LP4: Betreiben der Services: Unterschied zwischen den Versionen
Aus YaSM Service-Management-Wiki
Andrea (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Andrea (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
| Zeile 1: | Zeile 1: | ||
<itpmch><title>LP4: Betreiben der Services | YaSM Service-Management-Wiki</title> | <itpmch><title>LP4: Betreiben der Services | YaSM Service-Management-Wiki</title> | ||
<meta name="keywords" content="yasm services betreiben, yasm service | <meta name="keywords" content="servicebetrieb, service operation,yasm services betreiben, yasm service betrieb, yasm service operation, service management operation prozess" /> | ||
<meta name="description" content="YaSM-Prozess: Betreiben der | <meta name="description" content="Der Service-Operation-Prozess in YaSM stellt sicher, dass die Services effektiv und effizient sowie in Übereinstimmung mit den vertraglichen Zusagen erbracht werden. [...]" /> | ||
<meta property="og:url" content="https://yasm.com/wiki/de/index.php/LP4:_Betreiben_der_Services" /> | |||
<meta property="og:title" content="LP4: Betreiben der Services | YaSM Service-Management-Wiki" /> | |||
<meta property="og:description" content="Der Service-Operation-Prozess in YaSM stellt sicher, dass die Services effektiv und effizient sowie in Übereinstimmung mit den vertraglichen Zusagen erbracht werden. [...]" /> | |||
<meta property="og:site_name" content="YaSM"> | |||
<meta property="og:type" content="article" /> | |||
<meta property="article:publisher" content="https://www.facebook.com/yasmcom" /> | |||
<meta property="fb:admins" content="100002035253209" /> | |||
<meta property="fb:admins" content="100002592864414" /> | |||
<meta property="og:image" content="https://yasm.com/wiki/de/img/yasm-prozess/Betreiben-der-services-yasm-lp4.jpg" /> | |||
<meta property="og:image:width" content="847" /> | |||
<meta property="og:image:height" content="662" /> | |||
<meta property="og:image" content="https://yasm.com/wiki/de/img/yasm-prozess/thumbs/yasm-lp4-de-400x400.jpg" /> | |||
<meta property="og:image:width" content="400" /> | |||
<meta property="og:image:height" content="400" /> | |||
<link href="https://plus.google.com/100916307096177053362/posts" rel="publisher" /> | |||
</itpmch> | </itpmch> | ||
<html> | <html><a href="https://yasm.com/wiki/en/index.php/LP4:_Operate_the_services"><img src="https://yasm.com/wiki/de/img/yasm-wiki/yasm-wiki-english.png" width="48" height="30" style="float:right;" alt="in English" title="This page in English" /></a><br style="clear:both;"/></html> | ||
<a href="https://yasm.com/wiki/en/index.php/LP4:_Operate_the_services"><img src="https://yasm.com/wiki/de/img/yasm-wiki/yasm-wiki-english.png" width="48" height="30" style="float:right;" alt="in English" title="This page in English" /></a><br style="clear:both;"/> | |||
<p> </p> | <p> </p> | ||
'''Prozessname:''' [[#Prozess-Beschreibung|Betreiben der Services]] - '''Teil von:''' [[YaSM-Prozesse#service-lifecycle-prozesse|Service-Lifecycle-Prozesse]] | |||
'''Vorhergehender Prozess:''' [[LP3: Erstellen neuer oder geänderter Services|Erstellen neuer oder geänderter Services]] | |||
'''Nächster Prozess:''' [[LP5: Verbessern der Services|Verbessern der Services]] | |||
<p> </p> | <p> </p> | ||
| Zeile 14: | Zeile 31: | ||
==Prozess-Beschreibung== | ==Prozess-Beschreibung== | ||
<html><div itemscope itemtype="https://schema.org/ImageObject" | <html><div itemid="https://yasm.com/wiki/de/img/yasm-prozess/Betreiben-der-services-yasm-lp4.jpg" itemscope itemtype="https://schema.org/ImageObject"> | ||
<a href="https://yasm.com/wiki/de/img/yasm-prozess/Betreiben-der-services-yasm-lp4.jpg" title="Betreiben der Services. - YaSM-Prozess LP4." itemprop="contentUrl"> | |||
<meta itemprop="width" content="847" /> | |||
<meta itemprop="height" content="662" /> | |||
<meta itemprop="keywords" content="YaSM Service Operation" /> | |||
<meta itemprop="keywords" content="YaSM Service-Betrieb" /> | |||
<meta itemprop="keywords" content="Service-Operation-Prozess" /> | |||
<img style="margin:20px 0px 10px 0px; float:left;" src="https://yasm.com/wiki/de/img/yasm-prozess/Betreiben-der-services-yasm-lp4.jpg" width="847" height="662" title="Betreiben der Services. - YaSM-Prozess LP4." alt="Abb. 1: Betreiben der Services. - YaSM Service-Operations-Prozess LP4." /></a><br style="clear:both;"/> | |||
<div class="thumbcaption"><span style="font-variant:small-caps;"><b>Abbildung 1:</b></span> <small><span itemprop="caption">"Betreiben der Services". - YaSM Service-Lifecycle-Prozess LP4.</span></small></div></div><br style="clear:both;"/> | |||
<p><span | <p><span id="md-itempage-description" itemprop="description">Der Service-Operation-Prozess in YaSM ("<strong class="selflink">LP4: Betreiben der Services</strong>") stellt sicher, dass die Services effektiv und effizient sowie in Übereinstimmung mit den vertraglichen Zusagen erbracht werden. Dies beinhaltet die Bearbeitung von Serviceaufträgen und die Lösung von Incidents und Problemen ebenso wie die Erledigung routinemäßiger Betriebsaufgaben.</span></p> | ||
<p>Die erreichte Servicequalität wird regelmäßig gemessen. Die entsprechenden Service-Qualitätsberichte stellen einen wichtigen Input für den Serviceverbesserungs-Prozess dar.</p> | <p>Die erreichte Servicequalität wird regelmäßig gemessen. Die entsprechenden Service-Qualitätsberichte stellen einen wichtigen Input für den Serviceverbesserungs-Prozess dar.</p> | ||
| Zeile 26: | Zeile 51: | ||
==Sub-Prozesse== | ==Sub-Prozesse== | ||
<html><div itemscope="itemscope" itemtype="https://schema.org/ | <html><!-- define schema.org/CreativeWork --><div itemid="https://yasm.com/wiki/de/index.php/LP4:_Betreiben_der_Services#Sub-Prozesse" itemscope="itemscope" itemtype="https://schema.org/CreativeWork"> | ||
<meta itemprop=" | <link itemprop="additionalType" href="http://www.productontology.org/id/Business_process" /> | ||
< | <meta itemprop="name" content="Service-Betriebs-Prozesse" /> | ||
<meta itemprop="alternateName" content="Definition der YaSM Service-Operation-Prozesse" /> | |||
<p><span itemprop="description">YaSM's Service-Operation-Prozess <i>'LP4: Betreiben der Services'</i> beinhaltet die folgenden Sub-Prozesse:</span> | |||
</p> | </p> | ||
<p> </p> | <p> </p> | ||
< | |||
< | <div itemprop="hasPart" itemid="https://yasm.com/wiki/de/index.php/LP4:_Betreiben_der_Services#Prozess-LP4.1" itemscope itemtype="https://schema.org/CreativeWork"> | ||
<meta itemprop="alternateName" content="YaSM Service-Betriebs-Prozess LP4.1" /> | |||
<dl id="LP4.1"><dt itemprop="name">LP4.1: Unterstützen des Service-Betriebs</dt> | |||
<dd itemprop="description">Prozessziel: Bereitstellen von Unterstützung für den Service-Betrieb, z.B. durch Sicherstellen der notwendigen Ressourcen für den Service-Betrieb sowie durch Konfigurieren und Verwalten der unterstützenden Systeme, die für den Betrieb der Services erforderlich sind.</dd></dl> | |||
</div> | |||
<p><br /></p> | <p><br /></p> | ||
< | <div itemprop="hasPart" itemid="https://yasm.com/wiki/de/index.php/LP4:_Betreiben_der_Services#Prozess-LP4.2" itemscope itemtype="https://schema.org/CreativeWork"> | ||
< | <meta itemprop="alternateName" content="YaSM Service-Betriebs-Prozess LP4.2" /> | ||
<dl id="LP4.2"><dt itemprop="name">LP4.2: Bereitstellen von Leitlinien für den Service-Betrieb</dt> | |||
<dd itemprop="description">Prozessziel: Bereitstellen von Instruktionen für die vom Betriebspersonal auszuführenden Tätigkeiten. Dies schließt z.B. die Erstellung von detaillierten Richtlinien für regelmäßige Wartungsaufgaben mit ein.</dd></dl> | |||
</div> | |||
<p><br /></p> | <p><br /></p> | ||
< | <div itemprop="hasPart" itemid="https://yasm.com/wiki/de/index.php/LP4:_Betreiben_der_Services#Prozess-LP4.3" itemscope itemtype="https://schema.org/CreativeWork"> | ||
< | <meta itemprop="alternateName" content="YaSM Service-Betriebs-Prozess LP4.3" /> | ||
<dl id="LP4.3"><dt itemprop="name">LP4.3: Überwachen der Services</dt> | |||
<dd itemprop="description">Prozessziel: Sicherstellen, dass die Service-Infrastruktur laufend überwacht wird, und Bestimmen von geeigneten Maßnahmen, falls Unregelmäßigkeiten festgestellt werden.</dd></dl> | |||
</div> | |||
<p><br /></p> | <p><br /></p> | ||
< | <div itemprop="hasPart" itemid="https://yasm.com/wiki/de/index.php/LP4:_Betreiben_der_Services#Prozess-LP4.4" itemscope itemtype="https://schema.org/CreativeWork"> | ||
< | <meta itemprop="alternateName" content="YaSM Service-Betriebs-Prozess LP4.4" /> | ||
<dl id="LP4.4"><dt itemprop="name">LP4.4: Erstellen von Service-Qualitätsberichten</dt> | |||
<dd itemprop="description">Prozessziel: Regelmäßiges Messen der erreichten Service-Qualität und Identifizieren von Bereichen, in denen die Service-Qualität verbessert werden muss.</dd></dl> | |||
</div> | |||
<p><br /></p> | <p><br /></p> | ||
< | <div itemprop="hasPart" itemid="https://yasm.com/wiki/de/index.php/LP4:_Betreiben_der_Services#Prozess-LP4.5" itemscope itemtype="https://schema.org/CreativeWork"> | ||
< | <meta itemprop="alternateName" content="YaSM Service-Betriebs-Prozess LP4.5" /> | ||
<dl id="LP4.5"><dt itemprop="name">LP4.5: Durchführen laufender Betriebsaufgaben</dt> | |||
<dd itemprop="description">Prozessziel: Durchführen der routinemäßigen betrieblichen Aufgaben, die erforderlich sind, um die vereinbarte Service-Qualität dauerhaft zu liefern.</dd></dl> | |||
</div> | |||
<p><br /></p> | <p><br /></p> | ||
< | <div itemprop="hasPart" itemid="https://yasm.com/wiki/de/index.php/LP4:_Betreiben_der_Services#Prozess-LP4.6" itemscope itemtype="https://schema.org/CreativeWork"> | ||
< | <meta itemprop="alternateName" content="YaSM Service-Betriebs-Prozess LP4.6" /> | ||
<dl id="LP4.6"><dt itemprop="name"><a href="https://yasm.com/wiki/de/index.php/LP4.6:_L%C3%B6sen_von_Incidents_und_Service_Requests" title="4.6: Lösen von Incidents und Service Requests">LP4.6: Lösen von Incidents und Service Requests</a></dt> | |||
<dd itemprop="description">Prozessziel: Bearbeiten von Service Incidents (Meldungen vermuteter oder tatsächlicher Service-Unterbrechungen) oder Service Requests (Serviceaufträgen). Im Falle von Incidents ist das primäre Ziel des Prozesses, den Service für den Anwender so schnell wie möglich wieder herzustellen. In manchen Fällen wird dazu ein Workaround eingesetzt, falls die zugrundliegende Ursache nicht unmittelbar identifiziert und/ oder behoben werden kann.</dd></dl> | |||
</div> | |||
<p><br /></p> | <p><br /></p> | ||
< | <div itemprop="hasPart" itemid="https://yasm.com/wiki/de/index.php/LP4:_Betreiben_der_Services#Prozess-LP4.7" itemscope itemtype="https://schema.org/CreativeWork"> | ||
< | <meta itemprop="alternateName" content="YaSM Service-Betriebs-Prozess LP4.7" /> | ||
</div><!-- end of schema.org/ | <dl id="LP4.7"><dt itemprop="name"><a href="https://yasm.com/wiki/de/index.php/LP4.7:_L%C3%B6sen_von_Problemen" title="4.7: Lösen von Problemen">LP4.7: Lösen von Problemen</a></dt> | ||
<dd itemprop="description">Prozessziel: Die Verwaltung aller Probleme über ihren gesamten Lebenszyklus, wobei ein Problem die einem oder mehreren (potentiellen) Incidents zugrundeliegende Ursache ist. Das primäre Ziel dieses Prozesses ist, dem Auftreten von Service Incidents vorzubeugen und die Auswirkungen von Incidents, die nicht verhindert werden können, minimal zu halten.</dd></dl> | |||
</div> | |||
</div><!-- end of schema.org/CreativeWork --><p></html> | |||
<p> </p> | <p> </p> | ||
| Zeile 57: | Zeile 106: | ||
==Prozess-Outputs== | ==Prozess-Outputs== | ||
<html><div itemscope="itemscope" itemtype="https://schema.org/ | <html><div itemid="https://yasm.com/wiki/de/index.php/LP4:_Betreiben_der_Services#Prozess-Outputs" itemscope="itemscope" itemtype="https://schema.org/CreativeWork"><!-- define schema.org/CreativeWork --> | ||
<meta itemprop=" | <meta itemprop="name" content="YaSM-Prozess LP4: Dokumente und Records" /> | ||
<p><span itemprop=" | <meta itemprop="alternateName" content="Service-Betrieb Prozess-Outputs" /> | ||
<meta itemprop="alternateName" content="Service-Betrieb Datenobjekte" /> | |||
<p><span itemprop="description">Die folgenden Dokumente und Records werden von YaSM's Service-Betriebs-Prozess LP4 <i>'Betreiben der Services'</i> erzeugt.</span> YaSM-Datenobjekte <a href="#ydo" title="YaSM-Datenobjekt">[*]</a> sind mit einem Sternsymbol markiert, und andere Objekte werden in grau dargestellt.</p> | |||
<p> </p> | <p> </p> | ||
< | |||
< | <dl style="color:#636363"><dt>Änderungs-Vorschläge zu Informationen zur Selbsthilfe</dt> | ||
<dd>Ein Vorschlag zur Aktualisierung der Informationen für Anwender zur Selbsthilfe. Diese werden z.B. auf den Support-Seiten des Service-Providers im Intranet zur Verfügung gestellt.</dd></dl> | |||
<p><br /></p> | <p><br /></p> | ||
< | <dl style="color:#636363"><dt>Anforderung zum Hinzufügen von Kompetenzen und Personalressourcen</dt> | ||
< | <dd>Eine Anforderung zum Hinzufügen von Kompetenzen und Personalressourcen zur Service-Provider-Organisation; diese wird z.B. bei einer Service-Implementierung erteilt, wenn neue oder geänderte Kompetenzen und/ oder zusätzliche Personalressourcen für einen neuen Service benötigt werden.</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl style="color:#636363"><dt>Anwender-Handbuch</dt> | ||
< | <dd>Eine Dokumentation für Endanwender, die beschreibt, wie eine Anwendung oder ein System zu bedienen ist.</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl style="color:#636363"><dt>Beschaffungs-Anforderung</dt> | ||
< | <dd>Eine Anforderung zur Beschaffung von Gütern von einem externen Lieferanten. Beschaffungs-Anforderungen werden typischerweise an den Supplier-Manager gerichtet, wenn z.B. Anwendungen, Systeme oder andere Infrastruktur-Komponenten für die Erstellung eines neuen Service notwendig sind, oder wenn Standard-Infrastruktur-Komponenten oder Verbrauchsgüter für den Service-Betrieb benötigt werden.</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl><dt>Beschwerde-Record</dt> | ||
<dd>Ein Record, der alle Einzelheiten einer Beschwerde von Kundenseite enthält, einschließlich der durchgeführten Aktivitäten zur Behandlung der Beschwerde. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | |||
<p><br /></p> | <p><br /></p> | ||
< | <dl><dt>Budget-Anforderung</dt> | ||
< | <dd>Eine Budget-Anforderung wird typischerweise erstellt, um finanzielle Mittel für das Erstellen, Verbessern oder Betreiben eines Service oder Prozesses zu erhalten. Eine genehmigte Budget-Anforderung bedeutet, dass die finanziellen Ressourcen vom Finanz-Manager zugeteilt wurden. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl><dt>Change Record</dt> | ||
< | <dd>In einem Change Record sind alle Einzelheiten eines Changes enthalten; er dokumentiert somit den Lebenszyklus eines einzelnen Changes. Zu Beginn beschreibt ein Change Record einen Change-Antrag (Request for Change, RFC), der vor der Implementierung des Changes zu bewerten und freizugeben ist. Weitere Informationen werden im Verlauf des Changes hinzugefügt. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl><dt>CI Record</dt> | ||
< | <dd>Konfigurations-Information wird für alle Konfigurations-Elemente (Configuration Items, CIs) in CI Records gepflegt, die unter der Kontrolle des Konfigurations-Managers stehen. In diesem Zusammenhang gibt es unterschiedliche Typen von CIs: Anwendungen, Systeme und andere Infrastruktur-Komponenten werden als CIs behandelt, aber oft auch Services, Richtlinien, Projektdokumente, Mitarbeiter, Lieferanten usw. Konfigurations-Informationen sind im Konfigurations-Management-System (Configuration Management System, CMS) verzeichnet. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl><dt>Fragebogen zur Kundenumfrage</dt> | ||
< | <dd>Eine Kundenumfrage setzt typischerweise Fragebögen ein, mit denen Einblick in die generelle Zufriedenheit der Kunden und zu speziellen (Aspekten von) Services aus Kundensicht gewonnen werden sollen. In vielen Fällen werden Antworten auf einer Skala gegeben, wie z.B. '1: Sehr unzufrieden', ... , '10: Sehr zufrieden'. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl id="Geplante-Service-Unterbrechungen"><dt>Geplante Service-Unterbrechungen</dt> | ||
< | <dd>Im Dokument bzw. in der Datenbank der geplanten Serviceunterbrechungen sind erwartete bzw. geplante Abweichungen von der normalen Service-Verfügbarkeit aufgeführt, wie z.B. Unterbrechungen auf Grund von Wartungsarbeiten oder Implementierungen von Changes. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl style="color:#636363"><dt>Incident- bzw. Request-Status-Information</dt> | ||
< | <dd>Eine Nachricht mit Informationen zum aktuellen Stand der Bearbeitung eines Incidents oder Serviceauftrags an einen Anwender, der zuvor einen Incident oder Serviceauftrag gemeldet hat. Statusinformationen werden Anwendern typischerweise an verschiedenen Punkten im Lebenszyklus eines Incidents bzw. Serviceauftrags gesendet. Falls die Lösungszeit den vereinbarten Zeitrahmen überschreitet oder zu überschreiten droht, sind Status-Benachrichtigungen besonders wichtig, um den Anwender auf dem Laufenden zu halten.</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl><dt>Incident Record</dt> | ||
< | <dd>Ein Datensatz mit allen Angaben zu einem Service Incident, in dem der Verlauf des Incidents von der Ersterfassung bis zur Schließung dokumentiert ist. Ein Service Incident ist definiert als ungeplante Unterbrechung oder Qualitätsminderung eines Service. Auch ein Ereignis, das in der Zukunft einen Service beeinträchtigen könnte, wird als Incident behandelt (z.B. der Ausfall einer Festplatte in einem Satz gespiegelter Festplatten). <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl><dt>Incident-Modell</dt> | ||
< | <dd>Incident-Modelle enthalten die vordefinierten Schritte zum Umgang mit einem bestimmten Incident-Typ. Incident-Modelle dienen dem Zweck, wiederkehrende Incidents effektiv und effizient zu bearbeiten. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl style="color:#636363"><dt>Informationen zum Change-Status</dt> | ||
< | <dd>Aktuelle Status-Informationen zur Implementierung eines Changes. Diese Informationen werden dem Change-Manager von den verschiedenen Prozessen zur Verfügung gestellt, die freigegebene Changes implementieren. Der Change-Manager wird so in die Lage versetzt, die Change Records und die Change-Planung aktuell zu halten.</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl style="color:#636363"><dt>Infos für Anwender zur Selbsthilfe</dt> | ||
< | <dd>Informationen für Anwender zur Selbsthilfe. Diese werden z.B. auf den Support-Seiten des Service-Providers im Intranet zur Verfügung gestellt.</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl style="color:#636363"><dt>Proaktive Anwender-Information</dt> | ||
< | <dd>Eine Meldung über bestehende oder potentielle Service-Unterbrechungen an die Anwender oder Kunden, damit die Anwender sich auf die zeitweilige Unterbrechung des Service einstellen können.</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl><dt>Problem Record</dt> | ||
< | <dd>Ein Datensatz mit allen Angaben zu einem Problem, in dem der Verlauf des Problems von der Ersterfassung bis zur Schließung dokumentiert ist. Ein Problem ist definiert als die zugrundeliegende Ursache eines oder mehrerer (potentieller) Incidents, auch wenn die Ursache bei der Erstellung eines Problem Records oft noch nicht bekannt ist. In vielen Fällen wird eine Umgehungslösung (Workaround) für ein Problem bereitgestellt, solange eine vollständige Lösung noch nicht verfügbar ist. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl id="Protokoll-der-Service-Zugriffe" style="color:#636363"><dt>Protokoll der Service-Zugriffe</dt> | ||
< | <dd>Das Protokoll der Service-Zugriffe (Service Access Log) enthält Datensätze, die von den Zugriffs-Kontrollsystemen gesammelt werden, wenn Benutzer Zugang zu bestimmten Services anfordern. Diese Daten werden z.B. vom Sicherheits-Manager als Grundlage für die Verbesserung von Sicherheits-Mechanismen und -Vorkehrungen genutzt.</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl id="Protokoll-der-System-Ereignisse" style="color:#636363"><dt>Protokoll der System-Ereignisse</dt> | ||
< | <dd>Das Protokoll der System-Ereignisse (System Event Log) enthält Datensätze, die von den Überwachungs-Systemen erzeugt werden, die kontinuierlich den Zustand der technischen Infrastruktur prüfen. Ereignis-Records (Event Records) werden z.B. genutzt, um aktuelle Service-Unterbrechungen zu detektieren, die unmittelbares Handeln erfordern. Mit Ereignis-Records werden auch Situationen identifiziert, die präventive Maßnahmen erfordern, um die Service-Qualität aufrecht zu halten (z.B. drohende Kapazitäts-Engpässe).</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl><dt>Service Request Record</dt> | ||
< | <dd>Ein Record, der alle Details eines Service Requests (Serviceauftrags) aufzeichnet. Service Requests sind formale Anfragen eines Kunden bzw. Anwenders im Rahmen bestehender Service-Vereinbarungen - z.B. nach Informationen, Beratung, Zurücksetzen eines Passworts, oder Installation einer Workstation für einen neuen Anwender. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl id="Service-Betriebshandbuch"><dt>Service-Betriebshandbuch</dt> | ||
< | <dd>Ein Service-Betriebshandbuch spezifiziert die Aktivitäten, die für den Betrieb eines Service und der darunter liegenden Infrastruktur erforderlich sind. Die Informationen im Service-Betriebshandbuch sollen die im Tagesgeschäft anfallenden Aufgaben auf eine für das Betriebspersonal nützliche Weise beschreiben. Einige Anweisungen für den Betrieb bestimmter Anwendungen, Systeme oder Infrastruktur-Komponenten können in separaten technischen Handbüchern oder Standardarbeitsanweisungen ('Standard Operating Procedures, SOP') dokumentiert werden. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl id="Service-Qualitaets-Bericht"><dt>Service-Qualitäts-Bericht</dt> | ||
< | <dd>Ein Service-Qualitätsbericht stellt dar, inwieweit der Service-Provider in der Lage ist, die zugesagte Service-Qualität zu liefern. Insbesondere vergleicht der Bericht die erreichten Service-Levels mit den vereinbarten Zielwerten, wie in den Servicedefinitionen festgelegt. Service-Qualitätsberichte stellen auch etwaige Verletzungen vertraglicher Verpflichtungen und außergewöhnliche Ereignisse heraus.</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl><dt>Service-Request-Modell</dt> | ||
< | <dd>Service-Request-Modelle enthalten die vordefinierten Schritte zum Umgang mit einem bestimmten Typ von Serviceauftrag. Request-Modelle dienen dem Zweck, häufig wiederkehrende Serviceaufträge effektiv und effizient zu bearbeiten. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl style="color:#636363"><dt>Statistik zur Service-Inanspruchnahme</dt> | ||
< | <dd>Statistische Daten zur Inanspruchnahme der Services durch Kunden bzw. Benutzer, als Basis für die Erstellung von Kunden-Rechnungen.</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl style="color:#636363"><dt>Support-Anfrage</dt> | ||
< | <dd>Eine Anforderung zur Unterstützung bei der Behebung eines Incidents oder Problems. Eine solche Anforderung wird üblicherweise vom Incident- oder Problem-Manager gestellt, wenn weitere technische Expertise für die Behebung von Incidents oder Problems erforderlich ist.</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl style="color:#636363"><dt>Technisches Handbuch</dt> | ||
< | <dd>Ein Dokument, das die Verfahren zu Betrieb und Wartung eines Systems oder anderer Infrastruktur-Komponente beschreibt. Technische Handbücher werden oft von externen Produktlieferanten oder internen Entwicklungsteams bereitgestellt.</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl><dt>Testprotokoll</dt> | ||
< | <dd>Ein Testprotokoll stellt einen detaillierten Bericht zu Testaktivitäten bereit. Ein solches Protokoll wird z.B. während der Tests neuer oder geänderter Service-Komponenten erstellt, oder während der Tests von Sicherheits- oder Service-Kontinuitäts-Mechanismen. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl><dt>Testskript</dt> | ||
< | <dd>Ein Testskript bzw. Testdrehbuch spezifiziert einen Satz von Testfällen einschließlich der erwarteten Ergebnisse. Die Art der Testfälle hängt davon ab, was zu testen ist. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl style="color:#636363"><dt>Vorschlag zur Verbesserung der Kontinuitäts-Vorkehrungen</dt> | ||
< | <dd>Ein Vorschlag zur Verbesserung der Service-Sicherheit. Solche Vorschläge können an jeder Stelle innerhalb der Organisation entstehen.</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl style="color:#636363"><dt>Vorschlag zur Prozess-Änderung</dt> | ||
< | <dd>Ein Vorschlag zur Änderung eines oder mehrerer Service-Management-Prozesse. Vorschläge für Prozess-Änderungen oder -Verbesserungen können an jeder Stelle innerhalb der Organisation entstehen.</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl style="color:#636363"><dt>Vorschlag zur Service-Änderung</dt> | ||
< | <dd>Ein Vorschlag zur Änderung eines Service, z.B. zur Verbesserung der Qualität oder Wirtschaftlichkeit des Services. Solche Vorschläge können an jeder Stelle innerhalb oder außerhalb der Service-Provider-Organisation entstehen.</dd></dl> | ||
<p><br /></p> | <p><br /></p> | ||
< | <dl id="Wiederherstellungs-Plan"><dt>Wiederherstellungs-Plan</dt> | ||
< | <dd>Wiederherstellungspläne (Recovery-Pläne) enthalten genaue Anweisungen zu den Maßnahmen, mit denen bestimmte Services und/ oder Systeme nach einem Ausfall wieder hergestellt werden können, was in vielen Fällen auch die Wiederherstellung von Daten zu einem definierten, konsistenten Stand mit einschließt. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | ||
</div><!-- end of schema.org/ | </div><!-- end of schema.org/CreativeWork --><p> | ||
<p> </p> | <p> </p> | ||
| Zeile 171: | Zeile 223: | ||
<html><p>Prozesskennzahlen werden benötigt, wenn gemessen werden soll, ob die Service-Management-Prozesse "zufriedenstellend" laufen.</p> | <html><p>Prozesskennzahlen werden benötigt, wenn gemessen werden soll, ob die Service-Management-Prozesse "zufriedenstellend" laufen.</p> | ||
<p>Vorschläge zu geeigneten <a | <p>Vorschläge zu geeigneten <a href="https://yasm.com/wiki/de/index.php/YaSM-Kennzahlen" title="Wie ermittelt man die Performance der YaSM-Prozesse - Prozesskennzahlen">Prozess-Kennzahlen</a> entnehmen Sie der <a href="https://yasm.com/wiki/de/index.php/YaSM-Kennzahlen/_Service-Lifecycle-Prozesse#metriken-lp4" title="Kennzahlen für den YaSM-Prozess LP4: Betreiben der Services.">Liste von Kennzahlen zum Service-Operations-Prozess</a>.</html> | ||
<p> </p> | <p> </p> | ||
| Zeile 240: | Zeile 292: | ||
<p> </p> | <p> </p> | ||
== | ==Anmerkungen== | ||
<html>< | <html><img src="https://yasm.com/wiki/de/img/yasm-prozess/thumbs/yasm-lp4-de-180x110.jpg" width="180" height="110" title="YaSM LP4: Betreiben der Services" alt="YaSM LP4: Betreiben der Services. - Thumbnail." style="display: block; float: left; margin-right: 10px" /></p> | ||
<div style="margin-left: 30%; color:#636363"> | |||
<p style="margin-top: 0;">Basiert auf: Der Service-Operation-Prozess aus der <a href="https://yasm.com/de/produkte/yasm-prozesslandkarte" title="YaSM-Prozesslandkarte">YaSM Prozesslandkarte</a>.</p> | |||
<p><small>Von:  Stefan Kempter <a rel="author" href="https://plus.google.com/111925560448291102517/about"><img style="margin:0px 0px 0px 0px;" src="/wiki/de/img/yasm-wiki/bookmarking/google.jpg" width="16" height="16" title="Von: Stefan Kempter | Profil auf Google+" alt="Autor: Stefan Kempter, IT Process Maps GbR" /></a>  und  Andrea Kempter <a href="https://plus.google.com/113316270668629760475/about"><img style="margin:0px 0px 0px 0px;" src="/wiki/de/img/yasm-wiki/bookmarking/google.jpg" width="16" height="16" title="Von: Andrea Kempter | Profil auf Google+" alt="Koautor: Andrea Kempter, IT Process Maps GbR" /></a>, IT Process Maps.</small><br style="clear:both;"/></div><p></html> | |||
<p> </p> | |||
< | ==Themenverwandte Blog-Beiträge== | ||
<html><a href="https://yasm.com/de/blog/service-operation-yasm"><img src="https://yasm.com/de/content/blog/150729-service-operation-yasm/img-180x110.jpg" alt="Haben die Betriebsprozesse in YaSM einen anderen Zweck als die in ITIL®, und was ist das Besondere an Service Operation in YaSM?" style="display: block; float: left; margin-right: 10px"/></a> | |||
< | <div style="margin-left: 30%; color:#636363"> | ||
<p style="margin-top: 0;"><a href="https://yasm.com/de/blog/service-operation-yasm">Service Operation in YaSM</a></p> | |||
< | <p><small>von: Stefan Kempter</small></p> | ||
< | <p>Haben die Betriebsprozesse in YaSM einen anderen Zweck als die in ITIL<sup><small>®</small></sup>, und was ist das Besondere an Service Operation in YaSM? <a href="https://yasm.com/de/blog/service-operation-yasm">[...]</a></p></div><p> | ||
<p> </p> | |||
</ | |||
</ | |||
<p><small> | <p><small> | ||
| Zeile 279: | Zeile 329: | ||
</span> | </span> | ||
</small></p> | </small></p> | ||
</ | |||
<!-- define schema.org/ItemPage --> <span itemid="https://yasm.com/wiki/de/index.php/LP4:_Betreiben_der_Services" itemscope itemtype="https://schema.org/ItemPage" itemref="md-itempage-description"> | |||
<link itemprop="additionalType" href="http://www.productontology.org/id/Business_process" /> | |||
<meta itemprop="name Headline" content="LP4: Betreiben der Services" /> | |||
<meta itemprop="alternateName" content="YaSM Service-Betriebs-Prozess" /> | |||
<meta itemprop="alternativeHeadline" content="Der Service-Operation-Prozess in YaSM" /> | |||
<link itemprop="url" href="https://yasm.com/wiki/de/index.php/LP4:_Betreiben_der_Services" /> | |||
<span itemprop="hasPart" itemid="https://yasm.com/wiki/de/index.php/LP4:_Betreiben_der_Services#Sub-Prozesse" itemscope itemtype="https://schema.org/CreativeWork"> | |||
</span> | |||
<span itemprop="hasPart" itemid="https://yasm.com/wiki/de/index.php/LP4:_Betreiben_der_Services#Prozess-Outputs" itemscope itemtype="https://schema.org/CreativeWork"> | |||
</span> | |||
<link itemprop="primaryImageOfPage" href="https://yasm.com/wiki/de/img/yasm-prozess/Betreiben-der-services-yasm-lp4.jpg" /> | |||
<link itemprop="image" href="https://yasm.com/wiki/de/img/yasm-prozess/Betreiben-der-services-yasm-lp4.jpg" /> | |||
<meta itemprop="significantLinks" content="https://yasm.com/wiki/de/index.php/YaSM-Kennzahlen" /> | |||
<meta itemprop="significantLinks" content="https://yasm.com/wiki/de/index.php/YaSM-Kennzahlen/_Service-Lifecycle-Prozesse#metriken-lp4" /> | |||
<link itemprop="isPartOf" href="https://yasm.com/wiki/de/index.php/YaSM-Prozesse#service-lifecycle-prozesse" /> | |||
<meta itemprop="isBasedOnUrl" content="https://yasm.com/de/produkte/yasm-prozesslandkarte" /> | |||
<meta itemprop="inLanguage" content="de" /> | |||
<link itemprop="citation" href="https://yasm.com/wiki/en/index.php/LP4:_Operate_the_services" /> | |||
<link itemprop="publisher" href="https://yasm.com/de/#YaSMBrand" /> | |||
<link itemprop="copyrightHolder creator" href="https://yasm.com/de/kontakt#ITProcessMapsOrg" /> | |||
<link itemprop="author" href="https://yasm.com/de/allg/team#StefanKempter" /> | |||
<link itemprop="contributor" href="https://yasm.com/de/allg/team#AndreaKempter" /> | |||
</span><p></html> | |||
<!-- Diese Seite liegt in folgenden Kategorien: --> | <!-- Diese Seite liegt in folgenden Kategorien: --> | ||
[[Kategorie:YaSM-Prozess]] | [[Kategorie:YaSM-Prozess]] | ||
<!-- keine Inhalte nach diesem Kommentar! --> | <!-- keine Inhalte nach diesem Kommentar! --> | ||
Version vom 15. November 2016, 11:15 Uhr
Prozessname: Betreiben der Services - Teil von: Service-Lifecycle-Prozesse
Vorhergehender Prozess: Erstellen neuer oder geänderter Services
Nächster Prozess: Verbessern der Services
Prozess-Beschreibung
Abbildung 1: "Betreiben der Services". - YaSM Service-Lifecycle-Prozess LP4.
Der Service-Operation-Prozess in YaSM ("LP4: Betreiben der Services") stellt sicher, dass die Services effektiv und effizient sowie in Übereinstimmung mit den vertraglichen Zusagen erbracht werden. Dies beinhaltet die Bearbeitung von Serviceaufträgen und die Lösung von Incidents und Problemen ebenso wie die Erledigung routinemäßiger Betriebsaufgaben.
Die erreichte Servicequalität wird regelmäßig gemessen. Die entsprechenden Service-Qualitätsberichte stellen einen wichtigen Input für den Serviceverbesserungs-Prozess dar.
Die Abbildung oben verdeutlicht auch, wie drei bestimmte Teilprozesse des Servicebetriebs (Überwachen der Services, Lösen von Incidents und Service Requests, Lösen von Problemen) zusammenwirken, um existierende oder potenzielle Incidents sowie deren zugrundeliegenden Ursachen (Problems) aufzufinden und zu lösen.
Sub-Prozesse
YaSM's Service-Operation-Prozess 'LP4: Betreiben der Services' beinhaltet die folgenden Sub-Prozesse:
- LP4.1: Unterstützen des Service-Betriebs
- Prozessziel: Bereitstellen von Unterstützung für den Service-Betrieb, z.B. durch Sicherstellen der notwendigen Ressourcen für den Service-Betrieb sowie durch Konfigurieren und Verwalten der unterstützenden Systeme, die für den Betrieb der Services erforderlich sind.
- LP4.2: Bereitstellen von Leitlinien für den Service-Betrieb
- Prozessziel: Bereitstellen von Instruktionen für die vom Betriebspersonal auszuführenden Tätigkeiten. Dies schließt z.B. die Erstellung von detaillierten Richtlinien für regelmäßige Wartungsaufgaben mit ein.
- LP4.3: Überwachen der Services
- Prozessziel: Sicherstellen, dass die Service-Infrastruktur laufend überwacht wird, und Bestimmen von geeigneten Maßnahmen, falls Unregelmäßigkeiten festgestellt werden.
- LP4.4: Erstellen von Service-Qualitätsberichten
- Prozessziel: Regelmäßiges Messen der erreichten Service-Qualität und Identifizieren von Bereichen, in denen die Service-Qualität verbessert werden muss.
- LP4.5: Durchführen laufender Betriebsaufgaben
- Prozessziel: Durchführen der routinemäßigen betrieblichen Aufgaben, die erforderlich sind, um die vereinbarte Service-Qualität dauerhaft zu liefern.
- LP4.6: Lösen von Incidents und Service Requests
- Prozessziel: Bearbeiten von Service Incidents (Meldungen vermuteter oder tatsächlicher Service-Unterbrechungen) oder Service Requests (Serviceaufträgen). Im Falle von Incidents ist das primäre Ziel des Prozesses, den Service für den Anwender so schnell wie möglich wieder herzustellen. In manchen Fällen wird dazu ein Workaround eingesetzt, falls die zugrundliegende Ursache nicht unmittelbar identifiziert und/ oder behoben werden kann.
- LP4.7: Lösen von Problemen
- Prozessziel: Die Verwaltung aller Probleme über ihren gesamten Lebenszyklus, wobei ein Problem die einem oder mehreren (potentiellen) Incidents zugrundeliegende Ursache ist. Das primäre Ziel dieses Prozesses ist, dem Auftreten von Service Incidents vorzubeugen und die Auswirkungen von Incidents, die nicht verhindert werden können, minimal zu halten.
Prozess-Outputs
Die folgenden Dokumente und Records werden von YaSM's Service-Betriebs-Prozess LP4 'Betreiben der Services' erzeugt. YaSM-Datenobjekte [*] sind mit einem Sternsymbol markiert, und andere Objekte werden in grau dargestellt.
- Änderungs-Vorschläge zu Informationen zur Selbsthilfe
- Ein Vorschlag zur Aktualisierung der Informationen für Anwender zur Selbsthilfe. Diese werden z.B. auf den Support-Seiten des Service-Providers im Intranet zur Verfügung gestellt.
- Anforderung zum Hinzufügen von Kompetenzen und Personalressourcen
- Eine Anforderung zum Hinzufügen von Kompetenzen und Personalressourcen zur Service-Provider-Organisation; diese wird z.B. bei einer Service-Implementierung erteilt, wenn neue oder geänderte Kompetenzen und/ oder zusätzliche Personalressourcen für einen neuen Service benötigt werden.
- Anwender-Handbuch
- Eine Dokumentation für Endanwender, die beschreibt, wie eine Anwendung oder ein System zu bedienen ist.
- Beschaffungs-Anforderung
- Eine Anforderung zur Beschaffung von Gütern von einem externen Lieferanten. Beschaffungs-Anforderungen werden typischerweise an den Supplier-Manager gerichtet, wenn z.B. Anwendungen, Systeme oder andere Infrastruktur-Komponenten für die Erstellung eines neuen Service notwendig sind, oder wenn Standard-Infrastruktur-Komponenten oder Verbrauchsgüter für den Service-Betrieb benötigt werden.
- Beschwerde-Record
- Ein Record, der alle Einzelheiten einer Beschwerde von Kundenseite enthält, einschließlich der durchgeführten Aktivitäten zur Behandlung der Beschwerde. [*]
- Budget-Anforderung
- Eine Budget-Anforderung wird typischerweise erstellt, um finanzielle Mittel für das Erstellen, Verbessern oder Betreiben eines Service oder Prozesses zu erhalten. Eine genehmigte Budget-Anforderung bedeutet, dass die finanziellen Ressourcen vom Finanz-Manager zugeteilt wurden. [*]
- Change Record
- In einem Change Record sind alle Einzelheiten eines Changes enthalten; er dokumentiert somit den Lebenszyklus eines einzelnen Changes. Zu Beginn beschreibt ein Change Record einen Change-Antrag (Request for Change, RFC), der vor der Implementierung des Changes zu bewerten und freizugeben ist. Weitere Informationen werden im Verlauf des Changes hinzugefügt. [*]
- CI Record
- Konfigurations-Information wird für alle Konfigurations-Elemente (Configuration Items, CIs) in CI Records gepflegt, die unter der Kontrolle des Konfigurations-Managers stehen. In diesem Zusammenhang gibt es unterschiedliche Typen von CIs: Anwendungen, Systeme und andere Infrastruktur-Komponenten werden als CIs behandelt, aber oft auch Services, Richtlinien, Projektdokumente, Mitarbeiter, Lieferanten usw. Konfigurations-Informationen sind im Konfigurations-Management-System (Configuration Management System, CMS) verzeichnet. [*]
- Fragebogen zur Kundenumfrage
- Eine Kundenumfrage setzt typischerweise Fragebögen ein, mit denen Einblick in die generelle Zufriedenheit der Kunden und zu speziellen (Aspekten von) Services aus Kundensicht gewonnen werden sollen. In vielen Fällen werden Antworten auf einer Skala gegeben, wie z.B. '1: Sehr unzufrieden', ... , '10: Sehr zufrieden'. [*]
- Geplante Service-Unterbrechungen
- Im Dokument bzw. in der Datenbank der geplanten Serviceunterbrechungen sind erwartete bzw. geplante Abweichungen von der normalen Service-Verfügbarkeit aufgeführt, wie z.B. Unterbrechungen auf Grund von Wartungsarbeiten oder Implementierungen von Changes. [*]
- Incident- bzw. Request-Status-Information
- Eine Nachricht mit Informationen zum aktuellen Stand der Bearbeitung eines Incidents oder Serviceauftrags an einen Anwender, der zuvor einen Incident oder Serviceauftrag gemeldet hat. Statusinformationen werden Anwendern typischerweise an verschiedenen Punkten im Lebenszyklus eines Incidents bzw. Serviceauftrags gesendet. Falls die Lösungszeit den vereinbarten Zeitrahmen überschreitet oder zu überschreiten droht, sind Status-Benachrichtigungen besonders wichtig, um den Anwender auf dem Laufenden zu halten.
- Incident Record
- Ein Datensatz mit allen Angaben zu einem Service Incident, in dem der Verlauf des Incidents von der Ersterfassung bis zur Schließung dokumentiert ist. Ein Service Incident ist definiert als ungeplante Unterbrechung oder Qualitätsminderung eines Service. Auch ein Ereignis, das in der Zukunft einen Service beeinträchtigen könnte, wird als Incident behandelt (z.B. der Ausfall einer Festplatte in einem Satz gespiegelter Festplatten). [*]
- Incident-Modell
- Incident-Modelle enthalten die vordefinierten Schritte zum Umgang mit einem bestimmten Incident-Typ. Incident-Modelle dienen dem Zweck, wiederkehrende Incidents effektiv und effizient zu bearbeiten. [*]
- Informationen zum Change-Status
- Aktuelle Status-Informationen zur Implementierung eines Changes. Diese Informationen werden dem Change-Manager von den verschiedenen Prozessen zur Verfügung gestellt, die freigegebene Changes implementieren. Der Change-Manager wird so in die Lage versetzt, die Change Records und die Change-Planung aktuell zu halten.
- Infos für Anwender zur Selbsthilfe
- Informationen für Anwender zur Selbsthilfe. Diese werden z.B. auf den Support-Seiten des Service-Providers im Intranet zur Verfügung gestellt.
- Proaktive Anwender-Information
- Eine Meldung über bestehende oder potentielle Service-Unterbrechungen an die Anwender oder Kunden, damit die Anwender sich auf die zeitweilige Unterbrechung des Service einstellen können.
- Problem Record
- Ein Datensatz mit allen Angaben zu einem Problem, in dem der Verlauf des Problems von der Ersterfassung bis zur Schließung dokumentiert ist. Ein Problem ist definiert als die zugrundeliegende Ursache eines oder mehrerer (potentieller) Incidents, auch wenn die Ursache bei der Erstellung eines Problem Records oft noch nicht bekannt ist. In vielen Fällen wird eine Umgehungslösung (Workaround) für ein Problem bereitgestellt, solange eine vollständige Lösung noch nicht verfügbar ist. [*]
- Protokoll der Service-Zugriffe
- Das Protokoll der Service-Zugriffe (Service Access Log) enthält Datensätze, die von den Zugriffs-Kontrollsystemen gesammelt werden, wenn Benutzer Zugang zu bestimmten Services anfordern. Diese Daten werden z.B. vom Sicherheits-Manager als Grundlage für die Verbesserung von Sicherheits-Mechanismen und -Vorkehrungen genutzt.
- Protokoll der System-Ereignisse
- Das Protokoll der System-Ereignisse (System Event Log) enthält Datensätze, die von den Überwachungs-Systemen erzeugt werden, die kontinuierlich den Zustand der technischen Infrastruktur prüfen. Ereignis-Records (Event Records) werden z.B. genutzt, um aktuelle Service-Unterbrechungen zu detektieren, die unmittelbares Handeln erfordern. Mit Ereignis-Records werden auch Situationen identifiziert, die präventive Maßnahmen erfordern, um die Service-Qualität aufrecht zu halten (z.B. drohende Kapazitäts-Engpässe).
- Service Request Record
- Ein Record, der alle Details eines Service Requests (Serviceauftrags) aufzeichnet. Service Requests sind formale Anfragen eines Kunden bzw. Anwenders im Rahmen bestehender Service-Vereinbarungen - z.B. nach Informationen, Beratung, Zurücksetzen eines Passworts, oder Installation einer Workstation für einen neuen Anwender. [*]
- Service-Betriebshandbuch
- Ein Service-Betriebshandbuch spezifiziert die Aktivitäten, die für den Betrieb eines Service und der darunter liegenden Infrastruktur erforderlich sind. Die Informationen im Service-Betriebshandbuch sollen die im Tagesgeschäft anfallenden Aufgaben auf eine für das Betriebspersonal nützliche Weise beschreiben. Einige Anweisungen für den Betrieb bestimmter Anwendungen, Systeme oder Infrastruktur-Komponenten können in separaten technischen Handbüchern oder Standardarbeitsanweisungen ('Standard Operating Procedures, SOP') dokumentiert werden. [*]
- Service-Qualitäts-Bericht
- Ein Service-Qualitätsbericht stellt dar, inwieweit der Service-Provider in der Lage ist, die zugesagte Service-Qualität zu liefern. Insbesondere vergleicht der Bericht die erreichten Service-Levels mit den vereinbarten Zielwerten, wie in den Servicedefinitionen festgelegt. Service-Qualitätsberichte stellen auch etwaige Verletzungen vertraglicher Verpflichtungen und außergewöhnliche Ereignisse heraus.
- Service-Request-Modell
- Service-Request-Modelle enthalten die vordefinierten Schritte zum Umgang mit einem bestimmten Typ von Serviceauftrag. Request-Modelle dienen dem Zweck, häufig wiederkehrende Serviceaufträge effektiv und effizient zu bearbeiten. [*]
- Statistik zur Service-Inanspruchnahme
- Statistische Daten zur Inanspruchnahme der Services durch Kunden bzw. Benutzer, als Basis für die Erstellung von Kunden-Rechnungen.
- Support-Anfrage
- Eine Anforderung zur Unterstützung bei der Behebung eines Incidents oder Problems. Eine solche Anforderung wird üblicherweise vom Incident- oder Problem-Manager gestellt, wenn weitere technische Expertise für die Behebung von Incidents oder Problems erforderlich ist.
- Technisches Handbuch
- Ein Dokument, das die Verfahren zu Betrieb und Wartung eines Systems oder anderer Infrastruktur-Komponente beschreibt. Technische Handbücher werden oft von externen Produktlieferanten oder internen Entwicklungsteams bereitgestellt.
- Testprotokoll
- Ein Testprotokoll stellt einen detaillierten Bericht zu Testaktivitäten bereit. Ein solches Protokoll wird z.B. während der Tests neuer oder geänderter Service-Komponenten erstellt, oder während der Tests von Sicherheits- oder Service-Kontinuitäts-Mechanismen. [*]
- Testskript
- Ein Testskript bzw. Testdrehbuch spezifiziert einen Satz von Testfällen einschließlich der erwarteten Ergebnisse. Die Art der Testfälle hängt davon ab, was zu testen ist. [*]
- Vorschlag zur Verbesserung der Kontinuitäts-Vorkehrungen
- Ein Vorschlag zur Verbesserung der Service-Sicherheit. Solche Vorschläge können an jeder Stelle innerhalb der Organisation entstehen.
- Vorschlag zur Prozess-Änderung
- Ein Vorschlag zur Änderung eines oder mehrerer Service-Management-Prozesse. Vorschläge für Prozess-Änderungen oder -Verbesserungen können an jeder Stelle innerhalb der Organisation entstehen.
- Vorschlag zur Service-Änderung
- Ein Vorschlag zur Änderung eines Service, z.B. zur Verbesserung der Qualität oder Wirtschaftlichkeit des Services. Solche Vorschläge können an jeder Stelle innerhalb oder außerhalb der Service-Provider-Organisation entstehen.
- Wiederherstellungs-Plan
- Wiederherstellungspläne (Recovery-Pläne) enthalten genaue Anweisungen zu den Maßnahmen, mit denen bestimmte Services und/ oder Systeme nach einem Ausfall wieder hergestellt werden können, was in vielen Fällen auch die Wiederherstellung von Daten zu einem definierten, konsistenten Stand mit einschließt. [*]
Anmerkungen:
[*] "YaSM-Datenobjekte" sind Dokumente und Records, für die YaSM detaillierte Empfehlungen bereithält: Für jedes YaSM-Objekt gibt es eine Checkliste (siehe Beispiel), die die typischen Inhalte beschreibt, und ein Lifecycle-Diagramm, das darstellt, wie sich der Zustand des Objekts ändert, während es von verschiedenen YaSM-Prozessen erstellt, geändert, gelesen und archiviert wird (siehe Beispiel).
"Andere Objekte" sind eher informelle Daten oder Informationen. Es gibt aus diesem Grund keine zugehörigen Lifecycle-Diagramme oder Checklisten.
Prozess-Kennzahlen
Prozesskennzahlen werden benötigt, wenn gemessen werden soll, ob die Service-Management-Prozesse "zufriedenstellend" laufen.
Vorschläge zu geeigneten Prozess-Kennzahlen entnehmen Sie der Liste von Kennzahlen zum Service-Operations-Prozess.
Rollen und Verantwortlichkeiten
Prozess-Owner: Betriebs-Manager (Operations-Manager)
- Ein Betriebs-Manager (Operations-Manager) trägt die gesamtheitliche Verantwortung für den Betrieb eines Service. Diese Rolle stellt unter anderem sicher, dass alle operativen Routine-Aufgaben zeitgerecht und zuverlässig ausgeführt werden.
| YaSM-Rolle / Sub-Prozess | Betriebs-Mgr. | Oper. | Serv.-Owner | Techn.- Fachexp. | |
|---|---|---|---|---|---|
| LP4.1 | Unterstützen des Service-Betriebs | AR | R | R | R |
| LP4.2 | Bereitstellen von Leitlinien für den Service-Betrieb | AR | - | R | R |
| LP4.3 | Überwachen der Services | A | R | - | - |
| LP4.4 | Erstellen von Service-Qualitätsberichten | A | R | R | - |
| LP4.5 | Durchführen laufender Betriebsaufgaben | A | R | - | - |
| LP4.6 | Lösen von Incidents und Service Requests | siehe RACI-Matrix "LP4.6: Lösen von Incidents und Service Requests" | |||
| LP4.7 | Lösen von Problemen | siehe RACI-Matrix "LP4.7: Lösen von Problemen" | |||
Anmerkungen
Basiert auf: Der Service-Operation-Prozess aus der YaSM Prozesslandkarte.
Von: Stefan Kempter 
und Andrea Kempter , IT Process Maps.
Themenverwandte Blog-Beiträge
von: Stefan Kempter
Haben die Betriebsprozesse in YaSM einen anderen Zweck als die in ITIL®, und was ist das Besondere an Service Operation in YaSM? [...]
Prozess-Beschreibung › Sub-Prozesse › Prozess-Outputs › Kennzahlen › Rollen
