Steer Your DX Project Through the Gate Process

Most companies have a stage-gate process for innovation and project approval, such as for thoughtful #DigitalTransformation (DX) including #IIoT, to ensure the right problems are solved, in the right order, with the right solution, with good returns, and is successful before it is scaled-out. To drive transformation you must navigate this gate process. Since budgets are finite your project competes with others for investment. So how do you manage development and get projects approved and funded? Here are my personal thoughts:

Stage-Gate Process

Many companies use the Cooper Stage-Gate process or a derivative to approve and manage innovation and solution development. The process has 5 gates (screens) and 5 stages (phases) preceded by ideation (stage 0). An additional 6th stage for review is a good practice. This process is used for approving and developing #Industry4.0 (Industrie 4.0) projects as well. Including innovation of solutions to plant problems using off-the-shelf products in innovative ways. Each use-case is managed based on the stage-gate process. After brainstorming use-cases, you must first show it is feasible and will pay off. And then develop and verify any new untested solution before it gets approved for full deployment. Concurrent use-cases will be at different stages of this approval process.

Preceding each stage, or between stages if you will, the details for each use-case solution is reviewed to either Go on to the next stage or Kill based on the results from the previous stage. At each gate-review the leader for the use-case development must provide relevant input to the gatekeepers. It is decided to Go, Kill, Hold, or Recycle each solution development project. The plant may initially have a very ambitious roadmap with many use-cases. But you can’t do all at once. It would become too taxing on resources. So along the way some use-cases will be dropped or held back if the investigation finds they are too expensive, provide too little savings or revenue increase, are not technically feasible, doesn’t support strategic initiatives like safety or sustainability etc., not providing the plant a competitive advantage, has a risk of not being utilized, or doesn’t match the responsibilities of the intended users. Only the most meritorious solutions to plant problems come out in the end.

Multiple use-case solutions are at various stages of this development process at any one time and make their way down the funnel. The I&C team lead should maintain a few solution development projects at each stage so they trickle out one by one to be deployed gradually. This way work in the plant is transformed step by step.

Stage 0: Discovery

A consulting integrator may say your #IIoT solution should be microservices, blockchain, RPA, bespoke APIs and web services, tailored apps, 5G, tablets, custom programming, IT/OT convergence, MQTT, Big Data, plus a digital twin and neural network machine learning data science for everything - starting with their PaaS cloud platform. Laying such a foundation would be incredibly expensive and time consuming before even the first use-case is solved. Digital for digital’s sake. The Return on Investment (ROI) for the first few use-cases would not look good. And you may not need all that infrastructure to solve your plant’s problems. You may not need any of that as many plant challenges have solutions which are surprisingly simple.

The recommendation is to instead start by conducting a discovery session to uncover challenges the various operational departments in the plant have: reliability, maintenance, integrity, process/energy, health & safety, production, and quality. This way you make sure you are addressing real problems and not deploying digital for the sake of digital.

Problem first, not platform first

The I&C department drives the digital transformation in the plant, but they must work with the operational departments to uncover their challenges which are transformation opportunities.

Just saying “transform the whole organization” is meaningless. The workshop must go into detail of the tasks performed by each department to uncover the site-specific challenges. The transformation opportunities depend on the state/age of the plant and how the plant is currently operated. This is a group exercise ideation of challenges that could be addressed, improvement opportunities, and may include brainstorming of solutions. Empathize with the personnel having these challenges. Understand how work is done today. What tasks are manual? What tasks are paper based? What are the problems faced? Review the organization one plant at a time down to individual tasks. You will find there are lots of manual tasks carried out by all the people in the plant. This exercise is done without a plant walkdown. The idea is to transform these tasks one by one until the whole organization is transformed holistically. Your plant is a Sleeping Diamond. With the right polish to each facet a lot of value can be unlocked.

The discovery workshop also includes some form of ranking the challenges uncovered to prioritize the order they go into the development funnel. The prioritized list of use-cases is a first-cut roadmap for the digitalization of the plant. Not all use-cases identified will be implemented. That’s what this solution development process is all about.

The other recommendation is to also work with your automation suppliers to explore the art-of-the-possible. What readymade solutions do they have? Try out the look & feel in their simulated lab. What problems have they solved in other plants that also apply to your plant? You will discover new possibilities. Costs are not considered at this stage; it is reviewed in a later stage.

