フレームワークの基本 プロセスマップ
タイムラインのところで説明したように、複数の出来事が連続して起きる場合
に、時系列に並べてみるのは重要だが、この方法では、それぞれの出来事の
順序関係や因果関係はわからない。
そこで、それぞれの出来事を分解して、それぞれ別の「箱」に入れてみる。
次に、それぞれの順序関係や因果関係を線で結ぶ。
例えば、受注から出荷の業務を分析するとする。
営業が、「受注する。」のを1日目として、その日のうちに「出荷指図を倉庫
に送る。」ことになり、次の日に、倉庫が「商品を出荷する。」とすると、
タイムラインでは、
１日目 「受注する。」 営業
「出荷指図を倉庫に送る。」 営業
２日目 「商品を出荷する。」 倉庫
とまとめられる。
プロセスマップだと、
「受注」⇒「出荷指図」⇒「出荷」
となるわけだ。
この場合、受注しない限り、出荷指図はなされないことは明確だし、それが
ないと、たとえ受注していても、出荷されないことが明確にわかる。
タイムラインだと、そこまではわからない。このような単純な例であれば、
ともかく、実際はもっとずっと複雑で入り組んでいるうえ、余分なものが
入ってくるので、それを整理することがタイムラインではできないのだ。
さらに言うと、上記のプロセスマップを分析していると次のような疑問が
わいてくる。
・在庫を確認せずに出荷指示をいきなり出すのだろうか？
・出荷指示を受けたとき、欠品していたら、倉庫はどうするのだろうか？
・その日のうちに出荷する場合はどうするのだろうか？それともその
ようなことは起こらないのか？
このようなことを調べていくと、いろいろな例外の扱いとかが明らかに
なってくるし、いろいろな作業手順や規則の意味が明らかになってくる。
こういったことは、タイムラインでは分析できないし、表すことが難しい。
よく、「「業務フロー」と「プロセスマップ」はどう違うのか？」という
質問をうけるが、あまり気にする必要はないだろう。書き方のお作法がいろ
いろあって、名前も違うものがついているが、やりたいことは、業務の流れ
の順番や因果関係を図示することになる。
このときに、その業務を実行する部署で、上下に書き分けたり、「箱」の
色やアイコンをシステムと手作業で書き分けたりといった工夫を目的に応じて
おこなうと、見やすくなる。
ポイントは、プロセスマップを書くこと自体ではなく、それを使って、業務
を分析することにある。
例えば、業務の引継ぎをするときに困ったりした経験はないだろうか？
「最初に○○帳票のコピーを××課からもらってきて」「次は、それをこの
表に転記して」「それで、○○伝票の控えがあるからそれと照合して、」
「それが終わったら、まとめて、課長の印鑑をもらってから、△△課に持って
いくの。」とかいわれて、目を白黒したりしたことはないだろうか。
このようなことは、業務の流れをプロセスマップで図示していれば、前後関係
も明確なので、説明しやすい。
複雑な前後関係がある場合や、複数の部門を巻き込んで行われる業務の流れを
明らかにするのには、最も重要な分析手法だ。
ちなみに、このように強力なプロセスマップだが、欠点は、「時間の経過が
わかりにくい。」ことにある。タイムラインと併用するとより効果的だ。