ERP Project 101: Deployment vs Requirements Gathering
August 31, 2013 5 Comments
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:
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.
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:
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.