第3回　3PLのITは荷主の期待に応えているか[米3PL研究]：ロジスティクス・ビジネス[LOGI-BIZ]バックナンバー

2010年3号

*下記はPDFよりテキストを抽出したデータです。閲覧はPDFをご覧下さい。

MARCH 2010　　56 3PLのITは荷主の期待に応えているか　ロジスティクスとＩＴは切っても切れない関係にある。
ＩＴシステムによって得られる情報が、サプライチェーンの計画・実行プロセスの血液であることはすでに業界の常識である。
荷主がロジスティクスの機能をアウトソーシングする際にも、ＩＴは関係性を成り立たせる必要条件となっている。
　�
稗圓鬚匹海泙韮械丕未貿い察△匹海泙納� 分で行うか、荷主は決断を下さなければならない。
その決断にあたっては、３ＰＬ側のＩＴ対応力がカギとなる。
　二〇〇二年度の初調査以来我々は、荷主側の期待とプロバイダーが持つＩＴ対応力との間にあるギャップと、サービスへの満足度について報告を行ってきた。
毎年、幅は多少増減するが、ギャップそのものは今回の調査でも相変わらず存在しつづけている。
　荷主と３ＰＬは相当の金額をＩＴに投じているが、その八割ほどはメンテナンスに消えてしまう。
既存の入り組んだアプリケーション、老朽化したインフラ、データ保管場所の分散、ポイント・ツー・ポイントの統合、などに経営資源を食い荒らされ、３ＰＬはそのギャップを埋められずにいる。
　しかし、朗報がある。
オープンビルドで柔軟な統合プラットフォームが登場し、サプライチェーンの計画・実行に使用しているアプリケーションとテクノロジーを、荷主と３ＰＬがともに統合・最新化する環境が整いつつある。
■課題 ──レガシーシステムがカネを食う　�
稗圓鬚瓩阿觝Ｆ釮硫歛蠅蓮�甬遒療蟷颪� 原因となっている。
　�
械丕未梁燭�魯瓮ぅ鵐侫譟璽爐筌潺奪疋譽� ジシステム上に、レガシー（旧来の）システムであるＥＲＰやアプリケーションを走らせている。
そして企業の吸収合併によってシステムは一層複雑になっている。
その結果３ＰＬは、ＩＴ向け経営資源の大半を現行システムの維持に割かざるをえなくなっている。
　レガシーアプリケーションの刷新で難しいのは、誤っていたり重複していたりするデータが、複数のデータサイロに分散していることが往々にしてあることだ。
　�
械丕娘�箸�△△襪い魯僉璽肇福爾肇如� タ統合をする場合は通常、他の私企業が所有権を持つプロトコルやレガシーＥＤＩ（電子データ交換）の標準規格がベースになる。
荷主側も同様にレガシーテクノロジーに経営資源を振り向けざるをえないことが、統合の足かせとなる。
　荷主も３ＰＬもビジネスニーズにいち早く対応でき、しかもコスト増無しですぐに効果が出るＩＴを求めている。
投資済みのシステムを強化する一方、イノベーションに貢献するソリューションの開発に、より多くの資源を充てたいと考えている。
　しかしそれは容易なことではない。
コンサ第3回　荷主は３ＰＬに、どのようなIT対応力を期待しているのか。
３ＰＬはその期待にどこまで応えられているのか。
期待と現実のギャップが生まれる原因は何か。
グローバル企業に対する広汎なアンケート調査から現状を分析し、問題解決の糸口を探った。
米キャップジェミニ・コンサルティング 57　　MARCH 2010 ルティング会社トンプキンス・アソシエイツのジーン・ティンドールはこう語る。
「問題となるのは将来的なアーキテクチャーのあり方だ。
アーキテクチャーを自分たちの戦略とリンクさせるにはどういう質問をしたらよいかということさえ、３ＰＬと荷主の多くは理解していない」　�
稗圓老弍沈鑪�鮗孫圓垢襪里坊萃蠹�� 役割を果たす。
戦略との連携が欠けていると、成長のエンジンとなるどころか、ＩＴのプラットフォームとインフラがボトルネックになってしまう。
サプライチェーンにおいて情報を管理することは、実際のモノの流れを管理するのと同等の重要性があるのだ。
　ところが三分の二以上の荷主は、自分たちのビジネスとＩＴとの連携の現状について否定的にとらえており、十一％が不十分、五八％が改善の余地ありと答えている。
同様に３ＰＬは不十分が八％、改善余地ありが五三％だった。
　いまひとつは、３ＰＬのＩＴの組織を集約するか分散させるかという問題である。
集約派は管理・コストの可視性、アプリケーションとインフラの標準化、といった点で有利であり、したがってビジネスプロセスの標準化が進むという。
分散は逆にインフラの複雑化、可視性の低下、コスト増、ＩＴ管理とビジネスプロセスの標準化の欠如、などを招くと主張する。
　�
械丕未呂垢任砲海離瓮奪察璽犬鬚④舛鵑� 受けとめている。
アプリケーションは統合されていたりしなかったりだが、八七％はＩＴの組織を集約していると回答している。
■ＩＴアウトソーシング ──�
械丕未浪燭鯆鷆，掘�拏腓浪燭� 利用するのか　おそらく３ＰＬ側のＩＴへの対応力不足が知れわたった結果だと思われるが、荷主は対顧客・計画アプリケーションを自ら運営する傾向にある。
　図１にあるとおり、受注管理は荷主の九四％、サプライチェーン計画については九一％が自社運営であり、外注をしているのはそれぞれ五％、四％である。
現在は自社で運営しているが可能であれば外注したいと考えている割合も、やはりそれぞれ五％と四％にすぎない。
　トランスポーテーション・ソーシングは全体の三分の一以上、三五％が外注しているが、将来的に検討すると答えた割合は十二％だけである。
　しかし実行系、ＥＤＩのホスティング、メッセージサービス、サプライチェーンの可視化を実現するアプリケーションなどについては、現在外注しているか、もしくは検討している荷主の数が増えつつある。
　荷主が正確な情報にもとづいて意思決定をするには、これまでの常識に頼るのではなく、３ＰＬのＩＴ対応力を適正に評価することが必要となる。
たとえば、３ＰＬが提供するウェブベースのソリューションを利用すればコストが下がるのに、すべてがパッケージされた統合ソリューションがいいということで提案が却下されるケースが数多く見られる。
また経済状況もアウトソーシングと自社管理のバランスを見直す契機になる。
　�
稗團▲Ε肇宗璽轡鵐阿蓮散綰��僴�� 〇年と一一年にはさらに伸びると予想されて図1　ロジスティクス・アプリケーションを管理するのは誰か？受注管理 5 94 5 サプライチェーン計画可視化（オーダー、配送、在庫、その他） EDI、事前出荷通知、インボイス作成サプライチェーン・イベント管理サプライチェーン・ネットワークの最適化ブッキング、オーダートラッキング、在庫管理、請求などのためのウェブポータブルトランスポーテーション・ソーシング 0％ 20％ 40％ 60％ 80％ 100％ 4 91 4 19 79 12 22 75 19 13 72 14 13 72 18 21 60 22 35 59 12 3PL に外注自社で運営可能であれば外注に MARCH 2010　　58 のことは、設備・ＩＴシステム・従業員なども含むロジスティクス全体をまるごとアウトソーシングするという大きな流れと合致している。
■懸案事項 ──荷主と３ＰＬはどう考えているか　�
械丕未陵諭垢淵▲廛螢院璽轡腑鵑��腓� れていないということは、ネットワーク内でオーダーや輸送のグローバルな可視性がないことを意味する。
荷主と３ＰＬはともに、この統合不足をＩＴに関する最大の懸案事項として挙げている（荷主側の回答は図３参照。
回答率は荷主が五五％、３ＰＬが五〇％）。
　その他の懸案事項を以下に挙げる。
●四二％の荷主が挙げる懸案事項の二番目は、パフォーマンスレポートが不十分なことである。
このことはおそらく、現行の技術では荷主が必要とする情報を完全には提供できていないという、より大きな問題にもつながるだろう。
●荷主と３ＰＬ両方が三番目に挙げるのは（荷主三八％、３ＰＬ二七％）、プロジェクトマネジメントにおける適切なプロセスの欠如や熟練担当者の不在である。
アウトソーシングをする際には、組織・ビジネスプロセス・ＩＴプラットフォームのすべてが同時に変わるため、３ＰＬ側は導入段階との約三分の一は、自分たちがロジスティクスの計画実行に使用しているＥＲＰやＴＭＳを採用するよう要請しており、四四％が荷主と同じＷＭＳを使うよう求めている。
荷主の生産工場付属の倉庫や既存の配送センターを任せる場合に、この傾向は特に顕著である。
　とはいえ割合からすれば、３ＰＬ独自のロジスティクス計画・実行アプリケーションの利用を容認する荷主の方が多い（四七％）。
こいる。
ティンドールはこう述べる。
「従業員の削減が進行したため、荷主の目はプロバイダーに向き始めている。
景気の落ち込みが底を打てば、需要は増えるだろう」　外注されるロジスティクスサービスでもっとも一般的なのは輸送と倉庫保管である。
したがって図２にあるとおり、３ＰＬの提供するアプリケーションで多いのが輸送管理（ＴＭＳ、七五％）と倉庫管理（ＷＭＳ、八一％）システムである。
　荷主側が、すでに統合されているか、あるいは他の３ＰＬのＩＴシステムと統合しやすいアプリケーションを利用している方が、３ＰＬにとっては都合がよい。
　また、荷主にとって替わりの３ＰＬを探すのはコスト負担になるため、いったん採用されれば長い付き合いになることが多い。
３ＰＬと深い結びつきを持たない荷主は、３ＰＬを選定する際にＩＴについてどれだけ任せるかを検討する必要がある。
　意外なことにサービス契約の一環として、３ＰＬが自社のＩＴプラットフォームをサブスクリプション・ベース（期間単位の契約）で提供する例が増えている。
こうした形で販売されるケースが多いのは輸送管理（計画、実行）、倉庫管理、可視化関連、受注管理などである。
現在では３ＰＬのおよそ一割が、こうしたサービスをサブスクリプション・ベースで提供している。
　統合を容易にするため、３ＰＬに対し荷主図2　3PL はどんなサービスを提供しているか倉庫／配送センター管理 9 81 12 輸送管理（実行）可視化（オーダー、配送、在庫、その他） EDI、事前出荷通知、インボイス作成バーコード付け受注管理ブッキング、オーダートラッキング、在庫管理、請求などのためのウェブポータブル輸送管理（計画） 0％ 20％ 40％ 60％ 80％ 100％ 10 75 14 16 71 11 15 71 11 13 70 11 18 63 12 23 62 10 16 62 15 将来的に提供予定すでに提供している特別な契約にもとづいて提供する 59　　MARCH 2010 ●３ＰＬが改善すべきもう一つの点は、見積もりから請求までの流れをスムーズにすることである。
様々なサービスの適正な見積もりをし、見積もり通りに実行し、そして実行したサービスの通りに請求を行うという、あたりまえのことではあるのだが。
　ここに挙げた懸案事項のすべてに共通することは、データを共有してビジネスプロセスをコーディネートしてより効果的なコラボレーションを実現するため、３ＰＬ側には輸送、在庫、その他のサービスを管理する内部システムを合理化して最新のものにすることと、統合のためにオープンな業界標準のツールを採用する必要があるということである。
荷主と３ＰＬの統合　荷主と３ＰＬがもっと緊密な協力関係を築く上で最大のハードルとなっているのは、データ共有までにかかる時間と手間である。
ＥＤＩ標準が存在するにしてもコンプライアンスという点では各社千差万別であるし、荷主と３ＰＬが違うバージョンを使っていることもある。
つまり統合には通常カスタマイズが必要となって統合と試行に長い時間がかかるが、それはすなわちコスト増を意味するのである。
　図４にあるように、荷主の半数以上が受発注・在庫確認・配送状況確認にＥＤＩを利用ころである。
データの質とタイミングの問題は通常、３ＰＬの複雑な内部システムが原因で生じる。
こうした３ＰＬはレガシーシステムを持つキャリアからデータを得る場合にも、統合問題に直面するだろう。
　　「３ＰＬのＩＴシステムの大半はまるでスパゲティの皿のようだ。
これでは長続きしないし、いろいろなギャップも存在する。
こうしたシステムでは正確な情報をタイムリーに得ることは不可能である」との声もある。
通常業務遂行段階の両方で、最新の注意を払ってアウトソーシング業務の計画実行を行う必要がある。
つまり３ＰＬは、プロジェクトの計画と管理の資格を持つ熟練した人材を、もっと採用しなければならないということである。
●３ＰＬの中にはオーダー、輸送、在庫などの情報さえ満足に提供できないところがあることは、荷主と３ＰＬがともに認めると図3　3PL のIT アプリケーションに対する荷主側の不満 55 42 38 38 30 26 26 24 3PL 自身のアプリケーションが統合されていないパフォーマンスレポートが不十分プロジェクトマネジメントのプロセスが不適切／熟練したPM 担当者の不在オーダー、輸送、在庫の可視化が不十分データがタイムリーに提供されない特別なサービスの見積もりが遅いデータの質が悪い利用サービスに対して正しい請求がなされない 0％ 10％ 20％ 30％ 40％ 50％ 60％受発注管理在庫確認配送状況確認輸送（ブッキング、申し込み、必要書類）送り状作成送り状作成生産スケジュール／配送スケジュール需要予測キャパシティ予測・アベリラビリティ 0％ 20％ 40％ 60％ 80％ 100％マニュアル（ファックス、電話、e-mail） EDI 独自規格標準規格受発注管理在庫確認配送状況確認輸送（ブッキング、申し込み、必要書類）生産スケジュール／配送スケジュール需要予測キャパシティ予測 0％ 20％ 40％ 60％ 80％ 100％マニュアル（ファックス、電話、e-mail） EDI 独自規格標準規格図4　3PL とのデータ共有：自動化or マニュアル、　　　カスタマイズor 標準規格？（荷主側）図5　荷主とのデータ共有：自動化or マニュアル、　　　カスタマイズor 標準規格？（3PL 側） 42 43 58 56 57 43 57 43 54 48 45 61 39 52 62 38 53 60 40 47 67 65 35 33 70 61 39 30 76 58 42 24 30 32 70 67 68 33 65 35 66 66 34 67 33 34 58 42 40 61 39 60 46 68 32 54 55 80 20 45 56 82 18 43 MARCH 2010　　60 る程度軽減することができる。
荷主と３ＰＬのコラボレーション　需要変動に素早く対応できる一方で在庫水準は低く保つという、アダプティブ（適応力のある）なロジスティクス・ネットワークの構築を目指す動きにともない、多くの荷主の目が３ＰＬに向けられている。
　その目的を達成するために荷主は、ロケーションやオーダー、配送の状況とともに、サプライチェーン全体の在庫に対する可視性を向上させる必要がある──サプライヤーのところには何があるか、生産中のものは何か、倉庫には何があるか、輸送中のものは何か、小売店の店頭に並んでいるものは何か、等々である。
　これは図６にも明らかである。
重要業績評価指標（ＫＰＩ）やその他の指標が望ましい範囲を逸脱した場合にいち早く対応できるよう、四分の三以上の荷主は３ＰＬにＫＰＩに関する情報を求めている。
　さらに計画外の配送とオーダーに関し、七一％がリアルタイムのレポートを、七〇％が注意の喚起を要求している。
?オートメーション化されたビジネスプロセス管理?といったより高度なサービスも結構だが、荷主は３ＰＬにまずは基本的なサービスの充実を求めるべきだろう。
　複雑な内部システムとデータの収集分析をほとんどマニュアルで処理することが原因で、備には一週間もあればこと足りると考えてしまいがちだ。
実際にデータを共有するのに、どれだけの時間がかかるかを認識せず、すでにインターフェースの準備は整っていると主張することで、こうした企業は３ＰＬ産業そのものに甚大な損害を与え、ＩＴに対する荷主との認識ギャップを拡大させる原因にもなってしまっているのである。
　こうしたマニュアルやカスタマイズでの統合にかかる時間とコストの問題は、オープンな標準規格ベースのツールを採用することであしている──こうした一般的な業務にしては低い数字であると思われる。
さらに、受発注にＥＤＩを利用しているうちの五七％は３ＰＬとの統合に標準メソッドを採用し、四三％はカスタマイズされたものを使用している。
　この割合は輸送状況確認も同様である。
スプレッドシート（エクセル等）、フラットファイル、ＦＴＰ（ファイル転送プロトコル）、その他の通信手段など、データ共有をマニュアルで行っている割合はまだまだ大きく、特に生産・輸送スケジュールと需要予測の分野で著しい。
　図５は３ＰＬ側のＥＤＩ利用の状況を示している。
荷主側の利用でもっとも多いのは受発注管理だが、３ＰＬでは三番目になっている。
３ＰＬで一番多いのは在庫確認である。
　発注書や運送書類などほとんどの一般的なドキュメントについて、３ＰＬの三分の二以上はＥＤＩを利用しており、標準規格を採用している割合が荷主よりもいくぶんか高い。
たとえば受注書については六七％の３ＰＬが標準規格のＥＤＩを利用しているのに対し、荷主は五七％である。
　販売プロセスにおいては特に、荷主と３ＰＬ双方が協力し合うことによってＥＤＩ統合のハードルを低くすることができる。
統合はとても大変なことだが、それは３ＰＬ側だけに問題があるからではなく、荷主側にも責任の一端がある。
　�
械丕未脇世討靴董▲ぅ鵐拭璽侫А璽垢僚� 受発注管理在庫確認配送状況確認輸送（ブッキング、申し込み、必要書類）送り状作成送り状作成生産スケジュール／配送スケジュール需要予測キャパシティ予測・アベリラビリティ 0％ 20％ 40％ 60％ 80％ 100％マニュアル（ファックス、電話、e-mail） EDI 独自規格標準規格受発注管理在庫確認配送状況確認輸送（ブッキング、申し込み、必要書類）生産スケジュール／配送スケジュール需要予測キャパシティ予測 0％ 20％ 40％ 60％ 80％ 100％マニュアル（ファックス、電話、e-mail） EDI 独自規格標準規格図4　3PL とのデータ共有：自動化or マニュアル、　　　カスタマイズor 標準規格？（荷主側）図5　荷主とのデータ共有：自動化or マニュアル、　　　カスタマイズor 標準規格？（3PL 側） 42 43 58 56 57 43 57 43 54 48 45 61 39 52 62 38 53 60 40 47 67 65 35 33 70 61 39 30 76 58 42 24 30 32 70 67 68 33 65 35 66 66 34 67 33 34 58 42 40 61 39 60 46 68 32 54 55 80 20 45 56 82 18 43 61　　MARCH 2010 リアルタイムの在庫状況（五三％）などが挙げられている。
　リアルタイムのオーダー・データがもっとあれば、３ＰＬは計画と実行に必要なより正確な情報を得ることが可能となり、二度手間や配送ミスが減る。
タイムリーな需要予測があれば、３ＰＬは荷主の必要に応じてしかるべき場所にしかるべきリソースを配することができる。
　デリバリーコストを削減するツールだけでなく、セルフサービス・ポータルのようなオートメーション化されたコラボレーションツールの開発にも、３ＰＬは力を入れている。
　荷主同様、３ＰＬ側も必要なデータの入手という点で課題を抱えている。
前出（連載第一回）の３ＰＬ、サドルクリーク社のブレイロック氏は「すべてのデータをシェアすることにとても前向きな顧客がいる一方、およそどんなデータも出したがらない顧客もいる」と指摘する。
　荷主がデータフォーマットの?独自規格?を開発し、それを３ＰＬに押しつけたため、３ＰＬ側の手間とコストを押し上げる結果になったケースもある。
■ＩＴ対応力のギャップを埋める ──荷主と３ＰＬはプラットフォーム・ストラテジーを採用すべきか？　�
械丕未裡稗埖弍�呂紡个垢覯拏臑Δ隆鋿� と実際の満足度には、常にギャップがあるこＬとの二五年にもおよぶ付き合いの中で、欠陥のない統合というのは見たことがない」と述べる。
　また、「パートナーは替わるものなので、我々にはフレキシビリティを保持していることが必要だ」という３ＰＬの意見はおそらく、投資をしてもその顧客を失うこともあるということを含意しているのであろう。
　図７は３ＰＬが荷主に求めるウィッシュリストである。
上から順に荷主側のオーダー管理システムへのリアルタイムのインターフェース（六三％）、タイムリーな需要予測（五四％）、３ＰＬが報告を提出するのに時間のかかることが往々にしてある。
これはしかるべきテクノロジーの導入によって解決しうる問題だ。
　しかし「ではそのテクノロジーには誰がカネを出すのか、という問題が持ち上がる」とティンドールは言う。
「共同で開発する例はほとんどない。
なぜ荷主と３ＰＬはもっと協力しあい、得た利益を分けあわないのだろうか？」　荷主が乗り気にならない理由のいくぶんかは、おそらく３ＰＬのＩＴ対応力に関するこれまでの経験にあるだろう。
ある荷主は「３ＰタイムリーなKPIとパフォーマンスデータリアルタイムのオーダーと配送の可視性計画外のオーダーと配送に対する注意の喚起リアルタイムの在庫状況（入庫・出庫・在庫）　正しい請求オートメーション化されたビジネスプロセス管理その他システム統合 0％ 20％ 40％ 60％ 80％図6　荷主は3PL に何を求めているか 75 71 70 56 55 52 32 2 荷主側のオーダー管理システムに対するリアルタイムのインターフェースタイムリーなインボイスの照合と支払いプロセスワークフロー管理を利用したコラボレーティブな計画と実行オーダートラッキングをする際のセルフサービス・ポータル利用の増加荷主側の経営層との接触リアルタイムの在庫状況タイムリーな需要予測その他 0％ 20％ 40％ 60％ 80％図7　3PL は荷主に何を求めているか 63 54 53 48 47 45 39 2 MARCH 2010　　62 　�
咤錬舛鰺�僂垢譴弌▲▲廛螢院璽轡腑鵑� デザインとリンクを様々に組み合わせていろいろなニーズに対応できる上に、共有基盤の標準化というメリットも享受できる。
投資したものがすべての３ＰＬと荷主の関係性に役立つため、誰も損をすることはない。
こうした開かれた扉、調和のとれた共通のプラットフォームが必要なのである。
　既存の３ＰＬのＩＴに起因する諸問題は、このアプローチである程度解決できる。
なぜならそれは３ＰＬと荷主を、オーダー管理、輸送計画と実行、トラックとトレース、という三つの重要なエリアで統合するからである。
その骨子、あるいは必要条件は次のとおりである。
●データ統合──正確な情報がシステム全体を一貫して流れる。
●秩序正しく配置されたプロセス──�
稗團� ロセスがビジネスプロセスに合わせて順序よく配置される。
●例外管理──想定外の事態を顧客に通知する。
も固有のＩＴ要件を満たすために自分たちのリソースを投入することに、３ＰＬ側は躊躇する。
一方荷主側は荷主側で、特定のプロバイダーとあまりにも深い関係になることには抵抗がある。
　徹底的にオープンなデータ共有によってすべてが白日の下に曝されることには、双方とも不安を持つ。
３ＰＬは価格を叩かれ、荷主はコントロールを失うというわけだ。
　�
械丕未�諭垢頁塾呂鮖�辰討い討癲�拏� は進んでそれにカネを払おうとはしない。
これは必ずしも利用可能なＩＴサービスにギャップがあるのではなく、荷主がタダで利用したいと思うものと３ＰＬが提供したいと思うものとの大きなギャップなのである。
　しかしこの袋小路から抜け出す道がある。
グローバルで、フレキシブルで、標準化された、産業の垣根を越えるＩＴプラットフォームである。
　図８に模式化したこのアプローチは、既存のアプリケーションを強化する一方、３ＰＬが新しいアプリケーションを開発・実施するのにも役立つもので、すべてサービス指向アーキテクチャ（ＳＯＡ）を利用するオープン・インダストリー・スタンダードである。
　これによって３ＰＬは、一つのプラットフォームから複数の顧客に複数のサービスを提供することが可能になる。
同様に荷主側は一つのプラットフォームを通じ、複数の３ＰＬから様々なサービスを受けることができる。
とをこれまで詳しく見てきたわけだが、ギャップの埋まらないいくつかの理由が明らかになった。
　つまるところそれはお互いの信義の問題だと言ってもよい。
双方とも限られたリソースを持ち寄って関係性が生まれ、そしておそらくは虫のいい話なのだが、ギャップを埋めるための投資は相手側がしてくれることを期待する。
　いつ逃げられるかわからない相手の、しかロジスティクス計画＆実行プラットフォームパートナー・ポータル、アプリケーションのユーザーインターフェース、エッジ・デバイスエンタープライズSOA、ワークフローマネジメント、イベントマネジメントアプリケーション、データハブ、インフラサービス１サービス２サービス３顧客１顧客２顧客３見積もり─キャッシュ、調達─支払いといった重要プロセスを処理するビジネスプロセス・プラットフォームをSOA を利用して作り上げるリンクシステム顧客、パートナー、サプライヤー、監督官庁とのコラボレーションハブを通じた効率的なコラボレーションプラットフォームの特徴 ●ベストオブブリード・ソリューションのサポート ●変更可能なコンフィギュレーション ●レガシーアプリケーションを強化 ●インダストリー・スタンダードのサポート ●拡張可能アプリケーション、データレポジトリ、インフラなどの最適化・最新化図8　荷主と3PL はプラットフォーム・ストラテジーを採用すべきか？ ©2009 C. John Langley, Jr., Ph.D., and Capgemini U.S. LLC. All rights reserved.