Mám za sebou projekty u největších globálních korporací i v bankovním sektoru. A pokaždé je to stejný příběh: na začátku bývá rozumný plán, rozdělené kompetence a soubor milníků. Realita se ale odehrává mezi nimi. Když chybí průběžný přehled o práci, rozhodnutí se ztrácí v e-mailech a když verze žijí vlastním životem, vzniká prostředí, které se špatně spravuje a ještě hůř předává. Jak často říkám, neefektivita nevzniká v kódu, ale v řízení a ve firemním prostředí. Technický problém je jen viditelný následek špatné organizace. Pak se i talentované týmy ocitají v bludném kruhu improvizací a zbytečně drahého a únavného reworku.

V praxi sledujeme stále stejné scénáře skládající se z drobných opomenutí: dokumentace, která se „dodělá později“, testy, které se doženou, release, který se spojí do velkého balíku, protože „teď hoří jinde“. V kritických odvětvích to pak znamená výpadky služeb a reputační škody. Zkušenost je pokaždé podobná: technické problémy jsou viditelné, ale příčina se nejčastěji najde ve špatné organizaci práce a kontroly.

Místo úspor a „svobody“ pak vidíme masivní finanční ztráty, které nejlépe dokládají kauzy, kde nekontrolovaný outsourcing způsobil selhání kritických systémů. Například selhání u Boeing 737 MAX, kde špatný vendor management a nedostatek kontroly vedly k tragickým haváriím kvůli chybám ve vývojovém softwaru. V Británii selhal outsourcovaný softwarový systém pro správu zdravotních záznamů (NHS) kvůli nekvalitnímu řízení a nedostatku transparentnosti, což vedlo ke zrušení projektu. I v ČR jsme viděli dramatické dopady slabého vendor managementu. Stačí si vzpomenout na závažné výpadky systému eRecept (SÚKL) v roce 2018 nebo na kolaps registru vozidel v roce 2012. Ve všech případech kritici poukazovali na stejný problém: klíčové části systému vznikaly bez transparentního dohledu a průběžného přebírání kódu.

Smyslem řízení externích dodavatelů není mikromanagement, ale nastavení hřiště tak, aby se na něm dalo bezpečně a předvídatelně hrát. Prakticky to znamená mít jasnou, sjednocenou cestu od prvního nápadu až po nasazení do provozu.

Základem je průběžně vidět, co se vyvíjí, v jakém je to stavu, a zavádět raději menší, ověřené a testované změny, než jeden velký rizikový balík na konci. Pro objednatele to znamená mít kdykoli po ruce aktuální kód, historii technických rozhodnutí i přehled o tom, co se právě ověřuje. Pro dodavatele je to jistota, že platí stejná pravidla pro všechny a že se rozhodnutí opírají o objektivní data, nikoli o pocity.

Když je tato transparentnost zajištěna, vývoj běží plynule: každá změna prochází stejnou, srozumitelnou dráhou, problémy se zachytí včas a provoz nikoho nezaskočí. Nástin řešení je přímočarý: sjednotit celou cestu. Důležité je dát oběma stranám jednotný zdroj informací o stavu projektu a domluvit se na pár jednoduchých metrikách.

V éře, kdy se mluví jen o plné automatizaci a umělá inteligence slibuje, že nahradí vývojáře, korporace dál tiše doplácejí na mnohem reálnějším a dražším problému. Nové technologie sice skvěle pomáhají automatizovat nudné úkony, ale AI nenahradí zdravý rozum a dohled.

Pokud teď nemáte přehled o kvalitě kódu a výkonu externího dodavatele, žádná AI za vás tuto základní manažerskou odpovědnost nepřevezme. Pořád potřebujete systém, který vám dává kompletní kontrolu a viditelnost.

 

Firmy se často drží starých kolejí, přestože jsou nefunkční. Investice do lepšího řízení vývoje se odsouvá, protože „teď není čas“ a „kontrola bude stát majlant“. Mezitím se potichu hromadí to, co v rozpočtu nevidíte.

V podstatě se platí dvakrát: jednou za dodávku, podruhé za opravu. Bez aktivního vendor managementu se z externí spolupráce stává černá skříňka.

Vendor Lock-in nebývá dramatický zvrat, spíš tiché přilnutí k jedinému dodavateli: kód je nestandardní, dokumentace kusá. Technologický dluh nenápadně roste: to, co se mělo zachytit v testech, se vrací v produkci a stojí násobky oproti včasné kontrole.

Průběžný dohled nad vývojem není mikromanagement. Znamená to držet se reality: mít přístup ke kódu a jeho verzím, průběžně přebírat menší dodávky a rozhodovat podle provozních dat, ne podle pocitu.

Technologický dluh a nepořádek se nepromítají jen do rozpočtu, ale přímo do kapacity celého IT oddělení. Týmy se začnou věnovat "hašení požárů" místo rozvoje produktu. Každý opravený bug je sice nutný, ale neposouvá firmu vpřed.

Zkušenost ukazuje, že jakmile překročí podíl reworku určitou, viditelnou hranici, vývojáři ztrácí soustředění a demotivují se. Není nic dražšího než talentovaný programátor, který tráví většinu svého dne opravováním chyb způsobených špatnou kontrolou v minulosti. To je přímá daň za neaktivní vendor management a plýtvání investic do chyb, které ani nemusely vzniknout. 

Je to jednoduchá matematika: „drahá kontrola“ bývá ve skutečnosti levnější než špatně zajeté koleje. Pokud má vývoj jasný plán, společnou viditelnost a průběžné ověřování, ubude nepříjemných překvapení a práce se dělá napoprvé správně. Nejde o to okamžitě vyměnit dodavatele, ale v první řadě získat objektivní data. Přesvědčení, že váš outsourcing „nějak funguje”, s sebou nese denní daň v podobě frustrace, zpožděných dodávek a nečekaných nákladů, které se v tabulkách neobjeví, dokud nebude pozdě. Bez systémového nástroje, který vám dá jednotnou, objektivní viditelnost do vývoje, zůstává vendor management jen prázdným pojmem a rizikem.

Pokud plánujete změnu a chcete ve firmě „uklidit”, nemusíte se děsit toho, že byste ji celou stavěli znova od základů. Stačí udělat několik srozumitelných kroků, které se stanou přirozenou součástí běžného provozu. Klíčem je přemýšlet o vendor managementu jako o pojistce. Zkuste si položit první, zásadní otázku: Představte si, že dnes večer končí váš dodavatel. Co by nový tým ráno potřeboval, aby okamžitě navázal? Kde je kód, jak se nasazuje, kdo schvaluje změny a podle čeho? Pokud odpovědi žijí jen v hlavách nebo byste je složitě skládali z několika e-mailů, je to signál, že transparentnost je téma pro „teď“.

A druhá otázka: Kdy jste naposledy převzali část práce tak, aby šla použít bez potřeby ladění a zásahů? Co nejde jednoduše popsat, nejde ani spolehlivě řídit. Pamatujte, že průběžný dohled není nedůvěra, ale prevence, která se vyplácí. Lock-in nevzniká jedním rozhodnutím, ale součtem drobných kompromisů. Pokud mu chcete předejít, potřebujete mít možnost kdykoli říct „bereme si to zpět“ a skutečně to udělat. Možná namítnete, že na to není prostor. Ve skutečnosti právě tyto kroky prostor vytvářejí: když vývoj postupuje předvídatelně a rozhoduje se podle dat z provozu, mizí nepříjemná překvapení, improvizace a krize.

Dnes existují platformy, které sjednotí cestu od požadavku po produkci, nastaví jednotná pravidla nasazování, automaticky sbírají důkazy o kvalitě a umožní průběžné přebírání menších dodávek. Nejsou náhradou dobrého řízení; jsou nosičem transparentnosti. Když máte kód vždy po ruce, historii rozhodnutí a metriky kvality, můžete si říct „bereme si to zpět“ – a skutečně to udělat.