Firma je jeden produkt. A každý zlý proces je jeho technický dlh.

Väčšina firiem nikdy nebola navrhnutá. Narástla. Najprv bol zakladateľ a jedna tabuľka, potom obchodník s vlastným zoznamom kontaktov, účtovníčka s vlastným softvérom, výroba s vlastným plánovaním. Každé rozhodnutie bolo vtedy obhájiteľné, ich súčet po desiatich rokoch nedáva zmysel takmer nikdy.

Užitočnejší model je iný: firma je jeden produkt. Má používateľov, rozhrania, toky, databázy, legacy, chyby aj používateľskú skúsenosť. A rovnako ako softvérový produkt si nesie technický dlh, z ktorého sa platia úroky, hoci ich žiadna účtovná osnova nevedie.

Nie je to metafora pre efekt, ale pracovný model, ktorý mení miesto, kde hľadáte problém. Ak je firma produkt, pomalá fakturácia nie je zlyhanie oddelenia, ale defekt v toku. A defekt sa neopravuje školením, ale prekreslením toku.

Firma nevznikla naraz, narástla vrstvu po vrstve

Oddelenia vznikajú ako odpoveď na bolesť. Niečo prestane stíhať jeden človek, tak sa naberú dvaja s vlastným nástrojom aj metrikou. Od tej chvíle každé oddelenie optimalizuje to, za čo je merané: obchod počet podpisov, výroba využitie kapacity, financie dobu inkasa, podpora čas prvej odpovede. Každá z tých metrík je sama o sebe rozumná.

Lokálne optimum jednej vrstvy však takmer vždy vyrába prácu navyše vo vrstve vedľa. Modelový príklad: obchodník dohodne neštandardnú splatnosť, lebo ho meria počet zmlúv. Financie potom robia ručnú výnimku, výroba dostane termín, s ktorým nikto nepočítal, a podpora vysvetľuje, prečo faktúra nesedí s ponukou. Nikto nepochybil, zle je navrhnutý systém.

Z pohľadu zákazníka existuje iba jedna firma

Zákazník nevie, kde končí obchod a kde začína fakturácia. Vidí jeden reťazec dotykov a vníma ho ako jeden zážitok. Customer experience, teda skúsenosť zákazníka naprieč celým vzťahom s firmou, nie je priemer týchto dotykov. Bližšie je k najslabšiemu článku reťaze: zlyhanie si človek zapamätá lepšie než hladký priebeh a hodnotí podľa neho celý vzťah.

Preto sa proces meria po celej dĺžke, nie po oddeleniach. Otázka neznie, ako rýchlo pracuje sklad, ale koľko hodín uplynie od objednávky po doručenie a kde zásielka iba leží.

Tri skupiny používateľov toho istého produktu

Každá skupina používa inú časť.

• Zákazník používa verejné rozhranie: web, ponuku, objednávku, faktúru, podporu.
• Zamestnanec používa interné rozhranie: systémy, formuláre, schvaľovania a tabuľky, ktoré mu nikto nenavrhol, iba sa nazbierali.
• Manažment používa vrstvu dát a reportov, z ktorej robí rozhodnutia.

Rozpočty to zvyčajne nekopírujú. Verejné rozhranie má vlastníka aj metriku, interné spravidla ani jedno, takže sa doň neinvestuje, kým nezačne horieť. Pritom employee experience, teda skúsenosť zamestnanca s nástrojmi a pravidlami vlastnej firmy, sa premieta do výkonu. Podľa výskumu MIT Center for Information Systems Research z roku 2017 na vzorke 281 senior manažérov boli firmy v hornom kvartile employee experience dvakrát inovatívnejšie než firmy v spodnom kvartile, merané podielom tržieb z nových produktov a služieb, a vykazovali o 25 percent vyššiu hodnotu na odvetvovej metrike ziskovosti. Ide o korelácie z manažérskeho sebahodnotenia, nie o dokázanú príčinu. Čas strávený obchádzaním vlastného systému však nevytvára hodnotu pre nikoho.

Proces je user flow, len ho nikto nenakreslil

V produktovom dizajne je user flow postupnosť krokov, ktorými používateľ prechádza k cieľu. Každý zbytočný krok stojí čas a zvyšuje šancu na chybu. Firemný proces je to isté, len ho nikto netestoval.

Trenie sa dá oceniť vzorcom, ktorý voláme Cost of Friction: čas jedného opakovania krát frekvencia krát počet zapojených ľudí krát hodinový náklad. Krok, ktorý trvá chvíľu, ale robí ho denne celé oddelenie, býva drahší než projekt riešený raz do roka. Bez tohto výpočtu sa priority vyberajú podľa toho, kto najhlasnejšie kričí. Prečo je dizajn nástroj na úsporu času a peňazí, sme rozobrali v texte Dobrý dizajn nie je dekorácia.

Interné systémy sú rozhranie firmy, značka je len jeho titulná strana

