では「アドホック」とは何か？ たぶん上手く説明できないが、「アドホックなネットワーク」や「アドホックな作業場所」などの用例で使われ、「恒久的でない」とか「その場しのぎ」と理解するのが良いだろう。
ワークフロー（業務プロセス）の世界でも、「アドホックなタスク」や「アドホックなワークフロー」と言う表現がある。平たく言えば担当者や作業順番が決まってない一連の作業だ。例えば、書類の回覧、複数人の承認などが例示されることが多く、「ワークフローシステム」で対応すべきか、「グループウェア」で対応すべきか、議論が分かれる。
第８回目となる「BPMNの書き方」のテーマは「アドホック（ad hoc）なタスクの定義方法」。
＝過去の「BPMNの書き方」＝
- 『業務フロー図表記法BPMNの基本は「分岐」だ』
- 『案件によっては同時並行処理が必要になる業務フロー』
- 『業務フロー途中で「定型メール」を自動送信』
- 『「子プロセス」を産む業務フロー定義の書き方』
- 『トークンが無限増殖するループ構造』
- 『業務フロー図を我流で書くなんて、ダメダメ』（同時並行処理がある場合の中断）
- 『成果物は同じでも、プロセス開始のキッカケは様々』（複数トリガーの想定）
＜各タスク名＞
1.タスク、2.タスク
[点検業務-点検データ受信：「2.タスク」画面]
＜各プロセスデータ名＞
- 件名
- 文字型: 作業内容
- 文字型(複数3行): 作業Ａ報告
- 文字型(複数3行): 作業Ｂ報告
- 文字型(複数3行): 作業Ｃ報告
- 掲示板型: 社内通信
- 選択型: 作業完了フラグ(完了/未完了)
「定義されていないフローを定義する」という時点でナンセンスな話だが、一つの考え方として、作業手順が決まっていない部分を大きなタスクとして定義してしまい、グルグル回すのがオススメだ。（厳密には「サブプロセス」あるいは「アクティビティ」と呼ぶべきで、すでに「タスク」と呼べない、が気にしない…）
ただこの場合、アドホックな作業群がキッチリ終了している事を把握する事はむつかしい。そんな場合には、以下のワークフロー定義の様に、同時並行処理として作業自体を分解しておくのも一手だ。
ちなみにQuestetraで利用する事ができる「グループスイムレーン」は、BPMNで定義されているものではない。
＜各タスク名＞
1.タスク、2.Ａタスク、2.Ｂタスク、2.Ｃタスク
0 件のコメント :
コメントを投稿