Mike Bearrow PE, VisiumKMS & Justin Trice, INEOS Styrolution
Incident Management System for a Global Company
Keywords: Incident Investigation, Root Causes, Basic Causes, Global Incident Management Procedure, Lessons Learned, Incident Management Software, Action Tracking
Abstract
The global implementation of an incident management and action tracking system is no easy task. Although everyone is trying to do the right thing from initial rollout, there are lessons learned along the way that will, in the end, solidify your already existing incident management system. A mid-size, yet global company of about 3,500 employees learned and applied these lessons during a three-phase incident management system rollout to three different geographical areas: the Americas, Asia and Europe. The challenges faced were not only geographical and cultural; they were also a result of the different legacy safety philosophies that come with joint ventures and new partnerships in the ever changing chemical industry.
What was the initial approach? Going back to basics: defining what an incident is, what types of incidents would be tracked, and what the requirements for an investigation were going to be. This paired with the lessons that were learned after each phased rollout resulted in the successful implementation of a global incident management procedure and software system; the lessons being continuously learned would make for an even more successful rollout in the future.
1 Background
INEOS Styrolution is part of the INEOS Group Limited (styled as INEOS) and is a privately owned multinational chemicals company headquartered in Rolle, Switzerland. It is in the top ten chemicals manufacturing companies as measured by sales revenue. Jim Ratcliffe is the founder, chairman, and sixty percent shareholder.
INEOS is an acronym of INspec Ethylene Oxide Specialties, a name derived from their first acquisition in 1998. It also stems from one Latin and two Greek words that founder Jim Ratcliffe and his two sons found when searching for a company name. “Ineo” is Latin for a new beginning, “Eos” is the Greek goddess of dawn and “neos” means something new and innovative. As a result, the name Ineos represents the “dawn of something new and innovative. Ineos is organised into around 20 standalone business units, each with its own board. One of those businesses is INEOS Styrolution.
INEOS Styrolution is the leading, global styrenics supplier with a focus on styrene monomer, polystyrene, ABS Standard and styrenic specialties. With world-class production facilities and more than 85 years of experience, INEOS Styrolution has over 3,500 employees worldwide and 15 manufacturing sites in 9 countries. In 2015 they had sales of 5 billion EUR. INEOS Styrolution is famous and proud for making the material that is used to make a well-known children’s building block product.
2 What’s a Global Incident Management System and why did we need one?
A global incident management system is actually a learning management system that helps ensure that “learning opportunities” are captured, communicated, analyzed and acted upon.Within INEOS Styrolution, that means that near miss, hazard recognition, Process Safety Management (PSM) events, environmental events, slips trips and falls, quality, security and reliability events are all captured for analysis, learning and action. Capture, analysis and learning without action of course is futile.
As a company we needed to ensure that our sites had an effective way to document Environmental, Health, and Safety (EHS) and PSM events and that they had a way to track corrective actions, preventive actions and continuous improvement ideas to closure. We also wanted to be able to report PSM progress and continuous improvement without bothering the sites for information and updates. We wanted to be able to create reports, but we did not want a reporting tool. Some companies collect EHS data or other information at the end of the month using excel spreadsheets or electronic entry screens so they can inform “senior management”. That kind of reporting does not drive improvement. An incident management system that is valuable at a site level will, as a by-product, have a meaningful reporting methodology.
After all, the purpose of incident management is never reporting. It’s not a reporting tool! It’s a learning and getting better tool. We decided we did not want a “reporting” or “compliance management system”. We wanted a continuous improvement tool that could be used at all sites and leveraged for all of our learnings and regulatory requirements. Shooting for compliance, and not excellence, is a mistake. Incident Management is the basis for continuous improvement. Like audits and risk assessments it drives the company forward with CAPA (Corrective And Preventive Action) and CI (Continuous Improvement).
3 What did we want in an Incident Management System?
We wanted an incident management system that could record any type of incident in a single repository. We wanted to collect all incident data/information in a consistent, structured format, using a common language. We wanted a system that could manage the investigation process from start to end, have automatic notification based on location incident types and severity. We wanted the system to enable and force action or recommendation tracking to completion. We wanted to be able to collect and share lessons learned, to stimulate continuous improvement goals. Finally we wanted to have a view of trends, areas of persistent weakness or common issues that could be identified and addressed at a local and/or enterprise level.
4 Why should software be a part of our Incident Management strategy?
When we say “Incident Management System” we mean an automated process that consists of process and software. First we defined the process we wanted to enforce followed by the selection of software that will enable its use and help ensure its success. The database application was necessary to achieve “One Source of the Truth” and Data Collection at the source of the risk. One source of the truth means that there is a single repository of all our incidents and learnings. Data collection at the source means ensuring that the men and women identifying incidents have direct access to the system in the plant, site, factory or platform. This is where the risk is and where continuous improvement gets done. This is where they need Decision Support, FROI (First Report of Injury), PSSR (Pre-Startup Safety Review), MOC (Management of Change) and idea collection.
Collecting, Analyzing (Measuring) & Sharing Lessons on a global basis is nearly impossible without the use of the internet and an application. We also needed automatic alerts when Incidents & Near Misses occur. Spreading the word quickly to those who can understand and create a plan of action is best done by a symphony of software: application, database, notification service, and an email system like MS Outlook or Lotus Notes. Our software needed to have a Corrective & Preventive Action (CAPA) tracking capability to ensure that identified issues are dealt with in a timely manner, making sure what needs to be done gets done. We included a management of change (MOC) requirement into our software needs in the event that our actions require it. Once you have the solution, make sure the proposed change is appropriately identified, evaluated, approved and executed.
5 How did we choose an Incident Management software solution?
There are thousands of software packages or solutions available in the market place. They come from all market sectors including banking, pharmaceuticals, chemical processing, and oil and gas. Each solution is usually steeped or focused on EHS compliance, Sustainability, Environmental, Health, Safety, or Process Safety Management/Risk Management Program (RMP). We found that no one solution can be as robust as it needs to be to address all EHS requirements, but we needed one that was known for its depth; not coverage. The PSM business processes most important for us were incident management, action/recommendation tracking, audit management, risk assessment and management of change. Indeed there are very few that are PSM focused for the chemical process industry and are made by a company that is mature and reliable. We chose VisiumKMS.
6 What we believe about process safety management…
INEOS Styrolution built our incident management solution based on some PSM tenets. They affected how we implemented this solution. We believe well run, efficient operations are much more likely to have optimal safety and health performance. Incident Management systems must enable optimal operation and then exemplary PSM/RMP performance will result. Incident Management systems must be configured and implemented principally for operations or production; no one else. It’s not principally for reporting or “compliance”. Operators, mechanics and engineers live and work where the hazards are and should always be the focus. Said another way, PSM compliance and reporting of Key Performance Indicators (KPIs) should be a by-product of PSM information systems (incident management systems) that are useful to the businesses. Finally, we believe PSM excellence is created one site at a time and is never a product of top down management. Management can help enable performance and can provide the best tools in the market place, but each site must embrace the importance, the process and the tools.
7 What’s the trick to success?
In the end, the trick to success of any enterprise system is to make it useful and valuable at the site level. PERIOD. If it is useful at the site and it enables local performance it has a good chance of working at an enterprise level. Of course incident management systems are intended to enforce global standards: risk ranking, incident types, severity, root causes methodology and operating phases. Standardization enables global insight and continuous improvement. Those are all important aspects of the system. However, we knew that incident data capture like smart checklists, security, communication and process needed to enable business units and sites enough flexibility to ensure wide-scale corporate adoption. The ability to accomplish some local tailoring helps to reduce the user’s perception of an “inflexible corporate system”. And the more user adoption the more we can maximize the value of lessons learned. Wide adoption then allows PSM Specialists at the business unit level and above to glean learnings from the vast amounts of data and then share corrective actions across affected areas of the business. The diagram below illustrates how local and global value is derived from an incident management system.
8 The Overall Challenge
It is challenging to bring large and culturally different groups together and agree on almost anything. It is certainly a challenge for a global implementation of an incident management and action tracking system. There is an initial planning step in which it is decided if the system will be rolled out at once (big bang) or in phases, followed by process mapping, implementation, training and final roll-out. This particular implementation was rolled out in three different phases divided into the three main geographical areas involved: the Americas, Asia, and Europe. These three regions were not only geographically, but also culturally, different including differences in language, company-culture and regulations. These differences are a result of a growing and changing global chemical company. We will explore the overall challenges and lessons learned during each implementation phase.
How many sites, Number of employees, Locations, Languages
Regulations and Legislation that are in play
When we started out we were reminded of all the different regulations that INEOS had to comply with around the world. The INEOS Styrolution facilities are covered by a plethora of standards and compliance requirements including, OSHA 1910.119 – Process Safety Management (PSM), OHSAS 18000 – International Safety Management, EPA RMP – Risk Management Program (RMP), ISO 9000 – Quality Management Systems including, ISO 14000 – Environmental Management, RESPONSIBLE CARE®, API-691 – Risk Based Machinery Management, RAGAGEP – Recognized and Generally Accepted Good Engineering Practice and Seveso.
Legacy Management Systems
INEOS Styrolution had recently acquired facilities from BASF in all 3 operating regions which had different management systems. Some systems used dedicated software, while others had spreadsheets. Each facility had different management systems for complying with local legislative and regulatory requirements. We had Excel spreadsheets, Access databases, and other data capture methods.
9 Initial Design and Challenges
As mentioned, the goal was to roll out a global incident management and action tracking system in three different regions of the world. Initial challenges were faced soon after selection of the software solution. If this was to be a global implementation there had to be consistent incident data capture (pick lists, checklists, and nomenclature) with the definitions of each type well-understood by all regions. This posed some basic questions that needed to be answered in order to establish minimum criteria:
First we had to agree on a top level workflow as presented below.
Then we defined incident? That was more difficult than I thought. We defined a PSM event as an event that results in, or reasonably could have resulted in, a catastrophic release of highly hazardous chemicals in the workplace. Investigations must be initiated no later than 48 hours after the incident occurs.
We had to answer a few more questions like “what are the automation requirements?” What results must be documented and communicated? How must incident recommendations be managed to closure? How will changes that result from recommendations be managed using the MOC element? What data elements should go into the electronic system?
Then we looked at what reports, metrics, KPIs do we need (Begin with End in Mind)? We decided we needed to know if Incident investigations completed on time and if Action items from investigations completed on time. Other reports used for trending and data analysis included Incident types, severity, risk ranking and root cause categories.
Success was accomplished by designating a process owner that would coordinate and support sites within all regions and become an expert in the designated automated system. The designated process owner was the PSM Specialist at one site. They reported directly to the global EHS manager. The Global EHS manager was also heavily involved in the entire process, from system selection to implementation and rollout. This helped the company convey project objectives and the end goal of standardizing incident management and action tracking throughout the organization. It also ensured participation, coordination, and buy-in of all sites into the design.
10 Preparation and Initial Rollout
We needed to ensure that there was consistent categorization of all the events that would go in to KMS. As such we decided to have standard incident types across the organization which included various types of safety, environmental, transportation, incidents that matched the existing corporate incident reporting structure. We also defined the criteria for incident inclusion including near misses.
Standardizing on a single root cause method across the company was desired as there were a number of different root cause approaches across the organization. Having standard root cause nomenclature would allow for larger scale data trending of the root causes across the organization. At the initial rollout we also decided to not standardize on a single root cause or incident investigation methodology and allow existing sites to still utilize whichever methodology they were previously using. A list of the various methodologies in the organization was entered into the investigator module of the software.
Although the software allows for recording up to 3 levels of a root cause map structure, we have found that the trending in the early stages of implementation works best at the highest level. As with any new system, there is a learning curve for utilizing it. In this case, users were more consistent in identifying the highest level of the root cause map structure. Keeping the root cause map structure simple also improves the utilization and is essential for smaller organizations that are not able to devote many resources into trend analysis. The effectiveness of a implementing a root cause mapping structure is also highly dependent upon auditing the results and continuous training of the users to build more consistency.
Another key feature of a good incident management system is having tools to assist with the initial incident entry. Capturing and communicating those details from technicians and frontline leadership is paramount for ensuring that an investigation will be successful. An incident checklist tool was developed and entered into the software system for this purpose. We used different checklists for injury and environmental release incidents to help guide the employees who were enter the incidents into the software system toward some key information. For injuries this included details such as: hours worked prior to the incident and what PPE was in place. For spills / releases, this included details such as: size of spill, spill quantity / rate, duration, precise location, etc.
A key feature that our company stressed was having a good system for capturing the corrective actions and lessons learned from incidents. For the corrective actions, a robust system for tracking the progress of these actions was extremely important as well as the ability to provide metrics on performance (i.e. items that are past due). Software systems can only do so much, a good incident management system should ensure that the results of the investigations are communicated throughout the organization.
Throughout the initial system configuration for the North America rollout, the regional sites were engaged in the process, mostly through web conferencing and email communication. We wanted to get as much buy-in from the sites as possible. A primary contact person was identified at each North American site to be responsible for soliciting feedback from the site during the process and to also eventually be the site administrator for the incident management system after the Go Live date.
As previously stated, a single employee was identified as the process owner for the incident management system. Throughout the configuration, this employee was responsible for gathering the necessary data from the sites, such as the location structure to use in the incident management system, and to test the system configuration. Maintaining a single point of contact ensured that all testing and evaluation would be consistent. A final approval of the configuration was made prior to rolling out the training.
The final step before going live with the system was to train all of the North American regional sites. Training was conducted at each site by a representative of the incident management system software company and the INEOS Styrolution process owner for the system. Having this dual team for the rollout helped ensure that the training would be utilize company terminology and it allowed for better feedback on questions about the incident management system and how it would integrate into day-to-day operations. The training was completed over the course of about 6 weeks to accommodate site schedules.
The incident management system utilizes two separate environments: The Production environment, or live system, and a Staging environment. This Staging environment is initially an exact duplicate of the Production environment which allows training to be conducted in a clean environment. The training classes were normally kept to 20 or fewer employees and the employees were all strongly encouraged to bring a laptop to the training. Having computer access during training was very important as it allowed the trainees to participate in a hand-on approach. The trainees all logged into the incident management system and as the trainers went through the steps for entering an incident, the trainees would enter their own incidents into the system. The trainees were encouraged to enter real incidents into the system so they could better see how the system would be utilized.
For the rollout, we decided to have each site go live in the system immediately after conducting the training at the site. This minimized the gap between training and using the system. During the training sessions, an occasional issue or improvement opportunity was identified; this is the other advantage of having hands-on training, the large diverse groups interfacing with the system served as an additional “beta” test of the configuration. As issues and opportunities were identified, we were able to make changes in the incident management system prior or within a day or two of the Go Live date that may normally not have been identified until weeks, or months, later.
The initial rollout of an incident management system does not end with the system going live. Especially in the early months it is very important to frequently audit the system and to solicit feedback from the new users. For our rollout, the process owner performed the review and also maintained frequent contact with the individual site contacts. Additionally, a conference call meeting was held a few months after the rollout with all of the site contacts to discuss feedback from the sites regarding the system.
This feedback process had a couple of benefits. First, site-specific concerns were addressed accordingly, creating a sense of ownership and understanding from all users. This helped pinpoint the differences in existing incident management processes at different sites and strengthen and revamp the global process. Secondly, coordination between sites – getting participation in the “final design” was essential in the long-term acceptance of the system. The staged rollout made this more difficult, especially for the European sites, but feedback was still solicited and changes made where they helped improve the system or facilitate better standardization.
Lessons Learned
As with any project, there are always lessons learned throughout the project on what you would do differently the next time.
One of the main learnings was that we would have benefited from having more companyspecific work instructions for using the system at the initial rollout. The initial training materials encompassed the entire system, making it more challenging for individuals to refer back to them when they needed to utilize the system, and since this is an incident management system, the interaction with the system for individual employees can be highly intermittent. By the end of the rollout, the process owner developed sets of instructions for each of the major steps in the incident management system workflow, including an overall workflow / process document to serve as a guide. These instructions were immediately provided to the sites. Some sites kept the instructions as-is, while others eventually integrated the instructions into their own incident investigation procedures. Had these instructions been developed earlier in the process, they could have been better integrated into existing systems earlier in the process.
Going into the implementation, the decision had been made to standardize on a single root cause map, but not a single methodology. This was to minimize the impact to the sites’ existing processes, but what we found during the rollout was that the sites did not have strong ties to their existing systems. In hindsight, we would have potentially benefited from more standardization of the investigation and root cause methodologies and utilized the rollout of the incident management system to make a clean change; however the compressed time frame that we had for implementing a new incident management system would have made that extremely challenging.
11 Expanding to a Global System
The North American region rollout was forced into a compressed time frame due to the impending loss of the existing system. The other two regions, Europe and Asia, did not have that challenge. Most of the European sites were already on a common incident management system program from their previous company, and most of the Asian sites did not have an electronic incident management system.
Asia was chosen as the next region for rolling out the incident management system. Since a previous system was not in place, they were very receptive to having a new system. The primary challenge for Asia was the wide variety of languages. INEOS Styrolution has manufacturing facilities in India, Thailand, and South Korea. INEOS Styrolution already had an internal incident reporting process that required alerts with incident details to be distributed in English, so it was determined that if the incident management system could not accommodate the Asian languages due to the types of characters used by the languages, English would be the preferred language.
The Asia pre-rollout work was relatively easy since the primary configuration had been completed with the original North America rollout. The main focus was to get the Asia sites individual data into the system, identify the primary points of contact for each site, and then to coordinate train-the-trainer sessions. The employee who served as process owner for the North American implementation also participated in the initial configuration and some web conferences to help plan the implementation. All of the training materials and work instructions that had been developed during and since the initial North America rollout were also provided well ahead of the implementation to allow for better planning and a more effective rollout of the incident management system.
The preparation for Europe presented a new set of challenges. Germany and the EU have privacy laws that can greatly impact handling of data, especially if the hosted server is located outside of the EU. Third party certification is required, and a few tweaks were made to the incident management system to better control the use of any personal information, especially when it comes to incidents that resulted in an injury.
Because of the previous incident management system rollouts in North America and Asia, the system was very robust when it came time for the Europe rollout, but make no mistake about it, implementing a global incident management system requires some sales, flexibility and finesse. Selling the local value and the need for a common approach is not always well received.
Since the initial selection of the incident management system, which occurred over 3 years prior, did not include the European sites, there was some resistance due to the feeling of a system from another country / region being forced upon them. Most sites were very comfortable with the existing system they used from the previous company, especially since most of the sites are embedded in larger facilities still owned by the previous company; however, those legacy systems were not going to be supported long term, so a change was going to be necessary. The ability to have the new system customized for the individual country languages (German, French and Dutch) helped to bridge the gap with the initial resistance. The staged rollout also assisted by being able to show data from the other regions and have employees relate their experiences using the incident management system.
The rollout to the Asia and European regions were conducted a little differently with more of a focus on a “train-the-trainer” approach. Training was conducted by the software vendor at a centralized location for each region and super-users were trained who then went on to train personnel at their individual facilities. This approach ensures that sites have identified the proper people and gives them the opportunity to practice and understand the electronic system and incident management process before the process is deployed in the facility.
Lessons Learned
Common Language and definitions were crystalized. The biggest initial learning curve was the discovery was that there were different definitions and expectations at the different sites around incident management. In order for our automated system to be successful and enable lesson sharing across a global organization, there have to be company-specific instructions and definitions around not only incident management but also what needs to go into an automated system and in which formats. This gives EHS leaders an opportunity to consolidate best practices across the organization as well and encourage sharing and evaluation of said best practices.
Prior to the Asia and Europe rollouts, the root cause map from the initial system was replaced. This was the first step in the process of even greater standardization in the incident investigation process across the global organization. The new root cause map has the advantage of being more structured with better documentation available, and it fits directly in with a full incident investigation / root cause analysis program that can be used both internally and by an external consultant if the need arises.
The Asia and Europe rollouts benefited from the lessons learned in the initial North American rollout, and the adoption in
12 Conclusions
There is no substitute for good judgment. No amount of automation will eliminate mistakes or poor decision making. There is also no substitute for management commitments and ensuring accountability. To really be successful you need managers that insist that there is only one tool they will go to for incident management reporting, metrics, statistics… No excuses when it comes to using the “system”.
What did we expect?
We expected it would be hard and it would take a while to be successful. But we have accomplished a full global implementation over a 4 year period throughout the entire INEOS Styrolution manufacturing organization. We expected that the sites would use incorporate the electronic incident management system into their existing incident investigation procedures. For the 16 manufacturing facilities, almost 4000 incidents, including Near Misses, have been entered, generating over 3000 action items that are being tracked in the system.
What Did We Learn
Selling the value at the site level and allowing some local tailoring is a big help. Ensuring that the system feels like it was designed for the sites and their purposes helps ensure better adoption and use. Making the system’s use mandatory and incorporating into the existing incident reporting structure is vital.
What would we do differently?
Develop more company-specific training and work instructions prior to the initial rollout. Establish a more consistent approach to investigation methodology and utilization of root cause mapping at an earlier stage. Conduct a consistent root cause analysis training with sites at, or before, the rollout of the existing system. The root cause map was a new feature for most sites and wasn’t rolled out until several months after the initial North America regional roll-out. There was not a specific training program on using the root cause map, so there were some inconsistencies in its utilization.
We would consider initially having a smaller group to conduct the final root cause analysis and entry of information into the electronic system to simplify the training and to build more of a subject matter expert group prior to opening the software up to a larger user group for entering incident investigations.
What we forgot to mention…
To be successful you must have a strong commitment to manage Process Safety from Sr. management. That commitment must be coupled with enough understanding of PSM and the related risks by those Sr. managers to ensure that they understand what that commitment will mean in terms of financial and manpower resources; and how decisions they make can impact process safety. Similarly for an incident management system, Sr. management must make the commitment and REQUIRE its use at all locations. A clear objective should be developed and then appropriate levels of management held accountable for its realization.
Want to learn more about VisiumKMS? Why not contact the author directly via email on mike.bearrow@visiumkms.com
