Sukces, czyli ryzyko - zagrożenia dla dostawcy w procesie wdrożenia

Wiele pisze się o metodologii wdrożeń. Wiedza na ten temat pomoże firmie, w której wdrażany jest system, zdefiniować procesy, wyszkoleni pracownicy mogą odbyć kursy, można także skorzystać z doświadczenia wynajętych konsultantów, dla których wdrożenie jest czynnością standardową, przećwiczoną wielokrotnie. W licznych publikacjach dużo miejsca poświęcono ryzyku związanemu z wdrożeniem. Mało kto zwraca uwagę na fakt, że wdrożenie może być również problemem dla producenta rozwiązania, czyli firmy informatycznej.

Wiele pisze się o metodologii wdrożeń. Wiedza na ten temat pomoże firmie, w której wdrażany jest system, zdefiniować procesy, wyszkoleni pracownicy mogą odbyć kursy, można także skorzystać z doświadczenia wynajętych konsultantów, dla których wdrożenie jest czynnością standardową, przećwiczoną wielokrotnie. W licznych publikacjach dużo miejsca poświęcono ryzyku związanemu z wdrożeniem. Mało kto zwraca uwagę na fakt, że wdrożenie może być również problemem dla producenta rozwiązania, czyli firmy informatycznej.

Wdrożenie jest ukoronowaniem pracy wielu zespołów informatycznych. Produkt, który tworzono często wiele miesięcy, a nawet lata, trafia do odbiorcy. Dla niego oznacza to dostawę rozwiązania, z którym wiąże duże nadzieje i które będzie pełniło zasadniczą rolę w jego biznesie. Pozwoli usprawnić funkcjonowanie firmy, poprawić kontrolę nad kluczowymi procesami, być może podwyższyć wydajność pracy i wskazać te obszary, które wpływają na efektywność.

Dla firmy informatycznej - producenta rozwiązania - nadejście komercyjnego sukcesu może być bardzo trudnym momentem. Jeżeli nie zmieni radykalnie swojej organizacji, może w krótkim czasie popaść w tarapaty.

Opisana historia jest autentyczna i miała miejsce na początku lat 90. Mała firma z niewielkiego miasta stworzyła prosty program do rejestracji korespondencji i rozmów telefonicznych. Sukces osiągnęła dzięki temu, że osoby, które tworzyły produkt, ściśle współpracowały z odbiorcami, doskonale rozumiejąc ich zadania i problemy. Produkt był tani, łatwy w obsłudze i stabilny, klienci więc zaczęli go masowo kupować. Firmie, przyzwyczajonej do ścisłej współpracy z odbiorcami, zależało na jak najlepszym obsłużeniu klientów. Pracownicy musieli dzielić swój czas między instalowanie produktu u nowych klientów, serwisowanie go u starych a pracę nad rozwijaniem oprogramowania. Efekt był taki, że żadnej z tych czynności nie wykonywali dobrze - ani nie poświęcali nowym klientom wystarczającej uwagi, ani nie odpowiadali na potrzeby dotychczasowych odbiorców. Najgorsze zaś, że całkowicie zaniedbali rozwój. Pojawienie się więc pierwszych aplikacji, wyposażonych w proste funkcje organizacyjne (np. Microsoft Works czy Lotus Organizer), podważyło podstawy ich bytu. Po roku od lawinowego wzrostu zamówień firma została praktycznie bez klientów.

Przykłady firm, które zgubił własny sukces, skłaniają do zastanowienia: co zawiodło, gdzie popełniono błąd, co sprawiło, że tak gwałtowny i obiecujący rozwój zakończył się klęską?

Za progiem laboratorium

Poprawne działanie każdej aplikacja tworzonej przez zespół informatyczny sprawdzane jest w warunkach laboratoryjnych. Nawet jeśli zasadniczy wysiłek wkłada się w testowanie, zawsze odbywa się ono w mniej lub bardziej fikcyjnych warunkach. Zespół, opracowując rozwiązanie, posiłkuje się wiedzą pochodzącą z analiz. Ich wyniki nie będą nigdy w stu procentach poprawne i kompletne, dlatego warunki budowy aplikacji będą się różniły od warunków działania. Chwila, gdy rozwiązanie przekracza próg owego laboratorium i trafia do klienta, to przełomowy moment dla pracy zespołu. Dotychczas skupiał się on na rozwoju produktu. Teraz będzie musiał dzielić czas między poprawianie produktu a dodawanie do niego nowych funkcji.

