生産管理システム比較｜タイ工場の選び方・RFP実務

「生産管理システム 比較」で検索すると、機能一覧や製品ランキングは数多く見つかります。しかし、タイの工場で本当に必要なのは、知名度ではなく、自社の業務、既存ERP、現場設備、帳票、ロット管理、支援体制に合うかを同じ条件で見極める方法です。本稿では、比較表、RFP、PoC、受入テストまでを一つの選定プロセスとして整理します。

生産管理システム比較で最初に決めること

比較を始める前に、「何を買うか」ではなく「何を改善し、どこまでを今回の対象にするか」を決めます。対象が曖昧なままデモを見ると、画面の見栄えや説明者の印象に評価が引っ張られます。候補Aは計画機能が強く、候補Bは実績収集が強く、候補Cはトレーサビリティが強い、といった違いを公平に比べられません。

まず、現行業務を「計画」「指示」「実行」「記録」「分析」の流れに分けます。各工程で、誰が、何を入力し、どのマスタを参照し、どの帳票やデータを出し、例外時に誰が判断するかを書きます。Excelが残っていても、それ自体を悪としないことが重要です。そのExcelが柔軟な計画調整に使われているのか、単なる二重入力なのかで、置き換えの優先度は変わります。

次に、プロジェクトの成功条件を三つ程度に絞ります。例えば「製造指図から実績確定までの転記をなくす」「原材料ロットから出荷ロットまでの追跡時間を短縮する」「日次会議で使うKPIを翌日ではなく当シフト内に確認する」です。ここで数値目標を置く場合は、現状値の測定方法も同時に決めます。測定定義のない“工数30%削減”は、提案比較にも受入判定にも使えません。

比較対象の境界を一枚にする

RFPの冒頭には、次の境界を一枚で示すと候補間の解釈差が減ります。

• 対象拠点、ライン、工程、製品群、利用人数、言語
• 対象業務と対象外業務
• ERP、WMS、品質、保全、設備、計量器、ラベルプリンタなどの接続先
• クラウド、工場内サーバー、ハイブリッドの制約
• 既存マスタと履歴データの移行範囲
• 本稼働希望時期と操業を止められない期間
• 監査、顧客要求、情報セキュリティ上の条件

境界を決める目的は、将来拡張を捨てることではありません。「今回の価格に含む」「オプションとして見積もる」「将来構想として記述だけ求める」を分けるためです。全部を必須にすると価格が膨らみ、逆に曖昧にすると契約後の追加費用が増えます。

タイ工場向け生産管理システムの選び方：9つの評価軸

製品名を横に並べる前に、評価軸と証拠を定義します。以下の九つは、多くのタイ工場で論点になりやすい実務軸です。業種、規模、顧客要求によって重みは変えてください。

1. 業務適合は機能数ではなくシナリオで見る

機能チェック表だけでは、候補はほぼすべて「対応可」になります。大切なのは、日常業務と例外業務を端から端まで通せるかです。受注変更、材料不足、設備停止、計画差し替え、部分完了、不良、手直し、代替材、ロット分割、ロット統合、夜勤中の障害など、自社で頻度または影響が大きい場面をシナリオ化します。

デモでは、候補ベンダーが用意した完成画面を見るだけでなく、自社の品目、BOM、工程、シフト、単位、ロット規則を最小セットで登録してもらいます。担当者がどの画面を何回操作し、例外をどこに記録し、承認履歴が残るかを観察します。「カスタマイズすれば可能」という回答は、標準対応と分け、費用、期間、更新時の影響を記録します。

2. 生産管理システムの費用は3年TCOで揃える

初期見積だけを比較すると、月額利用料、追加環境、バックアップ、連携監視、バージョンアップ、問い合わせ支援、社内担当者の工数が抜けます。逆に、すべてのリスクを大きな予備費にまとめると候補差が見えません。費用は同じ三年間、同じ利用者数、同じ拠点数、同じ通貨換算日で揃えます。

詳しい費用項目はタイ工場の生産管理システム費用でも整理しています。比較表では少なくとも、ライセンスまたはサブスクリプション、導入設定、追加開発、データ移行、外部連携、インフラ、教育、テスト、稼働支援、保守、社内工数、予備費を分けます。税、旅費、時間外対応、為替、契約更新時の値上げ条件も明記します。

3. ERP・設備・帳票連携は正常系より復旧を見る

