FOLYAMATLEÍRÁST SEGÍTİ MÓDSZERTANI AJÁNLÁS

Átírás

1

2 A dokumentum az Új Magyarország Fejlesztési Terv keretében, az Államreform Operatív Program támogatásával, az Elektronikus közigazgatási keretrendszer tárgyú kiemelt projekt megvalósításának részeként készült. A dokumentum elkészítésében részt vett: 2

3 Metaadat-táblázat Megnevezés Leírás Cím (dc:title) FOLYAMATLEÍRÁST SEGÍTİ MÓDSZERTANI AJÁNLÁS Kulcsszó (dc:subject) Folyamatleírás; ajánlás; módszertan Leírás (dc:description) A dokumentum módszertani ajánlásokat tartalmaz a közigazgatási folyamatok felméréséhez és a felmérés eredményének szöveges és grafikus reprezentálásához. A módszertan alapján elkészült dokumentumok a közigazgatási folyamatok SOA alapokra helyezésénél lesznek felhasználva. Típus (dc:type) Szöveg Forrás (dc:source) - Kapcsolat (dc:relation) Folyamatleírást Segítı Gyakorlati Útmutató Terület (dc:coverage) KOP-ok során megvalósuló projektek, központi IT fejlesztési projektek Létrehozó (dc:creator) e-közigazgatási Keretrendszer Kialalkítása projekt Kiadó (dc:publisher) MEH EKK Résztvevı (dc:contributor) BME IK Jogok (dc:rights) e-közigazgatási Keretrendszer Dátum (dc:date) Formátum (dc:format) Microsoft Word.doc, elektronikus adathordozón Azonosító (dc:identifier) Nyelv (dc:language) Magyar Verzió (dc:version) V2 Státusz (State) végleges Fájlnév (FileName) EKK_ekozig_folyamatleiras_modszertani_ajanlas_080730_V2.doc Méret (Size) Ár (Price) - Felhasználási jogok (UserRights) - 3

4 Verziókövetési táblázat A dokumentum neve FOLYAMATLEÍRÁST SEGÍTİ MÓDSZERTANI AJÁNLÁS A dokumentum készítıjének neve BME IK A dokumentum jóváhagyójának neve A dokumentum készítésének dátuma Verziószám V2 Összes oldalszám 119 A projekt azonosítója Változáskezelés Verzió Dátum A változás leírása V First draft V First draft. szemlézett változat V Kiegészítések V Szerkezeti változtatások, kiegészítések V Szemlézett változat V Kiegészítések V Kiegészítések V MeH-nek átadott verzió. 4

5 Szövegsablon Megnevezés Leírás 1. Elıszó (Foreword) 1. fejezet 2. Bevezetés (Preamble) 2. fejezet 3. Alkalmazási terület (Scope) 2.1 fejezet 4. Rendelkezı hivatkozások (References) 5. Fogalom-meghatározások 13. fejezet (Definitions) 6. A szabvány egyedi tartalma 1.- fejezet (UniqueContent) 7. Bibliográfia 11. fejezet 8. Rövidítésgyőjtemény 12. fejezet 9. Fogalomtár 13. fejezet 10. Ábrák Folyószövegben 11. Képek Folyószövegben 12. Fogalmak A 13. fejezet (Fogalomtár) tartalmazza a legfontosabb fogalmakat és meghatározásukat. 13. Verzió V Mellékletek (Appendix) 10. fejezet 5

6 Tartalomjegyzék 1. Elıszó Bevezetés CÉLOK, ELVÁRÁSOK ALAPELVEK JELEN DOKUMENTUM TARTALMA Folyamat meghatározási és fejlesztési szabványok, elıírások ÉRETTSÉGI ÉS KÉPESSÉGI MODELLEK FOLYAMAT TÍPUSOK ÉS FOLYAMAT ALAPELEMEK A KÖZIGAZGATÁSI FOLYAMATOK TÍPUSOK ÉS FOLYAMAT ELEMEK A folyamatleírás/azonosítás tervezése A FELMÉRÉSI CÉL MEGHATÁROZÁSA ÉS FORRÁSOK FELTÁRÁSA A RÉSZTVEVİK, ÉRDEKELT FELEK AZONOSÍTÁSA IDİ ÉS ERİFORRÁS TERVEZÉS Az információgyőjtés A VONATKOZÓ JOGSZABÁLYOK AZONOSÍTÁSA ÉS FELDOLGOZÁSA DOKUMENTUMOK ÁTVIZSGÁLÁSA AZ INTERJÚK ÉS AZ INTERJÚZTATÁS Az interjúk csoportosítása formai jellemzık alapján Az interjúk csoportosítása céljuk alapján Az alapvetı követelmények az interjúk esetében Felkészülés a szóbeli interjúk végrehajtására Kérdıívek összeállítása Állítások, kérdések A szóbeli interjú támogatására szolgáló kérdıív AZ ESETTANULMÁNY SZAKÉRTİI VÉLEMÉNYEK FELTÁRÁSA Brainstorming és brainwriting Egyéb módszerek Folyamat kidolgozása/módosítása FOLYAMATOK SZÖVEGES LEÍRÁSA FOLYAMATOK ÁBRÁZOLÁSA Ábrázolási módszerek, architektúrák Workflow minták Ábrázolási nyelvek BPMN Ábrázolási nyelvek összehasonlítása Kiértékelési szempontok Összehasonlítás Érthetıség Workflow minták kifejezhetısége Szoftveres támogatottság Hordozható formátum Elterjedtség Összegzés Folyamatok helyességének ellenırzése KONZISZTENCIA VIZSGÁLAT REDUNDANCIA VIZSGÁLAT INKONZISZTENCIA ÉS REDUNDANCIA EGY IDİBEN Folyamat mérése, indikátorok Összefoglalás Mellékletek FOLYAMATOK AZ ÜZLETI ÉLETBEN ÉS A SZOFTVERFEJLESZTÉSBEN FOLYAMAT MEGHATÁROZÁSI ÉS FEJLESZTÉSI SZABVÁNYOK, ELİÍRÁSOK A SZOFTVERFEJLESZTÉSBEN AZ ISO SZABVÁNY FOLYAMATAINAK RÉSZLETES BEMUTATÁSA

7 10.4. A CMM MODELL A SPICE MODELL /ISO SZABVÁNY Sajátságos SPICE-modellek: az Automotive SPICE A CMMI MODELL A CMMI szerkezete CMMI DEV CMMI-ACQ v Példa a CMMI egy támogató folyamatára KITERJESZTETT BPMN GRAFIKUS JELÖLÉSEK BPMN activity és artifact típusok BPMN connection típusok BPMN event típusok BPMN gateway típusok BPMN swimlane típusok BPMN eszközök listája EPC UML TEVÉKENYSÉGDIAGRAMOK MÉRÉSEK Mérési skálák: Mérési módszerek: a QIP, GQM és EF A QIP A GQM Az EF A mérési mód lehetséges megközelítései Szakirodalmi hivatkozás Rövidítésgyőjtemény Fogalomtár

8 1. Elıszó Jelen dokumentum az Elektronikus közigazgatási keretrendszer részét képezi. A közigazgatási folyamatok és eljárások informatikai támogatásához elengedhetetlen azok egységes szemlélető leírása, dokumentálása. Jelen ajánlás ehhez a feladathoz nyújt segítséget. A dokumentum röviden tárgyalja azokat a leíró módszereket, melyek alkalmasak lehetnek a közigazgatási folyamatok egységes szemlélető leírására, majd rövid összehasonlítást és indoklást követıen javaslatot tesz a konkrét eljárásra, módszerre. Az ajánlás alapján készített gyakorlati útmutatót a Folyamatleírást segítı gyakorlati útmutató c. dokumentum tartalmazza, mely egy konkrét példán keresztül mutatja be a javasolt módszert és eszközrendszert. 2. Bevezetés A modern e-közigazgatási rendszerek az ügyintézési folyamatok felméréséhez és dokumentálásához olyan egységes adat- és folyamatmodell kialakítására törekszenek, amely egyaránt alapját képezi az ügyfélbarát leírásoknak és a mind a háttérirodákban, mind az ügyfél elıtt zajló közigazgatási eljárások automatizált mőködtetésének. A folyamatleírás kidolgozandó szabályainak természetesen annyiban egységesnek kell lenniük, hogy ezeket minden közigazgatási eljárásra és szereplıre érvényesnek tekintjük. Ez alapozza meg a folyamatok könnyő szétbonthatóságát, össze- és átrendezését; egyes generikus részfolyamatok újrafelhasználhatóságát. A szabványos építıelemek lehetıséget adnak a részekre megadott idı-, pénz- és egyéb ráfordításokból a komplex folyamatok ilyen mennyiségi mutatóinak automatikus számítására már a tervezési szakaszban is. A folyamatok (vagy workflow-k) szabványos leírását központilag felügyelt, megosztott szolgáltatásként rendelkezésre álló, az elemek közti fogalmi kapcsolódások részletes feldolgozásával szakontológiává fejleszthetı kontrollált szótáraknak is segíteniük kell. A fogalmak és osztályaik rögzítése a folyamat-leírási módszertan kidolgozásával párhuzamosan képzelhetı el. Az elérendı fogalmi tisztaság és a leírás magas szintjén megnyilvánuló egységesség a SOA (Service Oriented Architecture) elveinek betartásával együtt megalapozza a sokféle e-kormányzati megoldás interoperabilitását. Több szintő leírási módszerrel és eszközzel kívánjuk segíteni a folyamatok leírását. A legfelsı szinten elsısorban közigazgatási szempontból kívánjuk rendszerezni az adott folyamat, ügy, eljárás lépéseit, szereplıit, feltételrendszerét, eredményeit. A leírások interjúk, dokumentum és jogszabályi vizsgálatok és kombinációjuk (például: esettanulmány) keretében alakulnak ki, melynek során folyamatosan kell építeni a kialakuló fogalomtárat. A munka jelen fázisában véleményünk szerint, a leírások módszeres támogatására feltehetıen szükség lesz olyan szoftver eszközökre, melyek az ilyen jellegő információgyőjtést és rendszerzést, ontológiakészítést támogatják. 8

9 A mintaként kiválasztott folyamatok leírásához elsı lépésben táblázatos megközelítést alkalmazunk. Az eddig feldolgozott nemzetközi tapasztalatok arra engednek következtetni, hogy ez a módszer kellı alapot tud adni a további finomításokhoz. A továbbiakban felsorolásszerően ismertetjük a körvonalazódott módszertan kialakításának lépéseit Célok, elvárások Az e-közigazgatási rendszer kialakítása projekt keretében a közigazgatási folyamatok leírására egységes formátumot és módszertant dolgozunk ki elsıdlegesen annak érdekében, hogy a leírás alapján lehetıvé váljon a folyamatok automatizálása. Mindemellett a módszertan hozadékaként más motivációs tényezık (pl.: folyamatok átláthatóbbá tétele, egységes megjelenés) megjelenését is reméljük. A leíró módszertannal kapcsolatban felmerülı elvárásokat a következükben foglaljuk össze: támogassa mind elemi, mind komplex (akár több szolgáltatóra, sıt közigazgatási ágazatra kiterjedı, ügyfél-szempontú élethelyzetbe integrált) folyamatok leírását; támogassa költség-haszon- és egyéb teljesítményszámítások alapját képezı, aggregálható mennyiségi adatok győjtését; a nyert leíró adatok segítségével a folyamatok lehetıleg legyenek felépíthetık olyan szabványos, közismert nyelven, amely üzleti folyamatkezelı alkalmazás segítségével jól hasznosítható; támogassa a leírt folyamatok közötti kapcsolatok felderítését; konzisztencia ellenırzés révén támogassa a közigazgatási folyamatok korszerősítését, megújítását; legyen kellıen általános és rugalmas ahhoz, hogy a közigazgatási gyakorlat sokfélésége befogható legyen; legyen kellıen specifikus a közigazgatási folyamatokra, eljárásokra, ügymenetekre; legyen átlátható; támogatottság tekintetében legyen robosztus; a leírást végzık számára egyértelmő, csak a szükséges információkra kiterjedı séma álljon rendelkezésre Alapelvek Az e-közigazgatási rendszer kialakítása projekt alapvetı feltevése, hogy a közigazgatási folyamatok és eljárások kezelése az üzleti és az ipari folyamatok kezelésénél felmerülı problémákhoz hasonló problémákat vet fel. Ezért a problémák megoldását is az üzleti szférában alkalmazott módszerek, eszközözök, megoldások között keressük. Kiemelten figyelembe vesszük a szoftverfejlesztésben elterjedt folyamatleírási, folyamatfejlesztési modelleket, szabványokat. Ennek több oka is van, melyek közül az alábbiakban vázolunk néhányat. A szoftverfejlesztésben régóta, már az 1980-as évektıl kezdve világossá vált, hogy a megoldandó feladatok mérete, komplexitása, a feladatok megoldásában résztvevı csapatok mérete folyamatosan növekszik. Egyre kevesebb (volt) az esély arra, hogy egy feladatot egyetlen személy átlásson, a maga teljességében kezelni tudjon. Emiatt fontossá vált a megoldás folyamatának megértése, pontos meghatározása, 9

10 dokumentálása, intézményesítése. A szoftverfejlesztık körében ezért már régóta elkezdıdött a feladatok megoldásának modellezése, szabványosítása. Az elmúlt 25 évben sok megközelítés került kidolgozásra a szoftverfejlesztési folyamatok rendszerezésének céljából, melyek azután a gyakorlatban is kipróbálásra kerültek, és a tapasztalatok alapján folyamatosan fejlıdtek, finomodtak. Jelenleg jelentıs mennyiségő tapasztalat, jó gyakorlat, kipróbált megoldás áll tehát rendelkezésre, melyek azzal együtt, hogy elsısorban a szoftverfejlesztésre dolgozták ki ıket jól használhatók minden olyan területen, ahol folyamatok azonosítása, leírása, intézményesítése, továbbfejlesztése a cél. A jelenlegi projekt célját képezı e-közigazgatási folyamatok új alapokra helyezése a folyamatok meghatározásán túl azok teljes körő IT-támogatását is feltételezi. Egy átfogó, e-közigazgatási rendszerben megjelennek tehát az IT-hez kapcsolódó folyamatok is. Ezek egy része támogató folyamatként van jelen (a közigazgatási folyamatok végrehajtását támogatják pl. a számítógép-hálózatok, adatbázisok, különbözı szoftverek). Másrészrıl, már a folyamatok kialakításánál is figyelembe kell venni az IT, a szoftverfejlesztés által hordozott sajátosságokat, mert, például, a számítógépesítési lehetıségek befolyásolják a közigazgatási folyamatok meghatározását, felbontását (pl. a feladatok részfeladatokra való bontásának mélységét befolyásolja, hogy mit tekintünk szolgáltatásnak, melyhez megfelelı IT támogatást lehet biztosítani). Ismereteink alapján, hosszútávon a szolgáltatás-orientált architektúrák és fejlesztési módszerek elterjedésével kell számolnunk mind az üzleti, mind a kormányzati megoldásokban. Mivel ez az architektúra képes kellı rugalmasságot, architektúra- és gyártófüggetlenséget, a meglevı és az új rendszerek közötti zökkenımentes kapcsolatot biztosítani. A SOA (Service Oriented Architecture) jelenleg elsısorban a nagyvállalati szektorban kedvelt megoldás az IT-rendszerek átalakítása, a mőködés és a késıbbi gyors továbbfejlesztések optimalizálása kapcsán. A SOA olyan szabványos, strukturált üzeneteket fogadó és küldı, pontosan meghatározott interfészeken keresztül kommunikáló szolgáltatások, modulok halmaza, amelyeket jelenleg a Web Service szabványok írnak le. A SOA technológia várhatóan 2-5 éven belül jut el a teljes érettségig. Bár elsı körben fıként a banki és a távközlési szektor vált át a SOA-technológiára, az elektronikus kormányzati megoldásoknál, fejlesztéseknél is megkezdıdött a váltás. Így pl Anglia, Írország, Bulgária és Csehország is SOA alkalmazások bevezetésével fejleszti e-kormányzati rendszereit és az azokhoz kapcsolódó szolgáltatásokat Jelen dokumentum tartalma Jelen dokumentum a folyamatok azonosításával, felmérésével, meghatározásával és leírásával foglalkozik. Áttekinti a gyakorlatban erre a célra alkalmazott módszereket, és javaslatot tesz egy, az Elektronikus közigazgatási keretrendszerben ajánlott módszerre. Az e-közigazgatási rendszer kialakításának lépései a következı: a közigazgatási folyamatok felmérése, meghatározása, a meghatározott folyamatok IT-vel támogatható részeinek azonosítása, az IT fejlesztéseknek/meglévı megoldások átalakításának (pl. SOA-alapokra helyezés, SOA- szemlélető architektúra kialakítása) tervezése és megvalósítása, 10

11 a közigazgatási folyamatok átállítása az új, IT-vel támogatott megoldásokra. Ezt a folyamatot az 1. ábra szemlélteti. 1. ábra: Közigazgatási folyamatok új alapokra helyezése Jelen ajánlás kidolgozásakor figyelembe vettük az IT, és kiemelten a szoftverfejlesztés tapasztalatait, az ezen a területen kialakult jó gyakorlatokat. Ilyen értelemben utalunk pl. a folyamatok ábrázolásának, modellezésének lehetıségeire, a modellezés szoftvereszközökkel való támogathatóságára. Nem célunk konkrét folyamatok leírása, még kevésbé konkrét (közigazgatási) folyamatok IT-vel támogatható részeinek, vagy szolgáltatásként azonosítható részeinek meghatározása, hanem arra adunk útmutatást, hogy ezeket a tevékenységeket hogyan lehet konkrét esetben megvalósítani. A folyamatok átállítása az IT-vel támogatott megoldásokra szintén nem képezi jelen dokumentum tárgyát. A fenti ábrán szürkével jelöltük azokat a részeket, amelyeket jelen dokumentum nem, vagy csak részben érint. A folyamatok meghatározásához, a folyamat-típusok és jellemzıik megértéséhez szolgáltat információt a 3. fejezet. Ebben a részben szólunk a közigazgatási folyamatok sajátosságairól, valamint a szoftverfolyamat-fejlesztési modellekrıl is, melyek elveit, sıt, bizonyos részeit bármilyen üzleti/közigazgatási területen sikerrel lehet alkalmazni. A dokumentum további részeiben az 1. ábra Folyamatleírások készítése doboza kerül részletezésre, amint azt a 2. ábra szemlélteti. 11

12 2. ábra: Folyamatleírások készítése Az általunk javasolt módszertan szerint tehát elıször meg kell tervezni a folyamatleírást. Ezt a folyamatot a 3. ábra szemlélteti, a folyamat leírását a 4. fejezet tartalmazza. 3. ábra: Folyamatleírás tervezése Ezt követi az összes, kapcsolódó információ szisztematikus begyőjtése és strukturálása (létezı leírásokból, gyakorlat vizsgálatából, jogszabályoknak/szabványoknak való megfelelıség 12

13 vizsgálatából, interjúkból, szakértıi véleményekbıl). Az információgyőjtés folyamatát a 4. ábra mutatja be, részletes leírását a 5. fejezet tartalmazza. 4. ábra: Információgyőjtés A begyőjtött információk alapján kerül sor a létezı folyamatok listájának elkészítésére, majd az egyes folyamatok kidolgozására/módosítására, az 5. ábrán bemutatott folyamat alapján. A listából kerülnek kiválasztásra azok a folyamatok, amelyek kidolgozása (ha még nem létezett a folyamat és a leírása), illetve módosítása (ha már létezett a folyamat és leírása, de azt módosítani, fejleszteni kell) képezi a következı, ciklikusan ismétlıdı tevékenységsorozatot. A ciklus addig ismétlıdik, ameddig van a szervezetben olyan folyamat, amelyet meg kell határozni, ki kell egészíteni, esetleg korábban fekete doboznak tekintett részét kell elemeire bontani, és az elemi részeket kell folyamatként meghatározni. A 2. ábra jelölésében addig folytatódik a folyamatleírás(ok) kidolgozása/módosítása, míg van változtatást igénylı folyamatleírás. Ha nincs már módosítandó folyamatleírás, akkor lehet az ábra STOP dobozába kerülni. A 2. ábran szereplı Egy folyamatleírás kidolgozása/módosítása dobozát az 5. ábra szemlélteti. Ennek lényege, hogy meg kell határozni a folyamat külsı jellemzıit, ezeket adott formában le kell írni. Ha érdekesek számunkra a folyamat belsı jellemzıi (tevékenységei) is, akkor azokat is le kell írni, és a folyamat-elemek belsı viselkedését grafikusan kell ábrázolni. A módszertani ajánlás a 6. fejezetben foglalkozik ezzel a tevékenységgel. Itt bemutatjuk a folyamatok lehetséges alapelemeinek szöveges leírására és lehetséges grafikus ábrázolási módjára vonatkozó lehetıségeket. A folyamatok grafikus ábrázolására ajánlott módszer a 6.2. fejezetben található. Amennyiben a folyamatnak belsı mőködése ismert, vagy szükséges, hogy ismertté váljon, akkor a folyamat belsı tevékenységei újabb, kidolgozandó/módosítandó folyamattá válhatnak. Ezekre 13

14 szintén az 5. ábra tevékenységei hajtandók végre. A ciklus addig folytatódik, míg a folyamat leírása eléri a szükséges granularitást. 5. ábra: Egy folyamatleírás kidolgozása/módosítása A folyamatleírások kidolgozását követi helyességük ellenırzése. Ez tartalmazza mind a folyamat belsı ellenırzését (pl. megfelel-e a szükséges jogszabályoknak vagy informatikai követelményeknek), mind a kidolgozott folyamattal kapcsolatban levı folyamatok és a kidolgozott folyamat közötti inkonzisztenciák és redundanciák vizsgálatát, megszüntetését. Megtörténhet, hogy egy folyamatleírás kidolgozásának hatására más folyamatok módosítása szükséges. A folyamatok helyességének ellenırzési folyamatát a 6. ábra tartalmazza, és a 7. fejezetben írjuk le részletesen. 14

15 6. ábra: Folyamatok helyességének ellenırzése, módosítandó folyamatok azonosítása A 8. fejezet a Folyamat mérése, indikátorok témát részletezi. A 9. fejezet röviden összefoglalja a jelen dokumentumban leírtakat. 15

16 3. Folyamat meghatározási és fejlesztési szabványok, elıírások A mindennapi életben folyamatnak nevezzük a bizonyos cél elérését célzó tevékenységek sorozatát. A folyamat általában erıforrásokat használ, melyek segítségével bemenı elemeket (inputot) kimenı elemekké (outputtá) alakít. A folyamat célja általában valamilyen termék, résztermék vagy szolgáltatás létrehozása. Az IEEE STD-610 szabvány alapján folyamatnak nevezzük bizonyos céllal elvégzett lépések/tevékenységek sorozatát. A folyamatok megértésének és meghatározásának fontossága a társadalom fejlıdésével, az ipari termelés növekedésével egy idıben került elıtérbe. Ahhoz, hogy a termelés gördülékenyen, optimális hatásfokkal és erıforrás-kihasználtsággal mehessen végbe, szükséges a folyamat elemeinek és azok kapcsolatának megértése, meghatározása, modellezése. A modellezés megkönnyíti a folyamat automatizálását is. Minél több részlet ismert egy folyamattal kapcsolatban, annál kisebb a valószínősége annak, hogy valamely elıre nem látott esemény (kockázat) megzavarja a folyamat optimális, tervezett végrehajtását. A szervezetek tevékenységének vizsgálatakor manapság igen elterjedt a folyamatszemlélet, amely azt jelenti, hogy a szervezet tevékenységeit nem egymástól elkülönítve, hanem kapcsolatukban, folyamatukban vizsgáljuk. A tevékenység folyamatszemlélető megközelítését és modellezését támogatja a Magyarországon és az EU-ban, üzleti tevékenységet folytató és közfeladatokat ellátó szervezeteknél egyaránt elterjedt ISO 9001:2000 szabvány ([B20]), mely a minıségirányítási rendszerek kialakítását és mőködtetését írja le, igen hangsúlyos vevıközpontú folyamatszemléletet alkalmazva. Mivel ez a szabvány minden szervezetre alkalmazható, tevékenységi típustól függetlenül, érdemesnek tartjuk a melléklet fejezetében röviden bemutatni, milyen tanácsokat ad a folyamatok meghatározására és mőködtetésére vonatkozóan. A szoftverfejlesztés és karbantartás folyamatai számára az ISO szabvány ([B21]) egységes fogalmi keretet hoz létre és konkrét folyamatokat definiál, jól meghatározott terminológiát használva. A szabvány folyamatai közül a közigazgatásban a beszerzés, szállítás, üzemeltetés, karbantartás, dokumentálás, minıségbiztosítás, problémamegoldás, együttes átvizsgálás folyamatok, valamint az összes szervezeti folyamat alkalmazható. Az ISO szabványt két felet érintı helyzetekben történı használatra tervezték, de alkalmazható akkor is, ha a két fél ugyanabból a szervezetbıl való. A szabvány olyan folyamatokat, tevékenységeket és feladatokat tartalmaz, amelyeket úgy alakítottak ki, hogy a konkrét projektek esetén illeszthetık legyenek. Az illesztés a nem alkalmazandó folyamatok, tevékenységek és feladatok törlését jelenti. Ez a szabvány szolgált alapul a következı részben bemutatott képesség-érettségi modellek folyamat-dimenziójának kialakításához. A szabvány részletesebb bemutatását a 10.3 melléklet tartalmazza. 16

17 3.1. Érettségi és képességi modellek A beszerzéssel, beruházásokkal foglalkozó szakemberek nem elégedtek meg az ISO 9001 által felkínált minıségi megközelítéssel. A továbblépésre az adta az impulzust, hogy nagy (és elsısorban az amerikai hadiiparhoz kapcsolódó) cégek szerették volna szoftverbeszállítóik munkáját átláthatóvá tenni, csökkentve ezáltal annak kockázatát, hogy a beszállítandó termék nem készül el idıben, vagy nem lesz megfelelı minıségő. Az 1980-as évek végén kutatás indult annak vizsgálatára, hogy milyen módszerrel lehetne osztályozni a szoftvergyártó cégeket. Általában a képességi-érettségi modelleket a szoftvergyártásban részt vevı folyamatok fejlesztésére használják (ebben, áttételesen, a szervezeti érettség fejlesztése is benne van), a szakirodalomban szokássá vált a képességi-érettségi modelleket folyamatfejlesztési vagy folyamatjavítási modellként is emlegetni. A folyamatfejlesztési megközelítések, modellek csoportokba sorolhatók attól függıen, hogy a fejlıdés szakaszosan (lépcsıkben, egyszerre több folyamat), vagy folyamatos (általában egy folyamatra fókuszálva), kisebb lépésekben történik. A folyamatjavítási modellek között vannak lépcsıs modellek (staged models), pl. CMM, folytonos modellek (continuous models), pl. a SPICE, Automotive SPICE, és integrált modellek, pl. CMMI. A lépcsıs modellek a teljes szervezetet vizsgálják. A vezetési és mőszaki folyamatokkal, az alkalmazott technológiával, és magával a szervezettel foglalkoznak. Adott érettségi szinten a szervezetnek bizonyos, a modellben elıre definiált folyamatokat kell mőködtetnie. A folytonos modellek az egyes folyamatokra (és nem a teljes szervezetre) koncentrálnak, folyamatokra állapítanak meg képességi szinteket bizonyos jellemzık alapján, és útmutatást adnak a folyamatok meghatározására és folytonos továbbfejlesztésére. Az ilyen modell alkalmazója maga döntheti el, hogy milyen folyamat érettségét szeretné vizsgálni. A kombinált, integrált modellek ötvözik a kétféle megközelítést, a bizonyítottan hasznos elemeket kiválasztva. A szervezet bizonyos érettségéhez bizonyos folyamatoknak bizonyos, elıre meghatározott képességi szintje szükséges. A közigazgatási folyamatok felmérése során célszerő az érettségi és képességi modellekben alkalmazott egységes definíciókat, meghatározásokat és irányelveket felhasználni, annak ellenére, hogy elsıdlegesen szoftver-fejlesztési területen elterjedtek, jelentıs többletet (elméletben és gyakorlatban egyaránt) biztosítanak más területeken is a folyamatokra, folyamatfelmérésre vonatkozóan. Ezért ajánlásunkban fontosnak tartottuk megjeleníteni egyes részleteiket, megközelítéseiket. Mindegyik kategóriából egy-egy igen ismert, példaként már említett modellt mutatunk be a mellékletben: a lépcsıs CMM modellt a fejezetben, a folytonos SPICE modellt fejezetben, és az integrált CMMI modellt a fejezetben. 17

