MINISZTERELNÖKI HIVATAL
INFORMATIKAI KOORDINÁCIÓS
IRODA

Bevezetés

A "milleneumi bomba" - egy egyszerû probléma katasztrofális következményekkel. Mivel a 2000. év beköszöntése az elsõ olyan évszázad váltás, amelyre automatizált társadalomban kerül sor, a számítógépeket használó intézmények idõzített bombán ülnek. Ilyen és ezekhez hasonló valóban "bombasztikus" megállapítások látnak napvilágot az utóbbi idõben a világ fejlettebb részének (elsõsorban az Egyesült Államok, Kanada és az Egyesült Királyság) számítógépes szaklapjaiban, közleményeiben, a WWW dedikált home page-ein, de a kérdéskör már a napilapok sõt a politikusok érdeklõdését sem kerüli el. A Gartner Group sokat idézett felmérése szerint a világnak 600 milliárd, míg csupán az Egyesült Államok adminisztrációjának 30 milliárd dollárjába fog kerülni a számítógépes rendszerek megfelelõ átalakítása. Még ha feltételezzük is, hogy Magyarország a veszélyeztetettség szempontjából "szerencsésebb" helyzetben van a fentebb említett országoknál, hiszen az informatizáltság szintje messze nem éri el ezekét, a meglévõ rendszerek is jóval fiatalabbak és ezért az alkalmazások többsége már nem a különösen "bomba veszélyt hordozó" COBOL nyelven készült, nem kerülhetjük meg a problémát. Ez azt jelenti, hogy nem "dughatjuk fejünket homokba" mintha a veszély nálunk nem létezne és abban sem bízhatunk, hogy létezik vagy létezni fog egy un. "silver bullet", amely a kérdéskör egyszerû, olcsó és gyors megoldását teszi lehetõvé. Míg a budapesti ICA konferencia kerekasztal beszámolóiból mindössze kettõ foglakozott a 2000-es év problémájával, az IPSIT (International Public Sector IT) csoport statisztikája azt mutatja, hogy tagországai (mintegy 15) adminisztratív intézményeinek 10%-a befejezte a szükséges változtatásokat, 18% jelenleg dolgozik ezeken, 50% még csak vizsgálja a témát és 23% az, amely hozzá sem kezdett a feladathoz. Az ITB-nek véleményünk szerint valamilyen formában el kell érnie, hogy legalább ne a statisztika utolsó tétele vonatkozzon ránk.

I. A probléma bemutatása

Az informatikai szakmában közismert, hogy a dátum adatokat az ISO vonatkozó elõírásait megszegve a memória takarékosság miatt a számítógépek és programok hagyományosan a szükséges 8 helyiérték helyett (DD-MM-YYYY) 6 helyiértéken (DD-MM-YY) tárolták. Míg az 1999. december 31. után a gépekben megjelenõ 01/01/00 értékû dátum adatot az ember tudná 2000. január 1.-nek értelmezni, a számítógépes rendszerek többsége ezt 1900 január 1-nek tekinti.

Ebbõl az egyszerû ténybõl sok kellemetlen következmény származhat a számítógépes rendszerekben és a közhiedelemmel ellentétben a gondot nemcsak az alkalmazói programok és az adatmezõk jelentik, hanem az operációs rendszerek/firmwarek és a kommunikációs rendszerek is. Az alkalmazások szintjén

• a programok a "00" bemenõ év adatot vagy hibásan 1900-nak tekintik vagy visszautasítják,
• a "00"-val végzett számítások hamis eredményeket adnak (pld 49 éves életkor helyett mínusz 51-et),
• a kimenõ év adatok két helyértéken kerülnek tárolásra, kinyomtatásra és továbbításra más rendszerek felé.

Az adatok helyének megtalálása a programokban igen fáradságos feladat. Ezt súlyosbíthatják a következõ tényezõk:

• a rendszerek dokumentálása szegényes,
• a forráskód nem szabványos,
• a programcsomagokat többször módosították,
• a beszállítók nem támogatják már az adott programcsomagot,
• alacsony szintû programnyelveket használtak,
• a forráskód egyszerûen már nem létezik.

