Timelime of the career of Ernie Dullaard
1983 – Ernie starts his career at NS Cargo
1999 – Meets APVO during Dutch–German integration project
2000 – Railion Benelux is established
2003/2004 – RCS selected as operational platform
2009 – Ernie moves from business into IT
2010s – Master Plan IT and European harmonisation
2020s – Mobile applications, WIM and continuous innovation
2026 – Retirement after more than forty years
Forty Years of Change, One Constant Partnership
When the Railway Changed Forever
By Edwin Visser
There is something fitting about talking to Ernie Dullaard at the end of his career. Not because he is retiring after more than forty years at DB Cargo Netherlands, but because he has witnessed one of the biggest transformations in European rail freight from the front row. His career spans an era that began with nationally operated railways and ends in a world of integrated logistics networks, digital platforms and real-time information.
For most people, rail freight is something they rarely think about. Trains pass by, containers move across Europe and goods arrive where they need to be. Behind that apparent simplicity lies one of the most complex logistical systems in the world, one that has reinvented itself several times during Ernie’s career.
“I entered a completely different railway world,” Ernie says.
Back then, Europe was still divided into national railway companies. Every country had its own state-owned operator. In the Netherlands there was NS Cargo. Germany had Deutsche Bahn. France had SNCF. Each organization worked largely within its own borders, supported by its own processes, its own systems and its own way of doing business.
“There simply weren’t any private railway companies,” Ernie recalls. “Everything was state-owned. Competition wasn’t really part of the equation.”
Profitability was rarely the primary objective. Railways fulfilled a public task. International freight certainly existed, but cooperation between countries was largely managed through agreements between national organizations rather than through integrated business operations.
Then Europe changed.
Liberalization Changed Everything
Around the turn of the millennium, the European Commission began opening the rail market to competition. Private operators entered the network, regulations changed, and national railways suddenly found themselves competing in a commercial environment.
For companies like NS Cargo, the consequences were enormous. “It meant we had to change,” Ernie says matter-of-factly. That simple sentence captures a revolution.
Organizations that had operated comfortably within national borders suddenly had to think internationally. Efficiency became a competitive advantage rather than a policy objective. Customers expected transparency. Processes had to become faster. Information had to flow between countries instead of stopping at the border.
And perhaps most importantly, software suddenly mattered. The old systems had been designed for organizations that barely changed. The new railway required systems that could evolve continuously.
A Meeting That Would Shape Twenty-Five Years
In 1999, while Europe was preparing for a new railway landscape, Ernie found himself involved in a project that seemed relatively straightforward.
At the time, nobody knew it would become the beginning of one of the longest customer partnerships in Ab Ovo’s history.
“I met Ronald Sand and Willem Jan Groenewoud for the first time,” Ernie remembers.
At that stage, they weren’t discussing software implementations. They weren’t selecting products. They weren’t negotiating contracts. They were asking questions.
German and Dutch freight operations were preparing to work much more closely together. Before anyone could decide which systems to use, they first needed to understand what already existed.
Which applications were in place? What functionality did they provide? Could German systems be adopted in the Netherlands? What were the advantages? Where were the gaps?
“It wasn’t a decision to merge systems,” Ernie explains. “The project was simply about understanding the possibilities before making any decisions.”
Looking back, that approach says a great deal about what would later become Ab Ovo’s way of working.
The technology wasn’t the starting point. The business was.
Railion Is Born
The discussions quickly became reality.
On 1 January 2000, Railion Benelux officially came into existence. NS Cargo ceased to exist as an independent organization, becoming part of a new international structure.
Even the name had only been decided a few months earlier.
Suddenly there was a new company. A new strategy. And a fundamental question. If the organization had changed, shouldn’t its IT landscape change as well?
“That became the next step,” Ernie says. “We had to determine which systems were suitable for the Dutch organization within Railion.”
It sounds almost obvious today. At the time, it was anything but.
Every national railway had developed its own applications over decades. Processes differed. Terminology differed. Even the way freight operations were organized differed from country to country.
Integrating organizations meant integrating information. That turned out to be much harder than changing a company name.
More Than Technology
Looking back now, Ernie doesn’t describe those years as an IT project. He describes them as a business transformation. Technology followed the business, not the other way around.
That distinction would become one of the defining characteristics of his collaboration with Ab Ovo over the next twenty-five years.
The conversations were never simply about replacing software. They were about supporting a business that was changing faster than ever before. As European rail freight became more international, information had to become more accessible. As operations became more complex, planning had to become more integrated. As organizations merged, systems could no longer remain isolated.
Without realizing it, Ernie and his colleagues were laying the foundations for something much bigger than a software implementation.
They were preparing for a completely different way of working.
The End of One Era, and the Beginning of Another
When Ernie looks back on those first years, he doesn’t speak nostalgically about the past.
He recognizes that change was inevitable. The railway industry couldn’t remain organized around national borders while freight itself had become international.
The challenge wasn’t simply adopting new technology. The challenge was finding technology capable of growing alongside the business. That search would eventually lead DB Cargo to a new operational platform called Rail Cargo System.
It would also begin one of the longest-running partnerships in European rail logistics.
Choosing RCS: Building More Than Software
When Railion Benelux was established in the early 2000s, the company inherited more than a new name and a new organizational structure. It also inherited an IT landscape that belonged to another era.
The freight business was changing rapidly. Customers expected more transparency, operations were becoming increasingly international, and planning was growing more complex by the day. Yet many of the systems supporting those operations had been developed for a world that no longer existed.
One of those systems was Bravo, a Swedish application that had served the organization well for many years.
“It wasn’t a bad system,” Ernie Dullaard reflects. “But it had reached the end of its life. We were looking for a more efficient way to plan our resources and support our operations.”
That search would eventually lead to one of the most important technology decisions in the company’s history.
Looking Beyond Technology
Many software selection projects begin with a long list of technical requirements.
This one was different.
Several suppliers were invited to present their ideas. Railion wanted to understand not only what each system could do, but also how it would support the company’s future.
“We asked different suppliers to bring their proposals,” Ernie recalls. “And in the end, we chose RCS.”
Looking back more than twenty years later, Edwin Visser asks the obvious question.
Why?
After all, selecting a core operational platform is not a decision companies make lightly. Ernie smiles before answering.
“It started with trust.”
A Supplier That Already Knew the Business
By the time the RCS selection process began, Ab Ovo was no longer an unfamiliar company.
The relationship had already started during the integration of the Dutch and German freight organizations, and shortly afterwards Ab Ovo had taken responsibility for managing Railion’s IT environment.
“They already knew our company,” Ernie explains. “They understood our processes. They understood our culture. They knew how we worked.”
That may sound like a small advantage. In reality, it was enormous.
Many software suppliers arrive with a product and then try to understand the customer’s business.
Ab Ovo had done it the other way around. Before writing software, they had spent years learning how Railion actually operated. That knowledge became a competitive advantage.
“It wasn’t only that they knew the technology,” Ernie says. “They knew the organization.”
More Than the Best Proposal
Of course, familiarity alone would never have been enough.
Other suppliers also entered the competition. Ernie still remembers one of them—a company from Liverpool called Fraser Williams—although many of the other names have faded over time.
What he does remember clearly is the outcome.
“When we compared the functionality,” he says, “RCS simply offered the best proposal.”
That sentence reveals something important. The decision was not based on relationships alone. RCS had to prove itself. It did.
The software matched the operational requirements, but perhaps more importantly, it matched the direction in which the company wanted to move. Railion wasn’t looking for another isolated planning tool.
It was looking for the foundation of an integrated operational platform.
Building Together
Edwin joined Ab Ovo years later, long after the first version of RCS had gone live.
He remembers hearing stories from colleagues about how the system had been developed in the basement of Ab Ovo’s former office in Utrecht.
For him, those stories had become almost legendary. For Ernie, however, they represented something much more practical. The software had never been developed in isolation.
It had been built together with the customer.
“I wasn’t directly involved in developing the software,” Ernie explains. “At that time I was responsible for intermodal transport, so my focus was on the business. Later, I became much more involved from the IT side as a process owner.”
That transition would prove to be invaluable.
Having worked on both sides of the organization, Ernie understood not only what the business needed, but also how technology could support it.
Software That Could Grow
One of the reasons RCS proved so successful was that it wasn’t designed to solve a single problem.
It was designed to evolve. That wasn’t obvious in 2003. At the time, nobody could predict how quickly the railway industry would change. Railion would become DB Schenker Rail.
Later it would become DB Cargo again.
The company would acquire operations in countries such as Italy and Denmark, bringing together organizations with different systems, different processes, and different ways of working.
Every organizational change placed new demands on technology. Most software struggles with that kind of evolution. RCS did not.
The Beginning of a Long Journey
Looking back today, it is tempting to see the selection of RCS as an obvious decision.
It wasn’t. It was a calculated risk. The company wasn’t just choosing a new application. It was choosing a long-term partner.
More than two decades later, that partnership is still intact. For Ernie, that says everything.
The success of RCS wasn’t determined on the day the contract was signed. It was determined by what happened afterwards. Every process improvement. Every new regulation. Every organizational change. Every challenge that required software to adapt rather than stand still.
The decision to choose RCS turned out to be about much more than replacing Bravo.
It marked the beginning of a collaboration in which software would grow alongside the business itself.
From Patchwork to Network
“Technology wasn’t our biggest challenge. Our biggest challenge was connecting the way we worked.”
The decision to implement RCS was never intended to solve a single operational problem. It was the beginning of something much larger.
Looking back, Ernie Dullaard describes the years that followed not as a software implementation, but as the gradual construction of a European railway company. The technology simply happened to make that transformation possible.
By the time he returned to RCS from the business side, his own career had changed direction.
For years he had been responsible for intermodal transport, working close to customers and operations. But around 2009, he made an unexpected move.
“I switched from the business into IT,” he says.
For many people that might seem like a complete career change.
For Ernie, it was simply another way of improving the railway.
Looking at the Railway Again
The timing was significant.
DB Cargo had continued to grow through acquisitions and international expansion. Italy had become part of the organisation. Denmark had joined. Different business units across Europe each brought their own operational processes, their own software and their own local way of working.
“It reminded me very much of 1999,” Ernie reflects.
“Once again we had to step back and ask ourselves a fundamental question: what should our IT landscape actually look like?”
The answer wasn’t encouraging.
“When you looked across the organization,” he says, “what you saw wasn’t a network. It was a patchwork.”
The word immediately captures the problem.
Individual systems worked reasonably well within their own countries. Local departments had optimized their own processes over many years. But together they formed a collection of isolated islands rather than a connected organization.
Information stopped at organizational boundaries. Processes stopped at national borders. Technology reflected history rather than the future.
The Master Plan
To solve that problem, DB Schenker Rail launched what became known internally as the Master Plan IT.
For Ernie, it was one of the most important projects of his career. The objective wasn’t to replace software simply because it had become old. The objective was much more ambitious.
“We wanted to harmonize our processes and the systems that supported them,” he explains.
That distinction matters. Many digital transformation programs begin with technology. This one began with process. Only after understanding how the organization wanted to work could the company determine which systems were capable of supporting that vision.
The question was no longer:
Which application do we need?
Instead it became:
How should a European freight railway actually operate?
Only then could software become part of the answer.
From Order to Cash
One phrase keeps returning throughout Ernie’s explanation. Order to cash. It sounds like business jargon. In reality, it describes almost every step involved in transporting freight across Europe.
A customer places an order. Capacity is reserved. Trains are planned. Locomotives and drivers are assigned. Consignment notes are created. Operational changes are processed. The journey is monitored. Finally, the customer receives an invoice. Each of those steps may involve different departments:
- Commercial teams
- Planning departments
- Operations
- Customer service
- Finance
Historically, many of those departments used separate applications.
Information was transferred manually. The same data was entered multiple times. Every handover increased the chance of delays or mistakes.
“What we were looking for,” Ernie explains, “was one system that could support our common processes. From order all the way through to invoicing.”
He pauses before correcting himself.
“Actually… from order to cash.”
That small correction says everything. RCS wasn’t simply recording operational information. It was supporting the entire business process.
Breaking Down Silos
Edwin remembers that period well.
Having worked as a consultant on the project himself, he recalls how RCS gradually connected departments that had previously worked almost independently. Orders could already be prepared before trains actually departed. Operational planning became visible across departments.
Consignment information flowed through the organization instead of remaining within individual applications.
For customers, much of this happened behind the scenes. For employees, it fundamentally changed the way they worked.
Instead of constantly asking colleagues for updates, information increasingly became available directly inside the system.
Planning no longer depended on who happened to know the answer. The organization itself became the source of truth.
A European Mindset
Looking back, Ernie believes one of the biggest changes wasn’t technological at all.
It was cultural. For decades, railway companies had been organized nationally. Each country had developed its own habits.
Its own terminology. Its own preferred ways of working. Creating a European railway company meant asking people to think differently.
Not:
“How do we do this in the Netherlands?”
But:
“How should we do this together?”
Software became the place where those common processes were defined. It forced discussions. Sometimes difficult ones. Should one country adapt? Should another? Or should everyone change a little?
Those conversations were often more important than the technology itself.
Growing Together
One reason the collaboration with Ab Ovo continued so successfully was that the software never remained static.
As the organization learned, RCS learned with it. New operational requirements became new functionality. Changing legislation became software updates. Business improvements became system improvements.
“It wasn’t about buying software once,” Ernie reflects, “It was about continuously improving the way we worked.”
That philosophy would define the relationship for the next twenty years. The system wasn’t simply maintained. It evolved alongside the business.
And as DB Cargo became more integrated across Europe, RCS quietly became one of the foundations that made that integration possible.
Software That Grows with the Business
“Software isn’t finished when it’s implemented. That’s when the real work begins.”
If there is one lesson Ernie Dullaard has learned after more than four decades in rail freight, it is that no operational system remains relevant by standing still. Rail freight doesn’t stand still. Customers change. Legislation changes. Markets change. Organizations change. So software has to change as well.
Looking back over more than twenty years of collaboration with Ab Ovo, Ernie doesn’t remember major software releases or version numbers. Instead, he remembers a continuous conversation.
“What does the business need now?”
That question never disappeared. It simply kept evolving.
From Project to Product
Many IT projects begin with a clear finish line. Requirements are gathered. Software is developed. The system goes live. Project completed.
RCS never worked that way. Of course, there was an implementation. There was a go-live. There was training.
But almost immediately afterwards, the next improvement appeared. A regulation changed. A customer requested new functionality. Operations were reorganized. A process became more efficient.
“There was always another step,” Ernie says.
Instead of treating RCS as a completed application, DB Cargo and Ab Ovo treated it as a product that continued to mature alongside the organization.
That difference proved essential.
Because while software ages, businesses don’t stop evolving.
The Railway Never Stops Changing
One of the biggest misconceptions about railway operations is that everything follows fixed procedures.
Passenger rail often works that way. Freight does not.
Freight rail is constantly adapting. A customer wants a different service. A terminal changes its processes. European legislation introduces new requirements. A neighboring country adopts a different operational standard.
Every one of those changes has consequences. And every consequence eventually reaches the software. Ernie saw that happen time and again.
“We never reached a point where we could say, ‘Now we’re finished.'”
There was always another improvement waiting.
Regulations Become Reality
European railway legislation has become increasingly harmonized over the years. For operators, that has been both an opportunity and a challenge. Standardization makes international cooperation easier. It also means systems have to adapt continuously.
One example Ernie remembers well is the introduction of the European Brake Sheet. For generations, brake information had been handled according to national practices. Now a common European approach had to be supported. That sounds like a relatively small adjustment.
It wasn’t. Every operational document influences planning. Planning influences execution. Execution influences safety. Safety influences compliance.
Suddenly, what appeared to be a single document became part of a much larger operational process.
Because RCS had been designed to evolve, the new requirements could be incorporated without redesigning the entire platform.
“That flexibility became one of the strengths of the system,” Ernie explains.
It wasn’t only responding to today’s business.
It was preparing for tomorrow.
When the Business Changes
Technology wasn’t the only thing evolving. The company itself changed dramatically.
When RCS was first introduced, DB Cargo Netherlands still functioned as what Ernie describes as a full-blown railway company.
The organization handled virtually every aspect of freight transport:
- Commercial contracts
- Pricing
- Planning
- Operations
- Customer service
- Billing
Everything happened within one organization.
Over the years, that model gradually changed. Responsibilities shifted within the wider DB Cargo Group. Some activities became centralized. Others moved to specialized business units.
The Dutch organization increasingly focused on production: the actual execution of rail freight operations.
That meant software had to change as well. Some functionality became less important. Other capabilities became essential.
“The business was different,” Ernie says.
“So naturally the system had to become different too.”
Rather than forcing the organisation to continue working in an outdated way, RCS adapted to its new role. That adaptability protected years of investment.
Instead of replacing software every time the organisation changed, the software simply evolved with it.
Listening to the People Who Use It
One of the characteristics Edwin has always associated with Ab Ovo is something that rarely appears in software specifications.
Listening.
Throughout the interview, Ernie returns repeatedly to the close relationship between developers and users.
New functionality rarely appeared because somebody had written a long technical specification. It appeared because conversations took place. Operational staff explained their challenges. Process owners identified opportunities. Developers asked questions.
Sometimes the original request wasn’t even the real problem.
By understanding daily operations, Ab Ovo often proposed solutions that went beyond what customers had initially imagined.
“It was never simply a matter of building what we asked for,” Ernie says, “They looked at why we were asking.”
That difference changed the nature of the relationship. Ab Ovo wasn’t simply developing software.
They were helping improve the business itself.
From the Office to the Tracks
Perhaps the clearest example of that philosophy appeared when mobile technology entered the railway.
For decades, operational information had largely stayed inside offices. Inspectors worked outside. Drivers worked outside. Shunting personnel worked outside. Yet many of the systems supporting them remained tied to desktop computers. As smartphones and tablets became more powerful, new possibilities emerged.
Suddenly, information could travel with the employee. Damage could be reported directly from the yard. Operational updates no longer had to wait until someone returned to the office.
Photographs could become part of the process. Information became richer. Faster. More reliable.
For Ernie, mobile applications weren’t simply another technological trend.
They represented another step in bringing information closer to the people who actually needed it. “The right information should be available at the right place,” he says.
It sounds obvious. In practice, it transformed daily operations.
Continuous Improvement
When people think about digital transformation, they often imagine one major implementation.
A new system. A big launch. A dramatic before-and-after moment.
Ernie has experienced enough transformations to know that reality is different. Real transformation happens gradually.
One improvement. Then another. A regulation. A mobile application. An integration. A process optimization.
None of them changes the business overnight.
Together, they reshape an organization over decades.
Looking back, perhaps that is what makes the partnership between DB Cargo and Ab Ovo so unusual.
It was never built around one project. It was built around continuous improvement.
And that mindset, more than any specific technology, became one of the reasons the collaboration lasted for more than twenty-five years.
The Right Helping Hands
When people talk about successful software projects, they often focus on technology. The architecture. The programming language.The integrations. The implementation. After spending more than forty years in rail freight, Ernie Dullaard has a different perspective. Technology matters. But relationships matter more.
As our conversation draws to a close, I ask him a simple question. After more than twenty-five years of working together, how would he describe Ab Ovo?
He doesn’t hesitate for a second.
“The right helping hands.”
It is probably the shortest answer of the entire interview. It also turns out to be the most revealing.
Thinking Beyond the Question
I ask him what he means. Is it about listening to the customer? Understanding requirements? Delivering software on time?
Ernie shakes his head. “No,” he says. “More than that.”
Then he explains something that, in many ways, defines the entire relationship between DB Cargo and Ab Ovo.
“When I have a wish or a problem,” he says, “Ab Ovo doesn’t simply solve that problem. They always solve a little bit more.”
It is a subtle distinction. Many software companies deliver exactly what the customer asks for. Ab Ovo consistently tried to understand why the customer was asking in the first place. That often led to a better solution than the one originally requested. For Ernie, that extra step made all the difference.
The Story of WIM
To illustrate the point, he tells the story of one particular feature. Inside DB Cargo it is known simply as WIM. The Wagon Information Message. At first glance, it sounds like a relatively small piece of functionality. It wasn’t.
Originally, the requirement was straightforward. “We only needed a list of wagon numbers,” Ernie recalls. “And, if possible, the weight of the wagons.” That was all. A replacement for the old arrival notification. Nothing more. The development team could easily have built exactly that. Instead, they asked another question.
What information does the customer actually need?
The answer transformed the entire concept.
From Notification to Information Exchange
Rather than sending only wagon numbers, WIM became an intelligent information service. Every customer could receive information automatically when a train arrived at a specified location. But it didn’t stop there.
Customers could also receive:
- departure station
- wagon capacity
- cargo weight
- maintenance and revision dates
- arrival notifications
- parked wagon overviews
- operational status
- and any additional information relevant to their own business processes
“What kind of information do you need?” became the guiding principle.
According to Ernie, customers were often surprised by how much information could actually be delivered. “They thought they needed one thing,” he says. “And then they discovered there was so much more value available.”
Information That Fits the Customer
The next step was even more interesting. Not every customer needs the same information. A terminal operator has different requirements than a chemical producer. A steel manufacturer looks at different operational data than an intermodal terminal.
So WIM became flexible.
Information could be tailored to individual customers. Contracts determined which information was visible. Customers only saw data relevant to their own wagons and operations, protecting commercially sensitive information while still providing complete transparency where it mattered.
For Ernie, this perfectly illustrated what good software should do.
It shouldn’t simply digitize existing paperwork. It should improve the way people work.
Planning Beyond the Railway
One of the most interesting consequences of WIM was that it reached beyond the railway itself.
Information no longer stopped once the train arrived. Terminal operators began using WIM to organise their own internal processes. Every morning they could see which wagons were already parked in their yard. They could prepare unloading schedules. Allocate staff. Reserve equipment. Organise storage capacity.
The railway had become part of the customer’s planning process. That represented a profound shift. The software wasn’t only supporting DB Cargo.
It was supporting the entire logistics chain.
Looking in the Mirror
Not everything in the interview is nostalgic. When the conversation turns to mobile applications, Ernie offers a remarkably honest reflection.
Asked whether the railway industry embraced mobile technology quickly enough, he smiles.
“As a company,” he says, “you have to look in the mirror.” Then he answers his own question. “Did we start too late?” “My answer is, frankly speaking… yes.”
It is a refreshing moment. After forty years in the industry, he is still willing to acknowledge that some opportunities could have been seized earlier.
Perhaps that openness explains why his career has been so closely associated with continuous improvement.
You cannot improve if you first refuse to admit something could have been done better.
More Than Software
As we approach the end of our conversation, I realise that we’ve spent surprisingly little time talking about technology.
Yes, we’ve discussed planning. Integrations. Order-to-cash. RCS. Mobile applications. WIM. But every technical subject eventually led back to people. To cooperation. To trust. To understanding each other’s business.
Perhaps that explains why the partnership between DB Cargo and Ab Ovo has lasted for more than a quarter of a century.
It was never built on contracts alone. It was built on curiosity. On listening. On challenging assumptions. On asking one extra question before writing one extra line of code.
Looking Back
Soon, Ernie will officially retire. The railway industry he entered no longer exists. The company has changed names several times. Markets have opened. Technology has evolved beyond recognition.
Processes that once depended on paper, telephone calls and local knowledge now rely on integrated digital platforms operating across Europe.
And yet, some things remain unchanged. Customers still need reliable transport.
People still need information they can trust. Technology still exists to support the business, not the other way around.
Before we end, I ask Ernie one final question. Not about software. Not about railways. But about collaboration.
What, after all these years, defines Ab Ovo?
He smiles again.
“The right helping hands.”
After everything we’ve discussed over the past hour, it feels like the perfect ending. Not because it describes a software company. But because it describes a partnership.
And perhaps that is the real story behind forty years of change. Not that technology transformed the railway.
But that the right people transformed it together.
