 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||
|
||||||||||||
| プロジェクトの予算超過を内製化で取り繕う | ||||||||||||
|
上記のその後の話もある。同プロジェクトでは、要件が決まらなかったといったこともあったが、それよりも第8社の技術力の問題によって、本番リリース時期がまだまだ延び、現場の担当者たちは苦労しているようだ。さらに、そのプロジェクトの予算超過に対して、「内製化」を考えているそうだ。つまり、自社のシステム部門から相当の要員を投入し、社員にサービス残業をさせたりすることで、何とか会計上は予算オーバーしないように見せようとしているらしい。 ところで、ベンダー選別を決めた事業部長がその後どうなったかというと、プロジェクトがはじまった3ヶ月後に取締役に昇進し、プロジェクトに関する責任を一切持ってない立場になっていた。 A社がプロジェクトが予算オーバーの対策に「内製化」をしたことは、本質的に粉飾決算の行為とあまり変わらないのではないか。 また、プロジェクトの成果に責任を持たない元事業部長はA社の利益というより、個人の政治関係を重視することを選択した。そこには、コラムのアジア通貨危機を引き起こす銀行の貸出担当者の行為と基本的に同様の「モラルハザード」があったとも考えられる。 こうした結果、このプロジェクトの調達はA社にとって効率的なものとはならず、紛れもないITの不良資産を作ってしまうことになってしまった。 |
||||||||||||
| 次々と「粉飾事例」が生み出されている！？ | ||||||||||||
|
上記のようなことを回避するため、システムを導入する前に、先行して採用したユーザ企業の事例を見学したり、その話を聞いたりするのはよくあることだ。 こうした事例の種類は、導入しているユーザ企業の都合によりリファレンス性の観点から図2のように分類できる。  図2：ベンダー事例のリファレンス性 実際に現地を見学しても、見えないものはたくさんある。同業他社であれば、競合の関係で一部しか見せないのが一般的だ。システムによって業務が動かせることを確認できたとしても、投資対効果のような証言を得られないこともあるだろう。 レベル4以上のレファレンス性がある事例であっても、本連載の第4回の事例のように、システムが動作するかどうかという基準から成功例として公開することが多い。 本来のシステム導入の目的に照らして、どれほど貢献できているかについては、話を聞いても把握しにくい。これは、導入したユーザ企業側が、システム導入の目的が十分明らかになる前にプロジェクトを発足させることにも起因している。 レベル3以下の事例ではベンダーの都合の合わせて脚色されている可能性が高く、レファレンス性は低い。こうした事例は、実績に基づく信頼性の証明というより、むしろシステムの運用方法の例として考える方が妥当かもしれない。 雑誌やアナリストなどの中立的な第3者が事例を作成する場合には、ベンダーによる脚色をある程度抑えられる。だが、導入効果の把握が難しいのは同じだ。 第3回でも述べたが、導入効果を享受するにはシステムそのものよりも、企業風土やプロセスなどの要素が必要になってくる。第3者による事例では、この点が表わされず均等に成功要因が書かれるケースが多くなりがちだ。 成功事例だけではなく、某誌では「動かない＊＊＊」といったベンダー泣かせの内容の記事が組まれる。だがこれも、あくまで動くかどうかという判断基準であり、「効果がない」「使えない」といった視点で公開される情報は少ない。 |
||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
