Tom Fairbairn サプライチェーン管理プロセスのバックボーンとしての IT インフラは、顧客の体験と収益に影響を与えるアクティビティを有効にしたり、制限したりすることができます。サプライチェーン管理におけるデジタルトランスフォーメーションの推進は、多くの場合、コスト、顧客体験、アジリティの3つに行き着きます。これらすべては、リアルタイムのコミュニケーションとリアルタイムのデータへのアクセシビリティによって大きな影響を受けます。そして、この新らたな10年が始まる今、これは大変重要です。
多くの企業は、Amazon、Alibaba、Shopify などの大企業に対抗し、国際配送を把握し、価格を正確に管理し、配送の遅延を予測・回避するために AI、IoT、ストリーミング分析などの新しいツールを活用して、すでにサプライチェーンをイベント対応にしています。これらの企業は、ITインフラがリアルタイムのデータに適応できる必要があることを認識しており、サプライチェーン管理にデジタルトランスフォーメーションを採用して、運用効率を最適化し、より優れた顧客体験を生み出しています。
このトピックに関するハイレベルのウェビナーにご興味がある場合は、次のビデオをご覧ください。
サプライチェーンと従来の統合ソリューション
天候、機械的な問題、または港での遅延により、海上輸送が遅れることが多いのは当然のことです。また、遅延がサプライチェーンに波及効果をもたらすことも驚くことではありません。例えば、ハリケーンにより、今週港に到着する予定だった貨物が遅れたとします。コンテナを収集する予定の輸送トラック/大型トラックを再スケジュールしてそこで待機させないようにし、その貨物を使用する予定の生産作業を遅らせる必要があります。
従来の統合ソリューションでは、ポーリングとポイントツーポイント統合を使用してサプライチェーンのこの部分を管理していました。船舶管理サービス（多くの場合、ClearMetal や OceanIT などの SaaS）をポーリングして、すべての貨物のステータスを確認していました。報告するものがない場合、リターンメッセージにはそのように表示されます。また、おそらく REST API を使用して、輸送管理アプリケーション（Oracle OTMなど）とポートのスケジューリングアプリケーションをポイントツーポイント統合で接続する必要があります。生産管理またはエンタープライズリソースプランニング（ERP）を追加する場合は、別のポイントツーポイント統合を追加する必要があります。
イベントドリブン型アーキテクチャは、サプライチェーン管理システムのような分散システムを別の方法で考えるやり方だと言えます。それ自体に困難がないわけではありませんが、その代わりに、従来の統合ソリューションでは得られなかったスケーラビリティ、柔軟性、敏捷性の面で大きなメリットが得られます。
上記のサプライチェーン管理の例の IT インフラがイベントドリブン型アーキテクチャで構築されている場合、遅延はそのイベントの内容を示すトピックとともに Event Broker に「公開」され、Event Broker は、そのトピックのイベントを受信するよう「登録」しているすべてのアプリケーションにイベントを配信します。これは、アプリケーションが互いに直接結びついておらず、通常は互いに認識することさえない、疎結合アーキテクチャにつながります。
サプライチェーン管理において疎結合が有益である理由
イベントドリブン型アーキテクチャでは、イベントは応答を期待せずに送信されます。サプライチェーン管理の IT インフラにおいては、なぜこれが良いアイデアなのでしょうか？送信者と受信者の間に依存関係がないことを意味するからです。
前に説明した例では、船舶管理アプリケーションは、出荷の遅延に関するイベントをリッスンしている他のアプリケーションを認識していません。そのため、遅延に関するイベントを購読することで、船舶管理システムを変更したり通知したりすることなくERP アプリケーションをミックスに追加できます。これにより、同じイベントで新しい処理を行う新しいアプリケーションの追加、設計、展開がはるかに迅速かつ容易になります。このデカップリングにより、ビジネス上の意思決定が改善されます。これは、すでに導入されているものに縛られることがなくなり、また新しいコードの作成や既存のシステムの変更をすることを意味するアプリケーションの追加や変更を心配したりする必要がなくなるからです。
しかも、何かをする必要があることに気づいてもポーリング間隔が切れるのを待つ必要がないので、処理やアクションの実行をリアルタイムで行うことができます。変更されていないデータで処理帯域幅と処理能力を浪費することがなくなり、ポーリングの頻度が低いために生産/出荷期間を見逃すリスクもなくなります。
進行中のイベント：Event Broker の役割
イベントドリブン型アーキテクチャでは、Event Broker は、トピック階層のベストプラクティスと組み合わせて、イベントを受信し、フィルタリングし、アプリケーションがどこにあるか（クラウド、オンプレミス）に関係なく、関心のあるアプリケーションにイベントを確実にルーティングする役割を担います。すべてのアプリケーションが Event Broker に接続し、ブローカーはエミッターからイベントを取得してリスナーに配信します。
トピックのルーティングとフィルタリング
IT インフラに Event Broker を追加したら、イベントが適切なアプリケーションに配信されるように、イベントがメタデータでタグ付けされるようにする必要があります。この「タグ」はトピックと呼ばれ、トピックはイベントが何を指しているかを説明するものです。トピックでは、イベント自体については説明していません。これは、イベントデータまたはペイロードの役割です。トピックは、イベントの内容を説明する階層的なフォルダ構造に似ています。イベントプロデューサーは、イベントを送信するトピックを認識するだけで、残りは Event Broker が処理します。イベントコンシューマーは、リッスンすべきトピックを認識する必要があります。
If an application needs to get an event, it registers its interest by subscribing to the topic – also known as the publish-subscribe messaging pattern. This subscription uses wildcards to select which events it should receive.
トピックの分類とサブスクリプションを使用すると、イベントドリブン型アーキテクチャの次の2つのルールを満たすことができます。
- サブスクライバーは、必要なイベントのみを購読する必要がある。サブスクリプションは、ビジネスロジックではなく、フィルタリングを行う必要がある。
- パブリッシャーは、1つのトピックに対して1回だけイベントを送信する必要がある。
サプライチェーン管理の例
出荷の例を見てみましょう：ウィジェットのコンテナ（1つのウルトラウィジェットを構築するのに必要）が嵐のために遅延しています。コンテナ船管理システムは、次のイベントを発行します。
widgetCo/supplyChain/shipping/v1/delayed/<container ID>/widget
このイベントには、新旧の到着時間などの変更の詳細と、記事番号などのウィジェットの詳細を反映したペイロードがあります。
輸送管理システムは遅延を把握する必要があるため、次のイベントをサブスクライブします。
widgetCo/supplyChain/shipping/v1/delayed/>
ワイルドカード「/>」に注意してください。これは、輸送管理がすべての出荷遅延通知を受信することを意味します。
サプライチェーン管理のデジタルトランスフォーメーションのためのイベントドリブン型の概念
サプライチェーン管理のデジタルトランスフォーメーションを進める前に考慮すべき重要なアーキテクチャ概念がいくつかあります。これらの概念は次のとおりです。
- Event Mesh
- パブリッシュ-サブスクライブメッセージングパターン
- コレオグラフィとオーケストレーション
- イベント管理
- イベントドリブン型デジタルツイン
サプライチェーン管理のためのイベントメッシュ
上記の例では、イベントの利用者がワイルドカードを使用したサブスクリプションを使用して、関心のあるイベントのみにイベントをフィルタリングする方法を示しました。しかし、イベントのルーティングについてはどうでしょうか？
アプリケーションは、さまざまな環境（オンプレミス、複数のクラウド）およびさまざまな地域でホストされる場合があります。サプライチェーン管理では、商品を国際的に発送している可能性が非常に高くなります。世界中にイベントを送信したり、すべてを1つの中央ポイントに接続したりしないようにするには、どのイベントをどこに送信するかを決定する必要があります。これをイベントのルーティングと呼びます。シンガポール行きのコンテナ遅延のイベントをカナダの輸送管理アプリケーションに送信しても、直接影響がない限り意味がありません。
幸いにも、これを行う簡単な方法があります。ただトピックを見るのです。必要なのは、さまざまな場所の Event Broker が、どのトピックがどこで消費されているかに関する情報を共有することだけで、ブローカーはイベントをどのように、どこにルーティングするかを決めることができます。ネットワーク内で Event Broker を接続して、コンシューマーのトピックのサブスクリプション情報を共有し、メッセージを動的にルーティングすることを Event Mesh と呼びます。
上記の例では、シンガポールのEvent Broker は、シンガポールでコンテナ遅延イベントのリスナーを持っている他のすべてのブローカーに指示します。以下の例は、Event Mesh（接続された Event Broker）が地理的な境界と、以前は異なる環境またはクラウドサービスによって課されていた境界を効果的に排除する方法を示しています。
- Widget & Co. の組立ラインがある中国のオンプレミス ERP
- 中国のクラウドサービスにおける輸送管理アプリケーション SaaS
- ヨーロッパでホストされているヨーロッパの海運会社のコンテナ管理 SaaS
パブリッシュ/サブスクライブによるサプライチェーンのパフォーマンスに関するリアルタイムインサイト
イベントストリームを構築すれば、リスナーも利用できるようになります。自分たちの権利として、一部のビジネスリーダーは、サプライチェーンのパフォーマンスに関する最新のインサイトを望んでいます。高級車の注文を完了するための重要な経路の一部が、税関検査を通過して顧客に配達されるまでの時間であると想像した場合、輸送、港、税関、陸上輸送を通じて進行を確認できる車両注文のダッシュボードが必要になり、これにより輸送時間も確認できます。Event Mesh が利用できる場合、データはすでに流れている（公開されている）ため、ダッシュボードにデータを取り込む（サブスクライブする）だけで済みます。
ダッシュボードは次のイベントをサブスクライブします (注、「EventMesh01」は車両のカスタム登録プレートです):
…/shipping/…/vehicle/EventMesh01/loadedOnBoard
…/shipping/…/vehicle/EventMesh01/unloaded
…/port/…/vehicle/EventMesh01/atCustoms
…/port/…/vehicle/EventMesh01/awaitingOnward
…/logistics/…/vehicle/EventMesh01/collected
…/logistics/…/vehicle/EventMesh01/deliveredToDealer
…/dealer/…/vehicle/EventMesh01/customerNotified
リアルタイムイベント (税関でディーラーに配信) がダッシュボードに送られるので、ビジネスリーダーは車で移動中でも必要に応じて、ビジネスの状態を一度に可視化できるようになります。
さらに一歩進めると、高級車メーカーはモバイルアプリを用意し、顧客がそれをダウンロードして…/*/…/vehicle/EventMesh01/>を購読できるようにすれば、顧客にリアルタイムで配送状況を通知することができます。
コレオグラフィーによるサプライチェーンの調整
ご想像の通り、何千ものサービスを提供するグローバル企業のサプライチェーン管理では、いくつかの深刻な調整が必要になります。他のすべてのサービスを追跡し、エラーが発生した場合にアクションを実行する単一のサービスを選択できます。これは、オーケストレーション – 単一の調整ポイント– と見なされ、問題を追跡する際に参照する単一ポイントを提供するだけでなく、単一障害点とボトルネックを提供します。
イベント駆動型アーキテクチャでは、サービスは受信したイベントをどう処理するかを理解することに依存しており、さらにイベントを生成することもあります。これは、個々のサービスが独自のことを行う「ダンス」につながりますが、組み合わせると、暗黙のうちに調整された応答が生成されます。このために、コレオグラフィーという用語が使用されているのです。私の同僚のJonathan Schabowskyがこのトピックに関する素晴らしいブログ記事を書いていますので、ぜひご覧ください。マイクロサービスコレオグラフィとオーケストレーション：コレオグラフィーのメリット
「だが、エラー条件はどうなのだろう？」と疑問に思っていらっしゃるかもしれません。エラーはイベントでもあるため、このようなエラーの影響を受けるサービスは、それらを消費してそれに応じて対応するように設定されています。これは、サプライチェーン管理のユースケースと高い関連性があります。別の例として、サプライチェーンの最初から見てみましょう。
ある農家では、高級アイスクリームブランドのフレーバーを提供するために、バニラのさやを栽培しています。さやは設定された日に収穫される予定ですが、収穫前日の悪天候により、作物全体の収穫が遅れてしまいます。オーケストレーションを使用しているアイスクリーム会社の場合、バニラのさやの収穫サービスでは次のことを行う必要があります。
- さやの回収のために道路輸送を遅らせる
- さやを回収する予定の船舶を遅らせ、通常通り停泊させるか、港の外で待機させるかを決定する
- 港のスロットを再スケジュールする
- 工場への次の区間についても、各工場で同様の作業が行われるよう徹底する
- 牛乳やその他の原料の出荷および下流物流を遅らせる
- ERPを更新して、工場生産スロットを更新する
大変多くの未確定要素があることがお判りいただけると思います。この複雑なサービスには多くの相互作用があり、何かを壊したり、サービス全体の SLA 時間を破る原因となる遅延を心配したりせずに、新しいサービスを変更または追加することは困難です。
次に、コレオグラフィーのアプローチについて考えてみましょう。収穫管理アプリケーションは、「バニラのさやの遅延」イベントをブロードキャストします。その仕事はこれで終わりです。他のアプリケーションは、イベントを消費し、それに応じて動作します。
- 陸上輸送管理アプリケーションは、適切な輸送トラック/大型トラックを再スケジュールし、「バニラのさやのコンテナ遅延」イベントを発行します。
- 船舶出荷管理アプリケーションと港湾管理アプリケーションは、コンテナ遅延イベントを受信し、ビジネスロジックがスケジューリングの影響を決定します。後続の船舶および港の遅延イベントが生成されます。
- ERP が更新され、生産が再スケジュールされます。
オーケストレーターサービスに依存するのではなく、イベントに対応する責任をイベントコンシューマー自体にローカライズすることで、デカップリングと懸念の分離を改善します。また、パフォーマンス面および俊敏性/複雑性の両面においても、ボトルネックとなるオーケストレーターを排除します。
理解と調整は依然として複雑に思えるかもしれませんが、Event Portal とも呼ばれるイベントストリームを管理、可視化、設計、共有するためのツールが用意されています。
Event Portal によるサプライチェーンイベント管理
バニラのさやの例からもわかるように、遅延に対処するための最善の方法を見極めるのは難しい場合があります。遅延したバニラのさやのコンテナの出荷を管理する方法の最適なソリューションを理解するためには、港と船の両方からの情報が必要です。
Event Portal は、ユーザーがイベントやイベントドリブン型アプリケーションを作成、カタログ化、共有、管理できるソリューションです。Event Portal は、それらを相互接続されたネットワーク図として視覚化し、チームは設計レビューで確認できます。このようにして、イベントやイベントドリブン型アプリケーションをデプロイする際、ランタイムで設計が現実とかみ合っているかどうかを簡単に確認できます（変更はすべてバージョン管理され、追跡されます）。
イベントドリブン型デジタルツイン
このような場面では、デジタルツインの概念が役立ちます。デジタルツインは、ビジネスプロセスのアクターのシミュレーションモデルであり、シナリオを実行してその結果を把握することができます。たとえば、農場から到着したらすぐにバニラのさやのコンテナを積み込めるように船を遅らせたいと思うかもしれませんが、すでに船に積み込まれている他のコンテナの遅延のコストはどうなるでしょうか？
ビジネスの現在の状態を正確に反映するには、シミュレーションモデル（コンテナや船などのデジタルツイン）を最新の状態に保つ必要があります。積載量の多い船は、積載量の少ない船よりも天候の影響を受けるため、遅延することが多いです。これは、デジタルツインが企業内の多数のソースからの最新のステータスを取り込まなければならないことを意味します。
デジタルツインをアップデートするために、関連するすべてのオーケストレーションプロセスを更新する責任を負いたいですか？おそらくそうではないでしょう。イベントドリブン型デジタルツインを作成することで、イベントメッシュを使用して関連するすべてのイベントをサブスクライブし、ツインの開発に合わせてモデリングを段階的に改良することができます。
結論: サプライチェーン管理のデジタルトランスフォーメーションに EDA が選ばれる理由
イベントドリブン型アーキテクチャが、サプライチェーン管理インフラを改善するための価値ある方法であるということが効果的に説明できたのではないかと思います。要約すると、サプライチェーン管理に適用されるイベントドリブン型アーキテクチャの主な原則は次のとおりです。
- パブリッシュ/サブスクライブメッセージングパターンを活用する
- Event Broker を使用して、適切なサービスとアプリケーションが適切なイベントを取得できるようにする
- 分散型アプリケーション、クラウドサービス、およびデバイス間でイベントを配信するためのイベントメッシュを作成する
- トピックを使用して、イベントが一度だけ送信され、アプリケーションが必要なものだけを受信できるようにする
- オーケストレーションによる単一障害点を導入するのではなく、イベントストリームを使用したコレオグラフィサービス
- Event Portal で可視化、設計、および発見のためのイベントドリブン型アーキテクチャを管理する
- イベントドリブン型デジタルツインを作成して、より優れたビジネス意思決定を行うためのシミュレーションモデルを開発する
なぜ、これらすべてを行う必要があるのでしょうか？
- 即応性。すべてのことが最速で発生し、他の人を待たずに済むため、イベントドリブン型アーキテクチャは最速のレスポンスタイムを提供します。
- 拡張性。下流で何が起きているかを考慮する必要がないため、サービスインスタンスを追加して拡張できます。トピックのルーティングとフィルタリングは、Command Query Responsibility Segregation（CQRS）のように、サービスを迅速かつ簡単に分割できます。
- 敏捷性。他のサービスを追加したい場合は、イベントをサブスクライブさせて、それ自身の新しいイベントを生成させることができます。既存のサービスは、これが起きたことを認識せず、気にも留めないので、影響はありません。
- 敏捷性、 再び。イベントメッシュを使用することで、クラウド、オンプレミス、別の国など、好きな場所にサービスをデプロイできます。イベントメッシュはサブスクライバーの場所を学習するため、他のサービスに認識されることなくサービスを移動できます。
これらのメリットは、単一の変更がチェーン全体に波及して大きな結果をもたらす可能性があるサプライチェーン管理のユースケースで特に重要です。リアルタイムの情報に対応でき、新しいサービスと分析をすばやく簡単に追加できるため、サプライチェーンの運用と管理が大幅に強化されます。
さらに詳しく知りたい方は、私のテクニカルウェビナーをご覧ください。
サプライチェーン管理のデジタルトランスフォーメーションと、イベントメッシュを構築することで運用効率を最適化し、より優れた顧客体験を生み出す方法をご覧ください。