Pasca obstarávania v podnikovom AI
Ukážka vyhrala tender
Víťazná ukážka bola čistá. Používateľ položil otázku, systém odpovedal s citáciami, rozhranie navrhlo ďalší krok a dashboard ukázal projektované úspory so sebavedomím, aké si zvyčajne nechávajú pre letiskovú architektúru. Nákupný tím urobil svoju prácu tak, ako to proces definoval. Požiadavky sa zhromaždili, dodávatelia sa ohodnotili, bezpečnostné dotazníky sa vyplnili, právne klauzuly sa vyrokovali a vybrané riešenie vyzeralo ako najschopnejšia možnosť. Každý mohol ukázať na súbor a povedať, že sa postup dodržal.
O šesť mesiacov bol postup stále správny a prevádzka unavená. Dátové konektory fungovali na vzorových zdrojoch, ale zápasili so skutočným archívom. Kvalita odpovedí bola dobrá v prostredí dodávateľa a nekonzistentná vo vnútornom pracovnom toku. Ľudská kontrola trvala dlhšie, než sa čakalo, pretože nikto nevyčíslil náklady na dokazovanie. Dodávateľ mal plán rozvoja, kupujúci výnimky a prevádzka rad problémov, ktoré nezapadali do pôvodnej tabuľky požiadaviek. Nič nebolo podvodné. Nič nebolo šokujúce. Nákupný proces kúpil schopnosť AI a len čiastočne kúpil podmienky, za ktorých sa táto schopnosť mohla stať prácou.
Toto je nákupná pasca v podnikovom AI. Nákupný proces je postavený na porovnávanie produktov, znižovanie právnej expozície, kontrolu ceny a dokumentovanie spravodlivosti. To sú legitímne ciele. Ale hodnota AI sa objavuje v chaotickom strede medzi produktom a organizáciou: prístup k dátam, redesign pracovných tokov, zachytávanie dôkazov, školenie používateľov, riešenie výnimiek, aktualizácie modelov, bezpečnostný postoj, integračný dlh, požiadavky na audit, spätné väzby a zodpovednosť za výsledky. Ak nákup hodnotí viditeľný produkt a prevádzkové podmienky považuje za implementačný detail, organizácia kupuje sľub a dostáva projekt.
Pasca nie je v tom, že by kupujúci boli hlúpi. Väčšina kupujúcich pracuje so zdedenými šablónami a skutočným tlakom. Majú umožniť inovácie, znížiť riziko, konať rýchlo, kontrolovať náklady, uspokojiť bezpečnosť, rešpektovať regulácie a vyhnúť sa neskoršiemu obviňovaniu, čo je stručný opis práce s emocionálnym rozsahom zošívačky. Pasca je štrukturálna: podnikové AI sa nakupuje ako softvér, ale správa sa ako prevádzkový model.
Kúpiť výstup nie je kúpiť výsledok
Firemní kupujúci sa často pýtajú, či systém dokáže vytvoriť výstup: zhrnutie, klasifikáciu, odporúčanie, extrakciu, návrh, označenie rizika, výsledok vyhľadávania, analýzu, akciu v rámci pracovného postupu. Toto je rozumná otázka, a zároveň aj tá menšia. Väčšou otázkou je, či organizácia dokáže premeniť tento výstup na výsledok, za ktorý nesie zodpovednosť. Kto ho dostane. Čo s ním urobia. Aké dôkazy vidia. Kedy ho môžu odmietnuť. Čo sa stane, keď je nesprávny. Ako sa chyba napraví. Kto vlastní metriku po tom, čo dodávateľ odíde z miestnosti.
AI zhrnutie nie je výsledok. Pracovník, ktorý pomocou overeného zhrnutia prijme rýchlejšie a lepšie zdokumentované rozhodnutie, môže byť výsledkom. Rizikové skóre nie je výsledok. Triediaci proces, ktorý spravodlivo prideľuje prípady, zaznamenáva dôvody a rieši výnimky, môže byť výsledkom. Odpoveď chatbotu nie je výsledok. Znížená záťaž podpory bez zavádzania zákazníkov, straty eskalačných ciest alebo vytvárania neviditeľnej zodpovednosti môže byť výsledkom. Nákup musí kupovať cestu od generovaného výstupu k inštitucionálnemu správaniu.
Táto cesta prechádza cez oddelenia. Právne oddelenie sa zaujíma o právomoc a zodpovednosť. Bezpečnosť sa zaujíma o prístup a izoláciu. Dátové tímy sa zaujímajú o pôvod a kvalitu. Prevádzka sa zaujíma o fronty a personálne obsadenie. Financie sa zaujímajú o náklady a realizáciu prínosov. Ľudské zdroje sa môžu zaujímať o dizajn práce. Compliance sa zaujíma o dôkazy. Používatelia sa zaujímajú o to, či im systém pomáha, alebo ich potichu robí zodpovednými za strojové odhady. Verejné obstarávanie, ktoré tieto otázky považuje za zaškrtávacie políčka namiesto vstupov do dizajnu, vytvorí elegantnú dokumentáciu a krehké nasadenie.
Tento rozdiel mení aj ceny. Lacný nástroj, ktorý si vyžaduje drahé preskúmanie, manuálnu prípravu dát, vlastnú integráciu, dodatočnú správu, nejasné dôkazy a vysokú podporu, môže byť drahý. Drahší nástroj so silnejším exportom, pozorovateľnosťou, dizajnom rolí, dátovými zmluvami a kontrolami aktualizácií môže byť lacnejší na prevádzku. Obstarávanie to nevidí, ak porovnáva cenu licencie a zvyšok nazýva implementáciou. Implementácia je miesto, kde projekty AI ukrývajú svoje faktúry.
Kontrolný zoznam rastie okolo nesprávneho stredu
Firemné obstarávanie miluje kontrolné zoznamy, pretože kontrolné zoznamy vytvárajú poriadok a obhájiteľnosť. Podporuje systém jednotné prihlásenie. Šifruje dáta. Poskytuje audítorské záznamy. Podporuje náš jazyk. Integruje sa so systémami na správu dokumentov. Ponúka prístup na základe rolí. Má príbeh o správe modelov. Podporuje reportovanie. Tieto otázky sú užitočné. Problém je, že odpoveď áno môže skrývať veľkú plochu.
Áno k audítorským záznamom môže znamenať surové technické záznamy, ktoré si vyžadujú odbornú interpretáciu, nie dôkazy na úrovni prípadu použiteľné pre compliance. Áno k integrácii môže znamenať, že existuje API, nie že je pochopený chaotický obsahový model kupujúceho. Áno k prístupu na základe rolí môže znamenať roly v produkte, nie zosúladenie s modelom právomocí organizácie. Áno k exportu môže znamenať, že dáta odchádzajú ako ploché súbory bez pôvodu. Áno k ľudskému dohľadu môže znamenať tlačidlo na schválenie. Enterprise AI je oblasť, kde by po mnohých odpovediach áno malo nasledovať ukáž mi za nepriaznivých podmienok.
Kontrolný zoznam by mal rásť okolo prevádzkových otázok. Aké dôkazy musia prežiť. Ktoré zdroje dát sú autoritatívne. Ktoré polia sú príliš zastarané. Ktoré prípady použitia vyžadujú deterministické záznamy. Ktoré akcie potrebujú schválenie človekom. Ktoré chyby vyžadujú upozornenie. Ktoré zmeny vyžadujú opätovné vyhodnotenie. Ktoré závislosti od dodávateľa sú prijateľné. Ktoré práva na odchod sú nevyhnutné. Ktoré tímy musia zmeniť správanie. Ktoré kontroly sa budú testovať pred spustením. Kontrolný zoznam produktu bez prevádzkového modelu je nákupný zoznam pre kuchyňu, ktorú nikto nezmeral.
Vágne požiadavky majú zvláštne čaro. Udržiavajú tender široký, znižujú konflikty a nechávajú každého veriť, že jeho záujem je zahrnutý. Bohužiaľ, vágne požiadavky nezmiznú po zadaní zákazky. Znovu sa objavia ako žiadosti o zmeny, oneskorenia, spory a prezentácie riadiaceho výboru so stále opatrnejšími slovami. Konkrétnosť sa pred podpisom zmluvy zdá pomalá. Po ňom je často oveľa rýchlejšia.
Prenos rizika je často divadlo
Procesy obstarávania sa snažia preniesť riziko. Zmluvy, záruky, odškodnenia, úrovne služieb, certifikácie, poistenie, podmienky spracovania údajov. Na týchto veciach záleží. Vyspelé nakupovanie ich potrebuje. Ale podniková AI vytvára riziká, ktoré sa nedajú úplne preniesť, pretože žijú v kontexte kupujúceho. Dodávateľ môže poskytnúť nástroj, záruky, podporu a dôkazy. Kupujúci vlastní dáta, pracovný postup, právomoci, správanie používateľov, cestu eskalácie a rozhodnutie, ktoré výstup prijíma. Zmluva nemôže outsourcovať úsudok, ktorý sa odohráva vnútri inštitúcie.
Tu sa niektoré organizácie stávajú príliš sebavedomými. Dodávateľ prešiel bezpečnostnou previerkou. Model má dokumentáciu. Podmienky pokrývajú ochranu údajov. Služba má záväzky týkajúce sa dostupnosti. Dobre. Teraz kto rozhoduje, či sa odpoveď s nízkou mierou istoty môže použiť v prípade s vysokým dopadom. Kto si všimne, keď používatelia prestanú kontrolovať. Kto rieši výzvu zákazníka. Kto overuje, že tréningové príklady zodpovedajú skutočnej práci. Kto pozastaví systém, keď sa zmení politika. Ak je odpoveďou dodávateľ, kupujúci si možno kupuje vládnu fantáziu. Ak je odpoveďou nikto, kupujúci si kúpil budúci incident.
Prenos rizika tiež vytvára zvrátené stimuly, keď kupujúci žiadajú dodávateľov, aby prevzali zodpovednosť za veci, ktoré môže kontrolovať iba kupujúci. Dodávateľ reaguje výnimkami, opatrnou konfiguráciou, nafúknutými cenami alebo vágnymi záväzkami. Kupujúci reaguje ďalšími klauzulami. Nakoniec sa zmluva stane vypchatou miestnosťou okolo pracovného postupu, ktorý nikto nenavrhol. Na papieri veľmi bezpečné. V utorok menej užitočné.
Lepší prístup je alokácia rizika. Pomenujte riziko. Priraďte časť, ktorú môže kontrolovať dodávateľ. Priraďte časť, ktorú musí prevádzkovať kupujúci. Definujte spoločné testy. Definujte dôkazy. Definujte eskaláciu. Definujte práva na pozastavenie. Definujte kontrolu zmien. Toto je menej uspokojujúce ako predstierať, že riziko bolo exportované v zip súbore. Je to tiež bližšie k realite, tvrdohlavej vlastnosti úspešných operácií.
Pilot nie je obstarávacia jednotka
Mnohé firemné nákupy umelej inteligencie začínajú pilotným projektom. Je to pochopiteľné. Pilotné projekty znižujú neistotu a pomáhajú tímom učiť sa. Nákupná pasca nastáva vtedy, keď sa pilotný projekt stane jednotkou dôkazu. Pilotný projekt je často chránený skúsenými používateľmi, vybranými údajmi, priamou pozornosťou dodávateľa, uvoľnenou integráciou, dočasným riadením a publikom, ktoré je ochotné odpustiť nedostatky. Produkcia je iná. Produkcia má objem, fluktuáciu zamestnancov, audity, okrajové prípady, bezpečnostné obmedzenia, požiadavky na podporu, pravidlá uchovávania, zmenené priority a používateľov, ktorí sa nezúčastnili na inšpiratívnom úvodnom stretnutí.
Pilotný projekt by preto mal testovať produkčné predpoklady, nielen schopnosti produktu. Dokážu bežní používatelia dokončiť pracovný postup. Drží si kvalita odpovedí na reálnych údajoch. Koľko času si vyžaduje kontrola. Ktoré záznamy sú potrebné na audit. Ktoré výnimky sú časté. Ktoré integračné body sú krehké. Čo sa stane, keď je zdroj zastaraný. Dokáže systém správne odmietnuť. Dokáže organizácia fungovať bez inžinierov dodávateľa v chate celý deň. Ak sa tieto otázky odložia až po schválení rozšírenia, pilotný projekt je divadlo s lepším občerstvením.
Jednotkou nákupu by mal byť riadený prevádzkový výsek. Výsek zahŕňa prípad použitia, zdroje údajov, oprávnenia, používateľov, postup kontroly, dôkazy, model podpory, proces zmien a cestu ukončenia. Je užší ako stratégia a väčší ako demo. Dá sa zmysluplne vyhodnotiť, pretože obsahuje veci, ktoré vytvárajú hodnotu, aj veci, ktoré vytvárajú náklady. Ak výsek funguje, rozšírenie znamená opakovanie a prispôsobenie známeho vzoru. Ak funguje iba nástroj, rozšírenie znamená objavovanie organizácie závislosť za závislosťou.
Preto by metrika pilotného projektu mala zahŕňať aj nudné čísla. Minúty kontroly na prípad. Percento opravených výstupov. Prípady odmietnuté pre chýbajúce dôkazy. Zlyhania aktuálnosti zdroja. Počet eskalácií. Dôvody nesúhlasu používateľov. Úplnosť exportu. Incidenty vyžadujúce podporu dodávateľa. Čas na vysvetlenie spochybneného výstupu. Tieto metriky sú menej atraktívne ako zvýšenie produktivity. Sú to však čísla, ktoré rozhodujú o tom, či produktivita prežije.
Prístup k údajom nie je zoznam konektorov
Nákupné dokumenty sa často pýtajú, ktoré systémy produkt spája. To je nevyhnutné, ale nedostatočné. Konektor sú dvere. Nepovie vám, či miestnosť obsahuje označené police, aktuálne záznamy, zákonný prístup, konzistentné identifikátory, použiteľné dokumenty, zachovaný kontext alebo podlahu. Firemné údaje málokedy trpezlivo čakajú. Obsahujú staré polia, duplicitné záznamy, PDF s tajomstvami, archeológiu v SharePointe, rezortné taxonómie, chýbajúcich vlastníkov a súbory s názvom final, pretože optimizmus je obnoviteľný.
Kupujúci musí pochopiť, čo systém umelej inteligencie potrebuje od údajov, nielen kde údaje žijú. Potrebuje celé dokumenty alebo extrahované polia. Potrebuje aktuálny stav alebo historické snímky. Potrebuje vyhľadávanie zohľadňujúce oprávnenia. Potrebuje líniu pôvodu. Potrebuje štruktúrované označenia. Potrebuje propagáciu vymazania. Potrebuje prahy kvality údajov. Potrebuje ľudskú korekciu. Každá potreba mení náklady na integráciu a riadenie. Konektor, ktorý tieto potreby ignoruje, je len hadica. Hadice sú užitočné. Tiež sú dôvodom, prečo sa pivnice zaplavia.
Prístup k údajom má právne a spoločenské rozmery. Systém môže technicky čítať zdroj a napriek tomu nemusí mať právo používať ho na trénovanie modelu, analýzy, monitorovanie zamestnancov alebo podporu automatizovaného rozhodovania. Používatelia môžu dôverovať úložisku na jeden účel a namietať, keď sa jeho obsah stane palivom pre iný. Nákup, ktorý sa pýta, či sa môžeme pripojiť, predtým ako sa spýta, či môžeme použiť, vytvára budúce prekvapenie. Prekvapenie je zlý mechanizmus súhlasu.
Kvalitný nákup AI preto zahŕňa náležitú starostlivosť o dáta pred zadaním zákazky, alebo aspoň pred jej rozšírením. Preskúmajte neusporiadaný korpus. Otestujte extrakciu. Skontrolujte povolenia. Zmerajte duplicitu. Identifikujte zastarané polia. Určte správcov dát. Overte uchovávanie a súhlasy. Pochopte, ktoré dáta sa nedajú presunúť. Vyčísľte náklady na vyčistenie. Ak sa vám zdá, že táto práca odďaľuje nákup, pamätajte, že nákup by rovnaký chaos aj tak objavil neskôr, len už so zmluvou.
Riadenie zmien je produkt
Podniková AI nezostáva stáť. Modely sa aktualizujú. Prompty sa menia. Indexy vyhľadávania sa prestavujú. Politiky sa posúvajú. Zdroje dát sa presúvajú. Používatelia objavujú okrajové prípady. Bezpečnostné pravidlá sa sprísňujú. Pribúdajú nové nariadenia. Systém, ktorý prešiel obstarávaním, nie je systém, ktorý bude organizácia prevádzkovať o rok neskôr. Riadenie zmien preto nie je administratívna záťaž okolo produktu. Je súčasťou produktu.
Obstarávanie by sa malo pýtať, ako sa navrhujú, testujú, schvaľujú, komunikujú, vracajú späť a dokladujú zmeny správania. Môže kupujúci oddialiť aktualizáciu modelu? Môžu byť zmeny promptov verzované? Dajú sa zmeny vyhľadávania porovnávať? Môžu byť balíky politík ukotvené? Poskytuje dodávateľ poznámky k vydaniu, ktoré mapujú operačné riziká, a nie marketingovú poéziu? Môžu byť vysoko rizikové prípady regresne testované pred nasadením? Môže organizácia vidieť, ktoré prípady boli zmenou ovplyvnené? Bez týchto práv si kupujúci nekúpil systém. Prihlásil sa na odber pohybu.
Interné zmeny sú rovnako dôležité ako zmeny dodávateľa. Oddelenie zmení formulár. Tím pre politiky upraví usmernenia. Dátový tím zmení názov poľa. Manažér upraví personálne obsadenie. Zmení sa právny výklad. Systémy AI sídlia na pomedzí týchto hraníc, takže malé interné zmeny môžu posunúť výstupy. Obstarávanie to nedokáže vyriešiť samo, ale môže vyžadovať prevádzkový model, ktorý pohyb odhaľuje a riadi. Ak sa každá zmena považuje za miestne zlepšenie niekoho iného, pracovný tok AI sa stane chodbou, kde sa dvere stále otvárajú do ľudí.
Dobré riadenie zmien dáva inováciám cestu. Neblokuje aktualizácie. Robí aktualizácie čitateľnými. Tímy môžu zlepšovať modely a pracovné toky rýchlejšie, keď vedia, ako testovať, schvaľovať a obnovovať. Opakom riadenia zmien nie je agilita. Je to neriadený drift s kalendárom vydaní.
Používatelia nie sú ciele adopcie
Obstarávanie často vníma používateľov ako ciele adopcie. Vyškolte ich, komunikujte výhody, merajte používanie, oslavujte šampiónov, odstraňujte prekážky. Niečo z toho je užitočné. Používatelia sú však aj kontrolné body, doménoví experti a systémy včasného varovania. Ak systému nedôverujú, možno odolávajú zmene. Môžu tiež zisťovať, že pracovnému postupu chýba dôkaz, autorita, čas alebo oprava. Proces obstarávania, ktorý používateľov vníma najmä ako ľudí, ktorých treba presvedčiť, prehliadne informácie, ktoré nesú.
Pred nákupom sa porozprávajte s ľuďmi, ktorých práca pohltí výstup AI. Opýtajte sa, aké dôkazy potrebujú na konanie. Ktoré prípady sú nebezpečné. Ktoré dátové polia sú nespoľahlivé. Ktoré výnimky spotrebúvajú čas. Ktoré rozhodnutia by nedelegovali. Ktoré chyby by boli trápne, škodlivé alebo nezákonné. Ktoré časti súčasného procesu sú neformálne, pretože formálny systém sa nikdy nenaučil realitu. Tieto odpovede nie sú odpor voči zmene. Sú to požiadavky s odtlačkami prstov.
Po nákupe by spätná väzba používateľov mala napájať riadenie zmien a dôkazy. Opravy, prepísania, eskalácie a dôvody odmietnutia by sa mali merať a diskutovať. Ak používatelia systém ignorujú, zistite, či je nesprávny, pomalý, nedôveryhodný, zle umiestnený, nesúladný s motivačnými stimulmi alebo jednoducho menej užitočný, než príbeh obstarávania. Samotné používanie je slabá miera hodnoty. Ľudia používajú zlé systémy, keď sú nútení, a vyhýbajú sa dobrým systémom, keď ich okolitý proces trestá za používanie úsudku.
Používatelia si tiež zaslúžia jasnosť. Ak je výstup AI poradný, povedzte to. Ak je povinný, povedzte, kto vlastní rozhodnutie. Ak sú prepísania vítané, netrestajte ich ako odchýlku. Ak sú dôkazy povinné, dajte čas na ich preskúmanie. Podniková AI zlyháva, keď sa používatelia stanú ľudskými nárazníkmi medzi sebavedomým nástrojom a nejasnou inštitúciou. To nie je adopcia. To je izolácia.
Test odchodu by sa mal uskutočniť pred vstupom
Odchod je najzanedbanejšia požiadavka obstarávania, pretože nikto nechce diskutovať o konci na začiatku. A predsa práve pri odchode sa kúpna sila stáva skutočnou. Môže organizácia odísť s dátami, metadátami, promptmi, konfiguráciami, záznamami o vyhodnotení, auditnými logmi, spätnou väzbou používateľov, výstupmi modelov, stopami opráv a dôkazmi o vymazaní neporušenými. Môže vypnúť systém bez straty schopnosti vysvetliť minulé rozhodnutia. Môže migrovať na iný nástroj bez toho, aby žiadala zamestnancov, aby pamäť inštitúcie odfotografovali obrazovku po obrazovke.
Test odchodu by mal byť praktický. Pred škálovaním exportujte reprezentatívny výrez. Obnovte ho inde. Skontrolujte identifikátory, časové pečiatky, pôvod, povolenia, prílohy, opravy a záznamy o rozhodnutiach. Overte, či dôkazy zostávajú čitateľné. Skontrolujte, či jazyk zmluvy zodpovedá technickej realite. Ak je export pomalý, stratový alebo závislý od zákazkovej práce dodávateľa, ocenite túto závislosť. Nádej nie je stratégia odchodu. Je to nálada so zlou správou verzií.
Práva na odchod tiež zlepšujú súčasný vzťah. Keď sú dáta a záznamy prenosné, dodávatelia súťažia na základe služieb a hodnoty, nie zajatia. Kupujúci sa menej boja úprimného vyhodnotenia. Interné tímy môžu navrhovať s ohľadom na výmenu. Architektúra sa stáva čistejšou, pretože význam musí byť explicitný. Odchod nie je pesimizmus. Je to hygiena.
Existuje príslovie o obstarávaní, ktoré čaká na napísanie: nikdy nekupujte systém AI, ktorý nemôžete opustiť bez toho, aby ste zabudli, prečo ste ho používali. Je príliš dlhé na hrnček, čo je pravdepodobne dobre. Hrnčeky už majú v kancelárskej kultúre čo vysvetľovať.
Únik z pasce
Únik z nákupnej pasce nevyžaduje hrdinský prevrat. Vyžaduje presun ťažiska nákupu z produktu na pracovný systém. Presne definujte prípad použitia. Včas otestujte reálne dáta. Ohodnoťte náklady na kontrolu. Vyžadujte dôkazy, ktoré odpovedajú na inštitucionálne otázky. S riadením zmien zaobchádzajte ako s primárnou požiadavkou. Kúpte si práva na odchod. Zapojte používateľov ako svedkov domény. Prideľte vlastníctvo výsledkov. Merajte záťaž na opravy a výnimky. Donútte dodávateľov ukázať systém v nepriaznivých podmienkach, pretože práve v nepriaznivých podmienkach trávi podnikový softvér väčšinu svojho života.
To spôsobí, že nákup bude na začiatku menej uhladený. Vynoria sa konflikty, ktoré kontrolné zoznamy predtým skrývali. Vlastníci dát zistia svoje povinnosti. Právne oddelenie bude potrebovať prevádzkové detaily. Bezpečnosť bude žiadať dôkazy. Prevádzka bude žiadať personál. Financie uvidia náklady, ktoré predtým číhali v kríkoch. Dobre. Skrytý náklad je stále náklad, len samol'úby.
Cieľom nie je natrvalo spomaliť nakupovanie. Cieľom je urobiť nákup natoľko čestným, aby sa implementácia mohla pohnúť vpred. Jasná prevádzková zmluva znižuje neskoršie spory. Otestovaná dátová cesta znižuje prekvapenia pri integrácii. Reálny model kontroly znižuje divadlo adopcie. Fungujúci odchod znižuje strach. Nákup sa stáva spôsobom, ako vytvoriť podmienky pre hodnotu, namiesto rituálu, ktorý vyberá najpresvedčivejší sľub.
Víťazná ukážka v úvodnom príbehu nebola nesprávna. Bola neúplná. Ukázala odpoveď, nie inštitúciu okolo odpovede. Nákup podnikovej umelej inteligencie sa musí naučiť kupovať aj túto vrstvu zameranú na inštitúciu: nudné práva, záznamy, roly, testy a odchody, ktoré menia schopnosť na riadenú prácu. Inak bude tender naďalej vyberať systémy, ktoré vyzerajú hotové pri zadaní zákazky a začnú sa stávať skutočnými až potom, čo sú všetci zmluvne zaviazaní. To je drahý spôsob, ako sa naučiť to, čo by lepšia otázka mohla odhaliť skôr.