日本語
down-arrow
language-flag language-flag language-flag

製造業および流通業におけるPMI（ポスト・マージャー・インテグレーション、経営統合）で、システムのダウンタイム、ネットワークセキュリティ、給与の継続性といった最も見えているリスクは既に十分に記録されています。

一方で、異なるコマースインフラストラクチャが未対応のまま残ることで発生する顧客体験の断絶は、収益問題となるまであまり注目しない課題です。

McKinseyによると、BtoB購入者は現在、総支出の3分の1をデジタルセルフサービスチャネルで処理しており、これには50万ドルを超える取引も含まれます。また、45%が注文の非効率性と可視性の不足を主な理由として、サプライヤーのデジタル体験に不満を表明しています。適切に管理されない限り、PMIはこれらの基本的な課題を悪化させます。

本記事では、PMI中に顧客体験がどのように悪影響を受けるか、またワークフロー統合に基づく戦略がいかにしてプロセス全体を通じて顧客関係を維持できるかを解説します。2つの組織事例により、これを効果的に対処する方法を探ります。

なお、組織がPMIを最初から最後まで管理する方法、適切なECプラットフォームを選択する際に考慮すべきこと、そして統合ワークフローアプローチを主張するためにCX断片化の財務コストをどのように定量化できるかについても詳しく紹介します。

PMI でのCXの問題：購入者がギャップを気づくとき

PMIは、予測可能な顧客体験の失敗パターンを作成することで既存の複雑さを倍増することができます。買収された事業体は、独立したERP、カスタムポータル、互換性のないデータ構造を伴います。

典型的なIT対応は、まず財務統合に焦点を当てながら並行システムを維持することです。顧客向けシステムは、苦情が増えるか、収益への影響が測定可能になった後についに注目を集めます。

従来単一のブランドと取引していた購入者にとっては、以下の通り現在いくつかの新しい問題に直面しています。

  • 複数のログイン認証情報
  • 一貫性のない価格表示
  • 断片化された注文履歴
  • 異なるドメインからの出荷通知

技術的には現在1つのサプライヤーである支出を管理する調達チームにとって、その体験は依然として複数のベンダー関係を管理していることを感じています。これにより、PMI CXの保全は強化の取り組みではなく、防御的要件です。

統合戦略としてのワークフロー統一

統合期間を通じて顧客関係を維持できる組織は、主に1つの特定のアーキテクチャアプローチを共有しています。それは、購入者体験からバックエンドの複雑さを切り離す統一されたコマース層です。

顧客タッチポイントに対処する前にERPを統合しようとするのとは異なり、この戦略は最終的にどのレガシーシステムがトランザクションを実行しても、すべての顧客主導プロセスに対して単一の相互作用モデルを作成することを目指しています。

このアプローチは、併合契約をまとめる後の重要な最初の90日間にすぐに3つの安定化メリットを提供します。

  • 顧客は、SSO（シングルサインオン）の実装によって統一された認証情報を受け取り、最も目に見える統合の問題点を排除します。
  • レガシーURLは、統合された体験にリダイレクトされ、サポートリクエスト量の急増を防ぎます。
  • カスタマーサービスおよび営業チームは、一貫したプロセスドキュメントを備えた共有知識ベースから運用し、どのエンティティが元々アカウントを管理していたかに関係なく、一貫した回答を可能にします。

エンドユーザー側では、顧客は1つのビジネスルールセットを持つ1つの会社を認識します。ITは、顧客が決して見ることのないロジックに基づいて、これらの相互作用を適切なバックエンドシステムにルーティングする複雑さを管理します。

「統合データモデル」を基盤とする「統合BtoB EC プラットフォーム」のコアコンポーネントを示す図。

以下の2つの成功事例は、ワークフロー統合に基づくアプローチの価値を実証しています。

【事例１】DiversiTech：統合を強制せずに12のERPを管理

DiversiTechの統合後環境は、非常に断片化された技術的環境におけるワークフロー統合の実用的な応用を示しています。

その組織は、買収を通じて構築された北米の大手HVACコンポーネントメーカーとして、12の独立したERPシステムを保持しており、それぞれが確立された顧客関係を持つ異なる事業単位をサポートしていました。

