The Prince Rupert Pipeline project was looking for a way to streamline field data collection for construction related activities. The companies existing SAP system was comprehensive but was not a good fit for reporting incidents from the field as data collection was required from not only Transcanada employees, but also contractors and subcontractors working on the project.
The traditional paper based system, while it has been the golden standard for many years, resulted in a significant amount of rework and also had no analytical capabilities unless they were manually entered into the corporate SAP system. The manual re-entry of incidents made on time reporting a challenge, especially during peak construction periods. This became a problem because of the significant amount of data entry required and potential for day to day activities to interfere with the reporting process.
As we went through this process we had a number of challenges. The first challenge was to make the system usable in the field. Many of the inspectors in the field were near the end of their careers, were used to the paper based format and were reluctant to change their ways. The system needed to add value to them or adoption rates would be minimal.
Secondly, in order to get good information in & out of the system we needed to allow for structured and non-structured data entry. This meant that we needed to utilize advanced capabilities such as GPS, temperature sensors, date\time, project marker locations to automatically populate information without entry from the user. As multiple companies would be using the system it was important that a high level of security was in place to ensure any entries would remain private.
Finally, The system needed to be able to cross departmental boundaries. If a safety incident resulted in an injury, an environmental issue, or quality issue itneeded to engage the appropriate teams to ensure a timely response.
When we got into the development we developed using the latest web technology. As we rolled the system out, we found that many of the contractors were using older systems with older web browsers and it didn't work as expected. This resulted in us developing controls to detect the different platforms being used and render the application accordingly. For situations where support was not possible, providing the employee with a notification of which browsers were supported.
Our first version of the app was focused on use of the app from field laptops and tablets. What we found is that many of the employees attempted to use the app from their mobile phones. This required the use of responsive web design. We incorporated bootstrap into our rendering engine to allow rendering on the device.
As many of the employees in the field were not necessarily friendly to technology, nailing the user experience was important. We did this by translating the experience they had with completing paper based forms onto our software. This resulted in minimal employee retraining. We added value by automatically populating information that we already knew. This reduced the amount of data that needed to be entered and was a key point in gaining adoption in the field. The final component of adoption was giving the contractors the ability to export their data. This allowed them to take that data and use it within their own systems.
The project used markers throughout the project to determine the incident location. We built a location engine that allowed us to cross reference the incident report with the closest project marker for reporting. We envisioned that we would be able to send the location information and the marker in our email notifications but the limitations within email prevented us from doing that. To get around this, we took the data and converted it to an image which was then sent via email.
As the project needed to collect different metrics over the course of the project it was important to be able to dynamically change the data collection process while protecting the historical information that was collected. We developed a comprehensive data model and rendering system (basically our own rendering language) to allow for rapid changes to be made without IT involvement. The rendering engine provided standard rules that also enabled them to action information for notifications.
Notifications proved to be very difficult to accomplish. There were conditions upon conditions that needed to be accomplished in different ways to different teams. This required us to develop a comprehensive actionable system that performed actions in real time and after submission.
The project resulted in a positive advancement in how near hit safe act incident reports were collected and reported. The success of this project led to adoption on other projects and by operational crews. - Elyse Trembley