みなさん、こんにちわ。ここ最近、BPMという言葉が徐々にではありますが認知を集めてきているように感じています。
BPMとはどんなものなのか、といえばビジネスプロセスをマネジメントするということでなんとなくイメージが出来そうですが、そのBPMの中でも重要な取り組みがプロセスの可視化です。
現在行われている業務の流れを可視化するという意味でAs-Isのプロセス可視化を行うこともあれば、そうして整理した情報をもとにしてあるべき業務の姿、To-Beのプロセス可視化を行うこともあります。
いずれにおいても、プロセスを可視化する際、むやみやたらにフローを書き始めるということは推奨できません。
業務フロー、プロセスフロー、プロセスダイアグラム、またはスイムレーンなど、プロセスの可視化の際に活用される成果物は多岐にわたりますが、既存のフローやネットで検索できる参考フローを真似ることで確かにそれっぽい成果物を作ることは可能です。
しかしながら、フローを作るという作業を経て正確に業務を理解するためには、ただフローを書くだけでは十分とは言えません。
本投稿では、単純にフローを作って終わりにせず、本当の意味で業務を理解するために必要なプロセス可視化のポイントを5選、ご紹介します。ご興味頂けましたらぜひお付き合いください。
Agenda
想定読者
- プロセスフローを書く作業に携わる方々
- 業務改善の取り組みを進めておられる方々
得られるメリット
- プロセス可視化のポイント、なぜそれが重要なのかがわかる
- プロセス可視化の活動の品質を高めることが出来る
BPMで非常に重要な要素となるプロセス可視化
そもそも、BPMではなぜプロセス可視化が重要なのか、簡単にお話させて頂きます。
BPMとは、ビジネスプロセスマネジメントを指します。当然ながら、BPMという活動におけるマネジメントの対象はビジネスプロセスです。
マネジメントという言葉には、様々な意味があり、一般にイメージしやすい言葉としては管理という言葉が想起されるかと思いますが、語源をたどっていくと「何とかする」という意味になります。
つまり、ビジネスプロセスマネジメントとは、ビジネスプロセスの現状を理解し、管理下に置き、「何とかして」もっと良い姿にする、あるべき姿に変化させていく試みといえます。
こうした取り組みを進める際には、「何とかする」対象がそもそもどういったものなのか、という点が明確にされている必要があります。そのためのプロセス可視化です。
「この日本をより良くしていきたい」と言ったとしても、意気込み自体は素晴らしいと思いますが、内容があまりに漠然としていて、何を良くしていくつもりなのか、まったくイメージ出来ません。
より良くしていくことを志すのであれば、対象となるものが明確にされている必要があります。
BPMについて言えば、BPMが対象とするプロセスがきちんと可視化されていて、誰にでも理解できるように文書にもまとめられている、ということがスターティングポイントとなるのです。
何かしらの問題が発生している状況において、その問題が整理・定義され、文書化されれば、あとは解決するだけという状況になるため、問題の50％以上はすでに解決している、という考えがあります。これと同様に、プロセスの可視化が行われていれば、あとはどこをどう改善していけばいいのかを考えるだけとなるため、改善活動は50％完了していると表現することも出来るでしょう。
プロセス可視化をする際の基本方針5選＋可視化時のルール5選
それではここから、プロセスを可視化する際のポイントを基本方針5つと可視化時のポイント5つをご紹介したいと思います。
皆様が気になるポイントをご確認頂ければと思いますが、本投稿ではまずはプロセス可視化の際に大事にして頂きたいポイント5つを先にご紹介します。
それでは個別にみていきましょう。
経営者目線で整理する
1つ目の要素は経営者目線で整理するという点です。
プロセスの可視化というと、現場の業務の流れを正確に理解するために細かな粒度で整理するものであると思われる方が多いかと思いますが、そうした整理だけではなく、経営者の目線での整理は非常に重要となります。
経営者の目線で整理するというのはどういうことなのか、アウトプットのイメージを見て頂きましょう。
このように、自社の業務を棚卸し、一覧として見えるようにすることが経営者の目線でプロセスを整理するという活動となります。
企業の戦略とプロセスを整合させることが可能となる
プロセス可視化はBPMの一つの要素であり、プロセス可視化の目的はプロセスをより良くしていくことにあります。その際、何をもってより良いプロセスと判断するのかが重要な論点となりますが、これは企業の定める戦略や目標・ゴールとそのプロセスが合致しているかが重要となります。
こうした検討をするときには、業務を行う上での細かな作業がどのようにつながっているのか、という点が整理されたフローよりも、一覧で業務が可視化されたものの方が有効となります。
自社の来季の目標は顧客満足度を高めるということであるとしましょう。プロセスの棚卸をしてみると、サプライチェーンを含む調達、生産、販売はプロセスが明確に定義されている一方で、営業活動後のポストセールスのフェーズで業務がきちんと整理されていないことがわかりました。
これでは企業の目指す方向と現状のプロセスが乖離を起こしてしまいます。こうしたことが起こらないようにするため、経営者目線といったハイレベルでのプロセス可視化が必要なのです。
優先順位の決定、投資の分配検討に活用できる
企業が持つ資金や人材は有限です。したがって、当然ながらすべての活動は優先順位を持ちます。
BPMにおいては、自社が資金を投じてでも改善を進めるべきと考えるプロセスは一体どれなのか、あるいはそもそもBPMに取り組むべきプロセスはどれなのか、という点が整理されている必要があります。
例えば、サプライチェーンの改革をする、という活動が始まる際、需給調整、生産、購買といったどのプロセスにメスを入れるのが最も友好的なのか、という点を考えてから活動をすることになりますが、どこに集中的にリソースを投じるべきなのか、という点を検討する際にはやはり細かな作業のつながりを整理したフローよりもハイレベルにプロセスの棚卸を行ったものの方が有効となります。
End to Endで整理する
2つ目の要素はEnd to Endで整理するという点です。まず、End to Endでプロセスを可視化した際のアウトプットはどのようなものか、イメージを見て頂きましょう。
プロセスの可視化というと、このようなフローを思い浮かべる方が大半なのではないでしょうか。
プロセスというのは、複数のRoleや、組織を横断して行われます。したがって、特定の部門やRoleの仕事だけに着目して「自分たちがやっている仕事」などの限られた領域だけに絞って可視化しても全体が見えません。
したがって、プロセスを可視化するときはプロセスとプロセスのつながりを意識して前工程は何か、後工程は何かを明らかにするという点に注力し、始まりから終わりまでを整理することがポイントとなります。
Roleや組織の間で無駄・非効率を見つけることが出来る
誰も無駄なこと、非効率な仕事をしよう、とは思わないはずです。しかしながら、現実には無駄や非効率は多くの仕事の中で発生しており、そうした問題の多くはRoleや組織の間で見つかります。
修理サービス等を受け付けるコールセンターの仕事を例にとってみましょう。
このコールセンターはお客様から電話を頂き、必要な修理サービスの内容を整理します。その後、速やかに修理対応をするエンジニアに仕事を割り当てます。コールセンターの仕事はエンジニアに円滑に引き渡すこととして定義されており、コールセンターは自分たちの仕事は完璧にこなしたと胸を張っています。
エンジニアはコールセンターが整理してくれた修理サービスの内容を確認し、お客様を訪問し、修理サービスを提供します。コールセンターが事前に必要なサービスの内容を整理してくれていたので、問題なくサービスが提供出来ました。
一見、何も問題がなさそうに見えますが、実はお客様の何割かはサービスの提供が遅いと不満を感じていました。
更にお客様の不満を深堀すると、エンジニアの割り当てがされたという連絡は早いものの、肝心のエンジニアが修理サービスに来てくれるまでに時間がかかりすぎているという声が確認できました。
コールセンターは対応可能なエンジニアを割り当てるという作業をしており、いつお客様のもとに訪問できるかという点はエンジニアが調整するというルールとなっていました。一方でエンジニアは、自分が担当することとなったお客様とスケジュール調整を行い、対応可能な日程で訪問をするという仕事をしていました。
このケースでは、コールセンター、エンジニアの双方が協力し、どのエンジニアが修理サービスに割り当てられると最速でお客様のもとへ訪問が出来るのかを考えることが出来るようなプロセスが、本来のあるべき姿です。
お客様の修理サービス依頼を確認したら、どのエンジニアが最も早くお客様を訪問できるだろうかという点をコールセンターが確認したうえでエンジニアを割り当て、エンジニアは日程調整がすでに済んだ状態で修理サービスに集中する。こういったプロセスがそもそも目指すべきものではないでしょうか。
コールセンターのプロセス、エンジニアの修理対応プロセスが別のものとして扱われていた場合、両者は自分たちの仕事は完璧にこなしていると誤った理解をし続けていたかもしれませんし、あるいはお客様の不満はエンジニアのサービス提供が遅いというものなので、短絡的にエンジニアが責任を負わされていたかもしれません。
一度自分たちの仕事はこういうものだ、という理解をすると、人間はその前提を疑うということをしにくくなってしまいます。こうした状況がないかを点検し、改善すべきポイントに気づくためには、Roleや組織を横断する視点で整理したEnd to Endの業務の整理が必要不可欠なのです。
階層管理を行う
3つ目の要素は、プロセスを階層管理するというものです。
ここまでで、経営者目線での整理と、End to Endの目線の双方が重要という話をしてきましたが、これらの２つの要素をうまく実現するための要素が階層管理であるという言い方もできます。
こちらもまずはイメージをつかんでいただきましょう。
このように、階層管理とはハイレベルで整理したプロセスを、ブレークダウンし、最終的にEnd To Endの細かな業務のつながりまでを表現することを指します。
経営から現場までの連携が円滑化出来る
企業・事業が持つ業務は多種多様なものであり、そのためプロセスも様々なものが存在します。こうしたプロセスですが、役職や権限の違いによってその時々で確認したいプロセスの姿というものは異なります。
これによって、同じ業務のことをイメージしながらも人によってプロセスの確認・検討を行うときの粒度・レベル感・解像度が異なるという事象が発生します。こうした、それぞれの人物が求めるレベルが異なる視点においても矛盾なく業務を表現するためには、ハイレベルから詳細レベルまでを階層管理することが求められます。
社長クラスの方であれば、全社的なコスト削減のためにテコ入れを行うべき業務領域を検討する、あるいは自社のビジネスモデルの点検という意味でハイレベルに表現したプロセスを確認するということが考えられます。例えば、ここでは会計領域がピックアップされたとします
会計領域の部門長クラスの方が、社長から指示のあったコスト削減を実行するために、自社で行っている業務のうち、まるごとアウトソースが検討できるオペレーションが無いかを検討するということもあるでしょう。ここでは請求・入金消込業務がピックアップされたとします。
自社の請求・入金消込業務をアウトソースすることが決定した状態であれば、経理部門のメンバーはアウトソースをすることになる業務領域を整理し、外部のBPOベンダーに情報を伝達します。その際、請求・入金消込業務の細かな作業の流れを確認したうえで、どこは自社で実施し、どこを外部のBPOベンダーに委託するのかを整理することになります。
このように、ハイレベルでの検討と、詳細レベルでの検討がシームレスにつながることが必要な場面というものがあるのですが、こうしたときにプロセスが階層管理されていると、社長クラスの方が確認するプロセス、それをブレークダウンした部門長クラスが確認するプロセス、そして現場の担当者が確認するプロセス、と自由に粒度感、レベル感、解像度を切り替えることが出来ます。
今回は、コスト削減のためのアウトソースという文脈を例にとり、一過性の取り組みの印象を与えてしまったかもしれませんが、BPMは継続的にプロセスを管理・改善するサイクルです。そうしたサイクルは繰り返し実行されることを前提としているため、BPMの活動の中ではこのようなハイレベルでの検討から詳細レベルでの検討を何度も往復することとなります。
こうしたサイクルを円滑に回すし、経営から現場に至る関係者の連携がスムーズに行われるために、プロセスを可視化するときはハイレベルから詳細レベルまでが矛盾なく整合するように階層管理を行うべきなのです。
一元管理をする
４点目の要素はプロセスに関する情報の一元管理です。
当たり前のようですが、多くの企業でプロセスに関する情報は一元管理されていないことが多く、それによってさまざまな問題が発生します。
調達、生産、物流、在庫管理、等の業務の流れが各部門で別々に管理されているというケースは非常に多く、場合によってはプロセスを表現した媒体がPower Point、Excel、Visio、等の異なるフォーマットであるということもあります。
あるいは、文書化したものがGoogle Drive、共有フォルダー、Sharepointなどに分散してアップロードされており、場合によっては管理者のノートパソコン上のローカルファイルが最新である、というようなケースもあります。
こうしたことが続くと、どれが現在の業務を正しく表現している文書なのかが不明瞭となり、次第に適切なタイミングで更新がされなくなる、さらにはどこかのタイミングで失われてしまうという恐れがあります。
せっかくプロセスを可視化したのであれば、継続的に活用され続ける仕組みが必要不可欠です。それがプロセスの情報を一元管理することの一番のメリットですが、この他にも得られるメリットを見て頂きましょう。
共通認識・コラボレーションの促進・成功体験の蓄積と横展開
プロセスの情報を一元管理すると、当然ですがそこにすべての情報が集まります。
これによって、誰が見ても、最新のものがすべてここに集まっている、という認識を生むことが出来、多くの人々が一元管理された情報を確認するようになります。こうすることによって、組織、Roleを超えた人々の間で同じ認識が構築されます。
従来までは自分の担当している領域だけにしか興味がなかったような人々でも、一元管理された情報の中で自分たちの仕事の前工程や後工程の業務を確認することが出来るようになります。
前工程、後工程にも及ぶ共通の認識が構築されると、自分たちだけでは出来なかったような前工程、後工程に踏み込んだ改革・改善の取り組みが進みやすくなるというコラボレーション上のメリットも生まれます。
例えば、請求書をもとに支払いを依頼されるという財務部門の業務があるとしましょう。月末に向けて多くの請求書が転送され、月末は毎回忙しくなる、という状況だったとします。
この業務の前工程は、事業部が請求書を転送するという業務ですが、この前工程の業務がどうなっているのかを確認すると、事業部が請求書を郵送で受け取り、それをプリンターでスキャンしてPDF化し、財務部門に転送していたということが見えてきました。
このスキャンという作業が適時行われておらず、結果として財務部門のところに請求書が転送されるのが月末に集中していたことがわかったため、財務部門は各事業部門に対して適時請求書を共有してもらいたいということを伝えるとともに、プリンターではなくスマートフォンで紙面の読み取りが出来るようなソリューションの実装に取り組むことにしました。
このように、財務部門だけでは取り組むことが出来なかったような改革の取り組みも、プロセスの一元管理によって進みやすくなるという効果があります。
さらに、このような改革の取り組み自体も一元管理をしていくことで、成功体験を蓄積し、必要に応じて社内の他の部門などの取り組みにも応用させていくという横展開も進めていくことが可能となります。
記述ルールを統一する
5点目の要素は記述ルールの統一です。
プロセスの可視化は、組織やチームによって独自に行われているケースがあります。生産管理などの現場では非常に細かな記載が行われPowerpointのスライド数十枚にわたって整理がされている一方で、人事や総務では大きなくくりでまとめられた作業が並べられておりスライド2、３枚にすべての業務が収まっている、というケースもあります。
記載の粒度だけであればまだよいですが、誰がその業務を実行するのか、どのシステムを活用するのか、という点が整理されているケースと、そうでないケースが混在していることもあり、やはりすでにある程度の業務知識を持っている人でないと理解が困難なものとなってしまっていることもあります。
こうした状況を打破するためのポイントが、プロセスの記述ルールの統一です。
記述の一貫性を高め、均質化、属人化を回避し、比較・再利用可能性を高める
プロセスを可視化する際の記述ルールを統一定義し、関係者間で共有をしておくことでプロセスを記述する人によって品質が異なる、記載の粒度が異なる、ということが防ぐことが出来ます。
こうすることによって、誰がプロセスを記述しても、前提知識が無い人でも容易に同じ理解をすることが出来るようになります。
また、組織を超えて一貫性、同程度の品質のプロセス記述が行われることで、比較検討を行う、再利用を行うということも可能となります。
例えば、大企業では購買のプロセスを購買対象の性質に応じて分け、戦略も別々に定義しているということがあります。その流れを踏襲し、同じ購買という業務であるにも関わらずまったく違うやり方で業務を実行しているということがあります。
購買に関する戦略策定の部分は別々に実施していたとしても、サプライヤーの選定を行った後の包括契約の締結、購買発注の作成、受領、棚入れ、といった業務は購買対象の性質を問わず同じものにしておくということは可能であり、効率的な考えです。
こうした購買業務の実行部分を購買対象品目の責任グループ横断で確認し、標準化・集約を進めていくという活動をする際、プロセスが同じルールで記述されていると、プロセスの比較・再利用が進めやすくなります。
具体的にどういった記述ルールが良いのか、という点についてはBPMN2.0という国際的な規格があるため、こちらを採用されるとよいでしょう。ただし、BPMN2.0は複雑なルールも一部含まれるため、この通りにやるというよりも、BPMN2.0を基本として、その中の一部を自社におけるプロセス記述ルールに取り入れる、という方法が現実的かと思います。
終わりに
いかがでしたでしょうか。プロセス可視化のポイントとして基本的な方針を５つ、ご紹介させて頂きました。
より具体的な、プロセス記述におけるポイント、ルールについてはまた別の投稿でご紹介したいと思います。