「出荷した製品の部品が、いざというとき現場で使えない——」そんな事態に、心当たりはありませんか?
たとえば
- コールセンターが旧番か新番か分からず、手配が止まる
- 修理現場で「見た目は同じなのに互換性がなく」交換できない
- サービス倉庫に在庫はあるのに、保証対象外で使えないと返却される
実際に製品が故障したとき、一発で正しい部品が届くかどうかは、エンドユーザーの満足度だけでなく、現場の工数・在庫コスト・保証コストにも直結します。
しかし、こうしたトラブルは現場のせいでもシステムのせいでもありません。
根本的には「部品表(BOM)が保守のために作られていない」ことに原因があります。
多くの製造業では、設計段階で作られEBOM(設計BOM)や、製造工程用のMBOM(製造BOM)は整備されています。
でも、保守・補修の現場で本当に必要な視点。交換単位・代替品・互換性・適用範囲・シリアル管理などを考慮した「サービスBOM(保守BOM)」は、まだ十分に構築されていないことが多いのが実情です。
結果として、現場ではこうなります:
- 見えているのに使えない部品が多発
- 初回修理解決率(FTFR)が上がらない
- 保証の判定が曖昧で、社内の確認工数が増える
- 旧番→新番のチェーンが追えず、誤手配が頻発
- 地域/仕様違いの適用ミスで出荷トラブルが発生
本記事でわかること
こうした状況を変えるには「サービスBOM」の考え方と設計が不可欠です。
本記事では、以下の内容を図表付きで実務的にわかりやすく解説します。
- サービスBOMとは何か?(EBOM/MBOMとの違いを含めて整理)
- 交換単位(LRU/SRU/CRU)ベースでの構成方法
- 代替・互換・適用モデル・シリアル範囲の設計ルール
- As-Built/As-Maintainedとの関係や、保証・リコールとの連携
- PLM/ERP/FSM/カタログ/ECとのシステム連携の要点
- 設計チェックリスト・Excelテンプレートを使った導入ステップ
BOMに関して全体像を知りたい方はこちらの記事をごかくにんください。
→BOMとは?|定義・種類・作成手順・管理ベストプラクティスまで徹底解説

