Are you still managing the “Henry Ford”-way?

Are We Truly Embracing the Future or are we Stuck in the Past?

You must have lived on a desert island not to have come across the term "Industry 4.0" in recent years. It was the Buzzword of all Buzzwords in the period 2015-2020. You certainly started some 4.0 initiatives or you might even have created your 4.0 project team. Solution providers too had to jump on the bandwagon, if not they were quickly labeled "old school". 

Now here's the catch: we all claim to be living in the 4.0 era, but then why are we still behaving en masse like managers from the second industrial revolution?

In Google Trends you can easily search for what the Internet is waking up to, and that immediately gives us some insights into the importance of the terms Industry 4.0 (blue, top line) and Industry 5.0 (red, bottom line)

Conflicting answers 

When we survey companies about the importance of digitization in Manufacturing, we get conflicting answers:

• In an overwhelming majority of manufacturing companies, digitization is seen as strategically important (that’s a good start ;) ),

• At the same time, a large proportion of these companies find it difficult to take concrete steps, 

• Unfortunately, more often than not, Proof of Concepts/Pilots fail miserably or prove difficult to scale.

This is not so illogical. After all, the Industry 4.0 trend is a "technology push". That is, a technological solution is pushed forward and often introduced by the top management of companies willy-nilly. 

To make matters worse, there is often no Management Model that recognizes that introducing digital tools requires a different approach compared to building a physical asset.

Are you still doing it the Old-School way? 

Even though your organization often has Digitalization at the top of its agenda, many Digital Teams in those environments are still operating as they did in the days of Henry Ford. (No offense to The Man, he was a visionary in his days…) 

Technocrats like Taylor and Ford were looking for methods to make repetitive and known work as planable and predictable as possible. To them, employees were robots who were given tasks from a "command and control" center and had to perform them to perfection and repeat them endlessly. Project Management concepts such as the Waterfall method and (a bit later) Gantt charts were a godsend. 

Now we understand very well that when you are building a bridge or a production line, it is pretty useful to know which contractor should be present at what time. You are trying to eliminate risks and you are a happy camper when all milestones are met on time and on budget.

Ford Assembly Line, Source: https://corporate.ford.com/articles/history/moving-assembly-line.html

Join the revolution! 

Enter: The Digital Age…

We might be building a new operator app, a machine learning model to predict something or maybe a new data pipeline towards some fancy cloud software. All those projects have something in common: there are more unknowns than knowns.

• We don’t know yet if we will be using machine learning method 1, 2, or maybe we default back to a simple linear equation.

• We don’t know how our technology stack will look like until we have validated it

• We don’t have a full user requirements document as combining all things all users want will inevitably end up in a product which will never be completed.

• (and many more things, feel free to add all the crazy stuff you encountered in the comments)

Long story short: We kindly invite you to Join the Revolution! 

We, people of the revolution, do things differently: 

• We don’t believe in hierarchy any longer. If the boss is the bottleneck, scaling will never happen. Autonomy and direct lines of communication between people with a common purpose are the way to go. 

• Small product teams are empowered to follow the concepts of Agile and DevOps. They focus on creating Value in fast development cycles. (cfr the famous “two pizza sided teams” of Amazon)

• In order to improve speed, those teams limit their Work in Progress: learning to say “no” to the business is probably one of the more underestimated competences. (cfr The Goal by  Eliyahu M. Goldratt)

• Because we understand that there is no “perfect architecture” that will last forever and because use cases and technology change over time, Technical Debt emerges. It creeps in and makes development cycles longer and longer. Eventually our ship comes to rest dead in the water. Making essential changes to our infrastructure and software, to limit the Technical Debt is an essential part of what our teams need to achieve. 

• We believe in the power of validating a business idea by doing a Pilot, but because we don’t want to get up with the nasty disease Pilotitis, we make sure every pilot has a clear end-date. After this end-date, the pilot needs to stop or needs to be transformed into an actual product, serviced by a dedicated Product Team. 

• Finally, as access to process data is crucial in the OT world, we focus heavily on making that data available to everyone in the organization. 

Final Thoughts 

Each and every of the above points deserve a followup article and that’s exactly what we are planning to do. Make sure to subscribe and please reach out to us if you feel inspired and like to talk to us about some of your own stories.  

To conclude this post, we’d like to share some books on this subject:

For further reading, see also our new article on Culture:

And to end on a lighter note: Imagine a world where Apple would add each and every user demand to its products… ;)