“E-REVERSE AUCTIONS IN PURCHASING: THE PROBLEM OF DESIGNING AN APPROPRIATE E-REVERSE AUCTION SOLUTION”
A study submitted in partial fulfilment
of the requirements for the degree of
Master of Science in Information Systems
at
THE UNIVERSITY OF SHEFFIELD
by
ANDREA LOESCH
September 2003
i Abstract
This dissertation aims to investigate e-reverse auctions in corporate purchasing. The research issue comprises the problem of how to design an appropriate e-reverse auction solution that meets the complex constraints of purchasing. In order to answer that question, a case study was carried out at a German software designer called Hybris. Interviews with both the CSO and the Manager for Technical Support and Training were conducted following the stages of Soft System Methodology (SSM). The revision of previous work suggests that e-reverse auctions are a valid tool for buyers to purchase goods from suppliers as they allow for great cost reductions. They may be applied to different purchasing situations, for instance private B2B exchanges or marketplaces. However, each application area requires its own functionality: The purchasing situation determines which people are involved in the e-reverse auction, what goods are purchased, and which processes need to be included. Regarding the technical environment of e-reverse auction software, the Internet provides a good basis for e-reverse auctions as it greatly reduces the transaction costs and allows to share and display remote data. In addition, technologies such as XML, CGI, and API enable the integration of the e- reverse auction tool with already existing information systems. The research findings correspond to the suggestions of the literature review: The e-reverse auction tool as suggested by Hybris does not only support the essential e-reverse auction processes. Depending on the purchasing situation it may also include additional processes required by the particular setting. Yet, the technical environment for the e-reverse auction solution is limited because the tool will be developed as a part of the Hybris Jakarta – a software platform provided by Hybris. Due to the special situation of consulting a software designer, the results and findings in this dissertation can only be discussed with regard to the evidence obtained from the literature review. At the same time, the critical discussion reveals the major drawback of the e-reverse auction tool: its dependency on the Hybris Jakarta platform. The summary and conclusions of this study indicate that a lot of research needs to be done in future to further investigate the problem of how to design an appropriate e-reverse auction solution. (362 words)
i Acknowledgements
I wish to take this opportunity to thank the following people who have been crucial to the creation of this of work:
Firstly, my supervisor Miguel Nunes for his great support throughout the whole year, not only regarding this dissertation but also regarding my PhD. Thanks for your help, your advice and the interesting discussions.
Secondly, special thanks to my dear granny who has always been encouraging me with my studies and who has now the probably highest phone bill ever. Je te remercie beaucoup, Bernadette!
Thirdly, I want to thank my parents and my ‘little’ brother for their continuous support and the hundreds of miles they have been driving to collect me at the airport.
Fourthly, big thanks and a big hug to my great boyfriend Ed who has been there for me throughout all ups and downs and never let me down. Thanks for keeping me going!
Last but not least, thanks to all my friends in England and back at home. That goes especially to Mo and AJ who waited with their wedding till I would have finished my dissertation!
ii List of Figures
Figure 1: Dependencies within the Software Industry Producing B2B Purchasing Solutions 6
Figure 2: Purchasing Process Model and some Related Concepts (van Wheele, 2000:15) 18
Figure 3: Market Framework (Teich et al., 1999:47) 31
Figure 4: Bundled Bid Example (Davenport et al., 2001:13) 36
Figure 5: Simple Bids, Bundled Bids and Supply Curves (i.e. Volume Discount Bids) (Davenport et al., 2001:10) 37
Figure 6: Process Flow for E-Reverse Auctions (Davenport et al., 2001:9) 39
Figure 7: The Typical Architecture for Web-based Software Solutions (Korper and Ellis, 2000:92) 45
Figure 8: The Basic Internet Architecture (Kalakota and Whinston, 1997:96) 48
Figure 9: CGI and the Internet (Kalakota and Whinston, 1997:96) 52
Figure 10: The Rich Picture of E-Reverse Auctions 57
Figure 11: The First Conceptual Model of E-Reverse Auctions 66
Figure 12: The Second Conceptual Model of E-Reverse Auctions 68
Figure 13: The Final Conceptual Model of E-Reverse Auctions 69
iii
Figure 14: The Functional Requirements 71
Figure 15: The Non-Functional Requirements 75
Figure 16: The Business System Options (BSOs) 76
Figure 17: The J2EE Architecture (Sun Microsystems, 2003b) 77
Figure 18: The Hybris Jakarta Platform Layers (Latka, 2003) 79
Figure 19: The E-Reverse Auction Extension Folder in the Hybris Jakarta 83
Figure 20: TSO 1 as proposed by Hybris (Hybris, 2001) 86
Figure 21: TSO 2 as proposed by Hybris (Hybris, 2001) 86
Figure 22: TSO 3 as proposed by Hybris (Hybris, 2001) 86
Figure 23: TSO 4 as proposed by Hybris (Hybris, 2001) 87
Figure 24: TSO 5 as proposed by Hybris (Hybris, 2001) 87
Figure 25: TSO 6 as proposed by Hybris (Hybris, 2001) 87
Figure 26: TSO 7 as proposed by Hybris (Hybris, 2001) 88
Figure 27: TSO 8 as proposed by Hybris (Hybris, 2001) 88
iv Table of Content
1 INTRODUCTION 1
1.1 BACKGROUND 1
1.2 DEFINITIONS 2
1.3 THE RESEARCH ISSUE 4
1.4 RESEARCH QUESTIONS AND OBJECTIVES 4
1.5 METHODOLOGY 5
1.5.1 THE RESEARCH ENVIRONMENT 5
1.5.2 APPROACH TO RESEARCH 6
1.5.3 METHODS OF INVESTIGATION 10
1.5.4 LIMITATIONS 12
1.6 DISSERTATION STRUCTURE 15
2 LITERATURE REVIEW 16
2.1 PURCHASING 16
2.1.1 DEFINITIONS: PURCHASING AND E-PROCUREMENT 17
2.1.2 THE DIFFERENT DIMENSIONS OF PURCHASING 20
2.1.3 ICT IN PURCHASING 24
2.1.4 ORGANISATION OF ELECTRONIC PURCHASES 26
2.2 E-REVERSE AUCTIONS 28
2.2.1 AUCTIONS 29
2.2.2 REVERSE AUCTIONS 30
2.2.3 ICT IN AUCTIONING 33
2.2.4 CURRENT ISSUES IN E-REVERSE AUCTIONING 34
2.2.5 PROCESS OF E-REVERSE AUCTIONS 38
2.3 TECHNOLOGY FOR E-REVERSE AUCTION SOFTWARE 43
2.3.1 BASIC REQUIREMENTS FOR E-REVERSE AUCTION SOFTWARE 43
2.3.2 ARCHITECTURE FOR E-REVERSE AUCTION SOFTWARE 45
2.3.3 THE INTERNET AS TOOL FOR INTEGRATION 47
2.4 SUMMARY 53
v 3 RESULTS AND FINDINGS 55
3.1 DOMAIN DESCRIPTION 55
3.2 THE PROBLEM SITUATION EXPRESSED: RICH PICTURE 56
3.3 ROOT DEFINITION AND CATWOE ANALYSIS 61
3.3.1 THE CLIENTS: FOR WHOM? 61
3.3.2 THE ACTORS: WHO? 62
3.3.3 THE TRANSFORMATION: WHAT? 62
3.3.4 THE WELTANSCHAUUNG: ASSUMPTIONS 63
3.3.5 THE OWNER 63
3.3.6 THE ENVIRONMENT 64
3.3.7 THE RESULTING ROOT DEFINITION 65
3.4 THE CONCEPTUAL MODEL 65
3.4.1 IDENTIFYING AND EXTRACTING THE VERBS WHICH FORM THE MAIN
TRANSFORMATION 66
3.4.2 ORGANIZING THE VERBS INTO ACTIVITIES AND DEFINING THE MAIN LOGICAL
DEPENDENCIES 66
3.4.3 CONSIDERING EACH ACTIVITY IN TURN AND ASKING “WHAT ACTIVITIES
MUST GO ON DIRECTLY PRIOR TO THIS ACTIVITY?” 67
3.4.4 ADDING CONTROL ACTIVITIES BY CONSIDERING THE IDEA OF THE SYSTEM 68
3.5 THE REQUIREMENTS 69
3.5.1 FUNCTIONAL REQUIREMENTS 70
3.5.2 NON-FUNCTIONAL REQUIREMENTS 72
3.6 RESULTING BUSINESS SYSTEM OPTIONS (BSOS) 75
3.7 IMPLEMENTATION 76
3.7.1 THE SOFTWARE PLATFORM 77
3.7.2 FRONT- AND BACK-END INTEGRATION 82
3.8 THE RESULTING TECHNICAL SYSTEM OPTIONS (TSOS) 85
4 DISCUSSION 89
4.1 THE DEVELOPMENT OF BSOS AND TSOS 89
4.2 BUSINESS SYSTEM OPTIONS (BSOS) 91
4.2.1 THE BASIC VERSION 91
vi 4.2.2 APPROVAL OF E-REVERSE AUCTIONS 92
4.2.3 FACILITIES TO AUCTION HETEROGENEOUS GOODS 93
4.2.4 ALGORITHMS FOR OTHER REVERSE AUCTION TYPES 95
4.3 TECHNICAL SYSTEM OPTIONS (TSOS) 95
4.4 SUMMARY 99
5 CONCLUSIONS AND FUTURE WORK 101
5.1 SUMMARY AND CONCLUSIONS 101
5.2 FUTURE WORK 102
REFERENCES 105
GLOSSARY 112
APPENDIX 120
vii 1 Introduction
The dissertation at hand is concerned with e-reverse auctions in purchasing and the problem of how to design an appropriate e-reverse auction solution. In order to facilitate the understanding of this subject, this chapter will give a brief summary of the background of this particular business area (1.1 Background). It will then develop the relevant definitions (1.2 Definitions) and present both the research issue (1.3 The Research Issue) and the research questions and objectives (1.4 Research Questions and Objectives). The chapter will also introduce and discuss the methodology used to investigate the research issue (1.5 Methodology). Finally, the dissertation structure will be presented (1.6 Dissertation Structure).
1.1 Background
Information and Communication Technology (ICT) are frequently addressed as the enabler of great improvements: Advances in information technology allow for more information to be communicated in the same unit of time, thus reducing transaction costs; furthermore, a tighter electronic linkage between buyer and seller is enabled (Axelsson and Wynstra, 2002). However, the use of ICT to support business activities is not completely new. In the early 1970s, Electronic Funds Transfer (EFT) proved to be the only way of efficiently handling massive volumes of transactions generated daily by the banking industry (Barnes and Hunt, 2001:1). One decade later, the use of electronic networks expanded with the emergence of Electronic Data Interchange (EDI) – the electronic movement of standard business documents such as purchase orders, bills and confirmations between large enterprises (Barnes and Hunt, 2001:2). In the 1990s, the emergence of the Internet has once more improved the possibilities of conducting business electronically. With the commercialization of the Internet, many companies have started applying ICT to sell their goods electronically. Electronic commerce was born and applications such as Yahoo and various online shops made it particularly famous.
E-reverse auctioning is only one of the latest applications using Internet technology for doing business. It has become publicly known due to the emergence of e-auction market sites such as Ebay. Ebay epitomises bargain buys for everybody
1 – and so do e-reverse auctions for companies: Using e-reverse auctioning, companies make average savings of between 5% and 30%, or in some cases even more (Barling, 2001). The great interest in this new application is supported by findings of a recent AMR Research study that the realities of user interest in the current market are highest for bidding events and bid analysis, negotiation, and contract management with 20% for each of those processes (Kemmeter, Mitchell and Sufeski, 2002).
1.2 Definitions
However, the recent emergence of various possibilities of doing business electronically has also created problems of defining and classifying those new business forms, so that currently, there is a lot of confusion what e-reverse auctioning is and how it fits into the e-business or e-commerce environment. In order to reduce the prevailing confusion about the new economy and e-reverse auctions, this section will first classify the e-commerce and e-business environment which e-reverse auctions are part of, and then clarify the context of e-reverse auctions within this dissertation.
Usually, there are two terms that are frequently referred to where conducting business electronically is concerned: e-business and e-commerce. The term ‘e- business’ was mainly shaped by IBM in 1998 and refers to conducting business on the Internet. This means not only buying and selling, but also servicing customers and collaborating with business partners (iWay, 2003). Thus, many authors assume that e-business refers to a broader scope of electronically enabled activities than e- commerce (CompTIA, 2003; Wippermann, 2001; Merz, 1999:17, Kalakota and Robinson, 1999; Chaffey, 2002; Butler and Power, 1999). Following this view, e- commerce is only one particular facet of e-business focussing on the commercial interactions between the different parties involved and can be defined as trading electronically (Turban et al.; 2000). Depending on the actors involved, it is generally accepted in the literature (Rayport and Jaworski, 2001:4; Korper and Ellis, 2000:6; Merz, 1999; Barnes and Hunt, 2001) to differentiate the following distinct categories of electronic commerce:
2 • Consumer-to-Consumer commerce (C2C), i.e. e-commerce between and among customers. • Business-to-Consumer commerce (B2C) or Consumer-to-Business commerce (C2B), i.e. e-commerce between business(es) and customers. • Business-to-Business commerce (B2B), i.e. e-commerce between businesses.
Korper and Ellis (2000:6) point out that this differentiation is very important since e-commerce is approached differently depending on whether a company is communicating with a business or with an individual on the Internet (Korper and Ellis, 2000:6). Electronic auctions can generally be applied to any of the categories described above. However, e-reverse auctions are a particular form of electronic auctioning and are mainly used within B2B commerce, i.e. for commercial activities between companies. They are primarily applied to corporate purchasing and enable a company to buy goods and services needed from a number of known or unknown suppliers (De Boer et al., 2002). Hence, this dissertation will only focus on the use of e-reverse auctions within B2B purchasing situations.
When conducting an e-reverse auction, the buying company usually invites potential suppliers to submit their bids for a particular good or service. The company then buys the good from the supplier who made the ‘best’ (i.e. normally cheapest) bid. Thus, e-reverse auctions usually focus on the price of the goods and services auctioned (Teich et al., 1999). But besides driving down suppliers’ prices, discovering market price trends and gaining access to a wider supply base have proved to be main reasons for the use of reverse auctions in purchasing (Barling, 2001). Furthermore, users have identified the following benefits of e-reverse auctions (Barling, 2001):
• A reduction in RFQ errors, thereby minimising administration and creating a fairer playing field for suppliers. • A decrease in time spent creating distributing, and managing RFQs and running the negotiation.
3 • A reallocation of staff from manual processing work to more valuable (to the business) and more interesting (for the people involved) sourcing and procurement work.
1.3 The Research Issue
Like any other key management task, purchasing within companies has aspects that are concerned with operational activities (day-to-day), tactical matters (medium term-perhaps one year) and with strategic issues (long-term) (Bailey & Farmer, 1990:43). The main objective of purchasing is to buy goods and services of the right quality, in the right quantity, at the right time, from the right supplier, and at the right price (Bailey and Farmer, 1990:69; Diamond and Pintel, 1989). Building and maintaining effective and responsive relationships between suppliers and customers is crucial to the successful process of purchasing and therefore to the survival of free-market enterprises (Saunders, 1994:216). Solely focussing on price cuts when selecting suppliers can be dangerous: Though significant savings may be made in short term, the drawbacks of this procedure may become apparent with the passage of time; bringing new suppliers on stream quickly, in response to lower bids, can produce quality problems and production delays (Saunders, 1994:216). Even so, the findings in a recent AMR Research study imply that there is a gap between the complex requirements of purchasing and the corresponding solutions offered by vendors all over the world (Kemmeter, Mitchell and Suleski, 2002). Suppliers refuse to take part in e-reverse auctions, and consequently, buyers are not able to really benefit from this application.
In short, the facts and findings presented above indicate that current e-reverse auctions may neglect the complex business constraints required by purchasing (Davenport et al., 2001). The challenge is now to carefully reconsider the requirements of e-reverse auctioning, make the appropriate improvements and thus, to resolve the existing problems.
1.4 Research Questions and Objectives
Therefore, this dissertation will address the key question of how to design an e- reverse auction solution that recognizes the complex constraints and information
4 needs within the corporate purchase process. As there is little known about e- reverse auction tools but the fact that they do not meet their requirements, this dissertation will pursue the following objectives:
• To investigate the complex constraints of purchasing (Objective 1). • To examine the constraints of e-reverse auctioning (Objective 2). • To identify the requirements for an e-reverse auction solution that satisfies both the constraints of purchasing and e-reverse auctioning (Objective 3). • To investigate the technical environment for e-reverse auction software (Objective 4). • To develop and discuss the Technical Systems Options (TSOs) and the Business Systems Options (BSOs) of the new system (Objective 5).
Investigating the business environment of purchasing and e-reverse auctioning is crucial to get a good understanding of the particular requirements and constraints. Current e-reverse auction solutions seem to have failed doing this. Both the examination of the particular requirements of an e-reverse auction solution and the investigation of the technical environment provide the basis for suggesting appropriate BSOs and TSOs. The resulting BSOs and TSOs will finally give detailed advice how to develop appropriate e-reverse auction software.
1.5 Methodology
This section will focus on different methodological aspects that are relevant for this dissertation. That includes a description of the research environment (1.5.1 The Research Environment), the presentation of the chosen approach to research (1.5.2 Approach to Research), the presentation of the methods of investigation used in this study (1.5.3 Methods of Investigation) and a critical assessment of the limitations of this study (1.5.4 Limitations).
1.5.1 The Research Environment
The problem of how to design an e-reverse auction solution that meets the complex requirements of the purchase process is part of the software industry that is
5 concerned with B2B purchasing solutions. Therefore, answers to the research question can be found in that environment.
A brief examination of that environment reveals that there are generally three players involved:
• The software designer, i.e. the company developing and selling the particular piece of software. • The buyer, i.e. the company buying and using the particular piece of software. • The supplier, i.e. the companies that the using company deals with by using the software.
When the software designer produces software, the software must meet certain requirements defined by the buyer who is going to use it. However, the buyer itself makes use of the software to deal with its suppliers. Therefore, the software must also satisfy certain criteria determined by the particular suppliers. The relationships within the software industry that have just been described are again illustrated in Figure 1 below.
Software Buyer Supplier Designer
Figure 1: Dependencies within the Software Industry producing B2B purchasing solutions
1.5.2 Approach to Research
Because the problem described in the research question has not been clearly defined as yet, and its real scope is as yet unclear, it is best resolved by exploratory discovery (Joppe, 2003). The approach chosen to conduct this research is a case study approach combined with the application of SSM (Soft Systems Methodology).
As for choosing a case study approach, Fidel (1992) suggests that case studies are appropriate for investigating phenomena when:
6 • A large variety of factors and relationships are included. • No basic laws exist to determine which factors and relationships are important. • The factors and relationships can be directly observed.
In the case of e-reverse auctions, there are many factors involved that derive from the constraints of the purchase process to be examined, from the different actors involved, their information requirements and the processes to be included. But currently, it is not clear which of those factors are relevant. However, it is possible to directly investigate these factors by addressing people concerned with-reverse auctions, i.e. buyers, suppliers or software designers (please see Figure 1, 1.5.1 The Research Environment). Indeed, asking a software designer appears to be the most suitable choice: As the software designer is going to develop a solution that needs to meet both the buyer’s and supplier’s requirements, it can be assumed that he has all relevant knowledge of the business environment and the requirements. He will also have the relevant technological knowledge.
Similar to Fidel’s (1992) suggestion, Yin (1994) claims that the case study approach be suitable under the following circumstances:
• The form of the research question is how or why. • The study does not require control over behavioural events. • The study focuses on contemporary events.
Each of these requirements is met by the research to be conducted: the research question concerns the design of a suitable e-reverse auction solution. In addition, the investigation of this question does not require any control over behavioural events. Finally, it focuses on a contemporary event as e-reverse auctions have just emerged as a tool within B2B commerce applications for purchasing.
The major benefit of applying a case study approach to this research is that it attempts to arrive at a comprehensive understanding of the event under study (Fidel, 1992). This is particularly important as there is little known about the particular requirements of e-reverse auctions. So it is advisable under these circumstances to conduct a case study in order to initially get a deep insight into this topic.
7 The case investigated in this dissertation will be a German software designer called Hybris. The company produces e-commerce software for Internet-based shopping and procurement (Hybris, 2003a). Currently, Hybris plans to extend the functionality of their core product, the hybris jakarta platform, by adding a reverse auction feature. Thus, the company represents a typical case for the problem addressed in the research question which is one major rationale for a single case study design (Yin, 2003:40).
However, Yin (1994) admits that a potential drawback of case studies is that they provide little basis for scientific generalization. Yet, it can be argued that like experiments, case studies are generalizable to theoretical propositions and not to populations (Yin, 1994). In this sense, the goal of conducting a case study is to achieve analytical generalization, i.e. to expand and generalize theories, and not to achieve statistical generalization, i.e. enumerate frequencies (Yin, 1994). The research question posed in this study is to find out about problems in designing e- reverse auctions that have not been recognized so far. Conducting a case study to approach the research question will contribute to the generalization and extension of the current academic and business knowledge of e-reverse auctions and maybe even resolve some of the current problems. Even though this research will not be applicable to all populations, it will deliver findings that may enhance the generalization of what is known so far. Thus, the case study approach appears to be the most appropriate one in order to address the problem presented in the research question.
The application of SSM (Soft Systems Methodology) appears favourable because SSM concentrates on the understanding of problem situations (Avison and Fitzgerald, 2003). It was found to be particularly relevant to problems of creating appropriate information systems (Checkland, 1995:4). The immense and well- documented amount of failures of information systems that did not meet the users’ real needs is one of the most compelling reasons for applying this methodology (Mingers, 1995). SSM does not only include a learning process about the particular problem situation, but also technical aspects such as creating corresponding conceptual models of the system (Davies and Ledington, 1991). Given its characteristics, SSM appears to be very suitable to answer the research question as
8 it can help to clarify the problem situation and to redefine the requirements of the new software solution.
The seven-stage process of SSM supports this goal accurately as it encourages the user(s) to undertake an analysis of the problem situation, name it and then define desirable and feasible changes to improve the situation (Davies and Ledington, 1991:12; Checkland and Scholes, 1990). In detail, the SSM process includes the following steps:
• The problem situation: unstructured. • The problem situation: expressed (Rich Picture). • Root definitions of relevant systems (CATWOE). • Conceptual models. • Comparison of the conceptual models with the problem situation expressed. • Desirable and feasible changes. • Action to improve the problem situation.
In contrast to all other steps, the creation of the root definition and of the conceptual model do not relate to the real world but to the world of systems thinking (Checkland and Scholes, 1990; Checkland, 1995). This distinction is important as it allows for understanding and expressing the real world problem in its real world context. The understanding of the problem situation can then be transferred into conceptual thinking and the corresponding models. These models can again be compared to the real world situation that will give important hints for changes and actions required to improve the problem situation. Following this process, it is ensured that the solution recognizes the real-life’s richness of information systems and does not solely focus on technological constraints. Consequently, changes done to the system are very likely to be ‘systematically desirable’ and ‘cultural feasible’ (Checkland and Scholes, 1990).
Checkland and Scholes (1990:28) point out that the cycle of learning about the respective system described above is ideally never-ending. This, of course, is not feasible in any information systems analysis. Due to the tight time constraints of this research project, the dissertation will only be able to cover the first four stages of SSM, i.e. the problem situation unstructured, the problem situation expressed (in
9 a rich picture), a root definition of the relevant system based on CATWOE analysis, and the creation of the corresponding conceptual model(s). The Technical and Business Systems Options will then be developed on the base of this model. The negotiation and validation of the model with the interviewees, its comparison with the real world, and the suggestion of changes and actions to be taken will not be part of this dissertation.
In addition to this shortcoming of the SSM analysis carried out here, Mingers (1995:25) argues that SSM generally misses a connexion to standard design methodologies or case tools to facilitate the detailed design work after the requirements have been identified. Indeed, the scope of SSM is very limited as it mainly focuses on the early stages of information systems development rather than on the design and development process itself (Avison and Fitzgerald, 2003). To overcome this shortcoming, SSM is usually combined with more structured design approaches such as SSADM in order to cover the whole process of information systems development. This dissertation, however, will do without the application of other design approaches in addition to SSM. The reason is that due to the time constraints this dissertation only aims to investigate and analyse the requirements of e-reverse auctions tools. It is not concerned with the logical design, physical design or implementation of the new system. Thus, the use of other design methods in addition to SSM is not necessary.
1.5.3 Methods of Investigation
The research conducted will mainly be qualitative as the strength of qualitative research is ‘its rich description’ (Glazier, 1992). The stated richness in description is not only required but also essential to properly approach the research question. Mason (1996) and Yin (2003) differentiate several methods of generating qualitative data such as interviewing, observation, visual data and documentation. The methods of investigation applied in this study will be the ones of literature review and analysis of secondary data sources as well as interviews with relevant employees of the German software designer Hybris.
The analysis of documentary resources is a well-known research method. Most of the documents are text-based even though they may also contain interesting non-
10 text based elements such as graphics, diagrams etc. (Mason, 1996:71). Yin (2003:86) points out that reviewing the relevant literature and secondary data resources is advantageous for research because documents are exact1, stable2, unobstrusive3, and they have a broad coverage4. Reviewing these data sources will also give an idea of the main problems related to the research question, for instance the omission of certain topics in the literature, concepts related to the problem situation or generally information about the problem situation etc.
Important reasons for using interviews to collect evidence include the following (Mason, 1996):
• People’s knowledge, views, understandings, and experiences are meaningful properties of the social reality that the research question is designed to explore. • The problem addressed in the research question requires an understanding of depth and complexity in people’s accounts and experiences rather than a more superficial analysis of surface comparability between accounts of large numbers of people. • The data relevant to the research question is not feasibly available in any other form.
As pointed out above, the software designer Hybris has the relevant knowledge to answer the research question. Furthermore, the best way to appropriately address the research question is an in-depth analysis of the problem situation. This dissertation aims to understand the complex constraints of purchasing and e-reverse auctioning and how they can be respected rather than investigating what actually happens when using e-reverse auctions. Finally, besides analysing relevant literature and documents, interviewing remains the only way to collect the relevant information. Observing the people involved would be useless because this method would not give information about people’s concerns, experience and knowledge which is, however, crucial for answering the research question.
1 They contain exact names, references, and details of an event. 2 They can be reviewed repeatedly. 3 They have not been created as a result of the case study. 4 They include a long span of time, many events, and many settings.
11 However, Gorman and Clayton (1997) argue that personal interviews may be very costly, too personal, uncritical, and especially open to bias. In order to overcome the high costs, the interviews will be conducted during a technical training in Munich. In order to overcome possible bias, the interviews will be structured and targeted at the information required for the SSM analysis. Flick (2002) suggests to ask unstructured questions first, and introduce increased structuring only later during the interview. This is to prevent bias and the interviewer’s frame of reference being imposed on the interviewee’s viewpoint (Flick, 2002:75). On the other hand, it enables the interviewer to control the interview situation and focus on the topic. Flick (2002) further suggests using additional materials such as pictures, documents etc. to support the interviewee in recalling specific situations. Here, the application of SSM is very helpful as it includes the use of rich pictures and conceptual models in order to illustrate and clarify the problem situation. The interviews therefore focus on the major stages of the SSM process (i.e. General Problem Situation, Rich Picture, CATWOE Analysis etc.). For further details on the interview scripts, please see Appendix 1.
1.5.4 Limitations
After having described the chosen path of research, this section will investigate the quality of this study and its limitations. According to Yin (2003:33), the quality of case study research usually depends on its construct validity, its internal validity, its external validity, and its reliability. Another issue related to a study’s quality is sampling, i.e. the decision about which persons to interview (Flick, 2002:61). Hence, the chosen path of research will be examined and discussed in terms of those concepts.
Construct validity means establishing correct operational measures for the concepts being studied and may be especially problematic in case study research (Yin, 2003). Studies that involve complex constructs such as happiness, effectiveness or similar are particularly vulnerable to criticism of lacking construct validity (Knight, 2002:137). However, this dissertation is concerned with the problems of e-reverse auction tools. As e-reverse auction tools are very concrete and precise, construct validity is not particularly endangered. Considering the given
12 nature of the research construct, it is very likely that this study does not only accurately identify the underlying constructs of e-reverse auction tools but also represents and measures them appropriately.
Internal validity determines the extent to which the research really investigates what it claims to have investigated (Knight, 2002). Again, due to the precise nature of the topic under study, there are no particular concerns about its internal validity.
External validity on the other hand deals with the problem of whether a study’s findings are generalizable beyond the immediate case study or not (Yin, 2003; Mason, 1996:24). External validity is supposed to be a major disadvantage of case study designs. Critics typically state that single cases offer a poor basis for generalizing (Yin, 2003:37). However, it has already been discussed above (1.5.2 Approach to Research) that even though the single case study design will not allow for statistical generalization, it will at least contribute to analytical generalization, i.e. deliver findings that may enhance the generalization of theories.
Sampling is very closely related to the external validity of the research. According to Knight (2002:120), the sample must be truly representative of the population in terms of the inquiry made. As mentioned above (1.5.2 Approach to Research), the case investigated in this dissertation is a German software designer called Hybris. This company is going to design a reverse auction tool. In other words, Hybris is currently facing the same problem as the one that is posed in the research question above. Therefore, Hybris is claimed to be a suitable data source for the investigation of the research questions as it represents a typical case.
As for the selection of the interviewees, the strategy was to interview both the senior product manager and the training and technical support manager (int02). The senior product manager was chosen because he would have the relevant knowledge concerning the requirements of the e-reverse auction solution, the general business environment of this product and the corresponding business constraints. The training and technical support manager on the other hand would be able to answer all questions concerned with the technical options of the e-reverse auction tool. Consequently, interviewing those people would give appropriate answers to pursue the above named research objectives. However, despite his contractual agreement,
13 the senior product manager could not be available for any interviews due to circumstances beyond control. He was replaced with Hybris’ CSO (Chief Security Officer) (int01) who is also concerned with product management and development, and thus, able to give appropriate answers.
The reliability of research involves the accuracy of the research methods and techniques and to what extent they reliably and accurately produce data (Mason, 1996:24). Due to the lack of standardized research tools, reliability is one major issue in qualitative research. However, the use of SSM in this dissertation aims to overcome the problem of reliability to some extent. As mentioned above (1.5.2 Approach to Research), SSM is an acknowledged methodology in the development of information systems. It is also especially suited to this dissertation due to both the focus of this methodology and the ill-structured nature of the problem situation (1.5.2 Approach to Research). Hence, it can be concluded that SSM is a valid way to ensure the reliable and accurate production of data.
Recapitulating, the major limitations of this research comprise the following:
• It includes only a limited set of methods of investigation, i.e. interviews and analysis of documents and literature. • It is only based on a single case. • The SSM analysis is not completed, i.e. there is no validation of the model obtained.
However, these limitations are due to the tight time constraints of this research, thus not changeable by the author. But it can be argued that, within its limited scope, this research may still be as valid and reliable as possible because it tries to
• Select the most appropriate approach to research, i.e. case study approach combined with the application of SSM. • Apply the most possible variety of methods of investigation, i.e. interviews as well as review of literature and documents. • Select a typical case and appropriate interviewees.
14 1.6 Dissertation Structure
In the following chapters, the dissertation will present the literature review (2 Literature Review), the results and findings of the case study and SSM analysis (3 Results and Findings), a discussion of the results and findings (4 Discussion) as well as corresponding conclusions and recommendations (5 Conclusions and Future Work).
The literature review (2 Literature Review) will cover the topics of purchasing, e- reverse auctions and technology for e-reverse auction software in order to give a first insight into the research environment, current issues and possible solutions. As mentioned above (1.4 Research Questions and Objectives), this is important for the identification of the requirements and the development of appropriate BSOs and TSOs for the e-reverse auction tool.
The third chapter (3 Results and Findings) will comprise all relevant outcomes of the case study conducted including a domain description, a description of the problem situation expressed in a rich picture, the CATWOE analysis with the resulting root definition, the conceptual model of the e-reverse auction tool, the resulting Business System Options, Implementation and possible Technical System Options.
The fourth chapter (4 Discussion) will then reconsider the relevant findings and comment on them. The results of the case study will be discussed taking into account the evidence obtained in the literature review. This will at the same time enable a refinement of the BSOs and TSOs suggested in the results.
The last chapter (5 Conclusions and Future Work) will finally summarize the main outcomes of this study and indicate possible areas of future research.
15 2 Literature Review
As mentioned above (1.1 Background), the advance in information technology has brought changes to the way companies do their business. Electronic commerce has become the most famous phenomenon of the ‘technologisation’ of business processes – and e-reverse auctions are one particular application within this new way of doing business. Being part of the new diverse economy, e-reverse auctions may vary in many dimensions. Just like there are various ways of conducting business electronically, there are various ways of applying e-reverse auctions within different business contexts. This chapter will therefore examine the environment of electronic business in order to better understand the context of e-reverse auctions later on.
The first section (2.1 Purchasing) will investigate corporate purchasing. As e- reverse auction software is mainly applied to B2B purchasing the investigation of this environment is necessary to specify the various dimensions in which e-reverse auctions may be applied. At the same time, a first outline of the relevant business constraints of e-reverse auctions may be obtained. The second section (2.2 E- Reverse Auctions) will then focus on e-auctioning and e-reverse auctioning in order to identify the relevant constraints, principles and processes of e-reverse auctions. The third section (2.3 Technology for E-Reverse Auction Software) will finally clarify the technical context of e-commerce solutions as to understand the technical constraints of an e-reverse auction tool.
2.1 Purchasing
As mentioned in the Introduction (1.1 Background), e-reverse auctions are primarily used for purchasing in B2B commerce scenarios, thus subject to the complex constraints of corporate purchasing. For a long time the importance of purchasing has been underestimated by companies. Purchasing has been considered a clerical and administrative function mainly expediting orders and not requiring specific skills (Leenders and Fearon, 1997). However, this attitude has changed when companies realized that the costs of purchased goods and services represented the dominant portion of their total costs (Gadde and Hakansson, 2001). Making the
16 purchase process more efficient by using ICT would consequently allow for immense savings. It is assumed that a 10% reduction in purchase costs may result in an up to 100% increase in profit margin (Digital Union, 2003:20) As e-reverse auctions are supposed to be a tool for achieving cost reductions in purchasing, this section will investigate purchasing in companies in order to identify and understand the context, processes, and constraints that are relevant for the development of e- reverse auction solutions in purchasing.
However, as characteristic for the whole field of e-commerce, there is also a lack of unique terminology within purchasing or its electronic equipollent due to the recent nature of it. Hence, this chapter will first define the act of doing purchases electronically as well as relevant concepts within purchasing (2.1.1 Definitions: Purchasing and E-Procurement). Then, it will introduce the different dimensions of purchasing to illustrate the complexity of this business activity as well as relevant constraints (2.1.2 The Different Dimensions of Purchasing). The implications of using ICT in purchasing will be presented in the following section (2.1.3 ICT in Purchasing). After all, section 2.1.4 will focus on the different ways to organize purchasing when using ICT (2.1.4 Organisation of Electronic Purchases).
2.1.1 Definitions: Purchasing and E-Procurement
As mentioned above, there is a lot of confusion about the terminology for describing the act of companies’ buying goods and services both traditionally and electronically. In general terms, purchasing encompasses the act of buying. Thus, van Weele (2000) defines purchasing in companies as follows:
“Obtaining from external sources all goods, services, capabilities and knowledge which are necessary for running, maintaining and managing the company’s primary and support activities at the most favourable conditions.” (van Weele, 2000:14)
17 As purchasing in companies must ensure the ‘five rights’ (Bailey and Farmer, 1990:69)5. It usually covers the following activities (van Weele, 2000:14):
• Determining the specification. • Selecting the most suitable supplier. • Preparing and conducting negotiations with the supplier in order to establish an agreement. • Placing the order with the selected supplier. • Monitoring and control of the order (i.e. expediting). • Follow up and evaluation.
In comparison, procurement is a somewhat broader term (Digital Union, 2003; van Weele, 16; Kalakota and Robinson, 1999). It includes all activities required in order to get the product from the supplier to its final destination, which means that it does not only encompass purchasing, but also stores, traffic and transportation, incoming inspection, and quality control and assurance (van Weele, 2000:16). The differences between procurement and purchasing are again illustrated in Figure 2 below:
Figure 2: Purchasing Process Model and some Related Concepts (van Weele, 2000:15)
Correspondingly, most authors in academic literature differentiate electronic purchasing and e-procurement (De Boer et al., 2002; Axelsson and Wynstra,
5 This means to buy goods and services of the right quality, in the right quantity, at the right time, from the right supplier, and at the right price (Bailey and Farmer, 1990).
18 2002; Rouvas, 2002). Whereas e-purchasing refers to the actual buying of materials and those activities associated with the buying process, e-procurement has a broader meaning and includes purchasing, transportation, warehousing, and inbound receiving (Kalakota and Robinson, 1999). Possible processes in e-procurement may include supplier integration, catalogue information, catalogue search functions, order management, approval workflows etc. (Hybris, 2003d). Among others, De Boer et al. (2002) consider the following processes as being part of e-procurement:
• E-sourcing. • E-tendering. • E-MRO. • Web-based ERP. • E-Reverse Auctioning.
E-sourcing refers to the process of identifying new suppliers for a specific category of purchasing requirements using Internet technology (Axelsson and Wynstra, 2002:125; DeBoer et al., 2002). It usually includes a set of processes for identifying, evaluating, qualifying, selecting and managing suppliers in a supply chain (Digital Union, 2003:8).
E-tendering concerns the process of sending RFIs (Request for Information) and RFPs (Request for Proposals) to suppliers and receiving their responses using Internet technology (Axelsson and Wynstra, 2002:125; DeBoer et al., 2002). RFIs are used in the early phases of sourcing to explore the market for new, potential suppliers and to gather enough information for deciding to invite them to participate in the next step (Digital Union, 2003:12). RFPs are then used to invite suppliers to propose innovative ways of solving problems and of reducing supply or manufacturing costs, e.g. propose a new component that performs the functions of several items (Digital Union, 2003:12).
The actual purchase usually happens ‘after’ e-sourcing and e-tendering as it is based on the outcomes of those processes. Depending on the products to be purchased and how the products are purchased, Axelsson and Wynstra (2002) differentiate between e-MRO, web-based ERP and e-reverse auctioning that all refer to the actual process of creating and approving purchasing requisitions, placing purchase
19 orders, and receiving goods and services by using a software system based on Internet technology (Axelsson and Wynstra, 2002).
In the case of e-MRO, the goods and services ordered are maintenance, repair, and operating (MRO) suppliers, office supplies etc. (i.e. non-product related), and the supporting software system can be used by all employees of an organisation (De Boer et al., 2002). The focus is mainly operational, however, it may also have some strategic or tactical implications (De Boer et al., 2002).
In the case of web-based ERP (enterprise resource planning), the goods and services ordered are product-related (Axelsson and Wynstra, 2002). Usually, only the employees of the purchasing department are using the supporting software system and the impact is mainly operational (De Boer et al. 2002).
In e-reverse auctioning, however, the price of the goods to be purchased is not fixed yet. The purchaser invites a number of potential suppliers to take part in the e- reverse auction. Usually, e-reverse auctions focus on the price of the goods and services auctioned (Teich et al., 1999), and the supplier making the best (normally cheapest) bid is determined as winner. Regarding the activities involved in traditional purchasing described above, e-reverse auctions would primarily concern the steps of determining the specification and selecting the most suitable supplier. They do not include contracting, monitoring and control of the order, or follow up and evaluation, even though these activities surely need to be done after having conducted an e-reverse auction.
As this dissertation only focuses on e-reverse auctions, other problems involved in purchasing such as issues deriving from e-tendering or e-sourcing are not taken into account here.
2.1.2 The Different Dimensions of Purchasing
As illustrated above (2.1.1 Definitions: Purchasing and E-Procurement), e-reverse auctions can be used in several purchasing situations as a tool to drive down supplier prices and select the most appropriate supplier(s) (Digital Union, 2003). The previous section has already given some insight into the different dimensions
20 of purchasing for instance in terms of different people being involved or different goods to be bought. This section will present a more detailed view of the various differences of purchasing as to clarify the various dimensions in which e-reverse auctions may be applied within the purchase process. Again it is important to understand the different dimensions of purchasing because the type of buying influences the type of software solution required (Kalakota and Robinson, 2000:339). When companies buy goods, the purchase can generally differ in several dimensions (Barrat and Rosdahl, 2002):
• How the products are purchased. • What products are purchased. • Who actually purchases.
How the products are purchased is mainly determined by the strategic focus of the particular purchase. Like any other key management task, purchasing has aspects that are concerned with operational activities (day-to-day), tactical matters (medium term-perhaps one year) and with strategic issues (long-term) (Bailey and Farmer, 1990:43). Consequently, many authors distinguish different types of purchases within organisations depending on the strategic importance of the purchase. The most common differentiation is between strategic purchases and spot purchases (Barratt and Rosdahl, 2002; Kalakota and Robinson, 2000; Kaplan and Sawhney, 2000; Rouvas, 2002):
Strategic or systematic purchases usually involve negotiated contracts with pre- qualified suppliers, and these purchases are often long term and are based on previous relationships (Kaplan and Sawhney, 2000). This type of purchasing includes supplier selection and contract negotiations as well as supplier management (Kalakota and Robinson, 2000:339). To be successful, the particular purchasing strategy needs to be integrated with the corporate strategies and with those of other key functions (Bailey and Farmer, 1990:43).
Spot purchases on the other hand are based on an immediate need for a specific product or service, which is often a commodity (Kaplan and Sawhney, 2000). Kalakota and Robinson (2000:339) assume that this kind of purchases mainly occurs in the following situations:
21 • When existing contracted suppliers cannot fill the order. • When there is a rush order. • When the order is one-time only and the order size is too small to justify the contract negotiation process.
Apart from the above distinction, purchases made by a company can further be categorized in terms of the goods purchased. There is consent in literature to differentiate between production related goods (i.e. direct purchases) and non- production related goods (i.e. indirect purchases) (Barratt and Rosdahl, 2002; Kaplan and Sawhney, 2000, Emiliani, 2000; Rouvas, 2002).
Production related goods include all items needed to produce a finished item (Kalakota and Robinson, 2000). Considering the importance of production related goods, the organization needs to make sure that they are of acceptable quality, and that they are delivered on time to the organizations premises, so as not to halt the production process (Rouvas, 2002). The ordering of production related goods is mainly driven by design specification (Kalakota and Robinson, 2000) and organizations usually form a cross-functional team to analyze and decide on this type of purchase (Emiliani, 2000). Consequently, production related goods are primarily ordered from a professional of the purchase department (Kalakota and Robinson, 2000). Direct purchases are closely connected to strategic purchases and are usually dominated by long-term contracts since the company cannot frequently change suppliers of such important goods and services (Rouvas, 2002).
Non-production related goods are not considered as core products, and may include maintenance, repair and operating goods (MRO), office supplies, travel etc. (Barratt and Rosdahl, 2002; Kalakota and Robinson, 2000). Those goods are usually purchased ad hoc, not scheduled and from any employee’s desktop (Kalakota and Robinson, 2000). Furthermore, the ordering of indirect goods is normally catalogue-driven and not automated, thus requiring appropriate levels of approval (Kalakota and Robinson, 2000:314).
However, a different way to classify the goods purchased is based on monetary value (Leenders and Fearon, 1997). This classification differentiates goods in terms
22 of the percentage of total items purchased and the percentage of total purchase costs (Leenders and Fearon, 1997):
• A-items represent only up to 10% of the total items purchased in a company. However, their value may comprise 70-80% of the total purchase expenses. An example could be a very sophisticated, expensive machine used in the production process. • B-items also represent only a small percentage of the total items purchased (i.e. 10-20%), but their value only comprises 10-15% of the total purchase expenses. Typical examples are medium expensive investments in the computing facilities or infrastructure. • C-items represent with 70-80% the major amount of total items purchased. However, their value may only comprise 10-20% of the total purchase costs. Typical examples of C items include office supplies such as pencils, paper or MRO goods.
The major benefit of this classification is that it allows the identification of areas of highest payoff (Leenders and Fearon, 1997).
As indicated above, there may be two different groups of people involved in corporate purchasing (De Boer et al., 2002):
• Members of the particular purchasing department or purchasing unit. • Any other members of the organisation.
As the purchasing department functions as an organisation’s official purchase representative, its members are usually in charge of planning the purchases, ordering etc. The purchasing department usually consists of a number of different managers specializing in particular purchase processes, e.g. ‘Manager for Follow- up and Expediting’ or ‘Manager of the Buying Section’ (Leenders and Fearon, 1997:45). The buying section represents the heart of the department as it is concerned with the actual purchases of the companies. It usually consists of various purchasing agents and buyers who may specialize on certain types of goods such as MRO, raw materials etc. (Leenders and Fearon, 1997:45). Depending on the size of the company, purchasing can be organized in a centralized or decentralized way or
23 sometimes even in both ways (Gadde and Hakansson, 2001:12). In any case, the members of the decentralized or centralized purchasing unit will be the people authorized of doing the actual purchases for a company.
Yet, in some situations other people than members of the purchasing department are involved in corporate purchases. For instance, in the case of non-production related goods such as office supplies or MRO, purchases may be initiated by any particular employee within the organisation and not by the purchase department or unit. That is because the immediate need for such goods is not within the purchase department but throughout the whole organisation. In the case of production related goods, it is very important to involve employees from the particular production unit in the purchase as they normally have the knowledge required to create an appropriate product specification (Emiliani, 2000). Due to the lack of relevant knowledge, it may sometimes be very difficult to purchase appropriate complex production-related goods if only members of the purchase department would be involved.
Recapitulating what has been discussed in this section, it can be concluded that purchasing may involve a number of different people depending on the strategic focus and the usage of the good purchased.
2.1.3 ICT in Purchasing
With the traditional paper based purchase process, it is usually quite inefficient to have employees throughout the whole company their purchases done themselves, to timely produce all relevant papers, to gather all relevant information, and to appropriately control this process (Alaniz, 1999). This section will therefore investigate how and why purchasing could benefit from the application of ICT.
Given the various activities involved in purchasing described above (2.1.1 Definitions: Purchasing and E-Procurement) 6 it can be concluded that the traditional way of purchasing without ICT may have several drawbacks: A huge amount of information and documents needs to be produced and shared between
6 This comprises determining the specification, selecting the most suitable supplier, preparing and conducting negotiations with the supplier, placing the order, monitoring and control of the order, follow up and evaluation (van Weele, 2000:14).
24 various parties such as suppliers, buyers and within the buying organization. Without using ICT, the transferral and sharing of this immense amount of data may be very difficult and time-consuming.
Consequently, Alaniz (1999) characterizes the traditional purchase process as follows:
• There is a high amount of maverick spendings (i.e. unauthorised purchases) due to a lack of control over the process. • Only low volume discounts may be given because of a lack of transparency and the resulting difficulty to appropriately bundle all purchases. • It is a very paper-intensive process because many documents need to be produced and shared between many different parties relying on paper as primary medium. • The order cycle time is very long due to the problems with generating, sharing and exchanging all relevant data. • There is a high amount of errors due to a lack of control over the process and the problem of sharing remote information.
Regarding these problems with the traditional way of purchasing, Gadde and Hakansson (2001:8) point out that buying electronically may have two strategic roles for a company: development and rationalization. Whereas the development role refers to the significance of suppliers as resource for the technical development of a company, the rationalization role of purchasing comprises all the day-to-day activities performed to decrease costs successively (Gadde and Hakansson, 2001). This may involve the discovery of what needs to be purchased, the rationalization of logistics and the rationalization of administrative operations (Gadde and Hakansson (2001).
Especially when it comes to frequent purchases of items like MRO and office supplies, the cost of handling a single purchase order from preliminary inquiry to invoice becomes immense (Gadde and Hakansson (2001:8). Therefore, it is particularly important to find effective routines for dealing with those transactions in order to increase the efficiency of purchasing (Gadde and Hakansson, 2001). ICT helps to achieve this goal by automating these administrative operations and
25 integrating them in the same format. Applying ICT to purchasing thus may increase the efficiency and effectiveness for both buyers and suppliers.
Buyers may generally profit from cost reductions, reduced cycle times and added value at several levels in the supply chain (Kalakota and Robinson, 2000; Digital Union, 2003). Cost reductions do not only relate to the decreased cost of the items purchased, but also the decrease in transaction and administrative costs as well as the elimination of unauthorised purchases (maverick purchases) (Kalakota and Robinson, 2000; Digital Union, 2003). Reduced cycle times mainly derive from lower supplier identification and qualification times, reduced price and contract negotiation time, lower transaction processing time, and less manual errors in inputting orders (Digital Union, 2003; Davenport et al., 2001; Korper and Ellis, 2000). Added value may be delivered to the buyer in terms of improved management information, improved workflows, well-organized reporting information, increased control and transparency over the supply chain etc. (Kalakota and Robinson, 2000; Digital Union, 2003).
Suppliers on the other hand may not only benefit from reduced cycle times and added value but also from the transparency of competitive pricing, the opportunity to expand their market and grow their business, and opportunities to better organise their production on the basis of long-term agreements (Digital Union, 2003).
2.1.4 Organisation of Electronic Purchases
Using ICT in purchasing has created different ways of organizing the exchanges between companies. Companies may either have private electronic enabled exchanges with only a few suppliers. But they may as well chose joining a public marketplace and purchase their goods there. Whether public or not, electronic B2B exchanges may focus on providing goods for one particular industry only (so-called vertical exchanges), or they may provide a wide range of products (so-called horizontal exchanges). Again, e-reverse auctions can be used in any of these purchasing scenarios. Hence, this section aims to describe those different organisations of purchasing in order to clarify and illustrate the different settings for applying e-reverse auctions.
26 De Boer et al. (2002) point out that Internet technology can be applied to the purchase process in three ways:
• Electronic public marketplaces. • Intranets. • Extranets.
The use of intranets and extranets for purchasing represents a way to conduct private exchanges between companies. Intranets are collections of websites with information and applications supporting electronic purchasing. They are only accessible by employees within the particular organisation (De Boer et al., 2002). Extranets are similar to intranets, however, they can only be accessed by employees of a specified set of organisations such as business partners, customers etc. (De Boer et al., 2002).
In contrast to private B2B exchanges, electronic public marketplaces are specific websites on the Internet that aim to bring buyers and sellers together in order to facilitate electronic purchases and more general e-commerce (De Boer et al., 2002; Teich et al., 1999). This form of B2B exchange is generally open to every company. In the case of marketplaces, buyers manage their own back-end systems containing product information and transaction data while a third party offers a common interface for buyers to access different suppliers (Korper and Ellis, 2000:8). Anderson and Frohlich (2001) point out that public marketplaces may provide the following advantages:
• Independence and neutrality. • Market efficiency as it matches right buyers and right sellers. • High volume. • Global reach.
In addition, buyers may benefit from the depth of information the public B2B exchange provides (Anderson and Frohlich, 2001). On the supply side, sellers can gain access to a global scale, as well as benefit from cost savings generated by free registration and participation and standardization (Anderson and Frohlich, 2001).
27 Apart from distinguishing private exchanges and public marketplaces, B2B exchanges can further be categorized either as vertical or horizontal exchanges. The main characteristic of a vertical marketplace is that it only operates within one specific industry (Barrat and Rosdahl, 2002:114). Again, these market sites can either be private or public. As they are often very specialized in terms of products, a deep knowledge about the products and how the industry operates is vital to the success of these sites (Barrat and Rosdahl, 2002:114). Horizontal market sites on the other hand are categorised as operating within cross-industry buyers (Barratt and Rosdahl, 2002:115). These sites are normally used to sell non-production related products to a wide range of buyers (Barrat and Rosdahl, 2002).
2.2 E-Reverse Auctions
As described in the previous chapter, different practices within the electronic version of purchasing can be distinguished (2.1.2 Definitions: Purchasing and E- Procurement). Whereas e-MRO and web-based ERP refer to the ordering and purchasing of goods at predefined prices, e-reverse auctions are used as a tool to negotiate appropriate prices for the particular good auctioned. Bichler et al. (2002) even diagnose a general shift from fixed to dynamic pricing due to the use of Internet technologies in purchasing. However, it is important to understand that even though e-reverse auctions allow for dramatic reductions in purchase costs, they are not suited to all purchasing situations (Digital Union, 2003:3).
This chapter will therefore first investigate auctions in general to understand the basic concept of auctions (2.2.1 Auctions). The second section (2.2.2 Reverse Auctions) will then examine e-reverse auctions in relation to auctions, their differences and underlying concepts. Section three (2.2.3 ICT in Auctioning) will briefly illustrate to what extent auctions and reverse auctions can benefit from the application of Internet Technology. The fourth section (2.2.4 Current Issues in E- Reverse Auctioning) will focus on the current problems of e-reverse auction software that need to be resolved. The fifth section (2.2.5 Process of E-Reverse Auctions) will then examine and present the process for e-reverse auctions.
28 2.2.1 Auctions
Generally speaking, auctions enable a supplier to sell goods and services to a number of known and unknown buying organisations (De Boer et al., 2002; Axelsson and Wynstra, 2002). During a relatively short time frame, the buying organizations involved submit bids for the goods and services that are auctioned (De Boer et al., 2002; Axelsson and Wynstra, 2002). Auctions can operate with either an upward (i.e. English auction) or a downward price mechanism (i.e. Dutch auction) (De Boer et al., 2002; Anderson and Frohlich, 2001:60). They generally can vary in a number of formats. The most common differences between auctions, however, exist in terms of the rank order (open cry vs. sealed bid) and in terms of the price mechanism (upward vs. downward) (Anderson and Frohlich, 2001:60). As the format of the auction determines its process, some of the most common auction types will be described below.
As for the first category ‘rank order’, open cry and sealed bid auctions can be distinguished. Open Cry Auctions start at zero or the specified minimum bid and bidders continue to offer more money for an item until the end of a specified bidding period (Korper and Ellis, 2000:214). The customer with the highest bid wins, and purchases the item (Korper and Ellis, 2000:214). Korper and Ellis (2000) point out that this type of auction works well when prospective buyers can afford the time to place counter bids throughout the specified period and feel comfortable making counter offers within a few minutes or hours (Korper and Ellis, 2000:214). In Sealed Bid Auctions on the other hand, a bidder is not aware of the other bidders’ information (Korper and Ellis, 2000:215). Sealed bid auctions are practiced when it is not possible for the bidders to prepare counter bids efficiently (Korper and Ellis, 2000:215).
In terms of the price mechanism, Dutch Auctions represent the most popular auction example for a downward price mechanism. Dutch Auctions work by initially placing a good or service at the highest bid (Korper and Ellis, 2000:215). The auctioneer then decreases the bid amount until the first customer bids for the good and is determined as winner (Korper and Ellis, 2000:215). This type of auction works particularly well when buyers feel comfortable about making a bid in
29 a few seconds and when the seller has a few expensive items with a higher demand (Korper and Ellis, 2000:216). In contrast to Dutch Auctions, classical English auctions work with an upward price mechanism. Here, the so-called bid amount represents the maximum amount the customer is willing to pay for an item, and not necessarily the current bid so that the bid will never be greater than the customer’s original bid amount, but maybe less (Korper and Ellis, 2000:216). During the auction, the auctioneer directs participants to beat the current, standing bid. New bids must increase the current bid by a predefined increment (Shor, 2003). The auction ends when no participant is willing to outbid the current standing bid (Shor, 2003). Then, the participant who placed the current bid is the winner and pays the amount bid (Shor, 2003). English auctions are also termed second-price auctions since the winning bidder need only outbid the next highest bidder by the minimum increment (Shor, 2003). Thus the winner, effectively, pays an amount equal to (and slightly higher than) the second highest bid. From the buyer’s perspective, second price auctions allow customers to place a maximum value on an item, bid that amount, and then pay little attention to the auction as the actual bidding process more or less happens automatically by increasing the customer’s bid by the minimum increment (Korper and Ellis, 2000:216).
2.2.2 Reverse Auctions
A reverse auction is basically the opposite of a common auction. Reverse auctions enable a purchaser to buy goods and services needed from a number of known or unknown suppliers (De Boer et al., 2002). Usually, buyers post their need for a particular product or service to a number of suppliers. The suppliers then bid to fulfil that need (Sun Microsystems, 2002; Federal Reserve Bank of Chicago, 2003). Unlike an auction, prices usually move down (Sun Microsystems, 2002; Federal Reserve Bank of Chicago, 2003).
In order to illustrate the differences regarding the situation in which auctions and reverse auctions occur, Teich et al. (1999) introduce a market framework that describes different scenarios of exchange in a market, i.e. buying and selling situations with non-fixed prices. They distinguish
• Negotiation, i.e. one buyer and one seller.
30 • Marketplace, i.e. many buyers and many sellers. • Auction, i.e. many buyers and one seller. • Reverse auction, i.e. many sellers and one buyer.
Figure 3: Market Framework (Teich et al., 1999:47)
Following this framework, auctions are primarily an instrument for suppliers to sell goods and services to a number of buyers at a good price. On the other hand, reverse auctions are mainly a tool for buyers to purchase goods and services at a good (i.e. low) price (Sun Microsystems, 2002). However, Teich et al. (1999) admit that the differentiation of auctions/reverse auctions and marketplaces is often not clear. Indeed, there is an overlapping area meaning that marketplaces may both offer auction and reverse auction facilities – as well as any other services. As mentioned above (2.1.4 Organisation of Electronic Purchases), the marketplaces may vary in their focus depending on whether they are organized as horizontal market sites or vertical market sites. As this dissertation is concerned with e-reverse auctions in B2B purchasing, only e-reverse auction applications will be investigated in further detail – regardless whether they are organized as marketplaces or as private B2B exchanges (for further details please see 2.1.4 Organisation of Electronic Purchases).
Like there is a number of different ‘normal’ auction formats, there are also different types of reverse auctions. The process of the different reverse auction types relates
31 to the one of the ‘common’ auction with only two differences: it is not the buyers who bid but the suppliers and thus, the tendency is that the lowest bid wins and not the highest. However, corresponding to the auction formats described above (2.2.1 Auctions), the following reverse auction types can be distinguished (Federal Reserve Bank of Chicago, 2003):
• Reverse Sealed Bid Auctions, i.e auctions with one buyer and many suppliers in which each seller makes a single (secret) bid and the lowest bid wins once all bids are received. • Reverse Open Cry Auctions, where there is one buyer and many suppliers who can see their competitors’ bids. The suppliers bid until finally the lowest bid wins. • Reverse Dutch Auctions that have one buyer and many suppliers. The auctioneer raises the price from a low starting point until finally a bidder agrees to sell at that price. • Reverse English Auctions, i.e. auctions with one buyer and many suppliers in which bidders offer decreasing prices to sell an item.
Digital Union (2003:4) point out that reverse auctions generally work well for the following situations:
• If the auctioned items form a substantial value and/or the buyer is a prominent market leader. • If purchased products or services are precisely specified. • If there are enough potential suppliers. • If the cost of switching suppliers is not prohibitive.
These suggestions provide early indications of the special characteristics of e- reverse auctions: First, in e-reverse auctions the buyer is usually in a very powerful position. Second, the goods auctioned need to be comparable (preferably homogeneous) so that all attributes are equal and the price is the only distinguishing feature. Third, there must be a lot of potential suppliers taking part in the e-reverse auction in order to uphold competition and drive down the prices. Fourth, e-reverse auctions may conflict with strategic purchasing constraints when the buyer heavily relies on a particular supplier, for instance to provide him with special production
32 related goods. In this case, it might be dangerous to force the supplier to take part in e-reverse auctions, thus risk losing the probably only source to get the special good from.
2.2.3 ICT in Auctioning
Both auctions and reverse auctions have always been common in the business world for negotiating trades of large monetary value. Small-scale purchases have typically relied on the fixed price model partially due to the high overhead associated with the auction method (Korper and Ellis, 2000:212). However, using the Internet for auctioning and reverse auctioning, the traditionally high transaction and menu costs have considerably been reduced (Bichler et al., 2003:287). Consequently, auctions and reverse auctions now can also be used efficiently for small-scale purchases. The application of Internet technology to auctions and reverse auctions is then referred to as e-auctions and e-reverse auctions.
In addition to the general benefits of using IT in purchasing that have been described in the previous chapter (2.1.3 ICT in Purchasing)7, Korper and Ellis (2000:213) point out that the application of Internet technology to auctioning and reverse auctioning may have the following additional benefits (Korper and Ellis, 2000:213):
• First, relying on (reverse) auctioning to sell goods may reduce the supplier’s distribution cost as the inventory may be stored in a single location. This reduces the time spent packaging, reduces shipping costs, and eliminates wear and tear (more specifically, loss or breakage) associated with the shipping process. • Second, the supplier may also benefit from the reduced surplus inventory as electronic (reverse) auctions represent an attractive alternative to the way businesses currently mark down the price of merchandise, clear inventory of seasonal items, or sell damaged goods. Often, auction profits far outweigh the long-term expense of waiting for a better way to eliminate inventory.
7 This is reduced costs, reduced cycle times, and added value.
33 • Third, buyers may benefit from ‘fairer’ prices. During typical sales, items are marked down by 20%, 30%, eventually 80%. E-(reverse) auctions replace these current practices of matching price to demand behaviour (and the resulting markdowns) to ensure sales volume as customers determine the cost of an item and the quantity they buy.
Regarding these benefits and the general benefits of applying ICT to purchasing, conducting e-auctions and e-reverse auctions proves very appealing as their benefits are now available for nearly every company due to Internet technology. Even small companies may take part in e-reverse auctions by joining a marketplace.
2.2.4 Current Issues in E-Reverse Auctioning
As described above (2.2.3 ICT in Auctioning), applying ICT to reverse auctions creates various benefits for both buyers and suppliers. However, the new possibilities of e-reverse auctions have also created new issues. These mainly derive from the fact that processes that have formerly been direct face-to-face interaction now must be ‘transferred’ to the virtual world. Thus, the major problem is to represent the real-world complexity of reverse auctions appropriately in the software solution. This section will illustrate the current issues within e-reverse auctioning and point out ways to cope with the problems identified.
As mentioned before, the main challenge is the complex nature of e-reverse auctions. The simplest case of an e-reverse auction would be a price negotiation for a single good. However, this would only be appropriate when the particular good is standardized in terms of its attributes and cannot be differentiated across suppliers except for the price (Kalagnanam, 2002). This is the case for homogeneous goods. Yet, the complex nature of purchasing described above (2.1 Purchasing) usually requires multiple criteria to be taken into account. Besides the price of a good, its quality, previous relations with the particular supplier, delivery times and many more factors may be crucial factors when making a purchase decision. Particularly in the case of heterogeneous goods, all these attributes may vary greatly. Furthermore, in some cases a bid in an e-reverse auction may not only include one item, but several items (i.e. multi-line bids).
34 Thus, it is essential that e-reverse auctions accurately match the needs of the buyer with the capabilities of the supplier by incorporating optimal bid selection subject to constraints based on the business rules of the particular purchasing situation (Davenport et al., 2001). As a consequence of these premises, the major issues of today’s e-reverse auctions are (Kalagnanam, 2002; Davenport et al., 2001; Bichler and Kalagnanam, 2002):
• Achieving comparability of multi-attribute bids. • Modelling bundled bids. • Modelling volume discount bids.
2.2.4.1 Achieving Comparability of Multi-Attribute Bids
As mentioned above, in the case of homogenous goods it may be sufficient to auction them in a simple e-reverse auction. Homogeneous goods have attributes that can be determined unambiguously. When buyers invite a number of suppliers to make bids, the attributes of the homogeneous goods are predefined unambiguously, so that bids do not differ in any other category but the price. However, in the case of heterogeneous goods and services, the comparability between different bids may be difficult to achieve. A variety of criteria may be taken into account related to the product specification (e.g. material quality and properties, colour, size), to the service specification (e.g. delivery time and cost, warranty) or to the supplier qualification (e.g. trading history, experience, reputation) (Kalagnanam, 2002). So- called multi-attribute bids usually include multiple items. They specify various relevant attributes for each item, including the unit price (Kalagnanam, 2002). Yet, it may be very difficult to ‘measure’, weigh and compare these attributes. For instance, a particular piece of clothing may vary in terms of material, cut, colour, pattern, the way it has been sewed etc. Not all of these attributes will be specified in advance. Variations within each attribute may be tolerable. Thus, the buyer would need to decide how important certain attributes and the satisfaction of these attributes are. According to Bichler and Kalagnanam (2002), two main techniques can be used to assign reasonable weights to certain attributes:
35 • The first approach is called ‘pricing out’ because buyers specify monetary values for attribute values in order to be able to compare different offerings. • The second approach uses decision analysis techniques to assign weights and individual value functions to the relevant attributes, and calculate a value score. Bidders can then compete on this value score by improving one or more of the attributes.
2.2.4.2 Modelling Bundled Bids
Bundled bids include multiple items, specify the quantity of each item and provide a total bid price for all items (Kalagnanam, 2002). There is only a single price for a bundled offer (Davenport et al., 2001). A bundled bid example is illustrated in Figure 4.
Figure 4: Bundled Bid Example (Davenport et al., 2001:13)
As the buyer needs to have all his needs fulfilled8, finding the cost minimizing bid set is particularly difficult as each bid can only be accepted as whole bundle. The buyer can either take the whole bundle or nothing. Therefore, bundled bids are also known as “all-or-nothing” bids (Davenport et al., 2001; Kalagnanam, 2002). This
8 This means in Figure 4 that the buyer needs to have at least 1000 large Mars brand display boxes AND 800 small Mars brand display boxes AND 800 small M&M’s brand display boxes.
36 problem is a combinatorial optimization problem and can best be solved by modelling it as an integer program (Kalagnanam, 2002). Particular business constraints (e.g. number of winning suppliers should be greater than a certain number or the maximum amount purchased from each supplier is bound to a certain limit etc.) can be captured as side constraints within the mathematical formulation (Davenport et al., 2001). Appendix 2 provides the detailed mathematical formulation for that problem.
2.2.4.3 Modelling Volume Discount Bids
According to Kalagnanam (2002) volume discount bids include multiple items, and specify the price curve of each item. This means that they allow the supplier to specify the price they charge for an item as a function of quantity that is being purchased (Davenport et al., 2001). For instance, a supplier may charge 100£ per ton for up to 30 tons of sugar, but for more than 30 tons would only charge 50£ per ton (Davenport et al., 2001). Consequently, those bids take the form of supply curves, specifying the price that is to be charged per unit of item when the quantity of items being purchased lies within a particular quantity interval (Davenport et al., 2001). The differences between simple bids, bundled bids and supply curves (i.e. volume discount bids) are illustrated in Figure 5 below.
Figure 5: Simple Bids, Bundled Bids and Supply Curves (i.e. Volume Discount Bids) (Davenport et al., 2001:10)
37 The choice of the winning bids and the amount to be purchased from each supplier is again a difficult optimization problem that is modelled as an integer program (Kalagnanam, 2002). As with bundled bids, various business rules can be captured as side constraints within the mathematical formulation (Kalagnanam, 2002). Appendix 3 provides a detailed mathematical formulation for this problem.
2.2.5 Process of E-Reverse Auctions
As can be seen from the various auction types described above (2.2.2 Reverse Auctions), e-reverse auctions usually require several rounds. This section therefore aims to identify the steps typically involved in an e-reverse auction and to determine the typical process flow for an e- reverse auction.
When regarding the process of the different types of reverse auctions introduced above (2.2.2 Reverse Auctions), the following similarities can be noticed (Davenport et al., 2001; Kalagnanam, 2002):
• All reverse auctions are started by a buyer. • Bids are submitted by several suppliers. • The bids are evaluated by means of the criteria determined by the particular bid and auction type. • Suppliers are given a feedback. • Suppliers may then reformulate their bids. • The round closes and the next round is entered with suppliers submitting their bids. • The auction ends when there are no new bids (due to whatever reason).
Davenport et al. (2001) include these steps in an iterative process flow for e-reverse auctions as illustrated in Figure 6 below:
38
Figure 6: Process Flow for E-Reverse Auctions (Davenport et al., 2001:9)
Besides enabling multiple rounds, the iterative design of an e-reverse auction may provide many other advantages (Davenport et al., 2001):
• It induces competition among the participating suppliers, thus enabling better offers. • It allows a supplier to correct and adjust a bid using information learned during the auction process. • It elicits bids incrementally thereby avoiding the need for the supplier to specify its entire preference set.
At the same time, it helps solving the problems described above such as the modelling of bundled bids or volume discount bids (2.2.4 Current Issues in E- Reverse Auctioning). Davenport et al. (2001) point out that in the case of bundled bids with N items, a supplier can specify 2N bids. This means if the number of items is 20, the supplier might have to provide over a million bids (Davenport et al., 2001). The iterative process helps to solve this problem by eliciting from suppliers only those bids that are profit maximizing at the current price levels (Davenport et al., 2001). Thus, the number of possible combinations to be reported by the suppliers is reduced step by step. Consequently, the iterative process reduces the mathematical complexity of the problem proposed. In the following, some major
39 steps included in the iterative e-reverse auction process will be investigated in further detail.
As for starting the auction, it can be assumed that the buyer would first need to determine on the specification of the good he wants to purchase. In the case of homogeneous goods, he will define all relevant criteria but the price (2.2.4 Current Issues in E-Reverse Auctions). In the case of heterogeneous goods, some more criteria than just the price may vary within tolerable boundaries (2.2.4 Current Issues in E-Reverse Auctions). Usually, as in the case of simple bids, the quantity of the goods is pre-determined as well (2.2.4 Current Issues in E-Reverse Auctions). Yet, if goods are auctioned as bundled bids or volume discount bids, their exact quantity may not necessarily be fixed in advance (2.2.4 Current Issues in E-Reverse Auctions).
Once having decided on what and approximately how much to purchase, the buyer would then try to find a number of suitable suppliers. In order to identify appropriate suppliers, the buyer needs to assess and compare different suppliers. Usually, companies store data about their suppliers in the company’s information system in order to be able to assess and evaluate the suppliers’ excellence. Van Weele (2000) points out that supplier assessment may take place at four different levels:
• The product level. • The process level (production process). • The quality assurance system level. • The company level.
However, supplier evaluation is normally limited to the product level and the process level (van Weele, 2000). This means that the supplier file stored in the buyer’s information system may include corresponding information such as product range, product availability or process. Emiliani (2000) further suggests gathering information about the supplier’s quality performance and the delivery performance what would result in attributes like supplier’s quality, particular delivery costs and delivery times. Information on suppliers may derive from internal resources (e.g. past contacts with the supplier) as well as from external resources (e.g. credit
40 assessment, shares etc.) (van Weele, 2000). As it usually depends on the buyer what kind of information he/she wants to collect about his/her suppliers, most software tools allow the buyer to define his/her own attributes to assess the supplier.
Besides selecting appropriate suppliers, the buyer would also need to set the relevant parameters of the particular auction when starting it. As for these details, Korper and Ellis (2000:216) suggest that the following attributes should be determined:
• The particular auction items and their descriptions. • The start date of the auction. • The end date of the auction. • The auction method that determines the closing rules and notification process. • The expected terms of delivery. • The payment methods.
In addition, it may also be favourable to include other attributes such as the starting price or the currency. However, the importance of each of these attributes varies from company to company. Thus, e-reverse auction software would usually allow the buyer to create his/her own attributes.
When the buyer finally has selected a number of suitable suppliers and determined the auction parameters, it can be assumed that the invitation to the e-reverse auction may contain details of the e-reverse auction itself and the goods requested.
Korper and Ellis (2000) also suggest to include a registration mechanism in the e- reverse auction process for both the buyer and the suppliers. Generally, it can be assumed that this step has already been taken prior to the actual auction. In most cases, particularly when using public electronic marketplaces, the registration rules and procedures are already established between both companies due to existing relationships. However, in the case of inviting new suppliers, the hosting company would need to make sure that the auction component of the e-commerce software provides registration templates for each involved party (Korper and Ellis, 2000:216).
41 In addition to the processes just described, purchasing goods in companies also involves particular sign-off-procedures, i.e. before a request (i.e. order or auction invitation) is released to a supplier, it must have the formal approval of relevant authorities (van Weele, 2000). Depending on the type of purchase and the structure of the company, the relevant authorities may comprise cost centres or relevant managers. As e-reverse auctions are a particular practice to purchase goods, they should comprise an approval workflow as well.
As for the bid submission, it has already been mentioned that e-reverse auctions may need to include more complex bid structures such as multi-attribute bids, bundled bids, and volume discount bids (please see above 2.2.4 Current Issues in E- Reverse Auctioning).
The major problem, however, remains the appropriate evaluation of such bids (please see above 2.2.4 Current Issues in E-Reverse Auctioning). In e-reverse auction tools, bid evaluation is automated by using a bid evaluation engine. The evaluation engine must assist the buyer in his/her decision-making by providing the following functions (Kalagnanam, 2002):
• Winner determination, i.e. the bid evaluation engine identifies winning bids from a given set of bids to minimize the total cost. • Pricing, i.e. the bid evaluation engine calculates the price to be ‘paid’ by each winner. • Signalling, i.e. the bid evaluation engine must send a signal to the suppliers to reformulate their bids.
As illustrated above in Figure 6, the process flow of e-reverse auctions also requires that after every bid evaluation some feedback be given to the suppliers to help them reformulate their bids (Davenport et al., 2001). For simple single item auctions, this feedback is usually provided as a ‘clearing price’ at which supply for each item equals demand (Davenport et al., 2001). As for multi-item auctions, it is possible to develop clearing prices for bundles of items (Davenport et al., 2001). As mentioned above, the iterative process ensures that in any iteration only a small number of bundles with clearing prices need to be reported.
42 Taking everything into account that has been said above, the e-reverse auction process flow would consist of:
• An initial sequence of activities that need to be completed (i.e. registration, approval, invitation of suppliers, auction start). • An iterative process (i.e. bid submission, bid evaluation, feedback, bid reformulation) that only ends when there are no new bids. The availability of new bids may be influenced by time constraints due to the auction type, by financial constraints of the suppliers or by any preferences of the buyer.
2.3 Technology for E-Reverse Auction Software
E-reverse auctions represent a relatively new form of data exchanges between companies in purchasing situations. As briefly indicated above (2.2.3 ICT in Auctioning), the major advantage of using Internet technology to conduct e-reverse auctions is the great reduction of transaction costs, thus making e-reverse auctions even accessible to small enterprises.
In order to illustrate the technical constraints of e-reverse auction solutions, this chapter will focus on the technology that may be used for e-reverse auctions. The first section (2.3.1 Basic Requirements for E-Reverse Auction Software) will describe the basic requirements for software solutions concerned with e-reverse auctions. In the second section (2.3.2 Architecture for E-Reverse Auction Software), the typical architecture for web based software solutions will be presented in terms of their main components. Finally, the third section (2.3.3 The Internet as Tool for Integration) will investigate integration of e-commerce solutions with other relevant components such as back-end systems, the supplier’s system etc.
2.3.1 Basic Requirements for E-Reverse Auction Software
Generally speaking, the vision of Internet based commerce is a platform- and vendor-independent environment in which multiple parties can inter-operate (CompTIA, 2003). Partners of different sizes and technical levels should be able to
43 communicate and exchange data without difficulties. Consequently, an e-reverse auction solution and its corresponding architecture must allow for maximum freedom and flexibility on the one hand as well as rely on a shared standard to facilitate affordable data exchanges on the other hand. The requirements for e- reverse auction software and the corresponding architecture therefore can be summarized as follows (CompTIA, 2003; VICS, 1998; Butler Group, 2001:48):
• Standards: The model should use existing and commonly used standards wherever possible in order to be usable by as many companies as possible. Standards may include the network protocol, the data transport, the data format, the presentation etc. (VICS, 1998). • Scalability: As described above (2.2.2 Reverse Auctions; 2.1.4 Organisation of Electronic Purchases), e-reverse auctions can be used in different purchasing situations with different actors involved. Therefore, the system must be able to scale from small enterprise to large enterprise implementations. This means the software should be able to cope with a various number of transactions, trading partners, collaborative relationships, users, and collaboration interactions. • Security: Trust and privacy are major issues in a collaborative environment. Security can be ensured by user authentification, access control, confidentiality, and data integrity. Virtual Private Networks (VPN) such as intranets and extranets provide a solution to this problem: they set up a virtual connexion between two locations, over the public network but with data encryption to prevent eavesdropping and tampering by unauthorised parties. • Openness: Solutions that require a single vendor's application are not acceptable in today’s heterogeneous business environment. By using open and published standards, new trading partners can come online quickly, and the systems can evolve. In addition, an open solution must be based on mature technologies, because the rapid pace of development and market acceptance can take evolving technologies in diverging directions-including extinction. • Manageability: An Internet based software solution should be easily maintainable by all parties.
44 • Extensibility: In today’s fast growing and moving business world, the software model must be able to accommodate and expand future technology evolution while maintaining migration from one technology to another.
Consequently, an e-reverse auction tool needs to be scalable, secure, open, manageable, extensible and based on recognized standards.
2.3.2 Architecture for E-Reverse Auction Software
After having identified the general requirements for e-reverse auction technology this section will illustrate the basic architecture and components for web-based e- reverse auction solutions. According to Korper and Ellis (2000) and Zhong (2001), a typical web-based software solution comprises the following components:
• Web clients (or browsers). • Web server software. • The particular e-commerce software. • Connectivity tools. • Back-end systems such as databases, ERP-systems etc.
Figure 7: The Typical Architecture for Web-based Software Solutions (Korper and Ellis, 2000:92)
45 The components within the architecture illustrated in Figure 7 work in the following way:
Web clients (i.e. web browsers) provide the graphical user interface for accessing and displaying content (Kalakota and Whinston, 1997:96). Suppliers, for instance, can view the e-reverse auction progress using their browsers or buyers may view the current bids etc. The most widely used web browsers are Microsoft’s Internet Explorer and Netscape’s Navigator (Kalakota and Whinston, 1997:97).
The second major component of a web based e-commerce solution is the web server software and the commerce server software. They usually reside in the same hardware component (Korper and Ellis, 2000:92). The web server software serves as a middleman between back-end systems and front-end web clients/browsers (Korper and Ellis, 2000:95). Its primary function is to generate and deliver documents based on HTML, XML or similar on-the-fly so that it is readable for the web client/browser (Korper and Ellis, 2000:95). Usually a wide range of network operating systems is supported, including NT, UNIX, Novell, and OS/2 (Korper and Ellis, 2000:95).
Commerce server software on the other hand is concerned with the actual software application. It is therefore the heart of the e-reverse auction solution (Korper and Ellis, 2000:95). It generates and supports the particular functionality by providing the relevant implementation tools, commerce server management tools (i.e. content management9, replication and clustering10, site usage statistics, and remote administration), and back-end integration tools (Korper and Ellis, 2000:96). Many commerce server software solutions also include standard templates that can be readily customized or they include wizards to assist the users with building their own solution (Korper and Ellis, 2000:96).
Back-end systems may include relational databases, transaction-based systems, ERP systems, EDI, third-party software, and proprietary systems (Korper and Ellis,
9 Content management is a feature that allows managing content such as products, categories, supplier scorecards, design of pages etc. (Korper and Ellis, 2000:97). 10 Replication and clustering capabilities are standard features of the particular commerce software or management component.
46 2000:98). They typically already exist in an organization and require a connectivity tool to link them to the server software (Korper and Ellis, 2000:92).
Connectivity tools act as translators to connect back-end systems to server software or to front-end clients (Korper and Ellis, 2000:97).
2.3.3 The Internet as Tool for Integration
As mentioned above, the main idea for using Internet technology for B2B commerce is to facilitate the data exchanges between the business partners and even within the company. Integration therefore is of major importance for e-reverse auction solutions as the data to be exchanged, stored or processed usually derive from many different sources and may have many different formats. Kalakota and Whinston (1997:99) point out that the Internet provides an ideal platform to integrate remote systems as it allows for four distinct forms of integration:
• Linking data provided by different servers. • Providing clients with data from diverse sources. • Encompassing new types of data. • Integrating new helper or plug-in-applications.
The first and second forms are particularly important for e-reverse auction software as they enable the data exchange. Therefore, this section will examine and answer the questions of
• How data can be displayed and shared using Internet technology and • How different data sources can be integrated.
However, as it is impossible to illustrate all technical possibilities of achieving integration using the Internet, this dissertation will only focus on a few very common ways to achieve that goal.
2.3.3.1 Front-End Integration via Internet
This client/server architecture of the Internet is the key to solve the problem of sharing and displaying remote data. Exchanging and sharing information on the
47 Internet happen as follows: Information is contained on web servers that store files and respond to requests. On the Internet, each data item (i.e. usually web documents written in HTML or similar) is addressed by a uniform resource locator (URL) (Kalakota and Whinston; 1997:99). However, those web documents may also contain the URLs of other documents in form of links (Kalakota and Whinston; 1997:95). When a user clicks on a link, his/her web client/browser requests information from the web servers by specifying the corresponding URL (Kalakota and Whinston; 1997:99). The server then simply transfers the requested file back to the client/browser (Kalakota and Whinston; 1997:95). Figure 8 below illustrates how data can be shared using Internet technology:
Figure 8: The Basic Internet Architecture (Kalakota and Whinston, 1997:96)
Besides web server and web clients/browsers that have already been described above (2.3.2 Architecture for E-Reverse Auction Software), other important components of the Internet architecture that enable data exchanges are:
• The Hypertext Transport Protocol (HTTP). • The Uniform Resource Locator (URL). • The Hypertext Markup Language (HTML).
HTTP provides the language that allows web servers and web clients/browsers to communicate (Kalakota and Whinston, 1997:97). Each HTTP interaction follows the pattern described below (Kalakota and Whinston, 1997:97):
48 • The web client (browser) establishes a connection with the web server. • The web client (browser) issues a request to the web server. • The web server sends a response (i.e. the requested data). • Both the web browser and the web server disconnect and the transaction ends.
URL is the unique address of each web page. Web browsers use URL addresses to identify and allocate web servers and the data documents contained. As mentioned above, the advantage of the web lies in the ability to connect distributed pages using links, that allow a reader to move between different pages by clicking on them (Kalakota and Whinston, 1997:97).
HTML is a presentation language for web documents. It describes the contents of each web page (Kalakota and Whinston, 1997:97). The browsers then interpret this language to make the final presentation of this information to the user (VICS, 1998). The major benefits of HTML include its simplicity, its popularity, and the fact that contents of HTML sites can be viewed by minimal client requirements (Classen, 1999). However, there are also some shortcomings of HTML particularly regarding its application to e-commerce solutions (Classen, 1999):
• HTML is static. • HTML mixes data structures (e.g. the articles contained in a shopping cart with presentation instructions such as a table border of one pixel width, and a row background colour of red are not distinguished). • HTML does not identify the data elements, thus losing much meaningful information (e.g. the information that pens are articles, and that 3.99 is their price, is lost when using HTML). • HTML is not extensible to allow for user-defined tags.
XML (Extended Markup Language) is a new standard, recently endorsed by the World Wide Web consortium (W3C) to overcome the shortcoming of HTML (VICS, 1998; World Wide Web Consortium, 2003). XML is a meta-language, meaning that it is a language for defining other languages, while HTML by itself is
49 a more or less well-defined language (Classen, 1999). Thus, XML does actually not define any tags by itself, but only describes a way of defining one’s own set of tags and attributes (Classen, 1999). As a means of representing data, the advantages of XML in comparison to HTML can be summarized as follows (Butler Group, 2001:49):
• XML conveys information about the meaning of data, as well as the data itself. • XML makes it easier to search and filter data, based on meaning. • XML is not language specific, so it can be used on a global basis. • This again means that using XML the data can not only be presented to a human in a browser, but the data can also be passed to a computer process in a way that allows the computer to “understand” what that information is (VICS, 1998). Thus, XML can be displayed in almost any format and any device.
Due to these advantages, XML is much better suited than HTML for Internet based software solutions.
2.3.3.2 Back-End Integration via Internet
After having described how disperse data can actually be made available on the Internet, this section focuses on how the data contained in various back-end systems can be integrated with the e-reverse auction solution and the web server. Linking the existing back-end systems to the new commerce software remains one of the most challenging aspects (Korper and Ellis, 2000). Therefore, Korper and Ellis (2000:97) suggest that before selecting commerce server software, it is important to make sure that it can easily be integrated with the existing back-end systems. As mentioned above (2.3.2 Architecture for E-Reverse Auction Software) back-end systems may fall into five different categories:
• Transaction-based systems. • Electronic data exchange (EDI). • Enterprise resource planning (ERP) systems. • Relational databases.
50 • Proprietary systems.
Integrating the e-commerce solution with the back-end systems usually is of major importance for the company (Korper and Ellis, 2000; Kalakota and Robinson, 2000; Kalakota and Whinston, 1997): The sharing and quick accessing of documents allows reduced cycle times, errors and costs (see above 2.1.3 ICT in Purchasing). Consequently, the e-reverse auction software should include integration to these systems by providing appropriate connectivity tools.
As for databases, the commonly supported ones usually include Microsoft’s SQL, IBM’s DB2, and Oracle’s relational databases (Korper and Ellis, 2000:98). In the case of ERP systems, e-commerce software usually supports integration with some of the most common ones such as People Soft and SAP (Korper and Ellis, 2000:99). Connections to transactional systems are normally provided as well, although with varying degrees of compatibility: Some vendors such as IBM include integration into any back-end environment, whereas others such as Microsoft, have not focused on providing the same breadth of connectivity (Korper and Ellis, 2000:99).
As mentioned above (2.3.3.1 Front-End Integration via Internet), XML is a good tool to enable and facilitate application-to-application interchanges. However, there are two other common ways to achieve integration with external data sources: Common Gateway Interfaces (CGI) and Application Programming Interfaces (API).
The CGI (Common Gateway Interface) is a standard for interfacing external applications with web servers (NCSA HTTPd Development Team, 1998). Whereas HTML documents are static (i.e. it exists in a constant state), CGI scripts are executed in real time meaning that they can output dynamic information (NCSA HTTPd Development Team, 1998). Web servers integrate the different data sources by allowing CGI programs to run in response to client requests; the CGI programs then perform general computations including accepting form data, communicating with other computers, and creating dynamic pages (Kalakota and Whinston, 1997:99). If for instance information contained in a database should be displayed to a client/browser, a CGI script needs to be created first (NCSA HTTPd Development Team, 1998). The Web daemon then will execute this CGI script to transmit information to the database engine, and receive the results back again to display
51 them to the client (NCSA HTTPd Development Team, 1998). CGI scripts are not database-specific and may be written in virtually any high-level language such as C/C++, Fortran, PERL, TCL, Apple Script, Visual Basic, and any Unix shell, although C and PERL are the most popular programming languages, since they run on most platforms (Kalakota and Whinston, 1997:107; NCSA HTTPd Development Team, 1998). Figure 9 below illustrates how a CGI script can interact with a database management system (DBMS) to pass data into a database and return data from the database to the web browser as a formatted HTML file (Kalakota and Whinston, 1997:106).
Figure 9: CGI and the Internet (Kalakota and Whinston, 1997:96)
An API (Application Programming Interface) serves as a middleman between two different software applications (e.g. a word processor and a spreadsheet) by making requests between the two different systems (Korper and Ellis, 2000:99). This provides for data sharing across different platforms and therefore is a way to achieve the total cross-platform consistency that is a goal of open systems (Bray, 2000). APIs are particularly important when developing new or upgrading existing distributed systems (Bray, 2000). There are four types of APIs that enable data sharing between different software applications on single or distributed platforms (Bray, 2000):
• Remote Procedure Calls (RPCs), i.e. programs that communicate via procedures (or tasks) that act on shared data buffers.
52 • Standard Query Language (SQL), i.e. a non-procedural data access language that allows retrieving data and exchanging it between applications by providing access into a common database. • File transfer, i.e. data sharing by sending formatted files between applications. • Message delivery, i.e. data sharing by direct inter-program communications via small formatted messages between loosely- or tightly-coupled applications.
Whereas CGI programs require additional storage place to execute separate processes for each client request, APIs execute all processes in the same storage place. Thus, APIs require less storage space. In addition, initialization with the client is only done once for all client requests. APIs are also able to maintain a real- time connexion. This is of major advantage for applications such as e-reverse auctions that heavily rely on accessing databases.
2.4 Summary
Considering the evidence obtained from the literature review, the following conclusions concerning e-reverse auctions may be drawn: First, the investigation of purchasing illustrates that e-reverse auctions may be applied only towards the end of a typical purchase process when prices are not fixed (2.1.1 Definitions: Purchasing and E-Procurement). In theory, both strategic and spot purchases can be conducted via e-reverse auction software (2.1.2 The Different Dimensions of Purchasing). However, the buyer needs to be aware of potential constraints in strategic purchasing. The goods auctioned may include any type goods (2.1.2 The Different Dimensions of Purchasing). Usually, the purchase department is in charge of conducting the e-reverse auction (2.1.2 The Different Dimensions of Purchasing). The goods may either be auctioned via private B2B exchanges (i.e. intranet, extranet) or via public electronic marketplaces (2.1.4 Organisation of Electronic Purchases).
Second, like common auctions, e-reverse auctions may vary in their format (2.2.2 Reverse Auctions). The auction format determines the rules for the actual procedure. The current issues in e-reverse auctions derive from the difficulty to
53 implement the complex decision process when evaluating the submitted bids. Current issues include the modelling of multi-attribute bids, of bundled bids and volume discount bids (2.2.4 Current Issues in E-Reverse Auctioning). By relying on an iterative process, some of these problems are partially resolved (2.2.5 Process of E-Reverse Auctions). The typical e-reverse auction process would thus consist of the following sub-processes:
• An initial sequence of activities that need to be completed (i.e. registration, approval, invitation of suppliers, auction start). • The actual iterative auctioning process (i.e. bid submission, bid evaluation, feedback, bid reformulation). This sub-process only ends when there are no new bids.
Third, the major requirements for e-reverse auction software include scalability, security, openness, manageability, extensibility, and the implementation of recognized standards (2.3.1 Basic Requirements for E-Reverse Auction Software). The Internet helps meeting these requirements as it allows for sharing and displaying remote data and integrating different data sources (2.3.3 The Internet as Tool for Integration). Sharing and displaying remote data is primarily enabled by technologies such as HTTP, URL, HTML, and most recently XML. Back-end integration on the other hand can be achieved via XML, CGI and API.
54 3 Results and Findings
The aim of this chapter is to present the results and findings of the case study conducted in cooperation with the German software developer Hybris. The first section (3.1 Domain Description) will briefly illustrate what has been found out about the problem domain of e-reverse auctioning. The second section (3.2 The Problem Situation expressed: Rich Picture) will describe the rich picture obtained from the first step of the SSM analysis. The corresponding CATWOE analysis and the root definition will then be presented in the third section (3.3 Root Definition and CATWOE Analysis). The development and description of the conceptual model will be part of the fourth section (3.4 The Conceptual Model). Based on the final conceptual model, the resulting functional and non-functional requirements of the e-reverse auction tool will be presented in section five (3.5 The Requirements). The corresponding Business System Options of the e-reverse auction tool will be developed in the sixth section (3.6 The Resulting Business System Options (BSOs)). In order to illustrate the technical environment of the e-reverse auction tool, section seven (3.7 Implementation) will have a closer look at the particular technical environment of the e-reverse auction tool which will enable the suggestion of appropriate Technical System Options that will be presented in section eight (3.8 The Resulting Technical System Options (TSOs)).
3.1 Domain Description
Generally speaking, the e-reverse auction tool developed by Hybris will be used in B2B purchasing. Three potential application areas can be differentiated (int01): Firstly, the tool may be used to auction homogeneous goods from suppliers (int01). This situation is conceivable when searching for a particular good in an e-catalogue, e.g. a monitor (int01). The monitor would need to satisfy certain criteria pre- determined by the buyer. The suppliers of all monitors meeting these criteria could be invited to an e-reverse auction. As all monitors auctioned would satisfy the same pre-determined criteria, the price remains the only distinguishing factor. During the e-reverse auction, the price would then need to be adjusted by the suppliers in order to make the best offer.
55 Secondly, the e-reverse auction software may be used for auctioning heterogeneous goods after having obtained different proposals from different suppliers. The reason for first sending out requests for proposals is to homogenize the heterogeneous goods and make them comparable (int01). Then, the preferred comparable proposals are selected and the buyer conducts an e-reverse auction for the now ‘homogeneous’ remaining proposals (int01).
Thirdly, the e-reverse auction tool might be applied for purchasing and selecting heterogeneous goods. In this case, the comparability of the goods would need to be achieved by the auctioning software during the auction process. However, this scenario is futuristic rather than current (int01). The interviewee (int01) suggests that the e-reverse auction tool should initially only focus on homogeneous C-items that can be selected from a catalogue (int01). The reason is that Hybris already has valuable experience in catalogue-based procurement of such goods (int01). By applying the tool to a familiar environment, the risks related to the development and the use of the new tool could be minimized.
In the following sections, the problem situation related to e-reverse auctions will be described in more detail by presenting evidence obtained from the interviews. As mentioned above (1.5.2 Approach to Research), SSM is used to systematically analyse the problem and develop appropriate solutions.
3.2 The Problem Situation Expressed: Rich Picture
Drawing a rich picture is important to clarify and understand the problem situation. The rich picture represents the important people, activities, relationships, and issues of the problem situation (Avison and Fitzgerald, 2003:162). This section will describe and present the rich picture of e-reverse auctions. The rich picture obtained from the interviews is illustrated in Figure 10.
56 Give technical support
3RD PARTIES HYBRIS Give technical support; Help customizing MANAGEMENT BOARD OF OWNING COMPANY IT OF THE OWNER Need to have a transparent purchase process Need to reduce Give Need to costs! Give technical control all technical support purchases! support Bid BUYER: PURCHASING We don’t DEPARTMENT Need to want our reduce margins to be costs! brought Invite Suppliers; Get bid Give Approval; down! details; Evaluate bids; Get relevant Notify bidders. data Need transpare Give SUPPLIERS ncy and Place Order Approval; Control purchases; control! Get relevant Bundle orders data
Want to be able to buy quickly and Give easily! Approval; CONTROLLING Need to Get relevant Need to have reduce data transparency and costs! control of my employees Need to purchases! reduce RELEVANT MANAGER Need to have ANY EMPLOYEE costs! transparency WITHIN BUYING COMPANY and control of all purchases! COST CENTRE
Index: External Controlling Body Crossed Swords (conflict area) Relationship between entities Major concerns
People within the system
Figure 10: The Rich Picture of E-Reverse Auctions
The two main stakeholders within e-reverse auctions are a particular buyer and its suppliers as both of them are directly involved in the e-reverse auction process. According to the interviewee (int01), the buyer can either be a particular employee of the purchasing department or any other employee within the buying organization who wants to make a purchase via e-reverse auction (int01).
“Der Einkauf wird dann entweder vom einzelnen Mitarbieter am Arbeitsplatz getaetigt oder aber von Mitarbeitern des Einkaufs.” (int01) [“The purchase can be conducted from the desktop by any employee or by employees of the purchase department.” (int01)]
57 However, considering the fact that the e-reverse auction tool should initially only be used for C-items, it seems very unlikely that each employee within the buying organisation would be allowed to initiate an e-reverse auction, for instance to buy a single pen. As indicated in the literature review (2.1.2 The Different Dimensions of Purchasing), it appears more likely that all single orders for C-items first are bundled at the purchase department and that the purchase department then conducts an e-reverse auction for the bundled orders. Consequently only the purchase department acts as the buyer within e-reverse auctions. All other employees within the company will just place purchase orders. Certainly, those orders need to be approved by the relevant authorities, but this happens independently from e-reverse auctions within e-procurement. As this process is not relevant for e-reverse auctions, it is not included in the rich picture (see above, Figure 10).
Buyers and suppliers generally use the e-reverse auction software to conduct a reverse auction. This means the particular purchase department invites the suppliers to the reverse auction and the suppliers submit their bids. After having viewed and evaluated the bids via the software tool, the buyer then notifies the suppliers of the further proceedings.
Besides the purchase department, the employees of the buying company and the suppliers, there are many other parties relevant to e-reverse auctions, such as the relevant cost centres within the buying company, the particular manager(s) of the buyer, and the controlling:
“Das Controlling, die Budgetverantwortlichen beziehungsweise die Kostenstelle muessen auf die Daten zugreifen koennen und checken, ob das Budget in Ordnung ist und solche Sachen. Die muessen dann eine aktive oder passive Genehmigung geben.” (int01). [“The Controlling, the relevant managers respectively cost centres need to have access to the relevant data to check whether the budget is okay etc. They then need to give their active or passive approval.” (int01)]
However, those parties are not involved in the actual e-reverse auction process as such, they are only controlling bodies:
58 ”[Sie sind] aber eigentlich nicht direkt in den Prozess eingebunden, sondern kontrollieren nur.“ (int01) [“They are not directly involved in the process, they only control” (int01)]
The major concerns of the controlling, the relevant managers, and the purchase department involve the following (int01):
• Having a transparent purchase process. • Controlling the purchases, particularly the preventing maverick spending. • Achieving cost reductions.
“Fuer das Controlling geht es auch darum, die Uebersicht zu behalten, Transparenz zu haben, rogue buying zu verhindern. Dadurch erhaelt man Kontrolle ueber den Prozess. Man kann so auch die Kosten senken ueber Kontrolle von rogue buying, Kostenbuendelung und Genehmigung.” [“The controlling wants to keep track of the purchases, wants to have transparency in order to prevent rogue buying. Cost reductions can be achieved via the control of rogue buying, the bundeling of orders, and approval workflows.” (int01)
“Die Mitarbeiter wollen es moeglist einfach haben, schnell an ihre Sachen kommen und auch moeglist schnell die Genehmigung zu erhalten.” (int01) [“The particular employees within the buying organization primarily want to have a simple purchase process that is easy to understand; they want to get their purchases as well as the bosses approval quickly as possible.” (int01)]
Regarding the suppliers, reverse auctions may cause serious concerns:
“In vielen Faellen wird Druck ausgeuebt, dass der Lieferant ein solches System nutzt. Das System ist oftmals darauf ausgelegt, dass seine Margen gesenkt werden. Das ist natuerlich ein Problem. In dem Moment, in dem die Gueter homogen sind, geht es nur noch darum, den Preis zu senken.” (int01) “Hier koennten z.B. Auktionen um heterogene Gueter Abhilfe schaffen.
59 Lieferanten koennen sich dort ueber andere, einzigartige Merkmale als nur den Preis profilieren.” (int01) [“In many cases, suppliers are forced to take part in e-reverse auctions. Usually, e-reverse auctions aim to bring down the suppliers’ margins. This, of course, is a major problem. In the case of homogeneous goods, the only relevant factor is price.” (int01) “In this case, reverse auctions including heterogeneous goods may help. Suppliers then could distinguish themselves by more than just the price attribute.” (int01)]
Participating in e-reverse auctions, however, may also provide benefits for suppliers. Particularly small suppliers being part of a large enterprises e-reverse auction system may profit from the large buyer’s influence on the suppliers’ suppliers (int01).
The owner of the system is the particular company represented by its management board that bought the e-reverse auction software from Hybris (int01). Usually, this is the buying company, but sometimes, it may as well be a supplier who wants to provide added value to his buyers (int01). If the system is used as marketplace, the owner is then particular service provider (int 01). However, as the owner of the system is relevant to it, it must be included as external entity.
The IT entity in the rich picture refers to the IT department of the owner, i.e. the company who bought the e-reverse auction software. Besides their potential involvement in initiating the purchase of the software (int01), the IT department controls the system in terms of operation and maintenance. Their task is to support the users of the system if any technical problems occur. However, it is important to understand that even though the e-reverse auction tool is developed by Hybris, it needs to be customized and implemented. Customizing and implementation are usually done by other third parties (int01). As a consequence of this collaboration, Hybris gives technical support only to the relevant third parties who in turn provide technical support to the owner of the software.
“Wir bieten den Support in erster Linie fuer den Partner an.” (int01) “Der Partner macht den Support fuer den Endkunden.” (int01) [“We primarily provide support for the particular partner.” (int01) “The partner then supports the end customer.” (int01)]
60 3.3 Root Definition and CATWOE Analysis
The root definition is a concise verbal description of the system which captures its essential nature (Avison and Fitzgerald, 2003:162). According to Avison and Fitzgerald (2003), it is bound to contain the answers to the following questions:
• Who is doing what for whom? • To whom are they answerable? • What assumptions are being made? • In what environment is this happening?
3.3.1 The Clients: For Whom?
Clients include the victims or beneficiaries of the transformation process (Checkland and Scholes (1990:35). In the case of e-reverse auctions, they include:
• The purchase department. • Any employee within the company who wants to buy something. • Controlling of the buying company. • Cost centres of the buying company. • Relevant bosses of buying people. • The management board of the buying company. • The suppliers. (int01)
The purchase department, the controlling, the cost centres, and the relevant bosses benefit from e-reverse auctions as this software tool allows for achieving cost reductions, controlling the purchase process, and having more transparency within purchasing. Therefore, they are considered to be clients of e-reverse auctions. On the other hand, the suppliers are affected as well by the introduction e-reverse auctions. E-reverse auctions generally present a new way of selling goods. They alter the way of dealing with buyers and may even have negative effects on the suppliers’ margins. Regarding the fact that e-reverse auctions mainly focus on driving down their margins, suppliers may rather considered to be victims than beneficiaries. However, the introduction of this new software may also have several
61 advantages as described above (3.2 The Problem Situation Expressed: Rich Picture, 2.2.3 ICT in Auctioning).
3.3.2 The Actors: Who?
Actors correspond to the ‘who’ in the definition given above. They are the agent of change, the ones who actually carry out the transformation process (Avison and Fitzgerald, 2003:162). Regarding the rich picture (Figure 10 in 3.2. The Problem Situation Expressed: Rich Picture), the major activities within the system (i.e. the above named transformation) are carried out by the buyer (i.e. the purchase department) and the suppliers.
3.3.3 The Transformation: What?
The transformation process determines the conversion of input to output (Checkland and Scholes, 1990:35). It is the actual change taking place and therefore the core of the root definition (Avison and Fitzgerald, 2003:162).
When using e-reverse auctioning, the actual change that is taking place concerns the purchase process as e-reverse auctions provide a new way to purchase goods (int01). In e-reverse auctions the purchase process is usually referred to as bidding. Therefore, the transformation caused by the introduction of new e-reverse auction software concerns bidding and all related activities. This includes
• Bidding. • Viewing bid details. • Evaluating bids. • Notifying the bidders. (int01)
The approval of relevant authorities for conducting e-reverse auctions may also be a relevant activity within e-reverse auctioning:
“Die Genehmigung haengt natuerlich groesstenteils auch davon ab, was im jeweiligen Unternehmen vorherrscht. Manche sagen dann, ja wir brauchen eine Genehmigung, andere halt nicht. Aber meistens ist es dann schon so, dass am Ende nochmal jemand die Entscheidung genehmigt, eine reverse
62 auction durchzufuehren.” (int01) [“The need for approval mainly depends on the climate within the particular company. Some companies do ask for approval, others don’t. But usually, there is some entity approving the decision to conduct an e-reverse auction.” (int01)]
Assessing and pre-selecting suppliers are not necessarily activities performed within e-reverse auctions:
“In einem E-Reverse Auction Tool ist die Lieferantenvorauswahl bei der Versteigerung heterogener Güter wichtig. (…) Ansonsten ist es nicht relevant fuer Reverse Auctions.” (int01) [“Pre-selecting suppliers is only important when auctioning heterogeneous goods. (…) Besides that, it is not relevant for reverse auctions.” (int01)]
As e-reverse auctions for heterogeneous goods do not represent a current area of interest (see above 3.1 Domain Description), the assessment and pre-selection of suppliers need not be included at present.
3.3.4 The Weltanschauung: Assumptions
According to Davies and Ledington (1991:69), Weltanschauung is the image of the world that makes the transformation meaningful in context. The worldview that makes e-reverse auctions meaningful is the prevailing assumption that they allow for more transparency, cost reductions, better control, and greater simplification of processes within purchasing.
“Die Hintergrundgedanken bei der Einfuehrung der Software sind sicherlich Transparenz, Kontrolle, Kosteneinsparungen und die Vereinfachung des Einkaufsprozesses.” (int01) [“The assumptions for introducing the software comprise the belief that transparency, control, cost reductions and a more simplified purchase process can be achieved.” (int01)]
3.3.5 The Owner
The owner of the system is the one that is answerable, i.e. the sponsor or controller (Avison and Fitzgerald, 2003:163). Checkland and Scholes (1990:35) point out that
63 owners are those who could stop the transformation. As mentioned above (3.2 The Problem Situation Expressed: Rich Picture), the owner of the e-reverse auction system is the particular Hybris client represented by its management board (int01). This may either be a buyer, a supplier or an independent service provider who offers the system as marketplace (int01).
3.3.6 The Environment
Checkland and Scholes (1990:35) refer to environmental constraints and define them as elements outside the system which it takes as given. Environment therefore includes the wider system of which the problem situation is a part (Avison and Fitzgerald, 2003:163). E-reverse auctions can generally be part of any business environment:
“Im Prinzip ist die Software branchenneutral.” (int01) [“In principle, this software can be used in any industrial sector.” (int01)]
Thus, the environment of e-reverse auctions is the business world in general with all its constraints, restrictions and regulations. However, it needs to be taken into account that e-reverse auctions are a very recent application within e-business. Therefore, further specialisation of e-reverse auction tools may take place in the future. Consequently, the environmental constraints will then become more and more specific:
“Allerdings kann man sagen, je spezifischer die Art der zu kaufenden Güter in Richtung A-Güter, desto höher ist der Branchenfokus der Software.” (int01) [“Admittedly, it needs to be said that the increasing complexity of the goods to be purchased via the software will lead to an increased focus on the particular industrial sector.” (int01)]
But as already mentioned above (3.1 Domain Description), this is a future challenge rather than a current one (int01). Therefore, it is not considered in this dissertation.
64 3.3.7 The Resulting Root Definition
The resulting root definition for e-reverse auctions based on the general format suggested by Checkland (1981:317) is as follows:
E-reverse auctions are a system owned by a Hybris customer which, under the environmental constraints of the business world, which it takes as given, transforms the traditional bidding process into an electronic bidding process by carrying out the activities of inviting the bidders, bidding, viewing the bid details, evaluating bids, and notifying the bidders. The transformation is carried out by the particular buyer (i.e. the purchase department) and its suppliers and will affect the purchase department of the buying company, any employee within the buying company, the controlling department of the buying company, the cost centres of the buying company, the relevant bosses of the particular buyers, the management board of the buying company, and the suppliers. E-reverse auctions are made meaningful by a view of the world captured in the belief that they can achieve transparency, control, cost reductions and a simplified purchase process.
3.4 The Conceptual Model
The conceptual model is obtained from assembling and structuring the minimum but necessary set of activities required of the system named in the root definition (Davies and Ledington, 1991:85). To ensure that the conceptual model only contains the relevant activities and relates to the root definition, Davies and Ledington (1991) suggest the following procedure:
• Identifying and extracting the verbs which form the main transformation. • Organizing the verbs into activities and defining the main logical dependencies. • Considering each activity in turn and asking “What activities must go on directly prior to this activity?”. • Adding control activities by considering the idea of the system.
65 The modelling process is complete when no further iterations are required to add missing elements (Davies and Ledington, 1991:91).
3.4.1 Identifying and Extracting the Verbs which Form the Main Transformation
As stated in the root definition above (3.3.7 The Resulting Root Definition), the activities performed in e-reverse auctioning include inviting the suppliers, bidding, viewing bid details, evaluating bids and notifying the suppliers (int01).
3.4.2 Organizing the Verbs into Activities and Defining the Main Logical Dependencies
Organizing the verbs into activities and putting them in the logically correct order leads to the following first draft conceptual model (Figure 11):
Invite suppliers
Submit Bids
View Submitted Bids
Evaluate Submitted Bids
Give Feedback to Suppliers
Figure 11: The First Conceptual Model for E-Reverse Auctions
66 3.4.3 Considering Each Activity in Turn and Asking “What Activities Must Go on Directly Prior to this Activity?”
When focussing on each activity and reconsidering it in terms of preceding activities it becomes clear that there are some important steps missing before a buyer can actually invite the suppliers and before the suppliers can submit their bids. First, it can be assumed that the particular suppliers would first need to register with the buyer’s company in order to be allowed to participate in the reverse auction. The registration only needs to be done once to give the suppliers access to the e-reverse auction and at the same time save all the relevant data about the particular suppliers in the database (int01). The successful registration would then be confirmed by sending out a confirmation to the particular supplier. Thus, it is indispensable to include an activity called ‘Register suppliers’ and ‘Confirm Registration’ as initial steps within the process (please see 2.2.5 Process of E- Reverse Auctions).
Second, it is common practice that suppliers do not submit their bids immediately after having received an invitation to an e-reverse auction. Before being able to invite suppliers, the buyer will have to officially have started the auction. This means setting the relevant auction parameters such as the items to be auctioned, the start date and the end date of the auction, the terms of delivery, the payment methods available and the auction method that determines the specific closing rules and notification process (Korper and Ellis, 2000:216) (please see above 2.2.5 Process of E-Reverse Auctions). Usually, these attributes will then be contained in the invitation sent to the suppliers.
What also becomes clear when reconsidering each activity in terms of preceeding and following activities is that e-reverse auctions do not form a sequential process:
“Im Internet ist es so, dass die Transkationskosten sinken, so dass man auch mehrere Runden durchlaufen kann.” (int01) [“The Internet has greatly reduced the transaction costs so that it is possible to have several rounds.” (int01)]
67 Hence, the reverse auction ends when there are no new bids submitted in the end of a round. Otherwise, just the round ends and the next iteration starts with suppliers submitting their bids. Within this iterative process it becomes obvious that suppliers may need to reconsider and reformulate their bids depending on the feedback they obtained from the buyer (2.2.5 Process of E-Reverse Auctions). In reformulating their bids, the suppliers will determine whether they are going to continue bidding and how or whether they are going to quit the e-reverse auction. Hence, the conceptual model needs to be extended by including an activity “Suppliers may reformulate their bids”.
The considerations made above have been included in the following evolved conceptual model for e-reverse auctions:
Register Suppliers
Confirm Registration
Start Auction End Auction
Invite the Suppliers If there are no new bids
Else Submit Bids Close Round
Evaluate Bids Reformulate Bids Give Feedback to Suppliers
Figure 12: The Second Conceptual Model for E-Reverse Auctions
3.4.4 Adding control activities by considering the idea of the system
The major control activity within e-reverse auctions is their approval by the relevant authorities. As mentioned before (3.3.3 The Transformation: What?), a buyer may need the approval of the relevant managers, cost centre and/or the
68 controlling depending on the company’s structure. It can be assumed that registration of the suppliers will already have taken place when asking for approval to conduct an e-reverse auction because most suppliers will already have been registered due to prior interactions with the company. Even in the case of new first time suppliers, the approving authority may with to know who exactly is going to take part in the e-reverse auction as this might be an important detail. Therefore, it appears sensible to approve the auction after having registered all suppliers. But as mentioned before, it depends on the companies policy whether and who to implement the approval workflow (int01). Including this activity, the conceptual model looks as follows:
Register Suppliers
Confirm Registration
Approve Auction
End Auction Start Auction
If there are Invite Suppliers no new bids
Else Submit Bids Close Round
Evaluate Bids Reformulate Bids Give Feedback to Suppliers
Figure 13: The Final Conceptual Model for E-Reverse Auctions
3.5 The Requirements
Based on the conceptual model, this section will focus on the requirements of the e- reverse auction tool, i.e. which functionality it should provide and which additional non-functional requirements it should meet.
69 3.5.1 Functional Requirements
According to Weaver (2002:73), the functional requirements of a system include descriptions of the actions or processes the system should carry out. This is in accordance with interviewee int01 who points out:
“Das System sollte natuerlich die eben beschriebenen Prozesse abbilden.” (int01) [“The system should certainly include the processes just described.” (int01)]
Hence, the e-reverse auction software needs to support the following functions:
• Registering suppliers. • Confirming the registration of the suppliers. • Approving the e-reverse auction by the relevant authorities. • Starting the e-reverse auction. • Inviting the suppliers • Submitting the bids. • Evaluating the bids • Giving feedback to suppliers • Reformulating the bids. • Closing a round. • Closing the auction.
The functional requirements of the e-reverse auction tool are listed in Figure 14 with their relevant descriptions.
70 Req.-ID Req.- Name Requirement Description Priority F01 Register The registration usually needs to be done once to give Essential. suppliers the suppliers access to the e-reverse auction and at the same time save all the relevant data about the particular suppliers in the database (int01). F02 Confirm The registration needs to be confirmed to give the Essential. registration supplier access to the e-reverse auction system. This may be done electronically by sending an email with an appropriate user ID and password. F03 Approve auction Approval should be given to the buyer as quickly as Desirable. possible (int01), preferably electronically. All data relevant to this process should be made available electronically. F04 Start auction The buyer starts the auction by determining the relevant Essential. parameters such as the items to be auctioned, their description, the start date and the end date of the auction, the terms of delivery, the payment methods available, and the auction method that determines the specific closing rules and notification process (Korper and Ellis, 2000:216). It is important that the software calculates an optimal starting price (int01). Else, the buyer may risk wasting money (int01)11. F05 Invite suppliers Before the auction begins, the buyer needs to invite Essential. selected suppliers to participate in the auction. The invitation should be sent as email containing a link to the e-reverse auction (int01). This gives the suppliers access to the particular auction. The email may also contain the relevant parameters of the auction mentioned above. The email may be generated by the software and have a predefined format. F06 Submit bids The suppliers should be able to submit the bids to the Essential. supplier by using the software. Again, the bids may have a predefined format. F07 Evaluate bids It is very important to evaluate the bids accurately Essential. (int01). This includes comparing all submitted bids and ranking them. As the e-reverse auction tool should be used to purchase C-goods (int01), it can be concluded that it needs to be able to handle bundled bids and volume discount bids and evaluate them appropriately (please see above 2.2.4 Current Issues in E-Reverse Auctioning). F08 Give feedback Giving feedback means that the buyer selects the best Essential. bids. He should be able to give the corresponding feedback to the suppliers electronically. F09 Reformulate The suppliers must be able to refine certain attributes of Essential. bids their bids based on the feedback that was given to them. They must be able to quit the auction or stay for another round. Again, this activity needs to be done electronically. F10 Close round The end of a round must be indicated electronically via Essential. the software to both the buyer and the suppliers. F11 End auction The end of the auction must be indicated electronically Essential. via the software to both the buyer and the suppliers. The general criterion for ending an auction is if there are no new bids available. However, the reason for bids being available or not has been pre-determined by the buyer by setting the relevant parameters when starting the auction and/or making his choices.
Figure 14: The Functional Requirements
11 There are, for instance, two suppliers (S1, S2). S1 would supply the good for 5£, S2 for 7£. The starting price is 9£. The auction would end at 6.99£ with the leaving of S2. However, if the starting price had been set 6£, the buyer would have been able to achieve further cost reductions from S1. However, this is a difficult optimization problem and can’t be resolved here.
71 3.5.2 Non-Functional Requirements
However, the e-reverse auction software also needs to satisfy certain non-functional requirements. Non-functional requirements detail how or within what limits a functional requirement should be met (Weaver, 2002:74).
“Wichtig ist es, die entsprechenden Informationen zu den Lieferanten in einer Datenbank zu speichern, um darauf zugreifen.” (int01) [“It is important, that the relevant information about suppliers is stored in the database in order to access this information.” (int01)]
Storing and accessing supplier data in the database is not only crucial for the supplier’s registration and invitation to the e-reverse auction. It may also be an important decision support when selecting and inviting suppliers to e-reverse auctions (int01). As information relating to suppliers needs to be accessed frequently, it is important to make it available in the database because this allows for easy access. Data about suppliers may include external information about suppliers such as credit assessment, turnover etc. but also internal information such as quality assessment, performance etc. (int01).
In order to allow relevant authorities (e.g. buyers, managers, controlling or cost centres) to access data related to e-reverse auctions appropriately, it is indispensable to integrate the new software within existing systems and applications (int01).
“Die Software sollte sich in das bisherige System integrieren, also ERP or Human Resources.” (int01) [“The tool should be connected to the existing systems, for instance ERP or Human Resources software.” (int01)]
This allows for sharing, accessing, updating, and storing data appropriately. In order to ensure that suppliers can take part in the e-reverse auction independently from the software system they are currently using, they need to have web-based access:
“Die Lieferanten sollten das System nach Moeglichkeit webbasiert nutzen koennen.” (int01) “Insofern koennte man Lieferanten auch nur fuer eine einmalige Auktion anbinden.” (int01) [“The suppliers should be able to use
72 the system via web-browser.” (int01) “In that it may be possible to connect and integrate suppliers for just one single auction.” (int01)]
This would not only allow for more competition between the suppliers but is at the same time an essential requirement if the system is going to be used as a marketplace. As for marketplaces, web-based access even becomes a crucial requirement for conducting e-reverse auction. In this case, both buyers and suppliers would need to access the system from ‘outside’. Due to the low transaction costs on the Internet, web-based access represents the only feasible way to integrate a great number of different participants is the best choice to enable a great number of people to take part in e-reverse auctions independent from the system they are currently using.
Initially, the e-reverse auction software should not be specified to meet the requirements of a particular industry:
“Eigentlich ist die Softwareloesung branchenneutral. Man muss natuerlich sagen, je spezifischer das ganze spaeter wird, d.h. je mehr ich mich von C- Guetern hin zu A-Guetern bewege, desto spezifischer muss dann auch die Software sein.” (int01) [“Initially, the software solution does not focus on a particular industry. However, one must admit that if the reverse auctioning is going to be more specific in the future, i.e. the more I focus on B- and A- goods, the more specific needs the e-reverse auction software to be.” (int01)]
As can be seen from this quotation, the requirement not to focus on a particular industry is directly related to question of which goods should be auctioned with the software. As indicated above, the software should initially only be used to conduct e-reverse auctions for homogeneous goods within catalogue-based e- procurement (int01). This means that the goods to be auctioned will derive from an electronic catalogue and thus, will be comparable regarding all attributes. Due to the simple and general nature of catalogue-based goods, the software does not focus on a particular industry anyway. Only when the goods become more special to a certain industry as in the case of production related A-goods, the software may need to provide facilities to auction more complex goods taking into account a variety of
73 heterogeneous factors. However, it is only in future when facilities for auctioning heterogeneous and more complex goods may be added (int01).
Regardless in which industry the software will be used, it remains very important that it relies on a certain classification system in order to make the different offers comparable:
“Das wichtigste Thema ist eine Vergleichbarkeit der Gueter zu schaffen. (…) Das ist Aufgabe der Klassifizierung. Man hat einen Produktbaum, mit Produktgruppen, Untergruppen, Typen, und verschiedenen Attributen. Anhand derer kann man dann eindeutig klassifizieren.” (int01) [“The most important topic is to achieve the comparability of goods. (…) This is the task of a classification. There is a product tree that consists of different product groups, subgroups, types and different attributes to clearly describe the products.” (int01)]
Only when all attributes describing the product are the same, a reverse auction can be conducted to cut down the price.
Regarding the development costs for e-reverse auction software, it seems sensible to first implement only the most common type of e-reverse auctions: the English reverse auction (int01). This may reduce the development cost and risk. Thus, the software needs to comprise the algorithms relevant for this type of e-reverse auction.
All non-functional requirements are summarized and described in Figure 15 below.
74
Req.-ID Req.-Name Requirement Description Priority N01 Store information The relevant data about suppliers needs to be Essential. about suppliers in stored in a database. This data may include database external information about suppliers such as credit assessment, turnover etc. but also internal information such as quality assessment, performance etc. (int01). N01 Provide integration The software must accurately be embedded Essential. with existing systems and integrated in the existing system. This and applications ensures that all relevant data can be exchanged, stored and accessed appropriately. N03 Provide web-based The system must be accessible via web Essential. access browser. This ensures that external parties can participate regardless the system they are currently using. It is at the same time a major requirement to use the system as a marketplace. N04 Provide facilities to The system should initially only provide facilities Essential. auction homogeneous for the auctioning of homogeneous goods within items catalogue-based e-procurement (int01). It must not focus on a particular industry but be usable in any business requirement (int01). N05 Provide facilities to The system needs to provide facilities to Possible auction heterogeneous auction heterogeneous goods. This involves future items. making multi-attribute bids for heterogeneous development. goods comparable (please see above 2.2.4 Current Issues in E-Reverse Auctioning). N06 Provide classification The description of the goods must be Essential. system standardized using an appropriate classification system. This is one major requirement to auction homogeneous goods as it ensures the comparability of different products (int01). Only when all attributes describing the product are the same, a reverse auction can be conducted to cut down the price. N07 Provide algorithms for The process flow and evaluation rules for Essential. English reverse reverse English auctions must be implemented. auctions This determines the auction method and all relevant parameters. N08 Provide algorithms for Algorithms for conducting other reverse Possible other reverse auctions auctions such as reverse Dutch auctions, future than the English one reverse Japanese auctions etc. may be development. implemented in future. The corresponding process flows and auction rules must be included.
Figure 15: The Non-Functional Requirements
3.6 Resulting Business System Options (BSOs)
As a result of the requirements catalogue, there are eight different Business System Options available that fulfil all requirements marked as essential. However, they may vary in meeting desirable requirements or requirements that may be included in future developments. One combination, BSO1, will only include the essential requirements (please see Figure 16 below). Some combinations, such as BSO2 or
75 BSO3, BSO4, and BSO5 may include the requirement of approving an auction but not all other desirable requirements (please see Figure 16 below). Others, for instance BSO3, BSO5, BSO6, and BSO7 may include algorithms for auctioning heterogeneous goods (please see Figure 16). BSO4, BSO5, BSO7, and BSO8 contain algorithms to conduct auctions other than English reverse auctions (please see Figure 16). All possible combinations are listed again in Figure 16 below with the corresponding requirements:
Req.-ID Req.-Name BSO1 BSO2 BSO3 BSO4 BSO5 BSO6 BSO7 BSO8 F01 Register suppliers X X X X X X X X F02 Confirm registration X X X X X X X X F03 Approve auction X X X X F04 Start auction X X X X X X X X F05 Invite suppliers X X X X X X X X F06 Submit bids X X X X X X X X F07 Evaluate bids X X X X X X X X F08 Give feedback X X X X X X X X F09 Reformulate bids X X X X X X X X F10 Close round X X X X X X X X F11 End auction X X X X X X X X N01 Store information about X X X X X X X X suppliers in database N02 Provide integration with X X X X X X X X existing systems and applications N03 Provide web-based X X X X X X X X access N04 Provide facilities to X X X X X X X X auction homogeneous items N05 Provide facilities to X X X X auction heterogeneous items. N06 Provide classification X X X X X X X X system N07 Provide algorithms for X X X X X X X X English reverse auctions N08 Provide algorithms for X X X X other reverse auctions than the English one
Figure 16: The Business System Options (BSOs)
3.7 Implementation
As the e-reverse auction tool will be developed as a module of the Hybris Jakarta Platform (int02), it is necessary to first investigate the constraints of this software platform in order to be able to deduce appropriate Technical System Options (TSOs) for the new system. However, the Hybris Jakarta Platform itself is based on the J2EE (Java 2 Platform Enterprise Edition). Therefore, this chapter will first
76 explain how the J2EE and the Hybris Jakarta Platform work (3.7.1 The Software Platform). Then, it will focus on how the e-reverse auction tool can actually be implemented in this platform, how it integrates other systems (3.7.2 Front- and Back-End Integration).
3.7.1 The Software Platform
Generally speaking, the J2EE (Java 2 Platform Enterprise Edition) is a set of coordinated specifications and practices that together enable solutions for developing, deploying, and managing multi-tier server-centric applications (Sun Microsystems, 2003a). The major benefit is the separation of business logic from resource and lifecycle management (Sun Microsystems, 2003a). That means that developers can focus on writing the particular business logic - their value add - rather than being concerned with writing the particular enterprise infrastructure (Sun Microsystems, 2003a). The basic J2EE architecture is illustrated in Figure 17 below:
Figure 17: The J2EE Architecture (Sun Microsystems, 2003b)
Like in the general architecture described above (2.3.2 Architecture for E-Reverse Auction Software), the J2EE consists of a number of different tiers or levels:
• The client-side presentation (i.e. browsers etc.) • The server-side presentation and business logic. • The enterprise information systems as relevant data sources.
77 The J2EE generally provides an easy and efficient way to achieve interaction with the enterprise information systems, i.e. the company’s databases, proprietary systems etc. and making content available to a number of clients. In order to simplify the development of the software solution, J2EE uses so called containers on both the web tier and the business tier (Sun Microsystems, 2003a).
The web containers (web server) host components that are relevant for the presentation of the particular content (JSP, Java Server Pages). The JSPs (JavaServer Pages) facilitate data exchanges with the client. They help to rapidly develop and easily maintain information-rich, dynamic web pages that leverage existing business systems (Sun Microsystems, 2003c).
On the other hand, EJB (Enterprise Java Bean) containers on the business tier host components representing the relevant business logic and enabling the access to the enterprise information system (Zhong, 2001). EJBs represent the relevant business objects of the particular company (int02). Instead of directly accessing an enterprise information system such as a database to get information about a particular business object, the platform will only need to access the relevant EJBs in the EJB container of the business tier. EJBs thus hide the underlying complexity of the data logic and facilitate the automated communication with the particular back- end system. As EJBs are readily implemented by J2EE technology vendors, they handle distributed communication, threading, scaling, transaction management, etc. more or less automatically and developers do not need to worry about it (Sun Microsystems, 2003a). Both EJB and JSP technology use XML-like tags that encapsulate the particular logic: in the case of EJBs the relevant business logic that is encapsulated, whereas in the case of JSP, the logic for generating the content for the web page is encapsulated.
The behaviour of the EJBs (such as performance, access authorization, persistency etc.) is controlled by separate XML files so-called deployment descriptors (int02). In order to customize the behaviour of the EJBs so that it fits in a particular business and technical environment, only the deployment descriptors need to be changed rather than changing the source code of the whole software platform (int02). An additional benefit of this structure is that it is fairly independent from the use of a particular application server (int02). At the same time, the scalability is
78 ideal: If the performance of the system is too low, clustering will improve the performance (int02). This means relevant components are simply added at all levels and connected in parallel until the desired performance rate is achieved (int02).
As mentioned above, the Hybris Jakarta Platform that will contain the e-reverse auction tool is based on the J2EE architecture. It consists of three different layers:
• The Jalo (Jakarta Logic). • The Jalo Implementation (Jakarta Logic Implementation). • The EJBs (Entity Java Beans).
Figure 18: The Hybris Jakarta Platform Layers (Latka, 2003)
Whereas the Jalo and the Jalo Implementation are considered to be part of the J2EE web tier, the EJBs are considered to be part of the J2EE business tier (int02). The Jalo (Jakarta Logic) contains the relevant logic to access EJBs. This logic represents the first layer within the Hybris Jakarta platform and allows to access java objects very easily (int02). It facilitates the communication between the Hybris Jakarta Platform and the web browser or client.
The JaloImplementation represents the actual implementation by using the Jalo (Jakarta Logic). It is the second layer of the Hybris Jakarta. The JaloImplementation maps the simple java objects of the Jalo to the more sophisticated EJB-objects of the EJB-layer. The wrapping is done automatically by the WrapperFactory and the JaloImplementationManager (int02). It is also possible to change the
79 implementation to map business objects in a programming language different than Java, for instance C++ (int02).
EJBs (Entity Java Beans) that may be relevant for e-reverse auctions include bids, products, price etc. (int02). As mentioned before, access to the relevant tables in the database will then be enabled automatically by addressing those EJBs.
The Hybris Jakarta Platform is generally available in three different editions:
• The Hybris Jakarta Standards Edition. • The Hybris Jakarta Professional Edition. • The Hybris Jakarta Developer Edition.
Only the Standards and Professional Edition can be used for ‘real’ software projects. The Developer Edition is primarily used by business partners who do not have a current software project but who want to investigate the platform. Even though the Standards Edition and the Professional Edition slightly vary in their features, they are both equally able to implement and support the e-reverse auction tool. The only difference that may impact the usability of the e-reverse auction tool is the fact that the Hybris Jakarta Standard Edition will only offer one language (Hybris, 2003c).
The Hybris Jakarta supports a number of different application servers (i.e. Orion, Oracle AS 9i, Bea Weblogic), databases (i.e. HSQL, MS SQL Server 2000, Oracle 8i, MySQL), and operating systems (Windows 2000, Windows NT, Suse 7.1 Linux, Red Hat Linux, HP UX, Solaris) (int02). Even though in theory, any combination of those application servers, databases, and operating systems may be implemented, only the following combinations have been tested for the Hybris Jakarta Platform (int02):
• Orion 1.5.x / OC4J 1.0.2.2.1 (Application Server), HSQLDB (Database), Win2000/NT/XP (Operating System for Application Server and Database).
80 • Orion 1.5.x / OC4J 1.0.2.2.1 (Application Server), MS SQL 2000 (Database), Win2000/NT/XP (Operating System for Application Server and Database). • Orion 1.5.x / OC4J 1.0.2.2.1 (Application Server), Oracle 8i (Database), Win2000/NT/XP (Operating System for Application Server and Database). • Orion 1.5.x / OC4J 1.0.2.2.1 (Application Server), My SQL 2000 (Database), Win2000/NT/XP (Operating System for Application Server), Linux Suse 7.1 (Operating System for Database). • Orion 1.5.x / OC4J 1.0.2.2.1 (Application Server), My SQL 2000 (Database), Linux Suse 7.1 (Operating System for Application Server and Database). • Orion 1.5.x / OC4J 1.0.2.2.1 (Application Server), HSQLDB (Database), Linux Suse 7.1 (Operating System for Application Server and Database).
However, there are generally no differences between any of these combinations (int02). The only existing differences between those combinations derive from the use of different operating systems (int02):
“Windows ist weit verbreitet, d.h. der Nutzer findet fast immer einen Ansprechpartner bei Problemen, jemanden der sich auskennt.” (int02) “Windows ist auch in vielerlei Hinsicht einfacher: Es ist leichter, den Webserver (IIS) zu konfigurieren und Systemeinstellungen zu ändern. Windows ist ein generell leichter verständliches User Interface für visuell orientierte Menschen.” (int02) [“Windows is very popular, meaning that when problems occur, the user will always find support, someone with relevant knowledge.” (int02) “In other respects too, windows is much simpler: It is easier, to configure the web server and to change systems parameters. The windows interface is generally easier to understand for visual oriented people.” (int02)]
On the other hand, Linux offers the following advantages:
81 “Linux ist am wenigsten anfaellig fuer Viren.” (int02) “Linux hat weniger Sicherheitsloecher.” (int02) “Linux ist das am meisten ausgereiftes Netzwerksystem: Es hat eine sehr hohe Stabilität. Bei Änderungen muss nicht neu gebootet werden, sondern sie können in Laufzeit eingespielt werden. Linux ist sehr leicht upzudaten. Linux hat eine wesentlich höhere Erfahrung Systeme in Echtzeit zu aktualisieren.” (int02) [“Linux is the least vulnerable to viruses.” (int02) “Linux has less security holes.” (int02) “Linux is the most sophisticated and mature network system: It is very stable. In case of modifications it doesn’t need to be rebooted. The modifications can be installed in run-time. Linux is easy to update. Linux is much more mature in updating systems in run-time.” (int02)]
3.7.2 Front- and Back-End Integration
As the e-reverse auction tool will be implemented as a so-called extension of the Hybris Jakarta Platform, the Hybris Jakarta will manage the communication with other systems and applications. As mentioned above in the literature review (2.3.3 The Internet as Tool for Integration), one way of achieving communication between different systems and applications is to rely on APIs (Application Programming Interfaces). APIs serve as middlemen between two different software applications by making requests between the two different systems (Korper and Ellis, 2000:99). This means that in order to be able to communicate with the existing systems and applications, the e-reverse auction tool needs to be added as a new extension to the Jalo API (i.e. application programming interface of the Jalo) (int02). For further information about API please read again section 2.3.3.2 Back-End Integration via Internet.
The Hybris Jakarta Platform contains a number of subfolders with relevant components such as Jalo, Jalo Implementation, EJBs etc. In one of these folders (i.e. ext folder) all extensions made to the Hybris Jakarta Platform are saved. It is in this folder where the e-reverse auction tool will be created. The creation of the e- reverse auction tool will comprise the following steps: A folder named ‘reverse auction’ will be created within the ext folder (int02). Among others, it will contain a
82 src folder, a resources folder, the extensioninfo.xml file, a build.xml file as illustrated below in Figure 19:
Figure 19: The E-Reverse Auction Extension Folder in the Hybris Jakarta
The src folder will consist of all java source codes for Jalo, JaloImplementation, and EJBs. Creating the relevant java code will be the first step in the development of the e-reverse auction tool (int02). The resources folder will contain the relevant deployment descriptors that control the behaviour of the EJBs (int02). So-called vendor specific deployment descriptors will automatically manage the behaviour of the EJBs depending on the particular application server (int02). The extensioninfo.xml file contains the particular version number of the extension and information about other extensions that needs to be referred to (int02). This file is responsible for the integration of the e-reverse auction extension in the Hybris Jakarta platform (int02). The build.xml file then initiates the automatic building of the relevant components, i.e. compilation and wrapping (int02). To do so, the extension ant from ant.apache.org is used (int02). The compiled and wrapped components are then saved in the bin folder. The bin folder contains the finished e- reverse auction module as jar-file in two variations (int02): the first one is the server
83 version to communicate with the server, the second one is the client version to ensure communication with the client. In addition, the folder contains a SQL script that enables access to the relevant tables in the database (int02).
Besides creating the source files and the functionality of the e-reverse auction tool, there are other problems to be tackled. For instance in order to successfully exchange data between the buyer and the suppliers, it is important to achieve standardization between the two different systems in terms of the information to be exchanged (int02). To resolve that problem, the Hybris Jakarta implements a generic classification approach, i.e. it allows to access many different types of classification systems such as eClass, UNSBSC etc. (int01). The particular classification systems then contain the particular contents (int01). This generic classification approach allows for more flexibility when integrating buyers and suppliers (int02).
As for the actual data exchange between different systems, it is important to differentiate two different kinds of data exchange: real-time data exchange and non- real time data exchange (int02). In the case of non-real time data exchange, data may be transferred periodically via ftp-server. However, in the case of e-reverse auctions, real-time data exchange is required in order to receive the relevant information on time. Therefore, data exchange can only take place via BMEcat. BMEcat is an XML based standard for exchanging product catalogues. BMEcat needs to be implemented both on the suppliers’ and the buyer’s system (int02). The information is then exchanged as XML request between the two systems (int02). A corresponding XML response signals whether the request for data has arrived or not (int02).
“Wenn Echtzeitbedarf besteht werden die einzelnen Informationen als XML Request zwischen den beiden Systemen ausgetauscht. Eine korrespondierende XML Response gibt Auskunft ob die Request eingegangen ist.” [“If real-time data exchange is required, data will be exchanged between the systems as XML request. The corresponding XML response indicates whether the request has arrived.” (int02)]
84 Besides via BMEcat, the buyer-supplier catalogue integration and data exchanges can also be achieved using WebMC (Hybris Jakarta Web Mangement Console). WebMC is a web-based administration interface. Suppliers rely on it to provide their product information to the buyers. Using WebMC, catalogue data simply can be changed via web-browser access. This allows for great flexibility in integrating multiple suppliers or other parties which may be particularly interesting for marketplaces. The WebMC implements authentification processes that ensure that suppliers can only access and change their own product data.
The time required to actually develop and implement the e-reverse auction tool would take approximately two and a half weeks: It takes about two weeks to program the e-reverse auction extension and create all relevant documentation (int02). Within only fifteen minutes, the extension can be integrated into the Hybris Jakarta Platform (int02). It would take another one or two days to implement the system at the customer (int02). However, the real development process usually takes a lot longer:
“Der größte Zeitverlust entsteht, wenn man herausfinden will, wie die Spezifikation genau aussehen soll.” (int02) [“The greatest loss of time is generated when trying to find out about the requirements of the specification.” (int02)]
3.8 The Resulting Technical System Options (TSOs)
Depending on the size of the project, there are different Technical System Options (TSOs) available for the Hybris Jakarta Platform and the e-reverse auctioning tool. All Technical System Options proposed will be able to support the Business System Options developed above. The differences regarding server, databases or software will be described below.
A small system configuration would usually comprise one application server and one database server. Two possible software combinations (TSO1 and TSO2) are listed below:
85 E-Commerce System: hybris jakarta, single CPU license
Application Server (AS): Orion 1.5
Operating System (AS): SuSE Linux 7.2
Database (DB): MySQL
Operating System (DB): Suse Linux 7.1
Figure 20: TSO1as proposed by Hybris (Hybris, 2001)
E-Commerce System: hybris jakarta, single CPU license
Application Server (AS): Oracle9i AS
Operating System (AS): Windows 2000
Database (DB): Oracle 9i
Operating System (DB): Windows 2000
Figure 21: TSO2 as proposed by Hybris (Hybris, 2001)
The small system configuration is able to handle up to 10.000 products, 5.000 customer datasets and 16.000 average requests per day (Hybris, 2001). For further details about the sizing please see Appendix 4. The price for the small system configuration including the appropriate third party software will be at least 15.000 £ (TSO1) including BMEcat and only first CPU but excluding VAT (Hybris, 2003c).
A medium-sized system configuration typically consists of two application servers and one database server. It would be able to handle up to 100.00 products, 25.000 customer datasets, and 85.000 average requests per day (Hybris, 2001). For further details about the sizing please see Appendix 4. The recommended software may be one of the following recommended options (TSO3 or TSO4):
E-Commerce System: hybris jakarta, 2x CPU license
Application Server (AS): Orion 1.5
Operating System (AS): Windows 2000
Database (DB): Microsoft SQL Server 2000
Operating System (DB): Windows 2000
Figure 22: TSO3 as proposed by Hybris (Hybris, 2001)
86 Application Server (AS): BEA WebLogic 6.x
Operating System (AS): Windows 2000
Database (DB): Oracle 9i Database
Operating System (DB): Windows 2000
Figure 23: TSO4 as proposed by Hybris (Hybris, 2001)
Large system configurations are able to handle up to 250.000 products, 50.000 customer data sets and 427.000 average requests per day (Hybris, 2001). For further details about the sizing please see Appendix 4. They usually require two web servers, two application servers, and two database servers (Hybris, 2001). The following software combinations are suggested by Hybris:
E-Commerce System: hybris jakarta, 2x CPU license
Application Server (AS): Oracle9i Application Server
Operating System (AS): Sun Solaris 8
Database (DB): Oracle 9i
Operating System (DB): Sun Solaris 8
Figure 24: TSO5 as proposed by Hybris (Hybris, 2001)
Application Server (AS): BEA WebLogic 6.x
Operating System (AS): Windows 2000
Database (DB): Oracle
Operating System (DB): Windows 2000
Figure 25: TSO 6 as proposed by Hybris (Hybris, 2001)
An extremely performant system configuration would require three web servers, three application servers, and two database servers. The system would be able to handle up to 500.000 products, 125.000 customer or supplier datasets, and 2.562.500 requests on average per day (Hybris, 2001). For further details please see Appendix 4. The following software (TSO 7 and TSO8) is suggested by Hybris to meet the requirements of extremely large projects:
87 E-Commerce System: hybris jakarta Standard v1.04
Application Server (AS): Oracle9i Application Server
Operating System (AS): HP Server, HP-UX 11i
Database (DB): Oracle 9i
Operating System (DB): HP Server, HP-UX 11i
Figure 26: TSO7 as proposed by Hybris (Hybris, 2001)
Application Server (AS): BEA WebLogic 6.x
Operating System (AS): Sun Solaris 8
Database (DB): Oracle 9i
Operating System (DB): Sun Solaris 8
Figure 27: TSO8 as proposed by Hybris (Hybris, 2001)
Depending on the size of the project, the introduction of an e-reverse auction tool based on the Hybris Jakarta Platform may cost between 80.000 and 250.000 Euro (int01)12. This price includes everything (i.e. any customizing, implementation etc.) except for the actual operating of the system (int01). The actual licence fee is only about 1/3 of this price (int01). The remaining costs are for customizing, consulting, integration, third party software etc. (int01).
12 This is approximately 52.500 and 164.000 £.
88 4 Discussion
After having presented the findings of the study in the previous chapter (3 Results and Findings), this chapter will discuss the most significant results. Given the research question of how to design an e-reverse auction solution that is appropriate for corporate purchasing, the major results of the case study comprise the Business System Options and Technical System Options derived from both the interviews and the SSM application. However, regarding the BSOs and TSOs obtained in this study, one could argue that they have not been developed accurately as only solutions of a single software designer – i.e. Hybris – are considered. Therefore, the following section will first illustrate the issue of the development of the Business and Technical System Options in this dissertation (4.1 The Development of BSOs and TSOs), before discussing the different BSOs and TSOs (4.2 Business System Options (BSOs), 4.3 Technical System Options (TSOs)). The main discussion points will be summarized in the fourth section (4.4 Summary).
4.1 The Development of BSOs and TSOs
BSOs and TSOs are usually developed when a company is looking for possibilities to improve or upgrade their current information system. The company will ask an IT analyst to examine the current system and suggest appropriate Business and Technical System Options for the new system. In this dissertation, however, there is no particular company analysing their system and trying to find possible solutions for e-reverse auctioning. On the contrary, it is the developer of an e-reverse auction tool who needs consultancy for the development of his solution. This difference in situation naturally impacts the development of the Business and Technical System Options.
According to Weaver (2002:156), BSOs will normally vary with different types and sizes of the particular projects. Different kinds of BSO include packages, bespoke software, current systems with modifications etc. (Weaver, 2002:159). In this dissertation, the software developer Hybris has clearly defined the essential requirements for the new system. These requirements also include three requirements for possible future development that, however, should explicitly not be included in the current solution. Thus, the only BSOs that could be developed
89 are the ones for the current Hybris e-reverse auction tool (i.e. BSO1 and BSO2) and the ones for possible future developments of the Hybris system (3.6 The Resulting Business System Options (BSOs)). It is impossible to consider BSOs available from other vendors such as different software packages or similar, because Hybris relies on the Hybris Jakarta Platform when designing the e-reverse auction software.
Weaver (2002:161) also suggests analysing and comparing the costs, development timescale, interface etc. for the different BSOs in order to find the most appropriate solution. But the findings obtained in the case study do not indicate that there would be a difference in development time, interface etc. between the different BSOs as they will all be developed by the same company, using the same development process and relying on the same platform. The only difference in development time is admittedly how quickly a customer can decide on the specification he/she wants to have (see above 3.7.2 Front- and Back-End Integration). But again, customizing is not part of the service provided by Hybris (3.2 The Problem Situation Expressed: Rich Picture), let alone that there is no pilot project where the estimation could be based on. Consequently, the scope of the Business System Options in this dissertation is much more limited than the scope of ‘normal’ BSOs.
As for the TSOs - they normally should include the technical system architecture, an outline development plan, and a cost-benefit analysis (Weaver, 2002:342). The Technical System Options in this dissertation only derive from the different configurations of the Hybris system. Again, no other platform can be suggested than Hybris Jakarta and J2EE, because Hybris will not offer anything else. And as before, not much can be said about the actual costs and the development plan due to the lack of a pilot project.
In sum, when consulting a software designer about how to develop a software solution, the BSOs and TSOs will need to be adjusted as follows: First, they usually need to be bound to the developer’s system offered. Second, they may not necessarily relate to a particular software project. This means that possible benefits, disadvantages, problems etc. of the particular options may only be identified by referring to people’s general experience in this field and by reviewing the literature.
90 In the following sections (4.2 Business System Options (BSOs) and 4.3 Technical System Options (TSOs)), both the tailored Business and Technical System Options obtained from the case study will be critically discussed in the following sections by referring to the evidence given in the literature review.
4.2 Business System Options (BSOs)
As mentioned above (3.6 The Resulting Business System Options (BSOs)), the major differences between the suggested Business System Options can be seen in their meeting different optional requirements in addition to satisfying the essential requirements. Some BSOs may only satisfy one optional requirement, others more (please see Figure 16 in 3.6 The Resulting Business System Options (BSOs)). Due to the lack of a pilot project, the implications of the existence or absence of the optional requirements will be discussed below by referring to the evidence obtained from the literature review (see above, 4.1 The Development of BSOs and TSOs).
4.2.1 The Basic Version
The basic version of the e-reverse auction tool (BSO1, please see Figure 16 in 3.6 The Resulting Business System Options (BSOs)) meets all essential functional and non-functional requirements derived from both the interviews and the SSM analysis13. By supporting these processes the basic version represents a valid tool to efficiently support the purchasing function within a company (2.1 Purchasing): With the functionality provided, it generally enables a buyer to buy goods and services of the right quality, in the right quantity, at the right time, from the right supplier, and at the right price (Bailey and Farmer, 1990:69). Particularly the possibility to buy goods at the right price is enhanced by the use of this tool (Barling, 2001). As the tool is based on ICT and Internet technology, it provides the corresponding benefits outlined above (2.1.3 ICT in Purchasing; 2.2.3 ICT in Auctioning) for both buyers and suppliers. These include reduced transaction costs,
13 I.e. supplier registration, registration confirmation, start of auction, invitation of suppliers, bid submission, bid evaluation, feedback, closing of round, ending the auction, storing supplier information in a database, integrating the existing systems and suppliers, facilities to auction homogeneous goods, implementing a classification system, implementation of an English reverse auction algorithm.
91 reduced cycle times, better control of the purchase process and increased transparency.
Regarding the different dimensions of purchasing (2.1.2 The Different Dimensions of Purchasing), it is generally possible to use the basic version of the e-reverse auction tool for both strategic and spot purchases. However, when using the e- reverse auction tool in strategic purchasing, the buyer will need to carefully deliberate about the potential price reductions and the possible impact on long-term buyer supplier relationships that may be threatened. Developing a decision model for those situations would be a task for further studies and cannot be discussed here.
Yet, the basic version of the e-reverse auction solution appears to have some shortcomings that become clear when considering the organisation of electronic purchasing (2.1.4 Organisation of Electronic Purchasing) and the different auction formats available for e-reverse auctions (2.2.2 Reverse Auctions). The lack of an approval process may cause problems when using the tool for private B2B exchanges. In addition, the fact that the basic version only supports English reverse auctions and the auctioning of homogeneous goods clearly limits its application area. Therefore, the following sections (4.2.2 Approval of E-Reverse Auctions, 4.2.3 Facilities to Auction Heterogeneous Goods, 4.2.4 Algorithms for Other Reverse Auction Types) will investigate the impact of these additional functionalities.
4.2.2 Approval of E-Reverse Auctions
As stated in the interview, including an approval workflow in the e-reverse auction process may depend on the prevailing circumstances within the company that is using the e-reverse auction software (3.3.3 The Transformation: What?). Even though there would usually be some approval before conducting the e-reverse auction, it is not necessarily relevant to all e-reverse auction settings (see above 3.2 The Problem Situation expressed: Rich Picture). Thus, it remains arguable, whether this process needs to be included in the software as essential or not. Bearing in mind that the e-reverse auction software could as well be used by a service provider who offers the system as a marketplace, the tool would not necessarily need to include the approval process. The approval would need to be given to the buyers and
92 suppliers outside the marketplace both relevant authorities within their companies. This means that the Business Systems Options that do not offer an approval feature (i.e. BSO1, BSO6, BSO7, BSO8, please see above Figure 16 in 3.6 The Resulting Business System Options (BSOs)) could best be used in marketplace situations.
Another possible application area for BSOs that do not include any approval process is to have them as additional module within a company’s existing e- procurement system. E-procurement systems usually support catalogue-based purchases including processes like search functions, catalogue management, approval workflows, orders and requests (2.1.1 Definitions: Purchasing and E- Procurement). By appropriately integrating the e-reverse auction software within the existing e-procurement system, the approval could be given by that system as response to a request to conduct an auction about certain goods. Considering the fact that the Hybris Jakarta platform is able to support the procurement processes just mentioned, the e-reverse auction solution would be especially attractive for existing Hybris customers who already rely on the Hybris Jakarta. In this case, the e-reverse auction tool would not need to include an approval process.
4.2.3 Facilities to Auction Heterogeneous Goods
As stated above, the basic version of the e-reverse auction tool would not include facilities to auction heterogeneous goods (4.2.1 The Basic Version). By only providing auction facilities for auctioning homogeneous goods, the software barely supports the complex decision process of determining the product specification. Either the goods have been homogenized in advance when selecting them from a catalogue or they have been homogenized via request for proposal procedures (3.1 Domain Description). In both cases, the buyer would already know the major attributes of the product he/she wants to buy and these major attributes would not differ.
In order to choose between different product specifications that vary in different important attributes, an algorithm for heterogeneous auctions would need to be included. The major issue here is to achieve the comparability of multi-attribute bids by implementing co-called ‘pricing out’ or other decision analysis techniques (2.2.4 Current Issues in E-Reverse Auctioning). The requirement of being able to
93 deal with heterogeneous goods becomes more and more important with the increasing complexity of the goods to be auctioned. This means that if the e-reverse auction tool is used to auction more complex and more expensive goods, it would be advantageous to provide the facilities to auction heterogeneous goods in order to enable an appropriate bid selection. BSO3, BSO5, BSO6, and BSO7 would then be more suitable than other Business System Options (please see Figure 16 in 3.6 The Resulting Business System Options (BSOs)).
However, the ability of the software to auction more complex goods may also have impacts on the people involved in the auctioning process. As a result from the interviews, the e-reverse auction tool initially should not focus on a particular industry; it should only be used within catalogue-based e-procurement of homogeneous items (3.5.2 Non-Functional Requirements). Thus, only the purchase department will act the role as buyer (3.2 The Problem Situation Expressed: Rich Picture). However, if production related or more complex B- and A-goods are auctioned, it may be necessary to form cross-functional teams to support the decision making process by providing relevant knowledge (2.1.2 The Different Dimensions of Purchasing). Thus, people other than employees of the purchase department may be involved in the selection process during an e-reverse auction to ensure that the right decision is made. Including these people might be particularly important when weighing and comparing the attributes of different heterogeneous bids submitted in an e-reverse auction.
The ability to auction more complex heterogeneous goods may also be of relevance in the case of marketplaces. As the main advantages of marketplaces include their independence, their global reach and the high volume (2.1.4 Organisation of Electronic Purchases), it seems favourable to provide facilities to auction many different types of goods in a marketplace. Being a service provider, marketplaces rely on the quality and variety of services they offer. The ability to auction heterogeneous goods may be particularly important for vertical exchanges as they only operate within one specific industry (2.1.4 Organisation of Electronic Purchases). Those marketplaces need to be able to handle and evaluate very specific, complex, heterogeneous bids. In the case of horizontal marketplaces, the ability of dealing with complex heterogeneous goods seems to be less important, as
94 these mainly focus on selling non-production related goods such as simple C-items that can easily be defined and homogenized before conducting the e-reverse auction.
4.2.4 Algorithms for Other Reverse Auction Types
Due to the special characteristics of marketplaces (2.1.4 Organisation of Electronic Purchases), it may also be favourable for them to offer more than one auction format in order to provide a broader range of facilities and services. Hence, marketplace service providers may also wish to include other reverse auction and auction formats in general (as described in 2.2.1 Auctions; 2.2.2 Reverse auctions). In such cases, the Business System Options including other reverse auction types (i.e. BSO4, BSO5, BSO7, BSO8, see Figure 16 in 3.6 The Resulting Business System Options (BSOs)) would be the best choice.
As for single companies using the e-reverse auction tool to conduct private exchanges, it depends on their specific needs whether they wish to have the possibility to conduct auctions other than English reverse auctions. This, however, can only be determined with regard to the particular company and therefore cannot be discussed here due to the reasons given above (4.1 The Development of BSOs and TSOs).
4.3 Technical System Options (TSOs)
As mentioned above (2.3.1 Basic Requirements for E-Reverse Auction Software), the technology used for e-reverse auction software must allow for maximum freedom and flexibility on the one hand as well as rely on a shared standard to facilitate affordable data exchanges on the other hand. The basic requirements for the corresponding architecture therefore comprise the use of standards, scalability, security, openness, manageability, and extensibility (CompTIA, 2003; VICS, 1998, Butler Group, 2001).
The Hybris Jakarta Platform that will contain the e-reverse auction tool is based on the widely-used J2EE standard. It implements XML, JSPs and Java that are all recognized standards. By relying on Internet technology, it is also able to greatly
95 reduce the transaction costs which is particular important for e-reverse auctions as mentioned before (2.2.3 ICT in Auctioning).
As for scalability, the different system configurations as proposed by Hybris allow for great variations regarding the sizing (3.8 The Resulting Technical System Options (TSOs)): Whereas small system configurations (TSO1, TSO2, please see Figures 20 and 21) are able to handle up to 10.000 products and 5.000 customer data sets, the extremely performant configuration (TSO7, TSO 8, see Figure 26 and 27) is able to handle 500.000 products and 125.000 customer data sets (Hybris, 2001). The scalability is mainly enabled by the use of deployment descriptors that facilitate the clustering (3.7.1 The Software Platform).
Security of the e-reverse auction tool is generally ensured: The software does not only include a registration process but it can also be used as virtual private network (VPN) as suggested above (2.3.1 Basic Requirements for E-Reverse Auction Software). Yet, differences in security may derive from the use of different operating systems as pointed out by interviewee int02 (for a comparison between Windows and Linux please re-read 3.7.1 The Software Platform).
Moreover, additional security mechanisms such as encryption etc. can easily be added due to the openness and extensibility of the system. As described above, extensions to the Hybris Jakarta Platform can simply be implemented by adjusting the relevant deployment descriptors in the Jalo API (3.7.1 The Software Platform). Again, the use of APIs represents a very common technique of integrating different applications (2.3.3.2 Back-End Integration via Internet). As for the ability to integrate different systems, the use of the generic classification approach provides the basis for integrating a variety of classification systems. In addition, the use of BMEcat enables data exchanges and sharing between buyers and suppliers who wish to integrate their systems. By granting web-based access via the WebMC, the system also can easily be used by anybody simply via web-browser which allows for great flexibility for the users. The possibility of web-based access is particularly important in the case of marketplaces with frequently changing participants. Finally, the Hybris Jakarta makes it possible to change the implementation to map business objects in programming languages other than Java (3.7.1 The Software
96 Platform) which allows for more freedom in the development of the particular EJBs.
The manageability of the system is ensured by the use of the J2EE. As mentioned above (3.7.1 The Software Platform), the separation of the business logic from resource management by using EJBs and JSPs technology allows for an easy development process as the developer can focus on the development of the business logic. This structure also reduces the development time of the software solution: As illustrated in the findings of the case study (3.7.2 Front-and Back-End Integration), the actual development and implementation time of the e-reverse auction tool may only take up to three weeks. Most of the time will be spend in discussing the particular specification with the customer, resulting in an overall development and implementation time of up to 6 months (3.7.2 Front- and Back-End Integration).
However, the Technical System Options for Hybris’ e-reverse auction software may differ in terms of price, sizing, and the use of different Hybris Jakarta editions (3.8 Resulting Technical System Options (TSOs)). The implications of these variances will be discussed below in further detail.
As for the use of different Hybris Jakarta editions, the Hybris Jakarta Standard Edition includes product descriptions in only one language (Hybris, 2003c). This may be problematic when offering the system as a marketplace. As mentioned above, one major goal of marketplaces is their global reach (Anderson and Frohlich, 2001). In such cases, the use of the Hybris Jakarta Professional Edition may be more appropriate as not to limit the facilities of the marketplace.
Regarding the sizing, it mainly depends on the requirements of the particular software project which configuration may be the appropriate one. As mentioned by int01 the question whether to buy the software or not can only be determined by a thorough activity-based costing. Only if the potential reduction of costs enabled by the software outweighs its costs, companies will buy the particular software. Yet, regarding the different hardware and software components suggested in the TSOs, it becomes clear that some TSOs offer the same sizing capacities but greatly vary in terms of their price: Even though the small system configurations (TSO1 and TSO2, see Figures 20 and 21 in 3.8 The Resulting Technical System Options (TSOs)) do
97 not differ in terms of their sizing, there is a price difference of nearly 10.000£ between the two options (Hybris, 2003c). The use of the Oracle Application Server and the Oracle Database in TSO2 make this option 2/3 more expensive than TSO1. Whereas TSO1 would be available for approximately 15.000£, TSO2 would cost approximately 28.400£ (Hybris, 2003c). The same pattern can be noticed regarding the other configurations. Consequently, small companies or larger companies with a limited budget are likely to prefer the cheaper versions of the configurations that satisfy their sizing needs.
In terms of potential customer for the Hybris e-reverse auction solution, the following tendencies may be assumed: If the e-reverse auction software is used for private B2B purchasing, it is likely that the size of the company determines the size of the configuration. That is because small companies tend to have a smaller number of customers and suppliers than large companies. Consequently, their information system software requires less capacity in terms of sizing. This means, that small companies may generally prefer the smaller systems configurations (such as TSO1, Figure 20 in 3.8 The Resulting Technical System Options (TSOs)), whereas large companies may prefer larger system configurations (e.g. TSO3, TSO4, TSO5 etc.) (for details please see 3.8 The Resulting Technical System Options (TSOs)). The situation is different if the software is used as a marketplace. The particular service provider may be a small company with limited budget. Yet, he would need to rely on larger systems configurations in order to provide appropriate capacities for a global marketplace. In such cases, the system configurations that offer a maximum sizing at minimum costs would be more appropriate.
Yet, these conclusions only mirror general tendencies and considerations. In any case, the particular TSO chosen by a particular company needs to suit the company’s existing IT infrastructure, required sizing, and the budget. These factors, however, can vary from project to project. Due to the reasons given above (4.1. The Development of BSOs and TSOs), they cannot be discussed in this dissertation. But after all, one general conclusion concerning the different Technical System Options as proposed by Hybris may be drawn: Regarding the high costs for licenses and technology infrastructure (3.8 The Resulting Technical System Options (TSOs)), it
98 may not seem to be justified at all to buy the rather expensive Hybris e-reverse auction software just to be able to conduct e-reverse auctions. It appears to be very unlikely that the software’s ability to reduce costs may outweigh its high costs that derive from both hardware and software. Being a module within the Hybris Jakarta Platform therefore appears to be the major drawback of all Technical System Options suggested here as it increases the software’s price immensely. The buyer needs to buy so much software and hardware in addition to the e-reverse auction module only to be able to conduct e-reverse auctions. Therefore, investing in any of the Technical System Options suggested above only seems sensible when aiming to automate other processes within purchasing as well such as ordering, supplier management, catalogue management etc. based on the Hybris Jakarta.
4.4 Summary
The discussion of the results carried out above has illustrated some important points to be taken into account regarding the BSOs and TSOs developed in this study.
First of all, it is important to understand that the BSOs and TSOs suggested in this research differ from common BSOs and TSOs. This is due to the difference in situation: Whereas common Business and Technical System Options are usually developed within real IT projects and refer to existing solutions, the BSOs and TSOs developed here are only the first outline for a possible software solution. They are developed as to consult a software developer on the possible proceeding of the development of his software. Consequently, the TSOs are much more focussed on the constraints within the software developer’s company, but at the same time, the BSOs are much more general concerning their scope than common BSOs as they cannot be related to a particular IT project.
Second, there is a basic version of the e-reverse auction tool (BSO1, please see above Figure 16 in 3.6 The Resulting Business System Options) that supports the essential processes within e-reverse auctioning, i.e. supplier registration, confirmation of the registration, auction start, invitation of suppliers, submission and evaluation of bids, feedback on bids, reformulation of bids, and the closure of rounds and auctions. Yet, sometimes it may be advantageous to include other features. For instance the approval of e-reverse auctions may be relevant for private
99 B2B exchanges, but not crucial for marketplace settings. The facilities to auction heterogeneous goods may be important with the increasing complexity of goods. This feature may be particularly interesting for e-reverse auctions that only focus on a particular industry (e.g. vertical marketplaces). Algorithms for other reverse auction types are generally more important for marketplace situations.
Third, the discussion of the TSOs has shown that all Technical System Options suggested by Hybris meet the basic requirements for e-reverse auction software as mentioned above (3.2.1 Basic Requirements for E-Reverse Auction Software), i.e. standardization, scalability, security, openness, extensibility, and manageability. The sizing capacities, however, must always suit to the particular software project. The same is true for the price: small companies are very unlikely to afford system configurations that include expensive 3rd party software even though the sizing may be appropriate. Furthermore, it appears unlikely that only the facility to conduct e- reverse auctions can outweigh the costs of the software solution as it is based on a very potent software platform, i.e. the Hybris Jakarta. To offset the costs of this platform, the customer would need to automate other business processes that are supported by the Hybris Jakarta as well. Hence, the Hybris e-reverse auction solution is particularly attractive for companies that already use the Hybris Jakarta or that want to automate more procurement processes than just reverse auctioning.
100 5 Conclusions and Future Work
As mentioned at the beginning (1.1 Background), e-reverse auctions represent another traditional business activity that benefits from the application of ICT and the Internet. This is not surprising as the application of technology allows for minimizing transaction costs, speeding up the reverse auction process, making the process more controllable and transparent, and generally reducing purchase costs (2.1.3 ICT in Purchasing, 2.2.3 ICT in Auctioning). However, with the application of ICT, new problems have emerged as well. The major problem has been tackled in this dissertation: How to design an e-reverse auction tool that recognizes the complex constraints of purchasing? This chapter will first summarize and reconsider the major outcomes of the study undertaken (5.1 Summary and Conclusions) and then indicate possible areas for future research (5.2 Future Work).
5.1 Summary and Conclusions
As mentioned above (5 Conclusions and Future Work), this dissertation has addressed the problem of how to design an appropriate e-reverse auction solution for corporate purchasing. To answer that question, a case study has been carried out at a German software designer who faces this very problem. Besides the evidence obtained from reviewing the relevant literature in this area, the interviews conducted have brought about new evidence to this subject. The application of SSM has not only given a better insight into the problem area, but also delivered a definition of the problem area, the conceptual model of an e-reverse auction solution as well as the corresponding requirements, BSOs and TSOs. In sum, both the literature review and the conduction of interviews combined with the application of SSM have allowed for achieving the research objectives defined in the beginning (1.4 Research Questions and Objectives):
The investigation of both the complex constraints of purchasing (Objective 1) and e-reverse auctioning (Objective 2) has given some first hints to answer the research question: E-reverse auctions may be applied to several different scenarios within B2B purchasing such marketplace situations, private B2B exchanges, the auctioning of homogeneous goods and the auctioning of heterogeneous goods.
101 As can be seen from the identification of the processes and requirements of e- reverse auction software (Objective 3), each of these application areas has a major impact on the processes and the requirements of the e-reverse auction tools. Depending on the different purchasing situations, the processes and requirements of the e-reverse auction tool may vary. The discussion of the BSOs as proposed by Hybris confirms these considerations.
The investigation of the technical environment for e-reverse auction software (Objective 4) has then lead to the identification of technologies that may enable the implementation of the tool by satisfying all relevant requirements. The development of the tool as module of the J2EE platform and the Hybris Jakarta has been discussed in further detail as result of the case study. Generally speaking, the Hybris Jakarta provides a good basis for the development of the e-reverse auction tool because it meets the basic requirements of e-reverse auction software (2.3.1 Basic Requirements for E-Reverse Auction Software): it is based on recognized standards, it is scalable, secure, open extensible and manageable.
The development of the Business System Options (BSOs) and the Technical Systems Options (TSOs) of the e-reverse auction tool to be designed for Hybris has presented detailed options for the design of e-reverse auction software (Objective 5). Whereas the basic version of the e-reverse auction tool generally supports the essential e-reverse auction processes, different purchasing situations may require additional functionality. In addition, the BSOs and TSOs suggested by Hybris are very limited as they are only based on the requirements and technical environment provided by Hybris. The dependency on the Hybris Jakarta clearly limits the possible application area of the e-reverse auction software to Hybris customers and customers who want to automate other procurement processes supported by the Hybris Jakarta.
5.2 Future Work
Thus, answering the research question has not only brought answers. The research has also raised a number of new questions that could not be responded to immediately due to the tight time constraints of this dissertation. Further research therefore should focus on closing the remaining gaps:
102 First of all, it is important to conduct further case studies with both qualitative and quantitative elements to increase the external validity of this study. Doing this may refine and validate the conceptual model, the requirements, BSOs and TSOs obtained in this study. This also includes a further evaluation of the BSOs and TSOs proposed in this dissertation.
Second, the further investigation of the different application areas of e-reverse auctions is crucial in order to refine the requirements and relevant processes for e- reverse auction tools. For instance the impact of the use of e-reverse auction tools on strategic purchases of product related goods represents a possible issue to be investigated. Resolving this issue may be particularly important for companies using e-reverse auction software: Knowing in which situations to rely on e-reverse auctions and how to use these tools properly may even increase the efficiency and quality of purchasing. E-reverse auctions as tool within JIT purchasing may be another application area with different constraints, thus, worth investigating.
Third, all current issues of e-reverse auctioning such as the handling of multi- attribute bids, bundled bids, and volume discount-bids require further study. Research in these areas is but at the beginning. The current algorithms need to be improved and adjusted.
Fourth, when having studied and clarified the constraints of the different e-reverse auction scenarios, the resulting requirements and the BSOs and TSOs for the e- reverse auction tool(s), research needs to be done focussing on the logical and physical design of the solutions suggested as well as on their implementation. This will also include finding out how the e-reverse auction tool will actually be accepted in industry. Further case studies need to be undertaken in that area as well.
Finally, possible areas of future work may appear with the emergence of new technologies. The Technical System Options must continuously be evolved taking into account new technical developments.
The research suggested above may certainly contribute to increase the knowledge about e-reverse auctioning. It can be seen as one step in closing the current gap in the academic literature. However, this study and the ones suggested may also have
103 implications on the business world: The evidence obtained from this and similar studies may help to overcome the problems of current e-reverse auction tools. And even though the results of this dissertation are by far not detailed enough to solve the current problems, they at least clarify what to do to improve the current situation. Once more, the results point up the importance of thorough system’s analysis to ensure the satisfactory quality of software.
(30.284 Words)
104 References
Alaniz, S. (1999). E-Procurement: A guide to buy-side applications [Online]. Little Rock, Arkansas: Stephens Inc. http://www.b2business.net/intn991227ir.pdf. [Accessed 14 July 03].
Anderson, J. & Frohlich, M. (2001). “FreeMarkets and Online Auctions”. Business Strategy Review, 12 (2), 59-68.
Avison, D. & Fitzgerald, G. (2003). Information Systems Development: Methodologies, Techniques and Tools. London: McGraw Hill.
Axelsson, B. & Wynstra, F. (2002). Buying Business Services. Chichester: John Wiley & Sons, Ltd.
Bailey, P. & Famer D. (1990). Purchasing: Principles and Management. London: Pitman.
Barling, B. (2001). Creating Sustainable Value Through B2B Sourcing. Boston: AMR Research. (Research Report December 2001).
Barratt, M. & Rosdahl, K. (2002). “Exploring business-to-business marketsites”. European Journal of Purchasing and Supply Management 8 (2), 111-122.
Barnes, S. & Hunt, B. (2001). E-Commerce and V-Business: Business Models for Global Success. Oxford: Butterworth-Heinemann
Bichler, M. et al. (2002). Applications of flexible pricing in business-to-business electronic commerce. IBM Systems Journal 42 (2), 287-302.
Bichler, M. & Kalagnanam, J.R. (2002). Winner Determination in Multi-Attribute Auctions. New York: IBM Research Division, Thomas J. Watson Research Center (IBM Research Report 6 June 2002).
Bray, M. (2000). Application Programming Interface: Software Technology Review [Online]. Pittsburgh: Software Engineering Institute (SEI) at Carnegie Mellon
105 University. http://www.sei.cmu.edu/str/descriptions/api.html [Accessed 18 July 2003].
Butler Group (2001). Strategic Sourcing. Effective Alternatives for the Enterprise. Hull: Butler Direct Limited.
Butler, M. & Power, T. (1999). The e-business advantage. Hull: Butler Group.
Chaffey, D. (2002). E-Business and E-Commerce Management. Harlow: Financial Times/Prentice Hall.
Checkland, P. & Scholes, J. (1990). Soft Systems Methodology in Action. Chichester: Wiley.
Checkland, P. (1981): Systems Thinking, Systems practice. Chichester: Wiley.
Checkland, P. (1995). “Soft Systems Methodology and its relevance to the development of information systems.” In: Stowell, F. (ed.) (1995), Information Systems Provision. The contribution of Soft Systems Methodology, pp.1-17, London: Mc Graw-Hill.
Classen, M. (1999). XML, the better HTML? [Online]. Darien: Jupitermedia Corp. http://www.webreference.com/xml/column1/ [Accessed 18 July 2003].
CompTIA (2003). E-Business Technology Standards: EIDX/CompTIA Internet Commerce Model [Online]. Oakbrook Terrace: CompTIA. http://www.eidx.org/publications/techinfo/tech_icm.html [Accessed 20 June 2003].
Davenport, A.J. et al. (2001). Combinatorial and Quantity Discount Procurement Auctions with Mutual Benefits at Mars, Incorporated. New York: IBM T.J. Watson Research Centre.
Davies, L.J. & Ledington, P.W.J. (1991). Information in Action: Soft Systems Methodology. Basingstoke: Macmillan Education.
106 De Boer, L., Harink, J. & Heijboer, G. (2002). “A conceptual model for assessing the impact of electronic procurement”. European Journal of Purchasing and Supply Management, 8 (1), 25-33.
Diamond, J. & Pintel, G. (1989). Retail Buying. New Jersey: Prentice Hall.
Digital Union (2002) Enterprise spend management with ez market [Online]. London: Digital Union. http://212.250.164.1/website/areas.nsf/94da14ec9ceba30780256d02004cd2ff/$FILE /Spend%20Management%20White%20Paper.pdf [Accessed 4 June 2003].
Emiliani, M.L. (2000). “Business-to-business online auctions: key issues for purchasing process environment.” Supply Chain Management: An International Journal, 5 (4), 176-186.
Federal Reserve Bank of Chicago. (2003). Glossary [Online]. Chicago: Federal Reserve Bank of Chicago. http://www.chicagofed.org/glossary/index.cfm?alphaletter=R [Accessed 3 June 2003]
Fidel, R. (1992). “The Case Study Method: A Case Study”, in: Glazier, J.D. and Powell, R.R. (ed.) (1992). Qualitative Research in Information Management. 37-50.
Flick, U. (2002). An Introduction to Qualitative Research. London: Sage Publications Ltd.
Gadde, L.-E. & Hakansson, H. (2001). Supply Network Strategies. Chichester: John Wiley and Sons Ltd.
Glazier, J.D. (1992). “Qualitative Research Methodologies for Library and Information Science: An introduction”. In: Glazier, J.D. & Powell, R.R. (ed.), Qualitative Research in Information Management, pp. 1-13. Englewood: Libraries Unlimited.
Gorman, G.E. & Clayton, P. (1997). Qualitative Research for the Information Professional. A practical Handbook. London: Library Association Publishing.
107 Hybris (2001). Hybris Jakarta Developer’s Guide [Online]. Muenchen: Hybris Holding AG. http://www.hybris.de/extranet/docu/framehtml/frame.jsp [Accessed 11 May 2003]
Hybris (2003a). Hybris e-commerce software. About hybris [Online]. Muenchen: Hybris Holding AG. http://www.hybris.de/hybris/unternehmen/index_en.html [Accessed 28 February 2003]
Hybris (2003b). Hybris Jakarta 1.05 Feature Matrix – English [Online]. Muenchen: Hybris Holding AG. http://www.hybris.de/extranet/documents/hybris_jakarta_1_05_featurematrix_0302 26_en.pdf [Accessed 17 July 2003]
Hybris (2003c). Hybris Jakarta Price List [Online]. Muenchen: Hybris Holding AG. ftp://ftp.hybris.com/sales_documentation/hybris_jakarta_1_05_Pricelist_030306_E N_uk.pdf [Accessed 4 July 2003].
Hybris (2003d). Hybris Jakarta E-Procurement: Unternehmensuebergreifende Beschaffungsprozesse mit der Hybris Jakarta. Muenchen: Hybris Holding AG iWay (2003). Ebusiness (e-business) - a Definition and Guide to Solutions from iWay Software [Online]. New York: iWay. http://www.iwaysoftware.com/definition/ebusiness-e-business.html [Acccessed 10 June 2003].
Joppe, M. (2003). The Research Process [Online]. Toronto: Ryerson University. http://www.ryerson.ca/~mjoppe/rp.htm [Accessed 12 May 2003].
Kalagnanam, J. (2002). MAP – Intelligent Decision Support for Sourcing [Online]. Yorktown Heights, NY: IBM T.J. Watson Research Centre. http://www.research.ibm.com/auctions/pubs/IBMSourcingWP140802.pdf [Accessed 24 July 2003].
Kalakota, R. & Robinson, M. (1999). E-business : roadmap for success. Harlow: Addison-Wesley.
108 Kalakota, R. & Robinson, M. (2000). E-business 2.0: roadmap for success. Harlow: Addison-Wesley.
Kalakota, R. & Whinston, A.B. (1997). Electronic Commerce: a manager’s guide. London: Addison Wesley.
Kaplan, S. & Sawnhey, M. (2000). “E-Hubs: the new B2B marketplaces”. Harvard Business Review, 78 (3), 97-103.
Kemmeter, J., Mitchell, P. & Suleski, J. (2002). E-Sourcing: ROI Tastes Great, Applications Less Filling. Boston: AMR Research. (Research Report June 2002).
Knight, P.T. (2002). Small-Scale Research. Pragmatic Inquiry in Social Science and the Caring Professions. London: Sage Publications Ltd.
Korper, S. & Ellis, J. (2000). The E-Commerce Book: Building the E-Empire. London: Academic Press.
Latka, T. (2003). The Hybris Jakarta Architecture. Muenchen: Hybris Holding AG
Leenders, M. R. & Fearon, H. E. (1997). Purchasing and Supply Management. Chicago: Irwin.
Mason, J. (1996). Qualitative Researching. London: Sage Publications Ltd.
Merz, M. (1999). Electronic Commerce. Marktmodelle, Anwendungen und Technologien. Heidelberg: dpunkt-Verlag.
Mingers, J. (1995). “Using Soft Systems Methodology in the Design of Information Systems”. In: Stowell, F. (ed.) (1995). Information Systems Provision. The contribution of Soft Systems Methodology, pp. 18-50, London: Mc Graw-Hill.
NCSA HTTPd Development Team. (1998). Common Gateway Interface [Online]. Illinois: University of Illinois at Urbana – Champaign http://hoohoo.ncsa.uiuc.edu/cgi/intro.html [Accessed 18 July 2003].
109 Rayport, J.F. & Jaworski, B.J. (2001). E-Commerce. New York, London: McGraw Hill, Irwin.
Rouvas, G. (2002). Electronic Purchasing Unraveled: An Investigaton of the Emergence of the Internet as a Corporate Procurement Tool. MSc, University of Sheffield
Saunders, M. (1994). Strategic Purchasing & Supply Chain Management. London: Pitman Publishing.
Shor, M. (2003). English Auction [Online]. Nashville: Owen Graduate School of Management, Vanderbilt University. http://www.gametheory.net/Dictionary/Auctions/EnglishAuction.html [Accessed 21 August 2003]
Sun Microsystems (2002). Defining Reverse Auctions [Online]. Sun Microsystems: Santa Clara. http://docs.sun.com/source/816-5981- 10/auctions/auc_defrevsauc.htm#Reverse_English [Accessed 21 August 2003]
Sun Microsystems (2003a). Java 2 Platform, Enterprise Edition (J2EE) – Frequently Asked Questions [Online]. Sun Microsystems: Santa Clara. http://java.sun.com/j2ee/faq.html [Accessed 18 July 2003].
Sun Microsystems (2003b). Java 2 Platform, Enterprise Edition (J2EE) –Overview [Online]. Sun Microsystems: Santa Clara. http://java.sun.com/j2ee/overview.html [Accessed 18 July 2003].
Sun Microsystems (2003c). Java Server Pages [Online]. Santa Clara: Sun Microsystems. http://java.sun.com/products/jsp/ [Accessed 18 July 2003]
Teich, J., Wallenius, H. & Wallenius, J. (1999). „Multiple-issue auction and market algorithms for the World Wide Web“. Decision Support Systems, 26 (1), 49-66.
Turban, E., Lee, J., King, D. & Chung, H.M. (2000). Electronic Commerce: a managerial perspective. London: Prentice Hall.
110 van Weele, A.J. (2000). Purchasing and Supply Chain Management. Analysis, Planning and Practice. London: Thompson Learning.
VICS (Voluntary Interindustry Commerce Standard) Association (1998). Internet Commerce Model: Recommended Technologies for Internet Commerce [Online]. Lawrencville: Voluntary Interindustry Commerce Standard (VISC) Association. www.vics.org/pressrel11-98.doc [Accessed 14 June 2003].
Weaver, P.L. (2002). Practical Business Systems Development Using SSADM: A complete tutorial guide. Harlow: Financial Times Prentice Hall.
Wippermann, P. (ed.) (2001). Duden. Woerterbuch der New Economy. Mannheim: Bibliographisches Institut und F.A. Brockhaus AG.
World Wide Web Consortium (2003). Extensible Markup Language (XML) [Online]. Cambridge, Sophia Antipolis, Kanagawa:World Wide Web Consortium. http://www.w3.org/XML/ [Accessed 14 June 2003].
Yin, R. K. (1994). Case Study Research: Design and Methods. Thousand Oaks, California; London: Sage.
Yin, R.K. (2003). Case Study Research: Design and Methods. London: Sage Publications Ltd.
Zhong, J. (2001). Step into the J2EE architecture and process [Online]. Boston: IDG http://www.javaworld.com/javaworld/jw-09-2001/jw-0928-rup.html [Accessed 17 July 2003]
111 Glossary
A-items: items representing about 10% of the total items purchased in a company but only comprising a value of 70-80% of the total purchase expenses (Leenders and Fearon, 1997).
API (Application Programming Interface): interface that serves as a middleman between two different software applications (e.g. a word processor and a spreadsheet) by making requests between the two different systems (Korper and Ellis, 2000:99).
Back-end systems: a companies base systems that may include relational databases, transaction-based systems, ERP systems, EDI, third-party software, and proprietary systems (Korper and Ellis, 2000:98).
B-items: items representing 10-20% of the total items purchased and comprising a value of up to 10-15% of the total purchase expenses. (Leenders and Fearon, 1997).
BMEcat: an XML based standard for exchanging product catalogues.
BSO (Business System Option): possible business solution for a new system that meets all essential requirements.
Bundled bid: bid including multiple items. The quantity of each item is specified, however, there is only a single price for this bundled offer (Kalagnanam, 2002; Davenport et al., 2001).
Business-to-Business commerce (B2B): e-commerce between businesses
Business-to-Consumer commerce (B2C): e-commerce between business(es) and customers
CATWOE analysis: analysis technique used in SSM to define the clients, actors, transformation, world view, owners, and environment of a particular system.
112 C-items: items representing the major amount of total items purchased (70-80%), but only comprising a value of 10-20% of the total purchase costs (Leenders and Fearon, 1997).
CGI (Common Gateway Interface): a standard for enabling communication between external applications and web servers (NCSA HTTPd Development Team, 1998).
Clearing price: Feedback given for simple single item auctions at which supply for each item equals demand (Davenport et al., 2001).
Clustering: connecting appropriate devices and software in parallel to increase the capacities of a system.
Commerce server software: software implementing the functionality of the actual application (Korper and Ellis, 2000:95).
Conceptual model: model that shows how various activities are related to each other (Avison and Fitzgerald, 2003).
Connectivity tools: tools that connect back-end systems to server software or to front-end clients (Korper and Ellis, 2000:97).
Consumer-to-Business commerce (C2B): e-commerce between business(es) and customers
Consumer-to-Consumer commerce (C2C): e-commerce between and among customers.
Deployment descriptors: XML files used in the J2EE that manage and control the behaviour of the EJBs.
Direct purchase: purchase of production related goods.
Dutch auction: auction operating with a downward price mechanism. A good or service is initially placed at the highest bid. The bid is decreased until one bidder finally accepts (Korper and Ellis, 2000:215).
113 E-business: conducting business on the Internet, i.e. not only buying and selling, but also servicing customers and collaborating with business partners (iWay, 2003).
E-commerce: a particular facet of e-business focussing on the commercial interactions between the different parties involved.
EJB (Enterprise Java Bean): components on the business tier of the J2EE that represent the relevant business logic and enabling the access to the enterprise information system (Zhong, 2001).
Electronic public marketplaces: specific websites usually open to public that aim to bring buyers and sellers together in order to facilitate electronic purchases and more general e-commerce (De Boer et al., 2002; Teich et al., 1999).
E-MRO: electronic purchasing of goods and services ordered are maintenance, repair, and operating (MRO) suppliers, office supplies etc. (i.e. non-product related) (De Boer et al., 2002).
English auction: auction working with an upward price mechanism. Bidders need to beat the current, standing bid in order to win (Korper and Ellis, 2000).
E-procurement: electronic procurement. This may include e-sourcing, e-tendering, e-MRO, web-based ERP, e-reverse auctioning (De Boer et al., 2002).
E-purchasing: electronic purchasing.
E-reverse auction: electronic reverse auction.
E-sourcing: the process of identifying new suppliers for a specific category of purchasing requirements using Internet technology (Axelsson and Wynstra, 2002:125; DeBoer et al., 2002).
E-tendering: the process of sending RFIs (Request for Information) and RFPs (Requests for Proposals) to suppliers and receiving their responses using Internet technology (Axelsson and Wynstra, 2002:125; DeBoer et al., 2002).
114 Extranet: collection of company websites that can only be accessed by employees of a specified set of organisations such as business partners, customers etc. (De Boer et al., 2002).
Functional requirements: the requirements of a system regarding the actions or processes the system should carry out (Weaver, 2002:73).
Heterogeneous goods: goods that have attributes that can not be determined and compared unambiguously.
Homogeneous goods: goods that have attributes that can be determined and compared unambiguously.
Horizontal marketplace: marketplace that operates across different industries (Barratt and Rosendahl, 2002:115).
HTML (Hypertext Markup Language): presentation language for web documents.
HTTP (Hypertext Transfer Protocol): protocol on the Internet that allows web servers and web clients/browsers to communicate (Kalakota and Whinston, 1997:97).
Hybris: German software developer who was subject to the case study.
Hybris Jakarta: software platform for e-procurement applications developed by Hybris. The Hybris Jakarta is based on the J2EE standard.
Indirect purchase: purchase of non-production related goods.
Int01: CSO (Chief Security Officer) at Hybris
Int02: Training and Technical Support Manager at Hybris
Intranet: collection of company websites that is only accessible by employees within the particular organisation (De Boer et al., 2002).
Jalo: layer of the Hybris Jakarta that contains the relevant logic to access the EJBs.
115 JaloImplementation: the actual implementation of the business objects in the Hybris Jakarta using the Jalo (Jakarta Logic).
JIT (Just-in-time management): the principle of JIT means that all materials and products become available at the very moment when they are needed in the production process, not sooner and not later, but exactly on time and exactly the right quantity (van Weele, 2000:200).
JSP (Java Server Page): technology used e.g. in the J2EE to facilitate data exchanges with the web client.
J2EE (Java 2 Platform Enterprise Edition): a software platform developed by Sun Microsystems that enables solutions for developing, deploying, and managing multi-tier server-centric applications (Sun Microsystems, 2003a)
Maverick spending: unauthorised purchase.
Multi-attribute bid: bid including several different criteria besides price and quantity.
Multi-line bid: bid including several items
Non-functional requirements: requirements defining how or within what limits a functional requirement should be met (Weaver, 2002:74).
Open cry auction: auction that reveals information about the other bidders’ bids (Korper and Ellis, 2000:214).
Procurement: all activities required to get the product from the supplier to its final destination. This usually includes purchasing, traffic and transportation, inspections, quality control and assurance etc.
Purchasing: the act of buying appropriate goods and services. It is a major activity in companies (van Weele, 2000).
116 Reverse auction: auction with one buyer and many suppliers that aims to reduce the price of the goods auctioned. The participating suppliers need to underbid the offers of their competitors.
Reverse Dutch auction: auction with one buyer and many suppliers. The auctioneer raises the price from a low starting point until finally a bidder agrees to sell at that price (Federal Reserve Bank of Chicago, 2003).
Reverse English auction: auction with one buyer and many suppliers in which bidders offer decreasing prices to sell an item (Federal Reserve Bank of Chicago, 2003).
Reverse open cry auction: auction with one buyer and many suppliers who can see their competitors’ bids. The suppliers bid until finally the lowest bid wins (Federal Reserve Bank of Chicago, 2003).
Reverse sealed bid auction: auction with one buyer and many suppliers in which each seller makes a single (secret) bid and the lowest bid wins once all bids are received (Federal Reserve Bank of Chicago, 2003).
RFI (Request for Information): request sent out by the buyer to suppliers in the early phases of sourcing to explore the market for new, potential suppliers and gather information about them (Digital Union, 2003).
RFP (Request for Proposal): request sent out by the buyer to invite suppliers to propose new ways of solving problems and of reducing costs (Digital Union, 2003).
Rich picture: technique used in SSM to express the problem situation. It represents the important people, activities, relationships, and issues of the problem situation (Avison and Fitzgerald, 2003:162).
Rogue buying: unauthorised purchase. See also maverick spending.
Root definition: particular definition format used in SSM to define the system. The required elements are obtained from the CATWOE analysis.
117 Sealed bid auction: auction that reveals all information about the other bidders (Korper and Ellis, 2000:215).
Second-price auction: auction where the winning bidder only needs to outbid the next highest bidder by the minimum increment or decrement (Shor, 2003).
SSM (Soft Systems Methodology): methodology incorporating a soft systems thinking approach (Avison and Fitzgerald, 2003). It primarily focuses on gaining a complete understanding of the problem situation rather than on developing software solutions (Avison and Fitzgerald, 2003). SSM consists of a seven stage process including the unstructured problem situation, the problem situation expressed in a rich picture, root definitions of the relevant systems obtained from the CATWOE analysis, conceptual models, the comparison of the conceptual models with the problem situation expressed in the rich picture, the development of desirable and feasible changes, and the suggestion of actions to improve the problem situation (Checkland and Scholes, 1990; Checkland, 1995).
Supply curve bid: see bundled bid.
Tier: layer
TSO (Technical System Option): possible technical solution that is able to support and implement a particular BSO.
URL (Uniform Resource Locator): addresses used on the Internet to identify and allocate web servers and the data documents contained.
Vertical marketplace: a marketplace that only operates within one specific industry (Barrat and Rosendahl, 2002:114).
Volume discount bid: bid that includes multiple items. The supplier specifies the price he/she charges for an item as a function of quantity that is being purchased (Davenport et al., 2001). Thus, the bid may take the form of a supply curve (Kalagnanam, 2002).
118 Web-based ERP (enterprise resource planning): electronic purchasing of product related goods and services (Axelsson and Wynstra, 2002).
Web browser: see web client.
Web client: graphical user interface for accessing and displaying content on the Internet (Kalakota and Whinston, 1997:96).
WebMC (Web Mangement Console): a web-based administration interface implemented in the Hybris Jakarta that can be used by suppliers to provide their product information to the buyers.
Web server software: software that serves as a middleman between back-end systems and front-end web clients (Korper and Ellis, 2000:95).
XML (Extended Markup Language): a meta-language for defining and enabling data exchanges on the Internet. It can also be used to enable application-to- application interchanges. XML was introduced to overcome the shortcoming of HTML (VICS, 1998).
119 Appendix 1
Interview Scripts
Interview 1 (24th of June 2003) – Hybris CSO (int01)
Einkauf in Unternehmen und das Verhaeltnis zu Reverse Auctions
Frage 1: Bitte beschreibe im Detail das Thema ‘Einkauf in Unternehmen’ hinsichtlich der Kernelemente und auftretender Probleme und Streitfragen!
Frage 1.1: Was sind die Kernelemente des Einkaufsprozesses?
Frage 1.2: Welche Personen und/oder Abteilungen sind am Einkauf beteiligt?
Frage 1.3: Welche Informationen sollten dem Käufer zur Verfuegung stehen, wenn er ein Produkt kauft?
Frage 1.4: Kannst Du Kriterien definieren, von denen Du denkst dass sie wichtig sind, wenn man ein Produkt für eine Firma/Arbeitsplatz kauft?
Frage 1.5: Welche Informationen sollte der Käufer über den Lieferanten haben?
Frage 1.6: Woher kann der Käufer die Informationen über den Lieferanten bekommen?
120 Interview 1 (24th of June 2003) – Hybris CSO (int01)
Einkauf in Unternehmen und das Verhaeltnis zu Reverse Auctions
Frage 2: In welcher Beziehung stehen E-Reverse Auctions zum Einkauf in Unternehmen?
Frage 2.1: An welcher Stelle können E-Reverse Auctions im Einkaufsprozess eine Rolle spielen?
Frage 2.2 Welche Kriterien für die Lieferanten-Auswahl sollten in einem E-Reverse Auction Tool vorhanden sein?
121 Interview 2 (24th of June 2003) – Hybris CSO (int01)
Rich Picture – E-Reverse Auctions
Frage 1: Beschreibe bitte ausfuehrlich alle Beteiligten, die in irgendeiner Weise mit E-Reverse Auctions zu tun haben!
Frage 1.1: Wer sind die User der E-Reverse Auction Software?
Frage 1.2: Welche Parteien und/oder Personen tauschen Informationen ueber die Software aus?
Frage 1.3: Welche Parteien und/oder Personen haben Zugriff auf Informationen innerhalb des Systems?
Frage 1.4: Welche Parteien und/oder Personen haben in irgendeiner Form Einfluss auf das System?
Frage 1.5: Welche Parteien sind generell betroffen durch das System?
Frage 1.6: Wer kontrolliert dieses System?
Frage 1.7: Wem gehoert das System?
122 Interview 2 (24th of June 2003) – Hybris CSO (int01)
Rich Picture – E-Reverse Auctions
Frage 2: Charakterisiere bitte die Beziehungen, die zwischen den beteiligten Personen und/oder Parteien bestehen!
Frage 2.1: Welche Informationsfluesse laufen zwischen den verschiedenen Parteien und/oder Personen ab?
Frage 2.2: Welche Daten werden zwischen den Parteien und/oder Personen ausgetauscht?
Frage 2.3: Was sind die relevanten Datenquellen fuer die Informationen?
Frage 2.4: Welche Informationen stehen digital zur Verfuegung und koennen direkt an das System weitergegeben werden?
123 Interview 2 (24th of June 2003) – Hybris CSO (int01)
Rich Picture – E-Reverse Auctions
Frage 3: Beschreibe bitte die Anliegen und Hintergrundgedanken der beteiligten Personen und/oder Parteien!
Frage 3.1: Welche Bedenken koennten auf Seiten des Kaeufers bestehen, E-Reverse Auction Software zu nutzen?
Frage 3.2: Welche Bedenken koennten auf Seiten des Lieferanten bestehen, E- Reverse Auction Software zu nutzen?
Frage 3.3: Welche Bedenken koennte der Hauptverantwortliche bzw. Besitzer des Systems haben?
124 Interview 3 (25th of June 2003) – Hybris CSO (int01)
CATWOE Analysis – E-Reverse Auctions
Frage 1: Bitte beschreibe E-Reverse Auctions hinsichtlich der jeweiligen Profiteure, Verantwortlichen, Besitzer, herbeigefuehrten Veraenderung, Weltanschauung und dem Umfeld!
Frage 1.1: Wer profitiert von der Einfuehrung der neuen Software (Client)?
Frage 1.2: Wer veranlasst in der Regle die Einfuehrung einer solchen Software und ist damit der Hauptverantwortliche?
Frage 1.3: Welche Veraenderung(en) werden durch die Einfuehrung von E- Reverse-Auction Software herbeigefuehrt?
Frage 1.4: Was sind die Gruende fuer die Einfuehrung einer solchen Software?
Frage 1.5: Wer ist der Eigentuemer dieser Software?
Frage 1.6: Wie wuerdest du generell die Umgebung nennen, in der E-reverse Auction Software eingesetzt wird?
125 Interview 4 (26th of June 2003) – Hybris CSO (int01)
Business Systems Options (BSOs) – E-Reverse Auctions
Frage 1: Beschreibe bitte die allgemeine Funktionsweise eines E-Reverse Auction Tools!
Frage 1.1: An welcher Stelle wird das E-Reverse Auction Tool im Einkaufsprozess eingesetzt?
Frage 1.2: Soll das E-Reverse Auction Tool nur für das von Euch bereitgestellte Katalogsystem anwendbar sein?
Frage 1.3: Welche Teilprozesse soll der Auktionsprozess beinhalten?
Frage 1.4: Welche Arten von Auktionen sollte das Reverse Auction Tool ermöglichen ?
Frage 1.5: Welche Funktionalitaet sollte das System fuer den Kaeufer bereitstellen?
Frage 1.6: Welche Funktionalitaet sollte das System fuer den Lieferanten bereitstellen?
Frage 1.7: Welche Vorteile ergeben sich dadurch fuer den Lieferanten?
Frage 1.8: Welche Vorteile hat der Kaeufer von der Einfuehrung von E-reverse auction software?
126 Interview 4 (26th of June 2003) – Hybris CSO (int01)
Business Systems Options (BSOs) – E-Reverse Auctions
Frage 2: Beschreibe bitte, welche Beteiligten genau in das System integriert werden sollen und wie dies geschehen soll!
Frage 2.1: Welche Lieferanten sollten in das neue System integriert werden ?
Frage 2.2: Können auch Lieferanten für eine einmalige Auktion an das System angebunden werden?
Frage 2.3: Ab welcher Unternehmensgröße lohnt es sich, ein solches System zum Procurement einzusetzen?
Frage 2.4: Kann die Software auch als Marktplatz genutzt werden?
Frage 2.5: Wie funktioniert das System, wenn es als Marktplatz genutzt wird?
127 Interview 4 (26th of June 2003) – Hybris CSO (int01)
Business Systems Options (BSOs) – E-Reverse Auctions
Frage 3: Beschreibe bitte die allgemeine Entwicklungsstrategie fuer das E- Reverse Auction Tool!
Frage 3.1: Wird die Software ausschließlich inhouse entwickelt?
Frage 3.2: Welche Komponenten werden von anderen Firmen beigesteuert?
Frage 3.3: Bietet Hybris User Training an? Wenn ja, fuer wen?
Frage 3.4: Welche Aktvitiaeten muss Hybris zusammen mit dem jeweiligen User entwickeln und absprechen?
128 Interview 4 (26th of June 2003) – Hybris CSO (int01)
Business Systems Options (BSOs) – E-Reverse Auctions
Frage 4: Welche Auswirkungen hat die Einfuehrung des E-Reverse Auction Tools auf die Firma, die die Software nutzt?
Frage 4.1: Ist neues Personal zur Betreuung des Systems erforderlich auf Seiten des Users?
Frage 4.2: Wer wartet die Software?
Frage 4.3: Fuehrt die Einfuehrung der Software zu einer Veraenderung in der Organisation z.B. des IT Departments oder anderer Abteilungen auf Seiten des Users?
Frage 4.4: Wie hoch sind die geschätzten Kosten für die Einführung der Software?
Frage 4.5: Wie lange dauert die Einfuehrung der Software?
129 Interview 5 (23rd of June 2003) – Manager Support und Training (int02)
Technical Systems Options
Frage 1: Bitte beschreibe das allgemeine technische Umfeld des E-Reverse Auction Tools im Detail!
Frage 1.1: Welche Application Server unterstützt die Software?
Frage 1.2: Welche Datenbanken unterstützt die Software?
Frage 1.3: Welche Operating Systems unterstützt die Software?
Frage 1.4: Gibt es Unterschiede in verschiedenen Kombinationen von Application Server mit Datenbanken und Operating Systems?
Frage 1.5: Beschreibe bitte die Funktionsweise der Plattform (Hybris Jakarta), in die das E-Reverse Auction Tool eingebunden ist, auf den unterschiedlichen Hierarchieebenen vom Datenbanklevel bis zum Application Level/HTML-Code?
Frage 1.6: Wie ist das E-Reverse Auction Tool in dieses Plattform eingebunden?
Frage 1.7: Welche bestehenden Systeme des Kunden werden integriert?
Frage 1.8: Wie werden diese Systeme integriert?
130 Interview 5 (23rd of June 2003) – Manager Support und Training (int02)
Technical Systems Options
Frage 2: Bitte mache detaillierte Angaben zu den Sizing Requirements des E- Reverse Auction Tools!
Frage 2.1: Welche Transaktionen kommen am häufigsten vor?
Frage 2.2: Welche Art von Requests kommen vor?
Frage 2.3: Wie hoch ist die geschätzte Anzahl der User?
Frage 2.4: Wie hoch ist die geschätzte Anzahl der Produkte?
Frage 2.5: Wie viele Requests gibt es?
131 Interview 5 (23rd of June 2003) – Manager Support und Training (int02)
Technical Systems Options
Frage 3: Wie lange ist die geschätzte Entwicklungszeit für ein E-Reverse Auction Tool?
132 Appendix 2
Mathematical Formulation of the Bundled Bid Winner Determination Problem (Davenport et al., 2001)
133
134 Appendix 3
Mathematical Formulation of the Volume Discount Bid Winner Determination Problem (Davenport et al., 2001)
135
136
137
138 Appendix 4
Sizing Estimates for the Hybris Jakarta (Hybris, 2001)
Characteristics of a smaller system configuration
Quantity of products and customers
Product quantity, variants included 10.000
Customer datasets 5.000
Visits
Visits per Year 50.000
Average Visits per Month 16.700
Max. Visits per Month 83.400
Average Visits per Day 560
Max. Visits per Day 2.800
Average Visits per Hour 25
Max. Visits per Hour 120
Systemload for a smaller system configuration
Orders (Orders)
Average Orders per Day 278
Max. Orders per Day 556
139 Average Orders per Hour 12
Max. Orders per Hour 23
Page Impressions (PIs)
"Order" Impressions per Day 1.700
"Add to basket" Impressions per Day 1.250
"Browsing" Impressions per Day 340
Average PIs per Day 3.250
Average PIs per Month 97.500
Average PIs per Hour 135
Max. Pis per Hour 270
Concurrent Users
Maximum concurrent ordering Users 2
Requests
Average Requests per Day 16.250
Average Requests per Hour 680
Maximal Requests per Hour 1.400
Characteristics of a medium-sized system configuration
Quantity of products and customers
Product quantity, variants included 100.000
140 Customer data sets 25.000
Visits
Visits per Year 1.000.000
Average Visits per Month 84.000
Max. Visits per Month 420.000
Average Visits per Day 2.800
Max. Visits per Day 14.000
Average Visits per Hour 115
Max. Visits per Hour 580
Systemload for a medium-sized system configuration
Orders
Average Orders per Day 1.250
Max. Orders per Day 2.500
Average Orders per Hour 50
Max. Orders per Hour 105
Page Impressions (PIs)
"Order" Impressions per Day 7.500
"Add to basket" Impressions per Day 6.250
"Browsing" Impressions per Day 3.400
141 Average PIs per Day 17.000
Average PIs per Month 515.000
Average VPIs per Hour 700
Max. PIs per Hour 1.400
Concurrent Users
Max. concurrent ordering users 8
Requests
Average Requests per Day 85.000
Average Requests per Hour 3.600
Maximal Requests per Hour 7.200
Attributes of a larger system configuration
Quantity of products and customers
Quantity of products, Variants included 250.000
Customer datasets 50.000
Visits
Visits per Year 5.000.000
Average Visits per Month 420.000
Max. Visits per Month 2.080.000
Average Visits per Day 13.900
142 Max. Visits per Day 70.000
Average Visits per Hour 580
Max. Visits per Hour 2.900
Systemload for a larger system configuration
Orders
Average Orders per Day 6250
Max. Orders per Day 12500
Average Orders per Hour 260
Max. Orders per Hour 520
Page Impressions (PIs)
"Order" Impressions per Day 37.500
"Add to basket" Impressions per Day 31.250
"Browsing" Impressions per Day 16.700
Average PIs per Day 85.500
Average PIs per Month 2.562.000
Average VPIs per Hour 3.560
Max. PIs per Hour 7.120
Concurrent Users
Max. concurrent ordering users 40
143 Requests
Average Requests per Day 427.000
Average Requests per Hour 17.800
Maximal Requests per Hour 164.200
Attributes of a very performant system configuration
Product- and Customer quantity
Product quantity, Variants included 500.000
Customer datasets 125.000
Visits
Visits per Year 23.000.000
Average Visits per Month 2.500.000
Max. Visits per Month 12.500.000
Average Visits per Day 84.000
Max. Visits per Day 417.000
Average Visits per Hour 3.500
Max. Visits per Hour 17.400
Systemload of a very performant system configuration
Orders
144 Average Orders per Day 37500
Max. Orders per Day 75000
Average Orders per Hour 1600
Max. Orders per Hour 3125
Page Impressions (PIs)
"Order" Impressions per Day 225.000
"Add to basket" Impressions per Day 188.000
"Browsing" Impressions per Day 100.000
Average PIs per Day 512.500
Average PIs per Month 15.375.000
Average VPIs per Hour 21.400
Max. PIs per Hour 42.700
Concurrent Users
Max. concurrent ordering users 235
Requests
Average Requests per Day 2.562.500
Average Requests per Hour 106.800
Maximal Requests per Hour 214.000
145