small business ERP

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 3^rd party logistics which can also mean, 3^rd party warehouse, outsourced warehouse, and 3^rd 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 1 – Integration 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.

Grade – F 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.

 Grade – B+ 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.

 Grade – D 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.

 Grade – F 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 3 – WMS 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 4 – Your 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).

Grade – A+ 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. 

Each has its place, make sure you know which is appropriate for your requirements.

There are many paths available when seeking to integrate multiple systems, but at the forefront of it all is ROI, it’s all that matters, so let’s explore the EDI vs API approach to integration.

At BizAutomation our philosophy is crystal clear. Integrate only “non-core” systems in order to minimize data duplication, manual entry, and complexity. So for example, Accounting and CRM are core, inventory is core, they should all be part of a suite on the same database (which benefits from all the goodness of data sharing, referential integrity), so there’s always a single version of the truth (e.g. a single customer record shared across all the modules that can use the data). But if you want to get shipping rates from FedEx, that’s non-core because FedEx rates originate at FedEx, not your business system.

When it comes time to integrate with 3^rd party non-core data, there seems to be a controversy in some circles about using an API vs EDI to get the job done. Some miss-informed articles  even make it sound as if API is the next version of EDI, but these two are intended for completely different purposes, so what you’re really doing is comparing apples and oranges. Don’t beleive anyone that makes it sound as if one is superior to the other. It would be like comparing a helicopter to an automobile simply because both are forms of transportation.

EDI is a specification that defines how two systems must exchange data electronically and (most importantly) universally, which means it’s going to be the same across every system that adherses to it. In the U.S. it’s governed by a protocal referred to as X12 which assigns specific numbers to documents (810 is an Invoice, 850 is a Purchase Order, 856 is a shipping confirmation document that informs the seller that a shipment has left the warehouse, and the list goes on). An 810 Invoice is going to contain a common denominator set of fields / codes that contain data expected within an invoice, such as line item name, description, etc… and it’s universal across all companies that integrate using it.  That’s right, if you’re sending Walmart, or Target, or whomever an invoice via EDI, the item name, description, qty, and other elements typical of an invoice, are going to be exactly the same because they’ll confirm to the X12 EDI standard.

An API on the other hand is not universal. It’s software application specific, and even the code used is not specific (there are JSON, XML, and other ways of describing the data). This means that if you want to send invoice data via API, then you have to know the software system used by the company sending / receiving it and code specifically to it. SO while an API is way more flexible, it’s ideal for custom integration between two software applications (which according to BizAutomation should not be “core” modules). Another advantage is that you typically don’t have to connect directly to the application without going through a 3^rd party “hub” that interprets the preferences of one of the 2 sides exchanging data (If you do, then each hub will be requiring different API integration from you). Yes, that 810 EDI Invoice has data that comes from the same ingredients, but Walmart might want an SKU, and Target might not, this is where these EDI MSPs play a role, particularly with the big box retailers because they already know what they want in terms of mapping, making things plug n play. This also means that once  you integrate with an application’s API you’re highly dependant on that application and can’t transfer the integration work to another application (or API hub) without rewriting the code.

Now, if EVERYONE used the same app to run their business, there would be no need for EDI because you’d just code to a single API and call it a day, but this isn’t how the real world works. And that’s why EDI is key for its role.

Now do you see why the comparison makes no sense ?.

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. 

It’s one of the most confusing topics you’ll find on the web. From the moment you find out you need EDI and begin your Google, Bing, and YouTube research, you’re more likely to come away confounded with frustration, with more questions than when you started.

I was faced with the same task, and as an ERP and small business expert with a horizontal technology background, you’d think this stuff would come easy to me, but that only made it more frustrating when I realized I wasn’t getting it. Then I realized… that’s how the the industry makes its money. It’s submission through obfuscation. Kind of like taxes. At the end of the day, chances are you’ll throw up your hands and just pay “whatever” it takes. 

Firstly, I’m going to assume that you know you need EDI. If you’re weighing the options of EDI vs API or anything along those lines, read my EDI vs API article where I conclude that it’s not a competition, as each technology is designed for different purposes. Secondly, I’m going assume that you’re looking to integrate EDI with your business systems. I’m also going to assume that as a business owner you’ve figured out that integrating non-core modules is only going to land you in data hairball hell, and if you’ve still not figured that out and are jumping to EDI, you have foundational problems you may not even be aware of, and will be seeking to compound them by looking to integrate EDI on that technology stack. Rather than reading on, instead you need to read my article (or what the video) about WHY you should only integrate “non-core” functions into your business system then come back to this article. BTW Core refers to the functions provided by apps that share common data that you can run within your business, such as Accounting, e-commerce, and CRM, where as Non-Core refers to services you can’t run on your business system, such as FedEx shipping rates, Credit Card processing,, etc.. these you have to “connect” to over the web. Lastly, if you outsource your warehousing / shipping to a 3PL, read my article about “How small business should integrate with 3PL” first.  Oh and BTW, if you sell in North America, you’re going to use X12 EDI over AS2 or SFTP (AS2 is rather pricey but might be required by the trading partner, SFTP is not).

So then, you’re a small business and need EDI. Let’s get one thing strait right off the bat. If you type EDI in any keyword phrase into Google, you’re going to probably land on one of the managed service provider pages from companies such as TrueCommerce (they own HighJump), SPS Commerce, Covelent Networks, and B2Bgateway (there are many more). These are EDI MSPs that have experience providing the Walmart’s of the world with data from companies such as BizAutomation that integrate with them, exactly the way they want it. You’re going to use one of them for the same reason you wouldn’t bother doing your own taxes (if you have complicated taxes). Not worth the hassle because they provide a huge ROI (you can thank competition for that).

How EDI and ERP should work together

I looked at some competitors that provide ERP software to figure out what we should be doing, and found that big players like NetSuite and Sage have a ton of solution app “partners” who will happily sell you their middle-ware for extracting and inserting data into these ERPs in order to transport that data to one of those EDI MSPs. Why NetSuite, Sage, and others don’t provide this directly to their subscribers ? Probably because these “partners” provide them with lots of leads, but you’ll have to ask them yourself. At BizAutomation you’ll find no such cronies partnerships. We integrate directly to a single EDI-MSP (based on their library of maps, and experience with the retail network, developer support, and end customer pricing flexibility). We selected “True-Commerce”.

So here’s how workflow should happen, within a typical transaction.

1. Initial Sales Order trigger:

  A. You manually create the Sales Order or

  B. Walmart issues a Purchase Order electronically for 100 widgets in which case BizAutomation automatically creates a Sales Order for “Walmart”.

2. This places product on allocation. It also will automatically confirm receiving the PO from Walmart in the background (All customers using EDI will require this).  Workflow automation updates “EDI Status”, “Order Status”, and “Order Source”, so you can easily track and separate all new open EDI from non-EDI sourced orders.

3. Once you’ve reviewed the order to make sure you have product to ship (3PLs can be incorporated into this but the process varys slightly), you’ll set a value on your order status that will automatically email your warehouse people with an alert that tells them it’s to ship out the order. When they do, order status changes to “Shipped” which triggers allocation release, which impacts accounting asset values, and workflow that automatically sends Walmart a shipping notice of the order. They respond by sending a confirmation that they received it, and everyone waits for the shipment to be received by Walmart.

4. When you send Walmart (or whomever) the invoice will depend on the business terms (They may need to first send you a “Shipment Received” notice), but in any event, you’ll eventually need to invoice them, which you can do by changing the value on the order status, which triggers workflow to issue the invoice to Walmart (which they confirm receiving with a confirmation note).

Needless to say, there are many moving parts, and this is with a totally integrated business system like BizAutomation working in concert with TrueCommerce for EDI. Adding more tiers to this technology stack (e.g. separate Accounting and Order mgt, or another middle-tier integrator) is just going to make things more prone to problems and increases longer term expense.

Pricing

If you create a low number of sales order per month with a trading partner (e.g. Walmart) ? Skip integration all together, it’s not worth the hassle. Use one of the portals that True Commerce or SPS Commerce offers for $99 to $199 per month, and manually enter the orders, and update order status in BizAutomation accordingly and call it a day.

If you absolutely need to integrate EDI with BizAutomation, know that there are one time, and recurring costs that will need to be included in your budget.

One time costs - These will vary depending on the number of trading partners, and what those trading partners require of you (ask 2 or 3 of them for their requirements documentation and you’ll see the variations I’m talking about). Both TrueCommerce and BizAutomation will be included in setting up this environment based on your trading partner requirements. If one trading partner requires an AS2 connection (instead of SFTP for example) there’s additional cost.

Ongoing costs – TrueCommerce charges a per document fee which. A typical set of documents within a single order would include the PO coming in from the trading partner called the 850, the confirmation response (997 which typically is free), the Ship confirmation 856, and the Invoice 810. So that’s 3 documents per Sale Order which will incur a fee.