Zarząd średniej firmy produkcyjnej ma na tablicy dwie opcje. Pierwsza: zrekrutować inżyniera AI na etat. Druga: podpisać umowę z zewnętrznym wykonawcą, który zbierze wymagania, spisze specyfikację i po kilku tygodniach pokaże prototyp. Obie zakładają, że firma już wie, co dokładnie trzeba zbudować i ile tej pracy będzie.
Zwykle nie wie. A proces, który ma zostać usprawniony, w dokumencie wymagań nie mieści się w całości — i nigdy się nie zmieści.
Najważniejsze w skrócie
- To nie jest wybór „tańsze kontra droższe”, tylko wybór między dwoma sposobami pozyskania kompetencji: gotową, osadzoną w procesie na czas projektu albo własnym etatem budowanym od zera.
- Realny koszt zespołu in-house to nie pensja jednej osoby, lecz rekrutacja trwająca miesiące, minimum dwie osoby (żeby nie mieć pojedynczego punktu awarii), narzędzia i infrastruktura oraz czas dojrzewania do pierwszego wdrożenia.
- Konsultant osadzony daje efekt szybciej tylko wtedy, gdy w umowie jest transfer wiedzy — inaczej kupujesz zależność, nie kompetencję.
- Bliskość procesu zmienia nie tempo pisania kodu, lecz liczbę okazji do korekty: błędne założenie wychodzi przy pierwszym realnym przypadku, nie po trzech sprintach.
- Najczęstszy błąd to decyzja podjęta raz na zawsze zamiast modelu etapowego, w którym decyzja o etacie zapada dopiero z danymi w ręku.
Fałszywy dylemat: „zatrudnić czy wynająć”
Pytanie „konsultant czy własny zespół” pada zwykle za wcześnie — zanim firma wie, które wąskie gardło w ogóle warto usuwać i czy do tego potrzebna jest AI, czy wystarczy prostsze narzędzie. Rzadko ktoś dokłada trzecią opcję: konsultanta osadzonego w procesie, który buduje pierwsze narzędzie razem z Twoim zespołem, a decyzję o zatrudnieniu odkłada do momentu, gdy wiadomo, czego dokładnie ta osoba miałaby pilnować na etacie.
Zanim policzysz koszty, rozdziel dwa pytania, które w praktyce się zlewają:
- Czy potrzebuję tego raz — jeden proces, jedno wdrożenie? To pytanie o projekt.
- Czy ta kompetencja ma stać się stałą częścią firmy, obsługującą wiele obszarów przez lata? To pytanie o strukturę organizacyjną.
Pierwsze prawie nigdy nie uzasadnia etatu. Odpowiedź na drugie poznaje się zwykle dopiero po pierwszym, mierzalnym wdrożeniu.
Ile naprawdę kosztuje własny zespół in-house
Pensja to najmniejszy składnik kosztu, a zarazem jedyny, który firmy zwykle liczą przed decyzją.
Rekrutacja. Znalezienie specjalisty od danych i AI to zwykle miesiące, nie tygodnie — a przez ten czas proces działa po staremu.
Liczba osób. Jedna osoba to ryzyko: jeśli odejdzie w trakcie budowy pierwszego wdrożenia, firma zostaje bez kompetencji i bez efektu. Dlatego realna zdolność in-house to zwykle minimum dwie osoby, na przykład inżynier AI i osoba od integracji danych — a więc dwa pełne koszty pracodawcy, zanim padnie pierwsze wdrożenie.
Narzędzia i infrastruktura. Licencje, moc obliczeniowa, środowiska — koszt stały, niezależny od tego, czy akurat jest co robić.
Czas dojrzewania. Zbudowanie od zera zdolności dowożenia wdrożeń — momentu, w którym zespół sam identyfikuje proces, buduje narzędzie i uruchamia je na danych firmy — to zwykle kilka do kilkunastu miesięcy.
Konkretnych widełek płacowych celowo tu nie podajemy: zależą od branży, lokalizacji i zakresu obowiązków, a każda liczba rynkowa bez sprawdzalnego źródła byłaby hipotezą, nie faktem.
Co kupujesz u konsultanta osadzonego, a czego nie kupisz nigdy
Konsultant osadzony (embedded) to specjalista pracujący wewnątrz procesu klienta — w siedzibie firmy albo w stałym, codziennym kontakcie z działem — który na czas określonego zakresu buduje narzędzie razem z zespołem, który ma go potem używać.
Nie przychodzi z raportem co dwa tygodnie i nie znika po dostarczeniu produktu.
Kupujesz w ten sposób:
- Czas do pierwszego efektu — ktoś, kto już usprawniał podobne procesy, nie uczy się podstaw na Twoim budżecie.
- Elastyczność zakresu — jeden obszar dziś (np. wyceny techniczne), inny za kwartał (np. serwis), bez zwalniania i rekrutowania od nowa.
- Wiele kompetencji naraz — inżynieria danych, dobór środka (reguła, formularz, model), uruchomienie.
Czego nie kupisz nigdy, jeśli umowa tego wprost nie gwarantuje:
- Wiedzy, która zostaje w firmie po zakończeniu współpracy. Jeśli konsultant buduje w zamkniętym, licencjonowanym narzędziu, a nie w kodzie i procesach przechodzących na własność klienta, po zakończeniu kontraktu zostajesz z niczym, mimo zapłaconej faktury.
- Ciągłości bez umowy. To nie etat, tylko projekt z zakresem i terminem.
Krótko: dostęp do kompetencji ≠ kompetencja w firmie. Różnica ujawnia się dopiero po zakończeniu współpracy, nie w ofercie.
Dlaczego bliskość procesu zmienia wynik
Problem projektów prowadzonych z dystansu rzadko leży w kompetencjach wykonawcy, tylko w przepływie informacji.
Handlowiec wie, że dla jednego klienta zawsze przygotowuje się wersję z osobnym komentarzem do pozycji technicznej. Technolog wie, że konkretna norma dotyczy dwóch odbiorców i nikogo więcej. Logistyk wie, że środowe dostawy rządzą się własnym trybem, bo tak wyszło trzy lata temu i wszyscy się przyzwyczaili. Żadna z tych rzeczy nie przyjdzie na pierwsze spotkanie wymagań — nie dlatego, że ktoś je ukrywa, tylko dlatego, że dla osoby robiącej to codziennie nie są informacją. Są tłem.
Specyfikacja ≠ proces. Dokument opisuje to, co da się powiedzieć. Proces zawiera także to, o czym nikt nie pomyślał, że warto powiedzieć. Tej wiedzy nie zbierzesz w ankiecie wymagań, bo pytanie trzeba by najpierw umieć zadać — wyłania się przy konkretnej pracy, konkretnym błędzie i pytaniu „a co w takim przypadku?”.
Krótsza pętla korekty. Klasyczny cykl to specyfikacja → sprint → pokaz → uwagi → poprawki, a jedna iteracja zajmuje tygodnie. Gdy prototyp powstaje obok użytkownika, informacja zwrotna przychodzi tego samego dnia. Liczy się liczba okazji do korekty w tym samym czasie.
Odpowiedzialność za wynik, nie za dostarczenie. Wykonawca rozliczany ze zgodności ze specyfikacją ma strukturalną zachętę, by dostarczyć dokładnie to, co uzgodniono — nawet gdy widzi, że uzgodnienie mija się z problemem. Ktoś pracujący wewnątrz procesu nie schowa się za dokumentem, bo jest wystarczająco blisko, żeby go zakwestionować.
Wobec etatu argument działa inaczej: własny pracownik też jest blisko procesu, ale tylko jednego. Konsultant osadzony wnosi bliskość i doświadczenie z innych procesów naraz.
Konsultant osadzony vs zespół in-house: porównanie na 4 osiach
- Czas do pierwszego mierzalnego efektu: konsultant osadzony — punktem odniesienia jest pilotaż trwający 4–6 tygodni. Zespół in-house od zera — kilka do kilkunastu miesięcy, licząc rekrutację i dojrzewanie.
- Koszt roczny: konsultant — płacisz za zakres i czas trwania projektu, skalowalny w górę i w dół. Zespół in-house — koszt stały niezależnie od tego, czy akurat jest co robić.
- Ryzyko rotacji: konsultant — ryzyko po stronie dostawcy, ciągłość reguluje umowa. Zespół in-house — odejście jednej osoby przy zespole jedno- lub dwuosobowym może zatrzymać projekt na miesiące i zabrać niezapisaną nigdzie wiedzę; etat rzadko ma na to plan B.
- Transfer wiedzy do firmy: konsultant — tylko jeśli jest jawnym punktem umowy (dokumentacja, kod na własność, szkolenie osoby po stronie klienta). Zespół in-house — z definicji zostaje, ale tylko dopóki zostają ludzie.
Kiedy in-house ma sens (i kiedy to kosztowna pomyłka)
Budowa własnego zespołu ma sens, gdy równocześnie spełnione są trzy warunki: (1) masz już co najmniej jedno mierzalne, działające wdrożenie, które pokazało konkretną wartość; (2) widzisz kolejkę kolejnych obszarów w kilku działach naraz — nie jeden projekt, tylko ciągły strumień pracy; (3) masz w firmie kogoś, kto potrafi zarządzać zespołem technicznym, bo etat bez nadzoru merytorycznego generuje ryzyko równie duże jak jego brak.
To kosztowna pomyłka, gdy firma zatrudnia „na zapas” — zanim wie, który z sześciu obszarów (sprzedaż, marketing, logistyka, serwis posprzedażowy, wyceny techniczne, produkcja i technologia) ma dane i proces gotowe do usprawnienia. Płacisz wtedy etat za czas, w którym nowa osoba dopiero poznaje firmę.
Kiedy wystarcza zwykłe zlecenie, a model osadzony nie ma sensu
Bliskość nie jest domyślnym trybem pracy, tylko odpowiedzią na złożoność procesu. Sprawdza się, gdy proces jest złożony i słabo udokumentowany, gdy trudno z góry powiedzieć, co trzeba zbudować, gdy po stronie firmy brakuje wolnych rąk do prowadzenia projektu i gdy przyjęcie narzędzia przez zespół jest równie ważne jak jego uruchomienie.
Nie ma sensu, gdy zadanie jest proste i dobrze opisane: wtedy dystans nie szkodzi, a praca zdalna kosztuje mniej.
Nie wiadomo jednak:
- czy problem jest w procesie, czy w jego opisie — bliskość pomaga tylko wtedy, gdy w procesie jest wiedza niepisana do wydobycia;
- kto po Waszej stronie ma czas na codzienną obecność konsultanta w dziale — model wymaga dostępu do ludzi, nie tylko do danych;
- jaka jedna liczba ma się zmienić i ile wynosi dzisiaj;
- kto utrzyma narzędzie po zakończeniu i czy ktoś w zespole będzie umiał je zmienić;
- czy zakres dostępu do systemów jest do zaakceptowania po stronie bezpieczeństwa i ochrony danych.
Brak odpowiedzi nie przekreśla projektu, ale przesuwa pierwszy krok z budowy na rozpoznanie. Wynikiem rozpoznania bywa także „tu nie warto” albo „tu nie potrzebujecie AI” — i to też jest wynik.
Model etapowy: Audyt → Pilotaż → Partnerstwo (+ Szkolenia)
Najbezpieczniejsza ścieżka dla średniej firmy produkcyjnej nie jest binarna. To sekwencja, w której każdy etap kończy się decyzją, a nie automatycznym przejściem do następnego:
- Audyt Procesów — mapuje proces w wybranym dziale, ocenia, czy dane da się odczytać i wskazuje pierwszy krok wraz z liczbą, którą będzie się mierzyć — zanim ktokolwiek zacznie kodować.
- Wdrożenie Pilotażowe — konsultant osadzony buduje jedno działające narzędzie razem z wyznaczoną osobą po stronie klienta, na realnych danych firmy, z pomiarem przed i po. Jak to wygląda krok po kroku, opisuje wdrożenie pilotażowe AI w 4–6 tygodni.
- Partnerstwo Wdrożeniowe — po potwierdzonym wyniku firma decyduje: rozbudowa na kolejne obszary z tym samym partnerem albo transfer kompetencji i przygotowanie do zatrudnienia własnej osoby, która przejmie utrzymanie.
- Szkolenia — niezależnie od ścieżki wyznaczona osoba po stronie klienta uczy się na żywym projekcie, nie na kursie. To ona, nie dostawca, ocenia później, czy firma jest gotowa na własny etat.
Nie płacisz pełnego kosztu etatu, zanim wiesz, że jest co robić, i nie zostajesz z niczym po zakończeniu współpracy, bo kod i wiedza od początku powstają jako własność klienta.
Jak podjąć decyzję: 4 pytania, zanim wybierzesz
- Czy mam już jedno mierzalne wdrożenie, które pokazało wartość? Jeśli dopiero to sprawdzasz, etat jest przedwczesny.
- Jeden projekt czy ciągły strumień pracy w kilku działach? Jeden projekt — konsultant. Strumień — model etapowy.
- Kto po stronie firmy przejmie wiedzę i nadzór nad utrzymaniem? Bez tej osoby żaden model nie da trwałego efektu.
- Czy umowa gwarantuje transfer wiedzy, czy tylko dostęp na czas kontraktu? Od tego zależy, czy zostajesz z kompetencją, czy z zależnością.
Najczęstsze pytania
Czy mogę zacząć od konsultanta osadzonego, a potem zbudować własny zespół?
Tak — to najbezpieczniejsza ścieżka dla średniej firmy produkcyjnej. Pierwszy pilotaż dostarcza danych o czasie, koszcie i efekcie, na podstawie których decyzja o zatrudnieniu jest świadoma, a nie spekulatywna.
Czym różni się konsultant osadzony od zwykłego outsourcingu IT?
Outsourcing zwykle realizuje gotową specyfikację, więc ryzyko trafności pomysłu zostaje po stronie klienta. Konsultant osadzony pracuje wewnątrz procesu klienta, na jego danych, i współtworzy rozwiązanie z zespołem działu, zamiast tylko je kodować.
Czy konsultant osadzony potrzebuje dostępu do naszych systemów?
Tak, i to jest sedno modelu — praca na rzeczywistych danych w rzeczywistym procesie. Zakres dostępu ustala się przed startem i ogranicza do tego, co niezbędne dla konkretnego zadania. To także moment na ustalenie podstawy prawnej przetwarzania, jeśli w grę wchodzą dane osobowe.
Jak mierzy się efekt takiej współpracy?
Jedną liczbą wybraną i zmierzoną przed startem: czasem wykonania czynności, liczbą powrotów do poprawki albo liczbą spraw na osobę. Po ustabilizowaniu narzędzia mierzy się tę samą liczbę ponownie. Bez pomiaru bazowego nie da się obronić żadnego wyniku.
Czy da się łączyć oba modele na stałe, a nie tylko na starcie?
Tak. Firma może utrzymywać własną, mniejszą obsadę od utrzymania działających narzędzi, a nowe obszary otwierać z partnerem zewnętrznym. To model trwały, nie tylko przejściowy — pod warunkiem, że kompetencja i rozwiązania zostają w firmie.
Co dalej
Zanim policzysz koszt etatu, sprawdź, który obszar firmy ma dane i proces gotowe do usprawnienia i czy ten proces w ogóle wymaga pracy z bliska.
→ Umów bezpłatną konsultację 30 minut i porozmawiajmy o jednym konkretnym wąskim gardle.
→ Wolisz zacząć samodzielnie? Bezpłatna diagnoza procesów pokaże, gdzie w Twoich procesach wąskie gardło kosztuje najwięcej.
→ Audyt Procesów wskaże, gdzie usprawnienie da najszybszy efekt, a gdzie nie warto go zaczynać.
Artykuł porównuje konsultanta pracującego wewnątrz procesu klienta z własnym zespołem i wyjaśnia, dlaczego dystans do procesu obniża jakość rozwiązania. Nie jest opisem konkretnej realizacji, kalkulacją wynagrodzeń ani obietnicą wyniku — przedstawia mechanizm oraz warunki, w których każdy z modeli ma przewagę, i te, w których jej nie ma.
