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

3PL 再 入門 梶田ひかる　高崎商科大学 特任教授 トランコム（株） ロジスティクスソリューションアドバイザー 《第　 回》 　サプライチェーン改革のポイントは2つある。
物流データ分析と部門間調整だ。
3PLやSCMコ ンサルタントにそのサポートを期待することはで きる。
しかし、効果を一時的なものに終わらせ ないためには、荷主が自身で改革の主導権を握 り、取り組みを通じて社内にSCM人材を育成し ていく必要がある。
MARCH 2013　　68 ＳＣＭの組織体制 　�
械丕未鯑各�靴燭蕾拏腓離蹈献好謄��紘� 門は不要になるのだろうか。
その答えは「否」 である。
その理由の一つとして、外部委託の 管理という観点から荷主のロジスティクス部門 が必要であることは本連載で既に述べた。
　そのほかに、もう一つ理由がある。
我々が 過去にロジスティクス管理と呼び、今ではサプ ライチェーン・マネジメント（ＳＣＭ）と呼ん でいる管理の対象範囲は、物流システムの管 理だけではない。
　物流がロジスティクスに変わった時点で、そ の管理範囲に全社在庫の適正化、つまり生 産活動と営業活動を同期化するための需給管 理が加わった。
それが進んで現在はサプライ チェーン上に一切の聖域を設けず、物流コス トの低減や在庫適正化を推進する施策を検討・ 実施することが必要になっている。
サプライ チェーン全体の企画である（図１）。
　この「物流システム管理」「需給管理」「サプ ライチェーン企画」の三つは、それぞれ必要 なスキルが異なっている。
そして過去にロジス ティクス管理と呼んでいた範囲のうち、３Ｐ Ｌ事業者に委託できるのは、物流システム管 理のみであり、残りの部分については荷主が 自社内で行う必要がある。
　そのため欧米における大手消費財メーカー のＳＣＭ部門の組織構造は、多くが図１に準 じた形態を取っている。
扱う製品によっては、 さらに調達部門、受注部門、顧客サービス部 門をＳＣＭ部門の傘下に配することもある。
　日本においても大手消費財メーカー等で同 様の組織構造の導入が始まっている。
ただし、 中堅以下の企業の管理組織は、ほとんどが従 来型のままであり、また大手であっても、Ｓ ＣＭ管理が十分に機能していないケースが目 立つ。
　それでは、どうすればＳＣＭを機能させる ことができるのであろうか。
物流システム管 理を中心とした従来の管理組織を、需給調整、 さらにはサプライチェーンという観点で全体の 効率化を検討する組織へと進化させることが 3 サプライチェーン改革のカギ 図1　サプライチェーン管理の機能 サプライチェーン管理 物流システム管理需給管理サプライチェーン全体の 企画 物流システムの改変と 円滑な運用 ●デイリーオペレーション ●トラブル発生時の対応 ●業務品質の向上 ●業務コストの低減 在庫の適正化 ●需要予測 ●生産と営業の調整 ●生産量決定 企業全体での効率化 ●コスト低減余地の検討 ●関連部門との調整 ●SCM施策の決定 ●SCMプロジェクト管理 69　　MARCH 2013 できるのであろうか。
　その鍵は二つある。
物流データ分析（図２） と部門間調整である。
またそれを担うことの できる人材である。
その重要性を筆者が長年 手掛けてきたＳＣＭコンサルティングのプロセ スに沿って見てみよう。
　一般にＳＣＭコンサルティングは以下のよう なプロセスを踏む。
?経営企画部門、物流部門、経理部門、情報 システム部門などから成るプロジェクトチー ムを組織する。
?物流に関するデータ、すなわち入出庫、在 庫、輸送実態およびそれらに関するデータ を分析し、実態の概略を理解する。
?把握された課題について関連部門にヒアリ ングを行い、原因を分析して仮説を立てる。
?再度、物流データ分析を行い、仮説を検証 する。
仮説が正しい場合には、それによる 財務的インパクトを算出する。
物流データ を加工してシミュレーションを行うことによ り、施策ごとの財務効果を算出する。
?施策ごとの財務効果に基づき具体的な活動 計画を検討する。
　一連の分析結果はステップごとにプロジェク トチーム内で共有して、コンセンサスを得なが ら施策を固めていく。
そして活動計画とその 財務効果を経営トップに報告することで、トッ プは施策の必要性を理解し、関連部門にその 実施を指示する。
そこからＳＣＭ高度化に向 けて全社が動き始めるのである。
多く見られる失敗パターン 　ただし、施策を着実に実施するにはそれな りの時間が掛かる。
大掛かりな改革となると 三年にも及ぶこともある。
そのため通常は改 革の専従要員が割り当てられて、関連部門を 巻き込んだ施策の実施、実施状況のチェック、 問題発生時の早期把握、それへのアクション という一連の管理サイクルを回す。
そのポイ ントがデータ分析と部門間調整の二つであり、 それを担うことのできる人材がそこで必要に なるわけである。
　物流データ分析と調整人材を欠いたＳＣＭ の取り組みは、ほぼ間違いなく失敗する。
そ の代表的なパターンを二つ紹介しよう。
　一つは在庫適正化を目的とした取り組みで ある。
高額なＳＣＰ（サプライチェーン・プ ランニング）パッケージを導入したものの、期 待したような効果が得られず、やがてシステ ム自体が使われなくなってしまうというケー スである。
パッケージを導入しさえすれば需 給問題は解決すると安易に考え、それまでの 販売計画、生産計画、調達計画のやり方を変 えないままだと、そうなってしまう。
　在庫を適正化するにはパッケージを導入す る前にやるべきことがある。
まず現状の在庫 量の把握である。
次に在庫が過剰なアイテム あるいは欠品率の高いアイテムについて、そ の原因を調べる。
そして、なぜそうなったの か、理由を生産部門と営業部門にヒアリング する。
　次に、生産の言い分と営業の言い分が、本 当に正しいのかどうかを判断する。
それぞれ の言い分ごとに、それによる在庫の過剰分や 欠品量などを調べ、その財務インパクトを算 出する。
　過剰在庫を発生させている原因の多くは、 生産部門や営業部門にある。
そして物流以外 の問題で過剰在庫が発生し、それによって倉 庫スペースが狭隘化し、借庫や横持ち輸送が 図2　物流実態データ分析とサプライチェーン管理 サプライチェーン管理 物流システム管理需給管理サプライチェーン全体の 企画 物流データ分析物流データ分析物流データ分析 ●作業（輸送）実態分析 ●物流システム変更時 の各種シミュレーション 等 ●過剰在庫、不動在庫、 欠品の抽出と原因の 特定 ●在庫管理方式のシミュ レーション等 ●仮説における問題の 大きさの数値化 ●施策案の効果シミュ レーション ●施策の効果測定等 入出庫データ　輸送データ　在庫データ 物流実態データ 発生している、あるいは作業生産性の低下な どが起きているのなら、プロジェクトチームや ＳＣＭ部門は他部門に業務のやり方を変えて もらわなくてはならない。
　それには原因を作った部門にその事実を数 値で示すことが解決の第一歩となる。
それも コストで示すのが望ましい。
また取り扱い製 品やその販売量は頻繁に変わるため、管理体 制は常に維持しておく必要がある。
こうした 需給調整を機能させるには、データ分析と関 連部門間の調整を行える人材がどうしても必 要になるのである。
　良く見られる失敗の二つ目は拠点集約であ る。
近年では３ＰＬ事業者が荷主に対して 拠点配置や輸送手段などの物流システム再構 築を提案することが多くなっている。
今日の ３ＰＬの代表的ソリューションとも言えるが、 いわゆる?任せっぱなし?では不幸な結果を 招いてしまう。
　拠点集約はコストとサービスレベルのトレー ドオフ問題を避けて通れない。
拠点を集約す れば安全在庫の水準は下げられる。
しかし、 その一方で時間指定配送や緊急配送への対応 力など、物流サービスレベルの低下するエリア が出てくる。
　拠点集約に伴い営業所から在庫が切り離さ れることも、よく問題になる。
新体制が完成 する間際、ひどい場合には稼動した後になっ て、営業所で在庫を確保することができなく なったことの影響に気付き、「これでは売り上 げが減ってしまう」という反対の声が上がる。
　この問題への対処もやはり物流データ分析 と関連間調整が鍵を握っている。
　それまで営業所ごとに倉庫を置き在庫を持っ ていた場合、顧客別の物流サービスレベルは 担当者任せになっていて書面化されていない ことが多い。
それを調査するのは３ＰＬを利 用している場合でも荷主側の役割になる。
　その他にも、担当者が抱えている在庫の実 態を調べる、営業に納品先との交渉を行って もらう、拠点集約が売り上げに与えるインパ クトを算出してコスト削減額を比較する等々、 荷主側でやるべきことは多い。
　このようなことから、改革の早い段階でデー タ分析のスキルを持った情報システム部門出 身のスタッフを物流管理部門に異動させたり、 改革チームに投入しているケースは多い。
物流データ分析要員の空白地帯 　部門間の調整役は企業規模がそれほど大き くない場合には社長自身が担うこともある。
問題となるのは分析スキルを持った人材の確 保である。
　分析と言うと定型的な分析表を思い浮かべ る人もいるかも知れないが、ここで言う分析 とは、データを様々な角度から見て、問題を 探ったり、仮説を検証したり、シミュレーショ ンを行う作業であり、非定型のものが圧倒的 に多い。
　大企業であれば社内にそうしたスキルを持っ た人材を見つけることもできるはずだが、日 本ではそのような人材がＳＣＭ部門に配置さ れていないことが多い。
中堅以下の企業とも なると、スキルを備えた人材を社内に確保す ること自体が難しくなる。
　物流システム管理に関するデータ分析だけ であれば３ＰＬに作業を委託することもできる。
しかしながら、前述のように需給管理、サプ ライチェーン全体の企画におけるデータ分析は 外部委託できる領域から外れている。
　�
械丕未僕蠅襪海箸呂任④此⊆卞發某雄爐� いない。
すなわち現状では、データ分析要員 MARCH 2013　　70 3PL 再 入門 図3　3PLとサプライチェーン管理 サプライチェーン管理 物流システム管理需給管理サプライチェーン全体の 企画 物流データ分析物流データ分析物流データ分析 Plan（計画） Do（実行） Check（k（実行） Ac（t 改善） Plan（計画） Do（実行） Check（k（実行） Ac（t 改善） Plan（計画） Do（実行） Check（k（実行） Ac（t 改善） 物流実態データ 多くの荷主が想定 している荷主の範囲 3PL 事業者の範囲 の空白地帯がある（図３）。
そのことが荷主 と３ＰＬの双方において、ＰＤＣＡサイクル を回していく上での大きな障壁となっている。
　現状では外部のＳＣＭコンサルタントがそ の穴を埋めている。
しかし、プロジェクトの 終了と共にコンサルタントたちは荷主の元から 去っていく。
その後も物流は新商品の発売や 終売、新たな納品先の追加、取引先の変更な ど、様々な要因で常に変化する。
そして変化 は常に新たな問題を引き起こす。
それを分析 できる人材がいないと、再び在庫は増加し、 物流コストが上昇してしまう。
　もっとも、分析手法はＯＪＴで学ぶことが できる。
コンサルティング期間中に社内のス タッフがコンサルタントの分析のやり方を横で 見て習得するのである。
本人に多少の素養と きっかけさえあれば、手取り足取り教育され なくても、自力でスキルを向上できる。
実際、 そのようにして社内人材を育成し、コンサル タントに頼らずともＳＣＭプロジェクトを進め られるようになった会社を筆者はいくつか知っ ている。
荷主が主導権を握れ 　また筆者が現在ソリューションアドバイザー を務めているトランコムでは、「ワンストップ ３ＰＬ」と呼ぶソリューションの一環として、 物流システム改変の検討開始時からシステム の安定稼動までの期間における物流データ分 析支援を行っている（図４）。
　物流コストを上昇させている原因は何なのか、 物流システムの変更が物流コストにどう影響 するのか等をきめ細かく分析して荷主に提供 している。
　あくまで３ＰＬの導入に付帯するサービス であって有償のコンサルティングではないため、 分析の範囲や内容は限定されるが、それらを 活用すればトータルコスト低減に向けた検討を 行うことができる。
そこから分析スキルを習 得することもできるはずだ。
　「物流から会社を変える」というアプロー チは極めて有効である。
物流には社内の諸問 題が現れるからである。
そして問題の原因は 多くの場合、社内の物流以外の部門にある。
従って物流コストを大幅に低減したいなら、 物流以外の他部門を動かす必要がある。
それ を３ＰＬに頼ることはできない。
　�
械丕未鰺�僂垢襯瓮螢奪箸琉譴弔蓮△修� によって浮いた社内のリソースを、需給管理、 さらにはサプライチェーン全体の企画の充実に 当てられることである。
そして荷主と３ＰＬ との協働でトータルコスト低減に向けた施策を 検討することにより、着実な効果が期待でき るようになる。
　大規模な改革となるが故に、取り組みのリー ダーシップは荷主の経営トップもしくはそれ に準ずる人物が取ることが望ましい。
荷主が ＳＣＭ改革を主導すること、それが３ＰＬを 活かす方法なのである。
71　　MARCH 2013 梶田ひかる（かじた・ひかる） 　1981年南カリフォルニア大学OR理学修 士取得。
同年日本IBM入社、91年日通総合 研究所入社。
2001年デロイトトーマツコン サルティング入社（現アビームコンサルティ ング）。
11年4月高崎商科大学商学部特任 教授。
同月、トランコム（株）のロジスティク スアドバイザーに就任。
現在に至る。
中央 職業能力開発協会「ロジスティクス管理２ 級・３級」のテキスト共同監修のほかSCM 関連の著書多数。
図4　トランコムにおける物流データ分析サービス サプライチェーン管理 物流システム管理需給管理サプライチェーン全体の 企画 物流データ分析物流データ分析物流データ分析 Plan（計画） Do（実行） Check（k（実行） Ac（t 改善） Plan（計画） Do（実行） Check（k（実行） Ac（t 改善） Plan（計画） Do（実行） Check（k（実行） Ac（t 改善） 物流実態データ