A SZIR-rendszert a leválás után már nem lehetett segítségül hívni. A kialakult káoszban a munkavállalók elképesztő erőfeszítéseinek köszönhetően pár hét alatt helyre állt a vonatközlekedés. A blamázs - becslések szerint - 300 millió forint többletköltséget jelentett a társaságnak.

A szakszervezetek fellépése nyomán a munkavállalók a túlóra díjazásán felül is kifizetésben részesültek. Christian Kern, az ÖBB Holding igazgatóságának akkori elnöke a VDSzSz Szolidaritás székházában tett látogatása alkalmával a „menedzsment hiba” kifejezést használta a történtekre. Az események kivizsgálását, esetleges felelősök megnevezését az Európai Üzemi Tanács ülésén kértük. Elmondtuk, hogy egy ilyen trauma után a munkavállalóknak joguk van megtudni, miként alakult ki ez az umbulda.

Javasoltuk, hogy a vállalati hírmondón keresztül tegyen a menedzsment őszinte, beismerő vallomást. Akkor ez az ötlet nagy tetszést váltott ki Kasperkowitz és Först igazgatóknál, de a nekibuzdulást nem követték tettek. Azóta is csak találgatások és egymásra mutogatások zajlanak. De már talán az sem. A főszereplők inkább a feledés jótékony fátylát borítanák az ügyre. Mivel nem került tiszta víz a pohárba, ezért magunk próbáljuk a történtek egy szeletét feltárni az alábbi levelezés közzétételével:

A piros sarokban (és betűvel): Péger Zoltán, akkori RCH IT vezető
Kék sarokban (és betűvel): Hannes Heiling, Kurt Pichler és Gerhard Senfter IT fejlesztéssel foglalkozó munkatársak Ausztriában

„BAPS/TKP:
Ez a program nem döntő jelentőségű a SZIR leváltása tekintetében.
Tiszteletben tartva Senfter úr véleményét, megítélésem szerint ezt az RCH üzemeltetési szervezetének kell eldöntenie. Ha ők is ezt állítják, akkor egyetértek.

Gerhard Senfter: Ha a szállítási lánc tervezése és az így bejövő ügyfél-információk nem is hiba nélkül működnek, legrosszabb esetben is csak csekély imázsveszteséget okoz az ügyfeleknél.
Azt, hogy ez az imázs vesztés felvállalható-e, megítélésem szerint az RCH kereskedelmi szervezetének kell eldöntenie. Nem ICT kompetencia.

RC.TiS:

Az RC.TIS valamennyi szükséges funkciója megvan és teljes mértékben használatra készen áll.
Ha ez így van, miért panaszkodnak a projekt tagjai és a tesztelők folyamatosan?
Lehet, hogy nem tudják, hogyan kell használni a rendszert?
Tudják, mikor mit kell tenniük és azt milyen sorrendben?
Van dokumentáció? Megfelelően ki lettek oktatva?

A SZIR leváltásának nincs semmi akadálya.
De mint tudjuk, a SZIR leváltása nem csak az RC.TIS bevezetéséből áll.
Kell hozzá a többi új alkalmazás is, ki kell vezetni a SZIR-t és a ZAIR-t úgy, hogy azok működőképesek maradjanak, a MÁV tudja őket használni, és végül, de nem utolsó sorban az üzleti folyamatainkat is igazítani kell az új működéshez nem csak a valóságban, hanem a fejekben is(!).

A szükséges fájlok (Docker, OKF, MÁV Pályavasút, H30, ...) elő vannak állítva, és – ahogy megállapodtunk – az SI-nek feltérképezésre és az útvonal megválasztására át vannak adva. A feltérképezés és az útvonal megválasztása az SI feladata és nem az RC.TIS-é.
Az lehet, de a végcél szempontjából mindegy, hogy az RC.TIS vagy az SI hibájából nem működik.

ZugDB, Hannes Heiling:

A ZugDB már hosszabb ideje üzemben van, a lecserélésnek sincs semmi akadálya. A menetrendek RC.TIS-be való átadásában pillanatnyilag akadnak nehézségek, amelyek elhárítása a következő naptári héten elsődleges feladat.
Azaz: az elmúlt két hétben nem működött, és így minden teszteset az első lépésnél már az elején elbukott.

