EWARENHAUS BERLIN: THE FUTURE PROCUREMENT SYSTEM … · 2017-07-31 · The Future Procurement System of The Captital 43 the unified procurement processes and the designed system landscape

EWARENHAUS BERLIN: THE FUTURE PROCUREMENT

SYSTEM OF THE CAPITAL

Christian Holz, [email protected]

Falko Menge, [email protected]

Johannes Nicolai, [email protected]

Johannes Passing, [email protected]

Matthias Weidlich, [email protected]

Hasso-Plattner-Institut Potsdam, 14482 Potsdam, Germany

ABSTRACT

According to empirical studies, the manual costs of procurement-processing in

authorities are much higher than the value of the purchased items themselves. The

city administration of Berlin has been spending over 800 million EUR per year on

procurement and has not used an electronic procurement system. Our project

team analysed and evaluated different scenarios suitable for reducing processing

times and costs in the public administration of the capital. We documented the

current situation in Berlin, summarised the requirements captured, and optimised

the business processes based on user observations, interviews, and

questionnaires. To validate our findings, we implemented and tested two different

e-procurement solutions (SAP SRM Standalone/SAP XI and DOGRO

DBW/DHB). The paper focuses on our non-standard SAP solution that satisfies

the special requirements of Berlin derived by its unique administrative and

budgetary needs.

Keywords: E-Procurement, Requirements Engineering, Process Analysis, User

Research, SAP SRM, SAP XI, Business Process Management, Process

Optimization.

INTRODUCTION

As empirical studies have proven, the manual procurement-processing costs in

companies and governmental organisations tend to be significantly higher than

42 Christian Holz et al.

the value of the purchased items themselves. The Aberdeen Group (Aberdeen

Gr a

pencil in several large termined the average

costs to be 114 USD if no electronic procurement system is used. In contrast,

companies th erage 31.50

USD and need

The city year on

procureme although

the desire

Several proj 7) with the

centralise and consolidate internal cross functional tasks have

been conducted over the past years, yet only little progress has been achieved in

uropean tender for the implementation and rollout of the

rocurement situation in the city of Berlin. Section 3 outlines our

t and document the requirements for the “eWarenhaus”

and summarises the most important results. Section 4 illustrates the main issues of

oup 2001) has analysed the processing costs of procuring a C-article1 such as

companies. This cost analysis has de

at already operate an e-procurement system spend an av

only a quarter of time.

administration of Berlin, spending 800 million EUR per

nt purposes, does not use an electronic procurement system,

for electronic support has existed for years.

