ERP implementations are complex projects and a way to manage their complexity is to
attempt reducing their complexity (instead of answering to complexity by
complexity). A project implementation’s methodology is probably the most important
area that allows project’s simplification, though none of the available
methodologies seems to work well with such projects.
The point
that differentiates the various methodologies is solution’s conceptualization.
In general, the expectation is to have a set of functional design documents
(FDDs) that describe how the system operates and that can be used for
programming the customizations, if any. The customer must review and sign-off the
FDDs before the setup is done, respectively the development starts. Moreover,
given the dependencies between documents, they often need to be signed off
together.
Unfortunately, FDDs reflect the degree of understanding of the target system and business requirements, gaps that can prove to be a challenge for the parties involved, requiring many iterations until they are brought to the expected quality level. The higher the accuracy considered; the more iterations are needed. FDDs tend to consume a considerable percent of the available financial resources, in extremis the whole budget being exhausted just for 'printed paper'. Moreover, the key users see late in the project the working functionality.
In agile methodologies, FDDs are replaced by user stories, and, if still needed,
can be written as part of the sprints or later. Unfortunately, agile
methodologies have their own challenges and constraints in ERP implementations.
As functionality is explored, understood, and negotiated with the customer
during the implementation, it’s seldom possible to provide a realistic cost
estimation upfront. Given that most ERP implementations exceed their budget,
starting a journey without having an idea how much the project costs seems to be
a prohibitive approach for many customers. Moreover, the negotiations have the
character of Change Requests, which can easily become a bottleneck for the project.
On the
other hand, agile methodologies involve the customer earlier and the
development could start earlier as well. The earlier the customer is involved, the
earlier the key users understand how the system works, and thus they can be
more efficient in performing their activities, respectively in identifying the
gaps in understanding, trapping functional issues early in the process, at
least in theory. Some projects address this need by having the key user trained,
though the training environment usually has a different setup and data than
needed by the customer. Wouldn’t be a good idea to have the key users trained in
an environment that reflects to a higher or lower degree the customer’s data and
setup requirements?
In theory
the setup for such an environment can be done upfront based on one standard configuration
frequently met in customer’s industry. With this the functional consultants can
start to configure the system together with the key users exploring the data and
setup existing in the legacy system(s). This would allow increasing on both
sides the depth of understanding and has the potential of speeding up the
implementation. This can be started in the early phases, during the time in
which the requirements are gathered. Ideally, a basic setup can exist already
when the requirements are signed off. It’s true that this approach would mean a
higher investment upfront, though the impact could be considerable. Excepting Data Migration and customizations the customer already has a good basis for
Go-Live.
Of course,
there can be further challenges, though the customer can make thus sure that
the financial resources are well spent – having a usable system, respectively a
good system understanding outweighs by far the extreme alternative of having high-quality
unimplemented FDDs!
No comments:
Post a Comment