成果物は同じでも、プロセス開始のキッカケは様々

「社員から申請されるケースもあれば、経理から確認するケースもある」

そう。世の中の業務プロセスは、毎度同じキッカケで開始されるわけではない。むしろ多くの業務プロセスで、複数のキッカケ（トリガーと言う）が想定されるべきだ。

第7回目となる「BPMNの書き方」のテーマは「複数トリガーの想定」。

＝過去の「BPMNの書き方」＝

• 『業務フロー図表記法BPMNの基本は「分岐」だ』 
• 『案件によっては同時並行処理が必要になる業務フロー』
• 『業務フロー途中で「定型メール」を自動送信』
• 『「子プロセス」を産む業務フロー定義の書き方』
• 『トークンが無限増殖するループ構造』
• 『業務フロー図を我流で書くなんて、ダメダメ』（同時並行処理がある場合の中断）

＜各タスク名＞
1abc.タスク、2.タスク

[BPMNサンプル-複数開始イベント：「1a.タスク」画面]

＜各プロセスデータ名＞

• 件名

▼プロセスデータ▼

• 文字型(複数3行): 入力データ
• 掲示板型: 社内通信

上記のワークフロー定義では、経理・開発・営業の誰かが作業（1x.タスク）を処理すると、経理の作業『2.タスク』に引き渡される仕組みだ。まさに複数のキッカケ（トリガー）が想定されている。しかし「分岐」もしていないのに「併合マーク」（併合ゲートウェイと言う）が唐突に存在する。なんだかヘンな感じがするかも知れない。

ちなみに、業務プロセスのキッカケが人間作業ではないケースだってある。

• ある時刻になれば、誰かに作業が割り当てられる
• センサーなど外部機器からのデータ伝送を受けて作業が発生する

以下のワークフローでは、経理は例えば「毎週月曜日の朝」に『1a.タスク』を処理する。（他のタイミングに自身の判断で『1a.タスク』を処理する可能性はある）
また加えて、メッセージ開始イベントにより直接『2.タスク』が割り当てられることもある。

なお、最初のタスクが人間の入力系作業である場合に、外部機器からのデータ伝送を想定する事がある。すなわち入力の省力化や簡素化が目的となる。ある程度、外部機器を信用するなら、最初の人間タスクは省略するワークフロー定義になろう。


＜各タスク名＞
1abc.タスク、2.タスク

• BPMNサンプル-複数開始イベント
• BPMNサンプル-複数多種開始イベント