統合前の顧客体験は、以下の通りこの断片化を2つの注目すべき方法で直接反映していました。

  • 製品ライン全体で購入する顧客は、各事業単位の個別のアカウントを管理していました。
  • 注文の可視性は配置の時点で終了しました。出荷を追跡したり、パッキングスリップにアクセスするには適切な営業担当に連絡し、手動検索を依存するしかなかったです。

CX改善の前提条件としてERPの合理化をしようとするのではなく、DiversiTechはOroCommerceと提携して、12のシステムすべてに接続する統合コマース層を実装しました。このプラットフォームは、受注とアカウント管理のための顧客向け記録システムとなり、財務および在庫の真実はERP全体に分散されたままでした。

顧客にとって、ログイン体験は潜在的な12つの認証情報セットから1つに縮小しました。注文履歴はすべての事業単位にわたって単一のダッシュボードに統合されました。以前は担当者の支援を必要としていた文書（パッキングスリップ、請求書、保証書、追跡情報）がセルフサービス検索になりました。認識は、12社のサプライヤーで購入することから、幅広い能力を持っている1つの会社から購入することに転換しました。

【事例２】Lactalis：地域の柔軟性を排除せずに標準化

各国に数十年の買収を通じて構築された乳製品の多国籍企業として運営しているLactalisは、企業規模の効率性を達成しつつ地域市場の応答性を維持するという窮地に直面していました。

拡大した各地域には、独立したビジネスプロセス、販売モデル、最新のものから時代遅れのものまでさまざまな技術スタックが付属していました。新しいデジタル活動は、速度とリソース要件によって妨げられ、個々の地域ごとのカスタムビルドと手動修正は言うまでもありません。

Lactalis Australiaのウェブサイトにおける「Long life white milk」製品カテゴリーページのスクリーンショット。バナーの下には、4種類のHarvey Fresh牛乳パックが並んで表示されています。

ワークフロー統合戦略は、ビジネスロジックを特定しながらプラットフォームアーキテクチャを標準化することにより、このペインポイントに対処しました。製品データ管理、顧客アカウント構造、受注、システム統合のための中核となるワークフローは、すべての展開で一貫したパターンに従いました。税計算、価格ルール、コンプライアンス文書要件の地域的変動は、カスタムコーディングではなく構成されました。

結果は自明です。新市場参入の展開時間は半分以上減少し、複数年の実装プロジェクトだったものを大幅に削減しました。ワークフロー自動化が、地域固有の回避策に取って代わったため、手動データ入力は44%減少しました。以前は流通が唯一の選択だった市場では、この標準化された基盤により、現在は直接顧客への販売チャネルの立ち上げが可能になっています。

ワークフロー統一のための実用的なヒント

PMI でのCX保全のための実装タイムライン

PMIを通じて顧客体験の質を成功裏に維持するために、多くの組織は技術的複雑さを段階的に管理しつつ購入者向けの安定性を優先する一貫した実装順序に従います。

  • まとめる前：デジタルデューデリジェンス（買収監査）PMIでの CXの保全は、取引評価段階で始まります。効果的なデューデリジェンスは、すべての顧客相互作用ポイントをマッピングします。（Webポータル、注文システム、価格設定ツール、アカウント管理インターフェース）評価は、どのシステムが顧客にとって重要であり、運用上便利であるか、手動プロセスがシステムギャップを隠している場所、どの統合ポイントが最も脆弱性リスクを示すかを特定します。
  • 最初の90日：CX向けの安定化。 SSOの展開により、認証情報の断片化が排除されます。URLリダイレクトにより、保存されたリンクを使用している顧客がリンク切れを回避し、正しい宛先に到達することを保証します。統合された知識ベースは、カスタマーサービスおよび営業チームに統一されたプロセスドキュメントを提供し、どのチームメンバーが電話を受けても一貫した回答を可能にします。
  • １～3ヶ月：統合プラットフォームの展開。 BtoB組織のプラットフォーム選択は、複数レベルの承認ワークフローを持つ複雑なアカウント階層、契約固有の価格設定、および複数のERPシステムとの統合をサポートする必要があります。データ衛生も、移行前に交渉不可能になります。既存の問題は、製品カタログの重複レコードや顧客データベースの一貫性のないアカウント階層を通じて新しいプラットフォームに持ち込まれるリスクがあるためです。
  • 12～36ヶ月：レガシーシステムの廃止。 システムは、使用データが顧客が新しいプラットフォームに移行したことを確認したうえで廃止されます。重複するソフトウェアライセンスが終了し、サポート契約が終了し、ITリソースが保守から開発作業にシフトするにつれて、統合によるコスト削減が明らかにします。

