 | |
|
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