良い営業、普通の営業、悪い営業、嫌な営業誰も知らない生産管理の苦悩を徹底討論(2)(2/3 ページ)

» 2008年07月09日 00時00分 公開
[上島康夫@IT MONOist]

需要を予測するなんて……あきらめた方がいい

B氏 私の場合は赴任した当初、まずは個別製品の生産計画がなかったから、そこから始めて、これは当然うまくいきました。

A氏 それまで個別計画なしで、どうやって造っていたんですか?

B氏 そりゃもう、「えいやっ!」で造るんですよ。

一同 (爆笑)、何を基準に造っていたの?

B氏 注文が来たら、出て行った分だけ補充するの。はっきりいって、欠品になったら造るってアイテムもかなりありましたね。そこでコンピュータを導入して、ある程度の在庫基準を決めて、在庫がそこを下回ったら自動的に発注書が出るような仕組みを作ったんです。ですから、ある日は作業表がいっぱいになって、その後何日も発注書が全然出ないこともあった。見込み生産といいながら、実態はそういう状況でした。そうやってとにかく予算金額までは造れと。それを在庫管理からコンピュータに落としていって、毎月の予測を立てていきました。ここまでは、比較的順調にいったんです。
 問題なのは“需要予測”ですよね。これはもう……当たらない。どんなに頑張っても当たらないんです。毎月一定量を受注できるものはいいんですよ。スタンダード商品なら多少受注量がぶれたってどうってことはない。頑張って造ればいいんだから。問題なのは数カ月に1回しか受注しないもの。これを予想しろっていわれたって、当たるわけがない。それでもいろいろと試したんですよ。分布を取ってみたり、どれくらいのリスクで外れるのか。まぁいろいろやったけど、最後は投げ出しましたね。当たるわけないから、注文が来たものを造るしかない。

A氏 分かります。あるアイテムの受注が月平均2個だったとしますよね。じゃあ在庫を4個持っておこうとしても、あるときいっぺんに10個注文が来たりする。5カ月に1回、10個の注文が来ても月平均2個ですから。

B氏 そうそう。ある製品はどれくらいのロットで注文が来るのか調べたら、半年に1回、10個ずつ注文が来るんだと分かった。そうか、1回の注文は10個単位なんだと。で、よく考えてみたら、うちの製品は10個入りでしか売っていなかった(爆笑)。そりゃ当たり前だ。2個とか4個の注文が来ても、そんな単位じゃ作れない。この手の需要予測は非常に難しい。そういうアイテムは半年分とか1年分の在庫を造っておいて、売れなければ仕方ないと割り切ってしまうしかないと思いますね。
 だから過剰在庫のアイテムと、多少在庫が足りない状況で動かすアイテムと、欠品になったらごめんなさいというアイテムを分けて、ABCランクみたいにして管理しましたね。Cランクのごめんなさいアイテムは、うちが本気で売りたい商品じゃないから、欠品してもいいと割り切りました。

在庫をあふれさせる犯人はCランク品だ

村上 お客さんのわがままに振り回されるという経験について、Cさんはいかがですか。

C氏 めったに注文の来ない商品を受注した場合、「来月もこのお客さんはこれを使うのか聞き出してくれ。普段造らないアイテムだから、もし継続して受注するならまとめて造っておきたいんだ」と営業にいうんですが、「その製品を来月もお使いになるんですか」なんてお客さんには聞けないと営業はいい張るんです。その製品を使った商品が売れるか売れないかは、お客さんにだって分からない。だから、未来の需要を尋ねても意味がないと。
 生産管理システムを導入するきっかけになったのは、50トン分くらいの容量しかない倉庫が当時いっぱいになっていたからです。そこで経営サイドは、倉庫を拡張するか、生産管理システムを導入して在庫を減らすかを検討して、もし在庫の見える化が実現できれば在庫を減らせるかもしれないという判断になって、システム導入が決まったのです。ところが、やっぱり在庫は減りませんでしたね。常に70トンくらいの在庫は必要です。過剰在庫と欠品がセットになって存在するという状況は、システム導入によっても変わらない。うちは1つのラインで多数のアイテムを造っているので、次にそのアイテムを造るまで持たせるだけの在庫はどうしても持たざるを得ない。それも主要製品を造りだめするので、常に製品在庫があふれて、出荷作業は非効率なままです。

村上 やはり問題なのは主力製品のAランクじゃなくて、めったに注文の来ないBランク、Cランクの商品ですか。

C氏 そうですね。安定した需要のある主力製品は一時的に在庫がたまって倉庫を圧迫しても、いずれ在庫は減っていきますから、あまり問題になりません。

