70% wewnętrznych projektów IT kończy się tragicznie. Dlaczego warto je outsource’ować?

Jest szósta wieczorem. Właśnie wróciłem ze spotkania biznesowego, na którym miałem okazję porozmawiać z osobami z branży, a także wymienić się uwagami z potencjalnymi klientami. Znacie takie spotkania?

fot. unsplash.com

Siedzi w jednej sali kilkunastu facetów, każdy z nich w branży od wielu lat, każdy specjalista w swojej dziedzinie. To właśnie w takich miejscach można złapać najlepsze kontakty, posłuchać wyjątkowych historii i dowiedzieć się nieco o rynku. Tak było i tym razem, jednak opowieść, której wysłuchałem, pokazała mi, jak jeszcze mało wiem o tej branży.

Polowanie na antylopy

Spotkania, a dokładniej konferencje biznesowe, mają to do siebie, że czasami najciekawsze nie są prelekcje, a rozmowy przy kawie. Oczywiście pierwsza kawa to badanie terenu. Każdy z nas jest wtedy lwem, który chce przydybać jakąś antylopę, dobić się do najciekawszych mówców i zadać im pytania. Staliśmy więc w holu hotelu, ściskaliśmy w rękach filiżanki i szukaliśmy grup, do których warto się przyłączyć. W pewnej chwili zauważyłem mężczyznę, który, tak jak ja, czekał i obserwował. Nie myśląc dłużej, podszedłem i podałem mu rękę. Po szybkiej wymianie uprzejmości okazało się, że rozmawiam z Robertem, menadżerem wyższego szczebla pewnej brytyjskiej firmy. Nie podaję jej nazwy, bo w tej chwili to najmniej ważne. Ważniejsze jest to, o czym zaczęliśmy rozmawiać. Mowa była o outsourcingu projektów oraz o tym, że kilka nieudanych wdrożeń „in the house” zmusiło zarząd do zmiany sposobu myślenia. Podczas ostatniej przerwy, tym razem obiadowej, Robert opowiedział mi całą historię.

Historia pewnego projektu

Robert pracuje w firmie sprzedającej wyposażenie domów i ogrodów. Wiecie: szwarc, mydło i powidło – od plastikowych kaktusów, do betonowych lwów, które nowobogaccy właściciele podmiejskich domostw stawiają przed drzwiami, bo wydaje im się, że są współczesnymi Cezarami. Firma od dłuższego czasu miała dwa problemy: pierwszym był brak dobrej komunikacji wewnętrznej, drugim – niesamowicie przestarzałe oprogramowanie, które można nazwać CRM. Ponieważ w zespole znajdował się mały dział IT (w tym 2 biegłych programistów), postanowiono na ich barki zrzucić poprawienie starego, pisanego wiele lat temu oprogramowania, połączyć je z systemem sprzedażowym, magazynowym, księgowym, logistycznym. Po prostu taki kombajn do wszystkiego. Na wszystko zarezerwowano w budżecie dodatkowe środki i ustalono pierwsze spotkanie zespołu roboczego. Miało się odbyć kilka dni później.

Małe trzęsienia ziemi

Nim Robert przeszedł do dalszej części swojej opowieści, zrobił małe wprowadzenie. Firma, w której pracuje, zatrudnia około 50 osób. Wydawałoby się, że przy tak niewielkiej liczbie pracowników przepływ informacji oraz realizacja wewnętrznych projektów będą wyjątkowo proste. Niestety, jak w wielu zespołach, działy marketingu i sprzedaży nie zawsze się dogadywały. Jeśli chodzi o nowy projekt e-commerce, tutaj mocno naciskano na Magento, ale ostatecznie zdecydowano się na inne rozwiązanie opensource. Do tego momentu wszystko wyglądało ok, problemy zaczęły się jednak na pierwszym spotkaniu z programistami oraz pracownikami, którzy będą korzystać z CRM.

Spotkanie ustalono na poniedziałek – zaraz po lunchu – tak, aby każdy miał już za sobą kawę, obiad i ogarnął część własnych obowiązków. Nikt wtedy nie myślał o tym, że druga połowa dnia zostanie spędzona na bezproduktywnym spotkaniu firmowym, które nie wniosło do projektu kompletnie nic. Dlaczego? W meetingu brało udział 25 osób, czyli połowa pracowników. Pracowników, którzy przez resztę dnia nie zrobili swoich zadań. Jeśli policzymy, że każdy z nich średnio zarabia po 25 funtów za godzinę, a spotkanie trwało 5 godzin, to prosto dojść do tego, że zapłacono im ponad 3000 funtów za siedzenie i wzajemne przerzucanie się pomysłami. Oczywiście, to wyliczenie jest dużym uproszczeniem, ale chodzi o pokazanie skali. Takich spotkań na pierwszym etapie było jeszcze kilka, a tak naprawdę doprowadziły one tylko do kilku bardzo podstawowych założeń.

