A valószínűségi munkafolyamatok rejtett költsége
Az a számla, amelyet a pilótafázisban senki sem látott
A pilótafázis olcsónak tűnt. Ez volt az első probléma. Egy csapat egy ismerős munkafolyamathoz kapcsolt egy AI-lépést: a beérkező dokumentumokat osztályozták, egy rövid összefoglaló készült, egy ajánlott útvonalat választottak ki, és egy emberi felülvizsgáló hagyta jóvá vagy módosította. A demó elegáns volt. A modell kompetensnek tűnt. A token-számla alacsonyabb volt, mint az ebédköltségvetés, ami mindenkit anyagilag érettnek éreztetett. Valaki kimondta a skálázható szót, és a terem rövid időre veszélyessé vált.
Három hónappal később a költségbeszélgetés megváltozott. A token-számla továbbra sem volt drámai. A rejtett költségek máshol voltak. A felülvizsgálók plusz perceket töltöttek a határesetek ellenőrzésével. Újrafuttatások jelentek meg, mert ugyanaz a bemenet néha kellően eltérő választ produkált. A kivételsorok nőttek. Az adatcsapatok azt vizsgálták, miért zavarta meg az osztályozót egy dokumentumtípus. A műveleti csapat mintavételezést adott hozzá. A jogi osztály bizonyítékot kért a vitatott esetekre. A vezetők azt kérdezték, miért vált kevésbé kiszámíthatóvá a ciklusidő. A mérnökök promptokat adtak hozzá, majd védőkorlátokat, majd tartalékokat, majd monitorozást, majd egy táblázatot, amelyet senki sem szeretett, de mindenki megnyitott. A munkafolyamat nem robbant szét. Varianciát szerzett.
Ez a valószínűségi munkafolyamatok rejtett költsége. A modellhívás a fogyasztás látható egysége, de a működési költséget a hívás körüli bizonytalanság hordozza. Egy valószínűségi komponens lehet hasznos, erőteljes és gazdaságilag ésszerű. Költséget is áthelyezhet a felülvizsgálatba, az egyeztetésbe, a bizonyítékokba, a támogatásba, a sorok kialakításába, az incidenselemzésbe, a minőségmérésbe és az emberi figyelembe. Ha ezeket a költségeket nem tervezik bele a munkafolyamatba, akkor is megérkeznek, általában kevesebb türelemmel.
A hagyományos munkafolyamat-rendszerek nem tökéletesek. Meghibásodnak, eltérnek, és a maguk unalmas módján meglepik az embereket. De gyakran van egy hasznos tulajdonságuk: ugyanaz a bemenet, állapot és szabály általában ugyanazt az eredményt hozza. A valószínűségi rendszerek gyengítik ezt a feltételezést. Néha ez a lényeg. Kezelik a kétértelműséget, a nyelvet, a képeket, a rendetlen dokumentumokat és a homályos szándékot. Jó. Az ár az, hogy a műveleteknek abba kell hagyniuk a színlelést, hogy a bizonytalanság csak egy demórészlet. Ez elsőrangú bemenet a költségmodellbe.
A variancia nem implementációs részlet
Probabilisztikus komponensek több ponton is varianciát vezetnek be. A modell némileg eltérő megfogalmazást produkálhat. Egy osztályozó a határérték közelében lévő esetet a küszöb bármelyik oldalára sorolhatja. Egy kereső az indexfrissítés után eltérő forráshalmazt adhat vissza. Egy összegző kihagyhat egy részletet, amely egy későbbi felülvizsgáló számára fontos lett volna. Egy eszközöket használó ügynök más hívási sorrendet választhat. Egyik sem automatikusan hiba. Csupán más anyag, mint a determinisztikus kód. Úgy kezelni, mint egy közönséges kódot, pusztán azért, mert van API-ja, kategóriahiba, amelynek számlái lesznek.
A varianciának működési következményei vannak. Növeli a mintavételezés és a felülvizsgálat iránti igényt. Megnehezíti az incidensek reprodukálását. Megnehezíti a teljesítmény mérését, mert az átlagos minőség elfedheti a szélsőséges instabilitást. Nézeteltérést szül a felhasználók között, akik különböző kimeneteket láttak. Törékennyé teheti a downstream rendszereket, ha azok stabil struktúrát várnak. Egy egyszerű szolgáltatási szintű megállapodást beszélgetéssé változtathat a valószínűségi eloszlásokról, ami remek módja annak, hogy kiderüljön, ki szereti a teremben igazán a matematikát.
Az első költség a döntési súrlódás. Amikor a kimenetek változnak, az emberek időt töltenek azzal, hogy eldöntsék, számít-e a változás. Egy e-mail-tervezet, amely ugyanazt mondja más szavakkal, elfogadható lehet. Egy orvosi összefoglaló, amely kihagy egy gyógyszert, nem az. Egy támogatási osztályozó, amely egy jegyet másként irányít, rendben lehet. Egy juttatási jogosultsági magyarázat, amely megváltoztatja az indoklását, nem az. A munkafolyamatnak toleranciamodellre van szüksége: melyik változat ártalmatlan, melyik igényel felülvizsgálatot, és melyik tilos.
A második költség a reprodukálhatóság. Ha egy ügyfél, állampolgár, könyvvizsgáló vagy mérnök megkérdezi, miért történt egy döntés, a szervezetnek reprodukálnia kell a releváns kontextust: modellverzió, prompt, keresési halmaz, bemenet, szabályzat, paraméterek, eszközkimenetek és emberi beavatkozás. E rekord nélkül a vizsgálat performansszá válik. Valaki újrafuttatja a promptot, más választ kap, és a terem keservesen megtanulja, hogy az újrapróbálkozás nem bizonyíték.
Az újrapróbálkozások nem ingyenesek csak azért, mert automatizáltak
Az újrapróbálkozások olcsónak tűnnek a kódból nézve. Ha a modell gyenge választ ad, hívd újra. Ha az osztályozó bizonytalan, kérj másik mintát. Ha egy JSON-válasz érvénytelen, javítsd ki. Ha az eszközhívás sikertelen, próbálj másik útvonalat. A gép végzi a munkát, ezért az ösztön az, hogy az újrapróbálkozásokat mérnöki ragasztóként kezeljük. Egy probabilisztikus munkafolyamatban az újrapróbálkozások szabályzatok. Azt döntik el, mennyi varianciát rejthet el a rendszer, mielőtt az ember meglátná.
Vannak jó okok az újrapróbálkozásra. Egy átmeneti hiba nem állíthatja meg a folyamatot. Egy hibás formátumú válasz gyakran kijavítható. Egy második átfutás kérése javíthatja a minőséget. De az újrapróbálkozások költséget és kétértelműséget is teremtenek. Melyik kimenet számít a rekordnak. Megtartjuk-e az összes próbálkozást. A későbbi próbálkozások felülírják-e a korábbiakat. Megmutatjuk-e a felülvizsgálónak az instabilitást. Az újrapróbálkozások a magabiztosabbnak hangzó válaszok felé torzítják-e a rendszert. Csak az olcsó eseteket próbáljuk-e újra, véletlenül lelassítva a fontos eseteket. Beleszámítjuk-e az újrapróbálkozásokat a költség- és késleltetési keretekbe. Az alázatos újrapróbálkozásnak sok véleménye van, ha egyszer beengeded a production környezetbe.
Az újrapróbálkozások az ösztönzőket is megváltoztatják. Ha a csapatok tudják, hogy a rendszer addig próbálkozik, amíg a kimenet meg nem felel az elvárt formának, alulberuházhatnak a bemenet minőségébe, a séma tervezésébe, a prompt-korlátozásokba vagy a determinisztikus előfeldolgozásba. Az újrapróbálkozás felmosórongy lesz. A felmosórongyok hasznosak. Egy felmosásra alapozott építési stratégia kevésbé lenyűgöző.
A jobb minta az, ha kategóriákba soroljuk az újrafuttatás okait. Az átmeneti infrastrukturális hiba az egyik kategória. A formázás javítása a másik. Az alacsony megbízhatóság a harmadik. A szabályzatütközés a negyedik. A forrásütközés az ötödik. Minden kategóriának szüksége van korlátokra, nyilvántartásra és eszkalációs szabályokra. Az újrafuttatást, amely elrejti a bizonytalanságot a felhasználó elől, másként kell kezelni, mint azt, amely csupán egy hálózati akadályból lábadozik. A költség nem csak a számítási kapacitás. Hanem annak a döntésnek a költsége, hogy a szervezet melyik bizonytalanságot kényelmes elrejteni.
A kivételsor a valódi architektúraábra
Minden valószínűségi alapú munkafolyamat előbb-utóbb a kivételsoron keresztül mutatja meg a valódi felépítését. Nem a boldog úton. A boldog út az, ahol az ábrák alkalmazottnak látszanak. A kivételsor mutatja meg, mely eseteket nem érti a rendszer, mely bemenetek piszkosak, mely szabályzatok ütköznek, mely felhasználóknak van szükségük támogatásra, mely küszöbértékek rosszak, és mely ígéreteket tették meg túl korán.
Ha a kivételsor jól van megtervezve, tanulási felületté válik. Az eseteket kategorizálják, mintavételezik, a megfelelő szerepkörök felülvizsgálják, összekötik a forrásadatok javításával, hozzákapcsolják a szabályzatváltozásokhoz, és visszavezetik az értékelésbe. Ha rosszul van megtervezve, mocsárrá válik. A nehéz esetek a hátralékban ülnek. A felülvizsgálók helyi szokásokat találnak ki. A vezetők csak mennyiséget látnak. A mérnökök csak összesített hibát látnak. A felhasználók késlekedést látnak. A modell rejtélyes marad, mert a szervezet a legjobb bizonyítékait operatív iszapba rejtette.
A kivételek költsége nem csak az esetek száma. Hanem az alakjuk. A tíz százalékos kivételarány kezelhető lehet, ha az esetek gyorsak, alacsony kockázatúak és könnyen útvonalazhatók. A két százalékos kivételarány költséges lehet, ha minden eset jogi értelmezést, szakterületi felülvizsgálatot, ügyfélkapcsolatot és bizonyíték-rekonstrukciót igényel. Az átlagos automatizáltsági arány ezért gyanús mérőszám. Azt mondja meg, mennyi ment át a gépen, nem azt, hogy mennyi költséget váltott ki a gép.
A kivételkezelés kialakításának explicitnek kell lennie. Határozzuk meg a megbízhatósági sávokat. Határozzuk meg a tartózkodást. Határozzuk meg, mely ütközések állítják le a munkafolyamatot. Határozzuk meg, mely szerepkörök mely osztályokat oldhatnak fel. Határozzuk meg a maximális sorkorlátot. Határozzuk meg az elfogadott esetek mintavételes felülvizsgálatát, nem csak a sikertelenekét. Határozzuk meg, mi javul, ha egy kivétel megismétlődik. Különben a szervezet nem automatizálta a munkát. Automatizálta egy második, kevésbé látható munka létrehozását.
A valószínűségi alapú kimenet tárgyalásra kényszeríti a downstream rendszereket
A szoftverrendszerek a szerződéseket kedvelik. A mező dátum. A státusznak megengedett értékei vannak. Az összegnek pontossága van. A szabálynak ága van. A valószínűségi kimenetek gyakran nyelvként, rangsorként, megbízhatóságként vagy részben strukturált találgatásként érkeznek. A downstream rendszerek ezután egyeztetnek. Értelmezik. Érvényesítik. Javítják. Újra kérdeznek. A homályos címkéket pontos állapotokra képezik le. Tartalékokat hoznak létre. Minden egyeztetés kis költség. Elég sok kis költségből lesz architektúra.
A strukturált kimenet segít, de nem szünteti meg a bizonytalanságot. Egy modell érvényes JSON-t tud előállítani, és mégis rossz kategóriát választ. Ki tud tölteni minden mezőt, és mégis kihagy egy feltételt. Tud forrást idézni, és mégis félreolvassa. A séma a formai hibákat fogja meg. Nem bizonyítja a jelentést. Ez gyakori csapda, mert a formai hibákat a gépek látják, a jelentésbeli hibákat pedig az emberek. Találd ki, melyiket javítják ki előbb.
A downstream egyeztetés a tulajdonjogot is megváltoztatja. Ha egy esetet rosszul irányítanak, mert a modell kimenete homályos volt, és az integrációs réteg találgatott, kié a hiba. A modellcsapaté. A platformcsapaté. A folyamatgazdáé. A lektoré. Az adatcsapaté. Mindenki tud elfogadható érvet felhozni, és ebből tudod, hogy hiányzik az üzemeltetési modell. A valószínűségi munkafolyamatoknak a határon kell tulajdonjogot kijelölniük, ahol a bizonytalanság rendszerállapottá válik.
Az egyik gyakorlati módszer a megbízhatóság, a teljesség és a következmény szétválasztása. A megbízhatóság azt mondja meg, mennyire valószínű a kimenet. A teljesség azt, hogy a szükséges bizonyíték jelen van-e. A következmény azt, hogy egy rossz művelet mekkora kárt okozhat. A nagy megbízhatóságú, hiányos bizonyítékú kimenet továbbra is felülvizsgálatot igényelhet. Az alacsony megbízhatóságú, alacsony következményű kimenet gyorsan továbbítható. A közepes megbízhatóságú, nagy következményű kimenet eszkalációt igényelhet. A munkafolyamat nem kezelhet minden bizonytalanságot ugyanolyan sárga színként.
Az értékelés visszatérő üzemeltetési költség
Sok csapat az értékelést projektfázisként kezeli. A bevezetés előtt összeállítanak egy tesztkészletet, futtatják a promptokat, összehasonlítják a kimeneteket, esetleg pontozzák a minőséget, és kijelentik a készültséget. Aztán jön a valóság új dokumentumokkal, új felhasználókkal, új élme esetekkel, új nyelvvel, új szabályzattal és új modellverziókkal. Az értékelési készlet öregedni kezd. Mint a sajt, csak kevésbé finom, és nagyobb valószínűséggel okoz megbeszélést.
A valószínűségi munkafolyamatoknak visszatérő értékelésre van szükségük. Ez gondozott eseteket, ellenséges eseteket, friss éles mintákat, regressziós tesztsorokat, domain-felülvizsgálatot, releváns esetekben méltányossági ellenőrzéseket, költség- és késleltetéskövetést, valamint olyan teszteket jelent, amelyek akkor futnak le, amikor a promptok, a modellek, a keresési indexek, a szabályzatok vagy a forrásadatok változnak. Az értékelés nem egyszeri kapu. Ez az üzemeltetési költségkeret annak megállapítására, hogy a munkafolyamat továbbra is megérdemli-e a forgalmat.
Ez a költség meglepi az embereket, mert a pilóta elrejti. A pilóta során a szakértők közel vannak a rendszerhez. Informálisan észreveszik a problémákat. A bemeneti összetétel korlátozott. A tét korlátozott. Élesben a rendszer annyira unalmassá válik, hogy a szakértők abbahagyják az egyes kimenetek figyelését, és pontosan ekkor kell átvennie a formális értékelésnek. A visszatérő értékelés nélküli valószínűségi rendszer olyan gép, amely lassan elkölti a bizalmat, miközben rendelkezésre állást jelent.
Az értékelést a döntésekhez is kötni kell. Ha romlik a minőség, ki állíthatja le. Ha nő a késleltetés, ki dönti el, hogy csökkentik-e a modell méretét, ritkítják-e az újrapróbálkozásokat, vagy bővítik-e a felülvizsgálati kapacitást. Ha egy új modell javítja az átlagpontszámot, de ront egy kritikus alcsoporton, ki utasítja el a frissítést. Ha a költség azért nő, mert a kivételek szaporodnak, kié a javítás. Az irányítópult, amely hanyatlást mutat, de nincs felhatalmazása a cselekvésre, csak drága időjárás-előrejelzés.
Az emberi felülvizsgálatnak sorbanállási elméleti ára van
Az emberi felülvizsgálatot gyakran megnyugtató frázisként említik. Egy ember a hurokban marad. Csinos. Melyik ember, milyen sorral, milyen kontextussal, milyen jogkörrel, milyen célidővel, milyen eszkalációs úttal, milyen fáradtságmodellel, és milyen védőhálóval, amikor a rendszer túl sok határesetet küld pénteken 16:45-kor. A huroknak logisztikája van. A logisztikának költségei vannak. A költségeknek bájos szokásuk, hogy az architektúra-diagram után bukkannak fel.
A felülvizsgálati kapacitás nem lineáris. A bizonytalan esetek kis növekedése nagy várakozási időnövekedést okozhat, ha a felülvizsgáló csapat a kapacitása közelében dolgozik. A sorbanállási elmélet kegyetlen, de igazságos. Ha az érkezések változékonyabbá válnak, és a kiszolgálási idő is változékonyabbá válik, a késések gyorsan nőhetnek. A valószínűségi munkafolyamatok gyakran mindkettőt növelik: egyenetlenebb esetnehézséget és változékonyabb felülvizsgálati időt. A szervezet azt hiheti, hogy a munka nyolcvan százalékát automatizálta, miközben a maradék húsz százalék csendben irányítja a szolgáltatási szintű megállapodást.
A felülvizsgálat minősége a kontextustól is függ. Ha a felülvizsgálók csak a végső választ látják, rekonstruálniuk kell, miért az jelent meg. Ha látják a forrásokat, a megbízhatóságot, a szabályzatot, a korábbi próbálkozásokat és az ismert bizonytalanságokat, gyorsabban és jobban tudnak cselekedni. Ha csak áteresztőképesség alapján mérik őket, megtanulnak túlságosan megbízni a gépben, vagy túl keveset küzdeni ellene. Az emberi felülvizsgálat nem varázsoldó, amit a bizonytalanságra öntenek. Ez képzett munka, amelyet meg kell tervezni.
A rejtett költség a figyelem. Az emberek nem tudnak korlátlan ideig korlátlan kétértelműséget felülvizsgálni. A fáradtság megváltoztatja a mércéket. Helyi szokások jelennek meg. Egyes felülvizsgálók szigorúak lesznek, mások pragmatikusak, megint mások beletörődők. A munkafolyamat attól függően kezd eltérő eredményeket produkálni, hogy ki kapta el az esetet. Aztán a valószínűségi rendszert hibáztatják azért az inkonzisztenciáért, amelyet a szervezet a felülvizsgálati tervezésben erősített fel. A gép szolgáltatta a szórást. Az emberek szolgáltatták a sor dinamikáját. Szép duett, ha a cél az auditfájdalom.
A költségelszámolásnak tartalmaznia kell a bizonytalanságot
A valószínűségi munkafolyamatok hasznos költségmodellje többet tartalmaz, mint a modellhívások. Tartalmazza a bemenet-előkészítést, a visszakeresést, az újrapróbálkozásokat, az érvényesítést, a felülvizsgálati időt, a kivételkezelést, az értékelést, a bizonyítéktárolást, az incidenselemzést, a megfigyelést, a felhasználótámogatást, a prompt- és szabályzatkarbantartást, az adatjavítást és a downstream javítást. Tartalmazza az opcionálisságot is: a modell, a szállító, a prompt, az index vagy a munkafolyamat megváltoztatásának költségét, amikor a jelenlegi felállás már nem illeszkedik.
Ez nem azt jelenti, hogy a valószínűségi alapú munkafolyamatok rosszak. Azt jelenti, hogy valóságosak. Sok közülük megéri a költségét. Egy olyan rendszer, amely csökkenti az ismétlődő olvasást, miközben kiemeli a kockázatos eseteket, kiváló lehet. Egy olyan osztályozó, amely jobban kezeli a rendezetlen szöveget, mint a szabályok, időt takaríthat meg. Egy olyan összefoglaló, amely jó első áttekintést ad a szakértőknek, javíthatja a szolgáltatást. A lényeg nem az, hogy elkerüljük a valószínűséget. A lényeg az, hogy ne rejtsük el annak működési költségét mások naptárában.
Az egyik hasznos elszámolási módszer az esetosztályonkénti árazás. A közvetlenül feldolgozott eseteknek van modell-, validációs és mintavételi költségük. A támogatott esetekhez felülvizsgálói idő járul. A kivételes esetekhez előszűrés, szakértői felülvizsgálat és bizonyítékköltség járul. A vitatott esetekhez reprodukció, kommunikáció és esetleges korrekció járul. A fejlesztési esetekhez adat- vagy promptkarbantartás járul. Ez az automatizálási arányt gazdagabb képpé változtatja: nem csak azt mutatja meg, hány esetet érintett az AI, hanem azt is, hogy a bizonytalanság hogyan változtatta meg a munkaterhelést és a kockázatot.
Egy másik módszer a varianciakeret nyomon követése. Mennyi kimeneti eltérés elfogadható ennél a feladatnál. Milyen gyakran térhetnek el egymástól az újrafuttatások. Hány kivételt képes naponta feldolgozni a sor. Mennyi felülvizsgálati idő van betervezve esetenként. Mennyi bizonyítékot kell tárolni. Milyen gyorsan kell reprodukálni a vitatott kimeneteket. Ezek a számok nem szüntetik meg a bizonytalanságot. Kormányozhatóvá teszik.
A determinizmusnak még mindig van szerepe
A valószínűségi rendszerek térnyerése nem teszi a determinisztikus mérnöki munkát régimódivá. Értékesebbé teszi a determinisztikus határokat. Használjon determinisztikus elemzést, ahol rendelkezésre áll a struktúra. Használjon explicit szabályokat, ahol a szabályzat egyértelmű. Használjon stabil visszakeresést, ahol a forrásoknak reprodukálhatónak kell lenniük. Használjon sémákat, érvényesítőket, véges állapotokat, verziózott promptokat, rögzített kiértékelési halmazokat és rögzített paramétereket. Használjon valószínűséget a feladat azon részére, amely valóban ítélőképességet igényel a kétértelműség felett, nem pedig arra a részre, amelyhez csak arra volt szükség, hogy valaki megírja az unalmas kódot.
Ez nem purizmus. Ez költségkontroll. Minden determinisztikus határ megszüntet egy helyet, ahol a variancia kiszivároghat. Egy olyan munkafolyamat, amely modellt használ a rendezetlen szöveg olvasásához, majd determinisztikus validálást a kötelező mezők ellenőrzéséhez, majd szabályokat az ismert szabályzat alkalmazásához, majd emberi felülvizsgálatot a nagy következményekkel járó bizonytalansághoz, általában könnyebben üzemeltethető, mint egy olyan munkafolyamat, amely mindent a modellre bíz, majd meglepődik, amikor a minden több véleményt is jelent.
A determinizmus a bizonyítékokat is javítja. Ha egy szabály aktiválódott, rögzítse a szabályt. Ha egy elemző kinyert egy mezőt, rögzítse a forrás helyét. Ha a visszakeresés rangsorolta a dokumentumokat, rögzítse az index verzióját és a pontszámokat. Ha a modell összefoglalót készített, rögzítse a promptot, a forráshalmazt, a modellverziót és a felülvizsgáló döntését. A cél nem az, hogy minden munkafolyamatot tárgyalóteremmé alakítsunk. A cél az, hogy a későbbi kérdések megválaszolhatók legyenek anélkül, hogy az egész mérnöki csapatot egy gyors egyeztetésnek nevezett megbeszélésre hívnánk.
A determinisztikus és valószínűségi munka közötti határt explicit módon kell feltüntetni a diagramokon és a költségvetésekben. Melyik lépés változhat. Melyik lépés nem változhat. Melyik lépés próbálható újra. Melyik lépést kell pontosan megismételni. Melyik lépés magyarázható statisztikailag. Melyik lépéshez kell nyilvántartás. Ha a csapat nem tudja meghúzni ezt a határt, nem tudja őszintén megbecsülni a költséget.
A tanulság
A valószínűségi munkafolyamatok rejtett költsége nem ok arra, hogy elkerüljük őket. Hanem ok arra, hogy őszintén számoljunk velük. A költség megjelenik az újrapróbálkozásokban, a felülvizsgálatokban, a kivételekben, a bizonyítékokban, az értékelésben, a várakozási sorokban, a támogatásban, és abban a lassabb munkában, amely eldönti, milyen eltérés elfogadható. Ha a munkafolyamat időt takarít meg a zökkenőmentes úton, de visszaköveteli azt a vitatott esetekben és az üzemeltetési ködben, akkor az üzleti terv csak félig készült el.
A jó valószínűségi működés azzal kezdődik, hogy a bizonytalanságot anyagként kezeljük. Nevezzük meg, hol lép be. Határozzuk meg, hol változhat. Rögzítsünk elég kontextust a döntések visszajátszásához. Tervezzük a kivételkezelő sorokat tanulási felületként. Adjunk a felülvizsgálóknak hatáskört és időt. Értékeljünk folyamatosan. Tartsuk meg a determinisztikus határokat ott, ahol csökkentik a költséget. Árazzuk be a kilépést és a változást. Ennek nagy része nem látványos. Ez annak a jele, hogy túlélheti az éles üzemet.
A modellhívás a könnyű tétel. A valódi kérdés az, hogy a szervezetnek mit kell tennie a hívás előtt és után ahhoz, hogy az eredményben meg lehessen bízni, azt meg lehessen kérdőjelezni, javítani és fejleszteni. A valószínűség képessé teheti a munkafolyamatokat. Kiszámíthatatlanabbá is teheti őket. A különbség nem varázslat. Hanem működés, amely az a hely, ahol a lenyűgöző demók vagy hasznossá vagy drágává válnak.