W poprzednim artykule dowiedzieliście się między innymi:

Miejsce na tekst pod listą. Jeśli nie mieliście okazji przeczytać tego piątego, z serii artykułów „Wdrożenie systemów IT. Błędy i problemy”, to bezpośredni link zamieszczamy poniżej.

Wybór zbędnych funkcjonalności w systemie

Warto przemyśleć jakie faktycznie funkcjonalności są niezbędne we wdrażanym systemie. Wprowadzenie hierarchizacji funkcji oraz określenie priorytetów pozwoli sprawniej przeprowadzić prace.

Dostawcy systemów informatycznych często oferują bogate pakiety funkcji w swoich systemach. Przedsiębiorstwo niesione na fali prezentacji systemu, pokazu możliwości i zapewnień o niezbędności danych rozwiązań, może podejmować nietrafne decyzje co do kształtu zamawianego systemu.

Potrzeby odnośnie systemu informatycznego są ściśle związane z branżą oraz specyfiką konkretnego przedsiębiorstwa. Gotowa lista funkcjonalności niemal zawsze niesie ze sobą funkcjonalności zbędne lub zbędne w danym momencie.

Organizacja musi trafnie określić, które z oferowanych funkcji są potrzebne i jak będą wykorzystywane (ich działanie musi przynosić optymalne efekty i zyski). Aby odpowiednio dobrać funkcje w systemie potrzebna jest analiza przedwdrożeniowa, ale też znajomość modeli procesów i logiki ich funkcjonowania.

Należy pamiętać o hamowaniu pokusy dobierania funkcjonalności na wyrost „bo może się przydadzą za jakiś czas” albo funkcjonalności niepotrzebnych, tylko dlatego, że są oferowane w niższej cenie czy mają stanowić znakomite uzupełnienie już wybranych funkcji.

Jeżeli wystąpi konieczność rozbudowy systemu, to odpowiednio ustalone warunki takiego działania pozwolą na dodanie wymaganych funkcjonalności. Natomiast oczywiście w przypadku jasnego planu i wiedzy w temacie wdrożenia określonych funkcjonalności sukcesywnie, warto rozważyć specjalne oferty i promocje, gdyż faktycznie może okazać się to korzystne finansowo.

Inna kwestia związana z customizacją rozwiązań i doborem funkcjonalności to kompatybilność – tak z zewnętrznymi systemami, jak i wewnętrzna tzn. możliwości takiego implementowania zmian w modułach czy też dodawania nowych elementów, aby nie dochodziło do zaburzenia logiki działania całego systemu czy błędów w jego poszczególnych modułach.

Wiele zależy od technologii i budowy systemu, jednak może zdarzyć się, że zmiany w jednym module będą miały wpływ na wynik działania innych modułów, co doprowadzić może nie tylko do błędów w postaci problemu z aplikacją, ale np. generowania niepoprawnych komunikatów, raportów, zestawień lub wyliczeń.

 

Problematyczna umowa wdrożeniowa

Zadbaj o dobrze skonstruowaną umowę wdrożeniową zapewniającą odpowiednie warunki i bezpieczeństwo obu stronom.
W przypadku wątpliwości włącz w skonstruowanie analizy umowy doświadczoną kancelarię prawną lub doradców.

Umowa wdrożeniowa jest jednym z najważniejszych elementów dotyczących prowadzenia prac prowadzonych do uruchomienia systemu informatycznego. Rzutuje na niemal każdy aspekt prowadzonych prac, ale przede wszystkim jej konstrukcja oraz zawartość determinuje efektywnąi sprawną finalizację wdrożenia.

W poniższej części używam zwrotu współpraca powdrożeniowa, jednak chciałbym wprowadzić także pojęcie współpracy PROwdrożeniowej, czyli nastawionej na takie postępowanie podmiotów biorących udział w przedsięwzięciu, aby prowadziło do sukcesu i pozytywnego zakończenia prac, a także dawało finalnie korzyści każdej ze stron.

