W tym odcinku poruszam kwestię wsparcia oprogramowania – czy SLA lub innego rodzaju wsparcie jest Ci w ogóle potrzebne, a jeśli tak – to na co zwracać uwagę przy negocjacji z dostawcą.

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się jak łączą się ze sobą świat biznesu i IT.

To jest odcinek 23. Korzystam z oprogramowania w swojej firmie - czy potrzebuję SLA? W tym odcinku analizuję kwestię wsparcia oprogramowanie w kontekście umów SLA, ale także szerzej w kontekście ogólnie pojmowanego wsparcia IT i zastanowię się, czy takie wsparcie może być potrzebne w twoim projekcie, a jeśli tak, to na co zwracać uwagę przy negocjacjach z dostawcą IT? Zacznijmy już klasycznie od definicji. SLA to Service Level Agreement, czyli umowa o poziomie świadczenia usług, w domyśle gwarantowanym poziomie świadczenia usług. Oczywiście jak to z umowami bywa, mogą one określać bardzo różne tematy, zakresy, sprawy, ale na ogół w takiej umowie znajdują się czasy reakcji, sposób komunikacji, zakres działań związanych ze wsparciem, związanym z utrzymaniem określonego produktu lub usługi. Szerzej na temat konkretnych parametrów powiem jeszcze pod koniec odcinka, natomiast teraz zastanówmy się nad samą istotą wdrażania usługi wsparcia, czy wsparcia SLA w kontekście systemów IT.

Zacznijmy od tego, że w ramach SLA praktycznie zawsze znajdują się zapisy związane z reagowaniem na wszelkie usterki, problemy, błędy systemu. Tutaj można od razu zadać sobie pytanie, że przecież w polskim prawie mamy takie pojęcia jak gwarancja, czy rękojmia, to czy nie wystarczyłyby one w zakresie usług i produktów IT? Jak zawsze w takich sytuacjach mały disclaimer, informacja ode mnie, że nie jestem prawnikiem, a co ważniejsze to stan prawny od momentu publikacji odcinka może się zmienić, dlatego we wszelkich sytuacjach spornych, jeżeli mój odcinek natchnie cię do pewnych działań, to radzę skonsultować się oczywiście z prawnikiem. Jak formalności mamy z głowy, przechodząc do meritum, mamy gwarancję, mamy rękojmię i co dalej? Rękojmia mam wrażenie jest trochę mniej znana, ale to ona paradoksalnie jest obowiązkowa. To znaczy przy sprzedaży ta rękojmia jest… Chciałem powiedzieć gwarantowana, więc to się kojarzy z gwarancją. Rękojmia jest po prostu obowiązkowa. Rękojmia chroni kupującego w zakresie wszelkich wad prawnych lub fizycznych. Jeżeli kupujemy produkt fizyczny, na przykład szczotkę do czyszczenia mieszkania i okazuje się, że ta szczotka była niesprawna, wypadło z niej włosie to możemy zgłosić się do sprzedającego i poprosić chociażby wymianę na nowy bądź naprawę, choć w takim przypadku o raczej wchodzi w grę tylko wymiana, ewentualnie zwrot pieniędzy. Na rękojmie, co warto tutaj zwrócić uwagę, mamy na zgłoszenie takiej rękojmi aż dwa lata. Z kolei gwarancja, być może ta bardziej znana forma, jest, co ciekawe, nieobowiązkowa, natomiast czas jej trwania jest dowolny. To może być kilka miesięcy, może być też wiele lat, a może być gwarancja dożywotnia. Zakres też jest ustalany w sposób dość swobodny i to co jest jeszcze ważne, co odróżnia gwarancję i rękojmie to to, że gwarancja dotyczy producenta, a rękojmie sprzedawcy, co może mieć duże znaczenie w przypadku transakcji zakupów międzynarodowych.

