コミュニケーション・ツールとしての生産スケジューラ

10年以上前に開発して納品した生産計画・スケジューリングシステムを、昨年、再度作り直して顧客におさめた。さすがにサーバ等のインフラが古くなってサポート切れになったことと、業務内容も昔とは変わったことが作り直しの理由だ。同じ生産スケジューラを(部分的には改善したとはいえ)10年もの長きにわたり使い続けていただいた顧客には感謝の言葉もない。

ところで、新しいスケジューラでは、旧い機能を大幅に削ったところと、新規に機能を追加したところがある。削ったのは、主に「最適化」したスケジュールを自動生成する部分だった。つけ加わったのは、計画部門/生産部門と営業部門が生産スケジュールを共有し、相互にその内容を編集し段階的詳細化していく機能だった。昔のバージョンでは、生産計画・スケジューリングシステムは、計画部門の担当者のほんの数人が使うシステムだった。今や大勢のユーザが複数部門からログインして、見たり触ったりしている。

大勢の人間が計画にアクセスできるようになって、スケジュールはより『最適な』ものに近づいたか? それはわからない。より現実的なものに近づいた、とは言えるかもしれない。しかし、そもそも「最適」なスケジュールとは何だろうか。与えられた生産オーダーと製造資源の組合せの中で、リードタイムが短く(=期間あたりの生産額が大きく)、製造原価・物流原価の小さなスケジュール、すなわち一言でいうと、「よりお金の儲かる」計画のことだろうか。それが「最適」といえるのだろうか。

最適とは、可能な解空間の範囲内で、目的関数が極大となる点のことだ。いいかえれば、ある生産スケジュールが最適といえるのは、計画対象範囲の生産オーダーの組が与条件として決められており、かつ目的(評価)関数もゆるぎないときだけである。しかし、この二つの前提は、現実にはどちらもあやしい。生産数量も品種も、急な追加変更でころころ変わる。今日、向こう1月分の完全な計画をつくっても、明日になればあちこちに修正が必要になる。おまけに、生産額ははたして本当に売上に確実になるといえるのか。工場から出荷しても、流通在庫を積み増しているだけなのではないか。さらに納期遅れが生じたら、売りそこないの機会損失はどう金額評価するのか。釣りのがした魚の重量測定法を発明した人は、いまだにいない。

こう考えると、最適スケジュールというのは、ある理想状態にのみ存在しうるものだとわかる。それは需要(ないし受注)が確定していて、追加も変更もない仮想的世界である。だから私は以前からずっと、生産スケジューラは最適スケジュール作成の道具ではないと主張してきた。そんなものを営業部門は許さないからだ。

それでは、スケジューラは何のためにあるのか? それは、今述べたことの逆を考えるとわかる。需要が確実にわかっていないとしたら、それを推測するために仮説が必要である。そして、多くの企業では、この仮説が部門ごとにバラバラで、だれも明確に口にも出さず、誰も調整しない。おまけに、納期最優先か、生産効率優先かで、目的関数(戦略)までくいちがう。その結果は? むろん、在庫過剰と欠品の山である。なぜなら営業の販売予測と工場の生産予定と物流の手配見込がずれているからだ。

だとしたら、関係部門がみなで、仮説共有できると素晴らしいだろうと考えられる。生産スケジュールと、その結果としての品目別需給表を見て、互いの見方を調整できる。最新のスケジュールが見えれば、納期回答も素早く正確になる。納期が正確になれば、顧客からの内示や注文もブレが減るし、販売額自体も増えるだろう。良循環が期待できよう。

生産スケジューラは、情報共有の道具なのである。どういう情報かというと、品目別生産量や着手完了日時だけではない、そのもとにある需要に関する仮説、実行のための評価尺度(戦略)を互いに確認し了解するための、道具である。つまり、コミュニケーション・ツールなのだ。ネットワークがこれだけ発達した現在、10年前や20年前のスタンドアローン型の視点で生産スケジューリング問題をみてはいけない。これが昨年私の学びなおした教訓である。

Follow me!