システムを離れて、
実際の現場に入った。

それまでの自分は、 JavaやPython、 PLMやERPなど、 システムを作る側にいました。

仕様を見る。

コードを書く。

テストする。

動かす。

でも倉庫に入ると、 見る対象が変わりました。

物がどこに置かれているか。

作業者がどこを歩くか。

どこで手が止まるか。

どこが危ないか。

誰が何を分かっているか。

システムの中ではなく、
人と物の動きを見るようになった。

この経験が、 後に業務改善案を考えるときにも かなり効いてきました。

倉庫内の改善では、 いきなりITを使おうとはしません。

棚の置き方。

部品の配置。

作業者の動線。

危険な場所。

作業指示の伝わり方。

まずは、 現場そのものを見ます。

技術を使わなくても、
改善できることは普通にある。

この感覚は、 システム開発をしていた頃には あまり持っていませんでした。

倉庫業務を担当する中で、 部長から 業務改善案を出してほしい というミッションを受けました。

対象になったのは、 倉庫のピッキングや梱包ではありません。

問い合わせ対応や 受発注登録といった 事務側の業務です。

自分は、 その業務を普段から 主担当としてやっていたわけではありません。

ただ、 改善案を考えるために、 問い合わせ対応や 受発注の流れを軽く経験しました。

改善するなら、
まず実際の流れを見る。

そこで、 どこに手作業があるのか、 どこで人が判断しているのか、 どこを自動化できそうかを 整理していきました。

問い合わせから 受注登録までを見ると、 全部が同じ種類の作業ではありませんでした。

電話で聞く。

内容を記録する。

部品情報を探す。

条件を照合する。

回答を考える。

確定した内容を システムへ登録する。

聞く。
探す。
判断する。
入力する。

ここを分けて考えると、 全部を同じ技術で 自動化する必要はないと分かりました。

AIがあるから使う。

RPAがあるから使う。

それでは、 現場改善にならないと思いました。

まず、 どこで人が手を使っているのかを見る。

どこで情報を探しているのかを見る。

どこで判断しているのかを見る。

どこが単純入力なのかを見る。

業務を分けてから、
それぞれに合う技術を当てる。

その考えで、 一次受電、 検索・照合、 受注登録を 三段階に分けました。