[「2025年の崖」に立ち向かうERP刷新プロジェクトの勘どころ]

基幹系刷新プロジェクトのフェーズ別留意点と「成功の秘訣」:第4回(最終回)

2019年6月21日(金)磯谷 元伸(NTTデータ グローバルソリューションズ 代表取締役社長)

前回は、基幹系システム刷新プロジェクトにおいて、日本企業特有の慣習などに起因する難しさについて述べた。では、実際にプロジェクトを推進する際、全体計画、体制や開発の各フェーズで、どのような点に留意すべきなのか。本連載の最終回となる今回は、プロジェクトの体制から開発フェーズごとの留意点を解説し、最後に当社が培った経験から導き出された「成功の秘訣」をお伝えする。

図1:基幹系刷新プロジェクトのフェーズ別留意点
拡大画像表示

全体構想と体制づくり

 グローバル最適化を目指した業務改革・基幹系システム刷新について、全社・ビジネス部門の理解、醸成が得られたとして、会社としても基幹系システムの刷新は10~20年ぶりの大仕事になるところがほとんどであろう。経営トップやビジネス部門責任者、またCIOとして、トップ自ら旗振りをし、最終的な意思決定をしてもらうポイントは非常に多い。

全体構想における留意点

・目的の明確化:情報システム部門からすれば、システムの老朽化や保守期限切れを理由にしがちだが、それらのシステム的な都合だけで経営層やビジネス部門から理解が得られるだろうか。「それだったら、システム部門に任せておけばいいや」となりがちだ。

 グローバルレベルで何をマネジメントしたいのか、事業管理を高度化することでどんなメリットが期待できるのか、全体最適化を目指した業務改革とは何なのか──などなど、システム刷新の目的について、全社的なコンセンサスが得られるまでしっかりと議論することが何よりも重要だ。

・計画づくり:検討・カバーする領域としてはグローバル・全事業領域の全体最適化を目指しつつも、一気呵成に刷新しようとすると、大規模プロジェクト(いわゆる「ビッグバンプロジェクト」)になり、仕様調整・体制面・管理面などすべてにおいてリスクが増大する。

 プロジェクトを円滑に推進するために、自社・ベンダーを含む多くのコアメンバーの確保、負荷を平準化する観点からも中長期での段階的なアプローチをお勧めすることが多い。

・予算化:企業全体を巻き込んだ一大プロジェクトとなるために、予算の立て方、実行管理の仕方、アローアンス(補正予算)の持ち方など、従来のシステム開発とはレベルの異なる考え方、腹積もりが必要となろう。例えば、構想段階終了後、ベンダーに見積り依頼を出すケースが多いが、この段階ではどのベンダーもPMBOKで言うところの超概算見積り(ROM:Rough Order of Magnitude)として一般的に±50%のブレが生じる可能性があることを、情シスの皆さんにもぜひご理解いただきたい。

体制づくりにおける留意点

・全社的な協力体制:グローバル化した日系企業における基幹系システム刷新はビジネス部門×コーポレート部門×情報システム部門によるプロジェクト体制が、海外グループ会社や国内の機能別グループ会社内にもある3部門をそれぞれ巻き込んでいくため、非常に複雑になる(図2)。

 そこでは本社の中で顔見知りのミドルマネジメント同士が「あうんの呼吸」で進めるようなやり方は通用しない。本社トップ・各部門の幹部、グループ会社幹部がプロジェクトの意義・目的をプロジェクトメンバー・関連部門にしっかりと伝え、自らも定期的な報告・ステアリングコミッティに参加することで、プロジェクト内外での意思疎通を円滑に保つことが重要である。

図2:基幹系システム刷新プロジェクトにおける複雑なプロジェクト体制
拡大画像表示

・ビジネス部門/コーポレート部門:全社的な業務改革を進め、業務プロセスを決定するキーパーソン(SAPプロジェクトでは「プロセスオーナー」と呼ぶ)をまずはしっかりとアサインすることが重要だ。ビジネス部門でもコーポレート部門でも優秀なキーマンは本業との半稼働といったケースが多いが、現業の業務が忙しくなると0.2や0.1稼働、最悪、週に1~2時間程度、打合せか検討に時間が割ければよいほうという状態になりがちだ。

 これでは新システムに必要な業務仕様の検討はできないし、ましてや業務改革に向けて本腰で全社業務を変えていこうという話にはならない。結果的にシステム部門やベンダーに「現行どおりで」もしくは「そちらで何かよい案を提案してよ」と丸投げすることになるのがオチだ。

 また、各部門から出てきたプロセスオーナーだけでは会計・生産・販売といった業務間を横串で連携させ、バリューチェーン全体を見通した業務プロセスの最適解を考えられる人材はそもそも少ない。自社グループ全体のプロセス設計を担える人材を、プロジェクトを進めながら育成していくことも必要だろう。

・情報システム部門:情報システム部門やシステム子会社内でも会計や販売といった業務アプリケーションごとに担当を分けているところが多いが、新システムの検討を既存システム側の維持と並行して担当する場合、やはりこちら側も0.5稼働程度しか捻出できないことが多い。検討当初はそれでも回せるかもしれないが、要件定義が具体化し、開発フェーズに入っていくと兼任体制でプロジェクトを乗り切ることは不可能だ。

 それは、現実的に既存システムすべてが単一のERPに乗り替わるわけではなく、周辺系システムと言われる部分でも、新システム導入に合わせて多くの検討・改修が必要となるからだ。大手企業への導入の場合、数多くの周辺システムを抱えているため、既存側での対応工数や予算がERP導入費用とほぼ同額(つまり予算が2倍)となるケースも少なくない。有識者を既存システム・周辺システムの維持・塩漬けの日常業務から外せるよう、日ごろから情報システム部門内の人事ローテーションや一部アウトソースについて検討しておくべきだろう。

この記事の続きをお読みいただくには、
会員登録(無料)が必要です
  • 1
  • 2
  • 3
バックナンバー
「2025年の崖」に立ち向かうERP刷新プロジェクトの勘どころ一覧へ
関連キーワード

2025年の崖 / ERP / SAP / 基幹システム / ACID

関連記事

トピックス

[Sponsored]

基幹系刷新プロジェクトのフェーズ別留意点と「成功の秘訣」:第4回(最終回)前回は、基幹系システム刷新プロジェクトにおいて、日本企業特有の慣習などに起因する難しさについて述べた。では、実際にプロジェクトを推進する際、全体計画、体制や開発の各フェーズで、どのような点に留意すべきなのか。本連載の最終回となる今回は、プロジェクトの体制から開発フェーズごとの留意点を解説し、最後に当社が培った経験から導き出された「成功の秘訣」をお伝えする。

PAGE TOP