5. Rendszerfejlesztési módszerek és modellek

Információmenedzsment, 4. HÉT (7. óra) IT RENDSZEREK FEJLESZTÉSE II

5. Rendszerfejlesztési módszerek és modellek 5.1.

A fejlesztési modellek csoportosítása

Életciklus modellek

  

Klasszikus (egyszerű) vízesésmodell Visszacsatolásos vízesésmodell V-modell

Prototípus (azaz Működő) modellek



Eldobható (throw-away) prototípus: „így nézne ki”

 

Feltáró fejlesztési modell Tapasztalatokon alapuló fejlesztés

Inkrementális fejlesztés (pl. agilis fejlesztés: scrum, kanban) Spirálmodell



kockázatvezérelt modell: teljes kockázat minimalizálása

5.2.

ÉLETCIKLUS MODELLEK

5.2.1. Klasszikus vízesésmodell

     

A legegyszerűbb vízesésmodell A fázisok megléte, a fejlesztési lépések egymásutánisága Nincs visszalépési lehetőség az előző fázisra Igen pontos elvárások ismeretében alkalmazható Nagyvonalú fejlesztési elképzelések esetén nem megoldás Ellentmond az iterativitás elvének – magas kockázat

5.2.2. Visszacsatolásos vízesésmodell

    

Lehetőség van korábbi fázisokhoz való visszatérésre Így kezelhetőbbek a hibák Folyamatos korrekciók – kisebb kitérők Lassabb Csábít a felületesebb átgondolásra, pontatlanabb specifikációra

A fejlesztés vízesésmodellje

5.2.3. Rendszerfejlesztés V-modellje A V-modell lényege, hogy az életciklus modelleknél megismert fázisokat speciális sorrendben, párosával hajtjuk végre: minden fázissal egyidőben elvégezzük annak a fázisnak a verifikációs vagy validációs folyamatának a pontos megtervezését is. Vagyis pontosan fogjuk tudni, hogy egy fázis elvégzésének melyek lesznek a tesztelési lépései, hogyan fogjuk eldönteni, hogy az adott fázisban elkészült produktum megfelelő-e vagy sem. Egy V betű két szára mentén balról jobbra sorrendben felírjuk az elvégzendő feladatokat. Minden bal oldali tevékenységgel egyidőben el kell végezni a vonatkozó tesztelés megtervezését is. Például a követelmények meghatározásával egyidőben ki kell dolgoznunk azt is, hogy az elkészült termékben hogyan fogunk megbizonyosodni arról, hogy a késztermék megvalósítja-e a követelményeket. Ugyanígy, a rendszertervvel egyidőben ki kell dolgoznunk a rendszer tesztelésének a pontos lépéseit, a tartalmi lépésekkel együtt: mit, mikor, milyen sorrendben fogunk majd tesztelni. A lenti ábrákon feltüntetett munkafázisokon tehát egyszerre mindkét oldalon felülről lefelé megyünk végig.

5.2.4. Az életciklus modellek kritikája

   

A vízesésmodellek egymásra épülő fázisokat rögzítenek  Módosítás esetén minden ráépülő fázist újra végig kell csinálni Befejezési kritériumokat kell rögzíteni  Mikor tekintünk befejezettnek egy fázist? (Határidő, pénz, ütemezés) Részletes szabványok, dokumentációk, értékelő megbeszélések Komplex problémák nagyon komplex tervezést igényelne

Az életciklus modellek előnyei:

Világos a tevékenységek struktúrája Követhető, tervezhető a megvalósítás Pontos specifikáció esetén jól működő rendszert kapunk Az életciklus modellek hátrányai:

Nem követik az igények iterációját, nehéz a korrekció Nem ismerhetők pontosan az elvárások, nagy a bizonytalanság Nem biztos, hogy a rendszer ki fogja elégíteni az igényeket (rejtett hibák maradhatnak, a felhasználók aktív részvétele szükséges)

1.4.

Prototípus (Működő) modellek

Prototípus (Működő) modell:

olyan tervezési koncepció, ahol a fejlesztő egy, a valós működést szimuláló, a felhasználó számára (számítógépen) bemutatható modellt, prototípust készít azzal a céllal, hogy a felhasználó véleményezze azt, döntsön arról. Indokolja:

a felhasználói igények pontatlansága, a fejlesztők bizonytalansága Lehetőségek:

Feltáró jellegű prototípuskészítés: a felhasználói igények pontosítására (“móricka rajz”)

Tapasztalatokra (előzményekre) épített prototípus: specifikálhatók az ismert megoldáshoz képesti elvárások A prototípus lehet: 

Papíralapú: “papír-ceruza” modell



Szimulált működés: legfontosabb funkciókra modell



Számítógépes keretrendszer

Prototípus modell

A feltáró és a tapasztalatokon alapuló prototípusok hátrányai:

A prototípus nem tartalmaz minden kritikus elemet, így kulcsfontosságú részek kimaradhatnak Nem szimulálható és nem modellezhető a rendszer elemeinek együttműködése, a megbízhatóság, biztonság, rugalmasság

A prototípusváltozatok nem specifikáltak és nem dokumentáltak A tervezetlenül készített elemek redundanciát okozhatnak, nehezítve a karbantartást és a fejlesztést A prototípuskészítés előnyei:

A legfontosabb funkciók gyorsan rendelkezésre állnak, megvitathatók A termék fejlesztés közben is látható, könnyebben fejleszthető Kisebb az esély, hogy felesleges opció kerül a rendszerbe, ill. felesleges fejlesztés történik.

1.4.1. Életciklus modellek vs. Prototípusfejlesztés Életciklus modellek

Prototípusfejlesztés

A rendszert előzetesen specifikálják

A specifikáció menet közben alakul

Szigorú, bürokratikus rendszer

Rugalmas

A fejlesztés lassú

Gyors

A fejlesztést szakemberek végzik

A felhasználók is nagyrészt végezhetik

Alaposan tervezett, robosztus rendszer

Gyakran ötletszerű, elhamarkodott

A végeredmény professzionális program

Túl sok a hibalehetőség

Jól dokumentált programok

Gyakran hiányos programleírás

Ott alkalmazható, ahol: Átfogó a fejlesztési projekt Nagy mennyiségű adat van Hiba esetén komoly anyagi veszteség

Ott alkalmazható, ahol: Szűk a feladatkör Kevés adat van A programot csak ritkán használják

Életciklus modellt használunk általában a komplex fejlesztéseknél, amit sok száz/ezer felhasználó fog használni vagy sok száz cég megvásárolni, és ahol szigorúan meghatározott technológiai sorrendben kell az egyes szoftverelemeket egymáshoz kapcsolni. A könnyebb érthetőség kedvéért nem szoftveres példát hozva, pl. egy autó, egy mobiltelefon gyártása esetén ilyen technológiai fegyelemre van szükség. Ilyenkor nem lehet tévedni a tervezés esetén, mert akkor több ezer készüléket gyártunk le rosszul. Viszont egy Forma 1-es autó kialakítása abszolút követi a prototípus-fejlesztés menetét: mivel egyszeri termék előállításáról van szó, ezért belefér a folyamatos kísérletezés.

1.5.

Inkrementális fejlesztés

Az életciklus és prototípus modellek előnyeinek ötvözése: kisebb, kezelhető funkcionális egységekre bontás. Az inkrementális fejlesztés lényege, hogy kisebb egységekben, ún. inkrementumokban történik a fejlesztés. A teljes fejlesztés projektjét valamilyen életciklus modell szerint tervezik, de azon belül az

egyes fázisok, inkrementumok tervezése és fejlesztése elsősorban gyors fejlesztéssel, pl. prototípusalapú fejlesztéssel történik. Az autós példánál maradva, az alváz, a motor, a karosszéria kifejlesztése történhet külön-külön prototípus modell szerint, majd ezek egymásra építése történik. A módszer legnagyobb kockázata és hátránya az, hogy az egyes inkrementumokat esetleg nehéz illeszteni az eddig elkészültekhez.

1.5.1. AGILIS termékfejlesztés (SCRUM) Az elmúlt évek legnépszerűbb szoftverfejlesztési módszertana az agilis fejlesztés, azon belül is a SCRUM-nak nevezett módszertan. A SCRUM egy inkrementális típusú fejlesztés, ahol az inkrementumok ún. Sprintekben (futamokban) készülnek. Kétféle ciklus van: a sprintek általában havi, vagy annál rövidebb (akár hetes, kéthetes) munkák elvégzését jelentik, de napi iteráció is van: a naponkénti SCRUM találkozók, ill. megbeszélések szigorúan ellenőrzik az előrehaladást és annak alapján módosítanak az elvégzendő munkákon. A feladatlista elnevezése backlog. Csapat (Scrum Team) - 5-9 főből áll. A csapattagok különféle képességei lehetővé teszik, hogy a feladatot közösen megoldják (fejlesztő, dizájner, tesztelő, ...) Scrum Master - elhárítja az akadályokat, amelyek gátolják a csapatot abban, hogy a futam célját megvalósítsa. Nem szó szerint projektvezető, de ő az, aki jól ismeri a módszertant és egyben tartja a fejlesztést.

1.6.

Spirálmodell

