緊急点検も定期点検とほぼ同じフローになるはずだ

『点検そして修繕、それは流れ作業だ』の記事では、シンプルな点検作業ワークフローを示した。

しかし、そもそも点検作業を行うキッカケは何だろう？　確かに定期点検もあるが、クレームや通報と言った何らかの外部通知によって行われるケースも少なくない。「点検データ受信」によって点検フローが自動的に開始されるように定義しておくと便利だ。


＜各タスク名＞
1.点検ポイント入力、2.点検予定日入力、3.点検実施報告、4.修繕予定日入力、5.修繕実施報告、6.確認

[点検業務-点検データ受信：「2.点検予定日入力」画面]

＜各プロセスデータ名＞

• 件名≪場所≫

▼点検ポイント▼

• 文字型: 点検場所GoogleMap
• 日付型: 点検完了希望日
• 文字型(複数3行): 点検作業概要
• 掲示板型: 社内通信

▼点検報告▼

• 日付型: 点検予定日
• 日付型: 点検実施日
• ファイル型: 点検写真
• 文字型(複数3行): 点検実施報告
• 選択型: 点検結果判定(要修繕/修繕不要)

▼修繕報告▼

• 日付型: 修繕予定日
• 日付型: 修繕実施日
• ファイル型: 修繕写真
• 文字型(複数3行): 修繕実施報告

上記のワークフロー定義では、タスク『1.点検ポイント入力』に着手する時点でデータが入力がされた状態になっている。すなわち、事務担当は目視確認するだけでスグに業務を流すことが出来る。
ただ、その場合は『1.点検ポイント入力』で仕事が滞留してしまう可能性が否定できない。もし伝送されてくるデータがどれも信用に足るものならば、以下のワークフロー定義の様にタスク『2.点検予定日入力』から点検フローを開始する形にしても良い。

＜各タスク名＞
1.点検ポイント入力、2.点検予定日入力、3.点検実施報告、4.修繕予定日入力、5.修繕実施報告、6.確認

＜追加プロセスデータ名＞
なし

• 点検業務-点検データ受信-事務
• 点検業務-点検データ受信-点検員