18 3.2. Folyamat típusok és folyamat alapelemek Az e-közigazgatási folyamatok meghatározása és dokumentálása során igen fontos, hogy egységes szemlélet alakuljon ki a folyamatok típusaira, lehetséges folyamat-csoportokra, illetve folyamat-alapelemekre vonatkozóan. Az egységes szemlélet alapján lehet majd a különféle, közigazgatásban alkalmazott folyamatokat konzisztens módon meghatározni és úgy leírni, hogy a meghatározott, dokumentált folyamatok, folyamatcsoportok vagy folyamatelemek jó alapját képezzék a szolgáltatás-orientált architektúrán alapuló szemlélet kialakításának. A továbbiakban ehhez az egységes szemléletmódhoz kívánunk támpontokat adni, a lehetséges folyamat-típusok, folyamat-csoportok, valamint folyamat alapelemek bemutatásával. A 3.1 részben felsorolt, és a 10. fejezetben bemutatott modellek mindegyike útmutatást ad a folyamatok meghatározására, elemeik azonosítására. Ez az útmutatás minden esetben meghatározza a modellt alkalmazó szervezet fontosnak ítélt folyamatait, azokat bizonyos csoportokba sorolja. A folyamatcsoportok modellenként különbözı elnevezést kaptak. Elmondható viszont, hogy általában a következı folyamat típusokat/csoportokat azonosítják a folyamatmeghatározási és folyamatfejlesztési modellek: Projektirányítási folyamatok Szervezeti folyamatok Támogató folyamatok Mőszaki folyamatok. Egyes modellek azonosítanak még beszerzési, infrastruktúrával kapcsolatos, újrafelhasználással kapcsolatos, mőködtetéssel/szolgáltatással kapcsolatos folyamatokat is. A felsorolt folyamatfejlesztési modellek folyamat-típusaiból a közigazgatási folyamatokat mőködtetı szervezeteknél is jól használható az összes projektirányítási, szervezeti és támogató folyamat. A folyamatmeghatározási és folyamatfejlesztési modellek mindegyike tartalmaz útmutatást a folyamatok különbözı, meghatározandó és fejlesztendı elemeire vonatkozóan. Az útmutatás egyes esetekben kevésbé részletes (az elemek meghatározása a felhasználóra van bízva, pl. a CMM esetében). A SPICE és a CMMI viszont pontosan leírják, milyen elemek azok, amelyek a folyamat meghatározásához elengedhetetlenek, és melyek azok az elemek, amelyek a folyamat magasabb képességi szintjére utalnak. Ezek szerint, a folyamatokat a következı elemek jellemzik: jól meghatározott input, jól meghatározott output, jól megfogalmazott cél, a folyamat tevékenységeinek pontos leírása, a tevékenységek elvégzéséhez szükséges felelısségek, hatáskörök és kompetenciák azonosítása és biztosítása, a folyamat követésére beiktatott ellenırzési pontok, a pontosan megfogalmazott teljesítmény-elvárások, a folyamat metrikák. Minél több elem van a helyén egy adott folyamat esetében, annál magasabb az adott folyamat képességi szintje. A folyamat képességének felmérésekor a következıket vizsgálják: Az egyéni folyamatokhoz tartozó eljárásokat végrehajtják-e (legalább informálisan)? A folyamatot megfelelıen tervezték-e? Követik-e a tervet? 18

19 Ellenırzik-e a végrehajtást? Követik-e a végrehajtást és hoznak-e korrekciós intézkedéseket? Szabványosított-e a folyamat? Értik-e a folyamatot mennyiségileg is? Folyamatosan javítják-e a folyamatot? A Mellékletek fejezetében mutatjuk be részletesen a képességi szinteket, itt most a meghatározott folyamat jellemzıinek rövid leírására szorítkozunk. A folyamatok lehetséges képességi szintjei: 0. szint: nem végrehajtott folyamat. 1. szint: végrehajtott (folyamat). 2. szint: menedzselt folyamat. 3. szint: meghatározott folyamat: a folyamatot a szervezetben meghatározták (dokumentálták), elkészült a folyamat szervezeti szinten érvényes szabványos leírása, és a sajátos esetekben a folyamatot a szabványos folyamatból szabják testre, a szintén dokumentált testreszabási útmutatók alkalmazásával. A meghatározott folyamatot a szervezet egészében bevezették, és győjtik a visszajelzéseket a szabványos folyamatra vonatkozóan. Magasabb szinten valósul meg a folyamathoz rendelt erıforrások kezelése is. Megtörténik az emberi erıforrás kompetenciájának meghatározása, a folyamat infrastrukturális követelményeinek meghatározása, megfelelı képességő emberi erıforrások biztosítása és a megfelelı infrastruktúra biztosítása. 4. szint: jósolható folyamat. 5. szint: optimalizáló folyamat. Egy meghatározott képesség szintő folyamat elemei: Cél Input Bemeneti (entry) kritériumok Tevékenységek Szerepek Mérıszámok Ellenırzési lépések Output Exit kritériumok Véleményünk szerint egy meghatározott képességő folyamat - jellemzıibıl adódóan - jól és hatékonyan automatizálható, ezért tartottuk fontosnak rövid bemutatását. Javasoljuk, hogy a folyamatfelmérés során törekedjünk a jellemzık minél teljesebb körő azonosítására A közigazgatási folyamatok típusok és folyamat elemek A 2007-ben készült a állami feladatok katasztere és a hozzátartozó útmutató dokumentum (lásd [B13]) útmutatást ad a állami feladatok kataszterének, értelmezéséhez, és hasznosításához, a kataszter és a folyamatok kapcsolatának megértéséhez. Számos olyan információt is ad, amelybıl arra következtethetünk, milyen típusú folyamatokat azonosítottak a közigazgatásban, s ezeknek mely elemeit tekintik fontosnak. 19

20 A ROP Programigazgatóság keretében készült el, szintén 2007-ben, Az ügyintézés modellezése c. tankönyv (lásd [B29]) a köztisztviselık továbbképzésére. A projekt léte, valamint a tankönyv és kapcsolódó anyagok elkészítése is mutatja, hogy a közigazgatásban szükségszerőségként jelent meg a folyamatok / ügyintézés meghatározása, modellezése. Ez az anyag foglalkozik, többek között, a közigazgatás mőködésének társadalmi környezetével, az elektronikus technológiaváltás és a közigazgatási folyamatok kapcsolatrendszerével, a közigazgatási munkafolyamatok jellegzetességeivel, az ügymenet-modellezés céljával, szerepével és vizsgálatának módszerével, valamint a közigazgatásban, gyakorlatban alkalmazható folyamatszervezéssel. Ez az anyag sok olyan kérdést érint, amelyekkel jelen dokumentumban is foglalkozunk, azoknak kiváló, közigazgatási szemlélető alapját adva. A különbség a jelen módszertan és az idézett anyag között fıleg a megközelítésmódban van. Az ügyintézés modellezése közigazgatási oldalról közelít, a közigazgatási folyamatok számítógépes támogatását szükségesnek tekinti, de nem foglalkozik az informatikai folyamatok sajátosságaival. A jelen anyag a közigazgatási folyamatok azonosításának, meghatározásának és fejlesztésének lehetıségét elsısorban azzal a céllal vizsgálja, hogy a számítógéppel / IT-vel támogatható részeket azonosítsa, és a SOA-szemlélető közigazgatási architektúra kialakítását segítve határozza meg a közigazgatás fontos folyamatait/folyamatcsoportjait vagy folyamatelemeit. Ebben az alfejezetben a továbbiakban a fentebb meghivatkozott anyagokból emelünk ki néhány elemet. Véleményünk szerint, a jelen anyag és az itt meghivatkozott anyagok egymást kiegészítı használata lehetséges, elıremutató megoldás. A közfeladatok felülvizsgálatának (az elıbbiekben hivatkozott, [B13] dokumentumok elkészítésének) célkitőzéseit az alábbi ábra szemlélteti. 7. ábra: A közfeladatok felülvizsgálatának részletes célkitőzései. Forrás: [B13] 20

21 Az állam által ellátott feladatok kataszterének felállítása elengedhetetlen volt ahhoz, hogy felül lehessen vizsgálni a közfeladatokat. A feladatkataszter egységes felépítését, logikáját az alábbi ábra szemlélteti. 8. ábra: Az Állami feladatkataszter felépítése. Forrás: [B13] A feladatkataszter(ek) összeállítására minisztériumonként került sor. Egy minisztérium esetében a több ágazatot átívelı felsı szintő irányítási feladatok a kormányprogram illetve a minisztériumi stratégia kidolgozását, a fejezeti gazdálkodással kapcsolatos feladatokat, a szakterület mőködtetéséhez szükséges intézményrendszer kialakítását és a szakterületeket átfogó kontrolling funkciókat tartalmazzák. A valódi közfeladatok az ábra középsı részén találhatók. A közfeladatok ellátása egy-egy tárcához kapcsolódóan több szakterületen folyik. Minden szakterület esetében vannak standard irányítási és igazgatási feladatok, amelyek struktúrája azonos, belsı tartalma szakterületenként eltérı. A szakterületi közfeladatok minden ágazat esetében speciálisak, a felülvizsgálat ezekre összpontosított. A szakterületi közfeladatok részletesen, minisztériumonként feladatcsoportban és azon belül több száz vagy ezer feladatban, tevékenységben kerültek kifejtésre. A támogató feladatok nem közfeladatok. Ide tartozik az intézményi irányítás, igazgatás, az intézményi gazdálkodás, a humán erıforrás menedzsment, az informatikai, a jog, a vagyongazdálkodás, a belsı ellenırzés és a kommunikáció feladatai. A feladatkataszter kidolgozása során a minisztériumok lebontották az általuk végzett vagy az ágazatukhoz tartozó összes közfeladatot, és egységes struktúrába szervezték azt, megadva minden közfeladat esetében a feladat nevét, tartalmát és a feladat létét indokoló jogszabályi hivatkozást és/vagy költségvetési sort. A feladatkataszter maximális 7 szint mélységő lehetett. Az egyes szintek a következık voltak: 1. szint: Ágazat 2. szint: Szakterület (pl. Lakásügy) 3. szint: Csoportosítási szint (pl. Lakástámogatások és lakásgazdálkodás 4. szint: Feladatcsoport (pl. Lakástámogatási rendszer mőködtetésével kapcsolatos feladatok) 5. szint: Feladat: (pl. Központi lakástámogatási rendszer mőködtetése) 21

22 6. szint: Tevékenység 7. szint: Mővelet Az alábbi táblázat mutatja be, hogy minisztériumonként hogyan néz ki a feladatkataszterek elemeinek számossága. 9. ábra: A feladatkataszterek elemeinek száma minisztériumonként. Forrás: [B13] Tevékenység és mővelet definiálására nem minden esetben került sor, de az 5., feladat szintig minden ágazati feladatlista tartalmazza a feladatok lebontását, így a állami feladatok kataszterében is csak az 5. szintig bontva szerepelnek az állami feladatok. A Feladatkataszterben szereplı, azonosított állami feladatok felhasználhatók az Elektronikus közigazgatási keretrendszerben. Véleményünk szerint, a Feladatkataszterben azonosított folyamatokat felhasználva, azok SOA-alapú megközelítést is támogató meghatározásában, dokumentálásában és modellezésében a továbbiakban bemutatott módon haladva, lépésrıl lépésre alakítható ki a magyarországi e-közigazgatásban alkalmazott folyamatok / folyamatcsoportok / folyamat-elemek halmaza. 4. A folyamatleírás/azonosítás tervezése Ebben a fejezetben a folyamatleírás / azonosítás tevékenységeinek lépéseit mutatjuk be. Lényeges üzenete ennek a fejezetnek, hogy a folyamatok azonosítása és dokumentálása komplex szakmai feladat, amelyet projekt-szerő mőködéssel lehet a leghatékonyabban elvégezni. Fontos tehát, hogy a folyamatleírás / azonosítás tevékenysége megfelelıen elıkészített, tervezett legyen, a megfelelı erıforrásokkal rendelkezzen, és a tervnek megfelelıen, ellenırzött módon kerüljön végrehajtásra. Fontos, hogy saját szükségleteink alapján tervezzük meg a folyamatleírás kidolgozását. A felmérési tevékenység tervezése során a következı feladatok azonosíthatóak: a) A felmérés céljainak meghatározása. b) A szakirodalom, jogszabályi háttér feldolgozása. c) A fogalmak meghatározása és a fogalmi elemzés. d) Az adatgyőjtési módszerek kiválasztása és kidolgozása. e) A felmérésben érintettek azonosítása. f) A felmérés idıtartamának tervezése. 22

23 g) A felmérés megvalósítás megtervezése. h) Terv készítés az adatok rendszerezésére és feldolgozására. i) Az eredmények értelmezési módjának meghatározása. j) A felmérési terv véglegesítése. A tervezéssel kapcsolatosan minimális követelmény, hogy történjen meg: a cél meghatározás, a résztvevık azonosítása és az idı- és erıforrás-tervezés. A tervezési folyamat fıbb lépéseit a 10. ábra szemlélteti, a folyamat leírását jelen fejezet további részei tartalmazzák. 10. ábra: Folyamatleírás tervezése 4.1. A felmérési cél meghatározása és források feltárása A folyamatfelmérés tervezésének elsı lépése a felmérés céljának meghatározása. Javaslatunk, hogy a felmérési célok meghatározása során törekedjünk jól definiált, konkrét és a lehetıségekhez mérten 1-2 kiemelt cél azonosítására. A kiemelt célok igény szerint priorizálhatóak és alábonthatóak. A célmeghatározás során két megközelítési mód közül is választhatunk: pozitív célmeghatározás során az elérendı célt definiáljuk (pl.: célunk az adószám igénylése újszülött részére folyamatfelmérése), negatív célmeghatározás kapcsán azt definiáljuk, hogy mi nem cél vagy mit nem tekintünk célnak (pl.: jelen felmérésünknek nem célja az adókártya kiállítás folyamatának feltárása). A célkitőzéssel járó kockázatokat (például: szubjektivitás, általánosság, publikáció hiánya) csökkenteni kell. A kockázat csökkenthetı kis létszámú célmeghatározó mini-csapatok kialakításával vagy rendszeres megbeszélésekkel a tervezés során. 23

24 Kialakított célrendszerőnkhöz rendeljük hozzá a megvalósításhoz szükséges módszereket (pl.: interjúztatás, esettanulmány), eszközöket (pl.: kérdıíves felmérés - hardver, szoftver eszközigény). Ha egy folyamat jellemzıit tárjuk fel, biztosítani kell annak mérhetıségét, és a kapott adatok regisztrálását egy reprezentatív mintán. Ha osztályozási céljaink vannak, biztosítanunk kell mindazoknak a jellemzıknek a mérhetıségét egy-egy reprezentatív mintán, melyek alapján a klasszifikációt el szeretnénk végezni. A célokból kiindulva a tervben meg kell fogalmazni, hogy: melyik folyamatot mérjük fel (célfolyamat); ki adhatja számunkra a megfelelı adatokat, információkat (megcélzott információforrások); milyen módszerrel szerezzük be az információkat; hol és mikor győjtjük/győjthetjük be az információkat. A tervezés elsı fázisában a cél és célfolyamat meghatározása után fontos az információforrások körének meghatározása. Az információforrás az alkalmazott felmérési módszertıl, módszerektıl függıen személy, dokumentum (elektronikus, nyomtatott) és/vagy multimédiás anyag egyaránt lehet. Minden adatgyőjtéssel kapcsolatos döntés befolyásolja az adatok felhasználhatóságát. Ez azért fontos, mert: az információ feltáró módszerek eltérı módon képesek az adatok begyőjtésére; az idı és a hely is befolyásoló tényezıvé válhat. A források vizsgálati köre lehet: teljes körő mintavételen alapuló (reprezentatív minta). A teljes körő feltárás általában rendkívül idıigényes, költséges, és túlbonyolítja az információ megszerzését, de egyben a legpontosabb és legrészletesebb képet adja. A reprezentatív minta segítségével gyorsabbá és hatékonyabbá tehetı a feltáró munka, ezért javasoljuk a felmérést reprezentatív mintán végrehajtani. A reprezentatív minta számos elınye, csak a megfelelı mintavételezéssel élvezhetı, ennek meghatározása komoly feladat. Ezért a tervben a minta jellemzıit is (mérete, homogenitása-inhomogenitás mértéke, stb.) meg kell állapítani. A mintavétel alkalmával olyan módszert kell alkalmazni, amely biztosítja: hogy a teljes sokaság minden egyede megfelelı esélyekkel juthasson be a reprezentatív mintába; a jellemzık változatosságából adódó torzítás minimalizálását. A mintavétel során négy kulcskérdést kell megoldani: a minta nagyságának meghatározását, a minta reprezentativitását és paramétereit, a mintába foglalt egységek elérhetıségét, a mintavétel stratégiai lépéseit.[b30] A reprezentatív minta feladata, hogy a sokaság egészét jellemezze (ez nem egy része a sokaságnak). A mintavétel lehet véletlen és nem véletlen alapú. A folyamatleírások kidolgozásánál a nem véletlen alapú mintavételezésre fektetjük a hangsúlyt. Ezek a mintavételi módok akkor használhatók, amikor a felmérést végzı vizsgálatával megcéloz egy csoportot és nem is célja, hogy az reprezentálja a teljes alapsokaságot. Ide tartoznak: 24

25 a tetszıleges mintavétel [F37], a quota mintavétel [F30], a szándékos mintavétel, a többdimenziós mintavétel [F38], a hólabda mintavétel [F9]. Véleményünk szerint a folyamatleírások készítése során sikerrel és hatékonyan alkalmazható: a szándékos mintavételi, valamint a hólabda mintavételi eljárás. Szándékos mintavétel: a mintába az egyedek a felmérı döntése alapján kerülnek be, tulajdonságaiktól függıen. Az eredmények reprezentativitása ebben az esetben is problematikus lehet. [B42] Tipikusan ezt a mintavételi módszert használjuk interjúalanyok kiválasztására. Általában munkakör, feladatkör, önéletrajz alapján kiválaszthatóak a megfelelı interjúalanyok. Hólabda mintavétel: a kutató meghatároz néhány egyedet, akik rendelkeznek a megfelelı tulajdonságokkal. İket sorra kérdezi, majd a megkérdezettek nyújtanak információt az újabb kérdezhetı egyedekrıl. [B42] Ez a mintavételezési eljárás a dokumentum átvizsgálás során kerül elıtérbe illetve a felkészülés szakaszában a jogszabályi és szakirodalmi háttér feltárása során. Javasoljuk, hogy mintavétel során az információforrás mintába történı kiválasztásnál vegyük figyelembe a forrás: folyamathoz való kötıdésének mértékét, naprakészségét (azaz mennyire aktuális), megbízhatóságát, elérhetıségének mértékét. A hólabda mintavételi eljárás az informális folyamatok meghatározásánál alkalmazható. Ebben az esetben a tervezés során figyelembe kell venni: a források száma kevésbé pontosan határozható meg elıre, a források azonosítása jellemzıen folyamatos iterációval történik. A minta kialakítását követıen azonosítani kell az érintetteket A résztvevık, érdekelt felek azonosítása Sikeres folyamatfelmérés elképzelhetetlen az érdekelt felek ([F6]) azonosítása és bevonása nélkül. A tervezésénél célszerő táblázatos formában összefoglalni az érdekelteket, igényeiket és elvárásaikat. Az érdekeltek közül definiálni kell legalább az alább felsorolt résztvevıket: az információ felhasználóját (végfelhasználót is, ha az információt továbbítjuk); az információ gazdát/hordozót (pl.: interjúalanyokat, szakértıket); a szervezésében érintetteket; a tervet megvalósító (végrehajtó) személyeket. Az érintettek részére biztosítani kell a visszacsatolás (feedback) lehetıségét és el kell nyerni elkötelezettségüket a terv végrehajtásával kapcsolatosan. Célravezetı, ha: az írásosság elvét alkalmazzák (pl.: interjún elhangzottakat írásban rögzítik); 25

26 az érintettek visszajelzést kapnak az eredményekrıl (pl.: összefoglaló, prezentáció keretén belül); a feltáró munka célja, lefolyásának menete és az információk felhasználásának módja ismert az érdekelt felek számára; a tervezésénél és végrehajtásnál cél a hatékonyság (pl.: felhasználható idıkeret meghatározása). Az érdekelt felek azonosítása, bevonása és elvárásaik ismerete biztosítja a nyert információk felhasználhatóságát és értelmezhetıségét Idı és erıforrás tervezés A felmérés/azonosítás tevékenységeihez rendeljünk erıforrásokat és tervezzük meg a várható idıigényeket is. A tevékenységeket az elvégezhetıség alapján rendezzük sorba, határozzuk meg a párhuzamosan is végezhetı és az egymástól függı feladatokat. Számolni kell a zavaró tényezıkkel és idıbeli csúszásokkal is. A felmérés folyamatai közötti kapcsolat létrehozásában segíthet a következı kérdések egyikének feltevése: Mit kell tenni, hogy e tevékenységet indíthassuk? (Top-down megközelítés) Mit lehet tenni most, hogy e tevékenység befejezıdött? (Bottom-up megközelítés) Az alábbi lépések végrehajtása a tervezés módszertanától, megközelítésétıl függetlenül végrehajtandóak: tevékenységek számba vétele tevékenységek idıszükségletének számba vétele tevékenységek kapcsolatainak számba vétele tevékenységek erıforrás-szükségletének számba vétele a megvalósítandó folyamat elemzése. Az ütemezés során számolni kell a következı veszélyekkel: nem tartható idıket rendelünk egy-egy feladathoz (pl.: csak az interjúztatás idejével számolunk, az adminisztrációs, technikai idıket figyelmen kívül hagyjuk), tartalék nélkül vagy túl sok tartalékkal számolunk (pl.: egy dokumentum átvizsgálására kevés idıt tervezünk, mert a dokumentum komplexitását figyelmen kívül hagytuk, nem ismertük), túl sok alternatív tervet dolgozunk ki (pl.: az alternatíva kiválasztásához külön döntési mechanizmus szükséges), nem vizsgáltuk meg más párhuzamos, konkuráló (pl.: másik folyamatfelmérés) tevékenységek ütemezését, az ütemezést nem aktualizáljuk, az eltéréseket nem vezetjük át (pl.: nincs felelıse a tervnek, így nincs karbantartója sem). Az ütemezési technikák közül a progresszív (idıben elırehaladó) ütemezés és a retrográd (idıben visszafelé haladó) ütemezés alkalmazása egyaránt elfogadható. Javasoljuk mérföldkövek alkalmazását például: felkészülési szakasz lezárásakor, interjúztatás, dokumentum átvizsgálás megkezdésekor, befejezésekor, 26

27 visszajelzések, kiegészítı információk beszerzésének lezárásakor, az elemzés befejezésekor. Tevékenységlista, tevékenységek idıtartama, a tevékenységek logikai sorrendje alapján célszerő Gannt-diagramon áttekinthetıvé tenni a tervet. Kritikus út meghatározása szükségessé válhat kis lét-/ darabszámú minta, illetve szőkös erıforrások esetén. Itt jegyezzük meg, hogy kritikus út tervezés esetén retrográd ütemezés alkalmazását javasoljuk a közös megközelítési szemléletmód miatt. Saját tapasztalataink alapján elmondható, hogy egy folyamatfelmérs tervezése projektmenedzsment eszközök (pl.: szoftver - Ms Project, ConceptDraw Project) használatával teljes mértékben lefedhetıek, de átgondolt táblázatok (feladatok alábontása, idıigények összegzése, ütemezése) és szöveges állományok használatával egyaránt tökéletesen kivitelezhetı terv készíthetı. A tervezés befejezését követıen kezdıdhet meg az információgyőjtés. 5. Az információgyőjtés Az adatgyőjtés során az elméleti megközelítés összekapcsolódik a valósággal, ellenırizve a valóságról alkotott elmélet helyességét. A létrejött elképzelés alapján megállapítjuk azokat a tényeket, amelyek érdekelnek bennünket és a körülményeket, amelyekre figyelve az adatokat győjteni fogjuk. A következı lépés az információgyőjtési módszer kiválasztása, amely segítségével tapasztalati kapcsolatot állítunk.[b43] Ebben a fejezetben a módszertan által javasolt szükséges információgyőjtési módszereket és azok alfajait foglaljuk össze. A jelen módszertanban javasolt információgyőjtési módszerek (a 11. ábra tünteti fel ıket): 27

