ユーザ企業の業務担当者は、日本企業特有のドキュメントが無い業務引き継ぎによって、「業務が分からない、全部は分からない」という状態です。

1.ユーザ企業がIT要求を定義できない

  こんな状況で、IT企業がRFPへ提案書を出して受注、RFPどうりシステム開発を行っても、テスト直前に別の業務担当者が現れ、「これでは業務が回らない!」とテストへ参加してくれない。IT企業はやむなく、そのIT要求を追加開発して何とか本稼働を迎える。

  こんなことでは、IT企業は利益が出るどころか、泥沼の大赤字のプロジェクトで他の利益を全て消し去ってしまいます。IT企業の当該事業部門の責任者は社内追究されて「もう絶対に赤字を出しません」と言うしかありません。しかし、他の事業部門でまた、大赤字プロジャクトが出てきてしまいます。根本原因は、日本企業にほとんどに共通している「業務ドキュメントがない」からであり、当然にIT要求がモレる訳です。 

  こうした状況下で、IT企業のプロジェクトマネジメント力を強化してもダメ。PMBOKをいくら勉強してもダメ。では、どうすればいいのでしょうか? 

  私がIT企業に在籍した時には、対象業務に強い人間を提案だけでなく、受注直後のシステム分析、その前工程のIT要求の確認&分析のところへ投入。IT要求が確認できれば、後工程のITソリューションごとの分析は簡単だからです。ところが、IT企業はITソリューション別に組織編制しています。これが大間違いですが、業務に強い人材は薄い。

2.IT企業の自衛策としての ⑤D.標準ITシステム機能  

  この状況「対象業務に強い人間」の代わりとして、こんな業務プロセスならば、通常はこんなITシステム機能が要求されるというナレッジ「⑤D.標準ITシステム機能」を開発し、提供を始めました。

  業務プロセス自体は業務参照モデルに内蔵されたものですので、IT要求のチェックリストとして「⑤D.標準ITシステム機能」を大きく整備しました。⇒M800-150  

  現在の対象業務は、サプライチェーンの計画、調達、製造、受注・出荷、返品、およびこれらへの支援機能です。

  これには、私がユーザ企業をコンサル支援した事例があります。上記のチェックリストは未開発でしたので、私が業務プロセス定義を見ながら私の頭の中で、こんなプロセスならばこういうIT要求があるのではと仮説コンサルしたものです。⇒事例4-2追加 開発期間1.5年のプロジェクトが、オンタイム稼働、予算増額なし。

  お問い合わせ⇒ info@process-design-eng.com

      「そんな事をしたら、IT要求スコープが増大してしまう」。

  ITシステム分析の段階で重要なIT要求を洗い出して、もしユーザの予算増額が難しければ、それよりも優先順位が低いIT要求を外してもらうのです。それ位の交渉はして下さい。ITでご飯を食べているなら。私の現役の時には、開発SEを引き揚げたことがありましたが、そんな度胸がないならITシステム分析段階で未然に防止するしかありません。