2 az 1-ben MT adattárházak egyesítése Koncz Béla, IQSymposium 2011.04.06
Tartalom Háttér Felmérés Alternatívák és elvárások Tervezett scope és ütemterv Megvalósítás Statisztika Tapasztalatok Sikerkritériumok Mit kerüljünk 2
A kezdetek üzleti háttér A történet 2006-2007-re nyúlik vissza A Magyar Telekom két meghatározó adattárház rendszert üzemeltet, mobil oldalon a DIAMOND, vezetékes oldalon az MDSS rendszer szolgálja ki az alapvető információszolgáltatási igényeket. Üzleti környezet Leányvállalatok egybeolvadása Üzletágak kialakulása Szervezeti integrációk Egységes bolthálózat Szinergia lehetőségeinek kihasználása Integrált termékek iránti igény IT területtel szembeni elvárások Költségcsökkentés (DT, MT) IT rendszerek hatékony üzemeltetése Architektúra egyszerűsítése CRM rendszer integrációja Közös kampányrendszer kialakítása Integrált termékek lehetőségének megteremtése Cél: MT szintű egységes, integrált adattárház létrehozása és működtetése 3
Felmérés az IQSYS segítségével Az IQSYS, mint független szakértő, tanácsadó bevonásával 2007. októberében indult, időtáv: 2 hónap Cél: koncepcionális terv és roadmap megalkotása Top-down szinten meghatározni az adattárház konszolidáció megvalósításának módját Javaslat a párhuzamos funkcionalitások integrációjára, az architektúra egyszerűsítésére Keretet biztosítani a prompt üzleti igények kielégítésének rövid távú adattárház fejlesztéseihez Meghatározni a konszolidáció megvalósításának ütemét Már az elején világossá vált: úttörő munka előtt állunk 4
Operational layer Primary layer Business layer Riport layer Az én váram és a te várad hasonlóak? M D S S End- user riportok OLAP kockák, Adatpiacok MDSS csillag modell Állomásoztató terület Forrásrendszer history ADATFORRÁSOK D I A M O N D End- user riportok OLAP kockák, Adatpiacok DW mag Stage Exprod ALAPVETŐ JELLEMZŐK: 1. Az adattárház rétegek egymásnak megfeleltethetőek, kialakításuk mégis különböző. 2. Mindkét DW normalizált adatmodellre épül, amelyre denormalizált réteg, aggregátumok, csillagsémák ülnek rá. 3. Mindkét DW riporting rétege erőteljesen Cognos szoftverek használatára épít. Diamond oldalon erős az adatbázis viewk-on keresztüli és közvetlen üzleti adatelérés. A napi üzleti igényeket SMS, e-mail riportok támogatják. MDSS oldalon e-mail riportok és a DW terület által kiszolgált ad-hoc lekérdezések magas száma jellemző. 4. A két adattárház között az üzleti igények mentén már kialakult adatáramlás. Az adatáramlás fő iránya az MDSS-től a Diamond felé, a Diamond publikál. Fő területek: Sales KPI-ok, Kampány kiszolgálás, Cross-sell/cross-brand riportok 5. Megjelent párhuzamos adattárolás és adatfeldolgozás is a T-Online adatok tekintetében
Alternatívák 1. Új DW Új adattárház építése. A meglévő DW-k mindaddig üzemelnek amíg az új át nem tudja venni a helyüket. Az üzleti igények kielégítése igényli a meglévő DW-k továbbfejlesztését is, az új fejlesztése mellett. 2. Migráló 3. Szintépítő Az egyik adattárház adatainak a másik adattárházba migrálása. A továbbélő bázis adattárház adatmodellje lényegileg nem változik, alkalmas arra, hogy felvegye a megszűnő donor DW adatait. A migráció fokozatos, az üzleti területek integrált igénye miatti fejlesztés csak a továbbélő DW-ben zajlik. Mindkét adattárház tovább működik, az integráció egy integráló rétegben valósul meg. Az integráló réteg fejlesztése párhuzamos mindkét DW fejlesztésével, üzemeltetésével. 4. Egyesítő A továbbélő bázis adattárház adatmodelljét bővítjük, alkalmassá tesszük a donor adattárház adatainak, tudásának beépítésére és az integráció által támasztott követelmények leképezésére. Fejlesztés egy idő után már csak a bázis DW-ben történik, a donor fokozatosan megszűnik. 6
Alternatívák értékelése Üzleti igények Kockázat Szakmai érvek Időtáv Beruházás Költségmegtakarítás 1. Új DW Nincs igény Redundancia > Átfutási idő < Rugalmasság Hosszútávon legjobb Minimum 3 év Magas > 3 év 2. Migráló Információ vesztés Egyesítőbe átmehet Egyik sem Alkalmas rá 2 éven belül Közepes < 1 év 3. Szintépítő Új business layerben Redundancia > T2M Hosszútávon bonyolult < 1 év Rövidtávon + Költség 4. Egyesítő Megfelelő layerben Harmonizáció Redundancia Értékek megőrzése 2 éven belül Közepes < 1 év 7
és amit választottunk Üzleti igények Kockázat Szakmai érvek Időtáv Beruházás Költségmegtakarítás 1. Új DW Nincs igény Redundancia > Átfutási idő < Rugalmasság Hosszútávon legjobb Minimum 3 év Magas > 3 év 2. Migráló Információ vesztés Egyesítőbe átmehet Egyik sem Alkalmas rá 2 éven belül Közepes < 1 év 3. Szintépítő Új business layerben Redundancia > T2M Hosszútávon bonyolult < 1 év Rövidtávon + Költség 4. Egyesítő Megfelelő layerben Harmonizáció Redundancia Értékek megőrzése Bázis adatmodell: Diamond 2 éven belül Alkalmassá kell tenni a vezetékes portfólió adatainak befogadására. Közepes < 1 év 8
Döntési szempontok mi szólt a Diamond mellett? Technológiai szempontok Diamond technológiája egységesebb, kevesebb eszköz használatát kell megtanulni (járulékos képzési költség is kisebb) A kevesebb, egyszerűbb funkciót tartalmazó adattárházat érdemesebb donorként a nagyobb adattárházba migrálni. Fő ok a Diamond magasabb szolgáltatási szintje: A Diamond elfogadottan autentikus információ-forrás, az üzleti elvárásokhoz, a jövőbeni információs igényekhez a Diamond áll közelebb. A Diamond információs terjedelme szélesebb. CRM, Kampány, Cross típusú riportok szempontjából a Diamond a publikáló oldal. Másik irányú migráció nagyobb költségekkel jár. Hosszú távú üzleti haszonelemek 9
Az integrációval szemben támasztott követelmények, alapelvek 1. Az integrált adattárház MT szinten az egyetlen, autentikus információforrás legyen. One of Truth elv érvényre juttatása. 2. Az integrált adattárháznak mind a T-Mobile, mind a T-Home, mind a T-System márkák és valamennyi üzleti terület által meghatározott üzleti igényeket ki kell szolgálnia. A T-Online-nak és a T-Kábelnek nem volt adattárháza. 3. Meglévő értékek megtartása és hatékony felhasználása. 8-10 éves fejlesztési, üzemeltetési tapasztalat mindkét oldalon. Kiváltandó riportok, adatszolgáltatások validálása indokolt. 4. Üzletmenet-folytonosság fenntartása. A meglevő adattárházak szolgáltatásaira folyamatosan szükség van. A szolgáltatások kiváltása csak jó minőségű szoftverfejlesztés és tesztelés után történhet meg. 5. Új igényeket az integráció feladatával párhuzamosan ki kell elégíteni. Harmonizáció az integrációs feladatokkal. Indokolt redundancia bevállalása. 6. Fokozatos, organikus fejlődés. 7. Az integrációnak a költségek csökkenésével és a hatékonyság növekedésével kell együtt járnia. 10
Milyen előnyökkel jár az üzlet számára? 1. Konszolidált ügyfél- és terméknézet. Minden Magyar Telekom ügyfél (szerződés) a hozzá kapcsolódó információkkal egy rendszerből, összehasonlítható módon elemezhető. xplay riportok megalapozása, mobil és vezetékes aspektusok értelmezettek, lekérdezhetőek. 2. One of Truth elv érvényre jut. 3. T-Pontok teljesítménye egy adatkörnyezetből, egységes szerkezetben mérhető, kimutatható. 4. T-Home ügyféljellemzők normalizált, hystorizált tárolásának kialakítása. 5. Integrált analitikus és operatív rendszerek egy DWH-ból kapnak analitikus információt Fejlesztési, átfutási idők rövidülnek 6. Az üzleti felhasználók egykapus kiszolgálást kapnak, az igénymenedzsment integrált. 7. Duplikált fejlesztések elkerülése. Fejlesztési költségek csökkenése T2M csökken 11
Tervezett nagyvonalú scope és roadmap 2008 Q1 Q2 Q3 Q4 Cognos (DM) 2009 Q1 Q2 Értékesítés Terv Ügyfél Hívásforgalom Reorganizálás - szervezet - technológia Hardver bővítés 12
és ami megvalósult scope Adatmodell, adatbetöltési logika, információszolgáltatás Adatkörönként ütemezett fejlesztés Visszamenőleges adatfeltöltés Riportok, adatszolgáltatások portolása, integrációja Egységes Adattárház portál Új, közös portál Cognos licencek konszolidációja Cognos v8 upgrade Közös DW platform Új hardware (Alpha --> Itánium) Új operációs rendszer (True64 --> HPUX) Oracle upgrade (9i --> 10g) Fejlesztési módszertan egységesítése Inkrementumok kiterjesztése MDSS-re (igénymenedzsment és az alkalmazott DW fejlesztési módszertanok). 13
és ahogy megvalósult roadmap 2008 2009 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 I. Fázis Integrált ügyféladatok Integrált szerződések Integrált értékesítési adatok Integrált Portál & Cognos 8v Integrált hűségnyilatkozatok II. Fázis Integrált szolgáltatások OSS havi számlák OSS belépési díjak & BENT III. Fázis Siebel SR & Adatszolgáltatások III OSS CDR IV. Fázis ICBS, ICPS, OSS főkönyv/ reklamáció, Kintlévőség DM ICCM & BSS Adatszolgáltatások IV HW&SW DWPROD EXTPROD Felmérés & Tervezés Implementáció & Tesztelés Üzembe állítás & Migráció Adatkör mérföldkövek 14
és ahogy megvalósult migráció Magas kockázat minden változik! Hosszú előkészületi munka fontossága Az új hardware és DB előkészítése Alkalmazás tesztek Performancia teszteket (funkcionális és másolás miatt) Read only terület előmigrálása, online terület minimalizálása Migrációs scriptek és keretrendszer elkészítése, tesztelése Migráció két lépésben: DWPROD: 2009.10.22 10.26 (hosszú hétvége, teljes leállás) EXTPROD: november folyamán (nem kritikus, transzparens módon) Kapcsolódó rendszerek számára cél a transzparencia biztosítása (jogosultság és fizikai elérés felülvizsgálata szükséges) Átállás utáni performanciális problémák egyedi kezeléssel kerültek megoldásra. 15
Scope és ütemterv változás okai és hatása Menedzsment jóváhagyás elhúzódása miatt későbbi kezdés. Világgazdasági válság hatása: Egész DT szinten beruházások visszafogása HW beszerzés későbbre ütemezése Határidő: + 6 hó Fejlesztések ütemének lassítása Visszamenőleges adatbetöltés nem várt hatásai: Forrásrendszerek minőségi problémái History képességek hiánya History adatbázisok és keretrendszer megalkotása Capex: + 25 % Külön migrációs scriptek megírása Performanciális problémák T-Kábel adatkörök bővülése: Kampánycélok miatt a 2-es fázis prioritása megnőtt ROI: 3 -->3,7 év 16
Elvégzett munka számokban Funkcionalitás Migráció közel 2 év 20-25 ember közreműködése 4000 enap fejlesztés 13 forrásrendszer 56 adatkör 300 tábla 350 programkód 100 view 100 riport és kocka (40 törölve) 3 milliárd rekord betöltése 6 TB adat ROI < 4 év közel 1 év előkészület 22 TB adat + index 1200 adattábla 3200 adattábla index 7000 felhasználói tábla 5200 felhasználói index 17
Sikerkritériumok Megalapozás Teljeskörű felmérés Alapos tervezés és megfelelő ütemterv Fázisok meghatározása prioritással Kockázatok felmérése Vezetői támogatás megszerzése (ROI + üzleti előnyök) Felhasználók bevonása Riportok, adatszolgáltatások revíziója Közreműködés a hibák, inkonzisztencák felderítésében Üzleti definíciók felelősei Múltbeli adatok meghatározói Kész szolgáltatások átvétele Építkezés Ütemterv figyelemmel kísérése Időkeretek szigorú tartása Fázisok tapasztalatainak felhasználása Tesztelés, minőségbiztosítás Kockázatok kezelése Harmonizáció a BAU feladatokkal Duplikációk minimalizálása Üzleti alkuk Munkacsoportok Kapcsolódó rendszerek Transzparenciára való törekvés Időben be kell vonni őket Támogatás nyújtása 18
Sikerkritériumok a jó csapat elengedhetetlen Diamond jellemzők Erős belső kompetencia Szoros belső együttműködés Saját módszertan, folyamat Külső erőforrás: Rugalmasság Minőség, megbízhatóság Kihívások Szervezeti integráció Módszertan, folyamatok oktatása Motiváció Félretenni az előítéleteket Energizálni a csapatot Bevonás 19
Intelmek Funkcionalitást nagy mértékben befolyásoló üzleti igények korlátozása Negatívan érinti a megtérülést Előre nem látható kockázatokat viszünk be Önmagában is nagy projektről van szó, kvázi új adattárházat hozunk létre Teljeskörű felmérés hiánya Erősen befolyásolja a megtérülést Extra terhet róhat az üzemeltető csapatra Ne gondolkozzunk big-bam módszerben Sokára lesz eredmény Kockázatos a kimenetel 20
Az MDSS nyugdíjazásának üteme Funkciók, feladatok 2010 2011 Státusz Adatelérés 01 02 03,,, 12 01 2010.01 havi adatok betöltése MDSS adatbetöltés teljes funkcionalitással üzemel. 02.20 2010 előtti adatok elérhetőek a felhasználók számára Adatbetöltés leáll. MDSS szerverek és adatbázis csökkentett rendelkezésre állással üzemelnek. 02.28 02.20 2010 előtti adatok elérhetőek a felhasználók számára Kiváltott adatbázisok, valamint a teszt és fejlesztői környezet leállításra kerül. Az MDSS továbbra is csökkentett rendelkezésre állással üzemel 03.01 12.31 2010 előtti adatok elérhetőek a felhasználók számára MDSS végleg leállításra kerül 01.03 adatok nem elérhetőek a felhasználók számára 21
Köszönöm a figyelmet! 23