Strategia AI · 23 maja 2026 · 24 min. czytania · Mohsen Ghulami, GTM Engineer, Amplifa

Strategia AI: Build vs. Buy w średnich przedsiębiorstwach

Strategia AI w sektorze MŚP: Proszę podjąć decyzję Build vs. Buy w oparciu o liczby, przypadki i jasne kryteria, zanim PoC pochłonie budżet.

Trzy tygodnie temu stoję w Gütersloh w sali konferencyjnej, która pachnie kawą z filtra i ciepłym tworzywem sztucznym. Thomas, CTO producenta maszyn zatrudniającego 280 osób, przesuwa w moją stronę swojego iPada i mówi: „Budujemy teraz własną platformę AI”. Na podwórzu piszczy cofający wózek widłowy, wewnątrz migocze slajd PowerPoint z logo Azure, wężem Python i blokiem budżetowym wynoszącym 1,2 miliona euro. Moje pierwsze pytanie nie było techniczne, lecz brutalnie proste: Czy to naprawdę strategia AI — czy tylko kosztowna droga na około do kolejnego standardowego oprogramowania?

Piszę o przemyśle od 1998 roku. Widziałem w Trumpf w Ditzingen, jak dane z wycinarek laserowych stają się biznesem usługowym. Doświadczyłem u mniejszych podwykonawców na Jurze Szwabskiej, jak jeden brakujący eksport z MES zatrzymuje cały projekt AI. I widziałem wystarczająco wielu dyrektorów finansowych (CFO), którzy na słowo „własna produkcja” zaciskają usta, jakby ugryźli cytrynę.

Build vs. Buy w przypadku AI nie jest zatem kwestią wiary. To kwestia alokacji kapitału. Średniej wielkości przedsiębiorca zatrudniający od 50 do 500 pracowników, który chce samodzielnie budować każdy model prognozowania, marnuje czas, wynagrodzenia i nerwy. Kto jednak kupuje każdą funkcję AI, mimo że to ona stanowi o różnicy w jego własnym produkcie, oddaje marżę dostawcom, którzy nie rozumieją jego biznesu. Widziałem oba przypadki. Oba bolą.

Dlaczego strategia AI staje się teraz sprawą dla zarządu

W marcu 2025 roku siedziałem u dostawcy w pobliżu Heilbronn, 410 pracowników, dużo obróbki skrawaniem, mało cierpliwości. Andrea, Head of Operations, pokazała mi linię z sześcioma centrami obróbczymi DMG Mori. Dźwięk był tym twardym, metalicznym śpiewem, który zna się z hal, w których nikt nie mówi o przyszłości, bo zlecenie musi wyjść do piątku. „Mamy cztery PoC AI”, powiedziała Andrea. „Żaden nie działa produkcyjnie”.

Dokładnie w tym miejscu znajduje się sektor MŚP. Nie na początku debaty o AI, lecz po pierwszym wytrzeźwieniu. ChatGPT otworzył drzwi w 2023 roku, Microsoft Copilot dotarł do wielu firm, SAP wprowadza funkcje AI do swojego pakietu, a co drugi dostawca oprogramowania nakleja już etykietę AI na swoją mapę drogową. Tylko że na hali, w sprzedaży, w serwisie dzieje się mniej, niż twierdzą sceny konferencyjne.

Liczby pasują do tej obserwacji. Według badania Bitkom z 2024 roku około 15 do 20 procent niemieckich firm stosuje AI produkcyjnie; w firmach zatrudniających od 100 do 499 pracowników wskaźnik ten znajduje się raczej w dolnym przedziale, około 10 do 15 procent. BCG i VDMA w 2023 roku w budowie maszyn dostrzegły wzorzec, który stale słyszę w rozmowach: ponad 60 procent eksperymentuje z PoC AI, ale mniej niż 15 procent posiada skalowalne aplikacje w firmie. Zatem: dużo pilotaży, mało eksploatacji.

To nie jest niemieckie prawo natury. To często efekt złego podejmowania decyzji. Sektor MŚP zbyt często traktuje AI jak zakup technologii, a zbyt rzadko jak kwestię tworzenia wartości. W zakładzie z Augsburga zatrudniającym 180 pracowników Jens, dyrektor handlowy, powiedział mi w styczniu 2025 roku: „Nie możemy sobie pozwolić na błąd”. To prawda. Ale brak decyzji to również błąd. Tylko cichszy.

Strategia AI w średnich firmach: Co naprawdę oznacza Build vs. Buy

Build nie oznacza, że trzech Data Scientists trenuje w piwnicy Foundation Model. Cóż, prawie nigdy. Build w średniej firmie oznacza zazwyczaj: własne potoki danych, własne modele lub przynajmniej własną logikę domenową, własne procesy MLOps, własny monitoring, własną odpowiedzialność. Dostawca dostarcza być może infrastrukturę chmurową, ale firma ponosi ryzyko produktowe i operacyjne.

Buy nie oznacza, że kupuje się oprogramowanie i w poniedziałek oszczędza 15 procent braków. Kto w to wierzy, nigdy nie widział interfejsu między starym ERP, eksportem z Excel a sterowaniem maszyn. Buy oznacza: zakup standardowego oprogramowania, SaaS lub komponentów platformy, konfigurację, integrację, szkolenie, pomiar. To jest praca. Ale to inna praca niż budowa modelu.

