非ユークリッドの恐怖（サプライチェーンのアンチパターン）

Joannes Vermorelによる、2015年6月

非ユークリッドの恐怖は、会社のITシステムの深淵から現れました。非ユークリッドの恐怖に長時間見つめ続けると、永久的な正気の喪失につながる可能性があります。

カテゴリー: 組織

問題: 会社は長年にわたり多くの異なるシステムを導入してきました。現在、ERP、WMS（倉庫管理システム）、CRM（顧客関係管理）、BIキューブ（ビジネスインテリジェンス）、電子商取引プラットフォームなどがあります。これらのシステムのすべての実装の間には、専門的なタスクを実行するために社内で開発されたコンポーネントもあります。ITランドスケープの複雑さは年々急激に増加しており、会社がすでに実装しているすべての他のアプリと通信するために、追加のアプリごとにすべての部門に影響を与えています。すべての部門に影響を与えていますが、販売、購買、財務、生産の間に位置するサプライチェーンが最も影響を受けています。変更は遅々としており、ほとんどのサプライチェーンの取り組みは期限に間に合っていません。もはや会社のシステム内で何が起こっているのかを誰も理解していません。

事例: 近くの別の倉庫に物理的に移動することは2週間で行うことができます。しかし、ソフトウェアの場合、新しい倉庫を統合するために必要な実際のIT移行には6か月以上かかります。

背景: ずっと前に、各社の部門は独自のソフトウェアソリューションでスタートしました。統合は不十分であり、最終的には「すべてを統治する」ためにERPシステムが設定されることになりました。ERPシステムは実装されましたが、ソフトウェア業界の急速な変化に追いつくことができませんでした。サプライチェーンに関しては、生産性と信頼性を向上させるためにWMS（倉庫管理システム）が設定され、これは比較的うまく機能しました。他の部門も、元のERPよりも適したドメイン固有のアプリを設定することで同様の動きをしました。しかし、ビジネスは今まで以上に速く変化しており、今日では、よりスマートなサプライチェーンオペレーションには、これらすべての異なるアプリ間の無数の相互作用が関与しています。

想定される解決策: 新たな課題が発生するたびに、ITシステムは期待される結果を提供するために最小限のレベルで調整されます。サプライチェーンの目的のために、CRMとの特別な統合が設定され、営業チームからの入力を収集するために別の特別な統合が財務との一貫性のある数字を持つ唯一の方法であるBIキューブとの間で設定されました。物流サービスとサプライヤーには、それぞれかなりの数の統合が必要でした。その結果、サプライチェーンチームは、ITの変更が大きければ大きいほど、イニシアチブが予算外になり、期限に間に合わなくなる可能性が高いことを学びました。したがって、狭い増分変更が、大幅な進化よりも強く支持されるようになりました。

結果的な状況: 東京の地下鉄の地図は、ビジネス内の異なるITの相互作用の表現と比較すると、シンプルに見えます。会社内のすべてのシステム間には数百もの微妙な依存関係があります。ITの全体像は最良の場合でも非常にぼやけています。サプライチェーンでは、新製品、プロモーション、ほぼ最終段階の発注、在庫レベルとストックアウトの履歴など、すべての関連情報にアクセスするための常に苦労しています。情報の追加によってプロセスが改善されるサプライチェーンの小さな修正ごとに、時間がかかります。データ入力が一貫しておらず、システムが故障し続け、あちこちで手動で管理する必要がある例外があります。

魅力的な要素: 会社は、ITのイニシアチブが大きければ大きいほど、イニシアチブが失敗する可能性が高いことを苦い経験から学びました。したがって、すべてのプラクティスは徐々により小さな焦点を持つイニシアチブに進化し、予算とタイムラインを管理しながら展開しやすくなりました。会社は、このような小規模なイニシアチブを通じて早期の成功を達成し、小さな予算で肯定的な結果を得ることに成功しました。

なぜこれが失敗につながるのか: 各増分変更は、すべての後続の変更のコストと複雑さを増加させます。会社のプラクティスは、できるだけ小さく、増分的な変更を好むため、「大局」に対する関心が常に不足しています。ある意味では、これは「共有地の悲劇」の一例であり、個々の利益（会社の別々の部門）が会社全体の共通の利益と一致していません。問題は、負の影響が変更が行われてから長い時間が経ってからしか通常観察されないため、より深刻になります。各変更は利益をもたらすように見えますが、会社は「技術的負債」を蓄積し続け、短期的な利益を時間の経過とともに損失に変えてしまいます。

