Praxisleitfaden für den Einsatz standardisierter Soll ... - d-NRW

Kompetenzzentrum Digitale Verwaltung NRW 

Praxisleitfaden 

kdv 

für den Einsatz standardisierter Soll-Prozesse in der 

Kommunalverwaltung 

Ein Projekt des Kompetenzzentrums Digitale Verwaltung NRW

Impressum 

Bochum / Seeheim, im Dezember 2010 

Auftraggeber: Kompetenzzentrum Digitale Verwaltung NRW 

c / o d-NRW Besitz-GmbH & Co. KG 

Lise-Meitner-Allee 4 

44801 Bochum 

Autoren: Harald Schumacher, b.i.t.consult GmbH, Seeheim 

E-Mail: kdv@d-nrw.de 

Praxisleitfaden 

für den Einsatz standardisierter Soll-Prozesse in der 

Kommunalverwaltung 

Ein Projekt des Kompetenzzentrums Digitale Verwaltung NRW 

Gunter Rückziegel, b.i.t.consult GmbH, Seeheim 

harald.schumacher@bitconsult.de 

gunter.rueckziegel@bitconsult.de 

3

4 

Redaktionelle Hinweise 

Redaktionelle Hinweise 

Der vorliegende Praxisleitfaden für den Einsatz standardisierter Soll-Prozesse in der 

Kommunalverwaltung ist der vierte und letzte Teil der KDV / d-NRW-Publikationsreihe 

zum Modellierungsstandard FaMoS. 

Weitere Publikationen zur Modellierungsmethode FaMoS sind: 

Band 1 Standards und Regeln zur Fachmodellierung kommunaler Geschäftsprozes- 

se (Modellierungshandbuch FaMoS 2.0) 

Band 2 Erfahrungsbericht zur Anwendung des Fachmodellierungsstandards 

Band 3 Nutzen, Ziele, Anforderungen und Methoden der Prozessstandardisierung 

(White Paper zum Fachmodellierungsstandard)

Danksagung 

Wir bedanken uns sehr herzlich bei allen Projektbeteiligten, die mit großem persönlichen Enga- 

gement und viel fachlichen Input zur Entwicklung und Durchführung des Projekts beigetragen 

haben: 

Projektleitung / Projektbüro: 

Jürgen Platte d-NRW 

Janine Pleus d-NRW 

Projektmentoren: 

Manfred Bals Stadt Dortmund 

Dirk Blauhut Stadt Köln 

Ralf Grevinga Stadt Dortmund 

Expertengremium: 

Ulrich Cassel Kreis Lippe 

Carol Fuchs Stadt Köln 

Martin Goetzke Stadt Dortmund 

Michael Hokkeler KGSt 

Peter Klinger Sprecher des KDV 

Stefan Schoenfelder Stadt Münster/ Citeq 

Harald Schumacher b.i.t.consult 

Gunter Rückziegel b.i.t.consult 

Projektkommunen: 

Stadt Bochum 

Stadt Dortmund 

Stadt Duisburg 

Stadt Köln 

Stadt Lüdenscheid 

Stadt Münster 

Hochsauerlandkreis 

Märkischer Kreis 

Kreis Soest 

5

6 

Urheber- und Nutzungsrechte 

Urheber- und Nutzungsrechte 

Urheber des Praxisleitfadens für den Einsatz von Soll-Prozessen in der Kommunalver- 

waltung ist die b.i.t.consult GmbH, Seeheim. Der d-NRW Besitz-GmbH & Co. KG, Dort- 

mund, handelnd für das Kompetenzzentrum Digitale Verwaltung (KDV) NRW wurde ein 

unwiderrufliches, ausschließliches, auf Nordrhein-Westfalen begrenztes, übertragbares 

Nutzungs-, Verbreitungs- und Veröffentlichungsrecht eingeräumt. 

Die d-NRW Besitz-GmbH & Co. KG Dortmund, handelnd für das KDV NRW, räumt ihrer- 

seits der Landesverwaltung, den kommunalen Gebietskörperschaften in Nordrhein- 

Westfalen, deren Verbünden und Ausbildungsstätten das nicht ausschließliche, nicht 

übertragbare, zeitlich unbegrenzte Recht ein, den Praxisleitfaden und die darin aufge- 

führten Hilfsmittel im eigenen Geschäftsbereich zu nutzen. Die Nutzung ist kostenlos. 

Eine Weitergabe an und eine Nutzung durch Stellen außerhalb der öffentlichen Verwal- 

tung ist nur mit vorheriger Genehmigung des Urhebers zulässig. Dies gilt auch für die 

Bearbeitung, Verbreitung, Verwertung und Veröffentlichung des Praxisleitfadens und 

seiner Hilfsmittel. 

Eine Vervielfältigung des Leitfadens ist der Landesverwaltung NRW, den kommunalen 

Gebietskörperschaften in Nordrhein-Westfalen sowie deren Verbünden und Ausbil- 

dungsstätten zum Zwecke der Eigennutzung gestattet.

Inhaltsverzeichnis 

Inhaltsverzeichnis 

Danksagung 5 

Urheber- und Nutzungsrechte 6 

Vorbemerkungen 10 

1. Projektreihe „Standardisierung kommunaler Prozesse“ 11 

1.1 Projektkontext............................................................................................................. 11 

1.2 Projektziel.................................................................................................................... 12 

1.3 Projektvorgehen ......................................................................................................... 15 

2. Praxisleitfaden 17 

2.1 Einführung .................................................................................................................. 17 

2.2 Projektinitialisierung und Qualitätssicherung Soll-Modell .................................... 19 

2.3 Soll- / Ist-Vergleich .................................................................................................... 36 

2.4 Stufenkonzept Umsetzung ........................................................................................ 49 

2.5 Fachliche Feinkonzeption ......................................................................................... 52 

2.5.1 Einführung von Fachanwendungen.............................................................................. 53 

2.5.2 Fachkonzept Web-Frontend......................................................................................... 53 

2.5.3 Fachkonzept Eingangsbearbeitung.............................................................................. 65 

2.5.4 Fachkonzept Dokumentenmanagement ...................................................................... 71 

2.5.5 Fachkonzept elektronischer Workflow.......................................................................... 73 

2.5.6 Fachkonzept Schnittstellen .......................................................................................... 82 

2.5.7 Fachkonzept Ausgangsbearbeitung............................................................................. 84 

3. Hinweise zum Veränderungsmanagement 88 

3.1 Rahmenbedingungen und Grundsätze .................................................................... 88 

3.2 Das Phasenmodell der Veränderung........................................................................ 89 

3.3 Prozessorientiertes Veränderungsmanagement .................................................... 91 

7

8 

Abbildungsverzeichnis 


Abbildung 1: Abgrenzung „fachliche“ und „technische“ Modellierung 14 

Abbildung 2: Übersicht über Teilnehmer und Prozesse 15 

Abbildung 3: Einordnung des Projekts in den Projektlebenszyklus 16 

Abbildung 4: Übersicht der Arbeitspakete und Projektrollen 18 

Abbildung 5: Deckblatt Projektergebnisdokumentation 19 

Abbildung 6: Bearbeitungshistorie und Versionskontrolle 19 

Abbildung 7: Checkliste Prozessoptimierung 21 

Abbildung 8: Fragebogen zur "Qualitätssicherung Soll-Modell" 26 

Abbildung 9: Vorgehen und Beteiligte zur Vorbereitung des Soll-Ist-Vergleichs 28 

Abbildung 10: Grafische Darstellung Rollenmodell 29 

Abbildung 11: Tabellarische Darstellung "Rollenmodell" 29 

Abbildung 12: Ableitung funktionaler IT-Anforderungen aus dem Fachmodell 31 

Abbildung 13: Vorlage Prozessfunktionstabelle 34 

Abbildung 14: Skizze des E-Government IT-Frameworks 35 

Abbildung 15: Prinzip des organisatorischen Soll-Ist-Vergleichs 37 

Abbildung 16: Leitfragen zum Soll-Ist-Vergleich Organisation 37 

Abbildung 17: Vorlage "Maßnahmenplan Organisation" 40 

Abbildung 18: Portfoliomethode zur Bewertung von Lösungsalternativen 42 

Abbildung 19: Schnittstellenanalyse mit der Prozesslandkarte 43 

Abbildung 20: Vorlage Soll-Ist-Vergleich Schnittstellen 44 

Abbildung 21: Dienste und Funktionen in der E-Government IT-Architektur 46 

Abbildung 22: Leitfragen zum Soll-Ist-Vergleich IT 47 

Abbildung 23: Vorlage "Maßnahmenplan Technologie" 49 

Abbildung 24: Alternative Stufenkonzeptionen 50 

Abbildung 25: Leitfaden und Entwicklungsstufen zur E-Government-Umsetzung 51 

Abbildung 26: Leitfragen zur Entwicklung des Stufenkonzepts 51 

Abbildung 27: Vorlage zur Darstellung des Stufenkonzepts 52


Abbildung 28: Klassifizierung angebotsorientierter Online Dienste 54 

Abbildung 29: Ablaufmodell zur Fachkonzeption Web-Frontend 54 

Abbildung 30: Checkliste Fachkonzept Web-Frontend 56 

Abbildung 31: Notation zur Erstellung von Anwendungsfalldiagrammen 60 

Abbildung 32: Vorlage Anwendungsfallbeschreibung 62 

Abbildung 33: Muster Fachkonzept Eingangsbearbeitung 70 

Abbildung 34: Checkliste Anforderung und Eignung DM 72 

Abbildung 35: Detaillierung: von der Fachprozess- zur Workflow-Ebene 74 

Abbildung 36: Fachprozessmodell "Bestellung" 75 

Abbildung 37: Rollen- Modell und Beschreibung zum „Bestellprozess“ 77 

Abbildung 38: Referenzierung von Rolle und Organisation 77 

Abbildung 39: Dokumentenmodell „Bestellprozess“ 77 

Abbildung 40: Vorlage „Beschreibung Informationsobjekt“ 78 

Abbildung 41: Prozessfunktionstabelle „Bestellprozess“ 79 

Abbildung 42: Workflowdiagramm „Bestellprozess“ 81 

Abbildung 43: Vorlage Schnittstellenbeschreibung 83 

Abbildung 44: Vorlage Outputanalyse 87 

Abbildung 45: „Drei Phasen Modell“ der Veränderung 90 

Abbildung 46: Inhalte und Aufgaben im "Drei Phasen Modell" 91 

Abbildung 47: Planungsschema Veränderungsmanagement 93 

9

10 

Vorbemerkung 

Vorbemerkung 

Der vorliegende Praxisleitfaden wurde gemeinsam mit den Teilnehmerinnen und Teil- 

nehmern des KDV-Projektes „Praxisleitfaden für den Einsatz standardisierter Soll- 

Prozesse in der Kommunalverwaltung“ unter Moderation und fachlicher Begleitung der 

Berater der b.i.t.consult GmbH erarbeitet. 

Am Projekt waren Mitarbeiterinnen und Mitarbeiter der Städte Bochum, Dortmund, Duis- 

burg, Köln, Lüdenscheid und Münster sowie der Kreisverwaltungen Hochsauerlandkreis, 

Märkischer Kreis und des Kreises Soest beteiligt. Unterstützt wurden die Teilnehmer von 

einem Team von E-Government kundigen Mentoren aus den beteiligten Kommunen und 

einem Expertengremium, dass die Projektergebnisse bewertete und reflektierte. Die Lei- 

tung des Projekts oblag d-NRW. 

Das Projekt „Praxisleitfaden“ bildet den Abschluss der KDV-Projektreihe „Standardisie- 

rung kommunaler Prozesse“, die die Erarbeitung, Anwendung und Evaluation von „kon- 

zeptionellen“ und „handwerklichen“ Grundlagen zur Frage der Gestaltung und Optimie- 

rung kommunaler Prozesse unter größtmöglicher Nutzung von E-Government- 

Technologien beinhaltete. 

Eine Besonderheit, wenn nicht ein Alleinstellungsmerkmal dieses Projektes in der Land- 

schaft kommunaler Modernisierungsprojekte lag darin, dass erstmalig optimierte Soll- 

Prozesse nach dem „Einer für Alle“ Prinzip in einem interkommunalen Verbundprojekt 

entwickelt und praktisch umgesetzt wurden. Dies bedeutet, dass zukünftig nicht jede 

Kommune „das Rad neu erfinden“ muss, sondern auf bereits vorhandene allgemeingülti- 

ge Referenzmodelle zurückgreifen kann, um die eigenen Prozesse und (Infra-) Strukturen 

zu optimieren. 1 

Das KDV NRW verfolgte unter anderem das Ziel, die interkommunale Zusammenarbeit 

in Leistungsnetzwerken zu ermöglichen und zu fördern. Die Standardisierung und ihre 

praktische Umsetzung bilden eine wesentliche Grundlage bei der vernetzten Erstellung 

kommunaler Leistungen bzw. Produkten. 2 

1 Die Projektergebnisse haben hier bereits eine erste „Resonanz“ erzeugt: Die Kommunale Gemeinschaftsstelle 

für Verwaltungsmanagement (KGSt) hat auf der Grundlage einer Kooperationsvereinbarung mit d-NRW/KDV 

und b.i.t.consult beschlossen, den Fachmodellierungsstandard FaMoS als Notations- und Beschreibungsstandard 

in die Prozessbibliothek der KGSt einzuführen. Die im Projekt “Standardisierung kommunaler Prozesse“ 

erarbeiteten Prozessmodelle und Methoden werden Bestandteil dieser Prozessbibliothek. 

2 Vgl. Modellversuch Vernetzte Verwaltung. Informationen und Bericht unter http://www.d-nrw.de/referenzen/ mo- 

dellversuch.


1. Projektreihe „Standardisierung kommunaler Prozesse“ 

1.1 Projektkontext 

Das Projekt „Praxisleitfaden“ bildet den Abschluss von drei Projekten zur Standardisierung 

kommunaler Prozesse. Ausgangspunkt war insbesondere die Überlegung, dass eine Vernet- 

zung kommunaler Produktionsprozesse und die Bildung kommunaler Leistungsnetzwerke nur 

dann erfolgreich durchgeführt werden können, wenn zuvor fachliche und organisatorische 

Standards zur Aufgabenwahrnehmung und Prozessdurchführung entwickelt und interkommunal 

abgestimmt wurden. Dies setzt voraus, dass eine gemeinsame „Sprache“ und „Methodik“ zur 

Beschreibung der Geschäftsprozesse existiert, die einerseits von Fachmitarbeitern und Organi- 

satoren der Kommunen „verstanden“ wird und andererseits „anschlussfähig“ an Methoden zur 

technischen Modellierung und Automation der Geschäftsprozesse ist. 

Im ersten Projekt wurde deshalb zunächst eine Methode zur Beschreibung und Modellierung 

kommunaler Geschäftsprozesse, der Fach-Modellierungs-Standard (FaMoS), entwickelt und 

praktisch erprobt. Anknüpfend an aktuelle Entwicklungen im Bereich der Geschäftsprozessmo- 

dellierung und -optimierung 3 , war es Ziel, den Kommunen eine Methodik bereitzustellen, die 

geeignet ist: 

verwaltungsspezifische Anforderungen und Prozess-Sachverhalte ohne Investition in 

spezielle Modellierungswerkzeuge und geringem Einarbeitungs- und Schulungsaufwand 

adäquat abzubilden, 

im Sinne eines integrierten Modellierungsansatzes sowohl fachliche und technologische 

Sachverhalte als auch die organisationsübergreifende, „strategische“ Sicht mit der „ope- 

rativ- / fachlichen“ Perspektive zu verknüpfen und 

durch eine klar strukturierte Modellarchitektur mit mehreren Darstellungs- und Detaillie- 

rungsebenen der Prozessmodelle die Modellierungsergebnisse interkommunal ver- 

gleichbar zu machen und die fachliche Standardisierung kommunaler Prozesse systema- 

tisch zu unterstützen. 

Im zweiten Projekt wurde die Methodik FaMoS genutzt, um sogenannte E-Government-Soll- 

Modelle für mehrere kommunale Kernprozesse zu entwickeln. Diese E-Government-Soll- 

Modelle bilden jeweils im Hinblick auf die fachlichen Inhalte und Aufgaben einer Kommune 

einen standardisierten und im Hinblick auf die informationstechnologische Unterstützung der 

Prozessdurchführung einen optimierten Soll-Prozess ab. Die E-Government-Soll-Modelle wur- 

den „interkommunal“ und „interdisziplinär“ entwickelt und abgestimmt, es waren also jeweils 

mehrere Kommunen und Vertreter der Fachbereiche, Organisatoren und kommunale IT- 

Experten an der Entwicklung beteiligt. 

Im Ergebnis konnte zu allen im Projekt bearbeiteten Kernprozessen ein interkommunal abge- 

stimmtes E-Government-Soll-Modell definiert werden. Dabei wurde zunächst ein Fachrefe- 

renzmodell unabhängig von der technologischen Unterstützung entwickelt und „technologie- 

3 Zum Beispiel an Konzepte zur Service orientierten Modellierung und Methoden zur Modellierung technischer Workflows 

wie BPMN.

12 1. Projektreihe „Standardisierung kommunaler Prozesse“ 

frei“, aber im Hinblick auf seine fachliche Aufgabenstruktur und im Hinblick auf eine möglichst 

effektive und effiziente organisatorische Strukturierung des Ablaufs im Sinne eines „Fach- 

Standards“ beschrieben und dokumentiert. Dieses standardisierte Fachreferenzmodell ist 

grundsätzlich auf alle nordrhein-westfälischen Kommunen übertragbar. 

Die Fachreferenzmodelle wurden in einem zweiten Schritt aus technologischer Sicht betrach- 

tet und im Hinblick auf ihre „E-Government-Potenziale“ analysiert. Dabei lag der Fokus auf der 

Frage: „Welche informationstechnologischen Dienste und Anwendungen können den Fach- 

prozess unterstützen und einen Beitrag zur Optimierung der Prozessdurchführung aufseiten 

der Verwaltungskunden und/oder der Verwaltung selbst leisten?“ Die Potenzialanalyse orien- 

tierte sich dabei keineswegs an den bei den Teilnehmerkommunen bereits verfügbaren E- 

Government-Diensten und IT-Anwendungen, sondern am technologischen „Stand der Dinge“ 

beim E-Government, also an den zur Zeit am Markt für kommunale IT verfügbaren und prak- 

tisch erprobten Konzepten und Lösungen. Im Ergebnis der Diskussion wurden die für das 

jeweilige Fachreferenzmodell relevanten E-Government-Dienste und Anwendungskomponen- 

ten identifiziert und in einem Strukturdiagramm dokumentiert. Abschließend wurden durch eine 

Projektion der Soll-E-Government-IT auf das Fachreferenzmodell mögliche Auswirkungen und 

Veränderungen im Fachreferenzmodell diskutiert und als E-Government-Soll-Modell doku- 

mentiert. 

Obwohl die E-Government-Soll-Prozesse in interkomunaler Zusammenarbeit gemeinsam und 

einvernehmlich standardisiert wurden, können sie in der Regel nicht direkt eingesetzt werden. 

Sowohl der organisatorische Aufbau als auch die eingesetzten IT-Komponenten weichen in 

den Gebietskörperschaften von einander ab. So werden z. B. verschiedene Fachverfahren mit 

unterschiedlichen Qualitäten eingesetzt oder es stehen (noch) nicht alle im E-Government- 

Soll-Prozess enthaltenen IT-Komponenten zur Verfügung bzw. der in Anspruch genommene 

kommunale IT-Dienstleister bietet diese Dienste (noch) nicht an (Portaltechnik, Signatur, Au- 

thentifizierung, Dokumentenmanagement, eAkte etc.). Jede Kommune muss den Soll-Prozess 

auf ihre spezifischen Bedingungen übertragen. 

1.2 Projektziel 

Das dritte und abschließende Projekt „Praxisleitfaden“ verfolgte deshalb das Ziel, einen „Metho- 

denbaukasten“ zu entwickeln und zu erproben, der die Kommunen dabei unterstützt, E- 

Government-Soll-Modelle auf ihre Organisation zu übertragen und diese organisatorisch und 

technologisch in die kommunale Praxis zu überführen. Auf diesem Wege sollen Veränderungs- 

prozesse in nordrhein-westfalischen Kommunen angestoßen und gefördert werden. 

Die Projekterfahrungen haben gezeigt, dass angestoßene Veränderungsprojekte regelmäßig 

nur initiiert und erfolgreich abgeschlossen werden, wenn es gelingt, eine Verständigung zwi- 

schen Verwaltungsführung, Fachbereichen, Organisatoren und IT-Experten einer Kommune 

über Ziele und Nutzen, aber auch und insbesondere über die konkreten fachlichen, organisa- 

torischen und technologischen Ansatzpunkte und Maßnahmen zur Veränderung herbeizufüh- 

ren. 

Eine besondere Herausforderung liegt dabei in der Überwindung der „Sprachbarriere“ zwi- 

schen allen Beteiligten: „Fachseite“, „Organisation“ und „Technik“. Insbesondere „Organisato- 

ren“ und „IT-Experten“ sprechen nicht nur verschiedene (Fach-)Sprachen, sie verwenden zur


Analyse und Darstellung gleicher Sachverhalte häufig auch gänzlich andere Methoden und 

Detaillierungstiefen 4 . Dies äußert sich in der Praxis z.B. darin, dass die Informationsbedürfnisse 

und Anforderungen der IT-Seite vonseiten der Organisatoren und Prozessexperten entweder 

nicht oder nur unzureichend erfüllt werden. Umgekehrt fällt es der IT-Seite nicht selten schwer, 

Anforderungen und Vorstellungen der Fachseite und / oder Organisatoren zu verstehen und 

den Informationsbedarf in einer der Fachseite verständlichen Sprache zu artikulieren. Im Er- 

gebnis können Verständigungsschwierigkeiten zwischen den Beteiligten dazu führen, dass 

Fachseite und Organisation Prozesse ohne Berücksichtigung der informationstechnologi- 

schen Möglichkeiten optimieren, 

bestehende IT-Optimierungsmöglichkeiten nicht genutzt und Potenziale verschenkt wer- 

den, 

durch Reorganisation des Arbeitsablaufs mehr Aufwand bei der technischen Umsetzung 

entsteht als organisatorisch eingespart werden kann, 

vonseiten der „Organisation“ mit großem Engagement und Aufwand erstellte Soll- 

Prozesse und Anforderungskonzepte von der „IT“ verworfen und im ungünstigsten Fall 

neu erstellt werden und / oder 

die eingeführte IT-Lösung die fachlichen Anforderungen nur unzureichend erfüllt. In der 

Folge ergibt sich ein mehr oder weniger langer Zyklus von Nachbesserungen. 

Die folgende Abbildung stellt den Zusammenhang und den Übergang von der fachlichen zur 

technischen Modellierung von Prozessen und IT-Systemen schematisch dar. 

4 Zur Vertiefung der Darstellung wird auf die Kapitel 2.1.4 bis 6 im „Modellierungshandbuch FaMoS 2.0“ verwiesen; 

verfügbar als Download unter www.d-nrw.de/projekte/kdv/standardisierung-kommunaler-prozesse und 

http://bitconsult.de/publikationen/cat_view/2-publikationen.html.


Fachliche 

Modellierung 

Informationstechnische 

Modellierung 

Abbildung 1: Abgrenzung „fachliche“ und „technische“ Modellierung 5 

In der Praxis besteht eine methodische Lücke bei der Überführung des Fachprozessmodells in 

das IT-Ausführungsmodell. Diese methodische Lücke führt dazu, dass die für die IT- 

Umsetzung fachlicher Anforderungen erforderlichen Informationen bei der „Übergabe“ von 

Projekten von Organisation und Fachseiten an die IT oft nur unvollständig vorliegen und zu 

den oben beschriebenen Auswirkungen führen. 

Der vorliegende Praxisleitfaden möchte dazu beitragen diese Lücke ein Stück weit zu schlie- 

ßen, indem er einfache Vorgehensweisen, Checklisten und Vorlagen zur Dokumentation IT- 

umsetzungsrelevanter Informationen anbietet. Diese können von der „Fachseite“ in ihrer eige- 

nen Sprache und ohne vertiefte Kenntnis der aufseiten der Technik verwendeten Methoden 

gehandhabt und dennoch von der IT verstanden werden. Alle Hilfsmittel wurden von den Pro- 

jektteilnehmern auf ihre Praxistauglichkeit hin überprüft, idem sie angewendet, verbessert und 

qualitätsgesichert wurden. 

In diesem Sinne dient der Praxisleitfaden dazu „Soll-Modelle“ systematisch zu einführungs- 

tauglichen „Realisierungsmodellen“ zu verfeinern. 

Der vorliegende Praxisleitfaden versteht sich als „Handreichung“ für Führungskräfte und Pro- 

zessverantwortliche der Fachbereiche sowie Organisatoren, Projekt- und Veränderungsmana- 

ger in Kommunen, die helfen soll, die Kommunikation und den Informationsaustausch zwi- 

schen den beteiligten Akteuren möglichst ziel- und ergebnisorientiert zu gestalten sowie Rei- 

bungsverluste und Redundanzen in der fachlichen und technischen Analyse und Konzeption 

zu reduzieren. 

Umfang der 

Fachmodellierung 

Fach- 

Fach- 

Prozess- 

Prozess- 

Architektur 

Architektur 

Fachprozessmodell 

Fachprozessmodell 

(„Ablaufmodell“) 

(„Ablaufmodell“) 

Fachliches 

Fachliches 

Service 

Service 

Modell 

Modell 

(Fach-SOA) 

(Fach-SOA) 

Fachliche 

Fachliche 

IT-Anforderungen 

IT-Anforderungen 

Informationstechnisches 

Informationstechnisches 

Service-Modell 

Service-Modell 

(IT-SOA) 

(IT-SOA) 

IT-Prozess-Ausführungsmodell 

IT-Prozess-Ausführungsmodell 

IT-Anwendungsmodell, 

IT-Anwendungsmodell, 

IT-Servicedefinitionen, 

IT-Servicedefinitionen, 

Programmcode 

Programmcode 

Modellumfang und Detaillierung 

Fokus Fachmodellierung: 

• Fachliche Modellierung von Prozessen 

• Anschlussfähigkeit an die technische 

Modellierung und Prozessautomation 

• Definition fachlicher IT-Anforderungen 

• Ableitung der Fach-Service 

Architektur aus den Geschäftsprozessen 

• Berücksichtigung verwaltungsspezifischer 

Anforderungen und Inhalte 

Fokus Praxisleitfaden 

5 Zur Vertiefung der Darstellung wird auf die Kapitel 2.1.4 bis 6 im „Modellierungshandbuch FaMoS 2.0“ verwiesen; 

verfügbar als Download unter www.d-nrw.de/projekte/kdv/standardisierung-kommunaler-prozesse und 

http://bitconsult.de/publikationen/cat_view/2-publikationen.html.


1.3 Projektvorgehen 

Alle Projektkommunen waren bereits Teilnehmer des zweiten Projektes, in dem 19 kommunale 

E-Government-Soll-Modelle erarbeitet wurden. Für 6 dieser 19 Prozesse wurden im Projekt 

„Praxisleitfaden“ entsprechende Umsetzungsstrategien entwickelt (siehe Abbildung 2). 

teilnehmende Kommune bearbeiteter Kernprozess 

Hochsauerlandkreis Apothekenaufsicht 

Stadt Bochum 

Stadt Dortmund 

Stadt Köln 

Kreis Soest 

Elternbeiträge KiTa 

Märkischer Kreis Hilfe zur Pflege 

Stadt Münster Schülerfahrkosten 

Stadt Lüdenscheid Vollstreckung 

Stadt Duisburg Wohngeld 

Abbildung 2: Übersicht über Teilnehmer und Prozesse 

Die besondere Ausgangslage bestand daher darin, dass aus der Sicht der teilnehmenden 

Kommunen zu Projektbeginn für die jeweiligen Fachprozesse bereits ein mehr oder weniger tief 

ausgearbeitetes E-Government-Soll-Modell vorlag, welches nicht innerhalb der eigenen Orga- 

nisation entstanden war und zunächst einmal mit den beteiligten Fachbereichen der Projekt- 

kommunen diskutiert und „geistig“ und „fachlich“ angenommen werden musste. Weiterhin be- 

standen (und bestehen) innerhalb der Projektkommunen jeweils völlig unterschiedliche finan- 

zielle und kulturelle Rahmenbedingungen sowie unterschiedliche personelle, organisatorische, 

technologische und methodische Voraussetzungen für die Durchführung und Umsetzung von 

Veränderungsprojekten im Bereich der „Prozessoptimierung durch E-Government“. Der Praxis- 

leitfaden verzichtet daher vollständig auf den Einsatz spezieller Modellierungswerkzeuge oder 

Methoden. Die vorgestellten „Werkzeuge und Methoden“ können also „mit Bordmitteln“ in jeder 

Kommune angewendet werden. Die bereits angesprochene „besondere Ausgangslage“, ein E- 

Government Soll-Modell, welches nicht unter Beteiligung der eigenen Mitarbeiter und Organisa- 

tion entwickelt wurde, liegt bereits vor, machte eine Modifikation herkömmlicher Vorgehensmo- 

delle in GPO 6 -Projekten notwendig. 

Zudem werden Referenzprozesse wie standardisierte und good- oder best-practice Prozesse in 

zunehmendem Maße über Prozessbibliotheken zur Verfügung gestellt. 

Die modifizierte Projektstruktur und ihre Einordnung in den Lebenszyklus von GPO-Projekten 

werden in der Abbildung 3 dargestellt. 

6 GPO = Geschäftsprozessoptimierung


Abbildung 3: Einordnung des Projekts in den Projektlebenszyklus


2. Praxisleitfaden 

2.1 Einführung 

Die Einführung eines E-Government-Soll-Modells in die tägliche Verwaltungspraxis vollzieht 

