Q-BPM:サンプルプロセス記事の書き方

Q-BPMサイトを利用されているみなさんは、少なからず、業務フロー図を見たことがあるでしょう.

業務フロー図は業務を遂行する上で「誰が」「どのようなルートで」「いつ」「誰に」「誰と」「どのようにして」、業務を構成する作業(タスク)を実行しているかを示す図です. Q-BPMの目的の一つである「世界中のビジネスマンがBPMの学習を行うことができるサイト」を目指していることにより世界中の業務フロー図を見ることは大きな助けになります.

色々な業種、シーンで利用されている業務フロー図を集めたサンプルプロセス記事集もQ-BPMを構成するコンテンツです. サンプルプロセスは、業務フロー図だけではなく、その業務フローの背景や使用するデータ等の情報もあります. 本ページの内容を理解して、色々なサンプルプロセスを見たり、それについて議論をしたり、自分の知見のある業務プロセス図を作成することで、Q-BPMを利用しているみんなでBPMの学習をしていきましょう.

記事の作成や更新
Q-BPMの用語記事を作成する方法と変わりはありません. Q-BPM:ヘルプやQ-BPM:Wiki文法の概要を参照して大胆にサンプルプロセス記事の編集を行ってください.

記事の構成
記事は以下の節で構成されることを推奨します.
 * 前文
 * 簡単にこの業務プロセスに関して説明します. 簡単に目的やどのような利用シーンかを記述すると良いでしょう.
 * 概要
 * 誰がどのようなタイミングで誰にどのようなアクションを起こすのかを文章で記述する節です. 箇条書き等にすると見やすく整理もつけられやすいでしょう.
 * プロセス担当者
 * この業務プロセスに係る関係者を列挙します. 同時にスイムレーン(後述)の名称を記述しておくと良いでしょう.
 * プロセスオーナ
 * この業務プロセスに対する責任者を記述します. この業務プロセスの実行状況を定期的に監視したり定期的な改善を行ったりする担当者となるでしょう.
 * プロセスダイアグラム例
 * Graphviz を使用して DOT 言語を用いて記述します. 記述方法については「Q-BPM:プロセスダイアグラム画像の書き方」を参照してください.
 * プロセスデータ例
 * 表形式でどのアクティビティ(タスク)において利用されるデータを表現します. データ毎にいずれのアクティビティで可視(r)、可編集(w)、不可視(-)のどの扱い方ができるかを記述します.

前述の節以外にも「リスク」や「メリット」、「デメリット」、「KGI」、「KPI」等を記述してよりその業務プロセスを知ってもらいましょう.

記事のネーミング
サンプルプロセス記事は非常に多数、掲載されています. その中で自分の知りたい業務プロセスを容易に探し当てたいと思うことでしょう. その為にも以下のネーミングルールを守り、キーワードの検索で容易に探し当てられるようにしてください.

{項目名称}+"/"(半角スラッシュ)+{キーワード} (記入例) 立替金申請プロセス/逐次提出・領収書画像アップロード・上司承認 ただし、あまりにキーワードが多い場合、サンプルプロセスの名称が読み取り難くなる可能性があります. キーワードの文字数最大20文字くらいが目安となるでしょう.
 * 記事名称は業務種類のカテゴリの中に分類されている項目名称とキーワードで構成されています.
 * 項目名称は後述の「記事のカテゴリ」の「業務種類別」の名称項目リストを参照してください.
 * キーワードは黒い点「・」(全角)で区切ってください. 複数のキーワードの設定をしてもらって問題ありません.

記事のカテゴリ
サンプルプロセスのカテゴリは、大きく分けて「業務種類別カテゴリ」「主管部門別カテゴリ」の2つの種類があります.
 * 「業務種類別カテゴリ」はどような業務においてサンプルプロセスが実行されているかを示すカテゴリです.
 * 汎用業務プロセス
 * 基幹系業務プロセス
 * 支援管理系業務プロセス
 * 「主管部門別カテゴリ」はサンプルプロセスがどの部門によって管理(メンテナンスや実行監視)されているかを示すカテゴリです.
 * 経理部
 * 人事部
 * 総務部
 * 開発部
 * 営業部
 * マーケティング部
 * 品質管理部
 * 経営企画室
 * 企画部
 * 財務部
 * 法務部
 * 広報部
 * IR部
 * 税務部
 * 監査部/室
 * 特許,知財部/室
 * 労務部
 * 研究部/室
 * 情報システム部
 * 任意部門
 * (注記)
 * いずれのプロセスでも管理されるものではないプロセス(様々な部門毎で管理されるようなプロセス)の場合、「任意部門」の指定を行う.

