Sie sind auf Seite 1von 9

DevOps Sourcing

Anhang – 3.1 Service Level Description


Version 1.1

zwischen
BMW AG („BMW“)
Bremerstraße 6
80788 München

und
TE MP LA TE F I L E („Auftragnehmer“)
[Straße]
[PLZ Ort]
DevOps Sourcing BMW AG (Auftraggeber)
Service Level Description Template File (Auftragnehmer)
Version 1.1

INHALTSVERZEICHNIS

Template File ............................................................................................................................1

1 Einleitung ............................................................................................................................3

2 SERVICE- und BEREITSCHAFTSZEITen ....................................................................................3

3 Lösungszeiten ......................................................................................................................4

4 Service Level Matrix .............................................................................................................4

5 Service Level Typen ..............................................................................................................4


5.1 Customer Experience ...........................................................................................................4
5.2 Governance ..........................................................................................................................5
5.3 Verfügbarkeit .......................................................................................................................6
5.4 Ticket Management .............................................................................................................7
5.5 Continuous SERVICE Improvement......................................................................................7
5.6 Development Quality ...........................................................................................................8

Seite ii
DevOps Sourcing BMW AG (Auftraggeber)
Service Level Description Template File (Auftragnehmer)
Version 1.1

1 EINLEITUNG
Dieser Anhang 3.1 (SERVICE Level Description) spezifiziert die in Anhang 3.3 (SERVICE Level Matrix)
definierten SERVICE Level. Die Spalte „Referenz ID“ in Anhang 3.3 (SERVICE Level Matrix) referenziert für
jedes dort definierte SERVICE Level auf die in diesem Anhang 3.1 (SERVICE Level Description) enthaltene
Beschreibung. Alle in diesem Anhang 3.1 (SERVICE Level Description) in Bezug auf ein spezifiziertes
SERVICE Level genannten Anforderungen und Bedingungen gelten damit ergänzend zu den Definitionen
in Anhang 3.3 (SERVICE Level Matrix).

2 SERVICE- UND BEREITSCHAFTSZEIT EN


Die SERVICEZEIT variiert je nach gewählter Time Zone. Dabei sind drei unterschiedliche Time Zones
festgelegt:

Time Zone SERVICEZEIT Enthaltene Regionen

Europe 07:00 – 18:00 (CET) West-, Ost- und Mitteleuropa

Western 07:00 – 18:00 (EST) Nord- und Südamerika

Eastern 07:00 – 18:00 (CNST) APAC

Diese SERVICEZEIT gilt von Montag bis Freitag. Optional kann die SERVICEZEIT auf Montag bis Samstag
erweitert werden. Die SERVICEZEITEN gelten auch an Feiertagen.
Folgende Modelle für BEREITSCHAFTSZEITen gibt es:

Bereitschaft(OnCall) Bearbeitung von „Critical“ und „High“ Tickets

None Nur während der SERVICEZEIT

Night Während der SERVICEZEIT und den jeweils zugehörigen


Nächten, d.h. von Montag 0 Uhr bis Freitag 24 Uhr („24*5“)
bzw. Montag 0 Uhr bis Samstag 24 Uhr („24*6“)

Full Rund um die Uhr, d.h. von Montag 0 Uhr bis Sonntag 24 Uhr
(„24*7“)

SERVICES, die unabhängig von der vereinbarten SERVICEZEIT (7*24) rund um die Uhr erbracht werden:
 Availability Management (Sub-Prozess: Verfügbarkeitsüberwachung und –Analyse)
 Change Management (Sub-Prozess: Bewertung und Durchführung von Emergency Changes)
 IT Operations Control (Sub-Prozess: System Überwachung)

Seite 3
DevOps Sourcing BMW AG (Auftraggeber)
Service Level Description Template File (Auftragnehmer)
Version 1.1

3 LÖSUNGSZEITEN
Die Lösungszeit wird gemessen ab Zuweisung eines Tickets an den Auftragnehmer. Die Zuweisung kann
nur innerhalb der SERVICEZEIT erfolgen.

Priorität Geforderte Lösungszeit für Tickets

Critical 1 Stunde

High 4 Stunden

Medium 11 Stunden

Low 33 Stunden

Die Messung der tatsächlichen Lösungszeit erfolgt nur während der SERVICEZEITEN (für Prioritäten
Medium und Low) bzw. während der SERVICEZEITEN oder BEREITSCHAFTSZEITen (für Prioritäten Critical
und High).

4 SERVICE LEVEL MATRI X


Die für diesen Vertrag verwendeten SERVICES Level, inklusive SERVICE Level Typen, SERVICE Level Credit
Percentage, At Risk Fee und At-Risk Percentage sowie Bonus und Messperiode sind dem Anhang 3.3
(SERVICE Level Matrix) zu entnehmen. Die Definition der Messgrößen, inkl. der Definition des
Algorithmus zur Berechnung der SERVICE Level Performance erfolgt in Kapitel 5 (SERVICE Level Typen).

5 SERVICE LEVEL TYPEN


Diese Ziffer 5 enthält Kennzahldefinitionen, die den in Anhang 3.3 (SERVICE Level Matrix) definierten
SERVICE Levels zugrunde liegen. Weitere Spezifikationen zu aktuell verwendeten Tools und
Prozessschritten der einzelnen Messungen sind dem SERVICE Level Performance Handbuch zu
entnehmen.
Alle nachfolgend definierten SERVICE Level werden auf der Ebene Line Item der Entity List der Sourcing
Unit gemessen.
Wenn nicht anders vorgegeben erfolgt die Messung jeweils nach Abschluss des letzten Tages innerhalb
der Messperiode.

5.1 Customer Experience


SERVICE Level Agreements, die der Kategorie „Customer Experience“ zugeordnet sind:

5.1.1 Kundenzufriedenheit (F-CE-1)


Diese Kennzahl ist ein Kombinations-SERVICE-Level und beschreibt die Zufriedenheit mit den jeweiligen
SERVICES, die durch den Auftragnehmer erbracht werden. Die einzelnen Umfrageergebnisse der beiden

Seite 4
DevOps Sourcing BMW AG (Auftraggeber)
Service Level Description Template File (Auftragnehmer)
Version 1.1

SERVICE Levels Customer Satisfaction Ticket Management und Customer Satisfaction User Stories
werden gewichtet zu diesem Wert kombiniert.
Algorithmus: Die SERVICE Level Performance wird kalkuliert als gewichteter Durchschnitt aller
Rückmeldungen innerhalb einer Messperiode.

5.1.2 Customer Satisfaction Product Owner (F-CE-2)


Diese Kennzahl misst die Zufriedenheit der Product Owner in der Sourcing Unit mit dem Lieferanten, im
Rahmen einer Umfrage. Das konkrete Design der Umfragemethodik wird im Performance Management
Handbuch beschrieben.
Algorithmus: Die SERVICE Level Performance ist die Rückmeldung des Product Owners für den
Betrachtungszeitraum.

5.1.3 Customer Satisfaction Ticket Management (F-CE-3)


Diese Kennzahl misst die Zufriedenheit des Ticket-Erstellers mit dem Lieferanten, im Rahmen einer
Umfrage. Das konkrete Design der Umfragemethodik wird im Performance Management Handbuch
beschrieben.
Algorithmus: Die SERVICE Level Performance ist die Rückmeldung des Ticket-Erstellers für den
Betrachtungszeitraum.

5.1.4 Customer Satisfaction User Stories (F-CE-4)


Diese Kennzahl misst die Zufriedenheit der Stakeholder von User Stories mit dem Lieferanten, im
Rahmen einer Umfrage. Das konkrete Design der Umfragemethodik wird im Performance Management
Handbuch beschrieben.
Algorithmus: Die SERVICE Level Performance ist die Rückmeldung der Stakeholder von User Stories für
den Betrachtungszeitraum.

5.2 Governance
SERVICE Level Agreements, die der Kategorie „Governance“ zugeordnet sind:

5.2.1 Qualität der Dokumentation (F-GOV-1)


Jedes einzelne Element innerhalb des SERVICE Knowledge Management Systems, bspw. das
Performance Management Handbuch, ein Betriebshandbuch, eine Lösungsdatenbank, die CMDB,
Schnittstellenkontrakte, usw. innerhalb der Sourcing Unit ist gemäß Prozessvorgabe gepflegt. Die
innerhalb des SERVICE Levels betrachteten Elemente, sowie die Prozessvorgaben zur Pflege dieser und
deren Gewichtung innerhalb des SERVICE Levels werden im Performance Management Handbuch
erfasst.

Algorithmus:

Seite 5
DevOps Sourcing BMW AG (Auftraggeber)
Service Level Description Template File (Auftragnehmer)
Version 1.1

∑𝑛𝑖=1(𝐸𝑟𝑟𝑒𝑖𝑐ℎ𝑡𝑒𝑟 𝑊𝑒𝑟𝑡𝑖 ∗ 𝐺𝑒𝑤𝑖𝑐ℎ𝑡𝑖 )


𝑄𝑢𝑎𝑙𝑖𝑡ä𝑡 𝑑𝑒𝑟 𝐷𝑜𝑘𝑢𝑚𝑒𝑛𝑡𝑎𝑡𝑖𝑜𝑛 =
∑𝑛𝑖=1 𝐺𝑒𝑤𝑖𝑐ℎ𝑡𝑖

