Reverse Engineer to Business Requirements
October 28, 2010 10 Comments
A critical activity for any ERP implementation is gathering business requirements. The purpose of business requirements is to define the needs that will enable business activities to generate business results. The traditional school of thought is that if we capture all the requirements then we assume that we will develop a solution that will produce the desirable results. I believe that experience has taught us that the above assumption is not correct.
Let’s use the above illustration to elaborate on a few observations based upon my experience:
- Customer’s existing business models will have both value-add and non-value-add business activities.
- Customer’s existing business models may produce undesirable business results.
A concern with traditional requirements gathering techniques is that non-value-add requirements are carried throughout the requirements management process. This results in wasted effort, loss of focus on the critical requirements, and informally creates the expectation that the new ERP system will replicate existing functionality. A majority of non-value-add requirements are a result of current technology or organization limitation. This is not a criticism but rather a reality we all (Customers, IT, Implementation Partner) must address as part of an ERP implementation.
START WITH THE END IN MIND
Let’s consider something unconventional and trace desirable business results back to business activities and the individual needs (requirements) for each business activity.
Starting with the desired business results ensures that we drive to only those requirements that directly support true business value. First, it is an exercise that really puts into perspective the purpose of a business model (results). This exercise is not only useful to the project team but also the business stakeholders. Second, it is an approach that can help you justify why certain existing business activities are not being carried forward in the new business solution. Third, taking a business results oriented approach enables your project team to be more successful at focusing on the right business requirements and not wasting time on capturing requirements for non-value-add activities.
Often we spend too much time and effort focusing on gathering requirements that do not support key business results and then gloss over the key business activities because of implementation time constraints. Prioritizing business results is an activity that we need to initiate before gather requirements, not during fit/gap when expectations are harder to manage and negotiate.