28 11. ábra: Információgyőjtés A közigazgatásban mőködı folyamatokkal kapcsolatos információk begyőjtése az itt bemutatott információgyőjtési technikák kombinálásával javasolt. Mindenképpen győjtsünk információt a közigazgatásban dolgozóktól és az ı munkájukat támogató szakemberektıl (pl.: folyamatszervezık, IT szakemberek). Lehetıségeinkhez mérten próbáljuk meg bevonni a folyamat érdekelt feleit (pl.: a folyamat ügyfelét ), növelve a valószínőségét annak, hogy választ kapunk arra a kérdésre, mely közigazgatási folyamatok/folyamat elemek/folyamat csoportok IT-vel való támogatása lenne célszerő A vonatkozó jogszabályok azonosítása és feldolgozása A jogszabályi háttér ismerete elengedhetetlen az információgyőjtés során. A jogszabálykutatás alapvetı célja, hogy információkat szolgáltasson a szervezet elektronikus közigazgatást érintı szabályozási, szervezeti, mőködési környezetérıl, viszonyairól, és az azokban szükséges változtatásokról. A jogszabályok kutatását egészíti ki a szervezet belsı normáinak elemzése, amely a szervezet felépítése, a mőködési környezet, az iratok kezelése valamint a releváns munkamódszerek tekintetében nyújt nélkülözhetetlen adatokat. A jogszabályi háttér vizsgálata során azonosítani kell a vonatkozó: törvényeket, Országgyőlési határozatokat, minisztériumi és kormányrendeleteket, önkormányzati rendeleteket. A feltárt jogszabályok és belsı normák részletes és alapos vizsgálatához szükség van arra, hogy a mindenkori legfrissebb, tehát a vizsgálatkor hatályos normák a rendelkezésre álljanak. Fontos azt is figyelembe venni, hogy a már érvényes, de még nem hatályos jogszabályok, szabályzatok, vagy azoknak még el nem fogadott, csak javaslat formájában létezı változatai hatással lesznek-e az elektronikus közigazgatás megvalósítására. A jogszabályok vizsgálatánál figyelembe kell venni a már megvalósított elektronikus eljárásokat, továbbá azt is, hogy a többi eljárás körében melyek azok, melyek elektronizálásának nincs jogszabályi akadálya. A különbözı az e-közigazgatás szempontjából releváns normák elemzésénél vizsgálni kell, hogy azok mennyire érthetıek, egyértelmőek, pontosan meghatározottak. Az e- közigazgatás egységes terminológiáján túl fontos, hogy az e-közigazgatással kapcsolatba kerülı más normák is azonos kifejezéseket használjanak azonos jogintézményekre. A jogszabályok egyértelmőségének, teljességének vizsgálatára azért is különösen nagy súlyt kell helyezni a közigazgatási folyamatok informatikai támogatásának bevezetésénél, az elektronikus közigazgatás megvalósításánál, mert manuális ügyintézés esetén még számítani lehet az ügyintézı jóhiszemő jogalkalmazására a jogszabályi hiányosságok, pontatlanságok áthidalása érdekében, de a folyamatok automatizálása általában kizárja ilyen kreatív megoldásokat. Törekedni kell az alá-fölé rendeltségi viszonyok megállapítására. Tisztázni kell, hogy melyek azok a szervezeti egységek, melyek hatáskörébe hatósági ügyek tartoznak, melyek azok, amelyeknél szükséges lehet IT támogatás kialakítása (pl. belsı nyilvántartások, 28

29 szervezetirányítási rendszerek stb.). Az IT rendszer alkalmassága az elektronikus ügyintézés megvalósítására növeli a szervezet lehetıségeit az elektronikus ügyintézés hatékony megvalósítására. Általában az elsıdleges feladat azon szakterületi szabályozási dokumentumok összegyőjtése, amelyek kimondottan az informatikai támogatással ellátandó, automatizálandó eljárásokhoz kapcsolódnak. Az egyes közigazgatási eljárások folyamatát általában a jogszabályok szigorúan szabályozzák, ezért a legtöbb információ pusztán a jogszabályok elemzésével is begyőjthetı, így a késıbbi interjúk alkalmával csak a helyi sajátosságokat (pl. az adott ügyben eljárni jogosult szervezeti egység neve, a feladatok ügyintézık között megosztása, az ügyben fizetendı illeték/igazgatási szolgáltatási díj megfizetésének módja, lehetıségei, esetleges nem világos rendelkezések tisztázása) kell megkérdezni. A vonatkozó és releváns ágazati jogszabályok összegyőjtéséhez a szervezet kapcsolattartóiként megjelölt illetékes munkatársainak segítségét kell kérni. Az adott szerv segítsége nélkül a jogszabálynak nem minısülı belsı normák nem ismerhetık meg, hiszen ezek többnyire vezetıi utasításokban találhatók, amelyek a szerv belsı körülményeit, mőködését szabályozzák, nyilvánosan nem elérhetık. A jogszabályok listája általában megtalálható az adott szerv (vagy a szervet felügyeletét ellátó szerv) honlapján is. Ezen kívül a jogszabálykeresıkben a megfelelı tárgyszavak begépelésével (az adott szervezet neve, az elektronikus ügyintézés bevezetését tárgyát képezı eljárások megnevezése) a megvizsgálni szükséges jogszabályok megtalálhatóak. Nem elég azonban csak az ágazati, szakterületi jogszabályokat és egyéb normákat felderíteni és tanulmányozni, hanem ismerni kell mindazon általános jogszabályokat is, amelyek a vizsgálandó folyamatokkal kapcsolatosan valamilyen relevanciával bírnak. Így például a közigazgatási ügyintézéshez szorosan kapcsolódik az iratkezelés (érkeztetés, iktatás, szignálás, kiadmányozás, postázás stb.) területe, ezért az ezzel kapcsolatos jogszabályok, ill. szerv iratkezelési szabályainak alapos tanulmányozása is nélkülözhetetlen a hatékonyan mőködı elektronikus rendszer bevezetéséhez. Nyilvánvaló, hogy az elektronikus ügyintézéssel, elektronikus dokumentumokkal, elektronikus aláírással kapcsolatos jogszabályok rendelkezéseit is figyelembe kell venni, ha informatikai eszközökkel kívánunk támogatni közigazgatási folyamatokat. Az adatvédelem, titokvédelem nagyon sok közigazgatási eljárásnál szerepet játszik, és bár az ezekre vonatkozó alapnormák azonosak a manuális és az elektronikus ügyintézés esetén, az informatikai megoldások sajátos gyakorlati megfontolásokat kívánnak. Az adatvédelmi biztosnak és az Alkotmánybíróságnak is vannak speciálisan az elektronikus megoldásokra vonatkozó állásfoglalásai, határozatai ebben a témában, amiket ismerni kell. A teljesség igénye nélkül feltüntetünk néhány, a jogi szabályozásra vonatkozó forrást. Magyar Közlöny ( ( Complex CD Jogtár A legfontosabb vonatkozó jogszabályok: évi XC. törvény az elektronikus információszabadságról; évi CXL. törvény a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól; évi XXXV. törvény az elektronikus aláírásról; 29

30 1995. évi LXVI. törvény a köziratokról, a közlevéltárakról és a magánlevéltári anyag védelmérıl; évi LXIII. törvény a személyes adatok védelmérıl és a közérdekő adatok nyilvánosságáról 335/2005. (XII.29.) Korm. rendelet a közfeladatot ellátó szervek iratkezelésének általános követelményeirıl; 193/2005 (IX.22.) Korm. rendelet az elektronikus ügyintézés részletes szabályairól; 194/2005. (IX.22.) Korm. rendelet a közigazgatási hatósági eljárásokban felhasznált elektronikus aláírásokra és az azokhoz tartozó tanúsítványokra, valamint a tanúsítványokat kibocsátó hitelesítés szolgáltatókra vonatkozó követelményekrıl; 195/2005. (IX.22.) Korm. rendelet az elektronikus ügyintézést lehetıvé tévı informatikai rendszerek biztonságáról, együttmőködési képességérıl és egységes használatáról; 18/2005. (XII. 27.) IHM rendelet a közzétételi listákon szereplı adatok közzétételéhez szükséges közzétételi mintákról; 13/2005. (X. 27.) IHM rendelet a papíralapú dokumentumokról elektronikus úton történı másolat készítésének szabályairól; 12/2005. (X. 27.) IHM rendelet az elektronikus ügyintézési eljárásban alkalmazható dokumentumok részletes technikai szabályairól; 24/2006. (IV. 29.) BM-IHM-NKÖM együttes rendelet a közfeladatot ellátó szerveknél alkalmazható iratkezelési szoftverekkel szemben támasztott követelményekrıl; 305/2005. (XII. 25.) Korm. rendelet a közérdekő adatok elektronikus közzétételére, az egységes közadatkeresı rendszerre, valamint a központi jegyzék adattartalmára, az adatintegrációra vonatkozó részletes szabályokról; A vizsgálat tárgyát képezı szerv alábbi belsı normáit célszerő megvizsgálni: Szervezeti és mőködési szabályzat (SzMSz) (általában jogszabály tartalmazza); A szervezet feladatkörébe tartozó eljárások esetében az elektronikus ügyintézésre vonatkozó jogszabály és belsı szabályzatok; Ügyrend; Iratkezelési szabályzat; Irattári terv; Informatikai biztonsági szabályzat (IBSz); Kiadmányozási rend; ISO folyamatleírások; A minıségbiztosítási rendszerhez kapcsolódó szabályzat; Adatvédelmi szabályzat; stb Dokumentumok átvizsgálása Ebben a fejezetben a dokumentumátvizsgálás tevékenységet tekintjük át, a leírás a SEI SCAMPI A [B41] módszertani leírása alapján készült. A leírásban arra törekedtünk, hogy a dokumentumátvizsgálást röviden, de mégis jól bevált gyakorlatokkal gazdagítva mutassuk be. A folyamatok feltérképezéséhez szükséges információk jelentıs része kinyerhetı a rendelkezésre álló dokumentumokból, ezek tartalmazzák a legtöbb közvetlen bizonyítékot a 30

31 folyamatok gyakorlati mőködésére vonatkozóan. Éppen ezért, ha részletes rálátást szeretnénk a szervezet gyakorlataira, a dokumentumok átvizsgálása egy hatékony módszer lehet. A dokumentumátvizsgálók gyakran abba a hibába esnek, hogy mindet megpróbálnak elolvasni, annak érdekében, hogy a folyamatleíráshoz szükséges minden fontos információt megszerezzenek. A dokumentumok átvizsgálása igen idıigényes lehet, ha nem egy jól meghatározott céllal végezzük, vagy nem egy adott információt keresünk. A dokumentumok megfelelı átvizsgálásához szükséges lépések: Létre kell hozni (és karban kell tartani) egy dokumentumlistát, melybe azok a dokumentumok kerülnek, amelyeket át szeretnének vizsgálni. Ebbe a listába kerül bele minden olyan dokumentum, amely forrása lehet egy keresett információnak. A dokumentumokból származó információkat szemlézni kell (át kell nézni) és a szemle során meg kell határozni, hogy kinyert információk elfogadhatók-e vagy sem. Meg kell határozni, hogy a kinyert információk mely folyamatok értelmezésénél, feldolgozásánál, leírásánál stb. segíthetnek. Meg kell határozni, hogy az adott információ mely szervezeti egységhez tartozik (hatáskör, felelısség, végrehajtó stb.). Paraméterek és korlátok A dokumentum átvizsgálás az interjúkat támogatja, és abban segít, hogy láthassuk, hogy az interjún elhangzottak milyen formában valósulnak meg a gyakorlatban. Általában csak olyan dokumentumokat kell / érdemes átvizsgálni, melyek az átvizsgálási folyamatot megelızıen készültek. Opcionális lépések Azon szervezetnél, amely a dokumentumait egy (webes) dokumentumkezelı rendszerben tárolja, a szervezet egy tagja mutassa be az adott rendszert és dokumentumstruktúrát. A webes linkek helyességét az interjúk elıtt le kell ellenırizni, hogy a felmérı csapat zavartalanul végezhesse a munkáját. Az olyan eszközök, mint például kérdıívek, folyamatleírások, bemutatóanyagok hasznosak lehetnek a folyamatok feltárásnál. Megvalósítási tanácsok Keressük a folyamatok nyomait a dokumentumokban. A dokumentum átvizsgálás során nem szükséges minden egyes folyamathoz vagy gyakorlathoz pontosan egy dokumentumot találni. Egy dokumentum tartalmazhat információkat több folyamathoz vagy gyakorlathoz is. Érdemes még a felmérı csapat megérkezése elıtt a már létezı dokumentumokat egy listába felvenni és a folyamatokhoz illetve gyakorlatokhoz kötni. Számos, folyamatfejlesztést (is) végzı szervezetnél ez a hozzárendelés eleve elérhetı. Azoknál a szervezeteknél, amelyek nem kezelnek ilyen listát, a felmérést végzı csapatnak kell megtalálnia a kapcsolatokat, így a felmérést nyilvánvalóan több idıbe kerül végrehajtani. A dokumentumok három szintje A vizsgálat tárgyát képezı dokumentum három különbözı szintre sorolható: Szervezeti szintő, Projekt szintő, Megvalósítási szintő. A szervezet szintő dokumentumok rálátást nyújtanak a szervezet szintő irányelvekre, policy-kra, és a szervezeti szintő folyamatokra. Így sok esetben a csapatnak nem 31

32 szükséges feltennie bizonyos szervezeti szintő kérdéseket az interjúk során, ugyanakkor a segíthet konkretizálni a felmerülı kérdéseket. A szervezet projekt dokumentumainak átvizsgálása segít megérteni a szervezet projektjeivel és támogató csoportjaival szemben támasztott elvárásokat. A megvalósítási szintő dokumentumok átvizsgálása során a felmérést végzı csapattagok további rálátást nyernek a betervezett interjúalanyok szerepére az adott projektekben vagy támogató csoportoknál, de ugyanúgy világossá válik a szervezeten, projekten vagy támogató csoporton belül alkalmazott terminológia is. Ezen dokumentumok szemlézése, átvizsgálása lehetıséget ad az interjúkérdések finomítására illetve módosítására. A folyamat helyzetét vizsgáló tipikusan azért vizsgálja át a megvalósítás szintő dokumentumokat, hogy a más forrásból származó információkat validálhassa. Ilyen, más forrásból származó információk lehetnek például az interjún elhangzottak vagy magasabb szintő dokumentumok. Gyakran az ezen a szinten fellelhetı dokumentumok átvizsgálásával ellenırizhetı a szervezeti szintő gyakorlatok megvalósulása Az interjúk és az interjúztatás Az interjúztatás az információk átadása, megszerzése körül forog. Az interjúztatás a még nem ismert és nem publikált, eredeti adatok saját kutatási célra történı megszerzését jelenti, ezért a primer kutatások közé sorolják. A közigazgatási folyamatok leírásához az interjúk alkalmazását javasoljuk a folyamatfelmérés során, mert: közvetlen kapcsolat alakítható ki a folyamatszereplıi és a felmérést végzı személy között, a valós gyakorlat, folyamat hatékonyan feltárható, folyamatra fókuszált. Az interjúkat többféle módon csoportosíthatjuk. A továbbiakban néhány ilyen csoportosítási lehetıséget vázolunk Az interjúk csoportosítása formai jellemzık alapján Formai jellemzık alapján az interjúkat hat csoportba lehet sorolni [B8]. Standard interjúk esetében elıre elkészített kérdıív szolgál alapul, vagyis ugyanolyan módon kérdezünk minden megkérdezettıl. Alkalmazás: hasonló területő, szerepkörő folyamatok felmérése során, ha elegendı egy vagy kettı formalizált kérdıív kialakítása, amelyek gyors testreszabási lehetıségeket is tartalmaznak. Mélyinterjúk esetében a gondolati vázat határozzuk meg, s a megkérdezett egyéni véleményének kifejtését kérjük. Alkalmazás: új, még nem definiált, különálló folyamat, folyamatcsoport felmérésekor, ha várhatóan kevés számú interjú várható, pl.: vezetıi interjú. Írásos interjúk esetében az interjú alanya a kérdıívek, interjú anyagok kitöltését önállóan végzi, a kitöltést írásos útmutató mellett szóbeli segédletek is támogathatják. 32

33 Alkalmazás: automatizált feldolgozás, az idı rövidsége vagy nagy létszámú interjúalany szám esetén javasolt. Szóbeli interjúk esetében az interjú alanyát kérdezıbiztos, az interjút vezetı személy segíti végig az interjún. A kapott információt az interjúztatója vagy munkatársa rögzíti. Alkalmazás: folyamatfelmérés során tipikusan használható, akár standard vagy mélyinterjú formájában. Egyéni interjúk esetében az interjún egy alany vesz részt, az interjúztatók számára nem vonatkozik megkötés. Alkalmazás: folyamatfelmérés során tipikusan használható. A csoportos interjú esetében egyszerre több interjúalany vesz részt az interjún, így mód nyílik a személyes véleményeken túl a megkérdezettek (célcsoport) közötti viszonyok feltárására is (pl.: a véleményvezetık befolyásoló szerepe, alá-, fölérendeltségi viszonyok). Az interjú vezetıje/kérdezıbiztosa egy elızetes kérdéskör alapján dolgozik, de feladata, hogy olyan aspektusokat ismerjen meg a csoportos vita során, amelyek még nem ismertek és a késıbbi kvantitatív adatfelvétel alapját képezhetik. A csoportos interjúk vezetéséhez jelentıs szakértelem és gyakorlati tapasztalat szükséges. Alkalmazás: folyamatfelmérés eredményeinek ellenırzésére, formális informális felmérések során tipikusan használható. Javasoljuk a folyamatleírás véglegesítési szakaszában alkalmazni. Az interjúk csoportosítása céljuk alapján Céljuk alapján az interjúkat három csoportba lehet sorolni. Bevezetı interjú. Az interjú kapcsolat kialakítására szolgál, célja kutatási, elemzési területek, részterületek meghatározása, érintettek/érdekelt felek és elvárásaik azonosítása. Jellemzı alkalmazási terület: üzleti partnerek (beszállító, ügyfél, munkatársak, stb.), szervezeti egységek, projekttagok megismerése; elvárásaik tisztázása; új feladat, szakmai terület azonosítása. Jellemzı a nyitott kérdések túlsúlya. Javaslat: a folyamatfelmérés során a folyamatok, alfolyamatok közötti kapcsolatok gyors azonosítására, feltárására használjuk. Feltáró interjú. A feltáró interjúk alkalmazása indokolt adott vizsgálati területen meglévı szokások, gyakorlatok és egyedi jellemzık alapos megismerésekor, alkalmazni általában a vonatkozó szakirodalom áttekintése után célszerő. Cél a konkrét körülmények által szabott feltételrendszerben a mindennapi gyakorlat elemeinek azonosítása, a bevált folyamatok, gyakorlatok és módszerek feltárása és további egyedi jellemzık azonosítása. Továbbá a szakirodalomhoz és/vagy viszonyítási alaphoz képest tapasztalható releváns eltérések megismerése, azonosítása. Jellemzı az összetettség és a kérdések sokrétősége. Jellemzı alkalmazási terület: konkrét terület gyakorlatának megismerése; folyamatok, részfolyamatok megismerése; projekt feladatok, célok meghatározása; testre-szabási útmutatók készítése. Javaslat: adott folyamat elemzı felmérése esetén alkalmazzuk. Ellenırzı interjú. Ez a típus az elemzı, feltáró munka eredményeinek ellenırzésére, helytállóságának megállapítására és/vagy alátámasztására szolgál. Vizsgálhatjuk az elkötelezettséget adott tervvel, projekttel vagy feladattal kapcsolatosan is. 33

34 A feltáró, elemzı munka során kiválasztott interjúalanyoktól eltérı alanyok kiválasztása esetén, az elemzı munkába bevont résztvevık viszonyát és az eredmények befogadhatóságát (a többi érintett számára) ismerhetjük meg az elkészített elemzésre vonatkozóan. Alkalmas ez az interjútípus az elemzı munkában résztvevı munkatársak elfogultságának mérésére és/vagy a félreértésekbıl adódó torzítások kiküszöbölésére. Jellemzı alkalmazási terület: fejlesztési tervek, elemzési munkák befogadására, végrehajtására vonatkozó elırejelzések készítése; szubjektív tényezık hatásának csökkentése; termék/szolgáltatás értékelése. Javaslat: egy már definiált, felmért folyamat folyamatleírásának pontosítására, a folyamatleírásban szereplı ellentétek feloldására használjuk. Az alapvetı követelmények az interjúk esetében Ahhoz, hogy az interjúztatást eredményesebben folytathassuk, elıször azon követelményeket kell meghatároznunk, amelyeknek a megszerzett információknak meg kell felelniük [B8]. A relevancia és a teljesség követelményén azt értjük, hogy az információk a vizsgált jelenségre vonatkozzanak és lehetıleg lefedjék azt. A megbízhatóság az adatok hőségére és torzításmentességére vonatkozik. Az idıszerőség követelménye azt jelenti, hogy az információnak tükröznie kell az aktuális eseményeket. A mérhetıség követelménye azt jelenti, hogy a rendelkezésre álló információk mérhetıek, valamilyen eljárással kvantitatívvá tehetıek. A költség-haszon elv azt jelenti, hogy az információk felhasználhatósága álljon arányban az információk elıállításának költségeivel. Annak ellenére, hogy az interjú során szóbeli válaszokat kapunk, az interjú alakilag és pszichológiai szempontból is különbözik az egyszerő beszélgetéstıl. Ime, néhány különbség: Az interjú meghatározott céllal és tervszerően folyik. A beszélgetıpartnerek pszichológiai szempontból nem egyenrangúak. Egy interjú során az interjúvezetı és a megkérdezett soha nem cserélhetnek szerepet. Az egyszerő beszélgetés és az interjú élménye között komoly pszichológiai különbségek vannak. Az interjú egyszerre tartalmaz feszültséget, tartózkodást, gyanakvást és félelmet is. [B62] Felkészülés a szóbeli interjúk végrehajtására Az interjú szervezésének fıbb lépései: a) Interjú céljának meghatározása (a megismerendı terület). b) Szakmai felkészülés az interjú által érintett területekre vonatkozóan (szakmai alapok megismerése, átfogó kép kialakítása). c) Interjú formai követelményeinek tisztázása (pl.: jegyzıkönyvek követelményei, fájl formátum, feldolgozás feltételei). d) Az interjú struktúrájának kialakítása (pl.: bevezetés, kérdések, feladatok, befejezés, visszacsatolás formája). 34

35 e) Kérdés, feladatsor összeállítása. f) Interjú idıtartamának, ütemezésének meghatározása (ütemterv, egy interjú maximális hossza). g) Interjú alanyok kiválasztása (pl.: hatáskör, szaktudás, érintettség alapján). h) Interjú helyszínének meghatározása (megfelelı környezet kiválasztása). i) Az interjún történı megjelenés követelményeinek meghatározása (öltözék, felkészülési teendık az alany számára). j) Kommunikációs csatornák kialakítása és a résztvevık tájékoztatása. Az interjúk során fontos szerepe van a kommunikációnak. Minden emberi viselkedés - szándéktól függetlenül - üzeneteket közvetít a környezet számára. Bármit teszünk, vagy nem teszünk, azzal véleményünket, érzéseinket adjuk társaink tudtára. Az élıbeszéd során nemcsak szavakat használunk, hanem egész testünket. A legtöbb köznapi érintkezésben a verbális (szóbeli) és nem verbális üzeneteket együtt alkalmazzuk. A szemtıl szembe zajló kapcsolatokban sokkal többet közlünk, mint amennyit szavakkal kimondhatunk, ezeknek nagy részét a nem verbális csatornákon keresztül tesszük. Ezért kiemelten fontos, hogy az interjúra készüljünk fel szakmailag és lelkileg egyaránt. Az, hogy milyen hangszínnel, intonációval, ritmussal történik a közlés, elárulja érzelmeinket, szándékainkat, viszonyulásunkat. A testbeszéd és beszéd együtt közvetíti a kommunikáció mondanivalóját. A nem verbális jegyek megerısítik, vagy gyengítik a verbális közlés kijelentéseit. Az interjú alatt önkéntelenül is nagyon sok információt közlünk a másikkal, ugyanakkor mi is olvashatjuk a partner nem verbális jeleit, és ezekhez igazodva alakíthatjuk, befolyásolhatjuk a beszélgetést. Öltözetünk ne legyen kihívó, de ne legyünk túlöltözöttek sem. Érkezzünk pontosan a megbeszélt helyszínre, testtartásunk legyen természetes, beszédünk érthetı. Mutatkozzunk be, készítsünk elı névjegykártyánkat és helyezzük jól látható helyre. Az interjúztatás során az alábbiak szerint kérdezhetünk: A megértı kérdezés során a kérdezı türelmes és kész arra, hogy végighallgassa a megkérdezettet. A semleges megkérdezés standardizált technika, amely során a kérdezı a kérdésre fókuszál, törekszik a válaszadót a kijelölt keretek közé terelni. A fegyelmezett kérdezés komoly ellenırzése alapján folyik és a fı hangsúly az ıszinte válaszokon van, miközben le kell küzdeni az alany "kérdés megkerülı manıvereit. [B43] Az interjú vezetıjeként ellátandó feladatok Az interjú vezetıjeként a következı gyakorlati feladatokra kell felkészülnünk: alakítsunk ki semleges légkört; tisztázzuk az interjúra vonatkozó feltételeket; teremtsünk alapot egy ıszinte beszélgetéshez (nincs jó vagy rossz válasz); ügyeljünk a rendelkezésre álló idı hatékony felhasználására (pl.: megakadályozni az interjú elhúzódását); zavaró tényezık (telefonálás, levelezés, munkatársi megkeresés) kiküszöbölése, hatásuk csökkentése; tartsuk fent az érdeklıdést a témával kapcsolatosan. Kérdezıbiztosként kerüljük: 35

36 a harsány beszédet; a túlzott részletességő magyarázatokat; a történeti elkalandozásokat; szubjektív véleményünk kifejezését; szakmai tudásunk elıtérbe helyezését; az ítélethozatalt; a bizalmaskodást. Az interjú alanyát ne hozzuk kényelmetlen helyzetbe. Gyakori hiba, hogy a bevezetı, feltáró/elemzı, ellenırzı interjút helytelenül az alany tesztelésére használják. (Ezek az interjúk nem stressz interjúk és nem egy személy alkalmasságát vagy képességeit hivatottak felmérni!) Elıítéleteinket tegyük félre, hagyjuk az interjú alanyát kibontakozni. Az elhangzó rövidítéseket rögzítsük, tisztázzuk és szükség esetén oldjuk fel az értelmezésbıl fakadó félreértéseket. A kommunikáció leggyakoribb csapdái: ítélkezés (kritizálás, címkézés, diagnosztizálás, értékelı dicséret); megoldások közlése (utasítás, fenyegetızés, moralizálás, zárt kérdések, tanácsadás); a másik aggodalmának megkerülése (elterelés, logikai érvelés, megnyugtatás). Soha nem tudjuk, mit mondott beszélgetıtársunk, csak azt, amit meghallottunk belıle. Ezért ellenıriznünk kell, hogy a másik mondanivalója torzítás nélkül érkezett-e meg hozzánk. A visszajelzésekben a figyelı újból megfogalmazza a beszélı által közvetített érzéseket és tartalmakat, ezzel kifejezésre juttatva megértését és elfogadását. Kérdıívek összeállítása Az írásos interjúk esetén a középpontban a megfelelı kérdıív, feladatsor kialakítása áll. A szóbeli interjúk is nagyon gyakran támaszkodnak kérdıívekre, ellenırzı listákra. A következıkben a kérdıívekben felhasználható kérdezési technikákat részletezzük Állítások, kérdések a) A kérdıívekben gyakran állítások szerepelnek, melyre vonatkozóan kell feltüntetni az egyetértés mértékét. Ennek felmérésére gyakran a Likert-skálát alkalmazzák. Példa: A jármő forgalomból történı kivonás iránti kérelem formanyomtatvány a kérelmezı számára átlátható és egyértelmő. nagyon egyetért egyetért nem ért egyet nagyon nem ért egyet. A Likert-skála mellett a Thurston mérce is használatos. Likert mércéje egy állítás helyességét a kérdezettektıl nyert válaszok és az összérték összefüggése alapján bírálja el, míg Thurston mércéjénél az értékelést a zsőri adja, mert az értékelık valójában zsőriznek. Ennek a mércének több foka lehet, leggyakrabban 11 fokos. Kidolgozásának módja a következı: 36

37 Összegyőjtünk kompetens szakemberektıl olyan kijelentéseket, amelyek indikátorai lehetnek annak, amit mérni szeretnének. A begyőjtött állításokat 1-11-ig terjedı osztályzatokkal értékeltetjük. A legpozitívabb állítások 1, a legnegatívabbak a 11-es értékelést kapják. A hatos értéket a semleges álláspontot tükrözı kijelentés kapja. Kiszőrjük és elvetjük mindazokat az állításokat, melyekrıl az értékelıknek nem alakult ki közös véleménye. A megmaradt állítások értékét pedig a medián segítségével határozzuk meg. Az állítások végsı válogatása úgy történik, hogy kiválasztunk 11 olyan állítást, melyek a skála egyik végétıl haladva 11 fokozatot adnak. A végsı válogatás során figyelembe kell venni az állítás értékét és az értékelık közötti egyetértés fokát is. Az ilyen módszerrel kidolgozott mérce bekerül a kérdıívbe, a kérdezett pedig azokat az állításokat keretezi be, amelyekkel egyetért. A kapott válaszok alapján az álláspont intenzitását és irányát már könnyő meghatározni. [B44] Az állítások mellett az alábbiakban felsorolt kérdéstípusokkal találkozhatunk. b) Nyitott kérdések A nyitott kérdésekre a megkérdezettek saját szavaikkal felelnek. A nyitott kérdéseknek számos elınye van, itt néhányat sorolunk fel. Könnyő az összeállításuk. A kérdezetteknek nem sugallnak semmilyen választ. A kapott válaszok segítséget nyújthatnak zárt kérdések megfogalmazásához. Nagyobb a tapasztalati értékük. A nyitott kérdések hátrányai közül is felsorolunk néhányat. A megkérdezettıl magas fokú fogalmazó-, íráskészséget várnak el. A megkérdezettek gyakran megkerülik, válasz nélkül hagyják a kérdést. A kapott válaszok verifikációs lehetısége kisebb, a válaszok sokrétősége miatt. Kevesebben válaszolják meg ıket (mivel több idıt, átgondolást igényel), ezzel csökken a minta reprezentatív jellege. A nyitott kérdések a válaszadónak nagyobb nehézséget jelentenek, de nem azonos szinten, így a válaszadásra is különbözıképpen motiváltak. Azonos idı alatt kevesebb számú kérdés tehetı fel. Nehezebb a feldolgozásuk. A nyitott kérdéseket a felmérés elıkészítı szakaszában javasolt feltenni. A rájuk adott válaszok tapasztalati értéke nagyobb, s elımozdíthatják a probléma felfedését, a hipotézisek felállítását és a zárt kérdések megfogalmazását. A nyitott kérdések az adatok magyarázatánál is segíthetnek, ha zárt kérdésekkel kombináljuk ıket. [B43] Példa: Soroljon fel néhány problémát, amit a vezetıségnek az idén orvosolni kellene! c) Zárt kérdések. Zárt kérdések esetében a lehetséges válaszok elıre adottak. A megkérdezett több lehetıség közül választhatja ki a véleményét legjobban tükrözı választ. A zárt kérdések elınyei: nem lényeges a kérdezettek íráskészsége; nagyobb a kapott válaszok száma; 37

38 a megkérdezettek feladata egyszerőbb, hisz könnyebb a választ bekarikázni, mint önállóan megfogalmazni; több kérdést lehet feltenni; könnyebb a válaszokat feldolgozni; nagyobb a hitelük. A zárt kérdések hiányosságai: nehezebb megfogalmazni, elıkészíteni ıket; korlátozott a válaszadás lehetısége; segítségével a kérdezetteket a probléma megoldása szempontjából releváns válaszok felé irányítja; passzívvá teszi a kérdezetteket; heurisztikus értékük kisebb, mert a megkérdezett nem írhatja le a megadott válaszoktól eltérı gondolatait. A zárt típusú kérdések lehetıvé teszik az általánosítást és a hipotézisek ellenırzését. Emiatt a verifikációs kutatások végsı kérdıíve rendszerint zárt kérdésekbıl áll. [B43] Zárt kérdéseknél meglévı válaszlehetıségek közül kell választani, azaz elıre kódolni kell a válaszokat. A válaszok szőkített köre miatt, szükséges feltüntetni az egyéb... kategóriát. Válaszoknál nézzük meg, hogy kölcsönösen kizárják-e egymást, vagy több válasz adása lehetséges. Ilyen esetekben kérhetjük az interjúalanyt, hogy rangsorolja a válaszokat. Példa: Honnan értesül a munkáját érintı törvényi elıírások változásáról? o TV o rádió o újság o Internet o Magyar Közlöny o Munkatársak o Felettesemtıl o belsı levelezés o egyéb: Évente, átlagosan, mennyi kérelem érkezik jármő forgalomból történı kivonásával kapcsolatosan, a közlekedési igazgatási hatósághoz? o 0-10/év, o 10-50/év, o /év, o 100-nál több /év A zárt kérdések az adható válaszok típusa alapján lehetnek: felsorolásos kérdések, intenzitásjelzı kérdések, kétirányú változókra vonatkozó kérdések, indirekt kérdések, projektív kérdések. A felsorolásos válaszokkal ellátott kérdés esetében sok felkínált válasz lehetséges. A feldolgozás segítése érdekében az ilyen kérdések kidolgozásakor ajánlatos a válaszokat külön sorszámozni. [B43] 38