5.2.2 Compliance-Erfüllung (F-GOV-2)


Jedes einzelne Element innerhalb des vereinbarten Kontrollhandlungsplans ist bei Fälligkeit in der
Messperiode erfüllt. Der Kontrollhandlungsplan ist im Performance Management Handbuch hinterlegt.
Algorithmus: Es wird ermittelt, ob das Kontrollhandlungsplanelement innerhalb der vorgeschriebenen
Frist erfüllt wurde.

5.3 Verfügbarkeit
SERVICE Level Agreements, die der Kategorie „Verfügbarkeit“ zugeordnet sind, wobei „Produkt
Verfügbarkeit“ sich aus den KPIs „Mean time to repair“ und „Mean time between failure“
zusammensetzt.
Die hier vorgeschlagene Methode ist ein Vorschlag für Produkte, die keine eigenen Verfahren zur
jeweiligen Messung haben.

5.3.1 Produkt Verfügbarkeit (F-AV-1)


Diese Kennzahl misst die durchschnittliche Verfügbarkeit für ein Line Item der Entity List.
Algorithmus:
𝑀𝑒𝑎𝑛 𝑡𝑖𝑚𝑒 𝑏𝑒𝑡𝑤𝑒𝑒𝑛 𝑓𝑎𝑖𝑙𝑢𝑟𝑒𝑠
𝑃𝑟𝑜𝑑𝑢𝑘𝑡 𝑉𝑒𝑟𝑓ü𝑔𝑏𝑎𝑟𝑘𝑒𝑖𝑡 =
𝑀𝑒𝑎𝑛 𝑡𝑖𝑚𝑒 𝑏𝑒𝑡𝑤𝑒𝑒𝑛 𝑓𝑎𝑖𝑙𝑢𝑟𝑒𝑠 + 𝑀𝑒𝑎𝑛 𝑡𝑖𝑚𝑒 𝑡𝑜 𝑟𝑒𝑝𝑎𝑖𝑟

5.3.2 Mean time to repair (F-AV-2)


Diese Kennzahl misst die durchschnittliche Ausfallzeit eines Line Items in der Entity List. Ein Ausfall ist
definiert als der Zeitraum in dem ein oder mehrere Incidents der Priorität „Critical“ oder „High“ ungelöst
sind.
Algorithmus:
∑𝑛𝑖=0 𝑡 𝑖
𝑀𝑒𝑎𝑛 𝑡𝑖𝑚𝑒 𝑡𝑜 𝑟𝑒𝑝𝑎𝑖𝑟 =
𝑛

Mit:
t = Ausfallzeit des Produkts
n = Anzahl der Ausfälle

5.3.3 Mean time between failure (F-AV-3)


Diese Kennzahl misst die durchschnittliche Zeit zwischen Ausfällen eines Line Items in der Entity List. Ein
Ausfall ist definiert als der Zeitraum indem ein oder mehrere Incidents der Priorität „Critical“ oder

Seite 6
DevOps Sourcing BMW AG (Auftraggeber)
Service Level Description Template File (Auftragnehmer)
Version 1.1

„High“ ungelöst sind. Die geplante Uptime ist die Zeitdauer in der Messperiode, in der der IT SERVICE zur
Verfügung stehen soll.
Algorithmus:
𝑡𝑢 − ∑𝑛𝑖=0 𝑡 𝑖
𝑀𝑒𝑎𝑛 𝑡𝑖𝑚𝑒 𝑏𝑒𝑡𝑤𝑒𝑒𝑛 𝑓𝑎𝑖𝑙𝑢𝑟𝑒𝑠 =
𝑛

Mit:
tu = Geplante Uptime
t = Ausfallzeit des Produkts
n = Anzahl der Ausfälle

5.4 Ticket Management


SERVICE Level Agreements, die der Kategorie „Ticket Management“ zugeordnet sind.

5.4.1 Durchschnittliche Lösungszeit Tickets (O-TM-1)


Diese Kennzahl misst die durchschnittlichen Lösungszeiten für alle Incidents und SERVICE Requests der
Prioritäten „Medium“ und „Low“ innerhalb der Messperiode.

Algorithmus:
∑𝑛𝑖=0 𝑡𝑖
𝐷𝑢𝑟𝑐ℎ𝑠𝑐ℎ𝑛𝑖𝑡𝑡𝑙𝑖𝑐ℎ𝑒 𝐿ö𝑠𝑢𝑛𝑔𝑠𝑧𝑒𝑖𝑡 𝐼𝑛𝑐𝑖𝑑𝑒𝑛𝑡𝑠 =
𝑛
Mit:
t = Lösungszeit eines Tickets
n = Anzahl aller Incidents

