Informatikai stratégiai tervezés a gyakorlatban

Informatikai stratégiai tervezés a gyakorlatban

MTA Információtechnológiai Alapítvány 1993.Készült a Learmonth & Burchett Management Systems Plc. engedélyével, az

¢¢LBMS Strategic Planning for Information Technology¢¢, valamint "Az informatikai stratégia kialakításának és megvalósításának irányelvei" c. kiadványok felhasználásával, a Miniszterelnöki Hivatal Informatikai Koordinációs Iroda megbízásából.

Készítette: Klimkó Gábor Elkészítésében közremûködött: Fövényi Zsolt Kincses László Kiss József Kun László Molnár Bálint Skobrics Tibor

Ó MTA Információtechnológiai Alapítvány, 1993

A kézikönyv tartalma, célja A könyv írásakor kitûzött cél az volt, hogy egy konkrét informatikai stratégiatervezési módszer bemutatásával segítse a központi közigazgatásban ilyen feladatban résztvevõk munkáját. Az ismertetésre kerülõ módszer megfelel azoknak az irányelveknek, melyek ismertetése 'Az informatikai stratégia kialakításának és megvalósításának irányelvei' c. kiadványban lelhetõ fel. A módszer alkalmazása során az irányelvekben követendõ példaként megfogalmazott dokumentumok elkészíthetõk. A módszer eredeti formájában mind a profit-orientált, mind a közszolgálati szektorban mûködõ szervezetek számára készült, ebben a kézikönyvben a közszolgálati szektorban alkalmazható technikák, megközelítési módok kerülnek bemutatásra. A kézikönyv a módszer szerkezetét követi: egy áttekintõ fejezet után a módszer egyes szakaszai szerinti bontás taglalja a tevékenységeket. A könyv függelékében tevékenységlista található.

Olvasótábor Az ismertetésre kerülõ módszer technikái, megközelítése általában hasznos lehet mind a központi közigazgatás szakmai munkájában, mind az informatikai tevékenységekben résztvevõ szakemberek számára. A kézikönyv érdeklõdésre tarthat számot az informatikai stratégiatervezésben résztvevõk közül

q a módszer alkalmazóinak táborában, q a stratégiai tervezésben résztvevõ vezetõk számára, q más stratégiatervezési megközelítést választó tervezésbeli résztvevõk számára. A módszer alkalmazóinak ez a dokumentum a módszer hivatkozási kézikönyveként használható, számukra az összes fejezet átolvasása szükséges. Vezetõknek a bevezetés, valamint a tervezésrõl és behatárolásról szóló fejezetek áttekintése segíthet az informatikai stratégiatervezéssel kapcsolatos elvárások kialakításában. Más módszerek alkalmazói számára pedig a kézikönyv összehasonlításra ad lehetõséget, és ehhez elégségesnek bizonyulhat a bevezetés és a függelék áttanulmányozása után az ismertetésre kerülõ anyagban folytatott tallózás.

Feltételezett elõismeretek A kézikönyv fejezetei az adattervezés kivételével nem épülnek rá mély informatikai alapismeretekre. Ez nem jelenti azt, hogy ilyen tudásra nem lenne szükség a tervezés során: a rendszerötletek felvetése igényli az informatikai szakértelmet is. Az informatikai stratégiai tervezés a szervezet szakembereinek és az informatikusok közös munkája kell, hogy legyen. Az informatikai stratégiai tervezés során megszületõ dokumentumoknak meg kell felelniük a az irányelvekben támasztott követelményeknek, ezért 'Az informatikai stratégia kialakításának és megvalósításának irányelvei' c. dokumentum ismerete a módszer alkalmazói számára nélkülözhetetlen. Szervezetstratégiai tervezési elvek és módszerek megértésében, de ez nem feltétlenül szükséges.

ismerete

segíthet

a

leírtak

Kapcsolódó kézikönyvek Az informatikai stratégiai tervezés vezérfonalát vezetõknek a már említett 'Az informatikai stratégia kialakításának és megvalósításának irányelvei' c. kiadvány foglalja össze. A stratégiai tervezés eredményeképp úgynevezett koncepciókat lehet a szervezetben érvényesíteni, mely a szervezet által követett megközelítéseket írja le egyes területeken. A rendszerelemzés területén az 'SSADM struktúrált rendszerelemzési és -tervezési módszer' c. kézikönyv, a projektirányítás területén 'Bevezetés a PRINCE projektirányítási módszertanba' c. kézikönyv ismertet lehetséges megközelítési módokat.

TARTALOMJEGYZÉK Bevezetés............................................................................................................... 5 Tervezés, behatárolás és adatgyûjtés................................................................. 15 A jelenlegi mûködési és informatikai stratégiák értékelése................................. 29 Az informatika jövõbeni stratégiai felhasználásának meghatározása..................61 A kinduló terv elkészítése.....................................................................................95 A stratégiai adattervezés áttekintése................................................................. 105 A végleges terv elkészítése................................................................................127 Tevékenységek felsorolása................................................................................135 Az irányelvek szerinti jelentések elõállítása....................................................... 141 Irodalomjegyzék................................................................................................. 145

4

1 Bevezetés Az informatikai stratégiai tervezés folyamatának áttekintése Az itt ismertetésre kerülõ informatikai stratégiatervezési módszer öt szakaszból áll, úgymint:

q tervezés és behatárolás, q alapadatgyûjtés, q stratégiai követelménytervezés, q stratégiai adattervezés, q részletes terv elkészítése. Az alábbi ábra a teljes folyamatnak részletesebb áttekintését nyújtja:

Bevezetés

6

Tervezés és behatárolás

Kezdeti információ gyûjtés

STRATÉGIAI KÖVETELMÉNYTERVEZÉS

STRATÉGIAI ADATTERVEZÉS

Jelenlegi mûködési és informatikai stratégiák

Ideális adatmodell

Az informatika jövõbeni stratégiai alkalmazása

Jelenlegi adatmodell

Adatterv készítése

Vázlatos informatikai stratégiai terv

Részletes terv készítése

Megjegyzendõ, hogy a "stratégia" szó több szövegkörnyezetben is megjelenik majd, másmás jelentéstartalommal. A "szervezeti stratégia" jelentése a vizsgált szervezet mûködésére, céljainak megközelítésére vonatkozik, ennek része a szervezet "informatikai stratégiája". A szervezet mûködési területein a "mûködési stratégiák" érvényesülnek, melyek a terület mûködésére, a szolgáltatások nyújtásának természetére jellemzõ. Végül a mûködési terület vezetése hozzáállásának módját az informatikához az "informatikai irányítási stratégia" fedi le. A kézikönyvben ismertetésre kerülõ módszer megfelel 'Az informatikai stratégia kialakításának és megvalósításának irányelvei' c. dokumentumban leírtaknak. A továbbiakban az "irányelvekre" történõ hívatkozások mindig az említett kiadványban foglaltakra vonatkoznak. A módszer megértéséhez szükséges négy alapfogalom bevezetése, melyek az alábbiak:

q Mûködési terület: a szervezet önmagában vizsgálható része, melyet az általa a külvilágnak nyújtott szolgáltatásai különböztetnek meg más mûködési területektõl. A módszer alkalmazása során a szervezetet mûködési területekre bontva fogjuk vizsgálni.

q Kritikus sikertényezõ: a szervezet törekvéseit megfogalmazó állítás. Olyan dolgot ír le, melyet ha nem jól csinálnak, az alapvetõen befolyásolja a szervezet teljesítményét és külsõ megitélését. A kritikus sikertényezõk összegyûjtése és jóváhagyása az informatikai stratégiatervezés határain túl mutat. A kritikus sikertényezõk írják majd le magas szinten a szervezeti-mûködési célkitûzéseket.

q Cél: a szervezeti-mûködési törekvések megfogalmazásaiból levezetett mérhetõ és ellenõrizhetõ követelmény, szükséglet vagy célkitûzés. A kritikus sikertényezõkhöz kapcsolt célokat használjuk fel arra, hogy el tudjuk dönteni, vajon sikerült-e a szervezeti célokat megvalósítani.

q Feladat: a célok megvalósítását elõsegítõ informatikai tevékenység. Miután a célok meghatározásra kerültek, feladatkitûzésekké kell átalakítani õket. A feladatkitûzések kifejezetten informatikai jellegûek. Az informatikához nem kapcsolódó feladatok nem MTA Információtechnológiai Alapítvány, 1993

tartoznak hozzá az informatikai stratégiatervezéshez. A fenti fogalmak pontosabb értelmezését a módszer megfelelõ pontjain adjuk majd meg.

Tervezés és behatárolás A tervezés és behatárolási szakasz feladata az elkészítendõ dokumentumok körvonalazása, illetve a stratégiai tervezési munkák részletes tervének elkészítése. Még mielött a stratégiai tervezéshez hozzáfognánk, több kérdésben dülõre kell jutnunk: q Szervezeti kiterjedés: a vizsgálandó szervezetnek mely részeire fog a tervezés

kiterjedni? q Kapcsolat tervezési ciklusokkal: a viszony: milyen a más tervezési ciklusokhoz az

informatikai stratégiatervezésnek a viszonya? q Projekt megközelítés: mi a megfelelõ módszerbeli indulási pont? Induljunk el a 'Az

informatika jelenlegi stratégiai felhasználása', vagy 'Az informatika jövõbeli stratégiai felhasználása', vagy a 'Stratégiai adattervezés' szakasztól? q Témakör kiterjedés: a tervezést leszûkíthetjük bizonyos témakörökre. Például

lehetséges, hogy egy szervezeten belül csak a pénzügyi területet vizsgáljuk. q Idõtávlat: milyen idõtávra fog az elkészítendõ terv vonatkozni? Ritkán érdemes

három évnél rövidebb, illetve öt évnél hosszabb idõre tervezni. q Terv: amikor az informatikai stratégiatervezési projekt idõtávlata és kiterjedése már

tisztázott, akkor egy részletes projekttervet kell elkészíteni. A tervben fellelhetõ lesz:

- a projekt elfogadott megközelítése, - az interjúalanyok személyei, - az elõzetesen meghatározott projektszerepek betöltõinek a nevei, - a vizsgálandó területek felsorolása, - a projekt során alkalmazandó technikák meghatározása, - részletes tevékenységterv, - a technikai személyzet nevesítése, és legalább egy nem számítástechnikai szakember kinevezése, ideális esetben projektirányítóként,

- a projekt tervezett határideje, - oktatási/tanácsadási szükségletek megbecslése, nevesítése. Az itt ismertetendõ módszer alkalmazásának javasolt ideje legfeljebb 6 hónap. A szokásos lefutási idõ 6 hét és 3 hónap között van.

Adatgyûjtés Ez általában egyszerû tevékenység, és a szervezet azon részeinek a feltérképezését jelenti, melyekre a tervezés kiterjed. Az alábbi információk kerülnek rögzítésre: q szervezeti egységek, pl. pénzügy, személyzeti osztály stb. q szervezeti struktúra, q kulcsemberek és szerepük a szervezeti egységekben (az interjúk számára). q mûködési területek, q funkciók és tevékenységek, pl. szerzõdéskötés, készletfeltöltés,

Bevezetés

8

q létezõ és fejlesztés alatt álló számítógépes rendszerek, q rendszerek/tevékenységek/mûködési területek közötti kereszthívatkozások,

Stratégiai követelménytervezés A stratégiai követelménytervezés az alábbi három lépés végrehajtásából áll: q Az informatika jelenlegi felhasználásának elemzése a szervezeten belül. q Elemzési technikák, interjúk és az elsõ lépés eredményeinek a felhasználásával a

rangsorolt szervezeti célok egy halmazának, illetve a célok elérését lehetõvé tevõ informatikai feladatkitûzések azonosítása. q A szervezet által megvalósítandó, rangsorolt projektspecifikációk formájába történõ

átalakítása az elsõ két lépés eredményeinek. Ezeket a lépéseket részletesebben is ismertetjük az alábbiakban.

Az informatika jelenlegi felhasználásának elemzése Ez lényegében egy felmérõ jellegû lépés, melynek során a szervezetet vizsgáljuk meg annak érdekében, hogy az információtechnológia jelenlegi hasznosulását értékeljük. A vizsgálatokat a mûködési területek, a területeken végzett tevékenységek és a tevékenységek elvégzését segítõ rendszerek tekintetében végezzük el. A vizsgálatok után több lényegi megállapítás születik majd meg. Ezek közé tartozik: q a jelenleg érvényes mûködési stratégiák felmérése, q a mûködési területek fontosságának megállapítása a szervezet számára, q az a mód, ahogy a vezetés jelenleg kezeli az informatikát, q azoknak a tevékenységeknek az értékelése, amelyekre érdemes tûnik informatikai

támogatást biztosítani. q a jelenlegi rendszerek szerepe és hatékonysága,

Az informatika jövõbeli szerepének elemzése A stratégiai követelménytervezés második lépése a jövõbeli stratégiai célok és az ezek eléréséhez szükséges feladatok meghatározását tûzi ki célul. A folyamat az alábbi lépésekbõl áll: q A szervezet jelenlegi mûködési módjának, stratégiájának átbeszélése a felsõ

vezetéssel. q A mûködési területek kritikus sikertényezõinek az egyeztetése vagy azonosítása,

valamint a kritikus feltételezések feltérképezése. q A mûködési területeken stratégiai elemzés végzése azért, hogy megállapíthassuk,

hogy az információtechnológiát hol és hogyan lehetne használni úgy, hogy ebbõl a lehetõ legnagyobb haszon származzon. q Az információtechnológia költséghatékony alkalmazási módjainak a meghatározása

minden egyes mûködési területre. q A kulcsszereplõkkel struktúrált interjúk lefolytatása, melynek során megállapításra

kerülnek:

- a szervezeti célkitûzések, melyeknek közük van a hatékonyság javításához, - azok az elképzelések a jövõrõl, melyek mérhetõ, igazi célokat fednek,

MTA Információtechnológiai Alapítvány, 1993

- azok az informatikai tevékenységek, melyek szükségesek a célok eléréséhez. A folyamat részeként a célokat feladatkitûzésekké formáljuk, melyek formája lehet: q fejlesztési projekt, q megvalósíthatósági tanulmány, q mûszaki értékelés, q technológia bevezetés, q szervezeti változás, q módszer, szabvány és koncepció bevezetése.

Az itt ismertetésre kerülõ módszert úgy tervezték, hogy biztosítsa azt, hogy a tervezett jövõbeli informatikai tevékenységek q a szervezet mûködési stratégiájának megfelelnek, q a

hatékonyság növelése, annak támogatásának szempontjait figyelembevevõ megfontolások eredményeképp születnek meg,

q olyan tevékenységekre koncentrálnak, melyek informatikával történõ támogatásából a

szervezet leginkább elõnyt fog élvezni, amennyire ez lehetséges. Ezenkívül a módszer kéri annak tudatos eldöntését is, hogy a szervezet vezetésének mi a legalkalmasabb hozzáállási módja az informatikához a szervezeti szükségletek szempontjából.

Kezdeti terv elkészítése A stratégiai követelménytervezés harmadik lépésében a feladatkitûzéseket rangsorolt projektspecifikációkká alakítjuk át, melyek tartalmazzák a felmerülõ költségek, elõnyök, határidõk és fejlesztési erõforrásigények részleteit. Ezek a projektspecifikációk tulajdonképpen az informatikai projektek 'mini' leírásai. A rangsorolás vagy szubjektív szempontok alapján, vagy számszerûsítéssel végzendõ el. Egy kiinduló (6-12 hónapos) idõegységekre bontott fejlesztési terv készül el a projektspecifikációknak fázisokra történõ csoportosításával.

Stratégiai adattervezés A stratégiai adattervezés három lépésbõl áll: q az ideális adatmodell felállításából, q a fizikai adatmodell megszerkesztésébõl, q adatáttérési terv elkészítésébõl.

Ideális adatmodell felállítása Az adattervezés a szervezet ideális adatmodelljének (Ideal Data Model - IDM) felállításával indul, melyet a jelenlegi implementációkból adódó megszorítások figyelmen kívülhagyásával kell elkészíteni. Ennek során különbözõ adatmodellezési technikákat fogunk használni. Az IDM a szervezet valóságos, 'generikus' adategyedeit (amikrõl adatokat tárolnak, pl. bûnözõ, beteg stb.) és a közöttük levõ kapcsolatokat szemlélteti. Ez valójában egy ideális, elképzelt állapot logikai szemléltetése. A gyakorlatban az IDM elérése csupán egy idealizált cél, melyet nem lehet költséghatékonyan megvalósítani. Az adattervezési folyamat rákényszeríti a tervezõt arra, hogy a modell megvalósítási költségeit és a megvalósításból származó elõnyöket

Bevezetés

10

értékelje, és segít egy megfelelõ kompromisszum kialakításában. Az IDM jellegzetességei az alábbiak: q a stratégiatervezési projekt kiterjedésében levõ összes rendszer összes adatát együtt

kezeli, q nincs benne redundancia, q kizárólag logikai leírást tartalmaz, a fizikai megvalósítás megszorításaitól független, q tartalmazza a szervezet meghatározó, generikus adategyedeinek a meghatározását.

Fizikai adatmodell megszerkesztése A stratégiai terv készítésének alapvetõen fontos tényezõje annak lépésrõl-lépésre történõ bemutatása, hogy a létezõ adatszerkezet hogyan fog átalakulni egy jövõbeli állapotba. Nem sok értelme van pusztán egy ideális, megcélzott állapot bemutatásának a vezetés számára, ha egyrészt nem vagyunk képesek rámutatni arra, hogy a jelenlegi állapot miben különbözik az ideálistól, másrészt hogy hogyan fogunk áttérni az elképzelt, ideális állapotra. A változásra tervezés alapproblémája, hogy hacsak nem egy 'õsrobbanás' (teljes 'tabula rasa') jellegû fejlesztéssel állunk szemben, akkor a jelenlegi helyzet letisztult képével kell rendelkeznünk annak érdekében, hogy meg tudjuk tervezni a módosítások végrehajtását. Sok szervezetben az adatok jelenlegi szerkezetének ismerete meglehetõsen felületes és ködös. Könnyen elképzelhetõ, hogy a szervezetben állományok zagyvaléka található, melyek információtartalma meglehetõsen redundáns és többértelmû. Az elhúzódó problémák Pandora-szelencéjének felnyitása mindig hálátlan feladat, és a fejlesztõk érthetõ módon húzódoznak attól, hogy túl sok erõfeszítést öljenek bele olyan rendszerek dokumentálásába, melyekrõl köztudott dolog, hogy kiváltásra fognak kerülni. Amire tehát szükség van, az egy viszonylag kis ráfordítást igénylõ módja a meglevõ, 'implementált' adatszerkezet leírásának. Az ismertetésre kerülõ stratégiatervezési módszerben ez az ún. fizikai adatmodellezési technika keretein belül kerül megvalósításra. Több lényeges szempont került figyelembevételre a technikában. q Ha viszonylag kézenfekvõ szabályokat és technikákat használunk, úgy az adatmodell

elkészítése meglehetõsen egyszerû. q A modell elkészítése nem igényel túlzott idõ- és erõforráslekötést. q A fizikai adatmodell (Physical Data Model - PDM) a jelenlegi adatszerkezetnek logikai

leírását nyújtja. Így a Munkacsoport tagjai az éppen használatos állománykezelõ és/vagy adatbáziskezelõ technikai részleteinek ismerete nélkül is tudnak modellezési tevékenységeket folytatni. q Az alkalmazott állománykezelõ és/vagy adatbáziskezelõ eszközök keverékétõl

függetlenül, a PDM egységes logikai leírási módot használ az egyedek és a közöttük levõ adatkapcsolatok szemléltetésére. q A PDM felszínre hozza az adatredundanciákat illetve más, meglevõ rendszerekben

rejlõ problémákat. q A PDM kiindulási alapot

képez az adatáttérési terv elkészítésére, mely a redundanciák eltüntetésére és egy egységes adatkörnyezet megteremtésére irányul.

Kivonatos adatmodellek A kivonatos adatmodellek (summary data model) iránt fellépõ igény különösen MTA Információtechnológiai Alapítvány, 1993

szembeötlõ, hiszen a stratégiai adatmodell elkészítésekor gyakran igen nagy, akár több száz egyedet és kapcsolatot tartalmazó modellekhez juthatunk. Ebben a módszerben az adatcsoport-modellezésnek (clustering) nevezett technika áll rendelkezésre összegzõ adatmodellek készítésére. Ennek a technikának az a lényege, hogy útmutatókat ad arra, hogy egy adatmodellt hogy lehet kezelhetõ méretûvé 'összenyomni'. A technika ezenkívül olyan szabályokat is rendelkezésünkre bocsájt, melyek azt írják le, hogyan lehet az adatcsoport-modellezés elveit a részadatbázisok (subject databases) meghatározásakor felhasználni. Az adattervezési módszer ezenkívül még segítséget ad az adatelosztás (data distribution) típusainak meghatározásában, annak elemzésében.

Adatáttérési terv A stratégiai adattervezés elsõ két lépésének befejeztével a tervezõ kétfajta adatmodellt készített el. Az egyik a jelenlegi helyzet visszatükröztetése, a másik egyfajta idealizált kép a szervezeti adatok áttekintésén alapul. A következõ feladat annak meghatározása, hogy a szervezet milyen módon fog a jelenlegi helyzetbõl az ideális irányában a lehetõségekhez képest minél 'közelebb' elmozdulni. Várhatóan a jelenlegi helyzetbõl az ideálisra történõ áttérés belsõ 'lépcsõfokokon' keresztül fog megtörténni. A módszer elõírásai szerint minden ilyen belsõ lépcsõfokot egy átmeneti adatmodell (Transition Data Model - TDM) ír le. Egy ilyen modell egy féltõl egyéves idõtartamig terjedõ fejlesztés eredményeit fogja felölelni. Az utolsó átmeneti modell lesz a cél, amely rendszerint 'közel' lesz az ideálishoz. A célzott modellt a jelenlegi adatszerkezetben rejlõ problémák azonosításával, valamint annak értékelésével származtatjuk, hogy a kiinduló vázlatos informatikai stratégiai tervben szereplõ szükségletek milyen módon érhetõk el az ideális adatszerkezet által. Összefoglalva, az adattervezési folyamat tartalmazza : q A projekt kiterjedésébe esõ mûködési területeknek a vizsgálatát egy olyan áttekintõ

és precíz adatmodell elkészítése által, mely megfelel a szervezet feladatainak, nem tartalmaz redundanciát, ellentmondásokat vagy fizikai jellegû megszorításokat. q A

szervezetbeli jelenleg megvalósított adatszerkezetek vizsgálatát, melyekbõl alkalmas szabályok alkalmazása után a jelenlegi adatmodell leírásához jutunk. Ez a modell várhatólag átfedéseket, inkonzisztenciát és eltéréseket fog kimutatni a szervezeti szükségletek és a meglevõ adatmegvalósítások között.

q Megfontolását

egy tudatosan irányított (menedzselt) adatkörnyezetbõl adódó következményeknek. A menedzselendõ környezet elemei közé tartoznak az adatelosztás, részadatbázisok, adatbáziskezelõrendszerek és adatszervezés területei.

q A jelenlegi és az ideális adatmodellek összevetését, a problémák és különbségek

felfedését. Ez utóbbi folyamatnak, a tudatosan irányított adatkörnyezet elérését célzó meggondolásoknak, és a kezdeti projektspecifikációknak az alapján egy olyan adattervet kell elkészíteni, mely megfelel a szervezet célkitûzéseinek.

Részletes terv elkészítése A módszer által elõírt elõállítandó kulcsdokumentum egy fejlesztési terv. A terv fõ alkotóelemei közé az alábbiak tartoznak: q Informatikához kapcsolódó, rangsorba rendezett projektek leírásai, egy fázisokra

szakaszolt terv keretében. Ezeknek a leírásoknak, avagy 'projektspecifikációknak' tartalmazniuk kell a rangsor kialakításában közrejátszó szempontoknak és a kockázatoknak részletes elemzését. A specifikációk olyan területeket fednek le, mint:

Bevezetés

12

- az informatika jövõbeli használata, annak érdekében, hogy a hatékonyságot növeljük, a költségeket csökkentsük, a szolgáltatásokat mássá tegyük,

- a módszereknek, módszertanoknak a jövõbeli használata az informatikai funkció hatékonyságának a növelése érdekében. Ilyen módszer alkalmazható pl. projekt tervezés és becslés, 4. generációs nyelvek alkalmazása, struktúrált módszerek és CASE eszközök, minõségirányítás területein. q Minden egyes fejlesztési fázisra elkészül a hozzátartozó 'adatstratégia', az egyes

fázisbeli projektspecifikációk és az átmeneti adatmodellek formájában. q A megvalósíthatósági tanulmányok és technikai értékelések rangsorba rendezett

felsorolása. A kulcsdokumentumon túl, a projektspecifikációk elkészítésekor felhasznált dokumentumok is a vezetés rendelkezésére fognak állni. Ilyenek lesznek (minden egyes mûködési területre): q az alkalmazandó mûködési stratégia nevesítése (ez lehetséges, hogy már a

vezetéssel átbeszélésre és egyeztetésre került), q a kritikus sikertényezõk (KST-k) listája és azok a kritikus feltételezések, melyekre a

KST-ket alapoztuk, q a

kulcscélok listája, és minden egyes célra azok a javasolt informatikai tevékenységek, melyek szükségesek az elõrehaladáshoz.

A felsorolt információk szerinti bontásban is lehet összegezni az elemzések eredményeit, és ezt az módot alkalmazni fogjuk a kézikönyvben. Egy másik lehetõség az, hogy a módszer alkalmazása során gyûjtött információkat és elemezéseket pontosan olyan módon rendszerezzük, ahogy azt 'Az informatikai stratégia kialakításának és megvalósításának irányelvei' c. dokumentumban megadott tipikus jelentések elõírják. Ezért az egyes szakaszokat ismertetõ fejezetekben (rendszerint a fejezet végén) mindig utalni fogunk arra, hogy mely jelentések készíthetõk el, vagy módosíthatóak az irányelvekben meghatározottak közül az adott szakaszban megszerzett tudás alapján. Ezeknek a jelentéseknek az elkészítése során nem csak az elemzések eredményét használjuk fel, hanem lehetõség szerint a lényeget kiemelõ, szöveges részekkel is el kell látni õket, ha ez szükséges.

MTA Információtechnológiai Alapítvány, 1993

2 Tervezés, behatárolás és adatgyûjtés Három lépést kell végrehajtani az ismertetendõ informatikai stratégiatervezési módszer elsõ szakaszában, úgymint: kiinduló terv elkészítése, végleges terv elkészítése és a technikák oktatása. A továbbiakban a projektszerepek ismertetése után ezeket a lépéseket fogjuk ismertetetni.

Projektszerepek Célszerû áttekinteni a módszer által elõírt, a stratégiatervezési projekt végrehajtása során betöltendõ szerepeket még azelött, hogy részletesen megvizsgálnánk a tervezési és behatárolási szakaszt. Sokféle szerepet kell betölteni a projekt során, ezek rövid értelmezését adjuk közre az alábbiakban. A szerepeket és a projektben elfoglalt helyüket az általuk elvégzendõ tevékenységek és technikák leírásával határozzuk meg. A szerepek az alábbiak: Megbízó. Ez alapvetõ fontosságú szerep. A Megbízó képviseli a szervezetnek azt a részét, ahol a stratégiai tervezést végrehajtják. A Megbízónak érdekében áll az, hogy a projekt sikeres legyen, és elvárjuk tõle azt, hogy a lehetõ legnagyobb mértékben segítse

Bevezetés

14

a munkák elõrehaladását. Ahol nincs olyan vezetõ, aki nyilvánvalóan betölthetné a Megbízó szerepét, egy rangidõs és felelõs személyt ki kell nevezni erre a feladatra. A Megbízónak hinnie kell a projektben, és feltétlenül érdekelt kell legyen a projekt sikerességében. Projektirányító. Úgy véljük, hogy amennyiben a Projektirányító nem az informatikai részleg személyi állományából kerül kijelölésre, az nagyban segíti a projekt elfogadtatását és végsõ soron a megfogalmazandó stratégiai terv megvalósítását. A Projektirányítónak kellõen motiváltnak kell lennie a projekt munkálataiban történõ részvételében, és rendelkeznie kell a szükséges képességekkel. A Projektirányítónak fel kell arra készülnie, hogy munkaidejének legalább 30%-át erre a munkára kell fordítania. A Projektirányító fogja elsõsorban a Tanácsadóval a kapcsolatot tartani. Zsûri. Ebben a csoportban az egyes mûködési területeket képviselõ rangidõs vezetõk foglalnak helyet. A Zsûri feladata lesz az informatikai stratégiai terv kialakítása során elõálló dokumentumok (termékek) véleményezése, szemlézése. A projekt során kb. 4-5 alkalommal kell a Zsûrinek összeülnie. Munkacsoport. A projektbeli résztvevõk olyan személyek legyenek, akik különbözõ területeken rendelkeznek tudással. A Munkacsoportban együtt kell dolgozzanak a szervezetnél folyó tevékenységek ismerõi, a felhasználók, és a technikai szempontokat (az adattervezési módszereket is) szem elött tartó tervezõk; nyilván kívánatos lenne közöttük egy megfelelõ arány elérése. Ha a szükséges képzettség nem áll rendelkezésre, úgy külsõ szakértõk bevonása lehetséges (lásd lejjebb is). Általában azonban elõnyben részesítendõ a belsõ erõforrások minél nagyobb mértékben történõ kihasználása. Területi reprezentáns. Minden mûködési területen ki kell jelölni legalább egy személyt, aki(k) a munkacsoport egyes kulcstevékenységeiben részt vesz(nek). Ez kiemelten fontos szerep, amelyet megbízható, mértékadó személyekkel kell betölteni, akikre lehet számítani, hogy tevékenyen fogják képviselni a mûködési területeik érdekeit. Az adott mûködési terület kellõ ismerete természetesen nélkülözhetetlen feltétel. Informatikai szóvivõ. Az informatikai stratégia elõkészítését szolgáló interjúk során minden mûködési terület ki kell állítson egy Informatikai szóvivõt, aki helyettük tud szólni az informatikai stratégia kialakításakor felmerülõ kérdésekben. Az Informatikai szóvivõnek ismeretekkel kell rendelkezni az informatikában, illetve az informatikának az adott mûködési területen történõ alkalmazásában. Határozott elõnyt jelenthet a jelenleg elérhetõ technológiák ismerete. Adattervezõ. A Munkacsoport legalább egy tagjának fel kell vállalnia az adattervezési tevékenységekbõl adódó felelõsségeket. A Munkacsoport több más tagja is várhatólag dolgozni fog adatokkal kapcsolatos munkákon, de kell lennie legalább egy személynek, aki megalapozott ismertekkel rendelkezik az adatmodellezés, a relációs adatelemzés és a fizikai adattervezés terén. Fájlkezelõ rendszerek, illetve a szervezet által használt adatbáziskezelõ szoftver(ek) használatában való jártasság különösen elõnyösnek bizonyulhat. Interjúalanyok. Õk azok a vezetõk, vagy kulcsemberek, akik részt fognak venni az interjúkban. Ugyancsak feladataik lesznek majd szemlék utáni tevékenységek kijelölésében. Könnyen lehetséges, hogy sokan fogják nemcsak az Interjúalany szerepet, hanem a Területei reprezentáns és/vagy a Zsûritag szerepét is betölteni. Tanácsadó. Ezt a szerepet a módszert jól ismerõ szakember tölti be. Ez a szerep különösen fontos lehet a szervezetbeli elsõ informatikai stratégiai tervezési projekt lefolytatásakor. A Tanácsadónak jól kell ismernie a módszert és annak technikáit. A Tanácsadó segíti a Projektirányítót a tervezési tevékenységek ellátásában, illetve hozzájárulhat tapasztalatával a projekt különbözõ szakaszaiban elvégzendõ munkálatokhoz.

MTA Információtechnológiai Alapítvány, 1993

Külsõ szakértõ. Nem várható el, hogy minden egyes területen rendelkezésre álljon a megkívánt szakértelem a Munkacsoporton belül, ezért a stratégiatervezési projekt során szükséges lehet specialisták (szakosodott külsõ szakértõk) bevonása. Ilyen lehet pl. a távközlés, az ügyviteltámogatás, az architektúrális kérdések területe. Ezeket a területeket ideális esetben a projekt tervezésekor kell felmérni, illetve menet közben is elképzelhetõ ad-hoc módon a specialisták felkérése.

Kiinduló terv elkészítése A módszer alkalmazása elött szükséges némi elõtanulmányokat végezni annak érdekében, hogy egy részletes projekttervet és feladatleírást el lehessen készíteni. A kiinduló terv elkészítése általában kettõtöl öt napig terjedõ idõtartamot vesz igénybe, és az alábbi kérdésekre adott válaszok (írásos) dokumentálását, mint kulcstermék elkészítését irányozza elõ:

q Célok: mik a felsõ vezetés által elõírt célkitûzései a projektnek? q Szervezeti kiterjedés behatárolása: mely mûködési területekre fog a stratégiai tervezés kiterjedni? Hány stratégiára lesz szükség, és mi lesz ezeknek az egymáshoz való viszonyuk?

q Milyen a más tervezési ciklusokhoz az informatikai stratégiatervezésnek a viszonya? q A projekt megközelítésének meghatározása: a módszer mely részei kerülnek felhasználásra?

q Témakörök behatárolása: mely témaköröket kellene kihagyni? q Idõtávlat: milyen hosszú a stratégiatervezés idõhorizontja? q Szerepek

betöltése: követelmények?

mik

a

munkacsoport

tagjaival

szemben

támasztott

q Oktatási igények: kiket, milyen mélységben kell informálni a tõlük elvárt szerepekrõl? A kédesekre adott válaszok alapján kell felvázolni a projekttervet. Elõreláthatólag egy sor feladatot kell elvégezni a kiinduló terv elkészítése során. A feladatok kiadatását gyakran a Tanácsadó kezdeményezi. A feladatokat az alábbiakban részletezzük.

Tájékoztató ülés Ez a módszert alaposan ismerõ specialista (aki gyakran a Projektirányító vagy a Tanácsadó) és a Megbízó között zajló megbeszélés, melynek során elõkészítik a stratégiatervezési projektet, és a Megbízó számára ismertetik azokat a javasolt feladatokat, melyek a stratégiatervezési módszernek az adott szervezetnél történõ alkalmazásából adódnak.

Kiinduló ülés Gyakori eset az, hogy a stratégiatervezési projekt indításakor a szervezet vezetõi vajmi keveset tudnak arról, hogy mi várható el egy ilyen tervezés lefolytatásától. A kiinduló ülésen azok vesznek részt, akik várhatólag valamilyen szerepet fognak projektben betölteni. Az ülés során a módszert alaposan ismerõ specialistának, vagy a Tanácsadónak fél-egy órás elõadást kell tartania, melyben megmagyarázza a kiinduló tervezés célkitûzéseit. Az ülés feladatai közé tartozik

q az elõadás megtartása, q minden egyes résztvevõ elképzelésének meghallgatása arról, hogy mit vár el a projekttõl. A specialistának (vagy Tanácsadónak) feljegyzéseket kell készíteni

Bevezetés

16

ezekrõl. Nem az a cél, hogy ezeket a rövid ismertetõket komoly interjú gyanánt kezeljük! Ez csupán lehetõséget nyújt arra, hogy a résztvevõk elmondhassák elképzeléseiket. Egy résztvevõ lehetõleg ne beszéljen 3 percnél tovább!

q amennyiben lehetséges, a kulcsszereplõk kinevezése, úgymint: a Megbízó személyének véglegesítése, aki a Tanácsadó számára a szervezet legfontosabb képviselõje lesz, a Projektirányító kinevezése (lehet ugyanaz a személy, mint a Megbízó), egy-két munkacsoporttag delegálása a szervezeten belülrõl.

Kulcsemberek ülése Az elsõ ülésen kijelölésre került összes kulcsszereplõ részt kell vegyen ezen az ülésen, azaz a Megbízó, a Projektirányító, egy-két Munkacsoportbeli tag, és a Tanácsadó (ha ez a szerep is betöltésre került). A célja az ülésnek az, hogy a stratégiatervezési projekt terjedelmének nagyságáról egy kiinduló képet nyerjen.

q Határoljuk be a szervezeti kiterjedését a projektnek! A stratégiatervezés legtöbb tevékenysége a mûködési területek fogalmának felhasználásával történik. A felteendõ kérdések közé tartozik: Ä

Valóban fel lehet-e a szervezetet különbözõ mûködési területekre osztani?

Ä

A mûködési területek által nyújtott szolgáltatások azonos módon jelennek-e meg a külvilág felé, vagy szükséges-e egyes mûködési területek további bontása alsóbb szintû egységekre? (A több mûködési területre nézve azonos szolgáltatási funkciókat lehet egyetlen mûködési területként kezelni, pl. számvitel, személyzet stb.)

Ä

Melyek azok a mûködési területek, melyek várhatólag a stratégiatervezés körébe esnek?

Gyakran hasznos tanulmányozni a döntés elött a szervezet szervezeti-funkcionális felépítését leíró ábrákat. Lehetséges, hogy a szervezet bonyolultsága miatt több stratégiatervezési projektet kell indítani. Ebben az esetben a projektek elkülönülnek, és az összes projekt lezárásának a végén külön figyelmet kell majd fordítani az eredmények harmonizálására. A majdani harmonizálási tevékenységek által támasztott követelményeket figyelembe kell venni már az egyes stratégiatervezési projekteknél. Mi a továbbiakban azt az egyszerûbb esetet követjük, amikor csak egyetlen projekt indul.

q Vizsgáljuk meg a szervezet más tervezési ciklusait, és határozzuk meg az informatikai stratégiai tervezés ezekhez való viszonyát! Ne feledkezzünk el arról, hogy informatikai stratégiát kell megfogalmazni, és nem szervezeti stratégiát. Minthogy az informatika felhasználását a szervezeti célkitûzésekbõl kell levezetni, ezért a szervezet jövõképérõl ismereteket kell majd szerezni. Át kell tekinteni azt is, hogy az informatikai és más stratégiatervezési ciklusok milyen módon mûködnek a szervezetnél, és milyen szervezeti háttér mûködteti õket.

q Döntsük el a projekt megközelítési módját! Ennek érdekében a módszert alaposan ismerõ specialistának, vagy a Tanácsadónak el kell magyaráznia a módszer három lehetséges indítási módját, amelyek az alábbiak: 1. Teljeskörû tervezés lefolytatása, mely kiterjed a stratégiai követelménytervezésre és adattervezésre egyaránt. 2. Egyes szervezeteknél elõfordulhat, hogy a stratégiatervezés bizonyos részeit már elvégezték és interjúkat folytattak le. A tervezés ebben az esetben kezdõdhet a célok és a feladatkitûzések meghatározásával, melynek során támaszkodhatnak a már elkészített dokumentumokra. MTA Információtechnológiai Alapítvány, 1993

