正確な見積は要件定義後にしかわからない

情報化調達では、ソリューションの決定と共に、ベンダーとの契約条件を決定しなければなりません。今回は、その費用に関して見て行きましょう。特に、今回は、ベンダー側から見た費用見積です。
一般に、情報化投資の費用は、ハード:ソフト:導入で、1:1:3であると言われています。投資総額の約60%が導入プロジェクトにかかるコストです。SAPの過去の統計では、これが、1:1:4~6という結果が出ています。
パッケージの導入では、アドオン開発がどの程度必要になるかによって、異なってきます。従って、提案時の見積は、アバウトな概算見積でしかありません。


しかし、この世の中、提案時の見積を後で変更する事は、ほとんど不可能です。よっぽどプロジェクト内容が変更になった場合を除いて。
結果として、要件が膨れ上がり、ベンダーが赤字になるという状態が良く見られます。このような場合、顧客とベンダー双方で、win-winの関係を築く事はできなくなってしまいます。プロジェクト終了後、2度とあの顧客との仕事はしたくない、というような愚痴がベンダー側から出る事もあります。
パッケージ導入に限らず、すべての開発プロジェクトの正確な見積ができるのは、要件が決定し、実現する開発規模が特定された時にしかわかりません。
では、どの様にすればよいか?
私が良く行った方法は、
・提案書提出時の見積は、概算見積である事を明記する
・概算見積作成の前提条件を並べる
・前提条件が変化すれば、見積も変化する事を明記する
・プロジェクトをフェーズ分けし、契約は、要件定義フェーズだけとする
・以降の開発フェーズは、要件定義終了後再見積をして、別途契約とする
・要件確定後の要求事項の新規追加は、別途見積とする
・要件確定後の要求事項の変更は、吸収できるかどうかを判断する
であり、顧客と十分に話し合った上で、契約を結びます。
この根底にある考え方は、
プロジェクトのスコープが変化したら、費用も変化する
と言うことです。意外とこれが分かっていない方が顧客に多いのも事実です。顧客側だけでなく、SIベンダーでも分かっていないところがあります。
F社がプライムを取ったあるプロジェクトでは、要件が膨れ上がり、収拾がつかなくなりました。いわゆる火が噴いた状態です。火消し役として、私を始め、プロジェクトマネジャーが3名入りました。
財務会計、管理会計、販売管理のチームリーダーとしてプロマネが入ったのです。私は、管理会計のリーダーとして入りました。この当時、複数のプロマネが投入されたプロジェクトとしては、SAP始まって以来初めてのことでした。
約2ヶ月で要件を整理し、方向性を決定しました。そして、顧客と、これ以降の変更は、別途契約ですと合意したわけです。また、新たに管理会計のメンバーを4名投入しました。
このプロジェクトのプロジェクトマネジャーとの話では、ここまででお役ごめんとなるはずでしたが、結局、それ以降カットオーバーまで約1年間常駐することになりました。良くある話です。
管理会計チームは、追加投入が4名で済みましたが、財務会計、販売管理は、結局追加投入数十名で、このプロジェクトは大赤字となりました。
このプロジェクトの問題点は、最初からボタンを掛け違っていたこと、営業が何でもできるようなことを言って契約してしまったことでした。これまた良くあるパターンです。
さらに、F社自体が、要件をすべて受け入れたことでした。要件を満たすため、アドオン開発を行い、アドオン開発を行なったため、標準機能では対応できなくなった部分があり、それをさらにアドオンで対応する。このような有様でした。
良くある帳票の開発だけではなく、このプロジェクトでは、要件を満たすために販売管理のモジュールの使用をやめ、1から販売管理を開発したようなものでした。財務会計も、標準機能は使用するが、販売管理と同じような感じでした。管理会計も結局、標準テーブルは使用するが格納するデータは、アドオンでロジックを作るというような状態でした。
F社との話もこじれ、険悪なムードの中でプロジェクトが進行したわけですが、このプロジェクトは、カットオーバーしたものの、明らかに失敗です。F社とは、訴訟寸前のところまで行ってしまいました。
さて、このような状況を回避するために、上に書いたような契約をすると、顧客側の皆さんから、「ベンダーの言いなりではないか!」と石が飛んできそうです。
顧客側として、どのような価格、費用に対する方法があるのか、それを次回、見て行きたいと思います。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*