Standard operating procedures in IBM Intelligent Operations Center Version 1.5

Interim FeaturePak

The Interim FeaturePack for Intelligent Operations Center V1.5.0.1 provides more support for Emergency Response, Citizen Collaboration, Executive Dashboard, and Sentiment Analysis. The Emergency Response feature also provides improved support for the authoring and execution of standard operating procedures. Learn how to use the Interim FeaturePak to define a standard operating procedure and understand the decomposition of "(English) language written" standard operating procedures.

Share:

Bob Patten, Chief Programmer, Intelligent Operations Center Emergency Response and Standard Operating Procedures, IBM

Bob Patten photoBob Patten is a Senior Certified Executive I/T Specialist board member, an I/T Specialist board member, and Open Group Distinguished Certified I/T Specialist. He was the Chief Programmer for the Intelligent Operations Center Emergency Response and Standard Operating Procedures feature. Bob was also the release engineer for the recent Intelligent Cities Planning and Operations product, test lead on the Integrated Information Core 1.4 product and release engineer for the 1.5 version. In a prior position, he was the original developer of the integration between WebSphere Message Broker and WebSphere Service Registry and Repository, and a founding architect of the IBM SWG Componentization Strategic Initiative. He was also chief architect for the Enterprise Application Development frameworks for Java™ (EAD4J) asset.



10 May 2013

Overview

Standard operating procedures (SOPs) are essential to an organization's ability to deliver consistent, measured, high-quality responses to complex events. An SOP might be related to automatically detecting a failure in a sensor and opening a work order to have it repaired, or to dealing with approaching severe weather during a sporting event, or be focused on dealing with a reported bomb blast. Regardless of the reason for the standard operating procedure, if an organization develops a planned, understood (and rehearsed) response to various events it can better respond to that incident quickly, and consistently.

Enhance IBM Intelligent Operations Center-based applications, (developerWorks, July 2012) contains information about the use of Tivoli Service Request Manager to achieve cohesion. Here we learn about the standard operating procedure feature that is part of the Intelligent Operations Center Version 1.5.0.1 Interim FeaturePack.

The Interim FeaturePack provides a line-of-business SOP tool that extends the Intelligent Operations Center product with easy-to-learn, easy-to-use features for authoring standard operating procedures (SOPs).

The SOP runtime includes a flexible and powerful support for systematically managing the SOP activities, including allowing correlation of the activities and the live data of the event or incident. The tool also adds role-specific user interfaces for authoring, enacting, and running SOPs across teams and eliminates manually tracking activities by keeping an electronic record of actions taken during SOP execution.

First, I cover the basics of the Intelligent Operations Center 1.5.0.1 SOP architecture, along with a brief discussion of the tool. Later I provide samples on how to decompose (English) "language written" SOPs into a form that can be easily authored into the Intelligent Operations Center runtime.


SOP tool architecture

The SOP tool extends the Intelligent Operations Center 1.5 infrastructure by providing both authoring and runtime support of SOP creation and execution. The tool provides authoring support with a simple wizard, uses events that flow within the Intelligent Operations Center infrastructure to suggest and automatically trigger SOPs for execution, allows activities to further contribute and coordinate, and tracks and monitors activities for on-time completion.

When events arrive in the Intelligent Operations Center infrastructure, they are processed according to defined rules. Any Common Alerting Protocol (CAP) event or alert can be associated to an SOP, effectively stating that you use this SOP in response to that event or events. After an SOP is started, the defined activities begin, as shown in Figure 1.

Figure 1. Event flow with SOPs
Diagram depicting the event flow with SOPs

Activity types

Activities can be manual, automatic, (email) notifications, event generating, start other SOPs, conditional, and more.

