Birmingham, Oracle a 216 milionů liber: Proč město už roky nevidí na vlastní účetnictví?

Birmingham měl orgán, který měl zamítat odchylky od standardu, výstupní kritéria pro testování i finančního ředitele, který vlastnil business case. Všechno to existovalo a všechno hlásilo, že je to v pořádku. Dnes se dopad nasazení Oraclu počítá na 216,5 milionu liber a radnice nasazuje znovu – tentokrát bez úprav.

// obsah 16
  1. 01 Co se vlastně stalo?
  2. 02 Kde se stala chyba?
  3. 03 Ta úprava za 45 tisíc liber
  4. 04 Co konkrétně přestalo fungovat?
  5. 05 Ten business case se obrátil ještě před startem
  6. 06 To číslo: 216,5 milionu, a jak vzniklo
  7. 07 Proč o tom třináct měsíců nikdo nevěděl?
  8. 08 Jak dostane zelenou modul, který prošel z 29 %?
  9. 09 Co na to dodavatelé?
  10. 10 Kdo tedy měl říct dost?
  11. 11 Položil Oracle radnici?
  12. 12 Co to udělalo s městem
  13. 13 Co dělají teď?
  14. 14 Proč mě to zaujalo?
  15. 15 Jak to spadne, když všechno svítí zeleně?
  16. 16 Zdroje

Deset dní před ostrým spuštěním dostal řídící výbor mapu připravenosti, na které byla čtyři oranžová políčka a všechno ostatní bylo zelené (včetně modulu, který radnici vzápětí sebral přehled o vlastních penězích).

Po článku o Lidlu a SAPu mi vrtalo hlavou, jestli je Lidl výjimka, nebo se najde víc podobných případů. Našel jsem jich několik a postupně je chci rozebrat. První na řadu přišel Birmingham (největší městská samospráva v Evropě), který v dubnu 2022 nasadil Oracle Cloud Fusion a od té doby neumí spolehlivě říct, kolik má na účtech. Je to mnohem líp zdokumentovaný případ, protože jde o veřejnou správu a je zde všechno v zápisech z jednání.

Čekal jsem, že najdu stejný problém jako u Lidlu. A vlastně ano. Birmingham si standardní systém ohnul k sobě úplně stejně. Zajímavé je ale to, jak se mu to povedlo, protože od začátku tou cestou jít nechtěl.

Co se vlastně stalo?

Birmingham měl od roku 1999 SAP (finance, nákup, HR a mzdy), a to nejen pro sebe, ale i pro své organizace a městské školy. Za těch dvacet let ho radnice velmi upravila, aby fungoval tak, jak potřebovala. Přepisoval se přímo kód, aby systém uměl to, co ve standardu ne. V roce 2019 se rozhodla ho vyměnit za Oracle Cloud Fusion, tedy finance, mzdy, HR, nákup a logistiku na jedné platformě. Systémovým integrátorem byl Insight UK ve spolupráci s Evosys (jako subdodavatelem), projektové řízení a change management dodával Socitm Advisory, datovou migraci Egress. Od ledna 2021 přibylo ještě Ameo, které dodalo ředitele programu.

Datum Co se dělo
červenec 2019 Rozpočet 19 mil. £, očekávané úspory 26,9 mil. £
říjen 2019 Start programu, nasazení plánované na prosinec 2020 a únor 2021
březen 2021 Finální schválení: rozpočet 39 mil. £, úspory už jen 10,9 mil. £ – a přechod z dvoufázového nasazení na jeden velký třesk
11. dubna 2022 Ostré nasazení – bez zkušebního běhu a bez paralelního provozu
duben 2022 – květen 2023 Rozsah problémů se nedostane k zastupitelům (cca 13 měsíců)
5. září 2023 Radnice vydává Section 114, tedy zastavení nových výdajů
11. února 2025 Grant Thornton datuje Public Interest Report, radnice ho zveřejňuje 20. února
2026 Systém se nasazuje znovu, spuštění odloženo na léto 2026

