This paper was presented at the 1997 CAUSE annual conference and is part of the conference proceedings, "The Information Profession and the Information Professional," published online by CAUSE. The paper content is the intellectual property of the author. Permission to print out copies of this paper is granted provided that the copies are not made or distributed for commercial advantage and the source is acknowledged. To copy or disseminate otherwise, or to republish in any form, print or electronic, requires written permission from the author and CAUSE. For further information, contact CAUSE at 303-449-4430 or send e-mail to [email protected].

L. Annette Foster and Billy T. Herndon,

Duke University

In its landmark strategic planning document, Shaping Our Future, Duke University acknowledged the challenge of maintaining its leadership in the areas of education, research, and patient care in an era of increasingly constrained resources. In an effort to be a better steward of its resources, Duke recognized the necessity of improving the effectiveness of its administrative support services. Shaping Our Future identified two goals—reviewing administrative services to provide greater productivity and modernizing administrative computing systems—as central to on-going improvement.

Senior administrators researched appropriate processes to perform both the improvement of current services and the implementation of new systems; they selected reengineering as the tool and launched a new initiative named Work Process Redesign. Work process redesign (WPR) is the "rapid and radical redesign of strategic, value-added business processes—and the systems, policies, and organizational structures that support them—to optimize the work flows and productivity in an organization."¹

WPR focuses on linking business goals to process outcomes with the result of changing the work that is done. Corporate senior executives view it as one of the most effective methods to cut costs and increase effectiveness.² Other change efforts such as downsizing, restructuring, and outsourcing achieve cost savings through the primary strategy of workforce reduction. Savings and quality control are often short-lived because the basic work has not been changed; fewer employees must perform the same amount of work. In the case of outsourcing, the organization often does not have quality assurance measures established by which to manage the performance of outsourced processes. Automation achieves efficiency and cost savings by changing procedures, but again, often does not change the essential nature of the work that is performed. By definition, work process redesign is not about achieving the incremental improvements that are the goals of Total Quality Management or Continuous Quality Improvement change efforts.

Work process redesign efforts achieve cost savings and efficiencies through careful analysis of high-level work processes and dramatic improvements in the way work is done. WPR examines and maximizes the three essential ingredients of any process: human potential; information; and technology.³ Restructuring may be an outcome of WPR in order to align employees with the work in the new process. Outsourcing may also be an outcome with quality control for contract management built into the new work process. A new information system is also usually one of the outcomes of WPR; however, the system is chosen and implemented based on workflow and goals for the new process and does not represent automation of an existing process.

Once a process has been redesigned, the organization often returns to or implements a quality improvement program. After redesign, the incremental improvements achieved are generally greater than before the process was reengineered. The essence of work process redesign is to achieve dramatic process improvements in a relatively short period of time, usually less than three years. The assumption of redesign is that the right things are not being done now and that radical change is required.

At Duke, the goal of work process redesign is to fundamentally rethink and redesign administrative processes to achieve dramatic improvements in critical measures of performance. In choosing to initiate work process redesign, Duke is committed to three primary goals, which may vary in priority according to project:

* reduce costs

* improve effectiveness

* increase flexibility

An implicit objective of redesign is that more efficient and cost-effective administrative processes will free resources to be directed to the educational, research, and patient-care of the University.

Beginning in December 1994, a dedicated WPR team studied the University and mapped all of its 20 processes. Since the administration’s directive was for change in administrative areas, only 11 were considered for redesign projects. The WPR Steering Committee selected three to move into the project phase: Procurement; Student Information Systems and Services; and Human Resources. The illustration below shows the high-level map of the University’s processes.

Procurement is the mechanism through which departments acquire goods and services used in instruction, research, patient care, and support services. It is of strategic importance to the institution, with total annual expenditures of $627 million. Staff and faculty in every office, department, and laboratory in the University, Medical Center, and Hospital perform purchasing functions, representing a customer base of nearly 20,000 individuals. In addition, the procurement process is monitored by a multitude of internal administrative offices, as well as external agencies, and is subject to a variety of federal rules and regulations. For these reasons, and because of Purchasing management’s desire to participate, senior administrators agreed to launch the procurement redesign first.

