在庫管理システム導入を検討するとき、製品比較や見積依頼を急ぐほど、現場で起きている在庫移動の定義が置き去りになりがちです。タイ工場で本当に決めるべきことは、クラウドかオンプレミスかではありません。入荷、移動、払出、返品、保留、棚卸差異、訂正の一件一件を、誰が・いつ・どこで・何を・いくつ・なぜ動かしたかという一つの権威あるイベントとして残し、ERP・会計と黙って食い違わない仕組みにできるかです。本稿では、RFP、費用、90日パイロット、FAT/SAT、受入判定までを、タイ工場の実務に沿って整理します。
在庫管理システム導入の結論：製品名より先に「正本イベント」と受入条件を決める
導入案件の成否は、画面数や機能一覧ではなく、在庫の正本を誰が持つかで決まります。現場アプリが受入を完了したのにERPには未計上、品質保留品を倉庫残として出庫可能、通信断後の再送で同じ入荷を二重計上、といった状態を許せば、バーコードを導入しても在庫差異は別の形で残ります。
見積依頼前に、少なくとも次の五点を決めてください。
- 在庫残高の会計上の正本、現場実行の正本、マスターの正本をそれぞれどのシステムが持つか。
- 入荷、保管、製造払出、戻入、移動、品質保留、廃棄、委託、棚卸、訂正をどのイベントで表すか。
- 品目、単位、保管場所、ロット／シリアル、在庫状態、所有者の最小データをどう統治するか。
- 通信断、重複スキャン、ERP停止、月末締め、取消のときに、黙った迂回を許さずどう復旧するか。
- FATとSATでどの入力を与え、どの出力なら受け入れるか。
比較対象は、ERP在庫モジュール、軽量在庫アプリ、WMS、個別連携レイヤーの四類型です。どれが常に優れるわけではありません。工程と取引の複雑さ、現場応答速度、トレーサビリティ、会計連携、拠点展開、保守体制に合わせて選びます。
タイ工場で今、在庫管理システム導入を証拠ベースで進める理由
Thailand BOIが公表した2026年上期の投資申請は、前年同期比37％増の約1.47兆THB、1,299件でした。これは個別の在庫管理システムの効果や優遇認定を示す数字ではありません。ただし製造・デジタル投資が活発な局面では、設備やソフトウェアを増やすだけでなく、増えた取引を監査可能な形で統合する必要が高まります。
BOIのIndustry 4.0 transformationに関する告示の英訳資料では、一定条件下のデジタル技術、ソフトウェア、クラウド、企業管理関連の支出が対象になり得る旨が示されています。しかし、対象可否はプロジェクト固有です。在庫管理システムを導入すれば自動的に恩典を受けられるとは言えません。投資計画に含める場合は、BOIや専門家へ書面で確認してください。
会計・税務との接続も欠かせません。タイ歳入局のRevenue Codeでは、期末在庫の評価について原価または市場価格のいずれか低い額を用いる旨と、評価方法の整合性に触れています。IAS 2も棚卸資産を原価と正味実現可能価額のいずれか低い額で測定し、状況に応じて個別法、FIFO、加重平均などを扱います。これは一般的な制度上の論点であり、本稿は税務・会計助言ではありません。また、WMSが会計方針を自動的に決めるわけでもありません。システムには、採用済み方針を再現できる数量・単位・原価連携・締めの証跡が必要です。
FIFO在庫管理の設計では先入先出とロット運用を詳しく扱っています。本稿はその前段として、導入プログラム全体と受入方法に焦点を当てます。製品範囲と予算を比較したい場合は、タイ工場向けWMS費用の整理も併せて参照してください。
導入範囲をRFP前に切り分ける
「在庫管理」という一語には、会計残高、倉庫作業、製造現場、品質、調達、販売、外注、委託在庫が混在します。境界を曖昧にしたまま提案を募ると、各社が異なる範囲を見積もり、価格も納期も比較できません。
在庫台帳と倉庫実行を分ける
在庫台帳は、品目・場所・状態・所有者ごとの数量を取引で増減させる論理です。倉庫実行は、入荷予約、検品、ラベル、ロケーション提案、ピッキング、梱包、積込、作業指示など、人と物を動かす論理です。ERPは台帳に強くても、ハンディ端末の低遅延運用や波動ピッキングまで備えないことがあります。一方、WMSは現場実行に強くても、会計締めの正本ではない場合があります。
RFPでは「在庫機能あり」と書かず、各イベントについて、入力、正本、承認、ERP計上時点、エラー時の滞留先、訂正方法を表にします。
製造払出・戻入を通常移動で済ませない
原材料のライン払出、余り材の戻入、仕掛品の工程移動、完成品の入庫には、生産指図、工程、BOM、ロット消費、歩留まりが関係します。倉庫間移動と同じ画面で数量だけ変えると、後から「どの生産に使ったか」を説明できません。バックフラッシュを採用する場合も、理論消費と実消費の差異、代替材、再投入、廃棄の処理を定義します。
品質保留は数量ではなく状態の管理
検査待ち、不適合、特採、返品待ち、再検査は、物理的に同じ棚にあっても利用可能在庫とは限りません。在庫状態と物理場所を分け、状態変更の権限と根拠文書を残します。ISO 9001:2015の文書化情報に関するガイダンスは、要求される場合の一意な識別、リリース、不適合などの証拠を扱いますが、ソフトウェア導入だけで認証されるわけではありません。要求事項に沿う運用証拠を残せるかが重要です。
委託・外注・顧客所有品の所有者を持つ
同じ品目・ロットが自社所有、仕入先委託、顧客支給で混在するなら、所有者を在庫次元に含めます。物理棚が同じでも、使用可否、評価、補充責任が違います。外注工程へ搬出した数量も、単純な消滅ではなく、外部場所・外注指図・予定返却日と結びます。
在庫差異の原因と対策を「イベント欠落」から考える
在庫差異は棚卸で見つかりますが、原因はその前の取引にあります。よくある原因を「作業者のミス」でまとめると改善できません。
| 差異の症状 | 背後にある設計問題 | システム・運用対策 |
|---|---|---|
| 現物はあるが帳簿にない | 未計上受入、通信断、仮置きの未移動 | 仮置き場所を正式化し、未同期キューと経過時間を可視化 |
| 帳簿はあるが現物がない | 二重払出、場所違い、未記録廃棄 | 重複防止キー、場所スキャン、廃棄承認イベント |
| ロットが合わない | ラベル貼替、混載、ロット入力省略 | ラベル再発行履歴、容器単位ID、必須スキャン |
| 数量だけが周期的にずれる | 単位換算、端数、包装入数変更 | UOM版管理、換算ルール、端数の扱いをテスト |
| ERPとWMSが時刻でずれる | 非同期連携、再送、締め後計上 | posting timeとevent timeを分離し、照合キューを設ける |
| 棚卸後に差異が戻る | 凍結中取引、遡及計上、未送信端末 | 棚卸スコープ凍結、遡及ルール、端末同期確認 |
対策の要点は、差異調整伝票を作れることではありません。元イベント、期待イベント、実際の計上、訂正イベントをリンクし、同じ差異が繰り返す原因を集計できることです。
最小データモデル：残高より先に移動イベントを設計する
在庫残高はイベントの累積結果です。残高だけを毎晩上書きすると、どこで差が生じたか再現できません。最低限、以下を持つイベントを推奨します。これは特定製品の必須形式ではなく、RFPで意味をそろえるための実務案です。
| 項目 | 意味 | 受入で確かめる点 |
|---|---|---|
| event ID | 一件を一意に識別 | 再送しても同じ取引を二重計上しない |
| item / UOM | 品目と数量単位 | 基本単位、取引単位、換算版、丸め |
| from / to location | 出所と行先 | 仮置き、ライン、車両、外注先も場所として定義 |
| lot / serial | 追跡単位 | 分割、統合、期限、親子容器を失わない |
| stock status | 利用可否 | available、quarantine、blocked等の遷移権限 |
| owner | 所有主体 | 自社、顧客、仕入先の混同を防ぐ |
| event time | 現場で起きた時刻 | オフライン中も発生時刻を保持 |
| posting time | 正本へ反映した時刻 | 遅延・月末跨ぎを説明できる |
| business reason | なぜ動いたか | PO、製造指図、返品、差異、廃棄等へ参照 |
| actor / device | 誰・何が記録したか | 人、端末、自動連携、ルールを識別 |
| correction link | 取消・訂正の関係 | 元イベントを削除せず逆仕訳で追跡 |
GS1 Global Traceability Standard 2.0は、重要な追跡イベントについて、日時、対象物の識別、場所、business step／disposition、責任主体などを記録する考え方を示しています。GS1 EPCIS 2.0は、what・when・where・whyの文脈で可視化イベントを表し、REST、JSON-LD、センサーデータも扱えます。EPCISはすべてのWMSに必須ではありませんが、複数拠点や取引先をまたぐトレーサビリティでは、独自項目を増やす前に相互運用モデルを検討する価値があります。
在庫管理システム比較：四つの構成パターン
ベンダー名ではなく、正本と実行責任の置き方で比較します。
| パターン | 向く状況 | 強み | 注意点 |
|---|---|---|---|
| ERP在庫モジュール中心 | 工程が比較的単純、会計統制優先 | マスター・購買・生産・会計が近い | 現場端末、オフライン、複雑な倉庫作業を要確認 |
| 軽量在庫アプリ | 小規模倉庫、短期立上げ、限定範囲 | 導入が速く画面が簡潔 | 拠点拡張、監査、ERP再送、複雑なロットに限界もある |
| WMS中心 | 多ロケーション、多入出荷、作業最適化 | 現場実行、ロケーション、作業指示に強い | ERPとの責任境界、カスタマイズ、運用保守が重要 |
| 個別連携レイヤー | 既存複数システムを維持、特殊工程 | 工場固有のイベントを吸収しやすい | 隠れた正本、属人化、変更費用を避ける統治が必要 |
評価表では「機能あり／なし」だけで採点しません。標準機能で可能か、設定か開発か、誰が保守するか、障害時にどの証跡が出るか、バージョンアップで維持できるかを記載します。デモには自社の異常ケースを持ち込み、想定結果と照合します。
バーコード・QR・RFIDは対象物と環境で選ぶ
識別媒体の選択は宗教論ではありません。GS1 General Specificationsの現行アーカイブではVersion 26.0.0が2026年1月に公表されています。品目・物流単位・場所の識別とデータキャリアを、ローカルな思いつきで設計せず、標準と取引要件に沿って統治します。
一次元バーコードは、既存流通や短い識別子との互換性が高く、安価です。二次元コードは、限られた面積により多くのデータを持たせやすい一方、コード内にすべてを詰め込むとマスター更新と矛盾します。RFIDは非接触・一括読取に利点がありますが、金属、液体、読取範囲、タグ費、誤読、工程設計を現場で検証する必要があります。
RFPでは、何に貼るか（品目、箱、パレット、治具、場所）、いつ発行するか、誰が再発行できるか、ラベルを失ったときどう本人性を回復するかを決めます。再発行は同一IDの複製か新IDへの置換かを区別し、印刷者・時刻・理由・旧IDを残します。
RFPに入れるべき実務要件
プロセスと例外
- 予約なし入荷、過不足、部分入荷、返品、混載、破損を扱えるか。
- ロット分割・統合、期限、シリアル、容器親子関係を保てるか。
- 製造払出、戻入、代替材、再投入、スクラップを指図へ結び付けられるか。
- 品質保留、解除、特採、再検査を権限と根拠付きで残せるか。
- 委託・外注・顧客所有品を所有者別に照合できるか。
タイ現場での利用性
- タイ語・英語・必要に応じ日本語で、ラベルと画面の用語を一貫管理できるか。
- イベントIDや理由コードは言語非依存とし、表示名だけを翻訳できるか。
- 手袋、照明、騒音、Wi-Fi死角、共有端末、交替勤務で操作できるか。
- オフライン時に何を許し、画面が「未同期」を明確に示すか。
- 現地サポート時間、重大度定義、一次対応、エスカレーション、部品交換を示せるか。
統合・性能・復旧
- API、ファイル、メッセージの仕様と、版管理・認証・監視方法は何か。
- 同じevent IDの再送を冪等に処理し、異なる内容なら競合として隔離できるか。
- ERP停止時に現場をどう継続し、復旧後に何件をどの順で送るか。
- ピーク時のスキャン応答、同時利用、日次件数、履歴年数をどの試験で証明するか。
- バックアップ対象にDBだけでなく設定、ラベル、連携、権限を含め、復元試験を行うか。
セキュリティと監査
- 役割別最小権限、職務分掌、退職・異動時の失効を管理できるか。
- 管理者操作、マスター変更、ラベル再発行、在庫訂正を改ざん防止ログへ残せるか。
- 共有端末でも個人または承認可能な主体へ追跡できるか。
- 脆弱性対応、更新、遠隔保守、証明書・秘密情報の更新手順があるか。
在庫管理システム費用：単価ではなく3年TCOで比べる
公開情報だけから普遍的な導入価格や改善率を示すことはできません。次は説明用の仮定シナリオであり、TOMAS TECHや他社の見積、相場、実績ではありません。単一倉庫、20名の記名ユーザー、稼働SKU 5,000点のタイ工場を仮定し、金額はTHB、VATを除き、1年目以降のハードウェア交換は含めません。
| 初期費用項目 | 仮定額（百万THB） |
|---|---|
| 現状調査・RFP・fit-gap | 0.20 |
| マスターデータ整備・移行 | 0.25 |
| ERP連携・帳票 | 0.45 |
| ハンディ・プリンター・ラベル・ネットワーク準備 | 0.35 |
| 教育・パイロット・切替 | 0.15 |
| 予備費 | 0.21 |
| 初期費用小計 | 1.61 |
年間のサブスクリプション、サポート、運用費を0.60百万THBと仮定すると、3年TCOは 1.61 + 0.60 × 3 = 3.41百万THB です。見積比較では、ライセンス名目だけでなく、データ移行、IF改修、ラベル消耗品、端末予備、夜間切替、出張、翻訳、トレーニング、テスト環境、バージョンアップを同じ枠にそろえます。
効果と回収年数の仮定シナリオ
年間総便益を、入荷・棚卸・ピッキング工数0.72百万THB、廃棄・陳腐化削減0.45百万THB、特急対応・欠品処理削減0.30百万THB、合計1.47百万THBと仮定します。年間運用費0.60百万THBを差し引くと、年間純便益は0.87百万THB、初期費用に対する単純回収は 1.61 ÷ 0.87 = 1.85年 です。これらは観測値でも保証値でもありません。
| 総便益の感度 | 年間総便益（百万THB） | 年間純便益（百万THB） | 単純回収年数 |
|---|---|---|---|
| 仮定の60％ | 0.882 | 0.282 | 5.71年 |
| 仮定の100％ | 1.470 | 0.870 | 1.85年 |
| 仮定の140％ | 2.058 | 1.458 | 1.10年 |
感度が示すのは、楽観値を一つ置くだけでは意思決定できないことです。パイロットでは、基準工数、差異件数、特急処理、廃棄、欠品の定義と測定方法を固定し、効果が60％にとどまる場合にも投資を継続するかを先に決めます。
90日パイロット：小さく始めても証拠は端から端まで通す
0〜30日：範囲とデータを固定する
対象倉庫、品目群、交替、取引を絞り、現状フローと例外を観察します。品目、UOM、場所、ロット、状態、所有者をプロファイルし、重複、欠損、使われていないコードを整理します。RFPの要求IDと、各要求を証明するテストケースを同時に作ります。現状差異を測らずに「精度99％」のような目標を置かないでください。
31〜60日：構築とドライラン
マスター移行、端末、ラベル、ERP連携、権限を設定し、正常系より先に異常系を投入します。二重スキャン、部分入荷、単位換算、ロット分割、品質保留、通信断、ERP停止を、保存した入力データで繰り返します。旧運用と新運用を並行比較し、差異をevent ID単位で説明します。
61〜90日：制御された切替とhypercare
対象範囲を明示して切り替え、影のExcelを禁止する代わりに、未処理例外を即時に見えるキューへ集めます。各交替にsuper userを置き、問題、回避策、根本原因、恒久対応、再テストを一つの台帳で管理します。日次でERP／WMS／現物を照合し、未同期件数と経過時間を確認します。90日目は単に稼働継続を祝う日ではなく、拡張、条件付き継続、停止の判断を証拠で行うgateです。
FAT/SATで実施する具体的な受入テスト
FATは供給側の管理環境で処理の決定性を確認し、SATは実際の端末、ネットワーク、プリンター、ERP、利用者権限、交替勤務で確認します。テスト結果には、入力、期待値、実値、ソフトウェア版、設定版、実行者、時刻、証拠ファイル、差異、再テストを残します。
| テストケース | 入力・操作 | 期待結果の例 |
|---|---|---|
| 重複スキャン | 同じevent IDで同じ箱を2回受入 | 在庫は1回だけ増え、重複として記録 |
| 部分入荷 | PO 100個に対し60個を受入 | 60個計上、残40個はopen、過剰完了しない |
| 単位換算 | 1箱=24個を10箱、途中で換算版を変更 | 取引時点の版で240個、履歴を再現可能 |
| ロット分割・統合 | 100個を60/40へ分割後、容器を統合 | 数量保存、親子・由来を追跡可能 |
| 品質保留 | 受入直後にlotをquarantineへ | 残高は存在するが払出不可、権限外解除を拒否 |
| 負在庫防止 | 利用可能10個に対し12個払出 | 拒否または承認済例外。黙ってマイナスにしない |
| オフライン再同期 | 端末を切断して3件処理し再接続 | 未同期表示、順序・ID保持、各1回だけ反映 |
| 冪等再送 | ERP応答前にtimeoutし同じ要求を再送 | 二重計上せず同じ結果を返す |
| 取消 | 完了済移動を正しい権限で取消 | 元を削除せず、逆イベントと理由を残す |
| 棚卸凍結 | 対象棚を数えている間に移動要求 | 定義済み規則で保留・別計上し、差異を説明 |
| ERP停止 | ERPを30分停止して現場処理を継続 | キュー、件数、順序、復旧、競合が可視化 |
| 権限違反 | 一般作業者が品質解除・在庫調整 | 拒否され、試行ログを残す |
| backup/restore | 設定を含むバックアップから復元 | RTO/RPO内でラベル・IF・権限も復元 |
| 月末照合 | 未送信・遡及・取消を含む期間を締める | WMS・ERP・台帳差異が一覧化され、owner付き |
合否閾値はプロジェクトごとに定めます。例えば「重大テスト100％合格」「重複計上0件」「未説明のERP差異0件」「通常スキャン応答の95パーセンタイル2秒以内」「重大度1の未解決0件」「バックアップ復元を一回成功」などを置けますが、これらは標準や保証値ではなく、あくまで例です。ネットワーク、取引量、安全要件、月末運用に合わせて合意してください。
Go／No-Goを画面の完成度で決めない
Go判断には、次の証拠をまとめます。
- 範囲内の品目・UOM・場所・ロット・状態・所有者マスターが承認済み。
- 重大な正常系・異常系テストが合格し、残課題にownerと期限がある。
- ERP停止、端末オフライン、プリンター故障時の手順が現場で実演済み。
- 未同期、競合、ラベル再発行、在庫訂正を監視する担当が決まっている。
- 交替ごとの利用者が、業務と例外処理を自力で完了できる。
- rollback条件、データの戻し方、判断者、連絡網が定義済み。
- 初日、初週、月末の照合手順と締め責任が決まっている。
逆に、マスター差異を「本番後に直す」、影のExcelを無期限で残す、エラー時に管理者がDBを直接修正する、受入証拠がスクリーンショットだけ、という状態ならNo-Goまたは条件付きGoが妥当です。
導入失敗を招く八つのパターンと予防策
1. マスターデータを移行直前に渡す
品目重複、UOM矛盾、無効場所、ロット規則の欠落は、画面開発より大きな手戻りになります。データownerを決め、30日目までに品質レポートと是正計画を作ります。
2. 影のExcelを安全弁として残す
例外処理がシステムにないと現場はExcelへ戻ります。禁止を宣言するだけでなく、例外キューと迅速な承認経路を用意し、Excelでしか処理できない事例を要求へ戻します。
3. 場所の粒度が曖昧
「倉庫」「ライン」だけでは仮置き、検査待ち、積込中、車両上を説明できません。物が一時的に留まる場所もコード化し、移動責任を定義します。
4. 遡及計上を無制限に許す
event timeとposting timeが違うことはありますが、締め済み期間へ自由に戻すと月末残が変わります。遡及可能期間、承認、会計影響、再照合を定めます。
5. UOMを画面表示だけで変換する
箱、個、kg、mの換算は、包装改定や密度、端数で変わることがあります。取引時の換算版と丸めを保存し、基本単位との整合をテストします。
6. ラベル再発行を通常印刷と同じにする
同じIDを二枚発行すると、二つの現物に貼られる危険があります。再発行理由、承認、旧ラベルの無効化、実物確認を別フローにします。
7. 例外にownerがいない
連携競合、未分類差異、保留品がキューに残っても、担当と期限がなければ蓄積します。種類ごとに一次責任、エスカレーション、SLAを決めます。
8. 過剰カスタマイズ
現在の帳票をそのまま画面化すると、バージョンアップ不能な個別システムになります。法令・顧客・安全上の必須、競争力に直結、単なる慣習を分け、設定と業務変更で吸収できないものだけ開発します。
運用開始後のKPIと統治
在庫精度だけを見ると、調整伝票を増やして見かけ上合わせる誘惑が生まれます。差異金額・件数に加え、未同期イベント、重複排除、未解決競合、ラベル再発行、遡及計上、品質保留滞留、マスターエラー、手動訂正を監視します。
月次レビューでは、各差異を人ではなく原因分類へ割り当てます。プロセス、マスター、端末、ネットワーク、連携、権限、教育に分け、再発防止の変更が別のテストを壊さないよう回帰テストを行います。マスター、IF、ラベル、理由コードを変更したら版を上げ、影響範囲、実施者、承認、rollbackを記録します。
バックアップもDBのコピーで終わりません。構成、API設定、証明書、端末プロファイル、帳票、ラベル、権限、ジョブ、手順書を復元できるかを定期的に試します。復元後に在庫イベントの連続性が維持され、ERPとの最終照合点から再開できることを確認します。
まとめ：在庫管理システム導入は、例外まで含むイベントの契約である
タイ工場の在庫管理システム導入では、製品比較より先に、在庫台帳・現場実行・ERP・会計の責任境界を明確にします。品目、UOM、場所、ロット／シリアル、状態、所有者を統治し、すべての移動を一意なevent ID、二つの時刻、理由、actor、訂正履歴へ結び付けます。RFPは正常機能の一覧ではなく、重複、通信断、ERP停止、棚卸凍結、権限違反、復元、月末照合の証拠を要求する文書にします。
費用はライセンス単価でなく3年TCOと効果感度で比較し、90日パイロットを「小規模な本番デモ」ではなく端から端までの受入試験にします。FATとSATで同じ要求IDを追跡し、例示した閾値を自社条件に置き換えれば、Go／No-Goを印象ではなく証拠で判断できます。
TOMAS TECHでは、製品を決める前の業務範囲整理、イベントデータモデル、RFP、概算TCO、90日パイロット、FAT/SAT受入項目の設計からご相談いただけます。タイ工場で在庫差異の原因が特定できない段階でも、現状確認から進められますので、必要に応じてお問い合わせください。
よくある質問：在庫管理システム導入・費用・比較
在庫管理システム導入前に最初に決めることは何ですか？
会計残高、現場実行、マスターの正本をどのシステムが持つかを決めます。そのうえで、入荷から訂正までのイベント、ERP計上時点、例外キュー、FAT/SATの期待結果を定義します。製品デモはその後です。
在庫管理システムの費用はどのように比較すべきですか？
ライセンスだけでなく、調査、マスター整備、連携、端末、ラベル、ネットワーク、教育、切替、運用、アップグレードを同じ期間のTCOで比較します。本稿の3.41百万THBは仮定シナリオであり、見積や相場ではありません。
在庫管理システム比較ではERPとWMSのどちらを選ぶべきですか？
会計統制と統合を重視し工程が単純ならERP中心が候補になります。多ロケーション、複雑な入出荷、作業最適化が必要ならWMSが候補です。ただし、どちらでも正本境界、現場応答、障害復旧、保守を自社ケースでテストしてください。
在庫差異の主な原因と対策は何ですか？
未計上、二重計上、場所曖昧、UOM換算、ラベル再発行、遡及計上、未同期端末が代表例です。棚卸調整だけで閉じず、元イベントと訂正をリンクし、原因分類ごとの再発を監視します。
バーコードとRFIDはどちらが在庫管理に向いていますか？
対象物、読取距離、環境、処理量、取引先標準、総費用で選びます。RFIDは一括読取に利点がありますが、金属や液体、誤読を実地試験すべきです。バーコードもラベル再発行と本人性を統治しなければ差異を防げません。
オフライン対応では何を受入テストすべきですか？
未同期表示、端末内キュー、event IDの保持、順序、重複排除、競合、ユーザーへの復旧案内を確認します。再接続後に「送れた」だけでなく、ERPまで各取引が一度だけ計上されたことを照合します。
在庫精度の合格値は何％にすべきですか？
業界横断の一つの閾値を本稿では推奨しません。品目重要度、取引量、現状値、測定方法を定義し、重大品と一般品を分けてプロジェクト固有の目標を合意してください。調整後の残高だけでなく、未説明差異を測ります。
90日で本稼働まで完了できますか？
対象を一倉庫・限定品目・限定取引に絞れば、90日でパイロットと拡張判断まで進められる可能性があります。全社展開の期間を保証するものではありません。30日ごとのgateでデータ、異常テスト、現場運用を確認します。
参照した一次・公式情報
- Thailand BOI, 1H 2026 Investment Applications — https://www.boi.go.th/index.php?_module=news&from_page=press_releases2&language=en&page=press_releases_detail&topic_id=139075
- Thailand BOI, Industry 4.0 Transformation Announcement (unofficial English translation) — https://www.boi.go.th/upload/content/15_2565EN.pdf
- Thailand Revenue Department, Revenue Code Sections 65–76 — https://www.rd.go.th/english/37764.html
- IFRS Foundation, IAS 2 Inventories — https://www.ifrs.org/issued-standards/list-of-standards/ias-2-inventories/
- GS1 General Specifications archive — https://ref.gs1.org/standards/genspecs/archive/1000
- GS1 EPCIS overview — https://www.gs1.org/standards/epcis
- GS1 Global Traceability Standard 2.0 — https://ref.gs1.org/standards/global-traceability/2.0.0/
- ISO, Guidance on Documented Information for ISO 9001:2015 — https://www.iso.org/files/live/sites/isoorg/files/standards/docs/en/iso_9001_2015_guidance_documented_information.pdf
