Inadequate “as is” documentation
Consider that you are the implementation Project Manager for a consulting firm and you have a client who has selected an ERP system.
The project manager and the team started gathering requirements from end users through focus groups, workshops, sessions with SMEs, etc. After obtaining all the details from end users you can easily conclude that you have all the necessary information and requirements to successfully implement the “to be” software system erroneously. During UAT (User’s Acceptance Testing) you can find out that the system does not meet all the end user’s expectations as well as the participants of UAT are unable to authorize your implemented solution previously.
Requirements not scrubbed
Instead of focusing on what the requirement should process, it should focus only on the function that the system will perform. Government organizations implementing an ERP solution document requirements are maintained frequently 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 and 5. Manage the lifecycle of the requirement. The ERP implementation partner is also tasked with interpreting the requirements from spreadsheets and it discerns how these requirements will be implemented during realization and verifies that the requirements have been met during testing process. Moreover, the implementation partner of ERP for the sake of meeting deadlines rushes through the blueprint phase does not scour the requirement and makes blind attempt for executing the requirement even when the requirement is not feasible, necessary or consistent with the functionality of the ERP application.
Vendor software problems
The process of testing or maintaining the SAP software will give you errors, and so the needed enhancements, or bugs within your software cannot be addressed with your existing project team and so these errors, bugs, and needed enhancements do not instigate from having customized or implemented SAP erroneously but are rather triggered due to a deficiency with the vendor software. Impact occurred to your business could be manifested in different manners such as client/end user dissatisfaction, inability to roll out specific planned system functionality, financial losses, and unstable system based upon the severity of the problem. These vendor software problems can also get unresolved for prolonged periods. Furthermore, lack of controls, participation from the SAP client as well as audit trails can cause the software vendor problems to erroneously become closed when in fact they were never resolved.
No Scope Verification
Controversial relationships between the client and implementation partner stem from the fact that the client feels that the implemented ERP solution does not cater to their business needs depending on the documented scope, and the end users cannot perform all these tasks that were implemented within the legacy systems without difficulty. And when the client report defects, short comings and bugs against the ERP system were not a part of the scope or documented via a requirement and so the problem is compounded. When the ERP integration partner labels the end user’s reported defects and problems as enhancements mutually rather than problems with the implemented ERP solution the relationship between the implementation partner and the client takes revolve for the worse.
Tag:
Add to 
Bookmark Murdok:
Ron Victor is a SEO copywriter for http://www.simplysap.com. He written many articles in various topics. For more information visit http://www.simplysap.com. Contact him at ron.seocopywriter@gmail.com