それぞれの種類のカテゴリ内に相当するカテゴリを設定してください. (設定例)

あなたがサンプルプロセスを作成する際に、上記の種類を探しても'''該当する「業務種類」、「部門」が無い場合には、上記に追加の上、利用してください. '''

「業務種類別カテゴリ」に属する項目名称
前述の「記事名称」に使用される項目名称をいずれのカテゴリに属しているかを含めて示します.

※内の IDX.X.X はAPQCのモデルIDを示しています.
 * 汎用業務プロセス
 * 文書作成プロセス
 * 申請処理プロセス
 * 定期報告プロセス
 * 稟議決裁プロセス
 * 戦略立案プロセス
 * 基幹系業務プロセス
 * EA構築プロセス
 * 顧客管理戦略策定プロセス(ID3.2.1)
 * CRM運用プロセス
 * マーケティング戦略構築プロセス
 * 見積取得プロセス
 * 検収プロセス
 * 支援管理系業務プロセス
 * 人事総務：採用プロセス（ID6.2.x）
 * 人事総務：身分証明書発行プロセス
 * ログインIDパスワード設定プロセス
 * 人事総務：能力開発プロセス（6.3.4）
 * 人事総務：人事考課プロセス（6.4.1）
 * 人事総務：モチベーションプログラム設定プロセス（6.4.1-6.4.2）
 * 総務：IT導入プロセス（ID7.1.8）
 * 経理：立替金申請プロセス（8.6.1）
 * 与信管理プロセス
 * ナレッジマネジメントプロセス(ID12.3.3)

スイムレーンのネーミング
記事内の「一般的な業務フロー例」の節で描かれている各タスクを長方形の囲みはおおよそグループをさします. (長方形の囲みを「スイムレーン」と呼びます. )

グループを示す名称としてメールアドレスを模して表現します. 「marketing@company.com」と記述してください. 解説:「marketing」("@"マークより前の文字列)は「マーケティング部」を指します. 「company.com」("@"マークより後の文字列)は「マーケティング部」の属する企業を指します. スイムレーンは他の会社の可能性もあります. よって同一企業内のスイムレーンの場合は「company.com」で統一する必要があります. ※スイムレーンで違う企業が存在する場合は「@ex.company.com」などの違う名称をつけてください. 「person@company.com」と記述してください. 解説:「person」("@"マークより前の文字列)は特定のグループや部をささない人物を指します. 「company.com」("@"マークより後の文字列)は「person」の属する企業を指します. 「marketing-leader@company.com」と記述してください. 解説:「marketing-leader」("@"マークより前の文字列)は「マーケティング部」のリーダを指します. marketingとleaderは「-」ハイフネーションで区切ってください. 「marketing」はスイムレーンを実行する人物のグループ／部の名前を示し、「leader」は地位を示します. もし、作成された一連の業務プロセス内に同一グループ／部の違う特別な地位のスイムレーンが複数ある場合は、 marketing-parent-leaderのように「parent-leader」を使用しきり分けをしてください.
 * 【例1：マーケティング部での業務プロセスの場合】
 * 【例2：様々なグループや部に属する人が利用する業務プロセスの場合】
 * 【例3：グループ内(例ではマーケティング部)で特別な地位の人が利用する業務プロセスの場合】

アクティビティのネーミング
記事内のプロセスダイアグラム例の節で描かれている各タスク(アクティビティ)でのネーミングルールを示します.


 * プロセスダイアグラム例(の一部)

