JAZZ - távközlési üzleti támogató rendszer (BSS)

A JAZZ rendszer a Westel 900 mobil távközlési vállalat belső fejlesztői csapata által készített ügyfélinformációs és számlázási szoftver rendszerek összessége. A fejlesztés 1996-ban kezdődött és 1998. augusztus 10-én ment élesben. Az évek során a szoftver modulok halmaza folyamatos fejlődésen ment át és a mai napig használják a Westel 900 jogutód vállalatai.

Kezdetben egy mobil távközlési vállalat ügyfél folyamatait támogatta. 2007-től a T-Mobile (Magyar Telekom Csoport), MATÁV és T-Online jogi összeolvadását követően a vezetékes és internet távközlési szolgáltatások értékesítésére is felkészítették.

Fejlesztés előzmény története

Kezdetek

Az 1990-és évek közepéig az emberek a telefonra, mint egy helyhez (lakás, üzlet) kötött eszközre gondoltak. 1993-ra a mobil telefónia – azon belül is GSM technológia – globálisan olyan éretté vált, hogy megkezdődhetett a tömeges piaci értékesítés. A mobiltelefonok mérete és ára el kezdett csökkenni nagy szériában jelentek meg a kézben fogható maroktelefonok, mint például az Ericson 198 készüléke. Minden ország sorra írta ki a GSM frekvenciát értékesítő tendereket. Megalakultak az országos lefedettséget kínáló mobil távközlési vállalatok. Így alakult a meg a Westel 900 is.

A Westel 900 alapításakor erősen támaszkodott az 1989-ben alakult, analóg technikával mobil telefon szolgáltatást biztosító Westel Rádiótelefon Kft szakértői gárdájára. Így teljesen nyilvánvaló volt, hogy az a zöldmezős GSM cég informatikájának vezetésére az akkor már több éves mobil számlázó és ügyfélinformációs rendszer tapasztalattal rendelkező Szűcs Józsefet kérték fel.

A cég vezetése extra növekedési potenciált látott a magyar piacban, mivel Magyarországon a vezetékes telefon ellátottság igen alacsony volt. Minden erőforrásukkal a frekvencia pályázatban ígért országos lefedettségű mobil hálózat kiépítésére és az ügyfelek megszerzésére koncentráltak. A távközlési üzlet szabálya szerint a telefonáló ügyfél hozza az árbevételt.

Az ügyfélkiszolgálást támogató (CRM), a havi számlákat előállító számlázó (Billing) és a vállalat irányítási(ERP) szoftver rendszereket is a piacon elérhető legjobb termékekből választotta ki a cég 1993-as indulásakor. Fontos volt a robusztus architektúra és nagy teljesítmény, így került hardver szállítóknak kiválasztásra a Digital Equipment Corporation számítógépei Unix operációs rendszerrel. Fejlesztő eszközként a C és C++ volt a logikus választás. Az adatok tárolására az akkor felfutó Oracle adatbázis kezelőt választották ki a szakértők.

A távközlési számlázó és ügyfélinformációs rendszer esetében koránt sem volt ilyen egyszerű a helyzet. Ez a piac igen éretlen volt 1993-ban. Összesen három lehetséges szállítói alternatíva volt. Alapos vizsgálatok után kiderült, hogy tulajdonképpen egy cégnek van működő és kompromisszumokkal elfogadható rendszere. Ő szállította a Westel 900 első CRM és Billing funkcióit. Itt azért a ma ide értett funkciók töredékére kell gondolni.

Felismerés

A GSM technológia kiforratlan volt. A hálózat és készülék szállítók hónapról, hónapra hoztak ki új fejlesztéseket, amiket részben maguk, részben a távközlési szolgáltatók generáltak. Az ügyfélszám növekedésével megnőtt a terhelés a megvásárolt CRM, Billing rendszereken és.ezzel egy időben teljesítmény problémák jelentkeztek. Közben az üzlet is folyamatosan változott. Ez új üzleti igényeket szült és a meglévő rendszerek folyamatos módosítását eredményezte.

Voltak olyan üzleti igények, amikre a jelenlegi rendszer nem kínált lehetőséget. Például:

• A Westel 900 vezetés igen fontosnak tartotta, hogy az új ügyfél a szerződéskötést követően működő mobil telefonnal lépjen ki a boltból. Így a CRM és Billing rendszereket on-line össze kellett kötni a távközlési hálózat kapcsoló központjával az MSC-vel.
• Megjelentek az első csaló ügyfelek is, akik magas telefon használat után nagy összegű kifizetetlen telefonszámlát hagytak hátra. Így megszülettek azok programok, akik időben felismerték a csaló magatartást illetve segítettek az így keletkező tartozások behajtásában.

Ezeket a programot már a Westel 900 belső IT csapata állította elő közösen az Allround csapatával. Fejlesztői kompetenciák épültek ki az informatikán belül is.

