Information Technology Reference
In-Depth Information
maintenance contracts to ensure the ERP system
evolution to the organization's needs may be
required. These types of scenarios are normally
predicted by managers and may become a con-
straint when deciding for an ERP system.
This “dependency” can be reduced if internal
teams constantly follow all phases of the imple-
mentation stage and ask for a high degree of
participation. This will give some autonomy for
companies to manage their maintenance costs.
is needed. This is due to the fact that it is very
hard to maintain the same performance when a
new release is available to market. Besides these
problems, a technological restriction can also be
pointed: some of the ERP Systems are developed
based on two layers (Presentation and Data layers),
which turn the upgrade operations into a difficult
task. This type of architecture does not provide
the desired scalability for such a complex and
multi-department system.
These scenarios also “spread” the feeling that is
necessary to buy the first ERP versions to avoid the
first errors of the so-called the Beta versions. This
became a usual procedure on software markets,
with customers preferring to wait for “mature”
versions to reduce implementation problems.
As a first conclusion, it can be assumed that
all these indicators are considered by company
managers to analyze the impact on their organi-
zation. Companies deal daily with the evaluation
of alternative scenarios to support the decision
process, comparing all the benefits and weak-
nesses of each option (internally, regarding process
modification; externally, the market reaction that
can be provided).
implementation times
According to Bingi (1999), the problem with ERP
packages is that they are very general and need
to be configured to a specific type of business
that takes a long time, depending on the specific
requirements of the business. For example, SAP
is so complex and general that there are nearly
8000 switches that need to be set properly so that
it is possible to handle the business processes the
way a company needs. The extent of customiza-
tion determines the length of the implementation.
The more customization needed, the longer it will
take to roll the software out and the more it will
cost to keep it up-to-date.
Tchokohué (2003) mentioned a study made
by the Standish Group, which found that 90% of
ERP implementations end up late or over budget.
And, in some cases, the implementation time is
extended indefinitely, which has negative conse-
quences for both the companies and the morale
of their employees.
An additional factor can be added if the imple-
mentation process is carried out by less compe-
tent partners/implementers, which will increase
implementation times, risks and costs.
trAditionAL erp sYsteMs'
Architecture
The actual ERP Systems already include solu-
tions for quick customizations. However, all of
them present some advantages and disadvantages
among each other, thus making it difficult to find
a “standard meaning”. This chapter presents the
traditional functional structure of these kinds of
systems.
Figure 1 presents a scheme, which represents
the existing functional structure for ERP Systems,
divided into 3 parameterization levels. A first
level for ERP internal business development can
be defined that includes all the business rules
developed by the software house as standard
operation routines. The second level is defined as
upgrade process (new Versions)
Other handicaps detected on these kinds of sys-
tems (even the “most advanced” ERP Systems
that include many configuration features) are
that they become a “nightmare” when an upgrade
Search WWH ::
Custom Search