【BPM】プロセス記述をする際に意識すべきポイント5選【記述のポイントとその背景】

みなさん、こんにちわ。ここ最近、BPMという言葉が徐々にではありますが認知を集めてきているように感じています。

BPMとはどんなものなのか、といえばビジネスプロセスをマネジメントするということでなんとなくイメージが出来そうですが、そのBPMの中でも重要な取り組みがプロセスの可視化です。

現在行われている業務の流れを可視化するという意味でAs-Isのプロセス可視化を行うこともあれば、そうして整理した情報をもとにしてあるべき業務の姿、To-Beのプロセス可視化を行うこともあります。

いずれにおいても、プロセスを可視化する際、むやみやたらにフローを書き始めるということは推奨できません。

業務フロー、プロセスフロー、プロセスダイアグラム、またはスイムレーンなど、プロセスの可視化の際に活用される成果物は多岐にわたりますが、既存のフローやネットで検索できる参考フローを真似ることで確かにそれっぽい成果物を作ることは可能です。

しかしながら、フローを作るという作業を経て正確に業務を理解するためには、ただフローを書くだけでは十分とは言えません。本投稿では、フローを作るときに意識して頂きたいポイント５選と、なぜそのポイントが重要なのかをご紹介します。ご興味頂けましたらぜひお付き合いください。

Agenda

想定読者

プロセスフローを書く作業に携わる方々
業務改善の取り組みを進めておられる方々

得られるメリット

プロセスを記述する際のポイント、なぜそれが重要なのかがわかる
プロセスを記述する活動の品質を高めることが出来る

BPMで非常に重要な要素となるプロセス可視化

そもそも、BPMではなぜプロセス可視化が重要なのか、簡単にお話させて頂きます。

BPMとは、ビジネスプロセスマネジメントを指します。当然ながら、BPMという活動におけるマネジメントの対象はビジネスプロセスです。

マネジメントという言葉には、様々な意味があり、一般にイメージしやすい言葉としては管理という言葉が想起されるかと思いますが、語源をたどっていくと「何とかする」という意味になります。

つまり、ビジネスプロセスマネジメントとは、ビジネスプロセスの現状を理解し、管理下に置き、「何とかして」もっと良い姿にする、あるべき姿に変化させていく試みといえます。

こうした取り組みを進める際には、「何とかする」対象がそもそもどういったものなのか、という点が明確にされている必要があります。そのためのプロセス可視化です。

「この日本をより良くしていきたい」と言ったとしても、意気込み自体は素晴らしいと思いますが、内容があまりに漠然としていて、何を良くしていくつもりなのか、まったくイメージ出来ません。

より良くしていくことを志すのであれば、対象となるものが明確にされている必要があります。

BPMについて言えば、BPMが対象とするプロセスがきちんと可視化されていて、誰にでも理解できるように文書にもまとめられている、ということがスターティングポイントとなるのです。

何かしらの問題が発生している状況において、その問題が整理・定義され、文書化されれば、あとは解決するだけという状況になるため、問題の50％以上はすでに解決している、という考えがあります。これと同様に、プロセスの可視化が行われていれば、あとはどこをどう改善していけばいいのかを考えるだけとなるため、改善活動は50％完了していると表現することも出来るでしょう。

プロセス可視化をする際の基本方針5選＋可視化時のポイント5選

それではここから、プロセスを可視化する際のポイントを基本方針5つと可視化時のポイント5つをご紹介したいと思います。皆様が気になるポイントをご確認頂ければと思いますが、本投稿では可視化時のポイント5選を取り扱っております。基本方針５選についてはこちらにもまとめております。

それでは個別にみていきましょう。

始点と終点を明確化する

プロセスを記述する際、意識すべきポイントの１つ目は、始点と終点を明確化することです。始点と終点を明確化することで、何がこのプロセスを開始していて、何をもってこのプロセスは完了するという扱いになるのか、という点を理解することが出来るようになります。

プロセスの目的、存在意義の理解につながる

プロセスの始まりと終わりが理解できると、そもそもこのプロセスは一体何を目的として存在していて、どのような価値を提供するためにあるのか、という本質的な思考が可能となります。

そうすると、本質的にこのプロセスが提供すべき価値をもっとうまく発揮するには、効率的に提供するためにはどうすればいいのか、という視点も同様に得られるようになります。

一例として、発注のプロセスがあるとしましょう。

このプロセスは、生産部門によって計画された生産台数を達成するために必要となる発注数量が確定することで開始していきます。そして、発注したものが無事に入庫され、生産部門に手渡されることで区切りを迎えます。

ここからさらに深堀をしていくことで、この発注プロセスが満たすべきニーズは生産部門の「生産活動のために必要な部材が欲しいタイミングに欲しい量だけあってほしい」、「ただ数量があるだけではなく、品質の良い部材が欲しい」といったものであると理解できるのです。

決められた発注数量だけ発注するプロセスである、という理解に終始しているケースと比較すると、本質的な思考が可能となり、改善のアイデアも多く出ることになるでしょう。