digraph SAMPLE { compound=true; //cluster graph [size="10,10", rankdir=LR]; // max width 10inch node [shape=box, style=rounded]; //default Activity edge [color="#444444", labelfloat=true]; //label text float OFF(=true)

subgraph cluster3 { labeljust=l; label="information-system@company.com"; I1 [label="I1:申請\nの確認"]; I2 [label="I2:ID/Passwd\nの発行"]; I3 [label="I3:書留\n郵送"]; Ie [label="Ie:却下\n通知"]; IY [label="",shape=circle, width="0.2", style=bold];

I1->I2 [arrowtail=rcrowlvee,weight=10]; I1->Ie [arrowtail=odiamond, taillabel="NG"]; IY->I3 [dir=back,weight=10]; I1->IY [arrowtail=odiamond, label="noise",minlen=2]; I2->I3 [arrowtail=odiamond, label="離地対応",minlen=2];

{rank=same; I1;IY;} {rank=same; Ie;I2;I3;} } }

ネーミングのルールとしては以下です. (記入例) I1:申請の確認 Ie:却下の通知 (例での解説) スイムレーンの名称は information-system@company.com であるので、該当のスイムレーンで 使用されるアクティビティのIDの英字部分は「I」となります.
 * {ID英字3文字以内} + {IDの数値もしくはイベントの頭文字} + {タスクの作業の体言止め}
 * 「ID英字」についてはスイムレーンの名称の頭文字を使用してください. 他のスイムレーンの頭文字と同じ場合は文字数を増やし他のスイムレーンとはユニークにしてださい.

プロセスデータの表記
業務プロセスにおいてアクティビティ(タスク)間において保持されるデータが存在します. そのデータをプロセスデータと呼びます. アクティビティによっては閲覧だけできるものであったり、編集できるものであったり、閲覧さえさせないデータが存在します.

業務プロセスがどのような振る舞いや利用者に影響を与えるかを理解するにはプロセスデータ例は必須となります.

アクティビティとプロセスデータの関係を簡易に表すことのできるよう表形式で表現を行ってください.

各アクティビティでのプロセスデータの扱い方は以下の記述方法によって行います.
 * 入力必須／任意属性
 * 必須の場合は、NotNull を示す「NN」を、任意の場合は「-'」(ハイフネーション)を欄内に入力し該当データの必須条件を明確にします.
 * 閲覧／編集属性
 * データの取扱いに対して閲覧の可／不可、編集の可／不可を明確にします.
 * 「R」　：プロセスデータの閲覧のみ可能な扱い.
 * 「RW」 ：プロセスデータの閲覧／記入が可能な扱い.
 * 「-」　：プロセスデータの閲覧／編集不可な扱い.
 * 「W」　：プロセスデータの新規記述もしくは上書きのみ可能な扱い. (既に存在するデータの閲覧は不可)

プロセスデータ例
上記のプロセスデータのような扱いを行うプロセスダイアグラム例

digraph SAMPLE { compound=true; //cluster graph [size="10,5", rankdir=LR]; // max width 10inch node [shape=box, style=rounded]; //default Activity edge [color="#444444", labelfloat=true]; //label text float OFF(=true) subgraph cluster1 { style=bold; labeljust=l; label="person@company.com"; PX [label="", shape=circle, width="0.2"]; PY [label="",shape=circle, width="0.2", style=bold];

P1 [label="P1:立替内容\n領収書画像\nの入力"]; P2 [label="P2:否決\n内容の確認"]; P3 [label="P3:入金\n予定の確認"];

PX->P1 [weight=10]; P1->P2 [dir=back, arrowhead=rcrowlvee, weight=10]; P2->PY [arrowtail=odiamond, label="否決\n受諾", weight=10]; PY->P3 [dir=back, weight=10]; } subgraph cluster2 { labeljust=l; label="section-leader@company.com"; S1 [label="S1:決裁"]; } subgraph cluster3 { labeljust=l; label="accounting@company.com"; A1 [label="A1:決裁\n内容の確認"]; A2 [label="A2:微細修正"];

A1->A2 [arrowtail=odiamond, label="miss"]; }

P1->S1 ; S1->P2 [arrowtail=odiamond, taillabel="NG"]; S1->A1 [arrowtail=rcrowlvee]; A1->P3 [arrowtail=rcrowlvee, headport=s]; A1->P2 [arrowtail=odiamond, taillabel="NG"]; A2->P3 [arrowtail=rcrowlvee];

}

関連記事

 * BPM
 * プロセス改善
 * プロセスモデル
 * 業務フロー図
 * プロセスオーナー
 * APQC
 * BPMN