V našom modeli má firma päť vrstiev: Brand, Experience, Systems, Automation, Intelligence. Značka je externé rozhranie, teda sľub. Interné systémy sú rozhranie, cez ktoré ten sľub niekto reálne plní. Ak sa rozchádzajú, prehráva vždy sľub: firma môže mať vycibrený vizuál a pritom posielať potvrdenie objednávky z osobnej schránky skladníka.

Platí to aj opačne: interný systém, ktorý nikto nechce používať, nie je problém disciplíny, ale dizajnu. Ľudia obchádzajú firemné nástroje z rovnakého dôvodu, z akého zákazníci opúšťajú zlý košík: cesta je dlhšia, než musí byť.

Dáta sú infraštruktúra, nie reporting

Ak ten istý zákazník existuje v piatich systémoch v piatich odlišných verziách, firma nemá zákazníka. Má päť domnienok. Dátová architektúra, teda dohoda o tom, kde vzniká pravda o zákazníkovi, objednávke a cene, je infraštruktúra rovnako ako elektrina. Nevidno ju, kým nespadne.

Preto sa vrstvy Automation a Intelligence nedajú postaviť skôr než vrstva Systems. Automatizácia na nekonzistentných dátach firmu nezrýchli, iba rýchlejšie rozmnoží chybu. Popísali sme to v článku AI nezachráni zlý proces.

Legacy proces je technický dlh a platia sa z neho úroky

Metaforu technického dlhu zaviedol Ward Cunningham v roku 1992 a jeho pôvodný význam je presnejší, než sa dnes zvykne citovať: dlh nie je synonymum nekvalitnej práce, ale vedomé dočasné zjednodušenie, ktoré prácu zrýchli, pokiaľ sa čoskoro splatí prepísaním. Nebezpečná nie je pôžička, nebezpečné je nesplácanie. Každá minúta strávená prácou s nie celkom správnym kódom je podľa Cunninghama úrok.

Preložené do firmy: legacy proces je postup, ktorý prežil svoj vlastný dôvod. Report sa posiela každý pondelok, lebo si ho pred rokmi vyžiadal manažér, ktorý už vo firme nepracuje. Nikto to nezastavil, lebo to nikoho nebolí dosť nahlas.

Úroky sú merateľné. Podľa longitudinálnej štúdie Beskera, Martiniho a Boscha, v ktorej 43 vývojárov sedem týždňov vykazovalo svoju prácu, strácajú vývojári v priemere 23 percent času pre technický dlh. Ide o vlastné odhady účastníkov, nie o objektívne meranie. Štúdia ukazuje aj druhú vlastnosť dlhu: približne vo štvrtine situácií, keď na dlh narazia, sú vývojári nútení zaviesť ďalší. Dlh sa reprodukuje sám, presne ako proces, v ktorom sa výnimka rieši ďalšou výnimkou.

Konzorcium CISQ odhaduje akumulovaný technický dlh v softvéri v Spojených štátoch na približne 1,52 bilióna dolárov. Samotná správa priznáva, že ide o inflačnú úpravu staršieho odhadu a dobrý odhad úrokov zatiaľ nemá. Poučnejší je dôsledok: technický dlh sa stal najväčšou prekážkou zmien v existujúcom kóde. Vo firme znie tá istá veta jednoducho: „to sa u nás nedá zmeniť.“

Silá nie sú kultúrny problém, sú integračný problém

V roku 1968 sformuloval Melvin Conway pozorovanie, ktoré poznáme ako Conwayov zákon: organizácie navrhujúce systémy sú nútené vytvárať návrhy, ktoré kopírujú ich vlastné komunikačné štruktúry. Rozpad v organizácii sa podľa neho premietne do štruktúry systému. Nešlo o empirickú štúdiu, ale o esej z praxe.

Potvrdenie prišlo neskôr. Výskumníci z Microsoft Research a University of Maryland analyzovali vývoj systému Windows Vista, konkrétne 3 404 binárok a viac než 50 miliónov riadkov kódu. Metriky organizačnej štruktúry predpovedali časti systému náchylné na chyby s presnosťou 86,2 percenta a úplnosťou 84,0 percenta, čím prekonali objem zmien v kóde, komplexitu aj pokrytie testami. Autori upozorňujú, že ide o jednu firmu a jeden produkt, no usporiadanie ľudí predpovedalo chyby lepšie než vlastnosti kódu. Štúdia MacCormacka, Rusnaka a Baldwinovej k tomu pridáva zrkadlový efekt: pri finančnom softvéri mohla zmena jedného súboru zasiahnuť v priemere 7,74 percenta systému pri voľne viazanej organizácii oproti 47,14 percenta pri tesne viazanej.

Z toho plynú dve veci. Ak si dve oddelenia posielajú prácu e-mailom, presne tak bude vyzerať aj vaša dátová integrácia. A dá sa to obrátiť: postup nazývaný Inverse Conway Maneuver zámerne mení štruktúru tímov tak, aby z nej vznikla želaná architektúra. Podľa správy DORA z roku 2022 mali vysoko výkonné tímy, ktoré plnia svoje ciele spoľahlivosti, o 40 percent vyššiu pravdepodobnosť, že stoja na voľne viazanej architektúre, teda takej, kde tím zvládne veľkú zmenu bez čakania na iné tímy. Ide o koreláciu zo sebahodnotiaceho prieskumu vyše 1 350 profesionálov.

