Around 2011, after my period working with team targets and performance management in Geleen, I moved to DSM Engineering Plastics.
The site in Emmen was the largest and most important site in the business. It had a number of extrusion lines and large tumble dryers, where post-condensation of nylon compounds took place.
My original assignment was to develop a track-and-trace application for raw materials.
But by the time I arrived, the immediate priority had changed. The site needed either a substantial cost reduction or an increase in capacity — both were considered valid outcomes.
I therefore became part of a team supporting the site, with McKinsey also involved.
First improve, then sustain
The largest improvements came from what we called S5.
There was a lot of manual work, with various tools and an established way of working that contained considerable inefficiencies. By analysing the actual activities and changing the way the work was organised, the team was able to achieve significant improvements.
The Asset Utilization work process played a different role.
Asset Utilization was essentially our DSM version of OEE. We measured performance and registered the causes of losses.
But the site did not initially see it as the tool that would produce the improvement.
The improvement team was already working directly on the major performance problems.
Instead, Asset Utilization was seen as a way to sustain the improvement after the team had left.
That made sense to me.
A project team can identify problems and change the way work is done. But eventually the project team disappears. The organisation then needs a way of knowing whether the improvement is still there.
So I needed to establish the current performance, identify the major performance killers and make the information available centrally. The intention was to publish the data through SAP BW.
The logic was simple:
First improve the process.
Then make the improvement visible.
Then continue measuring it so that the organisation can see when the improvement starts to disappear.
But there was another problem.
Before we could sensibly use the data, we needed to agree on what the data actually meant.
What does a loss actually mean?
Before implementing the Asset Utilization functionality in the two Emmen factories, I gave a refresher training on the work process.
The site was already familiar with Asset Utilization, but I thought that a refresher could do no harm.
Part of the training concerned the assignment of a specific loss category to an actual event.
DSM had a standard catalogue of loss categories. That was important because a common catalogue made it possible to compare information between plants.
For the workshop I had prepared five scenarios.
I deliberately made them quite detailed.
They did not simply describe a machine stopping. A scenario might describe a disturbance that was already underway, followed by a particular action that the operator had forgotten to take, which then caused another loss.
I asked the participants to assign a standard DSM loss category to each scenario.
The group consisted of several operators, a shift leader, the Improve engineer, the Maintenance engineer and the Plant Manager.
The result was surprisingly lively.
Different people assigned different categories to the same event.
The discussion then moved to the meaning of the individual terms in the standard catalogue. What exactly did a particular category mean? Where was the boundary between two apparently similar categories?
This was more than an exercise in getting the right answer.
It showed me that a standard vocabulary is only useful if the people using it attach the same meaning to the words.
And that led me to propose something that might initially sound contradictory to standardisation.
The site should be allowed to have a site-specific loss-category catalogue, provided that every local category could be translated into the DSM standard categories.
The system would contain a translation table.
The responsibility for creating that mapping would be with the local team.
My argument was simple:
These terms are used for mutual communication. It is important that everybody understands the same thing when we use them.
The corporate catalogue remained useful for comparison and reporting.
But the local organisation had to make sure that the terminology actually worked for the people who used it every day.
This became a principle I would encounter repeatedly afterwards:
standardisation does not necessarily mean that everything underneath the standard has to be identical.
Not everything is an equipment failure
There was another aspect of the Asset Utilization approach that was important to me.
A loss did not necessarily have to be attributed to a piece of equipment.
We wanted to understand what had actually caused the loss.
That could be an equipment failure. But it could also be something that happened in the operation: an action that was not taken, an operating mistake, or another way in which the work process had failed.
The purpose was not to blame someone.
I had learned this already from working with performance data in the control room: an operator should not be held responsible for something he or she cannot influence. But if an operator’s response can influence the outcome, making that visible can be useful.
That distinction was important.
The data was intended to help the organisation learn and improve, not simply to identify somebody or something to blame.
This would later become an interesting contrast with Covestro’s Production Loss Accounting, where the concept of a “bad actor” was much more prominent — and where a bad actor was an object, such as a piece of equipment.
At the time, however, I was still working within DSM.
And another development was about to make the question of standardisation much bigger.
One work process, one application
Corporate Operations was reinforcing the DSM work processes and wanted each of them to have a standard application.
The idea was straightforward:
One work process, one standard application.
Asset Utilization was one of the first candidates.
Corporate Operations approached us — the Business Group COO and me — with an attractive proposition. The first three implementations would receive financial support from Corporate and consultancy support from KPMG.
After some initial hesitation, we decided to take the opportunity.
And suddenly we were implementing the first DSM standard application for Asset Utilization.
Corporate took the lead in the process. They selected the system and led the development of the requirements.
The other two candidates for the first three implementations never materialised.
So for quite some time I was effectively the only person involved who had a direct stake in getting the system right for my own business.
Corporate had a stake in creating a standard.
I had to live with the result.
And there was an important difference in how we looked at the system.
Corporate defined the scope as Asset Utilization.
But the platform selected was an AVEVA/Wonderware MES platform.
I could already see much more potential in it, particularly for Operate Plant. This materialised when later all compounding related departments were combined into a single department with – yet again – a new centralized control room. The MES system was extended with a number of Operate Plant Normal functionalities that made this consolidation possible.
Corporate did not see it that way. From their perspective, this was an Asset Utilization application. The fact that the underlying platform was an MES was not the purpose of the project.
For me, that distinction was becoming increasingly artificial.
If we were establishing an MES platform in our plants, why would we regard its use for other work processes as something completely separate?
There were many discussions.
And this was my first real experience of a problem that would return later in my career:
what exactly are we standardising?
A particular application?
A work process?
A technical platform?
Or the way people actually work?
The template grows
The first implementation was followed by a second installation at our Evansville site in the United States.
The third candidate still did not materialise, so later we implemented another installation ourselves in Genk, Belgium.
By then, what had started as an Asset Utilization application was becoming a reusable template.
But a template immediately raises another question:
How much of it should remain the same when the operation changes?
That question became particularly relevant when I later moved to DSM Resins.
The Resins operations were quite different from the extrusion lines and post-condensation tumble dryers of Engineering Plastics. The template could therefore not simply be copied. It had to be significantly modified.
That experience reinforced something I had already learned in the Emmen workshop.
Standardisation was valuable, but it had to leave room for the reality of the operation.
And that, in the end, was perhaps the most important lesson I took from Emmen.
The system was not valuable because it was a DSM standard.
It was valuable because it helped people understand what was happening in their operation — and because the organisation could use that information to sustain improvements and improve again.
The technology was becoming more important.
But the question of who the technology was ultimately serving remained the more important one.