Firma je jeden produkt. A každý špatný proces je jeho technický dluh.

Většina firem nikdy nebyla navržena. Narostla. Nejprve byl zakladatel a jedna tabulka, potom obchodník s vlastním seznamem kontaktů, účetní s vlastním softwarem, výroba s vlastním plánováním. Každé rozhodnutí bylo tehdy obhajitelné, jejich součet po deseti letech nedává smysl téměř nikdy.

Užitečnější model je jiný: firma je jeden produkt. Má uživatele, rozhraní, toky, databáze, legacy, chyby i uživatelskou zkušenost. A stejně jako softwarový produkt si nese technický dluh, ze kterého se platí úroky, přestože je žádná účetní osnova nevede.

Není to metafora pro efekt, ale pracovní model, který mění místo, kde hledáte problém. Pokud je firma produkt, pomalá fakturace není selhání oddělení, ale defekt v toku. A defekt se neopravuje školením, ale překreslením toku.

Firma nevznikla najednou, narostla vrstvu po vrstvě

Oddělení vznikají jako odpověď na bolest. Něco přestane stíhat jeden člověk, tak se naberou dva s vlastním nástrojem i metrikou. Od té chvíle každé oddělení optimalizuje to, za co je měřeno: obchod počet podpisů, výroba využití kapacity, finance dobu inkasa, podpora čas první odpovědi. Každá z těch metrik je sama o sobě rozumná.

Lokální optimum jedné vrstvy však téměř vždy vyrábí práci navíc ve vrstvě vedle. Modelový příklad: obchodník sjedná nestandardní splatnost, protože ho měří počet smluv. Finance pak dělají ruční výjimku, výroba dostane termín, se kterým nikdo nepočítal, a podpora vysvětluje, proč faktura nesedí s nabídkou. Nikdo nepochybil, špatně je navržený systém.

Z pohledu zákazníka existuje jen jedna firma

Zákazník neví, kde končí obchod a kde začíná fakturace. Vidí jeden řetězec doteků a vnímá ho jako jeden zážitek. Customer experience, tedy zkušenost zákazníka napříč celým vztahem s firmou, není průměr těchto doteků. Blíž je k nejslabšímu článku řetězu: selhání si člověk zapamatuje lépe než hladký průběh a hodnotí podle něj celý vztah.

Proto se proces měří po celé délce, ne po odděleních. Otázka nezní, jak rychle pracuje sklad, ale kolik hodin uplyne od objednávky po doručení a kde zásilka jen leží.

Tři skupiny uživatelů téhož produktu

Každá skupina používá jinou část.

• Zákazník používá veřejné rozhraní: web, nabídku, objednávku, fakturu, podporu.
• Zaměstnanec používá interní rozhraní: systémy, formuláře, schvalování a tabulky, které mu nikdo nenavrhl, jen se nasbíraly.
• Management používá vrstvu dat a reportů, ze které dělá rozhodnutí.

Rozpočty to obvykle nekopírují. Veřejné rozhraní má vlastníka i metriku, interní zpravidla ani jedno, takže se do něj neinvestuje, dokud nezačne hořet. Přitom employee experience, tedy zkušenost zaměstnance s nástroji a pravidly vlastní firmy, se promítá do výkonu. Podle výzkumu MIT Center for Information Systems Research z roku 2017 na vzorku 281 senior manažerů byly firmy v horním kvartilu employee experience dvakrát inovativnější než firmy ve spodním kvartilu, měřeno podílem tržeb z nových produktů a služeb, a vykazovaly o 25 procent vyšší hodnotu na oborové metrice ziskovosti. Jde o korelace z manažerského sebehodnocení, ne o prokázanou příčinu. Čas strávený obcházením vlastního systému však nevytváří hodnotu pro nikoho.

Proces je user flow, jen ho nikdo nenakreslil

V produktovém designu je user flow posloupnost kroků, kterými uživatel prochází k cíli. Každý zbytečný krok stojí čas a zvyšuje šanci na chybu. Firemní proces je totéž, jen ho nikdo netestoval.

Tření se dá ocenit vzorcem, kterému říkáme Cost of Friction: čas jednoho opakování krát frekvence krát počet zapojených lidí krát hodinový náklad. Krok, který trvá chvíli, ale dělá ho denně celé oddělení, bývá dražší než projekt řešený jednou za rok. Bez tohoto výpočtu se priority vybírají podle toho, kdo nejhlasitěji křičí. Proč je design nástroj na úsporu času a peněz, jsme rozebrali v textu Dobrý design není dekorace.

Interní systémy jsou rozhraní firmy, značka je jen jeho titulní strana

