Az elmúlt években volt szerencsém tanácsadóként részt venni közművállalatok SAP rendszereinek bevezetésében és így az adatok SAP-ba történő migrálásában, illetve az állami közművállalat összevonásoknak köszönhetően, a migrálandó adatok SAP-ból történő letöltéséhez szükséges programok kialakításában

Minden cég életében óriási lépés, amikor lecseréli a vállalatirányítási rendszerét. A projekteknek pedig érzékeny és fontos része a migráció, amikor a régi rendszerből az adatokat át kell vinni az új rendszerbe úgy, hogy azok illeszkedjenek az új vállalatirányítási rendszerben kialakított eltérő adatstruktúrához és folyamatokhoz.

A projekt első fontos lépése a migráció szempontjából, hogy meghatározzuk az éles átállás módját. Ütemezetten kívánjuk végrehajtani az átállást hónapról hónapra több részletben, vagy egy lépéses migrációt tervezünk.

Ütemezett migráció esetén lehetőségünk van az ügyfeleket és a hozzájuk tartozó adatok átvitelét az elszámoló számlázáshoz igazítani. Így minden hónapban azok a fogyasztási helyek kerülnek át az új rendszerbe, akiknek az adott hónapban van a leolvasásuk és az elszámoló számlázásuk. Így elkerülhetjük a tömeges mérőállás becslés alapján történő elszámoló számlázást és így az új rendszerben a becslés tévedéséből adódó nagyszámú számlahelyesbítést. Ez az előny viszont eltörpül amellett a hátrány mellett, hogy így az átállás időszaka alatt az ügyintézőknek két rendszerben kell dolgozniuk. Ha történik egy törvényi változás az időszakban, azt egyszerre két rendszerben kell megvalósítani. Illetve a migráció esetén is figyelni kell arra, hogy ha egy ügyfélnek több fogyasztási helye is van és ezeknek eltérő hónapra esik a leolvasásuk és elszámoló számlázásuk, akkor az első érintett hónapban át kell vinni az ügyfél adatait, viszont a második körben már nem szabad újra átvinni. Az ilyen ügyfeleknél, ha az átállás közben változik valamelyik adatuk, akkor azt mindkét rendszerben módosítani kell. A fentiek alapján egyértelmű, hogy nem javasolt az üzemezett több lépéses migráció.

Egylépéses migráció esetén is választhatunk, hogy egy adott napon elvégezzük az összes ügyfél mérőállás becslését és elszámoló számlázását és az ezt követő naptól kezdődően kerülnek át az új rendszerbe, vagy történeti migrációt választunk és nem becslünk mérőállásokat, hanem minden ügyfelet az utolsó elszámoló számláját követő naptól veszünk át. A fenti két lehetőség közüli választás befolyásolja a migrálandó adatok körét, mert a második opció esetén történeti adatokat kell migrálnunk. Át kell vinnünk az új rendszerbe az utolsó elszámoló számla óta kibocsátott részszámlák adatait, hogy az új rendszerben keletkező elszámoló számla jóvá tudja írni őket, illetve az utolsó elszámoló számla kiállítása és az átállás közötti időszakban történt mérőcseréket és a nem elszámolás releváns mérőállásokat is, hogy az elszámoló számla kiállításához az új rendszerben minden adat meglegyen. Tehát a fenti két esetben a mérőállásbecslésből fakadó számlahelyesbítések állnak szemben a történeti migrációhoz szükséges plusz feladatokkal. Tapasztalataink szerint a történeti adatok migrálása több erőforrást igényel és több költséggel jár, mint a mérőállásbecslésekből fakadó számlahelyesbítések, így az egylépéses migráció mérőállás becsléssel választása javasolt.

Persze bármelyik átállási módot választjuk a történeti migrációt nem tudjuk teljesen elkerülni, hiszen az új rendszerben is szükség lesz az árak teljes visszamenőleges történetére, az átállás előtti időszakra történő manuális számlahelyesbítések miatt.

Az átállás módja mellett fontos kérdés az átállás dátuma is. A migráció időigényes folyamat, így javasolt egy hosszú hétvégés ünnepre időzíteni, amikor amúgy is zárva vannak az ügyfélszolgálatok, mert az adatok letöltése után már nem lehet dolgozni a régi rendszerben, az újban pedig addig nem lehet, amíg meg nem történik a migráció. Egy teljeskörű tesztmigráció esetén érdemes figyelni a betöltés idejét, így az éles betöltésnél már pontosabban lehet tudni, hogy mennyi idő kell majd az éles migrációhoz.

