Enterprise Resource Planning: States Adapt Processes to Match Available Software
Enterprise Resource Planning: States Adapt Processes to Match Available Software<@VM>Phoenix in Georgia<@VM>Par for the Course<@VM>Paying Pensions in Delaware<@VM>ERP and the Future
By Jon William Toigo
Successful system integration contractors have been long guided by the simple maxim that it is better to adapt software to fit client requirements than to force clients to adapt their business processes to fit software.
Organizations generally do not like to be told how to operate, especially by people with technical, rather than business, expertise. Integrators who ignored this dictum rarely stayed in business for very long.
But that time-honored wisdom has been stood on its head in recent state government projects for enterprise resource planning. Nearly one-third of states are working with integrators to replace legacy systems with ERP software packages that integrate core functions of the government enterprise, such as planning, financial accounting, human resources and logistics. Almost invariably, the direction from the states to their providers is to limit customization to a bare minimum.
There is a definite trend toward the no-customization approach, especially in government, according to David Kelly, director of consulting for market research firm Federal Sources Inc. of McLean, Va. That trend is a backlash against the inefficiency of customized software deployment in the past, which often resulted in costly and troubling upgrade and revision cycles over time.
Governments perceive value in importing ERP packages originally designed for the commercial marketplace into the government space, according to Kelly. ERP vendors ? which include Baan Co. of Herndon, Va.; JD Edwards of Denver; Oracle Corp. of Redwood Shores, Calif.; PeopleSoft Inc. of Pleasanton, Calif.; and SAP America Inc. of Newtown Square, Pa. ? claim to incorporate best business practices into their product design.
These vendors contend that their customers, by retooling operating procedures to match the methodology embodied in the ERP software, receive the two-fold benefits of effective software tools and improved operations that are in line with industry standards.
That value proposition has struck a note with government ERP adopters, who are "using the ERP package as a way to glean the gold nuggets of the best practices of the commercial world for use in their own operations," Kelly said.
Jon Derome, senior analyst within the Business to Business Commerce and Applications practice of The Yankee Group of Boston, agreed with Kelly's view, but also said he is troubled by it. Vendor claims that their ERP products embody best practices flies in the face of the facts, Derome said.
"The majority of the money invested into product development by these companies over the past three years has not been spent on improving the smarts of the products, their business logic components, but on adding Web-enabling capabilities for e-business," he said. Existing ERP packages, Derome said, are not appreciably better today than they were several years ago in terms of their intrinsic best practices application logic.
Derome said the more likely rationale for "accepting application defaults" and adjusting operating processes to agree with software-dictated processes was that doing so would speed implementation. Assuming the customer accepts the approach, it might offer a potential gain from a life-cycle perspective, he added.
"Most state governments are only implementing financials and human resources management components of the ERP package," Derome said. "They have little use for the manufacturing management or logistics management components of these packages, which is traditionally where the most customization work is done."
With minimal customization, application life-cycle costs, which derive from the periodic revision and upgrade requirements of most ERP packages, may be reduced, according to Derome.
"ERP has shown a 15 to 17 percent [annual] growth rate for the past 25 years," he said. "It operates on a continuous replacement cycle that requires organizations to rip and replace their system every two to three years, whether they use a commercial software package or a home-grown system."
Year 2000 concerns created a blip in ERP sales because they "pushed [several] years of replacements into one year," Derome said. Many organizations, including state governments, considered moving off stovepipe ERP systems and onto commercial ERP packages out of concerns over the Y2K vulnerabilities of their existing systems.
Y2K was a big driver in Georgia's ERP effort, according to Sue Armstrong, assistant director for Information Technology for Application Solutions within the state's Department of Administrative Services. Armstrong said the state had been working actively ? partly in response to Y2K issues ? to rewrite its home-grown accounting systems since 1992.
That effort proved an uphill struggle with occasional funding snags and other problems, according to Armstrong. Finally, in 1997, the resignation of seven key developers put a nail in the coffin, and forced the state to begin looking at the viability of purchasing an ERP package and implementing it quickly.
PeopleSoft financials and HRMS software were selected in late February 1998, as were the services of an experienced PeopleSoft integrator, The Hunter Group of Baltimore. With limited time to consider alternatives, the software product was selected for the human resources and financial application replacement project based on functionality and various technical requirements.
That view was reinforced by the fact that the department's board of regents already went with PeopleSoft for administrative system replacement.
Work commenced in March 1998 on the PeopleSoft implementation, part of a $52 million modernization effort dubbed the Phoenix Program. Armstrong estimated that $36 million was dedicated to the 16-month rollout of PeopleSoft Financials and the 18-month rollout of the vendor's HRMS modules. Remaining funds were used to modernize networks, replace non-Y2K-compliant personal computers and train more than 8,000 users in the operation of the new applications over a three-month period.
"We rolled out the PeopleSoft software in a record time frame," said Armstrong, who added that the success resulted from very good teams and two other factors. First, more than 70 of the state's agencies already were using the same legacy systems for both financials and human resources.
Additionally, she said: "We did a vanilla installation of the ERP package, used its base functionality as much as possible to get the work accomplished within the tight time frame. We were willing to change our business processes somewhat to meet the needs of the software, rather than vice versa."
Jay Richey, practice leader for The Hunter Group, said the bulk of the baseline processing functionality required by Georgia already was part of the product.
"Changes were needed only when mission-critical or special statutory requirements needed to be satisfied," he said. When customization of the PeopleSoft code was required, changes were made "in such a way that they can be segregated from other code when upgrades are applied."
The staggered rollout of the PeopleSoft modules in July and October 1999 facilitated parallel testing and training, according to Armstrong. The major hurdles, she said, were the "culture shock, which you have with any new system," and the short training time frame.
Dennis Parkinson, director of The Hunter Group's Public Sector National Practice, views the Georgia project as the rule rather than the exception. While more than half of state governments elected to keep legacy systems before Y2K, "seven states have put [requests for proposals] for packaged ERP systems on the street" in the six months since Jan. 1, he said.
He attributed the newfound interest to a desire to minimize upgrade expense and "to obtain best practices without having to reinvent the wheel."
While most states seek "plain vanilla, or near plain vanilla implementations" of ERP products, Parkinson noted a few differences in how states prefer to be serviced by integration service providers.
Some, such as Connecticut, prefer to use a single contractor to provide a total solution, "but this is not the norm," he said. "Most states prefer separate contractors to perform analysis and implementation."
In addition to Georgia, The Hunter Group is assisting Hawaii in deploying PeopleSoft for human resources and pension management. Parkinson said his company also has performed work for Texas and New York, but at an agency level. He noted that several states allow individual agencies to conduct their own ERP implementations.
Tom Ferrando, vice president of enterprise applications solutions with Acuent Inc. of Parsippany, N.J., another PeopleSoft partner and integrator, agreed with Parkinson that vanilla implementations are what state governments are seeking in ERP. But he stressed that smart customization is the added value that an integrator brings to an ERP project.
"In our recent project with the state of Delaware, they made it clear to us that they wanted a vanilla implementation of PeopleSoft," he said. "In fact, on the first day of the project, everyone involved was given a cup of vanilla pudding to emphasize the point. The pudding went bad in 18 months, of course."
According to Ferrando, the special requirements of the client necessitated customization of the PeopleSoft package for Delaware. His team had to remove the fear of customization by explaining techniques and methods, gleaned from more than 400 other PeopleSoft consulting engagements, for smart customization.
For Delaware, smart customization meant "creating and using bolt-on modules developed especially for the state, while avoiding making changes to the core modules of PeopleSoft," according to Ferrando.
"We need to consider customization on a case-by-case basis," he said. "While best practices may be embedded in the software, you still need to be flexible and adapt the product to customer needs."
John McCartney recalls the pain of his 20-year-old mainframe-based pension system all too well. Getting adequate performance from the system ? which until 1999 provided the means by which Delaware's Office of Pensions managed $5 billion in pension funds for the state's 35,000 active employees and 17,000 retirees ? was a daily tribulation.
McCartney, a strategic information systems manager, described the legacy system as a mixture of accounting programs used to administer 10 pension funds with data scattered across four different databases. Given concerns about the Y2K-readiness of the system and the small size of his technical staff ? just two full-time programmers ? "it only took about two seconds to consider and dismiss the idea of developing a new homegrown system."
In autumn 1997, the state issued a request for proposals for a packaged solution to the problem. Of the four respondents, Acuent got the nod to lead a 17-month project to roll out PeopleSoft's new pension module for its ERP product suite. PeopleSoft already had been selected for the state's payroll system replacement within the Department of Finance, so its selection for the Personnel Department, to which the Office of Pensions reports, was practically a given.
The results of the effort were uncertain, McCartney said. Acuent, while very knowledgeable about PeopleSoft, had never implemented the vendor's pension product. In addition, the pension module from PeopleSoft was not part of the vendor's public-sector ERP package. Acuent received permission to modify the commercial version for use by the state.
The project necessitated a lengthy requirements analysis, which evolved into "an office re-engineering study that both identified ways to consolidate forms and to Web-enable the solution," he said.
According to Ferrando, the three-month analysis phase enabled the scope of the project to be defined and also the normalization of data ? two key success factors for the project.
The latter was a big challenge, Ferrando said, especially given the disjointed state of the data and the numerous grandfathering rules used to establish earnings histories and payment requirements across the 10 pension plans.
Careful scrutiny of the existing system did provide the means "to map business process requirements to the software, where possible, and to define where process changes were necessary," Ferrando said.
The success of the initial rollout and its completion within the specified budget of about $4 million, including software licenses, Oracle databases and Sun Microsystems server hardware, earned Acuent subsequent work in the form of a six-week "opportunity assessment" that commenced in October 1999. The re-engineering study produced 43 recommendations, primarily involving the Web, for ways that the Pension Office could improve its business processes.
McCartney said the project's success emanated from other ingredients such as strong support from the leadership within the Personnel Department and Office of Pensions. Other projects in other departments had been less successful because they were subject to more debate, he noted.
McCartney also credited the partnership with Acuent, whose personnel he said had "what it took to complete the project."
As state government ERP projects continue to roll out, their success likely will depend less upon the best practices built into software than upon the skills and knowledge of integrators and the consistency of management support and funding.
According to The Yankee Group's Derome, "while there is no new best practice intelligence in these products, some integrators have gained a degree of best practice capabilities, which they bring to projects."
Officials in Delaware and Georgia are quantifying the benefits realized from their implementations. In the meantime, payroll is being paid, pensioners are receiving benefits and new ERP systems are settling in for the long haul.