ects (Senate Office for City Development Berlin, 200

common goal to

the attempt to introduce a central e-procurement system, the “eWarenhaus Berlin”

2.

The Senate Office of Internal Relations has, thus, encouraged the

Hasso-Plattner-Institut of Software Systems Engineering Potsdam to perform a

feasibility study concerning the electronic procurement in the city of Berlin. Our

group of seven bachelor students under the guidance of Prof. Dr. Werner Zorn,

Dr. habil. Susanne Patig and M.Sc. Stefan Kluth has collected the technical and

organisational requirements for the “eWarenhaus” and designed and evaluated

two possible approaches at a solution. Having assembled a functional

specification and developed these prototypes, we were, then, able to have the

requirements validated by the employees of the council of the Berlin boroughs

Berlin Lichtenberg and Berlin Mitte. The results of our study are now to serve as a

basis for a pan-E

“eWarenhaus”.

This paper is structured as follows. Section 2 describes the current organisational

and technical p

used approach to collec

1 C-articles are consumer goods with little raw and strategic value.

2 eWarenhaus Berlin is the German term for eWarehouse Berlin.

The Future Procurement System of The Captital 43

the unified procurement processes and the designed system landscape intended to

be implemented in Berlin. Section 5 deals with the concrete implementation of

our concepts and approaches by developing two prototypes. The paper concludes

by presenting the major outcomes of our study in Section 6.

CURRENT SITUATION

Procurement process

Every public authority in Berlin has the opportunity to participate in a Centralised

Procurement Procedure (CPP) operated by the State Administration Bureau

product quantities actually required. As a consequence, it has to rely on

emand has been accepted. Consequently, the stock management

(SAB). The CPP (State Administration Bureau Berlin, 2007) was established to

accumulate orders to take advantage of economies of scale. Furthermore, the

scope of the CPP is defined by the SAB, which also prepares the submission and

awarding of contracts. Due to lack of controlling, the SAB has no knowledge of

the

feedback provided by former suppliers to prepare the submissions. Based on these

submissions, potential suppliers submit their offers.

Once a certain group of suppliers has been selected, the SAB prepares and

distributes a catalogue to all public authorities participating in the CPP. In

addition to a printed version of this catalogue containing the product prices, an

electronic version in PDF format without product prices is also submitted to every

participating department.

The process of ordering a certain product of the catalogue varies, as the

autonomous boroughs have established different administrative structures. A

common approach is using small local stocks, which distribute products. In this

case, a consumer declares his demand at the local stock and directly fetches the

products, if his d

orders products from the catalogue in advance to ensure the availability of all

products. A different approach used throughout several boroughs allows the

employees to order products on their own. Consumers submit a requisition note to

their superior authority. After approval, a commitment3 is created and the order is

nt will be frozen and, thus, 3 By creating a commitment, the required budget on a certain accou

cannot be used for other purposes any longer.


submitted to the corresponding supplier (with a customer number provided by the

SAB), which delivers the product directly to the consumer. Once the shipment has

arrived, the consumer passes the signed bill of delivery to the local finance

department. Subsequently, the payment is triggered after the supplier sent the bill

Major drawbacks of the current process are media breaks4 in the continuous

he consumer to the supplier. In addition the cycle time

g appropriate means for

to the local finance department.

information chain from t

from ordering to receiving an item is long compared to industry standards because

of missing electronic processing. Due to organisational diversification and the

decentralised processing of ordering, the SAB is lacking the ability of gathering

feedback about the utilisations of its contracts. Moreover, there are also unused

potentials in regard to the bundling of requisition notes to reduce effort.

Technical landscape

While the awarding process is conducted through a web-based platform, a system

assisting the procurement process and providin

controlling is still missing. In addition, the SAB cannot use industry-standard

technologies for exchanging catalogue data with the suppliers. Rather, product

descriptions, received as PDF or Microsoft Excel files, are manually assembled

into a catalogue, which is then distributed either via e-mail or as printed

document.

Besides supporting the entire procurement process, a prospective procurement

system is also required to provide seamless integration with the currently

deployed accounting system ProFiskal, a system developed by DOGRO-Partner

ProFiskal Software GmbH & Co KG (DOGRO 2007). ProFiskal components are

particularly adapted to the needs of the administration of Berlin.

As the city of Berlin prepares the roll-out of further ProFiskal software modules,

these systems will be used for the next ten to fifteen years at least according to the

Senate Office of Internal Relations. Thus, a feasible integration of ProFiskal and

the procurement system is of particular importance.

consumes considerable resources.

4 A media break is a situation where data from one medium has to be transferred into another

medium. This process is often error-prone and


CURRENT SITUATION

In our preliminary investigations of the topic we developed a basic understanding

of the procurement processes in the public sector. We analysed several models of

how the system for Berlin can be structured from a technical and organisational

point of view. In this stage UML use case diagrams (Object Management Group

2007) and FMC block diagrams (Knöpfel et. al. 2005, FMC Consortium 2007)

have been used.

Consumer

XOR

XOR

Load stored

shopping cart or

template

[E02]

Shopping cart

created

Follow up

existing shopping

cart

Figure 1: First part of procurement process

Requisition is

noticed

Change Items

[E06]

Shopping cart has

to be authorised

Replace free text

items, possibly

supplementation

Procurement

operator

Order contains

free text

requisition note

Add article to

shopping cart

[E04]

Free text items

have been

replaced

Change and accept

free text

replacements

[E09]

Found ArticleXOR

Cancel

Shopping cart

is complete

Further

articles

required

Assign inital

account

[E05]

XOR

Search

articles

[E01]

XOR

Initial account

assignment

requested

Free text

requisition

note

requested

Create free text

requisition note

[E03]

Send

shopping cart

[E07]

Items are

validXOR

XOR

Consumer


This initial knowledge base was then augmented iteratively by user research and

Figure 2: Domain model of most important entities and

characteristics in our procurement process.

observation. We interviewed the procurement department managers of the

boroughs Berlin Lichtenberg and Berlin Mitte about their concrete processes and

existing IT support. We also talked to buying agents and accountants of the

procurement departments who showed us in detail how procurement is done in

practise.


The knowledge of the currently implemented processes was essential to define the

requirements for an electronic procurement solution in Berlin, but also the

products we evaluated in our testbed contributed to the requirements in a way that

they drew our attention to some practical aspects.

We distinguished five groups of requirements according to the different parts of

the procurement process they belong to. Each group contains about five to 20 use

cases and is described by several models. The workflows are modelled as

event-driven process chains (Kim 1995) as depicted in Figure 1. UML class

diagrams as shown in Figure 2 are used to describe a domain model and use case

diagrams give an overview about which roles are involved in the different

activities. The procurement process starts with the determination of the demand

by selecting products from an electronic catalogue and putting them into a virtual

shopping cart. If something can not be found in the catalogue it is possible to

describe the demand using free text.

The second group of requirements contains use cases dealing with the

authorisation of the demand. A manager responsible for the particular cost centre

of the demanding employee takes a look at each shopping cart position and

decides whether or not the order is allowed. Therefore she verifies if there is

enough budget and maybe she also changes accounting details. The actual

ordering from the supplier forms the next group of use cases. Shopping carts can

be bundled into larger orders or also split up into multiple orders if they contain

goods from multiple suppliers. For each order the according budget is set and

finally, orders are sent to the supplier via internet. The next group deals with the

recordal respectively proofing of goods arrival and invoice. If everything is

correct the payment of the invoice is triggered. The last group of requirements

contains several administrative tasks like updating catalogues and contracts,

analysing contract utilisation, optimising workflows, archiving and backup tasks

as well as maintaining users, suppliers and organisational structures.

A use case itself is described in a structured way like shown in Figure 3. Every use

case h s a unique lved.

First a short descr to be

performed in order to fulfil the use ca

a number, a priority and one or more roles which are invo

iption gives an overview and then the sequence of steps

se. Furthermore pre and post conditions,


special considerations, interfaces, extension points and security requirements are

specified. For each use case, we analysed in which degree it can be realised with

our testbed systems described in section 5. Figure 3 shows the scorecard for the

implementation of use case “E01 - Find Products” with SAP SRM. It rates the

coverage of each part of the use case specification in Figure 4. Possible ratings are

++ (completely covered), +, o, -, -- (not covered at all) and ? (unknown).

Figure 3: Sample use case scorecard


Figure 4: Sample use case

Figure 5 below shows the intended to-be scenario. All communication is

coordinated i.e. all authorities

oncerned, suppliers and consumers electronically interact with the procurement

system, which controls all ordering processes.

Suppliers who got the award provide authorities with their catalogues. Authorised

employees working in the State Administration Bureau, in turn, integrate the

single catalogues' contents into the main catalogue, which is available for each

employee. Prices and images showing products should be updated automatically.

In the long run, the electronic procurement system could efficiently support the

allocation process, e.g. service descriptions could be generated or offer prices for

announced positions could be directly recorded.

by the central “eWarenhaus” component,

c


TO-BE CONCEPT

to-be scenario

The responsible cost centre manager or a user authorised to cover for him also has

access to the system. She gets informed about the requisition note as soon as the

consumer submits it. Then she has to check the note's factual correctness and

Figure 5: Components of the

According to the scenario depicted in Figure 5, consumers working in different

authorities log on to their account in the “eWarenhaus” system. They are then

authenticated and are the roles assigned which gather the rights they need to have

to fulfil their part of the process. Enabled rights allow users to examine contents

of the catalogue and start operations, e.g. searching for needed articles, putting

items into their carts, or requesting unlisted positions. The shopping cart can be

seen as an electronic requisition note.


checks the budget in or

requested positions are

der to ensure the financing of the procurement. If the

factually correct and economically verified, the

requisition note is published for ordering. Since outline agreements exist, the

order conform

The orde ed artic r purchaser. The

re, it is able to negotiate more precise

s to a supplier's release order. These calls are made either manually

or directly, i.e. by electronic means. Manually means dispensing points set up by

authorities forward an order ticket to the supplier.

Figure 6: Architecture of the procurement system

r les are delivered directly to the consumer o

respective person updates the order's status in the procurement system noting one

of the following possible options: correct delivery, damaged delivery, wrong

article(s), wrong number of articles, and so on. The cost centre manager receives

both, invoice and delivery receipt and consequently orders the cash point to pay

the invoice via the integrated procurement system, if the status is positive.

The State Administration Bureau is able to create reports listing ordered articles

and their released quantity. Therefo

contracts with suppliers.

Figure 6 depicts the architecture of the procurement system. It consists of the

following major components: catalogue management, order management, and


budget management. Administrators are able to maintain user accounts and their

rights by means of the user management component, which is a cross-section

functionality for all other components and hence is not displayed in Figure 6 due

to clarity and simplification.

The catalogue management component provides functions to maintain

catalogues, browse and search articles and combine and save the positions

elected in a shopping cart. Catalogue maintenance also includes automatic

im

arenhaus”

In addition,

ble),

