25 prawd o wsparciu technicznym

Przez lata firmowe działy wsparcia technicznego wypracowały wyrafinowane sposoby rozwiązywania problemów technicznych i rozwiązywania problemów z użytkownikami. Zostały one oparte na oczywistych - przynajmniej dla doświadczonych pracowników - prawdach, które nie wymagają żadnego uzasadnienia. Uświadomienie ich sobie może być pomocne w projektowaniu procesów wsparcia, które zapewnią naprawdę wysoką efektywność zespołu i zadowolenie użytkowników.

Przez lata firmowe działy wsparcia technicznego wypracowały wyrafinowane sposoby rozwiązywania problemów technicznych i rozwiązywania problemów z użytkownikami. Zostały one oparte na oczywistych - przynajmniej dla doświadczonych pracowników - prawdach, które nie wymagają żadnego uzasadnienia. Uświadomienie ich sobie może być pomocne w projektowaniu procesów wsparcia, które zapewnią naprawdę wysoką efektywność zespołu i zadowolenie użytkowników.

1 Przybliżona data usunięcia usterki, którą pracownik wsparcia technicznego poda użytkownikowi, to data, którą ten dobrze zapamięta. Nigdy nie należy użytkownikom przekazywać informacji o terminie rozwiązania problemu, jeśli nie ma absolutnej pewności, że uda się go dotrzymać.

2 Praca bez zdefiniowanych precyzyjnie granic to praca bez końca. Nie ma sensu mówić: "Pracuję nad tym" bez określenia kiedy zadanie zostanie wykonane lub, w szczególnym przypadku, dlaczego nie zostanie ono wykonane w terminie.

3 Okres największego zagrożenia dla działu wsparcia to okres uruchamiania nowych lub zmodernizowanych systemów. Pewna doza konstruktywnej paranoi nie jest sama w sobie zła. Warto sprawdzić, że uruchomione zostaną właściwe moduły czy wersje oprogramowania. Dobrze nawet sprawdzić to dwa razy.

4 Użytkownicy miewają selektywną amnezję. Zawsze należy mieć "podkładkę" w postaci listu elektronicznego lub podpisu na papierze.

5 Nic nie zostanie wykonane, ani nic nie będzie działać, do czasu aż pracownicy działu wsparcia nie zainwestują przynajmniej niewielkiej części swojego czasu w sprawdzenie jak przedmiotowe rozwiązanie działa. Należy przyjąć, że tak jest, a nie dziwić się czy irytować.

6 Krótkie "Nie!" nie jest konstruktywną odpowiedzią. Nigdy nie należy tak odpowiadać na żądanie pomocy lub asysty. Zamiast tego należy użyć: "Proszę pozwolić mi to sprawdzić. Zajmę się tym do wtorku". Warto się tym zająć. Naprawdę można komuś pomóc.

7 Czego nie można zmierzyć, tego nie można kontrolować. Zdefiniowanie wewnętrznych celów poziomu obsługi i zbieranie danych to dobry pomysł. Następnie trzeba porównywać "powinno być" z "jest".

8 Nie jest możliwe oszacowanie czasu potrzebnego do wykonania zadania bez dokładnego poznania liczby i złożoności żądanych funkcji. Analiza żądań funkcjonalnych, nawet w przypadku błahych problemów, zawsze jest dobrym pomysłem.

9 Lis nie nadaje się do pilnowania kur! Dział wsparcia nie powinien samodzielnie oceniać własnej pracy. Zawsze należy postarać się o niezależną weryfikację.

10 Środowisko testowe to nie środowisko produkcyjne. Nigdy nie należy zakładać, że działanie czegoś w trakcie testów gwarantuje działanie w rzeczywistym środowisku.

11 Kupiłeś? Jest twoje. Jeśli pracownik działu wsparcia odbiera telefon, odpowiada za doprowadzenie sprawy do szczęśliwego zakończenia.

12 Krytyka na ogół jest czymś pozytywnym. Poszukiwanie winowajców - nie! Obwinianie nie ma sensu. Lepiej zastanowić się jak zespół może lepiej wykonywać zadania.

13 Prawa Murphy'ego powinny nastrajać optymistycznie. Nawet najlepsze planowanie i wykonywanie planu doprowadzą do problemów w najmniej odpowiednim momencie. Zawsze należy być czujnym, elastycznym i przygotowanym.

14 Efektywne komunikowanie załagodzi efekty wielu aktualnych i potencjalnych problemów. Kierownictwo i użytkownicy powinni być błyskawicznie informowani o możliwych kłopotach lub zidentyfikowanych właśnie problemach. Należy działać proaktywnie, a nie reaktywnie!

15 Nikt nie lubi nieprzyjemnych niespodzianek. O zmianach należy informować wszystkich, których pracę mogą one zakłócić.

16 Pamięć pracownika działu wsparcia również bywazawodna. Podobnie jest z pamięcią użytkowników. Nie warto ufać bezgranicznie pamięci(patrz punkt 4). Wszystko należy zapisywać.

17 Zadanie nie zostało zakończone do chwili otrzymania od użytkownika potwierdzenia, że problem został rozwiązany.

18 Jeśli nie określi się precyzyjnie oczekiwań, otrzymuje się to, na co się zasłużyło, a nie to, czego się potrzebuje. Precyzyjna informacja o tym, czego i kiedy oczekujemy oraz o tym, co i kiedy się dostarczy, jest absolutnie niezbędna.

19 Użytkownicy są klientami, a nie problemami! Tak należy ich traktować.

20 Przekonanie jest rzeczywistością. Zawsze należy domagać się informacji zwrotnych w związku z tym, co zostałozakomunikowane. Nigdy nie należy zakładać, że przekonanie pracownika działu wsparcia jest zgodne z rzeczywistością użytkownika.

21 Odpowiedzialność bezuprawnień jest przyczynąporażki. Jeśli czyni się kogoś odpowiedzialnym za coś, należywyposażyć go w uprawnienia, które pozwolą mu wykonać zadanie.

22 Łatwo dostrzegać problemy, o wiele trudniej znaleźćrozwiązanie. Nigdy nie należy przychodzić z problemem, jeśli nie ma się pomysłu na jego rozwiązanie.

23 Zdrowy rozsądek pracownika działu wsparcia nie zawsze jest zbieżny ze zdrowym rozsądkiem użytkowników. Nie można zakładać, że oczywistości są oczywiste dla wszystkich.

24 Technologia nie zawsze działa tak, jak powinna. Dobrym pomysłem jest opracowanie strategii testowania ograniczeń operacyjnych wszystkich technologii, które mają istotny wpływ na działanie biznesu.

25 Przypadki utraty danych mają miejsce zwykle akurat wtedy kiedy nie zostały wykonane ich kopie zapasowe. Regularny, systematyczny backup danych to absolutna konieczność!

W dniach od 18 do 21 czerwca 2007 r. w Ożarowie Mazowieckim odbędzie się III Forum Help Desk i Wielka Gala ITSM, zorganizowana przez Help Desk Institute. Computerworld jest patronem konferencji.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200