eGovernment Process Knowledge Ontology

Business Process Knowledge Interdependencies in the

Public Administration

Andrea Schminck, Rami-Habib Eid-Sabbagh, Mathias Weske

Institute of Computer Science at the University of Potsdam

14482 Postdam

Hasso Plattner Institute at the University of Potsdam

14482 Postdam

andrea.schminck@cs.uni-potsdam.de

rami.eidsabbagh@hpi.uni-potsdam.de

mathias.weske@hpi.uni-potsdam.de

Abstract: Optimising government operations and providing eGovernemt services hasassumed a major role for reducing government expenditure as well as tackling demo-graphic challenges in times of financial crises and resource shortages on different lev-els. However, re-organising public administrations, introducing IT-Systems support,and improving their service delivery is highly complex as their operations are highlyinterconnected and restricted by laws and regulations. Public service delivery as wellas input and output documents, executing roles, are defined by laws and regulations.The impact of change on the different aspects of this domain has to be consideredwhen changing and improving organisational or procedural structures.

Hence optimisation efforts of business processes, data quality, laws or organisa-tional structures need good and complete documentation and understanding of activ-ities and interdependencies between the different aspects of public service delivery.Planned changes have to be checked for feasiblity and compliance in regard to theregulations and interdependencies between business processes. This paper presents aneGovernment Process Knowledge ontology that takes a holistic view on the govern-ment domain, describes the interdependencies of the different aspects of public servicedelivery, and maps them to BPM elements. We present change strategies based on theontology that consider all elements and their interdependencies in the optimisationprocess. Our methodology will be explained on a real use case from the public admin-istration, the vehicle registration process.

1 Introduction

In recent years governments and public administration aim to modernise their internal and

external processes and services, their organisational structure and IT-Infrastructure. Bud-

get pressure, financial austerity measures, and demographic challenges accelerate these

modernisation undertakings especially in Europe. In the course of modernisation ef-

forts, eGovernment, i.e. the support of government operations and public services with

722

IT-systems is regarded as highly resourceful. eGovernment, however, mainly adresses

organisational changes.

To fully develop the modernisation potential of eGovernemnt an insight into the process

domain in the public sector (public services) is needed. What is the usual structure of a

public service? What is their input and ouput? What are the interdependencies between

the different elements? What should one consider when changing these processes or input

data, e.g. when introducing new IT systems?

These aspects are dealt with in Business Process Management (BPM) [Wes12], Enter-

prise Architectures, and more specifically in Business Process Architectures [DVR11,

ESDW12] which include descriptions of the business processes and their interdependen-

cies, or also meta models containing an abstract view on all process elements of an enter-

prise. To simply use only an abstracted view to describe the structures of public services

is inadequate as the main characteristics and interdependencies of processes in the public

sector need to be considered when optimising and re-engineering business processes. The

objective of this paper is therefore to:

1. outline characteristical elements of public services using an exemplary case study

2. design a knowledge ontology for public services, and mapping it to BPM elements

3. outline change strategies for process re-engineering in the public sector using the

ontology

The remainder of this paper is organised following these objectives. Section 2 embeds our

paper into current research. Section 3 gives an overview of public services characteristics

exemplified on the vehicle registration process. In Section 4 we develop and present the

Process Knowledge ontology for the eGovernment domain. Based on this, the strategies

for change and optimisation in this domain are described in Section 5. We evaluate our

framework on a real use case from the public administration in Section 6, followed by the

conclusion in Section 7.

2 Related Work

The work presented in this paper can be roughly related to two major streams of research:

Business Process Management in eGovernment, and Ontology modeling of the public

sector.

BPM has become an integral element of eGovernment strategies for establishing a process

view on the public administration. Based on the overview gained processes in the public

administrations are optimised. Several BPM initiatives1 exist in Germany; e.g. the Na-

1IT-Beauftragte der Bundesregierung