fot. unsplash.com

Założenia nowego CRM, które powstały po 5 godzinach spotkania:

prosta obsługa,
połączenie ze skanerem, by automatycznie dodawać skany faktur,
różne poziomy dostępów,
historia działań i zmian,
ładny, czytelny interfejs,
segmentacja leadów,
dopisywanie kredytu kupieckiego do klienta,
integracja z księgowością i magazynem,
implementacja xml,
dodawanie zadań, ustalanie priorytetów, czyli taki task manager.

Oczywiście, to te najważniejsze, które wpadły do głowy podczas wymiany pomysłów. Poza nimi pojawiła się lista innych, zawierająca około 50 pozycji. Na tym etapie oczywiście dział IT już opowiadał o tym, jak zamierza zrobić poszczególne elementy, a wiedza ta zupełnie nie była potrzebna pracownikom marketingu, czy nawet zarządowi.

Nic nie wskazywało, że projekt będzie porażką

Po 10 dniach ktoś wpadł na pomysł, aby już nie zbierać pomysłów i spotkać się jedynie z zespołem programistów. Tym razem wszystko poszło o wiele sprawniej, ale tutaj zaczęły pojawiać się kolejne problemy. Przede wszystkim zespół musiał być podzielony pomiędzy projekt e-commerce i CRM. „Na tym etapie dopiero oświeciło kogoś, że CRM i tak będzie trzeba połączyć z nowym sklepem. Co więcej, potwierdziliśmy, że zmodyfikujemy istniejący CRM, bo tak będzie szybciej i taniej. Zarząd przystał na to rozwiązanie. Ustalono termin wdrożeń i zaczęliśmy pracę”- wyjaśniał Robert.

fot. unsplash.com

Mój rozmówca na chwilę zamilkł i wyciągnął laptopa z położonej na krześle obok torby. Minęło kilka chwil i popatrzył znad klawiatury. Obrócił komputer ekranem do mnie, ukazując mi szereg statystyk. Zebrał je jakiś czas po tym, jak wdrożenie poszło tak źle, że zaczął obawiać się o swoje stanowisko. Sam zarządzał do tej pory działem sprzedaży, nigdy nie nadzorował pracy programistów, nie wiedział, czego od nich wymagać i jakie są realne punkty milowe takich prac. Na ekranie między innymi widniały badania McKinsey & Company, pokazujące, że 17% projektów IT idzie tak źle, że zagraża to istnieniu firmy, 70% projektów nie zostaje zrealizowanych w ogóle, a tylko 2,5% wszystkich projektów zrealizowanych jest w 100%, to akurat badanie Gallup. To tylko kilka ze statystyk, które pokazał Robert.

Co poszło nie tak?

Przede wszystkim błędem było rozproszenie pracowników pomiędzy dwa projekty (CRM i e-commerce) i praca ze starym silnikiem CRM. Przez kilka dni nikt nie wiedział, kto przygotował wcześniejszy kod, gdzie była dokumentacja, a osoba, która odpowiadała za tamto wdrożenie, już dawno nie była pracownikiem firmy. Poza tym nie było nikogo, komu można byłoby powierzyć koordynację pracy programistów. Dlatego Robert dostał to zadanie jako dodatkowy obowiązek, co doprowadziło do sytuacji, w której jego praca zaczęła być zaniedbywana. Nikt nie kontrolował samego wdrożenia. Nowy CRM zaczął być potworkiem, hybrydą starego i nowego, która raz działa dobrze, a raz zalicza niespodziewane „crashe”. Wielokrotnie zdarzały się sytuacje, w których dział handlowy nie mógł zrealizować zamówienia, bo znów coś nie działało. W tym samym czasie projekt e-commerce też nie był realizowany, nikt z programistów nie był bowiem grafikiem, a trzeba było pociąć grafikę e-sklepu, więc firma zaczęła szukać kogoś, kto może to zrobić. Tak minęło około 11 tygodni, które nie posunęły prac za bardzo do przodu. Wreszcie Robert poszedł do zarządu i zaproponował outsourcing projektu.