Najostrzejsza granica nie przebiega między chmurą a On-Prem. Przebiega między Commodity a dyferencjacją. Forecasting, standardowe NLP, klasyfikacja obrazów, optymalizacja tras, asystent ofertowania, proste Recommendation Engines — do tego istnieją użyteczne produkty. AI w rdzeniu produktu, na przykład inteligentna sensoryka, autonomiczna nawigacja, zastrzeżone sterowanie procesami lub algorytm serwisowy, który uczy się z 15 lat danych maszynowych — tam Build może mieć sens. Może. Nie musi.

PwC i Roland Berger od 2023 roku opisują wzorzec, który pojawia się również w moich rozmowach: mniejsze i średnie firmy wybierają głównie Buy lub Configure, większe średnie firmy częściej wybierają Hybrid. Zakład zatrudniający 300 osób kupuje raczej Microsoft, SAP, Cognex, Celonis, o9, PTC lub wyspecjalizowanego dostawcę. Dostawca zatrudniający 3000 osób buduje być może Analytics Competence Center i rozwija tam, gdzie leży wartość dodana. Brzmi to banalnie. Mimo to jest stale ignorowane.

Twarde liczby: Koszty, harmonogramy, wskaźniki sukcesu

W ciągu ostatnich dwóch lat rozmawiałem w Monachium, Stuttgarcie, Bielefeld i Linzu z osobami odpowiedzialnymi za cyfryzację, które prowadzą swoje budżety AI nie w komunikatach prasowych, lecz w Excelu. Przedziały są zadziwiająco stabilne. PoC typu Build w średniej firmie kosztuje zazwyczaj od 100.000 do 300.000 EUR za trzy do sześciu miesięcy. Zanim MVP zacznie działać produkcyjnie, realne są kwoty od 300.000 do 800.000 EUR, przy czym wewnętrzne koszty personelu nie zawsze są rzetelnie wyliczone. I właśnie tam zaczyna się samooszukiwanie.

Ponieważ Data Scientist nie jest darmowy tylko dlatego, że figuruje już na liście płac. Inżynier produkcji, który co tydzień przez osiem godzin sprawdza etykiety, również nie. Architektka IT, która wyjaśnia zatwierdzenia bezpieczeństwa, tym bardziej. W zakładzie pod Ulm w lutym 2025 roku pachniało chłodziwem, gdy Martin, kierownik IT, mówił mi: „Zewnętrznie wydaliśmy tylko 180.000 EUR”. Dwie godziny później pokazał mi wewnętrzne szacunki nakładów. Z uwzględnieniem pracy własnej projekt wyniósł 520.000 EUR.

Buy lub Configure zaczyna się od niższych kwot. Licencja pilotażowa plus integracja: często 50.000 do 250.000 EUR. Rollout na kilka zakładów lub obszarów: 150.000 do 800.000 EUR. Bieżące koszty licencyjne dla wielu scenariuszy w średnich firmach wynoszą od 50.000 do 200.000 EUR rocznie, zależnie od liczby użytkowników, wolumenu danych i nastroju dostawcy. Tak, nastroju dostawcy. Kto kiedykolwiek negocjował przedłużenie SaaS w trzecim roku obowiązywania umowy, wie, co mam na myśli.

Wskaźniki sukcesu są właściwym ciosem poniżej pasa. McKinsey raportował w State of AI 2023, że tylko około 20 do 30 procent firm osiąga znaczące korzyści finansowe z projektów AI. W produkcji i towarach przemysłowych, według mojego doświadczenia i benchmarków doradczych, 50 do 70 procent PoC umiera, zanim doczeka się realnej eksploatacji. W przypadku Build często tylko 30 do 40 procent wykonuje skok do produkcji. W przypadku Buy lub Configure raczej 50 do 70 procent. Nie dlatego, że dostawcy czarują. Lecz dlatego, że w modelu tkwi mniejsze ryzyko podstawowe.

Build opłaca się — ale rzadziej, niż twierdzą slajdy startupów

Lubię własne rozwiązania. Naprawdę. Istnieje ten moment, gdy zespół nie tylko trenuje model, ale osadza go w procesie, użytkownicy go dotykają, wskaźnik się zmienia, a kierownik zakładu nie mówi już o „tej rzeczy AI”, lecz o swoim nowym narzędziu. To jest mocne. Tylko że nie dzieje się to dlatego, że ktoś zainstalował PyTorch.

Trumpf jest dobrym przykładem, ale i ostrzeżeniem. Rodzinna firma z Ditzingen zatrudnia około 16.500 pracowników, posiada głębokie dane maszynowe, własną historię platformy z AXOOM i ekosystem wokół TruConnect. Od około 2017 roku Trumpf stale inwestuje w usługi cyfrowe, Predictive Maintenance i funkcje Smart Factory. W publicznych prezentacjach Trumpf mówi o skróceniu przestojów o 20 do 30 procent w przypadku niektórych urządzeń dzięki konserwacji zapobiegawczej. To nie jest poboczny projekt IT. To biznes produktowy i usługowy.

