Usługa · doradztwo

Konsulting automatyzacji procesów dla firm, które chcą najpierw wiedzieć, co robić.

Pracuję z firmami operacyjnymi na 3–50 osób — transport, budowlanka, magazyn, e-commerce. Oglądam to, jak dziś przebiega praca, i mówię wprost: co warto zautomatyzować, w jakiej kolejności, czym, ile to będzie kosztować w utrzymaniu i czego nie ruszać wcale. To ocena i plan. Wdrożenie jest osobną decyzją, którą podejmujecie później.

Bogusław Tolarz · aktualizacja: 20 sierpnia 2026

Zakres tej usługi

Zakres jest wąski i celowo taki zostaje. Nie dostajecie ode mnie strategii cyfrowej transformacji ani mapy dojrzałości organizacji, tylko odpowiedź na sześć rzeczy, które trzeba rozstrzygnąć, zanim ktokolwiek zacznie cokolwiek budować.

Przegląd tego, co dzieje się dziś

Idę przez wybrany fragment firmy krok po kroku: skąd przychodzi wejście, kto co przepisuje, gdzie dane czekają na człowieka i w którym miejscu przebieg się urywa. Interesuje mnie stan faktyczny, a nie procedura opisana w dokumencie — te dwie rzeczy rzadko są tym samym.

Odsiew: co nadaje się do automatyzacji, a co nie

Nie każdy uciążliwy proces jest kandydatem. Sprawdzam, czy powtarza się regularnie, czy da się go zapisać regułą, czy wejście przychodzi w stałej formie i czy błędny wynik ma jak zostać zauważony. Proces, który nie spełnia tych warunków, opisuję jako odrzucony razem z powodem.

Kolejność, w jakiej to robić

Lista rzeczy do zautomatyzowania jest bezużyteczna bez kolejności. Ustawiam ją według tego, co kosztuje najwięcej i co da się ruszyć niezależnie od reszty — a nie według tego, na co w firmie najgłośniej narzekają.

Wybór drogi dla każdej pozycji

Dla każdego procesu wskazuję, czym go załatwić: zmianą organizacyjną, funkcją, która już jest w programie, za który płacicie, gotowym narzędziem typu n8n, Make czy Zapier, czy dopiero rozwiązaniem pisanym na miarę. Kolejność jest właśnie taka — od najtańszego.

Rekomendacja, która może brzmieć „nie kupujcie nic”

Jeśli macie już wycenę od dostawcy albo agencji, czytam ją i mówię, co w niej jest realną robotą, co da się zrobić taniej inaczej, a czego w niej brakuje. Najczęściej brakuje utrzymania i opisu, co się dzieje, gdy automat po cichu przestanie działać.

Koszt po uruchomieniu

Przy każdej rekomendacji piszę, co trzeba będzie utrzymywać i co się stanie po aktualizacji programu albo zmianie po stronie kontrahenta. To ta część rachunku, której zwykle nie ma w ofertach — a która decyduje, czy oszczędność jest trwała, czy jednorazowa.

Doradztwo a wdrożenie — dwie różne umowy

Doradztwo odpowiada na pytanie co zrobić i dlaczego akurat to. Wdrożenie odpowiada na pytanie jak to zbudować, żeby działało w poniedziałek rano. To dwie różne roboty i warto je rozdzielać — zwłaszcza w rozmowie o pieniądzach, bo mieszanie ich w jedną pozycję jest najprostszym sposobem, żeby przepłacić za jedno i nie dostać drugiego.

W dużych firmach doradczych te dwie role są rozdzielone także osobowo: rekomendację pisze jeden zespół, a wykonuje ją inny — czasem z innej firmy, czasem rok później. Autor rekomendacji nie ponosi jej konsekwencji, bo w momencie, gdy okazuje się, że dane wejściowe wyglądają inaczej niż w prezentacji, jest już przy następnym projekcie.

U mnie ocenę i wykonanie robi ta sama osoba. To znaczy dokładnie tyle, że nie napiszę rekomendacji, której sam nie chciałbym potem zrealizować — bo to ja będę się tłumaczył, jeśli okaże się nierealna. W praktyce to najmocniejszy filtr na pobożne życzenia, jaki znam.

