Czy warto tworzyć własny system IT?
6 Dec 2016 14:53

O potrzebie posiadania systemu zarządzania nie trzeba już nikogo przekonywać. Jednak nadspodziewanie wiele firm z branży poligraficznej podejmuje się samodzielnego stworzenia takiego oprogramowania. W założeniu będzie ono „idealnie dostosowane do metod pracy i odpowie na wszystkie/większość potrzeb firmy”. Istnieje przekonanie, że napisanie i utrzymanie własnego systemu będzie znacznie tańsze niż jego zakup i uniezależni firmę od zewnętrznych dostawców. Należy przyznać, że wizja idealnego i taniego rozwiązania jest rzeczywiście kusząca – pytanie tylko, czy realna? Praktyka pokazuje, że większość firm po upływie 2-3 lat budowy własnego systemu decyduje się jednak na poszukiwanie gotowego rozwiązania. Dlaczego tak się dzieje? Najczęściej dlatego, że decyzja o tworzeniu własnego jest podejmowana pochopnie, bez zdefiniowania funkcjonalności samego systemu, oszacowania zasobów i kompetencji oraz czasu niezbędnych do realizacji takiego projektu. Należy pamiętać, że najczęściej wykonanie prototypu jest wielokrotnie droższe i bardziej czasochłonne od kolejnych egzemplarzy – ta zasada dotyczy również tworzenia oprogramowania. Budowę systemu zarządzania można porównać do budowy domu. Przede wszystkim należy zdefiniować, co chcemy osiągnąć – czyli wyobrazić sobie, jak ma wyglądać nasz wymarzony dom. Niezbędne jest stworzenie szczegółowej dokumentacji zawierającej spis wszystkich pożądanych rozwiązań, funkcji użytkowych, zakresu pracy systemu. Nie oznacza ona kilku stron ogólnie zarysowanych zadań, ale specyfikację zawierającą drobiazgową listę wszystkich elementów. Ogólnie ujmując, na stworzenie takiej dokumentacji trzeba poświęcić od kilku do kilkunastu tygodni pracy. Najczęściej popełniany błąd to zaniedbania dotyczące tworzenia dokumentacji wymaganych funkcjonalności – są one informatykom przekazywane ustnie w bardzo małych porcjach. Sprzyja temu duża wiedza biznesowa informatyków wynikająca często z wieloletniego doświadczenia w danej firmie. Wszyscy wszystkorozumieją, więc zapisywanie na bieżąco założeń i funkcjonalności systemu wydaje się niecelowe. Jednak trudno wtedy uchwycić faktyczną wielkość projektu. Moim zdaniem to właśnie fakt nieoszacowania wielkości projektu powoduje, że tak wiele firm decyduje się na tworzenie własnego systemu. Następnie potrzebne jest stworzenie samego projektu domu – czyli w naszym przypadku przełożenie założeń na to, jak te założenia zrealizować. Podobnie jak w przypadku budowy domu potrzebny jest architekt (w tym przypadku architekt systemu)! Informatyka to dziedzina szeroka i w jej ramach istnieje wiele specjalizacji – zupełnie inne kompetencje musi posiadać osoba odpowiadająca za instalację i administrację systemu operacyjnego czy pomoc użytkownikom, a zupełnie inne architekt systemowy,   jeszcze inne programista (zapewne nie chcielibyśmy, aby nasz dom projektował nawet najlepszy murarz – bardzo często jednak pozwalamy, aby decyzję o architekturze, czyli technologii podejmował programista). Stworzenie architektury systemu to zadanie na co najmniej kilkanaście tygodni. Kolejnym krokiem jest wybór technologii – takiej, która nie tylko sprawdzi się w danym momencie, ale także pozwoli na rozwój i modyfikację oprogramowania w przyszłości. Najlepiej, aby wybór technologii podpowiedziała kompetentna osoba/firma z zewnątrz, w innym przypadku może się okazać, że cegły na naszą budowę będziemy dowozić samochodem sportowym – bo nasz informatyk jest pasjonatem akurat tej czy innej technologii. Teraz wreszcie możemy przystąpić do budowy domu, pozostaje już tylko wybór ekipy – czyli zespołu programistów znających wybraną technologię oraz stworzenie harmonogramu budowy. Jak długo może trwać budowa? Po raz kolejny warto uzmysłowić sobie wielkość pracy do wykonania. Średniej wielkości system MIS (bez finansów, magazynów itp.) na potrzeby drukarni to mniej więcej od 200 tys. do 1,5 mln linii kodu. System klasy ERP – to od 3 do nawet 10 i więcej mln linii kodu. Jeśli przyjąć, że w przeciętnej książce na stronie mamy około 40 wierszy, a nasz system będzie miał „tylko” 10 000 linii kodu, to nasza książka liczyłaby 250 stron, 100 000 to 2500 stron, 1,5 mln to już ponad 37 tys. stron. Wnioski pozostawiam czytelnikom. Musimy również zadbać o wsparcie techniczne po wdrożeniu i rozwój systemu o kolejne funkcje. Oznacza to, że po wdrożeniu systemu nadal musimy utrzymywać (mniejszy) zespół. Projekt staje się więc procesem ciągłym, a nie jednorazowym przedsięwzięciem. Należy rozważyć kilka dodatkowych zagadnień, jak choćby ryzyko niepowodzenia projektu (znacznie większe niż w przypadku gotowego systemu),   konieczność długotrwałego zaangażowania pracowników, ryzyko związane z odejściem pracowników (szczególnie przy braku dokumentacji – system tworzony takim wysiłkiem będzie praktycznie bezużyteczny). Niebagatelne znaczenie ma również konieczność wyważania drzwi, wielokrotnie otwartych już przez innych (chodzi zarówno o kwestie techniczne związane z architekturą systemu, jak i logiczne – jak rozwiązać dany problem) czy tzw. zinformatyzowany bałagan (pracownicy oczekują, że system będzie funkcjonował zgodnie z aktualnymi procesami, często optymalizowanymi pod kąt-em pracy bez systemu, lub z innym systemem informatycznym). I wreszcie integracja z systemem finansowo-księgowym, z którym to problemem nawet gotowe produkty sobie nie radzą (o ile nie są w pełni zintegrowane tak jak np. PrintVis) – ale to już temat na kolejny artykuł. Dopiero takie całościowe podejście do budowy własnego systemu pozwoli oszacować, czy jesteśmy zdolni do stworzenia własnego systemu i czy korzyści z tego wynikające faktycznie przewyższają mankamenty zakupu gotowego rozwiązania.