Od tego momentu zespół będzie funkcjonował w rozdarciu. Z jednej strony będzie zmuszony dbać o to, żeby jego klient był zadowolony - poprawiać ewidentne błędy w oprogramowaniu, bo oczywiście produkt musi pracować stabilnie. Z drugiej strony swój czas będzie poświęcał na usuwanie błędów powstałych podczas analizy, przez co oprogramowanie nie eliminuje problemów, które chciał rozwiązać klient. Zespół będzie także musiał zapewnić normalny rozwój produktu, tak aby spełniał on zmieniające się wymagania klientów.

Sytuacja taka może mieć, jak w opisanym na początku przykładzie, fatalne skutki zarówno dla zespołu, jak i produktu. Ścisła współpraca informatyków z odbiorcą, tak ważna podczas tworzenia produktu, może być kłopotliwa po wdrożeniu. Dlatego bardzo ważne jest, aby szef projektu wyczuł ten moment i stworzył mechanizmy, które wyeliminują bądź przynajmniej zminimalizują ryzyko związane z tą fazą.

Sprzeczność lojalności

Pierwsze przykazanie sprzedawcy brzmi: Klient nasz pan. Dlatego jeżeli klient zgłosi potrzebę zmiany bądź stworzenia pewnej funkcji, jego życzenie powinno być natychmiast spełnione.

Niestety, nie zdarza się, by zespół czekał na takie zgłoszenie z założonymi rękami. Zwykle wtedy, gdy ono się pojawia, informatycy zajęci są realizacją innych zadań. "Przełączenie" się w tej chwili na pracę nad innym projektem oznacza odłożenie w czasie realizacji poprzedniego. Tym samym oznacza to niedotrzymanie terminów, pogorszenie funkcji nowej wersji produktu albo niedostateczne testowanie (a tym samym pogorszenie stabilności). Wszystko to uderza w nowych klientów, a pośrednio nawet w tego, który zgłosił życzenie.

W istocie nie ma więc dylematu: Czy spełniać żądanie klienta powstałe w procesie wdrożenia, ale Czy opłaca się wspierać jednego klienta kosztem innych. Odpowiedź na to pytanie zależy od odpowiedzi na kilka szczegółowych pytań. Po pierwsze, czy w ogóle są i będą inni klienci, bo jeżeli nie, to dylematu nie ma. Po drugie, jakie są żądania klienta - błędy bowiem należy poprawiać natychmiast, zaś życzenia można spełniać po dokładnych uzgodnieniach i ustaleniu wysokości wynagrodzenia. Po trzecie, istotny jest fakt, czy spełnienie jednego życzenia nie wywoła lawiny następnych, co skutecznie zdezorganizowałoby pracę.

W każdym przypadku o fakcie realizacji danego zadania, powinien decydować kierownik projektu, który zna wszystkie uwarunkowania biznesowe i techniczne, związane z produktem. W szczególności o tym także nie powinni decydować ani handlowcy (bo dla tych, jak wiadomo, wszystko jest możliwe), ani informatycy (bo ci najczęściej są bardzo pomocni, ale nie zawsze rozumieją wpływ decyzji technicznych na organizację procesu).

Rozważmy konkretny przypadek: do firmy informatycznej dzwoni producent lodówek, która kupiła aplikację do zarządzania naprawami gwarancyjnymi, i żąda, aby program pozwalał także monitorować i rozliczać koszty dojazdu do zgłaszającego usterkę. Kierownik zespołu może w tej chwili podjąć jedną z trzech decyzji. Zapewnić, że wykona tę funkcję w podanym terminie i za podaną sumę, po czym uzgodnić z informatykami zakres i harmonogram koniecznych prac. Może odmówić, twierdząc, że nie należy to do planów rozwoju produktu, i proponując w zamian aplikację logistyczną stworzoną przez zaprzyjaźnioną firmę. Najlepsze jednak co może zrobić to wpisać żądanie klienta na "listę życzeń", a potem co pewien czas ją analizować, następnie wybrać najczęściej powtarzające się życzenia i na ich podstawie określić plan pracy zespołu na najbliższe miesiące. W ten sposób kierownik zespołu osiągnie trzy cele: wytworzy w klientach przekonanie, że ich uwagi są uwzględniane, nie zdezorganizuje bieżących prac zespołu, a także uniknie jednostkowych modyfikacji.

