機種が分かっても、
どの部品か分からない。

部品を特定すると聞くと、 最初はもっと単純な作業に見えます。

機種を確認する。

部品表を見る。

品番を出す。

それで終わりそうです。

でも実際には、 機種だけでは決まらないことがあります。

号機を見る。

仕様を見る。

パーツリストを見る。

必要なら、 別の情報も突き合わせる。

情報はある。
でも、答えが一か所にあるとは限らない。

まず見るのは機種です。

でも、 機種が同じだからといって すべて同じ構成とは限りません。

製造された時期が違う。

号機が違う。

仕様が違う。

途中で変更が入っている。

そうなると、 同じ機種でも 使われている部品が変わります。

「この機種だからこの部品」
だけでは決められない。

機種は入口です。

そこから、 号機や仕様まで見て 条件を絞っていきます。

品番は、 部品を識別するための番号です。

だったら、 同じ部品には 同じ品番が付いている。

最初は、 そういうものだと思っていました。

でも実際には、 製造や設計の中で 同じ部品でも 新しい品番が作られることがあります。

担当者ごとに 新しい品番を切る。

とりあえず 変区を入れる。

その結果、 実物としてはかなり近い部品でも 別の品番として存在します。

さらに、 形や名称がよく似た部品もあります。

でも、 品番が違えば 基本的には別部品として扱います。

似ている。
ほぼ同じに見える。
でも違う。

品番は整理するためにあるのに、 過去からの積み重ねによって 逆に判断を難しくすることもありました。

さらに難しいのが、 過去の製造時の事情です。

過去には、 工場で製造している途中に 必要な部品の在庫がない場合、 手元にある流用可能な部品を 使用することがありました。

また、 手元にある部品を その場で加工して 機種へ取り付けるケースもありました。

現在では、 こうした対応は禁止されています。

ただ、 過去にそのような形で製造された機種は 今も実際に稼働しています。

そのため、 製造設計上の構成と 実際に取り付けられている部品に 差異が残っているケースがあります。

今は行われていなくても、
過去の製造差異は実機に残っている。

BOMや設計情報を追えば、 本来取り付けられているはずの部品は分かります。

でも、 実際の機種を見ると その部品が付いていないことがあります。

当時であれば、 「この機種はこのとき別の部品を使った」 と事情を知っている人が いたのかもしれません。

でも、 何十年も経てば 当時の担当者はもういません。

記録にも残っていなければ、 誰かに確認することもできません。

設計情報が間違っているわけではない。
でも、実機が設計通りとは限らない。

こうなると、 正しい情報を順番に追えば 必ず答えにたどり着ける、 という前提そのものが崩れます。

そして、 こうした過去の差異が残っていても、 サービス側では対応を続けなければなりません。

サービス側は、 部品を特定できなかったからといって そこで対応を終えることはできません。

実機は存在している。

顧客はその機種を使っている。

修理や交換が必要になっている。

だから、 「該当する部品は存在しません」 だけでは済みません。

分からなくても、
使える状態まで持っていく必要がある。

設計情報と実物が合わない。

当時の担当者にも聞けない。

品番も追えない。

そういう場合は、 代替できる部品を探します。

かなりレアなケースですが、 クライアントに 実際についている部品の写真を送ってもらい、 形状を見ながら 類似する部品を探すこともあります。

その中から、 実機に収まりそうなものを 一つずつ確認します。

単品で置き換えるのが難しい場合は、 その部品を含む 親部品ごと購入してもらうこともあります。

正しい品番を探すだけではなく、
どうすれば修理できるかを探す。

頻繁にある話ではありません。

それでも、 年に数度は こうした対応が必要になることがあります。

品番体系の分かりづらさは、 部品特定だけの問題ではありません。

似た部品がある。

似た品番がある。

それを棚へ戻すときに 取り違えることがあります。

Aの棚に Bを入れてしまう。

その瞬間は 問題が見えなくても、 後でピッキングしたときに 違う部品が出てきます。

それが、 在庫差異につながることもあります。

品番の分かりづらさが、
現物のズレにつながる。

棚配置にも影響があります。

古い品番だから あまり出ないと思われて、 奥側に置かれている。

でも実際には、 古い品番でも よく受注される部品があります。

すると、 よく出る部品なのに 毎回奥まで取りに行くことになります。

古い品番だから、
出ない部品とは限らない。

品番というデータ上の問題が、 棚入れ、 在庫差異、 棚配置、 ピッキング距離まで つながっていました。

部品を特定するための情報が まったくないわけではありません。

機種。

号機。

仕様。

パーツリスト。

BOM。

品番。

それぞれはあります。

でも、 一つ見れば答えが出るとは限りません。

さらに古い機種では、 情報を全部追っても 実物と一致しないことがあります。

だから、 経験がある人ほど 見る場所が早くなります。

この機種なら、 まずここを見る。

この号機なら、 このあたりを疑う。

古い機種なら、 設計情報だけで決めつけない。

情報そのものより、
情報のつなぎ方が経験になっている。

これが、 部品特定の速さが 人によって変わる理由の一つでした。

品番の分かりづらさや、 過去の製造との差異は、 最終的にサービス側にも影響します。

部品特定に時間がかかる。

顧客から写真をもらって 現物を確認する。

代替品を探す。

場合によっては、 親部品ごとの交換を考える。

でも、 品番や製造側のルールを決めるのは サービス側ではありません。

製造や設計側で決められたものを、 サービス側が後から使います。

その中で、 サービス側から 「こうした方が分かりやすい」 「この状態だと後から困る」 と意見を出しても、 簡単には変わらないことがあります。

困る側と、
仕組みを決める側が違う。

実際に仕事をしていて、 製造や設計側に対して サービス側の立場が弱いと感じる場面もありました。

問題が見えていても、 意見がそのまま通るとは限りません。

そして、 残った問題に 後から対応するのはサービス側です。

最初は、 部品検索を速くすれば 改善できるようにも見えます。

でも、 実際に見えてきた問題は もっと広いものでした。

機種から部品を絞る。

号機や仕様を見る。

品番の違いを見る。

過去の製造差異も考える。

必要なら代替部品を探す。

正しい棚に戻す。

出庫頻度に合った場所へ置く。

そして、 現場で見つかった問題を 改善につなげる。

品番はデータの話。
でも、その影響は実機・現場・顧客・組織まで続いている。

だから、 「検索画面を作れば終わり」 ではありません。

情報の整理。

実物との対応関係。

サービス側が使える形での情報。

そして、 現場から上がった問題を 仕組みに戻せること。

そこまで見て初めて、 改善になると思うようになりました。