Prozessmodell

From USM Wiki

This page is a translated version of the page Process model and the translation is 100% complete.

Definition eines Prozesses

Der Begriff Prozess wird im Service-Management-Kontext häufig missbraucht. Ein Prozess ist definiert als „eine Reihe von Aktivitäten, die für den Kunden von Bedeutung sind und ein bestimmtes Ziel verfolgen“ und sollte auf Aktivitäten beschränkt sein.

Die grundlegende Gestaltung eines Prozesses


Anforderungen an Prozesse

Um eine Prozessarchitektur zu definieren, brauchen wir mehr als nur diese einfache Definition. USM spezifiziert 10 Anforderungen, die für einen Prozess erfüllt sein sollten, bevor wir ihn tatsächlich einen Prozess nennen und als solchen behandeln können:

  1. Ein Prozess beschreibt, was nacheinander geschehen muss, nicht das wer oder wie.
  2. Ein Prozess kann mit einem Verb interpretiert werden.
  3. Ein Prozess kann gezählt werden.
  4. Prozesse sind nicht abhängig von praktischen Bedingungen (◊).
  5. Prozesse haben einen kundenrelevanten und eindeutigen Zweck.
  6. Ein Prozess kann in Teilprozesse unterteilt werden, aber das ändert den Prozess nicht.
  7. Ein Prozessmodell organisiert die Prozesse.
  8. Ein integriertes Prozessmodell umfasst alle Aktivitäten des Dienstleistungsmanagements.
  9. In einem integrierten Prozessmodell kommt jede Aktivität nur einmal vor.
  10. Alle Aktivitäten werden durch Prozesssteuerung (process control) organisiert.

Prozesse versus Praktiken

Wenn wir die „Prozesse“ aller aktuellen Rahmenwerke, Standards und Referenzarchitekturen anhand dieser 10 Anforderungen testen, kann gezeigt werden, dass sie alle Kombinationen von Menschen, Prozessen und Technologie beschreiben: das „Was“, das „Wer“ und das „Wie“. Daher fallen sie alle bei der ersten der 10 Anforderungen durch. Sie beschreiben nämlich Praktiken, und Praktiken sind keine Prozesse: Praktiken werden von Prozessen abgeleitet, indem das Wer und das Wie dem Was hinzugefügt werden. Die große Mehrheit erfüllt auch die Anforderung 5 nicht: Sie sind nicht kundenorientiert. Die meisten dieser „Prozesse“ sind interne Angelegenheiten des Service Providers und als solche nur ein „Teil“ der kundenorientierten Prozesse. Auch bei der Verwendung von BPMN oder anderen so genannten „Geschäftsprozessmodellierungs“-Techniken oder Produkten, die „Swimlanes“ verwenden, werden Rollen und Dokumente spezifiziert, wodurch Anforderung 1 nicht erfüllt wird.

Im E-Book „Den Begriff PROZESS entmystifizieren“ wird dies ausführlich erläutert.

Erstellen des Prozessmodells mit nur fünf Prozessen

Das Entfernen aller „Wer“ und „Wie“ aus diesen Praktiken führt dann zum Kernmaterial einer Prozessarchitektur: nur das „Was“.

Die Neuformatierung der verbleibenden Aktivitätensammlung in einer Weise, dass das Ergebnis den restlichen 10 Anforderungen entspricht, führt dann zu einem kundenorientierten, integralen, integrierten und nicht redundanten Prozessmodell für das Servicemanagement.

In diesem Prozessmodell finden wir nur fünf Prozesse, die unabhängig vom Geschäftszweig der Organisation sind. Vier dieser Prozesse sind reaktiv: Sie werden von außen, durch den Kunden, ausgelöst. Diese reaktiven Prozesse dienen dazu, auf die Nachfrage des Kunden zu reagieren.

  • Vereinbaren (Contract Management - CTM): Erstellung und Pflege von Servicevereinbarungen und Steuerung ihrer Umsetzung. Dieser Prozess betrifft sowohl die Dienstleistungsvereinbarungen mit Kunden als auch die Vereinbarungen mit externen Lieferanten und mit internen Lösungsteams, die zum Dienst beitragen. Der entsprechende Aufruf wird als Wunsch bezeichnet, der das Konzept der Beschwerde beinhaltet. Der Wunsch dient als Auslöser des Prozesses.
  • Change (Change Management - CHM): die kontrollierte Entwicklung und Freigabe von Änderungen an der Infrastruktur des vereinbarten Dienstes. Dieser Prozess bezieht sich auf die Einrichtung und/oder den Support, soweit er Teil der verwaltete Infrastruktur ist. Der zugehörige Aufruf wird als request for change (RFC) (oder Änderungsantrag) bezeichnet. Der Änderungsantrag dient als Auslöser des Prozesses.
  • Recover (Incident Management - INC): die Reparatur und Wiederherstellung des Dienstes wie vereinbart (in erster Linie nicht so schnell wie möglich, sondern so schnell wie vereinbart). Dieser Prozess betrifft sowohl Ausfälle als auch drohende Ausfälle jeder Größenordnung, einschließlich Katastrophen. Der entsprechende Anruf wird als Vorfall (oder Ausfallmeldung) bezeichnet. Der Vorfall dient als Auslöser des Prozesses.
  • Operate (Operations Management - OPS): die geplante Durchführung aller betrieblichen Maßnahmen für den vereinbarten Dienst und die Überwachung der Leistung der Infrastruktur und aller ihrer Komponenten. Der entsprechende Aufruf wird Service Request (oder Operations Request) genannt. Die Dienstanforderung dient als Auslöser des Prozesses.

