IT Project

Zarządzanie organizacją i Projektami IT

Ostatnio odbyłem ciekawą rozmowę z osobą zarządzającą firmą IT na temat znaczenia serwisu. Dlatego chciałbym się podzielić z Wami przemyśleniami na ten temat, bo wydaje mi się, że często serwis jest traktowany jako drugorzędny dodatek do biznesu, a nie kluczowy element biznesu. Stąd artykuł. Zapraszam.

Co mnie upoważnia do zabrania głosu w tej sprawie?

Przez ponad 5 lat byłem szefem serwisu private cloud oraz infrastruktury technicznej i systemowej dla ponad 170 Klientów. Serwis ten był realizowany w trybie 24/7, często w trybie high duty. Organizacja serwisu była poprzez BOK 24/7, nocne dyżury administratorów oraz pracę zespoły administratorów w dni robocze. W kolejnej firmie był realizowany serwis aplikacyjny systemu ERP (D365). Co było ciekawym doświadczeniem, ponieważ serwis ten był budowany od podstaw. Jako szef delivery byłem odpowiedzialny zarówno za projekty implementacyjne jak i projekty serwisowe.  To pozwoliło mi spojrzeć nieco inaczej na całość procesu dostarczania i serwisowania systemu IT oraz zarządzania zespołami i problemami z tym związanymi.

Przemyślenia:

1. Dobry i właściwy serwis to bezpieczeństwo Klienta

 Oczywiście podstawowym zadaniem serwisu jest utrzymanie niezawodności serwisowanego Systemy IT, rozwiązywanie na bieżąco problemów użytkowników, aktualizacje Systemu IT (np. podnoszenie oprogramowania do wyższej wersji, wgrywanie tzw. patchy) oraz rozwój systemu (realizacja CR). Natomiast ciekawym jest generalne podejście do sposobu realizacji serwisu. I tu chciałbym zwrócić uwagę na następujące zagadnienia:

1. 1. Serwis pasywny

To jest serwis, w którym czeka się na zgłoszenie od Klienta tzn., że jest problem do rozwiązania. Tak działa przytłaczająca liczna umów serwisowych. Jednak takie podejście powoduje, że o problemie Dostawca dowiaduje się post factum zdarzenia. Co gorsza, zwykle nie rozwiązany problem generuje kolejne problemy (np. wizerunkowe, biznesowe, logistyczne itd. Klienta) i z czasem narasta (np. poprzez konieczność wycofania większej liczby dokumentów, poprawy większego zakresu danych, tworzenie rozwiązań tymczasowych itd.). Brak dokładnego opisu problemu i danych diagnostycznych przy zgłoszeniu jedynie wydłuża czas rozwiązania problemu. Obecnie w dobie wysokiej konkurencji na rynkach Klientów, taki serwis dla wielu Klientów może być nie wystarczający, a nawet nie dopuszczalny. Mimo to mamy wiele takich umów. Kalkulacja kosztów ryzyka przestoju systemu IT vs koszty właściwego serwisu raczej nie jest mocną stroną podczas negocjacji tego rodzaju umów serwisowych, a rozwiązanie tego problemu w umowach poprzez wysokie kary nie jest rozwiązaniem, a jedynie próbą leczenia objawowego. Czy można inaczej? patrz punkty poniżej.

1. 2. Serwis aktywny

Utrzymanie systemów IT w szczególności w trybie high duty, 24/7, wymaga innego podejścia i przejścia na serwis aktywny. tzn. taki w którym są elementy predykcji problemu, a w przypadku wystąpienia problemu system sam zgłasza się do serwisu. Oznacza to, że kluczowe elementy systemu są podawane stałemu monitorowaniu, wraz z określeniem wartości brzegowych tych parametrów, przy których podejmowana jest akcja prewencyjna lub serwisowa. Jednak takie serwisy wymagają odpowiedniego systemu monitorowanie, odpowiednich czujek, zbudowania kilkustopniowego zespołu podejmującego akcje serwisowe. Jednak korzyścią takiego rozwiązania jest wysoka stabilność i dostępność Systemu IT, a tym samym maksymalna ochrona biznesu Klienta. Predykacja  problemu to możliwość zapobiegania. W przypadku wystąpienia problemu, szybsza reakcja, diagnostyka na podstawie wskazań monitorowanych parametrów, skrócenie czasu znalezienie rozwiązania. Taki serwis jest możliwy do zbudowania. Wiem, to z doświadczenia, bo sam budowałem takie systemy. Co więcej, przy odpowiedniej bazie wiedzy, można doprowadzić do sytuacji, że praktycznie 60% problemów może rozwiązywać osoba o mniejszych kompetencjach. A to oznacza lepszą jakość za niższą cenę.

