How small business should integrate with 3PL

If you’re tired of all the marketing spin and confusion that surrounds the topic, this paper is a MUST read for you.

It will provide you with a simple plain English understanding of how smaller businesses and SMBs that outsource their warehousing and fulfillment to 3PLs, should be thinking about integration with their own ERP / WMS. We will also explore where EDI (electronic data interchange) fits into the mix.

Assumptions: You (a business, aka “shipper”) already use some sort of “business software” that includes Inventory, Warehouse, & Order Management. If any of these systems are not already integrated with Accounting and CRM (or E-Commerce), we highly recommend you read the following Q&A (www.bizautomation.com/Q&A) and get familiar with the concept of “core vs non-core modules”.

3PL refers to 3rd party logistics which can also mean, 3rd party warehouse, outsourced warehouse, and 3rd party fulfillment.

There’s a chasm that all smaller businesses must cross when using 3PL to outsource their fulfillment / warehouses – “Integration”. It’s confusing to say the least. Depending on how you approach it, it can also be very expensive.

Why Integration is imperative

First, let’s talk about why integration is important – One of the disadvantages of our souring your warehousing (as I’m sure you know) is the disconnect between your inventory and that of the 3PLs because by definition it’s no longer in your control as 3PLs use their own WMS to manage all the inventory levels for all the customers they manage. This means that when you create a new Sales Order, which naturally places inventory on allocation (aka “committed”), in order to release that allocation which you have to do if you want to clear the asset value from your books, you have to figure out WHEN that 3PL ships product out (assuming you’ve emailed them a report that triggers this process somehow). This is why you’ll eventually have to figure out how to integrate with your 3PL’s WMS. Sure you can do it manually as most 3PLs provide email alerts from their WMS that provide this information, but eventually you’ll start to realize how the costs of doing it manually are prohibitive. So yes eventually you’ll be asking “how can I integrate this”. Here’s what you’ll be faced with.

Approach 1Integration using an API (Application Protocol Interface): This is usually preferred by the 3PL because it “locks” you into their solution as APIs are Software Application Specific. It’s also expensive because writing integration between your WMS and theirs requires “code”. So now you’ll need to hire someone to do this. Unless you’re a software company, this takes you way outside your expertise and will be expensive. If you want to know more about how APIs work, particularly in light of EDI, read this article.

GradeF If you have to foot the bill for custom integration. It’s also a bad idea due to vendor “lock-in”. or

If one or more customer / vendor requires you use EDI (EDI in the the formal sense). We’re talking about trading X12 documents here which is pretty much the only standard U.S. trading partners use -the kind of EDI imposed by companies such as Walmart and Ingram Micro.

 GradeB+ If your WMS already integrates properly (this is a loaded statement. There are multiple workflow and functions that are assumed here) with the WMS of the 3PL (EDI integration does not count. See next approach for details on this) and you don’t plan to use other 3PLs with different WMS systems.

Approach 2 Integration via EDI: More established 3PLs will have integration with EDI networks, and may suggest you use EDI to accomplish your integration objectives as an alternative to the API approach (but only if you plan to use EDI for other supply chain processes). Here’s how that works. They’ll recommend their own EDI MSP (managed service provider), which is understandable, as they have more experience with them, plus as a partner EDI companies will provide commissions to any partner that brings it new business. Whichever EDI MSP you ultimately choose, it will either already have integration with your own business systems (which indirectly means you should be able to quickly connect to your 3PL’s WMS) otherwise you’ll be building the integration yourself (a total non-starter that nobody should contemplate). But wait there’s more. Assuming you’re all integrated via EDI, now you can expect to pay for each document you trade with your 3PL per document (unless the EDI company charges a per order fee, which they might). There’s the “Shipment Release” document (called a 940 in EDI parlance), which requires its own confirmation document (997 in EDI speak) in return which may or may not require a fee. There’s the “Shipment release confirmation” document (aka “856” in EDI speak) which you have to confirm receiving with another 997.  If you want to learn about the differences between EDIs and APIs, click here.

 GradeD if your WMS already integrates with an EDI network. Bad idea because it increases the cost of each order, which can be a big deal if your per order profit is small. If it wasn’t, we’re assuming you wouldn’t be using 3PL in the first place.

 GradeF if it does not already integrate (Really REALLY bad idea if on top of ongoing costs, you have to pay for an EDI integration project. Yuk).

 Approach 3WMS worker at your 3PL handles your account: They can be trained to use your WMS (only possible if your WMS is cloud based). This isn’t something a small shipper is likely to be offered because clearly there is overhead for the 3PL so it may come with additional expenses. Under this model the 3PL is essentially outsourcing their employee to you. Typically, you add a new                  subscription on your WMS to let which they access to perform all “warehouse guy” functions as if your warehouse was on premise.

 Grade B if your WMS is cloud based and you can negotiate a sweet deal for this service from your 3PL. Lack of integration is a double edge sword because on one hand it’s nice to not have to deal with integration in the first place but on another, all you’ve really done is shift the inefficiency of double system work from your business to that of the 3PL, which is actually not as bad because they now have    access to data from both systems without the need for email exchanges and phone calls. Also, you’re paying for a fraction of a 1099 employee, which can be cost effective. But still, there’s no free lunch, and double system work is still inefficient which ultimately means more cost.   