3. Lehetséges az is, hogy a stratégiai követelménytervezést már elvégezték, és a projekt felhasználhatja ennek eredményeit kiindulási pontként a stratégiai adattervezésnél. Döntést kellene hozni ezen az ülésen arról, hogy hogyan (a módszer mely részénél) fog elkezdõdni a stratégiatervezési projekt.

q Határoljuk be a vizsgálandó témaköröket! Elõfordulhat, hogy bizonyos témaköröket

minden mûködési területen kihagyunk a tervezésbõl (pl. személyzeti kérdések). Ne feledjük, hogy témakörök elhagyása csökkentheti a tervezésbõl származó elõnyök nagyságát!

q Döntsük el a stratégiatervezés idõtávlatát ! Ritka az az eset, amikor érdemes három évnél rövidebb, vagy öt évnél hosszabb idõre tervezni. Kormányzati tervek esetében néha elõfordulhat a tíz éves idõtávlat is, mert az ottani projektek hosszú kifutásúak, fázisokra bontottak.

q Határozzuk meg, hogy a KST-k tekintetében milyen megközelítést javasolunk a vezetésnek! Négy lehetséges megközelítési módot különíthetünk el: 1. használjunk fel már elõre meghatározott KST-ket vagy 2. térképezzük fel a KST-ket a stratégiatervezés elvégzése elötti tevékenység keretében vagy 3. határozzuk meg a KST-ket a stratégiatervezési módszer 'Az informatika jövõbeli stratégiai alkalmazása' szakaszában vagy 4. tekintsünk el a KST-ktõl, az interjúk során csak a célok megfogalmazására törekedjünk. A Munkacsoport csak kellõ körültekintéssel ajánlhatja az utolsó lehetõséget a vezetés számára. Csak abban az esetben lehet ezt az utat biztonsággal járni, ha a vezetés bizonyos abban, hogy a szervezetre nem lesznek hatással ujonnan felfedett KST-k. Ez egyaránt vonatkozik a szolgáltatások területére, a ügyfelekre, a beszállítókra, a személyzetre stb. Amennyiben a második és harmadik lehetõség között választunk, a Munkacsoportnak figyelembe kell vennie a vezetés véleményét. Ha úgy vélik, hogy a KST-k meghatározása lényegében elvégezhetõ a szervezeten belül, azaz interjúk és megbeszélések lefolytatásával, akkor ésszerû lehet a KST-k meghatározását a stratégiatervezési projekten belül elvégezni. Ha azonban úgy tûnik, hogy a KST-k megállapítása érdekében szükséges a szervezeten kívüli tényezõket is megvizsgálni, pl. ügyfeleket vagy beszállítókat megkérdezni, vagy egy alapos társszervezet vagy felhasználói elemzést kellene elvégezni, akkor egy elkülönült KST-ket meghatározó tevékenységet kell lefolytatni. Ebben az esetben azt is tudatosítani kell, hogy egy ilyen tevékenység lényeges idõcsúszással járhat, még mielött a stratégiatervezési munka elindulhatna.

Felsõvezetõi ülés Ezt az összejövetelt annak a vezetõnek szervezik, aki a projekt által érintett, és a szervezeti hierarchiában legmagasabb helyet foglalja el. Minisztérium esetében ez a személy lehet pl. maga a miniszter, vagy a közigazgatási államtitkár, vagy más, megbízott személy. Ajánlatos, hogy ezen a megbeszélésen vegyen részt a Megbízó, a Projektirányító és a Tanácsadó. Amennyiben a Projektirányító személyét nem nevezték még ki, akkor ennek az ülésnek a végére ezt feltétlenül meg kell tenni. Az ülés feladatai közé tartozik:

q a kulcsemberek ülésén elfogadott megállapítások bemutatása, azaz a projekt

megközelítésének, szervezeti és témaköri határainak valamint idõtávlatának meghatározása. Ezenkívül ismertetni kell még a KST-k kezelésére vonatkozó

Bevezetés

18

ajánlást.

q A vezetõ az ismertetés után reagál az elmondottakra, annak kinyilvánításával, hogy mik az õ elvárásai a projekttõl. Megerõsítheti a hallottakat, vagy kérheti azok módósítását is. A Munkacsoportnak fel kell jegyeznie a vezetõ elvárásait és megjegyzéseit.

További vezetõkkel történõ megbeszélések Minden egyes mûködési terület vezetõjével és/vagy képviselõjével találkoznia kell a Projektirányítónak, és ha ez szükséges, a módszert alaposan ismerõ specialistának (vagy a Tanácsadónak) is. A találkozók célja a felsõvezetõi ülésen elfogadott körülmények, feltételek ismertetése, illetve a projektben kulcsszerepet betöltõ személyek kiválasztása folyamatának az elindítása. Az elvégzendõ feladatok közé tartozik:

q az elõzõ megbeszéléseken kialakított feltételrendszer ismertetése, q a mûködési területek vezetõinek a projekttel szemben támasztott elvárásainak az ismertetése,

q a

kulcsszerepek lehetséges betöltésére alkalmas személyek körének meghatározása, habár a konkrét személyek megnevezése még nem feltétlenül szükséges ezeknek a megbeszéléseknek a során. A szerepek tartalmazzák

·

a Területi reprezentánst,

·

az Informatikai szóvivõt,

·

a Zsûribeli képviselõt.

q Összeállítandó az interjúalanyok listája. A mûködési terület vezetõje nevezi meg

azokat a személyeket, akiket meg kell majd kérdezni. Tartsuk szem elött azonban, hogy az interjúkészítés várhatólag a legidõigényesebb tevékenység, ezért az interjúkat a lehetõségek határain belül minimalizálni kell.

Meglevõ rendszerek katalogizálása Ez gyakran elvégezhetõ a Kiinduló ülésen kinevezett munkacsoport-tagok segítségével. Ekkor még nem a rendszeradatok gyûjtése a cél, hanem azon rendszerek számának áttekintése, melyek a stratégiai adattervezés körébe tartoznak. A módszer jól ismerõ specialista, vagy a Tanácsadó gyakran áttekinti ilyenkor egy vagy két jellegzetes rendszer adatállományait, azért hogy elképzelése legyen a jövõbeli munkálatokról.

Adatok értékelése Ezt a feladatot gyakran a módszert jól ismerõ Projektirányító egymaga végzi, esetleg a specialista, vagy a Tanácsadó segítségével. Az eddig összegyûjtött adatok, illetve a kitûzött feltételrendszer ismeretében megbecslésre kerül:

q a Munkacsoportbeli személyek kívánatos száma és képzettsége, q a vezetõk és interjúalanyok számára tartandó ismertetések száma és szintje, q ha szükséges, a módszerhez kapcsolódó oktatás(ok), kiképzés(ek) részletei, q a stratégiai adattervezés során alkalmazandó technikák köre, q külsõ szakértõk bevonása szükségességének a szintje.

MTA Információtechnológiai Alapítvány, 1993

Ismertetés, módosítás Az adatok értékelésének az eredményeit informális módon bemutatják a Munkacsoport tagjai számára, melynek eredményeképp ezek módosulhatnak.

Idõigény felmérése A Munkacsoportnak meg kell becsülnie a projekt kulcsfeladatainak az idõigényét (a kulcsfeladatok listája az A. függelékben találhatók meg), beleértve ebbe az erõforrásfelhasználást és a járulékos költségeket is. Ne felejtsünk el idõt hagyni az interjúkra történõ felkészülésre, valamint a stratégiai követelménytervezés közben lefolytatandó minõségi szemlékre!

Kiinduló terv A Projektirányítónak (a módszert ismerõ specialista igénybevételével, ha ez szükséges) el kell készíteni a lehetõ legrövidebb formátumban egy jelentést (a kiinduló projekttervet), mely a kiinduló tervezési munkák eredeményeit tartalmazza.

A tervezés véglegesítése Általában a projekt indulása és a kezdeti tervezés befejezésének idõpontja között van némi idõeltérés. Ez alatt az idõ alatt kell a projekt tervét véglegesíteni, melyet vagy a Tanácsadóval, vagy nélküle kell elvégezni. q Nevesíteni kell a projektszerepek betöltõit, azaz minden egyes mûködési területre ki

kell nevezni a Területi reprezentánst, az Informatikai szóvivõt és a Zsûritagot. q Ujabb személyeket lehet delegálni a Munkacsoportba. A kezdeti tervezés alatt csak

egy-két embert rendeltek hozzá a projekthez, de elképzelhetõ, hogy igény merült fel további munkatársak bevonására. Ha ez fordulna elõ, akkor ezt az igényt most kell kielégíteni. q Egyeztetni kell a felmért oktatási igényeket, az oktatások pontos kezdését, tartalmát,

a résztvevõk körét és az oktatások technikai feltételeit. q A projekt idõbeli ütemtervét át kell tekinteni a tényleges projektbeli szereplõk

figyelembevételével, és amennyiben szükséges, módosítani kell rajta. q Minden érintettel ismertetni kell a nevesített szereplõket, illetve a projekt részletes

tervét.

Adatgyûjtés Bevezetés Általában mindenfajta stratégiai tervezésnél problémát okoz az dokumentummennyiség, melyet összegyûjtenek. Két aranyszabályt érdemes itt megemlíteni:

q 'a lehetõ legkevesebbet gyûjtsük' és q 'csak akkor gyûjtsük, ha tudjuk, hogy használni fogjuk (a gyûjtött adatot)'. Egyébként pedig az informatikai stratégiatervezési módszer során az adatgyûjtés folyamatosan ellátandó feladat. A gyûjtött anyagok kétféle természetûek lehetnek: q szervezeti információk, melyek szükségesek a munkák elvégzéséhez, vagy

Bevezetés

20

q a projekt tevékenységeibõl származó dokumentumok.

Az adatgyûjtés során az adatokat öt témakörben gyûjtjük, úgymint: q szervezeti egységek és felépítésük, q személyek és szerepeik, q mûködési területek, q tevékenységek az egyes mûködési területeken, q a tevékenységeket támogató jelenlegi rendszerek.

Szervezeti egységek és felépítésük Az adatgyûjtés során feljegyezzük a szervezeti egységeket, és a közöttük fennálló hierarchikus kapcsolatokat. Csak olyan, alapvetõen jellemzõ információk kerülnek feljegyzésre, mint: q a szervezeti egység azonosítója, q az egység neve, q rövid leírás, q minden egyes egységre a felettes egység(ek) neve(i), azaz a szervezeti felépítés.

A gyakorlatban a szervezeti hierarchiáról szerzett tudásunkat arra használjuk, hogy pontosabban megállapíthassuk, hogy melyek a szervezet mûködési területei. Ez a téma bõvebben kerül kifejtésre a következõ részben.

Személyek és szerepek A projekt szempontjait szem elõtt tartva, csak azoknak a személyi adatainak feljegyzésében vagyunk érdekeltek, akik majd részvesznek az interjúkon. Feljegyzendõ a q személy azonosítója, q neve, q telefonszáma, q egyéb megjegyzések.

A konkrét személyek megkérdezését a szervezetben betöltött szerepe teszi indokolttá, ezért jegyezzük fel minden egyes személy szervezeti egységét.

Mûködési területek Ennek a lépésnek az a célja, hogy a tanulmányozandó szervezetet a megfelelõ mûködési területekre bontsuk. Az elsõ próbálkozások eredményei a késõbbi elemzések során esetleg módosulhatnak. A szolgáltatások elemzését megnehezíthetik azok a különbözõ módok, ahogy a szervezet mûködik. A profit-orientált szférában a pénzügyi és versenyképességi mutatók használata kézenfekvõ az elemzésben, míg non-profit szférában ezek a technikák alkalmatlanok lehetnek. Ez a megállapítás igaz lehet a profit-orientált szféra bizonyos szolgáltatási jellegû területeinek esetében is, ahol viszont a sikerességet inkább a munka hatékonyságával mérik, mintsem pénzügyi mutatókkal. Az egyszerûség kedvéért mind privát, mind közszolgálati szervezetek esetében egyöntetüen mûködési területekrõl fogunk beszélni. A legtöbb esetben egy szervezetet inkább több mûködési területek egységeként kell felfogni, mintsem egyetlen monolitikus egységnek, mert az egyes területek a többiektõl

MTA Információtechnológiai Alapítvány, 1993

különbözõ módon viselkednek, reagálnak eseményekre. Egy szervezetnek mûködési területekre történõ osztása a szervezet természetének mély ismeretét igényli. A mûködési területek olyan mûködõ részei egy szervezetnek, melyeket a többi résztõl függetlenül lehet vizsgálni. Minden egyes területnek jól összefogott egységként kell mûködnie, általában nyilvánvaló irányultsággal. Bizonyos szervezeteknél a megkülönböztetés alapja a nyújtott szolgáltatások, vagy elõállított termékek lehetnek. Egy termelõ cég esetében például elképzelhetõ az, hogy a mûködési területekre bontás az elõállított terméken alapul, úgymint fénymásolók, adatfeldolgozó gépek és tartozékaik szerint. Amikor megpróbáljuk azonosítani a mûködési területeket, akkor azt kell átgondolnunk, milyen módon tevékenykednek a feltételezett mûködési területek. A felteendõ kérdések közé tartoznak: q minden területet saját vezetõsége irányít, amely ellenõrzi a teljes terület célkitûzéseit

és mûködését? q a terület összes része ugyanolyan módon viselkedik?

Néha elõfordul, hogy az elemzõ rákényszerül a kezdetben feltételezett területek további bontására. A gyártó példában elképzelhetõ, hogy a fénymásolás, mint mûködési terület, túl tágnak bizonyul, mert a cég a kisteljesítményû és a nagyteljesítményû másolókat teljesen másképpen kezeli. A szervezeti egységek hierarchiája gyakran jó kiindulópontnak bizonyulhat a mûködési területek helyes kijelölésében. Vannak olyan szervezetek, melyek kimondottan mûködési területeik szerint kerültek struktúrálásra. Az államigazgatásban elõfordul, hogy majdnem teljesen azonos a mûködési területek szerinti bontás és a szervezeti egységek szerinti bontás. A szervezeti egységek hierarchiája azonban nem mindig esik pontosan egybe egy jól kezelhetõ, mûködési területek szerinti felosztással. Például megesett, hogy egy számítástechnikai cég esetében a szervezet az ügyfelek szerinti csoportosítás elve alapján épült fel, melyek bankok, más pénzügyi intézmények, gyártók és az államigazgatás voltak. Az elemzés során aztán kiderült, hogy nem ezek voltak az igazi mûködési területek, hanem cég szolgáltatásai szerinti bontás volt helyénvaló (stratégiai tervezés, rendszerelemzés és projektirányítás). Ebben az esetben a mûködési területek 'átmetszették' a szervezeti struktúrát. Az informatikai stratégiai tervezés során azonosított mûködési területeket a szolgáltatások szerint kell megfeleltetni, melyeket a szervezet megbízóinak és ügyfeleinek nyújt. Amikor a szervezetet egymástól elkülönülõ részekre próbáljuk bontani, óvakodjunk attól, hogy légbõl kapott szempontok alapján, mesterségesen szabdaljuk az egészet részekre! Gyakran ugyanis az az eset fordul elõ, hogy a stratégiatervezési projekt terjedelmében a teljes szervezet egyetlen mûködési területként kezelhetõ. Ez különösen akkor lehet igaz, amikor a stratégiatervezés csak a szervezet egyes részeire terjed ki, mint pl. pénzügyek vagy adminisztratív szolgáltatások területei.

Útmutatók A mûködési területek azonosításához adunk néhány jól használható tanácsot. Egy mûködési terület q a szervezetnek olyan része legyen, mely a szervezet egyéb részeitõl függetlenül,

önállóan tanulmányozható, q olyan rész legyen, mely nyilvánvaló irányultságú és egységként tevékenykedik, q általában saját vezetése mûködteti, amely a mûködési terület célkitûzéseit és

tevékenységét felügyeli, q alkalmanként szervezeti egység szerinti felbontáshoz illeszkedik (de ez nem

Bevezetés

22

feltétlenül igaz), q megfelel annak a szolgáltatásnyújtási módnak, ahogy a szervezet kiszolgálja

megbízóit és ügyfeleit.

Tevékenységek Az informatikai stratégiai tervezés során a mûködési területeket tovább bontjuk az ott végzett tevékenységekre. A legtöbb szervezeti egységben, a szolgáltatási tevékenységeket egy (idõben) szekvenciális "láncként" képzelhetjük el. A tevékenységeket néha nehéz felismerni. Fennáll annak veszélye is, hogy túl kicsi és specifikus tevékenységeket választunk, és így a tevékenységek százaihoz jutunk. Fordítva, ha a tevékenységek túl 'nagyok', akkor az elemzés ereje csökken.

Útmutatók Sok jól használható tanácsot lehet adni tevékenységek azonosítására.

q Egy tevékenységet általában egyetlen szervezeti egység hajt végre. Ez az egység lehet egy osztály, vagy specialisták csoportja mint pl. egy döntõbizottság.

q A tevékenység lényege: valamilyen átalakítási folyamat. A legegyszerûbb szinten egy

tevékenység során a nyersanyagbõl félkész alkatrészek, alkatrészek vagy kész munkadarabok lesznek. Ezenkívül lehet egy tevékenység bemenete egy probléma, a kimenete a probléma megoldása, vagy lehet a bemenet egy követelmény, a kimenet pedig egy specifikáció.

q Egyes szervezetekben a termékek elõállításának, vagy a dokumentumok útjának

követésével lehet azonosítani a tevékenységeket. A folyamat követésével az elemzõ megtalálhatja azokat az átalakítási pontokat, ahol a tevékenységek végbemennek. Ez azonban még nem elégséges indok arra, hogy a szervezet egészére részletes, többszintû adatfolyam ábrákat rajzoljunk! Ez gyakran túlságosan is sok ráfordítással járna a megszerezhetõ tudáshoz képest.

q Általában az elkülönülõ tevékenységek más és más módon kerülnek finanszírozásra. Egy tevékenység elvégzésének a költségét viszonylag egyszerûen el kellene tudni különíteni más költségektõl.

q Amikor egy mûködési területen belül keressük a tevékenységeket, ne feledkezzünk meg arról, hogy lehetnek direkt és indirekt módon kapcsolódó tevékenységek is! A szolgáltatást vagy termékeket elõállító tevékenységek direkt módon kapcsolhatók a szolgáltatáshoz, míg a minõség biztosítását ellátó tevékenységek, mint pl. a javítás, karbantartás vagy MEO indirekt jellegûek.

q Egy más módja a tevékenységek azonosításának azon helyek felderítése, ahol számottevõ költségek lépnek fel. A lényegi költséggel járó területek szinte mindig valamilyen tevékenységre utalnak.

Rendszerek Az itt ismertett informatikai stratégiatervezési módszerben a 'rendszer' szó igen általános értelemben értendõ. A rendszer szó utalhat: q információs rendszerre (meglevõ vagy éppen fejlesztett), pl. megrendelésfeldolgozás,

raktározás stb. q csomag, mely ellát bizonyos folyamatokat és számítástechnikát használ, pl. integrált

irodaautomatizálási rendszer. Minden egyes mûködési területen fel kell kutatni a jelenleg használatos rendszereket, beleértve ebbe azokat is, melyek átlépnek a területek határain. Ezeket az adatokat mind MTA Információtechnológiai Alapítvány, 1993

a stratégiai követelménytervezés, mind a stratégiai adattervezés során fel fogjuk használni (a fizikai adatmodellek létrehozása során).

Az adatok rögzítése Több lehetõség áll rendelkezésre a stratégiatervezés során elõálló adatok tárolására: q célirányos szoftver alkalmazása, q kézi dokumentálás, q saját, célirányos szoftver elkészítése.

A kézi dokumentációt egyszerû tervezni, és elkészítése könnyen támogatható szövegszerkesztõk és táblázatkezelõ eszközökkel. Az elkészítendõ dokumentumok pontos tartalmának és formájának meghatározása a projekt elõkészítõ tevékenységei közé tartozik, egy lehetséges bontását az irányelveket ismertetõ dokumentumban találhatja meg az Olvasó. Egy másik követhetõ út az, amit ez a módszer ajánl, a gyûjtésre kerülõ információk és elemzésük alapján mindkét megközelítés elfogadható. Gyakran járható útnak bizonyulhat egy egyszerû szoftver tervezése és megvalósítása is, egy gyorsan és egyszerûen kezelhetõ fejlesztõeszköznek a segítégével, vagy egy könnyen testreszabható, "alakítható" CASE (Computer Aided Software Engineering) eszközzel.

Kereszthívatkozások Ha az alapadatok már rendelkezésre kereszthívatkozások elkészítése:

állnak,

akkor

lehetõvé válik

különbözõ

q mûködési területek és tevékenységek között, q tevékenységek és rendszerek között, q mûködési területek/szolgáltatási területek és szervezeti egységek között.

Elõírt termékek Az irányelvekben felsorolt jelentések közül a "Behatárolási tanulmány" teljes egészében elkészíthetõ. Ennek alapjául elsõsorban a stratégiatervezési projekt terve szolgál, ahol minden releváns információ fellelhetõ (sõt részletesebben is, mint ahogy azt az irányelvek kérik, hiszen itt a projektterv már a stratégiai tanulmány elkészítésére vonatkozik.) A projekttervben nem feltétlenül szerepel, de a projekt elõkészítése során áttekintésre került az informatikai stratégiatervezés kapcsolata más tervezési ciklusokkal. Ennek eredményét is rögzíteni kell a jelentésben. Hasonlóképpen, ha az volt a döntés, hogy több stratégiai tanulmányt kell készíteni, akkor ennek tényét, a döntés okait, a stratégiai tervek harmonizálásának módjait is ismertetni kell. A projekt elõkészítése során megszerzett, további idevágó információkkal kiegészíthetõ a jelentés. "A mûködési környezet leírása", "A mûködési környezet leírása", a "Célkitûzések és súlyponti kérdések" és a "Jelenlegi rendszerek" c. dokumentumok elkészítése elkezdõdhet az adatgyûjtés során megszerzett információk alapján.

3 A jelenlegi mûködési és informatikai stratégiák értékelése Bevezetés Ebben a fejezetben néhány, az informatika felhasználásához kapcsolódó olyan elképzelés kerül ismertetésre, melyek az informatika felhasználását a szervezeti célkitûzések megvalósításának, a hatékonyság növelésének egyik eszközeként tekintik. Az itt ismertetendõ elvek nem újak, tulajdonképpen az érintett területen dolgozó kutatók eredményeinek kiterjesztései. Egy ilyen kézikönyvben terjedelmi okokból csak felületes kitekintést adhatunk az alapokat képezõ elméletrõl. Ezért hangsúlyozottan ajánljuk, hogy a stratégiai tervezés megkezdése elõtt a munkában résztvevõ elemzõk behatóbban ismerjék meg az elveket, például a tárgykörbeli alapozó irodalom elolvasásával. A kézikönyv függelékében található meg az ajánlott irodalom felsorolása. A módszerben az alábbi két mûre támaszkodik elsõsorban: q Competitive Advantage, Michael E. Porter, Free Press q Fitting Information Systems Technology to the Corporate Needs: The Linking

Bevezetés

25

Strategy, Gregory L. Parsons, Harvard Business School Ezen a területen a legtöbb munka kifejezetten az üzleti szférára irányul. Ebben a kézikönyvben az elmélet oly módon kerül átvételre, hogy az a közigazgatásban, valamint a non-profit és közszolgálati szervezetekre is alkalmazható legyen. Javasoljuk azoknak a vezetõknek, akik interjúalanyok lesznek, hogy legalább a módszer alapelveivel ismerkedjenek meg. Nem várható el tõlük, ezt a kézikönyvet alaposan elolvassák, de azt hangsúlyozottan ajánljuk, hogy minden interjúalany vegyen részt egy 2-3 órás elõadáson, ahol ismertetésre és megbeszélésre kerülnek azok az elképzelések, melyek az informatika felhasználását a hatékonyság növelésének eszközeként kezelik.

Célok Ez a fejezet azoknak a feladatoknak a leírását tartalmazza, melyek a jelenlegi mûködési és informatikai stratégiák értékeléséhez kapcsolódnak. Jelen szakasz céljai: q az informatika jelenlegi, szervezeten belüli felhasználásának áttekintõ megismerése, q a

megszerzett ismeretek pontosítása elemzés illetve, ahol az lehetséges, kategorizálás felhasználásával a szervezet mûködési területein, illetve az ezeken a területeken folytatott tevékenységeken, valamint a tevékenységeket támogató rendszerek terén.

Az elemzések eredményeit a késõbbi szakaszokban használjuk a középtávú informatikai stratégiai terv kialakításakor. Ennek a szakasznak a feladatai közé tartozik: q A mûködési területek rangsorolása. q A tevékenységek elemzése. q A meglevõ rendszerek sajátosságainak elemzése. q Jelentések készítése. q Társszervezetek elemzése

MTA Információtechnológiai Alapítvány, 1993

MÛKÖDÉSI TERÜLETEK

Rangsorba helyezés

Mûködési stratégia azonosítása

Informatikai irányítási stratégia azonosítása

TEVÉKENYSÉGEK

Fõ- és mellékkategóriákba sorolás

Tevékenységlánc leírása

JELENLEGI RENDSZEREK

Rendszerkategóriába sorolás

Rendszerre ható erõk azonosítása

Támogatási kategóriák azonosítása

A stratégiatervezési munkacsoportnak elemeznie kell a szervezetet és az informatika jelenlegi felhasználását még azelõtt, hogy egy feladatterv kitûzése mellett döntenének. Ez a folyamat - köznapi hasonlattal élve - hasonlít egy orvos munkájához, aki alaposan megvizsgálja és diagnosztizálja a betegét, mielõtt kezelést írna elõ vagy nekiállna operálni. Általában három területét kell egy szervezetnek elemezni. Ezek: a mûködés maga, melyet egymástõl elkülönülõ mûködési területekre bontunk, a tevékenységek, melyeket a mûködés során végeznek, és végül a meglevõ rendszerek, amelyek a tevékenység elvégzését segítik és információkat szolgáltatnak.

A mûködési területek elemzése A mûködés elemzését megnehezíti az, hogy a szervezetek sokféleképpen és eltérõ módon mûködnek. A mûködési területek elemzésekor az üzleti (profit-orientált) szférabeli szervezetek esetében kézenfekvõ pénzügyi elemzéseket végezni, és a szervezet versenyképességet vizsgálni. Ugyanakkor közigazgatásbeli és non-profit szervezetek esetében az ilyen elemzések nem alkalmazhatók. Az alapadatgyûjtés során azonosított mûködési területeket három szempontból elemezzük. Ezek az alábbiak: q a mûködési területek fontossága, q a mûködés jellege (stratégiája) területenként, q az informatika irányításának milyensége (stratégiája) területenként.

Bármely mûködési terület fontosság szerinti kategorizálása elött át kell gondolni, hogy milyen jellegû kategorizálás lenne helyénvaló az adott esetben. A 'Boston-mátrix' technikán alapuló módszerek jól alkalmazhatók az üzleti szférában, ahol az elõnyõk és a felmerülõ költségek tisztán pénzügyi fogalmakkal mérhetõk. Ez a technika két szempont alapján sorolja be kategóriákba a rendszereket, nevezetesen a jelenlegi és a jövõbeli

Bevezetés

27

jövedelmezõségük szerint. A közigazgatásban ez technika egy-az-egyben nem használható. Ehelyett rendelkezésre áll egy olyan hasonló kategorizálási technika, mely a területeket rangsorolja az informatikai befektetések megtervezése számára a hatékonyság olyan mérõszámaira alapozva, melyek nem csak pénzügyi jellegûek.

Mûködési területek rangsorolása Miután meghatároztuk a mûködési területek azon körét, melyeket elemzésnek kívánunk alávetni, az elemzést annak megfontolásával kezdhetjük el, hogy melyek azok a területek, melyek várhatólag elõnyökhöz jutnának az informatika felhasználásával. Ezt az elemzést azzal segíthetjük, hogy elkezdjük tanulmányozni minden egyes terület hatékonyságát. Az üzleti környezetben egy ilyen típusú elemzés gyakran egyszerûbb, mert rendelkezésünkre áll két szokásos, pénzügyi adatokon alapuló formula annak eldöntése érdekében, hogy hol alkalmazzunk informatikát. Ez a két mutató: q a jelenlegi és jövõbeni bevétel egymással történõ szembeállítása, q a költségek és a várt haszon egymással történõ szembeállítása.

Szolgáltatói vagy közszolgálati környezetben ezek az egyszerû pénzügyi megfontolások közvetlenül nem értelmezhetõk. Ha például a rendõrség esetében vizsgáljuk az informatika alkalmazhatóságának a lehetõségeit, akkor a rangsorolást nem lehetne költség/haszon értékelésen alapulva elvégezni. Milyen pénzügyi haszna lenne például a gyilkosságok felderítésének? Ilyen esetekre másfajta megközelítés szükséges annak eldöntése érdekében, hogy hol alkalmazzunk informatikát. Nyilvánvalóan minden egyszerû mérési technika magában hordozza annak a veszélyét, hogy a technika túlzott általánosítása (nem megfelelõ körben történõ alkalmazása) helytelen eredményeket szül. Az itt bemutatandó megközelítés a hatékonyság egy egyszerû értékelési módját tartalmazza, amelyben a költség/haszon jellegû megfontolásokat figyelembe veszik, ha azok alkalmazhatóak. A mûködési területeket négy kategóriába rangsoroljuk, mint azt az alábbi ábra mutatja. 1 Kitüntetett 2 Várományos 3 Derékhad 4 Sereghajtó

A kitüntetett kategória azon mûködési területekre vonatkozik, amelyekrõl azt hisszük, hogy a legnagyobb elõnyök származhatnak az informatika felhasználásából. A sereghajtó kategóriába tartoznak azok a területek, ahol a legkisebb elõnyöket várjuk. Egy mûködési területnek a rangsorba történõ besorolása érdekében megkíséreljük a mûködési terület hatékonyságát mérni, méghozzá elõre megállapított értékekhez képest. Ehhez számos mutatót kell megvizsgálnunk. Elképzelhetõ, hogy rendelkezésre állnak MTA Információtechnológiai Alapítvány, 1993

már egyéb, korábban kidolgozott hatékonysági mutatók, amelyeket felhasználhatunk az elemzés során. a, Idõtartam A legtöbb esetben idõtartamhoz viszonyítunk, pl. éves, havi stb. Minden idõbeli értéket ugyanahhoz az idõtartamhoz viszonyítunk. b, Kiadás A mûködési terület adott idõtartamra vetített költségvetése vagy kiadásai. c, Bevétel/Megtérülés 1. Mérhetõ pénzügyi megtérülések az adott területen az idõtartam alatt (nem mindig alkalmazható) d, Bevétel/Megtérülés 2. Nem mérhetõ pénzügyi megtérülések az adott területen az idõtartam alatt. Ezeket vagy figyelembe vesszük, vagy nem vesszük figyelembe. Ha ezek lényegesek, úgy bizonyos elemeit figyelembe kellene venni. (Hasonlóképpen az elõzõ c, pontbeli merõszámhoz, ez az érték gyakran nem alkalmazható közszolgálati szektorban). e, Nettó ráfordítás A szolgáltatás "nyeresége", például b-(c+d). Ez lehet negatív is, amennyiben a mûködési területbeli szolgáltatás értékesítésébõl nyereséget várnak el. f, Szolgáltatási egység A hatékonyság mérése érdekében meg kell mondanunk, hogy milyen egységben mérünk. A rendõrségi példában, ha az Emberölési csoport szolgáltatásait vizsgáljuk, egy 'gyilkossági eset' lehet a szolgáltatási egység. Nem mindig egyszerû olyan szolgáltatási egységet találni, amely illeszkedik a teljes mûködési területhez. Elképzelhetõ, hogy többfajta egységet használunk, és ilyeténképpen a hatékonyságot többféle módon mérjük. Meg kell próbálnunk kiválasztani egyetlen 'fõ' típust. Amennyiben ez nem lehetséges, ez utalhat arra, hogy a kiszemelt mûködési terület túl nagy, és finomabb bontás lenne szükséges. g, Nagyságrend Az adott idõszakban fellépõ szolgáltatási egységek száma, pl. évente 500 gyilkosság. h, Eredményességi egység A szolgáltatási egységhez hasonlóan, az eredményességi egység a hatékonyság egyfajta mérési módját biztosítja. Az itt választott egységnek ugyanannak (vagy azon alapulónak) kell lennie, mint a szolgáltatási egység. Ha például a szolgáltatási egység a 'gyilkossági eset', akkor eredményességi egységként választhatnánk a 'felderített gyilkossági eset'-et. j, Eredményesség nagyságrendje Az adott idõszakban fellépõ eredményességi egységek száma, pl. évente 200 felderített gyilkosság. k, Hatékonyság Sikerességi nagyságrend/nagyságrend, százalékosan kifejezve: j*100/g. l, Minimális hatékonyság A vezetés által elfogadhatónak ítélt minimális hatékonyság (százalékban) m, Kitûzött hatékonyság A vezetés által megcélzott minimális hatékonyság (százalékban)

Bevezetés

29

n, Kitûzött költségszint Az elérendõ nettó ráfordítás nagysága Ebben szerepelhetnek a csökkentett kiadások (lásd b,), vagy megnövekedett elõnyök (lásd c, d,) vagy mind a kettõ. Ez az érték lehet magasabb, mint a jelenlegi nettó ráfordítás, ha a vezetés a jobb hatékonyság elérése érdekében hajlandó fizetni, vagy ahol ismeretes, hogy a költségek növekedni fognak, pl. a személyzet 10% fizetésemelést fog kapni. p, Társadalmi/politikai súlyozás A 0,1,2 értékek egyike. 0 érték adandó azon területek számára, amelyek legkevésbé fontosak szociális vagy elvi/politikai szempontból. A 2 értéket kapják a azok a területek, melyek kiemelkedõen fontosak politikai és/vagy társadalmi szempontból. Ebben a megközelítésben az elõzõ értékeket használjuk fel arra, hogy a területeket rangsoroljuk az informatikai beruházások szempontjából. Mint már említettük, négy kategóriát különböztetünk meg. 1 Kitüntetett

Hatékonyság < Minimum érték Hatékonyság < 50% Nettó ráfordítás > Kitûzött érték

Várományos

Hatékonyság < Kitûzött érték Hatékonyság < 70% Nettó ráfordítás < Kitûzött érték

Derékhad

Hatékonyság < 80%

2

3

4 Sereghajtó

Maradék

A százalékos számok csak illusztrációként szolgálnak, egy konkrét stratégiai tanulmány készítésekor az ott értelmezhetõ, specifikus számokat kell alkalmazni. A társadalmi/politikai súlyozás értékét a szolgáltatás kategóriájának a sorszámából vonjuk le, ilyen módon kerül elõbbre a rangsorban. Egy mûködési területet mindig a lehetõ legmagasabb kategóriába sorolunk azon kategóriák közül, melynek kritériumait a terület kielégíti. Visszatérve a rendõrségi példára, ha az 'Emberölés' és 'Betörés' mûködési területeket vizsgáljuk, a következõ adatokat is nyerhetnénk: Szolgálati ügy fajtája

EMBERÖLÉS

Idõszak

1 év

Kiadás

1 milló

BETÖRÉS 1 év 1 milló

Haszon/megtérülés 10 millió

Nettó költség

1 millió

Esetek

500

Sikeresség egység

Felderített betörési Felderített gyilkossági eset eset

MTA Információtechnológiai Alapítvány, 1993

500

1%

Hatékonyság

50%

Minimális hatékonyság

40%

Kitûzött hatékonyság

60%

Kitûzött nettó költség

1 millió

Társadalmi/politikai súlyozás

0

10% 20% 15 millió 2

A fenti példában az 'Emberölés' a Várományos kategóriába esik, mert hatékonysága kisebb a kitûzött hatékonyságnál (a példa elötti illusztráló ábrában szereplõ meghatározások alapján). A 'Betörés' a Kitüntetett kategóriába esik, mert hatékonysága jóval a minimum alá esik. A szociális/politikai tényezõ nem játszik szerepet az adott esetben, mert a 'Betörés' már eleve a legmagasabb kategóriába esik. Nyilvánvalóan ez az elemzés egyszerûsít, a területeknek egy elsõ nekifutásra adódó rangsorolását adja. Könnyen lehetséges azonban, hogy a következõ szakaszbeli interjúk során ez a rangsor változni fog.

Mûködési területek mûkõdési stratégiája A közigazgatásban a mûködési területeken a szolgáltatás színvonalát a szervezet célkitûzései határozzák meg. Ez utóbbiakat pedig a szervezetet létrehozó hatóság (pl. kormány) tûzi ki. A mûködési stratégia a szolgáltatás nyújtásának módját jellemzi. A jelenlegi mûködési stratégiák meghatározása során ötfajta stratégiát különíthetünk el.

Ellátó

Alapszolgáltató

Optimalizáló

Versenyeztetett

Végrehajtó

Alapszolgáltató Alapszolgáltató mûködési stratégia esetében a hangsúly egy elõre megszabott szinten történõ szolgáltatás biztosításán van. A szolgáltatás nyújtásakor törekednek a lehetõségek szerint a költségek csökkentésére. Gyakran a szolgáltatónak vajmi csekély befolyása van a szolgáltatás természetére vagy tartalmára, ehelyett jogszabály vagy a szolgáltatás felhasználója maga határozza meg a szolgáltatás természetét és az azzal szemben támasztott követelményeket. Az alapszolgáltató stratégiát követõ mûködési terület feladata ezeknek a követelményeknek történõ megfelelés költséghatékony módon. Alapszolgáltatóra példa: q parlamenti jegyzõkönyvvezetés, q népszámlálás, q állami vagy helyi beszerzési szervezetek,

Bevezetés

31

q épületkarbantartó és tisztító szolgáltatások.

Ellátó Ellátó stratégia esetében a szóbanforgó szervezet alapjában véve különleges szolgáltatást nyújt. A hangsúly azon van, hogy a szolgáltatás felhasználója a lehetõ legjobb minõségû szolgáltatásokat kapja, az alacsony költség nem tartozik a legfontosabb szempontok közé. Sok katonai szervezetben vannak olyan mûködési területek, melyek ellátóként mûködnek. A fegyverrendszerek fejlesztõinek például gyakran a legfontosabb az, hogy csúcsminõséget nyújtsanak a megrendelõknek. Az ellátók gyakran nagyon pontosan ismerik a kívülrõl származó követelményeket, de hasonlóképpen gyakran - nagy szabadsággal rendelkeznek a követelmények kielégítése terén. További példák ellátó stratégiát követõ szervezetekre: q orvosi szolgáltatások, q Informatikai szolgáltató szervezetek.

Végrehajtó Végrehajtó stratégia esetében jogszabályi elõírások vagy egyéb szabályok kikényszerítésén van a hangsúly. Az adóhatóságok gyakran végrehajtó stratégiát követnek, habár ezt az illetékes vezetõkkel feltehetõleg nehéz lenne elismertetni. A járandóságok beszedése és az elmaradások felfedése elsõrendû fontosságúak. Ezzel szemben annak ellenõrzése, hogy az igénybe vehetõ kedvezményekkel éltek-e, vagy hogy kivizsgálják az összes szóbajöhetõ túlfizetési esetet - ez nem tartozik a szervezet fõ feladatai közé ! Példák más szervezetekre, melyek végrehajtó stratégia szerint mûködhetnek: q rendõrségi munka egyes területei, q a kereskedelem és ipar irányításának bizonyos részei, q vám- és pénzügyõrségi tevékenységek.