インプット、アウトプットを明確化する

プロセスを記述する際、意識すべきポイントの2つ目は、インプットとアウトプットを明確化することです。プロセスとは、何かしらのインプットを得て、それを加工、あるいは付加価値をつけることでアウトプットを出力していくものとなります。各プロセスは目的を持ち、その目的を遂行する際にアウトプットを出力していると表現することが出来ますが、アウトプットを出力するためには当然ながらインプットが必要となります。

インプットとアウトプットの整合性が検証できる

少しプロセスの話から離れますが、AI、機械学習などのデータを多く活用する処理においては、「Garbage In, Garbage Out」という言葉あります。

これはつまり、ごみが入るとごみしか出てこない、という意味になります。

この言葉はプロセスにおいても同様で、インプットが適切なものでなければアウトプットも期待した内容にはなりません。あるいは、まったくアウトプットを出せないということも起こりえます。

プロセスを記述する際、その目的は意識されやすく、その目的遂行の方法でもあるアウトプットは焦点が当たりやすいためアウトプットをどう設計しようか、という議論は頻繁に行われるのですが、そもそも入ってくるインプットがアウトプットを出力するために適切かどうか、という点も同様に重要なポイントとなります。

こうした検討を進めるためには、まずプロセスのインプット、アウトプットを明確化することが必要となります。

購買発注のケースでいえば、購入する対象が決まらないともちろん購入は出来ませんので、品目の情報、希望納期の情報、必要な数量、納入先住所情報、等は必須になるでしょう。

こうしたインプットが明確化されていない状況において、とある担当者から「来週の半ばぐらいをめどに部材AAを10パレット分、持ってきてください。今週の残りはお休みを頂きますので、必ず発注をかけておいてください。」と言われたとしても、すぐに発注につなげることは出来ず、購買発注伝票の作成とサプライヤーへの送付、というアウトプットは出せません。

このような、プロセスが機能不全を起こすリスクを回避するためにもインプットとアウトプットの明確化は重要なポイントとなります。

アウトプットがプロセスの目的と合致しているかを検証できる

プロセスには目的があります。その目的と、プロセスが出力するアウトプットは整合しているのかを検証することは非常に重要です。

例えば、売上に関する定例確認会を行い、各事業部で売上の状況を確認しているとしましょう。

このプロセスのアウトプットは何でしょうか。会議終了後に関係者に共有される議事録でしょうか。それも正しいとは言えますが、議事録を出すことはこの会議の目的なのか、と考えると少々違う見方が出来そうです。

定例確認会の目的は、各事業部のメンバー間で売上の状況を共有し、現状の課題や、次の四半期で注力すべき案件の情報を共有し、ネクストアクションを合意し、確実に取り掛かることであるといえるでしょう。

そう考えると、このプロセスのアウトプットの一つは議事録ですが、成し遂げたいことはネクストアクションが明確化され、各事業部でアクションに取り掛かれる状況になることであり、議事録というよりも各事業部がとりかかるアクションプランである、と表現することが出来るのではないでしょうか。

なお、アウトプットというと、どうしても目に見える何か、紙に出力されたものや、資料、あるいは生産されたモノを連想してしまいがちですが、みんなの認識が合うこと、という状態を指すことも出来ます。

このように、インプットとアウトプットを明確にするという試みを通じて、プロセスそのものの機能不全を防ぎ、またプロセスの目的と合致したプロセスの設計が可能となります。

実行主体、関連アクターを整理する

プロセスを記述する際、意識すべきポイントの3つ目は、実行主体、関連アクターを明確化することです。

プロセスを整理する際、何を行うのか、という点に加えて重要となるのが、誰が行うのか、という点です。誰が、という部分を組織上の部門、あるいは役割として明確に整理を行うことが重要となります。プロセスを整理する際には、スイムレーンという図を用いますが、この図の中では水泳に用いるレーンのように左から右へと部門または役割ごとにレーンが引かれ、そのレーンの中にプロセスを構成する活動内容が記述されます。

この図の一番左に記載される部門、または役割がプロセスの実行主体となります。プロセスを整理する際、初めから終わりまでを整理しようとすると当然ながら自社だけではなく、他社などの組織外のアクターも記載する必要がありますが、その際はスイムレーンの枠を別に設ける形で、プールを別にして表現します。

責任の所在が明確化する

プロセスの実行主体、関連アクターを整理すると、まず各活動の責任の所在が明確化します。

誰が、何を行うのか、という点が明示されるため、プロセス実行上の問題があれば、それは誰の活動に問題があるのか、という点が追求しやすくなります。

これによって、この仕事は自分たちが実行しなければ次の工程に進まなくなってしまう、というある種の緊張感を生むことも出来、プロセスが知らない間に滞っている、ということをなくせる可能性があります。

なお、責任の所在が明確化するという表現をすると、何かをしなくてはならない、というネガティブな印象を持つ方もいるかもしれませんが、その責任の範囲内であれば自由に仕事を行ってよい、という側面もあります。

