I've watched a handful of AI pilots in procurement organizations go quiet. Not with a bang — with a shrug. Someone stops sending updates, the Slack channel goes dark, and three months later the tool is still technically active but nobody uses it. When you ask what happened, the answer is usually some version of "it just didn't really work out." Viděl jsem, jak v nákupních organizacích potichu doznívá celá řada AI pilotů. Bez velkého třesku — jen s pokrčením ramen. Někdo přestane posílat updaty, Slack kanál utichne, a za tři měsíce je nástroj sice technicky aktivní, ale nikdo ho nepoužívá. Když se zeptáte, co se stalo, odpověď je zpravidla nějaká varianta "prostě to nevyšlo."
It's rarely the AI's fault. I can count on one hand the cases where the technology itself was the problem. What actually kills these projects is a short list of management decisions — most of them made in the first two weeks, some of them made before the first meeting about the tool even happened. Skoro nikdy to není vina AI. Na prstech jedné ruky spočítám případy, kdy byl problémem samotný nástroj. Co tyto projekty skutečně zabíjí, je krátký seznam rozhodnutí — většina z nich padne v prvních dvou týdnech, některá ještě dřív, než proběhne první schůzka k danému nástroji.
Failure Pattern 1: Starting With a Tool, Not a Task Vzorec selhání 1: Začínáme nástrojem, ne úkolem
Someone went to a conference. Or saw a vendor demo. Or a LinkedIn post caught their eye. The tool looked genuinely impressive — and it probably was. So they bought licenses. Then they looked around for a problem to solve with it. Někdo byl na konferenci. Nebo viděl demo od dodavatele. Nebo ho zaujal příspěvek na LinkedIn. Nástroj vypadal opravdu působivě — a možná byl. Tak koupili licence. A pak začali hledat problém, který by s ním vyřešili.
This is backwards and it almost always ends the same way. The tool gets piloted on a task it wasn't really designed for, results are mediocre, and the team concludes that "AI doesn't work for us." The tool isn't wrong. The sequence is wrong. To je pozadu a téměř vždy to skončí stejně. Nástroj se pilotuje na úkolu, pro který nebyl navržen, výsledky jsou průměrné a tým dojde k závěru, že "AI u nás nefunguje." Nástroj není špatný. Postup je špatný.
The fix is simple, not easy: write the task in one sentence before you look at any tool. "We want to automatically extract payment terms and renewal dates from new supplier contracts." That sentence tells you what you need the tool to do. Then you find the tool that does it. If you can't write that sentence, you're not ready to buy anything. Řešení je jednoduché, ale ne snadné: napište úkol do jedné věty, ještě než se podíváte na jakýkoli nástroj. "Chceme automaticky extrahovat platební podmínky a data obnovení z nových dodavatelských smluv." Tato věta říká, co od nástroje potřebujete. Pak najdete nástroj, který to umí. Pokud tu větu napsat neumíte, nejste připraveni nic kupovat.
Failure Pattern 2: One Ambassador Syndrome Vzorec selhání 2: Syndrom jediného ambasadora
The pilot runs through one person. They're enthusiastic, capable, and they genuinely get it. They build the prompts, run the tests, train their colleagues, write the internal guide. The pilot looks promising. Pilot probíhá přes jednu osobu. Je nadšená, schopná, skutečně tomu rozumí. Staví prompty, spouští testy, školí kolegy, píše interní příručku. Pilot vypadá slibně.
Then that person goes on holiday for two weeks. Or changes jobs. Or gets pulled onto a bigger project. The pilot stops. Nobody else knows how the tool actually works — not at the level needed to keep it running. By the time the ambassador comes back, momentum is gone and everyone has moved on. Pak ta osoba odjede na dva týdny na dovolenou. Nebo změní práci. Nebo ji přesunou na větší projekt. Pilot se zastaví. Nikdo jiný neví, jak nástroj skutečně funguje — ne na úrovni potřebné k jeho provozu. Než se ambasador vrátí, momentum je pryč a všichni se posunuli dál.
Minimum viable redundancy: two people. Two people who both understand the tool, both know the prompts, both can explain it to a new colleague. This isn't about documentation — documentation gets outdated. It's about having two brains that hold the context. If your pilot doesn't have two active owners, it's one resignation away from disappearing. Minimální životaschopná záloha: dva lidé. Dva lidé, kteří oba rozumí nástroji, oba znají prompty, oba ho dokážou vysvětlit novému kolegovi. Nejde o dokumentaci — dokumentace zastarává. Jde o to mít dva lidi, kteří nesou kontext. Pokud váš pilot nemá dva aktivní vlastníky, jedna výpověď ho může smazat.
Failure Pattern 3: Skipping the Policy Vzorec selhání 3: Přeskočení politiky
This one sounds like bureaucratic nagging until you watch it go wrong. The team starts the pilot. Nobody writes a policy — "we'll do that later, once we know if it works." But while the pilot is running, other people in the team see it and start using whatever AI tools they have in their browser. ChatGPT, Gemini, Copilot. Pasting supplier prices into free-tier tools. Uploading contract drafts to systems with no data processing agreement in place. Tohle zní jako byrokratické mrzoutství — dokud se to nevymkne kontrole. Tým spustí pilot. Nikdo nepíše politiku — "to uděláme později, až budeme vědět, jestli to funguje." Ale zatímco pilot běží, ostatní v týmu to vidí a začínají používat AI nástroje, které mají v prohlížeči. ChatGPT, Gemini, Copilot. Vkládají ceny dodavatelů do nástrojů s free tier. Nahrávají návrhy smluv do systémů bez uzavřené smlouvy o zpracování dat.
By the time someone writes the policy — if they ever do — the habits are already set. Rolling them back is much harder than setting them correctly from the start. Když někdo konečně napíše politiku — pokud vůbec — zvyky jsou už zažité. Vrátit je zpět je podstatně těžší než správně nastavit od začátku.
One page. One afternoon. Before you start. The policy doesn't need to be a legal document. It needs to answer three questions: what data can go into which tools, which tools are approved, and who do you ask when you're not sure. That's it. Write it on the day you decide to run the pilot — not six weeks later when the damage is already done. Jedna strana. Jedno odpoledne. Před spuštěním. Politika nemusí být právní dokument. Potřebuje odpovědět na tři otázky: jaká data mohou jít do jakých nástrojů, které nástroje jsou schváleny, a koho se ptáte, když si nejste jisti. To je vše. Napište ji v den, kdy se rozhodnete pilota spustit — ne šest týdnů poté, co je škoda napáchaná.
If you want a template, Sourcing Sense has one — one page, ready to adapt in under an hour. Pokud chcete šablonu, Sourcing Sense ji má — jedna stránka, připravená k úpravě za méně než hodinu.
Failure Pattern 4: Measuring Adoption Instead of Outcome Vzorec selhání 4: Měříme adopci místo výsledku
Three months into the pilot, someone asks how it's going. The answer is: "Eight out of twelve people in the team are using it." That sounds like progress. It isn't a measure of success. Tři měsíce po spuštění pilota se někdo zeptá, jak to jde. Odpověď zní: "Osm ze dvanácti lidí v týmu to používá." To zní jako pokrok. Není to ukazatel úspěchu.
The question you actually need to answer is: did the original task get faster, cheaper, or better? If you wanted to reduce the time spent reviewing supplier responses, is that time going down? If you wanted to catch more contract risks before signing, are you catching more? Adoption without outcome measurement is just a usage report dressed up as a result. Otázka, na kterou skutečně potřebujete odpověď, je: stal se původní úkol rychlejším, levnějším nebo lepším? Pokud jste chtěli snížit čas strávený kontrolou odpovědí dodavatelů, klesá tento čas? Pokud jste chtěli zachytit více smluvních rizik před podpisem, zachycujete jich více? Adopce bez měření výsledku je jen report o používání přestrojený za výsledek.
Pick one number before you start. One metric that reflects the original task. Time saved per week. Error rate. Number of contracts reviewed without escalation. Whatever is relevant to your task. That number is your success criterion. If you don't define it before you start, you'll have no way of knowing whether the pilot actually worked. Vyberte jedno číslo před spuštěním. Jednu metriku, která odráží původní úkol. Ušetřený čas za týden. Míra chyb. Počet smluv zkontrolovaných bez eskalace. Cokoli, co je relevantní pro váš úkol. Toto číslo je vaše kritérium úspěchu. Pokud ho nedefinujete před spuštěním, nebudete mít jak zjistit, jestli pilot skutečně fungoval.
A Quick Summary Stručné shrnutí
The pattern across all four failures is the same: the decisions that matter most happen before the tool is ever opened. Task definition, team structure, data policy, success metrics — all of that is organizational groundwork. The AI itself is almost the last thing that determines whether a procurement AI project succeeds. Vzorec ve všech čtyřech selháních je stejný: nejdůležitější rozhodnutí padají ještě předtím, než je nástroj vůbec otevřen. Definice úkolu, struktura týmu, politika dat, metriky úspěchu — to vše jsou organizační základy. Samotná AI je téměř poslední věcí, která určuje, zda projekt v nákupu uspěje.
If you're about to start an AI pilot and you haven't done those four things, that's where to start. Not with the tool. Pokud se chystáte spustit AI pilot a tyto čtyři věci jste ještě neudělali, začněte tam. Nikoliv nástrojem.
AI doesn't fail procurement teams. Procurement teams fail their AI pilots — by skipping the boring work that should have happened first. The good news: it's entirely preventable. AI neselhává nákupní týmy. Nákupní týmy selhávají své AI piloty — tím, že přeskočí nudnou práci, která měla proběhnout jako první. Dobrá zpráva: je to zcela předvídatelné a lze tomu předejít.