The dangers of poor ERP requirements gathering: a case study

Unlike standalone enterprise systems such as accounting, inventory, or HRMS, ERP systems involve and interact with nearly every process, policy and operating rule within a particular company’s business environment. Unless the firm’s workforce and supporting technologies are entirely compliant with what the enterprise ‘needs’ and ‘wants’ on top of ‘how it operates’; things can go very wrong, very quickly.

Consequently, the development of proper sets of business and technical ERP requirements are critical, whether they involve the selection of the right ERP system during the lead up to a purchase, or used later as a concrete baseline and as operational measurements applicable to additional considerations down the road. They are never optional - ever.

The process of investigating, developing and defining requirements represents the knowledge-backbone of an enterprise. These elements must therefore be as flexible as there are sturdy, allowing administrative and technical managers, supported by a well-trained workforce and necessary technologies to deliver value on the bottom line.

Where things start to go wrong

However, many typically responsible managers fail to appreciate just how critical this intellectual effort is, and instead apply half measures, when a full-measure and more is not only important, but potentially life threatening if they get it wrong. In the case of ERP operations specifically, the latter characteristic applies more times than not; since as asserted previously, resources-based platforms become enterprise-centric immediately from the moment they spin up.

Our 60-step ERP selection checklist will help you draw up a suitable list of requirements for new software

As an example consider ‘Alpha Company’, a mid-sized manufacturer oriented to small-lot production of printed circuit boards for the automobile sector. In the past the company had done well, and subsequently become the sole provider for a premier auto brand called ‘BetaCar’, even though ‘Alpha’s management had never felt the need to consider an ERP platform. From their perspective, as long as its products were QA’d appropriately and delivered to ‘Beta’ on time, the money would continue to flow.

Everything moved along apace until ‘Beta’ merged with a larger global concern called “CharlieCar’. Suddenly, in order for ‘Alpha’ to maintain its sole-provider contract with ‘Beta’, it needed to select, purchase, and launch an ERP platform that was entirely compliant with both ‘Beta’ and ‘Charlie’s’ global automated scheduling systems, even though they were steps removed up the organizational chain from ‘Alpha’s’ operations.

Rushed ERP requirements gathering makes things worse

As one might expect an immediate business fire drill ensued; including what they thought was the execution of a detailed set of requirements documents including an index of all necessary internal processes. However, the work had not been done efficiently, and the effort failed to identify and detail several automated production-stage alerts were not only critical to ‘Beta’ and ‘Charlie’s’ larger business interests at a general data exchange level, but also to ‘Alpha’ directly since the now unknown process triggers were supposed to be integrated within the company’s automated production line.

Nevertheless, ‘Alpha’ happily bought a shiny, new, and highly-expensive piece of software; paid additional monies to a consulting firm to execute, launch and implement the system, and thought that they were home free, until the first product run stopped suddenly, and operators received an alert based on the irregular receipt of stage data to ‘Alpha’s’ ERP scheduling module. Unfortunately, after consuming 48 hours worth of troubleshooting, the result was that the new system was unable to perform the needed processing, and as a wag might say, ‘what was previously history suddenly became hysteria.’

The results

In the end of the day, what previously existed as a happy business relationship between one small and one larger company, became a nightmare times three. Meanwhile, given their respective financial strengths, ‘Beta’ and ‘Charlie’ managed to weather the collective storm reasonably well.

However, as the smallest, and most dependent of the lot, ‘Alpha’ ended up closing its doors, after responding to a raft of breach of contract lawsuits filed by its bigger business partners. All of that misery could have been avoided had ‘Alpha’ just taken proper care of its initial requirements investigation, and ensured that the company not only knew how its own internal processes did and didn’t work, but also how its integrated business partners operated as well. Unfortunately, they didn’t; and the subsequent cascade of failures put them in a spot they simply couldn’t recover from.