Most organizations don’t set out to design their future warehouse and transportation network around software.
Yet that’s exactly what can happen during an S/4HANA transformation.
The ERP program gains momentum, and design workshops begin. Decisions need to be made about EWM, TM, integrations, reporting, and site deployments. Before long, teams find themselves debating system architecture, deployment models, and configuration options without first agreeing on a more important question:
How does the business need to operate in the future?
That’s a problem because warehouses, transportation networks, inventory flows, and labor processes don’t operate in technology silos. They are part of a connected operation that must execute every single day.
When supply chain leaders start with the operation rather than the technology, the roadmap vision becomes clearer. Decisions about S/4HANA, EWM, and TM become a lot easier because they’re based on defined business requirements instead of assumptions.
The Technology Roadmap is Not the Same as the Operational Roadmap
One of the most common issues we see in large SAP programs is that the technology roadmap gets built before the operational roadmap. The implementation team begins evaluating what the future SAP environment could look like while imperative questions are still unanswered.
These questions matter because they shape the operation that SAP is ultimately expected to support. When those answers aren’t clear, organizations often recreate today’s environment in new technology. The software changes, but the operation and the operational problems do not.
That is rarely where the biggest transformation value comes from.
S/4HANA Creates an Opportunity to Rethink the Operation
For many organizations, S/4HANA is the largest supply chain transformation initiative they have undertaken in years, if not ever.
That makes it tempting to focus on migration plans, timelines, and technical requirements. But supply chain leaders should view the project as an opportunity to step back and evaluate how the business needs to run moving forward.
The goal shouldn’t simply be to move existing warehouse and transformation processes into a new SAP environment. The goal should be to determine which processes still make sense, which need improvement, and which exist only because of historical limitations.
That’s a very different conversation. It’s also where the most valuable decisions are made.
EWM Decisions Should Follow Operational Requirements
Organizations often approach EWM by asking what functionality they need. We believe a better place to start is understanding what the warehouse is expected to accomplish.
A facility shipping a few thousand orders per day has very different operational requirements than a highly automated distribution center supporting multiple channels, aggressive service commitments, and complex inventory flows. Likewise, a network of facilities rarely operates with the same level of complexity across every location.
Some sites may require sophisticated capabilities and deep integration with automation systems. Others may need a simpler operating model designed around consistency and ease of adoption.
The answer is not found in a software feature list; it is found by understanding how each operation works today and how it needs to work in the future.
TM Planning Starts on the Warehouse Floor
Transportation planning is often treated as a separate workstream. Operationally, it isn’t.
Transportation decisions influence picking priorities, staging activities, loading schedules, dock utilization, and carrier performance. At the same time, warehouse execution directly impacts whether transportation plans succeed or fail.
When these functions are planned independently, gaps emerge. When they are planned together, organizations gain a better understanding of where information, timing, ownership, and exceptions move across the operation.
That’s why transportation strategy should be developed alongside warehouse strategy, not after it.
Start with Four Questions
Before making major logistics technology decisions, we encourage organizations to evaluate every process, requirement, integration, and workaround through four simple questions.
Should we keep it? Does it still support where the business is going?
Should we change it? Is the requirement still valid even if the process isn’t?
Should we migrate it? Is it a critical business capability regardless of the technology supporting it?
Should we redesign it? Does it exist only because of historical limitations or legacy system constraints?
These questions shift the conversation away from replicating the past and toward designing a better future operation.
Build the Technology Roadmap from What the Operation Needs
Once the future-state operation is clearly defined, the technology roadmap becomes much easier to build.
Requirements for EWM, TM, labor management, automation integration, reporting, sequencing, and site rollout strategies all start to emerge naturally.
Instead of debating technology options in isolation, teams can evaluate them against a defined set of operational objectives.
That’s a much stronger foundation for decision-making.
It’s also how organizations avoid carrying years of legacy complexity into their next-generation SAP environment.
Your SAP Roadmap Should Start in the Operation
The most successful SAP transformations aren’t driven by software decisions. They’re driven by operational clarity.
Before deciding how EWM should be deployed, how TM should be integrated, or how sites should be rolled out, organizations need a clear understanding of how the business will operate over the next three to five years.
At Open Sky Group, this is where we start.
Our team works with organizations to evaluate current operations, recommend what should be kept, changed, migrated, or redesigned, and build a roadmap that connects business goals to technology decisions. Because when the operation leads, the technology roadmap becomes far easier to justify, execute, and sustain.
Planning an S/4HANA, EWM, or TM transformation? Talk to Open Sky Group about building the operational roadmap before the implementation roadmap.
