製造業で保全予備品需要予測AIの導入を検討するとき、最初に決めるべきことはモデル名ではありません。どの設備・品番・倉庫について、何週間先の不足を、誰が判断できるようにするかです。部品の払出履歴だけを学習させると、欠品中に満たせなかった需要や、廃番で後継品へ移った需要を見落とします。本稿はタイ工場の保全・購買・生産管理・IT担当が、予備品需要予測AIのRFPから実証、FAT/SAT、運用までを同じ物差しで判断するための実務ガイドです。
製造業の保全予備品需要予測AIで、何を予測するのか
「来月はベアリングが何個必要か」という問いだけでは仕様になりません。設備Aに適合するベアリングPを、倉庫Bから、仕入先の納期内に、予定保全と突発故障の双方へ供給できるか、という意思決定まで定義する必要があります。モデルの出力は単一の平均値ではなく、対象品番・拠点・予測期間、需要発生確率、需要量の分布、前提となった作業計画、データ鮮度、モデル版をひと組にした提案とします。最終的な発注量は、供給リードタイム、代替品、在庫引当、安全上の重要度、予算と合わせて人が承認します。
本稿の焦点は予測モデルの調達と検収です。予備品のABC分類や発注点の基本を確認したい場合は、保全予備品の在庫管理ガイドを先に参照してください。設備異常の兆候から保全時期を推定する話は予知保全の導入事例で扱っています。ここでは故障の検出精度そのものを売り文句にせず、承認済み作業指示と実績、設備の設置台数、交換周期、購買制約を使い、部品をいつ何個用意する判断を改善できるかを問います。
予測単位を粗くしすぎない、細かくしすぎない
全工場合計の月間需要だけを予測すると、別倉庫に在庫があっても現場へ間に合わない問題を隠します。一方、設備一台×品番×日で履歴がほぼゼロなら、AIが学習できる規則性はありません。実務では「品番または代替品群×倉庫×週」を主単位とし、重要設備について設備群や作業種類まで分解する案を比較します。どの粒度を採るかは、欠品回避に必要な意思決定時間と実際の取引件数で決めます。品番横断で情報を借りる階層モデルを使う場合も、同一とみなす技術的根拠を記録します。
需要予測と在庫最適化の境界
需要予測は「その期間にどの程度の部品需要が発生しそうか」を推定します。在庫最適化は、その分布と供給条件を受けて「いつ、何個発注するか」を決めます。混ぜて一つの『AI推奨発注数』だけ表示すると、予測誤差、納期遅延、在庫方針のどれが判断を変えたか追えません。RFPでは予測値と発注提案を別画面または別データ項目として取り出せるよう要求します。AIが発注を自動確定する設計は初期段階に含めず、購買担当の承認を経たERP処理に限定します。
なぜ払出履歴をそのままAIに入れると誤るのか
予備品の需要は、製品販売とは異なり、数か月ゼロの後に一度だけ複数個が出ることがあります。MicrosoftはCroston法の説明で、ゼロ需要期間の多い系列では一般的な予測法が過剰在庫または重要部品の欠品につながりうると解説しています。IBMの製品資料も、保全品の間欠的・変動的な需要を対象としていると説明します。ただし、メーカーが機能を提供していることは、特定工場でAIが単純な基準法を上回る証明ではありません。導入判断は自社データでの時間順検証と、在庫・欠品への影響で行います。
払出件数を需要そのものと扱えない代表例は欠品です。倉庫が空の週に保全担当が部品を要求し、緊急購入、他拠点からの融通、作業延期で対応した場合、その要求は通常の払出には残らない可能性があります。払出ゼロを「需要ゼロ」と学習すると、次回も低く予測する悪循環になります。RFPで必ず、欠品日、未充足の保全要求、緊急調達、他拠点移送、作業延期を結び付ける方法を求めます。記録が無い期間は真の需要を断定せず、欠損・打切り観測として扱い、検証対象からの除外または感度分析を明記します。
次に、品番の継承です。旧品番Pが後継品Qへ切り替わった日からPの払出がゼロになっても、設備に必要な機能は消えていません。互換性が片方向か双方向か、ロットや図面改訂で適合が変わるかを、エンジニアリングの承認付きマスタで管理します。単に名称が似ている部品を自動統合すれば、安全上不適合な代替を推奨しかねません。予測系列の結合と、実際に使ってよい代替品の判断は別の承認にします。
さらに、作業計画による需要と突発需要を分けます。承認済みの年次交換作業で来月必要なシールキットは、履歴だけから偶然予測させるより、CMMSの作業指示・部品表を既知需要として入力する方が説明しやすくなります。Microsoft Dynamics 365の資料では保全計画から作業指示を作成でき、IBM Maximoでは作業指示に材料・工具・作業情報を含められます。こうしたシステム上の予定と、突発故障に伴う需要の残差を切り分けることが、予測プロジェクトの中核です。予定作業が延期・中止・再承認された場合に予測を再計算する時点も定義します。
予備品需要データの最低限の照合表
| データ | 主な取得元 | 見落とすと起こる誤り | 検収時の確認 |
|---|---|---|---|
| 払出・返品・棚卸修正 | ERP／倉庫管理 | 返品や移送を新規需要と誤認 | 取引種別と元伝票を追跡 |
| 作業指示・予定部品 | CMMS／EAM | 確定した交換予定を見落とす | 承認状態と変更履歴を確認 |
| 設備・BOM・互換品 | 設備台帳／技術部 | 廃番後の需要消失、誤代替 | 版・適用設備・承認者を確認 |
| 欠品・未充足要求 | 倉庫／保全窓口 | 観測不能な需要をゼロと学習 | 欠品期間と代替対応を確認 |
| 発注・入荷・納期 | ERP／仕入先 | 実納期のばらつきを無視 | 約束日と実入荷日の差を確認 |
| 稼働台数・保全停止 | MES／設備台帳 | 設備増設・休止の影響を無視 | 変更日を時系列で保持 |
この表を「データがある／ない」のチェックリストだけで終えず、時刻、単位、識別子を揃えます。タイ工場では現地時刻と海外本社のUTC記録が混在しがちです。需要が発生した日時、作業指示が承認された日時、仕入先が納期を回答した日時を別々に保持し、評価時点でその時に本当に見えていた情報だけを使います。将来の実績を過去の予測に混ぜるデータ漏洩は、試験では高精度に見え、本番で再現できません。
AI方式を比較する前にベースラインを固定する
「AI導入」の提案に機械学習だけを出させないでください。最低でも、現行の発注判断、単純移動平均、間欠需要向けのCroston系またはTSB系、予定作業を加えたルール方式と比較します。Croston、SBA、TSBなどは万能ではありません。MicrosoftのCroston機能はプレビューとして説明されており、採用する場合は利用条件と製品版も確認が必要です。学術研究も手法の選択がデータ特性に依存することを示しています。採用理由は「AIだから」ではなく、同じデータ、同じ情報時点、同じ制約で比較した結果で説明します。
候補の一つは二段階モデルです。第1段階で期間中に需要が起こる確率、第2段階で起こった場合の数量を推定します。設備台数、稼働負荷、承認済み保全作業、過去故障、季節的な停止窓などを特徴量にできます。ただし、データの件数が少ない品番は複雑なモデルほど不安定です。その場合は品番群の情報を共有する階層モデル、専門家の上書き、単純法の継続を候補にします。個別品番で予測値を出せることと、その予測が信頼できることを混同しないよう、データ量不足の印を表示します。
別の候補は、需要分布を直接推定する確率予測です。発注判断には平均需要だけでなく、納期中に必要数が閾値を超える確率が必要です。予測区間が狭すぎれば重要品で欠品し、広すぎれば過剰在庫になり得ます。したがって「80%区間」と表示するなら、過去の同様のケースで実際に約8割が収まるかという校正を検証します。ここでの8割は検証の考え方を示す例であり、どの工場にも適した目標値という意味ではありません。
時系列バックテストをRFPの必須条件にする
ランダムに行を分ける検証は、保全予備品では危険です。未来に登録されたBOM、後継品、仕入先の納期、予防保全計画が学習側に流れ込むと、見かけ上の精度が上がります。評価は「ある週の月曜朝に実行したなら何を知っていたか」を再現するローリング時系列で行います。例えば過去の複数時点を起点にし、その時点までの情報だけで次の調達リードタイム分を予測します。具体的な期間・起点数は履歴の長さと調達周期から決め、提案書に固定します。
訓練、モデル選択、最終評価の期間を分けます。パラメータを何度も調整した評価期間は、すでに独立な試験ではありません。設備更新や大規模保全で需要構造が変わった時期を一つ含め、通常時と変更時の両方を見ます。新品番や新設備の履歴が無いケースは別群として報告します。全品番平均だけを出すと、高額・重要・超低頻度の品番で何が起こったか見えません。品番群、設備重要度、リードタイム、倉庫、需要頻度別の内訳を提出させます。
誤差指標を一つにしない
MAEなどの数量誤差は参考になりますが、ゼロが多い系列では「常にゼロ」と予測する方法が有利に見えることがあります。品番別に、需要発生の識別、数量誤差、確率の校正、そして発注方針に通した後の欠品・緊急購入・在庫価値を併記します。MAPEは実需がゼロの期間で定義できないため、主指標にしません。比較法ごとに同じ在庫初期値、補充制約、リードタイム分布、サービス目標を使うことが必須です。予測法だけ違うつもりが、発注ルールや安全在庫も変わっていれば公平な比較になりません。
評価の単位は「予測値」よりも「採否判断」です。重要設備の停止を避けるために部品を残す価値と、不動在庫になる費用を比べます。ただし停止損失額や安全影響を勝手に金額換算して一つのスコアに押し込まないでください。保全責任者が絶対に守る部品、代替可能で待てる部品、廃番リスクの高い部品を分け、各群の受入条件を事前に決めます。事後的に有利な指標だけ選ぶことを避けるため、FAT前に試験設計と合格条件を固定します。
仮想的な判定例
以下は試算手順を説明する仮想例であり、TOMAS TECHまたは顧客工場の実績ではありません。候補Aは100品番の平均数量誤差を10%改善したが、重要品20品番の欠品回数を増やした。候補Bは平均誤差の改善が小さくても、重要品の欠品を増やさず、発注提案の変更理由を説明できた。この条件なら平均誤差だけでAを採用しません。設計時に決めた重要品の受入ゲートを優先します。「改善率」は入力条件を変えると変わるため、ベンダーの一般的な宣伝数値を自工場の投資回収に転用しないでください。
設備・品番・倉庫を結ぶデータ設計
実装では、ERP品目マスタ、CMMS部品表、設備台帳、倉庫、仕入先、発注書、作業指示を一つの分析用モデルへ写します。統合キーは製品名の文字列一致では足りません。会社・拠点・倉庫ごとの品番、メーカー品番、単位、換算比、図面版、設備適合、有効日を保持します。複数拠点で同じ部品名でも仕様が違うケースを想定し、統合できなかった行は例外一覧として出します。件数だけでなく、対象金額や重要設備への影響も見るべきです。
予約在庫と実在庫も区別します。棚に5個見えても、別の承認済み作業へ4個引き当てられ、検査待ちが1個なら利用可能数はゼロです。修理して再使用する部品は、取外し日、修理先、合格予定日、合格実績まで追い、単純な購入品と同じ扱いにしません。返品や倉庫間移送は、需要発生と物理的な移動を区別します。これらを曖昧にしたままモデルを高度化しても、発注提案は説明不能になります。
データの時間軸は少なくとも二つあります。取引が実際に発生した日時と、システムに登録され利用可能になった日時です。数日遅れて入力される保全記録を、過去の予測時点ですでに存在したことにしてはいけません。RFPでは各入力の更新頻度、遅延の最大値、欠測時の動作、時差の扱い、再計算トリガー、訂正履歴を要求します。タイ工場の現地時刻で週を切る場合、海外サーバーのUTC日付と週境界がずれないこともSATで確かめます。
予備品需要予測AIの発注判断は人が確定する
推奨発注数は、予測分布と在庫方針の結果です。画面には現在庫、引当、未入荷発注、承認済み作業、需要発生確率、供給リードタイム、代替品候補、推奨理由を同時に表示します。保全は設備影響と代替可否を、購買は仕入先・価格・納期を、生産管理は停止窓を確認します。誰かが数量を上書きした場合は理由と承認者を記録します。上書き理由は次回のデータ改善につながる一方、無断でそのまま学習ラベルにするのは危険です。例外的な発注と実需を区別します。
AIがERPへ書き込む権限は段階的に付与します。最初は読取と提案書出力に限定し、次に人が承認した購買依頼案の作成へ進みます。発注書の確定や仕入先への送信は購買の通常承認経路を使います。提案が古くなった場合、例えば作業が延期され、別倉庫からの移送が確定し、品番が廃番になった場合は承認を失効させます。工場AIエージェントのOT権限と受入設計で述べるように、業務APIの権限、監査、停止手段をモデル外で定義します。ただし本件は設備制御ではなく、購買・保全システムの意思決定支援です。
RFPに書くべき要求と提出証拠
RFPを「AIで予備品を最適化」の一文で済ませると、デモは立派でも、実データの欠損や部品互換性に答えられません。ベンダーには少なくとも次の証拠を求めます。
- 対象と責任境界：対象工場、倉庫、品番、設備、予測期間、発注提案までの範囲、承認者を明記する。
- データ契約：ERP・CMMSから読む項目、更新時刻、識別子、単位、欠品・返品・移送・廃番の扱いを表で示す。
- 比較設計：現行法、単純法、間欠需要向け基準法、AI候補を同条件で時系列比較する手順を固定する。
- 確率と不確実性：平均だけでなく発生確率・範囲・校正・低データ量警告を出す。
- 説明可能性：推薦を変えた承認済み作業、設備台数、納期変更などを、根拠時刻付きで示す。
- 承認・監査：誰が提案し、確認し、上書きし、ERPへ何を書いたかを追えるようにする。
- 失敗時の動作：データ欠測、ERP停止、マスタ不整合、モデル異常時に、直近承認済みルールへ戻す。
- 変更管理：モデル・特徴量・閾値・部品マスタの版を記録し、比較試験と切戻し手順を用意する。
- 納品物：データ辞書、マッピング表、評価コードまたは再現手順、試験記録、運用手順、教育資料を指定する。
SaaSか個別開発かは、データ連携、説明性、保守体制、輸出・データ保管条件、拠点展開の仕方で選びます。製品パンフレットの「AI搭載」だけでは、欠品中の潜在需要や品番継承に対応するか分かりません。デモでは自社の匿名化した実例を提示し、ベンダーに入力から推奨理由まで再現してもらいます。保全現場のタイ語名称とERPの英語品目名、日本本社の日本語報告が混在する場合、翻訳表示と品番同一性も別々に試験します。画面の自然言語説明が流暢でも、品番と数量が合っている保証にはなりません。
FATとSATで合格をどう決めるか
FATでは、統制した試験環境に既知の欠品、品番切替、計画延期、納期遅延を入れ、システムが予測と提案をどう変えるか確認します。SATではタイ工場のERP・CMMS、実際の倉庫、承認権限、時差、ネットワーク停止を使って再試験します。FATでモデルの数値が合っても、SATで設備台帳が別品番を指せば実用になりません。設備安全に関わる代替品は、モデルの類似度ではなく技術部門の承認済み互換表だけを使うことを負の試験で示します。
| 試験 | 注入する条件 | 期待する振る舞い | 必要な証拠 |
|---|---|---|---|
| 欠品期間 | 払出ゼロだが未充足要求あり | ゼロ需要と断定せず警告 | 入力系列と推奨理由 |
| 品番継承 | 旧品番廃番、後継品に片方向互換 | 承認済み範囲だけ系列を結ぶ | 技術承認マスタと版 |
| 作業延期 | 承認済み作業の時期を変更 | 既知需要の時期を更新 | 変更前後の差分 |
| 納期悪化 | 仕入先実納期が伸びる | 予測と発注判断を分離して示す | 納期分布と判断記録 |
| 情報漏洩 | 将来登録されたBOMを過去評価へ混入 | 評価時点では参照しない | データ時刻と試験ログ |
| ERP障害 | 連携APIが応答しない | 重複発注せず提案を保留 | エラー、再試行、復旧ログ |
| 権限違反 | 未承認担当が発注書確定を要求 | 拒否し監査ログに残す | 権限設定と拒否記録 |
数値の合格条件は、自社の現状と設備リスクから設定します。例えば「重要品で欠品件数を増やさない」「発注提案の監査証拠を全件残す」「ERPへの書込みは承認済み購買依頼案に限る」は絶対条件にできます。一方、全品番平均誤差の改善率や在庫金額の削減率は、基準期間と外部要因を固定した比較が必要です。実績がまだ無い段階で一律の改善率を保証する契約は避け、評価方法、最低受入値、未達時の是正と再試験を先に合意します。
小さく始める実装順序
最初の対象は「重要度が分かる設備群」「品番・作業指示・払出の対応が比較的整った倉庫」「購買の承認経路が明確な拠点」から選びます。対象を単純に高回転品だけにすると、一般的な需要予測の実証になり、保全予備品の難しさを試せません。逆に履歴ゼロの特殊品だけなら、モデル比較が成立しません。頻度と重要度が異なる品番を混ぜ、例外の扱いを検証します。
第1段階でデータ監査を行い、取引種別、品番重複、欠品記録、BOM更新日、実納期の欠損を洗い出します。第2段階で現行法と基準法の時間順バックテストを作り、評価方法を固定します。第3段階でAI候補を追加し、予測だけを週次レビューします。第4段階で発注提案を購買・保全が共同承認し、ERPへの限定書込みをSATで確認します。最後に対象品番・拠点を増やします。期間を「必ず90日」と固定するより、データ修正、設備停止期間、仕入先確認に要する時間を織り込む方が現実的です。
ここで、試験対象から外す品番の理由も残します。たとえば設備がすでに廃却されている、旧品番と後継品の適合関係が未承認、交換作業が一度も記録されていない、実際の入荷日が欠けている、といった理由です。都合の悪い品番だけ後から除外すると導入効果を過大評価します。逆に試験に必要な履歴が不足している品番へ、見かけだけ精密な予測値を出すことも避けます。除外件数、重要度、在庫金額と補完の担当者を毎回の評価書に載せ、試験範囲の変化を追えるようにしてください。
倉庫をまたぐ部品の融通も、予測の評価と実運用で同じ条件にします。バックテストでは隣接拠点から即日移送できる前提なのに、本番では輸送許可や通関、担当者の承認に数日かかるなら、机上の欠品率は意味を持ちません。移送可能な拠点、所要時間、輸送費、品質検査の要否を管理し、利用できない経路は候補から除きます。現場が「使える在庫」と判断する時点を再現することが、モデルの精度を評価する以前の前提です。
運用開始後もモデルが正しいとは限りません。設備更新、保全周期変更、供給元変更、廃番、異常気象、緊急増産などで、学習時と条件が変わります。需要発生率、予測区間の校正、重要品の欠品、緊急購入、在庫滞留、承認者の上書き率を監視します。ただし上書き率だけを低くすることを目標にすると、現場が理由を書かなくなる恐れがあります。上書き理由を分類し、データ欠損なのか、実際の新情報なのか、モデルの偏りなのかを定例で確認します。悪化したら新モデルへ自動更新せず、基準法や直近承認済み設定へ戻せるようにします。
費用対効果をどう説明するか
投資額にはソフト利用料だけでなく、マスタ整備、CMMS/ERP連携、データ履歴の補完、保全と購買のレビュー時間、教育、監査、モデル運用を含めます。便益は在庫金額の減少だけではありません。欠品で延期された保全、緊急輸送、代替品確認、設備停止の機会損失、廃番品の不動化をそれぞれ測ります。二重計上に注意してください。緊急調達費に停止損失がすでに含まれる見積なら、合算前に区分を確認します。損失を金額化できない安全・品質上の制約は、便益に換算して相殺するのではなく採用条件として扱います。
PoCの段階では「モデル精度が何%改善」という一数字だけで稟議を通さず、候補ごとの重要品の欠品、発注金額、滞留在庫、担当者の確認負荷を並べます。AIが基準法に勝てない品番群は基準法のままでよい、と書ける契約が健全です。IBMの製品資料には履歴だけでなく保全・生産側の将来計画を手入力または取込で使う予測モードが示されています。これはAIに全てを任せるより、予定作業の確定情報と不確実な需要を分離する設計の参考になります。自社の会計と現場条件で回収可能性を判断してください。
モデルの運用契約で追加したい五つの論点
第一に、データの所有者です。ERPの品目マスタは購買、設備BOMは保全または技術部門、予測結果は分析担当、発注判断は購買責任者というように、項目ごとに変更権限を分けます。モデル開発会社が「品番が似ているから同じ部品」とマスタを書き換える権限を持つべきではありません。統合作業で発見した不整合は、根拠と影響範囲を添えて所有部門に返し、承認された修正だけを次回学習に反映します。
第二に、予測時点の証拠保全です。後から「なぜその週に4個発注したか」を追うには、モデルだけ保存しても足りません。当時の払出、未充足要求、在庫と引当、作業指示の承認状態、仕入先納期、互換品マスタ、しきい値、承認者の判断を同じ案件IDで結びます。個人情報や仕入先の機密を無制限に複製せず、保存期間と閲覧権限を決めた監査記録にします。履歴データが後日訂正されても、当時の判断に使ったスナップショットを上書きしないことが重要です。
第三に、用途別の失効条件です。生産停止が急に前倒しになった、設備が廃却された、仕入先が納期回答を撤回した、重要品の代替認証が取り消されたとき、以前の推奨をそのまま使ってはいけません。どの変更が自動再計算、どの変更が人の再承認、どの変更が提案停止を要するかを表にします。停電やネットワーク断の後に古い提案がまとめてERPへ流れないよう、提案には有効期限と冪等な案件IDを持たせます。
第四に、モデル改善の採否手続きです。運用データで再学習した新モデルは、必ずしも旧モデルよりよいとは限りません。重要品の欠品、予測区間の校正、低頻度品の過剰発注、手動上書きの内容を旧版と比較し、合格した版だけを段階的に配布します。設備群の一部で先行試験してから広げる場合も、旧版へ戻す条件と担当者を事前に決めます。学習データに突発の大規模修理を含めるかどうかは、将来も繰り返す構造的な需要か、一回限りの事象かを保全責任者と確認します。
第五に、契約終了後の移行です。導入時から品番対応表、予測値、使用した入力時点、例外理由、承認履歴を一般的な形式で書き出せるようにします。ベンダー独自画面の中に意思決定の根拠を閉じ込めると、次期システムへ移るとき比較と監査ができません。モデルの知的財産権まで一律に求める必要はありませんが、工場が自分のデータと承認履歴を継続利用できることはRFPの条件にできます。この五点を運用契約に入れることで、PoC時の一時的な精度だけではなく、日常の発注判断を持続的に検証できます。
FAQ：保全予備品需要予測AIの導入
予備品の払出履歴が少なくてもAIを導入できますか？
可能な場合はありますが、品番単位で高精度を約束できません。設備台数、承認済み作業、共通部品群、供給リードタイムを使い、履歴の乏しい品番には不確実性と人の判断を明示します。比較試験で単純法を超えなければ、その群にはAIを使わない判断も含めます。
Croston法よりAIの方が常に正確ですか？
いいえ。間欠需要にはCroston系、TSB系などの基準法があり、AIが優位になるかはデータ量と特徴量、需要構造に依存します。同じ時系列・同じ情報時点・同じ在庫方針で比較し、重要品の欠品を含めて採否を決めます。
予知保全AIがあれば部品需要も自動で分かりますか？
設備の異常を推定しても、どの作業をいつ承認し、どの品番と数量が必要かは別の情報です。予知保全のアラートは入力の一つにできますが、CMMSの作業指示、BOM、互換品承認、購買リードタイムと照合して初めて予備品の準備につながります。
AIが発注書を自動送信してもよいですか？
初期導入では勧めません。まず予測と提案を見える化し、保全・購買の承認とERPの通常権限を通します。重複発注、品番誤り、予算超過、期限切れ承認を負の試験で排除できた範囲から段階的に扱います。
タイ工場での導入費用はどのように見積もりますか？
品番と設備台帳の整備、過去履歴の品質、CMMS/ERPのAPI、拠点数、必要な承認画面、モデル運用体制によって大きく変わります。固定の金額を一般化せず、対象品番・データ項目・連携方向・試験証拠・運用範囲をRFPでそろえた見積を比較してください。
まとめ：AIの予測精度より、判断を再現できるか
製造業の保全予備品需要予測AIは、払出履歴を学習させて発注数を出すだけでは完成しません。欠品で見えなかった需要、品番継承、承認済み保全作業、供給納期、設備重要度を時点付きで結び、単純な基準法との時間順比較で価値を確かめます。予測と在庫・発注判断を分離し、保全と購買が理由を確認して承認できるようにすることが、導入の合格条件です。FAT/SATでは平均誤差だけでなく、重要品の欠品、誤代替、将来情報の漏洩、ERPへの誤書込みを負の試験で確認してください。
タイ工場で対象設備・品番を絞ったRFPやPoCの設計段階から相談したい場合は、TOMAS TECHへのお問い合わせをご利用ください。現在のCMMS/ERPの構成と、困っている欠品・滞留の事例が分かれば、最初に照合すべきデータと受入条件を一緒に整理できます。
参考情報
- ISO TC 251, ISO 55001:2024の変更点。資産管理の意思決定、リスク、資源を伴う計画の文脈を確認。https://committee.iso.org/sites/tc251/home/projects/published/iso-55001.html
- Microsoft Learn, Croston’s method forecasting (preview)。間欠需要の特性と単純な予測法の課題を確認。https://learn.microsoft.com/en-us/dynamics365/supply-chain/demand-planning/croston-method
- Microsoft Learn, Creating work orders。保全予定から作業指示を作る流れを確認。https://learn.microsoft.com/en-us/dynamics365/supply-chain/asset-management/preventive-and-reactive-maintenance/creating-work-orders
- IBM Docs, Maximo Inventory Optimization product overview。間欠需要、重要度、リードタイムを扱う機能説明を確認。https://www.ibm.com/docs/en/mio?topic=product-overview
- IBM Docs, Projected demand and forecast modes。履歴と保全・生産の将来計画を分けて扱う機能説明を確認。https://www.ibm.com/docs/en/mio?topic=items-projected-demand-forecast-modes
- IBM Docs, Maximo work orders。作業指示に材料、工具、設備等を含める構造を確認。https://www.ibm.com/docs/en/masv-and-l/maximo-manage/cd?topic=manage-work-orders-module
- Procedia CIRP, 2025, MRO予備品需要の予測手法比較。方法ごとの条件依存性を確認。https://www.sciencedirect.com/science/article/pii/S221282712500263X
公開情報の確認日：2026年10月18日。製品機能やプレビューの提供条件は契約・版によって変わり得ます。試験条件と実装の詳細は各工場のシステムと設備に合わせて確認してください。
