Velký poštovní skandál 1: Prototyp, který šel do výroby

Papírový výkaz do Chesterfieldu

Na začátku devadesátých let si Britové chodí pro sociální dávky osobně na poštu. Z papírové knížky vytrhnou poukázku a přepážkový pracovník jim vyplatí hotovost.

Tento model provází masivní kriminalita: jen v letech 1991 a 1992 se ztratí knížky za 230 milionů liber, z čehož 85 milionů organizovaný zločin i drobní podvodníci úspěšně promění v peníze. Dalších 16 milionů liber zmizí přes padělané šekové poukázky.

Ministerstvo sociálního zabezpečení chce knížky nahradit kartou s magnetickým proužkem. Fungovala by jednoduše: umožnila by výběr jen jednou týdně a při nahlášení ztráty by ji systém okamžitě zablokoval. Technologie je prověřená a dostupná. Problém je jinde: Pošta nemá infrastrukturu, která by transakce dokázala odbavovat.

Většina poboček funguje v principech sahajících do viktoriánské éry. Na konci každého obchodního týdne vyplní poštmistr rozsáhlý papírový výkaz, podepíše jej, složí do obálky a odešle do finanční centrály v Chesterfieldu. Jakmile hotovost dorazí fyzicky na pobočku, centrála nad ní ztrácí kontrolu. Ví pouze to, co poštmistr sám napíše na papír.

V roce 1994 proto Pošta a Benefits Agency (státní úřad vyplácející dávky) vypisují společnou zakázku s rozpočtem jedné miliardy liber. Vítězný dodavatel má zavést magnetické karty a kompletně zautomatizovat přepážky i zázemí celé sítě přibližně 20 000 poboček.

Financování má proběhnout formou PFI (Private Finance Initiative), tedy ryze ze soukromých zdrojů. Dodavatel systém vyvine, nasadí a zprovozní na vlastní náklady. Investice se mu začne vracet až následně – formou pevně stanoveného poplatku za každé jednotlivé protažení dávkové karty na přepážce po dobu osmi let.

Smlouva však obsahuje časovanou bombu: osmileté období nezačíná dnem spuštění ostrého provozu, ale dnem podpisu kontraktu. Každý měsíc zpoždění vývoje ukrajuje z doby, kdy dodavatel může své stamilionové výdaje inkasovat zpět. Tlak na co nejrychlejší předání je enormní.

Poštmistr zapisuje ruční výkazy – ilustrační obrázek

Poslední v osmi kritériích z jedenácti

V květnu 1996 vítězí v soutěži konsorcium Pathway. Prakticky celé spadá pod britskou firmu ICL – někdejší vlajkovou loď britského IT, v níž od roku 1990 drží osmdesátiprocentní podíl japonská Fujitsu.

Výběr provází pozoruhodný fakt: nabídka Pathway skončila na posledním místě v osmi z jedenácti odborných hodnoticích kritérií. Pro státní kasu byla nicméně na papíře nejlevnější, protože konsorcium požadovalo nejnižší provizi za provedenou transakci.

Před poštovním úřadem ve Stroudu pózují fotografům ministr Peter Lilley, ředitel Pošty Stuart Sweetman a Colin Baker, generální tajemník Národního svazu poštmistrů (NFSP). Baker mluví o „novém úsvitu a novém horizontu“. Svaz prodává systém svým členům na konferencích jako projekt století.

Vedení Pošty i oborový svaz vsadily na Horizon všechno.

Původní technická vize působí přímočaře: pod každou přepážkou poběží počítač s operačním systémem Windows NT, na stole bude stát dotyková obrazovka, čtečka čárových kódů a malá tiskárna účtenek. Každá operace se zapíše do lokální databáze a v noci se dávkově odešle přes linku ISDN na centrální mainframe Pošty.

Architektura pro 40 000 terminálů

