Vállalati információ-menedzsment

Az előadások a következő témára: "Vállalati információ-menedzsment"— Előadás másolata:

1 Vállalati információ-menedzsment
Az információs projekt feladatai, erőforrásai, költségei, kontrollingja Görög Mihály: Informatikai projektek vezetése Bőgel – Forgács: Informatikai beruházás (6. fejezet) Risztics Péter BME: Információrendszerek fejlesztése

2 Mi az (IT) projekt? 1. Tudatos tevékenység-irányítási, szervezési
módszertan és keretrendszer. 2. Komplex feladat megoldására kialakított és optimálisan szervezett tevékenységek összessége. Miért kell menedzselni? Mert komplex feladat: emberek, gépek, szervezet, külsősök Sok együttműködő, köztük „nehéz/drága” emberek Magas szintű munkamegosztás, fegyelem igénye Időben (és térben) nagy kiterjedésű lehet; közben sok változással Kockázatminimalizálás szükséges: ICT IA veszélyei, a rendszer tovagyűrűző hatásai miatt Költséghatékonysági követelmény: ez a beruházás „feje” Dokumentáltság-követelmény: a külső finanszírozás követelményei, a belső kontrolling követelményei, a „szervezeti tanulás” követelményei

3 Az IT projekt-menedzsment feladatai
„A tevékenységek ütemezése, az együttműködők koordinációja” A formalizálás feladatai: szervezeti keretek definiálása (ki-kit utasít, kinek jelent) a működtetés szabályozása (erőforrások igénybevétele, hatáskörök) eljárásrend kialakítása (mit, mikor, kivel, módosítások) dokumentálás (belső, külső és tanuláshoz) A Projekt attribútumai 1. Objektum, a megoldandó feladat, pl. bérszámfejtési rendszer 2. Ütemezés, időzítés: véghatáridőhöz (kötbérhez) kötött 3. Erőforrások: emberek, gépek, bizonytalanság 4. Költségek - nos, itt jövünk mi a képbe!

4 Az igény-feltárás módszerei
A/ Az ún. kemény rendszerelemzési technikák konkrét eljárásokat fogalmaznak meg az információs igények feltárására: kvantifikált ellenőrzés, regisztrálható adatigények, interjúk, dokumentum-elemzés. A strukturált folyamatelemzési technikák megvizsgálják az output dokumentumokat, s ezekről gyűjtik le az igényeket; az adatelemző eljárások az adatforrásokból, az adatbázisok elemzéséből építik fel az új logikai adatmodellt. B/ A puha rendszertervezési módszerek azt feltételezik, hogy a felhasználó nem tudja megfogalmazni, hogy adott szituációban milyen információkra lesz szüksége; a problémák jellegéről nincs vállalati egyetértés. A módszer: humán technikák, tárgyalás, iteratív tervezés, szervezeti szituációk számbavétele, közös megoldások. C/ A szocio-technikai tervezési módszertanok a fentiek kombinálásával dolgoznak: az erőteljes technológiai beruházások és az emberi tényezők, a szervezetek- csoportok együttműködésének párhuzamos vizsgálata képezik a módszerek súlypontját. ETHICS ETHICS & ISAC ISAC

5 IR -elemzési technikák
“Kemény” rendszerelemzés: - strukturált folyamatelemzési technikák, pl. SADT, Ross, 1977, IBM BSP, ARDOSZ, MSz SSADM, NCC, ITB, EuroMethod, EU UML technikák, stb. - adatelemző eljárások pl. Warnier - Orr, 1976, Jackson-diagramok, Data Structured System Devl. - prototípus-módszer, PRINCE proj. mgmt - CASE-eszközök feltételek? Sic: NEM üzleti-folyamat elemzés!

