約10年、ひとつの企業のSAP（ECC 6.0)を保守してきて

カットオーバー後に混乱した場合は事業部門と近い人々は、事業部門との調整に追われます。また、上司への報告するための情報を集めます。事業部門の偉い人は経営層に報告するために情報を集めます。

残業代がでない管理職は、勤務時間は爆発的に増えますが、直でボーナスに響く案件なので、かなりつらい話になります。

（ちなみに混乱せずにうまくいったとしても、うまくいくのが当たり前という評価なので、ボーナスが良くなるわけでない。）

発生する障害にもよりますが、社内で完結する障害であればなんとかなります。ただ外部に影響する障害だった場合は、情報システム部と連携して対応します。

請求書にミスがあった場合は、再出力の調整や翌月での金額調整など、信用を失いかねない事態になります。

カットオーバー直後は、体制は整えますが、プロジェクトの成功失敗が決まる重要な局面です。ある程度のトラブルは想定内のはずです。

一番理想は、何も発生せずに、暇な時間がただただ過ぎていくこと。肩透かしが理想です。

発生した障害を管理して、事業部門と調整して、基幹システムの安定化に目指します。

要件漏れなのか、設計ミスなので、切り分けを行う時期でもあります。もっと簡単に言うと、情報システム部のミスなのか、事業部門のミスなのか、ベンダーのミスなのか切り分けを行います。その責任所在によって、どこが費用負担をするのか明確にします。

（なので、システム開発の時にテスト・検証はしっかりしましょう。そこを手を抜くと、この時期にお金がかかります。）

また何かシステム上で新しいことをすることはできず、障害対応を優先します。そういう意味でも、いろいろな機会損失につながります

発生する障害にもよりますが、開発段階でのテストで気づかなかった障害をつぶすことになります。

一番、困るのが、キーマンの要件を拾えておらず、追加要件にも関わらず、障害として言われるケースです。（もっとひどいのは議事録でOKといってるのに、いまさらNGと言われるケースかな。。。）

便利機能より、障害が優先されるため、業務の負担は減らずに対応する時期です。

導入企業がそのまま保守するケースであれば、プロジェクト導入のマイナスをこの段階で回収が可能です。

障害対応で障害を呼ぶケースが数件あるので、気を遣う時期でもあります。

事業部門の簡易なミスでリカバリーをする時期です。

この時期に、使われない機能の精査をします。上記に書き似ましたが、レポート系は統計情報をみれば、使われてないレポートがわかるので、整理整頓します。

また、地味に使われないドメイン値が発生する時期です。ドメイン値から削除したいのですが、データの分析をしないと発見できないので、いつまでも残り続けます。

けっこう悲しかったのは、まったく使われない受注伝票タイプがあること。苦労して作成した受注伝票タイプなのに。

業務は日々変わっていくので、事業部門との連携は常に必要です。

システムが安定稼働することとは直接関係ないですが、導入にかかわった人が他部署に異動になったり、転勤などでいなくなります。きちんと引き継ぎが行われればいいですが、導入からかかわった人に比べるとどうしても知識量は少ないです。それにより、ちょっとしたミスにより、リカバリが発生する時期です。

また、機能追加を考える時期です。情報システム部に相談する前に事業会社内で新規事業や業務の効率化に時間を割く時期です。この後のフェーズでどでかい案件を情報システム部にもってくるために準備期間です。

保守するメンバーを減らす時期です。なので、一人に負担が増え、属人化になる時期です。複数メンバーで複数企業を見るケースもあるようですが、やはり企業ごとに専門性が必要なので、属人化から進む時期です。

事業部門が、そこそこ大きい案件の相談する時期です。寝耳に水で聞くケースが多いので、大型の案件が重なる調整が必要です。

「1個400円ものを、3つ受注受けたら1,000円で販売したい。その品目は複数ある」と相談を受けて、アドオンが邪魔してできないケースがあります。初期段階の価格決定条件の要件があとあとになって邪魔するケースです。

また、DBのバージョンアップやOSのバージョンなども発生する時期なので、仕事量が減るわけではないです。常にそこそこ忙しい。

ベテランの人がいなくなる時期でもあります。もしくはベテランがさらにベテランになります。

各部門に、めちゃくちゃシステム（SAP）に詳しい人が一人でてきます。

次の基幹システムにむけて、検討段階に入ります。そのためシステム開発が凍結とはいきませんが、縮小になります。新しい機能を作成しても、数年後にはなくなるので、よっぽどの理由（法対応など）がないと、改定をしません。