One of the reasons why I am a consultant is that I enjoy solving business problems with technology. ERP provides a technical foundation that I can utilize to solve problems. However, during my career I came to the realization that simply throwing technology at a business need is not in the best interest of the customer. This is especially true when you do not completely understand the requirement. There is a difference between an evolving requirement and an evolving understanding of the requirement. In the next sections we will briefly review a practical approach for ERP requirements management.
Gathering Business Requirements is Just the Beginning
I think we all can agree that gathering business requirements is a key activity that will have a significant impact on ERP implementation success. However, it is as equally important to focus on requirements validation before proceeding to implementing a solution for addressing requirements. Too often we jump from gather to design before we have a full appreciation of the business need. When it comes to formal requirements management, I keep the following simple equation in mind:
Defining What
Sounds simple enough but how you gather requirements sends a message. Also, it is important to understand if the requirement is the result of a new opportunity or addressing an existing business pain. The source should play a factor in your approach to gathering information. Consider the following commonly accepted approaches utilized for gathering ERP business requirements:
Please allow me to state that the above methods are valid and have their inherent advantages and disadvantages. The challenge I find is not gathering the requirement but rather the limited effort spent on understanding how the requirement supports business process results.
Determining Why
It is hard to provide a solution when you do not understand the business. Asking why is less about challenging business requirements and more about gaining a better perspective of the requirement. What are the desired result(s)? How do the result(s) add value to the overall business process? Odds are that you will have only a superficial understanding of the requirement if you do not understand the context (environment) of the business need. Also note that asking why is the first step to validating your understanding of the business need. Following is a list of the common validation activities for business requirements:
I firmly believe that all four validation methods should be employed as part of defining business requirements. Unfortunately, not all of these validation steps occur during the deployment. The advantage with ERP is that you have working software that you can easily demonstrate and confirm how business requirements would be handled. Do not guess – prove what is possible!
Constructing How
This process is typically an area that is not executed well when it comes to ERP. In the rush for faster results many assume that the solution must be implemented via technology. Technology is good for many activities (repeatable, logical) but it can also be a costly option for conflicting requirements across a business process. As a rule of thumb, I typically consider 4 options for addressing business needs:
- Automation: Developing a technical solution to address need.
- Business Process: Creating business process to address need.
- Acceptance: Do nothing and handle as the need arises.
- Avoidance: Eliminating the source of the business need.
Understanding both the What and Why will provide you the right insight to select the most viable approach for implementation of the requirement. It provides you with the perspective and context for effective decision-making.
Summary
An enterprise technology platform like ERP is an empowering toolset for addressing business needs across an organization. Yet, soft skills like requirements management have a greater impact on business solution success. It seems like every couple of years there is a “new” ERP methodology that will address the challenge of gathering ERP requirements. Often I observed too much focus on the methodology and not enough effort focused on the end result. I’m sure that I may receive some criticism from my peers in regards to my attempt to “dumb down” requirements management. However, I have found that the best approach is a simple approach that every stakeholder can understand and recall instantly versus having to go to a methodology book.
Join the community! 16k followers across 100 countries!
Leave a Reply