Wszystko fajnie, natomiast ja tu sobie przytoczyłem przykład zakupu szczotki, ale ja się to ma do świata software? Znowu, ważne jest to, czy mówimy o produktach informatycznych sprzedawanych masowo, czy o usługach, zwłaszcza o oprogramowaniu dedykowanym. Firmy produktowe, zarówno te popularne jak chociażby Microsoft, czy te niszowe, produkujące zdecydowanie mniej popularne produkty, mają na ogół odrębne działy, które zajmują się świadczeniem wsparcia. Nabywając licencję i to nieważne czy dla programu desktopowego, instalowanego na komputerze. Ja mam taki program, nie będę reklamował, ale mam program do czyszczenia Maca, który zwalnia miejsce na dysku. On jest instalowany na komputerze w systemie operacyjnym. Taki klasyczny program desktopowy, ale też w przypadku typowych SaaS-ów czyli usług świadczonych w chmurze z dostępem abonamentowym, warunki wsparcia są często określone, czy to przy instalacji oprogramowania, czy w momencie zakupu dostępu i wtedy wiemy i powinniśmy oczywiście takie umowy czytać. Czy tak się dzieje, to już jest inny temat. Tam możemy przeczytać na co się zgadzamy, co dostajemy niejako w pakiecie. W przypadku takiego oprogramowania, czyli produktowego, rzadko tutaj się używa takie pojęcia jak gwarancja, czy rękojmia. W dużej mierze dlatego, że spora część problemów, które występują przy takich klasycznych, fizycznych produktach nie dotyczy takiego rodzaju oprogramowania. Jeśli chodzi o zgodność z opisem sprzedawcy, czyli krótko mówiąc to, że kupiliśmy jakiś produkt, który okazało się, że nie ma jakiejś funkcji, to w przypadku oprogramowania produktowego bardzo często dostajemy wersję próbną na 7, 14, 30 dni i wtedy możemy sprawdzić praktycznie wszystkie funkcje oprogramowania, więc trudno powiedzieć, że nie mieliśmy okazji czegoś sprawdzić przed zakupem. Wady wynikające z niskiej jakości surowca, co też się zdarza w przypadku gwarancji, czy rękojmi, też w przypadku oprogramowania nie występują. Naturalnie to co występuje, to błędy oprogramowania. Okazuje się, że chcemy sobie wyeksportować z aplikacji do zarządzania zasobami ludzkimi raport kto ile pracował i okazuje się, że raport jest pusty. Typowy błąd. Oczywiście takie błąd należy zgłosić, ale bardzo często okazuje się, jako że nasz błąd to nie jest błąd naszej sztuki oprogramowania, tylko błąd, który najprawdopodobniej może dotyczyć co najmniej szerokiej grupy użytkowników, a bardzo możliwe, że i wszystkich użytkowników, to takie błędy są naprawiane z reguły bardzo szybko, czyli można powiedzieć, że dochodzi do takiego trybu reklamacji, natomiast z racji tego, że nie mówimy o naprawianiu konkretnej sztuki produktu, tylko naprawianiu całego produktu, to z reguły nie jest to faktycznie problemem. Tu jeszcze jest kwestia zwrotu kosztów i prawda jest taka, że z reguły rzadko prosiłem o zwrot w przypadku aplikacji, czy w przypadku SaaS-ów natomiast jako że firma, dostawca, takiego produktu, czy SaaS nie ponosi kosztu związanego z fizycznie dostarczeniem produktu do domu, czy biura klienta. Najczęściej da się dogadać. Na przykład umorzyć część kosztów, czy zwrócić koszt w całości.