6 További eljárások “Puha”tervezési módszerek:
- a felhasználói kommunikáció hatékonyságának javítása - egyetértés a megoldásokban is, participatív tervezés - a problémák komplexitásának csökkentése - iteratív, személyes, konzultatív eljárások - a problémás szituációk egyedi feldolgozása lehetőségek?

7 További technikák Szocio-technikai tervezési módszertanok
- Az ETHICS eljárás: a "részvételi demokrácia” - Az ISAC “emberközpontú” módszertan: felhasználó-centrikus feltárás - A Multiview "többszempontú módszertan" Mire jók a tanácsadói módszertanok? - hatékonyabban, gyorsabban, precízebben jutunk el az igényekig - a kommunikációs lehetőségek jobbak - jobb ellenőrzési lehetőségeket ad - jó minőségű dokumentáció készül - a szerepek, a felelősségek ismertek - a vezetői információs igényhalmaz konzisztens lesz.

8 Tipikus ETHICS kérdések
- Tényleg kell ez a változás? - Hol vannak a rendszer határai? - Milyen információkkal dolgozik a mostani rendszer? - Mik a részterületek (szerep, cél, résztvevők)? - Funkciók és felelősségek rendszere? - Jó megoldásokat adnak a mostani eljárások? - Milyen hatékonysági igények vannak? - Elégedettek a vezetők a szolgáltatásokkal? - Mit várnak a jövőtől? - Súlyozható a fenti két terület egy skálán? - Leírható egy szükségleti és egy célrendszer? - Tervezzük meg az új szervezetet! - Tervezzük meg a technikát, válasszunk optimális megoldást! - Menjünk le az információs munkalépések szintjére: tervezzünk! - Indítsuk el a rendszereket - Értékeljük ki: ki, mit kap, mennyiért, mennyire elégedett, stb. ETHICS

9 A puha ISAC módszer -------------------------------------
„ Information Systems Work & Analysis of Changes” - A változás szükségességének elemzése - Az egyes tevékenységek részletes tanulmányozása - Az információ-ellátás és az igények „szöveges” összevetése - Az adatkezelő rendszer tervezése, ún. „ISAC-gráfok” segítségével - Az információkezelő eszközrendszer illesztése ISAC ETHICS & ISAC

10 Projekt-menedzsment: a lépések
Projekt-előkészítés (cél, „mandátum”, pénz) Projekt-indítás (alapvető módszerek, szervezet, költségbecslés, „business case”-CBA igazolása, kockázatok lefektetése, vezetés, mérföldkövek és felelősségek; Projekt-Alapító-Doku (PAD)) Projekt-irányítás (proj.mgmt szerepe; ellenőrzési mechanizmusok, napló; szakasz-menedzsment; változás-kezelés – engedély, jegyzőkönyv-; minőségbiztosítás; mérföldkő-elemzés és projekt-termékek) Projekt-kockázatok: költségek részben és egészben; határidők és mérföldkövek, ütemterv zavarai; személyek-kompetencia-tudás allokálása; minőség részben és egészben; célok-kiterjedés változása; projekt-tulajdonos és vezetés figyelme, támogatása

11 A projekt üzleti értéke
A vezetői döntés: azt a projektet indítjuk, aminek nagyobb a várható üzleti értéke A választás lehetősége: Választás a szervezet általános üzleti igényei, tervei alapján: van igény, van vezetői támogatás, van finanszírozás – pl. egy CRM vízió megvalósítása Választás projekt-kategóriák között: fontosság, időtartam (van értelme?), határidő (meg lehet addig csinálni?); problémára-reagálás vagy direktíva, utasítás miatt kell? Választás gazdasági számítások (NPV, stb., ) alapján – vagy Mintzberg patkó-modellje: abszolút pénz, vagy abszolút más célok (stakeholder-elemzés) (pl. munkahelyek, alvállalkozók helyzetbehozása, stb akármi) Választás súlyozott kritériumok alapján (pl.: üzleti célok támogatása, belső támogatási erő, ügyfelek támogatása, technológiai szint, rövid megvalósítás, NPV pozitív, kicsi a költségek/kiterjedés/idő és más kockázati mutatója, stb.)

