When going towards ERP project the enterprise can use two main approaches. Either they first collect requirements for the system or they first select the product and/or vendor and then map the requirements against its capabilities. 

Selecting the product upfront seems ill-advised, as before specifying the requirements it is hard to get convinced that selected product has the best fit against requirements compared to rivals. So often requirements get collected first, either in-house or with help of consultant. And most straight-forward way is collecting them bottom-up, in a series of workshops, department by department. This wish list of all the good in the world then gets labelled as requirements list and send as RFQ to vendors. This is in theory a solid and logical way to proceed, but not without its problems.

Consistency issue

The first issue with this bottom-up approach is that it doesn’t guarantee consistency between requirements. Maybe person A from finance wants real-time financial status, which requires automatic postings from logistics. And maybe person B wants approval process to certain transactions, which means that postings get delayed until approved. It would take knowledge about target products internal logic and algorithms to know if those requirements are maybe mutually exclusive or is there a pitfall. And those conflicts can be tedious to discover even for product experts. This potential hidden inconsistency between requirements, which (hopefully) gets discovered further on the project, may then impede the project. 

Process context issue

Another issue with bottom-up gathering of requirements is that it implicitly assumes existing processes. Requirements concentrate on tasks currently seen as critical or pain points, not against the new tasks, introduced by the new system, that nobody yet knows about. Generally certain process steps will become more automatic with ERP, as all the needed data to execution is now available, along with provided programs that can execute them. As the task goes automatic and background, then related user interface requirements may become obsolete. On the other hand, the task of defining the exact rules for the automation get critical. E.g. purchase invoice verification can be 100% automatic, if invoiced quantity and price matches expected. But a new task arises: how to always maintain price-lists per vendor up-to-date. Before automation this was not a task at all, as all the verification was manual, if it even existed. Organization gathering requirements with context set to current processes easily get derailed into finding bunch of irrelevant requirements while ignoring many critical ones.

Hidden or silent knowledge issue

Third issue, and maybe the worst category of requirements, is those that never get documented. There are various reasons for this to happen. Maybe the right people were not present in the workshops to tell these. Either because they were too busy elsewhere, or maybe because they already left the company years ago. There are plenty of features built into old systems, some of them hidden in programs running in background. Possibly no one knows about those features or exactly when and how they affect, they just keep current system working.

Those who would know may not be present - it is not unusual to skip the documentation in the hurry of the project, so lots of such actually working business rules get hidden or lost. Or there could be documentation based on initial design, but which is outdated as later adjustments never found their way into the document.

Or maybe the right people were present in requirement gathering meetings, but some things appeared so self-evident to them that they went silent about them, just to make it faster to the next coffee break. The vendors may also consider those same details to be self-evident – but in a totally different way.

So areas of issues related to requirements gathering phase, in single site, are:

• potential internal inconsistencies in the requirements

• irrelevant requirements related to old processes and their requirements

• missing requirements related to new processes whose implications are yet unknown

• missing requirements stemming from hidden features built in old systems, possibly critical 

The processes definition approach

The standard practice to get the initial isolated list of requirements in a more solid format, is to describe the required functioning in the form of process diagrams. This way requirements get bound to processes and their steps, and everyone gets clearer view what happens before and after her own step, in other departments. This method is more top-down, starting from processes and then drilling into details. Requirements referring to-be obsolete tasks can be ignored. And those stemming from new tasks can be acknowledged and investigated.

But here comes the catch: these processes are usually ERP-product specific. It is difficult or impossible to define requirements in this top-down way without knowing the product which provides the template for the process. 

So it will be a catch-22 situation to decide which one to select first: requirements or the product. 

Downplaying of gaps by vendors

The usual way out of the problem is that the enterprise selects the product, with or without using preliminary requirements list as guidance. And the real work starts only after product is chosen. This is at least the way most vendors would like to sell their project! The unhappy party is then the company purchasing the ERP, as they are forced to "buying a pig in a poke", or committing to some serious design costs without knowing if in the end the product will fit. 

So ERP vendors prefer to consider business process planning as part of the project, as then the time spent is billable hours. Hence, they will only do the minimal effort to address the requirements in bidding phase, trying to push them as part of project. Normally they play down any gaps potentially discovered - it is often possible to find match for each requested feature separately, cherry picking single features from several (potentially mutually exclusive) processes, components or options. Of course their assessment to RFQ comes with disclaimer that proposed features are just preliminary and to be worked out in detail in process workshops later on.

This early product decision will be a further problem later on, as managers are reluctant to classify it as a failure, even if gaps turn out to be plenty and critical. Rather they stick to their initial choice through thick and thin, bridge the gaps with additional work ordered from vendor, and the project will eventually shoot over budget or fall short on critical features. Which unfortunately will happen on majority on ERP projects, less than 10% will succeed with both schedule and budget. 

So how to do it then?

Collecting requirements in-house, by own personal, while sounding a money saver to avoid consulting costs, carries major risks. Vendors wiggle through the list with vague promises, but project design phase then starts with a list of potentially self-contradicting, partially obsolete and regarding critical factors downplayed gaps list, missing the indirect new requirements of future processes and hidden requirements implicit in current systems. The magnitude of these shortcomings varies by vendor and each project team. 

It could be worth considering to have a separate consultant, not necessarily the same one that will be final implementation partner, to help sort out the requirements list. And help out with RFQ and how to interpret the answers by vendors. Having someone on same knowledge level as the vendor regarding the options, instead of giving vendors the superiority in this initial negotiating phase.

And last but maybe not least, as a word from the sponsor: yes, we provide these kind of services in Winter island.