さて、今日のテーマは「なぜ起こるトラブルプロジェクト」です。ITネタですみません。
実はある会社の社長と会長からトラブルプロジェクトを何とかしてくれ、と言う
要件で呼ばれましたので、その時のやり取りをから要点を拾って書いてみます。
1,事象
SAP http://www.sap.com/japan/index.html 導入プロジェクトにおいてプロジェクトマネジメント
が機能不全に陥りプロジェクトの状況が何も分からないまま、ユーザー検収テストのフェーズを
向えてしまい、どんな問題が発生するか想定できなくなった。
2,原因
プライムプロジェクトをマネジメントする実力が無いのに「請負」形式で受注してしまった。
プロジェクトマネージャの力量不足。
マスターデータや移行対象データの責任者が不在。（スケジュールすらされてない）
ユーザートレーニングの責任者が不在。（スケジュールすらされてない）
ユーザーの参画度合いが極端に低い。
ベンダー（下請け）管理の不在。
パッケージ販売元であるSAP Japanのサポートを全く利用していない。
本稼働後の体制を誰も考えていない。
運用設計ができていない。
責任者不在。
3,対応
依頼内容は、とにかく現場を調査して問題点を探し、プロジェクト管理を正常化させて欲しい
と言う内容だったが、今更一人経験者が入ってもスーパーマンではないので手遅れと判断して
以下の内容の内今から間に合うものを実行してもらう事に留めた。
1,契約（役割分担）の見直し
もし請負契約になっているのでしたら、それをタイム・アンドマテリアルもしくはSESのサポート契約に変更し、稼働責任はお客様にある事を明記してください。
プロジェクト失敗の一番の原因はエンドユーザーからベンダーへのプロジェクトの丸投げです。
2,導入フォーカスの見直し
何でもかんでもお客様の言われる通りにアドオンするのではなく、SAP HCMの標準機能で対応可能な範囲にフォーカスを限定し、
イレギュラープロセスはお客様によるマニュアル対応を基本としてください。その場合のキーサクセスファクターはエンドユーザーの参加とチェンジマネジメントです。
3,SAP Japan及びSAP AGを最大限に活用
先ずエンドユーザーのSAP Japan担当営業を確認しサポート依頼をしてください。
発生する課題は全てOSSに登録して一元管理してください。OSS番号があればSAPのサポートデスクが問題を切り分けして、既にあるバグ情報であれば
SAP Japanのサポートから対応策の提示があります。コンサルティングマターであればセカンドレベルであるSAP Japanのコンサルティング部隊がヒアリングもしくは
オンサイトで対応し、ソリューションを提供します。それでも解決しない問題や開発マターの問題はSAP AGの開発部隊にエスカレーションされSAP AGの
デベロッパーからNoteがでます。重要なのは自分達だけで何とかしようとしない事です。OSSにもLow, Mid, High, Escalation 等優先度がありますから、
必要に応じてSAP Japanのエスカレーションマネージャーにもご相談ください。
4,マスターデーター及び移行データーについて
マスターデーター及び移行データー（パラメータテーブル・在庫・仕掛・AP/AR等）の方針設計及び実行チームはインプリのチームとは独立した別チームを
編成してなるべく早めに着手してください。このチームの成功は一義的にエンドユーザーの参画にかかっています。必ずエンドユーザーに参加してもらってください。
5,ユーザートレーニングについて
4,と同様別チームとして、方針設計及び実行には早目に着手してください。エンドユーザーの参加の必要性は言うまでもありません。
6,稼働後のサポート
稼働後の運用サポート体制はプロジェクト中に決めておいてください。でないと運用できません。
7,マネジメントレポート
ERPの導入ばかりに目が行って、マネジメントレポートの検討がお留守になるケースが多いです。
経営層に必要な情報は何でどのような形で提供するのかについては、やはり別チームを作り早急に経営層と内容を詰めてください。
8,プロジェクトマネジメントについて
上記全てを調整し効率的に動かしていくのがプロジェクトマネージャーの役目です。
必ずエンドユーザーの責任者を当ててください。プライムベンダーのプロジェクトマネージメントとは次元が違います。
1,2,3,は既に工程が終了しており間に合わないので、4,以降を体制の見直しを含め実行してもらうしか手の打ちようがなかった。
ここまで読まれてお分かりだと思いますが、トラブルの原因の殆どが営業段階で作りこまれています。
必要なことは、営業段階でプロジェクトが分かる要員を入れてきちんとプロジェクト計画を立てるか、もしくは最初は計画立案フェーズ
だけの受注に留め、それをやってから実装に入る、この２つしかありません。
しかし、実際の営業現場では受注金額のみしか頭になく、計画という重要なフェーズが抜け落ちているのが現状です。
だから、いつまでたってもトラブルプロジェクトはなくならないのだと私は思います。
ただし、これはあくまでも私の経験を元にした自己流の考えです。この道のプロである白鳥さん、椎野さんに是非コメント頂きたいです。
もちろん他の方からも。
ここで、体系立ったプロジェクトマネジメントスキルを身に着けたい方向けの推薦図書を紹介します。
「トラブルプロジェクトの予防と是正」 瀬尾惠著 詳細及び著者の経歴は以下をご参照ください。
http://www.amazon.co.jp/%E3%83%88%E3%83%A9%E3%83%96%E3%83%AB%E3%83%BB%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%AE%E4%BA%88%E9%98%B2%E3%81%A8%E6%98%AF%E6%AD%A3%E2%80%95%E4%B8%80%E6%B5%81%E3%81%AE%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%BB%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A3%E3%83%BC%E3%82%92%E7%9B%AE%E6%8C%87%E3%81%97%E3%81%A6-%E7%80%AC%E5%B0%BE-%E6%83%A0/dp/4306011526
以上の一連のやり取りの後、その会長と社長は私に言いました。「そんな当たり前の事今更言われなくても知ってるよ」
では、何故手遅れになるような状態になったのでしょう？そうです、知ってると出来るは全く別なんです。
いくら知っていても、立派な資格を持っていても実践できなければ何にもならないのです。
Comments