Think Big, Start Small, Scale Fast – Digital Transformation

Why is it that in some plants digital transformation stalls even though it is very well funded, while in other plants success is quick and they soon expand beyond the initial proof-of-concept (PoC) even with limited investment? A recent World Economic Forum white paper on the fourth industrial revolution (Industrie 4.0) in collaboration with McKinsey suggests that to avoid getting stuck in prolonged “pilot purgatory” plants shall start small with multiple projects. With this in mind, does technology and architecture choices play a part? Here are my personal thoughts:

• Think Big
• Start Small
• Scale Fast

Scale Fast

Plants must scale digital transformation across the entire site to fully enjoy the safety benefits like fewer incidents, faster incident response time, reduced instances of non-compliance, as well as reliability benefits such as greater availability, reduced maintenance cost, extend equipment life, greater integrity (fewer instances of loss of containment), shorter turnarounds, and longer between turnarounds. The same holds true for energy benefits like lower energy consumption, cost, and reduced emissions and carbon footprint, as well as production benefits like reduced off-spec product (higher quality/yield), greater throughput, greater flexibility (feedstock use, and products/grades), reduced operations cost, and shorter lead-time.

Early adoption of technology is important to stay competitive. Plants that get stuck at the pilot stage will not enjoy the benefits of digital transformation.

Start Small

The organization can only absorb so much change at any one time. If too many changes are introduced in one go, the digitalization will stall:

• Too many technologies at once
• Too many data aggregation layers
• Too many custom applications
• Too many new roles
• Too many vendors

Technology and architecture choices can help

Multiple Phased Projects

McKinsey research shows plants successfully scaling digital transformation instead run smaller digitalization projects; multiple small projects across the functional areas. This matches what I have personally seen in projects I have worked on.

From what I can tell it is plants that attempt a big bang approach with many digital technologies at once that struggle to scale. There are forces that encourage companies to try to achieve sweeping changes to go digital, which can lead to counterproductive overreaching. For example, don’t write a specification for 3D laser scanning, artificial intelligence, big data analytics, connected classroom, digital work orders, drones, gamification, heads up display, learning boards, machine learning, nano technology, performance management system, planning and scheduling, robotics, social media analytics, supply chain management, vendor management system, and video analytics all rolled into a single project. This would be too taxing on capital, personnel, and other resources. Spread too thin it would take too long to be successful.

The Boston Consulting Group (BCG) suggests a disciplined phased approach rather than attempting to boil the ocean. I have seen plants focus on a technology that can digitally transform and help multiple functional areas with common infrastructure. A good example is wireless sensor networks. Deploying wireless sensor networks in turn enables many small projects that help many departments digitally transform the way they work. The infrastructure for one technology can be deployed relatively quickly after which many small projects are executed in phases. That is, there will be several projects ongoing at the same time but they share a common infrastructure. Perhaps one new project in the pilot phase and one project in the scale-up phase for each department; maintenance, reliability, process, energy, production, quality, and integrity etc.

Small projects are low-risk. A small trial of a solution in one plant unit finishes fast. After a quick success, then scale it to the full plant area, and then scale to the entire plant. Then the team can move on to start the next pilot project. This way plants move from PoC to full-scale plant-wide implementation at speed. For large organization with multiple plants, innovations often emerge at an individual plant, then gets replicated at other sites, rolled out nation-wide and globally.

Small projects are low-risk

Use Existing Platform

I have also seen big bang approach where plant pours a lot of money and resources into an additional “single software platform” layer for data aggregation before the first use-case even gets started. This new data aggregation platform layer is meant to be added above the ERP with the intention to collect data from the ERP and plant historian before making it available to analytics through proprietary API requiring custom programming. However, duplicating a mix of data from business and manufacturing systems above and below level 3.5 in the enterprise architecture into a single data lake is a major IT integration project which is time consuming. This slows down the digitalization because there is so much integration work to be done before digital transformation can even start. A costly additional platform layer leaves less money for the actual use cases. But there is a better way.

Instead, successful plants start small projects using the existing data aggregation platform; the plant historian. The historian can be scaled with additional tags as needed. This way a project can be implemented within two weeks, with the pilot running an additional three months, at low-risk. OPC-UA (a standard open API) allows all kinds of predictive analytics apps to access data from a mix of underlying data sources such as the existing historian, control system, machinery protection system, electrical system, and package unit PLCs etc. A system architecture built modelled on the NAMUR Open Architecture (NOA) allows the plant to scale fast, maximizing use of existing infrastructure and augmenting it rather than duplicating it.

The existing historian is the platform – just extend it

Ready-Made Solutions

