Tag: Covestro

By now I had experienced Covestro as a rather formal organisation. There were structures, responsibilities, standards and rules, and sometimes I found these constraining.

But that was not the whole story.

I gradually discovered that, if you stayed somewhat under the radar and found the right companions, quite a lot could still be done.

The Covestro Analytics Platform was a good example.

When I first became involved, the platform was still something of a pioneering activity. A first version of a serverless data lake framework (SDLF) had been set up, and not everything had yet been cast in stone.

I liked that.

There was a willingness to try something, learn from it and then build a better version, rather than pretending that the first design had to be the final one.

I built some of my applications on that first version. Later, when the second version of the platform, the broader Datazone, emerged, I was invited to migrate these applications to it.

I was not involved in designing the second version itself, but I received good support from the platform team during the migration. In the process, we also developed functionality for ingesting data from Layer-3 MES systems into the platform.

I could therefore contribute some of the experience I had gained from working with the first version. The Layer-3 ingestion functionality could become a reusable building block rather than something that had to be solved separately for every MES application.

This was exactly the kind of collaboration I enjoyed.

The platform team brought the cloud and data expertise. I brought the MES and plant perspective. And there was another IT colleague who was particularly valuable because he could bridge the gap between OT and the AWS environment.

None of us had to know the complete answer beforehand.

We could work it out together.

That was quite different from some of the more formal processes I had encountered elsewhere in Covestro. There was room to experiment, learn and adjust.

A different story: Santa Margarida

The MES implementation at Santa Margarida was a completely different story.

It originated from an idea that had already existed at DSM and followed from the earlier migration work. Turning that idea into reality was a fairly tedious project. Halfway through, we had to redo the architecture in AWS, which made an already complicated project considerably more cumbersome.

But eventually we got there.

Santa Margarida went live in 2023.

At the time, I did not think particularly much about whether this achievement was visible to the wider organisation. We had a project to do, we found people who could help us, solved the problems that arose and got it running.

Then, in 2025, I encountered an amusing consequence of having worked rather under the radar.

In the context of a Covestro award, the gMES programme was presented as the first cloud implementation of an MES in Covestro.

That was not quite how I remembered it.

Santa Margarida had already been running in the cloud for two years.

I did not make much of it. In a way, it was almost the logical consequence of how I had worked. If you operate quietly with a small group of people, solve problems together and do not need the wider organisation to validate what you are doing, there is a small downside as well:

sometimes nobody outside that circle knows what has actually been achieved.

But perhaps that was a price I was quite willing to pay.

Because there was also an upside.

I had discovered that the formal organisation did not tell the whole story. Within it were people who were curious, technically capable and willing to cross boundaries. With the right companions, there was room to experiment and to build things that had not yet been prescribed.

And that became one of the more positive things I took from my time at Covestro.

Amazing things can happen when you find the right companions.

Even if, occasionally, the organisation finds out about them only later.

Looking back,

I also realise how much of what I was able to do at Covestro had been shaped by my years at DSM.

DSM had given me the opportunity to develop not only as a professional, but also as a person. Working with colleagues, managing people at times, dealing with different personalities and trying to understand what motivates or frustrates people had made me increasingly aware of the psychology of organisations and of the people within them.

Professionally, DSM had given me an unusually broad playground. I had been able to move between technology, operations, projects, IT, data and organisational questions. I had not followed one narrow professional path; I had gradually accumulated different ways of looking at a problem.

Covestro continued that development, but in different directions. The migration and the work that followed gave me the opportunity to develop further in areas that had been much less familiar to me before — particularly cloud computing and, later, AI.

So although I sometimes found the Covestro organisation difficult to navigate, I cannot separate that experience from the things I learned there. I added new professional capabilities to a foundation that had largely been built at DSM.

Perhaps that is also why finding the right companions mattered so much. By then I had learned enough to recognise when someone had a different piece of the puzzle — and enough confidence to work with them without needing to know everything myself.

We are One — but I did not forget where I came from

There was also a repeated message from management, including from people who had themselves come from DSM: “We are Covestro now.” The intention was understandable. The integration had to become a success, and at some point people had to stop thinking in terms of “us” and “them”.

I nevertheless found it difficult when this seemed to imply that we should simply forget DSM.

I could not do that.

DSM was not just the company I happened to work for before the integration. It had been my formation period, professionally and personally. It had given me opportunities to develop in many different directions, to work with people, to manage people, to learn about organisations and their psychology, and to develop as a professional. Much of the way I looked at problems had been formed there.

You cannot simply switch that off because the name on the building changes.

Over time I came to see this less as a question of choosing between DSM and Covestro and more as a question of having more than one identity.

I sometimes think of people of Italian descent who have lived in the Netherlands for several generations. They may be completely Dutch, while still speaking Italian at home, knowing where their family came from or even putting an Italian tricolore on their car.

There is nothing contradictory about that.

You do not have to abandon one identity in order to acquire another.

Perhaps the same applies to organisations.

I could become part of Covestro without pretending that DSM had never existed. I could carry the things DSM had taught me into Covestro, learn new things there and gradually add them to what I already knew.

In fact, that is exactly what happened.

DSM had given me a broad professional foundation. Covestro added new experiences, particularly in areas such as cloud computing and AI.

So perhaps “We are One” does not have to mean that everybody has the same history.