Umowa na wdrożenie systemu powinna być podpisana tak, aby zapewnić obu stronom korzyści. Należy osiągnąć porozumienie satysfakcjonujące odbiorcę oraz dostawcę systemu. Należy dokładnie przemyśleć, jakie zapisy umowy są dla organizacji pożądane, jakie zapisy muszą znaleźć się w umowie, aby zabezpieczyć interesy przedsiębiorstwa i nie powodować nieprzewidzianych konsekwencji czy kosztów. Oczywistym jest, że należy wyważyć wszystko tak, aby oczekiwania co do kształtu umowy były realistyczne i możliwe do spełnienia przez wykonawcę.

Dobrym rozwiązaniem, często praktykowanym, jest podpisywanie tzw. umów SLA mających gwarantować najwyższy stopień zaangażowania i staranności dostawcy. Uwagę powinny zwrócić zapisy dotyczące m. in. sposobu rozliczania usługi, kosztów dodatkowych, sposób rozliczania usług serwisowych i gwarancyjnych, sposób przeprowadzania szkoleń z obsługi systemu czy zapisy dotyczące kar umownych.

Myślę, że trudno byłoby znaleźć czy też stworzyć umowę idealną. Są jednak określone elementy, bywa że pomijane lub traktowane niezbyt szczegółowo, które mogą zabezpieczyć interesy obu stron, a jednocześnie być bardzo pomocne przy rozwiązywaniu potencjalnych sporów.

W umowie poza kwestiami związanymi stricte z przygotowaniem oraz wdrożeniem systemu istotne są takie elementy jak obsługa powdrożeniowa, testowanie, szkolenia personelu, zakres i dostarczanie aktualizacji, wsparcie użytkowników, administracja systemem, możliwość jego rozwoju poprzez zlecenie prac innemu wykonawcy, zapewnienie infrastruktury czy też gwarancje serwisowe.

Następna sprawa to zapisy o możliwości wypowiedzenia umowy (mam na myśli umowę wdrożeniową, choć warunki współpracy powdrożeniowej także powinny być określone w formie pisemnej) oraz obwarowania z tym związane. Wielce istotny element to także kary umowne i tutaj pole do popisu jest szerokie, bo możliwości ustalenia tej kwestii jest sporo. Sygnalizuję jedynie, że tego typu zapisy, po dokładnym przemyśleniu i dostosowaniu do faktycznych warunków, powinny znaleźć się w umowie. Opisanie ich jasnym i spójnym językiem pozwoli na precyzję przy ewentualnym korzystaniu z nich.

Wdrożenie systemu nie obędzie się bez już wcześniej wspomnianej współpracy pomiędzy zamawiającym, a wykonawcą. I paradoksalnie na tym polu może pojawić się sporo nieporozumień i problemów. Dlatego dobrze jest określić zasady i formę współpracy adekwatną do planowanych prac oraz terminów realizacji przedsięwzięcia. Warto realnie określić przedmiot prac po obu stronach umowy, opracować odpowiednie procedury, tak aby wdrożenie przebiegało sprawnie i nie budziło wątpliwości. Jeżeli pracownicy wykonawcy mają mieć dostęp do infrastruktury czy też systemów wykonawcy warto to opisać oraz odpowiednio umocować.

Przy zakupie systemu „pudełkowego”, jak i podczas jego dostosowania, ale też, gdy system ma być „szyty na miarę” istotne jest przeanalizowanie licencji lub negocjowanie jej warunków. I tutaj dochodzimy do istotnej kwestii jaką jest formuła nabycia systemu projektowanego na potrzeby przedsiębiorstwa. Temat jest złożony i nie sposób, aby omówić go w tym momencie bardziej dokładnie, jednak zwrócę uwagę na pewne aspekty współpracy. Po pierwsze warto wziąć pod uwagę zlecenie wykonania analizy projektowej zewnętrznemu, niezależnemu doradcy lub zrobić to we własnym zakresie – o ile firma posiada takie możliwości.

