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

KI-Strategie · 23. Mai 2026 · Mohsen Ghulami

Strategia AI w średnich przedsiębiorstwach: Zdecyduj Build vs. Buy, opierając się na liczbach, przypadkach i jasnych kryteriach, zanim Twój budżet PoC zostanie pochłonięty.

Trzy tygodnie temu stoję w Gütersloh w sali konferencyjnej, która pachnie kawą filtrowaną i ciepłym plastikiem. Thomas, CTO producenta maszyn zatrudniającego 280 osób, podsuwa mi swojego iPada i mówi: „Teraz budujemy własną platformę AI”. Na podwórku piszczy cofający się wózek widłowy, w środku miga slajd PowerPoint z logo Azure, wężem Pythona i budżetem 1,2 miliona euro. Moje pierwsze pytanie nie było techniczne, ale brutalnie proste: Czy to naprawdę strategia AI – czy tylko kosztowna droga na skróty do kolejnego standardowego oprogramowania?

Od 1998 roku piszę o przemyśle. Widziałem w Trumpf w Ditzingen, jak dane z maszyn do cięcia laserowego stają się biznesem usługowym. Doświadczyłem w mniejszych firmach produkcyjnych na Szwabskiej Jurze, jak jeden brakujący eksport MES zatrzymuje cały projekt AI. I widziałem wystarczająco wielu CFO, którzy zaciskają usta na słowo „rozwój wewnętrzny”, jakby ugryźli cytrynę.

Build vs. Buy w AI nie jest więc kwestią wiary. To kwestia alokacji kapitału. Kto jako średnie przedsiębiorstwo zatrudniające od 50 do 500 pracowników chce samodzielnie budować każdy model prognozowania, marnuje czas, pensje i nerwy. Kto jednak kupuje każdą funkcję AI, mimo że to ona stanowi różnicę w jego własnym produkcie, oddaje marżę dostawcom, którzy nie rozumieją biznesu. Widziałem jedno i drugie. Obie opcje bolą.

Dlaczego strategia AI staje się teraz sprawą najwyższej wagi

W marcu 2025 roku był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 rozmawia o przyszłości, bo zamówienie musi być zrealizowane do piątku. „Mamy cztery PoC AI”, powiedziała Andrea. „Żaden nie działa produkcyjnie.”

Dokładnie w tym miejscu znajduje się średnie przedsiębiorstwo. Nie na początku debaty o AI, ale po pierwszym rozczarowaniu. ChatGPT otworzył drzwi w 2023 roku, Microsoft Copilot pojawił się w wielu firmach, SAP wprowadza funkcje AI do swojej pakietu, a co drugi dostawca oprogramowania przykleja etykietę AI do swojej mapy drogowej. Tylko: w hali, w sprzedaży, w serwisie dzieje się mniej, niż twierdzą sceny konferencyjne.

Liczby potwierdzają tę obserwację. Według badania Bitkom 2024, około 15 do 20 procent niemieckich firm produkcyjnie wykorzystuje AI; w firmach zatrudniających od 100 do 499 pracowników odsetek ten jest raczej niższy, około 10 do 15 procent. BCG i VDMA w 2023 roku w branży maszynowej doszły do wzorca, który ciągle słyszę w rozmowach: ponad 60 procent eksperymentuje z PoC AI, ale mniej niż 15 procent ma skalowane aplikacje w firmie. Czyli: dużo pilotażu, mało operacji.

To nie jest niemieckie prawo natury. Często to złe podejmowanie decyzji. Średnie przedsiębiorstwa zbyt często traktują AI jako zakup technologii, a zbyt rzadko jako kwestię tworzenia wartości. W firmie zatrudniającej 180 pracowników z Augsburga Jens, dyrektor handlowy, powiedział mi w styczniu 2025 roku: „Nie możemy sobie pozwolić na błąd”. Zgadza się. Ale brak decyzji to też błąd. Tylko cichszy.

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

Build nie oznacza, że trzech Data Scientistów w piwnicy trenuje model podstawowy. No, prawie nigdy. Build w średnich przedsiębiorstwach oznacza zazwyczaj: własne potoki danych, własne modele lub przynajmniej własną logikę domenową, własne procesy MLOps, własne monitorowanie, własną odpowiedzialność. Dostawca może dostarczyć infrastrukturę chmurową, ale firma ponosi ryzyko produktu i operacyjne.

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

