基幹システム刷新を成功裏に導く
「Fit to Standard」の実践方法とは

基幹システム刷新のプロジェクトで必ずといっていいほどキーワードになるのが「Fit to Standard（F2S）」です。これは、ERPパッケージなどが提供する「標準機能」に、自社の業務プロセスを合わせていくアプローチを指します。その目的は、追加開発（アドオン）を最小限に抑えることで、品質（Quality）、価格（Cost）、納期（Delivery）という、いわゆるQCDを高いレベルで達成することにあります。

しかし、F2Sは「現場の要望を諦めさせ、システムに我慢を強いる手法だ」と誤解されることが少なくありません。これはF2Sの本質を捉えきれていない見方です。真のF2Sは「なぜその業務は標準から外れているのか？」という原因を徹底的に掘り下げ、業務そのものを変革していくアプローチにほかなりません。

例えば、特殊な請求書フォーマットを維持するためにアドオン開発を検討するのではなく、「取引先と交渉して標準フォーマットに変えられないか？」と考えるとします。それに対し、複雑な承認フローを残すのではなく、「承認ルールを見直してシンプルにできないか？」と問い直します。このように、基幹システムの外側、つまり上流の業務や取引条件、社内ルールにまで踏み込んでメスを入れることこそが、F2Sを成功させる鍵なのです。

アドオンを多用したシステムは、導入時のコストだけでなく、将来のアップグレードやメンテナンスの際にも足枷せとなります。F2Sは短期的なQCD達成だけでなく、長期的なシステムの陳腐化を防ぎ、変化に強いIT基盤を築くための「賢い選択」といえるでしょう。

F2Sを実践するうえで、ただ闇雲に業務を標準機能に当てはめようとすると、「システムは導入できたが、全く使えない」という最悪の事態を招きかねません。そうならないために、私たちはF2Sを2つの側面から捉えるべきだと考えています。それが「Fit to Process」と「Fit to Data」です。

【基幹システムの2つの側面へのアプローチ】
Fit to Process（業務プロセス改革）： 標準機能で実現できる新たな業務プロセスを構築する
Fit to Data（経営データ改革）： “動くが使えない ”を避けるため、経営判断に必要な情報を定義する

基幹システムには、日々の業務処理を支える「オペレーションシステム」としての側面と、経営層が迅速な意思決定を行うための情報を提供する「意思決定システム」としての側面があります。

「Fit to Process」は、前者のオペレーション側面に着目し、業務プロセスそのものを標準機能に合わせて再構築することを目指します。これにより、業務の効率化や標準化を実現します。
一方で、後者の意思決定側面を支えるのが「Fit to Data」です。いくら業務プロセスが効率化されても、そこから得られるデータが経営判断に活用できなければ意味がありません。「どの事業がどれだけ儲かっているのか」「製品別の収益性をリアルタイムに把握したい」といった経営ニーズに応えるためには、「経営として何を見たいか」から逆算して、必要なデータ項目やコード体系を設計する必要があります。

この2つの“Fit”は、車の両輪のようなものです。プロセスだけを追い求めれば「使えない」データが残り、データだけを追い求めればプロセスが非効率になります。両方のアプローチをバランスよく進めることが、真に価値ある基幹システム刷新につながるのです。

多くのシステム導入プロジェクトでは、要件定義のフェーズで初めてF2Sの検討が本格化します。
しかし、これが大きな落とし穴です。数か月という限られた期間の中で、現場の担当者はもちろん、他部門の利害関係者まで巻き込み、長年続けてきた業務のやり方を変える合意を取り付けるのは、至難の業といえるでしょう。「うちの業務は特殊だから」「こんな短期間で取引先との調整は無理だ」
――こうした抵抗に遭い、結局は「現行踏襲」という形でアドオン開発に逆戻りしてしまうケースが後を絶ちません。そこで私たちは、要件定義が始まる前の段階で、F2Sの検討を前倒しで実施するアプローチを推奨しています。

【要件定義の前に実施すべきこと】
業務の棚卸し： 自社業務を作業レベルで徹底的に可視化し、実態を把握する
F2P/F2D検討： 現行のアドオン機能などを対象に、標準機能で代替可能か、その場合の変革点は何かを具体的に洗い出す

