How to Navigate Connectors (and Make Your Ecommerce Systems Play Nice Together)
Ecommerce directors have to make a lot of big decisions. This is especially true when your company is planning to launch a new site or replatform your old ecommerce system. In Command C Insights, we talk a lot about ecommerce platforms, as well as the systems required for successful backend operations, such as ERP (enterprise resource planning) software. Both sides of the equation are critical – and they are interdependent on one another.
Once you’ve chosen your platform, and defined your systems for inventory management, accounting, warehouse communications and more, you still have another major decision: How will all of our systems communicate together?
The answer lies in determining the best approach for unifying these systems through a connector. Let us explain.
What systems need to connect in your ecommerce business?
When we use the phrase “connector,” we’re talking about communicating information between the frontend of your ecommerce site and its backend operations. Sometimes this happens directly to a single ERP. But other times, we’re connecting to multiple operations systems.
In talking about employing a connector, we’re looking at how to pass information via a piece of middleware (software) between systems for things like:
- Inventory management and product data, including product photos, descriptions, variant information, etc.
- Customer data. This information is often in a CRM (customer relationship management) tool and may funnel into another system, such as email marketing software. Sometimes this is all in one system, but other times retailers distribute it over several different systems. For instance, your customer data may be in Netsuite as your ERP, and in Salesforce as your CRM, and in Mailchimp for email marketing. All of these various systems should have the same customer data.
- Other operational data and functions: orders, accounting, purchasing, warehouse management, fulfillment, and marketing.
This short list reflects the major functionality behind ecommerce, but there could be other things depending on how you structure your business.
The other part of the equation is what we’re connecting these systems to: sales channels. First of all, there’s your ecommerce store on Shopify or Magento or another platform. Then there are third-parties that provide retail sales channels, such as Amazon, Walmart, or Rakuten. Further, you may still sell through a physical retail store (or stores).
Connectors allow your operations system, however it is composed, to transfer data back and forth between itself and each of your sales channels, whichever they may be.
Connectors Help Prevent Inventory Overselling
One of the most compelling reasons for retailers to use a connector is for inventory syncing. Specifically, connectors can solve the challenge of overselling. For example, if your company sells in two different Shopify stores and three retail stores, and does not use an ERP as a single source to manage the availability of your products, you run the risk of overselling.
Imagine: Your business starts the day with 100 items for sale across various channels. Then you sell 50 items in the physical retail store, 50 in Amazon, and 50 in Shopify. Without a central source for that data, your business oversold by 50 units. This will create a lot of confusion and frustration for your operations team – and disappointment for your customers.
Connectors Create a Single Source of Truth for Data
Additionally, your business systems should talk to one another in order to create a single order fulfillment process, regardless of channel. A connector can help unify all the data which, by definition, is a little bit different in every place that it lives. In other words, your data looks a little different in Shopify, than it does in Amazon, than it does in the retail store.
But if your business uses a connector, all of the data gets translated into the format that the ERP (or other operations system) needs. Now your operations team can work with the data, from the backend, as though it were uniform.
In essence, having a connector is ultimately about automating tasks that people would have to do if you didn’t make the data uniform through a connector. Running data through a connector makes sure that all the systems have the same information. In this process, you’ve assigned a single source of truth (as much as that’s possible) for that information.
What Are the Different Types of Connectors?
1) Bundled ERP/Ecommerce
Generally-speaking, there are three main categories of connectors. The first kind is onboard ecommerce. For example, let’s say you use Netsuite for your back office operations and SuiteCommerce on the frontend. SuiteCommerce is the ecommerce solution that comes bundled with Netsuite. (Salesforce has a similar offering.) There is no challenge in connecting these two systems; they are already connected.
The pitfall here is you are limited to the capabilities that the onboard platform gives you. These can be powerful systems, but depending on your needs and budget, it may not be the right solution. We often caution retailers on using the ecommerce platform that’s bundled with their ERP, just because it’s bundled. Simply put, that’s not enough of a compelling reason to choose this solution. Merchants should undergo a technical discovery process to make sure it truly meets their needs from frontend to backend. Most importantly, you want to ensure that it provides a great customer experience that aligns with your brand and customers’ expectations for UX and features.
2) Middleware
The second type of solution is middleware. (This is also our most frequent recommendation.) Middleware is a piece of software that works between two other established pieces of software. The most common middleware is a SaaS connector, so software as a service or platform as a service.
It’s web-based software that someone else owns, and your company pays a subscription for it. They build and maintain it. It usually has an API and/or preset workflows and things you can do with it. You’re limited to what they tell you it can do. Usually they work with a bunch of different providers, including, on the ecommerce side, Shopify, BigCommerce, Walmart, and Amazon, among many others. On the ERP side, they will work with Netsuite, Brightpearl, Microsoft Dynamics, Salesforce, etc.
They’ve already done the work of forging the connection, and should maintain those connections through various platform and API upgrades, giving you one less technology concern for which to assume responsibility. There’s an entire team of people whose job it is to keep this running. As a retailer, you’re not responsible for it. So, you’re getting a big leg up because you have documentation and a support team to turn to if you run into problems.
3) Custom solution
In the third scenario, your development team builds a custom connector (still a piece of middleware) to unify the systems in your specific business. The common application for a custom solution is when a retailer’s ERP was built in-house. The retailer may not be able or willing to change the old ERP, so developers have to create a unique way to translate the ERP’s information to communicate with other systems.
For instance, imagine you’re a retailer on Magento 1. You’re planning to upgrade to Magento 2 soon, but in the meantime, you have a lot of orders coming in. In addition to your outdated ecommerce platform, your third-party fulfillment software is no longer working with M1. In this case, we would write middleware that listens for an order to be placed in Magento, and then translates that data into the format that the 3PL requires. Otherwise, the retailer would have to translate that data by hand. They’d also be responsible for regular transmission of the data to the provider, error – resolution, callback requests such as shipment tracking info – all of this is a monumental task.
Regardless of the Connector You Choose, You’ll Need a Data Map
Keep in mind that as your company embarks on your connector plan, you’ll need to create a map for your data. (This is also known as a field map.) This middleware basically takes data in one format and maps it into a different format. It’s like a translator. (It sounds simple, but as we know, simple things are always complex in ecommerce.)
For instance, when you ship an item out of the warehouse, and you put the tracking number into the ERP, that tracking number should go to the middleware. The middleware translates it into the format that Shopify is expecting. It then sends it on to Shopify, so Shopify can tell the customer that the item has shipped. This kind of functionality requires data mapping to ensure that data is correctly interpreted throughout the process. Another good example of this are product bundles or kits. Does the bundle exist as a single entity within your ERP, but multiple entities in the ecommerce platform, or vice versa? If so, then the middleware will need to split the product data on the way into the ecommerce platform from the ERP and combine it on the way out of the ecommerce platform as an order line item.
How to Move Forward
A lot of brick and mortar retailers are beginning to explore ecommerce more seriously, especially in light of physical store closings amid the coronavirus. If this is your situation – you already have operations systems up and running and you’re adding ecommerce now – you want to identify the simplest way to get from A to B. In most cases, this is probably through using SaaS middleware. You’ve already established your operations as they need to be; this is not the time to overhaul operations just to make it work better with your ecommerce platform.
On the other hand, let’s say you’re starting something brand new. You have never connected your ecommerce platform to an ERP before. In this case, it’s really valuable to do a technical discovery. The tech discovery process will help you determine the ideal system to build for your business.
In both cases, you’re starting with the operations aspect. Then you’ll decide on your ecommerce platform and think about how they go together. Your connector is driven by your two end points. It’s all about making systems talk with one another.