There are three generic developmental phases for WPR projects: vision, detail design, and implementation. The work for each phase is done by a team comprising staff members who are employed in the current process (e.g., staff from Material Support and Disbursements on the Procurement project) and stakeholders (e.g., staff from Accounting and user departments), as well as business and information technology professionals trained in reengineering. The efforts are often guided and assisted by external consultants. Each phase concludes with a team report and/or presentation to the WPR Steering Committee, executive sponsor, senior officers, and other stakeholders. Formal approval from the Steering Committee, the sponsors, and other appropriate senior officers is required before the project can move to the next phase.

During the same time period that the procurement redesign vision and design efforts were occurring, the Office of Information Technology (OIT) conducted an assessment of the University’s computing needs and of the organizational structure necessary to provide support. Duke’s administrative systems were 15-20 years old and did not meet departments’ changing business needs. A greater need for more accessible and timely information was identified.

As a result of this needs assessment, OIT developed a series of technology plans, directions, and strategies. These included: Information Technology Strategic Plan; Migration Planning Document for Applications and Computing; and Year 2000 Management Overview and Awareness Report.

Two significant strategies that came from this assessment process were to buy—and not to build—systems, and to buy new systems that are flexible. The assessment also recognized that the availability of new applications on mainframe technology was limited; this suggested that Duke should migrate toward a distributed computing environment. The assessment further concluded that it will be important to review and redesign business processes prior to the introduction of new technology. In addition, the preferred solution is to replace systems if feasible and not repair "Year 2000" problems.

In April 1995, a team was formed to develop a vision for radical and dramatic improvement in performance of the procurement process. The key drivers creating this opportunity were:

* the dramatic shifts taking place in the supply chain resulting, in part, from significantly fewer suppliers and many more partnerships;

* the continuing trend for organizations to fundamentally change their purchasing processes in order to reduce costs, simplify work, and focus on their core competencies; and

* the revolution in business-to-business electronic commerce, which is driven by the advances in global networking and client-server computing.

Procurement customers represent many constituencies. Through a series of focus groups with business managers, academic support staff, faculty, and senior management in the University, Medical Center, and Hospital, as well as Purchasing department employees, the Vision Team collected information and opinions from customers. Based on focus group data, the Vision Team learned that to address customer concerns, the procurement process must "SERVE" the customer by delivering:

The procurement vision is to procure the right goods (i.e., quality, service, reliability) at the right time (i.e., delivered when and where needed) for the right price (i.e., full value for each dollar spent). Goals of the redesign effort include greatly improved customer satisfaction and substantially lower transaction costs.

The vision foresees managing 90 percent of purchasing through an electronic ordering process with same- or next-day delivery. Customers will do most ordering using an electronic catalog on their desktop computers. Items will be placed in the electronic catalog as the result of enterprise-wide contract negotiations with suppliers by a supplier management team. Because suppliers are enabled to lower prices by increasing volume and exchanging purchasing transactions electronically, this could result in potential savings to Duke of up to several million dollars annually. A procurement card will be available to customers for purchasing immediate-need, low-dollar items. A well-trained customer relations team will assist customers with every aspect of purchasing.

The procurement vision was completed in September 1995 and approved by the steering committee and senior officers. It was also presented to employees, faculty, and other staff for feedback and comment.

The Detail Design Team began work in October 1995 with five goals:

* Redesign purchasing so customers can easily complete a purchase either electronically or via a procurement card.

* Maximize vendor relationships—fewer vendors, better contracts.

* Develop value-added jobs for staff; define training needs and create career paths.

* Do away with the bureaucracy created by too many rules. Push decisions and accountability "down" in the organization.

* Set a model for change management that others will want to follow.

The team took the high-level vision and created the detailed steps of the new procurement process, and then determined the organization and technology needed to support it. As a first step, the team divided the new procurement process into seven sub-processes:

* manage suppliers

* prepare requisition

* place electronic order

* place order with vendor