Kärcher z Winnenden jest równie interesujący. KIRA B 50, autonomiczny robot czyszczący, potrzebuje Computer Vision, nawigacji, fuzji czujników i solidnego oprogramowania w fizycznym produkcie. Standardowy Recommender z chmury niewiele tu pomoże. Kärcher od około 2018 roku buduje kompetencje cyfrowe, między innymi w Digital Hub, i łączy własny rozwój z komponentami chmurowymi. Tutaj Build nie jest prestiżem. AI tkwi w urządzeniu, w cenie, w umowie serwisowej.

To jest sedno: Build opłaca się, gdy AI zmienia korzyść dla klienta lub odwzorowuje proces, którego konkurenci nie mogą łatwo skopiować. Producent obrabiarek z miliardami historycznych danych z czujników ma inną sytuację wyjściową niż hurtownik zatrudniający 220 osób, który chce poprawić Cross-Selling w sklepie internetowym. Kto zaciera te różnice, zabiera się do rzeczy od złej strony.

Rozwijamy własne rozwiązania tylko tam, gdzie widzimy wyraźną przewagę konkurencyjną, a nasza wiedza o procesach lub produktach jest unikalna. Standardowe analizy i modele językowe kupujemy.

— zgodnie z sensem wypowiedzi CDO niemieckiego producenta maszyn, rozmowa Handelsblatt 2024

Nicole Büttner z Merantix Momentum w formatach EY dotyczących „Przyszłości Niemiec” podkreślała coś podobnego: Sektor MŚP ma przewagę dzięki własnym danym, ale powinien często kupować modele i platformy, zachowując kontrolę nad logiką domenową. Podpisuję się pod tym. Same dane nie są jeszcze fosą obronną. Dopiero gdy dane, wiedza procesowa i kanał dystrybucji spotykają się, Build staje się interesujący.

Buy-first to nie kapitulacja, lecz dyscyplina

W Münster spotkałem w listopadzie 2024 roku menedżera logistyki, Ralfa, który w Fiege brał wcześniej udział w projektach prognozowania. Siedzieliśmy w stołówce, pachniało sosem pieczeniowym, a z magazynu dochodziło głuche dudnienie techniki przenośnikowej. „Mogliśmy wszystko zbudować sami”, powiedział. „Ale po co?”. Fiege wykorzystuje w różnych obszarach usługi chmurowe, komponenty Azure i rozwiązania partnerskie, na przykład do prognoz i optymalizacji. Opublikowane Use Cases mówią o redukcji zapasów o 2 do 5 procent i poprawie Forecast Accuracy o 3 do 8 procent, zależnie od dziedziny.

To rzeczywistość średnich firm, tylko o numer większa. Forecast rzadko jest unikalny. Optymalizacja tras również nie. Kontrola jakości oparta na obrazie ze zdefiniowaną klasą błędów jest technicznie wymagająca, ale często nie stanowi powodu do budowy własnego zespołu Vision. Cognex, Landing AI, Microsoft Custom Vision, Siemens Industrial Edge, PTC ThingWorx lub wyspecjalizowani dostawcy mają swoje wady. Oczywiście. Ale nie zaczynają od zera.

Anonimowy przypadek z południowych Niemiec czysto pokazuje tę logikę. Producent maszyn, 800 pracowników, manualna kontrola wizualna, brak personelu, wysoka presja na poprawki. Firma kupiła komercyjny system Vision AI zamiast własnego rozwoju. Inwestycja początkowa: około 350.000 EUR na sprzęt, licencje, integratora i szkolenie. Cztery miesiące PoC, trzy miesiące rolloutu na dwóch liniach. Po dwunastu miesiącach wskaźnik błędów był o około 30 procent niższy, amortyzacja poniżej 18 miesięcy. Brak nagrody za innowacyjność. Ale są pieniądze.

Wiem, Buy brzmi dla niektórych CTO zbyt skromnie. Nie chce się tylko „konfigurować”. Chce się kreować. Zrozumiałe. Tylko że klient nie płaci za dumę działu IT. Płaci za terminowość dostaw, jakość, serwis, stabilność cen. Jeśli standardowe oprogramowanie przynosi 80 procent korzyści w jedną trzecią czasu, to własny rozwój jest często próżnością z planowaniem sprintów.

Druga prawda: Buy może stać się drogie, ociężałe i niebezpieczne

Teraz autokorekta. Buy-first nie oznacza Vendor-first. Widziałem projekty SaaS, które po dwóch latach wyglądały jak wynajmowane mieszkanie po dziesięciu podnajemcach: wszędzie adaptery, nikt już nie wie, do kogo należy klucz. Dostawca z Dolnej Bawarii zatrudniający 260 osób płacił w 2024 roku za trzy narzędzia bliskie AI w sprzedaży, serwisie i planowaniu umiarkowane licencje. Wraz z interfejsami, doradztwem i wewnętrznymi administratorami roczne koszty nagle wyniosły 310.000 EUR. Korzyść? Trudno mierzalna. „Mamy teraz pulpity nawigacyjne”, powiedział szef sprzedaży. Współczułem mu.