V praxi zadavatelé i dodavatel podcenili měřítko. Zadání nepředstavovalo jednu homogenní bankovní instituci s disciplinovanou sítí, ale 20 000 geograficky roztroušených vesnických a městských pošt. Každá pobočka měla jiný personál, často nabízela specifické regionální produkty a odbavovala finanční transakce výrazně pestřejší než komerční banky.

Projekt vyžadoval instalaci 40 000 terminálů, zaškolení 67 000 lidí s diametrálně odlišnou počítačovou gramotností a spolehlivé zpracování 56 miliard liber sociálních dávek ročně pro 28 milionů občanů. Systém takového rozsahu na míru v Británii do té doby nikdo nestavěl – ani státní správa, ani Fujitsu.

Fujitsu sice zvítězilo cenovým podbídnutím, realita vývoje v Hounslow však začala polykat deset milionů liber měsíčně.

Smlouva dodavateli ukládala povinnost předvést spolehlivý, trvalý a bezchybný provoz. Termín předvedení se už jednou posouval. V polovině roku 1997 však Fujitsu nedokáže spolehlivý chod demonstrovat ani v uzavřeném, laboratorním prostředí.

Prostě to nefunguje.

Představení systému veřejnosti – ilustrační obrázek

323 změn v běžícím vlaku

Před parlamentním vyšetřováním se Fujitsu později hájilo tím, že kooperace se zadavateli byla neúnosná. Dva různé státní subjekty s odlišnými zájmy neustále měnily cíl: k původním 366 smluvním požadavkům vznesly za tři roky 323 formálních změnových požadavků. K tomu přibyly stovky neformálních provozních „upřesnění“, jež si vynucovaly zásadní přepracování systémové architektury.

V prosinci 1997 došla trpělivost i úřadům. Pošta spolu s Benefits Agency zasílají do Fujitsu formální oznámení o porušení smlouvy. Fujitsu reaguje agresivně: oznámení odmítá převzít a přechází do protiútoku. Pokud nedostane garantován vyšší poplatek za každou transakci, okamžitě na Horizonu zastaví veškeré práce.

Byl to pokus o nátlak postavený na předpokladu, že stát do projektu investoval příliš mnoho, než aby mohl odejít. Jenže státní aparát odpověděl nečekaným tahem: Benefits Agency oznámila, že o čipové karty na dávky vlastně přestává mít zájem. Dávky začne posílat občanům přímo na běžné bankovní účty.

Tímto výrokem se celý obchodní model sesypal.

Fujitsu totiž za samotný vývoj ani nasazení nedostávalo žádné průběžné milníky. Celý příjem měl plynout z provizí za protažení karty na přepážce. Karta byla hlavním důvodem spuštění projektu a jediným zdrojem návratnosti nákladů pro dodavatele. Teď přestala existovat. Příjmy dodavatele spadly z minuty na minutu na nulu a Pošta čelila odchodu třetiny svých tradičních zákazníků do bankovního sektoru.

Příliš drahý na to, aby se dal zabít

V lednu 1998 se v Londýně reálně zvažuje úplné zrušení Horizonu. Projekt nemá funkční kód, chybí mu stabilní zadání a přišel o ekonomický model, na němž byl vystavěn.

Přesto přežije. Na ministerstvech převáží doktrína, že projekt je „too big to fail“ – příliš politicky a finančně nákladný, než aby jej bylo možné pohřbít. Zrušit po dvou letech a stovkách proinvestovaných milionů modernizaci poštovní sítě by znamenalo politickou katastrofu.

Následuje rok a půl trvající vyjednávání. V dubnu 1998 Pošta formálně přebírá řízení projektu na sebe. Benefits Agency z kontraktu definitivně vystupuje a z Horizonu se stává čistě poštovní systém. Fujitsu, které mezitím odepsalo ztrátu 180 milionů liber, vyjednává nový kontrakt za pevně stanovené platby.

