leírás u alapú ügyfélszolgálati rendszer megvalósítása ...±szaki leírás.pdfrendszer...

Műszaki leírás a

Regionális víziközművek integrációját célzó, egységes ügyfélszolgálati folyamatok mentén egységes SAP IS-U alapú ügyfélszolgálati rendszer megvalósítása a KOMP2

program keretében tárgyában kiírt közbeszerzési eljáráshoz

2

Tartalom 1. HÁTTÉR .................................................................................................................. 3

1.1 ELŐZMÉNYEK .................................................................................................. 3 1.2 ÜZLETI CÉLKITŰZÉSEK ................................................................................... 3 1.3 JELENLEGI HELYZET ÖSSZEFOGLALÓ BEMUTATÁSA ..................................... 3 1.4 MEGVALÓSÍTANDÓ MODELL, BEVEZETÉSI MEGKÖZELÍTÉS ........................... 6

2. VÁLLALKOZÓ FELADATA ............................................................................................... 8 3. SZÁLLÍTANDÓ TERMÉKEK .......................................................................................... 11 4. FOGYASZTÓI TÖRZSADATOK ....................................................................................... 13

4.1 TÁMOGATANDÓ FŐ FOLYAMATOK ................................................................. 13 5. LEOLVASÁS, ÜTEMEZÉS ............................................................................................. 13

5.1 TÁMOGATANDÓ FŐ FOLYAMATOK ................................................................. 13 5.2 KIALAKÍTANDÓ FUNKCIONALITÁS ................................................................. 14 5.3 RENDSZER KAPCSOLATOK ............................................................................ 15 5.4 FELTÉTELEZÉSEK, KIZÁRÁSOK ..................................................................... 15

6. ELSZÁMOLÁS, SZÁMLÁZÁS ................................................................................... 16 6.1 TÁMOGATANDÓ FŐ FOLYAMATOK ................................................................. 16 6.2 KIALAKÍTANDÓ FUNKCIONALITÁS ................................................................. 16 6.3 RENDSZER KAPCSOLATOK ............................................................................ 18 6.4 FELTÉTELEZÉSEK, KIZÁRÁSOK ..................................................................... 19

7. FOLYÓSZÁMLAKEZELÉS ............................................................................................. 19 7.1 TÁMOGATANDÓ FŐ FOLYAMATOK ................................................................. 19 7.2 KIALAKÍTANDÓ FUNKCIONALITÁS ................................................................. 20 7.3 FELTÉTELEZÉSEK, KIZÁRÁSOK ..................................................................... 22

8. ÜGYFÉLSZOLGÁLAT ............................................................................................. 22 8.1 TÁMOGATANDÓ FŐ FOLYAMATOK ................................................................. 22 8.2 KIALAKÍTANDÓ FUNKCIONALITÁS ................................................................. 23 8.3 RENDSZER KAPCSOLATOK ............................................................................ 24 8.4 FELTÉTELEZÉSEK, KIZÁRÁSOK ..................................................................... 25

9. KAPCSOLÓDÓ CENTRALIZÁLANDÓ RENDSZEREK ....................................................... 25 9.1 CALL CENTER ................................................................................................ 25 9.2 ONLINE ÜGYFÉLSZOLGÁLAT ......................................................................... 26 9.3 DOKUMENTUM MENEDZSMENT ..................................................................... 26 9.4 OUTPUT ÉS NYOMTATÁS MENEDZSMENT ..................................................... 27

10. MÉRŐKEZELÉS..................................................................................................... 28 10.1 TÁMOGATANDÓ FŐ FOLYAMATOK ................................................................. 28 10.2 KIALAKÍTANDÓ FUNKCIONALITÁS ................................................................. 30

11. MŰSZAKI FOLYAMATOK TÁMOGATÁSA ........................................................................ 31 11.1 TÁMOGATANDÓ FŐ FOLYAMATOK ................................................................. 31 11.2 KIALAKÍTANDÓ FUNKCIONALITÁS ................................................................. 33 11.3 FELTÉTELEZÉSEK, KIZÁRÁSOK ..................................................................... 34

12. MIGRÁCIÓ ............................................................................................................ 35 12.1 MIGRÁLANDÓ ADATOK KÖRE ........................................................................ 35 12.2 MIGRÁCIÓS MÓDSZERTAN ............................................................................ 36 12.3 FELTÉTELEZÉSEK, KIZÁRÁSOK ..................................................................... 37

13. ÜTEMEZÉS ........................................................................................................... 38

3

1. HÁTTÉR

1.1 ELŐZMÉNYEK Az MNV Zrt. a KOMP2 programot azzal a céllal indította, hogy megvalósuljon a tulajdonában lévő közlekedési központok és vízi közmű központok működési és informatikai integrációja és a lehető legtöbb szinergia kihasználásával és a folyamatok egységesítésével legyen hatékonyabb és kontrollálhatóbb a társaságok működése. A NÜSZ Zrt.-nek a Vállalkozóval érvényes szerződése van a közlekedési központok és a vízi közmű központok ERP rendszereinek kialakítására több szakaszban. A KOMP2 program az MNV Zrt. Igazgatóságának 2016. december 21-i döntése alapján kibővül a Vízi Közmű ügyfélszolgálati és kapcsolódó – jelen dokumentumban bemutatott – más rendszerek integrációjára is, amelyre Vállalkozó elkészíti az integrált Részletes Tervet is. Jelen felhívás tárgya az integrált Részletes Tervben szereplő az eredeti Vízi Közmű terjedelemtől eltérő illetve módosuló – jelen műszaki mellékletben rögzített – terjedelem megvalósítása.

1.2 ÜZLETI CÉLKITŰZÉSEK

Az MNV Zrt. mint a Vízi Közművek tulajdonosa az alábbi célkitűzések teljesülésének érdekében centralizálja a Vízi Közművek informatikai és üzleti működését:

• Egységes elszámolási és pénzügyi beszámoló rendszer, egységes folyamatok. • Tulajdonos számára transzparensebb és könnyebben kontrollálható működés. • Szinergiák kihasználása az ügyfélszolgálat esetében és a kapcsolódó területeken (call-

center, dokumentumkezelés, back office). • Jelentős megtakarítási és hatékonyságjavítási lehetőségek folyamat racionalizálás,

infrastrukturálisan és emberi erőforrás tekintetében.

1.3 JELENLEGI HELYZET ÖSSZEFOGLALÓ BEMUTATÁSA

1.3.1 A BEVEZETÉSBEN ÉRINTETT TÁRSASÁGOK A centrális vízi közmű rendszer bevezetést az alábbi Társaságokra kell elvégezni, az alábbi kiindulási rendszerekből a megadott szakmai végállapotokra:

• DMRV (jelenleg SAP IS-U -> közmű template rendszerre való áttérés) • ÉDV (jelenleg SAP IS-U -> migráció és közmű template rendszer alapján

történő működés) • DRV (jelenleg SAP IS-U -> migráció és közmű template rendszer alapján

történő működés) • TRV (jelenleg Libra Szumma -> migráció és közmű template rendszer alapján történő

működés) • ÉRV (jelenleg Libra Szumma -> migráció és közmű template rendszer alapján

történő működés)

4

Az érintett társaságok nagysága az alábbi kulcs fogyasztói adatokkal jellemezhető:

1.3.2 DECENTRALIZÁLTAN MŰKÖDŐ ARCHITEKTÚRA A Vízi Közművek jelenleg teljesen decentralizált módon, egymástól függetlenül, párhuzamosan működtetett, eltérő rendszerkörnyezetekben végzik a tevékenységüket.

TRV

TRV

TRV

5

1.3.3 JELENLEGI KÖZMŰ SPECIFIKUS FUNKCIONÁLIS MODELL

Az alábbi táblázat a vízi közművek közmű specifikus működéséhez tartozó ICT architektúra jellemzőit tartalmazza:

1.3.4 JELENLEGI MŰSZAKI RENDSZER SPECIFIKUS FUNKCIONÁLIS MODELL

Az alábbi ábra a vízi közművek műszaki rendszereinek átfogó architektúra modelljét tartalmazza:

Alcatel

Rudas& Karig

TRV

6

1.4 MEGVALÓSÍTANDÓ MODELL, BEVEZETÉSI MEGKÖZELÍTÉS

A Vállalkozó feladata, hogy a jelen fejezetben bemutatott architektúrát - beleértve a ’Centrális SAP IS-U funkciók’-at és a ’Centrális nem SAP rendszereket’ – megvalósítsa a Részletes terv alapján. Vállalkozó a rendszer működőképességének és a hatékony folyamat kiszolgálás érdekében a NÜSZ Zrt. előzetes jóváhagyását követően a Részletes Terven pontosításokat, bővítéseket hajthat végre.

1.4.1 ELVÁRT MÓDSZERTANI MEGKÖZELÍTÉS A Vállalkozó felé elvárás, hogy egységesen valósítsa meg a Vízi Közművek rendszereit a jelen dokumentumban rögzítettek szerint. Ehhez kiindulásként el kell készítenie a DMRV rendszerén alapulva az ún. template (sablon) modellt. A sablonnak tartalmaznia kell mindazon beállításokat, programokat és egyéb működési elemet, amelyek a központi megoldás részei és ezeket egységesen kell minden Víziközmű Társaságra leképezni. Csak a template elkészültét és NÜSZ Zrt. általi elfogadását követően lehet az egyes társaságspecifikus leképzéseket végrehajtani. A leképzés első lépése a DMRV rendszer átalakítása a template-nek megfelelően. Mivel a template működésre történő átállás folyamati átalakítással, működési változással és belső adatkonverzióval/remigrációval is járhat, az áttérés tervezése és irányítása a Vállalkozó feladata. A további Társaságok esetén a template rendszer bevezetése a feladat a Részletes tervben szereplő, illetve az implementáció során feltárt indokolt eltérésekkel. Vállalkozó köteles a Részletes Tervtől eltérő megvalósítási gap-et (eltérést) dokumentálni és indokolni, és azt csak a NÜSZ Zrt. általi elfogadás után implementálhatja társaság specifikusan a rendszerben. Vállalkozó feladata és felelőssége, hogy a rendszerbeli funkcionalitás működőképes legyen az éles indulásra, a belső SAP integrációk működjenek. Jelen szerződésben rögzített terjedelmet mindaddig nem adhatja át a Vállalkozó, míg saját tesztelési dokumentációval nem bizonyítja az általa fejlesztett rendszereken belüli és azok közötti integrált működőképességet. Vállalkozó az integrációs tesztelési szakaszban köteles harmadik felekkel együttműködni, hogy a Részletes Tervben szereplő interfacek működőképességét az általa kialakított rendszerek oldaláról biztosítani tudja.

7

1.4.2 TERVEZETT KÖZMŰ SPECIFIKUS FUNKCIONÁLIS MODELL Az egységes törvényi, rendeleti háttérnek megfelelően elkészült egy jövőbemutató centrális közmű rendszert tartalmazó architektúra modell, amit az alábbi ábra szemléltet, és amelynek piros illetve sárga színnel jelölt ’Centrális SAP IS-U funkciók’ és ’Centrális nem SAP rendszerek’ elemeit kell a Vállalkozónak szállítania:

A Központosított közmű modell (továbbiakban: KKM) – amely a ’Centrális SAP IS-U funkciókból’ és a ’Centrális nem SAP rendszerekből’ áll – az alábbi fő elemeket tartalmazza:

• Központosított IS-U, • Központosított Call Center, • Központosított Online Ügyfélszolgálat, • Központosított dokumentum kezelés, • Központosított Díjnet, Bank és PEK kapcsolat.

1.4.3 TERVEZETT MŰSZAKI RENDSZER SPECIFIKUS FUNKCIONÁLIS MODELL

Mivel a műszaki adatstruktúrák, rendszerek és folyamatok jelentősen eltérnek, így a műszaki rendszerek teljeskörű centralizációja nem valósul meg a jelen megbízással párhuzamosan. A jelen megvalósítási terjedelem nem terjed ki egységes műszaki rendszer kialakításra, viszont kiterjed az SAP és a műszaki rendszerek kapcsolatának részleges egységesítésére. A SAP rendszert használó Társaságok jól működő műszaki rendszerei egyelőre megmaradnak, azok centrális SAP rendszerhez illesztésének részleges egységesítése feladat.

DRV ÉRV TRV

8

2. VÁLLALKOZÓ FELADATA Vállalkozó feladata, hogy az előző fejezetben bemutatott koncepció szerint a következő fejezetekben bemutatott funkcionalitásnak és a Részletes Tervnek megfelelő rendszert szállítson az alábbi feladatok elvégzésével:

Me gvalósítás

A megvalósítási fázisban a következő tevékenységeket kell a Vállalkozónak elvégezni: A KKM Rendszerek Részletes Tervnek megfelelő beállítása; A Részletes Terv szerinti Programfejlesztés – beleértve a KKM-beli SAP és

nem-SAP rendszerekben bővítések, interfészek, riportok, workflow-k, migrációs eszközök fejlesztését;

A társaságok jelenlegi megoldásainak a template rendszerbe történő beépítése során a Vállalkozó feladata ezen megoldások lefejlesztése az integrált rendszerben.

Rendszerintegráció végrehajtása: Interfészek esetében a kiindulási ponttól a felhasználási pontig terjedő minden interfészt Vállalkozó készít, függetlenül az interfészek kiindulási pontjától és érkezési pontjától; kivéve azon interfészek esetén a másik rendszer oldali részt, ahol a Részletes Tervben jelölve van, hogy az interfész másik rendszerhez kapcsolódását 3. fél fejleszti. Vállalkozó felelős tehát a KKM-en belüli teljes és a külső integrációk esetén a KKM oldali rendszerintegrációért.

SAP rendszer bázis környezetének finomhangolására vonatkozó terv elkészítéséhez javaslat készítése, szükség esetén bázis szintű finomhangolás támogatása, architektúra tervezés támogatása. (Nem része a feladatnak az infrastruktúra, operációs rendszer és adatbázis szintű finomhangolás.)

A kapcsolódó centrális rendszerek alkalmazás környezetének teljes körű kialakítása és rendszerbeállítása, dokumentálása, architektúra ábrák készítése. (Nem részei a feladatnak az infrastruktúra, operációs rendszer és adatbázis szintű tevékenységek ellátása.)

Rendszer fejlesztői tesztelése és ennek dokumentálása (unit tesztek), melyben a fejlesztők és funkcionális tanácsadók a tesztkörnyezetben megvizsgálják, hogy az érintett funkciók maradéktalanul végrehajthatóak-e rendszerhiba nélkül;

Jogosultsági objektumok meghatározása a jogosultsági koncepcióhoz,; Megrendelő támogatása a jogosultságok meghatározásakor és beállításakor.

Tesztelési terv – beleértve a tesztelési stratégiát, tesztelési típusokat és azok végrehajtási módszertanát, a tesztesetek felsorolását - elkészítése, amely a követhető, a rendszer minden elemére kiterjedő tesztelés alapvető feltétele;

Migráció tervezése (minden ki oldali és be oldali migráció), migrálandó adatkörök előkészítését is beleértve;

Az adott funkciókhoz szükséges automatizált jobok dokumentálása és beállítása minden rendszerkörnyezetben.

Oktatás megtervezése. A szakasz eredményeként előáll a Részletes terveknek megfelelő, Vállalkozó által letesztelt KKM rendszer.

9

Kul csfe lhasználói oktatás

Az átadási fázisonként, a tesztelés megkezdése előtt a Vállalkozó az átadott funkcionalitás tekintetében átfogó kulcsfelhasználói oktatást tart. A kulcsfelhasználói oktatások témajegyzékét a projektvezetők közösen határozzák meg. A kulcsfelhasználói oktatáshoz a Vállalkozó oktatási anyagot készít képernyőkkel, részletes szöveges leírással. A Vállalkozó feladata továbbá felhasználói kézikönyvek készítése word formátumban. A kulcsfelhasználói képzéshez az oktatás technikai körülményeit a NÜSZ Zrt. biztosítja.

Te sztelé s

A tesztelési fázisban – a Tesztelési terv alapján – az alábbi teszt típusokat kell elvégezni: Funkcionális teszt: Ez minősül a rendszer első hivatalos tesztjének, melynek

során a NÜSZ és a Vízi Közmű társaságok részéről delegált korlátozott számú tag (tesztelő) részleteiben is megvizsgálja, hogy a tesztelésre kijelölt funkciók minden szempontból és teljes körűen a teszttervekben rögzített elvárásoknak megfelelően működnek-e. A jogosultságok és interfészek tesztelése nem képezik a funkcionális teszt részét. A funkcionális teszt biztosítja, hogy a Részletes tervben szereplő valamennyi funkció elvégezhető, illetve funkcionálisan jól, az elvárásoknak megfelelően működik.

Interfészek tesztje: Az interfészek tesztje a rendszerek közötti megfelelő adatáramlást vizsgálja.

Folyamat/integrációs teszt: A folyamatteszt célja a korábban tesztelt funkciók láncainak tesztelése, amelynek során a hangsúly a folyamatok végrehajthatóságán van. A folyamatok tesztelését a teszt rendszerekben kell elvégezni folyamatverziónként elkészített tesztlapok mentén. A folyamattesztet követő integrációs teszt célja pedig annak bizonyítása, hogy

a rendszer modulok közötti kommunikációja és adatáramlása megfelelő;

a szükséges hatások és reakciók megtörténnek, azaz teljesülnek az integrált rendszerrel szembeni funkcionális elvárások;

az SAP IS-U, ERP egyes moduljai és a kapcsolódó Vállalkozó által átadott centrális rendszerek és harmadik szállító rendszerei integráltan, a funkcionális specifikációkban, valamint a folyamat- és funkcióleírásokban definiált módon működnek.

Migrációs teszt: Migrációs eszközök tesztje Teszt migráció: A törzsadatok, nyitóadatok teszt betöltése az elkészített

migrációs eszközök segítségével. Jogosultságok tesztje: A felhasználói jogosultságok sikeres tesztelése az SAP

rendszerben tárolt adatokhoz való szabályozott hozzáférés működőképességét bizonyítja. A folyamatokat a jogosultsági tervben meghatározott jogosultságokkal kell tesztelni.

Teljesítmény teszt (terheléses teszt): a rendszer nagy tömegű felhasználói tesztelése az éles üzemi várható terhelésnek megfelelő vagy azt kismértékben meghaladó terheléssel. Az SAP rendszerek teljesítménytesztjéhez gépi tesztelő eszköz nem kerül használatra. A teljesítményteszt az alábbi elemekből áll:

NÜSZ és a Vállalkozó által közösen meghatározott futásidő-kritikus elemekre futási sebességtesztet hajt végre a Vállalkozó. Az eredmények MVMI-vel és NÜSZ-szel közös kiértékelése után esetlegesen az MVMI a báziskörnyezeten, a Vállalkozó az alkalmazásrétegben teljesítményjavítást végez.

10

NÜSZ által szervezett, sok felhasználót bevonó, pár óra folyamatos működést szimuláló és háttérben ütemezett „job”-okat is futtató szimulációs teljesítményteszt. A teljesítményteszt eredményei alapján esetlegesen az MVMI a báziskörnyezeten, a Vállalkozó az alkalmazásrétegben teljesítményjavítást végez.

Nyomtatási és egyéb infrastruktúra tesztek: a rendszerből üzemszerűen nyomtatandó dokumentumok tesztelése, nyomtatók ellenőrzése, sablonok, formátumok és adattartalom megfelelőségének ellenőrzése, kiemelten az Társaság oldali nyomtatások esetében.

Átvételi teszt: a rendszer teljes elkészültét bizonyító átfogó felhasználói teszt az élesítési üzemi előkészítést közvetlenül megelőzően.

A Vállalkozó feladata a funkcionális (unit) tesztek elvégzése a megrendelői tesztelésre átadást megelőzően, a Vállalkozó által leszállított fejlesztésekre és beállításokra vonatkozóan. Vállalkozó a fenti megrendelői teszteket támogatja. A tesztelési tervben kell bemutatni, hogy mely fenti teszt mely környezetben kerül végrehajtásra. (Fejlesztői, teszt, vagy minőségbiztosítási, esetlegesen indokolt esetben további, az adott tesztelés céljából létrehozott speciális tesztkörnyezetben.) A tesztelések során az SAP Solution Manager használata nem előírás. A jelen leírásban kifejezetten nem NÜSZ által végzett tesztelésként jelölt teszteléseket a Vállalkozó végzi. A NÜSZ által végzett teszteléseket a Vállalkozó mind módszertanilag, mind SAP szakmailag támogatja, módszertani javaslatokkal, szükség esetén pontosító kérdésekkel segíti a hibák szakmailag adekvát dokumentálását; a Vállalkozó a hibák kijavításáért felelős olyan válaszidővel, hogy az az adott tesztelési típus határidőre történő befejezését lehetővé tegye. A hibajavításokat követően a Vállalkozó javaslatot tesz az újratesztelés módjára és terjedelmére, amennyiben az eltér a normál tesztelési feladat végrehajtásától. A Vállalkozó a vizsgálata szerint nem neki felróható hibákat szakszerű megfogalmazással maga továbbítja az illetékesek felé (pl. SAP gyári hiba esetén SAP AG felé és kezeli teljes életútban a végleges megoldásig; az infrastruktúrákból, hálózati problémákból, ESB működésből eredő vagy itt nem nevesített, de MVMI szolgáltatási köréből adódó hibák esetén MVMI felé).

Éle s üzem e lőkészítése é s éles indítás

Az éles üzem előkészítésének egyik kiemelt feladata a végfelhasználói oktatások lebonyolítása. A projekt keretében a kulcsfelhasználók (Társaságok és NÜSZ) képzése a Vállalkozó feladata. A végfelhasználók teljes körű - a kapcsolódó folyamatokkal, eljárásrenddel kiegészített, SAP rendszer használatát bemutató és gyakorló - végfelhasználói oktatását a Társaságoknál a Társasági kulcsfelhasználók, a NÜSZ-nél a NÜSZ kulcsfelhasználók végzik. Az oktatások lebonyolítását a Vállalkozó által készített Oktatási Terv alapján kell elvégezni. Az éles üzem előkészítésének másik kiemelt feladata az integrált átállási terv előállítása és elfogadása valamennyi szereplővel. Az integrált átállási tervet a Vállalkozó készíti, a NÜSZ az üzleti átállással kapcsolatos inputokat szolgáltatja. Az átállási terv alapján az átállási feladatokat a tervben meghatározott felelősök menedzselik, a Vállalkozó átfogó koordinációja mellett. Az éles üzem indításának célja a rendszerek produktív használatba vétele és a szolgáltatások elindítása. Végrehajtásra kerül a törzs és nyitóadat továbbá a tervben rögzített esetekben előzmény (történeti) adat migrációja. A migrációban a Vállalkozó feladatait külön fejezet mutatja be.

