It Is Never Just About the Software

How better information, stronger relationships and smarter processes can make rail freight more competitive

By Marcel Veenstra, Senior Business Consultant Rail Cargo at Ab Ovo

When people ask me what I do at Ab Ovo, the straightforward answer is that I am a Senior Business Consultant working with our Rail Cargo System, RCS. I have been doing this work for around eighteen years.

But that answer does not really explain the job.

My work is not simply about implementing software, writing requirements or showing customers how a particular function works. It is about understanding how rail freight operates in practice. It is about asking why people work in a certain way, identifying where information is lost and helping customers make their processes safer, more efficient and financially sustainable.

Most importantly, it is about people.

Before joining Ab Ovo, I worked in logistics and spent eight years at DB Cargo in the Netherlands. That experience still influences how I approach every customer question. I understand that software is only one part of the operation. Behind every transport order, train composition, invoice and status message, there are people who have to make decisions and take responsibility.

Technology can support them. It can provide the right information, automate repetitive work and reduce the chance of mistakes. But the system does not run the railway by itself.

That is why I believe our work should never begin with the software. It should begin with the business.

When customers become friends

What I enjoy most about my job is the close connection I have with our customers.

Some of these relationships have existed for many years. They have developed far beyond the traditional distance between a customer and a software supplier. I have cooked goulash on a Sunday morning in the garden of a customer’s father. I have cycled to Lake Balaton with someone who may officially be a customer, but whom I would now describe as a friend.

Those experiences may seem separate from business, but they say something important about how we work.

A strong relationship creates trust. When customers trust you, they do not always create a formal ticket, write a long email or submit a detailed request through a system. Sometimes they simply call.

“Marcel, I see this problem. What do you think? How could we solve it?”

Very often, I can help immediately. The problem may not require a change to RCS at all. It could be a matter of understanding an existing function, correcting a process or helping someone use the available information more effectively.

When a genuine new requirement does arise, we work on it together.

That word—together—is essential. The customer and Ab Ovo are not moving in opposite directions. We have the same goal. We want the operation to work, the users to be supported and the implementation to deliver real value.

When we introduce a new version and it goes live without issues or emergency patches, I feel proud. Not because Ab Ovo has delivered something to a customer, but because we have reached the destination together.

Long-term partnerships make that possible. Over time, you learn how an organization operates. You understand its processes, history, concerns and ambitions. The customer, in turn, learns that you are not there simply to sell functionality. You are there to help improve the business.

The most important question is often “why?”

When a customer presents a challenge, I do not automatically accept the existing process as the correct starting point.

Someone may say, “This is what we do.”

My response is often: “Why do you do it that way?”

Does the activity create value? Is it a service that has been agreed with the customer? Does it contribute to the profitability of the organization? Is it necessary because of legislation or operational safety? Or is it simply a habit that has continued because nobody has challenged it?

Time spent handling a process is money. If people carry out work that adds little value, the organization is paying for that effort. When we can simplify the process, automate part of it or remove unnecessary handling, we make life easier for the employees and improve the performance of the company.

This does not mean that every existing process is wrong. Many procedures have valid operational, contractual or legal reasons behind them. But we should understand those reasons before transferring the process into a new system.

Replacing an old application while preserving every old habit is not transformation. It is only digitizing the past.

Our goal should be to help the company become better than it was before.

That requires open conversations. We may use business process diagrams and our BPM tools to visualize how the work currently flows. A visual model creates a shared view. People from different departments can look at the same process and discuss what is actually happening.

The model becomes a translation tool. People do not need to speak the language of software development. They can see the steps, responsibilities and information flows in front of them.

From there, we can ask better questions.

Do all these steps remain necessary? Where is information entered more than once? Which activities can be automated? Who really needs to receive a particular message? Where does the organization depend on local spreadsheets, screenshots or personal knowledge?

A diagram alone does not create change. People need help understanding it, and not every user is experienced in reading process models. That is why we talk customers through the process and discuss the different situations together.

The value is not in the picture itself. The value is in the conversation it creates.

Software cannot change habits by itself

Even when new functionality is available, people do not automatically change the way they work.

