生産管理システム 機能｜タイ工場RFP要件2026

生産管理システム 機能を比較するとき、機能名のチェック表だけではタイ工場に合う製品を選べません。「生産計画あり」「在庫管理あり」と回答されても、計画変更、代替材料、分割完了、保留、再作業、通信断を誰がどの証拠で処理するかは分からないからです。本稿では、RFPをMust/Should/Couldで優先し、標準・設定・個別開発を切り分け、マスタ、例外、権限、監査、ERP連携を受入証跡まで落とす方法を解説します。

生産管理システム 機能の結論：機能名ではなく結果と証拠を書く

良いRFPの1行は、「○○機能があること」では終わりません。少なくとも次の8点を結びます。

1. 業務結果：何を正しい状態にするのか。
2. 開始条件：どのイベント、時刻、承認で処理が始まるか。
3. 入力：どのマスタ、計画、実績、設備情報を使うか。
4. ルール：優先順位、数量、版、有効日、締め、例外判定は何か。
5. 例外：欠品、遅延、不良、取消、再作業、通信断をどう扱うか。
6. 権限：誰が実行、承認、訂正、解除できるか。
7. 出力：現場指示、ERP仕訳、在庫、品質、KPIへ何を返すか。
8. 受入証跡：どのテストデータ、ログ、画面、API応答で合格とするか。

例えば「製造実績入力機能があること」ではなく、「承認済み作業指示に対し、作業者が良品・不良・保留数量、開始/終了時刻、設備、ロットを登録できる。合計数量が指示数を超える場合は監督者承認を要求し、訂正前後値、理由、承認者、時刻を監査ログへ残す。ERPへ同じ実績が再送されても二重計上しないこと」と書きます。これならデモ、見積、設計、FAT/SATが同じ要件を参照できます。

先にシステム境界を決める：ERP・生産管理・設備制御を混ぜない

ISA-95は、企業・物流側と製造オペレーション側の活動、用語、情報交換を整理する国際的な枠組みです。公開概要ではLevel 3を製造オペレーション管理、Level 4をERPを含む事業計画・物流と位置付けています。同じ公式ページには、Part 1の現行版としてANSI/ISA-95.00.01-2025（IEC 62264-1 Modified）も掲載されています。ISA-95 overview

RFPで重要なのはピラミッドの絵を描くことではなく、各情報の正本と責任を決めることです。

境界が曖昧だと、ERPと生産管理の両方で品目や在庫を修正し、どちらが正しいか分からなくなります。逆に「ERPが正本」と書くだけでも不十分です。ERP停止中に現場が継続するか、緊急品目を仮登録できるか、復旧後に誰が照合するかまで決めます。

生産管理システムの製品軸を整理したい場合はタイ工場向け生産管理システム比較、標準製品と開発方式の違いは生産管理システムのカスタム開発判断も参照してください。本稿はその前段となるRFP機能要件に集中します。

Must・Should・Couldで「全部必要」を止める

部門ヒアリングをそのまま機能一覧にすると、各部門が自分の要求をMustと呼びます。そこでMoSCoWの考え方を使い、優先度を意思決定ルールとして定義します。

Must：無ければ業務開始または受入ができない

法令・顧客要求・安全・品質、月次締め、必須連携、重大な業務継続、データ移行に関わる要件です。Mustには「無い場合の具体的な不成立」を書きます。代替手順が安全かつ許容時間内なら、本当にMustか再検討します。

Should：初期稼働に高い価値があるが、期限付き代替が可能

代替手順、担当、許容期間、追加工数を明記します。「便利だから」ではなく、KPIや統制への寄与を説明します。Go-live後Phase 2に回す場合は、期日と再判断者を置きます。

Could：価値仮説を検証してから決める

AI予測、高度分析、最適化、細かなUI希望など、データや運用が整って初めて価値が出る候補です。将来構想として残し、初期設計を壊さないAPIやデータ保持だけをMustにする方法があります。

Won’t now：今回やらないこともRFPに書く

設備安全制御、全社原価再構築、全倉庫WMS置換など、今回境界外の項目を明記します。これは永久に不要という意味ではなく、今回の見積、責任、受入から外す宣言です。

Mustが全要求の大半を占めたら、優先付けが機能していません。Mustだけで予算と日程に収まるかを先に確認し、Should/Couldは別見積にします。

RFPの生産管理システム 機能マップ

機能マップは漏れを防ぐ入口ですが、採点表そのものではありません。各行を業務シナリオと受入条件へ展開します。