Najostrzejsza granica nie przebiega między chmurą a on-prem. Przebiega między towarem a dyferencjacją. Prognozowanie, standardowe NLP, klasyfikacja obrazów, optymalizacja tras, asystent ofert, proste silniki rekomendacji – do tego istnieją użyteczne produkty. AI w rdzeniu produktu, na przykład inteligentne czujniki, autonomiczna nawigacja, zastrzeżone sterowanie procesami lub algorytm serwisowy, który uczy się z 15 lat danych maszynowych – tutaj 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 przedsiębiorstwa przeważnie wybierają Buy lub Configure, większe przedsiębiorstwa częściej wybierają Hybrid. Firma zatrudniająca 300 osób raczej kupuje Microsoft, SAP, Cognex, Celonis, o9, PTC lub wyspecjalizowanego dostawcę. Dostawca zatrudniający 3000 osób może zbudować Analytics Competence Center i rozwijać się tam, gdzie znajduje się wartość dodana. Brzmi banalnie. Mimo to jest to ciągle 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 swoje budżety AI prowadzą nie w komunikatach prasowych, ale w Excelu. Rozpiętości są zaskakująco stabilne. PoC Build w średnich przedsiębiorstwach kosztuje zazwyczaj od 100 000 do 300 000 euro na trzy do sześciu miesięcy. Zanim MVP zacznie działać produkcyjnie, realistyczne jest od 300 000 do 800 000 euro, przy czym wewnętrzne koszty personalne nie zawsze są dokładnie obliczane. I właśnie tam zaczyna się samooszukiwanie.

Ponieważ Data Scientist nie jest darmowy tylko dlatego, że jest już na liście płac. Inżynier produkcji, który co tydzień przez osiem godzin sprawdza etykiety, też nie. Architekt IT, który wyjaśnia zgody bezpieczeństwa, tym bardziej. W fabryce pod Ulm w lutym 2025 roku pachniało olejem chłodząco-smarującym, podczas gdy Martin, kierownik IT, powiedział mi: „Na zewnątrz wydaliśmy tylko 180 000 euro”. Dwie godziny później pokazał mi wewnętrzne oszacowanie nakładów. Z własnym wkładem projekt kosztował 520 000 euro.

Buy lub Configure zaczyna się niżej. Licencja pilotażowa plus integracja: często od 50 000 do 250 000 euro. Wdrożenie w kilku zakładach lub obszarach: od 150 000 do 800 000 euro. Bieżące koszty licencji dla wielu scenariuszy średnich przedsiębiorstw wynoszą od 50 000 do 200 000 euro rocznie, w zależności od użytkowników, wolumenu danych i nastroju dostawcy. Tak, nastroju dostawcy. Kto kiedykolwiek negocjował przedłużenie SaaS w trzecim roku umowy, wie, o czym mówię.

Wskaźniki sukcesu to prawdziwy cios. McKinsey w swoim raporcie State of AI 2023 poinformował, że tylko około 20 do 30 procent firm osiąga znaczące korzyści finansowe z projektów AI. W produkcji i dobrach przemysłowych, według mojego doświadczenia i benchmarków konsultantów, 50 do 70 procent PoC umiera, zanim zobaczą prawdziwe działanie. W przypadku Build często tylko 30 do 40 procent przechodzi do produkcji. W przypadku Buy lub Configure raczej 50 do 70 procent. Nie dlatego, że dostawcy czarują. Ale dlatego, że w modelu jest mniejsze ryzyko podstawowe.

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

Lubię rozwój wewnętrzny. Naprawdę. Jest ten moment, kiedy 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 „tym czymś AI”, ale o swoim nowym narzędziu. To jest mocne. Ale nie dzieje się to dlatego, że ktoś zainstalował PyTorch.

Trumpf jest dobrym przykładem, ale także 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, predykcyjne utrzymanie ruchu i funkcje Smart Factory. W publicznych prezentacjach Trumpf mówi o zmniejszeniu przestojów o 20 do 30 procent dzięki predykcyjnemu utrzymaniu ruchu w przypadku niektórych instalacji. To nie jest projekt poboczny z IT. To jest biznes produktowy i usługowy.

