Leitfaden für Entwickler von Prozess- und Datenmodellen

Leitfaden für Entwickler vonProzess- und Datenmodellen

Version 1.0

Publikat

Septem

Praxisorientiertes Vorgehen zur Modellierung von Prozessen und Daten in der Bundesverwaltung

ion der KBSt

ber 2007

Publikation der KBSt

Nachdruck, auch auszugsweise, ist genehmigungspflichtig

Dieser Band wurde herausgegeben von der KBSt im Bundesministerium des Innern.

Redaktion: ]init[ AG, Berlin

Interessenten erhalten die derzeit lieferbaren Veröffentlichungen der KBStund weiterführende Informationen zu den Dokumenten beim

Bundesministerium des InnernReferat IT 2 (KBSt)

11014 Berlin

Homepage und Download der digitalen Version:http://www.kbst.bund.de/modellierungsleitfaden

mailto: [email protected]

http://www.kbst.bund.de/modellierungsleitfaden

mailto:[email protected]

Leitfaden für Entwickler von Prozess- und Datenmodellen

Praxisorientiertes Vorgehen zur Modellierung von Prozessen und Daten in der Bundesverwaltung

Version 1.0

September 2007

Herausgegeben vomBundesministerium des Innern

Inhaltsverzeichnis

1 Einleitung .............................................................................................. 7

1.1 Angesprochener Leserkreis ......................................................................................7

1.2 Zielsetzung ......................................................................................................................7

1.3 Hintergrund ....................................................................................................................7

1.4 Vorgehen .........................................................................................................................8

1.5 Ausblick ............................................................................................................................9

2 Vorbereitung der Modellierung ........................................................11

2.1 Bestimmung der Rahmenbedingungen ........................................................... 11

2.2 Festlegung der Standards und Technologien ................................................ 13

2.3 Zielgruppengerechte Modellierung ................................................................... 14

2.4 Anforderungen an Werkzeuge ............................................................................. 15

2.5 Festlegung der Konventionen .............................................................................. 17

3 Ist-Erfassung und -Modellierung ......................................................31

3.1 Identifikation und Priorisierung von Modellierungsbereichen ................ 31

3.2 Erfassung des Ist-Zustands ..................................................................................... 33

3.3 Modellierung des Ist-Zustands ............................................................................. 36

4 Schwachstellenanalyse .....................................................................43

4.1 Festlegung von Kriterien zur Schwachstellenidentifikation ...................... 43

4.2 Identifikation und Dokumentation der Schwachstellen ............................. 45

4.3 Ermittlung und Priorisierung von Verbesserungsmöglichkeiten ............ 46

5 Soll-Modellierung ...............................................................................49

5.1 Entwicklung des Soll-Zustands ............................................................................. 50

5.2 Modellierung des Soll-Zustands .......................................................................... 54

6 Bekanntmachung und Umsetzung der Modelle ..............................61

6.1 Entscheidung zur Umsetzungsstrategie ........................................................... 61

6.2 Einführung der Modellierungsergebnisse ........................................................ 62

6.3 Technische Implementierung der Modelle ...................................................... 63

6.4 Durchführung von Schulungen ........................................................................... 64

Anhang A Checklisten zur Modellierungsvorbereitung ...................................65

A.1 Checkliste Rahmenbedingungen ........................................................................ 65

A.2 Checkliste Standards und Technologien .......................................................... 66

A.3 Checkliste Werkzeug ................................................................................................ 67

A.4 Checkliste Modellierungskonventionen ........................................................... 67

Seite 5

A.5 Checkliste Dokumentation .................................................................................... 68

Anhang B Datenblätter zur Modellierung .........................................................70

B.1 Datenblatt Prozesse .................................................................................................. 70

B.2 Datenblatt Daten ....................................................................................................... 70

B.3 Datenblatt Schwachstelle ....................................................................................... 71

Anhang C Vorlage zur Dokumentation ..............................................................72

Anhang D Geeignete Standards und Technologien zur Modellierung ...........74

D.1 Unified Modeling Language (UML) ..................................................................... 74

D.2 Ereignisgesteuerte Prozesskette (EPK) ............................................................... 76

D.3 Flussdiagramm ........................................................................................................... 77

D.4 Entity-Relationship-Diagramm (ERD) ................................................................. 78

D.5 XML Schema Definition (XSD) ............................................................................... 79

D.6 Zusammenfassung Standards und Technologien ........................................ 81

Anhang E Glossar .................................................................................................82

Anhang F Abkürzungsverzeichnis .....................................................................86

Anhang G Abbildungsverzeichnis ......................................................................87

Anhang H Tabellenverzeichnis ...........................................................................89

Anhang I Literaturverzeichnis ...........................................................................91

Seite 6

1 Einleitung

1.1 Angesprochener Leserkreis

Der Leitfaden richtet sich in erster Linie an Mitarbeiter der Bundesverwaltung, die imRahmen von IT-Projekten in öffentlichen Verwaltungen die Modellierung von Prozes-sen und Daten durchführen. Weiterhin sollen mit dem Leitfaden Dienstleister ange-sprochen werden, die im Auftrag von Behörden der Bundesverwaltung die Prozess-und Datenmodellierung ausführen.

Zur Nutzung des Leitfadens wird ein grundsätzliches Verständnis für die objektorien-tierte Modellierung nach der Unified Modeling Language (UML) (siehe Abschnitt D.1auf Seite 74) vorausgesetzt. Lesern, die diese Kenntnisse nicht besitzen, wird insbe-sondere die Beachtung der gegebenen Beispiele in den einzelnen Abschnitten undder dazugehörigen Erläuterungen empfohlen. Dieser Leitfaden ist jedoch kein Ersatzfür eventuell benötigte Schulungen in UML oder UML-Werkzeugen. Hierzu wird aufdie in dem Literaturverzeichnis angegebenen Quellen verwiesen (siehe Seite 91).

1.2 Zielsetzung

Der Leitfaden hat das Ziel, Entwickler von Prozess- und Datenmodellen in der öffentli-chen Verwaltung – vor allem im Rahmen von IT-Projekten – bei ihrer Arbeit zu unter-stützen.

Der Leitfaden nimmt Bezug zu

• allgemeinen Konventionen zur Modellierung

• ausgewählten Standards und Technologien zur Modellierung

• Anforderungen an Modellierungswerkzeuge

• Vorgehensweisen bei der Erfassung und Modellierung von Prozessen und Daten

• Kriterien zur Optimierung von Prozessen und Datenstrukturen

• begleitenden Maßnahmen (Beispiel: Implementierung, Kommunikation, Schu-lung)

1.3 Hintergrund

Gemeinsam wurde von Bund und Ländern 2006 der Aktionsplan Deutschland-Online(DOL)1 verabschiedet. „Standardisierung“ ist eines der priorisierten Vorhaben vonDOL. Es soll die Entwicklung und Bereitstellung von fachlichen Standards für denelektronischen Datenaustausch (XÖV-Standards) unterstützen und koordinieren,sodass elektronische Prozesse innerhalb (G2G) und mit der öffentlichen Verwaltung(G2C, G2B) effizient und in einheitlicher Weise umgesetzt werden können. Hierfürwerden aufeinander abgestimmte Maßnahmen durch das Vorhaben zur Unterstüt-

1. siehe http://www.deutschland-online.de/

Seite 7

http://www.deutschland-online.de/

http://www.bsi.bund.de/fachthem/egov/download/3_Phase3.pdf

zung der XÖV-Projekte der öffentlichen Verwaltung angeboten: Entwicklungsmetho-den, Werkzeuge und technische Infrastrukturen sowie Beratungsleistungen undÖffentlichkeitsarbeit.

Um die Ziele des DOL-Vorhabens „Standardisierung“ zu erreichen, sind einheitlicheVorgehensweisen und geeignete Techniken für die Modellierung von Prozessen undDaten in öffentlichen Verwaltungen erforderlich. Nur dann können standardisierteProzess- und Datenbausteine2 wiederverwendet werden und die Interoperabilitätvon IT-Anwendungen von Bund, Ländern und Kommunen unterstützen.

Dieser von der Koordinierungs- und Beratungsstelle der Bundesregierung für Infor-mationstechnik in der Bundesverwaltung (KBSt) herausgegebene Leitfaden stellt aufder Grundlage von SAGA3 praxisnah geeignete Modellierungstechniken vor und skiz-ziert ein einheitliches Vorgehen beim Erstellen von Prozess- und Datenmodellen.

1.4 Vorgehen

Der Leitfaden ist so konzipiert, dass die einzelnen Arbeitsschritte während der Pro-zess- und Datenmodellierung detailliert behandelt werden. Er umfasst Ausführungenzu

Abbildung 1: Vorgehen bei der Modellierung

• Vorbereitung der Modellierung

• Erfassung und Modellierung des Ist-Zustands

2. Als Baustein wird hierbei ein Ausschnitt aus einem komplexen Modell bezeichnet. Im Idealfall kann aus mehreren untereinander abgestimmten Bausteinen ein Prozess- oder Datenmodell erstellt werden.

3. siehe „Standards und Architekturen für E-Government-Anwendungen (SAGA)“, KBSt, http://www.kbst.bund.de/saga

Kapitel 2Vorbereitung der

Modellierung

Komponente n(...)

...

Kapitel 3Ist-Erfassung und -

Modellierung

Kapitel 6Bekanntmachung und Umsetzung der Modelle

Kapitel 4Schwachstellenanalyse

Kapitel 5Soll-Modellierung

Seite 8

http://www.kbst.bund.de/saga


• Analyse und Optimierung der Modelle

• Modellierung des Soll-Zustands.

Um den erfolgreichen Abschluss eines Projekts gewährleisten zu können, muss nebenden genannten Schritten auch die Anpassung der vorhandenen Strukturen eineröffentlichen Verwaltung vorgenommen werden.

Dieser Leitfaden bildet diese Phasen der Modellierung sowie angrenzende Themen-schwerpunkte in chronologischer Reihenfolge in einzelnen Kapiteln ab.

Zur Erhöhung der Verständlichkeit für die Leser dieses Leitfadens wird in dem gesam-ten Leitfaden ein durchgehendes Beispiel mit Bezug zur öffentlichen Verwaltungbetrachtet.

Das Beispiel wird durch ein Icon in Form einer Lupe am Dokumentrand hervorgeho-ben. Die Grundidee des Beispiels lässt sich wie folgt skizzieren: In einer Behörde findetaktuell die Antragsverwaltung mit Medienbrüchen und unter einer geringen Einbin-dung von Informations- und Kommunikationstechnologien statt. Zukünftig soll einestärkere Nutzung der Informations- und Kommunikationstechnologien in den Abläu-fen der Antragsverwaltung erfolgen.

1.5 Ausblick

Entwickler von Modellen sollen zukünftig stärker in die Standardisierung von Prozess-und Datenbausteinen im Rahmen des Deutschland-Online Vorhabens „Standardisie-rung“ eingebunden werden. Momentan entsteht ein Repository der deutschenöffentlichen Verwaltung für die Speicherung von Datenmodellen und Datenbaustei-nen. Es soll in künftigen Versionen des Leitfadens dargestellt werden, wie bereitsstandardisierte Bausteine im Repository identifiziert werden, wie solche Bausteine ausdem Repository bezogen werden und wie sie zu verwenden sind. Ebenso soll auchbeschrieben werden, inwieweit Entwickler von Modellen selbst Prozess- und Daten-bausteine zur Standardisierung und Veröffentlichung im Repository vorschlagen kön-nen. Hierzu sollen Kriterien benannt werden, die Bausteine erfüllen müssen, damiteine Standardisierung sinnvoll ist.

Ein weiteres Thema für diesen Leitfaden soll der konkrete Einsatz des XGenerator 2.0werden. Dabei handelt es sich um eine Software zur automatischen Generierung vonXML-Schemata und Dokumentation aus einem UML-Datenmodell (im Format EMFXMI 2.0). Für das Projekt XMeld ist der XGenerator 2.0 bereits im Einsatz. Momentanentstehen allgemeine Templates, um die Konfiguration für die Verwendung in weite-ren Projekten zu erleichtern. Im 4. Quartal 2007 soll der XGenerator 2.0 als Open-Source-Software von der KBSt zur Verfügung gestellt werden.

Seite 9

http://www.databaseanswers.com/modelling_tools.htm


Seite 10

2 Vorbereitung der Modellierung

Um die Prozess- und Datenmodellierung im Rahmen eines Projekts zu einem größt-möglichen Erfolg zu führen, ist es notwendig, vor dem eigentlichen Start des Projektseine grundlegende Vorbereitung und Planung durchzuführen. Ziel ist es, dass zurModellierung von Prozessen und Daten in einem IT-Projekt die Rahmenbedingungenfür die öffentliche Verwaltung beachtet sowie einheitliche Standards, Technologien,Software-Werkzeuge und Modellierungskonventionen verwendet werden.

Abbildung 2 gibt einen Überblick über den Ablauf bei der Vorbereitung der Prozess-und Datenmodellierung.

Abbildung 2: Ablauf der Vorbereitung zur Modellierung

Grundsätzliche Informationen zum Management von IT-Projekten sind im V-ModellXT4 der KBSt zu finden.

2.1 Bestimmung der Rahmenbedingungen

Zu Beginn der Modellierungsvorbereitung erfolgt die Bestimmung der Rahmenbe-dingungen in einer öffentlichen Verwaltung, deren Beachtung für einen erfolgreichenAbschluss der Modellierung und somit auch des Projekts notwendig ist.

Unter Rahmenbedingungen werden spezifische Vorgaben und Informationen zueiner öffentlichen Verwaltung verstanden, die entsprechend in IT-Projekten zuberücksichtigen sind (Beispiel: Verantwortlichkeiten von Mitarbeitern, Einschränkun-gen in der Durchführbarkeit von Projekten, Strategien bezüglich Umsetzung, Kom-munikation und Schulung).

Rahmenbedingungen, deren Beachtung empfohlen wird, sind:

4. siehe V-Modell XT, KBSt, unter http://www.kbst.bund.de/v-modell

Abschnitt 2.1Bestimmung der

Rahmenbedingungen

Abschnitt 2.2Festlegung der Standards

und Technologien

Abschnitt 2.3Anforderungen an

Werkzeuge

Abschnitt 2.4Festlegung der Konventionen

Seite 11

http://www.kbst.bund.de/v-modell

Verantwortlichkeiten für Prozesse und Daten

Die Verantwortlichen für Prozesse und Daten sowie die Verantwortlichen für dieModellierung sollten benannt werden, um den Ablauf der Modellierung und dieBerücksichtigung der Verwaltungsstrukturen organisieren zu können.

Einbindung der Verwaltung

Es sollte durch die Verwaltungsleitung und Personalabteilung unter Einbindung vonPersonalrat, Gleichstellungsbeauftragten, Schwerbehindertenvertretung etc. festge-legt werden, inwieweit eine Änderung der Aufbauorganisation in einer öffentlichenVerwaltung möglich und gewünscht ist. Nicht überwindbare Rahmenbedingungen –beispielsweise verwaltungspolitische Prozesse, bestehende Aufbauorganisation,Gesetze und Verordnungen – können dazu führen, dass bei Nichtbeachtung dieserBedingungen ein Projekt scheitert.

Strategie zur Umsetzung der modellierten Prozesse und Daten

Die Verwaltungsleitung legt zu Beginn des Projekts fest, inwieweit nach der Modellie-rung der Prozesse und Daten deren Umsetzung in der öffentlichen Verwaltung vorge-nommen werden soll – entweder über eine stufenweise oder eine gleichzeitigeUmsetzung für einzelne Teilmodelle. Weiterführende Informationen zu diesemThema sind in Abschnitt 6.1 „Entscheidung zur Umsetzungsstrategie“ auf Seite 61 zufinden.

Kommunikations- und Schulungskonzept

Zur Schaffung von Akzeptanz bei den Mitarbeitern für die Maßnahmen während derModellierung sowie für die aus der Implementierung der Modelle entstehendenneuen Ablauf- und Aufbaustrukturen in einer öffentlichen Verwaltung ist es notwen-dig, ein Kommunikations- und Schulungskonzept zu erarbeiten, das bestehende Vor-behalte und Ablehnungen der Mitarbeiter beseitigt. Das Kommunikationskonzeptbeinhaltet Angaben zu Informationsveranstaltungen, persönlichen Gesprächen mit

Empfehlung 1:

Die Verantwortlichen für Prozesse und Daten sowie diejenigen für die Modellie-rung sollten eingangs des Projekts benannt werden.

Empfehlung 2:

Einschränkungen für Verwaltungsprozesse, die auf der Aufbauorganisation eineröffentlichen Verwaltung beruhen, sollten vor Beginn der Modellierung ermitteltwerden.

Empfehlung 3:

Schon vor Beginn der Modellierung sollte in Abhängigkeit vom Projekt die Umset-zungsstrategie festlegt werden – die stufenweise oder gleichzeitige Umsetzungvon Teilmodellen.

Seite 12

den betroffenen Mitarbeitern, Publikationen sowie Angaben über die Bekanntma-chung des Vorhabens und der Ergebnisse des Projektes im Intranet. WeiterführendeInformationen zu dieser Thematik befinden sich in Abschnitt 6.4 „Durchführung vonSchulungen“ auf Seite 64.

2.2 Festlegung der Standards und Technologien

Ziel der Auswahl von Standards und Technologien ist eine einheitliche Darstellungund Verwendung der später zu erstellenden Prozess- und Datenmodelle. Dazu ist esnotwendig, verwaltungsweite und -übergreifende Standards und Technologien zurProzess- und Datenmodellierung festzulegen.

Tabelle 1 zeigt die Standards und Technologien, die für die einzelnen Phasen derModellierung – sowohl die grobe5 und detaillierte Modellierung als auch die techni-sche Implementierung – von Prozess- und Datenmodellen in öffentlichen Verwaltun-gen geeignet sind.

Empfehlung 4:

Für einen erfolgreichen Abschluss der Modellierung – und somit auch des Projekts– ist es notwendig, ein Kommunikations- und Schulungskonzept zu entwickeln undumzusetzen.

Empfehlung 5:

Einheitliche Standards und Technologien zur Modellierung sollten festgelegt wer-den.

5. Eine grobe Modellierung findet statt, wenn das Ergebnis der Modellierung nur einen Über-blick über die Ist- bzw. Soll-Zustände liefern soll. Wenn z. B. bereits vor Beginn der Modellie-rung klar ist, dass eine Schwachstellenanalyse durchgeführt wird, sollte eine detaillierteModellierung mit UML erfolgen.

Modellierungsphase Prozessmodellierung Datenmodellierung

Grobe Modellierung EPK – Ereignisgesteuerte Prozessketten

Flussdiagramme

UML – Unified Modeling Language (Anwendungs-falldiagramme, Aktivitätsdi-agramme, Paketdia-gramme)

ERD – Entity-Relationship-Diagramme

UML – Unified Modeling Lan-guage (Klassendiagramme)

Tabelle 1: Geeignete Standards und Technologien zur Modellierung

Seite 13

mailto:[email protected]

In Anhang D „Geeignete Standards und Technologien zur Modellierung“ auf Seite 74werden die ausgewählten Standards und Technologien für die Prozess- und Daten-modellierung kurz vorgestellt und anhand von Beispielen erläutert. Für die einzelnenModellierungsphasen werden im Leitfaden begleitend Beispiele von UML-Diagram-men präsentiert.

2.3 Zielgruppengerechte Modellierung

Die Kommunikation der Modellierungsergebnisse an die Beteiligten des Projektserfordert eine zielgruppengerechte Ausführung. Es ist darauf zu achten, welche Formder Ergebnispräsentation in welcher Modellierungsphase am sinnvollsten ist. Ebensoist die Zielgruppe, zum Beispiel Führungskräfte, Fachanwender, IT-Verantwortlicheoder IT-Entwickler zu beachten. Hierbei sind die Erfahrungen und Kenntnisse desjeni-gen zu berücksichtigen, dem die Modellierungsergebnisse dargelegt werden.

Die folgende Tabelle gibt einen Überblick darüber, welche Standards und Technolo-gien für die jeweilige Zielgruppe geeignet sein könnten.

Detaillierte Modellie-rung

UML – Unified Modeling Language (Anwendungs-falldiagramme, Aktivitätsdi-agramme, Paketdia-gramme u. a. Diagramme)


Datenaustauschfor-mate / Technische Implementierung

XMI – XML Metadata Inter-change

XMI – XML Metadata Inter-change

XML – eXtensible Markup Language

XSD – XML Schema Definition

Zielgruppe Prozessmodellierung Datenmodellierung

Führungskräfte EPK – Ereignisgesteuerte Prozessketten

Flussdiagramme

UML – Unified Modeling Language (Anwendungs-falldiagramme, Paketdia-gramme)

Tabelle 2: Geeignete Standards und Technologien für unterschiedliche Zielgruppen

Tabelle 1: Geeignete Standards und Technologien zur Modellierung

Seite 14

2.4 Anforderungen an Werkzeuge

Auf Basis der zur Modellierung geeigneten Standards und Technologien erfolgt dieAuswahl der zu verwendenden Software-Werkzeuge. Ziel ist die einheitliche Darstel-lung der Prozess- und Datenmodelle durch Werkzeuge, welche die geeigneten Stan-dards und Technologien unterstützen. Weiterhin vorteilhaft ist die Einsparung vonKosten bei einer einheitlichen Nutzung von Werkzeugen in einer öffentlichen Verwal-tung. Lizenzen und Schulungen können in großer Anzahl letztendlich zu einem güns-tigeren Einzelpreis erworben werden und ggf. können Verwaltungsmitarbeiter alsMultiplikatoren verwaltungsinterne Schulungen durchführen.

Abhängig von der Auswahl der Modellierungswerkzeuge ist auch, ob die Verwal-tungsabläufe für ein Projekt einmalig aufgenommen werden oder ob für eine grund-

Fachanwender EPK – Ereignisgesteuerte Prozessketten

Flussdiagramme

UML – Unified Modeling Language (Anwendungs-falldiagramme, Aktivitätsdi-agramme, Paketdia-gramme)

ERD - Entity Relationship-Dia-gramm

UML - Unified Modeling Lan-guage (Klassendiagramm)

IT-Verantwortliche UML – Unified Modeling Language (Anwendungs-falldiagramme, Aktivitätsdi-agramme, Paketdia-gramme, u. a. Diagramme)



IT-Entwickler UML – Unified Modeling Language (Anwendungs-falldiagramme, Aktivitätsdi-agramme, Paketdia-gramme, u. a. Diagramme)




Empfehlung 6:

Die Modellierung sollte mit der Orientierung an den verschiedenen Zielgruppen –Führungskräfte, Fachanwender, IT-Verantwortliche oder IT-Entwickler – stattfinden,um für jede Zielgruppe Informationen sinnvoll aufzubereiten.

Empfehlung 7:

Die Nutzung von Werkzeugen sollte einheitlich erfolgen.

Tabelle 2: Geeignete Standards und Technologien für unterschiedliche Zielgruppen

Seite 15

sätzlich empfehlenswerte fortschreitende Optimierung eine Versionierung derAbläufe erfolgen soll.

An Werkzeuge werden insbesondere die folgenden Anforderungen gestellt:

• Kompatibilität: Fähigkeit eines Werkzeugs, die Ergebnisse eines anderen Werk-zeugs in Form von Daten weiterzuverarbeiten sowie Ergebnisdaten zur Weiterver-arbeitung an andere Werkzeuge zur Verfügung zu stellen

• Austauschbarkeit: Eigenschaft eines Werkzeugs, weit verbreitete Austauschfor-mate (Beispiel: XMI, XML) zu unterstützen, sodass das Werkzeug bei Bedarf auchdurch ein anderes ersetzt werden kann, das die Austauschformate ebenfallsunterstützt

Wird in der Praxis noch kein Modellierungswerkzeug erfolgreich genutzt, kann auf dieÜbersicht der KBSt zu Modellierungswerkzeugen6 zurückgegriffen werden. Sie nenntbeispielhaft Werkzeuge für die Modellierung und stellt eine Auflistung von ihrenEigenschaften und Funktionen zur Verfügung.

Neben der Sichtung bestehender Werkzeuglisten kann auch eine eigene Evaluierungzu Modellierungswerkzeugen durchgeführt werden. Zur Evaluation von Werkzeugenzur Prozess- und Datenmodellierung wird folgendes Vorgehen empfohlen:

• Dokumentenstudium: Auswertung von Papierquellen sowie Informationen aufWeb-Seiten von relevanten Anbietern, wie beispielsweise Datenblätter sowie Kri-tiken und Bewertungen von Anwendern. So kann der Modellierer das Feld der vie-len Anbieter eingrenzen, die seinen Anforderungen entsprechen, und kann dar-aus eine überschaubare Liste mit potenziellen Anbietern generieren.

• Praxistest: Durchführung praktischer Tests für alle Werkzeuge der verbliebenenAnbieter durch die Modellierer, um Qualitätsunterschiede feststellen zu können.

• Wirtschaftlichkeitsbetrachtung: Betrachtung von Kostenaspekten, falls nach derDurchführung des Praxistests an dieser Stelle noch mehrere Anbieter in Fragekommen.

Die Einhaltung der Reihenfolge der genannten Evaluationsschritte ist nicht zwingendvorgeschrieben, aus Haushaltsgründen kann eine Wirtschaftlichkeitsbetrachtung vordem Praxistest notwendig sein.

Empfehlung 8:

Das Werkzeug sollte standardisierte Austauschformate (Beispiel: XMI, XML) fürModelle unterstützen.

6. siehe http://www.kbst.bund.de/saga-tools

Empfehlung 9:

Für den Fall, dass in der öffentlichen Verwaltung momentan kein Werkzeug bzw.kein geeignetes Werkzeug zur Modellierung eingesetzt wird, sollte eine Werkzeug-auswahl über Dokumentenstudium, Praxistest und Wirtschaftlichkeitsbetrachtungerfolgen.

Seite 16

http://www.kbst.bund.de/saga-tools

Zur Unterstützung durch Werkzeuge werden in diesem Leitfaden weiterführendeInformationen zu den einzelnen Standards und Technologien gegeben (sieheAnhang D „Geeignete Standards und Technologien zur Modellierung“ auf Seite 74).

2.5 Festlegung der Konventionen

Um eine einheitliche Verwendung der ausgewählten Standards, Technologien undWerkzeuge zur Modellierung sicherzustellen, ist es notwendig, Konventionen fürderen Anwendung zu erstellen. Es wird empfohlen, auf die in den folgendenAbschnitten benannten Konventionen zurückzugreifen.

2.5.1 Sprache

Bei der Modellierung in deutschen Verwaltungen wird Deutsch als Sprache fürModelle und deren Dokumentationen festgeschrieben, da spezielle Bezeichnungenoft auf einer gesetzlichen Grundlage beruhen und oft nicht in eine andere Spracheübersetzt werden können, ohne den ursprünglichen Zusammenhang zu verlieren.Umlaute und Sonderzeichen der deutschen Sprache sollten in Bezeichnern nicht ver-wendet werden. Nur in Sonderfällen, in denen keine entsprechende deutscheBezeichnung existiert, sollte ein fremdsprachiger Begriff gewählt werden.

Bei den Dokumentationen der Modelle kann zusätzlich zu einer deutschen Beschrei-bung auch eine fremdsprachige Beschreibung erfolgen.

In internationalen Projekten sollte Englisch als Hauptsprache in Modellen festgelegtwerden.

2.5.2 Zeichensatz

Die entwickelten Modelle und XML-Schemata sollten mit einer standardisierten undinvestitionssicheren Codierung einsetzbar sein. Daher ist der bevorzugte Zeichensatzfür die Modelle der internationale Unicode-Standard UTF-8 (8-bit Unicode Transfor-mation Format)7, der auch in SAGA 3.08 für die Version 4.x als „Obligatorisch“ referen-ziert wird.

Empfehlung 10:

Grundsätzlich sollte die bei der Erstellung der Modelle und deren Dokumentationgenutzte Sprache Deutsch sein. Innerhalb internationaler Projekte sollte Englischverwendet werden.

7. siehe FAQ auf http://www.unicode.org/faq/utf_bom.html8. siehe http://www.kbst.bund.de/saga, SAGA 3.0, Seite 86

Empfehlung 11:

Als Zeichensatz für die Modelle sollte UTF-8 verwendet werden.

Seite 17


http://www.unicode.org/faq/utf_bom.html

2.5.3 Modelle und Diagramme

2.5.3.1 Arten von Modellen und Diagrammen

Im Abschnitt 2.2 „Festlegung der Standards und Technologien“ erfolgte in Tabelle 1auf Seite 13 eine Darstellung von geeigneten Standards und Technologien mit ihrenmöglichen Einsatzgebieten.

Damit verschiedene Entwickler von Modellen im Rahmen eines Projektes effektiv undeffizient an unterschiedlichen Teilmodellen arbeiten können, ist die Festlegung not-wendig, in welcher Modellierungsphase welche Modell- und Diagrammtypen einge-setzt werden können.

Zusätzlich wird empfohlen, in Bereichen, in denen keine geeigneten und werkzeug-unterstützten Darstellungsformen existieren, Datenblätter zu verwenden, sieheAnhang B „Datenblätter zur Modellierung“ auf Seite 70. Die Anwendung der Daten-blätter wird in den einzelnen Modellierungsphasen anhand von Beispielen vorge-stellt.

2.5.3.2 Layout der Modelle und Diagramme

Zusätzlich zu den Arten von Modellen und Diagrammen, die zur Modellierunggenutzt werden sollen, muss auch entschieden werden, welches einheitliche Layoutfür die Darstellung genutzt wird.

Die Festlegung eines einheitlichen Layouts ist insbesondere deswegen notwendig, daviele Werkzeuge benutzerspezifische Layouteinstellungen ermöglichen. Ein unter-schiedliches Layout der Modelle kann jedoch dazu führen, dass die Modelle fürandere Beteiligte schwerer verständlich werden.

Um unterschiedliche Layouts in Modellen zu vermeiden, wird empfohlen, insbeson-dere Festlegungen zu Form und Farbe der Objekt- und Beziehungstypen in den ein-zelnen Modell- und Diagrammtypen zu treffen.

2.5.3.3 Detaillierungsgrad der Modelle und Diagramme

In den Phasen der Ist-Erfassung und -Modellierung sowie Soll-Modellierung können jenach Bedarf auch unterschiedliche Detaillierungsgrade für Modelle und Teilmodelle

Empfehlung 12:

Die zu verwendenden Arten von Modellen und Diagrammen sollten vor demModellierungsbeginn festgelegt werden. Für Bereiche, in denen keine Modelle undDiagramme erstellt werden, sollten die im Anhang beschriebenen Datenblättereingesetzt werden.

Empfehlung 13:

Zur Erhöhung der Verständlichkeit sollte das Layout der Modelle einheitlichbestimmt werden (Beispiel: Arten der Modellelemente, Form und Farbe von Model-lelementen sowie Beziehungsarten).

Seite 18

eingesetzt werden. Dies hängt neben den Projektzielen von dem schon am Projektbe-ginn zu erwartenden Umfang der Veränderungen in einem Modell ab. Je größer derUmfang der Änderungen sein wird und wenn dies schon von Beginn an feststeht,desto weniger detailliert muss die Modellierung des Ist-Zustands erfolgen. Ebenso istes nicht immer notwendig, eine Ist-Erfassung und -Modellierung durchzuführen, ins-besondere bei der Einführung völlig neuer Prozesse.

Im Umkehrschluss ist eine detaillierte Ist-Modellierung vor allem dann notwendig,wenn zu Projektbeginn nicht erkennbar ist, welche Veränderungen auf die öffentlicheVerwaltung zukommen beziehungsweise welche Bereiche optimiert werden müssen.

Der Detaillierungsgrad muss jedoch so gewählt werden, dass die Vergleichbarkeit derTeilmodelle gewährleistet bleibt.

Detaillierungsgrad in Prozessmodellen

Für einzelne Aktivitäten eines Prozesses ist es bei einer zu großen Komplexität not-wendig, einen Unterprozess zu bilden und für diesen ein eigenes Modell zu entwi-ckeln. Hierbei muss jedoch für jeden Einzelfall entschieden werden, inwieweit die Ver-feinerung wirtschaftlich vertretbar ist und ob die Verfeinerung des Prozesses für dieLeistungserbringung der öffentlichen Verwaltung von ausschlaggebender Bedeu-tung im Gesamtprozessmodell ist. Beispiele für Kriterien, welche Einfluss auf denDetaillierungsgrad haben, sind in Tabelle 3 dargestellt.

Empfehlung 14:

Der Detaillierungsgrad der Modelle sollte abhängig von den jeweiligen Projektzie-len und -erfordernissen vor Beginn der Modellierung festgelegt werden.

Kriterium Detaillierung

Qualifikationen Je höher die Anzahl der Fähigkeiten ist, die ein Mitarbeiter haben muss, um eine Aktivität ausführen zu können, um so eher sollte diese Aktivität als Unterprozess detailliert und somit auf mehrere Mitarbeiter verteilt werden.

Auslösende Ereig-nisse

Ist die Anzahl der auslösenden Ereignisse größer als drei, sollte überlegt werden, die Aktivität als Unterprozess zu detaillieren.

Ausgehende Ereig-nisse

Ist die Anzahl der ausgehenden Ereignisse größer als drei, sollte überlegt werden, die Aktivität als Unterprozess zu detaillieren.

Tabelle 3: Kriterien zur Detaillierung von Prozessmodellen (Beispiele)

Seite 19

2.5.3.4 Qualität der Modelle und Diagramme

Die nachstehende Abbildung zeigt die Qualitätskriterien, die bei der Modellierung zuerfüllen sind.

Abbildung 3: Qualitätskriterien der Modellierung9

Ergebnisse Wird durch eine Aktivität mehr als ein Ergebnis erzielt, sollte geprüft werden, ob diese Varianten eines Ergebnisses oder von der Art her verschiedene Ergebnisse darstellen. Bei einer Verschiedenartigkeit der Ergebnisse sowie einer hohen Anzahl von Varianten sollte eine Detaillierung in weitere Unterprozesse vorgenommen werden.

Relevanz Aktivitäten, die an der Erstellung eines Prozesses einen hohen Anteil haben, sollten zur Identifizierung von Potenzia-len detaillierter betrachtet werden und ggf. in Unterprozesse unterteilt werden.

Unabhängigkeit Aktivitäten, die unabhängige Tätigkeiten enthalten und für die keine weitere Abstimmung mit anderen Mitarbeitern und Ressourcen notwendig sind, sollten nicht detailliert wer-den.

Empfehlung 15:

Für einzelne Aktivitäten innerhalb eines Prozessmodells ist ab einer gewissen Kom-plexität notwendig, die Detaillierung zu erhöhen und Teilmodelle für diese Aktivi-täten zu bilden. Zur Identifikation solcher Aktivitäten sind Kriterien festzulegen(siehe Tabelle 3).

9. siehe [Rauh/Stickel97]

Kriterium Detaillierung

Tabelle 3: Kriterien zur Detaillierung von Prozessmodellen (Beispiele)

Verständlichkeit

Modellqualität

Vollständigkeit Komponente n(...)

...

Übersicht-lichkeit

Ausdrucksfähigkeit

SemantischeKorrektheit

Syntaktische Korrektheit

Vollständigkeit Genügsamkeit Korrektheit Redundanzfreiheit

Seite 20

• Verständlichkeit ist ein wichtiges Ziel bei der Kommunikation zwischen Füh-rungskräften, Fachanwendern, IT-Verantwortlichen und IT-Entwicklern. Über-sichtlichkeit ist notwendig, damit der Betrachter schnellstmöglich Kenntnis überdie Zusammenhänge von Prozessen und Strukturen erwirbt. Diese Zusammen-hänge anschaulich und in der notwendigen Detailliertheit darzustellen, ist Ziel derAusdrucksfähigkeit.

• Das Modell muss alle notwendigen Informationen enthalten, die später imAnwendungssystem eine Rolle spielen. Es muss dem Kriterium Vollständigkeitgenügen.

• Die Genügsamkeit wiederum meint, dass der Umfang des Systems die benötig-ten Funktionen vollständig enthält, ohne darüberhinausgehende zusätzlicheFunktionen anzubieten.

• Die Korrektheit der Modelle ist Voraussetzung dafür, dass ein Modell das aussagt,was es tatsächlich aussagen soll und dass es vom Betrachter auch so interpretiertwird. Wichtig ist es, dass eine bestimmte Syntax eingehalten wird und die Realitätzutreffend wiedergegeben wird (Semantik).

• Das Kriterium Redundanzfreiheit verlangt, dass das mehrfache Vorhandenseinein und derselben Information an verschiedenen Lokalitäten vermieden werdenmuss.10

2.5.4 Namen

Im Rahmen eines Projektes kommt es häufig vor, dass verschiedene Projektmitarbei-ter von ein und demselben Sachverhalt sprechen, dies jedoch durch unterschiedlicheBegriffe ausdrücken und sich somit nicht korrekt miteinander verständigen können.Dies kann zum Scheitern eines Projektes beitragen.

Aus diesem Grund ist es notwendig, Vorkehrungen dafür zu treffen, dass alle Projekt-mitarbeiter auf gleiche Begrifflichkeiten und Darstellungen von Namen zugreifen. Diedaraus entstehende Konsistenz soll den Vergleich und die Analyse der vorliegendenDiagramme und Modelle erleichtern sowie Mehrdeutigkeiten ausschließen.

Fachbegriffkatalog

Ein Fachbegriffkatalog ermöglicht bei der späteren Prozess- und Datenmodellierung,dass alle Beteiligten auf den gleichen Wortschatz zurückgreifen. Der Gedanke hierbeiist die Definition einer domänenspezifischen Sprache. Die Bildung eines Fachbegriff-katalogs ist ein erster Schritt in diese Richtung. Vorteil der Definition von standardi-sierten Begriffen ist eine kurze Einarbeitungszeit von organisationsfremden Personendurch Benutzung des Katalogs als übergreifendes Glossar.

10. siehe [Rauh/Stickel97], Seite 30ff.

Empfehlung 16:

Zur Verwendung einer einheitlichen Begriffswelt wird die Erstellung eines Fachbe-griffkatalogs vorgeschlagen.

Seite 21

Für die Definition einer domänenspezifischen Sprache kann in drei Schritten vorge-gangen werden:

• Einführung eines Fachbegriffkatalogs (siehe Tabelle 4)

• Erweiterung des Fachbegriffkatalogs um einen Wertebereich mit möglichen Wer-ten, die ein Begriff annehmen kann

• Verwendung der domänenspezifischen Sprache im Rahmen der Modellierung beiUnterstützung durch ein Modellierungswerkzeug, wobei der Katalog als Grund-lage während der Erstellung und bei der Überprüfung von Modellen genutzt wird

2.5.5 Dokumentation

Die Dokumentation der Modellierung ist ein wichtiger Projektbestandteil. Zweck derDokumentation ist es, während und nach Beendigung eines Projekts einen Überblicküber die Modellierungsarbeiten und -ergebnisse zu erhalten. Die Dokumentationsollte gleichzeitig mit der Modellierung erstellt und entsprechend dem Fortschritt derProjektphasen erweitert und revidiert werden. Der Fortschritt der Dokumentationund somit auch der Modellierung sollte versioniert werden, um einen Überblick darü-ber zu erlangen, wer wann aus welchem Grund Änderungen an den Modellen vorge-nommen hat.

Viele Modellierungswerkzeuge bieten die Möglichkeit, die Prozess- und Datenmo-delle sowie die dazugehörigen Beschreibungen in verschiedene Dateiformate (z. B.RTF, PDF, HTML) zu transformieren, die dann für die Gesamtdokumentation weiter-verwendet werden können.

Es wird empfohlen, dass die Dokumentation – neben den projektbezogenen Anga-ben – ausführliche Informationen über die folgenden Themen enthält:

Begriff Synonym Erläuterung

Bürger Kunde, Person natürliche Person, welche einen Antrag stellt

Vertrag Kontrakt, Übereinkom-men, Agreement

eine von zwei oder mehreren Personen unterschriebene Willensäußerung über die Herbeiführung eines bestimmten Erfolgs

Tabelle 4: Beispiel für Einträge in einem Fachbegriffkatalog

Empfehlung 17:

Zur Erfassung und Aufbereitung der erstellten Modelle, Diagramme und Datenblät-ter sollte eine detaillierte Dokumentation erstellt werden. Der Fortschritt dieserDokumentation sollte über eine Versionierung erfasst werden.

Seite 22

Vorlagen zu den in der Tabelle benannten Datenblättern sind im Anhang A aufSeite 65 zu finden.

Zusätzliche Beschreibungen zu den Diagrammen der Ist-Modelle sollten nur dannerstellt werden, wenn es mit der Hilfe der empfohlenen Standards, Methoden undWerkzeuge nicht möglich ist, bestimmte Sachverhalte darzustellen.

Die Vorlage für ein Dokument, in dem die vollständige Dokumentation über Ist- undSoll-Zustand dokumentiert werden kann, findet sich im Anhang C auf Seite 72.

Metadaten

Alle bei der Modellierung angefallenen Objekte (Modelle, Diagramme, XSD- undXMI11-Dateien) müssen anhand von Metadaten ausführlich beschrieben werden.

Die Metadaten umfassen folgende Felder:

• „Titel“

• „Beschreibung (deutsch)“

• ggf. „Beschreibung (englisch)“

• „Autor“

• „Version“

• „Themenbereich“ (auch Taxonomie12)

• „Stichwörter“

Projektphase Bestandteile der Dokumentation

Ist-Erfassung und -Modellierung

Datenblätter zur Ist-Erfassung der Prozesse und Daten

Ist-Modelle der Prozesse und Daten in Form von Diagrammen und ggf. dazugehörige Beschreibungen

Schwachstellen-analyse

Datenblätter zu Schwachstellen in Prozessen und Daten

Soll-Modellie-rung

Datenblätter zur Gegenüberstellung der Ist- und Sollzustände der Prozesse und Daten

Soll-Modelle der Prozesse und Daten in Form von Diagrammen und dazugehörige Beschreibungen

Metadaten der Modelle und Diagramme

Tabelle 5: Bestandteile der Dokumentation

11. siehe Abschnitt D.1 „Unified Modeling Language (UML)“ auf Seite 74

Empfehlung 18:

Zur Beschreibung von Modellen und Diagrammen sowie anderen Dokumentensollen Metadaten eingesetzt werden, die einheitlich festgelegt werden.

12. Eine Taxonomie bezeichnet die hierarchische Gruppierung, Klassifizierung und Strukturierung von Objekten ohne eine nähere Beschreibung (Beispiel: Evolutionsbaum der Tierarten).

Seite 23

• „Status“ (ggf. durch Werkzeug automatisch zu vergeben)

• „Erstellungsdatum“ (ggf. durch Werkzeug automatisch zu vergeben)

• „Änderungsdatum“ (ggf. durch Werkzeug automatisch zu vergeben)

Dateiformate

Die Dateiformate für die zu speichernden Modelle und Dateien sollten einheitlichfestgelegt werden, um die spätere Wiederverwendung zu gewährleisten (siehe auchAbschnitt 2.2 „Festlegung der Standards und Technologien“ auf Seite 13). Ebensomüssen die zu speichernden Dateiformate die technische Implementierung derModelle in IT-Anwendungen unterstützen. Hierzu ist insbesondere XML MetadataInterchange (XMI) geeignet (siehe Abschnitt 6.3 „Technische Implementierung derModelle“ auf Seite 63).

Versionierung von Modellen

Um einen Überblick über die vollzogenen Änderungen an Prozess- und Datenstruktu-ren zu erlangen, muss eine vollständige Dokumentation der Modelle sowie eine Versi-onsverwaltung der Modelle eingeführt werden, sodass genau nachvollzogen werdenkann, wer wann warum welche Änderungen durchgeführt hat.

Festlegung eines Status für Modelle

Der Stand der Modellierung für die einzelnen Modelle bzw. Teilmodelle sollte miteinem Status, wie zum Beispiel „in Arbeit“, „Entwurf“, „Entwurf, fachlich abgestimmt“,„freigegeben“, „nicht freigegeben“, dokumentiert werden. Die Status werden ver-bindlich für alle Modelle und Objekte in einem Projekt festgelegt.

2.5.6 Prinzipien und Varianten in der Prozessmodellierung

2.5.6.1 Allgemeine Prinzipien zur Modellierung von Prozessen

Zur Modellierung von Prozessen, insbesondere im Rahmen der Soll-Modellierung, istes empfehlenswert, die folgenden Prinzipien zu beachten:

Empfehlung 19:

Dateiformate zur Speicherung der Modelle und Diagramme sollten einheitlich fest-gelegt werden.

Empfehlung 20:

Die Erstellung der Modelle und Diagramme sollte von einer Versionierung mitMetadaten begleitet werden.

Empfehlung 21:

Während der Erstellung sollten die einzelnen Modelle und Diagramme einem Sta-tus zugeordnet werden. Die Arten von Status werden einheitlich festgelegt.

Seite 24

• Parallelität: Die Aktivitäten eines Prozesses sollten nach Möglichkeit mit einerparallelen und nicht mit einer sequentiellen Bearbeitung durchgeführt werden.Dadurch wird die Bearbeitung der Prozesse beschleunigt. Zu beachten ist jedochhierbei, dass für die parallele Bearbeitung auch genügend Ressourcen zur Verfü-gung stehen. Als Beispiel für die Darstellung von parallelen Prozessen sei hier dieCritical Path Methode13 (CPM) zu nennen – eine Vorgangspfeil-Netzplantechnik,mittels der durch Abbildung von Arbeitsabläufen die voraussichtliche Prozess-dauer bestimmt werden kann.

• Durchgängigkeit: Ein Prozess sollte von einer möglichst geringen Anzahl vonPersonen bearbeitet werden, die im Idealfall zu einer organisatorischen Einheitgehören. Dies hilft, die Anzahl der organisatorischen Schnittstellen zu verringernund dadurch Einsparungen und Qualitätssteigerungen im Prozess zu erreichen.

• Kundenorientierung: Zur Stärkung des Kundenbewusstseins in der öffentlichenVerwaltung sollte für alle Prozesse ein Kunde identifiziert werden, der den Pro-zess-Output empfängt. Dies gilt auch für verwaltungsinterne Prozesse, die einenKunden wie Bürger, Unternehmen oder andere Verwaltungen nicht haben, son-dern beispielsweise eine andere Abteilung der Verwaltung.

• Qualitätssicherung: Nach Möglichkeit sollte für jede Aktivität oder Aktivitäts-gruppe eine Kontrollfunktion eingebaut werden. Dies erhöht zwar den Zeitauf-wand für den Prozess hat aber den Vorteil, dass bei einer frühzeitigen Kontrolleder Aktivitätsdurchführung und -ergebnisse schneller auf Fehler reagiert werdenkann als bei einer am Ende des Prozesses angesiedelten Qualitätssicherung.

2.5.6.2 Varianten in Prozessen

Varianten sind Prozesse, die grundsätzlich dieselben Abläufe beinhalten, jedoch imDetail unterschiedliche Strukturen aufgrund von verschiedenen Prozessobjektenumfassen (Beispiel: Eilauftrag, normaler Auftrag). Es sollte festgelegt werden, ob dieVariantenbildung frühzeitig, in der Ist-Modellierung, oder zu einem späteren Zeit-punkt während der Soll-Modellierung erfolgen sollte.

Der Vorteil einer frühzeitigen Modellierung liegt in der Reduktion der Modellkomple-xität und damit einer höheren Verständlichkeit. Nachteile können sich durch die Ent-

13. In einem CPM-Diagramm sind alle Aktivitäten aufgeführt, miteinander in Beziehung gesetzt und frü-heste sowie späteste mögliche Start- bzw. Endtermine festgelegt. Termine kennzeichnen den Ab-schluss eines Arbeitsvorganges (Knoten). Die Knoten sind durch Kanten, gerichtete Strecken verbunden, wobei eine Pfeilrichtung die zeitliche Abfolge angibt. Die Differenz zwischen dem frühes-ten und spätesten Beginn einer Aktivität wird als Pufferzeit bezeichnet. Der Weg vom Start- zum Ziel-knoten im CPM-Plan über die Knoten mit der geringsten Pufferzeit (bzw. Pufferzeit = Null) wird Kritischer Pfad genannt. Dieser bestimmt die Dauer des Projekts und muss besonders überwacht wer-den. Kommt es bei einem Knoten vom Kritischen Pfad zu Verzögerungen, verschiebt sich der Endter-min des Projektes.

Empfehlung 22:

Die Erstellung der Prozessmodelle erfolgt unter den Prinzipien Parallelität, Durch-gängigkeit, Kundenorientierung und Qualitätssicherung.

Seite 25

stehung von Redundanzen sowie durch mangelhafte Ausnutzung von Synergieeffek-ten bilden.

Der Vorteil einer späteren Abbildung von Varianten besteht in einer besseren Ausnut-zung von Synergieeffekten und der Vereinheitlichung der Prozesse. Als Nachteilmacht sich möglicherweise die lange Vernachlässigung der Prozessvarianten bemerk-bar. Der spätere Zeitpunkt sollte insbesondere dann gewählt werden, wenn zu einemProzess eine hohe Anzahl an Varianten existiert, um die Komplexität der Modellierungsolange wie möglich gering zu halten.

Die Darstellung von Varianten ist abhängig von dem Ziel, das mit der Variantenbil-dung verfolgt wird14:

• Mehrfachzuordnung von organisatorischen Einheiten zu Aktivitäten: DieseDarstellung ist dann empfehlenswert, wenn sich die Varianten nur dadurch unter-scheiden, dass die ausführenden Organisationseinheiten unterschiedlich, dieeigentlichen Aktivitäten jedoch identisch vom Ablauf sind.

• Modellierung alternativer Zweige: Sollten jedoch, im Gegensatz zum vorange-gangenen Beispiel, die Varianten unterschiedliche Aktivitäten beinhalten, ist dieDarstellung der Varianten in unterschiedlichen Prozesszweigen zu bevorzugen.

2.5.7 Klassen und Attribute in der Datenmodellierung

2.5.7.1 Klassenbildung

Eine Klasse ist eine Sammlung gleich strukturierter Objekte (Beispiel: Klasse „Adresse“für die Adresse von Bürger A, die Adresse von Bürger B, etc.). Die Bildung ist insbeson-dere für die Wiederverwendung von gleichartigen Datenstrukturen in einem Anwen-dungssystem notwendig.

Folgende Sachverhalte sollten bei der Bildung von Klassen beachtet werden:

• Wiederverwendung: Objekte mit gleichen Strukturen sollten zu Klassen zusam-mengefasst werden.

• Eindeutigkeit: Der Name einer Klasse muss innerhalb des Diagramms eindeutigsein. Er sollte der jeweiligen Fachterminologie entsprechen und in dem Fachbe-griffkatalog enthalten sein, siehe Abschnitt 2.5.4 „Namen“ auf Seite 21.

• Namensbildung: Der Klassenname ist ein Substantiv im Singular (Beispiele: Ange-stellter, Kunde, Antrag) oder auch eine Zusammensetzung von Substantiven,siehe Abbildung 4 „Klasse Adresse“ auf Seite 28. Besteht der Klassenname ausmehreren Wörtern, ist jedes neue Wort mit einem Großbuchstaben zu beginnen

Empfehlung 23:

Der Zeitpunkt der Variantenbildung in Prozessmodellen sollte vor Beginn derModellierung festgelegt werden.

14. siehe [BeKuRo05], S. 614 f.

Seite 26

(Beispiel: AntragKindergeld, BewilligungLeistung). Der Klassenname sollte nichtdie Rolle dieser Klasse in Beziehung zu einer anderen Klassen beschreiben.

2.5.7.2 Attributbildung

Attribute dienen der Charakterisierung von Klassen (Klassenattribute), sie könnenjedoch auch als spezifisches Merkmal einzelner Datenobjekte (Objektattribute) fest-gelegt werden15. Sie beschreiben die Eigenschaften, die ein Datenobjekt bzw. dieKlasse besitzt. Ein Attribut lässt sich unter anderem als Zahlenwert (Beispiel: „815“),qualitatives Merkmal (Beispiel: „blau“) oder Text (Beispiel: „Herr Meier“) ausdrücken.Unterscheiden lassen sich diese Eigenschaften durch den Datentyp des Attributs. Die-sem Datentyp ist ein zulässiger Wertebereich zugeordnet, aus dem der Wert einesAttributs entstammt.

Attribute können innerhalb der Unified Modeling Language (UML) (sieheAbschnitt D.1 auf Seite 74) mittels unterschiedlicher Datentypen modelliert werden:

• Primitive Datentypen16

• Aufzählungsdatentypen17

• Zusammengesetzte Datentypen18

Folgende Sachverhalte sollten bei der Bildung von Attributen beachtet werden:

• Eindeutigkeit: Ein Attribut muss innerhalb einer Klasse eindeutig sein.

• Namensbildung: Der Attributname beginnt mit einem kleinen Anfangsbuchsta-ben und darf beliebige Zeichen enthalten. Er ist ein Substantiv oder ein Adjektiv-Substantiv-Verbund. Besteht der Attributname aus mehreren Wörtern, ist jedesneue Wort mit einem Großbuchstaben zu beginnen (Beispiel: beantragteLeis-tung).

Empfehlung 24:

Klassen sollten für Objekte mit gleichen Strukturen gebildet werden. Ihr Namesollte eindeutig sein und aus einem bzw. mehreren Substantiven bestehen.

15. zur Unterscheidung zwischen Datenobjekt und Klasse siehe Abschnitt 2.5.7.1 „Klassenbildung“ auf Seite 26

16. Ein primitiver Datentyp definiert einen vordefinierten Datentyp, der keine Struktur besitzt, z. B. Boole-an (true/false), String (Zeichenkette), Integer (ganze Zahlen), UnlimitedNatural (natürliche Zahlen)

17. Ein Aufzählungstyp definiert eine endliche Menge von Werten mit freier Wahl der Werte: z. B. Montag, Dienstag, …, Sonntag.

18. Zusammengesetzte Datentypen werden für die Beschreibung von komplexen Strukturen verwendet und bestehen aus allen Arten von Datentypen.

Empfehlung 25:

Zur Beschreibung der Eigenschaften von Datenobjekten werden Attribute einge-setzt. Das Attribut sollte innerhalb einer Klasse eindeutig sein. Der Name bestehtaus einem Substantiv oder einem Adjektiv-Substantiv-Verbund.

Seite 27

2.5.7.3 Beispiel zur Klassen- und Attributbildung in Datenobjekten

Folgendes Beispiel soll die Modellierung der Klasse „Adresse“ mit den dazugehörigenAttributen erläutern:

Abbildung 4: Klasse Adresse19

1. Im Modellierungswerkzeug wird das Symbol für eine Klasse ausgewählt und derKlassenname „Adresse“ vergeben.

2. Im nächsten Schritt werden die Attribute der Klasse festgelegt. Hierfür stehenzumeist im Kontextmenü des Symbols Befehle zum Hinzufügen von Attributenbereit.

3. Für jedes Attribut muss nun ein Name vergeben werden. Die Namenslänge kanndurch vorher bestimmte Modellierungskonventionen oder durch Vorgaben desModellierungswerkzeugs eingeschränkt sein.

4. Dem Attribut wird im folgenden Schritt ein entsprechender Datentyp zugeordnet:

i. Für das Attribut „strasse“ werden der Datentyp String (= Zeichenkette) undeine maximale Länge festgelegt.

ii. Auch für das Attribut „hausnummer“ werden der Datentyp String und einemaximale Länge festgelegt. Es kommt kein Datentyp für Zahlen, wie z. B. Inte-ger, zum Einsatz, da somit keine Hausnummern vom Typ „3a“ richtig erfasstwerden könnten.

iii. Für das Attribut „ort“ werden wiederum der Datentyp String und eine maxi-male Länge festgelegt.

iv. Für das Attribut „postleitzahl“ wird als Datentyp String festgelegt. Für die aus-schließliche Erfassung deutscher Postleitzahlen bietet es sich an, die Länge desAttributwertes auf fünf zu begrenzen.

5. Für jedes Attribut muss entschieden werden, ob es ein Pflichtattribut ist und somitdie Angabe eines Wertes erforderlich ist oder nicht.

6. Zusätzlich können für Attribute so genannte Default-Werte eingestellt werden –Standardwerte, die bereits hinterlegt sind. Wenn z. B. ein Amt bestimmte Anträgenur aus Berlin bearbeitet, würde das Attribut „ort“ standardmäßig mit dem Wert„Berlin“ belegt sein.

Ebenfalls können Gültigkeitsregeln hinterlegt werden, die bei Eingabe eines Wertesgeprüft werden (z. B. enthält eine E-Mail-Adresse stets ein „@“, ein Geburtsdatumkönnte das Format „TT.MM.JJJJ“ bekommen).

19. Das Beispiel ist dem UML-Klassendiagramm der Abbildung 9 auf Seite 41 entnommen.

Seite 28

2.5.7.4 Beziehungen von Datenobjekten

Beziehungen zwischen Datenobjekten oder Klassen werden als Assoziationenbezeichnet. Sie drücken eine Bindung oder Abhängigkeit zwischen zwei Objektenoder Klassen aus.

Folgende Sachverhalte sollten bei der Bildung von Beziehungen beachtet werden:

• Arten: Als Formen der Beziehung sind entweder die einfache Assoziation, Aggre-gation (Zusammenfassung von Beziehungen zu einem höherklassigen Objekt),Generalisierung (Zusammenfassen von Objektklassen) oder Spezialisierung(Unterteilen von Objektklassen) auszuwählen.

• Metadaten: Für eine Beziehung sind Name, Kardinalitäten, Rollen sowie die Bezie-hungsart anzugeben.

• Namensbildung: Der Beziehungsname ist ein Verb (Beispiel: „ist“, „sind“, „hat“,„haben“). Rollennamen werden aus Substantiven gebildet und orientieren sich anden Namen des jeweiligen Datenobjekts oder der jeweiligen Klasse.

Empfehlung 26:

Zur Darstellung von Beziehungen zwischen Datenobjekten oder Klassen werdenAssoziationen eingesetzt. Der Name der Beziehung wird aus einem Verb gebildet.

Seite 29

Seite 30

3 Ist-Erfassung und -Modellierung

Das Ziel der Ist-Erfassung und -Modellierung ist die Darstellung des momentanenZustands der Prozesse und Datenstrukturen in dem zu untersuchenden Verwaltungs-bereich.

Abbildung 5 zeigt den Ablauf bei der Ist-Erfassung und -Modellierung. Die Durchfüh-rung der Ist-Erfassung und Ist-Modellierung kann auch in einem Schritt erfolgen. DieNummerierung der einzelnen Abschnitte orientiert sich an diesem Ablauf und spie-gelt die Struktur der folgenden Abschnitte wider.

Abbildung 5: Ablauf der Ist-Erfassung und -Modellierung

3.1 Identifikation und Priorisierung von Modellierungsbereichen

Um die später zu erstellenden Modelle nicht zu groß und unübersichtlich werden zulassen, wird empfohlen, die zu untersuchenden Verwaltungsprozesse in abgegrenzteTeilbereiche zu untergliedern. Dies ist jedoch nur dann notwendig, wenn eine umfas-sende Aufnahme aller Verwaltungsprozesse oder einer Vielzahl von Prozessengeplant ist. Für die Betrachtung einzelner Prozesse ist es nicht erforderlich, Modellie-rungsbereiche zu bilden.

Empfehlung 27:

Für Projekte, in denen anschließend an die Modellierung eine Schwachstellenana-lyse stattfindet, sollte eine detaillierte Dokumentation des Ist-Zustands erfolgen.

Für Projekte, in denen sich nur ein grober Überblick über den Ist-Zustand verschafftwerden soll, genügt eine grobe Ist-Erfassung und -Modellierung.

Für Projekte, für die keine Ist-Strukturen existieren, wird mit der Soll-Modellierungbegonnen.

Abschnitt 3.1Identifikation

und Priorisierungvon Modellierungs-

bereichen

Dokumentation

Abschnitt 3.2Erfassung desIst-Zustands

von Prozessen und Daten

Abschnitt 3.3Modellierung des

Ist-Zustandsvon Prozessen und Daten

VerifizierungVerifizierung

und Abstimmung

Seite 31

Dazu werden die Prozesse bezüglich ihrer Bedeutung für die Leistungserstellung deröffentlichen Verwaltung in Kern- und Supportprozesse unterteilt:

• Kernprozesse: Prozesse, durch welche die eigentliche Leistungserstellung derVerwaltung durchgeführt wird (Beispiel: Bürgerservice)

• Supportprozesse: Prozesse, die verwaltungsintern ablaufen und die Kernpro-zesse unterstützen (Beispiel: Informationsverarbeitung, Personalentwicklung und-service)

Anschließend erfolgt eine Priorisierung der festgelegten Modellierungsbereiche nachden Zielen, die mit dem Projekt erreicht werden sollen. Die Orientierung sollte dabeinach Objekten der öffentlichen Verwaltung (Beispiel: Antrag von Personalausweis)erfolgen. Die Teilbereiche können demnach aufgrund ihrer Eigenschaft als Kern- oderSupportprozess, ihrer Kostenintensität in der Verwaltung sowie dem zu erwartendenReorganisationsbedarf in eine Rangfolge eingegliedert werden. Je höher die Prioritätdes jeweiligen Teilbereichs ist, desto detaillierter sollte die spätere Erhebung der Ist-Modelle erfolgen.

UML-Paketdiagramm

UML-Paketdiagramme (siehe Abschnitt D.1 „Unified Modeling Language (UML)“ aufSeite 74) dienen der abstrakten Darstellung eines Gesamtmodells und seiner Unter-modelle sowie seiner Elemente (Beispiel: Datenobjekte, Diagramme). Pakete sindgeeignet, sowohl fachliche als auch technische Modelle und Systeme darzustellen.

In dem vorliegenden, einfach gehaltenen Beispiel (siehe Abbildung 6) wird dasGesamtsystem (sprich das oberste Paket) „Verwaltung“ durch die drei Unterpakete„Personalverwaltung“, „Antragsverwaltung“ und „Kundenverwaltung“ näher spezifi-ziert.

Abbildung 6: UML-Paketdiagramm „Verwaltung“

Einem UML-Paketdiagramm können im Verlauf der Prozess- und Datenmodellierungweitere UML-Diagramme und Elemente zugeordnet werden (Beispiel: Paketdia-gramme, Anwendungsfalldiagramme, Aktivitätsdiagramme, Klassendiagramme).

Empfehlung 28:

Zur Darstellung von Teilbereichen eines komplexen Modellierungsgebiets solltenUML-Paketdiagramme eingesetzt werden.

Seite 32

3.2 Erfassung des Ist-Zustands

Anschließend an die Festlegung der Modellierungsbereiche wird in den identifizier-ten Teilbereichen die Erfassung der Prozesse und Daten durchgeführt, um einenÜberblick über die zu untersuchenden Leistungsbereiche der öffentlichen Verwal-tung zu erhalten.

Die Erfassung der Prozesse und Daten ist eng miteinander verbunden. Im Anschlussan die Prozesserfassung ist es notwendig, zu ermitteln, welcher Input an Daten fürden jeweiligen Prozess aufgenommen und welche Daten als Output an nachfolgendeProzesse weitergegeben werden.

Zur Beschaffung von Informationen bei der Erfassung der Prozesse und Daten wirdder Einsatz folgender Methoden empfohlen:

• Dokumentenstudium: Zu dieser Methode gehören die Erfassung und Auswer-tung der in einer öffentlichen Verwaltung befindlichen Dokumente, wie Belege,Formulare, Beschreibungen, Listen, Protokolle, Benutzer- und Prozesshandbüchersowie Verzeichnisse und Beschreibungen bereits im Einsatz befindlicher Anwen-dungen zu einem Prozess. Ebenso ist zur Informationsbeschaffung eine Erfassungder Daten geeignet, die in Bildschirmmasken der Fachverfahren und Anwendun-gen einzugeben sind.

• Interviews und Fragebögen: Über diese beiden Methoden zur Informationsbe-schaffung lassen sich insbesondere Auskünfte von Mitarbeitern mit spezifischenKenntnissen über die ausgewählte Geschäftsbereiche sowie Fachverfahren einho-len. Dies unterstützt die Entwickler von Prozess- und Datenmodellen speziell beider Interpretation von Regelungen und bei der Aufdeckung von typischen Proble-men in einem Verwaltungsprozess sowie der Verifizierung der Informationen ausdem Dokumentenstudium. Weiterhin lässt sich beispielsweise ermitteln, in wel-cher Form Daten vorliegen (Papier, tabellenähnliches Dateiformat wie CSV-Dateien oder dezentrale, abteilungsinterne Datenbanken). Der Umfang der Inter-views und Fragebögen sollte nur die Abfrage der Informationen umfassen, diewirklich benötigt werden, da auch eine Auswertung der erfassten Informationenvorgenommen werden muss.

3.2.1 Prozesse

Bei der ersten Erfassung eines Prozesses wird die Aufnahme der dazugehörigen Infor-mationen über ein Datenblatt, in dem die Eigenschaften eines Prozesses skizziert wer-den, empfohlen. Ein solches Datenblatt ist beispielhaft in Tabelle 6 abgebildet.

Empfehlung 29:

Zur Erfassung des Ist-Zustands sollten Informationen über Dokumentenstudiumeingeholt und die beteiligten Mitarbeiter über Interviews und Fragebögen befragtund werden.

Seite 33

Empfehlung 30:

Die Erfassung von grundlegenden Informationen zu Prozessen sollte mit der Hilfevon Datenblättern vorgenommen werden (siehe Anhang B „Datenblätter zurModellierung“ auf Seite 70).

Eigenschaft Ist-Wert Soll-Wert

Prozessname Antrag annehmen

Kurze Ablaufbeschrei-bung

Der Antrag des Kunden wird entgegengenommen. Syn-chron finden die Erstellung und die Versendung der Ein-gangsbestätigung sowie die Vergabe eines Postein-gangsstempels statt. Abschließend wird der Antrag an den eigentlichen Bearbeiter weitergeleitet.

Auslöser Kunde hat Antrag gesendet.

Ergebnis Antrag wurde an den eigent-lichen Bearbeiter weiterge-leitet.

Verantwortlicher Poststelle

Bearbeiter Mitarbeiter der Poststelle

Ergebnisempfänger Bearbeiter des Antrags

Beteiligte Organisati-onseinheiten mit dazu-gehöriger Mitarbei-teranzahl

Poststelle (4), Sachbearbei-tung (5)

Eingebundene Anwen-dungssysteme

keine

Abhängigkeiten zu anderen Prozessen

Im Anschluss folgt der Pro-zess „Antrag bearbeiten“.

Durchlaufzeit pro Vor-ganga

3 Tage

Kosten pro Vorgang 500 €

Tabelle 6: Datenblatt Ist-Zustand Prozess (Beispiel)

Seite 34

3.2.2 Daten

Bei der ersten Erfassung von Daten wird die Aufnahme der dazugehörigen Informati-onen über ein Datenblatt, in dem die Eigenschaften der Daten skizziert werden, emp-fohlen. Ein Beispiel für ein solches Datenblatt ist beispielhaft in Tabelle 7 abgebildet.

Fehlerhäufigkeiten Reklamationen wegen ver-späteter Weiterleitung (5 von 100)

Nacharbeiten wegen nicht erstellter Eingangsbestäti-gung (15 von 100)

Medienbrüche keine (nur Papier)

Zustand über Funktion als Kernprozess

Supportprozess

Zustand der Dokumen-tation

Dokumentation nicht vor-handen

a. Die Zeiteinheit sollte für alle Prozesse zu Beginn einheitlich und verbindlich festgelegt wer-den.

Empfehlung 31:

Die Erfassung von grundlegenden Informationen zu Daten sollte mit der Hilfe vonDatenblättern vorgenommen werden (siehe Anhang B „Datenblätter zur Modellie-rung“ auf Seite 70).


Art der Daten Antragsdaten

Quelle Papier

Datenvolumen 2 Seiten

Bestandteile und ihre Wertebereiche

Kundennummer (Zahl)

Nachname (30 Zeichen)

Vorname (30 Zeichen)

Geburtstag (2 x 2 und 1 x 4 Zif-fern)

Straße (30 Zeichen)

Hausnummer (4 Zeichen)

Tabelle 7: Datenblatt Ist-Zustand Daten (Beispiel)


Tabelle 6: Datenblatt Ist-Zustand Prozess (Beispiel)

Seite 35

3.3 Modellierung des Ist-Zustands

Zur Durchführung der Ist-Modellierung werden Workshops empfohlen. Der Vorteilvon Workshops liegt in der Einbindung von unterschiedlichen Sichtweisen in dieModelle. Der Nachteil kann sich darin äußern, dass kein gemeinsamer Nenner gefun-den wird und Hemmnisse bei den Workshop-Teilnehmern auftreten könnten, sichmitzuteilen.

Zielsetzung dieser Aktivität ist die Modellierung der bestehenden Prozesse mit dendazugehörenden Daten über eine Vervollständigung der erfassten Datenblätter(siehe Abschnitt 3.2 „Erfassung des Ist-Zustands“ auf Seite 33) sowie nach Möglichkeitdie Darstellung des Einsatzes von Informations- und Kommunikationstechnologien.

Ort (30 Zeichen)

Postleitzahl (5 Ziffern)

Titel des Antrags (30 Zeichen)

Text des Antrags (1000 Zeichen)

Posteingangsstempel (2 x 2 und 1 x 4 Ziffern)

Relevanz verwendet

Abhängigkeiten zu anderen Daten

Bei Angabe einer Kundennum-mer kann der spätere Bearbeiter auf schon vorhandene Daten einer Kundenverwaltung zurück-greifen.

Häufigkeit von Ände-rungen

Gering (Veränderung des Status)

Art und Anspruch der Datensicherung

Archivierung einer Kopie der Ein-gangsbestätigung sowie einer Kopie des Antrags

Einsatzgebiete Antragsverwaltung

Fehlerquellen Anzahl Zeichen bei Hausnum-mer reicht nicht für z. B. „28-30“

Zustand der Doku-mentation

Dokumentation nicht vorhanden

Empfehlung 32:

Die Modellierung sollte im Rahmen von Workshops durchgeführt werden.


Tabelle 7: Datenblatt Ist-Zustand Daten (Beispiel)

Seite 36

Die erstellten Modelle müssen mit den befragten Mitarbeitern verifiziert werden, umso falsche Darstellungen der Realität zu vermeiden und Missverständnisse, die wäh-rend der Erfassung sowie der Durchführung von Workshops und Interviews entstan-den sind, auszuräumen. Hierbei ist darauf zu achten, dass eine geeignete Darstel-lungsform zur Präsentation der Modelle gewählt wird (siehe Abschnitt 2.3„Zielgruppengerechte Modellierung“ auf Seite 14).

Zum Erhalt eines konsistenten Gesamt-Modells ist es am Ende notwendig, die Schnitt-stellen zwischen den einzelnen Modellierungsbereichen zu überprüfen und auftre-tende Unstimmigkeiten zwischen ihnen solange abzustimmen, bis ein realitätsge-treues Gesamt-Modell erstellt ist.

3.3.1 Prozesse

Die in der Erfassung gesammelten Prozesse sollten zuerst gruppiert nach den ermit-telten Bereichen modelliert werden, wobei eingangs zu prüfen ist, ob für diesen Pro-zess bereits ein detailliertes Prozessmodell vorliegt, das wiederverwendet werdenkann.

Die grobe Modellierung (siehe Tabelle 1 „Geeignete Standards und Technologien zurModellierung“ auf Seite 13) der Prozesse kann mit der Hilfe von EreignisgesteuertenProzessketten (EPK) oder Flussdiagrammen erfolgen (siehe Abschnitt D.2 auf Seite 76und Abschnitt D.3 auf Seite 77).

Zur detaillierten Ist-Modellierung – aber auch zur groben Modellierung – der Prozessesind insbesondere UML-Anwendungsfalldiagramme und UML-Aktivitätsdiagrammegeeignet (Beispiel im Anschluss an die Empfehlung, weitere Informationen zu UMLsiehe Abschnitt D.1 auf Seite 74).

UML-Anwendungsfalldiagramm

Das Anwendungsfalldiagramm (auch: Use-Case-Diagramm) dient dazu, das Verhalteneines Systems aus Sicht der Nutzer darzustellen. Es umfasst die Darstellung der Nutzer(auch: Akteure), die Anwendungsfälle und deren Beziehungen untereinander. EinAkteur kann sowohl eine Person als auch ein anderes System (z. B. Vorgangsbearbei-tungssystem) sein. Ein Anwendungsfall spiegelt die Reaktion des Systems auf äußereEinflüsse wider und stellt Dienstleistungen des Systems dar.

Empfehlung 33:

Die erstellten Modelle sollten mit den befragten Mitarbeitern verifiziert und abge-stimmt werden.

Empfehlung 34:

Für die grobe Prozessmodellierung werden Ereignisgesteuerte Prozessketten (EPK),Flussdiagramme oder UML-Anwendungs- und Aktivitätsdiagramme eingesetzt.

Für die detaillierte Prozessmodellierung wird die Unified Modeling Language(UML) – insbesondere Anwendungsfall- und Aktivitätsdiagramme – eingesetzt.

Seite 37

In dem vorliegenden Beispiel wird ein Anwendungsfalldiagramm für das Paket„Antragsverwaltung“ erstellt.

Abbildung 7: UML-Anwendungsfalldiagramm der Antragsverwaltung (Ist-Zustand)

Das Diagramm beinhaltet die folgenden Akteure: „Bearbeiter“, „Poststelle“ und„Kunde“.

Die dargestellten Anwendungsfälle sind:

• Antrag stellen

• Antrag annehmen

• Antrag bearbeiten

• Bescheid erteilen

• Maßnahmen einleiten

Dem Diagramm lassen sich die folgenden Sachverhalte entnehmen:

• Kunde stellt Antrag

• Poststelle nimmt Antrag entgegen

• Poststelle leitet Antrag an Bearbeiter weiter

• Bearbeiter bearbeitet Antrag

• Bearbeiter leitet Maßnahmen ein

• Bearbeiter erteilt Bescheid

• Poststelle versendet Bescheid

Auf der Grundlage des UML-Anwendungsfalldiagramms können für die darin befind-lichen Anwendungsfälle detailliertere UML-Aktivitätsdiagramme erstellt werden.

UML-Aktivitätsdiagramm

Aktivitätsdiagramme dienen der Modellierung der eigentlichen Abläufe innerhalbeines Anwendungsfalls. Bei der Modellierung werden unter anderem paralleleAbläufe, Verzweigungen, Zusammenführungen und Ähnliches dargestellt.

Seite 38

Bei der Erstellung weiterer Aktivitätsdiagramme sollte darauf geachtet werden, dasseingebundene Datenobjekte, die auch in anderen Aktivitätsdiagrammen existieren,nach Möglichkeit in gleicher Art und Weise wiederverwendet werden.

Das Aktivitätsdiagramm „Antrag annehmen“ (siehe Abbildung 8) beinhaltet die Akti-vitäten, die der Akteur „Poststelle“ durchführt, um einen Antrag für eine öffentlicheVerwaltung anzunehmen, sowie die Objekte (auch: Gegenstände), die durch die Akti-vitäten ihren Zustand ändern:

1. Antrag wurde gesendet

2. Poststelle nimmt Antrag entgegen

3. Antrag wurde empfangen

4. Paralleler Ablauf

i. Eingangsbestätigung

• Poststelle erstellt Eingangsbestätigung

• Eingangsbestätigung ist erstellt

• Poststelle sendet Eingangsbestätigung

Abbildung 8: UML-Aktivitätsdiagramm „Antrag annehmen“

Seite 39

• Eingangsbestätigung wurde gesendet

ii. Poststempel

• Poststelle vergibt Posteingangsstempel

• Antrag ist gestempelt

5. Eingangsbestätigung wurde gesendet und Antrag ist gestempelt

6. Poststelle leitet Antrag an Bearbeiter weiter

7. Antrag wurde weitergeleitet

3.3.2 Daten

Abhängig von der gegebenen Projektsituation kann es sinnvoll sein, eine Ist-Model-lierung der Daten durchzuführen. Als Beispiel sei hier die Überführung eines komple-xen bestehenden Prozesses von der reinen Papierbasis hin zur Nutzung von Informa-tionstechnologie genannt. Im zurzeit stattfindenden Ablauf des Prozesses könnte dieErfassung falscher beziehungsweise redundanter Daten vermutet werden.

Um eine spätere Schwachstellenanalyse durchzuführen, wird die Modellierung einesDatenmodells in Form von Entity-Relationship-Diagrammen (siehe Abschnitt D.4„Entity-Relationship-Diagramm (ERD)“ auf Seite 78) beziehungsweise UML-Klassendi-agrammen vorgeschlagen (siehe Abschnitt D.1 „Unified Modeling Language (UML)“auf Seite 74).

UML-Klassendiagramme sind insbesondere für eine detaillierte Dokumentation desIst-Zustands geeignet. Ein Beispiel für ein UML-Klassendiagramm ist im Anschluss andie Empfehlung dargestellt.

UML-Klassendiagramm

Das vorliegende Klassenmodell stellt die Klassen und ihre Beziehungen (auch: Assozi-ationen) zueinander dar, die bei der Antragsverwaltung erforderlich sind. Beim Anle-gen einer Klasse wird diese oftmals einem Package (Paket, siehe auch Paketdiagrammin Abschnitt 3.1 „Identifikation und Priorisierung von Modellierungsbereichen“ auf

Empfehlung 35:

UML-Anwendungsfalldiagramme werden zur Beschreibung von einfachen Abläu-fen in der Sprache der Anwender bzw. Fachabteilungen eingesetzt.

Mittels UML-Aktivitätsdiagrammen lassen sich komplexe Abläufe wesentlich detail-lierter beschreiben. Es ist möglich, Ausnahmen, Varianten, Sprünge und Wiederho-lungen in einem UML-Aktivitätsdiagramm verständlich darzustellen.

Empfehlung 36:

Für die grobe Datenmodellierung werden Entity Relationship Diagramme (ERD)oder UML-Klassendiagramme eingesetzt.

Insbesondere für eine detaillierte Datenmodellierung werden UML-Klassendia-gramme empfohlen.

Seite 40

Seite 31) und damit einer funktionalen Leistungseinheit einer öffentlichen Verwal-tung zugeordnet (siehe Abschnitt D.1 „Unified Modeling Language (UML)“ aufSeite 74).

Das Anlegen einer Klasse und deren Attribute wird im Abschnitt 2.5.7.2 auf Seite 27beschrieben.

Abbildung 9: UML-Klassendiagramm der Antragsverwaltung (Ist-Zustand)

Das Modell in der Abbildung 9 zeigt eine Klasse „Kunde“ in Beziehung zu einer Klasse„Antrag“, wobei die Beziehung dieser zwei Klassen aussagt, dass ein Kunde keinen bisunendlich viele Anträge stellen und ein Antrag wiederum genau einem Kunden zuge-ordnet werden kann (Kardinalität: * – Kann-Beziehung). Der Kunde besitzt eine odermehrere Adressen. Eine Adresse kann wieder genau einem Kunden zugeordnet wer-den. Der Unterschied zur Beziehung Kunde-Antrag liegt darin, dass der Kunde miteiner Adresse angelegt werden muss (Kardinalität: 1..* – Muss-Beziehung). Dem Kun-den ist eine Rolle zugeordnet, ebenso dem Mitarbeiter, der die Anträge bearbeitet.Eine Rolle könnte z. B. ein „Antragsteller“, ein „Sachbearbeiter“ oder eine „Leitungs-kraft“ sein. Ein Mitarbeiter kann unbegrenzt viele Anträge bearbeiten, ein Antrag wie-derum kann von einem bis mehreren Mitarbeitern bearbeitet werden (* entsprichtmultiple, mehrfach). Weiterhin kann, aber muss nicht, ein Antrag Anlagen enthalten.Außerdem wird für einen Antrag genau eine Eingangsbestätigung erstellt. Diese kannumgekehrt genau einem Antrag zugeordnet werden (1:1-Beziehung).

Die folgende Übersicht zur Kardinalität stellt die Optionen dar, mit wie vielen Instan-zen der Klasse A eine Instanz der Klasse B verbunden sein kann bzw. muss.

Seite 41

Abbildung 10: Beschreibung der Kardinalität

Seite 42

4 Schwachstellenanalyse

Im Anschluss an die Ist-Modellierung der Prozesse und Daten erfolgt die Analyse desGesamtmodells auf Schwachstellen, welche noch nicht bekannt oder offensichtlichsind, sowie die Dokumentation der schon bekannten Schwachstellen.

Eine Übersicht zum Verlauf der Schwachstellenanalyse der Prozesse wird inAbbildung 11 gegeben.

Abbildung 11: Ablauf der Schwachstellenanalyse

4.1 Festlegung von Kriterien zur Schwachstellenidentifikation

Zur Identifikation der Schwachstellen von Prozessen und Daten ist es notwendig, Kri-terien festzulegen, nach welchen die Analyse der Modelle erfolgen soll. Die Kriteriensollten sich an den Zielen der jeweiligen öffentlichen Verwaltung orientieren.

Verwaltungsziele bezüglich der Prozess- und Datenmodellierung bewegen sich häu-fig in dem folgenden Rahmen:

• Eliminierung von unnötigen Prozessschritten

• Auslagerung von Prozessschritten

• Zusammenfassung von Prozessschritten

• Detaillierung von Prozessschritten

• Parallelität von Prozessschritten

• Optimierung von Schnittstellen zwischen Prozessschritten

• Beschleunigung von Prozessschritten durch Einsatz von Informations- und Kom-munikationstechnologien

• Optimierung der Datenhaltung durch ein zentrales Datenbanksystem

In Tabelle 8 sind Beispiele für Kriterien aufgeführt, mit deren Hilfe Schwachstellenermittelt werden können.

Abschnitt 4.1Festlegung von Kriterien

zur Schwachstellen-identifikation

Abschnitt 4.2Identifikation und Dokumentation der

Schwachstellen

Abschnitt 4.3Ermittlung und Priorisie-

rung von Verbesse-rungsmöglichkeiten

Seite 43

Kriteriengruppe Kriterium

Informations- und Kommunikationstech-nologien

Einbindung in bestehende Anwendungssysteme

Speicherung relevanter Daten

Speicherung redundanter Daten

Zuordnung eines Datenobjektes zu einem Prozess

Abhängigkeiten zwischen Datenobjekten

Elektronischer Austausch von Daten

Modernität und Leistung der Informations- und Kommuni-kationstechnologien

Einsatz unterschiedlicher Informations- und Kommunikati-onstechnologien für identische Aufgaben

Ablauforganisation Ersetzbarkeita

a. Beispiel: Weiterleitung von Akten erfolgt nicht mehr auf der Grundlage eines verwaltungsin-ternen Postdienstes, sondern durch die Zuteilung zu einem anderen Bearbeiter in einemVorgangsbearbeitungssystem.

Paralleler Verlauf von Aktivitäten

Verwaltungsinterne und -externe Schnittstellenb

b. Durch die Minimierung der Schnittstellen kann eine Reduzierung der Liege- und Einarbei-tungszeiten erfolgen.

Aufbauorganisation Entscheidungs- und Bearbeitungsverantwortung

Klarheit der Aufgabenzuordnung

Anzahl der betroffenen Hierarchieebenen

Anreizsysteme

Notwendige Qualifikation zur Bearbeitung

Qualifikation des Bearbeitungsverantwortlichen

Tabelle 8: Auswahl von Kriterien zur Schwachstellenanalysec

c. siehe [BeKuRo05], S. 173 ff.

Empfehlung 37:

Vor Beginn der Schwachstellenanalyse werden Kriterien wie z. B. der elektronischeAustausch von Daten oder die Qualifikation zur Aufgabenbearbeitung festgelegt,anhand derer die Identifikation von Schwachstellen erfolgen soll.

Seite 44

4.2 Identifikation und Dokumentation der Schwachstellen

Anhand der festgelegten Kriterien erfolgt nun die Analyse der Ist-Modelle hinsichtlichSchwachstellen und Verbesserungsmöglichkeiten sowie ihrer Auswirkungen auf dieöffentliche Verwaltung. Für diesen Vorgang sollten insbesondere Mitarbeiter mit ana-lytischen Fähigkeiten eingebunden werden.

Beispiele für Schwachstellen sind unter anderem:

• Unzureichendes Vorhandensein von Bearbeitern

• Unzureichende Verfügbarkeit von Daten (Beispiel: Bearbeiter muss die Informatio-nen suchen bzw. auf sie warten)

• Unnötige Aktivitäten und Daten (Beispiel: Mehrfacherfassung)

• Hohe Anzahl beteiligter Organisationseinheiten

• Hohe Anzahl an Rückkopplungen

• Hohe Anzahl an unnötigen Kontrollschritten

• Medienbrüche

Um die identifizierten Schwachstellen zu dokumentieren und zu systematisieren, wirdempfohlen, diese anhand von einheitlichen Merkmalen zu beschreiben. Dazu könnteunter anderem ein Datenblatt mit den in Tabelle 9 dargestellten Eigenschaften heran-gezogen werden.

Eigenschaft Wert

Kurzbezeichnung Langwierige Annahme und Weiterleitung von Anträgen

Beschreibung Die Annahme und Weiterleitung von Anträgen nimmt ca. 3 Tage in Anspruch. Rechnet man noch die 3 Tage hinzu, die ein Antrag benötigt, um auf postalischen Wegen vom Antragsteller zur öffentlichen Verwaltung zu gelangen, benötigt der Antrag 6 Tage bis die eigentliche Bearbeitung des Antrags beginnt.

Ursachen Abhängigkeit von Post und von Frequentierung der Post-stelle durch andere Schriftstücke

Verbesserungspotenzi-ale

Minimierung der Annahme- und Weiterleitungszeiten, Ver-ringerung von Fehlern bei der Datenangabe durch Voll-ständigkeits- und Plausibilitätstests in Web-Formular

Betroffene Organisati-onseinheiten

Poststelle, Bearbeiter, Kunde

Typa Ablauforganisation und Informations- und Kommunikati-onstechnologien

Tabelle 9: Datenblatt Schwachstelle (Beispiel)

Seite 45

4.3 Ermittlung und Priorisierung von Verbesserungsmöglichkeiten

Eng verbunden mit der Ermittlung von Schwachstellen ist die Ermittlung von Verbes-serungsmöglichkeiten. Dies beinhaltet die Diskussion der Schwachstellen sowie dereventuell schon dokumentierten Lösungsalternativen und Sofortmaßnahmen mitden betroffenen Mitarbeitern. Ziel dieses Schrittes ist es, Verbesserungsvorschläge zusammeln und zu analysieren. Als Methoden zur Durchführung werden Workshopsempfohlen.

Folgende Punkte sollten diskutiert und geklärt werden:

• Möglichkeiten zur Vereinfachung eines Teilprozesses (Beispiel: Formulare, Text-bausteine)

• Wege zur Vermeidung von Doppelarbeiten (Beispiel: Mehrfacherfassung)

• Mittel zur Beseitigung von Fehlerquellen bei der Bearbeitung

• Identifikation von zwingend erforderlichen Aktivitäten

Ausmaß Durch eine nicht schnell durchgeführte Annahme und Weiterleitung der Anträge durch die Poststelle verzögert sich auch die weitere Bearbeitung der Anträge. Die Verwal-tungskunden reagieren darauf mit verstärkten Anrufen nach dem Bearbeitungsstand ihres Antrags, welche die Bearbeiter wiederum von einer schnellstmöglichen Bear-beitung der Anträge abhalten.

Priorität der Bearbei-tungb

8 (hoch)

Lösungsalternativen und Sofortmaßnah-menc

Umstellung auf Antragstellung über Online-Dienste, Schu-lungen von Mitarbeitern der Poststelle zu Sachbearbeitern

a. Beispiel: Aufbauorganisation, Ablauforganisation, Informations- und Kommunikationstech-nologien

b. Beispiel: Skala von 0 (sehr niedrig) bis 10 (sehr hoch)c. Beispiel: Kompetenzverlagerungen, personelle Veränderungen, Beschaffungsmaßnahmen,

Automatisierungsmaßnahmen, Schulungen

Empfehlung 38:

Die Dokumentation einer Schwachstelle erfolgt über ein Datenblatt, welches diewesentlichen Informationen zu der Schwachstelle enthält.

Empfehlung 39:

Für die Ermittlung und Diskussion von Verbesserungsmöglichkeiten werden Work-shops durchgeführt.

Eigenschaft Wert

Tabelle 9: Datenblatt Schwachstelle (Beispiel)

Seite 46

Um die ermittelten Verbesserungsmöglichkeiten später auch wirklich umsetzen zukönnen, ist es notwendig, sie auf bestimmte Rahmenbedingungen hin zu untersu-chen:

• Verfügbarkeit von Ressourcen: Die Verbesserung eines Prozesses macht für dieöffentliche Verwaltung keinen Sinn, wenn die dafür notwendigen Ressourcen(Beispiel: Personal, Maschinen) nicht vorhanden sind. Es muss deshalb sicherge-stellt werden, dass Ressourcen in ausreichendem Maße zur Verfügung stehenbeziehungsweise beschafft werden können.

• Technische Realisierbarkeit der Änderungen: Neben der ausreichenden Ver-fügbarkeit der Ressourcen muss auch die technische Realisierbarkeit der Verbes-serungsvorschläge an sich gewährleistet sein. Es wird deswegen empfohlen, inZusammenarbeit mit IT-Entwicklern zu ermitteln, ob die Verbesserung mit dengegebenen technischen Möglichkeiten in Abstimmung mit der Fachabteilungrealisiert werden kann.

• Umfang der Änderungen an den Anwendungssystemen: Falls umfassendeÄnderungen an den bestehenden Anwendungssystemen aufgrund der Verbesse-rung eines Prozesses oder von Datenstrukturen vorgenommen werden müssten,ist es oft sinnvoll, diese Änderungen in Teilschritten zu vollziehen.

• Kosten: Bei der Umsetzung eines Prozesses lassen sich im Wesentlichen zweiArten von Kosten identifizieren. Auf der einen Seite die Kosten zur technischenund organisatorischen Umsetzung (Beispiel: Neueinstellung von Personal) sowieauf der anderen Seite die Betriebskosten zur anschließenden Durchführung derProzesse. Hierbei ist insbesondere darauf zu achten, dass die Betriebskosten desProzesses für die Zukunft im Vergleich zu den momentanen Kosten sinken. ImGegenzug dazu ist es bei den Umsetzungskosten häufig notwendig, umfangrei-che Investitionen zu leisten.

Die Diskussion bei der Priorisierung von Verbesserungsmöglichkeiten kann durch denEinsatz der Portfolio-Technik unterstützt werden. Bei dieser Technik werden Kriterien-paare gebildet und anschließend entsprechend ihrer Eigenschaften in einem Koordi-natensystem dargestellt (siehe Abbildung 12 auf Seite 48). Der Vorteil der Technikliegt in der grafischen Darstellung und Gegenüberstellung von zu vergleichendenVerbesserungsmöglichkeiten.

Zu beachten bleibt, dass meist nicht nur ein Kriterienpaar ausreicht, um die Umset-zung von Verbesserungsvorschlägen bewerten zu können. Häufig müssen mehrerePortfolios mit unterschiedlichen Kriterien betrachtet werden, um zu einem endgülti-gen Ergebnis zu kommen.

Empfehlung 40:

Ermittelte Verbesserungsmöglichkeiten sollten hinsichtlich der Verfügbarkeit vonRessourcen, der technischen Realisierbarkeit, dem Änderungsumfang an denbestehenden Anwendungssystemen sowie der Kosten untersucht und diskutiertwerden.

Seite 47

Abbildung 12: Beispiel für Portfolio-Technik

Empfehlung 41:

Für die Priorisierung von Verbesserungsvorschlägen wird der Einsatz der Portfolio-Technik vorgeschlagen.

Ein

führu

ngs

kost

en

Betriebskosten

niedrig hoch

nie

dri

gh

och

V4

V3

V1

V2

Seite 48

5 Soll-Modellierung

Auf Basis der erstellten Ist-Modelle, der Schwachstellenanalyse und der Ermittlungder Verbesserungsmöglichkeiten wird die Soll-Modellierung durchgeführt. Das Zielder Soll-Modellierung ist die Darstellung des zukünftigen Zustands der Prozesse undDatenstrukturen in dem zu untersuchenden Verwaltungsbereich.

Je nachdem ob die Ergebnisse der Soll-Modellierung eine grobe Richtungsweisungfür die spätere Entwicklung der IT-Anwendung geben oder ob die Modelle überTransformation in Quellcode direkt in deren Entwicklung einfließen, erfolgt die Ent-scheidung über eine grobe beziehungsweise detaillierte Dokumentation des Soll-Zustands in Modellen. Weiterhin ist zusätzlich eine einfache Gegenüberstellung derIst- und Soll-Zustände zu empfehlen, um den Führungskräften sowie den IT-Verant-wortlichen der öffentlichen Verwaltung den Umfang der eintretenden Veränderun-gen zu verdeutlichen. Dies ist insbesondere notwendig, um die spätere Umsetzungder optimierten und verbesserten Strukturen nicht zu gefährden und den Erfolg desProjekts gewährleisten zu können.

Die im Zuge der Ist-Erfassung und -Modellierung von Prozessen und Daten festgeleg-ten Modellierungsbereiche werden beibehalten (siehe auch Abschnitt 3.1 „Identifika-tion und Priorisierung von Modellierungsbereichen“ auf Seite 31).

Abbildung 13 zeigt den Ablauf der Soll-Modellierung. Die Entwicklung des Soll-Zustands und die Soll-Modellierung können auch in einem Schritt erfolgen. Die Num-merierung orientiert sich an den einzelnen Abschnitten dieses Kapitels.

Abbildung 13: Ablauf der Soll-Modellierung

Empfehlung 42:

Für eine grobe Richtungsweisung für die Entwicklung einer IT-Anwendung genügteine grobe Modellierung des Soll-Zustands.

Für eine Transformation der Modelle in Quellcode wird eine detaillierte Modellie-rung des Soll-Zustands der Prozesse und Daten durchgeführt.

Abschnitt 5.1Entwicklung des

Soll-Zustandsvon Prozessen und Daten

Dokumentation

Abschnitt 5.2Modellierung des

Soll-Zustandsvon Prozessen und Daten

Abstimmung

Seite 49

5.1 Entwicklung des Soll-Zustands

Es erfolgt eingangs zur Soll-Modellierung – auf der Grundlage der Ist-Erfassung – eineDarstellung der groben Prozess- und Datenstrukturen in den einzelnen Modellie-rungsbereichen, wie sie zukünftig gestaltet und umgesetzt werden sollen.

5.1.1 Prozesse

Für die Entwicklung des Soll-Zustands eines Prozesses wird der Einsatz des schon inder Erfassung des Ist-Zustands erstellten Datenblatts empfohlen (siehe Tabelle 6 aufSeite 34), in das die zukünftigen Eigenschaften eines Prozesses skizziert werden. VonVorteil ist die tabellarische Gegenüberstellung des Ist- und Soll-Zustands, um Unter-schiede und die entscheidenden Verbesserungen zu verdeutlichen. Für gänzlich neueProzesse ist eine solche Gegenüberstellung hinfällig. Hier ist eine Dokumentation desSoll-Prozesses ausreichend. Ein Beispiel für ein solches Datenblatt ist in Tabelle 10abgebildet.

Empfehlung 43:

Die Entwicklung des Soll-Zustands eines Prozesses kann über den Einsatz einesDatenblatts erfolgen, in dem der Ist-Zustand dem Soll-Zustand gegenübergestelltwird.

Für gänzlich neue Prozesse ist eine Gegenüberstellung mit dem Ist-Zustand nichtnotwendig.


Prozessname Antrag annehmen Antrag annehmen

Kurze Ablaufbe-schreibung

Der Antrag des Kunden wird entgegengenom-men. Synchron finden die Erstellung und die Versendung der Ein-gangsbestätigung sowie die Vergabe eines Posteingangsstempels statt. Abschließend wird der Antrag an den eigentlichen Bearbeiter weitergeleitet.

Der Antrag des Kunden wird über ein E-Mail-System der öffentlichen Verwaltung entgegengenommen. Automatisch wird eine Eingangs-bestätigung versendet. Gleichzei-tig wird der Antrag entschlüsselt, die elektronische Signatur geprüft und ein Zeitstempel für den elek-tronisch vorliegenden Antrag ver-geben. Anschließend wird der Antrag an den eigentlichen Bear-beiter über ein Vorgangsbearbei-tungssystem weitergeleitet. Alter-nativ soll auch der herkömmliche Weg der Antragstellung über die Post bestehen bleiben.

Auslöser Kunde hat Antrag per Post gesendet.

Kunde hat Antrag per Web-Formu-lar oder per Post versendet.

Tabelle 10: Datenblatt Soll-Zustand Prozess (Beispiel)

Seite 50

Ergebnis Antrag wurde an den eigentlichen Bearbeiter per Hauspost weiterge-leitet.

Antrag wird in das Vorgangsbear-beitungssystem überführt und einem Bearbeiter zugewiesen.

Verantwortlicher Poststelle Poststelle, IT-Abteilung

Bearbeiter Mitarbeiter der Poststelle Mitarbeiter der Poststelle

Ergebnisempfänger Bearbeiter des Antrags Bearbeiter des Antrags

Beteiligte Organisa-tionseinheiten mit dazugehöriger Mit-arbeiteranzahl

Poststelle (4), Sachbear-beitung (5)

Poststelle (2), Sachbearbeitung (6)

Eingebundene Anwendungssys-teme

keine E-Mail-System, Vorgangsbearbei-tungssystem


Im Anschluss folgt der Prozess „Antrag bearbei-ten“.

Im Anschluss folgt der Prozess „Antrag bearbeiten“, wenn die Antragstellung über Web erfolgt. Bei Antragstellung über Papier folgt der Prozess „Antrag erfassen“.

Durchlaufzeit pro Vorganga

3 Tage 15 Minuten

Kosten pro Vorgang 500 € 50 €

Fehlerhäufigkeitenb Reklamationen wegen verspäteter Weiterlei-tung (5 von 100)

Nacharbeiten wegen nicht erstellter Eingangs-bestätigung (15 von 100)

Medienbrüche keine (nur Papier) keine (für elektronischen Antrag) oder Papier-Vorgangsbearbei-tungssystem (für Papier-Antrag)

Zustand über Funk-tion als Kernprozess

Supportprozess Supportprozess

Zustand der Doku-mentation

Dokumentation nicht vorhanden

UML-Diagramme

a. Die Zeiteinheit sollte für alle Prozesse zu Beginn festgelegt werden.b. Beispiel: Anzahl von Reklamationen und Nacharbeiten


Tabelle 10: Datenblatt Soll-Zustand Prozess (Beispiel)

Seite 51

In der Übersicht wird deutlich, dass die folgenden Veränderungen geplant sind:

• Antragstellung auch über Web-Formular

• Elektronische Verschlüsselung und Signatur werden eingeführt

• Zeitstempel wird automatisch vergeben

• Eingangsbestätigung wird automatisch erzeugt und versendet

• Antrag wird automatisch an Vorgangsbearbeitungssystem weitergeleitet

• E-Mail-System und Vorgangsbearbeitungssystem werden eingebunden

• Folgen: Verkürzung der Prozesszeit auf 15 Minuten (vorher 3 Tage), Verringerungder Kosten auf durchschnittlich 50 € pro Antrag (vorher 500 €)

• Medienbruch, falls noch Papierantrag gestellt und dieser ins Vorgangsbearbei-tungssystem eingestellt wird

5.1.2 Daten

Für die Entwicklung des Soll-Zustands von Daten wird der Einsatz des schon in der Ist-Erfassung erstellten Datenblatts empfohlen (siehe Tabelle 7 auf Seite 35), in dem diezukünftigen Eigenschaften der Daten skizziert werden. Von Vorteil ist die tabellari-sche Gegenüberstellung des Ist- und Soll-Zustands, um Unterschiede und die ent-scheidenden Verbesserungen zu verdeutlichen. Für gänzlich neue Daten ist eine sol-che Gegenüberstellung hinfällig. Hier ist eine Dokumentation des Soll-Zustandsausreichend. Ein Beispiel für ein solches Datenblatt ist in Tabelle 11 abgebildet.

Empfehlung 44:

Die Entwicklung des Soll-Zustands von Datenstrukturen kann über den Einsatzeines Datenblatts erfolgen, in dem der Ist-Zustand dem Soll-Zustand gegenüberge-stellt wird.

Für gänzlich neue Datenstrukturen ist eine Gegenüberstellung mit dem Ist-Zustandnicht notwendig.


Art der Daten Antragsdaten Antragsdaten

Quelle Papier Papier / Web-Formular

Datenvolumen 2 Seiten 2 Seiten / 16 Formularfelder


Kundennummer (Zahl)



Geburtstag (2 x 2 und 1 x 4 Ziffern)

Kundennummer (Zahl)



Geburtstag (2 x 2 und 1 x 4 Ziffern)

Tabelle 11: Datenblatt Soll-Modellierung Daten (Beispiel)

Seite 52

In der Übersicht wird deutlich, dass die folgenden Veränderungen geplant sind:

• die Anzahl vorgesehener Zeichen für die Hausnummer werden erhöht

• als Datenquelle dienen zukünftig neben Papierformularen auch Web-Formulare

• neben den schon in der Vergangenheit erfassten Daten für einen Antrag wird inZukunft zusätzlich das Formularfeld „E-Mail-Adresse“ abgefragt

• Datensicherung nimmt für Web-Formulare an Umfang zu

• Verschlüsselung der Daten erfolgt und






Ort (30 Zeichen)


Titel des Antrags (30 Zei-chen)

Text des Antrags (1000 Zei-chen)

Posteingangsstempel (2 x 2 und 1 x 4 Ziffern)

Ort (30 Zeichen)


Titel des Antrags (30 Zei-chen)

Text des Antrags (1000 Zei-chen)

Zeitstempel (2 x 2 und 1 x 4 Ziffern)

E-Mail-Adresse (30 Zeichen)

Relevanz Verwendet Verwendet


Bei Angabe einer Kunden-nummer kann der spätere Bearbeiter auf schon vor-handene Daten einer Kun-denverwaltung zurückgrei-fen.

Bei Angabe einer Kunden-nummer kann der spätere Bearbeiter auf schon vor-handene Daten einer Kun-denverwaltung zurückgrei-fen.

Häufigkeit von Ände-rungen

Gering (Veränderung des Status)

Gering (Veränderung des Status sowie Ergänzungen)

Art und Anspruch der Datensicherung

Archivierung einer Kopie der Eingangsbestätigung sowie einer Kopie des Antrags

Elektronische Verschlüsse-lung und Signatur des Antrags, Ausdruck / Kopie des Antrags für Archiv

Einsatzgebiete Antragsverwaltung Antragsverwaltung

Fehlerquellen Keine bekannt Keine bekannt

Zustand der Dokumen-tation

Dokumentation nicht vor-handen

UML-Diagramme und XML-Schema


Tabelle 11: Datenblatt Soll-Modellierung Daten (Beispiel)

Seite 53

• elektronische Signatur wird eingeführt

5.2 Modellierung des Soll-Zustands

Zielsetzung dieser Aktivität ist die Modellierung der angestrebten Prozesse undDaten auf der Grundlage der Datenblätter sowie nach Möglichkeit die Darstellung desEinsatzes von Informations- und Kommunikationstechnologien.

Die Soll-Modellierung findet unter Berücksichtigung der in der Schwachstellenana-lyse festgestellten Schwachstellen und Verbesserungsvorschläge statt.

Zum Erhalt eines stimmigen Gesamt-Modells ist die Darstellung des abgestimmtenGesamtmodells als UML-Paketdiagramm geeignet (siehe Abschnitt 3.1 „Identifikationund Priorisierung von Modellierungsbereichen“ auf Seite 31).

Die erstellten Modelle sind mit den für die Prozesse und Datenstrukturen verantwort-lichen Mitarbeitern abzustimmen, um so falsche Darstellungen und Missverständ-nisse zu vermeiden. Nach erfolgreicher Prüfung auf Vollständigkeit und Korrektheitdurch die Verantwortlichen gelten die Modelle als abgenommen.

5.2.1 Prozesse

Die Soll-Prozesse werden nacheinander einzeln auf der Basis der vorliegenden Ist-Modelle und Soll-Werte modelliert. Anschließend werden diese Prozesse des Teilbe-reichs untereinander so abgestimmt, dass ein in sich stimmiges Teil-Prozessmodellentsteht.

Die grobe Soll-Modellierung kann mit der Hilfe von Ereignisgesteuerten Prozessket-ten (siehe Abschnitt D.2 auf Seite 76) sowie von Flussdiagrammen durchgeführt wer-den (siehe Abschnitt D.3 auf Seite 77). Wie auch für die Ist-Modellierung ist die detail-lierte Darstellung – aber auch die grobe Modellierung – der Soll-Prozesse durch UML-Anwendungsfalldiagramme und UML-Aktivitätsdiagramme geeignet (sieheAbschnitt D.1 „Unified Modeling Language (UML)“ auf Seite 74).

Das nachfolgende Beispiel erläutert den Einsatz der UML-Diagramme.

Empfehlung 45:

Die erstellten Modelle sollten in Zusammenarbeit mit den Verantwortlichen abge-stimmt werden.

Empfehlung 46:

Für die grobe Prozessmodellierung werden Ereignisgesteuerte Prozessketten (EPK),Flussdiagramme oder UML-Anwendungsfall- und Aktivitätsdiagramme eingesetzt.

Für die detaillierte Modellierung mit anschließender Code-Generierung wird dieUnified Modeling Language (UML) – insbesondere Anwendungsfall- und Aktivitäts-diagramme – eingesetzt.

Seite 54


Für das vorliegende Beispiel wird das Anwendungsfalldiagramm für das Paket„Antragsverwaltung“ aus der Ist-Modellierung (siehe Abschnitt 3.3.1 auf Seite 37) wei-terentwickelt, das die in der Soll-Entwicklung (siehe Abschnitt 5.1.2 „Daten“ aufSeite 52) skizzierten Änderungen beinhaltet.

Das Diagramm enthält die folgenden Akteure: „Bearbeiter“, „Poststelle“, „E-Mail-Sys-tem“, „Vorgangsbearbeitungssystem“ und „Kunde“.

Abbildung 14: UML-Anwendungsfalldiagramm der Antragsverwaltung (Soll-Zustand)

Es lassen sich im Wesentlichen zwei Varianten für den zukünftigen Ablauf der„Antragsverwaltung“ darlegen: „Antrag über Web-Formular“ und „Antrag überPapierformular“, deren Anwendungsfälle in Tabelle 12 dargestellt sind.

Anwendungsfall Variante „Web“

Variante „Papier“

Antrag stellen über Web-Formular (Spezialisierung von „Antrag stellen“)

x

Antrag stellen über Papierformular (Spezialisierung von „Antrag stellen“)

x

Antrag annehmen aus Web (Spezialisierung von „Antrag annehmen“)

x

Tabelle 12: Anwendungsfälle der Varianten für „Antragsverwaltung“

Seite 55

Dem Diagramm lassen sich die folgenden Sachverhalte entnehmen:

1. Kunde stellt einen Antrag über Web- oder Papierformular

2. Poststelle nimmt Antrag auf Papier entgegen bzw. E-Mail-System nimmt Antragaus Web entgegen

3. Poststelle erfasst Papierantrag im Vorgangsbearbeitungssystem

4. Vorgangsbearbeitungssystem leitet Antrag an Bearbeiter weiter

5. Bearbeiter bearbeitet Antrag

6. Bearbeiter leitet Maßnahmen ein

7. Bearbeiter erteilt Bescheid

8. Poststelle versendet Bescheid

Auf der Grundlage des UML-Anwendungsfalldiagramms können für die darin befind-lichen Anwendungsfälle UML-Aktivitätsdiagramme erstellt werden.


Aktivitätsdiagramme dienen der Modellierung der eigentlichen Abläufe innerhalbeines Anwendungsfalls sowie auch teilweise der Modellierung der involviertenDatenobjekte. Bei der Modellierung werden unter anderem parallele Abläufe, Ver-zweigungen, Zusammenführungen und Ähnliches dargestellt.

Bei der Erstellung weiterer Aktivitätsdiagramme sollte darauf geachtet werden, dasseingebundene Datenobjekte, die auch in anderen Aktivitätsdiagrammen existieren,nach Möglichkeit in gleicher Art und Weise wiederverwendet werden.

Das Aktivitätsdiagramm „Antrag annehmen aus Web“ (siehe Abbildung 15 aufSeite 57) beinhaltet die Aktivitäten, die der Akteur „E-Mail-System“ durchführt, umeinen Antrag für eine öffentliche Verwaltung anzunehmen sowie die Objekte (auch:Gegenstände), die durch die Aktivitäten ihren Zustand ändern:

1. Antrag wurde gesendet

2. E-Mail-System nimmt Antrag entgegen

Antrag annehmen aus Post (Spezialisierung von „Antrag annehmen“)

x

Antrag erfassen x

Antrag zuweisen x x

Antrag bearbeiten x x

Maßnahmen einleiten x x

Bescheid erteilen x x

Anwendungsfall Variante „Web“

Variante „Papier“

Tabelle 12: Anwendungsfälle der Varianten für „Antragsverwaltung“

Seite 56

3. Antrag wurde empfangen

4. Paralleler Ablauf

i. Eingangsbestätigung

• E-Mail-System erstellt automatisch Eingangsbestätigung

• Eingangsbestätigung ist erstellt

• E-Mail-System versendet automatisch Eingangsbestätigung

• Eingangsbestätigung wurde gesendet

ii. Entschlüsselung, Signaturprüfung, Zeitstempelvergabe

• Falls Antrag verschlüsselt, entschlüsselt System den Antrag

Abbildung 15: UML-Aktivitätsdiagramm „Antrag annehmen aus Web“

Seite 57

• Antrag ist entschlüsselt

• Falls Antrag signiert, überprüft System elektronische Signatur

• Signatur ist geprüft

• E-Mail-System vergibt Zeitstempel automatisch

• Antrag ist gestempelt

5. Eingangsbestätigung wurde gesendet und Antrag ist gestempelt

6. E-Mail-System leitet Antrag an Vorgangsbearbeitungssystem weiter

7. Antrag wurde im Vorgangsbearbeitungssystem erfasst

5.2.2 Daten

Daten sind der In- und Output für Prozesse, deren Soll-Zustand auch modelliert wer-den muss. Die Soll-Datenstrukturen werden auf der Basis der vorliegenden Ist-Modelle und auf Grundlage der Datenblätter für den Soll-Zustand modelliert.

Die Datenobjekte in den zu entwickelnden Modellen müssen verständlich sein undeine möglichst geringe Komplexität aufweisen. Eine zu große Anzahl von Datenob-jekten birgt jedoch die Gefahr, dass unter Umständen sehr viele Nachrichtenkanälezwischen den Objekten nötig werden, während eine zu geringe Anzahl von Datenob-jekten die Tendenz hat, einzelne Objekte zu überlasten. Es muss somit ein ausgewo-genes Verhältnis zwischen diesen beiden Aspekten bestehen.

Die Wiederverwendbarkeit von Datenobjekten steht im Vordergrund, um den Pfle-geaufwand für die Daten so gering wie möglich zu halten sowie Mehrfacharbeiten beider Durchführung von Verwaltungsvorgängen zu vermeiden.

Die Soll-Modellierung mit dem Ziel der groben Richtungsweisung für die umzuset-zenden Datenstrukturen kann mit der Hilfe von Entity-Relationship-Diagrammen dar-gestellt werden (siehe Abschnitt D.4 auf Seite 78).

Zur Darstellung von detaillierten fachlichen Datenmodellen, die zur technischenUmsetzung in objektorientierte Programmiersprachen und/oder XSD transformierbarsein sollen, sind UML-Klassendiagramme geeignet (siehe auch nachfolgendes Bei-spiel, weitere Informationen zu UML siehe Abschnitt D.1 auf Seite 74).

Einige der Modellierungswerkzeuge ermöglichen es, die SQL-Strukturen von passen-den Datenbanken zu generieren – sowohl aus Entity-Relationship-Diagrammen alsauch aus UML-Klassendiagrammen.

Empfehlung 47:

Für eine grobe Datenmodellierung werden Entity Relationship Diagramme (ERD)eingesetzt.

Für eine detaillierte Datenmodellierung werden UML-Klassendiagramme einge-setzt.

Seite 58

UML-Klassendiagramm

Auf Grundlage der in den Aktivitätsdiagrammen modellierten Aktivitäten, Objekteund deren Zustände ist der Modellierer in der Lage, ein Modell zur Verwaltung dieserObjekte abzubilden – das Klassendiagramm.

Abbildung 16: UML-Klassendiagramm der Antragsverwaltung (Soll-Zustand)

Seite 59

Seite 60

6 Bekanntmachung und Umsetzung der Modelle

In dem folgenden Abschnitt wird beschrieben, welche Maßnahmen zur Einführungund Umsetzung der modellierten Prozesse und Daten in einer öffentlichen Verwal-tung beachtet werden müssen, um die festgelegten Projekt- und somit auch Verwal-tungsziele erreichen zu können, wobei eine positive Entscheidung zur Projektumset-zung bereits gefallen ist. Dieses Kapitel soll aufzeigen, welche Schritte zurerfolgreichen Umsetzung erforderlich sind.

Auf der einen Seite werden Beispiele für die Einführung und Verbreitung der Model-lierungsergebnisse in der öffentlichen Verwaltung gegeben. Auf der anderen Seitewird eine Entscheidungshilfe zur Auswahl einer Umsetzungsstrategie gegeben sowieEmpfehlungen zur technischen Implementierung dargelegt. Weiterhin wird dieBedeutung von Schulungen nach der Umsetzung der Modelle in IT-Anwendungenhervorgehoben.

Abbildung 17: Ablauf der Bekanntmachung und Umsetzung der Modelle

6.1 Entscheidung zur Umsetzungsstrategie

Eine öffentliche Verwaltung sollte für ihren Bereich in Abhängigkeit von Führungssti-len, von der Anzahl betroffener Mitarbeiter und Prozesse sowie von der Reichweiteder Veränderung entscheiden, in welcher Reihenfolge sie die modellierten Strukturenumsetzen möchte beziehungsweise umsetzen kann.

Es lassen sich zwei Strategien der Umsetzung unterscheiden: die stufenweise und diegleichzeitige Umsetzung.

Stufenweise Umsetzung

Bei dieser Strategie der Umsetzung werden die neuen Prozess- und Datenstrukturenfür einzelne Teilbereiche der öffentlichen Verwaltung schrittweise umgesetzt.

Abschnitt 6.1Entscheidung zur

Umsetzungsstrategie

Abschnitt 6.2Einführung der

Modellierungsergebnisse

Abschnitt 6.3Technische Implementie-

rung der Modelle

Abschnitt 6.4Durchführung von

Schulungen

Seite 61

Ein Vorteil dieser Strategie liegt in den gewonnenen Erfahrungswerten bei der Umset-zung in einzelnen Teilbereichen. Fehler in frühzeitig erfolgten Teilumsetzungen kön-nen in späteren Umsetzungen vermieden werden. Des Weiteren ergibt sich für dieeinzelnen Teilbereiche der öffentlichen Verwaltung eine geringere Projektkomplexi-tät sowie ein geringerer und gleichmäßig verlaufender Ressourcenbedarf.

Die stufenweise Umsetzung kann zu Nachteilen führen, wenn eine Organisationsein-heit die neuen Strukturen und Abläufe in ihre Systeme integriert hat und es Schnitt-stellen zu anderen Organisationseinheiten gibt, die noch mit den alten Strukturenund Abläufen arbeiten. Ebenso findet durch eine aufeinander folgende Umsetzung inden einzelnen Teilbereichen die Umsetzungsphase über einen relativ langen Zeit-raum statt, in deren Verlauf die Motivation der Mitarbeiter für das Projekt sinken kann.

Gleichzeitige Umsetzung

Im Rahmen dieser Strategie werden sämtliche neue Prozess- und Datenstrukturenzum gleichen Zeitpunkt in der öffentlichen Verwaltung umgesetzt.

Vorteile dieser Strategie sind die kurze Umsetzungsphase sowie die frühzeitige, ver-waltungsweit produktive Arbeit mit den neuen Prozessen und Strukturen.

Nachteilig könnte sich auswirken, dass Fehler bei der gleichzeitigen Umsetzung inmehreren Teilbereichen der öffentlichen Verwaltung wiederholt werden, da keineErfahrungswerte gesammelt werden konnten. Ebenso erhöht sich durch die gleich-zeitige Umsetzung die Komplexität des Umsetzungsprozesses und des dazugehöri-gen Projektmanagements.

6.2 Einführung der Modellierungsergebnisse

Es muss festgelegt werden, wie nach Beendigung der Prozess- und Datenmodellie-rung die neuen Soll-Modelle veröffentlicht und in der öffentlichen Verwaltung ver-breitet werden. Als Beispiele bieten sich hier die Durchführung von Informationsver-anstaltungen, die Veröffentlichung von verwaltungsinternen Publikationen sowie diePräsentation im Internet an.

Informationsveranstaltungen

Im Rahmen von Informationsveranstaltungen sollten die Ergebnisse den Mitarbeiternvorgestellt werden. Insbesondere sollten hierbei die nachfolgenden Konsequenzenaus den neuen Strukturen mit den Mitarbeitern besprochen und diskutiert werden.Vor der Präsentation der Modellierungsergebnisse in der öffentlichen Verwaltungsollte erfasst werden, wann welche Informationsveranstaltung für welche Mitarbeiterstattfinden soll.

Empfehlung 48:

Vor Beginn der Umsetzung sollte sich die öffentliche Verwaltung entweder für einestufenweise oder für eine gleichzeitige Umsetzung der modellierten Prozesse undDaten entscheiden.

Seite 62

Publikationen

Eine weitere Maßnahme zur Kommunikation der Modellierungsergebnisse stellenPublikationen dar (Beispiel: Rundschreiben, Prozess- und Benutzerhandbücher). Essollte eine Klärung dahingehend stattfinden, in welcher Form was wann veröffent-licht wird.

Intranet

Zur Verbreitung der Modellierungsergebnisse in der öffentlichen Verwaltung bietetsich ebenso das Intranet an. Es muss geklärt werden, wie, wann und wem die Ergeb-nisse im Intranet zur Verfügung gestellt werden. Weiterhin sollte die Möglichkeitgenutzt werden, im Intranet ein Forum einzurichten, das den Mitarbeitern als Kom-munikationsplattform für Fragestellungen zu Modellen dient und in dem durch dieMitarbeiter Vorschläge für Verbesserungen unterbreitet werden können. Zumindestsollte den Mitarbeitern über ein Kontaktformular die Möglichkeit zur Kommunikationgeboten werden. Für häufiger auftretende Fragestellungen sollte eine Auflistung imSinne einer FAQ (Frequently Asked Questions) erstellt werden.

6.3 Technische Implementierung der Modelle

Im Rahmen der Umsetzung findet die technische Implementierung der neuen Pro-zess- und Datenstrukturen in Form von IT-Anwendungen statt. Ziel dieser Projekt-phase ist es, dass die IT-Entwickler auf der Basis der erstellten Prozess- und Datenmo-delle funktionstüchtige und benutzerfreundliche Anwendungen erstellen.

Zur Erleichterung der technischen Implementierung bieten einige Modellierungs-werkzeuge mittlerweile die Möglichkeit, Modelle in eine IT-gerecht weiterverar-beitbare Form zu bringen. So können viele Werkzeuge für die besonders geeigneteUnified Modeling Language (UML) Programm-Code beispielsweise in Form von Java-Klassen generieren und Datenmodelle nach XML Schema Definition (XSD) überführen(siehe Abschnitt D.1 „Unified Modeling Language (UML)“ auf Seite 74). Der Pro-gramm-Code und die XML-Schemata können direkt in die Entwicklung der Anwen-dungssysteme einfließen.

Empfehlung 49:

Die Einführung der Modellierungsergebnisse sollte mittels Publikationen erfolgen,die über das Intranet verbreitet werden können.

Empfehlung 50:

Die technische Implementierung erfolgt auf der Grundlage der erstellten Modelle.Nach Möglichkeit werden aus den Modellen Programm-Code oder Datenstruktu-ren generiert.

Seite 63

6.4 Durchführung von Schulungen

Die Umsetzung der Modelle in der öffentlichen Verwaltung muss, unabhängig vonder gewählten Einführungsstrategie, immer Maßnahmen zur Schulung der neu einzu-führenden Prozesse nach sich ziehen. Ziel von Schulungen ist es, die Mitarbeiter in dieLage zu versetzen, ihre eventuell neu festgelegten Aufgaben im Sinne der neuenStrukturen optimal zu erledigen. Um dies gewährleisten zu können, wird es empfoh-len, schon während der Soll-Modellierung der Prozesse und Daten – spätestensjedoch während der Umsetzung – mit der Erstellung eines Konzepts über die benötig-ten Schulungen für die Mitarbeiter zu beginnen.

Empfehlung 51:

Für den reibungslosen Umgang mit neuen IT-Anwendungen müssen die betrof-fenen Mitarbeiter geschult werden.

Seite 64

Anhang A Checklisten zur Modellierungsvorbereitung

A.1 Checkliste Rahmenbedingungen

CHECKLISTE Rahmenbedingungen ja nein

Verantwortlichkeiten für Prozesse und Daten

Einbindung der Aufbauorganisation

Strategie zur Umsetzung der Prozesse und Daten

Kommunikations- und Schulungskonzept

Tabelle 13: Checkliste Rahmenbedingungen

Seite 65

A.2 Checkliste Standards und Technologien

CHECKLISTE Standards und Technologien ja nein

Prozessmodellierung

Grobe Modellierung

Ereignisgesteuerte Prozesskette (EPK)

Flussdiagramme

UML-Anwendungsfalldiagramme

UML-Aktivitätsdiagramme

UML-Paketdiagramme

Detaillierte Modellierung

UML-Anwendungsfalldiagramme

UML-Aktivitätsdiagramme

UML-Paketdiagramme

weitere UML-Diagramme

Datenaustausch

XML Metadata Interchange (XMI)

Datenmodellierung

Grobe Modellierung

Entity Relationship Diagramm (ERD)

UML-Klassendiagramm


UML-Klassendiagramm

Datenaustausch

XML Metadata Interchange (XMI)

Technische Implementierung

Objektorientierte Programmiersprache

XML Schema Definition (XSD)

Tabelle 14: Checkliste Standards und Technologien

Seite 66

A.3 Checkliste Werkzeug

A.4 Checkliste Modellierungskonventionen

CHECKLISTE Werkzeug ja nein

Versionierung

Import / Export von XML Metadata Interchange (XMI)

Import / Export von eXtensible Markup Language (XML)

Import / Export von XML Schema Definition (XSD)

Tabelle 15: Checkliste Werkzeug

CHECKLISTE Modellierungskonventionen ja nein

Sprache

Deutsch

Englisch

Zeichensatz

UTF-8

Layout von Modellen und Diagrammen

Detaillierungsgrad von Modellen und Diagrammen

Grobe Modellierung


Namen und Begriffe

Fachbegriffkatalog

Domänenspezifische Sprache

Varianten in Prozessen

Variantenbildung in Ist-Modellierung

Variantenbildung in Soll-Modellierung

Tabelle 16: Checkliste Modellierungskonventionen

Seite 67

A.5 Checkliste Dokumentation

CHECKLISTE Dokumentation ja nein

Versionierung

Status

Metadaten

Titel von Modell und Diagrammen

Beschreibung

Deutsch

Englisch

Autor

Version

Themenbereich

Stichwörter

Status

Erstellungsdatum

Änderungsdatum

Ist-Erfassung

Datenblatt für Prozesse

Datenblatt für Daten

Ist-Modellierung

Modelle und Diagramme für Prozesse

Modelle und Diagramme für Daten

Metadaten zu Modellen und Diagrammen

Schwachstellenanalyse

Datenblatt für Schwachstellen

Soll-Entwicklung

Datenblatt für Prozesse zur Gegenüberstellung

Datenblatt für Daten zur Gegenüberstellung

Soll-Modellierung

Tabelle 17: Checkliste Dokumentation

Seite 68

Modelle und Diagramme für Prozesse

Modelle und Diagramme für Daten

Metadaten zur Modellen und Diagrammen

CHECKLISTE Dokumentation ja nein

Tabelle 17: Checkliste Dokumentation

Seite 69

Anhang B Datenblätter zur Modellierung

B.1 Datenblatt Prozesse

B.2 Datenblatt Daten


Prozessname

Kurze Ablaufbeschreibung

Auslöser

Ergebnis

Verantwortlicher

Bearbeiter

Ergebnisempfänger

Beteiligte Organisationseinhei-ten mit dazugehöriger Mitarbei-terzahl

Eingebundene Anwendungssy-steme


Durchlaufzeit pro Vorgang

Kosten pro Vorgang

Fehlerhäufigkeiten

Medienbrüche

Zustand über Funktion als Kern-prozess

Zustand der Dokumentation

Tabelle 18: Datenblatt Prozessea

a. ausgefülltes Beispiel siehe Tabelle 6 auf Seite 34


Art der Daten

Tabelle 19: Datenblatt Datena

Seite 70

B.3 Datenblatt Schwachstelle

Quelle

Datenvolumen

Bestandteile und ihre Wertebe-reiche

Relevanz


Häufigkeit von Änderungen

Art und Anspruch der Datensi-cherung

Einsatzgebiete

Fehlerquellen

Zustand der Dokumentation


Eigenschaft Wert

Kurzbezeichnung

Beschreibung

Ursachen

Verbesserungspotentiale

Betroffene Organisationseinheiten

Typ

Ausmaß

Priorität der Bearbeitung

Lösungsalternativen und Sofortmaß-nahmen

Tabelle 20: Datenblatt Schwachstellea



Tabelle 19: Datenblatt Datena

Seite 71

Anhang C Vorlage zur Dokumentation

1 Einleitung1.1 Zielsetzung der Modellierung1.2 Rahmenbedingungen1.3 Standards und Technologien1.4 Werkzeug

2 Modellierungskonventionen2.1 Sprache2.2 Zeichensatz2.3 Eingesetzte Modell- und Diagrammtypen2.4 Layoutregeln für Modelle und Diagramme2.5 Fachbegriffkatalog

3 Ist-Zustand3.1 Überblick über Teilbereiche (UML-Paketdiagramm + Beschreibung)3.2 Prozesse der Teilbereiche

3.2.1 Teilbereich 13.2.1.1 Überblick über Prozesse des Teilbereichs (UML-Anwendungsfalldi-

agramm + Beschreibung)3.2.1.2 Prozess 1 (Datenblätter + UML-Aktivitätsdiagramm + Verweis auf

die dazugehörigen Datenobjekte)3.2.1.3 Prozess 2 (Datenblätter + UML-Aktivitätsdiagramm + Verweis auf

die dazugehörigen Datenobjekte)…

3.2.2 Teilbereich 2…

3.3 Datenobjekte3.3.1 Überblick der Datenobjekte (UML-Klassendiagramm)3.3.2 Datenobjekt 1 (Datenblätter)3.3.3 Datenobjekt 2 (Datenblätter)…

4 Schwachstellen4.1 Beschreibung der Schwachstellen

4.1.1 Schwachstelle 1 (Datenblatt + Verweis auf die dazugehörige Verbesse-rungsmöglichkeit)

4.1.2 Schwachstelle 2 (Datenblatt + Verweis auf die dazugehörige Verbesse-rungsmöglichkeit)

…4.2 Beschreibung der Verbesserungsmöglichkeiten

4.2.1 Verbesserungsmöglichkeit 1 (Beschreibung)4.2.2 Verbesserungsmöglichkeit 2 (Beschreibung)…

4.3 Priorisierung der Verbesserungsmöglichkeiten

Seite 72

4.3.1 Kriterium 1 (Portfolio mit Verbesserungsmöglichkeiten + Beschreibung)4.3.2 Kriterium 2 (Portfolio mit Verbesserungsmöglichkeiten + Beschreibung)…

5 Soll-Zustand5.1 Überblick über Teilbereiche (UML-Paketdiagramm + Beschreibung)5.2 Prozesse der Teilbereiche

5.2.1 Teilbereich 15.2.1.1 Überblick über Prozesse des Teilbereichs (UML-Anwendungsfalldi-

agramm + Beschreibung)5.2.1.2 Prozess 1 (Datenblätter + UML-Aktivitätsdiagramm + Verweis auf

die dazugehörigen Datenobjekte)5.2.1.3 Prozess 2 (Datenblätter + UML-Aktivitätsdiagramm + Verweis auf

die dazugehörigen Datenobjekte)…

5.2.2 Teilbereich 2…

5.3 Datenobjekte5.3.1 Überblick der Datenobjekte (UML-Klassendiagramm)5.3.2 Datenobjekt 1 (Datenblätter)5.3.3 Datenobjekt 2 (Datenblätter)…

Seite 73

Anhang D Geeignete Standards und Technologien zur Modellierung

D.1 Unified Modeling Language (UML)

Der momentan wichtigste und am weitesten verbreitete Standard zur objektorien-tierten Prozess- und Datenmodellierung ist die von der Object Management Group(OMG)20 entwickelte, offene Unified Modeling Language (UML)21. Die Version UML2.0 wird in SAGA 3.022 für die Prozess- und Datenmodellierung als „Obligatorisch“referenziert. Der Standard eignet sich insbesondere für große Projekte, wie sie auchbei der Modernisierung von Verwaltungsabläufen anzutreffen sind.

UML unterscheidet verschiedene Arten von Diagrammen, die jeweils verschiedeneBlickpunkte auf eine zu entwickelnde Anwendung abbilden (siehe Tabelle 21).

20. siehe http://www.omg.org/ 21. siehe http://www.uml.org/ 22. siehe http://kbst.bund.de/saga, SAGA 3.0, S. 75

Art des Diagramms Name des Diagramms

Strukturdiagramme Klassendiagramma

a. Beispiel siehe Abbildung 9 auf Seite 41 und Abbildung 16 auf Seite 59

Objektdiagramm

Anwendungsfalldiagrammb

b. Beispiel siehe Abbildung 7 auf Seite 38 und Abbildung 14 auf Seite 55

Kompositionsstrukturdiagramm

Komponentendiagramm

Verteilungsdiagramm

Paketdiagrammc

c. Beispiel siehe Abbildung 6 auf Seite 32

Verhaltensdiagramme Aktivitätsdiagrammd

d. Beispiel siehe Abbildung 8 auf Seite 39 und Abbildung 15 auf Seite 57

Zustandsdiagramm

Interaktionsdiagramme Sequenzdiagramm

Kommunikationsdiagramm

Timing-Diagramm

Interaktionsübersichtsdiagramm

Tabelle 21: Auswahl von Diagrammen in UML

Seite 74

http://www.omg.org/

http://www.uml.org/

http://kbst.bund.de/saga

Code-Generierung

Eine große Anzahl an UML-Werkzeugen bietet Export-Möglichkeiten in Java, C und C#an. Der Quellcode kann direkt in die technische Implementierung der IT-Anwendungeinfließen.

XML Metadata Interchange

Mit der Hilfe von Werkzeugen können UML-Diagramme im XMI (XML Metatdata Inter-change)-Format gespeichert werden, die wiederum in XML-Schemata umgewandeltwerden können. Durch die Verwendung von XMI können UML-Diagramme, die miteinem bestimmten Werkzeug bearbeitet wurden, auch in andere Werkzeuge impor-tiert und weiterbearbeitet werden, sofern die gleiche XMI-Version verwendet wird.

Folgende Vorteile bietet XMI:

• XML-basiertes Format zur Darstellung von UML- und MOF-Modellen23

• Prozess zur Erzeugung neuer XMI-Vokabulare aus MOF-basierten Metamodellen

• Standard der Object Management Group (OMG)

• Bestandteil der Model Driven Architecture24

• Modellaustausch zwischen CASE25-Werkzeugen

• Möglichkeit zur Online-Kopplung heterogener Werkzeuge

• Langzeitspeicherung von Modellen

• Weiterverarbeitung der XML-basierten Darstellungen

• inzwischen durch fast jedes UML-Werkzeug angeboten

Aufgrund des XML-Formats einer XMI-Datei können entsprechende Dateien leichterzeugt, durchsucht, weiterverarbeitet, gespeichert und über das Internet übertragenwerden.

Werkzeuge

Für die UML-Modellierung und Code-Generierung einschließlich der Erzeugung vonXMI und XML-Schemata steht eine Vielzahl von Werkzeugen bereit. Im Internet sindumfangreiche Werkzeuglisten26 zu finden.

Wichtig bei der Auswahl eines UML-Werkzeuges sind unter anderem die folgendenKriterien:

• Einhaltung der UML-Spezifikation 1.5 oder 2.0

• XMI-Import und -Export

• Unterstützung von UML-Profilen

23. MOF = Meta-Object Facility, eine spezielle Metadaten-Architektur der OMG24. Model Driven Architecture (MDA) = Standardisierungskonzept der OMG, wobei im Rahmen der Soft-

ware-Entwicklung mit MDA Modelle die zentralen Elemente des Entwicklungsprozesses darstellen. Das Wesen der MDA besteht in der Trennung von plattformunabhängigen und plattformspezifischen Modellen.

25. CASE = Computer-Aided Software Engineering (Deutsch: Rechnergestützte Software-Entwicklung)26. Beispiele: http://www.oose.de/umltools.htm, http://www.uml-forum.com/tools.htm

Seite 75

http://www.uml-forum.com/tools.htm

http://www.oose.de/umltools.htm

• Multi-User-Funktionalität

• Versionsverwaltung

• Modell-Simulation

• Generierung von Programm-Code und XMI aus UML-Diagrammen zur Weiterver-arbeitung für andere Werkzeuge

• Customizing-Optionen

Der Umfang der Anforderungen an die Werkzeuge, die erfüllt werden müssen, istabhängig von den Zielen, welche die öffentliche Verwaltung mit der Prozess- undDatenmodellierung erreichen möchte.

Da sich UML nicht für die maschinelle Verarbeitung zum Austausch von Daten eignet,sondern vielmehr XML, dessen Struktur durch ein XML-Schema beschrieben wird, istes notwendig, die UML-Modelle in XML-Schemata zu transformieren. Für diese Auf-gabe stellt die KBSt27 noch im Jahr 2007 mit dem XGenerator 2.0 ein Werkzeug zurVerfügung. Voraussetzung für die Anwendung ist, dass die UML-Modelle im FormatEMF XMI 2.0 vorliegen und dass bestimmte UML-Profile für die Modellierung verwen-det werden28. Der XGenerator 2.0 validiert die korrekte Anwendung der UML-Profile.Außerdem generiert er eine zum Modell konsistente Dokumentation im DocBook-Format, aus dem wiederum eine PDF-Dokumentation erstellt werden kann.

D.2 Ereignisgesteuerte Prozesskette (EPK)

Die Ereignisgesteuerte Prozesskette (EPK) ist eine im deutschsprachigen Raum nebenUML weit verbreitete grafische Modellierungssprache für Prozesse.

EPKs bestehen aus den drei Grundelementen: Ereignisse, Funktionen und Verknüp-fungsoperationen (Konnektoren). Ereignisse sind Voraussetzungen von Funktionensowie das Resultat von Funktionen. Die Funktionen einer EPK stellen Aktivitäten dar.Die Konnektoren können sein: XOR, OR oder AND. Jede EPK beginnt mit mindestenseinem (Start-)Ereignis) und wird mit wenigstens einem Ereignis (Endereignis) abge-schlossen.

