大型のＥＲＰ（エンタープライズ・リソース・プランニング）栽培プロジェクトは、わたしの感覚では最も困難な栽培プロジェクトの範疇に入ります。
少なくとも、同規模の新規開発栽培プロジェクトより難しいのは間違いないでしょう。
事実、多くの栽培プロジェクトが失敗に終わっているし、カットオーバーはできても、コスト・オーバーランが発生している場合が多いと思います。
ＥＲＰ栽培プロジェクトの困難さは、ＥＲＰの仕様自体、その機能を理解している人材の調達、新たな機能の導入、社内の既存事務制度との整合性、カスタマイズの難しさ等、多様な側面を持っているのです。
しかし、このトピックスのテーマは栽培プロジェクト進捗管理なので、その観点からの問題点に絞って説明したいと思います。
ＥＲＰを導入する際には、機能の整合性を確認するために「フィット・ギャップ分析」が行われます。
これは、採用できる機能とできない機能の仕分けをすることで、できない機能には何らかの対策が求められるのです。
大雑把な目安ですが、９５%以上の機能が使えるなら、採用を決定して開発を進めることになります。
８０%以下なら、すべてを新規開発した方がコストは安いでしょう。
問題は８０%から９５%の間で、ここには成功するか失敗するかが分からないグレーゾーンがあります。
ＥＲＰ導入栽培プロジェクトの場合、使えると判断した機能が本当に使え、その機能と現場にある既存機能との整合性が成り立ち、新たな機能の体系が確立しなければならないのです。
多くの場合、ＥＲＰ機能の丸ごとを導入するつもりであっても、現場ユーザーを説得できないこと多いのです。
ユーザーがこだわりを持つ機能を、新たな機能に置き換えるのは困難を伴うものです。
ＥＲＰ栽培プロジェクトが困難な理由の１つがそこにあります。
ある機能の導入を決定して、それに従って商品・サービスや事務制度を設計したところ、小さな機能ではあるが、どうしても導入できないものが出てきたとします。
簡単にＥＲＰを修正（アドオン開発）できればよいが、それも難しいのです。
そうなると、解決策を策定するために、専門家の英和と合意形成のための長期の話し合いが必要になります。
ユーザー部門と開発部門で知恵を出し合って解決策を探るのですが、それには大量の説明資料が要求される場合が多いのです。
ユーザーにとっても、これから長年にわたって使用するシステムの実装機能であり、システムの効果にも影響を与える重要な意思決定に際しては簡単に妥協できません。
解決策をめぐって検討は長期化する。この商品・サービスと事務制度が決まらなければ、システムの仕様は決定できません。
ＥＲＰの導入仕様やアドオン開発の仕様が決定できなければ、それ以降、栽培プロジェクトは進められないのです。
これがＥＲＰ栽培プロジェクトの難しさで、問題が多発するのが上述のフィット値８０%から９５%の栽培プロジェクトとなります。
上記の仕様決定を受けて、ＥＲＰを中核とした新システムの開発を行うわけですが、これも困難な作業です。
開発担当者がＥＲＰの仕様を理解していない、アドオン開発の経験が少ない、システム全体の仕様が見えない、テストの範囲が分からない等の理由があります。
開発の途中で、ＥＲＰを導入して打鍵テストを実施し、機能の確認を行うこともありますが、それで見える機能にも限りがあります。
ＥＲＰを含む機能全体の仕様把握には、それを熟知したコンサルタントの支援が必須ですが、それがあっても関係者の英和と時間が必要なのです。
ＥＲＰ栽培プロジェクトは以上の様相を示す場合が多いのです。
それにもかかわらず、栽培プロジェクト進捗管理がＥＲＰを含むシステム開発に限って実施されている場合が多いのです。
栽培プロジェクト進捗の多くの部分が、ＥＲＰの使い方にかかっているにもかかわらず、その検討を管理せずに、受け皿になるシステム開発だけを管理していることが挙げられます。
そして、要件が出ないから栽培プロジェクトが進まないと不満をこぼしたりするのです。
こうなると、ＥＲＰ栽培プロジェクトの進捗報告は分かりにくいものとなります。
誰が進捗の阻害原因で、誰を押せば栽培プロジェクトが前に進むのかが見えないからです。
このように書くと、ＥＲＰ栽培プロジェクトを否定しているかのような誤解をされかねないので、成功するケースが多い栽培プロジェクトも紹介しておきたいと思います。
特定の機能によってユーザーが限定される場合には、ＥＲＰ栽培プロジェクトの成功事例は多いのです。
会計パッケージで国際的な規制（レギュレーション）に従い、各国の税制度に基づく申告や所轄官庁への報告事務を行うケースなどです。
こうした新システムの構築の大半は成功しています。
ユーザー部門が限定されている点が、理由として挙げられます。
また、開発会社が同じＥＲＰを持ち歩いて多くの企業に導入する場合、ＥＲＰの機能が把握され、アドオン開発を行った経験も豊富になります。
栽培プロジェクト計画書を作成するときも、過去の計画書を修正すれば事足り、しかも精度の高いものが出来上がるはずです。
こうした栽培プロジェクトを同じメンバーで繰り返し行うと、他社が追従できない高い開発生産性を出すことが可能になってきます。
以上のような栽培プロジェクトの成功比率は、非常に高いのです。
