 | |
|
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.
No comments:
Post a Comment