12 Egy SAP projekt céljai (N.Welti, 1999)
Vevőmegkeresések válasza 2 óra alá csökkentése Válaszok pontosságának javítása Rutin értékesítési adminisztráció javítása Vevőigények-anyagok biztosítása egyensúly javítása Fizetési határidők 5 napos kurtítása Rutinjellegű pénzügyi admin optimalizálása Rendelések átfutási idejének felezése Készletek átlagos állományának 40%-os csökkentése Készletforgási sebesség megduplázása Termelési költségek csökkentése Teljesítmény-javulás: tervezés, programozás A teljes „output” 2,5%-os növelése, azonos létszámmal Becsült teljes megtakarítás / év Példa tényleges TCO-ra:

13 Példa: egy CRM projekt megtérülése
Pozitív tételek: Az eladott mennyiséget növeljük, kereszt-értékesítéssel A szolgáltatási díjak növelése jobb piac-szegmentálással Értékesítési költségek csökkentése a vevőhűség erősítésével, célzott marketinggel Készletszintek csökkentése piaci előrejelzésekkel Követelés-állomány csökkentése a rossz vevők kiszűrésével (adatbányászat) Negatív tételek: A folyó kiadások növekedése az új ICT rendszer miatt A tárgyi eszközök állományának növekedése (beruházások)

14 Ami egyszerűbb: IT-Mgmt
Amiért fontos (Szabó Z.) - Az IT háttér nélkülözhetetlen, SOP jellegű, esetenként stratégiai - A beruházás és a fenntartás egyre többe kerül - Az új technika terjedése gyors, a „vevő” igényesebb - A hálózatok és a biztonság miatt a rendszerek egyre bonyolultabbak - Compaq felmérés: 25-ből csak egy pénzügyi döntéshozó veszi figyelembe, hogy az IT-beruházások költségeinek kb. 80%-a az üzemeltetés során lép fel. - BEIS (Brian Seitz): 1/5 projekt sikeres pénzügyileg, 1/3 leállításra kerül, „CIO means Career Is Over” A szokásos kérdések - Indokolható a jelenlegi csúcstechnológia követelése? - Illeszthető a tervezett eszközrendszer a meglévőkhöz? - Mekkora az egyszeri és folyamatos járulékos költség-növekedés? Amit tehetünk (viselkedési stratégiák): A/ Extenzív beruházás a technikába („több memória”, új processzorok, mindenkinek PC és Internet - aztán majd lesz valahogy) B/ Túlélés: tűzoltó jellegű beavatkozások („legalább egy gépen menjen”, „ a főnöknek van Internetje”, „igen, megvettük, 5 gépre”) C/ Figyelni, tervezni, előkészíteni, beruházni, fenntartani...

15 Az IT-projekt management modelljei
REJ Rapid Economic Justification, (Microsoft és Intellectual Arbitrage Co.): nem csak költség (TCO), hanem hasznok is BEIS (Business Enviromental/Economic Impact Statement), a REJ-jel párhuzamosan, annak „bátyjaként” fejlődött. Több részletes módszertani adatot és technikát tartalmaz, integrálva; inkább gyakorlati természetű. (Seitz, 1999) IT outsourcing megoldások

16 Az MS- REJ modell elvei A BEIS számos technikát, eszközt és megoldási utat foglal magában, ezzel szemben a REJ maga egy konkrét, lehetséges megoldási út IT-projektek értékelésére A REJ célja: kiegyensúlyozott megközelítésmód, az értékelés egyensúlyának (C/B) lehetősége, szemben a szimpla költségmodellekkel (pl. TCO) A REJ a gazdasági elemzések adatait és folyamatát gyorsan végrehajtható és nagymértékben fókuszált lépések sorozatába koncentrálja, melyek mindegyikéhez jól meghatározott kimenetet és javasolt végrehajtási technikát ajánl. A legtöbb egyszerű projekt esetében a REJ elegendő ahhoz, hogy egyszerre elégítse ki az igényeket és megfeleljen az „időben gazdaságos” elemzés feltételének. Ha a gyors elemzés elengedhetetlen, a „Rapid” EJ a megfelelő választás.

17 A REJ modell elemei A REJ-keretrendszer az üzleti feladatokra, mint kritikus sikertényezőkre (Critical Succes Factor – CSF) hivatkozik. Képes együttműködni más elemző eljárásokkal (pl. IT-portfolió menedzsment, Balanced Scorecard és a különböző, élettartam alatti költséget elemző módszerek). Egy REJ-tanulmány elkészítése három fázisból áll: A/ Csapat-szerepek és -felelősségek definiálása: sok szakterületről összeállított szakembergárda működtetése B/ Előkészületek az üzleti tanulmány elkészítésére (irányvonal, célok, magyarázó[!] részek gazdasági vezetőknek a haszonról, relatív haszon a konkurrens projektek vezetőinek!) C/ A tanulmány elkészítésének folyamata (technikák és eszközök a vizsgálat elvégzéséhez, Microsoft Solution Framework -MSF)

18 A REJ lépései

19 Az 5 REJ lépés és résztvevői:
1. Az üzleti helyzet felmérése, stakeholder identification, CFS definition, Key Performance Indicators (KPI): interjúk, értéklánc-elemzés, stb.

20 és: 2. A megoldás meghatározása: A csapat meghatározza a vállalat CSF-aihoz legjobban kötődő tevékenységeket, s a lehetséges IT támogatást (Required Enabler – RE) 3. A hasznok és költségek felbecslése: Megbecsülik a potenciális hasznokat és az ezek elérése közben felmerülő költségeket. Cash-flow tervezés (Cash-Flow Statement), lényegében „munkaktsg-megtakarítás” használható. Nem egyszerűen egy szokásos „Total Cost”: fogalmazzák meg maguk a résztvevő döntéshozók (Business Decision Makers, BDMs), mik az előnyök: írjanak le szcenáriókat, vitassák meg, mi-lenne-ha módon!

21 és: 4. A kockázatok meghatározása: A csapat azonosítja és számszerűsíti a projekt bizonytalan területeit, risk-mgmt módszerekkel (alignment-, pénzügyi feasibility-, operational-, beneficial-risks). Kockázati kategóriák: annak kockázata, hogy az implementációs költségek eltérnek a tervezettől; annak kockázata, hogy az üzemeltetési költségek magasabbak lesznek a becsülteknél; annak kockázata, hogy a hasznok alacsonyabbak lesznek a vártnál. A REJ ehhez egy komplex mátrixot használ (vizualizálás): az események bekövetkezésének valószínűségét és hatásának mértékét becsülteti fel:

22 és végül: 5. Finanszírozási mérőszámok számítása: Időtényezővel és a kockázatokkal módosított cash- flow számítások, mérőszámokkal kimunkálása (diszkontált cash-flow, NPV, IRR, EVA - economic value added - , megtérülési idő – pyback period – etc.). Az eredmény: egy tömör, komplex, sokoldalú report, egy „business case”, amely vezetői és finanszírozói (!) döntéstámogatáshoz használható

