Recent searches
Search options
@slothrop Naja, Prozesse noch nicht.
Ich wuerde aber gerne mal dahin kommen, dass wir von "der User meldet sich und wir springen" weg- und hin zu "der User moechte etwas und wir arbeiten es sinnvoll und konzentriert ab und behalten dabei den Ueberblick" kommen.
Wenn man es verargumentieren will, kann eine Neuanschaffung ja auch ein Change sein...
Ich wuerde aber "Request for Change" eher so sehen wie "bitte ein Port umpatchen" oder "User hat geheiratet und braucht einen neuen Namen" oder "bitte Software XY updaten"
@ij @slothrop Wir haben da nach ITIL differenziert.
Ein „wir müssen springen“ war halt ein Incident mit entsprechenden SLAs und Eskalations-Zeiten.
Diese Tickets wurden dann per KPI auch ausgewertet - Ticket-Lösungsquote in Stunden etc.
Alles andere Ressourcen-Erweiterung, Software-Updates, Bestellungen etc. war dann ein Change-Request. (1/3)
Da hatte man mehr Zeit, gerade weil Dinge ja auch z.T. Vorbereitung brauchen. Natürlich der Change-Antrag und Genehmigung durch das CAB, aber bei Bestellung je nach Höhe auch Ausschreibung etc. Sowas kann ja auch mal dauern und da mact es keinen Sinn, das Ticket nach einer Woche eskalieren zu lassen, weil es halt einen Monat schlafen gelegt wurde.
Und ja: Neuanschaffungen sind ein klassischer Change-Request. Aus eben oben genannten Gründen. (2/3)
Das hält auch die Statistik vom QM sauber und auswertbarer, wenn man da keine Ticket-Langläufer hat. (3/3)
@Kaffee_Junkie42 @slothrop Ich bin nun wirklich kein grosser ITIL-Fan, aber so ein bisschen Best Practices finde ich schon nett... und man muss halt auch nicht immer das Rad neu erfinden, wenn es schon bewaehrte Methoden gibt...
Hast Du grad zufaellig einen passenden Link parat?