Modellalkotás buktatói

A hibás megoldások létrejöttének alapvető oka az, hogy az informatikai rendszer megalkotásakor a rendszer valamely összetevője túlsúlyba kerül, vagy háttérbe szorul a többi összetevőhöz képest. A legtöbb esetben szakmai hibák, vagy tévesen felismert, ritkábban tudatos érdekek vannak a háttérben.

Egy közmű-informatikai rendszert sokféle szempont szerint bonthatunk elemeire:

Fizikai szempontból

• hardver (számítástechnikai eszközök, adatátviteli hálózat)
• szoftver (operációs rendszer, alaptechnológiák, alkalmazásfejlesztések stb.)
• adat (szakági, földrajzi, fogyasztói, pénzügyi, gazdasági stb.)

Modellalkotás szempontjából

• tevékenységek
• folyamatok
• objektumok
• kapcsolat típusok

Bármelyik felbontásban szereplő elem túlsúlya, vagy háttérbeszorítása veszélyezteti a projekt megvalósítását.

Az adatok szerepének alábecsülése

A leggyakoribb hiba, amikor egy informatikai projekt tervezésekor és megvalósításakor a hardver- és szoftverelemek kiválasztására, beszerzésére kifejlesztésére helyeződik a hangsúly. Az adatgyűjtés, adatfeltöltés, változásvezetés időszükségletét, költségeit alulbecsülik. Adatok hiányában a rendszer évekig nem tölti be funkcióját, majd szép lassan eltűnik. A gépek és alapszoftverek elévülnek, leselejtezik azokat. A kiképzett szakemberek tudása elavul. A fejlesztésre költött pénzből semmi sem térül meg.

A rendszer újraélesztése az adatok hiánya miatt igen költséges művelet. Az ilyen rendszerek sorsa leggyakrabban az, hogy kiselejtezik. Előfordul, hogy néhány évvel később a közművállalat megpróbálkozik egy új rendszer bevezetésével, de a drága tanulópénz megfizetése után sokkal óvatosabb és körültekintőbb lesz a közreműködő partnerek kiválasztásában.

Az alkalmazói szoftver elégtelensége

Ebben az esetben a rendszer kiépítése hardver és alapszoftver oldalról megfelelő. Az adatok gyűjtése, feltöltése megtörtént. A probléma ott jelentkezik, hogy az alkalmazói szoftver funkcionalitása hiányos. A leggyakoribb hiba, hogy az igen látványos adatmegjelenítő, lekérdező, tematikus elemző funkciók mellett a változásvezető funkciók definiálása és kifejlesztése nem kap elég hangsúlyt. Különösen igaz ez az olyan típusú adatokra (pl. földrajzi adatok), melyek változása nem a közművállalat tevékenységéhez kötődik, ezért begyűjtésük nehézkes és sokszor nagy tömegben kell átvezetni azokat.

A változásvezető funkciók

• új objektum generálása
• objektum törlése
• objektum módosítása

közül az objektum generálás és törlés kifejlesztése általában nem okoz gondot, (az adatfeltöltéshez egyébként is létrehozzák ezeket). A módosító funkciók azonban az objektumkapcsolatok miatt

• topológiai kapcsolat
• szülő-gyermek kapcsolat
• relációs mezők kapcsolatai stb.

összetettebbek és szerteágazóbbak. Bármely funkció hiánya ahhoz vezet, hogy az érintett adatok karbantartása lehetetlenné válik. A rendszer ugyan jól működik, de az adatok lassan elévülnek.

A rendszer sorsa általában az, hogy megfelelő költségráfordítással pótolják a hiányzó funkciókat. Ez sok esetben költséges adatmodell váltással is járhat, de a nagyságrendekkel többet érő adatokat nem hagyják elveszni. A rosszul megtervezett és kivitelezett alkalmazói felület miatt a projekt befejezése elhúzódik, közben a hardverkörnyezet és az alaptechnológia elévül.

Földrajzi adatok hiánya