Eine erweiterte Form der Modellierungsmethode EPK stellt die erweiterte Ereignisge-steuerte Prozesskette (eEPK) dar. Die logischen Abläufe eines Geschäftsprozesseswerden mittels der eEPK um die Elemente der Organisations-, Daten und Leistungs-modellierung erweitert. Hier können weitere Informationen über Ausführende, unter-stützende Systeme, verwendete Daten, erzeugte Dateien usw. ergänzt werden.

Es gibt zahlreiche Werkzeuge, welche die Erstellung von Ereignisgesteuerten Prozess-ketten unterstützen29.

27. siehe http://www.kbst.bund.de/28. Ein UML-Profil ist ein Standardmechanismus der Object Management Group (OMG), der eine Menge

von spezifischen Zusatzannotationen (Stereotypen) definiert, die einem UML-Modell hinzugefügt werden können. Informationen zum XÖV-UML-Profil siehe http://www.osci.de/ XÖV-Koordination

UML Profil für XÖV29. siehe http://www.kbst.bund.de/saga-tools

Seite 76

http://www.kbst.bund.de/saga-tools

http://www.kbst.bund.de/

http://www.osci.de/

D.3 Flussdiagramm

Abbildung 19: Beispiel eines Flussdiagramms

Flussdiagramme mit Orientierung an DIN 66001 „Informationsverarbeitung; Sinnbil-der und ihre Anwendung“ sollen zur Modellierung einfacher Prozessmodelle oder zur