問題に対処するためのポジティブなパターン: 基本的に、増分変更を実装することは合理的なアプローチです。ただし、各変更は、その後の変更がより安価またはシンプルになるように実行されるべきです。これらの2つの特性は実践では非常に相関しています。これは、すべてのイニシアチブが、イニシアチブの主要な目標だけでなく、変更がスムーズに行われるための副次的な目標も達成する必要があるということを意味します。

例: Contosoは、特定のB2Cセグメントでドイツの国内電子商取引のリーダーです。同社は2000年代初頭に事業を開始し、当時は独自のフロントエンドを開発しました。フロントエンドはオンラインでの購入を可能にする「アプリ」です。会社の初期の数年間、ほぼすべてのITニーズは、ますます成長するフロントエンドで解決されました。ただし、サプライヤーと発注の管理は、この独自のアプリにはあまりにも多すぎました。そのため、Contosoは中堅市場のERPに投資し、このERPシステムにバックオフィスプロセスをすべてオフロードすることを決定しました。しばらくの間、在庫レベルはフロントエンドとERPの両方で管理されましたが、これは混乱を招くことがわかったため、Contosoは最終的にフロントエンドから過度の責任を取り除くことに成功しました。

ERPは最初はその機能を果たしましたが、会社が成長し続けるにつれて、ERP開発を担当する技術チームの最善の努力にもかかわらず、ERPはビジネスのすべての要件に対応できなくなっていました。レポートは不十分であり、財務部門は独自のBI（ビジネスインテリジェンス）ポータルを設立することを決定し、他のほとんどの部門も同様のアプリを展開しました。サプライチェーンは、発注書をサプライヤーに送信するための一連のEDI統合を開始しましたが、ERPにすべてを統合することはますますイライラするように感じられました。なぜなら、ERPはContosoのサプライチェーンの操作の微妙さをすべて捉えることができなかったからです。

Contosoは国内のリーダーに成長したため、さまざまな調達オプションにアクセスできるようになりました。最初にContosoの成功に重要な役割を果たした地元のドイツの流通業者は、競合他社が価格を下げるにつれてますます高価になっていました。顧客がオンライン購入に「余分な」費用を支払う意欲がなくなって久しいです。その結果、Contosoは徐々に代替調達オプションをワークフローに統合する必要がありました。通常、より遠く、時には海外のサプライヤーのサービスを利用しています。マルチソーシングのロジックをERPに押し込む試みは数ヶ月間うまくいかず、サプライチェーンチームはERPから独立した独自のシステムを設定することにしました。サプライチェーンチームは高度な調達アプリを選択しましたが、セットアップには予想以上に長い時間がかかりました。新しいソリューションには問題はありませんでしたが、ERPとの統合に予期しない困難が生じました。たとえば、新しいソリューションのローンチから3ヶ月後、サプライチェーンチームは顧客のウェブサイトに表示される出荷の遅延がERPではなくフロントエンドによって管理されていることに気付きました。したがって、これらの「表示される出荷の遅延」はフロントエンドからERPに流れていましたが、逆をサポートするための何も行われていませんでした。その結果、製品を提供するために選択されたサプライヤーに基づいて動的に更新される修正された出荷の遅延をERPに注入しても、ウェブサイトに表示される数字には影響しませんでした。ERPはすでにかなり複雑なセットアップに成長しており、ContosoのITチームは内部で開発されたフロントエンドにはるかに快適に感じていました。そのため、サプライチェーンとITチームは共同で、調達ソリューションが修正された出荷の遅延を直接フロントエンドに注入することにしました。

このアプローチはやや混乱を招きましたが、最初は調達アプリを3ヶ月以内に展開する予定でしたが、「ライブ」にするまでには9ヶ月かかりました。しかし、それは投資に値するものでした。マルチソーシングにより、平均購入価格が15％下がり、これはビジネスにとってかなりのブーストとなりました。

現在に至るまでの経過。Contosoの調達チームは、サプライチェーン部門から分離され、最大のサプライヤーと有利ながらも複雑な契約を交渉しています。たとえば、サプライヤーは、通常、ユーロでの販売数量と購入数量の組み合わせを含む特定のクォータを達成した場合、四半期ごとに相当額の返金を行います。12ヶ月前、サプライチェーンチームは、各発注に対して最も利益の高いサプライヤーを選択する際にこのような契約を考慮に入れるためのイニシアチブを開始しました。しかし、このイニシアチブはほとんど停滞しています。サプライヤーの契約条件は調達システムにあり、財務要素はBIシステムにしか見つかりません。その他のサプライヤー関連情報はフロントエンドに残っており、このジグソーパズルの異なる部分を組み合わせるための内部のアップグレードはまだ完了していません。実際に必要な変更の量は少ないですが、会社内のすべてのシステムが関与しているようです。士気は低く、人々は次の割り当てにますます集中しています。