11

Az éles üzem indításának további kulcs Vállalkozói feladatai: Az indulás során felmerülő esetleges KKM rendszerproblémák dokumentált

megoldása. Interfészek működésének átállítása az új rendszerhez az SAP és a szállított

centrális rendszerek oldalán, majd ennek ellenőrzése. A minden bevezetni tervezett modulra vonatkozó rendszertámogatási leírást

(üzemeltetési dokumentációt) kell a Vállalkozónak átadnia a NÜSZ Zrt. SFKK szervezete, illetve az MVMI számára.

A szolgáltatás indulásának végső operatív egyeztetése és jegyzőkönyvezése. Az éles indulás utáni kiemelt támogatás Vállalkozó oldali szervezetének

létrehozása és eljárásrendjének kidolgozása a NÜSZ Zrt. és az MVMI által már jelenleg is alkalmazott gyakorlat szerint. A támogatási eljárásrendben rögzíteni kell a hibabejelentés pontos folyamatát, a jogosultságkezelés pontos folyamatát, az MVM Csoport által üzemeltetett help-desk feladatait, a Vállalkozó felé történő hibatovábbítás folyamatát (beleértve eszközeit és csatornáit), továbbá a javított hibák visszajelentésének és ellenőrzésének feladatait.

Kie me lt támogatás

A rendszerek éles indulását követő, kiemelt támogatási időszakokban (30 nap) a teljes rendszerkörnyezetek üzemeltetése az MVMI feladata, intenzív térítésmentes Vállalkozói támogatással. A Vállalkozó tudástranszfert kell, hogy biztosítson üzemeltetői dokumentáció és üzemeltetői oktatás formájában, amelynek célja, hogy a rendszer bevezetése során megszerzett tudás segítségével, annak üzemeltetését és működtetését az MVM Csoport már önállóan tudja végezni.

3. SZÁLLÍTANDÓ TERMÉKEK A Vállalkozónak az alábbi rendszertermékeket kell a jelen dokumentációban és a Részletes tervnek megfelelően szállítania:

• ’Centrális SAP IS-U funkciók’ • ’Centrális nem SAP rendszerek’:

o Központosított Call Center, o Központosított Online Ügyfélszolgálat, o Központosított dokumentum kezelés, o Központosított Díjnet, Bank és PEK kapcsolat.

• A fenti rendszerek egymás közötti interface kapcsolatai • A fenti rendszerek kapcsolatai az SAP ERP rendszerhez • A korábbiakban ismertettet Műszaki rendszerekkel való kapcsolatok

kialakítása, a leolvasási és mérőkezelési feladatok működőképességének biztosítása

• A fenti rendszerek belső adatkapcsolatai és interface-i, továbbá a fenti rendszerek oldali interfacek a tervben szereplő harmadik rendszerek felé

• Archiválási rendszerkapcsolatok • Migrációs betöltő programok

A Vállalkozó szállítási terjedelme: (1) fent felsorolt rendszertermékek átadása (2) az alább részletezett dokumentációkkal történő szállítása és a

12

(3) 2. fejezetben bemutatott Vállalkozói feladatok elvégzése. A szállítás terjedelmét nem képezi: (1) hardverek, operációs rendszer, adatbázis kezelők, továbbá (2) alkalmazás licenszek szállítása, ezekre vonatkozó méretezési, típus, mennyiségi információkat a Vállalkozónak azonban biztosítania kell az MVMI számára, amely ezek beszerzéséről intézkedik.

A Vállalkozónak az alábbi dokumentumokat kell elkészítenie a template megoldás éles indulásához kapcsolódóan, amelyet a következő fázisokra vonatkozóan aktualizálnia, bővítenie kell:

• Migrációs koncepció és terv • Jogosultsági tervhez, jogosultsági objektum meghatározások és koncepció

elkészítése • Oktatási koncepció és terv • Integrált Átállási terv • Template megoldás elkészítéséről szóló jegyzőkönyv • Tesztelési koncepció és terv • Tesztesetek listája • Vállalkozói fejlesztői teszt dokumentációja • SAP fejlesztések és interfacek fejlesztői dokumentációja • Migrációs betöltők dokumentációja • Migrációs betöltők tesztjének jegyzőkönyvei • Kulcsfelhasználói oktatási anyag • Kulcsfelhasználói kézikönyv • SAP alkalmazás, továbbá a terjedelembe eső további rendszerkomponensekről

technológiai környezeti és alkalmazási Üzemeltetői oktatási anyag • SAP alkalmazás, továbbá a terjedelembe eső további rendszerkomponensekről

technológiai környezeti és alkalmazási Üzemeltetési dokumentáció • Éles üzemi átadási jegyzőkönyv • Kiemelt támogatási időszakot lezáró jegyzőkönyv

A szállítandók elkészítése előtt a Vállalkozónak javaslatot kell tennie a szállítandók szerkezetére, formai és tartalmi felépítésére, azt egyeztetnie kell a NÜSZ Zrt. projektvezetőjével és a minőségbiztosítóval. A NÜSZ Zrt. kizárólag ezen előzetesen elfogadáson átesett szállítandót köteles átvenni.

13

4. FOGYASZTÓI TÖRZSADATOK Annak érdekében, hogy a fogyasztói törzsadatok minél pontosabbak és strukturáltan kereshetők és beazonosíthatók legyenek, címtörzs kódokat kell használni. Jelenleg a cégek jellemzően használnak utcatörzset, ugyanakkor mindenkinek jellemzően az adott régióhoz területhez tartozó címtörzs struktúrája áll rendelkezésre. A jövőbeni Vízi Közmű modellben az alábbi címadatok alapulnak címtörzs használatán:

• Fogyasztási helyek

• címadatai • Üzleti partnerek székhely/lakhely címadatai

Nem kötelezően alkalmazandó a címtörzs a levelezési címek megadásánál. Az alábbi cím törzs objektumok alkalmazása terjesztendő ki a DMRV modellre épülve:

• Településtörzs • Irányítószám törzs (településhez rendelve) • Utcatörzs (irányítószámhoz rendelve) házszámtartománnyal

4.1 TÁMOGATANDÓ FŐ FOLYAMATOK

• 7.2.1 fejezetben rögzített fogyasztói adatok kezelése • Település/irányítószám/utca létrehozása, módosítása, zárolása

5. LEOLVASÁS, ÜTEMEZÉS


• Leolvasás szervezése, ütemezése – leolvasási egységek/kötegek kialakítása

• Új fogyasztási helyek létrehozása – besorolás leolvasási egységbe, beköltözési mérőállás rögzítése

• Készülék fel/leszerelés, csere – leolvasási eredmény rögzítése

• Névátírás – ki/beköltözés leolvasási eredmény rögzítése • Leolvasói állományok (leolvasási rendelések) tömeges és egyedi

létrehozása • Leolvasói állományok (leolvasási rendelések) leolvasói alrendszerbe

(diszpécser rendszerbe) juttatása, • Leolvasói lapok nyomtatása készülék nélküli hagyományos leolvasás

esetén • Mérőállások importálása külső rendszerekből (diszpécser rendszerekből

és távleolvasói rendszerekből) • Ügyfél diktálások fogadása • IS-U-ba beérkezett mérőállások hihetőségvizsgálatának elvégzése • Hiányzó mérőállás esetén becsült mérőállások tömeges és/vagy egyedi

14

meghatározása

5.2 KIALAKÍTANDÓ FUNKCIONALITÁS

5.2.1 DMRV ALAP TEMPLATE RENDSZER KIALAKÍTÁSA

• a leolvasási és ütemezési funkciók és folyamatok implementációja alapvetően SAP sztenderd rendszerben történt kevés egyedi fejlesztéssel, átalakítással, melyek a sztenderd folyamatokat lényegesen nem módosítják

• a leolvasási egységek földrajzi egységenként és leolvasási gyakoriság szerint vannak szervezve

o leolvasási gyakoriságok: havi, 2havi, 3havi, 6havi, éves

• leolvasási módok: szolgáltató által végzett leolvasás, IVR/okostelefonos/internetes diktálás

• a leolvasási rendelések diszpécser rendszeren keresztül jutnak el a leolvasói mobil eszközökre

• a szolgáltatói leolvasás rögzítése mobil eszközökkel történik, technikai hiba esetén a diszpécser rendszerből leolvasói lista nyomtatható, az SAP-ból leolvasást támogató nyomtatvány közvetlenül nem áll elő

• a szolgáltatói leolvasási eredmények a diszpécser rendszeren keresztül kerülnek a mobil leolvasói eszközökből az SAP-ba

• elfogadhatóság-vizsgálatok: 3-szoros ellenőrzés, negatív fogyasztás

• megengedett az almérők főmérőktől eltérő időpontban történő leolvasása (ezt a kialakított elszámolási megoldás is támogatja)

• becslési módszerek:

• éves fogyasztás alapján (új lakossági fogyasztó 50 m3/év)

o részszámlázás esetén is használatban van a becslési algoritmus • a leolvasási eredmények monitorozásához a sztenderd tranzakciókon túl

fejlesztett SAP riportokat is használnak, illetve a riportolás/ellenőrzés részben a diszpécser rendszerben történik

5.2.2 TEMPLATE-BŐVÍTÉSI FELADATOK

• leolvasók, kötegek/leolvasási egységek implementálása (minden szolgáltató)

• köteg-határidő rekord “egymezős” bővítése / kapcsolódó funkció vizsgálata (ÉDV)

• emailen keresztül történő diktálási csatorna kialakítása (ÉRV)

• ciklikus leolvasás 2 hetente (ÉRV), évente 5 alkalommal (DRV)

• becslési módszerek validálása, szükség esetén kiegészítése (minden szolgáltató)

• leolvasó lapok (leolvasási rendelések) nyomtatása SAP-ból (minden szolgáltató)

• hihetőség-vizsgálatok validálása, újak kialakítása (pl. az ÉDV 27 félét használ, ennyi nincs a template rendszerben)

15

• Távleolvasás interfészelése

• Leolvasói megjegyzéskódok egységesítése

• Egységes követő műveletek kialakítása

• Riportok: rendelkezésre álló riportok validálása, szükség esetén kiegészítése (minden szolgáltató)

5.3 RENDSZER KAPCSOLATOK

5.3.1 DMRV RENDSZERKAPCSOLATOK

• diszpécser rendszer: leolvasási rendelések letöltése SAP IS-U-ból, leolvasási eredmények feltöltése SAP IS-Uba

• IVR diktálás

• internet és okostelefon

5.3.2 RENDSZERKAPCSOLATOK BŐVÍTÉSE

• Új Reader “Okostelefon” interfész – leolvasási rendelések letöltése, eredmények feltöltése (TRV, ÉRV, DRV)

