企業変革について語る際、プラットフォーム、移行方式、ターゲットアーキテクチャといった技術的な論点に焦点が当たりがちである。しかし、多くの企業にとって本当の懸念となることは、もっとシンプルである。
「ビジネスに不要な混乱を生じさせることなく、どのようにシステムをモダナイズできるか？」
この問いは、ERPが財務、製造、サプライチェーン、調達、顧客業務など、企業活動の中核をなすプロセスを支えている場合に、特に重要となる。変革プログラムは、たとえそれが技術的に成功したとしても、変革の進め方を誤ってしまったり、不要な複雑性をそのまま引き継いでしまったり、データの信頼性を損ねてしまったり、Go-Liveの直前になって初めて業務上の問題が明らかになったりすることもあり得る。そのようなケースでは、ビジネスに実際は深刻な影響を及ぼす可能性がある。したがって、リスク低減については移行を開始する前から考え始めなければならない。cbsでは、この考え方を以下の5つのステップに分けて提唱している。
Clarity（明確化） → Precision （具体化）→ Transformation（変革） → Trust（信頼） → Confidence（確信）
この5つの原則に則ることで、変革プロセス全体における不確実性を低減することができる。
-
Clarity: 変える前に、まず理解する
変革における最初のリスクは、現状環境を十分に理解しないまま意思決定を行うことである。大規模なSAP環境には、長年にわたって蓄積された以下のような要素が存在する。
- カスタム開発
- インターフェース
- 過去データ
- 組織変更の履歴
- 業務固有のプロセス
- 複数システム間の依存関係
つまりここで言いたいのは、どのように変革するかを決める前に、まず「現在の環境がどうか」を可視化する必要がある、ということである。
そのために把握しなければならないことは、
プロセスのなかでビジネスにとってクリティカルなのはどの部分か
現在バリューを実際に生み出しているのはどのカスタマイズ部分か
移行する必要があるデータはどの部分か
システムやインターフェースが相互に依存しているのはどの部分か
システムに複雑性を抱えているのはどの部分か。
こうした点に関する議論を飛ばしてしまうと、変革に関する意思決定は一気に「思い込み」に基づくものとなりうる。そして、実行フェーズに入ってからそれらの「思い込み」は、高くつく。
リスク低減の原則①：
行き先を決める前に、まず現状のランドスケープを理解せよ。
-
Precision：適切な変革アプローチを選択する
大前提として、SAP S/4HANAやSAP Cloud ERPへの移行に、唯一の正解ルートがあるわけではない。新規導入によって大幅なプロセス改革を行うことが適している場合もあれば、一方で、既存環境の多くを維持しながら、新しいプラットフォームへ移行することを優先すべき場合もある。また、現状すでにバリューを発揮しているプロセスや過去データを残しながら、変革が必要な領域だけを選択的に変えるアプローチが適している企業も存在する。まとめると、代表的な選択肢は、以下の3つである。
新規導入
大幅な簡素化、標準化、プロセス再設計を目指す場合。
システムコンバージョン
既存のランドスケープが概ね課題なく機能しており、直近のビジネス面での影響を抑えながら新しいプラットフォームへ移行することを優先したい場合。
選択データ移行
両者の要素を組み合わせ、必要なデータやビジネスバリューを維持しながら、特定のプロセス、組織構造、業務領域のみを選んで変革する場合。
どの選択肢を選ぶかそのものには、さしたるリスクは潜んでいない。
ただし、ここでリスクとなるのは、ビジネス要件を十分に理解する前に変革方式を決めてしまうことである。
リスク低減の原則②：
ビジネス観点での目標がIT面での方針を定義するのであって、その逆ではない。
-
Transformation変えるべきものを変えつつ、機能しているものは維持する
見てきたように、変革とは、すべてを置き換えることをたいていの場合意味しない。
長年利用されてきたSAP環境には、現在も大きなビジネス価値を持ち続けるプロセス、組織構造、過去データが存在する。
だからこそ、変革は選択的であるべきなのだ。
変える必要があるものを変える。
価値を生み続けているものは残す。
もはや無意味な複雑性は取り除く。
これは、以下のような企業にとって特に重要である考え方である。
- SAPを長年利用している企業
- 高度にカスタマイズされたシステム環境にある企業
- 過去データが大量に蓄積されている企業
- 複数の会社コードを持つ企業
- 複雑な組織構造を持つ企業
- M&Aによってシステム環境の変化を余儀なくされた企業
このような状況では、選択データ移行が有効な選択肢となる。
当然のように何から何まで移行するのではなく、どの部分をターゲット環境へ移行するのかを選択できるからである。
同じ考え方は、カーブアウト、M&A、組織再編を含むシナリオにも当てはまる。
企業が分離・再編を経る際、ビジネス形態の変化に合わせてシステムやデータも変化させる必要がある一方で、業務の継続性とデータの整合性はしっかりと維持されなければならないからである。
リスク低減の原則③：
変革は、ビジネス観点のバリューにアラインする形で、選択的かつコントロールされた形で進めよ。
-
Trust: Go-live直前だけではなく、継続的に検証を行う
変革における危険な思い込みの一つが、「検証はプロジェクト終盤に行うもの」という考え方である。
その段階になって問題が見つかれば、修正には大きなコストがかかる。むしろその状況を防ぐためにも、変革への信頼は、プロジェクトの遂行全体を通じて徐々に積み上げていく必要がある。
そのために、繰り返し検証しなければならない代表的要素をあげる。
- 移行のそもそものルール
- データ品質
- 財務データの照合
- 業務プロセスの挙動
- インターフェース
- 組織構造
- システムパフォーマンス
そして各ステージには、次の段階へ進む準備が整っていることを明確に示す「品質ゲート」を設けることが重要である。
ここで特に重要なのが、データに関してである。
なぜなら、移行が技術的には完了したとみなされ得る状態だとしても、実際のビジネスには、収支やマスターデータの不整合、取引データの欠落などの欠陥が残っている可能性があるからである。
だからこそ、移行のスピードに加えて、トレーサビリティと照合作業も同じように重要となるということだ。
リスク低減の原則④：
変革が機能するかの確認を、Go-liveまで待っていては遅い。
-
Confidence: 事業継続性を変革プログラムそのものに組み込む
ビジネスサイドにとって、変革の最終的な評価基準はシンプルである。
つまりそれは、「変革後も、事業継続性を担保できるのか？」という問いに尽きるように思われる。
工場は生産を続ける必要があるし、受注処理は止められない。
そして経理は決算処理を今まで通り行わなければならないし、サプライチェーンは動き続けなければならない。
企業がERPをモダナイズするという理由で、カスタマーに混乱や影響を及ぼすことは許されないということだ。
だからこそ、事業継続性に関する議論は、変革の設計段階から組み込んでおく必要があるのである。
最低でも定義しておくべき事項は以下の点であろう。
- 許容可能なダウンタイムの長さ
- クリティカルな業務が発生する期間
- カットオーバーにおける依存関係
- 問題発生時の対応方法
- データの整合性チェックに関するプロセス
- Go-liveに向けた明確な意思決定のポイント
特にダウンタイムに対する要求が厳しい場合には、変革を段階的に実行できるか、自動化をどこまで活用できるか、システム切り替えにかかる時間をどれだけ短縮できるかという観点で、変革ツールや移行戦略をより丁寧に検討する必要がある。
リスク低減の原則⑤：
Go-liveを迎えること自体はゴールではなく、Go-live後に安定的に事業運営を継続できることこそがゴールと心得よ。
変革のその先の運命を握るのも、デジタル基盤
繰り返しになるが、ERP変革を、モダナイゼーションの終着点として捉えるべきではない。
ERP変革によって、その先のデジタル化基盤の形成が見えてくるからである。
シンプルかつガバナンスのとれた基盤環境が整うと、取り組めるようになることを以下に例示する。
- アプリケーション統合
- プロセス自動化
- データへのアクセス性向上
- 新たなデジタルサービス導入
- AI活用
- 将来の組織変革対応
これは、SAP BTP、Business AI、さらには今後ますます台頭するであろうエージェンティック型のケイパビリティを目指す企業において、特に重要なポイントとなってくる。例えばAI活用の準備には、企業データの信頼性、有機的な業務プロセス、そして管理の行き届いたアーキテクチャが不可欠になる。
簡潔に述べると、既存の複雑性をそのまま再現するだけの変革では、「移行する」という今日の目標自体は達成できたとしても、明日のイノベーションを難しくしてしまう可能性があるということだ。
したがって、変革のリスク低減について考える際には、単にターゲット環境へ到達できるかどうかという点だけでなく、その環境が後々になって状況の変化に対応できるか、というところまで考慮する必要がある。
今すぐ始められる変革のリスク低減チェックリスト
ERPの変革方式を決定する前に、少なくとも以下の問いに答えられる状態であるかを確認するべきである。
- 現在のランドスケープをその課題まで含め明確に理解しているか。
- プロセスやカスタマイズのどの部分が、ビジネス価値におけるレバレッジ要因となっているかについて、把握できているか。
- テクニカルな議論にとどまらず、ビジネス要件に照らして複数の変革アプローチを比較したか。
- 移行する必要があるデータと、ないデータを把握しているか。
- テスト検証、データ整合性の確認、品質管理を、プログラムの初期段階から組み込んでいるか。
- 移行切り替え中の事業継続性をどのように担保するか。
- ターゲット環境は、将来的なクラウド、データ、AIに関する取り組みをより容易にするか。
これらの問いに明確な答えが見つからなければ、変革を実行フェーズへ進めるにはまだ、時期尚早かもしれない。
確信を持って変革を進めるために
企業変革に状況の変化はつきものである。
そしてすべてのリスクを排除することが変革の目的ではない。
重要なのは、どこにリスクが存在するのかをまずは理解し、それを根拠に意思決定を行うことで、変化にも焦らず対応できるようになることである。
この概念こそが、繰り返し我々が提唱する変革の5段階という考え方の根底にある。
Clarity（明確化） → Precision （具体化）→ Transformation（変革） → Trust（信頼） → Confidence（確信）
変える前に、把握する。
適切な道筋を選ぶ。
変革を選択的に。
検証は継続的に。
前進は目に見える根拠とともに。
なぜなら、繰り返しになるがSAPモダナイゼーションの成功とは、単に新しいERPプラットフォームを手に入れることを必ずしも意味しないからである。
今日の組織をより安定させ、明日の変化により柔軟に対応できるようになること。ONE.Ascent 日本は、cbs、SAP、そしてエコシステムの各社が、ERP、データ、ランドスケープ変革、クラウド、AI、そして継続的なオペレーション運用といった、それぞれの視点から企業変革のリスク低減について議論する場である。
価値を発揮できる領域でモダナイズする。
もう機能しているものは残す。
次の変化に備える。
ONE.Ascent 日本でお待ちしております。