Legende

Bescheid ist erteilt

Weitere Maßnahmen sind

eingeleitet

V

Antrag wird bearbeitet

Ereignis

V Und-Verbinder

Bescheid erteilen

Weitere Maßnahmen

einleiten

Funktion

Kundenantrag bearbeiten

Kunde stellt Antrag

Kundenantrag ist angenommen

Kundenantrag annehmen

Abbildung 18: Beispiel einer Ereignisgesteuerten Prozesskette

Legende

Antragstellen

Start

Ende

Maßnahmen einleiten

Bescheiderteilen

Antragbearbeiten

Antragannehmen

Zeigt Start bzw. Ende eines Prozessflusses an

Prozessfunktion

Seite 77

groben Modellierung komplexer Prozesse herangezogen werden. In SAGA 3.030 sinddie Flussdiagramme für die Prozessmodellierung als „Obligatorisch“ referenziert.

Es gibt zahlreiche Werkzeuge, welche die Erstellung von Flussdiagrammen unterstüt-zen31.

D.4 Entity-Relationship-Diagramm (ERD)

Die grafische Form eines Entity-Relationship-Modells ist das Entity-Relationship-Dia-gramm (ERD). Mehrere Darstellungsformen für das ER-Modell sind in Gebrauch, u. a.die Chen-Notation. Für ein Entity wird ein Rechteck verwendet, eine Verbindungsliniemit einer Raute, welche die Entitys verbindet, stellt eine Beziehung dar. An den Ver-bindungslinien werden Kardinalitäten32 angegeben. Die Attribute eines Entitys wer-den als Kreise dargestellt. Entity-Relationship-Diagramme sind oft Grundlage fürDatenbankschemata.

