Komponentový systém Personalistika Autor: Milan Mišovič, PEF, Ústav informatiky, Mendelova univerzita v Brně

Transkript

1 Komponentový systém Personalistika Autor: Milan Mišovič, PEF, Ústav informatiky, Mendelova univerzita v Brně -1-

2 Základy podnikové personalistiky popis Úvod Jednou z prvořadých povinností každého podniku je řízení lidských zdrojů (HRM Human Resource Management). Rozsah procesů v této oblasti je rozdílný nejen u malých, středních a velkých podniků, ale rovněž u různých typů organizací. Vlastní komputerizace těchto procesů je obvykle součástí ERP řešení typu all-in-one, ale setkáváme se rovněž s velmi propracovaným řešením kategorie best-of-breed. Obecně o personalistice Jak jsme již naznačili, je řízení lidských zdrojů na teritoriu ČR velmi pestré. Např. malé a střední podniky obchodně výrobního charakteru si často vystačí jen s komputerizací jednoduché personální evidence, základního zpracování mezd (případně doplněnou propočtem služebních cest). Dále je používáno sledování absence, docházky a výběrová řízení. Na druhé straně, podniky, které systematickou práci s lidskými zdroji považují za nezbytnou aktivitu pro udržení své konkurenceschopnosti, přechází na nejvyšší stupeň komputerizace všech personálních aktivit. Takové podniky si mohou vybrat poměrně hluboká řešení zabudovaná v ERP kategorie all-in-one (např. SAP, QI, Helios, ), nebo ve specifické kategorii best-of-breed, zaměřené jen na personalistiku. Někteří výrobci software pro řízení lidských zdrojů, specialisté na tuto problematiku, poskytují moduly, které jsou integrovatelné do vybraných ERP řešení a garantovány zastřešujícím implementačním partnerem. Takto poskytují zmíněné moduly implementačnímu partnerovi firmy K2, Elanor a Kvasar. Následující obrázek dokumentuje právě třináct relevantních skupin-podmnožin procesů v personalistice, které působí na první pohled odděleně, ale to je velký omyl. Hlavním rysem -2-

3 je společný život všech skupin ve vzájemné působnosti. Stačí připomenout vazbu Vzdělání-Výkonnost-Kariérní růst. Zmíněné skupiny jsou začleněny do tří kategorií: Talent Management. Personální řízení zaměstnanců. Jádro HR informačního systému. Je pochopitelné, že u vyspělého podniku jsou všechny skupiny a jednotlivé procesy důkladně popsány v podnikových legislativních dokumentech a je stanovena odpovědnost za jejich řízení. Je zřejmé, že systematická personální práce je pomalu a plánovitě budována a jsou poznatky z praxe, že její naplnění přináší podniku vysokou loajalitu zaměstnanců a jejich konsensus se strategickým cílem podniku Obrázek 1: Skupiny procesů personalistiky (převzato z [SodKl10]) a modifikováno). Skupiny fungují jako subjekty-podsystémy. 1, 6, 7, 10, 12, a 13 budou použity pro malý podnik Dodávka ERP ve formě kategorii best-of-breed je schopna pokrýt i vysoce specifické požadavky na řízení lidských zdrojů. Na tento způsob se specializuje zejména firma VEMA. Takto vzniklá dodávka se často označuje jako HRIS (Human Resource Information System). Mezi důležité uživatele best-of-breed řešení personalistiky patří zejména sektor veřejné zprávy (státní úřady), příspěvkové a rozpočtové organizace. -3-

