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

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

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


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

[点検業務-点検データ受信:「2.点検予定日入力」画面]
<各プロセスデータ名>
  • 件名≪場所≫
▼点検ポイント▼
  • 文字型: 点検場所GoogleMap
  • 日付型: 点検完了希望日
  • 文字型(複数3行): 点検作業概要
  • 掲示板型: 社内通信
▼点検報告▼
  • 日付型: 点検予定日
  • 日付型: 点検実施日
  • ファイル型: 点検写真
  • 文字型(複数3行): 点検実施報告
  • 選択型: 点検結果判定(要修繕/修繕不要)
▼修繕報告▼
  • 日付型: 修繕予定日
  • 日付型: 修繕実施日
  • ファイル型: 修繕写真
  • 文字型(複数3行): 修繕実施報告


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

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


<追加プロセスデータ名>
なし


0 件のコメント :

コメントを投稿