Największym błędem Buy jest ślepa wiara w funkcje. Demo oprogramowania zawsze pokazuje czyste dane. Zawsze. W realnej eksploatacji pojawiają się podwójne bazy klientów, brakujące hierarchie artykułów, odbiegające modele zmianowe i pole w ERP o nazwie „Inne”, które od 2009 roku zawiera wszystko, czego nikt nie potrafił przypisać. SAP, Microsoft, Siemens czy PTC mogą wiele zamortyzować. Ale nie naprawią organizacji, która lekceważy swoje dane podstawowe.

Drugim błędem jest Lock-in bez ekwiwalentu. Jeśli jeden dostawca kontroluje całe przechowywanie danych, logikę modelu, interfejs użytkownika i integrację procesów, firma staje się zależna. Może to być akceptowalne, jeśli Use Case to Commodity, a dostawca dostarcza stabilnie. Przy krytycznych procesach rdzeniowych należy być ostrożniejszym. Eksport danych, audytowalność, koszty przy skalowaniu, scenariusz wyjścia — nudne tematy, tak. Właśnie dlatego czyta się o nich zbyt późno.

Gdzie umierają projekty Build w średnich firmach

Istnieje scena, która się powtarza. Sala konferencyjna, szara wykładzina, biała tablica z pozostałościami warsztatu, gdzieś jeszcze widnieje „priorytetyzacja Use Case”. W pokoju siedzą IT, dział merytoryczny i zewnętrzny doradca. Po 14 miesiącach trwania projektu ktoś pyta: „Kto właściwie jest Product Ownerem?”. Wtedy zapada cisza. Doświadczyłem tego w Kolonii, Norymberdze i St. Gallen.

Pierwszą przyczyną śmierci jest jakość danych. Mało seksowne, ale zabójcze. Dostawca motoryzacyjny zatrudniający około 3.000 pracowników uruchomił w ciągu trzech lat kilka PoC Predictive Maintenance wspólnie z instytutem badawczym. Nakład: ponad milion euro, wliczając czas wewnętrzny. Wszystkie pilotaże utknęły w pojedynczych urządzeniach. OT i IT były rozdzielone, brakowało centralnego Lakehouse, dział utrzymania ruchu został włączony zbyt późno, a historia danych nie pasowała do logiki awarii. Po zmianie kierownictwa IT przeszło na standardową platformę. Dziewięć miesięcy później ruszyły pierwsze produkcyjne Use Cases, po 18 miesiącach na wybranych maszynach odnotowano o około 15 procent mniej nieplanowanych awarii.

Drugą przyczyną śmierci jest fałszywa duma. Handlowiec B2B z regionu DACH zatrudniający około 1.200 pracowników chciał zbudować własny Recommendation Engine, również po to, by zmniejszyć zależność od amerykańskich platform chmurowych. Pięcioosobowy zespół Data Science, Python, Scikit-Learn, później TensorFlow. Osiemnaście miesięcy czasu rozwoju, z grubsza 1 do 1,5 miliona euro. Ostatecznie wydajność po testach wewnętrznych wynosiła tylko 60 do 70 procent standardowego Cloud Recommender. Projekt został zatrzymany, rozwiązanie SaaS i tak zostało wprowadzone. Tylko później i drożej.

Trzecią przyczyną śmierci jest brak myślenia produktowego. AI jest uruchamiane jako projekt, a nie eksploatowane jako produkt. Jest PoC, raport końcowy, brawa w komitecie sterującym. Potem model dryfuje, nikt nie mierzy wskaźnika wykorzystania, nikt nie planuje retreningu, nikt nie czuje się odpowiedzialny za fałszywe alarmy. Po sześciu miesiącach kierownik zmiany mówi: „To coś wariuje”. I już po akceptacji.

MLOps nie jest tu buzzwordem, lecz pracą dozorcy dla modeli. Monitoring, wersjonowanie danych, procesy zatwierdzania, Rollback, odpowiedzialności, ścieżka audytu. Brzmi sucho. Bo takie jest. Ale bez tych rutyn AI staje się oprogramowaniem jednorazowym. Buduje się, pokazuje, zapomina.

Macierz Build-vs.-Buy dla solidnej strategii AI

W rozmowach chętnie korzystam z prostej macierzy 2×2. Żadna magia. Na osi X znajduje się potencjał dyferencjacji: Czy ta funkcja AI sprawia, że trudniej nas skopiować na rynku? Na osi Y znajduje się standaryzowalność: Czy istnieje dojrzałe oprogramowanie, które pokrywa 70 do 80 procent zadania? Jeśli obie osie zostaną uczciwie ocenione, wiele ulubionych projektów odpada.

Kwadrant pierwszy: wysoki potencjał dyferencjacji, niska standaryzowalność. Tutaj można poważnie rozważyć Build lub Co-Build. Przykłady: AI w urządzeniu medycznym ze specjalną sensoryką, autonomiczne funkcje w maszynie czyszczącej, sterowanie procesem przy własnej metodzie produkcji. Kärcher, Trumpf, Wittenstein czy Festo myślą w takich kategoriach. Tam AI tkwi blisko produktu lub tajemnicy procesu.

Kwadrant drugi: niski potencjał dyferencjacji, wysoka standaryzowalność. Kupić. Kropka. Standardowy Forecasting, klasyfikacja tekstów w obsłudze klienta, proste chatboty, sprawdzanie wydatków, Lead Scoring, kontrola obrazu ze znanymi wzorcami błędów. Kto tutaj głosi Build, powinien położyć na stole koszty alternatywne. Nie jako slajd. Jako kwotę w euro.

Kwadrant trzeci: wysoki potencjał dyferencjacji, wysoka standaryzowalność. To ekscytujący obszar hybrydowy. LLM może generować projekty ofert, ale własna logika produktu, zasady rabatowe, terminowość dostaw i klauzule odpowiedzialności muszą pochodzić z firmy. Microsoft Copilot lub SAP Joule mogą dostarczyć interfejsy, ale mózg biznesowy leży we własnym modelu danych. Właśnie tam średnie firmy powinny budować kompetencje.

Kwadrant czwarty: niski potencjał dyferencjacji, niska standaryzowalność. Zazwyczaj sygnał ostrzegawczy. Jeśli coś nie jest ani strategicznie ważne, ani łatwe do kupienia, po co to robić? Bo kierownik działu tego chce? Bo mruga program dotacyjny? Pieniądze z dotacji to nie Business Case. Tu nie ma o czym dyskutować.

Rachunek ROI: Dlaczego tańszy start może skończyć się drogo

W czerwcu 2025 roku zadzwonił do mnie prezes z Ravensburga. 120 pracowników, budowa maszyn specjalnych, przyzwoity EBIT, ale słabe IT. Zapytał: „Ile kosztuje nas AI do automatyzacji ofert?”. Odpowiedziałem pytaniem: „Ile kosztuje oferta dzisiaj?”. Cisza. Potem wertowanie kartek. Potem liczba: około 1.800 EUR wewnętrznego nakładu przy złożonych maszynach, gdy zaangażowana jest sprzedaż, konstrukcja i zakupy.

Dopiero z takimi liczbami Build vs. Buy staje się uchwytne. Jeśli firma pisze 900 złożonych ofert rocznie, a system asystencki AI skraca czas procesowania o 25 procent, nie mówimy o zabawie. Mówimy o wydajności, szybszej reakcji, mniejszej liczbie błędów w listach części, lepszym śledzeniu. O tym, czy rozwiązanie zostanie kupione, zbudowane czy będzie hybrydowe, decyduje Payback, a nie przeczucie CTO.

Porównanie branżowe: Budowa maszyn, handel, logistyka, motoryzacja

Budowa maszyn kusi do Build. Firmy mają pewność techniczną, wielu inżynierów, dobre dane produktowe i często kulturę samodzielnego tworzenia. W DMG Mori, Trumpf, Wittenstein czy Festo taka postawa ma sens w funkcjach AI bliskich produktowi. U producenta instalacji zatrudniającego 180 osób z Górnej Frankonii, który chce zbudować własną tekstową AI do raportów serwisowych — raczej nie. Zapach oleju hydraulicznego nie sprawia, że model NLP staje się zastrzeżony.

Handel i dystrybucja B2B powinny prawie zawsze myśleć w kategorii Buy-first. Recommendation, Pricing, prognozowanie zapasów, klastry klientów, sterowanie kampaniami — to dziedziny z wieloma dostawcami i dużym doświadczeniem. Dyferencjacja leży tam mniej w algorytmie, a bardziej w jakości danych, logice asortymentu, warunkach zakupu i egzekucji sprzedaży. Handlowiec z Essen powiedział mi w kwietniu 2025 roku: „Chcieliśmy sami odtworzyć logikę Amazon”. Zapytałem: „Dlaczego najpierw nie zacząć sprzedawać jak Amazon?”. Nie śmiał się.

Logistyka jest bardziej pragmatyczna. Być może dlatego, że tam każdy punkt procentowy natychmiast przekłada się na palety, kilometry i grafiki zmian. Fiege, Dachser czy Rhenus pracują z platformami, partnerami i własnymi zespołami tam, gdzie to pasuje. Buy dla standardowej optymalizacji, Build lub Co-Build przy specjalnych danych sieciowych i planowaniu specyficznym dla klienta. Decyduje posadzka hali. Nie dział strategii.

Dostawcy motoryzacyjni siedzą między krzesłami. Mają wolumen, presję jakościową, wymogi Traceability i wytyczne OEM. Predictive Quality, Maintenance, kontrola wizualna i AI do planowania są atrakcyjne. Ale wiele zakładów rosło historycznie, dane OT są pofragmentowane, a rada zakładowa chce być pytana o zdanie na wczesnym etapie. Kto tam zaczyna Build bez platformy danych, ląduje w bagnie PoC. Widziałem to zbyt często.

Przykład z praktyki: 320 pracowników, 14 miesięcy, uczciwa hybryda

