SaaSやパッケージシステムの導入において、システムをユーザ企業の現状の業務に合わせてカスタマイズするのではなく、業務プロセスやデータの持ち方などもを導入するシステムのほうに合わせる"Fit to Standard"という考え方があります。

ITコンサルと事業会社で「Fit to Standardで行きましょう！」と言う側と言われる側の両方を経験することでこの言葉の本当の意味、なぜ難しいのか、どうしたら成功するかが見えてきたので、共有します。

業務プロセスにおけるプロセス成熟度とシステム統合度

Fit to Standardという言葉の解像度を上げるために、まず「プロセス成熟度」「システム統合度」という２つの言葉を導入します。

プロセス成熟度

プロセス成熟度は、その業務プロセスがどの程度システムに組み込みやすい状態になっているかを表します。

プロセス成熟度が低い状態は、分岐や例外が多く複雑です。それゆえルールや手順を厳格化するのが難しく、曖昧で属人的になっていることが多いです。総じて運用負荷が高い傾向にあります。一方で、従業員やサービスを受ける側の目線では親切、柔軟です。

プロセス成熟度が高い状態は、シンプルで、ルールや手順が厳密に定められています。属人性は排除され、業務委託などに業務を委託するのも容易です。一方で、従業員やサービスを受ける側の目線では冷たい、お役所的です。

業務プロセスの運用開始当初や組織・会社規模が小さいうちは、柔軟性や変化の余地を残すため、プロセス成熟度は低くて構いません。しかし組織・企業の規模が大きくなるにつれ、運用負荷に耐え切れず曖昧性・柔軟性を排除し、ルールや手順を厳格化し、成熟度を上げていく必要が出てきます。

システム統合度

システム統合度は、その業務プロセスがどの程度システム上で実現されているかです。

システム統合度が低い状態では、業務データがExcelやスプレッドシートで管理され、やり取りはメールやチャットで非定型なフォーマットで行われています。ファイル単位など権限制御の単位が粗く不正や改ざんの防止がしづらいため性善説で運用されています。

システム統合度が高い状態では、業務データはデータベースで管理され、専用のシステム経由でしか閲覧、更新、削除ができません。フォーム経由の定型の入力しか受け付けず、細かな権限制御の元性悪説で不正や改ざんを防止しています。

システム統合度が低いままだと、データが活用できない状態でバラバラに管理されていたり、利用者のリテラシーに依存した運用になってしまいます。

Fit to Standardとは何か

「業務をシステム化する」ためには、プロセス成熟度とシステム統合度の両方を上げる必要があります。

基本的なアプローチは業務プロセス見直し(BPR) → システム導入

そのための基本的・古典的なアプローチは、業務プロセス見直し(BPR)を行い、その上でシステムを導入することです。

しかし、このアプローチは非常に難しいです。特に、BPRの段階でプロセス成熟度を十分に高めることができないケースが多いです。

業務プロセスの改善(BPR)でプロセス成熟度を十分に高められない理由

その理由は次の通りです。

1. 自分たちの業務プロセスが優れていると思っている
   自分たちが運用の中で磨き上げたプロセスが非効率・イケてないと思っている人はあまりいません。非効率だと思いながら日々の業務を行っていると、認知的不協和でストレスが溜まってしまいますから、徐々に「今がベストなんだ」と思うようになります。

2. 業務を変えたくない
   既に慣れ親しんでいて、労力をかけずにこなせる業務プロセスをあえて変更したいと思う人は少ないでしょう。それが、自分たちが優れていると思っているものならなおさらです。

3. あるべき状態が分からない
   業務プロセス改善では、今の業務プロセスの問題点や、理想の業務プロセスとのギャップを洗い出し、改善していきますが、事業会社の目線だと、現行業務が強力なアンカーになるため、ゼロベースであるべき状態を考えるのはとても難しいです。

4. 業務プロセス同士が複雑に絡み合っていて、一つを変更したときの影響調査が大変
   これは、私自身コンサルから事業会社にきて気が付きましたが、一見単純な業務プロセスでも、実はその前後左右には他の業務プロセスがあり、ある業務で使っているスプレッドシートが別のスプレッドシートから参照されていたりと、一つを変更したときの影響調査は骨が折れます。