Die Darstellung relationaler Datenmodelle für eine fachliche Grobkonzeption ist mit-tels Entity-Relationship-Diagrammen umzusetzen.

Abbildung 20: Beispiel eines Entity-Relationship-Diagramms

30. siehe http://kbst.bund.de/saga, SAGA 3.0, S. 7531. Beispiel: http://www.bva.bund.de/ Beratung Kompetenzzentrum VBPO Veröffentlichungen

Arbeitshilfen und Marktinformationen des CC VBPO „Softwareprodukte zur Geschäftsprozessa-nalyse und -optimierung“

32. Eine Kardinalität gibt die tatsächliche Anzahl der an einer Beziehung beteiligten Gegenstände an, z. B. kann ein Projektleiter mehrere Projekte leiten, während ein Projekt von genau einem Projektleiter ge-leitet wird.

Legende

Mitarbeiter

bearbeitet stellt

Kunde

enthält

Anlagen

Nach-name

Adresse

Vorname Geburts-datumAnrede

entspricht entspricht

Eingangs-datum

AnliegenStatus

Rolle

Haus-nummerStraße Ort Post-

leitzahl

Antrag

Titel

Eingangs-bestätigung

Ausgangs-datumText

hat

erhält

Entity

Relationship

Attribut

Seite 78

http://www.bva.bund.de/


Abbildung 20 auf Seite 78 zeigt ein vereinfachtes Beispiel. Modelliert ist ein möglicherAusschnitt aus einem Verwaltungsvorgang (Kunde stellt Antrag, der von einem Mitar-beiter bearbeitet wird). Mitarbeiter, Kunde, Rolle, Adresse, Antrag, Anlagen und Ein-gangsbestätigung sind die Entitäten. Kunde und Mitarbeiter erben die AttributeAnrede, Nachname, Vorname und Geburtsdatum von Rolle.

Aus heutiger Sicht stellen ER-Diagramme als Grundlage für relationale Datenmodellenoch immer eine geeignete Modellierung für viele Projekte dar. Grund dafür sind dieeinfache Strukturierung der Daten und damit einhergehend eine hohe Benutzer-freundlichkeit. Weiterhin können mit einigen Werkzeugen z. B. SQL-Fragmente für dieDatenbankgenerierung erzeugt werden. In SAGA 3.033 sind die Entity RelationshipDiagramme für die Datenmodellierung als „Obligatorisch“ referenziert.

Für die ERD-Modellierung bietet das Web zahlreiche Seiten mit Informationen überWerkzeuge34.

D.5 XML Schema Definition (XSD)

Die XML Schema Definition (XSD)35 wurde vom World Wide Web Consortium (W3C)36

entwickelt und dient der Beschreibung von XML-Datenstrukturen. Mit der Hilfe vonXML-Schemata können Klassen von XML-Dokumenten definiert werden.

Die eXtensible Markup Language (XML) ist nach SAGA 3.037 der universelle und pri-märe Standard für den Datenaustausch zwischen verwaltungsinternen und -externenInformationssystemen.

33. siehe http://kbst.bund.de/saga, SAGA 3.0, S. 7634. Beispiel: http://www.databaseanswers.com/modelling_tools.htm35. siehe http://www.edition-w3c.de/TR/2001/REC-xmlschema-0-20010502/36. siehe http://www.w3.org/37. siehe http://kbst.bund.de/saga, SAGA 3.0, S. 77

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"><xsd:annotation>

<xsd:documentation xml:lang="DE">Dies ein Beispiel für die Verwendung eine XML Schema Definition (XSD).</xsd:documentation>

</xsd:annotation><xsd:element name="Kunde" type="KundeTyp"/><xsd:complexType name="KundeTyp">

<xsd:sequence><xsd:element name="Id"/><xsd:element name="Person" type="PersonTyp"/><xsd:element name="Anschrift"></xsd:element><xsd:element name="Antrag" type="AntragTyp" maxOccurs="unbounded"/>

</xsd:sequence></xsd:complexType><xsd:complexType name="AntragTyp">

<xsd:sequence><xsd:element name="Id" type="xsd:integer"/><xsd:element name="Bearbeiter" type="BearbeiterTyp"/>

Tabelle 22: Beispiel einer XSD-Datei

Seite 79



http://www.edition-w3c.de/TR/2001/REC-xmlschema-0-20010502/

http://www.w3.org/


Mit der oben angegebenen XSD-Datei (siehe Tabelle 22) können beliebig viele XML-Elemente nach der immer gleichen Struktur erzeugt werden (siehe Tabelle 23).

<xsd:element name="Titel" type="xsd:string"/><xsd:element name="Text" type="xsd:string"/>

</xsd:sequence></xsd:complexType><xsd:complexType name="BearbeiterTyp">

<xsd:sequence><xsd:element name="Id" type="xsd:integer"/><xsd:element name="Person" type="PersonTyp"/><xsd:element name="Abteilung" type="xsd:string"/>

</xsd:sequence></xsd:complexType><xsd:complexType name="PersonTyp">

<xsd:sequence><xsd:element name="Nachname" type="xsd:string"/><xsd:element name="Vorname" type="xsd:string"/><xsd:element name="Geburtstag" type="xsd:string"/>

</xsd:sequence></xsd:complexType>

</xsd:schema>

<?xml version="1.0" encoding="UTF-8"?> <Kunde xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="xsd-beispiel.xsd">

<Id>1</Id><Person>

<Nachname>Meier</Nachname><Vorname>Erwin</Vorname><Geburtstag>01.01.1960</Geburtstag>

</Person><Anschrift>Frankfurter Allee 5, 12345 Berlin</Anschrift><Antrag>

<Id>1</Id><Bearbeiter>

<Id>1</Id><Person>

<Nachname>Schmidt</Nachname><Vorname>Hannelore</Vorname><Geburtstag>3.5.1945</Geburtstag>

</Person><Abteilung>Kindergeld</Abteilung>

</Bearbeiter><Titel>Antrag auf Kindergeld</Titel><Text>Hiermit beantrage ich ...</Text>

</Antrag> </Kunde>

Tabelle 23: Beispiel einer XML-Datei

Tabelle 22: Beispiel einer XSD-Datei

Seite 80

Nach SAGA 3.038 soll XSD zur strukturierten Beschreibung von Daten in Form vonXML verwendet werden. XML Schema ist weit verbreitet und wird von einer Vielzahlvon Werkzeugen unterstützt.

Werkzeuge

Für XML und XSD gibt es eine breite und etablierte Werkzeugunterstützung39.

Zur automatischen Erzeugung von XML-Schemata aus UML-Modellen wird die KBSteinen entsprechenden Schema-Generator40 zur Verfügung stellen.

D.6 Zusammenfassung Standards und Technologien

Die relationale Datenmodellierung mittels der Entity-Relationship-Diagramme kannsehr gut in kleinen Projekten mit wenig und einfach strukturierten Daten (z. B. vorlie-gend in Tabellen oder ähnlicher Form) eingesetzt werden.

Die objektorientierte Datenmodellierung ist eine wesentlich durchgängigereMethode als die Modellierung auf Basis des Entity-Relationship-Modells. So kann vonder Analyse über Design und Tests bis hin zum laufenden Programm das Konzept derKlasse für die Modellierung der Daten verwendet werden. In der objektorientiertenSoftware-Entwicklung hat sich UML als Modellierungsstandard durchgesetzt.

UML 2.0 ist ein offener und weit verbreiteter Standard für die objektorientierte Model-lierung, nicht nur für die Datenmodellierung, sondern auch für die Prozessmodellie-rung. Insbesondere bei der Durchführung von Großprojekten eignet sich UML für dieobjektorientierte Modellierung aufgrund einer Vielzahl von Diagrammen. Somit kön-nen komplexe Sachverhalte der öffentlichen Verwaltung in IT-Projekten abgebildetwerden. Ein weiterer Vorteil von UML ist, dass aus UML-Diagrammen XML-Daten-strukturen in Form von XML-Schemata generiert werden können. Zur groben Darstel-lung der Prozesse innerhalb einer IT-Anwendung können auch EreignisgesteuerteProzessketten und Flussdiagramme verwendet werden.

XML Schema Definition soll zur strukturierten Beschreibung von Daten genutzt wer-den. Der Standard ist weit verbreitet und wird von einen Vielzahl von Werkzeugenunterstützt.

38. siehe http://www.kbst.bund.de/saga, SAGA 3.0, S. 7639. siehe http://aktuell.de.selfhtml.org/links/xml-software.htm40. siehe Absatz zum XGenerator 2.0 auf Seite 76

Seite 81


http://aktuell.de.selfhtml.org/links/xml-software.htm

Anhang E Glossar

Assoziation

Eine Assoziation ist eine Beziehung zwischen zwei Klassen, siehe Abschnitt 2.5.7.4„Beziehungen von Datenobjekten“ auf Seite 29.

Datenbaustein

Datenbausteine sind fein granulare, fachneutrale Ausschnitte aus komplexenDatenmodellen, die in verschiedenen IT-Anwendungen und Kontexten eingesetztwerden können, wie zum Beispiel das Modell einer Anschrift.

Entity

Ein Entity ist ein eindeutig identifizierbarer und von der Realwelt abstrahierterGegenstand des zu modellierenden Bereiches. Siehe Abschnitt D.4 „Entity-Relati-onship-Diagramm (ERD)“ auf Seite 78.

EPK – Ereignisgesteuerte Prozesskette

Die Ereignisgesteuerte Prozesskette (EPK) wurde 1992 von einer Firma entwickeltund ist eine weit verbreitete grafische Modellierungssprache für Prozesse. EPKsenthalten die drei Grundelemente Ereignisse, Funktionen und Verknüpfungsope-rationen, welche in gerichteten Graphen mit Verknüpfungen verbunden werden.Ereignisse und Funktionen wechseln sich ab, wobei Ereignisse Voraussetzungenund das Resultat von Funktionen sind. Aktivitäten werden als Funktionen darge-stellt, die durch Ereignisse ausgelöst werden und sie resultieren in Ereignisse. DieVerknüpfungen sind XOR, OR oder AND. Jede EPK beginnt mit mindestens einem(Start-)Ereignis und wird mit wenigstens einem Ereignis (Endereignis) abgeschlos-sen. Siehe Abschnitt D.2 „Ereignisgesteuerte Prozesskette (EPK)“ auf Seite 76.

ERD – Entity-Relationship-Diagramm

Ein Entity-Relationship-Diagramm ist die grafische Darstellungsform des Entity-Relationship-Modells (ERM). Objekte und ihre Beziehungen zueinander sindBestandteile eines solchen Entity-Relationship-Diagramms. Des Weiteren werdendie Attribute der Objekte und ihre Kardinalitäten angegeben. ERDs dienen dergrafischen Erfassung wesentlicher betrieblicher Zusammenhänge und werdenhäufig als Grundlage für Datenbankschemata genutzt. Siehe Abschnitt D.4„Entity-Relationship-Diagramm (ERD)“ auf Seite 78.

ERM – Entity-Relationship-Modell

Das Entity-Relationship-Modell ist das am häufigsten zur relationalen Datenmo-dellierung verwendete Modell. Die 1976 von Chen41 veröffentlichte Notation istdas älteste Modell zur strukturierten Modellierung von Daten. Zentraler Begriffdes Modells ist das Entity. Das sind eindeutig identifizierbare Objekte der realenWelt. Die Eigenschaften der Entitys werden als Attribute bezeichnet. Jedes Attri-

41. Peter Pin-Shan Chen ist ein US-amerikanischer Informatiker, der 1976 einen Artikel The Entity Relation-ship Model - Toward A Unified View of Data veröffentlichte und damit die Datenmodellierung revoluti-onierte.

Seite 82

but hat einen Wertebereich, der alle Werte, die das Attribut annehmen kann, ent-hält. Relationships dienen der Modellierung von Beziehungen zwischen Entitys.Auch Relationships können Attribute besitzen. Ferner kennt das ERM auch Rollen,die Entitys annehmen können.

Klasse

Eine Klasse ist in der UML eine Sammlung von Objekten mit gleicher Bedeutung,denselben Attributen, Operationen und Beziehungen. Sie stellt das Grundmustervon gleichartigen Objekten der Realwelt dar. Objekte einer Klasse werden auchInstanzen genannt. Siehe Abschnitt 2.5.7.1 „Klassenbildung“ auf Seite 26.

Metadaten

Unter Metadaten werden allgemein Daten, die Informationen über andere Datenenthalten, verstanden. Metadaten sind also „Daten über Daten“. Ihr Einsatzgebietsind oft große Datensammlungen, wie Datenbanken. In vielen Fällen sind Metada-ten Angaben über den Autor, Titel, Datum der Herstellung, Format, Sprache u. ä.Durch Metadaten werden Ressourcen beschrieben und besser auffindbargemacht. Ein bekannter Metadatenstandard ist der Dublin Core-Ansatz der DublinCore Metadata Initiative (DCMI)42. Siehe Abschnitt „Metadaten“ auf Seite 23.

Modellierungsbereich

Der Modellierungsbereich, der Fokus der Betrachtung, ist ein durch die eindeutigeBenennung von Organisationseinheiten abgegrenzter Bereich im Rahmen derProzess- bzw. Datenmodellierung. Zum Modellierungsfokus gehören alle betrach-teten Organisationseinheiten und deren unmittelbar angrenzenden Bereichebzw. Akteure. Damit ein Modell nicht zu groß und unübersichtlich wird, wird emp-fohlen diesen in kleinere so genannte Modellierungsbereiche aufzuteilen. SieheAbschnitt 3.1 „Identifikation und Priorisierung von Modellierungsbereichen“ aufSeite 31.

MOF – Meta Object Facility

Der Begriff Meta Object Facility (MOF) wurde von der Object Management Group(OMG) eingeführt und beschreibt eine spezielle Metadatenarchitektur. Die MOF-Spezifikation stellt eine abstrakte Sprache zur Verwaltung von plattformunabhän-gigen Metamodellen dar. UML ist ein Beispiel einer solchen Metasprache.

Namespace

Mit einem Namespace – einem Namensraum – wird ein Mechanismus definiert,der es ermöglicht, in Kombination mit einem Uniform Ressource Identifier (URI),Element- und Attributnamen weltweit eindeutig festzulegen.

Prozessbaustein

Prozessbausteine sind fein granulare, fachneutrale Ausschnitte aus komplexenProzessmodellen, die in verschiedenen IT-Anwendungen und Kontexten einge-

42. Siehe http://dublincore.org/

Seite 83

http://dublincore.org/

setzt werden können, wie zum Beispiel das Begleichen einer Gebühr mittels Kre-ditkarte.

Repository

Ein Repository ist eine Ablage- bzw. Speichertechnologie für Datenobjekte. DieStrukturen von Objekten können abgebildet werden und die Beziehungen zwi-schen Objekten. Außerdem werden Metadaten der Objekte erfasst, die durch-sucht werden können. Ein Repository unterstützt die Versionierung seiner Inhalte.Kategoriensysteme können den Inhalten Struktur geben und einen alternativenZugang neben der Suche darstellen. Der schreibende und lesende Zugriff kannüber Web-Oberflächen erfolgen.

SAGA – Standards und Architekturen für E-Government-Anwendungen

Das Dokument SAGA, herausgegeben durch die KBSt im Bundesministerium desInnern in der aktuellen Version 3.043, gibt klare Empfehlungen für den Einsatz vonTechnologien, Verfahren und Methoden im E-Government-Bereich. Ziel ist dieErreichung von Interoperabilität, Wiederverwendbarkeit, Offenheit, Skalierbarkeitund Investitionssicherheit für E-Government-Anwendungen.

UML – Unified Modeling Language

Die Unified Modeling Language (UML) wurde 1997 von der Object ManagementGroup (OMG) als Standard akzeptiert, die seitdem die Standardisierung, Pflegeund Weiterentwicklung der Modellierungssprache übernommen hat. UML ist einegrafische Notation zur Visualisierung, Konstruktion und Dokumentation vonobjektorientierten Modellen. Siehe Abschnitt D.1 „Unified Modeling Language(UML)“ auf Seite 74.


Mit UML-Aktivitätsdiagrammen werden Abläufe von Anwendungsfällen mit Hilfevon Aktionen und Kanten (Aktionsübergänge) grafisch beschrieben. Auch sehrkomplexe Abläufe können mithilfe von Ausnahmen, Varianten und Wiederholun-gen noch übersichtlich und verständlich dargestellt werden. Siehe Abschnitt„UML-Aktivitätsdiagramm“ auf Seite 56.


Ein UML-Anwendungsfalldiagramm zeigt die Beziehungen zwischen Akteurenund Anwendungsfällen. Ein Anwendungsfall wird stets durch einen Akteur bzw.ein Ereignis initiiert. Siehe Abschnitt „UML-Anwendungsfalldiagramm“ aufSeite 55.

UML-Klassendiagramm

Ein Klassendiagramm stellt Objekte in Form von UML-Elementen, wie Klassen undihre Beziehungen zueinander, dar und soll einen Überblick über das Systemgeben. Anders als beim ERM beschreibt eine Klasse nicht nur die Struktur derObjekte mittels Attribute, sondern auch deren Verhalten durch mitgelieferte

43. siehe http://www.kbst.bund.de/saga

Seite 84


Methoden bzw. Operationen. Siehe Abschnitt „UML-Klassendiagramm“ aufSeite 59.

UML-Paketdiagramm

Ein Paketdiagramm beschreibt ein Gesamtmodell als ein Gebilde von Subsyste-men, die so genannten Pakete, welche eine Menge fachlich zusammengehören-der Klassen darstellen. Ein Paket ist eine Ansammlung von Modellelementenbeliebigen Typs. Paketdiagramme eignen sich für die Darstellung sowohl fachli-cher als auch technischer Modelle und Systeme. Siehe Abschnitt „UML-Paketdia-gramm“ auf Seite 32.

XMI – XML Metadata Interchange

Das XML Metadata Interchange-Format ist ein Standard der Object ManagementGroup (OMG) und ist ein XML-basiertes Austauschformat zwischen Software-Ent-wicklungswerkzeugen. Siehe Abschnitt „XML Metadata Interchange“ auf Seite 75.

XML – eXtensible Markup Language

Die Extensible Markup Language (XML) wurde vom World Wide Web Consortium(W3C) entwickelt. XML ist ein einfaches universelles Format für den Austausch vonstrukturierten Informationen. Siehe Tabelle 23 „Beispiel einer XML-Datei“ aufSeite 80.


Mithilfe der vom World Wide Web Consortium (W3C) entwickelten XML SchemaDefinition (XSD) können XML-Datenstrukturen beschrieben werden. XSDs definie-ren das Vokabular (Elemente und Attribute), das Inhaltsmodell sowie die Datenty-pen eines XML-Dokuments. Siehe Abschnitt D.5 „XML Schema Definition (XSD)“auf Seite 79.

Seite 85

Anhang F Abkürzungsverzeichnis

DIN Deutsches Institut für Normung e. V.

DOL Deutschland-Online

eEPK erweiterte Ereignisgesteuerte Prozesskette

EPK Ereignisgesteuerte Prozesskette

ERD Entity Relationship Diagramm

ERM Entity Relationship Modell

HTML Hypertext Markup Language

KBSt Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung

MOF Metadata Object Facility

OMG Object Management Group

PDF Portable Document Format

RTF Rich Text Format

SAGA Standards und Architekturen für E-Government-Anwendungen

SQL Structured Query Language

UTF-8 8-bit Unicode Transformation Format

UML Unified Modeling Language

W3C World Wide Web Consortium

XMI XML Metadata Interchange

XML Extensible Markup Language

XSD XML Schema Definition

Seite 86

Anhang G Abbildungsverzeichnis

Abbildung 1: Vorgehen bei der Modellierung .........................................................................8

Abbildung 2: Ablauf der Vorbereitung zur Modellierung ................................................. 11

Abbildung 3: Qualitätskriterien der Modellierung ............................................................... 20

Abbildung 4: Klasse Adresse ........................................................................................................ 28

Abbildung 5: Ablauf der Ist-Erfassung und -Modellierung ............................................... 31

Abbildung 6: UML-Paketdiagramm „Verwaltung“ ............................................................... 32

Abbildung 7: UML-Anwendungsfalldiagramm der Antragsverwaltung (Ist-Zustand) ...................................................................................................................................... 38

Abbildung 8: UML-Aktivitätsdiagramm „Antrag annehmen“ .......................................... 39

Abbildung 9: UML-Klassendiagramm der Antragsverwaltung (Ist-Zustand) ............. 41

Abbildung 10: Beschreibung der Kardinalität .......................................................................... 42

Abbildung 11: Ablauf der Schwachstellenanalyse ................................................................. 43

Abbildung 12: Beispiel für Portfolio-Technik ............................................................................ 48

Abbildung 13: Ablauf der Soll-Modellierung ........................................................................... 49

Abbildung 14: UML-Anwendungsfalldiagramm der Antragsverwaltung (Soll-Zustand) ................................................................................................................... 55

Abbildung 15: UML-Aktivitätsdiagramm „Antrag annehmen aus Web“ ....................... 57

Abbildung 16: UML-Klassendiagramm der Antragsverwaltung (Soll-Zustand) .......... 59

Abbildung 17: Ablauf der Bekanntmachung und Umsetzung der Modelle ................. 61

Abbildung 18: Beispiel einer Ereignisgesteuerten Prozesskette ....................................... 77

Abbildung 19: Beispiel eines Flussdiagramms ......................................................................... 77

Abbildung 20: Beispiel eines Entity-Relationship-Diagramms .......................................... 78

Seite 87

Seite 88

Anhang H Tabellenverzeichnis

Tabelle 1: Geeignete Standards und Technologien zur Modellierung ........................ 13

Tabelle 2: Geeignete Standards und Technologien für unterschiedliche Zielgrup-pen ................................................................................................................................... 14

Tabelle 3: Kriterien zur Detaillierung von Prozessmodellen (Beispiele) ...................... 19

Tabelle 4: Beispiel für Einträge in einem Fachbegriffkatalog .......................................... 22

Tabelle 5: Bestandteile der Dokumentation ......................................................................... 23

Tabelle 6: Datenblatt Ist-Zustand Prozess (Beispiel) .......................................................... 34

Tabelle 7: Datenblatt Ist-Zustand Daten (Beispiel) ............................................................. 35

Tabelle 8: Auswahl von Kriterien zur Schwachstellenanalyse ........................................ 44

Tabelle 9: Datenblatt Schwachstelle (Beispiel) ..................................................................... 45

Tabelle 10: Datenblatt Soll-Zustand Prozess (Beispiel) ........................................................ 50

Tabelle 11: Datenblatt Soll-Modellierung Daten (Beispiel) ................................................ 52

Tabelle 12: Anwendungsfälle der Varianten für „Antragsverwaltung“ .......................... 55

Tabelle 13: Checkliste Rahmenbedingungen ......................................................................... 65

Tabelle 14: Checkliste Standards und Technologien ........................................................... 66

Tabelle 15: Checkliste Werkzeug ................................................................................................. 67

Tabelle 16: Checkliste Modellierungskonventionen ............................................................ 67

Tabelle 17: Checkliste Dokumentation ...................................................................................... 68

Tabelle 18: Datenblatt Prozesse ................................................................................................... 70

Tabelle 19: Datenblatt Daten ........................................................................................................ 70

Tabelle 20: Datenblatt Schwachstelle ........................................................................................ 71

Tabelle 21: Auswahl von Diagrammen in UML ....................................................................... 74

Tabelle 22: Beispiel einer XSD-Datei ........................................................................................... 79

Tabelle 23: Beispiel einer XML-Datei .......................................................................................... 80

Seite 89

Seite 90

Anhang I Literaturverzeichnis

[Balzert05]Balzert, H.: „UML 2 kompakt mit Checklisten“, München, 2005

[BeKuRo05]Becker, Jörg; Kugeler, Martin; Rosemann, Michael (Herausgeber): „Prozessmanage-ment – Ein Leitfaden zur prozessorientierten Organisationsgestaltung“, 2005, 5.Auflage, Springer-Verlag

[BITKOM04a]BITKOM-Arbeitskreis eGovernment: „Wildwuchs von Datenaustauschformatenvermeiden – internationale offene Standards der UN/CEFACT verwenden“, Berlin2004

[BITKOM04b]BITKOM: „Merkmale der UN/CEFACT Modeling Methodology (UMM) und CoreComponent Technical Specification (CCTS) – XMeld im Kontext der internationa-len Standardisierung“, BITKOM-Arbeitspapier der Expertengruppe „Daten- undKommunikationsglossar“ unter Federführung von Gunther Stuhec (SAP AG) undYorck Rabenstein (PSI AG), Berlin, 2004

[Bodendorf03]Bodendorf, F.: „Daten- und Wissensmanagement“, Berlin, Heidelberg, 2003

[BSI05]Bundesamt für Sicherheit in der Informationstechnik: „E-Government-Handbuch“,„Kapitel III: Phasenplan – Phase 3 – Analyse“, Version vom 7.7.2005, Internet: http://www.bsi.bund.de/fachthem/egov/download/3_Phase3.pdf (12. Juni 2006)

[DIN03]Deutsches Institut für Normung (DIN) e. V.: „PAS 1021 – Verfahrensmodell zurGestaltung von Geschäftsprozessen der öffentlichen Verwaltung“, März 2003

[Dumke]Reiner R. Dumke: „UML Tutorial“, Universität Magdeburg, Internet: http://ivs.cs.uni-magdeburg.de/%7Edumke/UML/ (12. Juni 2006)

[Kemper04]Kemper, A.; Eickler, A.: „Datenbanksysteme – Eine Einführung“, München, 2004

[NBü05]Normenausschuss Bürowesen im DIN: „Normen und Standards für E-Govern-ment“, Version 0.2, Berlin, Oktober 2005

Seite 91



http://ivs.cs.uni-magdeburg.de/%7Edumke/UML/

http://ivs.cs.uni-magdeburg.de/%7Edumke/UML/

[Oestereich04]Oestereich, B.; Weiss, Chr.; Schröder, Cl.; Weilkiens, T.; Lenhard, A.: „Objektorien-tierte Geschäftsprozessmodellierung mit der UML“, Heidelberg, 2004

[OOSE]OOSE Innovative Informatik GmbH: „UML-Tutorial“, Internet: http://www.oose.de/uml.htm (12. Juni 2006)

[Rauh/Stickel97]Rauh, O.; Stickel, E.: „Konzeptuelle Datenmodellierung“, Stuttgart, 1997

[Schäling05]Schäling, Boris: „Der moderne Softwareentwicklungsprozess mit UML“, 2005,Internet: http://highscore.de/uml/ (12. Juni 2006)

[Störrle05]Störrle, H.: „UML 2 für Studenten“, München, 2005

[UML]UML-Website der Object Management Group (OMG), Internet: http://www.uml.org/ (12. Juni 2006)

Seite 92

http://www.oose.de/uml.htm

http://www.oose.de/uml.htm

http://highscore.de/uml/

http://www.uml.org/

http://www.uml.org/

Documents

Leitfaden für Entwickler von Prozess- und Datenmodellen