View
215
Download
2
Category
Preview:
Citation preview
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.
WIRTSCHAFTSINFORMATIK 47 (2005) 5, S. 356–366
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-
WIRTSCHAFTSINFORMATIK 47 (2005) 5, S. 356–366
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).
WIRTSCHAFTSINFORMATIK 47 (2005) 5, S. 356–366
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}
eGov Form:ApplicationForMove
Referenzmodellierung fur E-Government-Services 359
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:
WIRTSCHAFTSINFORMATIK 47 (2005) 5, S. 356–366
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
360 Knut Hinkelmann, Barbara Thonssen, Fabian Probst
& 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.
WIRTSCHAFTSINFORMATIK 47 (2005) 5, S. 356–366
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
Referenzmodellierung fur E-Government-Services 361
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
WIRTSCHAFTSINFORMATIK 47 (2005) 5, S. 356–366
2
3
1
eGov Form:ApplicationForMove
eGov Form:ApplicationForMove
eGov Form:Update Documents
Fill inApplicationfor Move
CheckApplication
CheckApplicationExtension
eGov Form:ExtensionApplicationFor
Move PA-2-deregister
eGov Form:ExtensionApplicationFor
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>>{PAs responsible for(de)registration}
<<note>>{citicens' notification}
ProvideInformationOfApplication
ProvideInformationOfApplication
Key:
eGov - WS
Sub Process
R1PM_FAFM (File an-Application for Move)
R2PM_FAFM (File an-Application for Move in Olten)
eGov Form:ApplicationForMove
eGov Form:ApplicationForMove
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}
<<note>>{PAs responsible for(de)registration}
ProvideInformationOfApplication
ProvideInformationOfApplication
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
362 Knut Hinkelmann, Barbara Thonssen, Fabian Probst
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.
WIRTSCHAFTSINFORMATIK 47 (2005) 5, S. 356–366
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
Referenzmodellierung fur E-Government-Services 363
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
WIRTSCHAFTSINFORMATIK 47 (2005) 5, S. 356–366
Prozess-Editor
Instanz
Prozess-Ontologie
KonzeptProperty
Bild 9 R1PM File an Application for Move im Prozess-Editor und als Ontologie
364 Knut Hinkelmann, Barbara Thonssen, Fabian Probst
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-
WIRTSCHAFTSINFORMATIK 47 (2005) 5, S. 356–366
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
Referenzmodellierung fur E-Government-Services 365
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. books@ocg.at, 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.
WIRTSCHAFTSINFORMATIK 47 (2005) 5, S. 356–366
366 Knut Hinkelmann, Barbara Thonssen, Fabian Probst
Recommended