Kärcher z Winnenden jest podobnie interesujący. KIRA B 50, autonomiczny robot czyszczący, potrzebuje wizji komputerowej, nawigacji, fuzji czujników i solidnego oprogramowania w produkcie fizycznym. Standardowy rekomendator 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 jest w urządzeniu, w cenie, w umowie serwisowej.

Oto sedno: Build się opłaca, gdy AI zmienia wartość dla klienta lub odwzorowuje proces, którego konkurenci nie mogą łatwo skopiować. Producent obrabiarek z miliardami historycznych danych z czujników ma inną pozycję wyjściową niż hurtownik zatrudniający 220 osób, który chce poprawić sprzedaż krzyżową w sklepie internetowym. Kto zaciera te różnice, stawia sprawę na głowie.

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

— w wolnym tłumaczeniu za CDO niemieckiego producenta maszyn, rozmowa w Handelsblatt 2024

Nicole Büttner z Merantix Momentum w formatach EY dotyczących „Przyszłości Niemiec” podkreślała coś podobnego: średnie przedsiębiorstwa mają przewagę dzięki własnym danym, ale często powinny kupować modele i platformy, a logikę domenową opanować samodzielnie. Podpisuję się pod tym. Same dane to jeszcze nie fosa. Dopiero gdy dane, wiedza o procesach i kanał dystrybucji łączą 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 wcześniej w Fiege brał udział w projektach prognozowania. Siedzieliśmy w stołówce, pachniało sosem pieczeniowym, a z magazynu dochodził stłumiony odgłos taśmociągu. „Moglibyś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 prognozowania i optymalizacji. Opublikowane przypadki użycia mówią o redukcji zapasów o 2 do 5 procent i poprawie dokładności prognoz o 3 do 8 procent, w zależności od obszaru.

To jest rzeczywistość średnich przedsiębiorstw, tylko o jeden numer większa. Prognoza rzadko jest unikalna. Optymalizacja tras również nie. Wizyjna kontrola jakości z określoną klasą błędów jest technicznie wymagająca, ale często nie jest powodem do budowania własnego zespołu wizyjnego. 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 jasno pokazuje logikę. Producent maszyn, 800 pracowników, ręczna kontrola wizualna, niedobór personelu, wysoka presja na poprawki. Firma kupiła komercyjny system Vision-AI zamiast własnego rozwoju. Początkowa inwestycja: około 350 000 euro na sprzęt, licencje, integratora i szkolenie. Cztery miesiące PoC, trzy miesiące wdrożenia 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 innowacje. Ale pieniądze.

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

Druga prawda: Buy może stać się drogie, powolne 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 umiarkowane licencje za trzy narzędzia związane z AI w sprzedaży, serwisie i planowaniu. Razem z interfejsami, doradztwem i wewnętrznymi administratorami roczne koszty nagle wyniosły 310 000 euro. Korzyści? Trudne do zmierzenia. „Mamy teraz pulpity nawigacyjne”, powiedział szef sprzedaży. Współczułem mu.

Największym błędem w strategii Buy jest ślepa wiara w funkcjonalność. Demonstracja oprogramowania zawsze pokazuje czyste dane. Zawsze. W prawdziwym działaniu pojawiają się podwójne bazy klientów, brakujące hierarchie artykułów, różne modele zmian i pole ERP o nazwie „Inne”, które od 2009 roku zawiera wszystko, czego nikt nie chciał kategoryzować. SAP, Microsoft, Siemens czy PTC mogą wiele złagodzić. Ale nie naprawią organizacji, która gardzi swoimi danymi podstawowymi.

Drugim błędem jest lock-in bez wartości dodanej. Jeśli 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 przypadek użycia jest towarem, a dostawca stabilnie dostarcza. W przypadku krytycznych procesów podstawowych należy być bardziej ostrożnym. Eksport danych, możliwość audytu, koszty skalowania, scenariusz wyjścia – nudne tematy, tak. Właśnie dlatego są czytane zbyt późno.

Gdzie umierają projekty Build w średnich przedsiębiorstwach