We sometimes introduce structured information services, such as train or wagon information messages, while users continue to make screenshots and send separate emails. From their perspective, that method feels familiar. They know who normally receives the message and they trust their own routine.

A system cannot solve that problem on its own.

Managers need to support the change and give people confidence in the new process. They must explain why the organization is working differently and make sure employees understand that the information in the system can be trusted.

At Ab Ovo, we sometimes organize over-the-shoulder sessions. We sit with users while they carry out their daily work and observe what actually happens.

Why did you open that spreadsheet?

Why are you copying that information?

Why are you sending this message?

What happens after the recipient receives it?

Could the system already support this activity?

Perhaps another customer has faced a similar situation and we have already implemented a process that could help.

These sessions are valuable because the formal process description does not always reflect the reality at a local office, terminal or operational location. We can see what happens within RCS, but we cannot automatically see the parallel activities taking place outside the system.

That is where old habits often survive.

Successful digitalization therefore depends on more than functionality. It requires management attention, user involvement and a serious approach to change.

My personal ambition: fewer emails

One of my personal goals is to reduce the amount of operational work that depends on email.

Email is useful, but in many organizations it has become a process of its own. People send a message to a large distribution group, even though only one or two recipients actually need the information. Everyone receives the attachments, opens the message or creates an Outlook rule to avoid reading it.

I have seen emails containing nine or even eighteen attachments. Every copy consumes storage, but the greater cost is the attention it demands from people.

A railway operation may involve one person who needs information to prepare or run the train, another who needs information for invoicing and someone else who needs it for reporting. They do not all need to receive the same email.

Within RCS, the relevant data can be stored centrally. Each user can access the information required for their role. The invoicing process, for example, can use the content of the train or the information in the waybills without requiring someone to collect and forward attachments manually.

The aim is not to send more information. It is to make the right information available to the right person at the right moment.

Web interfaces and APIs can extend that approach to external parties. They can retrieve the data they need or register completed events directly, without starting another email chain.

I do not expect email to disappear completely. But we can significantly reduce the number of people whose daily work consists largely of reading, forwarding and processing messages.

That gives them more time for work that requires knowledge, judgment and human attention.

Do not replace six systems with a seventh

Introducing a rail cargo system is not the same as buying a standard application and switching it on the next morning.

Railway companies have specific processes, contractual arrangements, interfaces and operational responsibilities. During a tender, organizations describe their requirements based on how they understand their current business.

Writing those requirements is a specialized task. We need to understand what the customer has written, but also what the organization is truly trying to achieve.

Because RCS has been used in live rail operations for many years, we bring practical knowledge to that discussion. We can map a customer’s requirements to processes that already exist in the solution, while helping the organization look beyond a direct replacement of its old system.

The question should not be: how can we reproduce every old function?

It should be: how can we prepare this organization for the future?

That could mean improving data quality, automating activities or reducing the number of systems involved in the same process. Contracts, train operations and invoicing should not necessarily exist in separate worlds. When information is connected, everyone has a clearer understanding of what is happening.

The last thing a company needs is to introduce a new application while continuing to maintain six other systems that perform overlapping tasks.

Digital transformation should reduce fragmentation, not add another layer to it.

Taking implementation step by step

The scope and duration of an RCS implementation depend on what the customer wants to achieve. In many cases, we advise a phased approach.

A company could begin with invoicing. That is often a practical starting point because it does not immediately interfere with the live operation of the trains. Once a transport has been completed, the relevant order and operational information can be used to prepare the financial process.

After that, the implementation can expand into the operational domain.

This reduces risk and gives the organization time to learn. People can see value being created in one part of the business before the solution is extended to more operationally sensitive activities.

However, to understand the value of an integrated rail cargo system, it helps to follow the complete journey of a transport.

From commercial agreement to train departure

A transport normally starts with a commercial agreement between the railway company and its customer.

The customer then places an order. That order may concern an entire train or a single wagon. Both scenarios can be supported within RCS.

Let us take a complete train as an example.

The train is requested from the infrastructure manager, and the railway undertaking receives the timetable. The operator must then collect detailed information about the train’s composition.

