Do napisania poniższego tekstu zainspirował mnie vlog Andy Brandt – „o KPI czyli metrykach i zaangażowaniu” (http://bit.ly/AJ18KPI). Bardzo spodobało mi się niezwykle celne stwierdzenie, że najpierw należy zbudować motywację zespołu, a następnie zastanowić się jakimi miernikami możemy sprawdzać, czy osiągamy zamierzone cele. Niestety bardzo często doświadczamy czegoś zupełnie odwrotnego – najpierw tworzone są KPI, które podobno mają motywować pracowników lub rozliczać ich z efektów pracy, a następnie wiąże się te KPI np. z systemem premiowania. Katastrofa gotowa.
Przypomniało mi to o próbach opomiarowania obszaru wsparcia użytkowników IT w mojej poprzedniej firmie. Pamiętam jak jeden z dyrektorów rozpoczynając swoje rządy stwierdził, że musimy się opomiarować, bo jak nie zrobimy tego sami, to zrobią to za nas firmy konsultingowe (dodatkowo dokładając do KPI banchmark branżowy, który pokaże jak mizernie działa nasze wewnętrzne IT). Tworzenie KPI zaczęło się od pytania „co możemy mierzyć?”. W tamtym czasie w organizacji było wykorzystywane bardzo proste narzędzie typu HelpDesk, które pozwalało rejestrować zgłoszenia i następnie je procesować – i to w zasadzie tyle. Jedną z miar jaką można było 'wyciągnąć’ z systemu w miarę prosto była ilość zgłoszeń obsłużonych/rozwiązanych przez pracownika w zadanym okresie czasu (np. w przeciągu miesiąca). Zaczęło się więc generowanie plików xls zawierających ilość zgłoszeń rozwiązanych przez poszczególne działy IT, średnie na pracownika itd, itp.
Nikt oczywiście nie zadbał o to, żeby zdefiniować jaką 'granulację’ zachowywać podczas wpisywania zgłoszeń do systemu, więc dość szybko co sprytniejsi zaczęli rozbijać zadania, które kiedyś wpisywano w jednym zgłoszeniu (np. przygotowanie stacji roboczej), na kilka lub kilkanaście zgłoszeń (instalacja systemu operacyjnego, instalacja pakietu MS Office, podłączenie stacji roboczej na stanowisku użytkownika itp). Znalazły się więc sposoby na 'ogrywanie’ takiego miernika.
Gorsze jednak były inne konsekwencje, odczuwalne dla całej organizacji. Np. pracownicy, którzy znali rozwiązanie danego problemu informatycznego niechętnie dzieli się tą wiedzą – informacja o znalezionych rozwiązaniach nie była przekazywana do niższych linii wsparcia (jak to normalnie powinno mieć miejsce), użytkownicy nie byli informowani o tym, że następnym razem mogą sami poradzić sobie ze zgłoszonym problemem poprzez realizację kilku prostych kroków itd. Wśród wielu informatyków zapanowało przekonanie, że jeśli podzielę się swoją wiedzą, to ktoś inny rozwiąże podobny incydent w przyszłości – a przecież każdemu zależało, żeby to 'jego’ słupki rozwiązywalności rosły …
Inny przykład KPI, który okazał się szkodliwy, to ustawienie progu rozwiązywalności incydentów przez pierwszą linię wsparcia (Service Desk) na poziomie 50%. Idea słuszna – chodzi przecież o to, żeby jak najwięcej zgłoszeń od użytkowników było 'załatwianych’ podczas pierwszego kontaktu z IT (first call resolution). Jakie były negatywne skutki takiej decyzji? Otóż pracownicy SD próbowali za wszelką cenę rozwiązać problem podczas pierwszej rozmowy, nawet jeśli trwała ona 30 min. W efekcie inni pracownicy organizacji nie mogli dodzwonić się do SD, bo operatorzy I linii byli zajęci rozmowami. Oczywiście informacje o prostych rozwiązaniach, które mogliby samodzielnie zastosować użytkownicy systemów IT również nie były im przekazywane – jeśli problem pojawił się ponownie, to użytkownik był zmuszony zadzwonić do SD, który znał rozwiązanie, a to podbijało mierzoną wartość.
Ten drugi przypadek oczywiście można obsłużyć w dość prosty sposób – wprowadzając kontr-miarę „Dostępność pracowników SD na poziomie X%”. Ale to wymagało wprowadzenia dodatkowych narzędzi, które pozwalałby na mierzenie tego parametru (np. centralki VoIP).
Jeśli więc zamierzacie wprowadzać jakiekolwiek miary a następnie rozliczać pracowników z realizacji założonych poziomów KPI, zastanówcie się dobrze, jak może to wpłynąć na całą organizację – może się okazać, że takie mierniki będą bardziej szkodziły niż pomagały.
A może znacie inne przykłady KPI, które w konsekwencji okazały się szkodliwe? Zapraszam do dyskusji.
W pewnej organizacji, wpadli na pomysł by uzależnić wypłatę 100 % stawki godzinowej dla programistów od mierzenia terminowości i jakości zadań w SCRUM. To zabiło motywację i morale zespołu, który się rozpada