Az RC.TIS-be való adatátvitel nem akadálya az indulásnak, mivel ez törzsadat-kezelőket és a felhasználókat a napi munkájában támogatja. Az RC.TIS-be minden vonat és menetrend kézileg is bevihető, a menetrendek optimalizálását pedig amúgy is a törzsadat-kezelőknek kell kézzel elvégeznie (állomás-függő karbantartás).
Csak ugye, ahogy hallom az üzemeltetési területen dolgozó kollégáktól itt Magyarországon arra nincs elegendő humán erőforrás, hogy amit az egyik rendszerbe már bevittünk, újra bevigyük a másikba.
Nem tudom megítélni, mi az igazság, de talán nem is tisztem.

A ZugDB-RC.TIS interfész (VDB) tehát nem akadálya a SZIR leváltásának.
Ezzel a fentiek alapján nem tudok teljes mértékben egyetérteni.

e-fb@:

Az e-fb@ szempontjából nincs kockázat. 2013. 06. 13-án ezt a verziót kiadták Ausztriában, és azóta stabilan fut. Az integrációs teszt során egyetlen egy hiba merült fel, amelyet azóta kijavítottak.
Arról, hogy mennyire stabil az efb@ és a teszt efb@ az általam is nyomon követett servicedesk bejelentések tanúskodnak. A helyzet korántsem olyan rózsás.
Magyarul: esik-kel mindkét rendszer hetente többször is.

SI:

Az SI szempontjából nincs kockázat. Az e-fb@-adatcsere változatlan maradt. A H30-adatcsere valamennyi követelménynek megfelelően valósult meg, az útvonalak megválasztása megfelelően megtörtént.
Hát ehhez inkább nem is írok semmit.

RTLM, Kurt Pichler:

Az RTLM szempontjából nincs komoly kockázat. A tesztek sikeresen lezajlottak illetve zajlanak, minden követelmény ki van elégítve.

Ahogy én tudom, az üzleti integrációs tesztesetek kb. 10%-át tudtuk eddig végrehajtani és ebből kb. 0% volt sikeres.
Lehet, hogy ez nem az RTLM hibája, de talán mindegy is.

Az én szempontomból NINCS akadálya az indulásnak.

Általánosságban:
Mindezzel nem akarom az mondani, hogy az átállás teljesen veszélytelen. Ez alatt azt értem, hogy a feltételek teljesültek és tesztjük sikeresen lezajlott. Nincs olyan veszély, hogy új, meg nem rendelt követelmények bukkannának fel.
Fennáll annak veszélye, hogy az ilyen nagy átállási munka során nem a terv szerint zajlik le. Ha az egyik fogaskerék nem kapaszkodik a másikba, akkor természetesen az egész rendszer leállhat.

Nagyon szép, politikus vélemény, de sajnos – ahogy én tudom - nem engedhetjük meg magunknak ezt a leállást!
Mindent meg kell tenni annak érdekében, hogy a kockázatokat minimalizáljuk.
Ennek elengedhetetlen feltétele, hogy az üzleti integrációs teszt sikeresen lefusson, ez a minimum!”

Ezen levélváltásokon túl számos vezetői előterjesztés (pl. 10240/2013.) tanúskodik arról, hogy a rendszert nem lett volna szabad ezen a napon útjára indítani. A jelentések hemzsegnek a „magas kockázati szint”, a „további tesztelések szükségesek” kifejezésektől, és a határidők kitolását javasolják.

„A kritikus problémák megoldása a tervezett átállásig hátralévő időben nem reális, egy korai erőltetett bevezetés alapjaiban veszélyeztetné a cég működését.”
A fentiek ellenére – feltételezhetően – a menedzsment mégis a bevezetés mellett döntött…

Mózes Tibor, VDSzSz Szolidaritás Cargós társasági vezető ügyvivő

Tartozz közénk, erősíts minket: lépj be Te is a VDSzSz Szolidaritáshoz! Legfontosabb szolgáltatásainkat itt találod! A belépéshez keresd területi irodáinkat, a Tagdíjlevonási nyilatkozatot itt találod.

Szeretnél elsőkézből értesülni a legfrissebb hírekről? Csatlakozz a VDSzSz Szolidaritás facebook-oldalához!