本文へジャンプ

シリーズ連載「生産管理入門」(5)

第5回 「生産管理とは何か? その5」

タブの始まり

IBMは製造業のお客様に向けて「統合化部品表ソリューション」をご提供しています。本連載では、日本企業のお家芸でもある生産管理および生産管理システムについて、その歴史・考え方をひもときながら6回にわたってご紹介していく予定です。

筆者紹介
株式会社クラステクノロジー
代表取締役 四倉 幹夫 氏

リアルタイム生産

-生産計画の問題点

MRPは生産計画(MPS:基準日程計画)に従って極めて正確にものを発注したり製造したりできる仕組みでした。リードタイムも在庫も完璧にコントロールしてその完全なパラメーターを駆使して完全なMRP計算をすれば、企業は余剰な在庫を持ったりマーケットの需要があるのに欠品を引き起こしたりしなくなるのでしょうか?

答えは当たり前なのですが、Noです。なぜならば、生産計画の予測がはずれていればどんなに正確にMRPを運用しても無意味だからです。でたらめな生産計画を立てれば余剰在庫と欠品の繰り返しになるだけなのです。

それではどうやったら正確な生産計画を立てられるのか、人々はそのことに知恵を絞りました。1990年代にこうした背景から登場したソリューションがサプライチェーン技術として発達した需要予測システムでした。当初は英国の数学者ロナルド・フィッシャーの回帰モデルアルゴリズムやインドの技術者が考えた独特のアルゴリズムが一世を風靡しましたが、このソリューションは今のところあまり成功していないようです。それはなぜかというと、需要予測を本当に行いたい目的がそもそも漸増漸減をとらまえることではなく、需要の急増と急減をいち早くとらまえることにあったからです。数学のアルゴリズムではそれができないのです。それゆえ、今日では需要予測はコンピューターではできないという結論になっています。

それでは今回の米国のサブプライム問題に端を発した国際金融市場の混乱で世界の自動車産業が見舞われたような市場の急減や急増に対してシステムはどう対応すればよいのでしょうか?
その答えが需給変動バランスの崩れをリアルタイムにつかむという管理です。

従来の生産計画はMRPのバッチのサイクル(タイムバケットの範囲)である、1ヶ月や1週間という単位でしか計算を行いませんし、そのタイムバケットより未来の在庫や需給バランス変動は計算していません。従って前のMRPと次のMRP計算の間や、MRP計算より未来の在庫の変動をキャッチする仕組みは存在しなかったのです。

では需要予測プログラムもダメでMRPでも不完全であるとすればどうすればよいのでしょうか?

筆者は需給バランスの変動をセンサーのように素早くつかむ仕組みが有効であると考えました。そのためには現物(在物)しか管理していなかった在庫マスタに時間軸と空間軸を付加して現在の在庫の変動が未来にどのような影響を与えるか瞬時に計算しなければなりません。在庫に時間軸を導入するということは、過去、現在、未来の在庫情報を連続的に管理するということで、データの更新も未来に向かって連続的に行われます。空間軸というのは在庫のロケーションをViewでフィルタリングして管理することによって同じ品目の在庫でもロケーション毎に管理することができます。

例えば、ロケーション概念のなかった生産管理システムでは支給品(有償・無償)を協力会社に搬送すると在庫からデータが消えてしまいました。空間軸で管理するとこれが本社工場のロケーションから協力会社のロケーションへ移動したと管理するので、入出庫のような処理は行わず在庫移動として処理できるのです。

MRPというシステムはバッチなので、全ての計画、全てのオーダーを一度に計算するのと同時に、いくつかの受注をまとめて計算するので、ある顧客の注文がいつ納入されるかというような情報はタイムリーに算出されませんし(全て計算してあるオーダーの内数を受注にペギングしないと納期が回答できません)、部品も日々流れているにもかかわらず一定の間隔でまとめた数字でしか扱えません。理論的には1時間毎にMRPをまわせば物流やラインのタクトに合わせた部品供給やオーダーが出せるだろうと考えられますが、1時間毎あるいは半日毎に工場の全オーダーを実オペレーションに乗せることはできません。工場全体のオーダー(発注、製造全てのアクティビティー)を1時間毎に再計算して連続的に生産を運営することは限りなく不可能です。また、現在の工場はセル生産や屋台生産が普及して生産現場自体はリアルタイム化しています。リアルタイム化した製造ラインを駆使してタイムリーにユーザーに納期を回答することができます。ところがバッチのMRPではこうしたリアルタイムな納期回答/座席予約は不可能ですし、日々刻々と流れるセルや屋台にタイムリーに部品を供給することもできません。このためにMRPよりもっとリアルタイム化した生産管理システムが必要になってきたのです。

