SCM、

248 デルスタイルをシステムにすれば

06:物流システム

物流システム奮闘記

前回のデルコンピュータの仕組みをシステム的にイラスト化します。

システム的にもっと細かくデータの流れを記載できますが、細かすぎないほうが分かり易いと思いこの程度にまとめました。内容はイラストの通りですが、簡単にコメントをします。

デルスタイル


まず、我々消費者がインターネットを利用して、オンラインショッピングを行います。

昨今はデルに限らず受注生産方式のサイトは無数にあります。
お手軽なところでは、ハンコ屋、表札屋、名刺屋などもそうですね。
中には花屋だってサービス提供しています。何でもサービスありの時代ですね。

これら全て スケールは小さいながら、BTO(Build to Order)の一種です。

デルのサイトを見れば分かりますが、注文してから僅かな日数で製品が手元に届きます。
近所の電気店で購入するのと大差ありません。

必要最低限の部品を確保し、新たな部品調達が発生しても 僅か1~3日、組み立てを入れても部品から製品に於ける在庫期間は10日もありません。(なかには8日と記載されているサイトもあります)

注文してから出荷するまでが10日の意味じゃなく、棚卸資産が10日ってことです。注文してから納品までなら僅か数日です。

生産指示も1日に何回も行います。これにより正確な生産計画が行われます。

成功の決め手はITです。
データ化されていなかったら絶対実現不可能です。
この大規模なシステムを回転させるには裏方の物流業者もかなり大変なことでしょう。


これだけ在庫期間が短いと凄いことがおきます。
お金が出て行くスピードより、入って来るスピードの方が早いのです。

サイトには、サービス体制24時間365日テクニカル電話サポート、必要とあらば即座に出張修理します・・・とのこと。(ホントかいな。まさに本当だったら凄いことです。)


(おまけ)
最近、某メーカーのレーザープリンターが故障しました。
コールセンターとのやり取りの末、修理に出すことになりました。
持って歩ける大きさのプリンターではありません。修理センターも関東にありません。

困ったあげくメーカーに相談すると、メーカーから大きな返却用カラ段ボール(中には緩衝材付き)が送られてきて、それに入れて配送業者(黒ネコさん)が修理のため往復をする。
こんな感じになりました。

なるほど・・・比較的大きな機器なら便利です。実に便利な世の中になりました。

このメーカー対応に感激し、次の購入もこのメーカーにしようと思っています。

247 需要予測を3つのptnに分けるHP社の調達管理

06:物流システム

流通システム/物流システム徒然記

ヒューレット・パッカード社の話をしていますが、正直言ってヒューレット・パッカード社を良く知りません。HP社は良く知りませんが、IBM社なら少しだけ分かります。

大型汎用機全盛時代のIBMは物凄かった。
20年以上前の話になりますが、千葉の幕張にある日本IBMに何度か仕事で行ったことがあります。とんでもなく素晴らしい環境です。

但し、『ここで生き残るのは半端じゃないだろうなあ』と思ったものです。のびのび生きるか?、激務のなか高収入で生きるか?


月間ロジステック・ビジネスさんの資料によれば、IBMは世界中に3万数千のサプライヤーと4万数千のビジネスパートナーが年間7万8千に及ぶ製品に対して、OSやファームウェア、アプリケーションの各種設定を行い、年間90万トン超の製品(もしくは部品)を移動しているとのこと。

世界最大規模のSCMを行っている企業の一つですが、この数値はイメージ出来ません。最盛期のIBMの勢いは無いものの、その規模はまだ半端じゃありません。

ヒューレット・パッカードのSCM


IBMのSCMは別の機会にして、ヒューレット・パッカードのSCMに戻ります。

当然ですが、HP社の製品の多くは下請け工場で作られています。よって製品をいくつ作るかは非常に重要です。

俗に言う需要予測の判断ミスが、会社に大きな影響を与えます。需要予測の判断ミスで会社は潰れたコンパックコンピュータがその見本です。

HPはこの需要予測を3つのパターンに分けて外注先管理を行っています。この3つのパターンを上手くコントロールしています。

