Jak słusznie zauważa Andrzej Raniszewski, informatycy często nie tylko nie integrują się z pracownikami innych działów, ale i nie utożsamiają się z problemami firmy. Często jeszcze słyszy się wśród informatyków tezę, że przestój w sprzedaży czy pracy magazynu to nie jest ich problem. Ich problem to deadlock na bazie danych czy backup blokujący dodawanie nowych rekordów. Informatycy tak postrzegający świat muszą się zmienić, i to bardzo szybko. Bo jeśli się nie zmienią, to ich miejsce zajmie outsourcing usług informatycznych z wszechobecnym SLA (z angielskiego Service Level Agreement), czyli współczynnikiem definiującym jak szybko dana awaria zostanie usunięta dla tego kontraktu.

Twórczo czy wymiernie?

Od tego miejsca jednak spojrzenie autora polemiki i moje znacząco się rozchodzą. Andrzej błędnie zakłada, że skoro firma zlecająca usługę outsourcingową innej firmie rozlicza się z tego na podstawie realizacji mniej lub bardziej skomplikowanych współczynników, to realizację tych współczynników trzeba przenosić na informatyków realizujących to zadanie. Błąd ten rozwinę dalej, gdyż niepostrzeżenie dotarliśmy do zawoalowanego pytania, którego Andrzej otwarcie nie postawił, ale przewinęło się również w komentarzach do elektronicznej wersji naszego artykułu: Jak motywować pozornie nietwórczych pracowników help desku? To pytanie było bardzo silne między innymi dlatego, że jako przykład motywacji informatyków w poprzednim artykule wybieraliśmy bardziej twórcze stanowiska z obszaru informatyki. Po tekście słyszęliśmy więc często tezy: Projektanta czy programistę może da się tak motywować, ale jak motywować serwisanta?

Zanim opowiem, jak to ma być z motywacją dam przykład, dlaczego motywowanie wskaźnikami pracowników help desku jest błędem. Opisywaną sytuację zaobserwowałem w działach obsługi klienta dwóch firm informatycznych, będących spółkami giełdowymi. Przez litość przemilczę ich nazwy, ale skoro takie rzeczy zdarzają się dużym, to mogą się trafić wszędzie. Otóż sytuacja była taka: niemal w każdym programie zdarzają się błędy. Niektóre pojawiają się sporadycznie, inne z mniejszą lub większą regularnością. Przypadek, który mam na myśli dotyczy błędu, który pojawiał się stosunkowo często. Na tyle często, że pracownicy help desku wypracowali sobie metodę szybkiego naprawiania go. Mniej lub bardziej skomplikowany skrypt usuwał błąd w kilka minut. Do napisania skryptu potrzebna była analiza, co jest przyczyną błędu oraz w jakiej sytuacji występuje. Pracownik help desku przeprowadził taką analizę i wykrył warunki powodujące powstanie błędu. I przełożył efekt swojego myślenia na skrypt usuwający błąd.

Jaki ma to związek z destrukcyjnym działaniem wskaźnikowych motywatorów tego pracownika? Otóż pracownik ten premiowany był za szybkość rozwiązywania zgłaszanych mu problemów. Od czasu gdy stworzył skrypt naprawiający problem, jego premia znacząco wzrosła. Błąd, którego naprawa mogłaby zająć kilka godzin, zajmowała mu kilka minut. Dzięki temu średnia szybkość reakcji na pojawiające się incydenty wzrosła, a z nią urosła premia. Nie na rękę było mu więc informowanie działu produkcji, jakie są przyczyny błędu. Na rękę mu było to, że ten błąd istnieje i z wersji na wersję nie jest usuwany.