Risks to your ERP-SAP implementation
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
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