生産スケジューラー 比較で候補を絞るとき、機能一覧の丸印やデモの見栄えだけでは、タイ工場で本当に回る製品は選べません。必要なのは、自社の受注・設備・人員・材料・段取りを同じ条件で各候補に解かせ、計画変更後の復旧まで確かめることです。本記事では、発注直前のRFP、シナリオデモ、PoC、FAT/SAT、連携、運用体制、TCOを一つの選定手順にまとめます。
生産スケジューラー比較2026:先に結論
タイ工場の生産スケジューラー選定では、製品名から入るのではなく、次の順序で比較するのが実務的です。
- 現在の計画業務と困り事を、受注から現場指示までの流れで可視化する
- 「有限能力」「段取り」「代替資源」「材料制約」「凍結期間」を自社データで定義する
- 全候補に同じRFPとシナリオデモ課題を渡す
- 上位候補だけをPoCへ進め、正常系だけでなく例外復旧を検証する
- FATで設定と連携を、SATで現場運用と実績反映を確認する
- ライセンスだけでなく、マスタ維持、連携保守、教育、バージョン更新を含むTCOで判断する
比較の目的は「最も多機能な製品」を選ぶことではありません。自社の制約を、許容できる保守負荷で表現でき、計画担当者と現場が毎日使い続けられる仕組みを選ぶことです。製品の標準機能が豊富でも、自社の段取りルールを大量の個別ロジックで埋め込まなければならないなら、稼働後の変更費用が膨らみます。反対に、機能が絞られていても、対象工程の意思決定を安定して支えられるなら、有力候補になり得ます。
比較表は「機能の有無」ではなく検証方法まで書く
最初の比較表は、次のように作ります。「対応」と書かせるだけではなく、何を入力し、何が出れば合格かを明示してください。
| 比較軸 | RFPで確認する内容 | シナリオデモ/PoCの合格証跡 |
|---|---|---|
| 有限能力 | 設備、人員、治工具、炉、検査機などを能力制約として扱えるか | 能力超過がなく、負荷グラフと割付結果が一致する |
| 段取り | 品種順序、色、金型、洗浄、立上げなどの切替条件を表現できるか | 順序を変えると段取り時間・使用資源が意図どおり変わる |
| 代替資源 | 主設備と代替設備の速度差、優先度、禁止条件を設定できるか | 故障時に許可された代替だけへ再割付される |
| 材料制約 | 在庫、入荷予定、ロット、代替材料、支給材を考慮できるか | 材料未着の工程が開始されず、入荷変更時に影響が見える |
| 凍結期間 | 確定済み指示を守る範囲と、例外解除の権限を管理できるか | 再計画しても凍結内は保持され、権限者だけが解除できる |
| ERP/MES連携 | 受注、BOM、工程、在庫、実績、停止情報の責任システムはどれか | 連携失敗の検知、再送、重複防止、監査ログを示せる |
| 例外復旧 | 特急、欠勤、故障、不良、材料遅延の再計画手順 | 元計画との差分、納期影響、変更理由を担当者が説明できる |
| 運用体制 | 日次運用、マスタ承認、障害一次対応、変更管理の役割 | タイ現地時間での連絡先、応答条件、教育計画が明文化される |
| TCO | 初期、継続、追加拠点、更新、内製工数を含むか | 3年または5年の前提付き見積が同じ費目区分で比較できる |
この表の右列が空欄のままなら、比較はまだ営業資料の読み比べに留まっています。
生産スケジューラーとAPS・生産計画システムの違い
「生産スケジューラー」「APS 生産計画」「生産計画 システム」は、製品資料や企業内で意味が重なることがあります。名称だけで比較対象を決めず、意思決定の粒度で整理してください。
生産計画システムが扱う時間軸
月次・週次の需要と供給を合わせ、品目や製品群単位で、いつ何をどれだけ作るかを決める領域が上位の生産計画です。一方、生産スケジューラーは、個々の製造オーダーや工程を設備・人員・時間へ割り付け、現場へ実行可能な順序を渡す役割を担います。APSはAdvanced Planning and Schedulingの略称として、上位計画と詳細スケジューリングの一部または両方を指すことがあります。
したがって、RFPでは「APSに対応していますか」と聞くより、次の三つを分けて聞くほうが正確です。
- 需要・在庫・供給をどの期間、どの粒度で計画するか
- 製造オーダーと工程を、どの資源・時間単位へ割り付けるか
- 実績や例外を受け、誰がどの頻度で計画を修正・発行するか
有限能力計画は「設備カレンダーを持つ」だけではない
有限能力計画とは、使える能力を超えない範囲で工程を割り付ける考え方です。しかし、工場の能力は設備台数だけでは決まりません。オペレーターの資格、金型、治具、共有炉、検査機、保全停止、残業枠、休日カレンダーが同時に効く場合があります。
製品比較では、各候補が「有限能力」と説明していても、どの資源を同時制約として扱えるか、能力の単位は時間・数量・バッチのどれか、制約違反を禁止するのか警告として許容するのかを確認します。自社要件を定義せずに「有限能力あり」というチェックだけ付けても、比較にはなりません。
2026年の製品情報は鮮度マーカーとして扱う
公式情報では、Asprovaは海外向けVer.18.1を2026年6月4日公開と案内しています。SAP Helpの対象ページはSAP S/4HANA Manufacturing for planning and schedulingのPP/DS 2025 FPS01(2026年2月)に紐づき、Oracleの26A文書はProduction Scheduling Plans REST resourceによるrefresh、solve、repair、releaseや有限能力計画の流れを説明しています。SiemensもOpcenter APSのAdvanced Schedulingについて、制約、段取り、材料、スケジュール公開などを製品機能として説明しています。
これらは候補製品の保守が続いているか、現行版の文書があるかを見るための鮮度マーカーです。公開日が新しいから自社に最適とは限りません。また、ベンダーが説明する機能は、その製品・構成・契約条件での公称内容です。導入効果、計算速度、精度を別工場へ一般化せず、自社データで検証してください。