http://www.cio.bund.de/DE/Architekturen-und-Standards/

Daten-und-Prozessmodellierung/Prozessmodellierung/prozessmodellierung\

_node.html

723

tional Process Library2 where public services are collected, described, analysed, shared

and improved. A similar approach is pursued in Switzerland by the eCH project aiming at

developing generic public service descriptions3.

Attempts to create meta models or domain ontologies for the public sector based on the

process model pools are rare. One of the most popular approaches comes from Greece, the

Governance Enterprise Architecture (GEA) [PT04]. The main driver for this project were

the demanding semantic interoperability problems in the complex and distributed environ-

ment of public administration. One important part of the GEA plays the "‘GEA Object

Model for the Service Execution Phase"’ (SEP model) which specifies five central entities

of a public service (Service, Rule, Outcome, Evidence, Subject). Among other applica-

tion scenarios, the GEA model is used to implement eGovernment services using semantic

web service technologies. In [VL07], the transformation from the generic eGovernment

object model to descriptions of services based on the Web Services Modeling Language

(WSML) is presented.

Refining the GEA, the Public Administration (PA) domain ontology for eGovernment ser-

vices is presented by Goudos [GLPT07]. It covers multiple aspects of the public domain

grouped around public services such as responsible roles, involved documents, or admin-

istrative level. The aim is to model the relations between the concepts of the domain in

order to support different tasks as electronic service provisioning, including workflow and

change management.

A similar approach is the domain models and enterprise application framework for public

services developed at the United Nations University [OJE07]. It depicts the key aspects

of public service delivery to provide a semantic basis for formulating the domain require-

ments. Ojo et al. [OJE07] also present a behavioral view of in their electronic public

service framework that shows am abstract process of public service delivery. However, the

interdependencies between public service elements and business process elements are not

considered in their ontology for developing electronic public services.

A well developed object model for public services is defined in the UK e-Service Devel-

opment Framework [Off02]. The Government Common Information Model (GCIM) is

based on a "‘Service Interaction"’ which describes the interface between a service and its

user. It defines its relations to subjects, services, locations, outcomes, evidences and rules.

The GCIM can be used to define the requirements of business processes, helping analysts

and domain experts to share a common view of the domain.

One approach considering Business Process Management for the eGovernment domain is

the ontology presented by Stojanovic et al. [SASS04]. They create a formal model for

public services in order to represent ways to manage changes of semantic web services.

In this way the change propagation process can be automated and executed in a consistent

way.

Parts of elements and considerations from the before mentioned approaches will be used

in our ontology presented in the next sections. However, in contrast to before mentioned

approaches, our focus is the integration of the procedural view, i.e. BPM elements, into the

2Nationale Prozessbibliothek http://www.prozessbibliothek.de3eCH Project http://www.ech.ch

724

characteristics of the public sector and public service delivery in the eGovernment domain.

In this way BPM research results can easier be applied to eGovernment processes with the

help of proposed ontology. A more holistic view is taken and changes made to one of the

elements in the ontology is propagated to all other interrelated elements providing a more

consistent change management process.

3 Processes in the Public Sector

This section introduces the characteristics of the public sector domain focusing especially

on public services. The main elements of public services will be highlighted and explained

on an exemplary case study; the vehicle registration process in Germany.

3.1 Public Service Characteristics

Compared to the private sector, the public sector is characterized by a strong hierarchical

organisation. The responsibilities are determined by laws and other administrative reg-

ulations and cannot easily be changed. Including this point, the main characteristics of

processes in the public sector are [LT01]:

• a high degree of political and legal regulations (laws)

• a high importance of information and knowledge (data)

• a high degree of collaborative processes (actors)

• a high degree of interdependencies between processes

The main product type and as such the outcome of a public service is the administrative

decision. A requester submits a request for a particular service and then receives the result

of the decision, e.g. the citizen submits evidence data, the administration processes it and