A spriállmodell olyan kockázatvezérelt rendszerfejlesztési megközelítés, ami állandóan a projekt teljes kockázatát próbálja minimalizálni. Olyan fejlesztést jelent, ahol az elemzéstervezés-megvalósítás-értékelés gyors ciklusokban megy végbe, és a következő fázis előrehaladási irányát, feladatlistáját kockázatelemzéssel döntik el.

1.6.1. MVP (Minimálisan életképes termék) A spriálmodell egyik jól ismert megvalósulása az MVP (Minimum Viable Product, magyarul minimálisan életképes termék) módszertan, amit Eric Ries fogalmazott meg a Lean Startup c. könyvében. (Egyúttal a prototípus modell megvalósításának is tekinthető, mert egy leegyszerűsített, legfontosabb funkciókra szorítkozó modellt hoz létre először.) Az elsősorban startup vállalkozások számára javasolt megközelítés szerint nem érdemes azonnal egy teljesen jól funkcionáló, hibátlan terméket drágán elkészíteni, hanem egy olyan gyorsan, olcsón összerakható prototípussal kell kezdeni, ami alapján a potenciális felhasználók megértik a koncepciót, amit tudnak tesztelni, véleményt mondani róla. Íly módon minimalizálni lehet a fejlesztés kockázatát: csak annyit csináljunk meg egyszerre, ami nem jelent túl nagy felesleges munkát rossz visszajelzés esetén. Ahhoz, hogy kiderüljön, mit kell másképp csinálnunk, miben kell a terméket módosítanunk, mérni kell a visszajelzéseket, az adatokat gondosan fel kell dolgozni, annak alapján pedig újra lehet specifikálni a prototípus vagy termék következő verzióját.

Az MVP elvű termékfejlesztés ciklusa:

Forrás: Eris Ries: Lean startup, HVG 2013

PÉLDA: Nagyvállalati fejlesztés: 4 komplexitási szint Példa: http://www.telekom.hu/mobil (Webshop) fejlesztése: 2. Tartalom módosítás (CMS funkció – Content Management System) – bárki az üzleti területen elvégezheti, nem igényel programozást: pl. új termékek és jellemzőik (szöveg, kép., stb.) feltöltése 3. Paraméterezés – főként üzleti elemzők végzik, a felhasználói (üzleti) igények szerint beállítják a paramétereket (pl. hány menüpont ill. almenüpont vagy hirdetés jelenjen meg egy sorban vagy egy oldalon, milyen elrendezésben, stb.). Nem igényel programozást, de egyes esetekben bonyolultabb lehet.

4. Kisebb fejlesztés – például összehasonlítás más készülékekkel (ha ez nincs már eleve beépítve a webshop motorba), vagy egyéb háttérrendszerekkel való integráció (pl. szolgáltatás nyújtás földrajzi információi). Programozást, és emiatt fejlesztési ciklust (tervezés, kivitelezés, tesztelés, stb.) igényel. 5. Nagyobb fejlesztés – nagyobb funkcionális egységek fejlesztése, pl. online ügyfélszolgálat, számlabemutatási és kiegyenlítési funkciók. Komolyabb fejlesztést, beleértve megvalósíthatósági elemzést igényel.

Vállalati Informatikai Működtetési tevékenységek Információmenedzsment, 5. HÉT (9. óra) Ebben a fejezetben az IT menedzsment részletes modelljének a RUN, azaz magyar elnevezéssel MŰKÖDTETÉS fázisát vizsgáljuk. (A “működtetés” és “üzemeltetés” kifejezéseket gyakran egymás szinonimájaként is használják, mivel az angol operations szó mindkét féleképpen fordítható, de a jelen megközelítésben a működtetést tekintjük tágabb fogalmi kategóriának.)

A kifejlesztett, üzemeltetésbe átvett, élesben működő informatikai rendszerek működtetését úgy kell végezni, hogy az megfeleljen az üzleti követelmények alábbi rendszerének. ÜZLETI KÖVETELMÉNYEK rendszere a COBIT (Control Objectives for Information and related Technology) módszertan alapján:







MINŐSÉGI (Quality) o Minőség (Quality) o Költség (Cost) o Szolgáltatás biztosítása (Delivery) – a szolgáltatás alapvetően működjön (pl. a postástól azt várjuk, hogy kiszállítsa a levelet, a webáruháztól azt, hogy online lehessen terméket rendelni.) BIZALMI (Fiduciary) o Hatékonyság és Eredményesség (Efficiency and effectiveness ) – költség- és időhatékony módon történjen a szolgáltatás, minden szereplő számára. A tevékenység céljai teljesüljenek. o Megbízhatóság (Reliability) – a szolgáltatás megbízhatóan működjön, azaz ne legyen sokszor leállás, illetve a vállat szolgáltatási szintet (szállítási idő, stb.) teljesítsék. Minél többször fordul elő „hiba” a működésben, annál kisebb a megbízhatóság. o Megfelelőség (Compliance) – jogi, törvényi előírásoknak való megfelelés. BIZTONSÁGI (Security) - CIA o Bizalmasság (Confidentiality) o Sértetlenség (Integrity) o Rendelkezésre állás (Availability)

A vállalati informatikai működtetési tevékenységeit három csoportba soroljuk:

A) Informatikai szolgáltatások  “Ügyfél”: Vállalat üzleti területei, alkalmazások felhasználói  Egyes rendszerekre, alkalmazásokra, felhasználókra külön-külön vonatkozik B) Üzemeltetés, karbantartás  “Ügyfél”: Informatikai üzemeltetés szervezete  Az összes rendszerre, alkalmazásra (a teljes “informatikára”) egységesen vonatkozik C) IT biztonság és üzembiztonság  “Ügyfél”: Egész vállalat összes szervezete  Az összes rendszerre, alkalmazásra egységesen és külön-külön is vonatkozik (Megjegyzés: az angol Operations szót „működtetés” és „üzemeltetés” szavakkal is fordíthatjuk. Mivel jelen jegyzetben az üzemeltetés fogalmát szűkebb értelemben használjuk, ezért a „működtetés” fogalmat használjuk tágabb jelentésű fogalomként. A vállalati mindennapi szóhasználatban ez a két szó leggyakrabban szinonimaként használatos.)

A) Informatikai szolgáltatások 1. Éles futtatás, munkaütemezés 2. Belső ügyfelek informatikai (sőt: IKT1) kiszolgálása 3. Rendszertámogatás: Help Desk 4. Változásmenedzsment: változtatási igények kezelése

5.2.5. 1. ÉLES Futtatás Futtatás: egy alkalmazás (program) éles működtetése és egyes felhasználói munkák operátorok általi terv szerinti ütemezése és végrehajtása

 

  

Operátori kézikönyvek, utasítások alapján Futtatás módja (automatikus, vagy felhasználói)  Indítási esemény (idő, feltétel)  Futtatás időtartama, “nyitvatartás”  Jogosultságok  Felelős személy Adatállományok kezelése (mentés, helyreállítás, adatmigrálás) SQL leválogatások (elemzések, statisztikák az adatbázisból, adattárházból) Eredmények és azok továbbításának módja

Futtatás: batch-jellegű, vagy interaktív módon Batch: zárás, összesítés, archiválás. Sok ezer-millió tranzakció beavatkozás nélküli futtatása. Operátorok végzik. Pl. sok tízezer giro utalás, vagy hírlevél több ezer ügyfélnek. Interaktív: operátori felületen (“konzolon”) keresztül – egy-egy parancs futtatása

5.2.6. 2. Belső ügyfelek informatikai kiszolgálása      

Személyi számítógépekkel ellátás és beszerzés, telepítés, leszerelés (BYOD: Bring Your Own Device) Szoftverekkel (alkalmazások, irodai szoftverek) ellátás és beszerzés, telepítés, leszerelés Alkalmazás jogosultságokkal való ellátás, megvonás Egyéb eszközökkel (telefon, mobil, táblagép, háttértár, egyéb munkavégzéshez szükséges eszközökkel) való ellátás Nyomtatók, egyes irodai felszerelések biztosítása (pl. központi nyomtatás)

5.2.7. 3. Rendszertámogatás (Help Desk) Feladata: Felhasználói kérdések és problémák azonnali kezelése 1

IKT = Infokommunikációs technológiák, pl. mobiltelefóniát is beleértve

Normál állapot helyreállítása Típusai a probléma nehézsége és a megoldók képzettsége alapján: 1. szintű: Végfelhasználók segítése (Help Desk) - Gyakorlatlan – a nehezebb eseteket továbbadja, folyamati 2. szintű: Alkalmazás üzemeltetési támogatás - Tapasztalt – adott területre specializált, műszaki 3. szintű: Gyártói szintű támogatás - Szakértői – minden problémára, műszaki Haszna: Állásidő csökken, gyorsabb zavarelhárítás Javuló felhasználó-szolgáltató kapcsolat Jobb erőforrás-felhasználás

5.2.8. 4. Változtatási igények kezelése A rendszerek változtatásának (főként: új funkciók bevezetésének) okai:  Új szabályozók, pl. új adónemek  Új szolgáltatások vagy termékek  Változó piaci feltételek és kapcsolatok  Új üzleti célok Feladat: Változtatási igények (demand) kezelése  Változtatási kérések feldolgozása, prioritások meghatározása  Változtatás mértékének és erőforrásigényének rögzítése  A végrehajtás ütemezése, implementáció, tesztelés, átadás IT rendszer képességeinek folyamatos mérése Felhasználói elvárásokkal való összevetés Üzem. költségek 43%-a rendszermódosítás, 17%-a adatformátum változás, 12%-a sürgős korrekció (hibás, nem szándékolt működés); a maradék: karbantartás és új elemek

B) ÜZEMELTETÉSI, Karbantartási SZOLGÁLTATÁSOK (Operations, maintenance) 1. 2. 3. 4. 5. 6.

Eszköznyilvántartás és infrastruktúra menedzsment Rendszerfelügyelet Incidens- és problémakezelés: rendszert ért zavarok elhárítása Verziókövetés, szoftververziók és változatok kezelése Minőségbiztosítás Licenckezelés

5.2.9. 1. Eszköznyilvántartás és infrastruktúra menedzsment Összetett rendszerek: hardver-, szoftveregységek, hálózati kapcsolatok elemeit adminisztrálni kell 1. szint: Eszköznyilvántartás feladata:  Pontos leltár az informatikai vagyonról (mi, hol, hogyan, ki a felelős, mekkora érték, stb.)

 

Gazdálkodás az IT erőforrásokkal Pénzügyi adminisztráció támogatása (értékcsökkenés, leírás)

Eszköze: konfigurációkezelési adatbázis, CMDB (Configuration Management Database) 2. szint: Informatikai infrastruktúra menedzsment (hardver és szoftver konfiguráció menedzsment HCM/SCM) feladatai:  Azonosítás, eszköztérkép, beállítások (paraméterek)  Változtatási jogosultságok, felhasználói jogok, felelősségek  Erőforrás menedzsment. (lásd köv. bekezdés)

5.2.10.  

Erőforrások menedzsmentje

Megelőzés és helyreállíthatóság Elavult technológiák felújítása, pl. szerverek cseréje

Támogató eszközök:   

5.2.11.

Rendszermonitorozó eszközök (input/output kihasználtság, teljesítmény) Terheléskezelő eljárások (múltbéli tapasztalat alapján előrejelez) – egyidejű felhasználásra, egyidejű tranzakciók kiszolgálására vonatkozóan Kapacitáskezelő funkció (jelenben + a bővítés tervezésében is) – tranzakciók és adatok összes volumenére, adatbázisok méretére vonatkozóan

2. Rendszer- és hálózatfelügyelet

Feladatok:

   

A felhasználó és a rendszer közötti kapcsolat monitorozása Incidensek minél gyorsabb detektálása Adatbázis felügyelet (adatmentések, hosszú távú mentések, frissítések, verziókövetés, beállítások) Információszolgáltatás a rendszerfejlesztés tervezéséhez

Hálózatfelügyelet

  

Router, hub, bridge, modem, tűzfal, stb. A hálózati rendszerek igen összetettek, átláthatatlanok Nyilvántartás adatbázis segítségével: elhelyezkedés és kapcsolatok

Számítóközpontok

 

ahol a gépek vannak ahol a felügyelet zajlik – dashboardok-on követhető legyen

5.2.12.

3. Incidens és Probléma-kezelés

INCIDENS MENEDZSMENT  Váratlan hibák, leállások minél gyorsabb észlelése és kiküszöbölése  Gyors javítás, beavatkozás: pl. újraindítással, ideiglenes, áthidaló megoldással (Workaround)  A hiba okának feltárása és végleges javítás elkezdése  Nagyobb károk esetén katasztrófatervnek, üzletmenet folytonossági tervnek alapján (lásd később a biztonságnál) eljárni PROBLÉMA MENEDZSMENT  Váratlan események bekövetkezésének oknyomozása  Múltbéli események visszakereshetősége  Jövőbeli előfordulás megakadályozása, javítás a rendszerben Post Mortem Report: Mi történt és miért történt (Nem csak a hibát, de annak okát is meg kell találni)  Probléma felismerés  Hiba súlyossága, okozott károk  Elhárításáért tett erőfeszítések  Hiba felelőssége (költségek elszámolása érdekében)

5.2.13.

4. Verziókövetés, konfigurációmenedzsment

Problémák: Szoftverváltozatok szolgáltatásainak azonosítása és dokumentálása A frissítések telepítésének kérdése, ha már nincs közvetlen kapcsolat Annak biztosítása, hogy mindenki elvégezze gépén a frissítést Ki a felelős az új verziók és változatok kezeléséért Szoftververziók kontra Szoftverváltozatok Alapállapot – igények – változtatás tervezése – változtatás implementációja – új verziók (új funkció) Ezek eltérő környezetbe kerülnek – szoftverváltozatok (konfigurációk) Beállítás (konfiguráció) kezelés: azonosít, nyilvántart és dokumentál.

5.2.14.

5. Minőségbiztosítás

Hatékonysági és minőségi mutatók követelményeinek és elvárásainak való megfelelés Módszerek: Minőségi kritériumok kielégítését ellenőrző technikák MTBF (Mean Time Between Failure): két meghibásodás között eltelt idő, ami a technikai minőségét méri, MTTR (Mean Time To Repair): javításig eltelt idő,ami az informatikusok hozzáértését jelző mérőszám) Programtechnikai eszközök a gyors hibajavításhoz Matematikai statisztikai eljárások (hiba előfordulás)

Költség-haszon elemzések (mennyire legyen hibatűrő) Tesztelési eljárások: Helyreállíthatósági teszt: hibát generálnak és az automata javítást ellenőrzik Biztonsági teszt: képes-e a szándékos károkozástól védeni Stressz teszt: szélsőséges eseteket szimulál és mér

5.2.15.

6. Licenckezelés

Licencszerződések megkötése: alkalmazás felhasználásának jogi feltételei, körülményei Licencszerződéseknek való megfelelés

     

Felhasználók száma Felhasználók egyidejűsége Processzorok száma Munkaállomások száma Időtartam Földrajzi elhelyezkedés (határokon túlnyúlóan multiknál)

Auditok

 

Manuális Automata (nagy cégeknél)

Komoly büntetések a gyártók részéről, ha kevesebb licencért fizet a felhasználó, mint amennyit

6.

HÉT (11. óra): IT stratégia

Stratégia = Stratégiai cél + Roadmap

Az IT stratégia az IT terület megcélzott jövőbeli állapotának és az oda vezető roadmapnek meghatározását jelenti. Az IT stratégia tartalmi kialakítását jelentősen befolyásolják olyan külső tényezők, amelyek közvetlenül nem IT specifikusak, pl. az üzleti stratégia, a szervezet pénzügyi terve, a vállalati kormányzás (governance) módja, nemzetközi IT trendek, a szervezet (beleértve az IT-t) szakértői, és a folyamatok. A stratégiai cél nem egy homogén céltábla, hanem több szintű célrendszerként tekinthető. Az alábbi modell szerint 5 szintet különböztetünk meg. 1. Alapstratégiai célok, ami a szervezet legfelsőbb szintű üzleti stratégiájából ered: például költséget kell csökkenteni, jobb kiszolgálást nyújtani, hatékonyabb folyamatokat létrehozni. Ezek a célok határozzák meg legfelsőbb szinten az IT stratégiát. 2. Üzleti elvárások: példák: ügyfélközpontúság, elektronikus kiszolgálás, egységes információs bázis, teljes körű kiszolgálás. 3. IT stratégiai célok: az IT legyen rugalmas, olcsó, modern. 4. IT területspecifikus célok: alkalmazásokra, infrastruktúrára, üzemeltetésre, biztonságra, hálózatra, stb. vonatkozó célok 5. IT stratégiai tézisek: a megvalósítandó célok konkrét, letisztult megfogalmazása Az IT stratégia egyszerre jelent egy leszállítandót (dokumentumok körét), másrészt egy folyamatot, ami mentén kidolgozásra kerülnek a leszállítandók.

Melyek a tipikus vállalatvezetői kérdések, amelyekre az IT stratégia kell, hogy választ adjon? Néhány példát itt sorolunk fel: Bevezessünk-e egy új integrált ügyviteli (vállalatirányítási) rendszert? Hogyan erősítsük IT-val a vállalat új marketing stratégiáját? Bevezessünk-e és hogyan online ügyfélszolgálatot? Hogyan tudjuk 20%-kal csökkenteni az üzemeltetési költségeket? Hogyan vezessük be a big data vagy AI feldolgozást? Az IT Stratégia hiányának egyes következményei       

A rendszerfejlesztések nem támogatják a vállalati célokat Nem valósul meg a rendszerek integrációja – dupla munka, pontatlanság, késedelem A folyton változó fejlesztési tervek idő- és erőforrás pazarlók Nem lehet meghatározni az erőforrások optimális szintjét Ellentmondásos, ad hoc vezetői döntések, érvelések Nem valósul meg az egyetértés az IT szakemberek és az üzlet (felhasználók) között Elmaradnak az infrastrukturális beruházások.

IT STRATÉGIA LESZÁLLÍTANDÓK

Az IT stratégia elkészítendő dokumentumai a következők: A) IT stratégia dokumentum (10-20 oldal): IT stratégiai tézisek megfogalmazása, amelyek a célrendszert alkotják, valamint a roadmap magas szintű kibontása, ami a

legfontosabb stratégiai programok és projektek felsorolását, rövid bemutatását jelenti. B) IT stratégiai terv (20-50 oldal): a roadmap részletezése IT területenként: alkalmazások (vállalatirányítási rendszerek, CRM, szakrendszerek), infrastruktúra, hálózat, számítóközpont, stb. területek konkrét programjai, projektjei, amelyek együtt alkotják a stratégiai roadmap-et. C) Implementációs- és költségterv (5-15 oldal): az IT stratégiát megvalósító programok és projektek részletezése: fázisolás, időbeli ütemezés, várható emberi erőforrás és pénzügyi forrás igények és ezek ütemezése. D) Vezetői összefoglaló (2-3 oldal): elsősorban a vállalatvezetők számára foglalja össze tömören, hogy az IT milyen programokon keresztül fog hozzájárulni a vállalati stratégia sikeres végrehajtásához, és ez milyen erőforrásokat igényel.

INPUTOK begyűjtése és elemzése: nem lehet jó stratégiát készíteni, ha nincs megfelelő forrásanyag, amiből elemzéseket lehetne készíteni. A legfontosabb input fajták, amelyek beszerzése szükséges a jelenlegi és jövőbeli állapotok elemzéséhez:       

A rendszerfejlesztések nem támogatják a vállalati célokat Nem valósul meg a rendszerek integrációja – dupla munka, pontatlanság, késedelem A folyton változó fejlesztési tervek idő- és erőforrás pazarlók Nem lehet meghatározni az erőforrások optimális szintjét Ellentmondásos, ad hoc vezetői döntések, érvelések Nem valósul meg az egyetértés az IT szakemberek és az üzlet (felhasználók) között Elmaradnak az infrastrukturális beruházások.

Az inputokat úgy kell feldolgozni, hogy azokból azonosíthatók legyenek az üzleti ösztönzők, másrészt az IT fókuszterületek. Ezek definíciója: Üzleti ösztönző: azok az üzleti célok és célkitűzések, amelyek az üzleti stratégia részeként leginkább az IT-ra épülnek, tehát megvalósításuk leginkább függ az alkalmazandó IT megoldástól. IT fókuszterület: azok az IT területek, amelyek leginkább megújításra szorulnak, mert fejlesztés nélkül jelentős kockázatot jelentenek mind az IT, mind a támogatott üzleti folyamatok számára. Az IT és a vállalati stratégia kapcsolatára 3 forma létezik: 1. Az IT-t nem tartják stratégiai erőforrásnak  IT hagyományos szerepe, használata költségcsökkentő célú  Az IT back office feladatokat lát el  Automatizáló eszköznek tekintik. 2. Az IT a stratégia megvalósításában játszik szerepet (követő)  Az IT csak a meglévő stratégia megvalósításában játszik szerepet.

3. Az IT a jövőbeli stratégia kialakításában is meghatározó  Az IT képes megváltoztatni a termékeket, szolgáltatásokat, a termelés gazdaságosságát (differenciáló szerep)  Alkalmazásával erőfölénybe kerülhet a konkurenciával szemben

Az IT Stratégia V-modellje Mivel az IT általában egy belső szolgáltató funkció egy vállalat életében, ezért úgy kell megalkotni az IT stratégiát, hogy illeszkedjen a vállalat üzleti céljaihoz, stratégiájához. Az IT stratégia V-modellje ezt a célt hivatott teljesíteni. A modell alábbi ábráján bal oldalon az különféle szintű üzleti célokat, mutatókat, programokat és projekteket soroljuk fel, amelyek az üzleti stratégia elemeiként értelmezhetők. Minden egyes üzleti stratégiai elemhez (szinthez) meg kell feleltetni azt az IT stratégiai megoldást.

IT stratégia felépítés

Az IT stratégia dokumentumot alapvetően négy rész alkotja: az üzleti ösztönzők az üzleti stratégia azon kiemelt részei, amelyek leginkább IT támogatásra szorulnak. Ezen ösztönző tehát az üzleti célok és stratégia tanulmányozása alapján határozhatók meg. Az IT fókuszterületek az IT belső folyamataiból adódnak. Mindezek elemzéséből fogalmazhatók meg az IT stratégiai tézisek, amelyek konkrétan megfogalmazzák az IT célokat, megvalósítandó teendőket. Az IT stratégiai roadmap pedig azt sorolja fel, hogy milyen programok, projektek indításával valósíthatók meg a tézisben szereplő célok. Mindezekre az órán bemutatott diák adnak példákat. Az Üzleti ösztönzés (elvárás) fajtái az IT működés felé 1. “Élenjáró IT” működés :  Folyamatos technológiai újítások: piaci versenyelőny biztosítása 2. “Szabadpiaci IT” működés:  Maga a felhasználó választja meg a hardvert, szoftvert és szállítót  Költségkorlátok szabnak csak gátat  Belső IT versenyzik a külsővel 3. “Monopólium-típusú” IT működés:  Legyen centralizált IT szervezet 4. “Szűk erőforrás” IT működés:  Szigorú költségkorlátok között kell működnie az IT-nak

IT STRATÉGIAI TERV Az IT stratégiai terv az IT stratégiában megfogalmazott tézisek és roadmap alapján bontja le a teendőket IT területenként (ERP, CRM, üzemeltetés, biztonság, számítóközpontok, stb.). Ugyanakkor nem csak top-down, hanem bottom-up módon is itt kell összefoglalni

mindazokat a célokat és teendőket, amit az egyes IT területek megfogalmaznak, mint szükséges teendőket a következő évekre. Az IT stratégiai terv tehát IT területenként foglalja össze mindazokat a célokat és az azokat megvalósító teendőket, amelyek a top-down és bottom-up elemzések kompromisszumaként vállalható, mint a következő évekre érvényes roadmap. Az egyes IT területek stratégia terveit formailag pl. 1-2 oldalas „sablon”-szerű formában foglalhatják össze. Ezekből az ún. „1-oldalas” tervekből áll össze a vállalat IT stratégiai terve. A stratégiai terv elemei, minden egyes IT területre: 1. Jelenlegi állapot és értékelése 2. Jövőbeli állapot és értékelése 3. Hogyan jutunk el a jövőbeli állapotba 4. Megfontolások, a fentiek alátámasztása érveléssel: előnyök, akadályok, kockázatok,, erőforrás igény, stb. 5. Szükséges akciók részletezése: idő és szervezeti egység dimenziókban.

IMPLEMENTÁCIÓS ÉS KÖLTSÉGTERV Az IT stratégia részeként szokták tekinteni az IT Stratégiában, ill. az IT Stratégiai Tervben megfogalmazott programok, projektek megvalósítási tervét, ami egyrészt időtervezést (melyik projekt mikorra készül el), másrészt költségtervezést (mennyiből valósíthatók meg az egyes projektek) tartalmazza. Projekt menedzsment eszközkészlettel készíthetők el ezek a tervek, pl. GANTT diagramok felhasználásával.

VEZETŐI ÖSSZEFOGLALÓ Az egész stratégia 1-2 oldalas összefoglalását jelenti, amelyet jellemzően a szervezet felsővezetői fognak majd olvasni. Lényegre törően kell megfogalmazni a legfontosabb IT vonatkozású programok és projektek célját, tartalmát, ütemezését, költségvonzatát. Ki kell emelni, hogy az egyes programok milyen hatással lesznek a szervezet jövőbeli működésére, ill. eredményességére nézve. Érdemes kiemelni az üzleti függőségeket is, tehát azokat a tényezőket, amelyekre az üzletnek fel kell készülnie.

IT stratégiai szerepe a vállalat működésében Stratégiai rács: az IT fontossága a vállalatban Minden iparág más és más mértékben igényli az IT felhasználását. Ugyanígy igaz az is, hogy minden szegmensben másfajta információs rendszerek alkalmazására lehet szükség, ezért önmagában az alkalmazott technológia és a vállalat mérete nem ad választ arra, hogy az adott szervezet a megfelelő módon és hatékonyan használja-e ki meglévő rendszerét. Azt

kell megvizsgálni adott iparágon belül, hogy a meglévő és a fejlesztendő rendszerek hatása mekkora, illetve mekkora lehetőséget kínálnak. Erre szolgál jó módszerrel az ún. McFarlanféle stratégiai rács modell:

Támogató (Support) IT: az IT sem a jelenben, sem a jövőben nem kap meghatározó szerepet. Az IT csak részfunkciókat lát el (szövegszerkesztés, internet), szerepe nem igényel vezetői kontrollt. Pl. étterem, takarítóvállalat Termelési (Factory) IT: a jelenlegi rendszer megbízható és költséghatékony. Fejlesztés helyett karbantartás. Pl. egy raktár nyilvántartási rendszere Átalakító, transzformációs (Turnaround) IT: a stratégiai cél eléréséhez szükséges az IT fejlesztése, elmaradása versenyhátrányt okozna. Pl. áruházlánc kommunikációs hálózatának fejlesztése.

Stratégiai (Strategic) IT: az IT szerepe fontos és az is lesz, a vezetés az IT-vel együttműködő. Pl. bankok, biztosítók, távközlési cégek.

Diffúzió és infúzió: Minden szervezethez más IT stratégia illik Diffúzió: az IT szervezete, irányítása mennyire decentralizált. Infúzió: a vállalat milyen mértékben függ az IT-tól, mennyire elterjedt az IT.  

 

Kis diffúzió és infúzió: az IT irányítása erősen centralizált, az IR-ek jelentősége alacsony (pl. DP korszak szervezetei) Kis diffúzió és erős infúzió: Erősen központosított irányítás mellett az IR-ek kritikus szerepet játszanak. Kiváló minőségű, integrált rendszereket igényel. – JELENLEG EZ A LEGMODERNEBB, LEGINKÁBB MEGCÉLZOTT FORMA. Nagy diffúzió, kis infúzió: decentralizált vezetés, az irányítás a helyi követelményeknek megfelelően. Az integráció az együttműködésen, nem terveken múlik. Nagy diffúzió és infúzió: nehezen irányítható, komplex környezet, drága. Erős decentralizáció – a kulcsfontosságú rendszerek szétesésének kockázata.

Adattárházak és Üzleti intelligencia (5. HÉT, 8. óra)

A tipikus IR-ek (alkalmazások) a technikai megvalósításuk szerint egy ún. háromrétegű architektúra szerint épülnek fel. Ez az jelenti, hogy legfelül a felhasználói interfész jelenti azt a felületet, amin keresztül a felhasználó kommunikál az alkalmazással. Ennek a rétegnek a legfontosabb követelménye az átlátható, vonzó design. A második szint maga a funkcionalitás, amit másképpen a „programnak” tekinthetünk. Ez az alkalmazás-logika, vagyis azon algoritmusok összessége, ami szükséges az üzleti feladatok ellátásához. A harmadik szint az adatbázisok szintje. Itt tároljuk mindazokat az adatokat, amit a program szint (és kisebb részben a felhasználói interfész szint) használ. A jelen fejezet ezt a harmadik szintet, az adatbázisok működését mutatja be magas szinten. Információrendszerek: Alkalmazás-Technológia-Adat Az információrendszerek másféleképpen is csoportosíthatók. A rendszerek felhasználásának célja, azaz funkciója szerint beszélhetünk ERP, CRM, analitikus CRM rendszerekről, döntéstámogató rendszerekről, riportoló rendszerekről, és sok más rendszerkategóriáról. A rendszerekben alkalmazott technológiák szerint beszélhetünk mesterséges intelligencia (AI) rendszerekről, amelyek AI technológiákat használnak fel, üzleti intelligencia rendszerekről, amelyek BI technológián alapulnak, és ehhez hasonlóan big data technológiát, web technológiát, mobil technológiát, felhó technológiát, stb. alkalmazó rendszerekről. Csoportosíthatjuk a rendszereket aszerint is, hogy milyen adatbázis technológiát használnak: vannak relációs adatbázis menedzselő rendszerek (DBMS), adattárházak, adatpiacok. Először az adatbázis technológiákat vizsgáljuk meg.

Adatok és adatbázisok Adatok

     

Fizikai értelemben: bit, byte (=8 bit), KB, stb. Logikai értelemben: alfanumerikus karakterek, mezők, rekordok, fájlok.

Adatbázisok Korábban: adatfájlok, amit az egyes programok beolvasnak Most: adatok adatbázisokban Több alkalmazás számára DBMS (Database Management Systems) –vezérli az adathozzáférést  Felhasználó → programok → DBMS → adatbázis  Adatbázis szerverek Előnyei:  Logikailag tiszta adatszerkezet  Az adatok könnyen lekérdezhetők  Jobb biztonsági rendszer alakítható ki

Adatbázisok vs. Adatbázis menedzselő rendszerek (DBMS) Az adatbázis az adatok szervezett állománya. Az adatokat jellemzően úgy szervezik, hogy modellezzék a valóság egyes jellemzőit oly módon, hogy közben támogatják az információt igénylő folyamatokat. Pl. modellezzék szállodák szobáinak elérhetőségét oly módon, hogy meg lehessen találni az üres szobákkal rendelkező hoteleket. Az adatbázis menedzselő rendszerek (DBMS) olyan szoftver alkalmazások, amelyek interakcióban vannak a felhasználókkal, más alkalmazásokkal, és magával az adatbázissal, hogy abban adatokat

tároljanak és elemezzenek. Egy általános célú DBMS-t úgy terveznek, hogy lehessen definiálni, létrehozni, feltölteni, keresni, frissíteni és adminisztrálni az adatbázisokat. A legismertebb DBMS-ek: Oracle, IBM DB2, MySQL, PostgreSQL, Microsoft SQL Server, ...

Problémák a meglévő adatokkal Mivel az adataink elsősorban a múltra, néhány hónapra, évre, esetleg évtizedre vonatkoznak, ezért nagyon sokszor bizonytalanság támad az adatok feldolgozása kapcsán:

BIZONYTALAN adatok okai Bizonytalan adatoknak nevezzük a valamilyen okból nem megbízható adatokat, valamint a hiányos vagy inkonzisztens adathalmazokat. Bizonytalan adatok okai:  Korábban: adatfájlok, amit az egyes programok beolvasnak  Most: adatok adatbázisokban  Több alkalmazás számára  DBMS (Database Management Systems) –vezérli az adathozzáférést  Felhasználó → programok → DBMS → adatbázis  Adatbázis szerverek  Előnyei:  Logikailag tiszta adatszerkezet  Az adatok könnyen lekérdezhetők  Jobb biztonsági rendszer alakítható ki

Integrált adatforrások Nagyon előnyös, ha egy vállalatnál az egyes információrendszerek adatbázisai nem függetlenek egymástól, hanem integráltak. Pl. ha a számlázó rendszerben és a CRM rendszerben is felhasználjuk az ügyfelek lakcímeit, akkor nincs értelme azokat két helyen külön-külön tárolni és feldolgozni, hanem egy adatbázisban kell tárolni őket, de biztosítani kell, hogy mindkét rendszer, akár egyidőben, hozzáférjen ugyanazokhoz az adatokhoz. Sőt, ha az egyik alkalmazáson keresztül módosítjuk az adatokat, akkor a másik rendszerben is azonnal látszódjanak a változtatások. Az integrált adatbázisú (röviden: integrált) rendszerek a 90-es évek közepén terjedtek el, elsőként a vállalatirányítási (ERP) rendszerekben.

A jó minőségű integrált adatforrás (adatbázis) jellemzői:

 teljes mértékben támogatja az üzleti folyamatokat,  az adatok jól strukturáltak és dokumentáltak,  megfelelő az adatok pontossága,  az adatok naprakészen rendelkezésre állnak,  egységes az adatok formátuma,

 az adatbázis redundancia-mentes,  az adatok megértése (információ tartalma) bármely felhasználó számára egyszerű. Adattisztítás Ha az adatbázisaink bizonytalan (megbízhatatlan) adatokat tárolnak, akkor időről időre szükség lehet szisztematikus adattisztításra. Leggyakrabban nagyobb rendszerek konszolidációja esetén van szükség arra, hogy a különböző rendszerek adatbázisait migráljuk egyik rendszerből a másikba, vagy összefésüljük őket. Például cégek összeolvadása esetén gyakori ez a helyzet. Ilyen esetekben alapvető fontosságú az adattisztítás. A nagyobb adatbázisok adatainak tisztítása akár éveket is igénybe vehet, például több évtizedes személyes adatokat (nyugdíj, szociális ellátások, egészségügyi adatok) tároló kormányzati rendszerek esetén. Az adattisztítások sokszor Big Data problémák a nagyon bonyolult összefüggések automatikus ellenőrzése esetén. Adattisztítás tipikus feladatai:  Adatok azonosítása  Adatok megértése  Metaadatok (pl. értelmezésre vonatkozóan)  Adatok tisztítása és integrálása (formátum, hiány, redundancia)  Adatkapcsolatok egyértelműsítése  Adatok elemzése, rendezése  Adatok telepítése (adatbázis feltöltés tiszta adatokkal)

Az adattárházak DW (Data Warehouse), adattárház: egy szervezet összes információs célú adatának összesített rendszere, amely az adatok

  

integrált, (azaz a logikai kapcsolatban lévő adatok összekapcsoltak) időfüggő, (azaz lehetőleg minden adathoz időpont tartozik) nem felejtő, (azaz sohasem törölnek adatot, csak hozzáadnak)

adatbázisa. Támogatja a menedzsment döntéshozatali folyamatait. Olyan felépítésű, hogy segítse az üzleti intelligencia funkciók minél eredményesebb megvalósítását. Nem feltétel a redundancia-mentesség, azaz egy-egy adat (például havi értékesítés volumene) akár többször is szerepelhet az adatbázisban.

Adattárházak és Adatpiacok célja: OLTP – DW – OLAP Az adattárházak (adatraktárak) és adatpiacok segítenek megoldani azokat a problémákat, amikor hiányzó vagy inkonzisztens adatai vannak a szervezetnek: a meglévő adatokból lehet következtetni a pontos adatokra. Segítenek továbbá szabványosítani az adatformátumokat a tranzakciós adatok és a külső féltől vásárolt adatok között is.

Az adattárházak és adatpiacok kifejezetten adatelemzések és adatbányászat számára készítenek elő, tárolnak és menedzselnek adatot.