At the simplest, an SOP is a collection of pre-defined activities or tasks that must occur in response to an event or set of events. For example, an airline maintenance operations crew might establish steps that must be done to prepare an aircraft for takeoff, a stadium might want to establish specific procedures in the event of severe weather and use integration to an early warning weather adapter to automatically trigger those activities, or a city might want to establish specific procedures to be followed in the event of a bomb threat or blast. This type of coordination is normal with a workflow engine; however, it generally requires IT programming help to set it up or administer it. The SOP tool provides this function that is directed to the line-of-business user, eliminating the need for programming expertise.

Author an SOP

The Standard Operating Procedure tool integrates with the Intelligent Operations Center infrastructure and provides a straightforward and powerful UI that uses a standard conceptual model for SOP management. The SOP tool supports authoring through a simple editing interface wizard that provides multiple activity types, automatic triggering, a normalized way of handling multiple versions of an SOP, owner/role-based security, and associations to links to a library of reference material.

Before you author an SOP, you must understand the scope of an SOP. This scope places boundaries on the SOP, which limits its activities. Within the tool, authoring a bomb blast SOP is the same as authoring one for scheduled maintenance, but the scope or purpose of the SOP is different.

The next step is to use the tool to author the definition of the SOP. The definition of an SOP consists of four parts; an overview section that includes name and description, an execution owner or role section, an activities or tasks list section, and an event description section that describes events that can cause the launch of this SOP.

Determine the scope of the SOP

All SOPs have a scope and expected usage; for instance, the procedures for reacting to a bomb threat are different from procedures for maintaining an aircraft. Even the response to a bomb threat for a building is different from one for a bomb threat for a subway. Determining the scope places boundaries on how to construct the SOP.

Determining this scope is part of the planning step, whether explicitly documented or implicitly "assumed", that planning is done. For example, if you develop standard procedures for handling explosives for a government agency, you do not create SOPs related to swimming pool incidents. That planned use, or scope, must be understood to specify the activities within specific SOPs.

In addition to the activities, the events that an SOP is in response to help scope those SOPs. For instance, the types of events that are of concern for a 911 crisis center is different from events for planned scheduled maintenance. Standard operating procedures are initiated in response to specific types of events; for instance, in the case of an event that has a category of security and a headline with 'bomb', and an urgency of immediate, the SOP that is started might be "Respond to bomb threat".

Codify the SOP definition

Whether the plan of an SOP was explicitly (or implicitly) stated, by now the SOP scope and the basic set of activities that must be done are understood. The definition of a SOP requires name and description, role and access, activities or steps to do, and any event information that triggers the SOP.

In this step, we begin to codify the SOP, which means naming it and defining the set of activities that must be done if it is initiated. For example, if the plan for the SOP is related to response to flood events, then the scope of activities focuses on responding to the impending flood, not equipment maintenance.

Creation of an SOP is done with the Standard Operating Procedures authoring portlet. This portlet shows all defined SOPs, and allows maintenance on those SOPs. Use the create option to define a new (draft) SOP, as shown in Figure 2. This same portlet is used for editing a SOP as well.

Figure 2. SOP Admin Portlet
Screen shot image of the SOP Admin Portlet window

When the create option is chosen the user is led through a series of steps that are required to create an SOP. These steps involve defining the name and description of the SOP, any owner, or reader roles, the events this SOP is in response to, and the activities to do after this SOP is started. The name and (at least one) activity are required.

Figure 3. SOP creation – Basics
Screen shot image showing SOP creation and the basics window

In the terminology of the Intelligent Operations Center 1.5.0.1 Interim FeaturePack, a standard operating procedure (SOP) is a pre-defined, pre-approved set of activities that are to be done in response to a triggering event or incident. An SOP's activities contain instructions and references for what must to be done to complete the activity, and when all of the required activities are done, the SOP is considered complete.

Figure 4. SOP creation – Activities
Screen shot image showing SOP creation and the activites window

