Nirab Kumar, Vice President, Digital Transformation at Odyssey Logistics, leading AI-driven supply chain innovation.
I have been through enough transformations to recognize the ones that change how you think, and this one changed everything. Eighteen months into a transformation program, every dashboard was green. The steering committee was satisfied. The operations team was furious. Sitting in that review, I realized something every executive eventually learns: Program health and business health are not the same thing.
Modernization is not about replacing software; it’s about rebuilding the operating system of the business. After more than 18 years leading technology and transformation programs across transportation and logistics, I have learned that every modernization effort looks unique on the surface. Underneath, they fail and succeed for remarkably similar reasons. I have inherited programs midstream, launched new ones and watched many transformation initiatives quietly die. I used to believe that if you picked the right platform and funded it properly, the rest would follow. Now, I know exactly how wrong that was.
How These Programs Always Begin
When a leadership team decides their transportation management system (TMS) needs to change, the conversation almost always goes the same way. Which platforms are available? What do analysts say? Who else has done this? None of these questions matter when no one has documented what the system is actually doing or what replacing it will cost in money and time.
A TMS is the operational spine of a freight moving enterprise. Order management, carrier selection, tendering, route optimization, tracking, billing, customer visibility—everything runs through it or connects to it. When you replace it without understanding the workflows it supports, you do not transform anything. You move the same broken operations onto newer infrastructure and spend years wondering why nothing changed. Upgrading operating systems without upgrading the way we operate does not lead to real transformation.
The pressure to layer AI on top or in between makes this worse. AI is a multiplier. Applied to a clean foundation, it accelerates performance. On a fragmented one, it finds every flaw you have been managing around and scales them faster than any team can respond. AI serves as a mirror, revealing an organization’s readiness, data discipline, processes and culture. AI doesn’t fix operational weaknesses—it exposes them. Poor master data becomes poor predictions. Inconsistent processes become inconsistent automation. Fragmented systems become fragmented intelligence. AI is less a solution than a stress test for organizational maturity.
What The Programs Actually Looked Like
A Foundation Left Unexamined
The first time I stepped into a modernization program midstream, the platform had already been selected. What had not yet been done was to map what already existed. There were overlapping systems, API layers built by people who had long since left, custom middleware nobody understood and master data scattered across systems that did not communicate.
We spent the first year discovering what we had inherited, not modernizing it. But every program I’ve watched skip that step has ended up back at it a year later, at avoidable cost.
We Built Intelligence On Top Of Ignorance
Later, I owned an effort to introduce AI-driven decisioning into freight operations. The business case made perfect sense on paper, while everything underneath it quietly fell apart. Carrier data lived in one system, customer data in another, pricing logic in spreadsheets that predated everyone on the team.
Integration complexity consumed most of our engineering capacity before a single model could be deployed. Our most experienced dispatcher had started keeping a parallel spreadsheet. She never voiced her doubts about what we had built, but when I finally found out and asked how long she’d been keeping it, she said, “Since the second week.” And we were already seven months in.
We Automated The Wrong Workflows
In another program, pressure to show quick wins led us to automate workflows before they had been redesigned. The automation worked perfectly, and the exception rate climbed anyway. Flaws that operators had quietly absorbed through judgment were now generating failures at machine speed. We spent months in exception management that would not have existed if we had slowed down first.
Measuring Success Differently And Calling It Progress
Technology tracked go-live dates and feature launches, while operations measured tender acceptance, carrier performance and touchless transactions. Both teams reported progress, yet the business stood still because we had never aligned on what success truly meant. Looking back, that was the question we should have asked from Day 1.
Key Takeaways For Leaders
Here is what I wish someone had told me years ago:
• Audit before you architect: Map what you actually have before selecting anything new. What is load-bearing? What is redundant? Where is master data governed and where is it quietly a mess? This work does not appear in any vendor demo. It determines whether everything that follows actually lands.
• Data governance starts in the C-suite: Assign executive ownership for critical data. Without clean, governed carrier, customer, location and pricing data, AI initiatives will underperform long before leadership recognizes the problem.
• Respect the sequence: Govern data first, consolidate platforms next, redesign and automate workflows, then layer AI. Every transformation that skips these steps eventually returns to them, at greater cost and with diminished confidence.
• Build one shared scorecard: Define success in business terms from Day 1 and hold both technology and operations accountable to the same metrics. If your program looks good on a status deck but has not changed how operations teams actually work, the people on the ground already know it. The question is how long before leadership does?
• Be honest about the timeline: True ecosystem transformation takes three to five years. Executives who protect the foundational phases from pressure to move faster are the ones who finish with something the business actually uses.
Conclusion
I still think about that dispatcher. She had found a way to do her job despite the system we had spent months building around her. I wonder how many people in programs going live right now are doing the same thing—opening a spreadsheet, building a work-around and quietly starting over.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?