例えば「鍵」。賃貸住宅のドアのキーです。お客様との契約前には内覧をしていただきますが、その為にはたくさんの鍵を管理し、社員がお客様に同行し、中を開けて説明し、他の部屋が見たいと言えば、では後日、と言って再び同じことを繰り返します。あるいは、契約書であるとか、預金口座自動振替依頼書であるとか、さまざまな「紙」が発生し、これをお客様との間でやり取りする過程で、封入コストや郵送コスト、管理・保管コストが発生します。
このような例が、私がいうところの「当たり前のムダ」です。言い方を変えると、他の業態と比べると相対的にムダに見えるものということになります。例えば、ネット証券会社を考えてみてください。ほとんどのオペレーションが電子的に済み、さまざまなリソースを多くの顧客でシュアしている業態は、うらやましいほど効率的です。しかし、「当たり前のムダ」がある中でも、より効率的なオペレーションは築いていけるはずです。
私は何とか「工場化」できないか？ と考えています。「IT化」ではなく「工場化」です。つまり、事務作業やデスクワークといわれる業務を、製造作業のような「性質」に変換できないか？ ということです。
では、「製造作業」と「デスクワーク」の違いは何でしょうか？ これを考える前に、ビジネス（あるいは、仕事、業務、作業）の構造を考えてみましょう。
- トリガー（業務の引き金） ： どんな業務でも、必ず開始されるきっかけがあります。それには「アイデアがひらめいた」とか、「仕事の依頼がきた」、「上司に指示された」、「期日がきた」などさまざまでしょう。
- ロール（業務の実施者と役割） ： 業務は人によって行われます。誰が、どんな役割で業務を行うのか？ これがロールです。IT化された業務では、システムがロールとなることもあるでしょう（ロールがシステムだったとしても、その処理内容は人が管理していますので、最終的にはすべての業務が人によって行われているということになります）。
- インプット（業務に必要なもの） ： 業務には何らかのインプットがあります。伝票や請求書、要件などです。また、業務の実施者の知識や経験、アイデアのような無形のものもあります。
- プロセス（業務の手順） ： 何を、どう処理していくかという業務の手順がプロセスです。「請求書の内容を確認し、支払管理システムから支払依頼書を発行し、経理に提出する」というようなものです。
- コントロール（業務の制御） ： 取り敢えず「制御」という日本語を充てていますが、管理、監督、統制など、Controlのいくつかの和訳に置き換えてもいいでしょう。プロセスには何らかのコントロールがあります。「上司の承認を受ける」とか「支払額は予算の範囲内」とか、「条件分岐」であったりします。
- アウトプット（業務の成果） ： プロセスによって生み出された成果となるものがアウトプットです。インプットと同様、アイデアなどの無形のものもあるでしょう。
これに対しデスクワークの一部は、不明確な役割分担のもと、品質レベルが不明確な成果物を、試行錯誤の連続によって行い、かつ、成果物や業務遂行レベルを定性的に捉えることが多く、作業全般を通じて見えにくくなっています。
上表のように、{ T,R,I,P,C,O }で比較してみましょう。
- ロール ： デスクワークでは責任と権限のバランスがとれていないケースがあります（責任だけは押しつけられるが、それを遂行するだけの権限がないなど）。
- インプットとプロセス ： 例えば新規事業を企画する、というような業務を行う時、インプットやプロセスは試行錯誤の連続によって行われます。「市場調査をやってみたけれど有用な情報を得られなかったから、競合他社の分析をしてみよう」というようなケースです。そうした試行錯誤の連続は、スピードや効率の低下要因となります。
- アウトプット ： 最も大きな違いがアウトプットです。製造作業のアウトプットには明確な品質レベルが測定可能な形で定義され、よって検証することができます。しかし、デスクワークのアウトプットの大部分はこの逆です。例えるなら、製造作業はX,Yの座標で弓を射る目標を定義しているのでズレを定量評価できますが、デスクワークは的のどこかに当たればいいというような曖昧な定義なので、定性的な評価しかできません。
性質変換によるデスクワークの工場化、理屈はこれでいいのかもしれませんが、では実践ではどのようなアプローチをすればいいのでしょうか？ これから具体的に検証していきたいと思います。
0 件のコメント:
コメントを投稿