Z původního modelu PFI, kde měl dodavatel nést komerční i provozní riziko, nezbylo nic. Národní kontrolní úřad (NAO) později vyčíslí škody způsobené tímto krachem zadání na půl miliardy liber z veřejných peněz.

Právě v dubnu 1998 nastupuje do budovy Fujitsu v Hounslow nový softwarový inženýr.

Hounslow, duben 1998: tašky na kartonový model

Clint parkuje před kancelářským komplexem ze skla a betonu na okraji Hanworth Parku v Hounslow. Na recepci si vyzvedává vstupní kartu.

Jméno Clint je pseudonym. Britský novinář Nick Wallis s ním hovořil o dvě dekády později v hotelu Grand v Yorku, kde vývojář předložil podklady dokládající jeho identitu i roli v projektu. Wallis si jeho kvalifikaci i odbornou podstatu výpovědi následně nezávisle ověřil u dalších softwarových expertů. Clint strávil většinu devadesátých let v Bruselu návrhem a stavbou finančních systémů pro Evropský parlament a Evropskou komisi. Do Fujitsu přišel na pozvání bývalého kolegy jako člověk, který má pomoci zkrotit projekt v těžkých potížích.

Realita uvnitř budovy předčila očekávání.

„Když jsem přišel, všichni v budově věděli, že je to hnůj,“ popsal Clint Wallisovi. „Úplně všichni. Testovací laboratoří to prošlo bůhvíkolikrát a testeři hlásili chyby po tisících, včetně kategorie A.“

Systémové vady se dělily standardně podle kritičnosti: céčko představuje drobný problém, béčko závažnou chybu, zatímco áčko značí kritické selhání bránící použití. „V systému byly tisíce a tisíce chyb. Pro samé skákající antilopy nebylo nic vidět a spousta z nich byla áčka a béčka.“

Žádné konkrétní zadání Clint nedostal. Jeho nadřízený disponoval v IT právě takovým rozhledem, aby chápal blížící se katastrofu. Když zhodnotil Clintův profesní životopis, shrnul jeho misi jedinou větou: „Běž tam a zjisti, co ti vývojáři dělají.“

Vývojový tým pokladního softwaru čítal osm lidí. Pár z nich podle Clinta psát kód umělo a chtělo pracovat poctivě. Zbytek popsal bez obalu jako „školku“: „Nevěděli, jak na to, a nezajímalo je to. Šlo jim o to nacpat si kapsy a jít večer domů.“ Manažeři neuměli odlišit kvalitního programátora od nekvalitního, protože sami z vývoje nevzešli. V čele vývoje pokladní aplikace stál bývalý zaměstnanec Pošty, který předtím nikdy vývojářský tým neřídil. „Měl tam sedět jako poradce pro byznys a vývoj měl vést pořádný vývojový manažer.“

Stav inženýrské disciplíny byl nulový: „Nepsaly se specifikace, neexistovala žádná kontrola vývoje, návrh nebyl nikde sepsaný, nebylo nic.“

Po několika týdnech interního auditu měl Clint diagnózu hotovou. Uživatelské rozhraní, psané ve směsi Visual Basicu, C a C++, vykazovalo zásadní nedostatky. Skutečný strukturální problém ale ležel hlouběji – v datové vrstvě.

Jádrem Horizonu byl komerční software Riposte – distribuované úložiště zpráv. Jeho úkolem bylo bezpečně přenášet a replikovat finanční data z jednotlivých poboček na centrální servery. Do takového systému je nutné zapisovat výhradně podle striktně definovaného datového slovníku a přes validující aplikační vrstvu, která každou zprávu před uložením prověří.

V Hounslow nic takového neexistovalo.

„Jinak můžete do úložiště zpráv psát ve volném stylu, a přesně to dělali,“ vysvětluje Clint. „Nebylo tam žádné aplikační rozhraní, žádný dohodnutý katalog dat, nic.“