Pamiętajmy, że takiego trybu postępowania raczej nie stosuje się w przypadku, gdy wdrożenie ma miejsce u pierwszego klienta. Ten spełnia bowiem szczególną rolę - jest nie tylko adresatem pierwszej faktury, ale przede wszystkim źródłem wiedzy. Gdy system opuszcza sterylne laboratorium dostawcy, jakim jest dział rozwoju, dopiero wtedy podlega solidnej weryfikacji. Pierwszy klient powinien być traktowany szczególnie, choćby ze względu na to, że ta wiedza, której dostarcza, jest warta dużo więcej niż zapłata za produkt. Niewątpliwie więc pierwszy klient będzie mógł pozwolić sobie na znacznie więcej niż następni.

Na schizofrenię - elastyczność

Najgorsze, co może zrobić zespół informatyczny, to popaść w swoistą "schizofrenię produktową". Jeżeli rozwijany jest jeden produkt, to nie można dopuścić do rozdzielenia go na wiele produktów. Dzieje się tak wtedy, gdy menedżer zgodzi się, aby dodać funkcję szczególną dla jednego klienta. Na przykład, gdy firma posiadająca sieć Novella chce, aby zalogowanie się do sieci było równoznaczne z autoryzacją w systemie finansowo-księgowym (który normalnie posiada osobny system autoryzacji). Stworzenie specyficznej wersji dla jednego klienta oznacza, że trzeba wspierać dwa (a może nawet więcej!) produkty, zamiast jednego. Komplikuje to kwestie związane z programowaniem, testowaniem, dokumentowaniem i wsparciem technicznym.

Wewnętrzny koszt rozdzielenia produktu na kilka wersji jest bardzo wysoki i należy mieć tego pełną świadomość. Z doświadczeń wynika, że najwięcej czasu pochłaniają najbardziej banalne czynności - przeinstalowanie programu, uaktualnienie środowiska, czytanie dokumentacji, spotkania mające na celu uzgodnienie funkcjonalności i harmonogramu, kompilację, generowanie wersji instalacyjnej itd. Warto zauważyć, że żadna z tych czynności nie ma charakteru merytorycznego - bo przecież czekanie na wynik kompilacji ani nie podnosi wiedzy informatyka, ani nie przynosi korzyści klientowi.

Współczesne technologie, takie jak CORBA czy COM, pozwalają i wydzielić ogólnie dostępną część interfejsu aplikacji, i dostarczać komponenty zewnętrznym dostawcom (innym firmom, innym zespołom albo nawet klientowi, jeśli ten orientuje się w kwestiach technicznych). Jeżeli więc dodanie do produktu specyficznych funkcji jest konieczne, można skorzystać z możliwości wydzielenia zadanej funkcji do zewnętrznego komponentu. Zamiast więc popadać w "schizofrenię produktową", lepiej aplikację po prostu uelastycznić - w ten sposób zadośćuczynimy zarówno wymaganiom klienta, jak i wewnętrznym wymogom organizacyjnym.

Pierwsze, drugie, piąte

Warto wiedzieć, że każde kolejne wdrożenie ma zupełnie inne znaczenie dla zmian organizacyjnych wewnątrz firmy informatycznej. Pierwsze wdrożenie jest zasadniczo testem jakości produktu. W trakcie jego realizacji ujawniają się zarówno błędy techniczne, jak i niedociągnięcia organizacyjne wewnątrz firmy. Zwykle ich usunięcie wymaga sporego wysiłku i dużej wyobraźni. Tutaj potrzeba inteligentnego, szybkiego działania i - powiedzmy to otwarcie - ogromnego wysiłku. Podczas drugiego, trzeciego wdrożenia testowana jest elastyczność produktu. Okazuje się, że następni klienci mają nieco inne wymagania i kluczowym zagadnieniem jest zachowanie równowagi między dopasowaniem produktu do potrzeb każdego klienta z osobna i jednocześnie utrzymaniem jednej ścieżki rozwoju produktu. Jeżeli menedżer nieprawidłowo określi tę równowagę, będzie miał kilka produktów zamiast jednego. W tej fazie menedżer musi przede wszystkim doskonale znać produkt i zagadnienia analityczne. Wreszcie pojawia się problem skali. Przy piątym, dziesiątym wdrożeniu informacje "co u kogo" nie mogą być tylko w pamięci pracowników firmy, a muszą powstać procedury zarządzania taką wiedzą. Tutaj najlepiej sprawdza się sprawny administrator, który zna się na zagadnieniach zarządzania. Na szczęście po zdobyciu dziesiątego klienta na ogół są już pieniądze na większe inwestycje związane z nowymi stanowiskami i informatycznym wspomaganiem zarządzania informacją.