makes a decision, finally it notifies the citizen about their positive or negative decision,

for instance a building permission or prohibition to run a restaurant. In order to come to a

decision, different kind of process types exist which can be differentiated by their level of

regulation. Highly regulated and often repeated processes are "‘programmed decisions"’

and can be seen as the operative work of the administration. "‘Non-programmed deci-

sions"’ like control procedures, resource management and management decisions are less

regulated. The focus of this work is on the operative processes as they are expected to

include more standard elements of public services to describe in an ontology [Len05].

725

3.2 Use Case: Vehicle Registration Process

The characteristic elements of a public service are highlighted and exemplified with the

process of vehicle registration in Germany, described in [SPP03] and depicted in Figure 1.

Cit

izen

Cit izen

passesauthorisat ion

notepays for the

service

fetcheslicense

documentsand sealed

platespurchase ofvehicle ormove to

another town

vehiclelicensed

vehicleregistrat ion

requestgets authorisat ion

note andbill

gets licenseplates gets receipt receives

documents

Reg

istr

atio

n o

ffic

e

Cas

e o

ffic

er

Case off icer

requestsinsurance

data

recordingvehicle data

prints vehicledocumentsand sends

them to thecounter

vehiclelicense

licenseplates

receipt

registrat iondocument

vehiclelicense

data fortax off ice

data fortransportauthority

sealedlicenseplates

registrat iondocument

Pay machine

transfer ofdata to

tax off ice

transfer ofdata to

transport authority

gets registrat ionrequest

Co

un

ter

Counter

seals plates;provideslicense

documents

handlespayment

paymentreceived

receives vehicledocuments

Lice

nse

pla

tes

mak

er

createslicense plates

licenseplates

authorisat ionnote

receipt

registrat iondocumenteVB- Number

bill

authorisat ionnote

bill

input form

IT- System

ident ity cardor passport

withevidence ofresidence

Figure 1: Vehicle registration process in Germany

The vehicle registration process has a high number of cases every year. In the two biggest

registration offices in Germany, based in Berlin, 89.000 vehicles have newly been licensed

in the year 2010 [Sta11]. The main steps of this process are described in the following:

1. A citizen requests vehicle registration at the registration office using an input form

and submitting some evidence data (e.g. identity card)

2. The case officer checks the documents and evidences, handles record data and trans-

mits the record to the counter

3. The case officer transmits the record data to the transport authority

4. The case officer transmits the record data to the local tax office

5. The citizen goes to the license plates maker in order to obtain the license plates for

his vehicle

6. The citizen goes to the pay machine in the registration office in order to pay for the

service of vehicle registration

726

7. The citizen goes to the counter in order to get the sealed license plates and his license

documents

Based on some findings of the other approaches presented in Section 2 and on the main

elements of process models, shown also in corresponding example in Figure 1, the eGov-

ernement ontology will be deducted and described in the next section.

4 An Ontology for the eGovernment Domain

eGovernment is a modernisation strategy of the public sector, aiming at optimising public

services by the use of information technologies. To facilitate the improvement of un-

derlying processes, an ontology should outline the elements and interdependencies to be

considered when changing or re-engineering them. At first, a definition of an ontology is

given before presenting and explaining the eGovernment Process Knowledge Ontology.

4.1 Ontologies

Ontologies in information science are widely used to represent knowledge about a specific

domain in order to increase the interoperability and share the knowledge of systems. An

ontology as such is ’an explicit specification of a conceptualization’ containing classes,

relations, functions and other objects as the vocabulary of the domain [Gru93]. There

exists a variety of ontology concepts which can mainly be distinguished by their extent of

formality. Simple glossaries and dictionaries can be seen as an ontology as well as XML

schemas and description logics [ES07]. The domain ontology for the eGovernment sector

depicts the main elements of public services and the relations between them in order to

share knowledge about the main terms and concepts of the domain.

