今回は、例外処理への対応について述べていきたいと思います。

例外処理というのは、プログラミング用語で、通常ではないことが起きたときに実施する処理のことを言います。

反復継続的なロワーマネジメント業務は、プログラミングのようなITの世界の考え方が非常に参考になります。

仕事において、通常ではないことが起きた場合、あらかじめ決めておいたマニュアルや手順書通りには処理できないということになります。

ここでポイントとなるのが、その通常出ないことというのが

• ①想定されていた
• ②想定されていなかった

かです。

①の場合、想定されていたわけなので、その対応をあらかじめ企画しておくことが可能になります。

書類の処理で例を挙げると、当社仕様の注文書で発注を受けるというのが通常のオペレーションだったところ、顧客が自社仕様の注文書で注文してきた場合、どうすればよいでしょうか？

大きな会社であれば、注文先に送る注文書のフォーマットも自分たちの仕様で作って送付してくるところが多いと思います。つまり、こうしたケースは十分に想定されるわけです。

そこで、当社仕様ではない注文書を受け取った場合の処理の仕方をあらかじめ定めておくということができます。社内管理用の注文番号は、当社仕様であればあらかじめ書類にナンバリングされていますが、相手仕様であれば番号はないので、新たに番号を取り直すということになり、そのルールを作っておくということになります。

A-No.12345678というのが社内注文書のナンバリングであれば、顧客フォーマットの注文書の場合は、B-No.12345678という風なイメージです。

一方で、自社が想定していなかったような場面に出くわした場合は、どうすべきでしょうか？これは何らかの意思決定が必要になります。
一般のオペレーターレベルでは対処できないことも多いでしょう。

しかし、想定していなかったとしても、想定していなかった事態が起きた際の意思決定を誰がどのように行うかというのはルール化できます。
このルールを定めておくことが重要になります。

そうしなければ、誰もその処理をどうするのかがわからず、処理が進まない、スピードが遅くなり、お客様などに迷惑をかけてしまうことになります。
最悪の場合、担当者がそうしたことが発生したという情報事態を握りつぶしてしまう可能性もあります。

仕組み化するというのは、すべての事象を網羅的にもれなく対応できるルールを作り、特定の人に依存せずに実施できるようにするということなので、想定外の事態に誰が対応するかを決めておくこともまた仕組み化と言えるのです。

通常は事態の重要度によって、そのレベルの責任者が対応するかを決めることになります。

ここで問題になるのが、あまりにもこうした例外処理が多くなってしまうケースです。
例外処理はすべて上司が行うということになってしまえば、上司は結局ロワーオペレーションだけを行うことになり、本当に重要なマネジメントがないがしろになってしまうということになりかねません。

これでは本末転倒です。

そこで、想定外だと思っていた仕事を良く分析し、実は定型化できるものがあるのではないか？という視点で考えることが必要です。

冒頭で述べたプログラミングの世界では、良いプログラムというのは、短いコードであらゆる処理が問題なく行われるものだと言われます。

例外処理がたくさんあるプログラムは、長ったらしいものになり、処理装置にも負荷をかけることになります。
プログラムの修正作業も大変です。

例外処理の中に同質性を見出し、それを単一のプログラムの中で処理できるようにひとくくりにしてあげることが、プログラムをシンプルにする秘訣となります。

これと同じことを仕事の中でも考えて、一つにまとめ統合するということが必要です。
仕事の改善の仕方で、この例外処理を規格化して例外ではなくするということは非常に重要だと思います。

次回は、仕組み化の最重要工程であるマニュアル化について考えていきたいと思います。
以上、お読みいただきありがとうございます。