タイヤ仕入れ、 電話なしで.
注文は作業シートに現れず、毎週静かに数時間を消費する作業の一つ: サイズを確認するために3つのポータルをチェックし、在庫のある業者に電話し、その後同じ情報を自社システムに入力する。
時間の実際の使い道
整備工場にタイヤ仕入れにかかる時間を尋ねると、通常は過小評価される。なぜなら、まとまった時間ではなく断片的に行われるからだ。
その断片は、仕入れ業者間の在庫確認、直接比較できない価格の比較、注文の発注、作業が来ることを知るための記録、到着しない場合の追跡である。それぞれは小さいが、合計は大きい。
もう一つのコストは中断である。注文は通常、他の作業の途中で行われるため、遅くなり、ミスが発生しやすい。
1つの可用性表示が3つのポータルに勝る
最大の節約は、早く注文することではなく、可能なことを知るために複数の場所を確認する必要がないことだ。
サプライヤーの可用性と価格が1つの画面に表示されると、決定は数秒で行え、最初に確認したポータルに基づくのではなく、完全な情報に基づいて行われる。同じサプライヤーからの注文を続ける静かな習慣も止まる。
その習慣は高くつく。優先サプライヤーはサービスと価格で地位を得ており、注文時に代替を見なければ評価できない。
サイズではなく、作業に基づいて注文する
ポータルでサイズとして注文すると、その存在理由と切り離され、再接続は後で誰かが手作業で行うことになる。
予約に基づいて注文を行うことで、作業は何がいつ来るかを把握でき、顧客には正直に伝えられ、納品書と日記を照合する必要がなくなる。納品が遅れた場合、影響を受ける作業は明確で、当日に発見するものではない。
これにより、利益が月単位ではなく作業単位で可視化され、実際に価格決定が行われるレベルになる。
関係を維持し、電話を減らす
自動化された注文が長年築いてきたサプライヤーとの関係を損なうことへの真剣な懸念がある。
実際、関係は信用条件、在庫が厳しいときの配分、問題が発生したときに誰かが応答することに関するものであり、これらはルーチンの電話注文には依存しない。標準品の自動注文でもすべてが維持される。
判断が必要な事柄、例えば異常な取り付け、緊急の作業、間違った納品については電話を残す。それらの会話は、週に40件のルーチンと競合しないときにより価値がある。
届いたものを確認し、注文したものだけではない。
注文と納品の間にお金が漏れる隙間があり、ほとんど確認されない。
- 当日に気づく短納品だが、クレジットされない。
- 仕事が必要だからと、静かに代替品を受け入れる。
- 同じ品目の見積もりと請求額の差異。
- 一つの仕入先からの繰り返しの遅延が、数値化されない。
- 返品が発生し、その後進まない。
どれも小さく、記憶に残らないからこそ続く。注文と受領の記録がパターンを明らかにし、そのパターンを仕入先に持っていく。
エージェントに繰り返し作業を任せる。
注文は繰り返しでルールに基づき、大量処理が必要なため、自動化に適しているが、判断には不向き。
エージェントは仕入先の在庫を確認し、好みのルールを適用し、定期的な注文を行い、人的対応が必要な例外をフラグ付けできる。決してすべきでないのは、どの仕入先との関係が重要かを決定したり、指定された品目の代替品を受け入れたりすること。
正しく設定されているかのテスト:定期的な注文が日常から消え、異常なケースは十分な文脈を持って誰かのデスクに届く。
よくある質問
タイヤの発注にはどれくらい時間がかかりますか?
ほとんどの整備工場が見積もるよりも多く、いくつかのポータルを確認し、価格を比較し、注文を出し、作業に対して記録し、遅延を追跡するという断片的な作業があるためです。中断コストは時間に加算されます。
自動発注は仕入先との関係を損ないますか?
通常はそうではありません。関係は信用条件、在庫が不足しているときの配分、問題が発生したときに誰かが応答することに依存しており、これらは電話でのルーチン発注には依存しません。判断が必要なケースのために電話を残すことで、より有用になります。
サイズではなく作業に対して注文する理由は?
サイズでの注文はその存在理由と切り離されているため、後で再接続する必要があります。予約に対して注文することで、遅延が影響を受けた作業に対して明らかになり、利益が作業ごとに可視化されます。
発注時にお金が漏れるのはどこですか?
発注と受領の間のギャップにあります:短納品がクレジットされない、静かな代替品、見積もりと請求書の価格差、そして定量化されない遅延です。それぞれは小さく記憶に残らないため、持続します。
発注時にエージェントがしてはいけないことは?
どの仕入先との関係が重要かを決定したり、正確な品目が指定された作業で代替品を受け入れたりしてはいけません。ルーチンでルールに基づく発注を処理し、例外を判断できるコンテキストを持つ人に渡すべきです。