23 Példa az öt lépésre ELEMZÉS: legyen az “értékesítés hatékonysága” elfogadott CSF Nagyobb IT-támogatás eredményes lehet: - A fogyasztókat termékinformációkkal látjuk el - Termékbemutatókat tartunk kiválasztott fogyasztóknak - A versenyző árajánlatokra azonnal (real-time) válaszolunk - Az értékesítési eseményeket online módon elemezzük, stb. MEGOLDÁS: ha a “termékinformációk vizsgálata” egy kulcstevékenység, pl. az idő 50%-át viszi el (árak, specifikációk, stb.), akkor csináljunk adatbázist, intraneten, és adjuk ki azt laptopokra, frissítéssel, tegyük extranetre, stb. CBA elemzés: - Direkt munkaköltség-megtakarítások - A tudásalapú dolgozók munkaidő-alapja növekszik - A döntések ciklusideje csökken - A felhasznált működő tőke csökken - A támogatási és infrastrukturális költségek csökkennek - A végeredményt tekintve a bizonytalanság és a kockázat csökken. RISK MANAGEMENT, mutatószámok, kockázatok pontozása TANULMÁNY, pénzügyi mutatók: sROI, NPV, IRR, Economic Value Added – EVA, megtérülési idő, Earnings Per Share – EPS).

24 A BEIS modell tulajdonságai
Business Environmental/Economic Impact Statement - értékelő tanulmány A BEIS mélyebb vizsgálatot, statisztikai korrelációk és az üzleti stratégiához való viszony elemzését is lehetővé teszi. A REJ-től eltérő utak használata jóval több időt és erőfeszítést emészt fel, és nem ajánlott olyan vállalatoknak, melyeknek nincs gyakorlatuk az IT-megvalósíthatósági tanulmányok kidolgozásában.

25 A projektek értékelésének nehézségei /1
Legtöbbször nem egy projekt fut, hanem több, párhuzamosan Ma már csak nagyon komplex szoftver-rendszerek vannak Több-helyszínes, akár több-országos projektek futnak A célrendszer nem világos, a határok és stakeholderek nehezen azonosíthatóak, változnak A technológia menet közben megváltozik, integrálni is kell A legtöbben részmunkaidőben vesznek részt egy informatikai projektben: ez nem építőipar! A projektek hosszúak és bonyolultak: mikor lesz „sikeres”? Mikor „failed”? A sok helyi sajátosság miatt minden projekt „más”

26 Mi a probléma az ICT projektekkel? /2
Nincsenek egzakt mutatószámok, amelyekkel a projekt sikerét, kimenetét mérni lehet (nem úgy, mint egy ipari beruházásnál) A projektek nagy százalékban (50-60%!) kudarcot vallanak, módszertan, szakértők hiányában, s ez bizonytalanná teszi a vezetőket – mindent alábecsülnek! Az ismeret- és információhiány nem biztosítja a szükséges vezetői támogatást A technológia és a létrehozott rendszerek bonyolultak, gyorsan változnak A szállítók garanciáját egyedül a referencia-munkák jelentik, azok megítélése pedig bizonytalan Az örökölt rendszerek megtartásának igénye akadályozza a projekt előrehaladását Egyes örökölt rendszereket integrálni kell, az adat-migráció súlyos probléma A meglévő informatikai csapat nehezen vehető rá az együttműködésre, nehéz a csapatépítés, külsősökkel kell dolgozni A beszállítói kockázatok miatt a projektek sokat késnek, költségeik nehezen tervezhetőek. CHAOS

27 A kudarcok okai Ipari beruházás VIR bevezetés Célok
Ipari beruházás VIR bevezetés Célok Egzaktan megadható teljesítési mutatók Általános, nem mérhető kritérium-célok Kiválasztás Definiálható kritériumrendszer alapján Referencia alapon Szerződés Általában különválik a tervezési és a kivitelezési megállapodás Általában a rendszertervezés előtt szerződnek a kivitelezésre is. Termék Előre megtervezett technológia kivitelezése Projekt során feltárt ügyviteli folyamat leképezése egy szoftver lehetőségeire Környezeti stabilitás A megvalósítás ideje alatt a technológia szempontjából stabil feltételek Dinamikusan változó cégműködés közben, gyorsan változó technológia Kivitelezés Vevő részvétele nélkül végezhető Vevő részvétele nélkül nem megy Teljesítés Mérhető output Szubjektív output elemek: (mennyiség, minőség) Komfortos? Elég gyors? Egy év múlva? (Bőgel György nyomán)

