IT-Prozessmanagement einer Sicherheitsbehörde am Beispiel eines IT-Großprojekts Mai, André; Kozanecki, Fanny, Teuber, Anne ZKA Bergisch Gladbacher Straße 827 51069 Köln [email protected]

Abstract: Prozesse in IT-Großprojekten sind aufgrund der innewohnenden Sparzwänge von Pragmatik gekennzeichnet. Der Beitrag beschreibt vor diesem Hintergrund das Prozessmanagement in einem IT-Großprojekt einer Sicherheitsbehörde. Ausgangspunkt der Beschreibung ist ein ProzessmanagementVerständnis, in dem die Beziehungen zwischen Prozessen. Die Prozesse werden nach Projekt-, Betriebs- und Verwaltungsprozessen unterteilt und hinsichtlich ihrer Dokumentationsformen, In- und Outputs sowie relevanter Steuerungsgrößen vorgestellt. Im Vergleich mit den Referenzmodellen ITIL und COBIT wird die Vollständigkeit der Prozesse des IT-Großprojekts geprüft und Gründe für Abweichungen gesucht. Es ist festzustellen, dass die Managementbereiche von ITIL gut abgedeckt sind. Die COBIT-Domäne MONITOR AND EVALUATE ist nur unzureichend umgesetzt. Das widerspricht der zentralen Bedeutung der Controlling- und Berichtsprozesse. Daher wird in einem Ausblick weiterer Untersuchungs- und Handlungsbedarf formuliert.

1 Einleitung 1.1 Begriff Prozessmanagement und Einordnung des Beitrags Prozessmanagement ist seit mehreren Jahren in Produktionsund Dienstleistungsunternehmen etabliert ([HaCh95], [Sche98] m. w. N.). Auch die öffentliche Verwaltung folgt diesem Trend, der mit dem Neuen Steuerungsmodell der KGSt. manifestiert wurde [KGSt93]. Über den Begriff des Prozessmanagement besteht noch keine einheitliche Vorstellung. Becker, Mathas et. al. stellen die Prozessdokumentation und -gestaltung mit Hilfe von Prozessmodellen in den Vordergrund [BMW09, S. 3]. Fischermans versteht darunter ein „auf Dauer ausgerichtetes Konzept von Vorgehensweisen, Verantwortlichkeiten, ITUnterstützungen und kulturflankierenden Maßnahmen, um eine effektive und effiziente

706

Prozessorganisation im Unternehmen gewährleisten zu können.“ [Fisc06, S. 26]. Scheer und Jost fordern ein erneutes „Process-Re-Engineering“, um die mit „Web-Enabling“ vorgenommenen A n f ä n g e im E-Business durch SCM-, CRM- oder ERP-Projekte f o r t z u f ü h r e n [ScJo02, S. 34]. Dieser Beitrag folgt einem ProzessmanagementBegriff, bei dem die Identifikation, Dokumentation und Steuerung von Prozessen im Vordergrund steht. Hinsichtlich des Management-Aspekts folgt das Prozessmanagement dem Demingkreis [Demi00, S. 88], der in 4 Phasen den organisatorischen Grundprinzipien Planen, Umsetzen/Testen, Prüfen und Handeln folgt. Der Beitrag erläutert die Prozesse im IT-Großprojekt. Abschnitt 1.2 stellt die Projektsituation und die Behörde vor. Danach werden die Rahmenbedingungen beschrieben, denen Behörden unterliegen (Abschnitt 1.3). Kapitel 2 präsentiert die im Projekt enthaltenen Prozesse (Abschnitt 2.1). Hauptgegenstand des Beitrags ist die Frage, ob die im IT-Großprojekt enthaltenen Prozesse vollständig sind. Um einen Eindruck darüber zu erhalten, werden sie mit den Standards von IT Infrastructure Library (ITIL) (Abschnitt 2.2.1) und Standard Control Objectives for Information and related Technology (COBIT) (Abschnitt 2.2.2) verglichen.1 In einem Ausblick (Kapitel 3) werden die Erfahrungen und Änderungspotenziale der Prozesse im Projekt zusammengefasst. Er stellt somit eine Fallstudie als qualitative und verhaltensorientierte Forschungsmethode dar (vgl. [BSSK08, S. 74], [HeSi80, S. 294]). 1.2 Projektsituation Das hier vorgestellte IT-Großprojekt INZOLL hat zur Aufgabe, das vom Zollkriminalamt (ZKA) „zu unterhaltende“ Zollfahndungsinformationssystem gemäß § 3 Abs. 3 ZFdG neu- bzw. weiter zu entwickeln. Das IT-Verfahren INZOLL wird daher im Gegensatz zu vielen anderen IT-Projekten mit einem gesetzlichen Auftrag entwickelt. Das ZKA ist eine Mittelbehörde im Geschäftsbereich des Bundesministeriums der Finanzen (BMF). Im Projektauftrag wurde vorgegeben, das Projekt mit einem externen Auftragnehmer zu entwickeln. Im Jahr 2006 erfolgte die Produktivnahme der ersten Ausbaustufe. Derzeit befindet sich das Projekt in der zweiten Ausbaustufe, in der Schnittstellen zu externen IT-Verfahren geschaffen werden. Neben der Weiterentwicklung ist auch der Betrieb zu gewährleisten Das Großprojekt zeichnet sich durch eine hohe Komplexität, begründet in umfangreichen (Fach-)Anforderungen, einem großen Kreis an Beteiligten sowie einer insgesamt langen Projektlaufzeit, aus. Die am Projekt Beteiligten können nach ZKAintern und extern unterschieden werden. Das BMF stellt den bedeutendsten externen Beteiligter. Es ist Auftraggeber des Projekts und Budgetgeber. Darüber hinaus werden von dort Regelungen für die Projektabläufe und ITStandards definiert. Der externe Auftragnehmer, der die Weiterentwicklung des IT-Verfahrens 1

Auf die Beschreibung der Auswahl der Frameworks wurde aus Platzgründen verzichtet.

707