Optimalizáló Az optimalizáló stratégia az ellátó és a végrehajtó jellegzetességeinek sajátos keverékével rendelkezik. Egy népjóléti/szociális feladatokat ellátó szervezet esetében például elképzelhetõ, hogy biztosítva akarják azt látni, hogy minden ellátott a neki járó teljes juttatást megkapja. Ugyanakkor a szervezet a csalókkal szemben szigorú politikát folytathat, pl. kezdeményezheti büntetõjogi felelõsségrevonásukat.

Versenyeztetett Versenyeztetett stratégiáról akkor beszélhetünk, ha a szervezet olyan területen mûködik, ahol másokkal versenyzik. A jegybank, vagy egy takarékpénztár például számos olyan mûködési területtel rendelkezhet, ahol a versenyeztetett stratégiát kell alkalmazni annak érdekében, hogy az állampolgárok számára szolgáltatásaik vonzóak legyenek. Nyilvánvalóan annak meghatározásakor, hogy egy mûködési területen milyen mûködési stratégiát követnek, az elemzõnek az adott terület rangidõs vezetõivel kell konzultálnia. Ne érje meglepetésként az Olvasót, hogy sok szervezetnél még soha senki sem vizsgálta meg az általuk folytatott mûködési stratégiákat ! Ez az egyszerû elemzés néha arra késztetheti a mûködési területek képviselõit, hogy elsõ alkalommal gondolkozzanak el az általuk adott szolgáltatások természetérõl.

MTA Információtechnológiai Alapítvány, 1993

Azért firtatjuk, hogy az egyes területeken milyen mûködési stratégiát követnek, mert a szolgáltatások (pontosabban az õket támogató rendszerek) jellege és a mûködési stratégiák úgynevezett ideális kombinációkba párosíthatók. Amikor majd a késõbbiek során a szolgáltatásokról adatokat gyûjtöttünk össze, akkor majd meg tudjuk határozni a szervezet jelenlegi helyzetét az ideális kombinációkhoz képest.

Informatikai irányítási stratégiák azonosítása A mûködési területek elemzésének egy harmadik módja a területen alkalmazott informatikai irányítási stratégia szerinti kategorizálás. Ennek során Gregory Parsons munkásságára támaszkodunk. Parsons hatféle megközelítési módot különböztetett meg az informatikai irányítási stratégia szempontjából. Az általa meghatározott irányítási stratégiák az alábbiak: q központilag tervezett, q élenjáró, q szabad piac, q monopólium, q erõforráshiányos, q szükséges rossz.

Parsons szerint az egyes informatikai irányítási stratégiák csak bizonyos környezetben használhatók, és egy szervezet minden mûködési területen az ott megfelelõ stratégiát kell alkalmazza. A jelenlegi mûködés hatékonyságának kiértékelése érdekében tehát meg kell határoznunk minden egyes mûködési területre az ott jelenleg használatos informatikai irányítási stratégiát. A Parsons-féle besorolása az informatikai irányítási stratégiáknak útmutatót nyújt számunkra az informatika szervezeten belüli alkalmazásának értékelésében. Minden egyes stratégia más és más megközelítését képviseli annak, hogy hogyan alkalmazzunk információtechnológiai erõforrásokat a szervezeti célok elérése érdekében. Vannak olyan szervezetek, melyek jól megalapozott stratégiákkal rendelkeznek minden mûködési területen. Mások hosszú évek után jutnak el egy stratégiához. Megintcsak mások sose választanak tudatosan egy stratégiát, hanem a szervezetbeli irányítási stílushoz és kultúrához illeszkedõ megközelítéssel élnek. Az utóbbi esetben az informatika hasznosulása tendenciájában kevésbé hatékonyabb, mint az ideális, és a kapcsolódó tevékenységek rendre nehézségekbe ütköznek. Az informatika hasznosulásából származó elõnyök maximális kihasználása érdekében Parsons az alábbi tevékenységek elvégzését ajánlja: q értsük meg a hat általános informatikai irányítási stratégiát, q határozzuk meg, hogy melyik stratégia áll a legközelebb a jelenlegi gyakorlathoz, q a mûködési területek osztályozása alapján határozzuk meg, hogy melyik stratégia

lenne a legmegfelelõbb az egyes mûködési területeken, q tudatosan tervezzük meg, hogy hogyan vezetjük be a területeken az annak megfelelõ

informatikai irányítási stratégiát ! Az informatikai irányítási stratégiákat az alábbiakban ismertetjük.

Központilag tervezett Ilyen esetben egy magas beosztású vezetõ/bizottság felelõs az informatika felhasználásáért a szervezeten belül. Ez a vezetõ vagy bizottság ugyanakkor jól ismeri a

Bevezetés

33

szervezeti stratégiát és az a feladata, hogy biztosítsa az informatika olyan felhasználását, mely elõsegíti a hatékony mûködést. Ezenkívül a vezetõ/bizottság tudatában van annak, hogy az informatika megfelelõ alkalmazása elõsegítheti a hatékonyság további növelését. Nyilvánvalóan olyan hatáskörrel kell rendelkeznie, amely garantálja, hogy az informatikai terveket valóban megvalósítják.

Élenjáró Ez a stratégia lényegében a legújabb technológiával történõ folytonos kísérletezésnek és tapasztalatszerzésnek felel meg. Ellentétben a központilag tervezett stratégia használatával, ahol a technológia egy bizonyos felhasználásra orientált, vagy bizonyos felhasználók igényeit elégíti ki, az élenjáró stratégia inkább K+F jellegû, nem pontosan meghatározott felhasználói körrel. A felsõ vezetésnek hinnie kell az új technológiákban, és hajlandónak kell lennie arra, hogy fejlesztésre költsön még akkor is, ha nem jósolható meg pontosan a fejlesztés kimenetele vagy a belõle származó termékek sorsa.

Szabad piac Szabad piaci stratégiáról akkor beszélünk, amikor az informatikával történõ ellátásnak a fõ hajtóereje maguktól a felhasználóktól származik. A felhasználónak kell meghatároznia, hogy mire van szüksége és szabadsággal kell rendelkeznie annak eldöntésében, hogy a követelményeket hogyan lehet a legjobban kielégíteni. A felhasználók többféle lehetõséggel rendelkeznek az informatikai igényeik kielégítése során: q használhatnak belsõ informatikai szolgáltatásokat, q beszerezhetnek kész szoftvert, q használhatnak külsõ erõforrásokat.

Ilyen stratégia alkalmazása esetében a vezetésnek biztosítania kell, hogy mûszaki/technikai útmutatás és segítség a felhasználók rendelkezésére álljon, de végsõ soron a felhasználók maguk vezérlik az informatika felhasználását.

Monopólium Ez a stratégia hasonló a szabad piaci stratégiához, azzal a különbséggel, hogy szervezeti szinten elõírják azt, hogy kizárólag belsõ erõforrásokat lehet a felhasználói igények kielégítése során felhasználni. A vezetésnek megfelelõ szolgáltatásokat kell biztosítania az igények ésszerû költséghatárokon belül történõ kielégítéséhez. A belsõ informatikai csoport (mint erõforrás) lehet egy központi szervezet, részlegenkénti vagy az információs központok köré szervezett. Sok szervezetben a felhasználók személyi számítógéppekkel (PC-kel) vannak ellátva, melyek olyan szokványos szoftverekkel vannak felszerelve, mint pl. fájlkezelõk, szövegszerkesztõk, táblázatkezelõk. A PC-k felhasználása ekkor a monopólium kategóriába esik, hiszen a felhasználókat minimálisan korlátozzák abban, hogy gépeiket milyen módon használják. Az adatfeldolgozó részleg ellenõrzi továbbra is viszont a nagyszámítógépes feldolgozást és a személyi számítógépek összekapcsolását hálózatba.

Erõforráshiányos Az ilyen stratégiát alkalmazó szervezetekben nem valószínû, hogy a felhasználói igényeket kielégítik. A pénzügyi kereteket gyakran még a felhasználói igények ismerete elött megállapítják. A vezetés ellenõrzi az erõforrások használatát, és többféle módon oszthatja el õket: MTA Információtechnológiai Alapítvány, 1993

q a kéréseket idõbeni beérkezésük sorrendje szerint elégítik ki, q a nagyobb befolyással rendelkezõ felhasználókat elégítik ki elõbb, q rangsorolják a projekteket megtérülésük alapján, q stb.

Ebben a környezetben erõforrásokért.

a

felhasználók

mindig

versenyeznek

az

informatikai

Szükséges rossz Általában a szervezeten belüli sikeres alkalmazások hiánya vezethet a 'szükséges rossz' megközelítéshez, melyet csak akkor szabad használni, amikor nincs nyilvánvaló alternatívája. Ilyen környezetben kizárólag a szembeötlõen költséghatékony, általában nagy mennyiségekkel dolgozó, ismétlõdõ jellegû tevékenységek (mint pl. számlázás vagy bérszámfejtés) számára teszik lehetõvé az informatikai erõforrások használatát. Némelykor az informatikát azért kell alkalmazni, mert ez adja az egyetlen praktikus megközelítési módot, pl. az olaj- és gázfelhasználás ellenõrzése, vagy az ÁFA visszatérítés lehetnek ilyenek. Fejlesztéseket csak akkor végeznek, ha az nyilvánvaló haszonnal járna, vagy amennyiben jogszabályi módosítás tenné azt szükségessé. A kategóriák áttekintése után megvizsgálhatjuk az egyes mûködési területeket és azt, hogy milyen módon használják fel az informatikai erõforrásokat. Ezen a módon határozhatjuk meg a jelenlegi informatikai irányítási stratégiát. Gyakran ez egyszerû tevékenység lesz, mert azok a szervezetek, melyek tudatosan nem választottak stratégiát, hajlamosak ugyanannak a véletlenszerûen választott stratégiának a használatára az összes mûködési területen.

Mûködési területek kategóriái - összefoglalás A mûködési területek elemzése során minden egyes területet az alábbi három szempontból kategóriákba soroltunk: q a mûködési területek fontossága szerint, q a mûködés jellege alapján, q az informatika irányításának milyensége szerint.

Alapszolgáltató Ellátó

Kitüntetett

Végrehajtó Optimalizáló

Várományos Derékhad

Versenyeztetett

Sereghajtó

Mûködési stratégiák

Mûködési területek rangsora

egy-sok

Egy stratégiát több terület alkalmazhat. Egy területen lehet, hogy egy fõ- és egy alstratégiát használnak jelenleg. Mûködési területek

Központilag tervezett Élenjáró Szabad piac Monopólium Erõforráshiányos Szükséges rossz

IT irányítási stratégiák

egy-sok

Bevezetés

35

A tevékenységek elemzése A mûködési területek elemzése után a tervezõ figyelmét az egyes mûködési területeken végzett tevékenységekre irányíthatja. A tevékenységek elemzésekor Michael Porter munkásságára támaszkodunk. Minden szervezet olyan tevékenységeket folytat, melyek a szervezet által biztosított szolgáltatásokkal függnek össze, vagy pedig segítik/támogatják az elõbbi tevékenységeket. A szervezetekben kilenc tevékenységtípus lelhetõ fel, melyek sokféle módon, az adott szervezettõl függõen kapcsolódnak egymáshoz. Egy szervezetnek a rá jellemzõ tevékenységeinek azonosításában gyakran segítséget jelent az alaptípusokból történõ kiindulás. MELLÉKTEVÉKENYSÉGEK

SZERVEZETI INFRASTRUKTÚRA

SZEMÉLYZETI ÉS MUNKAÜGY TECHNOLÓGIA, FEJLESZTÉS

BESZERZÉS

Beszállítás

ALAPFOLYAMAT

(Bemeneti logisztika)

Kiszállítás

Tájékoztatás

(Kimeneti logisztika)

(Hírnév, reputáció

Ügyfélszolgálat

kialakítása)

ELSÕDLEGES TEVÉKENYSÉGEK

A fenti ábra a kilencfajta tevékenység-alaptípust mutatja be. Gyakran a legjobb megközelítés induláskor az, ha indulásképpen a szervezeten belül a kilenc alaptípusba sorolható tevékenységeket azonosítjuk. Ezeket a típusokat két csoportra bonthatjuk, az egyikben azok az ún. elsõdleges tevékenységek találhatók, melyek a szervezet által nyújtott szolgáltatásnak az elõállítási láncában vannak, míg a másikba a szervezet melléktevékenységei kerülnek. Elsõdleges tevékenységek közé soroljuk az alábbiakat: q Beszállítás (bemeneti logisztika) q Szolgáltatás mûködtetése q Kiszállítás (kimeneti logisztika) q Tájékoztatás, hírnév és elismertség megalapozása q Utólagos szolgáltatások/ügyfélszolgálat

Melléktevékenységek q Szervezeti infrastruktúrális tevékenységek q Személyzeti és munkaügyi tevékenységek

MTA Információtechnológiai Alapítvány, 1993

q Technológia fejlesztési tevékenységek q Beszerzés

Tevékenységtípusok Az alábbiakban minden tevékenység típushoz felsorolunk néhány példát. Beszállítás: iratok és kérvények kézhezvétele, tárolása, elosztása, -raktározás, leltárrevizíó, (be)szállításütemezés.

anyagbeszállítás,

Alapfolyamat: kérvényelbírálás, panaszkivizsgálás, nyomtatványelõállítás, nyomozati eljárás, jelentésösszeállítás. Kiszállítás: terítés, nyomtatványok raktározása, igénylõhöz történõ eljuttatása, igények feldolgozása.

kiszállítás

tervezése,

útlevelek

Tájékoztatás: hirdetés, sajtószolgálat. Ügyfélszolgálat: szolgáltatás elvégzése utáni további szolgáltatások, mint például telefonos ügyfélszolgálat. Szervezeti infrastruktúra: tevékenységek.

vezetés,

tervezés,

pénzügyek,

könyvelés,

jogi

Személyzeti tevékenységek: toborzás, bérlés, kiképzés, személyre szóló továbbképzés, javadalmazás és díjazás és ellentételezés. Technológia fejlesztés: kutatás és fejlesztés, információs rendszerek fejlesztése, alapfolyamat fejlesztése. Beszerzés: anyagbeszerzés, pótalkatrész beszerzés, állóeszköz beszerzés. A tevékenységek képezik az építõelemeket a hatékonyság elérésében. Az a mód, ahogy az egyes tevékenységeket végrehajtják, és a tevékenység gazdaságossága (economics) fogja meghatározni a szervezet szolgáltatásainak költségét. Az egyes tevékenységek elvégzésének 'jósága' fogja (a szervezet által biztosított) szolgáltatások minõségét meghatározni. Kizárólag melléktevékenysegeket tartalmazó mûködési területeket gyakran nem célszerû elkülöníteni, hanem az ilyen jellegû tevékenységeket az egyes mûködési területek részeként lehet vizsgálni. Ez természetesen nem jelenti azt, hogy a melléktevékenységek nem fontosak a szervezet számára, csupán azt a törekvést jelzi, hogy a mûködési területeket a szervezet külvilágnak nyújtott szolgáltatásai alapján próbáljuk megkülönböztetni.

Tevékenységelemzés A mûködési területeken végzett tevékenységek azonosítása után azokat három szempontból is elemezhetjük. Általános szabályként azt mondható, hogy informatikai erõforrásokkal olyan tevékenységeket érdemes támogatni, melyek magas költséggel járnak, magas az értékük a szervezet számára és magas az információtartalmuk. Ezért tehát a tevékenységeket meg kell vizsgálnunk a költségek, a szervezet számára képviselt érték és az információtartalom szempontjai szerint. Elöször is meg kell határoznunk, hogy egy tevékenység alacsony, vagy magas költségekkel jár-e. Jól használható ökölszabály az, hogy amennyiben egy tevékenységre az elsõdleges tevékenységekbõl származó összköltségeknek több mint 10%-a jut, akkor az magas költségûnek tekintendõ. Egy másik megközelítés szerint rendezzük nagyság szerinti sorrendbe az összes tevékenységek költségeit ! Ezek közül azok, melyek a rangsor felsõ negyedébe esnek, azok magas költségûek. A következõ lépésben az információtartalmat kell szemügyre vennünk. Minden

Bevezetés

37

tevékenységnek lesz egy fizikai és egy információs összetevõje. Az anyagok és az információk bekerülnek egy tevékenységbe, átalakulnak valamilyen módon és vagy kikerülnek a tevékenységi láncból, vagy a lánc következõ eleméhez kerülnek. Ha egy tevékenységbe 'sok' információ érkezik, és 'sok' információ távozik, akkor magas az információtartalma.

ANYAGOK ANYAGOK TEVÉKENYSÉG TEVÉKENYSÉG INFORMÁCIÓ INFORMÁCIÓ Végül, értékelnünk kell minden egyes tevékenység értékét. Ez gyakran szubjektív értékelés. Egy lehetséges módja az értékelésnek az, melyet 'hozzáadott érték szerinti' megközelítésnek hívnak. Ez különösen ott alkalmazható jól, ahol a szolgáltatatás több, jól elkülöníthetõ lépésben jön létre.

TEVÉKENYSÉG NYERS BLOKK

FÚRÁS, VÉSÉS EGYENGETÉS

MEGMUNKÁLT BLOKK

A fenti példában a motorblokk értéke jelentõsen nõtt, ha a tevékenység elvégzése megtörtént. Óvakodjunk a 'hozzáadott érték' elvnek a kizárólagos használatától az elemzés elvégzésekor! A tájékoztatási tevékenységek például nagyon nagy értékkel bírhatnak a teljeskörû mûködés során, habár fizikailag semmilyen értékkel sem növelik a szolgáltatás értékét. Több kérdést lehet feltenni a magas értékû tevékenységek felismerése érdekében: q Ha az adott tevékenységet megszüntetnék, akkor ennek káros hatása lenne? q Ha az adott tevékenységet kétszer olyan jól végeznék, akkor ennek jól észlelhetõ,

pozitív hatása lenne ? q Ha az adott tevékenységet fele olyan jól végeznék, akkor ennek káros hatása lenne ?

A tevékenységek közötti kapcsolatok megállapítása. A tevékenységek közötti kapcsolatok leírására használhatjuk a tevékenységláncot (value chain), vagy például az adatfolyammodellezési (Data Flow Modelling, DFD) technikát. Utóbbi használata azzal az elõnnyel járhat, hogy természetesen kapcsolódhat a szervezetnél alkalmazott rendszerfejlesztési módhoz (mint például az SSADM, Structured System Analysis and Design Method), és több információt is megjeleníthet. A tevékenységek közötti kapcsolatok megállapítása gyakran még nehezebb, mint a kategorizálás. Mint azt már korábban megállapítottuk, a hatékonyság növelése érdekében felhasznált informatikai alkalmazások szempontjából elõnyben részesítjük azokat a tevékenységeket, melyek értéke, információtartaloma és költsége magas. Porter szerint elképzelhetõ, hogy más szempontokat is figyelembe kell venni. Sok tevékenység oly módon is kapcsolatban állhat, melyet egy egyszerû tevékenységi lánc nem juttat kifejezésre. Lehetséges, hogy ezek a kapcsolatok nem nyilvánvalóak. Egy önkormányzati szociális gondozási feladatokat ellátó mûködési terület esetében egy egyszerûsített tevékenységi lánc az alábbi módon nézhet ki: MTA Információtechnológiai Alapítvány, 1993

A RÁSZORULT GYERMEK FELKERESÉSE

GONDOZÓ SZÜLÕK KERESÉSE

A GYERMEK ADATLAPJÁNAK AKTUALIZÁLÁSA

A GYERMEK ELHELYEZÉSE

A GONDOZÁS ELLENÕRZÉSE

A fenti példában a 'gyermek elhelyezése' tevékenység hatással bír az adatlappal kapcsolatos tevékenységre, mely a lánc korábbi eleme. Senkit ne vezessen félre a bemutatott példa egyszerûsége! Az ilyen típusú tevékenységek közötti értékfüggõségek felismerése szubjektív folyamat, melynek során tapasztaltra, mély felhasználói tudásra van szükség. A kategorizálás során kíséreljük meg a függõségek felismerését és lejegyzését. A felteendõ kérdés így szól: "A tevékenységi láncon belül vannak-e olyan tevékenységek, melyek megkülönböztetett értékkel bírnak, mert javításuk kihat más, nem közvetlenül rákövetkezõ tevékenységekre?"

A jelenlegi rendszerek elemzése A mûködési területek és a tevékenységek elemzése után az õket támogató rendszerek kerülnek az érdeklõdés középpontjába. A stratégiai tervezés során a 'rendszer' szó utalhat információs rendszerre, mint például rendelésfeldolgozás vagy készletezés, vagy folyamatra, mely segíti a szervezetet funkcióinak az ellátásában, és az informatika az egyik meghatározó komponense. Ez utóbbira példa lehet egy irodaautomatizálási rendszer. A rendszereket három szempontból elemezzük: q a jelenbeni/jövõbeli hatékonyság szempontjából, q a rendszerre ható erõk (service forces) szempontjából, q a rendszerre ható erõk segítésének módjai szerint.

Jelenbeni/jövõbeli hatékonyság szerinti rendszerkategorizálás Az itt felhasznált technika a Boston-mátrix technikával azonos elveken alapul. A rendszerkategóriák mátrixában az egyik tengely a 'jelenlegi hatékonysághoz való hozzájárulás', a másik a 'jövõbeli hatékonysághoz való hozzájárulás' lesz.

Bevezetés

39

MAGAS

NAGYREMÉNYÛ

STRATÉGIAI

FENNTARTÓ

TERMELÕ

Hozzájárulás a jõvõbeli hatékonysághoz

ALACSONY

MAGAS

Hozzájárulás a jelenlegi hatékonysághoz

Rendre megvizsgálva a rendszereket, azokat a mátrix azon négyzetébe kell "elhelyezni", amelyik legjobban illik hozzájuk. A kategorizálást el kell végezni mind a jelenlegi, illetve a tervezett rendszerek esetében. A besorolási folyamatát az alábbi két kérdés megválaszolása vezeti: q A rendszer jelenleg hozzájárul-e alacsony vagy magas hatékonyság eléréséhez az

adott szolgáltatási területen ? q A rendszer a jövõben biztosíthat-e megnövelt hatékonyságot ?

Stratégiai A stratégiai rendszerek azok, melyek ténylegesen hatékonyságát, mind a jelenben, mind a jövõben.

befolyásolják

a

szervezet

Nagyreményû A nagyreményû rendszerek általában bizonytalan kimenetelûek, legyenek akár új fejlesztések vagy meglevõ rendszerek. Ezeket a rendszereket a vezetõk vagy a felhasználók hasznosnak, de nem kritikusnak ítélik meg a mûködés szempontjából. A döntéstámogató vagy a statisztikai rendszerek gyakran ebbe a kategóriába esnek. Az ilyenek rendszerek figyelmet érdemelnek, mert egy esetleges fejlesztéssel stratégiaivá válhatnak.

Termelõ A termelõ rendszerek általában az alapvetõ mûködést segítik, mint például a számlázás vagy a rendelések feldolgozása. Ebben az esetben a hangsúly olyan tevékenység támogatásán van, mely segíti a hatékonyságot.

Fenntartó A fenntartó rendszerek azok, melyek nem tûnnek sem a jelenben, sem jövõben a hatékonyságot közvetlenül elõsegítõnek, habár szükségesek lehetnek a szervezet mûködéséhez. A bérszámfejtõ rendszerek például gyakran ebbe a kategóriába esnek. Néhány példája az egyes kategóriákba esõ tipikus rendszereknek: Stratégiai: q Adóbeszedés adófizetõknél q Közvetlen hozzáférést biztosító szolgáltatások

MTA Információtechnológiai Alapítvány, 1993

q Automatizálás q Pénztárautomata (Point of Sale) q Telekommunikációs hálózat q Piacelemzõ rendszer q Ügynökségek/ ügyosztályok közötti adatmegosztás

Termelõ: q Pénzügyi ellenõrzés q Elõrejelzés/elemzés q Raktári rendszer q Megrendelések feldolgozása q Kinnlevõségeket kezelõ rendszer q Számlakezelõ rendszer

Nagyreményû: q Irodaautomatizálás q CAD/CAM q Döntéstámogatás q Statisztikai rendszer

Fenntartó: q Bérszámfejtés q Általános számvitel q Munkaerõ nyilvántartás q Állóeszköz nyilvántartás q Pénzügyi kimutatások

A fenti lista pusztán útmutatóként szolgál, de mindig szem elött kell tartani, hogy a rendszerek, vagy alkalmazások nem esnek eleve ugyanabba az egyik, vagy másik kategóriába. Ugyanannak a rendszernek a kategóriája változhat szervezetrõlszervezetre ! Például a vendéglátóiparnak a szállodai szegmensében a kifinomult on-line foglalási rendszerek leginkább a stratégiai kategóriába esnek. A másik oldalon viszont ugyanezek a rendszerek a repülõtársaságok esetében inkább kiszolgáló típusú rendszerként mínõsithetõk. Csupán néhány repülõtársaság látja a foglalási rendszerének a javítását kulcsfontosságúnak a versenyképesség növelése érdekében. A legtöbb szervezet azt gondolja, hogy a bérszámfejtõ rendszere általában a kiszolgáló kategóriába esik. Valószinûleg úgy okoskodnak, hogy ügyfeleik semmivel sem kapnak többet tõlük attól, hogy kitünõ a bérszámfejtõ rendszerük. Természetesen ez nem igaz olyan bankokra vagy szervezetekre, melyek az ilyen tevékenységeket szolgáltatásként nyújtják. Ilyen esetben a bérszámfejtés nagyreményûnek vagy talán stratégiainak is minõsíthetõ. Fontos arra emlékeztetnünk, hogy a fenntartó rendszerek területén történõ további informatikai befektetések lehetõségét nem zárjuk ki. Az ilyen kategóriában a kiadások azonban a költségcsökkentést fogják elõirányozni. Ha egy szervezet alapszolgáltató, azaz az alacsony költségeken van a hangsúly, akkor a kiszolgáló rendszerek által nyújtott költségcsökkentés létfontosságú lehet.

Bevezetés

41

A következõ ábra összefoglalja a rendszerkategóriakat, illetve a jelenlegi és a tervezett rendszerek jellegzetességeit, melyek az egyes kategóriákba esnek.

NAGYREMÉNYÛ

STRATÉGIAI

Meglévõ rendszerek

Meglévõ rendszrek

Értékesek, de a szervezet mûködése nem függ teljes mértékben tõlük

Kritikus a jelenlegi folyamatokra nézve

Jövõbeli rendszerek

Jövõbeli rendszerek

Valószínûleg kritikus a szervezet sikerességére nézve

Kritikus a szervezet sikerességére nézve

FENNTARTÓ

TERMELÕ

Meglévõ rendszerek

Meglévõ rendszerek

Alapszolgáltatásokat nyújtanak, de nem kritikusak a szervezet mûködésére nézve

Fontos a szervezet mûködõképességének fenntartása szempontjából

Jövõbeli rendszerek

Jövõbeli rendszerek

Alapszolgáltatásokat nyújtanak, de nem kritikusak a szervezet mûködésére nézve

Továbbfejlesztést nem tekintik kritikusnak

A késõbbiek során látni fogjuk, hogy létezik az informatikai irányítási stratégiáknak és a rendszerkategóriáknak egy ajánlott párosítása. A kétféle információ összegyûjtése után össze tudjuk majd vetni a szervezet jelenlegi helyzetét az elméleti ideális állapothoz képest.

Rendszerre ható erõk (service forces) Ideális esetben a rendszereket olyan módon tervezik meg, hogy segítsék a szervezet hatékonyságának növelését, valamint a szervezet céljainak elérését. Az elemzések egyike arra vonatkozik, hogy a rendszerek vajon ezt segítik-e, és ha igen, akkor milyen módon. A feladat itt az, hogy eldöntsük minden egyes rendszerre ható erõ vonatkozásában, vajon segít-e a szervezetnek a rendszer, vagy sem. A közigazgatásban ötféle rendszerre ható erõt különböztetünk meg, melyeket az alábbi ábrán szemléltetünk:

MTA Információtechnológiai Alapítvány, 1993

Beszállító

Ügyfél

Megbízó RENDSZER

Ügyintézõ

Társszervezet

Beszállító Egy rendszer vizsgálata esetén szeretnénk azt tudni, hogy a rendszer megváltoztatja-e a viszonyt a szervezet és a beszállítói között. Beszállítónak számít egy olyan alárendelt szervezet is, amely adatokkal látja el a vizsgálat alatt álló szervezetet. A beszállító típusú erõk azonosítása során felteendõ kérdések közé tartoznak az alábbiak: q Javítja-e a rendszer a szervezet pozícióját a beszállítókkal szemben? q Segít-e a rendszer a beszállítási költségek csökkentésében? q Vonzóbb ügyféllé tesz-e minket a rendszer a beszállítók számára? q A rendszer általa lehetséges-e más/olcsóbb/gyorsabb/jobb beszállítókat választani? q Nyilvánvalóvá

teszi-e vagy csökkenti-e a rendszer bizonyos beszállítandókra vonatkozó igény nagyságát?

q Növeli-e a rendszer a beszállított dolgok minõségét?

Ügyfél A szervezet hatékonyságának növelését gyakran az ügyfeleknek nyújtott szolgáltatások javításával lehet elérni. Az ügyfél szó itt azokat a (jogi vagy természetes) személyeket takarja, akik az egyes mûködési területeken nyújtott szolgáltatásokat igénybe veszik. Ezek lehetnek például adófizetõk, szociális juttatásokban részesülõk, avagy tárgyalásra váró személyek is. Az ügyfél típusú erõk azonosítása során felteendõ kérdések közé tartoznak az alábbiak: q Igaz-e, hogy a rendszer gyorsabb szolgáltatást nyújt az ügyfelek számára? q Lehetõvé teszi-e számunkra a rendszer az ügyfél, illetve a hozzákapcsolódó ügyletek

hatékonyabb nyomonkövetését? q Segít-e a rendszer abban, hogy az ügyfél az õt megilletõ teljeskörû szolgáltatást

megkapja? q Segít-e bennünket a rendszer abban, hogy kiderítsük, vajon az ügyféllel szemben

inkorrektül vagy helytelenül jártak el, vagy bármi egyéb gond merült fel az ügyféllel kapcsolatban? q Olyan információt nyújt-e a rendszer, mely az ügyfél és a szervezet kapcsolatát

Bevezetés

43

hatékonyabbá teszi? q Elõsegíti-e a rendszer az ügyfél költségeinek a csökkentését és/vagy javítja-e a

szervezet megítélését az ügyfél szemében?

Megbízó A 'megbízó' szó ebben a szövegkörnyezetben olyasmikre vagy valakikre vonatkozik, amik/akik ténylegesen finanszírozzák a mûködési területet. Ilyen lehet a kormány, egy minisztérium vagy akár az állam maga. A szervezet célkitûzéseitõl, küldetésétõl függõen lehetnek többé vagy kevésbé fontosak azok a rendszerre ható erõk, melyek segítik a megbízót. Egy végrehajtó környezetben, mint amilyen például az adók beszedése, a felügyeleti szerv tisztánlátásának a javítása fõ cél lehet. A megbízó típusú erõk azonosítása során felteendõ kérdések közé tartoznak az alábbiak: q A rendszer valóban 'értéket a pénzért' szolgáltatásokat nyújt-e? q A mûködési terület ellenõrzési, beszedési, kikényszerítõ és felülvizsgáló jellegû

mechanizmusait javítja-e a rendszer? q Segít-e a rendszer abban, hogy a Megbízó megkapja mindazon információkat és

statisztikákat, melyek szükségesek a szervezet megítéléséhez? q A rendszer kellõképpen hajlékony-e, hogy alkalmazkodni tudjon a Megbízó által

tervezett, a mûködési területre vonatkozó változtatások bekövetkezte esetében? q Összehasonlítható-e

a

rendszer

a

társszervezeteknél

mûködõ

hasonló

rendszerekkel?

Ügyintézõ Sok közigazgatási szervezetben a hatékonyságot lényegesen javítják az olyan rendszerek, melyek a szervezetbeli felhasználók (az ügyintézõk) munkavégzésének hatékonyságát jobbítják és készségeiket fejlesztik. Az ügyintézõ típusú erõk azonosítása során felteendõ kérdések közé tartoznak az alábbiak: q Segít-e a rendszer az ügyintézõk teljesítményének növelésében? q A felhasználók számára sikerélményt ad-e a szervezetbeli tevékenységük ellátása

során, illetve a felmerülõ problémák kezelésében a rendszer használata? q A felhasználók számára vajon a rendszer kellõ idõben szállítja-e a pontos

információkat? q Megszüntet-e a rendszer unalmas és ismétlõdõ jellegû munkákat? q A rendszer elõsegíti-e új munkaerõ toborzását és a régiek megtartását?

Társszervezet A társszervezet szó olyan csoportokat, minisztériumokat vagy hivatalokat jelent, melyekkel a szervezet együttmûködni, adatokat vagy esetleg szolgáltatásokat megosztani kíván. A társszervezet típusú erõk azonosítása során felteendõ kérdések közé tartoznak az alábbiak: q Olyan kapcsolatok épít fel a rendszer, ahol lehetõség nyílik a szervezetek közötti

adatcserére? q A rendszer architektúrája lehetõvé teszi-e a társszervezetek szolgáltatásainak, MTA Információtechnológiai Alapítvány, 1993

eljárásainak, hardver és szoftver eszközeinek használatát? q Vagyunk-e abban a helyzetben, hogy csökkentenénk a költségeket és/vagy

növelnénk a hatékonyságot azáltal, hogy résztveszünk valamilyen társszervezeti együttmûködésben? q Olyan szintû-e a de facto és egyéb szabványok helyi bevezetésének a szintje, hogy

személyzetet tudnánk átvenni a társszervezetektõl, ezáltal jelentõs megtakarítást elérve a kiképzési és betanítási költségek területén? q Olyan jól szervezett-e a szervezet, hogy szabványok bevezetése nem fog komoly

elvándorlást eredményezni a személyzet sorai között?

Támogatási kategóriák azonosítása A támogatási kategóriák azt írják le, hogy a rendszerek a rendszerre ható erõket hogyan támogatják. Az alábbi ábra nyolc támogatási kategóriát különböztet meg.

KÖLTSÉG

INFORMÁCIÓ

SZOLGÁLTATÁS

RENDSZER

GYORSASÁG

TECHNIKAI

SPECIALITÁS

JOGOK VÉDELME

VÁLTOZTATÁS

Annak megállapításán túl, hogy milyen erõket támogat egy rendszer, azt is meg kellene állapítanunk, hogy mennyire támogatja azokat. A támogatási kategóriák számos további alkategóriába oszthatók, melyeket az alábbiakban ismertetünk.

Költség KCS: költségcsökkentés a szervezetnek KCK: költségcsökkentés minisztériumoknak stb.

külsõ

félnek,

például

beszállítóknak,

ügyfeleknek,

TAN: takarékosság nagyban (economies of large scale), azaz már végrehajtott beruházásokból származó eredményeket (nyereség, hatékonyság növelése, stb.) az eredeti befektetés töredékéért tovább lehet fokozni az ide irányított további beruházásokkal, pl. informatikai fejlesztések, stb. TAK: takarékosság kicsiben (economies of small scale), például lehetõvé teszi kisvolumenû rendeléseket

a

OPT: optimalizálás, például szállítás mennyiségét, ügyek számát, emberi erõforrással kapcsolatos igényeket.

Bevezetés

45

Információ JIS: jobb információ a szervezetnek. JIK: jobb információ külsõ félnek, például a szervezet kihelyez terminálokat más szervezetekbe.

Specialitás SSS: speciális szolgáltatás, tulajdonság (feature) a szervezetnek. SSK: speciális szolgáltatás, tulajdonság (feature) külsõ félnek. NSM: nem szokványos megoldás vagy szolgáltatás, például telefonos 'hot-line', ÁFA visszatérítések gyors intézése bizonyos esetekben, különleges engedélyek kiadása stb.

Technikai MJR: mûszaki jellegû rugalmasság. KÖK: kommunikációs és összeköttetési szolgáltatások. AHF: adatok hozzáférhetõsége.

Szolgáltatás JSS: jobb szolgáltatás a szervezetnek. JSK: jobb szolgáltatás külsõ félnek, például gyorsabb kézhez juttatása kérelmeknek vagy iratoknak.

Védelem SJV: a szervezet jogainak védelme. KJV: külsõ fél jogainak a védelme, például általános vagy alkotmányos szabadságjogok érvényesítése, jogszabályoknak történõ megfelelés stb.

Gyorsaság GMS: gyors megoldás (szolgáltatás) a szervezetnek, például gépjármû-adatok rendõrség számára történõ visszakeresése, helyfoglalási rendszernek küldött válasz stb. GMK: gyors megoldás (szolgáltatás) külsõ félnek, például a Parlamentben feltett kérdésekre adott válaszok, belépõjegyek nyomtatása stb.

Változtatás GRV: gyors reagálás a világban, a környezetben bekövetkezõ változtatásokra, például új adótörvények, új termékek kezelése, biztosítási politikára, politikai változások (mint választások) stb.

Rendszerkategóriák összefoglalása Az alábbi ábra összegzi a rendszerek terén végzett kategorizálásokat.

MTA Információtechnológiai Alapítvány, 1993

RENDSZERKATEGÓRIÁK

RENDSZER

Termelõ Fenntartó Szépreményû Stratégiai

Beszállító Ügyfél Megbízó Ügyintézõ Társszervezet

RENDSZERRE HATÓ ERÕK

Szolgáltatás Költség Információ Specialitás Technikai Védelem Változtatás Gyorsaság TÁMOGATÁSI KATEGÓRIÁK

RENDSZERRE HATÓ ERÕK TÁMOGATÁSA

Az elemzések eredményeinek áttekintése Elemzési jelentések Ebben a fejezetben a mûködési területek, tevékenységek és rendszerek különbözõ szempontból vett kategorizálását tekintettük át. Ennek befejeztével olyan jelentéseket tudunk készíteni, melyek tükrözik az eddig tett megállapítasokat. A jelentéseket aztán össze lehet hasonlítani bizonyos 'ideális' kombinációkkal, melyeket szakértõi vélemények alapján gyûjtöttek össze.

Alapjelentések Szükségünk lesz néhány alapvetõ fontosságú dokumentumra, melyek egyszerûen azt tartalmazzák, amit eddig összegyûjtöttünk. Ezeket fogjuk a késöbbiek során kiindulópontként használni, amikor is tartalmukat módosíthatjuk, az abban foglaltakat felülbírálhatjuk. Az alapjelentések közé tartozik: q A mûködési területek listája, rangsor szerint. q Minden egyes mûködési területre a kapcsolódó tevékenységek és rendszerek listája. q Az általános jellegû tevékenységek tevékenységtípus szerint összegyüjtve. q A rendszerek listája, rendszerkategória szerint. q Minden egyes rendszerre egy olyan jelentés, mely tartalmazza a kapcsolódó