V našem modelu má firma pět vrstev: Brand, Experience, Systems, Automation, Intelligence. Značka je externí rozhraní, tedy slib. Interní systémy jsou rozhraní, přes které ten slib někdo reálně plní. Pokud se rozcházejí, prohrává vždy slib: firma může mít vytříbený vizuál a přitom posílat potvrzení objednávky z osobní schránky skladníka.

Platí to i naopak: interní systém, který nikdo nechce používat, není problém disciplíny, ale designu. Lidé obcházejí firemní nástroje ze stejného důvodu, ze kterého zákazníci opouštějí špatný košík: cesta je delší, než musí být.

Data jsou infrastruktura, ne reporting

Pokud tentýž zákazník existuje v pěti systémech v pěti odlišných verzích, firma nemá zákazníka. Má pět domněnek. Datová architektura, tedy dohoda o tom, kde vzniká pravda o zákazníkovi, objednávce a ceně, je infrastruktura stejně jako elektřina. Není ji vidět, dokud nespadne.

Proto se vrstvy Automation a Intelligence nedají postavit dřív než vrstva Systems. Automatizace na nekonzistentních datech firmu nezrychlí, jen rychleji rozmnoží chybu. Popsali jsme to v článku AI nezachrání špatný proces.

Legacy proces je technický dluh a platí se z něj úroky

Metaforu technického dluhu zavedl Ward Cunningham v roce 1992 a její původní význam je přesnější, než se dnes obvykle cituje: dluh není synonymum nekvalitní práce, ale vědomé dočasné zjednodušení, které práci zrychlí, pokud se brzy splatí přepsáním. Nebezpečná není půjčka, nebezpečné je nesplácení. Každá minuta strávená prací s ne zcela správným kódem je podle Cunninghama úrok.

Přeloženo do firmy: legacy proces je postup, který přežil svůj vlastní důvod. Report se posílá každé pondělí, protože si ho před lety vyžádal manažer, který už ve firmě nepracuje. Nikdo to nezastavil, protože to nikoho nebolí dost nahlas.

Úroky jsou měřitelné. Podle longitudinální studie Beskera, Martiniho a Bosche, ve které 43 vývojářů sedm týdnů vykazovalo svou práci, ztrácejí vývojáři v průměru 23 procent času kvůli technickému dluhu. Jde o vlastní odhady účastníků, ne o objektivní měření. Studie ukazuje i druhou vlastnost dluhu: přibližně ve čtvrtině situací, kdy na dluh narazí, jsou vývojáři nuceni zavést další. Dluh se reprodukuje sám, přesně jako proces, ve kterém se výjimka řeší další výjimkou.

Konsorcium CISQ odhaduje akumulovaný technický dluh v softwaru ve Spojených státech na přibližně 1,52 bilionu dolarů. Sama zpráva přiznává, že jde o inflační úpravu staršího odhadu a dobrý odhad úroků zatím nemá. Poučnější je důsledek: technický dluh se stal největší překážkou změn v existujícím kódu. Ve firmě zní tatáž věta jednoduše: „to se u nás nedá změnit.“

Sila nejsou kulturní problém, jsou integrační problém

V roce 1968 zformuloval Melvin Conway pozorování, které známe jako Conwayův zákon: organizace navrhující systémy jsou nuceny vytvářet návrhy, které kopírují jejich vlastní komunikační struktury. Rozpad v organizaci se podle něj promítne do struktury systému. Nešlo o empirickou studii, ale o esej z praxe.

Potvrzení přišlo později. Výzkumníci z Microsoft Research a University of Maryland analyzovali vývoj systému Windows Vista, konkrétně 3 404 binárek a více než 50 milionů řádků kódu. Metriky organizační struktury předpověděly části systému náchylné k chybám s přesností 86,2 procenta a úplností 84,0 procenta, čímž překonaly objem změn v kódu, komplexitu i pokrytí testy. Autoři upozorňují, že jde o jednu firmu a jeden produkt, ale uspořádání lidí předpovídalo chyby lépe než vlastnosti kódu. Studie MacCormacka, Rusnaka a Baldwinové k tomu přidává zrcadlový efekt: u finančního softwaru mohla změna jednoho souboru zasáhnout v průměru 7,74 procenta systému při volně vázané organizaci oproti 47,14 procenta při těsně vázané.

Z toho plynou dvě věci. Pokud si dvě oddělení posílají práci e-mailem, přesně tak bude vypadat i vaše datová integrace. A dá se to obrátit: postup nazývaný Inverse Conway Maneuver záměrně mění strukturu týmů tak, aby z ní vznikla žádoucí architektura. Podle zprávy DORA z roku 2022 měly vysoce výkonné týmy, které plní své cíle spolehlivosti, o 40 procent vyšší pravděpodobnost, že stojí na volně vázané architektuře, tedy takové, kde tým zvládne velkou změnu bez čekání na jiné týmy. Jde o korelaci ze sebehodnoticího průzkumu více než 1 350 profesionálů.

