Why bother with an OMS, I’ve already got an ERP?

Based on the above, it’s perhaps easy to ask “Well, why can’t my ERP do all that?”, and to a certain extent it is possible for an ERP, or the combination of an ERP and eCom platform, to cover some of the functions described. But the challenge should not be “can my ERP do this?”; it should be “is my ERP the right system to do this both today and in the future?” If all your experience is with an ERP, then it’s tempting to see it as the solution to all types of problems; in the words of Abraham Maslow, “If the only tool you have is a hammer, you tend to see every problem as a nail.” But an OMS should be seen as another tool in your belt – perhaps not right for every task, but certainly an option to be considered in the right circumstances.

So, what could be some of the reasons for using an OMS rather than an ERP or a commerce platform?

• In many businesses, the ERP which manages back-end functions around supply chain or finance is not the same solution managing customer-facing or in-store functions. A customer offer doesn’t care about these boundaries (e.g. click and collect needs to know inventory, which may be in the ERP, but the store systems are critical in enabling the pick-up process), so strategy should be driven firstly by customer experience, customer-focused use cases and value drivers, and only then should existing organizational or systemic constraints be considered. A modern OMS connects one or many customer-facing front ends via APIs or built-in apps to back-end supply chain & finance processes, acting as a reliable bridge between channels, stores, warehouses, ERPs, and more.
• Customer service – like above, the ERP is usually not the system which enables customer services’ call center tools. An OMS can easily integrate through enterprise APIs to whichever systems the call centers are using to reduce complexity and connect the customer journey.
• Returns – returns are a huge cost driver for virtually all D2C businesses, and many resort to implementing a specific returns solution separate to their channels and/or ERP. Whilst this can enable more customer functionality, it is often at the expense of being able to tie the returns flow directly in with the outward fulfillment, often making the customer journey disjointed. An OMS enables retailers to automate and coordinate the return process to decrease cycle times and handling costs – all while simplifying the customer journey.
• ERP order fulfillment flows are typically more aligned to an order to cash process, driven by a limited number of customers ordering large quantities of products frequently via Electronic Data Interchange (EDI) or even through dedicated account managers, and making limited changes to those orders, rather than a consumer-focused fulfillment flow where large numbers of customers will order small baskets of products infrequently across a large number of self-service channels, and will often want real-time changes to those orders during or after that fulfilment – the differences in these two approaches are considerable, almost like speaking two different languages, and thus having an OMS in the middle can be the translator.
• As fulfillment networks grow and become more complex, with the options to fulfill both from owned warehouses, but also stores, 3^rd party logistics providers, retail partners, drop ship vendors, and other locations, it’s likely an ERP simply cannot master all inventory or location details (or perhaps would not want to, given that to do so may impact financial calculations), which then makes presentation of a consolidated supply view difficult, let alone accurate for a customer promise.
• ERPs are typically designed to mandate best practice flows to business processes, and deviation from those flows is often costly or not possible, so implementing new logic or processes to handle the ever-changing world of customer fulfillment can be disruptive and costly. By contrast, an OMS is set up to expect ongoing change in logic, new workflows, new offers, and new capabilities.
• Lastly, a modern OMS is highly modular and designed for agility – Fluent Commerce order management for example, is event-based, so inputs trigger outputs and operations are all in real time. A MACH (short for Microservice, API-drive, Composable & Headless) architected application like this means updates can be made often and changes are much easier to test, deploy, assess, and iterate, generally without continual needs to test end-to-end functionality.

Where could an ERP be suitable for enabling OMS capabilities?

All of the above is intended to point out some of the difficulties of trying to manage OMS functionality inside an ERP, but it isn’t the case that it’s always the wrong decision. Modern ERPs do allow more flexibility in their operations, and if you’re a D2C business which has grown up with the capabilities to deliver a customer-centric offer via digital channels, then many of the considerations above have probably already been considered and factored in. In such examples, the key consideration should perhaps not be whether an ERP is right for my business today, but whether there is enough agility in my operations that I could adapt ways of working to handle new channels, new offers, new products, etc. without impacting the wider ways of working each time.

So, in summary, what are some of the initial questions I need to consider when looking at my existing systems vs. a new OMS?

• What are the customer features/functions/offers which are going to add value to my business in the near term and long term?
• How feasible is it to adapt my current systems to handle these new customer offers/requirements? And how feasible is it given whatever else is already in the pipeline for these systems?
• If my requirements change, can my current system keep up with frequent changes? Is it future-proof? Scalable?
• Can I add additional value by decoupling my customer offer from my core processes through use of an OMS?
• How much would implementing an OMS cost vs. adapting my current ERP?

These aren’t easy questions and there will always be good arguments on both sides, so please reach out to the experts at Capgemini.