場合によっては、下請けを飛び越して、孫・ひ孫請け会社とも直接取引きしたりもします。
HP社が下請けを通さず 孫・ひ孫請け会社に直接発注したりするなんて、日本の古い企業だと考えられません。

但し、実際の流れは下請けを経由して流通に流れます。
この手法はメリットが沢山あります。


参考文献:月間ロジステック・ビジネス

246 5つのSCMモデルを持つHP社の物流戦略

06:物流システム

流通システム/物流システム徒然記

さて、前回からの続きです。ヒューレット・パッカード(HP社)のSCM戦略はどのような仕組みなのか?

まず、SCMという言葉が何度も登場していますが、このSCMの意味は、当ブログの [ 010 在庫削減の成功は取引先との協力 ][ 011 SCMの改革は自分の会社から ] などを参照して下さい。言葉の意味だけでも理解しておいて下さい。


ものを製造して運んで店頭に並べるまでには、幾つかのパターンがあります。
日常雑貨や食品など取り扱っている企業なら1つのパターンでも間に合います。
しかし、HP社のように取扱い製品種類が多い企業は無理な話です。
個人向けパソコンと企業向けサーバー製品とは製造工程も流通ルートも異なります。

さりとて、取扱い製品毎にSCMを作るとなると、数百のSCMパターンが出来てしまいます。そこでHP社はザックリ5つのモデルに分けてます。全ての製品をこの5つのどれかに当てはめています。

HP社の5つのSCMモデル
HP社の5つのSCMモデル


勿論、どれにも属さない製品は発生します。
どんな企業でも例外モデルは発生します。単一製品でも例外は発生します。
しかし、大抵の企業は例外もそのモデルの中に取り込んでシステム化します。
業務の効率化を考えるなら例外を認めていると商売にならないからです。


図を上から簡単に説明しましょう。

ノータッチモデル:下請け会社が作った製品をそのまま流通ルートに乗せる方式

ロータッチモデル:下請け会社が作った製品をさらにHPの物流センターで手を加えて流通ルートに乗せる方式

ダイレクトモデル:直販モデル、注文されて組み立てる方式
ビジネスモデルとしてデル方式があります

ハイバリューソリューションモデル:企業向けモデル ハードウェアだけを売るのでは無く、ソフトや各種サービスを加えての販売モデル

メンテナンスモデル:修理やサポート、これも独自のビジネスモデルとして形成されています

「 たった5つで成り立つの? そんな単純な訳ないでしょ? 」
勿論、そんな単純じゃありません。
モデルそれぞれは更に大きなシステムとして複雑に機能しています。まあ、大雑把にイメージして下さいな。


要は製品に応じてSCMモデルを作り、そのモデルに合わせてシステムを構築しています。
言うは簡単ですが、これを実際にシステムとして機能させるとなると、どれだけ大変か賢い皆様なら十分お分かりになると思います。(と言って解説を逃げます)

下請け、工場、物流センター、3PL企業、販売店が上手く機能しています。これぞITならではのSCMです。仕組みを知れば知るほど凄いもんだと感心します。


参考文献:月間ロジステック・ビジネス

245 売上げ10兆円のHPの物流戦略

06:物流システム

流通システム/物流システム徒然記

ヒューレット・パッカード社の売上げの半分以上は、物流関係に投じられています。
更にその物流関係の中でもSCMに投じられているのですが、これは一般企業が物流関係に投じる比率としては驚く数字となっています。
しかし、そうでもしなければ、超大量の製品は安心して世界の店頭に置けません。

前回に触れた内容を再掲すると、取り扱い製品は20万SKU(部品種類が20万種)、毎年650の新製品の投入
コンピュータ(PC,サーバー)が1日10万台、プリンターが1日15万台、プリンターのインクカートリッジになると1日100万個の出荷

ちょっと、どの位の量になるのか想像出来ません。

HPの製品群
ヒューレット・パッカードの製品群


