MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Diplomová práce
Procesní analýza IT firmy
Brno 2013
Bc. Jakub Ježek
Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Bc. Jakub Ježek V Brně, dne 27. 5. 2013
Vedoucí práce: RNDr. JUDr. Vladimír Šmíd, CSc.
ii
Poděkování Moje poděkování patří mému vedoucímu diplomové práce panu RNDr. JUDr. Vladimíru Šmídovi, CSc. za vysoce odborné vedení a velkou trpělivost v celém průběhu tvorby této diplomové práce. Dále bych rád poděkoval mojí rodině a mojí přítelkyni za jejich podporu a za pomoc, které se mi po celou dobu dostávalo. Nakonec bych rád vyjádřil své díky mým přátelům za jejich rady a nekončící ochotu konzultovat a diskutovat nad tématem a vzniklými problémy.
iii
Shrnutí Práce seznamuje čtenáře s tématikou procesního řízení firem, se způsoby modelování procesů a se standardem pro vývoj služeb CMMI-DEV. Stěžejní částí práce je procesní analýza reálné české IT firmy. Popis hlavních procesů je doplněn o modely procesů v jazyce BPMN 2.0. Dále následuje hodnocení vyspělosti procesního modelu analyzované firmy dle standardu CMMI−DEV. V závěru práce jsou nastíněny možné optimalizace procesů pro dosažení vyššího stupně vyspělosti procesního modelu a tím i lepší a efektivnější fungování firmy.
Summary The thesis describes business process management, process modeling and the service development model CMMI-DEV.
A process analysis of an actual
Czech IT company is shown with the description of key processes, which includes descriptions of process models in the BPMN 2.0 language. The CMMI-DEV model is employed to evaluate maturity of the process model of the analyzed company. Based on the analysis, recommendations are provided aimed at process optimization, so that higher maturity level of the process model is reached and thus better and more effective management of the company is achieved.
iv
Klíčová slova proces, procesní analýza, procesní řízení, optimalizace procesů, CMMI, hodnocení procesů
v
Obsah ÚVOD ............................................................................................................................................................ 3 1
ŘÍZENÍ IT FIREM................................................................................................................................ 5
1.1
1.2 1.3
IT FIRMA ............................................................................................................................................. 6 1.1.1 Rozdělení firem.......................................................................................................................... 6 1.1.2 Outsourcing .............................................................................................................................. 7 FUNKČNÍ ŘÍZENÍ ................................................................................................................................. 8 PROCESNÍ ŘÍZENÍ ................................................................................................................................ 9 1.3.1 Výhody procesního řízení ......................................................................................................... 10 1.3.2 Rozdělení procesu .................................................................................................................... 12 1.3.3 Procesní mapa.......................................................................................................................... 13
2
BPMN.................................................................................................................................................. 15
2.1
SYNTAXE .......................................................................................................................................... 15 2.1.1 Tokové objekty ......................................................................................................................... 16 2.1.1.1 2.1.1.2 2.1.1.3
Události....................................................................................................................................... 16 Aktivity ....................................................................................................................................... 16 Brány ........................................................................................................................................... 17
2.2
2.1.2 Spojovací objekty...................................................................................................................... 17 2.1.3 Plavecké dráhy ......................................................................................................................... 18 2.1.4 Artefakty ................................................................................................................................. 18 BIZAGI BPMN PROCESS MODELER................................................................................................... 19
3
CMMI.................................................................................................................................................. 20
3.1 3.2
HISTORIE .......................................................................................................................................... 20 POPIS ................................................................................................................................................ 21 3.2.1 Procesní oblasti........................................................................................................................ 21 3.2.2 Úrovně vyspělosti .................................................................................................................... 24 3.2.3 Cíle procesních oblastí.............................................................................................................. 26 3.2.3.1 3.2.3.2
3.3
Specifické cíle a praktiky............................................................................................................ 26 Generické cíle.............................................................................................................................. 27
CMMI VS. ISO ................................................................................................................................. 27
4
PROCESNÍ ANALÝZA ..................................................................................................................... 29
4.1
CHARAKTERISTIKA SPOLEČNOSTI ..................................................................................................... 29 4.1.1 Kontext.................................................................................................................................... 29 4.1.2 Strategie a vize ........................................................................................................................ 29 4.1.3 Cíle.......................................................................................................................................... 30 4.1.4 Organizační struktura ............................................................................................................. 31 4.1.4.1
4.1.5
Role a odpovědnosti................................................................................................................... 31
Procesy.................................................................................................................................... 37
4.1.5.1 Hlavní proces.............................................................................................................................. 39 4.1.5.1.1 Popis....................................................................................................................................... 39 4.1.5.1.2 Model ..................................................................................................................................... 39 4.1.5.2 Proces Získání nové zakázky..................................................................................................... 39 4.1.5.2.1 Popis....................................................................................................................................... 39
1
4.1.5.2.2 Model ..................................................................................................................................... 41 4.1.5.3 Proces Analýza nové zakázky.................................................................................................... 41 4.1.5.3.1 Popis....................................................................................................................................... 41 4.1.5.3.2 Model ..................................................................................................................................... 43 4.1.5.4 Proces Implementace nového systému ..................................................................................... 43 4.1.5.4.1 Popis....................................................................................................................................... 43 4.1.5.4.2 Model ..................................................................................................................................... 45 4.1.5.5 Proces Nasazení nového systému.............................................................................................. 45 4.1.5.6 Proces Podpora........................................................................................................................... 46 4.1.5.7 Proces Rozšíření existujícího systému....................................................................................... 47 4.1.5.8 Proces Propagace (marketing) ................................................................................................... 48 4.1.5.9 Proces Vzdělávání zaměstnanců ............................................................................................... 48 4.1.5.10 Proces Nábor nového zaměstnance........................................................................................... 49 4.1.5.10.1 Popis....................................................................................................................................... 49 4.1.5.10.2 Model ..................................................................................................................................... 50 4.1.5.11 Proces Správa hardware a software........................................................................................... 50 4.1.5.12 Proces Správa financí ................................................................................................................. 51 4.1.5.13 Proces Správa dokumentů ......................................................................................................... 51
5
HODNOCENÍ PROCESNÍHO MODELU ...................................................................................... 53
5.1 5.2
5.3
METODA HODNOCENÍ ...................................................................................................................... 53 HODNOCENÍ VYSPĚLOSTI MODELU DLE 2. STUPNĚ ............................................................................ 54 5.2.1 Správa konfigurací................................................................................................................... 55 5.2.2 Měření a analýza ..................................................................................................................... 56 5.2.3 Dohoda o vedení dodavatele...................................................................................................... 57 5.2.4 Plánování projektu................................................................................................................... 58 5.2.5 Sledování a řízení projektů....................................................................................................... 59 5.2.6 Správa požadavků .................................................................................................................... 60 5.2.7 Zajištění kvality procesu a produktu......................................................................................... 61 ZÁVĚR HODNOCENÍ.......................................................................................................................... 61
6
OPTIMALIZACE............................................................................................................................... 62
6.1 6.2 7
DOSAŽENÍ 2. STUPNĚ VYSPĚLOSTI ..................................................................................................... 62 DOSAŽENÍ 3. STUPNĚ VYSPĚLOSTI ..................................................................................................... 63 ZÁVĚR................................................................................................................................................ 64
LITERATURA ............................................................................................................................................. 65 PŘÍLOHA A................................................................................................................................................. 67 PŘÍLOHA B ................................................................................................................................................. 68
2
Úvod Procesní řízení patří mezi v posledních dekádách často používaný přístup k řízení společností. Mnohé firmy se rozhodly a přešly na tento způsob řízení. Přechod z funkčního řízení na procesní je sice obtížný, ale ve výsledku přináší své ovoce v podobě široké škály možností optimalizace, striktně definovaných odpovědností za proces a zprůhlednění fungování firem. Hlavními cíli této práce bylo seznámení čtenáře s problematikou procesního řízení a následná procesní analýza reálné IT firmy. Dalším cílem práce bylo představení modelu kvality organizace CMMI1 a posouzení procesního modelu analyzované firmy pomocí metodiky tohoto modelu. První kapitola seznamuje čtenáře s řízením firem a představuje dva protichůdné přístupy k němu. Diskutuje rozdíly mezi funkčním řízením a procesním řízením. Podrobněji se věnuje právě procesnímu řízení. Dále zmiňuje fenomén posledních let – outsourcing. Ve druhé kapitole je popsán jazyk BPMN 2 2.0, který poskytuje nástroje pro grafické znázornění a validaci procesů. Na závěr kapitoly je zmíněno, jaký nástroj jsem pro modelování procesů ve čtvrté kapitole použil. Třetí kapitola představuje model kvality organizace CMMI, popisuje jeho principy a metodiky. Také srovnává tento model se standardem ISO/IEC 15504. Hlavní kapitolou práce je čtvrtá kapitola, která obsahuje procesní analýzu reálné IT firmy. Analýzu jsem prováděl ve firmě, ve které pracuji. Analýza je doplněna i o grafické znázornění hlavních procesů za pomoci výše zmiňovaného jazyka BPMN. Následuje pátá kapitola popisující výsledky hodnocení vyspělosti 1 Capability Maturity Model Integration 2 Business Process Model and Notation
3
procesního modelu analyzované firmy dle CMMI. V šesté kapitole jsou stručně nastíněny možnosti optimalizace procesního modelu. Práce je zakončena závěrem, který celou práci hodnotí.
4
1 Řízení IT firem V dnešní době se ve firmách práce, kterou její zaměstnanci odvádí, nejčastěji dělí na práci na konkrétních projektech. Respektive činnosti zaměstnanců jsou vždy prováděny v rámci konkrétního projektu za účelem splnění cílů tohoto projektu. Plánování zdrojů probíhá vždy v kontextu několika projektů či ve vztahu ke konkrétnímu projektu. Zdroje mohou být přirazeny jednomu danému projektu, nebo jsou sdíleny vícerými projekty.
Projekt Projekt je plánovaná, řízená, časově ohraničená skupina činností, která má dané vstupy a výstupy a spotřebovává určité zdroje (lidské, technologické, finanční). [1] Definice projektu: „Projekt je dočasné úsilí s cílem vytvořit unikátní produkt nebo službu.“ [2] PMBOK Guide1
„Projekt je jedinečný proces sestávající z řady koordinovaných a řízených činností s daty zahájení a ukončení, prováděný pro dosažení cíle, který vyhovuje specifickým požadavkům, včetně omezení daných časem, náklady a zdroji.“ [3] Norma ISO 10006:2003
Z obou definic vyplývá, že nemá-li projekt přesně stanoveny časové hlediska (počátek, konec) a jasné výstupy (produkty, služby), nejedná se o projekt. Nedefinování nebo pouze vágní definice těchto aspektů bývá častou chybou projektů. [1]
1
A Guide to the Project Management Body of Knowledge
5
1.1 IT firma 1.1.1 Rozdělení firem Nejčastějšími atributy, na jejichž základě jsou firmy děleny, jsou velikost (počet zaměstnanců společnosti) a její roční obrat. Komise evropských společenství ve svých dokumentech stanovujících podmínky čerpání dotací z EU definuje velikost firem právě dle počtu zaměstnanců a dle ročního obratu. V Nařízení Komise (ES) č. 800/2008 [4] z 6. srpna 2008 znějí definice následovně.
Mikro podniky Mikro podniky jsou vymezeny jako podniky, které zaměstnávají méně než 10 osob a jejichž roční obrat nebo bilanční suma roční rozvahy nepřesahuje 2 miliony EUR.
Malé podniky Malým podnikem je podnik, který zaměstnává méně než 50 osob a jeho roční obrat nebo bilanční suma roční rozvahy nepřesahuje 10 milionů EUR.
Střední podniky Jedná se o podniky, které zaměstnávají méně než 250 osob a jejichž roční obrat nepřesahuje 50 milionů EUR nebo jejichž bilanční suma roční rozvahy nepřesahuje 43 milionů EUR.
Velké podniky Pokud nějaký podnik není dle výše uvedených parametrů ani mikro podnikem, ani malým a ani středním podnikem, patří mezi velké podniky.
6
1.1.2 Outsourcing Společnost, v níž jsem prováděl procesní analýzu, je subdodavatelem velké nadnárodní společnosti. Tomuto modelu, kdy si firma pro uspokojení potřeb svého zákazníka najímá třetí firmu, se říká outsourcing. Outsourcing znamená, že firma vyčlení různé podpůrné a vedlejší činnosti
a svěří
je
smluvně
jiné
společnosti
čili
subkontraktorovi,
specializovanému na příslušnou činnost. Je to tedy druh dělby práce, činnost však není zajišťována vlastními zaměstnanci firmy, nýbrž na základě smlouvy. Typicky se jedná o činnosti jako je úklid, údržba, doprava nebo správa počítačů (IT). Outsourcing se považuje za obchodní rozhodnutí, které má vést ke snížení nákladů a (nebo) k soustředění na hlavní činnosti firmy, a to v zájmu její konkurenceschopnosti. Motivací pro nasazení outsourcingu je v první řadě fakt, že firmy, specializující se na daný obor, mají zpravidla mnohem proškolenější a v dané problematice zkušenější pracovníky. Odpovědnost za problematiku nese jiný subjekt a výchozí firma se může plně věnovat svému oboru. Náklady na zajištění specializované činnosti jsou při využití outsourcingu zpravidla nižší. Zajišťování služeb pomocí outsourcingu je celosvětově zvyšujícím se trendem. [5] V oblasti IT využívají outsourcing společnosti, které poznaly, že vlastní vývoj a údržba jejich informačního systému je pro ně z ekonomického hlediska nevýhodná.
Využívají
služeb
počítačových
firem
—
poskytovatelů
outsourcingu, kterým předají odpovědnost za návrh, budování a správu jejich informačního systému. Použití outsourcingu není omezeno pouze pro oblast informačních technologií, ale běžně se používá v oblastech, jako jsou údržba komunikací, stravování, personální záležitosti, vztahy s veřejností (Public Relations), marketing, firemní tisk a řadě dalších. [6]
7
1.2 Funkční řízení Do dnešní doby (po téměř 200 let) byl hojným manažerským způsobem využívaným k řízení organizace funkční přístup. Tento přístup vychází z myšlenek Adama Smithe, že výrobní procesy mají být rozloženy na nejjednodušší úkony. Funkční jednotky tedy slouží k rozdělení složitějších, sofistikovaných činností a k jejich dekompozici na jednoduché kroky, které může vykonávat i nekvalifikovaný dělník (viz A. Smith: Bohatství národa, napsaná v roce 1776). Tento přístup má však několik zásadních nevýhod. [1] Procesu se účastní a pracuje na něm několik týmů, tyto týmy vykonávají pořád stejné činnosti a dokáží se v nich zlepšovat. Tato výhoda umožní zdokonalit pouze jednu část řetězce, který na projektu pracuje, ale cílem není zlepšovat jednotlivé kroky, ale celý výsledný postup. Důvodem je fakt, že pokud začneme optimalizovat jednu část systému bez ohledu na ostatní, můžeme sice docílit vylepšení efektivity této části systému, ale celkově může systém na efektivitě ztratit. Je to dáno tím, že vylepšení jedné části může znamenat zhoršení v jiné části. Například změna požadavků na vstupní informace do části systému může negativně ovlivnit ostatní části systému. [1] Další nevýhodou je častá komunikační bariéra mezi jednotlivými týmy. Týmy mají jiné vedoucí pracovníky, jiné znalosti nebo zkušenosti a proto předávání informací často selhává a informace zůstávají izolované v rámci jednoho týmů. Procesy musí produkovat nějaké vstupy a výstupy. Výstupem může být produkt, služba nebo informace. Ve funkčně řízených organizacích se často vyskytují procesy, které neprodukují žádné produkty, ale jen uspokojují vnitřní požadavky společnosti. Poslední nevýhodou funkčního přístupu je nedefinovaná či nejasná zodpovědnost za daný proces. V tomto přístupu zodpovědnost přechází z jednoho manažéra funkčního týmu na další manažery. V případě problému je pak velice složité domáhat se zodpovědnosti
8
za chybu. [1] Procesní řízení organizace výše zmíněné nevýhody a problémy odstraňuje.
1.3 Procesní řízení Abychom mohli mluvit o procesním řízení, je nejprve nutné definovat samotný pojem proces. Pro proces existuje mnoho slovních definice, které ale vesměs pohlížejí na proces stejně, jenom jinými sovy. Definice procesu: „Proces je po částech uspořádaná množina aktivit, které přinášejí přidanou hodnotu. Proces musí mít svého vlastníka. Rovněž má vstupy a musí mít výstupy.“ [7] H. James Harrington
„Proces je soubor činností, který vyžaduje jeden nebo více druhů vstupů a tvoří výstup, který má hodnotu pro zákazníka.“ [8] M. Hammer
„Proces je sada jedné nebo více propojených procedur nebo činností, jež společně uskutečňují cíle nebo naplňují politiku firmy. Obvykle se tak děje v kontextu organizační struktury definující funkční úlohy a vztahy.“ [9] David Hollingsworth
Výše uvedené definice říkají v podstatě to stejné a to, že proces představuje posloupnost aktivit, která je vykonávána, aby bylo dosaženo cíle. [1] Za každý proces musí být jasně stanovená osoba, která za něj zodpovídá. Tento člověk nemusí nutně být vykonavatelem aktivit v rámci procesu. Nejenom odpovědná osoba je jasně dána, ale i vykonavatele aktivit procesu by
9
měli být předem jasně známy. Každý proces musí mít jasně stanovené vstupy a výstupy. V rámci procesu jsou také spotřebovávány určité zdroje, které by měly být také identifikovány a dobře známy. Podnikové procesy by zároveň měly korespondovat s podnikovou strategií. Z té vychází podnikové cíle, které by měly být procesem naplňovány.
1.3.1 Výhody procesního řízení Oproti funkčnímu řízení procesní řízení definuje striktně zodpovědnost za proces. Tato zodpovědnost je dána na všech úrovních. Procesní mapa umožňuje definovat hierarchii procesů a zodpovědnost je v procesním řízení definována na všech úrovních. Jelikož proces definuje aktivity, které nejsou předávány dále pryč z procesního týmu, je zodpovědnost striktně dodržována a zpětně vysledovatelná. Procesní řízení poskytuje vysokou možnost optimalizace. Je to dáno množstvím informací, které popisy procesů poskytují. Optimalizace může být manuální, či automatická s podporou softwaru. Největší hodnotou společnosti je v dnešní době know-how. Know-how je informace, která umožňuje společnosti pružně reagovat a fungovat efektivně. Procesní řízení umožňuje know-how neukládat v hlavách zaměstnanců (kteří mohou firmu opustit), ale v procesech, respektive v jejich popisech. Je tedy jednoduché tyto informace sdílet a měnit. Procesní řízení umožňuje zdokonalit chování společnosti ve vztahu k dynamickým změnám. Jakmile má společnost namodelovány procesy a řídí se jimi, je pro ni jednodušší reagovat na změny. Tedy udělat úpravu v procesech a implementovat tyto změny do denního běhu firmy. Pokud jsou procesy podpořeny informačním systémem, tak je nutné provést změnu tohoto systému a implementace změny je provedena. Znamená to, že organizace je schopna na menší změny v procesech reagovat okamžitě a na větší s kratší
10
časovou prodlevou než dříve. Procesní řízení umožňuje zprůhlednit fungování a chování společnosti a to navenek i zevnitř. V dnešní době společnosti velice často spolupracují s jinými. Společnost má své dodavatele, zákazníky a partnery. Aby tyto vztahy byly efektivní, je třeba pracovat na chápání potřeb druhých stran. Namodelované procesy ve vztahu k ostatním organizacím umožňují lépe definovat tyto vztahy. Každá společnost definuje své pracovní postupy a chování. Procesy jsou jednou z možností. Výhodou procesů je fakt, že tento popis je unifikovaný a lehce čitelný. Běžný způsob popisu chování společnosti je neunifikovaný a pro každou část společnosti se liší. [1] Přehledné srovnání funkčního a procesní přístupu velmi dobře znázorňuje níže uvedená tabulka.
Tabulka 1-1 Srovnání funkčního a procesního přístupu k řízení — základní rozdíly1 Funkční přístup Lokální orientace pracovníků. Problém transformace strategických cílů do ukazatelů.
Orientace na externího zákazníka. Pracovnici neznají smysl a propojení na interní zákazníky a dodavatele – minimální součinnost s jinými činnostmi.
Procesní přístup Globální orientace prostřednictvím procesů. Propojeni strategických cílů a ukazatelů procesů. U procesního přístupu je maximálně vystihující charakteristika: Myslete globálně, jednejte lokálně. Existence interních a externích zákazníků. Pracovnici vědí, jaké vstupy využívají pro prováděné činnosti a od koho je přebírají a jaké výstupy a komu poskytuji k realizaci navazujících činností – součinnost s jinými činnostmi.
1
Grasseová, Monika a kolektiv. Procesní řízení v soukromém i veřejném sektoru. Praha : BIZBOOKS, 2007. str. 272. ISBN 9788025119877.
11
Problematické definování zodpovědnosti za výsledek procesu a tvorby hodnoty pro zákazníka. Komunikace přes „vrstvy“ organizační struktury. Problematické přiřazení nákladů k činnostem. Rozhodnutí jsou ovlivňovaná potřebami činnosti (funkcí). Měřeni činnosti je izolováno od kontextu ostatních činnosti. Informace nejsou mezi činnostmi pravidelně sdíleny. Pracovnici jsou odměňovaní podle jejich přispěni k dané činnosti. Účast zaměstnanců na řešení problémů je nulová nebo je omezena pouze na jimi prováděnou činnost.
Zodpovědnost a tvorba hodnoty pro zákazníka je určovaná podle procesů. Komunikace v rámci průběhu procesu. Přímé přiřazení nákladů k činnostem. Rozhodnuti jsou ovlivňovaná potřebami procesů a zákazníků. Měření činnosti zohledňuje její požadovaný přinos a výkon v rámci procesu jako celku. Informace jsou předmětem společného zájmu a jsou běžně sdíleny. Pracovnici jsou odměňováni podle jejich přispěni k výkonnosti procesu, respektive organizace jako celku. Podstatné problémy jsou pravidelně řešeny týmy složenými napřič činnostmi (v rámci procesu) ze všech úrovní organizace.
1.3.2 Rozdělení procesu Z všeobecného pohledu se dělí podnikové procesy na tři skupiny. Tyto skupiny se nazývají hlavní, řídící a podpůrné procesy. Hlavní neboli klíčové procesy jsou ty procesy, které přímo naplňují cíle podniku. Vytváří přidanou hodnotu, kterou platí externí zákazník. Úkolem řídících procesů je vytvořit maximálně účinný a jednoduchý jednotný systém řízeni. Podpůrné procesy jsou zaměřeny na poskytování produktů a služeb zákazníkům nebo klíčovým procesům, které však v případě potřeby mohou být s výhodou zajišťovány externě subdodavatelsky (outsourcovány). [10]
12
Tabulka 1-2 Typy, způsob řízení a všeobecná charakteristika podnikových procesů [10] Typ
Způsob,
procesu
jakým má být řízen
Charakteristika procesu Přidává
Probíhá
Má externí
Generuje
hodnotu?
napříč
zákazníky?
tržby
podnikem?
(zisk)?
hlavní
Výkonově
ANO
ANO
ANO
ANO
řídicí
Nákladově
NE
ANO
NE
NE
podpůrný
Výkonově,
ANO
NE
NE
NE
možnost outsourcingu
1.3.3 Procesní mapa Velice užitečným a praktickým nástrojem procesního řízení je procesní mapa. Znázorňuje všechny procesy v podniku v jednom co nejvíce přehledném diagramu. S rostoucím počtem procesů v podniku se snižuje přehlednost této mapy. Tento fakt lze řešit sdružováním procesů do skupin, které spolu nějakým způsobem souvisí nebo po sobě následují. Takto zjednodušená mapa opět nabývá přehlednosti a je mnohem lépe použitelná v praxi. Tímto zjednodušením pak vzniká hierarchie procesů. Příklad můžete vidět na obrázku níže.
13
Obrázek 1-1 Hiearchie procesů [1]
14
2 BPMN Jazyk BPMN neboli Business Process Model And Notation je v současnosti nejrozšířenějším jazykem pro modelování firemních procesů, který používají jak business analytici, tak i vlastníci procesů. Základ jazyka BPMN tvoří popis posloupnosti činností včetně popisu událostí, které proces provázejí a komunikace mezi samostatnými subjekty. Jazyk umožňuje popsat průběh i velmi komplexních činností a to díky svému velkému vyjadřovacímu potenciálu. Záměrem tvůrců jazyka BPMN bylo navrhnout vizuální modelovací nástroj pro popis firemních procesů. Pro svou vyjadřovací sílu a přehlednost si BPMN brzy oblíbili nejenom analytici, ale i vývojáři a rozvinuli jeho možnosti tak, že v současnosti podporuje plnou automatizaci procesů (workflow management). BPMN lze v praxi využít pro komplexní procesní model organizace stejně tak jako pro detailní popis konkrétních firemních procesů pro potřeby business analýzy nebo jako programovací nástroje automatizaci operací. [11]
2.1 Syntaxe V této kapitole popisuji syntaxi jazyka BPMN a to v jeho poslední verzi 2.0. Objekty jazyka BPMN se dělí do čtyř základních kategorií. [12]
Tokové objekty (Flow objects)
Spojovací objekty (Connecting objects)
Plavecké dráhy (Swim lanes)
Artefakty (Artifacts)
15
2.1.1 Tokové objekty Tokové objekty jsou základní grafické prvky definující chování firemních procesů. Dělí se do tří skupin události, činnosti a brány.
2.1.1.1 Události Události představují děj či událost, ke kterým v průběhu procesu dochází a ovlivňují ho. Může se jednat o počáteční událost, průběžnou událost anebo konečnou událost. Tyto typy událostí se ještě mohou dělit na zprávy, časovače nebo signály.
Obrázek 2-1 Příklady událostí
2.1.1.2 Aktivity Tyto prvky znázorňují činnosti, které se odehrávají uvnitř procesu. Rozlišujeme 2 druhy aktivit a to podproces a úloha. Úlohy se dále dělí na uživatelské úlohy, úlohy přijímající zprávu, úlohy odesílající zprávu atd. Podproces se používá na skrytí části procesu, který nechceme na aktuální úrovni modelu zobrazit.
16
Obrázek 2-2 Aktivity
2.1.1.3 Brány Brány se používají pro zobrazení větvení a slučování toků nebo procesů, kdy dochází k zohlednění různých podmínek. Brány se dělí na další typy například exkluzivní, inkluzivní, komplexní nebo paralelní. Exkluzivní brána vytváří několik různých toků procesu, ale proces vždy projde pouze jednou z nich. Inkluzivní brána se používá tam, kde proces může projít přes danou bránu vícekrát než jednou.
Obrázek 2-3 Brány
2.1.2 Spojovací objekty Spojovací objekty slouží ke spojování tokových objektů. Dělí se na sekvenční tok, tok zpráv a asociaci.
17
Pomocí sekvenčního toku znázorňujeme posloupnost procesních toků. Zdrojem a cílem je vždy aktivita, událost nebo brána. Sekvenční tok nesmí přesahovat hranice bazénu ani podprocesu. Tok zpráv nám říká, jaké zprávy proudí přes hranice bazénů, lze ho využít pro komunikaci v rámci dvou a více bazénů, tudíž ho nelze použít k propojení činností uvnitř jednoho bazénu. Používá se pro připojení artefaktů nebo textu k tokovým objektům. [13]
Obrázek 2-4 Toky
2.1.3 Plavecké dráhy Plavecké dráhy umožňují organizování a kategorizaci činností. Dělí se na dva typy a to bazén a dráhu. Bazén slouží k oddělování různých části popisované organizace. Součástí bazénu jsou dráhy a používají se k organizaci a kategorizaci činností v rámci bazénu. Často se aktivity v nich dělí dle rolí a funkcí.
Obrázek 2-5 Plavecké dráhy
2.1.4 Artefakty Artefakty rozšiřují portfolio elementu BPMN, umožňují přidat rozšiřující
18
informace do modelu procesu. Pomáhají zvyšovat informační hodnotu modelu. Existují tyto artefakty: datové objekty, skupiny, Anotace. Datové objektu znázorňují data, která jsou využívána při vykonávání dané aktivity. Skupiny umožňují seskupovat prvky modelu do skupin, ale do samotného toku diagramu nezasahují. Nejsou svazovány hranicemi bazénu. Anotace slouží pro zvýšení přehlednosti a srozumitelnosti celého modelu.
Obrázek 2-6 Artefakty
2.2 Bizagi BPMN Process Modeler Pro vizualizaci analyzovaných procesů jsem použil jedno z volně dostupných řešení s názvem Bizagi BPMN Process Modeler od společnosti Bizagi. Jedná se o velmi intuitivní nástroj, který umožňuje modelovat procesy a řádně je dokumentovat a to vše za použití standartní notace BPMN. Má podporu pro týmovou spolupráci, podporuje využití centrálního uložiště.
19
3 CMMI Tato kapitola popisuje standard CMMI1 a to převážně jeho část pro vývoj CMMI-DEV V1.3. Vysvětluje základní pojmy tohoto standardu a popisuje způsob hodnocení vyspělosti procesních modelů.
3.1 Historie Autorem modelu CMMI je tým pracující při Carnegie Mellon University, konkrétně jejich Software Engineering Institute, zkráceně SEI-CMU. SEI-CMU vydalo první model pro softwarové procesy v roce 1987. Tento model vycházel ze starších standardů a prací zejména z práce Phila Crosbyho Quality is Free, ve které definoval Maturity Grid, matici která byla pro CMMI ideovým základem. Model byl postupně vyvíjen a poprvé dostal označení CMM — Capability Maturity Model v roce 1990. V roce 1995 byla vydána verze modelu pro návrh celých technologických celků — SE-CMM System Engineering CMM. Vedle sebe tak existovaly dva velmi podobné standardy pro stejný typ práce: CMMI, označované nadále jako SW-CMM pro softwarové týmy a SECMM pro týmy technické. Sloučením dvou podobných modelů vedla v roce 2000 ke vzniku CMMI. Přidané slůvko „integrated“ značí, že model integruje několik standardů dohromady. [14] Postupem času vznikaly nové a nové propracovanější verze tohoto modelu. V současnosti je aktuální verze CMMI Version 1.3. Model CMMI se nyní skládá ze tří modelů:
1
CMMI for Development (CMMI-DEV)
CMMI for Services (CMMI-SVC)
Capability Maturity Model Integration
20
CMMI for Acquisition (CMMI-ACQ)
Obrázek 3-1 Historie CMMI [12]
3.2 Popis 3.2.1 Procesní oblasti CMMI rozděluje procesy do 22 procesních oblastí, kde 16 je společných pro celý model, jedna je sdílená s jedním dalším modelem a pět jich je speciálně pro model CMMI-DEV. Těchto 22 oblastí je rozděleno do čtyř kategorií dle organizačního zaměření. [15]
21
Tabulka 3-1 Procesní oblasti dle organizačního zaměření [16] Organizační zaměření (typy činností)
Oblast procesu Vývoj požadavků Technické řešení
Návrh a realizace (Engineering)
Integrace produktu Verifikace Validace Plánování projektu Sledování a řízení projektu Integrovaná správa projektů
Řízení projektu
Dohoda o vedení dodavatele Správa požadavků Řízení rizik Správa množstevních projektu Zaměření na organizační proces Organizační definice procesu
Správa procesů
Organizační školení Výkon organizačního procesu Organizační inovace a nasazení Správa konfigurací Zajištění kvality procesu a produktu
Podpůrné procesy
Měření a analýza Analýza rozhodnutí a řešení Analýza a řešení příčin
Následující tabulka popisuje podmínky předmětu nebo účelu každé procesní oblasti. Tabulka 3-2 Popis procesních oblastí [16] Oblast procesu
Účel
CAR – Analýza a řešení příčin
Zjistěte hlavní příčinu výjimečných problémů procesu (zvláštní proměny příčin pro použití W. Termín Edwardse Deminga) a navrhněte a implementujte změny procesu, abyste zabránili opakování. Pozornost je směrována na neobvyklé chování kvantitativně chápaných stabilních procesů. Každodenní překvapení by byla pravděpodobně považována za součást řízení rizika (RSKM), nikoli CAR.
22
CM — Správa konfigurací
Namísto pouhého řízení verze zdrojového kódu tato oblast procesu zahrnuje veškerou správu týkající se systémového prostředí, konfigurace součástí, platforem, middleware, aplikací a dokumentace. Schopnost úspěšně vytvářet a zavádět pracovní kód spadající do této oblasti procesu.
DAR – Analýza rozhodnutí a řešení
Pro všechna klíčová rozhodnutí v rámci projektu nebo vývoje produktu ukažte, že byla zvážena sada alternativ nebo možností a že k posouzení vhodnosti možností byly použity kontextové prvky. Zaznamenejte rozhodnutí a vybrané důvody.
IPM — Integrovaná správa projektů
Tato druhá úroveň řízení projektů v rámci modelu CMMI naznačuje, že organizace je schopna zpracovávat více potenciálně závislých projektů současně. To je často dosaženo pomocí programu nebo portfolia podnikové správy.
MA – Měření a analýza
Sběr dat o výkonu procesu, projektu a produktu. Vytváření metrik a ukazatelů ve formě sestav založených na datech.
OPD — Organizační definice procesu
Organizace by měly mít jednu nebo více definic procesů, které jsou definovány v kontextu. Kontext popisuje profil rizika. U každého projektu lze posoudit rizika a definici procesu vybranou z organizačního katalogu a pak odpovídajícím způsobem přizpůsobit.
OPF – Zaměření na organizační proces
Organizace by se měly domnívat, že proces definice definuje a ovlivňuje schopnost a že zlepšení schopností je především úsilím vylepšených procesů. V důsledku toho organizace aktivně spravuje své definice procesů a monitory (pomocí oblasti procesu PPQA) s cílem zajistit, že jsou tyto definice dodrženy.
OPM – Správa organizační výkonnosti
Tato procesní oblast zapouzdří pojem statistická znalost, jak dobré výsledky proces poskytuje oproti očekávaným možnostem. Změny procesu za účelem zlepšení schopnosti lze vyhodnotit a posoudit základní model pro proces, pokud zjištěné výsledky neodpovídají výsledkům předpokládaným základním modelem při provedení změny definice procesu. Jeho obchodní potřeby organizace spravuje svůj výkon prostřednictvím svých obchodních procesů.
OPP – Výkon organizačního procesu
Tato procesní oblast zapouzdří pojem porovnání výkonu, který je často označován jako „benchmarking“ (testování). OPP vytvoří procesní modely z porovnání dat směrného plánu. To umožňuje organizaci odpovědět na otázky typu „Které naše tři produktové týmy jsme měli zvolit pro [tento určitý projekt]?“
Organizační školení
Individuální schopnosti při specifických postupech jsou důležité pro výkon procesu a možnosti systému. Správně fungující systém se silným výkonem bude mít silnou schopnost školení vedoucí ke snížení variability ve schopnostech na místní úrovni praxe.
Integrace produktu
Možnost integrovat více komponent do formy kompletního výrobku a spravovat požadované prvky, aby to bylo možné.
Sledování a řízení Shromažďujte údaje o probíhajících projektech, porovnávejte je oproti projektu plánům, projekcím a simulacím a na jejich základě přijímejte vhodná opatření. Plánování projektu Plánujte projekty na základě odhadů, simulace a analýzy požadavků.
23
Zajištění kvality procesu a produktu
Především proces auditu shody. Účelem je ukázat, že systém pracuje v souladu se záměrem. Pomáhá zabránit potenciálním chybám správy a změnit proces za účelem nápravy problému, pokud není dodržován správný postup procesu.
Správa množstevních projektu
Toto je třetí a nejvyšší úroveň řízení projektu v rámci modelu CMMI. To znamená, že statisticky spolehlivé kvantitativní metody slouží k plánování, monitorování a řízení projektů.
Vývoj požadavků Existuje definovaný, opakovatelný proces k vyzývání, vyjednávání, analýze a dokumentaci požadavků. Správa požadavků Požadavky jsou sledovány po celou dobu životnosti projektu a ideálním existuje kompletní sledovatelnost mezi dodanou konfigurací a původní žádostí s požadavky. Řízení rizik
Přestože celý model CMMI lze vnímat jako rámec pro řízení rizik, tato oblast procesu řeší především „rizika na základě událostí“ nebo pravděpodobnost a dopad změn zvláštních příčin a každodenních překvapení. Tato oblast vyžaduje proces omezení rizika, zmírnění, pohotovostního plánování, správy problémů a řešení.
Dohoda o vedení dodavatele
Možnost spravovat externí dodavatele, definovat dohody, spravovat kontrakt a převzít dodávku požadovaného produktu nebo služby.
Technické řešení
Všechny dovednosti vyžadované vzhledem k architektuře softwaru, návrhu a kódování.
Verifikace
Souhlas s testováním podle požadavků zákazníků.
Validace
Testování proti návrhu (z technického řešení). Usiluje o zajištění toho, že vytvářené produkty budou představeny, navrženy a sestaveny tak, aby vyhovovaly potřebám uživatelů a fungovaly v jejich prostředí.
3.2.2 Úrovně vyspělosti CMMI definuje způsob hodnocení organizace jako celku a to za pomocí stupňovitého modelu vyspělosti. Model vyspělosti je pětistupňové hodnocení firmy. Každá úroveň má pevně dané procesní oblasti, které musí firma splňovat pro dosažení příslušného stupně vyspělosti.
1. stupeň vyspělosti (počáteční) Jedná se o nejnižší stupeň vyspělosti. Ve společnosti na této úrovni vyspělosti de facto nedochází k žádnému řízení procesů, procesy jsou vykonávány nesystematicky. S největší pravděpodobnosti tato firma dodává své produkty se zpožděním a bez velkých zisků.
24
2. Stupeň vyspělosti (spravovaný) Projekty společnosti splňující tento stupeň mají zajištěné kvalitní zdroje, vedoucí pracovníci přehled o projektu a výstupy projektu naplňují očekávání. Projekty jsou řešeny na základě plánovaných procesů. Procesní oblasti 2. stupně:
CM — Správa konfigurací
MA – Měření a analýza
SAM – Dohoda o vedení dodavatele
PP – Plánování projektu
PMC – Sledování a řízení projektu
RM — Správa požadavků
PPQA — Zajištění kvality procesu a produktu
3. stupeň vyspělosti (definovaný) Procesy prováděné v tomto stupni vyspělosti jsou velmi dobře specifikované, popsané a řádně zdokumentované. Standardy, specifikace procesů a jejich procedury jsou sdílené a pevně dané pro celou společnost. Procesní oblasti 3. stupně:
RD – Vývoj požadavků
TS – Technické řešení
PI – Integrace produktu
VER – Verifikace
VAL – Validace
IPM – Integrovaná správa projektů
RSKM — Řízení rizik
OPF – Zaměření na organizační proces
OPD – Organizační definice procesu
OT — Organizační školení
DAR – Analýza rozhodnutí a řešení
25
4. stupeň vyspělosti (kvantitativně spravovaný) Procesy ve společnosti na 4. Stupni jsou hromadně spravované a kontrolované, čehož se využívá pro analýzy a statistiky, na jejichž základě se vytváří předpoklady. Procesní oblasti 4. Stupně:
OPP – Výkon organizačního procesu
QPM – Správa množstevních projektu
5. stupeň vyspělosti (optimalizující) Na základě splnění předchozích stupňů jsou na 5. stupni jsou procesy neustále optimalizovány, což vede k tomu, že jsou i na tomto stupni odstraňovány chyby. Procesní oblasti 5. Stupně:
CAR – Analýza a řešení příčin
OPM – Správa organizační výkonnosti
3.2.3 Cíle procesních oblastí Pro splnění každé procesní oblasti je nutné dosáhnout jejích specifických cílů, které jsou pro každou oblast unikátní. Dále jsou definovány generické cíle, ty jsou však stejné pro všechny procesní oblasti.
3.2.3.1 Specifické cíle a praktiky Specifické cíle definují unikátní charakteristiky, které se musí v procesech společnosti nacházet, aby byla daná oblast naplněna. Pro každou oblast bývají jeden až tři specifické cíle. Každý specifický cíl v sobě obsahuje několik specifických praktik. Jedná se o popis aktivity, která je považována za důležitou pro dosáhnutí specifického cíle. [15] Tyto praktiky zároveň obsahují popis postupu, jak dosáhnout naplnění těchto praktik a tím i samotných specifických cílů.
26
3.2.3.2 Generické cíle Generické
cíle
jsou
sdílené
pro
všechny
procesní
oblasti.
Popisují
charakteristiky, které musí proces splnit, aby byla oblast implementována. I generické cíle mají své praktiky. Generické cíle jsou celkem tři. Druhý stupeň vyspělosti vyžaduje splnění pouze prvních dvou. Všechny následující stupně požadují splnění všech tří generických cílů. [15] Pro dosažení prvního generického cíle je nutné dosáhnout všech specifický cílů dané procesní oblasti. Druhý generický cíl vyžaduje, aby provádění procesů z dané oblasti bylo řízené. Musí existovat jasně daný plán pro jednotlivé procesy, procesy musí mít vyhrazené a dostupně zdroje, jasně stanovené role a odpovědnosti. Pro každý proces je zdokumentováno, jak se má daný proces vykonat a je stanoveno, jaké výstupy a produkty jsou kontrolovány a monitorovány. Třetího generického cíle je dosaženo tehdy, pokud pro každý proces v daném projektu existuje standartní proces, který není nutné modifikovat, ale lze ho rovnou použit pro tento proces.
3.3 CMMI vs. ISO ISO/IEC 15504, známý také jako SPICE, je modelu CMMI velmi podobný. (CMMI se standardu ISO/IEC 15504 přizpůsobilo tím, že zavedlo kontinuální model implementace a upravilo některé požadavky). Použití obou standardů je v podstatě rovnocenné a i posouzení na shodu se CMMI a audit podle ISO/IEC mají v stejnou váhu. Rozhodnutí, zda usilovat o posouzení shody procesů se CMMI nebo certifikát na ISO/IEC 15504 tedy závisí ne na standardech, ale spíš na zákaznících a trhu, pro který daná firma pracuje. Obecně CMMI je praktičtější pro implementaci, protože obsahuje řadu návodu a doporučení, kdežto evropský standard je mnohem stručnější. Pro většinu firem, které standard CMMI implementují, je navíc často argumentem, že standard CMMI je volně ke stažení na Internetu, takže se s
27
ním pracovníci snadněji seznámí. Na druhou stranu, certifikace podle ISO/IEC 15504 vyjde levněji než posouzení podle CMMI. [17]
28
4 Procesní analýza Tato procesní analýza byla vypracovávána na základě mých pracovních zkušenosti v analyzované společnosti a na základě občasných konzultací s naším projektovým manažérem. Struktura textu je inspirována vzorovou šablonou pro procesní analýzu, která mi byla představena v předmětu PV207 Business Process Management v rámci studia oboru SSME. Šablonu jsem přeložil do češtiny, upravil a zjednodušil.
4.1 Charakteristika společnosti 4.1.1 Kontext Společnost, v níž jsem prováděl procesní analýzu, se zaměřuje na tvorbu zakázkového softwaru na míru dle potřeb a specifikace konkrétního koncového zákazníka. Zároveň již několik let figuruje jako subdodavatel české divize jednoho z hlavních dodavatelů komplexních IT řešení na celosvětovém trhu. Práce na outsourcovaných projektech má svá specifika. Často doplácí na selhání komunikace na jedné ze tří stran tohoto vztahu. Svá úskalí má i integrace vlastních řešení s dalšími subdodavateli. Hlavními doménami, ve kterých společnost působí a již v rámci nich řešila projekty, jsou zdravotnictví, hutní průmysl, řízení výroby. Podle rozdělení firem v kapitole 1.1.1 spadá tato společnost do skupiny malých firem.
4.1.2 Strategie a vize Společnost usiluje o upevnění si své pozice jednoho z hlavních subdodavatelů
29
výše zmiňované nadnárodní IT společnosti. Snaží se o pravidelné získávání nových zakázek pro tohoto dodavatele a to hlavně na základě dobrých zkušeností z minulých projektů, které již pro tuto společnost realizovala. Dále chce vedení společnosti pokračovat v rozšiřování skupiny zákazníků, kterým dodává softwarová řešení napřímo jako hlavní dodavatel. Od tohoto kroku si vedení slibuje stabilnější pozici na trhu a menší závislost na jednom velkém dodavateli. V neposlední řádě nyní vedení společnosti uvažuje o rozšíření svého působení i mimo hranice České republiky.
4.1.3 Cíle Hlavní cíle
poskytovat komplexní služby v oblasti implementace zakázkového softwaru na míru
získávat pravidelně nové zakázky a rozšířit základnu stálých zákazníků
upevnit svou pozici subdodavatele pro partnerskou nadnárodní korporaci
Vedlejší cíle
zajistit komfortní a zároveň produktivní prostředí ve firemním kolektivu
udržovat dobře proškolený, kreativní a invenční tým pracovníků
optimalizovat hlavní firemní procesy, aby bylo dosaženo vyšší výkonosti a efektivnosti
expandovat za hranice České republiky
30
4.1.4 Organizační struktura Na vrcholu celé organizační pyramidy této společnosti je vedení mateřské firmy, které je analyzovaná firma součástí. Jednatelé a vedení mateřského subjektu spíše pouze dozorují činnost dceřiné společnosti a kontrolují, aby si udržela finanční stabilitu a rozvoj. Organizační struktura této dceřiné společnosti se asi nejvíce podobá společnosti s funkční organizační strukturou. Funkční organizační struktura je nejzákladnější formou organizace, kde jsou zaměstnanci s podobnými úkoly, schopnostmi anebo aktivitami zařazeni do jedné skupiny. [18] V tomto případě jsou těmito skupinami Oddělení analýzy, Oddělení testování, Oddělení vývoje, Technické oddělení.
4.1.4.1 Role a odpovědnosti Vedení společnosti, jednatelé Jedná se o skupinu nejvýše postavených zaměstnanců firmy. Jejich úkolem je řídit společnost a dozorovat nad chodem společnosti. Dále se starají o její finanční prosperitu a finanční toky v rámci společnosti. Mají právo vystupovat jako zástupci firmy a mohou podnikat právní úkony jménem firmy, jako jsou například uzavírání smluv s dodavateli a zákazníky, manipulace s majetkem firmy atd. Do každodenních procesů probíhajících uvnitř dceřiné firmy a přímo zasahujících do vývoje, či testování se téměř nezapojují.
Ředitel Je jedním z ředitelů společnosti. Jeho hlavním úkolem je vedení firmy po administrativní stránce. Stará se o náležitosti spojené se smlouvami se zákazníky. Dohlíží na to, aby byly tyto smlouvy dodrženy. Dále jedná se zákazníky o akceptaci projektů, o zaplacení akceptovaných projektů a dalších
31
smlouvami vázaných problémech. Nedílnou součástí jeho odpovědností je získávání nových zakázek a marketingová činnost společnosti. V neposlední řadě je přímým spojením s vedením a jednateli firmy. Účastní se pravidelných schůzek vedení a aplikuje jejich přání, nařízení, či zákazy do chodu společnosti.
Technický ředitel Tento post se od postu Ředitele liší převážně tím, že Technický ředitel neřeší administrativní záležitosti, ale konkrétní technické, analytické, vývojové a testovací problémy jednotlivých projektů. Na rozdíl od Ředitele má technické znalosti v jednotlivých odvětvích vývoje a orientuje se v doménách, již se řešené projekty dotýkají. Účastní se pravidelných schůzek se zákazníky, kde se probírají problémy či úspěchy konkrétních projektů. Zodpovídá za tvorbu nabídek na implementace nových projektů, připomínkuje analytické projekty a další výstupní dokumenty, jež jsou určeny zákazníkovi.
Projektový manažér Hlavní pracovní náplní projektového manažéra je plánování jednotlivých projektů, jejich řízení a komunikace s projektovým týmem. V počátcích projektu PM sestavuje projektový tým. Po dobu trvání celého projektu monitoruje jeho průběh a stará se o dodržení plánu. Reaguje na komplikace, které se objeví v průběhu projektu. PM má odpovědnost za kvalitu a formální stránku výstupů projektu jako jsou například dokumentace, zápisy z jednání se zákazníkem či dodavatelem, reporty z meetingů a podobně.
32
Hlavní analytik Organizuje činnost celého analytického oddělení a je autorem všech analytických projektů, které toto oddělení vytvoří. Orientuje se v obchodní problematice jednotlivých projektů a jeho úkolem je zaškolení členů vývojového, testovacího i analytického týmu v rámci každého nově řešeného projektu. Hlavní analytik se účastní se analytických schůzek se zákazníkem, kde se domlouvají požadavky na projekt. Jeho úkolem je, co nejdetailněji a nejvýstižněji specifikovat požadavky zákazníka. V průběhu projektu řeší nejasnosti, které se naskytnou. Případně svolává jednání, kde jsou tyto problémy řešeny.
Vedoucí testovacího oddělení Řídí činnost celého testovacího oddělení a stará se o rozdělení úkolů v tomto oddělení. Také udržuje evidenci reportovaných problémů v rámci jednotlivých projektů a stará se o to, aby byly všechny tyto problémy řešeny a přiděleny příslušnému testerovi. Jeho úkolem je tvorba testovacích scénářů a dalších dokumentů, které provázejí celý proces testování vyvíjených aplikací.
Hlavní programátor Je vedoucím týmu programátorů. Ve spolupráci s projektovým manažérem rozděluje a plánuje práci v rámci svého oddělení. Zodpovídá
za
technickou
dokumentaci
jednotlivých
implementovaných modulů. Úzce spolupracuje s analytiky při návrhu řešení a při volbě vhodných technologií.
33
Analytik Plní úkoly, které mu jsou přiděleny hlavním analytikem. Řeší dílčí analytické problémy, které diskutuje s hlavním analytikem. V případě potřeby zastupuje hlavního analytika, účastní se schůzek se zákazníkem. Spolupracuje s testovacím a vývojovým oddělením při řešení problémů a nejasnosti, které se v rámci implementace projektu vyskytnou.
Programátor Hlavní odpovědností programátora je implementace nových modulů, správa a oprava existujících. Tyto činnosti vykonává na základě zadání od analytika či hlavního programátora. Nové či upravené moduly předává do testovacího procesu testerům. Na základě výsledků testu modul buď odesílá k distribuci, anebo probíhá ladění a opětovné odeslání k testu. Dále zodpovídá za připravenost testovacího prostředí, vytváří data nebo pomáhá s jejich přípravou.
Tester Kontroluje korektnost implementovaných modulů a rozhoduje, zdali jsou již ve stavu, kdy je možné je nasadit do provozu. Podněcuje
inovace
zkušeností s testováním.
v nasazených Skrze
aplikacích
na
základě
evidenci interních problémů
svých
navrhuje
potenciální inovace či opravy.
Asistentka ředitele, personální Podporuje ředitele v jeho činnosti, stará se o organizaci jeho času, jeho schůzek a podobně. Její další rolí je funkce personalistky. Sestavuje smlouvy zaměstnanců a
34
další příslušné dokumenty související s činností personalistky. Zároveň se stará o finanční záležitosti firmy. Vytváří podklady pro mzdovou účetní mateřské firmy. Drží pokladnu firmy. Zajišťuje dodávky spotřebního zboží, které je pro chod společnosti potřeba, jako jsou například káva, kancelářské potřeby, stravenky.
BackOffice manažer Zpracovává nově příchozí reportované problémy v dodávaných aplikacích, které přichází od zákazníka. Eviduje je v interním systému pro evidenci chyb a předává tyto problémy k řešení oddělení programátorů. Dále odesílá potvrzení o přijetí těchto problémů. Předává informaci o jejich vyřešení. Jeho hlavní agendou je řízení distribucí jednotlivých oprav či nových modulů. Sestavuje doprovodné dokumenty k záplatám či nasazování nových aplikací. V neposlední řadě udržuje dokumentový server, spravuje verze dokumentů a stará se o jejich distribuci na příslušná místa. Na
základě
interního
systému
generuje
reporty
pro
ředitele,
technického ředitele a projektového manažera.
Hardwarový specialista Hlavní odpovědností HW specialisty je vedení technického oddělení. Mimo to spravuje počítače, servery a sítě v budově firmy. Zároveň se správou HW, má na starosti také licence k programovému vybavení, které členové týmů ke své práci potřebují. V případě požadavků na nový hardware nebo software je prvním, kdo hodnotí relevantnost tohoto požadavku. V případě schválení, postupuje tento požadavek dál.
35
Databázový specialista Databázový specialista se podílí na návrhu nových aplikací nebo změn stávajících a to z pohledu návrhu vhodných databázových řešení a použití vhodných technologií. Jeho role přichází na řadu v momentě, kdy programátoři nejsou schopni sami o sobě optimalizovat výkon aplikace například složité databázové výběry a podobně. Dále je konzultantem pro řešení a analýzu technických problémů zákazníka. Ale to vše pouze v rovině konzultační, jelikož na straně zákazníka jsou již příslušní administrátoři, kteří tyto problémy řeší.
36
Obrázek 4-1 Organizační struktura společnosti
4.1.5 Procesy Při analýze jsem objevil a pokusil jsem se, co nejlépe popsat následující procesy:
Hlavní firemní proces
37
Získání nové zakázky
Analýza nové zakázky
Vývoj nového systému
Rozšíření existujícího systému
Podpora
Nasazení nového systému
Propagace (marketing)
Vzdělávání zaměstnanců
Nábor nového zaměstnance
Správa hardware a software
Správa financí
Správa dokumentů
Následující procesní mapa zobrazuje, které z nich jsou hlavní a které podpůrné.
Obrázek 4-2 Procesní mapa
38
4.1.5.1 Hlavní proces 4.1.5.1.1 Popis Hlavní proces popisuje posloupnost jednotlivých hlavní firemní (sub)procesů, které jsou detailně dekomponovány níže. Obsahuje v sobě všechny hlavní firemní procesy, jedná se o procesy Získání nové zakázky, Analýza nové zakázky, Vývoj nového systému, Nasazení nového systému, Podpora, Rozšíření existujícího systému. Pro názornost je v následující kapitolem proces znázorněn graficky.
4.1.5.1.2 Model
Obrázek 4-3 Hlavní firemní proces
4.1.5.2 Proces Získání nové zakázky 4.1.5.2.1 Popis Proces Získání nové zakázky popisuje, jakým způsobem probíhá ucházení se o novou zakázku skrze výběrové řízení vyhlášené zadavatelem (zákazníkem). Jakmile ředitel obdrží zprávu o novém výběrovém řízení včetně specifikace požadavků zákazníka, provede analýzu zadání. Po konzultacích
39
s hlavním analytikem stanoví, zdali je zakázka vhodná pro tuto firmu. Hodnotí technické nároky zakázky, potřebné know-how, finanční rentabilitu a současné volné zdroje jednotlivých týmů. V průběhu této analýzy konzultuje s hlavním analytikem, projektovým manažérem i technickým ředitelem. Účast ve výběrovém řízení buď zamítne, pak firma o danou zakázku neusiluje, anebo ji schválí a předá příslušné podklady hlavnímu analytikovi. Hlavní analytik na základě předaných materiálu provede jejich analýzu a ve spolupráci s ostatními analytiky, hlavním programátorem a technickým ředitelem vypracuje nabídku pro danou zakázku. Nabídka se skládá z návrhu řešení, odhadu časové náročnosti řešení a v neposlední obsahuje cenovou kalkulaci celého navrhovaného řešení. Takto vytvořenou nabídku odesílá ředitel zákazníkovi spolu s přihláškou k výběrovému řízení. V průběhu vyhodnocování nabídek od účastníků výběrového řízení občas zadavatel svolává schůzky, kde se vyjasňují případně nejasnosti. Těchto schůzek se za tuto společnost nejčastěji účastní technický ředitel a hlavní analytik. Pokud ve výběrovém řízení společnost uspěje, je tato nabídka předána analytickému oddělení, které provede detailní analýzu a návrh řešení. Tuto část popisuji v kapitole 4.1.5.3.
40
4.1.5.2.2 Model
Obrázek 4-4 Získání nové zakázky
4.1.5.3 Proces Analýza nové zakázky 4.1.5.3.1 Popis Analýza nové zakázky začíná v momentě, kdy ředitel společnosti pro tuto zakázku pošle hlavnímu analytikovi schválenou nabídku a podklady k implementaci. Na základě ní hlavní analytik ve spolupráci s ostatními analytiky začne
41
analyzovat jednotlivé části nového systému. Rozdělí práci mezi analytiky. Výstupem této práce je analytický projekt. V průběhu vytváření je obsah tohoto dokumentu konzultován s oddělením vývoje, v případě potřeby se na jeho tvorbě podílí i další techničtí specialisté. Pokud má budoucí systém kooperovat s jinými systémy, je nutné analyzovat i integrační vazby. V tomto případě je většinou nutné uspořádat Nově vzniknuvší dokument obsahuje nejen popis řešené problematiky, ale i návrh řešení, rozdělení jednotlivých rolí a podobně. Hotový analytický projekt hlavní analytik posílá zadavateli ke schválení. Zadavatel znění tohoto dokumentu buď schválí, anebo ho pošle zpět s případnými připomínkami a návrhy na změnu. V případě většího množství připomínek a nejasností je většinou uspořádána schůzka, kde jsou diskutovány vzniklé nejasnosti. Na základě získaných informací analytické oddělení provádí opětovné analýzy a analytický projekt je na základě nich upraven. Poté se celý proces odeslání ke schválení opakuje, dokud není celý dokument schválen zadavatelem. Jakmile dojde k jeho schválení, předává hlavní analytik celý projekt k řešení oddělení vývoje, kde si ho přebírá hlavní programátor a rozděluje jednotlivé úkoly programátorům. Tento proces popisuje kapitola 4.1.5.4. Pro lepší ilustraci procesu Analýza nové zakázky obsahuje následující podkapitola model procesu.
42
4.1.5.3.2 Model
Obrázek 4-5 Analýza nové zakázky
4.1.5.4 Proces Implementace nového systému 4.1.5.4.1 Popis Proces Implementace nového systému započíná, jakmile hlavní analytik předá do oddělení vývoje analytický projekt. Hlavní programátor po prostudování tohoto dokumentu dekomponuje budoucí aplikaci na jednotlivé moduly, na základě nich vytvoří úkoly pro programátory. Programátor obdrží úkol implementovat konkrétní modul. Nastuduje si analytický projekt a započne implementaci. V průběhu implementace
43
konzultuje případné nejasnosti s hlavním programátorem a s příslušnými analytiky. Po dokončení implementace provede jednotkové testy nového modulu a v případě, že je vše v pořádku, předá modul k otestování testovacímu oddělení. Tester se po seznámení se s analytickým projektem pustí do testování. V průběhu komunikuje s programátorem daného modulu a případně i s analytikem. Po ukončení testů předá modul zpět programátorovi, který v případě negativního výsledku testu, modul opraví, otestuje a opět předá testerovi. Tato část procesu se opakuje, dokud tester neshledá modul jako korektní a bezchybný. V tomto momentě programátor informuje hlavního programátora o splnění úkolu. Hlavní programátor kontroluje práci programátorů, a jakmile jsou implementovány a otestovány všechny moduly, předává zprávu hlavnímu analytikovi. Na tento proces plynně navazuje proces Nasazení nového systému, který je popsán v kapitole 4.1.5.5. V následující kapitole naleznete model celého procesu v grafické podobě.
44
4.1.5.4.2 Model
Obrázek 4-6 Implementace nového systému
4.1.5.5 Proces Nasazení nového systému Samotnému nasazení nového systému předchází série příprav. Nejprve Projektový manažer ve spolupráci s integrátorem a zákazníkem naplánuje celý proces nasazení. Pro každou fázi nasazení definují podmínky, kdy je možně postoupit do následující fáze. Jakmile se vše naplánuje a podepíše všemi stranami, může se v plánovaném termínu přistoupit k samotnému nasazení.
45
Nejprve na straně zákazníka jeho technici a správci dle specifikace připraví potřebné servery, datová uložiště a adekvátní síťovou infrastrukturu. Oddělení vývoje ve spolupráci s technickými specialisty připraví instalační balík pro prvotní instalaci. Následuje fáze instalace, kdy správci systému na straně zákazníka spustí instalační balíky, této akci jsou přítomni i projektový manažér a hlavní programátor naší společnosti. Případné komplikace řeší hlavní programátor na místě, a pokud je potřeba tak vzdáleně ve spolupráci s programátory ve firmě. Po úspěšné instalaci se spouští takzvaný pilotní běh, kdy uživatelé začnou nasazenou aplikaci používat. V průběhu pilotu se rychle a pružně řeší problémy, které nastanou. Instalují se opravné záplaty a celá aplikace se ladí, aby mohla přejít do ostrého provozu. Po uplynutí stanovené doby pro běh pilotu, přichází na řadu hodnocení pilotu. Pokud zákazník pilot neakceptuje jako úspěšný, běh pilotu se prodlužuje a nadále se aplikace ladí a opravují se chyby. Jakmile zákazník pilot akceptuje, nic nebrání posunu do další finální fáze a to přepnutí do ostrého provozu, kdy již zaměstnanci zákazníka s aplikací začnou pracovat naplno. Po uvedení aplikace do provozu přichází na řadu jednání o akceptaci celého projektu. Akceptace je důležitý bod pro společnost, jelikož jakmile je projekt akceptován, zákazník celou zakázku musí také zaplatit. V rámci jednání o akceptaci se zároveň dojednává smlouva, která definuje, jak bude probíhat podpora aplikace, jak bude placena a jak dlouho bude podpora trvat. Standardně podpora trvá v rozmezí dvou až pěti let.
4.1.5.6 Proces Podpora Podpora nasazeného systému začíná podpisem smlouvy o podpoře. Uživatelé na straně zákazníka většinou mají svůj interní systém pro evidování a sledování chyb a požadavků na změnu systému. Z toho systému skrze elektronický komunikační kanál například e-mail chodí hlášení o těchto
46
chybách. Tyto e-maily zpracovává BackOffice manažér a eviduje tyto problémy do interního systému pro evidenci chyb v dodávaných aplikacích. Supportní smlouva jasně stanovuje, jaká je reakční doba a doba vyřešení pro jednotlivé závažnosti reportovaných chyb. Tyto termíny jsou závazné a za jejich nedodržení hrozí finanční sankce. Po zaevidování chyby ji BackOffice manažér přiřadí v systému konkrétnímu analytikovi, který rozhodne, kdo ji bude řešit. Pokud se jedná o znovuotevřený problém, který se vrátil od zákazníka jako neúspěšně opravený, či bylo potřeba nějaké další upřesnění, předává ho rovnou dřívějšímu
řešiteli,
nejčastěji
programátorovi.
Každý
problém
má
definovaného svého analytika a i svého testera. Programátor chybu zanalyzuje a implementuje opravu, případně konzultuje jím navržené řešení s příslušným analytikem. Implementovanou opravu nasadí do testovacího prostředí a v systému odešle tuto chybu k testu. Tester
tuto
opravu
otestuje,
a
buď
ji
pošle
programátorovi
s připomínkami zpět, anebo ji schválí a problém v systému přiřadí zpět programátorovi. Ten se postará o distribuci opravy k zákazníkovi. Instalační balík je společně s průvodními dokumenty odeslán zákazníkovi. V evidenci je zároveň problém programátorem nastaven do stavu vyřešen a je předám zpět na BackOffice manažera. Ten zákazníkovi odešle reakci na jeho původní mail s informací o vyřešení problému a popisem řešení. Správci aplikace na straně zákazníka se postarají o instalaci a nasazení instalačního balíku. Pokud je oprava zákazníkem akceptována, problém se uzavírá. V případě, že není, problém se vrací zpět a celý proces se opakuje.
4.1.5.7 Proces Rozšíření existujícího systému Proces Rozšíření existujícího systému, přestože je součástí Hlavního procesu, je v podstatě téměř totožný, jako celý Hlavní proces. Od získání zakázky, přes analýzu, implementaci až po nasazení, podporu a případné další rozšíření.
47
Má ale svoje specifika. Pokud je rozšiřovaný systém známým systémem, který byl vytvořen touto firmou, je proces analýzy jednodušší a rychlejší. Zároveň si práce oddělení vývoje i testování pracují rychleji a odpadá prvotní zaškolení a podobně. Trochu složitější je celá situace v případě rozšíření neznámého systému, který vytvořila jiná společnost. Je nutné vynaložit více prostředků na analýzu existujícího systému a velmi dobře nastudování technické dokumentace všemi členy týmu.
4.1.5.8 Proces Propagace (marketing) Hlavním prostředkem prezentace společnosti na veřejnosti jsou webové stránky, které popisují portfolio služeb, které nabízí. Stránka dále obsahuje reference na dříve řešené projekty. Stránky jsou pravidelně aktualizovány. Tato společnost nevyvíjí nějakou konkrétní veřejnou marketingovou aktivitu, jako třeba reklamu v mediích, či na sociálních sítích. Nové zakázky jsou získávány na základě kontaktů s partnerskou nadnárodní korporací, kde tato společnost figuruje na seznamu subdodavatelů a je informována o výběrových řízeních, které tato korporace vypisuje. V neposlední řadě jistou marketingovou činnost vykonává ředitel společnosti, který monitoruje výběrová řízení převážně ve státním sektoru a vybírá, která jsou vhodná, a případně do nich společnost přihlašuje.
4.1.5.9 Proces Vzdělávání zaměstnanců V současné době v této firmě neexistuje standardizovaný proces pravidelného školení a vzdělávání zaměstnanců. A to ani v oblasti technického vzdělávání, například o nových technologiích a postupech v používaných programovacích jazycích ani v oblasti cizích jazyků či měkkých dovedností. Zaměstnanci jsou vysílání na školení pouze v případě, že je nutné zvládnout nový programovací nástroj či jazyk anebo si osvojit schopnost manipulovat s novým neznámým hardwarem.
48
4.1.5.10
Proces Nábor nového zaměstnance
4.1.5.10.1
Popis
Podnět k přijetí nového zaměstnance většinou přichází od vedoucího některého z oddělení. Bývá to na základě přílišné vytíženosti jeho týmu, anebo z důvodu absence zaměstnance se specifickými znalostmi a schopnostmi, které jsou v rámci projektu vyžadovány. Vedoucí oddělení předává požadavek včetně nároků na nového člena týmu projektovému manažérovi. PM zhodnotí tento požadavek a buď ho zamítne jako neopodstatněný, anebo ho schválí a dále zpracuje. Na základě podkladů od vedoucího vytvoří detailní specifikaci a tu předá personalistce. Ta tuto specifikaci zformalizuje a vypíše výběrové řízení, o jeho vypsání informuje skrze inzerci. Pak následuje samotný proces výběrového řízení, kdy jsou jednotlivý uchazeči zváni na pohovory, kterých se účastní personalistka, projektový manažér a někdy i vedoucí příslušného oddělení. Pokud je vybrán vhodný kandidát, je mu nabídnuta pracovní smlouva a po provedení všech formalit je přijat do domluveného pracovního poměru. V této společnosti jsou převážně kmenoví zaměstnanci na plný pracovní zůstatek, dále pak společnost spolupracuje s několika externími pracovníky.
49
4.1.5.10.2
Model
Obrázek 4-7 Proces Nábor nového zaměstnance
4.1.5.11
Proces Správa hardware a software
Od zaměstnanců pravidelně přichází různorodé požadavky na nové hardwarové vybavení. HW specialista tyto požadavky vyhodnotí, a pokud je shledá relevantními, provede cenovou kalkulaci a předá tento požadavek řediteli. Ředitel tento požadavek buď schválí, či zamítne sám. V případě vyšší finanční náročnosti požadavku, postoupí jeho schválení na vyšší místa do mateřské společnosti. V případě potvrzení požadavku HW specialista zajistí
50
objednávku, předá fakturační podklady asistentce ředitele a ta se postará o úhradu. Analogicky probíhá celý proces vyřízení žádosti o nový software. Další větví toho procesu je řešení problémů s již zakoupeným vybavením. HW specialista analyzuje problematická zařízení, a buď je opraví sám, nebo je zasílá k dodavateli na reklamaci či opravu. Dále probíhá průběžná inovace hardwarového vybavení zaměstnanců vždy v pravidelných intervalech například po třech letech užívání.
4.1.5.12
Proces Správa financí
Správu financí mají v globálním měřítku této společnosti na starosti vedení a jednatelé mateřské společnosti. Řídí jaký obnos peněz má dceřiná společnost k dispozici. Veškeré fakturace zákazníků jdou přes tuto společnost a až jejich část putuje přímo k dceřiné společnosti. Stejný způsobem jsou řízeny i výdaje. Jsou schvalovány a kontrolovány shora. Samotné platby neprovádí asistentka ředitele (personální), ale účetní zmiňované mateřské společnosti. Na úrovni samotného podniku je v držení asistentky ředitele pokladna, která disponuje určitým obnosem pro běžné potřeby podniku. Tyto výdaje si řídí dceřiná společnost sama. Zaměstnanci, kteří mají přiřazené služební vozidlo, ke kterému mají i platební kartu, pro úhradu nákladů spojených s provozem vozidla.
4.1.5.13
Proces Správa dokumentů
Dokumenty jsou uchovávány na podnikovém DMS1 serveru. Obsah tohoto serveru je primárně ve správě BackOffice manažera. Ve spolupráci s HW specialistou se stará se o jeho bezproblémový chod. 1
Document management system neboli Systém pro správu dokumentů, je počítačový systém určený ke správě elektronických dokumentů a/nebo zdigitalizovaných papírových dokumentů, tj. např. dokumentů převedených do digitální podoby skenováním. [20]
51
Sám BackOffice manažér spravuje přístupová práva k jednotlivým částem toho systému. Díky tomuto řízení muže přistupovat k tomuto uložišti každý zaměstnanec, pouze se liší rozsah obsahu, který je mu zobrazen a který může editovat. Všechny průběžné dokumenty jsou vedeny v revizním módu, takže je jednoduché se vracet ke starším verzím, případně s nimi porovnávat. Každý dokument má svého vlastníka, správce, který nejčastěji i samotný dokument založil. Vlastník schvaluje změny, které v jeho dokumentech provedou jiní zaměstnanci. Toto uložiště obsahuje nejen interní dokumenty, ale všechny smlouvy, analýzy, nabídky, ujednání, akceptační kritéria a podobné významné dokumenty. DMS server je pravidelně zálohován, připojen k záložnímu zdroji energie a nachází se v zabezpečené místnosti chráněné alarmem.
52
5 Hodnocení procesního modelu V této kapitole jsou popsány výsledky hodnocení procesního modelu. Je stanoven výsledný stupeň vyspělosti modelu.
5.1 Metoda hodnocení Hodnocení probíhá na základě ověřování, zdali procesní model firmy splnil konkrétní procesní oblast zkoumaného stupně vyspělosti. Splnění procesní oblasti je dokázáno na základě dosažení specifických a generických cílů a to na základě splnění jejich specifických a generických praktik. Metodika hodnocení, která je použita v této kapitole, je jednou z oficiálních hodnotících technik standardu CMMI. Vychází z mechanismu PIID (practice implementation indicator description). Celá hodnotící technika se nazývá SCAMPI (The Standard CMMI Appraisal Method for Process Improvement). Celé posouzení se zakládá na hledání objektivních důkazů o přítomnosti jednotlivých praktik v procesech firmy. V této metodice existují 3 typy důkazů – přímé artefakty, nepřímé artefakty a prohlášení. Artefakty obecně jsou produkty (výstupy) praktiky.
Přímé artefakty Přímé artefakty jsou přímé výstupy praktiky, což znamená, že se jedná o služby nebo produkty, které jsou produkovány touto konkrétní praktikou.
Nepřímé artefakty Nepřímé artefakty jsou nepřímé výstupy praktiky, tedy jedná se o výstupy, které dokazují provedení dané praktiky, ale nejsou primárním důvodem provádění praktiky.
53
Prohlášení Prohlášení jsou ústní nebo písemná tvrzení, která potvrzují přítomnost dané praktiky v procesu. Tato tvrzení pochází od účastníku daného procesu
Pro splnění dané praktiky stačí, aby byly nalezeny alespoň dva ze tří možných důkazů. Když jsou splněny všechny praktiky dané generického nebo specifického cíle, považujeme cíl za splněný. Jakmile jsou za splněné prohlášeny všechny generické a specifické cíle dané procesní oblasti, je i tato oblast prohlášena za splněnou. Pokud jsou splněny všechny procesní oblasti daného stupně vyspělosti, považujeme tento stupeň za splněný.
5.2 Hodnocení vyspělosti modelu dle 2. Stupně První stupeň vyspělosti splňuje automaticky každý procesní model, tudíž se jím není potřeba dále zabývat. Posouzení vyspělosti procesního modelu dle 2. stupně bylo prováděno po jednotlivých procesních oblastech. V rámci těchto oblastí jsem zkoumal splnění jejich generických a specifických cílů.
54
5.2.1 Správa konfigurací Generický cíl 2 Konfigurační proces v této společnosti je plánován a dokumentován projektovým
manažérem.
Správa
systémového
prostředí,
stejně
jako
konfigurace součástí, platforem, aplikací a dokumentace se plně zapojuje do všech firemních procesů. Všechny tyto konfigurace jsou v průběhu vývoje kontrolovány. Konfigurace jsou evidovány v rámci interního dokumentového serveru. Díky těmto faktům můžeme považovat tento generický cíl za splněný. Splněný
Specifický cíl 1: Vytvoř kontrolní body Po celou dobu vývoje systému jsou projektovým manažérem ve spolupráci s hlavním analytikem, hlavním programátorem a vedoucím testovacího oddělení jsou v jednotlivých kontrolních bodech vytvářený a udržovány nové verze výstupů projektu jako jsou analytické projekty, dokumentace testování, výsledky testování, programová dokumentace a striktně verzovaný zdrojový kód. Tyto výstupy jsou ukládány na dokumentový server a jsou spravovány BackOffice manažérem. Všechny tyto konfigurační položky spadají do procesu Správy konfigurací. Díky důkazu existence tohoto procesu můžeme považovat tento specifický cíl za splněný. Splněný
Specifický cíl 2: Sleduj a kontroluj změny produktu Výše zmíněné konfigurační položky jsou udržovány včetně jejich celé historie verzí. Každá změna, která je provedena a následně schválena příslušnými zodpovědnými
vedoucími jednotlivých oddělení, je v tomto systému
55
evidována. Pokaždé pokud je do systému zaveden nový požadavek na změnu konfigurační položky, je vytvořená nová vyšší verze. Splněný
Specifický cíl 3: Udržuj integritu kontrolních bodů Přestože k jednotlivým konfiguračním dokumentům mají přístup téměř všichni zaměstnanci, každý dokument má jasně dané, kdo schvaluje a přijímá změny v tomto dokumentu, což zajišťuje integritu těchto položek. V průběhu každého projektu jsou pravidelně prováděny audity, kdy se revidují přijaté změny, aby nedocházelo ke ztrátě konzistence. Obě specifické praktiky jsou tedy naplněny, tudíž je tento cíl také splněný. Splněný
5.2.2 Měření a analýza Generický cíl 2 Implementace každého nového projektu jsou v interním systému pro evidenci projektů, nových požadavků a chyb evidovány. O zavádění nových požadavků do systému se stará projektový manažér. Díky tomuto systému lze monitorovat práci členů týmu na projektu. Systém umožnuje generování statistik, přehledů jak za celý projekt, tak pro jednotlivé moduly či členy týmu. Splněný
Specifický cíl 1: Definuj cíle a aktivity měření Projektový manažér v rámci systému pro evidenci projektů definuje parametry, které jsou u těchto projektů sledovány. Výsledky sledování jsou systémem pravidelně generovány a výsledné dokumenty slouží jako podklady pro analýzu výkonu a efektivity celého vývojového týmu. Splněný
56
Specifický cíl 2: Zpracuj výsledky měření Jak je již uvedeno výše, výsledky měření jsou zpracovávány v podobě generovaných dokumentů, které obsahují popis, číselné i grafické znázornění výsledků. Tyto dokumenty slouží hlavně projektovému manažérovi pro lepší představu výkonnosti týmu a pro odhalení kritických míst vývoje. Splněný
5.2.3 Dohoda o vedení dodavatele Generický cíl 2 Smlouvy s dodavateli jsou spravovány ředitelem společnosti, který se podílí na jejich sepisování a definování. Je zodpovědný za jejich korektnost a úplnost. A je zároveň i zástupcem společnosti podepsaným pod těmito smlouvami. Stará se o to, aby nedošlo k výpadku dodávek dohodnutých produktů. Splněný
Specifický cíl 1: Vytvoř smlouvy s dodavateli Na základě potřeby externí dodávky nějaké konkrétní služby či produktu vybere ředitel vhodné kandidáty pro jejich dodání. Zhodnotí schopnosti a spolehlivosti těchto dodavatelů a vybere z nich nejvhodnějšího kandidáta. S tímto kandidátem dojedná podmínky smlouvy a v případě společné shody je tato smlouva podepsána. Splněný
Specifický cíl 2: Dodržení smluv s dodavateli Po dobu platnosti smluv jsou kontrolovány a zaznamenávány všechny dodávky, které na základě těchto smluv vznikly. O tuto činnosti se dělí ředitel společnosti a jeho asistentka. Tito dva dohlíží na to, aby byly tyto smlouvy z obou stran dodržovány a naplněny v plném znění.
57
Dodávané produkty jsou poté skrze asistentku, HW specialisty a další pracovníky distribuovány mezi zaměstnance. V případě outsourcovaných pracovníků řídí dodávky jejich služeb vedoucí příslušného oddělení, které jejich služby využívá. Smlouvy s externími pracovníky spravuje opět ředitel a jeho asistentka. Splněný
5.2.4 Plánování projektu Generický cíl 2 Součástí každé nabídky na implementaci nového projektu a analytického projetu je projektový plán, který vytváří projektový manažér. Procesy této procesní oblasti jsou plánované a řízené zodpovědnými osobami. Projektový plán obsahuje nejen časový plán, ale jasně stanovuje závazky projektu, požadavky na projekt. Identifikuje rizika, která ohrožují plynulý běh projektu. Splněný
Specifický cíl 1: Odhadni parametry projektového plánu Vytvoření každého projektového plánu přechází analýzy a odhady, které provádí projektový manažér. Pro každý složitější projekt vytváří PM hierarchickou strukturu prací (WBS - Work Breakdown Structure). PM ve spolupráci s hlavním analytikem odhadují objem práce a finanční náklady na projekt. Splněný
Specifický cíl 2: Vytvoř projektový plán Spolupráce projektového manažéra a hlavního analytika pokračuje i v dalším průběhu tvorby projektového plánu. Stanovují potřebný rozpočet projektu a časový plán. Definují jednotlivé fáze projektu, včetně odhalení rizik, které se
58
v průběhu fází mohou vyskytnout. Vytvořený projektový plán dále definuje účastníky a role v rámci projektu. Jsou zde popsány i potřebné schopnosti a znalosti projektového týmu. V neposlední řadě tento dokument popisuje potřební zdroje a data potřebné pro úspěšné dokončení projektu. Splněný
Specifický cíl 3: Zjisti a udržuj závazky k plánu Po vytvoření projektového plánu projektový manažér provádí analýzu nutných závazků řešitelů a účastníků projektu. Ověří, zdali jsou všichni schopní dostát svých závazků a zda jsou schopni poskytnout potřebné zdroje. S účastníky projektu sepíše závazky, které z jejich účasti na projektu plynou. Splněný
5.2.5 Sledování a řízení projektů Generický cíl 1 Všechny procesy, které spadají do této procesní oblasti, jsou projektovým manažérem řádně plánované a dokumentované. Každý proces má jasně definované role a odpovědnosti a jeho vstupy a výstupy jsou sledované a podléhají kontrole. Splněný
Specifický cíl 1: Sleduj běh projektu proti projektovému plánu Projektový manažér v průběhu celého běhu projektu sleduje, jak je dodržován časový plán projektů. Slouží mu k tomu nejen výstupy ze systému pro správu projektů, ale i pravidelné schůzky s vedoucími jednotlivých oddělení, kde jsou diskutovány dosavadní výsledky projektu. V rámci monitoringu procesu PM sleduje rizika, datové výstupy a vývoj zapojení jednotlivých účastníků
59
projektu. Veškeré výsledky sledování porovnává s původním projektovým plánem a analytickým projektem. Splněný
Specifický cíl 2: Řiď korigující akce až do skončení projektu Na základě analýzy výsledků sledování zmíněných ve specifickém cíli 1, projektový manažér navrhuje korekce běhů projektu oproti původnímu plánu. Řídí začlenění těchto změn do běhu projektu. Tyto korekce provádí od počátku projektu až do jeho skončení. Splněný
5.2.6 Správa požadavků Generický cíl 2 Procesy v této procesní oblasti jsou plánované, mají jasně definovány role a odpovědnosti, mají přiřazeny konkrétní zdroje a využívají schopné odborníky. Z těchto faktů vyplývá, že je tento generický cíl splněný. Splněný
Specifický cíl 1: Spravuj požadavky V průběhu výběrového řízení, vytváření nabídky i analytického projektu je dbáno na jasnou, srozumitelnou a přehlednou specifikaci požadavků. Na této činnosti se podílí hlavní analytik, projektový manažér, ředitel a technický ředitel. Projektový manažér sleduje vývoj projektu a monitoruje změny požadavků, analyzuje je. Dále kontroluje, aby se samotná práce na projektu neodchýlila od naplnění stanovených požadavků. Výstupem tohoto procesu jsou změny projektového plánu v důsledku změn požadavků. Splněný
60
5.2.7 Zajištění kvality procesu a produktu Generický cíl 2 Vzhledem k neexistenci procesů, které by hodnotily kvalitu procesů společnosti, nemůže být naplněn druhý generický cíl. V této společnosti nedochází k auditům, které by hodnotily procesy. K jediným optimalizacím procesů dochází na popud některého z pracovníků. Toto ale často vede k emotivním debatám, které často ani nemají věcný závěr a přínos. Z důvodů výše uvedených nesplňuje procesní model tento generický cíl. Nesplněný Vzhledem k neexistenci procesů této procesní oblasti by byla analýza jejích specifických cílů bezpředmětná.
5.3 Závěr hodnocení Míru splnění jednotlivých praktik jsem evidoval pomocí formuláře [19], který jsem převzal z webu společnosti ProcessLabs. Graf znázorňující míru splnění 2. stupně vyspělosti procesního modelu, který byl vygenerován právě pomocí tohoto formuláře, naleznete v Příloze A. Celý formulář naleznete ve formátu XLSM na CD přiloženém k této práci. Prvních 6 procesních oblastí 2. stupně vyspělosti modelu je naplněno, jelikož jsou splněny všechny jejich generické a specifické cíle. Poslední procesní oblast Zajištění kvality procesu a produktu bohužel naplněna není, jelikož v této společnosti prakticky neexistují procesy, které by umožňovaly objektivně hodnotit a optimalizovat firemní procesy. Z tohoto závěru plyne, že ač těsně tak procesní model nedosahuje 2. stupně vyspělosti procesního modelu dle CMMI-DEV 1.3.
61
6 Optimalizace Tato kapitola stručně nastiňuje směry, kterými by se společnost mohla vydat, pokud by chtěla provést optimalizaci svých procesů. Tyto optimalizace by byly prováděny projektovým manažerem za podpory vedení společnosti.
6.1 Dosažení 2. stupně vyspělosti Hlavním cílem vedení společnosti by mělo být dosažení 2. stupně vyspělosti procesního modelu dle standardu CMMI-DEV. Na základě hodnocení v přechozí kapitole je nutné splnit poslední z procesních oblastí a to Zajištění kvality procesu a produktu. Je nutné zavést proces, který by naplňoval specifické a generické cíle této oblasti. Specifické cíle této oblasti jsou:
Objektivně ohodnoť procesy a produkty
Poskytni objektivní pohled na chyby
Zjednodušeně by výstupem procesu mělo být objektivní hodnocení procesů a produktů. Zjištěné nedostatky by měly být diskutovány vedoucími pracovníky a závěry se měly promítnout do procesů společnosti. Druhou variantou je tento proces převést na externí firmu, která provádí audity procesní a produktové kvality. Výhodou tohoto řešení je zajištění opravdové objektivity, jelikož auditoři externí firmy nemají žádné emoční vazby na zaměstnance společnosti a tudíž nemají tendence k uchýlení se k subjektivnímu hodnocení. Jakmile bude dosaženo 2. stupně vyspělosti, bude možné přejít k přípravám na dosažení 3. stupně vyspělosti.
62
6.2 Dosažení 3. stupně vyspělosti Pro dosažení 3. stupně vyspělosti modelu je nutné splnit všech jedenáct procesních oblastí toho stupně. Hlavní podmínkou je pro všechny procesy procesního modelu vytvořit standardizované procesy, ale pro každý nový projekt mohly být použity tyto standardní procesy. Dále bude nutné nasadit například procesy spojené zajišťující:
definování procesů
kontinuální odhalování slabých stránek procesů a jejich optimalizaci
řízené školení zaměstnanců
identifikaci alternativních řešení
validaci produktů
verifikaci produktů
Nasazení těchto projektů bude vyžadovat delší úsilí a může trvat poměrně dlouhý časový úsek. Každopádně cílem každé společnosti by mělo být vyvíjet se a zdokonalovat.
63
7 Závěr Cílem mojí diplomové práce bylo provedení procesní analýzy reálné IT firmy a následné hodnocení vyspělosti procesního modelu dle CMMI. Práce rovněž měla čtenáře seznámit s problematikou řízení firem a procesního řízení jako takového. V neposlední řadě měla práce ve stručnosti nastínit, jakým způsobem by bylo možné optimalizovat procesní model analyzované firmy. V průběhu procesní analýzy firmy jsem identifikoval všechny hlavní firemní procesy a i několik dalších podpůrných procesů. Tyto procesy jsem popsal a identifikoval jsem role a odpovědnosti, které v nich figurují. Hlavní z těchto procesů jsem pro vyšší vypovídací hodnotu namodeloval za pomocí notace BPMN 2.0. Hodnocení vyspělosti modelu jsem provedl za pomoci metodiky SCAMPI, která je součástí CMMI modelu. K mému překvapení procesní model nedosáhl ani 2. stupně vyspělosti, protože nesplnil jednu procesní oblast, která se týká kontroly kvality procesů a produktů. V závěru práce jsem stručně naznačil, jaké optimalizace procesního modelu by bylo potřeba provést, aby se zvedl stupeň vyspělosti této firmy. Klíčem k pozitivnímu vývoji každé procesně řízené firmy je kontinuální optimalizace, touto cestou může firma dosáhnout maximální efektivity řešení svých projektů. Procesní analýza a hodnocení vyspělosti procesního modelu jsou dobrým začátkem na této dlouhé cestě. Pokud vedení analyzované firmy projeví zájem, dala by se tato práce použít jako odrazový můstek pro detailnější analýzu procesů firmy. Zároveň by na základě hodnocení procesního modelu a navržených optimalizací mohl být vytvořen detailní návrh optimalizací pro dosažení vyšší vyspělosti jejího procesního modelu.
64
Literatura [1]. PROCHÁZKA, Jaroslav. Procesní řízení realizace projektů. Ostrava : Ostravská univerzita, 2006. [2]. PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK Guide) - Fourth edition. Pennsylvania : PMI, 2008. ISBN 978-1-933890-51-7. [3]. ISO. Quality management systems - Guidelines for quality management in projects. [Online] ISO, 2003. http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csn umber=36643. [4]. KOMISE EVROPSKÝCH SPOLEČENSTVÍ. Nařízení Komise (ES) č. 800/2008. Lucemburk : Úřad pro publikace Evropské unie (Publications Office of the European Union), 2008. [5]. STÝBLO, Jiří. Outsourcing a outplacement: vyčleňování činností a uvolňování zaměstnanců. Praha : ASPI, 2005. str. 114. ISBN 80-7357-094-7. [6]. Přispěvatelé Wikipedie. Outsourcing. [Online] Wikipedie: Otevřená encyklopedie, 2013. http://cs.wikipedia.org/wiki/Outsourcing. [7]. Harrington, H. James, Esseling, K. C. a Nimwegen, Van. Business Process Improvement Workbook. USA : McGraw Hill Professional, 1997. ISBN 9780070267794. [8]. Hammer, M., Champy, J. Reengineering the Corporation : A Manifesto for Business Revolution. New York : HarperCollins Publishers, 2003. ISBN 0060559535. [9]. Hollingsworth, David. Workflow Management Coalition The Workflow Reference Model. [Online] 19. ledna 1995. http://www.wfmc.org/standards/docs/tc003v11.pdf. [10]. Šmída, Filip Ing. Zavádění a rozvoj procesního řízení ve firmě. Praha : Grada Publishing, 2007. ISBN 978-80-247-1679-4. [11]. LBMS. Modelování procesů v BPMN. [Online] 2012. http://www.lbms.cz/Kurzy/popis/modelovani-procesu-v-bpmn.htm. [12]. OMG. Business Process Model and Notation (BPMN). [Online] 3. ledna 2011. http://www.omg.org/spec/BPMN/2.0/PDF.
65
[13]. Přispěvatelé Wikipedie. Business Process Model and Notation. [Online] Wikipedie: Otevřená encyklopedie, 2013. http://cs.wikipedia.org/w/index.php?title=Business_Process_Model_and_N otation&oldid=10263156. [14]. —. CMMI. [Online] Wikipedie: Otevřená encyklopedie, 2013. http://cs.wikipedia.org/wiki/CMMI. [15]. CMMI Product team. CMMI®for Development, Version 1.3. [Online] Carnegie Mellon University, 2010. http://www.sei.cmu.edu/reports/10tr033.pdf. [16]. MSDN komunita. CMMI zásady a hodnoty. [Online] Microsoft, Leden 2012. http://msdn.microsoft.com/cscz/library/hh765978.aspx#BKMK_CMMIsimple. [17]. PDQM. CMMI - FAQ (Časté otázky). [Online] PDQM, 2013. http://www.pdqm.cz/Blog/CMMI-FAQ.html#CMMI-ISO15504. [18]. BusinessInfo.cz. Typy organizačních struktur a jejich členění. BusinessInfo.cz. [Online] 2010. http://www.businessinfo.cz/cs/clanky/typyorganizacnich-struktur-cleneni-2840.html#!&chapter=4. [19]. processlabs GmbH. PIIDs for CMMI-DEV v1.3. [Online] processlabs GmbH, 2012. http://www.processlabs.de/downloads/category/2-cmmi-devpiid.html?download=4%3Acmmi-dev-piid-2007. [20]. Přispěvatelé Wikipedie. Správa dokumentů. [Online] Wikipedie: otevřená encyklopedie, 2013. http://cs.wikipedia.org/wiki/Spr%C3%A1va_dokument%C5%AF.
66
Příloha A CMMI Maturity Level 2 Compliance 100% 90%
% Implementation
80% 70% 60% 50% 40% 30% 20% 10% 0%
L2 Total, Process Areas (PAs) Obrázek A-1 Graf znázorňující míru splnění 2. stupně vyspělosti [19]
67
Příloha B Obsah CD K této diplomové práci je přiloženo CD, které obsahuje:
Elektronickou verzi textu práce
Zdrojové soubory modelů procesů pro program Bizagi Process Modeler
Bitmapové obrázky jednotlivých procesů
Formulář pro evidenci vyspělosti modelu s vyplněnými procesními oblastmi pro 2. Stupeň vyspělosti.
68
