アパレル業界で私が知ってること 閑話続き：ノード＆リンク法

　いやー、なんか個人的なメソッドにカタカナの名前を付けちゃったりしたら「それらしい感」が出ちゃいますね。ぶっちゃけそれらしい感とかってタイプじゃないのでちょっと違和感ありありです。

　でも、この思考法というかフレームワーク的ななにかって、なんか応用利きそうといいますか、きちんと研究して事例を増やして検算しておけば、わりかし汎用的に使えるんじゃないかなって思ってまして。
　まあ、当時の私って本当にいろんな事をバラバラに考えまくっていましたので、後から整理したら山ほどいろいろってのがよくありまして。整理したら結構いろいろ出てきてる感がありますので、まあ使えそうなのが出てきたら整理していきたいなーと。
　その中で、SCM構築とか全体最適とかってのをやっていた時に意識していたやり方というか方法論群みたいなのを整理したものが今回お話したい「ノード＆リンク法」です。

　大雑把に言えば、各々の業務の中で改善を行うのではなく「ノード(結節点)」のところに着目して、そこをなるべくシームレスに接続する為の「リンク」を構築するっていうのが主旨というか手法の骨子になります。
　うーん、手法っていっても具体的な方法そのものは多種多様に渡っていますのでちょい違う感がありますね。考え方のほうなのかも知れません。

　まあ具体例を上げてみましょう。その方が手っ取り早く説明できそうです。実際に業務改善をやってきた中での大きな変更として、営業担当が各々の店舗都合で発注や出荷を行っていたりしていたのを一括管理したあたりの話を持ち出してみます。

　以前は商品が分配されたものに対して、営業担当が出荷指示を行っていたわけです。もうちょい言いますと営業が発注する際に納期をバラバラに設定していましたので、生産担当者は「いつ入荷させるのが正しいのか？」というのも実はあやふやだったりしていたんですね。ぶっちゃけ適当に納期設定する場合と、きちんと意図をもって納期設定する場合にわかれていたりしました。問題なのは「意図をもって納期を早めに設定している」場合とかがあったりしたわけです。正直高々１店舗の為に全体の納期を早めるとかできませんので担当者も「早くあがったらラッキー」程度の感覚で納期設定するんですけど、まあ、会社全体から見たら迷惑な話なんですよね、これ。

　さて、営業が「出荷指示を行う」という作業は「物流倉庫が出荷を行う」「生産担当が納品させる」という作業とに結節点があるっていう風に考える事ができます。ついでに言えば「物流倉庫が出荷を行う」と「生産担当が納品させる」との間にも結節点がありますね。

　さて、営業からすりゃ出荷指示したくても納品されていなければ出荷されないんですよね、当たり前なんですけど。でも店頭から要望とかあっちゃったりして急がされたりなんかして板挟みになったりなんてのはわりとよくあります。基本的な納期から大きく遅れない限りは１店舗とか２店舗とかの都合でしかないんですけど、営業担当者にとっては１店舗とか２店舗とかの要望って過大評価しちゃうんですよね。ですので物流倉庫に「入荷したらすぐ教えてくれ」とか言っちゃうんです。で、入荷したら本来の展示会発注分と別で分配前に出荷指示とかしちゃうんですよ。油断したら数字が合わなくなったりとかするんです。当時分配していたのは私なんですが、平社員の私の見解より営業課長とかの意見の方が優先されてたりとか普通にありましたから。職務が違うので権限的には私の方が上じゃないと組織上破綻するんですけどね。っていうか破綻しそうだったのでしょっちゅう文句言ってたり出荷指示をキャンセルしてやったりとかしていました。
　あ、ちなみに事前に要望として出してくれていた場合はわりと対応していましたけどね、実は。このあたりは私と物流との間ではリンクが取れていましたから問題なかったんですよ。

　それはさておき、要するに「バラバラに出荷される」っていうことは「バラバラに出荷指示がくる」っていうことで、物流側としては同じものを一気にピッキングしたいのにできなかったり、入荷した商品が多いからと思って手ぐすね引いてまっていたら一向に出荷指示が回ってこなかったり、逆に油断していたら異常な量の出荷指示所が回ったりとかってのが起きていたわけです。物流側としてはたまったもんじゃありませんし、物流業務が煩雑になるってのは要するに会社全体としてコスト増になる原因です。