そのHPの年間売り上げは、どの位だか分かりますか?
そうだな~想像もつかないけれど・・・日本円で8千億とか9千億円くらいかな? それとも1兆円くらい行くのかな?
なかなか鋭いです。実態を知らない人なら、皆目分からない値です。惜しいかな1桁足りません。

HP社の売上げは、円換算で10兆円規模の企業です。

前回にも触れましたがHP社と言えば、我々には (1)パソコン、(2)プリンターが有名です。
しかし、売上げで言えば (3)企業向けサーバーやシステムソリューションの方が断然大きいのです。
(3)のシステムソリューションって何?
説明すると長くなるけど、簡単に言えばシステム構築と言えるかな。

ハードとソフトを組み合わせてシステム構築するのは、HP社でなくとも儲かる商売なのです。裏を返せば企業がシステムを構築することは、非常にお金が掛かることを意味します。システム規模によっては数千万円、数億円は簡単にかかります。

これら開発費の多くは技術者の人件費です。
勿論、サーバー等のハード費用も相当の額になりますが、長い目で考えれば人件費です。
HPが凄い凄いって書いていますが、ここにトヨタさんの物流も持ち出すと更に面白いかもしれません。

全然関係のない裏話ですが、昔トヨタ系列会社にシステム提案をしたことがあります。お会いする相手は全て日本人ですが、提案書は全て英文でメールのやり取りも英語でした。

何故?と思ったものです。
しかし、メールに参加する人も提案書を読む人も日本人だけじゃないからのようです。
やはり世界のトップ企業は違います。
最近、社内公用語を英語にする会社が話題になりましたが、確実に時代は国際化しています。

さて、HP社のSCM戦略はどのような仕組みなのか?

244 ヒューレット・パッカードと世界物流

06:物流システム

今年早々の日経新聞(1月22日)のトップ記事に、パソコン部門「NEC、レノボと合併」なるちょっと驚くニュースが登場しています。
大型汎用機時代に世界を席巻したコンピュータの巨人IBMのパソコン部門は中国企業(聯想集団=れんそうしゅうだん)に買収されました。
今度はNECのパソコン部門か・・・(注)NECのブランド名は存続します

PC98シリーズで日本国内を独占し最盛期を知っている我々にとって、かなり寂しい感じさえします。
EPSONが互換機を出した頃の強気な発言が、今は昔となってしまいました。



流通システム/物流システム徒然記

冒頭に記載したパソコンシェアをグラフ化しました。

パソコンシェア
2011年1月22日 日経新聞のデータ値より


ここで登場する世界トップのヒューレット・パッカードについてちょと触れます。
かなり規模の大きい話になります。

ヒューレット・パッカードと言えば、(1)パソコン、(2)プリンター、(3)企業向けサーバーやシステムソリューションとして有名です。
消費者の我々にとっては、パソコンやプリンターに馴染みがありますが、売上高で言えばサーバーやシステムソリューションの方が断然大きな売上げです。

ヒューレット・パッカードと世界物流


ご存知のようにコンピュータの寿命って非常に短くて、3ヶ月で新製品投入しなければいけない厳しい業界です。何でそんなに新製品投入しなければいけないの? 疑問さえ感じます。

そこで働く社員も大変です。
知人にHPの社員がいますが、『お金はもっと少なくていいから、ゆとりが欲しい』 とか 『あと5年ここで在籍しているとは思えない・・・』と言っておりました。
若い頃は良く飲みに行きました。彼と合コンに参加したこともあります(笑)。まあ昔の話ですね。


それはさておき 2~3年前の古いネタになりますが、物流専門誌LOGI-BIZさんの情報によれば、HP社の取り扱い製品は20万SKU(部品種類が20万種)、毎年650の新製品の投入とのこと。

コンピュータ(PC,サーバー)が1日10万台、プリンターが1日15万台、プリンターのインクカートリッジになると何と1日100万個の出荷があるそうです。

これだけ大きな規模になると物流も半端なシステムでは成り立ちません。
3PLとして100社以上の企業が参入しています。ここで登場する3PL企業はどこも大手企業ばかりです。

ともあれ、こんな巨大な取扱い製品をどうやって正しく管理コントロール出来るのか?
厳しい生産管理と在庫管理が待ち受けているであろうことは、容易に分かりますが。

