悩み多きユーザ企業

悩み多きユーザ企業


多くのユーザ企業が、システム開発で悩みを抱えているのではないでしょうか。

システム発注の前段階では、

(1)コンピュータの事はよく判らず、システム導入するために何をしたらよいのかわからない。

(2)システムの開発をどの会社に頼んだらよいのかわからない。

(3)契約書にはどのような条項をいれるべきなのか。

などなど。


システム開発段階、導入段階では、

(1)納期通りにシステムが出来上がらず、いつになったら導入されるのかわからない。

(2)当初の予算を大幅にオーバーしてしまい、いったいいくら掛かるのかわからない。

(3)出来上がったシステムを、どの様に受け入れ検収したらよいのかわからない。

などなど。

実際にシステム調達のコンサルをやらせていただく際、ユーザ企業はシステム発注までに何をすべきか、そしてどの様に段取りを立ててベンダーにシステムを発注すべきなのかを明確にします。

そして、システム開発段階、導入段階でのユーザ企業のすべきことも。

それでも、システム開発の様々な工程で問題は発生するものです。

私は、指導者面した表面的なコンサルをするのではなく、ユーザ企業のエージェントとして効率的なシステム調達のお手伝いをすることを目的とし、一緒に作業を進めていく方法をとっているので、ユーザ企業の内実にドンドン突っ込んでいきます。

そのため、一緒に悩みを抱えてしまうことも度々ありますが・・・

その原因がユーザ企業側にあるのか、ベンダー企業側にあるのかによって対処の仕方は変わります。

その都度、問題解決に向けた対策をたてて調整をするのですが、ベンダー側の原因による問題でかなり厄介なものもあります。


最近の実例として、

◇A社では、
予定通りシステムを発注したものの、ベンダー側のプロジェクト発足が遅れる。
原因は、担当SEが他のプロジェクトから抜けることができず、要員を確保できなかったのです。

◇B社では
要求事項に対する理解度が低く、ユーザ側の意図がなかなか理解できない。
ベンダー選定にあたり当該業界での経験を重視したのですが、担当SEが当該業務に関する知識に乏しかったのです。
ベンダーの 『会社としての経験知』 も大事ですが、システム開発の成否は担当する 『SEの個人の経験知』 によりに大きく左右されるのです。

◇C社では
ベンダー側の要員が揃わず、担当SEが何役もこなさなくてはいけない状況。逆にこちらが心配する有様・・・
でも担当SEは、焦りからどんどん先へ進めるが、その内容が設計に反映されないので、結局は仕様が後戻りしてしまう事に。

如何でしょうか?

いくらユーザ側で対策を立て、ベンダーに 『ああしろ』 『こうしろ』 と言っても、ベンダーの 『努力』 と SEの 『能力』 に期待して、ヤキモキしながらも待つしかない事もあるのです。

故に私は、システム発注時点で最悪のシナリオを想定しながら契約書をチェックし、如何なる場合 (ユーザの落ち度は別ですが) でもユーザ企業が不利にならないよう、事前に手を打つようにしてます。

また、ユーザ企業側のプロジェクト監理支援を行うときも、ユーザ企業側に落ち度がないように心掛けてます。この事は、結果としてベンダーの支援にもなっているようです。

システム開発では、導入したシステムが安定稼動するまで、悩みは尽きないものです。

事後の対処に追われるより、事前の対策を立てましょう。

システム開発のリスクを想定し、もしもの時の対策を立てておけば、多少なりとも悩みは減るのではないでしょうか。

0 件のコメント:

コメントを投稿

システム設計書

システム設計書 システム開発における設計書。 名前の付け方、内容の記述の仕方、実はこれ、ベンダーによってまちまちなんです。 名前の付け方に関して言えば、外部設計書/内部設計書というベンダーもあれば、基本設計書/詳細設計書というベンダーもあります。 場合によっては...