Kultura współpracy, kultura żądania

Na początku lat 90. w Polsce dominował "amerykański" model biznesu informatycznego, który można by określić w dwóch słowach: "Radźcie sobie". Radzić sobie musiał odbiorca, bo wdrożenie systemu było aktem jednorazowym, a "po odejściu od kasy reklamacji nie uwzględniało się". Firmy stawiały nie tyle na długofalową współpracę, ile na krótkoterminowe korzyści. Niestety, kij ten miał dwa końce, bo odbiorca - zirytowany niespełnianiem jego potrzeb - mógł zaprzestać współpracy albo nie zapłacić kolejnej faktury. Można by taki model biznesu porównać do nieustannych przepychanek między klientem, mającym pieniądze i potrzeby, a dostawcą, mającym oprogramowanie i chcącym sprzedać jeszcze jedną licencję.

Dziś, gdy przedsiębiorstwa dojrzały i stały się zamożniejsze, dominuje inny model. Wdrożenie jest procesem, w którym obie strony starają się współpracować w celu osiągnięcia jak najlepszego efektu. Konsekwencje tej zmiany dla zespołu informatycznego są bardzo poważne. Przede wszystkim informatycy muszą coraz lepiej rozumieć uwarunkowania ekonomiczne, w których działa przedsiębiorstwo ich klienta. To dlatego mówi się, że informatyka jest dziedziną interdyscyplinarną. Aby opracować dobry system obsługujący pracę agentów ubezpieczeniowych, trzeba dysponować prawie taką wiedzą, jaką ma agent ubezpieczeniowy (oprócz wiedzy technicznej!). Toteż mają mniej czasu na prace czysto informatyczne. I dlatego tym istotniejsze jest, aby ich czas szanować i optymalnie go wykorzystywać. Kultura współpracy z jednej strony jest więc korzystniejsza dla wszystkich stron, z drugiej zaś - wymaga większego zaangażowania informatyków w prace wdrożeniowe. Może więc bardzo osłabić zespół informatyczny. Paradoksalnie więc, kultura współpracy - choć lepsza z biznesowego punktu widzenia - jest zmorą zespołów informatycznych. Do tego stopnia, że w Internecie można znaleźć dowcipy o namolnych klientach, choć zdroworozsądkowe podejście wymagałoby więcej szacunku dla tych, którzy w ogólnym rozrachunku są pracodawcami informatyków.

Trzeba jednak uczciwie stwierdzić, że informatycy nie mają prawie żadnego wpływu na to, czy w kontaktach z klientem dominuje kultura współpracy czy kultura żądania. Po prostu rzadko uczestniczą w procesie decyzyjnym. To nie oni nadają ton rozmowom z odbiorcą i to nie ich słowo decyduje o sformułowaniach w kontrakcie. Muszą więc poniekąd wypić piwo nawarzone przez kogoś innego i jedyną pociechą może być fakt, że coraz więcej firm zdaje sobie z sprawę z wad tego podejścia i włącza informatyków także w proces decyzyjny.

Szanujmy się

Od informatyków wymaga się coraz więcej. Muszą rozumieć technologię, biznes, muszą być też doskonali w kontaktach interpersonalnych. Uważnie słuchając swoich klientów, okazują im szacunek, ale nie zasłużą sobie na ich szacunek, jeżeli nie będą siebie szanować. Wdrożenie jest znakomitą okazją, aby zadbać o to, żeby odbiorca szanował także swojego dostawcę. W długofalowej perspektywie wszyscy na tym zyskają.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200