* handle returns

* receive goods

* make purchases using a procurement card

Small working groups analyzed each of the subprocesses in terms of process characteristics, metrics, benefits, roles and responsibilities, management, culture, and technical information and requirements.

The team then divided into two subteams to develop detailed organizational and technical design solutions. The objectives of the design subteams were:

Organizational Design Subteam

* describe organization, staffing, jobs, career paths, and incentives

* mesh technical and social elements

* develop preliminary plans for training, reorganization, and implementation

Technical Design Subteam

* identify technology to support the new procurement process

* eliminate duplication and reduce redundancies

* replace error detection with error avoidance

The Organizational Design Subteam’s focus was on designing a new organization to meet the procurement vision. In this phase, effort was focused on jobs and not on the individuals in them. The subteam its began work by identifying the changes needed in responsibility, authority, knowledge, skills, and tools to enable customer-contact personnel in the new Procurement Services department to be empowered in their positions and to better serve customers. The subteam conducted individual interviews as well as focus groups with a representative sample of employees covering all current job titles in the procurement process.

The subteam clustered current positions based on the performance of comparable or interrelated tasks. An assessment was made of the levels of skills, knowledge, and orientation required for individuals to be successful in each job cluster. This work served as a building block for designing fewer positions, but with broader responsibilities and more focus on customer service. The subteam noted that jobs in the new organization require more complex and higher level skills than were generally necessary in the current organization.

Two objectives of the organizational redesign effort were to simplify the organization and move accountability to the lowest appropriate level. The results of these changes will be a flatter organization and fewer job titles. The subteam recommended eliminating several management positions and reorganizing employees as work teams. The team structure would replace the traditional hierarchical management structure and requires leaders whose primary organizational skills are training, advising, negotiating, and mentoring.

The organizational subteam recommended the formation of three teams in the new organization, each reporting to a manager who in turn reports to the director of Procurement Services. The recommended teams and their areas of responsibility are:

Customer Relations: Serves as the first point of contact to assist customers with questions and issues. Surveys and assesses customer needs. Investigates and resolves customer problems. Analyzes customer trends. Trains customers.

Supplier Management: Handles contract management and negotiation. Approves and sets up suppliers. Handles vendor disputes. Establishes performance criteria and monitors contract performance. Monitors product standards, utilization, product quality control, and ISO standards. Manages catalog, conducts product reviews, and provides substitutes as needed. Maintains supplier-rating reporting. Provides forecasts and compiles information needed for strategic planning.

Operations: Serves as the functional owner of the procurement application system. Handles LAN management and hardware and software installations, as well as troubleshooting for procurement staff. Issues and monitor procurement cards. Prepares organization budget. Provides administrative support and handles special projects. Processes invoices.

Using metrics from the current process and projecting them for the new process based upon the technology that will be available, projected staffing levels were developed. At the time this paper was written, the new Procurement Services organization projected hiring a permanent staff equaling 37 FTE, compared to 88.5 FTE in the previous Material Support and Disbursements operations. During the implementation phase of the project, the new organization was created and staffed. Large portions of the previous central purchasing organization remained to perform day-to-day operations of the old process during the transition.

The Technical Design Subteam formed several work groups that concurrently addressed specific portions of the new technology for the procurement process.

Procurement System: In January 1996, the Technical Subteam identified a total of 46 possible vendors for the new on-line procurement system. After a series of phone interviews and other contacts, the list was narrowed to 20 who received a request for proposal.

After reviewing the proposals, four vendors were invited to campus to present product demonstrations. The Technical Subteam prepared scripts for the demos that were sent in advance to each vendor. After careful review, the Detail Design Team recommended two viable candidates for the procurement system software: SCS and SAP. SCS provided a reasonably priced, user-friendly, niche product that met virtually all of the requirements of the vision. SAP’s product is an enterprise-wide financial system, the purchase of which would impact other high-level processes at Duke; the functionality of the procurement module of the SAP product meets the majority of the requirements of the vision.

The University’s Information Technology Advisory Committee (ITAC) recommended that a broader view be taken to provide opportunities for effective change beyond the procurement redesign project. The executive vice president appointed the Systems Integration Coordination Committee (SICC) in response to the ITAC recommendation. The committee comprises senior administrators representing the University, Medical Center, and Hospital.

SICC was also responsible for reviewing technical needs for two other work process redesign projects, Student Information Systems and Services and Human Resources, which were launched after the procurement project. Other matters for SICC’s consideration included infrastructure needs and "first project" issues. Examples of the infrastructure and first project issues were the selection of the relational database and the determination of client/server support requirements. As SICC reviewed the client/server system options for the new procurement system, OIT’s technology strategies proved to be important in offering direction.

After a detailed review by SICC, SAP was selected as the preferred vendor for the new procurement system. Significant factors in the decision were technical fit, functional fit, robustness of function for procurement and comprehensive accounting, price, and risk. These factors were even more significant for the Medical Center in light of the constantly changing healthcare environment. For the Duke application, SAP provided a higher functional fit at lower cost and was able to effectively address the possibility of increased risk. Duke and SAP entered into a contract in August 1996.

Procurement Card: The procurement card work group obtained information from eight vendors via a Request for Information. Three vendors were invited to campus to give product demonstrations. Of these, only one vendor, GE Capital, met enough of the vision requirements to remain a viable candidate. A contract was signed with GE Capital and pilot implementation of the software began in October 1996 with several departments.

EDI/EFT (Electronic Data Interchange/Electronic Funds Transfer): This working group narrowed the vendor search to those who could: (1) provide a turn-key solution (VAN, translation software, implementation assistance); (2) handle the broadest spectrum of electronic data interchange (EDI) transaction standards; and (3) provide translation software compatible with hardware meeting Duke's institutional technical specifications. Detailed discussions were conducted with three vendors. After extensive review, the recommended vendor was Sterling. A contract was signed with Sterling in September 1996. The team also outlined a plan for electronic funds transfer (EFT) with Wachovia, the University’s primary banking institution.

Storerooms: The Storerooms working group interviewed storeroom managers to understand the business transacted, the major customers, and the products stored. From this analysis, it became clear that the service provided by storerooms is important to researchers and others. The working group recommended that Procurement Services’ senior managers research several possible outcomes. The managers recommended that Duke outsource the storeroom operation to a vendor. VWR Scientific was chosen as the vendor and began operation of the storerooms on July 1, 1997.

IT Tasks: The IT Tasks working group analyzed system operations and troubleshooting. The primary objective of this group was to identify and detail all needed IT-related tasks and, in conjunction with OIT, to determine which organization—Procurement Services or OIT—would perform and be responsible for each task. Fundamentally, OIT will be the technical owner of the on-line procurement system and will oversee hardware, technical software, and database maintenance tasks. Procurement Services will be the functional owner of the system, handling usage and modification issues. During implementation, the IT tasks will be further discussed and refined.

A project of the size, scope, and importance of the Procurement Implementation requires a qualified implementation team as well as strong executive involvement and oversight, which allows project managers the flexibility to direct the day-to-day work of the team. Project governance begins with an executive committee comprising senior officers, which meets quarterly to monitor progress and evaluate results. A steering committee of senior administrators meets weekly to provide direct project guidance.

The management team includes the project’s senior managers, each of whom has responsibility for project subteams, and the senior SAP consultant. This group has a standing weekly meeting, and often meets more frequently on an ad hoc basis.

The 40-member project team is divided into nine working subteams:

Functional Subteams

* Accounts Payable: develop new systems of payment

* Actions: assessment, communications, and training; develop system roll out

* Catalog: develop electronic catalog with SAP-partner vendor

* EDI/EFT/Fax: test EDI; research EFT and Fax options

* General Ledger: develop system variations

* Purchasing: develop new system of obtaining goods and services

Technical Subteams

* Basis: install hardware and SAP infrastructure

* Development: write interfaces to transfer data to new system; design interface with current general ledger

* Security: develop end-user security scheme