B氏 問題なのは、今月売れるか売れないか分からない商品ですよね。この問題に対してうちも生産スケジューラを導入して、見事にコケました。スケジューラってのは、要するにこれで造ろうって計画は出せるんですが、その生産計画が需要に対して合っているのかというのは誰にも分からない。そもそも、このアイテムはなぜ造らなければならないのかという理屈がちゃんと通っていないと、スケジューラをいくら入れてもうまくいかないんです。需要予測がちゃんとしていないといけない。スケジューラを入れると、確かに仕掛かり在庫などは減るし、リードタイムも短くなる。じゃあ在庫が減るかというと、減らないんです。そもそもスケジューラって、在庫とは関係ない。受注予測を完ぺきにしてくれるスケジューラがあれば別ですけど(笑)。

売れない商品ほど不要な分まで造ってしまう

村上 おおよそこれまでに、生産管理部門の担当者が直面する問題点や、苦労が浮き彫りにされてきたようです。皆さんそれぞれお立場は違いますが、3つのサバ(工場、営業、お客さん)に苦労されているようです。次に、2つの勘違い、すなわち「たくさん造れば安くなる」「何が起こるか分からないから早めに投入しておく」という点についてはいかがでしょうか。

A氏 生産計画を立てる立場として、「何が起こるか分からないから早めに投入しておく」という行為は日常的にやっていました。アイテムごとに、これは何日に投入して、いつまでにいくつ完成させるとスケジュールを立てるわけですが、あるとき急に「あれ、次に造るものがないじゃないか」という事態は当然起こるわけです。そこから先が知恵の絞りどころで、“勘ピュータ”で2日分くらいの生産予定を埋めたり、あるものを前倒しで生産するのは当たり前、できる限り前倒しで生産したのに、まだ造るものが足りなかったり。

村上 「たくさん造れば安くなる」について、ロットまとめはどうですか。

A氏 当然ありますね。大型設備でまとめて造る工程が入りますから、大量に投入する方が生産性がいいし、段取り変えも少なくしたい。そうすると売れる売れないにかかわらず、生産ロットは決まってしまいます。

村上 特に古くからある生産設備って、ロットを大きくすればするほど生産性が上がるようにできていますよね。ロットサイズを半分にすると、生産性は半分よりずっと下がってしまい、そんな量では下手をすると生産できない。

B氏 ロットを小さくし過ぎて不要品にしてしまう場合もありますね。

A氏 あと、原材料が余ってしまうとか。この溶かした材料……どうするのって(笑)。

C氏 製造量は機械の1日のバッチ量が基準になっていますね。半日単位の生産にすると歩留まり度数が増えてしまいますし、例えば100キログラム造っても1トン造っても、機械の中に残ってしまう原材料は同じですから、たくさん流した方がいいということになります。あと混合製品など、最近では10キログラム単位の注文が多いんですが、それだと原材料が機械の下の方だけになって、羽根を回しても空回りして交ざらないんですよ(笑)。やはり100キログラムくらいないとうまく材料が交ざらない。

B氏 うちは原材料のミキシングのロット量があって、これはある程度保存できます。次のプレス工程では、最低300個は造ってからでないと現場の人は金型を交換したがらない。次は炉に入れるんですが、このバッチもロット量があって、材質によって炉の温度が違うんです。いっぱい入れているのと少しのときとで、炉内の温度が違うらしいんですよ。不良品を出さないためには一定のロットで造るしかない。そうすると、売れない商品ほど大ロット、つまり不要な分まで造ってしまう。売れている商品は、適当なところで切れるからまだいいんです。

A氏 うちの製品は切削加工の工程があって、注文は1個でも、試し切りで2〜3個使っちゃうんです。ちゃんとした寸法で出すのに、微調整をしながら造りますから。だからスケジューラにも「歩留まり3個」と設定してあります。で、注文は1個でも4個製造する羽目になる(笑)。

村上 そんなもうからない注文をどうして取ってくるんでしょうか。

A氏 こっちの知らない間に取っちゃってるんですよね。EDI(Electronic Data Interchange:電子データ交換)を使ってコンピュータで注文が来るものなどは、誰も知らない間に受注しちゃっている。

B氏 あのEDIってのは、小ロット化の引き金になったという意味で、大きな問題ですよね。受注に関して営業の裁量は一切入りませんから。最低ロットというのは一応決めているんですが、大抵は無視されます。

A氏 新商品で小ロットはある程度仕方がないと思いますが、廃番間際のアイテムとか、シリーズ全体では売れているのでEDIに登録されたままだけど、実際にはほとんど使われないアイテムが、何カ月に1回という頻度でEDIから注文が入ってきてしまう。

Copyright © ITmedia, Inc. All Rights Reserved.