A co w przypadku oprogramowania dedykowanego, szytego na miarę? Naturalnie, temat jest mi zdecydowanie bliższy, można powiedzieć, że o ile w przypadku produktów desktopowych, czy SaaS stoję z reguły po stronie klienta. Tutaj mogę powiedzieć też coś z punktu widzenia dostawcy. Oczywiście w kwestiach gwarancji, czy rękojmi staje się pewnym problemem, bo trudno mówić o wymianie całego oprogramowania na nowe. Zwrot kosztów też jest opcją mało realistyczną, bo oprogramowanie jest szyte na miarę, więc tak jakbyśmy szyli garnitur na miarę i próbowali go oddać. To nie jest tak, że ten produkt może być w jakiś sposób odnowiony i sprzedany ponownie. Oprogramowanie niestety jest dopasowywane do klienta. Ma to oczywiście swoje plusy, ale w tym kontekście to jest pewien problem, więc większość tych opcji, poza oczywiście opcjami naprawy, bo do tego się z reguły sprowadza, jest utrudniona. Właśnie dlatego precyzyjne określenie warunków wsparcia i utrzymania jest kluczowe w przypadku takiej współpracy i w zasadzie najlepiej jest je ustalić jeszcze przed rozpoczęciem takiego projektu, bo nawet jeżeli pojawiają się zapisy dotyczące gwarancji, która jest przypominam nieobowiązkowa, czy nawet chcielibyśmy skorzystać z rękojmi to jakbyśmy chcieli tu odwoływać się do wartości związanych na przykład z czasami reakcji, to jeśli chodzi o reklamację w zakresie rękojmi to mówimy tu o 14 dniach kalendarzowych. Gwarancja to zależy jak się dogadamy, ale też z reguły czasy gwarancyjne nie są krótkie, co w kontekście funkcjonowania systemu informatycznego, który ma jakieś zasadnicze znaczenie dla działania firmy, robi się często, z czasem zdecydowanie zbyt długi. Wreszcie pamiętajmy o tym, że każda gwarancja poza tą dożywotnią, kiedyś się kończy. Rękojmia też jest ustawowo ograniczona. Pytanie, czy po tym czasie, chcemy oprogramowanie wyrzucić do kosza? Pewnie nie. Poza tym, może tak się trochę rozgadałem na temat błędów, usterek i problemów, pamiętajmy, że nawet oprogramowanie, które działa bez błędów i przez cały czas gwarancji nie zostały znalezione żadne usterki lub te, które zostały znalezione zostały naprawione sprawnie, to problem w kwestii usterek to nie jest jedyne, co może wymagać wsparcia w zakresie produktów usług informatycznych.

No dobrze, to co mam na myśli? Przede wszystkim usługa informatyczna, produkt nie funkcjonuje w próżni. Każde oprogramowanie współpracuje z systemem operacyjnym Windows, Linux, na którym jest zainstalowane. Często występują inne komponenty takie jak bazy danych, czy technologie chmurowe i te wszystkie komponenty, który otaczają oprogramowanie, które nabyliśmy, podlegają zmianom, podlegają aktualizacjom. Nawet jeżeli nic nie zmienia się w naszym oprogramowaniu, to te inne powinny być aktualizowane nie dla zabawy, ale chociażby dla bezpieczeństwa, bo w miarę upływu czasu, w istniejącym oprogramowaniu pojawiają się nowe luki, luki bezpieczeństwa i należy w związku z tym to oprogramowanie aktualizować. Jeżeli aktualizujemy inne składniki naszego eko systemu informatycznego, to potencjalnie nasz program, nasz system może w pewnym momencie przestać być w stanie komunikować się z innymi składnikami. Nie muszę chyba za bardzo dodawać, że taka sytuacja ewidentnie pod gwarancję, czy pod rękojmie się nie kwalifikuje. Tutaj może się odwołam do mojej ulubionej branży, do której lubię porównywać IT, czyli branża motoryzacyjna. W samochodzie zepsuje się jakiś komponent, silnik w czasie gwarancji, to powinien zostać naprawiony bezpłatnie o tyle, jeżeli minie określony czas i zużyje się olej albo klocki hamulcowe, to jest już to eksploatacja i to gwarancji nie podlega. To jest coś oczywistego, czym trzeba się zająć dodatkowo. Nawet jeżeli wyłączymy w ogóle wszelkie incydenty, czy te związane z błędami, czy te związane z bezpieczeństwem, czy niezbędnymi aktualizacjami. Umowy SLA potrafią mieć też drobne pulę godzin, związane z gwarantowanym czasem na drobne zmiany w oprogramowaniu, które jednocześnie z reguły są zbyt drobne, aby kwalifikować je jako regularny rozwój systemu, development. Na przykład kwestia drobnych zmian wizualnych, drobnych zmian w konfiguracji aplikacji. Często też kwestia wspierania klienta w zakresie obsługi jego klientów. Może być tak, że pojawią się jakieś zapytania związane z systemem, których sam klient nie obsłuży i będzie potrzebował naszego, czyli dostawcy, wsparcia, aby udzielić odpowiedzi na pytanie. To też są kwestie, gdzie po prostu jest wykonywana praca po stronie dostawcy i taka umowa SLA jest w stanie w właściwy sposób pokierować działaniami i powiedzieć w jaki sposób dochodzi do rozliczeń, jakie są parametry świadczenia takiej usługi.