「生産計画機能」と一括りにせず、計画生成、凍結、承認、リリース、変更、再計画、影響通知を分けます。「トレーサビリティあり」も、前方/後方、検索時間、分割/統合、再作業、外注、データ保存、出力形式まで指定します。

要件を受入可能な1行へ変換するテンプレート

ISO/IEC/IEEE 29148:2018は、システム/ソフトウェアのライフサイクルを通じた要求工学プロセスと情報項目を扱います。2018年版は2024年に確認されましたが、ISOのライフサイクル表示は現在「改訂予定」で、後継DISが開発中です。したがって公開済み2018年版を現時点の参照としつつ、改訂案が確定済みとは扱いません。ISO/IEC/IEEE 29148:2018 RFPでは規格文をコピーするのではなく、要求を追跡できる形にします。

推奨列は次のとおりです。

• Requirement ID
• 業務目的と要求元
• 優先度（Must/Should/Could）
• 前提、トリガー、入力
• 正常ルール、境界値、例外
• 役割、承認、職務分離
• 出力、通知、連携先
• データ保持、監査、セキュリティ
• 受入シナリオ、期待結果、証拠
• ベンダー回答（標準/設定/個別開発/外部）
• 製品版、前提、制約、追加費、納期

悪い例：

多言語に対応すること。

良い例：

FR-UI-014（Must）：作業者画面はタイ語と英語をユーザー単位で切替できる。品目名はERPから受信したタイ語/英語名称を表示し、名称が欠落する場合は品目コードを表示して欠落を日次データ品質レポートへ記録する。切替後も作業指示IDと入力途中状態を保持する。FATでは同じ5指示を2言語で完了し、保存されたコード、数量、時刻が一致することをDB出力と監査ログで確認する。

悪い例：

ERPと連携できること。

良い例：

IF-ERP-021（Must）：承認済み製造実績を一意のevent_id付きでERPへ送信する。タイムアウト時は同じevent_idで再送し、ERP受信済みなら二重計上しない。HTTP 400系業務エラーは隔離キュー、通信エラーは上限付き自動再試行とし、担当者、初回時刻、試行回数、payload hash、最終結果を検索可能にする。SATでは応答欠落と再送を発生させ、ERP伝票が1件であることを両システムの証跡で確認する。

この粒度なら、機能の有無ではなく実装可能性と運用責任を比較できます。

マスタ機能：画面より所有者・版・有効日を決める

生産管理システム 導入で最も長く影響するのはマスタです。品目、BOM、工程順、標準時間、歩留まり、設備能力、シフト、休日、保管場所、検査規格、理由コードが一致しなければ、計画も実績も正しくなりません。

ISO 8000-8:2015は、情報・データ品質の概念と測定を品質管理プロセスへ適用する考え方を示しています。同版は2022年に確認され、現行版です。ISO 8000-8:2015 RFPでは「データクレンジングを行う」とだけ書かず、次を決めます。

マスタ所有権

• 品目基本属性はERP、製造工程は生産技術、検査規格は品質、設備能力は製造/保全など、属性単位でOwnerを置く。
• 作成者と承認者を分ける。緊急変更は期限付きとし、事後承認の条件を限定する。
• 日本本社、タイ法人、各工場のどこが共通コードとローカル属性を持つかを分ける。

版と有効日

• BOM/工程/規格は版、発効時刻、失効、対象工場を持つ。
• 既にリリースした作業指示へ新しい版を遡及するか、旧版で完了するかを定義する。
• 有効期間が重なる変更を自動で拒否または承認待ちにする。

データ品質ルール

• 必須、形式、参照整合、重複、許容範囲、単位、言語名称を検証する。
• unknown、not applicable、未入力を同じ空欄にしない。
• 取込件数、成功、失敗、警告、除外、hashを記録し、再実行しても重複しない。

移行受入では「全件入りました」ではなく、対象件数、変換規則、除外、重複、欠落、サンプル照合、Owner承認を証拠パックにします。

例外機能：正常系より先に業務の止まり方を書く

標準デモは注文を作り、指示し、完了するまでを見せます。しかし現場コストは例外に集まります。RFPワークショップでは、正常フローを1回確認した後、次の例外を実データで通します。

1. 材料が足りない、現物とシステム在庫が違う。
2. 代替材料を使いたいが、顧客または品質承認が必要。
3. 一部数量だけ完了し、残りを次シフトへ引き継ぐ。
4. 不良が出て再作業ルートへ移す。
5. 完了後に数量またはロット誤りが判明する。
6. 工程が止まり、別設備または外注へ振り替える。
7. 作業中に計画版、BOM、工程が変更される。
8. 端末がオフラインになり、復旧後にイベントが再送される。