Jest scena, która się powtarza. Sala konferencyjna, szary dywan, tablica z resztkami warsztatu, gdzieś jeszcze wisi „Priorytetyzacja przypadków użycia”. W pomieszczeniu siedzą IT, dział specjalistyczny i zewnętrzny konsultant. Po 14 miesiącach 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. Nieseksowna, ale śmiertelna. Dostawca z branży motoryzacyjnej zatrudniający około 3000 pracowników rozpoczął w ciągu trzech lat kilka PoC predykcyjnego utrzymania ruchu, wspólnie z instytutem badawczym. Nakład: ponad milion euro, wliczając czas wewnętrzny. Wszystkie pilotaże utknęły w pojedynczych instalacjach. OT i IT były oddzielone, nie było centralnego lakehouse, utrzymanie ruchu było późno zaangażowane, a historia danych nie pasowała do logiki awarii. Po zmianie kierownictwa IT, przestawiono się na standardową platformę. Dziewięć miesięcy później uruchomiono pierwsze produkcyjne przypadki użycia, po 18 miesiącach zgłoszono około 15 procent mniej nieplanowanych awarii na wybranych instalacjach.

Drugą przyczyną śmierci jest fałszywa duma. Hurtownik B2B z regionu DACH zatrudniający około 1200 pracowników chciał zbudować własny silnik rekomendacji, również w celu zmniejszenia zależności od platform chmurowych z USA. Pięcioosobowy zespół Data Science, Python, Scikit-Learn, później TensorFlow. Osiemnaście miesięcy rozwoju, około 1 do 1,5 miliona euro. Ostatecznie wydajność po wewnętrznych testach wynosiła tylko 60 do 70 procent standardowego rekomendatora chmurowego. Projekt został zatrzymany, rozwiązanie SaaS i tak się pojawiło. Tylko później i drożej.

Trzecią przyczyną śmierci jest brak myślenia produktowego. AI jest uruchamiana jako projekt, a nie prowadzona jako produkt. Jest PoC, raport końcowy, aplauz w komitecie sterującym. Potem model dryfuje, nikt nie mierzy wskaźnika użytkowników, nikt nie planuje ponownego szkolenia, nikt nie czuje się odpowiedzialny za fałszywe alarmy. Po sześciu miesiącach kierownik zmiany mówi: „To coś szaleje”. I już akceptacja znika.

MLOps to tutaj nie buzzword, ale praca konserwatora dla modeli. Monitorowanie, wersjonowanie danych, procesy zatwierdzania, rollback, odpowiedzialności, ścieżka audytu. Brzmi sucho. I takie jest. Ale bez tych rutyn AI staje się oprogramowaniem jednorazowego użytku. Buduje się, pokazuje, zapomina.

Macierz Build-vs.-Buy dla wiarygodnej strategii AI

W rozmowach lubię używać prostej macierzy 2x2. Bez magii. Na osi X znajduje się potencjał różnicowania: Czy ta funkcja AI sprawi, że będziemy trudniejsi do skopiowania na rynku? Na osi Y znajduje się standaryzacja: 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.

Pierwszy kwadrant: wysoki potencjał różnicowania, niska standaryzacja. Tutaj można poważnie rozważyć Build lub Co-Build. Przykłady: AI w urządzeniu medycznym ze specjalnymi czujnikami, autonomiczne funkcje w maszynie czyszczącej, sterowanie procesami w własnym procesie produkcyjnym. Kärcher, Trumpf, Wittenstein czy Festo myślą w takich kategoriach. Tam AI jest blisko produktu lub tajemnicy procesu.

Drugi kwadrant: niski potencjał różnicowania, wysoka standaryzacja. Kupić. Kropka. Standardowe prognozowanie, klasyfikacja tekstu w obsłudze klienta, proste chatboty, kontrola wydatków, punktacja leadów, kontrola obrazu ze znanymi wzorcami błędów. Kto tutaj głosi Build, powinien położyć na stół koszty alternatywne. Nie jako slajd. Jako kwotę w euro.

Trzeci kwadrant: wysoki potencjał różnicowania, wysoka standaryzacja. To jest ekscytujący obszar hybrydowy. LLM może generować projekty ofert, ale własna logika produktu, zasady rabatów, zdolność dostaw i klauzule odpowiedzialności muszą pochodzić z firmy. Microsoft Copilot lub SAP Joule mogą dostarczyć interfejsy, ale mózg biznesowy leży w własnym modelu danych. Właśnie tam średnie przedsiębiorstwa powinny budować kompetencje.