Egyébként az is tévhit, hogy csak a COBOL-ban létrehozott un. "legacy" alkalmazások 2000-es probléma hordozók. A modern programnyelvek közül más C betûvel kezdõdõek, pld. C, C++ sem mentesek a kórtól, a kevésbé elterjedt ADA nyelv viszont kiküszöböli a problémát.

A valóságban a számítógépes alkalmazói program módosítása csak a "jéghegy csúcsa", mert a teljes információ rendszert kell újra integrálni és tesztelni. Miután az alkalmazások módosítása már megtörtént, az év adatot tartalmazó adatmezõket is konvertálni kell négy helyiértékesre. Ez sem könnyû feladat különösen, ha

• nincsenek adatdefiníciók,
• az adatdefiníciók ellentmondásosak,
• a "00"-t más speciális célra (pld "header record" jelzésére) használják,
• a 31/12/99 utáni dátumokat már két helyiértéken letárolták és ezért újra interpretálandók.

Az operációs rendszerek többsége helytelenül kezeli a század váltását és ez vonatkozik a PC-k beépített firmware-jeire (BIOS chip-jeire) és a mainframek operációs rendszereire egyaránt. A problémák körét szélesíti az a meglepõ tény is, hogy sok program nem tudja megfelelõen kezelni a 2000-es évet mint speciális szökõévet (amely ugyan mint minden negyedik év az lenne, de mint a század elsõ éve sokak hite és a konvenciók szerint nem az, de mert negyedik évszázad mégis az). Ki hinné, hogy az elõbbi probléma fõ okozói az Intel bázisú PC-k (tény, hogy a gyártók megkezdték a hibák kijavítását), a szökõévvel pedig olyan közkedvelt szoftvereknek van gondjuk mint a Lotus, Excel és Quatro Pro elsõ verziói (a hitetlenkedõknek a Datamation 1996. január l-ei speciális "Year 2000:Fix it now" c. riportja ajánlható betekintésre).

Végül pedig arra is kell gondolni, hogy a saját rendszerek megfelelõ korrekciója nem mindig oldja meg a problémát, hiszen ha az adatokat olyan együttmûködõ partnerektõl kapjuk pld. on-line kommunikációs kapcsolaton keresztül, amelyek még nem végezték el a módosításokat, a közös rendszer hibásan fog mûködni.

A fentebb említett Datamation riport alcíme a lehetséges következményekre célozva azt állítja, hogy a 2000-es év probléma megoldásának alternatívája csak az üzleti mûködés összeomlása lehet.

II. A következmények

A "milleneumi bomba" a valódiaktól eltérõen nem okoz "látványos" katasztrófákat, hanem "csak"

• a számítógépes rendszerek mûködésének összeomlását (a rendszer nem indul, tranzakciók elutasítódnak, hibásan számított adatok, job-ok nem kerülnek feldolgozásra, stb.),
• a kulcsfontosságú üzleti rendszerek mûködésének összeomlását (megrendelések és számlák nem kerülnek feldolgozásra, kamatok és más kifizetések hibás értékekkel, stb),
• az intézmények mûködésének összeomlását

eredményezheti. Nem igényel különösebb bizonyítást, hogy olyan intézmények, amelyek legfontosabb üzleti alkalmazásaikat hosszabb ideig nem tudják mûködtetni egy számítógépes katasztrófa miatt és nem rendelkeznek megfelelõ "helyreállítási" tervvel, befejezettnek tekinthetik mûködésüket.

A fejlett számítógépes kultúrával rendelkezõ országokban már ma sem ritka olyan alkalmazások müködési zavara a 2000-es váltás miatt, amelyek hosszabb távra (pld. öt évre) elõre terveznek (erre egy példa az Egyesült Államokban a Union Pacific Vasúttársaság, amelynek néhány alkalmazásában már 1995-ben "felütötte fejét a kór"). A Gartner Group becslése szerint már 1996-ban az alkalmazások 20 %-a volt veszélyeztetett, de 1999-ig a hibák kiküszöbölésének elmaradása esetén ez a mutató elérheti a 90 %-ot is.

III. Az idõ és pénz

