When I returned to Geleen after Scotland, around 2007, I found myself in a rather different organisation from the one I had left.
The DSM Manufacturing Center (DMC) had been established a few years earlier. It brought together activities that could be centralised relatively easily: the plants’ Improve, Maintenance and Project activities, as well as functions such as Finance and HR.
The plants retained their core operations and some of the key knowledge bearers.
Central Engineering had also been dissolved, with part of its engineering expertise becoming part of an engineering expertise organisation within DMC.
The logic was clear. Instead of every plant maintaining all these capabilities independently, DMC could pool expertise and allocate resources according to the needs of the plants.
And this was a carefully designed organisation. Resource planning was supported by an extensive planning tool intended to match people and expertise with plant requirements. The way of working was closely aligned with DSM’s work-process documents, and the associated tools were deliberately standardised. I remember, for example, that part of the Asset Utilization data gathering had been built into SAP BW.
There was a strong belief within DMC that this combination of expertise, standardised processes and systematic resource planning made the organisation best in class.
There was quite a lot of justification for that belief.
But I increasingly found myself in an uncomfortable position.
Between the centre and the plants
The former Plant Manager from Scotland had become my boss. He headed four cluster leaders, each responsible for the improvement agenda of a cluster of plants. Each cluster had several engineers who worked more or less dedicated to those plants.
I became one of the cluster leaders.
Together, we also had responsibility for the HR aspects of all our engineers and, more remotely, for the other chemical engineers working in the business parts of the plant organisations.
So although I was part of a central organisation, I spent a lot of time close to the plants.
And that influenced how I looked at the role of DMC.
Some of my colleagues felt that I was too lenient towards the plants.
I understood why.
We had assembled a considerable amount of expertise in DMC. We had standard work processes, standard tools and a sophisticated system for allocating resources. From that perspective, it was quite natural to believe that we knew how things should be done.
But being close to the plants taught me something else.
A plant might do something differently from the central standard for a perfectly good reason. The people working there possessed knowledge that could not always be captured in a process document or a planning system.
I increasingly saw the question not as:
Who knows best — the centre or the plant?
but rather:
How do we combine the expertise of both?
I was not against standards. I was becoming sceptical about the idea that the standard itself was necessarily the best description of reality.
When following the process became the problem
The financial crisis provided a particularly good illustration.
In 2009, the credit crunch put considerable pressure on DSM’s finances and immediate cost savings were required. My boss was asked to establish a team to identify savings opportunities, and I was asked to join it.
Among the initiatives we examined was the effectiveness and efficiency of the maintenance process.
What we found was revealing.
The maintenance organisation was following the prescribed process very carefully.
And yet the process generated a lot of problems.
There were unnecessary delays and discussions built into the way work moved through the organisation. People were doing what the process told them to do, but that did not necessarily make the maintenance operation efficient.
During this period I helped develop what we called the “short route”.
The idea was not to abandon the process. Rather, we identified situations in which some of the prescribed steps added little value and could therefore be shortened under defined conditions.
But the exercise also revealed a different problem.
Many of the plants were old. When equipment failed, an identical replacement was often no longer available.
The alternative was a functionally equivalent, but non-identical replacement.
That immediately raised questions. Was it really equivalent? Did the specifications still meet the requirements? What about engineering, safety, documentation and approval?
The existing process generated plenty of questions and discussions around such cases, but there was no properly organised route for dealing with them.
As a result, non-identical replacements could become uncontrolled exceptions.
So while we were shortening the process where it contained unnecessary slack, we also filled a gap by establishing a way of dealing with non-identical replacements.
This taught me an important lesson:
A good work process is not simply one that people can follow. It has to deal with the situations people actually encounter.
If reality repeatedly falls outside the assumptions built into the process, telling people to follow the process more strictly is not necessarily the answer.
Sometimes the process itself needs to change.
When the standard tool meets a different plant
I encountered a similar issue with Asset Utilization.
One of the plants I supported was a relatively small Engineering Plastics plant. It sometimes produced a deviating product in campaigns, making its operation quite different from the larger, more repetitive plants.
The Asset Utilization application was not particularly strong in handling batch production. During these special campaigns, considerable workarounds were required to make the system represent what was actually happening.
Again, the issue was not whether the plant should use the standard application.
The question was how much effort should be spent making a standard designed around one operating model fit another.
It was another small reminder that standardisation and reality are not always the same thing.
Team targets
Another experiment from this period concerned team targets.
For some groups of employees, people in the lower grades did not receive individual targets. Instead, teams could subscribe to a target which was connected to their bonus.
The important part was not simply the target.
The teams were coached in setting their own goals and determining how they could achieve them.
Instead of:
This is the number you personally have to deliver.
the message became more like:
What do you think your team can achieve, and what are you going to do to get there?
The target created accountability, but the team retained ownership of how to achieve it.
For me, this was another practical example of empowerment through structure.
Empowerment did not mean removing accountability. It meant creating an environment in which people could accept responsibility and work out how to achieve the result.
A central organisation, but not a central answer
Looking back, I think my difficulty with DMC was therefore not really about centralisation itself.
The organisation had been created for good reasons. Pooling expertise, centralising activities where this made sense, establishing common processes and sharing resources could all create real value.
The problem arose when the success of that model encouraged the belief that the model itself was the answer.
The standard work process became the way work should be done.
The standard tool became the way information should be collected.
The resource-planning system became the way resources should be allocated.
And deviations could easily start to look like weaknesses in the plants rather than information about where the central model needed to adapt.
My experience was pushing me in the opposite direction.
I increasingly believed that the centre should provide expertise, structure and standards, but that the plants needed room to apply them to their own reality.
That was probably one of the reasons I welcomed the opportunity to move back into the business.
Back to Engineering Plastics
When an opportunity arose to return to DSM Engineering Plastics, I took it.
In a way, I was moving back towards the environment where I felt I could contribute most effectively: closer to the business, closer to the plants and closer to the people who actually had to make the processes work.
That move, around 2011, brought me to Emmen.
And the question of standardisation followed me there.
But now it appeared in a different form.
Could a standard information system really serve different plants and different ways of operating?
And where should the standard end and local adaptation begin?
Those questions became very concrete when we implemented Asset Utilization in Emmen.
There I would learn that even something as apparently simple as the meaning of a loss category could not simply be prescribed from the centre.
And that experience would eventually lead to a much bigger story about MES, standardisation and the tension between a corporate platform and the reality of the business.