E RP systems are continuously changipg and evolving to provide the organization with a new way of l ooking at business processes and decision making. Organizations are also continuously changing to match their environments. Both need the flexibility to adapt with each other in order to be successful. System implementations are generally very complex, time consuming, and resource intensive. B ecause of its size and impact on the organization an ERP system only increases this complexity; therefore, before imple
menting ERP, an organization has to plan and understand the life cycle of these sys
tems. This section will provide a quick overview of the ERP implementation process, which is also the main focus of this book. It therefore lays the foundation for the remain
ing chapters; the concepts introduced here will be discussed in more detail later.
CHAPTER 1 INTRODUGION TO ENTERPRISE SYSTEMS FOR MANAGEMENT 1 9
F I G U R E 1 -1 1 ERP Life Cycle
E R P L I F E C Y C L E
Understanding an ERP system life cycle and its effects o n today's organizations i s funda
mental to fulfilling the long-term investment in an ERP system. As shown in Figure 1-1 1 , E R P implementation i s n o t a o n e time implementation. It requires a continuous cycle of product release and support.
The key to a successful implementation, therefore, is to use a proven methodology, to take i t one step at a time, and to begin with an understanding of the ERP life cycle.
When a system implementation does not have a well-defined methodology, deadlines will likely be missed, budgets overspent, and functionality will not meet the client's needs and requirements. ERP system implementations are very risky, and using a well-defined pro
ject plan with a proven methodology will assist in managing those risks.
TIlere must be a strong well-communicated need to make the change from the exist
ing information systems/applications to an ERP system before starting any E RP develop
ment or implementation.There should also be clear and well-defined business objectives written and communicated to the organization. (A good set of ERP system objectives will be reviewed in Chapter 4.) The project methodology needs to be documented, reviewed, and fully understood by everyone involved in the project once objectives are outlined.
There are many methodologies documented and used in system implementations.
Figure 1 -12 shows a sample ERP implementation methodology. When selecting one, make sure it is robust and addresses all components for the entire project. This includes
I I
FI G U RE 1 -1 2 ERP Implementation Methodology
Requirements
'" "" '"
Gathering/Gap General System
Build and Test Design
Analysis
/ / ' /
Functional
Technical
Change Management
'"
Stabilization.�
Implementation and ProduCliO
/
/
SupportI I
20 CHAPTER 1 INTRODUCTION TO ENTERPRISE SYSTEMS FOR MANAGEMENT
project start-up through system stabilization. If an implementation partner or consultant is involved, be sure to review its methodology. Implementation partners may have good expertise in the functional areas, but their most important criteria are a knowledge base of how to design and implement systems successfully.
E R P I M P L E M E N TAT I O N S T R AT E G I E S
Implementing an E RP system is problematic without first considering current business processes and changes to those processes based on the functionality of the new system. If business processes are not analyzed and compared with what the new system can do, it is very likely the implementation will require significant system modifications after imple
mentation. In developing the business case for an ERP implementation one must make a decision on the number of modifications to be made to address business requirements. An implementation with considerable modifications to the E RP software package, sometimes referred to as "chocolate" implementation, can increase the chances of success with the users because the package has been customized based on user requirements; however, mod
ifications increase the investment in the system and introduce higher implementation risk.
In a purchased system like ERP, modifying the system means that every modification will have to be addressed each time the system is upgraded. It is like paying for the mod
ification over and over again. Most purchased ERP systems today are minimally modi
fied (or as-is) to protect the investment in the system. This is sometimes called a "vanilla"
implementation. Every E RP vendor upgrades t heir system on a regular basis, adding functionality, fixing problems, and generally keeping the product current with the ever
changing technology innovations to remain competitive. Product life cycles are shown i n Figure 1-13.
F l G U RE 1 - 1 3 Product Life Cycle
Implementation
��
(3a.
Resource Requirements n.
H�h 0' �
Med
Applications Management Operations and Post Production
I
Low r-�---.�---�--�----�--+---�+---�--, Base Personnel
� 0 0 --I G'l OJ z c s:
.2, Ct> <0' Ct> (/) Ct> < Ct> Ct> � 0 0> () Ct> :;; '0 0> (Q -,
S' r '" � 0
� � 0' (Q <' 0' s: 0> a. �
� SI<> '0 Ct> (Q 0 Ct>
3 a. (/)
CD G'l Ct> c
< 0> � CD
(D' '0 (/)
:;;
CHAPTER 1 I NTRODUCTION TO ENTERPRISE SYSTEMS FOR MANAGEMENT
S O FT WA R E A N D V E N D O R S E L E C T I O N
2 1
The number of organizations using the Internet has increased dramatically since the early 1 990s. The Internet and web browsers have created an environment that allows for information systems to move out of the back room and onto desktops everywhere.
Information systems have grown in functionality and availability. They have also become increasingly complex and difficult to develop. From the 1 960s through the early 1 990s many organizations were very capable of developing an information system application in-house. The development time was not lengthy and the systems developed were cer
tainly not as complex. It is very different today. Most organizations lack the skillsets and desire to spend t he time and money developing an ERP system "in house." For many of the reasons identified earlier many more organizations today have chosen to purchase ERPs on the market.
It is best for an organization that does not have the experience in developing ERP systems to purchase one; however, it does bring forward several issues that should be addressed. Even though it may seem that the vendor selection is the most important issue, t h e key is the organizational culture. Is the organization ready for change?
Organizations need more preparation for change with a purchased system. Setting expectations, developing organizational buy-in, and communicating the need for the change are essential. The "old" days of changing a system within a "silo'd" department are gone. Changing or modifying a system needs to be addressed in the context of the whole organization. In addition, most organizations that move from an i n-house devel
oped system to a purchased one find they have to address the notion of system "per
sonality" (i.e., owning the system, its functionality, and how it works). In-house -developed systems fit an organization and its business processes very closely. With purchased systems, each is developed with its own "personality" and requires adj usting to it. To utilize a purchased ERP system fully requires time to continually learn how the system can work best within the organization.
ERP systems consist of computer applications t h a t supports and connects all aspects of an organization 's business processes and offer a link to customers and sup
pliers. The data flows freely and is integrated in "real time." When an organization real
izes that its legacy system is keeping i t from properly and efficiently servicing customers and that their operations are in need of process improvements, t hey realize they should consider investing in an ERP system. The selection of a vendor-developed ERP system is a challenging j ob because the organization has to find both a system that is most appropriate for its operational needs and a vendor to become a "partner" for quite some time.
Before selecting a vendor, the organization must carefully evaluate its current and future needs in enterprise management systems. This needs assessment can begin very simply by looking at the size of the organization in terms of the number of employees that will be accessing the ERP applications. TI1e assessment must look at the industry that the organization belongs to and the functional areas that the ERP application will be sup
porting. In addition it must review the organization 's existing hardware, network, and software infrastructure, and finally the resources (i.e., money and people commitment ) available for t h e implementation. The criteria developed from this needs assessment can help the organization narrow down the vendors to a select few (i.e., three or four).
These vendors should be invited to submit their bids for the project. During this phase vendors should be asked to install their application (sand-box) on the company's IT
22 CHAPTER 1 INTRODUCTION TO ENTERPRISE SYSTEMS FOR MANAGEMENT
infrastructure and to have it made available to potential users for testing. In addition, the vendor needs to be evaluated on the following:
• business functions or modules supported by their software
• features and i ntegration capabilities of the software
• financial viability of the vendor as well as length of time they have been in business
• licensing and upgrade policies
• customer service and help desk support
• total cost of ownership
• IT infrastructure requirements
• third-party software integration
• legacy systems support and integration
• consulting and training services
• future goals and plans for the short and long term
These criteria should help narrow down the selection to one ERP vendor that best fits the organization. The purchasing and contract discussions should then start with that vendor.
O P E RAT I O N S A N D P O S T- I M P L E M E N TAT I O N
Going l ive ("Go-live") is one of the most critical points i n a project's success. A lot of time and resources have been spent to get to this point. In assessing an E RP project's readiness for Go-live it is vital to focus the efforts of t he teams to ensure that task and activities are completed before going live. This allows project management to address any outstanding issues that may jeopardize the Go-live date. This involves a readiness process that needs to include as many team members and appropriate users and man
agers as possible because i t helps the overall organization understand that t he imple
mentation is near and that changes will be taking place. D uring a project it seems like the system will never be implemented. An effective readiness process lets the teams and organization know that going live is close.
Many ERP implementations have turned into disastrous endeavors during or after the Go-live stage. For instance, FoxMeyer D rug actually collapsed during the stabiliza
tion stage, following SAP implementation, in late 1 990s and filed a $500 million lawsuit against SAP/R3. Much of the success of the implementation, therefore, is in the stabi
lization and postproduction support processes. Stabilization is the time from Go live to about 90 days after, or until the number of issues and problems has been reduced. An effective response to stabilization issues will determine how well the system is accepted by the end-users and management. Five areas of stabilization are important:
1. Training for end-users
2. Reactive support (i.e., help desk for troubleshooting)
3. Auditing support to make sure data quality is not compromised by new system 4. Data fix to resolve data migration and errors that are revealed by audits
5. New features and functionalities to support the evolving needs of the organization D aily and continual monitoring of the implementation issues will provide an appro
priate time to move to the postproduction support phase. This phase also addresses the backlog of developmen t issues, evaluates new business processes, and provides more updated training, all of which is a part of the continued implementation
CHAPTER 1 INTRODUCTION TO ENTER PRISE SYSTEM S FOR MANAGEM ENT