Ha már kiválasztottuk az átállás módját és ismerjük az átadandó adatkört (például csak az átálláskor érvényes szerződéssel rendelkező szerződéseket és a hozzájuk kapcsolódó adatokat szeretnénk átvinni), akkor már meg lehet határozni az adatok migrálásához szükséges objektumokat és az ahhoz szükséges adatokat. Az adatok meghatározásakor – mivel a régi és új rendszer azonosító számai eltérnek – törekedni kell arra, hogy az ügyintézők munkáját segítsük abban, hogy az új rendszerben létrejött azonosítóhoz könnyen be tudják azonosítani a régi rendszerben tartozó azonosítót (például az új rendszer szerződésébe migráljuk át, a régi rendszerben lévő szerződés számot).

Az SAP standard paraméterezhető migrációs eszközt (SAP IS-U Migration Workbench) kínál a közművállalatok számára, mely segítségével összeállítható az egy-egy migrációs objektumhoz szükséges adatok struktúrája, illetve elvégezhető az adatok feltöltése. Az így előállított struktúrákban tudja fogadni az új rendszer az adatokat. Ha olyan adatokat kell nagy mennyiségben átvenni, amihez nincs standard migrációs objektum (például a leolvasások, elszámolások és számlázások ütemezéséhez szükséges ütemezési törzsadatok, a kötegek és leolvasási egységek), akkor a feltöltő programot fejlesztéssel kell előállítani.

A régi rendszerből a meghatározott struktúrákban kell kigyűjteni az adatokat. Ez történhet manuális módon, vagy letöltő programok segítségével. A manuális fájl létrehozás csak olyan esetben javasolt, amikor kevesebb erőforrással megoldható, mint a fejlesztés, illetve elegendő egyszer előállítani a fájlt és nem kell minden migrációs körben újra és újra. Minden más esetben a letöltő programok használata javasolt, mert ha hiba lesz a fájlban, akkor a programban könnyebben visszakereshető a hiba oka. Javítható a hibás rész és a javítás után csak újra kell futtatni a programot, nem kell újra elvégezni a manuális előállítás folyamatát.

Az adatokat javasolt tabulátorral tagolt txt fájlokban átadni. A pontosvesszővel tagolt csv fájlok használata kerülendő, mert például a szöveges megjegyzés mezőkben az ügyintézők használhatnak pontosvesszőt és ez a feltöltéskor hibát okoz, mert a program minden pontosvesszőnél elhatárolja az adott sort és így az adatok elcsúszhatnak.

Minden a migrációhoz szükséges mezőhöz meg kell határoznunk, hogy az oda szükséges adat hogyan állítható elő. Amennyiben fix értéket kell használni egy mezőben (például vállalat kód), akkor ezt nem érdemes belerakni a migrációs fájlokba, hiszen felesleges a fájl minden sorát kitölteni ugyanazzal az értékkel. Az SAP által biztosított migrációs eszközben standard módon beállíthatók a fix értékek.

Amennyiben egy az egyben át kell forgatni egy mező értékét egy másik értékre, akkor megállapodás kérdése, hogy ezt az átforgatást a régi rendszerből letöltéskor, vagy az új rendszerbe feltöltéskor végezzük. Ha a régi rendszerben tesszük meg, akkor a fájlok módosítás nélkül feltölthetőek az új rendszerbe. Viszont, ha egy értéknek hiányzik a párja és emiatt hiányos lesz a fájl, akkor a módosítás után újra le kell futtatni a letöltő programot és a teljes állományt elő kell állítani. Ha az új rendszerben történik az átforgatás, akkor ha hiányzik egy érték párja, a hibás rekord nem kerül betöltésre (amennyiben kötelező mezőről van szó). A hiányzó érték rögzítése után az SAP migrációs eszköze lehetőséget biztosít arra, hogy csak a hibás sorokat dolgozzuk fel újra, így nem kell a teljes állományt újra feltölteni. Bárhol is történjen az átforgatás, javasolt egy beállító táblát létrehozni az érintett rendszeren és ebben tárolni a mezőneveket, illetve a hozzájuk tartozó régi és új értékeket. A programban az ebbe a táblába beállított értékekkel kell elvégezni az átforgatást. Így, ha változnak az értékek, akkor nem szükséges módosítani a programon, elegendő a beállító táblában átírni az értékeket.

