Problem
Before replacing an ERP system, you need to document your requirements. Obvious, right? You just have to talk to the
people working with the existing system and ask them for the requirements. But that would be a huge mistake, for a
number of reasons. If employees are afraid the new system will automate a big part of their job, they might be
reluctant to tell the whole story. Also, they might be unable to think outside of their own box, or they might think
certain tasks are not worth mentioning
Solution
There is a better way. Rather than ask employees to define their requirements, hold a business process review where
they can describe their current process, including its pros and cons. That will uncover the processes that should be
maintained as well as weaknesses that could lead to new requirements. By the way, it’s a good idea to get an
estimate on the impact of a weakness – the time wasted because of it. This will help you decide how much attention
to pay to the weakness (for example, an employee might be troubled by a rather insignificant issue that doesn’t
warrant a lot of detail in the documentation). The impact could also be used to help build a business case if the
problem is significant. The new system should eliminate the weakness, while generating cost and time savings. For
that reason, all problems should be considered opportunities with a new system.
For the process meeting, ask employees to bring both printed and electronic versions of key forms, documents and
reports. Consider writing the review documentation as the employees speak and letting them see what you’re writing.
Don’t copy verbatim; focus on understanding and synthesizing. That will allow the employees to see instantly if you
do in fact understand. It helps to be a fast typist but it’s not essential as you should be documenting only the key
points.
Level of Detail
The biggest challenge lies in deciding on the right level of detail in your requirements, so here are some pointers.
First, for the development of a custom system, you need much more detail than you do when selecting existing
systems. Second, if you will be evaluating vendors that already have hundreds if not thousands of clients, don’t
document basic requirements. The vendors would not be in business if they didn’t already have those covered. Third,
you need to be good at synthesizing so you capture only the essence of the process. For example, you don’t need to
know every person who approves a document. But you do have to understand the business rules associated with
approvals – whether there are multiple sign-offs or whether approvals are based on dollar amounts. Fourth, do
remember the purpose of the business process document. It’s not meant to serve as a training tool, but as a vehicle
for exposing key strengths and weaknesses. The same requirements might be defined in multiple places and not grouped
logically. Consider the business process review report as a working paper — a starting point in discussing the
“to-be” business process, in building a business case for improvement and in defining requirements in a vendor
questionnaire
Script
With some adjustments, the business process review report can also be used as a script for potential vendors to
follow in conducting their demonstrations. But if you want it to serve as a vendor questionnaire, you will need to
transfer the requirements to another document where you group them into sections and subsections. For example, a
requirement for the number of segments in the chart of accounts would be included in the general ledger section and
setup subsection.
Requirements
When the requirements document is completed, you still need to have the requirements confirmed and prioritized. This
is usually done by a group of key people who not only understand the details but know the organization’s objectives
and critical success factors. They can decide what’s really important. Confirming a requirement includes ensuring it
is clear. Prioritization could be something like 5=critical, 4=very high, 3=high, 2=medium, 1= low. To get through
the requirements on a timely basis, you should assign one person as a spokesperson for each section. Those who
disagree could express their opinion and there could be a debate.
In the end, you should have a clear, well-defined set of requirements that can be used to obtain quotes from vendors
for custom development or implementation of an existing system. The document can also be included in the vendor
contract to mitigate the risks of non-delivery.Proper requirements analysis takes time but wouldn’t you rather spend
that time at the beginning than much later, when every change will cause budget overruns and/or delays with the
chosen vendor?