Wyobraźmy sobie sytuację, która wcale nie jest rzadka.
Organizacja kupuje nowoczesny system informatyczny za kilkaset tysięcy, a czasem nawet kilka milionów złotych. Wdrożenie trwa miesiącami. Są analizy, warsztaty, szkolenia, serwery, licencje i umowy serwisowe. Na końcu pojawia się niewielki element dostarczony przez inną firmę – na przykład skaner kodów kreskowych za 2 tysiące złotych.
System zostaje uruchomiony. Przez pewien czas wszystko działa poprawnie. Następnie pojawiają się problemy. Pracownicy zgłaszają błędy, procesy przestają działać, dokumenty nie są odczytywane prawidłowo albo dane nie trafiają do systemu.
Klient zgłasza problem głównemu dostawcy.
I wtedy rozpoczyna się dobrze znana gra w przerzucanie odpowiedzialności.
– To nie nasz system, to skaner.
– Skaner działa poprawnie, to problem integracji.
– Integracja jest prawidłowa, ale urządzenie wysyła błędne dane.
– Urządzenie działa zgodnie ze specyfikacją.
– Proszę kontaktować się z drugim dostawcą.
W efekcie organizacja, która zapłaciła ogromne pieniądze za wdrożenie, zostaje sama z problemem.
Problem współczesnych projektów IT
Dzisiejsze systemy informatyczne rzadko pochodzą od jednego producenta.
Typowy projekt składa się z:
- systemu głównego,
- serwerów,
- baz danych,
- urządzeń sieciowych,
- skanerów,
- drukarek etykiet,
- podpisów elektronicznych,
- usług chmurowych,
- integracji z systemami zewnętrznymi.
Każdy element może pochodzić od innej firmy.
Dla klienta nie ma to większego znaczenia. Organizacja kupuje rozwiązanie, które ma realizować określony proces biznesowy. Nie kupuje przecież osobno skanera, aplikacji i integracji. Kupuje działający system.
Tymczasem wielu dostawców bardzo chętnie bierze odpowiedzialność za sprzedaż projektu, ale znacznie mniej chętnie za jego późniejsze funkcjonowanie.
Rozmycie odpowiedzialności
Największym zagrożeniem nie jest awaria sprzętu.
Największym zagrożeniem jest brak jednoznacznej odpowiedzialności.
Jeżeli w projekcie uczestniczy pięciu dostawców, a żaden nie odpowiada za całość, klient może znaleźć się w sytuacji, w której każdy wskaże winnego gdzie indziej.
Powstaje wtedy klasyczne „rozmycie odpowiedzialności”.
Im więcej podwykonawców i partnerów technologicznych, tym większe ryzyko, że w razie problemów nikt nie będzie czuł się odpowiedzialny za ich rozwiązanie.
Dlaczego klienci wpadają w tę pułapkę?
Najczęściej dlatego, że podczas zakupu koncentrują się na funkcjonalnościach.
Pytają:
- Czy system potrafi to zrobić?
- Jakie ma moduły?
- Ile kosztuje?
- Jak długo trwa wdrożenie?
Znacznie rzadziej pytają:
- Kto odpowiada za całość?
- Kto będzie diagnozował problemy?
- Kto koordynuje współpracę podwykonawców?
- Kto ponosi odpowiedzialność za integracje?
- Kto jest właścicielem procesu obsługi zgłoszeń?
To właśnie te pytania często okazują się ważniejsze od listy funkcji.
Jak uniknąć problemu?
1. Jeden odpowiedzialny za całość
Najlepszym rozwiązaniem jest zasada:
„Jeden dostawca odpowiada za cały system.”
Nie oznacza to, że musi sam produkować każdy element.
Może korzystać z podwykonawców, partnerów czy producentów sprzętu.
Klient powinien jednak mieć jedno miejsce zgłaszania problemów i jedną firmę odpowiedzialną za ich rozwiązanie.
To dostawca powinien rozmawiać z producentem skanera, a nie klient.
2. Zapisy umowne
W umowie warto zawrzeć zapis, że dostawca odpowiada za poprawne działanie całego rozwiązania, również w zakresie dostarczonych przez niego integracji i rekomendowanego sprzętu.
Brak takich zapisów często prowadzi do wielomiesięcznych sporów.
3. Testy akceptacyjne
Przed odbiorem systemu należy przeprowadzić testy obejmujące cały proces biznesowy.
Nie należy testować oddzielnie:
- systemu,
- skanera,
- drukarki.
Należy sprawdzić cały proces od początku do końca.
To właśnie wtedy wychodzą problemy na styku różnych komponentów.
4. Dokumentacja architektury
Organizacja powinna wiedzieć:
- kto dostarczył poszczególne elementy,
- kto odpowiada za ich utrzymanie,
- jakie są zależności między systemami.
W wielu projektach wiedza ta istnieje wyłącznie w głowie wdrożeniowca.
To bardzo niebezpieczna sytuacja.
5. Unikanie uzależnienia od jednego wykonawcy
Paradoksalnie odpowiedzialność za całość nie oznacza całkowitego uzależnienia od dostawcy.
Klient powinien mieć:
- dostęp do swojej bazy danych,
- dokumentację integracji,
- prawa do własnych danych,
- możliwość przejęcia utrzymania przez inny podmiot.
Odpowiedzialność za system i uzależnienie od dostawcy to dwie różne rzeczy.
Skaner za 2 tysiące może zatrzymać system za milion
W praktyce bardzo często okazuje się, że problem nie wynika ani ze skanera, ani z systemu.
Problem pojawia się na styku obu rozwiązań.
Jeżeli jednak nikt nie odpowiada za ten obszar, klient zostaje pomiędzy dostawcami.
W efekcie organizacja, która wydała setki tysięcy złotych, prowadzi wielotygodniową korespondencję dotyczącą urządzenia wartego 2 tysiące.
Nie dlatego, że skaner jest tak ważny.
Dlatego, że zabrakło osoby lub firmy odpowiedzialnej za całość projektu.
Wnioski
Przy zakupie systemu informatycznego warto pamiętać, że największym ryzykiem nie jest awaria sprzętu, błąd programu czy problem z siecią.
Największym ryzykiem jest sytuacja, w której nie wiadomo, kto ma ten problem rozwiązać.
Klient nie powinien być arbitrem w sporze pomiędzy dostawcami technologii.
Powinien mieć jednego partnera, który bierze odpowiedzialność za działanie całego rozwiązania.
Bo ostatecznie organizacja nie kupuje skanera, serwera czy licencji.
Kupuje sprawnie działający proces biznesowy.