■生産管理ソフトの間違い

■生産管理について

　この頃流行の生産管理ソフトについて考えてみます。つまり、生産管理ソフトがいかに間違っているかについて述べてみます。

●ラインバランスはとれない

　生産工場の各工程の能力を一定にしようと、管理者は躍起になって人員配置を検討したり、設備投資を繰り返しますがこれがうまくいった試しはありません。

　かりにラインの生産能力が同等であるとした場合にでも、ある工程でトラブルが発生した場合、次工程には「待ち」が発生します。その待ち時間は理論的に次々と次工程に繰り延べされていきます。それを解消するには残業等で生産量を補わなければならないでしょう。

　さらにトラブルは至る所、あらゆる物件で発生するので、こうした「待ち時間」は加速度をつけて累積されて、その結果工場全体に納期遅れ、品質低下などを引き起こしていきます。

●余裕を持ちすぎると企業は倒産する

　ではそのトラブルを防ぐために各工程の大幅な能力アップを図ったらどうなるでしょうか。多くの余剰人員を配置し、高額な大型機械を設置すれば多少のトラブルがあっても生産能力は高いわけですから、回避できるような感じがします。

　しかし、その投下された資源、固定費に対して十分な仕事がなければどうなるでしょうか。答えは明白です。大赤字で倒産するでしょう。

●季節変動という大波がやってくる

　製造業には季節変動という大波がやってきます。その大波の頂点に照準をあわせた人員、設備をもてば、閑散期は大赤字で倒産します。閑散期に照準をあてれば繁忙期に納期遅れの心配もあります。

　いずれにしても、ラインバランスはとれないというのが現実ですが、それをなんとかしようと苦心しているのが工場管理者です。

■そこで、生産管理ソフトを使うのだか・・

　困った工場管理者は高額な生産管理ソフトを購入すればこの様々に入り組んだ問題は解けるだろうと思います。

　しかし問題はボトルネックです。どのような企業であろうとも、ボトルネックは必ず存在します。もし自社内に存在しなくとも市場がボトルネックになる場合があります。無限には売れないのです。

　結論からいえば、いかに生産管理ソフトが巧妙なスケジューリングをしようが、ボトルネックの能力以上には生産されないということですから、生産管理ソフトは「スケジューリングなどしなくて良い」ということになります。

　生産管理は各工程の能力を計測します。例えば人員が何名いて一人８時間だから合計何時間を持っているとか設備の能力などをインプットします。続いて各仕事の作業時間を予測し、ソフトに入力することで仕事の割り振り、スケジュールを計算するわけです。

　この際、「山積み方式」といって、各工程でオーバーフローした仕事は翌日に回すといった計算をおこなって、何月何日にはこの仕事、次の日はこれと指示書が出てくるようになっているようです。

　ところが、各工程の能力を設定して、全ての仕事をインプットしたからうまくいくのかというと、これが予定通り進まないのが現状です。

■ようはボトルネックの能力でしか生産されないのだから・・

　ようはボトルネックの能力で全社が決まるわけなので、そもそも各工程の能力を測定して設定することじたい「不要である」ということになります。

　つまり、全工程の能力をボトルネック工程の能力より、少し多めくらいに設定しておけば、それで良いということなのですが、それを各工程の能力を”正確に算出”するから、おかしくなるのです。

ボトルネックより大きい能力設定をしてスケジューリングをするからこそ、”過度の投入を許して”しまい、工場内に仕掛品の山を築くことになってしまうのです。このことは生産管理担当者の誰もがまだ知らない点です。パラドックス（逆説）といってもいいでしょう。

■正確を求めた結果が、無制限につながってしまう

　精度をもとめて、もしくは混乱した状態を目に見える形にしようとスタートした生産管理ソフトが、じつは「企業内に大混乱を招いてしまう」という驚くべき結果になりました。

　これはボトルネックを知らずにコントロールすることがいかに悪影響を及ぼすのか、という意味も興味深い事例になると思います。

　そして、以前から信奉されている生産管理がいかに間違っているかです。

　しかもこうした「考え方が間違っているがために引き起こされる不具合、赤字など」を、「方針制約」といいます。

■生産管理ソフトに求められるもの

　生産管理ソフトに「欠落」している要素に、余裕時間の設定があります。余裕時間を工程内のどの位置に適切に設けて、作業の遅れというリスクを一括吸収するかという点については、まだ検討されていません。

　これまえは各工程内に準備時間、実稼働時間、後処理時間に加えて余裕時間を考慮してスケジューリングを行いましたが、これではうまくいきません。すべて食いつぶされてしまうからです。個々の最適化の合計は全体最適とイコールにはなりません。

　よって、余裕時間をもつ、ブランク工程を必要箇所に設置して、そこがクッションの役割を果たすようソフト側でプログラミングする必要があります。いまはこうした考え方がないために、ギリギリの余裕のないスケジューリングで苦労せざるを得ないわけです。