28 Dr Megyeri Károly Projektmódszertan 2000 KFKI ISYS
(Bőgel György nyomán)

29 Példa: szoftverhibák kijavításának költségei
Mikor észleli a hibát? Költségek nagysága USD A felhasználói igények meghatározásakor 100 – 1,000 A programozás során és a modulok belső tesztelésekor 1,000 – plusz A rendszer össz-tesztelésekor 7,000 – 8,000 Az elfogadási tesztnél, a felhasználó jelenlétében 1,000 – 100,000 Implementálás és átvétel után, a teljes rendszer éles futásakor, szervezeti és folyamat-átalakítások után feltárt hibáknál milliós nagyságrend Menet közbeni kérdések: - Amikor rájövünk, hogy így nem megy tovább, de már benne van X millió, mit tegyünk ezzel? Hova számoljuk? Újrakezdjük? - Mennyi tartalékot képezzünk a valószínűsíthető problémákra?

30 ICT projekt-menedzsment: a kommunikációs gát

31 Láttuk az Info Arch keretében:
PRINCE2 stands for 'PRojects IN Controlled Environments', it was developed by the UK Office of Government Commerce (OGC) back in the 1990s. PRINCE2 is a de facto standard developed and used extensively by the UK government and is widely recognised and used in the private sector, both in the UK and internationally. It embodies established and proven best practice in project management.

32 PRINCE: brit ajánlás a projektekhez
A PRINCE projektirányítási módszertan az LBMS (Learmonth and Burchett Management Systems') cég módszerének (PROMPT) továbbfejlesztése. A PRINCE (Projects IN Controlled Environments) a brit kormányzat informatikai részlegeinek projektirányítási ajánlása (CCTA -(Central Computer and Telecommunications Agency A gyakorlatban a PRINCE nem alkalmazható nagyon kis projektek esetén, amelyek kevesebb mint három embert foglalkoztatnak, vagy három hónapnál rövidebb ideig tartanak. A PRINCE nem rendszerfejlesztési, hanem projektirányítási módszertan. A PRINCE főként az SSADM-en (Structured System Analysis and Design Method) alapuló rendszerfejlesztési projektekhez nyújt irányítási keretet. Ezenkívül támogatja következők használatát is: A konfigurációkezelési módszer (KKM) a rendszer struktúrájának és tartalmának ellenőrzéséről gondoskodik a fejlesztés során; CRAMM (CCTA's Risk Analysis ans Management Methodology): tevékenységek, amelyek a kockázatokat megfelelően csökkenthetik. PRINCE

33 PRINCE: IT projekt-módszertan 1.
A PRINCE-ben a projektnek véges élettartama, megadott felelősségi körökkel rendelkező szervezeti struktúrája, meghatározott és egyedi termékei, a termékek előállításához szükséges tevékenységei, valamint e tevékenységek elvégzésére alkalmas erőforrásai vannak. Egy projekt több szakaszra bomlik, egy szakasznak is vannak meghatározott termékei és tevékenységei, szervezeti felépítése, valamint véges lefutási ideje. A szakasz végét a benne meghatározott termékek előállítása jelenti, amennyiben azok kielégítik a megállapodás szerinti minőségi feltételeket. A PRINCE meghatározza a projektnek és szakaszainak szervezeti felépítését, az egyes projekttervek tartalmát és szerkezetét, valamint ellenőrzési pontokat annak biztosítására, hogy a munkálatok a tervek szerint folyna, a termékek „elkészülnek”. . A PRINCE projekt minden terméke egy jól meghatározott és összefüggő nyilvántartási rendszerben van elhelyezve, amelyben az irányítási, műszaki és minőségbiztosítási termékek egymástól elkülönülnek. Egy tipikus rendszerfejlesztés esetén a projekt szakaszai a rendszerfejlesztés életciklusának felelnek meg. Eszerint a szakaszhatárok a specifikáció, (megvalósíthatósági tanulmány), tervezés kivitelezés és üzembehelyezés fontosabb termékeinek teljesítéséhez igazodnak.