Stage 1: Scope

In the Gate 1 review, for each challenge identified in the discovery stage, decide if the use-case shall proceed for further evaluation or be killed. In some companies this is a 5 min stand-up ‘shark tank’ review. Since lots of challenges are identified there will be several use-cases that can proceed, but also many that are killed. Once all the use-cases identified in the discovery workshop have been reviewed, the roadmap will be a lot leaner.

The discovery workshop uncovered many plant challenges. The discovery session also looked at readymade solutions. But challenges and solutions may not necessarily match up perfectly. Some solutions may not be necessary. Some solutions may be missing. You might have a rough idea of what the solution to your use-case is, but too fuzzy to make an investment decision.

Review the current way of performing the task to better define the problem and new concept. Study other ways of performing the task, alternate solutions. Look at ready-made solutions from automation vendors. For instance, maintenance inspection of pumps today may entail periodic testing by personnel carrying portable testers and taking readings from mechanical gauges and capturing it on paper with pen and clipboard and then having to type it into software. This manual way of working may be the reason for surprise pump failures. The digital way is to put advanced sensors to collect the data sending it to analytics that gives an early warning to developing problems. An alternate semi-digital way is for personnel to carry a tablet instead of pen and paper. Understand the readymade solutions available off-the-rack, and which solutions would require custom software development. Look at the capabilities and limitations of the solution to understand how it will benefit the personnel performing the task. This initial study is done without a plant walkdown.

The recommendation is to match each plant challenge to a readymade solution and use that. One usually exists since plants have similar challenges and therefore similar use-cases. Most use-cases have already been done in other plants, often somewhere else in your company. If something is truly the first of its kind, then you innovate and co-create together with your automation supplier. Your use-case may require developing a new solution in which case you should strive to do it using off-the-shelf products. Only in the worst case go for a solution requiring custom programming. Usually solutions that can give quick wins, results you can see instantly, make it through this process first, so that is a good way to start. This includes solutions that provide energy savings. Such wins prove the value of digital transformation helping the funding of the next round of deployments which can include use-cases where the results take longer to become evident. Plan for deployment of individual solutions in short agile sprints.

The other recommendation is for plant departments to work in parallel on a few solution development projects. Each one in their domain.

Stage 2: Business Case

In the Gate 2 review, for each use-case investigated in the scope stage, decide if the use-case shall proceed for further evaluation or be killed. Use-cases for which proven readymade solutions are available or new solutions which use off-the-shelf components may make it through. Use-cases that require custom programming may not.

Tailoring apps, custom programming interfaces, merging IT (ERP) and OT (historian) data in the same data lake, a digital twin for the entire plant, and extract-transform-load historical plant data from multiple systems all have a hefty price tag. A pool of data scientists and PaaS cloud platform contract have high long-term cost. But only very few use-cases would need that, and they may not have a good return. Such solutions would not be feasible. However, many use-cases are lower cost and provide a good return.

Detail Solution Definition

The recommendation is to write a business case document for the use-case. This is essentially a feasibility study. This is a more detailed study. Still without having to walkdown the plant. Explain the potential value to the department responsible for the task being transformed. Explain the benefits the solution provides. Explain the features the solution has. Specify how many instances of the solution are required now and in the future. For instance, estimate how many pumps need to be monitored. There may be a need for an equipment criticality ranking if that has not been done before, but engineers often know from experience what needs to be changed. Explain how the task is performed today and the drawbacks of this old (current) way of working. Specify where the initial deployment or PoC will be made. If any custom software development is required this should be only by exception and the rational for this explained in the business case document as custom programming has higher upfront and lifecycle cost, delays, and dependencies that impact the business case ROI and Total Cost of Ownership (TCO). Similarly, if the solution is deployed in the cloud it should be IaaS or SaaS. If PaaS platform is required should be only by exception and the rational for this explained in the business case document as the dependency on a single vendor drives up cost in the long term. Use IEC standards like WirelessHART (IEC62591) for Wireless Sensor Network (WSN) and OPC-UA (IEC62541) for software interfaces. If any non-IEC standard wireless sensors or non-IEC software API / Web Services are used between vendors this should be only by exception and the rational for this explained in the business case document as non-standards have higher lifecycle cost, limits options, and makes migration impractical.

