第十五話「他責の念」
定期的に購入される商品の販売会社で、受注・配達業務での返品問題に悩まされておりました。返品問題は1か月約500件発生しており、これに関連するコストもばかにならないものでした。社長の強い意志で、これを削減するようにとの命令が上記担当部門に発せられました。大キャンペーンを始めて、しっかりした全社共通の基準に基ずく統計資料も整理され、地域ごとの成果検討会も開かれるようになりました。3か月もすると、大した根本的な対策も打っていないのに、会社側の自責による件数が2割ほど減少しました。

もう、賢明な読者の方々はおわかりでしょう。

そうです。返品という現象は受注・配達部門だけの責任で処理できるものばかりではありません。この手の問題は担当者にがんばれと命じただけでは根本的な解決には至りません。このゲームには、お客という外部の参加者がいるからです。そこで公平にデータを処理するためには、この部門の責任で発生した返品と、それ以外のものを明確に分離する必要があります。自分たちがアクションをとれない原因に対する責任を追求されても困るからです。ただし、こうすることで自責他責を区別をするための判断が必要ですし、自責か他責かが不明確なものは他責として分類されてしまう傾向が強くなります。まさに、このようなことに時間と才能を使うことは、効率的なことではありませんが、責任部門にすれば自分を守るためには、極めて重要なことです。

これが、私のいう管理問題アプローチです。この種のアプローチでは関係者が気合いを入れて、失敗をしないように努力します。それでも人間ですから間違いをします。人間は必ず間違いをします。だから人間なのです。最後は個人間のミスの比較をすることになるかもしれません。このやり方の延長上には答はありません。統計データからは問題点は見つかりますが、問題は見えてきません。問題は現場に落ちているのです。現象が起きて完結して、統計データになってからでは、統計の精度の問題と誰が悪いのかの問題が残るだけです。恐らく統計データを前に会議をしている人達が思いつく改善策は効果がないものが多いでしょう。

この問題を改善問題として作り替えるにはどうしたらよいでしょうか。問題は空間と時間と価値観で出来ています。これを替えてみましょう。

現在考えている空間は、受注・配達部門で処理できる範囲です。従って、自責他責の分離はこの部門から見た視点で分離されます。数量の間違いや品種の間違いなどはそのお客が日頃注文しているものと、明らかに違えば、お客の責任と言うよりは、受けた側の責任だといわれても仕方ありません。つまり、お客の側に立って、考えた場合は当然責任の区分は変わるでしょう。問題の所有者は受注・配達部門としても、情報システム部門や、営業部門などは関係部門としてプロジェクトに参加してもらうべきでしょう。本当を言えば、社長以下全員参加が望ましいところです。

時間について考えましょう。受注・配達部門が一つの注文を処理するために許された時間があります。それは、仕事量を人数で割ったものとして出てくるでしょう。客先でちょっとしたミスを見つけても、時間的余裕がなかったり、他部門の協力がえられなければ、みすみすその場での処理が可能でも返品として処理されます。仮に数量が間違って多すぎたとしても、どうせいずれは使うのだから、取りあえず受け取ってもらって、請求の仕方でお客の了解を得ることも可能です。そのためには、余分な時間が掛かります。改善問題アプローチでは現場での処理に必要な時間的余裕を与えることにします。

価値観は特に重要です。現在は返品のために掛かっている余分なコストを削減したいという価値が採用されています。その前提として、人間は努力をすれば、間違いをゼロに近づけるだけ減らせるという価値観が存在します。上記の価値観で対策を講じても、もぐらたたきになってしまい、歯止めがきかずに同じ事の繰り返しになり、最後にはこのテーマはいろいろやったが難しい、という理由で忘れ去られるでしょう。少なくとも、社長さんが交代した瞬間に無くなる可能性があります。本気でこの問題に取り組むなら、価値観は「お客の満足」でゆくべきです。そしてコストは忘れるべきです。すくなくとも、短期的にはコストが上がるかもしれませんが、長期的には副次的効果も考えられ、コストも下がると思われます。人間は間違いをするのが当たり前であるとする価値観の下では問題は違って定義され、解決策も違ったものがでてくるはずです。

このように問題を作り替えると、改善策にはどのような違いがでてくるかを考えてみましょう。まず、自責他責という考えは本質的でないので止めます。全部自責です。また、打つべき手をオンゴーイングなアクションと究極的なアクションに分けて考えることにします。まず、オンゴーイングなアクションによって、当面の問題を処理し、そこで処理できない問題を煮詰めて究極的なシステム問題として、長期的に解決するという考えです。

オンゴーイングなアクションとしては、現場の人達がミスを見つけたら、返品になってしまう前にできるだけの処理をして、返品を無くすための意識的な努力をします。例えば、倉庫でオーダーピッキングをしている人が「このお客はいつもこんなに多くの量(あるいは品種)を注文していない」と気がついたら積極的にアラームを上げる。そして、そのことを返品報告と同じフォームで報告する。返品を出して怒られるなら、それを未然に止めたなら褒められても良いはずです。その中から改善案が生まれるかもしれません。目前のコストだけでを攻撃目標にすると、失敗を数えて、成功を数えなくなります。成功を褒めて、失敗を問題解決の種にすればよいのです。

また、配達現場でミスが発見されたら、その場で担当部署に連絡して、アクションを取るように努力します。ミスが統計データとして上がって来るまで誰も気が付かないのではなく、ミスが発見された時にベストのアクションを取ろうとするのです。そのためには余分な時間がかかりますし、他部門の協力が必要です。これがうまくゆかないところがあれば、そこに究極的なアクションの必要性が見えてきます。

究極的なアクションは、人間のする間違いをどのようにして機械的に補正するかにありあます。例えば、発注時の、お客や受注者の間違いは、お客の過去の発注トレンドを基にチェックすることで、発見できることが多いものです。当然この場合は間違いであるかどうかを相手に確認する作業が生じますが、コンピュータを使えば、それも自動化できます。新商品がでるとその特性が(お客と担当者の両方によって)理解されず、受注上のミスが起こるとすれば、そのミスを無くすための新製品情報をインターネット上に用意するこもできます。これらのために情報システム部門の協力が必要です。

このような考えで問題解決をする姿勢は必ずお客様の知るところとなり、良い印象を与えます。顧客満足度を向上させようとする会社の姿勢を顧客に知ってもらえます。受注ミスを無くすための情報システムのような究極的なアクションが実現すれば、返品の減少につながりコストも下がります。

このような問題は、ここに挙げた例意外にも多くあります。例えば工場での事故件数やチョコ停回数、不良率、なども、常に下がり続けている(あるいは上がり続ける)グラフを見ると信じられないことがあります。そんな時に現場の責任者にソット聞くと「ちょっとばかり言葉の定義を変えただけです」と言われ、妙に納得することがあります。

戻る