Is Unified Commerce the New ERP Bloat?
Tuesday, July 10, 2018

Is Unified Commerce the New ERP Bloat?

ERP Bloat is a term that was popular in the naughts (2000’s) and early part of 2010’s. Enterprise resource planning (ERP) systems were initially created and designed to help very large firms stay nimble. It gave the mid and large enterprise the ability to know its numbers in near real-time. It was supposed to improve efficiency. Moreover, it was supposed to help companies compete effectively. But over time ERP bloat crept in. System vendors created a growing number of modules and subsections to the ERP system. Eager salespeople sold clients on a growing number of modules. Some that customers needed, while other were sold but never used. Hence the term created to describe a system that started off with a great focused idea, which grew. In most regards, these systems grew too big, resulting in the ‘ERP bloat’ idea, of having too many extra modules you don’t really need.

Too much means ending up with a cumbersome mess that is difficult to learn, use and manage. So, people stop using it, except for the critical needs. Sadly, ERP bloat has become a standard association with large systems.

For retail, today’s parallel is the bloat becoming more common with unified commerce systems. Of course, this is simplest to see in the ERP based solutions. Funny how old habits die hard. However, even among the modern, non-legacy based firms, this habit seeps in. The habit is to oversell customers on much more than they need. Not only is it a lengthy build (24+ months is common), but it often adds capabilities you won’t use or need. Instead, consider solutions designed as converged commerce systems.

Restrictive Contracts Sadly, ERP bloat has become the accepted standard in ERP systems and practices

It wouldn’t be a problem if you could launch, then give back what you don’t really need. Deploy a singular unified commerce system (SUC – all from one vendor), then swapping out weak sub-systems could be a good policy. It would give you, the retailer, veto power over the systems that you keep, and those you bring in specialized software to get done well. This would work perfectly, were it not for the restrictive and binding contracts. For most, there is no room to maneuver. Even if the vendor’s OMS or PIM system does not work – you have to pay for it, regardless.

Fortunately, you do have choices. Just say NO to these type of binding contracts. Insist on conditions that allow for swap-out of systems that don’t meet your needs or minimum standards.

 

Read More: Is Retail Like a Formula 1 Race? 

 

Insist on Fixed Price Implementations

Part of the problem with lengthy 24+ month SUC and ERP deployments is the lack of a fixed price implementation. If there is no fixed price implementation there is an incentive to draw out the deployment. Get a commitment from the vendor, then hold them strictly accountable to it. Certainly, it is understandable that if your requirements change, there will be corresponding adjustments to the implementation fees. Beyond that, get a price and time commitment. Then stick to it.

Certainly, there has to be some reasonable play room. The real-world does not follow all our best laid-out plans. However, the competitive retail world does not forgive long and drawn out implementation projects that span out beyond 6 month, 12 months, 18 months plus.

Out-of-the-Box No Custom Hard-Code

Retail is forever changing. You need to be able to reconfigure, adjust and set new parameters fast. We have seen retail projects where an unethical systems integrator (uSI) is involved in a dual role. Acting both as a trusted advisor and systems integrator, they assess solutions for the retailer. The retailer chooses a non-custom coded, industry standard system that can be operationalized quickly. Only later, to have the uSI suggest that they can deploy a platform solution and custom code a system for that client. Naturally, this is based on what they learned from acting as the neutral consultant. It results in a large custom coding project for the uSI. For many of these systems, it seems that the uSI’s work never really ends. A parasitic model like this ends up seeping resources from the retailer indefinitely.

Avoid the programming project that never ends. Worse yet, is getting a hard-coded system that ties you to consultants and uSI’s every time you need a change. Face it, retail is forever changing. Worse yet, changes happen fast. You need to be able to reconfigure, adjust and set new parameters fast. That means you need the stability of a system that is already field tested. Customized systems by definition are not. You need a system that is flexible and can quickly adjust. If you need to schedule a time for a coder to come in to make a business rule adjustment – then you need to reconsider the system you purchased.

 

Related: Distributed Order Management

 

Build Your System on Best-in-Class Technologies

Insist on the unified commerce’s leaner, performance-based cousin – the converged commerce system. A converged commerce system is built with best-in-class technologies. These are field tested, battle-hardened solutions. They are designed by companies that focus and specialize in a specific area. That means you are getting the best technology available. This rather than putting up with whatever your SUC vendor could figure out how to build.

Just Say NO to Licensing Fees Get the Omni-1000 Research Study

The other day, an analyst at a very large firm called me to ‘confirm’ what I meant by ‘no licensing fees.’ Being a native SaaS solution, our fee structure is simple. There is a monthly SaaS fee. If the retailer exceeds their included order volume, then they pay a nominal fee for extra capacity to handle additional orders. That is reasonable. It requires extra resources, for a small additional charge to cover the added needs. That’s it. There are no additional software licensing fees, hosting fees, annual consultation fees, maintenance charges, or anything else.

Scrutinize these extras. In the age of cloud technology, no retailer should EVER pay annual licensing fee or upgrade charge. In fact, all of those additional charges are ancillary. Just say NO!

 

Read More: The Rise of Converged Commerce

 

Consider Converged Commerce System

If you still want a single sourced unified commerce system, look to vendors that use OEM sub-systems. OEM being original equipment manufactured solutions. That means your vendor would have taken your best interests into account. They have sourced best-in-class technologies and pulled together a performance-based converged commerce system, for you. This scenario gives you all the benefits of a single vendor to contact. Yet you have the security of knowing that core components are sourced from best-of-breed technology vendors – for superior performance.

Either way, converged commerce systems are your best best. They bring together only the technologies that you need. Rather than relying on one vendor to create the best-in-class for every technology (not a likely scenario), you get to cherry pick the best of the best. It also means you don’t give in to the ERP bloat pressure, from one vendor maximizing their quota achievement, at your cost. ERP bloat exists. in Today’s retail, it is quickly becoming synonymous with unified commerce systems. Side-step the whole issue by choosing a good SI partner, and insisting on a converged commerce system configured to your every need.

 

Author:

Charles Dimov - Director Marketing OrderDynamicsCharles Dimov is Vice President of Marketing at OrderDynamics. Charles has 21+ years experience in Marketing, Sales and Management across various IT and Technology businesses. Previous roles include Chief of Staff, Director Product Marketing, and Director Sales. Charles has held roles in brand name firms like IBM, Ericsson, HP, ADP, and OrderDynamics.