Łatwy, trudny problem

Organizacja działów wsparcia była przez całe lata traktowana przez szefów działów IT po macoszemu. Zwykle do czasu, tj. do momentu, gdy okazało się, że trywialne problemy powstające w trakcie realizacji procesu wsparcia mogą skutecznie utrudnić funkcjonowanie całego przedsiębiorstwa.

Organizacja działów wsparcia była przez całe lata traktowana przez szefów działów IT po macoszemu. Zwykle do czasu, tj. do momentu, gdy okazało się, że trywialne problemy powstające w trakcie realizacji procesu wsparcia mogą skutecznie utrudnić funkcjonowanie całego przedsiębiorstwa.

Na pewnym etapie rozwoju każdego przedsiębiorstwa przychodzi moment, w którym kłopotów związanych z codziennym wsparciem nie da się już "zamiatać pod dywan". Zwykle nadchodzi on przy okazji wdrożenia nowej wersji systemu, gdy nagle okazuje się, że z pozoru prosta migracja kompletnie blokuje funkcjonowanie firmy na kilka dni. Czasem pierwsi nie wytrzymują użytkownicy, oskarżając dział IT o lenistwo i niekompetencje. Czasem najpierw cierpliwość tracą informatycy, którym wsparcie użytkowników pochłania czas, który powinien zostać przeznaczony na utrzymanie i rozwój systemów. Czasem wreszcie pierwszy zaczyna zdawać sobie sprawę z problemu menedżer IT, który w pewnym momencie zauważa, że proporcje pomiędzy działaniami podejmowanymi w ramach wsparcia użytkowników dominują nad innymi funkcjami realizowanymi przez dział.

Niezależnie od tego, kto pierwszy dostrzega symptomy problemu, jego nazwanie oznacza konflikt. Dopiero on pozwala dostrzec wagę kłopotów i w odpowiedniej perspektywie spojrzeć na cały problem i znaleźć w organizacji wolę jego rozwiązania.

Kompleksowo i metodycznie

Jak zabrać się do organizacji działu helpdesk? Przede wszystkim kompleksowo i metodycznie.

Podstawowym błędem popełnianym przez menedżerów odpowiadających za wsparcie jest doraźny charakter podejmowanych działań. Użytkownicy skarżą się na działanie głównej aplikacji? Trzeba oddelegować więcej ludzi do wsparcia. Handlowcy z terenu narzekają na problemy z replikacją bazy? Trzeba sprawdzić jakość łączy i zrobić przegląd notebooków. Taka strategia jako żywo przypominająca czasy "wielkich budów epoki socjalizmu", prowadzi do stałego wzrostu kosztów usługi i w rezultacie do eskalacji całego problemu. Zamiast rozwiązywać problemy na dłuższą metę pogłębia tylko frustrację użytkowników systemów i informatyków.

Funkcjonowanie działu wsparcia przypomina system naczyń połączonych. Jakość jego pracy zależy w równym stopniu od wiedzy analityków modelujących procesy, skrupulatności osób rejestrujących zlecenie, zaangażowania menedżerów nadzorujących pracę działu, czy zarządzających relacjami z dostawcami IT i w konsekwencji osób odpowiedzialnych za rozwój kadr, na których barkach spoczywa kwestia kształtowania polityki szkoleniowej firmy (a więc również kształcenie użytkowników z podstawowych zadań związanych z obsługą sprzętu i systemów informatycznych).

Złożoność realizowanych zadań i mnogość wariantów, jakie mogą powstać w trakcie realizacji procesu wsparcia powodują, że budowa działu wsparcia musi być realizowana metodycznie. (Olbrzymią pomocą przy realizacji tego typu przedsięwzięć służy cała biblioteka książek z serii ITIL - IT Infrastructure Library.) Projekt najlepiej zacząć od wyodrębnienia podstawowych funkcji realizowanych w ramach świadczenia usług wsparcia i doboru miar, pozwalających na ich mierzenie. Stworzenie takiej listy, będącej zalążkiem katalogu usług, oraz próba pomiaru realizowanych zadań pozwolą na zebranie wiedzy potrzebnej do analizy i ewentualnego przemodelowania procesów. Bez takich pomiarów zarządzanie usługami wsparcia będzie niemożliwe.

Szczegółowe dane pozwolą również na odpowiednie zaprojektowanie organizacji komórki wsparcia. Nie znając charakteru problemów, z którymi zwracają się użytkownicy, a także ile czasu poświęcają na ich rozwiązanie dedykowani pracownicy, trudno oszacować, ile osób powinno pracować na pierwszej linii wsparcia, a także jaki procent czasu na rozwiązywanie usterek i błędów powinni poświęcać inni pracownicy pionu IT. Nie można również zaprojektować spójnej bazy wiedzy na temat zgłaszanych problemów. W rezultacie trudno więc liczyć na to, że z czasem uda się ograniczyć liczbę zgłoszeń, wynikających czy to z wadliwej konfiguracji sieci, czy np. braków kompetencyjnych niektórych użytkowników systemów.

Metoda małych zwycięstw

Budowa racjonalnie zarządzanego działu wsparcia to żmudny proces. Tym większe znaczenie dla jego sukcesu ma odpowiednia promocja całego projektu. Musi ona obejmować wszystkich tych, których dotyczą problemy wsparcia, a więc de facto niemal cały personel w organizacji.

Jak zdobyć zaufanie tak dużej i zazwyczaj niejednorodnej grupy ludzi. Sprawdzonym sposobem jest metoda "szybkich zwycięstw", a więc takie prowadzenie projektu, by możliwie duża grupa użytkowników szybko odczuła pozytywne skutki zmian. To ułatwia zjednanie personelu do dalszych działań i zazwyczaj zapewnia przychylność także w trakcie realizacji trudniejszych elementów projektu. (Nie możemy przecież zapominać, że budowa centralnego działu wsparcia ma na celu przede wszystkim usprawnienie i racjonalizację procesów wsparcia i nie musi zawsze oznaczać bezwzględnej poprawy jakości jego funkcjonowania.) O to, że dodatkowa doza sympatii i cierpliwości może nam być podczas budowy działu helpdesk potrzebna, możemy być spokojni.