bharatbhasha.com
Free Articles  >>  Computers and internet >>  Page 35  >> 

Creating Incident Management System Software Part 3 The Log







In the previous articles we have covered: Levels of Depth (Part 1) - The concept that the system should only expose complexity as a user needs to dive deeper into details. The Incident (Part 2) - The Incident serves to link together the more detailed information that relate to an Incident.

This article, Part 3 - The Log is all about creating a logging capability that makes for a world-class system.If there is a single capability to invest in it is The Log. When the Log is done well, it is singularly the best tool for gathering information and getting a handle on a situation. If The Log is done poorly the whole IMS is at risk of not being used or jettisoned in favour of clipboards and notepads.The Log allows capture of simple text information and it should automatically record the date and time that the system recorded the entry (i.e. when it was entered); the date and time that the entry occurred (you will still have paper notes for rapid call logging); the operator (name and role) that made the entry; and perhaps the workstation that was used to make the entry.There are a minimum of two Log tools that you should have and a third level-of-depth will help if you manage a large number of incidents or have a large organization that is brought to bear - the General Log, the Incident Log, and for some larger agencies, the Duty Log.

GENERAL LOG At the highest level you'll need a General Log for items that are either routine and non-incident related (e.g. shift changes, general weather statements, administrative items) and to record significant occurrences that affect the whole operations of your organization (e.g. EOC activation/deactivation, Area-wide severe weather) or all of the active incidents. You will want to consider allowing the lower-level logs to be referenced so you can add an item at the General Log level but have it copied/linked to one or more of the Incidents that are active.

INCIDENT LOG For every Incident you will need an Incident Log. The Incident Log provides a place to log key events and occurrences during an incident. Any information that is relevant to the incident, either immediately or post-incident should be logged in the Incident Log. The audience of the Incident Log is incident-centric, either for situational awareness or forWhen an entry is made in the Incident Log you will want to allow the user to automatically add the entry to the General Log as well. This capability will allow your operators to keep the overall organization up to date without having to take extra steps.

DUTY LOG Following the levels-of-depth approach, if an Incident is large-scale or is supported by many distinct groups in your organizations it may warrant the addition of Duty Logs. Duty Logs keep domain-specific information separate so it doesn't clutter up the information that users that aren't in that domain see. For example, under an ICS organization there may be Operations, Logistics, Finance, etc. Other organizations may break Duty Logs out by supporting organization (e.g. Public Works, Health, Security). The ICS and non-ICS approach can also be combined.Access to the creation of Duty Logs (i.e. the addition of a particular Duty Log category to an Incident) and the ability to add information to a particular Duty Log may be restricted to avoid confusion.When an entry is made in the Duty Log you will want to allow the the user to automatically add the entry to the Incident Log as well. This capability allows the Duty staff to keep the Incident current with key Incident-level information that they are providing.

ACTIVITY LOG (AUTOMATED LOGGING) There is a second kind of log that you should consider when creating IMS software. This is an automated log that captures all of the changes that are made during the prosecution of an incident. Changes in resource assignment, task status, incident description, and other items should not require a manual log entry to be made. The system should keep a running activity log of all changes. This can be used in the heat of an event for situational awareness or after the incident has been closed as a post-mortem tool. All Activity logs should contain the user that made the change, the date and time of the change, and if possible, the data that was changed (both before and after).You will want to limit the events that automatically create General and Incident Log entries to ensure that you don't overwhelm and clutter your logs.

KEY DESIGN DECISIONS The following decisions need to be made as you implement The Log.