タイ工場で比較条件が変わる7つの理由
タイの製造拠点では、日本本社で採用済みの製品をそのまま横展開すれば済むとは限りません。製品の良し悪しではなく、拠点固有のデータ、権限、支援体制が適合性を左右します。
1. 日本語のルールをタイ語の現場運用へ落とす必要がある
計画担当者が日本人、現場監督者がタイ人、保守ベンダーが英語で対応する構成では、用語の不一致が設定ミスにつながります。「確定」「凍結」「仮置き」「割込み」「実績確定」など、状態名と操作権限を日・タイ・英で対応づける必要があります。画面の多言語対応だけでなく、教育資料、エラーメッセージ、問い合わせ窓口の言語を確認してください。
2. 実際の能力がマスタではなく人の記憶にある
「この金型は2号機でも使えるが、薄肉品だけは不可」「雨季は乾燥時間を延ばす」「新任者の班では標準速度を落とす」といった条件が、Excelや担当者の記憶に残っていることがあります。これを整理せず高度な最適化を入れると、数学的には整っていても現場では実行できない計画になります。
射出成形のように金型、材料、乾燥、色替え、成形機能力が重なる工場では、射出成形向け生産管理システムの選び方も参考に、工程・資源・実績の単位を先に揃えてください。
3. ERPの計画値と現場実績の時刻が合わない
ERP上は完了でも、現場では一部数量だけ完成、検査待ち、ラベル待ちということがあります。逆に、夜勤の完了実績が翌朝まで反映されなければ、スケジューラーは古い仕掛状況で再計画します。連携方式より先に「何をもって開始・完了とするか」「どの時刻帯に誰が確定するか」を合意します。
4. 材料の入荷予定が確約ではない
輸入材、顧客支給材、通関、港湾・陸送の変動が計画へ影響する工場では、発注残の日付をそのまま使用可能日とみなすと危険です。入荷予定、到着、受入、検査合格、払い出し可能を別状態として扱えるか、PoCで確認します。材料遅延時には、別オーダーへの切替だけでなく、代替材料の承認状態も守らなければなりません。
5. 交替勤務とスキル制約が設備能力を変える
設備が空いていても、有資格者がいなければ稼働できない工程があります。勤務表を資源カレンダーとして毎日連携するのか、標準班編成として持つのか、欠勤だけ手入力するのかを決めます。人員制約を細かくしすぎるとマスタ保守が続かないため、「計画判断を変える制約」に絞ることが重要です。
6. 本社標準と現地最適の責任分界が曖昧になりやすい
本社がライセンスを契約し、タイ法人が導入ベンダーへ発注し、現地ITが日常保守を担う場合、障害の責任分界が複雑になります。RFPに、製品不具合、設定、インターフェース、ネットワーク、マスタ品質、操作ミスの切り分け手順を含めます。タイ工場での導入会社選びは、工場システム導入ベンダーの選定基準も併せて確認してください。
7. 投資環境の統計と自社効果を混同しない
タイBOIは民間投資指標を公開しており、設備投資環境を把握する一次情報になります。ただし、国全体の申請額や投資件数は、自社の納期遵守率や在庫削減効果を直接証明しません。本記事では、2026年6月の暫定値を含む可能性があるBOI指標を参照先として示すに留め、記事の導入効果へ転用しません。投資判断は自社の基準値とPoC結果で行います。
生産スケジューラー比較のRFPを作る
RFPは「欲しい機能一覧」ではなく、ベンダーが同じ前提で提案するための問題設定です。長大な仕様書より、工場の意思決定とデータ条件が分かる文書を優先します。
RFPに入れるべき10項目
| 項目 | 記載内容 | 避けたい書き方 |
|---|---|---|
| 対象範囲 | 工場、製品群、工程、設備、計画期間、計画粒度 | 「全工程を最適化」だけ |
| 現状業務 | 入力、計画作成、承認、発行、変更、実績反映の流れ | 現行システム名だけ |
| 業務課題 | 納期回答、残業、段取り、仕掛、欠品、再計画の困り事 | 「効率化したい」だけ |
| 制約 | 設備、人、治具、材料、段取り、代替、バッチ、凍結 | 機能名のチェックリストだけ |
| データ | オーダー、BOM、工程、在庫、実績の件数・更新頻度・品質 | 「ERPと連携」だけ |
| KPI | 納期遅延、段取り、計画作成時間などの定義と基準期間 | 改善率を先に固定する |
| 例外 | 特急、故障、欠勤、不良、材料遅延、手直し | 正常系だけ |
| 連携 | 責任システム、方向、頻度、再送、監査、時刻基準 | API必須など手段だけを指定 |
| 運用 | 役割、権限、言語、締切、休日、支援時間 | 「ユーザー教育を実施」だけ |
| 契約 | 成果物、検収、SLA、ライセンス、データ返却、撤退条件 | 初期見積だけ |
要件には優先度と理由を付ける
Must/Should/Couldのような優先度を付ける場合、Mustを増やしすぎないでください。Mustは「満たさなければ対象業務が成立しない条件」です。たとえば、代替機へ割り付けられない製品がある工場なら、設備・品目の禁止組合せはMustになり得ます。一方、ガントチャートの色を部署別に自由設定できることはShouldまたはCouldかもしれません。
各要件に業務理由、責任者、検証方法を付けると、後から仕様が膨張しにくくなります。
| 要件ID | 要件 | 優先度 | 業務理由 | 検証方法 |
|---|---|---|---|---|
| SCH-01 | 凍結期間内の確定作業を自動再計画で動かさない | Must | 当日指示の頻繁な変更を防ぐ | 再計画前後の作業ID・開始時刻を比較 |
| SCH-02 | 同一色の連続生産を優先する | Should | 洗浄と材料ロスを抑える | 順序別の段取り回数を比較 |
| SCH-03 | ダッシュボード配色を部署別に保存する | Could | 視認性を高める | ユーザー設定を確認 |
シナリオデモで営業デモを実務テストに変える
シナリオデモでは、自社の代表データを匿名化して全候補へ渡します。ベンダー側が用意したきれいなサンプルは操作理解には役立ちますが、自社適合性の証明にはなりません。
共通シナリオに含める5つの変化
- 通常受注を投入し、有限能力で初期計画を作る
- 納期優先の特急オーダーを途中投入する
- ボトルネック設備を一定期間停止する
- 主材料の入荷を遅らせる
- 確定済みの直近作業を凍結したまま再計画する
候補ごとに結果画面が違っても、同じ採点票で評価します。採点対象は、計画結果だけではありません。入力データの準備時間、設定変更の手順、計算時間の測定条件、差分説明、操作権限、エラー処理も記録します。
「最適」の意味をKPIで分解する
納期遅延を減らす、段取りを減らす、在庫を減らす、残業を減らすという目標は、同時に最大化できないことがあります。納期を最優先すれば段取りが増え、段取りをまとめれば一部のオーダーが遅れるかもしれません。各候補に「最適化できますか」と聞くのではなく、評価関数、優先順位、重みの変更権限、制約違反の扱いを説明してもらいます。
デモ結果には、少なくとも次の値を残します。
- 納期遅延オーダー数と総遅延時間
- 段取り回数と総段取り時間
- ボトルネック資源の負荷率
- 凍結期間内で変更された作業数
- 未割付作業数と理由
- 元計画から変更された作業数
- 計画作成に要した実測時間と測定環境
ここでの数値は候補間の同条件比較に使います。別工場やベンダー事例の改善率を合格基準にはしません。