39 A zárt típusú intenzitásjelzı kérdéseket a mennyiségi változók esetében használjuk Erre a célra célszerő páratlan szint számmal rendelkezı skálát kialakítani (pl.: 3, 5, 7), így a skála kiegyensúlyozottá válik. A túlzott részletesség és az elnagyolt skála is torzíthatja a kapott eredményeket. Például háromszintő skála elegendı, ha negatív tartózkodom / semleges pozitív jellegő választ várunk kérdésünkre. A példából látható, hogy a skála egyaránt használható egy- vagy kétirányú (pl.: megelégedettség) válaszadásra is. Ha már elıre feltételezzük, hogy a kérdezetteknek nehézségeik lesznek az ıszinte válaszadással, indirekt kérdéseket teszünk fel. Az indirekt kérdések megkönnyítik az ıszinte válaszadást, ami nem mindig könnyő. Projektív (kivetítı) kérdéseket lehet alkalmazni, ha az interjú alanya várhatóan negatív, elmarasztaló választ ad vagy az alany számára a kérdés kellemetlen lehet. A projektív kérdések lehetıvé teszik, hogy a megkérdezettek ıszinte véleményt mondjanak egyes kérdésekrıl, azon emberek véleményén keresztül, akikkel azonosulni tudnak. További kérdéstípusok: memóriakérdés; ismereti kérdések, amelyek a felkészültséget vizsgálják; ellenırzı kérdések (ıszinteség vizsgálatára); sorbarendezési kérdés; értékelési kérdés az egyetértés ellenırzésére; feltételes kérdés, korábbi kérdés megválaszolásától függ. [B12] d) Táblázatos kérdések. A táblázatos kérdés több kérdés jobb térkihasználását, gyorsabb válaszadást, könnyebb feldolgozást segíti elı. Feltétele, hogy a lehetséges válaszok azonosak legyenek minden kérdés esetén. Példa: Nem értek egyet: 1 Egyetértek: A bontásra átvétel folyamata tisztázott. A forgalomból kivonás folyamata egységes. A hatósági jelzés selejtezésének folyamata az érintettek számára egyértelmő A kérdıívek összeállításával kapcsolatban javasoljuk, hogy a kérdezés során figyeljünk a következıkre: fogalmazzunk érthetıen; gyızıdjünk meg, hogy a megkérdezett ismeri a témát és érti a kérdést; kerüljük a kétértelmő kérdéseket; releváns kérdéseket tegyünk fel; rövid, egyszerő kérdéseket tegyünk fel; ne használjunk tagadó kérdéseket, mert elkerülheti a válaszadó figyelmét a nem szó; kerüljük a sugalmazó kérdéseket (gyakran a válaszadók a társadalmi elvárásoknak megfelelı választ adnak). Kérdıívszerkesztés alapszabályai szerint elvárás, hogy a kérdıív: 39

40 ne legyen túl hosszú; legyen jól áttekinthetı (egy sorba lehetıleg egy kérdés kerüljön, legyen elég hely a válasznak); egyes fejezetek elıtt készítsünk rövid tájékoztatót; tájékoztassuk az alanyt a kérdıív hosszáról, további felhasználásáról, a kitöltéshez szükséges idı nagyságáról; adjunk egyértelmő instrukciókat a kérdıív kitöltéséhez; jelezzük, ha csak egy választ szeretnénk kapni, ha rangsorolást kérünk, akkor írjuk le a rangsor készítés módját; a válaszlehetıségeket körültekintıen adjuk meg; kerüljük a szuggesztív kérdéseket; a feleletválasztós kérdéseknél ajánlott négyzeteket tenni a kérdések után vagy számkarikázást kérni, a válaszok könnyebben feldolgozhatósága érdekében; feltételes kérdések során tüntessük fel a kapcsolatot: Ismeri az egyes részfolyamatokat? Ha igen, melyiket? Igen, ismerem:.. Igen: 1, bontásra átvétel Nem 2, forgalomból kivonás 3, hatósági jelzés selejtezése 4, Egyéb: figyeljünk a kérdések sorrendjére, (az elızı kérdés ne befolyásolja a válaszadót a következı válasz kiválasztásában); a logikai sorrend mellett figyeljünk a pszichológiai sorrendre is; a kérdések legyenek lényegre törık; törekedjünk érdekes kérdések feltevésére. A szóbeli interjú támogatására szolgáló kérdıív Az ilyen típusú kérdıívek kitöltését az interjú vezetıje, kérdezıbiztosa vagy az interjút jegyzıkönyvezı személy végzi. A kijelölt személy a kérdéseket ismeri, céljukkal, értelmezésükkel tisztában van, ezért ezek a kérdıívek bonyolultabb kérdéseket, állításokat is tartalmazhatnak. Általában az általános tájékoztató részek elhagyásra kerülnek, forgatókönyvként funkcionálnak. Ezeknek a kérdıíveknek a célja, hogy az interjúkat azonos mederben tartsa és/vagy egységes szerkezetet biztosítsanak az interjúknak. Az interjút vezetı személy feladata az alany tájékoztatása segítése a kérdések megválaszolásával kapcsolatosan. A kérdıív általános felépítése: a) Bevezetı (fejléc) tartalmaz: aa) az interjú helyszínét, idıpontját, azonosítóját tartalmazza; ab) résztvevıket, résztvevıre vonatkozó információkat (pl.: beosztás, munkakör) tartalmaz ac) az interjúra vonatkozó tájékoztatót tartalmaz. b) Törzs: kérdéseket, feladatokat tartalmaz 40

41 c) Befejezés, ellenırzı lista (pl.: interjúalany tájékoztatása megtörtént, kapcsolati adatok rögzítettek) A kérdıívek gyakran kerülnek kiegészítésre ellenırzı listákkal (checklist). A checklist kialakítása során törekedni kell a gyors kezelhetıségre az ellenırzést a lényegi elemekre fókuszálni. Az ellenırzı listák Igen/Nem kérdések sorozata, melyek Go vagy Nogo döntéshez köthetıek. Szerepük a felkészülés során illetve az interjúk befejezésekor kerül elıtérbe Az esettanulmány Az esettanulmány interjúk és dokumentumvizsgálat kombinációjából jöhet létre. Az esettanulmány készítése a szisztematikus, jól elıkészített és módszertanilag megalapozott megfigyelést és adatnyilvántartást jelenti. Adatgyőjtési módszerként használható, ha részleteiben akarunk egy jelenséget, folyamatot megismerni és ezek alapján induktív következtetéseket levonni. Problémamegoldást elıkészítı módszerként az esettanulmány szakmai problémák megoldásában használható. Az esettanulmány leginkább a megfigyelés és az interjú módszereit alkalmazza, de más, a céloknak megfelelı módszerek használata sem kizárt. [B43] Az esettanulmány alapot teremt egy eseménnyel, folyamattal kapcsolatosan: az elızmények, környezeti tényezık leírását, az információk értékelését; a probléma, vagy problémák felismerését; döntési változatok kidolgozását; javaslat, vagy javaslatok elıterjesztését a döntéshozók felé Szakértıi vélemények feltárása Ebben a részben az információgyőjtés fontos tartozéka, a szakértıi vélemények feltárásnak lehetséges módjait mutatjuk be. A fejezetben részletezésre kerülı módszerek ötvözhetıek. Egy-egy módszer lépésrıl lépésre történı végrehajtása gyakran nem elégíti ki információs igényeinket. Szakértık bevonása kiválthatja a dokumentum átvizsgálást vagy az interjúztatást is, de természetesen együttes alkalmazásuk a folyamatleírás teljességét nagyobb mértékben biztosítják. Szakértık bevonását és véleményük kikérését javasoljuk, ha a folyamatleírás készítés során: a rendelkezésre álló elsıdleges források nem nyújtanak elegendı információt (pl.: a hiányos folyamatleírás nem egészíthetı ki dokumentumok, jogszabályok alapján), a folyamatleírás készítése során (ebben a formában nem feloldható) ellentmondásokba ütközünk (pl.: azonos szintő, részletezettségő dokumentumok, esetleg jogszabályok ellentmondást tartalmaznak folyamatleírásunkra vonatkozóan), származtatott folyamatleírás készítése esetén (pl.: egy összetett folyamat részfolyamatokra történı bontásakor), önálló információgyőjtési formaként alkalmazzuk, mert más források nem állnak rendelkezésre. A szakértıi vélemények feldolgozása során figyelembe kell venni a fıbb vélemény-torzító tényezıket [B43]: 41

42 az információ értéke idıben változó; az ember hajlamos elhanyagolni a benne kialakult egységes képet zavaró adatokat; témánként eltérı az információra való fogékonyság; nem megfelelı mélységő információkat győjtenek és ismeretanyaguk egyenetlen lesz; a meghökkentı elméletek fenntartás nélküli elfogadása. A kapott válaszok megbízhatósága függ: a szakértık megbízhatóságától és kompetenciájától, feleleteik jellegétıl, a probléma dinamikájától és más jellegzetességétıl, az idıtartamtól, melyre a jelenség fejlıdését elırelátják. [B43] Brainstorming és brainwriting A brainstorming olyan csoportos feltáró munka, amelynek a célja, hogy az egyének csoportos véleményalkotásából származó elınyöket hasznosítsák. Lényege: a szabad, kritikától mentes ötletfelvetés, a gondolattársítás (asszociációk is). Jellemzıje az érintettek minél szélesebb körének bevonása, a szabad, kritikamentes ötletfelvetés, az ötletek szemléletes győjtése, többszöri ötletfelvetés lehetıségének biztosítása. A javaslatok minısítése nem a felmérést végzı csoport feladata. Lépései: a) A probléma felvetése, az elérendı cél meghatározása. b) A moderátor (csoportvezetı) megbízása: a moderátor legyen jó ismerıje a szakmai problémának, jó kapcsolatteremtı készséggel rendelkezzen. c) A csoport tagjainak kijelölése és felkérése a csoportmunkára. A csoportba minden érintett szakterületrıl célszerő meghívni munkatársakat, de lehetnek külsı tagjai is a csoportnak. A csoport tagjai lehetıleg ne csak szakemberekbıl álljon, esetenként laikusokat, illetve társ szakterületek képviselıit is célszerő meghívni. d) A csoport tagjainak elızetes írásbeli tájékoztatása. A megtárgyalandó probléma ismertetése, a rendelkezésre álló dokumentációk, segédanyagok (amik segítik a felkészülést) megküldése. e) A csoportmunka szabályainak ismertetése. ea) kritika megtiltása, eb) egyszerre egy javaslat felvetése, ec) a résztvevık sorban teszik meg javaslatukat, ed) mások javaslatai továbbfejleszthetıek, ee) tilos vitát folytatni, ef) akinek már nincs ötlete, passzolja az ötletfelvetés lehetıségét. f) Végrehajtás: fa) a moderátor a táblára felírja a problémát, fb) a résztvevık nem kerülnek bemutatásra (feszélyezettség elkerülése végett), 42

43 fc) kéri a rövid, tömör megfogalmazást (max. két szó), fd) sorban felszólítja a résztvevıket ötleteik megtételére, fe) a moderátor sorban felírja a táblára az ötleteket, ff) az ötletfelvetés addig tart, amíg vannak újabb ötletek. g) Az ötletek hasznosítása: az összegyőjtött ötleteket elıször értelmezni, majd csoportosítani kell. Elıször az ötletek egymáshoz való viszonyát célszerő tisztázni, amely lehet: egyik ötlet része a másiknak; az egyik ötlet kiegészíti a másikat; az egyik ötlet ellent mond a másiknak. Ezek után lehet az összetartozó ötleteket csoportosítani (affinitás diagram), további értelmezés céljából. A brainstorming nem adja meg az egyértelmő választ valamely probléma megoldására, de széles ötlettárat tár fel az elemzık elıtt a lehetséges megoldásokból. Tapasztalataink alapján alkalmazását javasoljuk: nem egyértelmő, nehezen meghatározható információforrások azonosítására, folyamatábrázoláshoz kapcsolódó logikai láncok kialakítása során. A brainwriting során az ötleteket a résztvevık leírják, kifejtik. A kifejtés ebben az esetben nem szakértıi véleményalkotást jelent. Philips 66 A Philips cégnél alkalmazták elsıként. A módszer végrehajtása a következı: Hat fıs csoportok, hat percig beszélik meg az ülésen felvetett javaslatokat. A javaslatokat a moderátor terjeszti a csoport elé. Az ötleteket a brainstorming módszerével tárgyalják. Hat perc után szünet, majd újabb forduló. Elsısorban konkrét mőszaki probléma megoldásánál alkalmazzák ezt a módszert szakértık közremőködésével. A felmérés gyakorlatában a folyamatleírások újra gondolására kínál gyors és hatékony megoldást. Egyéb módszerek Ebben a fejezetben térünk ki további vélemény feltáró módszerek bemutatására. A bemutatás célja, hogy a rendhagyó folyamatfelmérési esetek egy részét is lefedjük. A fejezetben bemutatásra kerülı módszerek segíthetnek: alternatívák közötti választásban, idı- és térbeli korlátok hatásának csökkentésében, kiküszöbölésében, szakértıi munkák összehasonlításában. A 635 módszer Ezzel a módszerrel hat fıs csoportok, három megoldási változatot köröznek egymás között ötször egymás után. Minden körben kiegészítik, véleményezik a hozzájuk került anyagot. Többnyire tervvariánsok, megoldásmódok elbírálására használatos módszer. Egy folyamat alternatív folyamatleírásai közül a végleges kiválasztására alkalmas módszer. A gyakorlatban hat fıs csoportok helyett kisebb létszámú csapat is alkalmazhatja a módszert. A 43

44 megoldási változat számának csökkentése az asszociáció mértékét csökkentheti, növelése pedig a döntés hozatali idıt növeli. A szinektika Összetett feladatok megoldására alkalmazható, lényege a csoportos ötletgyőjtés (7-7 fıs szakértıi csoportok), melyet módszertani oktatás és továbbképzés alapoz meg. A módszer a kreatív gondolkodás jellegzetességeit aknázza ki. A feladatot több szempontból vizsgálják kiváló képzettségő szakemberekkel. A módszer biztos eredményeket ad, alkalmazása azonban szők területre korlátozódik, mert idı és költségigényes. Alkalmazása több nagy közigazgatási szervezet együtt mőködése esetén célszerő, amennyiben a szervezetek közös, komplex folyamatok kialakítását tőzik ki célul. Tipikus alkalmazási területe, ha a külsı tanácsadói csapatból és belsı folyamatgazdákból belsı folyamatelemzı, fejlesztı csapat áll rendelkezésre. Az ankétmódszerek Az ankét tényadatok begyőjtésére szolgáló, a statisztikai mintavételt, a kérdıívet és az interjút ötvözı technika (Mozer, 1962). Az ankét szélesebb értelemben kérdésfeltevéssel végzett adatgyőjtés. A szőkebb értelemben vett ankét kérdıíves írásbeli adatgyőjtés egy reprezentatív minta megkérdezetteinek véleményérıl és álláspontjairól. A korábban leírt interjúztatás illetve dokumentum átvizsgálás együttes alkalmazása egy szőkebb értelemben vett ankét, amennyiben az interjúalanyokat adott terület szakértıjének tekintjük és a dokumentumok megfelelı elméleti tudással is megalapozottak. A Delphi módszer olyan szakértık által végzett tevékenység, ahol a csoport tagjai egymástól elkülönülten végzik tevékenységüket, ezért hosszú az átfutási ideje. A módszer lépései: az elérni kívánt cél (a megoldandó probléma) meghatározása; a résztvevı szakemberek kiválasztása (csak szakértık); a szakértıktıl részletes írásbeli válasz (megoldási javaslat) kérése; értékelı csoport összeállítása a szakértıi vélemények értékelésére; az értékelı csoport munkája alapján újabb forduló a szakértık körében; újabb értékelés és újabb véleménykérés a probléma szakértıi egyetértéssel történı megoldásáig. Folyamatfelmérés során szembesülhetünk azzal a problémával, hogy az információ több idıben és térben jól elhatárol területen lelhetı fel, esetleg több nemzetközileg is szabályozott folyamatot is érinthet. A szakértık más-más nézıpontból közelítenek, ilyen esetben a felmérést végzı csapatra az értékelı csoport feladatai hárulnak. 6. Folyamat kidolgozása/módosítása Ebben a fejezetben a folyamatok kidolgozásának / módosításának, azaz a folyamatok leírásának és ábrázolásának módját, formátumát tárgyaljuk. A folyamatok módosítása a nem létezı folyamat elemeinek azonosítását jelenti, nem a fejlesztési értelemben való módosítást. 44

45 12. ábra: Egy folyamatleírás kidolgozása/módosítása 6.1. Folyamatok szöveges leírása A folyamatok szöveges leírásakor arra kell törekedni, hogy a leírás megfelelıen tömör legyen, ugyanakkor tartalmazzon minden szükséges elemet a közigazgatási folyamatok egyértelmő azonosításához és lényeges tulajdonságaik rögzítéséhez. A folyamatok szöveges leírásakor mindeképpen figyelembe kell venni a folyamatleírási és fejlesztési szabványok/modellek ajánlásait. Mindezeket figyelembe véve, a 3.2 és 3.3 részekben leírtak jól felhasználhatók. Ezek szerint, a folyamatok esetében legalább az alábbi elemeknek kell meglenniük a folyamat meghatározásában: jól meghatározott input, jól meghatározott output, jól megfogalmazott cél, a folyamat tevékenységeinek pontos leírása, a tevékenységek elvégzéséhez szükséges felelısségek, hatáskörök és kompetenciák azonosítása és biztosítása, 45

46 a folyamat követésére beiktatott ellenırzési pontok, a pontosan megfogalmazott teljesítmény-elvárások, a folyamat metrikák. Jelen módszertan kidolgozása során figyelmbe vettük a Kopint-Datorg Infokommunikációs Zrt. Esettanulmányait közigazgatási folyamatok leírásával kapcsolatban, valamint azon országok és projektek tapasztalatait, melyek SOA alapú közigazgatási korszerősítésbe kezdtek. Ezek alapján, valamint a közigazgatási folyamatok érdekelt feleivel folytatott egyeztetések, interjúk során meghatározásra kerültek azok az elemek, amelyek leírása szükségesnek látszik ahhoz, hogy egy folyamatot meghatározottnak lehessen tekinteni. A továbbiakban ezeket az elemeket részletesen is bemutatjuk. Folyamat hivatalos neve: Folyamat hivatalos neve, amennyiben a név nem fedi le a folyamat célját a cél cellában részletesebben ki kell fejteni. Cél: Opcionálisan tölthetı cella, ha a név nem utal megfelelı mértékben a folyamat céljára. Azonosító: A folyamatnak egy rövid és egyértelmő megnevezése, amit a leírásokban referenciaként könnyen használhatunk. Rövid név: A folyamat azonosítására alkalmas, a gyakorlatban alkalmazott nem szükségképp hivatalos elnevezés Informatikai támogatás mértéke: A folyamat végrehajtása lehet tisztán emberi tevékenység, de tartalmazhat gépi informatikai támogatást is (szélsı esetben az egész folyamat támogatott). A támogatottság mértékét csak az éppen vizsgált folyamatra számítjuk, az általa indított gyermek folyamatokra nem. Tulajdonos: A folyamatot kidolgozó szervezet vagy személy A folyamat meglétéért, végrehajtásáért felelıs szervezet, intézmény megnevezése. Üzemeltetı: A közigazgatás alanya, aki a tevékenységet végzi. A tevékenység végzéséhez szükséges feltételekkel rendelkezik. Beírhatók még az üzemeltetı elérhetıségére vonatkozó adatok: Kapcsolattartó - neve Kapcsolattartó Kapcsolattartó telefon. Szakértı: A folyamat minden mozzanatát ismerı szervezet, személy, akinek a folyamattal kapcsolatos állásfoglalása mértékadó. Beírhatók még a szakértı elérhetıségére vonatkozó adatok: Kapcsolattartó - neve Kapcsolattartó Kapcsolattartó telefon. 46

47 Verzió: aktuális verziószám. Létrehozás: létrehozás dátuma és idıpontja. Módosítás: utolsó módosítás dátuma és idıpontja. Folyamat leírása: A folyamat szöveges megfogalmazása, terjedelme: 5-10 sor. A közigazgatás alanyának jogi hatással bíró, jogszabályokon, jogi normákon alapuló akaratnyilvánítása megvalósításához szükséges tevékenység. A folyamatot egy a folyamaton kívülrıl származó indító esemény kezdeményezi. A folyamat lehet összetett, amikor a megvalósításhoz további folyamat(ok) végrehajtásának kezdeményezése szükséges. Indító esemény: A folyamat szempontjából külsı esemény, amely a folyamat egy példányának létrejöttét és a folyamat megindulását eredményezi, ha az elıfeltételek és kezdeti állapot ezt lehetıvé teszik. Az esemény pillanatszerő, oszthatatlan történés. Eseménynek tekintendı valamely megjelölt idıpillanat elérkezése is. Az eseménynek lehetnek paraméterei. Pl: az esemény idıpontja, az eseményt okozó személy. Bemenetek: Az indítás pillanatában a folyamatot indító által az induló folyamatnak átadott dolgok (pl. termékek, ügyiratok, adatok). Elıfeltétel, kezdeti állapot: Azon folyamaton kívüli dolgok (beleértve a folyamat bemeneteit is) jellemzıire vonatkozó korlátozások összessége, amelyeknek teljesülnie kell az indító esemény bekövetkeztének pillanatában ahhoz, hogy a folyamat ténylegesen meginduljon. Szokásos lépések: Ha a folyamattól elvárt eredmények, utófeltételek kialakítása érdekében végzett tevékenység nem ragadható meg egyetlen mozzanatként (lépésként), akkor a tevékenységet lépések sokaságaként definiálhatjuk. Egy lehetséges lépés egy újabb folyamat indítása. A folyamat konkrét példányának végrehajtásakor a lehetséges lépéssorozatok egy változata hajtódik végre. Ez a leírás a leggyakoribb lépéssorozatot adja meg. (Példa folyamat: pénzfelvétel ATM-bıl. Itt a sikeres eset tekinthetı szokásosnak) A Gyermek folyamatok a Szokásos lépéseknek azon részhalmaza, amelyet külön folyamatleíró lapon elemzünk. Változatok: A lehetséges lépéssorozatok kevéssé gyakori változatainak leírása. (Példa folyamat: pénzfelvétel ATM-bıl. Egy változat: a PIN kódot ismételten meg kell adni, és a bankszámlán nincs elegendı pénz, ezért a pénzfelvétel meghíusul) Termékek, kimenetek: Mindazon, a folyamat végrehajtása során keletkezett dolgok (okiratok, adatok stb.) összessége, amelyek kimunkálása, létrehozása céljából zajlott le a folyamat. A termékek a folyamat indulása elıtt nem léteztek, de a folyamat befejezıdését követıen tovább léteznek. Utófeltétel, végállapot: Azon folyamaton kívüli dolgok jellemzıire vonatkozó korlátozások összessége, amelyeknek teljesülnie kell a folyamat befejezıdésének pillanatában. Mind a szokásos lefutás, mind a változatok esetére meghatározandó. 47

48 Napi kérések: A folyamat napi indításainak száma átlagosan Csúcsterhelés: A folyamat napi indításainak maximális száma. A csúcsterheléses idıszakok elıfordulása, hosszúsága. Átlagos kiszolgálási idı: A folyamat teljes lefutásának szokásos ideje Minimum kiszolgálási idı: A folyamat teljes lefutásának minimális ideje Maximum kiszolgálás idı: A folyamat teljes lefutásának maximális ideje Kapcsolatok: A Gyermek folyamatok a Szokásos lépéseknek azon részhalmaza, amelyet külön folyamatleíró lapon elemzünk. Szülı folyamat: Azon folyamat(ok), amely(ek)nek a végrehajtása során a vizsgált folyamat végrehajtását kezdeményezik. Gyermek folyamat: Azon folyamat(ok), amely(ek)nek végrehajtását a vizsgált folyamat kezdeményezi. Jogszabályok: Azon jogszabályok, jogi normák, elıírások, amelyek a folyamattal, annak végrehajtásával kapcsolatosak, amelyek módosulása a folyamat módosítását okozza. Gazdasági vonatkozások: Azon szabályok, elıírások összessége, amelyek a folyamat végrehajtásának gazdasági aspektusait meghatározzák. Pl: ki és hogyan fedezi a folyamat végrehajtása során felmerülı költségeket (illetékeket)? Ha a folyamat gazdasági, pénzügyi tevékenységeket, illetve erre való hivatkozásokat (büntetés kiszabása vagy segély, támogatása folyósítása) tartalmaz, akkor az milyen módon és kik között történik? Függıségek: Azok a folyamaton kívüli dolgok, amelyek hatással lehetnek a folyamatra általában, és a leírás korábbi pontjaiban nem szerepelnek. Megjegyzés: Tetszıleges a folyamat megértését segítı szöveg. Pl: Folyamatként kezeljük, azonos sémában írjuk le a magas szintő (absztrakt, elvont) és a mélyebb (konkrét részletekre vonatkozó) munkafolyamatokat is. A legelemibb folyamatoknak, amelyekrıl e projektben adatlapot töltünk ki, webszolgáltatások (WS) alapját kell képezzék. A folyamat absztrakciós szintjének megadása hosszabb távon, a folyamatleíró módszertan letisztulása során válhat kiegészítı leíró elemmé. A fentiek figyelembevételével, az ajánláshoz kapcsolódó Folyamatleírást segítı gyakorlati útmutatóban a fenti elemek leírásához megadtuk a közigazgatásban javasolt táblázatos formát. 48

49 6.2. Folyamatok ábrázolása A gyakorlat azt mutatja, hogy a folyamatok szöveges leírásával egyidejőleg történı grafikus ábrázolása segíti a folyamatok késıbbi (elsısorban külsı fél általi) megértését. A grafikus ábrázolás amellett, hogy könnyebben és gyorsabban értelmezhetı, feldolgozhatóbb, mint egy többoldalas szöveg, információt sőrít és jól alkalmazható az elágazások, ciklusok, döntési pontok egyértelmő reprezentálására, javítja az információ átláthatóságát. A grafikus megjelenítés gyakran a legjobb kiegészítıje a szöveges leírásoknak, mivel nagyon nehéz konzisztens és mindenki számára egyértelmő szöveges folyamatleírást készíteni, majd ezeket feldolgozni, verifikálni és validálni. A folyamatábra segít ezekeket a problémákat megoldani, s így kiküszöbölni az esetleges szöveges inkonzisztenciákat. Jól bevált folyamatleíró gyakorlat, hogy elıbb a grafikus reprezentációt készítjük el, majd a grafikus ábrázolás elemeihez, elsısorban folyamataihoz, lépéseihez, tevékenységeihez, esetleg eseményeihez szöveges magyarázatot rendelünk. Természetesen a leírás és ábrázolás sorrendjét mindig a folyamatleíró dönti el az aktuális helyzet és információk alapján Ábrázolási módszerek, architektúrák A folyamatábrázolás számos szempontból kategorizálható, így például architektúra és megközelítés szerint. A minimalista megközelítés szerint csak a feltétlenül fontos elemeket szükséges modellezni. Itt a cél az, hogy bárki számára könnyen érthetı és gyorsan feldolgozható reprezentációt hozzunk létre. A maximalista megközelítés szerint a cél a számítógép számára is feldolgozható modell létrehozása. A maximalista megközelítés alapján készült modellek számos olyan részletet tartalmazhatnak, melyek ember számára nehezebben érthetık, kevésbé átláthatók. Architektúra szempontból is két fı irány figyelhetı meg: a top-down és bottom-up folyamatábrázolási megközelítések. A top-down módszernél a folyamat ötletétıl indulva elıször ábrázolunk, tehát leírunk egy ideális folyamatot, majd megvalósítjuk azt. A bottom-up módszernél egy létezı folyamatot próbálunk meg ábrázolni. Jelen esetben az a célunk, hogy már meglévı folyamatokat térképezzünk fel s ezeket fıleg emberek számára érthetı módon ábrázoljuk, a továbbiakban tehát egy top-down, minimalista megközelítést követünk Workflow minták A workflow vagy control flow minták egy grafikus ábrázolási nyelv kifejezıképességét, viselkedését mutatják meg. Workflow minta például a szekvencia, különbözı típusú elágazások vagy a szinkronizáció. Egy ábrázolási nyelv kiválasztásánál fontos szempont lehet, hogy az adott nyelvben hogyan lehet leírni a leggyakrabban alkalmazott workflow mintákat. Ebben a témakörben számos tudományos kutatás folyik jelenleg is. Egy, az Eindhoveni Mőszaki Egyetemen folyó munkában, [B53] 21 ilyen mintát azonosítottak, s ezeket különbözı kategóriákba sorolták. A kutatók azt vizsgálták, hogy a kiválasztott mintákat hogyan lehet BPMN-ben és EPC-ben megvalósítani. Egy másik kutató, Weske [B52] az elıbbihez hasonló módon szintén a workflow mintákra alapozva (amit ı control flow mintáknak nevez) mutatja be, hogy a különbözı folyamatmodellezı nyelvekkel hogyan lehet leírni az általa bemutatott mintákat. Az elıbbiek alapján úgy gondoljuk, hogy az 49

