Eliciting Requirements For ERP: 10 Quick Tips To Apply
/Basic Rule for ERP Implementation, “First you listen to the users; then you ignore them”.
When I first came across this quote, I found it quite amusing. On second thought however, I realized there was something else to it. An ERP implementation is a complex endeavour – its implementation is often fraught with budget restrictions, tight deadlines, management's wishes, diverse interests, technical limitations, organizational politics and a myriad of unpredictable factors. The effect of the combination of all these factors are further revealed as implementation progresses. Amidst all this “noise”, it can be quite difficult for the user's voice and opinions to come through.
The challenge often lies with the Business Analyst to stand in for the user and reiterate their needs to ensure that the resulting system reflects their requirements, despite the constraints.
ERP projects are notorious for failure. Research has placed ERP failure rates as high as 60% (See Article by John Cummings). BAs are expected to reduce the risk of failure by eliciting requirements that are accurate, within scope, technically feasible...the list goes on. Poor requirements elicitation can easily lead to a failed effort – a very expensive and public one.
So, where does one start eliciting requirements from?
The question of where to start requirements elicitation presents an interesting conundrum.
If you approach stakeholders to tell you what they want, you are likley to end up with a wish list of features that may not be necessary, are out of scope or out of line with the overarching objectives of the business or project. Though there is value in asking them directly what they would like the system to do, you may end up spending a considerable amount of time sifting through their responses to identify what is necessary and what is superflous.
On the other hand, if you present them with what you think will work, you may end up limiting their imagination, missing out on key requirements or end up with stakeholders that do not feel like their opinions matter, thereby reducing the chances of success.
Requirements elicitation for an ERP implementation when you already have established processes and systems implies that you do not have to start from scratch. In implementing a new ERP, it's important to examine what works with the current system as well as what doesn't work.
In determining what does not work, here are some starting points that can provide useful insight:
Change requests from business users
Helpdesk issues/call-center logs for complaints and internal user requests
Workarounds that are in place due to system deficiencies/process gaps
System test reports that provide information on system bugs. Typically, the ones that are yet to be fixed can provide insight into current deficiencies
Customer complaints
Feedback/user survey forms
In eliciting requirements during an ERP Project, take note of these quick tips:
Use interviews and workshops to elicit high-level business requirements. These techniques can also be used to validate pre-existing requirements and seek clarification.
The strategic objectives of the business should guide the scope of the ERP project. Is the main goal to reduce stock-outs or to increase customer engagement? Having these objectives in mind will serve as guiding lights when requirements are being evaluated and prioritised.
Business process modelling is the technique of choice. ERP projects usually involve process reengineering with requirements largely driven by business processes. Business process models offer an effective way to compare the As-is process with the To-be (future & improved state). The To-be processes form the heart of ERP requirements. These processes should guide ERP configuration and not the other way round. Process requirements (in addition to technical requirements) should form the basis of vendor demonstrations; they would be required to prove that their software can meet or be configured to meet these requirements.
You may approach requirements elicitation by module or by process.
ERP requirements eliciation is a team-based activity. In addition to the business analyst, the team would include ERP consultants, enterprise architects, project managers, data specialists, process owners and subject matter experts, to mention a few. The BA will be expected to play a key role in facilitating requirements elicitation sessions to ensure that the team comes to agreement on key project matters.
The BA role is key to eliciting and prioritizing requirements. BAs are expected to support the business in determining what is in scope and what is out of scope.
Users must be actively involved in requirements elicitation and all the implementation phases. This provides the opportunity to manage and influence their expectations in order to reduce resistance to change when the new system is live.
In addition to eliciting functional requirements, non-functional requirements and interface requirements also need to be identifIed, documented and validated with users.
Examine existing reports: This will shed some light on data requirements and output that the new system needs to produce.
Document exceptions: Process flows often come with exceptions that need to be discussed and documented.
ERP implementation is no doubt a complex endeavour. With these tips in mind, you should be able to identify an effective strategy that will help you elicit accurate requirements and increase the chances of project success. Lean on the expertise of other team members and ensure that the voices of relevant stakeholders are heard.
Picture Attribution: “Needs Wants Computer Keys Show Necessities And Wishes” by Stuart Miles/Freedigitalphotos.net