1. 3. Ciągłość działania/dostępności Systemu IT– zmiana mentalna i kluczowa

Kolejnym poziomem podnoszącym jakość świadczenia usług serwisowych jest przejście na umowy serwisowe w oparciu o KPI ciągłości działania i/lub dostępności systemu. W skrócie można powiedzieć, że są to umowy w których „Klient płaci za to, że jest zdrowy, a nie za, wizytę u lekarza jak zachoruje”. Oznacza to, że Klient płaci pełną stawkę opłaty serwisowej, jeśli dany KPI zostanie dotrzymany oraz odpowiednio mniej jak KPI nie zostanie dotrzymany lub wcale jeśli KPI spadnie poniżej ustalonej między Stronami wartości.  W takim przypadku, w interesie dostawcy serwisu jest takie utrzymanie Systemu IT, aby otrzymał pełną opłatę za usługi serwisowe. W zamian Klient otrzymuje dużo bardziej stabilny system i wysokie bezpieczeństwo swojego biznesu. Oczywiście taki system rozliczeń musi zostać poprzedzony audytem obecnego Systemu IT, doprowadzeniem go do poziomu niezawodności akceptowalnego przez obie strony, a następnie opomiarowany go pod kątem automatycznego naliczania KPI. W tym sposobie rozliczeń, Dostawca musi być odpowiednio przygotowany, aby taką usługę realizować (zespoły, narzędzia, procedury). Taki system rozliczeń daje się budować i takie umowy serwisowe miałem w portfolio serwisowym, a  stąd to już krótka ścieżka do outsourcingu części lub całości Systemu IT Klienta np. w obszarze administracji, ale czasem i biznesowym.

2. Dodatkowe moce wynikające z Serwisu - synergia zespołu realizacji i serwisu

Z perspektywy czasu uważam, że realizacja i serwis powinny być spinane przez jedną osobę. Zgodnie z powiedzeniem „jak sobie pościelisz, tak się wyśpisz”. W takim układzie właściwe zrealizowanie projektu realizacyjnego jest w interesie takiej osoby, bo za chwilę wdrażany system będzie miał w serwisie. Dla Klienta jest to również korzyść w postaci zachowania ciągłości działania, wiedzy o Systemie IT po stronie Dostawcy co niewątpliwie wpływa na stabilności systemu IT oraz potem szybkość rozwiązywania problemów przez serwis.  Ale też jest wiele innych korzyści z takiego układu, przy odpowiednim podejściu:

1. 1. Z założenia, Zespół Serwisowy powinien być nieco przewymiarowany (i zwykle jest przewymiarowany, ze względu na niedookreśloność liczby zgłoszeń serwisowych w danym okresie), jednak to przewymiarowanie można również wykorzystać do czasowego wymagających wsparcia projektów realizacyjnych.
   2. W okresach mniejszej aktywności w projektach realizacyjnych, Zespół Realizacyjny czasowo powinien wspierać serwis np. w akcjach serwisowych, realizacji większej liczby zgłoszeń, usunięcia awarii, realizacji CR itd. (oczywiście o ile jest taka potrzeba!). Dodatkowym atutem tego działania jest podniesienie świadomości w zespole realizacyjnym z czym się mierzy serwis, jakie konsekwencje są po stronie serwisu nie właściwie rozwiązanych problemów realziacyjnych (np. kosztów gwarancji, kar itd.), czy też braku dobrej dokumentacji itd.
   3. Zespół Serwisowy włączający się  min w końcowym etapie projektu realizacyjnego (np. w trakcie HyperCare), poznaje specyfikę Systemu IT oraz Klienta zanim rozpocznie się właściwy serwis. Tym samym nieco odciąża zespół realizacyjny, nabywa wiedzę, aby później szybciej diagnozować problemy, szybciej dostarczać rozwiązania.
   4. Dodatkowo, zespół serwisowy może być kuźnią kadr dla firmy, a w szczególności dla zespołów realizacyjnych. Przyszli konsultanci, developerzy mogą podglądnąć na rzeczywistym działającym systemie jak pewne problemy zostały rozwiązane. Pod nadzorem mogą rozwiązywać problemy. Tym samym skrócić czas nauki i zbierania doświadczeń.