50 alapvetı minták könnyő leírhatósága egyik elsıdleges szempont kell, hogy legyen az ábrázolási nyelv kiválasztásánál Ábrázolási nyelvek Fejlesztıi körökben elsısorban UML (Unified Modelling Language) activity diagramokat alkalmaznak folyamatok leírására, de számos más módszerrel is találkozhatunk, mint pl: Petri hálók, EPC (Event Driven Process Chain), Workflow hálók, YAWL (Yet Another Workflow Language), GPWL (Graph-Based Workflow Language) BPMN (Business Process Modeling Notation) és BPD (Business Process Diagram). Mindezek mellett nem szabad megfeledkeznünk az Enterprise Modeling illetve a POEM (Process Oriented Enterprise Modelling [B48]) által ajánlott, sok esetben kevésbé formalizált megoldásokról sem. Az Enterprise Modeling nagyvállalati környezetben történı, helyzetfüggı modellezést értünk, melynek célja hasonló a BPMN-hez, a különbözı felek közötti kommunikáció könnyítése, melyhez helyzettıl függıen különbözı típusú diagramokat használhatunk. A felsorol megoldások közül a BPMN, EPC és az UML megoldások segítségével a közismert workflow minták könnyen leírhatók, egységes, kiforrott jelölésrendszert használnak, emberi és gépi feldolgozásra egyaránt alkalmasak, a legelterjedtebbek, széleskörő szoftveres támogatással rendelkeznek. Ezen elınyökbıl kiindulva a továbbiakban erre a három megoldásra koncentrálunk, s ezek egyikét javasoljuk a folyamatok ábrázolására. A következıkben röviden bemutatjuk az általunk legfontosabbnak ítélt módszereket. Részletesebb bemutatásuk a [B52] irodalomban található illetve a mellékletben található BPMN A BPMN (Business Process Modeling Notation) egy szabványosított grafikus jelölési mód az üzleti folyamatok munkafolyamatban való megjelenítésére. A BPMN-t a BPMI (Business Process Management Initiative) fejlesztette ki és jelenleg az OMG (Object Management Group) kezeli, a két szervezet 2005-ös összeolvadása óta. A BPMN széles körben elterjedt verizója az 1.1. A 2.0 verzió végleges formája 2008 során fog megjelenni. A 2.0-s verzió jelenleg RFP-ként (Request for Proposal) már elérhetı. A BPMI célja a BPMN-el egy minden érintett számára érthetı szabványos jelölési mód kidolgozása volt. Ezek az érintettek lehetnek üzleti elemzık, akik létrehozzák és finomítják a folyamatokat, fejlesztık, akik a folyamatok megvalósításáért felelnek vagy menedzserek, akik menedzselik és követik a folyamatot. A BPMN tehát egy közös grafikus jelölési mód, melynek célja, hogy kiküszöbölje a kommunikációs problémákat különbözı hátterő érintett felek között. Fontos kiemelni, hogy a BPMN flowchart technikára épül, kidolgozásánál pedig számos jelölésrendszert és módszert felhasználtak, így például az UML tevékenységdiagramot, UML EDOC Business Process, IDEF, ebxml BPSS, Activity- Decision Flow (ADF) Diagram, RosettaNet, LOVeM és az EPC-t [B50]. 50

51 A BPMN elemei Az alábbiakban kifejtjük a BPMN alapvetı elemeit. A könnyebb érthetıség érdekében az elemek megnevezését angolul és magyarul is feltüntettük. Flow objects (Folyamat objektumok): A BPMN-nek három alap folyamat objektum eleme van, így sem a modellezınek sem az értelmezınek nem szükséges nagyszámú alapelemlistát megtanulnia. o Event esemény Az eseményeket körrel jelöljük, és segítségével jelezhetjük, hogy valami történik az üzleti folyamat során. Az események a folyamat mőködését befolyásolják, így egy eseménynek jellemzıen van oka és hatása. Háromféle eseménytípust különböztetünk meg, attól függıen, hogy hogyan befolyásolja az üzleti folyamatot: Start (indító), Intermediate (köztes), és End (záró) esemény. 13. ábra Indító, köztes és záró esemény BPMN jelölése o Activity Tevékenység A tevékenységeket BPMN-ben kerekített sarkú téglalappal jelöljük és a szervezet munkáját jelképezik. A tevékenységek lehetnek feladatok (atomiak) vagy al-folyamatok (összetettek, tovább részletezettek). Az alfolyamatot egy kis plusz jel -el jelöljük a téglalap alsó részén, középen. Abban az esetben, ha az alfolyamatot nem külön ábrán részletezzük, akkor a plusz jel helyett mínusz jelt használunk. o Gateway Átjáró Az átjárót a jól megszokott rombusszal (45 fokban elforgatott négyzettel, vagy gyémánttal ) jelöljük és a szokásos fork-join szerepét tölti be, tehát döntéseket, elágazási és összefogó pontokat jelölhetünk vele. A rombusz belsı felében feltüntetett jelek mutatják az átjáró típusát. Connecting objects (Összekapcsoló objektumok): A folyamatobjektumokat összekapcsoló objektumok segítségével köthetjük össze. A BPMN ezekbıl is három típust különböztet meg: o Sequence flow szekvencia folyam A szekvencia folyammal tevékenységeket köthetünk össze. A szekvencia folyamot egy vékony vonallal és a végén sötét nyíllal jelöljük, ahol a nyíl vége mutatja a tevékenységek végrehajtásának irányát, sorrendjét. (Megj: a BPMN nem használja a control flow kifejezést). Figyelem: két különbözı medencében lévı tevékenység között csak üzenetfolyam jelölést használhatunk, szekvencia folyamot nem. o Message flow üzenetfolyam Az üzenetfolyam szaggatott vonallal, a végén fehér nyíllal reprezentálható. Az üzenetfolyam két egymástól elkülönülı folyamatszereplı (üzleti entitás vagy üzleti szerepkör) üzenetváltását 51

52 mutatja meg. A BPMN-ben két különálló medence között húzhatunk üzenetfolyamokat. Az üzenetfolyam segítségével az üzleti felek közti üzenetváltások (küldés-fogadás) válik hangsúlyossá. o Association asszociáció Az asszociáció pöttyözött vonallal, végén egyszerő nyíllal reprezentálható. Segítségével adat, szöveg és más termékek rendelhetık a folyamatobjektumokhoz. Terméket csak asszociációs kapcsolattal rendelhetünk folyamatobjektumokhoz. Ilyenkor kötelezı meghatározni az asszociáció irányát is (a vonal melyik végén legyen a nyíl). Az asszociáció irányától függıen az adat- vagy szövegobjektum be- vagy kimenet lesz. Olyan modellezésnél, ahol elég egy magas szintő, kevésbé precíz ábra (pl. dokumentációs vagy kommunikációs célokra), ott egy jól érthetı modell könnyen és gyorsan elkészíthetı a bemutatott alapelemek felhasználásával. 14. ábra BPMN alapelemekbıl álló BPD Ha mégis precízebb modellt szeretnénk, akkor felhasználható a BPMN kibıvített elemlistája, mely az alapelemeket további altípusokra bontva segít még konkrétabbá tenni az ábrát. Ezek a kibıvített jelölések általában az alapjelöléseken belül jelennek meg, pl. - pluszjel a tevékenység jelében tovább részletezett, alfolyamat, - vagy óra a köztes eseményt jelölı kettıs kör belsejében mely idızítést jelöl. 52

53 15. ábra - kiterjesztett BPMN elemeket is tartalmazó BPD Swimlanes (Úszósávok): o Pool medence A medence egy folyamat résztvevıjét reprezentálja, ugyanakkor grafikusan mutatja meg az egymáshoz tartozó tevékenységek listáját. A különbözı medencékben található tevékenységek külön folyamathoz tartoznak. Mindegyiknek van indító és záró eseménye. o Lane sáv Egy medencét több sávra lehet osztani, így a sáv mindig egy medence részét képezi. A sávok a tevékenységek szervezésére és kategorizálására használhatók fel. A különbözı sávokhoz tartozó események egy folyamathoz tartoznak, így egy indító és egy záró eseményük van. Fontos különbség a medence és a sáv között, hogy különbözı sávokban található tevékenységek között létrehozhatunk szekvencia folyamot, viszont különbözı medencékben található tevékenységek között nem (ez esetben üzenetfolyamot hozhatunk létre). A BPMN alapelemei között három terméktípus szerepel: az adatobjektum, a csoport, és a megjegyzés. Emelett a BPMN-t úgy tervezték, hogy bármennyi terméket hozzá lehessen adni egy diagramhoz és ki lehessen terjeszteni az alapelemek listáját. Artifact (Termékek): o Data objects adatobjektumok Az adatobjektum klasszikus inputokat és outputokat jelenít meg. Segítségével megmutathatjuk, hogy egy tevékenységhez milyen adatokra van szükség illetve, hogy milyen adatok jönnek létre a tevékenység végrehajtása esetén. Az adatobjektumokat asszociáció segítségével köthetjük a tevékenységekhez. 53

54 o Group csoport(osítás) A csoportosítást használhatjuk dokumentációs vagy elemzési célokra. Fontos tudni, hogy nincs hatással a szekvencia folyamra. A csoportosítást pontozott-szaggatott vonalú és kerekített sarkú téglalappal jelöljük. o Annotation megjegyzés A megjegyzések segítségével további információkat főzhetünk a BPDhez vagy a BPD egyes elemeihez. Az alapelemeken kívül a BPMN tartalmazza ezek kiterjesztését is, a teljes elem- és szimbólumlista megtalálható a mellékletben. BPD A BPMN jelölésekkel BPD-ket (Business Process Diagram), készíthetünk. Egy BPD többféle típusú lehet, köztük például magas szintő üzleti, részletes üzleti, külsı, nem ismert folyamatokkal együttmőködı, két vagy több folyamat együttmőködését, kollaborációját megjelenítı BPD. A BPD-k különbözı típusai egy ábrán is használhatók, mégis ha túl sok BPD típust használunk egyszerre, akkor a diagram nehezen érthetıvé válhat, így érdemes inkább mindig a BPD egy típusát használni (pl. egyéni folyamatábra vagy kollaborációs folyamatok). WS-BPEL A WS-BPEL (Web Services Business Process Ecexution Language) vagy röviden BPEL nyelvet végrehajtható üzleti folyamatok leírására hozták létre. A BPMN specifikációja tartalmaz egy leírást arról, hogy hogyan lehet a BPMN-t BPEL kódokra fordítani, de sajnos ez a mapping informális és nem teljes [B54]. A BPEL és a BPMN terjedésével számos eszközbe megpróbálták implementálni a kettı közötti konverziót. Egyik ilyen open source eszköz a BPMN2BPEL 1. Ezen eszközök fejlesztése során fény derült néhány BPMN és BPEL közötti alapvetı különbségre, ami miatt számos esetben nem lehet a BPD-ket BPEL-é konvertálni. Még nehezebb a helyzet, ha ember számára olvasható BPEL kódot szeretnénk generálni, vagy ha a fejlesztés során round-trip engineering megközelítést alkalmazunk [B60]. XPDL Az XPDL (XML Process Definition Language) egy, a Workflow Management Coalition (WfMV) által szabványosított formátum. A szabványos formátum segítséget nyújt a különbözı workflow termékek, modellezı és üzleti folyamatmenedzsment eszközök közötti átjárhatóságra. Az XPDL egy XML sémát definiált az üzleti folyamatok deklaratív részének leírásához. XPDL-ben az üzleti folyamatok grafikus és szemantikai információit tárolhatjuk. Az XPDL-t kifejezetten arra tervezték, hogy a BPD-k minden információját tárolni tudja, így például kétdimenziós koordintákat is, melyekkel az adott BPMN elem BPD-beli helyét írhatjuk le, de ugyanígy tartalmaz végrehajtáshoz kapcsolódó információkat is. Ez lényeges különbség a BPEL és az XPDL között, mivel a BPEL kizárólag a BPMN végrehajtható aspektusaira koncentrál. Így a BPEL nem tartalmaz olyan elemeket, melyek a folyamatok 1 Elérhetı a címen. 54

55 grafikus ábrázolását segítenék. Az XPDL specifikációját lásd a weboldalon. Ábrázolási nyelvek összehasonlítása Szempontok nélkül nehéz összehasonlítást végezni, így elıször meghatároztuk a helyzetbıl fakadó legfontosabb szempontokat, majd ezek szerint választottuk ki az általunk javasolt ábrázolási nyelvet Kiértékelési szempontok Elsıdleges szempontunk az érthetıség, mivel a folyamatábrákat különbözı környezetbıl érkezı emberek fogják értelmezni, használni esetleg módosítani. Az érthetıség képességtıl és háttértıl függı, szubjektív jellemzı, ezért nehezen mérhetı. Mégis néhány kutató érinti ezt a témakört, mint például Mendling [B27] vagy Becker [B9]. A workflow minták reprezentálhatósága a nyelv kifejezıképességét mutatja meg. Egy kevésbé jó kifejezıképességő nyelvvel nı az ábrák bonyolultsága. Az ábrák bonyolultságának növekedésével csökken az érthetıség, növekszik a hibák száma. Ha egy ábra érthetı, alapelemeik egyszerőek, tanulhatóbbá is válik. Mivel minél könnyebben és gyorsabban szeretnénk létrehozni és módosítani folyamatábráinkat, azon túlmenıen, hogy egy érthetı folyamatábrát hozunk létre, szempontunk, hogy megfelelı szoftveres támogatottsággal rendelkezzen az adott megközelítés. A különbözı szolgáltatást nyújtó szervezetek egymástól független szoftvereket használhatnak saját rendszereikben, ezért fontosnak tartjuk, hogy a kiválasztott megközelítés ne függjön egyetlen gyártótól sem (több, különbözı gyártó által forgalmazott szoftver álljon rendelkezésre). Amellett, hogy szabadon megválaszthatjuk a modellezésre felhasznált szoftvert, egy hordozható, más szoftverek által is ismert formátumba való mentés is igen hasznos lehet. Egy technológiát vagy ábrázolási módot minél többen alkalmaznak annál könnyebb bevezetni, elfogadtatni. Emiatt fontos, hogy minél szélesebb körben alkalmazott megoldást javasoljunk a közigazgatási folyamatok leírására és nem egy újat kifejleszteni vagy kevésbé elterjedtet alkalmazni. A fentiek alapján, a következıket találtuk a legfontosabb szempontoknak: érthetıség, workflow minták leírhatósága, szoftveres támogatottság, hordozható formátum, különbözı szférákban való elterjedtség, alkalmazottság, adoptálhatóság. 55

56 Összehasonlítás Az összehasonlítás során az egyes megközelítéseket a bemutatott szempontok alapján értékeljük. A szempontokat fontossági sorrendben tárgyaljuk és a végsı döntés is ez alapján történik Érthetıség Mendlingék [B27] kutatásukba 73 egyetemistát és 12 folyamatmodellezési szakértıt vontak be a Bécsi, az Eindhoveni Mőszaki és a Madeirai egyetemrıl. A résztvevıkkel kérdıíveket töltettek ki, melyek segítségével azt vizsgálták, hogy a mennyire tudják helyesen értelmezni a kérdıívben szereplı 12 féle folyamatábrát. A kutatás azt mutatta ki, hogy a folyamatábrák megértését elsısorban a személyes faktorok, azaz a résztvevık korábbi elméleti és gyakorlati folyamatmodellezési ismeretei, tapasztalatai határozzák meg. A másik fontos tényezı az érthetıség szempontjából a modell mérete, mely különbözı metrikákkal mérhetı [B25][B27]. Az érthetıség további lehetséges befolyásoló tényezıiként határozzák meg az értelmezı a modellezett folyamatokban való jártasságát, a modellezési nyelvet, és az ábra elrendezését. White [B53] érthetıség szempontjából nem látott különbséget az UML 2.0 tevékenységdiagramok és a BPD-k között. A három modellezési nyelv közül az UML-t a szoftvertervezık és -fejlesztık használják, az EPC-t fıleg az üzleti szféra, míg a BPMN-t mindkét fél. Ez nem véletlen, hisz a BPMI célja a BPMN-el egy minden érintett számára érthetı szabványos jelölési mód kidolgozása volt. Így az elsıdleges szempontnak véleményünk szerint a BPMN felel meg a legjobban. Workflow minták kifejezhetısége Mindhárom ábrázolási nyelv hasonló elemekre épül ilyenek például a fork-join, branchmerge, alap és kiterjesztett tevékenységek, de ezeket különbözı jelölésrendszerrel és terminológiával írják le. Néhány elemnek nem létezik megfelelıje a másik diagramban, így ez nehezíti az automatikus konverziót. Néhány ilyen, EPC és UML 1.x tevékenységdiagram közötti jelölésbeli különbséget tárgyal Wienberg [B55]. Az IBM munkatársa, White, felhasználva Aalst és mások eredményeit, BPMN és UML tevékenységdiagramokat hasonlított össze 21 alapvetı workflow minta alapján [B53]. Az összehasonlítás eredményeképp, arra következtetésre jutott, hogy mindkét ábrázolási nyelvvel egyformán jól le lehet írni a vizsgált mintákat. Egyetlen kivételként jelöli meg, hogy a tevékenységdiagram metamodelljének nincs megfelelı struktúrája egy adott workflow minta létrehozásához. A két megközelítés tulajdonképpen egyetlen metamodell különbözı nézete [B53]. Mivel az OMG kezeli a BPMN-t és a tevékenységdiagramokat is, valószínősíthetı, hogy ezek a jövıben konvergálni fognak egymáshoz, esetleg össze fognak olvadni. Az EPC-t Mendling és társai vizsgálták meg, Aalst 20 mintája alapján, és felfedtek néhány apróbb hiányosságot, aminek korrigálására javaslatot tettek [B28]. Belátható, hogy nehéz ebbıl a szempontból rangsorolni a három megközelítést, mivel mindhárommal leírhatók az alapvetı workflow minták, de ha mindenképp különbséget szeretnénk tenni közöttük, akkor White eredményei alapján a BPMN felel meg a legjobban ennek a szempontnak. 56

57 Szoftveres támogatottság A szoftveres támogatottságot összevetve látható, hogy az UML-t (és ezen belül értelemszerően az UML tevékenydiagramokat is) támogatja a legtöbb alkalmazás, ezután következik a BPMN, majd az EPC. Az EPC szoftveres támogatottságában hátránya, hogy indulásakor egy adott vállalatnál fejlesztették ki, míg az UML-t és a BPMN-t a független OMG kezeli, több szoftvercég részvételével. Annak ellenére, hogy az UML-t támogatja a legtöbb modellezı eszköz, bıven lehet találni megfelelı eszközöket a másik két ábrázolási nyelvhez is. Ennek a szempontnak az UML felel meg a legjobban, viszont számos eszköz támogatja az EPC-t és a BPMN-t is. Pl. MS Visioval mindhárom típusú diagram létrehozható. Hordozható formátum A hordozhatóság szempontjából az EPC erıssége a Mendling és társa által definiált EPML [B26], mely egy szabványos és független XML formátum. Kérdés, hogy ezt a különbözı alkalmazások mennyire támogatják/fogják támogatni. Az UML diagramok esetében számos UML modellezı alkalmazás támogatja az OMG által specifikált XMI formátumot (jelenleg még inkompatibilitási problémákkal), vagy exportálni tud valamilyen más, nem szabványosított XML-be. A BPMN esetében kifejezetten a hordozhatóság támogatása érdekében a Workflow Management Coalition definiálta az XPDL-t. Látható, hogy mindhárom formátum XML alapú és ingyenesen elérhetı, de a megvalósítás terén mindhárom esetben léteznek hiányosságok. A lehetıség adott, a szabványosított formátum alkalmazása a gyártókon múlik. A BPMN-t és az UML-t támogató formátumokat egy-egy konzorcium specifikálta, emiatt valószínőleg nagyobb támogatottságra számíthatnak, mint az EPC. A hordozhatóság szempontjából (az XMI formátum miatt, amit már több gyártó implementált) az UML tartjuk a legmegfelelıbbnek. Elterjedtség Az OMG többéves professzionális múltja miatt, az általa kezelt/szabványosított jelöléseket, formátumokat a gyártók ma már gyorsan elfogadják, adoptálják, így ez meghatározó tényezı az UML és a BPMN elterjedtségének tekintetében. Az EPC-t, indulásakor egy konkrét vállalatnál vezették be és nem állt mögötte konzorcium, ezért az elterjedése is szerényebb az elıbbi kettınél. Az IT szektor szinte kizárólagosan UML-t használ modellezési célokra, ez a legelterjedtebb a szoftvervilágban. Az üzleti szférában sokféle jelölést használnak az egyszerő folyamatábráktól, a sajátos jelöléseken keresztül a BPMN, UML és EPC-ig, így nehéz megmondani, hogy ott mi az elterjedtebb, így az UML-t gondoljuk a legelterjedtebb megoldásnak. Összegzés Az összehasonlítás alapján látható, hogy mindhárom jelölésrendszernek számos elınye van, és mindegyik valamilyen szempontból kitőnik. Ugyanakkor a meghatározott 57

58 szempontrendszert figyelembe véve, az érthetıséget és a workflow minták kifejezhetıségét illetıen a BPMN tőnik a legjobb megoldásnak, az UML tevékenységdiagramnak viszont a legnagyobb a szoftveres támogatottsága, vagy egy részben jól implementált közös formátuma és (fıleg IT területen) nagyon elterjedt. A következı táblázat összefoglalja az összehasonlítás eredményét, a szempontokat fontossági sorrend szerint feltüntetve. BPMN EPC UML tevékenységdiagramok Érthetıség + Workflow minták kifejezhetısége + Szoftveres támogatottság + Hordozható formátum + Elterjedtség + 1. táblázat ábrázolási nyelvek összehasonlítása A fent említett ábrázolási megoldások kiválasztásánál nehéz jó döntést hozni, mivel sok szempontból nagyon kevés különbség van közöttük. Annak ellenére, hogy az UML több szempontnak felel meg mint a BPMN, végsı megoldásként a BPMN-t javasoljuk a folyamatok ábrázolásához, mivel: az elsı két legfontosabb szempontból a legmegfelelıbb (érthetıség és workflow minták reprezentálhatósága) kellı szoftveres támogatottsággal rendelkezik, hordozhatóság szempontjából mindhárom megoldás, nagyon hasonló formátummal rendelkezik, (az UML egy árnyalattal, implementáltság szempontjából jár elırébb e téren), az üzleti szférában elterjedt, emellett úgy gondoljuk, hogy könnyő érthetısége és az OMG támogatása miatt elterjedtsége (az UML-éhez hasonlóan) gyorsan fog növekedni. 7. Folyamatok helyességének ellenırzése A folyamatok helyességének ellenırzése a következı 4 lépésbıl áll: Inkonzisztens folyamatok módosításra jelölése, Redundáns részeket tartalmazó folyamatleírások módosításra jelölése, Jogszabályoknak való megfelelıség vizsgálata, Azon folyamatok módosításra jelölése, melyek még csak külsı jellemzıikben kerültek kidolgozásra, de a belsı jellemzık leírása is fontos. A folyamatokat helyességük alapján két csoportba soroljuk: a) Nyitott folyamat: módosításokra nyitott folyamat. b) Lezárt folyamat: a folyamat teljesnek tekinthetı, helyessége ellenırzött és módosításra nem nyitott. Egy nyitott folyamat 4 lehetséges állapota: konzisztens és redundancia mentes, konzisztens és redundáns, inkonzisztens és redundancia mentes, inkonzisztens és redundáns. 58

59 A folyamatleírásokat és folyamatábrákat inkonzisztencia és redundancia szempontjából kell ellenırizni. A nyitott folyamat állapotát meg kell határozni, majd konzisztens és redundancia mentes állapotra hozni. Lezárt folyamat estén a folyamatot az érintettek teljes körének bevonásával meg kell nyitni és meg kell szüntetni az inkonzisztenciát és redundanciát Konzisztencia vizsgálat A konzisztencia fontossága és lényege az e-közigazgatás területén abban áll, hogy egy közigazgatási folyamatról, az eddigi ismert gyakorlatokat, törvényszerőségeket visszatükrözı letérképezést (folyamatleírásokat) kell létrehozni, mely ezen folyamatok elemeinek (késıbbiekben egyre több folyamat) értékét és helyét meghatározza. Kiküszöbölve ezzel, hogy a közigazgatásban ugyanazon szolgáltatásra több egymásnak ellentmondó folyamat is létezhet. Folyamat inkonzisztencia alatt azt az állapotot értjük, amikor egy folyamatleírásban vagy folyamatábrán önmagának vagy más folyamatoknak ellentmondó információk szerepelnek. Az ellentmondás-mentesség csak akkor lehet biztos, ha minden adat és ezek keletkezési módja pontosan dokumentált, illetve az egymással oksági kapcsolatba hozható adatok kapcsolatrendszerét leíró táblázat adott, mely alapján a szakmai hibaelemzés elvégezhetı. Az konzisztenciát/inkonzisztenciát vizsgálni kell: csoportosítások, halmazok esetén, hierarchia kialakítása során, alá-fölé rendeltség megállapításakor (pl.: inkonzisztencia: B részhalmaza A-nak, C részhalmaza B-nek, A részhalmaza C-nek), állítások, kijelentések rögzítésekor (tényeknek ellentmond vagy sem), jogszabályi, szabályzati hivatkozások terén (a folyamatleírásban/leírásokban a hivatkozások vonatkozhatnak más idıpontban kiadott határozatokra, módosított törvényekre) Inkonzisztencia feltárására javasoljuk, hogy az azonos vagy hasonló területen felmérést végzı csapatok munkájuk eredményét mutassák be egymásnak. Kapcsolódó folyamatok, illetve folyamatok kapcsolódási pontjainál ajánlott a prezentációt kötelezı elemé tenni a felmérési folyamatban. Inkonzisztencia vizsgálatára és megszüntetésére alkalmasak a 5.5. fejezetben bemutatott szakértıi véleményeztetések. A konzisztencia vizsgálat szoftveres eszközökkel is támogatható. Általános lépések: a) Folyamatok átvizsgálása (leírások átolvasása, ábrák áttekintése, prezentáción való részvétel). b) Inkonzisztens elemek azonosítása, az érintettek tájékoztatása. c) Inkonzisztencia feloldása (szakértıi vélemények, információk ismételt beszerzése, aktualizálása, a várható módosításokhoz jóváhagyás elnyerése az érintettektıl). d) Inkonzisztencia megszüntetése. Figyeljünk arra, hogy a folyamatleírás frissítésekor sok esetben az ábrát is frissíteni kell. Mindig meg kell vizsgálni, hogy a folyamatleírás és a folyamatábra ugyanazt az 59

60 információt tartalmazza-e. Amennyiben nem, az ellentmondásokat a valós állapotnak megfelelıen kell korrigálni. e) A feltárt inkonzisztenciát és a nyert tapasztalatokat publikálása. (Legalább az érintettek és az összes felmérést végzı csapat között.) 7.2. Redundancia vizsgálat Redundancia több kapcsolódó, egymással kapcsolatban álló folyamat között gyakran megfigyelhetı. A folyamatfelmérés és fejlesztés hatékony eszköze a felesleges ismétlıdések csökkentésének. Ebben a fejezetben azonban a folyamatleírások redundanciájának megszüntetésére, csökkentésére fektetjük a hangsúlyt és a felesleges, a leíráskészítés és ábrázolás nehézségeibıl adódó ismétlıdésekre fókuszálunk. Egy folyamatleírás vagy folyamatábra redundáns, ha egy információ (feleslegesen) ismétlıdik, többször elıfordul benne. Redundancia figyelhetı meg folyamatok között (külsı) és folyamatelemek között (belsı) is. A belsı ismétlıdéseket a folyamatleírás készítés korai szakaszában azonosíthatjuk, és lehetıségeinkhez mérten törekedjünk megszüntetésükre (ez a leírást készítı személy/személyek feladata). A folyamatok közötti ismétlıdések azonosítását és megszüntetését a felmérés egészét koordináló, támogató és ellenırzı csapat tudja elvégezni, illetve a felmérést végzı csapatok együttes, céltudatos együttmőködésével elızhetı meg. Ezért fontos, hogy a csapatok egymás munkáját és eredményeit láthassák. Az ismétlıdések azonosítására és megszüntetésére alkalmasak a 5.5. fejezetben bemutatott szakértıi vélemények feltárását részletezı módszerek. Természetesen ilyen nagy volumenő feladatok esetén, mint az e-közigazgatás kialakítása javasolt további eszközök alkalmazása is (pl.: szoftver). Általános lépések: a) Folyamatok átvizsgálása (leírások átolvasása, ábrák áttekintése, prezentáción való részvétel); b) Redundancia azonosítása, az érintettek tájékoztatása. c) Ismétlıdés megszüntetése, ismétlıdı részek kiemelése (pl.: külön folyamatba, tájékoztató információt tartalmazó egységes, közös leíró állományba /pl.: fogalomtár/). A folyamatok kiemelése megegyezik a folyamat azonosítása-majd módosítása lépéssorozattal, amelyet az 12. ábra szemléltet. A kiemelést követıen is el kell végezni a szükséges konzisztencia és redundancia- vizsgálatot. d) Az azonosított, kiemelt redundáns elemek publikálása. (Az összes felmérést végzı csapat részére.) A redundancia megjelenésének legfıbb okai: folyamatokat fel lehet bontani részfolyamatokra, folyamatoknak azonos részfolyamatai vannak (pl.: az ügyindulás vagy a hiánypótlás folyamata), 60