Ahogy az ábrán látható, legkülönfélébb adatforrásokból, éles tranzakciós (production) adatbázisokból, más belső adatokból, valamint külső, például vásárolt adatokból gyűjt a vállalat adatot, amelyeket tisztít és előkészít az adattárházba való betöltés előtt. Az adattárháznak három komponense van: - Adattárház Menedzselő rendszer (DW DBMS): ami menedzseli az adatokhoz való hozzáférést - Adattárház adatbázis: jellemzően relációs adatbázis, ami tárolja az adatokat - Adattárház metaadatok: adatok az adatokról, amelyek szükségesek a hatékony adatmenedzseléshez, pl. mezőleírások, értelmezések.

Adattárházak és adatpiacok közötti különbség  Az adattárházak (DW) tranzakciós (működési) adatokat és vásárolt adatokat tárolnak. A DW megtisztítja és feldolgozza az adatokat, ha szükséges. Az egész szervezetet szolgálja.  Az adatpiac kisebb, mint a DW, és egy üzleti szervezet vagy egy szűkebb terület speciális információs igényeire vonatkozik, emiatt téma-orientált. Funkcionalitásában megegyezik a DW-zal. Közvetlenül lekérdezhető konkrét feladatokra.

Vállalati adatszükségleti hierarchia

Az adatszükséglet piramis csúcsán az adatbányászat, alatta az OLAP eszközök, alatta az ad-hoc lekérdezések, legalul a működési beszámolók, amelyek rendszeresen elkészített, jól strukturált, egyértelmű riportok, adatszolgáltatások.

Üzleti intelligencia rendszerek Üzleti intelligencia rendszerekről beszélhetünk funkció, eszközök és technológiák szerint.

Definíciók Az üzleti intelligencia rendszerek

nyers adatokat elemeznek és transzformálnak értelmes és hasznos információvá, üzleti elemzések céljára, hogy a menedzsment olyan döntéseket hozzon, amelyek információval minél jobban alátámasztottak. Webopedia: Az üzleti intelligencia

eszközöket és rendszereket jelent, amelyek kulcsszerepet játszanak a vállalati stratégiai és operatív tervezési folyamatban. vállalati adatokat gyűjtenek, tárolnak, elemeznek, azokhoz hozzáférést biztosítanak a döntéshozatal során. Üzleti intelligencia (BI) funkciók

  

Információ (összefüggés) keresés – lekérdezéseken keresztül Riportolás: teljesítménymérés, mutatószámok (KPI-k) Online analitikus feldolgozások (OLAP)

 

Üzleti elemzés (analitika): magyarázó és előrejelző modellezés főleg statisztikai alapokon Figyelmeztető (“alert”) eszköz

OLAP: Az Üzleti intelligencia funkciók közül az egyik legfontosabb és legnépszerűbb az online analitikus feldolgozások.

OLAP funkciók és az OLAP adatkocka-modell Aggregáció: dimenziók mentén összegzés, pl. a múlt évben eladott összes cipő, majd összes termék Lefúrás: az aggregáció ellentéte, pl. havi bontásban (DRILL DOWN) az egyes cipőfajták Forgatás: dimenzió felcserélése (más nézet): pl. a hely dimenzió helyett a fizetés módja szerint elemezni az adatokat Szelekció: egy dimenzióban értékre szűrés: pl. a febr. 4-én eladott termékek elemzése (egy „adatkocka” kiválasztása) Szeletelés: egy dimenzió lekötése, részkocka kivágása: pl. egy konkrét hónap, február elemzése minden más dimenzió szerint

OLAP vs OLTP OLTP (On-line Transaction Processing)

 

Napi üzletmenet működése Repülőgépes helyfoglaló rendszerek

OLAP (On-line Analytical Processing)

 

Féléves, éves trendek alapján előre jelezni Döntéshozatal

Üzleti intelligencia (BI) eszközök és technológiák Az üzleti intelligencia (BI) rendszer egy olyan információrendszer, ami üzleti intelligencia (BI) eszközöket alkalmaz, hogy létrehozzon és szolgáltasson információt. A BI eszközök olyan számítógépes programok, amelyek bizonyos BI technikákat alkalmaznak. A technikákat 3-féleképpen kategorizáljuk:

  

Riportoló eszközök: adatot olvasnak be, feldolgozzák azokat, és olyan strukturált riportokba formázzák az adatokat, amelyeket a felhasználó látni kíván. Elsősorban értékelésre használják. Adatbányász eszközök: statisztikai algoritmusokat használva dolgozzák fel az adatokat, mintákat és kapcsolatokat keresnek és előrejelzést tesznek az eredmények alapján. Tudásmenedzselő eszközök: munkatársi tudást (folyamatleírásokat, kapcsolatokat, összefüggéseket, “okosságokat”) tárolnak, és elérhetővé teszik az érdeklődők számára. Itt az adatok forrása az emberi tudás.

Adatbányászat (Data Mining) Definíció

 Előre nem sejthető minták, törvényszerűségek, összefüggések keresése nagy adatbázisokban (“TUDÁS” feltárás) Módszerek

  

Asszociációk



Tornádó és epres pite – tornádók közeledtével az emberek „bespájzolnak” egy konkrét epres süteményből, amire nincs racionális magyarázat, de az adatbányászatból kimutatható.

Szekvenciák keresése



Sör és bébiétel – kimutatták, hogy a bébiétel és a sör vásárlás között korreláció van, ezért e két termékcsoportot egymás mellé érdemes helyezni a boltokban.

Csoportok keresése



Szakácskönyvek: 20-40 év közötti nők

Alkalmazott technikák: Klaszteranalízis, neurális hálók, döntési fa, big data, stb.

Adatbányászati technikák Klaszteranalízis



Pl. Felhasználók szegmentálása marketing szempontból

BI rendszerek SPECIÁLIS FAJTÁI Analitikus ügyfélkapcsolat rendszer – CRM

 

„Nem termékhez vevőt, hanem vevőhöz terméket” Adatbányászati alkalmazási területei nagyon sokfélék:

    

Ügyfél szegmentáció és ügyfélmegtartás Kockázatmenedzsment Csalások felderítése és megakadályozása Direkt marketing Keresztértékesítés

Vállalati teljesítménymenedzsment – EPM (Enterprise Performance Mgmt)



Olyan rendszer, mely a vállalati teljesítmény mérésére használt mutatók alakulását követi nyomon. Pl.:

 

Eladások egy vizsgált időszakban Befektetett tőke megtérülési ideje – ROI (Return on Investment)

CRM rendszerek - típusai Háromféle CRM típust különböztetünk meg: Az ügyfélkapcsolat-menedzselő (CRM) informatikai rendszereket általában három csoportba sorolják a funkciójukat tekintve: Operatív CRM: az ügyfelekkel közvetlen kapcsolatban álló munkatársak, ügyintézők (pl. értékesítésben, kontaktcenterekben, ügyfélkiszolgálásban) támogatása az ügyfelekről rendelkezésre álló információk megjelenítésével, hogy azok azonnal felhasználhatók legyenek az ügyfél kiszolgálásában. Analitikus CRM: az ügyfelekről meglévő adatok elemzése, elsősorban a marketinget és értékesítést segítő új ügyfél-információk (pl. szegmentálás, ügyfélérték) meghatározása céljából, és az így kapott új tudás visszacsatolása az operatív CRM-be. Kollaboratív (Együttműködő) CRM: azok az alkalmazások, amelyek ténylegesen megvalósítják a kapcsolatot az ügyintéző és az ügyfél között (pl. kontaktcenter-alapalkalmazások, ügyfélsorolók stb.), és azonosításuk után megfelelő munkafolyamatba terelik az ügyfeleket. Legegyszerűbben úgy jegyezhetjük meg a három rendszer közötti különbséget, hogy a múltbeli események rögzítéséről és elemzéséről az operatív, a jövő elemzéséről, predikciókról az analitikus, a jelenben történő ügyfélkapcsolatról pedig a kollaboratív rendszer gondoskodik.

CRM RENDSZEREK A vállalatirányítási (ERP) rendszerek ugyan jelentős volumenű tranzakciós adatot halmoznak fel, de az ügyfelek személyre szabott követésére nem alkalmasak. A hagyományos ERP rendszerek az 5. ábrán látható ügyfélkiszolgálási láncban elsősorban a középső fázist támogatják: az eladási tranzakciók kapcsán nyilvántartanak ugyan vásárlói, ill. eladói adatokat, de olyat nem, ami az ügyfél időbeli viselkedését írná le. Ahhoz is lekérdezésekre van szükség, hogy a rendszer felismerje, ha valaki másodszor vásárolt egy adott terméket. Nem látható azonnal, hogy az adott ügyfélnek mikor adtak el valamit, vagy mennyire lojális ügyfélről volt szó. Ilyen ügyfélközpontú információk gyors elérésére, az ügyféltörténet nyilvántartására dolgozták ki a CRM-alkalmazásokat, amelyeket operatív CRM-eknek is neveznek. Operatív CRM (vagy más néven: tranzakciós CRM) rendszerek képesek a tranzakciók ügyfélorientált végigvitelére, nemcsak az eladási fázisban, hanem a támogatás, ügyfélszolgálat fázisában is. Ennek során olyan adatok nyilvántartása zajlik, mint például milyen támogatást igényel az ügyfél, mi az oka az elégedetlenségének, miért volt problémája a termékkel, ill. szolgáltatással, mikor lesz kész a javításra beadott készüléke. Ezekből az adatokból nagyon fontos következtetéseket tud levonni a termékfejlesztés és a marketing: legközelebb hogyan kell pozícionálni a terméket, mikor a legmegfelelőbb piacra dobni, stb. A háttérben működő adattárházak ugyanakkor alkalmasak a tranzakciós adatok analitikus feldolgozására, legkülönfélébb célú statisztikai elemzésére marketingés értékesítés-tervezési céllal, stratégiai irányok meghatározására. Vannak triviálisan fontos elemzések, összefüggések, amiket mérni, monitorozni kell. Ilyen lehet például a bankkártya-