SOP activities represent the set of tasks or steps that are considered standard procedures. Activities can be specified as either:

  • Manual

    Contains a description of the action to be done, along with reference material

  • Notification

    Specifies a particular email is to be sent as part of the activity

  • Automation

    Initiates and tracks a particular work order by using a specific automation interface. This activity type is used with Tivoli Service Request Manager for complete work process management.

  • Event

    Specifies the CAP event that is to be run by that step, allows for one SOP to start others (if they are set for auto-trigger). This type of subordinate SOP does not block the parent activity.

  • SOP

    Specifies that a subordinate (child) SOP starts. The parent waits for confirmation from the child that the activities are complete before the parent activity can complete.

  • If-then-else

    Allows the execution of different activities that are based on the 'answer' provided (conditional logic)

  • REST

    Allows the execution of a specified REST interface, through passing the associated events.

To allow for the assignment of activities across teams, each SOP activity definition can have one or more assigned owners authorized to run the activity, and add more reference material and comments. (See Figure 5.) Other users can be granted reader privileges, where they are granted access rights to view the activities and add comments to them, but not move the activity progress forward.

Figure 5. SOP creation – Owner
Screen shot image showing SOP creation and the owner window

An SOP's event-trigger conditions indicate which SOP to use in response to a specific event instance. When matched, the triggers act as a way to provide a set of SOPs that can be used. If set to auto-trigger, then a match starts an instance of that SOP. For instance, a CAP message with headline 'fire', category of 'safety' and urgency of 'immediate' is an indication the SOP "respond to fire" is more correct that an SOP named "prepare for flood".

Figure 6. SOP creation – Trigger
Screen shot image showing SOP creation and the trigger window

The SOP triggers are based on Intelligent Operations Center CAP events, and support the primary CAP attributes; category, severity, certainty, urgency, headline, and sender.

The Reference Library

The Reference Library is part of the SOP tool in Intelligent Operations Center 1.5.0.1 Interim FeaturePack, and can contain a set of information references that you can add to SOPs and their activities, by either authoring them into the definition or by adding them during execution. Each reference is a Universal Resource Indicator (URI), which points to an information object on the network that is useful in completing an SOP or activity or is used to document that activity. For example, perhaps an SOP must deal with hazardous materials, so at author time a reference might be added that shows a set of images of the common hazardous materials. At runtime, you can add a reference to a picture (from the field) of the handled material.


Use SOPs at runtime, in response to events

The process of deciding how to handle incoming events, concerning SOPs, is considered an event triage. The SOP tool includes a Triage Events portlet that displays the incoming Intelligent Operations Center events that must be triaged.

For each event listed in the Triage Events portlet, the SOP operator can select to handle that event in one of the following ways (by right-clicking on the event):

  • Create a new SOP instance/initiate an SOP based on an event
  • Associate the event to an existing SOP instance
  • Cancel the event

At runtime

To create a SOP instance means to start a set of activities that are defined by that SOP. For instance, start a SOP in response to a fire event.

To associate a SOP instance, means to associate this event to an existing SOP or its ongoing set of activities. For instance, if multiple reports of the same fire were received, each event can be associated to the same ongoing set of activities.