Analiza wykonywana przez konkretnego dostawcę może być zrobiona nie pod potrzeby firmy i w jej najlepszym interesie, a w oparciu o możliwości dostawcy i jego wygodę oraz maksymalizację zysków. Warto zwrócić na ten aspekt uwagę, tak aby naprawdę autorskie rozwiązania, które firma przekazuje do implementacji zgodnie z wytycznymi były w odpowiedni sposób przeanalizowane. Po drugie, jeśli system tworzony jest na bazie doświadczenia, wiedzy i pomysłu powstałego w firmie, a do tego wpisuje się w specyficzną jej dzialalność i może stanowić o sile i konkurencyjności, to należy dobrze zastanowić się nad formą prawną związaną z prawami autorskimi.

Zapoznanie się z wachlarzem możliwości, jakie mogą wystąpić w konkretnych przypadkach zleconych i prowadzonych prac powinno pozwolić na racjonalne i korzystne decyzje w tym obszarze. Jeśli firma nie posiada doświadczenia w konstruowaniu umów czy w ogóle we wdrożeniach, to warto jest skorzystać z doradztwa zewnętrznego, choćby w postaci doświadczonego zespołu prawnego zajmującego się prawem autorskim i prawem nowych technologii oraz umowami w IT.

 

Problematyczna umowa serwisowa

Istotnym elementem wdrożenia jest przejrzysta umowa serwisowa zapewniająca odpowiedni poziom wsparcia oraz utrzymanie systemu.

Umowa serwisowa czy też umowa na utrzymanie dla wdrożonego już systemu informatycznego to w zasadzie konieczność. Nie tylko dlatego, że wsparcie systemu związane jest z wydawanymi przez producenta aktualizacjami czy też zapewnia opiekę i pomoc dla użytkowników, ale też ze względu na zabezpieczenie różnorodnych interesów przedsiębiorstwa np. zapewnienia ciągłości działania, zgodności ze zmieniającym się otoczeniem prawnym, możliwości eliminowania znalezionych błędów, reagowania na awarie czy też planowania i rozwoju funkcjonalności zgodnych z potrzebami i działaniami firmy.

Zdarza się, że nieścisłości w zapisach lub brak pewnych elementów w umowie, w przypadku wystąpienia problemu czy awarii, powodują niepotrzebne napięcia i zamęt, ale przede wszystkim mogą generować nieprzewidywalne koszty albo doprowadzić do sporu przed sądem, a to z kolei wprost zagraża realizacji ciagłości działania systemu, a niekiedy i przedsiębiorstwa. Często przedsiębiorca związany taką umową będzie podstawiony pod ścianą i niejako zmuszony przyjąć sposób rozwiązania problemu czy eliminacji awarii narzucony przez dostawcę.

W umowie serwisowej powinno być wyraźnie określone, które prace dostawca wykonuje w ramach oferowanej gwarancji, a które podlegają płatnemu serwisowi. Ważne jest wskazanie klasy i typów błędów – od błędów drobnych, które nie uniemożliwiają pracy w systemie, do błędów krytycznych, generujących poważne awarie czy powodujących przestój w pracy. Ustalając klasy błędów trzeba określić czasy reakcji serwisu na te błędy (im poważniejsza awaria, tym szybsza reakcja).

Istotny jest też czas gwarancji oraz ewentualne koszty aktualizacji systemu w przypadku wydania nowych wersji. Zrozumiałe i szczegółowe określenie rodzajów błędów pozwoli wyeliminować sytuacje sporne, w których trudno będzie przyporządkować zdarzenie do odpowiedniego poziomu błędu. Może wystąpić sytuacja, w której konkretne moduły czy funkcje systemu będą krytyczne dla funkcjonowania przedsiębiorstwa i w takiej sytuacji trzeba na ciągłość ich działania oraz wsparcie w zakresie ich obsługi położyć szczególny akcent.

Brak „otwartości” wprowadzanych rozwiązań

Uwzględnij możliwości rozbudowy i modernizacji systemu, dodawanie nowych modułów czy też funkcjonalności pozwoli na rozwój systemu razem z działalnością oraz ułatwi utrzymanie ładu technologicznego