責任が明確化することによって、その責任を果たすために必要と考えられる行動を自発的にとることが出来るようになる、というポジティブな面もあることをご理解頂ければと思います。

責任・役割の定義とプロセスの目標・ゴールの整合性を検証できる

責任を明確化しようとする試みを進めると、今定義されている責任・役割の定義というものはそもそも正しいのか、という検証を行うことが出来るようになります。

プロセスにはそれぞれ、目標とゴールが存在します。

コールセンターの業務であれば、お客様からの問い合わせをスムーズにさばき、お客様の求める回答をする、あるいは解決策を提示する、そして次の実作業に進めていく、といった活動を通じてお客様が抱える問題を解決に向けて迅速に導いていくことが求められます。

仮に、コールセンターの担当者がお客様から問い合わせを頂いた後、技術的な内容に関しては技術部門の電話番号を案内して終える、という活動でプロセスが完了していたらどうでしょうか。

責任の範囲がこのように定義されていれば、その責任は果たしたといえるかもしれませんが、技術部門がお客様の問い合わせにきちんと対応をしているかは技術部門に丸投げとなります。また、技術部門は本来的には開発の企画を行い、新たな製品を作ることを役割として持っているのならば、お客様からの問い合わせの電話への対応の優先度が下がる可能性があります。

このように、プロセスを構成する各活動のつながりを整理し、それぞれを実行する主体の責任と役割の定義状況が、プロセス全体の目標・ゴールと整合した設計となっているか、という点を検証するためにも、実行主体、関連アクターを整理することは重要となるのです。

イベント、タスク、分岐条件を洗い出す

プロセスを記述する際、意識すべきポイントの4つ目は、イベント、タスク、分岐条件を明確化することです。

イベントはプロセスの始点または終点となるもので、タスクはプロセスを構成する活動を意味し、分岐条件はプロセスの枝分かれを表現します。

バリエーションの網羅が可能となる

これら3つの整理を行うと、プロセスのバリエーションを網羅的に記述することが出来ます。

プロセスフロー、ダイアグラム、またはスイムレーンといったものを用いてプロセスを記述する際には、バリエーションを意識することが重要となります。

例えば、とある製造業の購買プロセスを可視化する際、関係者から「まずは購買依頼が要求部門から提示され、それが承認されると購買部門で確認可能となり、購買発注が作られる。それを承認したら、サプライヤーさんへ発注伝票を送る」という発言が得られたとしましょう。これをステップにしてみると、購買依頼の作成、購買依頼の承認、購買発注の作成、購買発注の承認、サプライヤーへの発注伝票の送付、と整理することが出来そうです。

このスイムレーンを見て、これでプロセスのバリエーションは網羅されているのか、と考えるときに注目するポイントが、イベント、タスク、分岐条件です。

まずイベントから考えていきますと、在庫を補充したい、という要求部門の要望からスタートしているプロセスとしてこのスイムレーンが記述されていますが、他にもパターンはないかと考えると、営業部門がこのプロセスをスタートするケースがありそうです。

例えば、受注をした製品が年間であまり出荷される予定のないもので、サプライヤーから仕入れたものを直接お客様に対して送付するような仕入先直送と呼ばれるプロセスについては、購買のプロセスをスタートするのは営業部門の受注であり、また、最後のイベントは入荷ではなく、仕入れ先への直送につながるように整理しなおすことが必要となります。

次にタスクから見ていきますと、購買発注の作成と承認の前に、サプライヤーに見積もりを提示してもらうというステップが必要なときもあるな、と考えることも出来ます。

一方で、毎回見積を提示してもらうということも実際はしていないので、見積もりが必要になるケースとそうでないケースを分岐条件として定義したほうがいいのではないか、という風に具体化していくことも出来ます。

このように、イベント、タスク、分岐条件に着目することでプロセスのバリエーションを網羅的に整理することが出来ます。

属性情報を活用する

プロセスを記述する際、意識すべきポイントの5つ目は、属性情報の活用です。

プロセスを可視化していく活動のなかで、最終的に作り上げるものとしてイメージしやすいものはプロセスフロー、ダイアグラム、スイムレーンといった業務の流れとつながりが理解できるように作図された成果物でしょう。

しかしながら、こうしたものの中だけでは表現することが難しい要素というものもプロセスには存在します。こうしたものを無理に作図の中で表現しようとすると無駄な労力が発生しますし、あとで作図した成果物を眺めてみても理解が難しくなることが多いため、こうしたものは作図した成果物とは別に整理していく方針が有効となります。

具体的には、各業務の細かな手順を記したマニュアル、そもそも業務の目的、内部統制の観点でのリスクと対応するコントロールの詳細、またとある条件別に異なる処理を行うのであればその条件を整理したディシジョンテーブル、等があります。こうした要素を属性情報と表現し、プロセスフロー、ダイアグラム、スイムレーンに付与していくことで、作図した成果物を起点にプロセスのあらゆる情報をたどっていくことが可能となります。