組織を機能させるために必要な3つのこと

「業務が属人化している…」という悩みを抱える経営者の方は多いかもしれません。 また、ある程度経験を積んだビジネスパーソンが「新しいことに取り組みたいけど今までやっていた仕事がいっぱいでなかなか手が出せない…」と思っていることもあるかもしれません。

いずれも「個人が対応することが慣例となっている業務を組織的に回せるようにフレームワーク化したい」というケースです。今回はそのために必要なプロセスを考えてみたいと思います。

(1)一般化

今あるタスクではどんな時にどんなことをしているか、顧客ごとにどう対応するか、社内の各職場向けの情報はどうやって作るかなど、個人のノウハウになっている情報はたくさんあると思います。それらを一つ一つ棚卸しして、状況別に仕分けます。ここは各個人の作業になりますが、ここである程度状況ごとに分類します。

例えば ある商品の 受注から発送までを行う作業があるとします。受注するルートはWebサイト、電話、小売店からのパターンがあるとします。Webと電話は個人への小売り、小売店の場合は小売店A社と小売店B社への卸販売だとすると、作業完了までに必要なタスクの並び方から4パターンの作業があることになります。

ここで仮に個人からの発注の場合は入金を確認出来てから発送するという条件にします。また取引が継続的にある法人の場合、請求は月でまとめている可能性もあるかもしれません。そうすると大きく流れは以下のようなものが想像できます。

1-a1. Web受注 → 在庫確認 → 入金確認 → 梱包 → 伝票作成 → 発送
1-b1. 電話受注 → 在庫確認 → 入金確認 → 梱包 → 伝票作成 → 発送 
1-c1. A社から受注 → 在庫確認 → 梱包 → 伝票作成 → 発送 → 請求
1-d1. B社から受注 → 在庫確認 → 梱包 → 伝票作成 → 発送 → 請求 

ここでの仕分け作業は、実際にタスクにあたる時にタスクの条件と照らし合わせて今後の対応の場合分けをする際に必要な情報となります。

その仕分け作業が済んだら、それらの中から固有名詞や特定の商品名や限定される条件を取り除きます。それによって一回り大きな情報で整理されます。例えば上の例で言うと、「A社から受注」「B社から受注」は卸売りという行為にまとまりますし、Webと電話は個人からの受注として扱うことになるかもしれません。

それらをまとめ直すと以下のように2パターンの業務フローがあることになります。

1-a2. 個人から受注 → 在庫確認 → 入金確認 → 梱包 → 伝票作成 → 発送
1-b2. 卸販売の受注 → 在庫確認 → 梱包 → 伝票作成 → 発送 → 請求

もしここでWebや電話での受注の仕方に更に細かいルーチンワークがあったりする場合は、個人向けとまとめずに別で分けたままパターンを考えた方がいいかもしれません。それはタスクの内容と実施状況によります。

この作業のパターンが作業工程（作業プロセス）になります。

(2)標準化

続けて一般化した作業工程の中に存在するタスクに誰でもわかるようなスタートとゴールを作ってタスクの標準的な処理の方法を作ります。

上記の例の中の「在庫確認」というタスクを見てみましょう。在庫確認は受注した数量が現在在庫として保有しているか確認する行為です。在庫を確認し、発送する数量をピックアップすることが在庫確認のタスクになると思います。

2-a. 在庫を保管している倉庫に行く
2-b. 該当する商品の棚の数量を確認する
2-c. 必要な数量の商品をピックアップする

しかし、在庫確認の際に発生する行為はそれだけでしょうか。仮に商品が発送するのに必要な数量なかったら購入品であれば取り寄せる、自社で作っているものなら工場で生産する必要があります。ということは2-b1で数量を確認した結果によって2-cが2つに分かれることになります。

2-a. 在庫を保管している倉庫に行く
2-b. 該当する商品の棚の数量を確認する
2-c1. 必要な数量の商品をピックアップする

2-c2. 数量が不足する場合は発注（生産指示）処理をする