Einer der fünf Prozesse ist proaktiv: Er wird intern, von der Organisation des Service Providers, ausgelöst. Dieser proaktive Prozess zielt auf strukturelle Verbesserungen der erbrachten Dienstleistungen ab und bewältigt alle Bedrohungen und Innovationen für die Servicebereitstellung.

  • Verbessern (Risikomanagement - RIM): die Verhinderung von Auswirkungen, die sich nachteilig auf die vereinbarten Dienstleistungen auswirken (Abmilderung von Bedrohungen), sowie die Förderung struktureller Verbesserungen der vereinbarten Dienstleistungen (Förderung von Innovationen). Der entsprechende Aufruf heißt Risiko. Das Risiko fungiert als Auslöser des Prozesses. Der Verbesserungsprozess wird nicht von anderen Prozessen ausgelöst, sondern nur von Menschen: Im Sinne des Prozessmodells ist er 'selbstauslösend'. Menschen melden Risiken, aber es wird auch aktiv nach Risiken gesucht. Der direkte Stakeholder ist hier die eigene Organisation des Service Providers. Der Kunde ist nur ein indirekter Stakeholder: Alle Verbesserungen verbessern letztendlich die Servicebereitstellung.
Das USM Prozessmodell mit ganzen Prozessen


In einem Prozessmodell, das alle 10 Anforderungen erfüllt, wird Leistung mit Workflows erreicht: zusammengesetzte Aktivitätsflüsse, die aus nicht überlappenden Fragmenten einzelner Prozesse aus dem integrierten Prozessmodell bestehen. Beispielsweise kann eine Wiederherstellungsaktion durchgeführt werden, indem eine Änderung vorgenommen wird oder indem eine Infrastruktur zurückgesetzt wird, aber in beiden Fällen wird die Ausführung in einem und nur einem Prozess realisiert: Operations Management. Dies schafft eine eindeutige Kontrolle über die tatsächliche Servicebereitstellung und verhindert Konflikte.

Diese einzigartige integrierte Prozessmodellierung für Service Provider lässt sich leicht erlernen, anwenden und mit Tools unterstützen. Dabei werden nicht mehr als 8 standardisierte USM Workflow Vorlagen für alle Ihre Service Management Aktivitäten verwendet. Stellen Sie sich nur die Reduzierung der Komplexität und der Kosten vor, die Sie mit einem solchen Managementsystem erreichen.

Standardisierung des Layouts eines Prozesses

Jeder Prozess hat das gleiche grundlegende Layout und folglich hat jeder Prozess auch ähnliche Aktivitäten. Am Anfang und am Ende jedes Prozesses finden wir immer die gleichen ähnlichen Aktivitäten: Starten und Beenden des Prozesses. Prozesse unterscheiden sich hauptsächlich in einem Aspekt: ​​dem kundenbezogenen Zweck des Prozesses und damit in der Art des Prozesses. Dieser Unterschied manifestiert sich in den Aktivitäten im 'Hauptteil' des Prozesses.

Im Bild unten werden die Aktivitäten im Hauptteil jedes Prozesses durch ihre Farbe gekennzeichnet. In diesem Bild sind die ähnlichen (aber nicht „identischen“) Aktivitäten grau. Die Details dieser Hauptteilaktivitäten werden pro Prozess im USM Buch behandelt.

Das grundlegende Layout der 5 USM Prozesse


Die Zusammenarbeit zwischen Prozessmodellkomponenten

Wegen der Nichtredundanz der Prozesse benötigt jeder Prozess (außer OPS) einen oder mehrere der anderen, um eine erforderliche Leistung zu erbringen. Daher ist jeder der Prozesse (außer OPS) in zwei Abschnitte unterteilt: den Anfangsabschnitt, der den folgenden Prozessblock auslöst, und die Abschnitte, die den Prozess administrativ abschließen. Die Pfeile im Bild unten zeigen, wie sich die Prozessblöcke gegenseitig auslösen.

Das USM Prozessmodell mit geteilten Prozessen


Die Konsequenz dieser Nichtredundanz und internen Abhängigkeit zwischen Prozessblöcken führt zu dem Konzept der USM Workflows mit erstaunlichen Ergebnissen.