IT導入・システム開発をやると決まった時には、当然やりたいことがあってのことです。初めにやるべきことは、何をやりたいのかを決めることですが、その時点で既に失敗に向かっていることもあります。
しかし、決めた時点では、むしろ前向きで輝かしい未来が待っているように見えます。そのような企画に限って、大きなリスクを抱えているということが言えます。
失敗しそうなやりたいことを3つほど挙げます。
ひとつは、一般顧客向けにITシステムを提供するものです。
ふたつめは、システム統合していくという計画です。
三つめは、パッケージソフトが便利そうなので全体を入れ替えるという計画です。
どれもよくある計画ですし、もちろんすべてが失敗しているとは言いませんが、失敗の兆候は最初に決めた時にからあることもあるので、気を付けましょう。事例を紹介します。
一般顧客向けシミュレーション機能を提供しようとしたが完成せず
金融機関が顧客向けにライフプランのシミュレーションを行うITシステムをITベンダーに対し発注しました。
シミュレーションの結果を踏まえて金融商品を勧めるというものになり、その金融機関としては初の領域の取り組みでした。
このようなものは既に世の中に多くあるのですが、発注側はあまり慣れておらず、やりたいことの結果だけを求めました。
一旦完了に見えたこのITシステムに対し、発注側は少し違う、とのことで仕様変更を繰り返しました。
シミュレーションの計算方法は熟知している人は確認しないと結果があっているかがわかりませんが、この金融機関ははっきりと仕様を提示できないところがあり、やってはやり直しの繰り返しとなっていました。
受注側であるITベンダーはあまりにも仕様変更激しいにも関わらず、完成期限への対応は一切行わなかったことで、発注側との関係が決裂しました。
このITシステムの開発プロジェクトは、頓挫したわけですが、完成していないのにも関わらず、費用はできたところまでは払わなければならなかったという最悪の結果となっています。
散在するITシステムを統合すれば費用削減や効率化が実現できるという幻想
ITシステムは要求が大きい分野から導入していくものです。よって各分野でITシステムがばらばらに導入され、複数に入力する等非効率やミスを引き起こす原因になっていることがあります。
専門商社において、グループ間含めて散在したITシステムを統合するという計画がスタートしました。
このようなITシステムの計画にありがちなのは、統合が目的になっているということです。
統合すれば、データが一元管理や連動され、効率化され、さらには顧客満足にも繋がると考えていたのです。
この専門商社はITベンダーに発注し、ITシステムの開発プロジェクトを開始しました。
ところが開始して間もなくて、既に多くの課題が発生しました。
例えば、グループ会社の管理しているお客様出荷先情報と本社の出荷先は統合できるはずだ、ということで進めていたのですが、顧客事業所内で複数個所を管理している等の理由で管理レベルが一致していないことがわかりました。
このような言葉は似ているが実際は違うものが多く発見されました。
調査段階での下調べが足りなかったのでしょう。統合ということが目的とされていただけに、そのまま突き進んでいました。
統合ということは、業務を統合する必要もあります。言葉は似ていてもやはり実態が違うものが出てきて、どこまで統合にどこまで個別にするのか、ということがなかなか決まらなくなりました。
結局基本設計が終わらない、ということとなり、頓挫してしまいました。
当然発注側の管理責任が問われることとなりました。
パッケージソフトはすべてが出来上がっていて便利だと思いきや、導入まで至らず中止
医薬品関連事業を行う企業にてERPパッケージ導入の計画が立てられました。
元々はかなり昔に手作り開発されたシステムを長年使っていました。
ERPパッケージは年々進化しているため、多くの企業にて導入されています。
そこでこの企業においても導入のため、ITベンダーに提案から依頼をしました。
提案されたパッケージソフトはかなり便利な機能があり、業務上の問題を解決してれるものと思われました。
ただし、このERPパッケージは想定した業務フローに基づいて作られていましたので、実業務を合わせる場面も必要となります。
進めていくうちに、部門間における業務を大幅に変更する場面が出てきました。
この企業においては組織間の壁が大きく、組織間調整が難航しました。
業務フローを変更すると、顧客サービスが低下するという意見も出てきました。
仕様変更要求やアドオン追加要求が続々と出てきます。またそれらを急いで対応していくため、テスト時に不具合が多く発生してしまいます。そして、解決すべき不具合や課題が積み上がり、解決にどんどん時間を要していきます。
よくある失敗のスパイラルに陥りました。
ITシステムが完成していないとして、導入プロジェクトは中止となりました。
ERPパッケージが現状の業務と合わないというのはよくあることであり、説明不足であるという受注側の責任があると言われました。しかし、発注側も業務を変えないといけないことに対する決定遅れも散見されていました。
よって、このケースではどちらも責任はあるということになっています。
そもそもERPパッケージを導入するのが目的だったのでしょうか。その目的で進められていたとは思いますが、そうだとしたら業務をERPパッケージに合わせていくのがやるべき姿だと言えます。
しかし本当にそれがやるべき姿だったでしょうか。
経営として何をすべきか、というところから始まっていないため、合わないERPパッケージを選んでしまったのが、本当の失敗なのではないでしょうか。
まとめ
一般顧客向け等、一定のユーザが決まっていないものに対しての要件は、やってみないとわからないこともあり、なかなか決まりません。
ITシステムの統合は、一見夢のようではありますが、難易度の高いことであることを前提に考えたほうがよいです。
ERPパッケージの導入も同様で、すべてを解決してくれる手段と考えるのは危険です。
何をやりたいかと決める時には、実現できるのかを見極めないと、失敗に向かって走り出すことにもなりかねませんので、注意が必要です。
コメント