Przygotowany na najgorsze

Do tej pory firma nie wydała za dużej części zarezerwowanego budżetu, praca była bowiem wykonywana wewnętrznie, ale cały czas pojawiały się straty, które spowodowane były obecnym projektem. Szukając rozwiązań, Robert postanowił przejrzeć oferty software house’ów. Stwierdził, że outsourcing, przed którym tak bronił się zarząd, może być najlepszym rozwiązaniem. Zaopatrzył się w mały brief, który pokazywał na przykładach, a co najważniejsze, na liczbach, korzyści płynące z delegowania zadań na zewnątrz. Najważniejsza była informacja, że 27% firm zleca na zewnątrz procesy, aby ciąć koszty firmowe, gdyż dzięki tej metodzie można zaoszczędzić nawet 60% założonych kosztów. 57% firm deklaruje, że dzięki temu może skupić się na głównej działalności przedsiębiorstwa, przez co unika strat. Rozmowa z zarządem była burzliwa, ale z racji tego, że jeszcze nie ruszono założonego budżetu, Robert otrzymał zezwolenie na działanie.

fot. unsplash.com

Wsparcie ekspertów

Analiza rynku pozwoliła na szybką weryfikację ofert. Odbyły się pierwsze rozmowy, a także spotkania. Ostatecznie zdecydowano się na wybór programistów z Polski, między innymi dlatego, że mieli oni świetną opinię, a poza tym byli dużo tańsi niż ich zagraniczni koledzy. Na początku gdzieś w głowie Roberta pojawiła się obawa o to, jak poradzą sobie oni z komunikacją, jak będzie wyglądało wdrożenie itd. Bał się między innymi, że nie będzie miał kontroli nad zadaniem, kiedy nikt z zewnętrznego zespołu nie będzie pracował w biurze. Szybko jednak rozwiano jego wątpliwości.

Kilka dni później w biurze Roberta pojawili się dwaj pracownicy wybranego w trakcie analizy ofert software house’u. Spędzili razem 7 godzin, podczas których przeanalizowali oni potrzeby Roberta i jego pracowników, zapoznali się z obecną strukturą panującą w firmie, a co najważniejsze, zobaczyli z bliska, jak wyglądają poszczególne procesy i komunikacja pomiędzy działami. Były jeszcze trzy takie spotkania, tylko że różniły się bardzo od wspomnianych burz mózgów. W tym przypadku przeprowadzono krótkie wywiady z pracownikami oraz dano im do wypełnienia ankiety, które pomogły wyselekcjonować najważniejsze potrzeby i problemy. Te dwie osoby w kilkanaście godzin zebrały więcej informacji potrzebnych do wdrożenia niż cały zespół w firmie Roberta przez kilka dni. Spowodowane to było przede wszystkim tym, że deweloperzy zewnętrzni pracowali według metodologii, która ułatwiała im pracę i pomagała przewidzieć, jakie zdarzenia mogą wystąpić na każdym etapie współpracy. Dla Roberta i jego pracowników Agile, Waterfall, czy też MoScoW to były tylko słowa, dla koderów – mapa podróży.

Szybko zweryfikowano główne potrzeby, które pojawiły się podczas burzy mózgów. Zdecydowano, że wewnętrzny dział IT wesprze programistów z zewnątrz, co dodatkowo sprawi, że będą oni mogli zwiększyć swoją wiedzę. Wydelegowano obowiązki, ale co najważniejsze, ustalono trzy główne elementy, które wcześniej były jedynie zarysowane: budżet, plan działania wraz z datami oraz pełną specyfikację. Dodatkowo do projektu przydzielony został projekt menadżer z firmy deweloperskiej, który zdjął z barków Roberta ciążące na nim obowiązki, dzięki czemu mógł się on skupić na pracy swoich podwładnych. Osoba ta zarządzała pracą łącznie 7 osób, z czego trzy były pracownikami przydzielonymi z firmy Roberta. Aby uniknąć jednego z najważniejszych problemów wdrażania projektów, czyli szumów komunikacyjnych, o których mówi 57% ankietowanych projekt managerów, zastosowano narzędzie online do zarządzania projektami, w którym znajdowały się wszystkie informacje, uwagi oraz zmiany. Każda odpowiedzialna za pracę osoba miała dostęp do potrzebnych danych, widać też było, jak idą prace. Raportowanie ustalono na 7-dniowe okresy, dzięki temu jedna strona mogła spokojnie pracować, a druga wiedziała, że w każdy poniedziałek otrzyma zestawienie wykonanych prac i informację o tym, jak daleko do zamknięcia projektu.

