1. The conventional challenges of WMS implementation
Resistance to change and limited user adoption
Often, users only become aware of a new WMS once it goes live.
Until that point, they’ve never seen the interface and have no idea what the system means for their day-to-day work.
In the early stages, the feelings of resistance and imposition can weigh heavily on productivity. A piece of software that isn’t widely adopted—even if it’s perfectly configured—will fail to deliver.
Change is gradual. Staff need time to grieve the loss of the old system before accepting the new one.
Recommendation: Communicate as broadly as possible and involve all users. Share regular updates on project progress. Encourage key users to act as ambassadors. These individuals are the operational link between the project team and front-line employees.
Integration challenges
Integrating WMS software with an ERP system is a topic that comes up regularly in pre-sales conversations.
Data-exchange rules aren’t always defined early on and sometimes emerge during acceptance testing, leading to delays, cost overruns, and technical trade-offs.
In today’s increasingly complex IT architectures, ERP and WMS systems are only part of the equation.
Numerous third-party systems also need to be considered, each with its own constraints for triggering orders, synchronizing stock data, managing statuses, and handling other flows. Failing to address these early on can create knock-on effects across the entire IT ecosystem.
Recommendation: Map all affected systems, even if only at a high level. A best-of-breed WMS can adapt to a wide range of environments, provided the integration scope is clearly defined upfront.
Organizations are increasingly using middleware to streamline data exchanges, apply management rules, and mediate between systems—supporting both reliable integration and long-term success.
Under-resourced projects
Many companies launch a WMS software consultation without ensuring the necessary resources are in place.
This is understandable since the priority is to keep the warehouse and daily operations running.
But this approach creates a vicious cycle: key users juggle competing priorities, validations are rushed or incomplete, and workshops drag on.
A WMS project requires time—not just from the vendor, but from the customer too. Teams need to be freed from everyday tasks so they can focus on testing, documenting, and making informed decisions. That time should be seen as an investment.
Recommendation: Plan resource availability at the scoping phase, formally allocating time and assigning responsibilities.
Poorly prepared operational data
Acceptance testing often reveals issues that should have been addressed early on, such as incomplete, outdated, or inaccurate data. These hurdles can turn the validation phase into a race against time.
Common warning signs include:
- Incomplete data: missing product attributes, “ghost” customers, outdated transport grids
- Partial business flow models: overlooked processes, undocumented exceptions
- Inadequate documentation: undocumented management rules, no centralized procedures
- Incomplete test sets: missing real-world use cases, underestimated volumes
For example, one Hardis Supply Chain customer failed to model an entire retail flow ahead of time. At go-live, this flow had to be urgently integrated into the WMS, interfaces had to be reconfigured, and test sets had to be rebuilt.
Having a technically mature WMS helped the customer recover, but the experience left a lasting impression. Properly mapping flows upfront could have avoided the stress.
Recommendation: Clean up data and document actual flows before the design phase. It may feel like wasted time, but it prevents weeks of emergency fixes and secures employee confidence in the new system.
2. Upstream strategic challenges
Requirements that emerge over time
Requirements aren’t always set in stone from the outset. They can evolve as the project progresses, shift depending on who you talk to, or even contradict each other as priorities change.
The result: costly back-and-forth, missed timelines, and discouraged teams.
Sometimes, projects are suspended or abandoned entirely.
The better you frame requirements upfront, the easier it is to make adjustments during design.
Recommendation: Focus on outcomes, not just the means of achieving them. Balance standard system features with operational requirements. Run internal workshops before engaging outside consultants.
Side note: Deploying an ERP system can be lengthy. Conversely, a WMS can typically be rolled out in about eight months. Prioritizing the WMS saves time, minimizes disruption and delivers results sooner.
This feedback from an SAP-Hardis WMS project might catch your attention.
Aligning IT, business, and sales teams across the board
It often happens that IT approves the architecture and operations sign off on the flows, only for sales to discover six months after go-live that the system doesn’t support co-packing—requiring a new module and lost commercial opportunities.
Different teams operate on different timelines.
While Sales focus on services and volumes over 6–18 months, IT prioritizes security and reliability over 10–15 years, while operations want a reliable, user-friendly system from day one.
Organizations often align IT and operations but neglect sales. When sales requirements emerge later, the technical groundwork is missing.
Recommendation: Bring IT, operations, and sales into the project from the scoping phase. Develop a common three-year vision, map future services, prioritize investments, and agree on what can be postponed. Hold regular reviews to stay aligned.
Should you start small with a less mature solution?
It might seem sensible to start with a simpler WMS. But 3 to 5 years later, organizations often face another costly project.
This is especially true for 3PLs, who need flexibility and advanced configuration from day one. Immature systems often result in numerous custom developments—costly, risky, and creating dependency.
Recommendation: Choose a mature WMS from the start, even for simple use cases. That way, you can scale without relaunching a new project.
3. Downstream strategic challenges
Choosing the right indicators
Tracking picks per hour or error rates can be useful, but these metrics alone aren’t enough.
Businesses often overlook key logistics indicators such as system lifespan (10–15 years), operator buy-in, IT autonomy, scalability and data quality—all of which affect competitiveness and the WMS ROI.
For instance, simply rolling out a more user-friendly system can boost staff retention, lowering hiring costs and stabilizing the workforce.
Optimization requires big-picture thinking, not just local metrics. That’s why holistic KPIs matter.
Recommendation: During scoping, agree on a comprehensive, ROI-focused evaluation method that combines project metrics, operational gains, security, and “soft” benefits like operator comfort.
Thinking continuous improvement
It’s tempting to see go-live as the finish line.
But external factors—fluctuating volumes, evolving services, and growing user demands—require constant adjustment.
At Hardis, we see WMS software as a performance driver—something built over time through hands-on use, experience, and iterative improvements.
Some customers start with standard features, then refine them later using real-world experience to prioritize the most useful changes.
Recommendation: Build continuous improvement into the run phase, challenging processes and increasing ROI over time.
“The way needs are expressed is always influenced by experience. That experience can help us look forward. But it can equally hold us back. It’s OK not to have everything in place at go-live. Sometimes, it’s best to start with the standard model then consider whether it meets all your needs, or whether you need to adjust processes or go down the customization route.” – Florian Sauvage
Recognizing that shadow IT can drive efficiencies
Almost every warehouse uses Excel spreadsheets to fill gaps in existing systems.
These “off-the-radar” tools—spreadsheets, Access databases, macros, shared documents—are common in every deployment project.
They’re part of what’s known as shadow IT: improvised workarounds that often meet needs faster and better than official systems.
Another example, one customer used Excel to extract orders, apply filters, group priorities, and launch waves—even though the system could handle these tasks natively. At first, it worked. Over time, it slowed the organization down.
The workaround became critical, creating issues:
- Maintenance depended on specific individuals
- Data was duplicated
- Risk of data loss increased
- Processes weren’t documented
Importantly, rolling out a WMS doesn’t mean starting from scratch. It’s better to map existing processes, estimate costs and make case-by-case decisions. Some processes can be absorbed by the WMS, others by the ERP, TMS, OMS, or PIM.
Shadow IT often operates under simple, informal rules and is frequently overlooked as a source of quick, lasting gains.
Recommendation: Ask the right questions and assign clear responsibility for each tool or system. Sometimes it’s easier to allocate a process to a non-specialized system than force it into the wrong one.
Conclusion
Turning a WMS into an enabler of lasting performance requires a robust strategic framework, a shared long–term vision, and standardized front-line processes. This is especially true of shadow IT, which is often seen as a problem when it can actually provide valuable business intelligence.
A WMS project extends well beyond implementation. Shifting requirements, immature systems, poor post-project management, and incomplete alignment among IT, business, and sales can all erode ROI.
Deploying warehouse management software is not a one-off project. It’s a 10–15 year investment. ROI builds over time:
- Operational quick wins: within 6 months
- Process optimization: over 6–18 months
- Strategic benefits: long term
A successful WMS project requires customers and vendors to share both credit for success and responsibility for setbacks.
Both sides need to work together, not in silos.
So before thinking about the system itself, start by assessing the maturity of your project management processes.