I received an email today from a customer who had been speaking to a fellow web storeowner about integration. Their conversation went some thing like this, I meet someone at a trade show who said they could integrate my web store to my back end ERP or 3PL, that was back in the spring, sounded good, cheap price, they still have not delivered and I found out they had out sourced the work to some southeast Asian country. Turns out the guy they hired got sick and almost died. So here we are 6 months later and I have nothing. Christmas is coming and I am desparate. The customer mentioned to me that the description mirrored what he had heard from other web store owners who were trying to get their shopping carts properly integrated to either their 3PL or their ERP. Is this the integration nightmare before Christmas?
That got me thinking, perhaps a blog article was in order. An article that laid out some of the key issues.
All in all integrating a shopping cart to an in-house ERP package or 3PL sounds like a relatively simple exercise until you actually get into it. The devil is in the details and that is why integration costs money. If people tell you they can do it for cheap, they don’t know what they are doing or you are going to get very limited functionality. The cheaper the cost the less functionality you get or the more template driven the solution is. That may work in many circumstances but from what we have seen it doesn’t take a successful business long to out grow that model.
So lets go through the process. I am going to take Magento as a shopping cart as we were recently certified as an Industry Partner by Magento.
Magneto has an API (application Program Interface). By talking to the API through web services I can ask the Magento platform to deliver me the sales order data. That data comes down in an XML file. Ok, so the first step is to setup the API calls to pull orders down. A programmer will tell you its easy until they actually have to do it.
Now that I have the order I will need to translate the order into the format that my 3PL or ERP will accept. Here in lies some of the details that I alluded to earlier. I will examine both processes. This is where the programmer has difficulties.
The first issue for ERP integration is the customer. Why you say? Unless the customer is a repeat customer, the customer data is not in the ERP. I need to get the customer data into the ERP before I can import the order. Sound simple enough right? The next issue we will encounter are the product codes. Unless I am using the same product codes on my web store I will have to translate the web store item code to the equivalent item code in my ERP. That means a cross-reference table that will have to be maintained. This now means that when I do the translation from one format to another I will have to ensure that I get the correct code into the file that will be imported.
Once these issues have been worked out the data should flow. So the order is now in the ERP. You pick pack and ship and now want to provide the shipment tracking information back up to the web store. Provides for a complete customer experience. This part is not too hard but it does require that I extract data from the ERP and move it up to the web store using the API.
The 3PL process is very similar however I have other issues I need to deal with. A 3PL only cares about the customer data because they have to ship the product out to the customer. Accuracy is important. What they are concerned with is the ship method and what product they have to ship. If the web store uses different ship methods (FEDEX Ground, UPS Air etc.) and the product codes are different then I need to maintain cross-reference tables for this data. There is also the very simple matter of translating from one format to another and ensuring data completeness.
Once all these logistical data issues are out of the way we have the nasty little rat of bad data that we have to contend with. Rats, as we all know, are pesky little rodents. What is bad data? Well bad data can manifest itself in many ways, the most obvious is an incorrect zip code, an incorrect state or province or a discontinued product. Bad data causes down stream issues that have to be dealt with. Think of the human process, something doesn’t make sense when you get an order, you make a decision on how to handle that delinquent piece of information. A computer system needs to be told how to handle these exceptions and that’s where the devil in the details resides. So if you are looking for a cheap solution you probably won’t get much int he way of reporting or support around data related issues. Why? Very simply they are expensive to deal with.
If you get more than 25 orders a day, then integration is important, necessary and the issues I have outlined need to be thought through. What I have found over the years is web store developers make varying degrees of API functionality available. Not all shopping carts are the same. ERP packages are no different. 3PLs and fulfillment houses fall into the same group it all depends on what they themselves use internally to run their businesses. It’s all over the place.
The bottom line is if you want to do integration properly then seek out experts, people who know supply chain data integration. Don’t rely on a contract programmer or even the design agency, and better yet don’t rely on someone who spins a good yarn. Sorry, to say most have no clue about supply chain data integration and you end up with what they think is proper integration. Would you risk your business?
Take a read of our e-books for some thoughts and ideas that will help you.