A milleneumi probléma megoldásának egyik sarkalatos kérdése a határidõ. Szakértõk véleménye és az eddigi tapasztalatok szerint komoly tévedés lenne azt hinni, hogy a hátralévõ három év bõven elegendõ a problémák feltárására és megoldására. A megoldást alapos integrálási és tesztelési szakasznak kell követnie, ami szintén idõigényes. Az informatikai projektek világszerte túllépik a határidõket (egy közzétett statisztika szerint mindössze 14%-uk kivétel ebbõl a szempontból), de ebben az esetben a határidõ érthetõen nem módosítható.

Az adott határidõ szigorúságán kívül nem elhanyagolható tényezõ milleneumi projektek anyagi háttere bizonytalanságának kérdése sem. Belátható, hogy az intézmények felsõ vezetõi igen nehezen gyõzhetõk meg arról, hogy elõzetesen nem tervezett nem látványos és nem produktív projektekhez komoly erõforrásokat kell mozgósítaniuk. Márpedig a bonyolultabb integrált rendszereknél, különösen a tesztelési szakaszban igen komoly és ezért nem olcsó szakértelemre van szükség.

IV. Mi a teendõ

Ebben a fejezetben elsõsorban a CCTA javaslataira alapozva megkíséreljük röviden összefoglalni azokat az általánosan szükséges intézkedéseket, amelyeket egy szervezet szintjén foganatosítani kell a "milleneumi bomba" hatástalanítására (az ITB várható szerepére a kérdés kezelésére a késõbbiekben próbálunk alternatívákat javasolni).

1. A vezetõk (döntéshozók) meggyõzése, szponzor keresése és 2000-es év felelõs menedzser kinevezése

Azoknak a szervezetek és intézményeknek, amelyek még nem kezdtek hozzá milleneumi problémáik felméréséhez, a siker érdekében haladéktalanul lépniük kell. Mindenképen szükség van egy felelõs menedzser kinevezésére, aki tevékenysége elsõ lépéseként akár külsõ vagy már gyakorlatot szerzett társszervezetekkel konzultálva feltárja szervezete milleneumi veszélyeztetettségét és kimutatja a megoldás pénzügyi feltételeit. Ezután meg kell találni az intézményen belül azt a döntéshozó személyt, aki felmérve a prioritásokat képes a szükséges anyagi hátteret biztosítani.

2. Szoftver leltár és vagyon felmérés elkészítése

Az intézmény milleneumi sebezhetõségének kimutatása és a vezetés támogatásának megnyerése után egy magas szintû auditálási tevékenységet kell kezdeményezni a következõ területek vizsgálatára:

• A szervezet információs rendszer vagyonának felmérése annak tisztázásával, hogy melyek a még mûködésben lévõ elemek és ezek milyen beszállítótól származnak (erre a munkára lehet szoftver eszközöket használni),
• A szoftver fejlesztések forrása,
• A programnyelvek, amelyekkel ezeket a szoftvereket készítették,
• A forrásprogram rendelkezésre állása,
• A beszállítók jelenlegi helyzete és készsége a szállított termékeikért való felelõsség vállalásra,
• A hardver platformok és potenciális problémáik,
• A rendszerek interfészeinek száma (beleértve a házon belüli rendszerek közötti és a külsõ kapcsolatokat egyaránt). Minél nagyobb ez a szám annál bonyolultabb a probléma megoldása,
• És a jövõ: Annak megerõsítése, hogy a szervezet nem kíván a jövõben nem "milleneum biztos" rendszereket vásárolni vagy építeni.

3. A rendszerek elemzése és munkaterv meghatározása az idõbeni 2000-es megfelelõség biztosítására

Miután a rendszer vagyon rendelkezésre áll, az intézményeknek tisztázniuk kell:

• Mikor és melyik rendszer fog hibásan mûködni
• Melyik rendszer hibásodik meg elõször
• Melyek a kulcsfontosságú rendszerek
• A rendszerek milyen mértékben dátumfüggõek
• Milyen terjedelmû a rendszer

Annak tisztázására, hogy milyen módon érhetõ el a 2000-es probléma kiküszöbölése és a szervezetek mennyire alkalmasak ezt megvalósítani, fel kell tenni a következõ kérdéseket:

