Nearly every day we see another story about the demise of retail due to over-building, over-leveraging, and the rise of omni-channel. Many companies with established supply chains complain that e-commerce cannot be profitable and that competition with Amazon on their home turf is a fool’s errand, but there are a few other stories behind the anxiety. One point that has been lost (or ignored) in all the recent talk of “investing in price”, supplier squeezing, and reactive e-commerce M&A activity is that many retailers and third-party logistics providers are simply unprepared for e-commerce-driven piece picking both technologically and operationally, often having relegated small parcel shipments to workstation-driven exception lanes. Whether your company is considering an upgrade of your current parcel process or a new implementation of shipping software, it is important to start with the understanding that parcel shipping is very complex and business-critical in the new retail landscape, not an exception process. Shipping speed and packing quality reflect more on a brand now, which means effective shipping software might be a key factor in your business’ performance in the next decade. Keep reading to learn five high-level strategies to minimize common risks and challenges in shipping software implementation.
Don’t oversimplify your requirements
It is convenient to assume that shipping software just sends addresses and weights to the carrier and the boxes show up at a customer’s door. The reality is that multi-carrier shipping software considers a multitude of compliance rules and regulations, in addition to managing all your package data in a manner that improves operational efficiency, avoids carrier fines, and maintains data integrity in your WMS. If you haven’t changed your parcel shipping process in a while, it can also be easy to assume that you don’t have a lot of business logic built around your current system. Making this assumption is a huge risk to the project from the get-go as it will likely lead to underestimating project effort and complexity.
An example to watch out for is carrier rating and compliance. If you ship with more than one carrier, you probably have unseen logic built into your host system, WMS, TMS, or current shipping software that determines which carrier is most favorable or necessary for certain accounts and destinations. Even more risky is the scenario where all of your business rules are manually managed by the shipping office. Carrier selection and rate shopping complexity can be a huge cost variable during implementation if it comes up as a change request rather than selection criteria. Make sure you fully understand the current decision points in your process before you ask for proposals to avoid surprises.
Document the current state; Design the future state
Your future state after implementation might be similar to your current state, but it cannot be exactly the same. Carrier capabilities and standards have improved dramatically over the years, enabling your operation to integrate more tightly and for your brand to delight customers through seamless tracking visibility and carrier interactions. Due to the seismic technological shift of the last ten years, your team should avoid gathering requirements and selection criteria based solely on your legacy processes. What efficiencies could you gain if you had 10x better transaction speed, real-time carrier rating, and more control over labeling? Would you switch to pre-pick manifesting or add more automation? Could you re-allocate FTEs to more value-added tasks?
Your future state after implementation might be similar to your current state, but it cannot be exactly the same. Due to the seismic technological shift of the last ten years, your team should avoid gathering requirements and selection criteria based solely on your legacy processes.
The reality we frequently see is that keeping the status quo can come at a higher cost than adjusting to use new functionalities due to carrier compliance updates and modernized integration approaches. If your previous shipping software used socket or table-to-table integration, you might be hesitant to use the “black box” web service integrations of the latest generation, but it could be costly not to embrace that paradigm shift once your business requirements are real-time and your communication is still asynchronous or single-threaded.
You will also likely find that some of your field mapping has been deprecated or that your label formats are no longer grandfathered in. Carriers typically maintain backwards compatibility for several years, but carrier-certified shipping software will be expected to comply with the latest standards. In addition, shipping software from a decade ago sometimes managed concepts such as multi-piece shipments and manifest closing very inefficiently, leading to excessively manual end of day and consolidation processes that can now be automated. Think about what your business needs to get to the next level and brainstorm with your peers about what-if solutions for current operational hurdles. A good systems integrator can help determine what is feasible within your budget and work with you to categorize Phase I and II requirements. Just remember to share your wish lists up front to avoid scope and budget creep in the initial implementation phase.
Maintain open stakeholder communication
At this point you might still be thinking, “shipping software is just an IT system, right? Data goes in and shipping labels come out?” Unfortunately, there is a lot more to it than that. Issues like carrier service selections, service-level targets, and packaging are matters that frequently require the input of host system administrators, operations, sales, finance, and sometimes even 3PL clients, especially if a client is driving the project in the first place. Multiple functions might not be necessary during the selection process, but it is important to make sure that the integration is designed so internal and external stakeholders are getting the data they need (though not necessarily want) from the system, even if it requires deep dive meetings. The project sponsors and leaders must be decisive to avoid cross-functional decision paralysis, but this approach will avoid unnecessary UAT and go-live pain.
Regression test end-to-end, not just label printing
Previous sections have alluded to the many IT touch points of shipping software including: host systems, material handling, client billing, freight audit, and more. Thus, testing phases should include as many of those systems as possible. Data elements like reference fields, service condition flags, rate types, and units of measure need to flow smoothly from one system to another or you might find out about serious client billing, costing, or conveyor routing issues at go-live. Shipment confirmation messages and ASNs must be regression tested to make sure all fields required by your host systems and trading partners are included and decoded properly.
Partner with an experienced systems integrator, not a generic programming shop
If you’ve made it this far, hopefully you have gained an appreciation for the complexity of shipping software implementation and the potential consequences of oversimplification. A general development shop will only see interface mapping documents, not the business processes around the systems. An experienced systems integrator that knows your WMS and, in the best case, your shipping software can work with you to build more efficient operational processes and work in tandem with the vendor to troubleshoot issues.
Are you interested in speaking with our team about your shipping software project? Contact us today to find out how we can help you get the most out of your supply chain systems and processes.
- 5 Shipping Software Implementation Strategies to Minimize Risk - May 28, 2017
- How to Reset a Stuck JDA RedPrairie RF Gun - August 29, 2016
- 5 Ways WMS Can Help Your Mid-Sized Business - October 1, 2015
- Why Mobile Bluetooth Printers Won’t Work with JDA WMS - January 26, 2014
- Is the Java Process Hurting RedPrairie WMS Performance? - January 17, 2014
- RedPrairie WMS Discrete Performance and SQL Server - February 15, 2013
- Printer Management in RedPrairie Discrete WMS - January 29, 2013