業務フロー記述ガイドライン

Ranabaseにおける業務フローの表記法について解説します。Ranabaseでは、Event Driven Process Chain diagram (以後“EPC”と表記)と呼ばれるグローバルでも古くから広く親しまれてきたビジネスプロセスの表記法を採用しています。業務フローの表記法は昨今の世界標準と言われるBPMN2.0を始めとして数多く存在しますが、その中で敢えてEPCをお勧めする理由は、

• 文章のように描ける/文章のように読める

• 業務フローを描く際に使い分けるべきシンボル (Ranabaseでは”クリップ”と呼びます) の種類が比較的少なく、習得が簡単

• イベント (Event) という業務の開始条件や分岐条件を言葉で記述するルールに従うことで、人やシステムが実行するプロセスが進んでゆくロジックが明確になる。これが改善点への気付きに繋がる。

などが挙げられます。端的に言えば、人の業務の改善サイクルを回すという目的に一番フィットするからです。それでは以下に、必要最低限の記述ガイドラインを示します。

レーンの並べ方はお客様を左、主人公を中心、社内関係者を右に

スケッチを開いたら、まずはレーンに名称を付けてゆきます。主人公を中心として、お客様(主人公に対する依頼者)を左側、主人公が何かを依頼する社内関係者を右側に配置するようにします。また、主人公から見て直接的な接点を持つ相手は主人公の近くに、間接的な相手は遠くになるようにすると良いでしょう。見積プロセスで言うと、一番左から、顧客→営業担当者(主人公)→営業上長→事業部担当者、といった並びになることが典型例です。業務フローの見た目上の”形”は、このレーンの並べ方によって変わります。レーンの並べ方を揃えることにより、誰が描いても同じような流れになるようにしましょう。

Open

時間の流れは上から下

業務フロー上の時間は上から下に進みます。業務Aが業務Bの前提となる場合、業務Bは必ず業務Aよりも下に書いて下さい。当たり前のように思えるかもしれませんが、レーンを跨いだら矢印が上に戻るような業務フローを書いてしまう方が意外と多いのです。(空いているスペースを有効活用しようという意図でしょう) 業務が並列で進む場合では、出来るだけ並行する業務の開始タイミングを横並びで揃えるようにして下さい。処理時間が異なるので、並列化して二番目以降の業務は無理に揃える必要はありません。矢印が上に戻っても良いのは、実際に業務が手戻りを起こし、前工程に戻らなければならない場合に限ります。

Open

クリップはデフォルトの大きさのまま使う

スケッチ編集画面の左上に業務フローを描くための部品となる”クリップ”が用意されています。ここから必要なクリップを選んで、ドラッグ&ドロップで業務フローの描画領域に配置することで業務フローを描いてゆきます。各種クリップはパワーポイントやエクセルの描画機能と同様、大きさを変えることも出来ますが、デフォルトの形・大きさのまま利用して下さい。業務フローの体裁を出来るだけ揃えるためです。大きさを変えることについて、あなたには何らかの意図があるかもしれませんが、他人にはその意図は正確には伝わりません。今は重要だから大きく描きたいとしても、将来はその重要性が変わる可能性があります。他者はその時に、そのクリップの大きさを直して良いものかどうか判別がつかなくなります。こうして、この業務フローには「あたな以外は触ってはいけないもの」という暗黙のフラグが立ち、陳腐化してゆきます。業務フローに個性を出さないことが、継続的な業務プロセス管理においては重要なポイントです。

イベント→業務→イベントの流れで描く

業務は通常、お客様にトリガーされて始まります。お客様とは文字通りの顧客のことだけではなく、主人公にとっての依頼者(前工程の人)もお客様と捉えることができます。業務フローの始点はそのお客様がどういう条件で、どんな手段で、その依頼をして来るのか？と考えることから始めます。例えば、何らかの作業を実行するという業務は、前工程の人からその作業を依頼されることで開始されます。紙の「依頼票」をもらうのか、メールで依頼されるのか、システムにログインしてタスクが回ってきたことに気づくのか、と考えることで、前工程の業務のアウトプットと自工程の業務へのインプットが具体的に特定されます。これに応じて、イベントには「〇〇依頼票を受領した」「○○依頼を受信した」「○○作業を依頼された」と記述し、その手段はインプット、アウトプット、利用システム等のクリップで表現します。この業務も必ず次の工程のトリガーとなるはずです。本工程の完了イベント(完了条件)は次工程の開始イベント(開始条件)になる訳です。このような繋がりを丁寧に記述してゆくと、業務フローは自然に「イベント→業務→イベント→業務→イベント・・・」と、イベントと業務が交互に連なった流れになります。イベントに書かれる文言が当たり前過ぎてアホらしくなる、面倒に思えるという場面もあるかと思いますが、当たり前なことを丁寧に描くことが重要です。業務課題の多くは「○○作業を依頼された」というイベントの中に潜んでいます。依頼されるけど、期日が不明、内容が曖昧、コロコロ変わる、優先度的にすぐには着手出来ない、依頼されたことに気づかずに放置してしまう等など、業務そのものよりも、イベントの方を指差して気づくことが、現場からはたくさん出てくるはずです。

イベントはそれがトリガーする業務と同じレーンに置く

イベントと業務を交互に置いて流れを作ると説明しましたが、流れがレーンを跨がる時には、次の業務と同じレーンにイベントを配置して下さい。つまり、イベントは常に業務の真上にあるようにするということになります。どんな条件で次の業務が開始されるのか、その人の視点に立ってイベントを描くよう心掛けましょう。

