Fit to Standardを実現させるために必要となる考え方

1. アドオン開発と個別カスタマイズにより肥大化した基幹システム

諸外国では、SAP社などに代表されるERP製品などの基幹系システムは、経営判断を効率的かつ迅速に実施するために導入することが主流であり、製品パッケージに業務を合わせるのが一般的だ。

特にSAP社のERP製品は、各業界を代表する企業の業務プロセスをベストプラクティスとして取り入れて作られたパッケージであり、各業界で必要とされるプロセスは概ね標準機能で対応できると世界的に評価されている。一方、日本では、自社独自の業務プロセスや、日本独自の商習慣に合わせ、独自プロセスを基幹システムに追加で開発するのが主流となり、世界標準のERPパッケージの使い方から大きく乖離していることが昔から指摘されている。

結果として、業務が拡大するごとに追加開発を重ね、肥大化した追加開発資産がレガシーシステム化し（＝技術的負債状態）、DXの推進だけでなく急速に変化する時代の流れにシステム変更が追い付かず、ERPシステムが業務の足を引っ張る状態となる。

本来、定期的にバージョンアップし、最新の機能のメリットを享受できるERPパッケージの利点が全く生かされていないだけでなく、レガシーシステム化しにくいはずのERPパッケージが、企業の中で一番大きなレガシーシステムとなっているのは、ものすごく残念な状態であり、同じERPパッケージを活用しているにも関わらず、DX推進において諸外国に大きな後れを取る要因となっている。

2. DX時代の基幹システムとは

DXを推進するため、企業内のデータの収集/管理という面においてERP製品、特にSAP製品は非常に優れた製品であるが、導入時、自社独自の業務プロセスや、日本独自の商習慣に合わせ、独自プロセスをアドオンという形で追加開発してきたため、ERPシステム自体が強大なレガシーシステム化してしまったのが今の状況であり、基幹システムがDX推進の足を引っ張る要因となっている。

これからの基幹システムに求められるものは、データの集中管理/リアルタイム管理はもちろんのこと、顧客・市場の変化に柔軟に対応し、デジタル技術をマイクロサービス・アジャイルといった手法で取り入れ、素早く新たな製品、サービス、ビジネスモデルを市場に展開し企業成長を遂げることを下支えする基盤としての役割だ。

SAP製品は、これらの要求に十分応えられる製品だが、その性能を生かすためには「Fit to Standard による導入（標準導入）」が欠かせない。「Fit to Standard」で導入できなかった場合、現在同様、柔軟性に欠ける巨大なレガシーシステムを誕生させることになる。

※ ERPを導入することにより、リアルタイムに経営状況を分析/把握できる基盤を手に入れた企業がある一方で、ERPを導入したにも関わらず、経営状況を思うように分析/把握できない企業も多い。なぜこの違いが発生するかについては、別の記事にて解説する。

3. Fit to Standardで考慮するポイントとは

過去に導入したERPパッケージがレガシーシステム化してしまい、扱いに困っている企業ほど、Fit to Standard（標準導入）の重要性を身に染みて感じていることだろう。

しかし、Fit to Standardを推進する際に懸念される「現場からの反発」や、「自社が持つ競争優位が失われてしまう点」を危惧し、Fit to Standardでの導入に踏み切れない企業や、プロジェクトを推進するうちに、なし崩し的にアドオン開発を許容してしまった企業は数多い。

これまでERPパッケージの導入では、自社業務にFitしない部分について、下記の2択で検討することが多かった。

• 現場業務を変える（業務変革）

• 独自プロセスを追加する（アドオン開発/ERP外でのスクラッチ開発）

昨今では上記の２つに加えて、下記の選択肢がある。

• 他サービス（SaaS/PaaS）の活用、という「第三の道」

• ノーコード/ローコードでの開発、という「第四の道」

この第三の道や第四の道を考慮せず、経営陣の「強い意思」や、外部コンサル会社の「チェンジマネジメントの技術」に頼ってFit to Standardでの導入を目指しても、これまでの歴史が示す通り、非常に危ういものであると言わざるを得ない。

Fit to Standardは手段であり、目的ではないことを意識し、

1. 現場業務を変える（業務変革）

