ワークフローサンプル: 障害発生時こそワークフロー手順に従った報告を！

「障害の発生」の公表は、正確性と迅速さが欠かせない。特に「一次発表」までの時間を、如何に短縮できるかが大きなポイントと言える。事業内容（業種）に応じて『障害情報』の発表フォーマットはそれぞれ異なるが、その作成手順（業務プロセス／ワークフロー）には大きな違いはない。

Web事業者（広義の「Webサービス」）
データセンター事業者
SaaS事業者
通信事業者
交通機関
など

なお、忘れられがちな話だが、それらの障害情報を集積しキッチリと分析する事が最も大切だ。障害発生時の業務プロセスを整備するだけでなく、報告時刻などの対応履歴を定期的に分析するようにしたい。

＜各タスク名＞
1.障害検知報告、2.アサイン、3a.一次発表文作成、3b.アプリ一次報告、3c.インフラ一次報告、4a.発表文定時更新、4b.アプリ復旧定時報告、4c.インフラ復旧定時報告、5.一次発表文確認、6.復旧完了確認

障害対応には「順序立てられないタスク」（アドホックなタスク群）が無数に存在する。特に、「障害に関する追加情報」や「外部からのクレーム」などの共有手順やルートは決めづらい。その様な業務プロセスでは、細かいタスクの定義にはこだわらず「骨格となるタスク」だけを定義すべきだ。
なお、この様な非定型なコミュニケーションが発生する場合には「社内SNS機能」が有効だ。Questetra BPM Suite には「ワークフローと連動する社内SNS機能」が標準搭載されている。是非試してみて欲しい。

[障害情報の発信「2.アサイン」]