Czwarty kwadrant: niski potencjał różnicowania, niska standaryzacja. Zazwyczaj sygnał ostrzegawczy. Jeśli coś nie jest ani strategicznie ważne, ani łatwe do kupienia, dlaczego miałoby to być robione? Bo chce tego kierownik działu? Bo program dotacyjny kusi? Pieniądze z dotacji to nie jest biznesplan. Tutaj mysz nie przegryzie nici.

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

W czerwcu 2025 roku zadzwonił do mnie dyrektor zarządzający z Ravensburga. 120 pracowników, budowa maszyn specjalnych, przyzwoity EBIT, ale słabe IT. Zapytał: „Ile będzie nas kosztować AI do automatyzacji ofert?” Odpowiedziałem: „Ile kosztuje oferta dzisiaj?” Cisza. Potem szelest kartek. Następnie liczba: około 1800 euro wewnętrznych kosztów w przypadku złożonych maszyn, gdy zaangażowane są sprzedaż, konstrukcja i zakupy.

Dopiero z takimi liczbami Build vs. Buy staje się namacalne. Jeśli firma pisze 900 złożonych ofert rocznie, a system asystujący AI skraca czas realizacji o 25 procent, nie mówimy o zabawie. Mówimy o wydajności, szybszej reakcji, mniejszej liczbie błędów w listach materiałowych, lepszym śledzeniu. To, czy rozwiązanie jest kupowane, budowane czy hybrydowe, decyduje się wtedy na podstawie zwrotu, a nie na podstawie intuicji CTO.

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

Budowa maszyn jest kusząca dla Build. Firmy mają techniczną pewność siebie, wielu inżynierów, dobre dane produktowe i często kulturę samodzielnego działania. W DMG Mori, Trumpf, Wittenstein czy Festo takie podejście ma sens w funkcjach AI bliskich produktowi. W przypadku producenta instalacji zatrudniającego 180 osób z Górnej Frankonii, który chce zbudować własną AI tekstową do raportów serwisowych, raczej nie. Zapach oleju hydraulicznego nie czyni modelu NLP zastrzeżonym.

Handel i dystrybucja B2B powinny prawie zawsze myśleć w kategoriach Buy-first. Rekomendacje, wyceny, prognozowanie zapasów, klastry klientów, sterowanie kampaniami – to obszary z wieloma dostawcami i dużym doświadczeniem. Różnicowanie leży tam mniej w algorytmie, a bardziej w jakości danych, logice asortymentu, warunkach zakupu i realizacji sprzedaży. Sprzedawca z Essen powiedział mi w kwietniu 2025 roku: „Chcieliśmy sami odtworzyć logikę Amazona”. Zapytałem: „Dlaczego najpierw nie sprzedawać jak Amazon?” Nie zaśmiał się.

Logistyka jest bardziej pragmatyczna. Może dlatego, że każdy procent natychmiast przekłada się tam na palety, kilometry i harmonogramy 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 dla specjalnych danych sieciowych i planowania dostosowanego do klienta. Podłoga hali decyduje. Nie dział strategii.

Dostawcy motoryzacyjni siedzą między dwoma krzesłami. Mają wolumen, presję jakościową, wymagania dotyczące identyfikowalności i wytyczne OEM. Predykcyjna jakość, utrzymanie ruchu, kontrola wizualna i AI planistyczna są atrakcyjne. Ale wiele zakładów rozwijało się historycznie, dane OT są fragmentaryczne, a rada zakładowa chce być wcześnie pytana. Kto tam rozpoczyna Build bez platformy danych, ląduje w bagnie PoC. Widziałem to zbyt często.

Praktyczny przykład: 320 pracowników, 14 miesięcy, uczciwa hybryda

Przypadek, który mogę opowiedzieć anonimowo: producent komponentów z Badenii-Wirtembergii, 320 pracowników, obroty prawie 75 milionów euro, klienci z branży maszynowej i 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 frezowane części w szarych tacach. Sabine, kierowniczka jakości, powiedziała: „Tracimy czas, bo zbyt późno zauważamy błędy.”

Firma miała trzy pomysły na AI: Vision AI do kontroli jakości, prognozowanie w zakupach, asystent ofert dla części specjalnych. Wcześniej prawdopodobnie uruchomiono by trzy PoC. Tym razem nie. Dyrektor zarządzający przepuścił każdy pomysł przez macierz. Vision AI: Buy. Prognozowanie: Buy/Configure. Asystent ofert: Hybryda, ponieważ logika wykonalności technicznej i zasady wariantów były naprawdę wewnętrzne.