It can also mean that people with different histories become part of the same organisation — without having to erase where they came from.

Gradually when time passed, I stopped focussing on Covestro as a whole.

That did not mean that I stopped working hard or that I stopped caring about the people around me. Quite the opposite. I had my own area of responsibility, my own systems and, importantly, my own users. They were largely the people in the plants with whom I had already worked for many years.

I knew what information they needed, how they used it and what was useful to them.

So I decided, in effect, to focus on my own shop.

Part of that work was the reporting of OEE data coming from the systems I was responsible for. The reporting had originally been developed at DSM and, after the migration, was rebuilt on Covestro’s analytical platform.

This work could take place relatively unnoticed by the wider Covestro organisation. My customers were largely the plants that had previously been part of DSM. They already knew the data and were familiar with the way we used it. I could therefore concentrate on making the reporting useful in the new technical environment rather than having to redefine its purpose.

We automated much of the monthly reporting process and also built a data foundation for setting performance targets.

I also had to decide how much to standardise.

I chose to build standard Python scripts that could be parametrised for individual sites. The basic transformation architecture was common, but specific functionality could be added where a particular site needed it.

I could have made everything identical. Instead, I tried to find a middle ground:

Standardise what benefits from standardisation, but leave room for genuine differences.

When I later became involved in version 2.0, the technical environment had changed. The data was now coming from an emerging new standard tool, so parts of the solution had to be rebuilt.

But I kept the architectural principle.

The common functionality remained standardised, while the architecture allowed site-specific additions where they made sense.

In that way, I could carry some of the ideas I had developed earlier into the new environment without making a particular point of doing so.

I was no longer trying to change the organisation.

I was simply trying to build something that worked.

Another way of contributing

There was another way in which I moved on.

I became a union officer within Synergo, taking on organisational responsibilities, and became involved in the CLA negotiations. I organised union leaders’ tours around the Dutch Covestro sites.

Although I was a member of Synergo, a union serving higher professionals, I cared about cooperation between the different unions. I tried to facilitate a common line towards management rather than having the unions approach the negotiations as competitors.

Before the negotiations, I also helped organise surveys among employees, so that the combined union effort could start from as good an understanding as possible of what people actually wanted.

Sitting in the CLA negotiations, I learned another thing that I had not expected: quite a lot about negotiation itself.

The relationship between management and employees felt different there. Neither side could simply decide for the other. To reach an agreement, you needed each other.

I found that surprisingly instructive. The formal hierarchy that existed in the company was still there, of course, but at the negotiation table it was balanced by mutual dependence. Management needed an agreement; the unions needed an agreement. Both had something to bring to the table, and neither could simply dictate the outcome.

I also think that my increasingly limited emotional attachment to Covestro helped me in that role. I could represent the interests of employees and work towards a good agreement without feeling that I had to defend Covestro as a company.

I found the experience valuable enough that I would recommend it to colleagues. Even if you never intend to become a union officer, sitting through serious CLA negotiations gives you a quite different perspective on how an organisation works — and on negotiation itself.

I did this during the negotiation cycles of 2022, 2023, 2024 and 2025.

This was another way of having an influence that felt natural to me. I had a clear role, a constituency I was representing and colleagues from different unions with whom I could work.

I also became a member of the Works Council in Geleen, the site that was my formal work location.

I did not have direct colleagues there with whom I worked on a daily basis. And the site itself had changed considerably. The sale of one business and the closure of two others had greatly reduced the number of people remaining.

The Works Council nevertheless gave me a connection with the site and with the colleagues who were still there.

So my engagement with Covestro did not disappear. It changed its form.

Watching from the outside

Even when I was no longer trying to influence the direction of Covestro itself, I continued to follow what happened.

The transition of Covestro to ADNOC was another example. I followed the developments and was interested in what would happen to the company and its people. But I noticed something in myself: I followed it without feeling personally engaged in the outcome.

That was perhaps the clearest sign that something had changed. I was still working at Covestro, still doing my work and still engaged with the people around me. But my relationship with the company itself had become different.

I had moved on — while still being there.

Perhaps that is what “moving on” ultimately meant for me.

I had not stopped caring about doing good work. I had not stopped caring about colleagues. I had not even stopped being interested in Covestro.

But I had stopped carrying Covestro as a company.

My engagement had become more local and more concrete: my systems, my users, the plants, my colleagues, the unions, the Works Council, and the things where I could actually contribute.

And now even that phase is coming to an end.

After the 2025 negotiations, my successor will have to step into the organisational work I had taken on within Synergo. My professional work will also eventually be handed over.

Looking back, I think I moved on not by becoming indifferent, but by putting my engagement where I could make a difference.

My first substantial involvement with Covestro came immediately after the transition. I was naturally involved in the IT migration, particularly because I had systems that originated in DSM and had to continue operating in the new environment.

There was also a personal route into the new organisation.

One of the first people I got to know in Covestro was the leader of the Advanced Process Control department in Technology. She was managing an AspenTech APC implementation, so our work had a natural point of contact from the beginning. Through that work, I came into contact with her quite early in the integration.

I also discussed my hesitation about moving to Engineering with her. Process Automation, including DCS and MES, was part of Engineering in the Covestro organisation, and that seemed the obvious place for my background. But I did not really want to move there. She understood my hesitation and introduced me to the manager of a department in Technology where I eventually found my place.

