Risks to your ERP-SAP implementation
1. Inadequate “as is” documentation
Symptoms: You are the implementation Project Manager for a consulting firm and you have a client that just selected an ERP system. You (the project manager) and your team start gathering requirements from end users through focus groups, workshops, sessions with SMEs, etc. After gathering information from end users you erroneously conclude that you have all the necessary information and requirements to successfully implement the “to be” software system. Since you believe you understand the “to be” system you neglect to document the “as is” system.
During UAT (User’s Acceptance Testing) you find out that the system does not meet end user’s expectations and the UAT participants cannot validate your implemented solution. Your client is dissatisfied with the proposed solution, and you are now challenged to prove that your implemented ERP solution is consistent with the client’s business needs, and requirements. Given clients’ complaints you are put in a position where you cannot explain how the proposed ERP solution meets or exceeds previous system functionality. The question now becomes how does the ERP system meet replaced system functionality if at all? Suggestions: Determine if there are any existing documents in the form of functional specs, architecture diagrams, requirements or flow process diagrams that describe current system functionality. Work with the client and in particular programmers who designed the legacy systems to understand the nuances and high-risk areas of the system that will be replaced. Document from your findings your understanding of the current “as is” system and also specify how you will replace the “as is” functionality with the “to be” ERP system. Draft test cases that specifically address how the replaced functionality will be verified within the ERP system and also allow the UAT members to peer-review the drafted test cases as they become available. Document any feedback from the UAT members for the drafted test cases and as time allows produce prototypes of the proposed solution to minimize the impact on the end users.
2. Requirements not scrubbed
Symptoms: Organizations in particular within the federal government draft hundreds or thousands of requirements that are often phrased as “the system shall…”. Instead of focusing on what the requirement should do the requirements should focus on what the system will do.
Frequently government organizations implementing ERP solutions draft requirements ahead of making a decision to acquire an ERP system and thus the requirements are incongruent with the capabilities of an ERP system.
These government organizations implementing an ERP solution document requirements that are often maintained in web of spreadsheets that makes it difficult to: 1. Track a requirement, 2. Modify the requirement while communicating the changes to the affected parties, 3. assigning requirement ownership, 4. Create an RTM (requirements traceability matrix), and 5. Manage the lifecycle of the requirement.
The ERP implementation partner is tasked with interpreting the requirements from spreadsheets and discerning how these requirements will be implemented during realization and verifying that the requirements have been met during testing. The ERP implementation partner for the sake of meeting deadlines rushes through the blueprint phase does not scrub the requirement and blindly attempts to implement the requirement even when the requirement is not feasible, necessary or consistent with the functionality of the ERP application. After testing is finalized and the ERP system is deployed much debate ensues as to the functionality of the ERP system because it fails to meet the requirements and the end users lose confidence on the deployed ERP application. Suggestions: For companies undergoing requirements based testing obtain a requirements management tool such as requisite pro or caliber-rm. Scrub...
Please join StudyMode to read the full document