監修・執筆:UEL株式会社編集部
UEL株式会社のTechデザイン企画部と現場に精通した社内有識者が監修・執筆しています。
本記事は一般的な情報提供を目的としたものであり、特定の企業・環境・状況への適用や効果を保証するものではありません。内容の利用は読者ご自身の判断と責任にてお願いいたします。参考としてご活用ください。
サービスBOMとは?
サービスBOM(保守部品表)とは、製品が市場に出たあと、保守・補修の現場で正しく・迅速に部品を特定・手配できるように再編成された部品表(BOM)です。
従来のBOM(EBOM:設計用、MBOM:製造用)は、それぞれ設計構成や製造工程の最適化を目的としたものであり、そのままではサービス現場で必要な「交換可能単位」「保証可否」「適用条件」「代替・互換ルール」などが不足していることが多くあります。
サービスBOMは、それらを補い、アフターサービス業務に特化して構成されたBOMです。
目的:なぜサービスBOMが必要か?
サービスBOMの導入によって、以下のような課題を解決できます:
- 一次解決率(FTFR)の向上
→ 現場で部品を一発特定・一発交換できる - 誤手配の削減
→ 適用範囲や互換性が明記され、誤った部品を出荷しない - 在庫の最適化
→ モデルや市場ごとに適用品が絞り込まれ、在庫管理が効率化 - 保証適用の迅速化
→ サービス品番ごとに保証可否が定義され、照合がスムーズ
他BOMとの役割の違い
種別 | 主な目的 |
---|---|
EBOM | 設計意図の反映(設計構成) |
MBOM | 製造工程の実行(製造構成) |
サービスBOM | 保守・補修・部品手配の実行(サービス構成) |
ポイント:
どのBOMも必要ですが、使用フェーズに応じて目的がまったく異なるため、
特にサービスフェーズではサービスBOMがなければ業務が成立しないケースが増えています。
利用されるタッチポイント
サービスBOMは、以下のような現場業務の中核で利用されます:
タッチポイント | 主な用途例 |
---|---|
オンラインパーツカタログ | 顧客や代理店が適用品を検索・発注する |
コールセンター/サービスデスク | 型番・互換性・保証区分を問い合わせ/回答 |
現場作業(FSM) | 作業員が部品を特定し、その場で交換を行う |
RMA/修理センター | 修理可否や再利用判断のために構成情報を参照 |
LRU/SRU/CRU:交換単位の基本構造
サービスBOMは、現場で実際に交換可能な単位(Replaceable Unit)を基準に構成されます。
区分 | 名称 | 概要 |
---|---|---|
LRU | Line Replaceable Unit | 現場(ライン)で即時交換できるユニット(例:電源ユニット) |
SRU | Shop Replaceable Unit | 修理センターで分解・交換可能な中ユニット(例:基板単体) |
CRU | Customer Replaceable Unit | 顧客が自ら交換可能な小部品(例:フィルター、ファン) |
図:LRU/SRU/CRUのレベル分解イメージ
(※各階層に「交換時間」「必要工具」「安全基準」のラベル付きブロック図)
150%サービスBOM → 100%サービスBOMの考え方
保守用の部品構成は、製品の型番・仕様・市場・地域・オプション装備などによりバリエーションが多岐にわたります。
これに対応するため、サービスBOMは次のような階層で設計されます:
- 150%サービスBOM:全てのバリエーション候補を含んだマスタ構成
- 100%サービスBOM:ユーザーのS/N・地域・仕様に応じてフィルタ抽出された適用品構成
この設計によって:
- 部品のマスタを一元管理しながら
- エンドユーザーには必要な構成だけを自動提示でき
- カタログやFSMとの連携もスムーズになります
EBOM・MBOMとの違い
同じ「BOM」でも、目的がまったく違う
設計、製造、保守それぞれのフェーズで必要とされるBOMは、名前は似ていても役割も中身もまったく別物です。
- EBOM(Engineering BOM)は、「どう作るか」ではなく「どう設計されたか」に焦点を当てた設計構成
- MBOM(Manufacturing BOM)は、製造現場で「どう組み立てるか」の作業・工程中心
- サービスBOM(Service BOM)は、保守・修理現場で「どう交換し、どう保証し、どう選定するか」の視点で構成
つまり:
EBOM=設計の意図を表現するためのBOM
MBOM=製造工程を実行するためのBOM
サービスBOM=保守現場で正しく手配・交換するためのBOM
EBOM・MBOM・サービスBOMの比較表
以下は、それぞれのBOMの違いを6つの観点で整理した比較表です。
観点 | EBOM(設計BOM) | MBOM(製造BOM) | サービスBOM(保守BOM) |
---|---|---|---|
目的 | 設計意図の反映 | 製造工程の実行 | 保守・補修・部品手配の実行 |
粒度 | 機能分解(ユニット構造) | 作業順/着座順(工程順序) | 交換可能単位中心(LRU/SRU/キット単位) |
主な属性 | 図面/改訂履歴/材料仕様 | 工程用途/治工具/置場/段取り | 代替/互換/適用機種/シリアル/保証/キット |
主システム | PDM/PLM | ERP/MES | FSM/パーツカタログ/EC・DMS |
更新トリガ | 設計変更 | 工程変更・購買変更 | 代替化・廃番・リコール・適用範囲の拡大/縮小 |
ポイント:
サービスBOMは「物理構成」ではなく「交換構成」=現場で交換/供給できる単位で再構成されている点が特徴です。
どのBOMにも正解がある。目的によって「使い分け」が必要
多くの現場トラブルは、「BOMそのものが間違っていた」のではなく、フェーズに合わないBOMを使いまわしてしまったことが原因です。
たとえば:
- 製造用MBOMをカタログ用に流用 → 不要な治工具・工程情報が混在
- EBOMの図番しか持っていない → サービス部品の代替ルールに対応できない
- サービスBOMがなくMBOMを使って手配 → 保証適用や互換判定が不明確
BOMは一つではありません。フェーズごとに最適なBOMを設計・運用・連携することが、エンジニアリングチェーンとサプライチェーンの分断を防ぐ鍵になります。
構成の持ち方①:代替
なぜ「代替」の設計が難しいのか?
現場で頻発する誤手配や在庫引当ミスの多くは、旧番→新番の移行や代替部品の使い方が曖昧なまま進められていることに起因します。
その理由のひとつは、「代替」と一口に言っても、意図や前提がまったく異なる複数のケースが混在しているからです。
設計すべきは2種類の代替
サービスBOMにおいては、以下の2種類を明確に区別して管理する必要があります。
種類 | 説明 | 例 |
---|---|---|
計画代替 | 旧番→新番への移行。設計変更や生産中止による後継チェーン。 | SV-1001-A → SV-1001-B |
同等代替 | 条件付き・優先順位付きの代替。機能は同等だが違いあり。 | 消費期限短い部品、色違いなど |
両者を同じ列/同じルールで扱うとトラブルのもとになります。設計段階で「代替の区分」を必ず定義し、現場に伝わるように明示することが重要です。
必須の属性項目
代替を実務で正しく運用するには、以下のような属性を部品マスタで管理する必要があります。
属性名 | 用途・説明 |
---|---|
代替区分 | 「計画代替」「同等代替」などの種別 |
優先度 | 同等代替が複数ある場合の使用順序(例:1st / 2nd) |
有効開始日/終了日 | 適用期間の制御(計画切替・リコール対応など) |
シリアル範囲 | 適用品かどうかをS/Nで判定 |
双方向互換(Yes/No) | 新→旧への引当も可能か?(片方向 or 相互) |
FFF基準での互換判断とは?
代替部品の互換性を判断する際は、FFF(Form, Fit, Function)という基本指針を使います。
項目 | 内容 |
---|---|
Form | 外形・寸法・接続部が同じか |
Fit | 取り付け可能か、安全性に問題ないか |
Function | 性能や機能が等しいか |
FFFがすべて一致する場合、「完全互換・同等代替」として扱えます。
一部だけ異なる場合は、「要注意互換」や「条件付き保証」に分類し、マスタに注記/制限条件を登録しておきましょう。
代替が影響を及ぼすもの
代替設計を疎かにすると、以下のような副作用が発生します:
- 保証判定:代替後の部品が保証対象か不明になり、CS対応が増える
- 在庫引当:旧番・新番の混在により引当ミスが起きる
- 価格・原価:代替品が高額・高原価であっても自動で置換されてしまう
- 輸送規制(HazMat):代替品が危険物扱いになる可能性を見落とす
これらの影響を防ぐためにも、代替ルールと属性を明文化・マスタ化することが重要です。
実務での推奨:ExcelやPLMマスタへの実装例
導入初期であれば、以下のようなカラム構成でExcelやPLMマスタに代替情報を追加していくのが推奨します。
サービス品番 | 旧番-新番チェーンID | 代替区分 | 優先度 | 有効開始日 | シリアルFrom | シリアルTo | 双方向互換 |
---|---|---|---|---|---|---|---|
SV-1001-B | CHAIN-CTRL-01 | 計画代替 | 2024-04-01 | AX1-000100 | AX1-009999 | Yes | |
SV-2005-B | 同等代替 | 1 | 2023-10-01 | No |
構成の持ち方②:互換性
「使えるはずが使えない」その原因は互換性設計にある
部品の見た目が同じでも、「本当に使えるかどうか」は互換性の定義にかかっています。
現場でよくある混乱は、互換性の方向(前方/後方/相互)が不明確なまま運用されていることに起因します。
互換性の3タイプを明確に分ける
種類 | 意味 | 例 |
---|---|---|
前方互換 | 新→旧に使える(新型が旧型の代わりに使える) | 新型電源が旧型コントローラに対応する |
後方互換 | 旧→新に使える(旧型が新型にも使える) | 旧モデルのパーツを新モデルにも流用 |
相互互換 | 双方向に使える(どちらでも代用可能) | 同一性能・同一サイズのファン部品 |
ポイント:
代替と異なり、互換性は方向性を含めて「相性」の管理です。
双方向に使えるか、片方向だけかで、保証・在庫引当・カタログ表示のルールが変わります。
適用条件の記述方法:粒度と視点をそろえる
互換判断を正しく下すためには、どの条件下で互換とするかを明記する必要があります。
特にサービスBOMでは、次の4つの視点での記述が推奨されます。
視点 | 説明例 |
---|---|
モデル/仕様コード | AX100/AX120/AX150など型番や内部仕様の違い |
市場(地域/電圧) | JP 100V/EU 230V/US 120Vなど |
オプション装備 | フル装備/エントリーモデル/通信モジュール有無など |
キット/バンドル構成 | キットAに含まれる部品/個別供給か否かの違い |
これらの条件を部品ごとに組み合わせて記述し、「どこまでなら同一扱いOKか」を定義することで、誤出荷や保証外の組合せを防ぐことができます。
関連する属性設計:互換をマスタ管理するためのカラム例
サービスBOMで互換性をマスタ化するには、以下の属性が重要です:
属性名 | 説明 |
---|---|
互換グループID | 同じ機能・性能を持つ部品群に付けるグループ識別子(例:COMP-GRP-03) |
禁止組合せ(Exclusion) | 組み合わせると問題があるモデルや仕様(例:AX100 × 高電圧部品) |
必要同梱(Inclusion) | 一緒に使わないと機能しない部品(例:変換ブラケット、取付ビスなど) |
これらはパーツカタログやFSMにも展開される情報です。
互換情報は「現場判断の自動化」に直結するため、必ず構造的に定義し、単なる注記にしないことが重要です。
互換性と他プロセスとの接続点
- 在庫引当ルール:互換グループ単位で在庫を横断引当可能にするか否か
- 保証区分との連携:後方互換の場合は保証対象外にするか、明示ルールを設ける
- カタログ表示:前方互換部品は「代替候補」として別枠で表示、同一扱いしない
実務における注意点
- 互換情報を部品同士の「関係性」として構造的に管理する
- 「相互互換だから何でも使える」とは限らない。適用条件が揃って初めて成立
- 禁止組合せと必要同梱は現場マニュアルや作業指示書生成時にも活用される
構成の持ち方③:適用機種・適用範囲
なぜ適用範囲の管理が重要なのか?
「その部品、本当にこの製品に使っていいのか?」
この判断を現場が一目でできるかどうかは、保守業務の成否を分けます。
誤出荷・誤手配・保証ミスの多くは、適用機種やシリアル管理が曖昧なまま運用されていることに原因があります。
適用範囲には3種類の効果がある
サービスBOMでは、以下の3つの効果情報を使い分けて、部品の適用条件を明確に管理します。
図:適用範囲(3種の効果)
※タイムライン+構成ツリーの模式図で、モデル・シリアル・製番の違いを視覚化。
種別 | 説明 | 使用例 |
---|---|---|
モデル効果日 | 特定のモデルがいつからいつまで対象かを管理 | AX120 → 2024年1月〜2026年12月 |
シリアル効果 | シリアル番号(S/N)の範囲で適用対象を絞り込む | S/N From:AX1-000100〜000999 |
ロット/製番効果 | ロット番号や製番単位で適用品を限定する | Lot-202401〜Lot-202406 など |
これらの効果情報は個別に使ってもよいですし、組み合わせて条件を厳密化することも可能です。
適用条件を組み合わせて絞り込む
次のようなテーブルで、「どのモデル/地域/シリアルに使えるか」を定義すると、
150%サービスBOMからのフィルタリングがスムーズになります。
モデル | 地域/電圧 | S/N From | S/N To | 備考 |
---|---|---|---|---|
AX100 | JP 100V | AX1-000100 | AX1-004999 | 後方互換のみ/要アダプタ同梱 |
AX120 | EU 230V | AX1-020000 | AX1-029999 | 正常適用 |
AX150Pro | US 120V | AX1-050000 | AX1-059999 | 除外条件あり(バッテリ別売) |
- モデル名(型番)
- 地域・市場・電圧
- シリアル番号範囲
- 補足条件(同梱品・除外組合せ など)
150%構成 → 100%構成へのフィルタワークフロー
多くの製品は、モデル・市場・構成オプションによってバリエーションが存在します。
このため、サービスBOMは最初に「150%構成(全候補を含む)」で作成し、以下のようなフィルタ条件で「100%構成(適用品だけ)」を動的に生成するのが基本です。
フィルタ条件の例:
- モデル:AX120
- 地域:EU
- シリアル:AX1-021000
- オプション装備:無線モジュール付き
この条件でフィルタすれば、該当ユーザーに必要かつ正しい部品だけが抽出されます。
この仕組みは、ECのパーツカタログ/RMA対応システム/FSM現場支援アプリにも組み込むことが可能で、
「誤出荷のない世界」を実現するための重要な鍵となります。
実務ヒント:テンプレ設計時のカラム定義
ExcelやPLM上のサービスBOMテンプレートでは、以下のカラムを定義しましょう:
- 適用モデル(複数記述可)
- 適用地域(JP/EU/USなど)
- シリアルFrom/To(半角固定)
- 効果開始日/終了日(モデル効果用)
- 除外条件/必要同梱(互換連動)
現品票・シリアルとの関係
サービスBOMは今の構成とつながってはじめて価値を持つ
設計や製造時点の構成(EBOM/MBOM)だけでは、
出荷後の製品が実際にどのような状態で、何が交換されたかまでは追えません。
保守の現場では、以下のような構成のトラッキングが重要になります:
- 出荷時点の構成 → As-Built構成
- 保守作業後に更新された構成 → As-Maintained構成
この構成の「今」を把握し、保証やリコールの判断に直結させるためのベースとなるのが、サービスBOMと現品票の接続です。
As-BuiltとAs-Maintainedの違い
種類 | 定義 | 主な用途 |
---|---|---|
As-Built | 出荷時点の製品構成。製番・S/N単位で固定される | 保証開始判定/適用品フィルタの起点 |
As-Maintained | 保守履歴・交換履歴を反映した現在の構成 | RMA対応/次回訪問計画/構成追跡/保証残の確認など |
As-Builtは「出荷された時の真実」、As-Maintainedは「現在の構成の真実」。
両者をつなぐのがサービスBOM+ワークオーダー(WO)+構成履歴の連携です。
流れ:現品票(S/N)→WO→構成更新のプロセス
製番(S/N)登録
↓
インストールベース(設置台帳)に構成を記録(As-Built)
↓
ワークオーダー(WO)発行・作業
↓
交換実績を構成履歴に反映(As-Maintainedへ)
↓
最新構成情報で保証/次回対応/RMAを判断
この流れが整っていれば、サービスBOMの代替・互換・適用・保証情報を正しく運用できます。
保証判定のポイントとサービスBOMとの接点
保証可否を判定する際には、以下のような要素を総合的に見る必要があります:
判定観点 | 参照する情報 |
---|---|
対象部位 | サービスBOM上の「保証区分」属性 |
使用条件 | シリアル範囲/適用モデル/地域などの「適用品定義」 |
保証期間 | 効果開始日/終了日、または設置日+経過年数など |
保証回数制限 | 構成履歴とワークオーダー情報を突合(例:バッテリは1回まで) |
保証の判定ロジックは、「現品票(S/N)+サービスBOMの属性+構成履歴」で構成されます。
これが自動で照合されていれば、CSやサービス現場での確認負担は大きく軽減できます。
リコール/サービスキャンペーンでの照合プロセス
リコールや無償対応キャンペーンの際には、次のようなプロセスで対象製品の抽出と交換部品の特定が行われます:
- S/Nスキャン/製番検索(顧客や現場が実施)
- インストールベースからAs-Built構成を呼び出し
- サービスBOMの適用品定義と突合
- 代替・互換ルールを反映し、交換対象部品を自動抽出
- ワークオーダー自動生成/部品先出し発送などを実施
これにより、「誰が・どの製番で・どの部品を・いつ・どのように対応すべきか」を機械的に判断することが可能になります。
現場実務における設計ポイント
- S/Nと品番の接続:現品票に対応する品番・構成情報を設置台帳で一元管理
- 構成更新履歴の蓄積:As-Maintained構成はワークオーダーを通じて自動更新
- BOM属性の参照設計:保証/互換/代替/適用条件などを構成単位でフィルタ可能に
- 履歴がない構成変更は禁止:棚卸・保証・RMAすべてに影響するため履歴必須
作り方:EBOM/MBOMからサービスBOMを派生させる
設計・製造用のBOMは、そのままでは使えない
EBOM(設計BOM)やMBOM(製造BOM)は、それぞれ「どう設計されたか」「どう作るか」に最適化されています。
しかし保守現場が必要とするのは、「どう交換できるか」「どこまで保証するか」という視点です。
そのため、サービスBOMは既存のBOMから再編成・再定義して派生させる必要があります。
サービスBOMの派生ステップ(5段階)
Step 1:交換可能単位(LRU/SRU)を抽出
- まずは、既存の部品構成から交換可能な単位(Replaceable Unit)を抽出します。
- 線引きの基準は以下の4つ: 判定軸例交換時間15分以内で現場交換できるか?工具の有無特殊工具が不要か?標準工具で済むか?安全性感電・圧力・放射などのリスクが低いか?
- この基準で、LRU/SRU/CRUへの分類を行い、サービス部品候補を確定します。
Step 2:MBOM構成をサービス部品に置換
- 次に、MBOMの構成部品をベースにしながら、以下のような変換を行います: 処理内容例分割1つのMBOM品番を複数のサービス部品に分解キット化現場作業を効率化するためのセット組み消耗品追加フィルター・グリス・シールなど現場補充品
- これにより、実際に使いやすい部品構成に変換されます。
Step 3:代替・互換・適用ルールを付与(マスタ化)
- 派生した部品には、前章で解説した以下の属性をマスタとして付与します: 属性カテゴリ内容代替計画代替 or 同等代替/優先度/有効期間/双方向互換など互換方向性(前方・後方・相互)/互換グループID/除外・同梱条件適用モデル/仕様コード/地域/シリアルFrom–To/効果日
- これらをマスタ化しておくことで、サービスBOMとしての信頼性と一貫性が保たれます。
Step 4:公開フローの整備(可視化・翻訳・価格)
- 現場がBOMを正しく活用できるようにするには、以下の公開処理が不可欠です: 要素内容テクニカルイラスト分解図/爆発図で交換部位を可視化翻訳多言語対応(地域ごとに表示文言を切替)価格参考価格 or サービス価格を表示在庫可視化拠点ごとの在庫数/引当可否などを連携
- FSMアプリ/eカタログ/修理見積などとシームレスに接続されることが理想です。
Step 5:システム連携と配信(PLM → FSM/カタログ/EC)
- 最終的に、整備されたサービスBOMを各システムに正確に配信・承認していきます。
PLM(マスタ管理)
↓
FSM/パーツカタログ/EC(配信先)
↓
承認ゲート or 自動連携(差分更新・バージョン管理)
- 承認フロー・配信バッチ・トリガ設計も含め、業務運用と密接に統合されるべきです。
変換マッピング例:設計BOM → サービスBOM
設計品番 | サービス品番 | 交換レベル | キットID | 適用条件 | 互換可否 | 参考価格 |
---|---|---|---|---|---|---|
CTRL-0001 | SV-1001-A | LRU | KIT-CTRL-01 | AX120/JP/100V | Yes | ¥85,000 |
PWR-750A | SV-2005-B | SRU | KIT-PWR-01 | AX100/US/120V | No | ¥22,000 |
FAN-A3x3 | SV-3002-K | CRU | KIT-FAN-03 | AX120/EU/230V | Yes | ¥9,800 |
- このようなマッピング表を作成し、PLM→FSM→eカタログへの構成連携のベースとします。
運用と変更管理(ECR/ECN・サプライチェーン)
なぜ「作って終わり」ではないのか?
サービスBOMは一度作れば終わり、ではありません。
部品の代替・廃番・リコール、適用拡大/縮小、保証条件の変更など——
サービス提供中も絶えず変化する製品構成に追従し続けることが求められます。
そのためには、変更管理(ECR/ECN)と、流通・サービス部門との連携設計が不可欠です。
旧番→新番の自動継承と引当切替
代替部品の導入にあたっては、単に品番を置き換えるだけでなく、以下の設計が必要です:
項目 | 説明 |
---|---|
自動継承ルール | 旧番→新番のチェーンIDで繋ぎ、システム上の引当も新番に切替える |
並行在庫の消化ルール | 在庫が旧番・新番で混在する場合、優先順位・保証条件・価格差分を明確化する |
双方向互換の有無 | 新→旧への引当を許可するかどうか(片方向代替 or 相互互換) |
PLM・ERP連携時には、旧番→新番の置換対象が「保証内か否か」で処理を分けるなど、
引当や価格・保証への影響まで設計する必要があります。
変更内容の通知と配信先の設計
サービスBOMの変更は、以下の業務部門・チャネルへ正しく通知・配信されることが必須です。
通知先/配信先 | 内容例 |
---|---|
コールセンター | 保証・互換・代替情報の最新化(顧客対応時の即答のため) |
代理店/修理拠点 | 部品の変更・代替・価格変更・適用機種拡大/終了の情報 |
オンラインパーツカタログ | 構成変更・代替品の優先表示・適用品のフィルタ更新 |
価格表・パーツ表PDF | 定期的な価格・品番・適用条件の一括更新(更新履歴付き) |
FSMシステム | 適用範囲・保証・交換可能レベルの再同期化 |
通知は一括配信でもよいですが、更新カテゴリごと(代替・価格・適用範囲など)に分かれていると、現場判断が迅速になります。
監査対応:変更履歴と適用証跡の管理
製品ライフサイクルが長い製品では、変更の証跡を年単位で遡って確認する必要があるケースもあります。
特に保証対応・リコール対応時には、下記の管理が求められます。
対応項目 | 説明 |
---|---|
変更履歴 | いつ/誰が/どの属性を/どう変えたかの記録(ECN履歴) |
適用証跡 | 適用された構成(モデル・S/N・地域など)と効果期間のログ |
ロールバック手順 | 誤った変更や承認漏れがあった場合の巻き戻し手順と権限管理の整備 |
よくある落とし穴は、「Excelベースで複数バージョンが拠点にばらまかれた結果、整合性が取れなくなる」こと。
単一マスタ+承認ゲート制+自動配信が推奨されます。
実務ヒント:変更管理チェックリスト
- ECN通知の配信先は整っているか?(社外含む)
- 品番チェーンと在庫引当のルールが明文化されているか?
- 過去変更の証跡を5年分以上遡れるか?
- カタログ・価格表・FSMに自動反映される構成になっているか?
- 間違った更新をロールバックできる権限設計があるか?
システム連携(PLM/ERP/FSM/カタログ/EC)
部品情報は「設計」から「サービス」へ、シームレスに流れるべき
サービスBOMは、設計部門だけのものではありません。
マスタ起点から、在庫・作業・販売チャネルに至るまで、正確かつ自動的に連携されることで、
はじめてその価値を最大化できます。
典型アーキテクチャ:サービスBOM連携の全体像
PLM(マスタ起点:品番・構成・属性)
↓
ERP(品目登録・在庫・価格・仕入情報)
↓
FSM(WO・構成・設置情報・作業履歴)
↓
eカタログ/EC(部品検索・発注・保証表示)
図:BOM情報の連携アーキテクチャ構成図(例)
各システムを横断して「品番」「適用」「代替・互換」「構成」が流れる様子を示した連携図(一方向&双方向)
各システムに渡すべきデータ項目
サービスBOMを各システムと連携するうえで、押さえておくべきデータ項目の設計ポイントは以下の通りです。
項目カテゴリ | 説明/用途 |
---|---|
品番・サービス品番 | 各レベル(LRU/SRU/CRU)の品番体系と命名ルール |
代替・互換情報 | 計画代替・同等代替、互換グループ、優先度、双方向フラグなど |
適用条件 | モデル・地域・仕様コード・S/N範囲・効果期間など、フィルタ条件として使用される |
構成レベル | 親子関係(親品番・数量・単位)、交換レベル、キット構成 |
保証属性 | 保証区分(対象・条件付き・非対象)、回数制限、対象部位フラグ |
メディアリンク | テクニカルイラスト・爆図・マニュアルへのリンク(図番やURL) |
危険品コード | UN番号やHazMat情報。輸送可否判定や通関情報と連携 |
梱包入数 | 箱入数・パッケージタイプ・最小発注単位など |
参考価格 | サービス価格(エンドユーザー向け)、または参考原価 |
リードタイム | 倉庫出荷や仕入先リードタイム(日数)。引当計画や納期回答で利用 |
システムごとのIF活用例
システム | 主な活用ポイント |
---|---|
PLM | BOM構成・属性のマスタ管理。ECNによる変更履歴トラッキング |
ERP | 品番管理・在庫管理・価格表登録。並行在庫の引当・消化制御も対応 |
FSM | インストールベースの構成確認、適用品の検索、保証対応可否の判定 |
eカタログ | 顧客向け部品検索・画像表示・適用品フィルタ・互換部品一覧など |
EC/DMS | B2B/B2C販売チャネルにてパーツ購入ページやRMA受付と自動連携 |
実務ヒント:マスタ連携を設計する際の注意点
- マスタ配信は差分方式(更新分のみ) or 全量方式(フル配信)を選択する
- 互換・適用情報は構成マスタとは別テーブル管理してもよい(複数品番にまたがるため)
- FSMやECでは「構成の現在値」=As-Maintained構成との突合が必要
成果指標(KGI/KPI)
サービスBOMは「見える成果」に直結する
サービスBOMは「設計側の業務」ではありますが、
その構築・運用がアフターサービス全体のパフォーマンスに直結します。
KPIは単なる数値ではなく、「部品情報が現場で正しく機能しているか」の健康診断項目です。
主なKGI/KPI項目
指標名 | 説明 |
---|---|
FTFR(First Time Fix Rate) | 一発解決率。正しい部品が初回で届く割合。交換構成の整備で大幅に向上。 |
誤手配率 | 誤った部品が出荷された件数/率。代替・適用ルールの明確化で減少。 |
在庫回転率/滞留率 | 適用品を絞り込んだことで在庫が動きやすくなる。ロングテール在庫の可視化も可能に。 |
パーツ売上率 | 製品売上に対する部品売上の割合。カタログ整備により販売機会が拡大。 |
検索 → 購入CVR | パーツカタログ上で部品を検索してから購入に至る割合。適用品抽出の精度で改善。 |
平均修理TAT | 修理完了までの平均日数。事前交換準備が進むことで短縮される。 |
導入前後のベンチマーク例
項目 | 導入前(例) | 導入後(目標) | 備考 |
---|---|---|---|
一次解決率(FTFR) | 72% | 90%以上 | 構成の正確化と代替・適用情報の反映 |
誤手配率 | 8.5% | 1.5%未満 | 互換・適用品判定の自動化で防止 |
在庫回転率(年) | 1.6回 | 3.0回以上 | 不適用品在庫の圧縮+在庫最適化が鍵 |
検索→購入CVR(EC) | 12% | 25%以上 | フィルタ精度と代替候補の表示が効果的 |
平均修理TAT(日) | 7.2日 | 4.5日以下 | WO前倒し・部品先出しなどの対応力向上による |
数値はあくまでモデルケースですが、サービスBOMの導入で可視化・改善可能な領域が明確であることが分かります。
ダッシュボード設計のヒント
サービスBOM運用状況の可視化には、部品属性/構成/履歴と業務実績を掛け合わせたKPIビューが有効です。
ダッシュボード項目例 | 解説 |
---|---|
品番別FTFR | どの部品で一発解決率が低いかを特定できる |
誤手配の原因分類(代替/互換/適用ミスなど) | 設計側のどのルールが破られているかを把握 |
モデル別・地域別適用品精度 | 地域・市場ごとの設定ミスや適用漏れを可視化 |
キット構成使用率 | キット化が現場で活用されているか、活用率で評価できる |
保証適用否認理由(データ不足/構成不整合など) | CSや現場で保証適用できなかったケースを構造化できる |
サービスBOMとFSM/パーツカタログ/保証システムが連携されていれば、これらのKPIは自動的に集計可能です。
よくある失敗と対策
❶ 代替と互換を同じ列で管理して混乱
Problem
「代替品と互換品を1列でまとめて管理」していると、
現場で使えるはずの部品が出荷されない/保証外の部品が混入といったトラブルが多発します。
Why?
- 代替:時系列の置き換え(旧番 → 新番)
- 互換:技術的な交換可否(前方/後方/相互)
→ 目的も運用もまったく異なる概念です。
Solution
- 代替と互換は別テーブルまたは別カラムで管理する
- 各項目に優先度/有効期間/方向性(片道or双方向)/判定ルールを明記する
- FSMやeカタログではUI上も明確に分離表示することで誤認防止
❷ MBOMの工程情報をサービスBOMに混在
Problem
製造工程(MBOM)の作業順や治工具情報が、そのままサービスBOMにも残っているケース。
→ 結果、「現場で不要な工程手順が表示され、誤解・混乱が発生」。
Solution
- サービスBOMには「構成と属性のみ」を含める
- 作業手順はFSMやサービスマニュアルに切り出すのが基本
- BOM上には「交換時間」「安全条件」など作業性のメタ情報のみ残すのがベター
❸ 適用範囲が曖昧で誤出荷
Problem
モデル別やシリアル別の適用が明確でないと、「似ているけど適用外」の部品が手配・出荷されるリスクが高まります。
Solution
- 適用条件はモデル/仕様コード/地域/S/N範囲/効果日などで細かく定義する
- 「適用あり/なし」ではなく、条件を列挙して機械判定できる構造に
- フィルタ適用品抽出や検索制限でユーザーが誤選択しない仕組みを作る
❹ 旧番 → 新番チェーンが分断
Problem
旧番 → 新番の代替履歴が正しく連結されておらず、
「途中の品番が抜けて引当できない」「保証対象から漏れる」といった連鎖ミスが発生。
Solution
- 継承グループIDを設けて「どの代替チェーンに属するか」を明示
- 過去の代替履歴は履歴を凍結/保存する設計(ロジ含む)」にしておく
- FSMや保証判定では、最新品番へ自動トレースされる設計に
❺ Excelで現場版が乱立してしまう
Problem
拠点や担当者ごとに独自編集されたExcelのBOMが氾濫し、
どれが正しいマスタか分からなくなる。更新漏れ・バージョン混在・誤出荷の温床に。
Solution
- 単一マスタ(PLMなど)を定義し、承認済のみを流通させる
- FSM/eカタログなどのフロントエンドにAPI連携で自動配信
- 「マスタ改訂フロー(承認→通知→反映)」を業務プロセスに組み込む
- ローカル編集は禁止。構成は変更リクエストで中央受付する運用に統一
総括:サービスBOMは「業務と設計の接着剤
これらの失敗は、いずれも「構成の責任主体が曖昧」「目的ごとの設計思想が混在」していることに起因します。
サービスBOMは、設計・製造・保守・流通を貫く「業務構造のハブ」です。
設計時点でルール化し、運用に落とし込むことが、
FTFR向上・誤出荷削減・保証対応スピードUP・CS満足度改善につながります。
FAQ
Q1. サービスBOMとMBOMの違いは?
サービスBOMは、保守・補修の現場作業のために再構成されたBOMです。
MBOM(製造BOM)は、製造工程で使う構成情報であり、主に組立順や使用治工具など製造視点が中心です。
観点 | MBOM | サービスBOM |
---|---|---|
主目的 | 製造工程の実行 | 保守・補修・部品手配の実行 |
粒度 | 作業・着座順 | LRU/SRU/CRUなど交換単位で分解 |
属性 | 工程順・置場・仕掛品 | 代替/互換/適用範囲/保証/価格 |
利用部門 | 製造/調達 | アフターサービス/コールセンター/修理部門など |
Q2. 旧番→新番に置き換えた後、保証はどう扱う?
保証判定は「製品に搭載されていた品番」または「交換時の代替関係」をもとに処理されます。
- 旧番で製品が出荷されていた場合でも、正しい継承ルール(代替チェーン)を管理していれば、
新番部品でも保証範囲内として適用できます。 - ただし、代替品が性能アップやコスト変更などを伴う場合は、保証対象を明確に再定義する必要があります。
運用のポイント:
FSMや保証DB上で、旧番→新番のマッピングをトレースできる構造(継承IDや履歴フラグ)を作ること。
Q3. シリアル効果と日付効果はどちらを優先?
原則として、シリアルNo.(S/N)による効果範囲の方が優先されます。
- 製品の組立順と構成を厳密に追跡するためには、S/Nベースでの構成適用(As-Built)が最も信頼性が高い。
- 一方、日付効果(例:2024年4月1日から有効)は、マーケティングや価格表などのタイムライン管理に有効です。
両方設定する場合のおすすめルール:
- S/N優先、日付は補助条件として設定
- 例)「S/N10001以降、かつ2024/04/01以降が対象」
Q4. 150%サービスBOMからモデル別100%をどう生成?
150%サービスBOMは、すべてのモデル・市場・オプションを包含する「バリアント統合構成」です。
この中から、個別モデルに適した100%構成を生成するには、フィルタ条件を使います。
フィルタ条件の例:
- モデルコード:AX120
- 地域:JP(100V)
- オプション:Wi-Fi搭載
- S/N範囲:10001〜15000
☑ 上記条件でフィルタ抽出された構成が、そのモデルの100%サービスBOMになります。
→ PLMやパーツカタログ上で自動生成できるよう、適用条件をマスタ化しておくことが重要です。
Q5. ECのパーツカタログと連携する最短手順は?
ECやeカタログとサービスBOMを連携するには、以下の5ステップが最短・実用的です:
- PLMで構成マスタを整備(代替/互換/適用などの属性含む)
- サービス品番に画像・イラスト・価格・保証区分を付与
- 中間データ(CSVやAPI)でパーツカタログ側に配信
- フィルタ条件ロジック(モデル/S/N/地域など)を実装
- 購入〜保証〜RMA連携までのシステムIFを構築
EC側はフロントで表示されるだけに、UI上の「適用品のみ表示」「代替候補表示」などの体験設計がCVRに直結します。
まとめ
要点の再確認
- サービスBOMは、保守・補修のために再編成された部品表。
- 代替・互換・適用・シリアルなど、サービス現場で必要な情報を明示的に保持する。
- EBOM/MBOMとは目的と構成が異なり、誤出荷・保証ミス・在庫トラブルを防ぐ。
次の一手:実務に活かすステップ
1. 設計チェックリストを確認する
サービスBOMに必要な属性(代替・互換・適用範囲・シリアル管理)を整理した
「サービスBOM設計チェックリスト(Excel)」をダウンロードして、現状のBOMと照合。
2. テンプレートで構成情報を整える
サービス品番・適用条件・保証情報を含む
サービスBOM構成テンプレート(表形式)で、すぐに運用に落とし込めるマスタ形式を確認。
3. カタログ設計の相談を検討する
現状のMBOMや設計情報をベースに、サービス部品としてどう分解・構成すべきか
社内ワークショップやカタログ連携設計の支援も可能。