1. Introduction

Anecdotal evidence from recent efforts to deploy Web-enabled procurement at companies such as AMD and Boehringer Ingelheim Corp., indicates that such moves create "a massive reengineering challenge" [27, quoted in the original]. Why is this so? Why can't organizations simply purchase and install an off-the-shelf software package that supports procurement functions that use the Internet without encountering a massive reengineering challenge? Is the experience at organizations like AMD simply anomalous, or are they likely to be typical of other organizations following a similar path? Are the challenges any greater, lesser or just different if we address the procurement of contracted services instead of the procurement of supplies for maintenance, repair and operations?

The purpose of this paper is to explore four research questions that follow from these simple inquiries through an action research case study performed at the Office of Naval Research. The ONR study focussed on reengineering the procurement of contracted research services. The procurement of contracted services is a topic that has not appeared in previous studies of Web-based electronic commerce [cf. 8, 9, 14, 26, 32]. As such, the first question addresses, how is the procurement of contracted services in an organization like ONR similar to, or different from, other common procurement activities. The second question examines, what is involved in reengineering the processes for procurement of contracted services. The third research question investigates, how can information technologies for Web-based process management play a role in facilitating the reengineering of contracted service procurement . Finally, the fourth question identifies what kinds of challenges can make the transition to Web-based procurement processes problematic, and how can these challenges be resolved. Background discussion and related research in Section 2 on business process reengineering (BPR), electronic commerce (EC) and information technology (IT) for process management can be used to formulate initial answers to these questions. However, developing grounded answers to these questions requires an empirical investigation. This is the purpose of the case study at ONR found in Section 3.

The paper describes an approach, technology, and case study for understanding, redesigning and transforming procurement processes and information work environment for a complex, multi-site organization. It begins with a background that characterizes what must be understood in order to redesign and transform the procurement of services, specifically R&D services supported by contracts and grants from ONR. The next section provides an overview of related research used in the case study that follows. Through the ONR case study, six challenges for what's involved in understanding, redesigning and transforming procurement processes to utilize Web-based EC capabilities are identified and addressed. A discussion of these challenges and the consequence of their resolution at ONR follows. Finally, the conclusions reexamine the four research questions that motivate this study.

Through this effort, a dramatic reduction in the cycle time by a factor of 20 was achieved, while operational cost savings worth $10M-$15M per year were identified and mobilized. The case study thus serves to explain how these results were accomplished by overcoming challenges in place at ONR.

2. Understanding service procurement and how to reengineer it

Procurement typically refers to organizational activities associated with the purchase of raw materials and production goods, supplies for maintenance, repair and operations (MRO), as well as for capital goods. Materials, supplies and production goods are generally items that can be found and described in catalogs, then purchased in quantity units per transaction. The procurement of items like these is a focus of research and practice for how EC may be applied in organizations through Internet-based procurement processes [3, 8, 9, 14, 27]. Nonetheless, many organizations also procure contracted services of one kind or another. Services may or may not result in the delivery of materials, supplies or goods. Services instead may provide new, enhanced, or sustaining capabilities to an organization.

R&D service contracts (including research grants) often expend amounts between $10K-$10M per year. At ONR, the average expense for a research contract is about $100K per year. As a result, fulfillment of contracted services procurement usually takes months or years to complete. Similarly, due to the high cost, governance and management controls associated with service contracts of this kind, the procurement of research service is usually not a single purchase transaction. Instead, it is a sequence of incremental procurement actions over the course of a contract. Long duration contract service procurements, such as a research grant, give rise to many short-term procurement actions. Subsequently, the structure and workflow of short-term service transactions in the context of a long-term fulfillment become the focus of what must be redesigned and transformed in order to utilize Internet or Web-based EC systems associated with the procurement of contracted services.

2.1 Understanding the procurement of contracted services

The authorization and obligation of start-up or incremental funding are common actions when procuring contracted services. Such actions obligate funds and designate budget line items in the corporate treasury to be charged, which in turn are exposed for expenditure draws, subject to various corporate accounting policies and auditing controls. Invoices submitted by service providers can then be paid, for instance via Electronic Funds Transfer (EFT). Progress payments to pay for incremental or ongoing services are made until the funding authorization is exhausted, changed or rescinded, subject to other terms and conditions stipulated and agreed to in the contract. In order to redesign the processes for procuring services such as R&D, details such as these point to the control logic, pre- and post-conditions (i.e., business rules) associated with different procurement process steps or workflow actions. Similarly, these details begin to identify the types of information entities that procurement participants may need to access, update or manipulate through an Internet-based user interface to underlying EC applications. Examples of these details are presented later.

2.2 How is service procurement at ONR the same/different than other government organizations or commercial enterprises?

Acquiring R&D services is big business. The acquisition of R&D services represents a substantial area of procurement actions and expenditures within the U.S. Government, with total U.S. Government outlays for R&D services in 1998 exceeding $70B [25]. Understanding how procurement processes at ONR may be redesigned to use Internet-based EC capabilities may shed light on how it may be applied in similar research acquisition settings. Thus, a substantial opportunity exists for exploring how Internet-based EC can be applied to support the acquisition and procurement of R&D services. However, things may be different in the private sector.

Few corporations, if any, acquire scientific research services from external sources at the total dollar level or total number of procurement actions compared to ONR or similar Government agencies. Nonetheless, a large portion of corporations and non-research oriented Government departments frequently acquire contracted services of various kinds (E.g., consulting, engineering, and facilities management) from external providers. These acquisitions may come in the form of service contracts, sub-contracts, or other outsourcing arrangements. Thus, this study can help highlight issues and challenges that can arise when a large organization seeks to redesign its procurement processes for contracted services to take advantage on Internet-based EC capabilities. A foundation for these capabilities now follows.

Two areas of related research bear on this study. These are business process reengineering and EC. Each is addressed in turn, though the results cited will be framed in terms of their application for procurement processes. Also, the process-driven IT employed in this study is introduced and described.

2.3 How to reengineer business processes like procurement?

Following the work of Hammer, Davenport and their colleagues, existing as-is procurement processes should be either obliterated rather than automated [13], or else understood and measured [5]. Accordingly, innovative to-be procurement processes should be prototyped using leading-edge IT as a new foundation for coordinating research grants management activities [5]. However, the ability to successfully realize the benefits of radical IT-based changes in most business processes has been elusive.

Reflective studies of the problems, pitfalls and best practices of BPR find that certain organizational variables, rather than IT, are key to achieving successful BPR outcomes [1, 12]. In many of the BPR projects examined, BPR failure was reported to be the outcome about 70% of the time [1]. How can BPR failure be avoided when redesigning procurement processes? Available research results indicate that critical conditions to help realize successful BPR should include the participation and commitment of top management executives, empowered workers, shared vision, realistic expectations, changes in worker roles and responsibilities, new performance measurements, worker incentives, and the like [1, 12]. Conversely if these organizational conditions are insignificant or missing, then we should expect the application of BPR to processes like procurement to fail.

The dilemma of how to realize the benefits of a successful BPR project, while avoiding the likelihood of failure, gave rise to a series of empirical field studies and surveys to track down the source of variation and causality. Results from representative investigations [2, 6, 10] emphasized the importance of addressing BPR implementation within the broader context of organizational change in a complex socio-technical environment [cf. 17]. For instance, some organizations may choose to reengineer a set of processes over time, in order to learn from what succeeds and what fails [2]. Applying a lesson learned from Caron and colleagues [2] to procurement reveals that BPR efforts should be implemented bottom-up by the process end-users, rather than imposed top-down by senior management [cf. 13], to succeed. Following this, senior management should provide the strategic vision for an effort to redesign processes, such as procurement, that empowers process staff to participate in directing and implementing the effort [6]. Similarly, change management strategies and techniques, technological competence, tactical planning and project management, and training personnel for to-be processes, should be factors related to success when redesigning procurement processes [10]. Subsequently, drawing from the emerging theoretical basis of BPR [15], when redesigning procurement processes, focus should be on the creation of an organizational environment that supports change management strategies, learning, knowledge sharing supplemented with IT, internal and external partnering, and measurable process improvements, as prerequisites for BPR success.

Finally, recent studies of BPR establish ties between process change and their consequence on organizational performance. For example, applying the results of Guha and colleagues [11], reengineering procurement processes should require the creation of a learning organization where the interdependencies between the change environment, process management and change management. Following [30], when redesigning procurement processes, management controls of organizational resources, such as procurement expenditures, must remain effective though perhaps in a more streamlined manner.

2.4 How is Electronic Commerce Research Related to Procurement Processes?

Procurement has been identified as one of the key areas for the application and integration of EC tools and techniques [14]. However, the relationship seems to primarily emphasize the use of EC to support the procurement of MRO commodities, supplies or goods, rather than contracted services. How to best support contracting, contract management, and negotiation in the context of EC is seen as a topic for future research [24], yet procurement contract management processes are central to this study. Emerging theory on EC points to the need to understand business processes in terms of the interdependencies of variables such as business partnering arrangements [26], networked IT infrastructure design [31], and transaction (governance) costs [32]. Thus, we should assume these interdependencies can arise in the context of applying EC technologies and techniques to contracted service procurement, and so they should be investigated.

2.5 Redesigning Procurement Processes with IT for Process Management

Research results in BPR draw attention to the need to focus on change management and process management. Change management draws attention to understanding and transforming work activities, the organizational setting and the ways participants act towards both. For process management, we choose to understand, analyze, and engineer complex organizational processes using process-driven intranets (PDIs) supported by a knowledge-based systems approach [19, 23, 28, 29]. The PDI and underlying technology developed at the USC ATRIUM Laboratory in the mid-1990's (and possibly appearing somewhat dated) are not the focus of this paper, but they are described elsewhere [23, 29]. Instead, attention is directed at the approach taken for process management, and the role the PDI played in supporting this approach.

The incremental specification and system-based interpretation of business process representations is central to this approach. Such representations can be designated as organizational process architectures (OPAs). An OPA denotes a structured, software-based representation of the object, attributes, relations, methods and constraints. These representations collectively define and link the structure and flow of work processes within an organizational and technological context [29, 22]. Such a computational representation is more than a graphical workflow specification; it is instead an ontology that specifies the structure and definition of relationships between objects denoting who does what, where, when, why and how in the course of enacting work processes. Description of the ontology is found elsewhere [19, 28]. Using such an ontology, OPAs can be formalized as knowledge representations (semantic networks) that model the web of processes, products, people (roles and workgroups), information infrastructure, and tools central to an organization in its routine and ad hoc work operations [17, 19, 28, 29]. Highlights of the activities associated with development of OPAs now follow, since their details appear elsewhere [28, 29].

In simplest terms, support for understanding and redesigning business processes entails the development of OPAs through knowledge-based engineering of the process life cycle [28, 29]. PLC engineering is a technique for process management [4], rather than a BPR methodology practiced by industry consultants [16]. Process management subsumes common BPR activities such as process modeling, visualization, analysis, simulation, redesign and prototyping. Our approach to process management adds support for these capabilities across multi-partner (virtual) enterprises and multiple settings [23]. Similarly, it adds Internet-based IT mechanisms for integrating multiple distributed processes, automated process-driven IT environment generation, semi-automated process enactment, automated enactment monitoring and history capture (plus replay), recovery from process enactment failures, and process asset management, as part of its life cycle [23, 28, 29]. None of these capabilities are specific to procurement processes, and thus these capabilities can be used to support any organizational process whose OPA can be formally modeled following our approach. However, these capabilities provide an Internet-based IT infrastructure to rapidly configure, prototype and instantiate a PDI that can serve as a collaboratory for process reengineering [cf. 18]. Such a PDI provided a computer-supported learning environment where personnel from multiple ONR sites could share and participate off-/on-site with USC researchers to incrementally elicit, visualize, prototype, refine and integrate organizational processes, using tools and OPAs accessed over the Internet [22, 23, 28, 29]. These were new capabilities previously not used in BPR projects (in 1996-97), though they have been used in other domains [19, 22, 29]. Furthermore, existing tools for redesigning or implementing procurement processes generally lack these capabilities [cf. 3, 5, 14, 27]. Subsequently, our choice was to use this approach to process management to support the BPR of contracted procurement processes by a research team partnered with process end-users.

3. Case Study: Reengineering research service procurement at ONR

In this case study, the BPR focus was directed at the set of four processes of ONR's research acquisition activity: Pre-Award (proposal solicitation [20] and review), Award (funding decision and obligation), Administration (funds disbursement and field office operations), and Close-out (funding completion, reconciliation, and reporting compliance). These four interrelated processes consisted of about 150 as-is process steps (i.e., problem-solving tasks) at ONR, representing up to four levels of process decomposition and supervision. Five regional offices support ONR across the U.S. to facilitate or perform these processes. Thus inputs, outputs or refinements to/from the activities involved in the reengineering effort had to be accessible in locations across the U.S. The choice made was to utilize a collaborative Internet-based information infrastructure for process redesign developed to address this need [29]. Accordingly, collective effort was focused on learning and demonstrating how process life cycle activities could access, support, and deliver procurement processes at ONR offices over the Internet using a PDI and EC service transactions. Examples will be highlighted along the way.

As part of this study, ONR wanted to adopt a corporate-wide intranet to support its internal processes throughout its offices associated with funding and tracking of research contracts and grants. This intranet was envisioned by senior management at ONR to eventually use EC tools and techniques, in line with emerging Government EC initiatives [7]. Senior management's long-term goal at ONR was to evolve this intranet to integrate and support EDI for research grant paperwork submissions, EFT for funds distribution, and various information repositories to organize, broker, track, evaluate, and report on funded R&D project activities. Nonetheless, the existing IT-based systems at ONR operated mainly as independent systems.

3.1 Challenges in redesigning ONR procurement processes for Internet-based EC

Understanding and modeling the situation at hand was the first goal [5]. Through a series of meetings and initial process elicitation, we came to discover a number of challenging problems had to be addressed in redesigning ONR's acquisition processes to eventually accommodate a multi-site corporate intranet. Six such problems became apparent:

Personnel at ONR were unfamiliar with the concepts, techniques, and tools for understanding and redesigning their work processes. This seems true of organizations that have not undertaken a process redesign effort [1]. Thus, we could not expect that ONR personnel could readily describe or articulate high fidelity specifications of their work processes and arrangements, though they work within them on a daily basis. Most of their knowledge of these routine processes had become tacit. Thus we and they had to collectively educate and share with each other how these processes operate, the operational problems arising during these processes, and how these processes might be changed and streamlined [15].

ONR had a heterogeneous computing infrastructure and isolated information systems that often made information sharing problematic. ONR possessed the basic compliment of Internet-based systems and infrastructure needed to conduct EC. These systems included TCP/IP LANs with Internet connectivity, secure web server and web browsers installed on desktop PCs. ONR also employed a database system for managing procurement actions, a second database system used by field offices for contract and grant administration, and a third database system outside of ONR under the control of the U.S. Dept. of Defense Comptroller for tracking ONR's expended funds. In addition, ONR employs an experimental EDI testbed, and various data analysis and management reporting utilities. However, all these capabilities existed as distinct stand-alone systems. ONR stipulated that these legacy systems could not be thrown out or bypassed. Instead, they must be incorporated into proposed redesign alternatives. Implementing an intranet thus would require bridging and integrating these heterogeneous "islands of automation" [22].

There was recurring difficulty in efficiently managing and tracking research grants funding expenditures. The management of contract service expenditures was not a routine everyday activity at ONR, compared to the four research acquisition processes. Instead, it was an ad hoc, on-demand process to gather, summarize and report data on the status of overall procurement funds from different financial databases accessed or maintained by ONR. Demand for expenditure management updates could be triggered by programmatic changes in budget authorization or unexpected budget shortfalls/surpluses. However, relevant data was located in different information systems or personal information spaces. Elements of this information were said to be inconsistent, depending on whose "numbers" staff could access and when.

There was a lack of trust and lack of data integrity controls in existing data sets. This gave rise to problems higher up in the organization since decision-makers need timely access to current budget totals for procurement funds obligated, encumbered, and expended across different categories and research programs [cf. 30].

There was limited visibility and slow response to external customer inquiries (from outside agencies using ONR research grants management services) on the status of pending funding actions for research proposal grants to be awarded. Untimely delays or inconsistent data could lead to loss of obligation authority for funding contract procurements inside ONR or its funding partners (e.g., DARPA), due to Federal budgeting process constraints and DoD financial controls. These constraints and controls had to be maintained, while conformance to them needed to be streamlined [cf. 30].

Can all of the five preceding challenges be concurrently address via an approach to process management that incorporates organizational transformation, process redesign and Internet-based systems integration? The basic issue here is to avoid development of an ad hoc, piece-meal, or point solution to each of the preceding challenges, and instead pursue a collaborative, comprehensive and integrated solution.

Subsequently, this set of challenges suggests that redesigning research service procurement at ONR would be a major undertaking [cf. 27].

3.2 Addressing the challenges

The USC research team came to the view that the preceding problems were interrelated. Thus, the solutions to these problems should also be related. For example, data integrity problems were assigned a top priority by ONR senior management for action. Subsequently, process redesign would need to provide upstream data quality checks to minimize the likelihood of getting inconsistent data into the systems [12, 30]. One goal of process redesign would need to address how to make sure that people who were most interested in getting correct data input to a process were enabled and self-motivated to do so. For instance, the principal investigator or institution that submits a research proposal to ONR should be capable and well-motivated to correctly enter data pertaining to their proposed budget, schedule of deliverables, and surface or electronic mail addresses for receiving payments. However, this was a to-be vision. In the as-is condition, different ONR staff would re-enter such data in various procurement steps, in different organizational locations, in different formats into different information systems. This adds no value to the data, but instead increases the likelihood of error, data inconsistency, process workarounds, and subsequent processing delays. Providing Web-based input forms and corresponding ONR server-side database entry routines could support such a redesign [5, 13]. This in turn could eliminate some of the existing as-is process pathologies that compromise data integrity.

Subsequently, the process redesign team found the other challenges could be resolved through a series of solution steps that bring people, processes, work products, and extant information system technologies into alignment. A description of these steps now follows.

Step 1: Facilitate collaborative understanding, redesign and transformation of ONR processes.

Procurement organizations are populated with personnel that are usually not specialists with advanced information technology. They cannot be expected to already be familiar with a wide range of intranet tools or EC concepts. This was true at ONR. Furthermore, they might resist the intervention by "outsiders" whose purpose may be perceived as eliminating their jobs or reducing their administrative autonomy through a process redesign effort [cf. 1, 2]. Nonetheless, ONR like other government agencies is under substantial pressure to accept increasing workloads, improve organizational efficiency and effectiveness, and reduce operational costs, all within shrinking operating budgets.

Understanding the as-is and to-be OPA of research procurement processes at ONR benefited from the involvement, participation, and intellectual engagement of personnel from the top to the bottom of the ONR organization [1, 15]. The USC researchers needed to educate ONR personnel on our motives, methods and capabilities; ONR needed to help us learn about the generic, circumstantial, and problematic variants of their work processes and information flow [10, 11]. Two or three iterations of process elicitation, analysis, visualization and redesign refinements were typically performed, particularly with key process end-users, process owners or subject-matter experts. Follow-up validations and refinements by other personnel not necessarily involved in earlier iterations were also performed. Furthermore, a shared vision and constraints were established early on between the research team and ONR personnel covering the following items [cf. 1, 6, 10, 15]:

• the USC research team would identify opportunities for optimizing the redesign of work processes, information flow and information integration (see Table 1 for examples);
• effort would be directed at improving personnel effectiveness and workflow without increasing anyone's workload--personnel had to be more satisfied with the new redesigned work arrangements than with the status quo;
• no new personnel positions would be created or added, but responsibilities could change;
• four ONR acquisition processes examined would be developed in three forms: as-is (legacy form), to-be (alternative process architecture), and here-to-there transition forms (steps taken in 30 day increments to progressively transform the organizational work patterns and processes from the as-is to to-be forms--see Table 2 for examples).
• all intermediate and in-progress results would be posted on the USC ATRIUM web site, so ONR personnel could access this information over the Web at their discretion, and provide questions or feedback via email, telephone or face-to-face meetings;
• ONR personnel would make final decisions on the selection, prioritization and schedule of process redesign alternatives to be implemented;
• any process improvements to be implemented had to be self-motivating or enable local organizational incentives to increase the likelihood of their successful implementation and routinization.

One key aspect of the collaborative strategy for redesigning procurement processes at ONR was the ability to identify multiple alternatives for how the process structure or flow could be streamlined. Accordingly, the USC researchers identified ten possible process redesign options that could be applied in different parts of the procurement process at ONR. Table 1 presents these in the following manner. The first column identifies the "process diagnostics" that characterize some part of the as-is procurement processes at ONR, derived from measurements on the OPA [27]. The second column identifies the corresponding redesign opportunities [12] or "process redesign heuristics" [29] that seek to resolve the problems associated with a process diagnostic [20, 21]. The final column represents a collective, subjective assessment by the USC and ONR process redesign team for the expected return on investment if ONR were to provide the resources required to successfully implement the corresponding redesign heuristic. No robust cost analysis or attendant effort to collect cost data was performed. Nonetheless, ONR decision-makers were comfortable with such an assessment, given the openness of the process redesign and assessment activity, discussion and perceived outcomes [1].

As may be apparent from Table 1, multiple overlapping process redesign alternatives exist, but with varying perceived returns. Most of the redesign heuristics point to a new information infrastructure for procurement that manages new or existing information entities with new/legacy tools or process automation capabilities that could be integrated with Internet-based technologies. But to do so would require making many changes in how procurement processes work at ONR. The USC researchers were responsible for proposing process redesigns, then prototyping and demonstrating the resulting information infrastructure for the redesigned procurement processes. These results could be turned over to one or more commercial IT service contractors ONR uses for final implementation and ongoing production support. ONR personnel were then responsible for choosing which process redesigns to pursue, resource and implement. In the end, ONR personnel selected all but one of the redesign alternatives, with the exception being the rule-based contract document builder.

ONR needed to implement the proposed changes from the as-is to to-be forms of the procurement processes and information infrastructure. The process redesign team in conjunction with many others at ONR then developed and refined a here-to-there transition plan which relevant ONR personnel had to approve and commit the necessary resources. Table 2 provides a sample from the 25 transition steps that characterize the priority and level of resources/effort needed to incrementally make the requisite transitions from as-is to to-be procurement processes.
 

Entries in the left column denote an organizational and/or technological transformation. The corresponding priority and schedule for implementation appear in the right column. Selected results from transformations such as these are described below, as well as in related papers [23, 29].

Step 2: Iteratively prototype, demonstrate and refine a PDI for ONR procurement processes.

Figure 1 shows one example step (in a then current Netscape 1.2 browser window in 1996) within procurement processes at ONR. This step is part of the Pre-Award process, whereby a research investigator (a user role) submits a proposal to ONR for funding consideration. As part of this step, the investigator enters data needed by ONR for logging and tracking subsequent actions pertaining to the submitted proposal. This includes identifying the proposal file to be submitted for upload or transfer to ONR. When the user satisfactorily enters the requested data, the transfer is initiated by selecting the "Done" button. After this, the user can then select the "Next Task" from a list of those ready to be performed. Although not shown, it is a similar step whereby the investigator submits an electronic budget form that accompanies the proposal submission. Finally, the frame in the bottom right that displays the history of steps done as a way of recording the in-progress status of each cycle through the process. In this way, multiple concurrent process instances (i.e., procurement action requests in progress) may be active in different steps at any time. Users can select the one the wish to work on by selecting from the "available tasks" (not shown here) form maintained in a repository for user-role, process-instance status. Depending on auditing requirements, other attributes indicating the date and time of step completion, PC network (IP) address, etc. can be recorded and later replayed or analyzed for process improvement opportunities.

Figure 2 displays the resulting proposal object attribute values that are uploaded from the user client to the ONR database. This view simply provides the user with a validation of data submitted, and requires no further action on the part of the user, unless they recognize an error in their data entry [cf. 12]. Nonetheless, the data that is posted can be automatically entered into a logging procedure for proposals submitted to update pending procurement actions in the ONR corporate procurement database. This information can similarly be used to automate the notification of proposal received to relevant ONR divisions as well, as required in one of the transition steps noted in Table 2. Server-side resources control repositories for executable process representations, user role access, and database transactions. Other procurement process steps may also use client-side "helper application" tools for editing data forms/records, preparing correspondence or presentation reporting materials, calculating spreadsheet functions, and database query and update transaction forms. The multi-level scheme used for integrating different kinds of tools, data or legacy applications into a PDI, and the overall system architecture of a PDI are described elsewhere [22, 23].

Last, PDIs provide additional forms of security through fine-grain access control [cf. 3, 14, 30]. Specifically, when users access information through a PDI, they do so by first establishing their user-id, password, and process role. In a process involving many people performing in different roles, the PDI can provide role-specific access to only those parts of the process that a registered user in a designated role requires in order to complete their work. In this way, access to information can be specified and controlled by user-id, user group-id, assigned role or process step. As a person might also have multiple roles in different processes, then access control can be assigned in a corresponding manner. Similarly, access control can be further specified by process step, since traversal of each process step in a PDI constitutes an event or process transaction that can have pre-condition guards, post-condition triggers or other business rules assigned to them [cf. 23]. Fine-grain access controls such as these are now, in 1999, widespread on Internet-based EC sites and applications.

Step 3: Facilitate the tactical challenges of expenditure management, data integrity, external customer queries through Internet-based systems integration.

At ONR, expenditure management was complicated by the fact that the requisite information was distributed across three distinct information systems and across the four research acquisition processes. Each such system had its own administrative authority, organizational location, database, data model, and data format. Subsequently, as-is expenditure management reports and briefings for ONR senior management had to be constructed on an ad hoc basis. This often required manually transcribing procurement expenditure data into PC-based spreadsheets, which in turn were summarized and incorporated into presentation materials (i.e., MS PowerPoint slides). The temporal relevancy of this data was often 3-6 weeks old, whereas $500K to $3M or more might be expended on a workday. Thus, a timely, less cumbersome solution was needed for expenditure management. A view of the proposed solution can now be described.

In Table 3, each of the three rightmost columns represents data managed by a separate database management system and administrative authority. Integrating these heterogeneous databases into a single global database would be an expensive and time-consuming proposition. Therefore this was not a redesign option. Instead, the USC researchers proposed a networked form-based script that provides read-only views through a purpose-built data cache that periodically queries, downloads, reformats, and sorts (using Award and Request Numbers as indices) the funding data from each database. Table 3 shows a representative view integration, although other ONR or provider-specific information is not shown. In addition, ONR's external customers (E.g., Program Managers at DARPA) could query-access this data through their role-specific views and Award numbers from a Web-based PDI user interface in their offices.

ONR personnel indicated on-demand access to an integrated view of funding actions over an intranet would address critical decision-making needs in ways not previously available. This meant stressful, ad hoc processes for expenditure management could be eliminated. Similar integrated data views could be created to display the dates associated with the performance of specified procurement process steps. These would meet other status reporting needs. Linking these tables with common PC tools like Microsoft Access, PowerPoint and WordPerfect would then enable further automation and streamlining of management report preparation, since the required reports and presentation graphics could then be automatically produced within redesigned procurement processes. While these changes propose adding new tools, user access roles and process steps, together they improve the overall effectiveness of research service procurement and grants management. Subsequently, being able to address practical problems such as expenditure management, status reporting and external customer queries may determine the eventual success in being able to apply these results in other settings.

4. Results and Discussion

The relatively ease with which the approach and results reported here can be replicated outside of ONR is a matter of opinion. However, this case study conveys what was done, how it was accomplished, and how it might be applied, reproduced or reused in other organizational settings. For example, utilizing collaborative IT-based process management, the process redesign heuristics outlined in the Table 1, and change management techniques, we observed a substantial reduction in cycle time for PALT. PALT measurements indicate the elapsed time at ONR from a research grant-funding obligation to the time when the grant recipient can begin to expend their funding award. As more than 5000 research procurement actions are performed per year at ONR (1995-1997), a reduction of average PALT from 70 days in 1994-5, to 7-10 days in 1997, to 2-3 days in early 1999 represents a demonstration of successful process reengineering and ongoing improvement at ONR. It also represents what people working together can accomplish when they collaborate in efforts that were specified to make their work practices more timely, more efficient, and more effective through careful understanding and redesign of their OPA. Other proposed transformations such as the adoption and internal distribution of electronic research proposals, electronic budgets and associated procurement actions status tracking would save ONR $10M-$15M per year. Finally, the plan and steps for transitioning ONR to a PDI was developed by a collaborative process redesign team working using a process reengineering collaboratory mobilized for this effort.

The action research method and shared effort agreements were also key enablers for achieving the results described here. Similarly, the OPA and process life cycle tools, techniques, and concepts employed were a key enabler [23, 28, 29]. Last, the capability to provide remote access to our research technologies to external customers and internal users, such as personnel at ONR Headquarters and at its five field offices across the U.S., was also a key enabler helping to affect empowerment, distance learning, process redesign, and change management.

Finally, how do other alternatives to PDIs compare in addressing the challenges encountered at ONR? For example, the Zephyr System [9], and those from vendors such as Ariba Inc. or CommerceOne [27], can be considered a PDI for the procurement of non-commodity parts or MRO supplies, respectively. They differ from the PDI technology used in this study [23, 29] in that they are designed to specifically implement processes for routine procurement and EC. Similarly, none of these other systems were designed nor implemented as a distributed multi-site collaboratory [18]. The PDI technology from USC takes an OPA specification as input, then compiles it to automatically generate a PDI application corresponding to modeled process. This PDI capability can be used to collaboratively model, visualize, prototype, automate, or (re)engineer business processes of all kinds over the Internet, whether or not the processes are related to routine or contracted service procurement. In so doing, it then becomes possible to rapidly create PDI collaboratories for different types of processes, that can integrate different types of data, data repositories, legacy applications, control and version management schemes, and multiple process instances [29]. Thus, while the alternative systems may be successful and easy to adopt or use in their targeted procurement processes, they would seem to be a poor fit for the procurement processes for contracted services at ONR.

Beyond this, alternative systems may use XML based notations for specifying and exchanging procurement data formats as a technique for integrating disparate or heterogeneous systems. However, prior research has already revealed that integrating heterogeneous systems across wide-area networks requires multiple techniques for data, control flow, and process integration [22, 23, 28]. Similarly, the technique used to address the expenditure management challenge at ONR relies on computational methods (i.e., automated processes) to construct and present an integrated view of data from multiple disparate databases. Markup notations like HTML or XML serve to enable Web browsers (or other PC applications) to display or present shared data. Subsequently, view integration is the technical accomplishment that emulates heterogeneous systems integration, rather than the use of a data markup notation. Thus, at best techniques such as XML can simplify data exchange between heterogeneous systems, but they do not address the range of issues or mechanisms needed for systems integration.

5. Conclusions

Four questions motivated this research study. Each can now be reexamined in turn.

First, the procurement of contracted research services at ONR is different from the routine procurement of materials, supplies and goods in a many ways. Contracted services are procured incrementally over periods of months to year in the course of their completion, versus the quantity unit purchase transactions associated with routine procurements. PALTs are a key performance measure for contracted service procurement. ONR like other government agencies in the research service contract business are subject to Federal Acquisition Regulations which add process steps and problem-solving tasks that do not occur in commercial firms. Thus, procurement of contracted research services at ONR is sufficiently different than commercial packages targeted to support routine procurement activities over the Internet would not work without modification, if that is possible. However, ONR is sufficiently like other government research agencies in that understanding and redesigning its research procurement processes may lead to solutions that can be reused in these agencies, and thus contribute in some way to a more efficient federal government.

Second, reengineering the processes for procuring contracted research services at ONR was precipitated by a combination of concepts from BPR and EC together with IT-based process management tools. Nonetheless, the case study also makes clear that reengineering projects must address the organizational situation, the roles participants play in understanding as-is and to-be versions of their procurement processes, and provide a transition path for how to transform the situation, participants and processes. Off-the-shelf software packages that facilitate procurement services over the Internet by themselves will not provide such an understanding of what exists, what's desired, nor how to get from here to there. Change management techniques, collaborative learning environments (PDIs), and process management technologies can however help.

Third, new IT or Web-based systems for process management can play a significant role in facilitating the collaborative understanding, redesign and incremental transformation of procurement processes for contracted services. This appears especially true in an organization like ONR that has multiple field offices in geographically dispersed locations. Procurement processes for research services are enacted and spread across multiple sites, systems, and administrative units. Process-directed intranets represent an appealing choice for providing a wide-area information infrastructure that supports collaborative learning through shared process management activities. PDIs model and enact organizational process architectures. A knowledge-based systems approach to process life cycle engineering of an OPA provides a strategy for how to blend process management activities together with change management and organizational learning techniques. Such an approach differs from conventional EC system approaches where the focus may be aimed primarily at providing only the computational functions needed to conduct purchasing or procurement transactions. Thus, they may not be open to the needs identified in the preceding two research questions (e.g., ability to support FARs, support BPR change management and incremental transformation techniques).

Last, six challenges were encountered at ONR that made the transition to Web-based procurement processes problematic. However, these challenges were specific to this case study, though they might also be found in other settings. Nonetheless, resolving these problematic challenges required an approach to reengineering ONR's processes for procuring contracted research services that provided a coherent, integrated approach to organizational change management and process management. This approach was based on related research in BPR, EC and IT-based process life cycle engineering, that was put into practice and grounded through a three step, collaborative action research strategy. This approach proved successful in this case study at ONR in giving rise to substantial reductions in the cycle time and operational costs associated with the procurement of contracted research services.

Overall, the four research questions that motivated this paper provide a new conceptual framework for understanding problems like how to reengineer procurement processes for contracted services using Internet-based, EC technologies. What is clear from this study, however, is that these technologies alone do not affect a solution strategy, nor do they cause the organizational transformations needed to transition new systems into productive operation. Instead, a more comprehensive approach that combines and balances organizational change management techniques with new Web-based process management technologies provides a promising avenue for further research and practice in reengineering procurement processes.

Acknowledgements

This research was supported by ONR contract N00014-94-1-0889 and the Experimental Acquisition Research Program (EARP) of the Defense Acquisition University by grant N487650-27803. None of the material in this report should be construed as a statement of policy, procedure, or endorsement by ONR, the US Navy, EARP/DAU, or any other US government agency. Contributors at ONR in this study include Jim Carbonara, Dennis Padilla, Diana Nichols, Frank O'Day, Chuck Paoletti, John Starcher, Ann Stuart, Cmdr. Jim Valvocin, Dr. Ralph Wachter, and dozens of others. Capt. Jay Miller, (now at www.ebtech.com) Director of Acquisition at ONR at the time of this study, provided project oversight and senior management leadership. Prof. John Noll at the University of Colorado in Denver, led the effort to develop and evolve the PDI technology used in this research. Cedric Knight of New Directions Technologies Inc. provided valuable field support and consulting services for this effort. In addition, former USC ATRIUM Laboratory researchers, Dr. Peiwei Mi, now at Vigilance Inc., and Prof. Mark Nissen, now at Naval Postgraduate School, contributed to the concepts and techniques employed in this investigation.

References

[1] B.J. Bashein, M.L. Markus and P. Riley. Preconditions for BPR Success: And How to Prevent Failures. Information Systems Management , 11(2):7-13, Spring 1994.

[2] J.R. Caron, S.L. Jarvenpaa and D.B. Stoddard. Business Reengineering at CIGNA Corporation: Experiences and Lessons Learned From the First Five Years. MIS Quarterly, 18(3):233-250, September, 1994.

[3] S. Danish and P. Gannon. Building Database-Driven Web Catalogs , McGraw Hill, New York, 1998.

[4] T.H. Davenport and M. Beers. Managing Information about Processes. J. Management Information Systems, 12(1):57-80, 1995.

[5] T.H. Davenport and J.E. Short. The New Industrial Engineering: Information Technology and Business Process Redesign. Sloan Management Review, 34(4):1-27, 1990.

[6] M.J. Earl, J.L. Sampler, and J.E. Short. Strategies for Business Process Reengineering: Evidence from Field Studies, J. Management Information Systems, 12(1):31-56, 1995.

[7] Electronic Commerce Acquisition Management Program Office (ECAMPO). Streamlining Procurement through Electronic Commerce, National Institute of Standards and Technology, Washington, DC, October 1994. http://snad.ncsl.nist.gov/dartg/edi/arch.html

[8] J. Gebauer, C. Beam and A. Segev. Impact of the Internet on Procurement. Acquisition Review Quarterly, 5(2):167-184, 1998.

[9] J. Gebauer and H. Schad. Building an Internet-based Workflow System--The Case of Lawrence Livermore National Laboratories' Zephyr Project, Fisher Center Working Paper, 98-WP-1030, University of California, Berkeley, April 1998.

[10] V. Grover, S.R. Jeong, W.J. Kettinger and S. Wang. The Implementation of Business Process Reengineering. J. Management Information Systems , 12(1):104-144. 1995.

[11] S. Guha, V. Grover, W.J. Kittenger and J.T.C. Teng. Business Process Change and Organizational Performance: Exploring an Antecedent Model. J. Management Information Systems, 14(1):119-154, 1997.

[12] G. Hall, J. Rosenthal and J. Wade. How to Make Reengineering Really Work. Harvard Business Review, 119-131, November-December 1993.

[13] M. Hammer. Reengineering Work: Don't Automate, Obliterate. Harvard Business Review. 68(4):104-112, July-August 1990.

[14] R. Kalakota and Whinston, A.B. Frontiers of Electronic Commerce . Addison-Wesley, Reading, Mass., 1996.

[15] W.J. Kettinger and V. Grover. Special Section: Toward a Theory of Business Process Change Management, J. Management Information Systems , 12(1):9-30, 1995.

[16] W.J. Kettinger, J.T.C. Teng and S. Guha. Business Process Change: A Study of Methodologies, Techniques and Tools. MIS Quarterly , 21(1):55-80, March 1997.

[17] R. Kling and W. Scacchi. The Web of Computing: Computer Technology as Social Organization. in A. Yovits (ed.), Advances in Computers, 21:3-90, 1982.

[18] R.T. Kouzes, J.D. Meyers, and W.A. Wulf. Collaboratories -- Doing Science on the Internet, Computer, 29(8):40-48, 1996.

[19] P. Mi and W. Scacchi. A Meta-Model for Formulating Knowledge-Based Models of Software Development. Decision Support Systems, 17(3):313-330. 1996.

[20] M.E. Nissen. Reengineering the RFP Process through Knowledge-Based Systems. Acquisition Review Quarterly, 4(1):87-100, Winter 1997.

[21] M.E. Nissen. Redesigning Reengineering through Measurement-Driven Inference. MIS Quarterly, 22(4): 509-534, December, 1998.

[22] J. Noll and W. Scacchi. Integrating Heterogeneous Information Repositories: A Distributed Hypertext Approach, Computer, 24(12):38-45, December 1991.

[23] J. Noll and W. Scacchi. Supporting Software Development Projects in Virtual Enterprises. Journal of Digital Information, 1(4), February 1999. http://jodi.ecs.soton.ac.uk/

[24] NSF Workshop on Research Priorities in Electronic Commerce: Workshop Report Final Draft. The IC² Institute, University of Texas at Austin, January 1999. http://crec.bus.utexas.edu/workshop/ecdraft.html

[25] RAND Corporation. Facts About Federal R&D, Santa Monica, CA, 1998.

[26] F.J. Riggins and H-S. Rhee. Toward a Unified View of Electronic Commerce, Communications ACM, 41(1):88-95, October 1998.

[27] B. Roberts. Companies See Web Reengineering Procurement Practices. Web Week, 1/5/98. http://www.internetworld.com/print/1998/01/05/intranet/19980105-companies.html

[28] W. Scacchi and P. Mi. Process Life Cycle Engineering: A Knowledge-Based Approach and Environment. Intelligent Systems in Accounting, Finance, and Management, 6:83-107, 1997.

[29] W. Scacchi and J. Noll, Process-Driven Intranets: Life Cycle Support for Process Reengineering, IEEE Internet Computing , 1(5):42-49, September 1997.

[30] S.K. Sia and B.S. Neo. Reengineering Effectiveness and the Redesign of Organizational Control: A Case Study of the Inland Revenue Authority of Singapore. J. Management Information Systems, 14(1):69-92, Spring 1997.

[31] J. Tenenbaum, T.S. Chowdhry, and K. Hughes. Eco System: An Internet Commerce Architecture. Computer, 30(5):48-55, May 1997.

[32] R. Wigand. Electronic Commerce: Definition, Theory, and Context. The Information Society, 13(1):1-16, 1997.