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

Joannes Vermorel著、2015年6月

会社のITシステムの奥深くから、非ユークリッドの恐怖が現れた。非ユークリッドの恐怖を見すぎると、永久に正気を失う危険性がある。

カテゴリー: 組織

問題: 長年にわたり、会社は多様なシステムを導入してきました。現在、ERP、WMS（倉庫管理システム）、CRM（顧客関係管理）、BI キューブ（ビジネスインテリジェンス）、eコマースプラットフォームなどが存在します。これらすべてのシステムの実装の間に、より専門的なタスクを遂行するために社内コンポーネントも開発されました。IT環境の複雑さは急激に増大し、追加される各アプリがすでに導入されているすべてのアプリと通信する必要が出てきました。すべての部署に影響が及びますが、営業、購買、財務、生産の中間に位置するサプライチェーンが最も影響を受けています。変更は鈍く、ほぼすべてのサプライチェーンの取り組みが期限を守ることに失敗しています。誰も会社のシステム内で何が起こっているのか、本当に理解できなくなっています。

逸話的証拠: 近隣にある別の倉庫へ物理的に移動するのは2週間で可能ですが、ソフトウェアに関しては、新しい倉庫を統合するための実際のIT移行には6ヶ月以上かかるでしょう。

文脈: ずっと昔、各部署はそれぞれ独自のソフトウェアソリューションからスタートしました。統合が不十分だったため、最終的に全てを支配するためのERPシステムを導入することが決定されました。ERPシステムは実装されましたが、ソフトウェア業界の急速な変化に追いつくことはできませんでした。サプライチェーンに関しては、生産性と信頼性を向上させるためにWMS（倉庫管理システム）が導入され、これは比較的うまくいきました。他の部署も、元のERPよりも適合性の高い独自のドメイン専用アプリを導入するという同様の動きを取りました。しかしながら、ビジネスはかつてない速さで変化しており、今日、よりスマートなサプライチェーン運用を実現するには、これらすべての異なるアプリ間の無数の相互作用が必要となっています。

想定される解決策: 新たな課題が発生するたびに、期待される結果を出すためにITシステムが最小限の調整を受けています。サプライチェーンの目的では、営業チームからの入力を集めるためにCRMとのアドホックな統合が行われ、また、財務で使用される数字と一致する数値を得る唯一の方法としてBIキューブとのもう一つのアドホック統合が設定されました。物流サービスやサプライヤーも独自の統合をいくつか必要としていました。その結果、サプライチェーンチームは、ITの変更が大きくなるほど、予算を超え、期限を守れなくなる可能性が高いことを学びました。したがって、狭い範囲での漸進的な変更が、大きな進化よりも強く支持されるようになりました。

結果としての文脈: ビジネス内のさまざまなIT相互作用の表現と比較すると、東京の地下鉄路線図はシンプルに見えます。会社内のすべてのシステム間には、何百もの微妙な依存関係が存在します。IT環境の全体像は、せいぜいぼんやりとしているに過ぎません。サプライチェーンでは、新製品、プロモーション、ほぼ確定した段階の購買注文、在庫レベルや在庫切れの履歴など、あらゆる関連情報にアクセスするための絶え間ない苦闘があります。プロセスが追加情報を活用して改善されるたびに、サプライチェーン運用の小さな改訂が永遠に続くように感じられます。データ入力は不一致で、システムは次々と障害を起こし、例外を手動で管理する必要があちこちにあります。

魅力的な力: 会社は、ITの取り組みが大きければ大きいほど、その取り組みが失敗する可能性が高いということを痛感しました。したがって、すべての施策は次第により小規模で、より集中した取り組みに進化し、予算とスケジュールを管理しやすくなりました。結果として、会社はまさにこのような小規模な取り組みにより早期の成功を収め、ごく少ない予算で好結果を得ることができました。

これが失敗につながる理由: 各漸進的な変更は、その後のすべての変更のコストと複雑さを増加させます。会社の慣行ができるだけ小規模で漸進的な変更を好むため、「全体像」に対する関心が常に欠如しています。ある意味で、これは「共有地の悲劇」のケースであり、個々の利益（会社の各部署）が会社全体の共通利益と一致していないのです。さらに、マイナスの影響は通常、変更が行われたかなり後になって初めて観察されるため、この問題は一層深刻になります。各変更が利益をもたらすように見えても、会社は「技術的負債」を蓄積し続け、短期的な利益が時間とともに損失へと転じています。

問題に対処するための前向きなパターン: 基本的に、漸進的な変更を実施することは合理的なアプローチです。しかし、各変更は、その後のすべての変更がより安価または単純になるように実行されるべきです。実際、これら二つの性質は非常に相関関係にあります。これは、各取り組みが、取り組みの主要な目標を達成するだけでなく、次の変更を円滑にするという二次的な目標も果たす、いわば「共有地の税」を支払う必要があることを意味しています。

