リコーが挑む超高難度SAPプロジェクト 3領域でFit to Standardを貫いたPgMO運営
別々で動いていた刷新プロジェクト、リーダーの判断とは
PMOではなく「PgMO」で、3つのプロジェクトをマネジメント
前述の通り、3つのプロジェクトの立ち上げ時期は異なる。Fit to Standardのアプローチの下、途中から一本化して進めることにしたものだ。つまり、基本構想の策定が終わった段階で、プロジェクトオーナーやプライムベンダーを変えることはできない。そこで、せめて体制だけは一本化しようと大野氏がリーダーとなって立ち上げたのが「ERP展開推進室」である。各プロジェクトのメンバーを同組織に集約して心機一転、プロジェクトを始動することにした。
当然ながらSAPに統一し、ワンインスタンスで展開することにはリスクがともなうものの、そのメリットも大きい。たとえば、会社や事業をまたいでも同じ指標で経営情報を可視化できる。また、M&Aや事業構造改革といったイベントが発生しても、システム統合への対応を効率化できるだろう。他にも、コンプライアンス強化、オペレーション品質の均質化、業務とシステムのオペレーションコストの低減など、その優位性は多い。ただし、確実にプロジェクトの難易度は高まり、マネージャーの負担も増える。リコーでも複数の大型プロジェクトを同時進行させるため、常にプロジェクト間の整合性を維持しなくてはならず、連携を常に意識できるように計画調整の必要もでてきた。
また、複数システムの統合に付き物である「コード体系の不一致」という問題にも悩まされたという。生産管理と会計、それぞれのシステムにおける品目コード体系が異なっていたため、その統一に約1年程度を要した。さらに、SAPに一本化するにあたり、各領域のシステムで個別に考えていた類似機能の集約が必要になった。特に、SAPの外で開発しようと考えていたアドオンは、Fit to Standardを徹底する以上、重複なく共通化させなくてはならない。開発後の保守を含めて、効率的に行うための設計が必要になった。
これらの課題を抱える3つの大型プロジェクトを同時並行で進めるため、大野氏が立ち上げたのが「PgMO(Program Management Office)」である。当初、別々のプロジェクトとして進行していた関係で、各プロジェクトはどうしても担当領域ごとに物事を考えてしまう。ワンインスタンスで導入する以上、担当領域だけでなく、システム全体の関係性や他のプロジェクトへの影響を意識してもらわなくてはならない。そこで、PgMOとして3つのプロジェクトを“1つのプログラム”に束ねるプログラムマネジメントを導入し、「われわれは常にワンチーム」という志を掲げながら、個別最適ではなく全体最適を意識するように促した。プライムベンダー3社それぞれが対等な立場で参画する体制のため、リコーと各ベンダーの役割と責任範囲を明確にする狙いもあった。
グループ会社への展開に向けての学び
3つのプロジェクトで足並みをそろえるため、PgMOでは設計、開発規約の策定、テンプレートの適用や権限の考え方、周辺基盤やインフラを整備した。また、モジュール間の結合テストを円滑に実行するため、プロジェクト横断でのテストシナリオの作成から実行、マネジメントまでもPgMOでリードしている。当然ながら、PgMOの運営がすべて順調に運んだわけではない。大野氏は、「品質が安定するまでに想定以上の時間がかかり、テスト期間を延長する必要があった」と明かす。厳密に言えば、個社会計の領域は計画通りだったものの、3つのプロジェクトが連動している関係で、すべての展開計画を見直している。
プロジェクトで直面した問題は他にもある。業務全体を横断的に理解できる人材が不足していること、既存システムに精通したメンバーがいないことに代表される“人材の問題”だ。また、旧システムを限界まで維持してきたため、その設計書がなかったり、あったとしても内容が更新されていなかったりした。要件定義フェーズでは気づくことなく実装に進んでしまい、テストフェーズでの手戻りの原因になったという。「今回の結果を踏まえて、要件定義やテスト、移行フェーズで品質向上のために何をやるべきか整理し、今後のプロジェクトに活かしたい」と大野氏。今後、グループ会社への展開が続いていくため、今後の展開計画に反映させる予定だとする。
今、大野氏が考えていることは大きく3つだ。1つ目は、ここまでのプロジェクトの経験から得た学びを展開計画に反映し、QCDの向上を実現すること。そして、2つ目はSAPのバージョンアップである。グループ会社への展開を控えているが、導入時に「SAP S/4HANA 2021」を選択したため、2026年12月の保守期限が近い。2年までの期限延長が認められているため、その間に新しいターゲットバージョンの選定を行う必要がある。新しすぎず古すぎない、安定的に動作するバージョンを慎重に選び、効率的にバージョンアップを行う意向を大野氏は示した。
最後の3つ目は、SAPの保守・運用を進化させることだ。その一環として、AIアシスタントである「SAP Joule」の活用を視野にいれているという。どの業務領域に適用すべきか、ユースケースの評価・検証を進めていく。そして、長期的な視点からAI活用のスキルやノウハウを蓄積していき、内製組織への転換を目指すとした。
この記事は参考になりましたか?
- EnterpriseZine Press連載記事一覧
-
- リコーが挑む超高難度SAPプロジェクト 3領域でFit to Standardを貫いたPg...
- 第一三共の挑戦、AIエージェントを相棒にしてデータドリブン創薬研究の「次のボトルネック」を...
- 創業50年超のアシストが描く製品提供の「その先」 既存資産を殺さないSoR/SoIの現実解...
- この記事の著者
-
冨永 裕子(トミナガ ユウコ)
IT調査会社(ITR、IDC Japan)で、エンタープライズIT分野におけるソフトウエアの調査プロジェクトを担当する。その傍らITコンサルタントとして、ユーザー企業を対象としたITマネジメント領域を中心としたコンサルティングプロジェクトを経験。現在はフリーランスのITアナリスト兼ITコンサルタン...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア
