Modellierung interorganisationaler IT-Service ... · tion/Data Model (SID) wurde im Rahmen von eTOM...

PIK, Vol. 13, pp. 291–301, Dezember 2010 � Copyright c� by Walter de Gruyter � Berlin � New York. DOI 10.1515/piko.2010.049

Modellierung interorganisationaler

IT-Service-Managementprozesse

Matthias Hamm

proCon IT AktienGesellschaftWarnslerstr. 981829 Mü[email protected]

Dr. Matthias Hamm ist Diplom-Informatiker und zertifizierter IT-Service-Manager und arbeitet als Projektleiter bei der proCon ITAktienGesellschaft in München. Von 2006–2009 wissenschaft-licher Mitarbeiter am Leibniz-Rechenzentrum in Garching undMitglied des Münchner Netzmanagement (MNM) Teams. Erveröffentlichte zahlreiche Beiträge im Gebiet des IT-Service-Managements in interorganisationalen Organisationen.

Silvia Knittl

IT Service Zentrum TechnischeUniversität MünchenKarlstr. 4580333 Mü[email protected]

Silvia Knittl hat an der Ludwig-Maximilians-Universität (LMU)München Informatik studiert und ist zertifizierte IT-Service-Ma-nagerin. Seit 2006 arbeitet sie an der Technischen UniversitätMünchen im Bereich Identity und Access-Management. Ihr For-schungsschwerpunkt liegt im Bereich Konfigurationsmanagementin föderierten Umgebungen. Seit 2006 ist sie Mitglied im MNMTeam.

Patricia Marcu

Leibniz-RechenzentrumBolzmannstr. 185748 Garching b. Mü[email protected]

Patricia Marcu studierte Informatik an der LMU (Abschluss 2006)und arbeitet seit 2007 als wissenschaftliche Mitarbeiterin am LRZfür das europäische Projekt Géant. Sie arbeitet an der Weiter-entwicklung des CNM (Customer Network Management) Werk-zeuges und an der Visualisierung des LHC (Large Hadron Col-lider) Netzmonitoring. Sie ist zertifizierte IT-Service-Managerin.Der Schwerpunkt ihrer Forschung liegt im interorganisationalenFehlermanagement. Seit 2007 ist sie Mitglied des MNM Teams.

Mark Yampolskiy

Leibniz-RechenzentrumBolzmannstr. 185748 Garching b. Mü[email protected]

Als wissenschaftlicher Mitarbeiter des Leibniz-Rechenzentrumsarbeitet Dr. Mark Yampolskiy für das europäische Géant Projekt.Zu seinen Aufgaben zählt die Konzeption und Entwicklung einesMulti-Domain Netzwerk Monitoring Systems. Studium der Ange-wandten Mathematik an der Technischen Universität Moskau undder Informatik an der TU München (Diplom 2005). Von 1993 bis2006 Tätigkeit als Softwareentwickler in Russland und Deutsch-land. Seit 2006 ist er Mitglied des MNM Teams.

Zusammenfassung

IT-Services werden aufgrund ihrer hohen Komplexität undübergreifenden Vernetzung häufig nicht mehr von einereinzigen Organisation alleine erbracht; die Notwendig-keit für Kooperationen zwischen IT-Service-Providern, auchüber das klassische Outsourcing hinaus, stellt sich im-mer öfter. Dadurch ergeben sich neue Herausforderungenim IT-Management, die von den etablierten IT-Service-Management-Frameworks wie z. B. der IT Infrastrcture Li-brary (ITIL) nicht ausreichend berücksichtigt werden. In die-sem Beitrag stellen wir eine Reihe von Forschungsergebnis-sen des Munich Network Management (MNM) Teams mitdem gemeinsame Ziel der Unterstützung interorganisationa-ler IT-Service-Management(ITSM)-Prozesse vor. Der Beitragzeigt zunächst auf, welche spezifischen Aspekte bereits inder Spezifikationsphase zu berücksichtigen sind und präsen-tiert die neue Methode ITSMCooP zur Modellierung inter-organisationaler Prozesse. Die Anwendung dieser Methodewird an drei ITSM-Prozessen aus Projekten des MNM-Teamsdemonstriert. Dabei werden bereits Anforderungen an ei-ne Werkzeugunterstützung in der späteren Ausführungspha-se abgeleitet. Exemplarisch werden im Anschluss zwei dedi-zierte ITSM-Werkzeuge vorgestellt, die die Kooperation vonProvidern sowohl in technischen als auch organisatorischenAspekten unterstützt.

1 Einführung

Das IT-Service-Management (ITSM) hat sich in den letz-ten Jahren sowohl in der Industrie wie im Hochschulbereichnachhaltig etabliert; ITSM ermöglicht die Erbringung von

- 10.1515/piko.2010.049Downloaded from De Gruyter Online at 09/28/2016 10:04:06PM

via Technische Universität München

mailto:[email protected]




292 Matthias Hamm et al.

Globale Prozessinstanz

…

Globaler Prozess (interorganisational)

Prozess

Lokale

Interoperabilität

ILokaleProzessinstanz

LokaleProzessinstanz

LokaleProzessinstanz

Organisation O1 Organisation O2 Organisation On

Lokale Prozesse (intraorganisational)