ベンダーの主張の検証：マーケティングよりもアーキテクチャ

PMIでの CXの取り組みのための多くのコマースプラットフォームは、通常、「統一された」および「オールインワン」の機能を持つものとして広告します。アーキテクチャ的に統一されたプラットフォームをただツールやソフトウェアを集めるソリューションと区別するには、機能チェックリストにとどまらず技術的検証が必要です。

  • 単一データモデル：アーキテクチャ的に統一されたプラットフォームは、コアコマースエンティティ用の1つのデータベースに対して動作する1つのコードベースによってアクセスされる1つのデータモデルを維持します。契約価格の変更は1つの場所で1回発生し、すべての顧客向けディスプレイにすぐに反映します。複数の企業の買収を通じて統一を達成するプラットフォームは、このテストに失敗することが多いです。
  • ネイティブアカウント階層：BtoB購買担当組織には複雑な構造があります。この環境用に構築されたプラットフォームは、これらの階層をデジタルで複製できるアクセス制御リストを提供します。これにより、顧客は監査証跡を維持しながら、ITの関与なしに役割と支出のしきい値を調整して、独自のユーザーを管理できます。
  • マルチエンティティ管理：複数のブランドまたは買収されたエンティティを管理する組織の場合、プラットフォームはマルチエンティティ操作をネイティブにサポートする必要があります。これは、グローバルデータを一元管理しながら、ローカルデータを特定の事業単位に分離することを意味します。新しいエンティティのオンボーディングは、カスタム開発プロジェクトから構成の課題に転換します。

断片化のコストの定量化

PMIでの CX投資に対する経営幹部の承認を得るには、技術アーキテクチャの問題を財務影響指標に変換する必要があります。

Gartner PAIDモデル（Planning 計画、Address 対処、Ignore 無視、Delay 遅延）を基づくフレームワークは、技術的負債をビジネスリスクおよび修復コストにマッピングすることにより、徹底的な評価を可能にします。

McKinseyのデータは、保守活動がIT予算の約40%を消費することを強調しています。断片化された合併後のスタックを運用している組織は、統合の複雑さが増すにつれて、この割合が高くなる傾向があります。ビジネスへの影響とリスクの両方で高い点数を獲得するコンポーネントは、優先的な統一対象を表します。

最終的な考慮事項：ワークフロー統一による合併後の状況のナビゲート

組織は、断片化されたインフラストラクチャを保持し、運用コストと顧客体験の低下を永続的な条件として受け入れることを選択できます。あるいは、統合をアーキテクチャ統合のための強制機能として扱うこともできます。

M&A活動から価値を抽出する組織は共通点を示します。それは、顧客体験の断片化が収益リスクに直接変換されることを認識しており、完全なERP統合をしようとする前にワークフロー統合に投資し、消費者用ツールを適応させるのではなく、BtoBの複雑さのために設計されたプラットフォームを選択します。

最も重要なのは、彼らがコスト削減指標だけでなく、デジタルチャネルの採用率、平均注文額、統合中の顧客維持率、新規に獲得された顧客関係の生産性向上までの時間など、いくつかの指標を通じて成功を測定します。PMIでの CX保全の目的は、統合後のクリーンアップ活動を超え、この併合契約が顧客価値を創造するか破壊するかを決定する戦略的統合ワークストリームです。

PMI期間にわたってCXを維持するには、明確かつ戦略的なビジョンが不可欠です。お客様の組織に最適なアプローチをご確認いただくため、ご相談のご予約をご希望の方は、contact@ekino.vnまでお問い合わせください。

OroCommerceの最新バージョンが登場しました。新しいOroCommerce 7.0のデモをご希望の方は、contact@ekino.vnまでお問い合わせください。