Przypadek, który mogę opowiedzieć anonimowo: producent komponentów z Badenii-Wirtembergii, 320 pracowników, obrót prawie 75 milionów euro, klienci z branży budowy maszyn i techniki medycznej. Byłem tam w październiku 2024 roku. W dziale kontroli jakości pachniało alkoholem do czyszczenia, pod lampą LED leżały wyfrezowane części w szarych tackach. Sabine, kierowniczka jakości, powiedziała: „Tracimy czas, bo zbyt późno widzimy błędy”.

Firma miała trzy pomysły na AI: Vision AI do kontroli jakości, Forecasting w zakupach, asystent ofertowania dla części specjalnych. Dawniej prawdopodobnie uruchomiono by trzy PoC. Tym razem nie. Prezes przepuścił każdy pomysł przez macierz. Vision AI: Buy. Forecasting: Buy/Configure. Asystent ofertowania: Hybrid, ponieważ logika technicznej wykonalności i zasady wariantów były naprawdę specyficzne dla firmy.

Liczby po 14 miesiącach: Pilotaż Vision AI dla dwóch rodzin części kosztował około 210.000 EUR wliczając kamerę, oświetlenie, integratora i szkolenie. Przepuszczalność błędów spadła o 28 procent, poprawki o 11 procent. Forecasting został wprowadzony przez moduł istniejącego partnera ERP plus zewnętrzny potok danych, koszt około 95.000 EUR; Forecast Accuracy wzrosła w częściach A o 6 punktów procentowych. Asystent ofertowania kosztował więcej: około 380.000 EUR, ponieważ zintegrowano CPQ, zasady bliskie CAD i historie cenowe. W zamian średni czas procesowania złożonych ofert spadł z 9,5 do 6,8 dnia roboczego.

Ważniejszy od poszczególnych liczb był ład (governance). Na każdy Use Case przypadał jeden Product Owner, odbywał się miesięczny przegląd KPI, istniały jasne kryteria przerwania i mały rdzeń danych: jeden Data Engineer, jedna Analytics Engineer, zewnętrzny architekt na sześć miesięcy. Żadne laboratorium AI z pufami. Żaden cyrk innowacji. Tylko praca.

Amplifa ICP Playbook — Praktyczny playbook, aby czysto zdefiniować docelowych klientów, źródła danych i priorytety, zanim AI w sprzedaży lub generowaniu leadów spali pieniądze.

FAQ: Kiedy średnia firma powinna sama budować AI?

Średnia firma powinna sama budować AI, gdy spełnione są jednocześnie trzy warunki: funkcja tworzy dyferencjację u klienta, niezbędne dane są zastrzeżone i wiarygodne, a firma może sfinansować eksploatację, monitoring i dalszy rozwój. Jeśli brakuje jednego z tych warunków, dopuściłbym Build tylko z partnerem i twardą linią stopu. Przykład: inteligentna diagnostyka stanu własnych maszyn z ekskluzywnymi danymi z czujników może uzasadniać Build. Standardowy chatbot do zapytań serwisowych — nie.

FAQ: Jaka jest najlepsza strategia AI dla 50 do 500 pracowników?

Dla firm zatrudniających od 50 do 500 pracowników najlepszym wyborem jest zazwyczaj strategia hybrydowa Buy-first. Standardowe oprogramowanie dla Use Cases typu Commodity, własna logika domenowa dla procesów dyferencjujących, mały wewnętrzny zespół rdzeniowy dla danych i odpowiedzialności za produkt. Brzmi to mniej heroicznie niż „budujemy własną platformę”. Działa częściej. Według Bitkom 2024 produktywne wykorzystanie AI w niemieckim sektorze MŚP jest wciąż niskie; właśnie dlatego Time-to-Value liczy się bardziej niż duma techniczna.

FAQ: Jak uniknąć pułapki PoC w przypadku AI?

Unika się jej dzięki kryteriom przerwania (Kill-Kriterien), zanim rozpocznie się pierwszy warsztat. Przykład: Jeśli rozwiązanie Vision AI po dwunastu tygodniach nie wykaże co najmniej o 10 procent lepszej wykrywalności w porównaniu z manualną próbką, zostaje zatrzymane lub przedefiniowane. Jeśli asystent ofertowania po sześciu miesiącach nie przyniesie mierzalnej oszczędności czasu, wylatuje z portfela. Brzmi twardo. Ale jest tańsze niż 18 miesięcy nadziei.

Rekomendacje działań: 7 kroków do decyzji Build-vs.-Buy

Jako prezes, CTO lub osoba odpowiedzialna za cyfryzację nie zaczynałbym od wyboru narzędzi. Ani od warsztatu AI, po którym na koniec 47 Use Cases wisi na karteczkach post-it i nikt nie wie, kto za nie zapłaci. Zrobiłbym siedem rzeczy. Dokładnie w tej kolejności.