Oczywiście uzyskanie takiej synergii nie jest proste, ponieważ mentalnie często zespół realizacji jest inny od serwisu. Dodatkowo struktury organizacyjne Dostawcy tylko wzmacniają ten problem poprzez tworzenie oddzielnych zespołów czy pionów. Poza tym wymaga to zbudowania wspólnych odpowiednich narzędzi dla obu zespołów, wykorzystania części tych samych procedur, dokumentów itd. To da się zrobić.

3. Serwis jako źródło nowych działań i projektów

Niby oczywiste, ale ile firm tak naprawdę potrafi w serwisie rozwijać się razem z Klientem? Aktywnie diagnozować potrzeby Klienta. Sprawdzać, jak Klient pracuje z Systemem IT, aktywnie podpowiada, jak coś zrobić szybciej, lepiej, jaką zmianę zaproponować aby usprawnić pracę itd. Monitoruje funkcjonalności dostarczane przez Producenta systemu i podpowiada Klientowi co można wykorzystać w jego biznesie. Regularnie spotyka się z Klientem w celu omówienia jego planów rozwojowych w celu ich wsparcia w Systemie IT. To jest ogromny obszar możliwości rozwoju biznesu i współpracy zarówno na poziomie serwisowanego systemu IT, ale też innych systemów jakie Klient posiada lub planuje wdrożyć. Znam firmy które latami utrzymują się z tego typu działań.

4. Serwis jako stabilizacja biznesu dla firmy IT

Ostanie punkt, choć od niego zaczęliśmy dyskusję, na którą powołałem się na początku. Serwis bywa nie doceniany, ale głównie dlatego, że zwykle jest traktowany jako drugorzędny dodatek do biznesu. A to duży błąd. Serwis powinien budować długofalowe relacje z Klientem, które powinny przekładać się na nowe projekty i działania. Przychody z serwisu powinny pokrywać min. 60% kosztów stałych firmy, aby można było mówić o stabilnych podstawach biznesowych działalności.  W przypadku koniunktury lub dekoniunktury na rynku daje jej możliwość odpowiednio, rozwoju lub przetrwania na rynku w trudnym czasie.

Powyższe zagadnienia i wskazówki rozwiązań nie są czysto teoretyczne, ale są to rzeczywiste pomysły i rozwiązania, które udaje się realizować. Choć jak to zwykle bywa diabeł leży w szczegółach…

Jak zawsze zachęcam do współpracy.

IT Project » Strona główna

Zaproszenie

Jeśli interesuje Ciebie jakaś tematyka, która warta jest opisania w blogu lub chciałbyś się podzielić własnym tekstem lub przemyśleniami, proszę skontaktuj się ze mną, prześlij propozycję teksu. Ten blog może być forum wymiany myśli na temat zarządzania organizacją, czy też Projektem IT.

Zaproszenie

Jeśli interesuje Ciebie jakaś tematyka, która warta jest opisania w blogu lub chciałbyś się podzielić własnym tekstem lub przemyśleniami, proszę skontaktuj się ze mną, prześlij propozycję teksu. Ten blog może być forum wymiany myśli na temat zarządzania organizacją, czy też Projektem IT.

tel. +48 605-960-037 

jacek.baran@poczta.onet.pl