PoCで検証する有限能力・段取り・材料・例外復旧
シナリオデモを通過した候補に対し、PoCでは実データの一部を使って運用可能性を確認します。PoCを小さな本番導入にしないことが重要です。期間、対象、合否、成果物、終了条件を先に決めます。
PoCの対象範囲を絞る
代表性のある一つの製品群またはボトルネック工程を選びます。単純すぎる工程では難所を検証できず、全工場を対象にするとデータ整備だけで終わります。次の条件を含む範囲が適しています。
- 複数設備の選択肢がある
- 品種順序で段取り時間が変わる
- 材料または治工具が制約になる
- 特急や故障による再計画が日常的に起こる
- 現場実績を取得できる
マスタデータ品質を別の合否項目にする
PoCで良い計画が出ない原因が、エンジンではなくマスタ欠損であることは珍しくありません。だからこそ、製品評価とデータ評価を分けます。
| データ | 品質確認 | PoCでの処置 |
|---|---|---|
| 品目・BOM | 有効日、代替、単位、歩留まり | 欠損率と補正ルールを記録 |
| 工程・標準時間 | ロット依存、設備差、待ち時間 | 実績分布と標準値の差を確認 |
| 資源 | 稼働カレンダー、能力、禁止組合せ | 計画判断に効く資源だけ先行整備 |
| 段取り | 前後品種、色、金型、洗浄 | 段取り行列の根拠と承認者を記録 |
| 在庫・入荷 | 状態、保留、検査、入荷確度 | 使用可能在庫の定義を統一 |
| 実績 | 開始、完了、良品、不良、停止 | 入力時刻と計画反映時刻を確認 |
例外復旧は「再計算できるか」より重要
現場では、計画どおりに進まないことが通常です。良い運用は、毎回ゼロから最適解を作ることではなく、何が変わり、どの注文へ影響し、誰が承認したかを短時間で説明できることです。
PoCでは、設備故障後に修理予定が未確定のケース、代替設備は使えるが速度が遅いケース、材料が一部数量だけ届くケースを試します。自動再計画、部分修復、手動移動のそれぞれについて、凍結作業を守れるか、変更差分を残せるか、元に戻せるかを確認してください。
Oracle 26Aの公式文書がrefresh、solve、repair、releaseを区別していることは、比較観点の参考になります。ただし、同じ用語や操作を全製品へ求める必要はありません。重要なのは、自社の「最新データ取得」「計画生成」「局所修正」「現場発行」に相当する状態と責任者が明確なことです。
ERP・MES連携はISA-95の境界から整理する
生産計画 自動化を目指すと、すべてをリアルタイムAPIでつなぎたくなります。しかし、最初に決めるべきなのは技術方式ではなく、各データの責任システムです。
ISA-95は、企業系と制御系の統合、特にLevel 3の製造オペレーション管理とLevel 4のビジネス計画・ロジスティクスの境界や情報交換を整理する共通言語になります。ISAの案内ではPart 1の2025年版が示されています。規格に製品構成を機械的に合わせるのではなく、ERP、スケジューラー、MES、設備の責任分界を議論する枠組みとして使います。
データごとに責任システムを一つ決める
| データ | 主な候補 | 決めること |
|---|---|---|
| 受注・納期 | ERP | 変更確定の時点、キャンセル、優先度 |
| 品目・BOM | ERP/PLM | 有効日、代替、版管理、単位 |
| 工程・能力 | ERP/スケジューラー | 標準値の責任者、設備別差、更新承認 |
| 在庫・入荷 | ERP/WMS | 使用可能状態、検査保留、時刻 |
| 詳細計画 | スケジューラー | 計画版、凍結、承認、発行 |
| 作業指示・実績 | MES | 開始・完了、数量、不良、停止理由 |
| 設備状態 | MES/IoT | 停止判定、通信断、履歴保持 |
同じマスタをERPとスケジューラーの両方で自由に修正できる状態は避けます。現場都合でスケジューラー側に補正値が必要なら、補正の所有者、有効期限、ERPへ戻すかどうかを決めます。
連携の非機能要件をRFPに含める
連携頻度だけでなく、タイムゾーン、文字コード、単位、採番、重複、順序逆転、再送を定義します。たとえばERPから同じ製造オーダーが二度届いたとき、二重登録せず更新になるか。実績が遅れて届いたとき、すでに再計画した作業へどう反映するか。連携停止中に現場が進んだ場合、復旧後の整合を誰が取るか。これらが運用コストを左右します。
欠品が重要課題なら、単に在庫数量を連携するだけでなく、工場の欠品を防ぐシステム設計で扱う発注残、引当、仕掛、入荷確度の考え方も含めて設計してください。
FAT・SATで「動く」と「使える」を分けて検収する
FAT(Factory Acceptance Test)は、一般に供給側の環境で設定や機能、連携を確認する工程です。SAT(Site Acceptance Test)は、導入先の実環境でネットワーク、端末、実データ、業務運用を確認します。名称や契約上の定義は案件ごとに異なるため、RFPと契約書で明示してください。
FATで確認する項目
- 承認済み要件と設定値の対応表
- シナリオごとの入力、期待結果、実結果、証跡
- ERP/MES模擬連携の正常・異常・再送
- ユーザー権限と操作ログ
- バックアップ、リストア、設定移送
- 未解決事項、回避策、SATへの持越し条件
SATで確認する項目
- タイ工場のネットワーク、端末、認証での動作
- 本番相当件数の計算と画面応答
- 実際のシフト、休日、設備停止、材料状態
- タイ語利用者を含む日次運用
- 実績取込後の差分と再計画
- 障害連絡、一次切り分け、復旧手順
- 計画発行から現場受領までの承認
検収条件を「システムが起動すること」にしないでください。Must要件ごとに証跡と未解決重大度を定め、重大障害が残る場合の再試験、期限、支払い条件を契約へ落とします。

