I&P Ticketing Systeme und Critical Chain Projektmanagement

Das Management von sogenannten Incidents and Problems (I&P), das heißt von auftretenden Fehlern und Problemen innerhalb von (IT-)Systemen, wird durch sogenannte „Ticketing Systeme“ gelöst – ein Ticket ist die Meldung eines Problems mit der Bitte, dieses zu lösen. Nach meinem Kenntnisstand gibt es dort eine Menge Systeme und Lösungsmöglichkeiten, aber keines, das sich direkt auf Theory of Constraints-Methodik (TOC) beruft.

Critical Chain Projektmanagement Ketten

Dabei sind die I&P-Prozesse ideal zur Anwendung von Methoden des Critical Chain Projektmanagements (CCPM). Diese Behauptung möchte ich im Folgenden erläutern.

Betrachten wir einen typischen I&P-Prozess:

  1. Ein Ticket wird einer „I&P-Organisation“ eingereicht
  2. Die I&P-Organisation priorisiert das Ticket, z. B. nach den folgenden Prioritäten:
    Prio A: Das System, das das Problem verursacht, ist in seiner Funktionalität nicht mehr nutzbar und verursacht damit Schaden in den Geschäftsprozessen.
    Prio B: Das System, das das Problem verursacht, ist zwar in seiner Funktionalität nicht mehr nutzbar, die Funktionalität kann aber durch einen Workaround befriedigend ersetzt werden. Die Geschäftsprozesse werden nur in unkritischem Maß gestört
    Prio C: Das System, das das Problem verursacht, ist in seiner Funktionalität zwar gestört, die unterstützten Geschäftsprozesse werden dadurch aber nicht gestört.
  3. Jeder Priorität ist über ein Service-Level-Agreement (SLA) eine maximale Reaktionszeit zugewiesen (eine maximale Lösungszeit wird in den meisten Fällen nicht garantiert). Innerhalb dieser Zeit ist garantiert, dass das Problem soweit bearbeitet wurde.
  4. Die I&P-Organisation versucht nun die vorhandenen Tickets so abzuarbeiten, dass die maximale Reaktionszeit eingehalten wird.

Betrachten wir nun die Struktur eines solchen Incidents and Problems-Auftrags:
Er besteht aus mehreren Arbeitspaketen, die von Ressourcen abgearbeitet werden, die im Normalfall auch an x anderen Tickets arbeiten werden. Dieser I&P-Auftrag hat einen festen Endtermin – Eingang des Tickets bei der I&P-Organisation plus maximale Reaktionszeit. Diese Struktur ist in den wesentlichen Zügen nichts anderes, als die Projekte, die wir in der CCPM-Methodik bearbeiten. Hat eine Reaktion (innerhalb der maximalen Reaktionszeit) stattgefunden, wird ein neues „Projekt“ aufgesetzt mit – streng nach SLA definierter – neuer maximaler Reaktionszeit und somit neuem Endtermin.

Betrachten wir das „Ziel“ einer Incidents and Problems-Organisation:
Sie möchte, wenn möglich, möglichst alle Tickets so abarbeiten, dass sie nach SLA alle maximalen Reaktionszeiten einhalten kann (sonst drohen ggf. empfindliche Strafzahlungen) – und das unter Nutzung umkämpfter, knapper Ressourcen und mit hoher inhaltlicher Qualität (also keine einfache Reaktion, sondern ein fachlich qualifiziertes Feedback für den Kunden). Diese Ziele stimmen aber, übertragen in die I&P-Welt, mit dem Ziel des Critical Chain Projektmanagements überein, in einer Multiprojektumgebung (= Multiticketumgebung) möglichst alle Projekte (= Tickets) erfolgreich (für Projekte in vollem Umfang und innerhalb des Budgets, für Tickets im Sinne eines fachlich qualifizierten Feedbacks) „in time“ bzw. rechtzeitig abzuwickeln.

Damit sollte es für eine I&P-Organisation möglich sein, durch Anwendung der CCPM-Methoden eine erfolgreiche Ticket-Verarbeitung durchzuführen. Diese würde sich folgendermaßen auswirken:

  • Weniger schädliches Multitasking – durch einen Freeze von Tickets niederer Priorität (die aus der Pipeline herausgenommen werden können, da Mitarbeiter sonst versucht wären, „doch mal schnell diese Aufgabe wegzuputzen“)
  • Full-Kit – die freigewordenen Ressourcen bearbeiten die hochpriorisierten Tickets mit neuer Sorgfalt
  • Planung nach CCPM – die Tickets werden von Reaktionszeit zu Reaktionszeit wie Projekte in einer Pipeline gestaffelt und verwaltet, Puffer werden wie in Projekten geplant
  • Umsetzung nach CCPM – die Ressourcen werden nach Priorität (= Endtermin) und Verbrauch der Puffer eingesetzt
  • Einflüsse des Kunden abmildern
  • Fremdvergabe von Teilprojekten – in I&P-Organisationen vielleicht noch wichtiger als in Multiprojektorganisationen, da viele Aktivitäten zur Problembehandlung von (IT-)Systemen oftmals außerhalb der eigenen Organisation liegen


Ähnliche Beiträge im GPM BLOG:

Schlagwörter: , , ,

Kommentare

  1. […] Das Management von Incidents and Problems wird meist durch Ticketing Systeme gelöst. Die Anwendung von Methoden des Critical Chain Projektmanagements bietet sich hier an.  […]

  2. avatar Thomas Schlesinger

    Hallo Herr Bacharach,

    wie würden Sie das handhaben, wenn es ein Soll-Ende für die Störung gibt, also keine Reaktionszeit, sondern einen Zeitpunkt, an dem das Problem behoben sein soll?

    Mein Ansatz wäre hier, die Zeit von Meldedatum bis zum Soll-Ende für den Pufferverbrauch zu berücksichtigen und nicht nach jeder erfolgten Reaktion innrhalb eines Incidents/Problems ein neues Soll-Ende mit neuem Puffer zu berechnen.

    1. avatar Guido Bacharach

      Hallo Herr Schlesinger,

      die Frage, die sich mir nur stellt, ist, ob es realistisch ist, dass ein Unternehmen sich auf ein I&P-Service-Level-Agreement mit garantierten Behebungsterminen festlegen würde. Die SLA’s, die ich kenne, beruhen immer nur auf garantierten Reaktionszeiten.

      Oder war Ihr Vorschlag auf rein theoretischer Basis gedacht?

      Viele Grüße
      Guido Bacharach

      1. avatar Thomas Schlesinger

        Hallo Herr Bacharach,

        bei meinem Arbeitgeber gibt es für für jeden Incident ein Soll-Ende, das sich aus der Priorisierung eines Incidents ergibt (konzerninterner IT-Dienstleister), daher meine durchaus praxisbezogene Frage.

        Die Vorgabe einer Lösungszeit ist in ITIL nicht abwegig, siehe z. B. http://wiki.de.it-processmaps.com/index.php/Checkliste_Incident-Priorit%C3%A4t oder http://www.otrs.com/fileadmin/mediafiles/Enterprise_Support/Enterprise-Support_GER/Enterprise_Support_DE_EUR.pdf oder http://de.wikipedia.org/wiki/Support_(Dienstleistung) .

        Mit freundlichem Gruß
        Thomas Schlesinger

        1. avatar Guido Bacharach

          Hallo Herr Schlesinger,

          vielen Dank für diese höchst interessante Information. Tatsächlich bin ich in meinem beruflichen Leben bislang zwar der theoretischen Möglichkeit einer Lösungszeit begegnet, in der Praxis bin ich aber weder in der Rolle eines Lösungsanbieters noch in der Rolle eines Kunden bislang auf ein Unternehmen gestossen, dass eine Lösungszeit wirklich anbietet.

          Können Sie mir für die Ihnen bekannten Beispiele sagen, welche Pönalen die SLAs anboten für den Fall, dass die Lösungszeit nicht eingehalten wurde?

          Vielen Dank und viele Grüße
          Guido Bacharach

  3. avatar Guido Bacharach

    Hallo Herr Schlesinger,

    vielen Dank für die Links, die zu sehr interessanten Informationen führten (der zweite Link ist zwischenzeitlich, das merke ich soeben, nicht mehr gültig?). Meine Frage, die mir diese Links nicht beantworten, bleibt jedoch: Wie kann eine Lösungszeit-orientierte SLA finanziert werden?

    Oftmals braucht die Lösung bestimmter Probleme eine lange Zeit, da die zugehörigen Problemursachen schwierig zu finden sind. Das Finden von Ursachen lässt sich über ein CCPM-Puffermanagement leider nicht befriedigend lösen. Und mit diesem hohen Risiko, bei unklaren Problemursachen die Lösungszeiten nicht einhalten zu können, kann eine SLA entweder nur ohne Pönalen oder rein umlagenfinanziert sein (die Pönalen müßten dabei auch durch die Umlagen finanziert werden). Eine SLA auf Basis einer kostendeckenden Finanzierung (im Sinne eines Cost Centers) oder gar gewinnorientierten Finanzierung (im Sinne eines Profit Centers) kann ich mir da nicht vorstellen.

    Oder unterliege ich einem Denkfehler? Existieren, die Frage bitte auch an andere Kommentatoren, Finanzierungsmodelle, die auch solche Rahmenbedingungen abdecken?

    Viele Grüße
    Guido Bacharach

Leave a Reply

Ihre E-Mail-Adresse wird nicht veröffentlicht. Benötigte Felder sind markiert. *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>