34 PRINCE: az életciklusok
Elképzelés Megvalósíthatósági tanulmány Hatáselemzés Feladat-specifikáció Tervezés Fejlesztés Tesztelés Üzembe helyezés Üzemeltetés Változtatás Termék- életciklus Projekt- életciklus

35 PRINCE projekt-módszertan 2.
A PRINCE tervek hierarchikus struktúrát alkotnak, a szervezet szintjeihez igazodó tervezési szintek formájában.

36 1. Az IT projekt megtervezése
A PRINCE és a tanácsadó 1. Az IT projekt megtervezése - a “van” helyzet: információgyűjtés - problémák azonosítása, igénylisták készítése, szűrés - strukturális terv: mit akarunk elérni, kiket fog ez érinteni, milyen lépésekre van szükség - erőforrás-terv: költségek, emberek, idő, stb. - és egy vázlatos tevékenységi terv, legtöbbször hálóterv / GANTTformájában. 2. A projekt irányítása Rendszertervező helyett: “művezető” IT-menedzser, vezető programozó, felhasználói projektmenedzser? Emberi problémák (életkor, képzettség, attitűdök); mérési problémák; minőségbiztosítási problémák; ellenőrzés és számonkérés nehézségei. Koordinálás, rugalmasság, jó kommunikációs készségek, szaktudás, gyakorlat a KÉZBENTARTÁS kérdése PRINCE

37 És láttuk: „célvezérelt projekt-menedzsment…”
3. A projekt ellenőrzése - célvezérelt szemlélet - mérföldkövek ellenőrzése, személyhez kötés - eltérések magyarázata - változás-menedzsment, korlátozások - erőforrás-felhasználás - eredménymérés: auditálás.

38 Az e-projektek specialitásai
eBusiness: a cég kulcsfolyamatainak teljes elektronizálása, Internet szolgáltatásokkal A szokásos eBusiness architektúra: Ügyfél-oldali (kliens) felület (browser, vagy spéci terminál) Központi szerver (adatbázis, szoftverek, fizetés) Üzemeltetés-támogató rendszerek (monitorozó szoftverek, üzenetközvetítés, portál-technikák) Távközlési infrastruktúra A speciális projekt-követelmények: 7 x 24 x 365 folyamatos üzemeltetés, rendelkezésre állás Alacsony válaszidő, tartalmi értelemben is (Toys ‘R Us) A teljesítmény-igény ingadozik, nem becsülhető (Harry Potter) Erős biztonságtechnikai igények vannak (szegmentálás, szakértelem) Nincs idő sok fejleszthetőségre (RAD, PRINCE) c. Szabó Zoltán, BKAE

39 Egy módszertan: A „célvezérelt” projektmenedzsment azt diktálja, hogy a projekt vezetése során a legfontosabb a cél-hierarchia felépítése, figyelése, a tevékenységek célra-orientálása A főbb fogalmak: cél-lebontási struktúra (Mission Breakdown Structure) pontos felépítése a környezet állandó figyelése: az érdekcsoport-elemzés (Stakeholder Analysis) és a bizonytalanság-elemzés (Uncertainty Analysis) kidolgozására összpontosít. az átfogó tervezés egy többsávos mérföldkő-tervezésre épít és alapul szolgál a részletes tervezéshez, a projekt-követéshez és a kontrollhoz. Forrás: GDMP kézikönyv

40 Old Economy: IT a költség-csökkentésért
Véry Zoltán Old Economy: IT a költség-csökkentésért New Economy: IT/IM a profit-növelésért