tevékenységeket és mûködési területeket.

Elemzõ jelentések A jelenlegi rendszerek és a tevékenységek viszonya A ilyen típusú jelentés felsorolja minden egyes mûködési területre az ottani tevékenységeket és azt, hogy ezek milyen módon kerülnek támogatásra rendszerek által. A tevékenységeket kategorizálni kell q információtartalom,

Bevezetés

47

q érték, q költség

szerint. A cél annak bemutatása, hogy a jelenlegi rendszerek milyen módon támogatják az egyes mûködési területeket. Azt várnánk el, hogy a rendszerek támogatnak minden 'magas' kategóriába esõ tevékenységet. Ez jelentés lényegében kimutatja, hogy a tevékenységek közül melyek nincsenek kellõképpen támogatva, mely tevékenységek esetében nagyobb a szükségesnél a támogatás, illetve mely tevékenységek esetében megfelelõ szintû a támogatás.

Környezeti összefüggés Szakértõk véleménye szerint ideális esetben a mûködési stratégia, a rendszerre ható erõk és a támogatási kategóriák között közvetlen összefüggés van. Ezek az ún. ideális kombinációk, melyeket az alábbi táblázat tartalmaz. TÁRSSZERVEZET

BESZÁL -LÍTÓ

ÜGYFÉL

MEGBÍZÓ

ÜGYINTÉZÕ

ALAPSZOLGÁLTATÓ

KCK JSS TAN OPT KCK

JSK

JIS GRV JSS

JIS SSS JSS

ELLÁTÓ

OPT

JIS SSK NSM JSK GMS GRV SJV

JIK GRV

JIS SSS JSK

VÉGREHAJTÓ

OPT

JIK GRV SJV

GMK GRV SJV

MJR KÖK JIS SSS AHF JSK NSM

OPTIMALIZÁLÓ

OPT

JIK SSK NSM JSK GMK GRV KJV SJV

JIK GMK GRV SJV

MJR KÖK JIS SSS AHF JSS NSM

VERSENYEZTETETT

KCS TAN TAK OPT

KCK JIK SSK NSM JSK SJV GMK GRV

KCK JIK SSK JSS SJV GMS GRV

JIK SSS JSS GMS

KÖK AHF

MJR

A jelenlegi rendszerek szerepe a rendszerre ható erõk támogatásában Ez a jelentés tartalmazza minden egyes mûködési területre az azt támogató rendszereket, az egyes rendszerre ható erõket és a támogatási kategóriákat. Ezt össze MTA Információtechnológiai Alapítvány, 1993

lehet vetni az ideális kombinációk táblázatával.

A jelenlegi informatikai irányítási stratégiák viszonya Ez a jelentés a mûködési területek informatikai irányítási stratégiáját veti össze egy ajánlható ideális modellel. Ez az összehasonlítás a területeket támogató rendszerek kategóriái alapján készül. Az ajánlásokat az alábbi táblázat mutatja:

NAGYREMÉNYÛ

Rendszerkategória

Informatikai irányítási stratégia

ÉLENJÁRÓ SZABAD PIAC

KÖZPONTILAG TERVEZETT

ERÕFORRÁSHIÁNY

SZABAD PIAC SZÜKSÉGES ROSSZ

FENNTARTÓ

STRATÉGIAI KÖZPONTILAG TERVEZETT

ÉLENJÁRÓ

MONOPÓLIUM

ERÕFORRÁSHIÁNY

TERMELÕ

A nagybetûvel írt informatikai irányítási stratégiák az elsõdleges ajánlások. A kisbetûvel írtak lehetséges alternatívák. Az egyes informatikai irányítási stratégiáknak a rendszer kategóriák alapján történõ ajánlásának indoklását az alábbiakban ismertetjük.

Központilag tervezett Legjobban illeszkedõ stratégiák: Elõfeltételek:

Indoklás:

Felhasználók/veze tõk szerepe:

STRATÉGIAI, nagyreményû.

Központi felelõs vezetõ vagy szervezet, mely felhatalmazással rendelkezik az informatikai stratégia tervezésére, és biztosítani tudja az informatikai stratégia és a szervezeti célok összhangját. Olyan jogkörrel kell rendelkezzen, hogy végre tudja hajtatni a terveket. Felkészült és elkötelezett felsõvezetésre van szükség. Egy központi irányító szervezet át tudja tekinteni a feladatokat és kiválóan alkalmas a szervezeti tervek informatikai stratégiává történõ lefordítására. Ismerjék az informatika használatát. Legyenek készek arra, hogy rendszerötletekre hívják fel a központi funkció figyelmét.

Bevezetés

Élenjáró Legjobban illeszkedõ stratégiák: Elõfeltételek:

NAGYREMÉNYÛ, stratégiai (költséges lehet!)

A felsõvezetés legyen hajlandó arra, hogy a szükséges erõforrásokat rendelkezésre bocsássa. Innovatív és felkészült vezetés szükséges, amely kész az informatika agresszív használatára szervezeti célok elérése érdekében.

Indoklás: Felhasználók/veze tõk szerepe:

Szabad piac Legjobban illeszkedõ stratégiák: Elõfeltételek:

Elmélyült, naprakész tudás álljon rendelkezésre. A felhasználókkal közeli legyen a kapcsolattartás . Hit abban, hogy az informatika komoly lehetõségeket ad a hatékonyság javítása szempontjából. Legyenek készek arra, hogy az új rendszerek elkészülte esetén azokat valóban használni fogják.

NAGYREMÉNYÛ (ha a felhasználók kellõképp felkészültek), fenntartó (egyébként) Felkészült felhasználók (ha a nagyreményû kategóriáról van szó) Az informatikára vonatkozó pénzügyi tervezés a szükségleteken és nem elõre meghatározott korlátokon alapul.

Indoklás: Felhasználók/veze tõk szerepe:

Monopólium Legjobban illeszkedõ stratégiák:

A felhasználók maguk választják ki a 'legjobb fogást'. A belsõ informatikai szolgáltatók hajlandóak a szállítókkal versenyezni, és olyan szolgáltatásokat nyújtanak, melyek 'értéket adnak a pénzért'. A legjobb döntések és értékálló informatika a szabad piaci erõk harcából származik. Ismerjék az informatika alkalmazásában rejlõ lehetõségeket, és fogjanak hozzá a megfelelõ források felkutatásához, ahonnan az informatikai erõforrások beszerezhetõk.

TERMELÕ

MTA Információtechnológiai Alapítvány, 1993

49

Elõfeltételek:

A felhasználók fel vannak készülve a belsõ informatikai monopólium elfogadására. Az erõs vezetés képes legyen az egyetlen forrásból történõ igénykielégítés politikájának elfogadtatására.

Hajlandóság a belsõ informatikai erõforrásokkal és személyzettel történõ együttmûködésre. Szükséges a pontos elõrejelzésnek valamilyen formája az erõforrások eltékozlásának elkerülése végett, máskülönben erõforráshiányos stratégiába csaphat át. Összehangolt megközelítést könnyebben tesz Indoklás: lehetõvé, mint a szabad piaci megközelítés. A belsõ funkciónak tudnia kell az igényekrõl. A Felhasználók/veze követelményeket meg kell tervezni, hogy tõk szerepe: biztosítsák az erõforrások rendelkezésre állását.

Erõforráshiány Legjobban illeszkedõ stratégiák: Elõfeltételek:

FENNTARTÓ, termelõ (fennáll az alacsony színvonalú erõforrásellátottság veszélye) Erõs informatikai költségtervezés és ellenõrzés léte. Döntõ bizottság és pontos keretek közé szorított felhasználói hozzájárulás léte. Hatékony projektellenõrzési és nyomonkövetési rendszerek rendelkezésre állása.

Indoklás:

Csak igazán értékálló informatikai rendszereket szerezzünk be. Az informatika csak korlátozott mértékben áll rendelkezésre. Készüljenek fel arra, hogy a lehetséges projekteket Felhasználók/veze költségek szempontjából meg tudják indokolni. tõk szerepe:

Szükséges rossz Legjobban illeszkedõ stratégiák: Elõfeltételek:

Indoklás:

FENNTARTÓ (csak alacsony szintû)

Szoros ellenõrzése az informatika felhasználásának. A vezetés legyen hajlandó az alapvetõ rendszerigények kielégítésére. Az informatikai rendszerek nem stratégiai jellegûek és lényegében adatfeldolgozás és/vagy numerikus adatfeldolgozás kategóriába sorolódnak.

Felhasználók/veze Nincs tudatos informatikai szerepvállalás. tõk szerepe: Az informatikát csak ismétlõdõ tevékenységek esetében használják.

Bevezetés

51

Társszervezet elemzése A közigazgatásban a társszervezetek elemzése hasznosnak bizonyulhat az informatikai stratégia kialakítása során. Az alábbiakban ehhez adunk némi útmutatást. A társszervezet elemzésének célja a hasonlóságok felismerése, a helyes gyakorlat követése. Általában társszervezetekrõl adatokat csak mûködési terület szinten gyûjtsünk. A társzervezetnél folytatott tevékenységekrõl csak ritkán áll rendelkezésre részletes információ, de a fõ tevékenységeinek a kategóriáit gyakran meg lehet határozni a társszervezet (szervezeti) stratégiájából vagy külvilággal szemben tanúsított magatartásából. Gyakran lehetséges az is, hogy a társszervezeteket meglátogassuk, és ilyen módon nyerjünk információt. A jelenlegi helyzet értékelése a következõ ábrán foglalható össze. TEVÉKENYSÉGKAPCSOLATOK

10-20 FONTOSABB

10-20 FONTOSABB

MÛKÖDÉSI TERÜLET

MÛKÖDÉSI TERÜLETEK TEVÉKENYSÉGEK

RENDSZEREK

TEVÉKENYSÉGEK

RENDSZER

TEVÉKENYSÉG

KERESZTHÍVATKOZÁS

ISMERT

TÁMOGATÁSI KATEGÓRIÁK RENDSZERRE HATÓ ERÕK TÁMOGATÁSI KERESZTHÍVATKOZÁS

RENDSZERRE HATÓ ERÕK TÁMOGATÁSA

Elõírt termékek Az irányelvekben felsorolt jelentések közül a "Mûködési modellek" c. dokumentum az adatokat leíró részei kivételével elkészíthetõ. A szervezet funkcióinak leírásakor a mûködési területekre vonatkozó elemzési adatokat használhatjuk fel, a folyamatok és az információáramok leírásához a tevékenységek, illetve kapcsolataik szolgáltatnak alapot, a szervezet mûködésének különfélei jegyeit pedig kereszthivatkozásokkal mutathatjuk be. Bemutatható ezenkívül az adatgyûjtés során már felmért szervezeti hierarchiaábra is, a kulcsemberek megnevezésével. A mûködéshez szükséges kulcsadatokat majd a stratégiai adattervezés jelentései írják le. Ne feledkezzünk meg a leíró, narratív információkról sem a jelentés elkészítése során ! "A jelenlegi rendszerek" c. jelentésnek a meglevõ rendszereket ismertetõ része teljes egészében elkészíthetõ, a tervbe vett rendszerekrõl a késõbbiek során kell majd nyilatkozni. A rendszerek értékét kategóriájuk érzékelteti, szolgáltatásaik terjedelmét és helyét a támogatási kategóriák, illetve a támogatott erõk. Az üzemeltetés és irányítás módját mûködési területenként az informatikai irányítási stratégia jellemzi, az ott gyûjtött adatok alapján további részletek is leírhatók, ha ez szükséges. A jelentés ne csak a kategorizálások puszta tényét tartalmazza, hanem az ahhoz vezetõ út, az indokok (szöveges) leírását is. "A mûködési környezet leírása" jelentésben az ügyfelek és a szervezetre ható erõk vizsgálatához felhasználhatók a rendszerre ható erõk és a támogatási kategóriák elemzése során a beszállítókra és ügyfelekre vonatkoztatott adatok. Hasznosítani lehet itt a társszervezet elemzés idevágó eredményeit is. A jelentés elkészítéséhez lehet, hogy további felméréseket kell végeznünk arról, hogy hogyan viszonyul a szervezet más, a projekthatárokon túl esõ szervezeti-mûködési egységekhez, további kormányszervezetekhez.

MTA Információtechnológiai Alapítvány, 1993

4 Az informatika jövõbeni stratégiai felhasználásának meghatározása Bevezetés Az elõzõ lépésben a szervezet mûködését és informatikai környezetét tanulmányoztuk. Ebben a lépésben azoknak az információtechnológiával kapcsolatos projekteket állítjuk össze, amelyeket a szervezetnek meg kell valósítania a stratégiatervezés elõkészítõ szakaszában meghatározott idõtávon belül. Ennek a listának az összeállítása két úton történik: q az elõzõ elemzés eredményeinek vizsgálatával és az ebbõl adódó feladatkitûzéssel; q az érintett vezetõk megkérdezésével, igényeik feljegyzésével és vizsgálatával.

A lépés során öt dolgot igyekszünk elérni: q meg szeretnénk szerezni a vezetéstõl a Munkacsoport által megállapított mûködési

Bevezetés

53

stratégiák megerõsítését; q vagy meghatározzuk a kritikus sikertényezõket, vagy azt vesszük fontolóra, hogy

milyen módon történjen a meghatározásuk; q el akarjuk dönteni, hogy milyen területeken legyenek informatikai fejlesztések; q feladatokat fogunk kitûzni annak biztosítása érdekében, hogy a jelenlegi - és

amennyire lehet a jövõbeni - rendszerek a legalkalmasabban ellensúlyozzák a külsõ, szervezetre ható erõket; q végül

a vezetés bevonásával biztosítani kivánjuk, hogy a szóbajövõ rendszertípusoknál mindig a megfelelõ informatikai irányítási stratégia kerüljön alkalmazásra.

A stratégiatervezés ezen részével kapcsolatban öt - újabb alfeladatokra bomló - feladat van. q A középvezetés bevonásával meg kell erõsíttetni az elõzõ szakaszban megállapított

mûködési stratégiákat. q A választott megközelítéstõl függõen el kell végezni a szervezet kritikus sikertényezõi-

nek meghatározását. q A szervezeti terv vizsgálatával és egy ún. SCOPE-elemzés lefolytatásával elõ kell

készíteni a kulcscélok ill. -feladatok kialakítását. q Átfogó interjúkészítési program segítségével ki kell alakítani a kulcscélokat ill. -felada-

tokat az informatika és módszerei felhasználására. q Közös feladatkitûzõ ülések (joint action session) segítségével meg kell határozni az

informatikai irányítási stratégiát (minden egyes mûködési területre).

A mûködési stratégia megerõsítése Az elemzõnek meg kell erõsíttetni a középvezetéssel, hogy az egyes mûködési területeken a már meghatározott mûködési stratégiák helyesek-e, illetve egyetértésre kell jutni a jövõbeni fõbb mûködési stratégiákat illetõen. MÛKÖDÉSI MÓD

A jövõben lehetõleg csak egy mûködési mód legyen területenként

Lehet, hogy jelenleg több mûködési mód is tartozik egy területhez

MÛKÖDÉSI TERÜLET

Amikor a jövõbeni mûködési stratégiák megerõsítést nyertek, az informatika jövõbeni felhasználását leíró dokumentumot felül kell vizsgálni, és ha szükséges, módosítani kell.

A kritikus sikertényezõk megállapítása A kritikus sikertényezõk jelentõsége A kritikus sikertényezõket (KST-ket) lehet egy meglévõ szervezeti-mûködési tervbõl származtatni, de az is lehet, hogy az informatikai stratégiatervezés elõtt meg kell hatáMTA Információtechnológiai Alapítvány, 1993

rozni õket, vagy esetleg módosítani kell õket a projekt során. A kritikus sikertényezõk alapvetõen a szervezet törekvéseit fogalmazzák meg, összegyûjtésük és jóváhagyásuk valójában az informatikai stratégiatervezés körén kívülre esik. Mivel azonban az informatikai stratégiai tervnek követnie kell a szervezet mûködési vagy rendeltetési céljait, ezért fontos, hogy a szervezet KST-i már korábban megállapításra kerüljenek. Számos megközelítés létezik a KST-k megállapítására, legtöbbjüket szakkönyvekben részletesen leírták. Nem ennek a kézikönyvnek a feladata, hogy ezt a témát itt részleteiben kifejtse, de némi magyarázatra mindenképp szükség van. A KST-k azok a dolgok, amelyek alapvetõen befolyásolják a szervezet "mûködését".

Példák A tényezõk szervezetrõl szervezetre változnak. Az alábbi kijelentések KST-nek tekinthetõk, a megfelelõ szervezetben. q A költségvetésnek el kell készülnie a kitûzött határidõre. q A lakosság véleménye jó legyen a közbiztonság jelenlegi állapotáról. q A makrogazdasági paraméterek olyan módon kerüljenek meghatározásra, hogy

elõsegítsék az ország gazdasági fellendülését. q A migrációs és menekültügyi politika szerezzen nemzetközi elismertséget. q Az adóbevételek alakulását az év során jó közelítéssel lehessen elõre jelezni, és

pontosan követhetõ legyen a tényleges adatok. q A környezetvédelmi adatok rendszere harmonizáljon az EK megfelelõ elõirásaival. q A munkanélküliség megfelelõ módon legyen kezelve. q A nemzeti valuta védelme, a kamatlábak megfelelõ szintre állítása biztosított legyen.

Megfigyelték, hogy sok szervezetben hiányzik ill. alig-alig van meg annak ismerete, hogy milyen KST-ken alapul a siker (tulajdonképpen az eredményesség) jelenlegi megítélése. Elõfordulhat az is, hogy nem jó a vezetés elképzelése a szervezet KST-irõl. A profitorientált szférában például számos esetben elõfordult, hogy a vezetés azt hitte, hogy a piacuk nagyon érzékeny az árra. Az alacsony árak fenntartását tekintették kulcstényezõnek (azaz kritikus sikertényezõnek). Az elvégzett piackutatás azonban feltárta, hogy a piac sokkal érzékenyebb volt más tényezõkre, mint pl. a minõség, szállítási idõ vagy a termék tulajdonságai.

A KST-k és a stratégiafejlesztés kapcsolata A "jelenlegi" KST-k megállapítása nem feltétlenül egyszerû feladat. Ugyanakkor a KST-k alkalmas körének meghatározása egyértelmûen alapvetõ jelentõségû. Ha egy informatikai stratégia fejlesztése elindul és a KST-k elõzõleg nem kerültek meghatározásra, akkor az elsõ alkalommal történõ megállapításuk idõigényes tevékenységnek bizonyulhat. Mint ahogy az már a Tervezés, behatárolás és adatgyûjtés szakaszában is említésre került, a vezetésnek több megközelítés közül választhat a KSTk meghatározásakor: q készítsenek egy külön KST-tanulmányt a stratégiafejlesztési munkák elkezdése elött, q

a stratégiafejlesztés során fogalmazzák meg a KST-ket,

q az informatikai stratégiafejlesztés céljai szempontjából hagyják figyelmen kívül a KST-

ket és a szervezeti igényeket csak az interjúk elsõ körének lefolytatása során, a célok meghatározásával tárják fel.

Bevezetés

55

A vezetésnek óvatosnak kell lenni a harmadik megközelítés választásánál, ugyanis csak akkor biztonságos ezen az úton járni, ha meg vannak arról gyõzõdve, hogy mélyrehatóan ismerik a szervezet mûködését, beleértve ebbe beszállítóikat, alkalmazottaikat, termékeiket és szolgáltatásaikat és a szolgáltatások igénybevevõit. Ha az elsõ két megközelítés között választanak, a vezetõknek ismét csak figyelembe kell venni, hogy mit tudnak a szervezetük mûködésérõl. Ha úgy gondolják, hogy a KST-k megállapítása lényegében a szervezeten belül elvégezhetõ a vezetõkkel folytatandó interjúk és megbeszélések segítségével, akkor ésszerû ezt a munkát a stratégiafejlesztés során elvégezni. Ha azonban úgy érzik, hogy a KST-k megállapítása érdekében a szervezeten kívülre is kell menni - például az ügyfelekhez ill. beszállítókhoz, vagy a társszervezeteknél kiterjedt vizsgálatokra, netalán a felsõbb szintû politikai elemzésére van szükség -, akkor a külön KST-tanulmány elkészítésének lehetõsége megfontolandó. Ha az a döntés született, hogy a KST-ket figyelmen kívül hagyják, akkor ezek természetesen - semmilyen szerepet nem fognak játszani a fejlesztés során. Ha azonban a fejlesztés részét képezik, akkor tehát a Munkacsoport vagy a KST-k egy már létezõ listájából indulhat ki, vagy olyan megbízást is kaphat, hogy a szervezet életében elsõ alkalommal állapítsák meg azokat. Amennyiben a KST-ket már korábban meghatározták, akkor interjúkon keresztül azt kell megállapítani, hogy melyik KST melyik mûködési területhez kapcsolódik és miért. A fejlesztés késõbb fázisában, amikor a célok kerülnek meghatározásra, az elemzõk megpróbálják majd a célokat KST-khez kapcsolni.

A KST-k meghatározása Amennyiben a kritikus sikertényezõk meghatározása a stratégiatervezési projekt részét képezi, akkor ez egy interjúprogram, mint megvalósító mechanizmus segítségével valósul meg. Három lépésbõl áll a KST-k meghatározása: q az interjúk lefolytatása, q az eredmények vizsgálata valamint az egyes mûködési területekre vonatkozó KST-k

meghatározása és feljegyzése, q az eredmények vizsgálata vezetõk bevonásával megtartott hivatalos üléseken, azok

esetleges módosítása és a végsõ lista jóváhagyása.

Csoportmegbeszélések A KST-interjúkat egyénileg ill. csoportmegbeszélések formájában lehet lefolytatni. A csoportmegbeszélések idõt takarítanak meg és gyakran hatékonyabbak, mint az egyéni interjúk. Ha azonban a csoportok túl nagyok, nem sokat lehet elérni velük és a megbeszélés célja elveszhet. A megbeszélésen résztvevõ csoportok ezért legfeljebb hat vezetõbõl és két vagy három interjúkészítõbõl álljanak. Ügyelni kell arra, hogy jó gyakorlat érvényesüljön a csoportmegbeszéléseken, azaz: q az idõpont, a helyszín és a napirend kerüljön elõre egyeztetésre, q a résztvevõket ösztönözni kell, hogy a megbeszélésre készüljenek fel, q legyenek elõre megállapított és elfogadott alapszabályok a megbeszélésen történõ

felszólalásra, közbevágásra, kérdésfeltevésre valamint a kezdés és zárás idõpontja pontosan be legyen tartva, q erõs, tekintéllyel bíró elnök (vitavezetõ) vezesse le a megbeszélést és biztosítsa az

alapszabályok betartását, q a célok és az elkészítendõ dokumentumok elõre legyenek lerögzítve,

MTA Információtechnológiai Alapítvány, 1993

q a résztvevõk megadott szerepeket töltsenek be, azaz legyen kérdezõ, jegyzõ stb.

Lehetséges kérdésfeltevések Több olyan kérdés van, amelyek feltevésével elõ lehet segíteni a megbeszélés sikerességét. Az elsõ és a legnyilvánvalóbb: q Mik a szervezet sikeres mûködésének a kulcstényezõi?

További kérdések lehetnek: q Miért hozták létre a szervezetet? q Miért veszik igénybe az ügyfelek a szervezet szolgáltatásait? q Mik az elismerés fõ forrásai? q Vannak-e olyan speciális "lehetõségek a kiemelkedésre", ahol egy viszonylag kis

"lökés" jelentõs hatással lehet az eredményességre? q Milyen tényezõk akadályozzák meg a szervezetet, hogy kétszer olyan eredményes

legyen, mint ma? Annak, hogy egy szervezet számára jó KST-k legyenek megállapítva, fontos részét képezik az ún. "kritikus feltételezések". A kritikus feltételezések olyan dolgok, amikrõl a KST-ket megállapító emberek úgy gondolják, hogy az egyes tényezõk alapjául szolgálnak. Gyakori, hogy közelebbrõl megvizsgálva ezek a feltételezések vagy hamisnak, vagy csak részben helytállónak bizonyulnak. Amikor az egyéni interjúk vagy a csoportmegbeszélések lezajlottak, a Munkacsoportnak össze kell vetni az eredményeket és nyilvánosságra kell hoznia a KST-k listáját a kapcsolódó kritikus feltételezésekkel együtt minden egyes mûködési területre. Ezeket a megállapításokat az interjúk elsõ körében részt vett vezetõknek és -lehetõség szerint - a felsõ vezetés képviselõjének is át kell vizsgálni. Hogy az esetleges módosítások és változtatások átvezethetõk legyenek, egy visszajelzési mechanizmust kell kiépíteni.

A kulcsfeladatok kialakítása Bevezetés Amikor a célok meghatározásával kapcsolatos munkát végezzük, fennáll a veszélye annak, hogy a szervezet mûködésére és az informatikai stratégiatervezésre vonatkozó fogalmak összekeverednek. Egy informatikai stratégiatervezési projektben a célok meghatározása nem helyettesíti a szervezeti-mûködési tervezést. Mindazonáltal fontos, hogy a megfogalmazott informatikai feladatokat a szervezet valós mûködésébõl ill. rendeltetésébõl fakadó igények támasszák alá. A gyakorlatban sok probléma lép fel azoknak az adatoknak az összegyûjtésével és összevetésével kapcsolatban, amelyek a célok és az informatikai feladatok kitûzéséhez szükségesek. q A projekt e szakaszában jelentõs mennyiségû anyag áll már rendelkezésre, amelynek

egy része a projekt során elõzõleg keletkezett. Ezt az információt meg kell vizsgálni és be kell vonni a folyamatba.

Bevezetés

SZERVEZETI-MÛKÖDÉSI TERVEK

EDDIG ELKÉSZÜLT PROJEKTJELENTÉSEK

57

KRITIKUS SIKERTÉNYEZÕK

CÉLOK

q Valószínûleg sok olyan emberrel kell interjút készíteni, akik mindegyike elfoglalt és

bizonyos esetekben a projekt "centrumához" képest távoli helyeken dolgoznak. A többszöri interjúkat ugyanazzal a személlyel lehetõleg el kell kerülni. q Sok egymáshoz kapcsolódó feladat van a folyamat során, mint pl. az interjúk és

megbeszélések elõkészítése, csoportmegbeszélések lefolytatása, az interjúk/megbeszélések eredményeinek összevetése, felülvizsgálat és javítási feladatok. A folyamat körültekintõ megtervezése és irányítása nélkülözhetetlen a munka hatékony elvégzéséhez.

A résztvevõk A fejlesztés e szakaszában sok résztvevõt kell bevonni a célok és a feladatok meghatározásához.

A Munkacsoport A szakmai folyamatokat jól ismerõ képviselõkbõl és informatikusokból áll.

Területi reprezentánsok (képviselõk) Minden mûködési területrõl ki kell nevezni legalább egy személyt, aki részt vesz a Munkacsoport különféle kulcstevékenységeiben. Ez fontos szerep, amelyet olyan megbízható, tekintéllyel rendelkezõ és ötletgazdag személyre kell kiosztani, akire mindig számítani lehet a mûködési terület érdekeinek képviselete tekintetében. Természetesen a mûködési terület mélyreható ismerete alapkövetelmény.

Informatikai szóvivõk Az együttes feladatkitûzõ ülések során, amelyek az informatikai stratégia meghatározására hivatottak, minden mûködési terület egy-egy Informatikai szóvivõvel képviselteti magát, aki az informatikai stratégia tárgykörében az érdekükben felszólal. Az Informatikai szóvivõnek az informatika és annak felhasználása a saját mûködési területén belül feltétlenül az érdeklõdési körébe kell essen; határozott elõnyt jelent a jelenleg elérhetõ technológiák alapos ismerete.

Zsûri Ezt a csoportot a mûködési területek rangidõs vezetõibõl kell összeállítani. A Zsûri szerepe a stratégiai terv kifejlesztésével kapcsolatos fõ termékek szemrevételezése. Várhatóan három-négy alkalommal kell összeülniük a munka tervezési részében.

MTA Információtechnológiai Alapítvány, 1993

Az interjúkban résztvevõ vezetõk és személyzet Ezek azok a személyek, akiket interjúra kijelöltek. Be lesznek vonva a szemle utáni visszacsatolási körbe (post review feedback cycle) is. Sokan közülük Területi reprezentánsok vagy Zsûritagok is lesznek.

A folyamat Ezek a csoportok a végleges kulcsfeladatok meghatározásának különbözõ szakaszaiban vesznek részt. A folyamatot három lépésnek lehet tekinteni: q Elõkészület. q Vezetõi interjúprogram. q Közös feladatkitûzõ ülés.

Mindegyik lépés tovább-bomlik az alábbiak szerint.

Elõkészület q A Munkacsoport és a Területi képviselõk "kiindulási", "1. fordulós" (first cut) célokat

hoznak létre a szervezeti-mûködési terv alapján. q Az elõzõ szakaszban elkészített projektjelentések vizsgálata és az ún. SCOPE-

elemzés (átfogó célelemzés) hajtanak végre a "javasolható" (second cut) célok meghatározására.

Vezetõi interjúprogram Az interjúk célja kulcsfeladatok meghatározása az informatika felhasználására és informatikai módszerek alkalmazása érdekében. Ennek során: q Ki kell osztani az interjúalanyoknak felülvizsgálat céljából:

-

a szervezeti-mûködési terv idevonatkozó részeit,

-

az elõzõ szakaszban elkészített projektjelentéseket,

-

a KST-fejlesztés eredményét,

-

az elõkészület során feladatkitûzéseket.

létrehozott

kiindulási

és

javasolható

cél-

és

q Le kell folytatni az interjúkat az egyedi cél- és feladatkitûzések meghatározására. q A Munkacsoportnak az egyedi célokat rendbe kell rakni, össze kell vonni valamint

optimalizálni kell a kulcscélok és -feladatok szûkebb körévé. q Felül kell vizsgáltatni a kulcscélokat és -feladatokat a Zsûrivel. Az észrevételek

alapján a módosításokat, javításokat a Munkacsoportnak át kell vezetnie.

Közös feladatkitûzõ ülések q Meg kell határozni az informatikai irányítási stratégiát. q A

Munkacsoportnak módosítania kell a jelenlegi rendszerekrõl összegyûjtött információkat a kulcscélok és -feladatok ismeretében.

q A Munkacsoportnak javaslatot kell tennie egy mûködõképes informatikai irányítási

stratégiára és a kapcsolódó cél- és feladatkitûzésekre. q Közös feladatkitûzõ ülést kell szervezni a vezetõk egy kiválasztott csoportjával a

Munkacsoport által javasoltak megvizsgálására, ahol végül dönteni kell a stratégiát illetõen, valamint meg kell határozni a célokat és feladatokat.

Bevezetés

59

q A Munkacsoportnak rendbe kell rakni, össze kell vonni valamint optimalizálni kell a

vezetõi célokat és feladatokat kulcscélokká és -feladatokká. q Felül kell vizsgáltatni a kulcscélokat és -feladatokat a Zsûrivel. Az észrevételek

alapján a módosításokat, javításokat a Munkacsoportnak át kell vezetnie.

Célok és feladatkitûzések Mielött a célok meghatározására és a feladatok megállapítására vonatkozó megközelítések és mechanizmusok számbavételére sor kerülne, elõször a kifejezések mögött húzódó fogalmakat kell tisztázni.

Célok A célokat általában a szervezeti-mûködési törekvések megfogalmazásaiból vezetik le. Ilyen tipikus megfogalmazások lehetnek: q Minden benyújtott munkanélküli segélyre vonatkozó kérvényt a benyújtástól számított

14 napon bíráljanak el. q A rendszeres követi jelentéseket a beérkezéstõl számított két héten belül fel kell

dolgozni. q A költségvetésben odaítélt összegek határidõre jussanak el a jogosultakhoz. q A felsõoktatásban az oktatók ugyanannyi idõ alatt 30%-kal több oktatási anyagot

tudjanak kidolgozni. A célokat az a tény különbözteti meg más törekvésektõl, szándékoktól, hogy mennyiségileg jellemezhetõek és mérhetõ eredménnyel járnak, amelyeket ellenõrizni lehet. Például a "A lakosság véleménye jó legyen a közbiztonság jelenlegi állapotáról" szervezeti törekvést ahhoz hasonló konkrét állításokra kell "lefordítani", mint amilyenek az alábbiakban vannak felsorolva, mielött életképes célnak lehetne tekinteni: q A megismert betörésés bûncselekményeknek legalább a fele felderítésre kerüljön. q A járõrkocsikban 1 percen belül eldönthetõ legyen, hogy egy adott rendszámú

gépjármû körõzés alatt áll-e. q A bûnesetek veszélyére figyelmet felhívó kiadványok, ismertetõk számát 30%-al

növelni kell. A célokat rendszeresített ún. célismertetõ ûrlapokon, vagy közvetlenül valamilyen arra szolgáló számítógépes eszközzel lehet dokumentálni. Minden célnak egyedi azonosítóval, fontossági besorolással, egy rövid és egy részletesebb leírással kell rendelkeznie. Minden célnak egy konkrét mûködési területre is vonatkoznia kell. Fel kell jegyezni az olyan lehetséges problémákat és kockázatokat, amelyek gátolhatják vagy megakadályozhatják a célok elérését. Az elérésükbõl származó várható hasznot is fel kell jegyezni, mégpedig amennyire lehet, konkrétan. Ebben a szakaszban nem szükséges részletes költség-haszon elemzésbe bocsátkozni, mivel az késõbb úgyis elvégzésre kerül. Fontos az is, hogy a célok elérésével kapcsolatos ellenõrzési és követési eljárások is megfogalmazásra kerüljenek, mivel a vezetés visszajelzést igényel arról, hogy milyen mértékben sikerült a célokat elérni. Jó gyakorlat, ha az új rendszereket eleve úgy tervezik, hogy ezek az ellenõrzõ eljárások meg legyenek bennük valósítva, vagy legalábbis a szükséges "nyers adatot" szolgáltatni tudják. A "kiindulási" rangsor felállításának egyszerû módja a célok sürgõsségi szempontból történõ jellemzése egy 1-5-ig terjedõ skálán, ahol 1 használatos a leginkább és 5 a

MTA Információtechnológiai Alapítvány, 1993

legkevésbé sürgetõ célokra. Ez még csak egy kezdeti próbálkozás a rangsorolásra szubjektív értékítélet alapján. A késõbbi szakaszokban ez finomításra kerül pénzügyi számításokon alapuló technikákkal. A célokat a hozzájuk legközelebb álló KST-kkel is megfeleltetésbe kell hozni (kereszthivatkozást kell készíteni).

Feladatkitûzések Miután a célok meghatározásra kerültek, feladatkiírásokká kell átalakítani õket. Ennek során abból a szempontból kell a célokat vizsgálni, hogy milyen módon lehet teljesíteni õket az informatika felhasználásával. A feladatkitûzések kifejezetten informatikai jellegûek. A fejlesztés során meghatározott célok között lesznek olyanok, amelyeknek nincs közvetlen informatikai kihatása vagy megoldása. Ezeket fel kell jegyezni és el kell juttatni a szervezeti-mûködési tervezésért felelõs részleghez. Itt vizsgáljuk meg utoljára õket a fejlesztés során, és ha nem lehet informatikai feladatokat azonosítani velük kapcsolatban, akkor a továbbiakban nem foglalkozunk velük. Az informatikai stratégiatervezés kifejezetten az informatikával kapcsolatos szolgáltatások használatával és biztosításával foglalkozik, és nem szabad, hogy mellékvágányra terelõdjön a nem-informatikai megoldások vizsgálatával. Az interjú közben, mialatt az interjúalanyok mérhetõ és ellenõrizhetõ célokat határoznak meg, felkérik õket arra is, hogy fogalmazzanak meg rájuk egy vagy több informatikai feladatot. A feladatkiírásoknak a készítésénél több különbözõ informatikával kapcsolatos terület vehetõ tekintetbe, úgymint: q új rendszerek fejlesztése, q meglévõ rendszerek módosítása, q megvalósíthatósági tanulmányok készítése, q mûszaki értékelések ill. elemzések, q módszerek bevezetése, q szervezeti változtatások.

CÉL MIRE VAN SZÜKSÉG MÉRHETÕ ÉS ELLENÕRIZHETÕ FORMÁBAN

FELADATKITÛZÉSEK

HOGY LEHET INFORMATIKÁVAL ELÉRNI ?

Egy célhoz több informatikai feladatkitûzés tartozhat.

Bevezetés

61

Kulcscélok és -feladatok A célok és feladatok meghatározása után a Munkacsoportnak ezeket kulcscélokká és -feladatokká kell átalakítani. Az interjúalanyok általában saját, egyéni véleményüket fogalmazzák meg. Ha ezen az egyéni szinten hagynánk a célokat és feladatokat, áttekinthetetlen mennyiségû dokumentációból kellene a feladattervet "kihámozni". Ezért szükséges csökkenteni a számukat azáltal, hogy összevonjuk és optimalizájuk õket. Az interjúk végén így egy összesített lista áll majd rendelkezésre a "kulcs"-célokról és -feladatokról.

Felkészülés a vezetõi interjúkra Bevezetés A cél és feladat fogalmának tisztázása után visszatérünk a meghatározásuk folyamatára. MUNKACSOPORT ÉS A TERÜLETI KÉPVISELÕK

KEZDETI CÉLOK FELÁLLÍTÁSA

KEZDETI CÉLOK

MUNKACSOPORT ÉS A TERÜLETI KÉPVISELÕK

SCOPE ELEMZÉS JAVASOLHATÓ CÉLOK ÉS FELADATOK MEGFOGALMAZÁSA

Két lépésben kell felkészülni a vezetõi interjúkra, elõször a "kiindulási" (first cut), majd utána a "javasolható" (second cut) célokat kell meghatározni. Mielött az interjúkat elkezdené, a Munkacsoportnak elõ kell készíteni a talajt bizonyos, nem az interjúk miatt készített dokumentumok elemzésével. Ha a szervezet készített mûködési tervet, akkor az elõkészítés elsõ tevékenysége ennek a tervnek a vizsgálata lesz azért, hogy minden mûködési területre meglegyen a "kiindulási" célok egy-egy listája a tervben megfogalmazott törekvéseken és feladatokon alapulva. A "kiindulási" célokat elõ lehet állítani a mûködési tervbõl, de meg lehet õket határozni az ún. SCOPE-elemzéssel is. Ezek még nem túl konkrétak, de rámutatnak azokra a pontokra, amiket az interjúalanyok jobb ismereteik révén valós célokká és feladatokká tudnak kibontani. A "kiindulási" célok rögzítése után minden mûködési területen SCOPE-elemzést kell végezni. Ebben a lépésben a csoport és a területi képviselõk több szempont figyelembe vételével kibõvítik és módosítják a "kiindulási" célokat, például: q Synergy - együttmûködés informatika terén az ügyfelekkel és a beszállítókkal. q Competitor - az informatika alkalmazásának vizsgálata a társszervezeteknél. (Az

elemzés a profit-orientált szférából származik, értelemszerûen kell a közszolgálati szférában felhasználni.) MTA Információtechnológiai Alapítvány, 1993