Jeżeli wdrażany system ma uwzględniać perspektywę rozbudowy o nowe funkcjonalności, możliwość integracji z innymi systemami, aplikacjami, bazami danych powinien mieć zapewnioną tzw. otwartość tj. umożliwiać łatwe dokonywanie zmian i przystosowywanie do nowych uwarunkowań oraz wymagań. Otwartość systemu poszerza jego elastyczność oraz zdolności do rozwoju i utrzymania.

W przypadku rozwiązań „pudełkowych” dostawcy często oferują mnogość modułów oraz funkcjonalności, a na bazie posiadanych zasobów mogą także implementować kolejne rozwiązania i poszerzać dostępne opcje zgodnie ze zgłaszanymi potrzebami. Jednak w przypadku takich dostawców warto zwrócić uwagę na technologie, jakimi się posługują oraz na potencjałwykonawczy.

Istnieje oprogramowanie wykonane przed laty, co prawda aktualizowane i użytkowane w firmach, jednak powstający dług technologiczny powoduje, iż dostosowanie go do nowych wymogów czy wdrażanie innowacji może być utrudnione, kosztowane albo wręcz niemożliwe bez zmiany technologii.

 

Źle określone koszty całościowe systemu

Szacuj koszty uwzględniając różnorodne aspekty i czynniki, tak aby unikać eskalacji nieprzewidzianych wydatków lub problemów
z budżetowaniem, co może nieść ze sobą negatywne skutki dla jakości, a nawet powodzenia wdrożenia systemu.

Decyzja o wdrożeniu nowego systemu informatycznego jest zazwyczaj uzasadniana określonymi profitami, jakie ma przynieść skorzystanie z innego rozwiązania. Podobnie w przypadku informatyzacji przedsiębiorstwa, gdy przechodzi się z tradycyjnych sposobów pracy na elektroniczne lub cyfryzuje się kolejny obszar w firmie.

Oszacowanie kosztów wdrożenia systemu informatycznego powinno odnosić się do całości przedsięwzięcia oraz być zestawione z kosztami istniejących rozwiązań. Porównanie powinno zawierać wskazania wad i potencjalnie nadmiernych kosztów generowanych przez obecny system, koszty migracji środowiska do nowego systemu oraz określać ryzyko przedsięwzięcia.

Dokonanie analizy ekonomicznej jest istotnym elementem działania. Szacowanie rentowności może odbywać się z użyciem różnych metod np. ROI – zwrot z inwestycji, ROO – zwrot z wykorzystanej okazji czy TBO – całkowita korzyść z wdrożenia systemu albo TCO – całkowity koszt wdrożenia systemu. Złe oszacowanie kosztów może być wynikiem niedokładnego określenia zakresu wdrożenia podczas rozmów z dostawcą lub pominięcie niektórych obszarów podczas analizy.

Gdy koszty rosną może okazać się, że zabranie środków na dokończenie wdrożenia. Może też pojawić się pomysł, aby aneksami do umów z dostawcą ratować system i manewrować między tym, co zostało już zrobione, a tym co pozostało, szukając oszczędności lub rezygnując z jakichś opcji. Może doprowadzić to do wdrożenia słabego jakościowo, które nie spełni wymagań albo nawet do zaprzestania działań wdrożeniowych i porażki.

Trzeba pamiętać, że koszty wdrożenia systemu to nie tylko samo oprogramowanie oraz wyżej wspomniane elementy. Często należy uwzględnić także koszty sprzętu czy potencjalnie potrzebnych audytów, ale też koszty dodatkowych podsystemów, modułów, utrzymania oraz rozwoju systemu. Można przyjąć, że utrzymanie i wsparcie dla systemu może generować nawet do 50% kosztów w stosunku do kosztów wdrożenia. Jeśli koszty wstępne nie są wysokie może mieć to odzwierciedlenie w kosztach stałych obsługi. Warto przeliczyć jak wyglądać może zapotrzebowanie finansowe na pokrycie kosztów funkcjonowania systemu w przyszłości.