– Jonathan Hobday, Sales Director at Innovise IES, says:
I was talking to a client recently who was explaining that prior to Cortex their automation had consumed as much effort in managing failure, as it had saved in automation. Not really a success story then, but now, 2 years into Cortex, this client is a transformed business. It made me think of a popular cultural saying “Monkey see, monkey do”. It is a saying that popped up in American culture in the early 1920s. This refers to the learning of a process without an understanding of why it works.
Automation takes a similar view of the world: We “see”; we analyse the process we want to automate. We capture this into a system then “fire it off, either manually, or through automated triggers again, and again, and again. It’s not long before it goes Boom! So why does it go wrong?
Thinking about the implicit message of “Monkey see, Monkey do”, it really describes the kind of actions that should be prime candidates for reliable automation. The kind of highly repeatable processes we can effectively automate do not require a highly evolved decision making power, just like a monkey who mimics your actions. But just like a monkey, he will mimic your actions then check back in. It is “Monkey see, monkey do… Monkey see, monkey do…” not “Monkey see, monkey do, monkey do, monkey do” which, even a monkey would know, will eventually result in “monkey failed” – just like the automation.
In automation, popular activities have focussed on capturing, then coding processes, so called “hard coding” because it is repeatable and unchangeable. This works well in isolation for specific universal processes but frequently fails when integrated into real world environments due to new events, exceptions, change, systems failures, or simple environmental change. So the obvious solution is to make the processes around these “fixed systems” adaptable, as automation engineers would say. There is general consensus that this is the smart route to travel, however this perspective has created multiple roads, and unfortunately an entire cottage industry of consultants who will erroneously identify individual aspects of change in the “fixed system” for causing the failure including:
- The model was incorrect…so goes the story of model based development, standards and best practices like Swim Lanes, Flow diagrams, and ultimately BPMN with its abstraction from the real process.
- The implementation needs to be more flexible…so goes the story of implementation standards like BPEL and XPDL, WS-BPEL and their change processes
- It was just an external environmental issue…so goes the story of Event management, Complex Event Processing, Operation Intelligence
..and it goes on. As we are forced further and further down this route of the “Monkey do, monkey do, monkey do…” we drive harder and faster to be better. We know where this ends up. What was that definition of insanity again?
The more pernicious perspective is that the further we travel this erroneous track, the higher we make the economic barrier to entry. It takes more effort, and time to automate so only the highest value or highest frequency processes are automated and then managed by skilled technicians who struggle to keep pace with change. Ultimately, killing off the benefits of automation to the business.
Industrial automation experts have travelled this road over many years, and to extend the analogy, not ended up in the cul-de-sac of just doing more. Industrial automation engineers have been dealing with automation for decades and can achieve reliable fully automated factories with a minimal number of adaptable systems, supervisory controllers and adaptive processes.
Can you imagine working in a nuclear power station. When something changes, it would be surreal to be told to go and “do it manually”. There is no “manually” in nuclear power. Industrial automation experts have learned to bring together environmental variables, with process and policy knowledge to automate the decisions, which drive processes in a single system whilst adapting to change at a granular scale.
So why is it, for example, IT Process automation specialists think it is OK when automating user provisioning to add a user to Active Directory without the right pre-checks, and post confirmations and without constant revision of the process depending upon the environment, policy, event, or incident? What happens if you cannot connect to the Domain controller? What happens if the network is slow?
The simple answer is that you can’t check everything, and if you did, the process would be so arduous and complex, it would be futile so they code what they can and deal with the failure… manually. This is what my client was talking about.
So let’s do more to get it right with automation expert platforms, not more software tools.
At Innovise, we put our clients back on the automation superhighway where situational awareness creates operational intelligence and drives automated decisions inside processes on a single platform. Our clients are not stuck up the auto-destructive cul-de-sac with a cottage industry of consultants, fragmented software and complex standards.