Egy közműszolgáltató cég műszaki nyilvántartása két különböző adatot kezel:

• szakági adatok
• földrajzi adatok (ingatlan-nyilvántartás, közműalaptérkép)

A szakági adatok tulajdonosa, kezelője maga a közműszolgáltató cég. A szakági adatokban bekövetkező változásokat az általa végzett tevékenységek generálják, ezek nyomon követése viszonylag egyszerű feladat. Míg a szakági adatok közmű specifikusak addig a földrajzi adatok elvben egységesek minden közművállalat számára. A földrajzi adatok tulajdonosa és kezelője az állam (földhivatalok, önkormányzatok). A földrajzi adatokban bekövetkező változások sokszor függetlenek egy közművállalat tevékenységétől. Ezek begyűjtése, változásvezetése állami feladat.

Magyarországon a digitális földrajzi adatok hiánya olyan projekteket szült, ahol megpróbálták a földhivatalok, önkormányzatok szerepkörét átvállalni, legtöbbször sikertelenül. A földrajzi adatok begyűjtése, változásvezetése, a célirányos közmű-informatikai rendszerbe való betöltése, átalakítása a kívánt formátumba sokszor meghaladja a projekt erőforrásait, lehetőségeit. A megoldás az azonos régiókban tevékenykedő közművállalatok együttműködése a földrajzi adatok előállítására. A költségek megoszlanak, és az egységes szabvány kidolgozása később óriási előnyöket jelent az információcserében.

Szép példa erre az RWE Szinergia projekt, ahol a budapesti közműcégek egy jelentős csoportja (Fővárosi Vízművek Zrt., Budapesti Elektromos Művek Nyrt., Fővárosi Gázművek Zrt.) összefogott és a Komunálinfó Zrt.-vel együttműködve, kölcsönösen előnyös kompromisszumokkal képesek voltak egységes digitális közműalaptérképi hátteret teremteni nyilvántartásuk támogatására.

Hibás modellezés

Ha megvizsgáljuk az eddig kifejlesztett jelentős közmű-informatikai rendszereket azt tapasztaljuk, hogy a tervezési, fejlesztési, telepítési fázisában a közművállalatok külső informatikai szakcégeket vonnak be a megvalósításba. A két fél között fontos a közös szakmai nyelv kialakítása, az együttgondolkodás megteremtése. Ami a közműszakember számára természetes, az újdonság lehet az informatikusnak és fordítva. A nem megfelelő párbeszéd hibás modellalkotáshoz vezethet, ami sokszor csak a projekt végső fázisában, vagy esetleg jóval az üzembe helyezés után derül ki.

Képzeljük el, hogy egy gázszolgáltató külső szakcéggel közösen létrehozza műszaki nyilvántartó rendszerét. Együttműködésük eredményeként létrejön a rendszer és a korábban felsorolt buktatókat kikerülve sikeres projektet zárnak. A rendszer szépen üzemel, mindenki elégedett mindaddig, míg a gázszolgáltató életében szokványos, de nem túl gyakori esemény következik be: egy egyszerű művelettel átállítják az egyik körzet nyomásfokozatát. Az informatikai rendszerben kiderül, hogy a körzet által lefedett szakági objektumokon a nyomásváltozás átvezetése csak igen körülményes, hosszantartó, több hetes munkával hajtható végre. Miért? Mert a modellalkotáskor a nyomásfokozatot a szakági objektumok beégetett, statikus információjává tették. Ezzel ugyan a nyomásfokozatok közötti kapcsolatmodell (relációs mezők) kezelése funkcionális oldalról egyszerűbbé vált, de a dinamikus paraméter hiánya lehetetlenné tette a gyors átvezetést.

A megoldás új adat- és funkciómodell kidolgozását követelte meg, ahol a nyomásfokozat a szakági objektumok dinamikusan változtatható leíró adatává vált. A valóságban megtörtént eset kapcsán a szolgáltató jelentős erőforrás ráfordítás mellett, másik szakcéget kért fel az újratervezésre.