használatok idősoros elemzése, ügyfélcsoportokra, vagy akár egyéni ügyfelekre lebontva. Az elemzések eredményeként új ügyféladatok, összefüggések generálhatók, amelyek visszacsatolva megjeleníthetők a CRM-rendszerben, az ügyfélszolgálati munkatárs, vagy éppen az értékesítési ügynök monitorján. Analitikus CRM: A nem triviális összefüggések, például hogy milyen jellemzőket részesítenek előnyben a hölgyek egy digitális kamera vásárlásakor, automatikusan nem adódnak az ismert CRMvagy adattárház rendszerekből, ez már az analitikus CRM-ek területe. Ezek feltárásához például adatbányász algoritmusokat szokták alkalmazni. Az adatbányászatot leginkább úgy értelmezik, hogy adatokból mintákat vonnak ki, vagyis az adatot információvá alakítják. Az adatbányászattal az adathalmazokból olyan mintákat, összefüggéseket lehet felderíteni, amelyek explicit módon nincsenek benne az adatbázisban. Nem véletlen, hogy pl. a marketing területek vagy éppen a csalásfelderítések kedvenc eszköze. Az üzlet részéről a legtöbb csalódás abból adódik, hogy az operatív CRM-eszközöket nem tudják igazán kihasználni, amennyiben nem tudnak hasznos ügyfél-információkat megjeleníteni az ügyintézők számára, amikor azok éppen kiszolgálják az ügyfelet (például mennyi az ügyfél lemorzsolódásának valószínűsége, vagy milyen ajánlatot kellene tenni az adott helyzetben az ügyfélnek). A jelenlegi rendszerek legtöbbször adósak a várható ügyféltranzakciók előrejelzésével, ami – az ügyfél aktív befolyásolása miatt – nem független a marketingtevékenységtől. Ebben segítenek az analitikus CRM-ek.

Operatív CRM

Analitikus CRM Mit

Mit

(Megoldást)

(Terméket)

Mennyiért

Ár Ki

Mikor

Javítás

Fizetés

Ügyféltranzakció előrejelzése

Probléma m

Ki Mikor

Csatorna

Kollaboratív CRM

Fizetés Csatorna

Eladás/vásárlás tranzakciója

Ki Határidő ő Helyszín

Fizetés

Támogatás, ügyfélszolgálat tranzakciója

5. ábra: Ügyfélkiszolgálási lánc Ügyféltranzakció előrejelzése. Az 5. ábrán az első (bal oldali) fázis a legnagyobb kihívás mind az üzlet, mind az informatika számára, hiszen jövőbeli eseményt kell megjósolni, tervezni. A marketing- és értékesítési vezetők elvárásainak tehát olyan informatikai támogatórendszer-együttes a megfelelő, amely a tranzakciós adatbázisok, adattárházak és operatív CRM-rendszerek célirányos kombinációján alapul. (Az adattárházak kibővítése ilyen elemző és előrejelző funkciókkal, ill. zárt folyamatú visszacsatolásokkal az analitikus CRM lényege.) Az előrejelzés modelljének felállításához számos paramétert figyelembe kell venni. A következőkben összefoglaljuk, milyen főbb üzleti követelményeknek kell megfelelnie egy alkalmas informatikai rendszernek. Elsőként, „ki”-ről beszélünk? Már ügyfél? Ha igen, akkor kockázatos, fennáll a lemorzsolódás veszélye? Ha nem ügyfél, akkor volt ügyfélről van szó, akit próbálunk visszacsábítani? Vagy egy potenciális új ügyfél, akit be kell „cserkészni”? Mindezen ügyfél-kategóriákban szegmentálni is lehet és érdemes az embereket, például életkor, újdonságaffinitás (szereti az újdonságokat, követi a

divatot, vagy éppen konzervatív?), technológiahasználat (számítógép, internet, mobil stb.) szerint, ami az értékesítési terület számára hasznos információval szolgál. A következő dimenzió a termék, amelyet a megcélzott ügyfél igényelne. A hagyományos megközelítés szerint van egy jónak ígérkező ötlet, ebből termék készül, és az értékesítés megpróbálja eladni, lehetőleg olyan célcsoportok számára, melyeket a marketing alakít ki. Ettől a modelltől két irányban is továbbfejlődött a gondolkodás, és az informatikai támogató funkcionalitás. Egyrészt megfordítjuk a dolgot, és az ügyfelek igénykategóriáit próbáljuk előre jelezni, majd ennek alapján alakítjuk ki (paraméterezzük) a terméket, és adjuk el azoknak, akik igénylik. Például olyan életbiztosítás kialakítása, amely a háromgyerekes, egykeresős családok számára előnyös. A másik irány: megoldást adni, nem terméket. Bár trivialitásnak tűnik ez az állítás, de mégsem az. A termékek, például egy ADSL-előfizetés, része egy igénynek, az otthoni internetezésnek. De ez messze áll a „megoldástól”, attól, hogy két vagy három PC-ből álló családi gépflottát hálózatba kössünk, és bármelyikről elérhető legyen a szélessávú internet. Ehhez ugyanis routerre van szükség, legtöbb esetben WLAN routerre, de ehhez a gépeket is el kell látni WLAN adapterekkel, hálózati beállításokat kell végezni, stb. (A megoldásszállítás ugyan ismert fogalom az üzleti ügyfelek kiszolgálása során, de az egyéni ügyfelekkel kapcsolatban még nem terjedt el.) Ahhoz, hogy ezeket a megoldásokat proaktívan kínálni lehessen, tudni kell, hogy az adott ügyfél feltehetően milyen megoldást szeretne látni. Azért rendkívül fontos ez a szemlélet, mert legtöbbször maga az ügyfél sem tudja, mi jelentené számára a „megoldást”, hiszen egy áruházban vagy akár az interneten is csak termékek között bolyong. A megoldásszemlélet miatt egyre bonyolultabb a következő feladat, a termékek árazása. A komplex termékek ugyanis elemi termékekből és szolgáltatásokból állnak össze, tehát meg kell találni az ideális árkonstrukciót a személyre (illetve ügyfél-kategóriára) szabott megoldásoknál, és ehhez informatikai támogatásra is szükség van. A következő fontos kérdés a cégek számára az ütemezés. Mikor ajánljunk egy terméket, vagy immár megoldást? Minél hamarabb? A konkurencia mikor ajánlja? Az új termék csökkenti-e a már meglévő piaci részesedését, azaz fennáll-e a kannibalizáció veszélye? A magától értetődő kérdés ezek után, hogy hogyan, milyen csatornán reklámozzuk és kínáljuk a terméket/megoldást. A bolt, fiók, telefon és tévé mellett egyre több kommunikációs és értékesítési csatorna jöhet szóba: internet (web), e-mail, különféle mobilcsatornák: sms, mobilinternet, az interaktív tévé. A legjobb csatorna kiválasztását és annak felhasználási volumenét meghatározni csak elemzésekkel lehet, ahol az összes eddigi dimenziót elemezzük: kinek, mit, mikor. Ehhez szorosan kapcsolódik a marketingkampányok tervezése: egyszeri, ismétlődő vagy folyamatos kampány legyen? Lehetővé válik a személyre szabott kampányok lebonyolítása, akár több száz, egymással párhuzamosan. Nyilván szükség van a kampányok megtérülésének növelésére, a marketingköltségvetés hatékonyabb felhasználására. Ehhez kampányszimulációt érdemes végezni, valamint a lezajlott kampányokat utólag értékelni. A ciklus végén áll a fizetés előrejelzése, ugyanis már rég nem mindegy a fizetés módja. A közműveknél az utólagos fizetés a szokás, a fogyasztási termékeknél az azonnali készpénz, bankkártya vagy hitelkártya, illetve nagy érték esetén a vásárlási hitel. A cél kettős, de ezek egymás ellen hatnak: egyrészt az ügyfél elégedettségének növelése egyre könnyebb fizetési megoldásokkal, másrészt a kintlévőségek kockázatának csökkentése. Az ügyfelek fizetési preferenciáit szintén lehet és érdemes mérni, és ennek alapján egyrészt felkészülni az új fizetési formákra, másrészt terelni az ügyfeleket a cég számára hasznos irányba. Eközben érdemes figyelni az újszerű fizetési lehetőségekre is, például mobiltelefonos fizetés, elektronikus pénztárca, de ezek ma még csak a palettát színesítő lehetőségek.