1. Proszę zinwentaryzować możliwe Use Cases AI w produkcji, sprzedaży, serwisie i back-office. Przy każdym Use Case proszę dopisać wskaźnik: braki, przestój, czas oferty, konwersja, zapas, koszty reklamacji. Bez wskaźnika nie ma Use Case.
2. Proszę ocenić każdy Use Case za pomocą macierzy 2×2: potencjał dyferencjacji kontra standaryzowalność. Oceny należy dokonać w małym gronie z zarządem, działem merytorycznym i IT. Nie na warsztacie dla 18 osób.
3. Proszę zdefiniować zasadę Buy-first dla tematów Commodity. Forecasting, standardowa analiza tekstu, prosta Vision Inspection, automatyzacja CRM i Recommendation powinny stać się Build tylko wtedy, gdy istnieje pisemny powód biznesowy.
4. Proszę ustalić kryteria przerwania (Kill-Kriterien). Limit czasu, minimalne KPI, dostępność danych, akceptacja użytkowników. PoC bez linii stopu to nie eksperyment, lecz ryzyko kosztowe pod przyjazną nazwą.
5. Proszę zbudować mały zespół rdzeniowy. Dla 50 do 500 pracowników często wystarczy: jeden Data Engineer lub Analytics Engineer, silny Product Owner na każdy Use Case, architekt IT w niepełnym wymiarze godzin, zewnętrzni specjaliści na ograniczone fazy.
6. Proszę zintegrować AI z istniejącymi systemami. Żadnych izolowanych portali AI, jeśli użytkownicy pracują w ERP, CRM, MES, CPQ lub systemie zgłoszeniowym. AI musi pojawić się tam, gdzie i tak odbywa się praca.
7. Proszę raportować kwartalnie o produkcyjnych aplikacjach AI, a nie o PoC. Proszę pokazywać wpływ na biznes, wskaźnik użytkowników, koszty, otwarte ryzyka. CFO powinien rozumieć tabelę bez konieczności sprawdzania w Google, czym jest „Embedding”.

Produkt Amplifa — Automatyzacja sprzedaży wspierana przez AI dla zespołów B2B, które nie chcą traktować generowania leadów, doprecyzowania ICP i outreachu jako projektu do samodzielnego majsterkowania.

Governance: Kto decyduje, kto odpowiada, kto zatrzymuje?

Governance AI brzmi jak termin korporacyjny. To nie do końca prawda. Właśnie sektor MŚP go potrzebuje, ponieważ drogi są krótkie, a błędy szybko stają się osobiste. Jeśli AI zarekomenduje błędne zatwierdzenia jakości, temat nie trafi do anonimowej komisji ds. ryzyka. Trafi do Sabine w kontroli jakości, do Thomasa w inżynierii i do prezesa, gdy klient złoży reklamację.

Użyteczny ład (governance) dla 50 do 500 pracowników nie musi być obszerny. Potrzebuje czterech ról: Business Owner, Product Owner, osoba odpowiedzialna technicznie, audytor ds. ryzyka lub zgodności. Business Owner odpowiada za korzyść. Product Owner odpowiada za wykorzystanie i mapę drogową. Technika dba o czystość eksploatacji, bezpieczeństwo i przepływ danych. Compliance sprawdza ochronę danych, kwestie rady zakładowej, relewantność EU AI Act i audytowalność. Cztery nazwiska. Nie „dział IT”.

EU AI Act stanie się stopniowo bardziej odczuwalny od 2025 i 2026 roku, szczególnie w przypadku zastosowań wysokiego ryzyka. Wiele Use Cases w średnich firmach nie wpada do najwyższej klasy ryzyka, ale dokumentacja, przejrzystość i odpowiedzialność staną się ważniejsze. Kto dzisiaj wprowadza AI w decyzjach dotyczących jakości, procesach kadrowych lub krokach produkcyjnych bliskich bezpieczeństwu, nie powinien czekać, aż audytor stanie w holu.

Governance decyduje również o Build vs. Buy. Przy Buy muszą Państwo sprawdzić dostawcę: przetwarzanie danych, przejrzystość modelu, hosting, koncepcje usuwania, dostęp, logi audytowe. Przy Build muszą Państwo potrafić to wszystko sami. Szczerze? Wiele firm zatrudniających 200 osób tego nie potrafi. To nie zarzut. To kryterium decyzyjne.

Stos technologiczny: Czego naprawdę potrzebują średnie firmy

Jeśli Build lub Hybrid ma sens, nie potrzeba zoo technologicznego. Zbyt często widzę obrazy architektury z Databricks, Snowflake, Azure ML, MLflow, Airflow, Kafka, Kubernetes i pięcioma innymi logo, mimo że firma wciąż przesyła pliki CSV z ERP mailem. To nie jest strategia. To kolekcjonowanie logo.

Dla wielu średnich firm wystarczy jasny stos (stack): centralne składowanie danych lub Lakehouse, stabilne interfejsy do ERP/CRM/MES, narzędzie MLOps do wersjonowania modeli i monitoringu, koncepcja uprawnień, raportowanie. Azure jest silny w sektorze MŚP w regionie DACH, często ze względu na umowy Microsoft 365 i istniejące kompetencje IT. AWS SageMaker, GCP Vertex AI, Databricks, Snowflake, SAP AI Core czy Siemens Industrial Edge mogą pasować. Pytanie nie brzmi, które logo brzmi nowocześniej. Pytanie brzmi, kto to obsłuży.