That introduction turned out to be important for the rest of my time at Covestro. He became my manager and supported me throughout the years that followed.

My position was therefore somewhat unusual. I was in Technology, working with historian functionality and applications built on top of it, while at the same time remaining involved in the gMES team led by Engineering. And because of my existing MES systems, I was involved from the beginning in the practical consequences of the IT integration.

This was not simply a matter of moving servers from one place to another. The systems depended on network configurations, firewall rules, access arrangements and connections to other systems.

Some of these things were different between the former DSM sites and Covestro.

Third-party access to the MES environments was one example. The way we had previously arranged access did not fit the Covestro approach, so a new Third Party Access mechanism had to be established.

The local firewall configurations provided another example. The former DSM sites had their own configurations and rules, some of which were important for my systems. They did not simply match the Covestro standard.

Changing all of this as part of a fast integration was not realistic. The integration therefore had to distinguish between what could be changed immediately and what could not. In some cases, new acceptable standards had to be developed that allowed the systems to operate during the transition without making the integration unnecessarily slow.

I found this quite interesting because it was one of my first experiences of what a large-scale integration meant in practice. The organisational decision to integrate the companies was one thing. Making hundreds of technical dependencies fit together was another.

The first migration reminded me of an experience I had had in Scotland.

My impression was that the first migration had not been sufficiently prepared. The migration itself did not go particularly well either. We had to repair quite a few things afterwards, and some of those repairs caused significant outages.

Where in Scotland, I had to learn to trust “we’re getting there”, here I learned to trust that it would become OK after all.

The Covestro project team reacted very quickly. Problems were investigated, solutions were found and, where the original approach proved inadequate, the team was willing to change it. They were also remarkably flexible in helping to solve problems that were not necessarily part of the neat original project definition.

There was another difference with the IT environment I had known towards the end of my DSM years. Covestro still had a substantial number of its own IT people who could actually do things themselves. They could investigate a technical problem, change a configuration or make an adjustment without every action first becoming a ticket for an external service provider.

This made a surprisingly large difference.

When something went wrong, it was often possible to bring the right people together in a Teams meeting and work through the problem directly. Sometimes somebody who had not originally been part of the project or meeting turned out to have exactly the knowledge we needed. It was usually possible simply to bring that person into the discussion.

There was therefore a certain informality in the way problems could be solved. We could move from “something doesn’t work” to “let’s find the person who knows why” and then actually do something about it.

This contrasted with the IT environment I had experienced towards the end of my DSM years, where an increasing number of services had been outsourced. There, a relatively simple technical problem could involve several organisations: a request had to be formulated, routed to the appropriate external party, perhaps subjected to a security review, approved and then implemented by yet another party. DSM IT remained responsible for coordinating the process, but the people coordinating it did not necessarily have the technical ability to solve the underlying problem themselves.

In Covestro, at least during this early integration period, I experienced something different: the organisation still contained enough technical capability to act.

That made the learning cycle short. If we discovered during one migration that something had not been considered properly, the people who encountered the problem could often work directly with the people who could change the solution. The next migration could therefore be different from the previous one.

And it was.

The subsequent site integrations went progressively better. Preparations improved, the actual transitions became smoother and a way of dealing with exceptions emerged. In some cases we discovered that server hardware itself would have to be replaced rather than simply migrated. By then, however, an effective process for handling such situations had developed.

Looking back, this was one of my first experiences of something that I would encounter repeatedly during my Covestro years:

an organisation can learn very quickly when it is willing and able to learn from the first implementation.

The first migration had been imperfect. But it became the basis for a better process for the next one.

I also had an individual IT contact who became, in effect, my IT companion for as long as I remained at Covestro. He helped me whenever he could, but what I particularly appreciated was that he did not wait until something had already broken.

When IT was planning an infrastructure change that might affect my systems, he would involve me proactively. When servers or operating systems had to be migrated, he was there. When functionality was added or the environment changed in ways that could affect the applications, he helped me understand what was happening and find a way through it.

That relationship became particularly valuable as the technical environment evolved beyond the initial integration.

The eventual cloud-based MES implementation in Santa Margarida was one of the more complex examples. By then, the lessons from the earlier migrations and the relationships between the different parts of IT and the business had accumulated. The work was no longer simply about moving something from the old DSM environment into Covestro. It involved building something new while dealing with the dependencies of an existing manufacturing environment.

I found the contrast with the first migration instructive.

The first experience had shown me the friction created when two technical environments, each with their own history and standards, suddenly had to become one. The subsequent integrations showed something else: the integration itself could become a learning process.

And perhaps that was my first real introduction to Covestro as an organisation.

It was not yet the Covestro of standards, governance and organisational boundaries that I would encounter later. It was an organisation trying to make a very large and complicated integration work — sometimes imperfectly, but with people who were prepared to adapt when reality did not match the plan.

That experience would remain an important reference point for me when, later, I encountered situations in which the ability to adapt became more difficult.

What does an operatorless plant mean?

Not long after I started at Covestro, I was invited to participate in an activity looking at the future of manufacturing automation.

I was familiar with batch manufacturing and had worked extensively with automation, although within Technology, batch automation itself had not been a major focus. So I came to the discussions with some relevant experience, but also with an open mind about what Covestro saw as the future.

The ambition quickly became clear: the operatorless plant.