Vývojáři měnili formáty zpráv za běhu podle toho, co zrovna potřebovali implementovat. Pokud zpráva dostala nové datové pole a starší záznamy nikdo nezmigroval, pokladní terminál při zpětném čtení narazil na neznámou strukturu. Následky byly nepredikovatelné: pád aplikace, odeslání poškozených dat do účetního jádra nebo tiché zkreslení částek.

„Když aplikace nekontroluje, jestli je obsah zpráv správně – a ona to nekontrolovala – je úložiště úplně zanesené smetím,“ dodává Clint.

Vývojáři pracují na nefunkčním systému – ilustrační obrázek

Když pátral po původu tohoto chaosu, narazil na podstatu celého problému: kód pokladního softwaru napsala malá skupina jako rychlý prototyp pro obchodní prezentace v tendru. Měl sloužit pouze jako vizuální ukázka toho, jak by obrazovka mohla na bázi Riposte fungovat. A tento prototyp vyhrál zakázku.

„Když zakázku získáte, máte prototyp zahodit a začít od začátku. Prototyp jen dokazuje, že to jde. Je to architektův kartonový model. Na kartonový dům nezačnete pokládat střešní tašky. A přesně to dělali.“

Clint prošel celou architekturu a šel za vedením s jednoznačným stanoviskem: jádro aplikace je nutné vyhodit a postavit znovu. Klíčovým bodem byl modul cash account – komponenta, která každý večer agreguje všechny transakce na přepážkách dané pošty a spočítá, kolik hotovosti musí fyzicky ležet v trezoru a v zásuvkách. Výsledná suma putuje v noci do centrály. Na integritě tohoto jediného modulu stála veškerá důvěryhodnost finančních výkazů.

Vedení Fujitsu přepsání rezolutně odmítlo. Znamenalo by to další měsíce zpoždění a masivní vícenáklady. Clint dostal za úkol modul pouze látat za běhu. Sestavil tým schopnějších vývojářů a pokusil se stabilizovat nejhorší excesy. Krátce nato ho vnitřní firemní politika odsunula na jiný úsek projektu.

Na otázku, jak by Horizon s odstupem definoval, odpověděl Clint jednoznačně: „Byl to prototyp, který se několik let nafukoval a slepoval a pak ho s křikem a kopáním vystrčili ze dveří. Nikdy neměl spatřit světlo světa. Nikdy.“

Navzdory riziku

Na jaře 1999 je projekt po revizi smluv plně v rukou Pošty. Její interní IT specialisté a provozní manažeři však odmítají pustit systém na pobočky bez vlastního hloubkového auditu.

Dne 4. března 1999 zasedá programová rada Pošty a sestavuje registr rizik. Metodika je standardní: pravděpodobnost krát dopad, maximální skóre 25 bodů, přičemž cokoliv nad 15 bodů spadá do kritického červeného pásma.

Prvních pět položek registru je červených. Všech pět má maximální skóre: 25 bodů.

Interní zpráva uvádí, že kvůli „nedostatečné viditelnosti návrhu“ a smlouvě, která zadavateli neposkytuje nástroje k jejímu vymáhání, „jsme nebyli schopni získat vysokou míru jistoty o přiměřenosti nebo vhodnosti služby“. V kolonce Opatření se nachází lakonická poznámka: „Všechny ostatní přístupy selhaly. Pathway byla naposledy požádána o spolupráci a o zpřístupnění odpovídající dokumentace.“

Fujitsu reaguje defenzivně. V požadavcích vidí další nebezpečí zásahů klienta, které by přinesly nové změny a další finanční ztráty. Navíc software stále vykazuje kritické vady. Dodavatel se proto odvolává na klauzule o ochraně obchodního tajemství v původním kontraktu PFI a odmítá auditory do svých systémů pustit.

Jinými slovy: zákazník měl převzít a garantovat systém, do jehož vnitřní architektury nesměl vůbec nahlédnout.

Laboratoř ve West Boldonu

