Strategie AI · 23. května 2026 · 24 min. čtení · Mohsen Ghulami, GTM Engineer, Amplifa
Strategie AI: Build vs. Buy ve středně velkých podnicích
Strategie AI ve středně velkých podnicích: Rozhodujte o Build vs. Buy na základě čísel, případů a jasných kritérií, než Váš PoC pohltí rozpočet.
Před třemi týdny stojím v Güterslohu v jednací místnosti, která voní po překapávané kávě a teplém plastu. Thomas, CTO strojírenské firmy s 280 lidmi, mi podává svůj iPad a říká: „Teď si stavíme vlastní platformu AI.“ Na dvoře pípá couvající vysokozdvižný vozík, uvnitř bliká PowerPointový snímek s logem Azure, hadem Python a rozpočtovým blokem 1,2 milionu eur. Moje první otázka nebyla technická, ale brutálně jednoduchá: Je to skutečně strategie AI — nebo jen drahá oklika k dalšímu standardnímu softwaru?
O průmyslu píšu od roku 1998. Viděl jsem u firmy Trumpf v Ditzingenu, jak se data z laserových řezacích strojů mění v servisní byznys. U menších zakázkových výrobců ve Švábské Albě jsem zažil, jak jediný chybějící export z MES zastaví celý projekt AI. A viděl jsem dost CFO, kteří při slově „vlastní vývoj“ sevřou rty, jako by kousli do citronu.
Build vs. Buy u AI proto není otázkou víry. Je to otázka alokace kapitálu. Kdo jako středně velký podnikatel s 50 až 500 zaměstnanci chce každý model pro forecasting stavět sám, spaluje čas, platy a nervy. Kdo ale každou funkci AI dokupuje, i když právě ona tvoří rozdíl v jeho vlastním produktu, daruje marži dodavatelům, kteří jeho byznysu nerozumí. Viděl jsem obojí. Obojí bolí.
Proč se strategie AI stává prioritou vedení
V březnu 2025 jsem seděl u dodavatele poblíž Heilbronnu, 410 zaměstnanců, hodně obrábění, málo trpělivosti. Andrea, Head of Operations, mi ukázala linku se šesti obráběcími centry od DMG Mori. Zvuk byl ten tvrdý, kovový zpěv, který znáte z hal, kde nikdo nemluví o budoucnosti, protože zakázka musí být do pátku hotová. „Máme čtyři PoC AI,“ řekla Andrea. „Žádný neběží produktivně.“
Přesně tam se střední stav nachází. Ne na začátku debaty o AI, ale po prvním vystřízlivění. ChatGPT v roce 2023 rozrazil dveře, Microsoft Copilot dorazil do mnoha firem, SAP tlačí funkce AI do své sady a každý druhý dodavatel softwaru mezitím lepí nálepku AI na svou roadmapu. Jenže: v hale, v prodeji, v servisu se děje méně, než tvrdí konferenční pódia.
Čísla tomuto pozorování odpovídají. Podle studie Bitkom 2024 využívá AI produktivně přibližně 15 až 20 procent německých firem; u firem mezi 100 a 499 zaměstnanci se kvóta pohybuje spíše v dolní oblasti, zhruba 10 až 15 procent. BCG a VDMA dospěly v roce 2023 ve strojírenství ke vzorci, který v rozhovorech slyším neustále: Více než 60 procent experimentuje s PoC AI, ale méně než 15 procent má ve firmě škálované aplikace. Tedy: hodně pilotů, málo provozu.
To není žádný německý přírodní zákon. Často je to špatné rozhodování. Středně velké firmy zacházejí s AI příliš často jako s nákupem technologie a příliš zřídka jako s otázkou tvorby hodnoty. V podniku se 180 zaměstnanci z Augsburgu mi Jens, obchodní ředitel, v lednu 2025 řekl: „Nemůžeme si dovolit chybu.“ Pravda. Ale nerozhodnutí je také chyba. Jen tišší.
Strategie AI ve středně velkých podnicích: Co Build vs. Buy skutečně znamená
Build neznamená, že tři Data Scientists ve sklepě trénují Foundation Model. No, skoro nikdy. Build ve středně velkém podniku většinou znamená: vlastní datové pipeline, vlastní modely nebo alespoň vlastní doménovou logiku, vlastní procesy MLOps, vlastní monitoring, vlastní odpovědnost. Dodavatel možná dodá cloudovou infrastrukturu, ale firma nese produktové a provozní riziko.
Buy neznamená, že si koupíte software a v pondělí ušetříte 15 procent zmetků. Kdo tomu věří, nikdy neviděl rozhraní mezi starým ERP, exportem z Excelu a řízením stroje. Buy znamená: nakoupit standardní software, SaaS nebo platformové moduly, konfigurovat je, integrovat, školit, měřit. To je práce. Ale je to jiná práce než stavba modelu.
Nejostřejší hranice nevede mezi cloudem a on-prem. Vede mezi komoditou a diferenciací. Forecasting, standardní NLP, klasifikace obrazu, optimalizace tras, asistence při tvorbě nabídek, jednoduché Recommendation Engines — pro to existují použitelné produkty. AI v jádru produktu, například inteligentní senzorika, autonomní navigace, proprietární řízení procesů nebo servisní algoritmus, který se učí z 15 let dat o strojích — tam může mít Build smysl. Může. Nemusí.
PwC a Roland Berger popisují od roku 2023 vzorec, který se objevuje i v mých rozhovorech: menší a střední podniky volí převážně Buy nebo Configure, větší středně velké podniky volí častěji Hybrid. Podnik o 300 lidech spíše koupí Microsoft, SAP, Cognex, Celonis, o9, PTC nebo specializovaného dodavatele. Dodavatel o 3 000 lidech možná vybuduje Analytics Competence Center a vyvíjí tam, kde spočívá tvorba hodnoty. Zní to banálně. Přesto se to neustále ignoruje.
Tvrdá čísla: Náklady, časové osy, míry úspěšnosti
V uplynulých dvou letech jsem v Mnichově, Stuttgartu, Bielefeldu a Linci mluvil s digitálními manažery, kteří své rozpočty na AI nespravují v tiskových zprávách, ale v Excelu. Rozpětí jsou překvapivě stabilní. Build-PoC se ve středně velkém podniku pohybuje většinou mezi 100 000 až 300 000 € za tři až šest měsíců. Než začne produktivně běžet MVP, je realistických 300 000 až 800 000 €, přičemž interní osobní náklady nejsou vždy čistě započteny. A právě tam začíná sebeklam.
Protože Data Scientist není zdarma jen proto, že už je na výplatní listině. Výrobní inženýr, který každý týden osm hodin kontroluje labely, také ne. IT architektka, která řeší bezpečnostní schválení, už vůbec ne. V jednom závodě u Ulmu to v únoru 2025 vonělo po chladicí emulzi, zatímco mi Martin, vedoucí IT, říkal: „Externě jsme utratili jen 180 000 €.“ O dvě hodiny později mi ukázal interní odhad nákladů. S vlastní prací byl projekt na 520 000 €.
Buy nebo Configure začíná níže. Pilotní licence plus integrace: často 50 000 až 250 000 €. Rollout přes více závodů nebo oblastí: 150 000 až 800 000 €. Průběžné licenční náklady se u mnoha středně velkých scénářů pohybují mezi 50 000 až 200 000 € ročně, v závislosti na uživatelích, objemu dat a náladě dodavatele. Ano, náladě dodavatele. Kdo už někdy ve třetím roce smlouvy vyjednával o prodloužení SaaS, ví, o čem mluvím.
Míry úspěšnosti jsou skutečnou ranou pod pás. McKinsey ve zprávě State of AI 2023 uvedl, že pouze asi 20 až 30 procent firem dosahuje z projektů AI významných finančních výhod. Ve výrobě a průmyslovém zboží podle mých zkušeností a podle benchmarků poradců umírá 50 až 70 procent PoC dříve, než uvidí skutečný provoz. U Build zvládne skok do produkce často jen 30 až 40 procent. U Buy nebo Configure spíše 50 až 70 procent. Ne proto, že by dodavatelé čarovali. Ale proto, že v modelu je méně základního rizika.
| Bod rozhodování | Build: typická realita | Buy/Configure: typická realita | Zdroj nebo pozorování |
|---|---|---|---|
| Náklady na PoC | 100 000–300 000 € za 3–6 měsíců | 50 000–250 000 € za pilot a integraci | Benchmarky poradců DACH 2023–2025 |
| MVP až Rollout | 300 000–800 000 € plus interní časy | 150 000–800 000 € u více oblastí | Rozpětí projektů z rozhovorů ve středních firmách 2024/2025 |
| Time-to-Value | 9–18 měsíců k měřitelnému dopadu na byznys | 3–9 měsíců k prvním efektům | Vzorce PwC/Roland-Berger, potvrzeno v praxi |
| PoC do produkce | 30–40 % dosáhne stabilního provozu | 50–70 % dosáhne stabilního provozu | Průmyslové benchmarky, výroba a B2B |
| Interní potřeba | Data Engineering, MLOps, Product Owner, odborné oddělení | IT, odborné oddělení, integrátor, Vendor Management | Zkušenosti z projektů ve strojírenství a logistice |
| Strategický přínos | Vysoký, pokud AI posiluje klíčový produkt nebo procesní tajemství | Vysoký, pokud má standardní problém přinést rychlý účinek | Odvozeno z případů Trumpf, Kärcher, Fiege |
Build se vyplatí — ale méně často, než tvrdí slajdy startupů
Mám rád vlastní vývoj. Skutečně. Existuje ten moment, kdy tým model nejen vytrénuje, ale vloží ho do procesu, uživatelé si na něj sáhnou, KPI se pohne a vedoucí závodu už nemluví o „té věci s AI“, ale o svém novém nástroji. To je silné. Jenže se to neděje proto, že někdo nainstaloval PyTorch.
Trumpf je dobrým příkladem, ale také varováním. Rodinná firma z Ditzingenu má kolem 16 500 zaměstnanců, hluboká data o strojích, vlastní historii platforem s AXOOM a ekosystém kolem TruConnect. Od roku 2017 Trumpf kontinuálně investuje do digitálních služeb, Predictive Maintenance a funkcí Smart-Factory. Ve veřejných prezentacích Trumpf u určitých zařízení hovoří o snížení prostojů až o 20 až 30 procent díky prediktivní údržbě. To není vedlejší projekt z IT. To je produktový a servisní byznys.
Kärcher z Winnendenu je podobně zajímavý. KIRA B 50, autonomní čisticí robot, potřebuje Computer Vision, navigaci, fúzi senzorů a robustní software ve fyzickém produktu. Standardní Recommender z cloudu tam moc nepomůže. Kärcher od roku 2018 buduje digitální kompetence, mimo jiné v Digital Hub, a spojuje vlastní vývoj s cloudovými moduly. Zde není Build prestiží. AI je v zařízení, v ceně, v servisní smlouvě.
To je ten bod: Build se vyplatí, pokud AI mění přínos pro zákazníka nebo zobrazuje proces, který konkurenti nemohou snadno zkopírovat. Výrobce obráběcích strojů s miliardami historických dat ze senzorů má jinou výchozí pozici než velkoobchodník s 220 lidmi, který chce zlepšit Cross-Selling v e-shopu. Kdo tyto rozdíly stírá, staví dům od střechy.
Sami vyvíjíme pouze tam, kde vidíme jasnou konkurenční výhodu a kde jsou naše znalosti procesů nebo produktů jedinečné. Standardní Analytics a jazykové modely dokupujeme.
— volně podle CDO jednoho německého strojírenského podniku, rozhovor pro Handelsblatt 2024
Nicole Büttner z Merantix Momentum ve formátech EY k tématu „Budoucnost Německa“ zdůraznila něco podobného: Středně velké firmy mají díky vlastním datům výhodu, měly by však modely a platformy často dokupovat a doménovou logiku ovládat samy. Pod to se podepisuji. Data sama o sobě ještě nejsou hradním příkopem. Teprve když se spojí data, procesní znalosti a distribuční kanál, začíná být Build zajímavý.
Buy-first není kapitulace, ale disciplína
V Münsteru jsem v listopadu 2024 potkal manažera logistiky, Ralfa, který se ve firmě Fiege dříve podílel na projektech prognózování. Seděli jsme v jídelně, vonělo to po omáčce k pečeni a ze skladu se ozývalo to tlumené hučení dopravníkové techniky. „Mohli jsme si všechno postavit sami,“ řekl. „Ale k čemu?“ Fiege využívá v různých oblastech cloudové služby, moduly Azure a partnerská řešení, například pro prognózy a optimalizaci. Publikované Use Cases hovoří o 2 až 5procentním snížení zásob a o 3 až 8 procent lepší Forecast Accuracy, podle oboru.
To je realita středně velkých firem, jen o něco větší. Forecast je málokdy jedinečný. Optimalizace tras také ne. Kontrola kvality založená na obraze s definovanou třídou chyb je technicky náročná, ale často není důvodem k budování vlastního týmu Vision. Cognex, Landing AI, Microsoft Custom Vision, Siemens Industrial Edge, PTC ThingWorx nebo specializovaní dodavatelé mají své mouchy. Samozřejmě. Ale nezačínají od nuly.
Anonymizovaný případ z jižního Německa ukazuje logiku čistě. Strojírenská firma, 800 zaměstnanců, manuální vizuální kontrola, nedostatek personálu, vysoký tlak na opravy. Firma koupila komerční systém Vision-AI místo vlastního vývoje. Počáteční investice: přibližně 350 000 € za hardware, licence, integrátora a školení. Čtyři měsíce PoC, tři měsíce rollout na dvě linky. Po dvanácti měsících byla chybovost o 30 procent nižší, návratnost pod 18 měsíců. Žádná cena za inovaci. Ale peníze.
Vím, že Buy zní některým CTO příliš nízce. Člověk nechce jen „konfigurovat“. Chce tvořit. Pochopitelné. Jenže zákazník neplatí za hrdost IT oddělení. Platí za schopnost dodat, kvalitu, servis, stabilitu ceny. Pokud standardní software přinese 80 procent užitku za třetinu času, pak je vlastní vývoj často ješitností s plánováním sprintů.
Druhá pravda: Buy může být drahý, líný a nebezpečný
Nyní sebekorekce. Buy-first neznamená Vendor-first. Viděl jsem projekty SaaS, které po dvou letech vypadaly jako nájemní byt po deseti podnájemnících: všude adaptéry, nikdo už neví, komu patří klíče. Dodavatel s 260 lidmi z Dolního Bavorska platil v roce 2024 za tři nástroje blízké AI v prodeji, servisu a plánování v každém případě mírné licence. Spolu s rozhraními, poradenstvím a interními administrátory byly roční náklady najednou 310 000 €. Užitek? Těžko měřitelný. „Teď máme dashboardy,“ řekl šéf prodeje. Bylo mi ho líto.
Největší chybou Buy je slepá víra ve funkce. Demo softwaru vždy ukazuje čistá data. Vždy. V reálném provozu přijdou duplicitní kmenová data zákazníků, chybějící hierarchie artiklů, odlišné modely směn a pole v ERP s názvem „Ostatní“, které od roku 2009 obsahuje vše, co nikdo neuměl zařadit. SAP, Microsoft, Siemens nebo PTC mohou hodně odpružit. Ale neopraví organizaci, která pohrdá svými kmenovými daty.
Druhou chybou je Lock-in bez protihodnoty. Pokud dodavatel kontroluje veškeré ukládání dat, logiku modelu, uživatelské rozhraní a integraci procesů, stává se firma závislou. To může být přijatelné, pokud je Use Case komoditou a dodavatel dodává stabilně. U kritických klíčových procesů by měl být člověk opatrnější. Export dat, schopnost auditu, náklady při škálování, exit scénář — nudná témata, ano. Přesně proto se čtou příliš pozdě.
| Use Case | Doporučení pro 50–500 zam. | Proč | Typické KPI |
|---|---|---|---|
| Kontrola kvality na bázi obrazu | Většinou Buy/Configure | Vyspělé produkty Vision-AI, rychlá pilotáž na linkách | -20 až -40 % průniku chyb ve vhodných případech |
| Forecasting v prodeji nebo nákupu | Buy/Configure | Standardní modely často stačí, integrace dat je hlavní práce | +3 až +10 % Forecast Accuracy |
| AI ve vlastním strojírenském produktu | Build nebo Co-Build | Diferenciace, proprietární data ze senzorů, obrat ze servisu | Nové obraty ze servisu, méně prostojů |
| Asistence při nabídkách v B2B prodeji | Hybrid | Dokoupit LLM, integrovat vlastní produktovou a cenovou logiku | -20 až -50 % průběžné doby nabídky |
| Predictive Maintenance na standardních zařízeních | Hybrid nebo Buy | Platformy k dispozici, užitek závisí na kvalitě OT dat | -10 až -20 % neplánovaných výpadků |
| Recommendation v e-shopu | Buy, kromě velmi speciálních sortimentů | Algoritmy jsou víceméně komoditou | +2 až +8 % konverze nebo hodnoty košíku |
Kde projekty Build ve středně velkých firmách umírají
Existuje scéna, která se opakuje. Jednací místnost, šedý koberec, whiteboard se zbytky workshopu, někde ještě stojí „Prioritizace Use Case“. V místnosti sedí IT, odborné oddělení a externí poradce. Po 14 měsících trvání projektu se někdo zeptá: „Kdo je vlastně Product Owner?“ Pak nastane ticho. Zažil jsem to v Kolíně nad Rýnem, Norimberku i St. Gallenu.
Prvním důvodem úmrtí je kvalita dat. Není sexy, ale je smrtící. Automobilový dodavatel s přibližně 3 000 zaměstnanci spustil během tří let několik PoC Predictive-Maintenance společně s výzkumným ústavem. Náklady: přes milion eur, včetně interního času. Všichni piloti uvízli u jednotlivých zařízení. OT a IT byly oddělené, neexistovalo centrální Lakehouse, údržba byla zapojena pozdě a historie dat neodpovídala logice výpadků. Po změně ve vedení IT se přešlo na standardní platformu. O devět měsíců později běžely první produktivní Use Cases, po 18 měsících bylo na vybraných zařízeních hlášeno o 15 procent méně neplánovaných výpadků.
Druhým důvodem úmrtí je falešná hrdost. B2B obchodník z regionu DACH s přibližně 1 200 zaměstnanci chtěl postavit vlastní Recommendation Engine, také proto, aby snížil závislost na amerických cloudových platformách. Pětičlenný tým Data-Science, Python, Scikit-Learn, později TensorFlow. Osmnáct měsíců vývoje, zhruba 1 až 1,5 milionu eur. Nakonec byl výkon podle interních testů pouze na 60 až 70 procentech standardního cloudového Recommenderu. Projekt byl zastaven, řešení SaaS přesto přišlo. Jen později a dráž.
Třetím důvodem úmrtí je chybějící produktové myšlení. AI je spuštěna jako projekt, nikoli provozována jako produkt. Existuje PoC, závěrečná zpráva, potlesk v řídicím výboru. Poté se model začne odchylovat, nikdo neměří kvótu uživatelů, nikdo neplánuje Retraining, nikdo se necítí zodpovědný za falešné poplachy. Po šesti měsících vedoucí směny řekne: „Ta věc blbne.“ A akceptace je pryč.
MLOps zde není buzzword, ale domovnická práce pro modely. Monitoring, verzování dat, schvalovací procesy, Rollback, odpovědnosti, auditní stopa. Zní to suše. Také to takové je. Ale bez těchto rutin se AI stává jednorázovým softwarem. Člověk postaví, ukáže, zapomene.
Matice Build-vs.-Buy pro spolehlivou strategii AI
V rozhovorech rád používám jednoduchou matici 2×2. Žádná magie. Na ose X stojí potenciál diferenciace: Dělá nás tato funkce AI na trhu hůře kopírovatelnými? Na ose Y stojí standardizovatelnost: Existuje vyspělý software, který pokryje 70 až 80 procent úkolu? Pokud jsou obě osy upřímně vyhodnoceny, mnoho oblíbených projektů propadne.
Kvadrant jedna: vysoký potenciál diferenciace, nízká standardizovatelnost. Zde lze vážně prověřit Build nebo Co-Build. Příklady: AI v lékařském přístroji se speciální senzorikou, autonomní funkce v čisticím stroji, řízení procesů u vlastního výrobního postupu. Kärcher, Trumpf, Wittenstein nebo Festo přemýšlejí v těchto kategoriích. Tam je AI blízko produktu nebo procesnímu tajemství.
Kvadrant dva: nízký potenciál diferenciace, vysoká standardizovatelnost. Koupit. Tečka. Standardní forecasting, klasifikace textu v zákaznickém servisu, jednoduché chatboty, kontrola výdajů, Lead Scoring, kontrola obrazu se známými vzory chyb. Kdo zde káže Build, měl by položit na stůl náklady obětované příležitosti. Ne jako slajd. Jako částku v eurech.
Kvadrant tři: vysoký potenciál diferenciace, vysoká standardizovatelnost. To je napínavá hybridní oblast. LLM může generovat návrhy nabídek, ale vlastní produktová logika, pravidla slev, schopnost dodání a doložky o ručení musí pocházet z firmy. Microsoft Copilot nebo SAP Joule mohou dodat rozhraní, ale mozek byznysu leží ve vlastním datovém modelu. Přesně tam by měly středně velké firmy budovat kompetence.
Kvadrant čtyři: nízký potenciál diferenciace, nízká standardizovatelnost. Většinou varovný signál. Pokud něco není ani strategicky důležité, ani snadno koupitelné, proč by se to mělo dělat? Protože to chce vedoucí oddělení? Protože se rýsuje dotační program? Dotace nejsou Business Case. Přes to nejede vlak.
| Diferenciace | Standardní software k dispozici | Rozhodnutí | Příklad z praxe |
|---|---|---|---|
| Vysoká | Nízká | Build/Co-Build | Funkce AI ve strojírenském produktu, například u servisních nabídek podobných Trumpf |
| Nízká | Vysoká | Buy | Standardní forecasting v nákupu nebo prodeji s Azure, SAP, o9 nebo SAS |
| Vysoká | Vysoká | Hybrid | Asistent nabídek s LLM plus vlastní CPQ a cenová logika |
| Nízká | Nízká | Zastavit nebo nově definovat | Speciální reporting bez jasného uživatele a bez ROI |
| Střední | Střední | Časově omezený pilot s Kill-kritérii | Predictive Maintenance na smíšeném strojovém parku |
Výpočet ROI: Proč může levnější start skončit draze
V červnu 2025 mi zavolal jednatel z Ravensburgu. 120 zaměstnanců, stavba speciálních strojů, slušný EBIT, ale slabé IT. Zeptal se: „Co nás stojí AI pro automatizaci nabídek?“ Zeptal jsem se zpět: „Co stojí nabídka dnes?“ Ticho. Pak listování. Pak číslo: přibližně 1 800 € interních nákladů u komplexních strojů, pokud jsou zapojeny prodej, konstrukce a nákup.
Teprve s takovými čísly se Build vs. Buy stává hmatatelným. Pokud firma napíše 900 komplexních nabídek ročně a asistenční systém AI zkrátí průběžnou dobu o 25 procent, nemluvíme o hračce. Mluvíme o kapacitě, rychlejší reakci, méně chybách v kusovnících, lepším sledování. Zda je řešení koupené, postavené nebo hybridní, se pak rozhodne podle Paybacku, nikoli podle pocitu CTO.
| Scénář: Asistence nabídek pro strojírenskou firmu s 250 zam. | Build | Buy/Configure | Hybrid |
|---|---|---|---|
| Počáteční náklady | 450 000–750 000 € | 120 000–280 000 € | 250 000–500 000 € |
| Průběžné náklady za rok | 180 000–350 000 € za tým, cloud, údržbu | 60 000–160 000 € licence a podpora | 120 000–240 000 € platforma, licence, interní tým |
| Time-to-Value | 12–18 měsíců | 4–8 měsíců | 6–12 měsíců |
| Riziko | Vysoké při mezerách v datech a MLOps | Střední kvůli integraci a akceptaci | Střední, pokud je Product Owner silný |
| Má smysl, když | Logika nabídek je jedinečná a strategická | Proces je blízký standardu CPQ/CRM | Je potřeba standard LLM plus vlastní produktová logika |
| Očekávaný Payback | 18–36 měsíců, silně kolísavý | 9–18 měsíců při čistém zavedení | 12–24 měsíců při měřitelném objemu |
Srovnání odvětví: Strojírenství, obchod, logistika, Automotive
Strojírenství svádí k Build. Firmy mají technické sebevědomí, mnoho inženýrů, dobrá data o produktech a často kulturu „udělej si sám“. U firem DMG Mori, Trumpf, Wittenstein nebo Festo dává tento postoj u funkcí AI blízkých produktu smysl. U výrobce zařízení se 180 lidmi z Horních Frank, který chce postavit vlastní textovou AI pro servisní zprávy, spíše ne. Vůně hydraulického oleje nedělá model NLP proprietárním.
Obchod a B2B distribuce by měly téměř vždy uvažovat o Buy-first. Recommendation, Pricing, prognóza zásob, klastry zákazníků, řízení kampaní — to jsou pole s mnoha dodavateli a mnoha zkušenostmi. Diferenciace tam spočívá méně v algoritmu než v kvalitě dat, logice sortimentu, nákupních podmínkách a provedení prodeje. Jeden obchodník z Essenu mi v dubnu 2025 řekl: „Chtěli jsme si sami postavit logiku Amazonu.“ Zeptal jsem se: „Proč nejdřív neprodávat jako Amazon?“ Nesmál se.
Logistika je pragmatičtější. Možná proto, že tam každý procentní bod okamžitě padá do palet, kilometrů a plánů směn. Fiege, Dachser nebo Rhenus pracují s platformami, partnery a vlastními týmy tam, kde se to hodí. Buy pro standardní optimalizaci, Build nebo Co-Build u speciálních síťových dat a plánování specifického pro zákazníka. Rozhoduje podlaha haly. Nikoli strategické oddělení.
Dodavatelé v Automotive sedí mezi dvěma židlemi. Mají objemy, tlak na kvalitu, požadavky na Traceability a zadání od OEM. Predictive Quality, Maintenance, vizuální kontrola a plánovací AI jsou atraktivní. Ale mnoho závodů rostlo historicky, data OT leží fragmentovaná a podniková rada chce být dotázána včas. Kdo tam spustí Build bez datové platformy, skončí v bažině PoC. Viděl jsem to příliš často.
Příklad z praxe: 320 zaměstnanců, 14 měsíců, poctivý Hybrid
Případ, který mohu vyprávět anonymizovaně: Výrobce komponent z Bádenska-Württemberska, 320 zaměstnanců, obrat necelých 75 milionů eur, zákazníci ze strojírenství a zdravotnické techniky. Byl jsem tam v říjnu 2024. V oddělení kontroly kvality to vonělo po alkoholovém čističi, pod LED svítidlem ležely frézované díly v šedých trayích. Sabine, vedoucí kvality, řekla: „Ztrácíme čas, protože chyby vidíme příliš pozdě.“
Firma měla tři nápady na AI: Vision AI pro kontrolu kvality, Forecasting v nákupu, asistence nabídek pro speciální díly. Dříve by se pravděpodobně spustily tři PoC. Tentokrát ne. Jednatel nechal každý nápad projít maticí. Vision AI: Buy. Forecasting: Buy/Configure. Asistence nabídek: Hybrid, protože technická logika proveditelnosti a pravidla variant byla skutečně firemní.
Čísla po 14 měsících: Pilot Vision-AI pro dvě rodiny dílů stál přibližně 210 000 € včetně kamery, osvětlení, integrátora a školení. Průnik chyb klesl o 28 procent, opravy o 11 procent. Forecasting byl zaveden přes modul stávajícího partnera ERP plus externí datovou pipeline, náklady cca 95 000 €; Forecast Accuracy vzrostla u A-dílů o 6 procentních bodů. Asistence nabídek stála více: přibližně 380 000 €, protože byly integrovány CPQ, pravidla blízká CAD a historie cen. Za to klesla průměrná průběžná doba komplexních nabídek z 9,5 na 6,8 pracovního dne.
Důležitější než jednotlivá čísla byla Governance. Pro každý Use Case existoval Product Owner, měsíční přehled KPI, jasná kritéria pro ukončení a malé datové jádro: jeden Data Engineer, jedna Analytics Engineerka, jeden externí architekt na šest měsíců. Žádná laboratoř AI se sedacími vaky. Žádný inovační cirkus. Jen práce.
Amplifa ICP Playbook — Praktický playbook pro čistou definici cílových zákazníků, datových zdrojů a priorit dříve, než AI v prodeji nebo při generování leadů spálí peníze.
FAQ: Kdy by si měl středně velký podnik stavět AI sám?
Středně velký podnik by si měl AI stavět sám, pokud jsou současně splněny tři podmínky: Funkce vytváří diferenciaci u zákazníka, potřebná data jsou proprietární a spolehlivá a firma může financovat provoz, monitoring a další vývoj. Pokud jedna z těchto podmínek chybí, povolil by jsem Build pouze s partnerem a tvrdou stop-čarou. Příklad: inteligentní diagnostika stavu pro vlastní stroje s exkluzivními daty ze senzorů může Build ospravedlnit. Standardní chatbot pro servisní dotazy nikoli.
FAQ: Jaká je nejlepší strategie AI pro 50 až 500 zaměstnanců?
Pro firmy mezi 50 a 500 zaměstnanci je většinou nejlepší volbou hybridní strategie Buy-first. Standardní software pro komoditní Use Cases, vlastní doménová logika pro diferencující procesy, malý interní kmenový tým pro data a odpovědnost za produkt. Zní to méně hrdinsky než „stavíme si vlastní platformu“. Funguje to častěji. Podle Bitkom 2024 je produktivní využití AI v německém středním stavu stále nízké; právě proto se Time-to-Value počítá víc než technická hrdost.
FAQ: Jak se vyhnout pasti PoC u AI?
Vyhnete se jí pomocí Kill-kritérií dříve, než začne první workshop. Příklad: Pokud řešení Vision-AI po dvanácti týdnech nevykáže alespoň o 10 procent lepší rozpoznávání oproti manuálnímu vzorku, bude zastaveno nebo nově definováno. Pokud asistence nabídek po šesti měsících nepřinese měřitelnou úsporu času, letí z portfolia. Zní to tvrdě. Ale je to levnější než 18 měsíců naděje.
Doporučení pro postup: 7 kroků k rozhodnutí Build-vs.-Buy
Jako jednatel, CTO nebo digitální manažer bych nezačínal výběrem nástroje. Ani workshopem o AI, na jehož konci visí 47 Use Cases na post-itech a nikdo neví, kdo je zaplatí. Udělal bych sedm věcí. Přesně v tomto pořadí.
- Inventarizujte možné Use Cases AI ve výrobě, prodeji, servisu a backoffice. Ke každému Use Case napište jedno KPI: zmetkovitost, prostoj, doba nabídky, konverze, skladové zásoby, náklady na reklamace. Bez KPI není Use Case.
- Ohodnoťte každý Use Case pomocí matice 2×2: potenciál diferenciace proti standardizovatelnosti. Hodnocení proveďte v úzkém kruhu s vedením, odborným oddělením a IT. Nikoli v workshopu o 18 lidech.
- Definujte pravidlo Buy-first pro komoditní témata. Forecasting, standardní analýza textu, jednoduchá Vision Inspection, automatizace CRM a Recommendation by se měly stát Build pouze tehdy, existuje-li písemný obchodní důvod.
- Stanovte Kill-kritéria. Časový limit, minimální KPI, dostupnost dat, akceptace uživateli. PoC bez stop-čáry není experiment, ale nákladové riziko s přátelským jménem.
- Vybudujte malý kmenový tým. Pro 50 až 500 zaměstnanců často stačí: jeden Data Engineer nebo Analytics Engineer, jeden silný Product Owner na Use Case, jeden IT architekt na částečný úvazek, externí specialisté pro omezené fáze.
- Integrujte AI do stávajících systémů. Žádné izolované portály AI, pokud uživatelé pracují v ERP, CRM, MES, CPQ nebo ticketovacím systému. AI se musí objevit tam, kde se práce stejně děje.
- Čtvrtletně reportujte o produktivních aplikacích AI, nikoli o PoC. Ukažte Business-Impact, kvótu uživatelů, náklady, otevřená rizika. CFO by měl tabulce rozumět, aniž by musel googlit „Embedding“.
Amplifa Produkt — Automatizace prodeje s podporou AI pro B2B týmy, které nechtějí generování leadů, zpřesňování ICP a Outreach nastavovat jako kutilský projekt.
Governance: Kdo rozhoduje, kdo ručí, kdo zastavuje?
Governance AI zní jako korporátní záležitost. Není to úplně pravda. Právě středně velké firmy ji potřebují, protože cesty jsou krátké a chyby se rychle stávají osobními. Pokud AI doporučí špatné schválení kvality, neskončí téma v anonymním výboru pro rizika. Skončí u Sabine v kontrole kvality, u Thomase v inženýringu a u jednatele, když zákazník reklamuje.
Použitelná Governance pro 50 až 500 zaměstnanců nemusí být obsáhlá. Potřebuje čtyři role: Business Owner, Product Owner, technický odpovědný pracovník, kontrolor rizik nebo shody (Compliance). Business Owner odpovídá za užitek. Product Owner odpovídá za využití a roadmapu. Technika udržuje provoz, bezpečnost a tok dat v čistotě. Compliance kontroluje ochranu dat, témata podnikové rady, relevanci EU AI Act a schopnost auditu. Čtyři jména. Nikoli „to IT“.
EU AI Act bude od roku 2025 a 2026 postupně citelnější, zejména u vysoce rizikových aplikací. Mnoho Use Cases ve středně velkých firmách nespadá do nejvyšší rizikové třídy, ale dokumentace, transparentnost a odpovědnost budou důležitější. Kdo dnes zavádí AI do rozhodování o kvalitě, personálních procesů nebo výrobních kroků blízkých bezpečnosti, neměl by čekat, až bude auditor stát ve foyer.
Governance rozhoduje také o Build vs. Buy. U Buy musíte prověřit dodavatele: zpracování dat, transparentnost modelu, hosting, koncepty mazání, přístup, auditní logy. U Build musíte toto všechno umět sami. Upřímně? Mnoho firem o 200 lidech to neumí. To není výtka. Je to kritérium rozhodování.
Technologický stack: Co středně velké firmy skutečně potřebují
Pokud má Build nebo Hybrid smysl, nepotřebujete technologickou zoo. Příliš často vidím obrázky architektury s Databricks, Snowflake, Azure ML, MLflow, Airflow, Kafka, Kubernetes a pěti dalšími logy, i když firma stále posílá CSV soubory z ERP e-mailem. To není strategie. To je sbírání log.
Pro mnoho středně velkých firem stačí jasný stack: centrální úložiště dat nebo Lakehouse, stabilní rozhraní k ERP/CRM/MES, nástroj MLOps pro verzování modelů a monitoring, koncept oprávnění, reporting. Azure je ve středním stavu regionu DACH silný, často kvůli smlouvám Microsoft 365 a stávajícím kompetencím IT. AWS SageMaker, GCP Vertex AI, Databricks, Snowflake, SAP AI Core nebo Siemens Industrial Edge mohou vyhovovat. Otázkou není, které logo zní moderněji. Otázkou je, kdo ho provozuje.
Open Source není jídlo zdarma. PyTorch, TensorFlow, scikit-learn, XGBoost, Hugging Face, MLflow — všechno dobré nástroje. Ale někdo musí spravovat závislosti, kontrolovat bezpečnostní aktualizace, sledovat modely, rozpoznávat Drift, opravovat pipeline. V odpolední směně nikoho nezajímá, zda chyba pochází z Feature Store nebo z rozhraní PLC. Linka stojí.
U Buy/Configure vypadá stack jinak. Siemens Industrial Edge nebo Insights Hub pro průmyslová data, PTC ThingWorx pro scénáře blízké IoT, SAP AI Core a Joule v prostředí ERP, Microsoft Dynamics 365 s Copilot pro procesy CRM, Celonis pro Process Mining, o9 nebo SAS pro plánování, Cognex nebo Landing AI pro Vision. Tyto produkty nevyřeší každý problém, ale dávají strukturu. Pro mnoho středně velkých firem je struktura už polovinou ROI.
Amplifa pro strategii prodeje s AI — Pro středně velké B2B podniky, které chtějí AI v prodeji využívat produktivně, aniž by musely nejprve stavět vlastní Outreach a datovou platformu.
Change Management: Hala rozhoduje s Vámi
V prosinci 2024 jsem byl v podniku poblíž Pforzheimu. 160 zaměstnanců, přesné díly, hodně ruční práce při kontrole. Mladý projektový manažer vysvětloval na monitoru rozpoznávání chyb s podporou AI. Vedle mě stál kontrolor, možná koncem padesátky, ruce černé na okrajích prstů. Řekl tiše: „Když se ta bedna splete, můžu za to já.“ To byla nejdůležitější věta dne.
Zavádění AI zřídkakdy selhává jen na technice. Selhává na odpovědnosti. Pokud lidé věří, že jim AI bere práci, přihrává chyby nebo znehodnocuje jejich zkušenosti, nebudou ji používat. Pak se systém obchází, varování se ignorují, data se udržují špatně. Change Management neznamená vyvěšování plakátů. Znamená to čisté vyjasnění rolí, ručení a užitku.
U Vision AI v zajištění kvality musí být jasné: Schvaluje AI, nebo doporučuje? Kdo rozhoduje v hraničních případech? Jak se zachází s falešně negativními výsledky? Jak proudí zpětná vazba kontrolorů do modelu? U asistence nabídek v prodeji musí být jasné: Smí AI navrhovat ceny? Kdo kontroluje slevy? Která vyjádření směrem k zákazníkům jsou tabu? Tyto otázky nejsou brzdami. Jsou to provozní předpoklady.
Podniková rada k tomu patří včas, nikoli až po pilotu. Zvláště u AI v měření výkonu, plánování směn, HR nebo asistenčních systémech s údaji o využívání. Znám firmy, které ztratily tři měsíce, protože věřily, že participace je formální akt. Nebyla. Byla to samotná podstata rolloutu.
Co očekávám v roce 2026: méně divadla s PoC, více tvrdého výběru
Moje prognóza je ostrá: Do konce roku 2026 mnoho středně velkých firem zredukuje svá portfolia AI na polovinu. Ne proto, že by AI zklamala. Ale proto, že seznamy projektů z let 2023 a 2024 byly příliš široké, příliš technické a špatně spočítané. CFO se bude ptát, které aplikace běží produktivně. Prodej se bude ptát, proč asistent nabídek ještě není v CRM. Výroba se bude ptát, proč pilot funguje jen na lince 3. Pak se bude vyřazovat.
Zároveň ty dobré firmy zrychlí. Nebudou sledovat 30 Use Cases, ale pět. Budou brát standardní software tam, kde stačí, a vlastní know-how budovat tam, kde to bolí, pokud ho má i konkurence. Nebudou „dělat AI“. Budou snižovat zmetkovitost, zrychlovat nabídky, zvyšovat obraty ze servisu, redukovat zásoby. To je jiný tón.
CTO SAP Jürgen Müller veřejně několikrát zdůraznil integraci generativní AI do Business Suite. Poselství pro střední stav je jasné: Ne každý zákazník má stavět vlastní Foundation Models. Mnohé mají AI konzumovat, vkládat, kontrolovat. Považuji to za zdravé. Kdo v roce 2026 ještě věří, že firma o 250 lidech musí nejprve založit vlastní laboratoř AI, než uvidí užitek, plete si středně velký podnik s výzkumným ústavem.
Nakonec zůstává scéna z Güterslohu. Thomas, CTO s plánem za 1,2 milionu eur, mi zavolal dva týdny po našem rozhovoru. Myšlenku platformy zastavili, spustili dva piloty Buy a ponechali si jediný hybridní Use Case pro svou strojní logiku. „Působí to méně vizionářsky,“ řekl. V pozadí jsem znovu slyšel pípání vysokozdvižného vozíku. Možná právě to byl ten pokrok.