• Home
  • |
  • Blog
  • |
  • Lost in Translation: Why is COTS/ERP so hard?!

September 29, 2015

Lost in Translation: Why is COTS/ERP so hard?!

Adam Richards

Through decades of high profile failure and struggle the industry of information systems has become notorious for generating what I call “software disappointment.”

Costly defect escapes, project cost overruns, and even outright failures have historically been about as likely as success.

Among the many responses to this pattern of struggle has been the shift toward purchasing commercial “off-the-shelf” (or “COTS”) solutions and, on a larger scale, pre-packaged enterprise resource planning (“ERP”) tools.

These commercial products are designed to address well-defined business problems using a pre-packaged set of structures and functions. They have built-in “configurability” to meet an organization’s unique business needs, minimizing the need for custom programming.

To “buy, not build” makes sense from a business point of view given the well-understood costs and risks of custom software development. What is not so well-understood is what it takes to successfully implement an off-the-shelf solution.

We all know someone with a cautionary tale about the 2 year project at their office that turned into a 5 year disappointment. And the statistics bear this out. Recent research confirms several trends that illustrate that COTS/ERP implementation is hard:

  • ERP failure rates are increasing, not decreasing
  • Customization of off-the-shelf products (instead of adapting to the solution) is going up
  • Expected operational benefits are not being realized

So why is this happening? Why can’t we get it right?? There are lots of forces at work, mostly related to our fallibility as humans. But I’ll save that analysis for the behavioral economists. I’m focused on the solution.

The question for me really becomes: how do we create the conditions necessary for success? And the answer lies in one word: framework.

Fitting existing business information and processes into a pre-packaged solution is like fitting a square peg in a round hole. Existing internal processes and systems have grown organically around what you’re replacing.

A replacement solution almost never fits neatly into the existing environment. Is the hole large enough to fit the square peg? Do corners need to be shaved? Spotting these discrepancies is hard, and it is the key to implementation success. But how?

In some ways moving an organization to a new system to run its business is like changing the language that it speaks. Languages are systems too, evolved to solve the basic human problem of communication. And all languages are organized around a common set of things we all relate to – nouns, verbs, each other.

Language translation starts with a reference to definitions and rules, grammar and usage. These are building blocks of language, and provide a bridge from one language to the next. They are the ‘framework’ that defines possibility in a language.

In a similar way to language, information systems have an underlying structure of information and functions they must support, that defines what must be possible in the system.

Unfortunately, too often COTS and even ERP-scale system transformations start with an incomplete definition of the underlying structure of the system to be supported. They start without a framework.

For those of us experienced on such projects, we have all seen the “list of requirements” approach, and we have all seen it fail. The typical approach to defining the system need for prospective vendors is to make a list of everything the user community can think of. This approach is a recipe for failure.

It’s easy for a COTS/ERP vendor to respond to a “list” in the affirmative, to say that their solution is a fit. The lack of structured definition of the information, rules, and functions the system must support allows for multiple interpretations of the same starting information. Sales people and contract negotiators love lists of requirements.

The risk goes beyond vendor accountability. There are good vendors with outstanding systems that can meet the needs of your system transformation. But just because the hole is large enough to fit the square peg through, doesn’t necessarily make it a good fit.

There are always leftovers in translation. Professional language translators talk about translating “ideas, not words,” because in many languages and cultures, meanings and contexts do not always align. The same word may mean the same thing in some contexts but not in others; or there may not be a matching word at all.

Even the ideas themselves may not map well between two languages or systems. I’m reminded of “The Celestial Emporium of Benevolent Knowledge,” a fictitious but nonetheless instructive example of how even the categories we use are wholly dependent on our cultural frame of reference.

Too often, the promise of ‘configurability’ leads to laziness. I have seen firsthand how differences in interpretation in a requirements-list-based environment can kill enterprise-scale projects in the final hour. It is sad when thousands of hours of people’s effort ends in a food fight over semantics.

Of course, the challenge of translation is not a reason to not implement systems! But it is an issue that can torpedo your COTS/ERP implementation. And you spot it by developing a framework that defines what you need your system to do.

A system transformation framework provides a frame of reference from your existing system to your ideal future system. It gives you a structured way to talk about what you need, and map existing data and functions into it – even before you select a vendor.

On the COTS/ERP side, it provides a solution-independent frame of reference for prospective vendors to map their solution onto it. And it empowers your team to identify gaps early in the effort, before the vendor comes back with a configured system. The “is this it?” game never works.

The earlier you identify things that don’t map, the more time you have to address them – whether by choosing a different vendor, converting data, or altering business processes. Having a central framework that defines your starting point – the information structures and categories in the existing system – is essential to a predictable, successful system transformation.

In future posts we’ll dive deeper on COTS/ERP framework contents and usage. There are many religions in the world of software frameworks and abstraction, which we will bypass in pursuit of truth.

Meanwhile, if you’re compiling a list of requirements for your COTS/ERP solicitation right now, it’s not too late!!! With a little effort, you can make a framework that will save your bacon at contract time, at implementation time, and at rollout time.

Related Posts

Reframing the Need for Requirements Traceability Best Practices

Reframing the Need for Requirements Traceability Best Practices

Accelerate Agile Testing: Boost Efficiency with Keyword-Driven Automation

Accelerate Agile Testing: Boost Efficiency with Keyword-Driven Automation

Successful Automated Testing – It’s all in the Details

Successful Automated Testing – It’s all in the Details

Business Analyst vs. Functional Analyst | What are the role differences and why are they needed?

Business Analyst vs. Functional Analyst | What are the role differences and why are they needed?
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
>