Ma to też drugą stronę, którą wolę powiedzieć od razu: jestem potencjalnym wykonawcą tego, co sam zarekomenduję, więc mam w tym interes. Dlatego dokument piszę tak, żeby dało się go zanieść do dowolnej agencji albo do własnego programisty: z nazwanymi narzędziami, warunkami brzegowymi i kryterium odbioru, nie w formie „potrzebna jest analiza pogłębiona”. Jeśli po lekturze zdecydujecie, że zrobicie to bez mnie, dokument nadal działa.

Jak taka ocena wygląda w środku? Przeczytaj przykładową analizę →

Jak to przebiega

Cztery kroki, zawsze w tej kolejności. Każdy z nich może być ostatni — także pierwszy, jeśli z rozmowy wyjdzie, że nie ma czego automatyzować.

1
Rozmowa bez przygotowania
Nie musicie nic wcześniej opisywać ani rysować. Wystarczy, że powiecie, co się dzieje i co Was uwiera. Częścią tej rozmowy jest ustalenie, czy w ogóle macie problem, który warto ruszać — i zdarza się, że kończy się ona na tym.
2
Wgląd w to, co dzieje się naprawdę
Patrzę na to, jak proces przebiega naprawdę, zamiast na slajd z jego opisem — zwykle wystarczy, że ktoś przeprowadzi mnie przez kilka typowych przypadków i pokaże przykładowe dokumenty. Zakres dostępu ustalamy wcześniej i bywa, że nie potrzebuję żadnego: często wystarczy rozmowa z osobą, która ten proces wykonuje. Praktycznie zawsze wychodzi wtedy arkusz, o którym nie ma w dokumentacji ani słowa, i to on trzyma całość.
3
Ocena i plan na piśmie
Dostajecie dokument: co zautomatyzować, w jakiej kolejności, czym, co to wymaga po Waszej stronie, czego nie ruszać i dlaczego. Napisany tak, żeby dało się go położyć na stole przed dowolnym wykonawcą — nie tylko przede mną.
4
Decyzja jest Wasza
Możecie zrobić to sami, zlecić komuś innemu albo poprosić mnie o wykonanie. Wdrożenie jest osobną rozmową i osobną decyzją; ocena ma wartość również wtedy, gdy odpowiedź brzmi „robimy to z kimś innym” albo „nie robimy tego w tym roku”.

Czego w tym nie ma

Granice zakresu wypisuję, bo taniej jest rozstać się przed rozmową niż w jej połowie. Jeśli któryś z tych punktów opisuje właśnie to, czego szukacie, macie odpowiedź od razu i bez straty czasu.

Nie zajmuję się automatyzacją przemysłową

Linie produkcyjne, sterowniki PLC, roboty na hali, systemy SCADA — to osobna dziedzina i osobne kompetencje. Pracuję z procesami biurowymi i operacyjnymi: dokumenty, zamówienia, dane między programami, obieg informacji między ludźmi.

Nie doradzam w prowadzeniu firmy

Nie wchodzę w strategię, ceny, politykę kadrową ani windykację. Zakres kończy się tam, gdzie kończy się pytanie „jak ma przebiegać ta praca i co da się z niej zdjąć”.

Nie liczę, kogo da się zwolnić

Efekt automatyzacji opisuję jako odzyskany czas i zdjęte ryzyko błędu, nie jako redukcję etatów. Jeśli oczekiwanym wynikiem projektu jest lista stanowisk do likwidacji, to nie jest zlecenie dla mnie.

Nie wydaję ocen na podstawie samej opowieści

Rekomendacja zbudowana wyłącznie na tym, jak proces jest opisywany na spotkaniu, jest wróżeniem. Muszę zobaczyć realne dane i realne przebiegi — także te nietypowe, bo to one zwykle decydują o wykonalności.

Nie potwierdzam decyzji już podjętych

Jeśli narzędzie jest wybrane, umowa w zasadzie ustalona, a ode mnie oczekuje się dokumentu, który to uzasadni przed zarządem albo wspólnikiem — odmówię. Taka opinia nikomu nie służy, a mnie kosztuje dokładnie to, co w tej pracy jest warte pieniędzy.

Nie prowadzę szkoleń z narzędzi

Nie uczę obsługi konkretnego programu ani nie robię warsztatów „wprowadzenie do automatyzacji”. Tłumaczę decyzje, które podejmuję, i to, jak utrzymać zbudowane rozwiązanie — ale mieści się to w robocie i nie sprzedaję tego jako szkolenia.

Od czego zaczynamy rozmowę

Możecie odpowiedzieć sobie na nie jeszcze przed kontaktem ze mną. Same odpowiedzi zwykle porządkują sprawę bardziej niż pierwsza rozmowa, a przy okazji pokazują, ile z tego da się rozstrzygnąć bez wydawania pieniędzy.

Co się stanie, jeśli przez rok nic z tym nie zrobicie?

Jeśli odpowiedź brzmi „nic szczególnego, będzie irytująco”, to jest ważna informacja — i uczciwie ją powiem, zamiast szukać uzasadnienia dla projektu. Sensowna automatyzacja zwykle ma po drugiej stronie coś twardego: rosnący wolumen, powtarzalne błędy albo jedną osobę, na której wszystko stoi.

Kto zna cały przebieg od początku do końca?

Jeśli takiej osoby nie ma, to jest pierwsza rzecz do zrobienia — i nie jest to zadanie programistyczne. Bez takiej osoby wynik będzie szybszy, ale tak samo pogmatwany — i przez lata nikt nie odważy się tam zajrzeć.

Skąd przychodzą dane i czy da się to zmienić u źródła?

Bardzo często najtańsza zmiana nie jest automatyzacją: formularz zamiast wiadomości pisanej prozą, ustalony układ pliku zamiast „każdy przysyła, jak umie”. Pytam o to na początku, bo taka odpowiedź potrafi skasować połowę zakresu, zanim cokolwiek powstanie.

Za jakie systemy już płacicie i czego w nich nie używacie?

Zanim zaproponuję dołożenie czegokolwiek, sprawdzam, czy program, który już macie, tego nie potrafi. Zaskakująco często potrafi — tylko funkcja nie została włączona albo nikt nie wiedział, że tam jest.

Kto będzie właścicielem tego po uruchomieniu?

Rozwiązanie bez właściciela po stronie firmy umiera po pierwszej zmianie w otoczeniu. Pytam o konkretną osobę i o to, czy ma na to czas w kalendarzu — nie o deklarację, że „ktoś się tym zajmie”.

Czym dla Was będzie znaczyło, że się udało?

Bez tego zdania nie da się później sprawdzić, czy projekt miał sens. Policzcie to u siebie zawczasu: ile razy w miesiącu ta czynność się powtarza, razy ile minut zajmuje jedna, razy stawka osoby, która ją wykonuje. Ten rachunek zostaje po Waszej stronie; ja go tylko urealniam.

Dostajesz ocenę i plan. Wykonania w tym nie ma.

Dobra strona: rozmawiacie z tą samą osobą, która ogląda dane, pisze rekomendację i — jeśli tak zdecydujecie — potem to buduje. Nic nie ginie w przekazaniu między zespołem sprzedaży, zespołem analizy i zespołem wykonawczym, bo nie ma takich przekazań. Nie usłyszycie też, że „to było poza zakresem tamtego etapu”.

Zła strona: jestem jeden, a duża firma doradcza ma zaplecze, którego pojedyncza osoba nie zastąpi. Jeśli Wasza organizacja potrzebuje ciągłości zespołowej, kilku równoległych strumieni pracy albo dużego programu przekształceń prowadzonego przez rok, to jest realny powód, żeby wybrać kogoś innego. Powiem to na rozmowie, jeśli tak będzie wyglądać.

Jest jeszcze trzecia rzecz, mniej oczywista. Skoro to ja będę wykonawcą, mam naturalny konflikt interesu przy rekomendowaniu rozwiązań pisanych na miarę — to najdroższa i najciekawsza technicznie droga. Świadomie ustawiam ją na końcu listy możliwości i sięgam po nią dopiero wtedy, gdy tańsze warianty odpadną z podanego powodu. Jeśli w moim dokumencie trafi się rekomendacja budowy czegoś od zera bez takiego uzasadnienia — dopytajcie. Macie do tego pełne prawo.

Napiszcie, co macie rozstrzygnąć.

Nie potrzebuję opisu procesu, listy systemów ani wiedzy, czy Wasze programy mają API. Wystarczy jedno–dwa zdania o tym, co Was uwiera albo jaką decyzję macie przed sobą — odpowiem, czy to jest w moim zakresie, i powiem, od czego bym zaczął.

Opisz swoją sytuacjębez płatności i zobowiązań

Zanim napiszecie, warto samodzielnie przejść test opłacalności: automatyzacja procesów w małej firmie — co się opłaca → A jeśli problemem są dwa programy, które ze sobą nie rozmawiają: integracja systemów — kiedy się opłaca →