A vállalati MI beszerzési csapdája
A demó megnyerte a tendert
A nyertes demó tiszta volt. A felhasználó feltett egy kérdést, a rendszer hivatkozásokkal válaszolt, a felület javasolta a következő lépést, az irányítópult pedig a várható megtakarításokat mutatta azzal az önbizalommal, amelyet általában a repülőtéri építészetnek tartanak fenn. A beszerzési csapat elvégezte a dolgát, ahogyan a folyamat meghatározta. Összegyűjtötték a követelményeket, értékelték a szállítókat, kitöltötték a biztonsági kérdőíveket, egyeztették a jogi záradékokat, és a kiválasztott megoldás a legalkalmasabb opciónak tűnt. Mindenki rámutathatott a dokumentumra, és mondhatta, hogy az eljárást betartották.
Hat hónappal később az eljárás még mindig helyes volt, a működés viszont fáradt. Az adatkapcsolatok a mintaforrásokon működtek, de a valódi archívummal küszködtek. A válaszminőség a szállítói környezetben jó volt, a belső munkafolyamatban viszont ingadozó. Az emberi felülvizsgálat a vártnál tovább tartott, mert senki sem árazta be a bizonyítékterhet. A szállítónak volt ütemterve, a vevőnek kivételei, a műveleti csapatnak pedig egy sor olyan problémája, amely nem illett az eredeti követelménytáblázatba. Semmi sem volt csalárd. Semmi sem volt megdöbbentő. A beszerzési folyamat megvásárolt egy mesterséges intelligencia képességet, és csak részben vásárolta meg azokat a feltételeket, amelyek mellett ez a képesség működővé válhat.
Ez a beszerzési csapda a vállalati mesterséges intelligenciában. A vásárlási folyamat arra épül, hogy összehasonlítsa a termékeket, csökkentse a jogi kockázatot, ellenőrizze az árat és dokumentálja a méltányosságot. Ezek legitim célok. Az MI értéke azonban a termék és a szervezet közötti rendezetlen középben jelenik meg: adathozzáférés, munkafolyamat-újratervezés, bizonyítékrögzítés, felhasználói képzés, kivételkezelés, modellfrissítések, biztonsági helyzet, integrációs adósság, auditkövetelmények, visszacsatolási hurkok és az eredmények felelőssége. Ha a beszerzés a látható terméket pontozza, miközben a működési feltételeket megvalósítási részletként kezeli, a szervezet ígéretet vásárol, és projektet kap.
A csapda nem az, hogy a vásárlók ostobák. A legtöbb vásárló örökölt sablonokkal és valódi nyomással dolgozik. Arra kérik őket, hogy támogassák az innovációt, csökkentsék a kockázatot, gyorsan cselekedjenek, ellenőrizzék a költségeket, elégítsék ki a biztonságot, tartsák tiszteletben a szabályozást, és kerüljék el, hogy később őket hibáztassák, ami egy tömör munkaköri leírás egy tűzőgép érzelmi skálájával. A csapda strukturális: a vállalati MI-t úgy szerzik be, mint egy szoftvert, de úgy viselkedik, mint egy működési modell.
Kimenet vásárlása nem eredmény vásárlása
Enterprise buyers often ask whether the system can produce the output: summary, classification, recommendation, extraction, draft, risk flag, search result, analysis, workflow action. This is a reasonable question and also the small question. The larger question is whether the organisation can turn that output into an outcome with responsibility attached. Who receives it. What do they do with it. Which evidence do they see. When may they reject it. What happens when it is wrong. How is the mistake repaired. Who owns the metric after the vendor leaves the room.
An AI summary is not an outcome. A caseworker using a verified summary to make a faster, better documented decision may be an outcome. A risk score is not an outcome. A triage process that routes cases fairly, records reasons and handles exceptions may be an outcome. A chatbot answer is not an outcome. A reduced support load without misleading customers, losing escalation routes or creating invisible liability may be an outcome. Procurement must buy the path from generated output to institutional behaviour.
This path crosses departments. Legal cares about authority and liability. Security cares about access and isolation. Data teams care about lineage and quality. Operations cares about queues and staffing. Finance cares about cost and benefits realisation. HR may care about work design. Compliance cares about evidence. Users care about whether the system helps or quietly makes them accountable for machine guesses. A tender that treats these concerns as sign-off boxes rather than design inputs will produce elegant paperwork and a fragile deployment.
The distinction also changes pricing. A cheap tool that requires expensive review, manual data preparation, custom integration, extra governance, unclear evidence and high support may be expensive. A more expensive tool with stronger export, observability, role design, data contracts and update controls may be cheaper to operate. Procurement cannot see this if it compares license price while calling the rest implementation. Implementation is where AI projects keep their invoices.
The checklist grows around the wrong centre
Enterprise procurement loves checklists because checklists create order and defensibility. Does the system support single sign-on. Does it encrypt data. Does it provide audit logs. Does it support our language. Does it integrate with document systems. Does it offer role-based access. Does it have a model governance story. Does it support reporting. These questions are useful. The problem is that yes can hide a large surface area.
Yes to audit logs may mean raw technical logs that require specialist interpretation, not case-level evidence usable by compliance. Yes to integration may mean an API exists, not that the buyer's messy content model is understood. Yes to role-based access may mean roles in the product, not alignment with the organisation's authority model. Yes to export may mean data leaves as flat files without lineage. Yes to human oversight may mean an approve button. Enterprise AI is where many yes answers should be followed by show me under ugly conditions.
The checklist should grow around operating questions. What evidence must survive. Which data sources are authoritative. Which fields are too stale. Which use cases require deterministic records. Which actions need human approval. Which errors require notification. Which changes require re-evaluation. Which supplier dependencies are acceptable. Which exit rights are non-negotiable. Which teams must change behaviour. Which controls will be tested before go-live. A product checklist without an operating model is a shopping list for a kitchen nobody has measured.
Van valami különös kényelem a homályos követelményekben. Szélesek maradnak a pályázati kiírások, kevesebb a konfliktus, és mindenki azt képzelheti, hogy az ő szempontja is benne van. Sajnos a homályos követelmények nem tűnnek el a szerződés odaítélése után. Változáskezelési kérelmekként, késedelmekként, vitákként és egyre óvatosabb igéket használó irányítóbizottsági diákként születnek újjá. A pontosság lassúnak tűnik a szerződés előtt. Utána gyakran sokkal gyorsabb.
A kockázatáthárítás gyakran csak színház
A beszerzési folyamatok megpróbálják áthárítani a kockázatot. Szerződések, garanciák, kártérítési kötelezettségek, szolgáltatási szintek, tanúsítványok, biztosítás, adatkezelési feltételek. Ezek fontosak. Az érett beszerzésnek szüksége van rájuk. De a vállalati mesterséges intelligencia olyan kockázatokat hoz létre, amelyeket nem lehet teljesen áthárítani, mert a vevő környezetében élnek. A szállító eszközt, védelmet, támogatást és bizonyítékot tud adni. A vevő birtokolja az adatokat, a munkafolyamatot, a jogosultságokat, a felhasználói viselkedést, az eszkalációs utat és a döntést, amely átveszi a kimenetet. A szerződés nem tudja kiszervezni az intézményen belüli döntéshozatalt.
Itt válik néhány szervezet túl magabiztossá. A szállító átment a biztonsági felülvizsgálaton. A modell rendelkezik dokumentációval. A feltételek lefedik az adatvédelmet. A szolgáltatás rendelkezik üzemidő-vállalásokkal. Jó. De most ki dönti el, hogy egy alacsony megbízhatóságú válasz felhasználható-e nagy hatású esetben. Ki veszi észre, amikor a felhasználók abbahagyják az ellenőrzést. Ki kezeli az ügyfél kifogását. Ki ellenőrzi, hogy a tanítási példák megfelelnek-e a valós munkának. Ki állítja le a rendszert, amikor a szabályzat változik. Ha a válasz a szállító, a vevő lehet, hogy egy irányítási fantáziát vásárolt. Ha a válasz senki, a vevő egy jövőbeli incidenset vásárolt.
A kockázatáthárítás perverz ösztönzőket is teremt, amikor a vevők olyan dolgokért kérnek felelősséget a szállítóktól, amelyeket csak a vevő tud kontrollálni. A szállító kizárásokkal, óvatos konfigurációval, felfújt árakkal vagy homályos kötelezettségvállalásokkal válaszol. A vevő több záradékkal válaszol. Végül a szerződés egy kibélelt szoba lesz egy olyan munkafolyamat körül, amelyet senki sem tervezett meg. Papíron nagyon biztonságos. Kedden kevésbé hasznos.
Jobb megközelítés a kockázatelosztás. Nevezze meg a kockázatot. Rendelje hozzá azt a részt, amelyet a szállító tud kontrollálni. Rendelje hozzá azt a részt, amelyet a vevőnek kell működtetnie. Határozzon meg közös teszteket. Határozzon meg bizonyítékokat. Határozzon meg eszkalációt. Határozzon meg felfüggesztési jogokat. Határozzon meg változáskezelést. Ez kevésbé kielégítő, mint az, hogy úgy teszünk, mintha a kockázatot egy zip fájlban exportáltuk volna. De közelebb áll a valósághoz, ami a sikeres működés makacs jellemzője.
A pilot nem a beszerzési egység
Számos vállalati MI-beszerzés pilóta projekttel kezdődik. Ez érthető is. A pilóta projektek csökkentik a bizonytalanságot, és segítik a csapatok tanulását. A beszerzési csapda akkor jelenik meg, amikor a pilóta projekt válik a bizonyítás egységévé. Egy pilóta projektet gyakran védik a szakértő felhasználók, a gondosan válogatott adatok, a közvetlen szállítói figyelem, a laza integráció, az ideiglenes irányítási keretek és egy olyan közönség, amely hajlandó elnézni a kezdeti hibákat. A éles üzem más. Az éles üzemben van volumen, fluktuáció, audit, szélsőséges esetek, biztonsági korlátok, támogatási jegyek, adatmegőrzési szabályok, megváltozott prioritások és olyan felhasználók, akik nem vettek részt a lelkesítő kickoff eseményen.
A pilóta projektnek ezért az éles üzemi feltételezéseket kell tesztelnie, nem csupán a termék képességeit. Végig tudják-e vinni a hétköznapi felhasználók a munkafolyamatot. Megmarad-e a válaszok minősége valós adatokon. Mennyi felülvizsgálati időre van szükség. Mely rekordok kellenek az audithoz. Mely kivételek gyakoriak. Mely integrációs pontok törékenyek. Mi történik, ha egy adatforrás elavult. Tud-e a rendszer megfelelően visszautasítani. Képes-e a szervezet támogatni a rendszert anélkül, hogy a szállító mérnökei egész nap a chatben lennének. Ha ezekre a kérdésekre csak a méretarányos jóváhagyás után keresünk választ, a pilóta projekt csak színház jobb harapnivalókkal.
A beszerzés egységének egy ellenőrzött üzemeltetési szeletnek kell lennie. Egy szelet magában foglalja a használati esetet, az adatforrásokat, a jogosultságokat, a felhasználókat, a felülvizsgálati eljárást, a bizonyítékokat, a támogatási modellt, a változáskezelési folyamatot és a kilépési útvonalat. Ez szűkebb, mint egy stratégia, és tágabb, mint egy demó. Értelmesen értékelhető, mert tartalmazza azokat a dolgokat, amelyek értéket teremtenek, és azokat, amelyek költséget jelentenek. Ha a szelet működik, a méretarányosítás egy ismert minta ismétlését és adaptálását jelenti. Ha csak az eszköz működik, a méretarányosítás a szervezet felfedezését jelenti, egy függőségről a másikra haladva.
Ezért kell a pilóta projekt mérőszámainak tartalmazniuk a hétköznapi számokat is. Felülvizsgálati percek esetenként. A javított kimenetek százalékos aránya. A hiányzó bizonyíték miatt visszautasított esetek. Az adatforrás-frissességi hibák. Az eszkalációk száma. A felhasználói egyet nem értés okai. Az export teljessége. A szállítói támogatást igénylő incidensek. A megkérdőjelezett kimenet megmagyarázásához szükséges idő. Ezek a mérőszámok kevésbé látványosak, mint a termelékenységnövekedés. De ezek a számok döntik el, hogy a termelékenység fennmarad-e.
Az adathozzáférés nem kapcsolódási lista
A beszerzési dokumentumok gyakran kérdezik, hogy mely rendszerekhez csatlakozik a termék. Ez szükséges, de nem elégséges. Egy kapcsolódás egy ajtó. Nem árulja el, hogy a szobában vannak-e címkézett polcok, naprakész rekordok, jogszerű hozzáférés, konzisztens azonosítók, használható dokumentumok, megőrzött kontextus vagy padló. A vállalati adatok ritkán várnak türelmesen. Vannak örökölt mezőik, duplikált rekordjaik, titkokat tartalmazó PDF-jeik, SharePoint-ásatások, részlegek szerinti taxonómiák, gazdátlan adataik és olyan fájljaik, amelyeket azért neveztek el finalnak, mert az optimizmus megújuló erőforrás.
A vevőnek meg kell értenie, hogy az MI-rendszernek mire van szüksége az adatokból, nem csupán azt, hogy hol élnek az adatok. Teljes dokumentumokra vagy kinyert mezőkre van szüksége. Aktuális állapotra vagy történeti pillanatképekre van szüksége. Jogosultság-tudatos lekérdezésre van szüksége. Származási adatokra van szüksége. Strukturált címkékre van szüksége. Törlési propagációra van szüksége. Adatminőségi küszöbértékekre van szüksége. Emberi korrekcióra van szüksége. Minden egyes igény megváltoztatja az integrációs költséget és az irányítási kereteket. Egy kapcsolódás, amely figyelmen kívül hagyja ezeket az igényeket, csak egy tömlő. A tömlők hasznosak. De pontosan így öntik el a pincéket is.
Az adathozzáférésnek jogi és társadalmi dimenziói is vannak. Egy rendszer technikailag képes lehet olvasni egy forrást, de mégsem joga van felhasználni azt modellképzésre, elemzésre, munkavállalói megfigyelésre vagy automatizált döntéstámogatásra. A felhasználók megbízhatnak egy adattárban egy célra, és tiltakozhatnak, amikor annak tartalma egy másik cél üzemanyagává válik. Az a beszerzés, amelyik azt kérdezi, hogy tudunk-e csatlakozni, mielőtt azt kérdezné, hogy használhatjuk-e, későbbi meglepetéseket okoz. A meglepetés rossz beleegyezési mechanizmus.
Az értelmes MI-beszerzés ezért magában foglalja az adatok átvilágítását az odaítélés előtt, vagy legalábbis a bevezetés előtt. Mintavételezze a rendezetlen korpuszt. Tesztelje a kinyerést. Vizsgálja meg a jogosultságokat. Mérje fel a duplikációt. Azonosítsa az elavult mezőket. Nevezze meg az adatgazdákat. Ellenőrizze a megőrzési időt és a hozzájárulásokat. Értse meg, mely adatok nem mozdíthatók. Árazza be a tisztítást. Ha ez a munka úgy tűnik, mintha késleltetné a vásárlást, emlékezzen arra, hogy a vásárlás úgyis ugyanerre a rendezetlenségre bukkant volna később, csak éppen szerződéssel a nyakában.
A változáskezelés maga a termék
A vállalati MI nem áll meg. A modellek frissülnek. A promptok változnak. A keresőindexek újraépülnek. A szabályzatok módosulnak. Az adatforrások mozognak. A felhasználók felfedezik a szélső eseteket. A biztonsági szabályok szigorodnak. Új szabályozások érkeznek. A rendszer, amely átment a beszerzési eljáráson, nem ugyanaz a rendszer, amelyet a szervezet egy évvel később üzemeltetni fog. A változáskezelés ezért nem adminisztratív teher a termék körül. Hanem a termék része.
A beszerzésnek meg kell kérdeznie, hogyan javasolják, tesztelik, hagyják jóvá, kommunikálják, vonják vissza és dokumentálják a viselkedésbeli változásokat. Késleltetheti-e a vevő a modellfrissítést. Verziózhatók-e a promptváltozások. Összehasonlíthatók-e a keresési változások. Rögzíthetők-e a szabályzatcsomagok. Tud-e a szállító olyan kiadási jegyzeteket adni, amelyek működési kockázathoz kapcsolódnak, nem pedig marketingköltészethez. Tesztelhetők-e a nagy hatású esetek regressziós teszttel az élesítés előtt. Látja-e a szervezet, hogy mely eseteket érintett egy változás. E jogosultságok nélkül a vevő nem rendszert vásárolt. Hanem mozgásra fizetett elő.
A belső változás ugyanolyan fontos, mint a szállítói változás. Egy osztály módosít egy űrlapot. Egy szabályzatcsapat felülvizsgálja az útmutatót. Egy adatcsapat megváltoztat egy mezőnevet. Egy vezető átalakítja a létszámot. Egy jogi értelmezés eltolódik. Az MI-rendszerek ezeken a határokon átívelnek, így a kisebb belső változások is elmozdíthatják a kimeneteket. A beszerzés ezt egyedül nem tudja megoldani, de megkövetelheti azt a működési modellt, amely észleli és kezeli a mozgást. Ha minden változást valaki más helyi fejlesztéseként kezelnek, az MI-munkafolyamat olyan folyosóvá válik, ahol az ajtók folyamatosan emberekbe nyílnak.
A jó változáskezelés utat ad az innovációnak. Nem blokkolja a frissítéseket. Átláthatóvá teszi azokat. A csapatok gyorsabban fejleszthetik a modelleket és a munkafolyamatokat, ha tudják, hogyan kell tesztelni, jóváhagyni és helyreállítani. A változáskezelés ellentéte nem az agilitás. Hanem a felügyelet nélküli sodródás kiadási naptárral.
A felhasználók nem bevezetési célpontok
Az ellátáslánc-menedzsment gyakran úgy tekint a felhasználókra, mint akiket meg kell nyerni az ügynek. Képezze őket, kommunikálja az előnyöket, mérje a használatot, ünnepelje a bajnokokat, szüntesse meg a súrlódásokat. Ennek egy része hasznos. De a felhasználók egyben kontrollpontok, szakterületi szakértők és korai figyelmeztető rendszerek is. Ha nem bíznak a rendszerben, lehet, hogy ellenállnak a változásnak. Az is lehet, hogy érzékelik: a munkafolyamatból hiányzik a bizonyíték, a felhatalmazás, az idő vagy a javítás lehetősége. Az a beszerzési folyamat, amely a felhasználókat elsősorban meggyőzendő célpontnak látja, figyelmen kívül hagyja az általuk hordozott információt.
Vásárlás előtt beszéljen azokkal, akiknek a munkájába beépül majd az AI kimenete. Kérdezze meg, milyen bizonyítékra van szükségük a cselekvéshez. Mely esetek veszélyesek. Mely adatmezők megbízhatatlanok. Mely kivételek emésztik fel az időt. Mely döntéseket nem bíznák másra. Mely hibák lennének kínosak, károsak vagy jogellenesek. A jelenlegi folyamat mely részei informálisak, mert a formális rendszer soha nem tanulta meg a valóságot. Ezek a válaszok nem változásellenállás. Ezek követelmények, ujjlenyomattal.
Vásárlás után a felhasználói visszajelzésnek táplálnia kell a változáskontrollt és a bizonyítékokat. A javításokat, felülbírálatokat, eszkalációkat és elutasítási okokat mérni és megvitatni kell. Ha a felhasználók figyelmen kívül hagyják a rendszert, derítse ki, hogy az rossz, lassú, bizalmatlan, rossz helyen van, nincs összhangban az ösztönzőkkel, vagy egyszerűen kevésbé hasznos, mint a beszerzési történet sugallja. A használat önmagában gyenge értékmérő. Az emberek kényszer hatására rossz rendszereket is használnak, és jó rendszereket is elkerülnek, ha a környező folyamat bünteti őket a józan ítélőképességükért.
A felhasználók világosságot is érdemelnek. Ha az AI kimenete tanácsadó jellegű, mondja ki. Ha kötelező, mondja meg, ki a döntés gazdája. Ha a felülbírálat üdvözlendő, ne büntesse eltérésként. Ha a bizonyíték kötelező, adjon időt az áttekintésére. A vállalati AI megbukik, amikor a felhasználók emberi pufferré válnak egy magabiztos eszköz és egy homályos intézmény között. Ez nem bevezetés. Ez szigetelés.
A kilépési tesztnek a belépés előtt kell megtörténnie
A kilépés a legelhanyagoltabb beszerzési követelmény, mert senki sem akar a végről beszélni az elején. Pedig a kilépés az, ahol a vevői hatalom valóságossá válik. El tudja-e hagyni a szervezet a rendszert az adataival, metaadataival, promptjaival, konfigurációival, értékelési rekordjaival, auditnaplóival, felhasználói visszajelzéseivel, modellkimeneteivel, javítási nyomaival és törlési igazolásaival együtt. Ki tudja-e kapcsolni a rendszert anélkül, hogy elveszítené a képességét a múltbeli döntések magyarázatára. Át tud-e települni egy másik eszközre anélkül, hogy a munkatársaknak képernyőnként kellene lefotózniuk az intézmény emlékezetét.
A kilépési tesztnek gyakorlatinak kell lennie. A méretnövelés előtt exportáljon egy reprezentatív szeletet. Állítsa vissza máshol. Ellenőrizze az azonosítókat, időbélyegeket, származást, jogosultságokat, mellékleteket, javításokat és döntési rekordokat. Győződjön meg róla, hogy a bizonyítékok olvashatók maradnak. Ellenőrizze, hogy a szerződéses nyelv megfelel-e a technikai valóságnak. Ha az export lassú, veszteséges vagy egyedi szállítói munkától függ, árazza be ezt a függőséget. A remény nem kilépési stratégia. Ez egy hangulat, rossz verziókezeléssel.
A kilépési jogok a jelenlegi kapcsolatot is javítják. Amikor az adatok és rekordok hordozhatók, a szállítók a szolgáltatásban és az értékben versenyeznek, nem a fogva tartásban. A vevők kevésbé félnek az őszinte értékeléstől. A belső csapatok a csere szempontjából tervezhetnek. Az architektúra tisztább lesz, mert a jelentésnek explicitnek kell lennie. A kilépés nem pesszimizmus. Ez higiénia.
Van egy beszerzési közmondás, amely még megírásra vár: soha ne vásároljon olyan AI-rendszert, amelyet nem hagyhat el anélkül, hogy elfelejtené, miért használta. Ez túl hosszú egy bögréhez, ami valószínűleg így is van jól. A bögréknek így is van elég számlájuk az irodai kultúrában.
Kilépés a csapdából
A beszerzési csapdából való kilépéshez nem kell hősies újrafeltalálás. Elég, ha a vásárlás középpontját a termékről a munkarendszerre helyezzük. Határozzuk meg szorosan a felhasználási esetet. Teszteljük korán a valós adatokat. Árazzuk be a felülvizsgálati munkát. Követeljük meg az intézményi kérdésekre választ adó bizonyítékokat. Kezeljük a változáskontrollt elsődleges követelményként. Vásároljuk meg a kilépési jogokat. Vonjuk be a felhasználókat mint szakterületi tanúkat. Rendeljünk felelőst az eredményekhez. Mérjük a javítások és kivételek terhét. Kényszerítsük ki, hogy a szállítók a rendszert mostoha körülmények között mutassák be, mert a vállalati szoftver életének nagy részét éppen mostoha körülmények között tölti.
Ez eleinte kevésbé rendezetté teszi a beszerzést. Felszínre hozza azokat a konfliktusokat, amelyeket korábban az ellenőrzőlisták elrejtettek. Az adattulajdonosok kötelezettségeket fedeznek fel. A jogi osztálynak működési részletekre lesz szüksége. A biztonságiak bizonyítékot kérnek. Az üzemeltetés létszámot kér. A pénzügy olyan költségeket lát meg, amelyek korábban a bokrokban várakoztak. Ez így jó. A rejtett költség is költség, csak önelégült.
A cél nem az, hogy a vásárlás örökre lassabb legyen. Hanem az, hogy a vásárlás elég őszinte legyen ahhoz, hogy a megvalósítás elindulhasson. Egy világos működési szerződés csökkenti a későbbi vitákat. Egy kipróbált adatút csökkenti az integrációs meglepetéseket. Egy valós felülvizsgálati modell csökkenti az átvételi színházat. Egy működő kilépés csökkenti a félelmet. A beszerzésből az érték feltételeinek megteremtője válik, nem pedig egy rituálé, amely a legmeggyőzőbb ígéretet választja ki.
A nyitó történetben szereplő győztes bemutató nem volt rossz. Csak hiányos volt. Az eredményt mutatta, nem pedig az eredmény körüli intézményt. A vállalati MI-beszerzésnek meg kell tanulnia megvásárolni ezt az intézmény felé forduló réteget: az unalmas jogokat, nyilvántartásokat, szerepköröket, teszteket és kilépési lehetőségeket, amelyek a képességet szabályozott munkává alakítják. Különben a tender továbbra is olyan rendszereket választ, amelyek az odaítéléskor késznek látszanak, és csak azután kezdenek valódivá válni, hogy mindenki már szerződésileg elkötelezte magát. Ez drága módja annak, hogy megtanuljuk azt, amit egy jobb kérdés korábban is megtalálhatott volna.