Přestože se musel zkušební pilotní provoz v terénu kvůli nestabilitě softwaru už v září 1997 zrušit a přestože interní testování odhalilo zásadní nedostatky, v červenci 1999 britská vláda oznamuje, že ostrá plošná automatizace pošt začne v říjnu. Vznikají centrální týmy, nakupuje se hardware a na vybraných pobočkách se rozbíhá pilotní zkouška naostro.

Jednou z nich je malá vesnická pošta ve West Boldonu. U jediné přepážky zde stojí šedesátiletá poštmistrová Margaret Davison. Za zády se jí tísní technici, elektrikáři, inspektoři z centrály a IT specialisté, zatímco se snaží odbavovat frontu vesničanů.

„V systému bylo tolik závad, se kterými jste se měla vyrovnat za pochodu, s frontou zákazníků před sebou,“ popsala později situaci. Telefonická podpora na helpdesku byla natolik přetížená a personálně nezkušená, že čekání na spojení běžně trvalo přes hodinu. „Od prvního dne byl ten systém vadný.“

Fronta na poště – ilustrační obrázek

V srpnu 1999 – pouhé dva měsíce před plánovaným plošným startem – dokončuje interní tým Pošty analýzu dopadů. Dokument identifikuje šest problémů nejvyšší závažnosti.

Jeden ze záznamů varuje: „Cash account odvozený v TIP se nerovná elektronickému cash accountu, který TIP přijal.“

TIP (Transaction Interrogation Platform) představoval páteřní centrální systém zpracovávající transakční toky z poboček. Přeloženo do srozumitelné řeči: modul denní uzávěrky, který chtěl Clint před rokem zbourat a postavit znovu, vykazoval interní chyby přímo v jádře. Částky odeslané z terminálu na pobočce nesouhlasily s hodnotami, které centrála přijala a uložila.

Autoři analýzy otevřeně konstatují, že Pošta „neviděla podrobný popis chyb, které chybějící data způsobují, ani popis toho, jak a kdy budou opraveny“. A přidávají varování: „Tyto mezery v datech se nakonec promítnou do rozvahových účtů.“ Fujitsu autorům zprávy oficiálně přiznává, že „dosud nerozumí kořenové příčině problému“.

Seznam dalších kritických incidentů zahrnuje samovolné ztráty dat v centrální databázi způsobující účetní schodky, transakce mizející ještě před zaúčtováním do denního výkazu, zamrzající klientské terminály i nefungující periferie.

V září ne, v říjnu ano

V září 1999 představenstvo Pošty odmítá systém Horizon převzít. Do oficiálního zápisu ze zasedání nechává zanést „vážné pochybnosti“ o stabilitě a celkové spolehlivosti softwaru.

O pouhý měsíc později uvádí zápis z dalšího zasedání: „Po nápravných pracích na dvou problémech, které dříve bránili akceptaci, byl systém přijat a implementace pokračuje tempem 200 poboček týdně.“

Co se stalo se zbývajícími čtyřmi kritickými incidenty a se záhadnou chybou v cash accountu, jejíž příčině sám dodavatel nerozuměl, z historických pramenů nevyplývá. Prezentace nebo audity, které představenstvo během třiceti dnů přesvědčily k obratu o 180 stupňů, nebyly nikdy publikovány.

Představuje akceptace v organizaci ověřitelný technický důkaz, nebo jen politický ústupek unaveného vedení?

Dvě stě poboček týdně

Logistika v terénu byla mezitím připravena. Sklady přetékaly nakonfigurovanými počítači, obrazovkami a tiskárnami, instalační týmy měly rozepsané harmonogramy výjezdů. Scénář byl všude stejný: technik přijel na pobočku, usedl s poštmistrem k terminálu, ručně s ním přepsal čísla z posledního papírového výkazu do dotykové obrazovky a vyrazil na další adresu.