No dobrze, skoro uzasadnienie dla istnienia takiej umowy SLA się pojawiło, to zastanówmy się o co warto zadbać w trakcie negocjacji takiej umowy. Przede wszystkim czasy. Czas reakcji i czas naprawy. Często też się można spotkać, zwłaszcza w przypadku większych strategicznych systemów, że mamy jeden czas naprawy bez wchodzenia w szczegóły związane z kwestią reakcji i naprawy. Różnica jest taka czas reakcji z reguły rozumiemy jako maksymalny czas, bo to wszystko są maksymalne czasy, w jakim dostawca przystąpi do pracy, przeanalizuje problem, rozpocznie jakiekolwiek działanie. Czas naprawy jest oczywiście czasem, w którym problem powinien być naprawiony, a jeżeli nie jest to możliwe, bo może się okazać, że jest kwestia, która zajmie tyle czasu do naprawienia, że nie uda się zdążyć w terminie jednego dnia roboczego. To kwestia zaproponowania obejścia, które pozwoli na przywrócenie sprawności systemu. Te dwa czasy mają oczywiście zupełnie inne znaczenie, natomiast tutaj nie da się ukryć wartości im mniejsze tym lepsze dla klienta, ale też tym droższe.

Kolejną ważną kwestią jest metoda zgłaszania błędów. Tu wydawałoby się, że może jest to drobiazg, ale w umowie SLA warto precyzyjnie określić i to jest ważne dla obu stron, w jaki sposób dochodzi do dodawania zgłoszeń. Z reguły jest to jakiś system typu Gira, kiedyś było takie narzędzie Track, oczywiście są też różnego rodzaju helpdeski. Chodzi przede wszystkim o to, aby z jednej strony nie doszło do sytuacji, w której klient przekaże informację o wykryciu jakiejś usterki, ale zrobi to w sposób, przez który nie dojdzie do przekazania komunikacji do właściwej osoby, bo na przykład klient zadzwoni do prezesa, który jest na urlopie, a tenże prezes nie będzie w stanie przekazać tej informacji dostatecznie szybko do właściwej osoby. Co gorsza w drugą stronę. Ktoś dodzwoni się do pracownika na urlopie i tu będzie problem z przekazaniem tej informacji. Oczywiście warto też zaproponować jakąś metodę awaryjną, gdyby taki system sam przestał działać, system do zgłaszania usterek, co oczywiście może mieć miejsce. To jest kluczowa rzecz, aby zdefiniować proces zgłaszania takiej usterki. Drugim ważnym aspektem, dlaczego warto jest ten proces opisać dokładniej i też zastosować narzędzie do tego, to potem rozliczanie tych wszystkich prac, czyli klient mówi, że „My nie korzystamy z tego SLA, bo przecież tak mało się dzieje", to wystarczy wejść do narzędzia, zrobić eksport z danego miesiąca, czy z kilku miesięcy i wtedy widzimy czytelnie, że było tyle i tyle prac i jak widać dzieje się. Dla obu stron uzasadnienie, pełna wiedza na temat tego, co się dzieje, jest przydatna.

Wreszcie zakres godzin. To też jest niezwykle istotne, bo z jednej strony wydawałoby się, że najfajniej gdyby była to praca 24/7, czyli cały czas wsparcie. Są takie systemy, które potrzebują takiego wsparcia, ale ono niestety kosztuje. Może się okazać, że lepszy wariant to 24/5, czyli tylko dni robocze, bez świąt i bez weekendów, czy też klasyczne 9-17 przez 5 dni roboczych w tygodniu. Warto pamiętać o różnicach w strefach czasowych, bo 9-17 w Polsce a w Stanach to kilka godzin różnicy, nawet do 9. Warto też pamiętać o określeniu dni świątecznych, które również w różnych krajach mogą różnie wyglądać. O ile z świętami Bożego Narodzenia problemu z reguły nie ma, to jakieś typowo polskie święta zawsze musimy komunikować naszym klientom w Makimo, że mamy tutaj Święto Niepodległości, tu mamy święto sierpniowe naszego wielkiego zwycięstwa. Krótko mówiąc dołączamy w formie wykazu dni i w razie wątpliwości tłumaczymy jak to wygląda.

