Strategie AI: Build vs. Buy v malých a středních podnicích
KI-Strategie · 23. Mai 2026 · Mohsen Ghulami
Strategie AI v malých a středních podnicích: Rozhodněte se pro Build vs. Buy s čísly, případy a jasnými kritérii, než váš PoC spolkne rozpočet.
Před třemi týdny stojím v Güterslohu v zasedací místnosti, která voní po překapávané kávě a teplém plastu. Thomas, CTO strojírenské firmy s 280 zaměstnanci, mi podává svůj iPad a říká: „Teď si budujeme vlastní AI platformu.“ Na dvoře pípá couvající vysokozdvižný vozík, uvnitř bliká PowerPointová prezentace s logem Azure, hadem Python a rozpočtem 1,2 milionu eur. Moje první otázka nebyla technická, ale brutálně jednoduchá: Je to skutečně AI strategie – nebo jen drahá oklika k dalšímu standardnímu softwaru?
O průmyslu píšu od roku 1998. Viděl jsem v Trumpf v Ditzingenu, jak se data z laserových řezacích strojů stávají součástí servisního byznysu. Zažil jsem u menších zakázkových výrobců na Švábské Albě, jak jediný chybějící export z MES zastaví celý AI projekt. A viděl jsem dost finančních ředitelů, kteří při slově „vlastní vývoj“ stiskli 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á firma s 50 až 500 zaměstnanci chce každý model prognózování stavět sám, spaluje čas, platy a nervy. Kdo ale každou AI funkci nakupuje, ačkoli právě ona dělá rozdíl ve vlastním produktu, rozdává marži dodavatelům, kteří byznysu nerozumí. Obojí jsem viděl. Obojí bolí.
Proč se AI strategie stává záležitostí 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 hotová do pátku. „Máme čtyři AI PoC,“ řekla Andrea. „Žádný nefunguje produktivně.“
Přesně tam se nachází středně velké podniky. Ne na začátku AI debaty, ale po prvním vystřízlivění. ChatGPT v roce 2023 otevřel dveře, Microsoft Copilot dorazil do mnoha firem, SAP tlačí AI funkce do své sady a každý druhý softwarový dodavatel nyní lepí AI štítek na svůj roadmap. Jenže: V hale, v prodeji, v servisu se děje méně, než tvrdí konferenční pódia.
Čísla odpovídají tomuto pozorování. Podle studie Bitkom 2024 používá AI produktiv asi 15 až 20 procent německých firem; u firem mezi 100 a 499 zaměstnanci je podíl spíše v dolní části, zhruba 10 až 15 procent. BCG a VDMA v roce 2023 ve strojírenství dospěly k vzoru, který neustále slyším v rozhovorech: Více než 60 procent experimentuje s AI PoC, ale méně než 15 procent má škálované aplikace ve firmě. Tedy: hodně pilotů, málo provozu.
To není německý přírodní zákon. Je to často špatné rozhodování. Středně velké podniky příliš často zacházejí s AI 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 nerozhodování je také chyba. Jen tišší.
AI strategie v malých a středních podnicích: Co Build vs. Buy skutečně znamená
Build neznamená, že tři datoví vědci trénují základní model ve sklepě. No, skoro nikdy. Build v malých a středních podnicích většinou znamená: vlastní datové pipeline, vlastní modely nebo alespoň vlastní doménovou logiku, vlastní MLOps procesy, vlastní monitoring, vlastní odpovědnost. Dodavatel možná poskytuje 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 do Excelu a řízením strojů. Buy znamená: nákup, konfigurace, integrace, školení, měření standardního softwaru, SaaS nebo stavebních bloků platformy. To je práce. Ale je to jiná práce než stavba modelů.
Nejostřejší hranice nevede mezi cloudem a on-premise. Vede mezi komoditou a diferenciací. Prognózování, standardní NLP, klasifikace obrázků, optimalizace tras, asistence při nabídkách, jednoduché doporučovací systémy – na 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 být Build smysluplný. Může. Ale nemusí.
PwC a Roland Berger od roku 2023 popisují vzor, který se objevuje i v mých rozhovorech: menší a střední podniky převážně volí Buy nebo Configure, větší střední podniky častěji volí Hybrid. Firma s 300 zaměstnanci spíše nakupuje Microsoft, SAP, Cognex, Celonis, o9, PTC nebo specializovaného dodavatele. Dodavatel s 3 000 zaměstnanci si možná vybuduje Analytics Competence Center a vyvíjí tam, kde je tvorba hodnoty. To zní banálně. Přesto se to neustále ignoruje.
Tvrdá čísla: náklady, časové osy, míra úspěšnosti
Během posledních dvou let jsem v Mnichově, Stuttgartu, Bielefeldu a Linci hovořil s digitálními manažery, kteří své rozpočty na AI spravují v Excelu, nikoli v tiskových zprávách. Rozpětí jsou překvapivě stabilní. PoC typu Build se v malých a středních podnicích pohybuje obvykle mezi 100 000 a 300 000 eury na tři až šest měsíců. Dokud MVP nefunguje produktivně, je reálných 300 000 až 800 000 eur, přičemž interní personální náklady nejsou vždy přesně spočítány. A právě tam začíná sebeklam.
Protože datový vědec není zdarma, jen proto, že je již na výplatní listině. Ani výrobní inženýr, který každý týden osm hodin kontroluje štítky. Ani IT architektka, která objasňuje bezpečnostní povolení, už vůbec ne. V továrně u Ulmu v únoru 2025 vonělo po chladicí kapalině, zatímco mi Martin, IT ředitel, řekl: „Externě jsme utratili jen 180 000 eur.“ O dvě hodiny později mi ukázal interní odhad nákladů. S vlastní prací se projekt vyšplhal na 520 000 eur.
Buy nebo Configure začíná níže. Pilotní licence plus integrace: často 50 000 až 250 000 eur. Rollout napříč několika závody nebo odděleními: 150 000 až 800 000 eur. Běžné licenční náklady se pro mnoho scénářů malých a středních podniků pohybují mezi 50 000 a 200 000 eury ročně, v závislosti na uživatelích, objemu dat a náladě dodavatele. Ano, náladě dodavatele. Kdo už někdy vyjednával prodloužení SaaS ve třetím roce smlouvy, ví, co mám na mysli.
Míra úspěšnosti je skutečným úderem. McKinsey ve svém State of AI 2023 uvedla, že pouze asi 20 až 30 procent společností dosahuje významných finančních výhod z projektů AI. Ve výrobě a průmyslovém zboží podle mých zkušeností a podle srovnávacích testů konzultantů umírá 50 až 70 procent PoC, než se dostanou do skutečného provozu. U Build se do výroby dostane často jen 30 až 40 procent. U Buy nebo Configure spíše 50 až 70 procent. Ne proto, že dodavatelé čarují. Ale proto, že v modelu je méně základního rizika.
| Rozhodovací bod | 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 | Srovnávací testy konzultantů DACH 2023–2025 |
| MVP až Rollout | 300 000–800 000 € plus interní časy | 150 000–800 000 € v několika oblastech | Rozpětí projektů z rozhovorů se středními podniky 2024/2025 |
| Time-to-Value | 9–18 měsíců do měřitelného obchodního dopadu | 3–9 měsíců do prvních efektů | Vzor PwC/Roland-Berger, potvrzený v praktických případech |
| PoC do výroby | 30–40 % dosáhne stabilního provozu | 50–70 % dosáhne stabilního provozu | Průmyslové srovnávací testy, 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 rychle přinést výsledky | Odvozeno z případů Trumpf, Kärcher, Fiege |
Build se vyplatí – ale méně často, než tvrdí zakladatelské prezentace
Mám rád vlastní vývoj. Opravdu. Je tu ten okamžik, kdy tým model nejen trénuje, ale integruje ho do procesu, uživatelé se ho dotýkají, metrika se pohybuje a vedoucí závodu už nemluví o „té AI věci“, ale o svém novém nástroji. To je silné. Jenže se to nestane jen proto, že někdo nainstaloval PyTorch.
Trumpf je dobrým příkladem, ale také varováním. Rodinná firma z Ditzingenu má asi 16 500 zaměstnanců, hluboká strojní data, vlastní historii platformy s AXOOM a ekosystém kolem TruConnect. Od roku 2017 Trumpf nepřetržitě investuje do digitálních služeb, prediktivní údržby 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 počítačové vidění, navigaci, fúzi senzorů a robustní software ve fyzickém produktu. Standardní doporučovač z cloudu tam moc nepomůže. Kärcher od roku 2018 buduje digitální kompetence, mimo jiné v Digital Hubu, a kombinuje vlastní vývoj s cloudovými komponenty. Zde Build není prestiž. AI je v zařízení, v ceně, v servisní smlouvě.
To je ten bod: Build se vyplatí, pokud AI mění zákaznickou hodnotu nebo mapuje proces, který konkurenti nemohou snadno zkopírovat. Výrobce obráběcích strojů s miliardami historických senzorových dat má jinou výchozí pozici než velkoobchodník s 220 zaměstnanci, který chce zlepšit cross-selling ve svém e-shopu. Kdo tyto rozdíly zamlžuje, dělá věci obráceně.
Vyvíjíme sami pouze tam, kde vidíme jasnou konkurenční výhodu a kde jsou naše procesní nebo produktové znalosti jedinečné. Standardní analytiku a jazykové modely nakupujeme.
— podle CDO německého strojírenského podniku, rozhovor pro Handelsblatt 2024
Nicole Büttner z Merantix Momentum v EY formátech k „Budoucnosti Německa“ podobně zdůraznila: Střední podniky mají výhodu s vlastními daty, ale modely a platformy by měly často nakupovat a doménovou logiku ovládat samy. S tím souhlasím. Data sama o sobě ještě nejsou obranným valem. Teprve když se spojí data, procesní znalosti a distribuční kanál, stává se Build zajímavým.
Buy-first není kapitulace, ale disciplína
V listopadu 2024 jsem se v Münsteru setkal s logistickým manažerem Ralfem, který se dříve ve Fiege podílel na projektech prognózování. Seděli jsme v jídelně, vonělo to po omáčce a ze skladu se ozývalo tlumené dunění dopravní techniky. „Všechno jsme si mohli postavit sami,“ řekl. „Ale k čemu?“ Fiege využívá v různých oblastech cloudové služby, komponenty Azure a partnerská řešení, například pro prognózy a optimalizaci. Zveřejněné případy použití hovoří o snížení zásob o 2 až 5 procent a o 3 až 8 procent lepší přesnosti prognóz, v závislosti na oblasti.
To je realita středních podniků, jen o něco větší. Prognóza je zřídka 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 vybudování vlastního týmu pro vidění. 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 jasně ukazuje logiku. Strojírenská firma, 800 zaměstnanců, manuální vizuální kontrola, nedostatek personálu, vysoký tlak na přepracování. Společnost zakoupila komerční systém Vision-AI namísto vlastního vývoje. Počáteční investice: asi 350 000 eur za hardware, licence, integrátora a školení. Čtyři měsíce PoC, tři měsíce rollout na dvou linkách. Po dvanácti měsících byla chybovost asi o 30 procent nižší, návratnost investice pod 18 měsíců. Žádná inovační cena. Ale peníze.
Vím, že Buy zní některým CTO příliš malicherně. Nechtějí jen „konfigurovat“. Chtějí tvořit. Pochopitelné. Jenže zákazník neplatí za hrdost IT oddělení. Platí za schopnost dodávat, kvalitu, servis, cenovou stabilitu. Pokud standardní software přináší 80 procent užitku za třetinu času, pak je vlastní vývoj často marnivost s plánováním sprintů.
Druhá pravda: Buy se může stát drahým, pomalým a nebezpečným
Nyní sebekorekce. Buy-first neznamená Vendor-first. Viděl jsem SaaS projekty, které po dvou letech vypadaly jako pronajatý byt po deseti podnájemnících: všude adaptéry, nikdo už neví, komu patří klíč. Dodavatel z Dolního Bavorska s 260 zaměstnanci zaplatil v roce 2024 za tři nástroje blízké AI v prodeji, servisu a plánování mírné licence. Spolu s rozhraními, poradenstvím a interními administrátory se roční náklady náhle vyšplhaly na 310 000 eur. Přínos? Těžko měřitelný. „Teď máme dashboardy,“ řekl obchodní ředitel. Bylo mi ho líto.
Největší chyba při nákupu je slepá víra ve funkci. Softwarová ukázka vždy ukazuje čistá data. Vždy. Ve skutečném provozu se objeví duplicitní zákaznické kmeny, chybějící hierarchie položek, odlišné směnové modely a pole ERP s názvem „Ostatní“, které od roku 2009 obsahuje vše, co nikdo nechtěl zařadit. SAP, Microsoft, Siemens nebo PTC toho dokážou hodně zmírnit. Ale neopraví organizaci, která pohrdá svými kmenovými daty.
Druhou chybou je lock-in bez protihodnoty. Pokud dodavatel kontroluje celé 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 případ použití komoditou a dodavatel stabilně dodává. U kritických klíčových procesů byste měli být opatrnější. Export dat, auditovatelnost, náklady při škálování, scénář exitu – nudná témata, ano. Přesně proto se čtou příliš pozdě.
| Případ použití | Doporučení pro 50–500 zaměstnanců | Proč | Typická KPI |
|---|---|---|---|
| Vizuální kontrola kvality | Většinou Buy/Configure | Zralé produkty Vision-AI, rychlé pilotování na linkách | -20 až -40 % chybovosti v vhodných případech |
| Prognózování v prodeji nebo nákupu | Buy/Configure | Standardní modely často stačí, integrace dat je klíčová práce | +3 až +10 % přesnosti prognóz |
| AI ve vlastním strojním produktu | Build nebo Co-Build | Diferenciace, proprietární senzorová data, servisní tržby | Nové servisní tržby, menší prostoje |
| Asistence při nabídkách v B2B prodeji | Hybrid | Nákup LLM, integrace vlastní produktové a cenové logiky | -20 až -50 % doby zpracování nabídek |
| Prediktivní údržba standardních zařízení | Hybrid nebo Buy | Platformy k dispozici, přínos závisí na kvalitě OT dat | -10 až -20 % neplánovaných výpadků |
| Doporučení v e-shopu | Buy, kromě velmi specifických sortimentů | Algoritmy jsou z velké části komoditou | +2 až +8 % konverze nebo hodnoty košíku |
Kde projekty Build v malých a středních podnicích umírají
Existuje scéna, která se opakuje. Zasedací místnost, šedý koberec, tabule se zbytky workshopu, někde je ještě napsáno „Prioritizace případů použití“. V místnosti sedí IT, odborné oddělení a externí konzultant. Po 14 měsících projektu se někdo zeptá: „Kdo je vlastně Product Owner?“ Pak nastane ticho. Zažil jsem to v Kolíně nad Rýnem, Norimberku a St. Gallenu.
První příčinou smrti 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 prediktivní údržby, společně s výzkumným ústavem. Náklady: přes milion eur, včetně interního času. Všechny pilotní projekty uvízly v jednotlivých zařízeních. OT a IT byly oddělené, neexistovalo centrální Lakehouse, údržba byla zapojena pozdě a historie dat neodpovídala logice selhání. Po změně ve vedení IT bylo přejito na standardní platformu. O devět měsíců později běžely první produktivní případy použití, po 18 měsících bylo na vybraných zařízeních hlášeno o zhruba 15 procent méně neplánovaných výpadků.
Druhým důvodem smrti je falešná pýcha. B2B prodejce z regionu DACH s přibližně 1 200 zaměstnanci chtěl vybudovat vlastní doporučovací systém, také aby snížil závislost na amerických cloudových platformách. Pětičlenný tým datových vědců, Python, Scikit-Learn, později TensorFlow. Osmnáct měsíců vývoje, zhruba 1 až 1,5 milionu eur. Nakonec byla výkonnost podle interních testů pouze 60 až 70 procent standardního cloudového doporučovače. Projekt byl zastaven, SaaS řešení přesto přišlo. Jen později a dráže.
Třetím důvodem smrti je chybějící produktové myšlení. AI se spouští jako projekt, nikoli jako produkt. Existuje PoC, závěrečná zpráva, potlesk ve řídícím výboru. Poté se model odchyluje, nikdo neměří míru uživatelů, nikdo neplánuje přeškolení, 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 už je akceptace pryč.
MLOps zde není módní slovo, ale údržbářská práce pro modely. Monitorování, verzování dat, schvalovací procesy, rollback, odpovědnosti, auditní stopa. Zní to suše. A také je. Ale bez těchto rutin se AI stává jednorázovým softwarem. Postavíte, ukážete, zapomenete.
Matice Build-vs.-Buy pro spolehlivou AI strategii
V rozhovorech rád používám jednoduchou matici 2×2. Žádná magie. Na ose X je potenciál diferenciace: Dělá tato funkce AI naši firmu na trhu hůře kopírovatelnou? Na ose Y je standardizovatelnost: Existuje zralý software, který pokrývá 70 až 80 procent úkolu? Pokud jsou obě osy upřímně hodnoceny, mnoho oblíbených projektů propadne.
První kvadrant: vysoký potenciál diferenciace, nízká standardizovatelnost. Zde je vhodné vážně zvážit Build nebo Co-Build. Příklady: AI v lékařském zařízení 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 uvažují v těchto kategoriích. Tam je AI blízko produktu nebo procesnímu tajemství.
Druhý kvadrant: nízký potenciál diferenciace, vysoká standardizovatelnost. Koupit. Tečka. Standardní prognózování, klasifikace textu v zákaznickém servisu, jednoduché chatboty, kontrola výdajů, bodování leadů, kontrola obrázků se známými chybami. Kdo zde hlásá Build, měl by položit na stůl oportunitní náklady. Ne jako snímek. Jako částku v eurech.
Třetí kvadrant: vysoký potenciál diferenciace, vysoká standardizovatelnost. To je zajímavá hybridní oblast. LLM může generovat návrhy nabídek, ale vlastní produktová logika, pravidla slev, dodací schopnost a doložky o odpovědnosti musí pocházet z podniku. Microsoft Copilot nebo SAP Joule mohou poskytovat rozhraní, ale obchodní mozek leží ve vlastním datovém modelu. Přesně tam by měly středně velké podniky budovat kompetence.
Čtvrtý kvadrant: nízký potenciál diferenciace, nízká standardizovatelnost. Většinou varovný signál. Pokud něco není 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 nabízí dotační program? Dotační peníze nejsou obchodní případ. S tím se nedá nic dělat.
| Diferenciace | Dostupný standardní software | Rozhodnutí | Příklad z praxe |
|---|---|---|---|
| Vysoká | Nízká | Build/Co-Build | Funkce AI ve strojním produktu, např. u servisních nabídek podobných Trumpf |
| Nízká | Vysoká | Buy | Standardní prognózování 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 přeformulovat | Speciální reporting bez jasného uživatele a bez ROI |
| Střední | Střední | Časově omezený pilot s kritérii pro ukončení | Prediktivní údržba na smíšeném strojním parku |
Výpočet ROI: Proč levnější start může skončit draze
V červnu 2025 mi zavolal generální ředitel z Ravensburgu. 120 zaměstnanců, výroba speciálních strojů, slušný EBIT, ale slabé IT. Zeptal se: „Kolik nás bude stát AI pro automatizaci nabídek?“ Zeptal jsem se zpět: „Kolik stojí nabídka dnes?“ Ticho. Pak listování. Pak číslo: přibližně 1 800 eur interních nákladů u komplexních strojů, pokud se podílí prodej, konstrukce a nákup.
Teprve s takovými čísly se Build vs. Buy stává hmatatelným. Pokud firma ročně napíše 900 komplexních nabídek a systém AI asistence zkrátí dobu zpracování o 25 procent, nemluvíme o hračce. Mluvíme o kapacitě, rychlejší reakci, méně chyb v kusovnících, lepší sledovatelnosti. Zda je řešení koupené, postavené nebo hybridní, se pak rozhoduje podle návratnosti, nikoli podle pocitu CTO.
| Scénář: Asistence při nabídkách pro výrobce strojů s 250 zaměstnanci | Build | Buy/Configure | Hybrid |
|---|---|---|---|
| Počáteční náklady | 450 000–750 000 € | 120 000–280 000 € | 250 000–500 000 € |
| Běžné roční náklady | 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ý |
| Smysluplné, pokud | Logika nabídky je jedinečná a strategická | Proces je blízko standardnímu CPQ/CRM | Je potřeba standard LLM plus vlastní produktová logika |
| Očekávaná návratnost | 18–36 měsíců, silně kolísavá | 9–18 měsíců při čisté implementaci | 12–24 měsíců při měřitelném objemu |
Srovnání odvětví: strojírenství, obchod, logistika, automobilový průmysl
Strojírenství je lákavé pro Build. Firmy mají technické sebevědomí, mnoho inženýrů, dobrá produktová data a často kulturu „udělej si sám“. U DMG Mori, Trumpf, Wittenstein nebo Festo má tento přístup smysl u funkcí AI blízkých produktu. U výrobce zařízení s 180 zaměstnanci z Horního Franka, který chce vybudovat 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 myslet na Buy-first. Doporučení, cenotvorba, prognóza zásob, klastry zákazníků, řízení kampaní – to jsou oblasti s mnoha dodavateli a bohatými zkušenostmi. Diferenciace zde spočívá méně v algoritmu než v kvalitě dat, logice sortimentu, nákupních podmínkách a realizaci prodeje. 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ě spadá do palet, kilometrů a 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 zákaznicky specifického plánování. Rozhoduje podlaha haly. Ne strategické oddělení.
Dodavatelé v automobilovém průmyslu sedí mezi dvěma židlemi. Mají objem, tlak na kvalitu, požadavky na sledovatelnost a specifikace OEM. Prediktivní kvalita, údržba, vizuální kontrola a plánovací AI jsou atraktivní. Ale mnoho továren se historicky vyvíjelo, OT data jsou fragmentovaná a odborová rada chce být včas dotázána. Kdo tam spustí Build bez datové platformy, skončí v bažině PoC. Viděl jsem to příliš často.
Praktický příklad: 320 zaměstnanců, 14 měsíců, poctivý hybrid
Případ, který mohu anonymně vyprávět: výrobce komponentů z Bádenska-Württemberska, 320 zaměstnanců, obrat necelých 75 milionů eur, zákazníci ze strojírenství a medicínské techniky. Byl jsem tam v říjnu 2024. V kontrole kvality vonělo po alkoholovém čističi, pod LED svítidlem ležely frézované díly v šedých táccí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, prognózování v nákupu, asistence při nabídkách pro speciální díly. Dříve by se pravděpodobně spustily tři PoC. Tentokrát ne. Generální ředitel nechal každý nápad projít maticí. Vision AI: Buy. Prognózování: Buy/Configure. Asistence při nabídkách: Hybrid, protože logika technické proveditelnosti a pravidla variant byly skutečně firemní.
Čísla po 14 měsících: Pilot Vision-AI pro dvě rodiny dílů stál zhruba 210 000 eur včetně kamery, osvětlení, integrátora a školení. Chybovost klesla o 28 procent, přepracování o 11 procent. Prognózování bylo zavedeno prostřednictvím modulu stávajícího ERP partnera plus externí datové pipeline, náklady asi 95 000 eur; přesnost prognóz u A-dílů vzrostla o 6 procentních bodů. Asistence při nabídkách stála více: zhruba 380 000 eur, protože byly integrovány CPQ, pravidla blízká CAD a historie cen. Díky tomu se průměrná doba zpracování komplexních nabídek snížila z 9,5 na 6,8 pracovních dnů.
Důležitější než jednotlivá čísla byla správa. Pro každý případ použití existoval Product Owner, měsíční přehled KPI, jasná kritéria pro ukončení a malý datový tým: jeden datový inženýr, jedna analytická inženýrka, externí architekt na šest měsíců. Žádná AI laboratoř s sedacími vaky. Žádný inovační cirkus. Jen práce.
Amplifa ICP Playbook Praktický playbook pro čisté definování cílových zákazníků, zdrojů dat a priorit, než AI v prodeji nebo generování leadů spálí peníze.
FAQ: Kdy by měl středně velký podnik stavět AI sám?
Středně velký podnik by 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 podnik je schopen financovat provoz, monitorování a další vývoj. Pokud jedna z těchto podmínek chybí, povolil bych Build pouze s partnerem a s přísnou stopkou. Příklad: inteligentní diagnostika stavu pro vlastní stroje s exkluzivními senzorovými daty může ospravedlnit Build. Standardní chatbot pro servisní dotazy nikoli.
FAQ: Jaká je nejlepší AI strategie pro 50 až 500 zaměstnanců?
Pro firmy s 50 až 500 zaměstnanci je obvykle nejlepší volbou hybridní strategie „Buy-first“. Standardní software pro běžné případy použití, vlastní doménová logika pro diferencující procesy, malý interní tým pro data a odpovědnost za produkt. To zní méně hrdinsky než „budujeme si vlastní platformu“. Častěji to funguje. Podle Bitkom 2024 je produktivní využití AI v německých středních podnicích stále nízké; právě proto je čas do hodnoty důležitější než technická pýcha.
FAQ: Jak se vyhnout pasti PoC u AI?
Vyhnete se jí s kritérii pro ukončení, než začne první workshop. Příklad: Pokud řešení Vision-AI po dvanácti týdnech neukáže alespoň o 10 procent lepší rozpoznávání oproti manuálnímu vzorku, bude zastaveno nebo přeformulováno. Pokud asistence při nabídkách po šesti měsících nepřinese měřitelnou úsporu času, bude vyřazena z portfolia. Zní to tvrdě. Ale je to levnější než 18 měsíců naděje.
Doporučení k akci: 7 kroků k rozhodnutí Build vs. Buy
Jako generální ředitel, CTO nebo digitální manažer bych nezačínal výběrem nástrojů. Ani s AI workshopem, kde nakonec na Post-itech visí 47 případů použití a nikdo neví, kdo je zaplatí. Udělal bych sedm věcí. Přesně v tomto pořadí.
- Inventarizujte možné případy použití AI ve výrobě, prodeji, servisu a backoffice. Ke každému případu použití napište klíčovou metriku: zmetky, prostoje, doba nabídky, konverze, zásoby, náklady na reklamace. Bez metriky není případ použití.
- Vyhodnoťte každý případ použití pomocí matice 2×2: potenciál diferenciace versus standardizovatelnost. Proveďte hodnocení v úzkém kruhu s vedením, odborným oddělením a IT. Ne na workshopu s 18 lidmi.
- Definujte pravidlo „Buy-first“ pro komoditní témata. Prognózování, standardní textová analýza, jednoduchá vizuální kontrola, automatizace CRM a doporučení by se měly stát Build pouze tehdy, pokud existuje písemný obchodní důvod.
- Stanovte kritéria pro ukončení. Časový limit, minimální KPI, dostupnost dat, akceptace uživatelů. PoC bez stopky není experiment, ale nákladové riziko s přátelským názvem.
- Vybudujte malý základní tým. Pro 50 až 500 zaměstnanců často stačí: jeden datový inženýr nebo analytický inženýr, silný Product Owner pro každý případ použití, IT architekt na částečný úvazek, externí specialisté na omezené fáze.
- Integrujte AI do stávajících systémů. Žádné izolované AI portály, 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 AI aplikacích, nikoli o PoC. Ukažte obchodní dopad, míru uživatelů, náklady, otevřená rizika. Finanční ředitel by měl tabulku rozumět, aniž by musel googlit „embedding“.
Amplifa Produkt Prodejní automatizace s podporou AI pro B2B týmy, které nechtějí budovat generování leadů, zpřesňování ICP a outreach jako kutilský projekt.
Správa: Kdo rozhoduje, kdo nese odpovědnost, kdo zastavuje?
AI správa zní jako korporace. To není tak docela pravda. Právě středně velké podniky ji potřebují, protože cesty jsou krátké a chyby se rychle stávají osobními. Pokud AI doporučí chybné schválení kvality, téma neskončí v anonymním výboru pro rizika. Skončí u Sabine v QS, u Thomase v inženýrství a u generálního ředitele, když si zákazník stěžuje.
Použitelná správa pro 50 až 500 zaměstnanců nemusí být tlustá. Potřebuje čtyři role: Business Owner, Product Owner, technický manažer, kontrolor rizik nebo compliance. Business Owner zodpovídá za přínos. Product Owner zodpovídá za využití a roadmapu. Technika udržuje provoz, bezpečnost a datový tok čistý. Compliance kontroluje ochranu dat, témata odborových rad, relevanci EU AI Act a auditovatelnost. Čtyři jména. Ne „IT“.
EU AI Act se bude od roku 2025 a 2026 postupně projevovat, zejména u vysoce rizikových aplikací. Mnoho případů použití v malých a středních podnicí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 procesech nebo bezpečnostně relevantních výrobních krocích, neměl by čekat, až auditor stojí ve foyer.
Správa také rozhoduje o Build vs. Buy. U Buy musíte prověřit dodavatele: zpracování dat, transparentnost modelu, hosting, koncepty mazání, přístup, auditní záznamy. U Build musíte být schopni všechno tohle sami. Upřímně? Mnoho firem s 200 zaměstnanci to nedokáže. To není výtka. Je to kritérium pro rozhodování.
Technologický stack: Co středně velké podniky skutečně potřebují
Pokud má Build nebo Hybrid smysl, nepotřebujete technologickou zoo. Příliš často vidím architektonické obrázky s Databricks, Snowflake, Azure ML, MLflow, Airflow, Kafka, Kubernetes a pěti dalšími logy, ačkoli společnost 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 podniků stačí jasný stack: centrální úložiště dat nebo Lakehouse, stabilní rozhraní k ERP/CRM/MES, nástroj MLOps pro verzování a monitorování modelů, koncept práv, reporting. Azure je v DACH středních podnicích silné, často kvůli smlouvám Microsoft 365 a stávajícím IT kompetencím. AWS SageMaker, GCP Vertex AI, Databricks, Snowflake, SAP AI Core nebo Siemens Industrial Edge se mohou hodit. Otázka není, které logo zní moderněji. Otázka je, kdo to provozuje.
Open Source není jídlo zdarma. PyTorch, TensorFlow, scikit-learn, XGBoost, Hugging Face, MLflow – všechno dobré nástroje. Ale někdo musí udržovat závislosti, kontrolovat bezpečnostní aktualizace, monitorovat modely, rozpoznávat drift, opravovat pipeline. V noční směně nikoho nezajímá, zda chyba pochází z Feature Storu 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 IoT scénáře, SAP AI Core a Joule v prostředí ERP, Microsoft Dynamics 365 s Copilotem pro CRM procesy, Celonis pro Process Mining, o9 nebo SAS pro plánování, Cognex nebo Landing AI pro Vision. Tyto produkty neřeší každý problém, ale dávají strukturu. Pro mnoho středně velkých podniků je struktura už polovina ROI.
Amplifa pro AI prodejní strategii Pro středně velké B2B společnosti, které chtějí produktivně využívat AI v prodeji, aniž by musely nejprve budovat vlastní platformu pro outreach a data.
Change Management: Hala rozhoduje s
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 na monitoru vysvětloval AI-podporovanou detekci chyb. Vedle mě stál kontrolor, možná kolem padesátky, s rukama černými na okrajích prstů. Tiše řekl: „Když se krabice špatně umístí, je to moje chyba.“ To byla nejdůležitější věta dne.
Zavádění AI zřídka selže jen na technice. Selže na odpovědnosti. Pokud lidé věří, že jim AI bere práci, svaluje na ně chyby nebo znehodnocuje jejich zkušenosti, nebudou ji používat. Pak se systém obchází, varování se ignorují, data se špatně udržují. Change management neznamená věšet plakáty. Znamená to jasně objasnit role, odpovědnost a přínosy.
U Vision AI v kontrole kvality musí být jasné: Uvolňuje AI nebo doporučuje? Kdo rozhoduje v hraničních případech? Jak se řeší falešné negativy? Jak se zpětná vazba od kontrolorů promítá do modelu? U asistence při nabídkách v prodeji musí být jasné: Smí AI navrhovat ceny? Kdo kontroluje slevy? Jaké výroky vůči zákazníkům jsou tabu? Tyto otázky nejsou brzdou. Jsou to provozní předpoklady.
Odborová rada patří k tomu brzy, ne po pilotním projektu. Zvláště u AI v měření výkonu, plánování směn, HR nebo asistenčních systémech s uživatelskými daty. Znám firmy, které ztratily tři měsíce, protože věřily, že účast je formalita. Nebyla. Byla to skutečná implementace.
Co očekávám v roce 2026: méně PoC divadla, více tvrdého výběru
Moje prognóza je ostrá: Do konce roku 2026 mnoho středně velkých podniků sníží 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 příliš špatně spočítané. Finanční ředitel se zeptá, které aplikace běží produktivně. Obchod se zeptá, proč asistent nabídek ještě není v CRM. Výroba se zeptá, proč pilotní projekt funguje jen na lince 3. Pak se bude třídit.
Zároveň se dobré firmy zrychlí. Nebudou sledovat 30 případů použití, ale pět. Budou používat standardní software tam, kde stačí, a budovat vlastní know-how tam, kde to bolí, když ho má i konkurence. Nebudou „dělat AI“. Budou snižovat zmetky, zrychlovat nabídky, zvyšovat tržby ze služeb, snižovat zásoby. To je jiný tón.
CTO společnosti SAP Jürgen Müller veřejně několikrát zdůraznil integraci generativní AI do balíčku Business Suite. Zpráva pro středně velké podniky je jasná: Ne každý zákazník by si měl budovat vlastní základní modely. Mnozí by měli AI konzumovat, integrovat, kontrolovat. Považuji to za zdravé. Kdo v roce 2026 stále věří, že firma s 250 zaměstnanci musí nejprve založit vlastní AI laboratoř, než uvidí přínos, zaměňuje 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. Zastavili myšlenku platformy, spustili dva pilotní projekty Buy a ponechali si jeden hybridní případ použití pro svou strojní logiku. „Cítí se to méně vizionářsky,“ řekl. V pozadí jsem znovu slyšel pípání vysokozdvižného vozíku. Možná to byl právě ten pokrok.