データはある。
でも、そのままでは答えにならない。

問い合わせ対応で 部品を調べるとき、 必要な情報が まったく存在しないわけではありません。

基幹システムにも データがあります。

設計図面もあります。

パーツリストもあります。

でも、 どこか一つを見れば そのまま答えが出るわけではありません。

データはある。
でも、サービス側が使いやすい形に
整理されているとは限らない。

部品を調べるとき、 機種だけを見れば 終わるとは限りません。

号機。

仕様。

品番。

どの情報を見ればいいのかは、 案件によって変わります。

さらに、 一つの機種でも 条件によって使われている部品が 違うことがあります。

「機種を検索すれば部品が出る」
というほど単純ではない。

システムにデータが入っていても、 そのデータをどう読むかが 必要になります。

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

でも実際には、 品番そのものを見れば すぐ判断できるとは限りません。

同じように見える部品でも 別の品番になっていることがあります。

過去から積み重なった 品番や変更の情報もあります。

そのため、 単純に文字列を検索して 一件見つかったら終わり、 とはなりません。

品番は識別子。
でも、業務上の答えそのものではない。

品番の背景まで見ないと、 判断できないことがあります。

さらに、 データだけでは判断できないケースもあります。

古い機種では、 設計上の構成と 実際についている部品に 差異が残っていることがあります。

そうなると、 図面やパーツリストを見ても 実機と一致しません。

データが間違っている、 という単純な話でもありません。

過去の製造時の事情が 実機側に残っているケースがあります。

正しいデータを見ても、
現物の答えが出ないことがある。

ここまで来ると、 システム検索だけで 解決するのは難しくなります。

問い合わせ内容を確認するときは、 複数の情報源を見ることがあります。

基幹システム。

設計図面。

パーツリスト。

それぞれに 必要な情報があります。

一つを見て分からなければ、 別の情報を確認する。

そこで分かった内容をもとに、 また別の情報を見る。

情報がないわけではない。
必要な情報が、いろいろな場所に分かれている。

一件の問い合わせでも、 複数の情報をつなぎ合わせて 答えを作る必要があります。

サービス側で 問い合わせに対応するとき、 知りたいことは データベースの中身そのものではありません。

この機種。

この号機。

この問い合わせ内容。

それに対して、 今どの部品を案内できるのか。

必要なのは、 最終的にはそこです。

データを探したいのではなく、
問い合わせに対する答えを知りたい。

でも、 その答えが 一つの画面や一つの項目として 用意されているわけではありません。

複数の情報を見て、 人が判断して 答えに近づけていきます。

ここまで見ていくと、 問題は 「システムにデータがない」 ことではありませんでした。

データはある。

でも複雑。

情報源も分かれている。

実機との差異が残っていることもある。

そのため、 データから問い合わせの答えまで 人が間を埋めています。

足りないのはデータではなく、
データから答えまでをつなぐ仕組みだった。

だから改善を考えるときも、 基幹システムを全部作り直すことより、 必要な情報をどう探し、 どうつなぎ、 どう候補として出すか。

そこを考える方が 現実的だと思いました。