Auditorova vlastní časová osa ukazuje navíc jednu věc: ředitel programu, finanční ředitel i generální ředitel se vystřídali každý aspoň jednou ještě předtím, než se vůbec mělo původně nasazovat.

Časová osa programu z auditní zprávy Grant Thornton

Zdroj: Grant Thornton UK LLP, Birmingham City Council – Report in the Public Interest, 11. 2. 2025, str. 20.

Kde se stala chyba?

Původní plán byl správný. Radnice si dala za cíl princip adopt, not adapt, tedy že přizpůsobí svoje procesy standardnímu Oraclu, ne naopak. Přesně to poučení, které si Lidl vzít odmítl. Birmingham si ho jasně dopředu definoval a napsal ho do zadání.

A pak ho porušil. Auditor to popisuje suše: program měl být postavený na přizpůsobení procesů standardním funkcím Oraclu, ale tohle se změnilo na přizpůsobování systému procesům radnice. Do systému se dopisovaly úpravy, aby seděl na to, jak se věci dělaly v customizovaném SAPu.

Vtip je v tom, že radnice na to měla orgán. Jmenoval se Business Design Authority a v popisu jeho práce doslova stálo, že má upřednostňovat standardní funkce a rozporovat navrhované odchylky. Byla to jediná brzda, kterou tam ten projekt měl.

Jenže ta „brzda“ ty odchylky schvalovala. Auditor píše, že Business Design Authority autorizovala značné množství dodatečných úprav standardního Oraclu, a označuje to za přímý rozpor s principem, na kterém byl celý projekt postavený. Její vlastní předseda to popsal takhle: bylo nemožné říct ne požadavkům, které se odchylovaly od standardu, obzvlášť když za nimi stál odpovědný vedoucí programu. Tím byl finanční ředitel radnice.

Takže ne, nikde není zápis, kde by někdo zrušil to definované „adopt not adapt“. Ale nestalo se to ani potají. Ty odchylky se schvalovaly jedna po druhé, na papíře, v orgánu zřízeném přesně proto, aby je zamítal.

Mimochodem ještě v dubnu 2021 finanční ředitel na kontrolním výboru potvrdil, že se principu drží přísně. Půlroční zpoždění návrhu tehdy vysvětlil právě tím, že si dávají záležet, aby se řešení neodchýlilo od standardního Oraclu.

Bacha na tohle, protože přesně takhle to vypadá i na malých projektech. Rozhodnutí odchýlit se od standardu skoro nikdy nepadne jako rozhodnutí. Padne jako padesát výjimek, každá zvlášť obhajitelná.

Ta úprava za 45 tisíc liber

Jednu z těch výjimek jde dohledat úplně přesně a stojí za to si ji projít, protože je to celý ten příběh v malém.

Standardní Oracle neuměl to, co radnice požadovala od zpracování hotovostních plateb. V únoru 2020 proto přišel na Business Design Authority návrh na vlastní řešení. Auditor z rozhodovacího dokumentu, který schválil finanční ředitel, cituje tři varianty: dělat to celé ručně, vzít standardní Oracle tak, jak je, nebo si nechat naprogramovat vlastní modul.

Vybrala se třetí. Rozhodovalo se podle jednoho čísla: Evosys odhadl vývoj na 45 tisíc liber, zatímco ruční varianta by znamenala devět lidí navíc. Auditor k tomu pak jen dodává, že neexistuje doklad o jakékoli podrobnější analýze těch variant ani o ověření těch nákladů, než rozhodnutí padlo.

Ten modul se jmenoval Bank Reconciliation System. Je to ta věc, kolem které se pak zbořilo všechno ostatní.

Přitom čtyřicet pět tisíc liber proti devíti lidem navíc je naprosto rozumná úvaha. Na tom čísle prostě není nic špatně. Jenom se nikdo nezeptal na to, co stojí každý rok žít s tím, že máte v jádru účetnictví vlastní kód, který nikdo jiný na světě nemá a nikdo jiný ho neumí opravit.

Co konkrétně přestalo fungovat?

