小さな入力：
1.プロジェクトは閉じられています。 自分用に設計されています。
2.開発環境は重要ではありません。 制約の理論のアルゴリズムは単純な数学です。つまり、利用可能なプログラミング言語によって実装されます。
3.すべてのメモは、私たちの実践を世界と共有する試みです。 インターネットで理論を探してください。
だった
マネージャーは、在庫のある製品の数を確認し、これに基づいて、生産計画で倉庫注文を出しました。 しかし、自由な時間がある間に何かをするという原則は、それ自体が生き残っています。 ある製品の在庫が10個あるとします。 マネージャーはこれでは不十分であると判断し、生産に「50個製造する必要があります」と伝えます。 50個を処理しながら半分を出荷することができました。 再び倉庫の注文。 そして円で。 このようなスキームの欠点は明らかです。 「Fonarevリファレンスブック」のすべてのデータ。 ワークショップは、生き物であるにもかかわらず、簡単に制御できるアルゴリズムに従って動作することを決定しました。
になっています
マネージャは、システムが監視する位置を選択します。 ソースデータを入力します。 最初のバッファのサイズだけで十分であり、これは最後に行うことです。 さらに自動操縦。 初期バッファー（インターネット上の定義を参照）は、システムが自動モードに入るためにプッシュするものです。 以下のスクリーンショットに示す例を使用して、初期バッファーのサイズを決定します。 期間は12か月です。 平均在庫13 750個 離職期間は約17日間です。 つまり、17日間で約14,000ユニットを販売します。 これらのデータはアクティブなデータベースから取得され、各時点で最新のものであることに注意してください。 練習から、快適な作業のために、約1〜1.5か月の在庫が必要です（製品によって異なります）。 約20,000台の在庫を保管する必要があることがわかりました。 これは初期バッファーのサイズです。 ここでは精度は重要ではありません。 25,000個インストールできます。 一定期間後、システム自体が現在の出荷と倉庫への到着に基づいてバッファを調整します。
それだけです さらに、システムは、選択した位置の追跡を開始し、重要なポイント（レッドゾーン）に達したときに計画に配置する必要があるものを通知します。
青は過剰生産です。 緑は過剰です。 黄色は快適です。 赤は危険です。 黒は穴です。
次回は動的バッファについて説明します。