übernimmt, stellt einen weiteren wichtigen Beteiligten dar. Die zukünftigen Schnittstellenpartnerbilden den dritten Partner auf der Entwicklungsseite. Stellvertretend für die Gruppe der Benutzer stehen die acht Zollfahndungsämter, die nach dem Zollfahndungsdienstgesetz Aufgaben zur Verhütung und Vorsorge von Straftaten wahrnehmen (§§ 24, 25 ZFdG).

Die Projektgruppe gliedert sich in Anlehnung an das V-Modell 97 [BD93] in die Submodelle SE, QS, KM und PM. Für den Betrieb von INZOLL wurden mit der Verfahrensbetreuung (VB) und der Systembetreuung (SB) zwei weitere Submodelle definiert. 1.3 Compliance-Standards in Behörden Das Aufstellen und Einhalten von Regelungen ist ein Behörden immanentes Vorgehen. Auch wenn für den Compliance-Begriff ebenso wenig eine allgemein anerkannte Definition existiert, wie für den Begriff Prozessmanagement ([KBGSS, Suche: Compliance]), deckt die Begriffserläuterung im Deutschen Corporate Governance Kodex das Handeln einer Behörde analog mit ab. Die Definition lautet: „Der Vorstand hat für die Einhaltung der gesetzlichen Bestimmungen und der unternehmensinternen Richtlinien zu sorgen und wirkt auf deren Beachtung durch die Konzernunternehmen hin (Compliance).“ [BMJ10, Ziff. 4.1.3]. Verwaltungen sind als Organe der Exekutive (vgl. [Mont86]) den Gesetzen unterworfen (Vorbehalt und Vorrang von Gesetzen, abgeleitet aus Art. 20 Abs. 3 GG). Somit sind sie in noch stärkerem Maße Regelungen und Standards unterworfen als Unternehmen. Zu den internen Aufgaben einer Behörde zählen: Haushaltswesen, Beschaffungen, Personalangelegenheiten, Organisation. Das Haushaltswesen folgt dem parlamentarisch gesteuerten Etatprinzip (Art. 110 GG). Im Haushaltsplan werden alle Einnahmen und Ausgaben eingestellt, worunter auch alle Finanzierungsleistungen für IT-Projekte fallen. Für den wirtschaftlichen Einsatz von Haushaltsmitteln und zur Korruptionspräventation unterliegen alle Behörden dem Vergaberecht (§ 97 Abs. 1 GWB). Damit einher geht die Einhaltung der Vergabegrundsätze Transparenz, Wettbewerb, Gleichbehandlung bzw. Diskriminierungsverbot (vgl. § 97Abs. 2 GWB, § 2 VOL/A, [UfAB, S. 15]). Neben allgemeinen verwaltungsinternen Regelungen greifen die Grundsätze des Datenschutzes und der IT-Sicherheit. Datenschutzregelungen sind im Bundesdatenschutzgesetz zu finden. Für den Zollfahndungsdienst enthalten darüber hinaus die Strafprozessordnung und das Zollfahndungsdienstgesetz weitergehende Einschränkungen des technisch Möglichen. Die Sicherheitsanforderungen für IT-Systeme im Geschäftsbereich des Bundesfinanzministeriums sind in einer Vewaltungsvorschrift zur IT-Sicherheit (VV BMF-IT Sicherheit) beschrieben. Sie orientieren sich, wie für alle Bundesbehörden, an den Standards des Bundesamts für Sicherheit in der Informationstechnik [BSIStandards]. Hierzu zählen neben den Grundschutzkatalogen [BSI-GS-Kataloge]

708

weitergehende Regelungen zum Management von Informationssicherheit und dem Notfallmanagement. Als Vorgehensmodell gilt für IT-Projekte in Bundesbehörden das V-Modell XT sowie sein Vorgänger V-Modell 97 (zum V-Modell 97 [BD93], zum V-Modell XT [VMXT]). Während das V-Modell 97 sich an festen Submodellen orientierte [Vers00, S. 19], bietet das V-Modell XT deutlich mehr Flexibilität hinsichtlich der enthaltenen Aktivitäten, Rollen und Produkte [VMXT, Teil 3 – V-Modell-Referenz Tailoring]. Da das V-Modell keine für den Betrieb von IT-Systemen notwendige Aktivitäten enthält, sind die Betriebsprozesse im Projekt INZOLL an anderen Standards angelehnt. ITIL definiert Prozesse, die über das reine Projektgeschehen hinausgehen und – wie in der Definition des Prozessmanagements von Fischermans – „auf Dauer“ angelegt sind [Fisc06, S. 26]. Den Einsatz von ITIL in der öffentlichen Verwaltung beschreibt das IT Service Management Forum [ITSMF07]. Für die Dokumentation von Prozessen existieren keine vorgegebenen Standards. Das Feinkonzept des Projekts Strukturentwicklung Zoll orientiert sich an ARIS und den darin verwendeten Wertschöpfungsketten bzw. ereignisgesteuerten Prozessketten (dazu [Sche98]). Daneben hat das ZKA ausgewählte Prozesse mit dem Werkzeug ADOit [JKSK00] modelliert. Mit der PICTURE-Methode [BKP09] steht seit kurzem ein weiterer, übersichtlicher Modellierungsansatz zur Verfügung. Im Projekt wird die Prozessdokumentation als wichtig angesehen. Die Abbildungsmethoden schwanken jedoch abhängig vom Zweck der Dokumentation und dem Leserkreis.

2 Prozesse im Projekt 2.1 Überblick über die IT-Prozesse Wie unter 1.2 aufgeführt, wurden die Projektorganisation im IT-Projekt INZOLL anhand des V-Modells 97 und der ITIL-Version 1 definiert. Die Prozesse lassen sich grob in folgende Kategorien einteilen: Projektprozesse, Betriebsprozesse, Verwaltungsprozesse. In den Abschnitten 2.1.1 bis 2.1.3 werden die in den Kategorien enthaltenen Prozesse aufgeführt und beschrieben. Neben der Prozessbezeichnung und den verantwortlichen Rollen werden In- und Outputinformationen sowie zentrale Steuerungsgrößen angegeben. Die Beschreibung erfolgt anhand einer Black-Box-Sicht auf Prozesse [HaCh95, S. 22], [Fisc06, S. 12]. 2.1.1 Projektprozesse Die Projektprozesse wurden nach den Submodellen der Projektorganisation gruppiert. Sie enthalten die Aufgaben, die während der Projektlaufzeit angefallen sind. Da ein Softwareentwicklungsprojekt untersucht wird, fallen darunter vorwiegend Softwareentwicklungsaufgaben.

709

Projektmanagement Jedes größere Projekt benötigt Projektmanagementaktivitäten (dazu [Litk07, S. 19]). Prozessbezeichnung (Verantwortlich) Projektplanung (Projektleiter)

Prozessdokumentation vertragliche Regelungen, Projekthandbuch Prozessbeschreibung

Vertragsmanagement (Projektleiter) Nachfrage (Projektleiter) Controlling ((Teil-)Projektleiter)

vertragliche Regelungen Projektauftrag

Berichtswesen ((Teil-)Projektleiter)

Projektauftrag

Risikomanagement (Projektrisikomanager)

Risikomanagementkonzept

Input

Output

Projektziele, Teilprojekte

Projektplan

Antrag auf Vertragsänderung Nachfrage

geänderte Vertragskonfiguration

Finanz-, Termin-, Planungsdaten Sachstände, Projektfortschritt Projektinformationen

Steuerungsgrößen, Kennzahlen Meilensteine, Ressourcen

beantwortete Nachfrage Bewertung der Daten im Hinblick auf die Projektziele Information über Projektstand

Umfang der Vertragsdokumentation, Anzahl Änderungsanträge eingegangene NF, offene NF Budget (geplant, verfügbar, Ausgaben), Termine Berichtstermine, Berichtsarten

Risiken mit Eintrittswahrscheinlichkeiten und Schadenspotenzialen

Anzahl der potenziellen Risiken, Schadensereignisse, Umfang der entstandenen Schäden

Tabelle 1 Überblick über Prozesse des Projektmanagements

In chronologischer Folge beginnen die Projektmanagementprozesse mit Projektplanungsprozessen. Projekt und Teilprojekte werden nach vergleichbaren Mustern konzipiert, beauftragt, überwacht und gesteuert. An der Schnittstelle zum externen Auftragnehmer muss das Vertragsmanagement dafür Sorge tragen, dass die Vereinbarungen, die der Ausschreibung zu Grunde lagen, dokumentiert sind. Außerdem werden sämtliche Änderungen an den Dokumenten einem Änderungsprozess unterworfen, an dem auch Rechtsverantwortliche beteiligt sind. Der Nachfrageprozess dient der nachvollziehbaren inhaltlichen Auseinandersetzung mit Fragen oder Widersprüchen in den Anforderungsprodukten, Prozessen oder vertraglichen Regelungen. Er ist als Statusübergangsmodell definiert. Controlling und Berichtswesen beschäftigen sich mit den Informationspflichten der Projektmitarbeiter gegenüber den Teilprojektleitern, Submodellverantwortlichen und dem Projektleiter sowie den Berichtspflichten des Projektleiters gegenüber seinen Auftraggebern. Sie sind weitestgehend in die Projektplanungsprozesse integriert, da jeder Projektauftrag Aussagen über die anzufertigenden Berichte trifft. Berichtsinhalte sind regelmäßig auch Risikobetrachtungen, die das Risikomanagement zusammenführt. Systemerstellung Die Systemerstellung eines Projekts mit Auftraggeber-/Auftragnehmerschnittstelle beschränkt die Aufgaben der Systemerstellung auf folgende Prozesse:

710

Prozessbezeichnung (Verantwortlich) Anforderungsmanagement (SE-Verantwortlicher)

Prozessdokumentation Wertschöpfungskettendiagramm mit textueller Prozessbeschreibung, vertragliche Regelungen

Input

Output

Informationen über geplante Schnittstellen

Anforderungsprodukte

fachliches Change Management (SE-Verantwortlicher)

vertragliche Regelungen

Änderungsanträge

geänderte Anforderungsprodukte

Steuerungsgrößen, Kennzahlen Anzahl der geplanten Schnittstellen, Anzahl der Anforderungsprodu kte Anzahl der Änderungsanträge

Tabelle 2 Überblick über Prozesse der Systemerstellung

Das Anforderungsmanagement beschäftigt sich mit der Identifikation und Dokumentation der Anforderungen an die Software. Die Anforderungen werden mit Hilfe von UML-Modellen, Anwendungsfallbeschreibungen, Maskenskizzen und anderen Anforderungsprodukten an den Auftragnehmer übergeben. Der Auftragnehmer realisiert daraufhin die entsprechenden Software-Funktionen. Das Anforderungsmanagement wird Release bezogen geplant und folgt einem iterativen Vorgehen (zum Begriff der Iteration vgl. bspw. [VMXT, Glossar Iteration]. Während der einzelnen Abschnitte werden – bezogen auf die jeweilige Schnittstelle – die Benutzersicht, die Datensicht, die Schnittstellensicht und die technische Sicht definiert. Im so genannten fachlichen Change Management werden Änderungsanforderungen bearbeitet, die während der Entwicklung der Software oder im Betrieb entstanden sind. Da die Analyse der Änderungsanforderungen während einer der Iterationen erfolgt, stellt das fachliche Change Management eine Alternative des AnforderungsmanagementProzesses dar. Qualitätssicherung Aufgabe der Qualitätssicherung ist die Prüfung der gelieferten Software [VMXT, Baustein Prüfung]. Der globale Prüfauftrag stellt die Frage, ob der Auftragnehmer alle Anforderungen vollständig und fehlerfrei umgesetzt hat. Die damit verbundenen Prozesse sind: Prozessbezeichnung

Prozessdokumentation vertragliche Regelungen

Input

Output

SoftwareRelease

Fehlermanagement (QS-Verantwortliche)

für Auftragnehmer: vertragliche Regelungen für Projektgruppe: Leitfaden

SoftwareFehler

Integrationstest (QS-Verantwortliche)

Vereinbarung mit Schnittstellenpartner

abgenommenes Release

Testbericht, Abnahmeerklärung dokumentierter SoftwareFehler, behobener SoftwareFehler getestete Schnittstelle

Abnahme (QS-Verantwortliche)

Steuerungsgrößen, Kennzahlen Anzahl offener Fehler, Anzahl neuer Fehler, Fehlerbereinigungsrelease für Auftragnehmer: vertragliche Regelungen für Projektgruppe: Leitfaden

Vereinbarung mit Schnittstellenpartner

Tabelle 3 Überblick über Prozesse der Qualitätssicherung

711

Der Abnahmeprozess folgt den werkvertraglichen Pflichten und prüft durch Testkonzepte, Testfälle und ähnliche Prüfdokumente den geschuldeten Erfolg. Zur Abstimmung, Bewertung, Diskussion und Verfolgung dieser Mängel, die in ITSystemen als Fehler bezeichnet werden,2 dient der Fehlermanagementprozess. In ihm werden sämtliche Fehler erfasst, die dem Auftragnehmer zu melden sind. Aus der vertraglich festgelegten Klassifikation ergeben sich die Reaktions- und Wiederherstellungszeiten, an denen der Auftragnehmer gemessen wird. Wegen der in der zweiten Ausbaustufe zu entwickelnden Schnittstellen gewinnt der Integrationstest eine besondere Bedeutung (vgl. [KBGSS, Begriff Integrationstest]). Neben der Planung der gemeinsamen Schnittstellentests sind vor und während der Testdurchführung umfangreiche Abstimmungen mit den Schnittstellenpartnern vorzunehmen, die im Prozess zum Integrationstest dokumentiert werden. Konfigurationsmanagement Das Konfigurationsmanagement zerfällt im Projekt INZOLL in vier Aufgabenteile: Prozessbezeichnung

Prozessdokumentation

Input

Output

betriebliches Change Management (Change Manager) Build- und DeploymentManagement (Release Manager) Release Management (Release Manager)

vertragliche Regelungen für Auftragnehmer und interner Leitfaden vertragliche Regelungen

Request for Change

erledigter Auftrag

Steuerungsgrößen, Kennzahlen Anzahl RfCs, Anzahl offener RfCs

Software-Lieferung

Build, installierte Instanzen

Anzahl Lieferungen, betroffene Schichten, Anzahl Instanzen

vertragliche Regelungen

Anforderungsprodukte

ReleasePlanung

Configuration Management (Config Manager)

vertragliche Regelungen für Auftragnehmer und interner Leitfaden

Configuration Item (Dokumente, Quellcode-Dateien)

Konfiguration

Umfang der Änderungen, Termine Anzahl der Konfigurationen, Art und Umfang

Tabelle 4 Überblick über Prozesse des Konfigurationsmanagements

Ziel der KM-Prozesse ist die Aufrechterhaltung einer widerspruchsfreien Leistungs-, Vertrags- und Lieferungskonfiguration sowie ausreichendes Informieren aller Projektbeteiligten. Die Prozesse des betrieblichen Änderungsmanagements folgen dem Schema eines ITSupports. Sämtlicher Änderungsbedarf an Systemen, Software oder Hardware ist mittels Request for Change (RfC) anzuzeigen. Nach werkzeugbasierter Abstimmung in der Projektgruppe löst der Change Manager die Änderungsaufträge (Order for Change) aus. Das Build- und Deployment-Management ist eine Teilmenge des betrieblichen Änderungsmanagements, bei dem Aktivitäten zum Erstellen (Build) bzw. Verteilen (Deployment) der Software ausgeführt werden. Die Steuerung erfolgt ebenfalls über RfC. 2 zur Abgrenzung zwischen Fehler und Mangel-Begriff vgl. bspw. Hinweise zum EVB-IT-Systemvertrag unter http://www.cio.bund.de

712

Das Release Management stellt sicher, dass die Lieferungen dem vertraglich vereinbarten Stand entsprechen und alle INZOLL-Instanzen mit der gewünschten INZOLL-Version ausgestattet werden. Der Release Management-Prozess schließt sich an den Prozess der Systemerstellung an und definiert die Einzelheiten der Lieferung. Darüber hinaus stellt er im Betrieb sicher, dass behobene Fehler schnellstmöglich ausgeliefert werden können. Aufgabe des Configuration Managements ist die Aufrechterhaltung einer konsistenten Leistungsbeschreibungs-, Vertrags- und Softwarestruktur. Die Aufgaben des Konfigurationsmanagements fallen über das Projektende ahinausn, während des Betriebs an. Die Zuordnung zu den Projektprozessen erfolgte wegen der Zuordnung der Aufgaben zum Submodell KM des V-Modell 97 [BD93] und der überwiegend im Projekt anfallenden Arbeiten. 2.1.2 Betriebsprozesse Betriebsprozesse in INZOLL werden in Administrations- und IT-Betriebsprozesse unterschieden. Administrationsprozesse erfolgen via Masken aus INZOLL . Prozessbezeichnung (Verantwortlich)

Prozessdokumentation Input

Output

Vorlagenerstellung (VB-Verantwortlicher)

Verfahrensanweisung INZOLL, Prozessmodell in ADOit Verfahrensanweisung INZOLL, Prozessmodell in ADOit Verfahrensanweisung INZOLL, Prozessmodell in ADOit

neue/ geänderte Vorlage geänderter Katalog

Katalogpflege (VB-Verantwortlicher) Benutzerverwaltung (VB-Verantwortlicher)

Antrag auf neue/ geänderte Vorlage Antrag auf neuen Katalog(-wert)

Steuerungsgrößen, Kennzahlen Änderungsaufträge, Anzahl Vorlagen Änderungsaufträge, Anzahl Katalog(-wert)e

Antrag auf Änderung neue der BenutzerBenutzerinformationen bzw. informationen -berechtigungen

Änderungsaufträge, Anzahl Benutzer

Tabelle 5 Überblick über Prozesse der Verfahrensbetreuung

Zur Nachvollziehbarkeit der Änderungen und Vorbeugung von Manipulationen werden sämtliche Änderungen der Verfahrensbetreuung durch einen Auftragsprozess reguliert. Dadurch ist sichergestellt, dass keine unbefugten Änderungen im System vorgenommen werden. Die Prozessdokumentation erfolgt in Prozessmodellen, die mit ADOit modelliert wurden (stellvertretend [JKSK00]). Die IT-Betriebsprozesse im engeren Sinne folgen konzeptionell dem ServiceManagement der ITIL Version 1 [ITSMF07]. Prozessbezeichnung Sicherheitsmanagement (Dokumentationsverantwortlicher) Service Level Management + Service Desk

Prozessdokumentation keine

keine

Input

Output

Sicherheitsanforderung, Infrastruktur Sicherheitsanforderung

dokumentierte und bewertete Infrastruktur Verfügbarkeit

713

Steuerungsgrößen, Kennzahlen Verfügbarkeit, Anzahl Geräte Anzahl Änderungsanträge

Prozessbezeichnung Incident Management

Problem Management

Prozessdokumentation Prozessmodell in ADOit

Input

Output

Störung

Prozessmodell in ADOit

Problem

behobene Störung oder Problem behobenes Problem

Steuerungsgrößen, Kennzahlen Anzahl Störungen, Anzahl Benutzer Anzahl Probleme, Anzahl betroffener Benutzer

Tabelle 6 Überblick über Prozesse der Systembetreuung

Basis für die IT-Betriebsprozesse sind die Sicherheitsanforderungen des ZKA. Aus fachlicher Sicht wurde eine maximal tolerierbare Ausfallzeit von 40 Stunden pro Jahr definiert. Dementsprechend sind Infrastruktur, Service Desk und Service Level Management so aufgebaut, dass plötzliche Ausfälle durch redundant vorgehaltene Maschinen kompensiert werden und die Benutzer rund um die Uhr einen Ansprechpartner haben. Incident und Problem Management beinhalten die Maßnahmen zur Beseitigung von Störungen (Incidents) und komplizierteren Problemen. 2.1.3 Verwaltungsprozesse Verwaltungsprozesse stellen die internen Prozesse der Behörde dar. Prozessbezeichnung (Verantwortlich)

Prozessdokumentation

Input

Output

IT-Rahmenplanung (Projektleiter, -controller)

keine

Bedarf

geplante Finanzmittel

Haushalts-bewirtschaftung (Projektleiter, -controller)

keine (Haushaltsaufstellungsbzw. -führungserlass des BMF) Beschaffungsleitfaden des ZKA

bewilligter Bedarf

Ausgaben

Bedarf

realisierter Bedarf

keine

neue Stelle

keine

offene Stelle

Stellenbeschreibung und -bewertung besetzte Stelle

Beschaffung (Projektleiter, -controller)

organisatorische Zuarbeiten (Projektleiter, -controller) Personalgewinnung (Projektleiter, -controller)

Steuerungsgrößen, Kennzahlen geplante Kosten, geplante Projekte verfügbare Haushaltsmittel, Ausgaben Anzahl geplanter, beantragter und erledigter Beschaffungen Anzahl neuer Stellen Anzahl offener Stellen

Tabelle 7 Überblick über Verwaltungsprozesse

IT-Rahmenplanung und Haushaltsbewirtschaftung sind Finance-Prozesse, der erste in strategischer bzw. planerischer Hinsicht, der zweite hinsichtlich des wirtschaftlichen Einsatzes der Mittel. Der Beschaffungsprozess stellt die vergaberechtlichen Grundlagen sicher.

714

Personalgewinnungsprozesse und die organisatorischen Zuarbeiten beinhalten die organisatorischen Voraussetzungen für Personalgewinnungen (Einrichtung von Dienstposten bzw. Stellen, Tätigkeitsbeschreibung und Stellenbewertung) sowie die eigentlichen Besetzungsverfahren (Stellenausschreibung, Bewerberprüfung, Vorstellungsgespräche, Einstellungen). 2.2 Abgrenzung zu Standardprozessmodellen ITIL stellt ein Referenzmodell für die IT Service Management-Prozesse dar [ITSMF07, S. 17]. Der Betrieb von INZOLL lässt sich unter das IT Service Managements subsummieren. COBIT stellt ebenso wie die ITIL eine Auswahl von „Good Pracitices in Form eines Domänen- und Prozess-Frameworks zur Verfügung“ [COBIT05, S. 6]. Aus diesem Grund wurden die im Projekt INZOLL identifizierten Prozesse mit den beiden Standards verglichen. Ziel des Vergleichs ist eine Abschätzung, welche Prozesse im Projekt umgesetzt wurden. 2.2.1 ITIL Die folgende Tabelle zeigt eine Übersicht über die ITIL-Prozesse in der Version 2 und die Umsetzung durch die Prozesse im Projekt. Zuordnung der Prozesse und Funktionen in der ITIL-Versionen 2 Managementbereich Publikation Financial Management for Service Delivery IT-Services Capacity Management Service Delivery Service Level Management Service Delivery Security Management Security Management IT Service Continuity Service Delivery Management Availability Management Service Delivery Change Management Service Support Configuration Management Service Support Release Management Service Support Deployment Management Service Support Service Desk Service Support Technical Support Operations Application Management Incident Management

ICT Infrastructure Management ICT Infrastructure Management Application Management Service Support

715

im Projekt realisiert durch IT-Rahmenplanung, Haushaltsbewirtschaftung keine Realisierung im Projekt Service Level Managementprozess IT-Sicherheitsmanagement keine Realisierung im Prozess ad-hoc-Implementierung im Projekt betriebliches Change Management Configuration Management Release Management Build- und Deployment Management Service Level Management und Service Desk keine Realisierung im Projekt keine Realisierung im Projekt keine Realisierung im Projekt Incident Management

Zuordnung der Prozesse und Funktionen in der ITIL-Versionen 2 Managementbereich Publikation Problem Management Service Support

im Projekt realisiert durch Problem Management

Tabelle 8 Umsetzung der ITIL-Prozesse (Version 2) im Überblick

Da das Projekt INZOLL nur ein IT-Verfahren umfasst, sind die Application Management, Capacity und IT Service Continuity Prozesse weniger von Relevanz. Availability Management findet bei der Planung von Updates, Deployment-Aktivitäten im Rahmen des Build- und Deployment-Management-Prozesses implizit statt, ohne dass dafür ein Prozess definiert wurde. Technical Support und Operations werden von den Administratoren des Verfahrens ebenso ad hoc übernommen. Alle übrigen ITILProzesse sind durch entsprechende Projekt-Prozesse umgesetzt. 2.2.2 COBIT COBIT ist neben dem ITIL-Standard ebenfalls weit verbreitet (stellvertretend [FrHo09, S. 233], [BKP09, S. 256]). COBIT richtet seinen Fokus in erster Linie auf die Steuerung und Kontrolle auf strategischer Ebene im Sinne eines IT-Alignments und komplementiert somit die von ITIL vorrangig vertretene taktische und operative Sichtweise. So ist es möglich, Prozessmodelle beider Standards innerhalb einer (Projekt) Organisation einzusetzen. Vor dem Hintergrund der durch das ZKA und die ihm unterstellten Zollfahndungsämter zu erfüllenden Aufgaben und der Anforderungen an die IT-Sicherheit treten im Projekt INZOLL die Sicherheitsschutzziele unter den Formalzielen in den Vordergrund. Dazu gehören die Vertraulichkeit, mit dem Ziel lediglich autorisierten Anwendern Informationen zur Verfügung zu stellen, die Integrität der gespeicherten Daten sowie die Einhaltung der Regeln, wie Gesetze und Behördenstandards [Boeh11, S. 8]. Ebenso bedeutungsvoll ist die Sicherstellung der Qualitätsziele Verfügbarkeit und Verlässlichkeit, da in INZOLL eine jährliche Ausfallzeit von maximal 40 Stunden toleriert wird. Um die Wirtschaftlichkeit des Projekts zu gewährleisten sind Effektivität und Effizienz ebenfalls wichtige Formalziele. Im Rahmen dieses Berichts erfolgt eine vergleichende Darstellung über die in 4 Domänen gegliederten 34 COBIT-Prozesse in der Version 4.0 und die Umsetzung durch die Prozesse im Projekt. Zuordnung der Prozesse und Funktionen in der COBIT-Versionen 4.0 DOMÄNE / Prozess PLAN AND ORGANISE PO1 Define a Strategic IT Plan PO2 Define the Information Architecture

PO3 Determine Technological Direction

im Projekt realisiert durch Lenkungsausschussvorlagen und -Sitzungen im Rahmen des Berichtswesen teilweise Realisierung durch das Anforderungsmanagement im Bezug aus das Projekt Lenkungsausschussvorlagen und –Sitzungen

716

Zuordnung der Prozesse und Funktionen in der COBIT-Versionen 4.0 DOMÄNE / Prozess PO4 Define the IT Processes, Organisation and Relationships PO5 Manage the IT Investment PO6 Communicate Management Aims and Direction PO7 Manage IT Human Resources PO8 Manage Quality PO9 Assess and Manage IT Risks PO10 Manage Projects ACQUIRE AND IMPLEMENT AI1 Identify Automated Solutions

AI2 Acquire and Maintain Application Software

AI3 Acquire and Maintain Infrastructure AI4 Enable Operation and Use

Technology

AI5 Procure IT Resources AI6 Manage Changes AI7 Install and Accredit Solutions and Changes

DELIVER AND SUPPORT DS1 Define and Manage Service Levels DS2 Manage Third-party Services DS3 Manage Performance and Capacity DS4 Ensure Continuous Service

DS5 Ensure Systems Security DS6 Identify and Allocate Costs DS7 Educate and Train Users

DS8 Manage Service Desk and Incidents DS9 Manage the Configuration DS10 Manage Problems

im Projekt realisiert durch im Rahmen des Berichtswesen Definition von Projekt-Prozessen (vgl. Abschnitt 2.1) teilweise Realisierung innerhalb der (ITRahmenplanung ad hoc-Regelungen, z. B. bei Lenkungsausschuss-Sitzungen Personalgewinnungsprozesse keine Realisierung im Projekt Risikomanagement-Prozess teilweise Realisierung durch die Arbeit gemäß V-Modell XT teilweise Realisierung durch das Anforderungsmanagement, Untersuchung erfolgte in großem Umfang vor Beginn der Realisierung von INZOLL keine Realisierung im Projekt, jedoch Betrachtung im ZKA im Rahmen der Arbeit der Zentralen Facheinheit keine Realisierung im Projekt analog zu AI2 Verfahrensanweisung, Hilfe, Schulungsangebote IT-Rahmenplanung, Haushaltsbewirtschaftung und Beschaffungsprozesse betriebliches und fachliches Change Management Abnahmeprozess, Integrationstest, Build- und Deployment-Management, Release Management Service Level Management + Service Desk Beschaffungsprozess, Vertragsmanagement teilweise Realisierung in Last-Testverfahren zur Performance-Messung keine Realisierung als Prozess, jedoch Betrachtung im Rahmen der Administrationsaufgaben Sicherheitsmanagement keine Realisierung im Projekt, da keine nutzerspezifischen Abrechnungen erfolgen keine Realisierung im Projekt, sondern außerhalb der Projektgruppe durch das Schulungsreferat Service Desk und Incident Management Configuration Management Problem Management

717

Zuordnung der Prozesse und Funktionen in der COBIT-Versionen 4.0 DOMÄNE / Prozess DS11 Manage Data DS12 Manage the Physical Environment DS13 Manage Operations

MONITOR AND EVALUATE ME1 Monitor and Evaluate IT-Performance

im Projekt realisiert durch nichtfunktionale Anforderungen im Anforderungsmanagement Anforderungsanalyse an Rechenzentrum und Hardware vor Betriebsaufnahme keine Realisierung im Projekt, da ein Zusammenspiel mit anderen Applikationen außerhalb der Schnittstellen nicht erfolgt Einsatz von Überwachungswerkzeugen ohne Prozess-Regularien keine Realisierung im Projekt keine Realisierung im Projekt teilweise Realisierung durch Berichtswesen

ME2 Monitor and Evaluate Internal Control ME3 Ensure Regulatory Compliance ME4 Provide IT-Governance

Tabelle 9 Umsetzung der COBIT-Prozesse (Version 4.0) im Überblick

Die Übersicht zeigt, dass knapp 60 % (= 20) der 34 von COBIT vorgesehen Prozesse im Projekt ein Pendant finden. 15 % der geforderten Regelungen sind zumindest teilweise umgesetzt. Die verbleibenden 12 % (= 9), die nicht umgesetzt sind, umfassen vier Prozesse (AI2, AI3, DS4, DS7), die in anderen Organisationseinheiten des ZKA wahrgenommen werden. zwei Prozesse (DS6, DS13) haben aufgrund der Betrachtung eines einzelnen Projekts keine Relevanz. Die drei Prozesse, die darüber hinaus bisher nicht umgesetzt sind (PO8, ME2, ME3) entfallen neben den QM-Aktivitäten, die bisher vordergründig auf die QS der Leistungen des Auftragnehmers beschränkt wurde, auf Überwachungsprozesse, die momentan nur ungenügend etabliert wurden. Hieraus resultiert Handlungsbedarf.

3 Zusammenfassung und Ausblick Der Vergleich der Projektprozesse mit den Standardwerken ITIL und COBIT zeigt, dass ein Großteil der in den Standards geforderten Prozesse im IT-Großprojekt INZOLL umgesetzt ist. Die Untersuchung zeigt auch, dass für ein einzelnes Projekt nicht alle Prozesse etabliert sein müssen, die in einer kompletten IT-Service-Einheit (im Fall von ITIL) bzw. einem gesamten Unternehmen (im Fall von COBIT) gefordert werden. Insbesondere im Bereich der Verwaltungsprozesse und in den Überwachungs- und Evaluierungsprozessen zeigt sich Verbesserungspotenzial. Die Verwaltungsprozesse sind zurzeit nicht ausreichend dokumentiert. Dies könnte sich grundlegend ändern, da in der Prozesslandkarte des Zolls die Serviceprozesse mit aufgeführt sind [FK07, S. 22]. Es bleibt zu hoffen, dass die Serviceprozesse ebenso wie die Standards der Fachpakete grafisch modelliert und der Steuerung unterworfen werden. Die Prozesse aus der Domäne MONITOR AND EVALUATE des COBIT-Standards wurden nur teilweise im Projekt abgebildet. Diese Erkenntnis widerspricht der in Abschnitt 2.1.1 gewonnenen Erkenntnis, dass gerade Überwachungs- und Berichtsprozesse zentrale Bestandteile der Projektprozesse sind.

718

Der inhaltliche Vergleich der Projektprozesse mit den von COBIT geforderten Aufgabenpaketen stellt nur einen ersten Schritt dar. Im weiteren Projektverlauf ist die Untersuchung der Reifegrade zur Verbesserung der Prozess- und Servicequalität im Projekt INZOLL notwendig.

Literaturverzeichnis [Arms06] Armstrong, Michael: A Handbook of Human Resource Management Practice, Cambridge 2006, University Press, London, 10. Auflage, 2006. [BADN03] Becker, Jörg, Algermissen, Lars, Delfmann, Patrik, Niehaves, Björn: Konstruktion konfigurierbarer Referenzmodelle für die öffentliche Verwaltung in: Dittrich, Klaus, König, Wolfgang, Oberweis, Andreas, Rannenberg, Kai, Wahlster, Wolfgang (Hrsg.): Informatik 2003 – Innovative Informatikanwendungen (Band 1), Bonn 2003, S. 249-253 [BAF09] Becker, Jörg, Algermissen, Lars, Falk, Thorsten: Prozessorientierte Verwaltungsmodernisierung - Prozessmanagement im Zeitalter von E-Government und New Public Management, Berlin, Springer, 2007 [Boeh11] Boehmer, Wolfgang: Über die Anwendung von Sicherheitsmanagement Systemen, Policies und Spieltheorie zur Unternehmensabsicherung, in Heiß, Hans-Ulrich, Pepper, Peter, Schlingloff, Holger, Schneider, Jörg (Hrsg.): INFORMATIK 2011 - Informatik schafft Communities; Beiträge der 41. Jahrestagung der Gesellschaft für Informatik e.V. (GI), GI e. V., Berlin 2011 [BD93] Bröhl, Adolf-Peter, Dröschel Wolfgang (Hrsg.): "Das V-Modell – Der Standard für die Softwareentwicklung mit Praxisleitfaden", München, Oldenbourg 1993. [BKP09] Becker, Jörg, Knackstedt, Ralf, Pöppelbuß, Jens: Entwicklung von Reifegradmodellen für das IT-Management – Vorgehensmodell und praktische Anwendung, in Wirtschaftsinformatik, Heft 3/2009, S. 249-260 [BMJ10] Bundesministerium der Justiz: Bekannmachung des „Deutschen Governance Kodex“, Bundesanzeiger vom 2.7.2010. [BMW09] Becker, Jörg, Mathas, Christoph, Winkelmann, Axel: Geschäftsprozessmanagement. Springer, Berlin 2009, [BRS95] Becker, Jörg, Rosemann, Michael, Schütte, Reinhard: Grundsätze ordnungsmäßiger Modellierung. In: Wirtschaftsinformatik 37 (1995), Nr. 5, S. 435-445. [BSI-GS-Kataloge] IT-Grundschutz-Kataloge des Bundesamtes für Sicherheit in der Informationstechnik https://www.bsi.bund.de/DE/Themen/weitereThemen/ITGrundschutzKataloge/itgrunds chutzkataloge_node.html, zuletzt abgerufen am 28.10.2011 [BSI-Standards] IT-Grundschutz-Standards des Bundesamtes für Sicherheit in der Informationstechnik https://www.bsi.bund.de/ContentBSI/Publikationen/BSI_Standard/it_grundschutzstand ards.html, zuletzt abgerufen am 28.10.2011 [BSSK08] Balzert, Helmut, Schäfer, Christian, Schröder, Marion, Kern, Uwe: Wissenschaftliches Arbeiten – Wissenschaft, Quellen, Artefakte, Organisation, Präsentation, Witten, Herdecke, 2008 [BuKn02] C. Bunse, A. v. Knethen: "Vorgehensmodelle kompakt", Heidelberg, Berlin, Spektrum 2002. [COBIT05] IT Governance Institute: COBIT 4.0 - Control Objectives for Information and related Technology, Deutsche Ausgabe, Rolling Meadows, 2005 [Demi00] Deming, William Edward: Out of the Crisis, MIT Press Edition, Cambridge, MA, 2000.

719

[FeSi01] Ferstl, Otto K., Sinz, Elmar J.: Grundlagen der Wirtschaftsinformatik : Band 1. 4., überarb. und erw. Auflage. München : Oldenbourg, 2001 [Fisc06] Fischermanns, Guido: Praxishandbuch Prozessmanagement, ibo Schriftenreihe, Gießen 2006 [FK07] Bundesministerium der Finanzen: Feinkonzept zum Projekt Strukturentwicklung ZOLL, abgerufen unter: http://www.zoll.de/e0_downloads/wir_ueber_uns/feinkonzept.pdf [FrHo09] Frank, Ulrich, Hofmann, Georg Rainer: IT-Controlling und IT-Produktivität, in Wirtschaftsinformatik, Editorial zum Heft 3/2009, S. 233 [HaCh95] Hammer, Michael, Champy, James: Business Reengineering - Die Radikalkur für das Unternehmen, Campus-Verlag,; Frankfurt 1995 [HeSi80] Herberger, Maximilian, Simon, Dieter: Wissenschaftstheorie für Juristen : Logik, Semiotik, Erfahrungswissenschaften, Frankfurt am Main, Metzner 1980 [ITSMF07] ITSMF: ITIL in der öffentlichen Verwaltung – Planung, Einführung und Steuerung von IT-Service-Prozessen, Symposion Publishing GmbH, Düsseldorf, 2007 [JKSK00] Jungings, S., Kühn, H., Strobl, R., Karagiannis, D.: Ein GeschäftsprozessmanagementWerkzeug der nächsten Generation- Adonis: Konzeption und Anwendung, Wirtschaftinformatik, 5, 2000. [KBGSS] Kurbel, Karl, Becker, Jörg, Gronau, Norbert, Sinz, Elmar, Suhl, Leena: Enzyklopädie der Wirtschaftsinformatik – Online-Lexikom unter http://www.oldenbourg.de:8080/wi-enzyklopaedie, zuletzt abgerufen am 27.10.2011 [KGSt93] KGSt: Neues Steuerungsmodell unter: http://www.kgst.de/themen/organisationsmanagement/organisatorischegrundlagen/neues-steuerungsmodell.dot, zuletzt abgerufen am 27.10.2011 bzw. im Online Verwaltungslexikon http://www.olev.de/n/nsm.htm, zuletzt abgerufen am 28.10.2011 [Litk07] Litke, Hans-Dieter: Projektmanagement : Methoden, Techniken, Verhaltensweisen, evolutionäres Projektmanagement, Hanser, München, 2007. [Mai10] Mai, André: Definition von Services für ein Informationssystem. Beginn einer SOA eines behördlichen IT-Dienstleisters in: Fähnrich, Klaus-Peter, Franczyk, Bogdan: Informatik 2010: Service Science - Neue Perspektiven für die Informatik, Beiträge der 40. Jahrestagung der Gesellschaft für Informatik e.V. (GI), Band 1, 27.09. - 1.10.2010, Leipzig, LNI 2010, S. 353-359 [Mont86] Montesquieu, Charles de: Vom Geist der Gesetze, Reclam, Leipzig, 1986 [Oest04] Oestereich, Bernd: Objektorientierte Softwareentwicklung. Analyse und Design mit der UML 2.0. 3. Auflage, München : Oldenbourg, 2004. [OMG01] OMG: Model Driven Architecture (MDA) http://www.omg.org, cgi-bin, doc?ormsc, 2001-07-01 27.10.2011 - OMG [Part98] Partsch, Helmuth: Requirements-Engineering systematisch : Modellbildung für softwaregestützte Systeme., o. Auflage., Berlin. Springer, 1998. [Rögl10] Röglinger, Maximilian: Verifikation von Webservicekompositionen, in Wirtschaftsinformatik, Bd. 49 (2009), Heft 6, S. 496-505 [Rump05] Rumpe, Bernhard: Agile Modellierung mit UML : Codegenerierung, Testfälle, Refactoring. 1. Auflage. Berlin : Springer, 2005 [Rupp01a] Requirements Engineering und Management, Professionelle, iterative Anforderungsanalyse für die Praxis, Hanser 2001; www.sophist.de [Rupp03] Rupp, Chris: Wie aus Wünschen Anforderungen werden. in: InformationWeek Nr. 22 vom 30. Oktober 2003, S. 24-25 [Sche98] Scheer, August-Wilhelm: ARIS – Vom Geschäftsprozess zum Anwendungssystem, Berlin, Heidelberg, New York, Tokio, Springer 1998. [ScJo02] Scheer, August-Wilhelm, Jost, Wolfram: ARIS in der Praxis, Springer, Berlin, Heidelberg, 2002.

720

[UfAB] [Vers00] [VM] [VMXT]

Unterlag für Ausschreibung und Bewertung von IT-Leistungen, veröffentlicht unter www.cio.bund.de, zuletzt abgerufen am 27.10.2011 Versteegen, Gerhard: Das V-Modell in der Praxis, dpunkt, Heidelberg 2000 ohne: www.vorgehensmodelle.de (Homepage der FG WI-VM), zuletzt abgerufen am 27.10.2011. ohne: http://www.v-modell-xt.de/, zuletzt abgerufen am 27.10.2011.

721