Nasadili to 11. dubna 2022 bez zkušebního běhu a bez paralelního provozu se starým systémem. A tady je detail, který stojí za pozornost: paralelní běh nebyl opomenutí. Řídící výbor ho měl 25. března 2022 na stole jako jednu ze tří variant: nechat starý SAP a nový Oracle počítat mzdy vedle sebe, dokud se výsledky nesrovnají. Vybrala se varianta bez něj.

Rozbila se hlavně bankovní rekonciliace, tedy párování plateb na výpisech proti účetnictví. Desetitisíce hotovostních transakcí nešlo dohledat do účetnictví: místní daně, platby dodavatelům, rozpočty škol. Podle zprávy auditora pro auditní výbor z ledna 2024 jich bylo přes 70 000 a musely se dohledávat a opravovat ručně. Jedna chyba v úpravě systému nechala nespárované transakce v čisté hodnotě 74 milionů liber a v roce 2023/24 systém zaúčtoval transakce za dvě miliardy liber do špatného roku.

Nešlo ale jen o rekonciliaci. Ještě na jednání řídícího výboru 19. května 2022, šest týdnů po nasazení, nebylo zapnutých 34 z 82 integrací na okolní systémy. Za prvních šest měsíců provozu radnice zaevidovala přes osm tisíc incidentů.

Graf incidentů hlášených v Oraclu po měsících od dubna 2022 do prosince 2023

Vrchol přišel v květnu 2022, měsíc po nasazení: 2 121 tiketů. Poslední sloupec je jen do 8. prosince 2023, proto je tak nízký. Zdroj: Grant Thornton UK LLP, Report in the Public Interest, 11. 2. 2025, příloha J, str. 61.

Na tom grafu mě zaujalo něco jiného než ten vrchol. Křivka nikdy nespadne k nule. Ještě v listopadu 2023, rok a půl po nasazení, přibylo 567 incidentů za měsíc. Porodní bolesti to po roce a půl už fakt nejsou.

K tomu se ukázalo, že systém byl nastavený bez oddělení pravomocí a bez kontrol při zaúčtování. Model přístupových práv byl stoprocentně vlastní, postavený tak, aby napodobil starý SAP a měl díry, kterými se lidi dostali k datům mimo svoji odpovědnost. Modul, který tohle riziko hlídá, naběhl až v září 2023 a ani pak neuměl pokrýt všechny úpravy, které si radnice do systému dopsala. Když auditor na začátku roku 2024 psal svoji zprávu, radnice pořád nedokázala své transakce spolehlivě auditovat.

A pak dvě věty, které jsou z mého pohledu nejhorší z celé kauzy. Auditoři v lednu 2024 konstatovali, že jednotlivým odborům nebyly poskytnuty žádné reporty o čerpání rozpočtu za roky 2022/23 ani 2023/24. A finanční ředitel v únoru 2024 dodal, že se nedalo spolehnout ani na ty nejzákladnější finanční informace ze systému.

Město s rozpočtem přes tři miliardy liber tedy dva roky hospodařilo bez čísel, na která by se dalo spolehnout.

Ten business case se obrátil ještě před startem

Tohle je věc, kterou bych nejradši vytiskl a pověsil na zeď.

V červenci 2019 vypadal záměr takhle: zaplatíme 19 milionů, ušetříme 26,9 milionu. Dává to smysl, do toho jde každý.

V březnu 2021, kdy se to finálně schvalovalo, vypadal takhle: zaplatíme 39 milionů, ušetříme 10,9 milionu. Cena se zdvojnásobila, přínos spadl na necelou polovinu.

Ještě jedna věc se v březnu 2021 změnila a v těch papírech se skoro ztrácí. Původně se mělo nasazovat ve dvou vlnách – finance a nákup v prosinci 2020, personalistika a mzdy v únoru 2021. Nově šlo všechno naráz. Riziko se tím znásobilo a byla to poznámka pod čarou v dokumentu, jehož hlavním tématem byly peníze.

Čili než se nasadil jediný modul, byl business case naruby. Původní poměr přínos ku ceně byl 1,4. Nový byl 0,28. Je fér dodat, že to není poctivý poměr – porovnává jednorázový náklad s úsporami rozloženými do celé životnosti programu. Ale posun mezi tou první a druhou verzí měří obojí stejně, takže o něčem vypovídá. Přesto se to schválilo a jelo dál. Technicky se přitom nestalo vůbec nic. Jenom se nikdo nezastavil a neřekl, že tohle už není ten projekt, který se schvaloval.

Já vím, jak se to stane. Když už jsou v projektu dva roky práce a spousta peněz, nikdo nechce být ten, kdo řekne „tak jsme se spletli, končíme“. A přesně proto je dobré mít ten práh napsaný předem, v rozhodnutí zaznamenaném písemně, ještě než začnete. Kdy tenhle projekt zastavíme? Když padne co?

To číslo: 216,5 milionu, a jak vzniklo

Stejně jako u Lidlu si i tady zaslouží hlavní číslo vysvětlení, protože se v médiích používá dost volně.

Částku 216,5 milionu liber spočítal Audit Reform Lab při University of Sheffield (autoři James Brackley a Adam Leaver) z veřejných podkladů radnice. Skládá se takhle:

Položka Částka
Přímé náklady na Oracle do února 2024 86 mil. £
Zhoršení nedobytných pohledávek (business rates) 23/24 12,5 mil. £
Schodek na výběru místní daně (council tax) 23/24 4 mil. £
Odepsané plánované úspory 23/24 69 mil. £
Dopad na General Fund k březnu 2024 171,5 mil. £
Rozpočet na Oracle do dubna 2026 45 mil. £
Celkem k dubnu 2026 216,5 mil. £

Všimněte si, že přímé náklady na software a lidi jsou jen zhruba 60 procent. Zbytek je to, co se nevybralo a neušetřilo, protože systém nefungoval. To je mimochodem přesně ta část nákladů, kterou v žádné nabídce ani v žádném rozpočtu projektu neuvidíte.

Těch 86 milionů nejsou celkové přímé náklady, jenom to, co k únoru 2024 dopadlo na General Fund. Finanční ředitel radnice mluvil ve stejné době o 131 milionech. Každé číslo v téhle kauze měří něco trochu jiného a k jinému datu, což je taky důvod, proč se v médiích tak rozcházejí.

Pro srovnání: očekávaná úspora z celého projektu byla 10,9 milionu liber za celou dobu jeho životnosti.

Proč o tom třináct měsíců nikdo nevěděl?

Tahle část se netýká Oraclu ani ERP, ale úplně obyčejného fungování firmy.

Systém se rozbil v dubnu 2022. Rozsah problémů se k zastupitelům dostal až v květnu 2023. Mezitím zněla komunikace takhle:

  • Auditní výbor, říjen 2022: systém je nasazený, existuje plán na oblasti, které se ještě nestihly, počítá se s vyřešením během několika měsíců.
  • Zastupitelstvo, duben 2023: Oracle už prý dodává širokou škálu důležitých funkcí včetně mezd a plateb dodavatelům a od roku 2023/24 začne přinášet úspory.

Ani jedna z těch vět není vyloženě lež. A přesně proto to fungovalo, protože obhájit se dají obě a přitom z nich nikdo nepozná, co se doopravdy dělo.

Grant Thornton to ve své zprávě pojmenoval dvěma způsoby, které stojí za zapamatování. Píše o optimism bias u vedení projektu i dodavatelů, kteří měli protichůdné motivace: udržet rozpočet, neposunout termín a ochránit reputaci. A pak přidává větu o kultuře organizace, že špatné zprávy nebyly vítané, nebo se je lidi neodvažovali sdělovat.

Těch třináct měsíců se počítá k prvnímu podstatnému materiálu pro auditní výbor v květnu 2023. Je to konzervativní číslo: plný rozsah průšvihu se přes orgány radnice dostával ven ještě celý podzim 2023 a doopravdy až v lednu a únoru 2024, skoro dva roky po nasazení.

