The Hardest Part of an OMS Project
If you've stepped into any retail store in the last year, then I'm confident you've seen "Pickup In-Store" ads plastered on the doors, as well as broadcasted on supporting TV commercials and online adverts. Those of us that have had the joy of calling a retailer's contact center to get a return label sent to you, or needed to return/exchange for a new product, have been on the receiving end of capabilities fueled by an Enterprise Order Management (EOM or OMS) system.
All in - There's 60+ use-cases (and growing) that can be enabled through an OMS, with no shortage of acronyms: BOSS, BOPIS, BIPIS, BORIS, ROPIS, RIPIS. They're all shortcode for "bought through (this channel) fulfilled by (that channel)".
I've been fortunate over the last ten years to have designed and implemented 30+ OMS projects, across multiple leading platforms, and one thing's clear to me:
The challenge isn't integrating and testing the system, it's knowing how to leverage its capabilities.
Let me explain....
Two things make it increasingly hard to implement OMS:
- The rate of change in the products offered
- The equal lack of retailer experience implementing modern OMS solutions.
One of the main engines within an OMS is the Order-Routing component. Each of the main players (IBM/Manhattan/Aptos/Kibo) have all made advancements in this core function in the last two years to enable better order broker logic, keying on additional fields to optimize based on speed and cost. The example here is that the new functionality doesn't get bumped up to the top of the conversation when for example the software vendor comes out with new functionality to route based on the price-status at a specific store. The value which was foregone could have been to route a full-price order to a store where the inventory was marked down, recuperating what would have been lost margin and reducing the likelihood of the product having to been shipped back or liquidated in the stores. Once the projects get underway and the sole business case is solidified, it's less likely the retailer 1) knows of the new functionality, 2) wants to expand the scope of the project, even if it has a massive savings opportunity.
Look - When I need a mechanic, I go to one who works predominately with the car I own.Finance questions? Someone who works with and understands the needs of someone in my age range.
Likewise - If you're starting to embark on an OMS project, your best bet is to check with someone who focuses primarily on your industry and needs who is "a foot wide and a mile deep" rather than a generalist, or even worse, a consulting firm predominately rooted in strategy work, that can help provide the value of capabilities, but can't link them to your capacity to enable those capabilities.
In the following weeks, I'll post some additional detail on specifics for the above. In the meantime, feel free to take our 5-minute survey to see where your organization stacks up against the broader market.
Here's another quick read on a similar topic.