ビジネスプロセスモデリング

序

モデリングには色々ありますが、ビジネスプロセスを形成するための手法をまとめていきます。

ビジネスプロセスとは

ビジネスプロセスは、

何らかのアクターやオブジェクトが関わった一連のイベント、行動や意思決定で、そのひとつひとつがイベントによって引き起こされて、その一連の結果が顧客にとっての利益になるもの

のことです。

ビジネスプロセスには目的、リスク、規則、知識の要素が多くの場合含まれます。
目的は企業全体としての戦略に繋がるかどうか、
リスクはプロセスが内包するリスクの分析、
規則はコンプライアンスの違反がないか、
知識はそのプロセスが要求する専門知識があるかどうかです。

ビジネスプロセスの例

eg1 届いた商品が不良品だった場合

理想の結果：顧客にとって最低限の手間で不良品が修繕される　or　顧客にとって最低限の手間で保険が適用される

プロセス順	プロセス
1	コールセンターでの対応
2	サービスセンターへの発送
3	技術者による検査および修理
4	在庫の確認
5	保険会社への連絡
6	顧客への返答

がこのケースにおいて考えられるビジネスプロセスモデルです。

ビジネス全体から見たビジネスプロセス

ビジネスには内的環境と外的環境があり、外的環境は経済、政府、文化などで、それがステークホルダーや組織全体のビジネスプロセス形成に影響を及ぼしうるものです。内的には組織全体のビジネスプロセスにおける高水準パフォーマンス維持のための計画、管理が直接に傾向として顧客の満足度に影響します。そのため、たとえ競合企業と同じ商品を同じ卸売から購入し販売したとしてもビジネスプロセスモデルの管理次第で競合他社に差をつけることができるということです。

ビジネスプロセスの向上

技術の革新やそれに伴う文化の変容とともにビジネスプロセスのモデルも変容していくので、部分的あるいは全体的な向上が必要です。
多くの場合現代の企業におけるビジネスプロセスは以下の要素で構成されています。

• 情報システム
• 従業員
• 経営パートナー
• サプライヤー
• ITインフラ
• データ
• 顧客

BPM(Business Process Management)はこれら要素を鑑みながらビジネスプロセスを向上させていくことです。その根本的な価値は、ビジネスに透明性をもたせ、管理者に何を管理するべきかを明確にすることです。ビジネスに透明性があるということは内的にはそのビジネスが統合されていて効率的でコンプライアンスが保たれていることで、外的には対応の早さや品質、そして対応力の向上に繋がります。

プロセスモデル管理のライフサイクル

ビジネスプロセスはまずそのプロセスの定義から始まります。一度定義されるとそれからは

工程数	工程	関係者
1	プロセスの創製	プロセスオーナー
2	プロセスの分析	アナリスト
3	プロセスの再デザイン	プロセス参加者
4	プロセスの実現	デベロッパー
5	プロセスの監視・管理	システム管理者
1	プロセスの創製	プロセスオーナー

と繰り返していきます。

プロセスモデル創製に必要な要素

• 管理制御
  • 何をしなければいけなくて、それをいつ行うか
  • どのようなイベントがあってそれがどの順序で行われるべきか
  • それが自動化できるものかそうでないか
• アーティファクト
  • なにに取り掛からなければならないか
  • イベントを通して何が入出力されるか
  • それが物理的なものか電子化されたものか
• リソース
  • だれがそれに取り掛かるか
  • 次のイベントへ向けてどのようなリソースが必要なのか
  • 人、ソフトウェア、システム

モデルとは

ここでそもそもモデルとは何をすることなのかを説明します。

モデルは現実の現象を抽象化することです。
モデルは現実の事物・現象から必要な要素のみの集合です。
モデルには、対象があって、その関係者がいて、モデリングする目的があります。

モデル自体が抽象化することですが、定義自体がかなり抽象的です。
そのため決まったモデルがすべての事物にあるわけではありませんし、ある事物に対して複数の適したモデルがある場合もあります。
しかし、状況に応じて適したモデルの選択が重要になります。

抽象化に必要な要素

• 文書化
• コスト計算
• 結果の予測
• 水準の決定
• ワークフロー管理
• ソフトウェア開発
• 統合
• テスト

これら要素を策定していくことでプロセスの全容がモデル化されるのですが、モデルには関係者が必ずしも必要なように、ステークホルダーの種類によってモデルの方向性は変わります。ビジネスのエキスパートなら経営上の利点から、ITのエキスパートなら堅実なシステムの構築を目指すモデルになるでしょう。

BPMN (Business Process Model and Notation)

BPMNはビジネスプロセスのモデル・表記法のことで、国際基準にのっとったビジネスプロセスの正しいモデル方法を提供するものです。詳しくはここで調べられると思います。

BPMNにのっとったプロセスモデルはdraw.ioなどで簡単に書くことができます。

記号

BPMNの適用例（保険適用申請受理時の対応）

これはただの一例でビジネスプロセスによっては多くの分岐や反復を含んでより複雑、イベントの開始事由や終了事由が複数に及ぶこともありえますが、大事なのはその図を読めばよほど特殊な状況でないかぎり汎用的なビジネスプロセスの理解を得ることができます。

より高度なBPMN記号

BPMNに用いられる記号はもっともっとあるのですが、初めてのうちはこれくらいで十分複雑なプロセスフローを可視化できると思います。

モデルのより良い作り方

モデルは以下の点を守るように気をつけて行うことになります。