The McKinsey white paper highlights software development can be highly complex. Plants may underestimate the time and resources required for custom programming analytics apps in Python, ‘R’, and other programming languages. Once you consider the multitude of equipment types available in a plant: pumps, compressors, heat exchangers, cooling towers, blowers/fans, air cooled heat exchangers, relief valves, and steam traps etc. you understand the complexity of taking on such a software project. It is incredibly hard to completely specify all the requirements for any moderately complex software. Many requirements will invariably be left out, which translates into variation orders with the risk of high cost and delays. Custom software invariably have long implementation periods with coding, testing, and verification - in many iterations.

Instead the white paper suggests using off-the-shelf solutions. Successful plants start small projects using tried and tested ready-made software. This matches what I have personally seen. Off-the-rack analytics apps are already available for plant equipment like pumps, heat exchangers, steam traps, and relief valves etc. No custom programming required so it becomes a low-risk project. A project including sensors and software can be implemented within two weeks and can even skip the pilot stage altogether because the solution including software has a track record already proven in multiple other sites. Plants run the pilot for a few months before deploying at scale.

Proven track record software means low risk

Ease of Use

A McKinsey article notes it requires a lot of effort and expertise to develop accurate machine-learning models, and the cost and complexity may ultimately limit their application. Hiring data scientists to work on such analytics tools is costly ant it takes time to know the line of business. Historical data cleaning and maintenance records classification can be time consuming. But there is another solution.

Instead the McKinsey article suggests it is often possible to address a potential problem in a simpler way, for example by monitoring the temperature or vibration of a component against a set threshold. Model-based predictive maintenance becomes a breakthrough way to solve selected high-value problems. It notes the approach has the most potential where there are well-documented failure modes with high associated downtime impact, for example in a critical machine on a larger production line. It suggests automating approaches such as fault-tree analysis as well as cause-and-effect or failure-modes-and-effects analysis (FMEA). Using such engineered analytics approach based on direct sensing, first principle (1P) models, and FMEA matches what I have personally seen. Plants successful with digital transformation use predictive analytics purpose-built for pumps, relief valves, or heat exchangers etc. They start small projects by deploying user-friendly analytics software with a simpler user interface requiring no data science know-how, and that can be setup and used by the existing personnel in the plant such as reliability engineers and maintenance technicians with little or no training. Because it can be done by existing personnel without hiring additional headcount it is very low risk. A project can be implemented within two weeks, with the pilot showing success within a few months.

Sensors are the new analytics

Digital Ecosystem

Mixing sensors for different measurements from multiple vendors using dissimilar sensor network protocols, and backhaul network protocols, with analytics apps for monitoring different equipment from many other vendors is certainly possible but can be unnecessarily complex due to the need for protocol conversion and data mapping resulting in project risk including delays.

Plants successful with digital transformation start small projects using components designed part of a digital ecosystem. This means, sensors and software were specifically designed to work together. Sensors can interface with the software without protocol conversion or data mapping. This makes deployment faster and easier, and very low risk, as everything was designed by the same manufacturer to work together. A small project can be implemented within two weeks, sensors and software. An important observation is that the digital ecosystem must be based on open standards such as FOUNDATION fieldbus, WirelessHART, and OPC-UA such that third-party sensors and software can be integrated if need be.

Digital ecosystem means products were designed to work together

Think Big

I personally like to add you must also think of the bigger vision. A plant cannot run multiple small projects in isolation resulting in siloed solutions. Plants successful with digital transformation early on establish a vision of what the end goal looks like. Based on this they can select the technologies and architecture to build the infrastructure that supports this end goal.

Discovery Session

So what is that bigger vision? To find that out, start with a discovery session to uncover the many challenges around the plant faced by the various operational departments. A discovery session gathers stakeholders from the many operational departments; maintenance, reliability, process, energy, production, quality, and integrity etc. The facilitator ask questions to uncover challenges. Challenges often boil down to manual and paper-based procedures, as the root cause of lack of information. The outcome of the discovery session is a report which in turn becomes the input for the digital roadmap including the many small projects. A discovery session need not be a big show with multiple breakout sessions and with sticky notes on the wall, there are a few simple formats that produce good results.

One methodology is to review the typical tasks in a plant and capture the problems around these. Once the participants learn about the possibilities of these digital technologies in existing solutions this also inspires new ideas around other plant-specific tasks that have challenges. Solutions that don’t exist yet can be co-created using available building blocks.

Another approach preferred in some plants is a methodical review of selected plant documents and records. For example, reviewing the equipment on the plant P&ID will surface challenges around these, failures in the maintenance log, incident records, and procedures etc. The challenges and ideas are captured.

Common Technology and Operational Infrastructure