Redesign firmy se dělá stejně jako redesign produktu

Posloupnost je stejná jako u produktu a nedá se přeskočit.

1. Výzkum. Rozhovory s lidmi, kteří práci reálně dělají, ne s jejich nadřízenými. Zajímá nás skutečnost, ne směrnice.
2. Mapování. Jeden proces od začátku do konce, se všemi čekáními, přepisy a výjimkami.
3. Prioritizace. Cost of Friction plus otázka, kde má malá změna velký dopad. Donella Meadows nazývá taková místa pákovými body a korporaci uvádí přímo jako příklad komplexního systému. Cituje přitom Jaye Forrestera: lidé páku obvykle najdou správně, jen jí tlačí opačným směrem.
4. Prototyp. Nový postup na jednom týmu, s měřením, ne celofiremní nasazení.
5. Implementace. Teprve tady přichází nástroj. Technologie je poslední rozhodnutí, ne první.
6. Měření. Stejná metrika před i po. Bez toho jde jen o názor.

Nad celou posloupností platí tvrdé pořadí zásahů: odstranit, zjednodušit, automatizovat, rozšířit. Nejprve zrušte, co není potřeba, potom zjednodušte, co zůstane, teprve pak automatizujte a nakonec rozšiřujte lidské schopnosti nástroji včetně AI. Kdo začne od třetího kroku, kupuje si dražší verzi původního problému. Jak by firma vypadala, kdyby se stavěla od nuly, jsme rozepsali v textu o firmě, která nepotřebuje armádu administrativních lidí.

Co nikdy neautomatizovat bez pochopení lidí

Neautomatizujte proces, kterému nerozumíte do detailu, který je plný výjimek nebo který jste nikdy neviděli dělat naživo. Automatizace je beton: zalije přesně ten tvar, který jí dáte, i s deformacemi.

Nezdokumentované obcházky jsou informace, ne sabotáž. Označují přesně to místo, kde je systém špatný. W. Edwards Deming odhadoval, že asi 94 procent problémů patří systému a je odpovědností managementu, zatímco zbylých 6 procent tvoří zvláštní příčiny. Formuloval to jako osobní odhad ze zkušenosti, ne jako naměřenou veličinu. I tak ale přesně vystihuje, proč výměna lidí zřídka pomůže. Podle poznámek účastníka jeho semináře z roku 1993 to řekl ještě tvrději: špatný systém porazí dobrého člověka pokaždé.

Ještě jedna věc, kterou v naší branži slyšíte málokdy: ne každý problém potřebuje vlastní software. Část procesů se opraví zrušením reportu, jedním sdíleným formulářem nebo krabicovým nástrojem za pár desítek eur měsíčně. Vlastní řešení má smysl teprve tam, kde je proces skutečně specifický a jeho tření převyšuje cenu vývoje i údržby. Kdo nabízí vývoj dřív, než pochopil proces, prodává nástroj, ne řešení.

Firma není soubor oddělení. Je to systém

Systémové myšlení znamená jedinou disciplínu: hodnotit chování celku, ne výkon částí. Firma s pěti výbornými odděleními a pěti špatnými přechody mezi nimi je pomalá. Zdržení a chyby totiž nevznikají v odděleních, ale v přechodech mezi nimi, kde proces nemá vlastníka.

Pokud přijmete, že firma je jeden produkt, změní se i otázky. Místo „kdo to pokazil“ přichází „kde v toku to vzniká“, místo „kupme systém“ přichází „který krok tu vůbec nemusí být“. A místo velké transformace přichází série malých zásahů v místech s největší pákou. První krok není nákup ani reorganizace, ale poctivá diagnóza jednoho konkrétního toku.

Co si z toho vzít

• Vyberte jeden proces, který se dotýká zákazníka, a zmapujte ho od prvního kontaktu po zaplacenou fakturu včetně čekání.
• Spočítejte Cost of Friction: čas krát frekvence krát počet lidí krát hodinový náklad. Teprve pak rozhodujte o pořadí změn.
• Udělejte si seznam legacy procesů jedinou otázkou na týmu: co děláme jen proto, že se to tak vždycky dělalo? Cokoli bez platného důvodu je splatný dluh.
• Držte pořadí odstranit, zjednodušit, automatizovat, rozšířit. Automatizace špatného procesu je jen dražší verze téhož problému.
• Před nákupem nástroje si odpovězte, který krok se jím ruší. Pokud žádný, nekupujete řešení, ale další vrstvu.