sich in den folgenden vier Schritten: 

Projektinitialisierung und Qualitätssicherung Soll-Modell (Kapitel 2.2) 

Um das bereits vorliegende fachliche Soll-Modell in der eigenen Organisation bekannt und 

„hoffähig“ zu machen erfolgt „vor Ort“ eine Qualitätssicherung des Soll-Modells unter Einbezie- 

hung von Fachbereich, Organisation und IT-Experten. Ziel und Ergebnis dieser Projektphase 

ist, dass alle Teilnehmer das Modell und seine Zielrichtung verstanden haben. 

Soll-/Ist-Vergleich (Kapitel 2.3) 

Durch einen Soll-/Ist-Vergleich erfolgt im nächsten Schritt eine Identifizierung der Handlungs- 

bedarfe in den Bereichen Organisation und technologische Infrastruktur der Kommune. Zielset- 

zung dabei ist es, alle Handlungsbedarfe zu identifizieren und zu priorisieren und daraus be- 

reits erste Maßnahmen im Bereich des Veränderungsmanagement abzuleiten (Beteiligungen, 

Information und Kommunikation). 

Stufenkonzept Umsetzung (Kapitel 2.4) 

Sind die Handlungsbedarfe intern kommuniziert und ihre Priorisierung(-en) abgestimmt, werden 

die Handlungsbedarfe in ein Grobkonzept zur Umsetzung des Soll-Modells transformiert. Die- 

ses Grobkonzept zeigt auf, in welchen Umsetzungsstufen und in welchem Zeithorizont der 

Sollzustand erreicht werden soll. Ziel und Ergebnis dabei ist die Ableitung eines Projektumset- 

zungskonzepts (Stufenkonzept), welche die örtlichen Rahmenbedingungen und Umsetzungs- 

voraussetzungen vollständig berücksichtigt und zugleich einen Entwicklungspfad aufzeigt, der 

auf jeder Umsetzungsstufe bereits eine voll praxistaugliche Teillösung bereitstellt und einen 

wahrnehmbaren und messbaren Prozessnutzen erzeugt. 

Fachliche Feinkonzeption (Kapitel 2.5) 

Für die erste Umsetzungsstufe wird nun mit den im Praxisleitfaden bereitgestellten Hilfsmitteln 

ein fachliches Feinkonzept erarbeitet. Das fachliche Feinkonzept spezifiziert die Anforderungen 

an die gewünschte IT-Unterstützung aus fachlicher Sicht und liefert der IT bereits wertvolle 

Detailinformationen, die eine Abschätzung von Machbarkeit, Aufwand und zusätzlichen (IT- 

spezifischen) Spezifikationsbedarfen ermöglicht. 

Der Aufbau des Praxisleitfadens orientiert sich an dem in der folgenden Abbildung dargestellten 

Vorgehensmodell. Das Vorgehensmodell verfeinert die bereits im vorigen Abschnitt dargestell- 

ten Projektphasen nach Arbeitspaketen und zeigt exemplarisch auf, welche Rollen jeweils an

18 2. Praxisleitfaden 

der Bearbeitung der Projektaufgaben und Arbeitspakete beteiligt sind. Die Federführung bzw. 

Projektleitungsfunktion liegt in jeder Phase bei der Rolle „Organisator“. 

Personal- 

Betreuer 

Organisator 

Fach- 

Führungskraft 

IT-System 

-architekt 

Organisator 

Fachexperte 

Fach-Anw.- 

Betreuer 

Fach- 

Führungskraft Fach-Aw.- 

Betreuer 

Fachexperte 

IT-System 

-architekt 

Organisator Fachexperte 

IT-System 

-architekt 

Abbildung 4: Übersicht der Arbeitspakete und Projektrollen 

Die im Folgenden dargestellten Hilfsmittel und Vorlagen sind so angelegt und gestaltet, dass 

sie auch unabhängig von dem in den Abbildungen 3 und 4 dargestellten Vorgehensmodellen 

in GPO-Projekten der Kommune einsetzbar sind. Je nach der konkreten Projektaufgabenstel- 

lung können und sollen die Vorlagen selektiv genutzt werden. Sie erheben andererseits auch 

keinen Anspruch auf Vollständigkeit, sondern repräsentieren die Erfahrungen des oben be- 

schriebenen interkommunalen Veränderungsprojekts. Die Auswahl der im Praxisleitfaden be- 

handelten Themen und Fragestellungen orientierte sich also an den Fragestellungen und Prio- 

ritäten der projektbeteiligten Kommunen. 

Erstellung 

Rollenmodell 

Soll 

Soll-Ist-Vergleich 

Organisation 

Grobkonzept 

organisatorische 

Maßnahmen 

Prozesspotenzialcheck 

Qualitätssicherung 

Soll-Modell 

Erstellung 

IT-Funktions- 

Modell Soll 


Fach- 

Anwendungen 

Stufenkonzept Einführung Soll- Prozess und IT 

Alle dargestellten Checklisten, Erhebungsbögen usw. finden Sie auch im Internetangebot von 

d-NRW unter der Adresse http://www.d-nrw.de/referenzen/kdv/standardisierung-kommunaler- 

prozesse als Dokumentvorlagen zur unmittelbaren Verwendung. 

Grobkonzept 

technologische 

Maßnahmen 

Erstellung 

IT-AW-Architektur 

Soll 


E-Gov. 

Basiskomponenten 

Analyse und Darstellung fachlicher Anforderungen zur IT-Umsetzung 

der Umsetzungsstufe (-n) 

A 

QS Soll- 

Modell 

B 

Soll-/Ist- 

Vergleich 

C 

Stufen- 

Konzept 

D 

Fein- 

Konzept


2.2 Projektinitialisierung und Qualitätssicherung Soll-Modell 

Die Projektphase „Qualitätssicherung Soll-Modell“ besteht aus vier Arbeitspaketen: 

A. A. Der Abstimmung einer auf die jeweiligen Projektziele und -inhalte ausgerichteten 

Projektdokumentation und der im Projekt zu verwendenden Dokumentenvorlagen 

B. Dem Prozesspotenzialcheck, in dem der von der Kommune ausgewählte Ge- 

schäftsprozess im Hinblick auf mögliche Schwachstellen und Optimierungspotenzi- 

ale bewertet wird 

C. Der Qualitätssicherung des Soll-Modells, welches aus einer Prozessbibliothek oder 

sonstigen Quellen als „Blaupause“ für die Optimierung des ausgewählten Ge- 

schäftsprozesses dienen soll. 

D. D. Der Vorbereitung des Soll-Ist-Vergleichs, bei der Modellinhalte aus dem Soll-Modell 

extrahiert und in eine für den Soll-Ist-Vergleich geeignete Darstellung transformiert 

werden. 

A. Projektdokumentation 

Im Rahmen der Projektinitialisierung werden Projektziele, Umfang und Inhalte sowie Vorgehen 

und Arbeitspakete und der Projektterminplan mit allen Teilnehmern besprochen und die Struk- 

turierung der Projektdokumentation sowie die zu verwendenden Dokumentenvorlagen verbind- 

lich abgestimmt. Die folgenden Abbildungen 5 und 6 zeigen beispielhaft, welche Informationen 

auf dem Deckblatt der Projektergebnisdokumentation und in der Bearbeitungshistorie zu den 

jeweiligen Ergebnisdokumenten mindestens enthalten sein sollten. 

Prozessname: 

Prozesseigentümer/Fachbereich 

Mitgewirkt haben / Bearbeiter: 

Projektmoderator: 

Kontakt für Rückfragen: 

Inhaltsverzeichnis / Anlagen 

Dokument / Name: 

Abbildung 5: Deckblatt Projektergebnisdokumentation 

Version Nr Inhalt / Bearbeitungsvermerk Bearbeiter Status Datum 

Abbildung 6: Bearbeitungshistorie und Versionskontrolle


Wird die Projektdokumentation als Ergebnisdokumentatio verwendet, sollte sie auch Ergeb- 

nisse, Empfehlungen zur Umsetzung sowie zum weiteren Planungs- und Entscheidungsbedarf 

und eine Zusammenfassung wesentlicher Punkte enthalten. 

B. Checkliste Prozessoptimierung 

Die folgende „Checkliste“ (Abbildung 7, Seiten 21-25) enthält eine Reihe von Fragen zu mögli- 

chen Schwachstellen bzw. Optimierungsansätzen in kommunalen Leistungs- und Stützpro- 

zessen. Die Checkliste kann als Interviewleitfaden verwendet werden, um im Vorfeld einer 

detaillierten und modellbasierten Prozessanalyse erste Anhaltspunkte zu den in einem „Ist- 

Prozess“ versteckten Schwachstellen und Optimierungsansätzen zu erhalten. Im weiteren 

Verlauf der Prozesspotenzialanalyse dient die Checkliste zur Dokumentation von Projekter- 

gebnissen und als „Ideenspeicher“ für vertiefende Fragestellungen und Verbesserungsvor- 

schläge. Die Checkliste ist in mehrere Abschnitte gegliedert, die sich jeweils auf die in jedem 

Prozessablauf enthaltenen Teilprozesse beziehen. Diese Abschnitte lauten: 

a. „Kunden- und Partnerprozesse“ 

b. „Eingangsbearbeitung“ 

c. „Vorgangsbearbeitung“ 

d. „Ausgangsbearbeitung“ 

Bearbeitungshinweise: 

Zunächst sollten Sie im Tabellenkopf den Prozessnamen sowie die den Prozess auslö- 

senden „Startereignisse“ und die den Prozess beendenden „Endereignisse“ eintragen, 

um den Untersuchungsgegenstand einzugrenzen. 

Die Checkliste enthält mehrere Spalten zur Dokumentation der Interviewergebnisse: 

Notieren Sie in der Spalte „J/N“, ob ein bestimmter Sachverhalt zutrifft, bzw. ob er für die 

weitere Untersuchung relevant ist. 

Tragen Sie ggfs. In der Spalte „Wert“ quantifizierbare Größen und Angaben zu den Pro- 

zesssachverhalten ein, zum Beispiel: „Ist-Werte“ oder „Schätzwerte“. 

Priorisieren Sie den Sachverhalt in der Spalte „Prio“ nach dem bewährten A-B-C- 

Schema. 

Erläutern Sie ggfs. den Sachverhalt in der Spalte „Ursachen / Wirkungen / Bemerkun- 

gen“. 

Halten Sie ggfs. erste Ideen und Verbesserungsvorschläge in der Spalte „Empfehlun- 

gen“ fest. 

Checkliste: siehe Abbildung 7, folgende Seiten 21 bis 25


Checkliste Prozessoptimierung 

© d-NRW / b.i.t.consult, 2010 

Prozess Name: Prozess Start: Prozess Ende: 

Klasse/Nr. 

Mögliche Schwachstellen J/N Wert Prio Ursachen / Wirkungen / Bemerkungen Empfehlung 

A Kunden- und Partnerprozesse 

A 1 allgemeine Fragen zu Kunden und Partnerprozessen 

1 Wie hoch ist der Anteil der Anträge, die in bearbeitungsfähigem Zustand eingehen? 

7 Welche elektronischen Informationsangebote bestehen? 

8 Welche schriftlichen Informationsangebote bestehen? 

9 Welche telefonischen Informationsangebote bestehen? 

10 Welche persönlichen Informationsangebote bestehen? 

Sind alle Informationen, Formulare und Unterlagen "in der Sprache der Kunden" 

13 

verfasst? 

Qualität des Online Service Angebots 

A 2 

Sind Download-Formulare "interaktiv" und "fallspezifisch bzw. kontextsensitiv" 

aufgebaut und gestaltet? 

11 

Können Daten aus elektronischen Formularen oder Bearbeitungsmasken in 

Fachanwendungen importiert und genutzt werden? 

Abbildung 7: Checkliste Prozessoptimierung (1 / 5) 

18 

35 Können Verwaltungsgebühren Online bezahlt werden? 

Qualität des Bürger Service Angebots (Bürgeramt) 

5 Wann und wie oft ergeben sich Wartezeiten für die Kunden? 

6 Wann und wie oft ergeben sich Leerzeiten für die Mitarbeiter? 

A 4 

Werden alle bürgerorientierten Dienstleistungen der Verwaltung auch im BürgerService 

angeboten? 

8 

Wie hoch ist der Anteil der Bürgeranliegen, die im Erstkontakt abschließend erledigt 

werden können? 

13 

Kommt es häufig zu Rückfragen und Klärungen zwischen "Front-Office" und "Back- 

Office" Mitarbeitern? 

15 

Haben die Servicemitarbeiter ausreichenden Zugriff auf relevante Fachanwendungen 

der Verwaltung? 

17 

Werden Eingangsdokumente, die im BürgerService angenommen werden digitalisiert 

oder mit der Post ins Backoffice weitergeleitet? 

19 

Können Zahlungsvorgänge direkt beim Servicemitarbeiter/Kundenberater angenommen 

und abschließend, d.h. ohne Nachbearbeitungsaufwand in Kasse oder FiBu bearbeitet 

werden? 

20 

B Eingangsbearbeitung


Poststelle 

B 1 

1 Über wieviele Stationen erreicht die Eingangspost den zuständigen Bearbeiter? 

3 Wie hoch ist der Anteil der geschlossen zugestellten Posteingangsdokumente? 

Wie hoch ist der Anteil interner Absender bzw. Empfänger am Postaufkommen in der 

Poststelle? 

8 

10 Wie hoch ist der Anteil der im ersten Durchlauf falsch zugeordneten Posteingänge? 

Digitalisierung und Scan-Verfahren (frühes Scannen) 

B 2 

2 Werden eingehende Dokumente / Posteingänge an zentraler Stelle digitalisiert? 

Sind das Scan-Verfahren und nachgelagerte Vorgangsbearbeitungssysteme 

ausreichend integriert, werden die Dokumente in den Arbeitskorb des Bearbeiters 

übergeben? 

9 

Multikanalmanagement, Integrierte Kommunikationskanäle 

B 3 

Sind alle für den Prozess offenen Eingangskanäle, etwa: Fax, E-Mail/DE-Mail/E- 

Postbrief, Online Service und Telefon mit dem Vorgangsbearbeitungssytem / der 

Fachanwendung integriert und können deshalb in einer Anwendung ohne Medienbruch 

bearbeitet werden? 

1 

C Vorgangsbearbeitung 

C 1 Ablauforganisation, Prozessgestaltung 


a Kostentreiber 

1 Ist der Arbeitsablauf für alle Bearbeiter einheitlich geregelt, dokumentiert und bekannt? 

2 Arbeiten alle Bearbeiter nach diesem Ablauf? 

3 Welche Teilprozesse oder Prozessaktivitäten sind besonders kostenintensiv? 

Gibt es Aktivitäten im Prozessablauf, die überflüssig sind und entfallen können, ohne 

dass das gewünschte Prozessergebnis dadurch negativ beeinflusst wird? 

6 

b Zeitfresser 

Welche Teilprozesse oder Prozessaktivitäten "fressen" besonders viel 

Bearbeitungszeit? 

9 

12 Welche Teilprozesse oder Prozessaktivitäten benötigen besonders hohe Rüstzeiten? 

Welche Teilprozesse oder Prozessaktivitäten sind mit Liege- oder Wartezeiten 

verbunden? 

14 

16 Wo enstehen im Prozessablauf Transportzeiten?


18 Welche Störungen führen zu Unterbrechungen im Bearbeitungsablauf? 

Welche Teilprozesse, Prozessaktivitäten oder Tätigkeiten können zukünftig parallel 

statt sequenziell durchgeführt werden? 

20 

c Qualitätstreiber 

Welche Zuarbeiten, Vorarbeiten oder vorlaufende Aktivitäten verursachen besonders 

häufig Rückfragen oder Rückverweisungen (="Fehler")? 

23 

27 Welche Kosten entstehen durch die Fehler- Bearbeitung und Behebung? 

In welchem Verhältnis stehen die Kosten der Fehler- und Risikominimierung zu den 

Kosten der Fehlerbearbeitung? 

30 

Existieren bereits Qualität sichernde Tätigkeiten oder Kontrolltätigkeiten, die aber nie 

Fehler identifizieren und deshalb grundsätzlich entfallen können? 

31 

Welche (manuellen) Qualitätssicherungsmaßnahmen und Kontrollen können 

automatisiert werden? 

32 

Welche Fremdkontrollen werden können entfallen, weil sie bereits an anderer Stelle 

durchgeführt wurden? ("Sechs- und mehr-Augen-Prinzip" notwendig…?) 

34 

Aufbauorganisation 

C 2 

a Strukturierung 

Sind Zuständigkeiten und Prozessrollen (Aufgaben, Rechte, Pflichten) klar und 

überschneidungsfrei geregelt? 

35 

Wurden bei der Definition der Prozessrollen die Unterschiede zwischen kundennahen 

Front-Office Tätigkeiten, sachbearbeitenden Back-Office Tätigkeiten sowie 

unterstützenden Aufgaben und Führungsaufgaben angemessen berücksichtigt? 


36 

Ist die im Rollenkonzept festgelegte Arbeitsteilung im Hinblick auf die Erreichung der 

operativen Ziele effektiv (zielführend) und effizient (wirtschaftlich). 

38 

Kann die Bearbeitung durch eine Bündelung von Vor- und Zuarbeiten an anderer Stelle 

entlastet, beschleunigt oder kostengünstiger gestaltet werden? 

39 

40 Welche Vor- und Zuarbeiten können automatisiert werden? 

Kommt es im Bearbeitungsablauf zu (häufigen) Bearbeiterwechseln innerhalb des 

Fachbereichs oder zwischen verschiedenen Fachbereichen? 

41 

45 Werden Abstimmungen aufgrund räumlicher oder örtlicher Trennung erschwert? 

b Standardisierung 

46 Wie komplex und variantenreich ist der Prozessablauf? 

47 Wie viele Akteure und Rollen sind am Prozessablauf beteiligt? 

Kann der Prozessablauf durch eine Organisationsverfügung, zum Beispiel durch die 

Vorgabe eines Soll-Prozessablaufs, standardisiert werden? 

49 

Können Verfahrensregelungen oder Satzungen der Kommune, die aufwändige 

Arbeitsabläufe erzwingen vereinfacht werden? 

52


c Stellenbemessung 

Sind die Mitarbeiter gleichmässig ausgelastet, oder kommt es in bestimmten 

Aufgabenbereichen immer wieder zu Personalengpässen bzw. Arbeitsrückständen? 

53 

55 Existieren Aufgaben oder Tätigkeiten, für die sich niemand verantwortlich fühlt? 

Existieren Aufgaben oder Tätigkeiten, die durchgeführt werden, obwohl sie nicht 

Bestandteil einer Stellenbeschreibung bzw. Prozessrolle sind? 

56 

Prozessnahe IT-Unterstützung 

C 3 

a Automationspotenziale 

64 Welche manuellen Aktivitäten oder Tätigkeiten können automatisiert werden? 

Haben alle Bearbeiter elektronischen Zugriff auf alle für die Aufgabenwahrnehmung 

66 und Prozessdurchführung erforderlichen Informationen, Dokumente, Formulare und 

Textvorlagen? 

Können papiergestützte Vorgangsakten oder hybride Akten durch elektronische Akten 

ersetzt werden? 

68 

b IT-Anwendungen 

Stellt die Anwendung alle für die fachliche Bearbeitung der Fälle erforderlichen 

Funktionen (z.B.: Berechnungen zu Sonderfällen) zur Verfügung, sodass keine 

"Nebenrechnungen" oder "Bearbeitungen" ausserhalb der Anwendung erforderlich 

sind? 

69 

Werden bestimmte Daten redundant, d.h. an verschiedenen Orten oder in 

unterschiedlichen Anwendungen, erfasst, gespeichert und/oder gepflegt? 


70 

Welche "sonstigen", möglicherweise selbst entwickelten IT-Anwendungen und 

Hilfsmittel werden von den Sachbearbeitern genutzt? 

71 

Sind alle benötigten Anwendungen "auf dem Desktop" des Bearbeiters integriert, oder 

muss dieser ständig zwischen mehreren Anwendungen hin und her wechseln? 

73 

Können die Eingangs- und Ausgangs- Dokumente, Ergebnisdokumente und Vermerke 

elektronisch gespeichert werden? 

77 

Unterstützt die Anwendung das Management der Abläufe, oder findet das 

Workflowmanagement "im Kopf" des Sachbearbeiters statt? 

79 

Unterstützt die Anwendung die elektronische Aktenführung und die revisionssichere 

Dokumentation der Bearbeitungshistorie? 

80 

87 Wird der neueste Releasestand der Anwendung genutzt? 

Sind alle verfügbaren Funktionsmodule der Anwendung implementiert, auf dem 

aktuellen Stand und werden sie auch tatsächlich genutzt? 

88 

Sind alle Mitarbeiter ausreichend in der professionellen Nutzung der Anwendung 

geschult und geübt? 

90 

c IT-Schnittstellen


Wo existieren Medienbrüche im Prozessablauf, die zum Beispiel ein "Ausdrucken" oder 

"Erfassen" von Informationen oder Daten erforderlich machen? 

91 

Sind alle Eingangs- und Ausgangs- Medien (Online Portal, mail, fax, Post) die der 

Geschäftsprozess nutzt mit dem die Vorgangsbearbeitung "führenden" System 

integriert? 

92 

Können Daten, die bereits in internen oder externen It-Anwendungen der öffentlichen 

Verwaltung gespeichert sind, automatisiert abgefragt und ohne Medienbruch 

weiterverarbeitet werden? 

94 

Sind erforderliche Schnittstellen zu vor- oder nachgelagerten Anwendungen und 

Systemen (z.B.: Kasse) vollständig implementiert und funktional angemessen 

ausgestaltet (z.B.: "bidirektional")? 

96 

d Infrastruktur am Arbeitsplatz: 

Haben alle Mitarbeiter an ihrem Arbeitsplatz Zugriff auf wichtige Basisanwendungen wie 

etwa: Intranet, E-Mail Service, Online-Recherchemöglichkeiten usw. 

98 

Ist die Qualität der Bildschirmausstattung zur Sichtung und Bearbeitung elektronischer 

Dokumente ausreichend? 


99 

Verfügen die Arbeitsplatz-Rechner über eine angemessene Rechen-Kapazität und 

aktuelle Standardsoftware? 

100 

Ist die am Arbeitsplatz verfügbare Bandbreite ausreichend und ermöglicht 

angemessene Lade- und Antwortzeiten? 

101 

Ermöglicht die Ausstattung mit sonstigen Peripheriegeräten (z.B.: Scanner, Printer, 

Kartenleser) ein zügiges arbeiten? 

102 

D Ausgangsbearbeitung 

D 1 intern 

Kann der innerbehördliche Austausch von (Papier-) Dokumenten zugunsten der 

elektronischen Kommunikation reduziert werden? 

1 

extern 

D 2 

Kann die manuelle Bearbeitung des Postausgangs (drucken, kuvertieren, freimachen) 

zentralisiert und automatisiert werden? 

1


C. Qualitätssicherung von Soll-Modellen 

Die Qualitätssicherung von Soll-Modellen unter Einbeziehung der Fachdienste und der IT ist in 

mehrfacher Hinsicht ein erfolgskritischer Projektschritt. Sie dient zunächst dazu, das Soll- 

Modell im Hinblick auf seine verwaltungsfachlichen, betriebswirtschaftlichen und informations- 

technologischen Inhalte und Aussagen zu diskutieren und zu überprüfen. Mindestens ebenso 

wichtig ist jedoch, dass in der Diskussion des Soll-Modells ein gemeinsames Verständnis der 

Ziele und Möglichkeiten zur Prozessoptimierung in der Projektgruppe erreicht wird. 

Der in Abbildung 8 dargestellte Fragebogen dient als Checkliste, Ergebnisdokumentation und 

Ideenspeicher zur Qualitätssicherung von Soll-Prozess-Modellen: 

Leitfragen zur „Qualitätssicherung des Soll-Modells“ 

Bitte diskutieren Sie diese Leitfragen mit ihren Fachexperten! 

Fügen sie ggfs. Verbesserungsvorschläge oder Kommentare unter „Bemerkungen“ ein 

Ergänzen Sie bitte bei Bedarf die Leitfragen und Bemerkungen! 

1 

Fachmodell / fachliche Inhalte: 

Enthält das Modell alle am Prozess beteiligten Akteure und Rollen (interne, ex- 

terne Prozessbeteiligte)? 

2 Fachmodell / fachliche Inhalte: 

3 

A 

B 

C 

D 

Sind alle Geschäftsaufgaben und Fallkonstellationen, die aus fach- und verfah- 

rensrechtlicher Sicht mindestens bearbeitet werden, müssen durch das Modell 

abgedeckt? 

Fachmodell / fachliche Inhalte: 

Enthält das Modell alle im Zuge der Bearbeitung benötigten Geschäftsobjekte 

und Informationsobjekte? 

Sind alle Inputobjekte im Modell enthalten? 

Sind alle Outputobjekte im Modell enthalten? 

Ist ihre Benennung aus fachlicher Sicht korrekt und eindeutig? 

4 Prozesslogik: 

Sind alle Schnittstellen zu (internen und externen) Stützprozessen berücksich- 

tigt? 


Sind alle Schnittstellen zu externen Prozessen / Partnerprozessen berücksich- 

tigt?



Sind die vom Kunden der Verwaltungsleistung durchzuführenden Geschäftsauf- 

gaben und Aktivitäten („Kundenprozesse“) berücksichtigt? 

7 Medienintegration: 

Wurden alternative Zugangswege (Multikanalmanagement) und Kommunikati- 

onskanäle (Medienintegration) im Modell berücksichtigt? 

8 E-Government und Prozessautomation: 

Wurden alle zurzeit „am Markt für i-Technologie“ verfügbaren E-Government 

Service Optionen („State of the Art E-Government“) berücksichtigt? 

(Entspricht das E-Government Soll-Modell dem letzten Stand der Technik?) 

9 E-Government und Prozessautomation: 

Wurden mögliche Auswirkungen von E-Government und Prozessautomation auf 

die Organisations- und Prozessstruktur korrekt eingeschätzt und modelliert? 

10 Technologischer Innovationsbedarf: 

Wie würde die Lösung aussehen, wenn NEUE E-Government Service Optionen 

integriert würden? (z.B.: „E-Postbrief“, „DE-Mail“, „E-PA“) 

11 Organisatorische Innovationen: 

Wurde das Front Office / Back-Office Organisations-Prinzip angemessen be- 

rücksichtigt? 

12 Organisatorische Innovationen: 

Wurden im Soll-Modell Chancen und Möglichkeiten zur Einführung von „Shared 

Services“ angemessen berücksichtigt? 

13 Rechtlicher Innovationsbedarf: 

Bestehen nach Ihrer Einschätzung Hindernisse im Rechtsrahmen des Verwal- 

tungshandelns zur Durchführung bzw. Umsetzung des Soll-Modells? 

Abbildung 8: Fragebogen zur "Qualitätssicherung Soll-Modell" 

D. Vorbereitung des Soll-Ist-Vergleichs 

Nachdem das Soll-Modell anhand der oben dargestellten Fragen im Hinblick auf seine Voll- 

ständigkeit und Plausibilität überprüft wurde, muss in einem nächsten Schritt der Soll-Ist- 

Vergleich vorbereitet werden. Dazu müssen bestimmte Modellinhalte aus dem Soll-Modell ext- 

rahiert und in eine für den Soll-Ist-Vergleich geeignete Darstellung transformiert werden. Mögli- 

cherweise liegt das Soll-Modell bereits als „Datei“ in einem Datenbank gestützten Modellie- 

rungswerkzeug vor. In diesem Fall können die im Folgenden beschriebenen Teilmodelle mögli-


cherweise mit Hilfe einer „Report-Funktion“, d.h. durch eine Modellierungswerkzeug gestützte 

Auswertung aus der Modelldatenbank erzeugt und grafisch oder tabellarisch dargestellt wer- 

den. Alternativ dazu erfolgt die Extraktion der Modellinhalte „manuell“. Für die Darstellung der 

für den Soll-Ist-Vergleich erforderlichen Teilmodelle empfehlen wir in diesem Fall die Nutzung 

folgenden Vorlagen: 

Rolle 1 

Rolle 2 

Rolle 3 

Rolle 2 

A 2 

a. Rollenmodell 

b. Prozessfunktionstabelle 

c. IT-Anwendungsarchitekturdiagramm 

„Soll-Prozessmodell“ 

A 1 

A 4 

A 5 

A 6 

A 7 

A 3 

A 8 

AW 1 

AW 2 

AW 1 

Abbildung 9: Vorgehen und Beteiligte zur Vorbereitung des Soll-Ist-Vergleichs 

Die oben stehende Abbildung 9 zeigt schematisch auf, wie die „Zerlegung“ und Transformati- 

on des integrierten Soll-Modells, in dem fachliche, organisatorische und technologische Sach- 

verhalte in einer kompakten, mehrperspektivischen Darstellung zusammengefasst wurden, in 

die Teilperspektiven bzw. Teilmodelle erfolgen soll. Diese Aufgabe ist eine „Gruppenarbeit“, 

bei der mehrere Fachexperten zu Rate gezogen werden sollten: 

Die Rolle „Organisator“ hat die Aufgabe, das Soll-Modell zu erläutern, das Rollenmodell 

zu extrahieren und die Arbeit zu moderieren. 

Die Rolle „Fachexperte“ hat die Aufgabe, die aus fachlicher Sicht zur Prozessdurchfüh- 

rung erforderlichen IT-Bearbeitungsfunktionen zu benennen und wird dabei vom IT- 

Anwendungsbetreuer beraten. 

„Rollenmodell“ 

Rollen 

Rolle 1 

A 1 

Aufgaben 

Rechte 

Der „Anwendungsbetreuer“ bringt sein aktuelles Wissen über prozessrelevante IT- 

Anwendungen und Servicekomponenten ein und kann die aus fachlicher Sicht geforder- 

ten IT-Funktionen bestimmten IT-Anwendungen und Komponenten zuordnen. 

A 2 

A 3 

Rolle 2 

AW 1 

A 6 

A 7 

A 8 

Rolle 3 

„IT-Anw.-Architektur“ 

A 4 

A 5 

AW 2 

„IT-Funktionsmodell“ 

A 2 

A 3 

AW 1 

Aw1 

A 6 

A 7 

A 8 

portal 

Service 

Service 

AW 2 

A 4 

A 5 

Service 

Organisator Anwendungs- 

Betreuer 

Fachexperte 

IT-System 

-architekt


Der „IT-Systemarchitekt“ stellt alternative Lösungsszenarien vor und skizziert, wie die 

vom Prozess geforderten IT-Komponenten und Services innerhalb der E-Government 

Anwendungsarchitektur zusammenspielen. 

a. Rollenmodell 

Das Rollenmodell enthält alle am Prozess beteiligten Prozessrollen und beschreibt deren Ar- 

beitsaufgaben in der Form von Aktivitäten, Aktivitätengruppen oder Teilprozessen. Das Rol- 

lenmodell bildet den Ausgangspunkt für den organisatorischen Soll-Ist-Vergleich, indem die im 

Soll-Modell definierte Zuordnung der Arbeitsaufgaben zu den Rollen mit der bestehenden Auf- 

gabenverteilung in der Organisation verglichen wird. 

Das Rollenmodell kann tabellarisch oder grafisch dargestellt werden. Die grafische Darstellung 

kann in der Regel sehr einfach durch „copy & paste“ 7 der entsprechenden Notationselemente 

aus dem grafischen Prozessmodell erzeugt werden und eignet sich besser zur Visualisierung 

der Rollen, zum Beispiel für Gruppendiskussionen und Workshops. 

Abbildung 10: Grafische Darstellung Rollenmodell 

Die tabellarische Darstellung des Rollenmodells macht ohne Werkzeugunterstützung mehr 

Arbeit (die entsprechenden Inhalte und Aussagen aus dem grafischen Modell müssen in die 

Tabelle übertragen werden), ist aber auch wesentlich aussagekräftiger und kann zum Beispiel 

als Vorlage und Input für eine Stellenbeschreibung wieder verwendet werden: 

7 copy & paste = „Kopieren und Einfügen“ 

Rolle 

Teilprozess 

Aktivitätengruppe 

Aktivität 

Abbildung 11: Tabellarische Darstellung "Rollenmodell"


Bearbeitungshinweise 

Die Zuordnung der Teilprozesse, Aktivitätengruppen und Aktivitäten sowie die zu ihrer 

Bearbeitung erforderlichen Hilfsmittel und Ressourcen ergeben sich unmittelbar aus der 

grafischen Prozessdarstellung. 

Die Aktivitäten können jeweils nur einer Rolle, nämlich ihrem „Eigentümer“, zugewiesen 

werden, Interaktionen mit anderen Rollen führen immer zu Aktivitäten auf beiden Seiten 

der Interaktion (überschneidungsfreie Aktivitäten). 

Entscheidungen und Entscheidungskompetenzen können in der Regel aus den an den 

Prozessverzweigungen angegebenen Entscheidungsregeln („business rules“ 8 ) abgele- 

sen oder auch aus entsprechenden Kommentierungen des Fachmodells abgeleitet wer- 

den. 

Zu den „Rechten“ werden unter anderem die „Zugriffsrechte“ auf bestimmte IT- 

Anwendungen gerechnet. 

Die Tabelle sollte bei Bedarf und im Sinne der Übersichtlichkeit im Bereich „Teilprozes- 

se, Aktivitätengruppen und Aktivitäten“ um weitere Zeilen erweitert werden. 

b. Prozessfunktionstabelle 

Die Prozessfunktionstabelle stellt eine Erweiterung des grafischen Soll-Modells dar. Sie be- 

schreibt „en Detail“ welche unterstützenden IT-Funktionen oder IT-Services der Fachprozess 

erfordert. Mit Hilfe der Prozessfunktionstabelle können alle Prozess unterstützenden IT- 

Anwendungen durch einen Abgleich der Soll-Funktionen mit den Ist-Funktionen im Hinblick 

auf die Qualität und den Umfang der Prozessunterstützung bewertet und funktionale „Lücken“ 

in der prozessnahen IT identifiziert werden. In der Praxis enthalten die Soll-Modelle nur selten 

Informationen, die unmittelbar Auskunft über alle benötigten IT-Services und IT-Funktionen 

geben, da Fachmodelle in der Regel „nur“ den Detaillierungsgrad von „Aktivitäten“ und von mit 

den Aktivitäten assoziierten IT-Anwendungen erreichen. Dennoch bietet das Soll-Modell eine 

sehr gute Ausgangsbasis zur Identifikation funktionaler IT-Anforderungen. Kernfrage dabei ist: 

„Welche maschinellen, teilmaschinellen oder manuellen Bearbeitungsfunktionen sind in einer 

Fach-Prozessaktivität (implizit) enthalten?“. Logik und Vorgehen zur Identifikation der funktio- 

nalen IT-Anforderungen aus einem Soll-Modell sind in der folgenden Abbildung schematisch 

dargestellt: 

8 business rules = Geschäftsregeln. Diese sind zum Beispiel bei der Entwicklung maschinell gesteuerter Prozessabläufe 

besonders wichtig und müssen dann in eine „maschinenlesbare“ Form gebracht werden.


Rolle 1 

Rolle 2 

Rolle 3 

Rolle 2 

„Soll-Prozessmodell“ 

A 2 

A 1 

A4 

A 5 

A 6 

A 7 

Geschäfts- 

Aufgabe / 

„Aktivitäten- 

Gruppe“ 

Abbildung 12: Ableitung funktionaler IT-Anforderungen aus dem Fachmodell 

Auch hier ist es ratsam unterschiedliche Experten an der Aufgabe zu beteiligen, dazu gehören: 

die Rollen „Organisator“, „Fach-Prozessexperte“ und „IT-Anwendungsbetreuer“. Um die Funkti- 

onsanforderungen systematisch zu erfassen und für den Soll-Ist-Vergleich aufzubereiten, sollte 

die grafische Darstellung des Soll-Modells zunächst in eine tabellarische Darstellung überführt 

werden. Professionelle Modellierungswerkzeuge unterstützten dies in der Regel durch entspre- 

chende Auswertungsfunktionen. Andernfalls muss die Transformation der Darstellung manuell 

erfolgen, indem die für die „Prozessfunktionsanalyse“ relevanten grafischen Modellinhalte und 

Aussagen in eine Excel-Tabelle überführt werden. Die von uns empfohlene Tabellenstruktur ist 

in der Abbildung 13 dargestellt. 


A 3 

A 8 

AW 1 

AW 2 

AW 1 

Aktivität 

Aktivität 

Die Prozessfunktionstabelle dient der Erfassung und Spezifikation der funktionalen IT- 

Anforderungen (IT-Bearbeitungsfunktionen) aus der Perspektive des Soll-Modells. Sie ist 

über die Projektphasen "Grobkonzept" bis zur "Feinkonzeption" im Sinne eines Anforde- 

rungskonzepts und Pflichtenhefts für die IT-Umsetzung laufend fortzuschreiben. Dabei ist 

die Versionskontrolle (siehe; Bearbeitungshistorie) zu beachten. Die Prozessfunktionsta- 

belle entsteht als Extrakt bestimmter Informationen durch manuelle Übertragung oder als 

Report aus einem Modellierungswerkzeug aus dem Soll-Modell. Verantwortlich für die 

Erstellung der Prozesstabelle ist der Organisator bzw. Prozessberater. Er wird dabei un- 

terstützt durch die Prozessexperten aus dem Fachbereich und die IT- 

Anwendungsbetreuer der Kommune. 

Prozessfunktionstabelle SOLL / IST 

Aktivität Funktion IT-Anwendung 





Manuelle 

Tätigkeit 

Maschinelle 

Funktion 

Übertragen Sie zunächst das Aktivitätenflussdiagramm in die Tabelle (Spalten A-F). 

Durch die konsistente Nummerierung der Prozesselemente können grafisches Modell


und Tabelle jederzeit aufeinander bezogen werden. Es ist empfehlenswert, die Zuord- 

nung der Aktivitäten zu den Prozessrollen "in einem Zuge" durchzuführen. Tragen Sie 

zunächst die im Prozessmodell verwendeten Rollen in den Tabellenkopf (Spalten G-I) 

ein. Fügen Sie bei Bedarf zusätzliche Spalten ein. Weisen Sie die Aktivitäten durch Ein- 

trag einer "1" in die entsprechende Rollenspalte einer Rolle zu. Die Verwendung der "1" 

anstelle eines "X" ermöglicht später numerische Auswertungen. 

Prüfen Sie, ob die von Kunden durchzuführenden Prozessaktivitäten im Modell (mindes- 

tens in der Prozesslandkarte) enthalten sind (Beispiel: "Antrag erstellen"). Diese müs- 

sen zum Beispiel in Fällen, bei denen „Online Anträge" zum Soll-Konzept gehören, ge- 

nau wie verwaltungsinterne Prozesse modelliert und spezifiziert werden. Prüfen Sie 

gleichfalls, ob (mindestens in der Prozesslandkarte) die von den Prozesspartnern 

durchzuführenden Prozessaktivitäten im Modell enthalten sind. In vielen Fällen nutzen 

Prozesspartner ebenfalls IT-Systeme, zu denen dann im Sollkonzept IT-Schnittstellen 

entwickelt werden müssen. 

Übertragen Sie nun zu jeder Aktivität die Input- Daten und Dokumente aus dem Grafi- 

schen Prozessmodell (Spalten: J-K). 

Im nächsten Schritt beginnt die Spezifikation der Anforderungen des Soll-Modells an die 

Prozess unterstützenden IT-Anwendungen und Komponenten. Dabei ist es zunächst 

völlig unerheblich, welche Anwendung oder Komponente die gewünschte Bearbeitungs- 

funktion später bereitstellen wird. Dies zu entscheiden obliegt dem IT- 

Systemarchitekten. Um die vom Prozess benötigten IT-Bearbeitungsfunktionen zu er- 

kennen und allgemeinverständlich zu beschreiben, sollten Sie zunächst die Fachexper- 

ten befragen, welche Tätigkeiten mit der Durchführung der jeweiligen Prozessaktivität 

verbunden sind und welche Geschäftsobjekte oder Informationsobjekte (Daten und Do- 

kumente) dabei angenommen, erzeugt, bearbeitet, erfasst, geprüft, gezeichnet, gespei- 

chert, versendet usw. werden. Aus der Beschreibung der notwendigen Arbeitsschritte 

können die von der Prozessaktivität geforderten IT- Bearbeitungsfunktionen in der Re- 

gel direkt abgeleitet werden. Dies erfordert allerdings eine gute Allgemeinkenntnis der 

Unterstützungsmöglichkeiten und Automationspotenziale, die IT heutzutage anbieten 

kann! Diskutieren und erfassen Sie vorhandene und gewünschte IT-Funktionen. Bitte 

vergessen Sie dabei nicht die Automationspotenziale an Schnittstellen zu externen und 

internen Prozessbeteiligten. Nehmen Sie dazu die Prozesslandkarte zur Hilfe; dort soll- 

ten alle Schnittstellen zu externen und internen Prozessbeteiligten eingetragen sein. 

Tragen Sie die Ergebnisse in der Spalte L „IT-Bearbeitungsfunktionen Beschreibung" 

ein. Fügen sie ggfs. in der Spalte Q "Bemerkungen" ergänzende Informationen hinzu. 

Bei komplexen Aktivitäten kann es sehr hilfreich sein, diese zunächst in einem zusätzli- 

chen Modellierungsschritt weiter zu verfeinern. Dabei wird der Ablauf der Tätigkeiten 

wiederum in einem grafischen Ablaufmodell modelliert. Hilfreich ist es, auf dieser Detail- 

lierungsebene zwischen "manuellen Tätigkeiten" (Arbeitsschritten) und "maschinellen 

Bearbeitungsfunktionen" zu unterscheiden. Ergänzen Sie bei Bedarf die Prozessfunkti- 

onstabelle im Bereich "Aktivitätenflussdiagramm" an den entsprechenden Aktivitäten um 

eine Spalte "Tätigkeiten".


Nun ist es möglich, mit Hilfe der vollständig ausgefüllten Prozessfunktionstabelle den Soll- 

/Ist- Vergleich der geforderten und der von den vorhandenen IT-Anwendungen und An- 

wendungskomponenten bereitgestellten Bearbeitungsfunktionen durchzuführen. Spre- 

chen Sie dazu mit den IT-Anwendungsbetreuern und IT-Architekten Ihrer Kommune. 

Diese wissen in der Regel, welche der vom Soll-Prozess geforderten IT- 

Bearbeitungsfunktionen von welcher Anwendung oder Anwendungskomponente bereit- 

gestellt werden (Ist) oder bereitgestellt werden können (Soll), bzw. welche IT-Module zu- 

sätzlich beschafft oder entwickelt werden müssen, um den Sollprozess zu realisieren. 

Dokumentieren Sie ihre Gesprächsergebnisse dazu in den Spalten: M-Q.


Abbildung 13: Vorlage Prozessfunktionstabelle 

A B C D E F G H I J K L M N O P Q 

Aktivitätenflussdiagramm Bearbeiter-Rolle Daten und Dokumente IT-Bearbeitungsfunktionen 

Anwendung / Komponente 

Bemerkungen 

TP-Nr TP-Name AkGr-Nr. AkGr-Name Akt-Nr. Aktivität-Name Rolle-Name Rolle-Name Rolle-Name Input Output Beschreibung IST SOLL Name Hersteller 

1 1.1 1.1.1 1 Antrag Eingangsbestätigung 

1.1.2 1 

1.2 

2 2.1 2.1.1 1


c. IT-Anwendungsarchitekturdiagramm 

Das Anwendungsarchitekturdiagramm skizziert den grundsätzlichen Aufbau und das Zusam- 

menspiel der vom Soll-Modell geforderten IT-Anwendungen. Es handelt sich dabei um eine 

grob vereinfachte Darstellung in der Form eines Blockdiagramms. Zur Erstellung des Soll- 

Modell spezifischen IT-Anwendungsarchitekturdiagramms müssen die im Soll-Modell aufge- 

führten IT-Anwendungen oder Servicekomponenten in das E-Government IT-Framework ein- 

geordnet werden. Die folgende Abbildung 14 stellt dieses E-Government IT-Framework in ver- 

einfachter Form als Blockdiagramm dar. Diese Abbildung können Sie als Vorlage für die Erstel- 

lung ihres Prozess spezifischen IT-Anwendungsarchitekturdiagramms verwenden, indem Sie 

die vom Soll-Prozess benötigten Anwendungen, Komponenten und Dienste in das entspre- 

chende „Feld“ eintragen und alle nicht benötigten Komponenten weglassen. 

Vorsprache 

Telefon 

DOC 

Brief 

Logistik-Service 

Bündeln 

Zustellen 

Scan-Service 

Registrieren 

Digitalisieren 

Indizieren 

SCAN- 

Extrahieren 

Service 

Input Mgmt. 

Zuordnen 

Aufklären 

Weiterleiten 

E-Mail 

Sonst. Verzeichnisdienste 


Abbildung 14: Skizze des E-Government IT-Frameworks 

Gehen Sie bitte das komplette Soll-Modell durch und notieren Sie alle im Modell aufge- 

führten IT-Anwendungen, IT-Dienste und Komponenten sowie Schnittstellen und Daten- 

dienste (professionelle Modellierungswerkzeuge können dazu eine Auswertung der in ei- 

nem Modell verwendeten IT-Ressourcen erstellen) 

Berücksichtigen Sie dabei bitte unbedingt die Kunden- und Partnerprozesse mit ihren 

verschiedenen Verwaltungszugängen und möglicherweise unterschiedliche Zugänge 

(mobil, stationär) für die Mitarbeiter der Verwaltung, sowie die Schnittstellen zu internen 

Stütz- und Partnerprozessen aus der Prozesslandkarte! 

Ordnen Sie nun die identifizierten IT-Ressourcen des Soll-Modells in das Architekturdia- 

gramm ein 

Online Brief 

Online 

Zugang 

(Kunde) 

Extranet 

Zugang 

(Intermediär) 

Intranet 

Zugang 

(Mitarbeiter) 

Mobiler 

Zugang 

(Mitarbeiter) 

(Prozess-) Portal (Composite Application Plattform, Desktop/Taskflow) 

Vorgangssteuerung (Workflowmanagement System/bus) 

Servicesteuerung (Middleware, Servicemanagement System/bus ) 

E-Mail 

Elektronische Vorgangsbearbeitung 

(Workflow Management & Service-Aufrufe) 

E-Poststelle 

Virtuelle Poststelle 

E-Signatur 

Identity Management 

Input Management. 

& 

Verzeichnisdienste 

E-Government Portal 

Servicebibliothek (Service Repository) 

E-Governmnent Basiskomponenten 

Customer Management 

Dokumenten- Mgmt. 

& sonstige 

Basis-Dienste 

(z.B.: Formulare, Payment, 

Content usw.) 

E-Shop-Systems 

E-Payment Systems 

Content Management 

Knowledge Management 

Office Anwendungen 

Formular Management 

It-Hardware- und Netzinfrastruktur 

Document Management 

HKR-System 

EWO-Melde-Register 

sonstige Fachverfahren 

Telefon 

Fachverfahren Fach- 

Verfahren, 

Fach- 

Dienste 

Sonstige Web-Services 

Office Anwendungen 

E-Mail 

Online Brief 

Brief 

E-DOC DOC 

Versand-Mgmt 

Nachweis 

. 

erbringen 

zustellen 

Versenden 

Print-Mgmt 

Output 

Vorsprache 

Freimachen 

. 

Couvertieren 

Mgmt. Drucken / 

Weiterleiten 

PRINT- 

Registrieren 

Indizieren 

Service 

konvertieren 

Output-Mgmt 

DOC


Behandeln Sie dabei IT-Schnittstellen zu internen oder externen Prozessbeteiligten wie 

„Fachdienste“ 

Lassen Sie die Anwendungsbereiche im Framework, die nicht zur Umsetzung des Soll- 

Modells erforderlich sind, weg. 

2.3 Soll- / Ist-Vergleich 

Nachdem das Soll-Modell qualitätsgesichert und seine organisatorischen und technologischen 

Aussagen und Inhalte aufbereitet wurden, kann ein Vergleich zwischen Ist- und Soll-Situation 

der Prozessimplementierung durchgeführt werden, um die Differenzen und Handlungsbedarfe 

herauszuarbeiten und einer systematischen Umsetzungsplanung zugänglich zu machen. Der 

Soll-Ist-Vergleich besteht aus zwei Bereichen, dem organisatorischen und dem technologi- 

schen Soll-Ist-Vergleich. Der Soll-Ist-Vergleich liefert also die „Bausteine“ für das im nächsten 

Projektschritt zu erstellende „Stufenkonzept“ zur Einführung des Soll-Modells. 

Da bereits ein qualitätsgesichertes Soll-Modell vorliegt, kann an dieser Stelle in der Regel auf 

eine aufwendige Ist-Modellierung verzichtet werden. Sie wäre nur dann erforderlich, wenn zum 

Beispiel ein Prozesskostenvergleich erwünscht ist, der die Prozessoptimierungseffekte quanti- 

fiziert und als Grundlage für eine Wirtschaftlichkeitsbetrachtung des Prozessprojekts herange- 

zogen werden soll. Gegebenenfalls kann die Wirtschaftlichkeitsbetrachtung aber auch „qualita- 

tiv“ durch die Anwendung der „Checkliste Prozessoptimierung“ auf den Ist-Prozess durchge- 

führt werden. Wir empfehlen in jedem Fall die Wirtschaftlichkeitsbetrachtung mit dem Stufen- 

konzept zu verknüpfen, damit sicher gestellt ist, dass jede einzelne Umsetzungsstufe „greifba- 

re“ Effekte und Vorteile erzielt. Die Wirtschaftlichkeitsbetrachtung der Umsetzungsstufen kann 

also auch zur Überprüfung der Plausibilität des Stufenkonzepts herangezogen werden. 

Organisatorischer Soll-Ist-Vergleich 

Der organisatorische Soll-Ist-Vergleich beantwortet die Frage, wie das Rollenkonzept des Soll- 

Modells in die bestehende Aufbauorganisation integriert werden soll und welche Verände- 

rungsbedarfe sich im Zuge dieser Integration im Bereich der Aufbauorganisation ergeben. Er 

liefert dadurch eine erste Grundlage für die Planung von Maßnahmen und die Eingrenzung 

der im anstehenden Veränderungsprozess zu beteiligenden Stellen und Personen. Zur Durch- 

führung des Abgleichs muss die Definition der Prozessrolle mit den ihr zugeordneten Aufga- 

ben und Tätigkeiten mit der Aufgabenbeschreibung der Stellen im Organigramm abgeglichen 

und „kompatibel“ gemacht werden. Jede mögliche Abweichung, zum Beispiel im Hinblick auf: 

Aufgabenumfang und Inhalte der Stelle, damit verbundene „Rechte & Pflichten“, Anforderun- 

gen an den Stelleninhaber, Qualifikationserfordernisse, Stellenbewertung, Stellenbemessung 

usw. muss durch eine entsprechende „Maßnahme“ in den „Sollzustand“ überführt werden. 

Die folgende Abbildung stellt Hilfsmittel und Ansatzpunkte sowie die beteiligten Akteure im 

organisatorischen Soll-Ist-Vergleich schematisch dar:


Rolle 1 

A 1 

Rolle 3 

A4 

A 5 

„Rollenmodell“ 

A 2 

A 3 

Rolle 2 

A 6 

A 7 

A 8 

Abbildung 15: Prinzip des organisatorischen Soll-Ist-Vergleichs 

Der organisatorische Soll-Ist-Vergleich führt zu einer Liste von organisatorischen Maßnahmen, 

die erforderlich sind, um das Soll-Modell in der Organisation zu implementieren. Ein Beispiel: 

Die Rolle 2 mit den Aktivitäten A2, A3, A6, A7 und A8 aus dem Soll-Modell soll auf der Stelle X 

implementiert werden. Die Ist-Stellenbeschreibung berücksichtigt diese Aktivitäten nicht. Daher 

wäre eine Anpassung erforderlich. 

? 

Der folgende Fragebogen enthält eine Zusammenstellung der Erkenntnis leitenden Fragen zur 

Durchführung des organisatorischen Soll-Ist-Vergleichs. Die Beantwortung der Fragen führt im 

Ergebnis zu einer ersten Übersicht zu den für die Projektdurchführung erforderlichen Maßnah- 

men im Bereich der Organisation und des Veränderungsmanagements 9 . Die Fragen sind nach 

folgenden Überschriften gegliedert: 

´FB / OE 

A Projektnutzen und Ziele 

B Handlungsfeld abgrenzen 

C Handlungsbedarfe erkennen 

D Projektvorschlag entwickeln 

E Entscheidungsbedarfe erkennen 

F Projektorganisation planen 

Leitfragen zum „Soll-Ist-Vergleich Organisation“ 

Organigramm / 

Stellenbeschreibung 

Stelle A 

Stelle B 

Stelle X Stelle Y Stelle Z 

Aufgaben 

Stelle X 

Aufgaben 

Stelle A 

Aufgaben 

Stelle B 

Aufgaben 

Stelle Y 

Erstellen bzw. „extrahieren“ Sie zunächst aus dem Soll-Prozess-Modell das Rollenmodell 

zum vorliegenden Soll-Prozess. 

Nehmen Sie ein Organigramm, Aufgabenverteilungsplan und ggfs. Stellenbeschreibungen 

ihrer Kommune / Organisation zur Hand und referenzieren Sie die Rollen und ihre Geschäftsaufgaben 

auf „ihre“ Organisationsstruktur (Stellen). 

9 Siehe Kapitel 3 „Hinweise zum Veränderungsmanagement“ am Ende des Praxisleitfadens. 

Aufgaben 

Stelle Z 

Organisator 

Führungskraft 

Personal- 

Betreuer


Bitte diskutieren Sie die dabei folgenden Leitfragen mit ihren Fachexperten! 

Identifizieren Sie dabei ggfs. alle Abweichungen zwischen „IST“ und „SOLL“ und tragen Sie 

Ergebnisse und Maßnahmenvorschläge zur Veränderung in die folgende Tabelle ein. 

A Projektnutzen und Ziele: 

1 Welche übergeordneten („strategischen“ und „politischen“ Ziele werden durch 

das Projekt unterstützt und erreicht bzw. „gefördert“? 

Wie kann die Zielerreichung gemessen werden? 

2 Welchen konkreten Nutzen bringt das Projekt für die Kommune? 

Wie kann der erreichte Nutzen gemessen werden? 

B Handlungsfeld abgrenzen: 

3 Welche Organisationseinheiten, Entscheider und Aufgabenträger sind heute an 

der Leistungserbringung beteiligt und deshalb direkt von der Einführung des 

Soll-Prozesses „betroffen“? 

4 Welche Organisationseinheiten, Entscheider und Aufgabenträger sind zu 

„beteiligen“ und/oder zu „informieren“? 

5 Ist die Personalvertretung zu beteiligen bzw. zu informieren? 

C Handlungsbedarfe erkennen: 

6 Können Rollen / Aufgabenzuordnungen auf die bestehende Struktur übertragen 


7 Ändert sich die Aufbauorganisation? 

8 Ändert sich die Aufgabenverteilung? 

9 Ändert sich die Ablauforganisation? 

10 Ist die für die Einführung des Soll-Prozesses die Einführung einer organisationsübergreifenden 

Prozessverantwortung erfolgskritisch? 

11 Welche (internen und externen) Liefer- und Leistungsbeziehungen und Vereinbarungen 

(„Service Level Agreements“) dazu sind betroffen? 

D Projektvorschlag entwickeln: 

12 Welche Maßnahmen sind im Bereich der Organisation zu ergreifen um den 

Soll-Prozess einzuführen? 

13 Welche organisatorischen Maßnahmen sind erfolgskritisch und haben deshalb 

eine hohe Priorität? 

14 Welche organisatorischen Maßnahmen (und Entscheidungen) stehen in einem 

sachlichen oder zeitlichen Zusammenhang und müssen deshalb in einem 

„Maßnahmenpaket“ zusammengeführt, bzw. gebündelt werden? 

15 Welche ursächlichen Zusammenhänge und Abhängigkeiten bestehen zwischen 

Organisationsentwicklung und Technologie- Entwicklung?


(z.B.: Einführungschritte und -stufen, Qualifizierungsbedarfe etc.) 

16 Welche Ressourcen (Personal-und sonstiger Aufwand) werden für die Entwicklung 

und Umsetzung der organisatorischen Maßnahmen benötigt? 

17 Wie beurteilen sie die „Wirtschaftlichkeit“ des Projekts? 

18 Welches sind die „kritischen Erfolgsfaktoren“ für die Durchführung des Projekts? 

19 Wie verankern Sie das Projekt in der Verwaltungsführung und den politischen 

Gremien? 

20 Wie verankern und entwickeln Sie das Projekt in den beteiligten Fachbereichen 

(Projekt begleitendes „Veränderungsmanagement“)? 

E Entscheidungsbedarfe erkennen: 

21 Welche Entscheidungen müssen (ggfs. in welcher Reihenfolge) herbeigeführt 


22 Wer entwickelt die Entscheidungsvorlage(-n)? 

23 Wer trifft die Entscheidung(-en)? 

F Projektorganisation planen: 

24 Welche Know-How-Träger werden für die Feinkonzeption gebraucht? 

25 Welche Know-How-Träger werden für die Entwicklung eines Stufenkonzepts 

zur Einführung gebraucht? 

26 Welche Know-How-Träger werden für den kontinuierlichen Verbesserungsprozess 

gebraucht? 

27 Sind die Projekt- Rollen und Aufgaben definiert, kommuniziert, verstanden und 

akzeptiert? 


Abbildung 16: Leitfragen zum Soll-Ist-Vergleich Organisation 

Die Fragen sind nummeriert. Fette Nummern markieren jene Fragen, deren Beantwor- 

tung im Rahmen des Soll- / Ist-Vergleichs zwingend erforderlich ist. 

Die Beantwortung der weiteren Fragen empfiehlt sich im Zuge der Grobkonzeption und 

bei der Entwicklung eines Stufenkonzepts für die Einführung des Soll-Modells. 

Entwickeln und dokumentieren Sie ein (grobes) Konzept mit allen zur Implementierung 

des Soll-Zustandes erforderlichen Maßnahmen. 

Priorisieren Sie die Maßnahmen nach dem bewährten A-B-C-Schema! 

„Schnüren“ Sie sinnvolle Maßnahmenpakete aus thematisch, d.h. in organisatorischer 

und funktionaler Hinsicht, zusammenhängenden Maßnahmen.


Stellen Sie sicher, dass jedes Maßnahmenpaket in sich abgeschlossen und vollständig 

ist und einen klar erkennbaren Nutzen stiftet. 

Bringen Sie die Maßnahmenpakete in eine zeitliche Abfolge („Einführungsstufen“)! 

Synchronisieren Sie die Stufen der Organisationsentwicklung mit den Einführungsstufen 

der technologischen Entwicklung! (siehe nächster Abschnitt: technologischer Soll-Ist- 

Vergleich) 

Die folgende Tabelle hilft Ihnen, alle Maßnahmenvorschläge zu dokumentieren und zu struktu- 

rieren: 

Maßnahmenplan Organisation 

Nr. Typ Maßnahme Prio Paket 

A Projektnutzen 

B Handlungsfeld 

C Handlungsbedarf 

D Projektvorschlag 

E Entscheidungen 

F Projektorganisation 

G Projektplanung 

Technologischer Soll-Ist-Vergleich 

Nr. 

Stufe 

Nr. 

Abbildung 17: Vorlage "Maßnahmenplan Organisation" 

Bemerkung 

Der technologische Soll-Ist-Vergleich beantwortet die Frage, welche Maßnahmen im Bereich 

der Informationstechnologie zu ergreifen sind, um das Soll-Modell zu implementieren. Dabei 

müssen in der Regel die prozessnahe IT-Infrastruktur, also alle Anwendungen, welche die 

Prozessdurchführung direkt unterstützen (z.B. „Fachanwendungen“) und IT-Komponenten mit 

Querschnittscharakter (E-Government Basisinfrastruktur, zum Beispiel Online Services, For- 

mulardienste, etc.) in den Vergleich mit einbezogen werden. Grundsätzlich sollte der techno- 

logische Soll-Ist-Vergleich seitens der Organisation und der Fachbereiche allerdings ohne die 

Unterscheidung in „prozessnahe“ und Querschnittskomponenten auskommen. Aus „fachlicher 

Sicht“ und aus „Prozess-Sicht“ ist es unerheblich, welche IT-Anwendung oder Komponente 

eine erforderliche Bearbeitungsfunktion bereitstellt, oder technisch ausgedrückt: „implemen- 

tiert“. Es fällt grundsätzlich in die Zuständigkeit der IT-Abteilung zu entscheiden, wie fachliche 

und prozessorganisatorische Anforderungen an IT erfüllt werden. Die Unterscheidung ist also 

eher der Tatsache geschuldet, dass kommunale IT eben in der Regel einerseits aus prozess- 

nahen „Office-“ und „Fachanwendungen“ und andererseits aus E-Government Anwendungen 

für die gesamte Verwaltung besteht. Die Unterscheidung soll also lediglich die Verständigung 

zwischen „Organisation“ und „Technik“ erleichtern. Der technologische Soll-Ist-Vergleich be-


steht aus einer Bestandsaufnahme und einer sogenannten „Lückenanalyse“ (GAP-Analyse 10 ) 

in drei Bereichen: 

Prozessfunktion 

Schnittstellen 

(E-Government)-Basiskomponenten 

Lückenanalyse der Prozessfunktionen 

Ziel der Analyse ist es, eine Übersicht über die „operativen Lücken“ in der IT- 

Prozessunterstützung zu erhalten und anschließend zu überlegen, wie diese Lücken geschlos- 

sen werden können. Als „Werkzeug“ zur Durchführung der Lückenanalyse dient die bereits im 

Abschnitt „Qualitätssicherung von Soll-Modellen“ vorgestellte „Prozessfunktionstabelle“. Die 

Tabelle wird zunächst dadurch fortgeschrieben, dass die bereits im Rahmen der „Qualitätssi- 

cherung“ identifizierten maschinellen und teilmaschinellen Prozessaktivitäten und Tätigkeiten 

auf die bestehende IT-Unterstützung für den Prozess, d.h. auf die Gruppe der prozessnahen 

IT-Anwendungen referenziert werden, um operative IT-Lücken sichtbar zu machen. 11 


Erstellen Sie eine Liste aller IT-Anwendungen, die von den Prozessbearbeitern („Rollen“) 

im Ist-Zustand verwendet werden. 

Nehmen Sie zusätzlich die „Checkliste Prozessoptimierung“ zur Hand (siehe Abbildung 

7), sie enthält sehr viele Hinweise auf typische Schwachstellen und Optimierungspoten- 

ziale, die nicht immer, auch für IT erfahrene Sachbearbeiter „auf der Hand liegen“. 

Notieren Sie zu jeder IT-Bearbeitungsfunktion in der Spalte L, ob diese Funktion von ei- 

ner der in der Liste aktueller Anwendungen geführten Anwendungen angeboten wird 

(z.B. durch ein „X“ oder ein „Ja“ in Spalte M). 

Dabei ist es hilfreich sich zu vergegenwärtigen, ob es sich bei einer bestimmten funktio- 

nalen Anforderung um eine fachliche Funktion (z.B.: „Berechnung des Wohngeldan- 

spruchs“) oder um eine allgemeine „office“ Funktion (z. B.: „Bearbeitung von Textvorla- 

gen“), eine Prozessautomationsfunktion (z.B.: „Dokument weiterleiten“), oder eine Servi- 

ce-Schnittstelle (z.B.: „Einwohnermeldedaten abfragen“) handelt. 

Notieren Sie in der Spalte O den korrekten und vollständigen Namen der Anwendung und 

ihren Versionsstand. 

Notieren Sie in der Spalte P den Namen des Herstellers oder Anbieters. 

10 GAP: engl. für „Lücke“. Der Begriff „GAP-Analyse“ bezeichnet eine universelle betriebswirtschaftliche Methode zur 

Identifikation von strategischen oder operativen Lücken und zur Ableitung von Handlungsbedarfen in unterschiedlichen 

Projektkontexten. 

11 Die Prozessfunktionstabelle ist ebenso ein sehr geeignetes Hilfsmittel, um Anforderungskonzepte für die Auswahl und 

Beschaffung von Fachanwendungen zu erstellen oder Fachanwendungen im Hinblick auf ihre „Prozessproduktivität“ 

und Unterstützungsqualität zu beurteilen.


Beurteilen Sie in der Spalte Q die Qualität der Anwendung bzw. notieren Sie möglicher- 

weise ergänzende Anforderungen und Merkmale, die im Soll-Zustand erfüllt werden sol- 

len. 

Funktionen, die keiner bestehenden Anwendung zugeordnet werden können stellen „ope- 

rative Lücken“ dar, die geschlossen werden müssen, um eine effiziente Prozessdurchfüh- 

rung zu gewähren. 

Funktionen, die zwar „im Prinzip“ vorhanden sind, aber qualitativ verbessert werden kön- 

nen, stellen „qualitative Lücken“ dar, die ebenfalls geschlossen werden müssen. 

Diskutieren Sie die identifizierten operativen und qualitativen Lücken mit den jeweils zu- 

ständigen Anwendungs- bzw. Verfahrensbetreuern, um Ideen und Vorschläge für die Be- 

hebung der Lücken zu sammeln. Diskutieren Sie dabei auch Umsetzungsalternativen. 

Erstellen Sie eine Liste der Lösungsvorschläge und Alternativen und bewerten Sie ggfs. al- 

ternative Lösungsvorschläge im Hinblick auf ihre Verbesserungsqualität für den Prozess 

und ihre Machbarkeit, bzw. ihren Umsetzungsaufwand. Eine geeignete Methode zur Dar- 

stellung der Bewertungsergebnisse ist die Portfoliomethode (siehe folgende Abbildung). 

Starke 

Verbesserung 

geringe 

Verbesserung 

B A 

Abbildung 18: Portfoliomethode zur Bewertung von Lösungsalternativen 

Lückenanalyse der Prozess- und Anwendungsschnittstellen 

Ein nach der FaMoS-Methode erstelltes Soll-Modell enthält eine sogenannte „Prozesslandkar- 

te“ vom Typ „Prozesskollaborationsdiagramm“. Dieses Diagramm gibt Auskunft über alle 

Schnittstellen des Soll-Modells zu internen und externen Prozessbeteiligten. Ziel der Lücken- 

analyse ist es festzustellen, ob die im „Ist“ vorhandenen Schnittstellen den Anforderungen des 

Soll-Modells entsprechen. Die folgende Abbildung 19 zeigt eine solche Prozesslandkarte. Sie 

stellt den Geschäftsprozess „Bearbeitung von Verkehrsordnungswidrigkeiten“ dar. 

Dabei wurde zu jeder Schwimmbahn links die Rolle des Bearbeiters und rechts die vom Bear- 

beiter verwendete „führende“ IT-Anwendung eingetragen. Die daten- und dokumentenbasier- 

ten Prozessschnittstellen wurden durchnummeriert, um ihre systematische Erfassung und 

Beschreibung 12 zu erleichtern. Die Prozesslandkarte zeigt auf, zwischen welchen Akteuren 

und zwischen welchen IT-Anwendungen Schnittstellen bestehen. 

12 Zur Methodik der fachlichen Beschreibung von Schnittstellen siehe Abschnitt 2.5.6 „Fachkonzept Schnittstelle“. 

C 

hoher 

Aufwand 

B 

geringer 

Aufwand


Abbildung 19: Schnittstellenanalyse mit der Prozesslandkarte 

Verkehrs- 

Überwachung 

durchführen 

TP1 

Verstoßdaten 

aufbereiten 

TP2 

(Rücklauf) 

Bußgelder 

bearbeiten 

TP6 

Forderungen 

durchsetzen 

TP7 

Vk-Qwi 

Bescheide und 

Anhörungen 

versenden 

TP3 

(Rücklauf) 

Verwarnungen 

bearbeiten 

TP5 

Postalischen 

Rücklauf 

VK-Owi 

digitalisieren 

TP4 

Bescheide und 

Anhörungen 

bearbeiten 

Strafzettel 

bearbeiten 

Zahlung 

annehmen 

Halterdaten 

bereitstellen 

Voreinträge 

bereitstellen 

Adressdaten 

bereitstellen 

Halter-/ 

Fahrer- 

Ermitteln 

Adressdaten 

bereitstellen 

XOR 

€ 

Zahlung 

annehmen 

XOR 

€ 

Zahlung 

annehmen 

Bescheide und 

Anhörungen 

bearbeiten 

€ 

X 

X 

Halter-/ 

Fahrer- 

Ermitteln 

X 

Halter-/ 

Fahrer- 

Ermitteln 

X 

Betroffene 

Ermitteln 

X 

Halterdaten 

bereitstellen 

Voreinträge 

bereitstellen 

Adressdaten 

bereitstellen 

X 

Halterdaten 

bereitstellen 

Voreinträge 

bereitstellen 

Adressdaten 

bereitstellen 

X X 

Ermittlungs- 

Akten 

Bereitstellen 

X 

XOR 

XOR 

Papier- 

Anzeige 

X 

Ermittlungs- 

Unterlagen 

bereitstellen 

Ermittlungs- 

Unterlagen 

bereitstellen 

StaAw 

VK-Gericht 

EWO 

Meldestelle 

KBA 

SB- 

Kasse 

Betroffene 

IT-DL / 

SSC 

SB- 

BG-Stelle 

SVD 

VKÜ 

VK- 

Polizei 

SVD- 

Ermittler 

X XOR X XOR 

XOR 

X 

X 

X X 

Soll- 

Stellung 

X 

X 

X 

X 

X 

X X X 

X 

X 

X 

X 

X X 

X 

X 

X 

€ 

€ 

€ 


Stellung 

X 

1 

2 

3 

4 

8 

6 

7 

5 9 

10 11 

12 

15 

13 

14 

17 

18 

19 

20 21 

22 

16 

Verkehrs- 

Überwachung 

durchführen 

TP1 

Verkehrs- 

Überwachung 

durchführen 

TP1 

Verstoßdaten 

aufbereiten 

TP2 

Verstoßdaten 

aufbereiten 

TP2 

(Rücklauf) 

Bußgelder 

bearbeiten 

TP6 

(Rücklauf) 

Bußgelder 

bearbeiten 

TP6 

Forderungen 

durchsetzen 

TP7 

Forderungen 

durchsetzen 

TP7 

Vk-Qwi 

Bescheide und 

Anhörungen 


TP3 

Vk-Qwi 

Bescheide und 

Anhörungen 


TP3 

(Rücklauf) 

Verwarnungen 

bearbeiten 

TP5 

(Rücklauf) 

Verwarnungen 

bearbeiten 

TP5 

Postalischen 

Rücklauf 

VK-Owi 


TP4 

Postalischen 

Rücklauf 

VK-Owi 


TP4 

Bescheide und 

Anhörungen 

bearbeiten 

Strafzettel 

bearbeiten 

Zahlung 

annehmen 

Halterdaten 

bereitstellen 

Voreinträge 

bereitstellen 

Adressdaten 

bereitstellen 

Halter-/ 

Fahrer- 

Ermitteln 

Adressdaten 

bereitstellen 

XOR 

€ 

Zahlung 

annehmen 

XOR 

€ 

Zahlung 

annehmen 

Bescheide und 

Anhörungen 

bearbeiten 

€ 

X 

X 

Halter-/ 

Fahrer- 

Ermitteln 

X 

Halter-/ 

Fahrer- 

Ermitteln 

X 

Betroffene 

Ermitteln 

X 

Halterdaten 

bereitstellen 

Voreinträge 

bereitstellen 

Adressdaten 

bereitstellen 

X 

Halterdaten 

bereitstellen 

Voreinträge 

bereitstellen 

Adressdaten 

bereitstellen 

X X 

Ermittlungs- 

Akten 

Bereitstellen 

X 

XOR 

XOR 

Papier- 

Anzeige 

X 

Ermittlungs- 

Unterlagen 

bereitstellen 

Ermittlungs- 

Unterlagen 

bereitstellen 

StaAw 

VK-Gericht 

EWO 

Meldestelle 

KBA 

SB- 

Kasse 

Betroffene 

IT-DL / 

SSC 

SB- 

BG-Stelle 

SVD 

VKÜ 

VK- 

Polizei 

SVD- 

Ermittler 

X XOR X XOR 

XOR 

X 

X 

X X 


Stellung 

X 

X 

X 

X 

X 

X X X 

X 

X 

X 

X 

X X 

X 

X 

X 

€ 

€ 

€ 


Stellung 

X 

1 

2 

3 

4 

8 

6 

7 

5 9 

10 11 

12 

15 

13 

14 

17 

18 

19 

20 21 

22 

16 

EWMR 

VZR 

HKR 

EGVP 

E-Postbrief 

E-Postbrief 

Mobile Erf. 

Bilddaten. 

Intranet. 

E-Postbrief 

SC-Owi 

Scan/OCR 

Matching


Im Rahmen der technologischen Lückenanalyse ist nun zu klären, welche der Schnittstellen im 

Ist durch „Technik“ unterstützt werden kann, um möglichst alle im „Ist“ vorhandenen Medien- 

brüche zu beseitigen. 

Vorlage Soll-Ist-Vergleich Schnittstellen 


A B C D E F G H I J K L M N 

Bezeichnung Nr Sender Empfänger Interaktionstyp Informationstyp it-Unterstützung Empfehlung 

Name/Funktion Schnittstelle Akteur/Rolle 


it-Anwendung 

Akteur/Rolle 

it-Anwendung 

unilateral 

bilateral 

Abbildung 20: Vorlage Soll-Ist-Vergleich Schnittstellen 

Eingang 

Ausgang 

Daten 

E-Dokumente 

P-Dokumente 

IST SOLL Maßnahme 

Ergänzen Sie, falls erforderlich ihre „Prozesslandkarte“ um Pools für alle am Prozess beteiligten 

Akteure und um entsprechende Schwimmbahnen für die Rollen. 13 

Fügen Sie die entsprechenden Rollensymbole und IT-Anwendungssymbole ein. 

Kontrollieren Sie, ob die Prozesslandkarte alle Prozessschnittstellen an denen Daten 

oder Dokumente ausgetauscht werden enthält. 

Unterscheiden Sie dabei Schnittstellen, an denen (elektronische) Daten ausgetauscht 

werden von den Schnittstellen an denen papiergebundene Dokumente (z. B. Post- Ein- 

gang / -Ausgang) oder elektronische Dokumente (z.B. E-Mail, Fax, Online Portal) aus- 

getauscht werden. 

Nummerieren Sie die Schnittstellen durch und erstellen Sie eine Liste aller Schnittstellen 

(siehe Abbildung 19). 

Tragen Sie eine (möglichst funktionsorientierte) Bezeichnung für die Schnittstelle in 

Spalte A der Vorlage ein. 

Tragen Sie die Schnittstellennummer aus der Prozesslandkarte in Spalte B ein. 

Tragen Sie Angaben zum Sender bzw. Empfänger der Informationsobjekte aus der Pro- 

zesslandkarte in die Spalten C und D ein. 

13 Erläuterungen zur Methodik von FaMoS (Fachmodellierungsstandard) finden Sie im Modellierungshandbuch 

FaMoS 2.0; vgl. auch Fußnote 4.


Kreuzen Sie den Interaktionstyp 14 der Schnittstelle in den Spalten E oder F an. 

Charakterisieren Sie durch entsprechende Kreuze in den Spalten G-K den Typ des Infor- 

mationsobjekts (Datenobjekt, E-Dokument oder Papierdokument) und verwenden Sie bei 

Bedarf (bilaterale Interaktion) für „Eingang“ und „Ausgang“ getrennte Zeilen, damit Me- 

dienbrüche zwischen Eingangs- und Ausgangskanal „sichtbar“ werden. 

Tragen Sie nun in Spalte L ein, welche Medien, IT-Services und Anwendungen im Ist- 

Zustand die Interaktion unterstützen. Falls an einer Prozessschnittstelle mehrere Medien 

genutzt werden, sollten Sie für jedes Medium eine separate Zeile nutzen. 

Tragen Sie nun in Spalte M den Soll-Zustand ein, falls der Ist-Zustand nicht optimal ges- 

taltet ist. 

Tragen Sie in Spalte N ihre Maßnahmenvorschläge zur Schließung „operativer Lücken“ 

bei Schnittstellen ein. Diskutieren und bewerten Sie die Lösungsvorschläge mit ihren IT- 

Experten und Fachexperten. 

Priorisieren Sie bei Bedarf alternative Lösungsvorschläge mit Hilfe der in Abbildung 18 

dargestellten Portfoliomethode. 

Lückenanalyse der E-Government Basiskomponenten 

Grundlage für die Lückenanalyse bei den IT-Querschnittsfunktionen und Basiskomponenten ist 

die bereits im Rahmen der Qualitätssicherung des Soll-Modells erstellte grobe Skizze der Pro- 

zess spezifischen IT-Anwendungsarchitektur. Nun geht es schlicht darum festzustellen, ob die 

dort skizzierten Soll-Funktionen und Dienstekomponenten innerhalb der lokalen E-Government 

IT-Infrastruktur bereitgestellt werden oder nicht. Die folgende Abbildung 21 zeigt eine schema- 

tische Übersicht der Dienste, Funktionen und Komponenten, die in einer vollständig entwickel- 

ten, SAGA konformen und Service orientierten E-Government IT-Architektur enthalten sein 

sollten. 

Sie detailliert und ergänzt die in Abbildung 14 gezeigte grobe Skizze zur Anwendungsarchitek- 

tur für das Soll-Modell. Anhand der von Ihnen erstellten Skizze zur Prozess spezifischen An- 

wendungsarchitektur und der in Abbildung 21 dargestellten Gesamtübersicht zur E- 

Government Dienstearchitektur können Sie nun operative und strategische Lücken „ihrer“ E- 

Government IT identifizieren: 

Die „operative Lücke“ zur Umsetzung des ausgewählten Soll-Prozesses ergibt sich aus 

dem Soll-Ist-Vergleich zwischen Prozess spezifischer Soll-Architektur und der vorhande- 

nen Ist-Infrastruktur 

Die „strategische Lücke“ ergibt sich aus dem Soll-Ist Vergleich der vorhandenen Ist- 

Infrastruktur mit der Gesamtübersicht der E-Government Dienstearchitektur. 

14 „Unilateral“ = Informationsobjekt(-e) fließen nur in eine Richtung; „Bilateral“: Informationsobjekte fließen in beide 

Richtungen, möglicherweise muss hier zwischen verschiedenen „Nutzungsszenarien“ unterschieden werden. Ver- 

wenden Sie in diesem Fall je Nutzungsszenario eine separate Zeile und Benennen Sie das Nutzungsszenario in Spalte 

A entsprechend.


Vorsprache 

Telefon 

DOC 

Brief 

Logistik-Service 

Bündeln 

Zustellen 

Scan-Service 

Registrieren 

Digitalisieren 

Indizieren 

Extrahieren 

Input Mgmt. 

Zuordnen 

Aufklären 

Weiterleiten 

E-Mail 

Online 

Zugang 

(Kunde) 

Abbildung 21: Dienste und Funktionen in der E-Government IT-Architektur 

Dokumentieren und diskutieren Sie die eventuell bei diesem Soll-Ist-Vergleich identifizierten 

operativen und strategischen Lücken mit ihren IT-Experten. Entscheidungen und Maßnahmen 

zur Schließung operativer Lücken sollten immer auch im Hinblick auf die Gesamtarchitektur, 

die letztlich eine Infrastruktur für alle kommunalen Prozesse bereitstellen muss, getroffen bzw. 

ergriffen werden. Dies bedeutet einerseits, dass die Schließung „operativer Lücken“ als Chan- 

ce begriffen werden sollte, einen weiteren Schritt zum Aufbau der Gesamtarchitektur zu tun 

und andererseits, dass ein enger Zusammenhang zwischen der operativen und der strategi- 

schen Perspektive besteht, in dem grundsätzlich strategische IT-Entscheidungen ein höheres 

Gewicht als operative IT-Entscheidungen haben sollten. Diesem Zusammenhang muss im nun 

folgenden Schritt, der Entwicklung eines Stufenkonzeptes zur Umsetzung des Soll-Prozess- 

Konzepts, Rechnung getragen werden. 

Extranet 

Zugang 

(Intermediär) 

In dem folgenden Fragebogen haben wir nochmals alle wichtigen „Leitfragen“ zur Durchfüh- 

rung des technologischen Soll-Ist-Vergleichs zusammengestellt. Bitte berücksichtigen Sie 

dabei: es geht nicht um die Klärung technologischer Detailfragen, sondern „lediglich“ darum, 

die aus fachlicher und aus prozessualer Sicht für eine optimale Prozessdurchführung fehlen- 

den IT-Services zu benennen und einer an Umsetzungsstufen orientierten Projektplanung 

„zugänglich“ zu machen. Der Fragebogen ist in folgende Abschnitte gegliedert: 

A Analyse Soll-Prozess-Modell 

Intranet 

Zugang 

(Mitarbeiter) 

B Fortschreibung Prozessfunktionstabelle 

C Gap-Analyse Prozess- Funktionen und Automation 

D Soll-Ist-Vergleich Prozess Schnittstellen 

E Soll-Ist-Vergleich Anwendungsarchitektur 

Mobiler 

Zugang 

(Mitarbeiter) 

(Prozess-) Portal (Composite Application Plattform, Desktop/Taskflow) 

Vorgangssteuerung (Workflowmanagement System/bus) 

Servicesteuerung (Middleware, Servicemanagement System/bus ) 

Sonst. Verz.-Dienste 

Online Brief 

E-Mail 

Virtuelle Poststelle 

E-Signatur 

Servicebibliothek (Service Repository) 

E-Government Services 

Identity Management 

E-Payment Systems 

E-Shop-Systems 

Customer Management 

Knowledge Management 

Content Management 

Formular Management 

Document Management 

Hardware- und Netzinfrastruktur 

HKR-System 

EWO-Melde-Register 

sonstige Fachverfahren 

Telefon 

Fachservices 

Sonstige Web-Services 

Office 

Anwendungen 

E-Mail 

Online Brief 

Brief 

E-DOC DOC 

Versand-Mgmt 

Nachweis 

erbringen 

. 

zustellen 

Versenden 

Print-Mgmt 

Weiterleiten 

Registrieren 

Indizieren 

konvertieren 

Vorsprache 

Freimachen 

. 

Couvertieren 

Drucken 

Output-Mgmt 

DOC


Leitfragen zum Soll- Ist- Vergleich IT 

Diskutieren Sie die folgenden Fragen mit den Fach-, Prozess- und IT-Experten ihrer Kommune. 

Schreiben Sie dazu zunächst die Prozessfunktionstabelle im Bereich „Ist-Zustand“(Spalten 

L-Q) fort. 

Erstellen Sie zusätzlich eine Liste mit einer Grobbeschreibung und Bewertung aller Prozessschnittstellen. 

Erstellen Sie eine Grobskizze der Soll-Anwendungsarchitektur und führen 

Sie den Soll-Ist-Vergleich dazu durch. 

A Kritische Analyse bzw. Auswertung des Soll-Prozess-Modells: 

1 

Ist das Soll-Prozess-Modell bereits so detailliert, dass alle für die Durchführung 

der Prozessaktivitäten erforderlichen IT-Funktionen bzw. IT-Services „bekannt 

und benannt“ sind? 

2 Aus welchen IT-Komponenten bzw. IT-Anwendungen besteht das Soll- 

Anwendungssystem? 

3 Welche Prozessaktivitäten / Teilprozesse werden im IST von welcher Anwendung 

unterstützt? 

4 Aus welchen IT-Komponenten bzw. IT-Anwendungen besteht das IST- 

Anwendungssystem? 

5 Welche funktionalen Lücken bzw. IT-Servicelücken ergeben sich aus dem Soll- 

Ist-Vergleich? 

B Fortschreibung der Prozessfunktionstabelle: 

6 (Falls Sie Leitfrage 1 mit „Nein“ beantworten müssen) 

Welche Prozessaktivitäten müssen weiter zergliedert werden, damit die benötigten 

IT-Funktionen „sichtbar“ werden? 

Zergliedern Sie gegebenenfalls diese Aktivitäten in manuell und maschinell 

ausführbare „Tätigkeiten“ („Feinmodell“/Funktionsmodell) 

Erstellen Sie eine Prozessfunktionstabelle und tragen Sie zu allen Aktivitäten 

die jeweils geforderten IT-Bearbeitungsfunktionen ein 15 

(siehe Anlage: „Prozessfunktionstabelle“) 

7 Welche Fachfunktionen werden jeweils durch die Aktivitäten benötigt? 

8 Welche Office-Funktionen werden jeweils durch die Aktivitäten benötigt? 

9 Welche Prozesssteuerungsfunktionen werden jeweils durch die Aktivitäten benötigt? 

10 Welche Dokumentenmanagementfunktionen werden jeweils benötigt? 

15 Siehe Abbildung 13


11 Welche Datenbereitstellungs- und Bearbeitungsfunktionen werden jeweils benötigt? 

12 Welche Schnittstellen und Dienste zur „Kommunikation“ von Daten oder Dokumenten 

werden jeweils benötigt? 

13 Welche Dienste zur Abwicklung von Zahlungsvorgängen werden jeweils benötigt? 

14 Welche Vorlagen, Inhalte, Wissensquellen und sonstigen elektronischen Hilfsmittel, 

Dienste oder Anwendungen werden benötigt? 

C „Gap-Analyse“ der Prozessfunktionen und des Prozessautomationsgrads: 

15 Welche Anwendungen unterstützen aktuell den Prozess und sind deshalb im 

Rahmen der Gap-Analyse sind zu untersuchen? 

16 Welche Prozessfunktionen werden von welcher Anwendung bereitgestellt? 

17 Welche Prozessfunktionen werden nicht bereitgestellt? 

18 Welche IT-Anwendungen, Module oder E-Government Dienste und Komponenten 

können die „operativen Lücken“ bei nicht abgedeckten Funktionen schließen? 

D Soll- Ist- Vergleich Schnittstellen: 

19 Welche Schnittstellen verlangt das Soll-Konzept zwischen dem internen IT- 

Anwendungssystem und externen IT-Anwendungen? 

20 Welche Merkmale haben die vorhandenen Schnittstellen? 

(siehe Vorlage: Soll-Ist-Vergleich Schnittstellen) 

21 Welche Medienbrüche bestehen bei Schnittstellen? 

22 Welche Automationspotenziale bestehen bei Schnittstellen? 

E Soll-Ist-Vergleich Anwendungsarchitektur: 

23 Welche IT-Anwendungen oder Funktionsmodule und Basisdienste gehören zum 

für den Soll-Prozess erforderlichen Zielsystem? 

24 Welche IT-Anwendungen oder Funktionsmodule und Basisdienste sind aktuell 

nicht vorhanden und müssen beschafft oder entwickelt werden? (vergl. Frage 18) 

25 Können vorhandene Anwendungen (mit operativen Lücken) technisch in das Ziel- 

system integriert werden? 

26 Welche Anwendungen müssen aufgrund ihrer als „kritisch“ bewerteten technolo- 

gischen Interoperabilität zum Zielsystem abgelöst werden? 

Abbildung 22: Leitfragen zum Soll-Ist-Vergleich IT


Die folgende Tabelle hilft Ihnen alle Maßnahmenvorschläge zu dokumentieren und zu struktu- 

rieren: 

Maßnahmenplan Technologie 

Nr Typ Maßnahme Prio Paket 

A Prozess- 

Bearbeitungsfunktionen 

B Schnittstellen 

C Basiskomponenten 

D Online Dienste 

E Entscheidungen 

F Projektorganisation 

G Projektplanung 

Nr. 

Stufe 

Nr. 

Abbildung 23 Vorlage "Maßnahmenplan Technologie" 

2.4 Stufenkonzept Umsetzung 

Bemerkung 

Im Rahmen des Soll-Ist-Vergleichs wurden systematisch alle Potenziale, Möglichkeiten und 

Maßnahmen zur Optimierung des Ist-Prozesses identifiziert und dokumentiert. Da in der Praxis 

nur selten alle Optimierungsansätze zu einem Geschäftsprozess in einem Zuge umgesetzt 

werden können, müssen die Optimierungsansätze und Maßnahmen im Rahmen einer Stufen- 

konzeption sinnvoll gebündelt und in eine logische und zeitliche Abfolge gebracht werden. Für 

die Gestaltung des Stufenkonzepts bieten sich zwei grundsätzliche Alternativen an, die in der 

folgenden Abbildung 24 schematisch dargestellt sind. 

Das Vorgehen in „Variante A“ ist konsequent auf das Endergebnis des Projekts ausge- 

richtet. In jeder Umsetzungsstufe werden die Grundlagen und Voraussetzungen für die 

nächste Umsetzungsstufe geschaffen, bis das geplante Gesamtergebnis erreicht wurde. 

Diese „klassische“ Vorgehensweise in der Projektplanung „optimiert“ zwar den Projekt- 

aufwand, hat aber den Nachteil, dass erst mit dem Projektabschluss eine funktionsfähige 

Lösung zur Verfügung steht. Bei Projekten, die über einen längeren Zeitraum geplant 

wurden, birgt dieser Planungsansatz aber gewisse Risiken. Jeder Praktiker weiss, dass 

sich die „Rahmenbedingungen“ wie etwa verfügbare Finanzmittel oder Projektziele im 

Zeitablauf ändern können. Dies führt nicht selten zum Abbruch ehrgeiziger Verände- 

rungsprojekte, mit dem Ergebnis dass statt einer „Pyramide“ (geplantes Projektergebnis)


ein „Hubschrauberlandeplatz“ (erreichtes Ergebnis) entsteht, den niemand wollte und 

den keiner gebrauchen kann. 

Variante A: „klassische“ Vorgehensweise 

Variante B: „modulare“ Vorgehensweise 

Abbildung 24: Alternative Stufenkonzeptionen 16 

Die „modulare“ Vorgehensweise (Variante B) hat demgegenüber den Vorteil, dass mit 

jeder einzelnen Umsetzungsstufe bereits ein „gebrauchsfertiges Teilergebnis“ (kleine Py- 

ramide) entsteht, welches mit jeder weiteren Umsetzungsstufe erweitert wird, bis das Pro- 

jektziel erreicht wird. Diese Vorgehensweise schließt also das Risiko einer „Projektruine“ 

weitgehend aus. 

Übersetzt man die Vorgehensweise aus Variante B in die Sprache und Objektwelt des kom- 

munalen E-Government ergibt sich daraus ein relativ allgemein gültiger Entwicklungspfad für 

Prozessoptimierungs- und Organisationsentwicklungsprojekte, die auf dem Einsatz der E- 

Government Technologien beruhen. Dieser Entwicklungspfad ist in der folgenden Abbildung 

25 dargestellt. Er kann als „roter Faden“ zur Entwicklung ihres Umsetzungsstufenkonzepts 

dienen. 

1 

1 

2 

16 Darstellung in Anlehnung an Philipp Meyerbröcker: Die kleine Pyramide. In: Projektmagazin. Heft 10/2010. 

2 

3 

3


2. Stufe: Plus Elektronische Vorgangsbearbeitung 

Dokumentenmanagement / Archivierung 

E-Vorgangsbearbeitung, E – Workflows, 

Scannen / Digitalisieren, Outputmanagement 

1. Stufe: Verwaltungsprozessoptimierung 

Optimierter Einsatz Büroautomation und Fachverfahren, 

Entbürokratisierung, Schnittstellenminimierung, 

Lauf- und Liegezeitenverkürzung, 

Personalbemessung 

Abbildung 25:Leitfaden und Entwicklungsstufen zur E-Government-Umsetzung 

Die folgenden Leitfragen (siehe Abbildung 26) helfen bei der Erstellung und Qualitätssicherung 

ihres Stufenkonzepts. Die Fragen beziehen sich auf die Plausibilität und Konsistenz der Um- 

setzungsstufen. In Abbildung 27 finden Sie unseren Vorschlag zur Zusammenführung der im 

Rahmen des Soll-Ist-Vergleichs identifizierten, organisatorischen und technologischen Maß- 

nahmenpakete in einer tabellarischen Darstellung ihres Stufenkonzepts. Sie sollten das Stufen- 

konzept unbedingt um eine Planung der Projekt begleitenden Maßnahmen im Bereich des Ver- 

änderungsmanagements ergänzen. Wie Sie das machen, erfahren Sie im Kapitel „Hinweise 

zum Veränderungsmanagement“ am Ende unseres Leitfadens. 

Leitfragen zum Stufenkonzept 

Überprüfen Sie anhand der folgenden Leitfragen die „Plausibiliät“ ihres Stufenkonzepts. 

Diskutieren Sie die folgenden Fragen mit den Fach-, Prozess- und IT-Experten ihrer Kommune. 

A Plausbilität der Umsetzungsstufen 

4. Stufe: Neues Kommunales Produktionsmodell 

Front- und Backoffice-Organisation / Netzwerkverwaltung 

Shared Services 

auf der Basis standardisierter Verwaltungsprozesse 

3. Stufe: Plus E-Government 

Modellierung von E-Governmentfunktionen in den Prozessen, 

Verschmelzung digitalisierter Prozesse mit den manuellen, 

Verlagerung von Arbeiten auf die Nutzer, 

Bildung Nutzergruppen, SB-Services durch eID 

1 Ist das Stufenkonzept nach dem Prinzip der „kleinen Pyramiden“ aufgebaut, 

d.h.: entsteht nach jeder Umsetzungsstufe eine in sich geschlossene und praktisch 

einsetzbare (Teil-)Lösung? 

2 Welche Auswirkungen hat die Umsetzungsstufe auf vor- und/oder nachgelagerte 

Prozesse bzw. Teilprozesse? 

3 Entstehen zu irgendeinem Zeitpunkt in der Umsetzung der Stufen zusätzliche 

Medien- oder Systembrüche im Prozessablauf?


4 Können Sie den qualitativen Nutzen der Teillösungsstufen beschreiben? 

5 Können Sie den quantitativen Nutzen (zum Beispiel Prozesskostenersparnisse) 

auf jeder Teillösungsstufe beziffern? 

B Konsistenz der Umsetzungsstufen 

6 Welche technische Maßnahme gehört zur Umsetzungsstufe? 

7 Welche organisatorische Maßnahme gehört zur Umsetzungsstufe? 

8 Welche personelle Maßnahme gehört zur Umsetzungsstufe? 

9 Wie soll die Einführung der Umsetzungsstufe erfolgen? Welche Maßnahmen im 

Bereich des Veränderungsmanagement sind erforderlich? 

Name / Inalt 

Umsetzungsstufe 

Ergebnis 

Nutzen 

Organisation 

1. 

2. 

3. 

Technik 

1. 

2. 

3. 

Veränderungsmanagement 

Abbildung 26: Leitfragen zur Entwicklung des Stufenkonzepts 

Vorlage Planung Stufenkonzept 


Stufe 1 Stufe 2 Stufe 3 Stufe X 

Maßnahmenpakete 

Abbildung 27: Vorlage zur Darstellung des Stufenkonzepts 

2.5 Fachliche Feinkonzeption 

Die folgende Themenliste zur fachlichen Feinkonzeption umfasst praktisch relevante Aufga- 

benstellungen. Sie erhebt keinen Anspruch auf Vollständigkeit. Die ausgewählten Themen 

entsprechen einer von den Projektteilnehmern selbst vorgenommenen Priorisierung. Die 

Themenauswahl deckt aber nichtsdestoweniger den kompletten Zyklus eines „typischen“ E- 

Government Prozesses ab. Dies „garantiert“, dass die im Folgenden behandelten Themen und 

Konzeptionsaufgaben in vielen Praxisprojekten wieder auftauchen werden. 

Wie bereits in der Einführung zum Praxisleitfaden dargestellt, liegt der Schwerpunkt der fachli- 

chen Feinkonzeption darin, relevante Anforderungen an die Prozess unterstützende IT aus


fachlicher Sicht und in fachlicher Sprache zu formulieren, damit IT-Fachleute auf dieser Grund- 

lage Lösungsvorschläge und Alternativen entwickeln können, ohne ihrerseits erneut in die Be- 

standsaufnahme bzw. Sollkonzeption „einsteigen“ zu müssen. Der Leitfaden zur Feinkonzepti- 

on wendet sich also an Organisatoren und Prozessexperten der Kommune und möchte diesen 

bei der Bestimmung ihrer Anforderungen helfen. 

2.5.1 Einführung von Fachanwendungen 

Wie eine empirische Untersuchung der b.i.t.consult GmbH ergab 17 , existieren, trotz des an- 

scheinend umfassenden IT-Einsatzes in der kommunalen Verwaltung immer noch eine ganze 

Reihe von Kernprozessen, die heute nur ansatzweise eine IT-Unterstützung erfahren. Außer- 

dem entsprechen nicht wenige kommunale Fachanwendungen nicht mehr dem heutigen Stand 

der Technik, sodass die Auswahl und Einführung einer Fachanwendung ein in der kommunalen 

Praxis immer noch sehr relevantes Thema ist. Die Erfahrung zeigt, dass dabei neben den „rein 

fachlichen“ Funktionen zunehmend Anforderungen und Aspekte zur Prozessautomation 

(„Workflowmanagement“), der E-Aktenführung und der Integrationsfähigkeit von Fachanwen- 

dungen in komplexe E-Government Service-Architekturen eine entscheidende Rolle spielen. 

Unabhängig davon, ob die gesuchte Anwendung als autarke „stand alone“ Lösung oder als 

integrierte Anwendung in einer E-Government Dienstearchitektur betrieben werden soll, emp- 

fiehlt es sich zunächst einmal ein weitgehend „technikfreies“ fachliches Anforderungskonzept 

auf der Grundlage einer soliden Prozessanforderungsanalyse zu erstellen. 

Das Hilfsmittel zur Ableitung fachlicher und prozessualer Anforderungen aus Prozessmodellen 

haben wir bereits kennen gelernt: die Prozessfunktionstabelle (siehe Abbildung 13). Mit ihrer 

Hilfe können fachliche und funktionale Anforderungen an IT-Anwendungen direkt aus dem Pro- 

zessmodell abgeleitet und umfassend dokumentiert werden (Spalten A-L, N und G). Wie die 

Prozessfunktionstabelle angewendet werden soll, wurde bereits im gleichnamigen Abschnitt 

erläutert. 

2.5.2 Fachkonzept Web-Frontend 

Online Services stellen eine ganz zentrale Möglichkeit dar, kommunale Geschäftsprozesse um 

neue, kundenorientierte Angebote zu erweitern und zugleich die Abläufe in der Verwaltung zu 

optimieren bzw. teilweise oder vollständig zu automatisieren. Grundsätzlich können kundensei- 

tige Online-Dienste der Verwaltung nach fünf Kategorien bzw. Entwicklungsstufen eingeord- 

net 18 werden: 

17 Siehe: „Studie Effizientes E-Government“, Köln/Seeheim 2011; als Download nach vorheriger Registrierung verfügbar 

unter: http://www.bitconsult.de/publikationen.html#content 

18 Siehe: Cap Gemini, „smarter, faster, better, the 8th European E-Government Benchmark”; 

http://ec.europa.eu/information_society/eeurope/i2010/docs/benchmarking/egov_benchmark_2009.pdf


1 Informationsangebote 

2 Einseitige Interaktionen 

(z.B. Downloads) 

3 Zweiseitige Interaktionen 

(z.B.: Terminvereinbarungen, Austausch e-Dokumente) 

4 Online Transaktionen 

(z.B.: sichere Online-Abwicklung und Bezahlung von Verwaltungsvorgängen, etwa einer 

Online-Meldeauskunft) 

5 Kundenspezifische, proaktive und automatisierte Online-Transaktionen 

(z.B.: regelmäßige Erteilung von Online Massenauskünften für registrierte „Heavy User“) 

Abbildung 28: Klassifizierung angebotsorientierter Online-Dienste 

In der Regel müssen solche Online-Dienste im Web-Frontend der Verwaltung allerdings völlig 

neu entwickelt werden, sie können nicht aus „Ist-Prozessen“ abgeleitet werden. Die Entwick- 

lung von Online Diensten der Kategorie drei und insbesondere der Kategorien vier und fünf 

stellt für die meisten Kommunen immer noch eine grundlegende Prozessinnovation dar. Die 

Aufgabe des Organisators ist es, fachliche Anforderungen, wie etwa die zur Sachbearbeitung 

zwingend notwendigen Angaben (z.B. Anschrift) und die technischen Anforderungen, wie etwa 

ein automatischer Abgleich der Daten mit dem Melderegister, zu identifizieren, um sie der IT 

für die Programmierung mitzuteilen. 

Um innovative Soll-Prozesse bzw. Teilprozesse zu entwickeln und dabei ihre fachlichen und 

technologischen Anforderungen zu spezifizieren, empfehlen wir Ihnen zunächst anhand der 

folgenden Checkliste „Fachkonzept Web-Frontend“ relevante, allgemeine Anforderungen zu 

sammeln und anschließend anhand der Vorlage „Anwendungsfallbeschreibung“ eine detaillier- 

te Beschreibung des oder der Anwendungsfälle („Use Cases“) zum Web-Frontend zu erstel- 

len. 

Abbildung 29: Ablaufmodell zur Fachkonzeption Web-Frontend


Das Vorgehen zur Erstellung des Fachkonzepts ist in dem oben stehenden Ablaufmodell dar- 

gestellt. Die Aktivität 3 „Maskenfluss modellieren“ markiert den Übergang zur technischen Fein- 

konzeption. Zur Erfassung und Dokumentation der Anforderungen und Servicemerkmale (fach- 

liche Grobspezifikation) eines Web-Frontends für Kunden und Partner der Verwaltungsprozes- 

se dient die folgende tabellarische Übersicht zu den wesentlichen Funktionen eines online 

gestützten Self-Service-Angebots.


erforde 

liegt 

rlich? 

vor? 

Detaillierung Methodenhinweise 

J N J N 

Checkliste: 

Feinkonzept "Web-Frontend" / "Portal" 


Kommunikations- und 

Marketingkonzept 

A Zielgruppen- und Nutzer- Analyse 

Kundensegmentierung, 

Rollenkonzept, 

Kommunikationskonzept 

X 

Beschreibung der Zielgruppen und Kunden 

bzw. Nutzergruppen 

Wer sind die Nutzer (Zielgruppe)? Ist die Zeilgruppe "homogen" oder 

müssen für unterschiedliche Gruppen unterschiedliche Service-Angebote 

bzw. Zugänge geschaffen werden? 

1 

internetzugang 

extranetzugang 

intranetzugang 

Prozesslandkarte 

2 

Ableitung aus den Prozessaufnahmen, 

Sind die Anwendungsfälle aus Nutzersicht identifiziert? 

X Use Case Diagramm 

Prozesslandkarte oder Neukonzeption 

Use Case Beschreibung 

3 

Kommunikationskonzept 

Ist der Kundennutzen beschrieben? siehe: "Kurzbeschreibung" Use Case X 


Use Case Modell 

(Diagramm / Beschreibung) 

Sind die Aktivitäten des Nutzers und die Funktionen der Anwendung 

1 (Portal-Frontend) vollständig erfasst und dokumentiert? Use Case Diagramm 

Akteure (Mensch/Maschine) X Use Case Diagramm 

Anwendungsfälle X Use Case Diagramm 

Unteranwendungsfälle X Use Case Diagramm 

Ausnahmen ("exceptions") X Use Case Diagramm 

Varianten ("extensions") X Use Case Diagramm 

2 Welche Zugangsmöglichkeiten sollen dem Nutzer angeboten werden? Use Case Beschreibung 

freier Zugang, keine Beschränkung Use Case Beschreibung 

Zugang mit Nutzername / Passwort Use Case Beschreibung 

Zugang mit Nutzername / Passwort / TAN Use Case Beschreibung 

Zugang über nPA Use Case Beschreibung 

Zugang über de-Mail / E-Postbrief Use Case Beschreibung 

personalisierte Anwendungsoberfläche Use Case Beschreibung 

persönliches Postfach Use Case Beschreibung 

single sign on Use Case Beschreibung 

3 Welche Bearbeitungsfunktionen sollen dem Nutzer geboten werden? Use Case Beschreibung 

B Fachliches Feinkonzept funktionale Anforderungen 

Abbildung 30: Checkliste Fachkonzept Web-Frontend (1 / 4)


Ansprechpartner suchen Use Case Beschreibung 

Inhalte suchen Use Case Beschreibung 

Inhalte ansehen Use Case Beschreibung 

Inhalte downloaden Use Case Beschreibung 

Formular ansehen Use Case Beschreibung 

Formular bearbeiten Use Case Beschreibung 

Formular unterschreiben Use Case Beschreibung 

Formular downloaden Use Case Beschreibung 

Druckfunktion Use Case Beschreibung 


Daten ansehen 

Datenmodell 


Daten erfassen 

Datenmodell 


Daten bearbeiten/ändern/löschen 

Datenmodell 


Dokumente downloaden 

Dokumentenmodell 


Daten Downloaden 

Datenmodell 


Dokumente uploaden, versenden 

Dokumentenmodell 


Daten uploaden, versenden 

Datenmodell 

E-Mail versenden Use Case Beschreibung 

Rückruf vereinbaren Use Case Beschreibung 

Terminvereinbarungen Use Case Beschreibung 

4 Welche BearbeitungsService-Funktionen sollen dem Nutzer geboten werden? Use Case Beschreibung 

Plausibilitätsprüfung Daten Use Case Beschreibung 

Vollständigkeitsprüfung Formulareingaben Use Case Beschreibung 

Vollständigkeitsprüfung Anlagen Use Case Beschreibung 

Geführter Nutzerdialog über mehrere 

Eingabefenster mit Eingabeabhängigen 

Maskenfluss, Ablaufmodell 

Entscheidungen zum Maskenfluss 

5 Benötigt der Nutzer ergänzende Informationsangebote und "Inhalte"? Use Case Beschreibung 

gesetzliche Grundlagen, Rechtsbelehrung Use Case Beschreibung 

Zuständige Bearbeiter / Kontaktdaten Use Case Beschreibung 

Produkt- /( Leistungsbeschreibung Use Case Beschreibung 

Hilfetexte, Bearbeitungshilfen, Erläuterungen Use Case Beschreibung 

sonstige Use Case Beschreibung 



müssen für den gesamten 

C sonstige funktionale Anforderungen 


Anwendungsfall gelten! 

1 Barrierefreiheit Use Case Beschreibung 

barrierefreier Zugang Use Case Beschreibung 

Mehrsprachigkeit Use Case Beschreibung 

2 Shopmodul Use Case Beschreibung 

E-Payment Use Case Beschreibung 

Warenkorb Use Case Beschreibung 

3 Web-Telefonie Use Case Beschreibung 

Telefonanruf aus der Anwendung heraus Use Case Beschreibung 

Anwenderbetreuung durch Callcenter Agent Use Case Beschreibung 

4 allgemeine Informationsdienste Kommunikationskonzept 

Newsletter Kommunikationskonzept 

Veranstaltungskalender Kommunikationskonzept 

Stadtplan Kommunikationskonzept 

sonstige Kommunikationskonzept 

müssen für den gesamten 


Anwendungsfall gelten! 

Geschäftsregeln, 

Datenschutzbedarfsanalyse, 

Datenschutzkonzept 

sichere Datenverbindung / -Übertagung (VPN) Use Case Beschreibung 

D sonstige technische Anforderungen 

Abbildung 30: Checkliste Fachkonzept Web-Frontend (3 / 4) 

1 Datensicherheit: Nutzung von sensiblen Kundendaten 

Verschlüsselung der Daten/Dokumente (SSL) Use Case Beschreibung 

Einverständniserklärung Nutzer Use Case Beschreibung 

fortgeschrittene E-Signatur (siehe B2) Use Case Beschreibung 

qualifizierte E-Signatur Use Case Beschreibung 

2 Anbindung von internen IT-Verfahren und Service-Komponenten Use Case Beschreibung 

Formularserver Use Case Beschreibung 

Virtuelle Poststelle Use Case Beschreibung 

CMS Use Case Beschreibung 

DMS Use Case Beschreibung 


Feinkonzept "Schnittstelle" 

Fachverfahren




Kasse 

Datenbank Use Case Beschreibung 

Outputmagementsystem Use Case Beschreibung 

Inputmanagementsystem (Indizierung Formulare!) Use Case Beschreibung 

ID-Management Use Case Beschreibung 

CRM Use Case Beschreibung 




externe Verwaltungen 



Unternehmen 



NGO und Freie Träger 


3 Anbindung von externen IT-Verfahren und Service-Komponenten 



Bearbeitungshinweise zur Checkliste Fachkonzept Web-Frontend 

Kreuzen Sie zunächst in der Checkliste die zur Feinspezifikation des Anwendungsfalls 

erforderlichen Themen und Merkmale in der Spalte „erforderlich“ an 

Besondere Aufmerksamkeit erfordert die Zielgruppen und Nutzeranalyse und das Kom- 

munikationskonzept. Das „beste“ Online Service-Angebot kann keine Wirkung entfalten, 

wenn es der Zielgruppe nicht bekannt gemacht wird! Erstellen Sie dazu frühzeitig einen 

das Feinkonzept ergänzenden Maßnahmenplan. 

Beachten Sie die Methodenhinweise zur weiteren Konkretisierung Ihres Fachkonzepts 

Schreiben Sie die Checkliste zur Kontrolle des Projektfortschritts und der Dokumentation 

des Fachkonzepts fort (Spalte: liegt vor?) 

Zur weiteren Verfeinerung des Fachkonzepts empfehlen wir die Erstellung eines Anwendungs- 

falldiagramms und die Erstellung einer Anwendungsfallbeschreibung. Diese bilden den fach- 

konzeptionellen „Input“ für die Ableitung von Rollen und Rechten, der Prozesssteuerungslogik 

und des Maskenflusses im Rahmen der technischen Feinkonzeption. Das Anwendungsfalldia- 

gramm ist besonders gut geeignet, um zunächst eine grobe Übersicht zu den am Anwen- 

dungsfall (=Systemnutzung) beteiligten Akteuren und Rollen sowie die durch die Web- 

Anwendung bereit zu stellenden Funktionsgruppen („Aktivitäten“) zu erhalten. Die zur Erstel- 

lung eines Anwendungsfalldiagramms benötigten Symbole und ihre Verwendung sind in der 

folgenden Abbildung schematisch dargestellt: 

Das „Use Case“- Diagramm nach der UML (Unified Modelling Language) 

Rolle / Akteur 

Geschäftsprozess 

 

Teilprozess 

Name 

Anwendungsfall 1 

Anwendungsfall X 

Unter- 

Anwendungsfall 1.1 

Unter- 

Anwendungsfall 1.2 

Aktivität 

(Objekt / Verrichtung) 

Abbildung 31: Notation zur Erstellung von Anwendungsfalldiagrammen 

Bearbeitungshinweise zum Anwendungsfalldiagramm 

Unter- Unter- 

Anwendungsfall 1.1.1 

Unter- Unter- 

Anwendungsfall 1.1.1 

Entsprechung der Detaillierungsebenen in FaMoS 



Tätigkeit 


Eine Standard-Methode zur Modellierung von Anwendungsfällen bietet die UML 19 mit 

dem sogenannten „Use-Case-Diagramm“ (Anwendungsfalldiagramm). Die Anwen- 

dungsfälle entsprechen grundsätzlich den Teilprozessen oder Aktivitätengruppen bzw. 

19 UML = Unified Modelling Language, ein in der IT-Anwendungsentwicklung verwendeter Methodenstandard zur 

Modellierung von Anforderungen an IT-Systeme


Aktivitäten in einem Soll-Modell. Im Unterschied zum Soll-Modell wird aber der Kontroll- 

fluss aus der Betrachtung ausgeblendet. Anwendungsfälle fokussieren auf die Funktio- 

nen, die eine Anwendung bereitstellen soll. 

Dabei werden, analog zum Vorgehen bei der Prozessmodellierung, die Anwendungsfälle 

solange in ihre Unteranwendungsfälle zergliedert, bis die Funktionen „sichtbar“ werden. 

Zu jedem Anwendungsfall entsteht also eine „Liste“ von mehr oder weniger stark detail- 

lierten Anwendungsfunktionen. 

Die Menge der Anwendungsfunktionen wird umgekehrt, je nach Komplexität der Anforde- 

rungen, durch die Anwendungsfälle bzw. ihre Unteranwendungsfälle gruppiert bzw. ge- 

bündelt. 

Dabei entsprechen die Funktionsbündel der Anwendungsfälle den für Anwender zu ent- 

wickelnden Bearbeitungsfunktionen in den „Bearbeitungsmasken“ der zu erstellenden 

Anwendung. 

Bei komplexen Anwendungsfällen empfiehlt es sich, ein Maskenflussdiagramm und Pro- 

zessablaufdiagramme zu erstellen, welche Auskunft über die logische Verknüpfung und 

Abfolge der Bearbeitungsmasken in der Anwendung geben (Kontrollfluss, Workflowdi- 

agramm). 

Es hat sich praktisch bewährt zunächst das sogenannte „Happy-Day-Szenario 20 “ und erst 

anschließend die „Ausnahmen“ zu modellieren. 

Im Anschluss an die grafische Modellierung der Anwendungsfälle soll zur Spezifikation der 

fachlichen Anforderungen in den Anwendungsfällen eine Anwendungsfallbeschreibung erstellt 

werden. Diese beschreibt den Ablauf sowie allgemeine, funktionale und technische Anforde- 

rungen. Auf ihrer Grundlage können bereits erste Entwürfe der grafischen Benutzer- 

Schnittstelle (GUI / Bearbeitungsmaske) erstellt werden. Auf ihrer Grundlage kann ein techni- 

scher Entwurf der Web-Anwendung erstellt werden. Eine entsprechende Dokumentenvorlage 

mit einem kurzen Fallbeispiel zur Anwendungsfallbeschreibung finden Sie in der Abbildung 32. 

Bearbeitungshinweise zur Anwendungsfallbeschreibung 

Erstellen Sie zu jedem im Anwendungsfalldiagramm skizzierten Anwendungsfall (und bei 

Bedarf zu den Unteranwendungsfällen) eine detaillierte Anwendungsfallbeschreibung 

Beginnen Sie jeweils bei der Beschreibung des Anwendungsfalls zunächst mit dem so- 

genannten „Happy Day-Szenario“. Dieses beschreibt den Regelfall der Nutzung bzw. 

den einfachsten Anwendungsfall. Beschreiben Sie erst danach die Sonderfälle und Aus- 

nahmen. 

Neben der Ablaufbeschreibung können ergänzende Angaben, zum Beispiel zur erwarte- 

ten Nutzungshäufigkeit, den sonstigen funktionalen und technischen Anforderungen so- 

20 Das sogenannte „Happy Day Szenario“ beschreibt den einfachsten Anwendungsfall und blendet alle Prozessvarianten zur 

Bearbeitung von Ausnahmen und Sonderfällen sowie mögliche Fehlerbearbeitungsprozesse aus.


wie zu Erfordernissen zur Datenspeicherung sehr wichtig für die Gestaltung einer nut- 

zerfreundlichen, ergonomischen und sicheren Anwendung sein. 

Diskutieren Sie Ihre Anwendungsfallbeschreibung sowohl mit den fachlich zuständigen 

Prozess- als auch mit den IT-Experten Ihrer Verwaltung und halten Sie alle offenen Fra- 

gen fest. 

Zum Abschluss der Anwendungsfallbeschreibung dürfen keine offenen Fragen mehr vor- 

Vorlage 

handen sein! 

Anwendungsfallbeschreibung Seite 1/4 

© b.i.t.consult GmbH Seeheim 2010 

1. Name Anwendungsfall Einkommenserklärung abgeben 

2. Nummer Anwendungsfall XXX 

3. Referenzierte Dokumente Zum Beispiel: 

4. Kurzbeschreibung und 

Kundennutzen 

Anwendungsfalldiagramm 

Prozesslandkarte 

Prozessmodell 

Maskenflussmodell 

Maskenentwurf 

Was soll mit dem Anwendungsfall erreicht werden? 

Zum Beispiel: Eltern, die ihre Kinder in der Kita angemeldet haben geben online über das 

Bürgerportal eine Selbstauskunft zu ihrem erwarteten Einkommen ab, damit die Kommune 

den Elternbeitrag festsetzen kann. Der Kunde erspart sich die schriftliche / postalische Mitteilung 

5. Akteure Welche Akteure (Anwender und Systeme/Anwendungen) 

sind an dem Anwendungsfall beteiligt? 

5.1 Anwender: zum Beispiel: Bürger (Eltern) 

5.2 Anwendung: Bürgerportal / Online Bürgerservice Elternbeiträge 

6. Auslöser Wie, bzw. durch was wird der Anwendungsfall ausgelöst? 

Zum Beispiel: Der Anwender hat sich mit seiner Kennung am Bürgerservice angemeldet und 

ruft die Seite „Einkommenserklärung Elternbeiträge“ auf 

7. Vorbedingungen Was muss bereits vorher geschehen, bearbeitet oder 

durchgeführt worden sein, damit der Anwendungsfall eintreten 

kann? 

• Die Kita-Anmeldung des Kindes muss der Kommune vorliegen 

• Die Eltern haben eine Zugangskennung zum Bürgerservice Elternbeiträge erhalten


Vorlage 



8. Ergebnisse und 

Nachbedingungen 

8.1 Ergebnisse: 

Welche Nachbedingungen müssen erfüllt sein? 

• die Einkommensdaten der Eltern wurden über das Portal an das Jugendamt übermittelt 

8.2 Nachbedingungen: 

• der Anwender hat sich ordnungsgemäß am System abgemeldet und die Session beendet 

• die Eltern haben eine Empfangsbestätigung erhalten 

9. Benutzte Anwen- 

dungsfälle 

Welche anderen Anwendungsfälle werden von diesem Anwendungs- 

fall benutzt? 

• Anwendungsfall: „Systemanmeldung / Nutzerkennung prüfen“; Anwendungsfall Nummer: XXX 

• Anwendungsfall: „Empfangsbestätigung versenden“; Anwendungsfall Nummer: YYY 

10. Ablaufbeschreibung 

10.1 Basisablauf („Happy Day-Szenario“) 

Schritt Akteur Aktivität / Funktion Bemerkung 

1 Eltern Web-Seite „Kita-Elternbeiträge“ aufrufen 

2 Web-Portal Web-Seite Elternbeiträge anzeigen 

3 Eltern Service-Seite „Elterneinkommen erklären 

aufrufen“ 

4 Web-Portal Service Seite „Elterneinkommen erklären“ 

anzeigen 

5 Eltern Am System anmelden; Nutzer- 

Kennung eingeben 

6 Web-Portal Nutzerkennung prüfen, Formular „Elterneinkommen“ 

anzeigen 

7 Eltern Stammdaten prüfen 

Kundeninformation 

Rechtsgrundlagen 

anzeigen 

8 Eltern E-Mail Adresse prüfen bzw. erfassen Alternativ: schriftl. Bestätigung 

anfordern 

9 Einkommensdaten erfassen


10 Eltern Erfasste Daten bestätigen 

Vorlage 



11 Eltern Daten absenden 

12 Web-Portal Daten speichern 

13 Web-Portal Bearbeitungsprotokoll erstellen 

14 Web-Portal Empfangsbestätigung versenden Mail/postalisch? 

15 Web-Portal Daten an Fachanwendung übergeben 

16 Fachanwendung 

Elternbeiträge 

10.2 Ausnahmen und Varianten 

Einkommensdaten speichern Benachrichtigung SB 

generieren 

5.A Eltern Neue Nutzerkennung anfordern 

6.A Web-Portal Nutzerkennung ungültig, Zugang verweigern 

6.B Web-Portal Anforderung „Neue Nutzerkennung anbieten“ 

14.A Web-Portal Empfangsbestätigung per E-Mail versenden 

14.B Web-Portal Versand einer postalischen Empfangsbestätigung 

anstoßen 

11. Sonstige funktionale 

Anforderungen 

Zum Beispiel: 

Welche sonstigen funktionalen Anforderungen bestehen die für 

den gesamten Anwendungsfall? 

• Die gesamte Anwendung und die Anwendungsdialoge mit den Nutzern müssen sehr einfach 

und übersichtlich gestaltet sein 

• Alle Funktionen und Datenfelder müssen mit „Hilfe-Menüs“ hinterlegt sein („mouse over“) 

Die Seite muss dem CD / CI der Kommune entsprechen 

12. sonstige technische 

Anforderungen 

Welche sonstigen technischen, das heißt nicht funktionalen Anforderungen, 

gelten zu diesem Anwendungsfall?


Vorlage 



Zum Beispiel: 

• Die Übermittlung der Einkommensdaten muss über eine gesicherte Verbindung (z.B.: SSL- 

Verschlüsselung) erfolgen 

Der Seitenaufbau darf nicht länger als 3 Sekunden dauern 

13. Datenspeicherung Werden aufgrund oder im Verlauf dieses Anwendungsfalls Da- 

ten gespeichert? Welche und wie viele? 

• e-Mail-Adresse der Eltern 

• Einkommensdaten der Eltern 

o Bruttoeinkommen per anno Eltern 1 (numerisch, 6 stellen) 

o Bruttoeinkommen per anno Eltern 2 (numerisch, 6 stellen) 

Alternativ: 

o Auswahlmenü mit Einkommensgruppierung Eltern 1 bzw. 2 

• Bearbeitungsprotokoll (log-Datei) 

14. Nutzungshäufigkeit Wie häufig wird der Anwendungsfall eintreten? 

• Es werden maximal 6000 Nutzer und Nutzungen per anno erwartet 

15. Priorität Welche Umsetzungspriorität hat der Anwendungsfall? 

A/B/C/D Bemerkungen 

16. Offene Fragen Gibt es offene Punkte und Fragen im Zusammenhang mit der 

Anwendungsfallbeschreibung? 

Dieser Abschnitt darf bei Freigabe des Dokuments keine Inhalte mehr haben. 

Abbildung 32: Vorlage Anwendungsfallbeschreibung 

2.5.3 Fachkonzept Eingangsbearbeitung 

Im Sinne einer effizienten elektronischen Vorgangsbearbeitung müssen grundsätzlich alle Ein- 

gangskanäle (und Ausgangskanäle), möglichst ohne Medienbruch, in IT-Anwendungssysteme 

zur E-Vorgangsbearbeitung integriert werden. Während die bereits im Bereich der „elektroni- 

schen Medien“ angesiedelten Eingangskanäle: Bürgerportal, Fax und E-Mail mit ihren Varian- 

ten DE-Mail bzw. E-Postbrief ohne Medienbruch in die Vorgangsbearbeitung integriert werden 

können, können unvermeidliche Medienbrüche im Bereich der Posteingangsbearbeitung nur 

durch eine Digitalisierung papiergebundener Eingangsdokumente „geheilt“ werden. Im Fach- 

konzept Eingangsbearbeitung geht es um die Zusammenstellung jener Fachinformationen, die


zur Planung von Prozessen, technischer Infrastruktur und Personaleinsatz im Bereich der 

Digitalisierung von Eingangsdokumenten (Scan-Verfahren, Prozess) benötigt werden. 

Da die Digitalisierung von Eingangsdokumenten im Bereich der Kommunalverwaltung immer 

noch eine Ausnahmeerscheinung darstellt, möchten wir zunächst eine kurze Einführung in das 

Thema „Scannen“ voranstellen: 

Aufgabe des Scanprozesses ist primär die Umwandlung von Papierdokumenten in ein 

digitales Abbild, das die Grundlage für alle weiteren Arbeitsschritte ist. Bei den Scan- 

nern wird in Arbeitsplatz-, Abteilungs- und Produktionsscanner sowie Großformatscan- 

ner unterschieden. Aktuelle Scanner sollten folgende Mindestanforderungen erfüllen: 

Doppelseitiges Scannen bis 300 dpi 21 in Farbe und SW in einem Durchgang. 

Automatischer Dokumenteneinzug 

Unterstützung von ISIS 22 und TWAIN 

Anschluss über USB, FireWire oder Ethernet (Netzwerkscanner) 

Doppelseiteneinzugskontrolle (über Ultraschall) 

Abteilungs- und Produktionsscanner unterstützen in der Regel Dokumentgrößen bis DIN A3 

und sind in der Lage, sowohl das Schwarz-Weiß, wie auch das Farbbild gleichzeitig zu erfas- 

sen. Neben im Scanner ablaufenden Bildverbesserungsverfahren (Geraderücken, Ränder 

beschneiden, Helligkeitskorrektur, automatische Ausrichtung, usw.) unterscheiden sich die 

Geräte hauptsächlich in Geschwindigkeit und Tageskapazität. Im Standard werden die Doku- 

mente oben aus einem Anlagefach am Scanner gezogen und in einem Fach darunter wieder 

abgelegt (umgekehrt wie beim Laserdrucker). Diese Verarbeitung kann bei einigen Dokumen- 

ten zu Problemen führen, z.B. sehr kleine Dokumente, sehr lange Dokumente, altes brüchiges 

Papier (Altakten), Pappvorlagen (Karteikarten). Für solche Zwecke sind Scanner verfügbar, 

die das Papier vorne einziehen, gerade durch den Scanner führen und hinter dem Scanner 

ablegen. Für Formate über DIN A3 sind spezielle Großformatscanner erforderlich. Zu beach- 

ten ist, dass die erzeugten Bilddateien z.T. ein erhebliches Datenvolumen erreichen können; 

dies belastet unter Umständen Speicherkapazitäten und Bandbreiten bei der Übermittlung der 

Dokumente. 

Das Datenvolumen wird dabei maßgeblich von der gewählten Bildauflösung (dpi-Rate), den 

Farbinformationen und dem Ausgabedateiformat beeinflusst. Es ist also jeweils abzuwägen 

welche „Bildqualität“ ausreichend ist. 

Beim „ersetzenden Scannen“. werden die Originaldokumente nach dem Scannen ver- 

nichtet. Falls Rechtsunsicherheit über die Anerkennung gescannter Dokumente besteht, 

müssen die Originale weiterhin aufbewahrt werden. 

Werden die Dokumente bereits direkt nach der Anlieferung, zum Beispiel in der Poststel- 

le oder bei einem Scan-Dienstleister digitalisiert, spricht man vom „Frühen Scannen“. 

Für bestimmte Dokumente, in der Regel aus dem Bereich des Sozialgesetzbuches, wird 

eine qualifizierte elektronische Signatur gefordert. 

21 dpi = „dots per inch“; Maßeinheit für die Punktdichte bei Bildreproduktionen. 

22 Bei ISIS bzw. TWAIN handelt es sich um technologische Standards zum Austausch von Daten zwischen Bildeinga- 

begeräten.


Werden die Dokumente nach der internen Zustellung im Fachbereich, am Arbeitsplatz 

des Sachbearbeiters oder nach der papiergestützten Sachbearbeitung gescannt, spricht 

man vom „Späten Scannen“. Das „späte Scannen“ ist in der Regel die weniger effiziente 

Vorgehensweise, lässt sich aber nicht immer vermeiden. 

Ein Scanprozess ist in der Regel in vier Teilprozesse gegliedert: die Arbeitsvorbereitung, 

die Digitalisierung, die Indizierung und die Nachbereitung. In der Arbeitsvorbereitung 

werden die zu scannenden Dokumente nach „Themen“ sortiert und für das Scannen vor- 

bereitet. Zunächst werden die Dokumente entklammert, aufgeschnitten oder sonst nach 

Vorgabe vorbereitet. Der Anfang jedes neuen Dokuments mit einem Barcodeaufkleber 

oder durch ein Trennblatt gekennzeichnet. Dies ist erforderlich, da eine automatische 

Dokumententrennung sicher funktioniert. Es folgt die Ablage der Schriftstücke in sachli- 

chen Stapeln. Hinter den Stapeln liegen Beschreibungen der Scansoftware, wie die Do- 

kumente zu verarbeiten sind. Zu jedem Stapel wird ein Laufzettel erstellt, der dokumen- 

tiert, wer welche Tätigkeiten im Prozess erledigt hat. Beim Digitalisieren der Dokumente 

werden die einzelnen Scanstapel mit der dafür erstellten Scanklasse verarbeitet, d.h. die 

vorbereiteten Scanstapel werden in den Scanner eingelegt und zunächst digitalisiert, es 

erfolgt die Barcodeerkennung und die Dokumententrennung. Dieser Teilprozess endet 

mit einer ersten Qualitätskontrolle und der elektronischen Signatur der Dateien. Im 

nächsten Teilprozess, der Indizierung, erfolgt die Klassifizierung der Dokumente und die 

Gewinnung von Inhaltsinformationen zum Dokument. Dies erfolgt entweder automatisiert 

oder manuell. Nach der abschließenden Qualitätssicherung werden die indizierten Bild- 

dokumente zur weiteren Verarbeitung bereitgestellt. Die Dokumente werden mit den In- 

dexinformationen an das DMS- / Workflowmanagementsystem übergeben. Wie die Da- 

ten übergeben werden müssen hängt vom Dokumenten- bzw. vom Workflow- Manage- 

mentsystem ab. In der Nachbereitung werden die Dokumente nach den Kategorien: 

„Vernichten“ (mit einer Karenzzeit von bis zu 6 Wochen), „Einlagern“ und „Weiterleiten“ 

sortiert und verarbeitet. Die Vernichtung erfolgt verzögert, damit bei Fehlern im Prozess 

noch Korrekturen bzw. ein Nachscannen möglich sind. 

Entscheidend für die Wertschöpfung des Scanprozesses und Prozessoptimierungseffekte 

in der nachgelagerten Vorgangsbearbeitung ist der Automationsgrad im Scanverfahren 

und die sorgfältige Indizierung der Eingangsdokumente, damit diese möglichst ohne 

Umwege zu dem für ihre Bearbeitung zuständigen Mitarbeiter gelangen. 

Bei der Indizierung der digitalisierten Eingangsdokumente werden diese mit sogenannten 

Metadaten, zum Beispiel einem Aktenzeichen versehen. Die Metadaten ermöglichen in 

Verbindung mit entsprechenden Verzeichnisdiensten eine maschinelle Zuordnung („Mat- 

ching“) des Dokuments zum Vorgang und zum Bearbeiter. Anhand der Metadaten kön- 

nen die Dokumente also ohne manuelle Eingriffe in den elektronischen Posteingang des 

Bearbeiters übergeben werden. 

Die Indizierung kann, abhängig von der Typologie und Struktur der Eingangsdokumente 

und der Wirtschaftlichkeit des Technologieeinsatzes manuell oder maschinell erfolgen. 

Darüber hinaus können Dokumenteninhalte und Daten maschinell ausgelesen und zur 

elektronischen Weiterverarbeitung in Vorgangsbearbeitungssystemen oder sonstigen


Fachanwendungen bereitgestellt werden. Dies vermeidet manuellen Erfassungsauf- 

wand in den nachgelagerten Prozessen. 

Die zur maschinellen Indizierung eingesetzten Programme basieren auf den sogenann- 

ten OCR 23 bzw. ICR 24 Technologien, die in Verbindung mit Validierungskatalogen, z.B. 

für Geschäftszeichen, eingesetzt werden. 

Die zum Scannen eingesetzte Hardware und Software weist eine große Bandbreite bei 

den Funktionen und den Investitions- bzw. Lizenzkosten auf. Deshalb ist es sinnvoll, 

erwartete Bearbeitungsmengen und Leistungsanforderungen im Rahmen der Fachkon- 

zeption zur Eingangsbearbeitung zu ermitteln und eine Wirtschaftlichkeitsanalyse zu 

erstellen. 

Insgesamt stellt sich bei allen Scan-Projekten die Frage: „Selbst machen oder verge- 

ben?“. 

Kriterien, die für eigenes Scannen sprechen: 

Zeitkritischer Prozess, Post soll direkt in den Prozess gescannt werden 

Datenschutz verbietet externe Vergabe 

Auslastung vorhandener Infrastruktur 

Kriterien, die für externes Scannen sprechen: 

Volumen ist mit eigenen Kräften in einem gegebenen Zeitrahmen nicht zu schaffen 

(Archivierung Altakten, Projektstart mit umfangreichen Scanaktivitäten) 

fehlendes Know/How oder fehlende Technik 

Zeitunkritisch, geringe Auswirkungen auf interne Geschäftsprozesse 

Preis bzw. Kosten 

Zur Erstellung des Fachkonzepts sind zwei Arbeitsschritte erforderlich: 

1. Ist-Aufnahme der relevanten Prozessdokumente 

2. Analyse der relevanten Prozessdokumente 

Grundlage für die Ist-Aufnahme der relevanten Prozessdokumente ist Ihre Prozessfunktions- 

tabelle. In der Spalte Daten und Dokumente wurden bereits die Input- und Outputdokumente 

erfasst. Für den Scanprozess sind hier die Eingangsdokumente relevant, die in Papierform 

ankommen. Für diese Dokumente ist eine Dokumentenanalyse erforderlich, um die fachlichen 

Anforderungen an den Scanablauf zu beschreiben. Die Analyse dient zum einen der Auswahl 

der richtigen Technik wie Scanner und Software, zum anderen zur Festlegung der Tätigkeiten 

vor, während und nach dem Scannen. In der folgenden Abbildung 33 finden Sie eine Vorlage 

zur Durchführung und Dokumentation Ihrer Dokumentenanalyse. Die Vorlage enthält bereits 

Beispielinformationen, die veranschaulichen, welche Inhalte als Ergebnis der Dokumenten- 

analyse gewünscht werden. 

23 OCR = Optical Charakter Recognition; optische (Schrift-)Zeichenerkennung. 

24 ICR = Intelligent Character Recognition; optisches Verfahren zur Entzifferung von handschriftlichen Zeichen oder 

Erkennung fehlerhafter Schreibweisen (Worterkennung, IWR) durch Mustervergleiche.


Bearbeitungshinweise: 

Übertragen Sie alle papiergebundenen Eingangsdokumente (Eingangskanäle: Poststelle 

und Bürgerdienste) aus dem Soll-Modell in die Vorlage 

Erstellen Sie die Dokumentenbeschreibung 

Stellen Sie fest, ob das Eingangsdokument vertrauliche Daten enthält und deshalb „ge- 

schlossen“ zugestellt werden muss. Dokumente dieses Typs sollten „spät“, d.h. vom zu- 

ständigen Bearbeiter bzw. Empfänger persönlich gescannt werden. Grundsätzlich muss 

allerdings ein Vermerk „vertraulich/persönlich“ im Adressfeld enthalten sein, um solche 

Posteingänge sichtbar zu kennzeichnen. Die Nennung des Empfängernamens im Ad- 

ressfeld begründet rechtlich keine geschlossene Zustellung! 

Ermitteln Sie durch die Sichtung einer Dokumentenstichprobe die Anforderungen zur Ar- 

beitsvorbereitung 

Legen Sie mit Blick auf die erforderliche Bildqualität, Bandbreite, Dokumentenladezeiten 

und Speicherkapazität die Anforderungen an die Digitalisierung der Dokumente fest 

Analysieren Sie anhand welcher Metadaten und Kriterien die Klassifizierung der Ein- 

gangsdokumente und ihre Zuordnung zu Vorgängen und Bearbeitern erfolgt bzw. zu- 

künftig erfolgen soll (Indizierung) und prüfen Sie, welche Inhaltsdaten aus Dokumenten 

extrahiert werden können. 

Ermitteln Sie gesetzliche Aufbewahrungsfristen zu jedem Eingangsdokument 

Legen Sie die Anforderungen zur Dokumentennachbereitung fest


nein PZU 

PZU Text / Vordruck 1 8000 A5 farbiges 

Papier 

X 

graustufe 

nscan 

8bit 

AZ, Datum 

Empfänger Name Nein 

gegen Daten aus 

Fachverfahren JA Nein 

200 JEPEG 

scannen nein VK-OWI 

Vorgangsakte 30 3500 A4 normal X sichten 

(Bildbestnadteil 

e), 

entheften, 

entklammern, 

Haftnotizen 

entfernen und 

separat 

Vorgang Typ 

Fremd-AZ 

Eigenes AZ Nein Nein nein Nein 

SW- 

Scan 

oder 

graustufe 

nscan 

8-bit 

nein KWF 

Rechnung Text / strukturiert 2 15000 A4 normal X 

graustufe 

nscan 

8bit 

nein VK-OWI 

Anschreiben Text / formlos 1 2500 A4 normal X 

SW- 

Scan 

8-bit 

200 PDF/A Typ Vorgang 

Name, 

Vorname, 

Adresse 

AZ Nein Nein nein Nein 

200 PDF/A Absender 

RE-Nr 

RE-Positionen 

Auftragsnr. 

RE-Beträge 

Skonto J/N 

Summe Netto gegen Daten aus 

RE-Betrag 

Summe Brutto Fachverfahren nein Nein 

200 PDF/A 

Fahrerfoto Bild 1 2500 A6-A5 Photopapier 

X aufkleben A4 

nein, an 

Dokument 

anhängen VK-OWI 

Farbscan 

16bit 

AZ, 

KFZ-Kennz. 

Datum Nein 

gegen KFZ- 

Melderegister JA Ja 

Selbsteinschätzung 

Text / Vordruck 1 6000 A4 normal X keine nein KITA- 

Beiträge 

SW- 

Scan 

8-bit 

Einkommensnachweise 

nein KITA-Beiträge 

diverse 2 3500 A4 und A5 normal X keine nein KITA- 

Beiträge 

SW- 

Scan 

8-bit 

offen 

Dokument- 

Papier- Papier- 

Dokumenten- Dokumenten- Zuordnung 

Bezeichnung Strukturierung Zahl Stück/Jahr Format Merkmale Vorbereitung Trennung Scan-Stapel Scan-Typ 

Wohngeldantrag Text / Vordruck 4 1500 A3 gefaltet normal X vor den Antrag und Wohngeld SWscannen 

in der anlagen 

Scan 

Faltung einzelne 

8-bit 

auftrenen Dokumente 

Vermieter- Text / Vordruck 1 1500 A4 normal X keine nein Wohngeld SWbescheinigung 

Scan 

8-bit 

Barcode Vordruck 

GZ bei Wiederholungsanträgen 

Nein Nein 

Barcode Vordruck 

GZ bei Wiederholungsanträgen 

Stammdaten Antrag 

gegen 

Einwohnermeldea 

uskunft 

Abbildung 33: Muster Fachkonzept Eingangsbearbeitung 

Einkommenserklärung 

Eltern 

Text / Vordruck 2 6000 A4 normal X keine 

SW- 

Scan 

8-bit 

Nein 

200 bitmap Barcode Vordruck 

Name, 

Stammdaten 

Vorname, 

Antragsteller gegen Daten aus 

Adresse 

Einkommensdaten Fachverfahren Nein 

200 JEPEG Typ Vorgang 

nein 

Name, 

Vorname, 

Adresse Nein Nein 

JA 

200 PDF/A Barcode Vordruck 

nein 

Name, 

Stammdaten 

Vorname, 

Antragsteller gegen Daten aus 

Adresse 

Einkommensdaten Fachverfahren 

Nein 

300 TIF 

200 GIF 

nein 

Ja 

Dokumenten- 

Typ & 

Ø 

Seiten- 

Verkehrsmenge 

geschlossen 

dpi Format 

200 PDF/A 

Indizierung 

Metadaten 

Extraktion 

Inhaltsdaten 

Mindest- 

Auflösung 

Ausgab 

e- 

Plausibilitätsprüfung 

Daten Urkunde Aufbewahrung 

nein 

Aufbewahrungs- 

Frist 

Dokumentenbeschreibung Zustellung Anforderung ArbeitsvorbereitungAnforderungen Digitalisierung Anforderungen Nachbereitung 

Muster Dokumentenanalyse 

© d-NRW / b.i.t.consult, 2010


2.5.4 Fachkonzept Dokumentenmanagement 

Die Einführung elektronischer Vorgänge und Akten in Verwaltungsverfahren bietet erwiesener- 

maßen viele Vorteile und Chancen zur Optimierung der Geschäftsprozesse. Als Oberbegriff für 

Optimierungsansätze in diesem Bereich hatte sich schon früh der Begriff der „elektronischen 

Vorgangsbearbeitung“ in Verbindung mit dem DOMEA-Fachkonzept 25 etabliert. 

Die Funktionskomponente „Dokumentenmanagement“ ist lediglich eine von mehreren funktio- 

nalen Komponenten der elektronischen Vorgangsbearbeitung. Zu einem ganzheitlichen Kon- 

zept der E-Vorgangsbearbeitung gehören darüber hinaus die Funktionskomponenten: Scan- 

nen, Input- bzw. Outputmanagement, Workflowmanagement sowie eine Middleware- 

Komponente zur Integration und Steuerung von Service-Aufrufen (E-Service Bus) aus Fachver- 

fahren oder sonstigen E-Government-Basiskomponenten 26 . Es existiert zurzeit keine allgemein 

anerkannte Definition davon, was ein „Dokumentenmanagementsystem“ (DMS) ist und was es 

genau leisten muss. Stattdessen existiert eine große Zahl von Produkten und „Lösungen“, die 

sich in ihrem Funktionsumfang, ihrer Leistungsfähigkeit und ihren technischen Merkmalen, zum 

Beispiel im Hinblick auf ihre Integrationsfähigkeit, ganz erheblich unterscheiden. Eine der Kom- 

plexität des Themas angemessene Darstellung des Sachverhalts würde den Rahmen dieses 

Praxisleitfadens bei weitem sprengen. Darüber hinaus gehört die Frage, ob und welches DMS 

die IT-Infrastruktur der Kommune ergänzen soll, in den Bereich der IT-strategischen Entschei- 

dungen, da ein DMS als „Querschnittsanwendung“ grundsätzlich immer mit Blick auf die Ge- 

samtverwaltung, d.h. mit Blick auf die Anforderungen aller Kernprozesse und die „Passfähig- 

keit“ des DMS innerhalb der bereits vorhandenen IT-Anwendungslandschaft getroffen werden 

sollte. 

Dies „reduziert“ die Frage nach den fachlichen Anforderungen an DMS zunächst einmal darauf, 

die bereits umfänglich dokumentierten, allgemeinen Anforderungskataloge zu DMS 27 zur Hand 

zu nehmen und im Hinblick auf die eigenen Erfordernisse anzupassen und zu priorisieren. 

Aus der Perspektive eines Geschäftsprozesses stellt sich in der Praxis immer wieder die Frage: 

„Benötigt der Prozess ein Dokumentenmanagementsystem?“ Da der Einsatz eines DMS Li- 

zenzkosten verursacht und in der Regel auch Einführungs- und Integrationsaufwand nach sich 

zieht, ist die Beantwortung dieser Frage sehr „praxisrelevant“. Das Fachkonzept Dokumenten- 

management dient vor allem zur Beantwortung dieser Frage, nicht zur Auswahl und Beschaf- 

fung eines DMS. In der folgenden Abbildung 34 finden Sie eine kurze Checkliste, die Ihnen 

helfen soll festzustellen, ob: 

A. der Geschäftsprozess überhaupt ein „professionelles“ DM-System benötigt und 

B. die möglicherweise genutzte Fachanwendung bereits DM-Kernfunktionalitäten anbietet 

25 DOMEA steht für: „Dokumentenmanagement und elektronische Archivierung im IT-gestützten Geschäftsgang“. Die 

Bundesregierung hat im Regierungsprogramm „Vernetzte und transparente Verwaltung“ beschlossen, ein neues 

Konzept zu erarbeiten, das den organisatorischen Rahmen für die elektronische Verwaltungsarbeit definiert (Organi- 

sationskonzept Elektronische Verwaltungsarbeit). Dieses Konzept soll 2011 veröffentlicht werden und das DOMEA- 

Konzept ablösen. Für weiterführende Informationen siehe: http://www.verwaltung-innovativ.de/nn_685148/DE/ 

Organisation/domea__konzept/ domea__konzept__node.html?__nnn=true 

26 Vgl. Abbildung 21 

27 Der DOMEA Anforderungskatalog kann hier heruntergeladen werden: http://www.verwaltung-innovativ.de/nn_1006118/ 

SharedDocs/Publikationen/DE/domea__konzept__anforderungskatalog __excel__tabelle.html?__nnn=true


5 Steht innerhalb der Fachanwendung ein leistungsfähiger Dokumentenviewer zur Verfügung? 

Können Eingangs- und Ergebnisdokumente ausreichend mit einem "unifizierenden" Namen (z.B.: 

6 AZ+Dokumentenname) versehen werden? 

Wird die Suche nach Dokumenten oder Dokumenteninhalten durch die Fachanwendung 

7 unterstützt? 

8 Können Metadaten zu Dokumenten in der Form eines Barcode ausgedruckt werden? 

Anzeigen von Dokumenten: Seitenzahl, Rotieren, Zoomen, Blättern, 

Scrollen, Thumb Nails 

Bearbeiten von Dokumenten: Textmarker, Unterstreichen, Stempel, 

Anmerkungen, Notizzettel, Lassofunktion, OCR-Textwandlung 

Bestehen besondere Anforderungen an eine revisionssichere Dokumentation aller 

9 Bearbeitungsschritte im Verwaltungsablauf? 

B Fragen zur DM-Eignung von Fachanwendungen Ja Nein 

Können Ergebnis- und Ausgangsdokumente in der Fachanwendung elektronisch gespeichert 

1 werden? 

2 Können digitalisierte Eingangsdokumente in der Fachanwendung gespeichert werden? 

Kann die Ablagestruktur in der Fachanwendung entsprechend den Anfordewrungen einer E-Akte 

3 nach verschiedenen Hierarchiestufen gegliedert werden? zum Beispiel: Akten, Vorgänge, Mappen usw. 

Können mehrseitige TIF oder PDF/A-Dokumente gespeichert, angezeigt und bei Bedarf 

4 ausgedruckt werden? 

Bearbeitungsprotokolle gehören zu den Standardfunktionen von DMS, 

aber auch viele Fachverfahren können revisionssicher protokollieren 

Wird ausser den Primärdaten aus den Eingangsdokumenten das Dokument selbst für den 

2 weiteren Bearbeitungs- und Entscheidungsprozess benötigt? 

3 Müssen Eingangsdokumente an verschiedene Bearbeiter weitergeleitet werden? 

4 Werden die Dokumente durch den oder die Bearbeiter verändert, ergänzt oder kommentiert? 

5 Sind im Verfahrensablauf Stellungnahmen oder Gutachten vorgesehen? 

6 Müssen (interne) Eingangsdokumente Mitzeichnungs- und Freigabeverfahren durchlaufen? zum Beispiel: Urlaubsantrag, oder Bestellungen… 

7 Müssen Ergebnisdokumente Mitzeichnungs- oder Freigabeverfahren durchlaufen? 

8 Sind im Verfahrensablauf häufig Akteneinsichten durch externe oder interne Stellen vorgesehen? 

Das Dokument, z.B. "Antrag" dient also lediglich als Datenquelle und zur 

Dokumentation der Antragstellung bzw. des "Kundenauftrags". In 

diesem Falle könnten die DM-Funktionen auch durch ein einfaches 

Ablage-/File-System erfüllt werden! 

Abbildung 34: Checkliste Anforderung und Eignung DM 

1 Hat der Prozess mehrere Bearbeiterrollen innerhalb der Verwaltung? 

Die Zahl der Prozessrollen allein ist kein hinreichendes Kriterium für 

DMS-Bedarf! 


A Fragen zur Klassifizierung der Prozessanforderungen an DM Ja Nein Bemerkungen 

Checkliste zum Fachkonzept Dokumentenmanagement



Werden die Fragen im Abschnitt A der Checkliste in Bezug auf den gegebenen Prozess 

mit „Nein“ beantwortet, benötigt der Prozess mit großer Wahrscheinlichkeit kein DMS, 

sondern lediglich ein Dokumentenablagesystem („File-System“). 

Werden die Fragen im Abschnitt B der Checkliste in Bezug auf die Prozess unterstützen- 

de Fachanwendung überwiegend mit „JA“ beantwortet, sollten Sie prüfen, ob sich die 

Einführung bzw. Integration eines DMS mit der Fachanwendung lohnt. Die Fachanwen- 

dung verfügt bereits über wesentliche Kernfunktionen eines DMS. 

2.5.5 Fachkonzept elektronischer Workflow 

Die Modellierung elektronischer Arbeitsflüsse („Workflows“) ist immer dann erforderlich, wenn 

Geschäftsprozesse automatisiert oder maschinell gesteuert werden sollen. Die grafische Dar- 

stellung der Arbeitsflüsse erleichtert dabei das Verständnis für die technische Umsetzung der 

fachlichen Anforderungen und Abläufe für Beteiligte, die selbst nicht programmieren können. 

Dazu müssen Soll-Modelle zu maschinell ausführbaren Workflowmodellen weiterentwickelt 

werden. Dies geschieht durch eine Detaillierung oder „Verfeinerung“ des Soll-Modells. Dabei 

werden die Fachprozess- „Aktivitäten“ in „Arbeitsschritte“ zergliedert. Die Arbeitsschritte können 

dabei den folgenden drei Klassen zugeordnet werden: 

Manuelle Arbeitsschritte erfolgen ohne IT-Unterstützung (z.B.: „ein Gespräch führen“). 

Diese Arbeitsschritte sind für maschinell ausführbare Workflows nicht relevant und kön- 

nen im Weiteren „ausgeblendet“ werden. Manuelle Arbeitsschritte (Ist), die automatisier- 

bar sind (Soll), zum Beispiel „Brief kuvertieren“, müssen auch als solche klassifiziert wer- 

den! 

Teilmanuelle, bzw. teilmaschinelle Arbeitsschritte erfolgen mit IT-Unterstützung. Hier fin- 

det eine Mensch-/Maschine-Interaktion statt. (z.B.: „Daten erfassen“). Der Anwendungs- 

dialog muss gestaltet werden, indem die Bearbeitungsmaske des Anwenders (z.B.: Da- 

tenfelder und Bearbeitungsfunktionen) beschrieben und die zwischen Mensch und Ma- 

schine ausgetauschten Nachrichten, d.h. der Nachrichtenfluss und seine Informationsob- 

jekte spezifiziert werden. 

Die maschinellen Arbeitsschritte werden „automatisch“ durch eine „Prozessmaschine“ 

ausgeführt. Diese maschinellen Arbeitsschritte können wiederum in zwei Gruppen einge- 

teilt werden: die „Daten- oder Informationsobjekt transformierende“ und „Prozess steu- 

ernde“ Arbeitsschritte. 

Die transformierenden Arbeitsschritte werden durch eigens zu erstellende Programmab- 

läufe oder gegebenenfalls durch den Aufruf geeigneter IT-Services ausgeführt. Diese 

Transformationen sind wertschöpfende Arbeitsschritte, wie etwa: „Leistungsanspruch be- 

rechnen“, „Dokumentenvorlage hochladen und Stammdaten einfügen“ usw. 

Neben den „Transformationen“ benötigt die maschinelle Prozessausführung auch „steu- 

ernde Arbeitsschritte“. Diese werden im Fachmodell durch die „Entscheidungen“ und 

„Entscheidungsregeln“ repräsentiert. Die steuernden Arbeitsschritte beschreiben, anhand 

welcher Kriterien und Parameter die Prozessmaschine zwischen alternativen Prozess- 

fortsetzungen „auswählt“.


Es existieren keine verbindlichen Standards für die Modellierung von Workflows. Die Vorge- 

hensweise bei der Übersetzung eines Fachprozessmodells in einen maschinell ausführbaren 

Workflow hängt davon ab, welche Notationsmethode(-n) und welche SW-Werkzeuge für die 

technische Umsetzung verwendet werden. Sie erfordert „Expertenwissen“. Andererseits stellt 

in der Prozessmodellierung der Übergang von „fachlichen“ zu „technisch ausführbaren“ Pro- 

zessmodellen in der Praxis immer wieder eine „Bruchstelle“ dar, weil Anforderungen der 

Fachseiten gar nicht, oder nur unvollständig oder nicht mit ausreichender Klarheit im Pro- 

zessmodell beschrieben wurden. 

Verfeinerung des Prozessmodells 

Fachprozess- 

Ebene 

Workflow- 

Ebene 

Manueller 

Arbeitsschritt 

Geschäftsprozess 

Teilprozess Teilprozess Teilprozess 


Aktivität 


Dialog 

Teil- 

Maschineller 



Aktivität 


Trans- 

Formation 


Aktivität 


Maschineller 


Steuerung 

Klassifikation 

Spezifikation 

Abbildung 35: Detaillierung: von der Fachprozess- zur Workflow-Ebene 

Der Praxisleitfaden kann eine intensive Beschäftigung mit für die Prozessautomation geschaf- 

fenen Werkzeugen und Methoden nicht ersetzen, er möchte aber dazu beitragen, die Model- 

lierung von „technisch ausführbaren“ Workflows durch die Fachseite und mit den Mitteln der 

Fachmodellierung noch besser vorzubereiten, um typische Schwachstellen zu beseitigen und 

Projektrisiken zu vermindern. Zur Definition eines ausführbaren Workflows gehören neben der 

Logik des Kontrollflusses u.a. eine definierte Rollenstruktur, Anwenderdialoge sowie eine Be- 

schreibung der Informationsobjekte, ihrer Datenstrukturen und den Datentransformationen. Im 

Folgenden erfahren Sie anhand des in Abbildung 36 dargestellten Beispiels, wie aus dem 

Fachprozessmodell „Bestellung“ 28 mit Mitteln der fachlichen Modellierung ein Workflowmodell 

entsteht, welches die für die technische Umsetzung, d.h. die Programmierung eines maschi- 

28 Das Modell wurde aus didaktischen Gründen vereinfacht:. Es handelt sich um ein „Happy Day-Szenario“.


nell ausführbaren Workflows, erforderlichen Fachinformationen enthält. Der Beispielprozess 

enthält acht Aktivitäten. Von diesen soll die Aktivität fünf „Mittelverfügbarkeit prüfen“ automa- 

tisch, alle anderen sollen semiautomatisch durchgeführt werden, d.h. sie erfordern einen An- 

wenderdialog. Insgesamt soll der Bestellprozess also durchgängig durch eine Workflowanwen- 

dung unterstützt werden. Das Fachmodell enthält bereits Informationen, welche Rollen und 

welche Informationsobjekte im Prozess vorkommen. 

Abbildung 36: Fachprozessmodell "Bestellung"



Erstellen Sie zunächst ein separates Rollenmodell zum Fachprozessmodell. Das Rol- 

lenmodell zu unserem Beispielprozess ist in der Abbildung 37 dargestellt. Aus dem Rol- 

lenmodell geht hervor, dass die Rolle Besteller zugleich die Rechte der Rolle Bedarfs- 

träger hat (aber nicht umgekehrt!). Die Rollenbeschreibung enthält eine kurze Charakte- 

risierung der Aufgabe und der Aktivitäten der Rolle im Prozess. 

Referenzieren Sie nun die Prozessrollen auf Stellen und Stelleninhaber in ihrer Organi- 

sation. In der darauf folgenden Abbildung 38 ist dargestellt, welchen Personen in wel- 

chen Organisationseinheiten eine bestimmte Rolle und die damit verbundenen Nutzer- 

Rechte in der geplanten Workflowanwendung zugewiesen wurden. 

Erstellen Sie nun eine Übersicht der Geschäfts- bzw. Informationsobjekte, die im Pro- 

zessablauf entstehen oder bearbeitet werden (Input- und Output- Objekte). In der 

nächsten Abbildung 40 ist das „Dokumentenmodell“ zum Fachprozess Bestellung dar- 

gestellt. Das Modell enthält alle „Dokumente“ (Synonyme: Geschäftsobjekt, Informati- 

onsobjekt) des Prozesses und zeigt zusätzlich, wie sie sich aufeinander beziehen: zu 

einem „Auftrag“ gehören zum Beispiel die „Subdokumente“ bzw. Informationsobjekte 

„Bestellung“ und „Vormerkung Obligo“. Das „Dokumentenmodell“ ist also in diesem Sin- 

ne bereits eine grobe Strukturskizze des im Rahmen der technischen Umsetzung zu 

erstellenden Datenmodells. 

Um die Datenmodellierung weiter mit „fachlichem Input“ vorzubereiten, empfehlen wir 

Ihnen, nun zu jedem Informationsobjekt („Dokument“) eine detaillierte, fachliche Be- 

schreibung in tabellarischer Form zu erstellen. Eine Vorlage dazu finden Sie in der Ab- 

bildung 41. 

Das Fachprozessmodell (Abbildung 36) enthält bereits eine Klassifikation der Aktivitäten 

nach den Kategorien „manuell“, „semiautomatisch“ und „automatisch“. Die Klassifizie- 

rung wird jeweils rechts unten zu jeder Aktivität als Bildsymbol angezeigt. Diese Klassi- 

fizierung ist aber für ein detailliertes, fachliches Workflowmodell noch nicht hinreichend 

detailliert. Nehmen Sie diese Detaillierung mit Hilfe der bereits im Kapitel A vorgestellten 

Prozessfunktionstabelle (Abbildung 13) vor und tragen Sie zu jeder Aktivität die dort er- 

wünschten IT-Bearbeitungsfunktionen ein. Diese entsprechen der Darstellungsebene 

der Arbeitsschritte im Workflowmodell. In der Abbildung 41 finden Sie eine für unseren 

Beispielprozess ausgefüllte Prozessfunktionstabelle.


Abbildung 37: Rollenmodell und Beschreibung zum „Bestellprozess“ 

Abbildung 38: Referenzierung von Rolle und Organisation 

Abbildung 39: Dokumentenmodell „Bestellprozess“


Vorlage Beschreibung Informationsobjekt 


Informationsobjekt Name: Auftrag 

Attribut Datentyp Mussfeld? Einschränkungen fachliche Beschreibung 

Das Datum an dem der Auftrag erstellt wurde 

Auftragsdatum Datum JA 

(Systemzeit) 

Ersteller Text JA maximal 12 Zeichen Kürzel des Erstellernamens 

Auftragsnummer Text JA maximal 30 Zeichen 

die Auftragsnummer entspricht der 

Vormerknummer zum Obligo im HKR-System 

Lieferant Name Text JA maximal 30 Zeichen Firmenname aus Lieferantenverzeichnis 

Lieferant Strasse Text JA maximal 30 Zeichen Adresse aus Lieferantenverzeichnis 

Lieferant Hausnummer alfanummerisch JA maximal 4 Stellen Adresse aus Lieferantenverzeichnis 

Lieferant PLZ ganze Zahlen JA maximal 5 Zeichen Adresse aus Lieferantenverzeichnis 

Lieferant Ort Text JA maximal 30 Zeichen Adresse aus Lieferantenverzeichnis 

Position Name Text JA maximal 30 Zeichen 

Position Stückzahl positive Dezimalzahl JA maximal eine Dezimalstelle 

… … … … … 

Abbildung 40: Vorlage „Beschreibung Informationsobjekt“


A B E F G J 


K L M N O P 

Aktivitätenflussdiagramm Bearbeiter Daten und Dokumente IT-Bearbeitungsfunktionen 

Anwendung / Komponente 

TP-Nr TP-Name Akt-Nr. Aktivität-Name Rolle-Name Input Output Beschreibung 

Hochladen eines E-Formulars 

"Bedarfsmeldung" 

die Daten (Name/OE) des Nutzers sind 

vorausgefüllt 

Erzeugnung einer Prozessinstanz 

"Bestellung", Vergabe einer Vorgangs- 

ID durch System 

IST SOLL Name Hersteller 

Bestellung 

Bedarfsmeldung 

Beschreibung 

Funktionen: bearbeiten, speichern, 

1 durchführen 1.1 erstellen Bedarfsträger Bedarf Bedarfsmeldung löschen, drucken, weiterleiten 

Hochladen/Anzeige der 


Funktionen: Auswahlmenue 

Prüfvermerk mit "Bestellung möglich" 

oder "Ergänzung angefragt", 

kommentieren, weiterleiten, 

in einem zweiten Fenster kann der 

Bearbeiter den Warenkatalog 

hochladen um nach bedarfsgerechten 

X Workflow Bestellung Eigenentwicklung 


Vermerk Waren zu suchen und Warenmerkmale 

Workflow Bestellung Eigenentwicklung 

1.2 prüfen Besteller Bedarfsmeldung 


Prüfergebnis zu vergleichen X Warenkatalogsystem Shopsys GMBH 

mit Prüfvermerk: 

Hochladen/Anzeige der 


"Ergänzung ergänzte Bedarfsmeldung 

1.3 ergänzen Bedarfsträger angefragt" Bedarfsmeldung Funktionen: wie Akt. Nr. 1.1 

Suche des Lieferanten im 

Lieferantenverzeichnis (Kreditoren- 

DB/HKR-System) 

Übernahme der Stammdaten 

"Lieferant" aus Lieferantenverzeichnis 

in das Informationsobjekt (IO) 

X Workflow Bestellung Eigenentwicklung 

Bestellung mit: "Bestellung" 

Daten Lieferant Suche der Warenpositionen im 

aus Lieferanten- elektronsichen Warenkatalog 

verzeichnis; Übernahme der Stammdaten zu 

Bedarfsmeldung Daten zu Bestellpositionen (Waren) aus 

mit Prüfvermerk Bestellpositionen; Warenkatalog in das IO "Bestellung" 

"Bestellung Einzel- und Funktionen: bearbeiten, speichern, 

Workflow Bestellung Eigenentwicklung 

Bestellung 

möglich" Gesamtkosten löschen, drucken, weiterleiten, 

HKR-System HKR-GmbH 

1.4 erfassen Besteller 

aus Warenkatalog kommentieren 

Warenkatalogsystem Shopsys GmbH 

1.5 

1.6 

1.7 

1.8 

Mittelverfügbarkeit 

prüfen SB Haushalt 

Mitteilung 

Budgetüberschreit 

ung erstellen SB Haushalt 

Vorkontierung 

erfassen SB Haushalt 

Bestellung 

auslösen Besteller 

Beispiel: Prozessfunktionstabelle "Bestellprozess" 

Bestellung, 

Kosten, 

Kostenstelle, 

Kostenträger; 

IST verfügbare 

Mittel laut KLR 

negatives 

Prüfungsergebnis 

verfügbare Mittel 

positives 



Bestellung mit 

Vormerknummer 



negative Mitteilung 

an Bedarfsträger 

Vorkontierung 

Obligo im HKR- 

System; 

Übergabe der 

Vormerknummer 

aus HKR an 

Informationsobjekt 

Bestellung 

Anschreiben und 

Auftrag 

Hochladen des IO Bestellung, 

Sichtkontrolle durch SB HH, 

falls erforderlich Kosten-stelle/-träger 

erfassen 

Verfügbare Mittel zu Kostenstelle /träger 

anzeigen und mit Prüfungsdatum 

im IO Bestellung speichern 

Auswahlmenue Prüfvermerk mit: "Mittel 

Verfügbar" und "Mittel erschöpft" 

falls Prüfergebnis "negativ", 

automatisches hochladen des E-Forms 

"Negativmitteilung" 

Übernahme des Prüfergebnisses 

inklusive Metadaten in das E-Form 

Funktionen: Kommentar einfügen, 

speichern, drucken, weiterleiten 

Falls Prüfergebnis "positiv" 

automatisches hochladen der HKR- 

System Bearbeitungsmaske zur 

Erfassung der Vorkontierung. Das HKR- 

System vergibt automatisch eine ID zur 

Vorkontierung ("Vormerknummer") 

manuelle oder automatische 

Übernahme der Vormerknummer in 

das IO-Bestellung 

Funktionen: Vorkontierung erfassen, 

speichern, bearbeiten; 

Vormerknummer importieren, 

Bestellung speichern, drucken, 

weiterleiten 

Auswahlmenue: "Bestellung 

freigegeben" (muss!) 

Anzeige/Hochladen der freigegebenen 

Bestellung, 

Hochladen der Dokumentenvorlage 

"Auftrag/Bestellung", automatische 

Übernahme aller relevanten Daten aus 

IO Bestellung in Dokumentenvorlage 

"Auftrag/Bestellung" 

Funktionen: Vorlage öffnen, Daten 

importieren, Dokument signieren, 

Dokument speichern, PDF/Agenerieren, 

PDF/A speichern, 

Dokument drucken, Dokument als Mail- 

Anhang versenden 

Hochladen der Dokumentenvorlage 

"Anschreiben/Bestell-Auftrag" 

Funktionen: Vorlage öffnen, 

Adressdaten Lieferant importieren, 

Einfügen von Textbausteinen, 

manuelles Ergänzen von 

Textbausteinen, Dokument signieren, 

Dokument speichern, PDF/Agenerieren, 

PDF/A speichern, 

Dokument drucken, Dokument als Mail- 

Anhang versenden 

Abbildung 41: Prozessfunktionstabelle „Bestellprozess“ 

Workflow Bestellung 

HKR-System 


HKR-System 


HKR-System 


Outputmanagement 

System 

Eigenentwicklung 

HKR-GmbH 


HKR-GmbH 


HKR-GmbH 


Eigenentwicklung


Modellierungshinweise zum Workflowmodell 

Nachdem Sie die oben genannten fünf vorbereitenden Arbeitsschritte erledigt haben, können 

Sie mit der grafischen Modellierung des Workflows beginnen. Den in der Prozessfunktionsta- 

belle (Abbildung 41) zu unserem Beispielprozess skizzierten Workflow finden Sie in der Abbil- 

dungen 42 als grafisches Modell. 

Legen Sie für jede Rolle und das Workflowmanagementsystem (WFMS) jeweils einen 

Pool an. Die oberen Pools werden den Rollen, der untere dem WFMS zugeordnet. 

Nur die Aktivitäten, die dem Pool des WFMS zugeordnet werden, sind maschinell aus- 

führbar, die Aktivitäten in den Pools der Rollen werden von den Systembenutzern ab- 

gearbeitet, sie stellen Mensch-Maschine Interaktionen dar. 

Beginnen Sie nun damit, die Aktivitäten und Bearbeitungsfunktionen aus der Prozess- 

funktionstabelle als „Flussdiagramm“ über alle Pools zu modellieren. 

Modellieren Sie den „Dialog“ zwischen Mensch und Maschine jeweils mit zwei simulta- 

nen Arbeitsschritten: eine Aktivität im Pool des Bearbeiters repräsentiert seine Tätigkeit 

und eine simultane Aktivtät im Pool des WFMS repräsentiert die Funktion der Maschine. 

Der Dialog („senden und empfangen“) kann nun als Nachrichtenfluss zwischen den si- 

multanen Aktivitäten dargestellt werden. Tragen Sie die dabei ausgetauschten Informa- 

tionsobjekte im Nachrichtenfluss ein. Die im Dialog von der Maschine bereitgestellten 

Bearbeitungsmasken oder Vorlagen werden grafisch als „E-Dokument“ symbolisiert, die 

vom Menschen erfassten Daten als „Datenobjekt“. Diese Informationsobjekte können 

nun anhand der Vorlage „Beschreibung Informationsobjekt“ (siehe Abbildung 40) weiter 

spezifiziert werden. 

Eine Besonderheit besteht in der Modellierung von „Prozessverzweigungen“ und „Prozess- 

schleifen“. Maschinen können nur eindeutige Informationen verarbeiten. Dies bedeutet, dass 

„Oder-Gateways“ nicht zulässig sind und in eindeutige „Und“- bzw. „Entweder Oder“-Gateways 

aufgelöst werden müssen. Das Fachmodell (Abbildung 36) enthält eine Prozessschleife (Akti- 

vität 3); die Schleife kann nur beendet werden, wenn am zweiten XOR-Gateway „Rückfrage“ 

die Information „Nein“ vorliegt. Dieses Problem kann dadurch gelöst werden, dass der Bestel- 

ler bei der Aktivität 2 „Bedarfsmeldung prüfen“ durch eine Eingabe den „Zustand“ der einge- 

gangenen Bedarfsmeldung klassifiziert. Dies wurde in der Prozessfunktionstabelle (Abbildung 

41) durch die IT-Bearbeitungsfunktion „Auswahlmenü Prüfvermerk“ dokumentiert. 

Die vom WFMS für die Prozessdurchführung benötigten ITServices wurden unterhalb des für 

die WFMS-Aktivitäten reservierten Pools in dem blau gefärbten Bereich „ITServices“ darge- 

stellt.


Abbildung 42: Workflowdiagramm „Bestellprozess“ (1 / 2)


Abbildung 42: Workflowdiagramm "Bestellprozess" (2 / 2) 

2.5.6 Fachkonzept Schnittstellen 

Bei der Entwicklung elektronischer Geschäftsabläufe ist die Integration von kommunalen 

Fachanwendungen in maschinell ausführbare Workflows von herausragender Bedeutung. 

Dies kann technisch durch die Entwicklung von Schnittstellen oder sogenannten „Web- 

Services“ erfolgen. Zur Spezifikation der fachlichen Anforderungen an eine Schnittstelle sind 

mindestens die in der folgenden „Vorlage Schnittstellenbeschreibung“ enthaltenen Informatio- 

nen erforderlich. Die Abbildung 43 zeigt die im Projekt „Praxisleitfaden“ durch Mitarbeiter der 

Stadt Bochum erarbeitete Beschreibung einer Schnittstelle zur Abfrage von Daten zum ALG2- 

Leistungsbezug im Zusammenhang mit der Festsetzung von KiTa-Elternbeiträgen. 


Damit keine datenschutzrechtlichen Bestimmungen verletzt werden, sollten Sie in jedem 

Falle recherchieren, auf welcher gesetzlichen Grundlage der Austausch bzw. die Erhe- 

bung von Daten durchgeführt werden soll. Zu klären ist, ob das Einverständnis des Da- 

teneigentümers dazu erforderlich ist.


1 Name der Schnittstelle: 

2 

3 

4 

5 

6 

7 

8 

Rechtsgrundlage und Vorschriften für 

die Erhebung der Daten (Datenschutz) 

Ist das Einverständnis des Dateneigentümers nach dem Gesetz über 

informationelle Selbstbestimmung erforderlich? 

Welche Informationen werden 

zurückerwartet? 

Was soll geschehen, wenn die 

Informationen nicht verfügbar sind? 

Abbildung 43: Vorlage Schnittstellenbeschreibung 

* 

*Die Datenabfrage soll generell nur mit Zustimmung des 

Dateneigentümers erfolgen 

Falls JA; Wie wird das Einverständnis Im Rahmen der jährlichen rückwirkenden Einkommensüberprüfung der Beitragspflichtigen wird auf die Möglichkeit der 

Einverständniserklärung zur Datenabfrage hingewiesen und das entsprechende Formular beigefügt. 

erklärt? 

Der Vordruck ist vom Bezieher an das Jugendamt zurückzusenden. Die Erklärung wird zur Beitragsakte genommen. 

Dem Transferleistungsträger soll die Zustimmung nicht übermittelt werden. Hier ist es ausreichend, dass durch das Jugendamt 

erklärt wird, dass die Zustimmung vorliegt. (Es ist geplant zukünftig die Zustimmung zur Datenabfrage auch über eine 

Web-Schnittstelle im Rahmen einer Portal-Lösung "Elternbeiträge" zu ermöglichen). 

Worin liegt der Nutzen der Schnittstelle für den Prozess "Elternbeiträge" festsetzen? 

Die Eltern sind nach den o.g. Vorschriften verpflichtet ihr Einkommen zu erklären (Dies gilt auch für 

Transferleistungsempfänger. 

Diese sind bisher nicht grundsätzlich von der Zahlung von Elternbeiträgen befreit sondern müssen ihr Einkommen durch 

Vorlegen 

der Leistungsbescheide nachweisen). Dem wird aber nicht immer ohne mehrmalige Aufforderung nachgekommen. Der Grund 

hierfür 

dürfte darin liegen, dass die entsprechenden Leistungsbescheide für das zurückliegende Beitragsjahr den Beitragspflichtigen nicht 

mehr vorliegen so dass diese nicht ohne Weiteres beigebracht werden können. Den erfolglosen mehrmaligen Aufforderungen zur 

Einkommenserklärung folgt i. d. R. die Festsetzung des Höchstbetrages mit Mahnverfahren und schließlich der Beitreibung der 

ausstehenden Beiträge. Hierdurch wird ein erheblicher aber überflüssiger Verwaltungsaufwand der Stadtverwaltung generiert. 

Der Datenabruf der Leistungsbescheid-Daten stellt in diesem Fall eine einfache und schnelle Lösung für Beitragspflichtige 

Transferleitstungsbezieher da, ihrer MItwirklungspflicht nachzukommen. 

Sonstige Anforderungen an die 

Schnittstelle 

Vorlage Schnittstellenbeschreibung 


Dabenabfrage "Bezug von Arbeitslosengeld II" 

GTK, SGB VIII, SBG XII und KiBiz NRW i.V.m § 90 Abs. 1 SGB VIII und § 23 Abs.1 KiBiz NRW i.V.m § 4 der Satzung über die 

Erhebung von Elternbeiträgen für die Inanspruchnahme der im Stadtgebiet bestehenden Tageseinrichtungen für Kinder und 

der Inanspruchnahme der Kindertagespflege (Elternbeitragssatzung), erlassen aufgrund der §§ 7 und 41 der Gemeindeordnung 

für das Land Nordrhein-Westfalen (GO NRW) in der Fassung der Bekanntmachung vom 14.07.1994 (GV NRW S.666/ SGV 

NRW 2023) und der §§ 2, 4 und 6 des Kommunalabgabengesetzes für das Land Nordrhein-Westfalen (KAG NRW) vom 

21.10.1969 (GV NRW S. 712/ SGV NRW 610) 

Welche Informationen werden an die Information 1 

Schnittstelle übergeben? (eindeutig) 

optional: Aktenzeichen 

Information 2 

Name 

Information 3 

Vorname 

Information 4 

Geburtsdatum 

Information 5 Information 6 

Adresse (Straße, Aktenzeichen 

der Einzelfall-Akte der 

Hausnummer, Akte 

Arge zum ALG II 

Postleitzahl) Elternbeiträge 

Information 1 

(eindeutig) Information 2 Information 3 Information 4 Information 5 Information 6 

Aktenzeichen Akte Name Vorname Adresse (Straße, Höhe der Höhe und 

Elternbeiträge 

Hausnummer, monatlichen Zusammen- 

Postleitzahl) Hilfe 

setzung des 

angerechneten 

Einkommens 

Information 7 

Alternativ: Gesamter Bescheid als Datenstruktur/PDF übermitteln 

Alternativ: lediglich ALG-Bezug und Bewilligungszeitraum ausgeben (Konsequenz für Prozess: 

Bewilligungszeitraum 

Beitragsbefreiung über Satzung regeln) 

Meldung über Fehlanzeige ausgeben 

Weitere Anforderungen an die Schnittstelle: 

- Mindestanforderung ist die Zusendung der Bescheiddaten, z.B. die benötigten Bescheide als PDF - durch eine zentrale Stelle 

der Transferleistungsträger. (Eine Einzelanforderung bei dem jeweils für den Einzelfall zuständigen Sachbearbeiter generiert 

auf 

beiden Seiten zuviel Aufwand und ist damit in der Umsetzung nicht erfolgversprechend.) 

Diese Variante wäre eine asynchrone Schnittstelle, bei der der Sachbearbeiter Elternbeiträge den Vorgang zurückstellen muss, 

bis die Antwort durch den Transferleistungsträger erfolgt ist. (=höhere Prozessdurchlaufzeit). Im Prinzip wäre auch eine 

Sammelanfrage (Stapelverarbeitung) zu einem bestimmten Stichtag des Jahres möglich. 

- Optimallösung wäre ein "echter" Fachservice, der als Web-Schnittstelle umgesetzt ist. 

Die Datenabfrage kann in diesem Fall durch Berechtigte direkt aus dem Bearbeitungsprozess Online erfolgen, die Antwort 

erfolgt 

unmittelbar über einen Prozess, der auf Seite des Transferleistungsträgeres automatisiert abläuft. Hierbei handelt es sich um 

eine 

synchrone Lösung, die sicher auch von anderen Behörden genutzt werden kann (Gerichte , Polizei etc.) und die Sachbearbeitung


2.5.7 Fachkonzept Ausgangsbearbeitung 

Unter dem Begriff der Ausgangsbearbeitung („Outputmanagement“) fassen wir mehr als ledig- 

lich den Druck und die Verteilung bzw. den Versand von Ausgangsdokumenten der Ge- 

schäftsprozesse an ihre Adressaten zusammen. Auch wenn der Versand von gedrucktem 

Papier ohne Zweifel auch zukünftig einen hohen Stellenwert im Bereich der Ausgangsbearbei- 

tung haben wird, müssen auch heute schon weitere Ausgangskanäle, wie etwa: Fax, E-Mail, 

DE-Mail / E-Postbrief und E-Government Portale sowie die parallele Übergabe der Ausgangs- 

dokumente in Dokumentenmanagement- oder Archivsysteme in eine ganzheitliche Konzeption 

der Dokumentenlogistik einbezogen werden. Die Implementierung eines Outputmanagement 

bietet erhebliche Kosteneinsparpotenziale. Die aus dem Druckbereich bekannten „klassi- 

schen“ Kostenbetrachtungen, wie etwa TCO („Total Cost of Ownership“ 29 ) oder CPP („Costs 

per Page“ 30 ) werden dabei dem Sachverhalt allerdings bei weitem nicht gerecht, besteht doch 

der Löwenanteil an den Kosten bei der Betrachtung der Dokumentenausgangsbearbeitung 

aus Arbeitskosten der Mitarbeiter. Optimierungsansätze setzen schon im Bereich der Doku- 

mentenerstellung an und bestehen grundsätzlich in folgenden Strategien: 

A. Der Verlagerung dezentraler Druckvorgänge („Lokaldruck am Arbeitsplatz“) in zentrale 

Drucksysteme bzw. Verfahren (Optimierung Printmedien und Prozesse) 

B. Der konsequenten Ausstattung von Rücklaufdokumenten mit geeigneten Metadaten, 

z.B. durch das Aufbringen eines Barcode, damit diese bei der Digitalisierung im Postein- 

gang möglichst maschinell dem zuständigen Bearbeiter zugeordnet und elektronisch zu- 

gestellt werden können (Optimierung Printmedien und Prozesse) 

C. Der Verlagerung hausinterner Zustellungsvorgänge in das Medium E-Mail oder 

Workflowmanagementsystem (Migration von Print zu E-Medien) 

D. Der Verlagerung eines möglichst großen Anteils der klassischen Postausgänge an ex- 

terne Adressaten in den Segmenten G2C, G2B, G2G in elektronische Medien (siehe o- 

ben) (Migration von Print zu E-Medien) 

Die Verfolgung und Umsetzung der oben genannten grundsätzlichen Optimierungsansätze 

muss durch ein Bündel organisatorischer, technologischer und kommunikativer Maßnahmen 

geschehen. Um konkrete Optimierungsansätze, zum Beispiel für einen bestimmten Ge- 

schäftsprozess sichtbar zu machen, den „richtigen Maßnahmen Mix“ zur Einführung eines 

prozessorientierten Outputmanagements zu finden, ist es zunächst erforderlich, eine Be- 

standsaufnahme der Ausgangsdokumente und Medien vorzunehmen und dabei wichtige Do- 

kumenten- Merkmale und Strukturen zu erfassen. Die folgende Vorlage (siehe Abbildung 44) 

unterstützt Sie bei der Erfassung der relevanten Daten und Informationen. Eine konkrete 

Maßnahmenplanung ist ohne detaillierte Analyse der technologischen Voraussetzungen und 

Rahmenbedingungen nicht machbar, dies ist allerdings nicht Gegenstand dieses Praxisleitfa- 

dens. 

29 „TCO“ ist ein Kostenrechnungsverfahren bei Investitionsgütern, bei dem nicht nur die Anschaffungskosten, sondern 

auch alle mit der Anschaffung und Nutzung verbundenen Folgekosten berücksichtigt werden. 

30 „(Druck-) Kosten pro Seite“.



Es ist sehr wichtig, alle Ausgangsdokumententypen eines Geschäftsprozesses in die 

Analyse einzubeziehen 

In Spalte 4 „Dateiformat“ ist das Ursprungsformat des Dokuments in der erstellenden An- 

wendung gefragt. Es kann sich dabei um ein „Rohdatenformat“, z.B. ASCII 31 , oder 

CSV 32 -Dateien oder XML 33 -strukturierte Dateien oder aber bereits „vordefinierte“ fertige 

Dokumente mit entsprechenden Layout und CD 34 -Informationen handeln, die zum Bei- 

spiel als Word oder als PDF-Datei vom Quellsystem bereitgestellt werden. 

Die Spalten 5 und 6 beziehen sich auf die dem Dokument, bzw. der Ausgangsdatei vom 

erstellenden System mitgegebenen Metadaten, etwa: Ersteller, Aktenzeichen, Adressat, 

Dokumententyp usw., die für eine weitere Steuerung der Outputmanagementprozesse 

und der Dokumentenlogistik sehr wichtig sind. 

Spalte 7 „persönliche Zustellung“ ist besonders für Verwaltungsdokumente wichtig. Wenn 

hier ein JA erscheint, bedeutet dies, dass ein Zustellnachweis erforderlich ist. Dies 

schließt bestimmte postalische Versandarten und bestimmte E-Ausgangsmedien für die- 

se Dokumente aus. 

Spalte 8 „Beilagen“ bezieht sich zum Beispiel auf Zahlscheine/Überweisungsvordrucke, 

Prospekte und sonstige Beilagen einer Sendung, die besondere Anforderungen an das 

Druckverfahren, die Konfektionierung und Kuvertierung einer Sendung stellen können 

Spalte 9 „Rücklaufdokument“: typische Rücklaufdokumente sind zum Beispiel Anhö- 

rungsbögen, Postzustellungsurkunden, aber auch Formulardownloads, die vom Kunden 

gedruckt, ausgefüllt und dann an die Kommune verschickt werden. Um eine effiziente 

Eingangsbearbeitung zu ermöglichen, sollten solche Dokumente und Vorlagen grund- 

sätzlich mit barcodierten Metadaten versehen werden, die eine maschinelle Verarbei- 

tung, Sortierung und elektronische Zustellung des „Rückläufers“ unterstützen. 

Mengenangaben: die Mengenangabe „Individualdruck“ in Spalte 14 bezieht sich auf die 

Angabe zur Jahresoutputmenge in Spalte 11. 

Angaben zu Adressaten (Spalten 15-20): die genaue Erfassung der Adressatenstruktur 

eines Dokumententyps würde den Rahmen einer „Tabelle“ leider sprengen; Insofern 

können Sie hier lediglich eine grobe Segmentierung der Zielgruppe und eine Erfassung 

der Mehrfachadressaten (Spalte 19 und 20) vornehmen. Es lohnt sich aber an dieser 

Stelle sehr genau darüber nachzudenken, ob und wie welche Adressatengruppen über 

elektronische Medien erreicht werden können und welche technischen, organisatori- 

schen und kommunikativen Voraussetzungen dazu geschaffen werden müssten. Dazu 

31 ASCII = American Standard Code for Information Interchange. Der Zeichensatz entspricht weitgehend der Tastatur 

einer Schreibmaschine, enthält aber nur sehr wenige Text-Formatierungsinformationen. 

32 CSV = Comma-separated Values; einfaches Dateiformat zur Darstellung von Texten oder Tabelleninhalten.So können 

zum Beispiel Excel-Tabellen als CSV-Datei gespeichert und weiterverarbeitet werden. 

33 XML = Extensible Markup Language; ist eine sogenannte „Auszeichnungssprache“ zur Darstellung hierarchisch 

strukturierter Daten. Dabei werden die dargestellten Datenobjekte in menschenlesbarer Form beschrieben 

(„ausgezeichnet“). 

34 CD = Corporate Design.


kann es erforderlich sein, ein wesentlich detaillierteres „Profil“ von Zielgruppen mit 

Migrationspotenzial und eine genaue Übersicht aller Kontaktsituationen zu diesen Ziel- 

gruppen zu erstellen, um einzuschätzen, ob hier Chancen bestehen, diese Adressaten 

für die Nutzung der im Vergleich zu Print-basierten Medien wesentlich kostengünstige- 

ren elektronischer Kommunikationskanäle zu gewinnen. 

Erfassung der Ist-Situation bei den Ausgangsmedien / Kanälen: Vermerken Sie in den 

Spalten 21/22, ob das Ausgangsdokument entweder in Papierform (Sp. 21) oder in e- 

lektronischer Form (Sp. 22) archiviert werden muss. Schätzen Sie zusätzlich den Anteil 

(%) der in den Spalten 23-31 genannten sonstigen Ausgangsmedien an der Gesamt- 

menge in Spalte 11. Erweitern Sie die Tabelle ggfs. um einen Block „Ausgangsmedien 

Anteil Soll“, um Ziele für das zukünftige Outputmanagement zu definieren und zu doku- 

mentieren 

Werten Sie die Ergebnisse ihrer Bestandsaufnahme aus, indem Sie die Relevanz der 

oben unter den „grundsätzliche Optimierungsansätzen“ genannten Punkte A bis D für 

„Ihren“ Prozess bestimmen.


Vorlage Outputanalyse 


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 

Name Geschäftsprozess: 

Druckvarianten Adressaten Ausgangskanal: Anteil IST in % 

Portal 

Zustellserver VPS 

E-Postbrief 

DE-Mail 

E-Mail 

FAX 

Boten 

Hauspost 

Post 

DMS / E-Ablage 

Mehrfachkontakten? 

Name 

Meta- 

Beilagen 

davon Zyklus davon 

Ausgangs- Papier Datei daten? 

zur Rücklauf- Menge MassenMassenIndividual- Nr. Dokument Format Format (J/N) Metadaten Typ Sendung? Dokument? pro jahr druckdruckdruck G2C G2B G2G intern Bemerkung 

Aktenz. 

Mehrfachtäter, 

1 Bußgeldbescheid A4 Word JA Kassenz. tw. Zahlschein PZU, tw. Nein 60000 40000 wöchentlich 20000 X X JA FuhrparkUN 100 100 

Aktenz. 

Mehrfachtäter, 

2 Anhörungsbogen A4 Word JA Kassenz. nein Zahlschein JA JA 45000 30000 wöchentlich 15000 X X JA FuhrparkUN 100 100 

Nachforderung 

3 Unterlagen A4 Word JA AZ nein nein nein nein 5000 5000 X X X Nein 100 98 2 

4 

persönl. 

Barcode? 

Empfänger mit 

Ablage / Akte / Archiv 

Zustellung? 

Abbildung 44: Vorlage Outputanalyse

88 3. Hinweise zum Veränderungsmanagement 

3. Hinweise zum Veränderungsmanagement 

E-Government und Prozessoptimierungsprojekte führen zwangsläufig zu Veränderungen in 

der Ablauf- und Aufbauorganisation der Verwaltung. Jede Organisation reagiert auf Verände- 

rungen zunächst mit Beharrungsvermögen oder gar Widerstand. Dies ist zunächst nichts ne- 

gatives, werden Organisationen doch mit dem Ziel geschaffen „stabil“ zu sein und selbst unter 

widrigen Umständen zu „funktionieren“. Dies bedeutet: Organisationen verfügen über eine 

inhärente Fähigkeit zur Selbststabilisierung durch Standardisierung, Regeln und Routinen und 

durch die „Kultivierung“ von Gewohnheiten und Ritualen. Veränderungen in der Organisation 

entstehen deshalb in der Regel nicht aus innerem Antrieb, sondern nur durch Veränderungs- 

druck von außen. Veränderungen „stören“ den gewohnten Ablauf, werden sie persistent, kann 

dies zu Konflikten und Auseinandersetzungen zwischen den Beteiligten und Betroffenen füh- 

ren. Dabei werden die „Mechanismen“ zur Stabilisierung und zur Veränderung durch formelle 

und informelle Kommunikationsprozesse vermittelt und wirksam. Daraus folgt, dass Verände- 

rung in der Organisation nur durch erfolgreiche Kommunikation und gezielte Interventionen 

erreicht werden können. Die Erfolgschancen steigen, wenn sich Kommunikation und Interven- 

tion dabei an wieder erkennbaren Mustern orientieren, die an Vertrautes anschließen. 

Die folgenden „Hinweise“ zum Veränderungsmanagement orientieren sich an mittlerweile all- 

gemein anerkannten Methoden und Vorgehensmodellen aus dem Umfeld der systemischen 

Organisationsberatung. Zielsetzung dabei ist es, die bisher vorgestellten, eher auf die analyti- 

sche Klärung fachlicher und technologischer Sachverhalte ausgerichteten Methoden, in einen 

übergeordneten Rahmen zur Planung und Gestaltung von Veränderungsprojekten einzuord- 

nen. Die praktische Erfahrung zeigt, dass die Bedeutung einer sorgfältigen Vorbereitung und 

die Beherrschung von Methoden und Techniken zur Steuerung von Veränderungsprojekten in 

der öffentlichen Verwaltung nicht hoch genug eingeschätzt werden kann. 

3.1 Rahmenbedingungen und Grundsätze 

Veränderungsprojekte im Kommunen müssen die spezifischen Rahmenbedingungen und das 

soziokulturelle Umfeld der kommunalen Verwaltung berücksichtigen: 

Veränderungsvorhaben benötigen eine sichtbare Unterstützung durch Politik und Ver- 

waltungsführung. Projektzielsetzungen müssen deshalb anschlussfähig sein an die ü- 

bergeordneten, standort- und finanzpolitischen Ziele der Kommune. 

Der demografische Wandel in der Gesellschaft, aber auch in der Mitarbeiterschaft der 

Verwaltung, erzwingen einerseits eine „Rationalisierung“ der Verwaltungsabläufe und 

eröffnen zugleich ein Handlungsfenster für eine sozialverträgliche Gestaltung des Wan- 

dels. 

Veränderungsprozesse bringen nicht nur Vorteile, sie verursachen auch Aufwand und 

Kosten. Dieser Sachverhalt darf in der Kommunikation von Projektzielen und Nutzen 

nicht verschwiegen werden. Der Projektnutzen muss nachvollziehbar nachgewiesen 

und überzeugend kommuniziert werden. 

In Veränderungsprozessen sollten die Interessen der Organisation und nicht die Interes- 

sen der Mitarbeiter im Mittelpunkt stehen. Es kann für eine Institution, die im öffentlichen 

Auftrag handelt und mit Mitteln der öffentlichen Hand finanziert wird, nicht darum gehen,


eine „gerechte“ Organisation zum Wohle ihrer Mitarbeiter zu schaffen; stattdessen sollte 

eine möglichst effektive und effiziente Organisation der Aufgabenwahrnehmung Ziel sein. 

Insofern darf „Partizipation“ der Mitarbeiter in Veränderungsprozessen nicht mit „Basis- 

demokratie“ verwechselt werden. Veränderungsprozesse zielen auf die Umgestaltung 

von Arbeitssituationen, Arbeitsmitteln und Arbeitsbedingungen. Sie orientieren sich am 

Kontext und nicht am Subjekt der Verwaltungsarbeit. Vor diesem Hintergrund bedeutet 

„Partizipation“ die Chance und die Aufforderung an die Mitarbeiter das Neue aktiv und 

konstruktiv mit zu gestalten, sie verfolgt nicht das Ziel, subjektive Motivationsprobleme zu 

lösen. 

Im Hinblick auf die „Veränderungsbereitschaft“ betroffener Mitarbeiter darf angenommen 

werden, dass in der kommunalen Verwaltung, wie in anderen Organisationen auch, das 

Gesetz der Gaußschen Normalverteilung gilt. Dies bedeutet: etwa 15% der Betroffenen 

sind grundsätzlich aufgeschlossen für Veränderungen, etwa 70% der Betroffenen verhal- 

ten sich neutral und abwartend und etwa 15% verhalten sich grundsätzlich ablehnend 

gegenüber Veränderungen. Schenken Sie der Gruppe der Ablehnenden nicht zu viel 

Aufmerksamkeit. Fokussieren Sie ihre Anstrengungen und Ressourcen darauf, die 

Gruppen der aufgeschlossenen und neutralen Mitarbeiter für den Veränderungsprozess 

zu gewinnen und zu befähigen. Nur die Gruppe der „Neutralen“ kann überhaupt gewon- 

nen werden. Die Mitglieder der Gruppe der „Aufgeschlossenen“ werden schon aufgrund 

ihrer persönlichen Prädisposition die Rolle von „Multiplikatoren“ im Veränderungsprozess 

annehmen. Die „Gaußsche Normalverteilung“ gilt übrigens für alle Phasen des Verände- 

rungsprozesses, deshalb sollten Sie nicht überrascht sein, wenn nach dem Projektab- 

schluss wiederum ein bestimmter Prozentsatz der Beteiligten, das erreichte Ergebnis 

„kritisch“ beurteilt. 

Die Ankündigung von anstehenden Veränderungsprozessen löst nicht selten Sorgen und 

Ängste bei den betroffenen Mitarbeitern aus. Dies fördert die Entstehung von Konflikten 

und teilweise heftigen emotionalen Reaktionen. Führungskräfte, die es gewohnt sind in 

„stabiler Umgebung“ und in der Tradition des „kooperativen Führungsstils“ zu arbeiten, 

geraten in dieser Situation sehr schnell in Rollenkonflikte zwischen den Extremen „Ko- 

operation“ und „Konfrontation“. Es kann deshalb sehr hilfreich und „entlastend“ sein, 

wenn zumindest in der Startphase des Veränderungsprojekts die Rolle des „Change 

Agents“ bzw. Initiators der Veränderung von einem Außenstehenden wahrgenommen 

wird. 

3.2 Das Phasenmodell der Veränderung 

Das in Abbildung 45 dargestellte „Drei Phasen Modell der Veränderung“ stammt aus der sozi- 

alpsychologischen Forschung zu Veränderungsprozessen in sozialen Gruppen. Es wurde von 

Kurt Lewin bereits in den vierziger Jahren des 20ten Jahrhunderts entwickelt und hat sich als 

einfaches Schema zur Strukturierung gruppendynamischer Veränderungsprozesse durchge- 

setzt.


einfrieren 

Abbildung 45: „Drei-Phasen-Modell“ der Veränderung 

Die drei Phasen: „Auftauen“, „Verändern“ und „Einfrieren“ bilden einen Rahmen zur Planung 

und Durchführung von Veränderungsprozessen in Organisationen. In der folgenden Abbildung 

46 werden die Aufgaben und Arbeitsschwerpunkte in den drei Phasen in allgemeingültiger 

Form skizziert. Wir haben dabei die beiden Handlungsebenen „Changemanagement“ und 

„Projektmanagement“ unterschieden, um die in unserem Praxisleitfaden behandelten Aufga- 

ben und Fragestellungen besser in den Projekt-Designrahmen des Veränderungsmanage- 

ments einordnen zu können. Dies bedeutet aber nicht, dass wir der Auffassung Vorschub leis- 

ten möchten, es handele sich hier um zwei getrennte Handlungsfelder oder Bereiche! Selbst- 

verständlich müssen in der Praxis die Ziele und Aufgaben des Veränderungsmanagements 

mit denen des „operativen“ Projektmanagements eng verzahnt und synchronisiert werden. Die 

praktische Erfahrung zeigt, dass sehr viele Projekte eben daran scheitern, dass dies nicht in 

ausreichendem Maße geschieht. Umgekehrt macht der Sachverhalt deutlich, dass ein erhebli- 

cher Qualifikationsbedarf zu Methoden und Führungskompetenzen in Veränderungsprojekten 

besteht, da „klassische“ Projektmanagementmethodiken dazu tendieren, ein eher „technokra- 

tisches“ Verständnis zum Management von Projekten und Projektrisiken zu propagieren, wel- 

ches die sogenannten „weichen“ Faktoren entweder ganz ausblendet, als „Kommunikations- 

probleme“ verniedlicht oder schlicht in die Verantwortung der „Führung“ „wegdelegiert“, um 

sich sogleich auf das Terrain des „Projektmanagements“ zurück zu ziehen. Als ein wesentli- 

cher Erfolgsfaktor hat sich ein mit dem „Projektmanagement“ eng verzahntes „Changemana- 

gement“ durch dafür qualifizierte Mitarbeiter oder ggf. externe Berater erwiesen. 

Eine umfassende Darstellung der Methoden und Techniken in allen Phasen des Verände- 

rungsprozesses würde den Rahmen dieses Praxisleitfadens sprengen, deshalb sei an dieser 

Stelle auf die umfangreiche Fachliteratur zum Thema „Change Management“ verwiesen. 35 

35 Zum Beispiel: Schäfer, Frank: Kommunales Change Management, Berlin 2011oder Namokel, Herbert / Dieter Rös- 

ner: Change Management. Lexikon, Düsseldorf 2010. 

Neue Struktur 

Alte Struktur 

Veränderungs- 

Management 

verändern 

auftauen


Change- 

Management 

Projekt- 

Management 

Abbildung 46: Inhalte und Aufgaben im "Drei Phasen Modell" 

3.3 Prozessorientiertes Veränderungsmanagement 

Im Unterschied zu „breit angelegten“, auf die Veränderung der gesamten Organisation zielen- 

den Veränderungsprojekten, lag dem Vorgehen im Kontext unseres Projektes eine andere 

Strategie zugrunde, die wir „prozessorientierte Veränderung“ genannt haben und aus verschie- 

denen Gründen gerne zur Nachahmung empfehlen möchten. Die Vorteile dieser Vorgehens- 

weise liegen unseres Erachtens auf der Hand: 

Prozessorientierte Veränderungsprojekte sind „politisch“ leichter durchzusetzen, die ge- 

plante Veränderung ist begrenzt und löst somit weniger Vorbehalte, Widerstände und 

Ängste aus. 

In jeder Kommune existieren „notleidende“ Aufgabenbereiche, die aufgrund äußerer oder 

interner Faktoren dringend einer Reformierung und Optimierung bedürfen. 

Im Rahmen der Studie Effizientes E-Government wurden bereits ca. 200 bis 300 kommu- 

nale Kernprozesse mit E-Government Potenzial und Standardisierungspotenzial identifi- 

ziert, deren Optimierung mit großer Wahrscheinlichkeit zu „zählbaren“ Erfolgen führen 

wird. 

„Auftauen“ „Verändern“ „Einfrieren“ 

• Kontaktaufbau zu Führungskräften • Implementierung des 

und Mitarbeitern Change-Projektteams im Fachbereich 

• Einbeziehung der Personalvertretung • Vereinbarungen zur Projektstruktur, 

• Strategieworkshops: gemeinsames Kommunikation und Dokumentation 

Verständnis zu Auslöser und Zielen • Implementierung von 

• Qualifikationsmaßnahmen FüKr Schnittstellenzirkeln und KVP-Teams 

zu Grundlagen und Methodik • Zielvereinbarungen zu Maßnahmen 

• Erste Mitarbeiterworkshops zur 

Umsetzung 

Information und Einbindung • Begleitung der Maßnahmen- 

• Erste Situationsanalyse und Umsetzung durch Coaching und 

Sensibilisierung 

„Training on the Job“ 

• Überprüfung von Lernerfolg • Überprüfung der erwarteten 

bei Methodik und 

Verhaltensänderungen 

Führungskompetenzen 

und Zielvereinbarungen 

• Implementierung des Projektteams 

IST-Analyse und Sollkonzeption 

• Erarbeitung des Soll-Konzepts 

• Diskussion des Sollkonzepts 

in Mitarbeiterworkshops 

• Beschluss Stufenkonzept Umsetzung 

• Feinkonzeption der ersten 

Umsetzungsstufe(-n) 

• Schaffung der i-technischen 

Voraussetzungen 

• Pilotierung und AW-Test Technik 

• Einführung Sollprozess und Technik 

• kontinuierliche Verbesserung 

der Soll-Arbeitsabläufe 

• Change Request Management 

• Pflege der Prozessdokumentation 

Ein in einem überschaubaren Zeitrahmen und erfolgreich abgeschlossenes Verände- 

rungsprojekt im Bereich eines Kerngeschäftsprozesses zeigt auf, dass „Veränderung 

machbar“ ist und positive Ergebnisse erzielt werden können. 

• Qualifikationsmaßnahmen zur 

Vertiefung von Methoden- und 

Führungskompetenzen 

• Coaching und Moderation zur 

Anwendung der 

Steuerungsinstrumente 

• Projektabschluss 

• Abschluss von Dienstvereinbarungen 

und Dienstanweisungen 

zum Sollprozess 

• Publikation der Projektergebnisse 

• Monitoring der 

Prozessdurchführung im 

Rahmen des GPM 

Die im Rahmen der prozessorientierten Veränderung gewonnenen Erfahrungen können 

als Blaupause für die Veränderung und Optimierung weiterer Kernprozesse dienen. 

Die im Praxisleitfaden behandelten Themen sind aus der Sicht des Veränderungsmanage- 

ments samt und sonders der Projektphase „Auftauen“ zuzuordnen. Deshalb möchten wir im


Folgenden auf praxisrelevante Aspekte zum prozessorientierten Veränderungsmanagement in 

dieser Phase eingehen: 

Der ausgewählte Prozess sollte ausreichendes Optimierungspotenzial bieten 

Nutzen Sie dazu unsere „Checkliste Prozessoptimierung“ und die Ergebnisse der Studie 

„Effizientes E-Government“ 

Bereits beim Kontaktaufbau zu den prozessverantwortlichen Führungskräften des Fach- 

bereichs sollte ein gemeinsames Verständnis zu Auslösern, Zielen und Optimierungs- 

ansätzen des Veränderungsprojekts erzielt werden („KO-Kriterium“) 

Nutzen Sie das standardisierte Soll-Modell des Prozesses aus der Prozessbibliothek als 

„Checkliste“ bzw. Diskussionsgrundlage, um eine erste Einschätzung zur IST-Situation 

des in Frage kommenden Prozesses und über die Einschätzung und das Urteilsvermö- 

gen der Führungskräfte dazu zu erhalten. 

Beteiligen Sie frühzeitig ihre IT-Experten, um zu erfahren, ob der geplante Optimie- 

rungsansatz mit vorhandenen technischen Mitteln umsetzbar, oder ob eine Investition 

erforderlich ist. 

Stellen Sie frühzeitig fest, inwieweit die Personalvertretung zu informieren oder zu betei- 

ligen ist und leiten Sie entsprechende Maßnahmen ein. 

Beziehen Sie die Führungskräfte und ausgewählte Fachkräfte in die Durchführung des 

Soll-Ist-Vergleichs ein (Workshop). Geben Sie dabei den erforderlichen theoretischen 

und methodischen Input, um die Mitarbeiter und Führungskräfte über die zur Optimie- 

rung in Betracht kommenden Technologien und Organisationsprinzipien und ihre Zu- 

sammenhänge zu informieren. Nutzen Sie dabei die „Leitfragen zum Soll-Ist-Vergleich 

Organisation“ (siehe Abbildung 16) als Checkliste und Moderationsleitfaden. 

Entwickeln Sie, entsprechend zu der Anzahl der ermittelten Optimierungsansätze ein 

schlüssiges Stufenkonzept nach dem Prinzip der „kleinen Pyramiden“. 

Wenn sich dabei alternative Umsetzungspfade ergeben, lassen Sie den Fachbereich 

darüber entscheiden, wie die Umsetzungsstufen zu priorisieren sind. Wenn nicht, erläu- 

tern Sie überzeugend, warum es nur einen Umsetzungspfad gibt. 

Entwickeln Sie zügig das technische und organisatorische Umsetzungskonzept (Fein- 

konzept) zur ersten Umsetzungsstufe. 

Fordern Sie parallel dazu die Ausarbeitung des Changemanagement-Konzepts zur Pilo- 

tierung und Einführung des Soll-Prozesses durch Führungskräfte und ausgewählte Mit- 

arbeiter des Fachbereichs ein. Unterstützen Sie dabei bei Bedarf durch fachliche und 

methodische Inputs. 

E-Government und IT-getriebene Prozessoptimierungsprojekte führen zu erheblichen 

Veränderungen der IT-Unterstützung der Prozesse und damit zu einer veränderten Ar- 

beitsumgebung für die Mitarbeiter. Dies führt in der Regel dazu, dass zum Teil über vie- 

le Jahre eingeübte Arbeitsroutinen wegfallen oder stark verändert werden müssen, da- 

mit die erwünschte Produktivitätssteigerung eintritt. Die Mitarbeiter werden zwar im Zu- 

ge der Produktivsetzung neuer Anwendungen in der Nutzung der neuen IT-Anwendung


geschult, aber in der Regel mit der Anpassung ihrer Arbeitsroutinen auf der „Mikro- 

Ebene“ alleine gelassen. 

Darüber hinaus dürfen Sie keineswegs voraussetzen, dass alle Mitarbeiter über eine aus- 

reichende Medien- und IT-Anwenderkompetenz verfügen, um den erforderlichen Trans- 

fer dramatisch erweiterter IT-Funktionen in der Arbeitsumgebung auf die Entwicklung 

angemessener Arbeitsroutinen ohne Hilfestellung, ausreichende praktische Einübung 

und ohne Transferkontrolle am Arbeitsplatz zu leisten. 

Es wäre auch nicht Ziel führend, die Entwicklung angemessener Nutzungsroutinen dem 

Zufall, bzw. der Kreativität und der IT-Kompetenz der Mitarbeiter zu überlassen, da sich 

alsbald zahlreiche individuelle Abweichungen in der Arbeitsweise einschleichen würden. 

Diesem Sachverhalt sollten Sie, zum Beispiel durch geeignete Testverfahren zur Feststel- 

lung der aktuell vorhandenen Anwenderkompetenz und durch entsprechend ausgestalte- 

te Qualifizierungsmaßnahmen, Training on the Job und Qualitätszirkel der Mitarbeiter zur 

„kontinuierlichen Verbesserung“ der Arbeitsroutinen im Rahmen des Veränderungsma- 

nagements Rechnung tragen. 

Wir empfehlen Ihnen einen „Maßnahmenplan Veränderungsmanagement“ zu erstellen, der das 

„Stufenkonzept“ (siehe Kapitel C. Stufenkonzept) zur Umsetzung der geplanten Lösung er- 

gänzt und aus dem klar hervorgeht, welche Projekt begleitenden Aktivitäten im Veränderungs- 

management in welcher Umsetzungsstufe durchgeführt werden. Der Maßnahmenplan zum 

Veränderungsmanagement enthält die vier Handlungsebenen: „Kommunikation“, „Qualifizie- 

rung“, „Einbindung“ und „Vereinbarung“. Berücksichtigen Sie bei ihrer Planung, dass alle Hand- 

lungsebenen in jeder Phase des Veränderungsprozesses und in jeder Umsetzungsstufe ihres 

Sollkonzepts mit Inhalt zu füllen sind, um ein schlüssiges und nachhaltiges Konzept zum Ver- 

änderungsmanagement zu erstellen! Nutzen Sie zur Entwicklung ihrer „Change-Konzeption“ 

das in der folgenden Abbildung dargestellte Planungsschema: 

Maßnahmeplan 

Veränderungsmanagement 

Initialisierung Umsetzung 

Stufe 1 

Handlungsebene Maßnahmen 

Kommunikation 

Qualifizierung 

Einbindung 

Vereinbarung 

Umsetzung 

Stufe 2 

Abbildung 47: Planungsschema Veränderungsmanagement 

Umsetzung 

Stufe x 

Wir wünschen Ihnen nun viel Erfolg bei der Anwendung des Praxisleitfadens in ihrer Kommune! 

Harald Schumacher Dezember 2010 

Gunter Rückziegel 

b.i.t.consult GmbH 

Seeheim

Praxisleitfaden für den Einsatz standardisierter Soll ... - d-NRW

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?