Rizika přitom nikdo neschovával. Byla v podkladech. Jenom byla v detailu příloh, ne v tom, co si přečetl člověk, který o nasazení rozhodoval. Zpráva to říká natvrdo: kdyby byla informace o kvalitě a úplnosti testování prezentovaná jasněji, program by nasazení nejspíš neschválil.

Jak dostane zelenou modul, který prošel z 29 %?

Teď k tomu, co se dělo o patro níž, na jednání řídícího výboru 1. dubna 2022, deset dní před spuštěním.

Testování bankovní rekonciliace se nikdy nedokončilo, protože systém nebyl dost stabilní. Ale ve výstupu pro řídící výbor stálo, že u bankovní rekonciliace nejsou žádné otevřené defekty kromě občasných problémů.

Čísla z testů, která k tomu výstupu patřila, vypadala takhle:

Testovací kolo Testů Provedeno Prošlo
UAT 1, cyklus 1 – finance celkem 776 71 % 62 %
– z toho modul hotovosti (bankovní rekonciliace) 62 82 % 29 %
UAT 1, cyklus 2 – jen plánování rozpočtu 54 80 % 80 %
UAT 2 – finance celkem 77 65 % 43 %
– z toho pohledávky 18 61 % 6 %

Výtah z finálního reportu o testování s výsledky UAT pro finanční moduly

Řádek „CM“ je Cash Management, tedy ten modul s bankovní rekonciliací. Zdroj: Grant Thornton UK LLP, Report in the Public Interest, 11. 2. 2025, příloha I, str. 60.

Ta procenta jsou počítaná z naplánovaných testů, ne z provedených. U modulu hotovosti prošlo 18 testů z 62 naplánovaných. A v UAT 2, kde měl ten samý modul naplánované tři testy, se nespustil ani jeden. (V tabulce výš ten řádek není, je ve stejné příloze zprávy.)

Výstupní kritérium pro ukončení testování přitom znělo: sto procent testovacích případů provedeno. A tady je odpověď na otázku z nadpisu. Hned za tím kritériem totiž stálo v závorce „nebo vyřazených z rozsahu“ a další bod dovoloval řídícímu výboru odložit část oprav i u defektů dvou nejvyšších stupňů závažnosti do provozní podpory. Nemuselo se tedy nic obcházet, ta výjimka byla zabudovaná od začátku. I tak podle auditora testování za vlastními kritérii radnice výrazně zaostalo a jako celek dostalo v reportu status zelená.

Takhle vypadala mapa připravenosti, kterou na tom jednání dostali:

Heatmapa připravenosti jednotlivých modulů Oraclu, téměř celá zelená

Zdroj: Grant Thornton UK LLP, Report in the Public Interest, 11. 2. 2025, příloha F, str. 57.

Oranžová jsou čtyři políčka, zbytek zelený. A teď se podívejte doleva, čtvrtý řádek odspodu ve sloupci Cloud Financials: Cash Management, zelená. To je ten modul s 18 prošlými testy z 62.

Zástupce jednoho z týmů tuhle prezentaci připravenosti označil za nerealistickou. A ze zásadního jednání 7. dubna 2022, čtyři dny před spuštěním, neexistuje zápis.

Nemyslím si přitom, že by někdo lhal. Ta zelená políčka někdo poctivě vyplnil podle nějakého pravidla. Jenom to pravidlo měřilo něco jiného než „funguje to“. A to se dá zopakovat v jakékoli firmě a na jakémkoli projektu.

Co na to dodavatelé?

Na tom samém jednání prvního dubna dostali slovo všichni tři hlavní dodavatelé. Evosys, Socitm i Egress reportovali zelenou a shodně doporučili spustit.

Nejlíp je vidět na Socitmu, jak se to dělá. Do zápisu uvedli, že jsou problémy s přístupem ke školení a že se nedá školit na kompletním řešení, protože se pořád opravují defekty. A pak doporučili jít do toho. Obojí v jednom odstavci.

