入門編では業務プロセス可視化の進め方を最低限のポイントに絞って解説します。まずはとにかく、業務を可視化したいという皆様向け、Ranabaseライトプラン(無償範囲)だけで実行可能な内容です。基礎編に進むための前提条件ともなります。
業務一覧の検討
業務一覧とは、ここでは「業務フローのタイトル一覧」のことと捉えて下さい。業務フローを描く単位をどうするか? ということが問題になります。社内に既に存在する業務一覧がいまいち、しっくりこない。本当にこれが全てなのか? 業務フローどうしの繋がりは整合性が取れているのか? 担当者にとってわかりやすいのか? 改善サイクルを回すにあたりこのままで良いのか? などというお悩みを抱えていらっしゃる方が多いと思います。Ranabaseで今回初めて業務フローを描こうという皆様はもちろんのことですが、既にある業務フローをRanabaseに載せ替えようという皆様は、既存の業務フローをそのままRanabaseに書き写すのではなく、是非一度ここで「業務フローを描く単位」をしっかりと定義することをお勧めします。考慮すべきポイントは、次の3点です。
1. 業務を実行する主体にとってわかりやすいこと
業務フローには主人公を決めて下さい。その業務を主体的に進める役割の方です。物販の見積プロセスを例にとると、主人公は恐らく営業担当者です。このプロセスは営業担当者に対して見積依頼が届いてから、見積書をお客様に提示するまでが業務フローを描く一単位となります。途中で倉庫や工場に在庫状況を問い合わせるためにバトンが他部門に渡ることもあるでしょうが、業務上の推進責任は一貫して営業担当者にあります。業務フローは、この営業さんにとってわかりやすい事が一番です。この営業さんにとって関係のないパターンを混ぜて描いたり、逆に本来は配慮しなければならないパターンが書かれていなかったりすると、わかりにくくなります。わかりにくい業務フローは使われない→メンテナンスされない→改善サイクルは回らない、という結果になってしまいます。主人公にとってわかりやすい事が一番重要です。
2. その業務で扱う主たる情報を一つに絞ること
その業務フローで扱われる主要な情報を一つ決めて下さい。前述の見積プロセスの例で言えば「見積」です。「見積」という情報について作成を依頼されてから、依頼者に提供するまでが一つの業務となります。あらゆる業務は情報を受け渡しているだけだとも言えます。モノやお金や人を動かすという局面においても、企業ではそのことを情報として記録しますよね。アイデア、企画、計画なども情報にあたります。情報の作成・変更・削除を依頼されてから、それを完了させるまでを一単位とすることで、業務フローの切れ目が明確となり、粒度が揃ってきます。
3. フローどうしの前後関係が繋がっていること
業務フローどうしの繋がりを維持して下さい。多くの場合、一つの業務フローの終点は、別の業務フローの始点になるはずです。業務上の課題と対策を検討する際は、課題が顕在化している箇所から上流へ遡ってその原因を探ります。業務フローが繋がっていないと、そのような探究も途中で途切れてしまうことになります。
以上3点に注意して、これから業務フローを作成する単位をリストアップし、前後関係に従って業務フロー名の先頭に番号(ID)を付けて下さい。Ranabaseでは”スケッチ一覧”が業務一覧となります。
...
業務フローの作成
業務一覧の検討を通して、一つの業務フローの中に登場する主人公と主たる情報、始点と終点が決まりました。それでは、いよいよ業務フローの作成に入ってゆきます。
業務フローを作成する準備として、Ranabaseの操作に不安のある方はまずこちら(クイックスタートガイドとスケッチの基本操作)を参照し、スケッチの編集画面を開いてから続きをお読み下さい。
記述ガイドライン
Ranabaseにおける業務フローの表記法について解説します。Ranabaseでは、Event Driven Process Chain diagram (以後“EPC”と表記)と呼ばれるグローバルでも古くから広く親しまれてきたビジネスプロセスの表記法を採用しています。業務フローの表記法は昨今の世界標準と言われるBPMN2.0を始めとして数多く存在しますが、その中で敢えてEPCをお勧めする理由は、
文章のように描ける/文章のように読める
業務フローを描く際に使い分けるべきシンボル (Ranabaseでは”クリップ”と呼びます) の種類が比較的少なく、習得が簡単
イベント (Event) という業務の開始条件や分岐条件を言葉で記述するルールに従うことで、人やシステムが実行するプロセスが進んでゆくロジックが明確になる。これが改善点への気付きに繋がる。
などが挙げられます。端的に言えば、人の業務の改善サイクルを回すという目的に一番フィットするからです。それでは以下に、必要最低限の記述ガイドラインを示します。
レーンの並べ方はお客様を左、主人公を中心、社内関係者を右に
スケッチを開いたら、まずはレーンに名称を付けてゆきます。主人公を中心として、お客様(主人公に対する依頼者)を左側、主人公が何かを依頼する社内関係者を右側に配置するようにします。また、主人公から見て直接的な接点を持つ相手は主人公の近くに、間接的な相手は遠くになるようにすると良いでしょう。見積プロセスで言うと、一番左から、顧客→営業担当者(主人公)→営業上長→事業部担当者、といった並びになることが典型例です。業務フローの見た目上の”形”は、このレーンの並べ方によって変わります。レーンの並べ方を揃えることにより、誰が描いても同じような流れになるようにしましょう。
...
時間の流れは上から下
業務フロー上の時間は上から下に進みます。業務Aが業務Bの前提となる場合、業務Bは必ず業務Aよりも下に書いて下さい。当たり前のように思えるかもしれませんが、レーンを跨いだら矢印が上に戻るような業務フローを書いてしまう方が意外と多いのです。(空いているスペースを有効活用しようという意図でしょう) 業務が並列で進む場合では、出来るだけ並行する業務の開始タイミングを横並びで揃えるようにして下さい。処理時間が異なるので、並列化して二番目以降の業務は無理に揃える必要はありません。矢印が上に戻っても良いのは、実際に業務が手戻りを起こし、前工程に戻らなければならない場合に限ります。
...
クリップはデフォルトの大きさのまま使う
スケッチ編集画面の左上に業務フローを描くための部品となる”クリップ”が用意されています。ここから必要なクリップを選んで、ドラッグ&ドロップで業務フローの描画領域に配置することで業務フローを描いてゆきます。各種クリップはパワーポイントやエクセルの描画機能と同様、大きさを変えることも出来ますが、デフォルトの形・大きさのまま利用して下さい。業務フローの体裁を出来るだけ揃えるためです。大きさを変えることについて、あなたには何らかの意図があるかもしれませんが、他人にはその意図は正確には伝わりません。今は重要だから大きく描きたいとしても、将来はその重要性が変わる可能性があります。他者はその時に、そのクリップの大きさを直して良いものかどうか判別がつかなくなります。こうして、この業務フローには「あたな以外は触ってはいけないもの」という暗黙のフラグが立ち、陳腐化してゆきます。業務フローに個性を出さないことが、継続的な業務プロセス管理においては重要なポイントです。
...
イベント→業務→イベントの流れで描く
業務は通常、お客様にトリガーされて始まります。お客様とは文字通りの顧客のことだけではなく、主人公にとっての依頼者(前工程の人)もお客様と捉えることができます。業務フローの始点はそのお客様がどういう条件で、どんな手段で、その依頼をして来るのか？と考えることから始めます。例えば、何らかの作業を実行するという業務は、前工程の人からその作業を依頼されることで開始されます。紙の「依頼票」をもらうのか、メールで依頼されるのか、システムにログインしてタスクが回ってきたことに気づくのか、と考えることで、前工程の業務のアウトプットと自工程の業務へのインプットが具体的に特定されます。これに応じて、イベントには「〇〇依頼票を受領した」「○○依頼を受信した」「○○作業を依頼された」と記述し、その手段はインプット、アウトプット、利用システム等のクリップで表現します。この業務も必ず次の工程のトリガーとなるはずです。本工程の完了イベント(完了条件)は次工程の開始イベント(開始条件)になる訳です。このような繋がりを丁寧に記述してゆくと、業務フローは自然に「イベント→業務→イベント→業務→イベント・・・」と、イベントと業務が交互に連なった流れになります。イベントに書かれる文言が当たり前過ぎてアホらしくなる、面倒に思えるという場面もあるかと思いますが、当たり前なことを丁寧に描くことが重要です。業務課題の多くは「○○作業を依頼された」というイベントの中に潜んでいます。依頼されるけど、期日が不明、内容が曖昧、コロコロ変わる、優先度的にすぐには着手出来ない、依頼されたことに気づかずに放置してしまう等など、業務そのものよりも、イベントの方を指差して気づくことが、現場からはたくさん出てくるはずです。
...
イベントはそれがトリガーする業務と同じレーンに置く
イベントと業務を交互に置いて流れを作ると説明しましたが、流れがレーンを跨がる時には、次の業務と同じレーンにイベントを配置して下さい。つまり、イベントは常に業務の真上にあるようにするということになります。どんな条件で次の業務が開始されるのか、その人の視点に立ってイベントを描くよう心掛けましょう。
...
業務ステップはハンドオフの単位で切る
業務フローにおける業務の1ステップの粒度 (粗さ/細かさ) は、"ハンドオフの単位" で描きます。ハンドオフ(Hand off)とは、手渡しするという意味の英語です。仕事は前工程からの依頼を受けて、何かの作業を行い、次の工程にそのバトンを渡すという行為の連続です。この「バトンをもらってから次の人に渡すまでを業務の一単位」としましょう、という事です。この基準はGlobalに通用するものです。日本BPM協会のトレーニングコースでもそのように教えています。ハンドオフで切る理由や効果についてはカエル塾のブログでご紹介していますので、そちらをご参照下さい。
https://kaerujuku.jp/modeling/modeling002/
以上の形式的なガイドラインを守ることにより、業務フローの形を見るだけで、中の文字を読まなくても、その業務の複雑度を評価できるようになります。ステップ数が多い、レーンを跨ぐ回数が多いのは、それだけで(理由はともかく)非効率であると評価できます。業務改善サイクルを回し、業務フローがどんどんシンプルになり、短いステップ数で終わるようになってきたという様を、是非Ranabaseに記録して下さい。もちろん、必要なステップを省いたら不正や事故や品質問題が起きます。そのバランスを取ることが業務改善です。
クリップの命名規則
クリップに付ける名称は用法・語法を統一しておくことをお勧めします。以下にご推奨する命名規則を示します。
...
クリップ
...
命名規則
...
補足
...
業務L3
...
[対象]を[行為]する
...
例：
[見積申請]を[起案]する
...
イベント
...
[対象]を[行為]した
または
[対象]が[行為]された
...
例：
[見積申請]を[受領]した
[見積申請]が[承認]された
...
その他
(業務L1、業務L2、情報、帳票、モノ、ユーザーインターフェース、ルール、KPIなど)
...
名詞
...
社内で一般的に通用する用語を使うこと
社内に用語規定がある場合はそれに従う
システム関連の用語(画面名、帳票名など)は、その正式用語に従う
特に、業務とイベントの書きっぷりを上記の命名規則に従うことにより、「見積申請を起案する」「見積申請を受領した」「見積申請を審査する」「見積申請が承認された」・・・と、読み手にとっては業務フローを文章のように読むことが出来るようになり、業務の繋がりがわかりやすくなります。名詞が羅列されたような業務フローに比べると、人が何をしているのかがより具体的に伝わります。
また、情報、帳票、ルール等、その他の要素に関しては、業務フロー上に記述する用語を出来るだけ集約化する、つまり同じ対象物に対しては同じ用語を使うことが望ましいと言えます。もし期せずして同じ用語が異なる対象物に対して登場した場合は、社内で用語を見直すか、暫定策としてその用語の後ろに( )書きで、その区別を記すようにして下さい。業務フローを整備してゆく過程で、業務用語の乱れに気づき、それを正すということも、業務改善活動の目的の一つです。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条件で合流します。
...
業務フローの記述ガイドラインは以上となります。内容面のレビューを受ける前に、ここでご説明した形式面のガイドラインに準拠していることをチェックすることをお勧めします。セルフチェックシートを用意しましたので雛形としてご活用下さい。
...