How to build a smarter WMS implementation

Editor’s note: Sreekumar Somasundaram is a senior supply chain technical program manager at AWS. This article and its content was created prior to his current position with AWS.

Implementing a warehouse management system (WMS) is a complex project that demands careful planning, precise execution, and thorough attention to detail. This article outlines key considerations and best practices for successful WMS implementation, from vendor selection through post-implementation optimization. Drawing from real-world experience, we explore critical factors that can make or break a WMS project.

Strategic vendor selection: Beyond market rankings

A successful WMS implementation begins with selecting a product that precisely aligns with your organizational needs. While the vendor selection process involves multiple factors, this article highlights the most crucial element: evaluating how different WMS solutions address your specific operational requirements.

Success in vendor selection demands three critical components: deep understanding of WMS functionality, strong relationships with your organization’s warehouse process owners, and comprehensive knowledge of operational complexities and current system limitations. The evaluation team must possess this expertise to make an informed decision. The most effective approach involves conducting detailed stakeholder workshops to document process owner inputs systematically, map existing (as-is) processes, and capture system complexities and pain points comprehensively.

Consider this scenario: During a picking operation, an operator needs to retrieve a carton buried beneath others in a pallet. The process requires removing top cartons, accessing the system suggested carton, and replacing the moved items. Such complex scenarios, often handled through customization in legacy systems, require particular attention during vendor evaluation. While modern WMS platforms offer greater flexibility, it's essential to thoroughly document and present these complex requirements during the RFP process.

Any WMS can manage standard operations like basic receiving or put-away. The evaluation should instead focus on organization-specific processes that deviate from standard operations, nuanced requirements unique to your business, and complex scenarios requiring specialized solutions. Remember: WMS vendors design their products for diverse global customers, meaning not all requirements might be met out-of-the-box.

Success depends on highlighting nuanced requirements during vendor discussions and requesting demonstrations specifically tailored to your warehouse operations. Understanding how each vendor's product addresses your operational complexities is essential, as is evaluating vendors based on their ability to meet your specific needs rather than just their market reputation.

While market reports provide valuable context, the ultimate differentiator should be how effectively a vendor's WMS handles your organization's unique requirements, alongside considerations of cost and service quality.

Test cases: The blueprint for implementation success

The foundation of any successful WMS implementation lies in thorough test case development. While detailed requirements are essential, developing solutions based solely on requirements proves insufficient. Consider this sample requirement: "Ability to receive against PO and ASN by capturing item, quantity, condition of goods, serial number, handling unit. Ability to record overage and shortages." Such requirements typically outline system expectations without delving into detailed process steps or indicating actual warehouse floor operations.

A test case documents the complete end-to-end process and all possible variations, providing warehouse operations teams insight into new system behavior while serving as a baseline for the WMS technical implementation team to ensure solutions and configurations meet expected outcomes. The test case document should be developed alongside detailed requirements collection, and subsequent design and solution building must be based on both requirements and test cases. While some detailed test case steps might not be known until the design phase, capturing different flows and process steps is crucial, even without complete system navigation details.

For instance in a receiving process the different test cases would look like:

The test case steps and expected output would specify system validation of the PO, prompting for handling unit scanning, and successful completion messages. This detailed test case structure captures the multitude of variations possible during PO receiving on the warehouse floor, each requiring specific documentation of expected outcomes. While requirements might comprehensively list functionalities, they do not capture the granular system behavior needed for each scenario. For instance, without thorough test cases, implementation teams might build a system that handles basic pallet or carton receiving but overlooks scenarios like receiving unpacked loose products. Even when requirements capture these variations, they rarely specify how scanning procedures would differ across scenarios or what specific system responses should occur at each step. Test cases bridge this critical gap by documenting not just ‘what’ the system should do, but exactly ‘how’ it should behave in every possible scenario and provides the opportunity to close any gaps between the warehouse operations and WMS implementation team. For instance, when reviewing these test cases with warehouse operations process owners, important system behaviors become apparent. For example, the operations team might discover that after receiving, a background job must run to generate put-away tasks. These system nuances rarely surface during the requirements phase, making clear communication about system behavior crucial for expectation alignment.

The implementation process involves crucial two-way communication. Requirements and warehouse processes knowledge comes from operational process owners to the WMS IT implementation team, who then translate these into detailed system requirements and test cases. This translated information must flow back to process owners for validation, ensuring business requirements are correctly interpreted, system capabilities meet expectations, and potential gaps are identified early. This cyclical validation process, completed before detailed configuration work begins, forms the cornerstone of successful WMS implementation.

WMS-TMS-ERP integration requirements

WMS serves as an execution system, driven by signals from various enterprise systems. The integration landscape typically centers around ERP systems and transportation management systems (TMS), transmitting information between each other. For instance, purchase orders originating in ERP systems trigger receiving processes in WMS, while demand signals flow into WMS through sales orders from ERP. The WMS, in turn, generates shipping confirmation signals back to ERP, enabling order closure and initiation of accounting cycles.

During the requirements collection and design phase, identifying and documenting all potential integration requirements becomes crucial. However, the real challenge lies not in implementing straightforward integrations but in handling change management and revision scenarios. Consider a situation where a sales order created in ERP and transmitted to WMS undergoes a cancellation after picking has already commenced in the warehouse. Such scenarios demand clear documentation and careful consideration during design and solution development. While standard integration paths are relatively straightforward to implement, these exception scenarios and change management requirements often get overlooked, potentially leading to significant operational disruptions if not properly addressed.

Managing user training and learning curves

The transition from legacy systems to new WMS implementations presents a significant challenge in terms of user adaptation, particularly for RF mobile device operators. Years of muscle memory and unconscious actions in the legacy system can make the transition to new transaction patterns particularly challenging. Operators who have developed intuitive responses to specific key combinations must now consciously relearn these patterns, potentially impacting operational efficiency during the transition period.

