The Process We Thought We Understood

When a client approached us about building a logistics management system, it initially looked like a fairly typical software project. The company was growing, its processes were becoming more complex, and the tools that had worked for years were starting to limit further growth.

Most operations were managed through Excel spreadsheets. Schedules, transportation, external partners, deliveries and coordination between different stages of the process. Everything worked largely because the people responsible for operations knew exactly what they were doing. But as the business grew, managing all those dependencies became increasingly difficult. A planning mistake could mean more than additional work. It could lead to expensive changes in transportation and logistics.

Our job was to move those processes into a proper system, organize them and build something that would support the company's continued growth. What we didn't realize at the time was that the biggest challenge wouldn't be writing the software. It would be discovering how the business we were supposed to automate actually worked.

The Process Everyone Knew

We started the way many similar projects begin: talking to the client, analyzing existing tools, gathering requirements and mapping business processes. The people responsible for operations explained their daily work, what information they needed and how decisions were made. At that point, everything seemed relatively logical. We had activities, sequences, dependencies and rules that needed to be translated into software. Based on that understanding, we designed the first solutions and started development.

And then the exceptions started appearing. First, a small case requiring a minor adjustment. Then another one involving a special situation. Shortly afterwards, we discovered that a previously agreed rule shouldn't apply under certain conditions. Sometimes a new exception required us to change logic we had implemented just a few days earlier. Interestingly, this wasn't because the client had deliberately left requirements out. Very often, they simply hadn't remembered them.

For people performing those processes every day, many of these situations were completely natural. They knew that under specific circumstances something had to be handled differently because that was how they had always done it. Only when the software required an explicit rule did someone ask why things worked that way in the first place. And suddenly, the real process turned out to be much more complicated than the one we had documented during our initial workshops.

When An Exception Gets Its Own Exception

For a while, we tried to handle everything as it came. The client reported a new case, we analyzed it and adjusted the system's logic. That's a normal part of software development, especially when dealing with complex business processes. The problem was that eventually we started finding contradictions between requirements. Some rules were supposed to apply everywhere, except in particular situations. Then those exceptions turned out to have exceptions of their own. The more accurately we reproduced the existing process, the more complicated the system became.

At some point, we began questioning whether all those rules really needed to exist. If the process had evolved for years around spreadsheets, perhaps some of its complexity came from the limitations of those tools rather than actual business requirements. Maybe certain activities were performed manually only because there had never been a better way. Maybe some exceptions had been created to solve problems that no longer existed. And perhaps a few rules weren't really business rules at all, just habits developed by the people doing the work.

We started to realize that moving the entire process into a new system wouldn't necessarily improve it. We could end up building a much more expensive and complicated version of Excel.

We Paused Development

We were roughly halfway through development when we agreed with the client that we needed to pause implementation and revisit the requirements. It wasn't the most convenient decision. We already had working code, implemented solutions and a plan for the remaining work. Continuing development and adding more rules would have been the easier option. But we were becoming less confident that all those rules should exist in the first place.

So we went through the business processes again, this time with a completely different perspective. During the first workshops, we had mainly asked how the process worked. Now we started asking why it worked that way. Why did this particular case require special handling? Where did that rule come from? What would happen if we removed it? Did the original problem it was supposed to solve still exist?

Our approach was somewhat similar to the Five Whys technique, where you keep asking questions instead of accepting the first explanation, trying to reach the root cause of a problem. Rather than accepting "because we've always done it this way," we wanted to understand why that way of working had emerged at all. And that was when things started getting really interesting.

Not Every Exception Had To Survive

Thanks to everything we had learned during development, our conversations with the client became much more specific. We now had real examples of problematic cases, understood which requirements contradicted each other and could see how individual rules affected the rest of the process. Some exceptions were genuinely necessary. They reflected real operational constraints and absolutely needed to be supported by the system.

But others could be eliminated. Not by ignoring requirements, but by simplifying the underlying process together with the client. Understanding why a particular rule existed sometimes allowed us to find a better approach that removed the need for that rule altogether. That was an important shift in how we thought about the project. We stopped treating the existing process as something that had to be reproduced exactly and started using it as a starting point for designing a better way of working.

Software gave us possibilities that hadn't existed before. There was no reason to recreate every limitation of spreadsheets and manual coordination. As a result, we didn't just clarify the requirements. Together with the client, we simplified parts of the business process itself.

The First Version Had To Prove It Worked

When we returned to development, we had much more confidence in the direction we were taking. But another challenge remained: how could we safely verify that the system actually worked? Logistics isn't exactly the best place to experiment with live operations. Incorrect planning can generate significant costs, particularly when transportation, schedules and external partners are involved. Even if the application performed well in testing, we didn't want to replace the existing way of working overnight.

Once we had a usable first version, we suggested running the processes in parallel for a while. The existing spreadsheets remained the basis for daily operations, while the new system processed the same cases, allowing us to compare the results. That gave us something extremely valuable: the ability to verify the system using real operational data without putting the business at unnecessary risk.

Over time, we started seeing very few discrepancies, and the system was increasingly reflecting how operations actually worked. The client could see that the solution was beginning to deliver what they needed. That was an important moment because confidence in the new system was no longer based only on what the development team promised. It was based on comparing its results with reality.

From Reproducing The Process To Automating It

Only after we had enough confidence in the core processes could we start automating them further. And that distinction mattered. At the beginning, we were primarily trying to translate the existing way of working into software. After revisiting the requirements, simplifying some rules and validating the first version, we were ready to go further.

It was no longer just about replacing spreadsheets with a new interface. It was about reducing manual work, improving coordination and creating a system that would allow the organization to handle a growing scale of operations without a proportional increase in operational complexity. That's where technology starts making a real difference to the business. Not when it perfectly reproduces everything people used to do, but when it allows them to do it better.

Not All Process Knowledge Lives In Documentation

What I find particularly interesting about this project is that the initial requirements weren't simply poorly prepared. Both we and the client were working with the knowledge available at the time. Development gradually revealed details that had been hidden in people's daily routines for years. Some rules were so natural to them that nobody thought they were worth mentioning. Others seemed essential until we started asking why they existed.

This shows one of the limitations of traditional requirements analysis. We can run excellent workshops, produce detailed documentation and draw accurate diagrams, yet still fail to discover everything before implementation begins. That doesn't make analysis unnecessary. It means we should treat it as something we can return to as our understanding improves.

And sometimes we need to be willing to tell the client that instead of implementing yet another exception, we should first sit down together and decide whether that exception is needed at all.

Final Thoughts

Looking back, I don't remember this project primarily as building an ERP system. I remember it as a project where development forced us to understand the business better, and that better understanding allowed us to build a simpler system.

We could have continued implementing exceptions indefinitely, gradually making the solution more and more complicated. Instead, we paused, went back to the client and questioned some of the rules we had previously accepted as obvious. Not every problem could have been predicted at the beginning, and not every exception could be removed. But the knowledge we gained during development allowed us to make much better decisions than we could have made when the project started.

If I were starting a similar project today, I would still spend plenty of time understanding the business processes. But I wouldn't assume that completing the initial analysis meant we knew everything. Sometimes it's only when you start building the system that you discover how the process you're trying to automate actually works.

Sometimes the best thing you can do for a new system is to simplify the business process it is supposed to support before automating it.