Ha egy mező értéke csak bonyolultabb szabályok által határozható meg, akkor a régi rendszerben készülő letöltő programban kell elvégezni az átforgatást, mert ott minden adat az eredeti állapotában rendelkezésre áll. Mivel azonos kulccsal nem lehet több rekordot rögzíteni, ezért az ilyen problémákat is még a letöltő programban kell elhárítani (például, ha máshogy lesznek meghatározva az új rendszerben a készüléktípusok és a régi rendszer több készüléktípusa is az új rendszerben egy készüléktípusba lesz átsorolva, akkor ami a régi rendszerben még egyedi készüléktípus-gyártási szám páros volt, az már az új rendszerben ismétlődő pár lesz). Ha a régi rendszerben mondjuk egy mezőben volt az utca neve és a közterület jellege (például tér, utca, út, stb.), az új rendszerben pedig ezek külön mezőbe kerülnek, vagy fordítva, akkor ezeket az átalakításokat is a letöltő programban kell elvégezni.

Ahhoz, hogy minőségi adatokat tudjuk átvinni az új rendszerbe elengedhetetlen a meglévő rendszerben az adatok tisztítása (például utcanevek elírása miatt Kossuth utca létezik egy és két s-sel is).

A migráció minden lépésében kiemelten fontos az adatok ellenőrzése. Már a letöltő programok által előállított fájlokban ellenőrizni kell, hogy a kötelező mezők töltve vannak-e. Azokban az oszlopokban, ahol egy megadott értékkészletből kell adatokat adni, ott meg kell nézni, hogy csak az értékkészletben szereplő értékekkel van-e sor.

A teszt migráció első köreiben érdemes kisebb adatkörökkel (például egy-egy település) adataival próbálkozni, mert ha a teljes adatkört betöltjük és utána derül ki, hogy hibás volt a betöltés, akkor a rendszert vissza kell állítani a migráció előtti állapotba, hogy újra a teljes adatkörrel próbálkozhassunk.

A sikeres feltöltés sem garancia arra, hogy az adatok teljesen jók. Hiszen attól, hogy egy dátum mezőben dátum van, attól még nem biztos, hogy az a dátum jó. Így elengedhetetlen a bemigrált adatok szúrópróba ellenőrzése az új rendszeren, illetve az új rendszer funkcionális és folyamattesztelése az átmigrált adatokkal.

Az sem mindegy, hogy a teszt migrációk során a migrációs letöltő programokat mikor futtatjuk és milyen rendszerről adjuk az adatokat. Ha lemásoljuk az éles rendszert és utána erről a másolatról adjuk az adatokat, akkor bármikor lehet adatot szolgáltatni. Viszont ebben az esetben az adathibákat az éles és a másolt rendszeren is javítani kell párhuzamosan, vagy az élesen történt javítás után újabb másolatot kell készíteni. Lehetőség van a teszt migráció számára is az éles rendszerről adni az adatokat, de ez esetben csak munkaidőn kívül lehet futtatni a letöltést, mert még a jól megírt migrációs letöltők is több óráig futhatnak a nagy adatmennyiség miatt és ha közben dolgoznak a rendszeren, változnak az adatok, akkor az inkonzisztenciát okozhat az átadott adatokban (például a program futása közben költöztetnek ki egy ügyfelet, vagy cserélnek le egy mérőt).

Természetesen egy blog keretében nem lehet kitérni egy migrációval kapcsolatos összes problémára és döntési helyzetre, de remélem, hogy így is sok hasznos információt oszthattam meg Önökkel. Amennyiben az Ön cége a jövőben tervezi lecserélni a vállalatírányítási rendszerét SAP-ra, vegyék fel a kapcsolatot cégünkkel. Évtizedes tapasztalattal rendelkező tanácsadóink támogatásával a migráció gördülékenyen végrehajtható, a tervezéstől az adatok új rendszerbe történő betöltéséig.