Which wagons will be included?

What cargo is being transported?

Are dangerous goods involved?

Does the train contain exceptional transport that requires specific permission?

What are the wagon numbers, weights and seals?

This information is gathered within the transport order. When necessary, it can also be used to create a consignment note.

The wagons are then connected to the relevant order and train. This allows the system to show where a wagon is located, what is happening to it and on which train it is planned next. Shunting teams can see which wagons need to be placed on a particular train and prepare the composition in time.

Before departure, both administrative and technical checks are required.

Someone may physically inspect the train, register the brake test and record wagon defects. At the same time, the system can support checks relating to the length and total weight of the train, the individual wagon weights and the rules for transporting dangerous goods.

Once the train has been checked and confirmed, a series of automated processes can begin.

RCS can create the train list and brake list. It can send train composition and confirmation messages to the infrastructure manager. Depending on the operation, it may also send electronic consignment notes or information to the next railway undertaking.

Wagon defects can be registered and communicated to the relevant broker so that the wagon owner can be informed.

For some customers, the system also sends a train-ready message. In simple terms, the train is waiting in front of a red signal and the operator is telling the infrastructure manager: everything is ready; we want to depart.

By that point, the necessary information has already been communicated.

The infrastructure manager responds to these messages. If the information is not accepted, the user can be warned before the train departs and act immediately.

Most of the time, the response is positive. But rail operations need to be prepared for exceptions. A train could be canceled shortly before departure, or a message could contain information that does not match what the infrastructure manager expects.

The value of real-time communication is that the operator can respond while there is still time to correct the situation.

Knowing where the train is

Once the train departs, information from the infrastructure manager can be processed automatically.

The operator can follow the progress of the train and see when it departs, passes certain points or arrives at a station. This information can also be used to inform customers, depending on the agreed service.

Consider a train traveling from Venlo to the Port of Rotterdam.

The customer or terminal could be informed when the train passes Venlo, Eindhoven or Tilburg. Based on that information, the receiving operation can estimate the arrival time and adjust its own planning.

Cranes, employees, terminal capacity and connecting transport can be prepared more effectively.

This is where information becomes more than an internal record. It becomes an operational advantage across the logistics chain.

When I started at Ab Ovo, this level of train-running information was not available in the same way. RCS has continued to evolve as data availability, customer expectations and industry interfaces have developed.

Today, the arrival of a train can also trigger financial processes. If a train departs with twenty wagons and the customer’s agreement is based on those twenty wagons, the completed order can move automatically into the financial domain and be prepared for invoicing.

Depending on the agreement, invoices may then be generated daily, weekly or monthly.

The connection between operation and finance reduces duplicate work and helps ensure that the invoice reflects what actually happened.

Connecting cargo operations and planning

RCS can also work together with planning solutions such as RCP or APS.

The appropriate setup depends on the type and size of the customer’s operation. A company transporting single wagons, for example, needs to reserve capacity for individual wagons on specific trains.

That process resembles booking a passenger journey with multiple connections. The wagon must be assigned to the correct trains and moved through the network toward its destination.

The transport order can be created in RCS and sent to the planning solution. The planners or optimization system determine how the wagon should travel and return that plan to RCS.

The customer may then receive an expected arrival time, provided the relevant information is available across the route.

The same principle applies to train planning. Trains may be received directly from the infrastructure manager or from another Ab Ovo planning solution. Drivers and locomotives can be planned in the appropriate environment, while RCS uses that information for the production and cargo processes.

Not every customer needs the same level of advanced planning. The architecture should fit the business rather than forcing every organization into an identical model.

When something goes wrong

Rail freight is complex, and not every transport continues exactly as planned.

Imagine that a wagon develops a defect during its journey. The problem could be identified by an external monitoring system, such as a heat detector, or by someone inspecting the train during a stop.

The wagon may need to be removed from the train and parked on a track.

The defect can be registered in RCS, including photographs. This can be done through an application or directly within the system. The relevant broker can be informed automatically, and the train can continue without the defective wagon.

For every wagon under the operator’s control, RCS maintains a history of events.

