２つの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、そしてMoSCoW
ここで必要になるのが、要求を評価する軸です。構想策定の中で、業務要求レベルでAs-IsとTo-Beの差分からBPRの方向性を定め、その変化を何で測るのかをKPIとして置いておく。そこまでできていれば、要求は「昔からあるから必要」ではなく、「このBPRに資するのか」「このKPIに寄与するのか」で見られるようになります。議論が揺れても、立ち返る場所が明確になります。
さらに、優先順位を属人的にしないためには、MoSCoWで閾値を置くことも重要です。
要するに、As-Is要求への対処は、後から削ることではなく、先に評価軸を置くことです。BPRとKPIが要求の向きを定め、MoSCoWの閾値が要求の重みを整える。この二つが揃って、要求を場当たり的に減らすのではなく、最初から膨らみにくくする仕組みにしておくのです。
SaaS ERPの価値を活かせるかどうかは、ここで分かれる
SaaS ERPの価値は、標準機能を土台にしながら、変化に対応して業務を進化させ続けられることにあります。だからこそ、導入の出発点が現行業務の再現に傾くと、その価値は十分に活きません。SaaS ERPを選びながら、進め方はオンプレミス時代の延長になってしまうからです。
まとめ
Fit to StandardとFit to the Systemは、似た言葉でも、プロジェクトを導く方向が違います。前者は業務を整え、標準を活かせる状態をつくっていく進め方です。後者は現行業務の再現を起点にしやすく、結果としてプロジェクトを苦しくしやすくなります。
途中でAs-Is要求が膨らみ、「やはりシステムに合わせるのは苦しい」という空気が出てくるのも、その流れの中で起きています。問題は標準化そのものより、目指しているつもりの方向と、実際の進め方がずれていることにあります。
そのズレに構想策定の段階で気づけるかどうか。そこが、プロジェクトの分岐点になるのだと思います。