業務ステップはハンドオフの単位で切る

業務フローにおける業務の1ステップの粒度 (粗さ/細かさ) は、"ハンドオフの単位" で描きます。ハンドオフ(Hand off)とは、手渡しするという意味の英語です。仕事は前工程からの依頼を受けて、何かの作業を行い、次の工程にそのバトンを渡すという行為の連続です。この「バトンをもらってから次の人に渡すまでを業務の一単位」としましょう、という事です。この基準はGlobalに通用するものです。日本BPM協会のトレーニングコースでもそのように教えています。ハンドオフで切る理由や効果についてはカエル塾のブログで詳しくご紹介していますので、こちらをご参照下さい。

https://kaerujuku.jp/modeling/modeling002/

以上の形式的なガイドラインを守ることにより、業務フローの形を見るだけで、中の文字を読まなくても、その業務の複雑度を評価できるようになります。ステップ数が多い、レーンを跨ぐ回数が多いのは、それだけで(理由はともかく)非効率であると評価できます。業務改善サイクルを回し、業務フローがどんどんシンプルになり、短いステップ数で終わるようになってきたという様を、是非Ranabaseに記録して下さい。もちろん、必要なステップを省いたら不正や事故や品質問題が起きます。そのバランスを取ることが業務改善です。

クリップの命名規則

クリップに付ける名称は用法・語法を統一しておくことをお勧めします。以下にご推奨する命名規則を示します。

特に、業務とイベントの書きっぷりを上記の命名規則に従うことにより、「見積申請を起案する」「見積申請を受領した」「見積申請を審査する」「見積申請が承認された」・・・と、読み手にとっては業務フローを文章のように読むことが出来るようになり、業務の繋がりがわかりやすくなります。名詞が羅列されたような業務フローに比べると、人が何をしているのかがより具体的に伝わります。

また、情報、帳票、ルール等、その他の要素に関しては、業務フロー上に記述する用語を出来るだけ集約化する、つまり同じ対象物に対しては同じ用語を使うことが望ましいと言えます。もし期せずして同じ用語が異なる対象物に対して登場した場合は、社内で用語を見直すか、暫定策としてその用語の後ろに( )書きで、その区別を記すようにして下さい。業務フローを整備してゆく過程で、業務用語の乱れに気づき、それを正すということも、業務改善活動の目的の一つです。Ranabaseではパレットという機能で、業務フロー上で使われたクリップ名称の一覧を確認することが出来ます。クリップの属性には、その定義を記述することも出来ますので、業務用語の棚卸と再定義のために活用して下さい。

情報は左上から右下へ (業務に対する付帯情報の配置ルール)

業務に対して情報や帳票のインプット/アウトプットを配置する際は、業務に対するインプットを左上に、アウトプットを右下に並べるようにして下さい。「ルール」は業務で参照されるという意味でインプットになります。「KPI」はこの業務で決定される、または計測されるという意味でアウトプットになります。「ユーザーインターフェース」(この業務で利用するシステムやツール)はインでもアウトでもありません ので、(強いて言えばこの業務の実行をサポートする”役割”の位置付け) インプットやアウトプットとは区別して、右上から業務に接続します。(矢印はアウトプットの始点とは異なる場所に差し込んで下さい)

分岐と合流

次にフローの分岐と合流の描き方について解説します。

XOR条件

ある業務の結果次第で次の業務のパターンが複数考えられ、必ずその内の一つのパターンに進むという場合、「菱形に X マーク」のXOR条件(エックスオア条件)を使います。専門用語では Exclusive OR またはExclusive Gatewayといいます。(エックスオアのエックスは Exclusive の”X”を取ったものです) 名前は馴染みにくいかもしれませんが、承認行為や検査後のOK/NGなど、分岐表現の中で最も多く使われるタイプですので覚えて下さい。

このルールで分岐した業務が合流する場合は、必ずXOR条件で合流します。A, B, またはCのいずれか一つに分岐したのですから、その内の一つからしか戻ってこないためです。

AND条件

XOR条件の対極にあるのがAND条件です。ある業務の後、後続の業務を全て同時並行で行う場合、「菱形に+マーク」の分岐シンボルを使います。専門用語ではParallel gateway といいます。

AND条件で分岐したプロセスが合流する場合は、やはりAND条件で合流します。A, B, Cの全てを並列で行っているので、そのうちの一つでも終わっていない場合は、その完了を待ってから次に進みます。

OR条件

最後にOR条件です。これは「なんでも有りの分岐パターン」と覚えて下さい。A, B, Cの全てかもしれないし、その内の二つかもしれないし、一つかもしれない。ケースバイケースの分岐表現です。「菱形に○マーク」の分岐シンボルを使います。業務の中の判断ロジックを細かく要素分解すれば、最終的には必ずXOR条件またはAND条件で表すことが可能ですが、そこまで細かいことを書くのは業務フローの他の箇所と粒度感が合わなくなってしまうことがあります。そういう時のために使う妥協案です。(曖昧なので出来るだけ使わないようにして下さい)

OR条件で分岐したら、合流時はやはりOR条件で合流します。

業務フローの記述ガイドラインは以上となります。内容面のレビューを受ける前に、ここでご説明した形式面のガイドラインに準拠していることをチェックすることをお勧めします。セルフチェックシートを用意しましたので雛形としてご活用下さい。

https://ranabase-design.atlassian.net/wiki/spaces/RBD/pages/168329448