The site engineering team, the I&C team, and the department responsible for the task being transformed work together with the automation vendor on the definition of the solution and how it will be deployed. If the solution includes connection across the Internet such as to cloud hosted software or integration with the ERP system, the IT team must be included.

The other recommendation is to write the Functional Design Specification (FDS) requirements document for the solution. Reference available templates.

The recommendation, if the solution involves custom programming of software, is that special care must be taken in writing a detailed requirement specification for the custom software. If the software requirements are not complete and well defined, the app will not turn out as imagined. Variation Orders (VO) will be costly and time consuming, and may not fit in the original budget. There may be cost overruns or you may have to forgo a desired feature. It must be clear who will own the source code and documentation associated with the custom software.

Solution Cost

Get a solution cost estimate from your automation vendor; ideally their proven readymade solution, or the cost of a new solution using off-the-shelf products, or worst case the cost of a solution involving custom programming by an integrator. Don’t let a consultant-integrator reinvent the wheel at your cost. With purpose-built and readymade software the deployment effort, total installed cost, and time is kept low since there is no custom programming and no long data cleaning and algorithm training period. Plan for sensors which are wireless and ideally non-intrusive as they can be installed while the plant is running reducing the cost and delays. This way good ROI is achievable. Also get the automation vendor to demo the solution, particularly software, to the department responsible for the task being transformed. The automation vendor may be able to arrange a visit to other plants already using that solution. Your company may already be using the solution at some other sites. Get the automation vendor to provide links to product data sheets and manuals on the web so you have the details at hand and you know the solutions is off-the-rack and proven.

Keep in mind that many use-case solutions share common infrastructure such as User Interface (UI), analytics framework, data management platform, and wireless network infrastructure. That is, the cost of this infrastructure can be split over many solutions supporting multiple operational departments. This sharing is only possible if IEC standards like WirelessHART (IEC62591) for Wireless Sensor Network (WSN) and OPC-UA (IEC62541) for software interfaces are used.

Benefit/Value

The value of digital transformation solutions is reduced operations costs and increased revenue for the plant. For many use-cases there are readymade business cases and loss (potential savings) calculators you can reference. The savings potential is what you are currently loosing unnecessarily due to manual and paper-based ways of working. The recommendation is to quantify your existing losses. For instance how many failed steam traps and passing PRVs where found in the last surveys? Estimate the losses. What is the cost of downtime due to pump failure? Cost of breakdown overhaul? What is the cost of slowdowns due to cooling tower and fin-fan failure, or heat exchanger fouling? Operations keep historical records of energy consumption vis-à-vis production rate so you can see if this is increasing over time. Energy manager keep records of steam trap replacement so you can calculate your losses. Maintenance keep records of repair expenses. Reliability keeps records of downtime so you can calculate opportunity cost. Safety officers maintain records of incidents so you can calculate cleanup cost and more. Energy and labor rates vary greatly by world area and industry so calculate based on actual rates in your location to estimate what can be achieved for your site.

Development Schedule

Draw up the development schedule with milestones and date when the solution can be deployed and when it can go live.

Stage 3: Solution Development

In the Gate 3 review, the management and the department responsible for the task being transformed reviews the feasibility for each use-case studied in the business case stage to decide if the use-case shall proceed for detailed development or be killed. Solutions that require plant-wide infrastructure which is time consuming and costly to deploy, or solutions for use-cases where savings may take longer to materialize, will get killed or put on hold. Development of solutions that use infrastructure that can be deployed in just one part of the plant, or development of solutions for which savings can be seen almost instantly, go first.

The solution for some unique use-case may require a piece of software not available off-the-shelf. It could be an app or proprietary interface/driver to another piece of software. If so, it must be custom developed before Gate 4. However, considering the vast amount of ready-made software available and the vast proliferation of OPC-UA and OPC Classic before it, it is highly unlikely custom is required. If a consulting integrator proposes custom software as part of the solution it may be a good idea to doublecheck if off-the-rack software is available and why it was not chosen, just to be doubly sure you don’t get landed with bespoke unnecessarily. The solution for a use-case with a complex composite of multiple unit processes with many pieces of equipment may require machine learning analytics. If a predictive model is built from historical data it should be developed before Gate 4. Machine learning should not be applied to simple unit processes or single piece of equipment that can use ready-made first principles (1P) or rule-based analytics apps or templates.