5.4.2 Tickets innerhalb maximaler Lösungszeit (O-TM-2 bis O-TM-5)


Diese Kennzahl misst den Anteil der Tickets je Priorität, die innerhalb der erlaubten Lösungszeit gelöst
wurden. Es gelten die Zeiten aus Kapitel 3.
Algorithmus:
𝐴𝑛𝑧𝑎ℎ𝑙 𝐼𝑛𝑐𝑖𝑑𝑒𝑛𝑡𝑠 𝑔𝑒𝑙ö𝑠𝑡 𝑖𝑛𝑛𝑒𝑟ℎ𝑎𝑙𝑏 𝐿ö𝑠𝑢𝑛𝑔𝑠𝑧𝑒𝑖𝑡
𝑀𝑎𝑥𝑖𝑚𝑎𝑙𝑒 𝐿ö𝑠𝑢𝑛𝑔𝑠𝑧𝑒𝑖𝑡 𝐼𝑛𝑐𝑖𝑑𝑒𝑛𝑡 =
𝐴𝑛𝑧𝑎ℎ𝑙 𝑎𝑙𝑙𝑒𝑟 𝐼𝑛𝑐𝑖𝑑𝑒𝑛𝑡𝑠

5.5 Continuous SERVICE Improvement


5.5.1 Ticket Reduction Trend (O-CSI-1)
Diese Kennzahl misst den Erfolg des Auftragnehmers die Anzahl der Tickets je Support-Level zu
reduzieren.

Seite 7
DevOps Sourcing BMW AG (Auftraggeber)
Service Level Description Template File (Auftragnehmer)
Version 1.1

Algorithmus:
Es soll erreicht werden, dass die Anzahl der Tickets über mehrere Messperioden einer fallenden
Trendlinie folgt.
Hierzu wird im Betrachtungszeitraum die mittlere Anzahl der Tickets in der zweiten Hälfte des
Betrachtungszeitraums mit der mittleren Anzahl der Tickets in der ersten Hälfte des
Betrachtungszeitraums verglichen.
Enthält der Betrachtungszeitraum eine ungerade Anzahl von Messperioden, wird die mittlere
Messperiode zur ersten Hälfte des Betrachtungszeitraums gezählt.
Der Betrachtungszeitraum ist im Performance Management Handbuch hinterlegt.

̅2 − 𝑁
𝑁 ̅1
𝑇𝑖𝑐𝑘𝑒𝑡 𝑅𝑒𝑑𝑢𝑐𝑡𝑖𝑜𝑛 𝑇𝑟𝑒𝑛𝑑 =
𝑁̅1
Mit:
̅1 =mittlere Anzahl der Tickets in der ersten Hälfte des Betrachtungszeitraums
𝑁
̅2 =mittlere Anzahl der Tickets in der zweiten Hälfte des Betrachtungszeitraums
𝑁

5.6 Development Quality


Development Quality misst die Qualität in der IT Entwicklung hinsichtlich Coding Qualität und dem
Umgang mit Defects.

5.6.1 Codequalität (D-DQ-1)


Diese Kennzahl wird über eine automatisierte und toolbasierte Prüfung nach jedem Deployment über
ein Sourcecode Audit Tool ermittelt. Dabei kommen definierte Regelwerke pro eingesetzter Technologie
zum Einsatz. Diese sind den BMW Vorgaben angepasst. Das Tool, die Messmethodik und die
einzuhaltenden Messwerte werden im Performance Management Handbuch beschrieben. Im Rahmen
dieses SLA wird die Erreichung der definierten Zielwerte berichtet.

Algorithmus: Die SERVICE Level Performance wird vom zu verwendenden Tool gemessen und wie im
Performance Managementhandbuch beschrieben berechnet.

Beispiel für die Verwendung von Sonar als Tool zur Messung der Codequalität:
Es seien z.B. folgende Metriken definiert:

Seite 8
DevOps Sourcing BMW AG (Auftraggeber)
Service Level Description Template File (Auftragnehmer)
Version 1.1

Dann könnte eine mögliche Berechnung des SLA „Codequalität“ sein wie folgt:
Für die SLA Berechnung betrachtet werden die vier Metriken
- Blocker issues
- Condition Coverage on New Code
- Rules Compliance Index
- Unit Test Success.

Der SERVICE Level ist rot, wenn mindestens eine dieser Metriken die Stufe „Error“ erreicht.
Der SERVICE Level ist gelb, wenn keine dieser Metriken die Stufe „Error“, aber mindestens eine dieser
Metriken die Stufe „Warning“ erreicht.
Andernfalls ist der SERVICE Level erreicht.

Seite 9