Much of the discussion was about advanced automation, advanced process control and related technologies. I found that interesting, but I also started asking some questions.

If we were going to automate so extensively, why stop with the production operator?

Could we not also automate plant-support activities? Engineering? Perhaps even parts of process control itself?

Those questions did not seem to generate quite the same enthusiasm.

But there was another point I felt was missing.

From my experience, automation did not necessarily mean simply eliminating jobs. It changed what people did.

Work that had to be done during shifts could sometimes be moved to daytime activities. That could reduce the burden of night shifts and physical strain on operators. Repetitive work could disappear, leaving operators with work that was more interesting and intellectually challenging.

So I made a slide for the final presentation that expressed this human side of automation.

The presentation was being prepared for very senior management and the German Works Council. The material was professionally edited by an external agency. When the person from the agency saw my slide, he was actually pleased with it. After many slides about technology and the future of automation, he said, in effect, that it finally brought some human interest into the story.

I received drafts and commented on them, but I was not involved in the final editing. Eventually the presentation was released.

At some point I went through the final version.

My slide was gone.

Nobody had told me that it had been removed. There had been no discussion about it. It had simply disappeared somewhere between the draft and the final presentation.

Later I was asked to communicate the presentation in my own environment.

I did so.

But I added my slide back into the deck.

And when I presented it, I made sure to talk about it.

I don’t remember being particularly angry about the missing slide. What stayed with me was something subtler.

I had come into an organisation where there was clearly a lot of ambition and technical expertise. But when I tried to broaden the question from “How far can we automate the plant?” to “What could automation do for the people who work in the plant?”, I did not feel the same enthusiasm.

Perhaps that was simply because the exercise had a different purpose.

But it was also one of my early experiences of discovering that the questions I naturally asked were not necessarily the questions everybody else was interested in answering.

The idea of silos was not new to me when I joined Covestro.

When the DSM business units were formed in 1992, several central services were dismantled or heavily decentralised. Maintenance was one example. People who had previously belonged to the same functional organisation became formally colleagues in different business units.

For the plants it meant that people from different central departmens became colleagues in the same organisation.

That did not mean that cooperation emerged automatically. We had to learn how to work across the new boundaries. “Destroy the silos” became one of the familiar expressions for this.

People like me, with a more academic background and increasingly involved in managerial and coordinating work, were often asked to help make that happen. I experienced this, for example, in my work with the Applied Research department after it had been decentralised. Working from the plant, I inevitably interfered with their priorities. But there was something in it for both sides. When a research idea fitted an actual business or plant priority, the probability that it would eventually be implemented was much higher. Connecting research with the business therefore gave their ideas a better route to application.

In hindsight, I think this taught me something important: formal organisational boundaries do not determine where the work itself takes place.

Finding myself between the silos

This became relevant again after the transition to Covestro.

I was initially expected to move into Engineering because Process Automation was responsible there for DCS and MES. I did not want to make that move and eventually found a place in Technology, where I could work with historian functionality and the applications being built on top of it.

At first, that seemed like an ordinary organisational decision. But it made me increasingly conscious of the difference between where expertise is organised and where a problem actually belongs.

A control-room project was a good example.

It might look like a technical project: automation has to be redesigned, a DCS replaced, local panels removed, new equipment installed. But that is only part of the job.

The plant may also have to reorganise its operation. Roles have to be described. The Works Council may need to be consulted. People have to be informed and selected. People whose positions disappear need to be treated carefully and helped through the transition. Communication has to be organised. At the same time, the technical work has to progress: automation, civil construction, room design, workplaces and equipment all have to come together.

The plant therefore has one integrated change, while the expertise needed to deliver it sits in several different places.

I experienced myself as one of the pivots in this process, together with local management and HR. I did not have authority over all these areas, nor did I need to. My role was to understand enough of the different perspectives to see the dependencies and help make the pieces fit together.

That made me realise that there is nothing inherently wrong with organising expertise in separate departments. Engineering should have engineering expertise; Technology should have technology expertise; HR should have HR expertise.

But then there needs to be a strong cross-silo capability that can bring those disciplines together around a particular result.

For a major plant project, this might even mean temporarily making the plant organisation the overriding structure: bringing the relevant specialists together around the project, rather than expecting each function to optimise its own contribution and somehow having the integrated result emerge afterwards.

I felt that this cross-silo mechanism was not sufficiently present.

A different organisational memory

My DSM experience gave me an interesting comparison.

The strong decentralisation of DSM had certainly had disadvantages. Some central expertise disappeared. Knowledge networks replaced parts of the former central functions, but those networks had less authority to impose standards and often had little budget for centrally developed applications.

So decentralisation was not automatically better.

But we had also learned to work around those disadvantages. Because people were closer to the business and the plants, cross-functional cooperation became part of getting things done. Expertise could be brought in through networks and personal relationships.

In other words, we had lost some centralisation and standardisation, but we had also developed ways of working across the remaining boundaries.

That became an important reference point for me at Covestro.

Deductive and inductive thinking

There was another aspect that I came to think about, although I recognise that this is a subjective interpretation.

One of my German managers once remarked that he saw Germans as tending more towards deductive thinking, whereas Dutch people were more comfortable combining deductive and inductive thinking.

I found that interesting because it corresponded, at least partly, with how I had experienced my own work.

Many of the plant projects I had worked on developed quite inductively.