4 Na rozdíl od Obrázku 1, další Obrázek 2 ilustruje zase HRM (Human Resource Management) jako součást ERP řešení s velmi širokým podnikovým kontextem. Personalistika je porůznu chápána nejen v softwarových firmách, ale i v samotných organizacích. Je dobré si uvést co obecné členění personalistiky, které jsme uvedli, představuje, a proto alespoň stručně jednotlivé skupiny popíšeme. Předem si ale musíme uvědomit podstatu dvou obecných přístupů k personalistice. Personalistika v užším pojetí... zahrnuje evidenci osobních údajů zaměstnanců a zpracování pracovněprávních dokumentů. Dokumenty jsou upravovány v souladu s platnou podnikovou a celostátní legislativou. Personalistika v širším pojetí... rozšiřuje užší pojetí o agendu pro ochranu zdraví při práci, o systemizaci pracovních míst, o vzdělávání zaměstnanců a řízení karierního růstu, o hodnocení zaměstnanců a sociální programy a o řízení uchazečů o práci a výběrového řízení. Na první pohled se zdají mnohé ze skupin, které jsou uvedeny v Obrázku 1, velmi jednoduché. Některé z nich mají ovšem jistá specifika, na které se zaměříme. Výběrová řízení Organizace výběrových řízení může být specifická, ovšem důležité jsou potřebné formuláře: Program výběrového řízení. Veřejné zpřístupnění řízení. Dotazník uchazeče. Strukturovaný životopis. Všechny zmíněné formuláře mají buď podnikovou strukturu, anebo se sledují společné oborové, resp. celostátní formuláře. Mezi IT nástroji, které komputerizují elementární personální práci, by měla být celopodniková aplikace (např. InfoPath od firmy Microsoft) pro produkci zmíněných formulářů. Zpracování mezd Standardní řešení ERP kategorie all-in-one umí zpracovávat všechny typy mezd, včetně výpočtu daní a odvodů sociálního a zdravotnického pojištění. Výpočet probíhá buď jednotlivě, nebo po skupinách zaměstnanců, kteří mají stejné parametry výpočtu mzdy. Je zde rovněž podpora měsíčních uzávěrek a tisku celé řady dokumentů, např. přehled zaplaceného sociálního pojištění, výkaz dávek nemocenského, soupis srážek ze mzdy. A konečně, je možný výpis celoročních příjmů zaměstnance, odvedených dávek na dani, sociálního a zdravotního pojištění a mnoha dalších dokumentů. Často se vyskytuje komputerizace nadstandardního řešení mzdové agendy. Patří sem tzv. zpětné přepočty (pozdě dodané podklady dovolená, neschopenka, narození dítěte, ). -4-

5 Přepočty sice probíhají do minulosti, ale promítnou se do přítomnosti, včetně správných odvodů. Plánování pracovních míst Ačkoliv se to nezdá důležité, opak je pravdou. Důkladný popis pracovního místa je předpokladem pro pozdější možná hodnocení zaměstnance prostřednictvím měření jeho výkonnosti. Jde tedy o popis činnosti, definice požadavků na vlastnosti, zkušenosti a vzdělání zaměstnance, který má danou pozici zastávat. Propojení s personální evidencí je nezbytné. Struktura popisu může umožnit automatické posuzování případných uchazečů. Neméně je důležitá systemizace pracovních míst a jejich propojení s organizační strukturou podniku. Nejde jen o vizualizaci, ale o realizaci celé řady zajímavých operací. Vzdělávání zaměstnanců Tuto personální aktivitu nelze podceňovat. Je přímo důležité sledovat vzdělání zaměstnanců, pomáhat v jeho doplnění a na jeho základě hýbat se zaměstnaneckou šachovnicí podniku. Podnikové vzdělávání je vysoce automatizováno využitím velmi sofistikovaných elektronických výukových programů a e-learningových opor. Podobným způsobem bychom mohli sledovat obsah všech zbývajících skupin personálních procesů. Mnohé z nich prodiskutujeme ve cvičeních s ilustrací na dvou ERP systémech Qi a K2. Personální evidence Pochopitelně, bez dokonalé personální evidence není možno komplexně sledovat hodnoty všech atributů, které systém HRM požaduje sledovat. Personální evidence je realizována velmi flexibilní tabulkou s mnoha užitečnými operacemi nad řádky a sloupci. Velké množství sledovaných atributů žádá specifické způsoby jejich vedení, a proto se setkáváme s velkým množstvím podřízených podrobnějších tabulek. Řízení výkonnosti Následující Obrázek 2 ilustruje systémový přístup k řešení pracovní výkonnosti zaměstnanců podniku. Jestliže jsou komputerizovány vztahy mezi komponenty systému řízení výkonnosti, potom to vede k následujícím přínosům: 1. Všichni zaměstnanci chápou požadavky kladené na jejich pracovní pozice. 2. Jde rovněž o možnost spravedlivého odměňování zaměstnanců. 3. Proces hodnocení je kratší a administrativně jednodušší. 4. Proces je snadno propojitelný s ročním plánem podniku, s karierovým růstem a procesem identifikace personálních rezerv. -5-

6 Obrázek 2: Systém řízení výkonnosti (převzato z [ToKu10]) Pozoruhodné pro personalistiku je silná souvislost mnoha procesů z různých skupin a jejich odraz v personální evidenci. Tuto situaci ilustruje následující obrázek. Rovněž situaci odráží procesní modelování pro jednotlivé skupina procesů-subjekty-procesní podsystémy. Obrázek 3: HRM jako součást řešení ERP (převzato z [SodKl10]) -6-