q Opportunities - a szervezet elött álló lehetõségek feltárása. q Present - a jelen helyzet felmérése az eddig készített projektjelentések elemzésével. q Expenditure - a kiadások és a befektetések elemzése.

"Kiindulási célok" Nehéz bármit is elõírni ezzel a tevékenységgel kapcsolatban, a célja mindenesetre az, hogy az esetlegesen létezõ szervezeti-mûködési terv átvizsgálásra kerüljön és onnan minden olyan cél kiemelésre kerüljön, ami az adott stratégiafejlesztésre érvényes lehet. Nyilvánvaló, hogy a szervezeti-mûködési terv tartalma és formája szervezetrõl szervezetre változik, így azt, hogy a tevékenység pontosan milyen módon legyen végrehajtva, a Projektirányítónak kell eldönteni. A szokásos gyakorlat szerint legalább a Munkacsoport egy elemzõje dolgozik a Területi reprezentánsokkal (mindegyik mûködési területrõl). Az õ tevékenységük többek között: q a szervezeti-mûködési terv vizsgálata, q amennyiben lehetséges, mûködési területenként a tervvel összhangban álló célok

összegyûjtése. Ezeknek a "kiindulási" céloknak kettõs szerepe van. Elõször is biztosítani kell, hogy ha a stratégiatervezési projekt elött készült szervezeti-mûködési terv, akkor annak célkitûzései beépüljenek a stratégiatervezési projekt eredményeibe. Másrészt kiindulási pontot kell adni a Munkacsoport számára a munkavégzéshez. A szervezeti-mûködési tervnek, ha létezik, kulcsszerepet kell játszania a lehetséges célok megfogalmazásában. Ha nem áll rendelkezésre hivatalos szervezeti-mûködési terv, akkor nem lesznek "kiindulási" célok és helyette a munka a SCOPE-elemzéssel kezdõdik. Mûködési területenként a "kiindulási" célokat formálisan rögzíteni kell, mint a késõbbi szakaszokban felhasználandó információt.

"Javasolható célok" A SCOPE-elemzést mûködési területenként kell elvégezni a Munkacsoport legalább egy tagjának és az adott mûködési terület képviselõjének bevonásával. A munka célja több különbözõ olyan szempont tanulmányozása, amelyek hatással lehetnek az informatika szervezeten belüli alkalmazására, és javíthatják a "kiindulási" célokat, sõt bõvíthetik is azok körét "javasolható" célokká. Célszerû ennél a lépésnél, ha a Munkacsoport próbaképpen már most feladatokat is társít a célokhoz.

Együttmûködés A SCOPE-elemzés elsõ része annak értékelésével foglalkozik, hogy milyen elõnyökkel járhat a szervezet számára egy szorosabb együttmûködés kialakítása vagy hasznosítása informatika területén a szervezet saját ill. annak ügyfelei és/vagy beszállítói között. A következõ kérdésekre kell tekintettel lenni: q Használnak-e az ügyfeleink vagy beszállítóink informatikát a mûködésük folyamán? q Kiterjed-e ez a használat a mi szervezetünkkel vagy az õ más ügyfeleikkel ill.

beszállítóikkal fennálló kapcsolatra? (Pl. népegészségügyi adatok számítógépes formában történõ átadása.) q Tudjuk-e csökkenteni a költségeinket ill. növelni a hatékonyságunkat annak lehetõvé

tételével, hogy a rendszereinket az ügyfeleink és beszállítóink is használni tudják? q Tudjuk-e csökkenteni a költségeinket ill. növelni a hatékonyságunkat annak lehetõvé

tételével, hogy mi tudjuk az ügyfeleink vagy beszállítóink rendszereit használni iletve,

Bevezetés

63

hogy a rendszereink szoros kapcsolatban álljanak az övékével? q Jelent-e hátrányt egy szorosabb kapcsolat kiépítése az ügyfeleink vagy beszállítóink

rendszereivel? Éppen hogy kevésbé elérhetõvé kellene tenni a rendszereinket?

Társszervezetek A SCOPE-elemzés második része azt értékeli, hogy miként használják az informatikát a társszervezeteknél. Ha korábban történt ilyen jellegû felmérés, akkor itt meg kell vizsgálni ennek az eredményét. Mindegyik esetben a cél annak feltárása, hogy felhasználhatók-e azok az ismeretek, amit az informatika társszervezeteinknél történõ alkalmazásáról meg lehet tudni, az informatika saját szervezetünknél való alkalmazásában. q Használják-e

jelentõs mértékben hatékonyság növelésére?

az

informatikát

a

társszervezeteinknél

a

q Elismertségük megszerzésében, növelésében lényeges tényezõ-e az, ahogy az

informatikát alkalmazzák? q Hogyan álljuk az összehasonlítást velük az informatika alkalmazásának területén? q Kellene-e bármi módon követni a társszervezeteinket? q Lehetne-e

vagy szükséges lenne-e még társszervezeteinkrõl a jövõ szempontjából?

több

információt

szerezni

a

Lehetõségek A harmadik fajta elemzés általában veszi szemügyre az informatika lehetõségeit a szervezeten belül. Fõleg a Területi reprenzentánsok gondolataira építve, de felhasználva a szervezetrõl megszerzett ismereteiket is, a Munkacsoportnak fel kell tárnia azokat a szóbajöhetõ területeket, ahol az informatika jelentõsen hozzá tud járulni a szervezet mûködésének javításához, rendeltetésének betöltéséhez. A cél nem "elõrehozni" az interjúk "elsõ körét", hanem olyan gondolatokat megfogalmazni az interjúalanyok számára, amelyeket azoknak még az interjú elött véleményezniük kell. Egy hasznos technika az informatikai lehetõségek meghatározására az ún. SWOTelemzés. Ez a megközelítés kiterjeszti az elemzést a következõkre: q Strengths

Erõs oldalak

q Weaknesses

Gyenge pontok

q Opportunities

Lehetõségek

q Threats

Fenyegetések

Mûködési területenként az elemzõ és a Területi reprezentáns az adott terület erõs oldalaival kezdi a számba vételt, majd folytatja a gyenge pontokkal és így tovább: q Mik a szervezet erõs oldalai, és vajon lehet-e ezeknél az informatikára építeni ill.

felhasználni azt ezek megszilárdítására? q Mik a gyenge pontjaink, és vajon lehet-e ezeket háttérbe szorítani ill. megerõsíteni az

informatika segítségével? q Mik az alapvetõ lehetõségek a mûködési területen belül, és vajon lehet-e az

informatika segítségével maximalizálni ill. kihasználni ezeket a lehetõségeket? q Milyen fõbb fenyegetéseknek van kitéve a mûködési terüleet? Hogy lehet ezeket

minimalizálni ill. csillapítani az informatika alkalmazásával?

MTA Információtechnológiai Alapítvány, 1993

Jelen helyzet A SCOPE-elemzés negyedik része a jelen helyzet elemzésével foglalkozik. A fejlesztés elsõ szakaszában, "A jelenlegi mûködés és informatikai megközelítés vizsgálata" során több jelentést készült. A jelen helyzet elemzése az elkészült dokumentumok közül az ún. elemzõ dokumentumok vizsgálatával foglalkozik, azaz a "A jelenlegi rendszerek és a tevékenységek viszonya", a "A jelenlegi rendszerek szerepe a rendszerre ható erõk támogatásában" és a "A jelenlegi informatikai irányítás viszonya" jelentésekkel. (Ha a projekt nem ilyen jelentéseket készített volna el, akkor a megfelelõ információtartalomra utalunk a továbbiakban.) A jelentésekre és a belõlük levont, idevágó következtetésekre alapozva határozzák meg a "javasolható" célokat. "A jelenlegi rendszerek és a tevékenységek viszonya" jelentés tartalmazza mûködési területenként a tevékenységeket és ezek osztályozását, azaz, hogy magas vagy alacsony az információtartalomuk, a költségük ill. az értékük. Ez azt is mutatja, hogy milyen jelenlegi rendszerek támogatják az egyes területeket. Általában azokat a tevékenységeket támogatni kell, amelyek minden szempont szerint "magas" besorolást kaptak. Ha a jelentés egy ilyen tevékenységet anélkül tartalmaz, hogy jelenleg bármilyen rendszer támogatná, ez jelezheti, hogy érdemes informatikai támogatás lehetõségét fontolóra venni ezen a területen. Ezen túlmenõen a jelentés olyan tevékenységeket is tartalmazhat, amelyek több szempontból is "alacsony" besorolást kaptak. Ez általában arra utal, hogy további informatikai befektetés ezeknél a tevékenységeknél nem indokolt. Egyes tevékenységek "magas" besorolást kaphatnak az érték és a költség szempontjából, ugyanakkor "alacsony"-t az információtartalom tekintetében. Ez gyakran azt jelzi, hogy az informatika automatizálási céllal történõ további alkalmazása hatékony lehet. A manuális tevékenységek is idõnként ebbe csoportba esnek. Nyilván egy jelentés csak figyelemfelkeltõ szerepet játszik, és minden egyes esetet a saját kontextusában és önmagában kell megvizsgálni. Például a jelentésbõl az következhetne, hogy egy tevékenységet célszerû informatikával támogatni, de megvizsgálva az esetet kiderülhet, hogy: q a gyakorlatban nincs járható út az informatika alkalmazására az adott tevékenység

végrehajtására vagy megsegítésére, q a szükséges technológia teljesen kívül esik a szervezet tapasztalati körén, és egy

ilyen technológia bevezetését nem lehet igazolni pusztán egy egyedi esettel. Gyakran, különösen ott, ahol az utóbbi eset áll fenn, el kell gondolkozni a tevékenység szerzõdéses alapon történõ "kitelepítésén" egy olyan másik szervezethez, amely a rendelkezésére álló kifinomult technológiával hatékonyabban képes elvégezni a munkát, mint ahogy azt "házon belül" lehetne. "A jelenlegi rendszerek szerepe a rendszerre ható erõk támogatásában" jelentés mûködési területenként és a megállapított fõ mûködési stratégiából kiindulva mutatja az ellensúlyozásra ajánlott rendszerre ható erõket és annak módját, valamint hogy a jelenlegi rendszerek támogatják-e ezeket. Emellett az adott mûködési területet támogató összes rendszerre felsorolja a rendszerre ható erõket és az ellensúlyozásuk módját, valamint hogy ezek ajánlottak-e. Ez a jelentés áttekintõ képet ad a jelenlegi helyzetrõl és megmutatja, hogy a jelenlegi rendszerek milyen mértékben szolgálják a mûködési hatékonyságot. Kimutathatja, hogy egy szervezetben túl kevés rendszer ad támogatást a rendszerre ható erõkkel szemben. Ez általában azért van, mert az informatikusok és a felhasználók nem abban gondolkodnak, hogy az informatikát eszközként használva közvetlenül ezeket az erõket ellensúlyozzák. Nagyon ritkán érzik csak szükségesnek ezeket az erõket egy mûködési

Bevezetés

65

területen belül megvizsgálni, és tudatosan beépíteni az ezekkel kapcsolatos támogatást az újonnan fejlesztett rendszerekbe. A Munkacsoportnak meg kell vizsgálnia a jelenlegi rendszerek módosításának azokat a lehetõségeit, amelyek a rendszerre ható erõk ellensúlyozásával a szervezet mûködését elõsegítik. Egyes esetekben célszerû lehet "javasolható" célokat, sõt feladatokat is kitûzni felsorolva azokat a rendszereket, amelyek újrafejlesztését a mûködési hatékonyság biztosításához meg kellene valósítani a megfelelõ erõk megfelelõ módon történõ ellensúlyozásával. A tevékenységekrõl szóló jelentés alapján mûködési területenként öt osztályba sorolhatjuk azokat a tevékenységeket, ahol jövõbeni informatikai befektetés indokolható. Ezek: q magas érték, költség és információtartalom, q magas érték és információtartalom, q magas költség és információtartalom q magas információtartalom, q magas érték, költség és alacsony információtartalom.

A Munkacsoportnak nem szabad automatikusan pusztán erre az öt osztályra alapozva meghatározni a "javasolható" célokat és feladatokat; a jelentés csak kiindulási pontot ad a gondolkozáshoz arra vonatkozóan, hogy a szervezet melyik területe számára nyújtana elõnyöket az informatika. Annak az eldöntése, hogy az informatikát lehet-e egyáltalán költséghatékonyan alkalmazni egy ilyen "magas" besorolású tevékenységnél, önmagában is egy olyan feladat lehet, amely megvalósíthatósági tanulmány készítését teszi szükségessé. Habár nem mindig nyilvánvaló, hogy hol lehet az informatikát elõnyösen alkalmazni, de majdnem mindig érdemes röviden azt is megvizsgálni, hogy egy olyan tevékenység, amelynek nincs jelenleg informatikai támogatása, de mind a három szempont szerint "magas" kategóriába tartozik, nem húzhat-e hasznot az informatika felhasználásából.

Kiadások Az utolsó lépés a SCOPE-elemzés során a kiadások és a ráfordított összegek rövid áttekintését adja. A cél az, hogy a Munkacsoport figyelme azokra a területekre irányuljon, ahol a legnagyobb költségek merülnek fel, vagy ahol a legnagyobb pénzösszegek kerültek befektetésre. Nem törekszik mélyreható pénzügyi elemzésre, inkább csak emlékeztetõként szolgál az informatika legvalószínûbb alkalmazási helyeire. A Munkacsoport mûködési területenként az adott terület képviselõjével együtt kell áttekintse a vezetés által átadott könyvelési és mûködési számadatokat. Nem mindig lehet konkrét célokat megfogalmazni ezen a területen,hanem csak "kiindulási" célokat, amelyeket majd az interjúalanyoknak kell majd még alaposan megvizsgálniuk. A területenként elvégzett SCOPE-elemzések végére a Munkacsoport és a területi képviselõk több, különbözõ forrásból "javasolható" vagy "2. fordulós" célokat határoznak meg. Ezeket mutatják meg az interjúalanyoknak mint "figyelemkeltõ" célok. Az interjúk során e "2. fordulós" célok egynémelyikét lehet, hogy elvetik, míg másokat olyan valós célokká finomítanak tovább, amelyek a késõbbi lépésekben kulcscélokká és -feladatokká válhatnak.

Vezetõi interjúprogram Bevezetés A vezetõi interjúprogrammal kapcsolatos fõ feladatok már ismertetésre kerültek, de talán MTA Információtechnológiai Alapítvány, 1993

hasznos röviden átismételni õket ennél a lépésnél: q Az alábbi anyagokat kell szétosztani az interjúalanyoknak vizsgálat céljából:

-

a szervezeti-mûködési terv idevonatkozó részeit,

-

az elõzõ szakaszban készített projektjelentéseket,

-

a KST-fejlesztés eredményeit,

-

az elõkészítés során feladatkitûzéseket.

meghatározott

kiindulási

és

javasolható

cél-

és

q Interjúkat kell készíteni az egyedi célok és feladatok meghatározása céljából. q A kulcscélok és -feladatok szûkebb körének meghatározása végett a Munkacsoport

feldolgozza, összevonja és optimalizálja az egyedi célokat. q A kulcscélokat és -feladatokat a Zsûri felülvizsgálja. Az észrevételek alapján a

módosításokat, javításokat a Munkacsoport átvezeti. Szervezeti-mûködési tervek INTERJÚALANY

Kritikus sikertényezõk A már elkészített dokumentumok áttekintése

Javasolható célok Eddigi elkészült projektjelentések

MUNKACSOPORT / INTERJÚALANYOK Közös feladatkitûzõ megbeszélés Egyedi célok és -feladatkitûzések

MUNKACSOPORT Kulcscélok és -feladatok megfogalmazása Kulcscélok és -feladatkitûzések

ZSÛRI Szemrevételezés és javítások kezdeményezése

Amint a lényeges információk rendelkezésre állnak, szét kell osztani azokat az interjúalanyok között. Minden interjúalanynak az interjút megelõzõen az információk négy csoportját kell átvizsgálnia: q a szervezeti-mûködési tervet, q az elemzési jelentéseket, q a kritikus sikertényezõket mûködési területenként, q a "javasolható","2. fordulós" célokat mûködési területenként.

Csak annak az információnak a vizsgálatára kell az interjúalanyokat felkérni, amely a saját mûködési területére vonatkozik, és elegendõ idõt kell hagyni rá. A vezetõi interjúk során minden interjúalany - lehetõleg egy interjú alkalmával - a kérdések két csoportjával fog foglalkozni. Az elsõ csoport az informatika felhasználásával, a második a szervezeten belül alkalmazandó informatikai módszerekkel kapcsolatos.

Bevezetés

67

Ideális esetben egy interjún a Munkacsoport két tagja vesz részt: az egyik kérdez, a másik az interjú eredményeit rögzíti. Amikor az interjúk mûködési területenként befejezõdtek, a Munkacsoport összegzi az eredményeket kulcscélok és -feladatok formájában. Amikor ezek a kulcscélok és -feladatok elkészültek, össze kell hívni a Zsûrit az eredmények átvizsgálására és megvitatására. Ha nagyszámú kulcscél és -feladat van, lehet, hogy a szemlét több ülésben kell megvalósítani.

Interjúalanyok Azoknak a személyeknek a listája, akikkel interjú készül, szervezetrõl szervezetre változik, de általában tartalmazza: q a mûködési területek struktúráján kívül esõ, befolyásos vezetõket, q a mûködési területek fõosztályvezetõit, q a mûködési területek helyettes fõosztályvezetõit, q a mûködési területek informatikai szóvivõit, q a mûködési területek osztályvezetõit a fõosztályvezetõi ill. helyettesi szint alatt, q a támogató funkciók igazgatóit, pl. bérszámfejtés, személyzeti ügyek stb., q a mûködési területek képviselõit, q egyes vezetõket a támogató funkcióktól, q informatikai középvezetõket, q informatikai vezetõket és kulcsszerepet játszó szervezõk-elemzõket, q informatikai igazgatót.

Interjústruktúra: az informatika felhasználása A kérdések elsõ csoportja arra keres választ, hol használjuk fel az informatikát a szervezetben. Az informatikafejlesztés területének értékelésénél a Munkacsoportnak egy meghatározott fontossági sorrendet kell követnie: q Hogyan lehet az informatikát felhasználni a mûködési hatékonyság növelésére? q Hogyan lehet az eredményességet növelni jobb információk használatán keresztül? q Hogyan lehetne a költségeket csökkenteni? q Hogy lehetne az alaptámogatást biztosítani?

Nem lehet mindig olyan példát találni, amelyik a fenti kategóriák mindegyikéhez illeszkedik. és valószínû, hogy a fõ hangsúly az informatika mûködési hatékonyságot növelõ alkalmazására fog esni, majd ezt követik a lista többi kategóriái. Az utolsó három kategóriáról sem szabad elfeledkezni, minthogy jelentõs számú jövõbeni projekt továbbra is azzal fog foglalkozni, hogy több, jobb információ álljon rendelkezésre, csökkenjenek a költségek, vagy hogy alapszolgáltatások biztosítva legyenek.

Informatikai módszerek Amikor az "informatika hasznosítási" része az interjúnak lezajlott, indulhat az "informatikai módszerek" rész. Ebben a részben az interjúalany áttekinti az informatika a jelenlegi megközelítéseit, valamint hogy ezek mennyire felelnek meg a szervezet igényeinek. A megvitatásra váró területek közé tartozik: q az informatikai koncepció (IT policy), MTA Információtechnológiai Alapítvány, 1993

q az értékelés és tervezés módja, q az ellenõrzés módja, q a módszerek, q az adatkezelés, q a hardver és szoftver használata, q a mûszaki személyzet, q az oktatás, q a minõségirányítás (quality management).

Hasonlóan az "informatika hasznosításához", ezen a területen is célokat kell meghatározni.

Célok A Munkacsoportnak bátorítani kell az interjúalanyokat arra, hogy az elõzõ lépésbõl eredõ, "javasolható" célokkal kezdje a munkát. A "javasolható" célok átvizsgálása után segíteni kell minden interjúalanynak abban, hogy megfogalmazza az õ saját elképzelését a mûködési területére vonatkozó célokkal kapcsolatban. Ezek lehetnek a "2. fordulós" vagy "figyelemfelkeltõ" célok kifejtései, de lehetnek teljesen újak is. Ha az interjúalany nem ért egyet a javasolt "2. fordulós" célmegfogalmazással, akkor akkor ezt az interjú készítõjének fel kell jegyeznie. A célok azonosításával egyidejüleg a célokat ki kell egészíteni az õket meghatározó pontos, mérhetõ követelmények megadásával. A célok megfogalmazása után arra kell figyelmet fordítani, hogy milyen módon érhetõk el, vagy másképp fogalmazva, minden egyes célhoz feladatkitûzéseket kell kapcsolni. Nem minden cél informatikához fûzõdõ! Az informatikához nem kapcsolódó célokat meg kell jelölni, és át kell adni a szervezetfejlesztési mechanizmus számára. A Munkacsoportnak a feladatkitûzések összeállításakor még egyszer lesz lehetõsége annak eldöntésére, hogy az illetõ célok elérésében az informatika alkalmazható-e, vagy sem. Amennyiben ekkor újra az derül ki, hogy ez nem lehetséges, úgy ezekkel a célokkal a továbbiakban nem foglalkozunk. Nem feledkezzünk meg arról, hogy egy megvalósíthatósági tanulmány vagy mûszaki értékelés elvégeztetése is lehet egy feladatkitûzés tárgya. Amirõl elsõ pillantásra úgy tûnik, hogy nincs köze az informatikához, az mélyebb vizsgálatok után egy informatikai projekthez vezethet. Az interjúk során három szinten kerül a célok és a feladatkitûzések megvitatása terítékre.

1. szint: az informatika stratégiai alkalmazása Itt lényegében egyetlen kérdés merül fel:

q Tudjuk-e az informatikát a hatékonyságunk növelésére használni? Néha olyan stratégiai lehetõségeket is ki lehet aknázni, melyek elsõsorban profit-orientált szférára jellemzõek:

q Lehetséges-e az informatikát önálló bevételi forrásként, új mûködési területként felhasználni?

q Segít-e minket az informatika abban, hogy szolgáltatásaink mások legyenek, mint amit a versenytársak ajánlanak?

Bevezetés

69

2. szint: döntéstámogatás q Lehetséges-e a döntéseinknek a hatékonyságát és minõségét növelni jobb és/vagy több információ felhasználásával?

3. szint: az informatika stratégiai alkalmazása q Képesek vagyunk-e költségcsökkentést elérni új rendszerek fejlesztése vagy a meglevõk továbbfejlesztése által?

q Vannak-e olyan területek, ahol az alapvetõ támogatás biztosításához (pl. bérszámfejtés) új rendszerekre vagy a meglevõk lényegi továbbfejlesztésére lenne szükség? A kérdéseket a fenti, fontosság szerinti sorrendben kell feltenni, azaz az 1. szinttõl kezdve.

Interjúhierarchia Az interjúkat felülrõl-lefele haladva ajánlott elvégezni, azaz elõször az elöljárót kell megkérdezni, és utána a hierarchiában egy szinttel alatta elhelyezkedõ beosztottakat. Ahogy az interjúkészítés folyamata halad elõre a vezetés hierarchiájában, a különbözõ személyek által megfogalmazott egyéni (egyedi) célok és feladatkitûzések között ellentmondások léphetnek fel. Ezt ellentétnek (clash) nevezzük. Az ellentétek a szervezet feladatkitûzéseiben rejlõ összeférhetetlenségekre utalnak, melyeket meg kell szüntetni. A felsõvezetés céljait minden alacsonyabb szintnek el kell fogadni, ha valóban arra törekszünk, hogy az informatika a szervezeti célokat támogassa. Ilyen ellentmondások felderítésére jó megközelítésnek bizonyulhat a 'célok eltitkolása'. Ennek során az interjúk hierarchikusan, felülrõl-lefele készülnek. Elõször a vezetõ céljai és feladatkitûzései kerülnek megbeszélésre, és csak azután az alárendelteké. Az 'eltitkolás' szó arra utal, hogy a vezetõ céljai és feladatkitûzései nem kerülnek nyilvánosságra a beosztottak interjúja elött.

Ellentétek (clashes) Sokfajta ellentét léphet fel:

q a beosztottak céljai és feladatkitûzései nem egyeztethetõk össze a vezetõjük elképzeléseivel,

q azonos

hierarchiaszinten összeférhetetlenek,

levõ

társcsoportok

céljai

és

feladatkitûzései

q habár a célok összeegyeztethetõek, elérési módjaik nem, azaz különbözõek a feladatkitûzések. A vezetõ és beosztottai között fellépõ nézetkülönbségek alapvetõ eltérésekre utalhatnak a problémák és feladatok megközelítésében és megoldásában. A célok ugyanarra a kritikus sikertényezõre vonatkozhatnak, de teljesen eltérõ stratégiákat körvonalazhatnak a siker elérésére. Természetesen ezeket az eltérõ stratégiákat harmonizálni kell. Az interjúkészítés struktúrált voltából következik az, hogy a magasabb szinten megfogalmazott céloknak alcsonyabb szinten meg kell jelenni. Fordítva, a közép- vagy alsóvezetés szintjén megfogalmazott célokat a felsõvezetés célkitûzéseihez kell kapcsolni. Ez a folyamat a szervezetnek és célkitûzéseinek alapvetõ újraértékelését eredményezheti. Az ellentétek fellépése gyakran meglepetésszerûen érik a szervezetet és elindíthatják annak vizsgálatát, hogy egyáltalán miért vannak problémák a szervezeten belül. MTA Információtechnológiai Alapítvány, 1993

Az ellentétek és prioritások feloldásának folyamata maga is további feladatkitûzésekre vezethet.

Kérdésgyûjtemény Az alábbiak kérdések csak ajánlások, és példa gyanánt szolgálnak. Természetesen nem kell minden egyes kérdést minden interjú során feltenni !

A. Az informatika felhasználása Az informatika mint a hatékonyság növelésének eszköze q Elképzelhetõ-e, hogy az informatikát a hatékonyság növelésére használjuk? q Milyen célokat kellene ennek érdekében kitûznünk? q Milyen

ezeknek a céloknak a sikertényezõkhöz való kapcsolata?

szervezeti

célkitûzésekhez

és

a

kritikus

q Hogyan lehetne a célok elérésébõl származó hasznokat mérni? q Lehet-e az informatikát a 'sikerességi egységek' adott idõtartamra vonatkoztatott mennyiségének növelésére használni?

q Lehet-e az informatikát a szolgáltatási/sikerességi egységre jutó költségeknek a csökkentésére használni?

q Az informatika lehetõvé tenné-e azt, hogy a felhasználói igények, a közizlés, a jogszabályozásban beálló változásoknak gyorsabban meg tudjunk felelni?

q Tudjuk-e az informatikát arra használni, hogy megakadályozzuk az egyének jogainak megsértését?

q Tudjuk-e

az informatikát úgy kötelességmulasztó/vétkes esetek számát?

alkalmazni,

hogy

csökkentsük

q Tudjuk-e az informatikát annak biztosítására használni, hogy a jogosultak az õket megilletõ összes szolgáltatásban részesüljenek (pl. nyugdíj, anyasági segély stb.)?

q Lehetséges-e az informatikát a szervezet és beszállítói közötti alkupozició javítására felhasználni?

q Tudunk-e az ügyfeleinknek olyan szolgáltatásokat nyújtani, melyek jobban megfelelnek az elõírásoknak, csökkentik a költségeket vagy gyorsabb ügyintézést tesznek lehetõvé?

q Lehetséges-e a meglevõ rendszereinket úgy módosítani, vagy újakat kifejleszteni, hogy más, olcsóbb, gyorsabb, jobb beszállítókat találjunk?

q Az informatika használatával megszüntethetõ vagy csökkenthetõ-e egyes beszállított anyagok iránt mutatkozó igény?

q Lehetséges-e a meglevõ rendszereinket úgy módosítani, vagy újakat kifejleszteni, hogy beszállítóink teljesítményét értékelni tudjuk, ezáltal nyomást gyakorolva rájuk?

q Lehetséges-e az informatikát a készletek minõségének javítására használni? q Lehetséges-e az informatikát úgy költségcsökkentésre használni, hogy egyes költségek másokra hárulnak majd?

q Lehet-e nyilvánvalóan az informatikát a szervezet költségvetésének csökkentésére, vagy az általa nyújtott szolgáltatások komfortjának növelésére használni?

q Tudjuk-e szolgáltatásaink értékét növelni az informatika használata által?

Bevezetés

71

q Tudjuk-e az informatikát potenciális ügyfeleink azonosítására használni? q Tudjuk-e az informatikát az ügyfeleink igényének felmérésében és annak kielégítésében hasznosítani?

q Fel tudjuk-e használni az informatikát az ügyfelek jobb informálására? q Az új rendszer vagy a meglevõ rendszer megnehezíti-e a vetélytársak belépését a mûködési területre? (versenyeztetett mûködési stratégia esetében)

q Az informatika alkalmazása annyira megnövelné-e a szolgáltatásaink vonzóerejét, hogy ez mások számára megnehezítené a versenyt? (versenyeztetett mûködési stratégia esetében)

q Tudjuk-e az informatika alkalmazásával olyan olcsóvá tenni a szolgáltásainkat, hogy új belépõk nem képesek a piacon megjelenni? (versenyeztetett mûködési stratégia esetében)

q Az informatika segítségével tudunk-e annyira más szolgáltatásokat ajánlani, hogy vetélytársak vonzóereje csökken az ügyfelek szemében? (versenyeztetett mûködési stratégia esetében)

q Lehetséges-e az informatika felhasználásával a piacon egyedi szolgáltatásokat ajánlani? (versenyeztetett mûködési stratégia esetében)

q Tudunk-e olyan rendszereket fejleszteni, vagy a meglevõket úgy módosítani, hogy

olyan szolgáltatásokat nyújtsunk, melyek a társzervezeteknél már rendelkezésre állnak?

q Meg tudjuk-e elõzni a vetélytársak elõre kiszámítható lépéseit informatikával? q Lehet-e az informatikát a vetélytársak költségeinek a növelésére használni? q Lehet-e a szervezeten belül egységek informatikai együttmûködését arra használni, hogy a mi és az ügyfeleink költségeit csökkentsük?

Az informatika önálló bevételi forrásként történõ felhasználásának témakörében: q Elfogadott cél-e az, hogy az informatikát önálló új mûködési területként kezeljük? q Hogyan jelenik ez meg a szervezeti tervekben? q Ha lenne ilyen cél, milyen kritikus sikertényezõkhöz kapcsolódna? q Minek alapján lehetne a döntést abban meghozni, hogy érdemes-e önálló üzletágként mûködtetni az informatikát?

q Van-e jelenleg példa a szervezeten belül arra, hogy az informatika versenyelõnyt biztosít, egy meglevõ rendszer fejlettebb, mint a vetélytársaké, potenciálisan értéket képviselõ adathalmaz?

q Lenne-e rá piac? q Tudnánk-e az informatikai szolgáltatásokat forgalmazni? q Rontaná az informatikai szolgáltatások forgalmazása egyéb pozicióinkat? q Vannak-e példák hozzánk hasonló intézményekre, ahol az informatikát önálló bevételi forrásként hasznosítják?

q Szükséges-e egy megvalósíthatósági tanulmány elkészítése a lehetõségek felmérése céljából?

MTA Információtechnológiai Alapítvány, 1993

Szolgáltatásaink javítása informatika felhasználásával: q Cél-e a szolgáltatásaink megkülönböztetése mások szolgáltatásaitól? q Van-e több ilyen cél, azaz többféle módon kellene a szolgáltatásainkat megkülönböztetni?

q Megjelenik ez a szervezeti tervekben és a kritikus sikertényezõkben? q Lehetséges-e a különbözõségekbõl származó hasznok mérérése? q Tudnánk-e direkt módon informatikai komponenseket szolgáltatásainkba vagy termékeinkbe beleépíteni, ami elõnyös lenne (pl. telefonkártya)?

Jobb információkkal történõ javítása a hatékonyságnak q Tud-e olyan célról, mely jobb információszolgáltatásra vonatkozik? q Ezek

a célok hogyan sikertényezõkhöz?

viszonyulnak

a

szervezeti

tervekhez

és

kritikus

q Hogyan lehetne ezeket a célokat mérni, számszerûsíteni? q A mûködési területen belül mely funkciók igényelnek több információt? q Milyen típusú információ érhetõ el jelenleg? q Vannak-e hiányosságok abban, ahogy az információ jelenleg elérhetõ? Vajon pontose, teljes-e, idõben elérhetõ-e és a használható formátumban áll-e rendelkezésre?

q Milyen változtatások lennének szükségesek? q Milyen új információk szükségesek? q Gyûjtik-e jelenleg ezeket az információkat? q Hogyan lehet e jelenleg még nem gyûjtött információkat megszerzni? q Van-e igény új vagy módosított döntéstámogatási rendszerre? q Milyen rendszerekre lenne igény? q Léteznek-e megfelelõ programcsomagok? q Költségek szempontjából alá tudjuk-e támasztani a javaslatokat?

A költségek csökkentése q Elfogadott cél-e a költségek csökkentése? q A mûködési területen belül lehet-e az informatikát a költségek csökkentésére használni?

q Milyen funkcióból származna haszon? q Mik a pontos költségcsökkentési célok? q Milyen rendszereket kellene módosítani? q Milyen új költségcsökkentési projekteket kellene megvizsgálni? q Vannak-e olyan elérhetõ programcsomagok, melyek csökkentenék a költségeket?

Alaptámogatás q Vannak-e olyan alaptevékenységeket ellátó területek (pl. számvitel), melyek jelenleg

Bevezetés

73

rosszul vannak informatikával támogatva?

q Igazolható-e az informatika használata ezeken a területeken? q Mik a tényleges célok? q Mely funkciók igényelnek számítógépes támogatást, és hogyan segítenék a tevékenységeket?

q Van-e igény a jelenlegi rendszerek módosítására? q Vannak-e olyan elérhetõ programcsomagok, melyek csökkentnék a költségeket?

Az alkalmazott módszerek az informatika területén Ezek a kérdések az interjúk második részére vonatkoznak, ahol a felhasználókat arról faggatjuk, mi a véleményük az információt rendelkezésükre bocsátó módszerekrõl.

Koncepciók q A jelenlegi informatikai koncepciók biztosítják-e, hogy a felhasználók teljes mértékben hozzájutnak az informatika felhasználásából származó hasznokhoz és elõnyökhöz?

q Ha nem ez a helyzet, hol vannak a gyenge pontok és hogyan lehetne rejtuk segíteni? q Milyen célokat és feladatokat kéne ezen a területen meghatározni? q Rendelkezünk-e a megfelelõ mennyiségû és minõségû erõforrással? q Milyen szervezeti módosításokra vagy felelõsségátruházásra lenne szükség (ha ennek igénye egyáltalában felmerül)?

Értékelés és tervezés q Van-e megfelelõ projekttervezési és értékelési funkció? q Ha nincs, milyen funkciókra kéne figyelmet fordítani és hogyan? q Elfogadhatóan történik-e a tervezés és a becslés? q Milyen célokat kellene ezen a területen kitûzni? q Ha a tervezés nem megfelelõ, milyen változtatásokra lenne szükség?

Ellenõrzés q Vannak-e megfelelõ ellenõrzõ rendszerek a projektek lefutása terén, a dokumentumok terén, a verziókezelés terén, a módosításkezelés terén?

q Ha nem, melyek a gyengeségek és milyen célokat és feladatkitûzésekre lenne szükség?

Módszerek q Hatékonyan kerülnek-e a modern módszerek felhasználásra a CASE eszközök,

MTA Információtechnológiai Alapítvány, 1993

4. generáció programnyelvek, kódgeneráló eszközök, fejlesztési módszerek, fejlesztéstámogató eszközök, tesztelést elõsegítõ eszközök, külsõ tanácsadás, stratégiatervezés területén?

q A fejlesztésre költött kiadások elegendõek-e? Esetleg túl nagyok-e? q Mik a hiányosságok területei, és milyen változtatásokra lenne szükség? q Milyen célokat és feladatokat kellene meghatározni?

Adatirányítás (data management) q Van-e elfogadható adatirányítási koncepció? q Az adatok katalogizálásának és elemzésének módja megfelelõ szintû-e? q Van-e jelentékeny redundancia és rendezetlenség az adatok tekintetében? q Termelékeny és hatékony-e az adatbáziskezelõ eszközök jelenlegi használata? q Megkisérelték-e az adatoknak az egyes rendszerhatárokon túllépõ, egységes kezelését?

q Az adatok együttes kezelését célzó koncepció nem akadályozza-e meg a gyors és hatékony fejlesztéseket?

q Azonosítsuk a a gyenge pontokat, és javasoljunk kitûzendõ célokat és feladatokat!

Hardver és szoftver q Úgy tûnik-e, hogy elégséges a rendelkezésre álló hardver a feladatok megoldására? q Van kapacitásfölösleg? q Problémák származnak-e egy esetleges kevert hardver környezetbõl? q A PC-kel kapcsolatos koncepciók megfelelõek-e ? Kielégítik-e a felhasználók igényeit?

q A szervezet a lehetõ legjobban használja-e ki a rendelkezésre álló szoftver erõforrásokat?

q Milyen területek szorulnak jobbításra, és milyen cél- és feladatkitûzésre lenne szükség?

Technika személyzet q Rendelkezésre áll-e megfelelõ nagyságú személyzet? q Megfelelõ-e a személyzeten belül a technikai tudás keveréke? q Kielégítõ-e a személyzet képzettsége? q A technikai személyzet segítõkész-e a felhasználók problémáinak megoldásában?

Bevezetés

75

q Milyen területek szorulnak jobbításra, és milyen cél- és feladatkitûzésre lenne szükség?

Oktatás q Kellõ fontosságot kap-e az oktatás? q Helyesen van-e az oktatás megszervezve (jók-e az oktatási témák)? q Kielégítõ-e az oktatás? q Milyene területeken kéne javítani? q Tûzzünk ki célokat és feladatokat ezen a területen!

Minõségirányítás (quality management) q Van-e informatikai minõségirányítási program? q A felhasználói követelmények hitelesítése eléggé elõ van-e készítve? q Vannak-e mechanizmusok a fejlesztés elötti kiértékelésére a rendszerek felhasználói felületére, kiterjeszthetõségére, performanciájára, karbantarthatóságára, dokumentáltságára, összekapcsolására vonatkozóan?

q Vannak-e megfelelõ tesztelési és verifikálási módszerek? q Megbízhatóak-e a leszállított rendszerek? q Úgy mûködnek-e, ahogy azt a felhasználók elvárták? q Milyen célokat és feladatok szükségesek ezen a területen?