• diszpécser rendszer illesztése (ÉDV, DRV, ÉRV)

• diktálási csatornák illesztése – email, internet/okostelefon, telefon, IVR (minden szolgáltató)

• távleolvasási rendszer illesztése (MOM IZARNET: ÉDV, DRV)

• nyomtatás leolvasó-lapok előállításához

5.4 FELTÉTELEZÉSEK, KIZÁRÁSOK Az alábbi feladatok nem tartoznak a megvalósítási terjedelembe:

• leolvasói mobileszközök egységesítése

• diszpécser rendszerek egységesítése

• leolvasás egységesítése, újraszervezése, optimalizálása

• előrefizetős funkciók, pilot projektek eredményeinek implementációja

• egységes dokumentumkezelés kialakítása

16

6. ELSZÁMOLÁS, SZÁMLÁZÁS

6.1 TÁMOGATANDÓ FŐ FOLYAMATOK Az IS-U elszámolás, számlázás területén az alábbi fő folyamatokat kell támogatni:

• Árak nyilvántartása, kezelése

• Tarifastruktúra kialakítása, alkalmazása az elszámoláskor (rezsicsökkentés leképezése)

• Elszámolás/számlázás kiválogatás kezelése

• Al-főmérős kapcsolatok elszámolásának megvalósítása

• Osztott fogyasztás kezelése

• Részszámlázás

• Elszámolás/számlázás ütemezése

• Nyomtatás

• E-számlák kezelése

6.2 KIALAKÍTANDÓ FUNKCIONALITÁS A kialakítandó funkcionalitás tekintetében a DMRV IS-U rendszerében megvalósított elszámolási és számlázási megoldását kell alapul venni, ehhez képest mutatjuk be az egyezőségeket és különbségeket.

6.2.1 DMRV ALAP TEMPLATE RENDSZER KIALAKÍTÁSA, ÉS A TOVÁBBI TÁRSASÁGOK SAJÁTOSSÁGAI

6.2.1.1 Árak nyilvántartása, kezelése

Az árak nyilvántartása és kezelése standard eszközökkel történik, azaz tarifa tényező csoportok, és bekötés (tényező) szintű egyedi árak alkalmazásával. Ennek a logikának a bővítését/fejlesztését jelenleg nem látjuk szükségesnek. Az ÉDV esetén fordul elő, hogy a tarifatípus/tarifafajta/tarifa is meghatároz árakat, e miatt nagyon nagy db számú tarifa struktúra törzsadat objektum van használatban, ezt a logikát szükséges tarifa tényező csoport, ill. szükség esetén bekötés szintű egyedi árak használatával leképezni.

6.2.1.2 Tarifa struktúra kialakítása, alkalmazása az elszámoláskor (rezsicsökkentés leképezése)

A DMRV tarifa struktúra kialakítása tartalmazza az iparági/törvényi tételek számlázásához szükséges tételek kezelését:

• alapdíj (1-hez köthető havi díj),

• m3 arányos díjak (ivóvíz, szennyvíz, vízterhelési díj),

• átalány m3 díja,

• locsolási kedvezmény (%-os, ill. mérős), Elvárás, hogy ez a kialakított tarifa struktúra a lenti kiegészítésekkel alkalmas legyen minden Társaság esetén a használatban lévő díjtételek számlázására. A tarifa struktúrát az alábbi funkcionalitással kell kiegészíteni:

17

• az ÉDV alkalmaz nap arányos alapdíj számlázást, amit meg kell szüntetni és át kell térni a határnapos számlázásra,

• az ÉRV és TRV esetén egyedi csatornadíj kedvezmények, hasonlóan a locsolási díjkedvezményhez,

• a TRV esetén folyékony hulladék számlázása (ha az IS-U-ban kerül megvalósításra).

Minden Társaságnál előfordul, hogy a csatorna vagy a vízdíjat társszolgáltató számlázza, így excel állományt kell átadni az adott cég részére. Ezt a tarifák bővítésénél figyelembe kell venni, valamint egységesíteni kell azt a jellemzőt, mely alapján az excel állományt előállító program a leválogatást elvégezheti (pl. CO kontírozás, vagy valamilyen bekötés jellemző). A rezsicsökkentés leképezése az egyes Társaságok esetén kismértékben eltérő módon történt (pl. kerekítések kezelése), ezt célszerű lesz egységes módon kezelni. Valamint a DRV esetén a rezsicsökkentés több fogyasztási helyes számlában is megjelenik, ennek az egységes kezelését is meg kell határozni. A template rendszert is fel kell rá készíteni.

6.2.1.3 Elszámolás/számlázás kiválogatás kezelése

Az IS-U standard elszámolás és számlázási kiválogatás csoportokkal megvalósított megoldás van használatban a DMRV és az IS-U-t használó Társaságok esetén, kiegészítve a manuális kiválogatás lehetőségével. Ez minden Társaság esetén alkalmazandó.

6.2.1.4 Al-főmérős kapcsolatok elszámolásának megvalósítása

A DMRV és az ÉDV esetén al/főbekötéssel (bekötés struktúrával), a DRV esetén viszont a standard al-főmérős kapcsolattal megvalósított al-főmérős kezelés van. Minden Társaság esetén az al/főbekötéses megoldást kell alkalmazni. A DMRV esetén létezik többszörös mellékmérős kapcsolat, így ez a bővebb megoldás képzi az alapot.

6.2.1.5 Osztott fogyasztás kezelése

A DMRV esetén osztott fogyasztás megosztása csak bekötés tényezőben megadott %-os érték alapján történik, azonban az ÉDV esetén ez al/főbekötés segítségével van megvalósítva. A DRV esetén nincs osztott fogyasztás kezelés. Az ÉRV-nél egy mérő fogyasztása is számlázódhat több fogyasztási helyre vonatkozóan %-os megosztással, ez elszámolás releváns beszerelés, és %-os megosztás kombinációjával kezelhető. A TRV esetén fogyasztási hely szintű %-os megosztást lehet alkalmazni. Az elszámolás releváns beszerelés, és bekötés szintű (bekötés tényezőben megadott) %-os megosztás kombinációjával képzendőek le a lehetséges esetek.

6.2.1.6 Részszámlázás

DPC eljárással történik a részszámlák kibocsátása a DMRV-nél, a részmennyiség értéke bekötés tényezőben tárolt. Az ÉDV nem alkalmaz részszámlázást. A DRV-nél nem DPC eljárással történik a részszámlázás, hanem részszámlázási terv eljárással, valamint itt előre is történik részszámla kibocsájtás. Az ÉRV és TRV-nél is történik részszámlázás. A részszámla mennyiség meghatározás alapja változó, lehet pl. előző évi fogyasztásból vagy előző leolvasási adatból képzett havi átlag. Szükséges egységesen a DPC eljárással kezelni a részszámlázást, és a havi részmennyiséget bekötés tényezőben tárolni. A részmennyiség alapjának meghatározása különbözhet az egyes Társaságokban. A részszámla előre kibocsátása a DPC-s eljárás esetén is biztosítható.

18

6.2.1.7 Elszámolás/számlázás ütemezése

Az elszámolás, számlázás ütemezése az egy rendszerben kialakítandó több vállalatos megoldás esetén is az adott Társaságban meghatározott ütemezést követi, ezt a leolvasási egységek, kötegek megfelelő (adott Társaságra vonatkozó) kialakításával kell biztosítani.

6.2.1.8 Nyomtatás

DMRV esetén saját központi nyomtatás és borítékolás történik, nincs köztes rendszer. Az ÜSZO-n nem kap számlát a fogyasztó, központi nyomtatás/ postázással valósul meg a számlaküldés. A DRV-nél saját kézben lévő, de SAP tekintetében külső rendszeren keresztül történik a nyomtatás. Saját tömeges számla nyomtatás és borítékolás, de a személyes ÜSZO irodákban egyedi nyomtatás is történik. Az ÉDV esetében a tömeges nyomtatás külső cégen keresztül történik. Egyedi nyomtatás ügyfélszolgálati irodákban. A számlakép formai kialakítása és nyomtatása SAP application forms űrlapon keresztül történik, nem a külső cég alakítja ki a számlaképet. Az ÉRV esetén is történik helyi nyomtatás, a TRV-nél a tömeges ágba küldik az ÜSZO-n indított számlanyomtatási igényeket.

A számlanyomtatás kapcsán szükséges az egységes kezelés:

• nyomtatás SAP application forms-on keresztül, mely RDI állományt állít elő (nincs formázás),

• az RDI állomány spool kérelmen keresztül külső rendszerben feldolgozásra kerül,

• a külső rendszer alakítja ki a kapott RDI adatokból a számlaképet, melynek nem vállalt specifikus részét is célszerű egységesíteni, majd pdf állományt készít, mely archiválódik is, és vagy visszamegy az egyedi nyomtatóra, ha egyedi nyomtatás történik, vagy a tömeges nyomtatást végző nyomtatóra (adott esetben külső céghez) érkezik meg a tömeges állomány,

• ha e-számláról van szó, akkor a külső rendszerből a szükséges állomány (xml, pdf) továbbítódik az e-számla szolgáltatóhoz.

Az egységes kezelés kapcsán a számlakép nem társaság specifikus része is egységesítendő. A számla mellékleteként szükséges a mellékmérős adatok nyomtatása is a jelenlegi gyakorlatnak megfelelően.

6.2.1.9 E-számlák kezelése

A DMRV, DRV, és az ÉRV a Díjnet rendszerén keresztül mutatja be az e-számlákat, illetve a DMRV esetén saját e-mailes számlaküldés is van. Az ÉDV esetén a Számlaközpont Zrt.-n keresztül történik az e-számlabemutatás. A TRV-nél nincs e- számlázás. Várhatóan az e-számlabemutatás azonos szolgáltatón keresztül történik, a nyomtatási résznél javasolt egységes technikai megvalósítással.

6.3 RENDSZER KAPCSOLATOK Az elszámolás, számlázás részen a számlanyomtatás, és a hozzá kapcsolódó e- számlaküldés jelenti a külső rendszer kapcsolatokat:

• SAP IS-U és a számlaképet, nyomtatási állományt, e-számla adatokat előállító külső rendszer interface (RDI állomány átadás, ill. elkészült pdf

19

archiválás, majd hozzákapcsolása a nyomtatási bizonylathoz pl. későbbi másolat nyomtatás miatt)

6.4 FELTÉTELEZÉSEK, KIZÁRÁSOK Az alábbi feltételezések érvényesek a megvalósítási terjedelemre:

• A rezsicsökkentés leképezése egységesített módon megvalósítható.

• Al-főmérős kapcsolatok kezelésére az al/főbekötéses megoldás egységesen használható.

• Az osztott fogyasztás kezelése az elszámolás releváns beszerelés, és bekötés szintű (bekötés tényezőben megadott) %-os megosztás eszköztárával valósul meg.

• A részszámlázás DPC-s eljárással megvalósított, a havi részmennyiséget bekötés tényezőben tárolva.

• Az egyedi, tömeges számlanyomtatás az output menedzsment rendszerben valósul meg, a számlaarchiválás egységes kezelése külső rendszeren (FileNet) történik, az SAP-ban a FileNet elérés linkje kerül eltárolásra.