4.2 eGovernment Process Knowledge Ontology

The ontology for the eGovernment domain is shown in Figure 2 and is derived from the

example process of vehicle registration (see 3.2). It integrates elements of ontologies from

the literature such as the differentiation between Procedural Conditions [PT04]

and Laws [Off02, PT04, GLPT07] as regulations to the public service. In addition, the

entity Consequence is derived from the GEA model [PT04], however related to a BPM

event which can trigger new activities and services.

The ontology is modeled as UML class diagrams which originally aim at abstracting

object-oriented programs. In the eGovernment Process Knowledge ontology, the boxes

describe the entities of the domain, generalisation is expressed by triangular arrows, other

relations are displayed by arrows with description of the relation type.

727

Figure 2: eGovernment Process Knowledge Ontology

The ontology consists of the main elements public service, activity, event, roles, data,

input, output, it-system, and rules. The different elements and the interpretation of the

ontology will be explained on the vehicle registration process: The request of the public

service is done by the citizen (Request Role). To submit his request, he needs to pro-

vide several input data (Input) like evidences as his identity card (Evidence) and the

input form (Form). The evidences can be the output of another public service (Output),

for example the output of the process to obtain an identity card.

The public service itself consists of several events like the arrival of the registration re-

quest (Event) and activities like the case officers recording the vehicle data (Activity).

Events can trigger activities and inversely. An event can also be the consequence output

of another public service and as such trigger the execution of other services. The recorded

vehicle data in the registration process will for example trigger other processes at the local

tax office or the transport authority as it is transferred to them (Consequence).

The activities handle data (Data) as public services are knowledge intensive processes.

To process the data, information system can, but have not to be used (IT system).

Activities are executed by the service providing agency like the vehicle registration office

or a 3rd party provider like the license plates maker (Executing Role). The activities

and corresponding executing roles are defined by rules (Rules) which can be laws (Law)

or other mandatory administrative regulations (Procedural conditions). The reg-

istration of a vehicle is among others regulated by the national law “Straßenverkehrszulas-

sungsordnung” (StVZO) and the regional law “Straßenverkehrsrechtszuständigkeitsverord-

nung” (StVRZVO). They and their originators (Legislative Role) have to be con-

sidered whilst changing related entities in the process.

728

5 Strategies for Change and Optimisation of eGovernment Processes

The described ontology can be used as a tool for improving public services in the context

of eGovernment. It assures all related elements are considered in the change management

process and changes are propagated tp them. It is important to know - and this is the fo-

cus of this section - which other related elements need to be considered when changing

elements of a public service and which actors have to be involved in the change strategy.

First, the field of change management will briefly be introduced before outlining and eval-

uating change strategies for public services based on the presented eGovernment Process

Knowlegde ontology.

5.1 Change Management

In order to deal with organisational changes, the economic sciences use the term Change

Management. The different definitions of Change Management mostly include that it

does not handle single, urgent problem spaces, but continuous and holistic changes of

organisations and can be segmented into phases like the planning, analysis, realisation and

evaluation of the change process. The objective is to lead the organisation from a status quo

to a certain target state in order to permanently increase efficiency and effectivity [VW10,

RS10].

The fields which can cause the change demand and are affected by it are [VW10]:

• strategy: vision, mission statement, business strategy

• business culture: communication, leadership

• technology: methods, techniques

• organisation: structures, processes

As the Change Management approach was developed by economic sciences, most of

the methods and guidelines deal with business organisations. Some literature deals with

Change Management in the public sector, however it mainly focuses on the cultural and

project management aspect of changes [Bun09, NL08, BS04], which is important consid-

ering the organisational differences of the public and private sector.

Nevertheless, from an business process management point of view, the focus of changes

lies on behavioral aspects, i.e. processes and re-engineering techniques. The process level

gains importance and slowly assuming a central role in eGovernment strategies as depicted

in Section 2. The focus is rather put on the elicitation, modeling and analysis of processes

