Das SOUSIS-Modell by Daniel Wobmann https://padlet.com/d_wobmann/gz7l6r7ukloo Quelle: https://www.informatik-aktuell.de/management-und- recht/projektmanagement/service-level-agreements-effektiv-managen.html en-us 2019-05-01 14:54:41 UTC 2025-12-10 01:20:11 UTC hello@padlet.com https://imgglb.padletcdn.com/v13/image?t=g_auto&url=https%3A%2F%2Fpadlet.net%2Ficons%2Fpng%2F1f5c2.png Ziel des Vorgehensmodells d_wobmann https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/355825493 Das Vorgehensmodell (...) muss auf die Geschäftswelt anwendbar sein, also verschiedene Betriebsabläufe sowie Vertragsbeziehungen berücksichtigen und zugleich die Technik so beherrschen, dass die IT-Services kundenorientiert konfektioniert werden können.]]> 2019-05-01 15:08:25 UTC https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/355825493 Anforderungen an das Vorgehensmodell d_wobmann https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/355826955 Anforderungen aus bestehenden Betriebsstrukturen
Anforderungen an das Vorgehensmodell ergeben sich aus Betriebsstrukturen. Diese Strukturen werden [zum Beispiel] im Rechenzentrum aufgebaut, um einen kontrollierten Ablauf im Betrieb zu gewährleisten. Dieser kontrollierte Ablauf ist insbesondere bei der Konfektionierung von Leistungen zu gewährleisten. Hierfür muss das Vorgehensmodell eine probate Lösung liefern.
Die Betriebsstrukturen unterscheiden sich in jedem IT-Betrieb, auch wenn Standards wie ITIL eingehalten werden. Das Vorgehensmodell muss einerseits den Standards genügen, andererseits genügend Flexibilität aufweisen, um generisch anwendbar zu sein.
Beispiele:


Anforderungen aus entstehenden Geschäftsstrukturen
Die Anforderungen die aus dem Betrieb gestellt wurden, zeigen, dass dies nur eine Sichtweise ist. Weitere Anforderungen werden über das Management gestellt. Im konkreten sind damit juristische Geschäftsstrukturen zu betrachten. Entscheidend sind dabei die Vertragspartner und die Leistungsgeber und –nehmer. Diese Geschäftsstrukturen müssen so unterstützt werden, dass sie die Geschäftsbeziehungen, z.B. Provider – Servicenehmer, Provider – Zulieferer, etc. ermöglichen.

Anforderungen durch technische Gegebenheiten
Die Vielzahl von technischen Systemen, die in Rechenzentren eingesetzt werden, stellen neue Herausforderungen und somit Anforderungen an das Vorgehensmodell.
Beispiele:


]]> 2019-05-01 15:11:08 UTC https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/355826955 d_wobmann https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/355841318 2019-05-01 15:37:01 UTC https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/355841318 d_wobmann https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/355841562 Die Ablaufbeschreibung wird unterteilt in den Standardablauf, die OLA-Erweiterung und die UC-Erweiterung.
Der Standardablauf beschreibt, wie man die im Servicekatalog dokumentierten Services in das Service Level Agreement übernimmt und um weitere vertragsrelevante Aspekte erweitert. Anschließend wird die Einordnung des SLAs bzgl. Rahmenverträge etc. vorgenommen. Die agierende Rolle ist dabei [zum Beispiel] das Rechenzentrum, das gegenüber Kunden die IT-Services beschreibt und verkauft.
Muss [wie in diesem Fall] das Rechenzentrum interne IT-Abteilungen zur Erbringung einer Kundenleistung koordinieren, so wird eine OLA-Erweiterung erforderlich. Diese Erweiterung beschreibt, wie z.B. mehrere am Service eines Kunden beteiligten IT- Abteilungen ihre Qualität dokumentieren und diese im SLA abstimmt festlegen.
Befindet sich das Rechenzentrum in der Rolle, dass es von externen Unternehmen Leistungen beziehen muss, um die Leistung gegenüber dem Kunden zu erbringen, so sind die nach ITIL definierten "Underpinning Contracts" (UC) erforderlich. Diese müssen ebenfalls mit dem SLA des Rechenzentrums, das als Generalunternehmer gegenüber dem Kunden auftritt, abgestimmt sein. Hierfür müssen besonders die Service Levels (SL) entsprechend kalkuliert sein.]]> 2019-05-01 15:37:25 UTC https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/355841562 d_wobmann https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/355846731 1. Servicekatalog
Den Einstiegspunkt beim Standardablauf bietet der Servicekatalog. Die zentralen im IT-Betrieb vorliegenden IT-Services müssen erhoben werden. Dabei werden vom Servicekatalog wesentliche Strukturen vorgegeben, sodass eine einfache Erhebung der Services aus dem IT-Betrieb möglich ist. Zu jedem Dienst liegen nach Fertigstellung des Servicekatalogs die zentralen Parameter zu Serviceklasse, -betrieb und -überwachung, unabhängig von einer konkreten Kundenbeziehung, vor. Diese Vorarbeit ist zwingend im Vorfeld zu leisten, um die Service Levels und weitere relevante Parameter miteinander vergleichen zu können. Ebenfalls gelten unternehmensweite Service Levels, die im Servicekatalog als übergeordnete Service Levels gekennzeichnet sind und für alle Services gelten (z.B. Support- und Pikettzeiten).