7. FOLYÓSZÁMLAKEZELÉS

7.1 TÁMOGATANDÓ FŐ FOLYAMATOK Az IS-U folyószámla kezelés területén az alábbi fő folyamatokat kell támogatni:

• Üzleti törzsadat kezelés

• Folyószámla könyvelés (manuális és automatikus)

• Folyószámla karbantartás

• Banki kapcsolatok, utalás

• Pénztár

• Nyomtatványkezelés

• Felszólítás, hátralékkezelés

• Kivezetések, leírások

• Részletfizetések, fizetési haladékok

• Késedelmi kamatkezelés

20

7.2 KIALAKÍTANDÓ FUNKCIONALITÁS A projekt során a folyószámlakezelés r e n d s z e r o l d a l i folyamatainak egységesítése, harmonizálása a Vállalkozó feladata. Az egységes kezeléshez szükséges üzleti oldali döntések meghozatala a Megrendelő feladata. A koncepció szerint a DMRV SAP FI-CA moduljának jelenlegi folyamatait és funkcióit alapul véve egy olyan egységes megoldást szükséges kialakítani, amely mind az öt Társaság működését hatékonyan támogatja.

7.2.1 ÜZLETI TÖRZSADATOK KEZELÉSE

7.2.1.1 Üzleti partnerek

Az SAP IS-U modul törzsadat struktúrájának legfelsőbb szintje, amely természetes személyek, jogi személyek, és csoportok alapvető adatainak (nevek, címek, azonosítók, bankkapcsolatok) tárolására szolgál. Az egységes üzleti partner struktúra kialakítása során kiegészítendő a DMRV SAP IS-U rendszerében kialakított üzleti partner struktúra, ezzel lehetővé téve a többi Társaság üzleti partnereinek migrációját is.

7.2.1.2 Szerződéses Folyószámlák

Az SAP IS-U modul törzsadat struktúrájának következő szintje, amely a folyószámla kezelés funkcióinak vezérlő paramétereit tartalmazza. A DMRV SAP IS-U rendszerében kialakított folyószámla típusokkal (lakossági, gazdálkodó, intézményi, társasház, SD folyószámla) valamennyi Társaság folyószámla törzsadata lefedhető lesz. Konszolidálni szükséges azonban az egyes mezők eltérő használatát (például számlaosztály mező), és értékkészletét. Az egységesítés során harmonizálni kell a folyószámlák vezérlő paramétereit, melyek közül a legfontosabbak a különböző zárolások és okaik, számlakijelölési jellemzők, fizetési kondíciók, fizetési módok, kamatkulcsok, felszólítási eljárások, levelezési változatok.

7.2.1.3 Védett fogyasztók törzsadatai

A védett fogyasztók esetében is szükség van egységesítésre, mert a különböző Társaságok mai megoldásai nagyon eltérőek. A DMRV SAP IS-U rendszere ma nincs felkészítve a védettségi adatok tárolására, ezt a projekt során ki kell alakítani.

7.2.2 ALAPFUNKCIÓK

7.2.2.1 Manuális könyvelések

Az SAP IS-U és SD számlázó modulokból automatikusan könyvelt számlatételek mellett különböző típusú bizonylatokat manuálisan rögzítenek a felhasználók (önkormányzati támogatások, átkönyvelések, stb.). Ezekhez a könyvelésekhez szükséges fő és részműveleteket, valamint a kapcsolódó bizonylat fajtákat egységesíteni kell.

7.2.2.2Számlakarbantarás

A folyószámlákon található követelések és kötelezettségek összepontozását a rendszerben egyedileg kézzel és automatikusan ütemezett háttér jobbal is végre kell tudni hajtani. Az automatikus összepontozás funkció jelenleg nincs használatban a DMRV rendszerében. Az ÉDV, valamint a DRV SAP IS-U rendszereiben azonban (eltérő rendszerességgel) használatban van. A megvalósítás során az egységes működéshez kidolgozandó az a kiegyenlítési logika, amely valamennyi Társaság működését támogatja. Az egységesített rendszerben szükséges az éjszakai tömeges automatikus összepontozás kialakítása.

21

7.2.3 BANKI KAPCSOLATOK A DMRV SAP IS-U rendszerében jelenleg 2 különböző bank (CIB Bank, Budapest Bank) felé van kialakítva automatikus számlakivonat betöltő interfész. A megvalósítás során szükséges ennek kiegészítése további bankok felé: OTP és K&H. A csoportos beszedéseket jelenleg is egy bank felé indítják a Társaságok, az egy rendszerbe migrálását követően sem tervezünk változást. A postai csekkes állományok bedolgozását a DMRV PEK állomány betöltő interfész felhasználásával szükséges valamennyi Társaság számára a Vállalkozónak megvalósítania.

7.2.4 PÉNZTÁR A pénztár funkciók megvalósításához a DMRV SAP FI-CA pénztár funkcióját szükséges a többi Társaság számára is elérhetővé tenni.

7.2.5 FELSZÓLÍTÁSOK, HÁTRALÉKKEZELÉS A felszólítási eljárásokat a projekt során egységesíteni kell. Ehhez a DMRV rendszerében kialakított 7 felszólítási eljárást szükséges alapul venni. Szükség esetén új eljárásokat, szinteket, tevékenységeket kell a Vállalkozónak definiálni a rendszerben. Az új rendszerben szükséges kialakítani az inkasszó és ügyvédi irodáknak való átadást behajtásra, illetve peresítésre.

7.2.6 KIVEZETÉSEK, LEÍRÁSOK A folyószámlákról bizonyos esetekben szükséges nyitott tételeket különböző okokból kivezetni. Ilyenek lehetnek például a kisösszegű tételek kivezetése, elengedett követelések leírása vagy bizonyos követelések eladása. A különböző céllal könyvelt kivezetéseket kivezetési okokkal kell vezérelni, illetve megkülönböztetni egymástól. Az új rendszerben a kivezetések körét, okait és beállításait egységesíteni szükséges.

7.2.7 RÉSZLETFIZETÉSEK, FIZETÉSI HALADÉKOK Az SAP FI-CA folyószámlán található nyitott tételekre részletfizetés adható. Ehhez részletfizetési terv létrehozása szükséges. A részletfizetési terv típusokkal különböző futamidejű részletfizetéseket definiálhatunk, ezen kívül megadhatunk díjakat és különböző kerekítési szabályokat is. A részletfizetésbe vont tételekre késedelmi kamat is számítható és statisztikai tételként könyvelhető. A részletfizetési terv típusokat részletfizetési terv kategóriákba is szükséges besorolni. A projekt során a részletfizetési terveket és a kapcsolódó űrlapokat egységesíteni kell a Vállalkozónak.

7.2.8 KÉSEDELMI KAMATSZÁMÍTÁS A késedelmesen kiegyenlített tételek esetén késedelmi kamatot számíthatunk fel az ügyfeleknek. Ez történhet egyedileg vagy tömeges háttérfutás alkalmával. A késedelmi kamatról az ügyfelet a következő esedékes számlán vagy külön kamatközlő levélen értesítjük. A folyószámlához rendelhető kamatkulcsokat, kamatszámítási szabályokat, és a kamat értesítés módját egységesíteni szükséges.

7.2.9 NYOMTATVÁNYOK A folyószámlakezelés folyamatai számos űrlap nyomtatását teszik szükségessé. Ezek közül a legfontosabbak az egyenlegközlők, fizetési felszólítók, részletfizetési megállapodások, kamatlevelek, pénztári nyugták. A projekt célja, hogy a Társaságok a lehető legnagyobb mértékben egységes formájú és kinézetű nyomtatványokat bocsássanak ki. Az űrlapok nyomtatására biztosítani kell lokális, illetve nyomdai előállítási módot az output menedzsment megoldási komponens támogatásával.

22

7.2.10 RENDSZERKAPCSOLATOK A DMRV központi vízközmű rendszerének folyószámlakezelő modulja a következő SAP-n kívüli rendszerekkel szükséges interfésszel összekötni:

• banki interfészek,

• postai PEK

• DÍJNET E-számla interfész,

• behajtó iroda,

• ügyvédi iroda,

• On-line ügyfélszolgálat,

• ELO (partneradatok),

• nyomda. A központi vízi közmű template megoldás integrációja más SAP modulokkal:

• SD modullal való integráció: A nem alaptevékenységi számlázás az SD modulból fog történni és az SD modul a FI-CA felé fog feladni. Szükséges az SD – FI-CA előleg kezelési folyamat kialakítása.

• FI modullal való integráció: Az értékvesztés kezelése során az adatok exportálása a FI-CA-ból történik, majd a manuális kalkulációt követően az importálása az FI modulba történik.


• Folyószámla kezelési folyamatok egységes kezelése.

• Űrlapok egységesített kinézettel, egységes nyomdai interfész.

• A folyamatok kialakításánál alkalmazkodás az SAP standard lehetőségeihez.

• Fejlesztések minimalizálása, fejlesztés csak nagyon indokolt esetekben.

8. ÜGYFÉLSZOLGÁLAT


• Ügyfélszolgálati csatornák

o Személyes ügyfélszolgálat a jelenlegi fizikai helyükön megmaradva elosztottan

o Back Office-ba érkező megkeresések (e-mail, levél, fax, online formokon keresztül)

o Telefonos ügyfélszolgálat (Call Center)

o Online ügyfélszolgálat (e-mail, internet és mobil)

• Ügyfélszolgálati funkció támogatás

o Gazdasági ügyfélszolgálati folyamatok

Törzsadatok létrehozás és karbantartása

23

Szerződéskezelési folyamatok (új bekapcsolás, átírás, szerződés módosítás, szerződés megszüntetése)

Leolvasási eredmények fogadása

Egyedi számlázási funkciók

o Folyószámlakezelési funkciók

Fizetések kezelése

Részletfizetés, fizetési haladék

Információszolgáltatás, reklamációk, stb. kezelése

o Műszaki ügyfélszolgálati funkciók

Hálózat fejlesztési munkák (bekötés kialakítás)

Műszaki munka megrendelések

• Ügyfélszolgálati folyamat támogatás

o Ügyfélszolgálati kapcsolatok naplózása

o Ügykövetési funkciók

o Időpont egyeztetés

o Riportok, adatszolgáltatások o Nyomtatványok (szerződés, egyedi számla, egyedi folyószámla

űrlapok – egyenlegközlő, tartozás igazolás, részletfizetési/fizetés haladék megállapodás, ügy bejelentő űrlap, törzsadat módosítás bejelentése)

8.2 KIALAKÍTANDÓ FUNKCIONALITÁS A vizsgált Vízi Közművek funkcionális- és folyamatigényei a szabályozási előírások és az ágazati jellemzők miatt nem térnek el egymástól. Az 5 Vízi Közmű jelenleg alkalmazott informatikai támogatása (funkcionális terjedelem, mélység, integráltság) jelentős mértékben különbözik. Az alábbiakban azokat a funkciókat soroljuk fel, amely a DMRV alap template rendszer felállításához feltétlenül szükségesek, hogy az 5 Vízi Közmű ügyfélszolgálati folyamatait integráltan támogatni tudja.

8.2.1 DMRV ALAP TEMPLATE RENDSZER KIALAKÍTÁSA

