「BPM とかを読み下す」までの流れ

BPMN

ビジネスモデルは BPMN という「書く人によってなんとなく書かれるモデル図」として記載される。
BPMN の内容とチケットの内容を紐付けると次のようになると思う。
(この記事を参考にさせていただきました)
[フローオブジェクト]
イベント = status (todo, done)
アクティビティ = status(doing など)
ゲートウェイ = 完了の定義
[接続オブジェクト]
シーケンスフロー = チケットのステータスの通る場所(頭の中にある)
メッセージフロー = プログラムでフックしてればメールが飛ぶかもね
関連 = ステータスのフローを作る時に注意すべきこと
[スイムレーン]
プール = アサイン
レーン = ロール
[成果物]
オブジェクト = チケットに添付するもの
グループ = 対応するものなし
注釈 = チケットのコメント

BPMN は UML はわかりにくいからわかりやすくしてやったぜ！という
意気込みのもと作られたらしいが、はっきり言ってわかりにくいと思うよ。

アクティビティに対する条件を記載するのは、注釈とゲートウェイでフロー管理するんだろうけど、ちょっと厳しいと思う。拡張されたアクティビティは、現実に対応するためとはいえ筋が悪い。
ループは、ゲートウェイを通るまでやるということなので、特に書く必要を感じないし
アドホックは、ワークフローがひとつにしか流れないという前提と戦っている。

ここに記載されていますが、BPMN で表すのは UML のアクティビティ図の部分 だけ。
IT システムを作るには、アクティビティ図はホンの一部なので BPMN が出来れば簡単にシステムが出来ると勘違いしないほうが良いと思います。発注する人はわからないかもしれませんが、こんなのは コンサルが金をとってくための紙切れですよ。ほほほ。この紙切れを作るのに、数週間もかけてしまうようなら、プロジェクトのやり方を考えなおしたほうが良いかもしれません。

BPMN 自体は、図 なので解釈できる必要があります。
そこ出てくるのが BPEL です。

BPEL

BPML を機械化するための変換処理機構全般の呼び名。
WS-* の亡霊とも言うべき WS-BPEL という規格もあるらしい。
こういうとこを見ると良いですよ

個人的に興味ない。

まとめ

アクティビティの所をプログラム化できるか、できないかで判断していくと早いんじゃないかな。
できるのなら、プログラム化を進めていく。
どうせ完璧なのは、最初からは無理なので サクサク作れる簡単なツールを作っていくと良いのではないでしょうか。

あるアプリを作るために調べたんだけど、コンサル内容が多すぎて、読むのにつかれたよ…
十数サイトをみたのですが、中でも取り上げている 日揮さんの記事が一番わかり易かった。

あれですよ、奥さん。
こうなんじゃないかなー、という日記なので、間違いがあれば指摘くださいな