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.