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: IKT 1 ) 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. Eszköznyilvántartás és infrastruktúra menedzsment 2. Rendszerfelügyelet 3. Incidens- és problémakezelés: rendszert ért zavarok elhárítása 4. Verziókövetés, szoftververziók és változatok kezelése 5. Minőségbiztosítás 6. 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: 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 5.2.11. 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. Analitikus CRM Operatív CRM Kollaboratív CRM Mennyiért Mit (Megoldást) Ár Mit (Terméket) Javítás Probléma m Ki Ki Ki Mikor Mikor Határidő Csatorna Fizetés Csatorna Fizetés Helyszín Fizetés Ügyféltranzakció előrejelzése Eladás/vásárlás tranzakciója 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