than on developing general change strategies. The next section will therefore focus on

change approaches for process improvements which will be outlined and evaluated. Ex-

amples of such changes in the eGovernment sector can be the informatisation of processes

or the establishment of standards. The areas of Change Management above mentioned

show, which other areas like the culture of an organisation have to be considered when

applying the approaches to be described.

729

5.2 Change Strategies for Public Services

In order to increase efficiency and effectivity of public services, the underlying processes

need to be optimised. Another aspect for optimisation of public service could be the

exchange of the information technologies used to deal with the existing knowledge bases,

as it is often part of eGovernment strategies. However, in general all elements included in

the presented eGovernment Ontology can be subject of a change.

Table 1 gives guidelines on which objects to consider and which actors to involve when

changing elements of public services in order to improve them and assure a consistent

change throughout all interrelated elements. The first column depicts the element which

is changed, a rule number is given in column 2 to facilitate referencing the specific change

rules. Column 3 specifies the exact type of change and the last 2 columns show the el-

ements of change (what) and the actors (whom) to consider in the change process. The

actors to be involved are also the actors that can initiate the change. Changes which can

be triggered and implemented by the process owning and executing organisation itself, are

marked with an asterisk as not all changes can be performed by an organisation itself, e.g.

the adaption of national laws.

Table 1: Change strategies

Element

to change

Change

rule

number

Change type Objects to consider Actors to consider

IT System1* Change/insert com-

plete IT System, in-

sert new workflow

features to facilitate

manual activities

Activities and events using the system,

data handled, rules regulating the data

Executing role (de-

cision maker, sys-

tem user)

2 Insert new features

for data transfer/as

interface

Activities and events to be supported (in-

cluding other public services), data han-

dled, activities and events using the sys-

tem, rules regulating the data

Executing role of

all concerned pub-

lic services (deci-

sion maker, system

user)

Data

3 Change in-

put/output data

format

IT system handling the data, activities

and events handling the data (including

other public services), rules regulating

the data

Executing role of

all concerned public

services

4* Change record data

format

IT system handling the data, activities

and events handling the data, rules reg-

ulating the data

Executing role

5* Add/remove input

data

IT system handling the data, rules regu-

lating the data, activities and events han-

dling the data

Executing role

6 Add/remove output

data

IT system handling the data, rules regu-

lating the data, activities and events han-

dling the data (including other public ser-

vices)

Executing role of

all concerned public

services

7 Change of input

data source

IT system handling the data, activities

and events handling the data, old and

new source of data

Executing role, new

source of data

Activity

8* Merge/split activi-

ties

Related events (catching/throwing), re-

lated activities, data handled

Executing role

9* Add/remove activ-

ity from a process

Related events (throwing), related activi-

ties, data handled

Executing role

10* Move activity from

one process to an-

other

If same executing role: related events

(catching/throwing), related activities,

other cases see change of executing role

Executing role

730

Element

to change

Change

rule

number

Change type Objects to consider Actors to consider

Event 11* Add/Remove event Related activities Executing role

Executing

Role

12 Change executing

role of an activity

Rules (laws/conditions) regulating the

process, activities processed by the for-

mer and the new executing role, re-

quest/receive role

Legislative role,

(Executing role if

bottom up involve-

ment)

Request/

Receive

Role

13 Change request/ re-

ceive role

Data (input/output) of public service Executing role

Rules

14 Change law regard-

ing data regulations

Related activities and events see change

of activities

Legislative role

15 Change law regard-

ing the authority of

the executing role

Executing role see change of executing

role

Legislative role

16* Change of "self-

made" regulations

(conditions)

Activities see change of activities Executing role

Applying a change rule and considering the involved objects leads to deciding whether the

objects can remain unchanged, or have to be changed, shifted to other roles or processes,

or can be removed. These operations can lead to other changes and the need to apply

other change rules. Figure 3 shows how to use the change matrix. I consists of four steps

the identification elements to change, the selection of an appropriate change type, and the

involvement of affected actor and implementation of change. In case the planned changes

trigger other change action this process needs to be repeated until all necessary changes

are performed.

Figure 3: Change workflow

6 Evaluation

To evaluate the applicability of the eGovenment Process Knowledge ontology and the

developed change strategies we picked a common change type, the support of a public

services with information systems. By introducing internet technologies citizens shall be

enabled to request public services online, in this case the vehicle registration service. In-

731

formatisation of government processes is often part of eGovernment strategies to facilitate

the use of services. This use case demonstrates the use of the change matrix outlined in

Table 1. the re-engineered process is depicted in Figure 4. The input evidence is crossed

out to show that this form document is not longer needed. The encircled elements show

newly inserted and changed elements in the process model.

Figure 4: Reengineered vehicle registration process

To achieve that citizens can request the vehicle registration online, change rule 2 needs to

be applied, addressing the insertion of new IT features as an interface for the service . The

objects to consider by this change are:

• Related activities: vehicle registration request

• Related events: gets registration request

• Data handled: eVB-Number, identity card, registration document, input form

• Rules regulating the data: data security and privacy conditions in order to process

the data via the internet

The actors to be involved are the executing role including the decision makers and system

user.

732

This change can lead to other changes, thus trigger other change rules e.g. regarding the

data handled. The input form needs to be transferred into an online form, however the

evidence data would still have to be handed over personally to the registration office. To

optimise this, the data on the identity card could also be requested by the registration office

from the residents register. This means a change of input data, thus applying change rule

7. The objects to consider by this change are:

• Related IT system: IT system to record the vehicle data

• Related activities: vehicle registration request, recording vehicle data

• Related event: gets registration request

• Data source “old”: Citizen (identity card)

• Data source “new”: Residents register

To realize this change the IT system needs the ability to request the data from the resi-

dents register. Hence a new activity to request the data from the residents register at the

registration office, needs to be inserted. A citizen does not need to submit his identity card

anymore with the registration request facilitating parts of the process. However, to fully

provide online service delivery also the other evidence data like the registration document

and the eVB-Number would have to be considered and other change rules would have to

be applied.

In this example one can easily see the complexity of changing and improving public ser-

vices and the impact of the change of one element of a public service has to its related el-

ements. Equivalently, the applicability of the eGovernment Process Knowledge ontology

on this real use case and the easy use of the corresponding change matrix were demon-

strated. The user of the ontology with the change matrix has a concrete guideline on how to

approach changes in the public service delivery, on who to involve, and how to implement

such changes in a consistent way.

7 Conclusion

This paper introduced an eGovernment Process Knowledge Ontology that relates the key

elements of public services to business process elements. The main characteristics of pub-

lic services compared to processes in the private sector were presented. Public services are

highly regulated and determined by several actors, laws and inter-process dependencies

that introduces a high complexity into optimisation efforts. The ontology describes con-

crete interdependencies between public service and business process elements providing

the basis for the development of coherent change strategies. The presented change strate-

gies offer a concrete guideline about the handling of affected objects, actors to involve,

and a consistent workflow in the change process.

Although the change matrix was tested on several process change examples, from which

one was shown in the Section 6, it should be validated and tested for completeness with

733

other life situations, public services, and process types. This could involve an analysis

of public services from other countries, as this work was mainly based on data from the

German public administration. Other process types could require further refinement and

extension of the ontology. In addition, domain experts could be involved to check the

change matrix regarding the objects and actors to consider for further validation. Future

work will deal with the refinement of the eGovernment Process Knowledge ontology and

the corresponding change matrix.

References

[BS04] Eugen Baacke and Welf Schröter, editors. Umbau zur Dienstleistungskommune. Tal-heimer, 2004.

[Bun09] Bundesministerium des Innern, editor. Change Management: Anwendungshilfe zuVeränderungsprozessen in der öffentlichen Verwaltung. Bundesministerium des Innern,2009.

[DVR11] R M Dijkman, I Vanderfeesten, and H A Reijers. The Road to a Business ProcessArchitecture: An Overview of Approaches and their Use. BETA Working Paper WP-350, Eindhoven University of Technology, The Netherlands, 2011.

[ES07] Jérôme Euzenat and Pavel Shvaiko. Ontology Matching. Springer-Verlag, 2007.

[ESDW12] Rami-Habib Eid-Sabbagh, Remco M. Dijkman, and Mathias Weske. Business ProcessArchitecture: Use and Correctness. In BPM, volume 7481 of LNCS, pages 65–81.Springer, 2012.

[GLPT07] Sotirios K. Goudos, Nikos Loutas, Vassilios Peristeras, and Konstantinos A. Tarabanis.Public Administration Domain Ontology for a Semantic Web Services EGovernmentFramework. In IEEE SCC, pages 270–277. IEEE Computer Society, 2007.

[Gru93] Thomas R. Gruber. A Translation Approach to Portable Ontology Specifications.Knowledge Acquisition, 5(2):199–220, 1993.

[Len05] Klaus Lenk. Vielfalt der Geschäftsprozesse in der öffentlichen Verwaltung. In RalfKlischewski and Maria Wimmer, editors, Wissensbasiertes Prozessmanagement im E-Government, E-Government und die Erneuerung des öffentlichen Sektors, pages 43–55.LIT Verlag, 2005.

[LT01] Klaus Lenk and Roland Traunmüller. Electronic Government - ein Wegweiser. Com-puter kommunikativ, (4):15–18, 2001.

[NL08] Rüdiger Nolte and Sven Max Litzcke. Change Management: Theorie und Praxis. Fach-hochschule des Bundes für öffentliche Verwaltung, 2008.

[Off02] Cabinet Office Office of the e-Envoy. e-Services Development Framework Primer,2002.

[OJE07] Adegboyega Ojo, Tomasz Janowski, and Elsa Estevez. Domain Models and EnterpriseApplication Framework for Developing Electronic Public Services. UNU-IIST Report,(369), April 2007.

734

[PT04] Vassilios Peristeras and Konstantinos A. Tarabanis. Advancing the Government Enter-prise Architecture - GEA: The Service Execution Object Model. Electronic Govern-ment, pages 476–482, 2004.

[RS10] Susanne Rank and Rita Scheinpflug, editors. Change Management in der Praxis.Beispiele, Methoden, Instrumente. Erich Schmidt Verlag, 2010.

[SASS04] Ljiljana Stojanovic, Andreas Abecker, Nenad Stojanovic, and Rudi Studer. On manag-ing changes in the ontology-based e-government. In In Proceedings of the 3rd Interna-tional Conference on Ontologies, Databases and Application of Semantics (ODBASE2004), number 3291 in Lecture, pages 1080–1097. Springer Verlag, 2004.

[SPP03] Tino Schuppan and Jörg Penning-Poggenbeck. eGovernment im Kfz-Zulassungswesen.KWI-Projektberichte 2, 2003.

[Sta11] Statistisches Bundesamt, editor. Einfacher zur Fahrzeugzulassung. Eine Erhebung ver-schiedener Pilotverfahren im Deutschland-Online-Vorhaben "‘Kfz-Wesen"‘. Statistis-ches Bundesamt, September 2011.

[VL07] Costas Vassilakis and George Lepouras. An Ontology for e-Government Public Ser-vices, 2007.

[VW10] Dietmar Vahs and Achim Weiand. Workbook Change Management: Methoden undTechniken. Schäffer-Poeschel, 2010.

[Wes12] Mathias Weske. Business Process Management, Concepts, Languages, Architectures.Springer-Verlag, second edition edition, 2012.

735