Abbildung 1 Struktur interorganisationaler Prozesse.

IT-Diensten im Rahmen definierter Qualitäts- und Kosten-strukturen. Gängige ITSM Frameworks, wie etwa die ITInfrastructure Library (ITIL) [OGC07b], haben dabei eineschwerpunktmäßig auf den Diensterbringer bezogene Per-spektive. In der Zusammenarbeit mit anderen Unternehmenbzw. Organisationen wird eine hierarchische Organisationss-truktur vorausgesetzt, mit dem Kunden an der Spitze derHierarchie, der einen Provider beauftragt; dieser kann wie-derum Sub-Provider mit der Erbringung von Basisdienstenverpflichten.

Kooperationen, d. h. die gemeinsame Erbringung von IT-Diensten durch mehrere unabhängige gleichberechtigte Pro-vider, werden durch Frameworks wie ITIL derzeit nicht ab-gedeckt. In kooperativen, inter-organisationalen Szenarienfällt die Diensterbringung in die Verantwortung mehrererProvider-Organisationen; in diesen Umgebungen werden zu-sammengesetzte, interdependente Dienste angeboten, die ineiner kooperativen Weise erbracht werden (vgl. Abschnitt 3).

Dieser Beitrag präsentiert einen Überblick über eine Reihevon Forschungsergebnissen des Münchner Netzmanagement(MNM) Teams1 mit dem gemeinsamen Ziel der Unterstüt-zung interorganisationaler und kooperativer ITSM-Prozesse.Das MNM-Team engagiert sich seit mehreren Jahren in ei-ner Vielzahl von Forschungs- und Praxis-Projekten, die sichzumeist durch eine große Anzahl von Partnern bzw. zu er-bringenden IT-Diensten auszeichnen. Die dabei untersuchtenFragestellungen reichen von Problemen der Prozess- und In-formationsmodellierung bis hin zu Managementarchitekturenund -systemen.

Der restliche Beitrag ist folgendermaßen struktuiert: ImAbschnitt 2 wird die auf der Prozessmodellierungsspra-

1Das Munich Network Management Team (MNM-Team) unter derLeitung von Prof. Dr. Heinz-Gerd Hegering und Prof. Dr. D. Kranzl-müller ist eine Forschungsgruppe mit Wissenschaftlern an der Ludwig-Maximilians-Universität München (LMU), der Technischen UniversitätMünchen (TUM), dem Leibniz-Rechenzentrum (LRZ) und der Univer-sität der Bundeswehr München (UniBW). Das MNM-Team ist einer derersten deutschen Forschungsgruppen im Bereich IT-Management.

che BPMN (Business Process Modeling Notation) und demITSM-Informationsmodell SID (Shared Information/DataModel) basierenden Methode ITSMCooP zur Modellierunginterorganisationaler ITSM-Prozesse präsentiert. Im folgen-den Abschnitt 3 werden beispielhaft eine Reihe von Pro-zessen des IntegraTUM-Projektes der TU München vorge-stellt. Abschnitt 4 greift diese Prozesse auf und beschreibtMöglichkeiten, diese Prozesse mit dedizierten Werkzeugenzu unterstützen; exemplarisch werden die Tools ioCMDB undI-SHARE vorgestellt. Die Arbeit schließt in Abschnitt 5 miteiner Zusammenfassung und einem Ausblick.

2 Modellierung

Die Partizipation mehrerer unabhängiger Organisationen inder Durchführung von Prozessen führt zu neuartigen, spe-zifischen Problemstellungen (vgl. hierzu z. B. [vdAVH02,BKKR02]). Abbildung 1 zeigt die besondere Struktur inter-organisationaler Prozesse. Aufgrund der Autonomie der be-teiligten Organisationen erfolgt die Ausführung der Prozesseverteilt; jede Organisation steuert dabei ihre eigenen, sog. lo-kalen Prozesse unabhängig und eigenständig. Durch Mecha-nismen der Prozess-Interoperabilität werden die lokalen Pro-zesse im Sinne der Ausführung organisationsübergreifenderglobaler Prozesse koordiniert [Kup06].

Als die derzeit einflussreichsten ITSM Frameworks kön-nen ITIL (IT Infrastructure Library), eTOM (Enhanced Tele-com Operations Map) [OGC07c], COBIT (Control Objecti-ves for Information and Related Technologies) [ITG07] so-wie ISO/IEC 20000 [ISO05] genannt werden. Die etablier-ten ITSM Frameworks geben keine konkreten Handlungsan-weisungen für die Spezifikation interorganisationaler Prozes-se. Insbesondere kooperative, nicht-hierarchische Szenarienwerden derzeit durch die etablierten Frameworks nicht unter-stützt.

In diesem Beitrag wird mit ITSMCooP eine dedizierteMethode zur Spezifikation der Betriebsprozesse kooperieren-



Modellierung interorganisationaler IT-Service-Managementprozesse 293

Abbildung 2 Bausteine der Methode ITSMCooP.

der Provider verwendet. Die Methode kann im Rahmen die-ses Beitrages nur skizziert werden; für eine ausführliche Be-schreibung dieser Methode siehe [Ham09].

Gemäß Balzert wird eine Methode durch Konzepte, No-tationen und eine systematische Vorgehensweise charakteri-siert [Bal96]. Diese Elemente werden in ITSMCooP wie folgtumgesetzt:

Grundlegende Konzepte ITSMCooP basiert auf denKonzepten des ITSM sowie der Prozess- und Informations-modellierung in interorganisationalen ITSM-Szenarien.

Konventionen Die Prozessmodellierungssprache BPMNunterstützt interorganisationale Prozesse bereits auf der syn-taktischen Ebene, vor allem durch das Konzept der Pools[OMG09]. BPMN deckt jedoch die Informations- und Da-tenmodellierung nicht ab [OMG09]. Das Shared Informa-tion/Data Model (SID) wurde im Rahmen von eTOM mitdirektem Bezug zu einem ITSM Framework entwickeltund eignet sich als Grundlage eines Informationsmodellsfür ITSM-Prozesse. Um eine Integration der verwendetenProzess- und Informationsmodellierungstechniken zu errei-chen und die Eignung der Modellierungstechniken zur Spezi-fikation interorganisationaler ITSM-Prozesse zu verbessern,definiert ITSMCooP einen Katalog von Konventionen zurModellierung interorganisationaler Prozesse. Die Syntax undSemantik der als Grundbausteine herangezogenen Model-lierungstechniken werden durch die Konventionen anwen-dungsspezifisch präzisiert und ggf. behutsam erweitert.

Vorgehensmodell Die Prozessmodellierung ist selbst einProzess, der möglichst strukturiert festgelegt werden sollte –insbesonders in einem komplexen interorganisationalen Um-feld. Zweiter Baustein von ITSMCooP ist daher ein Vorge-hensmodell zur Prozessdefinition. Das Vorgehensmodell gibtvor, wie auf Basis von BPMN und dem SID-Modell unterVerwendung der Notationskonventionen Prozesse zur Steue-rung der Zusammenarbeit von IT-Providern erstellt werdenkönnen.

Eine Reihe von Referenzprozessen demonstriert die An-wendung von ITSMCooP.

Abbildung 2 zeigt eine Übersicht über die Bausteine derMethode ITSMCooP. Die Lösungsbausteine bilden zusam-men ein Methode, die die prozessorientierte Vorgehensweiseder etablierten ITSM Frameworks aufgreift und auf interorga-nisationale Szenarien überträgt. Die im folgenden Abschnittbeschriebenen Prozesse sind Beispiele für die Anwendungvon ITSMCooP.

3 Interorganisationale ITSM-Prozesse

am Beispiel IntergraTUM

Die Beschreibung interorganisationaler ITSM-Prozesse indiesem Beitrag orientiert sich an einem konkreten Szenario.Im Folgenden wird zunächst das Projekt IntegraTUM kurzbeschrieben. Im Anschluss wird eine Reihe von Prozessen ex-emplarisch vorgestellt.

An der Technischen Universität München (TUM) wurdein den Jahren 2003 bis 2009 zusammen mit dem Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaf-ten (LRZ) in Garching, dem Dienstleister auf dem Gebiet derInformationsverarbeitung für die Münchner Hochschulen,2

das Projekt IntegraTUM durchgeführt. Das Ziel des Projekteswar die Schaffung einer benutzerfreundlichen und integrier-ten I&K-Infrastruktur. In diesem Projekt wurden gemeinsammit dem LRZ Dienste entwickelt, wie etwa ein hochverfügba-rer und zentral administrierter Dateiserver für die Ablage vonDaten der TUM-Mitarbeiter und Studenten oder ein zentralerVerzeichnisdienst als wesentlicher Bestandteil der Identity-und Access-Management (I&AM) Infrastruktur. Die Diens-te, die in diesem Projekt gemeinsam von TUM und LRZentwickelt wurden, sind ab Herbst 2009 in einen Standard-betrieb überführt worden. Dabei stellte sich die grundlegen-de Herausforderung, wie die ITSM-Prozesse zwischen TUMund LRZ gestaltet werden sollen. Beispielhaft werden in die-sem Beitrag die Prozesse des Incident-, Configuration- undService-Level-Managements vorgestellt.

3.1 Incident-Management

Das Hauptziel des Incident-Managements besteht darin, nachdem Eintreten einer Störung den normalen Servicebetriebschnellstmöglich wiederherzustellen [OGC07b]. Ebenfalls inder Verantwortung dieses Prozesses liegt die Minimierungder Auswirkungen von Störungen auf den Geschäftsbetrieb,um Dienstgüteparameter (Quality of Service), wie etwa dieVerfügbarkeit, auf dem mit den Kunden vereinbarten Niveauzu erhalten.

Bei der Erbringung interorganisationaler Dienste, wie imFall von IntegraTUM, ist die Durchführung von ITSM-Prozessen aufgrund der organisatorischen und technischenHeterogenität äußerst komplex. Wenn man die Problematikaus einem prozessorientierten Gesichtspunkt betrachtet, kannman die Heterogenität mit einer steigenden Komplexität so-

2IntegraTUM wurde von der Deutschen Forschungsgemeinschaft(DFG) unter Vertragsnummer WGI 554 975 bis September 2009 geför-dert.




Abbildung 3 IntegraTUM Incident-Management-Prozess.

wohl auf Prozesssicht als auch auf Systemsicht verbinden[MSG09]. Unter diesen Umständen ist ein geeignetes interor-ganisationales Störungsmanagement (Incident-Management)unverzichtbar. Ein wichtiger Faktor bei der Durchführungdes interorganisationalen Incident-Managements ist auch diekonkrete Form der Diensterbringungung; diese kann vielfälti-ge Spielarten annehmen, von einer klassischen hierarchischenStruktur bis hin zu heterarchischen Formen, die vor allem inkooperativen Szenarien relevant sind [MSGL09].

Abbildung 3 stellt das Prozessmodell gemäß ITSMCooPdes IntegraTUM Incident-Management-Prozesses dar. DieserProzess erstreckt sich über zwei Organisationen – TUM undLRZ – die Dienste in IntegraTUM gemeinsam erbringen.

In [HK10] werden die Grundsätze des interorganisationa-len Störungsmanagements in IntegraTUM beschrieben. Ei-ne von einem Benutzer gemeldeten Störung wird von ei-nem Mitarbeiter des TUM Service-Desks zunächst entgegen-genommen, erfasst und dokumentiert (Aktivität A1). Dazuwird das Werkzeug OTRS (Open Ticket Request System) ver-wendet, mit dem ein Ticket geöffnet wird [HK10]. Anschlie-ßend erfolgt eine Klassifizierung (Priorisierung und Kategori-sierung) durch den Service-Desk-Mitarbeiter (Aktivität A2).Hierbei können Dienstleistungsvereinbarungen (Service Le-vel Agreements, SLAs) die notwendigen Inputs liefern. DerService-Desk bzw. die Spezialisten in der TUM bearbeitendie Störung (Aktivität A3a), schließen das Ticket ab (A10)und benachrichtigen den Benutzer (Aktivität A11).

Nicht in allen Fällen kann die Ermittlung der Störungs-ursache und die Störungsbehebung direkt durch die Mitar-beiter der TUM durchgeführt werden. Tickets, die das TUMService-Desk nicht lösen kann und die außerhalb der Zustän-digkeit der TUM-Experten liegen, werden fachlich eskaliert

und an das LRZ weitergeleitet (Aktivität A3b). Der Prozesswird dann am LRZ weitergeführt. Das TUM Service-Deskfungiert dabei als Ticketowner, ist also für den Gesamtpro-zess der Ticketlösung verantwortlich. Es ist daher wichtig,dass die Antworten auf Störungen, die an das LRZ weiterge-leitet werden, wieder zurück an das TUM Service-Desk zu-rückgegeben werden.

Historisch gesehen, sind die LRZ- bzw. TUM-Werkzeuge„älter“ als der interorganisationale IntegraTUM-Prozess. Ei-nige Erweiterungen der bestehenden Prozesse mussten vor-genommen werden, um diese an die Gegebenheiten von Inte-graTUM anzupassen: Damit z. B. die LRZ-Hotline nicht je-de vom TUM Service-Desk weitergeleitete Anfrage manuellkopieren muss, wurde für die Ticket-Informationen ein dedi-ziertes, formales und einfach maschinenlesbares Austausch-format vereinbart; dieses erlaubt die automatische Übernah-me von TUM-Tickets als LRZ-Ticket.

Störungen, welche von der TUM an das LRZ weitergelei-tet werden, werden am LRZ neu erfasst und stellen für dasLRZ eine „neue“ Störung dar. Die Störung wird im LRZ-Ticketsystem dokumentiert; und ein LRZ-Ticket wird geöff-net (Aktivität A4). Im LRZ wird ARS Remedy seit vielenJahren als Ticket-System benutzt. Mittelfristig wird das ARS(Remedy Action Request System) am LRZ gegen die ITSM-Suite von iET Solutions ausgetauscht. Das wird im Rahmender Ausrichtung der ITSM-Prozesse gemäß ISO/IEC 20000stattfinden.

Der Prozess folgt am LRZ einem ähnlichen Ablauf wie deran der TUM. Zunächst versucht die LRZ-Hotline selbst dasTicket zu lösen (Aktivität A5a). Ist dies erfolgreich, schließtdie LRZ-Hotline das LRZ-Ticket ab (Aktivität A8) und leitetdie Antwort an das TUM Service-Desk zurück (Aktivität A9).




Abbildung 4 Informationsmodell in IntegraTUM nach [Kni10].

Wenn die LRZ-Hotline keine Lösung für die bestehende Stö-rung findet, eskaliert sie diese funktional innerhalb des LRZan den zuständigen Spezialisten (Aktivität A5b). Nach derBehebung der Störung durch die LRZ-Spezialisten (Aktivi-tät A6) erfolgt eine Meldung an die LRZ-Hotline (AktivitätA7), das LRZ-Ticket wird geschlossen (Aktivität A8) und dieLösung an das TUM Service-Desk gemeldet (Aktivität A9).Hier werden die Aktivitäten A10 und A11 wie oben beschrie-ben durchgeführt. Der Prozess muss in jedem Fall eingehaltenwerden, auch für den Fall, dass am LRZ Störungen gemeldetwerden, die offensichtlich die TUM betreffen. Hierfür wirddie LRZ-Hotline die Benutzer an das Service-Desk der TUMverweisen.

3.2 Configuration-Management

Während der Incident-Management-Prozess auch für Kun-den direkt sichtbar ist, ist das Configuration-Managementfür Kunden und Nutzer zumeist transparent. Das Configura-tion-Management stellt Informationen über Konfigurations-elemente und deren Beziehungen bereit und unterstützt da-mit alle anderen ITSM-Prozesse. Das Configuration-Mana-gement geht weit über die reine Inventarisierung hinaus. Un-terstützt wird u. a. das Incident-Management, das dokumen-tierte Abhängigkeiten zwischen Konfigurationselementen zurVereinfachung der Fehlersuche nutzen kann. Ein anderes Bei-spiel ist das Service-Level-Management, dem eine belast-bare Grundlage für die Definition von Dienstgüteparame-tern geliefert wird. Konfigurationsinformationen werden überein dediziertes Werkzeug bereitgestellt; als Bezeichnung hat

sich hierfür der Begriff Configuration Management Database(CMDB) etabliert. Für interorganisational erbrachte Dienstesind spezifische Anpassungen der CMDB notwendig (sieheAbschnitt 4.1).

Die Aktivitäten im Configuration-Management sind dar-auf ausgelegt, die Konfigurationsinformationen in der CMDBkorrekt und aktuell zu halten. Inkorrekte und veraltete Da-ten würden dazu führen, dass den ITSM-Prozessen keine ver-lässliche Informationsbasis zur Verfügung steht. Das führt alsKonsequenz wiederum dazu, dass Prozesse umgangen wer-den oder Schattendatenbestände separat und mit manuellemAufwand gepflegt werden.

Abbildung 4 stellt einen vereinfachten Auszug der Infor-mationen dar, welche im IntegraTUM-Szenario relevant fürdas ITSM sind. Hier sind die Zusammenhänge innerhalb derNetzinfrastruktur dargestellt. Dieses Wissen ist insbesonde-re für das Incident-Management im Bereich des Netzma-nagements relevant. Eine Besonderheit hierbei ist, dass einTeil dieser Informationen vom LRZ und ein anderer Teil vonder TUM verwaltet werden. Die Aufgabe des TeilprozessesStatus Accounting und Reporting ist es, diese Infor-mationen für IntegraTUM abzurufen und geeignet bereitzu-stellen. In Abbildung 5 sind die hierfür notwendigen Prozess-schritte gemäß von ITSMCooP dargestellt.

Eine generell notwendige Vorbedingung im Configura-tion-Management ist es, den Umfang der benötigten Infor-mationen vorab festzulegen. Der Umfang der benötigten In-formationen stellt für unser Beispiel obiges Informationsmo-dell dar. Weiterhin muss vereinbart werden, wie die Datenaus den lokal an LRZ und TUM vorhandenen Datenbestän-




Abbildung 5 Teilprozess Status Accounting und Reporting im interorganisationalen Configurations-Managementnach [HK08b].

den abgerufen werden. Hierbei gehen wir in dieser Beschrei-bung von zeitbasierten Abrufen der Daten aus, denkbar wär-den auch ereignisgesteuerte Mechanismen. In der Darstel-lung werden die an TUM und LRZ vorhandenen Datenbe-stände als lokales Management Data Repository (MDR) bzw.CMDB bezeichnet. Wie in der Abbildung gezeigt wird, mussim interorganisationalen Fall beim Manipulieren von Kon-figurationselementen in einem lokalen MDR geprüft wer-den, ob eine Änderung auch eine Relevanz für den inter-organisationalen Fall hat. Wenn dem so ist, wird die Än-derung in die inter-organisationale CMDB propagiert. Ei-ne tatsächliche Änderung eines Configuration-Items (CI) er-folgt nach Genehmigung durch einen inter-organisationalenConfiguration-Manager.

Von ITSMCooP kamen bei der Modellierung des Prozes-ses die folgenden Konventionen besonders zum Tragen:

– Jeder Aktivität wird genau eine ausführende Rolle zuge-ordnet;

– Spezifikation von Zeitbedingungen für Aktivitäten und denProzess;

– Verschattung personenbezogener bzw. organisationsinter-ner Informationen aller Akteure.

Informationen zwischen den Akteuren werden mittelsNachrichten ausgetauscht. Die Inhalte dieser Nachrichtenrichten sich hierbei nach der Struktur, wie sie vom Informati-onsmodell (siehe Abbildung 4) vorgegeben werden. Im Pro-zessmodell (Abbildung 5) sind die auszutauschenden Infor-mationen als BPMN-Artefakte CI modelliert.

3.3 Service-Level-Management

Das Service-Level-Management (SLM) hat als Ziel die mitdem Kunden vereinbarte Qualität von IT-Diensten zu ge-währleisten und zu verbessern [OGC07a]. Zur Überwachungder tatsächlichen Dienstgüte wird ein Monitoring zumindestder wesentlichen Dienstgüteparameter benötigt. Dies ermög-licht die Bewertung der Erfüllung der Dienstgütevorgabendes Kunden.

Die Durchführung dieser Aufgabe erfordert eine Kombi-nation von manuell ausgeführten und Werkzeug-unterstütztenTätigkeiten. Die Beteiligung mehrerer Provider an der Diens-terbringung in interorganisationalen Szenarien erfordert zu-dem die Beteiligung aller Provider am Monitoring und derAggregation der Dienstgüteparameter der Teildienste. DieKomplexität und der Umfang der Prozesse stellen dabei ei-ne Herausforderung dar. Um die Prozesse übersichtlich zugestalten, ist es oft sinnvoll, die Prozesse auf unterschiedli-chen Abstraktionsniveaus zu beschreiben. Die Abbildungen 6und 7 zeigen beispielhaft die Modellierung eines solchen Pro-zesses mit ITSMCooP.

In Abbildung 6 ist der für für Monitoring und Reportingzuständige ITSM-Prozess im IntegraTUM-Szenario darge-stellt. Timer-gesteuert wird in der Aktion A1 zunächst der ak-tuelle Dienstinstanzzustand abgefragt. Je nach Zustand kön-nen unterschiedliche Aktionen ausgelöst werden, die Betei-ligte aus mehreren Organisationen involvieren. Sollte z. B. ei-ner der vereinbarten Grenzwerte (Threshold) nicht eingehal-ten werden, wird der Incident-Management-Prozess angesto-ßen, indem eine entsprechende Nachricht an die LRZ-Hotlinegeschickt wird.




Abbildung 6 SLM-Prozess Monitoring und Reporting.

Abbildung 7 Prozess Teildienstüberwachung.

Das Ergebnis der Abfrage des Dienstzustandes wird an dieTUM-Betriebsgruppe geschickt. Um die Anfrage beantwor-ten zu können, müssen die relevanten Dienste von dieser Rol-le kontinuierlich überwacht werden. Die Modellierung die-ses Teil-Prozesses ist in Abbildung 7 dargestellt. Dabei wirddeutlich, dass bei Kopplung der Betriebsprozesse oft auchdie Kopplung der eingesetzten Werkzeuge notwendig ist. DieWeiterleitung von Monitoring-Informationen zwischen Orga-nisationen sind dabei als Nachrichten zwischen Pools zu mo-dellieren, da unterschiedliche Organisationen beteiligt sind.

4 Werkzeugunterstützung

Organisationsübergreifende IT-Service-Managementprozes-se, wie sie im vorigen Abschnitt beschrieben wurden, können

ohne geeignete Werkzeugunterstützung nicht effizient umge-setzt werden. In diesem Abschnitt werden Werkzeugansätzebeschrieben, die im Rahmen von Projekten des MNM-Teamszur Unterstützung interorganisationaler ITSM-Prozesse ent-wickelt wurden. Die Anforderungen und Use Cases zur Ent-wicklung dieser Werkzeuge wurden aus den mit ITSMCooPerstellten Informations- und Prozessmodellen abgeleitet.

4.1 InterorganisationaleConfiguration-Management-Database

Zur Unterstützung der ITSM-Prozesse hat sich in der Praxisdie CMDB etabliert [OGC07b]. In einer CMDB werden rele-vante Managementinformationen als Konfigurationselemen-te gepflegt. Diese Konfigurationselemente sind ein logischesAbbild der physischen Infrastruktur. Im interorganisationalen




Links to border interface information

End-site domain

End-site domain

Connecting domains

Adjoining interfaces at demarcation point

Abbildung 8 I-SHARe: Festlegung der Route eines E2E Links.

Fall ist ebenso eine geeignete Werkzeugunterstützung not-wendig, diese wird analog zur CMDB interorganisationaleCMDB (ioCMDB) genannt (siehe auch [HK08a]).

Im Vergleich zum Einsatz einer CMDB innerhalb einerOrganisation sind jedoch im interorganisationalen Fall weite-re Spezifika zu berücksichtigen. Hierzu gehören u. a. Aspekteder geeigneten Modellierung oder des dedizierten Zugriffesauf die Konfigurationsinformationen. Hinsichtlich der Mo-dellierung muss bei der Abbildung der Konfigurationsele-mente in ein übergreifendes Datenmodell berücksichtigt wer-den, dass sich die relevanten Dienste aus Dienstfragmentenzusammensetzen, welche von verschiedenen Organisations-einheiten bereitgestellt werden; im Beispiel IntegraTUM vomLRZ oder von den verschiedenen Organisationseinheiten in-nerhalb der TUM. Das bedeutet, dass in der ioCMDB Da-ten aus verschiedenen Quellsystemen importiert werden müs-sen, die in den beteiligten Organisationen lokal und auto-nom betrieben werden. Besonderheiten, die dabei bzgl. derInformationsmodellierung zu berücksichtigen sind, wurdenin [HK09] dargestellt.

In der Regel kann weiterhin nicht davon ausgegangenwerden, dass von der interorganisationalen Ebene aus unbe-schränkte Zugriffe auf die lokalen Systeme möglich sind undumgekehrt. Aus diesem Grund ist im interorganisationalenFall die effektive Steuerung des Datenaustauschs ein wich-tiger Aspekt. Ein möglicher Ansatz hierzu wurde in [HK08a]vorgestellt.

Im Rahmen von IntegraTUM wurde ein Teil der angespro-chenen Konzepte bereits prototypisch umgesetzt. So wurdedas oben dargestellte Datenmodell (vgl. Abbildung 4) in eineCMDB auf Basis von OTRS integriert. Hierzu wurden Kon-nektoren für zwei verschiedene lokale MDR implementiert,eines am LRZ und eines an der TUM. Diese stellen sicher,

dass die relevanten Informationen geeignet in die CMDB ein-gepflegt werden (siehe auch [Kni10]). Notwendig wurde hier-bei eine Anpassung des OTRS-eigenen Datenmodelles, umdie zusätzlichen spezifischen Typen von Konfigurationsele-menten abzubilden. Als weitere Schritte sind die Erweite-rung des Werkzeuges um geeignete Visualisierungsmöglich-keiten und die Umsetzung eines feingranularen Zugriffkon-zeptes geplant.

4.2 I-SHARe

Die Organisationsstruktur des IntegraTUM-Szenarios ist re-lativ stabil. Oftmals sind Kooperationen zwischen IT-Service-Providern jedoch von einer weit größeren Dynamik geprägt.Die in diesem Beitrag präsentierte Methode ITSMCooP un-terstützt auch Szenarien mit einer großen Anzahl von Part-nern und/oder einer hohen Fluktuation. In solchen Szenari-en können einzelne Dienstinstanzen auch nur von einer Aus-wahl von Partnern erbracht werden. Der Werkzeugunterstüt-zung kommt dabei eine besondere Bedeutung zu. Zur Illus-tration wird abschließend das System I-SHARe (InformationSharing across Heterogeneous Administrative Regions) vor-gestellt. Dieses System wurde im Rahmen des EuropäischenWissenschafts- und Forschungsnetzes Géant entwickelt.

I-SHARe ist ein Werkzeug zur Unterstützung der Planungund des Betriebs dedizierter optischer Verbindungen – sog.E2E Links – im Géant-Netz. Die Prozessmodellierung fürI-SHARe erfolgte auf Basis von ITSMCooP.

Im Gegensatz zum IntegraTUM-Projekt, in dem eine fi-xe Aufgabenteilung zwischen beiden beteiligten Organisa-tionen vertraglich geregelt ist, ist die Beteiligung der natio-nalen Forschungsnetzorganisationen (sog. National Researchand Educational Networks, NRENs) bei Géant E2E Links im-




Abbildung 9 I-SHARe: Abstimmung der Interfaceoptionen.

Abbildung 10 I-SHARe Architektur.




mer Dienstinstanz-bezogen. In Abhängigkeit vom Verlauf derRoute eines E2E Links realisieren und betreiben unterschied-liche NRENs die Teilstrecken eines E2E Links.

I-SHARe bietet auf der GUI-Ebene unterschiedliche Per-spektiven. Bei der Planung eines neuen E2E Links werdenzunächst die NRENs ausgewählt, die sich bei der Erbrin-gung dieser Dienstinstanz beteiligen werden (siehe Abbil-dung 8). Zwischen benachbarten NRENs werden die Ver-bindungsstellen (sog. Points of Presence, POPs) festgelegt.Diese Festlegungen werden in den nachfolgenden Schrittenvon den benachbarten NRENs bis hin zu technologiespezifi-schen Parametern verfeinert, die für die Zusammenschaltungder einzelnen E2E-Link-Segmente notwendig sind (siehe Ab-bildung 9). Dabei kann jeder NREN ausschließlich Angabenüber eigene Netzinfrastruktur verändern.

Wegen der Dienstinstanz-bezogenen Beteiligung einzelnerNRENs ist es – im Gegensatz zu IntegraTUM – nicht mehrmöglich, bei der Definition der interorganisationalen Betrieb-sprozesse direkt auf konkrete Betriebsgruppen zu verweisen.Diese Restriktion wird durch Definition einer entsprechendenRolle umgangen. Dasselbe Vorgehen lässt sich auch auf dieDefinition der Interaktionen zwischen verschiedenen Kompo-nenten des I-SHARe-Systems übertragen. Prozessdefinitio-nen beschreiben das erwartete Verhalten der Komponentenunterschiedlicher NRENs. In Kombination mit einem stan-dardisierten Kommunikationsprotokoll wird es ermöglicht,dass die NREN-Komponenten in Eigenregie realisiert wer-den, was u. U. für die Kopplung mit den eingesetzten pro-prietären Managementsystemen notwendig sein kann. Abbil-dung 10 zeigt die Architektur des I-SHARe-Systems. Die or-ganisatorische Vielfalt des Szenarios spiegelt sich in der de-zentralisierten, Service-orientierten Architektur des Systemswider (vgl. [HYH08]).

5 Fazit

Dieser Beitrag stellte eine Reihe von Forschungsergebnissendes MNM-Teams vor, die sowohl methodische Probleme derModellierung und Spezifikation als auch technische Aspekteder Werkzeugunterstützung interorganisationaler und koope-rativer ITSM-Prozesse untersuchen. Jeder dieser Beiträge istein essentieller Baustein in diesem relativ jungen Fachgebiet,das die etablierten ITSM-Methoden und -Framworks ergänzt.Die hier vorgestellte Methode ITSMCooP wurde bereits inverschiedenen Forschungsprojekten erfolgreich eingesetzt: InIntegraTUM konnte vor allem die Spezifikation der Prozes-se vorangetrieben werden, die weitere Automatisierung undWerkzeugunterstützung wird in nachfolgenden Projekten an-gegangen; Géant profitierte vor allem durch die Werkzeug-gestützte Kollaboration in den Prozessen, welche durch diehier vorgestellte Methode effektiv definiert wurden. Ebensovielfältig wie die Organisationsationsformen im interorgani-sationalen IT-Service-Management sind die dabei zu untersu-chenden Fragestellungen – entscheidend für eine bessere Un-terstützung insbesondere kooperativer Szenarien der Diens-terbringung wird daher nicht zuletzt auch eine enge Integrati-on und Koordination der weiteren Forschungsanstrengungendieser Disziplin sein.

Literatur

[Bal96] Balzert, H.: Lehrbuch der Software Technik:Software-Entwicklung. Spektrum Akademi-scher Verlag, Heidelberg u. a., 1996.

[BKKR02] Bernauer, M., G. Kramler, G. Kappel und Wer-ner Retschitzegger: Specification of interorga-nizational workflows–a comparison of approa-ches. Technischer Bericht 08/02, Business In-formatics Group, Institute of Software Techno-logy and Interactive Systems, Technische Uni-versität Wien, 2002.

[Ham09] Hamm, M.: Kooperation im IT-Betrieb: Ei-ne Methode zur Spezifikation der IT-Service-Managementprozesse Verketteter Dienste. Süd-westdeutscher Verlag für Hochschulschriften,2009.

[HK08a] Hommel, W. und S. Knittl: An Access ControlSolution For The Inter-Organizational Use OfITIL Federated Configuration Management Da-tabases. In: Hewlett-Packard (Herausgeber):2008 Workshop of HP Software University As-sociation (HP-SUA), Marrakesch, Marokko, Ju-ni 2008. Infonomics-Consulting.

[HK08b] Hommel, W. und S. Knittl: An Inter-Organiza-tional Configuration Management Database asKey Enabler for Future IT Service ManagementProcesses. In: eChallenges 2008, Stockholm,Schweden, Oktober 2008.

[HK09] Hommel, W. und S. Knittl: Zielorientierte Da-tenmodellierung für ITIL-basierte inter-organi-sationale Configuration Management Databa-ses. In: 9. Internationale Tagung Wirtschafts-informatik, Wien, Österreich, Februar 2009.

[HK10] Hommel, W. und S. Knittl: Aufbau von or-ganisationsübergreifenden Fehlermanagement-prozessen im Projekt IntegraTUM. In: Bode, A.und R. Borgeest (Herausgeber): Informations-management in Hochschulen. Springer-Verlag,Berlin, 2010.

[HYH08] Hamm, M. K., M. Yampolskiy und A. Hane-mann: I-SHARe. DFN Mitteilungen, 74(Mai):39–41, 2008.

[ISO05] ISO/IEC: International Standard ISO/IEC20000-1:2005(E). Part 1: Specification. Genf,2005.

[ITG07] ITGI (IT Governance Institute): Control Objec-tives for Information and related Technology,Version 4.1. ITGI, Rolling Meadows, 2007.

[Kni10] Knittl, S.: Unterstützung der IT-Service-Man-agement-Prozesse an der Technischen Univer-sität München durch eine Configuration-Man-agement-Database. In: Bode, A. und R. Bor-




geest (Herausgeber): Informationsmanagementin Hochschulen, Berlin. Springer-Verlag, 2010.

[Kup06] Kupsch, F.: Framework zur dezentralen Inte-gration systemübergreifender Geschäftsprozes-se. Dissertation, Deutsches Forschungszentrumfür Künstliche Intelligenz, 2006.

[MSG09] Marcu, P., L. Shwartz und G. Grabarnik: Mo-del for Incident Ticket Correlation for Inter-Or-ganizational Service Delivery. In: eChallenges2009, Istanbul, Turkey, Oktober 2009.

[MSGL09] Marcu, P., L. Shwartz, G. Grabarnik undD. Loewenstern: Managing Faults in the Ser-vice Delivery Process of Service Provider Coali-tions. In: IEEE International Conference onService Computing (SCC 2009), Bangalore, In-dia, 2009.

[OGC07a] OGC (Office of Government Commerce) (Her-ausgeber): Service Design. IT Infrastructure

Library v3 (ITIL v3). The Stationary Office,Norwich, UK, 2007.

[OGC07b] OGC (Office of Government Commerce) (Her-ausgeber): Service Operation. IT Infrastruc-ture Library v3 (ITIL v3). The Stationary Office,Norwich, UK, 2007.

[OGC07c] OGC (Office of Government Commerce): Ser-vice Strategy. The Stationary Office, Norwich,UK, 2007.

[OMG09] OMG (Object Management Group): BusinessProcess Modeling Notation (BPMN) Specifica-tion, Version 1.2. Elektronische Quelle URL:http://www.omg.org/spec/BPMN/1.2/PDF, 2008 (letzter Zugriff: 08.01.2009).

[vdAVH02] Aalst, Wil M. P. van der und K. Van Hee: Work-flow Management – Models, Methods, and Sys-tems. MIT Press, Cambridge/Mass., 2002.



http://www.omg.org/spec/BPMN/1.2/

PDF

Modellierung interorganisationaler IT-Service ... · tion/Data Model (SID) wurde im Rahmen von eTOM...

Documents

Transcript of Modellierung interorganisationaler IT-Service ... · tion/Data Model (SID) wurde im Rahmen von eTOM...