For example, operators might be accustomed to using specific side buttons on RF scan guns for transaction completion in their legacy system. When these same buttons serve different functions in the new system, the risk of errors increases substantially, potentially affecting operational efficiency. While mirroring legacy keystrokes in the new system might seem like an ideal solution, it's not always technically feasible.

The most effective approach combines multiple rounds of pre-go-live training with realistic expectations about initial operational slowdowns. Implementation teams and warehouse process owners should anticipate and plan for reduced efficiency during the transition period. Setting clear performance metrics to monitor improvement trends becomes essential, allowing management to identify areas requiring additional training or support. This proactive approach to managing the learning curve helps ensure a smoother transition while maintaining operational stability during the critical implementation period.

Migration strategy: Developing a robust cutover plan

In most WMS implementations, organizations transition from a legacy system to a new one, making a graceful migration critical to minimize operational disruption. This transition is particularly challenging because warehouses typically cannot cease operations or halt shipping during the process.

The migration must encompass various critical elements:

• Current inventory snapshot
• Open orders in process
• Master data, including:
  • Part numbers
  • Customer information
  • Supplier information

To illustrate the complexity, consider a scenario where an organization plans to decommission its legacy WMS on a specific date and launch the new system. The cutover must account for multiple order states, such as:

• Orders picked but not shipped
• Orders shipped but not financially closed
• Orders received but awaiting wave planning
• Orders wave planned but not picked

Rather than executing the cutover directly in production, the optimal approach is to conduct thorough system integration testing (SIT) cycles that precisely mirror the production cutover. This involves copying all open orders and master data from the existing production environment to the new WMS test environment, followed by comprehensive testing.

Organizations should perform this complete testing cycle at least twice before attempting the production cutover. Different organizations face varying levels of complexity, and if two iterations don't demonstrate a smooth transition in testing, additional iterations should be conducted until achieving the desired results.

A problematic cutover from a legacy to a new WMS in production can create significant operational disruptions from day one. Given that operators will naturally work more slowly with a new system, any initial issues can compound quickly, potentially leading to severe operational impacts.

Performance testing

A WMS consists of two major components:

1. Desktop-based application
2. RF (radio frequency) scan gun software

While performance testing is crucial for all enterprise applications, it is particularly critical for WMS due to its real-time warehouse floor operations. Multiple operators simultaneously use RF mobile devices that communicate with the application server, making response time a crucial factor.

Performance validation should be conducted using production-equivalent data, which ties back to the cutover strategy. This involves:

• Importing production data volumes into the test environment
• Generating RF transactions that simulate actual production scenarios
• Executing these transactions to validate performance metrics

For example, in directed put-away operations, when an operator scans a pallet barcode, the system must:

• Execute through put-away strategies and rules
• Generate a put-away suggestion
• Complete this process within seconds

This rapid response time is essential because operators cannot afford to wait for extended periods while the system processes their scan. They need immediate system feedback to maintain operational efficiency. Therefore, optimizing RF transaction performance and minimizing latency is fundamental to any successful WMS implementation.

Scalability: Designing for future growth

Generally, WMS implementations are started with a warehouse that has the lowest volume to reduce the risk. But what could be missed is the technical solution, which performs very well with the launch warehouse’s volume, as we deploy the same solution to a warehouse that processes large amounts of data, resulting in the solution failin. Though the launch might be on a smaller volume warehouse, all technical solution design must be based on the largest volume warehouse or consider future volumes to ensure that it can handle the scale.

Post-implementation success: A phased approach to optimization

While WMS projects are driven by specific business objectives—whether modernizing an outdated system or improving operational efficiency—determining the appropriate scope for the initial launch is crucial.

The initial implementation typically involves numerous complex elements such as new system integration, TMS and ERP connectivity, operator training and adaptation, label printing setup, and parcel system integration. Given these complexities, the initial pilot launch should focus solely on implementing the system successfully while maintaining current operations. Maintaining existing warehouse KPIs during this transition should be considered a success, as it indicates the new system hasn't negatively impacted operations—this establishes your foundational stage.

Only after achieving stability in these areas should you consider implementing operational efficiencies, introducing process improvements, and exploring advanced features. It's crucial to avoid simultaneously introducing both a new system and operational process changes, as this compounds complexity. The initial pilot launch should minimize process changes and focus primarily on system implementation. Subsequent phases can then concentrate on optimizing operations once users are comfortable with the new system and integrations are running smoothly.

Conclusion

Successful WMS implementation requires a balanced approach that considers technical requirements, operational needs, and human factors. While the journey from legacy to new WMS presents numerous challenges, following these established best practices can significantly improve implementation outcomes. Remember that initial stability takes precedence over immediate optimization—build a solid foundation first, then incrementally enhance capabilities to realize the full potential of your WMS investment. This methodical approach, combined with careful attention to the elements discussed above, will help ensure your WMS implementation delivers lasting value to your organization.

About the author:

Sreekumar Somasundaram is a senior supply chain technical program manager at AWS, specializing in warehouse and transportation management systems implementation. With over 18 years of experience, he has been involved in developing and implementing logistics technology solutions across complex business environments. A mechanical engineering graduate with multiple professional certifications including Project Management Professional (PMP), Java and Oracle Programming, Transportation Management, and Supply Chain certifications from MITx, he brings a unique combination of technical expertise and business acumen to his role. His extensive background encompasses logistics solutions architecture, business analysis, and software development for warehouse and transportation systems. Throughout his career, he has successfully led WMS and TMS implementations for multiple Fortune 500 companies.

SC
MR