業務改善や効率化のプロジェクト、システム開発のプロジェクトや要件定義・・・色んな局面で使われているのがこの「業務フロー」です。
業務フローは、レベルを揃えよう
プログラミングの設計図の１つであるフローチャートにも同じことがいえますが、記法が単純なことから、上手くレベル感を揃えて書くのが思いの外難しいです。「見積作成」と丸めて書く人もいれば「見積作成開始→顧客検索→新規顧客なら〜→作業原価をExcelで入力して集計〜」という作業レベルに落とし込んで書く方もいらっしゃいます。
業務フローで作業手順を細かく書いてしまうと全体が見えにくくなってしまうため、私はA4の横1枚にまとめることが出来る粒度で書くことにしています。当方が業務フローに求めるのは、作業手順ではないからです。
業務フローは全体を俯瞰するためのものであって、作業手順を記述するものではありません。
これが当方が作った業務フローです。これより細かくするのであれば、各々のタスクの内容を深掘りしていけるよう、レベル２の業務フローを作成すると良いでしょう。帳票出力の有無は記載するようにしています。システムを使っているのであればそれらも登場人物として別途抽出します。これぐらいの粒度感でざっくりと作りましょう。複雑なものをシンプルに見せる工夫が必要です。
業務の可視化で必要なのは、登場人物と情報の流れ
業務フローは業務手順を記述するものではなく、下記の情報を整理して大まかな作業の流れを掴む以外のことを盛り込まないほうが良いでしょう。細かく書こうと思えばいくらでも書けてしまいます。
- どんな作業を担当しているのか？」
- 何を受け取って、何を渡しているのか？」
- 業務上使っているシステムやソフト
これらがパッと見てわかることが重要です。手順を書きたくなったら負け、と思うぐらいで丁度よいと考えています。
業務判断は帳票から判断する
業務フローを精巧に作ってもわからないのが、業務上の判断基準です。菱形の四角を書いて「YES/NO」を書くことは出来ますが、判断をフローに盛り込んでしまうと、100％網羅しないと正確性に欠けてしまいます。そのため、当方は業務上の判断を業務フローに書くことはしておりません。
業務上のルールやどんな判断を下しているかについては、帳票やお使いのシステムの画面から判断します。帳票のサンプルと、お使いのシステムの画面キャプチャやマニュアルをご提供頂き、必要な時に質問させて頂きながら、この仕事が完了するために必要な情報と判断材料は何なのかを、検討していきます。
判断が必要になるのは、仕事を受け取る時と他の人に渡す時です。そこにフォーカスを当てて「この見積書をお客さんに出せると判断できるポイントはどこですか？ また、何が不適切でないと判断できますか？」 というような質問をして、本当に必要な情報は何なのか、現在のやり方で提供できていない情報はないか、情報の集約は出来ないか。そういったことを考えます。
業務上の例外事項の９割は、顧客の個別対応
「この顧客の場合にだけ発生する」「在庫がないときだけに発生する」「この時はAさんではなくBさんにお願いする」という例外事項の9割は、顧客の個別対応です。当方の言葉で言いますと、ローカルルールです。全てのビジネスには顧客がいますし、原則としてどの顧客も同じ道筋を通ります。顧客別にやり方を変えていたら会社が回らなくなってしまいます。ですが、先方にもルールがありますので、お手間を取らせないようにそのルールに従うべき所が当然あります。
当方は、そういった例外事項に対する判断基準については別途リストを作ってまとめています。IT活用を前提にする場合、これらを如何にITでルール化出来るかを考えるかによって、業務効率が大きく変わるからです。何を判断材料にして、作業が完了したことを決定づけることができるのかを、中心に精査を行います。
業務フローで全体の流れを掴み、業務判断を帳票と現行システムからあぶり出す。
それが当方のやり方です。ご参考になれば幸いです。