1. デッドロックの回避 - たとえばXOR分岐してAND結合するなどは永遠に待機することになります。始まったイベントは必ず終わらなければなりません。
2. 正しいプロセスフロー - 分岐の次第で必要不可欠なプロセスを回避できるようなフローはよくありません。
3. 到達できないプロセス - たとえばXOR分岐したプロセスフローが先で互いにAND結合した場合のみ到達するさらなるAND結合がある場合、そこへ到達することはできません。

アーティファクトの追加

アーティファクトとはアクティビティに入出力される必要なデータのことです。
紙のようなアイコンがデータオブジェクトを表し、そのプロセスフローのあいだ有効なものです。
箱のようなアイコンがデータストアを表し、プロセスフローの期間を超えて保持されるものです。

リソースの追加

リソースはビジネスプロセスにまつわる関係者の占める場所とでもいいましょうか。
一番外側の枠組みをプールと呼び、多くの場合会社や部署などビジネスプロセスのイベントが始まって完結するまでに関わる場所すべてを内包できるものです。
内側の枠組みをレーンと呼んで、プールの中でのより細かい枠組みへと別れていきます。
プールもレーンもいくつあってもいいですが、一つのアクティビティが複数のプールやレーンにまたがることはありません。

メッセージの追加

メッセージはプロセスアクティビティ間にわたる情報のことです。
メッセージの流れはやじりが白く、羽が同じく白で丸い点線の矢の線を使います。(拙い語彙)
違うプール同士、レーン同士のやり取りなど情報の行き来が当然あるべきアクティビティの流れを明確にします。
またいくつかルールがありまして、

• シーケンスフローはプールの境界は超えられない
• シーケンスフロー、メッセージフローともにレーンの境界は超えることができる
• メッセージフローは同一##序 モデリングには色々ありますが、ビジネスプロセスを形成するための手法をまとめていきます。

メッセージの追加

メッセージはプロセスアクティビティ間にわたる情報のことです。
メッセージの流れはやじりが白く、羽が同じく白で丸い点線の矢の線を使います。(拙い語彙)
違うプール同士、レーン同士のやり取りなど情報の行き来が当然あるべきアクティビティの流れを明確にします。
またいくつかルールがありまして、

• シーケンスフローはプールの境界は超えられない
• シーケンスフロー、メッセージフローともにレーンの境界は超えることができる
• メッセージフローは同一プール内の２つ以上のアクティビティを繋げることができない
• メッセージの送信は送信元のアクティビティが完了したときに行われる
• メッセージの受信があるアクティビティは受信が完了してから行われる

サブプロセス

プロセスが肥大化・複雑化してくると、可読性が低くなってきます。
そこで始点と終点がはっきりしていて、何かしらの分岐と収束があるような処理を副次的なプロセスとして縮小して表現します。

サブプロセスの記入においてのルール

• シーケンスフローはサブプロセスの外部への垣根を超えられない
• メッセージフローは垣根を超えられる
• 始点は複数あってもよいが、先に満たされたものが開始される
• 終点が複数ある場合それはXOR分岐であり、サブプロセスの後はXOR分岐でサブプロセスの終点が分岐条件となる

再利用できるサブプロセス

プログラムにおける関数のように定義したサブプロセスを任意の時点で呼び出すことができます。
呼び出しするサブプロセスは太い黒縁で表現します。

反復できるサブプロセス

起点と終点が一つのみであり完了のための条件がある繰り返し処理は以下のように記述します。

しかしループできるものは単一の始点と終点がある場合のみで、特定の条件で別の終点へと行き着くようなものはループではなく恣意的なサイクルと考えて、サブプロセスの再利用には当てはまりません。

複数の実体をもつプロセス

たとえば競売のような複数のロケーションから同じ類の情報を得て、一つに選んで先に進むような処理をわかりやすくするために、プロセスに三本縦線のアイコンでそれを表現します。
AND分岐地獄を防ぐための処理ともいえます。
付記には完了条件や収集情報の濃度(Cardinality)がわかるようにします。

アドホックサブプロセス（仮サブプロセス）

まだプロセス解析の初期段階では順序の判明していないアクティビティの集合がそのすべての完了をもって次へ進める場合やそのうちのいくつかのみの完了で良い場合などに条件をつけて順不同な処理の集まりとして記述します。
太い旗のような記号を付記します。

イベントハンドリング

イベントは今まではただの丸でそのプロセスのトークン移動のためのものでしたが、より細かいサブイベント的な記号を用いてさらにわかりやすく仕上げていきます。

メッセージイベント

メッセージの送受信などそれしか行わなず、メッセージの受信によってはじまる一連のプロセスはメッセージイベントとして処理します。イベントと同じ丸に手紙のアイコンを施したものを用います。そしてこの場合、ただの丸のイベントはタイプのないイベントで、発生・終了の詳細が条件の必要ないものと定義されます。

一時的なイベント

ビジネスプロセスは一般的に時間的な制約を考慮しないものですが、ときに時間的な遅れが最初から考慮されている場合などに用います。
時計の記号を用いたイベントで、その待機時間を記入します。

イベント由来の分岐

一般的なXOR分岐はそこに到達すると同時に条件を確かめて振り分けられますが、イベント由来の分岐では分岐に到達してからイベントの発生を待機することになります。丸に五角形が入った分岐記号を用います。

イベントの強制終了

分岐などによってそのビジネスプロセスがサブプロセスなども含めてすべて終了するような状況は丸に黒丸の記号ですべてのフローの終了を意味させます。

例外

例外の処理はサブプロセスなどにおいてよく用いられます。ことさらその例外の状況に副次的な終了までのプロセスがある場合などに使われます。

主にこの三種の例外があります。

メモ

おいおい追加していきます。