IT導入・システム開発を始めるにあたって、要件や進めるための体制等が決まっていて、それによってプロジェクトとして進めることが難しくなったり、問題の原因となったりすることがあります。
ここでは３つほど事例を挙げます。
他のITシステムと連携することが要件であったが、結果的に繋がらず中止
中堅商社の販売管理基幹システムを構築する案件がありました。
発注側の中堅商社はITベンダーにITシステム全体の構築を依頼しました。
この販売管理基幹システムは、売上データを結果的に財務会計システムに連携する要件となっていました。
財務会計システムは、発注側企業に元々存在するものであり、そのシステムの仕様に合わせる必要があります。
このITシステムの開発プロジェクトは難航しました。
発注側企業は多くの独自業務ケースを販売管理基幹システムに盛り込もうとしていました。
担当営業毎に契約内容が異なるなど、ITシステムは複雑なモデルとなっていました。
ケースがあまりにも統一されていないため、今までは各営業担当が作業し、財務会計システムに取り込んでいたデータを、ITシステム間連携にして省力化しようというのが、今回の目的となります。
しかし、この複雑さが仇となり、難航していました。
そして、財務会計との連携構築については、複雑そのものでした。
営業担当が各自の判断で金額を合計し、財務会計システムに投入していたものを、システムに計算させることが、8割まではできてもあとの2割がどうもうまくいきません。
ITシステム開発プロジェクトは期間延伸し対応していきましたが、結果的には連携できないデータを手作業で都度書き換えることになっていました。
ITシステムは完成していない、として頓挫することとなりました。
今回についてはどちらかというと実現できなかった受注側のITベンダーが責任を問われることとになりました。
ただし、仕様の正しい提示を如何に行えるかによって、場合によっては発注側も責任があり得るというものになります。
諸事情によりシステム開発体制としてITベンダーが2社となり、一つのITシステムにならなかった
リース会社におけるリース管理システム構築の案件がありました。
このリース会社は、元々一部商品においてリース管理のシステムを保有しており、今回は元々あったITシステムに加えて、全体のリニューアルという位置づけとなっていました。
元々あったリース管理システムは、ITベンダーAが保守を行っていました。その関係から、一部商品の部分はITベンダーAに依頼することが決定していました。
ITベンダーAは大きな会社ではなかったため、全体のシステム構築を受けられず、全体はITベンダーBに依頼しました。
ITベンダーBは、ITベンダーAの部分も含めて全体の構築管理を行うこととしました。
この体制構築が不幸の始まりでした。
ITベンダーAの担当部分は、他の商品とは契約や性質が異なっていました。しかし、発注側はあくまでも全体としての一体化ITシステムを希望していました。
元々別々なITシステムにしたほうが結果的には早かったかもしれませんが、多くの共通部分を作り、全体最適志向の下に進めたため、途中からは引き返すことができませんでした。
ITベンダーAは担当部分は熟知していたため、その範囲においては間違いなく進めようとしました。しかしITベンダーBから全体としてみると矛盾点が出てきて、何度も変更を要求していくこととなりました。
ITベンダーBは全体の構築管理をすることとなっていますので、やっていることは間違いはありません。
ただし、ITベンダー間の関係は悪化していきました。
結果、本来は完成という段階となっても障害だらけでまともに動かない状況となっていました。
今回のケースでは、発注側が2社のITベンダーの管理をより行うべきであったと、責任を問われることとなりました。
ITベンダーBに丸投げしようとしたことが仇となったということになります。
IT導入・システム開発において、実現すべき機能以外の要件がはっきりしておらず、結果使えないITシステムとなる
中古車輸入販売業の注文システムのITシステム開発にて起きた件です。
発注側企業はITベンダーに注文システムを依頼しました。
注文システムは一見完成しました。要件どおり動きます。
最終確認を行っている段階で、本社担当がセキュリティ面が大丈夫かと心配となり、少し世間事情を調べました。
一般的なサイトのセキュリティ対策は当然組み込まれているべきであるとし、ITベンダーに報告させました。
すると、セキュリティ対策が施されていない部分が発見されました。
発注側は当然実施すべき、と主張しました。
しかし、受注側は明示的に要求されていないとし、そのまま納品することを求めました。
このまま注文システムを使用すると、悪意のあるユーザから情報を搾取されてしまいます。
近年このような搾取行為が増加します。やはりこのままでは、使えないと判断せざるを得ません。
発注側と受注側は険悪となり、争うこととなりました。
結果としては、発注側が認められました。
特に明示していないものの、実装されていて当然ということとなったわけです。
ここでも気を付けたいのは、このように当然だと認められるケースばかりではない、ということです。
必要な機能は比較的明示していくのですが、いわゆる非機能という部分は、特に明示せずあいまいになっていることがあります。
問題となった場合は、発注側が追加費用を支払うことにもなりかねませんので、機能以外の面でも注意していきたいです。
まとめ
IT導入・システム開発において、どのように進めていくのかという計画段階でリスクが潜んでいます。
他の既存システムに繋げたい、複数ベンダーに頼まざるを得ない、機能以外の要件が見えていない、といった例を出しましたが、こればかりでなく、ITシステム開発を難しくする様々な要素があります。
やりたいことそのものが難易度が高いことはよくあることです。それを乗り越えれば、独自の強みを発揮できるITシステムを活用することができる時がきます。
しかし、難易度が高くなるということは、下手すると完成しないリスクもあるということです。
予め難しくなりそうな点に注力して、問題とならないようやるべきことを漏れなく整理していくしかありません。
コメント