Take the control-room example. The work might start with a concrete automation problem: a new DCS is required, local panels are becoming obsolete, or another part of the automation infrastructure needs to be replaced.

Then comes the question:

If we are changing all this anyway, what should we do with the control room?

That question leads to others. What should the future operating model be? What should remain local? What should be centralised? What does this mean for roles, workplaces and the organisation?

Gradually, the larger concept emerges from connecting the individual observations.

That is an inductive process.

A silo organisation, by contrast, naturally lends itself more to a deductive way of working. Engineering defines the engineering problem; Technology defines the technology problem; HR addresses the people side; the plant addresses operations. Each can develop a very good answer within its own domain.

But some solutions emerge only when somebody is able to connect things that were not originally defined as belonging together.

This is not a statement that people in silos cannot think inductively. It is rather that the organisation gives them fewer opportunities and fewer incentives to do so.

And this is why I increasingly saw the cross-silo role as more than coordination. Someone needs to create the space in which the different disciplines can discover what their problems have in common.

Today, I would also be more cautious about the particular solution that emerged from those control-room projects. Mobile technology, remote operation and AI may make entirely different operating models possible. Perhaps the next generation will find ways of combining local presence, remote support and intelligent assistance that we could not have imagined.

That does not change the point of the example.

The particular solution may change. The need to connect technology, operations, organisation, people and business purpose does not.

And then came gMES

This was the background against which I experienced gMES.

I was part of the gMES team from Technology, while Engineering led the initiative. The ambition was to develop a standardised MES template that could be rolled out quickly across plants.

I understood the attraction. Standardisation could make implementation repeatable, and a lean template could make fast rollout possible.

But two moments made me increasingly uneasy.

The first concerned the balance between speed and plant value.

During the initial gap analysis at the first implementation plant, I saw several specific functionalities that addressed concrete issues the plant was already working on and for which MES could provide a useful solution.

Later, when the implementation speed became an explicit objective, I asked what had priority: making the implementation as useful as possible for each plant, or achieving the desired rollout tempo.

The answer from the Business was clear: tempo.

I found that revealing. The speed of deploying the template had become an objective in its own right.

The second issue was the role of the plant.

The plants had very limited capacity for this kind of work. Their organisations were lean and concentrated on running the operation. I argued that the plant nevertheless needed to be proactively involved, because what the MES should do and how it would create value depended on the purpose it served in that particular operation.

Instead, the plant was largely waiting.

The attitude was understandable:

I don’t know what’s coming. Let’s wait until it is finished and then see what it is.

But to me that was precisely the problem.

By the time the plant could see what had been built, many of the choices determining whether it would be useful had already been made.

I could see Engineering trying to do a good job within its responsibility: develop a good, standardised template and make it possible to roll it out efficiently.

I could also understand the plant: it had little capacity to engage in something whose outcome it could not yet see.

Neither side seemed unreasonable to me.

What was missing, in my eyes, was the cross-silo mechanism that would have made the plant’s purpose the organising principle of the project.

I could see the problem developing, but I did not have the authority to change the way the project was organised.

That was the point at which accountability without authority became very concrete for me.

It was not that somebody had formally made me accountable for the entire gMES outcome. It was that I felt sufficiently responsible for the outcome to see the problem coming — while the decisions that could change the conditions belonged elsewhere.

What the experience taught me

Looking back, I would not conclude that functional departments are the problem. Nor would I conclude that DSM’s decentralised model was inherently superior.

Both approaches have trade-offs.

What I came to value was the ability to temporarily organise around the problem rather than around the permanent organisational structure.

A plant does not experience an Engineering problem, a Technology problem, an HR problem and a management problem separately. It experiences one problem.

The organisation may need specialised functions to solve the pieces. But somebody still has to connect the pieces back into the one problem the plant is trying to solve.

That was increasingly the role in which I recognised myself.

And perhaps that explains why I felt uncomfortable when I was being placed inside one of the silos. I did not primarily see my contribution as belonging to Engineering or Technology. I saw it in the space between them — connecting the what the plant wanted to achieve with the how the different specialists could make it possible.

That space has no obvious place on an organisation chart.

Yet, in my experience, a surprising amount of the success or failure of large projects happens precisely there.

In 2019 I moved to DSM Resins.

By then the MES experience had travelled further. Within Engineering Plastics there had been the implementations in Emmen, Evansville and Genk, while Wilmington had shown that the same technological basis could be adapted to another business.

In Resins, the roll-out continued.

The next implementation came in Hoek van Holland, followed by preparation for two simultaneous implementations in Spain, at Parets and Santa Margarida.

But the context in Resins was broader than simply rolling out another application.

The director of DSM Resins wanted to push a digitalisation agenda across the whole business.

This included not only Manufacturing, but also functions such as Supply Chain, Marketing, Pricing, R&D and Patents.

The DSM IT Business Partner, who worked for the DSM IT organisation but was also a member of the DSM Resins Management Team, organised this effort.

The Resins COO did not attend these discussions for Manufacturing. He left that part of the agenda to me.

That meant I had to formulate a longer-term digitalisation agenda for Manufacturing.

The starting point was Asset Utilization. It was already proven, although the implementation was not yet completely finished.

From there, I saw a natural progression towards further Manufacturing functionality:

Asset Utilization → Track & Trace → Operate Plant → data integration → data-driven business steering.

