モジュール型生産計画ソフトウェア: 最初に追加すべきモジュールはどれか

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 · 2026-11-12

モジュール型生産計画ソフトウェアを使うと、成長する工場は計画の層を段階的に追加できます。既存のモジュール、それらが共有するもの、最初に追加すべきものを確認しましょう。

Automatically translated with AI from the original post. Read the English original

モジュール型生産計画ソフトウェアは、マスタースケジューリング、資材計画、有限能力スケジューリング、現場フィードバック、レポートなどの計画を独立したモジュールに分けます。そのため、最も大きな課題を解決するモジュールから始め、工場の成長に合わせて残りを追加できます。ただし、モジュールが効果を発揮するのは、同じデータを共有し、同じ計画で合意している場合に限られます。本記事は、製造工場で生産計画を担当し、最初のモジュールを選ぶ必要があり、寄せ集めの構成を避けたい方を対象としています。

重要なポイント

• モジュール型生産計画ソフトウェアは、マスタースケジュール、資材計画、有限能力スケジューリング、実行フィードバック、KPIといった層に計画を分割します。
• モジュールが連携して機能するのは、品目、部品表、工程順序、リソース、カレンダーのデータを一元的に共有している場合のみです。
• 最初に、最もコストのかかる症状を解消するモジュールを追加してください。具体的には、部品不足、実行不可能なスケジュール、誰も従わない計画、可視性の欠如などです。
• モジュール型とは、共有データを持つ1つのスイートなのか、インターフェースで連携する独立した製品群なのかを、すべてのベンダーに確認してください。その答えによって連携作業の負担が大きく変わります。
• 残りを購入する前に、1つの製品ファミリーについて、2つのモジュールをまたいでエンドツーエンドで試験導入してください。

生産計画ソフトウェアにおける「モジュール型」とはどういう意味ですか?

ベンダーはこの言葉を2通りの意味で使います。どちらの意味で説明されているのかを確認してください。

1つ目は、同じデータベースを共有するモジュールで構成されたスイートです。製造資源計画(MRP)についてのWikipediaの説明は、この考え方をよく表しています。MRP IIは、基準生産計画、品目マスタと部品表、生産資源データ、資材所要量計画、現場管理、能力計画などのモジュールで構成され、これらが共通データを共有することで自由に情報をやり取りできます。定義上、完全に統合されているか、少なくとも完全にインターフェース接続されています。

2つ目は、それぞれが特定の層に強みを持つ独立した製品を、インターフェースで連携させる構成です。後から一部を置き換えられる柔軟性がありますが、各製品間のデータマッピングとテストは自社で管理する必要があります。

どちらが誤りというわけではありません。違いは作業の発生場所にあります。スイートでは設定作業が中心になり、独立製品では連携作業が中心になります。価格を比較する前に、自社が何を購入しようとしているのかを把握してください。

どの計画層がモジュールになり得ますか?

計画担当者の業務は、いくつかの層を経て進みます。それぞれがモジュールになり得ます。製品によって名称は異なりますが、その考え方は変わりません。

• マスタースケジュール。 基準生産計画(MPS)は、各期間に生産する製品を定めます。Wikipediaによれば、その入力には需要予測、受注、在庫水準、供給、ロットサイズ、リードタイム、能力が含まれ、資材所要量計画を駆動します。
• 資材計画。 この層では、需要を在庫と未入荷の供給に対して相殺し、発注を提案します。Dynamics 365 では、これをマスタープランニングと呼びます。Microsoft のドキュメントでは、利用可能な資材や能力と必要量を組み合わせ、所要量を計算し、プランナーが変更できる計画オーダーを生成するものと説明されています。日々の補充を担う正味所要量計画と、長期的な需要に向けた需要予測ベースの計画とは分けて扱われます。
• 有限能力スケジューリング。 この層では、実際の制約を考慮して、オーダーを時間軸上で資源に割り当てます。高度な計画とスケジューリングは、Wikipedia では、資材と能力を一体で計画し、制約を考慮する手法として説明されています。一方、従来の MRP 型のシステムでは両者を別々に計画するため、実行できない計画が生じることがあります。
• 実行とフィードバック。 この層では、監督者に作業を割り当て、実際に何が起きたかを報告します。
• KPI とレビュー。 リードタイム、稼働率、納期遵守率を計画と比較します。

