FTS（Fit to Standard : 標準機能活用）を実現するための手法「要求ずらし」

SaaSタイプのERP導入にはFTS（Fit to Standard）アプローチを採用すべきです。それはSaaSがビジネス環境の変化に柔軟に対応するためのものであり、カスタマイズするとその分SaaSの恩恵を受けられなくなるからです。実際にERP導入てはプロジェクト方針として、「業務をシステムに合わせる」と言った方針が挙げられます。しかし、現実はどうでしょうか。ほとんどのプロジェクトがそのお題目だけで、多くのカスタマイズを施すことになっているのではないでしょうか。オンプレミスやシングルテナントならそれでも良いでしょう。しかし、高い頻度でアップデートするマルチテナントのSaaS ERPではそういうわけにはいきません。

そもそも、なぜカスタマイズが増えるのでしょうか。その代表的な原因をいくつか考えてみました。

最も多い原因は、要求管理にあります。ユーザーがまだERPのコンセプトを分からないうちに、機能要求をあげてしまう。「新しいシステムを導入するので要望を上げて下さい」と言われるとユーザーはどうしても今できることはこれからもできる様にしてほしいので、現状維持バイアスの強い要求が時には500件を超えて上がることもあります。現行のシステムとERPがマッチすることは皆無であり、この進め方が、ユーザーの変革意識の妨げになりカスタマイズを誘発するのです。

次に多いのは、導入ベンダーがカスタマイズを必要と判断してしまうことでしょう。業務および現行システムの調査で確認したことをそのまま要求としてしまうのです。これはERPの機能をよく理解していないか、あるいはERP導入を何度も経験しているが、その経験の中で、以前開発したから今回も開発すると結論付ける、開発を強みにしているベンダーに多く見受けられます。

他には、部門を横断して要求事項を精査できないことや、既存のシステムを多く残して、インターフェース開発で対応することも挙げられます。

中には、他システムとERPで在庫更新などの処理タイミングのズレが難易度の高いカスタマイズの発生原因になることもあります。

この記事では、これらの発生を未然に防ぐ手法を６つ紹介します。

最初に取り掛かる手法は、「ビジネス要求を踏まえたビジネスプロセスモデル定義」です。これは当たり前のことではありますが、この基本をしっかりとおさえなければなりません。新たな市場への展開（What, Where）、プロセスの最適化（How）やビジネス価値の最大化（Why）と言ったビジネス要求レベルと、ものの流れ、および在庫ポイントと言ったビジネスプロセスモデルを定義してERPにコンフィグレーションします。

次は、「取引パターンの網羅性」です。機能要求の様な“点”で捉えてしまうと、この網羅性が欠落します。これが後になって大幅なコンフィグレーションの変更を起こすこともあります。取引パターンを網羅するということは、先のビジネスプロセスモデルで上がった仕入先、倉庫、工場、配送センター、出荷先などをマトリックス化してこれらの組み合わせで発生するものの流れをおさえるということです。それと、受注生産、見込生産と言った生産形態を組み合わせて整理します。この取引パターンであれば、現行のプロセスに依存することなく、新しいプロセスを再定義できます。

３つ目に、ようやく業務ヒアリングになるのですが、ここではトリガーイベントアプローチを採用します。ERPの機能を最大限活用するためには、業務が発生するトリガーは何かを把握する必要があります。外部イベントであれば、顧客からの注文が何をトリガーとしているのか、内部イベントであれば、製造で仕損をどの様に発見しているのか、定期イベントであれば棚卸はどのサイクルで行われるのかなどです。プロセスの起点となるトリガーをおさえることで、業務の抜け漏れをなくすだけでなく、業務をゼロペースで再構築しやすくなるメリットがあります。

4つ目は、Man, Machine, Material の3M+Methodの制約条件です。ERPを導入して業務を変革すると言っても、設備や原材料が変わるわけではありません。従って、この3M+Methodは制約条件として優先度の高い要求事項となるのです。例えば、タンクの最大在庫量、設備の日産量やHACCP対応などです。

5つ目は、これまで確認する中で上がった要求事項をMoSCoWに起票することです。MoSCoWについては「SaaSタイプのERPにおけるプロジェクト品質-要求管理編-」で詳しく説明していますので、そちらを参照して下さい。このMoSCoWで大事なことは、ユーザーから挙げられた要求事項の優先順位とは別にMoSCoWの優先順位を取るということです。MoSCoWの優先順位は法令遵守、顧客の強い要望や社外取引、社内完結と言った客観的に決められる閾値となっていますので、これとユーザーの優先順位を組み合わせて分析します。組み合わせることで、その傾向がわかります。例えば、ユーザーの優先順位に“高”が80%あるが、そのほとんどが社内完結の機能要求だとすると、ユーザーが挙げられた要求は必須だけれども、それに代わる機能があれば良いということがわかります。要求事項に「この要求がないことによるビジネスインパクト」も挙げます。それがカスタマイズ可否の尺度となるでしょう。

最後は、ECRSです。これはよく業務改善に使われる手法ですが、ERP導入で要求を精査するのにこの手法はベストマッチなのです。使い方は次の通りです。先ず現状の帳票を全て洗い出します。帳票には、IT部門が管理していない現場で作成したExcelシートなども含めます。これら帳票の一覧を実機検証の開始前までにE（排除:Eliminate ）できるか、複数事業での導入であれば、事業ごとに同じ様な帳票をC（結合:Combine ）できるか、などの評価を終えておきます。その上で、ERPの実機検証でERPの標準機能にR（Rearrange:交換）できるかを判断します。ここまでで現行帳票の80%は削除やペーパーレス化されます。最後にどうしてもカスタマイズの必要な帳票はS（Simplify:簡素化）するのですが、それを即決するのではなく、それがMoSCoWのMust（法令遵守や顧客の強い要望）なのかを再確認します。この様に、極限までカスタマイズしない仕組みでプロジェクトを運営するのです。

タイトルに「要求ずらし」と書いたのは、ERP選定の段階で上がった要求事項のほとんどが現行システムの機能要求であるため、それらの要求を前述した手法を用いて、ERPの標準機能へ“ずらす”必要があるためです。

もちろん、FTSを実現するためには、ユーザーの変革意識が一番重要です。しかし、それだけでは総論賛成各論反対になってしまいます。そのため、ここで紹介した手法を用いて、ユーザーが納得できるように導いていく必要があるのです。

次回は、ユーザーがERPの習熟度を高める管理手法として「ERPの習熟度管理「ILUO」」を紹介します。FTSを実現するには、今回紹介した手法に加えて、ユーザーがERPを早期に習熟し、慣れていただくことが重要なのです。