61 folyamatelemek más folyamatokban is megjelennek, túlzott mélységő részletezettség Inkonzisztencia és redundancia egy idıben Inkonzisztencia és redundancia felléphet akár egy idıben is. Abban az esetben például, amikor párhuzamosan több résztvevı dolgozik a folyamatok leírásán, és egyszerre többen felismerik egy részfolyamat kiemelhetıségét, a redundancia és inkonzisztencia egyszerre is felléphet. Ilyenkor megtörténhet, hogy egy több folyamatban megjelenı részfolyamatot többször is kiemelünk és az új, kiemelt folyamatot különbözıképpen írjuk le. Ezért kiemelten fontos a folyamatok létrehozásakor, módosításakor mindkét ellenırzést elvégezni. 8. Folyamat mérése, indikátorok A mérések által olyan kulcsinformációkhoz juthatunk, melyek hozzásegítenek a folyamatok, objektumok fejlesztéséhez. A mérés segít, hogy összefüggéseket megértsünk, hogy irányítani tudjuk az eseményeket, hogy a termékeket/szolgáltatásokat, elvégzett feladatokat értékelni tudjuk, össze tudjuk hasonlítani egymással, hogy a jövıben bekövetkezı eseményeket minél pontosabban meg tudjuk jósolni. Gyakorlati tapasztalat, hogy a felmérést követıen igény van folyamatok, illetve a folyamatok teljesítményének javítására. Belátható, hogy mérıszámokra van szükségünk (mert csak azt tudjuk javítani, amit mérni vagyunk képesek). Ezért fontos a felmérési szakaszban mérıszámok azonosítása, használata. Egy adott folyamathoz többre is, kezdetnek három mérési terület is elegendı az alapok megteremtéséhez: gyorsaságra vonatkozó, költségre vonatkozó, minıségre vonatkozó mérıszámok és mérések. Nagyon fontos, hogy a méréseket a folyamat kiegyensúlyozására is felhasználjuk. Az egyensúlyvesztés könnyen okozhat problémákat, például gyorsak vagyunk, de rossz a minıségünk és drágán állítjuk elı. A mérés egy ismert könyvében (lásd [B15] ) a következı definíciókat találjuk: Mérés: az a folyamat, amelynek során a valós világ elemeinek attribútumaihoz számokat vagy szimbólumokat rendelünk, abból a célból, hogy valamilyen, jól meghatározott szabály alapján leírjuk, jellemezzük ıket. A mérés direkt vagy indirekt módon végezhetı. Egy attribútum direkt mérése olyan mérés, mely nem függ semmilyen más attribútum mérésétıl (pl. hosszúság). Egy attribútum indirekt mérése olyan mérés, mely magába foglalja egy vagy több további attribútum mérését (pl. sőrőség = tömeg/térfogat). A mérték, mérıszám vagy metrika: egy szám vagy szimbólum kísérleti hozzárendelése egy entitáshoz, valamilyen specifikus attribútum jellemzésére. Az indikátor olyan mérıszám (mutatószám), amely önmagában (pl.: az értékével) képes kimutatni egy figyelt tulajdonság, jellemzı, jelenség megjelenését, eltőnését és/vagy jelenlétét, ezzel a tulajdonságával biztosítja az érzékelhetıséget és a nyomonkövethetıséget. 61

62 Jelen módszertanban a mérés szót a mérési folyamatra, a mérıszám vagy metrika szavakat pedig a mérés eredményére értjük. A metrika és mérıszám szavakat szinonimaként használjuk. A mérés különbözı mérési skálákon történhet. Minél több összehasonlítási, mőveleti lehetıség van egy mérési skálán, annál gazdagabb az a skála. A melléklet fejezetében soroljuk fel az ismert mérési skálákat és legfıbb jellemzıiket. A mérés tárgyát képezı entitás egy attribútuma lehet belsı vagy külsı. Egy termék, folyamat vagy erıforrás belsı attribútumai azok, amelyek tisztán mérhetıek magán a terméken, folyamaton vagy erıforráson. Egy belsı attribútum mérhetı maga a termék, folyamat vagy erıforrás vizsgálatával, függetlenül annak viselkedésétıl. Egy termék, folyamat vagy erıforrás külsı attribútumai azok, amelyek a termék, folyamat vagy erıforrás környezetéhez való kapcsolódásának mikéntjébıl állapíthatóak meg. Itt a termék, folyamat vagy erıforrás viselkedése fontosabb, mint az entitás maga. Az attribútumok megfelelı kiválasztása és ezeknek a megfelelı metrikával való társítása komplex feladat. A munkát nehezíti az a tény, hogy nincsenek univerzálisan elfogadott modellek az attribútumok és a metrikák kiválasztására. A létezı modellek, szabványok és ajánlások kiindulópontként használhatóak, de csak a tapasztalat segíthet igazán a mérések megfelelı módon való végrehajtásában. A méréssel foglalkozó szakirodalomban számos leírást találunk a jó metrikáról. Lássuk például a jó mérés hét kritériumát, melyeket Gillies mutat be. Ezek a kritériumok a metrikák kiválasztásában segítenek, bármely mérés elvégzése esetén. Kritérium Objektivitás Megbízhatóság Érvényesség Szabványosítottság Összehasonlíthatóság Gazdaságosság Használhatóság Értelmezés Az eredményeknek szubjektív hatásoktól menteseknek kell lenniük. Nem szabad számítania annak, hogy ki végzi a mérést. Az eredményeknek precízeknek és megismételhetıeknek kell lenniük. A metrikának a megfelelı (helyes) jellemzıt kell mérnie. A metrikának egyértelmőnek és összehasonlításra alkalmasnak kell lennie. A metrikának összehasonlíthatónak kell lennie más, hasonló kritériumú metrikákkal. Az egyszerőbb, és ennélfogva olcsóbb metrikák használata a jobb. Egy metrika oka egy igény kell, hogy legyen, nem mérünk egy tulajdonságot pusztán kedvtelésbıl. 2. Táblázat: Gillies hét kritériuma a jó metrika kiválasztásához. Forrás: [B17] A fenti táblázatban a mérıszám objektivitása elsı helyen szerepel. Ezzel együtt, elıfordul, hogy nem találunk megfelelı objektív mérıszámokat, s ilyen esetekben a szubjektív mérıszámok is hasznos információt hordozhatnak (pl. besorolások, egyetértési skálák stb.). A hat szigma módszertana (amely termelésben és a szolgáltatások területén egyaránt elfogadott és hatékony módszertan) a méréseket rendkívül alaposan, rendszerezetten, célorientáltan és integráltan kezeli, ezért fontosnak tartjuk a mérésre vonatkozó logikai vázát röviden bemutatni. Fontos megjegyezni, hogy a hat szigma ennél jóval részletesebb és nagyobb terjedelemben foglalkozik a mérésekkel, jelen fejezetben nem célunk ezen részletek bemutatása. Jelen fejezetben, azért mutatjuk be a hat szigma mérésekre vonatkozó lépéseit, mert: 62

63 megfelelı alapot teremt a mérések és a méréshez kapcsolat feladatok áttekintéséhez, segítséget nyújt a mérés, mint tevékenység megismerésére, saját igényeinken alapuló méréseink kialakítására, és alapot teremt a folyamatfelmérés során megjelenı metrikák besorolására, funkciójának felismerésére. A mérés lépései: a) A folyamatelemzés és dokumentálás Folyamat modellezése (folyamattérképek, leírások, ábrák kialakítása). A folyamat bemenetei és kimenetei, kapcsolatuk azonosítás. b) Valószínőség és statisztika Helyes statisztikai következtetések megtétele (a leíró és az elemzı vizsgálatok elkülönítése). A központi határeloszlás tétele és a mintaátlag eloszlása. Valószínőségi alapfogalmak leírása (függıség, kölcsönös kizárás). c) Az adatok győjtése és összesítése Az adatok fajtái és mérési skálái (Folytonos és diszkrét adatok azonosítása, osztályozása. A névleges, rangsorolási, intervallum, és arányossági skálák leírása és meghatározása.) Adatgyőjtési módszerek meghatározása (pl.: ellenırzési lapok). Módszerek az adatok pontosságának és épségének biztosítására (pl.: véletlen mintavétel, homogenitás vizsgálat). Leíró statisztikák meghatározása, számítása (pl.: gyakoriság eloszlások, szóródási mérıszámok: terjedelem, szórás, szórásnégyzet, átlagos abszolút eltérés) Az összefüggések leírása, ábrázolása grafikus módszerekkel (pl.: diagramok, hisztogramok, Gauss valószínőségi hálók). d) Valószínőségi eloszlások számítása és értelmezése az összegyőjtött adatokból. (pl.: normális, Poisson-, t-eloszlás, F-eloszlás) e) Mérırendszer jellemzıinek elemzése (pl.: ismételhetıségre, reprodukálhatóságra, torzításra, pontosságra vonatkozóan). f) Folyamatképesség és folyamatteljesítmény Folyamatképesség vizsgálatok tervezési és végrehajtási elemeinek azonosítása (pl.: folyamat jellemzık, tőréshatárok, mintavételi tervek). A természetes folyamathatárok és a tőréshatárok közötti különbség meghatározása és mérıszámok számítása (pl.: hibás termék/teljesítési szám) Folyamatképesség-indexek (minıségképesség-indexek) meghatározása, számítása és értékelése. (C p és C pk indexek, részletesen kifejtve lásd: [B59]). Folyamatteljesítmény-indexek meghatározása, számítása és értékelése (P p, P pk, C pm indexek, részletesen kifejtve lásd: [B59]). 63

64 Rövid-távú és hosszú-távú mérésekkel kapcsolatos feltételek és szokások leírása, hogy a mérések értelmezhetısége, összehasonlíthatósága, aggregálása megoldott, megoldható legyen. Folyamatképesség minısítéses (szervezet által, folyamatra vonatkozón meghatározott) adatok alapján. (Ez a pont a folyamat szigma szintjének megállapítását jelenti, csak a hat szigma alkalmazása esetén lehet értelmezni.) A méréseket és a kapott eredményeket, természetesen, az elemzés, majd a fejlesztés követi. A további lépések elmulasztása a méréseket öncélúvá teszi. 9. Összefoglalás Jelen ajánlás az 1. ábrán vázolt folyamat elsı lépésének megvalósítási módját részletezi a 2. ábrán azonosítható tevékenységek leírásával. Az ajánlás a tevékenységek gyakorlati megvalósításához szükséges ismeretanyag bemutatására fekteti a hangsúlyt. A gyakorlati tevékenységek elvégzéséhez szükséges legfıbb elméleti ismereteket a dokumentáció mellékleteiben mutatjuk be. Az ajánláshoz kapcsolódóan készült egy gyakorlati útmutató (Folyamatleírást segítı gyakorlati útmutató), amely a 2. ábrán bemutatott tevékenységek alapján végrehajtott felmérés eredményeit mutatja be példaként. 64

65 10. Mellékletek Folyamatok az üzleti életben és a szoftverfejlesztésben A folyamat elnevezést manapság igen sok értelemben használjuk (tanulás folyamata, autóvezetés folyamata, fejlıdés folyamata ). Kiemelt helyet foglalnak el szóhasználatunkban az üzleti folyamatok (business process), amelyek különbözı szervezetek tevékenységét jellemzik. Nem teljes a konszenzus arra vonatkozóan, hogy az üzleti folyamatok csak azok-e, amelyek eredményeképpen a szervezet üzletet köt, pénzt szerez, vagy azok is, amelyek ugyan csak közvetve járulnak hozzá üzleti célok eléréséhez, de a célok megvalósulása nem lenne lehetséges nélkülük (pl. erıforrás toborzása, képzése, belsı infrastruktúra üzemeltetése, titkársági tevékenység stb.). A melléklet ezen fejezetének célja, hogy a szabványok és modellek részletes bemutatásával átfogó képet kapjunk, több szempontból is a folyamatokról. Ha egy szervezet tevékenységét vizsgáljuk, többféle csoportosítása lehetséges az azt mőködtetı folyamatoknak. Elterjedt, és az ISO 9001:2000 által is támogatott az a szemlélet, amely a folyamatokat vezetési/ stratégiai, értékteremtı és támogató folyamatokra osztja. Egyes megközelítések (lásd pl. CMMI, SPICE) külön kategóriaként említik a szervezeti folyamatokat. Az alábbiakban ismertetjük a folyamatcsoportok sajátosságait. A vezetési /stratégiai folyamatok biztosítják a szervezet sikerességét, hosszú távú fennmaradását. Tartalmazzák a tervezést (stratégiai, pénzügyi, mőszaki, minıségügyi ), követést és vezérlést. Az értékteremtı folyamatok azok, amelyeket a szervezet azért végez, hogy profiljának megfelelıen megjelenhessen és megmaradhasson a társadalomban, a piacon. Értékteremtı folyamatok egy szoftverfejlesztı cég szoftver elıállításával kapcsolatos mőszaki folyamatok (elemzés, tervezés, kódolás, tesztelés, dokumentálás stb.), egy oktatást végzı szervezet esetében az oktatás megszervezése, a tananyag biztosítása, az oktatás lebonyolítása, egészségügyi intézmény esetében a betegek ellátása stb. A támogató folyamatok közvetlenül nem vesznek részt a szervezet alaptevékenységében, de az alaptevékenység, az értékteremtı folyamatok végrehajtása nem lenne lehetséges nélkülük. Támogató folyamatot végez a titkársági dolgozó a postai küldemények iktatásakor és kézbesítésekor, a rendszergazda az információk védelmi rendszerének kiépítésekor és üzemeltetésekor, az adatok mentésekor, de támogató tevékenység valamely intézményben az információszolgáltatás, portaszolgálat is. A szervezeti folyamatok részben hasonlóak a támogató folyamatokhoz (némely szerzık nem is tekintik a szervezeti folyamatokat külön folyamatcsoportnak), de a szervezet optimális mőködését, hosszú távú fennmaradását szolgálják. Ilyen tevékenységek például a humán erıforrások toborzása, képzése, a szervezeti tudásvagyon kialakítása és karbantartása, vagy a szervezet folyamatainak feltérképezése, dokumentálása és folyamatos fejlesztése is. Üzleti folyamatként elsısorban az adás-vétel tárgyát képezı javak vagy szolgáltatások elıállításának céljából indított tevékenységsorozatokat szoktuk emlegetni, valójában azonban 65

66 az állami szerepvállalást feltételezı, állampolgároknak nyújtott szolgáltatások folyamatait is ide kell érteni. Ilyenformán üzleti folyamatokat találunk az állami hivatalokban, önkormányzatoknál, tanintézményekben, egészségügyben (pontos szabályoknak megfelelı üzleti folyamat pl. az adófizetés is). Az ISO 9001:2000 minıségirányítási folyamat-modelljét a 16. ábra szemlélteti. Minıségirányítási rendszer Folyamatos fejlesztés Vevı Erıforrás gazdálkodás Vezetés felelıssége Mérés, elemzés, fejlesztés Vevı Elégedettség Követelmények bemenet kimenet 16. ábra: Az ISO 9001:2000 minıségirányítási folyamatának modellje. Forrás: ISO 9001:2000 Ezek szerint, a vevı követelményeket fogalmaz meg, melyek alapján a szervezet terméket vagy szolgáltatást hoz létre. Érdemes megjegyezni, hogy a vevı a szervezet belsı tagja is lehet, és a termék vagy szolgáltatás létrehozása is történhet valamely szervezet belsı igényeit kielégítendı. Az átadott termék vagy szolgáltatás a vevı bizonyos fokú elégedettségét eredményezi. A vevıi elégedettség növelése érdekében a cég minıségügyi szervezetet hoz létre, belsı minıségirányítási rendszert alakít ki és mőködtet, amelyben saját folyamatait azonosítja, szükség szerint dokumentálja, fontos jellemzıiket méri, a mérés eredményeit elemzi és a folyamatos fejlesztés, fejlıdés érdekében használja fel ıket. A KSZK (Kormányzati Személyügyi Szolgáltató és Közigazgatási Képzési Központ, ) anyagai között, egy 2007 áprilisában kelt, ügymenet modellezéssel foglalkozó anyag (lásd: [B29] ) szerint, az államreform megkívánja a folyamatszemlélető gondolkodás alkalmazását a közigazgatás gyakorlatában. Az új közmenedzsment alapvetıen a szervezeti struktúra folyamatelvő átalakítására koncentrál, ennek megfelelıen a szervezet fı folyamatainak áttekintésére van elsısorban szükség, míg az elektronikus technológia váltás során az egyes munkafolyamatok standardizálása, automatizálása az egyedi munkafolyamatok elemi szintő leírását, technologizálását követeli meg. Láthatjuk, hogy itt is megjelennek a fı folyamatok. Maga a leírás, standardizálás, ITvel támogatott mőködtetés pedig (kimondatlanul) támogató folyamatként vannak jelen a közigazgatásban. 66

67 A fent idézett anyag további részleteket közöl a közigazgatási folyamatokról, hangsúlyozva a közigazgatásban mőködı folyamatok fontosságát. Ezek szerint: A közigazgatás céljait és eredményeit a mőködési folyamatok kötik össze. A munkafolyamatok összessége a hivatali mőködés dinamikáját jelenítik meg. A mőködési folyamatok idıbeliséget adnak a közigazgatási funkcióknak, feladatoknak és bemutatják a munkafolyamatok mőködési elemeinek összekapcsolódási logikáját. A szervezet fejlesztés mellett az igazgatási munka technológiájának korszerősítése teszi lehetıvé a szervezeti teljesítmények emelését, a közigazgatás hatékonyságának növelését. A közigazgatás eredményessége, hatékonysága a közigazgatás produktumaiból kiindulva ragadható meg, amelyeket a munkafolyamatok állítanak elı. A folyamatközpontú közigazgatás-szervezés lényege az, hogy a teljesítményre ható tényezıket a produktumokban, illetve az elıállításukra szolgáló munkafolyamatok mozzanataiban keressük meg. A közigazgatásban mőködı folyamatok meghatározásának igényére utal az a kezdeményezés is, melynek során, 2007 augusztusában 2797 állami közfeladatot azonosítottak (ezeket u.n. Állami feladatkataszter írja le, lásd [B13] ), ezekbe kb tevékenység tartozik Az üzleti/közigazgatási folyamatok között a számítógéppel/automatizálást biztosító eszközzel végrehajtott folyamatok egyre nagyobb szerepet kapnak. A szervezetek mőködésében vannak egyértelmően támogató kategóriába sorolható IT folyamatok. Ilyenek a számítógép-hálózatok üzemeltetése, vírusvédelem, tőzfalak mőködtetése, rendszeres adatmentések és archiválások végzése stb. Nem egyértelmő, hogy az IT-vel támogatott értékteremtı folyamatok IT-része (pl. őrlapok megjelenítése, adatok tárolása ) értékteremtınek vagy támogatónak nevezendı tény azonban, hogy az IT-rész szervesen összeépül, integrálódik az üzleti/közigazgatási folyamattal. Az integrálódás azt is eredményezi, például, hogy az eredeti folyamaton változtatni kell, hogy az IT támogatást optimálisan lehessen kihasználni. Jelen módszertan szempontjából érdemes hangsúlyozni, hogy a közigazgatási folyamatok modellezése messzemenıen feltételezi az informatikai ismereteket, hiszen döntı fontosságú például a szolgáltatás megfelelı szintő meghatározása, melyhez a folyamatok olyan mélységő felbontása vagy csoportosítása szükséges, hogy lehetıvé váljon informatikai szolgáltatások egyértelmő hozzárendelése a szolgáltatáshoz. A fentiekbıl az a következtetés adódik, hogy az üzleti/közigazgatási és informatikai/szoftverfejlesztési folyamatok szorosan kapcsolódnak egymáshoz struktúrájukban, alapelemeikben hasonlóak. Különbségek az egyes elemek/fogalmak értelmezésébıl adódhatnak. A folyamatok kidolgozásának, rendszerezésének fontos célja ezért egy egységes fogalomtár kialakítása és folyamatos bıvítése is. Érdemes tehát olyan megközelítést alkalmazni a folyamatok meghatározása és modellezése kapcsán, amelyben az informatikai folyamatok messzemenıkig figyelembe veszik az üzleti/közigazgatási folyamatok sajátosságait, másrészrıl, az üzleti/közigazgatási folyamatok modellezésekor (és különösen az ezidáig jelentıs tapasztalatot fel nem halmozott, közigazgatási folyamatok területén) érdemes felhasználni a szoftverfejlesztési és szoftverfolyamat-fejlesztési folyamatok meghatározásában és modellezésében rendelkezésre álló, negyedszázados tapasztalatot. Jelen fejezet következı részeiben a szoftverfejlesztésben kidolgozott, de az üzleti élet és a közigazgatás területén is jól alkalmazható elemeket, megközelítéseket mutatjuk be. 67

68 10.2. Folyamat meghatározási és fejlesztési szabványok, elıírások a szoftverfejlesztésben A szoftverfejlesztési folyamat azoknak a tevékenységeknek, módszereknek, eljárásoknak és transzformációknak az összessége, amelyeket az emberek szoftver fejlesztésének vagy karbantartásának céljából végeznek (lásd [B37]) A szoftverfejlesztési projektek méretének és komplexitásának folyamatos és igen gyors növekedése már a szoftver megjelenése utáni évtizedekben arra sarkallta a szakembereket, hogy tanulmányozzák, értsék meg, határozzák meg, modellezzék a szoftverfejlesztési folyamatot, ha kézben akarják tartani szoftverfejlesztési projektjeiket. A szoftveriparban ezért már az 1980-as évektıl foglalkoztak a szoftverfejlesztésben megjelenı folyamatok azonosításával, leírásával, modellezésével, mérésével, optimalizálásával, továbbfejlesztésével. A szoftverfejlesztést elıször életciklusmodellekkel írták le (vízesés modell, inkrementális fejlesztési modell, spirál modell, V- modell, iteratív fejlesztési modell, extrém programozási modell stb.). Az elsı életciklus modellekben még jobbára a mőszaki tevékenységekre koncentráltak (specifikáció készítés, tervezés, kódolás, tesztelés), késıbb azonban a szoftverfejlesztési projektek irányítási vonatkozásai is helyet kaptak az életciklus modellekben, s ezek mostanra kiegészültek a támogató és, esetenként, szervezeti, vagy külön kiemelt minıségügyi folyamatokkal, sıt, a szoftver által támogatott üzleti folyamatok is helyet kapnak a listában. Az ISO 9000:2000 definíciója szerint a szoftver: szellemi termék, amely egy hordozó médiumon levı információkból áll. Tehát, nem azonos a számítógépes programmal! Megjegyzésként még hozzáteszi a szabvány: A szoftver megjelenhet koncepciók, ügyletek vagy eljárások alakjában. Egy példa a szoftverre a számítógépprogram. Ebbıl is látható, hogy a szoftver fogalmába manapság az üzleti folyamatokkal kapcsolatos információk is beletartoznak. A szakemberek az 1980-as évek végére felismerték, hogy a szoftverfejlesztı cégek nem egyforma hatásfokkal dolgoznak, bár az alkalmazott életciklus modellek akár azonosak is lehetnek különbözı szervezetekben. Kiderült, hogy egyes szervezetek érettebbek mint mások, s ez elsısorban a fegyelmezett folyamat-végrehajtásban érhetı tetten. Az érett szervezetek nagyobb valószínőséggel képesek idıre leszállítani a megfelelı minıségő terméket/szolgáltatást. Felmerült tehát a kérdés: milyen jellemzık mutatják egy szervezet érettségét? Kiderült, hogy egy szervezetben annál valószínőbb a sikeres szoftverfejlesztés, minél több, jól szervezett folyamatot mőködtet a szervezet. A szoftver folyamat érettsége, Paulk szerint (lásd [B37]), annak mértéke, hogy egy folyamat mennyire pontosan meghatározott, vezérelt, mért, ellenırzött és hatékony. Az érett szoftver folyamat tehát meghatározott (definiált), vezérelt, mért, ellenırzött, hatékony és javulásra képes. A folyamat annál érettebb, minél több elem van a helyén az elıbb felsoroltak közül. A szervezet annál érettebb, minél több érett folyamatot alkalmaznak a szervezetben. (Az évek során az a konvenció alakult ki, hogy szervezet érettségérıl és folyamatok képességérıl beszélünk. Megjegyzendı azonban, hogy a két elnevezés gyakran keveredik a mindennapi szóhasználatban. Beszélünk például képesség-érettségi modellekrıl ami teljesen logikus elnevezés, hiszen a szervezet érettségét a folyamatok száma és azok képességi szintje mutatja. ) Lényeges megjegyezni, hogy a szoftverfejlesztés technikai folyamatai kis részét képezik csupán a szervezet sikerességét biztosító folyamatoknak. A sikeres szervezetben a mőszaki folyamatokat jól meghatározott projektirányítási, támogató, szervezeti és egyéb folyamatokba ágyazva hajtják végre. A szoftverfejlesztı cégek folyamatait leíró érettségi-képességi 68

69 modellekben ezért a tisztán mőszaki, tisztán szoftverfejlesztéssel kapcsolatos folyamatok száma a legkisebb! Mivel a szoftvert elıállító szervezetek éppen (és tulajdonképpen csak) mőszaki folyamataikban különböznek az egyéb üzleti tevékenységet végzı cégektıl, közfeladatokat ellátó szervezetektıl, érdemes a szoftverfejlesztésben kidolgozott, kipróbált, sok év tapasztalatát összegyőjtı folyamat meghatározási és folyamatfejlesztési modelleket megvizsgálni, hiszen várható, hogy a szoftverfejlesztés mőszaki jellemzıit leíró folyamatokon kívül ezen modellek összes többi folyamata felhasználható bármely üzleti területen, és a közigazgatásban is. Sıt. A közigazgatási folyamatok IT-vel való támogatottságának növelése céljából kifejezetten szükséges a szoftverfejlesztés technikai folyamataival is foglalkozni Az ISO szabvány folyamatainak részletes bemutatása A szoftverfejlesztési folyamatokat leíró szabványok között fontos az eredetileg 1995-ben megjelent (majd, a 2000-es évek elején kiegészített) ISO/IEC 12207:1995 szabvány (magyarul 2000-tıl áll rendelkezésre, lásd [B19], valamint [B20]). Olyan folyamatokat, tevékenységeket és feladatokat tartalmaz, amelyek szoftvert tartalmazó rendszerek, különálló szoftvertermékek és szoftverszolgáltatások beszerzése, valamint szoftvertermékek szállítása, fejlesztése, üzemeltetése és karbantartása során alkalmazandók. Alkalmazható teljes rendszerek, valamint szoftvertermékek és szoftverszolgáltatások beszerzésénél, szoftvertermékek és förmver szoftverrészének szállítása, fejlesztése, üzemeltetése és karbantartása során, függetlenül attól, hogy azt a szervezeten belül vagy kívül hajtják végre. E szabványnak való megfelelés azt jelenti, hogy végrehajtották az összes olyan folyamatot, tevékenységet és feladatot, amit a projekt céljaira az illesztési folyamat segítségével ebbıl a szabványból kiválasztottak. Minden olyan szervezetnek, amely e szabványt kereskedelmi feltételként elıírja, kötelessége, hogy meghatározza és nyilvánosságra hozza a folyamatok, tevékenységek és feladatok azon legszőkebb körét, amely megfogalmazza a szállítók e nemzetközi szabványnak való megfelelését. szerkezetét, de nem adja meg a folyamatokban szereplı tevékenységek és feladatok Az ISO szabvány korlátja, hogy leírja ugyan a szoftveréletciklus-folyamatok megvalósításának vagy végrehajtásának részleteit, nem írja elı a dokumentáció nevét, formáját, konkrét tartalmát, nem ír elı semmilyen konkrét életciklus modellt vagy fejlesztési módszert. Az ISO szabvány 5., 6. és 7. fejezetei mutatják be a szoftver-életciklus folyamatokat. E fejezetek szerkezetét a 8. ábra szemlélteti. 69