2 層目と 3 層目の間のギャップに注目してください。多くの遅延オーダーはここが原因です。Microsoft のドキュメントによると、計画製造オーダーは品目マスターの固定リードタイムを使用しますが、ルートベースの計画と資源制約を考慮したスケジューリングは、オーダーを確定する時点で行われます。そのため、計画時点と確定オーダーとの間でリードタイムが変わることがあります。これは欠陥ではありません。計画の各層が異なる情報を使っている場合に起きることであり、有限能力スケジューリングモジュールを検討する価値がある理由でもあります。

最初にどのモジュールを追加すべきでしょうか。

機能の一覧ではなく、最もコストのかかっている症状から始めてください。

1. 資材が不足する、または在庫が過剰になる。 資材計画から始め、在庫データとリードタイムデータを整備します。
2. 資材はあるのに、オーダーの出荷が遅れる。 計画が能力を考慮していません。有限能力スケジューリングを検討してください。
3. 画面上のスケジュールは問題なさそうに見えても、誰もそれに従わない。 実行のフィードバックが必要です。遅延を同日中にプランナーが把握できるようにします。
4. 数値をめぐって毎回議論になる。 新しい計画ロジックを導入する前に、合意された定義を持つ KPI の層を追加してください。
5. ある変更が効果を生むかどうか判断できない。 MRP II の解説にもあるシミュレーションのような What-if 機能は、後から追加しても構いません。

最初の対象範囲としては、単一の部門よりも単一の製品ファミリーの方が適しています。1 つのモジュールが実際の納期遵守率にどう影響するかを確認できるからです。

モジュール間で共有すべきものは何でしょうか。

アーキテクチャがどのようなものであれ、モジュール間で次の少数のマスターデータについて合意しておく必要があります。

• 品目マスターと部品表
• 工程ルートと作業時間
• 資源、作業センターとそのカレンダー
• シフトモデルと利用可能なスキル
• オーダーステータスとその意味

いずれかのデータを複数のモジュールがそれぞれ独自に保持している場合、数か月のうちに食い違いが生じます。各オブジェクトについてどのモジュールをマスターとするか、そして現場の実態と食い違ったときに誰が修正するかを決めてください。

デモで確認してください。あるモジュールで工程ルートの作業時間を変更するよう、ベンダーに依頼し、その変更が他のモジュールのどこに反映されるか、そしてどれくらいの時間がかかるかを示してもらいます。回答が「エクスポート後に反映されます」であれば、実際の統合作業の規模がわかったことになります。

例：1 つの工程ルート、2 つの答え

これは架空の例であり、測定結果ではありません。ある工場が、既存の資材計画に加えて有限能力スケジューリングモジュールを追加したとします。ブラケットの ERP 工程ルートでは、フライス加工に 15 分かかると定義されています。一方、スケジューリングモジュールは、段取りとバリ取りの後に作業者が実際に目にしている値である 22 分と記載されたスプレッドシートをもとに設定されていました。

資材計画では、ブラケットは木曜日に出荷できるとされています。スケジュールでは月曜日です。両モジュールはそれぞれのデータに基づいて正しく動作していますが、プランナーは毎週 1 時間をかけてその理由を説明しています。解決策はより良いアルゴリズムではありません。1 つの合意された時間を、1 人の担当者が管理し、両方のモジュールが読み込む 1 か所に保存することです。

すべてを作り直さずに、どのように成長させればよいでしょうか。

成長とは通常、製品の増加、シフトの増加、2 つ目のラインの追加、または別拠点の追加を意味します。その際は、次の 4 つの方法で備えてください。