各例外には、検出者、所有者、期限、許可された処置、承認、エスカレーション、次工程への影響、解除条件を持たせます。理由コードを増やしすぎると「その他」だらけになり、少なすぎると改善できません。コード変更のOwnerと廃止ルールも要件です。

権限・監査機能：できる/できないではなく責任を再現する

権限表は「管理者」「一般ユーザー」の2種類では足りません。計画作成、計画承認、指示解除、実績入力、実績訂正、品質判定、保留解除、マスタ変更、ユーザー管理、ログ閲覧を分けます。

最低限の設計観点は次です。

• 職務分離：高リスク変更を同じ人が作成・承認しない。
• スコープ：工場、部門、ライン、倉庫、品目群ごとに制限する。
• 時間：代理と緊急権限は開始/終了時刻と理由を持つ。
• ライフサイクル：入社、異動、休職、退職、委託終了と連動する。
• 共有ID禁止：端末共用でも作業者を識別し、機械/サービスアカウントを人と分ける。
• 監査耐性：誰が、いつ、何を、どの値からどの値へ、なぜ、誰の承認で変えたかを検索・出力できる。
• ログ保護：一般管理者が監査ログを削除・改変できない。時刻同期と保存期間を決める。

NIST SP 800-82 Rev.3は、OT固有の性能、信頼性、安全要求を踏まえたセキュリティを扱います。NIST公式ページではRev.3をfinalとして掲載し、Rev.4はdraftとして案内しています。本稿は現行finalのRev.3を参照します。NIST SP 800-82 Rev.3 生産管理が設備へ接続する場合、通常ITの認証だけでなく、ネットワーク境界、設備影響、保守窓、パッチ、バックアップ、復旧、縮退運転を要件化します。生産管理PoCを設備安全制御へ直結しない境界も明記します。

ERP 連携 生産管理：項目マッピングより取引の契約を書く

ERP連携の見積が膨らむ原因は、接続方式より「意味」と「失敗時責任」が未定なことです。NISTのDigital Thread研究は、設計・製造・品質をまたぐ情報の再利用、交換、トレーサビリティを扱っています。NIST Digital Thread RFPでは、単純なA列→B列の対応より次を決めます。

連携ごとの契約

インターフェース台帳にはOwner、上流/下流、方式、頻度、量、ピーク、SLA、再送、監視、データ分類、変更通知、テスト環境、終了手順を持たせます。「リアルタイム」は曖昧なので、例えば「受信対象イベントの95%を60秒以内に到達させる」のように、測定区間と分母を定義します。ただし数値は自社工程から決め、テンプレート値をそのまま使いません。

標準・設定・個別開発をどう判断するか

生産管理システム カスタマイズは悪ではありません。問題は、標準で変えるべき業務をコードで固定することと、自社の競争力を作るルールを標準へ無理に合わせることです。各要件を次の4分類で回答させます。

1. 標準（Standard）：製品本体の現行版で追加コードなし。
2. 設定（Configuration）：承認済みの設定、ワークフロー、帳票、ルールで対応。
3. 拡張/個別開発（Extension/Customization）：API、プラグイン、独自コードを保守する。
4. 外部/業務対応（External/Process）：別システムまたは標準作業で対応。

ベンダー回答には製品版、ライセンス、前提、制約、デモ可能性、追加費、納期、将来アップグレード影響を書かせます。「設定可能」は、誰がどの画面で変更し、承認、移送、版戻し、監査ができるかまで確認します。

個別開発を採用する場合は、ソース/成果物の権利、リポジトリ、ビルド、依存ライブラリ、テスト自動化、脆弱性対応、アップグレード回帰、ドキュメント、担当交代、契約終了時の引渡しを契約します。

非機能要件を別紙に追いやらない

機能が正しくても、月末に遅い、障害から戻らない、監査できない、変更のたびに止まるなら受け入れられません。ISO/IEC 25010:2023は、9つの特性で構成されるICT/ソフトウェア製品の品質モデルを定義しています。ISO/IEC 25010:2023 RFPでは規格名だけで済ませず、業務条件で測ります。

• 性能：通常/ピークの同時ユーザー、注文、実績イベント、帳票量と応答分布。
• 可用性：対象時間、計画停止、除外、監視、通知、サービスクレジットの要否。
• 復旧：RTO/RPO、バックアップ頻度、復元手順、復元後照合、年次試験。
• 互換性：ブラウザ、端末、OS、プリンタ、スキャナー、API版、文字コード。
• セキュリティ：SSO/MFA、権限、暗号化、秘密情報、ログ、脆弱性、パッチ。
• 保守性：設定とコードの分離、変更影響、回帰試験、監視性、文書化。
• 利用性：タイ語/英語、日本語管理、手袋、画面距離、エラー回復、教育。
• データ：精度、完全性、一意性、鮮度、系譜、保持、削除、エクスポート。

