SAP導入、ERP・基幹システムのプロジェクト管理、PMO、ベンダーマネジメント、周辺システム改修、ユーザー部門の進捗管理に関する
実務的な考え方を紹介します。
1. 基幹システム導入プロジェクトが遅れているとき、PM/PMOは何を確認すべきか
結論
遅延時は、遅れているタスクを急がせる前に、WBSの計画と実際の進捗、課題、プロジェクト体制、ベンダー作業、ユーザー部門の状況及びプロジェクト管理の仕組みをレビューすることが重要です。全体像を揃えることで、優先して対処すべき事項を判断できます。
はじめに
基幹システム導入プロジェクトでは、予定していたスケジュールから遅れが発生することがあります。
しかし、プロジェクトが遅れているときに、「遅れているタスクを急がせる」だけでは、問題が解決しない場合があります。
重要なのは、「なぜ遅れているのか、どこに問題があるのかを究明すること」です。
本記事では、基幹システム導入プロジェクトが遅れている場合に、PM/PMOとして確認したいポイントを整理します。
基幹システム導入プロジェクトが遅れるときに確認したい5つのポイント
1．WBSと実際の進捗が一致しているか
まず確認したいのがWBSです。
計画上のタスク、担当者、期限、完了条件が明確になっているかを確認します。
特に、
・タスクが細かく分解されているか
・担当者が明確か
・期限が設定されているか
・前後のタスクとの依存関係が明確か
・「完了」の定義が明確か
・タスク実施期間中の計画に対する進捗率が把握されているか
を確認します。
WBSが十分に整理されていなければ、プロジェクトの遅延状況を正確に把握することも難しくなります。
また、計画と実績のズレを可視化しないまま個別の課題に対応すると、根本原因を見誤りやすいためです。
まず全体像を揃えてから、優先度を判断する順序が有効です。
2．課題が適切に管理されているか
次に確認するのが課題管理です。
例えば、「ユーザー部門の確認待ち」という課題があった場合
・誰が対応するのか
・何をいつまでに行うのか
・対応しなかった場合に何が起こるのか
・後続工程にどのような影響があるのか
まで整理されている必要があります。
課題一覧が存在するだけでは、十分なプロジェクト管理とは言えません。
3．ユーザー部門の作業が止まっていないか
基幹システム導入では、IT部門だけでプロジェクトを進めることはできません。
業務部門による、
・要件確認
・データ準備
・テスト
・業務手順確認
・移行準備
などが必要になります。
そのため、プロジェクトが遅れている場合には、ユーザー部門の作業状況を確認することが重要です。
4．導入ベンダーの報告だけを見ていないか
ベンダーから、「予定通り進んでいます」という報告を受けていても、クライアント側で確認すべきことがあります。
例えば、
・実際に成果物が完成しているか
・レビューは完了しているか
・未解決課題が残っていないか
・後続工程への影響がないか
などです。
クライアント側にプロジェクトを判断できるPM/PMOがいることが重要になります。
5．プロジェクト管理の仕組みそのものに問題がないか
プロジェクトが遅れている場合、個別タスクだけではなく、管理方法そのものを確認する必要があります。
例えば、
・WBSが適切でない
・WBSが使われていない
・会議体が機能していない
・課題管理が形骸化している
・意思決定者が明確でない
・報告方法が統一されていない
といった問題です。
この場合、単に遅れているタスクを追いかけるだけでは、同じ問題が繰り返されます。
実際にプロジェクトを立て直した経験
SAPグローバル展開プロジェクトにおいて、当初のPMが短期間で離任し、PMOメンバーがPMを代行していたものの、プロジェクト管理方法に問題があり、プロジェクト開始後2ヶ月で既に進捗が1か月遅れの状況でPMを引き継いだ経験があります。
その際、プロジェクト管理の仕組みを見直し、WBSを再作成するなどしてプロジェクトの立て直しを行いました。
他にも立て直し事例は計9件あります。
まとめ
基幹システム導入プロジェクトが遅れている場合、
「どうやって遅れを取り戻すか」
だけを見るのではなく、
「なぜ遅れたのか」
を確認することが重要です。
WBS、進捗、課題・リスク、ユーザー部門、ベンダー、プロジェクト管理方法を総合的に確認することで、立て直すべきポイントが
見えてきます。
基幹システム導入プロジェクトの遅延・立て直しでお困りの方へ
プロジェクト途中からのPM/PMO支援、プロジェクト管理方法の見直し、WBS・課題・進捗管理等についてご相談いただけます。
2. 基幹システム導入プロジェクトでPMOが必要になる5つのケース
結論
PMOは、関係者が多い場合、プロジェクト管理の仕組みが不十分な場合、ユーザー部門の作業管理やベンダー管理が難しい場合、プロジェクトが遅延している場合に有効です。プロジェクトを横断して状況を整理し、判断につなげます。
はじめに
基幹システム導入プロジェクトでは、多数の関係者が関わります。
ユーザー部門、IT部門、導入ベンダー、海外拠点、周辺システム担当など、プロジェクトの規模が大きくなるほど、全体を横断して管理する役割が重要になります。
そこで必要になるのがPMOです。
PMOが必要になりやすい5つのケース
ケース1｜プロジェクト関係者が多い
複数部門、複数会社、複数ベンダーが関わる場合、情報共有や課題管理が複雑になります。
PMOは、
・会議体
・課題管理
・進捗管理
・報告
・関係者間調整
などを横断して管理します。
ケース2｜プロジェクト管理の仕組みが不十分
プロジェクトを開始したものの、
「進捗をどう管理するのか決まっていない」
「課題一覧はあるが更新されない」
というケースがあります。
この場合、PMOがプロジェクト管理の仕組みを整備することが重要です。
ケース3｜ユーザー部門の作業管理まで手が回らない
基幹システム導入では、ユーザー部門の作業が数多く発生します。
IT部門がプロジェクト全体を管理しながら、各部門の細かな作業まで管理することが難しい場合、PMOがその役割を補完できます。
ケース4｜導入ベンダーの管理が難しい
導入ベンダーが主体となってプロジェクトを進めている場合、クライアント側で進捗や成果物を確認する体制が重要です。
PMOが、
・ベンダー進捗
・課題管理
・リスク管理
・成果物品質
・スケジュール
等を確認し、クライアント側の判断につなげます。
ケース5｜プロジェクトが遅延している
プロジェクトが遅延している場合、PMOがプロジェクト全体を横断して状況を整理することが有効です。
個別のタスクだけではなく、
・スケジュール
・WBS
・課題
・リスク
・体制
・会議体
・意思決定
などを総合的に確認します。
PMOは「資料を作るだけ」の役割ではない
PMOというと、
「会議資料を作る人」
というイメージを持たれることがあります。
しかし、プロジェクトの状況に応じて、PMOはプロジェクト管理そのものを支える役割を担います。
実際のプロジェクトでは、
・課題を整理する
・担当者を確認する
・期限を設定する
・進捗を確認する
・ベンダーと調整する
・ユーザー部門に作業を依頼する
・PMに判断材料を提供する
といった実務が必要になります。
これまでのPMO経験
これまで41件のプロジェクトを経験し、基幹システム導入プロジェクトではプログラムマネージャー/PM、サブPM/PM補佐、PMO等の役割を経験しています。
また、S/4HANAの国内工場展開では、クライアント側のデータ移行PMOとして、移行方針・計画、作業ガイド、進捗管理等を担当しています。
まとめ
PMOが必要かどうかは、単純にプロジェクト規模だけで決まるものではありません。
「プロジェクトを横断して管理する人が必要か」という観点で考えることが重要です。
基幹システム導入プロジェクトのPMO人材が不足していませんか？
フルタイム、週2～3日程度、スポット等、プロジェクトの状況に応じたPM/PMO支援についてご相談いただけます。
3. 基幹システム導入プロジェクトでベンダー任せにしてはいけない理由｜導入プロジェクトのベンダー管理
結論
ベンダー任せにせず、スケジュール進捗、進捗、成果物、課題・リスク、クライアント側の作業を把握し、必要なクライアント側で必要な判断を行える状態をつくることが重要です。
はじめに
基幹システム導入プロジェクトでは、導入ベンダーが多くの作業を担当します。
専門知識を持つベンダーに任せることは必要ですが、
「すべてをベンダーに任せる」
ことと、
「ベンダーを適切にマネジメントする」
ことは異なります。
なぜクライアント側の管理が必要なのか
導入基幹システム導入プロジェクトでは、最終的に業務を利用するのはクライアントです。
そのため、
・本当に必要な要件なのか
・スケジュールは妥当なのか
・成果物は十分なのか
・課題は解決されているのか
・ユーザー部門の準備はできているのか
をクライアント側でも判断する必要があります。
ベンダー管理で確認したい5つのポイント
1．スケジュール
ベンダーが提示するスケジュールについて、
「なぜこの日程なのか」
を確認します。
各タスクの前提条件や依存関係を確認し、全体スケジュールとの整合性を見ることが重要です。
2．成果物
成果物については、
「提出されたか」
だけではなく、
「プロジェクトを次の工程へ進められる品質になっているか」
を見る必要があります。
3．課題・リスク
課題やリスクが発生した場合、
・影響
・対応策
・担当者
・期限
を明確にします。
4．クライアント側の作業
ベンダー側のタスクだけを管理しても、プロジェクトは完了しません。
クライアント側の、
・要件確認
・データ準備
・テスト
・レビュー及び承認
・業務手順整備
なども管理する必要があります。
5．判断事項
ベンダーから複数の選択肢を提示された場合、クライアント側で判断する必要があります。
そのためには、
・選択肢
・メリット
・デメリット
・コスト
・スケジュール影響
・業務影響
等を整理する必要があります。
「ベンダーを管理する」とは、対立することではない
ベンダーマネジメントは、ベンダーを監視したり、責任を追及したりすることではありません。
重要なのは、「プロジェクトを成功させるために、クライアントとベンダーの役割を明確にすること」です。
ベンダー側とクライアント側の双方の経験を活かす
私は日本IBM、IBMビジネスコンサルティングサービス、NTTデータ グローバルソリューションズでSAP等のシステム導入プロジェクトを
経験し、その後は個人事業主として導入ベンダー及びクライアント側の双方の立場で活動してきています。
そのため、ベンダー側の事情とクライアント側で管理すべき事項の双方を意識してプロジェクトを支援します。
まとめ
基幹システム導入プロジェクトでは、ベンダーの専門性を活用することが重要です。
同時に、
「クライアント側が何を判断し、何を管理するのか」
を明確にしておく必要があります。
ベンダー任せになっている基幹システム導入プロジェクトについてご相談ください
クライアント側PM/PMOとして、進捗、課題・リスク、成果物、スケジュール、ユーザー部門の作業等の管理を支援します。
4. 基幹システム導入に伴う周辺システム改修・再構築のプロジェクト管理
結論
基幹システム本体と周辺システムを別々に管理するのではなく、インターフェース、データ移行、外部結合テスト、ベンダー間調整を含めた全体の依存関係を整理して管理することが重要です。
はじめに
基幹システム導入プロジェクトでは、基幹システム本体だけを考えればよいとは限りません。
既存のローカルシステム、MES等の周辺アプリケーション等について、
・改修
・再構築
・廃止
・基幹システムとの連携方式変更
・インターフェース変更
・データ移行
・テスト
・ベンダー間調整
などが必要になる場合があり、複雑に絡み合う点です。
全体の依存関係を整理しながら管理する必要があります。
そのため、「基幹システム本体と周辺システムを含めたプロジェクト全体の管理」が重要になります。
特に、各要素の依存関係を可視化し、どの変更がどこに影響するかを整理したうえで進めることです。
周辺システムがプロジェクトを複雑にする理由
例えば、
「基幹システム→周辺システム」
というインターフェースが存在している場合、SAP側の変更によって周辺システム側にも影響が発生する可能性があります。
逆に、周辺システムを改修することでSAP側の要件やテストにも影響する場合があります。
そのため、
「基幹システム導入プロジェクト」
「周辺システム改修プロジェクト」
と完全に分けて考えることは難しいケースがあります。
管理すべき5つのポイント
1．システム間の依存関係
どのシステムがどのシステムと連携しているのかを整理します。
2．要件の整合性
基幹システム側の要件と周辺システム側の要件に矛盾がないか確認します。
3．スケジュール
基幹システム本体のスケジュールだけでなく、周辺システム開発、テスト、データ移行、インターフェーステスト、総合テストなどを含めて管理します。
4．ベンダー間の調整
基幹システム導入ベンダーと周辺システムの開発・運用ベンダーが異なる場合、ベンダー間の調整が必要になります。
5．責任分界
障害や課題が発生したとき、
「どのシステムの問題なのか」
「どのチームが対応するのか」
が不明確になることがあります。
そのため、役割・責任範囲を明確にしておくことが重要です。
実際に経験した周辺システム改修プロジェクト
大手製薬会社のSAPグローバル標準システム導入では、日本法人固有のSAPシステムをグローバル標準SAPへ置き換えるとともにBPRを実施。
その中で、
・ローカル周辺システムからグローバルSAPへの連携
・グローバルSAPからローカル周辺システムへの連携
・ローカル周辺システムの改修
・インターフェースの改廃・追加
などを含む複雑な構成となっていました。
その中で、周辺システム全体のプログラムマネージャーを担当しながら、データ移行/インターフェース開発・廃止・検証/ローカル主要周辺5システムの改修についてPMを、さらに10のMESシステム改修及びグローバルSAP連携ではPMOを兼務しています。
基幹システム本体だけではなく「全体」を見る
周辺システムを含むプロジェクトでは、
基幹システムだけを見ていてもプロジェクト全体は管理できません。
基幹システム本体、周辺システム、データ、インターフェース、ユーザー部門、ベンダー等を横断して見る必要があります。
まとめ
基幹システム導入に伴う周辺システム改修・再構築では、
「基幹システムを導入するプロジェクト」
ではなく、
「基幹システムを中心としたシステム全体を再構築するプロジェクト」
として考えることが重要です。
基幹システム導入と周辺システムの改修・再構築でお困りの方へ
基幹システム本体だけでなく、周辺システム、インターフェース、データ移行等を含めたPM/PMO支援についてご相談いただけます。
5. 基幹システム導入におけるユーザー部門の進捗管理をどう行うか
結論
ユーザー部門の作業は、WBSに落とし込み、担当者・期限・完了条件を明確にしたうえで、進捗状況と遅延が起きた場合の対応方法及び遅延の影響を確認することが重要です。
はじめに
基幹システム導入プロジェクトでは、IT部門や導入ベンダーだけではなく、ユーザー部門の協力が必要です。
しかし、
「ユーザー部門に作業を依頼したが、進捗がわからない」
「各部門の作業が遅れている」
「IT部門だけでは各部門の進捗まで管理できない」
という状況になることがあります。
このような場合、PMOによるユーザー部門の作業管理が重要になります。
ユーザー部門の作業を「具体化」する
「テストをお願いします」だけでは、担当者によって認識が異なる可能性があります。
そのため、
・何をするのか
・誰がやるのか
・いつまでに行うのか
・何をもって完了とするのか
を明確にします。
進捗管理の基本
1．作業をWBSに落とす
ユーザー部門の作業も、可能な限りWBSに落とします。
例えば、
テスト準備
↓
・テストケース確認
・マスタ確認
・テストデータ準備
・担当者確認
・実施日確定
というように具体化します。
2．担当者を明確にする
「営業部」「経理部」という単位だけではなく、可能な限り担当者・責任者を明確にします。
3．期限を設定する
「なるべく早く」ではなく、具体的な期限を設定します。
4．定期的に進捗を管理する
進捗確認は、「何しましたか？」や「終わりましたか？」だけでは不十分です。
これでは単なる実績収集で、タスク実施中の進捗は分かりません。
タスク実施期間中の遅延や未完了の場合、
・何が止まっているのか
・なぜ止まっているのか
・誰の対応が必要なのか
・いつ完了できるのか
を確認します。
5．遅延が起きた場合の対応方法
問題点を整理・確認のうえ、リカバリー策を立て、必要なフォローを行います。
詳細化・具体化されたタスク計画(WBS)があることで、遅延の原因を特定しやすくなります。
6．遅延がプロジェクト全体に与える影響を見る
ユーザー部門の作業が遅れた場合、後続のテスト、移行、教育、稼働準備等に影響する可能性があります。
そのため、個別タスクだけでなく、プロジェクト全体への影響を確認します。
データ移行では特にユーザー部門の管理が重要
データ移行では、ユーザー部門によるデータ確認・準備等の作業が発生します。
S/4HANA国内工場展開プロジェクトでは、クライアント側のデータ移行PMOとして、
・データ移行方針作成
・データ移行計画作成
・作業ガイド作成
・IT部門との打合せ等のコーディネーション
・進捗管理
等を支援しています。
移行チームの規模は総勢205名で、移行チームのPMOとして参画しています。
PMOがユーザー部門に入るメリット
ユーザー部門の作業をPMOが管理することで、
・作業内容が明確になる
・担当者が明確になる
・作業遅延を早期に把握できる
・IT部門と業務部門の認識を合わせられる
・プロジェクト全体への影響を把握できる
といった効果が期待できます。
まとめ
基幹システム導入におけるユーザー部門の進捗管理では、
「依頼する」
だけではなく、
「作業を具体化する→担当者を決める→期限を決める→進捗を確認する→遅延の影響を管理する」
というサイクルを回すことが重要です。
ユーザー部門の作業管理まで手が回らない場合は
クライアント側PMOとして、ユーザー部門への作業依頼、WBS管理、進捗確認、課題管理等を支援できます。