70 5. A z életciklus fı folyamatai 5.1. Beszerzés 5.2. Szállítás 5.3. Fejlesztés 5.4. Üzemeltetés 5.5. Karbantartás 6. A z életciklus támogató folyamatai 6.1. Doku mentálás 6.2. Konfigurációkezelés 6.3. M inıségbiztosítás 6.4. Igazo lás 6.5. Érvényesítés 6.6. Együttes átvizsgálás 6.7. Felü lvizsgálás 6.8. Problémamegoldás 7. A z életciklus szervezeti folyamatai 7.1. Irányítás 7.2. Infrastruktúra biztosítás 7.3. Megújítás 7.4. Képzés 17. ábra: Az ISO szabvány szerkezete Az ISO szabvány átmenetet képez az üzleti szemlélető minıségirányítási szabványok és a technikai jellegő, szoftverminıséghez kapcsolódó szabványok között. Érdemes megemlíteni, hogy az ISO szabvány minden fejezetének megfeleltethetı a szoftverfejlesztéshez kapcsolódó technikai részleteket leíró V-modell. A V-modellt 1997-ben az informatikai rendszerek fejlesztésének életciklusát leíró szabvány keretében tették közzé (lásd [B49]), az akkori Német Szövetségi Köztársaságban, a karbantartás folyamán szereplı összes tevékenységet, terméket, valamint kapcsolatukat Szövetségi közigazgatás számára. Ezek szerint a V-modell a rendszerfejlesztés, módosítás és szabályozza. Elsısorban az IT-vel kapcsolatos feladatokra koncentrál. Az 5.1. Beszerzési folyamat a beszerzı tevékenységeit öleli fel. A Beszerzı: olyan szervezet, amely rendszert, szoftverterméket vagy szoftverszolgáltatást szerez be vagy vásárol meg valamilyen szállítótól (vevı, fogyasztó, tulajdonos, felhasználó, vásárló). A beszerzı projektszinten irányítja a Beszerzési folyamatot olyan Irányítási folyamatnak (7.1.) megfelelıen, amit ahhoz a folyamathoz konkretizáltak, létrehozza a folyamat infrastruktúráját az Infrastruktúrabiztosítási folyamatnak megfelelıen (7.2.), illeszti a folyamatot a projektre az illesztési folyamatnak megfelelıen (A melléklet), és szervezeti szinten irányítja a folyamatot a Megújítási folyamatnak (7.3.) és Képzési folyamatnak (7.4) megfelelıen. A beszerzési folyamat tevékenységei a következık: Elindítás: A beszerzı fogja a rendszerkövetelményeket meghatározni és elemezni. A rendszerkövetelmények tartalmaznak üzleti, szervezeti, felhasználói, biztonsági, védelmi és másféle kritikus követelményeket, a hozzájuk kapcsolódó tervezési, tesztelési és megfelelési szabványokkal és eljárásokkal együtt Ajánlati felhívás készítése Szerzıdés elkészítése és aktualizálása Szállítófigyelés 70

71 Átvétel és befejezés Az 5.2. Szállítási folyamat megadja a szállítónak a tevékenységeit. A Szállító: olyan szervezet, amely a beszerzıvel szerzıdéses kapcsolatba lép valamilyen rendszer, szoftvertermék vagy szoftverszolgáltatás leszállítására a szerzıdéses feltételek betartásával (szerzıdı, termelı, eladó, gyártó- lehet a saját szervezet egy része is). A Szállítási folyamat tevékenységei a következık: Elindítás Válaszkészítés Szerzıdéskötés: A szállító a szerzıdésben módosítást a változásellenırzési eljárásrend keretében kérhet Tervezés: Tartalmazza az életciklus modell meghatározását, a szoftverfejlesztési alternatívák elkészítését, projektirányítási tervek, minıségbiztosítási eljárások elkészítését, beleértve a következık leírását: a projekt szervezet, mőszaki környezet, életciklus-tevékenységek lebontása szoftvertermékeket beleértve, határidık, szoftvertermék minıségi jellemzıi, biztonsági, védelmi és egyéb kritikus követelmények, alvállalkozók kezelése, verifikáció, validáció, szemlék, auditok, kockázatkezelés, jóváhagyás, követés Végrehajtás és ellenırzés: Szoftvertermék fejlesztés a Fejlesztési folyamat szerint, karbantartás a Karbantartási folyamat szerint, üzemeltetés az Üzemeltetési folyamat szerint Átvizsgálás és értékelés: informális megbeszélések, átvételi vizsgálat, átvételi teszt, együttes átvizsgálások és felülvizsgálatok, Igazoló ellenırzések. Követelmény, hogy Az értékelési, átvizsgálási, felülvizsgálati, tesztelési és problémamegoldási dokumentációt hozzáférhetıvé kell tenni a beszerzı számára. Leszállítás és befejezés Az 5.3. Fejlesztés folyamata megadja a fejlesztınek, azaz annak a szervezetnek a tevékenységeit, amelyik meghatározza és kifejleszti a szoftverterméket. A Fejlesztés folyamat tevékenységei a következık: Folyamatkialakítás A rendszerkövetelmények elemzése A rendszer nagyvonalú tervezése A szoftverkövetelmények elemzése A szoftver nagyvonalú tervezése A szoftver részletes tervezése A szoftver kódolása és tesztelése A szoftver integrálása A szoftver minısítési tesztelése A rendszer integrálása A rendszer minısítési tesztelése A szoftver telepítése A szoftver átvételi támogatása Kiemelten fontosnak tartjuk a Fejlesztési folyamathoz tartozó tevékenységet, annál is inkább, mert ezek ebben a szabványban kerülnek a legrészletesebben leírásra. Ezért ezeket részletesen is ismertetjük. A szabványkövetelmény itt az, hogy a fejlesztendı rendszer konkrét, tervezett használatát elemezni kell, hogy a rendszer követelményeit meg lehessen fogalmazni. A követelményspecifikációban le kell írni: a funkciókat és a rendszer képességeit, a szervezeti és felhasználói követelményeket, az üzleti, a szervezeti és a felhasználói követelményeket, a 71

72 biztonsági, védelmi, ergonómiai követelményeket, interfész követelményeket, üzemeltetési és karbantartási követelményeket, a tervezési és minısítési követelményeket. A rendszer követelményspecifikációját dokumentálni kell. A rendszer követelményeit ki kell értékeli az alábbi kritériumok figyelembevételével: A beszerzési igényekre való visszavezethetıség A beszerzési igényekkel való összeegyeztethetıség Tesztelhetıség A rendszer nagyvonalú tervének megvalósíthatósága Az üzemeltetés és karbantarthatóság megvalósítása Az értékelések eredményét dokumentálni kell A szoftverkövetelmények elemzése rész elıírja, hogy minden szoftverelemre (vagy konfigurációs elemre, ha külön azonosították) ez a tevékenység a következı feladatokból áll: Meg kell állapítani és dokumentálni kell a szoftverkövetelményeket, beleértve a következı minıségi jellemzık leírását (ISO 9126) Funkcionális és képességjellegő leírások, beleértve a teljesítményt, fizikai jellemzıket, környezeti feltételeket Szoftverelem külsı interfészei Minısítési követelmények Biztonsági és védelmi elıírások Ergonómiai elıírások Adatleírások, adatbázis követelmények Telepítési és átvételi követelmények Felhasználói dokumentáció, kezelési, végrehajtási, karbantartási követelmények A fejlesztınek a szoftverkövetelményeket ki kell értékelni következı kritériumok figyelembevételével: A rendszerkövetelményekre és rendszertervre való visszavezethetıség A rendszerkövetelményekkel való külsı összeegyeztethetıség Belsı összeegyeztethetıség Tesztelhetıség A szoftverterv megvalósíthatósága Az üzemeltetés és karbantartás megvalósíthatósága A kiértékelés eredményét dokumentálni kell A fejlesztınek a szoftverkövetelményeket ki kell értékelnie az alábbiak alapján: A rendszerkövetelményekre és a rendszertervre való visszavezethetıség A rendszerkövetelményekkel való külsı összeegyeztethetıség Belsı összeegyeztethetıség Tesztelhetıség A szoftverterv megvalósíthatósága Az üzemeltetés és karbantartás megvalósíthatósága A fejlesztınek nagyvonalú átvizsgálásokat kell tartania a 6.6-tal összhangban A szoftver nagyvonalú tervezése során a fejlesztınek a szoftverelemre vonatkozó követelményeket át kell alakítani egy olyan architektúrává, amely leírja a felsı szintő szerkezetét és meghatározza a szoftverkomponenseket. Tevékenységek: Adatbázis felsı szintő terve Felhasználói dokumentáció elsı verziója Tesztkövetelmények meghatározása, dokumentálása, integrálás ütemezése Architektúra kiértékelése Fejlesztı és beszerzı együttes átvizsgálást tart 72

73 A szoftver részletes tervezése azt jelenti, hogy részletes terv készül minden szoftverkomponensre, elkészül az interfészek terve, adatbázis részletes terve, megtörténik a felhasználói dokumentáció aktualizálása. Megtörténik a tesztkövetelmények meghatározása, dokumentálása, szoftveregységek tesztelésének ütemterve. A tesztkövetelmények tartalmazzák a szoftveregységek terhelését követelményeik határértékein. Megtörténik még a tesztkövetelmények és integrációs terv aktualizálása, a részletes szoftverterv és tesztkövetelmények kiértékelése, majd a fejlesztı és beszerzı együttes átvizsgálást tart A szoftver kódolása és tesztelése: kimondja, hogy ki kell dolgozni és dokumentálni kell minden egyes szoftveregységet és az adatbázist, ezekre teszteljárások és tesztadatok kidolgozása meg kell történjen. Minden egységet és az adatbázist le kell tesztelni ezzel garantálva, hogy a követelményeket teljesítik. Teszteredményeket dokumentálni kell. Megtörténik a tesztkövetelmények és ütemterv aktualizálása, valamint a szoftverkód és teszteredmények kiértékelése. A szoftver integrálása a következı tevékenységek elvégzését jelenti: Integrálási terv, mely tartalmazza a tesztkövetelményeket, teszteljárásokat, tesztadatokat, felelısségeket és ütemtervet Integrálás elvégzése, tesztelés Felhasználói dokumentáció aktualizálása A szoftverelem minden minısítési követelményéhez ki kell dolgozni a teszteket, teszteseteket (bemeneti és kimeneti adatok, tesztkritériumok) Integrálási terv, mőszaki terv, kód, tesztek, teszteredmények és felhasználói dokumentáció kiértékelése Együttes átvizsgálások A szoftver minısítı tesztelése minden szoftverelemre elvégzendı. Minısítési tesztqualification testing: a fejlesztı által (lehetıség szerint) a beszerzı jelenlétében végzett tesztelés annak kimutatására, hogy egy adott szoftvertermék kielégíti a specifikációját, és készen áll a célkörnyezetben való használatra. A fejlesztınek minısítési tesztelést kell végeznie a szoftverelemre vonatkozó minısítési követelményekkel összhangban. Biztosítani kell, hogy minden egyes szoftverkövetelményre a megvalósítás megfelelıségét leteszteljék. A tesztelés eredményét dokumentálni kell. A felhasználói dokumentáció aktualizálása meg kell történjen, s ugyanígy a mőszaki terv, kód, tesztek, teszteredmények, felhasználói dokumentáció kiértékelése. Vizsgálni kell a szoftverelem követelményeinek tesztlefedettségét, a megfelelést az elvárt eredményeknek, a rendszer integrálásának és tesztelésének megvalósíthatóságát, ha elvégzik, az üzemeltetés és karbantartás megvalósítását. A fejlesztınek támogatnia kell a felülvizsgálatok lebonyolítását a 6.7-tel összhangban. A felülvizsgálat után (ha végeztek ilyent) aktualizálni kell a leszállítandó szoftverterméket, létre kell hozni a szoftverelem tervének és kódjának alapváltozatát Alapváltozat (baseline): valamely konfigurációs elem formálisan jóváhagyott verziója, amelyet tekintet nélkül az adathordozóra formálisan megjelölnek és rögzítenek a konfigurációs elem életciklusának egy adott idıpontjában. A rendszer integrálása során a szoftverkonfigurációs elemeket rendszerré kell integrálni a hardverkonfigurációs elemekkel, a kézi mőveletekkel, és, ha szükséges, más rendszerekkel. Az aggregátumokat tesztelni kell a követelményeikkel szemben, a tesztelés eredményét dokumentálni kell.a rendszer minden minısítési követelményére teszteket, teszteseteket és teszteljárásokat kell kidolgozni a Rendszer minısítı tesztelésének végrehajtása érdekében, az integrált rendszert ki kell értékelni, az értékelés eredményét dokumentálni kell A rendszer minısítı tesztelése: A rendszer minısítı tesztelését el kell végezni a rendszerre elıírt minısítési követelményekkel összhangban. Biztosítani kell, hogy az egyes 73

74 rendszerkövetelmények megvalósítása a megfelelıség szempontjából is le legyen tesztelve, és a rendszer készen álljon a leszállításra. A tesztelés eredményét dokumentálni kell. A rendszer kiértékelése: A rendszerkövetelmények tesztlefedettsége, megfelelés az elvárt eredményeknek, az üzemeltetés és karbantartás megvalósítása. A fejlesztınek támogatnia kell a felülvizsgálatok lebonyolítását a 6.7-tel összhangban. A felülvizsgálat után aktualizálni kell és elı kell készíteni a leszállítandó szoftverterméket a szoftver telepítésére és a szoftver átvételi tesztelésére, létre kell hozni minden szoftverelem tervének és kódjának alapváltozatát. Az 5.4: Üzemeltetési folyamat megadja az üzemeltetınek, azaz annak a szervezetnek a tevékenységeit, amelyik mint szolgáltatást a számítógépes rendszer üzemelését, annak valós környezetében a felhasználói számára biztosítja. Tevékenységek: Folyamatkialakítás Üzemi tesztelés: A szoftvertermék minden kiadásakor az üzemeltetınek üzemi (operational) tesztet kell végrehajtania, és, ha az elıírt kritériumok teljesülnek, a szoftverterméket üzemi használatra ki kell adni. Az üzemeltetınek biztosítani kell, hogy a szoftverkód és az adatbázis a tervben leírtak szerint induljon el, mőködjön és álljon le Rendszerüzemeltetés Felhasználói támogatás Az 5.5: Karbantartási folyamat megadja a karbantartónak, azaz annak a szervezetnek a tevékenységeit, amelyik mint szolgáltatást a szoftvertermék karbantartását biztosítja vagyis intézi a szoftvertermék módosításait annak érdekében, hogy aktuális és üzemeltethetı maradjon. Magában foglalja az átállást és a szoftvertermék visszavonását is. Tevékenységek: Folyamatkialakítás Probléma és módosításelemzés A módosítás kivitelezése A karbantartás vizsgálata, elfogadása Átállás A szoftver visszavonása A szabvány 6. fejezete, Az életciklus támogató folyamatai a következıket tartalmazza: Dokumentálás Konfigurációkezelés Minıségbiztosítás Igazolás (verifikáció) Érvényesítés (validáció) Együttes átvizsgálás (joint review) Felülvizsgálás (audit) Problémamegoldás A 6.1. Dokumentálási folyamat: Megadja azokat a tevékenységeket, amelyek rögzítik az életciklus-folyamatok által elıállított információkat. Tevékenységek Folyamatkialakítás Tervezés és fejlesztés Elıállítás Karbantartás 6.2. Konfigurációkezelési folyamat: Megadja a konfigurációkezelési tevékenységeket. Tevékenységek: Folyamatkialakítás Konfigurációazonosítás Konfigurációfelügyelet 74

75 Konfigurációs helyzetfelmérés Konfigurációértékelés Kiadáskezelés és leszállítás 6.3. Minıségbiztosítási folyamat: Megadja azokat a tevékenységeket, amelyek objektív biztosítékot szolgáltatnak arra, hogy a szoftvertermékek és szoftverfolyamatok megfeleljenek a megfogalmazott követelményeknek és kövessék a kialakított terveket. Az együttes átvizsgálást, a felülvizsgálást, az igazolást és az érvényesítést mint technikát lehet alkalmazni a minıségbiztosítás során. Tevékenységek: Folyamatkialakítás Termékbiztosítás Folyamatbiztosítás A minıségügyi rendszer biztosítása A minıségbiztosítási folyamatok hozzák összhangba a kapcsolódó igazolási (6.4), érvényesítési (6.5), együttes átvizsgálási (6.6) és felülvizsgálási (6.7) folyamatokat 6.4. Igazolási folyamat (verifikálás): Megadja azokat a tevékenységeket (a beszerzı, szállító vagy valamely független fél számára), amelyek a szoftvertermék igazoló ellenırzésére szolgálnak a szoftverprojekttıl függı, különbözı mélységben. Igazoló ellenırzés: vizsgálattal való megerısítés, továbbá objektív bizonyíték nyújtása arra, hogy az elıírt követelmények teljesülnek. Igazoló ellenırzés (verifikálás) = verification = we build it right. A tervezés és fejlesztés során a verifikálás arra a folyamatra vonatkozik, amely az adott tevékenység eredményét vizsgálja az illetı tevékenységre elıre megállapított követelményeknek való megfelelıség megállapítására. Az ellenırzéssel igazolt kifejezés az ennek megfelelı állapotot jelöli. Tevékenységek: Folyamatkialakítás Meg kell határozni, hogy a projekt indokolja-e az igazoláshoz szükséges ráfordítást, és hogy milyen mértékő szervezeti függetlenségre van szükség ehhez. A projekt követelményeit elemezni kell a kritikusság szempontjából Van-e esély arra, hogy felderítetlen hiba halált vagy személyi sérülést okozzon, a feladat meghiúsuljon, pénzügyi veszteség vagy kár keletkezzen, vagy valamely berendezés katasztrofális elvesztése vagy károsodása következzen be A használt szoftvertechnológia fejlettsége és az ezzel kapcsolatos kockázatok Pénzügyi alapok és erıforrások rendelkezésre állása Ha indokolt, ki kell alakítani az igazoló folyamatot (megcélzott elemek, tervezés, terv megvalósítása) Igazoló ellenırzés A szerzıdés igazoló ellenırzése A folyamat igazoló ellenırzése A követelmény igazoló ellenırzése A mőszaki terv igazoló ellenırzése Helyes-e, összeegyeztethetı a követelményekkel, visszavezethetı azokra, helyes eseménysorozat, bemenetek, kimenetek, interfészek, logikai vezérlés A kód igazoló ellenırzése Visszavezethetı-e a mőszaki tervre és követelményekre, tesztelhetı-e, helyes-e és összhangban van-e a követelményekkel és kódolási szabványokkal, teljes-e, helyes eseménysorozat, bemenetek, kimenetek, interfészek, logikai vezérlés, 75

76 származtatható-e a mőszaki tervbıl és követelményekbıl, alkalmasan precíz módszerekkel kimutatva helyesen valósítja-e meg a kód a biztonsági, védelmi és egyéb kritikus követelményeket Az integráció igazoló ellenırzése A dokumentáció igazoló ellenırzése 6.5. Érvényesítési folyamat: Megadja azokat a tevékenységeket (a beszerzı, szállító vagy valamely független fél számára), amelyek a projektben szereplı szoftvertermék érvényesítésére szolgálnak. Érvényesítés, érvényesítı ellenırzés (validálás): vizsgálattal való megerısítés, továbbá objektív bizonyíték nyújtása arra, hogy teljesülnek a valamilyen tervezett felhasználásra vonatkozó konkrét követelmények Érvényesítés = validation = we build the right thing A tervezés és fejlesztés során a validálás a a termék megvizsgálásának a folyamatára vonatkozik, a felhasználó igényeinek való megfelelés meghatározására A validálás rendszerint kész terméken történik, meghatározott mőködési feltételek között, de szükséges lehet korábbi szakaszokban is (validált/érvényesített állapot). Többszörös validálás is végezhetı, ha különbözı, tervezett felhasználások vannak. Tevékenységek Folyamatkialakítás Érvényesítı ellenırzés Elıkészíteni a kiválasztott tesztkövetelményeket, teszteseteket és tesztelıírásokat a teszteredmények elemzésére Biztosítani, hogy ezek a tesztkövetelmények, tesztesetek és tesztelıírások tükrözik az adott, tervezett használatra vonatkozó egyedi követelményeket Elvégezni az elıbbi feladatokban szereplı teszteket, beleértve a következıket: Terheléses, határértéki és meg nem engedett adatok bevitelére építı tesztelések A szoftvertermék azon képességének tesztelése, hogy mennyire tudja elkülöníteni és minimalizálni a hibák hatását, azaz meghibásodás esetén képes-e fokozatosan csökkenteni a teljesítményét, túlterhelés, határérték-elérés és meg nem engedett körülmények fellépése setén az üzemeltetı segítségét kérni Annak tesztelése, hogy tipikus felhasználók sikeresen tudják-e tervezett feladataikat elvégezni a szoftvertermék használatával Érvényesítéssel ellenırizni, hogy a szoftvertermék eleget tesz-e tervezett használatának Tesztelni a szoftverterméket szükség szerint a célkörnyezet kiválasztott területén 6.6. Együttes átvizsgálási folyamat: Megadja azokat a tevékenységeket, amelyek valamilyen tevékenység helyzetének és termékeinek értékelésére szolgálnak. Ezt a folyamatot tetszıleges két fél alkalmazhatja, ahol valamilyen együttes ülésen az egyik fél (átvizsgáló fél) átvizsgálja a másik felet (átvizsgált fél). Együttes átvizsgálás: egy projekt valamely tevékenysége állapotának és termékeinek értékelésére szolgáló folyamat. Mind projektirányítási, mind mőszaki szinten végezzük. Együttes átvizsgálás = joint review Tevékenységek: Folyamatkialakítás Projektirányítási átvizsgálás A projekt helyzetének értékelése a vonatkozó projekttervhez, ütemezéshez, szabványokhoz és útmutatókhoz viszonyítva 76

77 Mőszaki átvizsgálás A szoftvertermékek vagy szoftverszolgáltatások értékelése, bizonyíték szolgáltatása arra nézve, hogy elkészült, megfelel a szabványoknak és elıírásoknak, változtatásaikat rendben megvalósították, a vonatkozó ütemezés szerint készítik, készek a következı tevékenységre, fejlesztését, üzemeltetését és karbantartását a projekt tervei, ütemezései, szabványai és irányelvei szerint végzik 6.7. Felülvizsgálási folyamat: Megadja azokat a tevékenységeket, amelyek valamilyen tevékenység helyzetének és termékeinek értékelésére szolgálnak. Ezt a folyamatot tetszıleges két fél alkalmazhatja, ahol az egyik fél (felülvizsgáló fél) felülvizsgálja a másik fél (felülvizsgált fél) szoftvertermékeit és szolgáltatásait. Felülvizsgálat: szoftvertermékek és szoftverfolyamatok olyan független felmérése, amit erre feljogosított személy hajt végre valamilyen követelménynek való megfelelés meghatározása érdekében Felülvizsgálat = audit Tevékenységek: Folyamatkialakítás Felülvizsgálat A felülvizsgálatokat úgy kell végrehajtani, hogy biztosítva legyen: A szoftvertermék úgy, ahogy bekódolták tükrözi a tervdokumentációt Az átvételi vizsgálatra és a tesztelésre a dokumentációban elıírt követelmények megfelelıek a szoftvertermék átvételéhez A tesztadatok megfelelnek az elıírásnak A szoftvertermékeket sikeresen letesztelték és azok teljesítik a rájuk vonatkozó elıírásokat A tesztjelentések helyesek, és az összes különbözıséget a tényleges és elvárt eredmények között feloldották A felhasználói dokumentáció megfelel az elıírt szabványoknak A tevékenységeket a vonatkozó követelmények, tervek és szerzıdés szerint hajtották végre A költségek és az ütemezés követik a kialakított terveket 6.8. Problémamegoldási folyamat: Minden olyan probléma (beleértve az eltéréseket is) elemzésére és megoldására szolgáló folyamat, amelyet a fejlesztés, az üzemeltetés, a karbantartás vagy más folyamat végrehajtása során tárnak fel. Cél: idıben, felelıs és dokumentált módon lehessen biztosítani, hogy minden feltárt problémát elemezzenek és megoldjanak, és a tendenciákat is felismerjék. Tevékenységek Folyamatkialakítás Zárt folyamat (minden észlelt problémát bejelentsenek és beléptessenek a Problémamegoldási folyamatba) Koncepció a problémák osztályozására és rangsorolására Elemzés a beérkezett problémákról és tendenciákról Problémamegoldások és kapcsolódó rendelkezések kiértékelése Problémamegoldás Probléma (beleértve az eltéréseket is) esetén problémajelentést kell készíteni, és a kialakított zárt folyamatot követni Az ISO szabvány 7. fejezete Az életciklus szervezeti folyamataival foglalkozik. Ezek 77

78 annak a szervezetnek a felelısségi körébe tartoznak, amely használja ezt a folyamatot. Az irányítási folyamatok a következık: Irányítás Infrastruktúrabiztosítás Megújítás Képzés 7.1. Irányítási folyamat Bármely fél alkalmazhatja, aki irányítja saját folyamatait. Tevékenységek: Elindítás és behatárolás Tervezés Végrehajtás és ellenırzés Átvizsgálás és értékelés Lezárás 7.2. Infrastruktúrabiztosítási folyamat: Tetszıleges más folyamathoz szükséges infrastruktúra létrehozásának és fenntartásának a folyamata. Az infrastruktúra tartalmazhat hardvert, szoftvert, eszközöket, technikákat, szabványokat és fejlesztésre, üzemeltetésre vagy karbantartásra szolgáló létesítményeket. Tevékenységek: Folyamatkialakítás Az infrastruktúra létrehozása Az infrastruktúra fenntartása 7.3. Megújítási folyamat: Valamilyen szoftver-életciklus-folyamat létrehozásának, felmérésének, mérésének, ellenırzésének és javításának folyamata. Tevékenységek Folyamatlétrehozás Folyamatfelmérés Folyamatjavítás 7.4. Képzési folyamat: A képzett személyzet biztosításának és fenntartásának folyamata. Tevékenységek: Folyamatkialakítás A képzési anyag fejlesztése A képzési terv megvalósítása Az ISO szabványban kiemelt fontosságú az illesztési folyamat, mely e nemzetközi szabvány szoftverprojekthez történı illesztését adja meg. A rendelkezı jellegő A melléklet adja meg azokat az alaptevékenységeket, amelyek e nemzetközi szabvány illesztéséhez szükségesek. A B melléklet rövid útmutatást tartalmaz a szabvány követelményeinek illesztéséhez, felsorolja azokat a kulcstényezıket, amelyek alapján az illesztési döntéseket meg lehet hozni. A melléklet: Illesztési folyamat, Tevékenységek: Projektkörnyezet meghatározása Pl: életciklusmodell, életciklus aktuális tevékenysége, a rendszer és szoftverkövetelmények, szervezeti politikák, eljárások és stratégiák, a rendszer mérete, kritikussága és típusa, a szoftvertermék vagy szoftverszolgáltatás, a személyzet létszáma és az érintett felek Kiindulási információ kérése A folyamatok, tevékenysége és feladatok kiválasztása Illesztési döntések és indoklásuk dokumentálása A B melléklet: Útmutató az illesztéshez 78

79 B1: általános útmutatás: elsı körben illesztés üzleti területhez, második körben illesztés konkrét projekthez B2: A Fejlesztési folyamat illesztése Beágyazott vagy egy rendszer szerves részét alkotó szoftverterméknél a folyamat minden tevékenysége legyen figyelembe véve. Tisztázandó, hogy a fejlesztıtıl a rendszerszintő tevékenységek végrehajtását vagy támogatását igénylik Önálló szoftvereknél: a rendszerszintő tevékenységekre (5.3.2, , és ) lehet, hogy nincs szükség, de azért legyenek figyelembe véve B3: Az értékeléssel kapcsolatos tevékenységek illesztése 5 osztály, elsı 4 projekt szintő, 1 szervezeti szintő- úgy válasszák ki és illesszék ıket, hogy arányban legyenek a projekt vagy szervezet határaival, méretével, bonyolultságával és kritikusságával Folyamaton belüli értékelések ( )- napi szinten, a folyamatbeli feladatokkal megbízott személyzet végzi Igazolás (6.4) és érvényesítés (6.5): a beszerzı, szállító vagy független fél végzi, a termékek igazolását és érvényesítését. A projekttıl függı, változó mélységben Együttes átvizsgálások (6.3) és felülvizsgálások (6.7): átvizsgáló és átvizsgált közös fórumán, a termékek és tevékenységek helyzetének és megfelelıségének értékelése, elızetes terv szerint Minıségbiztosítás (6.3): független személyek végzik, Használhatja az elıbbi három eredményeit Megújítás (7.3) a szervezet végzi folyamatainak hatékony irányításáért és önjavításáért B4: illesztési és alkalmazási megfontolások Szervezeti politikák Beszerzési stratégia Támogatási koncepció Életciklusmodellek Érintett felek A rendszeréletciklus tevékenysége Rendszerszintő jellemzık 79

