As a retailer, it may be easy to think you can set and forget your tech stack. Can't you just buy out-of-the-box solutions that will automatically sync with each other? While this is absolutely the state that software integrations are moving toward, we do not yet live in a world where it’s entirely hands-off. If you neglect to vet the architecture of your tech stack, you'll encounter easily avoidable problems.
We're sharing this story with the permission of our client. They're excited to share what they've learned, so you can learn from their experience.
Our client needed a way to manage their shipping integrations. They bought a plugin, but this plugin didn't connect with their Enterprise Resource Planning (ERP) System, Odoo. Only after examining the root issue did they find that they masked the problem with a plugin that ultimately resulted in dividing their systems, creating manual processes, and duplicate data, resulting in tech debt.
Imagine your data is following step-by-step directions like Google Maps. You start at the sale and it tells you a great set of directions to get from step 1) sale to step 2) sales confirmation. From the sale confirmation order, you then move to step 3) the production orders, where it tells everybody what to do. And from there you move to step 4) delivery. Then delivery will say, "Oh yeah, I came from this manufacturing order, which came from this sale, which came from this e-commerce platform." However, just as you're reaching the final step—shipping—the directions just say, "Guess how to connect shipping."
This was the disconnect for our clients: shipping. The shipping solution was not talking to the other systems, and the result was a usable set of data only up to the point a product was completed, ultimately disabling the company’s ability to run full order-to-cash analysis because that crucial final link was missing.
As it turned out, our client was unaware that they weren’t using the shipping integration to the extent that it was capable—namely creating a one-to-one relation between orders in Odoo and shipments in ShipStation. The shipping integration had the ability to create shipments in ShipStation from Odoo, and thereby establish a one-to-one link, but they used their existing shipment creation process that opted to have the orders generated directly from their e-commerce platforms with no pass-through of their ERP. This meant that there was no “unique key” linking the orders in Odoo and the shipments in ShipStation.
When they eventually wanted ShipStation to talk to Odoo upon every shipment to close deliveries, they found that ShipStation had no exact idea about which deliveries to mark as shipped based on the information available to them. A lack of one-to-one data relationships resulted in an impassable boundary for development (having to guess which shipment related to which order, requiring humans to make the final call), as well as dirty data that they couldn't use to forecast for the future.
When the data is not all in the same place or not properly related, you essentially don't have data at all. It's harder to query, there can be duplicates, or if people have been "matching" data, there's a tendency for error. Our clients had been guessing which orders matched which shipment, and that's no way to run a scalable business.
Workarounds are possible, of course. The order numbers will be the same and the product numbers will be the same, but consider the cases where order numbers are the same, or there are multiple returns from the same order, or an order is split up into two or more unique deliveries—things start to get very complicated very quickly.
The fix was to move to a different shipping solution that did integrate with Odoo out of the box and make generalizations about shipments in order to mark their corresponding orders in Odoo as shipped—really good guesses, but guesses nonetheless. In an ideal state, these two systems should be talking to each other, not to people!
Technology doesn't magically work, it has to be intentionally architected.
Technology doesn't magically work, it has to be intentionally architected. The most important decision you can make as a retailer to ensure the success of your tech stack is deciding on a single source of truth. Find out more about the steps to architecting your tech stack in this article.
Creating a single source of truth is vital, and that's an architectural decision. It's not hard, but it requires intentionality. You have to set up which system owns which data and make sure that you have the right data in the right place. Oftentimes, people don’t take that into consideration and end up with disparate systems and multiple sources of information.
It's tempting to try and one-to-one map what you currently do to software, immediately. You'll think, "Hey, we sell things, so let's get an e-commerce front like Shopify. Hey, we ship things, so let's get a shipping manager, like ShipStation." Then an ERP can often be an afterthought, where you think, "Now we need something to manage everything together." Really you should start with an ERP, and that should be your single source of truth from the onset.
When it comes to architecting (or upgrading) your tech stack, there are so many options to choose from and it's important to find one that not only meets your price point but also integrates with your other technologies. If you go for a quick, cheap solution, you'll likely pay for it later either in loss of data (and therefore loss of ability to analyze the past and optimize and plan for the future) or having to buy another system anyway. We created The Everyday Retail Blueprint to help retailers create and optimize their tech stack. If you're interested in automating your tech stack, reach out. We'd love to work with you.