• SAP ügyfélszolgálati funkciók leképezése – SAP IS-U CIC0 ügyfélszolgálati felületek implementálása

o gazdasági ügyfélszolgálati felület

o műszaki ügyfélszolgálati felület

o gazdasági és műszaki felület

• SAP ügyfélszolgálati folyamattámogatás

o jól szabályozott, egységesített ügyfélszolgálati folyamatokra SAP Front Office folyamattámogatás implementálása (átírás, egyéb szolgáltatások megrendelés pl. vízminőség bevizsgálása, stb.)

o SAP ügykövetési funkciók implementálása (naplózás, státuszolás, feldolgozó hozzárendelés) a Back Office számára ügy és folyamat lépés szinten.

24

o SAP IS-U ügyfélszolgálati riport fejlesztések (egységes, szabályozás által előírt scope-ra)

8.3 RENDSZER KAPCSOLATOK Az ügyfélszolgálati funkciókat kiszolgáló rendszerkapcsolatokat teljes mértékű centralizációja a Vállalkozó feladata

8.3.1 KÖZPONTI ÜGYFÉLSZOLGÁLAT RENDSZERKAPCSOLATOK

• SAP IS-U és központi, egységes Contact Center interface o azonosítás

o tájékoztatás o nyomtatvány és írásos tájékoztatás igénylés

o diktált mérőállások fogadása o folyószámla egyenleg lekérdezése

o ügyintézői kapcsolás (egyedi ügyintézés)

• SAP IS-U és központi, egységes online ügyfélszolgálat interface

o regisztráció, bejelentkezés

o időpontfoglalás

o törzsadat módosítás (levelezési cím változtatás) o mérőállás bejelentés, mérőállás történeti adatok

o számla megjelentés/letöltés/számlamásolat (Díjnet szolgáltatás jelenleg)

o bankkártyás befizetés (Díjnet szolgáltatás jelenleg)

o folyószámla megtekintés (egyenleg, tételek, nullás igazolás)

o fizetési mód változtatás

o csekk igénylés

o műszaki megrendelések fogadása

o bejelentő űrlap (általános, reklamáció)

• SAP IS-U és ügyfélszolgálati dokumentumkezelő rendszer (iratkezelés, archiválás, stb.) interface

• Egységes műszaki ügyfélszolgálati felület és Társaságonkénti műszaki

területekkel ELO rendszeren keresztüli kommunikáció megvalósítása, interface kapcsolatok kialakításával.

• Központi, egységes nyomtatási funkciók implementálása az SAP

rendszerből (pl. szerződésnyomtatás)

o lokális nyomtatás (front office folyamatokhoz kapcsolódóan)

o centrális, vállalati nyomtatás (back office folyamatokhoz kapcsolódóan)

o nyomtatási interface (nagytömegű háttér folyamatokhoz kapcsolódóan)

25


• Üzleti törzsadatok egységes kezelése (adattartalom, kötelezőség, stb.) –

szükség szerint ennek megfelelő adattisztítás (pl. adatpótlás) végrehajtása a Társaságok oldalán.

• Ügyfélszolgálati folyamatok egységes ügyvitele

• Ügyfélszolgálati űrlapok egységesítése

• Egységes Contact center

• Egységes online ügyfélszolgálati felület

• Egységes nyomtatási rendszer kapcsolatok

• A jelenlegi műszaki rendszerek megmaradnak, így az ügyfélszolgálati

oldalról indításra kerülő műszaki folyamatokat az ELO rendszer workflow megoldással fogja támogatni, mely szoros integrációban kell, hogy legyen az SAP ügykövetési megoldásával.

9. KAPCSOLÓDÓ CENTRALIZÁLANDÓ RENDSZEREK

9.1 CALL CENTER Call Center bevezetésével kapcsolatos Vállalkozói feladatok:

• A Vállalkozónak be kell vezetnie az Avaya Call Center k ö z p o n t i megoldását, melyet mind az öt társaság használni fog.

• Az IVR funkciót az Avaya Aura Experience Portal-nak (AAEP) kell kiszolgálnia.A cél egy teljesen egységes IVR menü rendszer kialakítása, amely egységesen kezeli az öt különböző vízi közmű felhasználóit.

• Az IVR eléréséhez víziközművenként külön-külön behívószám fog tartozni, ezzel lehetővé téve, hogy az IVR meg tudja állapítani, hogy a felhasználó melyik közmű céget hívta.

• Feladat az ügyfélhívások és visszahívások kezelésének kezelése. • A megoldásnak támogatnia kell a panaszkezelés fogadását és folyamatának

indítását a Call Center első menüpintjával, azonosítás nélkül. • Szükséges automata funkciókat megvalósítani a mérőállás bejelentés és

folyószámla egyenleg lekérdezés esetében, csökkentve ezzel az ügyfélszolgálati terhelést.

• Szükséges az SAP IS-U integrációt megvalósítani (ÜP beazonosítás és egyből ÜP áttekintő képernyő megjelenítése).

• A vállalkozó feladata kezelő felület biztosítása, mely tartalmazza a legfontosabb információkat, mint például a nyitvatartási rendek kezelése, a menüpontok transzfer számainak kezelése és a riportok.

• A megoldásnak támogatnia kell az ügyfél elégedettség mérést. • Központi HW infrastruktúra: Méretezni é s a r c h i t e k t ú r a t e r v e z n i

kell a Vállalkozónak, de a hardver szállítás nem terjedelem.

26

9.2 ONLINE ÜGYFÉLSZOLGÁLAT Online ügyfélszolgálat bevezetésével kapcsolatos Vállalkozói feladatok:

• A társaságok jelenlegi megoldásainak vizsgálatát követően a legkorszerűbb IS-U-val integrált megoldás átvétele és kiterjesztése a Vállalkozó feladata, mely szoros integrációt feltételez az SAP CIC0 felületével.

• Az online ügyfélszolgálati megoldásnak ESB-n keresztül kell kommunikálnia. Az ESB oldali feladatok specifikálása és kezelése a Vállalkozó feladata.

• Egy közös webhely a különböző Társaságok ügyfeleinek, Társasági azonosítással. • Más Társaságoknál használt Online regisztráció esetén a migrációt technikailag

meg kell oldani. • Szükséges a tervben szereplő automata funkciókat megvalósítani, csökkentve

ezzel az ügyfélszolgálati terhelést. • Az online felületen elérhető információk és indítható folyamatoknak

paraméterezhetőeknek kell lenniük, a megfelelő formokkal és beállíthatónak kell lennie, hogy mi érhető el ügyfél regisztrációval és mi regisztráció nélkül.

• Szükséges push üzenetek küldésének megvalósítása. • A megoldásnak tartalmaznia kell időpont foglaló felületet, ahol az ügyfelek

előzetesen időpontot foglalhatnak. A megoldásnak hívórendszerrel integrálhatónak kell lennie.

• Az időpont foglalásnak és a folyamat indításnak az SAP-val integrált módon kell működnie, támogatva ezzel a hatékony ügyfélszolgálati munkavégzést.

• A megoldásnak támogatnia és kezelnie kell az ügyfélkapus azonosítással való belépést.

• Az online ügyfélszolgálati felületnek alkalmasnak kell lennie online befizetés kezelésére, valamint a számlával kapcsolatos információk (pl. Számlakép megjelenítése) kezelésére.

• A felületnek alkalmasnak kell lennie mérőállások online módon történő fogadására és az SAP rendszernek való átadására, ügyintézői beavatkozás nélkül.

• Az online ügyfélszolgálati megoldásnak mobil applikációról is funkció azonos módon elérhetőnek kell lennie.

• Az online ügyfélszolgálati rendszert úgy kell kialakítani, hogy egységes legyen, azonban társaságonként eltérő design kezelését támogatni tudja.

• Központi HW infrastruktúra: Méretezni kell a Vállalkozónak, de a hardver szállítás nem terjedelem.

9.3 DOKUMENTUM MENEDZSMENT

Dokumentum menedzsment bevezetésével kapcsolatos Vállalkozói feladatok:

• Kiinduló rendszer a DMRV ELO professional v9 rendszere, ezt kell a Vállalkozónak minden cégre kiterjesztenie.

• Megvalósítandó, hogy az ügyfélszolgálati dokumentumok iktatása, kezelése a kibővített ELO enterprise v 1 0 rendszerben történjen.

• A DMRV-nek a jelen projekt által nem érintett ELO alkalmazásai át kell vezetni az új egységes ELO DMS rendszerbe.

• Az öt Vízmű ügyfélkapcsolati iratkezelésére egységes megoldást kell adni, amelynél a vízmű specifikus paraméterek (felhasználók, szervezeti egységek, jogosultságok) konfigurálással állítható be.

27

• AZ ELO rendszerben történő munkához szükséges ügyfél adatok elérése az SAP-val való kapcsolaton keresztül kell, hogy történjen.

• Az ELO rendszerben tárolt, és az SAP-val összekötött dokumentumok az SAP felületéről elérhetők lesznek. Egyéb rendszerek részére a dokumentumok az ELO interfészen keresztül biztosíthatók.

• Integrálni kell a dokumentum objektumot a megfelelő IS-U objektummal, az IS-U ügyfélkapcsolati naplóját kell használni erre a tevékenységre.

• Ki kell alakítani az output menedzsment tevékenység során, hogy az IS-U-ból képződő dokumentumok archiválása tárolása egyből a FileNet rendszerbe kerüljön SAP IS-U objektum kapcsolat kiépítéssel

9.4 OUTPUT ÉS NYOMTATÁS MENEDZSMENT Vállalkozói feladatok a központi output- és nyomtatásmenedzsment bevezetésével kapcsolatban:

• A dokumentum formátumokat egységesíteni kell, azonos tartalmú dokumentum csak egy formátumban fordulhat elő az esetleges Társasági sajátosságok (bankszámla, logó, cím adószám, stb.) ezen szerkezeten belül kezelendők.

• Az output menedzsment szoftver megoldásban a következő folyamatok kialakítása a Vállalkozó feladata:

o Tömeges nyomdai állományok előállítása

o Tömeges vállalati nyomtatás

28

o Lokális egyedi nyomtatás

o Lokális egyedi előnézet (preview) • Beállíthatónak kell lennie, hogy dokumentumtípusonként mely dokumentumok

hol nyomtathatók: o Ügyintéző melletti lokális nyomtató (pl. front office folyamat esetén) o Centralizált belső nyomtatás (kampány levelek, stb.) o Centralizált külső nyomtatás (pl. számlák, késedelmi kamat levelek).

• A megoldást úgy kell kialakítani, hogy minden tömeges generálási és másolat küldési folyamatot az SAP kezdeményez az LPDW nyomtató driverre, mint kimenti eszközre történő RDI adat nyomtatással.

• A nyomdai ágban kétféle esetet kell kezelni: o újonnan generált dokumentumok; o és létező dokumentumok küldését.

• A nyomdának való átadáskor támogatni kell, hogy a dokumentumok üzleti és technológiai szempontokat figyelembe vételével kerüljenek csoportosításra és rendezésre.

• Fel kell készíteni a rendszert a dokumentumok archiváló rendszerbe történő átadásával.