032 データモデリング

06:物流システム

物流システム徒然記

さて、EDIとして一番代表的な入荷予定データと出荷指示データを取り上げました。
勿論、他にも各種データは必要です。

それら最低限必要なデータは、前回の業務流れ図を参照して下さい。
この青い矢印がEDIとしてあれば便利なデータです。

入荷予定データは、入荷した貨物をチェックすることで在庫データ更新します。
同様に、出荷指示データは、出荷する貨物をチェックすることで在庫データを更新します。

結局は、入荷と出荷のやり取りで在庫は増えたり減ったりします。
それを管理するのが在庫管理となります。
仕組みだけ言えば非常に簡単な話ですが、在庫管理が難しいのは実際の荷物とデータ差異が生じることにあります。
現実の世界では それが複雑に関連するので、少しでも管理を怠ると収拾不可能なことになります。

データモデリング
各種データモデル図


企業はITを利用することによって、日々の入出庫管理を徹底させ、更に製品の売れ筋動向を正確に把握するシステムを構築します。
これにより戦略的なビジネス展開が出来るようになります。
これらが徹底されていなければ、現代の勝ち組企業になることは有り得ません。



このあと業務要求をしっかり固め、業務の流れ図を描き今まで話したようなデータ項目を決めます。

システムに必要なデータを格納する貯蔵庫は、データモデリングしてER(Entity Relationship)図を作ってデータベース設計します。
最近はUML手法を用いて進めることが多いのですが、これらの話しはIT専門分野になってしまい、途端に難解なIT話になるので省略します。

さて、まだまだ実務内容を意識した話は進みます。

031 入荷データを考察しよう

06:物流システム

物流システム徒然記

数回前の業務流れ図をちょっと思い出して下さい。
今回の入荷予定データは、上から5番目の入荷業務の受付に流れる青い太矢印がそれにあたります。

データ形式は前回にも掲げたように、受注番号、入荷予定日、製品コード、入荷予定数・・・せめてこの程度の項目があれば、何とか入荷処理出来ます。

更に項目追加した入荷予定データ
とは言っても項目が少なすぎるので、アパレル関係ならどうかな?と思って項目を増やしてみました。勿論、これは推測で項目追加しているだけです。

業界の扱う商品によっては、冷蔵や冷凍の温度管理が必要かもしれません。毒劇物があるかもしれません。賞味期限や有効期限があるかもしれません。
企業によっては入荷時に価格を管理したい場合があるかもしれません。

入庫と言っても倉庫間移動や返品入庫なのかもしれません。製造ロット番号も必要かもしれません。
EDIでシステム運用するなら、登録/変更/削除フラグもあったほうが良いかもしれません。
う~ん、考えるとそこそこ出てきそうです。

イラストを眺めていると、製品マスタがあれば、製品コードをキーにあれこれ情報が取得出来そうです。

以前話題に出したJTRNならコード番号(タグ番号)と項目名(エレメント名)があらかじめ割り当てられているので、それを参考にしても良いでしょう。
もっともJTRNは、あまり利用されている噂は聞きませんが。

030 入荷データを定義しよう

06:物流システム

物流システム徒然記

前回は出荷データだったので、入荷データについても記載します。

「 何故、出荷データを先にして入荷データを後に記載するの?」
別に意味はありません。たまたまです。

入荷時も出荷時のように、いきなり貨物が倉庫に到着することはありません。 (SCMが徹底されていない現実の世界では、昔は良くあった話です)

入荷予定データ
「 この製品を30個、お届けします 」 この手の情報を 事前に貰わないと困ります。
いきなり貨物だけトラックで運ばれてきても、内容の確認のしようがありません。 (そこそこ昔はありました)

このデータが事前入荷データってやつです。入荷予定データとも言います。輸出入ではASN(エーエスエヌ = Advanced Shipping Notice)と呼ぶことも多いです。
受け取る側にしてみれば入荷情報ですが、送る側にしてみれば出荷情報です。