Az eredmények egyeztetése Kulcscélok és kulcsfeladatok készítése Amikor a vezetõi interjúk lezajlottak, a Munkacsoport minden egyes területen egyezteti, összehasonlítja az eredményeket. Az a cél, hogy az egyedi célok és feladatkitûzések számát redukáljuk minden egyes területen és egy optimalizált cél- és feladathalmazhoz jussunk el. Amikor ezek a halmazok elõálltak, akkor egy végsõ optimalizálást hajtunk végre, melynek során a kulcscélokat és feladatokat projektszinten (a projekt kiterjedésében) egyeztetjük.

MTA Információtechnológiai Alapítvány, 1993

CÉLOK ÉS

CÉLOK ÉS

CÉLOK ÉS

FELADATKITÛZÉSEK

FELADATKITÛZÉSEK

FELADATKITÛZÉSEK

OPTIMALIZÁLT HALMAZOK AZ EGYES MÛKÖDÉSI TERÜLETEKRE

OPTIMALIZÁLT HALMAZ

OPTIMALIZÁLT HALMAZ

OPTIMALIZÁLT HALMAZ

KULCSHALMAZ ELKÉSZÍTÉSE

KULCSCÉLOK ÉS KULCSFELADATOK

Nehéz részletes elõírásokat adni arról, hogy hogyan kell ezt az optimalizálási folyamatot végrehajtani. A célunk tehát az egyedi céloknak és feladatkitûzéseknek egyetlen kezelhetõ halmazba történõ csoportosítása. Sokfajta optimalizálás történhet ennek során.

q Több egyedi cél egyetlen kulcscéllá olvad össze. Az eredeti célokhoz kapcsolódó

feladatkitûzéseket szintén összevonjuk, vagy, néha, külön feladatokként kapcsoljuk a kulcscélhoz.

q Sok cél lényegében azonos lehet, ilyenkor a feleslegeseket töröljük. A kitörölt

célokhoz kapcsolódó feladatkitûzéseket azonban körültekintõen felül kell vizsgálni. Ezeket vagy szintén törölni lehet, vagy be lehet olvasztani a visszamaradó feladathalmazba. Elképzelhetõ ugyanis, hogy habár a célok lényegében azonosak, a megfelelõ feladatkitûzések eltérnek egymástól.

q A szemlék felfedhetnek további ellentéteket, melyeket az interjúk során nem vettünk észre. Ezeket az interjúalanyokkal történõ további megbeszélésekkel lehet feloldani, ha ez szükségesnek tûnik.

q Néha elõfordul, hogy a '2. fordulós' célokat minden interjúalany elutasítja. A mûködési terület reprezentánsával történõ megbeszélés után ezeket a célokat vagy elejtjük, vagy a kialakult helyzetre utaló megjegyzéssel a Zsûri elé terjesztjük.

q Bizonyos esetekben a célok nem kapcsolódnak az informatikához, és nem lehet hozzájuk informatikai feladatkitûzést készíteni. Ilyen esetben a Munkacsoport újra áttekinti ezeket, és ha továbbra sem lelhetõ fel informatikai vonatkozás, akkor továbbadhatja õket a szervezetfejlesztési mechanizmusnak, de mindenesetre kihagyja õket a kulcscélok halmazából.

Amikor a kulcscélok és kulcsfeladatok halmaza elkészült, akkor ezt szemlére kell bocsátani. A szemlén Munkacsoport és a Területi reprezentánsok vesznek részt. A szemle után végsõ simításokat lehet a terven végezni, még mielött a Zsûri elé kerülne véleményezésre.

Bevezetés

77

A kulcscélok és kulcsfeladatok szemléje A kulcscélokat és a kulcsfeladatokat a Zsûrinek szemléznie kell. Ha nagy mennyiségû az áttekintendõ anyag, akkor a szemlét több ülés során, részenként kell lebonyolítani. Mint arra már korábban kitértünk, a szemlék során az értekezletek lebonyolításakor használt szokványos technikákat kell alkalmazni. Egy határozott fellépésû vitavezetõnek (elnöknek) kell irányítania a szemlét. A szemle hatékonyságának fokozása érdekében több szerepet kell betölteni az értekezlet során:

q vitavezetõ (már említésre került), q két

jegyzõkönyvvezetõ, tevékenységeket jegyzik jegyzõkönyvezetõket !),