2. Service Level Agreement
Aus dem Servicekatalog heraus, werden die Leistungen für das Service Level Agreement zusammengestellt. Der Servicekatalog ist als Vorstufe für das Service Level Agreement zu verstehen. Die einzelnen Dienste sind atomar aufgebaut, sodass sie wie Module behandelt und für den Kunden individuell zusammengestellt werden können. Durch die Normierung können die Werte zu den Diensten nach der Zusammenstellung miteinander abgeglichen werden, sodass eine homogene Kundenlösung entsteht. Müssen mehrere Dienste gegenüber einem Kunden für getrennte Geschäftszwecke – z. B. Callcenter, Buchhaltung, Logistik – gekoppelt werden, so können diese in einem SLA zusammengefasst sein oder in mehrere SLAs aufgetrennt werden.
Nachdem die Leistungen des Servicekatalogs im SLA abgestimmt sind, werden die Verantwortlichkeiten zwischen beiden Vertragsparteien verhandelt. Dabei sind die Punkte Verantwortung, Durchführung, Mitwirkung und Informationspflicht zur kontinuierlichen Leistungserhaltung und -erbringung gemeinsam zu klären.

3. IT-Rahmenvertrag
Nachdem das Service Level Agreement in seiner Ausprägung umfassend beschrieben ist, wird es dem entsprechenden IT-Rahmenvertrag zugeordnet. Somit sind im Wesentlichen die technischen Rahmenbedingungen festgelegt. Eine Weiterführung der organisatorisch abzustimmenden Werte erfolgt im IT- Rahmenvertrag. Im vorliegenden Ansatz wurde darauf geachtet, dass das SLA und der IT-Rahmenvertrag überschneidungsfrei aufgebaut sind. Dies erleichtert die Handhabung bei Änderungen durch neu hinzukommende, sich ändernde oder wegfallende Leistungen. Eine Besonderheit ist z. B. die Trennung von Verantwortlichkeiten im SLA und den Verantwortlichen im IT-Rahmenvertrag, die namentlich erwähnt sind und gegenzeichnen müssen. Somit bleiben auch Änderungen auf den IT-Rahmenvertrag begrenzt und sind dadurch ebenfalls beherrschbar.