　まあ他にも理由はあるんですが、業務改革を行うことによって「同じ商品は同時期に出荷される」っていう風に出荷指示の出方が変更されたわけです。

　当たり前なんですが、同時期に出荷されるのであれば一気にピッキングしたいってのが物流側の要望になります。ここが結節点になりますね。

　端的に言えば「出荷指示を送る→出荷指示を受け取ってピッキングを始める」の「→」の部分です。ここを上手くやれば、まあ物流用語でいう「種まきピッキングができる」っていうのになります。経験上種まきピッキングが摘み取りピッキングより速くなるための条件ってのは多少あるんですが、まあ一般論的には種まきピッキングの方が速いです。それに摘み取りピッキングをするにしても近い場所に全部があれば当然早くなりますしね。

　ただ「→」の部分で、気を使わないといけない事がでてきたりはします。例えば同じ指示書に追加商品が掲載されたりしちゃったら不都合ですし、紙ベースで伝票が出票されますから途中のページに違うものが挟まったりしても嬉しくないんですよね、実際。

　じゃあどうするかっていうと「初回出荷の伝票が動いている間は追加出荷の出票はしない」とかってルールを設定していくんです。実際の手法としては「その期間の急ぎの出荷は客注(店頭にない商品のお客様からの取り寄せ依頼みたいなものと思ってください)『客注』フラグを立てる」とか「一気に初回出荷する前の納期設定を行わない(あっても初回出荷が終了するまでは出荷しない)」とかっていう感じです。大雑把に言えばこのルールみたいなのが「リンク」になります。

　当然ですがITシステム的にもリンクを意識した設計を行いますし、運用レベルではイレギュラーな出荷(一括出荷前の荷集め等)も行うわけですが、基本ルールが出来上がった上で、出来上がっているリンク上でのやり取りですからいくらでも対応可能になります。
　「この１件分指示出すけど、後から他の店の分は一括で指示送るから棚入れせずに抜いてくれたらよいよー」とかって感じですね。実際に棚入れするしないは物流側の判断ですけど。

　この流れだけを考えてみても、例えば「セットアップする商品が上がってくるのが１週間後なのでそれまでは出荷しないよ」とか「この週にこの程度出荷指示だすけどいけそう？」とかってのが現実的な話し合いとして成立することになります。物流業務が「読める」ようになってくるんですね。

　よく読んで頂ければわかると思うんですが、ここまでの流れで各々の業務っていうかやることそのものは何も変わっていません。当然仕組みを組んだり管理手法が変わったりとかってのが伴う事もありますが「出荷指示を送る」「出荷指示を受け取ってピッキングを始める」という流れそのものは変化していません。変化したのは「→」の部分です。

　一見「なんだそんな事か」でしかないんですが、ここ、部門ごとで改善しようとあくせくしていても絶対に解決しない事なんです。わりと見逃されがちといいますか、部門ごとでタスクとして改善を考えている限り解決しないところですから、そういう意味では「ノード&リンク法」的な考え方ってのは全体最適化の為には重要なんですよね。ついでに言えば約束事決めてるだけですから簡単です。すぐにでもできます。笑。

　しかもこれをやる事で店頭に何がいつ納品されるのかを事前連絡する事が可能になりました。実はこのあたり、過去は例えば担当が出張していたらその間は出荷が保留されちゃったりとかってのが普通だったんです。しかも店頭の状況より担当の感覚の方が優先されがちだったりしてたりしました(特に消化店舗は)。なので店頭はいつ何が着荷するのかってわかんなかったりしたんですよね、実際。

　ここで「出荷指示を行う」→「出荷指示をした商品リストを店頭に送る」というリンクが作り出されます。ちなみに後半は新しく発生したタスクです。
　っていっても店舗別の初回発注リストは送付済ですから、一斉メールを送るだけで済みますから簡単です。細かい話をすれば品番を入力すれば絵型が呼び出されて張り付くマクロとか組んでました。こういう小さなサブシステム的な物はいっぱい作ってましたからねー、当時。

