W większości polskich MŚP są dziesiątki małych narzędzi, które decydują o tym, czy firma w ogóle wystawi dziś fakturę. Makra Excela, bazy Accessa, skrypty PowerShella, procedury SQL dopisane kiedyś przez byłego informatyka. Nikt już nie wie, co dokładnie robią. Dopóki działają — nikt nie pyta.
Nazywamy to shadow development: tworzenie i utrzymywanie oprogramowania poza oficjalnym IT, bez dokumentacji, bez kontroli wersji, często bez wiedzy właściciela. To nie to samo co shadow IT (czyli zakupy SaaS poza działem IT). Shadow development jest cichszy i groźniejszy, bo zwykle siedzi w sercu procesu — w fakturowaniu, w rozliczeniach, w eksporcie do księgowej. I zwykle ma jednego autora, który pamięta, dlaczego pewien IF wygląda akurat tak.
Pierwszy raz naprawdę zauważysz go wtedy, gdy ten autor odejdzie z firmy, a ty w piątek po południu dostaniesz od handlowców pytanie: „Czemu dziś prowizje są dziwne".
Jak to wygląda w typowej firmie
U jednego z naszych klientów — 28-osobowego producenta opakowań z tworzyw sztucznych, pracującego na enova365 i kilku arkuszach Google — zrobiliśmy audyt tego typu narzędzi. Wynik: 34 skrypty i makra, z czego tylko 9 miało w firmie aktywnego autora. Reszta pochodziła od byłego informatyka, dwóch odeszłych księgowych i jednego praktykanta sprzed czterech lat.
Największe ryzyko siedziało w jednym pliku Excela: makro liczące prowizje handlowców. Autor odszedł 18 miesięcy wcześniej. Przez ten czas dyrektor sprzedaży podpisywał co miesiąc listy prowizji — nie wiedząc, że od aneksu z 2024 roku jeden bonus był liczony inaczej, niż powinien. Firma przepłaciła prowizje na kwotę 47 tys. zł zanim ktoś to w ogóle zauważył. Zauważył zresztą nie dział sprzedaży, tylko biuro rachunkowe przy zamknięciu roku.
Drugi na liście: skrypt PowerShella uruchamiany co noc, kopiujący pliki z udziału sieciowego na serwer FTP klienta sieciowego. Nikt już nie wiedział, który klient, który serwer, ani co się stanie, jeśli skrypt padnie. Padł zresztą rok wcześniej — i nikt tego nie zauważył, bo klient nie zgłaszał braku plików.
Trzeci: baza Accessa, w której dział planowania produkcji trzymał harmonogram pięciu linii. Działała, dopóki nie trzeba było dodać nowego materiału. Wtedy okazywało się, że pole „kod materiału" w jednej tabeli ma 10 znaków, a w drugiej 12 — i że ten dziwny krok, w którym planista „przechodzi do widoku zapytania Q7 i klika strzałkę w dół trzy razy", też jest częścią procesu.
To nie są patologie. To normalny stan firmy, która przez 10–15 lat rozwijała się szybciej, niż jej IT.
Dlaczego to się dzieje
Shadow development powstaje z tych samych powodów co shadow IT: oficjalne narzędzia nie dowożą tego, co ludzie muszą robić. Z tą różnicą, że próg wejścia jest niższy. Każdy, kto umie napisać formułę w Excelu albo nagrać makro, może sobie „pomóc". A ponieważ to działa — nikt nie protestuje.
Trzy typowe źródła:
- ERP nie potrafi tego, co jest potrzebne na wczoraj. Handlowiec dostaje w ERP raport sprzedaży bez prowizji. Siada, buduje w Excelu makro, które robi za niego to, czego ERP nie zrobi. Problem rozwiązany na dziś. Ale makro zostało i stało się częścią procesu.
- Były informatyk kochał PowerShella. Każdy problem rozwiązywał skryptem. Każdy skrypt odpalał się z Task Schedulera na którymś serwerze. Nikt nigdy nie dostał listy tych skryptów. Po jego odejściu firma nawet nie wie, co się dziś w nocy wydarzy.
- Jedna osoba zbudowała sobie „swój system". Zwykle baza Accessa albo Google Sheet z Apps Scriptem. Działa — i w pewnym momencie trzy inne osoby zaczynają z niego korzystać. Jest już wtedy systemem produkcyjnym firmy, tylko bez umowy i bez backupu.
Jak zrobić inwentaryzację
Nie potrzebujesz do tego narzędzi za 20 tys. zł. Potrzebujesz jednej osoby, która poświęci na to dwa–trzy tygodnie, i prostego arkusza w czterech kolumnach: nazwa, co robi, kto zna, co się stanie, jeśli przestanie działać.
Krok 1 — zrób listę miejsc, w których żyje kod. Nie szukaj kodu, szukaj miejsc. Typowe źródła w polskiej MŚP:
- katalogi
\\serwer\dane\makra,\\serwer\it\skrypty,C:\Scriptsna serwerze, - Task Scheduler na każdym serwerze (również serwerach aplikacyjnych ERP),
- pliki
.xlsm,.accdb,.mdbw udziałach działów (sprzedaż, księgowość, planowanie), - cron / systemd timers na Linuksie, jeśli coś takiego jest,
- Apps Script w Google Workspace i Power Automate / Power Query w Microsoft 365,
- procedury składowane i joby w bazie SQL Server ERP-a (Comarch Optima, enova365, Subiekt — każdy pozwala dopisywać procedury),
- „makra Outlooka" na stacjach starszych pracowników.
Krok 2 — przy każdym elemencie listy zapytaj trzy osoby: kto to napisał, kto to dziś rozumie, co się dzieje, jeśli to padnie. Jeśli na którekolwiek z pytań odpowiedź brzmi „nie wiem" — oznacz pozycję na czerwono.
Krok 3 — dla każdej czerwonej pozycji odpowiedz sobie na jedno pytanie: czy proces, który to narzędzie obsługuje, jest krytyczny dla przychodu, zobowiązań podatkowych albo bezpieczeństwa. Jeśli tak, trafia na szczyt listy do naprawy.
To wszystko. Dwa tygodnie, jeden arkusz, zero magii. Pierwsza wersja nie musi być kompletna — musi być szczera.
Co zrobić z tym, co znajdziesz
Nie ma jednej dobrej odpowiedzi. Są cztery, w zależności od wartości narzędzia i ryzyka:
- Udokumentować i zostawić. Jeśli skrypt jest prosty, działa od lat i jest co najmniej jedna osoba, która wie, co robi — wystarczy opisać go w jednym akapicie i położyć kopię w repozytorium (nawet w zwykłym OneDrive z historią wersji). Nie wszystko trzeba przepisywać.
- Przepisać do kontrolowanej formy. Jeśli narzędzie dotyka pieniędzy (prowizje, faktury, cenniki, rozliczenia z dostawcami) albo bezpieczeństwa (dostępy, backupy, kopie dla biura rachunkowego) — przenieś je do czegoś, co ma kontrolę wersji, testy i jednoznacznego właściciela. Zwykle to prosty skrypt w repozytorium Git albo przepisanie makra na procedurę w ERP.
- Zastąpić funkcją oficjalnego systemu. Czasem makro liczące prowizje istnieje tylko dlatego, że nikt nigdy nie włączył w ERP modułu prowizji. Zamiast przepisywać, warto zapytać dostawcę ERP, czy to już nie jest standardem.
- Wyłączyć. Spora część skryptów nic już nie robi — generuje raport, którego nikt nie czyta, kopiuje plik, którego nikt nie potrzebuje. Wyłącz go na tydzień. Jeśli nikt nie zapyta — wyłącz na stałe.
Dla każdego narzędzia, które zostaje, przydziel drugiego człowieka. Nie dokumentację — człowieka. Dokumentacja się dezaktualizuje, drugi człowiek zadaje pytania.
Co dalej
Shadow development nie zniknie, bo firma będzie się dalej zmieniać szybciej, niż oficjalne IT. Chodzi o to, żeby wiedzieć, co masz, i żeby najważniejsze rzeczy miały właściciela, drugiego człowieka i miejsce, w którym żyją oficjalnie.
Jeśli nie wiesz, od czego zacząć w swojej firmie — można zacząć od godziny rozmowy. Przeprowadzamy taki audyt regularnie, zwykle wychodzi coś, czego właściciel się nie spodziewał. Lepiej, żeby to „coś" wyszło przy audycie, a nie w piątek po południu, gdy prowizje policzą się dziwnie.
Dopóki działa, nikt nie pyta. W dniu, w którym padnie, pyta się zwykle już klient.