CHAPTER 5 IMPLEMENTATION STRATEG I ES
1 1 4 CHAPTER 5 IMPLEMENTATION STRATEGI ES
---
company. At this time, early in the project, open and honest assessments are critical to project planning. Self-assessment, which was not done at Aquatech, is often difficult and inaccurate, so it is not unusual for businesses to hire consulting companies to make these complex assessments. The amount of t ime, effort, and money spent on an ERP imple
mentation makes one ask, "why not have an accurate assessment of a business's ability to implement an E RP successfully?"
In this chapter you will learn about the infrastructure components that make up an ERP system. It is often said that the ERP software is the inexpensive component of an implementation. TIle reality is that all the other surrounding systems components and resources cost more. With any ERP i mplementation strategy, all the implementation components need to be identified and planned. Tllis chapter focuses on the components and then works to address the implementation strategy. There are separate chapters (chapters 6 and 7) that address software selection and the process of "Go-live" and oper
ational needs.
In addition, you will learn about the risks and impacts of an implementation on a business and what it means to implement a vanilla system. I n contrast, you will also learn what it means to modify or customize a system, along with the corresponding risks and business impacts in doing so.
You will also begin to learn the importance of project governance, project man
agement, communication, teamwork, work groups, and charters, and how they are used to better ensure the project's success. A key factor in every ERP implementation is cre
ating clear expectations and communicating those expectations to the business during the planning process.
ERP COMPONENTS H A RD WA RE
Hardware includes all computer devices and peripherals used by an ERP system. An ERP system will specifically require a powerful set of servers for development, testing, and production environments. Software resources must be replicated in all three sets of hardware.
The following are the key hardware resources necessary for an ERP syste m (Figure 5-1 ) :
• Servers. ERP systems are very hardware intensive; hence. they require high-end Illultiprocessor systems with, for now,,64-bit processing. In addition, they will need several gigabytes of main memory or RAM, and several terabytes of secondary storage, which includes hard-drives for system backup and recovery.
• Clients. People accessing ERP systems (e.g. , end-users, IT support staff, and developers) use personal computers to access the ERP system. These PCs could be desktop computers, laptop computers, or personal digital assistants (PDAs).
Some ERP systems require an installation of client software on these PCs to access the ERP application. The current generation of ERP systems, however, uses Web clients and therefore does not require more than a Web browser for clients to access the ERP system. IT support staff and developers will require
CHAPTER 5 IMPLEMENTATION STRATEGIES 1 1 5
BusinessSites
)
Other Sites Border Router
Internet
.--L
Perimeter DMZ
firewall r---- ,---- - - ,---- r--
Network
T
Attached Storage Servers Print '�I·.vo "" � "�"Qv�.I
Load BalancersT T I l i T
I I
.-- Secure Network Segment
Application Servers Application
rrJD
Firewall
-,- Database Servers
f---- Batch
I�"h ,�"I, Reporting Production
I I I
3rd Party Training Development
... F ... I G.. ;.;;U ... R.;.E ... 5"'"""_.oLJ:R .. ic ... a .. lERP Architecture .:::.;:
secure connections (i.e., Citrix, VPN) to access the ERP administration and devel
opment environment.
• Peripherals. E RP systems also require media for long-term archiving of all business transactions, back-up and recovery RAID storage devices, and the like. I n addition, they will require print servers, printers, back-up power supply equipment, and networking hardware to· support a multiuser access over the Internet.
SOFTWA RE
The traditional definition of software is a set of operating instructions and logic called
programs that control and direct the computer hardware to perform its functions. The more contemporary definition also includes a set of information-processing instructions called procedu.res to assist people in their work. Software today can be visual (e.g., Microsoft Office) or embedded in the control systems (e.g. , in automobiles).
1 1 6 CHAPTER 5 IMPLEMENTATION STRATEGI ES
----------------------------������------------------------
The key software components for ERP systems are:
• System Software. This is the operating system platform that is essential for any application software to work efficiently with the hardware and IT personnel.
Similar to other application software, E RP work on a wide variety of server platforms (e.g., Microsoft Windows Server, Linux, and Sun Solaris). One of the key requirements for the OS platform is multiuser and multitasking capabilities with good security, back-up, monitoring, and recovery systems.
• Database Management System (DBMS). A reliable multiuser DBMS with good authentication, authorization, security, back-up, and monitoring function
ality can serve as a strong foundation for the ERP system, which is similar to other operating systems. Most E RP systems today can work with a variety of DBMS (e.g., SAP/R3 works with IBM-DB2, Oracle, Microsoft SQL); however, some of the smaller E RPs (e.g., Microsoft's Great Plains) work only with Microsoft SQL.
• Application Software. These are programs or software utilities that help in the development, monitoring, and integration of E RP software. Even though they are not as critical, many E RP implementations will require project management soft
ware, development software, remote access software, and automated software for monitoring system traffic, virus protection, and other software utilities to enhance the quality of experience with the users.
Table 5-1 illustrates some of the software used with an Oracle/PeopleSoft ERP implementation.
TAB LE 5-1 Software Components with Oracle/Peoplesoft ERP
Vendor Software
Oracle
BMC Control-M MicroFocus Cobol Informatica PowerCenter Citrix XPe
PentaSafe SQL Secure
Mobius Document Direct and View Direct IBM DCE for Solaris 3.2
BEA WebLogic Express Quest - Stat
Quest -Toad McAfee PGP
EMili Enterprise Server First Logic Address Cleansing Adobe Output Designer Merkur Fax Software
D atabase management B atch run control Software compiler ETL tool
Terminal emulation Security
Report distribution Data control softtware Web software
Software control system SQL development tool Security
Email distribution Address updating
Letter development and generation Faxing documents
-
CHAPTER 5 IMPLEMENTATION STRATEGI ES
As with most technology in the world today, Oracle is developing its ERP software using a newer set of software development services that is more current with the open source software direction.
PEOPLE RESO U RCES
For the implementation and operation of ERP systems to be successful, a knowledge
able staff is necessary. This includes end-users and IT specialists.
End-users can be employees, clients, vendors, and others who will ultimately use the system for their work. The success or failure of an ERP implementation is ultimately in the hands of these people. It is very important to understand the needs, skills, and abil
ities of this group very early in the implementation process.
IT specialists are staff members of the ERP implementation team. They consist of database administrators, IT operations support, developers, change management, train
ers, and others in the IT group that are involved with the development and operation of the ERP system.
The project manager plays a very important role in the success or failure of the ERP system. A good project manager is one that can put together a harmonious team, work with top management in getting support and resources for the project, and champion the system and its benefits to the end-users.
The ERP implementation team will include various subteams from business or func
tional areas, change management, development, data migration, and system support.
For example, the functional team determines the gaps between the ERP functionality and the business processes requirements. During the implementation process the func
tional team must chart out a customization and configuration plan for the development team. The development team customizes the systems functionality and forwards the changes to the quality assurance (QA) team, who is responsible for testing and assur
ing that the system functions according to requirements set out in the implementation plan. Along the way, the change management team works with end-users on training, communications, and support activities.
T H IR D PARTY PRO D U CTS W HY A RE T H EY NEEDED ?
What are t hird-party products? Third-party products are add-on software components either to make the system operational or to add missing functionality not offered by the ERP system. These products are often purchased or developed. Operational software may allow the new ERP system to distribute reports, permit a single user ID and pass
word, enforce a h igher level of security, or improve system performance monitoring.
Although these systems are not necessarily integrated with the ERP system, the data or services need to work with the system on a regular basis, and they must work seamlessly.
Another type of third-party product is one that adds missing functionality needed for the implementation to be successful. This type of product, whether purchased or developed, will need to work in conjunction with the ERP system. It will need to be interfaced or integrated with the system, depencling mostly on the data update timing requirements between the system components.
1 1 8 CHAPTER 5 IMPLEMENTATION STRATEGI ES
---
I N TEG RAT I O N W I T H ERP
When using third-party products, the decision to integrate or interface needs to be addressed. Integration is defined as the sharing of data and data elements directly with the ERP system without data redundancy or copying of data to another table or data
base. An intel!ace is a process by which data or data tables are copied or updated to or from, or both to and from, the ERP system. Both processes are similar to an imple- mentation, but they also have distinct areas that need to be addressed. .
Component integration should not be taken lightly. To integrate a component suc
cessfully, a staff person with a particular technical skill set is often needed. This is a per
son that fully understands the ERP system's internal data and coding structures. Staff must understand specifically how and when the system components and data will be updated. As described earlier with third-party products, both products will need to be investigated each time either is upgraded. If the products are both purchased, the ven
dors will sometimes only allow authorized staff to modify the system, thereby creating a dependency on both vendors each time either of the systems are changed or upgraded.
Interfaces are sometimes easier to implement, but the downside is that the data will not be as timely as if it were integrated. In general, interfaces should be one-way, either from the ERP to a third-party component or from a third-party component to the ERP.
Entering or changing data in one location will save time and reduce data and reporting errors. Two-way interfaces are sometimes required and should be addressed only after exhausting a one-way interface approach.
ST RATEG I C PART N ERS
ERP vendors have recognized third-party products and integration can cause prob
lems. To remedy that, ERP vendors have developed relationships with third-party software vendors in t he industry t o assist in addressing integration and interface issues with third party products. This generally means that the third-party product vendor will receive early versions of ERP system upgrades to allow for time to test and change the third-party product to work with the upgraded E RP version. Over time these partnerships have proven to be very beneficial and have expanded beyond early releases to developing coding standards and more elaborate system validation processes. I n looking at third-party products, a business should work with the E RP vendor to identify the vendor's strategic partners and fully to understand the mean
ing of a strategic partner. Third-party product vendors need to display a high standard of coding and to validate their product with the ERP vendor to ensure system integrity and reliability.
MIDDLEWA RE
Interfacing and integration is recognized as problematic to ERP systems. The develop
ment of middleware is an attempt to solve this issue. Middleware can assist with the development of reporting databases that use extract translate and load tools (ETL) and with newer middleware systems that act as the arbitrator between an ERP and other sys
tems or products. The ultimate goal for middleware is to create a seam less process between two or more systems without needing to modify either system. This type of middleware is relatively new and will mature with time.
CHAPTER 5 IMPLEMENTATI O N STRATEG I ES 1 1 9
--------------------------------�����--�------------------
S U PP O RT
Third-party product support will vary on level of technical expertise and the timing of upgrades that coincide with the ERP vendor. This will need to be addressed as upgrades are available and tested against the other products that make up the operational envi
ronment. The key to this whole process is to develop a thorough testing plan and to exe
cute it. This testing plan will better ensure that upgrades to any component of the operational environment meet the production needs of tbe business.
' . !is
"..S �l...7 L3
D ATA B ASE REQ U IREMENTS
U NDERSTA ND I N G T RA N SAC T I O NAL A ND REP O RT I N G NEEDS
Relational databases have come of age and are used throughout the industry. There has been much iteration of relational databases since they were first introduced back in the 1 970s. They have matured as products. In addition, hardware infrastructures have grown and are better suited to sustain the environment. This was not always the case: It often took a large number of specialized technical staff to ensure that the database environ
ment was available and functioning well.
For an ERP system to perform up to expectations, the update or transactional com
ponent and the reporting component m ust respond in a timely fashion. The transac
tional component requires a quick response time to individual pieces of information for updating or inquiring. All ERP systems are initially set up to provide as rapid as possi
ble a response time for single transactions as possible; however, this works in contrast to strategic reporting, which generally requires retrieval of large amounts of data for summarization or large-volume output. These two components, transactional and report generation, do not work well with a single database instance and lead to the develop
ment of data marts, data warehouses, and ETL middleware. These reporting environ
ments currently import data from the transactional environment and arrange the data in such a way as to be able to produce reports without having to write complex pro
grams to retrieve the desired data. In most instances a "user-friendly" reporting tool can extract data and arrange what is needed in a report without having to develop complex programs.
SELECTI N G T H E DATA BASE
The database software product market has matured. Large ERP system implementations require a robust relational database system. there are only a few vendors today that can support a large ERP system. Oracle, DE2, and Sybase are predominant in the mar
ket, with Microsoft SQL gaining more and more support. There is more variety with a medium-size system with approximately 8 to 1 0 database systems.
In selecting a relational database a number of factors need to be considered, includ
ing taking into account the availability of software applications using the relational data
base, the availability of skilled, trained technical staff to implement and maintain the database environment, and the overall functionality of the database itself. If a business is purchasing an ERP system it is best to work with the selected vendor to address this
1 20 CHAPTER 5 IMPLEMENTATION STRATEGIES
---
issue. As a general rule, the ERP vendor will not commit totally to one database or the other but they can convey how many businesses have chosen a specific relational data
base, which ones they develop system functions for first, and which one get early releases.
This is all good information to consider, but the ultimate decision resides with the IT staff and how a relational database will best fit with the overall IT infrastructure.
STAFFI N G A N D DATA BASE AD MINIST RATIO N
It is a steep learning curve for staff to develop the expertise to maintain a relational data
base. Over the years skilled consultants in relational database technology have made a lot of money by helping companies install and maintain a relational database. There is not enough database expertise in the industry today, and developing organizational expertise requires a significant amount of training and hands-on use to maintain the ERP database environment effectively. If they do not have expertise in-house, businesses should be pre
pared to hire from the outside or to develop a database group from within. The hiring of consultants for long-term engagements is usually more costly. It brings in inunediate exper
tise, but it also has the potential for not developing the knowledge base within the business.
ERP APPROAC H ES G OVER N A N CE
Governance is critical in any project that transforms an orgal}jzation. I n an ERP system implementation, governance should outline and define committees and workgroups that are responsible for the different components of the implementation, how the different groups interact, and the decision-making process, including escalation procedures. The components of governance should include, but not be limited to, such project organiza
tion as technical development, hardware and software installation, functional compo
nents, communications, change management, reporting, project management, project owners and sponsors, budget management , and the issue escalation process.
I t is critical in any ERP implementation that governance be defined and commu
nicated to all involved in the process. The ERP implementation will involve a vast major
ity of a company's users and require a commitment of IT staff along with senior management and end-users. A well-defined governance structure, with a clearly under
stood organization in place, helps to create a comfort level for all involved as to how the project decisions and priorities will be addressed. The governance structure must be communicated to all involved and fully un,derstood before t he project begins.
SAMPLE G OVER N A N C E
I . Pwpose
Governance is a framework of processes and underlying accountabilities that guide the management of the project. This framework defines the leadership, organization struc
ture (i.e., roles and responsibilities), and processes that align decision making with strate
gies and direction. Leadership provides clear and consistent direction, organization structure creates the infrastructure to support the implementation of decisions, and process alignment defines t he activities that turn ideas into action.
CHAPTER 5 IMPLEMENTATION STRATEGIES II. Roles and Responsibilities
Owners The owners will consist of the senior management. The chair is empowered to make decisions when the owners cannot reach consensus. The owners determine over
all policy, budget, and scope of the project. The owners will meet when needed at the call of the chair.
Owners: Senior management functional areas Senior management IT
Proj ect executive
Project Executive The proj ect executive oversees project activities, provides broad project oversight, resolves policy level issues, and ensures that the project stays within scope. The project executive also builds consensus on business process changes that impact t he company, and provides project status updates (as needed) to the owners. The project executive works with the steering committee and project managers to establish overall project direction, review and evaluate project progress, and ensure appropriate user involvement for the duration of the project. The project executive works directly with the implementation partner (if one is being hired) and with the steering commit
tee to resolve appeals of decisions made by project managers, the cross-functional team, or both. The project executive will represent the project at the project steering meeting, project management office meeting, and team leads meeting.
Project executive:
Advisory:
Person ultimately responsible for the success of the implementation Implementation partner if necessary
Steering Committee The Steering Committee will oversee the project's efforts and ensure appropriate leadership. The committee will link business leaders with the project to assure that high-level direction, resource commitments, and timeframes are consistent and support business priorities and strategies. Members will include business owners, information technology leaders, and project management staff.
Application Steward The application steward is appointed by the owners cabinet. This position may rotate periodically. The steward will work with the other business owners to develop an overall business direction of the system, developing consensus, and resolv
ing functional issues raised to the steering committee. It is important to understand the application steward, in the absence of consensus, is expected to make the decision in the best interest of the whole.
Chairperson The chair will oversee the activities of the steering committee, ensuring that the committee functions in accordance with the overall project oversight . This includes budget, resources, deliverables, risk, and expectations management.
Members: B usiness owners Information technology Project manager(s) Project executive
\
Project Management Office The Project Management Office (PMO) consists of the project executive, business and technical project manager(s), and the implementation partner (if hired). The project managers manage the day-to-day aspects of the project, ensure that the project plan is being followed, and keep both team members and the pro
ject executive aware of the status of the project. This responsibility includes overall