Liczby po 14 miesiącach: Pilot Vision-AI dla dwóch rodzin części kosztował około 210 000 euro, wliczając kamerę, oświetlenie, integratora i szkolenie. Błędy spadły o 28 procent, poprawki o 11 procent. Prognozowanie zostało wprowadzone za pomocą modułu istniejącego partnera ERP plus zewnętrznego potoku danych, koszt około 95 000 euro; dokładność prognoz w częściach A wzrosła o 6 punktów procentowych. Asystent ofert kosztował więcej: około 380 000 euro, ponieważ zintegrowano CPQ, zasady zbliżone do CAD i historie cen. Dzięki temu średni czas realizacji złożonych ofert spadł z 9,5 do 6,8 dni roboczych.

Ważniejsza niż pojedyncze liczby była ład korporacyjny. Był Product Owner dla każdego przypadku użycia, miesięczny przegląd KPI, jasne kryteria zakończenia i mały rdzeń danych: inżynier danych, inżynier analityk, zewnętrzny architekt na sześć miesięcy. Żadne laboratorium AI z pufami. Żaden cyrk innowacji. Tylko praca.

Amplifa ICP Playbook Praktyczny playbook do precyzyjnego definiowania klientów docelowych, źródeł danych i priorytetów, zanim AI w sprzedaży lub generowaniu leadów pochłonie pieniądze.

FAQ: Kiedy średnie przedsiębiorstwo powinno samodzielnie budować AI?

Średnie przedsiębiorstwo powinno samodzielnie budować AI, jeśli jednocześnie spełnione są trzy warunki: funkcja tworzy różnicowanie u klienta, niezbędne dane są zastrzeżone i wiarygodne, a firma może finansować działanie, monitorowanie i dalszy rozwój. Jeśli brakuje jednego z tych warunków, dopuściłbym Build tylko z partnerem i twardą linią zatrzymania. 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 firm zatrudniających od 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 do zastosowań ogólnych, własna logika domenowa do procesów różnicujących, mały wewnętrzny zespół do 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 niemieckich średnich przedsiębiorstwach jest nadal niskie; dlatego właśnie czas do wartości jest ważniejszy niż duma techniczna.

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

Unika się jej, ustalając kryteria zakończenia, zanim rozpocznie się pierwszy warsztat. Przykład: Jeśli rozwiązanie Vision-AI po dwunastu tygodniach nie wykaże co najmniej 10 procent lepszej detekcji w porównaniu z ręczną próbą, zostanie zatrzymane lub przeprojektowane. Jeśli asystent ofert po sześciu miesiącach nie przyniesie mierzalnych oszczędności czasu, zostanie usunięty z portfolio. Brzmi twardo. Ale jest tańsze niż 18 miesięcy nadziei.

Zalecenia dotyczące działania: 7 kroków do decyzji Build-vs.-Buy

Jako dyrektor zarządzający, CTO lub osoba odpowiedzialna za cyfryzację nie zaczynałbym od wyboru narzędzi. Ani od warsztatu AI, na którym na końcu 47 przypadków użycia 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. Zainwentaryzuj możliwe przypadki użycia AI w produkcji, sprzedaży, serwisie i back office. Do każdego przypadku użycia dopisz wskaźnik: odpady, przestoje, czas realizacji oferty, konwersja, zapasy, koszty reklamacji. Bez wskaźnika nie ma przypadku użycia.
2. Oceń każdy przypadek użycia za pomocą macierzy 2x2: potencjał różnicowania w stosunku do standaryzacji. Przeprowadź ocenę w małym gronie z zarządem, działem specjalistycznym i IT. Nie na warsztacie dla 18 osób.
3. Zdefiniuj zasadę Buy-first dla tematów ogólnych. Prognozowanie, standardowa analiza tekstu, prosta inspekcja wizyjna, automatyzacja CRM i rekomendacje powinny być budowane tylko wtedy, gdy istnieje pisemne uzasadnienie biznesowe.
4. Ustal kryteria zakończenia. Limit czasu, minimalny KPI, dostępność danych, akceptacja użytkowników. PoC bez linii zatrzymania to nie eksperyment, ale ryzyko kosztowe o przyjaznej nazwie.
5. Zbuduj mały zespół podstawowy. Dla firm zatrudniających od 50 do 500 pracowników często wystarczy: inżynier danych lub inżynier analityk, silny Product Owner dla każdego przypadku użycia, architekt IT w częściowym wymiarze godzin, zewnętrzni specjaliści na ograniczone fazy.
6. Zintegruj AI z istniejącymi systemami. Żadnych izolowanych portali AI, jeśli użytkownicy pracują w ERP, CRM, MES, CPQ lub systemie zgłoszeń. AI musi pojawić się tam, gdzie praca i tak się odbywa.
7. Raportuj kwartalnie o produktywnych zastosowaniach AI, a nie o PoC. Pokaż wpływ biznesowy, wskaźnik użytkowników, koszty, otwarte ryzyka. CFO powinien rozumieć tabelę, nie musząc googlować „embeddingu”.

