業務とシステム

「金は払ったんだから、お前たちでやってくれ。」システム開発の現場でよく聞きますよね。
私の場合はSoftwarPackegeを売ってましたから、「買ったのだから、あとはよろしく」と言う感じでしょうか。
当たり前のことなんですが、業務（仕事）のことはお客様しか知らないわけですよね。IT業者だから何でも知ってると言うわけはありません。

何故、こんなことが起きるのか？それは、営業プロセスの中で決まってしまった思い込みなのです。
営業は、パッケージにせよ、プロジェクトにせよ、売れれば良いわけですから、大変な思いをする導入プロジェクトの話なんかしません。（中には超優秀な営業がいて開発はもとより保守のことまで考えて提案します。当然プロジェクトで問題は発生しません。）お客様が心配して相談すると、パートナー企業を紹介して終わりです。（丸投げという得意技です）

お客様がシステムのことを覚えるのと、IT業者がお客様の仕事を覚えるのとどちらが早いかを考えれば、当然のごとく、お客様が考えて、エンジニアが実現してゆくのが理想です。それも、ただ人数を集めればよいと言うわけではありません。決定権を持った人がお客様側にいないとだめです。

今回のプロジェクト体制は、お客様が怒り出す前、「お前たちの製品の全機能を説明しろ。そうしたら
自分たちでやってやる。」という体制でした。システム子会社の若手社員に、これまた質問をうけたら
答えるとう自社のコンサルタントの待ちの姿勢が相乗効果をおこして、ぜんぜん進まない状態でした。

だから、予算はあまる、何もできない、どうしたら良いのか分からないの３重奏になってしまっていたのです。人数も多すぎました。

ですから、私たちは、先ずお客さんの業務ごとのキーマンを決めていただく、この方はプロジェクト開発のあとで、自部署に使い方を教えるというミッションも持ちます。その上でこちらのベテランを書くモジュールごとに用意する提案をしました。分かりにくいと思うのですが、ペアを組むのではありません。
こちらのコンサルタントが、全業務担当者の相手をするのです。これは、課長は喜ぶ資料ができても
営業現場が、回らなくなるようなことを防ぐためであり、完全にインテグレートされたパッケージを適用する際の効果的な方法です。

とにかく、提案は受け入れられ、先行していた工場のプロジェクトに適用しました。
何とか形になったところ、思いもよらない問題が、自社内で発生しました。
これは、ドイツとの問題でもあり、次回触れようと思います。