80 Egyéb szempontok Idı Pénz Követelmények Jog Védelem Biztonság Biztosítékok (ISO 9001 ) A szervezet képességei Minıségügyi kézikönyv Eljárások ISO/IEC szabvány Alkalmazás, Illesztés, Értékelés, Tesztelés Stb. Szerzıdés Minıségi terv Projekt terv Elindított projekt Modellek és módszerek Vízesés, inkrementális Spirál, vállalati módszerek környezet Felelısségi mátrix Beszerzı Szállító Fejlesztı Üzemeltetı Karbantartó 18. ábra: Példa a szabvány alkalmazására A CMM modell A CMM (Capability Maturity Model) egy, szoftverfejlesztı cégek számára kidolgozott, lépcsıs folyamatfejlesztési modell. Elveit, legtöbb folyamatát viszont bármely szervezet alkalmazni tudja (és alkalmazza is). A beszállítói problémára megoldást keresve, 1984 decemberében a DoD (Department of Defence) támogatásával létrejött a Software Engineering Institute (SEI 2 ) a Carnegie Mellon Egyetemen. Ez az intézet azóta világelsıséget és monopóliumot vívott ki magának a szoftverfolyamat-fejlesztési modellekkel kapcsolatos szolgáltatásokban. A SEI-ben 1986-tól projekt indult szoftverfolyamat-fejlesztési témában, melynek keretében 1989 és 1991 között, Watts Humphrey vezetésével, kidolgozták a CMM modellt. A CMM modell egy teljes szervezetet jellemzı érettségi szintjei a következık: 1. kaotikus vagy kezdeti szint (Initial) 2. ismételhetı szint (Repeatable) 3. meghatározott szint (Defined) 4. menedzselt szint (Managed) 5. optimalizáló szint (Optimizing). Az érettségi szintek jellemzıit röviden bemutatjuk a továbbiakban. 1. Kaotikus v. kezdeti szint: nincsenek folyamatok, mindenki tőzoltásszerően dolgozik, nagy a kockázat és szinte nem létezı az ellenırzés a projektekben, a projektek, ha elkészülnek, az egyének zsenialitása, hısiessége miatt készülnek el. 2 A SEI web-lapja: 80

81 2. Ismételhetı szint: az egyes emberek a saját munkájukat ismételni tudják. A projektmenedzsment megfelelı, projektirányítási rendszer mőködik a cégnél. A projekteket tervezik, követik és vezérlik, de az eljárások, szokások projektenként különbözhetnek. Az ezen a szinten mőködı folyamatok a következık: projekttervezés, projektkövetés- és vezérlés, követelménymenedzsment, minıségbiztosítás, beszállítók kezelése, konfigurációmenedzsment. 3. Meghatározott szint: a folyamatok cég szintjén szabályozottak, az egyes projektek saját folyamataikat a szabványos folyamatokból, testreszabási útmutatókat használva, szabják testre. A projektirányítási eljárásokon kívül megvannak a dokumentált mőszaki, támogató és irányítási eljárások is. Meghatározták és dokumentálták a cégnél alkalmazott életciklus modelleket. Becsülik, mérik, kézbentartják a készülı termék méretét, valamint a termék- és folyamat-minıség elfogadható értékeit. Ezen a szinten a 2-es érettségi szint folyamatain kívül - a következı folyamatok vannak jelen: szervezeti szintő folyamatszemlélet, szervezeti szintő folyamat-meghatározás, szoftvertermék-fejlesztés, integrált szoftvermenedzsment, páros (egyenrangú) szemlék, képzési program. 4. menedzselt szint: a folyamatokat mérik, a mérési eredményeket statisztikai módszerekkel elemzik. Ezen a szinten a 2-es és 3-as érettségi szint folyamatain kívül - a következı folyamatok vannak jelen: mennyiségi projektmenedzsment, szoftverminıség-menedzsment. 5. Optimalizáló szint: a mérések eredményeit folyamatos optimalizálásra használják fel. A technológiai változásokat tervezik és folyamatosan követik. Ezen a szinten a 2-es, 3-as és 4-es érettségi szint folyamatain kívül - a következı folyamatok vannak jelen: folyamat-változásmenedzsment, technológiai változásmenedzsment, hibamegelızés. A CMM modellt széles körben alkalmazták a világ minden részén. A SEI által közzétett adatokból megtudjuk, hogy 1987 és 2005 között a világban összesen 2794 felmérést végeztek, összesen 1367 szoftvercég projektjét mérték fel. A szervezetek érettségi szintjének átlaga emelkedett az évek során ben az összes korábbi felmérés alapján, a felmért szervezetek 5,7%-a volt 1-es érettségi szinten, 39,6%-uk 2-es érettségi szintő, 37,4%-uk 3-as érettségi szintő, 7,6%-uk 4-es érettségi szintő, 9,8%-uk pedig 5-ös érettségi szintő besorolást kapott. A CMM modellt sok kritika is érte az évek folyamán. Legerısebben azt kifogásolták a modell bírálói, hogy a mérések végzése csak a 4-es érettségi szinten jelenik meg követelményként, holott, szerintük, bármely folyamat csakis mérésekkel tartható kézben. A kritikára sokan és sokszor válaszolták, hogy méréseket már alacsonyabb szinten, folyamatosan végezni kell, ezt a CMM nem tiltja meg. Megjegyezzük, hogy a CMM modell 2005 decemberétıl hivatalosan már nem auditálható, és fokozatosan visszavonásra került, helyét a CMMI modell vette át. Mivel azonban a modell igen népszerő volt az 1990-es években, és alapul szolgált a CMMI modell kifejlesztésekor, fontosnak tartjuk bemutatni. Jelenleg (2008 július) a CMM modellt még több nagy cég alkalmazza, belsı folyamatfejlesztésre. Mindenestre, a CMM modellt felváltó CMMI modellben a mérési és elemzési folyamatot a lépcsıs megközelítés 2-es szintjén teszik kötelezıvé. A CMM modell folyamatok meghatározására, mőködtetésére és a folyamatos fejlıdésre vonatkozó szemlélete átvehetı a közigazgatásban is. 81

82 10.5. A SPICE modell /ISO szabvány A SPICE a Software Process Improvement and Capability determination rövidítése, és azt a nemzetközi projektet jelöli, amelynek keretében között kidolgozták a késıb ISO szabványcsaládban közzétett átfogó referencia- modellt a szoftverfejlesztési folyamatokra és a folyamatok képességi szintjére vonatkozóan, kis-, közepes- és nagyvállalatok nemzetközi tapasztalatait összegezve. (Bár helyesen SPICE projektet és ISO szabványt kellene emlegetnünk, a szakzsrgonban gyakran SPICE modell névvel illetjük azt a keretrendszert, amely a SPICE projekt keretében, az ISO szabványcsaládban került kidolgozásra. A szokásnak megfelelıen, a továbbiakban mi is alkalmazom a SPICE modell elnevezést. A szerzık.) A SPICE modell folytonos megközelítéső. A cég egyes szoftverfejlesztési folyamatait vizsgálja, melyek képessége 0 és 5 szint között mozoghat. A folyamat képessége annál magasabb, minél több jellemzı van a helyén a tervezés, dokumentálás, mérés, folyamatos fejlesztés attribútum-csoportokból. A SPICE modellt olyan cégeknek ajánlatos alkalmazni, amelyek bizonyos, 1-tıl különbözı érettségi szinten vannak a cég egészére vonatkozóan, és bizonyos folyamataikat szeretnék meghatározni, dokumentálni és továbbfejleszteni. Az ISO elsı változatát 1998-ban adták ki, majd, a kiadását követı idıszakban a SPICE projekt-vezetıség (mely öt nemzetközi Mőszaki Központ szövetségébıl jött létre) irányította a szabvány kipróbálását, tesztelését, és a visszajelzések alapján történı pontosítását. E tevékenység eredményeképpen a SPICE modellt (a kapcsolódó szabványban leírt keretrendszert) 20 ország szoftverfejlesztıi, szabványügyi szakértıi és kutatói tesztelték és véleményezték. Kezdetét vette a SPICE auditorok képzése is, a SPICE keretrendszer szerint végzett felmérések pedig növekvı népszerőségre tettek szert. A népszerőség oka valószínőleg abban keresendı, hogy a SPICE igen jól alkalmazható folyamat-fejlesztésre. Ezzel az adott idıszakban komoly versenytárssá vált a többi, piacon levı érettségi modell között. A korábban kifejlesztett CMM-re ugyanis rányomta bélyegét az a tény, hogy az Amerikai Honvédelmi Minisztérium beszállítóinak értékelésére hozta létre (bár kétségtelen, hogy a CMM elsı változatát követı frissítések igyekeztek eltávolodni ettıl a szemlélettıl és támogatni a folyamatfejlesztést). Az egyéb érettségi modellek a British Telecom, Bell Canada/BNR és Bellcore, termékei lévén, fıleg a telekommunikációban váltak elterjedtté. Fontos jellemzıje még a SPICE-nak, hogy nemzetközi szabványként kerül leírásra, emiatt a világon bárhol ismert, és az alkalmazó cég hovatartozásától függetlenül használható. Ezzel együtt elmondható, hogy a SPICE modellt inkább német nyelvterületen alkalmazzák, és elsısorban az autóiparban terjedı, Automotive Spice al-változata igen népszerő (erre vonatkozóan lásd a fejezetet.) Az ISO/IEC TR Software Process Assessment dokumentumok összességét általában SPICE99-ként emlegetik. Ennek kiadását követıen a szabványtervezet gyökeres változáson esett át. Egyrészt címében a folyamatjavítás mellıl elmaradt a szoftver szó, ezzel tetszıleges folyamatok felmérésére alkalmassá vált, másrészt részei is alapvetıen átalakultak. A dokumentumcsomag jelenleg (2008 júliusában) a következıket tartalmazza (csak angolul állnak rendelkezésre, lásd még [B40], [B39]): ISO/IEC :2004: Part 1 : Concepts and vocabulary ISO /IEC : 2003: Part 2 : Performing an assessment ISO /IEC : 2004: Part 3 : Guidance on performing an assessment ISO /IEC :2004: Part 4 : Guidance on use for process improvement and capability determination 82

83 ISO /IEC : 2006: Part 5 : An exemplar process assessment model for software life cycle processes ISO /IEC : 2007: Part 6 : An exemplar process assessment model for system life cycle processes ISO /IEC Part 7 : Assessment of organizational maturity megjelenése ban várható ISO /IEC Part 8:2007 : Exemplar IT Service Management Process Assessment Model (NWI Ballot October 2007) A felsorolt címekbıl is látható, hogy az ISO/IEC szabvány elsı öt része általános keretrendszert fogalmaz meg folyamatok értékelésére vonatkozóan. Eredetileg nem terveztek konkrét folyamat-modellt leírni, hanem azokat az elemeket hangsúlyozták, amelyek egy fejlesztı cég folyamatainak azonosításában, jellemzıik megértésében és a folyamatok képességi szintjének értékelésében használhatók. Sokáig a SPICE modell csak ajánlást tartalmazott arra nézve, hogy a szoftverfejlesztési folyamatokat az ISO szabványnak megfelelıen lehetséges azonosítani, de hangsúlyozta, hogy bármely területen alkalmazható egy, az adott területnek a sajátos folyamatait véve alapul. A modell ebben az állapotában is ismertté vált, és sokan alkalmazták sikerrel folyamatainak fejlesztésében. A megközelítést szimpatikussá tette, hogy nem határozott meg a cégek számára kötelezıen alkalmazandó folyamatokat, hanem a felhasználókra bízta a fejleszteni kívánt folyamatok kiválasztását. A SPICE modellel foglalkozó szakértık 2006-ban mégis kiadták a szabvány 5. részét, amely egy példa-értékő szoftverfejlesztési folyamatmodellt mutat be. Az ISO szabványnak ez a része szintén a korábban ajánlott, ISO szabvány folyamataira támaszkodik. Az ISO/IEC szabvány 6, 7, 8 részek kidolgozására vonatkozóan csak a szabványcsalád elsı öt részének kiadását követıen született meg a döntés. Az eddig megjelent, 6. és 8. részek a rendszerfejlesztésben és az információtechnológiai szolgáltatásokban alkalmazható folyamatokat ismertetik. A tervezett 7. rész kapcsolatot fog teremteni a folyamatok képességi szintjét vizsgáló folytonos megközelítés és a szervezetek érettségét vizsgáló lépcsıs megközelítés között. A SPICE legfıbb támogatói a világ SPICE-felhasználóit tömörítı SPICE User Group, amely évente SPICE-konferenciát is szervez, valamint az intacs (International Assessor Certification Scheme), amely a SPICE modell szerint auditálók képzését és akkreditálását tőzte ki célul. A SPICE-szal kapcsolatban a következı Internet-címen lehet a legtöbb hasznos információt megszerezni: A továbbiakban összefoglaljuk a legfontosabb tudnivalókat a SPICE szerkezetérıl. A SPICE modellnek két dimenziója van: a folyamat-dimenzió, és a képesség dimenzió. A folyamat-dimenzió a terméket vagy szolgáltatást fejlesztı cégeknél megjelenı folyamatok és jellemzıik meghatározásával foglalkozik. A folyamatok alapvetıen az ISO ben leírt folyamatok. A folyamatokat csoportokba (kategóriákba) sorolják aszerint, hogy felhasználóval kapcsolatosak-e, illetve fejlesztési, támogató, irányítási vagy szervezeti szintő folyamatok-e. Az Ügyfél-beszállítói (Customer, CUS) folyamatok azon folyamatok, melyek közvetlen hatással vannak az ügyfélre, support és szoftver szállítása az ügyfélnek, a szoftvertermék és/vagy szolgáltatás helyes mőködéshez járulnak hozzá. A Mőszaki, fejlesztési (Engineering, ENG) folyamatkategória olyan folyamatokból áll, melyek közvetlenül specifikálják, implementálják vagy karbantartják a szoftverterméket, illetve annak a rendszerhez való kapcsolatát és felhasználói dokumentációját. Abban az esetben, amikor a rendszer teljes egészében szoftverekbıl 83

84 épül fel, a Mőszaki folyamatok a szoftver felépítésével és karbantartásával foglalkoznak. A Támogató (Support, SUP) folyamatok azok a folyamatok, melyeket bármilyen más folyamat alkalmazhat (beleértve más support folyamatokat is) a szoftver életciklusának különbözı pontjain. A Menedzsment (Managerial, MAN) folyamatok azon folyamatok, melyek olyan általános gyakorlatokat tartalmaznak, amelyeket bárki felhasználhat, aki a szoftver életciklusában bármilyen típusú projektet vagy folyamatot menedzsel. A Szervezeti (Organisational, ORG) folyamatok segítenek megvalósítani a szervezet üzleti céljait és azon folyamat-, termék- valamint az erıforrás - eszközöket fejlesztik, melyek a projektek során szervezet üzleti céljainak elérésében segítenek. A képesség-dimenzió a kiválasztott folyamatok fejlettségét mutatja. A modell szerint, a folyamatokat a jól meghatározott input és output, a jól megfogalmazott cél, a folyamat tevékenységeinek pontos leírása, a tevékenységek elvégzéséhez szükséges felelısségek, hatáskörök és kompetenciák megléte, a folyamat követésére beiktatott ellenırzési pontok, a pontosan megfogalmazott teljesítmény-elvárások, a folyamat mértékek jellemzik. Minél több elem van a helyén egy adott folyamat esetében, annál magasabb az adott folyamat képességi szintje. A SPICE-ban azonosított, egyes folyamatokra vonatkozó képességi szintek a következık: 0. szint: nem végrehajtott folyamat. Ebben az esetben a folyamatot nem hajtják végre, következésképpen jellemzıi sincsenek. 1. szint: végrehajtott (folyamat): a folyamat létezik, végrehajtják a szervezetben, de azonosítható jellemzıi nincsenek. Nagy a valószínősége annak, hogy az adott folyamatot a különbözı projektekben a különbözı emberek esetenként különbözıképpen hajtják végre. 2. szint: menedzselt folyamat: a folyamatot végrehajtják, és menedzselésével kapcsolatosan léteznek ismérvek. A folyamatra vonatkozóan van teljesítmény menedzsment, ami azt feltételezi, hogy megtörténik az erıforrás igények meghatározása, a folyamat teljesítményének tervezése, megvalósul a tervezett tevékenységek implementálása és a tevékenységek elvégzésének menedzselése. Megfelelı a munka eredményének menedzselése is. Megtörténik az integritásra és minıségre vonatkozó követelmények meghatározása, a folyamatban szükséges tevékenységek meghatározása, megvalósul a munka eredményének konfigurációkezelése és a munka eredményének minıségmenedzsmentje. 3. szint: meghatározott folyamat: a folyamatot a szervezetben meghatározták (dokumentálták), elkészült a folyamat szervezeti szinten érvényes szabványos leírása, és a sajátos esetekben a folyamatot a szabványos folyamatból szabják testre, a szintén dokumentált testreszabási útmutatók alkalmazásával. A meghatározott folyamatot a szervezet egészében bevezették, és győjtik a visszajelzéseket a szabványos folyamatra vonatkozóan. Magasabb szinten valósul meg a folyamathoz rendelt erıforrások kezelése is. Megtörténik az emberi erıforrás kompetenciájának meghatározása, a folyamat infrastrukturális követelményeinek meghatározása, megfelelı képességő emberi erıforrások biztosítása és a megfelelı infrastruktúra biztosítása. 4. szint: jósolható folyamat: a rendelkezésre álló adatok, tapasztalatok alapján a folyamat végrehajtásának módja és teljesítménye jósolhatóvá válik. Megfelelı a folyamat mérése: megtörténik a folyamatok céljainak és a kapcsolódó mérıszámoknak a meghatározása, a méréshez szükséges megfelelı erıforrások és 84

85 infrastruktúra biztosítása, megvalósul a meghatározott mérési adatok győjtése s ezek alapján annak figyelése, hogy a folyamat céljai teljesültek-e. Magasabb szinten valósul meg a folyamat ellenırzése: elemzési és ellenırzési technikák kerülnek meghatározásra, megfelelı erıforrásokat és infrastruktúrát biztosítanak a mérésre, megfelelı a meglévı mérési eredmények elemzése, az eltérések azonosítása és a szükséges beavatkozás. 5. szint: optimalizáló folyamat: a folyamatot állandóan figyelik, és a tényleges teljesítmény alapján folyamatosan fejlesztik. A folyamat változása tervezett és kézbentartott, amennyiben a szabványos folyamatban szükséges változásokat azonosítják és jóváhagyják, a folyamat-változás bevezetéshez szükséges erıforrásokat rendelkezésre bocsátják, a jóváhagyott változásokat bevezetik, és vizsgálják a változtatás hatékonyságát. A szervezetben cél a folyamat folyamatos javítása, ami a javítási lehetıségek azonosítását, a bevezetési stratégia meghatározását, a testre szabott folyamat meghatározott területén végrehajtott módosítás bevezetését és a változtatás hatékonyságának vizsgálatát jelenti. A SPICE modellben tehát két dimenzió létezik: a folyamat-dimenzió, és az egyes folyamatokra vonatkozó képesség-dimenzió. A SPICE-nak megfelelı képesség-vizsgálat e két dimenzió elemeinek kereszt-szorzatából áll össze. Kategóri Életciklus folyamatok CUS ENG SUP MAN Folyamat Folyamat dimenzió ORG leképezé sek Szint Név Attribútumok 5 Optimalizáló folyamatok Folyamatváltoztató attribútum Folyamatos fejlesztési attribútum 4 Jósolható folyamat Folyamatmérési attribútum Folyamatellenırzı attribútum 3 Meghatározottt folyamat Folyamatmeghatározási attribútum Folyamaterıforrás attribútum 2 Menedzselt folyamat Teljesítménymenedzsement attribútum Munkatermék menedzsement attribútum 1 Végrehajtott folyamat Folyamatteljesítmény attribútum 0 Nem végrehajtott folyamat Képességi dimenzió 19. ábra: Az SPICE (ISO 15504) referencia modell dimenziói A kereszt-szorzat azt jelenti, hogy bármely folyamatra vizsgálhatunk képességi szintet. A modell alkalmazásához meg kell érteni egyrészt a fejlesztési folyamat, illetve a fejlesztı szervezetben meglévı folyamatok elemeit, ki kell választani a felmérni kívánt folyamatokat, majd meg kell vizsgálni az egyes folyamatok képességét. A SPICE-nak megfelelı képesség-felméréshez szükség van egy felmérési modellre, egy felmérési módszerre és szakképzett auditorokra. Az ISO /IEC szabvány 2. és 3. része leírja a felmérési modellt, valamint a felmérési módszerrel szemben támasztott követelményeket. Ezek alapján a felmérést végzık dolgozzák ki saját felmérési módszertanukat. Ezek a módszertanok összemérhetı eredményeket fognak szolgáltatni (hiszen mindegyikük megfelel a szabvány követelményeinek). A SPICE-felmérés tulajdonképpen azt jelenti, hogy kiválasztott folyamatok esetében vizsgálják azok képességi szintjét. Minden folyamatnak ki kell elégíteni a sajátosságaiból eredı követelményeket ezek az un. sajátos célok (specific goals). (pl. a konfigurációkezelésnek biztosítania kell, hogy a konfiguráció elemeit azonosítsák, minden projekt tag a megfelelı verziót használja, a változásokat megfelelıen követik stb.) A sajátos 85

86 célok teljesülése tulajdonképpen azt jelenti, hogy a folyamatot végrehajtják (tehát legalább 1- es képességi szintő). A továbbiakban azt vizsgálják, hogy a folyamat esetében teljesülnek-e, és milyen mértékben az általános célok: a folyamatnak bizonyos általános célokat ki kell elégítenie, és bizonyos munka - eredményeket (termékeket) kell létrehoznia. Az általános célok teljesülési foka mutatja a folyamat képességét (ami tulajdonképpen azt jelenti, hogy mennyire intézményesítették a folyamatot a szervezetben). A SPICE-felmérést képzett, regisztrált SPICE-auditorok végzik. Munkájukat kérdıívek segítik. A folyamatok képességére vonatkozó információkat megbeszéléseken, interjúkon nyerik a szervezet tagjaitól. Az elmondottak bizonyítására az auditorok esetenként dokumentumokat, egyéb munkatermékeket is ellenıriznek. A megbeszélésekrıl emlékeztetık születnek, majd elkészül a felmérés eredményét összefoglaló jelentés. A jelentésnek lényeges eleme a további fejlıdési irány ismertetése Sajátságos SPICE-modellek: az Automotive SPICE A SPICE tulajdonképpen konkrét folyamatoktól független képességi és folyamatfejlesztési sémája olyan sikeresnek bizonyult (elsısorban német nyelvterületen), hogy bizonyos ágazatok saját, ágazat-specifikus SPICE modell kidolgozásába kezdtek. Az ágazat-specifikusság azt jelenti, hogy az adott ágazatban sajátságos folyamatokat részesítik elınyben, miközben igyekeznek megtartani az általánosan érvényes SPICE folyamatokat is. Jelenleg (2008 július) négy kezdeményezésrıl tudunk, melyek közül 2007 végén kiadásra az autóiparban alkalmazott Automotive SPICE ( kiadásra is került. Munkacsoportot alakítottak még a banki környezetben alkalmazható Banking SPICE ( valamint a vállalati szintő integrált rendszert alkalmazó környezetet támogató SPICE ( létrehozására. Ezek munkacsoportok tevékenysége 2008 elsı félévében kezdıdött el. A SPICE honlapon szerepel még a MediSPICE munkacsoport is, ennek munkájáról azonban semmit sem sikerült kideríteni. A továbbiakban röviden bemutatjuk a Magyarországon is egyre ismertebb és népszerőbb Automotive SPICE modellt annak szemléltetése céljából, hogyan alkalmazható a SPICE egy igen sajátos folyamat-halmazra. Az ötletet fel lehet használni a közigazgatási folyamatok meghatározásában és folyamatos fejlesztésében is, azaz elképzelhetı egy Közigazgatási SPICE kidolgozása. Az Automotive SPICE modellt az autógyártók egyik érdekképviselete, az Automotive Special Interest Group (SIG) dolgozta ki az Automotive SPICE projekt keretében, a korábbi SPICE modellt és az ISO szabványt kidolgozó SPICE User Group-pal együttmőködve. Az Automotive SIG tagjai között van az AUDI AG, a BMW Group, a DaimlerChrysler AG, a Fiat Auto S.p.A., a Ford Werke GmbH, Jaguar, a Land Rover, a Porsche AG, a Volkswagen AG és a Volvo Car Corporation. Az Automotive Spice két részbıl áll: Automotive Spice Process Reference Model (PRM) és Automotive Spice Process Assessment Model (PAM). Csak angol nyelven hozzáférhetık. A Process Reference Model (PRM) modellt 2005 augusztusában adták ki elıször. Jelenleg a modell v4.3 verziója, i kiadása van érvényben. Ez a rész kompatibilis az ISO követelményeivel, és definiálja az Automotive SPICE által alkalmazott folyamatokat: 31, az ISO szabványban meghatározott folyamatot tartalmaz. A Process Assessment Model (PAM) modell elsı kiadása szintén 2005 augusztusi, jelenleg a modell én kiadott, v2.3 verziója van érvényben. Ez a rész az ISO/IEC

87 nek mindenben megfelelve határozza meg az autóipari beszállítók körében alkalmazható folyamat-értékelési modellt. A SPICE és Automotive SPICE közötti különbség csak az értékelendı folyamatok halmazában van. A folyamatokat a következı csoportokba sorolja: elsıdleges életciklus folyamatok csoportja: beszerzési folyamatok (ACQ, 7 folyamat), értékesítési folyamatok (SUP, 2 folyamat), fejlesztési folyamatok (ENG, 10 folyamat) szervezeti folyamatok: menedzsment folyamatok (MAN, 3 folyamat), folyamatfejlesztési folyamatok (PIM, 1 folyamat), újrafelhasználással kapcsolatos folyamatok (REU, 1 folyamat), támogató folyamatok csoportja (egyetlen csoport, SUP, 7 folyamat). A folyamatok modellbeli leírása tartalmazza a folyamatok egyes funkcionális céljait. Mindegyik folyamathoz pontosan meghatározott eredmények tartoznak, melyek megléte igazolja a folyamat sikeres végrehajtását. Az Automotive SPICE képesség-dimenziója megegyezik a SPICE modell képesség dimenziójával, azzal a különbséggel, hogy a folyamatok képességi szintjét jellemzı általános gyakorlatokon kívül általános erıforrások is társulnak az adott képességi szintekhez. A SPICE modell filozófiájának megfelelıen, az Automotive SPICE egy, az ISO szabvány 2. és 3. részének megfelelı modell és módszertan alapján auditálható. A német autógyártók egy csoportja (Audi, BMW, DaimlerChrysler és VW) létrehozta a Hersteller Initiative Software (HIS) nevő szervezetet, amely az Automotive SPICE-ban leírt folyamatok közül kiválasztotta azt az eredetileg 11, mostanra 15 folyamatot, melyet a szervezet minimálisan felmérendı folyamat-halmazként követel meg beszállítóitól, ez az úgynevezett HIS-scope, melyet a 10. ábra mutat be részletesen. Az ábrából is látható, hogy a jelenlegi HIS-scope 5 olyan, beszerzéshez kapcsolódó folyamatot is tartalmaz, amelyek nem részei a korábbi ISO szabványnak. Az autóipari beszállítások sajátosságából fakadóan, az Automotive SPICE kiemelt hangsúlyt fektet a hardvert és szoftvert tartalmazó rendszerek fejlesztésére, a beszerzési folyamatok karbantartására, valamint a követelmények kétirányú követhetıségének biztosítására a rendszerek fejlesztésében. Jelenleg az Automotive SPICE-nak megfelelı felméréseket az intacs (Scheme for Education and Certification of Assessors, nevő, 2006 márciusában alakult szervezet által akkreditált auditorok végzik. Az Automotive SPICE felméréseket a VDA- QMC ( ) fogja össze, ez a szervezet akkreditálja az Automotive SPICE-nak megfelelı felméréseket végzı szervezeteket is. 87

88 20. ábra : Az Automotive SPICE folyamatai, és a HIS által megkövetelt folyamatok. Forrás: HIS Working Group Assessment, Version V.29, A CMMI modell A CMMI modellt (Capability Maturity Model Integration) a Carnegie Mellon Egyetem Software Engineering Institute-ja fejlesztette (lásd [B24] ), az Amerikai Védelmi Minisztérium (US. Department of Defense) támogatásával. A modell elsı változatát 2000-ben tették közzé. A modell kidolgozásának célja a korábban a szoftverfejlesztésben, rendszerfejlesztésben és termékfejlesztésben leggyakrabban alkalmazott modellek, megközelítések összevonása volt egyetlen modellé, amelyet bármely, szoftverfejlesztéssel (is) foglalkozó szervezet alkalmazhat, a teljes szervezet érettségének és/vagy egyes folyamatai képességének növelésére. A CMMI modell a következı szabványokat/modelleket/megközelítéseket integrálja: Capability Maturity Model for Software (SW-CMM) v2.0 draft C Electronic Industries Alliance Interim Standard (EIA/IS) 731, Systems Engineering Capability Model (SECM) Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98 A modell az ISO/IEC Technical Report for Software Process Assessment-ben leírt modellel, vagyis a SPICE modellel is kompatibilis. A fentiekbıl következik, hogy a CMMI modell a következı területeken (diszciplínákban) alkalmazható: szoftverfejlesztés (SW) rendszerszervezés- és fejlesztés (SE) integrált termék- és folyamatfejlesztés (IPPD). A szoftverfejlesztés a CMMI modell kötelezıen választandó diszciplínája. A szervezet tevékenységének típusa szerint, ez a diszciplína kiegészíthetı a rendszerszervezésre- és fejlesztésre vonatkozóval, és/vagy az integrált termék és folyamatfejlesztésre vonatkozóval. 88