第８回　プロジェクト推進時のよくある課題「Phase2 RFP策定」

前回（第７回）のコラムでは、基幹システム再構築プロジェクトの『Phase1実態把握』推進時のよくある課題についての話した。今回は、『Phase2 RFP策定』推進時のよくある課題について語る。

　『Phase2 RFP策定』は、システム再構築後に目指すありたい業務（To-Be）プロセスを基本設計し、そのプロセスを実現するために必要なシステム機能を整理し、システムベンダーへの提案依頼書（RFP）の策定を行うフェーズである。

推進上の課題①：現状と変わらないTo-Beプロセス設計

せっかく大きく資金を投資し、プロジェクト工数をかけて基幹システム再構築プロジェクトを推進しているのにも関わらず、現行の業務手順を踏襲した現状の困りごとを改善したレベルのTo-Beプロセスに停留し、システムの単なる置き換え・小改善レベルに留まるといった課題である。

この要因として、To-Be設計を行う際に現状にしか目が向いておらず、現状の問題を解決する「問題解決アプローチ」の発想のみになっていることが大きい。「問題解決アプローチ」だけでなく、「本来ありたい業務のすがたは何か」「会社・事業の中長期的戦略・方針を実現する業務のすがたは何か」をゼロベースで考える「デザインアプローチ」の発想も必要である。

「デザインアプローチ」を行うためにも、To-Beプロセス設計を行う前に「To-Beコンセプト」を設計するとよい。「To-Beコンセプト」は、基幹システム再構築にてどういうことを目指すのが基本方針、改革方向性を示したものである。メンバー全員が目指す改革方向性を共通認識できるとともに、現状ベースの発想になってしまった際に、立ち戻る先にもなる。

推進上の課題②：システム機能要求が膨らみすぎる

現場からの新システムに求める機能の要件が膨らみ過ぎて、パッケージのカスタマイズが多くなり、システム費用の高騰が想定されるといった課題である。

機能要件が膨らまないようにするためには、To-Beプロセス検討時に、第５回コラムのコラムでも述べた「Fit To Standard」の発想が必要となる。

 ただ、現場部門のメンバーは、そもそもパッケージ標準機能を理解していないことが多いため、To-Beプロセス検討を行う前に、一般的なシステムパッケージが持っている機能の紹介をうける機会を設けると良い。

そのような機会を設定しない場合でも、To-Beプロセス検討に情報システム担当者等、パッケージ標準機能を理解している担当者が参加し、システム要件が標準機能の範囲内か範囲外かを切り分けてあげる必要がある。そのうえで、標準機能でできない要件については、標準機能を使って業務を行う方法が無いか、他に回避策がないか、必須な要件なのかを確認することが重要である。

現実的にはそのように検討を行っても整理した機能要求がある程度膨らんでいることも多い。そのため、最終的には、要求するシステム機能の優先度を設定しておき、ベンダー提案のシステム費用も踏まえて最終的に実装するかどうか判断することになる。

次回は、『Phase3 ベンダー選定』におけるプロジェクト推進時のよくある課題についての発信を予定している。