「APIがあります」だけでは連携品質を判断できません。ERPから製造指図を受ける時刻、差分方式、キー、取消・変更、重複防止、タイムアウト、再送、照合、監視、手動復旧、責任分界を確認します。設備接続では、PLCやゲートウェイから値を取れるかだけでなく、通信断中のバッファ、時刻同期、異常値、タグ変更、設備追加時の作業を見ます。

帳票連携ではタイ語・英語・日本語の文字、日付形式、単位、小数、バーコード、ラベル再発行の権限が論点になります。現場実績の収集方式を検討する場合は、タイ工場の生産実績収集システムも参考になります。

4. ロット・トレーサビリティは“きれいな流れ”だけで評価しない

トレーサビリティは、入荷ロットから製品ロットへの通常紐付けだけなら多くのシステムが説明できます。差が出るのは、材料の分割・混合、仕掛の合流、手直し、再検査、副資材、包装材、代替投入、廃棄、保留解除などの例外です。前方追跡と後方追跡の両方を、数量整合と時刻を含めて確認します。

企業間でイベントデータを交換する必要がある場合、GS1 EPCISは、what、when、where、why、howを扱う可視化イベントの標準として検討できます。EPCIS 2.0はセンサーデータ、認証情報、JSON/JSON-LD、REST APIなどをサポートします。ただし、EPCIS採用は全工場の必須条件ではありません。顧客、サプライヤー、物流事業者との相互運用性が必要かを先に判断します。

5. KPIは名称ではなく定義・式・時間で揃える

「OEE対応」「生産性を可視化」と書かれていても、停止時間、計画時間、良品、手直し、段取りの扱いが違えば値は一致しません。ISO 22400-1は、バッチ、連続、離散の製造にまたがるMOM向けKPIの業種横断フレームを示しており、2014年版は2025年に確認され現行とされています。ISO 22400-2は、選定されたKPIについて式と要素、時間挙動、単位・次元などを扱います。なおPart 2のISOページは改訂予定も示しているため、契約時点の版を確認してください。

RFPでは「KPIがあるか」ではなく、名称、目的、式、入力元、欠損時の扱い、時間粒度、締め後の修正、責任者を回答させます。PoCでは、同じ原データから既存集計と候補システムの値を出し、差分理由を説明できるかを見ます。

6. セキュリティと技術供給者リスクを別紙にしない

生産管理システムは、製造条件、品目、原価に関わるデータと、ERP・設備への接続を持ちます。導入時のパスワード設定だけでなく、運用中の権限変更、ログ確認、脆弱性通知、バックアップ復元、インシデント連絡、サブプロセッサ、サポート終了までを比較対象にします。

NIST SP 1305は、CSF 2.0のGV.SCを使ったサイバーサプライチェーンリスク管理能力の構築と、供給者要件の定義・伝達を説明しています。これをRFPへ応用し、供給者の開発・運用体制、依存サービス、脆弱性対応、契約終了までを質問します。NIST CSF 2.0は規模・業種・成熟度を問わず使えるリスクベースの成果フレームで、特定技術の採用を強制するものではありません。候補に“準拠”の自己申告だけを求めるのではなく、自社リスクに対する証拠を求める使い方が適切です。

7. ローカル支援は言語だけでなく復旧能力を見る

タイ語窓口の有無は重要ですが、それだけでは不十分です。工場の操業時間に一次応答できるか、アプリ、ネットワーク、端末、連携のどこまで切り分けられるか、現地訪問が必要なときの条件、製品開発元へのエスカレーション経路を確認します。日本本社、タイ拠点、地域統括、製品メーカーが分かれる場合は、誰が最終責任を持つかを契約前に一枚にします。

提案段階で、架空の障害を一つ提示して対応演習をすると有効です。「夜勤でERPから指図が届かない。現場は生産を継続すべきか」という問いに対し、受付、切分け、暫定運用、復旧、再送、整合確認、報告まで説明してもらいます。

8. データ移行は本番直前の作業ではない

移行対象には、品目、BOM、工程、設備、取引先、在庫、仕掛、未完指図、ロット、品質状態、ユーザー、権限、必要な履歴があります。すべてを移す必要はありません。法令、顧客要求、分析、現場照会に必要な期間を決め、旧システムを参照専用で残す選択も比較します。