Approach 4Your WMS trades XML across ALL supply chain functions with the 3PL. This is the ONLY approach we at BizAutomation use (contact us for a demo), because it’s the best and has the fewest if any drawbacks. This assumes you’ve picked a 3PL that has the the ability to handle XML document trading (if they don’t, find one that does. This is a required tool of the trade these days. We wouldn’t recommend any 3PL without this capability. This approach trumps all others because it’s portable (no 3PL lock-in, so you can negotiate with them as needed), it’s inexpensive (unlike EDI, there is little to no cost to trade such documents unless you have high volume requirements), it’s convertible if you DO need EDI on the front-end. XML can be converted to EDI by an EDI MSP you use to interface with trading partners that require it (can’t do that with the API approach), and it’s secure (encryption transporting XML is well understood via SFTP and the like).

GradeA+ By far the preferred approach for all the reasons mentioned. There will be setup costs, and additional monthly costs, but these will pale in comparison to the costs of actual EDI. 

Is your business living in connector hell ?

They’re held up as the magic elixir, a technology to cure all ills, the mighty “Connector”. “Don’t worry” the salesman will tell you. Our solution integrates into that solution, we have a “Connector”. But what exactly is a “Connector” and is it all that those polished salesy types make it out to be ?

A connector is a clever way of exchanging data over the web between two systems. In that regard it is a way of integrating software, but here’s where the average business owner ends up getting head faked, because integration as defined by the use of a connector, is really the process of making a copy of that data, and sending it over the web to another app which then neatly inserts it into its database – all behind the scenes absent any manual intervention. In other words, a connector is a way of automating the duplication and pasting of data that you’d normally have to do manually when running two systems.

This BTW is  absolutely awsome (as someone that remembers what it was like before that was possible). But even an awsome technology like this can be over used and miss applied. Penecilian was and continues to be an awsome discovery, but prescribe it for everything that ills us, and soon it ends up doing more harm than good. What’s that saying about too much of a good thing ends up being bad for you ?

Consider that small business lives in a world dominated not just by QuickBooks, but by the very technology legacy its success has cemented into the minds of business owners everywhere. It’s now considered established wisdom that small business must revolve (statistically this is true in 80% of SBs out there BTW) around QuickBooks or some financial point package at the hub surrounded by other systems such as CRM and E-Commerce. And unlike 10 years ago, today’s businesses know they must be a connected enterprise to compete (“cloudy” is all the rage). So if that’s true, isn’t a connector just what the doctor ordered ? Well yes, in some cases, and absolutely no in others. Keep reading, the plot thickens !

How connectors are getting miss applied ?

So let’s say your every small business USA selling widgets, and you started running on QuickBooks years ago, and later added a connected WMS and Order Management system. Maybe you sell online and added a Big Commerce store, and then listed on Amazon. Youv’e extolled the virtues of CRM and love what SalesForce.com has done for your sales staff – also connected. You’ve grown a bit and realized, like many, that there are efficiency gains to be realized by outsourcing your non-local logistics to 3PLs (just like the Fortune 500s). Then out of the blue Walmart or some other big customer approves you as a vendor, but like many big customers these days, they’ll not email POs, and you can’t email their A/P department an invoice, everything has to move around EDI.

Like that proverbial frog in the pan of warming water, your business has gradually entered connector hell.  So what’s happening ? Look at the following illustration, and the end result is self evident.

In these examples we see that core systems from the QuickBooks stack needs to use connectors to duplicate required data with other core systems, as compared to the BizAutomation example. The lesson ? While all these data should be integrated (no argument there), the integration technology used to integrate them is crucial, because while there is no other option other than to use connectors between core and non-core systems, in-between core systems, the use of them becomes a huge efficiency drain. How you ask ?. Let me answer a hypothetical question with just a few short questions every widget selling business needs to ask of their business systems, and the answer will become self evident. BTW – I can come up with dozens of these “gotcha” questions, so don’t think this is the extent of them.

1. BigCommerce, like any self respecting e-commerce app has cart abandonment logic which gives you access to leads that never became customers because they never clicked “Submit Order”. The data can be used to follow-up or remarket to that lead. Since clearly you have to connect customers and orders to QuickBooks, where do the prospects go ? Do you connect them to SalesForce or QuickBooks ? Before you answer, what good is a Prospect from BigCommerce without knowledge of the items they almost purchased. I don’t know the answer either (In BizAutomation this one is a no brainer).

2. SalesForce.com like many CRMs has very slick web to lead forms, so you can get leads from your web site, in order to apply sales opportunities through the pipeline into (hopefully) a customer. So congratulations, you’ve now converted a lead into a customer. Why are they a customer ? because they’re going to buy what you sell. So where is that data (Some SalesForce editions support items) and were are you connecting it to, the Order Mgt system, QuickBooks, both ? Ok, probably the Order Mgt system. So now you create the order to adjust warehouse levels, which then should connect back to QuickBooks to perform Invoicing duties. Whoops the customer made a mistake. They wanted 5 Red Widgets not 3 Green ones, and they’re changing the ship-to so you need to update the FedEx ground rates, and shipping labels. Which of the “now 3 apps with the same data” should you update, so it cascade updates the other 2 (don’t ask me, I’m confused too) ? 

3. How are you going to handle global reporting ?

4. How about workflow automation, across all core systems ?

Etc..., Etc... Etc.... Let it be said once and for all, that yes, QuickBooks, and SalesForce, and all the BIG, HUGE even software companies have established the standard by which most small business revolves - namely, around disconnected core apps that are connected using automated duplication (good for the solution partner ecosystems), we've just proven it's not the ideal for small business.