The important change was that the MES was no longer just an application for one work process.

It was becoming a potential digital platform for Manufacturing.

A little pioneering spirit

There was also a more informal side to the way I experienced innovation at DSM.

The director of DSM Resins had her office in the World Trade Center in Amsterdam Zuid. I came there regularly, and I remember the atmosphere as quite different from the more traditional corporate environment I had known. There was a pioneering spirit: people were trying things, new ideas were emerging and not everything seemed to have to be fully designed before you could start.

One of the projects I encountered was a pricing application developed by a team working in what had been the IBM building in Amsterdam. It was a rather fancy, almost hip environment, and the way people worked seemed to fit the surroundings: there was experimentation, some improvisation and a willingness to find out what worked.

I found that energising.

In early 2020, the Resins director had taken responsibility for all the Materials Science activities in DSM, and an alignment of the automation initiatives across these businesses was organised.

I knew Engineering Plastics — which later became Envalior — quite well, because I had been involved in building parts of its automation and performance-management environment myself. But now there were businesses I knew much less well, such as Dyneema — later Avient.

I had to present our approach to Manufacturing Performance Management to this broader group.

Instead of giving a conventional presentation, I decided to turn it into a quiz.

I prepared simple questions with three possible answers: two were complete nonsense and one was the right answer. We went through the questions together, and after each one I could explain why the correct answer was what it was and what it meant for the way we worked.

It was not exactly a sophisticated training technique.

But it worked.

People participated, there was some laughter, and the explanations became part of a conversation rather than a presentation being delivered to an audience.

I remember that session because it captured something I valued about that period at DSM: serious things did not always have to be done seriously.

There was room for experimentation not only in the technology, but also in how we worked with people.

---

When IT became part of the question

There was a reason why this increasingly became an IT as well as a Manufacturing issue.

The original Wonderware implementation had been financed by Corporate and developed with substantial involvement from DSM IT. The systems were part of the global DSM IT environment, including Active Directory, and were set up and maintained with IT involvement.

The AspenTech systems that I inherited in Resins had a similar IT orientation.

So although these were Manufacturing systems, they were not treated as a separate OT world.

I actually saw that as an advantage.

The future I envisaged was one in which manufacturing information would increasingly be integrated with the rest of the company’s information environment. A completely separate OT world would make that more difficult.

But this view was not universally shared.

There was a strong OT community within DSM that regarded its environment as something that needed to remain separate. I experienced that tension directly through my membership of the global DSM Process Control network.

At the same time, DSM IT was increasingly outsourcing infrastructure services.

Network management, including local firewalls, was handed over to external parties. This meant that OT operations increasingly became dependent on IT services.

That caused considerable discussion.

And the problem became larger as more and more IT functions were outsourced to different parties.

A seemingly simple firewall request could involve a security review by one external provider, approval by the site, implementation by another provider, with DSM IT coordinating the whole process.

The IT colleagues involved were often genuinely trying to help. But they increasingly found that their hands were tied by the organisational structure around them.

Different teams had their own resource planning and prioritisation, often using different Agile environments. Each could operate efficiently within its own boundaries, while the end-to-end process became increasingly difficult for the customer to navigate.

For Manufacturing, that distinction mattered.

The plant did not need a collection of well-managed services.

It needed one working solution.

---

The next step: cloud

Despite these frustrations, we continued with the Parets and Santa Margarida implementations.

The plan was to implement their MES environment in the AWS cloud.

For me, this was a logical next step.

I saw the future as an increasingly integrated IT/OT environment rather than two completely separate worlds. The cloud was part of that future.

But there was another important consequence of the way we had developed the systems at DSM.

Because the MES applications had been treated as IT systems, Covestro IT would later inherit responsibility for integrating them.

That would become significant.

The people who understood the applications and their manufacturing context were largely in Manufacturing.

The infrastructure and IT heritage pointed towards IT.

And the operational environment belonged to OT.

The boundaries did not line up neatly.

Then, while we were still working on the Parets and Santa Margarida plans, DSM became Covestro.

So I entered Covestro not with a blank sheet, but with a small ecosystem of legacy Manufacturing systems that had evolved over several years — Wonderware MES, AspenTech applications, Asset Utilization, and an emerging digitalisation architecture.

And with them came a set of assumptions about where MES belonged, how it should be developed, and how standardisation should work.

Those assumptions would soon be challenged.

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.

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.

The Roche Vitamins integration eventually brought me to Scotland.

By then, the central-control-room concept that had emerged from my Rotterdam experience had become part of the broader transformation of DSM Nutritional Products. At most sites, the local organisation implemented the new approach themselves.

Scotland was different.

There I became the implementation project manager, working together with the people responsible for the work-process implementation and with those reorganising the local organisation.

But the challenge in Scotland was not simply to install a new control room.

It was to change the way the plant was operated.

Changing the operating model

The Roche Vitamins operating model differed considerably from what I had experienced in DSM.

A chemist was responsible for the plant, while the operators and maintenance people were, in effect, his or her “hands”. The chemist would decide what needed to be done, and operators would execute it.

This also meant that chemists spent a considerable amount of time in the control room. Even during weekends, they could be called because an operational question might require their decision.

The DSM Operate Plant Normal work process was based on a different idea.

We knew how the plant should operate optimally. Operators did not necessarily need to have the detailed chemical background of a chemist to keep the plant in that state.

