Autorem artykułu jest: Robert Wojtkowski, CEO Gardens-Software
Przez lata pracy przy wdrożeniach widziałem ten sam obraz w dziesiątkach firm produkcyjnych. Wchodzę do zakładu, rozmawiam z właścicielem albo dyrektorem, pytam o systemy, na których pracują. I słyszę, z dumą, że akurat oni nie mają z tym problemu, bo mają u siebie zdolnego informatyka, który napisał im wszystko pod ich potrzeby. Działa idealnie, jest dopasowane co do milimetra, lepsze niż niejedno gotowe oprogramowanie z rynku.
Zwykle to prawda. I właśnie dlatego to jest groźniejsze, niż się wydaje.
Bo za tym obrazem sukcesu kryje się zależność od jednego programisty, której większość firm w ogóle nie nazywa problemem, dopóki problem sam się nie przypomni. A przypomina się zawsze w najgorszym możliwym momencie. W tym artykule chcę spokojnie pokazać, jak rozpoznać tę sytuację u siebie, dlaczego zatrudnienie drugiej osoby zwykle jej nie rozwiązuje i co można z tym zrobić bez wyrzucania tego, co u Was naprawdę działa.
Zacznijmy od tego, że firma, która ma własne oprogramowanie napisane przez wewnętrznego specjalistę, zwykle ma powody do zadowolenia. Taki system rośnie razem z firmą. Programista zna procesy od podszewki, bo sam je implementował, więc kolejne funkcje powstają szybko i pasują do realnej pracy, a nie do teoretycznego schematu. Nie ma długich kolejek do zewnętrznego dostawcy, nie ma faktur za każdą drobną zmianę. Jest jedna osoba, która rozumie i biznes, i technologię, i potrafi je połączyć.
To jest realna wartość i nie zamierzam jej podważać. Autorskie oprogramowanie, szyte na miarę, często obsługuje specyficzne procesy lepiej niż gotowe rozwiązania pudełkowe. Problem nie leży w jakości tej pracy. Wręcz przeciwnie, im lepiej ta osoba wykonała swoje zadanie, tym mocniej firma się od niej uzależniła, nie zdając sobie z tego sprawy.
Pamiętam rozmowę z prezesem pewnego zakładu, który powiedział mi wprost, że jego programista zarabia więcej niż on sam. Powiedział to ze śmiechem, jako ciekawostkę. Ale gdy się nad tym chwilę zastanowić, to nie jest ciekawostka. To opis sytuacji, w której cała firma stoi na wiedzy jednego człowieka, a ten człowiek doskonale o tym wie.
Zanim przejdę do ryzyka, muszę wyjaśnić jedno nieporozumienie, bo wraca w niemal każdej takiej rozmowie i sam długo nie zdawałem sobie sprawy, jak jest powszechne.
Wielu właścicieli i dyrektorów firm produkcyjnych mówi mi, że są świetnie zautomatyzowani i nie potrzebują żadnego systemu do zarządzania. Gdy dopytuję, na czym ta automatyzacja polega, okazuje się, że chodzi o zestaw programów obsługujących linię produkcyjną. Pomiary, parametry techniczne na poszczególnych etapach, opomiarowanie części zdawczej produkcji. To jest tak zwany system realizacji produkcji, w skrócie MES, czyli warstwa, która zbiera dane wprost z hali.
Z perspektywy dyrektora to jest cała automatyzacja, jaką firma potrzebuje. I tu pojawia się luka w myśleniu. Bo te programy na hali rzadko są połączone z resztą firmy. Działają obok magazynu, obok zamówień, obok rozliczeń. Nikt nie łączy faktów, że można mieć jedną platformę, w której zarządzanie zasobami, zlecenia produkcyjne, wycena magazynu i dane z produkcji żyją razem, w jednej bazie danych.
System klasy ERP to nie jest, wbrew obiegowej opinii, tylko księgowość i magazyn. To ogólne zarządzanie zasobami całej firmy, a produkcji nie da się sensownie planować w oderwaniu od zasobów, które ją zasilają. To jest fragment większej całości, który ktoś zbudował osobno, bo gotowy system tego konkretnego procesu nie obsługiwał.
To rozróżnienie ma znaczenie, bo pokazuje, że problem nie polega na tym, że firma ma „za mało technologii". Często ma jej sporo. Polega na tym, że ta technologia jest rozsypana, niepołączona i co najważniejsze dla tego artykułu, oparta na jednej osobie.
Dopóki kluczowa osoba jest na miejscu, wszystko działa i naprawdę trudno dostrzec zagrożenie. System chodzi, produkcja idzie, a ewentualne usterki ten ktoś naprawia, zanim większość załogi w ogóle je zauważy. To usypia czujność. Skoro od lat nie było problemu, to po co go sobie wymyślać.
Ryzyko nie znika jednak dlatego, że go nie widać. Ono tylko czeka na swój moment. A momentów jest kilka i każdy prędzej czy później nadchodzi.
Najłagodniejszy to dłuższy urlop. Człowiek, który zna system, wyjeżdża na dwa tygodnie, a firma nagle odkrywa, że pewnych rzeczy nikt poza nim nie potrafi zrobić. Zwykle da się to przeczekać, choć bywa nerwowo.
Poważniejszy to choroba, zwłaszcza nagła i dłuższa. Tutaj przeczekać już się nie da, a system nie poczeka na powrót do zdrowia.
Najtrudniejszy to odejście. Czasem do konkurencji, czasem do firmy, która zaoferowała więcej. Osoba, która odchodzi, zabiera ze sobą całą wiedzę o tym, jak działa coś, na czym stoi Wasza produkcja. I nie ma znaczenia, czy rozstajecie się w dobrej, czy w złej atmosferze, bo wiedza i tak wychodzi za drzwi, a firma zostaje niejako bez działającego systemu.
Jest jeszcze jeden moment, o którym mówi się najrzadziej, a który jest najbardziej nieubłagany. Emerytura. To nie jest ryzyko, to pewność rozłożona w czasie. Jeśli Wasz system napisała osoba, która zbliża się do końca kariery, to pytanie nie brzmi „czy", tylko „kiedy" i „czy będziecie wtedy przygotowani".
We wszystkich tych sytuacjach skutek jest ten sam. Zostaje oprogramowanie, którego nikt nie rozumie na tyle, by je bezpiecznie utrzymać, a tym bardziej rozwinąć.
Najczęstsza reakcja, gdy firma w końcu dostrzeże problem, jest logiczna. Skoro ryzykiem jest jedna osoba, to zatrudnijmy drugą, żeby było ich dwie. Niestety w praktyce to rzadko rozwiązuje sprawę, a powód jest techniczny.
Programy pisane wewnętrznie, przez lata, przez jedną osobę, powstają zwykle w językach niskiego poziomu. Mówię o technologiach pokroju C++ czy rozwiązaniach opartych na .NET, w których pisze się dużo kodu, blisko maszyny, i w których łatwo zbudować coś, co rozumie wyłącznie autor. Taki kod prawie nigdy nie ma dokumentacji, bo po co dokumentować coś, co i tak utrzymuje jedna osoba, która ma wszystko w głowie.
Kiedy do takiego systemu wchodzi nowy programista, nie dostaje czytelnej mapy. Dostaje tysiące linii cudzego kodu bez opisu, w którym logika biznesowa jest wpleciona w techniczne szczegóły. Zanim cokolwiek zrozumie, mijają miesiące. Zanim odważy się coś zmienić, nie psując przy tym dziesięciu innych rzeczy, mija jeszcze więcej czasu. A bywa, że nowa osoba po prostu się poddaje i stwierdza, że łatwiej byłoby napisać to od nowa, co przecież oznacza powrót do punktu wyjścia.
Dlatego mówię klientom wprost, że problemem nie jest liczba programistów, tylko forma, w jakiej zapisana jest wiedza o systemie. Jeśli ta wiedza istnieje wyłącznie w głowie jednej osoby i w nieczytelnym kodzie, to dołożenie drugiej osoby niewiele zmienia. Zależność się nie rozprasza, ona się co najwyżej pogłębia, bo teraz macie dwie osoby, bez których firma nie funkcjonuje.
Tu dochodzimy do sedna, bo łatwo odnieść wrażenie, że jedynym rozwiązaniem jest wyrzucenie autorskiego systemu i wdrożenie czegoś gotowego od zera. To rozwiązanie istnieje, ale jest kosztowne, długie i, co najważniejsze, oznacza utratę wszystkiego, co przez lata zostało dopracowane. Istnieje też inna droga.
W Gardens-Software podchodzimy do tego inaczej, bo Gardens ERP to nie jest tylko system, ale też platforma rozwoju oprogramowania z własnym, wysokopoziomowym środowiskiem programistycznym o nazwie IDE GAM. W praktyce oznacza to, że logikę istniejącego rozwiązania można przenieść na nową platformę, zamiast budować wszystko od początku.
Proces, w pewnym uproszczeniu, wygląda tak. Najpierw bierzemy to, co u Was działa, czyli sprawdzone procesy i reguły biznesowe zaszyte w starym systemie. Następnie przenosimy tę logikę na platformę IDE Gardens AM, przy okazji ją porządkując. To trochę jak refaktoryzacja, czyli przepisanie kodu tak, by robił to samo, ale w czytelniejszej, łatwiejszej do utrzymania formie. Logika zostaje, a balast i błędy, które narosły przez lata, zostają z tyłu. Zamiast niskopoziomowego, autorskiego kodu powstaje rozwiązanie w środowisku wysokopoziomowym, w modelu low-code, które jest czytelne i, co kluczowe, zrozumiałe nie tylko dla jednej osoby.
Efektem jest oprogramowanie, które robi to co wcześniej, ale przestaje być zakładnikiem jednej głowy. Może je rozwijać Wasz obecny specjalista, może przejąć ktoś inny, może wesprzeć zewnętrzny partner. Firma odzyskuje coś, co przez lata, często niepostrzeżenie, oddała pod kontrolę jednej osobie. Odzyskuje niezależność.
To pytanie pada zawsze i słusznie, bo dotyczy człowieka, który dla firmy jest cenny. Obawa brzmi mniej więcej tak: skoro uniezależniamy się od tej osoby, to czy ona straci znaczenie albo poczuje się zagrożona.
Odpowiadam zwykle, że jest dokładnie odwrotnie, i że ta osoba powinna być wygranym całego procesu, a nie jego ofiarą. Pomyślcie, kto najlepiej zna Wasze procesy. Nie my, konsultanci z zewnątrz, tylko właśnie ten programista, który je przez lata implementował. To czyni go najcenniejszym uczestnikiem przeniesienia systemu, a nie kimś, kogo się przy tej okazji odsuwa.
W modelu, który stosujemy, ta osoba nie odchodzi i nie traci pozycji. Po przeszkoleniu i zdobyciu certyfikatu developerskiego w platformie IDE Gardens AM może samodzielnie przenosić swoje rozwiązanie i dalej je rozwijać, tym razem w nowoczesnym, wysokopoziomowym środowisku, w którym pracuje się szybciej i wygodniej niż w starym kodzie. Z osoby, która w pojedynkę dźwiga trudny do utrzymania system, staje się tak zwanym Citizen Developerem, czyli osobą z firmy, która rozwija jej oprogramowanie od środka, łącząc znajomość biznesu ze znajomością narzędzia.
Dla specjalisty to rozwój kompetencji i mocniejsza, a nie słabsza pozycja. Dla firmy to spokój, bo wiedza tej osoby zostaje utrwalona w czytelnym kodzie, zamiast wyparować w dniu, w którym ona odejdzie. Z mojego doświadczenia świadomy programista, gdy zaproponuje mu się nową platformę i szkolenie, najczęściej sam chce się w to zaangażować, bo widzi w tym własny interes, nie zagrożenie.
Warto zatrzymać się przy tym, czym ta droga różni się od klasycznego wdrożenia gotowego systemu, bo różnica jest zasadnicza.
Klasyczne wdrożenie ERP od zera zwykle oznacza, że porzucacie dotychczasowe rozwiązanie i odtwarzacie procesy na nowo, często bez udziału osoby, która zna je najlepiej. To duży projekt z jednym, odległym terminem zakończenia, trochę jak budowa, gdzie efekt widać dopiero na końcu. Jest kosztowny, długi i obarczony ryzykiem, bo jeśli coś w odwzorowaniu procesów zostanie pominięte, okazuje się to zwykle po fakcie.
Przeniesienie logiki na platformę IDE Gardens AM przebiega inaczej. Zachowuje sprawdzone procesy i wiedzę zespołu, więc nie zaczynacie od zera. Odbywa się etapami, więc efekty widać po pierwszym kroku, a nie dopiero na końcu wielomiesięcznego projektu. Ma niższy próg wejścia, bo na start potrzebujecie zasadniczo licencji i szkolenia, a organizacja uczy się platformy stopniowo, w swoim tempie. To podejście bliższe pracy organicznej, krok po kroku, niż jednorazowej rewolucji, która na wiele miesięcy paraliżuje firmę.
Z każdego takiego wdrożenia, w którym uczestniczyła osoba znająca procesy, pamiętam to samo. Różnica w koszcie i w pewności efektu wobec budowania wszystkiego od podstaw była ogromna. Obecność kogoś, kto rozumie firmę, sprawia, że wdrożenie znacznie częściej kończy się sukcesem.
Jeśli rozpoznajecie u siebie sytuację, którą opisałem, nie znaczy to, że trzeba natychmiast cokolwiek przebudowywać. Pierwszy krok jest znacznie spokojniejszy. Polega na tym, żeby w ogóle nazwać ryzyko i przyjrzeć się, na czym dokładnie stoi Wasza firma.
Warto zadać sobie kilka prostych pytań. Które z naszych rozwiązań zna i utrzymuje tylko jedna osoba. Co się stanie, jeśli tej osoby zabraknie przez miesiąc, a co, jeśli na stałe. Czy ktokolwiek poza nią potrafi w tym kodzie cokolwiek zmienić. Czy istnieje jakakolwiek dokumentacja, czy cała wiedza jest w jednej głowie. Odpowiedzi zwykle są wymowne i same pokazują, jak pilna jest sprawa.
Dobra wiadomość jest taka, że najlepszy moment, by się tym zająć, to ten, w którym wszystko jeszcze działa, a kluczowa osoba jest na miejscu i może spokojnie uczestniczyć w przeniesieniu swojej wiedzy. Najgorszy moment to ten, w którym tej osoby już nie ma, a system trzeba ratować w pośpiechu. Różnica między tymi dwoma scenariuszami to różnica między świadomą decyzją a gaszeniem pożaru.
Jeśli chcecie zobaczyć, jak takie przeniesienie wygląda w praktyce i czy ma sens w Waszym przypadku, opisaliśmy to dokładniej na stronie poświęconej przeniesieniu firmowego systemu na platformę IDE Gardens AM. Nie trzeba na tym etapie niczego zmieniać. Wystarczy pokazać nam, jak dziś działa Wasze oprogramowanie i kto za nim stoi, a wspólnie ocenimy, od czego najlepiej zacząć.
Czym jest zależność od jednego programisty w firmie? Zależność od jednego programisty to sytuacja, w której firmowe oprogramowanie napisała i utrzymuje wyłącznie jedna osoba, a nikt inny nie rozumie go na tyle, by je bezpiecznie utrzymać lub rozwinąć. Ryzyko ujawnia się, gdy ta osoba bierze dłuższy urlop, choruje, odchodzi lub przechodzi na emeryturę.
Czy autorski system w firmie to coś złego? Autorski system sam w sobie nie jest niczym złym i często obsługuje procesy lepiej niż gotowe rozwiązania pudełkowe. Problemem nie jest jakość oprogramowania, lecz to, że wiedza o nim koncentruje się w jednej osobie, co tworzy ryzyko dla ciągłości działania firmy.
Dlaczego zatrudnienie drugiego programisty nie rozwiązuje problemu? Zatrudnienie drugiej osoby rzadko usuwa zależność, ponieważ autorski kod pisany w językach niskiego poziomu, bez dokumentacji, jest bardzo trudny do przejęcia przez kogokolwiek poza autorem. Nowa osoba potrzebuje miesięcy, by zrozumieć cudzy kod, a zależność zwykle się pogłębia, zamiast znikać.
Czy trzeba całkowicie zmienić obecny system, żeby uniezależnić się od jednej osoby? Nie trzeba wyrzucać obecnego systemu. Logikę istniejącego rozwiązania można przenieść na otwartą platformę, zachowując sprawdzone procesy, a jednocześnie zapisując je w czytelnym kodzie, który może rozwijać więcej niż jedna osoba.
Co się dzieje z dotychczasowym programistą po przeniesieniu systemu? Dotychczasowy programista zwykle staje się najważniejszym uczestnikiem przeniesienia, ponieważ najlepiej zna procesy firmy. Po szkoleniu i certyfikacji w platformie IDE Gardens AM może samodzielnie przenieść i dalej rozwijać rozwiązanie, zyskując nowe kompetencje zamiast tracić pozycję.
Czym różni się przeniesienie systemu od wdrożenia ERP od zera? Wdrożenie od zera oznacza porzucenie obecnego rozwiązania i odtworzenie procesów na nowo, w jednym długim projekcie. Przeniesienie na platformę IDE Gardens AM zachowuje istniejącą logikę i wiedzę zespołu, przebiega etapami i ma niższy próg wejścia.
Zależność od jednej osoby to jedno z tych ryzyk, które najłatwiej zignorować, bo nie boli, dopóki nie jest za późno. Ale właśnie dlatego warto zająć się nim wtedy, gdy jest jeszcze spokojnie. Jeśli chcesz porozmawiać o swojej sytuacji, bez zobowiązań, umów rozmowę o swoim systemie, a przyjrzymy się jej wspólnie.