Ta konstrukce dodavatelů má přitom vlastní vadu. Systémovým integrátorem byla na papíře Insight UK a Evosys byl její subdodavatel, takže když se to začalo sypat, radnice zjistila, že se k Evosysu obtížně dostává přes prostředníka. A orgán, který doporučoval proplácení milníků, byl podle auditora podstatnou měrou vedený zástupci právě těch dodavatelů, kterým se ty milníky proplácely.

Pak přišel říjen 2022. Radnice v té době tonula v problémech, a přesto vystavila certifikáty o dokončení a podporu předala dál. Auditor k tomu píše jednu suchou větu: není jasné, proč to udělala.

Zbytek už je smutná dohra. V prosinci 2022 poslala radnice Insightu a Evosysu dopis s výčtem problémů a požadavkem na vyjádření do konce března. Evosys odpověděl v březnu 2023, v květnu nabídl pomoc a v září předložil plán, jak to dát dohromady – na ten už mu nikdo neodpověděl. Sám se přitom hájí tím, že se o povaze problému s bankovní rekonciliací dozvěděl až v lednu 2023, tedy po konci svojí podpory, a že radnice odsouhlasila každý milník.

Zlého dodavatele v tom nehledám. Jde spíš o to, že u velkého projektu reportují nakonec všichni tomu, kdo je platí, a nikdo z nich nemá důvod být ten první, kdo řekne stop.

Kdo tedy měl říct dost?

Tahle otázka má u Birminghamu písemnou odpověď a je nepříjemná.

Odpovědným vedoucím programu a zároveň finančním ředitelem radnice byl jeden a ten samý člověk. Sponzorem byl generální ředitel, ale pravomoc program řídit delegovala rada města schváleným business casem právě na finančního ředitele. Auditor dodává, že spojení funkční a programové role samo o sobě není nic neobvyklého, jenže to vyžaduje pojistky, aby ostatní měli pořád odvahu oponovat, a ty tam nebyly.

Když se ho auditor zeptal na jeho odpovědnost, odpověděl písemně, že jeho role byla strategická, předsedal řídícímu výboru a nenesla žádnou provozní ani manažerskou odpovědnost za program. Jeho zástupce uvedl, že v programu neměl rozhodovací roli.

Auditor to konfrontuje s britským vládním standardem pro řízení projektů, podle kterého business case vlastní a za governance odpovídá právě ten, kdo je za program zodpovědný. A s tím, že tuhle pravomoc oběma delegoval schválený business case. Uzavírá to jako zásadní selhání dokumentace a evidence na straně radnice.

Zastupitelé na tom nebyli líp. Sami auditorovi řekli, že jim chyběla kapacita i odbornost, aby úředníkům mohli klást smysluplný odpor, a že jim reporty problémy sice přiznávaly, ale zlehčovaly. Zástupce vedoucího radnice popsal orgán, který měl na IT strategii dohlížet, jako příliš provozní na to, aby v něm politik vůbec seděl.

Takže na otázku, kdo měl v Birminghamu říct dost, existuje doložená odpověď: nikdo se k té roli nehlásí.

Položil Oracle radnici?

Tady musím být opatrný, protože se to často zkracuje na „ERP zbankrotoval město“, a to není přesné.

Section 114 taky není bankrot v našem slova smyslu. Britské obce nemůžou padnout do insolvence a nikdo na ně nepošle konkurz. Je to zpráva, kterou finanční ředitel oznámí, že výdaje přesahují zdroje, a která zastaví nové utrácení, dokud se zastupitelstvo nedohodne na řešení. Zní to míň dramaticky, ale pro chod města je to stopka.

A Oracle ta zpráva vůbec nezmiňuje, slovo Oracle v tom dokumentu není ani jednou. Jako důvod uvádí závazek z titulu rovného odměňování, který odhaduje v rozpětí 650 až 760 milionů liber. Zdroje z radnice včetně hlavního vládního komisaře Maxe Callera později pro Financial Times mluvily o realističtějším odhadu kolem 250 milionů a Caller sám těch 760 označil za scénář nejhoršího případu, spočítaný v době, kdy ještě nebyla ve hře dohoda s odbory.

