タイ工場で「予備品管理 システム」を検討するとき、単に部品の入出庫を電子化するだけでは十分ではありません。生産設備が止まる可能性、部品が届くまでの日数、代替品の有無、修理して再利用できるか、会計上どう扱うかを一つの判断系としてつなぐ必要があります。本稿では、停止リスクと過剰在庫を同時に抑えるための設計を、設備BOM、保全計画、発注点、ロット・シリアル、返却修理、棚卸、権限、受入テスト、90日PoCまで具体化します。
予備品管理システムで解くべき問題は「在庫金額」だけではない
一般の原材料や製品在庫では、需要予測、納期、欠品率、回転率が重要です。ところがMRO（Maintenance, Repair and Operations）予備品は、需要が間欠的で、故障時に突然必要になり、同じ数量不足でも設備への影響が大きく異なります。安価なヒューズが1個欠けただけで重要設備を復旧できない場合もあれば、高価なモーターを複数台持っていても長年動かない場合もあります。
したがって、部品在庫管理の目的は「数量を合わせること」ではありません。少なくとも次の四つを同時に管理する必要があります。
- 必要な部品を、必要な設備・作業・場所に、必要な時点で供給できること。
- 停止損失と調達リスクに見合わない過剰在庫を持たないこと。
- 互換品、修理品、返却品を含め、使える状態を誤認しないこと。
- 購買、倉庫、保全、製造、財務が同じデータで判断できること。
この四つの間にはトレードオフがあります。保全だけで決めれば「念のため多め」に寄り、財務だけで決めれば「動かない在庫を減らす」に寄ります。システムは片方の意見を自動化するものではなく、費用・リスク・性能を比較できる証拠をつくる基盤です。
ISO 55001:2024の公開解説では、資産管理の意思決定と価値、リスクと機会、データと情報、ライフサイクル、予測的な行動が強調されています。これは個別部品の在庫基準を定めるものではありませんが、予備品を「棚の数量」ではなく「設備サービスを支える資産管理の判断」として扱う考え方に整合します。認証を主張するのではなく、経営判断の筋道を設計する参考にするのが適切です。
まず設備停止リスクと部品重要度を分けて評価する
全品目に同じ在庫ルールを当てると、重要部品の欠品と低重要度部品の過剰在庫が同時に起きます。最初に「設備重要度」と「部品供給リスク」を分け、その組み合わせでサービス水準を決めます。
設備重要度の評価軸
- 人の安全、法令、環境への影響
- ライン停止時間と復旧までの生産損失
- 品質不良やトレーサビリティ欠落への影響
- 他設備や後工程への波及範囲
- 代替設備、手作業、外注など回避策の有無
部品供給リスクの評価軸
- 通常納期と納期ばらつき
- 海外調達、通関、最低発注量、輸送条件
- 単一メーカー、廃番、図面・仕様の属人化
- 現地調達品や互換品へ切り替えられるか
- 故障後に修理可能か、修理ターンアラウンドはどの程度か
- 保存期限、温湿度、劣化、校正など保管制約
たとえば、A/B/Cの設備重要度と、高/中/低の供給リスクを掛け合わせ、A×高のみ経営承認した高サービス区分にします。「高価だから重要」「よく使うから重要」と短絡しないことが大切です。頻度が低くても復旧に不可欠な保険部品があり、頻度が高くても当日調達できる汎用品があります。
重要度マトリクスを在庫ポリシーへ変換する
| 区分 | 代表的な考え方 | 在庫ポリシー例 | 承認者 |
|---|---|---|---|
| クリティカル | 欠品で安全・主要ライン・法令へ重大影響 | 最低保有、専用保管、代替品承認、定期レビュー | 工場長・保全責任者 |
| 重要 | 停止するが回避策または猶予がある | 発注点、リードタイム更新、修理循環 | 保全・購買 |
| 一般 | 影響が限定的で現地調達しやすい | 2ビン、定期補充、VMI候補 | 倉庫・購買 |
| 非在庫 | 都度手配でも許容できる | カタログ・見積・納期情報のみ保持 | 利用部門 |
ここで示す区分名や承認者は設計例です。実際の閾値は工場の安全基準、生産計画、調達条件、財務方針で承認してください。システムには評価点だけでなく、根拠、承認日、次回見直し日を保存します。点数が同じでも理由が違えば、将来の変更判断が変わるからです。
設備BOMを「保全で使える部品表」にする
予備品管理が崩れる典型は、品目マスターと設備台帳が別々に存在し、どの部品がどの設備に使えるか分からない状態です。SAPの公開ヘルプが示すmaintenance BOMの考え方でも、保全対象と、その保全に必要な部品を構造として結び付けます。導入製品にかかわらず、この関係を管理できることが出発点です。
設備BOMに必要な関係
- 工場→エリア→ライン→設備→ユニット→部品の設置階層
- メーカー品番、社内品目番号、旧品番、新品番
- 1台当たり標準使用数と取付位置
- 設備型式、製造番号レンジ、設計変更レベルへの適合
- 主部品、承認代替品、暫定代替品の関係
- 必須工具、校正、作業標準、安全手順へのリンク
- 交換周期、状態監視項目、故障モードとの関係
単純な「設備AにベアリングBを使う」だけでは、設計変更後の設備に旧仕様品を誤使用する危険があります。適用開始日・終了日、設備シリアル範囲、承認者を持たせ、変更管理と結び付けます。保全作業指図から部品を予約するときは、その設備BOMの有効版を参照できるようにします。
同一品の重複コードを統合する手順
現場では、メーカー品番の空白、ハイフン、大文字小文字、タイ語・英語表記、代理店独自番号の違いで同一部品が複数登録されがちです。いきなり削除統合せず、正規化キーをつくり、候補を照合し、保全と購買が現物・仕様書を確認したうえで代表コードと別名を決めます。
統合前には、未処理発注、予約、修理依頼、棚在庫、会計残高への影響を確認します。旧コードは検索別名として残し、新規取引を停止します。「マスターをきれいにする」作業と「履歴を壊さない」作業を分けることが重要です。
部品在庫管理では数量を状態別に分ける
帳簿上10個あっても、10個すべてが今すぐ使えるとは限りません。Oracleのフィールドサービス部品管理の公開説明では、on-hand、available、reservedを分け、excess/shortageも表示する考え方が示されています。製品固有の機能名をそのまま要件にする必要はありませんが、状態別の数量を区別する設計は有効です。
最低限、次の状態を混同しないようにします。
| 数量・状態 | 意味 | 発注判断への扱い |
|---|---|---|
| 現物数量 | 保管場所に物理的に存在 | そのまま利用可能とは限らない |
| 利用可能 | 品質・期限・所有・予約を考慮し払出可能 | 供給可能量に含める |
| 予約済み | 作業指図や設備停止対応へ引当済み | 他需要には使えない |
| 検査中 | 入荷検査、校正、品質判定待ち | 合格まで利用可能にしない |
| 修理中 | 外部または内部修理へ移動 | 返却予定を別管理 |
| 不適合・隔離 | 故障、期限切れ、仕様疑義 | 発注点計算から除外 |
| 輸送中・発注残 | 注文済みだが未入荷 | 納期確度に応じて考慮 |
在庫ポジションの基本形は、例として「利用可能＋確度の高い発注残＋修理返却予定－予約－未処理需要」です。ただし修理返却が遅れがちな工場で、予定を100%供給扱いにすると欠品を見逃します。予定日の信頼度やベンダー実績に応じ、計算へ含める条件を決めます。
より広い在庫システムの導入論点はタイ工場向け在庫管理システム導入ガイドを、入出庫時の現場入力やバーコード運用はハンディターミナル導入ガイドも参照してください。
発注点管理システムは「平均使用量×日数」だけで決めない
発注点は一般に、リードタイム中の需要と安全在庫で考えます。しかし予備品の需要はゼロが続いた後に突然1個発生するため、月平均だけでは停止リスクを表しにくい品目があります。SAPのMRO計画に関する公開ヘルプも、安全在庫やreorder pointを扱いますが、実際の値は各社がデータとリスクに基づいて設定すべきです。
品目ごとに補充方式を選ぶ
- 発注点方式：消費が比較的安定し、納期も把握できる消耗品。
- min-max方式：定期レビューや補充便に合わせ、上限まで補う品目。
- 2ビン方式：現場近接で使う低単価・高頻度品。空ビンが補充信号になる。
- 保険予備品方式：需要頻度より設備停止影響を重視し、最低1個などを経営判断する品目。
- 非在庫・都度調達：代替手段があり、納期を許容できる品目。
- 修理循環方式：新品購入だけでなく、故障品→修理→良品棚の循環数を管理する品目。
サービスパーツ計画では、需要、供給、在庫目標をネットワーク全体で見る必要があります。中央倉庫、工場倉庫、ラインサイド、技術員の工具箱が分かれている場合、工場ごとに余剰と欠品が同時発生しないよう、移送可能性と移送時間を含めます。
発注点の説明用計算例
以下は市場標準や推奨値ではなく、計算方法を確認するための架空例です。
- 対象：定期交換にも突発故障にも使うセンサー
- 見直し後の計画需要：90日で12個
- 調達リードタイム：45日
- リードタイム中の計画需要：12×45÷90＝6個
- 工場が承認した安全在庫：3個
- 発注点：6＋3＝9個
- 現在の利用可能数：7個
- 予約済み：2個
- 確度の高い発注残：1個
- 在庫ポジション：7＋1－2＝6個
- 発注点との差：9－6＝3個
- 発注ロット：4個単位
- システム提案：4個を発注
この例では、現物数量7個だけを見ると安心しやすい一方、予約を引くと在庫ポジションは6個です。提案数量は不足3個をそのまま発注せず、発注ロット4個に切り上げます。実運用では、未処理保全計画、キャンセル可能な予約、入荷遅延、同一ラインの共通故障、最小発注量、保管期限を追加で検討します。
重要なのは、発注点の数値と「なぜその数値か」を同時に持つことです。需要期間、リードタイムの取得日、安全在庫の承認根拠、見直し日を保存し、例外変更には理由を必須にします。欠品防止システムについてはタイ工場の欠品防止システム設計でも詳しく説明しています。
代替品管理は互換表ではなく、条件付き承認として設計する
「代替可」のフラグ一つでは危険です。機械的に取り付くこと、電気仕様が合うこと、制御プログラムが対応すること、品質保証上使えることは別問題です。代替関係には方向性もあります。BはAを置き換えられても、AがBを置き換えられるとは限りません。
代替品レコードには、次を持たせます。
- 元品目と代替品目
- 双方向か一方向か
- 適用設備、設備型式、シリアル範囲
- 追加加工、アダプター、配線、パラメータ変更の要否
- 品質・安全・顧客承認の条件
- 暫定か恒久か、有効期限
- 技術承認者、承認文書、検証結果
- 代替使用後に元へ戻す必要があるか
欠品アラート時に代替候補を表示するだけでなく、対象設備と作業条件に対して有効な候補だけを絞り込みます。暫定代替品を使った設備はフォローアップ作業を自動起票し、恒久対応が終わるまで追跡します。
ロット・シリアル管理は追跡粒度を品目別に決める
すべてをシリアル管理すると現場負荷が上がり、何も追跡しないと不具合範囲を特定できません。品目の価値、修理性、安全性、保証、校正、品質影響に応じて粒度を選びます。
ロット管理が向く例
- 潤滑剤、接着剤、薬品、シール材など使用期限があるもの
- 同一製造ロットで品質影響を評価したいもの
- 先入先出や期限先出を徹底したいもの
シリアル管理が向く例
- サーボドライブ、PLC、測定器、モーターなど個体履歴が重要なもの
- 修理回数、保証、校正、ファームウェア版を追うもの
- 高額で、貸出・返却・設備間移動を追うもの
払出時には「誰が」「いつ」「どの作業指図で」「どの設備へ」「どのロット・シリアルを」使ったかを記録します。返品時は未使用返却か、故障返却か、誤払出かを分けます。現場で入力を成立させるには、バーコードやQRコードを使い、設備・棚・作業指図・部品の四点をスキャンする設計が有効です。
返却修理プロセスを新品購買と別に可視化する
修理可能品では、故障品が倉庫へ戻らず現場に放置されると、新品を余計に買うことになります。返却修理は次の状態遷移で追跡します。
- 設備から取り外し、故障症状と設備・作業指図を記録する。
- 故障品を隔離場所へ返却し、良品在庫へ混ぜない。
- 修理可否、保証対象、見積上限、廃棄承認を判定する。
- 外部修理なら発送日、受領確認、見積、予定返却日を追う。
- 返却後に検査・試運転・校正を行い、合格後だけ利用可能へ戻す。
- 修理費、故障モード、再発期間を個体履歴へ記録する。
修理待ち数量と良品数量を混ぜず、修理ターンアラウンドと修理成功率を記録します。ただし、過去実績から未来を断定してはいけません。修理ベンダー変更、廃番、部材不足で条件は変わるため、最終確認日と確度を表示します。
一定回数以上の再故障、修理累計費が承認基準を超えた個体は、継続修理・更新・廃棄をレビューします。基準額や回数は企業ごとに異なるので、システムに固定値を埋め込まず、権限付き設定として管理します。
棚卸は年1回の数量合わせから、日常の精度管理へ変える
予備品は動きが少ないため、誤差が長く発見されないことがあります。年次一斉棚卸だけでなく、重要度と差異履歴に応じた循環棚卸を組み合わせます。
循環棚卸の設計要件
- クリティカル品、差異頻発品、高額品、期限管理品を優先する
- 棚卸対象の帳簿数量を数える担当者へ隠すブラインドカウント
- 一次カウントと再カウントを別担当にする
- 差異理由を、未登録払出、棚違い、単位違い、破損、マスター誤りなどで分類する
- 在庫調整には承認を必要とし、元取引を修正すべき場合は調整で隠さない
- 棚卸中の入出庫を止めるか、時刻順に整合できるよう制御する
精度KPIは単純な「一致行数」だけでなく、重要品の差異、数量差、金額差、再発原因を分けます。小さなボルトの差異100件と、唯一の保険予備品1件の紛失は意味が違います。
権限と監査証跡をRFPの中心要件に置く
在庫システムでは、入力できることより、誰が何を変更でき、後から説明できることが重要です。職務分掌を考慮し、少なくとも次を分離します。
- 品目マスター作成と承認
- 代替品の技術承認
- 発注点・安全在庫の変更と承認
- 購買依頼、発注承認、検収
- 受入、検査、利用可能化
- 払出、返却、在庫調整
- 修理発注、廃棄判定、廃棄承認
緊急時には例外払出を許す必要があります。そこで例外を禁止するのではなく、理由、設備、作業指図、承認者、事後確認期限を必須にします。共有IDでは監査できないため、個人IDを基本とし、端末共用時も利用者を識別します。
変更履歴には、変更前、変更後、日時、操作者、承認者、理由を残します。ログの閲覧権限と保存期間も要件化します。バックデート、マイナス在庫、棚間移動の未完了、取消処理のルールを受入テストで確認します。
会計上の分類をシステム用語だけで決めない
IAS 16の第8項では、予備品、予備設備、保守用設備は、有形固定資産の定義を満たす場合にIAS 16に従って認識し、それ以外は棚卸資産として分類するという原則が示されています。つまり「予備品」という名称だけで全て同じ会計区分になるわけではありません。
会計方針の判断は財務・監査人が行うべきで、在庫管理プロジェクトが独自に決めてはいけません。システム側では、運用上の保管場所・利用可能状態と、財務上の資産区分・評価・減損や廃棄の扱いを混同せず、必要な連携キーを持たせます。
たとえば、保険予備品を長期間保有する運用判断と、その品目を会計上どう認識・償却するかは関連しますが同じ判断ではありません。RFPでは「会計基準に自動適合」という曖昧な文言を避け、企業の承認済み会計方針をどのデータと仕訳連携で支えるかを確認します。
予備品管理システムのRFPに入れるべき要件
RFPでは画面一覧より、業務シナリオと判定条件を示す方が比較しやすくなります。
機能要件
| 領域 | 必須確認事項 |
|---|---|
| マスター | 多言語名称、別名、メーカー品番、単位、ロット・シリアル、期限、保管条件 |
| 設備連携 | 設備BOM、設計変更、有効期間、作業指図、保全計画、故障モード |
| 在庫 | 倉庫・棚・ラインサイド、利用可能・予約・検査・隔離・修理中、移送中 |
| 補充 | 発注点、min-max、2ビン、保険予備品、修理循環、例外承認 |
| 代替 | 方向性、適用設備、技術条件、暫定期限、承認文書 |
| 修理 | 個体履歴、修理依頼、見積、納期、検査、保証、廃棄 |
| 棚卸 | 循環棚卸、ブラインドカウント、再カウント、差異承認、原因分析 |
| 分析 | 欠品、余剰、長期不動、納期精度、修理日数、サービス水準、例外履歴 |
非機能・導入要件
- タイ語・英語・日本語表示と、Unicodeを含む検索・CSV入出力
- 工場内Wi-Fiが不安定な場所でのオフラインまたは再送制御
- バーコード/QR、ラベルプリンター、ハンディ端末との接続
- ERP購買・会計、CMMS/EAM、MES、ID基盤とのAPI・バッチ連携
- 権限、監査ログ、バックアップ、復旧、データ保持
- 取引量、同時接続、応答時間、月末・棚卸ピーク時の性能
- テスト環境、移行リハーサル、教育、タイ現地サポート、障害窓口
「標準機能で対応」の回答には、設定画面、制約、追加費用、アップグレード影響を確認します。「カスタマイズ可能」も同様に、誰が保守し、次版でどう検証するかを問います。デモでは正常系だけでなく、誤った単位、重複スキャン、期限切れ、予約競合、通信断、返品、取消まで実行してもらいます。
受入テストは実際の停止対応を再現する
要件定義の文章だけでは、現場で使えるか判断できません。受入テストは代表的な部品と設備、実在に近い作業指図を使ってエンドツーエンドで実施します。
受入テストの代表シナリオ
- 設備故障を登録し、設備BOMから適合部品と代替品を検索する。
- 利用可能2個、予約1個、検査中1個のとき、別作業へ何個払出可能か確認する。
- クリティカル品が発注点を下回り、発注ロットと承認経路を含む提案が出る。
- 旧設備には使えるが新設備には使えない代替品が正しく除外される。
- シリアル品を故障設備へ払い出し、取り外し品を修理中へ移す。
- 修理返却品を検査不合格にし、利用可能数量へ戻らないことを確認する。
- 棚卸差異を一般利用者が自己承認できないことを確認する。
- 通信断中のスキャンを再送し、二重取引が作られないことを確認する。
- マスターの安全在庫変更が履歴と承認者を残すことを確認する。
- ERP側の発注取消・入荷訂正が在庫ポジションへ正しく反映されることを確認する。
合否は「画面が表示された」ではなく、期待する数量、状態、権限、仕訳連携、監査ログまで定義します。重大度別に欠陥を分類し、稼働判定条件と暫定回避策の承認者を事前に決めます。
90日PoCでシステムと運用を同時に検証する
PoCは機能紹介ではなく、導入仮説を限定範囲で検証する場です。全工場・全品目を対象にせず、停止影響があり、現場協力を得られ、過去データを確認できる一つのラインまたは設備群を選びます。
Day 0〜30：基準とデータをつくる
- 対象設備、対象品目、保管場所、役割、成功条件を確定する
- 重複コード、単位、設備BOM、在庫状態、未処理発注を棚卸する
- クリティカル判定と承認根拠をレビューする
- バーコード、端末、ネットワーク、ERP/CMMS連携を接続する
- 現物と帳簿の初期差異を記録し、開始後の改善と混ぜない
30日ゲートでは、設備BOMの対象範囲、初期在庫精度、主要マスター欠落、ユーザー権限、連携エラーを確認します。初期値が不明なKPIは改善率を主張せず、まず測定可能になったことを成果とします。
Day 31〜60：実取引と例外を通す
- 計画交換、突発故障、通常入荷、緊急払出、返却、修理を実行する
- 発注点提案と人の判断差を記録する
- 予約競合、代替品、検査不合格、通信断などの例外を試す
- 入力所要時間、未処理取引、差異原因、アラート対応時間を確認する
- タイ語・英語の教育資料とシフト引継ぎを改善する
60日ゲートでは、システムが正しいだけでなく、現場が日常業務で使い続けられるかを判断します。入力を後回しにしてExcelへ戻るなら、UI、端末配置、役割、承認段階を見直します。
Day 61〜90：補充基準と展開判断を確定する
- 実績からリードタイム、予約、修理返却、発注点の前提をレビューする
- 欠品・余剰・長期不動候補を部品重要度と合わせて検討する
- 権限監査、バックアップ復旧、月末処理、棚卸を検証する
- 本番移行対象、データ責任者、教育、サポート、改善バックログを決める
- 継続、修正して継続、範囲縮小、停止の判断資料を作る
90日で必ず在庫金額が下がる、欠品がゼロになる、と約束してはいけません。低頻度故障では90日間に需要が発生しないこともあります。PoCで確認すべきは、判断に必要なデータが取れるか、重要品を守る統制が機能するか、現場負荷を許容できるか、展開費用とリスクを説明できるかです。
PoCスコアカード例
| 観点 | 基準値 | 90日判定の例 | 注意 |
|---|---|---|---|
| 設備BOM | 対象品の適合関係を確認 | 未確認関係を責任者付きで解消 | 正確性をサンプル監査 |
| 在庫精度 | 開始時に現物照合 | 重要品差異を原因別に管理 | 単純な行一致率だけにしない |
| 処理定着 | 手書き・Excel併用を記録 | 未処理取引が所定期限内 | シフト別に確認 |
| 補充判断 | 現行ルールを保存 | 提案理由を説明・承認可能 | 欠品ゼロを短期保証しない |
| 修理循環 | 修理中個体を初期把握 | 状態・予定日・結果が追跡可能 | ベンダー確度を分ける |
| 統制 | 権限と例外を初期確認 | 重大な職務分掌違反が未解決でない | 例外ログを監査 |
これらは説明用の判定例であり、普遍的な閾値ではありません。RFPまたはPoC計画書には、測定式、データ源、責任者、判定日、例外承認を記載します。
導入で起こりやすい失敗と回避策
「まず全品目を移行する」で止まる
汚れたマスターを全件完全化しようとすると、利用開始が遅れます。重要設備とクリティカル品から範囲を切り、未確認データには未確認フラグと責任者を付けます。ただし会計残高や安全関連を曖昧なまま移行してよいという意味ではありません。
発注点を一括計算して固定する
需要特性、設備影響、修理可能性が違うのに同じ式を使うと誤差が増えます。方式を品目別に選び、例外をレビューします。リードタイムは注文日から入荷日までの実績を定期更新し、異常値の扱いを決めます。
現場の払出入力が翌日になる
在庫表示が実態より多くなり、重複予約や緊急購買につながります。入力項目を絞り、作業指図とスキャンを連携し、端末とラベルを作業場所へ置きます。未処理時間を見える化し、責めるのではなく原因を改善します。
修理品を棚在庫へ戻してしまう
検査前の修理返却品や故障返却品を利用可能にすると、再停止を招きます。物理隔離、状態ラベル、システム状態、品質判定を一致させます。
過剰在庫削減だけをKPIにする
金額削減を急ぐと、低頻度の重要品が削減対象になりがちです。長期不動候補は、設備の現役状況、共通使用、代替品、納期、修理、売却・移送可能性を確認してから処置します。
FAQ：予備品管理システムの導入判断
予備品管理システムとは何ですか？
保全部品の品目、設備BOM、在庫状態、予約、補充、修理、代替品、ロット・シリアル、棚卸をつなぎ、設備停止リスクと保有コストを判断する仕組みです。単なる倉庫数量表ではなく、CMMS/EAMやERPと連携して保全作業と購買・会計を結ぶことが重要です。
メンテナンス部品の在庫管理はExcelでもできますか？
対象が少なく、利用者と拠点が限定され、更新責任者が明確ならExcelで基準を整えることはできます。ただし同時更新、予約、個体履歴、権限、監査、設備BOM、複数倉庫のリアルタイム連携が必要になると限界が出ます。PoC前のデータ整備にはExcelを使い、本番の正本をどこに置くかを明確にしてください。
欠品防止システムなら欠品をゼロにできますか？
ゼロを保証するものではありません。突発需要、供給停止、通関、災害、品質問題は残ります。重要度、代替、発注点、安全在庫、修理、拠点間移送、例外アラートを組み合わせ、許容できない停止リスクを優先的に下げます。
発注点管理システムの値は誰が決めますか？
システムが候補を計算しても、保全、購買、製造、財務が根拠を確認し、権限に従って承認すべきです。需要実績だけでなく、設備影響、納期ばらつき、代替、修理、保管期限を見ます。変更日と理由を保存し、定期レビューします。
予備品管理システムとERP、CMMS/EAMの違いは何ですか？
ERPは購買・在庫・会計、CMMS/EAMは設備・保全計画・作業指図を中心に持つことが一般的です。製品構成によって予備品機能の範囲は異なります。新システムを増やす前に、既存製品の機能、マスター正本、連携責任、現場UIの不足を確認してください。
タイ工場の90日PoCでは何を対象にすべきですか？
停止影響があり、部品・設備・取引履歴を確認でき、現場責任者が参加できる一つのラインまたは設備群が適します。すべての品目を広く浅く試すより、入荷から払出、故障返却、修理、補充判断、棚卸まで一巡できる範囲を選びます。
まとめ：予備品を「数量」から「復旧能力」へ変える
予備品管理システムの価値は、在庫リストをデジタル化することではありません。設備BOMで部品と設備を結び、重要度と供給リスクでポリシーを分け、利用可能・予約・検査・修理を区別し、発注点と代替品の根拠を説明できるようにすることです。ロット・シリアル、返却修理、循環棚卸、権限、監査証跡まで通して初めて、停止リスクと過剰在庫を同じ会議で判断できます。RFPでは業務シナリオを示し、受入テストでは数量・状態・権限・連携を検証し、90日PoCでは効果を誇張せず、測れる仕組みと運用定着を確認してください。
TOMAS TECHでは、タイ工場の設備・倉庫・購買・保全の現状整理から、設備BOM、補充ルール、バーコード運用、ERP/CMMS連携、受入テストまで検討段階からご相談いただけます。製品選定前に対象範囲とPoCの判定基準を整理したい場合は、お問い合わせください。
参考情報
- ISO/TC 251, ISO 55001:2024 key changes: https://committee.iso.org/sites/tc251/home/projects/published/iso-55001.html
- ISO, ISO 55001:2024 overview: https://www.iso.org/standard/83054.html
- IFRS Foundation, IAS 16 Property, Plant and Equipment: https://www.ifrs.org/content/dam/ifrs/publications/pdf-standards/english/2022/issued/part-a/ias-16-property-plant-and-equipment.pdf
- SAP Help, Maintenance BOM: https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e72f747389b340229f7fa343975bfa57/9d71b65334e6b54ce10000000a174cb4.html
- SAP Help, Service Parts Planning: https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/677f0a4e71d7487ebb70683014761789/47e12f019e014ac5e10000000a42189d.html
- SAP Help, MRO planning: https://help.sap.com/docs/SAP_INTEGRATED_BUSINESS_PLANNING/feae3cea3cc549aaa9d9de7d363a83e6/89ba7acf063047cea5b37702adfa300b.html
- IBM, What is spare parts management?: https://www.ibm.com/think/topics/spare-parts-management
- IBM Maximo, Inventory module: https://www.ibm.com/docs/en/max-it/cd.0.0_cd?topic=applications-inventory-module
- Oracle, Overview of Managing Field Service Parts: https://docs.oracle.com/en/cloud/saas/service-logistics/26a/fasul/overview-of-managing-field-service-parts.html
- Thailand BOI, Thailand FastPass press release, 23 June 2026: https://www.boi.go.th/upload/content/PR95_2569EN.pdf
※本稿は一般的なシステム設計の情報であり、会計・法務・安全上の助言ではありません。規格適合、会計処理、法令対応、安全在庫水準は、適用条件と社内方針を確認し、各分野の責任者・専門家が判断してください。数値例は説明用の架空例であり、市場相場、顧客実績、効果保証ではありません。