akik a szemle eredményeképpen le (csak a vitavezetõ utasíthatja

elvégzendõ bármire a

q minden mûködési területre egy Munkacsoportbeli képviselõ, q olyan valaki, aki mélyrehatóan ismeri a szervezeti terveket, és könnyen eligazodik bennük, és ha szükséges, vissza tud keresni belõlük adatokat,

q a kritikus sikertényezõket jól ismerõ személy, aki tudja azt is, hogy milyen módon származtatták ezeket.

A szemle eredménye az elvégzendõ feladatok listája lesz, valamint változtatások a kulcscélokon és kulcsfeladatokon. Ha az elvégzendõ feladatok listája nagy, akkor elképzelhetõ, hogy még egy szemlére lesz szükség. Az elsõ szemle alkalmával eldöntendõ az, hogy szükséges-e még egy szemle lefolytatása. Figyelmet kell arra fordítani, hogy a Zsûri a lehetõségekhez képest minél kevesebbet ülésezzen, mert résztvevõi általában elfoglalt emberek. Ha nem sikerül a szemléket idõben lefolytatni, az a stratégiatervezési projekt idõbeli elcsúszásához vezethet.

Informatikai irányítási stratégia Közös feladatkitûzõ megbeszélések A közös feladatkitûzõ ülésekhez kapcsolódó fõbb feladatokat már áttekintettük, de ebben a részben hasznos lehet ennek átismétlése.

q A kulcscélok és kulcsfeladat-kitûzések figyelembevételével a Munkacsoport módosítja a jelenlegi rendszerekrõl gyûjtött adatokat.

q A Munkacsoport megfogalmazza a követendõ informatikai irányítási stratégiát, illetve annak bevezetését szolgáló célokat és feladatkitûzéseket.

q A vezetõség kiválasztott körével közös feladatkitûzõ megbeszéléseket folytatnak le, ahol a Munkacsoport által ajánlott stratégiák szemlézésre kerülnek. A szemle során véglegesen eldöntésre kerül az alkalmazandó stratégia, és kialakítják a célokat és feladatkitûzéseket.

q A Munkacsoport összeveti az eredményeket, majd a vezetõi célkitûzéseket és feladatkitûzéseket optimalizálja. Ennek eredménye egy kulcshalmaz lesz.

q A kulcshalmaz a Zsûri elé kerül szemlére. A szemle megállapításai szerinti módosításokat végre kell hajtani. A közös feladatkitûzõ megbeszélések célja a mûködési területeken alkalmazandó informatikai irányítási stratégia bevezetéséhez kapcsolódó célok és feladatok megfogalmazása. Ebben a szövegkörnyezetben az informatikai irányítási stratégia úgy értelmezhetõ, mint az informatikai szolgáltatások nyújtásának mikéntje a szervezet számára. MTA Információtechnológiai Alapítvány, 1993

Informatikai irányítási stratégiák Az elõzõ fejezetben ismertetésre került a Gregory Parsons-tól származó hat informatikai irányítási stratégia, melyeket egy szervezet alkalmazhat. A stratégia itt azt az utat jelenti, ahogy a szervezet felhasználja erõforrásait a szervezeti célkitûzések informatikával történõ elérése során. A hat stratégia az alábbi:

q központilag tervezett, q élenjáró, q szabad piac, q monopólium, q erõforráshiány, q szükséges rossz. A stratégiák részletesen kifejtésre kerültek a harmadik fejezetben. Parsons szerint az egyes stratégiák bizonyos rendszerkategóriáknak felelnek meg a legjobban. Egy szervezetnek azt stratégiát kell egy mûködési területen tudatosan alkalmaznia, mely megfelel az ott levõ rendszer típusának. Az elõzõ lépés során meghatároztuk azt a stratégiát, mely a legközelebb áll a szervezet jelenlegi gyakorlatához. Most pedig az Informatikai szóvivõ segítségével a Munkacsoport minden egyes mûködési területre ajánlani fog egy alkalmas informatikai irányítási stratégiát. Az irányítási stratégia kiválasztása elött a Munkacsoportnak meg kell vizsgálnia az eddig elkészített kulcsfeladat-kitûzéseket és ha szükséges, módosítania kell a jelenlegi és tervezett rendszerekrõl gyûjtött adatokat. A feladatkitûzések maguk után vonhatják a már összegyûjtött adatoknak több szempontból is a módosítását, úgymint:

q Szükséges

lehet további rendszerekrõl adatokkal kiegészíteni a meglevõ információkat. Ezek a rendszerek feladatkitûzésekben kerültek meghatározásra, de nem szerepeltek a jelenlegi rendszerek kiinduló értékelésében.

q Ezekre az új rendszerekre vonatkozó kategorizálásokat, illetve a mûködési területekre

és tevékenységekre vonatkozó kereszthivatkozásokat el kell készíteni, azaz rendszerkategóriába kell õket sorolni, meg kell határozni a támogatott rendszerre ható erõket és a támogatási kategóriákat.

q Lehetséges, hogy ez maga után vonja némely jelenlegi rendszer kategóriájának megváltozását, például egy rendszer a Termelõ kategóriából átkerülhet a Stratégiai kategóriába, ha egy javasolt feladatkitûzést figyelemve veszünk. Megváltozhatnak a támogatott rendszerre ható erõk és a támogatási kategóriák, és módosulhatnak a rendszer által támogatott tevékenységek és mûködési területek köre is.

Ajánlott stratégiák A mûködési területek ismerete, valamint az '1. fordulós' interjúknak az informatikai módszereire vonatkozó kérdések alapján a Munkacsoportnak ajánlásokat kell készítenie az alkalmazandó informatikai irányítási stratégiára minden egyes mûködési területen. Az ajánlásokon kívül, a Munkacsoportnak javaslatot kell tennie azokra a célokra és feladatokra, melyek teljesítésével az ajánlott stratégia bevezethetõ. Ezek bemutatásra kerülnek a '2. fordulós' interjúk során. Az informatikai irányítási stratégiák közötti választás elvei és indoklása a harmadik fejezetben került ismertetésre. Az alábbiakban ennek összefoglalása található.

Bevezetés

Rendszerkategória

Informatikai irányítási stratégia

79

NAGYREMÉNYÛ

STRATÉGIAI

ÉLENJÁRÓ SZABAD PIAC

KÖZPONTILAG TERVEZETT

KÖZPONTILAG TERVEZETT

ERÕFORRÁSHIÁNY

SZABAD PIAC SZÜKSÉGES ROSSZ

FENNTARTÓ

ÉLENJÁRÓ

MONOPÓLIUM

ERÕFORRÁSHIÁNY

TERMELÕ

Az egyes informatikai irányítási stratégiák bevezetéséhez kapcsolódó szokásos feladatkitûzéseket fogunk a továbbiakban ismertetni.

Kapcsolódó feladatkitûzések Központilag tervezett: q Nevezzünk ki egy informatikai tervezéssel foglalkozó személyt a szervezeten belül, elég magas szinten a hierarchiában. Nagy szervezetek esetében ez csoport is lehet.

q Állítsunk fel egy informatikai tervezési és ellenõrzési mechanizmust, melynek során a szervezeti célkitûzésekeket informatikai tervekké fordítják le, felkészülnek a szervezeti tervekben beálló változásokra, elõterjesztik az informatikai terveket szemlére és jóváhagyásra, meggyõzõdnek arról, hogy az informatikai szervezet végrehajtja a tervben foglaltakat. q Állítsunk fel egy projektértékelési mechanizmust. q Bizonyosodjunk meg arról, hogy minden érintett érti a központi tervezés szerepét.

Élenjáró q Bizonyosodjunk meg arról, hogy a vezetés hisz a technológia alkalmazásában. (Ez

rendszerint csak ott lehetséges, ahol a szervezeten belül már sikerült elérni nagyobb sikert az informatika alkalmazásával.) q Mérjük fel, hogy milyen tudást kell megszerezni. q Értékeljük a szervezeten belül rendelkezésre álló tudást, és/vagy toborozzunk

embereket. q Állítsunk fel egy K+F csoportot, nem túl szoros ellenõrzéssel. q Biztosítsunk

megfelelõ K+F jellegû költségvetést, melynek egy része akár veszteségképpen is leírható (mint egy igazi K+F környezetben).

MTA Információtechnológiai Alapítvány, 1993

Szabad piac q Biztosítsunk tanácsadó szolgáltatást a felhasználók számára, hogy szakértõk

véleményét ki tudják kérni a lehetséges alkalmazások, korlátok és az elérhetõ informatikai eszközkészlet területén. q Biztosítsuk, hogy az informatikai költségvetés jelentékeny része felett a mûködési

terület maga rendelkezzen. q Állítsunk össze oktatást a felhasználók számára. q Állítsunk fel egy döntõbizottságot azzal a céllal, hogy a képzetlen felhasználók

helytelen döntéseit kiszûrhessük. q Vizsgáljuk meg annak lehetõségét, hogy a szervezet informatikai funkcióit ellátó

egység a szervezeten kivülre is dolgozhasson.

Monopólium q Tekintsük át a kulcsfeladatokat, valamint a jelenlegi karbantartási munkákat, és

becsüljük meg a szükséges erõforrások nagyságát. q Döntsük el, hogy a költségvetés nagysága kellõképpen indokolt-e. q Állítsunk fel egy mechanizmust, mely fogadja és kielégíti a felhasználói igényeket.

Erõforráshiányos q Tudatosítsuk a felhasználókban a választott stratégiát. q Vizsgáljuk át az eddig elkészített feladatkitûzéseket, és készítsünk költségvetést. q Hozzunk létre olyan döntési mechanizmust, amely rangsorolja a projekteket.

Szükséges rossz q Tudatosítsuk a felhasználókban a választott stratégiát. q Hozzunk létre olyan döntési mechanizmust, amely rangsorolja a projekteket. q Ha a szükséges rossz stratégiát választottuk az összes mûködési területen, akkor

vizsgáljuk meg, hogy miért volt szükség stratégiai tervezésre, és vegyük fontolóra a stratégiatervezési projekt leállítását.

Közös feladatkitûzõ megbeszélések A jövõbeli informatikai irányítási stratégiák megállapítását célzó közös feladatkitûzõ megbeszéléseket olyan csoportmegbeszélés formájában kell végrehajtani, ahol résztvesz az összes Informatikai szóvivõ, rangidõs számítástechnikai szakemberek és az informatikai igazgató. Ez a megközelítés akkor ajánlott, ha csoport nem túl nagy (8-10 személy). Ha a résztvevõk száma nagyobb lenne, akkor egynél több ülésre lehet szükség. A megbeszélés célja q az eddig elkészített feladatkitûzések áttekintése, különösen azoké, melyek az

informatikában alkalmazott módszerekre vonatkoznak, q az ajánlott informatikai irányítási stratégia, célok és feladatkitûzések véleményezése, q az egyes mûködési területeken alkalmazandó informatikai irányítási stratégia

meghatározása, q a célok és feladatkitûzések egy halmazának a kialakítása annak érdekében, hogy a

Bevezetés

81

választott stratégia bevezetésre kerüljön. (Ezek megfogalmazásában segíthet az elõbbiekben ismertett szokásos feladatkitûzések listája.) A Munkacsoport ezután összegyûjti az eredményeket, egy kulcshalmazt választ ki és a Zsûri elé terjeszti elfogadtatásra. A folyamat végén a kulcsfeladat-kitûzéseknek egy második, a Zsûri által elfogadott halmaza áll elõ. Ezek kapcsolódni fognak a megfelelõ informatikai irányítási stratégia bevezetéséhez. A vezetõi interjúk sorozata és a közös feladatkitûzõ megbeszélés után eljutottunk a kulcsfeladat-kitûzések egy halmazáshoz. Ez szolgál majd a kiinduló informatikai stratégiai terv elkészítésekor bemenõ adatként.

Elõírt termékek Az irányelvekben felsorolt jelentések közül a "Célkitûzések és súlyponti kérdések" c. dokumentum megfeleltethetõ a szervezet-mûködési tervnek, vagy egy kivonatának. Ha ilyen nem áll rendelkezésre, akkor e jelentés a KST-k alapján készíthetõ el, ha azok sincsenek, akkor a célok kialakítása során figyelembe vett feltételezéseket kell leírni. "A mûködési környezet leírása" dokumentum bõvíthetõ a szervezeti-mûködési tervbõl származtatott esetleges változtatási tervekkel. Hozzájárulhat még e jelentéshez a SCOPE-elemzés némely megállapítása is. "A jelenlegi rendszerek" c. jelentés a tervezett rendszerek leírásával most már kiegészíthetõ, de véglegesítésre csak az adattervezés befejezte után kerül, mert lehet, hogy újabb feladatkitûzéseket kell figyelembe venni. A "Lehetséges alkalmazások" jelentésben alatt az összes megfogalmazott informatikai feladatkitûzés szerepeltetendõ. A feladatkitûzésekbõl származtatott rendszerek értékelését (kategória, támogatott erõk, támogatási kategóriák) is fel kell használni. A kulcscélok és -feladatok leírását tartalmazza az "Alternatívák információs rendszerekre" c. jelentés. A módszer nem kéri ezek alternatívák formájában történõ megfogalmazását, de ez nyilván megtehetõ. Az alternatívák kialakításának elveit is rögzíteni kell. Ha túl sok alternatíva adódna, akkor ezeket forgatókönyvekbe (scenario) kell rendezni, melyek az egyik mindig a jelenlegi tervezési feltételezések szerint (a "status quo" szerint) épül fel. Az interjúk során az informatika használatára vonatkozó kérdésekre adott válaszok, a feladatkitûzések és a választott informatikai irányítási stratégia alapján kezdhetõ meg az "Irányítási és mûszaki koncepciók" c. jelentés elkészítése. Ez a jelentés még véglegesítésre fog kerülni a késõbbiek során elkészítendõ projektspecifikációk alapján.

MTA Információtechnológiai Alapítvány, 1993

5 A kinduló terv elkészítése Bevezetés Az elõzõ lépésben összeállítottuk a kulcsfeladatok egy halmazát. Ebben a lépésben átalakítjuk õket egy olyan formába, mely a stratégiai terv alapját képezi. Ezt a feladatkítûzések további kiegészítésével érjük el, ami magába foglalja:

q fejlesztési projektek esetében a kritikus igények és lehetséges megoldásaik rögzítését,

q költség/haszon elemzési adatok elõállítását, q a projektek pénzügyi értékelését, q az érintett mûködési területekkel történõ kereszthívatkozás elkészítését, q az érintett

jelenlegi

és

jövõbeli

rendszerekkel

történõ

kereszthívatkozások

elkészítését.

Általában egy kulcsfeladatot egy projektspecifikációvá alakítunk át. Elõfordulhat azonban, hogy kívánatos a feladatok összevonása vagy felbontása:

Bevezetés

83

q egy konkrét rendszerre vagy szervezeti változásra vonatkozó, több feladatkitûzés összevonható egyetlen projektspecifikációba,

q azok a bonyolult feladatkitûzések, melyek tevékenységei várhatólag idõben elhúzódnak, több projektspecifikációra is felbonthatók.

Projektspecifikációk A projektspecifikációk azoknak az informatikai projektek a 'mini' leírását jelentik, melyeket a stratégiai terv eredményeképpen végre fogunk hajtani. Hatféle projektspecifikációt különböztetünk meg:

q fejlesztési projektek (új vagy meglevõ rendszerek módosítása) q megvalósíthatósági tanulmányok, q mûszaki értékelések, q technológia bevezetés, q szervezeti változások, q módszer, szabvány és koncepció bevezetése. Kezdetben minden specifikáció tartalmaz egy javasolt prioritási kódot, mely a hozzátartozó legmagasabb prioritású feladatkitûzésbõl származik. Ezeket a prioritási értékeket használjuk eleinte a projektek sorrendjének kialakításakor. A rangsorolási folyamatról a késõbbiekben lesz szó. Amikor a projektspecifikációk elkészültek és rangsorolásra kerültek, akkor a Zsûri elé kerülnek szemlére. A szemle eredményeképpen:

q hozzá lehet adni és/vagy el lehet törölni projektspecifikációkat, q módosítani lehet tartalmukat, q módosítani lehet a rangsort. A projektspecifikációk tartalma és és rangsora egy újabb szemlére kerül majd a stratégiatervezés utolsó szakaszában.

Projektspecifikációban szereplõ adatok A projektspecifikációk formája legyen egységes minden projektspecifikációban számos adatot kell feltüntetni, úgymint:

q a projekt megnevezését, q leírását, q célkitûzéseit, q rangsorban elfoglalt helyét, q hogy melyik fázisban valósul meg, q az igényelt erõforrásokat, q a ráfordítandó idõt, q költség- és haszonelemzési adatokat (a megtérülési értéket), q kockázatelemzési adatokat, q felhasználókra és a szervezetre gyakorolt hatásokat, q kritikus igényeket, MTA Információtechnológiai Alapítvány, 1993

projektre

!

Egy

q a támogatott célokat és kritikus sikertényezõket q számbajövõ problémákat. A szükséges idõtartamról és pénzügyi fedezetrõl egyelõre csak nagyvonalú becslést kell adni. Ebben a szakaszban ezek még nem feltétlenül pontos értékek, a projekt nagyságrendjének a körülhatárolását segítik.

Kritikus igények A rendszerfejlesztés kezdeti szakaszaiban gyakran sok munkát fordítanak a rendszerkövetelmények felmérésére. Ennek a folyamatnak jó kiindulási alapot lehet biztosítani azzal, hogy már a stratégiai tervezés alatt a kritikus igények a projektspecifikáció részeként rögzítésre kerülnek. Fontos, hogy amikor fejlesztési projekteknél a felmerülõ kritikus igények vizsgálatakor

q figyelembe kell venni a felhasználó igényeinek fontosságát, azaz mennyire fontos egy igény a mûködés szempontjából,

q értékelni kell minden igény valóságosságát, azaz egy igény kielégítése milyen következményekkel jár a mûködésre? Mennyire értékesek a lehetséges javulások?

q Fel kell ismerni, hogy az igények súlya és fontossága különbözõ. Gyakran esnek abba a hibába, hogy úgy vélik: öt felhasználói igénybõl négyet megvalósító rendszer automatikusan jobb egy olyan megoldással szemben, ahol csak két igényt elégítenek ki az ötbõl. Ha van egy meghatározó az öt igény között, akkor az a jobb megoldás, mely lefedi ezt a meghatározó igényt. A feladatkitûzések figyelembevételével minden egyes projektspecifikációhoz össze kell gyûjteni a kritikus igényeket. Ahol értelmes, ott az igények kielégítésének elképzelhetõ módjait is körvonalazni lehet. Minden igényt rangsorolni kell az alábbi skála alapján: 1 = feltétlenül szükséges. 2 = nélküle a projekt értékelése, fontossága megváltozna. 3 = kulcsfontosságú, elhagyása a felhasználókkal történõ konzultációt igényelne. 4 = hasznos, de nem életbevágó. 5 = jó, ha van. Körültekintést és figyelmet igényel a kritikus igények meghatározása, mert a rendszerelemzés elkezdésekor fontos bemenõ adatok lehetnek.

Költség/haszon elemzés Jelenértékszámítás A célok és feladatkitûzések összegyûjtésekor, egy, a felhasználóktól származó szubjektív rangsor már feljegyzésre került. Egyes szervezetekben ez megfelelõ lehet a végleges rangsor felállításához, más esetekben szükséges lehet valamilyen megtérülési számításokon alapuló rangsorolási technika alkalmazása. Az alábbiakban ismertetjük a projekt jelenérték-számítási technikát (Net Present Value per Capita). A technika figyelembe veszi a projekt 'diszkontált' (diszkont kamatlábbal módosított) értékét a hasznosulás évei (vagy a rendszer) élete alatt. Ezek után egy projektmegtérülési mutatót számít ki a a projekt jelenértékének a fejlesztésre fordított emberévekkel történõ elosztása által. Ez a megközelítés elõnyben részesíti azokat a fejlesztéseket, amelyek idõben rövid lefutásúak. A következõ oldalon található kalkulációs

Bevezetés

85

formalap lehetõvé teszi a számítások egyszerû elvégzését.

Hasznok A hasznokat négy címszó alá kell besorolni:

q Kézzelfogható haszon: a tényleges realizálható bevétel. q Költségmegtakarítás: olyan költségek, melyek akkor merülnének fel, ha a projekt nem valósul meg.

q Csökkentett mûködési költségek: a jelenlegi, kiváltandó rendszer üzemeltetésébõl származó költségek.

q Nem kézzelfogható elõnyök: opcionális mezõ. Az olyan megfoghatatlan elõnyök számára van fenntartva, mint pl. 'jobb személyzeti morál', mely önmagában nehezen fejezhetõ ki költség formájában. Dönthetünk azonban úgy, hogy ennek ellenére számszerûsítjük, pl. tegyük fel: a jelenlegi személyzet változási aránya 20% évente, ami évente 4 fõ toborzását jelenti. Ha az új rendszer ezt 10%-ra csökkentené, akkor évente csak két új ember kellene. Ha kiképzési, betanítási költségek 100.000 Ft-ra rúgnak személyenként, akkor nem kézzelfogható elõny címszó alatt 200.000 Ft tüntethetõ fel. PROJEKTÉRTÉKELÕ FORMALAP Projektspecifikáció azonosítója: Mûködési terület: Rendszer:

Idõpont:

KATEGÓRIA

HASZON (ÉVRE)

DISZKONT %

HASZNOS ÉVEK

HASZNOK Kézzelfogható haszon Költségmegtakarítás Csökkentett mûködési költségek Nem kézzelfogható elõnyök ELÕNYÖK ÖSSZESEN

A

SÚLYOZÓ TÉNYEZÕK Jövõérték Stratégiai fontosság Szociális tényezõ SÚLYOZÓ TÉNYEZÕK ÖSSZESEN HASZNOK/SÚLYOK ÖSSZESEN

B A+B=C

KÖLTSÉGEK Fejlesztési költség Hardver/szoftver költség Folyó költség Egyéb költség ÖSSZES KÖLTSÉGEK

D

KOCKÁZATI ÉRTÉK

E

MTA Információtechnológiai Alapítvány, 1993

JELENÉRTÉK 100.000 Ft-ban

KÖLTSÉGEK ÉS KOCKÁZATOK ÖSSZESEN

D+E=F

PROJEKT JELENÉRTÉKE

C-F=G

FEJLESZTÉSI ÉVEK SZÁMA ÉVEKRE KIFEJEZETT PROJEKT JELENÉRTÉK

H G/H=I

Súlyozó tényezõk Egyes esetekben szükséges lehet az elõnyõket további tényezõkkel kiegészíteni. Három kategória kerül ismertetésre:

q Jövõérték: elsõsorban megvalósíthatósági tanulmányok esetében alkalmazható, ahol a tanulmányból közvetlenül nem sok haszon származik, de a majdani megvalósításból származó elõnyök számottevõek lehetnek.

q Stratégiai fontosság: olyan opcionális kategória, ami lehetõvé teszi a stratégiailag fontos projektek elõnyben részesítését.

q Szociális tényezõ: közszolgálatban elõfordulhat, hogy a szociális vagy politikai nyomást ezen a tényezõn keresztül lehet érvényesíteni. Az egyes tényezõkhöz/címszavakhoz tartozó értékek meghatározását az alábbi formulákkal végezhetjük el.

q Éves haszon pénzben kifejezve: teljes évre számított haszon Ft-ban. q Diszkont kamatláb: a rendszer élete során használandó százalékérték. q Hasznosulási idõ: azon évek száma, melyekre hasznot számolnak. q Jelenérték 100.000 Ft-ban: a jelenértéket egy skálázási faktorral osztjuk. Tegyük fel, hogy az elsõ évben a kézzelfogható elõnyök értéke 200.000 Ft. 15%-os diszkont kamatlábat választunk, és öt évig fog a rendszer üzemelni. Akkor

q Éves haszon: 200.000 Ft q Diszkont kamatláb: 15% q Hasznosulási idõ: 5 év q Jelenérték : 200.000 * [(1/0.15) * (1-(1/(1+0.15))**5)] = 670.430 q Skálázott érték: 6.7 (a "*" a szorzás, a "**" a hatványozás, a "/" az osztás jele.)

Költségek A költségeket három alaptípusba soroljuk:

q fejlesztési, q hardver/szoftver, q folyó költségek. A bemutatott formalap természetesen csak példaként tekintendõ. Minden szervezetnek magának kell kialakítania az ott elfogadott értékelési módot. Ha egzakt, objektív mérõszámokat nem lehet kialakítani, akkor szövegesen kell egyfajta költség-

Bevezetés

87

haszonelemzést a projektspecifikációhoz csatolni.

Kockázatelemzés Számos projekt esetében fontos az, hogy a fellépõ kockázatokat valamilyen módon értékeljük. A kockázatok számszerûsítése nehéz feladat, a bemutatásra kerülõ kockázatelemzési formalap szempontokat ad arra nézve, hogyan lehetne egy ilyen elemzést végrehajtani. Az elemzés eredménye opcionális (költségnövelõ) tényezõként szerepel a projekt jelenértékét kalkuláló formalapon. A kockázatelemzõ formalap tartalmazza azokat a fõbb tényezõket, melyeket figyelembe lehet venni a kockázatelemzés során. A kockázati egységek meghatározása példaként kezelendõ. KOCKÁZATELEMZÉSI FORMALAP Projektspecifikáció azonosítója: Mûködési terület: Rendszer:

Idõpont:

KATEGÓRIA

ÉRTÉK

FORMULA

A

Projekt költség

2 per 100.000 Ft-ként

B

Fejlesztési idõ (emberévekben)

1 emberévenként

C

Fejlesztési idõ (években, összes)

emberévek/évek

D

Felhasználó egységek száma

D értéke

E

Szerzõdõ felek száma

E értéke

F

Telepítési helyek száma

F/2 értéke

G

Képernyõk száma

H

Új a technológia a szervezet számára ?

I vagy N

I = A értéke, N = 0

I

A felhasználók tapasztaltak ?

I vagy N

I = 0, N = A/5 értéke

J

Ismert funkcióról van szó ?

I vagy N

I = 0, N = A/5 értéke

K

Új-e a fejlesztési módszer ?

I vagy N

I = A/5 értéke, N = 0

L

Milyen a funkció (egyszerû, közepes, bonyolult) ?

E, K, B

K = A/2, K = A/5, E= 0

M

KOCK. EGYSÉG

G értéke

ÖSSZESEN (A-tól L-ig) KOCKÁZATI ÉRTÉK

M/2 értéke

A fenti formalap ismét csak példaként tekintendõ. Minden szervezetnek magának kell kialakítania egy kockázatértékelési módot. Hasonlóan a költség-haszon elemzéshez, ha egy ilyen számítás nem végezhetõ el, akkor ezt szövegben kell megtenni.

Projektértékelés A projekt végsõ, számszerûsített 'megtérülési értékét' úgy kapjuk, hogy a hasznok és súlyozó tényezõk összegébõl kivonjuk a költségek és a kockázati érték összegét, majd a kapott értéket elosztjuk a projektre számított emberévek számával. (Az összegek MTA Információtechnológiai Alapítvány, 1993

számításánál persze mindig a skálázott értékeket használjuk fel.) Minél nagyobb ez az érték, annál elõbbre kerül a rangsorban az egyéb tényezõk szempontjából azonos projektek között.

A kiinduló stratégiai terv véglegesítése Amennyiben a feladatkitûzéseket átalakítottuk projektspecifikációkká, valamint a költség/haszon- és kockázatelemzés eredménye is rögzítésre került, akkor a Zsûrit összehívják azért, hogy áttekintse a rangsorba rendezett specifikációkat. A szemle megállapításaitól függõen a munkacsoport további tisztázó munkálatokat végezhet és/vagy újra felállíthatja a rangsort. Sok esetben a Zsûri a projektspecifikációk olyan ismételt rangsorba rendezését kéri, mely szubjektív szempontokat vesz figyelembe. Ez természetesen megoldható a megfelelõ súlyozási vagy szociális tényezõknek a növelésével vagy csökkentésével. Ha már sikerült a rangsorolás tekintetében egyezségre jutni, a Zsûri úgy dönthet, hogy a projekteket fázisokba sorolja. A szokásos megközelítés a fázisba sorolásnál az idõbeni bontás, azaz azok projektek kerülnek az elsõ fázisba, melyek a következõ hat hónap során indulnak el, a rákövetkezõ hat hónapon belül indulók a második fázisba, és így tovább.

Projektspecifikációk

Fázisok

1-6 hónap

7-12 hónap

13-18 hónap

Ezek a fázisok szolgálnak majd alapul a stratégiai adattervezésben az átmeneti adatmodellek elkészítéséhez. A vázlatos informatikai stratégiai terv kialakítása végén elõáll a jövõbeli informatikai projektek specifikációi a Munkacsoport, az interjúalanyok, a Zsûri és a Területi reprezentánsok számára. Ezeket a specifikációkat rangsorolták, a vezetés áttekintette õket, valamint fejlesztési fázisokba sorolták õket. Természetesen ez még nem a végleges stratégiai terv, mert a stratégiai adattervezés kimenetele jelentõs mértékben befolyásolhatja a projektspecifikációkat, azok tartalmát és sorrendjüket.

Elõírt termékek Az irányelvekben felsorolt jelentések közül az "Alternatívák információs rendszerekre" c. jelentés eddig elkészített változatát bõvíteni kell a projektspecifikációknál megállapítottakkal (függõségek, pénzügyi tényezõk, mûszaki megszorítások, közös infrastruktúra stb.).

Bevezetés

89

A "Projektállomány" jelentésnek megfeleltethetõ a fázisokba rangsorolt projektspecifikációk halmaza. A projektspecifikációk hivatkozásokat tartalmaznak az általuk támogatott szervezeti célokra. A projektek között lehetnek információs rendszereket megvalósító projektek, infrastruktúrális projektek, tanulmánykészítési és szervezési projektek, ami egyszerûen megfeleltethetõ a módszer szerinti projektbontásnak (fejlesztési projektek, technológia bevezetés és módszer, szabvány és koncepció bevezetése, megvalósíthatósági tanulmányok és mûszaki értékelések, szervezeti változások). ."Az irányítási és áttérési tervek" c. jelentés elkészítése során különösen az áttérési tervek elkészítéséhez felhasználhatók a módszer, szabvány és koncepció bevezetés típusú, valamint a technológiabevezetési típusú projektspecifikációk. Az irányítási terv esetében a fázisok leírásából kell kiindulni. és ennek alapján lehet a stratégia megvalósulásához kapcsolódó kulcstevékenységeket, eseményeket, függõségeket és határidõket felmérni. A terveknél ne feledkezzünk meg azok (szabad szöveggel történõ) értelmezésérõl! Az "Irányítási és mûszaki koncepciók" c. jelentés tartalmát ki kell egészíteni a technológiabevezetési és szervezeti változás típusú projektspecifikációkban foglaltakkal. Ez a jelentés még bõvülni fog a módszer utolsó lépése során megfogalmazott koncepciókkal, melyek kidolgozásához nem volt szükség elkülönült projektre.

MTA Információtechnológiai Alapítvány, 1993

6 A stratégiai adattervezés áttekintése Bevezetés Ez a fejezet rövid áttekintést ad a stratégiai adattervezésérõl. A fejezet azok számára készült, akik áttekintõ ismereteket akarnak szerezni a tárgykörben a részletek tanulmányozása nélkül. A részletek iránt érdeklõdök számára az 'SSADM struktúrált rendszerelemzési és -tervezési módszer' c. kézikönyv tartalmaz részletekbe menõ ismertetéseket. Az adattervezési tevékenységeket három lépésben végezzük

Bevezetés

91

IDEÁLIS

JELENLEGI

ADATSZERKEZET ELEMZÉSE

ADATSZERKEZET ELEMZÉSE

ADATTERVEZÉS

Az adattervezés során grafikus technikákat fogunk felhasználni, melyek jelentéstartalma rögzített, de a jelöléstechnikájuk nem az. Olyan szervezeteknél, ahol szükséges lehet a stratégiai tervek egyeztetése, ott célszerû, ha a felhasznált jelöléstechnika azonos (ilyen a helyzet a minisztériumok és az alárendelt szervezeteik esetében). Ennek a célnak például jól megfelel az SSADM jelõléstechnikája. A grafikus technikák használatát nagyban segítheti egy alkalmas CASE (Computer Aided Software Engineering) eszköz felhasználása.

Ideális adatmodell elkészítése Elsõ lépés az adatok idealizált szerkezetének az elemzése. Ez a tevékenység a stratégiatervezési projekt terjedelmébe tartozó mûködési területek logikai adatmodelljeinek felállításával foglalkozik. Célja, hogy áttekintést adjon a szervezeti mûködéshez kapcsolódó adatszerkezetekrõl. A projekt késõbbi szakaszaiban a Munkacsoport azt fogja tanulmányozni, hogyan lehet ezeket az ideális adatszerkezeteket megvalósítani. Az ideális adatmodellek létrehozása nem jelent elkötelezettséget azok megvalósítására, hanem a javasolt változtatások minden egyes területére teljeskörû költség/haszon elemzést kell elkészíteni, ami majd segít annak eldöntésében, hogy az adott változtatást végrehajtsuk-e. Az egyed-kapcsolat (entity-relationship) modellezési, a relációs adatelemzési, és az adatcsoport (clustering) modellezési technikák használhatók az ideális adatmodell létrehozásánál. Az ideális adatmodell az egyed-kapcsolat modell egyfajta jelölésrendszerével készül el. Olyan helyeken, ahol az SSADM módszert alkalmazzák rendszerelemzési és -tervezési területen, kézenfekvõ az SSADM jelöléstechnikáját alkalmazni a logikai adatmodell elkészítésénél. A modell tartalmazza a szervezeti mûködés számára lényeges egyedeket (azokat a dolgokat, amikrõl a szervezet adatokat tárol), valamint az egyedek közötti egysok kapcsolatokat. Az alábbi ábra egy jellegzetes adatmodellt mutat.

MTA Információtechnológiai Alapítvány, 1993

Eladási Osztály Osztály Statisztikák

Raktár

Eladási Régió

Régió Statisztikák

Hónap

Földrajzi Zóna

Értékesítési Körzet Körzet

Vásárló Típus

Termék

Statisztikák Vásárló Diszkont Kód

Raktárkészlet Fizetés Átutalás

Számla

Megrendelés

DIszkont Ár

Fizetség Megrendeléssor

Különleges Ár

Havi termékstatisztikák

Mindegyik téglalalap egy egyedet jelöl. Mindegyik egyedet ki lehet egészíteni adatelemekkel, melyek kimondottan az adott egyednek a részei, habár a stratégiai adattervezésben általában nem megyünk le az egyedek sajátos adatelemeinek szintjére. Az elmondottak szemléltetéseképpen a "vásárló" egyedet ki lehetne egészíteni olyan adatelemekkel, mint: q vásárló azonosító, q vásárló neve, q vásárló címe, q értékesítési körzet azonosító, q vásárló típuskód, q földrajzi zóna azonosító, q kintlevõség, q hitelkorlát, q stb.

A vonalak a kapcsolatokat mutatják. A vásárló például közvetlen kapcsolódik a megrendelésekhez, egy vásárló típushoz, egy földrajzi zónához, egy értékesítési körzethez, egy diszkont kódhoz, a speciális árakhoz és a számlákhoz. A kapcsolatok egysok jellegûek, a "csirkelábak" az egytõl a sok felé mutatnak (a sok oldalon van a láb rész). Például egy vásárlónak sok megrendelése lehet, de csak egy értékesítési körzethez tartozhat. A példában az üzleti környezetre vonatkozó következõ információk a modellbõl származtathatóak.

Bevezetés

93

q Az árusítási szervezeti hierarchia osztályból, régióból és körzetbõl áll. Egy osztály

több régiót és egy régió több körzetet tartalmazhat. q Az értékesítési statisztikákat havonta aktualizálják valamennyi szintjén az értékesítési

hierarchiának. q Szintén havonta aktualizálják az értékesítési statisztikákat mindegyik vásárló egyedi

termékeinél. q Mindegyik vásárló csak egy értékesítési körzethez tartozik és egy vásárló típusba van

kategorizálva. Egy vásárlóhoz csak egy típus tartozik, de ugyanahhoz a típushoz több vásárló is tartozhat. q Mindegyik

vásárló csak egy földrajzi zónában van és mindegyik zónához kapcsolódhat több vásárló. Mindegyik zónába egy egyetlen raktárból szállítanak és bármelyik raktárhoz kapcsolódhat több zóna. Tehát mindegyik vásárlónak egy raktárból szállítanak a vásárló földrajzi zónája alapján.

q Egy vásárlónak több rendelése lehet, de egy rendelés csakis egy ügyfélhez

kapcsolódik. Mindegyik rendelésnek lehet több rendelési sora és mindegyik sorhoz egy termék kapcsolódik. Egy termék természetesen több rendelési sorban is szerepelhet. q Egy terméket több raktárban is tárolhatnak és egy raktárkészletében több termék van. q A mûveletekhez legalább két árazási mechanizmus létezik. Mindegyik vásárlónak van

egy diszkont kódja. Ez a diszkont kód a termékkel együtt azonosít egy egyedi diszkont árat. Ráadásul lehetséges, hogy egy vásárló egyedi árral rendelkezik minden termékre. q Mindegyik vásárlónak több számlája lehet, de egy számla csak egy vásárlóhoz

kapcsolódhat. Mindegyik számlához kapcsolódhat több rendelési sor. q A fizetéseket vagy átutalásokat több számlára lehet szétosztani és bármelyik számlán

szerepelhet több fizetés vagy átutalás. Mindegyik mûködési területhez egy ilyen adatmodellt hozunk létre. A modellek számától és méretétõl függõen belõlük egyetlen, összetett ideális adatmodell állítható össze, vagy külön ábrákon hagyható a végleges IDM . Több okból tekinthetõ ideálisnak a modell: q a jelenlegi adatmodellekbõl vagy megvalósításokból származó korlátokat nem

vesszük figyelembe, q részleges és teljes ismétlõdéseket (redundanciákat és duplikációkat) nem tartalmaz, q minden generikus mûködési kapcsolatot megmutat, q egy egységes szervezeti információs rendszer fejlesztésének alapjául szolgál.

Az ideális adatmodell létrehozása során az elemzõk részadatbázisokra (subjects) bontják az elkészítendõ modellt, tömörítik azt az adatcsoport-modellezés használatával, és tanulmányozzák az adatok elosztását az adatelosztási elemzés segítségével. Ezek a technikák a fejezet késõbbi részeiben kerülnek ismertetésre.

Fizikai adatmodell elkészítése A fizikai (jelenlegi) adatfelépítés modellezése a létezõ állományok feltérképezésének egy módja, amely nem pusztán az állomány-szerkezetek (file layout) visszatükrözése, hanem egy logikai, sematikus ábra elkészítése. A fizikai adatmodell megmutatja, hogy milyen egyedek vagy fõ rekord típusok léteznek, és hogyan kapcsolódnak egymáshoz a létezõ rendszerben. A változásra tervezés alapproblémája, hogy hacsak nem egy 'õsrobbanás' (teljes 'tabula MTA Információtechnológiai Alapítvány, 1993

rasa') jellegû fejlesztéssel állunk szemben, akkor a jelenlegi helyzet letisztult képével kell rendelkeznünk annak érdekében, hogy meg tudjuk tervezni a módosítások végrehajtását. Ebben a módszerben a fizikai adatmodellezési technikát használjuk a jelenlegi állapot modelljének leírására. Sok szervezetben az adatok jelenlegi szerkezetének ismerete meglehetõsen felületes és ködös. Ha nagy az esélye annak, hogy a jelenlegi rendszer fejlesztése közben nem használtak adatmodellezési technikát, akkor valószínûsíthetõ, hogy a stratégiatervezési projekt terjedelmébe esõ mûködési területeken zavaros állományok találhatók, melyek meglehetõsen redundánsak és többértelmûek. A legtöbb szervezet mégis lassanként eljut egy közel ideális célállapotba. Sok rendszer még évekig a helyén fog maradni, míg mások esetében a cél elérhetõ a szükséges, viszonylag kis módosítások révén. Adott tehát a probléma: hogyan kaphatjuk meg a létezõ, implementált adatok képét anélkül, hogy rengeteget költenénk a jelenlegi rendszer vizsgálatára? Ezt a problémát oldja meg a stratégiai adattervezésben a fizikai adatmodellezés (Physical Data Modeling). Több lényeges szempont került figyelembevételre a fizikai adatmodellezési technikában. q Ha viszonylag kézenfekvõ szabályokat és technikákat használunk, úgy az adatmodell

elkészítése meglehetõsen egyszerû. q A modell elkészítése nem igényel nagy beruházást és rövid idõ alatt végrehajtható. q A fizikai adatmodell (Physical Data Model - PDM) a jelenlegi adatszerkezetnek a

logikai leírását nyújtja. Így a munkacsoport tagjai az éppen használatos állománykezelõ és/vagy adatbáziskezelõ technikai részleteinek ismerete nélkül is tudnak modellezési tevékenységeket folytatni. q Az alkalmazott, gyakran eltérõ állománykezelõ és/vagy adatbáziskezelõ eszközöktõl

függetlenül, a PDM egységes logikai leírási módot használ az egyedek és a közöttük levõ adatkapcsolatok szemléltetésére. q A PDM kiemeli az adatredundanciákat illetve más, meglevõ rendszerekben rejlõ

problémákat. q A PDM kiindulási alapot képez egy lépcsõzetes adatfejlesztési terv elkészítéséhez,

mely a redundanciák eltüntetésére és egy egységes adatkörnyezet megteremtésére irányul. Az alábbi ábra egy jellegzetes PDM-et mutat, ami egy meglevõ rendszerbeli adatmegvalósítás alapján (data implementation) készült.

Bevezetés

95

O

O

Anyagtípus

Cikkszám

Osztály

Cikkleírás Beszállítói kód

Cikk

O

Listaár Dátum

Beszerzési rendelés

Készlet

Az alap modellezési szabályok ugyanazok, mint az ideális adatmodellezéséi, de mivel a PDM nem a letisztult, ideális állapotot írja le, a jelölésrendszer kissé bonyolultabb lehet. A projekt indításakor kell meghatározni, hogy pontosan milyen jelölésrendszert fogunk használni, mert lehetséges, hogy nem szükséges a teljes szimbólumkészletet kihasználni. Az egyedeket az ideális adatmodellben használt jelöléshez képest eltérõ módon kell megjeleníteni. Ez elérhetõ más síkidom, pl. ellipszis használatával a téglalap helyett, vagy megkülönböztetõ jelzéssel (betûkkel) ugyanazon a síkidomon, vagy az egyedek névkiosztásában alkalmazott névkonvencióval. Erre azért van szükség, hogy amikor az átmeneti adatmodelleket készítjük, lehetséges legyen az IDM-bõl és a PDM-bõl számazó részeknek az elkülönítése. Az egyedekhez kapcsolódó üres háromszög szimbólum azt jelöli, hogy a jelenlegi implementációban ezek az egyedek közvetlenül elérhetõek az elsõdleges kulcsukon keresztül. Amelyekhez nem tartozik ilyen jel, azok közvetlenül nem érhetõk el. A pontozott vonal olyan egy-sok, vagy másképpen 1:M kapcsolatot mutat, ahol csak a 'master' (egy) érhetõ el a részlet (sok) felõl, fordítva nem (ez tulajdonképpen a hierarchikus adatbáziskezelõknél elõfoduló megvalósításból adódó megszorítás szemléltetése). Eltekintve ezektõl a különbségektõl, a PDM ugyanúgy olvasható, mint az IDM. Hasonlóan az ideális adatmodellezésnél mondottakhoz, olyan helyeken, ahol az SSADM módszert alkalmazzák rendszerelemzési és -tervezési területen, kézenfekvõ az SSADM jelöléstechnikáját alkalmazni a fizikai adatmodell elkészítésénél. Egy-egy PDM készül a tanulmány terjedelmébe esõ valamennyi létezõ mûködési területhez. Ezeket össze lehet fogni egyetlen PDM-be vagy, ha a méretük miatt ez nem célszerû, kettõ vagy három modellbe, melyek együtt mutatják a teljes képet. Az adatcsoport-modellezés használatával a PDM kezelhetõ méretûvé zsugorítható.

Adattervezés Három fõ bemenete van az adattervezési lépésnek, mely hat lépésbõl áll.

MTA Információtechnológiai Alapítvány, 1993

PROJEKTSPECIFIKÁCIÓK

IDEÁLIS ADATMODELL

FIZIKAI ADATMODELL

ADATTERVEZÉS

Összehasonlító elemzés Elsõ lépés: az ideális adatmodellt egybe kell vetni a fizikai adatmodellel. A feladat az, hogy a két modell közötti különbségekben rejlõ problémákat azonosítsuk. A problémák a jelenlegi adatmodellben megbújó, egy sor lehetséges hiányossággal állnak kapcsolatban, mint például: q az adatszerkezet nem pontos, q ugyanaz az egyedtípus többször fordul elõ, és mindegyik csupán egy részét

tartalmazza az egyed valóságos adatainak, q egyedek és kapcsolataik teljes duplikációi lelhetõk fel, q a kapcsolatok pontatlanok vagy hiányznak, q a jelenlegi modell racionalizálható lenne (tömörebbé tehetõ), q több jelenlegi adatszerkezet összefogható egyetlen átfogó ideális adatszerkezetbe, q kifinomultabb modellezési technikák alkalmazásával egyszerüsíthetõ a modell és a

feldolgozás könnyebbé tehetõ, q a jelenlegi rendszerek hibásan egyesítenek különbözõ adatszerkezeteket, amelyeket

szét kellene választani és külön kellene kezelni.

Projektspecifikációk felülvizsgálata Második lépés: A Munkacsoport áttekinti a már létrehozott projektspecifikációkat és azonosítja az adatkövetelményeket és azokat a feladatokat, melyek elvégzése ahhoz szükséges, hogy a létezõ adatokat eljuttassák abba az állapotba, ami által lehetõvé válik a projektspecifikációkban azonosított jövõbeli igények kielégítése. Számos tényezõ van, mely feladatkitûzésre vezethet. Ezek közül néhány: q a jelenlegi adatszerkezet nem elégíti ki a követelményeket, q rossz vagy hiányos adatok vannak jelen, q az adatok egységesítésének kívánt szintje nem áll rendelkezésre, q a jelenlegi adatok nem elégítik ki a követelményeket, q a jelenlegi adatok nem aktuálisak, q az adatok nem eléggé pontosak, q a részleges és teljes ismétlõdések konzisztencia problémákat okoznak, q a jelenlegi adatszerkezet elfogadhatatlanul gyenge teljesítõképességet eredményez, q az adatok minõsége iránti bizalom alacsony, q egy rendszerleállás utáni felépülés nem megfelelõen biztosított,

Bevezetés

97

q az adatbiztonság nem megfelelõ, q az adatok integritása nem éri el a kívánt szintet, q az adatvédelem szinvonala nem megfelelõ.

Lehetséges megoldások azonosítása Harmadik lépés: miután a problémákat és követelményeket azonosították, a Munkacsoportnak tisztázni kell a lehetséges megoldásokat. A gyakorlatban várhatólag számos lehetõséget kell majd tekintetbe venni, amikor eldöntik, hogy az adott problémákat miképpen oldják meg. Néhány ilyen lehetõséget sorolunk fel az alábbiakban. q Helyettesítés: ahol a PDM-en lévõ egyedek és kapcsolatok egy részhalmazát teljes

egészében kicserélik az IDM ekvivalens részeivel. q Áthidalás: ahol egy új vagy átdolgozott követelményt a létezõ adatszervezés és az új

vagy átdolgozott rendszer között épülõ híd elégíthet ki. Ez gyakran együtt jár a "lebontás és felépítés" ("strip and build") megközelítéssel, ahol a létezõ adatállományok adatokat szolgáltatnak idõlegesen egy közbülsõ adatbázishoz, amely táplálja az új rendszert. q Újrafelhasználás: ahol a létezõ adatszervezést megfelelõnek vélik az új vagy

átdolgozott rendszerhez. Ez a megközelítés együttjárhat kismértékû módosítással. q Módosítás/bõvítés: ahol a létezõ adatszervezést módosítani kell, hogy megfeleljen

az új követelményeknek. A változtatás eredményez valahol az IDM és PDM között.

"kompromisszumos"

adatszervezést

q Hibrid megoldás: akkor fordul elõ, ha a fenti tevékenységek egyesítése szükséges

ahhoz, hogy kielégítsük a projekt specifikációkban körvonalazott követelmények. Például, szükségessé válhat, hogy a létezõ rendszer adatainak csupán egy részét helyettesítsük új adatokkal, azaz csak egy részét módosítjuk a létezõ adatszerkezetnek, miközben más részét változatlanul hagyjuk. q Minden

marad a régiben: Elõfordulhatnak olyan projektspecifikációk nem követelnek adattevékenységeket.

esetek,

amikor

a

A harmadik lépésben lehetõség szerint ki kell választanunk a járható utat és a részletekkel aktualizálnunk kell a projektspecifikációkat. Ebben a szakaszban némely esetben nem lehet egyetlen megoldást választani, többet is számításba vehetünk. Minden egyes megoldást röviden vázolni kell tekintettel a költségekre, idõbeosztásra, egyéb problémákra és, ha lehetséges, egy ajánlást kell tenni. A változatok kiértékelése és a kedvezõ megoldás kiválasztása késõbbi szakaszban történik meg.

Hatáselemzés Negyedik lépés: ha egy létezõ adatszerkezet megváltoztatását javasolják, az jelentõs hatást gyakorolhat más területekre is. A módosítás és helyettesítés szükségessé teheti változtatások százait a létezõ programokon és tranzakciókon (a programokban alkalmazott adatfeldolgozási folyamatokon), amelyek az adatokat használják. Mielõtt elhatároznánk, hogy módosítjuk vagy helyettesítjük a létezõ adatszerkezetet, mindenekelõtt tekintetbe kell vennünk az adatok jelenlegi használatát. Minden egyednél, melyre változtatások kiterjednek, meg kell vizsgálnunk a rendszereket, amelyek jelenleg használják és az érintett programokat és tranzakciókat. Ha az adatokat a szervezet számára szolgáltatják, figyelemmel kell lenni arra, hogy a kívánt formában és tartalommal meg lehet-e kapni õket, Fordítva, ha az adatokat a külvilág számára szolgáltatják, akkor a fogadószervezettel tudatni kell a változtatást. Kellemetlen meglepetéseket okozhat egy ilyen elemzésnek az elvégzése. Az a gondolat, hogy a PDM részeit az ideális adatmodellel helyettesítsük, a gyakorlatban nem bizonyul MTA Információtechnológiai Alapítvány, 1993

feltétlenül költségkímélõnek. A hatáselemzés eredményeképpen lehet, hogy vagy korábbi javasolt megoldások elvetése, vagy módosítása mellett döntünk.

Megoldás-csoportok Ötödik lépés: Lehet, hogy megoldás-csoportokat kell a Munkacsoportnak azonosítania. Az adatelemzés összetettségének az egyik oka a különbözõ megoldások között lehetséges kölcsönös kapcsolatok léte. A megoldások egyedi kiértékelésének más lehet az eredménye, mint ha több megoldást egy csoportként szemlélünk. Néhány esetben a megoldások más megoldásoktól függenek, és nem lehet egyedül vizsgálni õket. Elõfordul, hogy ha nem csoportokban szemlélnénk a megoldásokat, akkor rossz megközelítést választunk. Számos ok van, ami miatt szükségessé válhat a megoldások csoportosítása. Ilyen például: q Szekvencia: Lehet, hogy van egy határozott sorrend, amiben a megoldásokat

implementálni kell. Lehet például, hogy egy új értékesítési statisztikai rendszer fejlesztését megelõzõen szükség van rendelés feldolgozási adatokra. q Függõség: Elképzelhetõ, hogy egy feladatkitûzés csak akkor helyes, ha elég széles

körre vonatkozik. Lehet például, hogy több megoldás van, ami javasol egy adott adatbázis kezelõ rendszert (DBMS), hardver környezetet, vagy szoftver típust. Lehet, hogy a megoldások külön-külön nem annyira meggyõzõ erejûek, ami megindokolhatná az adott DBMS bevezetését, de együttesen már nyomós érvet képezhetnek. q Költségek: A hatáselemzés kimutathatja, hogy van a megoldásoknak egy ésszerû,

költségekkel kapcsolatos csoportja. Ahol az adatok sok területen használatosak, rendszerint a legköltségkímélõbb ugyanolyan vagy hasonló típusú megoldást ajánlani valamennyi területen. Például egy olyan környezetben, ahol több rendszer használja ugyanazt az adatszervezést, nagyon valószínûtlen, hogy a legköltségkímélõbbnek az a stratégia bizonyulna, ami az egyik rendszernél helyettesítésen, egy másiknál áthidalásos megközelítésen, a harmadiknál pedig lényeges módosításokon alapulna. q Konzisztencia: a hasonlónak tûnõ megoldások csoportokba sorolását fontolóra

vehetjük. Az olyan megoldási lehetõségek, amelyek a rendszer újraírását szorgalmazzák egy különleges stílusú felhasználói felületen, egy csoportba kerülhetnek. Ha egy ilyen sajátos felhasználói felületet alkalmazunk, valószínüleg értelmes széleskörûen bevezetni. q Fejlesztési szakértelem: a megoldások csoportosíthatók a megvalósításukhoz

szükséges fejlesztési szakértelem szerint. Például a szoftvercsomagokat javasló megoldások elkülöníthetõk a fejlesztést igénylõektõl. q Adatelosztás:

az adatelosztás elemzésének végeredménye a megoldások természetes csoportjainak kialakulásához vezethet. Például egy olyan megoldás, amely az adatszerkezet egy részének elosztását írja elõ, maga után vonhatja a szóbanforgó adatokat használó összes funkció szétosztását. Ha ez nem így történik, az adatszerkezet egy részének elosztása valószínüleg akkor is jelentõs hatással van számos alkalmazási területre.

Új projektspecifikációk Hatodik lépés: az adatokkal kapcsolatosan új projektspecifikációkat kell létrehozni, ha ez szükséges. Az elõzõekben a kezdeti követelménytervezés folyamán azonosított projektspecifikációk összekapcsolásra kerültek az adatmodellek megfelelõ részeivel. Most az adatmodellek azon részeivel kell foglalkozni, melyek változtatását eddig nem láttuk szükségesnek a meglevõ projektspecifikációkban.

Bevezetés

99

Ezt az eddig azonosított követelmények és témakörök felülvizsgálatával érjük el. A Munkacsoport megvizsgálja a PDM-mel kapcsolatos problémákat is és foglalkozik az eddigi projektspecifikációkban még nem szereplõ problémák kijavításával és kiértékelésével. Ha a Munkacsoport az adatokkal kapcsolatos további intézkedéseket érez szükségesnek, akkor adatorientált projektspecifikációkat hoz létre és, ha lehetséges, több megoldást javasol a problémák feloldására.

Összefoglalás Az adatmodellezés ezen részének a végére a következõk fognak a Munkacsoport rendelkezésére állni: q az ideális és a jelenlegi adatszerkezet összehasonlító elemzése, q adatszempontokat figyelembe vevõ projektspecifikációk, q azonosított problémák és a nekik megfeleltetett, a jelenlegi adatszerkezeten alapuló

feladatkitûzések, q egy vagy több megoldás azzal kapcsolatban, hogy a jelenlegi adatszerkezet az ideális

felé mozduljon el. A következõ lépésben a Zsûri a megoldásokat felülvizsgálja és javaslatokat tesz az elfogadásukra illetve visszautasításukra. Azoknál a követelményeknél, melyeknél több, mint egy megoldás kínálkozik, a felülvizsgálat eredménye egy elõnyben részesített megoldási lehetõség kiválasztása lesz.

Szakasztervek felülvizsgálata Bemenetek A Munkacsoport azért, hogy segítsen a Zsûrinek fontolóra venni az adattervezés elsõ részének eredményeit, számos jelentést készít. A Zsûri ezeket tudja használni arra, hogy megismerkedjen a választási lehetõségekkel. A jelentések a következõk: q adatkövetelmények és megoldások jelentése, q megoldás-csoport jelentés, q hatáselemzés jelentés.

Adatkövetelményeket és megoldásokat tartalmazó jelentés készül mindegyik vizsgált területrõl. Ezek tömörített formában jelenítik meg a Munkacsoport által a követelményekrõl, problémákról és lehetséges megoldásokról összegyûjtött valamennyi információt. A jelentés gyakran számos bejegyzést tartalmaz, úgymint: q IDM és PDM információk. q Követelmények és problémák leírása:

- adatszerkezetbõl adódó következtetések, - fizikai megvalósítási szempontok, - adatelosztási megfontolások, - adatforrás-elemzésbõl származó megfontolások, - hatás a létezõ adathasználatra, - egyéb tényezõk. q Kapcsolódó projektspecifikációk katalógusa. q Javasolt megoldások leírása:

MTA Információtechnológiai Alapítvány, 1993

- leírás, - egyed/kapcsolat következtetések, - létezõ rendszerekre gyakorolt hatás, - fejlesztési következtetések, - szempontok mellette, - szempontok ellene, - munkacsoport javaslatok, - egyéb tényezõk. A megoldás-csoport jelentés tartalmazza az egyes csoportokkal kapcsolatos megoldásokat. Az adatkövetelmények és megoldások tanulmányozása közben a Munkacsoport azonosíthat megoldás-csoportokat, melyek együttes kezelését fontolóra kell venni. Ez a jelentés a Zsûri számára rövid, tájékoztató dokumentumot szolgáltat, ami kiemeli, hogy mely megoldásokat kellene együttesen kezelni. A hatáselemzés jelentés azon létezõ programokat és tranzakciókat tartalmazza, melyeket a változtatások érintenek. Ahol a meglevõ adatszerkezet újrafejlesztése javasolt, a költségek gyakran növekednek, mert sok létezõ programot és tranzakciót is újra kell írni vagy módosítani ahhoz, hogy az új adatszerkezeten használható legyen. Ez a jelentés egy rövid utalásokat tartalmaz azokra a létezõ programokra és tranzakciókra, melyek a jelenlegi adatszerkezethez kapcsolódó egyedeket használják. Amikor a dokumentációkat átadták felülvizsgálatra, a Zsûri megkezdi a javasolt megoldások elemzését. A szemlét megelõzõen a következõ dokumentumokat kell a Zsûrihez juttatni: q az eddig elkészült projektspecifikációkat, q fizikai adatmodellt (PDM) az észlelt adatproblémák leírásával, q ideális adatmodellt (IDM) a hozzá kapcsolódó adatokkal, q adatkövetelmények és megoldások jelentését, q megoldás-csoport jelentést, q hatáselemzés jelentést.

Ideális helyzetben a Zsûri az összes megoldást felülvizsgálja, választ közülük, és ajánlásokat tesz a prioritásra és sorrendiségre. Ez nem mindig lehetséges, lesznek esetek amikor néhány kérdés nem oldható meg további vizsgálat nélkül. Lehet, hogy szükséges még egy szemle a Zsûrinek a fennmaradt kérdések eldöntésére.

Módosítási tervek Amikor a szemle befejezõdött és a megoldások közül választottak, a projektspecifikációkat egyeztetik a kiválasztott megoldásokkal. Ez a következõket foglalja magába: q az érintett projektspecifikációknak az az adatokhoz kapcsolódó információkkal történõ

kiegészítését (adatkövetelményekkel és a választott megoldásokkal), q a költség, haszon és kockázat adatoknak az aktualizálását és a projekt prioritásoknak

az újraszámítását, q az összes projektspecifikáció felülvizsgálatát a Munkacsoport által.

Az adattervezés közben létrehozott projektspecifikációkat kidolgozását be kell fejezni, majd és hozzá kell adni a projektek meglevõ halmazához.

Bevezetés

101

A projektspecifikációk változtatásai, a módosított költség/haszon következtetések és Zsûri utasításai alapján a Munkacsoportnak újra fázisokba kell csoportosítania a projektspecifikációkat. Ez többnyire viszonylag nyilvánvaló feladat, de valószínüleg az adattervezési munkák jelentõs hatással lesznek a követelménytervezési szakaszban már elkészített projektspecifikációkra. A változtatásoknak számos típusa lehetséges. q Megváltozhat a projektsorrend annak következtében, hogy az eredetileg alacsony

prioritású tevékenységek feljebb kerülnek a sorrendben, mert más, magasabb prioritású projektek számára szükséges kritikus adatokat szolgáltatnak. q Sorrend változását okozhatja az, ha az eredetileg magas prioritásúnak gondolt

tevékenységek lejjebb kerülnek a rangsorban, mert az adategységesítés kivitelezéséhez szükséges erõforrások nem állnak rendelkezésre vagy a költségük nem indokolható. q Az adattervezési tevékenység azonosíthat egy integrált adatkörnyezet fokozatos

felépítésének a megvalósíthatósága által vezérelt ideális építkezési sorrendet. A sorrendek tehát különbözhetnek a kezdeti tervben meghatározottaktól. q Az adattervezés alatt új projektek derülhetnek ki, ha egy kezdeti ajánlás, amely

szerint a létezõ állományok vagy adatbázisok képezhetnék egy használható adatállomány alapjait, hibásnak bizonyul. q A projektspecifikációk lényegesen megváltozhatnak, átdolgozásra kerülhetnek amikor

a kezdeti ötletek a lehetséges integrációról megvalósíthatatlannak bizonyulnak. A létezõ programok vagy tranzakciók kicserélésének költségei túl nagynak bizonyulhatnak. Azon projektek, amelyek rendszerek újrafejlesztését irányozzák elõ, helyettesíthetõk olyan projektekkel, amelyek a létezõ állományok alapján felépítenek közbülsõ adatbázisokat. q Az

adat-megvalósítási stratégiák megváltozhatnak. A szervezetbeli egyetlen, kizárólagos adatbázis kezelõ rendszerre (DBMS) történõ áttérés költségei túl magasnak bizonyulhatnak. Például sokkal hasznosabb lehet, ha meghagyjuk a már használt hálós vagy hierarchikus adatbáziskezelõ rendszert az alapfolyamat támogatására, és relációs terméket használunk a lekérdezésekhez és a döntés támogató alkalmazásokhoz.

q A javasolt projekteket törölhetik, ha a visszafejteési (re-engineering) költségek becsült

nagysága jelentõsen megváltoztatja a költség/haszon kimutatásokat és ennek következtében a javasolt projektek prioritását.

Átmeneti adatmodellek elkészítése A Munkacsoport elkészít egy-egy átmeneti adatmodellt (Transition Data Model - TDM) minden a vázlatos minden egyes fejlesztési fázisához. Lehetséges az is, hogy ahol a fázis egy vagy több fõ projektet tartalmaz, ott ezen projektek mindegyikéhez készítünk TDM-et. Így elképzelhetõ, hogy egy fázishoz több, mint egy TDM tartozik. Az átmeneti adatmodellek elkészítésének folyamata a fizikai adatmodellel leírt jelenlegi adatszerkezettel indul. Mindegyik átmeneti adatmodell fokozatosan egy, az ideális adatmodellhez egyre közelebbi állapotba alakítja azt. Az átmeneti adatmodellek jelöléstechnikája az ideális és a jelenlegi adatmodelleknél használt technikák ötvözete.

MTA Információtechnológiai Alapítvány, 1993

Fizikai modell

Ideális modell

TDM1

Átmeneti modellek

Rangsorolt projektspecifikációk

TDM2 1 2 3 4 5

TDM3

Fázisleírások A stratégiai tanulmány rendszerint több átmeneti adatmodellt fog tartalmazni. Ha a TDMek fejlesztése befejezõdött, akkor minden egyes fázishoz a következõ információk kapcsolódnak: q a fázis leírása dátumokkal, stb., q teljes egészében leírt projektspecifikációk, q TDM leírások, q TDM adatszerkezet ábrák.

Munkacsoport szemlék Az adattervezés utolsó szakaszában a Munkacsoport felülvizsgálja az elkészült dokumentumokat. A szemle során foglalkozni kell minden egyes fázissal kapcsolatos információval. A szemlének ki kell térnie: q a dokumentációk befejezett voltának ellenõrzésére, q a költség/haszon kimutatások helyességének és indokoltságának vizsgálatára, q a technikai eszközök helyességének áttekintésére, q a TDM leírások megfelelõen hordozzák-e a TDM adatszerkezeti ábráinak az értelmét,

jelentését ? q a javasolt adatszerkezeti átmenetek sora értelmes-e?

A szemle némi átdolgozást eredményezhet. Amikor befejezõdött, megkezdõdhet a stratégiatervezési projekt végsõ szakasza.

Bevezetés

103

Elõírt termékek Az irányelvekben felsorolt jelentések közül az elõzõ szakasz végén érintettek mindegyike változhat, azaz "A jelenlegi rendszerek", a "Projektállomány", "Az irányítási és áttérési tervek" és a "Irányítási és mûszaki koncepciók" c. jelentések is, annak megfelelõen, hogy milyen új projektek kerülnek indításra, illetve melyek változnak meg az adattervezés következményeképpen. A "Mûködési modellek" c. jelentést ki kell egészíteni az adatokat leíró részekkel, a dokumentum más részei a követelménytervezés során készítendõ el. A stratégiatervezési projektnek már ennél a pontjánál érdemes az "Erõforrás-, finanszírozás- haszonkimutatások", valamint a "Gazdaságossági mérleg és befektetésindoklás" összegzõ jelentések elkészítésének a megkezdése, mert ezek tartalma érdekelheti a Zsûrit. A projektleírások tartalmazzák egy elõzetes becslését a projektekre vetített erõforrásigényeknek, a költségeknek, valamint költség/haszon elemzési adatokat. A fázisokra összegzett munkaerõ- és finanszírozási követelményeket, valamint a várható hasznot érzékeltetõ kimutatásokat ezek alapján el lehet készíteni, az irányelvekben foglaltak figyelembevételével.

Adattervezési technikák Bevezetés Számos adattervezési technika kerül felhasználásra a stratégiai adattervezés során. Ezek közé tartozik:

q az ideális adatmodellezés, q a fizikai adatmodellezés, q az átmeneti adatmodellek elkészítése, q a relációs adatelemzés, q az adatcsoportosítás (clustering), q a részadatbázisokra bontás (subject databases), q az adatelosztás-elemzés (distribution analysis), q az adatforrás-elemzés. Az elsõ két technika már kivonatosan ismertetésre került. A fennmaradókat a továbbiakban tekintjük át.

Átmeneti adatmodellek elkészítése Az átmeneti adatmodelleket (Transition Data Models - TDM) a jelenlegi adatmodell és az ideális modell egyes részeibõl szerkesztjük meg. A stratégiai terv minden egyes fázisához készül egy átmeneti adatmodell. A legtöbb esetben az fordul elõ, hogy az elsõ átmeneti adatmodell nagyrészt a jelenlegi adatmodell elemeit tartalmazza, és az ideális modellnek csak néhány eleme kerül be. A késõbbi, egymás után következõ modellek a jelenlegi adatmodellbõl egyre kevesebbet tartalmaznak, míg az ideális modellbõl egyre többet, ahogy a fázisok során a jelenlegi rendszerek új fejlesztésekkel vagy átdolgozásokkal kiváltásra kerülnek. Egy átmeneti adatmodell kidolgozásakor sok kérdést kell megválaszolni. Például nagyon valószínû, hogy az új rendszerek és az átdologozásra ki nem jelölt rendszerek között adatismétlés (duplikáció) lép fel. Hogyan kell ezt kezelni ? Többféle megközelítés lehetséges:

MTA Információtechnológiai Alapítvány, 1993

q tartsuk fenn a jelenlegi szintjét az adatismétlésnek, és tõle független új rendszereket tervezzünk,

q minimalizáljuk az ismétlést azáltal, hogy a meglevõ rendszerekben az új adatbázis bizonyos részeinek elõírjuk a használatát,

q az adatok közötti kapcsolatok figyelembevételével hozzunk létre egy redundancia nélküli közös adatbázist, melyet az összes alkalmazás használni fog,

q áthidaló szoftvert készítünk a jelenlegi és tervezett rendszerek közötti kapcsolat megteremtése érdekében.

Az alábbi ábrán látható egy minimális redundanciát tartalmazó átmeneti adatmodell, melyben a fizikai adatmodell egy része, illetve az ideális adatmodell egy része került összefésülésre.

Beszállító

Módosított Termék

Munkahely Raktár

Áradatok Elõállító Útmutató

Folyamat

Nyugta Gépsor

Tervek Nyugtasor

Elõállítási Szabványok

Megrendelés

Megrendeléssor

Nyugtasor hozzárendelés

Relációs adatelemzés A relációs adatelemzés olyan hatékony technika, mely minden egyes adatelemet értelmez, és részletes ideális adatmodellt épít fel. Minthogy ez a fajta elemzés szigorú szabályokon alapul, ezért szinte mindenféle adatra alkalmazható és a megfelelõ adatmodell egyszerûen megkonstruálható az eredményeibõl. A stratégiai tervezés során azonban nem feltétlenül kell relációs adatelemzést végezni. Az egyed-kapcsolat adatmodellezés a legtöbb esetben elégséges alapot nyújt a stratégiai adattervezéshez. Ugyanakkor vannak kivételek: egyes esetekben az a legjobb, ha a tervezõ kihasználja a relációs adatelemzés adta elõnyõket. A technika pontosan meghatározott lépések sorozatából áll, melyek elõírják az elemzõ számára

q a rendszerekben elõforduló adatelemek meghatározását és katalogizálását, q az adatelemek egyedekhez történõ rendelését, minimális redundanciával, q a szervezeti adatmodell felépítését, azaz az ideális adatmodell megkonstruálását, q az elõzõ lépések kombinációját. A relációs adatelemzési technikát csak akkor szokás használni a stratégiai adattervezés során, ha a vizsgált rendszerek bonyolultak, és nehezen érthetõk meg. Nem túl valószínû, hogy teljeskörû elemzést kellene elvégezni. Sokkal inkább elképzelhetõ, hogy néhány

Bevezetés

105

terület kiválasztásra kerül az adatelemzésre, és az eredményül kapott modell az egyedkapcsolat elemzésbõl, illetve a relációs elemzésbõl származó eredmények kombinációja lesz. Néhány szempontot adunk meg, melyek megléte arra késztethetnek, hogy az adott esetben használjunk relációs adatelemzési technikát.

q Az adatok furcsák és nehezen értelmezhetõk, q A meglevõ fájlrendszer olyan bonyolult, hogy a fizikai adatmodellt nem lehet belátható

idõben elkészíteni és az adattípusok 'be vannak drótozva' a programokba és a legegyszerûbb megoldásnak az tûnik, hogy az állományokon relációs adatelemzést hajtsunk végre.

q A modellezés alatt álló rendszer jelenlegi formája véglegesnek tûnik, és nem valószínû, hogy a stratégiai adattervezés során az megvalósításában lényeges változtatásokra lenne szükség.

adataiban

és

fizikai

q Ha a stratégiai adattervezés nem túl nagy kiterjedesû, és viszonylag kis mennyiségû adatelemmel kell foglalkozni (kevesebb, mint 300 adatelem). Az adatmodell létrehozásán kívül, a relációs adatelemzés további elõnyökkel is kecsegtet:

q mindes egyes egyedhez meghatározza annak tartalmát, q meghatározza az adatfüggõségeket és kapcsolatokat, q kiküszöböli a redundanciát, q megszünteti az adatok kétértelmûségét (pl. a Vásárló sorszáma és a Számlaszám ugyanazt jelenti-e ?),

q nagyban hozzájárul az adatelemek szemantikájának meghatározásához.

Adatcsoportosítás A kivonatos adatmodellek (summary data model) iránt fellépõ igény különösen szembeötlõ, hiszen a stratégiai adatmodell elkészítésekor gyakran igen nagy, több száz egyedet és kapcsolatot tartalmazó modellekhez juthatunk. Ebben a módszerben az adatcsoport-modellezésnek (Clustered Data Modeling, CDM) nevezett technika áll rendelkezésre kivonatos adatmodellek elkészítésére. Nincsenek abszolút szabályok a részletes modellnek a kivonatos modellé történõ átalakítására, de vannak jól alkalmazható általános elvek. Egy részletes adatmodell gyakran eleve részekre bontva készül el, méghozzá úgy, hogy a funkciókat és/vagy alkalmazásokat egyénként modellezik, és az eredményeket összevonják. Az adatcsoportosítás ebben az esetben az egyes funkcióból vagy alkalmazásból származó adatmodelleken külön-külön végzett egyedcsoportosítással, összevonással indul. A befejezõ lépés pedig a kisebb CDM-eket egyetlen modellbe vonja össze. A csoportosítás tulajdonképpen a részletes modell összetartozó elemeinek egybevonását jelenti. A csoportosítás egy magasabb szintjén levõ egyed számos más egyedbõl állhat. A kivonatos és a részletes adatmodell közötti integritás fenntartása érdekében a magasabb szintû modellnek kiegyensúlyozottnak (balanced) kell lennie, azaz a magasabb szintû modellbeli egyedbõl pontosan annyi kiinduló és beérkezõ kapcsolatnak kell lennie, mint a részletes modellben a hozzá tartozó egyedeknél összesen. Ezt illusztrálja az alábbi két ábra:

MTA Információtechnológiai Alapítvány, 1993

Kereskedelmi

Vásárló Típus

Osztály

Számla

Bizományos Státusz

Zóna

Bizományos

ADATCSOPORT

Rendelés

Termék

Szállítmány

Rendeléssor

Ha a szaggatott vonalon belüli egyedeket szeretnénk csoportosítani, öszevonni, azaz a Számla, a Címzett és Szállítási hely egyedeket, az eredményül kapott adatmodell az alábbi lenne:

Kereskedelmi

Vásárló Típus

Osztály

Bizományos Státusz

Vásárló adatai

Rendelés

Zóna

Termék

Rendeléssor

A kiegyensúlyozottság a példában megmaradt, hiszen a Vásárló csoport az összes olyan kapcsolattal rendelkezik, melyek az eredeti modellben is szerepeltek. A kiegyensúlyozottság elõnye, hogy az egyedcsoportok (clusters) és a részletezett egyedek egymással felcserélhetõek. Ennélfogva az egyedcsoportokat tartalmazó modell vegyes jellegû lehet, egyes részeket részletesen mutathat, másokat adatcsoport formájában. Az adatcsoportosítás az egyes adatmodellek egyszerûsítésének precíz eszköze. A gyakorlatban az ideális, a fizikai és az átmeneti adatmodellek mind tartalmaznak egyedcsoportokat.

Bevezetés

107

Részadatbázisok Az ideális és a jelenlegi adatmodellek közötti összehasonlítás elvégzése során lehetséges, hogy szükségesnek bizonyul az adatoknak kezelhetõbb egységekre való bontása, így juthatunk el a részadatbázis fogalmához. A részadatbázisoknak ugyanazoknak kell lenniük az ideális és a fizikai adatmodellekben (az összehasonlíthatóság érdekében). Az adattervezés az IDM és PDM összehasonlítható részeire vonatkozik. A részadatbázisokra bontás más szempontból is jól használható eszköze az IDM különféle elemzésének. Például rámutathat:

q felelõsség hozzárendelésére, q elosztás alapjára, q az adatbázis hardver elemeken történõ szétosztására, q a különféle adat- és adatbáziskezelõ eszközök szerinti bontásra. Az adattervezésben az adatok egymás iránti 'affinitását' használjuk elsõdleges szempontként a részadatbázisok kialakításakor. Ez a részadatbázisok közös kulcsokon és adatokon történõ alapulását jelenti. A megközelítés nagyon hasonlít az adatcsoportosításnál követett módszerre. Kivételt képez ez alól az adatelosztás elemzése. Ha egy adatmodell-rész elkülönült (distributed), akkor rendszerint érdemes önálló részadatbázisként kezelni.

Adatelosztás-elemzés Ha az adatokat elkülönült helyeken tárolják, célszerû lehet adatelosztás elemzést végezni, azért hogy lássuk, hogyan kellene az adatokat elosztani, 'szétszórni'. Az adatelosztás elemzésnek az a célja, hogy meghatározzuk, hogy hol kell a model egyes részeinek elérhetõnek lennie. Az adatelosztásnak négy fajtáját különböztetjük meg:

q adattípus szerinti, q adatpéldány szerinti, q attribútum szerinti és q duplikált adatelosztást. Az adattípus szerinti elosztást rendszerint egyszerû kezelni. Ilyen ott fordul elõ, ahol az egyedek, mint típusok fordulnak elõ különbözõ helyeken. Ez azt jelenti, hogy a modell egy része az egyik helyen van, a fennmaradók egy másikon. Adatpéldány szerinti elosztásról akkor beszélünk, amikor egy egyednek néhány példánya mind az egyik, mind a másik helyen felléphet. Ezt példázza az az eset, amikor úgy döntünk, hogy a kisebb vásárlóink rendeléseit az egyes áruházakban dolgozzuk fel, míg a nagyobb megrendelõk esetében ez a központnál történik. Ezért a Vásárló, a Rendelés és Rendeléssor egyedek példányai mind a központnál, mind a területi áruházakban fellelhetõk. Attributum szerinti adatelosztás esetében az egy egyedhez tartozó adatelemek több helyen kerülnek feljegyezésre. Egy vásárlási statisztikai rendszerben például, a Vásárló egyed némely adatelemei a központnál kerülnek tárolásra a statisztikai kimutatások elkészítése végett, míg más adatelemeit muszáj az áruházakban tárolni a megrendelések feldolgozása érdekében. Végül a közös, duplikált adatok jelenléte gyakori jelenség. A rendelésfeldolgozási példában a Termék egyed adatelemei, mint például Leírás, Súly, Ár rendelkezésre MTA Információtechnológiai Alapítvány, 1993

állhatnak minden egyes áruháznál. Az alábbi példa egy olyan modellt mutat be, ahol a Vásárló, a Rendelés és Rendeléssor egyedek adatpéldány szerinti elosztásban vannak, míg a Termékek egyed példányai duplikálásra kerülnek a központnál és az áruházakban.

Vásárló Irodák

D Rendelés

Termék

Raktár

D Rendeléssor

Duplikátumok

(mindkét helyen)

Adatforrás-elemzés Az adatelosztás elemzés jól használható, ha egy szervezet földrajzilag elkülönült egységekre bomlik, de az adatokat egy közös modellel szeretnénk leírni. Az egymástól elkülönült egységek építhetnek másoktól érkezõ adatokra, és mivel egy szervezeten belüli részegységekrõl van szó, az adattulajdonosok köre központilag kijelölhetõ. Ezen a módon a felelõsség kérdése rendezhetõ. Más a helyzet viszont a közigazgatásban, ahol a szervezetek gyakran számítanak más szervezetektõl kapott adatokra, viszont a közöttük nincsen közvetlen szervezeti kapcsolat, ezért az adatfelelõsség kiosztása csak körülményesen tehetõ meg. Az ilyen helyzeteket tudatos kezelését támogatja az adatforrás-elemzés, mely segíthet abban, hogy a vezetés is tudatában legyen az adatok megszerzése terén fellépõ esetleges bizonytalanságoknak. A bizonytalanságok kiküszöbölése túlmenne az informatikai stratégia tervezés projekttervezéskor megszabott határain, a cél itt a bizonytalan helyzet felismerése, és az abból származó informatikai következményekre történõ felkészülés. A technika nem grafikus jellegû, tulajdonképpen kiegészíti az ideális, a fizikai és az átmeneti adatmodellezési technikát. Elsõ lépésben katalógust kell készíteni azokról a külsõ szervezetekrõl, melyektõl a saját szervezet adatokat vár, illetve adatokat szolgáltat. A második lépésben a feladat az, hogy az egyes adatmodellekben szereplõ egyedekre, illetve egyedcsoportokra rögzítsük azt, hogy mely külsõ szervezetettõl várunk el adatszolgáltatást, és annak milyen a természete (jogszabály írja elõ, csak pénzért juthatunk hozzá stb.), ha ez szükséges. Ahol ilyen feljegyzés nincs, ott automatikusan feltételezzük azt, hogy a szervezet maga képes gondoskodni a szükséges adatokról. Természetesen a fordított tevékenység is elvégzendõ: minden olyan adatcsoportot, melyeket a stratégiatervezés kiterjedésébe esõ, saját szervezet szolgáltat másoknak, szinten meg kell határozni, beleértve ebbe a szolgáltatás természetét is. Erre is szükség

Bevezetés

109

van, mert pl. egy alárendelt szervezetnél elvégzett informatikai stratégiai tervezés végén a vezetésnek arról is tudomással kell bírnia, hogy milyen adatszolgáltatási kötelezettségekkel kell számolniuk. Nem szabad arról elfeledkezni, hogy az adatforrás-elemzés stratégiai szinten történik, azaz nem szabad az adatelemek szintjén elveszni, csak akkor, ha annak valóban jelentõsége van. Fontos lehet annak figyelemel kísérése is, hogy milyen módon történik az adatok átvétele és továbbítása (pl. floppi, X.25 stb.), az erre vonatkozó információk is feljegyzésre kerülhetnek. A rendszerek elemzésekor a rendszerre ható erõk közül a beszállító és az ügyfél típusú erõk vizsgálata segíthet az adatforrás-elemzés elsõ lépésében, a lehetséges adatszolgáltatók feltérképezésében. A tevékenységek elemzése során a beszállítás és kiszállítás tipusú tevékenységeknél érdemes figyelmet fordítani az adatforráselemzési szempontokra. Adat elvileg csak szervezeti tevékenységen kerül kerülhet be és kerülhet ki a szervezetbõl, ezért ezen a módon meg lehet állapítani a ki- és bemenõ adatforgalmat.

MTA Információtechnológiai Alapítvány, 1993

7 A végleges terv elkészítése Projektspecifikációk A kulcstermékek Az informatikai stratégiatervezési módszer végsõ kulcsterméke a rangsorolt projektspecifikációk rendszere. Ezek valójában azoknak az informatikai projekteknek a leírása, melyeket a stratégiai tervezés idõtávlatában meg szeretnénk valósítani. Mint az már korábban említésre került, a kényelem kedvéért a projekteket hat típusba soroljuk:

Fejlesztési projektek mint például:

q új számítógépes rendszerek létrehozása, q meglevõ nagyobb számítógépes rendszerek továbbfejlesztése, q régi, nem-integrált adatszervezés kiváltása adatbázistechnológiával, q meglevõ

mûködõ

rendszerekre

épülõ

adatkinyerõ

rendszerek

építése

Bevezetés

111

döntéselõkészítés támogatása végett,

q programcsomagok beszerzése és alkalmazása.

Megvalósíthatósági tanulmányok például az alábbi területeken:

q a célok eléréséhez kapcsolódó legjobb megoldások értékelése, q a javasolt tevékenységek részletes elemzése a felmerülõ költségek és hasznok szempontjából,

q a technikai megvalósíthatóság és a felhasználói igények költségvonzatainak értékelése.

Mûszaki értékelések mint például:

q hardver stratégiák elemzése, q hálózati megközelítések elemzése, q adatbáziskezelõ kiválasztása, q módszer, eszköz és technika értékelés, q fejlesztõeszközök értékelése.

Technológia bevezetés az alábbi területeken:

q irodaautomatizálás, q lokális hálózatok, q hardver, q CAD/CAM, GIS alkalmazások, q adatbáziskezelõk, q hálózat, q rendszerszoftver.

Szervezeti változások q Adatirányító (menedzselõ) funkció létrehozása. q Felelõsség kiosztása az adatokért és a rendszerekért q Az alkalmas informatikai irányítási stratégiák betartatását elõsegítõ mechanizmusok kiépítése.

q Az

informatikai megváltoztatása.

fejlesztések

kivitelezési,

Módszer, szabvány és koncepció bevezetése Lehetséges területek:

MTA Információtechnológiai Alapítvány, 1993

irányítási,

tervezési

módjának

q Elemzési és tervezési módszerek, q 4. generációs nyelvek, q minõségellenõrzõ és minõségfelügyeleti programok elindítása, q programozási technikák, q adatkezelési módszerek és eszközök, q minõségirányítási programok.

Projektleírások Minden egyes projekt esetében az eddig feljegyzett adatok kiegészítésre kerülnek az alábbiakkal:

q a fejlesztési fázis megadása, q a projekt rövid leírása, a kritikus felhasználói igényekre történõ utalással, q a költségek, hasznok és fejlesztési erõforrásigények áttekintõ értékelése, valamint a rangsorolásban felhasznált projektmegtérülési érték,

q a kockázatelemzés eredménye (a rangsorolási folyamat során történt meg), q ahol szükséges, annak magyarázata, hogy milyen rendszerre ható erõket támogatna a projekt eredményeképpen megvalósuló rendszer,

q ahol szükséges, annak ismertetése, hogy milyen mûködési tevékenységeket támogatnak milyen projekttel, és vajon ezek a tevékenységek magas költséggel, hozzáadott-értékkel és információtartalommal bírnak-e.

Fejlesztési fázisok A kezdeti tervezés során a fejlesztési projektspecifikációkat fejlesztési fázisokba soroltuk. Ezek általában a projektek indítási idõpontján alapulnak. Az elsõ fázisban jellemzõen azok a projektek kerülnek, melyek 0-6 hónapon belül indításra kerülnek, a második fázisban a 7-12. hónapban indulók, a harmadik fázisban a 13-18. hónapban indulók. Érdemes megjegyezni, hogy a fázisok nem feltétlenül követik pontosan a rangsort. Egy olyan projekt, mely várhatólag sokáig tart, de viszonylag alacsony a prioritása, elindítható a korai fázisban annak érdekében, hogy kellõ idõben rendelkezésre álljon.

További jelentések Minden egyes projektspecifikáció legalább egy kulcsfeladat-kitûzéshez kapcsolódik. Minden egyes kulcsfeladat-kitûzés egy kulcscélhoz kapcsolódik, és a kulcscélok kritikus sikertényezõkhöz fûzödnek.

Bevezetés

Kritikus

113

Kulcscél

Projektspecifikáció

Kulcsfeladat

Projekt/Feladat Kereszthivatkozás

Sikertényezõ

Cél

KST/Cél Kereszthivatkozás

A felhasználó kérheti annak bemutatását, hogy egy projektspecifikációhoz milyen kapcsolódó feladatkitûzés, cél és kritikus sikertényezõ tartozik.

Adatmodellek A végsõ jelentés négyfajta adatmodellt fog tartalmazni:

q a jelenlegi környezet logikai leírását (PDM), q az ideális környezet logikai leírását (IDM), q több átmeneti adatmodellt, melyek mutatják a jelenlegi és az ideális közötti lépéseket, q kiinduló

fizikai terveket, melyek ismertetik az átmeneti adatbáziskezelõvel, vagy fájlkezelõvel történõ megvalósítását.

adatmodelleknek

Fizikai adatmodell A PDM egyetlen vagy több összevont (clustered) adatmodellbõl áll. Általában egy függelék tartalmazza lényegi egyed/csoport hívatkozásokat. A PDM diagrammon túl, elkészül egy áttekintõ, adatokkal kapcsolatos problémákat leíró jelentés. A jelentésben kiemelésre kerül:

q magyarázat a modell(ek)hez, ha szükséges, q az adatismétlõdés és adatredundancia fõbb területei, q fõbb változtatandó területek, a megfelelõ projekt specifikációk, q javasolt változtatások a PDM és IDM összehasonlítása alapján. Ezenkívül, amennyiben ez gyûjtésre került, az egyedekkel kapcsolatos programok/tranzakciók is mellékletbe kerülnek. Ezt az információt akkor fogjuk használni, amikor meg kell fontolni egyes jelenlegi rendszerek kiváltását az adattervezés során.

Ideális adatmodellek Az IDM vagy egyetlen modellként, vagy több almodell képében készül el. Az egyed/csoport hívatkozás függelékbe berül. Az IDM csoportosítása kiterjesztésre kerül a részadatbázisok és a hozzájuk tartozó egyed alstruktúrák ismertetésével.

Átmeneti adatmodellek Minden olyan projektspecifikáció, mely fejlesztési projektet takar, eredményezhetné egy átmeneti adatmodell elkészítését. Ahelyett azonban, hogy sok átmeneti adatmodellt MTA Információtechnológiai Alapítvány, 1993

készítenénk, egyet készítünk minden egyes fázishoz. Egy három fázisból álló projekt esetében általában három átmeneti adatmodell készül el. Lehetnek azonban olyan esetek, amikor egyes különösen nagy vagy stratégiai jellegû projektek szükségessé teszik egy saját átmeneti adatmodell létrehozását. Ha a TDM-kben adatcsoportosítási technikát alkalmaztuk, akkor a csoport/egyed kereszthívatkozások függelékbe kerülnek. Minden egyes átmeneti adatmodellhez hozzátartozik az alábbiak rövid leírása:

q az átmenet a PDM-tõl az IDM-be, q az

áthidaló stratégiák, projektspecifikációkra),

ha

az

szükséges

(hivatkozásokkal

a

megfelelõ

q milyen módon fog a konverzió és bevezetés megtörténni (hivatkozásokkal a megfelelõ projektspecifikációkra),

q az egyedi adatirányítási (menedzsment) problémák és megoldásokra történõ utalások.

Kiinduló fizikai tervek Néha elõfordulhat, hogy a felhasználók az átmeneti adatmodelleket, vagy bizonyos részeiket fizikai tervezési formában is meg szeretnék kapni. Ezeket a szokásos konvertálási 'ökölszabályok' végrehajtásával kaphatjuk meg. A fizikai modellekhez fûzött megjegyzések utalnak arra, hogy

q a jelenlegi adatmegvalósítást változatlanul használják-e, q módosítások szükségesek a jelenlegi adatszerkezetben, q új szerkezeteket kell hozzátenni a meglevõkhöz.

Kiegészítõ jelentések Az informatikai stratégiatervezési projekt legfontosabb megállapításait rögzítõ, eddig ismertetett dokumentumokon kívül további kiegészítõ jelentéseket is el lehet készíteni. Ezek közé tartozik:

q kritikus sikertényezõk, a kapcsolódó kulcscélokkal és feladatkitûzésekkel, q minden egyes mûködési területre az alkalmazott mûködési stratégia, q minden egyes mûködési területen a választott informatikai irányítási stratégia.

Amennyiben a jelenlegi stratégiának a változtatását írtuk elõ, akkor hívatkozni kell a megfelelõ projektspecifikációkra.

Háttéradatok További, a stratégiai terv készítése során felhasznált információkat is mellékelhetünk. Ezek közé tartozhat:

q az egyes mûködési területek felsorolása, az ott érvényes kritikus sikertényezõkkel, tevékenységekkel és rendszerekkel,

q szervezeti hierarchiaábra, és a megfelelõ mûködési területek, q stb.

Elõírt termékek Az irányelvekben felsorolt jelentések közül végsõ formába kell önteni az összes, az adat-

Bevezetés

115

és követelménytervezés egyeztetésénél érintett dokumentumot, úgymint: a "Projektállomány, "Az irányítási és áttérési tervek", és az "Irányítási és mûszaki koncepciók" c. jelentéseket. (Ezeknek a jelentéseknek az elkészítésében a projektspecifikációkra támaszkodtunk.) Ha ezek a jelentések végleges formájukat már elnyerték, ezután befejezhetõ az "Erõforrás-, finanszírozás- haszonkimutatások", valamint a "Gazdaságossági mérleg és befektetésindoklás" összegzõ dokumentumok elkészítése is. "A stratégiai tanulmány" tartalma a már ismertett dokumentumok összefoglalása: a szervezeti-mûködési leírás, a jelenlegi rendszerek és a lehetséges alkalmazások együttes áttekintése. A stratégiai tanulmány tartalomjegyzékére részletes ajánlást tartalmaz az irányelveket ismertetõ kézikönyv A. függeléke. Ez a tartalomjegyzék tartalmaz egy olyan fejezetet, mely az elõrelépés alternatíváit taglalja. Az alternatívák megjelenésének az az oka, hogy amennyiben külsõ személyek készítenék el a stratégiai tanulmányt, akkor a vezetés világosan lássa a lehetséges utakat, és a közöttük történõ döntés joga és felelõssége ne kerülhessen a szervezeten kivûlre. Az itt ismertetett módszer erõsen épít a szervezet saját személyi állományának aktív részvételére, ezenkívül a vezetés rendszeres, szoros kapcsolatban áll a stratégiatervezési projekttel a zsûrizési mechanizmuson keresztül. Ezért a módszer szószerinti alkalmazása során nem készülne olyan alternatívákra tagolt dokumentum, mely döntéselõkészítõ célokat szolgálna, hiszen az alternatívák közüli választás egyrészt a szemlézési mechanizmussal (a Zsûri felelõsségével), másrészt a vezetés részvételével a közös feladatkitûzõ üléseken valósul meg. Ez a megközelítés egyszerûbb, takarékosabb és a vezetés nagyobb mérvû elkötelezettségével jár, feltétele a saját személyzet minél nagyobb fokú bevonása a Munkacsoportba. Ha a stratégiatervezési projektet szerzõdéses tevékenység keretében külsõ vállalkozókra bízzák, vagy a Megbízó az irányelvek szerint eredetileg elõírt termékbontást látott szükségesnek, akkor ezt a stratégiatervezési projekt indításakor figyelembe kell venni, és alternatívákat tartalmazó jelentéseket kell elkészíteni. "A stratégiai irányvonal" c. jelentés az irányelveket tartalmazó dokumentum alapján készítendõ el a stratégiatervezés végén, a Zsûri által elfogadott stratégiai tanulmányból kiindulva. Nagyon fontos az, hogy ez a vezetõknek szánt jelentés jó minõségû legyen, a vezetés számára értelmezhetõ, rövid, a szakzsargont mellõzõ stílusban kerüljön megfogalmazásra.

Vezetõi szemle Az informatikai stratégiai terv elkészültét egy átfogó szemle követi. Ez eredményezheti azt, hogy a terv egyes részei további tisztázásra igényelnek, egyes területei átdolgozásra szorulnak, illetve a projektspecifikációk rangsora felülvizsgálatra kerül.

MTA Információtechnológiai Alapítvány, 1993

A. függelék Tevékenységek felsorolása 1. szakasz - tervezés és behatárolás Ennek a szakasznak a célja, hogy meghatározza a projekt határait (kiterjedését), illetve el kell készíteni az informatikai stratégiatervezési projekt ütemtervét. Az egyes lépések és feladatok az alábbiak:

q Kiinduló tervezés: ·

Tájékoztató ülés, a Megbízó és a Tanácsadó részvételével.

·

Vizsgáljuk meg az informatikai stratégiatervezésnek a viszonyát más tervezési ciklusokhoz.

·

Döntsük el, hogy hány stratégiai terv készül, és milyen lesz ezeknek az egymáshoz való viszonya.

·

Határozzuk meg a projekt megközelítését.

·

Rögzítsük a témakör kiterjedését.

Bevezetés

117

·

Állapítsuk meg az idõtartamot.

·

Válasszuk ki a kritikus sikertényezõkkel kapcsolatos megközelítést.

·

Informáljuk a felsõvezetést a kiinduló tervezés eredményeirõl.

·

Határozzuk meg a végsõ jelentés formáját és stílusát.

q Tervezés véglegesítése. ·

Jelöljük ki a Munkacsoporton belüli szerepeket.

·

Tájékoztassuk a szervezeti, szolgáltató és informatikai egységek vezetõit.

·

Katalogizáljuk a jelenlegi rendszereket.

·

Mérjük fel a korlátozó tényezõket.

·

Ismertessük az eddigi eredményeket.

·

Készítsünk kiinduló ütemtervet.

·

Készítsük elõ a kiinduló tervezés dokumentumait.

·

Állítsuk össze az interjútervet.

·

Készítsünk el egy részletes tevékenységtervet.

·

Bocsássuk szemlére a részletes tervet.

·

Készítsük el a tervezési és behatárolási jelentést.

q Oktatás: ·

Készítsünk oktatási tervet.

·

Folytassuk le az oktatási tervben elõírtakat.

q Minõségbiztosítási és vezetõi szemle.

2. szakasz - adatgyûjtés Ennek a szakasznak a célja, hogy meghatározza és összegyûjtse az alapvetõ információkat a kiinduló elemzés számára. Csak a legszükségesebb adatokat gyûjtsük! Az egyes lépések:

q Vizsgáljuk a meg a szervezeti hierarchiát. q Azonosítsuk a kulcsembereket és szereplõket. q Határozzuk

meg a mûködési/termék/szolgáltatási területeket kereszthívatkozást közöttük és a szervezeti hierarchia között.

és

készítsünk

q Határozzuk meg a tevékenységeket. q Mérjük fel a létezõ számítógépes rendszereket. q Készítsünk kereszthívatkozásokat a mûködési területek és tevékenységek, valamint a tevékenységek és rendszerek között.

q Bocsássuk az elkészült dokumentumokat minõségbiztosítási és vezetõi szemlére.

MTA Információtechnológiai Alapítvány, 1993

3. szakasz - stratégiai követelménytervezés 3.1 lépés - Jelenlegi mûködési és informatikai stratégiák Ennek a lépésnek az a célja, hogy elemezze és kategorizálja a jelenlegi mûködési területeket, tevékenységeket és rendszereket, és átfogó képet adjon arról a megközelítésrõl, hogy a jelenleg milyen módon kerül az informatika alkalmazásra. A feladatok:

q Kategorizáljuk a mûködési/termék/szolgáltatási területeket ·

fontosság szerint,

·

mûködési stratégia szerint,

·

informatikai irányítási stratégia szerint.

q Kategorizáljuk a tevékenységeket: ·

generikus kategóriákba,

·

a tevékenységi háló elkészítésével,

·

tevékenységek értékelése költség/hozzáadottérték/információtartalom szerint.

q Kategorizáljuk a jelenlegi rendszereket: ·

hatékonysághoz történõ hozzájárulás szerint (rendszerkategóriákba),

·

rendszerre ható erõk szerint,

·

támogatási kategóriák szerint.

q Készítsünk jelentést, rámutatva azokra a területekre, melyeket közelebbrõl meg kell vizsgálnunk a következõ lépésben.

q Végezzünk társszervezet elemzést. q Bocsássuk az elkészült dokumentumokat minõségbiztosítási és vezetõi szemlére.

3.2 lépés - Az informatika jövõbeli stratégiai alkalmazása Ennek a lépésnek az a célja, hogy megfogalmazza az informatikai céloknak egy struktúrált halmazát, valamint feladatkitûzéseket, amelyek azt írják le, hogy milyen módon lehet ezeket a célokat az informatika alkalmazásával elérni. A lépések:

q Egyeztessük a jelenlegi mûködési stratégiákat és jussunk egyetértésre a jövõbeli stratégiák tekintetében.

q Állítsuk össze és bocsássuk szemlére a kritikus sikertényezõket. q Készüljünk fel az interjúkra: ·

Fogalmazzunk meg kiinduló célokat.

·

Hajtsunk végre SCOPE elemzést a célok finomítása, valamint feladatkitûzések felállítása érdekében.

·

Az interjúalanyok átolvasásával.

készüljenek

fel

az

eddig

elkészített

dokumentumok

Bevezetés

119

q Folytassuk le és dokumentáljuk az interjúkat, melyek tárgya a szervezeti igények és lehetséges megoldások felmérése. Részletesebben:

·

Folytassuk le az interjúkat az egyéni célok és feladatkitûzések felmérése végett.

·

Összegezzük az egyéni célokat és feladatkitûzéseket, és alakítsunk ki egy kulcshalmazt ezekbõl.

·

Bocsássuk szemlére a kulcscélokat és feladatkitûzéseket.

q Folytassuk le és dokumentáljuk a közös feladatkitûzõ megbeszéléseket, hogy azonosítani tudjuk az informatikai irányítási stratégiákat, koncepciókat és terveket. Részletesebben:

·

Folytassunk le közös feladatkitûzõ megbeszéléseket.

·

Összegezzük az egyéni célokat és feladatkitûzéseket, és alakítsunk ki egy kulcshalmazt ezekbõl.

·

Bocsássuk szemlére a kulcscélokat és kulcsfeladatokat.

q Bocsássuk az elkészült dokumentumokat minõségbiztosítási és vezetõi szemlére.

3.3 lépés - vázlatos informatikai stratégiai terv Ennek a lépésnek az a célja, hogy létrehozzon egy kiinduló tervet, mely tartalmazza az elvégzendõ informatikai projekteket. Minden egyes projektre egy rangsorba helyezett projektspecifikáció készül. A feladatok:

q Készítsük el a kiinduló informatikai stratégiai tervet: ·

Alakítsuk át a kulcsfeladatokat projektspecifikációkká, költség/haszon és kockázatelemzés elvégzésével.

·

Határozzuk meg és bocsássuk szemlére a projektek rangsorát és fázisbontását.

q Bocsássuk az elkészült dokumentumokat minõségbiztosítási és vezetõi szemlére.

4. szakasz - stratégiai követelménytervezés 4.1 lépés - ideális adatszerkezet Ennek a lépésnek a célja a szervezettõl elválaszthatatlan adatok logikai leírásának elkészítése. A feladatok:

q Bontsuk részekre a vizsgálat tárgyát képezõ területeket. q Minden egyes részre készítsünk el egy ideális adatmodellt (IDM-t), logikai adatmodellezési és/vagy relációs adatelemzési technikák felhasználásával.

q Az adatcsoportosítási technika segítségével jussunk el egyszerûen érthetõ modellhez. q Vonjuk össze az eredményeket egyetlen IDM-be, ha lehetséges. q Szemlézzük az adatcsoportosítás eredményeit, és módosítsük, ha szükséges. q Végezzünk adatelosztás- és adatforrás-elemzést, ha szükséges. q Bontsuk az IDM-t részadatbázisokra (subject databases). q Bocsássuk az elkészült dokumentumokat minõségbiztosítási és vezetõi szemlére.

MTA Információtechnológiai Alapítvány, 1993

4.2 lépés - jelenlegi adatszerkezet Ennek a lépésnek a célja a jelenlegi rendszerekben tárolt adatoknak az alapos megértése, logikai adatmodell készítése róluk. A feladatok:

q Minden egyes rendszerrõl gyûjtsünk információkat. q Minden egyes részre készítsünk el egy fizikai adatmodellt (PDM-t). q Készítsünk kereszthivatkozásokat a PDM-beli egyedek és a jelenlegi rendszerek között.

q Hajtsunk végre adatcsoportosítást. q Végezzünk adatelosztás- és adatforrás-elemzést, ha szükséges. q Vonjuk össze a PDM-ket egyetlen modellbe, ha lehetséges. q Bocsássuk az elkészült dokumentumokat minõségbiztosítási és vezetõi szemlére.

4.3 lépés - adatterv készítése Ennek a lépésnek a célja egy olyan adatterv elkészítése, mely feloldja a jelenlegi rendszerek és a kiinduló informatikai stratégiai terv között tátongó szakadékot. Az adattervet az átmeneti adatmodellek (TDM-k) sorozatával fogalmazzuk meg, amely megmutatja, hogy az egyes stratégiai fejlesztések befejeztekor hogyan kerülnek az adatok tárolásra. A feladatok:

q Hasonlítsuk össze az IDM-ket és a PDM-ket. Jegyezzük fel a problémákat és a fogyatékosságokat.

q Határozzuk meg az adatkövetelményeket az elõzõ lépés eredményei, valamint a kiinduló stratégiai tervben szereplõ projektspecifikációk figyelembevételével.

q Készítsünk lehetséges megoldásokat az adatproblémák és fogyatékosságok feloldására.

q Hajtsunk végre hatáselemzést annak felmérése érdekében, hogy a javasolt változtatások milyen módon érintik a jelenlegi rendszereket.

q Keressük meg a megoldási csoportokat, melyek a lehetséges megoldásokat ésszerûen összevonják.

q Állítsunk elõ projektspecifikációkat, ahol az adattervezés ezt szükségessé teszi. q Tekintsük át az adatkövetelményeket és a javasolt megoldásokat. Ahol több javaslat is született, válasszunk ezek közül.

q Vizsgáljuk felül a létezõ projektspecifikációkat és fázisokat. q Készítsünk átmeneti adatmodelleket a fázisokhoz. q Végezzünk adatelosztás- és adatforrás-elemzést, ha szükséges. q Bocsássuk az elkészült dokumentumokat minõségbiztosítási és vezetõi szemlére.

5. szakasz - Az informatikai stratégiai terv véglegesítése Ennek a szakasznak a célja részletes informatikai stratégiai terv elkészítése, és a stratégiatervezési projekt megállapításainak jelentés formájában történõ összegzése. A feladatok:

Bevezetés

121

q Gyõzõdjünk meg arról, hogy a munka során nem változtak-e az eredetileg tervezett átadandó termékek. Határozzuk meg újra a termékeket, ha ez szükséges.

q Gyûjtsük össze a projektspecifikációkat egyetlen jelentés képében. q Készüljünk fel a projekt megállapításainak a vezetés számára történõ ismertetésére, majd mutassuk be nekik az eredményeket.

q Beszéljük meg a vezetés és felhasználók visszajelzéseit, és módosítsuk a tervet, ha szükséges.

MTA Információtechnológiai Alapítvány, 1993

B. függelék Az irányelvek szerinti jelentések elõállítása Elõírt termékek A kézikönyvben "Az informatikai stratégia kialakításának és megvalósításának alapelvei" címû dokumentumban meghatározott jelentések elkészítésének folyamatát a módszer lépései során követtük végig. Ebben a részben a másik szemszögbõl: az elõírt jelentések oldaláról tekintjük át az elõállítás folyamatát. A hívatkozásokban az A. függelékben szereplõ tevékenységlista szerinti bontást használjuk fel. Ne feledjük el: az ismertetett módszer erõsen épít a szervezet saját személyi állományának aktív részvételére, arra, hogy a vezetés rendszeres, szoros kapcsolatban áll a stratégiatervezési projekttel. Ezért a módszer eredeti megközelítése szerint nem készül olyan alternatívákra tagolt dokumentum, mely döntéselõkészítõ célokat szolgálna. A számbaveendõ alternatívák közötti választás a szemlézési mechanizmussal és a vezetésnek a közös feladatkitûzõ üléseken történõ részvételével valósul meg. Ez a megközelítés egyszerûbb, takarékosabb és a vezetés nagyobb fokú elkötelezettségével jár, de feltétele az elsõsorban saját személyzetre

Bevezetés

123

történõ építkezés. Az ismertésre került módszer a stratégiatervezési ciklus egy részét fedi le, nem tér ki a megvalósítás tervezésére és hangolási, felügyeleti tevékenységekre. Ezeket az irányelvekben elõírt módokon kell megvalósítani.

Behatárolási tanulmány 1. és 2. szakaszban, elsõsorban a stratégiatervezés projektterve alapján készül el.

A mûködési környezet leírása 1. és 2. szakaszban adatgyûjtéskor kezdõdik el az írása. A 3.1 lépésben a szervezetre ható külsõ erõk és a támogatási kategóriák felmérését, illetve a társszervezet elemzés eredményeit kell beilleszteni. Ez bõvítendõ a 3.2 lépésben végrehajtott SCOPE elemzésbõl származó megállapításokkal.

Célkitûzések és súlyponti kérdések Ez valójában a szervezeti-mûködési tervezés során kellene, hogy létrejöjjön. A 3.2 lépésben felhasznált szervezeti-mûködési tervet át kell venni, ha ez nem áll, rendelkezésre, úgy a kritikus sikertényezõket és kitûzésük indokait kell felhasználni. Ezek hiányában a célokat, leírásukat, és alátámasztásukat kell megjeleníteni. A 3.1 lépésben elõálló mûködési területek rangsora is szerepeltetendõ a jelentésben.

Szervezeti-mûködési modellek A 2. lépésben a szervezeti felépítésrõl, és a kulcsemberekrõl szerzett adatokat szerepeltetni kell ebbe jelentésben. A 3.1 lépésben a mûködési területek egyes értékelései (mûködési stratégia/informatikai irányítási stratégia), indoklásukkal együtt idetartozik. A folyamatok leírását mutatják be a tevékenységláncok vagy az adatfolyamábrák. A 4.1 és 4.2 lépések során elõálló adatmodellek (ideális/fizikai) a szervezeti adatokat és kötnyezetüket írják le.

A jelenlegi rendszerek áttekintése A 3.1 lépésben a jelenlegi rendszerek értékelését kell felhasználni, a 3.2 lépésben a tervezett rendszerek értékelését. Az értékeléseket (kategória/rendszerre ható erõk/támogatási kategória) ki kell egészíteni indoklásukkal is.

Lehetséges alkalmazások A 3.2 lépésben alkalmazásokat.

elõálló

feladatkitûzések

listája

tartalmazza

az

elképzelhetõ

Alternatívák információs rendszerekre A 3.2 lépésben elõálló kulcsfeladatok listája tartalmazza az megcélzott alkalmazásokat. A kulcsfeladatokat tartalmazó írásos anyagok fokozatos szûréseken, szemléken mennek át. Ezek a dokumentumok tehát kezdetben tartalmazzák az alternatívákat az összes elképzelhetõ feladatkitûzés és projekt formájában, majd a késõbbi verzióikban a szemlék eredményeitõl függõen közülük egyre kevesebb marad meg. Ha a stratégiatervezési projekt indításakor szükségesnek látják, lehetséges ezeknek a dokumentumnak a szerkezetét eleve úgy meghatározni, hogy az a feladatokat és a projektspecifikációkat alternatívákba sorolja be.

MTA Információtechnológiai Alapítvány, 1993

A stratégiai tanulmány A tanulmány tartalma a már ismertett dokumentumok összegzése: a szervezeti-mûködési leírás, a jelenlegi rendszerek és a lehetséges alkalmazások áttekintése. Az 5. szakasz végén készül el.

A stratégiai irányvonal Az irányelveket tartalmazó kézikönyv alapján készítendõ el az 5. szakasz során, a stratégiatervezés végén, a Zsûri által elfogadott stratégiai tanulmányból kiindulva.

Irányítási-mûszaki koncepciók A 3.2 lépésben az interjúk során az informatika használatára vonatkozó kérdésekre adott válaszok, a feladatkitûzések és a választott informatikai irányítási stratégia alapján készül el a kiinduló verziója a jelentésnek. A 3.3 lépésben a technológiabevezetési és a szervezeti változás típusú projektspecifikációk tartalmával, illetve az 5. lépésben a stratégiatervezési projekt során megfogalmazott koncepciókkal kell bõvíteni ezt a jelentést.

Irányítási és áttérési tervek A 3.3 szakaszban készül el az elsõ változata. Az irányítási terv alapjául a rangsorolt projektspecifikációk szolgálnak. Az áttérési tervek elkészítéséhez felhasználhatók a módszer, szabvány és koncepció bevezetés típusú, valamint a technológiabevezetési típusú projektspecifikációk. Mivel a projektspecifikációk változhatnak a 4.3 lépésben, ezért szükséges lehet a jelentés átdolgozása ebben a szakaszban.

Projektállomány A 3.3 szakasz végére elõálló, fázisba rangsorolt projektspecifikációk alapján készül el.

Erõforrás-, finanszírozás- és haszonkimutatások A projektspecifikációk tartalmazzák egy elõzetes becslését a projektre vetített erõforrásigényeknek, a költségeknek, valamint költség/haszon elemzési adatokat. A fázisokra összegzett kimutatásokat ezek alapján lehet elkészíteni, az irányelvekben foglaltak figyelembevételével, elõször a 4.3 lépésben, illetve végleges formájában az 5. szakaszban.

Gazdaságossági mérleg és befektetésindoklás Az irányelveket megfogalmazó dokumentum alapján készítendõ el. A stratégiai alternatívák a projektspecifikációkat tartalmazó dokumentumok különbözõ verzióinak képében jelennek meg. Minden egyes projektleírás tartalmaz költség/haszon elemzést, valamint kockázatelemzés, ennek alapján készítendõ el az 5. szakasz végén.

Irodalomjegyzék A felsorolt könyvek tágabb kitekintésre adnak alkalmat. Kifejezetten informatikai stratégiai tervezéssel a következõ négy mû foglalkozik (melyek nem szorítkoznak csupán a közszolgálatra).

q "Management Strategies for Information Technology", Michael J. Earl, Prentice Hall. q "Corporate Information Systems Management", James I. Cash et al., IRWIN Inc. q "Information Systems Strategic Planning", Computer Technology Research Corp. q "Fitting Information Systems Technology to the Corporate Needs: The Linking Strategy", Gregory L. Parsons, Harvard Business School

A szervezetstratégiai tervezés kérdéseivel foglalkoznak az alábbi mûvek:

q "Stratégiai management", Barakonyi Károly, Közgazdasági és Jogi Könyvkiadó q "Competitive Advantage", Michael E. Porter, Free Press q "Strategic Management - Awareness and Change", Thompson, Chapman & Hall Az adattervezés részletei iránt érdeklõdõk figyelmébe ajánljuk az 'SSADM struktúrált rendszerelemzési és -tervezési módszer' c. kiadványt.