Doing any one of these actions removes the event from the need to be triaged list (note: the event is still available in a Details Event portlet. When events match SOP event trigger conditions, the Create SOP... and Associate SOP... actions display SOPs as suggested (matching the trigger) for the event. SOPs can "Start automatically when triggered", in which the triage occurs automatically, and triggered SOPs automatically start and display in the SOP Activities list portlet.

Figure 7. SOP starting from an event
Screen shot image showing an enlarged window view of an SOP start.

After an SOP starts, the SOP's owner can edit the SOP instance properties, including adding, editing, or skipping the activities (depending on the rules that are stated at author-time). The SOP activity owners can run their activities (Start, Complete, Skip), and add references or comments to this specific SOP instance. SOP activity readers can view and comment on the activities or their containing SOPs.

While doing the activities that are associated with an SOP, the tool automatically logs the actions, changes, and commentary for the SOP and its activities so that an electronic record is available for after-action review.


Decompose an existing 'human readable' SOP

Now that we know how to create an SOP, we will learn how to author one from an English description. The English form usually contains the response plan, which provides the scope of the SOPs, and the list of activities and coordination that must be done. With this information, the SOP can be authored into its codified form.

The codification of a human readable SOP starts first with decomposing it into groups of activities. The following patterns describe the decomposition.

Determine the number of teams mentioned in the SOP. There is a high likelihood of needing to define and codify an SOP for each team. For example, if the written SOP mentions four teams, you might author three to five codified SOPs.

Does the written SOP describe groups of activities that must be done together? For instance, if the description states, "After completing steps 3, 4, 5, then...", the grouping of steps 3, 4, 5 might require defining an SOP to contain this grouping.

How many conditional steps are mentioned? For example, if the description states, "If the area is near a school, then...", there you might author an SOP for that 'then' set of activities.

The next sections use different scenarios along with the patterns we've already covered to explain how to convert the written SOP into a codified SOP.

Scenario 1 – medical alert at stadium

Suppose that for some venue the response for a medical accident states:

    When a medical alert is reported in one of areas of <venue> stadium, the 
    following activities must be done.  First, medical help must be immediately 
    dispatched. After help is dispatched, the operator must call for an ambulance (so 
    that it is in route if needed, there is usually one on site).  
	
    In addition to immediate help, the operator must also alert the legal resources
    (for the stadium) regarding insurance and litigation reasons. The team responsible for
    insurance and risk mitigation must take statements from witnesses, photograph the
    area, make a note of current weather, capture video of the area, and record related 
    information about the accident location (such as alcohol sales in nearby concessions).

If you apply the patterns to Scenario 1, the medical staff would have its own SOP, related to the handling of that medical issue, while the operations and risk mitigation teams would have their own SOPs. Thus there might be three to four different SOP definitions.

In Scenario 1, there is a grouping order that is specified in that the medical team must be dispatched and confirm a medical accident before the risk mitigation team is contacted. In this scenario, there is also the risk mitigation team that has a set of required tasks that they must do, such as take witness statements and photographs.

And, there is the conditional response that is based on the report from the first responders / medical team.

Based on this decomposition, we would have these SOPs (and their corresponding activities):

SOP – 911 - Respond to medical accident
This SOP is the root operations center SOP. It is in response to either a 911 call or 911 event that opens within the Intelligent Operations Center infrastructure.
  • Activity: Gather initial information about accident. Determine the location (if not available through a mobile app), the type of accident, and the state of the person injured.
  • Activity: Dispatch medical team. This activity would start a new SOP, which would be owned by the medical staff. This set of tasks must happen in parallel to all other tasks.
  • Activity: If the medical team reports that the accident is not resolved and is not stadium-related, contact ambulance.
  • Activity: If the medical team reports that the accident is stadium-involved, then contact RM&IM teams. If the accident is because of a heart-ache, another set of activities must take place, but (for this scenario) it is the risk mitigation and incident response teams that must be contacted as the stadium is involved (for instance, tripping walking up the stairs).
Respond to medical dispatch
This subordinate SOP is owned by the medical team who responds to the incident. The specifics of this SOP are not provided in this written context, so for this discussion we limit it to a two activities.
  • Activity: Give medical help.
  • Activity: Report back to operations on accident.
Respond to risk mitigation dispatch
This subordinate SOP is owned by the risk mitigation team. These activities can happen in any order.
  • Activity: Take statements from witnesses.
  • Activity: Take photographs of accident area.
  • Activity: Take photographs of accident victim.
  • Activity: Save video images of area during accident timeframe.
  • Activity: Collect information about weather.
  • Activity: Collect information about area cleanliness.
  • Activity: Collect local concession information.
  • Activity: Collect other information that pertains to the accident.

Scenario 2 – pre-flight, departure preparation

Suppose that at an airline and airport, that after a plane arrives at the gate there is a set of tasks that must always be completed before the plane is cleared for takeoff. The airport operations staff informs the airline operations staff that the plane is at the gate ready for services. The (English) 'language written' SOP for the airline is written as:

    When a plane arrives at the gate, complete the following set of tasks.  
    Time starts upon opening of any aircraft door, and all activities much be completed 
    within 45 minutes (by airport policy).
	
    The gate crew is responsible for passenger offload and cabin preparation is 
    complete.
    
    The ground crew is responsible removal of waste (solid and fluid) and the 
    replacement of aircraft fluids (gas).
	
    The aircraft crew is responsible that the aircraft is showing all clear,
    regarding all gauges and indicator lights.
	
    The baggage crew is responsible for offloading and on-loading of all 'baggage'.  
	
    The on-board service crew is responsible for making sure the food, beverage, and 
    other passenger service items are replenished.

In Scenario 2, we see that there are five to six teams, which means five to six possible SOPs. In this case, there is the gate crew, ground crew, aircraft crew, baggage crew, on-board service crew, and the overall operation control (ATC) crew. Each of these teams has parallel activities that they must do before the aircraft is readied for flight. Because the aircraft is not ready until each SOP is done, there is also a group condition.

For brevity sake, I do not cover all the steps necessary for pre-flight validation. The goal of an SOP scenario is to describe the parallel activities and timing, not all of the steps that are required for a real-world checklist.

Prepare flight for departure
This SOP is the root airport pre-flight requirements. The 'ATC' airport team does not do the tasks. They inform the airline when it can begin. Policy determines when the airline must have the plane ready for departure.
  • Activity: Inform airline of aircraft availability (at gate). This activity uses the subordinate SOP Respond to prepare aircraft for departure. If this activity is completed within the timeframe (45 minutes), then the aircraft is ready. This activity is not done until the subordinate SOP is completed.
  • Activity: If the aircraft is departure ready (airline completed task within specified timeframe), then proceed. Otherwise, place the aircraft in delayed state.
Respond to prepare aircraft for departure
This SOP is used by the airline operations to prepare the aircraft for departure.
  • Activity: Start Prepare flight for departure (Gate Crew), which would use an SOP activity type to start the stated SOP. The duration would be set to 45 minutes.
  • Activity: Start Prepare flight for departure (Gate Crew), which would use an SOP activity type to start the stated SOP. The duration would be set to 45 minutes.
  • Activity: Start Prepare flight for departure (Ground Crew), which would use an SOP activity type to start the stated SOP. The duration would be set to 45 minutes.
  • Activity: Start Prepare flight for departure (Aircraft Crew), which would use an SOP activity type to start the stated SOP. The duration would be set to 45 minutes.
  • Activity: Start Prepare flight for departure (Baggage Crew), which would use an SOP activity type to start the stated SOP. The duration would be set to 45 minutes.
  • Activity: Start Prepare flight for departure (On-board Service Crew), which would use an SOP activity type to start the stated SOP. The duration would be set to 45 minutes.
  • Activity: If all the teams complete preparation (all prior activities are completed on-time), then inform Airport Operations of aircraft readiness. Otherwise, inform Airport Operations that there is a delay.
Prepare flight for departure (Gate Crew)
This SOP is the gate crew's set of activities.
  • Activity: Offload all passengers.
  • Activity: Wait for cabin preparation complete.
  • Activity: Inform airline operations of status (ready for departure, or not).
Prepare flight for departure (Ground Crew)
This SOP is the ground crew's set of activities.
  • Activity: Remove all waste from the aircraft.
  • Activity: Replace gas and other fluids.
  • Activity: Inform airline operations of status (ready for departure, or not).
Prepare flight for departure (Aircraft Crew)
This SOP is the aircraft crew's set of activities.
  • Activity: Verify that all the gauges and indicator lights are 'green'.
  • Activity: Inform airline operations of status (ready for departure, or not).
Prepare flight for departure (Baggage Crew)
This SOP is the baggage crew's set of activities.
  • Activity: Offload all necessary baggage.
  • Activity: Load baggage.
  • Activity: Inform airline operations of status (ready for departure, or not).
Prepare flight for departure (On-board Service Crew)
This SOP is the on-board service crew's set of activities.
  • Activity: Load food and beverages for passengers and crew.
  • Activity: Verify and load blankets and magazines.
  • Activity: Inform airline operations of status (ready for departure, or not).

Scenario 3 – Severe weather event at <venue>

In this scenario we are dealing with an outdoor venue. Suppose that specific procedures (SOPs) were created in the event of severe weather. For instance, suppose that a 'written' SOP states:

    If a lightning strike is detected within five miles of the venue, during a time when
    the venue is in use (game in progress).  The system automatically triggers an 
    SOP to (potentially) evacuate the stadium.  

    The first activity is for the operations center director, who must determine whether
    the evacuation/seek shelter must proceed. When the director receives the activity to 
    approve the evacuation, the director reviews the weather information in the 
    Intelligent Operations Center, including the lightning alert that triggers the SOP.  

    If evacuation/seek shelter is the right course of action, the SOP then triggers 
    parallel activities for the usher supervisor and the security supervisor to alert 
    their staff of the evacuation.  Activities direct the ushers to prepare specific 
    rooms, move the security personnel to the exits, and opens all exit gates. After 
    these activities are complete, the SOP automatically sends alerts through the fan 
    experience app and to the stadium displays asking fans to move to shelter.  

    The operations director must determine when the evacuation can be lifted so the 
    sheltering fans can be released. The director determines that it is safe then lifts 
    the evacuation. The ushers and security supervisors receive notification that 
    they can move the fans back to their seats.

Scenario 3 indicates that three to four teams are involved. There are simultaneous or parallel groups of activities. There are also conditional steps to do, hence individual SOPs that to define.

Based on this decomposition, we have these SOPs (and their corresponding activities):

Respond to severe weather alert
This SOP is targeted to the Operations Center director, or the Op Center in-site lead, and is automatically triggered based on an event with the attributes; category='Met', severity='severe', urgency='immediate', headline starts with "Intelligent Operations Center ER Severe Weather Alert".
  • Activity: Review weather alert and other information sources to determine whether an evacuation is needed. Severe weather is detected, but the decision to evacuate is the responsibility of the Ops Center.
  • Activity: Based on weather alerts and other information, if the decision is to evacuate, then send an event with attributes; category='Met', severity='severe', urgency='immediate', headline starts with "Evacuate Venue". Otherwise, no further action is required.
Respond to seek shelter/evacuate venue (Security response)
This SOP is targeted to the security lead, and is automatically triggered based on an event with the attributes; category='Met', severity='severe', urgency='immediate', headline starts with "IOC ER Severe Weather Alert".
  • Activity: Open all exists.
  • Activity: Position all security to pre-defined evacuation points.
  • Activity: Notify operations all preparations are complete. This activity issues an EVENT with the attributes category='Met', severity='severe', urgency='immediate', headline starts with "Evacuation Prep complete".
Respond to seek shelter/evacuate venue (Usher response)
This SOP is targeted to the lead usher, and is automatically triggered based on an event with the attributes; category='Met', severity='severe', urgency='immediate', headline starts with "IOC ER Severe Weather Alert".
  • Activity: Prepare shelter rooms for use.
  • Activity: Notify operations all preparations are complete. This activity issues an EVENT with the attributes category='Met', severity='severe', urgency='immediate', headline starts with "Evacuation Prep complete".
Respond to seek shelter/evacuate venue (Global notify)
This SOP is targeted to the Operations Center who must alert all people in the venue, and also sounds the all clear. This SOP is automatically triggered based on an event with the attributes; category='Met', severity='severe', urgency='immediate', headline starts with "IOC ER Severe Weather Alert".
  • Activity: Send notification to "fan experience app" and master venue display. This activity sends an EVENT, with attributes; category='Met', severity='severe', urgency='immediate', headline starts with "Severe Weather detected – seek shelter". It is expected that the "fan experience app" and the master large screen can respond to this event.
  • Activity: Monitor weather for 'all clear'.
  • Activity: After an all clear can be given, notify security and ushers. This activity issues an EVENT with the attributes category='Other', severity='minor', urgency='unknown', headline starts with "<Venue> All Clear".
  • Activity: After all clear can be given, notify fans. This activity issues an EVENT with the attributes category='Other', severity='unknown', urgency='unknown', headline starts with "<Venue> All clear".

Scenario 4 – Respond to reported bomb blast

Suppose that a bomb blast is being reported to a 911 call center, where the 'written' SOP to follow states:

    911 operator takes initial information that pertains to the blast, injuries, and 
    property damage.

    As soon as the initial information is known, the 911 operator must contact the 
    following agencies; local police department, area demolition team, local SWAT team, 
    and medical/fire/rescue as the situation warrants. Also, notify state and federal 
    ATF, governmental leaders, and media. Raise the alert level to critical.

    The local area demolition team commander is considered incident commander once 
    onsite, and is charged with clearing the local area of hazardous materials, removal 
    of secondary explosive devices, and establishing safe lanes of travel for medical and 
    rescue teams in coordination with area Traffic Management teams.  

    After safe lanes of travel are established, EMS teams will inform the incident 
    commander (IC) of the casualties and expected triage that is required. The IC 
    appoints one person as the lead for EMS transport and coordination.  

    After victims are removed from scene, crime investigation assumes responsibility, and 
    SOP CSI -Investigate bomb blast.

    Lower severity to caution for 24 hours, then to green.

Using the same patterns, the decomposition would have these SOPs (and their corresponding activities):

Respond to reported bomb blast
This SOP is targeted to the 911 operation center, and is automatically triggered by a CAP event with the attributes; category='CBNRE', severity='severe', urgency='immediate', headline starts with "911 – bomb blast".
  • Activity: Capture information that pertains to location, injuries, and local damage.
  • Activity: Contact local police (closest station to blast).
  • Activity: Contact area demolition team.
  • Activity: Contact local medical, fire, and rescue.
  • Activity: Notify state and federal ATF.
  • Activity: Notify government leaders.
  • Activity: Notify media.
  • Activity: Raise alert level to critical.
  • Activity: Transfer control after area demolition lead is onsite, begin Clear and Notify.
Clear and Notify
This SOP is targeted to incident commander and is about identifying if any secondary devices exist, securing the lanes of travel for medical and rescue, and securing the broader area. These activities must be done in order.
  • Activity: Determine whether any secondary devices are in the area.
  • Activity: Establish safe lanes for medical and rescue team.
  • Activity: Notify TMS and validate route.
  • Activity: Dispatch EMS to onsite locations.
  • Activity: Establish EMS coordinator; this activity would start a new SOP that is owned by the appointee, and done in parallel.
Coordinate EMS
This SOP is targeted to the appointed EMS coordinator.
  • Activity: Do the coordination. No more detail for brevity sake.
Investigate crime scene
This SOP is targeted to an investigation to determine who was involved and responsible.
  • Activity: Investigate the crime. No more detail for brevity sake.

Summary

The Intelligent Operations Center 1.5.0.1 Interim FeaturePack SOP tool provides easy-to-use features for authoring Standard Operating Procedures (SOPs). This tool is also the base for SOP functions in the next Intelligent Operations Center release. SOPs can be emergency procedures to follow in response to some incident, standardized procedures for normal maintenance activities, or pre-planned responses to specific events.

Resources

Learn

Get products and technologies

  • IBM Smarter City Solutions on Cloud: IBM Intelligent Operations Center on IBM SmartCloud offers a straightforward, user-based subscription service at a single price that includes all costs, including hardware, software, maintenance, support, and networking.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Industries
ArticleID=872898
ArticleTitle=Standard operating procedures in IBM Intelligent Operations Center Version 1.5
publish-date=05102013