更に2-c2には続きがあります。出来上がった製品が倉庫に納品されるのを待たなければいけません。この場合、発注したお客様にはお待ち頂く事になります（ここではWebや電話で受けた個人のお客様の注文ですから、Web上の注意事項や電話口などで在庫状況によりお待ち頂く旨をお伝えするようにします）。

その場合、発注した商品の入荷、倉庫への入庫（在庫数量が復活）が行われ、その上で必要な数量のピックアップが可能になり、梱包と発送処理の工程へと進みます。

2-a. 在庫を保管している倉庫に行く
2-b. 該当する商品の棚の数量を確認する
2-c1. 必要な数量の商品をピックアップする

2-c2. 数量が不足する場合は発注（生産指示）処理をする
2-d2. 商品入荷の報告を受ける
2-e2. 商品を倉庫に納める（在庫が復活する）
2-f2. 必要な数量の商品をピックアップする

このように作業を標準化する過程ではだれでもわかるような説明の仕方で、タスクの処理中に発生する可能性があるイベントについて条件分岐を作成します。

その各条件に対してゴールを設定します。ある作業プロセスの中に存在するタスクなので、分岐してもゴールは同じところに 戻ることは多いですが、そうではないケースが発生する可能性がないか注意して検討する必要があります。

そうではないケースの典型的な例は、倉庫に在庫していたはずの商品の扱いが終了していた場合などです。その場合はお客様から受注する前に受注窓口をクローズします。すでに受注した後にその注文に応じることが不可能であることが発覚した場合は速やかにお客様に連絡した上でクローズと返金処理をしますので、商品のライフサイクルと販売期間終了時の取り扱いなども検討しておくべきでしょう。

(3)明文化

ここまで検討して明らかにした作業の内容は口頭での周知で終わらせてはいけません。全体を通して作業プロセスを記載した作業工程表、各タスクの内容と判断基準を明記した作業手順書、手順通りに実施していることを継続管理するための管理表や管理チェックシートを作成します。それらを作ったら、それらの帳票類の適用範囲と保存期間を決めておきます。

【作業工程表】
ある作業がどのようなタスクで構成されているかわかるように記載した表。その作業が何のためにあり、何をトリガーにしてスタートし、何ができていれば終了なのか明示する。各タスクはどの作業手順書を見ればできるのかがわかるように、作業を構成するタスクに対応する作業手順書の書類番号を記載する。

【作業手順書】
作業の中の各タスクで必要な行動や処理、判断が必要な場合の判断基準などが分かるように記載する。各タスクの開始条件や終了条件も明示する。判断基準にない状況が発生した場合の報告先を記載して、非常時対応が可能な状態にしておく。
作業手順書は写真や図などを含めてわかりやすくし、説明は手順を追って箇条書きにする。判断基準は複合して発生しない条件が望ましいが、どうしても複合してしまう場合は、判断基準に対しても場合分けをして条件が分かるようにする。

【管理表、管理チェックシート】
タスクを実行する中で継続的に確認しなければいけないこと（上記の例では在庫の数量など）はタスクを実行するたびに確認し、確認結果を表やチェックシートなどにして残す。在庫の数量でいえば発注日と発注数量を管理すれば在庫を消化する期間の把握ができる。

これらを実施しておくことで、担当者が変わった場合やメンバーが追加された場合に経験者が帯同する時間を短くすることができたり、判断を間違うケースが限定されたりします。

また明文化して残す際には必ずその職場のベテラン職員の意見を求めたり、その方の仕事の仕方を取り入れることを検討すべきです。なぜならベテランの業務にはその作業を行う中で積み重ねた工夫や、身体に染み付いたカンやコツが含まれているからで、それらは必ずその方と会社にとって付加価値になっているはずだからです。

付加価値を生むことができる条件を他のメンバーにも共有することが組織として付加価値を生み出す可能性を引き上げます。

この3つの作業を日常業務を行いながら実施することはかなり困難ではありますが、価値を継続的に生むためには不可欠なことですので、少しずつでも推進することをお勧めします。