m

The budget m

econom ption

from

h can be carried

acc

ty, an

uate and precise the requirements in an iterative fashion

s

ports of catalogues and manual changes of single positions.

The order management component is the central element of “eW

Berlin. It checks requisition notes based on shopping carts passed down by the

catalogue component and updates their status to `ordered'.

maintenance includes forwarding orders to suppliers (bundled if possi

onitoring orders and updating the order's status. Besides, it deals with recording

goods and invoice receipt and initiating the payment.

anagement component supports the order management as it reads

ical-business information on available budgets and their consum

Berlin's budgeting system ProFiskal, and thus approves or disapproves

orders. The budget management conforms to a workflow, whic

out either automatically within the procurement system or manually by directly

essing the budgeting system.

Consumers and other users get access to the procurement system via a front-end,

which can be based on both, web or rich-client technology.

PROTOTYPING

Pilot-Implementation

In order to validate the requirements captured and to demonstrate feasibili

integral part of our approach was to set up a pilot-implementation of a software

system realising the to-be concept defined. Having such an implementation at

hand enabled us to re-eval

in the later phases of the project. In several workshops, the stakeholders were

presented real-life examples of procurements using the concrete system. This as


well as having stakeholders directly interact with the system, both, helped

enhancing the comprehension of the process and allowed for identifying

shortcomings and possible areas of enhancement.

After having spent the first third of the project period capturing the basic

and procurement

enfield development and

inspected by the stakeholders and turned out to

s on this system.

ctural alternative to be implemented, we chose to deploy

006, SAP 2006) software, combined with an Exchange

Infrastructure 3.0 (Nicolescu et. al. 2006, Stumpe et. al. 2006) installation, as

requirements, we made an evaluation of several possible system architectures for

pilot implementations. The most important constraint in this evaluation was the

integration of the existing budgeting system DOGRO ProFiskal DHB. The

supersession of this system with a single, integrated budgeting

software was not an option to consider, as the ProFiskal system has been declared

to be in use for at least ten to fifteen years. As such, two basic architectural

approaches could be spotted:

The enhancement of the budgeting system so that the entire procurement

process can be handled.

Setting up a procurement system based on gre

integrating both systems.

Of course, both approaches have their own advantages and shortcomings. In

particular, none of these solutions could be identified as being superior with

respect to the specific constraints of Berlin and the requirements captured at this

point. Consequently, we chose to create implementations for both architectures.

Both implementations were later

be viable solutions. The second implementation - being based on SAP SRM 4.0-

has proven to be more flexible. In addition, it satisfies requirements better and

even more precisely. Hence, the following discussion focuse

For the second archite

SAP SRM 4.0 (Weisert 2

illustrated in Figure 7. The objectives of this decision are twofold; on the one

hand, SAP being one of the market leaders in this specific area of standard

software can be expected to offer a proven solution for procurement systems.

Furthermore, the sustainability requirements and demand for long-term support

posed by the city of Berlin are addressed by SAP. On the other hand and possibly


more importantly, recent consolidation efforts of Berlin have yielded a general

orientation towards SAP software.

Figure 7: System landscape of the solution based on SAP components

The chosen system landscape includes an SRM 4.0 server as central component.

The catalogues are hosted and made available to the users by the CCM 2.0 server,

which in turn uses the TREX server for indexing and searching catalogue items.

For pricing and the hosting of the web interface, an IPC and an ITS system were

deployed. For integration purposes, namely the SRM/ProFiskal interfacing and

the import of external catalogues, an Exchange Infrastructure (XI) installation

was used. HCC München (SAP University Competence Centre Munich) has

conducted the initial setup and maintenance of all these systems except TREX.

HCC München also provided all SAP software components with permission by

SAP. By means of appropriate customising, we were able to realise the designated

procurement process and had the system fulfil the requirements posed. However,

for the integration with ProFiskal to be realised, several intricatenesses had to be

overcome.


Integration

SAP SRM is most commonly deployed in conjunction with an R/3 Enterprise

ackend

is

rfaces

betwe ased

FC loop back connection, the local system was configured to be the

backend system of type R/3 4.6C. Having provided these setting in the

customising, SRM would now call our own function modules instead of trying to

contact an FI system, rendering the direct FI dependency obsolete.

Core Components installation, including the FI module serving as the budgeting

system. Hence, SRM is designed to work in conjunction with FI as 'b

system'. Although three documented scenarios differing in the degree of coupling

between these two systems exist, a true 'standalone' scenario that does not require

the FI-backend and instead provides the usage of a third party budgeting system

not currently intended. The basic interfaces between SRM and the backend

system are only lightly documented, yet they are public and stable and may thus

be used for integrating a non-FI backend system such as ProFiskal. The use of

custom IDoc ports (for the transmission of commitment orders and invoices) and

a custom driver (for budget check) causes the SRM to provide explicit support for

specifying alternate implementations to be used. In theory, the desired integration

could thus be realised by solely relying on these hooks.

In practise, however, our investigations have shown that further inte

en SRM and FI exist. The problematic aspect about these RFC-b

interfaces is that they do not employ a single-indirection scheme (such as through

the use of a driver). In other words, SRM does not provide any support for using

alternate implementations of these interfaces. As a consequence, these interfaces

impose a direct dependency on FI, thwarting any efforts to integrate third-party

budgeting systems. It may be assumed that these interfaces have been introduced

in recent versions of SRM and have not existed at the time the mentioned

third-party integrations were realised.

As the mentioned direct-dependency interfaces became apparent to be not

essential for the operation of the system, a simple workaround could be

employed. From an FI-installation, we took the names and signatures of the

affected RFC function modules and created corresponding function modules on

the local SRM system using simple implementations. Furthermore, having

created an R


Having overcome the technical difficulties on the SRM side of the interfacing,

, being the compulsory

BAP function pool implementation. The

nvoice-IDocs

ProFiskal imposed further limiting factors. Constraining the most, ProFiskal does

not provide any interfaces for online booking or retrieval of data. The only

supported way to access the system besides using the user interface is through

batch import. Using batch import, a variety of booking transactions, including but

not limited to commitment orders and invoices can be imported and dispatched.

Presuming appropriate consideration, DOGRO assured us the basic feasibility of

enhancing the system with appropriate online interfaces supplying web services.

For a production environment, the usage of online interfaces promises to offer a

cleaner and more robust integration, although the semantics of such a web service

may be expected to be similar to the existing batch input interface.

Another problem bearing to be solved was inhomogenity of accounting schemes

used. While SRM uses industry-standard double-entry bookkeeping, ProFiskal

uses a fundamentally different scheme called cameralism

standard of German administration. This discrepancy was overcome by using

transformation functions and a collection of mapping tables. Although the

maintenance of the required tables imposes a certain steady administration effort,

the integration could be realised in a fully-automatic manner. Due to the fact that

the mapping tables, once properly initialised, will need to be changed only

infrequently, this solution promises to be cost-efficient in the long run.

For the technical integration, we have identified two solutions, both of which

have been implemented and tested successfully. The first approach to be

presented briefly relies on a custom A

basic idea employed is to capture the IDocs sent by SRM through the use of

ABAP-PSS IDoc ports. After extracting the required information from the IDocs

and performing several transformation steps including the conversion from

double-entry bookkeeping and cameralism, the booking data is buffered in the

local database. On a regular basis or through user interaction, the accumulated

orders are then retrieved from the database, formatted properly to comply with the

file format required by ProFiskal, and finally exported.

The second implementation uses SAP Exchange Infrastructure as a message

broker. Using XML-HTTP IDoc ports, the commitment order- and i


are transmitted to XI, where an integration process performing several

transformations, including the transformation of accounting information, receives

them. Following, the messages are transferred to a second integration process

realising the collection of messages - incoming messages are buffered for a

certain time interval after which all buffered messages are exported in a single file

ready to be imported by ProFiskal.

Having investigated the integration of SAP SRM and ProFiskal on a rather

detailed level and having overcome both technical and semantic discrepancies,

we have proven that an integration of SRM with a third party budgeting system is

technically still possible. Moreover, we have set up an e-procurement system well

reflecting the specific requirements of Berlin.

OUTCOMES

During the validation phase of our project, we let clerks, also involved in the

interview process, interact with our prototypes and improved the requirements

and prototypes according to their feedback. Furthermore, we wrote a story board

containing all procurement-related activities in a typical day of a public authority

of Berlin. Then, we inserted some typical exceptions from the standard process (e.

g. missing items in delivery, misspelled suppliers in search terms for the

catalogue and delegation of work items), we often noticed during user

Administration Bureau,

observation. After that, we captured video streams demonstrating how our pilot

implementations can be used to fulfil all activities contained in the storyboard.

Finally, we put these videos on DVD, distributed them among numerous

authorities and asked for further feedback.

We consistently observed positive reactions. Most clerks seemed to be excited

about the new possibilities electronic procurement provides to public authorities.

They assured us that the requirements and unified procurement processes

documented in our functional specification are both, realistic and would fit the

needs of the public administration of the city of Berlin. After a presentation of our

study to the Senate Office for Internal Relations, the State

the Berlin boroughs Berlin Lichtenberg and Berlin Mitte and the IT Service

Centre Berlin, it was decided to prepare a pan-European tender on the basis of the


results of our Bachelor thesis (Blechschmidt et. al. 2007). Since the preparation is

still in progress, we cannot say anything about the results yet.

Numerous institutions approached our group and the Hasso-Plattner-Institut

Potsdam to conduct follow-up projects. Currently, another bachelor project

analyses best practices to prepare the boroughs of Berlin, the State Administration

Bureau and the suppliers of the needed goods for the step-by-step introduction of

reason, we were asked by SAP to

ss story" (Patig 2007) that is hoped to attract other public

authorities in similar situations.

ent-Process Chain Approach”,

the "eWarenhaus Berlin".

The software suppliers of our prototypes, SAP and DOGRO, also signalled their

interests for further cooperation with our group. The standalone-scenario we

applied to reflect the special needs of Berlin without using an SAP R/3 system has

not been tested by SAP for three years. For this

provide a "succe

REFERENCES

Aberdeen Group (2001), “E-Procurement: Finally Ready for Prime Time”, Aberdeen

Group, Vol. 14 No.2, Boston.

Blechschmidt, Holz, Kunze, Menge, Nicolai, Passing, Weidlich (2007), “eWarenhaus

Berlin –Das zukünftige Beschaffungssystem der Hauptstadt”, Bachelor Thesis,

University of Potsdam, Potsdam.

DOGRO-Partner ProFiskal Software GmbH & Co. KG (2007), http://www.dogro.de

FMC Consortium (2007), “Fundamental Modeling Concepts”,

http://www.fmc-modeling.org

Kim Y. (1995), “Process Modeling for BPR: Ev

Proceeding of the Sixteenth International Conference on Information Systems:

109-121, Amsterdam.

Knöpfel A., Gröne B. and Tabeling P. (2005), “Fundamental Modeling Concepts:

Effective Communication of IT Systems“, Wiley, West Sussex.

Nicolescu V., Funk B., Niemeyer P., Heiler M., Wittges H., Morandell T., Visintin F.

and Stegemann B.K. (2006), “Entwicklerbuch SAP Exchange Infrastructure”,

Galileo Press, Bonn.


Object Management Group (2007), “Unified Modeling Language (UML) Infrastructure

Specification” and “Unified Modeling Language (UML) Superstructure

ation Guide” and “Catalog Content Management:

Configuration Guide”

Exchange Infrastructure”, Galileo Press, Bonn.

onfiguration Fact Book CCM 2.0”, SAP, Walldorf.

State Administration Bureau Berlin (2007), “Darstellung des Sammelbestellverfahrens

Stu P Exchange Infrastructure”, Galileo Press, Bonn.

Specification”, both version 2.1.1, http://www.uml.org

Patig, S. (2007), “Studenten helfen Berlin beim Sparen”, SAP Success Story,

http://www.hcc.uni-magdeburg.de/public/common/dokumente/20070613berlin_hpi

_projekt.pdf

SAP (2006), “SRM Configur

Senate Office for City Development Berlin (2007), “AVA-Online – Veröffentlichungs-

und Vergabeplattform des Landes Berlin”,

http://www.vergabeplattform.berlin.de/main.html

State Administration Bureau Berlin (2007), “Darstellung des Sammelbestellverfahrens

(SBV)”, http://www.berlin.de/landesverwaltungsamt/sbv/sbv.php

Stumpe J. and Orb J. (2006), “SAP

Weisert, U. (2006), “C

(SBV)”, http://www.berlin.de/landesverwaltungsamt/sbv/sbv.php

mpe J. and Orb J. (2006), “SA

Weisert, U. (2006), “Configuration Fact Book CCM 2.0”, SAP, Walldorf.

Documents

EWARENHAUS BERLIN: THE FUTURE PROCUREMENT SYSTEM … · 2017-07-31 · The Future Procurement System of The Captital 43 the unified procurement processes and the designed system landscape