「24/7」「応答3秒」といった数字は、工程要求と測定方法なしに書かないことが重要です。どの画面、何件、どのネットワーク、何パーセンタイル、どの時間帯で測るかを添えます。

FAT/SATの受入証跡をRFP時点で要求する

受入は最後に作るテストではありません。要件ごとに検証方法と証拠をRFP時点で結びます。

証拠パックには、要件ID、製品/設定版、実行日、環境、テストデータ、手順、期待値、実測、スクリーンショットだけでなく原ログや出力、欠陥、再試験、承認者を含めます。

FATはベンダー環境で標準・設定・連携・異常を確認し、SATはタイ工場の実ネットワーク、端末、プリンタ、ラベル、シフト、作業者、データ量で確認します。FAT合格を本番受入と同一視しません。

ベンダー選定はMustゲートと100点例で分ける

最初にMustをPass/Failで判定し、重大未達を価格点で埋め合わせないようにします。その後、下記の100点を例として比較できます。これは普遍的な配点ではなく、買い手が承認すべき試算用ガバナンスモデルです。

デモはベンダーの得意シナリオではなく、買い手が用意した同一データで行います。回答者とデモ担当の約束が違わないよう、要件IDごとに動画、設定画面、製品版、追加開発の有無を記録します。

5年TCOには初期ライセンス、サブスクリプション、環境、連携、移行、テスト、教育、端末、ネットワーク、保守、アップグレード、変更、現地支援、終了時エクスポートを含めます。費用値はRFP回答で取得し、架空の相場を置きません。

タイ工場の生産管理システム 選び方で追加する条件

タイ拠点では機能適合に加え、運用言語と責任分担を評価します。

• 作業者UIはタイ語、管理者は英語/日本語など、画面とマスタ名称を分けて要件化する。
• タイ語翻訳はラベルだけでなく、エラー、理由コード、教育、ヘルプ、変更時更新を含む。
• 日本本社とタイ工場で計画凍結、マスタ承認、月次締めの時刻と責任を合意する。
• タイの休日、交代勤務、日跨ぎ、ICTタイムゾーンをテストする。
• 現地サポートの受付言語、時間、一次応答、現場訪問、部品交換、エスカレーションを確認する。
• 個人データ、作業者実績、カメラ等の利用は、現地法と社内規程を確認する。

BOIのInvestment Promotion Guide 2026にはSmart and Sustainable Industryへの産業高度化と自動化関連の措置が掲載されています。BOI Guide 2026 ただしシステム導入が自動的に恩典対象になるわけではありません。申請前の発注、対象事業、投資内容、性能指標、期限などをBOIまたは専門家へ確認し、未確定の恩典を投資採算へ入れないでください。

RFPから本番までの判断ゲート

期間は規模により変わりますが、順序は固定できます。

1. Scope Gate：経営KPI、対象工程、境界外、Sponsorを承認。
2. Requirement Gate：MustとOwner、シナリオ、受入証拠を承認。
3. Fit-to-Standard Gate：標準/設定/開発/外部を実デモで確認。
4. Contract Gate：前提、TCO、責任、成果物、出口、変更単価を契約。
5. Design Gate：マスタ、権限、例外、連携、移行、運用を承認。
6. FAT Gate：正常・境界・異常・復旧と証拠を確認。
7. SAT/Go-live Gate：実環境、教育、切替、rollback、支援を確認。
8. Stabilization Gate：欠陥、データ品質、KPI、運用引渡しを確認。

各ゲートには、通過、条件付き通過、保留、中止の選択肢を持たせます。日程が遅れたからMustを無言でShouldへ変えず、変更理由、影響、代替、期限、承認を記録します。

失敗しやすいRFPと修正方法

機能数が多い製品を高得点にする

機能数は適合性ではありません。使わない機能は教育、権限、テスト、更新の負担になります。自社シナリオの完了率と例外証拠で評価します。

現行Excelをそのまま画面化する

Excelは長年の例外と個人判断を含みます。目的、正本、重複、承認、廃止可能な列を整理し、標準業務へ寄せる部分と差別化部分を分けます。

「リアルタイム連携」で一括見積する

イベント、遅延許容、量、再送、照合、エラーOwnerを分けます。リアルタイム不要のマスタまで同期させると複雑性が増えます。

デモ合格を受入合格にする