7 Zde vidíme několik procesních vláken, jejichž data jsou, jako požadované atributy, ukládány do personální evidence a vzájemně využívány. Personální evidence je informatickou základnou systému HRM. Teď se budeme chvíli věnovat tzv. procesnímu modelování a výsledná procesní schémata by měla definovat procesní architekturu (nejen strukturu, ale široké vazby procesů na podnikové okolí) domény HRM. Proto jsou vedle základních jednotek zmíněných procesních schémat, jimiž jsou procesy, další jednotky z podnikového prostředí: podnikové skupiny procesů-procesní modulyprocesní podsystému, podniková data, organizační jednotky, manažerské skupiny a jednotlivci, procesní cíle, Důležité: Proč předkládáme procesní modelování? Odpověď je jednoduchá. Jednak jednoznačně oddělujeme hmotu podniku od informace, která ji reprezentuje, pro abstraktní zpracování počítačem (přesněji jeho softwarem). Jestliže máme vhodná procesní schémata se širokým rozhledem vazby procesů mezi sebou a na jednotky podnikového prostředí (např. takovými jsou metody ARIS, Eriksson-Penker a další ), můžeme vhodně mapovat procesy do softwarových komponent. Toto zdůvodnění využijeme zejména v metamodelu Aplikace vývoje komponentového systému v objektové metodice, který bude použit pro zvýraznění dominance komponentové architektury v objektové metodice. Procesní architektura domény HRM Je pochopitelné, že základem personalistiky je podsystém Personální evidence zaměstnanců, ve kterém se odrazí informační výsledky všech zbývajících procesních podsystémů. Předpokládejme jen malý výrobně obchodní podnik, kterému postačí následující procesní podsystémy personalistiky: Personální evidence zaměstnanců. Základní zpracování mezd. Zpracování absence a docházky. Výběrová řízení. Plánování pracovních míst. Personální samoobsluha. Na základě tohoto předpokladu můžeme nakreslit následující hrubé výchozí procesní schéma pro procesní architekturu, tj. hrubý funkční - procesní schéma domény Personalistika. Jednotlivými prvky schématu jsou procesní podsystémy, které vzešli z původních procesních množin (1, 6, 7, 10, 12, a 13) z obrázku 1. Základní zpracování mezd Zpracování absence a docházky Výběrová řízení Personální samoobsluha Personální evidence zaměstnanců Plánování pracovních míst Obrázek 4: Výchozí procesní schéma pro logickou architekturu -7-

8 <<Podsystém>> Personální samoobsluha a průkazů zbraní 8 <<využívá>> <<využívá>> Základní zpracování mezd a průkazů zbraní <<využívá>> <<využívá>> 7 <<Podsystém>> <<Podsystém>> Personální evidence zaměstnanců <<využívá>> <<využívá>> 6 <<využívá>> <<Podsystém>> Zpracování absence a docházky 4 <<využívá>> 3 <<Podsystém>> Plánování pracovních míst <<Podsystém>> Výběrová řízení <<využívá>> Obrázek 5: Schéma hrubé funkční závislosti podsystémů (pouze relace <<využívá>>) Po prostudování vzájemných souvislostí procesních podsystémů z obrázku 4, tj. subjektůpodsystémů, jsme sestavili Schéma hrubé funkční závislosti v problémové doméně s použitím jediné závislostní relace <<využívá>>. Jediná relace proto, že chceme závislostní situaci mít transparentní. Stručný popis závislostí: 1. Mzdy a docházka silně souvisí. 2. Docházka a absence bude pamatována v Personální evidenci zaměstnanců. 3. Jsou absence a docházky v souladu s informacemi ve výběrovém řízení se zaměstnancem (zatajená vážná nemoc, )? 4. Nelze dělat výběrová řízení na neplánovaná pracovní místa. 5. Výběrová řízení jsou ukládána v Personální evidenci. 6. Každý zaměstnanec je napojen na plánované pracovní místo. 7. Základní údaje, které se potřebují pro mzdu, jsou v Personální evidenci. 8. Některé data mohou spravovat zaměstnanci přímo. Pro celou doménu HRM můžeme sestavit kolekci procesních diagramů, které dokumentují zejména život podsystémů, každého jako procesního celku a jejich vazby a vazby na okolí podniku. Název každého podsystému považujme za nejvyšší proces a potom můžeme adresovat závislost dvou subjektů přes jejich podprocesy. Po naší redukci na malý podnik, je celkem v 1. vrstvě 5 procesních podsystémů (vynechán podsystém Samoobsluha). Procesní diagram 1. vrstvy je na obrázku 6. Jeden z těchto podsystémů, přesněji Výběrové řízení je rozvinut do podprocesů 2. vrstvy na obrázku 7. Rozvoj do 3. vrstvy teď není uvažován. Jak tyto procesy-procesní podsystémy navzájem žijí, můžeme dokumentovat např. pomocí procesního diagramu metodou Eriksson-Penker. Výběr této metody má několik relevantních důvodů. Např., že je veřejně přístupná v (Erik Pen, 2011), je rozšířením UML, je jednodušší než některé další metody podobného zaměření (procesy a široké podnikové okolí). Tento diagram bude mít rozhodující vliv na vznik dílčích komponent domény a každého podsystému. -8-

9 V procesním modelování můžeme ovšem pokračovat dále. Pro každý podsystém v schématu na obrázku 5 můžeme sestrojit procesní diagramy druhé vrstvy. Takových procesních diagramů 2. vrstvy je právě tolik, kolik je podřízeních procesů (podprocesů) ve vybraném podsystému 1. vrstvy. A kolik bude diagramů 3. vrstvy a kolik bude procesů v podsystému celkem? To vše získáme až po provedení všech rozkladů. Proveďme ukázku rozkladu jen pro podsystém Výběrová řízení. Pro tento podsystém považujeme za relevantní následující procesy 2. vrstvy: Výběrová řízení 1. Analýza stavu využití volného pracovního místa 2. Tvorba nabídky volného pracovního místa 3. Získávání pracovníků 4. Tvorba dokumentů pro uchazeče 5. Výběr uchazečů 6. Přijímání nového pracovníka Podsystém Výběrové řízení je rozvinut do podprocesů 2. vrstvy na obrázku 7. Diagramy na obrázcích 5, 6 a 7 ilustrují jen část Procesní architektury problémové domény HRM. -9-

10 HRM Obrázek 6: Procesní diagram pro 1. vrstvu procesních podsystémů domény HRM, s rozklady procesních podsystémů na nižší procesy 2. vrstvy -10-

11 VÝBĚROVÉ ŘÍZENÍ Obrázek 7: Procesní diagram 2. vrstvy pro podsystém Výběrová řízení. Tento podsystém má 6 dílčích procesů -11-

12 Logická architektura Jaké další prvky logické architektury musíme k předchozímu schématu na obrázku 5 (Schéma hrubé závislosti podsystémů Personalistiky) ještě přidat, abychom dostali Schéma logické architektury? Jistě to budou prvky, které předchozí schéma oživí a přiblíží více k realitě funkcionality cílového software. Např.: Báze dat, která bude použita v podsystému Personální evidence zaměstnanců. Podsystém správy s klienty - management Personálního oddělení. Podsystém výstupních sestav a statistiky. Podsystém úpravy báze dat, tj. změny informace v Personální evidenci zaměstnanců. Klientský počítač. Správa výstupních sestav a statistiky <<Podsystém>> Personální samoobsluha a průkazů zbraní <<Podsystém>> Základní zpracování mezd a průkazů zbraní <<Podsystém>> Personální evidence zaměstnanců <<Podsystém>> Zpracování absence a docházky <<Podsystém>> <<Podsystém>> Výběrová řízení Správa a komunikace s klienty BD Plánování pracovních míst Obrázek 8: Schéma logické architektury pro doménu Personalistika. Pochopitelně, můžeme přidávat další prvky logické architektury. Pro náš případ je ale přidání dostatečné. Jakou funkcionalitu můžeme potom programátorovi pomocí přidaných prvků logické architektury předložit? Tady jsou její možnosti: 1. Systém potřebuje centrální řízení komunikace s klienty, které umožní nejen autentizaci a autorizaci, ale i organizaci plnění jejich požadavků a prověřování práv, povinností a kompetencí na data, procesy, Klienti mohou spouštět jednotlivé podsystémy. 3. Veškerá informace podsystémů je uložena v bázi dat. 4. Podsystém Správa výstupních sestav a statistiky bude organizovat výstup podle připravených výstupních šablon a nebude využívat ostatní podsystémy přímo, ale jen jejich data z báze dat-bd. Statistika v HRM je nutná téměř pro každý podnik. -12-

