２つのFTS、Fit to Standard とFit to the System
「実は、そのアプローチ、Fit to the Systemになっています。」
昨今、ERPを導入するほとんどのプロジェクトが「Fit to Standardでシステム導入する」「業務をシステムに合わせる」との号令のもと、プロジェクトが開始されますが、よくよく考えてみると、それは「Fit to the System」であることが多くあります。
「Fit to Standard」とは、決して業務をシステムに合わせるということではなく、業務を標準化する中で断捨離していくことです。標準機能を土台にしながら、ゼロベースで業務を見直し、判断基準と業務ルールを定め、シンプルで変化に強い業務をつくっていく。その結果として、業務は自ずと新しいシステムに合うようになります。
今回の投稿では、先に述べた二つのFTSの違い、特に Fit to the Systemとなる失敗が、ERP選定後ではなく、その前段階ですでに始まっていることに焦点を当てていきます。
同じFTSという言葉でも、発想の起点が違う
Fit to StandardとFit to the Systemは、言葉だけを見るとよく似ています。どちらも標準に寄せていくように聞こえるからです。けれども、実際のプロジェクトでは起点が大きく異なります。
Fit to Standardが起点に置くのは、これからどんな業務にしていきたいのか、という問いです。標準機能を前提に、業務の流れを整え、不要な手順を減らし、揃えるべきルールを揃えていく。そうやって業務の形を洗練していく中で、システムとの整合が取れていきます。
一方のFit to the Systemが起点に置くのは、今ある業務や要求をできるだけ残しながら、新しいERPの中にどう収めるかという発想です。すると議論の中心は、業務をどう変えるかではなく、現行をどこまで再現できるかへ寄っていきます。
この違いは大きいです。
前者は業務を洗練するアプローチであり、後者は現行業務を延命するアプローチです。
なぜ多くのプロジェクトが取り違えるのか
ここで厄介なのは、当事者が最初からFit to the Systemを目指しているつもりはないことです。むしろ多くのチームは、自分たちはFit to Standardで進めていると思っています。だからこそ問題が見えにくくなるのです。
その誤認が生まれるきっかけの一つが、「業務をシステムに合わせる」という言い方です。この表現はわかりやすい反面、中身が曖昧なまま使われると危うい方向へ進みます。
本来ここで問うべきなのは、標準機能を前提に業務構造を見直し、不要な手順や属人的な判断を減らせるかどうかです。 ところが現場では、「今の業務は残したまま、新しい画面操作に慣れてもらうこと」と受け取られがちです。そうなると、標準化の議論が順応の議論にすり替わります。
この言葉のズレが、Fit to Standardと言いながら、実態はFit to the Systemに近づいていく入口になります。
問題はERP選定後ではなく、もっと前から始まっている
こうした取り違えは、ERP選定のもっと手前、構想策定の段階ですでに始まっています。
構想策定では、まずTo-Beを起点に、何を実現したいのか、どんな業務に変えていくのかを整理し、制約条件を踏まえながら要求へ具体化していく必要があります。こうしてはじめて、議論は「できるか、できないか」ではなく、「やるべきか、やらないべきか」で整理できます。
ところが実際には、現行業務の棚卸しから入ることが少なくありません。今のシステムで何をしているのか、何が足りなくなると困るのか、どの帳票を残したいのか。こうした話から始まると、評価の視点は自然にAs-Is寄りになります。すると、新しいERPをどう活かすかではなく、現行をどこまで再現できるかがテーマになっていきます。
その結果、プロジェクトはかなり早い段階からFit to the System側へ傾き始めます。しかも、その場では「丁寧に現場を見ている」「自分たち（現場）のことをよく理解している」「現実的に進めている」と映ることが多いため、問題として認識されにくいのです。
As-Is要求が噴き出すのは自然なことです
この状態になると、プロジェクトの途中でAs-Is要求が次々に出てきます。これは自然な流れです。現場は自分たちの仕事を守ろうとしますし、見慣れた帳票や処理、例外対応を手放すことにも不安があります。構想策定の段階でAs-Isを起点に話していれば、現場は「今の業務を前提に差分を埋めてくれる」と受け取ります。
その結果、要求は「今までやっていた」「現場が困る」「念のため欲しい」といった言葉で積み上がっていきます。こうなると、後から要求を削るだけでは収まりません。問題は、要求の量ではなく、要求を評価する軸が置かれていないことにあります。
原点回帰のためのBPRとKPI
その軸になるのが、BPRの方針とKPIです。構想策定の中で、As-IsとTo-Beの差分からBPRの方向性を定め、その変化を何で測るのかをKPIとして置いておく。そこまでできていれば、要求は「昔からあるから必要」ではなく、「このBPRに資するか」「このKPIに寄与するか」で見られるようになります。議論が発散しても、原点に戻りやすくなります。
逆に、この原点がないまま要求だけが積み上がると、後になって「このERPは足りない」「やはりシステムに合わせるのは苦しい」という空気が強くなります。そのとき苦しくなっているのは、標準化そのものよりも、現行業務を温存したままパッケージに収めようとする進め方の方です。
SaaS ERPの価値を活かせるかどうかは、ここで分かれる
SaaS ERPの価値は、標準機能を土台にしながら、変化に対応して業務を進化させ続けられることにあります。だからこそ、導入の出発点が現行業務の再現に傾くと、その価値は十分に活きません。SaaS ERPを選びながら、進め方はオンプレミス時代の延長になってしまうからです。
まとめ
Fit to StandardとFit to the Systemは、似た言葉でも、プロジェクトを導く方向が違います。前者は業務を整え、標準を活かせる状態をつくっていく進め方です。後者は現行業務の再現を起点にしやすく、結果としてプロジェクトを苦しくしやすくなります。
途中でAs-Is要求が膨らみ、「やはりシステムに合わせるのは苦しい」という空気が出てくるのも、その流れの中で起きています。問題は標準化そのものより、目指しているつもりの方向と、実際の進め方がずれていることにあります。
そのズレに構想策定の段階で気づけるかどうか。そこが、プロジェクトの分岐点になるのだと思います。