デモは可能性、FATは設定/連携、SATは実環境、安定化は継続運用を確認します。それぞれ別の証拠と責任があります。

カスタマイズを件数だけで禁止する

件数ではなく、差別化、リスク、Owner、アップグレード、試験、出口で判断します。小さな独自コードでも全注文を止めるなら高リスクです。

生産管理システムRFPチェックリスト

• 経営KPIと対象業務境界が1ページで説明できるか。
• ERP、PLM、WMS、QMS、MES、設備の正本と責任を定義したか。
• Must/Should/Could/Won’t nowに判定根拠と承認者がいるか。
• 正常だけでなく欠品、再作業、取消、訂正、通信断をシナリオ化したか。
• 品目、BOM、工程、設備、カレンダー、規格のOwner、版、有効日を決めたか。
• 作成/承認/訂正/解除/管理を職務分離したか。
• ERP連携に一意ID、版、単位、時刻、再送、照合があるか。
• 標準/設定/個別開発/外部を製品版と証拠付きで回答させるか。
• 性能、可用性、復旧、セキュリティ、保守性、多言語を測定可能にしたか。
• 要件IDとFAT/SAT/移行/教育の証拠が紐づくか。
• 5年TCOに変更、更新、現地支援、終了を含めたか。
• タイ工場と日本本社のOwnerが受入と変更を共同承認するか。

まとめ：生産管理システム 機能は受入証跡まで設計する

生産管理システム 機能の選定は、機能名の数を比べる作業ではありません。業務結果、トリガー、入力、ルール、例外、権限、出力、証拠を1本につなぎ、Must/Should/Couldで投資順序を決めます。マスタのOwnerと版、例外の止め方、権限と監査、ERP連携の再送・照合を先に書けば、標準・設定・個別開発を公平に判断できます。

TOMAS TECHでは、タイ工場の現状業務整理、RFP要件、タイ語/日本語ヒアリング、ベンダーデモシナリオ、ERP連携、FAT/SAT証拠の設計を支援できます。製品や予算が未確定の段階でも、Must要件とシステム境界の整理から相談可能です。お問い合わせはこちら

生産管理システム 機能のよくある質問

生産管理システムにはどのような機能が必要ですか？

一般にはマスタ、製造要求、計画、作業指示、実績、材料/仕掛、品質、トレーサビリティ、例外、原価/KPI連携、権限/監査、運用機能があります。ただし全機能を初期Mustにせず、対象工程の業務結果と受入証拠から優先します。

生産管理システムの選び方で最初に決めることは何ですか？

製品名より先に、対象KPI、業務境界、ERPや設備との責任分担、Must要件を決めます。次に同じ実データシナリオで標準/設定/個別開発の適合を比較します。

Must・Should・Couldはどう判定しますか？

Mustは無いと法令、顧客、安全、品質、締め、業務継続、受入が具体的に成立しない要件です。Shouldは期限付き代替が可能、Couldは価値仮説を後で検証する要件です。判定理由と変更承認者を記録します。

生産管理システムのカスタマイズは避けるべきですか？

一律に避ける必要はありません。業界共通業務は標準、工場差は設定を優先し、顧客価値や固有工程を支え、Ownerとテスト・アップグレード・出口を持てる場合に個別開発を検討します。

ERP連携 生産管理で最も重要な要件は何ですか？

項目マッピングだけでなく、イベントの意味、一意ID、版、時刻、単位、応答、再送、隔離、照合、Ownerを契約することです。通信断と応答消失をSATで発生させ、二重計上しない証拠を確認します。

多言語対応は画面翻訳だけで十分ですか？

不十分です。マスタ名称、エラー、理由コード、ヘルプ、教育、サポート、翻訳変更のOwnerまで必要です。タイ語/英語を切り替えてもコードと実績が一致することを受入試験で確認します。

RFPで費用はどう比較しますか？

5年TCOとしてライセンス、環境、設定、個別開発、連携、移行、試験、教育、端末、保守、更新、変更、現地支援、終了時エクスポートを同じ前提で回答させます。未確定前提と予備費も分離します。

FATとSATの違いは何ですか？

FATは主にベンダー環境で標準、設定、連携、異常、証拠を確認します。SATはタイ工場の実ネットワーク、端末、データ、シフト、作業者で運用可能性と受入条件を確認します。

参考情報

• ISA-95 Series of Standards
• ISO/IEC/IEEE 29148:2018 Requirements engineering
• ISO/IEC 25010:2023 Product quality model
• ISO 8000-8:2015 Data quality
• NIST Digital Thread for Smart Manufacturing
• NIST SP 800-82 Rev.3
• Thailand BOI Investment Promotion Guide 2026