The standard phases of an ERP implementation are mandatory and inflexible as there seems to exist a imposed succession of the phases rooted in customer’s need of having an upfront cost estimate for the project. Moreover, the concept-based approach reflected in the creation of a set of Functional Design Documents (FDDs), even if it’s supposed to increase an implementation’s accuracy, it brings considerable challenges and an effort volume that could be spent in other areas. E.g., having a proof-of-concept setup subproject early in the project seems to bring more benefits.
Usually, before
or during the requirements gathering phase the functional consultants together
with the key users look at the legacy system(s) and data, questions are asked
on both sides, and the findings are hopefully documented, though the outputs
are high-level ideas or process design sketches. The sessions are abstract, and
besides diagrams there’s no feedback mechanism to make sure that the parties
understood customer’s processes and data structures, respectively that the key
users understood what the future system is supposed to deliver. Some projects consider
the building of 'AS-IS' diagrams and/or user stories during this phase, though their
impact on project’s outcomes is questionable.
Why not include
in this phase also hand-on training sessions for the key users during which a
system is set up based on the available information? For example, one can start
with an existing shell of the system reflecting standard parameters used in the
industry where the customer works. Starting from this shell the key users and
consultants go through the various processes and business scenarios, change
parameters, add master data manually, sketch how the process could look like,
respectively understand the gaps from expectations, or maybe how the process
can be changed to avoid customizations. That’s more effective than discussing
over and over the data structures and processes!
Of course,
this seems to increase exploratory phase's complexity, though the increase is apparent. Allowing key users to understand how the target system
works has the potential of simplifying project's planning and execution. Besides reaching a common
understanding of the functionality, the key users can better evaluate whether
the target system satisfies the high-level requirements, respectively better perform
the various activities - requirements’ definition, reviews and user acceptance testing benefiting altogether. Moreover, they can train and involve other users
earlier.
For this to
work there are several assumptions. First, that the functional consultants know
the target system(s), which is not necessarily needed in other approaches where
a person (e.g. business analyst) who can understand how a system
works and can document processes is enough. Second, the key users must have a good
understanding of the legacy systems. Third, the shell should reflect the business
needs as much as possible. Fourth, the necessary financial resources need to be
made available upfront. Fifth, the business commitment must be there, and with
this the key users should focus only on the project.
However,
the most important aspect is that the parties involved need to buy and support the
idea! The FDDs bring a safety net and make sense for both parties, the setup
being performed only after the signoff. On the other hand, because of the considerable
number of iterations FDDs involve high costs. Performing first the setup as
described above and writing later the FDDs, if still needed, should improve FDDs’
quality, and require fewer iterations.
This
approach allows an important volume of work to be done upfront, and even if further
effort is needed for customizations and testing, a lower level of
coordination is needed later, reducing thus the complexity of the planning and
of the overall project.
Previous <<||>> Next
No comments:
Post a Comment