候補ごとに、抽出、変換、クレンジング、投入、照合、不一致処理、再実行の方法を聞きます。本番一回で成功させる前提ではなく、少なくとも移行リハーサルと差分移行の計画を求めます。データ件数だけでなく、単位変換、桁、コード体系、改訂、重複、文字コードを確認します。

9. 撤退可能性は導入前に契約する

選定時には長期利用を想定しますが、事業再編、製品終了、価格改定、支援品質の低下で切り替えが必要になることがあります。契約終了時に、マスタ、取引、実績、監査ログ、添付ファイルを一般的な形式で出力できるか、データ辞書とインターフェース文書を受け取れるか、出力費用と期間、削除証明、移行支援を確認します。

撤退可能性は“簡単に他システムへ移れる”という保証ではありません。少なくともデータを人質に取られず、次の移行を計画できる状態を作ることです。独自拡張が増えるほど、ソース、仕様、テスト、知識移管の契約が重要になります。

生産管理システム比較表の作り方

比較表は、○△×ではなく、要求、重要度、回答、証拠、制約、費用、責任者を結びます。同じ質問に対して候補ごとに自由文を書かせるだけでは採点できません。回答区分を次のように固定します。

回答Sでも無条件に高得点にはしません。標準機能でも自社の権限規則や例外処理に合わないことがあります。反対に個別開発Dでも、競争力に直結する業務で、責任と保守が明確なら採用可能です。重要なのは、候補間で同じ意味を使うことです。

推奨重みの例

次は説明用の一例であり、市場標準やTOMAS TECHの固定基準ではありません。自社のリスクに応じて経営、製造、品質、IT、財務で合意してください。

各軸を0〜5点で採点する場合、加重得点は「得点÷5×重み」で計算できます。ただし総合点だけで自動決定しないでください。重大な法令違反リスク、必須顧客要求の未対応、復元不能、契約上のデータ出力不可などは、足切り条件にします。また、採点者ごとの差が大きい項目こそ議論の価値があります。平均値で埋めず、なぜ評価が割れたかを確認します。

生産管理システムRFPに書くべき項目

RFPは分厚い機能辞書ではなく、候補が同じ前提で設計・見積・リスク回答を行うための文書です。タイでのパッケージソフト導入支援で扱う導入体制も踏まえ、次の章を用意します。

1. 会社・工場・製品・生産方式の概要
2. 現状課題と測定済みベースライン
3. 対象範囲、対象外、将来範囲
4. 業務シナリオと優先度
5. データ、マスタ、ロット、帳票要件
6. ERP・設備・外部システム連携
7. KPIとレポート定義
8. 非機能要件とセキュリティ
9. 移行、教育、テスト、切替、安定化
10. 支援時間、SLA、責任分界
11. 価格回答様式と3年TCO
12. 契約、知的財産、データ、終了条件
13. 回答期限、質疑方法、評価プロセス

“対応できますか”を“証明してください”へ変える

質問は「ロット追跡に対応していますか」ではなく、「材料ロットを二つの仕掛ロットへ分割し、一方を手直し後に別の完成品ロットへ統合した場合、完成品から原材料へ、原材料から出荷先へ追跡してください。数量差の理由と操作履歴も表示してください」と書きます。

連携なら、「ERPが同じ指図を再送した場合の重複防止」「ネットワーク断から復旧した際の順序保証」「マスタ不整合時の隔離と再処理」を実演項目にします。セキュリティなら、権限表のサンプル、管理者操作ログ、バックアップからの復元記録、脆弱性通知の流れを求めます。マーケティング資料ではなく、評価可能な証拠に変えるのがRFPの役割です。

生産管理システム費用を3年TCOで比較する例

以下は計算方法を示す架空の例で、実在案件の価格、TOMAS TECHの標準価格、市場平均ではありません。単位はTHB、期間は3年と仮定します。

候補ごとに同じ行を使い、含まれない項目はゼロではなく「別途」「未見積」とします。未見積が多い候補は安いのではなく、不確実性が高い候補です。利用者数、取引量、設備点数、保存年数、API回数で変動する料金は、基準ケースと増加ケースを出します。

便益は売上増、在庫、停止、不良、転記、追跡、締め作業などに分けますが、重複計上を避けます。例えば停止時間短縮と生産量増加を別々に全額計上すると同じ効果を二重に数える場合があります。便益の責任者、測定元、実現開始月、達成確率を置き、強気・基準・慎重の三つで見ると投資判断が安定します。

BOI施策は“値引き”として先取りしない