• Rendelkezik-e a szervezet megfelelõ adatszabványokkal
• Állnak-e már rendelkezésre az adatmezõk azonosítására és a kód kijavítására szolgáló szoftver eszközök (ilyen termékek már sorra látnak napvilágot, s típusaikról, mûködésükrõl pld, a Datamation már említett célszáma ad képet) és mûködõképesek-e ezek az adott környezetben
• Rendelkezésre állnak-e megfelelõ pénzügyi, emberi és számítástechnikai erõforrások a probléma megoldására vagy kívülrõl kell ezeket megszerezni

Ebben a fázisban a szervezetek más stratégiát is választhatnak. Célszerû lehet a milleneumi probléma megoldását radikális rendszer változtatásokra felhasználni, de tisztázandó, hogy:

• Megfelelõ-e az idõpont a folyamatok radikális átalakítására
• Át kell-e térni kész programcsomagok alkalmazására
• Szükség van-e az egész rendszerre
• A szervezet tudja-e kezelni az esetleges rendszer összeomlást

Feltétlenül hangsúlyozandó, hogy a radikális változtatások ugyan néhány esetben célravezetõk lehetnek, de a nagy kockázat és a tipikusan csúszó határidõk miatt, a szervezeteknek tisztázniuk kell, hogy képesek lesznek-e az ebben az esetben megváltozhatatlan határidõt tartani.

4. A rendszer kijavításának szigorúan menedzselt programja

• A munka prioritásainak és idõtervének meghatározása.
• A kijavítandó elemek azonosítása.
• A megfelelõ megoldások meghatározása minden rendszerhez.
• Adatkonverziós változtatások elvégzése és áthidaló programok készítése a még nem konvertált alrendszerekhez és rendszerekhez.
• Szigorú konfiguráció menedzsment annak biztosítására, hogy a már kijavított rendszerek ne "fertõzõdjenek" kijavítatlan kóddal vagy adattal.

5. A teljes rendszer modulonkénti majd integrált tesztelése 2000-es környezetben

Megjegyzendõ, hogy a 2000-es környezet biztosítása nem egyszerû feladat, ha nem állnak rendelkezésre megfelelõ termékek és nehézséget okozhat a 2000-es és azon túli dátumok szimulációja is.

6. A kijavított rendszerek határidõn belüli implementációja

A milleneumi megfeleltetés programjának sikere elsõsorban attól függ, hogy milyen gyorsan kezdenek hozzá a projekthez, amely csak hatásos program és projekt menedzsmenttel valósítható meg. A munkát végzõ programozó személyzet megfelelõ ösztönzését a menedzsment nem kerülheti meg, mert a feladat eléggé monoton és unalmas lehet, de teljes befejezéséig az embereket mindenképen meg kell tartani.

V. Kormányzati lépések külföldön

Az informatika alkalmazásában élenjáró országokban, elsõsorban az Egyesült Államokban, de Kanadában és az Egyesült Királyságban is már hosszabb múltra tekint vissza a "milleneumi bomba" hatástalanításának ügye. Ebben a fejezetben röviden áttekintjük, hogy ezekben az országokban elsõsorban kormányzati szinten eddig milyen lépéseket foganatosítottak.

Az Egyesült Államokban az SSA (Social Security Administration) már 1989-ben (!) munkacsoportot alakított a probléma megoldására és 1998 decemberére tervezi óriási méretû szoftver vagyonában az átalakítás befejezését. Nem véletlen, hogy ezen intézmény valamint a GSA (General Services Administration) az OMB (Office of Management and Budget) vezetésével került sor jó néhány fontos kormányzati lépésre a milleneumi probléma kiküszöbölésére. Az OMB 1995-ben létrehozott egy Year 2000 Interagency Committee-t (Tárcaközi Bizottságot) az SSA elnökletével, amely mintegy 40 szövetségi intézmény képviselõjének részvételével havonta ülésezik. A Bizottság eddig az alábbi intézkedéseket tette:

• A probléma tudatosítására a privát szektorral együttmûködve a szövetségi intézmények szakemberei részére megszervezett egy országos szeminárium/munkaülést.
• Szintén a tudatosításra és információ cserére létrehozott egy Internet Year 2000 Information Directory-t tartalmazó WWW home page-et.
• Az OMB kezdeményezésére két memorandumot adott közre a kormányzati intézmények vezetõi és informatikai fõnökei részére, amelyben nyomatékosan felhívják figyelmüket a 2000-es problémára. A memorandumok a témát alapvetõen olyan üzleti stratégiai kérdésként kezelik, amelynek elsõsorban informatikai és szerzõdéstechnikai vonzata van.
• A Bizottság kifejlesztetett egy ajánlott szabványosított minta szerzõdés nyelvezetet, amely a kormányzati informatikai beszerzéseknél figyelembe veszi a 2000-es megfelelõség követelményét.

Az utóbbi idõben a téma a politikusok érdeklõdését sem kerülte el és a kongresszusban több képviselõ is megkérdõjelezte OMB kezdeményezéseinek hatásosságát a szükséges pénzügyi hátteret is hiányolva.

Kanadában a 2000-es kérdéskört kormányzati szinten 1994-ben vetették fel elõször, de 27 intézmény megszondázása után nem alakult ki olyan mértékû veszélyérzet mint napjainkra. 1996 elején viszont a kormányzati informatika ottani koordinációs szervezete a TBS (Treasury Board Secretariat) létrehozta a Year 2000 Project Office-t és megalakult déli szomszédjukhoz hasonlóan a Year 2000 Interdepartemental Working Group is az intézmények képviselõibõl. A Bizottság havonta összehívott ülésein speciális szakértõi véleményeket hallgatnak meg, és fõleg információt cserélnek 2000-es módszertanokról, automatikus szoftver eszközökrõl és az egyedi gyakorlati tapasztalatokról.

1996 májusában a TBS Titkára mintegy 80 intézmény felelõs vezetõit levélben kereste meg kifejezve aggodalmát a 2000-es év gondjai miatt, arra kérve kollégáit, hogy tekintsék át a következõ kérdéseket:

• Hogyan tervezik a probléma megoldását
• Rendszereik teljes átalakításához milyen mértékû pénzügyi fedezet szükséges
• Figyelembe véve a téma esetlegesen tárcákon túlmutató jellegét valamint felkészültségüket a probléma megoldására, szükségesnek tartanak-e egy összkormányzati kezdeményezést

Tanulságos anyagot szolgáltatnak a kérdéssel kapcsolatban azok a válaszlevelek is, amelyeket három független konzultáns cég, a Coopers Lybrand, az LGS valamint DMR Group Inc. küldött John Oakes, a TBS Year 2000 Projekt Irodája speciális tanácsadójának kérésére.

A hozzánk földrajzilag, méretben (de nem az informatika fejlettségében) közelebb álló Egyesült Királyságban Robin Guenier, a CCTA elõzõ igazgatójának vezetésével Brit Kormányzati kezdeményezésre jött létre a 2000 Taskforce. A kormányzati körök érdeklõdését a téma iránt mutatja az, hogy a Taskforce Year 2000 tavaly októberi konferenciájának megnyitó beszédét Ian Taylor, Tudomány-és Technológiaügyi miniszter tartotta. A CCTA, a Computing Services Software Association, a Brit Kereskedelmi-és Ipari Minisztérium valamint a PA Consulting Group részletes átfogó anyagokat bocsátott közre a problémakör kezelésére.

(Megjegyzendõ, hogy Európában a milleneumi átalakítás nem az egyetlen komoly változtatás, amely az informatikai rendszereket érinti 1999 végéig, hiszen a közös valuta bevezetését is erre az évre tervezik.)

VI. És hogyan lépjünk mi

Az elõzõkben ismertetett tények, megközelítések és adatok közreadásának nem az volt a célja, hogy az itthoni helyzetet illetõen pánikot keltsen. Tisztában vagyunk azzal is, hogy a forrásként használt közlemények egy részét esetleg üzleti érdek befolyásolta (konzultáns cégek véleménye, a speciális szoftverek kidolgozására szakosodó cégek lobbi érdekei) és pld. az Egyesült Államokban, ahonnan forrás anyagaink jelentõs része származik, hajlamosak egy-egy divatos téma túlzott "felfújására". Azt sem titkoljuk, hogy vannak szkeptikusabb vélemények is a probléma mértékét és finanszírozhatóságát illetõen. Például az International Data Corp., amelynek nem fûzõdik anyagi érdeke a túlzott veszélyérzet keltéséhez, 100 amerikai informatikai és pénzügyi vezetõ véleményének kikérése után sokkal optimistább adatokat tett közzé a témáról ("Most companies are ready for year 2000 says IDC survey").

