It seems all IIoT is paved with good intentions. Yet many still are caught up in the “Pilot Purgatory” that McKinsey & Co and the World Economic Forum suggested is plaguing our present pathway to moving towards the 4th Industrial Revolution. In their white paper released in January 2018 called “The Next Economic Growth Engine- Scaling Fourth Industrial Revolution Technologies in Production,” they tackle this well.
We still face many problems in taking the “idea” of transformation through pilots into full-scale implementations. Many companies are in the investigative phase, where it is estimated that the average number of pilots can be around eight different industry 4.0 solutions. That is a fair amount, so why do we still seem trapped in pilots.
I think it is for many reasons; let’s take a look at several inhibitors here as my view:
Pilots seem cheap, so let’s do one, or even a few is an easy option.
Firstly a pilot is a relatively cheap way to evaluate if a solution can work from a technical perspective in a limited and safe environment. This small scale, controlled environment gives a good initial understanding of some of the challenges that might happen when you begin to scale.
Pilots get the ball rolling. Many cynical people would argue it allows all sides in the eventual debate to point towards their understanding of the results from the pilot to point out its advantages but equally show every reason not to change the current situation. Pilots actually can open up more of the “hornet’s nest” than we all initially perceived.
Pilots do need care; as you resolve issues that build technology understanding, they cause that growing focus on the technical aspects of the solution and many companies lose sight of the broader implications and impacts.
The overemphasis placed on pilots
Pilots also tend to have dispropriate resources than the eventual deployments, and that resource underestimation becomes a real impediment when you do scale something out. The underestimation of resources, of recognizing one process, in theory, has multiple versions supporting it. Software versions across a global organization can be massively different from migrating to the solution you want to put in. This legacy issue, or lack of a common platform, can take more years to resolve than implementing the chosen solution. I can recall one evaluation just in one region of the world where there was 60 plus different versions of ERP being in operation.
Pilots for free- you’re welcome.
I like this piece of advice to solution providers
“Don’t do pilots for free, because if the client is unwilling to pay at least something towards these, then you have really not found a problem they feel is not worth solving, and with all your efforts, you are most probably unlikely to see any money or return even if the pilot is successful“.
Of course, if it is to validate your technology to build a use case, it is different.
It is easier to set the vision than actually getting the organization aligned to what the change process actually entails in efforts, costs and most importantly, who pays for it internally.
Well, how fully confident are you with the actual solutions developed?
Some exceptional savvy people develop the solutions but who have minimal hands-on experience. The more experienced executive is very reluctant to change, often taking the attitude of “why mess with something that works”, and this “divide” often traps solutions in this stress testing due to a lack of confidence that an industry-specific set of solutions can actually solve my (unique) problems.
We are also caught up in the increasing world of rhetoric. The over-hyping of technology, what it can solve, the time it takes, the downplay of time, impact and cost. The company executive has a level of ingrained scepticism, hears everything is so innovative they suffer that classic “innovative fatigue”, so pilots get designed to be set up to fail or prove the claimed points. That attitude dooms so many.
A world of constant change brings in more headaches.
The argument against simply standing still is correct, but who wants to implement version 3 and, by six months down the track, start upgrading to version 4 without the change itself being embedded. No manager likes to inform the board the millions they are spending is already out of date, but it does seem a real reality today with the pace of technology change. The last thing is to get the technology solution wrong, placed on the wrong platform, architecture as something that needs radical revisions as software, platforms, and mergers keep altering the technology landscape daily. Little wonder committing to scaled deployments does not have a certain “career-limiting” risk to making those decisions.
Dealing with the cascading “knock-on” effect when you add something new into a current process.
Of course, having a pilot is more than likely as it represents a change from existing processes. The cascading effect or implications of bring a new (part) system into the process that the “knock-on” effects are fully evaluated and solutions ready to make initial ‘workarounds’ and eventual solution fixes.
The whole alignment between all the myriad of different groups involved that evolve operations, manufacturing, finance, OT and IT, facility and maintenance bring consistent descent, comment, and their opinions. Handling the alignment in a pilot small scale is very different than across a diverse global operation where different levels of capability, capacity and competence “reside”.
For any 4IR change – what are you trying to change?
The importance of achieving really high levels of connectivity yields much of the productivity value. With such variable technology provision globally, many solutions become “compromised” simply because of the inability to fully connect up all the parts. Old machines operating in one country are equally important to the latest, state of the art if you are trying to achieve a global overview and “real-time or near real-time” of your operations.
The ability to resolve technology constraints become not just country-by-country but often plant-by-plant or machine-by-machine. Pilots might help solve several broader technical issues but fail to account for all the variables you can find when you begin to roll this out across all your operations.
I recall living out of a suitcase, country by country, being fully resident to tackle their problems, for a period of nearly three years. Finding this was as much overcoming one specific site problem after another as implementing a new global solution. Tackling local workarounds to meet global criteria was often harder to overcome as they were physical, logistical and technology-related, sometimes needing operations to re-house to achieve the solutions required.
My biggest “beef” today is the simple throwaway line of seeing the “use case”.
So many of these drive me nuts. They lack substance, they are not thought through, and most self-justifying from those selling the solutions. How many “use cases” are just showcasing for the IoT providers technology prowess? The person doing the evaluations gets very little in their initial understanding. They often can’t relate to the “real-life” example provided as it lacks so much detail. All they are encourages is to contact the “sales rep”.
How often do you get a case history of what worked, what needed to be modified, what we learned, what impact it had, in time and additional costs, what needed more work or re-work and what plainly did not work, and we needed to pivot that accordingly. The results are often sanitized; they lack compelling validations and open sharing.
I really find “use cases” as poor in so many cases. Do they go through the goals, scope, complexity, context, conditions, triggers, success and setbacks, major events and interactions that arose, success scenarios, etc.? We need to push for much better “use cases” to identify, clarify and show how the outcome was organized.
So I can relate to pilots and the purgatory so many go through
What are my “sage” pieces of advice?
- You have to really try to work out how the changes will impact your existing processes or systems and get a “feel” for the real, hard gains or potential paybacks.
- Make them real and tangible; if you can’t do it, keep pursuing the pilot into purgatory.
- Make that consistent list of “what worked, what needs more work and what clearly does not work” and keep that ruthlessly updated.
- Remember, it is business value, not technology. Any pilot needs to really focus on core business issues and deliver a different impact to justify the resource involvements,
- Forget the solution providers offer of help; it is yours that gives continuity, understanding and growing expertise.
- Do not feel “seduced” as technology is seductive. It is how it works in your environment, not shown at an event, demonstrated in a staged situation; it needs to meet reality in your world.
- Do not delude yourself. You are not so often at the forefront of digital solutions; you are mostly catching up.
- Setting the vision is easier than mobilizing the organization to change- always remember that.
- Work on a road map really early on. Sketch it, talk about it, revise it and then test it with selective pilots
- Do not forget the cost of disruption at all stages- pilots also need to be worth it. No compelling impact then you are engaged in pilot theatre.
Finally, we have perhaps four main needs to experiment, pilot, change and scale
- The solutions give you agility and responsiveness that the current processes do not
- It releases resource to be more adaptive, gives real productivity, efficiency, and effectiveness
- You do get speed to market and eventually lower costs, otherwise what’s the point in today world?
- You are able to customize to customer needs increasingly
Escape your pilot purgatory. Jettison or Propel. We must scale to realize the benefits of the technologies supporting the 4th Industrial Revolution, otherwise, we stay trapped in the past.
