ERP Project 101: Deployment vs Requirements Gathering

Customers, System implementers and ERP vendors are always looking for ways to accelerate ERP implementations.  One popular approach is to take a phased deployment approach based upon criteria such as location, ERP module or feature set.   Requirements are gathered, validated, and tested based upon a limited scope.  Unfortunately, many ERP projects utilizing this approach result in failure given requirements conflict and misaligned expectations.  In the following blog posting we will discuss how to minimize challenges associated with phased ERP deployments.

Reality Check!  There will be ERP requirements conflicts

A reality with any cross-functional or multi-site deployment is that there will be requirement conflicts as part of an ERP implementation.  In our focus for rapid results and simplifying ERP deployments we forget the fundamental result – an ERP implementation is the implementation of a business solution.  Consider the following illustration:

ERP REquirements Conflict

Example of Requirements Conflict for ERP

Let’s assume that we want to accelerate an ERP HR implementation by deploying ERP solution by region.   To further streamline our efforts the project only gather requirements from the North America HR stakeholders (Phase I). The above approach appears to work for the initial ERP deployment; however; these short-sighted decisions can have a negative impact to future deployments.   Remember that correcting problems and limitations are more costly once an ERP system is deployed in a production environment. 

With the above said, I appreciate that ERP vendors are evolving their ERP software to provide additional flexibility in configurations to allow variances based upon industry, line of business, country and even user preferences.  However, we should understand that all ERP solutions leverage a common data model with specific data dependencies.  We can address this constraint in one of two methods.  Either we take a risky approach of gathering requirements in silos hoping that we clearly define all ERP configuration dependencies or take the practical approach of gathering requirements across all HR operational areas. In the next section we discuss several practical steps to ensure requirements conflicts are minimize.

Practical Steps to Minimize ERP Requirements Conflict

Let’s brief speak to some common-sense approaches to deal with the reality of ERP requirements conflicts.

How to address ERP requirements conflicts

Practical approaches to address requirements conflicts

The first step of requirements management is to perform a stakeholder analysis to identify the appropriate business owners and subject matter experts in include in requirements gathering.  It is important to note that we always implement to a business process not simply to the software (ex. module, feature). Utilize solution modeling to analyze business requirements from multiple perspectives.  Too often I observe ERP projects spend more time on defining exceptions to standard business scenarios versus defining a common requirements set that can be leverage to isolate and manage unique requirement criteria.  Consider the following illustration:

 

Logical Business Requirements Model

Logical progression of gathering ERP requirements

There should be a logical progression of business requirements from the global level to the specific user level.  Isolate requirement exceptions to effectively quantify frequency, impact, and cost.  Utilizing this approach will provide the customer with greater insight for an informed decision.   Finally, let’s not forget the Lean principle that states process efficiency is gained when variability (exceptions) is minimized.

Summary & Conclusion

The ERP industry is hyper-competitive where every ERP vendor and System Implementer is looking for an edge to accelerate and reduce the costs associated with ERP implementations.  This desire is intensified by the entrance of ERP SaaS offerings with lower entry costs for a growing target market.  The challenge is to identify competent options for accelerating ERP implementations without putting long-term customer success at significant risk.  Requirements management (gathering, validating, and testing) is the critical discipline that impacts all downstream implementation activities.  Taking a technology-oriented approach results in (a) unclear requirements, (b) requirements conflicts, and (c) additional rework to support future deployments.  Making the right investments in requirements management will be the best chance to accelerate downstream activities including deployments.                    

Advertisements

About Grady 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.

5 Responses to ERP Project 101: Deployment vs Requirements Gathering

  1. Pingback: New PM Articles for the Week of August 26 – September 1 | The Practicing IT Project ManagerThe Practicing IT Project Manager

  2. Well said. After participating in these over the past 20 years you nailed it.

  3. henrywilliamms says:

    Nowadays, businesses are struggling in defining their ERP requirements. In that case, it is essential on their part to hire professional ERP consultants who can provide you the most peeless ERP solutions that specifically are designed as per their business specifications and demands. Professionals design ERP solutions for a business after keeping various factors in mind like organization’s budget, technological infrastructure and specially the operational needs.

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

%d bloggers like this: