Business Process Engineering versus E-Business

Proceedings of the 36th Hawaii International Conference on System Sciences - 2003

Business Process Engineering versus E-Business Engineering A summary of case experiences Wil Janssen1, Maarten W. A. Steen1, and Henry Franken2 1 Telematica Instituut, the Netherlands 2 BizzDesign, Inc., the Netherlands {wil.janssen | maarten.steen}@telin.nl, [email protected] Abstract Business process re-engineering has overcome the hype of the nineties of the last century and has become an engineering discipline. With the advent of e-business a new era of uncertainty in systems’ development has arrived. Do current approaches extend to e-business engineering, or are there too many essential differences to prevent this? In this paper we discuss the similarities and difference between business process engineering and e-business engineering, based on research and cases that we have carried out over the last seven years. From this analysis we digest what support is needed for engineers in e-business and relate this to current approaches in ebusiness.

1. A history of business process redesign and e-business The eighties and nineties of the last century have seen a focus on changing the way businesses operate. Business process redesign and business process re-engineering were used to rationalize processes and products. The industrial revolution automated many production activities in companies. Work shifted from ‘blue collar work’ to ‘white collar work’. Improving the performance of white-collar work cannot be achieved by simply automating this work, but by working smarter, enabled by information technology. In this, the effective use of information technology has played a crucial role. Don’t automate illogical related business activities, which are there because nobody dares to challenge them (Hammer 1990). Introduce new information technology hand in hand with new process ideas. The capabilities of information technology enable smart work [4]. Another reason for changing business processes was customer focus. Companies need to compete and perform excellent to maintain their customers and gain new ones.

The customer demands fast services, cost-efficiency, high (standard) quality, and flexibility. Ultimately, cost, flexibility, improvement and standardization of quality need a process focus. Looking at the business activities serving the end-customer, they appeared to be partitioned on the basis of, amongst others, historical evolution and political power structures, existing departmental boundaries, and physical location and geographical borders. Given complexity and risks involved in changing an organizational way of working, a business process engineering approach is needed. Dealing with design complexity demands abstraction using architectural methods and tools. By the end of the last century, different methods and tools have been developed to assist organizations in optimizing processes and introducing customer focus. Business process redesign has moved from an ill-understood skill, with a substantial failure rate, to a repeatable exercise [8][7]. It has become business process engineering. However, organizations cannot function in isolation. To meet customer demand they depend on close cooperation with suppliers. They rely on customer information and feedback for product quality. There’s nothing new in this. Well-known procedures for business operations between companies have evolved over time. Yet, these were based on traditional circumstances — such as stable markets, stable and simple business relationships, geographically limited markets, and mass production and marketing — and through traditional channels — paper, phone, and fax [1][21]. This situation has drastically changed over the last few years. Customers have become increasingly demanding and product innovation rates are high. Also, globalization of markets and the availability of new electronic media led to new players in existing markets and high pressure to work more effectively, reduce costs, and become more flexible. Due to information and communication technology (ICT) flows of goods between parties in a value chain and associated flow of

0-7695-1874-5/03 $17.00 (C) 2003 IEEE

1


Degree of business transformation

information have been uncoupled. This leaves room for new intermediaries within existing chains and shifting roles. The information flow itself becomes an important area of business [19] (Rayport and Svoklia 1994). The advent of e-business and e-government has definitely changed the way organizations and cross-organizational processes function and, therefore, also the way they should be designed. Or hasn’t it? From a strategic point of view, the advent of ecommerce and e-business has lead to ample discussion ([18][21][20][14][16][9], to name a few). Although not everybody agrees on the extent in which strategy does change, it is generally accepted that e-commerce does introduce new business models and new ways of thinking. According to Venkatraman IT-enabled business transformation can take place at different levels, starting from local optimizations to radical business change (BPR) or even business network redefinition, e-businesslike transformations (Figure 1) [23]. This suggests that the transition from business process engineering (BPE) to e-business engineering (EBE) might be evolutionary as well, not requiring a radically different approach.

Business scope redefinition Business network redesign Business process redesign

The analysis in this paper may help process engineers, firstly, to recognize when they are in fact dealing with an e-business trajectory, and secondly, to identify the specific issues that need to be addressed by e business engineering (EBE) methodologies. The discussion is not new. At ICIS 2000 a debate was organized around the question whether the trend toward e-business calls for changes in the fundamental concepts of information systems [1]. The debate did not lead to a clear conclusion, although the audience generally speaking stated that no new fundamental concepts were needed to describe systems. Possible, new ways of building systems were needed. This paper discusses this issue on the basis of the results a large number of case studies performed within the Telematica Instituut over the last five years. From these, we take four examples that are typical for the range of projects we encountered. The cases are described in the next section. The rest of the paper is organized as follows. After the cases we discuss the similarities between BPE and EBE, and how to profit from these similarities. In section 4, however, we argue that the differences between the two are too important to ignore, touching the essence of what’s new in e-business. Finally, we discuss what type of support is needed for e-business engineering, given the analysis in this paper, and how this support relates to current research within the Telematica Instituut.

2. Case descriptions and research approach Below we give a brief description of all four cases. They cover e-business, e-government as well as business process redesign. The first two cases are primarily business processes engineering oriented.

Internal Integration Localized exploitation Potential benefits

Figure 1. Transformation levels according to Venkatraman [23] E-business has changed our view on organizations, moving from an enterprise perspective to a network perspective, but does this also mean business process engineering should be traded in for something new, say, e-business engineering? Existing engineering methods do not extend beyond systems engineering and business process engineering, suggesting “no” for an answer. Also, the fact that many ICT companies stick to their current practice, such as object oriented development and use-case based development [2][12] suggests the same. In fact, the trigger for this paper was a discussion with a methodologist within a large ICT company challenging the idea that there are essential differences between business process engineering and e-business engineering.

Shared service centers ING, a large financial institution is grouping its core business functions, now being performed within each label individually, into shared service centers. Functions such as handling of insurance policies, mortgage offering, underwriting and administration, general payment functions, etc. are being clustered into cost centers. The business case is evident: economy of scale with potential savings on investments in personnel, information technology, and operational excellence through standardization, cost-effective contracts with (preferred) service providers, etc. For such shared service centers to arise and meet the business case, the actual operational business processes at each individual label have to be harmonized. Moreover these activities have to be ‘cut out’ of a label, leaving a necessary interaction to be managed under strict service levels. Why? Because the

0-7695-1874-5/03 $17.00 (C) 2003 IEEE

2


front-office labels are still serving the individual endcustomer (or his intermediary), and outsource all kinds of handling to the cost centers. Claim handling (PROFIT insurances) An insurance company has problems in handling insurance claims. The throughput of the process is too slow, and customers complain about the lack of information, that, moreover, comes from different people within the insurance company as well as intermediary offices. In order to improve performance, the insurance company makes specific contracts with a number of garages on repair, and alters the process such that customer contact is with intermediaries only. Payments are settled with the garages directly. The next two cases are more towards e-business. The first case is not so much an engineering case as a case involving standardization. E-procurement standardization in EP.NL Electronic procurement promises organizations substantial cost savings. Especially for secondary goods and services the cost of the transaction currently are much higher than the value obtained. Handling these transactions automatically in cooperation between buying and selling organizations may save a lot and speed up processes. However, moving into e-procurement is not simple: the selling side dominates the market and software vendors, not taking the buying side into consideration. The processes (implicitly) supported by this software do not comply with the services requested by the buy-side organizations. Standards, such as OBI, are based on an American procurement model that is not suited to the Dutch situation. Against this background, a number of important buy-side organizations in the Netherlands joined forces and standardized the procurement processes for secondary goods and materials, technical materials and temporary labor in a project called EP.NL. Tapestria European fabric mills face substantial problems in accessing the US market, as access is possible through distributors only, and they determine product offering and price. To overcome this, a managed market place was launched for European mills to offer directly to US interior designers. The market place offers buying and previewing functionality, as well as ordering samples and storing project information. Tapestria delivers samples within 24 hours and offers near-feeling visual information. In order to meet the high delivery standards, a complex integration of logistics, information and financial settlement was developed. Special client software installed at the mills to interface with the

Tapestria market place to allow for real-time inventory information.

2.1 Research approach As the cases were performed over a longer period of time within the context of different project, without a preconceived idea of evaluation, there has not been a systematic approach to the study. The data were compiled from a number of interviews with people involved in the cases plus a number of workshops with the engineers directly involved. The results from this are therefore primarily a vision on the field in retrospect and not a fully scientifically supported framework. The experiences gathered, however, extend beyond the four cases mentioned and were found repeatedly in other cases. The (e-) business engineering approaches used in the cases (viz. [7] and [13]) were derived from and iteratively improved on the basis of case experiences.

3. Similarities From an organization’s perspective, business process engineering remains important, also under the pressure of cross-organizational cooperation, as the introduction of new products and services demands the design of new (core) processes, and the continuous improvement and harmonization of processes demands insight in the functioning of current business processes. When designing organizations as well as when designing organizational networks the following issues have proven to be crucial [21]: • taking the business process as leading; • emphasis on service level to customers; • guaranteeing performance and effectiveness of processes; • using ICT to improve internal and external services. A business process consists of activities between a customer demand for a service or product and the actual delivery. Therefore, they can also cross company boundaries. The business process should be leading as processes deliver products/services to the customer, are measurable and have improvement focus. The emphasis of added value to the customer and the focus on processes is one of the crucial elements. All cases take this, to a certain extent, into account. In table 1 these similarities have been summarized for all four cases. The role of processes, customer service level, ICT, and performance increase is addressed everywhere, albeit from a slightly different angle. Any approach, in business process engineering as well as e-business engineering should be process based and should allow to analyze operational performance. Moreover, the role of ICT should be made explicit and thus, a point of

0-7695-1874-5/03 $17.00 (C) 2003 IEEE

3


Table 1. Service level, process focus, ICT, and performance in the four cases. Shared services

Claim handling

EP.NL

Tapestria

S1. Service level improvement

Mass customization

Dissatisfaction reason for case

Buy-side customer satisfaction

Extensive designer support

S2. Process focus

Harmonization

Process re-distribution over actors

Adding process to existing standards

Cross-organizational process leading

S3. ICT as enabler

For cost reduction and support

Workflow introduction

No e-procurement without ICT

Essential in bridging the gap to the market

S4. Goal with respect to performance and effectiveness

Harmonization should lead to effectiveness

Higher throughput

Motivated by potential cost saving and efficiency gains

Effective market reach, superior logistic performance

discussion, also for management. Many improvement approaches are process based, such as business process reengineering (BPR), continuous process improvement (CPI), and activity based costing (ABC). Tool supported methodologies for BPR and ABC, such as Testbed (Franken et al. 2000), explicitly address these issues.

4. Essential Differences Although business process engineering and e-business engineering projects share many of the same characteristics, there are some inherent differences. In this section we highlight 10 essential differences between BPE and EBE. The differences are actually subtler than we purport them to be here, but therein exactly lies the danger of mistaking one for the other. It may be appealing to apply familiar and established methods for BPE also in e-business trajectories. However, we believe that such an oversight may easily lead to project failure and that EBE requires dedicated methods. The differences are illustrated with the cases introduced above. D1. Enterprise Focus vs. Network Focus The first essential difference between BPE and EBE lies in the focus of the project. BPE projects tend to focus on a single enterprise, the main actor and stakeholder. This actor is usually the problem or process owner, i.e., the organization that wants to have its business processes improved. Other organizations with which the main actor interacts may be taken into consideration also, but only to the extent in which they influence the main actor's own processes. As an example, look at the Claims Handling case. Here Profit Insurances is the main actor. Other organizations, such as the garages and the intermediaries were also considered in the redesign, but only because they were instrumental in optimizing and improving the claims handling process for Profit Insurances.

EBE projects on the other hand, generally have a wider focus and take the network in which the enterprise operates as the starting point. Such a stance is necessary if business network redesign or business scope redefinition is the objective. Business scope redefinition has higher potential benefits at the cost of higher risks. There may still be a main actor or stakeholder, but in order to be able to carefully consider its strategic positioning (see D3 below) in its supply chain, the entire value system should be mapped out as part of the project. The Tapestria case illustrates this very well. Here the main actor did not reason from its own perspective to make the business case. Instead it identified an opportunity for adding value by analyzing the problems of their suppliers, the European fabric mills, and their customers, US-based interior designers, as well as the role of their competitors, the US-based importers and distributors. During the project all product, information and revenue streams in this network were mapped out to determine how and where the Tapestria marketplace could best be positioned.

Figure 2. Enterprise focus and network focus D2. Introvert vs. Extrovert attitude Closely linked to the previous difference is, that BPE projects tend to be more introvert and EBE projects more extrovert. Compare the case of the Shared Services Center with the Standardization case. In the former case all attention went to the private business processes of the main stakeholder. In contrast, the latter project only dealt

0-7695-1874-5/03 $17.00 (C) 2003 IEEE

4


with the public parts of the procurement processes between buyers and suppliers of secondary goods and services.

Figure 3. Introvert and extrovert attitudes Such an introvert stance is typical for BPE projects. In an EBE project the starting point, at least for analysis, but potentially also for redesign, is the network in which the enterprise operates rather than the enterprise itself. Both the Claim Handling case and the Tapestria case started out looking at the external processes, but obviously also had to address the internal processes. D3. Business case BPE and EBE projects also differ in the business case: what triggered management to start the project in the first place? Of course, drivers for change may vary considerably between projects. However, we can identify some tendencies for the different kinds of projects. BPE projects tend to be motivated by process optimization, cost reduction, service level improvement and product innovation. EBE projects on the other hand are motivated more from the point of view of added value, flexibility, and strategic positioning. One should be aware that different drivers also yield differing critical success factors. Analyzing the four cases introduced earlier, we see quite a range of different drivers. The motivation for Shared Service Center is to reach economies of scale, i.e., cost reduction. Profit Insurances redesigned its claim handling process to improve service levels. Standardization of procurement processes was motivated by a need to prevent supplier and vendor lock-in, i.e., to remain flexible in the buyer's choice of suppliers. Tapestria was mainly motivated by a desire to open-up new markets. D4. Who is the Customer? Business processes are commonly defined to run from customer to customer; they are triggered by a customer's request and end with the fulfillment of that request. For the processes under consideration in BPE projects it is generally clear who that customer is. Take the Profit Insurances case, for example. Here the customer is the end-consumer of insurance policies and claims. The business processes under consideration are the ones

dealing with insurance claims, etc., all triggered by some sort of customer request. For the processes under consideration in EBE trajectories it is not always so clear who the customer is. Take the Tapestria case, for example. Here a marketplace is being designed which operates as an intermediary between interior designers and fabric mills, but it also interacts directly with logistics providers. Which ones can be considered the customers? The fabric mills, or the interior designers, or even their customers? Where do the business processes start and finish? Who triggers them? These are questions that can make an EBE project much more complex than a BPE project. D5. Relationships under Consideration EBE projects not only deal with the customer-facing processes, but also look at many of the other relationships an enterprise has. BPE projects tend to deal just with one process or a small cluster of business processes, usually the ones that deal with the enterprise’s (internal) customers. As a result the processes under consideration tend to have a clear start and end, and a limited amount of interaction with the enterprise’s environment if at all. EBE projects, on the other hand, not only deal with the customer-facing processes, but also look at many of the other relationships an enterprise has. Interactions with suppliers and third-party service providers are just as important. Especially in a B2B setting, the change is from for the customer to with the customer (interactive, co-creation). D6. Transparence of Business Functions In BPE, business functions are generally considered private to the enterprise. Their internal workings, the private processes of organizations, are shielded from the environment. The motivation for doing this is that organizations consider their private processes a means to obtain competitive advantage. Networked enterprises, on the other hand, turn their business functions inside out and bring in extranets and virtual private networking technology to give their partners direct access to their own functions, at least to a certain extent depending on the relationship. Their idea is to focus on their own core business and utilize strong partnerships to create the best possible offering for their customers. Looking at our cases, we see remarkably different effects on business functions. One of the driving forces behind the Shared Services Center was to harmonize processes between the different labels before splitting business functions into differentiated front-offices functions for each of the labels and common back-office functions at the Shared Services Center. At no time was it considered to open-up functions to other players in the market. In the Claims Handling case, there was mainly

0-7695-1874-5/03 $17.00 (C) 2003 IEEE

5


attention for Profit’s own business functions although they were partly opened-up to a closed circle of insurance agents, so these could pre-process claims and deal with all customer queries directly. In the Standardization project there was some controversy over the question whether or not business functions should be made visible to supply chain partners or not. In the Tapestria case it was obvious from the start that all partners would have to open up their business functions, e.g., for inventory management, to each other. D7. Importance of Standardization In BPE business processes are considered private and a means for an enterprise to obtain a competitive advantage over its competitors. The objective in BPE trajectories often is to deliver unique services with obvious and specific value to the customers. A standard solution will just not do. In the Claims Handling case, for example, Profit Insurances tried to differentiate itself from its competitors by making their network of insurance agents the only channel for communication with their customers. This move enabled Profit to provide a much more personalized service to their customers, while reducing costs and process exceptions. Obviously, it is important for Profit to keep its network of agents as stable as possible. By designing a proprietary solution for the agents to communicate with the Profit back-office systems, it is virtually impossible for “independent” agents to sell Profit products and more difficult for existing agents to switch to another insurance provider. In EBE standardization of processes and service interfaces becomes highly important. Networked enterprises depend upon fast and flexible coupling of processes and systems. They operate in dynamic markets where one supplier or service provider is readily swapped for another. The advent of e-business has forced enterprises (supply chain partners, but also competitors) to cooperate and agree on public processes and service interfaces. The Standardization case is an obvious example, in which buyers got together with each other and their suppliers with the objective to standardize the public, inter-organizational processes, procedures and messages for e-procurement. D8. EAI vs. B2Bi Another difference between BPE and EBE is the kind of application integration that is usually employed. Application integration is concerned with the issue of connecting two or more applications that were not initially designed to be connected, in order to have them inter-operate and/or share data [6].

The kind of integration that is typical for BPE is Enterprise Application Integration (EAI). EAI is concerned with integrating applications within an enterprise; the applications that implement the “internal” processes typically not visible to the outside world. EAI played a major role in the Shared Services Center case. The kind of integration that is typical for EBE is Business-to-Business Integration (B2Bi). B2Bi is concerned with the applications of different enterprises; the automation of the “inter-organizational” processes. The Tapestria case is all about B2Bi. The other two cases involved intermediate forms of application integration. The Claim Handling case was characterized by a limited, looser form of EAI, called workflow automation. Application integration was not really pursued in the Standardization case itself, but it intended to deliver the requirements for a limited form of B2Bi, which one could call extended ERP (XRP) or simply B2B procurement. D9. Role of ICT Information and Communication Technology (ICT) typically has a supporting role in BPE trajectories. The business processes come first. Only after the processes have been designed, their implementation in applications is considered. Even if the possibilities of ICT have inspired the enterprise to redesign their business processes and the processes are fully or partly automated, they would generally still function, albeit with some difficulty, without the ICT systems to support them. In the Shared Services Center case, for example, ICT does play an important, but supporting role. The whole idea of sharing common back-office processing tasks would have made sense even if communication and processing would not be automated at all. For EBE trajectories, on the other hand, ICT is a major ingredient. Some e-business models and processes would not be possible without ICT. Therefore, the (re)design of business processes and ICT applications go hand in hand. This is illustrated by the Tapestria case in which ICT plays a crucial role. Without it, the business model for Tapestria could not have been realized. D10. Control and responsibility Since most BPE projects deal with the processes of one single enterprise, the question of control is not really an issue. There is a clear process owner who obviously also controls the process. In the Shared Services Center case there was no doubt about who should control the processes. The front-offices are in control and, when necessary, they temporarily pass over control to the backoffice.

0-7695-1874-5/03 $17.00 (C) 2003 IEEE

6


Table 2. The ten differences in four cases. Shared services

Claim handling

Standardization

Tapestria

D1. Enterprise / network focus

Enterprise + network (multiple labels).

Enterprise

Network

Network

D2. Introvert / extrovert

Introvert

Introvert + extrovert

Extrovert

Extrovert + introvert

D3. Drivers

Cost + service level

Service level

Cost + preventing lockin

Opening up new markets

D4. Customer

Consumer + intermediaries

Consumer + intermediaries

Buyer, supplier or internal customer

Interior designers, mills, customers

Customer + service providers

Customer + garage

Supplier + buyer

Buying, tracking, designer support

D6. Business functions

Internal harmonization, but closed

Restricted access to agents

Controversial

Open to partners and customers

D7. Standardization

Internal harmonization

None, proprietary solution

Objective

Not considered

D8. EAI / B2Bi

EAI

Workflow

Extended ERP / eprocurement software

B2B integration

D9. Role of ICT

Cost effective business case

Communication / process automation

Context of standardization

Crucial

D10. Process control

Internal

Internal

‘hot issue’

Explicit distributed design

D5. Relations

1 2

1

2

As Tapestria was primarily a greenfield operation, special attention had to be given to the internal business processes. Standardization is not an issue as the marketplace is for a semi-closed customer group, under strong supervision of Tapestria.com. When opening up this might prove a hindrance. Not standardizing, however, was not a strategic choice, but merely due to immaturity of the market.

As EBE deals more with inter-organizational processes, the question who has control over and is responsible for these processes suddenly becomes a major issue. Control was a very hot issue in the Standardization case, but as no implementation was built during this project, the question of control was left open. In Tapestria, process control was dealt with explicitly. Control is distributed over the supply chain partners and managed explicitly.

5. Conclusions for e-business engineering methods In summary, the results of the different cases have been gathered in table 2. E-business engineering should take the differences specific to e-business into account in order to reduce the risk of project failure, whilst not forgetting the lessons learned from business process engineering. Especially the difference in focus is crucial to the method applied. E-business engineering methodologies and support should take care of the essential elements of networked business design, keeping the similarities with BPE in mind. In order to get a grip on the development of new electronic transactions and transaction services for networked enterprises one therefore needs methods and tools that:

• start the development of transaction services supporting cross-company cooperation from a business network perspective, not from the perspective of single organization. This implies that in principle many different actors involved can have a customer role, and that many buyer-seller relationships co-exist within the network (D1, D4, D10, S1, S4). • not only allow to cross borders of different organizations, but also of different products and processes. It should be oriented on the overall architecture (D1, D5, D6, S2) • emphasize the roles of organizations in the business network with respect to each other, instead of the actual actors themselves (D1, D4, D10). • link cooperation between companies to internal business processes and existing (legacy) systems (D2, D6, S1, S2). • allow to assess the consequences and prerequisites of technology for business processes and cross-company cooperation (D7, D8, D9, S3). • effectively allow knowledge on standards and available components to be gathered and re-used, preferably supporting component-based development and re-use (D7, D8).

0-7695-1874-5/03 $17.00 (C) 2003 IEEE

7


5.1 Outlook For e-business engineering, no full-blown method currently exists. Most of the work concentrates on the strategic issues and choices (e.g., [18]), not on an integral engineering approach. Some attempts from practical experience have been made, e.g., [11] and [14]. Hoque [11] presents an informal approach with similar ingredients as our approach (see below), such as modeling and an asset repository. More from a scientific starting point Österle et al. [16] have initiated a method also aiming at the essential elements in networked business, starting from a method engineering approach. They address the cooperation aspect, processes, and the application architecture, which can be seen as an ICT perspective. Elsewhere we have proposed an integral approach to e-business engineering, called Rapid Service Development [13], which comprises of three building blocks: • Knowledge on the current technological state of affairs in e-business components and standards; • Knowledge on business processes and building blocks for e-business in an e-business process library, similar to ideas by Timmers [22]; • A framework for systematic development of ebusiness transaction systems, consisting of a conceptual framework, and roadmaps, e.g., for top down design, B2B integration, and standardization, as well as a modeling tool that is ebXML compatible [5].

Ambition & Scope Networked Enterprise

Systems

Transaction Scenarios

System Components

Networked Procedures Enterprise

Protocols

Figure 4. The RSD conceptual framework Central to the approach is a conceptual framework, which allows engineers to position design decisions in the methodology. Seven cornerstones of the RSD are structured along two dimensions, as illustrated in Figure 4. Firstly, we distinguish between businessoriented models (on the left) and technology or system oriented models (on the right). Secondly, models can vary in scope or granularity. Along this axis, they range

from high-level, broad scope, coarse grained, little detailed models (at the top) to low-level, narrow scope, small grained, highly detailed models (at the bottom). In addition, there is an implicit third dimension, the development dimension, ranging from analysis, through design, to realization, which is not visualized here. A continuous refinement of the methodology in practical ebusiness engineering cases is needed, in order to line-up with the state of affairs in ICT firms. Too drastic a departure from existing BPR and systems’ engineering practice is not wise. This analysis of the differences with e-business engineering has been an important step to us towards improving current practice. The next step in our research is to come to highly effective tool support for the RSD methodology, linking to system development tools and approaches. Current prototypes of the RSD handbook, library, and tools may be found at http://rsd.lab.telin.nl/ Acknowledgements This research has, to a large extent, been performed within the Telematics Institute project Testbed and Giga Transaction Services. The work in GigaTS is performed under the umbrella of the GigaPort programme (www.gigaport.nl). GigaPort is an initiative of the Ministry of Economic Affairs, Ministry of Transport, Public Works and Water Management and Ministry of Education, Culture and Science. Testbed was a 120 manyear research initiative that focuses on a virtual test environment for business processes. The project is financially supported by the Dutch Ministry of Economic Affairs. We appreciate to acknowledge all Testbed contributors. We would like to thank all case participants for their contributions to these ideas. We would like to thank Erwin Fielt and reviewers for their constructive criticism.

References [1] Alter, S., P. Ein-Dor, M. Lynne Markus, J. Scott, and I. Vessey. Does the trend toward e-business call for changes in the fundamental concepts of information systems? A debate. Communications of AIS. Volume 5, Article 10, April 2001. [2] Booch, G., J. Rumbaugh, Unified method for ObjectOriented Development, Rational Software Corporation, 1995. [3] Dai, Q. and R. Kauffman (eds.), B2B e-commerce revisited: revolution or evolution. Special section in Electronic Markets. Volume 12 (2). 2002. [4] Davenport, T., J.E. Short, The new industrial engineering: information technology and business process redesign, Sloan Management Review, Summer, 1990, pp. 309-330 [5] ebXML, http://www.ebxml.org/specs/index.htm.

0-7695-1874-5/03 $17.00 (C) 2003 IEEE

8


[6] Eijk, P. van der, D. Nickull, J. Dubray, C. Evans, D. Chappell, B. Harvey, M. Noordzij, J. Vegt, et al, T. McGrath, V. Chopra, B. Peat, Professional ebXML Foundations, Wrox Press, november 2001. [7] Franken, H., Bal, R., Berg, H. van den, Janssen, W. & Vos, H. de. Architectural design support for business process and business network engineering. International Journal of Services Technology and Management, 1(1), 114, 2000. [8] Golden, W., M. Hughes. Business process reengineering using intranets: a new beginning? In: proceedings 14th Bled Electronic Commerce Conference, 2001. pp. 646657. [9] Hagel, J. and J. Seely Brown. Your next IT Strategy. Harvard Business Review. October 2001, pp. 105-113. [10] Hammer, M. Reengineering Work: Don't automate, obliterate, Harvard Business Review July-August 1990. pp. 109-144. [11] Hoque, F. e-Enterprise: business models, architecture, and components. Cambridge University Press, 2000. [12] Jacobsen I., M. Christerson, P. J. G. Overgaard, Object oriented software engineering, a use case driven approach, Addison-Wesley, 1992. [13] Janssen, W., M. Steen, Rapid Service Development: an integral approach to e-business engineering, Volume 2016, Lecture Notes in Computer Science. pp 119-128. 2001 [14] Kalakote, R., M. Robinson. e-Business 2.0. AddisonWesley, 2001.

[15] Malone, T.W., & Laubacher, R.J. The dawn of the e-lance economy. Harvard Business Review, 76(5), 145-152, 1998. [16] Österle, H., E. Fleisch, R. Alt (Eds.), Business enterprise relationships on the Internet. Springer Verlag, 2001. [17] Ould, M.A. Business Processes: Modelling and analysis for re-engineering and improvement, John Wiley & Sons, Chichester, 1995. [18] Porter, M., Strategy and the Internet. Harvard Business Review, March 2001, pp. 63-78. [19] Rayport J.F.; Svoklia, J.J.: Exploiting the virtual value chain, Harvard Business Review, November-December, 1995. [20] Tapscott, D., Rethinking strategy in a networked world. Strategy and Business, Issue 24, 2001. [21] Tapscott, D., Lowy, A., Ticoll, D. Digital Capital: Harnessing the Power of Business Webs. Boston, MA: Harvard Business School Publishing, 2000. [22] Timmers, P., Electronic Commerce, Strategies and Models for Business-to-Business Trading, John Wiley and Sons ltd, England, 1999. [23] Venkatraman, N., IT-enabled business transformation: from automation to business scope redefinition, Sloan Management Review, Fall 1995, pp. 32-42.

0-7695-1874-5/03 $17.00 (C) 2003 IEEE

9