電話・FAXで、
仕事が止まる。

すべての注文を 人が一件ずつ入力しているわけではありません。

クライアントが 注文ページから必要な情報を入力して 正しくオーダーすれば、 そのまま受注登録まで進みます。

支店から入る注文も、 基本的には同じです。

標準の流れに乗る注文は、
すでにかなり整理されている。

業務を見ていて負荷が大きいと感じたのは、 そこから外れた案件でした。

問い合わせや受発注の業務は、 一つの情報だけを見れば 終わるものではありません。

部品を確認する。

条件を見る。

別の情報と照らす。

必要な内容を判断する。

そうした作業をしている途中でも、 電話は入ってきます。

電話が鳴れば、 いったん今の作業を止めて 問い合わせ対応へ切り替えます。

対応が終われば、 また元の作業へ戻ります。

電話対応そのものだけでなく、
作業が途中で切れることにも負荷がある。

どこまで確認していたのか。

次に何を見ようとしていたのか。

そこを思い出しながら 作業を再開します。

FAXは、 電話と違って 内容が紙として残ります。

ただ、 届いた内容だけで そのまま処理できるとは限りません。

品番が書かれていない。

機種しか分からない。

号機がない。

部品名が曖昧。

数量や条件の確認が必要。

必要な情報が足りないことも 多々あります。

紙に残っていることと、
処理に必要な情報が揃っていることは別。

情報が足りなければ、 調べたり、 必要に応じて確認したりして 足りない部分を補います。

電話やFAXで 情報が入ってきても、 内容によっては そのまま進められません。

この部品で合っているのか。

この機種に使うものなのか。

数量や条件に問題はないのか。

内容に不足や矛盾はないのか。

必要に応じて 部品情報や過去の情報を確認します。

登録の前に、
「この内容で進めていいか」の判断がある。

ここは、 単純な入力作業とは 分けて考える必要があります。

注文自体は 問題なく入っていても、 その後に話が変わることがあります。

たとえば、 支店から注文が入った後に 指定工場から追加の要望が出る。

その内容が 支店を経由して こちらへ回ってくることがあります。

また、 支店側から 標準の流れでは処理しづらい依頼が 来ることもあります。

そうなると、 すでに入っている注文だけを見ても 処理できません。

何を求められているのか。

その対応が可能なのか。

何を確認する必要があるのか。

人が状況を整理して 対応することになります。

標準処理は流れる。
例外になると、人の仕事が一気に増える。

例外案件では、注文内容だけを見ても判断できないことがあります。

基幹システム、設計図面、パーツリストなど、必要に応じて確認先を変えながら情報を追います。

ここで必要なのは、すべての情報を詳しく調べることではなく、その案件を進めるために何を確認すべきかを見極めることです。

例外対応では、
必要な情報を探す工程も増える。

この業務を見て、 全部を同じ方法で 自動化するのは違うと思いました。

標準の注文は、 すでにそのまま受注登録まで進みます。

一方で、 情報不足や例外案件では 人の確認や判断が必要になります。

だから、 改善するなら まず業務を分ける必要があります。

最初の問い合わせを受けるところ。

情報を整理するところ。

部品を検索・照合するところ。

内容が確定した後の登録。

人が判断するところと、
機械に任せられるところを分ける。

一次受電は AIボイスボットで受ける。

部品情報の検索や照合は 別の仕組みで支援する。

人が確認して内容が確定した後は、 必要に応じて RPAで登録する。

標準処理を作り直すのではなく、 人に寄っている部分を 少しずつ減らす考え方です。