By Jason Murray, CEO of Shipium
Early in my 19-year Amazon career, a preferred framework for continuous improvement along the supply chain emerged. Operators and decision makers followed the framework as the basis for the step-wise improvements Amazon made in its supply chain approach.
The idea went something like this:
Now with the fix in place, circle back to point number one to gather information to help identify the next problem to address. The cycle provided the kind of actionable ecommerce supply chain analytics for us to evolve and improve.
Once started, this circular process created a flywheel where projects were in flight at every stage, and injecting resources at any stage would have a positive impact on speed, cost, complexity, and efficiency.
It was critical to split out manual fixes versus automation.
Premature optimization is a bad thing. Jumping immediately to a solution that automates and scales often caused more harm than good because the exact set of ideas to automate may not be an exact fit.
Let me share an example.
At Amazon we anchored on the idea of a “promise” to the customer. If a customer placed an order and was told she would get the delivery next Thursday, the package better get there next Thursday. Doesn’t matter the cost because a good experience would keep her loyalty.
The promise became an object in the supply chain system which flowed throughout the rest of the fulfillment process.
Using the framework described above, we identified a few cost and efficiency issues in our ability to profitably keep a promise.
But we jumped to automation a bit too soon on one project. We thought that pre-selecting the shipping method up stream at the moment of purchase would create efficiencies downstream: If we had a “known constant” then programmatic decision making downstream would be easier and faster. We built automation technology around this idea.
The opposite ended up happening. It turns out that selecting the carrier method should be a “just-in-time” step as the very last thing the system does before a label is printed and package shipped. This is for a few reasons:
If we would have implemented a manual step first, we would have identified the progress of the solution and seen an iteration was needed. Instead, we had technology investments that now needed to be changed.
Always consider manual implementations of solutions before eventual automation and scale.
The virtuous cycle described above is not necessarily novel to Amazon. It shares similar ideas related to engineering feedback loops or Lean Startup methodologies, among others. But a key insight for us in the ecommerce supply chain domain was the importance of data. Without data, it was impossible to kickstart the flywheel because we wouldn’t have the best intelligence to make strategic decisions. Continuous improvement without data is like throwing darts while blindfolded. It’s impossible to understand what is the highest priority problem to solve. And even if luck causes the right project to be picked, it’s difficult to understand if the solution implemented is performing well and should be automated.
If I could lend one point of view to other supply chain leaders based on my experience, it’s to understand the power but also the place of data. No doubt data has its uses throughout the supply chain, but in today’s state of supply chains, it is the most powerful when used as a diagnostic tool. Tools like SONAR help give the data signals required for strong intelligence.
Continuous improvement is always preceded by continuously understanding the best problems to solve.