Reverse Engineer to Business Requirements

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. 

Business modeling associating business activities with business results

Results-Oriented View of Business Activities

 

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.

Business requirements support business activities which support business results

Results-Oriented View of Business Requirements

 

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. 

SUMMARY

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.

About these ads

About Brett Beaubouef
For the past twenty years Brett has helped customers select, implement, and manage ERP solutions across five industries (manufacturing, professional services, staffing, retail, and telecommunications). Business process knowledge and experience includes human resources, benefits, compensation, recruiting, time & attendance, finance, resource scheduling, contract administration, services procurement, sales, billings, project accounting, and project/portfolio management. Software selection experience includes evaluation of both ERP software and proposed implementation services. Brett has recently authored a book on leading ERP/COTS implementation strategies.

10 Responses to Reverse Engineer to Business Requirements

  1. Bill Gibbard says:

    I find that “traditional requirement gathering” always shows up in a list of requirements in Excel. It’s a boring spreadsheet with hundreds of lines per business process with vague statements of requirement often very wordy but still ambiguous. Each Excel cell leaves the statement open to interpretation and can’t be fully defined in this impersonal format. Marching to this list is dangerous for the very reasons that you state. In between rare true requirements, we find many that will sink a project. After digging into many spreadsheet lines with customer interviews, we find the requirement is ultimately supported by “that’s the way we’ve always done it” or “our old system made us to it that way”.

    I strongly prefer your notion of “desired business results”. How do you get there? Define business metrics (along with as-is measurements)? Document business scenarios at a high level? Then marry the two? Any suggestions suggestions for implementation tasks and deliverables would be grealty appreciated.

  2. Pingback: Adding Value to your ERP Requirements | ERP and More!

  3. Pingback: ERP Makes for an Expensive Custom Solution « ERP the Right Way!

  4. Pingback: Best approach for gathering ERP requirements « ERP the Right Way!

  5. Pingback: Best of Breed vs. Integrated ERP « ERP the Right Way!

  6. Pingback: ERP Application Strategy Roadmap for Maximizing Long-Term ROI « ERP the Right Way!

  7. Igor Arkhipov says:

    Hello,

    let me debate on the topic a bit.
    To my mind, what you are describing here is just a good and proper way of requirements engineering, so why call it reverse?
    Really, when a stakeholder gives an analyst some requirement, there are two basic ways of handling it:
    1) Most popular (as easier to carry out) but lamentable – to write it down as-is and then send the specification to developers for implementation.
    2) Less popular (as it requires additional brain work :) ) but desirable – to understand what was the reason for such requirement thus finding real lack of business value that stakeholder wants to eliminate (i call such reasons “real needs”). Satisfying such needs always results in what you call “desirable business results”.
    This is why there is a need in understanding what is there behind the requirement: stakeholder has some kind of ideal solution in his or her mind. This solution, when being formed as requirement, has to be transformed from the language of images in stakeholder’s head to some formal language (text or diagramms). Then vise versa this formal language has to be transformed to language of images in heads of project team. As stakeholder isn’t usually an expert in dealing with requirements, he or she cannot assure that the losses of information during this process are minimal.
    Another reason is that stakeholder, being expert in his or her area and having an understanding what the real problem is, can not always end up with most ideal solution to the problem within informational system. But people tend to come to the project team with solutions, not problems. Implementing such solutions without re-analysing them can result with total mess in a system from business result’s point of view.

    Returning back to reverse engineering of requirements, as I understand the term, it is a process of finding out, which requirements were standing behind some existing system without having any documentation about it. Such situation is common when dealing with legacy system (when we want to replace it with new one but remain same functinality) or as a result of non-structured or low-qualified development (when we finally want to create documentation about the system).

  8. Pingback: Reverse Engineer to Business Requirements | Pardaan.com

  9. Pingback: ERP Requirements Mgmt 101: What + Why = How | ERP the Right Way!

  10. Pingback: ERP Project 101: Challenging ERP Requirements | ERP the Right Way!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 4,410 other followers

%d bloggers like this: