Microsoft Operations Framework
Microsoft Operations Framework (MOF) bietet Ihnen neue Möglichkeiten zur effizienten Nutzung aller Ressourcen in Ihrem Unternehmen. In diesem Whitepaper vermitteln wir die Grundlagen, die zum Verständnis und zur Umsetzung von MOF erforderlich sind. Nach einer allgemeinen Einführung in das Thema stellen wir Ihnen das Prozess-, das Team- und das Risikomodell vor und veranschaulichen die Ziele, die mithilfe von MOF erreicht werden können. Dieses Dokument ist der ideale Einstieg rund um das Thema MOF und wie es einen Mehrwert für Ihr Unternehmen darstellt.
Weitere Informationen zum Microsoft Operations Framework finden Sie unter http://www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx (englischsprachig).
Auf dieser Seite
 | Einführung |
| Das MOF-Prozessmodell |
| Das MOF-Teammodell |
| Das MOF-Risikomodell |
| MOF und Microsoft Solutions Framework |
| Wo sollte begonnen werden? |
| Weitere Informationen |
|
Einführung
Überblick über die Frameworks
Um zum maximalen Erfolg von IT-Projekten beizutragen, stellt Microsoft für deren Planung und Realisierung Komplettanleitungen zur Verfügung. Diese Anleitungen dienen als Modell und Orientierungshilfe bei Design, Entwicklung, Deployment, Betrieb und Support Microsoft-basierter Lösungen. Die Grundlage schaffen dabei das Wissen, das Microsoft bei seinen großen Softwareentwicklungsprojekten und dem Betrieb von IT-Services sammelt, die Erfahrungen, die unsere Consultants bei der Durchführung von IT-Projekten für Firmenkunden machen, sowie insgesamt das IT-Know-how, über das Microsoft als weltweit führendes Softwareunternehmen verfügt.
Die Anleitungen sind in zwei komplementäre und eng miteinander verbundene "Frameworks" (Rahmenstrukturen) aufgeteilt: das Microsoft Operations Framework und das Microsoft Solutions Framework (MSF).
Als Zusammenstellung technischer Anleitungen unterstützt MOF Unternehmen dabei, Microsoft-basierte IT-Lösungen mit optimaler Zuverlässigkeit, Verfügbarkeit, Supportfähigkeit und Verwaltbarkeit zu erstellen und zu betreiben. MOF adressiert vier Faktoren, die in diesem Zusammenhang entscheidend sind: Mitarbeiter, Prozesse, Technologien und Verwaltung. Weitere Informationen zu MOF finden Sie unter http://www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx (englischsprachig).
Das zweite Framework, MSF, erfüllt als flexible und skalierbare Projekthilfe die Anforderungen von Unternehmen und Teams jeder Größe. Die Anleitungen aus dem MSF bestehen aus Prinzipien, Modellen und Disziplinen für das Management von Mitarbeitern, Prozessen und technologischen Elementen. Das MSF bietet bewährte Vorgehensweisen für das Planen, Entwerfen, Entwickeln und Bereitstellen erfolgreicher IT-Lösungen. Weitere Informationen zu MSF erhalten Sie unter http://www.microsoft.com/technet/archive/ittasks/plan/teamops/manorg.mspx (englischsprachig).
Der IT-Lebenszyklus
Um einen IT-basierten Service einzurichten, müssen sich die verantwortlichen IT-Mitarbeiter über zwei entscheidende Dinge bewusst sein:
1. | Sie müssen verstehen, wie die Bedarfslage ist und welcher Service benötigt wird, um eine entsprechende Lösung zu erstellen. |
2. | Sie müssen die Lösung betreiben, um den Dienst anzubieten. |
Von den beiden Microsoft-Frameworks - Microsoft Solutions Framework und Microsoft Operations Framework - ist MSF auf den ersten Punkt abgestimmt (Bedarfsanalyse und Lösungserstellung), während MOF den zweiten Punkt adressiert (kontinuierlicher Betrieb der Lösung als IT-Service).
Die beiden Frameworks sind komplementär und ermöglichen dadurch - vom Erkennen des Bedarfs bis zur Inbetriebnahme des Service - eine rasche Umsetzung des Gesamtprojekts. Terminologische und konzeptionelle Konsistenz zwischen den beiden Frameworks sorgt ebenfalls dafür, dass letztendlich eine hochwertige Lösung bereitgestellt werden kann.
MSF und MOF folgen beim Erstellen und Betreiben einer neuen Lösung vier grundlegenden Schritten:
1. | Die neue Geschäftsanforderung definieren |
2. | Eine Lösung entwickeln und bereitstellen (unter Anwendung von MSF and MOF). |
3. | Die Lösung betreiben (unter Anwendung von MOF) |
4. | Optimierungen vornehmen |
Änderungen an einer neu bereitgestellten Lösung können aufgrund betrieblicher, geschäftlicher oder regulatorischer Anforderungen erforderlich werden.
Indem der Microsoft-IT-Lebenszyklus die verschiedenen Aktivitäten innerhalb einer IT-Organisation positioniert und verknüpft, sorgt er für eine reibungslose und kosteneffektive Implementierung von IT-Services. MOF und MSF zielen auf unterschiedliche, aber dennoch eng miteinander verbundene Phasen des Lebenszyklus ab. Jedes Framework bietet hilfreiche detaillierte Informationen zu den Mitarbeitern, Prozessen und Technologien, die erforderlich sind, um das Projekt im jeweiligen Bereich erfolgreich umzusetzen. Mit konsistenten, mess- und wiederholbaren Anleitungen sorgen MOF und MSF dafür, dass sich IT-Lösungen effektiv und effizient einrichten und betreiben lassen.
Abbildung 1: MSF und MOF ergänzen sich beim Erfüllen geschäftlicher Anforderungen
MOF und ITIL
In der IT Infrastructure Library (ITIL) des englischen Office of Government Commerce (OGC) wurden aktuelle branchenspezifische optimale Vorgehensweisen für das IT-Service-Management umfassend dokumentiert.
Bei der OGC handelt es sich um eine Einrichtung der britischen Regierung, deren Aufgabe die Entwicklung optimaler Vorgehensweisen und Richtlinien für die Verwendung von Informationstechnologien zur Verbesserung des Service Management und betrieblicher Prozesse ist.
Zur Erreichung dieses Zieles führt die OGC in Zusammenarbeit mit führenden IT-Unternehmen auf der ganzen Welt regelmäßig Projekte durch, um optimale Vorgehensweisen für die Bereiche des IT-Service-Management zu dokumentieren und zu überprüfen. ITIL umfasst derzeit mehr als 40 Bücher. Jedes Buch behandelt eine Funktion des IT-Service-Management und enthält Querverweise auf die anderen Bücher.
MOF kombiniert diese gemeinschaftlich entwickelten Industriestandards mit speziellen Richtlinien für das Verwenden von Microsoft-Produkten und -Technologien. Darüber hinaus erweitert MOF die ITIL-Verfahrensnormen dahingehend, dass auch verteilte IT-Umgebungen, Branchentrends, Risk Management und die beteiligten Rollen (Personen), wie z. B. Anwendungshosting und webbasierte Transaktions- und E-Commerce-Systeme, Change/Release Manager oder Security Manager unterstützt werden.
Überlegungen zum Entwurf
MOF wurde so konzipiert, dass es folgende Ziele erreicht:
| • | Verwenden von Ideen, die sich im Einsatz bewährt haben. |
| • | Nutzen branchenspezifischer optimaler Vorgehensweisen. |
| • | Bereitstellen einer erweiterbaren Grundlage für Betriebswissen. |
| • | Auseinandersetzen mit Personen, Prozessen und Technologien. |
| • | Einbeziehen des Feedbacks von Kunden, Partnern, Microsoft ITG[1] sowie Produkt- und Dienstleistungsorganisationen von Microsoft. |
| • | Erhöhen der IT-Flexibilität, damit das Unternehmen schnell an sich ändernde Bedingungen angepasst werden kann. |
| • | Integrieren in Rahmenstrukturen, die andere Teile des IT-Lebenszyklus verwalten, wie z. B. Planung und Umsetzung. |
| • | Unterstützen der Verwaltung von End-to-End-Diensten, einschließlich Prozessen und Verfahren, statt nur der Verwaltung von Servern und Technologien. |
MOF-Modelle
MOF besteht aus drei Modellen:
| • | Prozessmodell |
| • | Teammodell |
| • | Risikomodell |
Diese Modelle bieten Unterstützung zu Personen, Prozessverwaltung und Risikomanagement im IT-Service-Management. Jedes Modell legt den Schwerpunkt auf verfügbare Technologien und optimale Vorgehensweisen, um hohe Systemverfügbarkeit, Zuverlässigkeit, Supportfähigkeit und Verwaltbarkeit für die Microsoft-Plattform zu erreichen. Darüber hinaus bieten die Modelle Unterstützung für die Interoperabilität mit anderen Technologieplattformen.
Das MOF-Prozessmodell
Übersicht
Das Prozessmodell für den Betrieb ist ein Funktionsmodell der Prozesse, welche Betriebsteams für die Verwaltung und Wartung von IT-Diensten ausführen. Daher bietet es eine Möglichkeit, sich komplexe IT-Umgebungen vereinfacht und verallgemeinert vorzustellen.
Ursprung
Das Prozessmodell basiert auf den optimalen Vorgehensweisen, die von der OGC in ihrer IT Infrastructure Library dokumentiert wurden.
Das Modell setzt voraus, dass die Betriebsgruppe in erster Linie für das Verwalten von Änderungen in der IT-Infrastruktur verantwortlich ist. Die effektivste Art für den Umgang mit Änderungen während der gesamten Lebensdauer eines Dienstes besteht darin, verwandte Änderungen in einer Reihe von Versionen zusammenzufassen, von denen jede als eine Einheit geplant und verwaltet werden kann. Das MOF-Prozessmodell beschreibt einen Lebenszyklus, der auf jede beliebige Version angewendet werden kann. Außerdem beschreibt es die Prozesse oder Aktivitäten, aus denen jeder Teil dieses Zyklus besteht.
Grundlegende Prinzipien
Das MOF-Prozessmodell basiert auf vier grundlegenden Prinzipien:
| • | Strukturierte Architektur:Das MOF-Prozessmodell ist eine Architektur, die sämtliche für die unternehmenswichtige Datenverarbeitung erforderlichen Betriebsaktivitäten strukturiert. Auf diese Weise können sie die zunehmend komplexe Umgebung besser handhaben. |
| • | Schneller Lebenszyklus, iterative Verbesserung:Die Änderungsrate bei betrieblichen IT-Prozessen beschleunigt sich immer mehr. Dieser Änderungsbedarf steht in direkter Beziehung zu den Anforderungen von Unternehmen, Anpassungen vorzunehmen und Innovationen zu realisieren, um wettbewerbsfähig zu bleiben. Infolgedessen hat MOF das Konzept eines iterativen Lebenszyklus integriert, das sowohl die Möglichkeit zum schnellen Einbeziehen von Änderungen als auch zum ständigen Bewerten und Verbessern der gesamten Betriebsumgebung unterstützt. |
| • | Überprüfungsgesteuerte Verwaltung:Das Prozessmodell umfasst Überprüfungen der wichtigen Stellen im Lebenszyklus, an denen das Team die Leistung für versionsbasierte Aktivitäten sowie für gleichbleibende bzw. zeitlich wiederkehrende Betriebsaktivitäten auswertet. Bei diesen Hauptüberprüfungen wird das obere Management mit einbezogen, wenn sein Feedback am meisten benötigt wird. |
| • | Eingebettetes Risikomanagement:Der heutige IT-Betrieb ist wichtiger und komplexer als je zuvor, und Betriebsausfälle sind für Kunden und IT-Benutzer weltweit besser sichtbar. Dies bedeutet, dass das Risikomanagement im Betrieb äußerst wichtig ist, um sicherzustellen, dass es zu keinem Ausfall der Geschäftsabläufe kommt. |
Terminologie
Für eine detailliertere Erläuterung des Prozessmodells ist es hilfreich, eine spezielle Terminologie festzulegen, die zum großen Teil auf der vorhandenen ITIL-Terminologie basiert.
| • | IT-Lösungen: Die Möglichkeiten, die IT dem Unternehmen bietet. Beispiele hierfür sind Messaging, Geschäftsbereichsanwendungen, Datenspeicherung und Drucken. |
| • | Version: Eine Gruppe von Änderungen, die das Betriebsteam als eine Einheit in die Produktionsumgebung einführt. Jede Version weist einen eigenen Lebenszyklus auf, und das Ende der einen Version kennzeichnet normalerweise den Beginn der nächsten Version. |
| • | IT-Service-Management: Das Konzept der Anwendung von strukturierten Prozessen, um sicherzustellen, dass die Qualität unternehmenswichtiger IT-Dienste den mit dem Kunden vereinbarten Leistungsniveaus entspricht. |
| • | Service Management Functions (SMFs oder Service Management Funktionen): 21 Prozesse, über die die meisten IT Lösungen verfügen und die während jeder Version erfolgen. Beispiele hierfür sind Capacity Management, Change Management, Service Desk und Sicherheitsverwaltung. Jede SMF bietet konsistente Richtlinien, Verfahren, Standards und optimale Vorgehensweisen, die auf die gesamte Reihe von IT Lösungen in den heutigen IT-Umgebungen angewendet werden können. |
| • | Dienstleistungszweck: SMFs können in vier Kategorien unterteilt werden, die jeweils durch einen Dienstleistungszweck definiert sind. So unterstützen die SMFs Change Management, Configuration Management und Release Management beispielsweise den Dienstleistungszweck 'Identifizieren, Prüfen, Steuern und Herausgeben von Änderungen an die IT-Umgebung'. |
| • | Quadranten: Die Kurzbezeichnung für die SMFs, die einen Dienstleistungszweck gemeinsam nutzen: 'Änderung', 'Betrieb', 'Support' und 'Optimierung'. Jeder Quadrant enthält mehrere SMFs. |
| • | Überprüfungen: Jeder Quadrant endet mit einer Überprüfung, während der das Team die Effektivität der zugehörigen SMFs auswertet. |
Abbildung 2: Das MOF-Prozessmodell
In der folgenden Tabelle werden der Dienstleistungszweck und die Überprüfung für die einzelnen Quadranten aufgeführt.
| Quadrant | Dienstleistungszweck | Überprüfung |
Änderung | Einführung neuer IT Lösungen, Technologien, Systeme, Anwendungen, Hardware und Prozesse. | Versionsbereitschaft |
Betrieb | Effektive und effiziente Ausführung täglich anfallender Aufgaben. | Betrieb |
Support | Schnelle Bearbeitung und Auflösung von Zwischenfällen, Problemen und Anfragen. | Service Level Agreement (SLA oder Vereinbarung auf Dienstebene) |
Optimierung | Durchführung von Änderungen zum Optimieren von Kosten, Leistung, Kapazität und Verfügbarkeit bei der Bereitstellung von IT-Diensten. | Genehmigte Version |
Zwei dieser Überprüfungen werden durch den Versionszeitplan bestimmt. Die Überprüfung 'Genehmigte Version' erfolgt, bevor eine Änderung an die Zielumgebung herausgegeben wird, und die Überprüfung 'Versionsbereitschaft' erfolgt bei der endgültigen Installation der Version. Die Überprüfungen 'Betrieb' und 'Service Level Agreement (SLA)' erfolgen in regelmäßigen Abständen nach der Einführung einer Version, um die internen Abläufe und die Leistung im Hinblick auf die Kundendienstebenen zu beurteilen.
Viele der MOF-SMFs basieren auf der IT Infrastructure Library von OGC. Die bemerkenswerten Ausnahmen sind Workforce Management (im Quadranten 'Optimierung') und sämtliche SMFs im Quadranten 'Betrieb'. Weil die ITIL plattformunabhängig ist, deckt sie diese Punkte nicht ab.
Infolgedessen stellt MOF im Quadranten 'Betrieb' den größten Teil der für Microsoft-Produkte und -Technologien spezifischen Hilfestellung beim Betrieb bereit. Da Microsoft den Schwerpunkt auf IT-Vorgänge legt, enthalten viele Produkte jetzt zusätzliche Features und Funktionen, die ihre Supportfähigkeit, Zuverlässigkeit und Verwaltbarkeit erhöhen sollen. MOF erweitert gegebenenfalls die grundlegenden IT-SMFs von ITIL mit speziellen Verweisen auf Microsoft-Produkte und -Features, die die Bereitstellung der SMF entweder automatisieren oder verbessern.
Diese IT-SMFs sind optimale Vorgehensweisen und müssen angepasst werden, um eindeutige oder spezielle Anforderungen einer bestimmten Betriebsumgebung zu erfüllen.
Informationen zu den Quadranten
In diesem Abschnitt wird erläutert, wie die vier Quadranten des MOF-Prozessmodells in einem spiralförmigen Versionslebenszyklus verknüpft sind. Diese Erläuterung setzt voraus, dass eine Version genehmigt und entwickelt wurde sowie in einer Produktionsumgebung bereitgestellt werden kann. Im IT-Lebenszyklus gibt es viele Punkte, mit denen diese Erläuterung begrifflich eingeleitet werden könnte, doch den intuitivsten Einstieg stellt dieser Punkt dar.
Änderung
Dieser Quadrant schließt sich an eine Überprüfung 'Genehmigte Version' an. Es ist die letzte Überprüfung, bevor eine vorgeschlagene Änderung an die Zielumgebung (Produktion) herausgegeben wird. Wenn die Überprüfung erfolgreich war, wird die Version durch folgende SMFs ausgeführt:
| • | Change Management: Identifiziert alle betroffenen Systeme und Prozesse vor Implementierung der Änderung, um eventuelle negative Folgen zu verringern oder auszuschalten. |
| • | Configuration Management: Identifiziert, protokolliert und verfolgt wichtige IT-Komponenten oder -Ressourcen und berichtet darüber. |
| • | Release Management: Erleichtert die Einführung von Software- und Hardwareversionen und stellt sicher, dass diese geplant, getestet und implementiert werden. Arbeitet mit den Prozessen Change Management und Configuration Management eng zusammen, um sicherzustellen, dass die gemeinsam genutzte Configuration Management Database (CMDB) auf dem neuesten Stand ist. |
Before the release is deployed into the production environment, a 'go' decision must be obtained at the release readiness review. Wenn die Version abgeschlossen ist, wertet die Überprüfung 'Versionsbereitschaft' die Effektivität der SMFs aus.
Betrieb
Unter der Voraussetzung einer erfolgreichen Bereitstellung ist die Version jetzt betriebsbereit. Anschließend beginnen folgende SMFs mit den täglichen Aktivitäten zum Betrieb des Systems:
| • | Security Administration: Verantwortlich für die Verwaltung einer sicheren Datenverarbeitungsumgebung durch das Entwickeln, Implementieren und Verwalten von Sicherheitskontrollen. |
| • | System Administration: Verantwortlich für die täglichen Aufgaben, mit denen die Ausführung der Unternehmenssysteme aufrechterhalten wird, sowie für die Bewertung der Auswirkung geplanter Versionen. |
| • | Network Administration: Verantwortlich für den Entwurf und die Wartung der physischen Komponenten, aus denen das Netzwerk der Organisation besteht, wie beispielsweise Server, Router, Switches und Firewalls. |
| • | Service Monitoring and Control: Beobachtet den Zustand eines IT-Dienstes und wird bei Bedarf tätig, um die Kompatibilität beizubehalten. |
| • | Directory Services Administration: Verantwortlich für täglich anfallende Prozesse, Wartung und Support des Unternehmensverzeichnisses. |
| • | Storage Management: Befasst sich mit lokaler und externer Datenspeicherung zum Zweck der Datenwiederherstellung und Verlaufsarchivierung. Stellt außerdem die physische Sicherheit von Sicherungskopien und Archiven sicher. |
| • | Job Scheduling: Weist Batchverarbeitungsaufgaben zu unterschiedlichen Zeitpunkten zu, um die Nutzung der Systemressourcen ohne Gefährdung der Unternehmens- und Systemfunktionen zu maximieren. |
| • | Print/Output Management: Verwaltet die mit den Unternehmensergebnissen verbundenen Kosten und Ressourcen und gewährleistet die Sicherheit der vertraulichen Ergebnisse. |
Die Überprüfung des Betriebs erfolgt regelmäßig. Sie konzentriert sich intern darauf, die Fähigkeit des IT-Personals zur Aufrechterhaltung eines bestimmten Dienstes und zur Dokumentierung der dabei gewonnenen Erfahrungen in einer 'Wissensdatenbank' (Knowledge Base) zu ermitteln.
Support
Nach Aufnahme des täglichen Betriebs treten zwangsläufig Probleme unterschiedlicher Art auf. Die Zielsetzung der folgenden SMFs ist die rechtzeitige Lösung von Zwischenfällen, Problemen und Anfragen für Endbenutzer:
| • | Service Desk: Bietet ersten Support für die Benutzercommunity bei Problemen, die mit der Nutzung von IT-Diensten verbunden sind. |
| • | Incident Management: Verwaltet den gesamten Verlauf der Problemlösung bei allen eintretenden Zwischenfällen. |
| • | Problem Management: Untersucht und löst die Ursachen von Fehlern und Störungen, die sich auf viele Kunden auswirken. |
Die Überprüfung 'SLA' erfolgt regelmäßig. Sie bewertet die Fähigkeit der Supportmitarbeiter, die in der Service Level Vereinbarung definierten Anforderungen an den IT-Betrieb zu erfüllen. Die Mitarbeiter führen Korrekturmaßnahmen in denjenigen Bereichen durch, deren Überprüfung fehlgeschlagen ist, und/oder sie handeln Änderungen in den Service Level Vereinbarungen aus. Darüber hinaus führen die Prozesse von Incident Management und Problem Management Änderungen an bestimmten Prozessen, Tools und Verfahren durch.
Optimierung
Die SMFs im Quadranten 'Betrieb' haben mit der Ausführung des Systems begonnen, und die SMFs des Quadranten 'Support' lösen tägliche Probleme. Die SMFs im Quadranten 'Optimierung' basieren auf einer langfristigen Sichtweise, wobei sie die aktuelle Leistung bewerten und Anforderungen bis sechs Monate im Voraus prognostizieren. Entsprechend kategorisiert ITIL die SMFs in den anderen Quadranten als betriebsbereit und die SMFs im Quadranten 'Optimierung' als taktisch:
| • | Service Level Management. Verwaltet die Qualität von IT-Diensten durch das Aushandeln, Überwachen und Warten von Service Level Vereinbarungen zwischen dem IT-Dienstanbieter und seinen Kunden. |
| • | Capacity Management: Plant, ändert die Größe und steuert die Kapazität der IT Lösung, um die Kundenanforderungen innerhalb der Leistungs-Levels zu erfüllen, die in der Service Level Vereinbarung festgelegt wurden. |
| • | Availability Management: Beschreibt, verwaltet, leitet und wartet proaktiv die Verfügbarkeit von Informationen und Diensten zu angemessenen Kosten und in Übereinstimmung mit den vereinbarten Qualitätsstufen. |
| • | Financial Management: Verwaltet monetäre Ressourcen zur Unterstützung von Organisationszielen. Das Financial Management kann Buchhaltung, Finanzplanung, Bewertungen von Projektinvestitionen und - in einigen Organisationen - Kostenabschreibung umfassen. |
| • | Workforce Management: Empfiehlt optimale Vorgehensweisen zum Anwerben, Weiterbeschäftigen, Verwalten und Motivieren der IT-Mitarbeiter. |
| • | Service Continuity Management: Diese früher als 'Notfallplanung' bekannte SMF plant die Bewältigung eines IT-Notfalles und die Wiederherstellung nach einem IT-Notfall. |
Die vorstehend aufgeführten SMFs definieren Änderungen (eine neue Version), die einerseits die Kosten reduzieren und andererseits die Dienstebenen beibehalten oder verbessern werden. Die Überprüfung 'Genehmigte Version' ist die letzte Überprüfung für die vorgeschlagenen Änderungen. Nach dieser Überprüfung beginnt ein neuer Zyklus mit den SMFs des Quadranten 'Änderung'.
Zusammenfassung
Im folgenden Diagramm wird der Versionslebenszyklus, einschließlich der vier Quadranten, der vier Überprüfungen und der 20 SMFs, dargestellt.
Abbildung 3: Das MOF-Prozessmodell und SMFs
Das MOF-Teammodell
Übersicht
Unternehmenswichtige Systeme sind komplex. Das Gleiche gilt für die zu ihrem reibungslosen Funktionieren erforderlichen Aktivitäten, wie in den SMFs des Prozessmodells dargestellt wird. Für die Ausführung dieser Aktivitäten und Prozesse müssen die Mitarbeiter im Betriebsteam gut organisiert und koordiniert sein, doch aufgrund der Komplexität der Arbeiten kann diese Anforderung nur unter Schwierigkeiten erreicht werden. Das MOF-Teammodell ist ein nützliches Tool, das die Ansicht von Teamrollen vereinfacht und dem Management hilft, sich auf das effektive Organisieren von Mitarbeitern zu konzentrieren.
Zu diesem Zweck verwendet das MOF-Teammodell Richtlinien für das IT-Service-Management. Diese Richtlinien basieren auf einer Gruppe von Qualitätszielen, die in erfolgreichen IT-Betriebsorganisationen aller Größen zu finden sind.
Das MOF-Teammodell beschreibt:
| • | Rollencluster für optimale Vorgehensweisen zum Strukturieren von Betriebsteams. |
| • | Die Schlüsselaktivitäten und Kompetenzen der einzelnen Rollencluster. |
| • | Die Verfahren zum Skalieren der Teams für unterschiedliche Größen und Unternehmenstypen. |
| • | Die Rollen, die effektiv kombiniert werden können. |
| • | Grundlegende Prinzipien, die beim Ausführen und Betreiben von verteilten Datenverarbeitungsumgebungen auf der Microsoft-Plattform helfen. |
| • | Beziehung des MOF-Teammodells zum MSF-Teammodell. |
Ursprung
Microsoft erstellte das MOF-Teammodell mithilfe der durch die Weiterentwicklung von MSF gewonnenen Erkenntnisse, aufbauend auf der optimalen Vorgehensweise von ITIL im Hinblick auf Organisationsstruktur und Prozessbesitz. Außerdem wurden dazu die wichtigen Erfolgsfaktoren modelliert, die von Partnern, Kunden und den firmeninternen IT-Gruppen bei Microsoft verwendet werden.
Ein wichtiger Aspekt des MOF-Teammodells ist seine Anwendbarkeit auf verteilte Teams, die verteilte Systeme verwalten. Die Prozessverwaltung konnte früher auf einfache Weise zentralisiert werden, solange die Datenverarbeitungsumgebung selbst zentralisiert war, weil die Teammitglieder normalerweise zu demselben Unternehmen gehörten und in demselben Gebäude arbeiteten. Heutzutage sind die Teams, die verteilte Datenverarbeitung verwalten, jedoch oft über geographische Grenzen, Zeitzonen und Unternehmen hinweg verteilt. Dies erschwert den zentralisierten Besitz von Prozessen und erfordert häufig ein neues Verfahren zum Strukturieren von Betriebsteams. Die optimalen Vorgehensweisen in MOF und ITIL können IT-Gruppen dabei helfen, den Wechsel hin zur gemeinsamen Verantwortlichkeit zu bewältigen.
Grundlegende Prinzipien
Zum Erstellen erfolgreicher, effizienter Betriebsteams wird mehr als nur die Beschreibung von Rollen und Verantwortungsbereichen benötigt. Erforderlich sind außerdem einheitliche Prinzipien, die ein Gefühl für gemeinsame Werte wecken und Richtlinien für das Funktionieren des Teams festlegen. Die fünf primären Prinzipien und Richtlinien für das MOF-Teammodell umfassen:
| • | Bereitstellen einer umfassenden Kunden Dienstleistung. |
| • | Verstehen der Unternehmensprioritäten, damit IT den wirtschaftlichen Nutzen erhöhen kann. |
| • | Aufbauen von starken, synergetischen, virtuellen Teams. |
| • | Nutzen von Tools für IT-Automatisierung und Wissensmanagement (Knowledge Management). |
| • | Anwerben, Entwickeln und Weiterbeschäftigen von leistungsfähigem IT-Betriebspersonal. |
Teamrollencluster
Das MOF-Teammodell basiert auf der Erfahrung, dass ein erfolgreiches Betriebsteam eine Reihe von wichtigen Qualitätszielen erreichen muss. Die Rollencluster des Teammodells definieren sechs allgemeine Kategorien von Aktivitäten und Prozessen. Die Prozesse innerhalb eines Rollenclusters unterstützen alle dasselbe Qualitätsziel. Es ist wichtig zu erkennen, dass es sich bei Rollenclustern um Gruppen von Aktivitäten handelt, die ein gemeinsames Ziel haben. Rollencluster sind keine Tätigkeitsbeschreibungen, und sie sind mit keinem Organigramm irgendeiner Art verbunden.
Die Anzahl der Personen für das Ausführen der einzelnen Rollen ist sehr unterschiedlich. In größeren IT-Organisationen kann ganzen Funktionsteams die Ausführung eines einzigen Prozesses innerhalb einer einzigen Rolle zugewiesen sein. So kann beispielsweise ein Dutzend Personen mit der Durchführung der Datenbankverwaltung - einem von mehreren Prozessen innerhalb der Betriebsrolle - befasst sein. Diese 12 Personen können einem virtuellen Prozessteam angehören, das von einem Prozessbesitzer geleitet wird und über mehrere Länder und Zeitzonen verteilt ist.
In kleineren Organisationen kann es erforderlich sein, Rollen zu kombinieren. Beispielsweise könnte eine Person in einer kleinen Zweigstelle für sämtliche Prozesse sowohl in der Sicherheitsrolle aus auch in der Infrastrukturrolle verantwortlich sein.
Das folgende Diagramm ordnet die sechs Rollencluster möglichen Funktionsteams in einer typischen Betriebsorganisation zu. Im Rest dieses Abschnitts werden die sechs Rollencluster ausführlicher behandelt.
Abbildung 4: Das MOF-Teammodell und Beispiele für Funktionsrollen oder Funktionsteams
Version (Release)
Das Betriebsteam muss vorhandene Ressourcen identifizieren und detailliert nachverfolgen, Prozesse klar dokumentieren und ein Änderungsprotokoll verwalten. Zum Erreichen dieses Zieles verfolgt der Versionsrollencluster normalerweise Änderungen und gewonnene Erkenntnisse in einer unternehmenseigenen Wissensdatenbank sowie Inventar und Änderungen in einer Configuration Management-Datenbank nach. Dieser Rollencluster ist außerdem die primäre Verbindung zwischen dem Projektentwicklungsteam und den Betriebsgruppen. Zudem enthält er die ITIL-Bereiche des Configuration Management sowie die Softwaresteuerung und -verteilung.
Infrastruktur
Ein effektiver IT-Betrieb muss physische Umgebungsstandards eindeutig definieren, physische Ressourcen verwalten, die IT-Infrastruktur pflegen und die Weiterentwicklung der Architektur überwachen. In erster Linie ist der Infrastrukturrollencluster für diese Aufgaben verantwortlich. Er erfüllt diese Ziele, indem er die Bausteine, von denen die End-to-End-Dienste abhängig sind, auswählt und verwaltet und indem er gemeinsame bzw. freigegebene Daten verwaltet. Darüber hinaus hilft er, Umzüge ganzer Gebäude- und Bürobelegschaften, Erweiterungen und Erwerbungen sowie physische Änderungen, wie z. B. Verdrahtung, Laborplatz und Benutzerkonnektivität, zu koordinieren.
Support
Für IT-Betriebsgruppen ist es wichtiger als je zuvor, über eine echte 'Servicekultur' zu verfügen, weil die Benutzer von Technologiesystemen in technischer Hinsicht selbst immer versierter werden und höhere Erwartungen an Systeme und die für den Support zuständigen Personen haben. Ein erfolgreiches Team stellt sicher, dass es hohe Supportstandards für interne und externe Kunden festlegt und erfüllt. Dies ist der Verantwortungsbereich des Supportrollenclusters.
Betrieb
Betriebsteams müssen sicherstellen, dass die täglichen Routineaufgaben zuverlässig ausgeführt werden. Der Betriebsrollencluster erfüllt dieses Ziel mit qualifizierten Fachleuten, die sich auf Technologiebereiche und Produktionssysteme spezialisiert haben, z. B. auf Messaging, Systemverwaltung, Telekommunikation, Netzwerke und Datenbankverwaltung. Weitere Aufgaben umfassen geplante, sich wiederholende Prozesse, wie Datensicherung, -archivierung und -speicherung, Output Management, Systemüberwachung und Ereignisprotokollverwaltung sowie Datei- und Druckserververwaltung.
Partner
Für die Bereitstellung von IT-Diensten sind zunehmend Partnerschaften mit anderen Unternehmen erforderlich. Das Definieren und Verwalten dieser Partnerschaften auf eine gegenseitig vorteilhafte und kostengünstige Weise ist für den Erfolg aller Beteiligten äußerst wichtig. Dies ist der Verantwortungsbereich der Partnerrolle. Der Partnerrollencluster umfasst sowohl den internen Manager, der für die Beziehungen zwischen den externen Parteien verantwortlich ist, als auch die Parteien selbst.
Sicherheit
Das primäre Ziel dieses Rollenclusters ist das Sicherstellen von Datenvertraulichkeit, Datenintegrität und Datenverfügbarkeit. Die Spezialisten im Sicherheitsrollencluster erfüllen diese Ziele mithilfe von Technologien, doch auch durch Einflussnahme auf die Unternehmensrichtlinien, wie z. B. durch Definieren von Verfahren, die beim Ausscheiden eines Mitarbeiters aus der Firma zu beachten sind.
Verbinden des Prozess- und des Teammodells
Die Teamrollencluster richten sich normalerweise an den vier Prozessquadranten des MOF-Prozessmodells aus, wie im folgenden Diagramm dargestellt wird. Beachten Sie, dass mehrere Rollen zu einem einzigen Quadranten gehören können und dass eine einzige Rolle (z. B. 'Lieferant' oder 'Sicherheit') in mehreren Quadranten enthalten sein kann.
Abbildung 5: MOF-Teamrollencluster und ihre Anpassung an das MOF-Prozessmodell
Das MOF-Risikomodell
Übersicht
Das Risikomodell für den Betrieb wendet bewährte Techniken des Risikomanagements auf die Probleme an, mit denen das Betriebspersonal täglich konfrontiert wird. Es gibt viele verschiedene Modelle, Rahmenstrukturen und Prozesse zum Verwalten von Risiken. Alle beschäftigen sich mit der Planung einer ungewissen Zukunft, und das Risikomodell für den Betrieb bildet hier keine Ausnahme. Dank seiner grundlegenden Prinzipien, einer benutzerdefinierten Terminologie, eines strukturierten, wiederholbaren Prozesses aus fünf Schritten und der Integration in eine größere Betriebsrahmenstruktur ist es jedoch wertvoller als viele andere Modelle.
Ursprung
Das Risikomodell für den Betrieb wurde als Reaktion auf die Kundenwünsche nach einer Rahmenstruktur entwickelt, die Organisationen beim Verwalten von Risiken während der Ausführung ihrer Geschäftsabläufe auf der Microsoft-Plattform helfen sollte. Microsoft Solutions Framework definierte ein in vielen Bereichen anwendbares Risikomodell, dessen Beschreibung angepasst wird, um das Risikomanagement während Projekten, insbesondere der Softwareentwicklung und -bereitstellung, durchzuführen. Das Risikomodell für den Betrieb basiert auf dem MSF-Risikomodell, das erweitert und angepasst werden kann, um die Anforderungen von Betriebsgruppen zu erfüllen.
Grundlegende Prinzipien
Dieses Risikomodell wendet folgende Prinzipien für ein erfolgreiches Risikomanagement im Betrieb an:
| • | Kontinuierliches Bewerten von Risiken: Dies bedeutet, dass das Team die Suche nach neuen Risiken niemals beendet und dass bekannte Risiken regelmäßig neu bewertet werden. |
| • | Integrieren des Risikomanagements in jede Rolle und jede Funktion: Grundsätzlich übernimmt jede IT-Rolle einen Teil der Verantwortung für das Risikomanagement, und beim Entwerfen jedes IT-Prozesses wird das Risikomanagement beachtet. |
| • | Positives Umgehen mit der Risikoidentifizierung: Damit das Risikomanagement erfolgreich ist, müssen die Teammitglieder bereit sein, Risiken ohne Furcht vor Kritik oder Sanktionen zu identifizieren. |
| • | Verwenden von risikobasierter Zeitplanung: Zur Aufrechterhaltung einer Umgebung ist es oft erforderlich, Änderungen der Reihe nach vorzunehmen. Dabei sollte das Team die riskantesten Änderungen nach Möglichkeit zuerst vornehmen, damit für Änderungen, die nicht herausgegeben werden können, keine Zeit und Ressourcen verschwendet werden. |
| • | Festlegen eines akzeptablen Formalitätsniveaus: Ein erfolgreicher Prozess muss vom Team verstanden und tatsächlich angewendet werden. |
Diese Prinzipien werden im Begriff proaktiv zusammengefasst. Ein Team, das proaktives Risikomanagement betreibt, erkennt an, dass Risiken ein normaler Bestandteil des Betriebs sind. Statt Risiken zu fürchten, betrachtet sie das Team als eine Gelegenheit zum Schutz künftiger Versionen. Die Teammitglieder zeigen eine proaktive Einstellung, indem sie einen sichtbaren, messbaren, wiederholbaren und kontinuierlichen Prozess zur objektiven Bewertung von Risiken und Gelegenheiten anwenden und dann Maßnahmen ergreifen, die sich sowohl mit den Ursachen der Risiken als auch mit deren Symptomen befassen.
Risikomanagementprozess
Im folgenden Diagramm werden die fünf Schritte des Risikomanagementprozesses dargestellt: Identifizieren, Analysieren, Planen, Nachverfolgen und Steuern. Es ist wichtig zu verstehen, dass jedes Risiko alle diese Schritte mindestens einmal - und oft zahlreiche Male - durchläuft. Außerdem besitzt jedes Risiko einen eigenen Zeitrahmen. Deshalb können in jedem Schritt zu jedem beliebigen Zeitpunkt mehrere Risiken vorhanden sein.
Abbildung 6: Der Risikomanagementprozess
Der Risikoprozess umfasst die folgende Liste von Risiken:
| • | Risikobewertungsdokument: In den ersten drei Schritten werden Informationen zu einem bestimmten Risiko gesammelt und zum Risikobewertungsdokument hinzugefügt. In den letzten beiden Schritten wird dieses Dokument zur Unterstützung bei der Entscheidungsfindung herangezogen. |
| • | Liste der wichtigsten Risiken: Diese Liste identifiziert die wenigen Hauptrisiken, die den größten Anspruch auf die begrenzte Zeit und die beschränkten Ressourcen des Teams haben. |
| • | Liste der zurückgezogenen Risiken: Jedes irrelevant gewordene Risiko wird aus der Liste der Hauptrisiken in die Liste der zurückgezogenen Risiken verschoben. Diese Liste dient als Verlaufsreferenz, an die das Team sich zukünftig halten kann. |
Der Prozess umfasst folgende fünf Schritte:
| • | Schritt 1: Identifizieren. Ermitteln folgender Faktoren: Quelle des Risikos, Fehlerart, Bedingung, Folge für den Betrieb sowie Folge für das Unternehmen. |
| • | Schritt 2: Analysieren. Ermitteln der Wahrscheinlichkeit und Auswirkung des Risikos sowie Verwenden der Ergebnisse zur Berechnung eines Gefährdungswertes als Hilfe beim Einstufen von Risiken. |
| • | Schritt 3: Planen. Definieren von abschwächenden Faktoren, die das Risiko ganz vermeiden, es auf eine andere Partei übertragen oder aber die Auswirkung oder Wahrscheinlichkeit oder beides reduzieren. Definieren von Notfallplänen, die beim Eintreten des Risikos auszuführen sind. Definieren von Triggern, die das baldige Eintreten des Risikos anzeigen. |
| • | Schritt 4: Nachverfolgen. Sammeln von Informationen darüber, wie sich verschiedene Elemente des Risikos im Lauf der Zeit ändern. |
| • | Schritt 5: Steuern. Ausführen einer geplanten Reaktion auf bestimmte Änderungen. Beispiele: Wenn ein Triggerwert wahr wird, wird der Notfallplan ausgeführt. Wenn ein Risiko nicht mehr relevant ist, wird dieses Risiko zurückgezogen. Wenn sich die Auswirkung geändert hat, wird der Zyklus beim Schritt 'Analysieren' neu gestartet, um die Auswirkung neu zu bewerten. |
Beispiel
Eine Person, die in der Betriebsrolle mit dem Verantwortungsbereich Availability Management für den Messagingdienst des Unternehmens tätig ist, erkennt, dass der Personalabbau infolge einer Fusion die Gruppe an der Erfüllung ihrer Anforderungen hindern würde.
| Risikokomponente | Erklärung |
Quelle des Risikos: | Technologie (die anderen Optionen sind 'Personen', 'Prozess' und 'extern'). |
Fehlerart: | Leistung (die anderen Optionen sind 'Kosten', 'Flexibilität' und 'Sicherheit'). |
Bedingung: Wenn sich in Zukunft Folgendes herausstellt ... | Die einzige Energieversorgung des E-Commerce-Webservers fällt aus. |
Folge für den Betrieb: ... dann wird der Betrieb folgendermaßen beeinträchtigt ... | Kauf einer neuen Energieversorgung; ein Techniker unterbricht eine andere Arbeit, um die neue Energieversorgung zu installieren. |
Folge für das Unternehmen: ... und das Unternehmen insgesamt wird folgendermaßen gefährdet ... | Kunden können die Site nicht nutzen, wodurch sie einen schlechten Eindruck vom Unternehmen erhalten. Einige Kunden wechseln dauerhaft zur Site eines Konkurrenten. |
Wahrscheinlichkeit: Die Möglichkeit der Bedingung ist gleich ... | 0,001 (1 in 1.000) pro Monat für die ersten drei Betriebsjahre des Dienstes. |
Auswirkung: Die Auswirkung, wenn die Folge für das Unternehmen wäre ... | Unter der Voraussetzung einer Skala von 1 bis 10 (mit 1 als niedrigstem Wert) wird die Folge für das Unternehmen bei dieser Firma auf 8 geschätzt. |
Gefährdung: Die Wahrscheinlichkeit, multipliziert mit der Auswirkung, ist gleich ... | 0,008 |
Abschwächende Faktoren: Vor Eintreten der Bedingung wird versucht, die Auswirkung und/oder die Wahrscheinlichkeit zu reduzieren durch ... | Reduzieren der Wahrscheinlichkeit, indem eine Diagnose ausgeführt und eine alte Energieversorgung vor ihrem Ausfall ersetzt wird. Reduzieren der Auswirkung des Ausfalls einer einzigen Energieversorgung, indem auf einen Server mit redundanter Energieversorgung umgeschaltet wird und Ersatzteile stets vor Ort verfügbar sind, um die Ausfallzeit zu minimieren. |
Trigger: Wenn die Bedingung nahe bevorsteht (jedoch noch nicht eingetreten ist), wird dies durch Folgendes mitgeteilt ... | Die Bedingung gilt als nahe bevorstehend, wenn regelmäßige Diagnosen einen Abwärtstrend der Zuverlässigkeit anzeigen, der einen bestimmten Grenzwert erreicht. Dienstprogramme für automatisierte Überwachung zeigen an, wenn ein tatsächlicher Ausfall vorliegt. |
Notfall: Wenn die Bedingung nicht verhindert werden kann, wird auf den Trigger folgendermaßen reagiert ... | Sofortiger Austausch der Energieversorgung gegen ein Ersatzteil. Wenn kein Ersatzteil verfügbar ist - Herunterfahren und Abschalten eines Servers, der einen Dienst mit niedrigerer Priorität unterstützt, und Installieren seiner Energieversorgung im E-Commerce-Webserver. |
MOF und Microsoft Solutions Framework
Zusammenarbeit der beiden Rahmenstrukturen
An einer IT-Lösung sind in der Regel zwei IT-Teams beteiligt. Ein Projektteam wird für einen begrenzten Zeitraum zum Planen, Erstellen und Bereitstellen (Umsetzung) der Lösung zusammengestellt. MSF ist zur Unterstützung dieses Projektteams gedacht. Im Gegensatz dazu ist das Betriebsteam dauerhaft tätig und für den täglichen Einsatz der Lösung im Betrieb sowie ihre künftige Weiterentwicklung verantwortlich. MOF ist zur Unterstützung des Betriebsteams konzipiert. Die beiden Rahmenstrukturen müssen sich von Anfang an überschneiden, um sicherzustellen, dass die Lösung des Projektteams nach der Bereitstellung betrieben werden kann.
MSF verfügt über sechs Rollen, darunter eine Rolle für Logistik (equivalent zu MOF Release). Eine Person aus dem Betriebsteam - normalerweise aus der MOF-Release-Rolle - ist Mitglied des MSF-Teams in dessen Logistikrolle. Diese Person vertritt die Interessen des Betriebsteams während des gesamten Entwicklungszyklus der MSF-Lösung, doch insbesondere während der Überprüfung 'Genehmigte Freigabe'. Außerdem testet das Projektteam die Lösung während der MSF-Stabilisierungsphase, in der das Betriebsteam die Pilottestumgebung betreibt.
Wo sollte begonnen werden?
Beliebiger Ausgangspunkt, beliebige Fortsetzung
Eine IT-Organisation kann mit dem Einsatz von MOF an einer beliebigen Stelle in der Umgebung beginnen und dann in andere Bereiche verzweigen. Da jedoch die Helpdesk- und Verfügbarkeitsgruppen die MOF-Unterstützung in Form von optimalen Vorgehensweisen oft am dringendsten benötigen, liegen hier die gebräuchlichsten Ausgangspunkte.
Weitere Informationen
Kurse
Informationen zur Verfügbarkeit von Kursen finden Sie unter http://www.microsoft.com/mof (englischsprachig).
Bücher
Wenn Sie weitere Informationen zu den in diesem Whitepaper erläuterten Konzepten erhalten möchten, wird folgendes Buch empfohlen:
IT Service Management, IT Service Management Forum/CCTA, ITIMF Ltd., 1995.
Websites
Weitere Informationen zu den Microsoft-Rahmenstrukturen und anderen Angeboten für Unternehmen finden Sie unter:
| • | http://www.microsoft.com/msf/ (englischsprachig) |
| • | http://www.microsoft.com/es/ (englischsprachig) |
Weitere Informationen zu ITIL finden Sie unter http://www.itil.co.uk/ (englischsprachig)
Weitere Informationen zum Help Desk Institute finden Sie unter http://www.helpdeskinst.com/ (englischsprachig)
Mitarbeiter
Autoren
Bret Clark, Microsoft Corporation
Neil Fairhead, Microsoft Corporation
Kathryn Rupchock Pizzo, Microsoft Corporation
Redaktion
Laurie Dunham, Microsoft Corporation
Weitere Mitarbeiter
Bill Bagley, Microsoft Corporation
Anthony Baron, Microsoft Corporation
Mary Anne Blake, Microsoft Corporation
Jeff Yuhas, Microsoft Corporation
Rechtlicher Hinweis:
Die in diesem Dokument enthaltenen Informationen stellen die behandelten Themen aus der Sicht der Microsoft Corporation zum Zeitpunkt der Veröffentlichung dar. Da Microsoft auf sich ändernde Marktanforderungen reagieren muss, stellt dies keine Verpflichtung seitens Microsoft dar, und Microsoft kann die Richtigkeit der hier dargelegten Informationen nach dem Zeitpunkt der Veröffentlichung nicht garantieren.
Dieses Dokument dient nur zu Informationszwecken. MICROSOFT SCHLIESST FÜR DIE INFORMATIONEN IN DIESEM DOKUMENT JEDE GEWÄHRLEISTUNG AUS, SEI SIE AUSDRÜCKLICH ODER KONKLUDENT.
Die Benutzer/innen sind verpflichtet, sich an alle anwendbaren Urheberrechtsgesetze zu halten. Unabhängig von der Anwendbarkeit der entsprechenden Urheberrechtsgesetze darf ohne ausdrückliche schriftliche Erlaubnis der Microsoft Corporation kein Teil dieses Dokuments für irgendwelche Zwecke vervielfältigt oder in einem Datenempfangssystem gespeichert oder darin eingelesen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen, usw.) dies geschieht.
Es ist möglich, dass Microsoft Rechte an Patenten bzw. angemeldeten Patenten, an Marken, Urheberrechten oder sonstigem geistigen Eigentum besitzt, die sich auf den fachlichen Inhalt dieses Dokuments beziehen. Das Bereitstellen dieses Dokuments gibt Ihnen jedoch keinen Anspruch auf diese Patente, Marken, Urheberrechte oder auf sonstiges geistiges Eigentum, es sei denn, dies wird ausdrücklich in den schriftlichen Lizenzverträgen von Microsoft eingeräumt.
Sofern nichts anderes angegeben ist, sind die in den Beispielen verwendeten Firmen, Organisationen, Produkte, Domänennamen, E-Mail-Adressen, Logos, Personen, Orte und Ereignisse frei erfunden. Jede Ähnlichkeit mit bestehenden Firmen, Organisationen, Produkten, Domänennamen, E-Mail-Adressen, Logos, Personen, Orten oder Ereignissen ist rein zufällig.
© 2003, Microsoft Corp. Alle Rechte vorbehalten.
Microsoft, das Windows-Logo, Windows, Windows Media, Active Directory und Windows NT sind eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern.
Die in diesem Dokument aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.