3-3.課題が明白なプロセスで活用すべし
当然の話ながら、その取り組みが何かを改善するならやるべきですが、改悪するならすべきではありません。
BPMNでビジネスプロセスを描画するにしても、対象とするビジネスプロセスに課題が少なければ、その取り組み自体の効果が低くなります。慣れてくるとBPMNで描く事自体が楽しくなってくるのですが、作図自体が目的になってはいけません。
では久々に（？）、回答が遅い問合対応プロセスを見てみる事にします。
＜図2＞
上流も下流もなく、誰から誰に流れるでもなく、すでにビジネスプロセスとは呼び難いレベルです。
BPMNで描画するまでもなく多くの問題を抱えていますが現実に良くある状態です。
メールソフトが「タスクの墓場」になるパターンです。
如何でしょう。「技術部門の助言」や「リーダの差し戻し」に耐えながら回答文を書き上げるビジネスプロセスを描いてみました。タスク放置を許さないビジネスプロセス定義は管理職の重要な責務です。
「開始アイコン（開始イベント）の中に手紙があるぞ！」
あ、はい。自主的な開始以外にも、外部からのメッセージをきっかけにプロセスが開始される場合もあります。
「開始アイコンが二個あっても良いのね！」
例によって「線路と列車」をイメージしてもらえれば良いのですが、始発駅や終着駅が複数存在しても問題ありません。
「黒い手紙と白い手紙があるぞ！」
目ざといです。
しばくぞ詳細は、BPMN初級で説明します。基本的に、円の中の手紙が黒いものは黒ヤギさん、白い手紙は白ヤギさんが書いたものです。
3-4.BPMNによるビジネスプロセス定義では分からない情報
これまで説明した様に、BPMNは現実のビジネスプロセスを簡易表記するための記法です。
しかし良く考えれば、いくつか重要な情報が欠落しています。
たとえば、上流タスクから下流タスクに受け渡しされるデータフォーマットは全く分かりません。
更に言えば、上流タスクを実施した人によっては、下流タスクの実行者を制限するのが効率的ですが、BPMNそのものはそこまで限定できません。
BPMNは基本的に、全体骨格情報だけを描画し、詳細にはこだわらない流儀です。
