In today’s business, incident management has been related to a company’s structure for helping internal and external customers. How to handle service tickets? What is the service level on first tier IT problems? Who is “the person” responsible for documenting all of the problems, potential solutions and final outcomes? In a smaller company, we had “the guy”. With a few key strokes he could figure out and fix some of the most complex IT problems. He really didn’t write a lot down like software configurations or passwords. As one could imagine, this became a problem as the customers grew and needed help from more than one person. We started writing things down, keeping logs, tracking passwords on a whiteboard etc.

I now work at SitScape and some of our software capability was born out of a need to bring order to the chaos above facing today’s business. In order to track specific large scale incidents our software has the concept of “Bundle” of “Pages” (Digital “Operating Picture”) where each Page represents a visual work-space or dashboard that can house an unlimited number of “Objects”. We could see the use of a bundle (of pages) for Dev-Ops, a bundle (of pages) for a specific customer or just a bundle of pages that focused each on specific parts of a project that needed to be tracked. This hierarchical system turned out to be very flexible in what it could represent and store.

Flexibility, Agility, Visual, Ease-of-use and Self-Services are the keys here. In the world of incident management, there are many software packages that are purpose-built to handle a workflow designed for it. That is to say a package like WebEOC has a specifically defined workflow where users are taught to do A then B then C. In a perfectly structured world this is ideal. As long as we can get C to always follow B which always follows A, we win. The phrase I hear the most after training is “I like WebEOC but what if we need it to do this?” or what if we want to use it for more than incident management? How about real-time collaboration or sensor monitoring?

Today SitScape has grown into a comprehensive software platform and environment, and it is much more than just bundles of pages of objects. One can now find concepts of incident management being used in every facet of commercial environments as well as government in the way of “Emergency Management Procedures”. The question is “is SitScape flexible enough to handle all of these different types of incident management and the answer is Yes.

So let’s talk a little about how a group of users can manage information using SitScape. First we need to establish a group of users in SitScape responsible for managing this and other like incidents. Once that is done then we need to evaluate our incident or emergency to determine how broad reaching it is. Will only a single or just a few documents suffice to represent this incident and should it be grouped with other like incidents? If the answer is yes then we need to establish an overarching bundle for all of these minor incidents and then a page that will hold all of the documents, images, recordings etcetera that will represent our crisis and its resolution.

Let’s suppose for a second that our emergency is big. It is not a five minute fix or a single security breach. No, this crisis will require interaction from many different participants in the group and many different documents to not only represent it but also its eventual solution. Well, we should start out with a bundle just for this incident. Add to this bundle the following pages:

• A page for team chatter. This page should have:
  • A link object that points to a page containing “Operating Procedures” documents for this type of incident for reference.
  • A document object to track participants and their contact info as well as their roles
• A page dedicated to describing the incident complete with videos
• Possibly monitoring page containing:
  • Social media objects to monitor Twitter and Instagram feeds
  • Objects that show live video feeds of the incident or newscasts
  • An incident board to track continuous updates from participants
  • A form to update that incident board
• A public facing community briefing page to track a course to resolution
• A dashboard page for each participant to track individual user email, video conferencing endpoint or personal notes on the incident.
• How about an executive briefing page to house documents supplied by each subordinate.
• A resolution summary page that tracks after action reports

 

Wow that seems like a lot of stuff but actually that is just the tip of the iceberg when it comes to incident management. So many more things need to be tracked and likewise so many more things can be done using SitScape. Here are a few more.

• Chat real-time with other participants in or out of a group setting.
• Keep a running log of all communications between participants.
• Import and review data visualization and statistics and other data about, well almost anything
• Participate in real-time with others on the same dashboard to collaborate on an incident
• Share any type of document or digital artifact with others inside or outside of your group including other pages and bundles
• Use a dashboard by yourself or with others to whiteboard ideas and concepts
• Track and audit all user actions in the system for analysis

Yes, incidents can range from something as small as a single security breach to a major continental catastrophe and yes, SitScape can handle it. You can go from day to day monitoring right through after action reports in one system with SitScape.