The system integrator develops any custom app if truly required for the solution. They develop the app based on your requirement specification. Therefore developing a detailed requirement specification for the custom software is an important part of stage 2 if custom software is part of the solution. Without a detail definition the app will not be as good as you envision and changes will be costly.

The system integrator develops any custom API or Web Services for proprietary interfaces if truly required for the solution.

The system integrator develops predictive models for any complex composite of multiple unit process with many pieces of equipment using machine learning analytics on historical data.

Custom Software Prototyping and Alpha Testing

If the system integrator for the solution needs custom software as part of the solution, this stage also includes coding and testing the alpha prototype. The recommendation is that any custom programmed software is tested extensively by selected members of the department responsible for the task being transformed to find bugs and other issues in the custom app. This is done together with the system integrator’s programmers so they can fix the bugs and other issues well before it is deployed in the plant. This is an iterative process often done at the integrator’s site.

For readymade software, alpha testing has already been done so this step is not required.

Stage 4: Solution Test and Validation

In the Gate 4 review, the solution detail design is studied and the outcome of any custom software alpha testing is scrutinized. The cost estimate for deployment of the solution should now have very little uncertainty. For each use-case solution designed in detail in the development stage, decide if the solution shall proceed for further test and validation or be killed.

Custom software can have bugs or issues not found when alpha testing in a lab environment. Multi-vendor software integration can have issues if it is not done over a standard interface like OPC-UA.

Custom Software Beta Testing and Proof of Concept (PoC)

Custom programmed software has not been tested in any other plants so solutions developed incorporating custom software need a full Proof of Concept (PoC) field test. Testing shall include members of the department responsible for the task being transformed, but not part of the solution development project team, to give independent feedback. For custom software the recommendation is to run this test for an extended period for it to be exposed to various process conditions. This is done at site with real input data, not simulated. Bugs and issues discovered must be corrected. This may take several iterations of testing fixes, and retesting. This must be managed carefully to not get stuck in “pilot purgatory”.

For readymade software, beta testing has already been done and the concept is already proven in other plants (often within your company) so this step is not required. Proven solutions minimize pilots/PoC avoiding ‘pilot purgatory’.

Machine Learning

Solutions with analytics that build a prediction model using machine learning algorithms on historical data from the plant as training data set need additional testing. For instance, it could be a model for predicting process upsets in a complex composite of multiple unit processes and pieces of equipment. The first level of testing is using a different set of historical data from the plant to verify the model is able to predict the upsets in the verification data set. The second test is in operation using live data from the actual plant to make sure there are no misses and no false positives.

The most interesting fact is that for first principles (1P) and rule-based analytics, the algorithm in the app/template has already been proven in other plants (often within your company) so this step is not required.

Third-Party Software Integration Testing

Most projects require integration between software from two or more vendors. This may be between new software required in the project and existing software already operating in the plant. If this integration is done over OPC-UA or one of the older OPC Classic interfaces like OPC-DA, OPC-HDA, or OPC-A&E, this should work fine. However, if there are non-standard API / web services interfaces this should be tested early.

Stage 5: Launch

In the Gate 5 review, for each use-case tested and verified in stage 4, decide if the solution shall proceed to be deployed in the plant or be killed. Solutions that have been tested at other sites or in a successful PoC can be approved and released.

People, processes, and technology goes the adage. The previous stages have been mostly about the technical solution. Change management including people and work processes must also be covered as part of the deployment of the new solution.

Communicate the Vision

If not already, management must communicate the new data-driven vision for the operations. Management must communicate the importance of Digital Transformation and the various use-cases and their solutions. This shall be done over an extended period of time through company newsletter articles, company update address, townhalls and toolbox talks at multiple levels, sharing short video clips, social media, T-shirts and coffee mugs, and announcements of successful deployments and celebration of the employees. Plants also organize yearly “Digital Day” company events where automation vendors show the new tools they provide that will soon be introduced in the plant, so the people that will use these new tools can familiarize themselves in a relaxed environment, and some fun and games.