運用体制を製品比較の採点対象にする
生産スケジューラーは、導入時より稼働後の変更が多いシステムです。新製品、設備増設、金型移管、シフト変更、材料代替が起きるたびにマスタとルールが変わります。運用体制を比較から外すと、最初は動いても半年後に計画担当者だけが扱えるブラックボックスになります。
RACIで日常業務を割り当てる
最低限、計画実行、計画承認、マスタ登録、ルール変更、障害一次対応、ベンダー連絡、バージョン更新をRACIで割り当てます。Rは実行責任、Aは最終責任、Cは相談先、Iは報告先です。日本本社、タイ工場、生産管理、現場、IT、導入ベンダー、製品ベンダーのどこが担うかを決めます。
特に重要なのは、計画結果を人が変更したときの扱いです。手修正を禁止すると緊急時に回らず、自由にするとルールが学習されません。変更理由を選択・記録し、一定期間ごとに頻出理由をマスタや制約へ戻す改善サイクルを設けます。
タイ現地サポートは所在地より実働条件で見る
「タイ対応あり」だけでは不十分です。問い合わせ言語、受付時間、タイの祝日、一次応答、リモート接続条件、オンサイト可否、担当交代時の引継ぎ、製品ベンダーへのエスカレーションを確認します。製品のバージョンアップ時に、連携や個別設定の回帰テストを誰が行うかも見積へ含めます。
生産スケジューラーのTCOを同じ式で比較する
初期ライセンス価格だけを比べると、個別設定や運用工数の差が見えません。各社見積を同じ費目に組み替えます。
TCO = 初期ライセンス・基盤 + 導入・設定 + データ整備 + 連携開発 + 教育・移行 + 評価期間中の継続費 + 社内運用工数 + 変更・更新費 - 契約上確定した値引き
クラウドとオンプレミスでは費用発生の時点が異なるため、比較期間、通貨、税、為替前提、拠点数、利用者数を揃えます。将来拠点の追加単価、データ量や計算資源による従量課金、開発環境・検証環境、バックアップも確認してください。
TCOのモデル試算(説明用の仮定)
以下は価格相場ではなく、比較表の作り方を示す架空の試算例です。実際の費用や効果を示すものではありません。
前提:比較期間3年、1工場、通貨THB、税・為替影響は含めない。候補Aは初期4,200,000 THB、年額900,000 THB、社内運用が月40時間。候補Bは初期2,800,000 THB、年額1,350,000 THB、社内運用が月70時間。社内工数単価は600 THB/時間と仮定し、追加変更費はAが3年間で600,000 THB、Bが900,000 THBと仮定します。
| 費目 | 候補A(例) | 候補B(例) |
|---|---|---|
| 初期費用 | 4,200,000 THB | 2,800,000 THB |
| 継続費(年額×3年) | 2,700,000 THB | 4,050,000 THB |
| 社内運用工数 | 864,000 THB | 1,512,000 THB |
| 変更費 | 600,000 THB | 900,000 THB |
| 3年TCO | 8,364,000 THB | 9,262,000 THB |
計算式は、候補Aの社内運用工数が40時間/月 × 36カ月 × 600 THB/時間 = 864,000 THB、候補Bが70時間/月 × 36カ月 × 600 THB/時間 = 1,512,000 THBです。初期費用だけならBが低い一方、この仮定では3年TCOはAが898,000 THB低くなります。結論を左右するのは年額費用と社内工数の仮定なので、感度分析として工数単価や月間工数を変えて再計算します。
効果は自社の基準値と式で示す
効果額もベンダー事例の改善率を転用せず、次のように自社基準値から組み立てます。
- 計画作成工数削減額 = 削減時間/月 × 社内工数単価 × 12カ月
- 残業削減額 = 削減対象時間 × 対象人数 × 会社負担込み時間単価
- 段取り削減額 = 削減時間 × 停止時間の限界費用。ただし削減時間が実際の増産や残業削減につながる条件を明記
- 納期遅延回避額 = 自社で記録した特急輸送、違約、選別、調整工数などの回避可能費用
- 在庫資金効果 = 平均在庫削減額 × 自社が採用する資金コスト率
「納期遵守率が何%上がる」「在庫が何%減る」といった普遍値はありません。PoC期間が短く金額換算できない場合は、まず計画作成時間、手修正回数、未割付理由の説明可能率などの先行指標で判断します。
失敗しない選定から稼働までの進め方
生産計画 自動化は、ソフトウェアを導入した瞬間に完成するものではありません。データと意思決定の更新を、段階的に仕組みに移します。
フェーズ1:業務診断と基準値取得
現行の計画表、入力データ、計画作成時間、手修正、遅延理由を記録します。担当者への聞き取りだけでなく、実際に一回の計画作成を観察し、どのExcel、メール、口頭情報が判断に使われるかを確認します。この段階で、システム化してはいけない例外と、標準化すべきルールを分けます。
フェーズ2:RFP・シナリオデモ・ショートリスト
同じデータ、同じ変化、同じ採点票で候補を比較します。製品機能、導入チーム、連携、運用、TCOを別々に採点し、総合点の内訳を残します。価格点だけで順位が逆転しないよう、Must要件の不合格は別管理にします。
フェーズ3:PoCとデータ改善
PoCは合否判定と同時に、マスタ整備の工数を測る機会です。誰が何件をどの根拠で修正したかを記録すると、本番展開に必要な工数を見積もれます。PoCで作った一時的な補正データを、そのまま本番マスタへ流用しないよう承認手続きを設けます。
フェーズ4:FAT・SAT・並行運用
FATで設定と連携を固め、SATで現場に通ることを確認します。並行運用では旧計画と新計画を二重に作る期間を必要最小限にし、差分の理由を毎日レビューします。新システムの結果を使わず旧運用へ戻り続ける状態を防ぐため、切替条件と戻し条件を事前に定義します。
フェーズ5:安定化と継続改善
稼働後は、手修正理由、計画未達理由、マスタエラー、連携エラー、問い合わせを定例で確認します。KPIが改善しない場合、エンジンだけでなく、基準値、計画発行時刻、実績入力遅延、現場の評価制度まで見直します。スケジューラーは計画を作りますが、計画を守れる業務条件までは単独で作れません。
生産スケジューラー比較の最終チェックリスト
発注前に、次の質問へ証跡付きで答えられるか確認してください。
- 対象工程、計画粒度、計画期間、発行頻度は明確か
- 有限能力に含める設備、人員、治工具、材料を定義したか
- 段取り時間の根拠と更新責任者が決まっているか
- 代替資源の速度差、優先、禁止条件を検証したか
- 材料の「使用可能」状態をERP・倉庫・品質で合意したか
- 凍結期間と例外解除権限が決まっているか
- 全候補へ同じシナリオデモ課題を渡したか
- PoCに故障、欠勤、特急、材料遅延、不良を含めたか
- 計画差分と手修正理由を追跡できるか
- ERP/MESとのデータ責任分界を決めたか
- 連携失敗の検知、再送、重複防止、監査方法があるか
- FATとSATの合否、証跡、再試験条件を契約に含めたか
- タイ語を含む教育と現地時間帯の支援条件があるか
- 3年または5年TCOに社内運用工数と更新費を含めたか
- データ返却、設定資料、契約終了時の移行条件があるか
一つでも「ベンダーに任せる」のままなら、発注前に責任者と判断期限を置いてください。未決事項を見える化して発注することと、未決事項に気づかず発注することは大きく異なります。
まとめ:比較の勝者は製品名ではなく自社シナリオで決める
生産スケジューラーの比較では、カタログ機能の数より、自社の有限能力、段取り、代替資源、材料制約、凍結期間を同じ条件で解かせることが重要です。RFPで問題を揃え、シナリオデモで候補を絞り、PoCでマスタ品質と例外復旧を確認し、FAT/SATで設定と現場運用を分けて検収します。最後はERP/MES連携、タイ現地の運用体制、社内工数を含むTCOで判断してください。特定製品の一般的な勝者はありません。自社の制約と運用能力に合う候補を、証跡で選ぶことが成功への近道です。
TOMAS TECHでは、製品が未決定の段階でも、タイ工場の現行業務整理、RFP作成、共通デモシナリオ、PoC・FAT/SATの評価設計をご相談いただけます。発注前に比較条件を揃えたい場合は、お問い合わせページから現在の工程と検討状況をお知らせください。
FAQ:生産スケジューラー比較でよくある質問
生産スケジューラーとは何ですか?
製造オーダーや各工程を、設備、人員、治工具、材料、時間などの制約を考慮して割り付け、実行順序を作るシステムです。製品によって対象範囲は異なり、上位の需給計画まで含む場合もあります。名称ではなく、対象期間、粒度、入力、出力、再計画の流れを確認してください。
APS 生産計画はERPのMRPと何が違いますか?
一般にMRPは需要、在庫、BOM、リードタイムなどから必要量と時期を計算し、APSや詳細スケジューラーは能力や順序制約を含めて時間軸へ割り付けます。ただし製品構成で役割は変わります。自社ではERP、APS、MESのどれを責任システムにするかをデータごとに決める必要があります。
生産計画システムの費用はどのように比較すべきですか?
初期ライセンスだけでなく、導入・設定、データ整備、ERP/MES連携、教育、移行、年額保守・利用料、社内運用工数、追加変更、バージョン更新、追加拠点を同じ期間と通貨で比較します。一般的な価格や回収年数を自社へ当てはめず、候補各社の正式見積と自社工数でTCOを計算してください。
生産計画 自動化のPoCでは何を確認すべきですか?
正常な初期計画だけでなく、特急受注、設備故障、欠勤、材料遅延、不良・手直し、凍結期間を含む再計画を確認します。結果の良さに加え、元計画との差分、未割付理由、手修正履歴、計算条件、データ補正工数を証跡として残します。
タイ工場では日本本社と同じ生産スケジューラーを選ぶべきですか?
本社標準には契約、教育、連携資産を共通化できる利点があります。一方、タイ工場の設備、材料、勤務、言語、データ品質、現地支援が異なれば適合しない場合があります。本社製品を優先候補にしつつ、タイ工場の共通シナリオとSAT条件で適合性を再検証するのが安全です。
参考情報
- Asprova Corporation, About / News(Ver.18.1の公開日を確認、2026年8月25日閲覧)
https://www.asprova.com/en/about/
- Asprova Corporation, Production Scheduling System Overview(機能・外部データ入出力等のベンダー説明、2026年8月25日閲覧)
https://www.asprova.com/en/overview/index.html
- SAP Help Portal, Production Planning and Detailed Scheduling (PP/DS), 2025 FPS01(有限計画・ヒューリスティクス等の製品文書、2026年8月25日閲覧)
- Oracle, Manage a Production Schedule, Oracle Fusion Cloud SCM 26A(refresh、solve、repair、release、有限能力計画、2026年8月25日閲覧)
- Siemens, Opcenter Advanced Planning and Scheduling — Advanced Scheduling Software(制約、段取り、資材、スケジュール公開等のベンダー説明、2026年8月25日閲覧)
- International Society of Automation, ISA-95 Standard: Enterprise-Control System Integration(Level 3/4と情報交換境界、Part 1の2025年版案内、2026年8月25日閲覧)
https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
- Thailand Board of Investment, Private Investment Indicators(タイの投資環境参照、暫定値の扱いに注意、2026年8月25日閲覧)
https://www.boi.go.th/index.php?language=th&page=private_investment_indicators