私はERPプロジェクトに23年間携わってきました。ここ5年間はすべてSaaSタイプのERPプロジェクトに従事しています。SaaSタイプのERPプロジェクトを成功させるには、ERPソフトウェアの標準機能を最大限活用すること（FTS : Fit to Standard）が重要です。そして、そのためにはベンダーにも、FTSへリードしてプロジェクト品質を高める管理が求められます。
プロジェクト管理は体系化されており、具体的な事例があらゆるところで挙げられています。そこで、ここではBifコンサルティングが重点を置く、お客様自らがERPソフトウェアを使いこなせるようになることを目指した管理手法について解説します。
Bifコンサルティングが重点を置くプロジェクト品質の管理は、要求管理、リスク管理、顧客変容、この3点です。
順を追って説明します。まずは、要求管理です。ここでは、用語について少し触れます。よく混同される「要求」と「要件」をBifコンサルティングでは区別します。「要求」とは、お客様の期待やニーズ、抽象的な特性や目標を表したものを指します。一方、「要件」とは、「要求」を具体化したものです。例えば、お客様が「在庫を削減したい」と言ったら、それは「要求」であり、「では、在庫を一年以内に50%削減しましょう」というのが「要件」になります。
話を要求管理に戻します。要求管理は、起票のタイミングが非常に重要です。要求のレベルによって、早すぎても遅すぎても問題となります。具体的に言うと、要求のレベルが「ビジネス要求」であれば、プロジェクトを開始する前に起票しておく必要があります。一方、「ソリューション要求」レベルは、ERPソフトウェアのコンセプトを理解する前に起票すると、お客様が使用しているレガシーシステムの機能要求ばかり上がってしまいます。最初は「標準機能を最大限活用」と言って始まったプロジェクトが、次第に開発要件を増やしてしまうことがあります。この開発要件増大現象は、RFP（提案依頼書）に300件を超える「ソリューション要求」が含まれている場合に起きると強く感じています。このようなRFPに対して「○」の回答をしたベンダーは、それに応じる他ありません。
従いまして、Bifコンサルティングは、プロジェクト開始前にビジネスモデルのヒアリングを通じてビジネスの“今“と“これから“を理解し、3M（Man, Machine, Material）+ Method のフレームワークをもとに制約条件を捉えることを推奨します。ERPを導入したとしても、設備や原材料が変わることはありませんから、先ず、これらの制約条件の要求を捉えることが必要なのです。時間をかけて300件を超える機能要求を起票する必要はないのです。
プロジェクト開始前に起票されたこれらの要求は、プロジェクト開始時には、WBSのMoSCoWバックログフォルダーで管理します。WBSはワークマネージメントアプリケーションのWrikeで作成します。Wrikeの使い方については、ERPを初めて導入される方でも安心のプロジェクト運営をWrikeで実現をご参照下さい。
ここで少しMoSCoWの説明をしたいと思います。MoSCoWとは、要求に優先順位を付けて、要求の起票から要件定義、機能検証やテストとその結果、製品移送までをトレーサビリティするツールです。優先順位は、必須要求から順にMust、Should、Could、Won’t の４つに分類します。このMoSCoWで大事なことは、優先順位に閾値を付けるということです。Mustであれば、「プロジェクトの目的達成に必要」、「法令や税制に遵守」、「顧客の強い要望」とします。Shouldは「顧客や仕入先といった取引先からの要求」、Could は「社内で完結する要求」、Won’tは不要な要求です。優先順位に閾値を付けないと、要求が何でもMustになってしまう恐れがあるので注意して下さい。そして、受入基準（合格基準）を設けます。この基準を検証前に決めておくことで、お客様は抜け漏れのない評価ができる様になります。また、検証環境を用意するベンダーも合格基準を考慮して準備できる様になります。
次に、この要求を要件にします。要求を具体的なものにすると言うことです。例えば、業務要求の「VMI管理ができること」を「仕入先に3ヶ月先までの所要量を提示して、仕入先が在庫を切らさない様に、在庫の消化状況を確認でき、自社が使用したタイミングで発注と検収が同時に行われる」と言った具体的な要件にします。仕入先直送などの物流ネットワークに関する要求は、取引パターンや配送ルートを要件にします。プロジェクトの一つ目のフェーズである構想策定で、ビジネス要求、業務要求を要件定義して、ERPソフトウェアに合わせたソリューション要求にするのです。こうすると、ビジネス要求/要件、業務要求/要件とソリューション要求が構造化できます。また、この構造から外れる要求も管理しておきます。
フェーズ2の業務構築では、ソリューション要求をERPベンダーが標準で用意しているビジネスプロセスフローに関連付けます。関連付けられないソリューション要求は、新たにビジネスプロセスフローを追加するかの評価が必要になります。しかし、ないからと言って、すぐに追加するのは早計です。全体のビジネスプロセスモデルと追加するプロセスの関係を良く考えてから追加の可否を判断します。
ここまで準備して、ようやくERPソフトウェアを動作しての検証が始まるのですが、ここでやるべきことは、業務要件を深掘りすることです。ビジネスプロセスフローごとに業務ヒアリングします。業務を組み立てる順番で進めるとお客様がヒアリングの意味を把握しやすくなるので有効です。
業務ヒアリングは、要求管理の要ですから、少し時間を割いて説明します。
例として、安全在庫のソリューション要求を定義します。初めに、安全在庫の一般的な用途と目的を説明します。これは、お客様に、自社のやり方が、一般的なのか、独自性が強いのかを知ってもらうために行います。次に、起票されているMoSCoWの業務要件（要求を具体化し終えている）をあらためて確認し、業務ヒアリングを行います。安全在庫の対象となる品目は何か。何故安全在庫が必要なのか。どう言う時に安全在庫が使われるのか。安全在庫の種類には何があるか。サービスレベルはどれくらいにしているのか。これらに加えて、在庫過多や偏重は起きているか。安全在庫を持っても欠品が起きる時の原因は何があるか。在庫は他社と比較して多いか少ないか、など。要するに、単に今やっていることを聞いたり、安全在庫の機能の説明だけをするのではなく、原理原則に立ち返って、お客様に本質を見極めてもらうのです。お客様が変容すると言うことは、今の仕事のやり方の踏襲や延長線にしないと言うことですから、事細かく確認するのです。こうして得られた情報を元に、あらかじめ用意したソリューション要求に、具体的なパラメータやマスター項目を加えて、ソリューション要件を作成します。
こう言ったことを地道に全てのソリューション要件ができるまで繰り返します。ビジネスデータモデルも同様ですが、それは別の機会にお伝えします。
要求管理が、正しく進めばプロジェクトの品質は高まります。一方で、要求管理が上手くいかない場合をリスクとして、リスク管理に特定してコンティンジェンシープランを用意します。これは使わないで済ませたいところですが、要求管理が想定通りに行かないことが、少なからず起きます。次回は、そのリスク管理についてお伝えします。