13 Fáze ZAHÁJENÍ Plánování projektu (iterace), kritická místa Tento pracovní postup zde nebudeme realizovat do velké hloubky, protože souvisí s ustanovením softwarového projektu. Z tzv. PRVOTNÍCH PŘÍPADŮ PŘÍSTUPU fáze ZAHÁJENÍ ovšem realizujeme jen předznačené: Plánování projektu (iterace), kritická místa Kontextová analýza problémové domény. Analýza klientů cílového software. Prvotní přístup k architektuře cílového software. Podmínky proveditelnosti. Obchodní případ. Prvotní přístup k využití vývojového prostředí. Procesní architektura domény, modely procesních podsystémů. Více o cílovém software. Prvotní přístup k prostředí nasazení. Kontextová analýza Nakreslíme-li HRM malého podniku jako černou skříňku a zaměříme se na okolí týkající se klientů a organizačních jednotek, potom můžeme nakreslit následující hrubé smíšené kontextové schéma. Doména HRM je specifickou doménou s malým počtem prvků v okolí, je to dáno její povahou. Zaměstnanci Personál revize Pracovníci personálního oddělení Vedoucí organizačních jednotek HRM Majitelé podniku Administrátoři systému Finanční skupina Obrázek 9: Hrubé kontextové schéma domény HRM malého podniku. Černou skříňku můžeme ovšem značně zjemnit, tj. rozložíme kontext klientů přibližně na jednotlivé skupiny procesních podsystémů domény HRM malého podniku. Tak se zvýrazní fragment datové integrity malého podniku daný doménou HRM. Co je datová a procesní podniková integrita? Názory jsou různé, jeden je dolů v poznámce. -13-

14 Prac. Finanční skupiny Základní zpracování platů Plánování pracovních míst Personální samoobsluha HRM malého podniku Zpracování docházky a absence Správa a komunikace s klienty Personální evidence zaměstnanců Pracovníci Per. oddělení, ved. organiz. jednotek Administrátoři, prac. Pers. oddělení, vedoucí organizačních jednotek, majitelé Pracovníci Pers. oddělení Ved. Pers. oddělení, majitelé, prac. Pers. oddělení Obrázek 10: Jemnější kontextové schéma domény HRM. Analýza klientů cílového software Abychom provedli hlubší analýzu poslání jednotlivých typů klientů, museli bychom problematiku práv, povinností a kompetencí zaměstnanců (na procesy, dokumenty, jiná podniková data, ) vyřešit předem v souvislosti se zastávanými zaměstnaneckými pozicemi a uplatnit na klienty. To jsme ovšem neudělali, a proto budou práva, povinnosti a kompetence klientů popisovány jen hrubě. Co jsou práva, povinnosti a kompetence k podnikovým datům a procesům. Jedno z pojetí je dáno v Př--Část VI. PŘÍLOHA 4 Práva kompetence a povinnosti zaměstnanců. Zaměstnanci Mají práva, některá data jen číst, mají kompetence a povinnosti, měnit a udržovat integritu tzv. volných dat s realitou domény. Jsou to většinou data, která se nezpracovávají relevantními podnikovými procesy. Někdy jsme schopni spíše říci, která data takovými nemohou býti, než přímo vyjmenovat volná data pro personální samoobsluhu. Personální revize Práva, kompetence a povinnosti tohoto typu klienta mohou být co do přístupu k datům (číst, ale neměnit) značně široké. Je to dáno funkcionálním posláním tohoto klienta. Klient má výhradní zodpovědnost za výsledná data revizí (čtení, tvorba, modifikace revizních zpráv) a může čtení zpřístupnit jiným typům klientů (majitel, ved. organizačních jednotek, ) Pracovníci Personálního oddělení Jejich práva, kompetence a povinnosti se týkají zavádění personálních dat o zaměstnancích do IS podniku. To vše ovšem provádí na základě připravených, vyplněných a zaměstnanci -14-