A vázolt modell szerint, megfelelő adatok, elemzési modellek, és informatikai támogató eszközök segítségével az ügyfelek viselkedése megjósolható. Ehhez az ügyfelek viselkedésének hosszú távú figyelésére és a kellően részletes historikus adatok feldolgozására van szükség. Ezt a fejlesztést a cégek vagy házi megoldásban építik össze a meglévő rendszerelemekből, vagy meglévő rendszereket vásárolnak. Az utóbbi egy-két évben a szállítók kifejlesztettek olyan analitikus CRM-alkalmazásokat, amelyek a fent körvonalazott funkciókat jellemzően tartalmazzák. A helyi vállalati környezetre szabás a versenyelőny növelése miatt nyilván fontos tevékenység marad minden bevezetésnél. Mindezen funkcionalitások csak szoros értékesítési, marketing- és informatikai együttműködéssel készíthetők el. A kollaboratív (együttműködő) CRM alkalmazásokat gyakran nem is sorolják a CRM rendszerek közé, de jellegükben mégis olyan alkalmazásokról van szó, amelyek ténylegesen megvalósítják a kapcsolatot az ügyintéző és az ügyfél között. A kontakt centerekben (vagy a telefonos call centerekben) az ügyintéző fogadja az ügyfél hívását, emailjét, sms-ét, stb. A feladat az, hogy az ügyfél kérését, kívánságát, ami lehet egy szolgáltatás megrendelése, lemondása, módosítása, vagy valamilyen technikai probléma bejelentése, minél előbb megfelelő munkafolyamatba tereljék. Ha az utolsóként említett technikai problémáról van szó, akkor a műszaki help-desk-es kollégákat kell megszólítani, akik a saját munkamenetükben kiderítik, hogy mi is a probléma, hol lép fel, általános vagy egyedi problémáról van-e szó, stb. A technikai probléma pontos leírása, majd az arra adott megoldás a kollaboratív CRM rendszerben kell, hogy rögzítésre kerüljön, de a köztes munkafolyamat nem része a CRM alkalmazásnak. A kollaboratív CRM rendszerekben is az első lépés az ügyfél beazonosítása. Szinte bármilyen ügyintézésünkre is gondolunk, mint magánszemély, az első informatikai rendszer, amivel találkozunk, egy ügyfélsoroló, ahol sorszámot kapunk. Az ügyfélsorolót is tehát ilyen értelemben ide lehet sorolni. CRM és folyamattámogatás kapcsolata. A CRM és folyamattámogatás informatikai területek csak látszólag függetlenek, ehelyett az a tendencia, hogy a két problémakör összefonódik. Két példa: egyrészt az előzőkben ismertetett ügyféltranzakciók előrejelzése folyamatot pontosan ki kell dolgozni, az összes érintett szervezet bevonásával. Az analitikus CRM megoldás kidolgozása folyamati változásokat követel az ügyfélszolgálatoknál, az eladási módszerekben és a marketing projektek menedzselésében. End-to-end folyamati modellt kell készíteni, hiszen az adatfolyamok is átlépnek üzleti, szervezeti határokat. A másik irányban is igaz az egymásra hatás, hiszen ahogy írtuk, a tranzakciós és analitikus adatbázisok elemzésével kimutathatók a folyamatok szűk keresztmetszetei, a várakozások, a szükséges beavatkozási pontok. Ezt a feladatot elsősorban a BAM (Business Activity Monitoring) eszközök képesek ellátni.

Mesterséges intelligencia (6. hét, 10. óra)

„Az ember el tud képzelni olyan technológiákat amelyek túljárnak a pénzpiacok eszén, feltalálnak olyan dolgokat, amit az emberi kutatók nem, manipulálnak emberi vezetőket, és olyan fegyvereket fejlesztenek, amelyek működését még csak nem is értjük.”

Stephen Hawking

Emerging technologies hype cycle Mesterséges intelligencia – 1.

= Artificial Intelligence (AI) A számítógép használata olyan feladatokra, melyekhez magas szintű emberi intelligencia, gondolkodási és szimbólumkezelési képesség szükséges. Turing (1950): a gép akkor intelligens, ha az interjúztató nem tudja a válaszok alapján eldönteni, hogy “ki” az ember és „ki” a gép, és a kísérletben szereplő emberek legalább 30 százalékával elhiteti, hogy ő is ember… Már folyt le olyan kísérlet 2014-ben, ahol a hallgatóság nagy része nem tudta megállapítani, hogy élő emberrel, vagy géppel kommunikál.

(http://hvg.hu/tudomany/20140608_mesterseges_intel ligencia_turing_teszt) Mesterséges intelligencia – 2.

Technikák: Cél: Exponenciális problémák lineárissá (polinomiálissá) konvertálása Neuronhálók (neurális hálózatok): korábbi példák alapján képes tanulni, mintát ismer fel, visszacsatolásos megtanítás Evolúciós (genetikai) algoritmusok: az evolúció mechanizmusának számítógépes modellje. Probléma – lehetőségek – optimális választás (fitnessz, mutációk, rekombináció) Fuzzy rendszerek: igazságtartalmakat valószínűségekkel adja meg („talán”, „jó eséllyel”) Logikai programozás (LISP, Prolog, szakértői keretrendszerek) - visszaszorultak Mesterséges intelligencia – 3.

Legfontosabb területei: Mintafelismerés: Álló- és mozgókép felismerés, Kézírásfelismerés Beszédfelismerés Gépi tanulás , mély tanulás Fordítóprogramok

Robottechnológia (ipari és antropomorf/humanoid) Játékok (az ember helyettesítése) Kiterjesztett és virtuális valóság (Augmented Reality, Virtual Reality) Szakértői rendszerek Intelligens ember-gép kapcsolat Mesterséges intelligencia – 4.

Hatással van rá a: Matematika – számítástudomány Közgazdaságtan – játék- és döntéselmélet Idegtudomány – emberi agy Kognitív pszichológia – emberi viselkedés Informatika – hardver- és szoftvertechnológiák

MI rendszerek előnyei: Tudása állandó, ill. egyre nő (nem felejt) Cselekedeteik dokumentáltak, elemezhetők A tanulás a program másolásával gyorsan reprodukálható

MI rendszerek hátrányai: Kreativitás hiánya (máshogy „kreatív”, pl. a sakkban) Szűk látókör és tartomány (specializált) – most még… Mesterséges intelligencia egyes mérföldkövei  Deep Blue (1997) – az IBM gépe sakkban legyőzte a világbajnokot, Garry Kasparovot egy 6 mérkőzéses viadalon.  IBM „Watson”(2011): természetes nyelvű kérdésekre válaszol: megnyerte a legnépszerűbb kvízjátékot USA-ban a két legerősebb játékos ellen. (200 millió oldalnyi „tudással” rendelkezik.)  Turing teszt (2014)

 Go világbajnok legyőzése (2016-17) Google AlphaGo AI megveri a világbajnokot / A MI okosabb mint egy gimnazista (NTT, japán): angol mondatok kiegészítése a dialógusok kontextusának értelmezése alapján főiskolai felvételi teszten. (47.5%) / http://index.hu/tech/2014/11/05/foiskolara_mehet_a_mesterseges _intelligencia/

A Google önműködő, sofőr-nélküli (Driverless) Autója Mobil Robotok FUTÓ robotok

“Távoli Jelenlét” Robotok: Mobil videokonferencia   

“Virtuálisan ott” technólogia Az orvos ki tudja “vetíteni” magát egy másik helyszínen, miközben körbe tud nézni lát, hall, beszél és interakciót végez, mintha ott lenne Digitális kamerák, mikrofonok, wifi adatátvitel, mozgó platform, stb.

Kiterjesztett valóság (Augmented reality) Definíció: A felhasználó valós világról alkotott, közvetlenül érzékelhető képének kiegészítése fontos információkkal.  Kiterjesztett valóság a múzeumokban  A Kiterjesztett valóság eszközei  A virtuális valóság KICSIT más

 Magyar AR/VR fejlesztések http://www.vsoft.hu/hu/innovaciok/kiterjesztett-valosag A számítástechnika azon területe, amely ötvözi a valós és a virtuális világot. … a közeljövő elsőszámú információs cél- és marketingeszköze.

Digitális Alerego (hasonmás) (Digitális színész, tanár, orvos, …) Vonzó vagy taszító/ idegesítő, ha egy mesterséges arc majdnem emberszerű? Az „uncanny valley” néven (rejtélyes, más néven: nyugtalanító völgy) azt a jelenséget nevezik, amikor a majdnem emberszerű, de mégis tökéletlen mesterséges emberi arc visszataszítóvá válik. Vagyis a humán felhasználók jobban szeretik azokat a mesterséges arcokat, amelyek meg sem próbálnak emberiek lenni. Ez egy nagy kihívás a MI számára, mert a 90-99%-os pontosságú hasonmások elutasítást fognak kapni, tehát egyből 100%-osra kell majd elkészíteni a humanoid robotok arcát. Ebben segít pl. a realisztikus 3D arc renderelés, amely technológa szerint úgy készítik el az arc digitális modelljét, hogy egyszerre 6000 LED láma világítja meg a mintául szolgáló emberi arcot egy speciális fénykupolában.