Audit Reform Lab z toho vyvozuje, že skutečnou příčinou byl Oracle spolu s růstem poptávky po sociálních službách a inflací, ne nové nároky na rovné odměňování. Grant Thornton je opatrnější a mluví o Oraclu jako o „přispívajícím faktoru“.

Staví to na jednom srovnání: v roce před nasazením Oraclu skončila radnice s rozpočtovým deficitem 3,1 milionu liber. V roce, který začal nasazením, spotřebovala 336,2 milionu liber rezerv. Nejsou to dvě stejně měřená čísla, ale ten skok je tak velký, že samotnými nákladovými tlaky se vysvětlit nedá. Zároveň ale platí, že Birmingham měl problémy i bez Oraclu.

Mně z toho vychází, že ji Oracle nepoložil, ale zaslepil. A organizace, která dva roky nevidí na svoje čísla, nedokáže včas zareagovat na nic, ani na to, co ji položí doopravdy.

Mimochodem v létě 2021, tedy necelý rok před nasazením, dostal Birmingham od CIPFA tříhvězdičkové hodnocení a v tiskové zprávě se psalo o „inspirativní cestě“ ke zdravému finančnímu řízení. Rok je v tomhle oboru fakt krátká doba.

Co to udělalo s městem

Tuhle část jde snadno přeskočit, protože se v ní nemluví o systémech. Přitom je to jediné, na čem u takového projektu nakonec záleží.

Měsíc po Section 114 přišla vládní intervence. Birmingham od října 2023 řídí radnice spolu s vládními komisaři a jejich mandát běží do října 2028.

Co se dělo mezitím:

  • Dvě po sobě jdoucí kola úspor, zhruba 150 milionů liber v roce 2024/25 a dalších 149 milionů v 2025/26. Podle Audit Reform Lab šlo aspoň 70 milionů z prvního kola přímo ze služeb lidem a v návrzích bylo asi šest set rušených míst.
  • Místní daň nahoru o 9,99 % a rok nato o dalších 7,5 %. Radnice chtěla podruhé zase skoro deset procent, tolik jí vláda nepovolila. Za dva roky to dělá zhruba osmnáct procent.
  • Rozprodej majetku. Původní cíl 750 milionů liber se loni zvedl na miliardu. Zatím se prodalo za 320 milionů.
  • Rámec výjimečné finanční podpory 1,25 miliardy liber od vlády. Radnice ho podle komisařů nechce vyčerpat celý, protože se splácí právě z prodeje majetku.
  • A pak věci, které jsou vidět z ulice: pouliční osvětlení se ztlumilo (úspora 900 tisíc liber), popelnice se vyvážejí jednou za čtrnáct dní místo každý týden (přes 4 miliony), podpora kultury spadla o polovinu a další rok na nulu.

Musím zopakovat, že tohle není účet za Oracle. Je to účet za rovné odměňování, za deset let škrtů a za Oracle dohromady a rozpočítat to mezi ně přesně nejde.

Komisaři v prosinci 2025 napsali, že radnice nemůže čekat čistý výrok auditora dřív než v roce 2027/28 – a jako hlavní důvod uvedli, že chvíli potrvá, než se vypořádá s pozůstatky po Oraclu. Ve stejné zprávě je i položka, která je z celé kauzy asi nejnázornější: radnice má pořád zhruba 650 milionů liber nevymožených pohledávek, mimo jiné proto, že se v některých službách roky nedalo vymáhat pořádně nebo vůbec.

Systém se nasadil v dubnu 2022. Nejdřív v roce 2027/28 bude město moct dostat účetnictví, o kterém auditor řekne, že sedí. To je šest let, kdy se všechno ostatní rozhoduje poslepu.

Co dělají teď?

Nasazují Oracle znovu. Tentokrát podle vlastního závazku z ledna 2024 s přijetím standardních procesů a konfigurace Oraclu, tedy out of the box. Bankovní rekonciliaci vytáhli ze systému úplně a řeší ji samostatným produktem třetí strany.

