Strona główna > O firmie, publikacje naszych specjalistów > Nowy system informatyczny. Piszemy czy kupujemy?
Nowy system informatyczny. Piszemy czy kupujemy?
Marek Wierzbicki
Artykuł opublikowany oryginalnie w: Computerworld 3/2007
W każdej firmie czy organizacji, która chce się rozwijać prędzej czy później może pojawić się zapotrzebowanie na nowy system informatyczny (magazynowy czyli WMS, ERP, BI lub OLAP, CRM bądź inny). Bez względu na to, czy potrzeba systemu narastała latami, była wynikiem zmiany logiki procesu biznesowego czy pojawienia się nowego zarządu, analiza wdrożenia tego przyszłego systemu może dotknąć kwestii kto ma napisać ten system. I nie chodzi o wybór konkretnej firmy, ale o decyzję, często wyłącznie polityczną, czyli czy system ma dostarczyć zewnętrzny dostawca, czy własne zasoby informatyczne. Pokusa samodzielnego tworzenia jest tym silniejsza, im większy i bardziej doświadczony zespół informatyków wspiera dotychczasowe działanie firmy w tym zakresie. Decyzja nie jest łatwa, stąd moje rozważania, które państwu przedstawiam.
Mimo dużej popularności usług typu outsourcing oraz dużej liczbie dostawców oprogramowania, wciąż istnieją firmy nieinformatyczne, które posiadają duże bądź olbrzymie działy informatyki i większość prac w tej dziedzinie wykonują we własnym zakresie. Często w takich firmach używane oprogramowanie stale ewoluuje i to właśnie tam, w chwili pojawienia się zapotrzebowania na nowy system rodzi się pokusa stworzenia go we własnym zakresie. Czy warto? Spróbuję wyważyć wady i zalety tej kwestii.
Zalety samodzielnego tworzenia oprogramowania
Wyobraźmy sobie spotkanie zarządu (w praktyce opisane decyzje nie powstają na jednym spotkaniu, lecz rodzą się dłuższy czas, jednak na potrzeby tego artykułu możemy przyjąć takie właśnie założenie), który cieszy się z rosnących obrotów swojej firmy, ale martwi, że dotychczasowa lokalizacja nie jest w stanie wytrzymać tego wzrostu. Należy rozbudować hale produkcyjne, korzystając z okazji zmienić coś w organizacji pracy i wdrożyć nowy system informatyczny (zarówno dlatego, że stary był niewydajny, jak i dlatego, że należy go dostosować do nowych warunków). Zdarza się, że w takim momencie dyrektor bądź prezes odpowiedzialny za nowe technologie, w tym informatykę, z dumą oświadczy, że jego chłopcy na pewno sobie z tym poradzą, a system będzie znacznie tańszy od kupionego i idealnie dopasowany do potrzeb przedsiębiorstwa. Oczywiście praca może być rozpoczęta natychmiast, zaraz po sformułowaniu podstawowych założeń, a ewentualne przyszłe poprawki i rozszerzenia też będą wykonywane od ręki (a nie tak jak przez dotychczasowego dostawcę nie wiadomo kiedy i za jakie pieniądze).
W praktyce system tworzony we własnym zakresie będzie tworzony na zasadzie zbliżonej do tak zwanych zwinnych metodyk, czyli przyszli użytkownicy będą mogli oceniać postępy prac i nawet we wstępnej ich fazie decydować, które funkcjonalności należy rozszerzyć, a które można zaniedbać. Dzięki takiemu podejściu bardzo często najpierw mogą powstać najważniejsze i najczęściej używane moduły. Bardzo łatwo będzie też ujawnić te rejony, które w ogóle nie będą używane i można zrezygnować z ich pisania. Podobnie będzie z przyszłymi poprawkami, które będzie można wdrażać na bieżąco niewielkim kosztem czasowym i finansowym. Ponadto poprawki można będzie wykonywać w małych krokach, co powinno zapewnić stabilność całego systemy, a zwłaszcza niemodyfikowanych modułów.
Wady tworzenia systemu we własnym zakresie
Niestety a może na szczęście na każdym zebraniu zawsze znajdzie się jakaś czarna owca, która nie podziela entuzjazmu prezesa od nowych technologii. Najczęściej bywa to dyrektor któregoś z działów firmy, traktowanego dotychczas najbardziej po macoszemu przez IT, który najdotkliwiej odczuwa niedociągnięcia wcześniejszej twórczości informatyków. Czasami jest on wspierany przez kierownika niższego szczebla z pionu IT, który zdaje sobie sprawę z ogromu projektu w porównaniu do sił którymi dysponuje. Ta czarna owca wysypie jak z rękawa wszystkie wady pomysłu tworzenia oprogramowania we własnym zakresie, zaczynając od konieczności wyważania drzwi, wielokrotnie już otwartych przez innych.
Problem wyważania otwartych drzwi istnieje przy tym na dwóch płaszczyznach. Z jednej strony chodzi o kwestie techniczne związane z architekturą systemu (np. jak w systemie wielodostępnym rezerwować kolejne numery dokumentów tak, żeby nie powstawały dziury w ich numeracji, mimo możliwości wycofania dokumentu w trakcie trwania transakcji). Z drugiej strony zachodzi konieczność oprogramowania na przykład procesu obsługi magazynu wysokiego składowania, co zostało już zrealizowane przez kilkaset firm i zoptymalizowane na podstawie uwag wielu użytkowników.
Poza tym pisanie samodzielne może spowodować powstanie tak zwanego zinformatyzowanego bałaganu. Jeśli nowy system ma wspierać pracę na dotychczasowych stanowiskach naturalne jest to, że pracownicy oczekują że system będzie funkcjonował zgodnie z aktualnymi procesami. Często procesy te były optymalizowane przez długi okres czasu pod kątem pracy bez systemu lub z innym systemem informatycznym. Jeśli nie zostaną zmienione tak, by uwzględniały nowe hipotetyczne właściwości nowego systemu, wtedy jego wdrożenie może zaprzepaścić możliwość uporządkowania i zoptymalizowania danego procesu. Zamiast tego utrwalone zostaną niekoniecznie efektywne schematy pracy.
Innym problemem związanym z tworzeniem nowego systemu samodzielnie jest możliwość zaniedbania tworzenia dokumentacji. Na etapie projektu, na skutek sukcesywnego pojawiania się założeń często są one informatykom przekazywane ustnie w bardzo małych porcjach. Sprzyja temu wysoka wiedza biznesowa informatyków wynikająca często z wieloletniego doświadczenia w tej firmie. Wszyscy wszystko rozumieją, więc zapisywanie na bieżąco założeń i funkcjonalności systemu wydaje się niecelowe. Dodatkowo wszyscy zdają sobie sprawę, ze zbyt szybko zbliżającego się terminu wdrożenia, więc dokumentacja poprojektowa też nie jest tworzona. I cała wiedza jak zwykle pozostaje w głowach programistów, którzy tym samym stają się trudno zastępowalnym elementem systemu. Często na skutek stosowania adaptacyjnych technik tworzenia programu już po jego uruchomieniu ciągle trzeba robić poprawki, tak że gdy system staje się w miarę kompletny nikt już nie pamięta jego założeń, więc tym bardziej nie można ich spisać.
Zalety zakupu gotowego produktu
Prawie zawsze na opisywanym zebraniu znajdzie się jednak ktoś z otwartą głową, którego zainteresuje jakie byłyby zalety zlecenia wykonania systemu informatycznego przez doświadczonego dostawcę. Wbrew pozorom skorzystanie z usług zewnętrznych wcale nie oznacza znaczącego zmniejszenia prac związanych z wdrożeniem, choć ich ciężar przesuwa się na inne obszary działań. Największa zaleta, która często nieoficjalnie traktowana jest jak największa zmora, to konieczność dokładnego udokumentowania procesów, które należy oprogramować. Taka dokumentacja wymaga opisania czasami nawet poszczególnych ruchów pracownika i jego styczności z systemem. Prawie zawsze umożliwia to optymalizację pracy pod kontem nowego systemu. Współpraca z doświadczonym dostawcą pozwala przyspieszyć działania na tym polu, zwłaszcza że dostawca często jest też konsultantem w zakresie procesów, które wspiera swoim systemem. Dodatkowo nie jest to jego pierwszy system, więc często niektóre rozwiązania ma już zoptymalizowane nie tylko pod kątem informatycznym, ale i biznesowym. Bardzo często dostawca zapoznany dokładnie z nowym projektem jest w stanie zaproponować optymalne rozwiązania, które osobom odpowiedzialnym za nowy projekt w sensie biznesowym, nie przyszły w ogóle do głowy.
Innymi zaletami skorzystania z usług zewnętrznego dostawcy jest szybkość dostarczenia gotowego rozwiązania, w porównaniu do szybkości pracy własnych programistów. Jakkolwiek wewnętrzni informatycy mogą rozpocząć działanie znacznie szybciej, niż firma zewnętrzna, ich moce przerobowe są znacznie skromniejsze. Często też duże doświadczenie w tworzeniu pojedynczych modułów, dotychczas wspomagających pracę w firmie, nie przekłada się na doświadczenie w tworzeniu dużego systemu zintegrowanego. Co innego bowiem tworzyć oprogramowanie wspomagające pracę, a co innego oprogramowanie, które jest odpowiedzialne za sprawy kluczowe (utrzymanie integralności na przykład stanów magazynowych czy dokumentów fiskalnych). Rzadko wspominaną zaletą jest kwestia finansowania. Jako że oprogramowanie kupowane od zewnętrznego dostawcy podlega licencjonowaniu, koszty związane z jego zakupem można amortyzować. Dodatkowo jest szansa na finansowanie zewnętrzne (leasing, kredyt) i większa niż w przypadku samodzielnego tworzenia szansa na wsparcie unijne (często dostawcy mają już przetarte ścieżki w tym zakresie).
Wady zlecenia rozwiązania na zewnątrz
Jednak prezes zajmujący się nowymi technologiami jest czujny i wypunktuje wszystkie wady korzystania z zewnętrznego dostawcy, zaczynając od konieczności związania się z nim na dłużej. Klasycznym chwytem w takim przypadku jest też zwrócenie uwagi na duże koszty tworzenia projektu. Tu prezes wykazuje się znajomością chwytów rodem z Shopenhauera. Przyrównuje bowiem koszty zakupu systemu z wartością powstałą przez pomnożenie pensji informatyków przez ich liczbę i czas oczekiwania na system u zewnętrznego dostawcy. Skrzętnie przy tym ukrywa, że wewnętrzni programiści poświęcą na pracę znacznie więcej czasu i rachunek kosztów nie będzie już taki oczywisty. Często podnoszonym argumentem jest też konieczność ponoszenia opłat w przypadku przyszłej rozbudowy systemu. Jeśli firma miała wcześniej negatywne doświadczenia z zewnętrznymi dostawcami będą one na pewno podnoszone. Ponadto własnych programistów będzie można skłonić do pracy po godzinach i w weekendy, w celu przyspieszenia prac, podczas gdy obcy dostawca będzie nieugięty w kwestii raz zdefiniowanego terminu.
Innym argumentem przeciwko wiązaniu się z zewnętrzną firmą jest konieczność przeprowadzenia długo trwającego procesu selekcji potencjalnego kontrahenta. Ze względu na dużą liczbę firm dostarczających podobne rozwiązania często mija sporo czasu, zanim powstanie tak zwana krótka lista, czyli lista firm, które mogą zostać zaproszone do złożenia oferty. Wiele osób mięknie pod argumentem, że czas upływa bezproduktywnie, kiedy nasi chłopcy mogliby już klepać kod. Często związek z zewnętrzną firmą budzi obawy dotyczące wycieku know-how. Oczywiście nie mówię o jawnej sprzedaży pomysłu innej firmie. Jeśli jednak mamy jakiś rewelacyjny i rewolucyjny pomysł, to nawet w przypadku całkowitego gwarantowania tajemnicy, wpływa on na sposób myślenia producenta oprogramowania i idea ta może nie wypływa, ale na pewno powoli się wysącza. Ten argument jest rzeczywiście trudny do podważenia. Tyle tylko, że często stosowany jest na wyrost, to znaczy zarząd obawia się wycieku własnej i rewolucyjnej idei (a przynajmniej tak mu się wydaje), natomiast dostawca oprogramowania często stosuje to rozwiązanie już od kilku lat. Czasami argumentem przeciw wdrożeniu systemu z zewnątrz jest konieczność zrobienia tego hurtem (od razu wszystkie moduły, przy czym nie ma pewności, że są one wszystkie potrzebne, choć zapłacić za nie trzeba).
Dyskusja
Nie będę odnosił się do wszystkich argumentów, zwłaszcza że niektóre są bardzo subiektywne. Podniosę tylko te, które według mnie są używane niepoprawnie ze względu pomylenia pojęć lub świadomie w celu przeforsowania jakiejś opcji. Klasyczny problem to koszty systemu. Jak wcześniej pisałem porównanie kosztów napisania oprogramowania przez dział IT i zakupu bazuje na czasie w którym dostawca dostarcza system. Oczywiście jest to duże nadużycie, gdyż wewnętrzni informatycy znacznie wcześniej zaczęliby pracować (jeszcze przed wyborem dostawcy, podpisaniem umowy i sformułowaniem wymagań), a w chwili wyznaczonej przez dostawcę może dostarczyliby działający system, ale wyłącznie w postaci najważniejszych funkcjonalności (czyli rzeczywista praca potrwa dużo dłużej). Drugim nadużyciem w ramach analizy wydatków jest stawianie tezy, że koszty poprawek systemu będą bardzo duże. Rzeczywiście dniówka zewnętrznej firmy bywa patologicznie wysoka i często wewnętrzne siły zrobią to nie tylko szybciej ale i za niższą stawkę dzienną. Tylko jakby między wierszami umyka nam kwestia, że dobrze zaprojektowany system wykonany od razu w całości powinien wymagać znacznie mniej poprawek, niż tworzony adaptacyjnie we własnym zakresie. Poza tym dostawca oprogramowania często niektóre funkcjonalności ma już zaszyte w kodzie i można je uzyskać przez modyfikacje parametrów, nieodpłatnie bądź bardzo tanio. Poza tym większość nowoczesnego oprogramowania ma możliwość ingerowania w niektóre funkcjonalności programu przez użytkownika (na przykład poprzez modyfikację procedur SQL czy wtyczek plug-in).
Kolejnym źle używanym argumentem jest możliwość natychmiastowego rozpoczęcia pracy nad systemem przez dział IT, w porównaniu do długich prac przygotowawczych przy współpracy z dostawcą. Otóż czas ten wykorzystywany na tworzenie dokumentacji czy definiowanie procesów stanowi zaplecze do przyszłych oszczędności i nie może być w żadnym razie uznany za stracony. Zakup systemu powoduje możliwość przyszłościowego zmniejszenia zasobów działu IT, lub przeniesienia ich do innych zadań. Prawie zawsze, nawet jeśli system jest dobrze udokumentowany, zasoby które go tworzyły w ramach wewnętrznych prac są dalej potrzebne. Choćby na przykład do usuwania błędów, które to błędy dostawca usunąłby w ramach gwarancji.
Innym źle używanym argumentem jest to, że kupując system u dostawcy płacimy często za funkcjonalność, której nigdy nie użyjemy. W argumencie tym popełnia się najczęściej aż dwa błędy jednocześnie. Po pierwsze to za co płacimy to w większości przypadków ta część oprogramowania, która została stworzona bezpośrednio pod nasze potrzeby. Moduły standardowe zostały dodane za darmo, albo za naprawdę symboliczną opłatą. Drugi błąd, to patrzenie na te moduły jako niepotrzebne. Jeśli dostawca dodaje jakieś funkcjonalności od siebie, to tylko wtedy, gdy funkcje te są używane przez większość dotychczasowych klientów i widzi potencjał ich użycia u bieżącego odbiorcy. Często zamiast zlecać wykonanie jakiegoś rozszerzenia wystarczy użyć odpowiednio skonfigurowanego modułu standardowego istniejącego już w systemie.
Na końcu należy wspomnieć o przypadkach, kiedy nie warto w ogóle rozważać pisania czy zlecania dostosowania oprogramowania do własnych potrzeb. Na pewno trzeba zrezygnować z tego w przypadku małych firm. Obecnie w granicach 1000 zł można kupić oprogramowanie do prowadzenia małych firm i znacznie tańszym rozwiązaniem będzie dostosowanie się do istniejącego standardu, niż zatrudnianie programisty, żeby napisał coś dokładnie pod nasze potrzeby. Podobnie w przypadku oprogramowania standardowego typu arkusz kalkulacyjny czy edytor tekstów. Do tego samego worka wrzuciłbym duże firmy potrzebujące wielofunkcyjnych systemów zintegrowanych, z bardzo dużą liczbą transakcji. Tu raczej należy się zdać na doświadczonego dostawcę zarówno ze względu na kosztowne ryzyko zaprojektowania błędnej architektury wewnętrznej jak i ze względu na konieczność posiadania bardzo dużej rzeszy doświadczonych projektantów i programistów do wykonania tego w skończonym czasie. Na przeciwnym krańcu znajduje się firma potrzebująca oprogramowania niszowego. Tu najczęściej nie ma się nad czym zastanawiać, gdyż często oprogramowanie takie w ogóle nie istnieje, jest bardzo drogie lub totalnie niedopasowane do potrzeb zamawiającego.
Jeśli w dyskusji padają argumenty, że własne siły będą w stanie wykonać projekt w zadanym czasie dzięki pracy w nadgodzinach i weekendach, to projekt zaczyna być zagrożony, zanim się rozpoczęła jego realizacja. Jeśli dodatkowo pada teza, że przy tak ważnym projekcie programiści pracują jak w transie, to już się można szykować na porażkę. Większość źródeł zgadza się co do tego, że praca znacząco przekraczająca europejskie normy czasu pracy jest silnym czynnikiem ryzyka. Praca pod presją czasu i znaczenia projektu dla firmy, to kolejny składnik ryzyka. Gorzej może być tylko wtedy, gdy programiści pracujący nad nowym systemem pracują dodatkowo przy rozbudowie i konserwacji poprzedniej wersji, ciągle funkcjonującej w firmie lub przystępują do projektu przemęczeni wcześniejszymi bardzo obciążonymi pracami i brakiem urlopów.
Podsumowanie
Nie zamierzam nikomu sugerować jak powinien się zachowywać w chwili, gdy stanie przed koniecznością podjęcia decyzji co robić. Zwracam tylko uwagę, że należy uwzględnić wymienione przeze mnie aspekty oraz zastanowić się, czy w konkretnym przypadku nie ma ich więcej. Osobiście stworzyłem namiastkę systemu ERP oraz duży system do analizy ryzyka inwestycyjnego (klasyczny produkt niszowy). Oba sprawnie pracowały przez dłuższy czas. Mimo to, gdybym dziś miał podejmować decyzję to optowałbym raczej za zleceniem takich prac zewnętrznemu specjaliście. Podobnie jak ja będą myśleli użytkownicy, którzy mają złe doświadczenie z produktami informatycznymi tworzonymi we własnym zakresie. Za tworzeniem oprogramowania wewnątrz w firmie na pewno będą optować szefowie informatycznych działów projektowych. Tu przyczyna jest oczywista - boją się konieczności redukcji liczby pracowników i utraty znaczenia swojej pozycji. Niewiadomą będzie zachowanie szefa informatyki i finansów. Jeśli szef informatyki miał złe doświadczenia z systemem kupowanym, a w swoim czasie stworzył w jakiejś firmie dobrze działający system, to prawie na pewno będzie forsował pomysł tworzenia oprogramowania we własnym zakresie. Fatalnie, jeśli powody są ambicjonalne, na przykład próba udowodnienia ważności działu informatyki lub siebie jako projektanta systemu. Co do szefa finansów - prawie na pewno wybierze wersję tańszą, oczywiście pod warunkiem, że będzie znał prawdziwe koszty obu wariantów rozwiązania. Może się bowiem zdarzyć, że osoba przedstawiająca koszty utworzenia systemu przejaskrawi wydatki związane z niechcianą przez siebie opcją, a pominie je w opcji uznanej za korzystną ze względów innych niż finansowe.
Ale to już niestety zupełnie nieinformatyczny problem.
Zapraszam również do przeczytania podobnego tematycznie artykułu: Pięć pytań przed wyborem systemu WMS.