Open Source nie jest darmowym posiłkiem. PyTorch, TensorFlow, scikit-learn, XGBoost, Hugging Face, MLflow — to wszystko dobre narzędzia. Ale ktoś musi dbać o zależności, sprawdzać aktualizacje bezpieczeństwa, monitorować modele, wykrywać dryf, naprawiać potoki. Na nocnej zmianie nikogo nie interesuje, czy błąd pochodzi z Feature Store, czy z interfejsu sterownika PLC. Linia stoi.

Przy Buy/Configure stos wygląda inaczej. Siemens Industrial Edge lub Insights Hub dla danych przemysłowych, PTC ThingWorx dla scenariuszy bliskich IoT, SAP AI Core i Joule w środowisku ERP, Microsoft Dynamics 365 z Copilot dla procesów CRM, Celonis dla Process Mining, o9 lub SAS dla planowania, Cognex lub Landing AI dla Vision. Te produkty nie rozwiązują każdego problemu, ale dają strukturę. Dla wielu średnich firm struktura to już połowa ROI.

Amplifa dla strategii sprzedaży AI — Dla średnich firm B2B, które chcą produktywnie wykorzystywać AI w sprzedaży, bez konieczności budowania własnej platformy outreach i danych.

Change Management: Hala współdecyduje

W grudniu 2024 roku byłem w zakładzie w pobliżu Pforzheim. 160 pracowników, części precyzyjne, dużo pracy ręcznej przy kontroli. Młody kierownik projektu objaśniał na monitorze wykrywanie błędów wspierane przez AI. Obok mnie stał kontroler, może pod sześćdziesiątkę, z czarnymi brzegami palców. Powiedział cicho: „Jeśli ta skrzynka się pomyli, to będzie moja wina”. To było najważniejsze zdanie tego dnia.

Wdrażanie AI rzadko zawodzi tylko przez technikę. Zawodzi przez odpowiedzialność. Jeśli ludzie wierzą, że AI zabierze im pracę, zrzuci na nich błędy lub zdewaluuje ich wiedzę doświadczalną, nie będą jej używać. Wtedy system będzie omijany, ostrzeżenia ignorowane, a dane źle utrzymywane. Change Management nie oznacza wieszania plakatów. Oznacza jasne wyjaśnienie ról, odpowiedzialności i korzyści.

Przy Vision AI w kontroli jakości musi być jasne: Czy AI zatwierdza, czy tylko rekomenduje? Kto decyduje w przypadkach granicznych? Jak traktowane są fałszywe negatywy? Jak informacja zwrotna od kontrolerów trafia do modelu? Przy asystencie ofertowania w sprzedaży musi być jasne: Czy AI może sugerować ceny? Kto sprawdza rabaty? Jakie wypowiedzi do klientów są tabu? Te pytania nie są hamulcami. Są warunkami eksploatacji.

Rada zakładowa powinna być włączona wcześnie, a nie po pilotażu. Szczególnie przy AI w pomiarze wydajności, planowaniu zmian, HR lub systemach asystenckich z danymi o użytkowaniu. Znam firmy, które straciły trzy miesiące, bo wierzyły, że partycypacja to akt formalny. Nie była. Była właściwym rolloutem.

Czego spodziewam się w 2026 roku: mniej teatru PoC, więcej twardej selekcji

Moja prognoza jest kanciasta: Do końca 2026 roku wielu średnich przedsiębiorców zredukuje swoje portfele AI o połowę. Nie dlatego, że AI rozczarowuje. Lecz dlatego, że listy projektów z lat 2023 i 2024 były zbyt szerokie, zbyt techniczne i źle skalkulowane. CFO zapyta, które aplikacje działają produkcyjnie. Sprzedaż zapyta, dlaczego asystent ofertowania nie jest jeszcze w CRM. Produkcja zapyta, dlaczego pilotaż działa tylko na linii nr 3. Wtedy nastąpi selekcja.

Jednocześnie dobre firmy przyspieszą. Nie będą śledzić 30 Use Cases, lecz pięć. Będą brać standardowe oprogramowanie tam, gdzie wystarcza, i budować własne know-how tam, gdzie boli, gdy konkurent też je ma. Nie będą „robić AI”. Będą obniżać braki, przyspieszać oferty, zwiększać przychody serwisowe, redukować zapasy. To inny ton.

CTO SAP, Jürgen Müller, wielokrotnie publicznie podkreślał integrację generatywnej AI z Business Suite. Przekaz dla sektora MŚP jest jasny: Nie każdy klient powinien budować własne Foundation Models. Wielu powinno konsumować AI, osadzać ją, kontrolować. Uważam to za zdrowe. Kto w 2026 roku wciąż wierzy, że firma zatrudniająca 250 osób musi najpierw założyć własne AI Lab, zanim zobaczy korzyści, myli średnie przedsiębiorstwo z instytutem badawczym.

Na koniec pozostaje scena z Gütersloh. Thomas, CTO z planem na 1,2 miliona euro, zadzwonił do mnie dwa tygodnie po naszej rozmowie. Zatrzymali pomysł na platformę, uruchomili dwa pilotaże Buy i zachowali jeden jedyny Use Case hybrydowy dla swojej logiki maszynowej. „Czuję się mniej wizjonersko”, powiedział. W tle znów usłyszałem piszczenie wózka widłowego. Być może właśnie to był postęp.