Their responsibility was to operate within defined operating windows and to respond appropriately when the process moved outside them.

For that, the work process used OCAPs — Out of Control Action Plans.

An OCAP made explicit what should happen when something moved outside its normal operating range: what the operator should check, what action should be taken and when the situation should be escalated.

This meant that knowledge which had previously resided largely with the chemist had to be translated into something that the operating organisation could use.

And that was an important part of preparing for the reorganisation.

The chemists increasingly moved towards Improve Plant and production-management responsibilities. At the same time, the shift leaders and operators were given more responsibility for what happened during their shifts.

The question was changing from:

What does the chemist want us to do?

to:

What happened during your shift, and how did you respond?

That was a substantial change in responsibility.

The new control room was therefore only the visible part of a much deeper organisational change.

Learning how to lead the change

I also had to learn how to work with the local organisation.

In the beginning, a local engineer supported me. I would give him an assignment and he would do it. He never seemed to object. At one point he even described me as a “tough taskmaster.”

At first I took that positively.

But then I started wondering why I wasn’t getting the kind of pushback I was accustomed to in Rotterdam.

There, colleagues would challenge me quite openly:

Why do you want this?

Wouldn’t it be better to do it differently?

I don’t think that will work.

I valued that. It forced me to explain my thinking and sometimes resulted in a better solution.

In Scotland, that kind of challenge did not come naturally.

I realised that this was potentially a problem.

If people simply did what I asked, I could easily mistake compliance for agreement.

And if we were trying to create an organisation in which operators and other employees were expected to take more responsibility, I could hardly expect them to become empowered simply because the organisation chart said so.

I needed to create room for people to question and challenge me.

That was one of my first personal lessons from Scotland: empowerment is not only something a manager gives; it also depends on people being willing and able to use it.

“We’re getting there”

Another small lesson came from the project action lists.

In Rotterdam, when I asked about an action, I would quite often get:

“Yes, finished.”

In Scotland, the answer was much more likely to be:

“Ah, we’re getting there.”

The first few times I heard it, I regarded this as a risk.

An action was either finished or it wasn’t. And “we’re getting there” didn’t tell me very much about what remained to be done.

Sometimes things did indeed become tight.

But gradually I discovered that the people saying it were genuinely committed to getting things done. They simply had a different relationship with the path towards the deadline.

And, most of the time, they did get there.

I had to learn not to confuse a different way of communicating progress with a lack of commitment.

It became an exercise in patience.

And, more importantly, in trust.

Staying close to the team

There was another small incident at the beginning of the project.

An open office had been reserved for the project team. It had one enclosed office, and when I arrived one day I was welcomed to “my new office.”

I was surprised.

I asked whether we could instead use the room as a conference room and have me sit in the open office with the rest of the project team.

The request seemed rather strange to them, but they accepted it.

I had learned from experienced project managers earlier in my career that staying connected with the team was an important condition for making a project work.

I wanted to hear the conversations, notice problems and be part of the team rather than create distance around my position.

It was a small decision, but for me it was part of the way I wanted to lead the project.

Managing the conflicts

There were, of course, strong differences of opinion.

The Plant Manager and I had some fierce debates about the content of the changes.

They were genuinely fierce, but they were not personal. We disagreed about how the organisation should be changed and how the project should be implemented, while continuing to work together.

There was an important person in the middle of this: the Site Controller, who was the local integration director supporting the DSM/McKinsey team.

He had considerable authority, but what impressed me most was how he used it.

When there was a conflict, he would patiently listen to both sides. He did not immediately decide who was right. He helped clarify the arguments and then helped the parties find a way forward.

His interventions were particularly useful when the Plant Manager and I disagreed.

Looking back, this was another important element of the new way of working.

Empowerment does not eliminate conflicting interests.

If anything, when people have more responsibility, those interests become more visible.

You therefore need management that is less about prescribing the answer and more about alignment, mediation and helping people resolve conflicts.

The control room was only the beginning

Eventually the new central control room went live.

That was a landmark event. The physical change was obvious: the operators were now working in a completely different environment, with the new technology and the new organisation around them.

But the opening was not the end of the project.

The much harder task was embedding the new way of working.

Operators and shift leaders had to become comfortable with their new responsibilities. The OCAPs had to become part of normal operation. The work processes had to become part of everyday management rather than something belonging to the implementation project.

And the organisation had to learn to operate without constantly referring back to the people who had designed the change.

I stayed for that phase.

Gradually the other DSM people involved in the implementation left.

Eventually I was the only DSM person left.

My role had therefore changed again.

I had started as the person responsible for implementing the change. I was now helping the local organisation make the change its own.

That meant discussing problems, questioning whether the new roles were actually working, helping people use the work processes and supporting the transition from project implementation to normal management.

Eventually, responsibility could be handed over to the permanent organisation, including the continuing implementation and auditing of the work processes.

The project team had to become unnecessary.

That was, in a sense, the ultimate test.

What Scotland taught me

Looking back, Scotland gave me several different lessons.

I learned that changing an organisation is different from designing one.

I learned that empowerment requires more than giving people responsibility: people need the knowledge, information and confidence to use it — and managers need to create the conditions for them to challenge and take responsibility.

I learned to be more patient with forms of behaviour that initially looked like a lack of urgency or commitment.

