|
This debrief system is currently being used by Fire
Services in the UK to collect information on incidents and to use it as a tool
to improve operational performance. As it is developed using the Metastorm Business
Process Management toolset, it has many advantages over ‘traditionally’ developed
systems - the key one being flexibility. It is relatively easy to customise an application
to reflect changing needs and this reduces the timescale of development and overall
cost of delivery and support. |
 |
The system can be used to
manage debriefs for Minor and Major incidents.
Minor debriefs are started by any
individual. The application allows anyone whose status is ‘watch’ or ‘officer’ to
start the process. The first person to create the debrief selects whether
it is critical or not. Once started, non critical debriefs will remain available
for others
who were involved in the incident to add their comments. Their comments are consolidated with the original debrief’s comments and documents.
Major Debriefs
are started by Control. A major debrief is defined as an incident where 4 or more
pumping appliances attend (although major debriefs can be requested for any incident
if required).
The contributors are selected from a list of all users of the system
which can be filtered by station, and other configurable criteria. When the initial
form is submitted each of the chosen contributors will receive an eMail with a link
back to a set of forms they are required to complete to provide information for
the debrief. Contributors are
required to log in to the system before being able to complete the forms.
Contributors must respond
within timescales set within the system; reminders are sent as the deadline for
submission approaches. Even if a contributor has no significant information to provide
the debrief must be returned before the process can complete. Contributors can be
removed from the debrief by Control if required.
The debrief process is shown in the map below.
|
|
This
is the Metastorm BPM map which is used to control the flow of the debrief folder.
The design of the workflow means that the system can respond differently according
to whether a debrief is Major or Minor, or if the debrief contains some safety critical
information.
Contributors are requested to provide
information relating to the following:
1.
Command and Control
2.
Operational Procedures
3.
Equipment Use
4. Communications
5.
Agency Liaison
Contributors are asked
to enter details about incident tasks, what worked well and what didn’t work well,
and comments and suggestions can be added.
Once completed an action is taken
which to submit the folder to the debrief team, who are responsible for collating
information into an Ops Report to be discussed at regular debrief meetings. The
system automatically collates submitted information but some editing is desirable
to consolidate the input from the contributors prior to producing the completed
report. |
|
 |
At the end of the process the Head
of Operations can decide whether or not the debrief should be published. Published
debriefs have service wide implications and everyone must read the report with no
exceptions, so the system monitors and records those who have read the report. When
published an eMail is sent to individuals notifying them of publication and requesting
that the report is read within 30 days. A reminder is sent after 20 days. The report
is archived after 30 days.
Unpublished debriefs are archived
and are available for reading. |
|
|
|
|