Produkt Amplifa Automatyzacja sprzedaży oparta na AI dla zespołów B2B, które nie chcą budować generowania leadów, doskonalenia ICP i działań outbound jako projektu hobbystycznego.

Zarządzanie: Kto decyduje, kto odpowiada, kto zatrzymuje?

Zarządzanie AI brzmi jak korporacja. Nie do końca. Zwłaszcza średnie przedsiębiorstwa potrzebują go, ponieważ drogi są krótkie, a błędy szybko stają się osobiste. Jeśli AI zaleca błędne zatwierdzenia jakości, temat nie trafia do anonimowego komitetu ryzyka. Trafia do Sabine w dziale kontroli jakości, do Thomasa w inżynierii i do dyrektora zarządzającego, gdy klient zgłasza reklamację.

Użyteczne zarządzanie dla firm zatrudniających od 50 do 500 pracowników nie musi być obszerne. Potrzebuje czterech ról: właściciela biznesowego, właściciela produktu, osoby odpowiedzialnej technicznie, kontrolera ryzyka lub zgodności. Właściciel biznesowy odpowiada za korzyści. Właściciel produktu odpowiada za wykorzystanie i mapę drogową. Technika utrzymuje działanie, bezpieczeństwo i przepływ danych w czystości. Zgodność sprawdza ochronę danych, kwestie rady zakładowej, istotność EU-AI-Act i możliwość audytu. Cztery nazwiska. Nie „IT”.

EU AI Act będzie stopniowo odczuwalny od 2025 i 2026 roku, szczególnie w przypadku zastosowań wysokiego ryzyka. Wiele przypadków użycia w średnich przedsiębiorstwach nie należy do najwyższej klasy ryzyka, ale dokumentacja, przejrzystość i odpowiedzialność staną się ważniejsze. Kto dziś wprowadza AI do decyzji jakościowych, procesów personalnych lub kroków produkcyjnych związanych z bezpieczeństwem, nie powinien czekać, aż audytor stanie w holu.

Zarządzanie decyduje również o Build vs. Buy. W przypadku Buy musisz sprawdzić dostawcę: przetwarzanie danych, przejrzystość modelu, hosting, koncepcje usuwania, dostęp, logi audytu. W przypadku Build musisz to wszystko umieć sam. Szczerze? Wiele firm zatrudniających 200 osób nie potrafi. To nie jest zarzut. To kryterium decyzyjne.

Stos technologiczny: Czego naprawdę potrzebują średnie przedsiębiorstwa

Jeśli Build lub Hybrid ma sens, nie potrzebujesz zoo technologicznego. Zbyt często widzę schematy architektury z Databricks, Snowflake, Azure ML, MLflow, Airflow, Kafka, Kubernetes i pięcioma innymi logo, chociaż firma nadal wysyła pliki CSV z ERP pocztą elektroniczną. To nie jest strategia. To zbieranie logo.

Dla wielu średnich przedsiębiorstw wystarczy jasny stos: centralne przechowywanie danych lub lakehouse, stabilne interfejsy do ERP/CRM/MES, narzędzie MLOps do wersjonowania i monitorowania modeli, koncepcja uprawnień, raportowanie. Azure jest silny w średnich przedsiębiorstwach 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 lub Siemens Industrial Edge mogą pasować. Pytanie nie brzmi, które logo brzmi nowocześniej. Pytanie brzmi, kto je obsługuje.