Při celkovém počtu 20 000 poboček, 40 000 terminálů a 67 000 lidí čekajících na zaškolení znamenalo tempo dvou set poboček týdně nepřetržitou práci na dva roky.

Pro vedení Pošty to byl vytoužený okamžik. Až dosud měla centrála o financích na pobočkách pouze takové informace, jaké jí poštmistr jednou za týden poslal poštou na papíře. Jediným způsobem ověření byla namátková kontrola revizorů. Nyní měla poprvé v historii vidět každou jednotlivou transakci z každého pultu v zemi, a to každou noc. Wallis poznamenává, že se Poště konečně „rozsvítilo“.

Byl v tom však fatální paradox: rozsvítil jí systém, jehož účetní součet pokladny podle srpnové technické analýzy nedokázal souhlasit ani sám se sebou.

Byl říjen 1999. Instalační vozy vyrazili k prvním dvěma stům pošt. Za přepážkami seděli drobní podnikatelé, kteří za každý zjištěný schodek v pokladně ručili vlastním domem a celoživotními úsporami. O šesti kritických systémových vadách Horizonu v životě neslyšeli – a vedení Pošty se postaralo o to, aby se o nich nikdy nedozvěděli.

„Když jsme nastoupili do úřadu, větší chaos než projekt Horizon nejspíš neexistoval.“

Tony Blair, interpelace v Dolní sněmovně, 12. dubna 2000

Co si z toho odnést na pondělní poradu

• Akceptace musí být technický důkaz, nikoliv politický podpis. Převzetí systému do ostrého provozu nesmí stát na únavě managementu nebo blížícím se termínu. Předem nadefinujte měřitelné metriky kvality a seznam nepřekročitelných podmínek, za kterých je přípustné změnit zamítavé stanovisko na schvalující.
• Bezpečnost a auditovatelnost mají přednost před obchodním tajemstvím dodavatele. Přebírat uzavřenou architekturu, do jejíhož návrhu, dokumentace a otevřených vad nesmí interní specialisté nahlédnout, je manažerský hazard. Smlouva musí zadavateli garantovat přístup ke zdrojovým kódům v úschově (escrow), detailním výsledkům zátěžových testů i k otevřenému bug trackeru.
• Cena nabídky nesmí převážit nad technickou způsobilostí a riziky. Zvolit dodavatele, který skončí poslední ve většině odborných hodnoticích kritérií jen proto, že předloží nejnižší cenovou nabídku, zpravidla nevede k úspoře. V případě Horizonu stály následné sanace a změny kontraktu půl miliardy liber ještě před ostrým startem.
• Prototyp není automaticky základem produkčního řešení. Pokud má kód vytvořený jako vizuální ukázka či proof-of-concept přežít do produkčního systému, musí jít o vědomé a architektonicky podložené rozhodnutí. Prototyp ověřuje proveditelnost konceptu; snaha obalit jej produkční logikou a zatížit ostrými transakcemi bez refaktoringu vede k chronické nestabilitě.
• Smluvní model a motivace formují kvalitu softwaru. Pokud smlouva váže veškeré výnosy dodavatele na okamžik spuštění a čas ubíhá od podpisu papíru, vzniká enormní tlak na odevzdání nefunkčního polotovaru. Zvláštní pozornost věnujte poměru změn k původnímu zadání: v okamžiku, kdy objem změnových požadavků dosáhne počtu původních specifikací, projekt fakticky ztrácí jasný cíl.

Příště: Horizon přijíždí na pobočky. Téhož roku se v Británii změní pravidlo, podle kterého soudy posuzují důkazy z počítače, a poštmistři zjišťují, co vlastně podepsali ve smlouvě o 152 stranách. V listopadu 1999 nastupuje na poštu v londýnském Camberwell Green sedmnáctiletá Tracy Felstead.

Zdroje

• Kniha The Great Post Office Scandal – Nick Wallis (Bath Publishing, 2021).

Při tvorbě článku bylo využito generativní AI.