Sajnos a megvásárolt ügyfélinformációs és számlázó program kiforratlan volt. A szállító folyamatos frissítéseket adott ki, aminek hatásként szoftverkrízis állt elől. Az alap rendszerbe csak szaporodtak a hibák és közben az új üzleti igények megvalósítása folyamatosan távolodott.

1996 tavaszán az informatika javaslatot tett egy saját fejlesztésű ügyfélinformációs és számlázó rendszer kifejlesztésére és egy dedikált belső fejlesztési csapat felállítására. A Sugár András által vezetett menedzsment felismerte a helyzet komolyságát. Ahhoz, hogy az ügyfelek minőségi kiszolgálást kapjanak nem elégséges

• a hálózat folyamatos fejlesztése lefedettség és kapacitás terén valamint
• az új ügyfelek megszerzése

A minőségi ügyfélkiszolgáláshoz és a közép és hosszútávú tervek megvalósításához elkerülhetetlen egy stabil, robusztus informatikai háttér, ami a változó piaci igények és törvényi környezet szerint, alacsony költséggel, gyorsan tovább fejleszthető. A piacon rendelkezésre álló rendszerek nem voltak képesek ezt az elvárást teljesíteni. Ezért egy igen merész döntésre jutott a menedzsment: elfogadta Szűcs József javaslatát és a Westel 900 saját ügyfélinformációs és számlázó rendszer fejlesztésbe kezdett. A feladattal elvégzésével Szűcs József informatikai igazgatót bízta meg, akire kettős feladat hárult:

• az ügyfelek zavartalan kiszolgálása a meglévő rendszerekkel, miközben az üzleti és jogi környezet változik és
• felállítani egy zöldmezős szoftverfejlesztő csapatot, ami képes leszállítani egy szoftver csomagot a folyamatosan változó üzleti folyamatoknak megfelelően.
  • Az új rendszer képes legyen kiváltani a meglévő rendszerhalmazt.
  • A meglévő adatok teljes migrálásra kerüljenek az új rendszerbe.
  • Végül a meglévő rendszerek teljes kivezetésre kerüljenek.

Így két szervezeti egység került kialakításra

1. IT alkalmazás üzemeltetési osztály – Kiss László Gyula vezetésével
2. IT fejlesztési osztály – Merényi András vezetésével

A fejlesztendő programcsomag a JAZZ nevet kapta a projekt indulásakor.

JAZZ általános információ

Célok

• Röviden a cél az volt, hogy az új informatikai megoldás képes legyen dinamikusan, rövid határidőre az üzleti célokat követve változni. Ha kell, akár hétről hétre új informatikai képességek álljanak az üzlet rendelkezésére. Manapság erre a kérdésre az agilis fejlesztési módszertanok biztosítanak eszköztárat. Az 1990-es évek második felében a felálló fejlesztő csapatnak kellett az elvárt igényeknek megfelelő szoftverfejlesztési módszertant kialakítani a rendelkezésre álló technológiai megoldásokból.

Verziók

JAZZ rendszer folyamatos fejlesztés alatt áll az 1998-ás indulás óta. Az alkalmazott technológiák szerint a következő verziókat különböztetünk meg.

