問題点

これは弊社で困っていた問題にかんするソリューションです。

弊社はもともと業務用ソフトウェアの受託開発を行っていたのですが、基本的な流れは、顧客の用件を聞いてから見積りを提出し、金額に関する話し合いをするというものでした。

実際は

というように、両社折り合うまで何度となく要件の聞きだしと、細かい仕様の詰め、見積り作成を繰り返していました。
車を買うのと同じで、このオプションを付けたら幾ら、取ったら幾ら、ディーラーオプションもあったり、メーカーオプションもあったり・・・という感じで、(車購入よりずっと目の細かな)協議を行います。

この作業は、弊社のような小さな会社も大手ソフトハウスも概ね同じでしょうし、業種が異なる受託業一般でも同じことだと思います。

弊社で起こっていた問題とは、見積りを何度も提出する中で最終的に発注をいただく見積りが、上図で云えば最後に出した「概算見積り4」とは限らないということです。
よくやる失敗は、発注いただいた「概算見積り3」に手を加えたものを詳細見積りに落として提出するようなとき、 特定のオプションをはずして、それに関連する他のオプションを取り損なうとか、はずすことができない筈のオプションを外してしまっているというものです。
結果、見積りの失敗の煽りを受けて、大概そのプロジェクトは赤字になってしまいます。

ソリューション サンプルはこちら

弊社のプロジェクトで大きく損をする見積りとは、お客様に言われて見積書の項目を複数削るときに、 その代替となる機能を付け加えることを忘れたようなケースで発生します。
お客様は、オプションをはずしたら、どのようなことまで出来なくなってしまうのか判っていたりはしません。
苦情をいただいた後に、無償で機能を追加する羽目になります。

まず必要なことは、お客様に、自身が注文しようとしているシステムが、どの業務と対応していて何をするものかを正確に理解してもらうことです。

システムは、概ね業務(プロセス)に対応しているわけですから、業務(プロセス)間の関連図をもってお客様と合意形成を図るのが、 もっとも行き違いの少ない方法だと思います。

お客様にも、この関連図を前に説明をすれば、特定の業務(プロセス)に対応するシステムを製作しなかったら、 関連する業務(プロセス)のどの部分が電子化されず、そこは人手で対応するのだということが理解いただけます。
逆に、人手のほうがコストパフォーマンスが良いという箇所が発見されることもあります。

本サンプルムービーでは、1プロセスに対応するシステムを作成するのにかかると予測される期間と金額を色で区分けしています。
1日のものは白、1週間は黄色、半月は青というように。そして業務関連図(フロー)をお客様の目の前で、話し合いながら作成し、 リスト機能を用いて、そのまま見積り原案として発行しています。
フローが発行する見積りですから、作り直す手間が殆どかかりません。

また、このフローのエレメント欄にデータを定義しておけば、業務のどの段階でどのようなデータが加えられるのかが一目瞭然で、プログラマーがDBの設計をするときの間違いリスクが低減します。

実際のツールが使われる様子をムービーで確認してください。  [→ ムービーはこちらからご覧いただけます]

BACK