About the Author: Efrain Rios is the founder of Fortress Oil & Gas, LLC, an asset integrity consulting company specializing in records and data management. For the past 15 years he has focused on the development, standardization, and global implementation of asset integrity software applications. He has developed critical software functionality and led large scale database restoration projects to improve confidence in data quality, risk management, and compliance with industry codes and standards. He recently served as the Director of Asset Integrity for a Houston-based pipeline services company and continues to work with leading integrity software companies to improve their applications and better serve the industry
Collectively, the four previous parts of this article series have given readers an overview of (1) common issues faced when using an inspection data management system (IDMS) and their typical causes, (2) the process and key considerations for selecting an IDMS, (3) options when critical functionality is missing, and (4) how creating a data management standard helps mechanical integrity teams to more efficiently and effectively manage safety, compliance, and risk. In this fifth and final part of this series, readers will learn the key obstacles faced in an implementation project and what measures can be taken to help prevent and mitigate their impact.
For this discussion, the implementation will be limited to simply installing the IDMS, building the data set, and configuring it to function as needed. However, more complex implementation projects may include automated interfaces with external tools used for risk assessments, financial analyses, and work management, or connection to bolt-on tools such as data visualization and mobile data collection platforms.
For individuals, installing a software application is often a very straight forward process. One simply clicks through the necessary screens to install and it’s done. There are rarely any major issues. However, for companies it can sometimes be a bit more difficult. Compatibility between a combination of various software applications and hardware items is always a potential concern. Also, any changes to live environments could have a knock-on effect to other previously installed applications. Poor planning prior to creating both the testing and live environments can cause unnecessary costs and negatively impact the implementation schedule. As we saw in part 2 “Selecting the Right IDMS,” early identification and engagement of key stakeholders will help the project team to identify these risks and ensure that no unforeseen issues arise during this late stage.
BUILDING THE DATA SET
In this stage, the implementation team is populating the database with all the data necessary to manage the inspection program. However, this step is more complicated than it may initially seem. And there are several key challenges to overcome.
Not having all the necessary data to populate a database may initially seem like a minor issue. Many users assume they can load what they have and worry about collecting the rest later. This is not always an option, however, as certain data may be critical for the software to function properly. When certain specific information is missing, some applications have features which may be rendered useless. This is very common with calculations which require a minimum level of information to process the data and provide outputs. Default values, assumed values, and user-defined business rules can typically help fill these gaps. This allows companies to take advantage of new features while modifying their work processes to collect and utilize data that they did not previously capture and manage.
Data Entry and Mapping
The simple act of entering information into an IDMS can also be problematic at times. If the source data is not already in an electronic format, e.g. all historical records are stored in paper format, the time and cost associated with data entry activities can be quite high. It may be worthwhile for implementation teams to consider scanning these paper records and using one of the many tools capable of reading PDFs and placing that information in a more useable format such as MS Excel. These tools obviously introduce an entirely new set of concerns about data quality, as one might imagine, so thorough testing and careful planning will be required.
When information is already in an electronic format, data mapping becomes a much larger concern. The required information must be migrated to the new IDMS in a manner that (1) allows the software to fully utilize it, (2) allows users to build the necessary queries to meet corporate reporting requirements, and (3) is swift, efficient, and cost effective. The first two can be accomplished by creating a Data Management Standard outlining how the data will be entered and managed within the system. This will require a solid understanding of how the application functions to process the data as well as how users need the information structured so that information reported from the software is consistent and accurate. The efficiency and cost concerns can be mitigated by using ETL (extract, transform, load) tools which structure and automate the movement of data from the source to the IDMS.
It is quite common for users to consider software configuration after all the necessary data has been put into the database. However, this is far too late in most cases. Configuration should be considered early in the implementation process as it is essentially the set of instructions that users provide to the IDMS telling the software how to process the its data. Users must consider how they want the software to utilize the information while simultaneously planning how the information should be structured for entry or migration into the IDMS. This helps users prevent rework in the data mapping and migration stages. When implementing an IDMS, it is usually very helpful to think backwards. Begin by considering how the information will be used (KPIs, work processes, corporate reporting, etc.), then determine how the software should be set up, and lastly decide how the data should be entered into the system so the end goal is ultimately achieved.
While it is clear to see that there are still many technical obstacles even in this final implementation stage, it is not a technical obstacle that presents the biggest challenge. Perhaps the largest hurdle to overcome is related to human behaviors. Technical challenges are always difficult, but with enough planning and communication can be avoided or more easily overcome. Changing the culture and habits of team members, however, usually requires the greatest level of effort. As readers saw throughout the previous 4 parts of this series, following a proven process that includes obtaining early stakeholder buy-in, selecting the right tool, ensuring functionality alignment with company processes, documenting standardized data management requirements, and creating a robust role-based training program will go a long way toward proving the value of the new system. This, in turn, will minimize any internal resistance and ensure a successful implementation.