貨物到着と一緒に出荷明細を渡すケースもあります。
「 入荷予定の情報くらいFAXで十分じゃないの?」と思うかもしれません。
しかし、電子データで処理を行うことは、いろいろとメリットがあります。

例えば、受信データを基にコンピュータからバーコード付き入荷確認リストが簡単に出力出来ます。
もし、バーコードの無いカートンや製品なら、事前に入荷予定データからバーコードラベルをプリントすることも可能になります。
バーコードが有るカートンや製品なら、この段階で色々と作業の効率化が図れます。

この効率化については、バーコードをテーマにした際に徒然に記載します。
勿論、在庫管理を行う場合、絶大な効率を図れます。

何度も記載していますが、「 電話とFAXで何とかなっているから、ウチはシステムはいらないよ 」 と考えたら駄目です。
「 やりたいのは、やまやまだけど予算がなくてね 」 これも単なる言い逃れです。
取引会社の候補から除外される可能性が十分にあります。

もっとも昨今はインターネットを利用した良いパッケージソフトが出回っているので、低予算で導入可能です。
これについては別の機会に触れます。

「 このシステムが稼働すれば、現在の○○社から御社に切り替えます。稼動予定日は、半年後の○月1日が目標です 」
○○社の中堅倉庫業者は、まだ何も知りません。
半年後に取引相手(某中堅メーカー)の取引から外されます。

これは数年前の経験談です・・・こんなこと珍しくないのです。

029 出荷データを考察しよう

06:物流システム

物流システム徒然記

前回の出荷指示データは、一般的に突然データを送信されることはありません。

SCMの考えでいけば、送信時間はあらかじめ企業間で約束されています。
受信側は、決められた日時までにデータを貰えば生産なり出荷を約束します。

つまり「 この製品を5個、△月△日に、○○様にお届けして下さい 」の電子データを貰う訳です。

更に項目追加した出荷指示データ
前回の出荷指示データに項目を追加しました。

大抵の場合、納品書とか請求書が必要ですよ。・・・そのためお届け商品の単価/数量/金額の項目を追加しました。

運送業者に渡す送り状も必要です(ヤマトさん、佐川さんなど配送伝票を意味します)。
そのためお届け先住所項目を加えています。

ピッキング作業時、梱包時、配送伝票の注意事項とかコメント欄などもあったら良いです。その項目も加えました。
ピッキング時や梱包時にも色々な指示が必要だったり、送り状(配送伝票)の「午前 10:00必着」とかの事細かなコメントです。

更に細かく考えると、お届け先と請求書先は別かもしれません。
会社が取り扱う製品固有の項目が必要かもしれません。例えば、組み合わせセット商品なんかもあるかもしれません。

う~ん、あれこれ考え出すと結構出てきそうです(実際いろいろ出てきます)。

改めて考えると、もっと追加項目がありそうです。
そうなんです、これがシステムを導入する際の調査・分析です。
調査・分析なんて言うと難しい感じがしますが、そうでもないです(みんな難しい顔してやっているだけです)。

これをあらかじめ取り決めたフォーマット(EDI)で毎回データ送信します。
皆さんが何気なくやり取りしているブログの日記データも、あらかじめ全部フォーマットが定義されています。
あとは約束事の通信手順(プロトコル)に従ってデータ送受信しているだけです。

028 出荷データを定義しよう

06:物流システム

物流システム徒然記

さて、業務のやりとりに必要な情報(ファイル)が分かったら、具体的に項目を考えてみましょう。
前回の流れ図の青矢印の一番上が出荷依頼データ、青矢印の5番目が入荷予定データであることは何となく分かるでしょう。

出荷指示データ
具体的に必要な項目名がどんなものか考えてみましょう。
例えば、出荷指示データならこんな感じでしょうか?
出荷指示データとは出荷を依頼する際のデータです。(言葉のままじゃん!)

これまでEDIについてあれこれ触れてきましたが、それらの説明が何も生かされていないほどのシンプルな内容です。
これでは少々足りないけど、何とか実務に耐えられそうです。

さらに、この項目について考察します。

1 2 3 4 >