|
| Recent
Articles |
End User Buy-In And How To Guarantee A Good Software Implementation
Failed Internet-based, software integrations and implementations aren't new; incompatibilities between people, change resistance, new processes and technologies have always been a concern.
Oracle, SAP Get Into Nerd Fight
Feeling cocky about Oracle's blowout quarter, CEO Larry Ellison outlined in a conference call last night, in no uncertain terms, the reasons SAP sucks and why it should be more like Oracle. SAP responded this morning with an I-know-you-are-but-what-am-I press release.
Philly Papers Tap SAP For ERP
Enterprise resource planning firm SAP picked up a deal with holding company Philadelphia Newspapers LLC to provide mySAP ERP for its print media companies.
Duet Hits Right Note For CRM, ERP Applications
Duet, the "groundbreaking collaboration between SAP and Microsoft," is turning heads yet again. Intended to bridge the gaps between the companies' software, Duet captured the attention of Computerworld, which deemed...
ERP Top Tool In China Factories
Manufacturers surveyed by IDC's Manufacturing Insights rated enterprise resource planning software highest among IT tools. Supply chain research director Bob Ferrari noted in the report he authored that intellectual...
|
 |
|
10.19.06
ERP-SAP Implementation Risks
 By
Ron Victor
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.
About the Author:
Contact him at ron.seocopywriter@gmail.com.
|
