W każdej firmie, która chce się rozwijać, prędzej czy później może pojawić się zapotrzebowanie na nowy system informatyczny. Bez względu na to, czy potrzeba systemu narastała latami, była wynikiem zmiany logiki procesu biznesowegoczy pojawienia się nowegozarządu, analiza wdrożeniaprzyszłego systemu możedotknąć kwestii,kto ma go stworzyć.I nie chodzi o wybórkonkretnej firmy,ale o decyzję, często wyłączniepolityczną, czyliczy zewnętrzny dostawca,czy informatycy w firmie.

Mimo dużej popularności usług outsourcingowych oraz dużej liczby dostawców oprogramowania, wciąż istnieją firmy nieinformatyczne, które posiadają duże 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 informatycy 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 budowany na zasadzie zbliżonej do tzw. 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 można je 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 do 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 z siłami, 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, zachodzi konieczność oprogramowania np. 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ą, iż system będzie funkcjonował zgodnie z aktualnymi procesami. Często procesy te były optymalizowane przez długi okres pod kątem pracy bez systemu lub z innym systemem informatycznym. Jeśli nie zostaną zmienione tak, by uwzględniały 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 zostaną utrwalone 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, co często jest wynikiem pośpiechu na etapie projektowania (jeden z poważniejszych błędów popełnianych przy tworzeniu oprogramowania). 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 kroków pośrednich 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 (nieomal wbudowani w serwerownię). 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 osoba z otwartą głową, którą zainteresuje, jakie byłyby zalety zlecenia wykonania systemu informatycznego doświadczonemu dostawcy. 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ększą zaletą, którą często nieoficjalnie traktuje się jak największą zmorę, jest 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 kątem 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 korzystania z usług zewnętrznego dostawcy jest szybkość dostarczenia gotowego rozwiązania w porównaniu z szybkością pracy własnych programistów. Mimo że wewnętrzni informatycy mogą rozpocząć działanie znacznie szybciej niż firma zewnętrzna, ich moce przerobowe są 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 (np. utrzymanie integralności 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ą też przetarte ścieżki w tym zakresie).

Wady zlecenia rozwiązaniana 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 Schopenhauera. Poró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 zmienia zdanie pod wpływem argumentu, że czas upływa bezproduktywnie, kiedy wewnętrzni informatycy mogliby już pisać 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 na pomylenie pojęć lub świadomie w celu przeforsowania jakiejś opcji. Klasyczny problem to koszty systemu. Jak wcześniej wspomniał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 niezwykle wysoka i często wewnętrzni informatycy 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 (np. 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 z długimi pracami przygotowawczymi przy współpracy z dostawcą. Otóż czas 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 liczby pracowników działu IT lub przeniesienia ich do innych zadań. Prawie zawsze, nawet jeśli system jest dobrze udokumentowany, osoby, które go tworzyły w ramach wewnętrznych prac, są nadal potrzebne. Choćby na przykład do usuwania błędów, które 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, tym za co płacimy, jest w większości przypadków ta część oprogramowania, która została stworzona bezpośrednio pod nasze potrzeby. Moduły standardowe dodano 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 marginesie analizy kosztów warto zwrócić uwagę, że koszt zakupu systemu na zewnątrz (w przeliczeniu na jedno stanowisko) często jest niższy, niż zapłacono za Office'a i Exchenge'a, którego zakupu nikt nie kwestionował.

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 konieczność posiadania bardzo dużej rzeszy doświadczonych projektantów i programistów do wykonania tego w określonym 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 zupełnie niedopasowane do potrzeb zamawiającego.

Jeśli w dyskusji padają argumenty, że wewnętrzni informatycy będą w stanie wykonać projekt w zadanym czasie dzięki pracy po godzinach i w weekendy, to projekt zaczyna być zagrożony, zanim rozpoczęła się 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 nadzorowałem tworzenie dużego systemu 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 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.

<hr>Autor jest członkiem PolskiegoTowarzystwa Informatycznego. Tekst nie stanowi oficjalnego stanowiska PTI, lecz jest osobistym poglądem autora.