15 podepsaných podnikových personálních dokumentů. Rozhodující je personální specifikace toho nebo onoho pracovníka. Majitelé podniku Mají spíše práva na široké čtení personálních dat, téměř žádné povinnosti je měnit, kompetence je obvykle přesněji vymezena. Administrátoři Řeší konfliktní situace v použití IS podniku všemi zbývajícími typy klientů a z toho plynou široká práva na čtení, modifikaci (za spolupráce s daným klientem). Vedoucí organizačních jednotek Mají práva číst data jen u svých podřízených, a to jen ty, které jsou personálního povahy. Nemají možnost je měnit a kompetence je silně omezená. Prvotní přístup k architektuře cílového software Informační infrastruktura malého podniku obsahuje postaru nejvýše jeden server a na něm zavěšené koncové počítače, řízené zakoupeným software (operační systém serveru, kancelářský balík Microsoft Office, IS podniku, ). IS podniku, který je vlastně cílovým software, se kvůli jeho vlastnostem (nerobustní - transparentní, těsně svázaný s procesy, přehledně koncipované podnikové služby pro zákazníky, ) vyplatí členit na komponenty, které se dají flexibilně modifikovat, vyměňovat, Komponenty jistě budou kompozitní a celý cílový software bude tvořen kolekcí komponent s jedinou nejvyšší komponentou se jménem Human Resources Management (HRM). Obecně bude tato komponenta složena z 13 dílčích - dceřiných komponent, ale pro malý podnik jen ze šesti. Každá dceřiná komponenta má specificky sestavené podnikové služby, které se mohou ještě dále členit do koncových komponent 2. vrstvy. Tyto koncové komponenty jsou na obálce ilustračního komponentového grafu. Tento graf vznikne tak, že za uzly považujeme komponenty a za hrany jejich propojení. Výsledný komponentový diagram pro malý podnik by potom měl pro 1. vrstvu pro celkem 6 fragmentů komponent, bývalé procesní podsystémy. Např. dále, komponenta Výběrové řízení má zase v druhé vrstvě 6 subkomponent. Druhá vrstva, podle hlubšího členění domény HRM, znamená další výrazný přírůstek komponent. Kvůli přijatelné transparentnost kolekce komponentových diagramů (od nejvyššího až k nejnižšímu) se doporučuje členění HRM maximálně jen na 3 vrstvy. Pro malý podnik jsme použili zatím jen dvě vrstvy. HRM Výběrové řízení vrstva 1. 6 fragmentů komponent, bývalé procesní podsystémy vrstva 2. další fragmenty komponent pro každý bývalý procesní podsystém vrstva 3. další fragmenty komponent pro každý podproces procesního podsystému Obrázek 11: Komponentový diagram domény HRM a jeho 3 vrstvy pro malý podnik. -15-

16 HRM vrstva 1. vrstva 2. vrstva 3. Obrázek 12: Ilustrační graf Komponentového diagramu domény HRM. Podmínky proveditelnosti záležitost projektu, neřešíme Obchodní případ (podnikatelské zhodnocení) záležitost projektu, neřešíme Prvotní přístup k využití vývojového prostředí Jistě je možno najít mnoho vývojových prostředí pro cílový software domény HRM malého podniku. Berme však ohled na plánovanou dynamickou komponentovou architekturu. Zde bychom mohli volit vývojové prostředí jazyka Java, nebo vývojové prostředí Visual Studio. Oba dva vývojové systémy jsou podporovány mohutným Framework systémem se vzorovým systémem správy dynamických komponent. Obě prostředí rovněž disponují progresivním způsobem práce s bází dat a realizací bazické architektury Klient-server. Vize o cílovém software bylo dostatečně naznačeno v Prvotním přístupu k architektuře cílového software Prvotní přístup k prostředí nasazení Cílový software, jehož relevantní vlastností by měla být jeho komponentová statická architektura, může být vyvíjen v jisté softwarové firmě na zakázku. Rozhodující pro nasazení cílového software je způsob jeho poskytnutí zákazníkovi, tj. malým podnikům ČR. Je několik možností: 1. Cílový software je malému podniku jednorázově prodán s celoživotní licencí. Vzhledem k možnostem informační infrastruktury zákazníka, je cílový software buď součástí IS, nebo figuruje samostatně, jako komponentový celek a mimo IS. Takový celek může být nainstalován na jednom ze serverů, nebo je rozložen na více serverů, což je dáno jeho fyzickým nasazením. Komponentový celek je statický, změny evokují novou instalaci. 2. Potřebné úpravy (modifikace, modernizace) software musí být s produkční firmou řešeno pomocí samostatných smluv. Cílový software je zákazníkovi poskytován v nájmu (podle nájemního modelu produkční firmy) a není na informační infrastruktuře zákazníka fyzicky nasazen. Všechny přístupy klientů jsou produkční firmou zabezpečeny. Produkční firma potom, v rámci nájmu, zohlední modernizační požadavky stávajících zákazníků. -16-