Team Building: The third stage of work process redesign—project implementation—began in October 1996 with a five-day project team kick-off, which included team-building exercises, training, and project history presentations. In addition, the management team participated in a two-day retreat with team-building and planning sessions.

Team Training: During the early stages of implementation, members of the project team attended extensive training on using SAP and other applications. One staff member coordinated the training schedule and related travel to ensure consistency in preparations and compliance with the comprehensive training plan.

Communications: During the implementation phase, communications has been critical both to end-user departments and team members. The project team employed a number of tools to keep constituents informed:

External

* Departmental Presentations: Team members visited departments across campus and made presentations about the new systems and procedures.

* Procurement Services Newsletter: monthly; target audience is end-users

* Web Site: serves as extensive reference tool and project update source for end-user departments

* Procurement Services’ Users’ Group: on-going focus group comprising business managers from representative departments; meets weekly

Internal

* Lotus Notes Groupware: primary communications tool for team to share information, issues, and documents

* Team Meetings: The project team meets biweekly; the nine subteams have weekly meetings.

* Common Work Space

Following initialization and the establishment of the project’s infrastructure, the team worked on three important middle stages of implementation. The first was to develop a procurement prototype using the SAP system. Following was a three-month "proof of concept," a short-term demonstration using the new technology in a Duke department. The Facilities Management Department (FMD) used the procurement prototype to generate purchase orders for maintenance and repair supplies from four suppliers. Lessons learned during the proof of concept were incorporated into the procurement design and will prove beneficial during implementation and roll out.

The third—and critical—step in implementation was the gap analysis, in which team members and SAP consultants reviewed in detail Duke’s new procurement process and assessed its functional "fit" with SAP. Once gaps were identified, the project team decided to change business processes in most instances; in five minor cases the team agreed to modify the SAP system, with approval of the Steering Committee. The gap analysis also defined other needed programs needed for conversion, interfaces, and reporting.

While the proof of concept and gap analysis were underway, members of the technical subteams designed the new procurement system’s technical infrastructure. The design included hardware, databases, and application software.

Hardware and Software: Following the SAP R/3 application decision, Oracle was chosen as the relational database management system and IBM SP2 as the hardware platform. The R/3 application is a three-tier client server application, which allows for a number of application servers to maintain performance. The R/3 system is robust, but is also hardware-intensive.

The R/3 system is housed in two SP2 frames, with three nodes within each frame. The SP2 high-speed switch provides a private network for node-to-node communication at 1.6 gigabytes per second. Six SP2 nodes support four R/3 systems. These systems are Development, Integration Test, Production, and Training; there are multiple clients within three. The systems have four gigabytes of memory and 240 gigabytes Serial Storage Architecture (SSA) disk drives, with the Development and Production systems disks mirrored. The Production system is different from the other systems with the database server and the two application servers on separate high nodes utilizing the three-tier architecture for performance. The illustration below shows the physical view of each system and node.

The configuration of modules occurs in the Development system. There are multiple development clients, one "golden" client, and other "sandbox" clients for prototyping or evaluation of new configurations. The configuration and programs are transported to the Test system for integration testing, and then transported to Production following approval. Any systems corrections are applied to the Development system and follow the transport path as well. The illustration below shows the logical view of the systems and clients.

A tape robot system on the mainframe MVS system is used for backup. Additional hardware servers were required for the electronic catalog, fax, and EDI software packages.

The illustration below shows an overview of the technical infrastructure.

During departments’ budget preparations, the project team provided information on determining workstation needs for the new procurement systems. The process included identifying departmental staff who will use the systems and the profile that fits each staff member. The workstation specifications included a minimum configuration for existing workstations as well as a recommended configuration for new workstations that would be expected to have a life of three to four years. The chart below shows the recommended configuration for new Windows-based workstations.

________________________________________________________________________

Recommended Standard Configurations

Recommended Systems: New Purchases (through December 1997)

________________________________________________________________________