【要件定義におけるFit to Standard検討の役割】
“事前検討の結果に対する「答え合わせ」と「間違い直し」の場とする”

具体的には、まず現状の業務プロセスとアドオン機能を徹底的に棚卸しします。そのうえで、一つひとつの機能が「標準機能で代替できないか」「上流システムやクラウドサービスで対応できないか」「取引条件や会計ルールを変更してシンプルにできないか」といった多角的な視点で「変革の可能性」を検証していくのです。この事前検討を丁寧に行うことで、要件定義の場はゼロから議論を始める場ではなく、事前に描いた改革シナリオの実現性を最終確認し、合意形成を行う場へと変わります。これにより、プロジェクトの手戻りを劇的に減らし、関係者の納得感を醸成しながら、スムーズに変革を推進することが可能になるのです。

F2Sがどのように業務を変えるのか、ある大手機械部品メーカーの事例で見てみましょう。この企業では、過去からの商慣習により、支払方法に応じて買掛金を細かく分割管理する必要があり、そのために複雑なアドオン開発を行っていました。

【支払条件変更と効果】
As-Is： 複雑な支払条件を守るため、アドオンで買掛金の分割処理を実装
To-Be： 取引先交渉を通じて分割条件を簡素化し、システムの標準機能（支払条件マスター）で対応
効果： アドオン開発と、それに付随する手作業を完全に廃止

この改革のポイントは、「基幹システムの中で何とかしよう」という発想を捨て、業務の大元である「取引条件」そのものにメスを入れた点です。結果として、アドオンを廃止できただけでなく、業務プロセスそのものがシンプルになり、月次の支払関連業務にかかる工数を約40%削減することに成功しました。

また、上記の事例が示すように、F2Sの本質は、単にシステム機能を当てはめることではなく、業務のあり方そのものを見直すことにあります。では、具体的にどのように進めれば、このような改革を実現できるのでしょうか。私たちは、以下の4つのステップが不可欠だと考えています。

▼Step1: 現状の徹底的な可視化
まずは、現行システムのアドオン機能や、経理部門がExcelや手作業で行っている業務をすべて棚卸しします。「なぜこの業務が必要なのか」「どれくらいの頻度と工数がかかっているのか」を客観的なデータで把握することが出発点です。

▼Step2: 変革ポイントの特定とシナリオ策定
次に、棚卸しした業務の一つひとつについて、「なぜ標準機能で対応できないのか」という原因を深掘りします。そのうえで、業務プロセス、取引条件、社内ルールなど、変革すべきポイントを特定し、複数の改革シナリオを描きます。

▼Step3: To-Beプロセスの設計と効果試算
標準機能の活用を前提に、新しい業務プロセスを具体的に設計します。この時、RPAや他クラウドサービスとの連携も視野に入れることで、実現可能性が大きく広がります。さらに、設計した新プロセスによって得られる工数削減効果などを定量的に試算し、投資対効果を明確にします。

▼Step4: 関係者との合意形成と実行計画策定
最後に、策定した改革シナリオと効果試算をもとに、経理部門だけでなく、営業や購買といった上流部門を含む関係者と丁寧に合意形成を図ります。全員の納得を得たうえで、具体的な実行計画に落とし込み、プロジェクトを推進します。

上記に示したステップは論理的ですが、いざ自社だけで実行しようとすると、多くの企業が「見えない壁」にぶつかります。「うちのやり方が一番だ」という過去の成功体験への固執、部門間の利害対立、そして何より「自社の常識」という名の思い込みです。社内の論理だけでは、客観的な判断や大胆な変革は困難を極めます。

もし、貴社が基幹システム刷新を単なる延命措置で終わらせず、「真の業務改革」につなげたいとお考えであれば、一度、外部の専門家の視点を取り入れてみてはいかがでしょうか。
我々レイヤーズ・コンサルティングでは、豊富な知見と他社事例に基づき、貴社だけでは見えなかった変革の可能性を共に探るお手伝いをさせていただきます。