Plants must not do the small projects in isolation because without a big vision the site may end up with a many piecemeal wireless solutions that only works for one type or one brand of sensors, and none that works for all the solutions. For instance, the first digital transformation project may be to monitor valve position to ensure correct valve lineup to prevent tank overfill or product cross-contamination. Looked at in isolation, the engineering team may inadvertently select wireless position transmitters using a wireless protocol only used by that vendor in that transmitter, and deploy one or more wireless gateways for those sensors. Once the second project rolls around, for instance steam trap monitoring, they will now discover the steam trap sensors use another protocol that requires other gateways. This would cause delays. And it would be impractical to deploy at scale.

Instead, successful plants look at the big vision which requires monitoring of all sorts of parameters: corrosion, erosion, vibration, position, level, discrete, flow, pressure, temperature, acoustic noise, and maybe H2S gas. The I&C departments then select a wireless sensor network technology for which sensors for all these measurements are already available; such as WirelessHART, and build a single common wireless sensor network infrastructure which can be shared by all operational departments for their measurement needs. This is very much neater and lower cost to deploy and maintain. More importantly, it allows plants to scale their digital transformation very fast because as the I&C department extends the shared wireless sensor network infrastructure in phases from unit to unit, and area to area, across the plant for the first application, subsequent applications use that same common infrastructure.

Shared infrastructure, shared rewards

In plants built using FOUNDATION fieldbus, some sensors such as common pressure, temperature, level, and flow can very easily be digitally integrated using those networks. This is ideal for measurements that require fast update periods, such as the discharge pressure and on pumps and compressors.

Similarly, the data from the various application cannot be trapped. The data generated must be accessible. Having said that, the solution is not to aggregate copies of the information from various systems into “single software platform”. Such a centralized eighties style system architecture is not practical as explained above.

Instead, I&C departments successful with digital transformation requires do aggregation the modern way: integrating multiple data sources through a standard API: OPC-UA. That is, every data source is an OPC-UA server, and every application using data is an OPC-UA client. This way an intermediate data aggregation platform layer is not required.

OPC-UA is a “virtual” data aggregation platform

NAMUR Open Architecture (NOA)

The system architecture for the digital operational infrastructure (DOI) is important. The wrong architecture leads to delays and inability to scale.

Some plants have gotten stuck in the process of attempting to implement digital transformation solutions within their existing DCS, running into various roadblocks. For instance, installing third-party software in the core DCS servers and workstations with concerns of jeopardizing the safety and integrity of the DCS. Connecting all sensors through the DCS would be challenging to implement in an existing plant. Sensors, gateways, and software introducing new protocols not for industry but for home automation and other consumer applications, incompatible with existing I&C tools like HART/fieldbus field communicator, HART modems, fieldbus interfaces, and Intelligent Device Management (IDM) software as well as established procedures and work processes. No standard API for data access deployed in the DCS results in difficulty to find the right analytics apps able to use data from the DCS. No pass-through of field instrument protocols results in inability to access auxiliary measurements and diagnostics in field instruments. No sensor network infrastructure provided, instead attempting equipment analytics using only process data and manually collected equipment data. Analytics apps requiring proprietary data aggregation platform, and therefore limited or no selection of analytics apps, requiring custom programming. There is a better approach, now being formalized.

To address these architecture issues, NAMUR (User Association of Automation Technology in Process Industries) has defined the NAMUR Open Architecture (NOA) to enable Industry 4.0. I have found that plants that have deployed digital operational infrastructure (DOI) modelled on the same principles as NOA are able to pilot and scale very fast. For instance, core process control DCS remains as-is, thus preserving safety and integrity of the DCS. The DOI is added as 2nd layer of automation on the side of the DCS, maintained by the I&C department just like the DCS, which works for both new and existing plants. It is based on existing I&C standards, compatible with existing I&C systems, tools, and ways of working. They use OPC-UA interface from the DCS for open data access. In some plants they also provide a 2nd channel interface to networked instruments to access auxiliary measurements and device diagnostics like plugged impulse line and valve travel deviation. These sites use digitally networked add-on sensors for automated collection of equipment data. Data sources are fitted with OPC-UA servers providing the flexibility to add analytics apps as needed.

Digital Operational Infrastructure (DOI) is a second layer of automation

Flying Start

The I&C department in plants can accelerate digital transformation to achieve operational excellence and top quartile performance by remembering Think Big, Start Small, Scale Fast. These translate into a few simple design principles:

• Phased approach
• Architecture modeled on the NAMUR Open Architecture
• Ready-made apps
• East-to-use software
• Digital ecosystem

The future is digital. Start the digital transformation journey with discovery session to uncover the challenges that have to be addressed. Develop a digitization roadmap based on the findings. Build an architecture modeled on NOA starting with a wireless sensor network in one plant unit, and expand it in phases. Installed easy-to-use ready-made analytics apps. With this the plant should be able to digitally transform at scale. Well, that’s my personal opinion. If you are interested in digital transformation in the process industries click “Follow” by my photo to not miss future updates. Click “Like” if you found this useful to you and “Share” it with others if you think it would be useful to them.