生産計画・管理ソフトウェアの選び方: 確認すべきポイント
Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.
By Mirko Peters ·
生産計画・管理ソフトウェアは、計画、スケジュール、受注の進捗管理を担います。対象となる範囲、ERPの守備範囲を超える部分、計画担当者が適切なツールを選ぶ方法を解説します。
Automatically translated with AI from the original post. Read the English original
生産計画・管理ソフトウェアは、何をいつ作るかを決める支援をし、その決定どおりに現場が動いているかを確認します。主に3つの連携した業務を扱います。計画(何を作り、何を購買するか)、スケジューリング(どの受注を、どの設備・資源で、どの順番で実行するか)、そして管理(受注の着手、進捗の追跡、計画の修正)です。本記事は、すでにERPシステムを使用しており、それに加えて何が必要か、またどのように選ぶべきかを知りたい生産計画担当者を対象としています。
重要なポイント
- 生産計画・管理ソフトウェアは、3つの連携した業務を担います。何を作るかの計画、どの受注をどこで行うかのスケジューリング、そして計画に対する実行の管理です。
- ERPのマスタープランニングとERPのスケジューリングは別々のステップであり、一部のERP製品では、計画の実行時に有限能力が考慮されない場合があります。
- スケジューリングの層を導入する効果が出るのは、順序が重要な場合です。たとえば、複数の製品が共有するボトルネック、前の受注に依存する段取り時間、または同時に複数の制約がある場合です。
- ソフトウェアがスケジュールできるのは、工程表、所要時間、カレンダー、在庫データが許す範囲に限られます。ツールを比較する前に、これらのデータを確認してください。
- 1つのボトルネック工程でパイロットを行い、ツールを現在の方法と並行して運用し、計画と実績を比較してから適用範囲を広げてください。
生産計画・管理ソフトウェアは何をカバーしますか?
5つのステップから成るループとして捉えてください。計画、着手、報告、比較、修正です。多くのツールは1つか2つのステップに強みがあります。5つすべてに強いツールは多くありません。
Dynamics 365 Supply Chain Managementのマイクロソフトのドキュメントは、一般的なERPにおける計画ステップの姿を示しています。マスタープランニングでは、手持ち在庫、既存の供給、承認済みの計画オーダーからの所要量を扱います。不足分があれば新しい計画オーダーが作成され、計画生産オーダーには有効な部品表とルートが紐づけられます。
次はスケジューリングです。同じドキュメントでは、オペレーションのスケジューリングとジョブのスケジューリングを区別しています。オペレーションのスケジューリングは、生産工程全体を時間軸で大まかに見積もるもので、ルートをジョブに分解することはしません。ジョブのスケジューリングは、直近または短期の期間で、現場の個々のジョブを扱うために使われます。有限能力では、スケジュールは受注に必要な資源の利用可能性に左右されます。
制御とは、リリース後に起きることです。生産プロセスの概要では、スケジュール作成が終わり、資材をピッキングできる状態になると、オーダーがリリースされます。その後、進捗と消費量を報告し、完成品を受け入れて、オーダーを終了します。RWTH Aachen の FIR 研究所の研究者も、同じ考え方を継続的なフィードバックループとして説明しています。オーダーの状況とリソースの使用状況はERPシステムに戻され、計画データは実績データと常に照合されます。
重要なのは、このループを閉じることです。計画を作成するだけのツールは、計画ツールにすぎません。実際に何が起きたかを把握し、それに応じて対応できるツールこそが、生産計画・管理と呼べるものです。
ご使用のERPは既に何を行っていて、どこで限界がありますか?
まずは自社の管理範囲から始めましょう。ERPシステムは、ほぼ確実に所要量を計算し、計画オーダーを作成しています。多くの工場はそこで止まり、順序付けを表計算ソフトや計画担当者の頭の中で行っています。
その理由を1つの製品の詳細から見てみましょう。計画最適化に関する Microsoft のドキュメントでは、計画生産オーダーにはリリース済み製品の静的リードタイムが適用されるとされています。ルート情報とリソースの制約を使うルートベースのスケジューリングは、オーダーを確定する時点で行われます。計画オーダーへの変更は、次回のマスタープランニング実行まで計画全体には影響しません。さらに、オペレーションスケジューリングのページには、マルチスレッド化されたマスタープランニングをオペレーションスケジューリングと併用する場合、有限キャパシティは考慮されないと記載されています。
これは1つの製品に関する設計上の選択であり、欠陥ではありません。ただし、多くのERPシステムに共通するパターンを示しています。プランニングの実行は「何が、いつまでに必要か」に答え、「どの順序で、どの機械で、どの作業者が行うか」という問いには、別のステップで答えられます。Dynamics 365 Supply Chain Management をお使いの場合は、ご使用のバージョンが各ステップで何を行うかを確認してください。別のシステムをお使いの場合は、ベンダーに同じ質問を平易な言葉で投げかけてください。プランニングの実行はキャパシティを考慮しますか、それとも後から過負荷を表示するだけですか?
答えが「過負荷を表示するだけ」であり、かつ順序が重要な場合、スケジューリングの層を追加する意味が出てきます。それが高度な計画とスケジューリングの領域です。キャパシティ、カレンダー、資材、ルーティングのルール、優先度から、実行可能なスケジュールを作成するソフトウェアです。
ERPのスケジューリングを超えて、どのような場合に追加のツールが必要になるのでしょうか?
必要ない場合もあります。ルーティングが安定していて、キャパシティに余裕があり、段取り替えが少ない工場であれば、ERPの計画と熟練した計画担当者で十分に運用できます。次のような兆候が見られたら、スケジューリングツールの導入を検討してください。
- 1つのリソースまたは作業センターが生産量を決めており、その手前でオーダーが滞留している。
- 段取り時間が直前の作業内容に左右されるため、順序によって実際のキャパシティが変わる。
- 機械、工具、熟練作業者、資材など、複数の制約が同時に適用される。
- 計画担当者が、スケジュールを判断するよりも作り直すことに多くの時間を費やしている。
- 顧客から納期回答を求められるが、手作業で半日かけなければ答えられない。
これらのどれにも当てはまらない場合は、まずデータと現場での実績報告に力を入れてください。データの品質が低いままより優れたスケジューラーを導入しても、自信に満ちているが誤ったスケジュールが生まれるだけです。
ツールを比較するとき、どの機能が重要でしょうか?
カタログに載っている機能チェックリストは使わず、自社で最も難しいケースにツールがどう対応するかを確認しましょう。
- どの制約をモデル化できますか。機械、工具、シフト、スキル、ゾーン、資材の在庫状況などです。ベンダーには、最も難しい3つのケースを提示してください。
- キャパシティは有限で計算されますか。そのため、スケジュールは常に実行可能なのでしょうか。それとも、手作業で修正すべき過負荷を表示するだけでしょうか。
- 計画をコピーして1か所だけ変更し、両方のバージョンを比較できますか?
- 障害の発生後、再スケジュールにどのくらい時間がかかりますか。また、何がどのように動き、その理由は何かをツールが示してくれますか?
- 計画はどのようにして現場に届きますか。印刷物、画面、タスクリストのどれでしょうか?
- 進捗はどのように戻ってきますか。また、報告するのは誰、または何ですか?
- データはどこから来るのか、マッピングは誰が保守するのか、ルーティングが変更されたときはどうなるのか。
- プランナーは、ベンダーに頼らなくてもルールや優先順位を変更できますか。
- 研修やインターフェースの費用を含めると、3年間でいくらかかりますか。
これらの質問は、自社のデータを使ったパイロットで検証してください。サンプル工場でのデモだけでは、自社に当てはまるかどうかはほとんど分かりません。
どのようなデータが必要ですか。
どのスケジューリングツールにも、必要な材料は同じです。
- 工程順序、作業時間、段取り時間を含むルーティング
- 部品表と、各オーダーに適したバージョン
- リソース、カレンダー、シフトモデル
- 人の数が生産能力の上限になる場合は、スキルや資格
- 在庫と未完了の購買発注
- 各オーダーの現在の状況
特に注意すべきなのはルーティングの作業時間です。ルーティングでは作業に12分かかると定義されているのに、実際には20分かかっている場合、すべてのスケジュールは同じ方向にずれ、プランナーはツールのせいだと考えてしまいます。直近のオーダーをいくつか取り上げ、ルーティングの時間と実績を比較してください。そのうえで、ボトルネックの差異を最初に修正します。
どのように展開すればよいですか。
最初のプロジェクトは小さく、測定可能な形で始めてください。
- 対象とする領域を1つ選びます。通常はボトルネックの作業センターと、その前後の工程です。
- ツールが支援すべき意思決定を明文化します。例えば「どのオーダーを次に機械へ投入するか、また各オーダーがいつ完了するか」といった内容です。
- その領域のデータを整備します。対象はルーティング、作業時間、カレンダー、在庫です。
- 最初のスケジュールは、現在の方法と並行して作成してください。この段階では切り替えないでください。
- 数週間にわたって計画と実績を比較します。計画が外れた箇所と、その理由を記録してください。
- 変更に関するルールについて合意します。どのような場合に再スケジュールを行うか、また何を固定するかを決めます。
- 最初の領域が安定して機能してから、次の領域に広げてください。
仮定の例で、このパターンを示します。ある機械加工工場では、すべてのオーダーが5軸加工機を1台通過し、プランナーは納期順にスプレッドシートで順序を決めているとします。有限スケジュールを作成すると、同じ工具を使う2件のオーダーを続けて実行すれば段取り替えを減らせると分かるかもしれません。また、どの順序にしても、3件目のオーダーは週末までに完了しないことも分かるかもしれません。プランナーはその事実を木曜日ではなく月曜日に知ることができます。ここに挙げた詳細は、実在の工場から取ったものではありません。スケジュールによって、いち早く何が分かるかを示すための例です。
計画が絶えず変わってしまうのを、どのように防げばよいですか。
1時間ごとに作り直されるスケジュールは、まったく変わらないスケジュールと同じくらい役に立ちません。計画のどの部分を固定するかを、あらかじめ決めておいてください。通常は直近の数時間や次のシフトです。どの事象が変更を正当化するかも決めます。例えば、機械の停止、資材の遅延、特急オーダーの到着などです。それ以外のことは、次の計画サイクルまで待ちます。
管理には指標も必要です。計画どおりに開始・完了したオーダーの数を比較してください。ずれは、計画が非現実的だったか、現場が計画から外れていったことを示します。どちらも知っておく価値があり、必要な対処も異なります。
よくある間違い
- ルーティングの作業時間やカレンダーを確認する前に、スケジューラーを購入してしまうこと。
- ERPの計画実行が能力制約をすでに考慮していると、検証せずに思い込むこと。
- ボトルネック1つではなく、工場全体から始めてしまうこと。
- 小さな乱れのたびにスケジュールを作り直し、現場の誰もそれを信頼しなくなること。
- 計画はプランナーに渡しても、現場で実際に何が起きたかを確認する手段を用意しないこと。
- ルールや優先順位を1人のプランナーの頭の中だけに置いておき、ツールに反映できない状態にすること。
Polarisの位置づけ
ERPの計画と実行可能なスケジュールの間にギャップがある場合、iFAKT Polarisは検討に値する選択肢の1つです。iFAKTは、Polarisを、ERPデータと連携する生産向けのAIとデジタルツインであると説明しています。Polaris Optimizerモジュールは、製品・工程・リソースのモデルを、リソース、シフト、ゾーン、スキル、能力などの制約のもとで実行可能な計画に変換し、混乱が発生した場合は再最適化します。Polaris Operatorモジュールは、計画を時間ベースのタスクとして現場に届け、進捗、遅延、混乱をフィードバックとして収集します。どのツールも同じですが、まずは自社のデータを使い、1つのボトルネックで検証してください。
関連して確認しておきたいトピック
- 有限能力スケジューリングに対する能力計画:週次の負荷表示で十分な場合と、日次で実行可能なスケジュールが必要な場合の違いです。詳しくは有限能力スケジューリングをご覧ください。
- スケジュール遵守率の測定方法:オーダーごとに、計画と実績の開始日時および完了日時を比較します。
- APS と MES のデータ共有の仕組み: 計画は下流へ流れ、ステータスは上流へ戻ります。詳しくは 製造実行システムをご覧ください。
- 計画のためのマスターデータ品質: 工程表と作業時間の責任者は誰か、そしてどのくらいの頻度で点検されているか。
次のステップ
生産計画・管理ソフトウェアを選ぶ前に、生産量を左右する設備(リソース)を1つ特定し、その日程を難しくしている制約条件を3つ書き出してください。そのリストと1か月分の受注データを持って、ベンダーとの次回の打ち合わせや ERP チームとの会話に臨んでください。