About the Author
Jose Fajardo,
PMP, M.S. and SAP certified has worked as a test lead and test
manager for various companies implementing ERP systems. He has
written and published numerous articles, and has given presentations
at several software testing conferences in Europe and North America.
Throughout his career, Jose has filed many roles that helped to
create testing standards, mentor junior programmers, audit testing
results, and implement automated testing strategies. Jose can be
contacted at
josefajardo@hotmail.com
Summary:
Drawing from his experiences at large ERP implementations
the author
reviews 15 common risks threatening the success of most ERP
implementations. Suggestions are provided to mitigate the effects of
these risks. The author brings attention to risks that are
incorrectly perceived as minor and escalate into perils for your ERP
implementation.
Title:
Risks to your ERP-SAP implementation
-
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.
Please note:
All contents hereby presented are copyrighted material from Jose
Fajardo.  Copyrighted 2002. All rights reserved. Must obtain
permission from Jose Fajardo to reproduce, disseminate or publish
this article. Email:
jfajardo@octanesystems.net