17 Návrhová architektura Na výsledku Návrhové architektury, kterým je Komponentový systém návrhové architektury, se podílí svou činností následující pracovní postupy (viz metamodel Aplikace vývoje komponentového systému do objektové metodiky, body: D, E, F, G, Část III. Komponentové systémy, kap. 6: 1. chování podsystémů domény, 2. mapování procesů/podsystémů do komponent, 3. propojení komponent. Komponentový systém pro 1. vrstvu: Komponentový systém je vytvářen jen pro malý obchodně výrobní podnik, tj. jen pro 6 podsystémů (Personální evidence zaměstnanců, Základní zpracování mezd, Zpracování absence a docházky, Výběrová řízení, Plánování pracovních míst, Personální samoobsluha), které pro správu jeho lidských zdrojů dostačují. Je charakteru kolekce dvou komponentových diagramů, pro 1. a 2. vrstvu. Sestrojme je postupně. Podsystémy bereme ze Schématu logické architektury (viz obrázek 8). Mapování podsystémů na komponenty je typu 1:1. podsystémy Správa výstupních sestav Správa a komunikace s klienty Základní zpracování mezd Zpracování absence a docházky Personální evidence zaměstnanců Výběrová jednání Plánování pracovních míst Personální samoobsluha BD mapování na komponenty Správa výstupních sestav Správa a komunikace s klienty Základní zpracování mezd Zpracování absence a docházky Personální evidence Výběrová jednání Plánování pracovních míst Personální samoobsluha BD Základní propojení komponent v komponentovém diagramu 1. vrstvy stanovíme pomocí následujících diagramů: 1. Chování podsystémů problémové domény (musíme to vytvořit pomocí pracovních postupů objektové metodiky z fází ZAHÁJENÍ a ROZPRACOVÁNÍ). 2. Schéma logické architektury (obrázek 8). 3. Procesní diagram domény (první vrstva, obrázek 6). Pochopitelně, pro každou tuto komponentu musíme stanovit, co vyžaduje od ostatních komponent a co pro ostatní komponenty dává k dispozici pro propojení. Tak najdeme tvar rozhraní. Dále připomínáme, že každá komponenta dědí interní návrhové chování podsystému, který byl na ni mapován. Chování podsystémů Chování podsystémů je postupně získáno: V pracovním postupu Požadavky: o vytvořením požadavků, stanovením případů užití a grafickou dokumentací všech souvisejících výsledků (Diagramy případů užití, Detailní tabulky případů užití a Aktivitní diagramy). -17-

18 V pracovním postupu Analýza případů užití: o Realizací případů užití pomocí analytických objektových tříd a grafická dokumentace (Diagramy analytických tříd a související Sekvenční diagramy, Stavové diagramy) V pracovním postupu Návrhová úprava: o Převedení analytických tříd do návrhové podoby (včetně jejich diagramů a Sekvenčních diagramů). Mapování procesů/podsystémů Management podniku navrhnul 1:1 (tedy jeden procesní podsystém = jedna komponenta), protože samotné procesní podsystémy jsou dostatečně velké služby podniku, tj. jsou to celky, o které má i jiný zákazník zájem. Mapování umožňuje vhodné poskládání podnikového IS z takto navržených komponent. Z tohoto rozhodnutí potom vychází základní diagram Komponentový systém pro 1. vrstvu. Základní propojení komponent Pochopitelně, diagram z obrázku 13 nebude obsahovat všechny interface a tedy i propojení komponent. Analýza této problematiky musí být v realitě velmi podrobná a neustále konzultovaná s managementem podniku. Management podniku má rovněž rozhodující slovo pro mapování procesů jednotlivých vrstev na komponenty, protože ví jaké komponenty a jejich služby zákazníkům nutno dodávat. Mluvíme proto ne o úplné kolekci komponentových diagramů, ale jen o jejich základě. <<Component>> Správa výstupních sestav <<Component>> Základní zpracování mezd <<Component>> Zpracování absence a docházky <<Component>> Personální samoobsluha <<Component>> Personální evidence zaměstnanců <<Component>> Výběrová řízení <<Component>> Správa a komunikace s klienty <<Component>> Plánování pracovních míst <<Component>> SŘBD BD Obrázek 13: Základní diagram Komponentový systém návrhové architektury první vrstvy (podsystémy) domény HRM. -18-

19 Diagram Komponentový systém 2. vrstvy pro podsystém Výběrové řízení získáme především z jeho procesního diagramu. Postup může být velmi jednoduchý, rozhodl tak management podniku, a spočívá na mapování procesů tohoto podsystému na komponenty 1:1 a určení jejich propojení. Komponenta Výběrové řízení je kompozitní a má 6 dílčích komponent. <<Component>> Výběrové řízení <<Component>> Analýza stavu využití volného pracovního místa << Component>> Tvorba nabídky volného pracovního místa << Component>> Získávání pracovníků << Component>> Tvorba dokumentace pro uchazeče a její doručení << Component>> Přijímání nového pracovníka << Component>> Výběr uchazeče Obrázek 14: Diagram Komponentový systém návrhové architektury pro podsystém Výběrová řízení (druhá vrstva) v malém podniku. Tvorba chování procesních podsystémů domény HRM Tvorba chování HRM je již u malého podniku poměrně namáhavá a rozsáhlá, protože pro malý podnik máme 6 procesních podsystémů, které mají vlastní procesy (např. víme, že Výběrové řízení jich má 6) a tyto jejich procesy jsou dále zjemněny. Když potřebné pracovní postupy objektové metodiky provedeme ilustrativně, jen pro procesní podsystém Výběrové řízení, tak se nedopustíme deformace problému. Vše provedené, použijeme později jako vzor pro ostatních 5 procesních podsystémů doména Personalistiky malého podniku. Zopakujme teď procesní diagramy 1. a 2. vrstvy. Třetí vrstvu, tj. zjemnění procesů procesního podsystému Výběrová řízení provedeme později. -19-

20 HRM Podsystém Podsystém Podsystém Podsystém Podsystém Obrázek 15: Procesní diagram pro 1. vrstvu procesů domény HRM. -20-

21 VÝBĚROVÉ ŘÍZENÍ Proces 2. vrstvy Proces 2. vrstvy Proces 2. vrstvy Proces 2. vrstvy Proces 2. vrstvy Proces 2. vrstvy Obrázek 16: Procesní diagram 2. vrstvy pro podsystém Výběrová řízení -21-

22 V dalším prozkoumáme chování jen procesního podsystému Výběrové řízení jako vzor pro ostatní procesní podsystémy malého podniku. Jeho procesy dále ještě zjemníme do 3. vrstvy (viz taxonomie požadavků). Prozkoumání povedeme podle nadpisů: pracovní postup Požadavky, Návrh případů užití, Diagramy případů užití, pracovní postup Analýza případů užití, a pracovní postup Návrh. Podsystém Výběrové řízení 1. Pracovní postup Požadavky Proveďme ukázku jen pro podsystém Výběrová řízení (na obrázku 15 je s červeným obrysem). Pro tento podsystém považujeme podle [Kou03] za relevantní následující nejnižší podprocesy 2. vrstvy: 1. Analýza stavu využití volného pracovního místa. 2. Tvorba nabídky volného pracovního místa. 3. Získávání pracovníků. 4. Tvorba dokumentů pro uchazeče. 5. Výběr uchazečů. 6. Přijímání nového pracovníka. Názvy procesů a jejich funkcionalita byly získány volným čtením v [Kou03]. Podsystém Výběrové řízení je rozvinut do podprocesů 2. vrstvy na obrázku 16. Obrázek 15 ilustruje snad nejvýznamnější vazby podsystému Výběrová řízení na ostatní procesní podsystémy HRM. Obrázek 16 již ilustruje vazby podprocesů, na které je Výběrové řízení rozloženo. Považujme všech šest podprocesů Výběrového řízení za požadavky tohoto podsystému. Popišme je alespoň stručně. 1.1 Taxonomie požadavků podsystému Výběrová řízení Za požadavky jsou považovány nejdříve procesy 2. vrstvy, viz obrázek 16. Funkční požadavky 2. vrstvy: Analýza stavu využití volného pracovního místa nezjemňováno Tvorba nabídky volného pracovního místa je rozložena do nejjemnějších požadavků 3. vrstvy: 1. Tvorba nabídky. 2. Tvorba požadavků na uchazeče. 3. Tvorba Přehledu progresu v zaměstnaneckém postupu. 4. Tvorba stručného popisu podniku. 5. Zveřejnění dalších skutečností. Získávání pracovníků nezjemňováno Tvorba dokumentů pro uchazeče je rozložena do nejjemnějších požadavků 3. vrstvy: zjemněno, nejsou uvedeny v obrázku Modifikace dokumentů pro uchazeče. zjemněno, nejsou uvedeny -22- v obrázku 16