例: Contosoは、ドイツにおける特定のB2C分野での国内eコマースリーダーです。会社は2000年代初頭に業務を開始し、その当時、オンライン購入を可能にする「アプリ」であるカスタムフロントエンドを開発しました。初期の頃は、ほぼすべてのITニーズが成長し続けるフロントエンドによって解決されました。しかし、サプライヤーや購買注文の管理は、このカスタムアプリには手に余るものでした。結果として、Contosoは中規模ERPへの投資を決断し、新興のサプライチェーンプラクティスの大部分を含むバックオフィスのプロセスをこのERPシステムに移管しました。一時的に、在庫レベルはフロントエンドとERPの両方で管理されましたが、この方法が混乱を招くことが判明し、最終的にContosoはフロントエンドから過剰な責任を見事に取り除くことに成功しました。

当初、ERPはその機能を果たしていましたが、会社が成長を続ける中で、ERP開発を担当する技術チームの最善の努力にもかかわらず、ERPはビジネスのすべての要求に追いつけなくなりました。報告機能は不十分で、財務部門は独自のBI（ビジネスインテリジェンス）ポータルを設置することを決定し、他の多くの部署も同様のアプリを独自に展開しました。サプライチェーン部門は購買注文をサプライヤーに送るための一連のEDI統合を開始しましたが、すべてをERPに流し込む方法は、Contosoのサプライチェーン運用の微妙なニュアンスを捉えられないため、次第にフラストレーションが溜まる結果となりました。

Contosoが国内リーダーへと成長するにつれ、幅広い調達オプションにアクセスできるようになりました。Contosoの初期の成功において重要な役割を果たした地元のドイツのディストリビューターは、競合他社が価格を引き下げる中で、ますます高価になっていきました。顧客がオンライン購入に「追加料金」を支払う時代はすでに終わっていました。その結果、Contosoは、より遠隔地あるいは海外のサプライヤーのサービスを利用するという、代替の調達オプションを徐々に業務フローに統合しなければなりませんでした。ERPにマルチソーシングのロジックを詰め込もうとする数ヶ月にわたる不成功の奮闘の後、サプライチェーンチームはERPから独立した自社システムを構築すべき時が来たと判断しました。サプライチェーンチームは先進的な調達アプリの導入を選択しましたが、設定には予想以上に長い時間がかかりました。新しいソリューション自体に問題があったわけではなく、ERPとの統合が一連の予期せぬ困難を引き起こしたのです。例えば、新ソリューションの立ち上げから3ヶ月後、サプライチェーンチームは、顧客サイトに表示される出荷遅延がERPではなく依然としてフロントエンドによって管理されていることに気づきました。したがって、これらの「表示される出荷遅延」はフロントエンドからERPへと流れていましたが、その逆の対応はなされていませんでした。その結果、製品提供に選ばれたサプライヤーに基づいて動的に更新される改訂済みの出荷遅延をERPに注入しても、ウェブサイトに表示される数値に影響を与えなかったのです。ERPはすでに非常に複雑な体制へと成長しており、内部で開発されたフロントエンドにContosoのITチームがより慣れ親しんでいたため、サプライチェーンチームとITチームは共同で、調達ソリューションが改訂済みの出荷遅延を直接フロントエンドに注入することに決めました。

このアプローチはやや混沌としており、元々は3ヶ月以内に調達アプリを展開する予定でしたが、実際には「稼働」までに9ヶ月を要しました。それでも、マルチソーシングによって平均購買価格が15%低下し、ビジネスに大きなブーストをもたらしたため、投資価値は十分にありました。

現代に目を向けると、サプライチェーン部門から独立したContosoの購買チームは、最大のサプライヤーと有利であるものの、残念ながら複雑な契約を交渉しています。例えば、ある一定のクォータが達成された場合、サプライヤーは四半期の終わりに多額の返金を行うかもしれません。これは通常、ユーロ建ての販売量と購入ユニット数の組み合わせを伴います。12ヶ月前、サプライチェーンチームは、各購買注文に最も利益をもたらすサプライヤーを選定する際に、こうした契約条件を考慮に入れる取り組みを開始しました。しかし、その取り組みはほぼ停滞状態にあります。サプライヤーの契約条件は購買システムにあり、財務関連の要素はBIシステムにのみ見られ、その他のサプライヤー関連情報はフロントエンドに残っており、これらのジグソーパズルの各部分を組み合わせるための内部アップグレードは一度も完了していません。実際に必要な変更量は少ないにもかかわらず、会社内のあらゆるシステムが関与しているようです。士気は低く、人々は次の任務にますます集中しており、前向きな成果は見込めていません。