Może to nie bajka, ale…

Wdrożenie się udało. Robert zauważył, że podczas współpracy dwa lub trzy razy nastąpiły drobne zgrzyty, które wyniknęły z niedopowiedzeń, ale ostatecznie udało się zakończyć współpracę. Przebudowano cały CRM, połączono go z e-sklepem. Usprawniono kilka procesów. On sam, zakochany w metodologii LEAN, wprowadził kilka zmian do obiegu dokumentów oraz akceptacji kart sprzedażowych, dzięki czemu średnio zaoszczędzono kilka godzin pracy miesięcznie. W ostateczności całość przedłużyła się o 4 tygodnie z racji dodatkowych implementacji, o których nie było mowy na początku. Nawet z tymi dodatkowymi pracami projekt zakończono z wydatkami o 30% niższymi niż planowano.

fot. unsplash.com

Nauczka na przyszłość

Na koniec swojej opowieści Robert zamknął laptopa i sięgnął po filiżankę z kawą. Ciekaw byłem jego opinii na temat współpracy z software housem. Zastanawiałem się, czy jeśli kiedyś będzie potrzebował pomocy, to zdecyduje się na ten sam krok. Odpowiedź była jedna. Stwierdził, że największym problemem była wiara, że jego mały dział IT poradzi sobie z dwoma dużymi wdrożeniami. Software house ma swoją grupę deweloperów, specjalistów od różnych języków, grafików i ekspertów, którzy mogą zrobić wszystko. Tam nawet jedna osoba jest wstanie poprowadzić projekt samodzielnie i znajdzie rozwiązanie, na przedstawione przed nią problemy. Są osobami wszechstronnymi, które potrafią działaś w zespole, jak i pojedynczo. Dodatkowo to oni sami koordynują pracę swojego teamu, zależy im na jak najszybszym oddaniu zlecenia, kodu najwyższej jakości, bo w tej branży wieści rozchodzą się szybko. Metodologia ich pracy, wewnętrzna dyscyplina oraz to, że skupiają się na jednym projekcie, bez zbędnego rozpraszania, sprawiają, że działają oni sprawniej, szybciej, a co najważniejsze taniej niż niektóre wewnętrzne zespoły. No i jeszcze jedna sprawa – modele pracy: body leasing, team leasing, a także całkowity outsourcing projektu sprawiają, że dopasowane one są do wymagań każdego klienta. Nie ma znaczenia czy pracujemy z zespołem 5 czy 50 osobowym, za tę grupę specjalistów przemawia ich sposób myślenia i analizowania. Dodatkowo jest jeszcze jedna rzecz. Polscy programiści należą do czołówki światowych ekspertów i pracowników. Inna kultura pracy, a także wspomniana wiedza sprawiają, że nie ma dla nich rzeczy nie do zrobienia. Dla jego firmy to była cenna lekcja.

Tak zakończyło się nasze spotkanie, wysłuchałem jego historii z dużym zaciekawieniem. Okazuje się, że nadal wiele firm nie do końca wie, jak działają i czym zajmują się software house’y, że pomoc zewnętrznych developerów jest dużo tańsza niż zatrudnianie własnych specjalistów do jednego projektu. Co najważniejsze: klient zawsze otrzymuje pełne wsparcie od teamu deweloperów i nie zostaje on pozostawiony samemu sobie. Często wraz z oddaniem wdrożenia otrzymuje on jeszcze kilku- lub kilkunastomiesięczny support.

Posiedzieliśmy jeszcze chwilę z Robertem, wymieniliśmy się wizytówkami i na koniec podaliśmy sobie ręce. Może kiedyś jeszcze spotkamy się na jakiejś konferencji biznesowej, a może jako partnerzy przy kolejnym wdrożeniu.

–

Adam Trojańczyk, członek zarządu i COO w software house’ie Inwedo.

Posiada czternaście lat doświadczenia w branży IT. Pracował z firmami z różnych zakątków świata. Od strefy ekonomicznej w Meksyku, firm w USA, poprzez dziesiątki firm z Europy, największe agencje interaktywne w Polsce, aż po firmy z Japonii i Australii. Przez ten czas zarządzał swoim software housem oraz współtworzył i angażował się w rozwój wielu startupów. Był mentorem i ekspertem w programach akceleracyjnych. Po godzinach pisze artykuły na swoim blogu https://trojanczyk.pl.