Referenzmodellierung für E-Government-Services; Reference modelling for E-Government Services;

1 Motivation

Obwohl Gemeinden nahezu identischeDienstleistungen erbringen, erfolgt derenUmsetzung individuell und immer wiederneu. Der relativ hohe Aufwand, haufig ver-bunden mit betrachtlichen Investitionenzum Aufbau der erforderlichen IT-Infra-struktur, der fur die Realisierung vonE-Government-Dienstleistungen zu leistenist, und gleichzeitig der als (immer noch)gering erachtete Nutzen haben dazu ge-fuhrt, dass die Umsetzung von E-Govern-ment nur langsam und noch nicht flachen-deckend voran geht [Weil04]. So schreibtJurg Romer, der Prasident von eCH (sieheAbschnitt 3.2) in [Rome05a]: „Es gibt

mehrere Grunde, warum die Schweiz ime-Government [. . .] in einigen nationalenVergleichen hintere und hinterste Range[belegt], in keiner mir bekannten Studiesteht sie ,auf dem Podest‘. FragmentierteFoderalismusstrukturen fuhren zu kompli-zierten und uneinheitlichen Prozessen [. . .]Ein weiteres Hindernis fur die rasche,durchgehende, umfassende und kosten-gunstige Ausbreitung elektronisch aus-getauschter Daten und elektronisch vermit-telter Dienstleistungen sind aber auchfehlende Standards.“Die Schweizerische Bundesverwaltung

geht im Rahmen eines Forschungsprojektsneue Wege, indem sie zusatzlich zur akti-ven Mitarbeit in der Entwicklung vonStandards (z. B. zur Forderung der Inter-operabilitat) Referenzmodelle fur E-Go-vernment-Services entwickelt, die von Ge-meinden und Kantonen direkt genutztoder als Basis fur individuelle Anpassungenverwendet werden konnen. Durch die Vor-

gabe dieser Referenzmodelle aber auchdurch die Bereitstellung von transaktions-orientierten Webservices soll bei den Ge-meinden der Aufwand fur die informati-onstechnische Realisierung individueller,gemeindespezifischer Web-Applikationenmarkant gesenkt werden. Daruber hinausermoglicht die nachfolgend vorgestellteArt der Referenzmodellierung die Anpas-sung von Prozessen, z. B. aufgrund neuergesetzlicher Regelungen, indem �nderun-gen der Referenzmodelle in den Gemein-den automatisiert nachgefuhrt werdenkonnen.Zunachst wird in Kapitel 2 das EU-Pro-

jekt OntoGov vorgestellt, in dessen Rah-men die Entwicklung und praktische Ver-wendung von Referenzmodellen furE-Goverment-Services erfolgt. Anschlie-ßend gibt Kapitel 3 einen �berblick uberden Stand der Referenzmodellierung undder E-Government-Initiativen in derSchweiz. Kapitel 4 beschreibt das Vor-

WIRTSCHAFTSINFORMATIK 47 (2005) 5, S. 356–366

Die Autoren

Knut HinkelmannBarbara ThonssenFabian Probst

Prof. Dr. Knut HinkelmannBarbara ThonssenFabian ProbstFachhochschule SolothurnNordwestschweizInstitut fur Management undWirtschaftsinformatik (IMI)Riggenbachstraße 164600 Olten{knut.hinkelmann | barbara.thoenssen |fabian.probst}@fhso.chhttp://www.fhso.ch

Referenzmodellierungf�r E-Government-Services

Kernpunkte

Unter Referenzmodellierung versteht man die Konstruktion und Anwendung wiederver-wendbarer Modelle. E-Government ist fur die Referenzmodellierung besonders geeignet, daGemeinden nahezu identische, auf denselben rechtlichen Grundlagen bestehende Dienst-leistungen erbringen. Die vorliegende Arbeit zeigt eine Methode zur Modellierung, Verwal-tung und Anpassung von Referenzmodellen im Kontext der offentlichen Verwaltung:

& Referenzmodelle erlauben die gemeindeunabhangige Modellierung von E-Government-Services.

& Alle Entscheidungen bei der gemeindespezifischen Anpassung von Referenzmodellenwerden dokumentiert und mit Begrundungen hinterlegt.

& Notwendige �nderungen an den Referenzprozessmodellen konnen erkannt und an allevon diesen abgeleiteten Modelle kommuniziert werden.

Stichworte: Referenzmodellierung, E-Government, Webservices, Ontologien, Spezialisie-rung von Referenzmodellen

WI – Schwerpunktaufsatz

gehen, das fur die Entwicklung der Refe-renzmodelle gewahlt wurde. Im nachfol-genden Kapitel 5 wird aufgezeigt, wie dieAbhangigkeiten zwischen den Referenz-modellen erfasst werden und Kapitel 6erlautert, wie diese Informationen fur dieErkennung und Auswertung von �nde-rungen genutzt werden konnen. In Kapitel7 wird die technische Implementierung desLosungsansatzes vorgestellt. Kapitel 8 gibteinen Ausblick auf die weitere Arbeit.Die Funktionsweise des Ansatzes wird

anhand des durchgangigen Fallbeispiels„Umzugsprozess“ verdeutlicht.

2 OntoGov

OntoGov (Ontology-enabled e-Gov Ser-vice Configuration) ist ein durch die EUim Rahmen des Information Society Tech-nologies (IST)-Programms gefordertesForschungsprojekt (IST-507237, http://www.ontogov.com). Das Projekt verfolgtdas Ziel, ein Framework fur die Entwick-lung, die Adaption, den Betrieb und dieVerbreitung von E-Government-Serviceszu schaffen und im Rahmen einer Pilot-Anwendung umzusetzen [AAHP04]:& Entwicklung: Design-Entscheidungen,

welche die Entwicklung von E-Govern-ment-Services beeinflussen, sollen trans-parent und explizit aufgezeigt werden.Dabei soll der gesamte Lebenszykluseines E-Government-Services von derEntstehung bis zur Ablosung durcheinen neuen Service dokumentiert wer-den.

& Adaption: Durch die explizite Doku-mentation aller Design-Entscheidungensollen im Fall einer Gesetzesanderungdie betroffenen Prozesse und Prozess-schritte identifiziert werden konnen.

& Durchgangigkeit: Dienstleistungen vonunterschiedlichen Behorden (und Dritt-Firmen) sollen fur den E-Government-Nutzer transparent angeboten werden(„One-Stop-Shop“).

& Betrieb: Die entwickelten Services sol-len auf der Basis semantischer Beschrei-bungen (Ontologien) zur Laufzeit zuProzessen zusammengestellt und aus-gefuhrt werden.

& Verbreitung: Die formale Beschreibungsowie das Management von Services solldie Verbreitung und Wiederverwendungvon Services und des zugrunde liegen-den Wissens erlauben.

Als Partner des Konsortiums ubernimmtdie Schweizerische Bundeskanzlei eine ak-tive Rolle bei der Umsetzung des Projek-

tes. Ihr Ziel ist es, das Angebot von E-Go-vernment-Services auf allen Ebenen deroffentlichen Verwaltungen quantitativ undqualitativ zu verbessern, sowie die Kostenfur Erstellung und Wartung zu senken.Dies soll erreicht werden, indem die Bun-deskanzlei& Referenzmodelle fur E-Government-

Services erstellt und anbietet,& dafur benotigte wiederverwendbare

Webservices entwickelt,& den Gemeinden diese Services zur Nut-

zung zur Verfugung stellt,& die Durchgangigkeit von verwaltungs-

ubergreifenden Dienstleistungen ge-wahrleistet (z. B. durch die Realisierungvon „One-Stop-Services“)

& und auch Nicht-Verwaltungsorganisa-tionen mit einbindet.

Referenzmodelle sind die Grundlage fureine modellgetriebene Entwicklung, Ver-breitung und Adaption von E-Govern-ment-Services durch die Bundeskanzlei. Siesollen dazu genutzt werden, Prozesse unddas damit verbundene Wissen explizit undfur die Verwaltungen verfugbar zu machen.Die nachfolgenden Ausfuhrungen konzen-trieren sich auf diesen Punkt und zeigendie in OntoGov gewahlte Methode zur Er-stellung der Referenzprozessmodelle, zumFesthalten von Abhangigkeiten zwischenModellen und zum Erkennen und Aus-werten von �nderungen. Die Operationa-lisierung der ubrigen Ziele wird in diesemArtikel nicht in der Tiefe behandelt.

3 Ausgangslage

Unter Referenzmodellierung versteht mandie Konstruktion und Anwendung wieder-verwendbarer Modelle (Referenzmodelle)[BrBu04; FeLo04]. Da Verwaltungen – imGegensatz zu Firmen – keinen Kon-kurrenzvorteil wahren mussen und ihreProzesse auf denselben rechtlichen Grund-lagen basieren, sind E-Government-Ser-vices fur Referenzmodelle besonders ge-eignet. Dennoch gibt es relativ wenigInitiativen fur die konkrete Anwendungvon Referenzmodellen fur Verwaltungs-prozesse.

3.1 Referenzmodellierung vonVerwaltungsprozessen

Im Rahmen von „eLoGo“, einem Projektdes Kommunalwissenschaftlichen Institutsder Universitat Potsdam, wurden drei eigen-standige Referenzmodelle fur die Prozess-,

die Anforderungs- und die Architektur-Ebene entwickelt, welche die Abhangigkei-ten zwischen Verwaltungsprozessen und In-formationstechnik auf unterschiedlichenEbenen beschreiben [OfHo04]. ThomasOff hat die Ergebnisse von „eLoGo“weiter-entwickelt und einen Standardisierungspro-zess beim Deutschen Institut fur Normungeingereicht. In Bezug auf den im vorliegen-den Artikel diskutierten Ansatz ist vor allemder Zusammenhang zwischen dem ideal-typischen eLoGo-Referenzprozessmodellund der Konkretisierung der Prozesssichtuber das Referenzanforderungsmodell inte-ressant. Die dazu erarbeitete Methode ent-halt Anleitungen und Regeln fur das „Tai-loring“ abstrakter Referenzmodelle zu kon-kreten Anwendungsmodellen.

Ziel des Projekts „RAfEG“ (das vomBMBF im Rahmen der Softwareinitiative2006 geforderte Projekt lauft zunachst bisEnde 2005, siehe unter http://www.rafeg.de)ist die Entwicklung einer „Referenzarchi-tektur E-Government“ mit Hilfe derer An-wendungssoftware fur transaktionsorien-tierte E-Government-Dienstleistungen rea-lisiert werden kann. Gegenstand desPilotprojekts ist die Abbildung der Prozes-se fur das Planfeststellungsverfahren. Dieim Rahmen des Projekts erarbeiteten Pro-zessmodelle werden mit Hilfe des ARISToolsets modelliert und dokumentiert[SMRV04].

Weder mit „eLoGo“ noch mit „RAfEG“kann jedoch das dokumentierte Wissenuber die Prozessmodellierung und die Ab-leitung der Referenzmodelle automatischausgewertet und aktiv genutzt werden.

3.2 Staatliche Initiativen

In der Schweiz sind auf staatlicher EbeneBestrebungen im Gange, E-Governmentauf Basis von Standards und Best Practi-ces voranzutreiben. Mit der Initiative„eVanti“ (http://www.evanti.ch) verfolgtdas Informatikstrategieorgan Bund (ISB)das Ziel, den Informations- und Erfah-rungsaustausch zwischen Behorden zufordern und dadurch die Zahl realisierterE-Government-Anwendungen zu erho-hen. Das Hauptinstrument der eVanti-Plattform ist ein Portfolio, eine Datenbankmit Beschreibungen zu erfolgreich reali-sierten E-Government-Anwendungen undInformationen zu deren Entwicklung. Beider eVanti-Initiative steht der Gedanke derWiederverwendung von Wissen uber Rea-lisierungen von eGovernment-Dienstleis-tungen im Vordergrund. Dieses Wissenwird aber weder generalisiert noch als for-males Model reprasentiert.


Referenzmodellierung fur E-Government-Services 357

Zudem wird die Verbreitung von E-Gov-ernment-Anwendungen durch die vomBund geforderte Organisation eCH (http://www.ech.ch) unterstutzt. Der Verein defi-niert unverbindliche Richtlinien zur Verbes-serung der Zusammenarbeit auf der Basisvon Musterprozessen und Datenstandards.Der Ansatz von eCH kommt dem Gedan-ken der Referenzmodellierung schon rechtnahe, da sowohl Datenmodelle wie auchMusterprozesse in einer formalen Notationdefiniert werden. Durch die Verwendungvon XML-Schema-Definitionen ist bei denDatenmodellen auch eine Ableitung inForm einer Instanziierung [Broc03] vor-handen. Im Gegensatz dazu werden Mus-terprozesse lediglich dokumentiert undkonnen nicht fur eine aktive Ableitung ver-wendet werden.

3.3 Beitrag von OntoGov

Mit OntoGov sollen gemeindeunabhangigeReferenzprozessmodelle fur E-Govern-ment-Services erstellt werden, die gemein-despezifisch angepasst werden konnen undsomit einen wesentlichen Beitrag zu einem„eGovernment im Stil des 21. Jahrhun-derts“ [Rome05b] leisten. Im Zentrum stehtdabei die Dokumentation der fur die Mo-dellierung relevanten Entscheidungen undderen Begrundungen, die Nachvollziehbar-keit von Ableitungen neuer Versionen derModelle sowie das teilautomatisierte Er-kennen und Auswerten von�nderungen.Aufgrund der ausgepragten Foderalis-

musstruktur ist die Adaptierbarkeit vonReferenzprozessmodellen unabdingbar furderen Akzeptanz bei Kantonen und Ge-meinden. Gleichzeitig mussen diese Anpas-sungen aber so dokumentiert werden, dasssie bei Veranderungen der ursprunglichenReferenzprozessmodelle automatisch er-kannt und nachgefuhrt werden konnen.

4 Erstellung von Referenz-prozessmodellen

Obwohl es keine bundesweiten Produkt-definitionen gibt, lassen sich die von denVerwaltungen zu erbringenden Dienstleis-tungen doch verallgemeinern. Zum einenbasieren samtliche von Behorden erbrachteDienstleistungen auf rechtlichen Bestim-mungen, wodurch eine Standardisierungder Prozesse auf einem gewissen Abstrak-tionsniveau gegeben ist. Weiterhin ist dergenerelle Ablauf von Prozessen, z. B. dereines Umzugs, im Wesentlichen uberallgleich: Abmeldung in der Wohngemeinde,

ggf. Information an den zustandigen Kan-ton (z. B. wenn es sich um einen auslandi-schen Einwohner handelt), Informationder Zuzugsgemeinde uber die Abmeldung,Anmeldung in der Zuzugsgemeinde undwiederum bei Bedarf Information des Kan-tons.Neben den Referenzmodellen selbst

wird mit OntoGov Wissen uber den Vor-gang der Prozessgestaltung verwaltet. Da-bei wird unterschieden zwischen Funk-tionswissen, das fur die Prozessbearbeitungbenotigt wird, und Prozesswissen, das In-formationen uber die Prozessgestaltungbeschreibt [HiKT02; NaSc02]. Dieses Pro-zesswissen und die damit verbundenenEntscheidungen werden haufig nicht oderunzureichend dokumentiert.Im Hinblick auf die Erstellung von Re-

ferenzmodellen kommt dem Prozesswissenbesondere Bedeutung zu: Entscheidungen,die zur Spezialisierung eines Referenzmo-dells fuhren, sollen jederzeit nachvollzogenwerden konnen und Entscheidungsgrund-lagen (z. B. rechtliche Bestimmungen) sol-len vollstandig transparent sein. Um dieszu erreichen, wird mit OntoGov Funk-tions- und Prozesswissen explizit gemacht,indem Prozesselementen die sie begrun-denden Entscheidungen zugeordnet wer-den. Dadurch konnen im Fall von Ver-anderungen die betroffenen Prozesseautomatisch identifiziert und zur �berpru-fung vorgeschlagen werden. Dies wieder-um bietet die Chance, die Zeit fur die Um-setzung der �nderung zu reduzieren.

4.1 Modellierung von Referenz-prozessen

Bild 1 zeigt das Referenzprozessmodell alsAktivitatsdiagramm in UML2-Notation.Diese wurde aufrund des großen Bekannt-heitsgrads von UML gewahlt. In OntoGovselbst wird eine eigene, projektspezifischeNotation verwendet (vgl. dazu Abschnitt7). Die Referenzmodelle sind in Englisch,da sie im Rahmen eines EU-Projekts er-stellt wurden. Vor der Einfuhrung mussensie in die Landessprachen deutsch, franzo-sisch und italienisch ubersetzt werden.Der Prozess beginnt mit dem Ausfullen

eines elektronischen Formulars (Fill in Ap-plication for Move). Anschließend werdendie Angaben uberpruft, wobei zwischender �berprufung von Standardangaben(Check Application) und Zusatzangaben(Check Application Extension) unterschie-den wird. Sind die Angaben korrekt, wirdder Antrag ausgelost (Commit). Die Akti-vitaten zur Weiterleitung der Informatio-nen an die zustandigen Behorden und den

Antragsteller (Provide Information of Ap-plication) sind Subprozesse, die wiederumals Referenzprozesse in einem separatenModell erstellt wurden.

4.2 Hierarchie von Referenz-modellen

Referenzmodelle sind Muster fur konkreteProzesse einer Behorde (z. B. „Antrag aufAbmeldung von naturlichen Personen“,„Antrag auf Erteilung einer Anliegerpark-erlaubnis“, „Antrag auf Bewilligung einerHundezucht“). Sie beschreiben – gemein-deunabhangig – den Bearbeitungsfluss, diedazu notwendigen Aktivitaten sowie diedafur maßgeblichen gesetzlichen Regelun-gen. Diese Art von Referenzmodellen wirdim Folgenden als Referenz1Prozessmodelle(R1PM) oder auch Basis-Referenzmodellebezeichnet.Aufgrund der foderalen Struktur der

Schweiz konnen die Kantone spezifischeRegelungen treffen, die zu Anpassungender Prozesse fuhren. Die kantonsspezi-fischen Referenzmodelle stimmen weit-gehend uberein und unterscheiden sich nurgeringfugig. Referenz1Prozessmodelle, diedie Gemeinsamkeiten der Modelle im Sin-ne einer Generalisierung reprasentieren,konnen uber mehrere Ebenen weiter spe-zialisiert werden z. B. hinsichtlich kantona-ler oder gemeindespezifischer Bedurfnisse.Diese abgeleiteten Referenzprozessmodellewerden Referenz2Prozessmodelle (R2PM)genannt.Umgekehrt konnen Referenzprozesse

zu generischen Prozessen wie z. B. „An-trag stellen“, „Status prufen“ oder „In-formation erteilen“ abstrahiert werden.Diese werden als Referenz0Prozessmodelle(R0PM) bezeichnet.Das OntoGov-Framework verwaltet ex-

plizit wie sich die Prozesse der Prozesshie-rarchie unterscheiden, so dass �nderungender abstrakten Modelle auf die jeweiligenSpezialisierungen ubertragen werden kon-nen.

4.3 Vorgehen

Fur die Erstellung von Basis-Referenzmo-dellen werden konkrete Prozesse (z. B.„Antrag auf Abmeldung von einer Gemein-de“) verschiedener Gemeinden analysiertund anschließend generalisiert. GemeinsameMerkmale der Prozesse werden hierbei ineinem ubergreifenden Basis-Referenzmo-dell zusammengefuhrt, indem Aktivitatenentweder als alternative Verzweigungenmodelliert oder unter Verwendung von abs-


358 Knut Hinkelmann, Barbara Thonssen, Fabian Probst

trakteren Prozessschritten generalisiertwerden [RuGT99, 228]. Ziel ist es, ein Pro-zessmodell zu erstellen, das gemeindeun-abhangig verwendet werden kann.

Von diesen Basis-Referenzmodellen(z. B. R1PM_A) werden durch inhaltlicheAbstraktion resp. Spezialisierung verschie-dene Ebenen von Referenzmodellen abge-leitet:& Abstraktion: Bildung von verallgemei-

nerten Referenzprozessmodellen (z. B.„Abwicklung eines Antrags“) mit demZiel, allgemeingultige Prozessmodellefur die vereinfachte Erstellung von Ba-sis-Referenzmodellen bereitzustellen.

& Spezialisierung: Bildung von gemeinde-abhangigen Referenzprozessmodellen(z. B. „Antrag auf Abmeldung von na-turlichen Personen in der Gemeinde Ol-ten“) mit dem Ziel, ausfuhrbare Prozess-modelle zu erstellen.

Bild 3 illustriert das Vorgehen. Die Zusam-menhange und Abhangigkeiten zwischenden einzelnen Referenzprozessmodellenwerden in Kapitel 5 beschrieben.Referenzprozessmodelle einer Ebene ha-

ben immer nur ein Referenzprozessmodellauf der nachsten Abstraktionsstufe. Sokonnen die ReferenzprozessmodelleR2PM_IAa und R2PM_IAb ausschließlichzu Referenzprozessmodell R1PM_IAabstrahiert werden, die Referenzprozess-modelle R1PM_IA und R1PM_IB aus-schließlich zu R0PM_I. Diese Einschran-kung wurde gemacht um die Komplexitat– vor allem im Hinblick auf die teilautoma-tisierte Nachfuhrung von spezialisiertenReferenzprozessmodellen – zu reduzieren(vgl. Kapitel 5).

4.4 Abstraktion

Bild 4 zeigt den generischen (Sub-)Prozessfur die Einreichung eines Antrags (Refe-renz0Prozessmodell: R0PM_FAA). Datenwerden eingegeben (Fill in Application),auf Vollstandigkeit und Richtigkeit gepruft(Check Application) und beim Auslosendes Antrags (Commit) gespeichert.Referenz0Prozessmodelle konnen neben

dem eigentlichen Prozessmodell weiteregenerell gultige Rahmenbedingungen wiegesetzliche Regelungen oder organisatori-sche Angaben, z. B. uber notwendigeRessourcen, umfassen. So bildet das ZivileGesetzbuch die Grundlage fur die Behand-lung von Antragen, gleich welcher Art.

4.5 Spezialisierung

Jedes Referenzprozessmodell kann weiterspezialisiert werden. So konnen von einem

generischen Referenzprozessmodell (z. B.von „R0PM Antrag stellen“) mehrere Refe-renzprozessmodelle (z. B. „R1PM Antragauf Erteilung einer Anliegerparkerlaubnis“oder „R1PM Antrag auf Abmeldung in ei-ner Gemeinde“) abgeleitet werden. Letzte-res wiederum kann zu „R2PM Antrag aufAbmeldung in Olten“ spezialisiert werden.

Die Spezialisierung von Referenzpro-zessmodellen ist wie folgt moglich:& Reduktion: Aktivitaten oder Sub-Pro-

zesse werden entfernt& Erweiterung: Zusatzliche Aktivitaten

oder Sub-Prozesse werden eingefugt& Ersetzung: Eine Aktivitat wird durch

eine andere ersetzt, wobei der Prozess-fluss nicht geandert wird.

Die nachfolgende Grafik zeigt die Speziali-sierung am bereits eingefuhrten Beispiel„Antrag auf Abmeldung in einer Gemein-de“ (R1PM_FAFM File an Application forMove) zu „Antrag auf Abmeldung in Ol-ten“ (R1PM_FAFM File an Application forMove in Olten).

Die erste �nderung fur R2PM betrifftden Service FillInApplicationForMove. Erwird ersetzt (1) durch die gemeindespezi-fische Aktivitat FillInApplicationFor-MoveInOlten, eine gemeindespezifischeImplementierung mit Anbindung an dieVerwaltungssoftware. Die zweite �nde-rung betrifft die Aktivitat CheckAppli-cationExtension, sie wird geloscht (2). Diedritte �nderung fugt eine zusatzliche Akti-vitat UploadDocs ein (3).


Bild 1 R1PM File an Application for Move: Antrag auf Abmeldung bei einer Gemeinde

Commit

CheckApplication

R1PM_FAFM (File an Application for Move)

[ContentNOK]

[noExtension]

Key:

eGov-WS

eGov Form :Upload Documents

CheckApplicationExtension

eGov Form:ExtensionApplicationForMoveP A-2-deregister

[ContentOK;]

Fill inApplicationfor Move

eGov Form:ExtensionApplicationFor

MoveP A-2-register<<pre-condition>>{additional informationis needed}

<<pre-condition>>{already filled ininformation isdisplayed}

error message

[Extension]

CheckApplication_AFM

eGov Form:ApplicationForMove

ProvideInformation Of

Application

application data /Process-ID

Sub Process

<<note>>{PAs responsible for(de)registration}

ProvideInformation OfApplication

<<note>>{citizens‘ notification}



Jede Spezialisierung des Referenzmo-dells wird aus Grunden der Nachvollzieh-barkeit explizit festgehalten (siehe Kapitel5). Je großer allerdings der Grad der Veran-derung ist, desto schwieriger wird es, diese�nderungen automatisch auszuwerten (sie-he Kapitel 6).

5 Abhangigkeiten vonReferenzprozessmodellen

Die Abhangigkeiten zwischen Referenz-prozessmodellen werden in Form von De-sign-Entscheidungen (Design Decisons)

festgehalten. Dabei wird nicht nur dieSpezialisierung sondern auch die Versio-nierung von Referenzprozessmodellendokumentiert. Fur die Modellierung vonVeranderungen an den Prozessmodellenwerden drei Arten von Design-Entschei-dungen unterschieden:& Delete-Design Decision fur das Lo-

schen einer Aktivitat! Reduktion& Add-Design Decision fur das Hinzufu-

gen einer neuer Aktivitiat ! Erweite-rung

& Replace-Design Decision fur das Aus-tauschen einer Aktivitat! Ersetzung

Bild 6 zeigt die schematische Darstellungder Abhangigkeiten zwischen Referenz-prozessmodellen, resp. die den �nderun-gen zu Grunde liegenden Entscheidungen.Gangige Modellierungsmethoden be-

trachten Prozesse nicht isoliert, sondernlassen verschiedene Sichten auf einen Pro-zess zu, die jeweils in einem eigenen Mo-dell reprasentiert werden. Eine der bekann-testen Methoden ist ARIS (Architekturintegrierter Informationssysteme) [Sche95]welche Daten, Organisation und Funktio-nen eines Unternehmens in ein Prozess-modell integriert. Die BPMS-Methodolo-gie [Kara95] unterscheidet Prozesse,Organisationsstruktur, Ressourcen undDaten/Dokumente.Diese Herangehensweise wird auch im

vorliegenden Ansatz verfolgt. Da alle Ver-waltungsprozesse einer gesetzlichenGrundlage bedurfen, ist fur die Reprasen-tation der Gesetze und Regelungen ein ei-genes Modell vorgesehen, so dass die fol-genden Modelltypen fur die integrierteProzessmodellierung verwendet werden:& Prozess& Organisation& Daten& Technik (unter diesem Begriff wird hier

die IT-Systemlandschaft einer Organisa-tion verstanden, die die Umsetzung vonProzessen beeinflusst)

& Gesetze/RegelungenSamtliche Entscheidungen, die zur Speziali-sierung oder Versionierung von Referenz-prozessmodellen fuhren, mussen begrundetwerden. Dabei gilt, dass jeder Design-Ent-scheidung mindestens eine Begrundung(Reason) zugeordnet wird (in der prakti-schen Anwendung konnen Entscheidungengruppiert werden; die ganze Gruppe mussdann lediglich durch einen „Reason“ be-grundet werden). Entsprechend der ver-schiedenen Sichten werden die Begrundun-gen fur Design-Entscheidungen in vierKategorien untergliedert, die entscheidendfur die Spezialisierung von Referenzpro-zessmodellen sind:


R1PM_IA

R2PM_IAa

R0PM_I

R1PM_IB

R2PM_IBaR2PM_IAb R2PM_IBb

Abstraktion / Spezialisierung

Abstraktion / Spezialisierung Abstraktion / Spezialisierung

Bild 2 Generalisierung von Referenzprozessmodellen

Prozess_1GemeindeA

Prozess_1GemeindeB

Prozess_1GemeindeX

Prozess_n Prozess_n Prozess_n

Generalisierung

R1PM_A

Bild 3 Ableitungen von Referenzprozessmodellen


& Legal-based Reason: Nahezu alle Pro-zesse offentlicher Verwaltungen basierenauf gesetzlichen Grundlagen oder davonabgeleiteten Verordnungen. Somit sindauch solche Regelungen fur das Designeines Prozesses bestimmend. Beispiels-weise erfordert die Gewaltentrennung,dass ausgewahlte Prozesse durch ver-schiedene behordliche und politischeInstanzen bearbeitet werden.

& Organisational-based Reason: Die Artwie eine Verwaltung strukturiert ist, inwelche Organisationseinheiten sie unter-teilt ist und welche Aufgaben von wel-chen Bereichen erledigt werden, beein-flusst in hohem Maß die Gliederungeines Prozesses. Werden Aufgaben bei-spielsweise von zwei unterschiedlichenOrganisationseinheiten ausgefuhrt, sowird diese Aufgabe durch zwei Aktivi-taten modelliert.

& Data-based Reason: Auch die zu ver-arbeitenden Daten und der Informati-onsfluss konnen Auswirkungen auf dasProzessmodell haben. Werden z. B. ineiner Aktivitat Daten benotigt, die wah-rend des Prozesses ermittelt werden, sokann sich daraus eine gewisse Reihenfol-ge der Aktivitaten ergeben.

& Technical-based Reason: Nicht nur or-ganisatorische oder rechtliche Vorgabenbestimmen das Design eines Prozessessondern auch die Technik. So kann eineDatenvalidierung – z. B. aus Grundender Sicherheit – in zwei getrennten Pro-zessschritten erfolgen (z. B. auf einemWeb-Server das �berprufen auf Voll-standigkeit obligatorisch einzugebenderDaten und in einer internen Verwal-tungssoftware die �berprufung der Per-sonendaten).

Eine Begrundung enthalt eine Beschrei-bung in naturlicher Sprache und einen for-malen Verweis auf die der Entscheidungzugrunde liegenden Elemente aus den ent-sprechenden Modellen. Beispielsweise wirdbei einer „Legal-based Reason“ ein Ver-weis auf die relevanten Gesetzesartikel fest-gehalten.Die Verknupfung von Design-Entschei-

dungen und Begrundungen geschieht inOntoGov unter Verwendung eines Life-cycle-Modells, in dem die Grunde fur dieModellierungsentscheide explizit model-liert werden. Das Modell basiert auf demIBIS-Ansatz (Issue Based Information Sys-tem, [KuRi70]). IBIS geht von einemThemaaus, zu dem verschiedene Positionen einge-nommen werden konnen. Diese Positionenwerden durch mehrere Argumente begrun-det. In Analogie zu IBIS wird in OntoGoveine Design-Entscheidung, unabhangig da-

von ob sie in einem Prozessmodell oder ineinem anderen Modell getroffen wurde, alsThema betrachtet, das durch andere De-sign-Entscheidungen oder durch die o. g.Aspekte begrundet wird. Da Entscheidun-gen wiederum durch andere Design-Ent-scheidungen begrundet werden konnen, er-gibt sich eine Argumentationskette. Bild 7zeigt den Aufbau einer Argumentations-kette in Anlehnung an die graphische Nota-tion gIBIS [CoBe98, 140–152].Neben der naturlichsprachigen Doku-

mentation ist es fur eine wissensbasierteUnterstutzung unerlasslich, die Design-Entscheidungen auch formal zu beschrei-ben [RuGT99, 231]. In diesem Ansatz wirddas Prozesswissen festgehalten, indem dasProzessmodell mit den genanntenModellen(Prozess, Organisation, Daten, Technik,Gesetze/Regelungen) formal verknupftwird. Dadurch werden Design-Entschei-dungen und Begrundungen, welche dieReferenzmodelle bestimmen, transparentund nachvollziehbar.Angenommen, die gesetzliche Grundlage

„BGB, Artikel 0815, Absatz 1“ regelt dieunterschiedlichen Zustandigkeiten vonzwei offentlichen Verwaltungen, so kanndieser Gesetzestext als Begrundung fur dieDesign-Entscheidung, zwei Aktivitaten ge-trennt voneinander zumodellieren, betrach-

tet werden. Die Design-Entscheidung wirdhierbei direkt mit den betroffenen Aktivita-ten verknupft und die Begrundung fur dieseEntscheidung liefert der Verweis auf denentsprechenden Artikel imModell Gesetze/Regelungen. Die konkrete Umsetzung wirdinAbschnitt 7 imDetail erlautert.

6 Erkennen und Auswertenvon �nderungen

Im Fall einer �nderung, z. B. eines Geset-zes, werden zunachst samtliche von der�nderung tangierten Referenzprozess-modelle und deren Aktivitaten eruiert.Dies geschieht, indem das Lifecycle-Mo-dell nach allen Referenzprozessmodellenund Aktivitaten abgefragt wird, derenDesign-Entscheidungen auf der rechtlichenBestimmung „BGB,Artikel 0815, Absatz 1“beruhen. Die Abfrage wird in OntoGovuber Suchmasken mit entsprechenden Pull-Down-Listen (z. B. fur samtliche Begrun-dungen) realisiert. Das Resultat ist eine Lis-te der betroffenen Referenzprozessmodelleund Aktivitaten. Bei Auswahl eines Refe-renzprozessmodells werden die betroffe-nen Aktivitaten und die zugrunde liegen-de(n) Design-Entscheidung(en) angezeigt.


ROPM_FAA (File an Application)

ApplicationForm

ApplicationForm

Fill inApplication

CheckApplication

Commit

[DataNOK]

[DataOK]

<<pre-condition>>{already filled ininformation is displayed}

Notification

Application Data /Prozess-ID

Bild 4 R0PM File an Application


Hat sich nur formal etwas geandert, z. B.dass nicht mehr Absatz 1 sondern Absatz 2von Artikel 0815 die rechtliche Begrun-dung liefert, so kann die Aktualisierung au-tomatisiert werden. Dazu wird die Begrun-dung entsprechend modifiziert und dannautomatisch an alle betroffenen Referenz-prozessmodelle und Aktivitaten propagiert.Soll die �nderung nur fur ein Referenzpro-zessmodell, resp. eine Aktivitat, gelten, somuss zunachst die alte Begrundung entferntund anschließend die neue Begrundung er-stellt und zugeordnetwerden.Entfallt eine Begrundung ganz, z. B. weil

Artikel 0815 gestrichen wurde, so konnenjene Referenzprozessmodelle ermittelt wer-den, welche Aktivitaten enthalten, derenDesign-Entscheidungen einzig auf dieserBegrundung beruhen. Diese Aktivitatenwerden zurLoschungvorgeschlagen.Gibt es


2

3

1



eGov Form:Update Documents

Fill inApplicationfor Move

CheckApplication

CheckApplicationExtension


Move PA-2-deregister


Move PA-2-register <<pre-condition>>{additional infor-mation is needed}

Commit

[ContentNOK]

CheckApplication_AFM

[noExtension]

[Extension]

Notification

Application Data /Process ID

<<pre-condition>>{already filled ininformation isprovided}


<<note>>{citicens' notification}

ProvideInformationOfApplication


Key:

eGov - WS

Sub Process

R1PM_FAFM (File an-Application for Move)

R2PM_FAFM (File an-Application for Move in Olten)



eGov Form:Upload Documents

CheckApplication

Fill in Applicationfor Move in Olten

<<pre-condition>>{already filled ininformation isprovided}

Notification

Application Data /Process ID

CommitUploadDocs

<<note>>{citicens' notification}




Key:

eGov - WS

Sub Process

[ContentOK;]

[ContentNOK]

Documents

[ContentNOK;]

A or B

Bild 5 Spezialisierung der Prozesselemente von R0PM zu R1PM (UML-Notation)

ReferenceProcessModel

Reference

DesignDecisionsReplace Service ( with A)

B

1

Delete Service ( )2

Add Service ( )

1

2

3

states the relations betweenrefernce prozess models

ReferenceProcessModel'

3

A

B

Derivation

Bild 6 Schematische Darstellung der Abhangigkeiten zwischen Referenzprozess-modellen


hingegen noch andere Begrundungen fureineDesign-Entscheidung,wird lediglich aufeine potenzielle Veranderung hingewiesen.Sollen Prozesse angepasst werden, so

kann wie folgt vorgegangen werden:& Die betroffenen Referenzprozessmodel-

le werden wie o. g. ermittelt,& der „hierarchiehochste“ Prozess (z. B.

R0PM File an Application) wird aus-gewahlt,

& eine neue Version des Referenzprozess-modells wird erstellt,

& Prozessanderungen, die zugrunde liegen-den Design-Entscheidungen sowie dieneue Begrundung werden dokumentiert.

Sind samtliche Anpassungen durchgefuhrt,so konnen – z. B. uber das Setzen eines ent-sprechenden Status – die Modifikationen analle davon abgeleiteten, spezialisierten Refe-renzprozessmodelle propagiert werden.Dies wird ermoglicht, indem die Informa-tionen des Lifecycle-Modells und Prozess-

wissen aus den Prozess-Modellen ausgewer-tet werden. Bild 8 zeigt das Vorgehen.Die automatisch erstellten neuen Versio-

nen abgeleiteter Referenzprozessmodelle

(hier: R1PM_A4MoveV4) erhalten den Sta-tus „Entwurf“. Sie mussen anschließendmanuell uberpruft und ggf. nochmals ange-passt werden.


Decision

DecisionDecision

DecisionDecision

Decision Decision

Reason

Reason

Reason

isReasonFor

isReasonFor

isReasonForisReasonFor

isReasonFor

isReasonFor

isReasonFor

isReasonFor

Bild 7 Verknupfung von Entscheidungen und Begrundungen

Reference

SpecializationR0PM_

Application

V2

�

�

�

�

R1PM_

A4MoveV3

E

A

�

Replace Service (� mit E)

Add Service(s) (F,G)

LCO_R1PM_A4MoveV3

B C D

F G

Replace Service (� with A)

Delete Service (�)Add Service(s) (B,C,D)

manually

created

copy

R0PM_

Application

V3

�

�

�

�

�

�

Read LCO_R1PM_a4MoveV3

and perform modifications

and store result in LCO_R1PM_a4MoveV4

no modifications für� -> no action

replace � mit E

replace � mit A

delete �add services B,C,D

add services F,G

add join control construct (H)

join B, C, D

add sequence control costruct (I)

new version

R0PM_ApplicationV3

Add CC split

Add Service(s) (4,5)

Add CC join

LCO_R0PM_Applic.V2

R1PM_

A4MoveV4 E

A

�

B C D

F G

Reference

automatically

created copy from

R0PM_

ApplicationV3

as a draft

H

�

I

�

�

�

states the relation from

R0PM_ApplicationV3 to

R0PM_Application V2

Reference

SpecializationR0PM_

Application

V2

�

�

�

�

R1PM_

A4MoveV3

E

A

�

Replace Service (� mit E)

Add Service(s) (F,G)

LCO_R1PM_A4MoveV3

B C D

F G

Replace Service (� with A)

Delete Service (�)Add Service(s) (B,C,D)

manually

created

copy

R0PM_

Application

V3

�

�

�

�

�

�

Read LCO_R1PM_a4MoveV3

and perform modifications

and store result in LCO_R1PM_a4MoveV4

no modifications für� -> no action

replace � mit E

replace � mit A

delete �add services B,C,D

add services F,G

add join control construct (H)

join B, C, D

add sequence control costruct (I)

new version

R0PM_ApplicationV3

Add CC split

Add Service(s) (4,5)

Add CC join

LCO_R0PM_Applic.V2

R1PM_

A4MoveV4 E

A

�

B C D

F G

Reference

automatically

created copy from

R0PM_

ApplicationV3

as a draft

H

�

I

�

�

�

states the relation from

R0PM_ApplicationV3 to

R0PM_Application V2

Bild 8 Change Propagation in Referenzprozessmodellen


7 RealisierungsansatzWerkzeuge zurModellierung vonReferenz-modellen unterscheiden sich wesentlich inihrer Leistungsfahigkeit. Die untere Grenzewird abgesteckt durch reineGrafik-Bearbei-tung von Modellen, wahrend leistungsfahi-gere Modellierungswerkzeuge uber ein zen-trales Repository zur Modellverwaltungverfugen [FeLo04, 336f.]. OntoGov gehthier noch weiter, indem neben den Refe-renzmodellen auch deren Abhangigkeitenund Begrundungen fur Design-Entschei-dungen verwaltet werden sollen.Die Referenzprozessmodelle sowie

samtliches fur deren Ausfuhrung oder Do-kumentation benotigte Wissen werden inForm von Ontologien reprasentiert. EineOntologie ist ein formales Modell einesTeils der Welt, uber dessen Begriffe undZusammenhange eine Gruppe von Exper-ten/Nutzern Einigkeit erzielte (in Anleh-nung an [Grub93]).Ontologien werden im OntoGov-Pro-

jekt verwendet, um komplexe Sachverhalteexplizit und formal auszudrucken. In derModellierungsphase werden diese Eigen-schaften genutzt, um die Abhangigkeiten

zwischen verschiedenen Modellen zu defi-nieren und komplexe Transformationenvon einem Referenzmodell zu einem abge-leiteten Modell festzuhalten. Zudem kanndie syntaktische Korrektheit eines Modellsmit Hilfe von Regeln sichergestellt und bei�nderungen in den Begrundungen die be-troffenen Prozesse automatisch identifiziertwerden.Ontologien unterscheiden typischerwei-

se Konzepte und Relationen, welche dieBeziehungen zwischen diesen Konzeptendefinieren. Die Sprache fur die Referenz-modelle basiert auf einer um Konzepte desBPML-Standards (http://www.bpmi.org/BPML.htm erweiterten Variante vonOWL-S (http://www.daml.org/services/owl-s/1.1), einer Prozessontologie, die inder vom World Wide Web Consortiumstandardisierten Web Ontologie LanguageOWL (http://www.w3.org/2004/OWL)beschrieben wird. Zudem wurden die Mo-delle mit den in Abschnitt 5 erwahntenKonstrukten zur Verwaltung von Design-Entscheidungen erganzt. In den nachfol-genden Abschnitten werden die Modellie-rungs- und die Ausfuhrungsumgebunganhand unseres Beispiels erlautert.

Kernelement der Modellierungsum-gebung ist ein graphischer Editor, der furdie Spezifikation des Ablaufs verwendetwird. Zudem werden dem Prozess uberdiesen Editor weitere wichtige Informatio-nen hinzugefugt, u. a. Design Decisions,verwendete Organisationsressourcen, An-wendungen usw. Die graphisch erstelltenProzessmodelle werden automatisch in dieProzess-Ontologie ubersetzt.Die Verwendung eines grafischen Edi-

tors vereinfacht die Modellierung, so dass(Referenz-)Prozessmodelle von Fachper-sonen der Verwaltungen selbststandig er-stellt und gepflegt werden konnen.

Bild 9 zeigt die Benutzeroberflache mitdem beispielhaft modellierten ProzessR1PM_FAFM (File an Application for Mo-ve) und die dazugehorige Ontologie, dieim Hintergrund angelegt wird.Soll von einem bestehenden Referenz-

prozessmodell ein neues Modell abgeleitetwerden, wird zunachst eine Kopie diesesReferenzmodells angelegt. Diese Kopiedient anschließend als Grundlage fur dieWeiterbearbeitung. Spatere �nderungen ander Kopie werden in Form einer Design-Entscheidung mit einem Verweis auf das


Prozess-Editor

Instanz

Prozess-Ontologie

KonzeptProperty

Bild 9 R1PM File an Application for Move im Prozess-Editor und als Ontologie


Referenzmodell und einer dazugehorigenBegrundung in der Lifecycle-Ontologiefestgehalten. Bild 10 verdeutlicht das Vor-gehen.Vom Referenzmodell (R1PM_FAFM)

wird eine Kopie (R2PM_FAFM) erstelltund anschließend abgeandert. Die Veran-derung wird in der Lifecycle-Ontologie inForm einer Instanz von Design Decisionfestgehalten. Diese enthalt formale Ver-knupfungen zur bisherigen Aktivitat (ori-ginService) und zur neuen Aktivitat(newService) und verweist auf eine Begrun-dung (LegalReason), welche wiederum aufein Element in der Legal-Ontologie refe-renziert.Design-Entscheidungen konnen sowohl

mit einzelnen oder mehreren Aktivitatenwie auch mit dem gesamten Prozessmodellverknupft werden. Jedes Element kann da-bei durch mehrere Design-Entscheidungenbegrundet werden.Ist die Prozessmodellierung abgeschlos-

sen, werden den einzelnen AktivitatenWebservices zugeordnet. Dies erfolgt inder Konfigurationsumgebung. Dabei kon-nen die fur die Ausfuhrung einer Aktivitatin Frage kommenden Webservices direktangegeben werden. Alternativ konnenAuswahlkriterien spezifiziert werden, uberdie zur Laufzeit die passenden Servicesidentifiziert werden.Die einfachste Art fur Gemeinden, an

E-Government-Services von OntoGov zupartizipieren, ist die Angabe einer Mail-Adresse. Zur Laufzeit wird fur die jeweili-ge Gemeinde der entsprechende Web Ser-vice ermittelt und die Daten, respektive derLink auf einen sicheren Datenserver (Da-tendrehscheibe), per E-Mail an die Ge-meinde gesendet.Ist die Gemeinde an einer engeren Inte-

gration interessiert, so kann ein Web Ser-vice jederzeit ausgetauscht und Daten z. B.direkt in das Legacy-System der Gemeindeimportiert werden – unter Berucksichti-gung der erforderlichen Sicherheitsbestim-mungen.

8 Fazit und Ausblick

Ein großer Teil der Aufgaben von Gemein-den ist gesetzlich geregelt. Daher ist derAblauf der Prozesse im Wesentlichengleich. Sie eignen sich somit hervorragendfur die Referenzmodellierung, indem dergemeinsame Kern eines Prozesses als Refe-renzprozess modelliert und vielfach wie-derverwendet werden kann. Die dabeientwickelten Referenzmodelle haben nor-

mativen Charakter im Sinne der Charakte-risierung von [FeLo04, 333], wobei dieNormung eher im Sinne einer Empfehlungzu verstehen ist, da die Behorden unabhan-gig sind in der Umsetzung ihrer Prozesse –sofern die gesetzlichen Vorschriften einge-halten werden.In dieser Arbeit wurde ein Verfahren

vorgestellt, mit dem Referenzmodelle inForm von Ontologien modelliert werden.Die Referenzmodelle sind in einer Speziali-sierungshierarchie organisiert, was dasAuffinden der passenden Referenzmodelleerleichtert. Daruber hinaus werden dieReferenzmodelle erganzt um eine expliziteModellierung von Prozesswissen uber ge-setzliche Grundlagen und Grunde fur

Design-Entscheidungen. So konnen z. B.im Fall von Gesetzesanderungen die be-troffenen Prozesse einfach identifiziert undangepasst werden.

Im Rahmen des OntoGov Projekts wirddas Vorgehen am Beispiel eines Pilotpro-zesses fur den Umzug von Privatpersonendemonstriert. Unter Federfuhrung derSchweizerischen Bundeskanzlei wird derReferenzprozess modelliert und fur Ge-meinden verschiedener Kantone adaptiert.Bei erfolgreicher Evaluation kann das Ver-fahren auf andere Prozesse ubertragen unddie von der Bundeskanzlei implementier-ten Webservices integriert werden.

Eine zukunftige Aufgabe wird es sein,die traditionelle Bearbeitung und internet-


Abstract

Reference Modelling for E-Government Services

The realisation of E-Government Services in Switzerland makes only little progress. Reasonsare – on the one hand – the federal constitution of the Swiss Confederation. On the otherhand, public administrations are concerned about the high initial effort and the correspond-ing financial investments. As a partner in the EU-funded project OntoGov the Swiss FederalChancellery now takes over an active role in the configuration of E-Government services.With the OntoGov system reference process models are provided at various abstractionlayers. Public administrations can adapt these reference models to their specific needs andmake them available for the citizens. Decisions for designing and adapting reference pro-cesses are explicitly modelled using ontologies, making the decision process traceable. Thus,subsequent changes in the reference models can be transferred to all the depending models.

Keywords: Reference Modelling, E-Government, Web Services, Ontologies, Specializationof Reference Models

Lifecycle-Ontologie

Bild 10 Prozessspezialisierung – Verknupfung der Lifecycle-Ontologie mit den ande-ren Ontologien


basierte Aktivierung von Prozessen zu in-tegrieren. Dies kann uber ein gemeinsamesReferenzmodell erreicht werden, von dem– analog zur oben beschriebenen Speziali-sierung – die beiden Prozessvarianten ab-geleitet werden. Dies hatte den Vorteil, dassdie Konsistenz der beiden Prozessvarian-ten sichergestellt und Redundanzen in derModellierung vermieden wurden.

Anmerkung

Diese Arbeit entstand im Rahmen des EU-Projekts OntoGov. Die SchweizerischenPartner in dem Projekt – und damit ins-besondere die Erstellung des vorliegendenArtikels – werden vom Bundesamt fur Bil-dung und Wissenschaft (BBW) gefordert.

Literatur

[AAHP04] Abecker, A.; Apostolou, D.; Hinkel-mann, K.; Probst, F.; Stojanovic, L.; Tambouris,T.: Ontology-enabled eGovernment ServiceConfiguration – the OntoGov Approach. In:Wimmer, M. A. (Hrsg.): e|Gov Days: State-of-the-Art 2004. [email protected], Wien 2004, Band177, S. 324–331.

[BFSt00] Bundesamt fur Statistik, Gruppe fur Wis-senschaft und Forschung; Bundesamt fur Kom-munikation (Hrsg.): InformationsgesellschaftSchweiz. Standortbestimmung und Perspekti-ven. Neuchatel 2000, S. 43–45.

[BrBu04] vom Brocke, J.; Buddendick, C.: Organi-sationsformen der Referenzmodellierung. In:Wirtschaftsinformatik 46 (2004) 5, S. 341–352.

[Broc03] vom Brocke, J.: Referenzmodellierung.Gestaltung und Verteilung von Konstruktions-prozessen, Logos Verlag, Berlin 2003,S. 299–308.

[CoBe98] Conklin, J.; Begeman, M.: gIBIS – AHypertext Tool for Exploratory Policy Discus-sion. In: Proceedings of CSCW98 , Seattle, Wa-shington 1998, S. 140–152.

[FeLo04] Fettke, P.; Loos, P.: Referenzmodellie-rungsforschung. In: Wirtschaftsinformatik 46(2004) 5, S. 331–340.

[Grub93] Gruber, T.: A Translation Approach toPortable Ontology Specifications. In: Knowl-edge Acquisition, Volume 5. Academic PressLtd., London 1993, S. 199–220.

[HiKT02] Hinkelmann, K.; Karagiannis, D.; Teles-ko, R.: PROMOTE – Methodologie und Werk-zeug fur geschaftsprozessorientiertes Wissens-management. In: Abecker, A.; Hinkelmann, K.;Maus, H.; Muller H.J. (Hrsg.): Geschaftspro-zessorientiertes Wissensmanagement. Springer-Verlag, Berlin, Heidelberg 2002, S. 65–90.

[IWTo04] Institut fur Wirtschaft und TourismusHEVs (Hrsg.): Analyse des Transaktionsservice-Angebots der Schweizer Gemeinden im Auftragder Bundeskanzlei. Schlussbericht. Siders 2004,S. 9.

[JRHZ04] Jeckle, M.; Rupp, C.; Hahn, J.; Zengler,Barbara; Queins, S.: UML 2 glasklar. HanserVerlag, Munchen 2004, S. 199 ff.

[Kara95] Karagiannis, D.: BPMS: Business ProcessManagement Systems. ACM SIBOIS Bulletin,Vol. 16, ACM Press 1995, S. 10–13.

[KuRi70] Kunz, W.; Rittel, H.W.J.: Issues as Ele-ments of Information Systems. WP-131, Univer-sity of California,http://www-iurd.ced.berkeley.edu/pub/WP-131.pdf. Abruf am 2005-05-12.

[NaSc02] Nagele, R.; Schreiner, P.: Potenziale undGrenzen von Business Process ManagementTools fur geschaftsprozessorientiertes Wissens-management. In: Abecker, A.; Hinkelmann, K.;Maus, H.; Muller H.J. (Hrsg.): Geschaftspro-

zessorientiertes Wissensmanagement. Springer-Verlag, Berlin, Heidelberg 2002, S. 25–46.

[OfHo04] Off, T.; Horn, E.: Referenzmodelle fureGovernment. In: Reichard, C.; Scheske, M.;Schuppan T.: Potenziale des eGovernment; 2004.Vorabversion unter http://www.thomasoff.de/egov-referenzmodelle/index_0.htm, Abruf am2005-05-2008.

[Rome05a] Romer, J.: Vorwort des Prasidenten ander GV 2005. In: eCH-Newsletter Nr. 10 vom14. Februar 2005.http://www.unisg.ch/org/idt/echweb.nsf/0/67b467f5ae9e4989c1256fa8002f7ef5/$FILE/Newsletter_10_GV_2005.ch_d.pdf, Abruf am2005-06-21.

[Rome05b] Romer, J.: eGovernment: Lautet dasTotenglocklein des Foderalismus?http://www.telematiktage.ch/downloads/referate/gemeinde/1.3.05_Referat_Roemer_HO.pdf., S. 5 Abruf am 2005-05-25.

[RuGT99] Rupprecht, Ch.; Peter, G.; Rose, Th.:Ein modellgestutzter Ansatz zur kontextspezi-fischen Individualisierung von Prozessmodellen.In: Wirtschaftsinformatik 41 (1999) 3,S. 226–237.

[Sche95] Scheer, A.-W.: Wirtschaftsinformatik:Referenzmodelle fur industrielle Geschaftspro-zesse. Springer-Verlag, Berlin, Heidelberg 1995.

[SMRV04] Seel, S; Martin, G.; Runger, G.; Voigt,M.; Petersohn, H.: Referenzarchitektur fur eGo-vernment. URL: http://vdbsrv.de/viomatrix/924/imgs//downloads/rafeg_210604_final.pdf,Abruf am 2005-05-12.

[Weil04] Weill, F.: Schweiz will rote Laterne abge-ben. In: Computerworld, Dossier E-Govern-ment, Nr. 45 (2004), S. 1.http://www.lernetz.ch/info/documents/35/2004_11_05_Computerworld45.pdf, Abrufam 2005-05-30.