タイBOIのSmart and Sustainable Industryの案内では、効率向上投資について土地・運転資金を除く最低投資額100万THB、機械・設備の輸入関税免除、条件に応じた3年間の法人税免除が示されています。税免除額は対象投資額の50%相当、国内自動化産業との連携・支援に関する30%以上の条件を満たす場合は100%相当という記載があります。

ただし、生産管理システム導入が自動的に対象になるわけではありません。対象活動、申請時期、投資範囲、機械・ソフトウェア・サービスの扱い、既存BOI事業との関係などを案件ごとにBOIまたは適切な専門家へ確認してください。比較表では、確認前の優遇を確定値としてTCOから差し引かず、「適用時のシナリオ」として別表示します。

PoCは製品紹介ではなく失敗条件の確認に使う

PoCの目的は、全機能を小さく導入することではありません。選定を左右する不確実性を低コストで潰すことです。例として、代表ライン一つ、製品群二つ、二シフト、4〜6週間という範囲を置けますが、これは計画例であり普遍的な基準ではありません。

PoC前に、検証仮説、入力データ、担当、期間、成功・失敗条件、成果物、本番への流用可否を合意します。候補ごとに環境やデータ量が違うと比較にならないため、共通シナリオと共通データセットを用意します。

PoCで高得点でも、本番の性能、全拠点展開、長期保守が保証されるわけではありません。逆にPoCの失敗は候補排除だけでなく、要求やデータ品質の問題を発見する機会です。どの失敗を製品制約、設計不足、自社準備不足に分類するかを共同で記録します。

受入テストを契約前から設計する

受入テストは導入の最後にユーザーが画面を触る行事ではありません。RFPの重要シナリオを、契約上の完了条件へ変換する工程です。要件ごとにテストID、前提、入力、操作、期待結果、証拠、担当、重大度を持たせます。

テストを四層に分ける

1. 機能テスト：指図、実績、在庫、品質、ロットなどが要求通り動くか
2. 結合テスト：ERP、設備、帳票、認証、外部サービスをまたぐか
3. 業務受入テスト：実際の役割とシフトで例外を処理できるか
4. 運用受入テスト：監視、バックアップ、復元、問い合わせ、暫定運用が機能するか

性能値や復旧時間を置く場合は、自社の操業条件から決めます。「応答が速い」ではなく、同時利用、取引量、回線条件、時間帯、測定地点を定義します。重大障害が残っていても期日優先で検収する場合は、未解決一覧、回避策、期限、責任、支払留保を文書化します。

データ照合を受入の中心にする

新システムの画面が正しく見えても、ERP残高、仕掛、ロット、KPIが合わなければ稼働できません。移行前後の件数、数量、金額、状態別内訳を照合し、不一致がゼロでない場合の許容理由を承認します。インターフェースは送信件数だけでなく、受信、拒否、保留、再送、重複の合計が一致するかを確認します。

導入ロードマップ：比較から安定化まで

選定と導入を切り離さず、次のゲートで進めます。

体制には、製造、計画、品質、物流、保全、IT、財務、経営スポンサーを含めます。全員が毎会議へ出る必要はありませんが、要求決定者と受入責任者を明確にします。ベンダーだけに現行業務の整理を任せると、暗黙の例外や部門間の責任差が抜けます。

比較でよくある失敗と回避策

製品ランキングを自社順位だと思う

一般的なランキングは市場理解の入口にはなりますが、自社の業務適合、タイ拠点支援、既存ERP、データ移行、契約条件までは代替できません。ランキングを候補抽出に使っても、最終評価は自社シナリオと証拠で行います。

要求を全部「必須」にする

必須が多すぎると、実質的に現行システムの再現になり、候補が個別開発前提になります。Must、Should、Could、対象外に分け、Mustには満たせない場合の業務影響を書きます。

デモの前に評価票を配らない

評価者が自由に感想を書くと、話し方、画面色、最後に見た候補に影響されます。デモ前にシナリオ、質問、採点基準を配り、個別採点後に合議します。

最安見積を最小TCOと誤認する

初期費が低くても、連携、移行、追加環境、支援、社内工数が別ならTCOは上がります。「未見積」を可視化し、前提差を調整してから比べます。

稼働日をゴールにする

本稼働直後は、データ不整合、操作質問、例外処理、KPI差分が集中します。安定化期間、日次レビュー、障害優先度、終了条件を計画し、通常保守へ引き渡すまでを導入範囲にします。

