The challenges facing this organization, as with most organizations implementing ERP, are tremendous. A few of the issues that presented key challenges for the project team are outlined below.
At about the same time that the functional project team completed the business blueprint phase (i.e., Phase II of the ASAP implementation methodology), the technical team was accepting shipment of equipment and software required as part of the technology infrastructure that would drive the ERP system. Shortly after the components were assembled and the switch turned on, the issue of problem "ownership" surfaced. With ERP systems you may have many folks involved to ensure the system is running at top performance: hardware vendors (e.g., Compaq, IBM, HP), operating system vendors (e.g., Red Hat, Microsoft, IBM, HP), database vendors (e.g., Microsoft, Oracle, IBM), database administrators focused on optimizing database performance, and application specialists on the user side who focus on ease-of-use and response time issues. The state was dealing with IBM as the hardware, operating system and database vendor, SAP as the application vendor, state employees as the database specialists (IBM db2), and the implementation consultants as the application experts. Still, when the project team became aware of a major performance issue (e.g., 20 hours required to run payroll, in contrast to the four-hour run time required by the legacy payroll system), it was not necessarily clear as to who "owned" the problem: Is it the hardware vendor, the operating system vendor, the database vendor, the application vendor, or the project team experts who are responsible for tuning the system?
Instituting change in any organization is difficult. Change in state government is particularly challenging since there is no single point of authority (e.g., CEO equivalent). On this implementation, the commissioner of the Department of Administration and the director of Civil Services serve as executive sponsors. As indicated in Exhibit 1, not all departments are under the direct control of the governor, so it is difficult to enforce implementation decisions across these departments. The director of Civil Services, for instance, does not report to the governor but instead to the Civil Services Commission. The Civil Services Commission is appointed by an independent body; i.e., a seven-member body that has final authority over the classified workforce. Six of the members are appointed by the governor; the seventh member is an employee representative elected by fellow state employees. Each member serves a six year term. When choosing an appointed member, the governor must select from a list of three people nominated by the president of one of the state's major private universities (e.g., Zavier, Loyola, Tulane, Louisiana College, Centenary and Dillard). The net result was the existence of various, often inconsistent, human resource processes across the different departments and agencies in the state.
Prior to the SAP implementation, each department and agency had control over their own internal processes. For example, an agency could have had many levels of testing and many levels of approval before someone was hired (i.e., a hire action). Others, like the Department of Corrections, may have had fewer levels. Someone could have actually started their job before all the formal approvals were in the system. The person who started could have been entered in the legacy system (Uniform Payroll System), but they might not have been immediately in the personnel system until all approvals were made. There was no central control over these processes at the agencies, and this led to much confusion and excessive paperwork.
It may be difficult to truly appreciate the role of the Chief Information Office (CIO) unless you have experienced a technology environment without one. The state's ERP implementation started during an era when ERP technology and Internet awareness was low. The concept of running a standard ERP package statewide introduced a big problem: how to ensure that each agency and each workstation was capable of simply running the ERP application from their desktops? The answer was simple. Every agency, every workstation, and the network connecting them to the system would need to be assessed, upgraded if necessary, and eventually certified.
The purpose of the network assessment is to assess the current network and computer infrastructure of Louisiana state government (in the context of ISIS HR project requirements). The goals of this network assessment are:
To establish a documented baseline of the existing network infrastructure that currently supports the designated ISIS HR users.
To determine the minimum recommended network enhancements required for the successful operation of the new ISIS HR system at each of the facilities.
To recommend a plan of action to ensure optimum near and long-term network access to the ISIS HR applications.
This project focused on assessing the current network system architecture, technologies and capabilities, defining and evaluating needs, and analyzing current and expected traffic. Upon completion of the data collection, assessment, and analysis work, recommendations were included in the final report for improving the overall network. Included with this is a summary of the current network architecture, existing workstation configurations, SAP network requirements, and an overview of any applicable new technology that would address the state of Louisiana requirements.
The distribution of the graphical user interface (GUI) to each workstation was unnecessarily burdensome. Compact disks had to be sent to each agency, with detailed installation instructions and an adequately staffed help desk to deal with problems. Alternatively, if the state could enforce the utilization of their statewide network backbone (LaNET), then the GUI upgrade process (involving each workstation) could be simply automated through LaNET. A more attractive alternative, one becoming increasingly popular, is to utilize a Web-based front end, thus requiring no software installation on the client side.
With every ERP implementation one must determine how many resources and how much effort will be required to develop all of the necessary (f)orms, (r)eports, (i)nterfaces, (c)onversions, and (e)nhancements (FRICE). A form is a collection of fields from one or more Infotypes that are displayed on the screen either together or on consecutive views to solicit input from a user. A report is the output of the database query. Reports can either be one of the hundreds included in SAP or can be custom designed to meet the needs of the client. An interface is a software program, usually developed from scratch or modified from an existing program, that can translate data from one system into a format that can be recognized by another system (SAP R/3) and back again. Conversions are also software programs, either custom written or modified, that are used to transport large amounts of data from the legacy system(s) into the SAP system. Enhancements to the core (SAP R/3) code provide advanced functionality and must be developed in SAP's proprietary ABAP coding language. The biggest issues related to the state's implementation involved reports, interfaces and conversions.
Reports: The state legacy system had over 400 payroll, benefits, and civil service reports. These were identified for analysis during the realization phase to determine priority and necessity of conversion. SAP delivers much of the reporting functionality required, so many of the current state reports were replaced by standard reports. Required reports not replaceable by SAP standard delivered reports were prioritized and scheduled for custom programming.
Interfaces: Interface requirements include such items as: Bank One Payroll Interface, Department of Public Safety Time Interface, FI/HR to AFS Interface, Great Western Life of CO—Deferred Compensation Interface, Group Benefits Interface, LASERS Interface, LSU Medical Interface, Object Update from AFS, and Savings Bond Purchases Interface.
The Savings Bond Purchases Interface, for instance, is used to pass payroll savings bond contributions to the savings bond purchasing TPA. The state requested that functionality be introduced to support the purchase of the new series I savings bonds.
Conversions: "Data conversion problems require a lot of asking… instead of telling.… We are at the mercy of the agencies to provide us with accurate and complete data. If they fix it … great … if not, a bunch of folks may not get paid … but everyone will point to the implementation team and the software vendor to assign blame."
This problem is complicated by the fact that the legacy data comes from three different systems. Also, the R/3 system requires certain data fields to be filled with meaningful data. In one case, "positions" were being forced, people were being loaded into these positions, and these people would therefore inherit incorrect information from the positions that were incorrectly assigned. Forcing questionable data into the system and bypassing standard integrity checks would result in an erroneous database. Garbage in, garbage out.
In summary, the data in the legacy systems was in bad shape. The state did not proactively cleanse the data. "We started the data conversion too late in the process to realize how poor the data in the legacy system was and how it would affect the new ISIS HR system. We have gone live and data problems are still the number one issue." The legacy system was not an effective information process mechanism. It could not, for instance, identify those employees that were actually working two jobs (dual employment occurred but is illegal in Louisiana). "With an R/3 system all the information is there in front of you.… You can easily detect dual employment… on the payroll side. Before, you could not run reports and get information that easily… but with R/3, everything is in front of you!"
Early in the blueprinting phase, one of the project team members stated, "I have a major concern that there is not adequate time to allow the agencies to learn how to use the system properly and especially to understand the integration and the new relationships that the user must learn in order to enter and manage information correctly." The technical director added, "Imagine the sheer logistics of training 3,200 people on a system that is changing daily. You get the training done and then they send a software upgrade. We must put addendums in training manuals that are only a couple days off the press. We only have six classrooms to boot. Our schedule is packed, and we had an instructor call in sick for the week. We had to push training into the post-go-live period. And we are finding folks that were trained in October, then retire in November, knowing darn well at the time of their training that they would be retiring."
From a content perspective, the training team put together an outstanding package. "The training is wonderful. The reviews are excellent. The on-line material is superb. But people have to use it. Building it is one thing. Getting them to use it is an entirely different game." There is also the issue of training delivery. "It is like when we were kids and we had to memorize the alphabet table. We learned by rote memory without really understanding it. The folks in training have to learn the mechanics. Then, later, when they are in their workplace, they will gain the understanding behind why the system does what it does in the manner that it does."
System performance can be looked at as something as basic as How long does it take to run payroll? During the early stages of testing, the answer to this question was 37 hours. Totally unacceptable. The legacy payroll system only took 4 hours. It is precisely at these times that those high-priced technical consultants "with an attitude" begin to earn their pay. How does one approach this problem? Performance tuning is always an interactive process. The journey begins when all the components are connected and all the performance parameters are set to the default. "We start by trying to tune the application side… the sequel statements, the buffering allocations, and things of those nature.… Then we continue to the database level and look at buffer mechanisms and table utilization. We may, for instance, move heavily utilized tables to their own disks. All of this usually accounts for 80% of the performance improvements.… Then you look at everything else.… The operating system itself does not provide much room for improvement… once you set it up it is usually ready to go.… The biggest magic bullet we have had so far was a misconfigured parameter at the DB2 level that significantly affected performance." In summary, the following were found to be key performance improvement fixes:
Poorly written sequel statements attributed to inexperienced ABAP programmers. Some SAP code is just not as efficient as it could be. Some code was designed to bring entire tables into memory instead of just the records that are needed.
Poor indexing on database tables. For instance, we found sequel statements that would search entire tables sequentially instead of by indexing. To a smaller extent, you may expect sequel statements to execute a little differently on different platforms. There is sometimes room for improvements by fine-tuning these statements.
Finally, the database (i.e., DB2) parameters related to buffering the locking mechanism required tuning.
It is arguably human nature to "choose the path of least resistance." This mind-set is common in traditional work environments and it was also apparent on the ISIS HR implementation. "Instead of looking for ways to make their jobs easier, people would just do what they were told and that was it. People are there to pick up their paycheck." This is perceived often as being more prevalent in the public sector but perhaps this is because these organizations are very large. The ERP implementation forces major change issues on project team members who where previously not empowered to dictate and enforce these changes. Failure of project team members to make decisions they were empowered to make generally result in undesirable circumstances.
In a specific situation, unacceptable system performance was driving the technical staff crazy. To solve this problem in a system that is as integrated as SAP requires close collaboration between the database administrators and the application developers. "It is like the old adage, the right hand knowing what the left hand is doing." Early on in the project these teams did much communication using e-mail. But it just was not enough. "There is no replacement for meeting in person. When we sit together and talk through the problems we tend to come up with fairly elegant solutions. We also tend to build a special trusting relationship. We won't bend over backwards for each other unless we trust each other and unless we agree that we are in this together and we have joint ownership of the problem."
The management and collaboration of the diverse groups involved (i.e., state project team members; state change agents; implementation consultants; change management consultants; training and documentation consultants; application software vendor SAP; hardware, operating system, and database vendor IBM; and different functional and technical project team members) were perhaps the most difficult aspects of this implementation.