Digitalisation strategy as community effort
I recently wrote a lengthy article about digitalisation in the enterprise, particularly the challenges for cross-functional topics such as IoT or data science in large organisations. I hypothesised that unclear responsibilities, vague goals and a lack of communication between organisational units contribute significantly to the failure of IoT projects and entire digitalisation strategies.
The original article mentioned power play and territorial behaviour as two issues that hinder the digital transformation of a company. We probably all agree that there are good practical reasons why some projects need to change owners, pivot in scope, be declared unsuccessful and shut down, or, when they are successful, have to open up to integrate or consolidate with other ongoing digitalisation initiatives. However, expect strong opposition from individuals and teams if their project is under threat. This may have simple personal reasons (hurt pride), but the very issue could also be deeply rooted in an organisational problem: What if the project manager’s manager’s bonus is dependent on a different performance index of the very project, and from his perspective it would make sense to carry on as is? And then, obviously, also beware organisational justifications that originate from career ambitions and other personal interests. It is very easy to imagine how ill-defined organisational goals, misaligned strategies, silo thinking and intellectual smoke screens between departments provide fertile ground for nasty company politics. These problems are by far not unique to recent IoT projects, as this useful article from 2012 about enterpise IT architecture shows.
“Go and implement some Industry 4.0 approches”
“Implement some Industry 4.0”, said no good manager, ever! But I’ve heard it’s been written into annual target agreements… Nonsensical targets based on hype and hearsay are costly for every organisation. “We need blockchain!” — though any simple relational database would do, for example. “Let’s do Hadoop!” — with the implicit hope that big data can make up for outdated desktop computers and inefficient work routines. That’s not going to help.
A good digitalisation strategy defines achieveable and clearly measurable outcomes, ideally beyond monetary gains and savings, based on all available data and expertise. Self-contained, manageable and realistic projects that yield a minimally viable product (MVP) make a lot more sense than a company-wide call to “go digital” or “do some Industry 4.0”. Rather than one or many uncoordinated initiatives that yield unnecessary replication of work, bind a lot of resources and that negatively impact the everyday operations of the company, a mosaic of MVPs that ultimately become interconnected is a lot more sustainable and robust to the occassional failure.
How do you plan those MVPs? There are frameworks for the execution of IoT projects from a strategic perspective. While IT project management frameworks are abundant, the interdisciplinary nature of IoT warrants their special treatment. Largely motivated by the fear of potential customers of the complexities of an IoT strategy, Bosch Software Innovations published the Ignite IoT Methodology in 2015, with contributions from industry analyst Machina Research and others. Their book Enterprise IoT opens with use cases around manufacturing, connected car and smart utilities, before going into the commercial and technical questions project managers must ask in these fields. Importantly, before going into hardware and software, strategy, opportunity identification and opportunity management are addressed as part of the Ignite IoT method. The business case is at the very core of this strategy. The AgileIoT framework (soon to become Eclipse project Duttile) is more focused on delivering IoT solutions in an agile and DevOps-oriented manner. However, similarly to Ignite, their prototyping phase also knows a vision definition and a definition of success, and addresses important strategic aspects such as retreat options in case of project failure. Topics like company agility and company improvement conclude their approach. However, both Ignite and AgileIoT assume somewhat obvious, generic use cases for which the practitioner needs to identify a suitable analogy in his or her application domain. But what does predictive maintenance really mean when you are a site operator for oil and gas, and how is it different to the job of somebody looking for similar applications in liquid gas handling? I’m calling for nothing less than a community effort to identify such use cases in order to build a strong portfolio of projects.
Let’s take a detour into to open source software. This is software developed in a collaborative manner that generally is available for free. It means that somebody invests time and effort to implement certain functionality without the immediate expectation of revenue, and others take that software and use it for their own purposes. What is striking is that after, in the beginning of the open source movement, mostly individuals donated their time to a common good, more and more companies are chosing to contribute sometimes entire teams to open source development. The reason for this is simple: Nobody gains a competitive advantage by writing commodity software like the seventh XML parser, but everybody wins by reusing a stable code base that is shared and tested by a community.
We need open frameworks that impinge on the level above Ignite IoT or Agile IoT: Ideas and concepts that can make an entire industry better, not just the occasional proof-of-concept.
Like open source, but for processes specific to a vertical…
I doubt that being better at predictive maintenance of the blast furnance air filter or something similar is going to be the competitive advantage in the steel industry. Similarly, sharing that the overall equipment efficiency (OEE) of a bioreactor can be improved by monitoring certain forms of sediment is not the decisive factor in the battle of biotech companies. There are other USPs that differentiate them. However, aforementioned scenarios are what, in the current phase of Industry 4.0, each and every enterprise seems to think about. This is the painful commodity issue the software field has learned to avoid. However, for IoT in particular verticals, everyone seems to be reinventing the wheel. For a given application domain, we should identify and fix what everyone is encountering (and what doesn’t give away the USP).
In terms of archictectural patterns, there are already great efforts to streamline digitalisation efforts in the brown field. Take RAMI 4.0, for example. The Reference Architectural Model for Industry 4.0 outlines in great detail how the technical components, e.g. of predictive maintenance solutions, should interface and which standards should be adhered to when connecting operational assets to enterprise IT. While I accept it is impossible to demonstrate the utility of such approach for the use cases on each and every shopfloor, what RAMI is missing is practical guidance as to which manufacturing devices would benefit from predictive maintenance, how easy or hard it is to collect relevant data, and what the business case for the respective device is. As a result, there are probably hundreds of proof-of-concept or feasibility studies for blast furnace air filters around the world… …and I thought digitalisation meant doing things more efficiently.
I’m currently looking into the opportunities for IoT in particular areas of the chemical industry. Would it not be clever if everyone working in a similar environment would share their findings? If Charlie from the Chocolate Factory would tell me that real-time tracking of the Oompa-Loompas is generally a waste of money, but kitting out the Warming Candy Room with sensors is indeed a splendid idea and should go first on my OEE optimisation list?
An exchange like that requires a new mindset and the acceptance that, in some respect, even your competitor can be a partner, and that nobody is losing out if we are talking industry-wide efficiency gains. This may sound like a socialist pipedream, but especially around energy efficiency and waste reduction, the advantage for society as a whole should be an incentive.
Recommendations and whish list
So far this was really just a review of how I perceive the situation, not just in our, but most organisations I’ve interacted with over the past years. I conclude:
- Organisations need to commit very clearly to digitalisation. You can’t just add tech, you need to shake up processes. That’s probably why it’s called 4th industrial revolution.
- Baby steps and proof-of-concepts are good. However, declare an organizational champion (digital leadership) to coordinate and oversee these projects. There is no point of work being replicated. The organization can only learn from the PoC if the results are widely shared.
- Waste is bad. If successful, make sure that your PoC can live on in production. That also implies that you declare your interfaces (both technical and process) early on so that the organisation can adjust and benefit from your work.
- Have a portfolio of projects that complement each other. What is the point of three feasibility studies assessing the impact of a certain technology when the real organisational pain points remain unaddressed? This is a natural development as everyone is going for the low-hanging fruit, while deferring the really hard problems to a later stage.
In respect to the last item, how should one prioritise projects? Every good manager will probably say “go for what makes the biggest impact”, as that keeps upper management and project sponsors happy. However, that is easier said than done.
The people who know the real pain points in manufacturing are operational engineers, not digitalisation, IoT or data science specialists. There are exceptions, but the reality is that there’s a significant knowledge gap between OT, IT and other technologists. Conversely, the greatest data scientist doesn’t add value without an understanding of the manufacturing process, and be it the fact that they may be able to predict a certain type of machine failure, which in practice rarely ever happens…
This brings me back to knowledge sharing within particular industries, similar to open source. I wish for a framework one level above Ignite IoT or AgileIoT that tells me:
- How to take stock in a novel manufacturing environment in industry X?
- What are the real pain points in the manufacturing of Y?
- What type of machinery I can expect to encounter in the production of Y, how often it breaks, how much it costs to repair, and what the impact of said machinery is on the production process? An example for the utility of such info is this:
- Is there a better opportunity for money saving when preventing failure of machine A, of which there typically are dozens on the shopfloor and that break often but are cheap to repair, or should one rather do a costly retrofit of machine B, that rarely ever breaks but when it does it’s real painful?
Those are the questions that OT can answer more easily than anyone else, but they may not even be aware that those are the interesting and relevant questions to a digitalisation team. At the same time, OT is a key resource and they only have limited time for, what they might perceive as, academic chit-chat. Thus, unfortunately, these conversations happen not as frequently as one might hope. A central port-of-call for questions around digitalisation in the manufacturing of “X” would be truly beneficial!