Zmierzając powoli do końca tego odcinka, chciałbym wrócić jeszcze do kwestii pytania zawartego w tytule. Oczywiście aby udzielić konkretnej odpowiedzi musiałbym porozmawiać z tobą, jeżeli cię taka sytuacja dotyczy. Zresztą zachęcam, bo przypadki bywają bardzo różne. Natomiast chciałbym podać ogólny przepis, taką radę, aby ogóle zacząć rozważania na ten temat. Jeżeli masz software dedykowany, jego działanie ma istotny wpływ na twoją firmę, to na pewno warto rozważyć takie SLA. Jeżeli korzystasz z jakiegoś gotowego oprogramowania, to z reguły jakieś wsparcie masz wbudowane w dostęp do takiej aplikacji, czy do takiej usługi. Warto się zainteresować na jakim poziomie. Jeżeli dalej nie jesteś pewny/pewna lub nie wiesz na jakim poziomie SLA powinno być, to warto zacząć od prostego ćwiczenia, czyli zastanowić się jaki byłby koszt oprogramowania, które nie działa w firmie przez czas rozwiązania w ramach zwykłej gwarancji, czy rękojmi. Ile kosztowałoby to utraconych przychodów? Ile kosztowałoby to straconego czasu pracowników? To są rzeczy, które da się, przynajmniej w przybliżeniu, policzyć. Porównując znowu do samochodów, to trochę jak w przypadku ubezpieczeń samochodowych. Kiedy miałem swoje pierwsze auto, stareńkie Seicento, to nie wykupywałem autocasco, bo gdyby ktoś ukradł to auto, czy gdyby była jakaś szkoda, to cóż. Koszt utracony byłby względnie niewielki. Zaakceptowałem po prostu takie ryzyko. W przypadku kolejnych samochodów stwierdziłem, że jednak ta kalkulacja skłoniła mnie do tego, aby w autocasco zainwestować. Zawsze można ponegocjować i wybrać takie rozwiązanie pośrednie pomiędzy brakiem jakiegokolwiek wsparcia a pełno wymiarową usługą SLA i ustalić coś w rodzaju best effort, czyli jak najlepszego wysiłku, ale bez wymuszania gwarantowanego poziomu usług. Dostawcy IT często nie mają problemu z szybką reakcją, nawet na poziomie SLA, na rozmaite problemy. Tym co nas najbardziej boli, jest kwestia gwarantowanego czasu. Jeżeli mamy z kimś podpisaną umowę SLA, to musimy zaplanować w zasadzie każdy dzień w roku, zwłaszcza długie weekendy, te dni, kiedy mamy Boże Ciało w czwartek, a potem jest piątek, czy majówkę, czy sezony urlopowe. Musimy zaplanować, aby zawsze był ktoś, kto będzie w stanie zareagować na wszelki wypadek. To niestety kosztuje. W momencie, w którym dogadujemy się na zasadzie best effort, czyli spróbujmy zrobić tak, żeby reagować jak najszybciej, ale nie musimy podchodzić do tego na zasadzie gwarancji. Można pozwolić sobie na pewne przestoje, zwłaszcza, tak jak wspomniałem, w strategicznych momentach. Strategicznych z punktu widzenia dostawcy, czyli te długie weekendy, majówki itd. Przez zdecydowaną większość roku to wsparcie faktycznie jest i wtedy nie ma problemu z szybkim czasem reakcji, tyle że niegwarantowanym.

Na tym kończymy ten odcinek. Z pewnością będzie kontynuacja, bo jak to często bywa, jak zaczynam jakiś nowy temat, to okazuje się, że mógłbym powiedzieć jeszcze więcej i więcej, ale to byłby materiał na 2, może 3 odcinki. Też pojawił się pomysł na gościa w tym temacie. Ja jak zawsze w przypadku nowych tematów chciałem z jednej strony zarysować problematykę a z drugiej, jak to się teraz mówi, dać wartość i przedstawić pewnego rodzaju porady, wskazówki, które mogą pomóc w negocjowaniu umów już teraz.

Na dziś to wszystko, serdecznie dziękuję za uwagę. Kłaniam się nisko i do usłyszenia.