業務要件を整理して機能要件に落とし込む一連のステップは，パッケージ導入ならではの醍醐味があり，コンサルタントにとっては腕の見せどころである。しかし，顧客とコンサルタントの意見が衝突して，双方が気まずい思いをすることが少なくない。 その原因の一つは，パッケージの標準プロセス/機能を押付ける一方的な姿勢，あるいは反対に顧客の要求を丸飲みする受身的姿勢で，コンサルタントが機能要件の定義を進めてしまうことにある。そのような進め方をすると，どんな結果を招くのだろうか。 まず，実現方法の決定が迷走した結果，プロジェクトが止まる。「運用可能な新業務プロセスを定義できない」「適合率が著しく低くなった結果，プロジェクト・オーナーがパッケージ導入のメリットを出せないならば必要ないと判断する」といったことが想定される。だが，この種のチェック機能が働くのはまだ良い方である。 もっと面倒なケースでは，意思決定の根拠
「何でもできます。死ぬ気でがんばります――。そんなITベンダーは要らない。その道の“プロ”をユーザー企業は求めている」。オリンパス IT改革推進部の北村正仁部長は、2008年11月26日に東京都内で開催された「IT Service Forum 2008」でこう訴えた。 同社は2002年から4年がかりで、ERP（統合基幹業務システム）パッケージをビッグバン導入した。プロジェクトの経験を振り返り北村部長は、「（ERPパッケージにかかわる）日本のITベンダーの常識は間違っている」と指摘する。 「ERPのベストプラクティスで業務改革を推進しましょう」「システムに業務を合わせてください」「品質が安定していて実績のある（最新ではない）バージョンを採用しましょう」「（開発日程が延び費用が増えると）最後まで死んでもやりきります」――。もし、この4つの決め台詞をITベンダーが言ったとしたら、「それはプロでは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く