【図1】
図1:未来在庫更新の仕組み

MRP計算は想定したバケットの範囲内で在庫の推移を独立需要も従属需要も含めて計算しますが、従来の在庫マスタは時間軸を持っていなかったので、それを記録して活用することができませんでした。 リアルタイム生産では、全ての品目の在庫が時間軸を持っていますので、計算したバケットまでの在庫は未来にわたるまで更新されています。

-納期回答/座席予約

基本的な考え方として、バッチ計算のサイクルを限りなく短くすることにより、リアルタイム処理は実現されると考えられます。しかし、MRPも一種のバッチ計算ですが、前述したようにMRPは工場のアクティビティーを全てまとめて計算するので1日に何度もまわせる処理ではありません。また、全てをまとめて計算する弊害もあり、いろいろな製品に使用できる品目をまとめて発注するのでひも付け(ペギング)が手動でないと(またはルール化されてないと)上手くできず、それによって特定製品の納期もすぐに回答できない生産システムでした。更に、リアルタイム化した現場(セル生産、屋台生産)にタイムリーに部品を供給することもできませんでした。

これらの問題を解決するために考案されたのが、納期回答/座席予約やAPS(Advanced Planning & Scheduling)と呼ばれるリアルタイム生産でした。リアルタイム生産を簡単に説明すると、受注単位に小MRPをまわして納期を回答するなど、出庫指示や製造指示をその場で出して座席予約をするシステムです。このリアルタイム生産システムを実現するためには生産管理のバイブルである部品表が座席予約要件となります。工程、リソース、品目等の情報を時系列で管理できなくてはならない(統合化部品表)のと同時に、在庫などの生産管理のデータにも時間軸と空間軸を持っていなければなりません。

それでは次章で納期回答/座席予約におけるいくつかのスケジューリング手法について説明します。

納期回答/座席予約におけるスケジューリング

1. フォワード・スケジューリング

フォワード・スケジューリングとは、本日を起点として工程を並べて、それぞれのリードタイムを足し算し、最早着手日から最早完了日を算出するスケジューリングです。
これはPUSH型生産に対応したスケジューリングでもあります。このスケジューリングの特長は、材料が容易に手に入るような品目に適していて、それぞれのリードタイムを単純に足してゆくことによって最早納期を算出します。MRPも基本的にはこの考え方に準じています。このスケジューリングの利点は、早めに生産することによって工程途中のトラブルや納期遅延に対応しやすくなるということが考えられますが、欠点としては生産変動に弱いという点や、仕掛在庫が増えるという点があります。

フォワード・スケジューリングをガント・チャートと部品表で表現すると以下のようになります。

【図2】
図2-1:フォワード・スケジューリング
図2-2:フォワード・スケジューリングのリードタイム
図2-3:フォワード・スケジューリング ガント・チャート

2. バックワード・スケジューリング

バックワード・スケジューリングとは、納期から逆算して工程を並べそれぞれのリードタイムを引き算して最遅完了日から最遅着手日を算出します。これは、かんばん方式と同じPULL型生産に対応したスケジューリングでもあります。このスケジューリングの特徴は、材料が容易に手に入らない品目のスケジューリングに使われ、下位品目の納期を確約して積上げて最遅着手日を決定します。このスケジューリングの利点は、ギリギリまで着手を引っ張って延ばしているので生産変動に強いということと、リードタイムが最短になるので、仕掛在庫も最小となる点です。ただし、納期に対する自由度はゼロなので、途中の工程で何かのトラブルが発生した場合は納期遅延を引き起こします。かんばん生産ではこれを防ぐために自働化という、後工程に不良品を流さないことを強力に推進しています。
バックワード・スケジューリングでは、下位品目から資材所要量計算を行って納期を確約し、計画をスケジュールする方式をとります。その意味では、下位品目から上位品目に向かってMRPをまわしてゆくような計算を行います。
バックワード・スケジューリングをガント・チャートと部品表で表現すると以下のようになります。
図2-4:バックワード・スケジューリング
図2-5:バックワード・スケジューリングのリードタイム

