The Service Desk Inspector: Episode 1 Setting the Challenges from itsmTV on Vimeo.

1. Audyt obecnych praktyk IT Service Desk

Przed wdrożeniem jakichkolwiek zmian dobrze jest zobaczyć jaki praktyki już są realizowane na IT SD te dobre i te złe. Być może już masz aplikację obsługującą SD np (BMC REMADY) która pozwoli zaimplementować i mierzyć wszystkie kluczowe aktywności IT SD. Wynikiem powinna być lista kluczowych aktywności, KPI, SLA na IT SD i procesów wraz z aplikacjami je wspierającymi.

2. Inspekcja SLA

Na podstawie listy SLA z 1 uzgodnij z klientem czy jest to wystarczająca i dopasowana do jego potrzeb lista kluczowych mierników zgodnych z jego Critical Success Factor (CSF). Wynikiem prac powinna być lista SLA dopasowana do potrzeb klienta.

3. Ponowna ocena kosztów

Zbierz informację o ogólnym koszcie dostawy tej funkcji IT SD (płace, aplikacje, połączenia, edukacja) Wylicz ile kosztuje obsługa jednego ticketa. Podziel tickety na kategorie i wylicz jaki udział mają poszczególne kategorie w ogólnej masie wszystkich ticketów. Zastanów się które można rozwiązywać szybciej i taniejnp: -poprzez jasną informację o outage i poważnych awariach można wiele calli szybko (małym kosztem) podłączyć do ticketa mastera, – poprzez wprowadzenie i informowanie o narzędziu do resetu haseł można znacznie usprawnić proces resetów haseł.

4. Sprawdź czy masz właściwy zespół

Sprawdź czy masz właściwe rozłożenie kompetencji miękkich i technicznych. Jeśli masz tylko pierwsza linię powinieneś mieć większość z kompetencjami miękkimi – komunikacja, negocjacja, otwartość,  empatia, odporność na stres. Przy IT SD berdzie technicznym z drugą linią wsparcia i z mocniejszymi SLA na FTF (First Time Fix) będziesz potrzebował doświadczonego drugoligowego zespołu z kompetencjami technicznymi. Taki IT SD będzie droższy ale za to będzie mógł realizować wyższe SLA na FTFy – decyzja klienta, patrz punkt 2.

5. One stop shop

Zbierz doświadczenia z innych obszarów biznesowych (finanse, HR, wsparcie produkcji) jak tam zarządza się zgłoszeniami, kosztami obsługi… by po pierwsze spojrzeć jak gdzie indziej rozwiązano podobne problemy w Twojej organizacji, a po drugie by zwiększyć bazę wiedzy o organizacji, tak by uczynić z ITSD One stop shop.

6. Ucz się na własnych błędach, korzystaj z bazy wiedzy na co dzień

Strwóż bazę wiedzy która wskazuje analitykom ścieżki eskalacji funkcjonalnych i strukturalnych, pozwala szybko połączyć znany błąd z rozwiązaniem lub koniecznością przekazania do konkretnego zespołu wsparcia. Zautomatyzuj ten proces, pozwalając z poziomu logowania ticketów wykorzystywać tę wiedzę.

7. Inicjatywa po stronie IT SD

Nie pozwalaj by inicjatywę przejęły zespoły wsparcia. Zarządzaj całym życiem Incydentu. To ITSD ma wiedzieć najlepiej co się dzieje w organizacji IT. Do tego potrzeba ustalić jasne zasady odpowiedzialności i ścieżki komunikacji oraz KPI dla zespołów wsparcia.

8. Self Service

Już banałem jest, że najłatwiejszym sposobem zmniejszenia  ilości zgłoszeń ITSD jest uruchomienie Self Service, już samo uruchomienie resetowania haseł do poczty odciąży ITSD, a można zautomatyzować dodawania/zmiana uprawnień do współdzielonych zasobów, zamawiania nowych usług…  . Daj użytkownikom bazę wiedzy zbudowaną ze rozwiązań znanych błędów jako narzędzie pozwalające rozwiązać problem przed zgłoszeniem nowego ticketa.

 Więcej o ITSD

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.

Jest coś o Incident Managemnet:I o Probelm Management:

Ale najciekawsze jest na koniec o metrykach

“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.

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.

1. 90% osób nie potrafi odróżnić ryzyka od nieporządnego zdarzenia – sam nie potrafiłem,
2. Ryzyka w tym samym obszarze np. uprzywilejowanego dostępu potrafią się znacznie różnić, a co z tego wynika trudno się analizuje trendy.

Przypomnę co było w manifeście Agile:

• osiągnięcie satysfakcji klienta poprzez szybkość wytwarzania,
• działające oprogramowanie jest dostarczane okresowo (raczej tygodniowo niż miesięcznie),
• podstawową miarą postępu jest działające oprogramowanie,
• późne zmiany w specyfikacji nie mają destrukcyjnego wpływu na proces wytwarzania oprogramowania,
• bliska, dzienna współpraca pomiędzy biznesem a developerem,
• bezpośredni kontakt, jako najlepsza forma komunikacji w zespole i poza nim,
• ciągła uwaga nastawiona na aspekty techniczne oraz dobry projekt (design),
• prostota,
• samozarządzalność zespołów,
• regularna adaptacja do zmieniających się wymagań.

Mało było z tego na webinarze. Ale były ciekawe slajdy:

Klasyczne już podejście do implementacji ITILa

Co klient chce.

Implementing ITIL Using Agile Methods