• 計画の期間を明確に分けてください。 Microsoftによると、マスタースケジューリングは通常1週間から6か月を対象とし、多くの企業では関係する製品の累積リードタイムのうち最も長いものまで広がります。どのモジュールがどの期間を担当するかを把握しておき、短期のスケジュールを長期計画と取り違えないようにしてください。
• 2つ目の拠点の計画は、まず紙の上で考えてください。 Microsoftのドキュメントでは、企業間計画は法人をまたいで需要と供給を結び付ける別のプロセスとして挙げられています。2つ目の工場を予定しているなら、候補のソリューションがそれをどう扱うかを確認してください。
• カスタムコードより設定を優先してください。 カスタムのルールは、アップグレードのたびに再テストが必要になります。
• データ量が増えたときの実行時の挙動を確認してください。 Microsoftによると、Planning Optimizationで作成された計画は再生成型であり、変更された要件だけでなくすべての要件を更新します。現在の2倍のデータ量で、計画の全体実行にどれくらいかかるかをどのベンダーにも尋ねてください。

ベンダーはどのように選定し、どのように検証すればよいでしょうか。

どのモジュールにも使える質問は次のとおりです。

1. このモジュールはどのデータを、どのシステムから読み取り、どのシステムへ書き込みますか。
2. 割り込みの受注、設備の故障、作業者の欠員が発生したとき、計画はどうなりますか。専門家がいなくても、計画担当者が再計画できますか。
3. 計画担当者は、モジュールがなぜその場所に注文を配置したのかを確認できますか。中身の見えない計画は、現場の会議で説明するのが難しくなります。
4. アップグレードはどのように扱われ、その後インターフェースは誰がテストしますか。
5. 次のモジュールを接続するには、ライセンス費用だけでなく、どれくらいのコストがかかりますか。
6. 計画データとマスターデータを、実用的な形式でエクスポートできますか。

次にパイロットを実施してください。1つの製品ファミリーと2週間分の実際の受注を選びます。候補のモジュールで計画を立て、現在の方法でも計画を立て、その結果を実際に起きたことと比較します。作業工数も記録してください。手作業による修正が何回あったか、準備に何時間かかったかです。

よくある間違い

• すべてのモジュールを一度に購入すること。 どのモジュールが効果をもたらしたのかを判断できず、データ作業も一度に大きな塊として発生します。
• 症状に合わないモジュールから始めること。 不正確な部品表に対して有限能力スケジューラーを使うと、正確だが誤った結果が出てしまいます。
• マスターデータの二重管理。 モジュール同士の内容がずれていき、どちらのデータも信頼されなくなります。
• 人の側面を無視すること。 計画担当者は、計画がなぜそのような形になっているのかを把握できなければ、結局その計画を上書きしてしまいます。
• インターフェースの責任者が不在であること。 アップグレードでインターフェースが壊れても、誰も責任を負いません。
• 現在の量だけを前提に計画すること。 契約する前に、次の製品ファミリーや次のシフトモデルについて確認してください。

Polarisが適する場面

モジュールを組み合わせて構成する計画基盤をお探しなら、iFAKT Polarisも検討に値します。iFAKTは、Polarisを、ERPデータと製造のデジタルツインを組み合わせ、7つのモジュールで構成された生産ソフトウェアとして紹介しています。Polaris Designerは、共通の信頼できる情報源として、製品・工程・リソースのナレッジグラフを構築します。Polaris Optimizerは、リソース、シフト、ゾーン、資格、生産能力などの制約条件のもとで生産計画を生成します。他の候補と同様に、1つの製品ファミリーと御社自身のデータで試してみてください。

関連して調べておきたいトピック

• マスターデータの品質。 工程表と部品表を誰が管理し、誤りをどのように修正するのか。
• 有限能力と無限能力の計画。 資材計画で十分な場合と、そうでない場合。
• 計画期間と固定期間。 各階層がどれだけ先まで計画するのか、そしていつからスケジュールが変更されなくなるのか。
• シナリオ計画。 確定する前に2つの計画をどのように比較するか。
• 複数拠点の計画。 工場間で需要と供給を共有すると、何が変わるのか。

次のステップ

モジュール型の生産計画ソフトウェアは、症状に応じてモジュールを選んだときに効果を発揮します。工場で最も大きな計画上の課題を1つ書き出し、それがどの階層に属するかを特定してください。そのうえで、2つのベンダーに、御社自身の製品ファミリーの1つを使って、そのモジュールの動作を示してもらってください。