And I learned that even an empowered organisation needs management: not necessarily management that tells people what to do, but management that helps reconcile interests, resolve conflicts and keep the organisation moving in the same direction.

Most importantly, the control-room project made the distinction between implementation and embedding very tangible to me.

We could define roles, write work processes, create OCAPs and switch on a new control room.

But eventually the people in the organisation had to answer a much simpler question for themselves:

“What happened during my shift, and what did I do about it?”

That, ultimately, was the real shift in responsibility.

And it was a shift that could not be achieved by the control room, the organisation chart or the work-process manual alone.

When DSM integrated the former Roche Vitamins business, one of the major drivers was cost reduction. It would later be integrated as DSM Nutritional Products (DNP). The different Roche Vitamins sites had to develop their own integration plans, with clear targets for reducing costs.

I became involved as team lead Process Automation, together with two engineers from Roche Vitamins.

We visited the major sites and organised workshops with the local teams. Each site had an integration team, including a DSM representative and a McKinsey consultant, which was working on the overall site integration plan.

Our part was to look at the process-automation and operator organisation, but the local teams were looking at the future organisation much more broadly.

Starting with the work

The workshops were essentially an activity analysis around the existing operator work places, in control rooms and elsewhere.

We went through what operators actually did, what activities were performed at each work place and what the workload was.

From this we could work towards the future organisation.

Two elements were particularly important.

The first was centralisation of the control rooms. If several existing operator stations could be brought together, the work could potentially be performed with fewer operators.

The second was the establishment of an operator day-shift team, moving activities that did not need to be performed by shift operators into a different organisational arrangement.

But the local teams did not look only at Operations.

They used the work processes as a basis for designing the organisation that would remain around the central control room. In particular, processes such as Improve Plant and Do Maintenance helped define what responsibilities would remain outside the shift organisation and how those activities should be organised.

At the same time, Operate Plant Normal provided a basis for defining the future operations organisation and the way the central control room would operate.

This was an important aspect of the work-process concept: it was not simply a description of what people did. It could also be used to design an organisation.

From activities to a business case

Based on the activity analysis and the proposed future organisation, we could estimate the required future headcount.

That estimate became an input to the site’s overall integration plan and therefore to the cost-reduction target.

There was another practical aspect.

If we proposed centralising control rooms, there would be consequences beyond the operator headcount. Where would the new control room be? What would have to be rebuilt? How much construction work would be required?

I therefore brought in an ergonomist to assess potential locations for the future control room and the associated construction work.

So the exercise connected several levels:

existing activities → work processes → future organisation → central control room → operator headcount → construction requirements → cost reduction.

This was quite different from simply saying: “We can save operators by putting the control rooms together.”

The work-process framework helped determine what the future organisation would actually do and how the responsibilities would be divided.

From one project to a larger transformation

This was also a significant step beyond my earlier Rotterdam experience.

In Rotterdam, I had been the project manager for a particular control-room consolidation and could develop the solution from the ground up.

Now the same basic ideas were being applied across several sites, within a much larger organisational transformation. But the experience also taught me that not every plant was suitable for exactly the same strategy. Some of the DSM Nutritional Products processes were much more complex, with considerably more manual work, and in those cases the case for centralising control rooms was simply not there. The approach therefore had to start from the actual characteristics of each plant rather than assuming that one solution would fit all.

There was an interesting combination of approaches.

The cost-reduction target provided the business driver.

The activity analysis provided the factual basis.

The work processes provided a framework for designing the future organisation.

And the central control room became one of the major changes through which that organisation could be realised — where the characteristics of the plant made such a solution appropriate.

From designing the organisation to teaching the way of working

The initial round of site analyses was only the beginning.

Once the future organisations had been defined, we started the work-process training. I was involved in training for Operate Plant and Asset Utilization.

This brought the work-process concept to a different level.

During the workshops, we had used the work processes as a framework for thinking about the future organisation. Now people had to learn what those processes meant for their actual work: their roles, responsibilities, interactions and the way performance would be managed.

And this was where I could bring something from the Rotterdam experience back into the story.

I invited one of the Rotterdam operators who had been particularly enthusiastic about the new control-room environment to participate in the training.

He could tell the new colleagues what had actually happened after the new system had been introduced.

He had not simply sat behind a different set of screens.

He and his colleagues had started asking for information they needed, building displays themselves and using the historian and other tools to create solutions for their own work. The new technology had given them possibilities that they had discovered and exploited themselves.

That was a much more convincing demonstration of empowerment than anything I could have explained in a classroom.

For the Improve Plant training, I also invited the plant staff manager from Rotterdam.

That was deliberate.

The idea was not to create a standardised training course delivered by people from the integration project. We wanted people who had actually lived with the new way of working to share their experience with colleagues who were about to go through the same transformation.

Looking back, I think this was an important characteristic of the DSM approach.

The change was propagated through people who had experienced it, not only through procedures and presentations.

The work processes provided the common language and framework. The control-room projects provided a practical application. And people from the earlier projects could explain what the new way of working actually looked like in practice.

The control-room concept was subsequently implemented at the different DSM Nutritional Products sites by the sites themselves — with one notable exception: Scotland.

In Scotland, instead of supporting the implementation from a distance, I would become the implementation project manager myself.

And there the question would become much less about designing the organisation on paper and much more about actually changing the way people worked within it.