フォワード・スケジューリングと違い、バックワード・スケジューリングは簡単ではありません。リードタイムを単純に逆算しても途中の工程の資材が入手できないだとか、ある工程が負荷オーバーで計画通りの納期では生産できない等、様々なできない理由をできる計画に再計算しなければならないからです。
そのため、受注数が1000個の品目を10月30日に納入しようとしても、10月30日分は700個で残りの300個は11月15日ということもありえるのです。
リアルタイム生産の良いところは、情報をその場で瞬時にはじき出すことができるという点にあります。フォワード・スケジューリングは、前述のような不測の事態に対応する手段がないためリードタイムを納期割れしないように長めにとることが多く、当然在庫は増えることとなります。
図2-6:バックワード・スケジューリング ガント・チャート

3. スクイーズ・スケジューリング

前述のバックワード・スケジューリングとフォワード・スケジューリングを組み合わせたものがスクイーズ・スケジューリングと呼ばれるものです。
これは負荷調整の不要な比較的材料が手に入りやすい品目をフォワードで機械的にリードタイムを足し算して計算し、材料が容易に手に入らないなど、負荷調整山崩しが必要な品目をバックワード・スケジューリングする方式です。 この場合の納期設定は、バックワードでスケジュールする品目を計算したあとに、そのバックワード・スケジューリングの最遅着手日から起算してフォワード・スケジューリングする品目を計算するものですが、各ノード(各レベル)にそれらのフォワードとバックワードの計算対象の品目が存在するモデルの時は必ず同じノードでバックワードの最遅着手日を計算し、そのノードの最遅着手日からフォワードの品目のスケジュールを計算するようにします。

4. カットイン・スケジューリング

カットイン・スケジューリングは、日本語では“内取り”とか“計画流用”と呼ばれます。
既に計画済みの一部の計画に緊急の計画を割り込ませるものです。簡単に説明すると、鮨屋でカウンターに座って「マグロを4貫握ってくれ」と注文して3貫まで握ってもらったらコハダを食べたくなったので、急遽マグロをコハダに変更してもらうということです。鮨屋のカウンターの在庫(セルや屋台の在庫と考えてください)にはコハダが存在するのでこのような計画の変更がリアルタイムで可能となります。しかし、コハダの代わりに梅のおむすびを注文しても鮨屋のカウンターでは作れません。鯛や穴子であれば可能です。
カットイン・スケジューリングとは、屋台やセルの在庫や能力の範囲で自由に計画の変更を行うものです。一見すると当たり前のことなのでそんな計画変更になぜわざわざ名前など付けるのかと思われるかもしれませんが、MRPという現在の製造業の生産管理システム上ではこれが不可能なのです。その理由は、MRPは工場全体の資材所要量の計算をある時点の在庫をもとに(ということは、1ヶ月に1回か、1週に1回か、かなり細かくても1日に1回 < これは不可能かもしれませんが > )計算する大バッチ・プログラムなので、リアルタイムに動いている生産現場に的確な指示を与えることができないのです。ですから、営業から飛び込んできた緊急の注文をリアルタイムに現場に指示するということは長い間不可能でした。カットイン・スケジューリングはそれを実現するためのフレキシブルなスケジューリングなのです。
カットイン・スケジューリングのイメージを図式化してみましょう。
製品αと製品βは一部の工程と部材が共通で(工程3,2,B,C)、後の作り方と材料は異なります。そのαの計画が連続するライン(セル、屋台)にβの計画をカットイン(内取り、計画流用)する場合のモデルを以下に説明します。


図2-7:カットイン・スケジューリングのイメージ α 図2-8:カットイン・スケジューリングのイメージ β 図2-9:カットイン・スケジューリングのイメージ

上記の計画にβを1月9日の納期で割り込ませると以下のようになります(βはバックワード・スケジューリング、αはフォワード・スケジューリング)。
図2-10:カットイン・スケジューリング

以上が納期回答/座席予約における代表的なスケジューリング手法となります。


IBMは、International Business Machines Corporationの米国およびその他の国における商標。
他の会社名、製品名およびサービス名等はそれぞれ各社の商標。
無断での転載、複写、翻訳、データベースなどへの入力を禁じます。
社外からの寄稿や発言内容は必ずしも弊社およびIBMとその関連会社の見解を表明しているわけではありません。

製造業向けソリューション

ECObjectsを使った製造業向けソリューションおよびサービスをお探しならIASCへご相談ください。

ECObjects

統合化部品表ソリューション ECObjects/TotalBOM


メールでお問い合わせ

このページに関するご意見・ご質問はこちら