Redesign firmy sa robí rovnako ako redesign produktu

Postupnosť je rovnaká ako pri produkte a nedá sa preskočiť.

1. Výskum. Rozhovory s ľuďmi, ktorí prácu reálne robia, nie s ich nadriadenými. Zaujíma nás skutočnosť, nie smernica.
2. Mapovanie. Jeden proces od začiatku do konca, so všetkými čakaniami, prepismi a výnimkami.
3. Prioritizácia. Cost of Friction plus otázka, kde má malá zmena veľký dosah. Donella Meadows nazýva takéto miesta pákovými bodmi a korporáciu uvádza priamo ako príklad komplexného systému. Cituje pritom Jaya Forrestera: ľudia páku obvykle nájdu správne, len ňou tlačia opačným smerom.
4. Prototyp. Nový postup na jednom tíme, s meraním, nie celofiremné nasadenie.
5. Implementácia. Až tu prichádza nástroj. Technológia je posledné rozhodnutie, nie prvé.
6. Meranie. Rovnaká metrika pred aj po. Bez toho ide len o názor.

Nad celou postupnosťou platí tvrdé poradie zásahov: odstrániť, zjednodušiť, automatizovať, rozšíriť. Najskôr zrušte, čo netreba, potom zjednodušte, čo ostane, až potom automatizujte a nakoniec rozširujte ľudské schopnosti nástrojmi vrátane AI. Kto začne od tretieho kroku, kupuje si drahšiu verziu pôvodného problému. Ako by firma vyzerala, keby sa stavala od nuly, sme rozpísali v texte o firme, ktorá nepotrebuje armádu administratívnych ľudí.

Čo nikdy neautomatizovať bez pochopenia ľudí

Neautomatizujte proces, ktorému nerozumiete do detailu, ktorý je plný výnimiek alebo ktorý ste nikdy nevideli robiť naživo. Automatizácia je betón: zaleje presne ten tvar, ktorý jej dáte, aj s deformáciami.

Nezdokumentované obchádzky sú informácia, nie sabotáž. Označujú presne to miesto, kde je systém zlý. W. Edwards Deming odhadoval, že asi 94 percent problémov patrí systému a je zodpovednosťou manažmentu, kým zvyšných 6 percent tvoria zvláštne príčiny. Formuloval to ako osobný odhad zo skúsenosti, nie ako nameranú veličinu. Aj tak však presne vystihuje, prečo výmena ľudí zriedka pomôže. Podľa poznámok účastníka jeho seminára z roku 1993 to povedal ešte tvrdšie: zlý systém porazí dobrého človeka zakaždým.

Ešte jedna vec, ktorú v našej brandži počuť málokedy: nie každý problém potrebuje vlastný softvér. Časť procesov sa opraví zrušením reportu, jedným zdieľaným formulárom alebo krabicovým nástrojom za pár desiatok eur mesačne. Vlastné riešenie má zmysel až tam, kde je proces skutočne špecifický a jeho trenie prevyšuje cenu vývoja aj údržby. Kto ponúka vývoj skôr, než pochopil proces, predáva nástroj, nie riešenie.

Firma nie je súbor oddelení. Je to systém

Systémové myslenie znamená jedinú disciplínu: hodnotiť správanie celku, nie výkon častí. Firma s piatimi výbornými oddeleniami a piatimi zlými prechodmi medzi nimi je pomalá. Zdržania a chyby totiž nevznikajú v oddeleniach, ale v prechodoch medzi nimi, kde proces nemá vlastníka.

Ak prijmete, že firma je jeden produkt, zmenia sa aj otázky. Namiesto „kto to pokazil“ prichádza „kde v toku to vzniká“, namiesto „kúpme systém“ prichádza „ktorý krok tu vôbec nemusí byť“. A namiesto veľkej transformácie prichádza séria malých zásahov v miestach s najväčšou pákou. Prvý krok nie je nákup ani reorganizácia, ale poctivá diagnóza jedného konkrétneho toku.

Čo si z toho zobrať

• Vyberte jeden proces, ktorý sa dotýka zákazníka, a zmapujte ho od prvého kontaktu po zaplatenú faktúru vrátane čakaní.
• Spočítajte Cost of Friction: čas krát frekvencia krát počet ľudí krát hodinový náklad. Až potom rozhodujte o poradí zmien.
• Urobte si zoznam legacy procesov jedinou otázkou na tíme: čo robíme len preto, lebo sa to tak vždy robilo? Čokoľvek bez platného dôvodu je splatný dlh.
• Držte poradie odstrániť, zjednodušiť, automatizovať, rozšíriť. Automatizácia zlého procesu je len drahšia verzia toho istého problému.
• Pred nákupom nástroja si odpovedzte, ktorý krok sa ním ruší. Ak žiadny, nekupujete riešenie, ale ďalšiu vrstvu.