Nedaří se to hladce. Spuštění se posouvalo z roku 2025 na duben 2026 a pak na léto 2026, protože testování ukázalo, že lidi ještě nejsou připravení a mzdy by nemusely sedět. Na auditním výboru se na přelomu ledna a února 2026 jako živá rizika probíraly kvalita dat, nedostatek lidí a řízení projektu. Celkový výhled nákladů programu je 144,4 milionu liber do rozpočtového roku 2027/28.

Takže po sedmi letech a několika stovkách milionů se Birmingham dostal přesně tam, odkud v roce 2019 vycházel: nasadit standardní Oracle a přizpůsobit se mu.

Proč mě to zaujalo?

Protože Lidl a Birmingham dohromady dávají odpověď, kterou jsem u Lidlu ještě neměl.

Lidl si z fiaska odnesl „standard pro nás není, postavíme si vlastní“. Birmingham si odnesl „tak dobře, přizpůsobíme se“. A obojí může být správně – rozdíl je v tom, jestli je odlišnost vašich procesů konkurenční výhoda, nebo jen zvyk. U Lidlu, kde je logistika a oceňování zásob jádro byznysu, se vlastní systém obhájit dá. U radnice, která vyplácí mzdy a vybírá daně, těžko.

Ta otázka „je tohle naše konkurenční výhoda, nebo jenom zvyk?“ je jediná otázka, kterou u požadavku na customizaci potřebujete. A odpovědět se na ni dá jen tehdy, když se zeptáte dřív, než napíšete první úpravu.

A pak je tu druhá věc, kvůli které jsem u toho zůstal dýl, než jsem chtěl. Projekty, na kterých dělám, jsou proti Birminghamu drobné. Jenže ta rozhodnutí jsou úplně stejná, jen mají o tři nuly míň.

Rozdíl je jenom v tom, že u malého projektu nikdo nepíše auditní zprávu. Když se úprava po třech letech vymstí při upgradu, nevyjde o tom sedmašedesát stránek – odneseme si to já a zákazník. O tom, jak se cizímu systému bránit technicky, jsem psal u anti-corruption layeru. U Birminghamu mi ale došlo, že ta obrana musí být nejdřív organizační.

Jak to spadne, když všechno svítí zeleně?

Odpověď je po článku rozdrobená, tak ji dám tady dohromady. V Birminghamu se sešly čtyři věci a ani jedna z nich není o Oraclu:

  • Kritérium mělo výjimku zabudovanou uvnitř. Auditor uzavírá, že testování za vlastními kritérii radnice výrazně zaostalo. Nasazení to nezastavilo.
  • Brzda byla podřízená tomu, koho měla brzdit. Předseda orgánu, který měl zamítat odchylky od standardu, sám říká, že se odmítnout nedaly, obzvlášť když za nimi stál odpovědný vedoucí programu.
  • A ten vedoucí byl zároveň ten, koho měla kontrola hlídat. Byl to finanční ředitel radnice: předsedal řídícímu výboru programu a současně odpovídal za hospodaření celého města.
  • Dohled existoval, ale neměl čím oponovat. Zastupitelé v auditním výboru se ptali. Sami ale auditorovi řekli, že jim chyběla kapacita i odbornost, aby úředníkům kladli smysluplný odpor, a že jim reporty problémy sice přiznávaly, ale zlehčovaly.

Kritérium bylo napsané, brzda existovala, role byly obsazené, výbor se ptal. Dohromady z toho ale nevyšel nikdo, kdo by mohl říct dost.

A to je jediná věc, kterou si z Birminghamu beru do vlastní práce. Zeptejte se u svého největšího projektu, kdo má právo ho zastavit a jestli to ten člověk sám o sobě ví.

Zdroje

Michal Katuščák
Michal Katuščák

Navrhuji a vyvíjím aplikace nad Symfony a Reactem, zajímám se architekturu softwaru. Žiju v Českých Budějovicích.