A bénázás költségeit a Birmingham City Council, pontosabban az önkormányzatnak adót fizetők állják.
Hirdetés
 

Egy IT-projekt definíció szerint akkor sikeres, ha adott határidőre és a becsült költséget nem meghaladva valósítja meg célkitűzését. De mint korábban is foglalkoztunk vele, ezeknek a kritériumoknak a teljesítése nem magától értetődő. Egy brit önkormányzatnak sikerült is összehoznia az IT-projektek állatorvosi lovát.

Az Egyesült Királyság második legnagyobb önkormányzata, a Birmingham City Council (BCC) már lassan 120 millió dolláros (kb. 100 millió font) költségnél tart egy olyan Oracle-projektnél, amit eredetileg kevesebb mint 50 millió dollárra becsültek. A 2018-ban elindított projektet 2020-ra kellett volna befejezni, de még mindig nem látszik a vége.

SAP-t Oracle-re, hogy olcsóbb legyen

Az önkormányzat 2018-ban úgy döntött, hogy két évtized után lecseréli az addig használt SAP rendszerét az Oracle felhőalapú ERP-rendszerére, a Fusionre. A Financial and People néven futó projekt célja az volt, hogy az önkormányzati feladatok ellátását – mindenekelőtt a HR- és a pénzügyi folyamatokat – hatékonyabbá és olcsóbbá tegyék. Az önkormányzati ERP-ben kezelik többek között az iskolákat, a szociális ellátó rendszert, de még az útkarbantartásokat is.

Csak hogy jobban érzékeljük, milyen méretű szervezet is választotta az Oracle rendszerét: a BCC évente 4,2 milliárd dollárnyi fontból gazdálkodik, és több mint 4 millió ember életét szervezi. Döntése egyébként az Oracle számára is jelentős fegyvertény volt. Larry Ellison 2021 márciusában a negyedéves jelentés utáni konferenciahíváson az SAP-nak címzett győzelmi jelentésében tételesen is említett két nagy brit önkormányzatot, köztük a BCC-t, melyeket sikerült elcsábítani a Fusionnel az SAP-tól, emlékeztet a The Register.

A projekt mindaddig nem kapott különösebb figyelmet, míg tavasszal egy iskoláról ki nem derült, hogy nem tudja fizetni a számláit, mert valami hiba lépett fel a Fusionben.

Hibákat hibára...

Ilyen esetben mindig beindul az egymásra mutogatás. De valójában mi okozta a kudarcot? Nézzük sorban.

1. A The Registernek egy névtelenül nyilatkozó szakértő azt mondta, hogy a Fusion nem igazán alkalmas az önkormányzati igények kielégítésére. Az ERP-t ugyanis elsősorban a gyártó és kereskedelmi vállalatokra tervezték. Persze, tette hozzá a szakértő, ugyanez igaz az SAP-ra is, ám utóbbit az idők folyamán a BBC olyannyira saját céljaihoz szabta, hogy – leszámítva a kisebb problémákat –, maradéktalanul ellátta a rá bízott feladatokat.

Persze a Fusiont is igyekeztek testre szabni, ám az önkomrányzat számára fontos funkciókat olyan bonyolult módon tudták megvalósítani, hogy a fellépő hibákat szinte lehetetlen volt javítani.

2. Mindenki megfeledkezett arról, hogy egy merőben új rendszer bevezetésekor nagyon komoly képzésben kell részesíteni a felhasználókat. Az önkormányzati alkalmazottak emellett azzal is szembesültek, hogy azok az automatizált folyamatok, amik a két évtized alatt letisztult formában megvalósultak, teljes mértékben elvesztek. Ezeket egy sor bonyolult manuális folyamattal kellett helyettesíteni egy nem kellően ismert rendszerben, ami miatt nőtt a hibalehetőség.

3. Hiányzott a belső kompetencia. Bár volt dedikált csapat a Fusion üzemeltetésére, egy idén tavasszal készített belső jelentés arra jutott, az önkormányzati IT-oszálynak nem volt meg a rendszer zavartalan működtetéséhez szükséges tapasztalata és tudása.

4. Kialakult egy súlyos single point of failure (SPOF) is (azaz olyan pont, amelynek meghibásodása a teljes rendszer leállását eredményezi): az Oracle rendszerében egyetlen ember menedzselhette a szerepköröket.

Innen csak egy irányba vezet út

Ez egy olyan projekt, ahol már nincs visszaút. Az önkormányzat működésének fenntartásához tovább kell vinni, és most az a cél, hogy minél előbb kiküszöböljék a rendszer működési anomáliáit.

Aminek persze további költségei lesznek, és nem fog menni egyik napról a másikra. A problémák eddig (kisebb fennakadásoktól eltekintve, lásd a fenti példát) nem akadályozták az önkormányzatot feladatai ellátásában, de ez nem volt ingyen. Például több mint 6 millió dollárjába (5,1 millió font) került az önkormányzatnak, hogy az Fusion bevezetésének csúszása miatt biztosítsa az SAP R/3 rendszerhez való hozzáférés.

És végül, de nem utolsósorban: a városatyák valószínűleg lemondhatnak azokról a megtakarításokról, amelyeket a rendszercserétől reméltek.

Cloud & big data

Külső appok és dolgozók is hullanak a Redditnél

A közösségi fórum igyekszik egyenesbe rakni magát a várható tőzsdére lépés előtt, de a folyamat messze nem fájdalommentes.
 
Hirdetés

Sokkolja a magyar cégeket, hogy ilyen támogatás is létezik

Mennyibe kerülhet, hogy a hoszting szolgáltató éjjel-nappal 60 másodpercen belül felvegye nekünk a telefont, és vezető rendszergazdái azonnal foglalkozzanak a problémánkkal? A vshosting~ szerint nem is biztos, hogy annyira sokba.

Valószínűleg soha. A piackutatók szerint a felhő mellett is dinamikusan növekszik a hosting iránti igény.

a melléklet támogatója a vshosting

Létezik egy ortodox irányzat, mely szerint a jelszavak legyenek minél hosszabbak és összetettebbek, valamint cseréljük azokat minél gyakrabban. Valóban ettől lesznek a rendszereink biztonságosabbak? Pfeiffer Szilárd (Balasys) írása.

Miért ne becsüljük le a kisbetűs jelszavakat? 2. rész

Miért ne becsüljük le a kisbetűs jelszavakat? 3. rész

A felmérésekből egyre inkább kiderül, hogy az alkalmazottak megtartása vagy távozása sokszor azon múlik, amit a szervezetük nem csinál, nem pedig azon, amiben egymásra licitál a többi munkáltatóval.

Ezért fontos számszerűsíteni a biztonsági kockázatokat

Ön sem informatikus, de munkája során az információtechnológia is gyakran befolyásolja döntéseit? Ön is informatikus, de pénzügyi és gazdasági szempontból kell igazolnia a projektek hasznosságát? Mi közérthető módon, üzleti szemmel dolgozzuk fel az infokommunikációs híreket, trendeket, megoldásokat. A Bitport tizennegyedik éve közvetít sikeresen az informatikai piac és a technológiát hasznosító döntéshozók között.
© 2010-2023 Bitport.hu Média Kft. Minden jog fenntartva.