ewarenhaus berlin: the future procurement system … · 2017-07-31 · the future procurement...
TRANSCRIPT
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.
44 Christian Holz et al.
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
The Future Procurement System of The Captital 45
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
46 Christian Holz et al.
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 Future Procurement System of The Captital 47
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,
48 Christian Holz et al.
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
The Future Procurement System of The Captital 49
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
50 Christian Holz et al.
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.
The Future Procurement System of The Captital 51
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
52 Christian Holz et al.
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
The Future Procurement System of The Captital 53
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
54 Christian Holz et al.
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.
The Future Procurement System of The Captital 55
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
56 Christian Holz et al.
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
The Future Procurement System of The Captital 57
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
58 Christian Holz et al.
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.
The Future Procurement System of The Captital 59
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.