ノウハウ

2014.10.17
    見える化戦略の具体例~在庫の見える化 第二回

    コンサルタント太田 達也

    • Facebookでシェアする
    • Twitterでシェアする
    • LINEでシェアする
    • メールでシェアする

    前回から引き続き、在庫の見える化を例にとって、「見える化戦略」のイメージを紹介していきます。第一回では見える化のアプローチの1つ、「問題見える化」の紹介の中で「組み合わせ思考」の話までしました。今回は「セグメント化」の話から続けたいと思います。

    1.問題見える化~続き
    在庫とサービスレベルのトレードオフ関係において、どういう組み合わせを選ぶかが即ち「戦略」なるというお話をしました。そして、戦略を考え始めると、「この顧客向け製品はサービスレベル 100%は死守しなくてはダメだな」「この製品は特殊仕様だから 5 日間くらいは待ってもらえるな」などと製品によってとるべき戦略が異なることに気付いてきます。そこで重要になってくるのが「セグメント化」です。

    「セグメント化」とは管理の対象をその特性によってグループ分けし、そのグループが持つ特性に合わせた戦略を採ることです。在庫基準とサービスレベルの組合せ戦略の場合であれば、例えば以下のようなセグメント化が考えられます。
    ・市場特性による製品の分類
    ・在庫金額による ABC 分析による製品の分類
    ・製品ライフサイクルにおけるステージによる分類

    ここで、例えば ABC 分析によるセグメント化を採った場合の戦略はどのようになるでしょうか。ほとんどの場合 A 品は品目点数が少なく、B、C の順で多くなる傾向があるので、以下のような戦略をとることができます。

    A 品:金額インパクトが大きいが品目点数は少ないので集中管理して、少ない在庫でサービスレベルを維持する。
    B 品:A 品ほどは工数をかけられないので、サービスレベルを維持するために在庫基準を多めに設定する。
    C 品:出荷頻度が少なく品目点数が多いので、在庫基準は上げずにサービスレベルの基準を多少下げる。

    いかがでしょうか。実際にはいくつかの切り口を組み合わせてセグメント化を行なうのですが、上記の例でだいぶイメージがつかめてきたと思います。ここまで戦略がたてられれば、あとは具体的な在庫日数をセグメントごとに決めていけば会社としての方針が反映された基準ができあがります。(※具体的な適正在庫日数の理論的な求め方については今回の主題から外れるのでここでは割愛します)

    さて、基準ができてしまえば、“問題の見える化”は 8 割方できたといってもよいでしょう。残りの 2 割は、問題を“見る”ための仕組みづくりです。これには情報システムの活用が欠かせません。膨大なデータの中から情報システムを活用して問題を浮き彫りにするのです。具体的な機能としては、基準在庫日数を実際の在庫日数を比較して、一定以上の差異がある製品をリストアップするというようなアラート機能が必要です。大手の ERP パッケージや SCP ソフトであれば大体似たような機能は持っていますが、上手く活用して“問題の見える化”をするためには、以下のようなポイントを重要視する必要があります。

    まずは、在庫基準のマスタ化です。製品のマスタ情報に先程の戦略で決めた在庫日数を更新します。重要なのはマスタに戦略が反映されているという意識です。「システム導入時に IT ベンダーさんから、ここにはこの値を入れてください、と言われたので、理由は分からないけどずっとその値を入力しています」という人は、極端な言い方をするとシステムに使われてしまっている人です。業務ユーザーがシステムを“活用”するためには、根拠を理解した上で戦略に基づいた基準値をマスタに更新し、常に見直すことが不可欠です。

    次のポイントは、在庫情報や販売計画の情報化です。「システムにも販売計画入力してるけど、実際には手元にあるエクセルシートで管理してる」という営業担当は以外と少なくありません。在庫日数は販売計画にもとづいて計算されるため、販売計画自体が現実と即していないのであれば、問題を見逃す可能性が大きくなります。何より、どうせ正しい値が入っていないという意識が、問題を見つけようとする気持ちを遠ざけてしまいます。とくにマネージャー層の方は、チームメンバーがシステムに情報を入力するための工数を確保する意識が必要です。
    以上のように、戦略にもとづいた基準を決め、情報システムを正しく活用して問題を見つける仕組みをつくることによって、在庫の問題見える化は完了です。

    2.全体見える化
    「問題見える化」によって、事実として問題が起こっていることが把握できるようになります。そして問題を知ったからには、原因を追究し改善方法を見出す必要があります。しかしそのためには問題だけをじっと眺めていても仕方ありません。その問題の背景にある事実を正確にとらえ、全体を理解した上で、問題を分析しないと、原因の追求や影響の説明はできないのです。在庫の例でいうと、基準在庫日数 10 日に対して実際には20日も在庫を持っている製品があるという問題を発見したときに、“在庫日数”という数字だけを見ても何も分かりません。販売計画・実績、生産計画・実績、購買予定・実績など、在庫の背景にある事実が情報として同時に見えていないと、なぜ今在庫日数が 20日になってしまっているのかについて原因の追究はできません。そこで、問題見える化の次は、“全体見える化”が必要になってきます。全体見える化とは、問題の背景にある事実を含めて全体として何が起こっているのかを説明できるようになることです。全体が見えると、原因を遡って追究し、対策を講じることができるようになります。

    例えば、過剰在庫の問題を発見したときに、その製品の受注実績が販売計画に対し少なかったとします。この場合在庫が増えた原因は販売予測が外れたということになります。さらに同じ問題が前月も起こっていたとすると、需要傾向が下降している、つまりはライフサイクルの衰退時期に入っている可能性が考えられます。もしそうだとすると、販売計画の見直しを指示したり、この製品の在庫基準を安定期型戦略から衰退期形戦略用に切替える、などといった対策をうつ必要があることが見えてきます。
    また、別の例として、販売計画は少ししかないのに生産数量が異常に多かったとします。SCM のマネージャーがこれに気付き、担当者に理由を尋ねると、生産ロットが大きいからしょうがないといいました。しかし突き詰めると、特に工場と交渉をしたわけではなく、この製品が売れ筋だった昔からの取り決めでそうなっていることが分かりました。この場合は、「生産を小ロット化できないか工場と交渉をする」ということが対策になります。
    全体見える化にも情報システムの活用は必要です。在庫の全体見える化のために情報システムに必要な機能としては、販売と生産・購買、それからその結果としての在庫を並べて表示するバランス表と、それぞれについて計画と実績を比較できるレポートが必要になります。具体的なレポート仕様については、マネージャー層が原因追求のプロセスを想定し、どのような情報が見える必要があるのかを考え、自ら仕様要求をだせるというのが、理想的な姿です。

    さて、ここまでで、「見える化戦略」の4つのアプローチの内の 2 つ、「問題見える化」と「全体見える化」の話をしました。次回はこのテーマの最終回になりますが、残り2つのアプローチを紹介し、これらをベースに最終的にどのようにマネジメントプロセスが形作られていくか、一緒に見ていきたいと思います。

    コンサルタント太田 達也

    1995年外資系パッケージベンダー入社。生産管理及び計画領域を軸としたコンサルタントとして、グローバルSCMの構築や生産計画プロセスの改善などで実績を残す。2007年マネジメント・プロセス・コンサルティング株式会社に入社、大手外食チェーンの差プラチェーン改革、流通小売企業の全社経営改革など、クライアント企業の一員となってプロジェクトをリードするスタイルで活動。