まとめ：比較表を意思決定の証拠にする

生産管理システム比較で大切なのは、製品数を多く見ることではありません。自社の重要シナリオを定義し、九つの評価軸で証拠を揃え、3年TCO、RFP、PoC、受入テストを一つの流れにすることです。標準機能、個別開発、パートナー製品、将来計画を区別し、重大リスクは総合点とは別に足切りします。こうすれば、選定理由を経営、現場、IT、監査へ説明でき、導入後の追加費用や責任の曖昧さも減らせます。

比較軸の設計やRFPのたたき台を作る段階でも、現行業務と接続先を整理できれば相談は可能です。タイ工場の条件に合わせて候補へ同じ質問を投げられる形にしたい場合は、TOMAS TECHのお問い合わせページをご利用ください。

FAQ

生産管理システムの選び方で最初に確認することは？

最初に製品一覧を見るのではなく、対象拠点・工程・業務、解決したい課題、現状値、対象外、接続先、成功条件を決めます。その後、重要な通常・例外シナリオを作り、候補が同じ条件で実演できるようにします。

生産管理システムの費用はどう比較しますか？

初期費だけでなく、同じ期間のTCOで比較します。ライセンス、設定、個別開発、連携、移行、インフラ、教育、テスト、稼働支援、保守、社内工数、予備費を同じ行に揃え、「別途」「未見積」をゼロと扱わないことが重要です。

生産管理システム導入のRFPには何を書きますか？

工場概要、課題とベースライン、範囲、優先度付き業務シナリオ、データ・ロット・帳票、連携、KPI、非機能・セキュリティ、移行、教育、テスト、SLA、価格様式、契約・終了条件を書きます。質問は可否ではなく証拠を求める形にします。

PoCとデモの違いは何ですか？

デモは候補の能力を共通シナリオで確認する選定活動です。PoCは、追跡の例外、設備連携、KPI計算など、採用判断を左右する不確実性を自社に近いデータ・条件で検証します。PoCの成功条件と本番へ流用できる範囲を事前に決めます。

クラウド型とオンプレミス型のどちらを選ぶべきですか？

一律の正解はありません。回線停止時の操業、設備接続、データ所在、更新、バックアップ、復旧、拠点展開、社内運用能力を比較します。ハイブリッドも含め、正常時だけでなく通信断と復旧後の整合を検証します。

ベンダーのローカル支援は何を確認しますか？

対応言語、受付時間、初動、現場訪問、対象範囲、製品開発元へのエスカレーション、障害報告、SLAを確認します。夜勤の連携障害など具体的な場面を示し、暫定運用から復旧・照合まで説明してもらうと実力が見えます。

BOI優遇を生産管理システム費用から差し引いてよいですか？

適用確認前に確定便益として差し引くべきではありません。Smart and Sustainable Industryには投資額や対象、手続きの条件があります。対象活動、費目、申請時期などをBOIまたは適切な専門家へ案件ごとに確認し、TCOでは適用時シナリオを別表示します。

将来のシステム切り替えに備えて何を契約しますか？

マスタ、取引、実績、監査ログ、添付の出力形式、データ辞書、インターフェース文書、出力費用・期間、削除証明、終了時支援を契約します。切り替えが簡単になる保証ではありませんが、移行を計画できる状態を確保できます。

参考情報

• Thailand BOI, Smart and Sustainable Industry: https://www.boi.go.th/th/smart_sustainable
• Thailand BOI, investment applications press release (1H 2026): https://www.boi.go.th/index.php?_module=news&from_page=press_releases2&language=en&page=press_releases_detail&topic_id=139075
• NIST SP 1305, Cybersecurity Supply Chain Risk Management: https://csrc.nist.gov/pubs/sp/1305/final
• GS1 EPCIS: https://www.gs1.org/standards/epcis
• ISO 22400-1: https://www.iso.org/cms/%20render/live/en/sites/isoorg/contents/data/standard/05/68/56847.html
• ISO 22400-2: https://www.iso.org/standard/54497.html
• NIST Cybersecurity Framework 2.0: https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final

注：制度、標準、製品仕様は更新されます。BOIの適用可否、ISOの版、契約・税務・法務上の扱いは、判断時点の一次資料と専門家の助言で確認してください。本文の重み、費用、PoC期間は説明用の仮定であり、統計や価格表ではありません。