LINKING TO LOG ENTRIES Where there are existing log entries you will want to allow users to link an existing entry to another log. For example a General Log entry about the weather situation may be directly relevant to a particular incident so you will want to link a copy of that log entry in to the Incident Log. The linkage should be a "shallow copy" (i.e. points to the original and doesn't duplicate the entry) and store the date and time that it was linked in to the incident.

EVENT DRIVEN LOGGING Though the system should capture all of the activity in an incident through the Activity Log, there will be key changes that will warrant creating an entry in the General or Incident Log. For example, the creation and closure of an Incident should automatically create an entry in the General Log. This will allow people reading the General Log to get an idea of when major events happened and it means that the users don't need to make manual entries. Consider event driven log entries for event such as Incident creation/closure/re-opening, SOP Activations, SOP completion, etc.

LOCATION If the location of the computer or mobile device is available for a log entry you may want to consider adding it to the log. The value of the location data will depend on your GIS implementation though (a later topic). This capability would be more "bleeding edge" than the norm, but location information is becoming more and more relevant for operational use.EDIT or DELETE - A decision needs to be made about whether your log will allow editing and/or deleting of log entries. Regardless, the system should never actually modify the original entry.

EDITING A LOG ENTRY: In the heat of an incident there are often log entries made with spelling, grammar, and other minor errors. A business decision needs to be made about whether the log should allow editing of these minor errors to allow the log to be cleaned up. If the system allows editing, the user should be presented with the original log entry that they can modify (the text, and the date & time). The system must never modify the original log entry, it should simple be marked the original log entry as "old" and a new entry should take its place.When editing is allowed, Log entries that have been edited should have an explicit way to view the original entry. Additionally you will want to consider showing any edited entries in log reports. Nobody wants to see the errors, but when an edited log entry is shown, knowing that the changes were immaterial is very important.

DELETING A LOG ENTRY: Deleting log entries should only be considered in an advanced system where the system has been in use for a long period of time. The confusion that can result from missing log entries is one thing. The legal ramifications are another. Regardless, if a system will support entry deletion there must be an explicit indication in all user-facing parts of the system that an entry has been deleted - the user interface, reports, and other records need to reflect any deletions. The simplest way to provide this capability is to present the original log entry with strikethrough text. The system may also provide the ability for a user to provide reason for deletion. If the system does support adding a reason for deletion that information should be available to users and in reports.

TAMPER PROOF: Regardless of whether your system should support Editing or Deleting entries, you will want to consider how the back-end prevents modification of the Log entries. If there is a high need for legal support of a logging system there may be a need to use some kind of cryptographic approach to prove that the contents of a Log entry have not been modified without the proper system-generated audit trail being subverted by modifying the database directly. There are various approaches that can be used to support making a log entry tamper proof but they are beyond the scope of this article. The key thing to consider is whether you need this kind of capability or not.

In this next article we will cover another key area that will ensure your organization is well prepared - Contacts.


About Author Darrell ODonnell :

Darrell O'Donnell, P.Eng. is the President of Continuum Loop Inc. He has been advising clients and creating situational awareness systems for over 15 years. Systems that he has created have been used to provide situational awareness around the world and they have been used to manage hundreds of thousands of incidents in search and rescue, military, and civilian domains.&nbsp; <a href="http://www.continuumloop.com" target="_blank">http://www.continuumloop.com</a>


Article Source: https://www.bharatbhasha.com
Article Url: https://www.bharatbhasha.com/internet-and-computers.php/476413


Article Added on Thursday, July 10, 2014
LD
Other Articles by Darrell ODonnell

Creating Incident Management System Software Part 5 Managing Resources
This is the 5th article in a series about Creating Incident Management System (IMS) Software. Once you've started logging activities, created incidents, and have your contacts in order the next logical thing to build into your IMS software is the ability manage your resources - the Personnel, Equipment, Supplies, and Teams (I call this the PEST mode - I tried STEP but the order felt funny and over the years PEST stuck) that your organization uses to respond to the various events that you...

Creating Incident Management System Software Part 7 Incident Mapping 2
In a previous article about Incident Mapping I covered off the main GIS integration bits - it's about the map (not the GIS), it needs to be dead simple, the map is there for context (initially), layers (avoid!), and search. WHAT ABOUT MY INCIDENTS AND OTHER DATA IN THE SYSTEM? You'll note that I haven't covered off the Incident Management System (IMS) specific capability yet. My rationale is that if you don't get the basic map capabilities right it really doesn't matter because your users...

Incident Management System Software Part 2 The Incident
In Part 1 of this series about Incident Management System Software, the concept of Levels-of-Depth was introduced. The idea is that when you don't need to go deep, the software should be easy to approach and not force complexity on you. If you need more detail then you can dive deeper into the software you can - and you'll expose new levels of depth and be able to do more. In this article we'll focus on the key set of information that you will need for every incident. This information...

Creating Incident Management System Software Part 6 Incident Mapping aka GIS Location Data
Creating Incident Management System Software - Part 6 - Incident Mapping (aka GIS & Location Data) If you are a GIS expert this article is going to be hard to read. I'm a big believer that GIS is incredibly powerful for incident management but I believe that it is powerful when the GIS is in the background - users just use the system and it works. The fact that there is a deep GIS in the background is irrelevant to users of a world-class system. Keep that in mind as you read through...

Incident Management System Software Part 1 Levels of Depth
One of the best tools that an organization can have in house is an Incident Management System (IMS) solution to help keep track of the various things that happen on a day-to-day and crisis basis. Any organization that has adopted the Incident Command System (ICS) methodology or the Canadian variant -- rather problematically, for this article series, called the Incident Management System -- will benefit from using an IMS to gather and manage their information. A well-handled IMS can help raise...

Creating Incident Management System Software Part 4 Contacts
This is the 4th article in a series about Creating Incident Management System (IMS) Software. You've seen the contact binders and you have used them. You've seen the problems - people change and even if the same person is there, their contact details have changed. Face it - the minute that you print out your Contact List it is already stale - it probably had 5-10% stale contacts before you hit print. During a crisis this incorrect information causes a massive amount of lost time. Fixing it...

Identity and Access Management Laying a Foundation For Your Organization
Many companies and organizations are asking what the best identity and access management (IAM) technology is for a particular need. The needs may be very specific (e.g. on boarding of staff), very new (integration of social media accounts for customers), to very broad (full identity, credential, and access management). The biggest thing that scares people about identity and access management is the breadth of options - the domain itself is huge. Any reasonable-sized organization has likely...

7 Steps to Success To Create World Class GIS Based Situational Awareness Tools
When an organization is looking to create a set of map-based (aka GIS-based) tools to improve situational awareness there are a set of steps that will vastly improve the chances that the project succeeds. Whether the tool is intended to be a Common Operating Picture (COP) or an operations toolset you will need to be careful about how you approach the project. Too many GIS-based projects start with the best of intentions but end up as failures. The following steps will improve the outcome of...

Publishers / Webmasters
Article ID: 476413
DELINK URL from Authors Bio
REMOVE Article
Tell A Friend
Leave A Comment!
Download this article in PDF
Report Article!
Search through all the articles:


273 Users Online!!
Related Articles:
Latest Articles:
 
computers and internet >> Top 50 Articles on computers and internet
Category - >
Advertising Advice Affiliate Programs Automobiles
Be Your Own Mentor Careers Communication Consumers
CopyWriting Crime Domain Names DoT com Entrepreneur Corner
Ebooks Ecommerce Education Email
Entertainment Environment Family Finance And Business
Food & Drink Gardening Health & Fitness Hobbies
Home Business Home Improvement Humour House Holds
Internet And Computers Kiddos and Teens Legal Matters Mail Order
Management Marketing Marriage MetaPhysical
Motivational MultiMedia Multi Level Marketing NewsLetters
Pets Psychology Religion Parenting
Politics Sales Science Search Engine Optimization
Site Promotion Sports Technology Travel
Web Development Web Hosting WeightLoss Women's Corner
Writing Miscellaneous Articles Real Estate Arts And Crafts
Aging


Disclaimer: The information presented and opinions expressed in the articles are those of the authors
and do not necessarily represent the views of bharatbhasha.com and/or its owners.


Copyright AwareINDIA. All rights reserved || Privacy Policy || Terms Of Use || Author Guidelines || Free Articles
FAQs Link To Us || Submit An Article || Free Downloads|| Contact Us || Site Map  || Advertise with Us ||
Click here for Special webhosting packages for visitors of this website only!
Vastu Shastra

Cheap Wordpress Hosting Provided By AwareIndia







Company IDS