小規模な製造現場で生産管理システムを検討すると、最初の論点は「どの製品を買うか」になりがちです。しかし、失敗を分けるのは製品名よりも、どの業務を標準化し、どのデータを誰が持ち、何をもって受入完了とするかです。Excelを続ける、自作する、パッケージを導入する、段階的に組み合わせる――どの選択にも合理的な場面があります。逆に、対象工程や運用責任が曖昧なまま全面刷新すると、規模が小さい工場ほど日常業務への負担が重くなります。
本稿では、タイを含む小規模・中小製造業が、Excel継続、自作、パッケージ、スモールスタートを比較し、RFP、PoC、TCO、UATの条件まで落とし込む方法を解説します。価格や効果を一律に断定せず、仮定を明示した計算例を使います。結論は「最小機能を急いで入れる」ことではなく、「最小の業務範囲で、将来も使えるデータと運用を確立する」ことです。
結論：小規模向け生産管理システムは4つの選択肢を同じ物差しで比べる
判断は、機能数ではなく次の7軸で行います。
- 現場の痛み：欠品、仕掛滞留、納期回答、実績遅れ、ロット追跡のどれを最初に解くか。
- 対象範囲：1ライン、1製品群、1工場、複数拠点のどこまでを初期対象にするか。
- 標準化の度合い：現行業務を残すのか、パッケージ標準へ寄せるのか。
- 変化への追随：品種、工程、帳票、取引先要求が変わったとき、誰が直せるか。
- データ統制：品目、BOM、工程、在庫、実績の正本をどこに置くか。
- 運用能力：ユーザー管理、問い合わせ、教育、バックアップ、障害復旧を誰が担うか。
- 総保有コスト：初期費だけでなく、5年間の保守、改修、停止、内部工数、出口費用を含めるか。
この軸で見ると、Excel継続は変更が速く初期負担が小さい一方、属人化と同時編集、監査性に限界があります。自作は業務適合性が高い一方、担当者の離任や技術更新が運用リスクになります。パッケージは標準機能とサポートを得やすい一方、現場を標準へ寄せる意思決定が必要です。段階導入は投資と変化を制御できますが、最終像とインターフェースを決めずに小さく始めると、Excelや部分システムが増えるだけです。
Excel継続・自作・パッケージ・段階導入の比較
| 選択肢 | 向いている状態 | 主な強み | 主なリスク | 契約・管理で押さえる点 |
|---|---|---|---|---|
| Excel継続 | 対象者が少なく、データ量と同時更新が限定的 | 低い初期負担、変更が速い、現場が理解しやすい | ファイル乱立、数式破損、最新版不明、監査証跡不足 | ファイル所有者、版管理、入力規則、定期バックアップ |
| 自作 | 固有工程が競争力で、社内に継続開発力がある | 業務適合、細かな改善、外部制約が少ない | 担当者依存、保守負債、仕様不在、セキュリティ更新 | ソースコード所有、文書化、テスト、引継ぎ、第三者保守 |
| パッケージ | 標準業務へ寄せられ、必要機能が市場製品にある | 短期導入、標準機能、保守窓口、更新ロードマップ | 過剰機能、追加費用、ベンダー依存、標準とのギャップ | ライセンス単位、SLA、API、データ返却、価格改定条件 |
| 段階導入 | 優先課題が明確で、停止リスクを抑えたい | 学習しながら拡張、投資分割、現場受容を高めやすい | 部分最適、二重入力、暫定連携の固定化 | 最終アーキテクチャ、移行基準、段階別受入条件 |
「小規模だからExcelで十分」「将来を考えると最初からERP一択」のどちらも、前提なしでは正しくありません。利用者が5人でも、食品や自動車部品のようにロット追跡が厳密なら監査証跡が重要です。一方、利用者が50人でも、製造実績は設備から自動取得し、計画担当だけが操作するなら画面ライセンス数は限定できるかもしれません。人数だけで規模を定義せず、取引件数、同時更新、追跡粒度、業務停止の影響で判断します。
Excelを続けられる条件
Excel継続は「何もしない」ではありません。最低でも共有場所を一つにし、入力列、単位、コード、日付形式を固定し、計算式を保護し、承認済み版を識別できるようにします。品目マスターを各担当のファイルへ複製せず、正本と更新責任者を決めます。日次バックアップと復元テストも必要です。
次の兆候が複数ある場合は、Excelの延命費用を計測します。
- 同じ実績を生産、在庫、経理へ二重・三重入力している。
- ファイル統合に毎日時間がかかり、納期回答が翌日になる。
- 数式エラーや列追加で集計が止まる。
- 退職・休暇で更新できない表がある。
- ロット、仕掛、廃棄、不良の履歴が後から再現できない。
- 受注変更が計画と現場へ同時に伝わらない。
これらの作業時間と誤出荷、緊急輸送、過剰在庫の発生を記録すれば、システム化の投資上限を議論できます。
生産管理システムを自作できる条件
自作は、プログラムを書ける人がいるだけでは成立しません。業務責任者、プロダクトオーナー、開発、テスト、インフラ、セキュリティ、利用者教育の役割が必要です。品目コードや工程変更の承認も運用設計に含めます。開発者が一人の場合、休暇や退職時に誰が障害対応するか、データベースの更新や脆弱性対応を誰が続けるかを先に答えます。
自作が合理的なのは、固有の生産方式そのものが競争力で、市販製品へ合わせる方が大きな損失になる場合です。それでも、認証、ユーザー管理、監査ログ、バックアップなど差別化にならない基盤まで一から作る必要はありません。業務ロジックは自作し、認証やデータベース、帳票基盤は実績のある部品を使うハイブリッドも選択肢です。
生産管理システムのパッケージを選ぶ条件
パッケージはデモの印象ではなく、シナリオで評価します。「在庫管理あり」ではなく、「受注変更後に所要量を再計算し、欠品候補を表示し、承認後に購買依頼へ連携できるか」のように確認します。自社の代表品目、代替材料、外注工程、分割納入、手直し、廃棄、ロット分割を使って操作します。
Fit & Gapでは、Gapをすべて改修対象にしません。法規・顧客要求・品質保証に必須か、競争力に直結するか、単なる慣習かを分類します。慣習なら業務を変え、必須なら設定、アドオン、外部連携の順に検討します。改修が多いパッケージは、更新のたびに再テスト範囲が増えます。
スモールスタートの条件
スモールスタートは機能を削ることではなく、検証可能な境界を選ぶことです。たとえば、1製品群の「受注→計画→払出→実績→完成入庫」を対象にし、会計連携は日次集計、設備連携は後段とします。ただし、品目コード、ロット、単位、時刻、ユーザーIDは将来の全体構想と合わせます。
生産管理システム比較の実務ガイドでは製品比較の観点を、スモールスタート導入の設計方法では段階展開の考え方を詳しく解説しています。費用の分類を先に整理したい場合は、生産管理システムの費用ガイドも参照してください。
導入前に作る「最小業務モデル」
システム要件を書く前に、A3一枚程度で現状と目標の流れを描きます。対象は受注、生産計画、購買、材料入庫、払出、製造実績、検査、完成入庫、出荷です。各工程について、入力、出力、責任者、締め時刻、例外、現在の帳票を記載します。
特に重要なのは例外です。通常品だけのデモでは現場適合性を判断できません。次を候補にします。
- 受注数量や納期が途中で変わる。
- 材料の代替、ロット分割、返品がある。
- 工程を飛ばす、戻す、外注へ出す。
- 不良を手直し、廃棄、特採に分ける。
- 一つの原材料ロットが複数完成品へ分岐する。
- オフライン時に実績を保持し、復旧後に重複なく同期する。
このモデルから「初期対象」「将来対象」「対象外」を分けます。対象外を明示することは、プロジェクトの弱さではなく、納期と責任範囲を守るための設計です。
RFPに書くべき要件：機能一覧より業務シナリオ
1. 業務・データ量・非機能の前提
RFPには工場数、ライン数、ユーザー数、同時接続、品目数、BOM階層、製造指図件数、実績件数、在庫ロケーション、保存年数を記載します。数値が不明なら現状ログを1〜4週間計測し、推定方法を示します。
可用性は「24時間365日」と書くだけでは不十分です。計画停止を含むか、対象時間帯、月次か年次か、復旧目標時間（RTO）、復旧目標時点（RPO）、問い合わせ受付時間を分けます。小規模工場では高可用構成そのものより、ネットワーク断でも作業を継続できるローカルバッファや紙の退避手順が実用的な場合があります。
2. マスターとトレーサビリティ
品目、BOM、工程、設備、作業者、取引先、倉庫、単位、理由コードについて、作成、変更、承認、廃止の権限を定めます。有効開始日を持たせ、過去の指図が後日のマスター変更で書き換わらないことを確認します。
ロット追跡は「可能」だけでなく、順方向・逆方向に何秒で検索できるか、払出訂正やロット分割後もつながるか、添付証明書と結び付くかを受入条件にします。必要な保存期間は顧客契約や法規に合わせ、記事だけで一律年数を決めません。
3. 連携とエラー処理
ERPや会計とは、品目、受注、購買、在庫評価、完成実績、出荷のどれをどちらが正本として渡すかを項目単位で決めます。API、ファイル、データベース直結の方式だけでなく、再送、重複防止、エラー通知、締め後訂正、時刻・タイムゾーン、文字コードを定義します。
データベース直結は短期的に速くても、更新でテーブル構造が変わると壊れます。可能なら契約されたAPIまたはバージョン管理されたファイル仕様を使います。インターフェースごとに「送信側が成功と判断する条件」「受信側が重複を拒否するキー」「未処理を再開する手順」を書きます。
4. 権限・監査・バックアップ
最小権限を基本に、計画変更、実績訂正、在庫調整、マスター承認、ユーザー管理を分離します。一人が複数役割を担う小規模組織でも、高リスク操作だけは二者承認または月次レビューにできます。共有IDは避け、誰がいつ何を変更したかを監査ログに残します。
バックアップは「毎日取得」だけでは要件になりません。対象、頻度、保存先、暗号化、保持期間、責任者、復元手順、復元テスト頻度を定義します。クラウドサービスでも、サービス提供者のバックアップと、自社が誤削除・契約終了に備えて取得するエクスポートは別物です。
PoCは「無料デモ」ではなく意思決定の実験
PoCは、本番機能を安く先に作る工程ではありません。比較で不確実性が大きい仮説を検証します。たとえば「作業者が20秒以内に実績入力できるか」「既存バーコードを読み取れるか」「通信断から復帰しても重複実績が出ないか」「日次締めが30分以内に終わるか」です。
PoC計画には次を含めます。
- 仮説と、採用・不採用を分ける閾値。
- 代表品目と例外シナリオ。
- 対象ユーザー、端末、ネットワーク、プリンター。
- テストデータの作成・匿名化・廃棄方法。
- 期間、責任者、障害時のエスカレーション。
- 本番へ移行する成果物と、使い捨てる成果物。
- PoC後のデータ削除証明または返却方法。
ベンダーが用意した理想データだけで成功しても、自社の工程では判断できません。少なくとも一つは、数量訂正、手直し、代替材料などの例外を通します。
UATの受入条件を契約前に決める
UAT（User Acceptance Test）は完成後の確認会ではなく、支払いや本番移行を判断する検収工程です。RFPまたは契約時点で、テストケース、期待結果、重大度、再テスト、合格条件、未解決事項の扱いを決めます。
| 分類 | 受入条件の例 | 証跡 |
|---|---|---|
| 業務 | 代表受注から完成・出荷まで数量とロットが一致 | テストケース、画面、帳票、DB照合 |
| 性能 | 合意した同時利用・データ量で主要画面が所定時間内 | 負荷条件、応答ログ、測定時刻 |
| 連携 | 再送しても二重計上せず、失敗が担当へ通知される | メッセージID、エラーログ、再送記録 |
| 権限 | 未承認者が在庫調整・マスター承認できない | ロール表、拒否ログ |
| 復旧 | 合意RPOのバックアップからRTO内に復元できる | 復元手順、実測時間、照合結果 |
| 移行 | 件数、合計、サンプル明細が旧データと一致 | 移行照合表、例外一覧 |
「重大障害ゼロ」だけでは、軽微な不具合が大量に残る可能性があります。重大度ごとの上限、回避策、修正期限、保留を承認する責任者を設定します。UAT合格後も、安定化期間と初回月次締めの支援を契約範囲に含めます。
30・60・90日（30/60/90日）のスモールスタート導入計画
0〜30日：事実を測り、対象を固定する
最初の30日は購入を急がず、現状を数値化します。Excelや紙帳票の件数、転記時間、訂正件数、納期回答時間、在庫差異、緊急手配を測ります。品目、BOM、工程、在庫のマスター所有者を決め、欠損・重複・単位違いを洗い出します。
成果物は、現状業務図、課題優先順位、最小業務モデル、データ辞書、候補選択肢のロングリスト、概算TCO、RFP初版です。経営層は対象範囲と意思決定基準を承認します。現場リーダーは代表シナリオと例外を選びます。ITは連携、セキュリティ、バックアップを整理します。
31〜60日：RFP、デモ、PoCで不確実性を潰す
候補ベンダーへ同じシナリオとデータを提示します。採点表は、業務適合、使いやすさ、連携、データ統制、運用、セキュリティ、5年TCO、導入体制に分けます。デモの華やかさではなく、証跡を残して採点します。
上位候補だけでPoCを行い、現場の入力時間、例外処理、オフライン、ラベル、ERP・会計連携の難所を検証します。同時に、契約案のデータ所有権、SLA、価格改定、解約時支援をレビューします。この時点で、Excel継続が最も合理的だと判明する可能性も残します。
61〜90日：契約、UAT設計、初期展開準備
採用する選択肢と対象範囲を確定し、責任分担表を作ります。設定、移行、教育、UAT、切替、安定化の計画を基準化します。データクレンジングを始め、移行リハーサル日を決めます。権限表、監査ログ、バックアップ、ローカルバッファ、障害連絡を確認します。
90日で全機能を本稼働させる必要はありません。90日目の到達点は、「投資判断、契約、データ、受入条件、運用責任が揃い、安全に初期展開へ進める状態」です。短期間で無理に全面切替するより、この出口条件の方が再現性があります。
TCOで比較する：見積価格に入らない費用を可視化
TCOは、初期費用＋利用料＋保守＋改修＋インフラ＋連携＋移行＋教育＋内部工数＋停止リスク＋出口費用で見ます。比較期間は製品寿命や契約に合わせますが、ここでは5年の例を示します。
仮定を明示した計算例
以下は特定製品の価格や効果ではなく、計算方法を示す仮定例です。
- 初期設定・移行・教育：1,200,000 THB
- 月額利用・保守：45,000 THB
- 追加改修：初年度300,000 THB、3年目200,000 THB
- 社内運用：月40時間、負担単価700 THB/時間
- 端末・ネットワーク・バックアップ：5年合計350,000 THB
- 契約終了時のデータ抽出・移行準備：200,000 THB
5年TCOは次のように計算します。
1,200,000 + (45,000 × 60) + 300,000 + 200,000 + (40 × 700 × 60) + 350,000 + 200,000 = 6,630,000 THB
この例には業務停止や為替、税、価格改定を含めていません。実際には見積条件と自社の内部単価へ置き換えます。Excel継続もゼロ円ではなく、集計・照合時間、誤りの修正、監査準備、バックアップ、属人化リスクを同じ期間で見積もります。自作では開発費だけでなく、要件管理、テスト、監視、脆弱性対応、技術更新、引継ぎを含めます。
便益も保証値にしません。たとえば、日次集計を3人が各45分行い、稼働日を月22日、人件費の負担単価を500 THB/時間、削減可能割合を70%と仮定すると、年間時間便益は次です。
3人 × 0.75時間 × 22日 × 12か月 × 500 THB × 70% = 207,900 THB/年
これに在庫削減や納期遵守改善を加える場合、現状値、改善メカニズム、対象金額、実現責任者を示します。「在庫20%削減」のような根拠のない一般値を入れません。
データ所有権と契約終了時の出口を先に決める
「データは顧客のもの」と契約に一行書くだけでは不十分です。原データ、設定、マスター、添付、監査ログ、計算結果、ダッシュボード、API経由で生成されたデータの範囲を定義します。エクスポート形式はCSVだけでなく、主キー、関連キー、単位、コード表、時刻、文字コード、添付ファイル構造を含むデータ辞書が必要です。
確認項目は次の通りです。
- 契約中に追加費用なしで定期エクスポートできるか。
- APIの呼出上限、対象項目、履歴、監査ログを取得できるか。
- 解約通知からデータ受領、削除までの期間と費用。
- 提供者がデータを保持・削除する条件と証明。
- 設定やカスタム帳票の移管可否。
- 事業継続・サービス終了時の支援。
月次でサンプルエクスポートし、別環境で読めるか確認します。出口テストを契約終了時に初めて行うと、必要項目が取得できないことが分かっても交渉余地が小さくなります。
小規模工場向けの運用・権限・バックアップ設計
運用を大企業の縮小版にする必要はありません。少人数でも外してはいけない統制を選びます。
運用責任
業務オーナーは業務ルールと優先順位、データオーナーはマスター品質、システム管理者はユーザーと設定、ベンダーは合意した保守を担います。問い合わせ窓口を一本化し、障害、操作質問、改善要望を分類します。改善要望を障害として緊急改修すると、変更管理が崩れます。
権限
役職名ではなく作業でロールを作ります。計画作成、計画承認、実績入力、実績訂正、在庫調整、マスター変更、ユーザー管理を分けます。退職・異動時の停止期限と、四半期など定期的な棚卸しを決めます。共有端末でも個人認証を維持できる方法を選びます。
バックアップと復旧
クラウド、オンプレミスのどちらでも復元テストを行います。ローカルバッファは通信断の継続性を高めますが、同期競合と端末故障への対応が必要です。RPOとRTOは「できるだけ短く」ではなく、業務が許容できる損失量と停止時間から決めます。復元後に品目件数、未完指図、在庫合計、監査ログを照合するチェックリストを作ります。
推奨アーキテクチャ：現場を止めず、ERPと疎結合にする
小規模工場でも、Shop floor、edge/local buffer、application/database、ERP/accountingの4層を意識します。設備やバーコード端末からの実績は、必要に応じエッジで一時保持し、アプリケーションへ送ります。アプリは生産指図、実績、仕掛、ロットを管理し、ERP・会計へ合意した粒度で連携します。
各層にRBAC、監査ログ、バックアップを適用し、定期エクスポートを確保します。ERPの内部テーブルへ直接書き込む密結合は避け、障害時にどこまで止まるかを限定します。現場からクラウドへ直接すべて送る構成も、工場ネットワーク、遅延、セキュリティ、データ所在地の要件を確認して選びます。
重要なのは製品の新しさではなく、以下が説明できることです。
- 通信断中にどの業務が継続し、何件保持できるか。
- 再接続時に重複と順序逆転をどう防ぐか。
- マスター変更が各層へいつ反映されるか。
- 監査ログとバックアップを誰が閲覧・復元できるか。
- 全データをいつ、どの形式でエクスポートできるか。
公的支援・投資優遇は採用理由ではなく資金計画の一要素
タイではBOIが既存事業の効率向上を支えるSmart and Sustainable Industryの動きを公表しており、2026年第1四半期には同施策の申請61件、投資総額7,071百万THBと発表しました。内容には省エネ、再生可能エネルギー、機械更新、自動化・ロボット、デジタル技術が含まれます。これは市場全体の動向であり、小規模な生産管理システム案件が自動的に対象になることを意味しません。
depaは2026年に、SMEのデジタル活用、標準化されたデジタルサービス、試行や資金アクセスを支える施策・連携を発信しています。OSMEPのBDSも、事業者と登録サービス提供者をつなぐ仕組みを紹介しています。ただし、制度の受付期間、対象企業、対象費用、補助率、上限、事前申請の要否は変更され得ます。システム選定前に利用可能性を決めつけず、申請時点の最新条件をBOI、depa、OSMEP/BDSなどの公式窓口で確認してください。補助金がなくても成立するTCOを基準にし、採択された場合を上振れとして扱う方が安全です。
ISO 22400をKPI設計の共通言語として使う
ISO 22400-1:2014は、製造オペレーション管理（MOM）におけるKPIを定義、構成、交換、利用するための業界中立な枠組みを示し、2025年に現行性が確認されています。同規格の考え方は、KPIの名称だけでなく、目的、式、要素、時間範囲、単位、利用者をそろえるのに役立ちます。ISO 22400-2の公開プレビューでは、時間、物流、品質、エネルギーなどの要素とKPI記述が扱われています。
システム導入時には、OEEや納期遵守率を画面に出すだけでなく、計算式、停止分類、良品定義、計画時間、締め時刻、再計算ルールをデータ辞書にします。同じ「稼働率」でも工場とベンダーで分母が違えば、UATは合格できません。規格への適合や認証を本稿が断定するものではなく、正式な要求は購入した規格本文と専門家の助言で確認してください。
よくある質問
小規模な生産管理システムは何人から必要ですか？
人数だけでは決まりません。取引件数、同時更新、ロット追跡、納期回答、誤りの影響、監査要求で判断します。少人数でも追跡性が重要なら導入価値が高く、人数が多くても対象業務が単純なら統制したExcelで暫定運用できる場合があります。
中小企業向け生産管理システムで最初に入れる機能は？
最初の経営課題に直結する閉じた業務を選びます。受注と計画だけ、在庫だけでは二重入力が残りやすいため、「受注→計画→払出→実績→完成入庫」のように結果を検証できる最小の流れが有効です。品質や設備保全は将来連携を見込んでコード体系を合わせます。
生産管理システムを自作すると安くなりますか？
初期の画面開発費だけなら安く見えることがありますが、5年間の要件変更、テスト、監視、バックアップ、セキュリティ更新、担当者交代、障害対応を含めて比較する必要があります。固有業務が競争力で、継続する内製体制がある場合に合理性が高まります。
生産管理システムのパッケージはどう比較しますか？
機能チェック数ではなく、自社データを使った業務シナリオ、例外処理、連携、権限、復旧、エクスポートで比較します。5年TCOと契約終了時の出口も採点し、デモ結果を証跡として残します。
スモールスタートでシステム導入すると部分最適になりませんか？
最終アーキテクチャ、正本データ、共通コード、段階の移行基準を先に決めれば抑えられます。小さく始める範囲と、暫定対応を終了する条件を同時に決めることが重要です。
RFP・PoC・UATはすべて必要ですか？
規模に応じ簡素化できますが、役割は分けます。RFPは比較条件、PoCは不確実性の検証、UATは契約上の受入判定です。小規模案件なら文書を短くしても、目的と合否条件は省かない方が安全です。
タイの補助制度は使えますか？
候補になる制度はありますが、企業属性、事業内容、申請時期、対象費用により異なります。公表済みの過去条件を現在の案件へそのまま当てはめず、BOI、depa、OSMEP/BDSなどの公式窓口で最新条件を確認してください。
まとめ：小さく始めるなら、データと出口は最初から大きく考える
小規模工場の生産管理システムは、Excel、自作、パッケージ、段階導入のどれかを先入観で選ぶものではありません。最小業務モデルを作り、同じシナリオ、RFP、PoC、5年TCO、UATで比較します。導入範囲は小さくても、マスター、データ所有権、権限、監査、バックアップ、エクスポート、ERP・会計連携の原則は最初から決めます。
自社のExcelが限界か、パッケージへ寄せられるか、どの工程からPoCすべきかを整理する段階でも、TOMAS TECHへご相談いただけます。タイの製造現場と既存ERP・会計を前提に、比較表、RFP、30・60・90日計画の作成から支援します。お問い合わせはこちら。
参考情報
- Thailand Board of Investment, Q1 2026 investment applications and Smart and Sustainable Industry activity: https://www.boi.go.th/index.php?language=en&module=news&page=boi_event_detail&topic_id=138788
- Thailand Board of Investment, H1 2026 investment update: https://www.boi.go.th/un/boi_event_detail?language=de&module=news&topic_id=139075
- depa, digital transformation cooperation for Thai SMEs, 17 July 2026: https://www.depa.or.th/en/article-view/20260717_04
- depa, SME Spring Board / BDS workshop, 30 June 2026: https://www.depa.or.th/th/article-view/20260630_01
- OSMEP SME Scoring: https://osmepscoring.sme.go.th/
- OSMEP BDS public information: https://bds.sme.go.th/News/Detail/103
- ISO 22400-1:2014 overview and status: https://www.iso.org/standard/56847.html
- ISO/DIS 22400-2 public preview: https://www.iso.org/obp/ui?_escaped_fragment_=iso%3Astd%3Aiso%3A22400%3A-2%3Adis%3Aed-2%3Av1%3Aen
