Building a Successful Evergreening Workflow for your Organization: Three Key Considerations White Paper A common concept emerging in fields that depend on access to large quantities of critical data is evergreening, the process of ensuring that the data is complete, accurate, and up-to-date. In the field of pressure relief analysis, implementing an evergreen process for the pressure relief analysis data is critical to ensure continued safe operation of the facility. Building and implementing an evergreening process has many challenges facing it, both institutional and technological. This paper identifies and discusses three key factors to consider when building an evergreening workflow. Siemens AG 2018, All rights reserved 1
Building a Successful Evergreening Workflow for Your Organization: Three Key Considerations Introduction Numerous papers have been published on the topic of evergreening of process safety information (PSI), the process of ensuring data is complete, accurate, and up-to-date, and of its role in ensuring an organization can meet the requirements of OSHA s 29 CFR 1910.119 PSM Standard. i ii iii iv Many of these previous papers have focused on the need for evergreening and different aspects of evergreen PSI systems. However, given the complexity and importance of evergreening, and the responsibilities it places on the organization, it is not something that can simply be tacked on as an afterthought. To be successful, an evergreening program should be tailored to the organization s structure and culture. This paper identifies three key factors to consider when building an evergreening workflow. While not a guarantee of success, giving these factors their due consideration can mitigate the likelihood of a failed implementation: Documenting the evergreening process and defining the communication plan for the process Defining the user roles and establishing ownership of the process Planning for and managing multiple sets of data While these principles are applicable to all elements of PSI, for the purposes of this paper they are applied to the field of Pressure Relief Analysis. Communication and Process Documentation Creating and implementing a robust communication plan is vital to the success of any effort. A breakdown in communications can doom the process to failure even after years of seemingly successful operation. Communication includes not only the interpersonal communication between team members (e.g., day-to-day communication such as progress tracking and data requests) but also the intraorganizational communication required to bring all users on board with the process (e.g. training materials), and to continue to provide updates and feedback. Defining the communication mechanisms, roles, and frequencies is critical to the process. Mechanisms could include e-mail, intranet sites such as MS SharePoint or forums, issue-tracking systems, or other proprietary systems. More often, a combination of several of these will be employed. The requirements for communication between persons involved in the effort should consider the requirements of the program and of the team members involved. In addition, communication frequency and expectations for response time should be established. Another key component of intra-organizational communication is the documentation of the process. When the documentation of the process is poor or incomplete, the users may fill in the gaps with their own ad hoc solutions or interpretations, which may introduce inefficiencies or loss of integrity of the process. In addition, this can lead to inconsistency and reduced longevity as the knowledge of the solutions is subject to the coming and going of the personnel involved. Providing thorough documentation of the process in the form of workflows and procedures yields the following benefits. First, publishing documentation of the process aids in standardization, especially when the process is adopted at multiple sites in the organization. Secondly, it facilitates in the training of new users to learn and adopt the processes quickly ( on-boarding ); this benefit is realized not only in the initial rollout of the process but also for the inevitable staff turnover. Lastly, once the documented process has been completed and the distribution mechanisms put into place (e.g. company intranet page, a MS SharePoint site, e-mail listing), the further distribution and communication of changes is greatly facilitated. One step that should not be overlooked in developing a process is to define the system use cases. A use case is a list of steps defining how the system is going to be used by a particular type or category of user. Some examples include how a user might access and retrieve information required for various engineering processes and activities, such as PHA support, or documenting a MOC, or how the user might go about preparing a new study on existing information. As the evergreening process is developed, returning to and reviewing Siemens AG 2018, All rights reserved 2
these system use cases can help ensure that the process properly addresses the different possible actions and outcomes from using the system. Ownership and Accountability Another critical step in implementing a successful evergreening program is identifying the process owner and establishing and enforcing accountability. It is widely accepted that when everyone is responsible, no one is responsible. Having a recognized process owner provides the organization with an identifiable authority and point of contact; this person may also serve as a champion of the process implementation effort. This person may or may not be also the person tasked with managing the pressure relief analysis processes and tools. It is also necessary to identify the users of the PRA data management system. If a stakeholder analysis has been performed, this step will likely already have been completed. The users may fall under many different categories, so it is important to understand how each category of users will interact with the PRA data management system. For example, the unit process engineer may be principally concerned with a single process unit, and be charged with the task of maintaining the PRA information for this unit. A project engineer, on the other hand, may only be concerned with the PRA data for a particular unit for the duration of a given project. How each of these users interact with the PRA data management system, and what particular responsibilities they are tasked with, should be understood, defined, and documented. A common tool in defining team members roles and level of responsibility is the RACI matrix (Responsible, Accountable, Consulted, Informed). Team members who are responsible are the ones who perform the task, while the member who is accountable is the one who is held answerable for the task; there may be many responsible members but only one accountable member. Adopting this tool can clearly establish the expectations from each of the users. The use of the software tools typically involved in performing pressure relief analysis (e.g. PRA calculation tools, process simulation tools, etc.) results in the production of large quantities of process safety documentation. This can be electronic, hardcopy, or a combination of the two. The process of generating this information can often include input from multiple people at different steps in the process. The need for approval at various steps should be evaluated, and where required, the approval gates should be documented in the process. Additionally, the communication plan should establish the expectations for response time. It is important to recognize the trade-off between efficiency and security that accompanies the approval gates in the process. Having too many approval steps in the execution process may significantly hinder the efficiency, while having too few may result in either unidentified errors passing through and/or require larger amounts of rework. Managing Multiple Data Sets A critical consideration when managing pressure relief information is anticipating and handling multiple data sets for the same equipment, area, or process unit. Often, this takes the form of archived data for past projects and old studies, a set of current data representing the current installed state in the field, and any number of prospective data sets, representing projects, expansions, what-if scenarios, etc. Typically these prospective data sets are created from a snapshot of the current data set, or branched. Furthermore, the possibility of the prospective data becoming the master record at some point in the future should be considered. Recognizing, anticipating, and planning for branching data can help prepare the organization for some of the challenges associated with these changes, especially as projects reach their conclusions and data records reach the end of their useful lives. It is important to understand the nature of the type of work that will be performed and the effort involved in different types of activities. For example, projects adding new systems to the process unit will typically involve creation of new PSI for new equipment, relief devices, and overpressure scenarios. On the other hand, projects like debottlenecking may only require revisions to the existing PSI after updating calculations on existing equipment, screening for potential concerns, and designing mitigations to address those concerns. Understanding what elements will be affected by different activities can help plan a path forward that minimizes the amount of data reconciliation required at the end of the project. Part of the management of these multiple sets of data is to recognize the need for communication between the disparate teams performing tasks, and create and reinforce the channels through which communication occurs. For example, in the event that the current data set is used to create a branched-off data set for use in a project, it is likely that separate individuals will be involved with the two sets: one team maintaining the current as-built set, and a project team performing an analysis on the prospective case. As these activities progress, the day-to-day maintenance on the as-built set may not be known to the project team. In such a case, it is important to provide a communication mechanism so that the project team is aware of the changes and can take these into account in the performance of their analysis. Communication between these groups should consider the direction of transmission required (may be one-way, two-way, or communication between more than two groups, depending on the activities being performed), an established expectation of communication frequency (e.g., daily, weekly, as-needed), and the expected time period for resolution, such that clear expectations are established to ensure a backlog does not Siemens AG 2018, All rights reserved 3
build to the point where it is unmanageable. For example, a one-way communication that is only required on a weekly basis may be as simple as a weekly e-mail, while a multidirectional communication that needs to be constantly updated may better benefit from an intranet SharePoint site or forum with subscription capabilities. Lastly, among the most important of considerations is the creation of a plan for the end of data. This includes planning for data reconciliation (e.g., at project conclusion) as well as the archiving and locking out of data that is no longer in use or obsolete. These plans should include a consideration of how to select which data set will become the next master record; depending on the scope of each project or maintenance effort, typically the reconciliation path that involves the least amount of data reconciliation is the optimum choice. Learning to identify this and providing a plan to address it can significantly reduce the headaches associated with managing branched data. Conclusion There are many factors critical to the successful implementation of a new evergreening program. Three of these are: Documenting the evergreening process Defining the communication plan for the process Defining the user roles and establishing ownership of the process, and planning for and managing multiple sets of data. While the three presented here are not a complete checklist, ensuring that these three areas are properly addressed can significantly improve the chances of success. While the focus of this paper is in relation to pressure relief analysis, these principles can be applied to many other areas as well. Siemens AG 2018, All rights reserved 4
Marshall, M., Nguyen, D., and Talreja, N. Excellence in Pressure Relief Systems Management through Evergreening Program. Proceedings from 14 th Annual Symposium Mary Kay O Connor Process Safety Center. College Station, TX. October 25-27 2011. Pp. 530-540. ii Sammons, S. and Higgens, S. Evergreening Your PHA. Proceedings from 6 th Global Congress on Process Safety. San Antonio, TX. March 22-24, 2010. iii Laskar, S. Importance of Process Safety Information (PSI) and Implementation of Design Best Practices for Upstream Safety Management Program. Proceedings from International Conference on Health, Safety and Environment in Oil and Gas Exploration and Production. Perth, Australia. September 11-13, 2012 iv Occupational Safety & Health Administration [OSHA]. (September 1, 2014). Process safety management of highly hazardous chemicals. 1910.119. Retrieved from https://www.osha.gov/pls/oshaweb/owadisp.show_document %3Fp_table%3DSTANDARDS%26p_id%3D9760 Siemens Energy, Inc. Process Safety Consulting 4615 Southwest Freeway, Suite 900 Houston, TX 77027 USA www.siemens.com/energy/oilandgasconsulting All rights reserved. All trademarks used are owned by Siemens or their respective owners. Siemens AG 2018 The information contained in this paper represents the current view of the authors at the time of publication. Process safety management is complex and this document cannot embody all possible scenarios or solutions related to compliance. This document contains examples for illustration and is for informational purposes only. Siemens makes no warranties, express or implied, in this paper. Siemens AG 2018, All rights reserved 5