なお、これに対しITコンサル/SIerは、より効率的な業務プロセスの企業を見てきていたり、得られる情報が限定的で複雑性を過小評価しがちなので、事業会社の人たちを変化を嫌う愚かな人種だと思っていたりします。

Fit to Standardという銀の弾丸（？）

Fit to Standardは、導入する製品の標準のデータモデル、業務プロセスに合わせて現行業務を変更することで、プロセス成熟度とシステム統合度を一気に高めてしまおうという考え方です。

ITコンサル/SIerにとって、Fit to Standardは非常に都合が良いです。その理由は次の通りです。

1. リスクを減らせる
   SaaS/パッケージには機能の制約があり、導入ベンダとはいえ詳細な仕様を知り尽くしている人はまずいません。そのため、システムを業務に合わせてカスタマイズするアプローチでは、要件定義で受け入れたものの、いざ設計・開発をする段階で製品の細かい制約により要件が物理的に実現不可能であることが分かるといったリスクがあります。
   一方、Fit to Standardでは物理的に実現できない要求は代替案で回避したり、業務プロセス整理で標準に合わせるのに想定外に苦労して遅延したときの原因をクライアント（事業会社）に転嫁できるというメリットがあります。

2. 相手の得意領域（事業会社の現行業務）ではなく、自分たちの得意力域（製品標準）で戦える
   BPRを行うためには、対象業務のドメイン知識やコンサルティング能力（ヒアリング力、課題抽出力、業務整理能力など）が必要になります。一方、Fit to Standardでは、製品標準の業務プロセスを説明して「これに合わせて下さい」というスタンスをとれるため主導権を握りやすく、プロジェクトが進めやすいです。さらに、現行業務を起点としたBPRよりも難易度が低いため、新卒一括採用した1年目にも仕事を任せ易く、育成にも利用できます。

Fit to Standardは難しい

ITコンサル/SIerにとって都合のよいFit to Standardですが、BPR→システム導入のアプローチに対して、Fit to Standardは業務が一気に大きく変更されるため、現場の反発や一時的な非効率が起こりやすいくハイリスクハイリターンなアプローチです。経験上、失敗の原因となりやすいのは次の2点です。

「現行業務に詳しい人」と「Standard(製品標準)に詳しい人」が対立する

製品標準の業務プロセスを説明して「これに合わせて下さい」というだけでも仕事として形にはなるものの、きちんと成功させるためには、現行業務とStandard(製品標準)への深い理解をもとにした業務改善や現場への説明が必要になります。

しかし、技術者がITベンダ側に偏在しているというIT業界構造と、解雇しづらいパートナーシップ型の雇用慣行という日本のIT業界の性質（参考）から、「現行業務に詳しい事業会社の社員」と「Standard(製品標準)に詳しい外部ベンダ」の利害が完全に一致せず、対立構造が生まれてしまうことも珍しくありません。

例えばSAPを導入する場合、SAPに詳しい人を社員として雇い利害の対立がない状態で導入を進め、導入が完了したら解雇するという進め方ができるジョブ型雇用の欧米企業と違い、日本ならではの難しさと言えるかもしれません。

トップダウンによる推進が理想だが、ガス欠になりやすい

業務を一気に大きく変えるFit to Standardの実現にはトップダウンでのプロジェクト推進が必要不可欠です。

しかし、Fit to Standardがうたわれる社内システムの導入は、会社にとってはあくまでコスト削減（ボトムライン向上施策）であることが多く、売り上げ向上（トップライン向上施策）に対し優先度が低いため、トップ（役員、マネジメントレベル）の興味が途中で尽きたり、より他の業務が優先されることがあります。

こうなると、トップダウンでの推進力が弱まり、「Standard(製品標準)に詳しい外部ベンダ」に対してお客さんである「現行業務に詳しい事業会社の社員」が強くなり、思ったように業務整理が進まない、ということが起こりやすいです。

まとめ

人もプロセスも凝り固まってしまった業務プロセスを一気に変革するために、Fit to standardという印籠・号令は一定の効果があると思います。

Fit to Standardをきちんと成功させるためには、大きな改革をトップダウンで断行する覚悟と、「現行業務に詳しい人」と「Standard(製品標準)に詳しい人）」が同じ方向を向けるように戦略的にチームを編成する必要があります。

以上です。