• Az output menedzsment szoftvernek kezelnie kell a nyomdai visszajelentések feldolgozását. A visszajelentési információk alapján státuszolnia kell a dokumentumokat. A JOB-ok monitorozását, és a hibás JOB-ok újraindítását/törlését is támogatnia kell.

• A teljesen visszajelentett dokumentumokat elmozgatja az archív táblába. Egy másik fontos feladata a rendszerben feleslegessé váló állományok törlése, a könyvtárak takarítása.

A Megrendelőnél rendelkezésre álló FileNet rendszerrel való integráció megvalósítása:

• Ki kell alakítani az output menedzsment tevékenység során, hogy az IS-U-ból képződő dokumentumok archiválása, tárolása egyből a FileNet rendszerbe kerüljön SAP IS-U objektum kapcsolat kiépítéssel.

• A FileNet rendszerben kerülnek tárolásra a tömegesen előálló dokumentumok, mint például számlák, felszólító levelek.

10. MÉRŐKEZELÉS


10.1.1 MŰSZAKI TÖRZSADATOK KIALAKÍTÁSA A műszaki törzsadatokat, címeket, fogyasztási helyeket le kell képezni az IS-U struktúra elemeivel. Ezek a következők:

• Csatlakozási objektum (címkezelés egységesítés)

• Fogyasztási hely (kiegészítő cím adatok)

• Bekötés (szerződés műszaki melléklete)

• Készülékhely (a készülékek fizikai elhelyezkedése)

Jelenlegi műszaki folyamatok esetén csatlakozási objektum címadatainak kezelése eltérő módon történik.

10.1.2 KÉSZÜLÉKEK KEZELÉSE Az IS-U-ban nyilvántartott készülékek törzsadatainak meghatározása. Az alábbi

29

törzsadatok kialakítása szükséges: • Mérőcsoportok kialakítása

• Készüléktípusok kialakítása, egységesítése

• Készülékek nyilvántartása (azonos gyártási számok kezelése, plombák egységes kezelése, távleolvasott mérők, előrefizetős mérők, locsolómérők)

10.1.3 MŰVELETEK KÉSZÜLÉKEKKEL Az IS-U-ban leképzendő készülék műveletek:

• Beszerelés (műszaki, elszámolás technikai, összesen) • Leszerelés (elszámolás technikai, műszaki, összesen)

• Csere

• Teljes életút követés (MM – IS-U integráció, a raktár munkáját mobil eszközzel kell támogatni)

• Beszerelt készülékek átalakítása

• Mérőkapcsolatok kialakítása

• Periódus fogyasztás módosítása

• Hitelesítés (Saját és idegen hitelesítés)

10.1.4 RIPORTOK Vállalkozói feladat egy egységes riport rendszer kialakítása az összes Társaságra. A riport igényeket konszolidálni kell, majd ezután szükséges a riportokat kialakítani. A DMRV-nél alkalmazott riportok:

• Fogyasztási helyek listája (mérő, illetve ügyfél mélységűek, az összes kapcsolódó adattal) (Teljes lista, az összes kimutatás előállításához.)

• Cserélendő mérők listája

• Mérő cserelap nyomtatás

• Mellék vízmérők listája hitelesítéshez

• Korlátozó lista

• Mérők listája

10.1.5 FELTÉTELEZÉSEK, KIZÁRÁSOK Az alábbi feltételezések érvényesek a megvalósítási terjedelemre:

• Az egységes mérőtípusokat a DMRV rendszerének indulására meg kell határozni. Javasolt az SAP ajánlást figyelembe venni: Azonos típus az, amikor két készülék egymással fizikailag cserélhető minden átalakítás nélkül. (Mérési tartomány, átmérő, hossz, stb. megegyezik.)

• Azonos gyártási számok kezelésének kidolgozása már a DMRV fázisban.

• A címkezelés egységesítése az első fázisban.

• A különböző mérők (locsoló, távleolvasott, kombi) egységes kezelése.

• Plomba nyilvántartás egységesítésre kerül.

• Mérő életút követés egységesítése.

• Nincs történeti migráció.

• A migrációhoz szükséges bemeneti (betöltendő) adatok előállítása a Vízi Közmű cégek feladata.

30

• A projekt során nem kerül kialakításra a műszaki rendszerek és az IS-U integrációja a műveletek (Beszerelés, Leszerelés, Csere) szintjén.


10.2.1 DMRV ALAP TEMPLATE RENDSZER KIALAKÍTÁSA • A DMRV esetében az alábbi elemek rendszertechnikai módosítása

szükséges:Címkezelés: Jelenleg fogyasztási helyenként van létrehozva csatlakozási objektum. Postai címenként elegendő egy.

• Teljes életút követés: Jelenleg nincs MM – IS-U integráció. (Egységes kialakítás javasolt az összes szolgáltatónál.)

• Készüléktípusok felülvizsgálata.

• Kombi mérők kezelésének felülvizsgálata.

• Plombák kezelése: Jelenleg csak a mérő megnevezésében vannak nyilvántartva.

10.2.2 DRV MIATTI SAJÁTOSSÁGOK IMPLEMENTÁLÁSA

• Mérőkapcsolatok használatának felülvizsgálata (bekötés csoport alkalmazása)

• Készüléktípusok felülvizsgálata

• Locsolómérők kezelése

• Kombimérők kezelése

• Plomba kezelés egységesítés

10.2.3 ÉDV MIATTI SAJÁTOSSÁGOK IMPLEMENTÁLÁSA

• Távleolvasott mérők kezelése

• Idősoros mérők kezelése





•

10.2.4 ÉRV MIATTI SAJÁTOSSÁGOK IMPLEMENTÁLÁSA


• Teljes életút követést alkalmaz (egységesítés)


• Előrefizetős mérők kezelése



31

10.2.5 TRV MIATTI SAJÁTOSSÁGOK IMPLEMENTÁLÁSA





11. MŰSZAKI FOLYAMATOK TÁMOGATÁSA


11.1.1 ELVÁRT MEGOLDÁS

A Vállalkozónak az alábbi rendszerkörnyezetből kell kiindulnia:

• A DMRV-nél, a DRV-nél és az ÉRV-nél jól kidolgozott, szofisztikált műszaki rendszer van bevezetve.

• A műszaki célrendszer a DMRV-nél a VMTR, a DRV-nél az OTMR, amelyek a T-Systems rendszerei hasonló műszaki alapokkal és megvalósítással. Az SAP PM karbantartás modulja a DMRV-nél nincs használatban, a DRV-nél minimális funkcionalitással van bevezetve, mely szerint az OTMR-ben létrehozott rendelések az elszámolások miatt PM rendelésként is leképződnek a rendszerben.

• Az ÉDV műszaki folyamatai az SAP karbantartás PM moduljával vannak leképezve. Az ÉDV-nél az SAP PM moduljának működése hangsúlyos és jól szofisztikált, a munkafolyamatok vezérélése innen történik. Az ÉDV-nél az SAP PM és SAP ISU modulok is működnek.

• Az ÉRV műszaki rendszere a Rudas & Karig MIR rendszere, a gazdálkodási rendszere jelenleg a Libra. Az SAP rendszer nincsen bevezetve.

• A TRV-nél nincs speciális műszaki rendszer, karbantartási rendszer. (papír alapon kerülnek rögzítésre a karbantartási események, az elszámolás a Libra rendszerben történik).

A Vállalkozónak az alábbiak szerinti rendszert kell szállítania:

• Átlátható, hosszú távú műszaki rendszer megoldás, amely a speciális vízműves modulokkal integráltan működik. A műszaki modell bevezetésével megvalósuljanak:

o az egységes elszámolási folyamatok, o az egységes műszak releváns költség riportolások, valamint o az SAP rendszer moduljaival történő integrált működés.

• A DMRV-nél, a DRV-nél és az ÉRV-nél a jelenleg használt műszaki rendszereknek meg kell maradniuk, és komplexitásuk, funkcionalitásuk kidolgozottságuk lényegesen nem csökkenhet, továbbá az SAP kapcsolatot költségek nyilvántartásban és az elszámolások tekintetében biztosítani kell.

32

• A TRV-nél a műszaki folyamatok hangsúlyosabb támogatására szükséges az SAP PM modul bevezetésével.

Az ÉDV-nél az SAP PM (karbantartás) modulja jól kidolgozott, ennek megszüntetése a műszaki megoldásban visszalépést jelentene, így ezen megoldásnak is maradnia kell.

11.1.2 TÁMOGATANDÓ FŐ FOLYAMATOK JAVASOLT MEGOLDÁS A megoldás módszerét tekintve alapvetőleg két modellt különítünk el: a vastag és vékony PM műszaki modellt.

• A vastag PM műszaki modellnél az SAP PM karbantartási modulja legyen a műszaki feladatok kiszolgálója és a műszaki feladatokhoz kapcsolódó riportálás a PM, PS és CO modulban valósuljon meg. Ebben a modellben a SAP-ban integráltan működnek a gazdasági és műszaki funkciók (modulok) egyaránt. A vastag PM modell szerint a műszaki törzsadat kezelést és a munkairányítási részt a PM (karbantartási) modul lássa el integrált működésben az SAP rendszer többi moduljával. A víziközmű speciális feladatokat (pl: Labor, Vízbiztonság, Térkép) továbbra is célszoftverek (ahol jelenleg is kezelik őket a Társaságok) végzik a jövőben is, amelyekhez nem szükséges interfész kapcsolat az SAP rendszerrel. A vastag PM modell az alábbi VK társaságoknál kerüljön bevezetésre:

o ÉDV-nél o TRV-nél

• A vékony PM műszaki modellnél is kerüljenek bevezetésre az SAP PM (karbantartás) és PS (Projektrendszer) modulok, de a műszaki feladatok kiszolgálói maradjanak továbbra is a jelenlegi műszaki rendszerek. Az SAP PM és PS modulok ebben az esetben elsősorban költségközvetítő, riportáló feladatokat látnak el.

• A Vékony PM modell bevezetése, integrálása a műszaki rendszerekkel az alábbi cégeknél történjen meg:

o DMRV-nél, ahol a műszaki rendszer a VMTR. o DRV-nél, ahol a műszaki rendszer az OTMR. o ÉRV-nél, ahol a műszaki rendszer a MIR.

• Ezen cégeknél továbbra is a műszaki rendszerek legyenek a vízi közmű rendszerhez tartozó speciális feladatoknak (pl: Labor, Vízbiztonság, Termelés és Térkép) a kiszolgálói.

• Mindkét műszaki modellnek képezze részét a PS modulból hierarchiába rendezett PST elemek használata, költségek elemzése céljából.

A fentiekben meghatározott célokat figyelembe véve az alábbi megoldás Vállalkozói kivitelezése szükséges: Vállalkozó készítsen

• egyrészt egy olyan SAP műszaki megoldást, mely integráltan működőképes a VMTR, OTMR, MIR műszaki rendszerekkel, amely a vékony PM modellnek megfelelően működik,

• másrészt vezesse be az ÉDV-nél és a TRV-nél a vastag PM műszaki modell vízi közmű megoldást, amely, az ÉDV jelenlegi SAP PM műszaki rendszerének logikáját, struktúráját, működését veszi alapul.

33


11.2.1 SAP VK vékony PM műszaki megoldás

VK vékony PM megoldás elemei tartalmazzák:

• Az SAP PM modul alap funkcionalitását és a többi SAP modullal (projektrendszer, kontrolling, eszköz, beszerzés) történő integrált működését.

• SAP PS modul alap funkcionalitását, a PS modulból hierarchiába rendezett PST elemek használatát, költségek elemzése céljából.

• Jelenlegi műszaki rendszerek (VMTR, OTMR, MIR) és az SAP rendszer interfész kapcsolatát.

11.2.2 SAP vékony PM műszaki megoldás a DMRV-nél és a DRV-nél

• SAP- VMTR, SAP - OTMR kapcsolat a műszaki nyilvántartás és operatív munkairányítás és követés terén a jelenlegi VMTR-SAP, OTMR-SAP interfész továbbfejlesztésével.

• OME rendelések megfelelő adatainak leképezése PM rendelések adataira a karbantartási és beruházási tevékenységre vonatkozó, egységes, az SAP-ból történő riporting megvalósítása érdekében.

• VMTR/OTMR munkafolyamatok megtartása (felhasznált anyagok, alvállalkozói szolgáltatások, emberi és fuvarteljesítmények visszajelentése a a jelenlegi műszaki rendszer – SAP munkamegosztás szerint).

• A PM rendelésre történő költségfelosztások PM rendelések elszámolási rendszerének kialakítása az SAP-ban az érvényes CO koncepció alapján, ezen belül gyerek-szülő OME rendelések kezelése.

• Alvállalkozói szolgáltatások szolgáltatás törzzsel való leképezése az SAP-ban kiegészítve a teljesítésigazolással és a VMTR esetében az SAP teljesítésigazolási lap (output) VMTR-nek történő rendelkezésre bocsátásával.

• SAP-hoz nem kapcsolódó VMTR/OTMR funkcionalitás:

Rajzi alrendszer

Termelés alrendszer

Vízbiztonság alrendszer

Labor alrendszer

Villamos energia alrendszer

11.2.3 SAP vékony PM műszaki megoldás – (MIR) ERV -nél

• SAP- MIR kapcsolat kialakítása a műszaki nyilvántartás és operatív munkairányítás és követés terén.

34

• MIR munkalapok megfelelő adatainak leképezése PM rendelések adataira a karbantartási és beruházási tevékenységre vonatkozó, egységes, az SAP-ból történő riporting megvalósítása érdekében.

• Felhasznált anyagok, alvállalkozói szolgáltatások visszajelentése az SAP-ban, emberi és fuvarteljesítmények visszajelentése a MIR-ben, adatok átadása a másik rendszernek.

• A PM rendelésre történő költségfelosztások és a PM rendelések elszámolási rendszerének kialakítása az SAP-ban az érvényes CO koncepció alapján.

• SAP-hoz nem kapcsolódó MIR funkcionalitás

rajzi alrendszer

termelés alrendszer

vízbiztonság alrendszer

labor alrendszer

11.2.4 SAP VK vastag PM műszaki megoldás

• Műszaki objektumok törzsadatainak kezelése az ÉDV-nél alkalmazott struktúrának megfelelően.

• Karbantartási és beruházási tevékenység kezelése PM rendelésekkel a karbantartási és beruházási tevékenységre vonatkozó, egységes, az SAP-ból történő riporting megvalósítása érdekében.

• Felhasznált anyagok, alvállalkozói szolgáltatások visszajelentése az SAP-ban standard módon.

• Emberi és fuvarteljesítmények visszajelentése munkalapokon az ÉDV-nél alkalmazott, fejlesztett megoldás szerint.

• A PM rendelésre történő költségfelosztások és a PM rendelések elszámolási rendszerének kialakítása az érvényes CO koncepció alapján.

• Jelenlegi fejlesztett Villamos energia és Termelési modul funkcionalitásának megtartása az ÉDV esetében; Kontrolling feladás átalakítása az érvényes CO koncepciónak megfelelően.

SAP PS modul alap funkcionalitásának kialakítása, a PS modulból hierarchiába rendezett PST elemek használata, költségek elemzése céljából.

11.3 FELTÉTELEZÉSEK, KIZÁRÁSOK A Vízi Közmű műszaki rendszerének bázisa SAP PM modullal lesz megvalósítva. A műszaki template-nél megkülönböztetünk a fent említett 2, a Vállalkozó által megvalósítandó megoldást.

Így az SAP oldaláról alapvetően két műszaki megoldás lesz bevezetve az 5 cégnél. A műszaki követelmény megvalósítása nemcsak az SAP PM modul bevezetését jelenti a

35

Vállalkozó számára, hanem a T-Systems rendszereivel, a VMTR-vel és OTMR-vel, továbbá Rudas & Karig MIR rendszerével együtt kell dolgozni közös munka keretében, amelyekhez a Vállalkozónak ki kell építeni az összes SAP oldali interfacet és végre kell hajtania a külső rendszerek szállítóival az interface és folyamati end-to-end teszteket.

12. MIGRÁCIÓ

12.1 MIGRÁLANDÓ ADATOK KÖRE A standard SAP ISU felépítésének megfelelően az alábbi adatok migrálása a Vállalkozó feladata:

• Címtörzs (helységkódokkal)

• Üzleti partner adatok (alapadatok, címek, bankszámlaadatok, azonosítók, szerepek)

• Szerződéses folyószámla (folyószámlakezelés adatai)

• Szerződés (közüzemi szerződés adatai)

• Bekötés (elszámolással kapcsolatos adatok)

• Csatlakozási objektum (a fogyasztási hely csatlakozásának pontja)

• Fogyasztási hely (a fogyasztás helye)

• Mérő - és készülékmenedzsment, (vízmérő és esetleg egyéb berendezések adatai és helyének adatai)

• Beszerelés összesen

• Készülék csoportosítása

• Mérőcsoport

• Készüléktípus

• Készülékhely

• Készülék

• Nyitott FICA tételek

• Köteg

• Leolvasási egységek

• Periódusfogyasztások

• Járatsorrend (ÉDV esetében) A migráció során betöltendő adatok biztosítása (előállítása) és előzetes tisztítása a Megrendelő feladata. A migrálandó adatkörökhöz tartozó betöltő struktúra megadása a Vállalkozó feladata, mely a megvalósítás során történik meg.

36

12.2 MIGRÁCIÓS MÓDSZERTAN Elvárás, hogy a migráció az alábbi módszertan szerint történjen:

1. A szakterületi tanácsadók által fel kell mérni a társaságok folyamatait és

törzsadat szerkezetét.

2. Az előzőek ismeretében meg kell határozni a forrásrendszerekből szükséges adatokat, valamint azok struktúráját. Migrálandó adatkörök esetében egy közös struktúrát kell kialakítani, mely mind az öt társaság számára előírja a migrációs állományok tartalmi elvárásait. Az egyes társaságok kompetenciája az adatok kinyerése saját rendszereikből.

3. A migrációs eszköznek az SAP standard ISU migrációs eszközét, az EMIGALL-t kell használni.

4. Ki kell alakítani a migrációs vállalatokat, fel kell építeni az EMIGALL objektum struktúráját, illetve fel kell paraméterezni az egyes objektumokat.

5. El kell készíteni egy előtétprogramot, amely a forrásrendszerekből kapott adatokat feldolgozza, szükséges átkódolásokat elvégzi, é s a rendszerbe való betöltéshez szükséges, származtatott adatokat előállítja, valamint előállítja az EMIGALL objektumok input állományait.

6. A felépített migrációs vállalatokban minden objektumból 1-1 próbamigrálást kell végrehajtani dummy tesztadatokkal.

7. A forrásrendszerekből származó éles adatokkal teljeskörű próbamigrációt kell végrehajtani.

8. A próbamigráció kiértékelése:

Tömeges ellenőrzés szükséges a számlázhatósági megfelelésre vonatkozóan, egyéb tekintetben legalább szúrópróba szerű manuális ellenőrzés az elvárás. A feltárt hibák típusosan az alábbi kategóriákba sorolhatóak:

o migrációs hibák – javítandó

o adat inkonzisztenciából adódó hibák – szakterületi tanácsadók és a társaságok adott felelősével a hiba jellege alapján javítandó (template rendszerben vagy a társaság a forrásrendszerben)

o forrásadat hiba – visszacsatolás a társaságoknak; javítandó a forrásrendszerekben

9. Tömeges folyamatteszteket is végre kell hajtani: migrált adatokkal funkcionális és integrált teszteléseket is kell végrehajtani a Társaságoknak, melyet a Vállalkozó támogat.

Kiértékelés: a hibák jellegétől függően a szakterületi tanácsadók és szükség szerint a társaságok felelőseinek bevonásával történik a javítás (template rendszerben vagy a társaság a forrásrendszerben).

10. Több próbamigrációt kell végrehajtani az éles migráció előtt. A 8. ponttól ismételve előzetesen 3-4 tesztkörrel (ismétléssel) kell számolni.

37

12.3 FELTÉTELEZÉSEK, KIZÁRÁSOK

Az alábbi feltételezések érvényesek a megvalósítási terjedelemre:

1. A társaságok címtörzsei egységes kódolást kell, hogy kapjanak. Ezt előzetesen a társaságoknak el kell végezni.

2. A migráció folyamatában nincs adattisztítás, azt csak a társaságok saját forrásrendszereikben végeznek, végezhetnek.

3. A társaságok a Vállalkozó által megadott, az öt társaság esetében egységes struktúrában biztosítják a forrásadatokat.

4. A próbamigrációk során éles rendszerből vett adatokkal kell tesztelni.

5. A próbamigrációkat a template rendszer éles másolatában szükséges végezni.

6. A próbamigrációkhoz – Megrendelői oldalon - rendelkezésre fog állni bővített infrastruktúra.

7. Az egyes objektumok azonosítói változni fognak, ezért azok külső hivatkozásait majd módosítani kell.

38

13. ÜTEMEZÉS

A Vállalkozó feladata, hogy az implementáció elején bevezetési ütemtervet készítsen, azonban annak igazodni kell az alábbi mérföldkő határidőkhöz. A közmű template megoldásnak – az integrált működés megvalósítása miatt - együtt kell élesben indulnia az ERP template megoldással. A közmű template megoldás, valamint a társaságok éles indulása szempontjából a következő két éles indulási ütemezés lehetséges. (T: Szerződés hatálybalépésének napja)

Teljesítési ütem

Teljesítés tárgya

Éles üzembe

állítás

1 hónapos

kiemelt

támogatás

vége

Fizetési

Mérföldkő

I. részteljesítés Közmű template

rendszer tesztelésre

átadása a DMRV

rendszerében

- - T + 4 hónap.

II. részteljesítés Közmű template

kialakítása a DMRV

rendszerében, DMRV

adaptálása a közmű

T + 6 hónap

T + 7 hónap

T + 7 hónap

III. részteljesítés ÉDV közmű

komponensek

megvalósítása

DRV közmű

komponensek

T + 9 hónap

T + 10 hónap

T + 10 hónap

Végteljesítés ÉRV és TRV Társaságok

közmű komponenseinek

megvalósítása

T +11 hónap

T + 11 hónap

T + 12 hónap

leírás u alapú ügyfélszolgálati rendszer megvalósítása ...±szaki leírás.pdfrendszer...

Documents