ロジビズ :月刊ロジスティックビジネス
ロジスティクス・ビジネスはロジスティクス業界の専門雑誌です。
2010年3号
米3PL研究
第3回 3PLのITは荷主の期待に応えているか

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

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

購読案内広告案内