IT導入・システム開発のプロジェクトにおいて、いくつも頓挫するケースはありますが、発注側の問題が問われるケースも受注側の問題と同じくらいあります。
お金を出して発注したにも関わらず、自分の問題で発注したものが完成しない、というのはいかにも理不尽な話ではありますが、よくあることと言ってもいいです。
いくかの頓挫の兆候事例を見てみたいと思います。
業務改革がうまくいかずITシステムプロジェクトが破綻
医療機関におけるパッケージシステム導入での事例です。
この事例は億を超える規模の失敗です。パッケージシステムを導入しようと、医療機関では複数のベンダー提案の中から選定し、導入のプロジェクトを進めることとしました。
IT導入の担当メンバは選択したパッケージが気に入ったため、パッケージをそのまま導入する方針を決め
業務をパッケージに合わせることにしました。
プロジェクトが進んでいくうちに、やはり現場業務に合わない部分がどうしても出てきており、アドオンとして追加で機能を開発していきました。さらにプロジェクトが進んでいくと、どんどんアドオン要望がでてくることとなりました。
最初に業務会改革ありきで、アドオンなしの方針を出していたため、その反動は大きくむしろアドオンが増加傾向となってしまいました。
医療機関側は、現場の要望を抑えることができずに、要望は膨らむ一方となっていきました。
そして悪いことにアドオン開発した箇所は、後から急いで対応したいったため品質が悪く、動作確認がまともにできない状況となっていきました。
発注側のマネジメントが効かず、それに応えるかの如く受注側も品質が低下していく、そして関係が見る見る悪化していく、ということはよくあることです。
最後は要望への対応が収拾つかず、費用負担も整理できなくなっていたことから一旦中断へと追い込まれました。
この事例はどちらにも問題はありますが、どちらかというと発注側が当初宣言した業務改革を実行できなかったことのほうが問題です。
発注側がマスタ抽出作業に非協力的であったため頓挫
食品製造業における販売管理システムのパッケージシステム導入に関わる事案です。
ITベンダーを選択し、パッケージシステムを導入するという計画については、前出の医療機関の事例を似ていますが、今回は受注側であるITベンダーは比較的しっかりしていました。
パッケージシステムにはよくある追加機能要望がやはり多く出ていました。それに対し、作業外であることをITベンダーは会議を行い、記録をとっていました。
発注側は不満を覚えつつも、追加要望に対する作業範囲の内数か外数かを受け入れ、プロジェクトを進めていきました。
プロジェクトが後半となり、別な問題が出てきました。
パッケージシステムを稼働さえるためのマスタデータの取り扱いに関してです。
マスタデータは旧システムの中にあるデータを加工して、新システムに投入することになります。
マスタデータを移行するにあたっては、旧システムから抽出し一次加工するまでが発注側の役割とされていました。
しかし、一次加工という比較的単純な作業であったにも関わらず、発注側の食品会社では、できませんでした。
できないばかりでなく、受注側のITベンダーに押し付け、丸投げに違い状態となっていました。
異なったシステムのデータの意味を合わせ、新しいシステムに投入する作業は、業務上の意味合いをわかっている人でないとできません。にも関わらず、発注側が非協力的であったため、マスタデータ移行は進みませんでした。
初期データが投入されていなければ、当然新システムは動きません。
結果、プロジェクトは頓挫しました。
発注側は完成していない、という主張をしましたが、マスタデータ移行作業に協力を示さなかったため、主張は認められず、受注側に非はないとされました。
発注側のプロジェクトマネジメント責任不履行による大幅増額負担
ＥＣサイトにおけるキャンペーン用受注機能の案件がありました。
キャンペーンは実施時期が決まっていたため、急ぎ開発が進められました。
既存のＥＣサイトは別のITベンダーに委託しており、キャンペーンサイトのみのシステム開発案件でした。
しかし、キャンペーンサイトはＥＣサイトと標準仕様を合わせたりデータを連携させるということをしなければなりませんでした。
キャンペーンサイトを受注したITベンダーは期間がタイトな中、システム開発を進めていたのですが、既存ＥＣサイトとのつなぎの部分が仕様が決まらず、結果的にキャンペーンに間に合わないという事態に陥ってしまいました。
キャンペーンでの顧客申し込み条件による取引の違いなどを決めるにあたり、既存ＥＣサイト上の制約からキャンペーンでできることに制限が出ていました。
その制限をキャンペーン側で作り込むのか、作るとしてもどの範囲とするのかがなかなか決まらず、結果的にシステム開発量が当初想定の倍以上になっていました。
キャンペーンは開始できず、システム開発は中断となってしまいましたが、何が悪かったのでしょうか。
発注側は、既存ＥＣサイトとキャンペーンサイトの両方を管理しシステム開発を進めなければいけない立場でした。しかし今回は、発注側のプロジェクトマネジメントができておらず、結果要求が膨らみ、期限も超過してしまう、という事態を招いたということになります。
まとめ
IT導入・システム開発のプロジェクトにおいては、例えお金を出す発注側であっても、その責務を全うしなければ、プロジェクトは失敗に終わり、さらには損害賠償まで求められることもあり得ます。
IT導入・システム開発において発注側として特に注意しなければならないのは、発注側の現場からの要望を管理しコントロールすること、初期データ移行の役割分担を明確にし発注側作業をきちんと全うすること、そして他に発注しているのであれば、合わせて全体としての管理責任がある、ということです。
コメント