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

この記事は chillSAP 夏の自由研究2020 の記事として執筆しています。

蜜蜂ハチ
蜜蜂ハチ

10年で色々ありましたが、一つの企業でSAPの保守を行い、見てきました。その経験を分析研究した結果を、SAPの話を交えながらの話になります。

基幹システムの導入後にはフェーズがある。

システム開発には、V字モデルと呼ばれるものがあります。基礎的な知識なので知ってる方も多いでしょう。

https://www.zooops-japan.co.jp/blog/carrier/blog181219/

私の経験上、システムを導入したあとでも同様にフェーズがあります。

今回は基幹システムとして、SAP(ECC 6.0)を導入した企業の立場から、そのフェーズを紹介します。導入モジュールは、MM、SD、FI、COです。

超混乱期(カットオーバー直後)

基幹システムの規模にもよりますし、案件によりますが。カットオーバーはどうなるか誰も読めません。なので、それなりの体制を整えて稼働日を迎えます。

標準機能だけでも混乱は発生します。ましてや、10年前の場合は、アドオン開発が当然だったので、混乱は避けられませんでした。

混乱しないためにも、開発段階の要件定義や十分なテストも大切ですが、それはシステム開発の初期段階の話です。

カットオーバー後に安定するためには、特に下記の3つが大切です。

  • マスタ
  • 移行
  • ユーザー教育

どれだけ立派な基幹システムを構築しても、マスタが存在しないと機能しません。

どれだけマスタが整っても、移行が失敗すればカットオーバー後は安定してません。

どれだけ移行が成功しても、システムをしっかりと理解して、使いこなせなければ、現場は混乱します。

正直な話、この段階でSAPだからという話はあまりないです。単純に基幹システム導入プロジェクトが成功失敗が問われる段階です。

情報システム部

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

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

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

事業部門

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

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

ベンダー

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

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

混乱期(障害多発期)

カットオーバー直後に暫定対応した障害の恒久対応をしていきます。優先順位を決めて、ひたすら障害をつぶしていきます。

想定外の処理時間がかかったJOBのパフォーマンスの対応も行います。

情報システム部

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

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

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

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

事業部門

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

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

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

ベンダー

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

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

安定期

小規模な障害は発生せず、改善要望がユーザーからよく来ます。また、使用されなくなる機能も出てくる時期です。せっかく作ったアドオンも使われなくなります。特にレポート系は担当がいなくなると、そのまま使われなくなることがよく起きます。

情報システム部

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

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

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

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

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

事業部門

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

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

ベンダー

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

大規模開発機

情報システム部

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

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

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

事業部門

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

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

次期基幹検討期

情報システム部

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

最後に

ここまで10年の経験をもとに、書かせてもらいました。

2025年の崖をこえて、S/4 HANAを導入しても、段階はそれほど変わらないと思います。しかし、発生する事象はまったく異なると思います。なので、あまり参考にはならないかと。

ECC 6.0 と S/4 HANAは似て非なるものです。また、RPAやAIなど復旧するので、基幹システムで何かするというのはなくなるでしょう。情報システム部は、SAP+周辺機能で対応する時代になると考えてます。

この記事は chillSAP 夏の自由研究2020 の記事として執筆しています。

蜜蜂ハチ
蜜蜂ハチ

ほかの人みたいに、技術の内容で技術を書きたかったのですが、このような内容のほうもなかなか聞けない話なので、書かせてもらいました。

chillSAPありがとうございます。

タイトルとURLをコピーしました