　厳密に言えばこれによって店頭側がわかるのは「いつ出荷されるか」でしかなく「いつ着荷するか」はわからないんですが、まあ普通は出荷日の翌日か翌々日かに着荷します。ここは地域によって決まってしまっていますから店側としては「じゃあ〇〇日に着荷かな？」ってのが読めるわけです。99%まではその通りに着荷します。
　そうすれば店舗側としては受け入れ態勢が整えられますし、シフトのやり取りとかでどうしようもない場合は「ごめん１日ずらしてくれー」とかって本社に電話してきたりとかするわけです。物流とのリンクが成立していますので、その程度なら余程タイミングが悪くなければ対応可能です。そもそも初回投入は１週間前とかに指示していましたからね。

　もっとあります。店舗にリストを送る時にその商品の企画意図やMD的な意味なんかも併せて連絡可能になるんです。ここで新たに「企画意図やMD的意味なを発信する」→「企画意図やMD的な意味を把握して店頭展開する」というノードとリンクが作れます。
　当たり前なんですが展示会段階で企画意図やMD的な意味は一旦作り上げられていて伝達しているんですけど、時間が経ったら忘れてたり、そもそも担当が変わっていたりとかしますし、本来ならＡという商品で対応するはずだったんだけど納期が遅れているので代わりにＢという商品で対応して欲しいとかっていう、至近での変更とかもありますので、ここで連絡できるのは大きいんですよ。

　まあ、ノードが増えれば多少(今回のこれに関しては本当に多少でしたけど。数分でできましたし。あ、プチシステム作ってる時間があったか。でもあれもマクロ流用だったから半日かかってない)手間がかかるんですが「このあたり何時入荷するん？」的な確認の電話とかそういうのが激減するっていう効果がありましたので、プラマイしても大きく業務改善です。その分販売員とは電話で商品についてや売場状況について語り合う時間が増やせます。
　「結局電話してるんかい」って話なんですけど、POSデータから見えた事象の理由を探るのは今後のためですし、販売員とのコミュニケは重要ですから周りから何を言われても気にしませんでした。まあそのうち周りも気にしなくなっていくわけですが。諦められたともいう。苦笑。電話しながらだと別の仕事していても相手が気にしないっていうのも利点でしたしね。

　まあ概略としてはこんな感じですかね？私の中でも、まだまとめきれているわけでもありませんし。

　一旦のまとめとしては
・業務改革や全体最適を行う場合、業務間のノードを意識してリンクさせることで業務効率が圧倒的に高まる場合が多い。
・１つのリンクが出来上がった場合、その成果物は他のところでも生かせる。
・それによって新たなノードが発生するのでそこでもリンクさせることが出来れば業務効率はさらにアップする。
・これを繰り返せばビジネスプロセスの全体がリンクすることになる。最終的には全体最適化される。ついでに言えばサプライチェーンマネジメントが可能になる。
・リンクを意識してシステムを組み上げる事が出来れば、まあコストパフォーマンスが良いシステムが構築できる(と思うんだけど)。見える化もできる。
　って感じでしょうか。

　個人的なデメリットとしては
・こんなのやってしまったから端から端までリンクした仕事を管理する羽目になった。
　ってのがありますが、まあこればかりは個人の仕事の仕方の問題でしかありませんので本質的なデメリットではありません。リンクを繋ぐ仕事をしていたからってのと、当時は体系化できていたわけじゃないのでどこまでも首を突っ込んでいたっていうのが原因です。実際一旦物流倉庫に一年ほど行ってましたけど機能してましたし、倉庫から帰ってきてからはイレギュラー対応と予実管理やら予算構築やらの仕事が激増してましたからねー。あとリカバリー施策。

　図とか入れたり事例を増やしたりしたらもう少しわかりやすくなるんでしょうけど、そんなことしたら本になってしまいそうな位応用が利く考え方だと個人的には思ってます。
　いや、こういう考え方そのものは世の中に既にでているかもなんですけどね。
　でも「全体最適が大事だ―♪」っていうわりには「全体最適化の為のメソッド」とかそういうのって案外聞いたことがないので、案外初出かもしれません。どうなんだろ？