Technical staffing included new positions in addition to current staff. The team used a strategy of contract-to-permanent employment for most of the new positions. New positions were required for the R/3 systems administrator (R/3 S/A) and the R/3 security administrator. The systems administrator is responsible for installation and upgrades, the correction and transfer of the application, and performance monitoring. This position is key to the project and requires UNIX systems and Oracle database administration skills in addition to SAP R/3 experience. The security administrator is responsible for application security, access, release strategies, and serving as back up for the R/3 S/A. Other Basis team members include an Oracle database administrator and a UNIX systems programmer to provide AIX systems administration.

The Development team included business analysts and analyst programmers. Their functions include: assisting the functional teams with configuration; developing conversion, load, interface, and reports programs; and making any approved modifications. To support the new electronic commerce function, an EDI coordinator position was created. In summary, 8-10 technical staff members were assigned to the project.

Three staff members will be required for ongoing client /server system support: one help desk specialist and two user services specialists for desktop support. The support model is based on a "local heroes" concept, relying on departments’ technical expertise and expert users. OIT cannot centrally support the large number of users due to limited staffing and funding resources.

Consulting services were contracted directly from SAP. This was the result of Duke’s decision to mitigate risk since SAP had little experience in higher education. Duke was reluctant to involve third-party consultants. SAP was amenable to this request since it gave their consultants direct access to a unique client: one that is both a major research university and an internationally recognized healthcare organization.

SAP’s staffing included a project manager and functional consultants for the financial, controlling, and material management modules. These services were required full time during implementation. Other consultants—for Basis, Security, and EDI—were used as required.

The first software installation occurred in December 1996; R/3 version 3.0e was installed and used for system orientation and functional training on site. In May 1997 version 3.1g was installed in order to have the availability of Internet-enabled user interface for some functions. The upgrade to version 3.1h was completed in October 1997; the team decided to upgrade to this general release prior to the "go live" date. The Basis subteam performed these installs and upgrades with no problems.

Determining the project schedule and a back office "go live" date has been a major part of the implementation phase. Just before the completion of this paper, the project’s go live date was set as April 6, 1998, with full departmental roll out expected to begin three to six months afterwards. In the interim, five representative pilot departments will begin using the system. The assessment of the system and any necessary revisions will determine the final roll out timeline. The illustration below shows a high-level view of the remainder of the implementation schedule.

The Procurement Implementation team has learned a number of lessons during this project:

A smaller project team working full-time is preferable to a larger team with some members working full-time and others working part-time. While Frederick Brooks raised similar concerns in his classic The Mythical Man-Month, resource-availability issues and the university standard of consensus building forced this project into relying on a team that exceeded 40 members. A significant number of team members had responsibilities to other departments and could not devote full time to project tasks. Their lack of availability caused problems during the critical integration-testing phase. The larger number of team members also meant that project managers spent mission-critical time on managing team communications.

The scope and significance of infrastructure and first project issues also should not be underestimated. The installation of new Oracle databases and the new SP2 required team members and other technical support staff to learn a great deal in a short period of time.

Project managers should not underestimate the amount of time required for the functional staff to define the redesigned work processes. Nearly everything about the processes is new, and the staff members are new to their redefined positions as well.

The amount of time involved in the scheduling process, as well as achieving buy-in from major stakeholders, should not be underestimated.

The team also discovered issues with a procurement-only implementation. SAP is a very integrated system, and several extra input and output interfaces were required.

Another significant challenge has been the culture and business process changes that must occur in the organization. Duke has faced the resistance to change at all organizational levels in the described project phases, but has yet to encounter the difficulties anticipated during procurement roll out to the Duke community. The impact of resistance and the time needed to work on change management are significant. These should be anticipated and addressed, using internal resources with significant change management expertise, if available, or external resources, if necessary.

Endnotes:

1 "Business Process Reengineering, Gateway Management Consulting," Section I: Overview, p. 33. 1993, 1994.

2 The Top 5 Cost-Cutting Methods chosen by 200 senior executives to increase effectiveness are automation-91%, reengineering-85%, downsizing-58%, restructuring-53%, and outsourcing-34%. Ibid, Section I: Overview, p. 10.

3 Ibid, Section I: Overview, p. 28.