Damage / Incident Response Workflow: BPMN Version 2
Meeting Chart 1 - as plotted in the community design meeting : anomalously four groups each produced charts
Meeting Chart 1b - as plotted in the community design meeting
Meeting Chart 1c - as plotted in the community design meeting
Meeting Chart 1f - as plotted in the community design meeting
Meeting Discussion 1 - as presented in the community design meeting
Meeting Chart 2 - as plotted in the community design meeting
Meeting Discussion 2 - as presented in the community design meeting
to my opinion it is also important that security has a place in this schedule. eg if an object gets damaged that nobody touches anything unless it is a calamity that can have a wider impact such as fire flooding or any other catastrophy.
Statens Museum for Kunst/KV
Looks fine to us
Hi Robert, interesting observation about security. Is it an over-arching concern, as in there needs to be a security plan? In which case, it might be part of the triggering event Disaster Plan (on the left side of the diagram). Or, are you speaking of a secure place for the damaged work during the process? In which case, we need to insert something about securing a location as a step in the process.
[In place Response], followed by the [Bring Supplies ..] step, should be moved beneath [Non Immediate] and [Immediate] as an alternative to [Move]. Insitu work can also have different levels of urgency.
[Move] and [Notification or Removal] should be replaced with a [Movement] sub-process as all movements can require some form of notification/documentation, but it may be done after the process particularly in a disaster situation.
[Treat] and [Document] should be replaced with a [Treatment] sub-process.
The [Re integration] is effectively a further [Movement] sub-process, it should also be an optional step as the work could have been carried out insitu and no movement may be required. This step should also be separated from the [Report] and [Post-mortem] steps as they may not be sequential.
The order of the [Report] and [Post-mortem] steps could be problematic because the results of the [Post-mortem] may also need to need reported.
I think it might be better to pull the [Report] step out and have it as a flexible additional process that could be optional and repeatable at almost every stage of this process. We may also need to indicate that there could be feed back from the [Report] process which could influence urgency, treatment, movement, etc..