Learning and development (L&D)

Learning and development (L&D) for plant personnel to pick up new digital skills/competencies is important to close any skills gaps. The recommendation is to let people experience and learn the new tools before they are deployed for use. Involve the HR department up front to support with change management. The L&D team part of HR is best equipped to manage the assignment of courses to be taken and the follow up to make sure courses are completed. Work with your automation vendor to conduct the classes with instructor, material, and demo gear etc. HR can also help drive the culture change to a data-driven “check the software first” mindset.

Maintenance technicians, reliability engineers, and other staff are not data scientists and not programmers. And the plant can’t afford to hire a pool of data scientists. And programming is not their business. One of the challenges plants face is that it is hard to attract and retain skilled personnel. The purpose of analytics is to help non-experts to work like an expert. But if you need to be a data scientist or programmer to use the tool, it doesn’t solve the skills problem. Again, the recommendation is to select analytics and other apps which are purpose-built for pumps etc. and therefore intuitive and easy to use, to make sure skills gaps are not formed in the first place. General purpose data analytics would be too hard to use for the type of problems found in plants.

Standard Operating Procedures (SOPs)

Manual steps like data collection are now eliminated. Modify the Standard Operating Procedures (SOPs) associated with each role and the duties transformed so the new digital tools and new data-driven ways of working are reflected in the SOPs. Modifying the SOPs, replacing the old ways of doing it, with new digital work practices, is the whole purpose of digital transformation. This helps ensuring the new data and information is incorporated in the daily operation & maintenance activities.

Deploy in Plant

Start by deploying the developed solution in one plant unit, then scale out to the whole plant area, and then the entire plant. This is where traditional project management comes in. I&C engineers are experienced in managing automation projects involving advanced sensors, industrial networking, and automation software. Everything from engineering (architecture, network infrastructure, security, and advanced sensors etc.), fabrication, FAT, installation, integration, commissioning, and SAT.

Although most solutions are already tried and tested in other plants, there are location specific hardware and software configurations to consider. For instance, dashboard content is industry and site-specific, and role-based, sensors must be selected with the correct process connection, wetted materials, range, and mounting etc. Software must be configured for the type of equipment, sizing, and operating conditions etc. Not programming. Just parameterization. This is the time for a site walkdown to gather site-specific details.

Don’t change too many tasks at the same time. It would be too much change for personnel to absorb. The recommendation is to deploy the use-case solutions one by one in short agile sprints, until the plant is transformed holistically. The I&C team lead maintains a funnel of transformation solution developments to change how the plant is run and maintained. These are deployed step by step as they get Gate 5 approval.

It is time to start thinking about the lifecycle management for the Digital Operational Infrastructure (DOI) deployed to support the Monitoring and Optimization (M+O) use-case(s), the second layer of automation on the side of the DCS for the Core Process Control (DCS).

Stage 6: Review

You need to report the success of the use-case solutions deployed in the plant to show the value of digital transformation to help secure funding for the next project.

The recommendation is to collect ‘after’ data, compare it to the data from ‘before’ the transformation, and calculate the savings or revenue increase. For energy solutions this is possible soon after the system is turned on as inefficiency, flaring, leaks, passing, and other losses can be detected almost instantly. It is a matter of how quickly the recommended actions such as cleaning heat transfer surfaces, overhauling passing valves, and replacing failed steam traps etc. can be carried out. You should see reduced power and utilities consumption on your next meter reading. Inspection workload reduction can be calculated from fewer or shorter rounds. Maintenance and reliability savings can be shown as the system may detect a developing problem somewhere the instance it is turned on.

Thoughtful Transformation

So, with the gate process it is not digital for digital’s sake. Digital transformation in the Fourth Industrial Revolution (4IR) is thoughtful. Time and money are not invested blindly. Transform only what you need. Start small with a few use-cases and supporting Digital Operational Infrastructure (DOI). Then expand as you uncover more operational challenges in the future. Schedule a meeting today to speed up digital transformation. Forward this essay to your I&C manager now. And remember, always ask for product data sheet to make sure the software is proven, and pay close attention to software screen captures in it to see if it does what is promised without expensive customization. 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. Save the link in case you need to refer in the future.