The system can show that the wagon was moved from one track to another, when the defect was detected, when it was repaired, which order it was serving and when it was handed over to another railway undertaking.

That history can support invoicing, reporting and data warehouse processes.

However, the system does not decide what should happen to the wagon.

A person must determine whether the cargo should be transferred to another wagon, whether the wagon can be repaired at its current location or whether it should continue on a later train.

This distinction is important.

Software provides information and supports the consequences of the decision. It can update the transport, create new documents, assign the wagon to another train and inform the customer.

But responsibility remains with the people running the operation.

That is how I believe technology should work: not replacing human judgment, but giving people the information and tools required to make better decisions.

Making rail easier to use

Rail freight competes with road transport, inland shipping and other modes.

For customers, working with rail can still be complicated. They may need to request empty wagons, organize loading and provide a considerable amount of information. By comparison, a truck may arrive at the customer’s location with a driver who actively supports part of the loading process.

Railway companies therefore need to make their services as accessible as possible.

The easier it is to order a transport, follow its progress, understand the costs and receive accurate information, the stronger the competitive position of rail becomes.

Technology cannot remove every physical or regulatory complexity from railway transport. But it can prevent those complexities from becoming unnecessary administrative burdens for the customer.

Better information can become a competitive advantage.

Transparent pricing and preventing revenue loss

Another area where railway companies can simplify the customer experience is pricing.

A transport may have a basic price, while additional invoices are created for activities such as shunting, placing wagons or preparing consignment notes. Some of these activities are unavoidable parts of delivering the transport.

When standard activities are invoiced separately, the customer may receive several invoices for what they experience as one service. That makes prices harder to understand and compare.

It also creates administrative work for the railway company. Every separately billed service has to be registered and invoiced. When an activity is forgotten, the result is revenue loss.

My personal view is that standard activities should generally be included in a transparent transport price.

When the customer requests something genuinely additional, it should of course be invoiced. If a defective wagon must be removed, an extra locomotive is required or an unexpected repair must be organized, those are additional services.

But when a train runs from A to B every day and the same standard handling is always required, combining those elements into a clear transport price can make life easier for everyone.

RCS can support both approaches. The system can invoice many different kinds of services and can use registered events to identify when activities have taken place.

But the fact that a system can produce five separate invoices does not mean that five invoices create the best customer experience.

Technology should support the commercial strategy. It should not determine it.

The future is not about removing people

When people discuss automation, they sometimes imagine a future in which humans are removed from the operation.

That is not the future I am working toward.

People will remain essential in rail freight. They understand the context, manage relationships, deal with exceptions and take responsibility for decisions that a system should not make independently.

What we should reduce is unnecessary human handling.

People should not spend hours copying information between systems, checking attachments that are irrelevant to them or manually creating messages that can be generated from reliable data.

Ordering should become more digital. Information should be delivered automatically or made available through online services. Customers and partners should retrieve the information they need when they need it, rather than receiving large quantities of data that may not be relevant.

The result is not a railway without people.

It is a railway in which people can focus on work that genuinely needs them.

Think like a transport company

After years of working in logistics, rail operations and software, I have developed one strong personal belief.

Railway companies should think of themselves less as railway companies and more as transport companies.

Customers are not buying a train movement for its own sake. They are buying the reliable movement of goods from one place to another.

The railway is the means by which the service is delivered. The customer cares about predictability, transparency, cost, information and ease of doing business.

That is where RCS and our work at Ab Ovo can contribute.

We connect the commercial agreement to the transport order, the train operation, the wagon movements, the customer information and the invoice. We help customers examine their processes and challenge habits that no longer create value.

But the most important part of the work remains the relationship.

Technology keeps evolving. Interfaces change. Regulations change. Customer expectations change. New functions are introduced and existing processes are improved.

Trust is what makes that continuous evolution possible.

When customers know they can call you with a problem, when you can challenge their process without damaging the relationship and when both organizations are working toward the same outcome, software becomes more than a product.

It becomes part of a shared journey.

And in rail logistics, the destination should always be clear: safer operations, better information, less unnecessary handling and a transport service that is easier for customers to use.