2. 独自プロセスを追加する（アドオン開発/ERP外でのスクラッチ開発）

3. 他サービス（SaaS/PaaS）の活用

4. ノーコード/ローコードでの開発

をうまく組み合わせ、DX時代の基幹システム、すなわち、顧客・市場の変化に柔軟に素早く対応できる基幹システムを構築することが重要だ。（選択肢の優先順位は1→3→4→2）

4. 「足りないものはつくる」から「足りないものは他サービスと組み合わせる、補う」に必要な要素

さて、「第三の道：他サービス（Saas/Paas）の活用」、「第四の道：ノーコード/ローコードでの開発」(局所的に「第二の道：独自プロセスの追加」)によってDX時代の基幹システムを実現するために重要なことは何であろうか。それは以下の２点である。

• インテグレーション基盤

• 運用/CICD基盤

4-1. インテグレーション基盤

様々な製品/サービスや、ノーコード/ローコードで開発した独自システムが複数存在すると、必ず問題となるのがインテグレーション部分だ。

インテグレーション基盤に問題があると、データが分散化・サイロ化されるだけでなく、システムの利用者（ユーザー）にとって使いにくいシステムとなり、結果として生産性が低下することがありうる。インテグレーション基盤を考えるにあたって重要なことは、システム利用者に複数のシステムを利用していることを意識させないことであり、この中には、プロセスインテグレーション、UXの統合に加えて、これらを支える認証認可などのセキュリティ技術も含まれていることを強調しておきたい。

4-2. 運用/CICD基盤

CI/CDとは、Continuous Integration / Continuous Delivery（継続的インテグレーション/継続的デリバリー）の略で、ソフトウェアのテスト、環境の管理、各環境へのリリース管理を自動化したうえで、リリース後のシステム状態を見える化し、常に開発や各環境からのフィードバックを得ながら高品質にシステムを改変運用し続ける技法のことだ。CI/CDを取り入れることで、システムに迅速性や継続性を付与しつつ、品質を向上させる事ができる。

DX時代の基幹システムは「顧客・市場の変化に柔軟に素早く対応できる」ことが求められることから、様々な製品/サービスを素早く、柔軟に組み合わせたり、切り離したりできる基盤や体制（CI/CD環境）、そして、製品/サービスが入れ替わっても、運用の品質が担保されることが重要だ。

運用基盤を構想/設計せずに、小手先で様々なSaaSサービスやアジャイル開発を取り入れても、すぐに行き詰まる結果を招く。

5. 「足りないものは他サービスと組み合わせる、補う」を実現させる基幹システムの図解

図 2. 「足りないものは他サービスと組み合わせる、補う」を実現させる基幹システムのイメージ図

業務システムのコア（中心）は、SAPを中心としたERPパッケージである。追加の開発など一切せずFit to Standardで導入/稼働する。

足りない部分は、ERPパッケージ自体に追加開発（アドオン開発）で作りこむのではなく、他SaaSや他パッケージを組み合わせて対応する。（第三の道）

他のサービスで対応できない場合も、なるべく作りこみを行わずノーコード/ローコードの技術を取り入れ、柔軟に迅速に基幹システムを構築する。（第四の道）

最後に、どの道にも該当せず、企業の競争力の源泉になるような機能は局所的に、しかし人的/技術的にレガシー化させないようにしっかり作る。（第二の道）
ここで大事なことは、こういう構想からDX時代の基幹システムを考え始めることである。
そしてその前提で、必要なシステム要素をアーキテクチャとして検討する事である。

Fit to Standardに気を取られると全体像を捉えることに時間を割く事ができなくなりがちだが、必要となる機能は、環境変化や技術進化により変わり続けることを考えるならば、これからの基幹システム構想においてアーキテクチャ構想の重要性は格段に高くなった。

次回は、DX時代の基幹システムを支える技術要素の全体像、アーキテクチャに焦点を合わせて解説する。続きは以下をご欄いただきたい。

関連記事：
ERP基幹システムは「作る」から「組み合わせる」時代へ｜Fit to StandardでDX推進を加速

資料ダウンロード：
Fit to Standard伴走支援サービス　Figues（フィグ）