4. Mitgeltende Dokumente
Der IT-Rahmenvertrag verweist u. a. auf bestimmte unternehmensinterne Dokumente, die z. B. bestimmte Abläufe definieren. Ein zentrales Dokument, dem hier eine besondere Stellung zukommt, ist die Minderungsregelung. Hier wird definiert, wie bei Leistungsverzögerung oder -ausfall im konkreten Fall vorgegangen wird. Dies sind meist Regelungen, die erst ab einem festgelegten Niveau der Leistungsminderung eintreten und eine Reduzierung der Leistungsverrechnung ergeben.]]> 2019-05-01 15:47:19 UTC https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/355846731 d_wobmann https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/355857379 Nachdem der Standardablauf erfolgt ist, kann es wie oben genannt zu Erweiterungen kommen. Der interne Betrieb größerer Rechenzentren ist meist in einzelne IT-Abteilungen für z. B. Serverbetrieb und Applikationshosting aufgeteilt. Werden gegenüber Kunden komplexe Leistungen angeboten, die aus den IT-Services der jeweiligen Abteilungen zusammengesetzt werden, so sind Operation Level Agreements nach ITIL zu definieren. Das Modell greift diese Tatsache auf und setzt es über ein gemeinsames Template um. Sowohl die Strukturen des Servicekatalogs, als auch die im Service Level Agreement enthaltenen, kommen hier analog zum Einsatz. Es sind auch die Basisleistungen der IT in einem oder mehreren Servicekatalogen zu definieren. Nach dem Angebot aus dem Servicekatalog können die einzelnen IT-Abteilungen ein oder mehrere Services in einem OLA zusammenstellen und diesen abstimmen. Basierend auf diesen OLAs können jetzt die Werte und Service Levels mit einem Service Level Agreement verglichen und abgestimmt werden.
Innerhalb der OLA-Erweiterung ist ein Service Level Kalkulator aufzubauen, der zur Darstellung und gegenseitigen Berechnung von Service Levels dient. Aus dem Kalkulator werden anschließend die Werte in den jeweiligen OLAs oder SLAs übernommen. Aufgrund des Szenarios, dass Leistungen von "unten" eingekauft und "oben" angeboten werden, ergibt sich meist die Richtung, dass die OLAs maßgeblich das SLA beeinflussen und entscheiden.]]> 2019-05-01 16:08:55 UTC https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/355857379 d_wobmann https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/355858936 Werden externe Unternehmen bei der Erbringung von IT-Services vertraglich eingebunden, so spricht man laut ITIL von Underpinning Contracts. Letztlich sind diese Verträge analog zu SLAs zu verstehen. Wird z. B. eine Netzleistung eingekauft und später mehrfach für den Transport von IT-Applikationen verwendet, so wird aus der Sicht des Providers aus dem SLA ein Underpinning Contract. Die UC-Erweiterung ist flexibel in das gesamte Vorgehensmodell einfügbar. Es sind jedoch einige Besonderheiten besonders zu berücksichtigen:
  • Die Leistungen sind meist nicht in einem IT-Servicekatalog definiert. Jedes Unternehmen definiert eigene Services. Für diesen Fall müssen die Services dennoch entsprechend normiert werden. Die UC-Erweiterung leistet dies, indem das UC das SLA-Template verwendet und somit konform zum OLA und SLA wird. Über diesen Mechanismus lassen sich heterogene, von externen Unternehmen kommende Leistungen normieren.
  • Die UC-Erweiterung setzt sich aus dem Standardablauf und der OLA-Erweiterung zusammen. Vom Standardablauf werden das SLA-Template und das Konzept zur inhaltlichen Trennung im IT-Rahmenvertrag übernommen. Im IT-Rahmenvertrag können ggf. andere Aspekte auftreten, sodass eine inhaltliche Trennung als kleinster gemeinsamer Nenner umsetzbar ist.
  • Aus der OLA-Erweiterung wird der Service Level Kalkulator verwendet, um die Abstimmung zwischen SLA und OLA vornehmen zu können.
]]> 2019-05-01 16:11:55 UTC https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/355858936 d_wobmann https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/356815682 Siehe hierzu auch:
«ManagementvonServicel-Level-Agreements», Robert Scholdener,dpunkt.verlag; 2. aktualisierte und erweiterte Auflage 2016, Kapitel 3.1.3 Das SOUSIS-Modell, Seite 93ff.]]> 2019-05-04 10:51:10 UTC https://padlet.com/d_wobmann/gz7l6r7ukloo/wish/356815682