Open Source to nie darmowe jedzenie. PyTorch, TensorFlow, scikit-learn, XGBoost, Hugging Face, MLflow – to wszystko dobre narzędzia. Ale ktoś musi zarządzać zależnościami, sprawdzać aktualizacje bezpieczeństwa, monitorować modele, wykrywać dryf, naprawiać potoki. Na nocnej zmianie nikogo nie obchodzi, czy błąd pochodzi z Feature Store czy z interfejsu PLC. Linia stoi.

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

Amplifa dla strategii sprzedaży AI Dla średnich przedsiębiorstw B2B, które chcą produktywnie wykorzystywać AI w sprzedaży, bez konieczności budowania własnej platformy do działań outbound i danych.

Zarządzanie zmianą: Hala decyduje

W grudniu 2024 roku byłem w firmie niedaleko Pforzheim. 160 pracowników, części precyzyjne, dużo pracy ręcznej przy kontroli. Młody kierownik projektu wyjaśniał na monitorze system wykrywania błędów wspomagany AI. Obok mnie stał kontroler, może po pięćdziesiątce, z czarnymi palcami. Powiedział cicho: „Jeśli maszyna się pomyli, to moja wina.” To było najważniejsze zdanie tego dnia.

Wprowadzanie AI rzadko kończy się niepowodzeniem tylko z powodu techniki. Kończy się niepowodzeniem z powodu odpowiedzialności. Jeśli ludzie wierzą, że AI zabiera im pracę, przypisuje błędy lub dewaluuje ich wiedzę ekspercką, nie będą jej używać. Wtedy system jest omijany, ostrzeżenia są ignorowane, dane są źle zarządzane. Zarządzanie zmianą nie oznacza wieszania plakatów. Oznacza jasne określenie ról, odpowiedzialności i korzyści.

W przypadku 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 opinie kontrolerów wpływają na model? W przypadku asystenta ofert w sprzedaży musi być jasne: Czy AI może proponować ceny? Kto sprawdza rabaty? Jakie stwierdzenia wobec klientów są tabu? Te pytania nie są hamulcami. Są warunkami działania.

Rada zakładowa powinna być włączona wcześnie, a nie po pilotażu. Zwłaszcza w przypadku AI w pomiarach wydajności, planowaniu zmian, HR lub systemach wspomagających z danymi użytkowymi. Znam firmy, które straciły trzy miesiące, ponieważ wierzyły, że uczestnictwo to formalność. Nie było. Było to faktyczne wdrożenie.

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

Moja prognoza jest ostra: Do końca 2026 roku wiele średnich przedsiębiorstw zmniejszy swoje portfele AI o połowę. Nie dlatego, że AI zawodzi. Ale dlatego, że listy projektów z 2023 i 2024 roku były zbyt szerokie, zbyt techniczne i zbyt słabo obliczone. CFO zapyta, które aplikacje działają produkcyjnie. Dział sprzedaży zapyta, dlaczego asystent ofert nie jest jeszcze w CRM. Produkcja zapyta, dlaczego pilot działa tylko na linii 3. Wtedy nastąpi selekcja.

Jednocześnie dobre firmy będą działać szybciej. Nie będą śledzić 30 przypadków użycia, ale pięć. Będą używać standardowego oprogramowania tam, gdzie wystarcza, i budować własne know-how tam, gdzie boli, jeśli konkurent też je ma. Nie będą „robić AI”. Będą zmniejszać odpady, przyspieszać oferty, zwiększać przychody z usług, redukować zapasy. To inny ton.

CTO SAP, Jürgen Müller, wielokrotnie publicznie podkreślał integrację generatywnej AI z pakietem Business Suite. Przesłanie dla średnich przedsiębiorstw jest jasne: Nie każdy klient powinien budować własne modele podstawowe. Wielu powinno konsumować, osadzać i kontrolować AI. Uważam to za zdrowe. Kto w 2026 roku nadal wierzy, że firma zatrudniająca 250 osób musi najpierw założyć własne laboratorium AI, 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ł platformy, uruchomili dwa pilotaże Buy i zachowali jeden hybrydowy przypadek użycia dla swojej logiki maszynowej. „Czuje się mniej wizjonersko”, powiedział. W tle znowu słyszałem piszczenie wózka widłowego. Może właśnie to był postęp.