Incident & Problem Management jak to działa i po co?
Polecam webinar:
Incident & Problem Management – Service is, as Service Does
Patrick Bolger wałkuje te same tematy po raz setny i o dziwo dochodzi do tych samych wniosków, jakie metryki są ważne i jak je zbudować. Robi to jednak zaskakująco prosto i moim zdanie trafnie.
Po ce te procesy?
Po co się zmóżdżać i wymyślać jakieś super mądre odpowiedzi na proste pytania, proszę:
“If you can’t describe what you are doing as a process, you don’t know what you’re doing.”
W. Edwards Deming
A jak coś tam poprawić to:
“Almost all quality improvement comes via simplification of design, manufacturing… layout, processes, and procedures.”
Tom Peters
Post dedykuję wszystkim dotkniętym opisywaniem procesów i procedur.
Krótka teoria czasu
Blog ten miałem prowadzić w wolnym czasie, gdy zaczęło mi brakować wolnego na bolgi, robiłem w międzyczasie, ostatnio tylko po czasie, więc ze sporym opóźnieniem. Cały czas mieszczę się jednak w czasie, co prawda przeszłym, ale jednak.
Czym się różnią metryki od KPIs, CSF
Metryką jest jakiś standard pomiaru - liczba incydentów zalogowany, średni czas zalogowania incydentu, procent rozwiązana incydentów w ciągu uzgodnionego poziomu usług (SL).
Key Performance Indicator (KPI) jest metryką, które została wybrana by mieżyc wydajność i może być używany jako miernik poprawy jakości. Najczęściej korzysta się z kilku kluczowych wskaźników wydajności KPI i na nich się skupia.
Zasadniczą różnicą jest to, że metryka to tylko pomiar, KPI jest metryką która została wybrana i uzgodnione z partnerami (czy wewnętrznymi czy z zewnętrznymi) by obserwować czy proces nią mierzony spełnia zadane oczekiwania definiowane w czynnikach sukcesu CSF.
Critical Success Factor (CSF) to, to co musi się wydarzyć by proces, projekt, plan, lub usługa mogła odnieś sukces. KPI są używane do pomiaru realizacji każdego CSF. Np. wskazany procent FTF.
Zarządzania ryzykiem w IT
Każdy z was pewnie kiedyś szacował ryzyko jakościowo lub ilościowo podczas prowadzenia projektu. Pewnie kilka osób, też zarządzało ryzykiem wyłącznie IT. Nie wiem jakie Wy macie doświadczenia, moje po ponad miesiącu zarządzaniu globalnym ryzykiem IT można streścić:
- 90% osób nie potrafi odróżnić ryzyka od nieporządnego zdarzenia – sam nie potrafiłem,
- Ryzyka w tym samym obszarze np. uprzywilejowanego dostępu potrafią się znacznie różnić, a co z tego wynika trudno się analizuje trendy.
Agile w ITIL? Bez pomysłu
Po wysłuchaniu „Implementing ITIL Using Agile Methods” jestem rozczarowany. Tylko jeden prezenter miałem wrażenie że wie z czym Agile się je. Każdy projekt odbywa się krokami cząstkowymi, ale nie znaczy to że jest to projekt robiony w Agile.
ITIL i Agile w jednym
Na 17 listopada przygotowana jest prezentacja z implementacji ITILa za pomocą zwinnych metod, Agile.
Panel będzie moderował Alim Ozcan. Przedmiotem dyskusji będzie praktyczne wykozystanie ITIL i Agile do mierzalnego podnoszenia jakości usług IT dla biznesu.
Czy wystarczy zarządzać projektem?
Metodyki takie jak PRINCE2, PMBOK, ITIL, COBIT, COPC podają rozwiązania w wymiarze procesów, wiedzy, celów i mierników. Czy jednak właściwe stosowanie formalnych, nawet najlepszych metodyk zapewni sukces projektu?
The Standish Group w raporcie „Chaos” w 1995 roku, często dyskutowanym i pozostającym wciąż aktualnym, jako czynniki sukcesu projektu podaje:
- Zaangażowanie klienta 15.9%
- Wsparcie kierownictwa 13.9%
- Jasno określone wymagania 13.0%
- Właściwe planowanie 9.6%
- Realistyczne oczekiwania 8.2%
- Mniejsze odstępy pomiędzy kamieniami milowymi 7.7%
- Kompetencje pracowników 7.2%
- Odpowiedzialność 5.3%
- Jasno postawione cele i wymagania 2.9%
- Ciężko pracujący, skupieni pracownicy 2.4%
Czy zatem formalna metodyka prowadzenia projektu jest istotna? Szereg z wymienionych 10 czynników jest opisanych i parametryzowanych przez metodyki np: zarządzanie oczekiwaniami, cele i wymagania, planowanie, ale te bezpośrednio formowane przez metodyki np. właściwe planowanie, mniejsze odstępy pomiędzy kamieniami milowymi … stanowią jednak ok 30 %, gdy ponad 50% to czynniki nie kształtowane przez metodykę, a zależne od czynników miękkich: komunikacji, motywacji, odpowiedzialności, otwartości, chęci współpracy …
Co zagraża rozwojowi?
W drodze do rozwoju poprzez cnoty zgodnie z coaching quest , każdej cnocie towarzyszy jej zagrożenie czyli przeszkoda. Identyfikacja, zrozumienie i przezwyciężenie każdej przeszkody prowadzi do rozwoju.
Podstawy jakości
U podstaw większości japońskich systemów jakości staneło pięć zasad 5S:
- Seiri – selekcja,
- Seiton – systematyka,
- Seiso – sprzątanie,
- Seiktsu – schludność,
- Shitsuke – samodyscyplina.
Zasady te stosuje się w systemach zarządzania jakością i można z powodzenie używać ich w codziennym życiu. Czytaj dalej …»