Már a bevezetõben is említetést nyert, hogy a hazai informatikai helyzet miatt a probléma mértéke nyilvánvalóan nem mérhetõ össze a példaként ismertetett országokéval. Ezt, a rendszerek viszonylagos "fiatalságán" kívül, még az a tény is alátámasztja, hogy sajnos ezek összekapcsolása sem éri el a fejlett informatikai kultúrával rendelkezõ országok szintjét. Márpedig a milleneumi átalakítás egyik "hektikus" területe éppen az ilyen rendszerek átalakítása és tesztelése. Mindezek ellenére szükségét érezzük egy átfogó felmérésnek a tárcák és alárendelt szervezeteik informatikai vagyonáról és a programok milleneumi veszélyeztetettségérõl ahhoz, hogy eldönthetõ legyen a kormányzati (ITB) szerepvállalás mértéke és mikéntje és hogy indokolt-e a "sense of urgency" vagyis a sürgõsség érzetének keltése kormányzati informatikában.

Elsõ lépésként, mintegy megelõzõ felmérésként a tárcák képviselõinek véleményezniük kell, hogy ezen anyag felvetései és eddigi esetleges tapasztalataik alapján milyen mértékûnek ítélik intézményeiknél és alárendelt szervezeteiknél a 2000-es veszélyeztetettséget. Az ITB titkára 1996. dec. 16-án kelt levelében a stratégiai tervek aktualizálásáról a Bizottság tagjainak már javaslatot tett arra, hogy beküldendõ anyagaikban foglalkozzanak a 2000-es problémák azonosításával és a megoldásukra tervezett lépésekkel. A beküldött vélemények és tervek alapján kell az ITB-nek - esetleg külsõ szakértõk bevonásával - dönteni a követendõ 2000-es stratégiát illetõen.

Ez a stratégia a vezetés szintjét és a beavatkozás módját illetõen háromféle megközelítésben képzelhetõ el:

1. Status Quo: A tárcák saját problémája

Jellemzõi:

• ITB (IKI) passzív vezetés, tárcák között csak tapasztalatcsere, helyzet jelentés.
• Felelõsség a tárcáké, ad hoc független megoldások. Intézkedések:
• Tudatosítás (mint a jelen anyag, szeminárium, stb).
• A tapasztalatcsere elõsegítése (intézményesítése).

2. Horizontális probléma kezelés

Jellemzõi:

• ITB (IKI) aktív stratégiai vezetése, a stratégiai tervek kötelezõ fejezete.
• Az ITB tagok (tárca felelõsök) rendszeres beszámoltatása.
• Költségek biztosítása (mint a stratégiai projektekre). Intézkedések:
• Ajánlás(ok) kiadása a közös megoldásokra és módszerekre.
• A kritikus kormányzati rendszerek menedzselése és elszámoltatása.
• Párhuzamos megoldások kiküszöböltetése aktív információ cserével.
• Esetleges tárcaközi munkacsoportok közös megoldásoknál és ezek finanszírozása.

3. Kormányzati szintû stratégiai megközelítés

Jellemzõi:

• Politikai vezetés és elszámoltathatóság.
• Központi projekt kezelés, kormányzati felelõsség.
• Elõírt stratégia szerinti implementációk, szigorú tárca beszámoltatás.
• Az IVSZ intézményesített bevonása a projektbe.

Intézkedések:

• Kormányzati "Task Force".
• Központi elszámoltatás és ellenõrzés.
• Összkormányzati kockázat felmérés és javítási módszertanok.
• Stratégiai döntések a kulcsfontosságú kormányzati rendszerekrõl.

Természetesen a határok a három változat között nem feltétlenül ilyen szigorúak és a választott megoldás tartalmazhat elemeket mind a három megközelítésbõl. Míg a 3. változat viszonyaink között nem tûnik reálisnak, a 2. változat (vagy elemeinek többsége az 1.-el kombinálva) lehet a választott alternatíva.

Budapest, 1997. január 15.
Összeállította: Szigeti András