POSシステム、KIOSK端末、生産管理は日本NCRビジネスソリューション株式会社へお任せください。
ホーム > 商品・サービス情報 > 製造業ソリューション > TPiCS-X > TPiCSとスケジューラの連携を考える
あるお客様向けにTPiCSとスケジューラの連携ソフトを提供することになりました。
今回はその作成について考えたことを踏まえて、連携ポイントと今後の課題なども含めて紹介したいと思います。
はじめに
ポイントでも少し書きましたが、生産計画というのは、将来、例えば3ヶ月先などは非常に大まかな計画を立てます。それが、1ヶ月、1週間、3日、1日、午前・午後、×時×分と、今（現在）に近づくに従って細かくなってきます。これを計画の「粒度」という風に捕らえているようです。MRP方式は良くも悪くも「タイムバケット」で規定されています。そのため、日バケットで運用した場合に、本日（現在）に近づけば近づくほど計画が「粗く」なるという事象が出てきました。典型的には納入指示が日時指定である場合、TPiCSの日バケットでは計画を表しきれない訳です。（下図参照）
概念的には上図の様に、2ヶ月先は「月バケット」、1ヶ月先は「旬バケット」、当月は「日バケット」で3日前から「時間単位」というような計画の範囲だとすると、TPiCSではシフトを組んで対応しても最後の「時間単位」計画は難しい。(逆に1日を2分割程度ならTPiCSのシフト使用も検討対象になります）「スケジューラ」という言葉がよぎる第一の要因がこれではないでしょうか。
もう一つの要因は、計画の重なりです。MRPは能力をバケット単位にまとめます。MRPは負荷を無限山積するのが問題ですが、それよりも、1個作ろうが10,000個作ろうが設定されたリードタイムで割り付きます（1日とか）。また、次工程とのつながりがバケット単位なので、現場では部品が出来ているのを目の当たりにしながら、完成入力が無いので待つというような計画が作られる場合があります。（TPiCSでは単位製造リードタイムという考え方で計画数によりリードタイムを可変にできる方法があるのですが、調達リードタイム（固定期間）との兼ね合いを考えるとどうしてもリードタイムを長く設定せざるを得ません。その面でこの部分は難しい問題を含んでいます）
(1)MRPだとバケット（上記では日バケット）とリードタイムの関係で実際に生産能力が
あっても二日に渡って割り付く場合がある。
(2)同じデータをスケジューラで計画すると工程毎の重なり（計画完了前でも数がまとまると次行程に渡す）や計画数量による作業時間策定をするので、より短期間(短納期）で製造できる計画割付を行なうことができる。
上記ではまるまる1日分リードタイムが削れる事になる。
この2つの「いいとこどり」ができないかというのがこの連携という発想です。
遅ればせながら、連携の意味は「互いに連絡し協力すること」という意味です。
残念ながら、当方はスケジューラの方の動きを全て把握していませんので、基本的にスケジューラは今回使用したものについて(固有）の動作を元にしています。これを解消する優れたスケジューラをお持ちのソフトメーカー様は是非連絡ください。
また、当然どのような方にもマッチするというのでなく、例えば、
a.計画単位が時分などの短い時間単位でのスケジュールを(真に)要求している。
b.MRPの機能だけでは山崩しが難しい工程割付（機械もの）がある。
ただし、bは、MRPの生産計画をスケジューラに渡して崩してやれば良いという「一方通行」型の連携？だと思います。
※マスター管理の問題は誰にもわかる事ですが大きな問題です。
「日本には製番管理という優れた管理方法がある」という事を良く聞きます。そんなわけで、製番管理に関する本を読むと、「製番管理は計画を確定しない（製品構成の変化ができることだと思います）MRPは計画を確定する（同様に構成が確定していなければならないから）」というような表現がありました。」これはこの表現で正しい事だと思います。しかし、生産計画を立てる方からすれば全く逆になります。製番はその工程（プロジェクト）全てが確定されます。これに対してMRPではバケット単位で確定し、それ以降の未確定バケットの計画変更を許すという動きをします（TPiCSではそうです）ですので、製番は本日から未来方向に向かって工程が確定されるのに大して、TPiCSでは確定されたバケットが（本来）計画確定され、それ以降の計画はどうにでもなるという立場です（当然途中で中止もできる）。スケジューラ=製番ではありませんが、考え方の基本は似ていると思います。ただし、製番管理を中心にした生産管理ソフトを幾つか（表面的ですが）見させてもらいましたが、それぞれ何とか使い易いようにという様に工夫を凝らしています。
(1)はA-A1の構成だとします。TPiCSでN日を一律確定しました。その場合当然ですが、N+1のAという工程は確定されません。
(2)スケジューラではN日の計画が確定されるとその後工程も確定されます。（というよりもスケジューラは最終工程からすべてのスケジュールが紐付けされていることがポイントです。例えば上記でA1が初工程だとすると、このプロジェクトが着手された事になり、従ってこれに携わる全ての工程が確定されると言うことです）
さて、この2つを一緒にしてみましょう？（これを今回は連携と考えます）
どうでしょう？
計画確定が今日(N日）と明日(N+1）ですのでまだ良いですよね。（本当は、良くないですね？）すなわち、（TPiCSで）確定期間としてはこの場合アイテム（品目）AのN+1も確定にしないといけません。
(TPiCSでは、「未確定期間」に「確定計画」を登録すると、そのバケットを「確定期間」として認識します。この措置は、スケジューラの「確定」、「未確定」のズレを吸収する方法として有効だと思います）
（注意点：スケジューラに共通部品を入れるのは要注意です、何故なら上の例のような確定システムでは、例えば1年分の共通部品を単価が安いので買ってしまう（ロットまとめ）と向こう一年間の計画が確定してしまいます。）
⇒この点を元にまとめると、連携上、部材は基本的にMRPを使用します。そして工程の手配をスケジューラで行ないます。理由としては、
(1)スケジューラとMRP(TPiCS）の計画確定方法の違いから、調達リードタイムの長いパーツやまとめて購入する共通部品をスケジューラの連携対象にする事には熟考が必要です。
(2)また、部材の発注や受入の時間単位が(一般的には）あまり厳しくないという事です。日単位でも充分対応できるのでは無いでしょうか？
という事(仮説）です。
さて、今一度、スケジューラの計画とTPiCSのf-MRPの割りつき方を比べてみましょう。（しつこいのですが重要です）
（余談ですが）今回の連携でチェックしなければならない事が3点ありました。
(1)最初の計画（例えば、今日）
(2)次の計画(例えば、明日）
(3)その次の計画(例えば、明後日）
が、（制約事項を除いて)きちんと動く事です。
(3)は今回の連携で掴んだ経験則です。
普通は、イニシャルの1回とその計画変更の繰返しですから「2回」で済むはずですが、今回の連携をするにあたって、「3回計画を回さないと判らない事象」が出たのです。(本当です）
A-A1-A2という構成を考えます。最終製品(例えば組立工程)Aがあり、その前にA1、その前にA2という構成です。それぞれ丁度1日で製造が可能で、さらに、MRPのバケットもスケジューラのジョブも（偶然にも）同じ1日に割りついたとします。
MRPの方で本日のA2の工程を確定します。すると以下の様になります。（水色の部分が確定）
スケジューラーで確定します。
Aを作成するプロジェクトが開始したため、
これに関する全ての工程が確定します。
この場合、途中で計画の変更がある場合に少し厄介な問題に遭遇します。図ではたった3日の期間ですので現実として問題は少ないように見えてしまいます。しかしながら、ここで、計画の変更可能性がある場合はどうでしょう？例えば、製造リードタイムが3日のうち、納入指図(確定注文）が納入2日前の場合はどうでしょう？すなわち最初のA2の工程は、内示データや見込み生産計画で製造しなければならない場合です。
以下は概念図です。一日経過して、上図で言うと「N+1日」が「N日」（本日）になりました。昨日確定したA2の70は確定計画ですが、A1、Aは注文確定し数量が80になりました。
その場合、
上記の様にA、A1については、TPiCSとしては本日計画変更で70→80と数量変更されます。
しかし、A2は10個足りないので当日(N+1日）に新規手配されます。これをスケジューラが計画を作成する場合はどうなるかと言うと、今までの70の計画は手をつけずに、新規に10の計画が作成されます。そして、問題の焦点は、この2日間で最終製品まで組み立てられるか？になります。
さて、次に減産の場合です。70の受注が60になりました
N日はすでに過去になりますので、手配もしているし実績も入ってくるでしょう、基本的には変更不可だと見なします。さて、ここでの動きの違いは、TPiCSは（確定期間の設定にもよりますが）ぎりぎりのところまで計画変更を可能にできるので、A、A1ともに、単に60と計画数が変更になり、A2の在庫が10残ると言う結果になります。ところが、スケジューラはこの場合最初の工程が着手されたので全工程70という計画数を変更できず10の完成品を作成することになります。（※そうならないスケジューラもあるようですが？）
このように、TPiCSと組み合わせるスケジューラの機能により連携の状況は大きく変わります。TPiCSとスケジューラ双方の動きを理解し、さらに生産計画を含めた業務運用設計をしっかり立てた上で連携は採用するべきだと思います。それは、TPiCSとスケジューラの双方で計画上のなんらかの矛盾が出る可能性があるからです。
連携時に製造指図をTPiCSで行なうのかスケジューラで行なうかは重要な問題になります。また、その時のTPiCS側の連携オペレーションの流れは、「TPiCSユーザーズマニュアル（環境設定編）」を参照ください。
今回はスケジューラ側で製造指図をする方式を取りました。この選択の要因としては、
(1)製造指図時の要求時間がTPiCSのバケットより細かい（短い）場合はスケジューラ側で製造指図をします。（TPiCSの製造指図での時間の持ち方と中間ファイル（Plan.Csv）が時間を持たない事によります）
(2)計画単位がTPiCSのバケットレベルで特に問題が無い場合は、TPiCS側で伝票発行する運用も可能です。(スケジューラはあくまでTPiCSの決めた生産計画の負荷調整に使用する場合など）
また、(1)と(2)のもう一つの違いは、
(1)の場合計画確定をスケジューラで行なう。（スケジューラメインの生産管理システム）
(2)の場合計画確定をTPiCSで（原則的に）行なう。（TPiCSメインの生産管理システム）
に有ると思います。後者（TPiCS指図の方式は深く考察していないので余りコメントを記せません。（TPiCSでの事後処理が結構あるようでマニュアル上のお薦めは(1)になっています）
※あるセミナーで基幹系とスケジューラの連携というタイトルですので拝見しました。その時のシステムは基幹系（ERP）で伝票発行していました。この場合の要因の一つは採番管理の問題でERP側で制限があるためだそうです。
TPiCSからスケジューラに対してスケジューラで言う「受注」を受け渡します。その戻りデータとして、スケジューラが各ラインや機械に割り振った計画数を個別に受付けるために、TPiCSの複数ロケーションを使用しました。
これが最初のアイデアでした。
TPiCS側で、客先からの「受注」を取り込みます。
(1)まず、計算するレベル(親子レベル）を設定しスケジューラに受け渡すアイテムに限定して所要量計算をします。そうする事で在庫を引当された後の製造オーダが計算されます。（TPiCSではこれは基本的に「主担当」という製造担当に割りつきます）
(2)このデータをスケジューラ側に受け渡します。（このスケジューラでは受注と言います）
(3)スケジューラはこのデータをスケジュールロジックに合わせて各資源(ライン）に割り付けていきます。
(4)TPiCSとスケジューラ間のマスターでこのラインNoや資源名を共通にしておき、スケジューラの計画をTPiCSの複数ロケーション機能（複数製造場所）でそれぞれ1対1にデータを受け取ります。
※TPiCS側のマスター設定
また、TPiCSで受け渡すデータで受注による変化数量を出すために、スケジューラに渡すべきアイテム（品目⇒スケジューラ側の最上位品目）のTPiCS側のマスターは、ダミー製造担当を設定し、これを「主担当」とします。その主担当アイテムマスターの「伝票発行期間」は”-1”にします。そうする事で、この主担当アイテムはTPiCS側では「（計画）確定」できなくなります。同時に、複数ロケーション”1”に設定しスケジューラの戻りデータは全て主担当以外で受付けます。この主担当のアイテムは親計画（上位品目や受注）の変化があった時に「既計画」や在庫と比較し、不足があれば計画追加(数量変更）をします。当初は上図の様に、現存ラインからデータを連携ファイル(Plan.Csv）に出そうとしましたが、確定期間後の追加注文（特急）に対して上手くデータを抽出できないという事からマスターを変更して対処しました。
このような「連携上」の理由もありますが、TPiCSとスケジューラの間のマスターは必ずしも同期させる必要はなさそうだとの見解を現在は持っています。
【追記】（2005/12/02）この未確定製造担当確定（固定）製造担当を複数ロケーションで分けるやり方は、今回のスケジューラ連携では問題点が内在していました。今回、TPiCSからスケジューラにデータを受け渡す時に、ステータス「N」のものをスケジューラ側は「新規受注」として取り込みます。この場合、当初計画に対して数量が増える(増産）ならば問題は無いのですが、数量が減る（減産）の場合に対応できません。この点に関しては、お客様に指摘を受けました。（この対応に関しては、お客様側で行っていただきました、これは、お客様のノウハウなので、ここに記述しません。ご了承ください）また、この様なマスター変更をしなければならないのは、TPiCS側の仕様でもあります。今後TPiCSを利用してスケジューラ連携を取る意向のある方は、TPiCS研究所での「管理番号4342Z」の対応をする事でこのマスターの煩わしさから免れる可能性があります。また、その他にもいくつか要望を出していますので、必要とあればお問合せください。
（備考）製番については、Plan.csvでは対応が取れていませんが(Ver3.1）、私見では製番構成データを直接利用した方が良いように思います。いずれにせよ、TPiCSにもある程度の負荷調整機能はありますが、加工機などの割付けなどTPiCSでは満足に割付けられない場合もありますので、この点は今後も考えなければならない要素だと当社では思っています。
（以上）
【参考】TPiCSを部材購買、スケジューラが工程指図と機能を完全に分ける場合
上記のマスターは必ず均等に作成しなくても良いという考え方を推し進めると、TPiCSのマスターで複数ロケーションを資源の数だけ用意する必要性があるかどうか？が検討材料になります。例えば、在庫の移動・保管場所の管理をある程度徹底したいのであれば以下のやり方は実現できませんが、「マスター登録を簡単にしたい」、「TPiCSとスケジューラの役割を明確に分ける」のが可能ならば図のようなマスターが可能になると思います。
TPiCSのマスターは未確定の計画が戻る主担当と、確定計画が戻る担当の2種類です。スケジューラにデータを受渡し、スケジューリングした後、（スケジューラ側で）計画確定します。「確定」計画は指図書を発行します。データをTPiCSに戻す時には、この指図をした「確定計画」をTPiCSの確定計画用のアイテム側に戻し、未確定はもとの未確定計画のアイテムに戻します。こうする事で、マスター登録の標準化をする事を推し進めます。（品目の他は製造担当が2つ設定すれば良い）また、最近TPiCSに「CADデータ変換オプション」が出ましたので、スケジューラで登録したマスターからTPiCSのマスターをある程度自動作成できる方法があるのでは無いかと思います。（ただし、在庫場所の概念が薄くなるので要注意です）
【追記】（2005/12/02）この点でもある種の問題が残りました。複数ロケーション「4」を利用すると後工程担当を保管場所に入れるので、「未確定計画用製造担当」と「確定用計画担当」の2つのオーダーが出る事になります。その為に、複数ロケーション「4」を使用しないか、する場合は未確定計画も「確定用計画担当」に（ステータス「N」）計画を戻す必要があります。(以上）
TPiCSではバケットという形で、1バケット(例えば1日）で幾つ作るかという計画で、例えばこの場合0:00分～23:59までに（総数）ｘｘｘ個というイメージです。そのため、1バケットの状態が「（計画）確定」もしくは「未確定」という捕らえ方は簡単に出来ます。
ところが、スケジューラは更に細かい計画を立てます。そのために、計画確定期間をどこにするかは「時間軸」上のどこにあっても良いわけです。
TPiCSの側から見ると、バケット毎に「確定」、「未確定」が決まるが、実際にスケジューラとの連携を考えると「同じバケット内に確定・未確定が混在する」事になります。以下の様にTPiCSでは「確定」なのに、スケジューラの計画では「未確定」が残ると言う事が（頻繁に)起こる可能性があります。
対処法
(1)（現行）TPiCSの仕様を利用します。「確定（計画）期間」に「未確定計画」が入る、「未確定期間」に「確定計画」が入ると自動的にTPiCSはそれぞれ未確定計画を「確定」します。この時、TPiCSが付番した注番（製造オーダーNo）とスケジューラ側で計画確定させた注番が原則異なりますので、この注番の差を利用し、TPiCS注番(デフォルトではWW）でスケジューラ対象アイテムの注残データは「未確定」データだとする方法です。
この方法はTPiCSとスケジューラの計画データの同期を取るために必須ですが、本来の製造指図以外の注残が発生するという弱点があります。また、これらの注残のメンテナンス(本来不要ですから削除していかなければなりません）も考慮に入れなければなりません。
(2)上記の「確定担当」と「未確定」担当を分けたマスターを作成しそれぞれにスケジューラからの「確定」「未確定」を対応させてデータ戻しをする。これは、原則的に(1)のような注残は発生しないので(1)より優れていると思います。今後連携を考慮する場合はこのようなマスターになると思います。
TPiCSとスケジューラは「時間」の捉え方が異なるので無理やり連携を取るとデータの整合性が取れません。そのために考案したのが上記のバケット内の「確定」「未確定」期間の混在方法です。この方法があるので、基本的にはどのスケジューラとTPiCSの間でもデータのやり取りができる可能性が出来ました。この考え方は、「TPiCSユーザーズマニュアル（環境設定編）に、それとなく書いてあります。
TPiCS-Xから渡す計画には、ユーザーが指定する過去日(本日の何日前)のデータを含め、全計画データを含みます。また、TPiCS-Xからの計画データを読み込む際、スケジューラは前回未確定計画であり、かつ今回TPiCS-Xから受け取る計画データに存在しない計画を、全て削除します。連携に関して検討を始めた当初、この項目は理解不能の状況でしたが、現実に連携を実装するとこの記述の方法が現在のところベストだと判ります。
以下の図を見て頂くと判りますがパズルのピースがきっちり噛み合うというイメージです。合成イメージ（下の方の図）の赤枠内のデータを相互で受け渡す事が可能になります。
ここまで、来るとスケジューラ等が得意な方ならイメージが湧くと思います。
連携データを最初にTPiCSからスケジューラに渡した時（イニシャル計画、当日）は何も既存計画が無い状況から計算しますので余り問題がないはずです。
問題は次回（2回目以降)の計画になります。
ここで、スケジューラとTPiCS間のデータの保証に関して今回はこのような考え方をしました。（当たり前な事ですがすぐ忘れる事です）
「計画を保証するのは、TPiCSかスケジューラのいずれか一方になり、他方はそのデータに従属する」
今回はスケジューラをメインにするのでTPiCSはスケジューラに従属します。
また、スケジューラに全ての計画があるので、TPiCSからスケジューラに行く計画は基本的に「消去」（リセット）されます。それが、スケジュ－ラの本質的な計画策定方法と合致しています。（ただし、データの連携可能≠連携可能）
以下、現実の生産計画をする上で当たり前だが、連携上上手く割り切れない事を考えていきます。（結論はありません）
(1)在庫引当の問題
(2)中間工程の単独計画
(3)既計画の実績による修正
スケジューラが本質的に自分で計画したスケジュールの進捗を管理しないのならば、在庫引当の問題は常に残る事になります。また、このような面からスケジューラ在庫引落しを断念された方もいるでしょう。結論から言うと、スケジューラに在庫引き落としの機能があり、スケジュールする時点で欲しい在庫データは「有効在庫」であると言う事です。(下図の場合、現実に今回の計画で引当可能なのは水色の部分だけです）また、現在庫は倉庫にはその数が現物として存在するという事も考慮要因です。
有効在庫照会などの機能を持つ生産管理システムも多々ありますが、ほぼMRP計算と同じになるので、「お手軽」に計算させるという訳には行かないのではないでしょうか。また、それでも厳密に言うと、MRPのタイムバケットとスケジューラの入出庫のタイミングが異なります。そのため、時間的なバッファを持たせて、未来の在庫計画の完成日を引当可能日とするのではなくその翌日にするなどの「細工」(決め事・妥協？）が要りそうです。そうすると計画精度が落ちるという事もあります。（このあたりは要検討です。）
TPiCS単独使用ではこの面での考慮は当然ながら不用です。スケジューラ用のデータを用意しようとすると厄介です。
(1)スケジューラは工程計画は製番の様に全て紐ついています。そのため、どの計画がどこで引落されるかは特定できます。
(2)TPiCSは親計画が必ずしも特定できません。TPiCSの「引落明細」から在庫計算をする事が出来ないので、現在の注残が消費されると見なす必要があります。
有効在庫を計算する【試案】
この場合スケジューラが計画した各々の(確定）計画に着目するとこのような関係になるかと思います。
有効在庫（スケジューラが引当可能な在庫数）
＝「現在庫」-{「スケジューラが立てた確定計画の実績」-「スケジューラが立てた確定計画の親工程の引落数（実績、もしくは理論値）} ・・・（をジョブ番号毎に集計したもの）
また、その時の引落し状況は大きく4つ（3分類で良いかもしれません）
| 後(親）工程のステータスによる増減 | 調整方法 | 備考 | ||
| 1 | 後工程が確定 | 完納 | 理論値としては増減なし（現工程実績による増加-後工程の引落し） | 完納状況を毎回計算させない方法(フラグを立てるなどの措置が必要） |
| 2 | 後工程が確定 | 未納（実績なし） | 後工程の引落し量を差引く（もしくは、後工程が未確定と同じ） | Plan.Csvの利用も考慮 |
| 3 | 後工程が確定 | 分納 | 後工程の引落し量を差引く（もしくは、後工程が未確定と同じ） | Plan.Csvの利用も考慮 |
| 4 | 後工程が未確定 | 後工程が全数引落すという前提で現在庫から差引く | スケジューラが後工程を特定(紐つけ）できること（必須） |
そうすると、在庫データを受け渡すに当たって、必要なTPiCSのファイルは、「在庫一覧」「注残一覧」「引落明細」「引落実績」「実績データ」（Plan.Csvの「内完了数」も条件付で使用できそうです）などが上げられます。在庫データは動的に変化しますので、スケジューラのデータだけではコントロールできません。また、在庫の引当を考えない計画は計画数が多めに設定されたり、誤ったリードタイム設定に陥るという危惧があります。ただし、これはあくまで「システム的な発想です」。
また、スケジューラがロットまとめ、不良率設定などをしない限り、在庫計画はされません。特に中間工程の単独計画は難しいはずです。これは、TPiCSの問題も含めて次項で検討しましょう。
【参考】もう一つの方法「ご破算」式
これは、あるスケジューラの機能が限定されている事を元に考えたものです。スケジューラメーカーにとっては反論のある方法かもしれません。いつか実験してみたい方法です。
生産計画に関して言えば、最初に立てた指図がそのまま実現される訳では無いわけです。逐次状況が変化する中で、次の手を打ち続けなければなりません。しかも、（マーフィーの法則）一般的に「悪い」方向へ進みます。
例えば、以下の図で、水色は未実績を表します。工程Yの左から2番目の指図が例えば機械故障で着手できませんでした。しかし他の機械が稼動できたのでそれ以降の指図は実現しました。そのため工程Xは指図順で作業を行い左から3番目までの指示を完了しました。TPiCSではこの間の「紐」は余り重視していないので余り問題は無いのですが、スケジューラではこの様な紐付けを無視した（現場では当たり前）実績入力に対しての明確な回答はありません。
また、右端に「現在」の線がありますが、この状態で未実績(水色)の部分があります。これは既に「遅れ」として実現できない計画ですから、速やかに「次善の手」を打たねばなりません 。
更に、以下の様に不良を加味した再手配の問題もあります。
現場としては、上図の様に可能ならばすぐリカバリに掛かると思います。そのような状況を元にスケジューラで、どの様に回答をするのかは(カスタマイズ可能なものは別でしょうが）なかなか難しい問題です。
(1)計画数どおりに作れない場合がある。
(2)計画時間までに作れない場合がある。
(3)計画順序を守れない場合がある。
という事は、スケジューラ強力なフィードバック機能が必要になる言うことです。(が現実には膨大な計算量になりそうですので難しいと思います。また、それをAPSと呼ぶ場合もあるようです）
このためのフィードバックとして、
(1)各種在庫データ
(2)各種実績データ(完成実績、引落実績、計画外実績などなど）
また、フィードバック期間も考慮しなければなりません。
（ほぼリアルタイム、秒、分、時、日、週、旬、月・・・・）
カオス理論では当初ちょっとした差異が繰り替えされるたびに複雑な動きをしてとんでもない事象を引き起こす事があるとしています（ある地方の小さなつむじ風が巨大台風の原因になるとか）。現実の工場ではその前に現場の人や物理的な制限で露呈するものですが、少なくとも、スケジューラとTPiCSの連携での計画データを信じてもらえなくなるでしょう。
そこで、毎回スケジューラのたてた計画を「ご破算」にするとどうでしょう？過去の計画は無意味ですので計画時点で一度清算します。
たとえば、以下の様に現在の（システム上）の現在庫数を計算します。
これに対して、現在の受注残を再度スケジューラに入力して計算します。
そうすると、誤差の範囲が狭まります。また、不良などにより実績数が下回った中間工程は適宜調整された計画となります。
ただし、大きな問題点が1つ、上記の図での敢えて表記しなかった間違いがあります。それは、計画策定時点と実指図との間の時間差についてです。下図の赤色四角枠内は予測値でしか計画が立てられない事になります。これは、製造現場により解釈が分かれますが、
(1)計画立案時間が（相対的に）短い場合
(2)製造リードタイムが（相対的に）長い場合は無視できます。
ただし、スケジューラの使い方が、MRPのバケットより細かい計画を立てる事が主眼ならば、多少の影響を覚悟しなければなりません。また、毎回スケジューラの立てた紐付けを断ち切るのでスケジューラの機能として何か影響が出ないかと危惧しています。
ただし、現場担当としては、今ある（計画策定時の理論在庫）ですが在庫でどこまで生産可能かというロジックになりますので判り易いと思いますが？
補足（2005/08/12)：いわゆるAPSは上記の様に直前の計画を柔軟に変更が可能なので、システムとしては面白いが、現実的な生産（現場)を考えると、あまりにも直前の手配変更は現実的に対応が出来ない場合が見られ、実際には適当な(計画）固定期間を設けて運用するべきとの見解もある。
これはスケジューラのマスターの組み方で実現できるものもあるようです。そういう機能のあるスケジューラ（そういうマスターが組めるスケジューラ）を元に考察しましょう。
その場合、TPiCSからのデータの受け渡し方に問題が出ます。TPiCSではいわゆるMPSという機能が生産計画表に統合されているので、独立需要数を抽出する方法がなかなかないのです。
品目Aは最終製品ですから基本的に独立需要しかありません。
ただし、A1が例えばユニットだとすると、（先行）見込生産する事もあり、親工程の品目Aの受注により計画される場合があります。TPiCSのMRP計算ではそれほど大きな問題ではないのですが、スケジューラでは、品目A-品目A1と紐付いた計画と、品目A1単独の計画とは別に（スケジューラの）受注に入れてあげねばなりません。なにしろ、それぞれ個別生産する形式になるのですから。その面を考えると、中間製品を（フレキシブルに）取り扱う事は非常に難易度が高い問題になりそうです。また、この単独で作られた中間品は、他の計画に振り返られるということもなさそうです。
この点は、スケジューラの機能をもう一度検証する必要がありそうです。
(続く2005/05/24）
スケジューラを過信する必要はなく、生産管理システムの運用スケジューラで対応するべきでしょう。逆にリスクをどのようにスケジュールするか（在庫計画）が肝心のように思います。
※文中のTPiCSとは、TPiCS-X（正式名称）のことを指します。
（リクナビ2011へリンクします）
（外部へリンクします）