• 1.0 Kliens – szerver architektúra (1998-2000)
• 1.3 Háromrétegű architektúra (2000-

JAZZ Architektúra

Adatbázis

Az architektúra központi eleme a közös adatmodellen alapuló adatbázis volt, amit az összes modul használt. Minden érintett üzleti folyamat ebbe az adatbázisba tárolja le az adatait. Egy üzleti információnak, egy informatikai adat felel meg, ami rendszer független. A program modulok az egymás közti kommunikációban egy közös leíró adatstruktúrát használnak. Nincs adattranszformáció és és nincsenek technológiát váltó interface-ek a rendszer modulok között.

Szoftver Architektúra

Az üzleti folyamatok felhasználási módjának függvényében két architekturális tömb került megtervezésére:

1. Felhasználói interakcióval rendelkező üzleti folyamatok architektúrája
2. Tömeges adatfeldolgozást végző automatikus üzleti folyamatok architektúrája

Felhasználói interakcióval rendelkező üzleti folyamatok architektúrája

A felhasználói interakcióval rendelkező üzleti folyamatok a rendszerben tárolt ügyfélkép módosítását végzik. Ide tartoznak az értékesítési, marketing, ügyfélszolgálati, szolgáltatás módosítási, ügyfél pénzkezelési és behajtási folyamatok, amik végül is az egyik bementi adatforrásai a tömeges adatfeldolgozást végző automatikus üzleti folyamatoknak.

Az interakcióval rendelkező üzleti folyamatok architektúrája a különböző verziók között komoly változáson ment keresztül.

Kliens – szerver architektúra

A zöldmezős fejlesztés architektúrája a 90-es éve népszerű elvek szerint történt:

• A végfelhasználó által használt felhasználói felület a Centura kliens tartalmazta az üzleti logikával együtt. Ez a felhasználó gépére telepített futtatható programok csomagját jelentette. A JAZZ esetében több kliensekről kell valójában beszélni, mivel a különböző üzleti területek igényei más-más modulban valósultak meg.
• A szerver jelen esetben adatbázis szervert jelentett, ahol a kliensek tárolták az adataikat. Egy átmeneti időszakban az adatbázos szerver PL/SQL eljárásokban üzleti logikát is tartalmazott .

Többrétegű architektúra

Az indulás utáni években az üzemeltetési tapasztalatok alapján az IT csapat szembesült a kliens – szerver architektúra ma már iskola példának számító tulajdonságával. Minden egyes kliens egy elő kapcsolatot tart fenn az adatbázis szerveren. Ezen adatbázis kapcsolatok szerver oldali erőforrás igénye lineárisan nőtt a rendszert használó felhasználók számával. Miközben egy kapcsolat a teljes kapcsolati idejének töredékében végzett valós adatbázis műveletet (keresés, adat manipuláció) azaz tulajdonképpen ideje javában munkára várt. A nyitott kapcsolatok – függetlenül aktivitásuktól – folyamatosan terhelték az adatbázist. Ez szerver oldali performanciális kihívásokhoz vezetett.

A problémára a három rétegű technológia kínált választ. A következő rétegekből épült fel esetünkben:

• Megjelenítési réteg – Itt a korábbi Centura kliensek maradtak. De az üzleti logikát kiköltöztették belőlük.
• Alkalmazás szerver réteg – Az alkalmazás réteg egy új réteg, ahol az üzleti logika újra fejlesztésre került. Az alkalmazás réteg feldolgozta a kliensek felől érkező kéréseket és eljuttatta az adatbázis szerverhez és az adatbázis felől érkező válaszokat feldolgozva tovább küldte a kliens felé annak elvárásai szerint. Az alkalmazás szerver réteg rendelkezett egy adatbázis kapcsolat pool-al, ahonnan az adott pillanatnyi adatkezelési kéréshez vett igénybe egy-egy kapcsolatot. A kapcsolatok az alkalmazás és adatbázis réteg közti adatcseres után azonnal felszabadultak. Ezzel sikerült elérni azt, hogy adatbázis szerverek élő kapcsolatainak száma több nagyságrenddel csökkent.
• Adatbázis réteg – Az adatbázis réteg szerepe nem változott lényegesen a kliens-szerver architektúrához képest. A kliensek helyett az alkalmazás szerver réteg kapcsolódott az adatbázishoz. Ez viszont az adatbázis szempontjából lényegtelen.

Tömeges adatfeldolgozást végző automatikus üzleti folyamatok architektúrája

Az ügyfél szolgáltatás használata és az ügyfélkép együttesen táplálják adattal az automatikus üzleti folyamatokat. Ezen folyamatok központi elemei a hívás árazás, számla készítés és kiküldés folyamatai, amik végül is egy távközlési szolgáltató bevételnek szinte egészet biztosítják.

Tömeges adatfeldolgozást végző automatikus üzleti folyamatok architektúrája az évek során nem sokat változott. Az elején kellett a megfelelő performanciát biztosító eszközöket kiválasztani, amit a maximális piac – azaz a lakosság – méretéhez kellett konfigurálni. Hiszen ezekben a rendszerekben a havi több tízmillió adatrekord feldolgozása elvárás volt már az ezredfordulón is.

Ezek a programok nagy központi Unix szerveken futottak C (programozási nyelv) és Pro*C programcsomagok alkotják a folyamatok gerincét.

Alkalmazott módszerek

Adatbázis modellezés

A fejlesztés egyik kulcs pontja a közös adatbázis modell volt, ami a fizikailag egy Oracle relációs adatbázisban valósult meg. Addig viszont hosszú volt az út. A fejlesztés során a tervezők először egy logikai adatmodellt állítottak elő. Az adatmodell tervezés az OMT (Object-modeling_technique) objektumorientált fejlesztési módszertan alapján történt. Az így elő álló objektum modell tartalmazott minden adat attribútumot és kapcsolatot. Egyszerűen lefordítható volt az Oracle adatbázis fizikai elemeire, mint táblákra, indexekre, primary és foreign key-re stb...

Modellezésre kezdetekben a Platinum Tecnology Paradigm Plus programját használták. Idővel a modell mérete meghaladta a Paradigm Plus ábrázolási képességét. Így a programtervezők a modellt átmigrálták az IBM Rational Rose UML modellező eszközébe. Ezzel egy időben áttértek az UML modellezés alkalmazására.