2013

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

N

A

M

Í

R

KOMIX NOVINY 2012/2013 Vážení čtenáři, KOMIX byl založen v  září 1992 a v  době, kdy píši tento úvodník, dovršil 20 let svého působení na trhu IT. Ze skupinky programátorů, která založila softwarovou firmičku s  tím, že když se to nepodaří rozběhnout, nechají se zaměstnat těmi lepšími, se stala firma s více než 100 zaměstnanci. Za tu dobu se nám podařilo být u řady historických změn – vyprovázeli jsme stařičký mainframe na Generálním ředitelství cel do zaslouženého důchodu a postavili statistiku zahraničního obchodu na unixovém stroji od firmy IBM a s využitím databázového systému Informix. Pomáhali jsme napojovat celníky do Evropské Unie, naši republiku do Schengenu, byli jsme u začátků zdravotního pojištění v naší republice, u nových řidičáků, biometrických pasů, nových občanských průkazů, nového systému pro matriky, nemocenskou nebo sčítání obyvatel. Pomáhali jsme vytvořit logistický systém pro Ministerstvo obrany. Chtěl bych na tomto místě poděkovat společnostem ATOS, HP, IBM a STC, které nás jako svého partnera k  řadě zde zmíněných projektů přizvaly. V  komerčním sektoru jsme měli tu čest být třeba u budování mobilní sítě Eurotelu, náš první velký zátěžový test jsme dělali pro Český Telecom, když měnil verzi SAPu, vytvářeli jsme faktoringový systém pro ŠkoFIN, měli jsme řadu projektů pro pojišťovny a banky a zanechali jsme své stopy i v retailu, televizi NOVA a u řady dalších zákazníků.

lečnosti QlikTech, která stále na burze roste, v Gartnerových kvadrantech stoupá a zatím nepodlehla akvizičnímu lákání. IT je velice dynamická disciplína a z  minulosti se žít nedá. Proto se snažíme sledovat trendy na trhu a  držet si pověst firmy, která zná moderní technologie a umí je aplikovat. Jsme přesvědčeni, že právě informační technologie velice výrazně mění život lidí a my jsme připraveni ve spolupráci s Vámi k takovým změnám přispívat. Toto své přesvědčení jsme se pokusili vyjádřit heslem „Dáváme technologiím smysl“. Chceme účastí v  projektech zaměřených na eGovernment nebo eHealth přispět k  tomu, aby tato země měla co nejlevnější a efektivní veřejnou správu, aby se nám všem v ní dobře žilo (nebo alespoň pohodlně komunikovalo se státní správou nebo lékaři, ony ty IT technologie všechno nevyřeší).

Vždy jsme se snažili pracovat se špičkovými technologiemi. V  začátcích firmy jsme se zaměřili na  unixové systémy s  databází Informix a naši informixoví specialisté byli a jsou jedni z  nejlepších na trhu. Jak jsme rostli, museli jsme pokrýt i další nosné softwarové technologie společností IBM, Oracle nebo Microsoft. Jsme schopni pracovat na  hardwarových platformách všech velkých hráčů – IBM, HP, SUN (nyní Oracle), Fujitsu nebo Dell.

Chceme privátním subjektům pomáhat s rozvojem jejich obchodních aktivit, se zefektivňováním provozu nebo řízením firem. Víme, že se naši zákazníci chtějí věnovat hlavně svému businessu a starosti s  IT rádi nechají někomu jinému. My chceme být trochu více než jen spolehlivá softwarová dílna s  dobrými specialisty. Chceme s  Vámi řešit Vaše problémy ve chvíli, kdy vznikají, a co více, jsme připraveni s Vámi vytvářet prostředí, kde se potenciálním problémům předchází. Vytvářet systémy, které rozpoznávají události a samy volí způsob jejich řešení, systémy, které Vám připraví informace pro strategické rozhodování.

Do České republiky jsme přinesli řadu špičkových technologií – v  počátcích firmy třeba CASE systémy firmy Westmount nebo Select, později testovací nástroje Mercury (dnes HP), monitorovací nástroj Wili (dnes CA), systém pro řízení projektových portfolií a řízení kapacit CLARITY společnosti Niku (dnes CA) nebo nástroj pro řízení požadavků DOORS (dnes IBM), před nedávnem QlikView spo-

Proto posilujeme své schopnosti pracovat jako konzultanti. Ovšem stále si chceme zachovat schopnost to, co zákazníkovi radíme, zrealizovat. Proti typické konzultační společnosti, která končí svou misi řadou doporučení, se odlišujeme tím, že  naše doporučení zákazníkovi i zrealizujeme a tedy na sebe bereme podstatně vyšší míru zodpovědnosti za výsledek.

Obsah

Úvodník ..................................................................... 1 KWH – zeštíhlovací kůra s CloverETL .............. 2 Manažerský informační systém pomáhá provést Zdravotní pojišťovnu ministerstva vnitra bouřlivými vodami.................................... 4 DATA MINING – příklad shlukové analýzy....................................................................... 5 SDMT – zpracování dat s velmi složitou strukturou ................................................................ 6 Jak měřit kvalitu a produktivitu analýzy?......... 9 Naše stopa v historii ČR .....................................12 Manažerský systém v předním dřevařském podniku AGROP NOVA a.s. ......14 Unit testy.................................................................16 Aplikační portál OZP on-line v roce 2012 .......18 Jsou databáze stále moderní?.........................20 Úspěšná recertifikace systému environmentálního řízení a bezpečnosti práce.........................................................................21 Vtipy, sudoku ........................................................23

V  novinách, které právě držíte v  ruce, se dočtete, čím se v současnosti zabýváme, na čem pracujeme, a doufám, že zde najdete řadu užitečných informací pro sebe. Přeji Vám, abyste dokázali i v této nelehké době plnit svá předsevzetí a cíle. Petr Kučera

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

N

A

M

Í

R

KWH – zeštíhlovací kůra s CloverETL V  hloubi 90-tých let minulého století, v  době, kdy se pojem „datový sklad“ vyskytoval převážně jen v  akademické literatuře, jsme pro Českou správu sociálního zabezpečení vyvinuli systém KWH (Komix Warehouse) pro výpočet statistik důchodů a důchodců – čísla, která mají zásadní vliv na makroekonomiku našeho státu. Systém KWH byl koncipován jako vícevrstvý systém implementující ROLAP principy. KWH implementoval všechny v  současné době používané vrstvy a komponenty datového skladu a implementován byl jako proprietární řešení v prostředí Unix/Informix/ESQL-C pro serverovou část a v prostředí VisualC++ a VisualBasic pro klientskou prezentační část. Z  hlediska složitosti byla stěžejní částí vstupní datová pumpa, která přebírala změnová data vygenerovaná z provozního systému ČSSZ ve formě textových souborů a na základě velmi složitých pravidel je promítala do normalizované relační databáze v  KWH. KWH celkově představoval poměrně složitý komplex různých komponent, skriptů, metadat atd., který od svého spuštění prošel jen minimem úprav, z nichž největší bylo povýšení verze databázového stroje Informix a změna operačního systému z  HP-UX na Solaris. Zjednodušený popis architektury původního řešení znázorňuje Obrázek 1.

Po úctyhodných 16-ti letech provozu byla požadována další technologická změna, tentokrát přechod z databáze Informix na Oracle.

Plánování změny Při plánování požadované změny jsme zvažovali 2 základní možnosti. • Provést skutečně pouze změnu technologie a rozsáhlé části kódu aplikace vytvořené v technologii Informix/ESQL-C „mechanicky“ přepsat do technologie Oracle Pro*C, tedy se zachováním již zastaralé a poměrně složité architektury, nebo • zásadním způsobem modernizovat použité technologie, které následně umožní výrazně zjednodušit celkovou architekturu systému a v důsledku i jeho obsluhu a správu. V tomto případě by však bylo nutné prakticky znovu vytvořit celou logiku aplikace, zejména její nejsložitější vstupní část.

První varianta byla sice hodně pracná, z  projektového hlediska však byla poměrně dobře odhadnutelná, tudíž málo riziková. Z  dlouhodobého hlediska však nepřinášela žádné další výhody, např. v  podobě zjednodušení správy, usnadnění případných budoucích změn technologie atd. Naproti tomu druhá varianta představovala poměrně značná rizika zejména kvůli neschopnosti přesně odhadnout pracnost a dobu implementace, nedostatku zkušeností vývojového týmu s novými technologiemi a nutnosti dobře pochopit všechna „business“ pravidla systému a implementovat je jiným způsobem. Kromě mnohem „zábavnější“ práce však tato varianta skýtala i další výhody do budoucna, zejména podstatné zjednodušení obsluhy a údržby systému a získání nové kompetence vývojového týmu. Nástin architektury nového systému znázorňuje Obrázek 2, je na něm jasně patrné výrazné zjednodušení oproti původnímu stavu. Po zvážení jednotlivých variant jsme se nakonec vydali náročnější cestou modernizace celého systému. Pro implementaci jednotlivých komponent jsme zvolili následující technologie: • CloverETL pro datové transformace, • Java pro pomocné aplikace s GUI, • QlikView a MS Excel pro prezentační vrstvu. V tomto článku se budeme věnovat hlavně implementaci datové transformace v nástroji CloverETL.

Postup práce

Obrázek 1 – Architektura stávajícího stavu

2

Jelikož jsme sami neměli dostatek zkušeností s návrhem složitějších řešení v CloverETL, požádali jsme o spolupráci tvůrce tohoto produktu. Experti z Javlinu se zúčastnili nejprve úvodního odhadu pracnosti celého řešení, dále pak úvodní fáze vývoje, kdy bylo potřeba položit základy řešení. Jak se poměrně záhy ukázalo, implementace vstupní pumpy (IDA) byla mnohem složitějším problémem, než se zdálo v  době plánování. Prvním důvodem bylo mnohem pomalejší seznamování vývojového týmu s novou technologií, než jsme předpokládali. Nakonec se ale vývojový tým zapracoval a práce probíhala podle očekávání.

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

N

A

M

Í

R

ná část rozdílů způsobena tím, že nové řešení vytváří správnější výsledky než staré řešení. „Doplňkové“ porovnání obsahu databáze původní a nové aplikace nám zároveň dobře posloužilo jako průkazný podklad pro předávací a akceptační řízení, který zákazníkovi poskytl mnohem větší jistotu, že nové řešení je plně funkční, oproti ad-hoc porovnávání finálních uživatelských výstupů obou aplikací a navíc za řádově kratší čas. Nám jako dodavateli tento přístup přinesl průkazné a přesně dokumentované zhodnocení kvality vytvořeného díla a samozřejmě podstatné zkrácení a zjednodušení předávacího a akceptačního procesu.

Závěr

Obrázek 2 – Architektura cílového stavu Vážnějším problémem bylo, že charakter a složitost implementované datové pumpy se do značné míry vymykala modelu typického ETL procesu, na který jsou ETL nástroje stavěné a který oslovení experti znali. Začátek procesu budování nové datové pumpy tak poznamenalo „objevování slepých uliček“. Ve spolupráci s  kolegy z  Javlinu i   sami jsme vymýšleli různé možnosti jak vůbec danou problematiku v ETL technologii implementovat, abychom je pak často částečně nebo i úplně zavrhovali kvůli tomu, že dané řešení neposkytovalo dostatečnou výkonnost nebo kvůli tomu, že výsledný ETL proces byl příliš složitý a v praxi neodladitelný a neudržovatelný. O složitosti tohoto procesu svědčí i to, že se nám podařilo objevit v  použitém ETL nástroji několik chyb, kterým se ale kolegové z Javlinu promptně věnovali a většinou je rychle odstranili.

než jsme v  počátku předpokládali. Naštěstí nám v této oblasti velmi pomohl zase ETL nástroj, když jsme v  něm jako „vedlejší produkt“ jednoduše a  rychle implementovali přehledné porovnávání obsahu původní a nové aplikace, „přelévání“ dat mezi nimi, což se stalo neodmyslitelným základem procesu ladění. Přestože jsme pro implementaci nové datové pumpy použili úplně jinou technologii, která si vyžádala často odlišné postupy zpracování dat, podařilo se nám při zpracování standardních měsíčních vstupních souborů o velikosti cca 80 – 100 tisíc vět dosáhnout rozdílu pouze desítek až stovek vět mezi obsahem databáze původní a nové aplikace. Tedy cca 0,1 % a i z tohoto počtu je znač-

Redesign KWH byl pro nás pilotním použitím nástroje CloverETL a ETL technologie vůbec na projektu reálného života. Byla to do značné míry zkouška ohněm, ale podařilo se nám ji úspěšně zvládnout a kromě „povinné“ téměř absolutní shody výstupů nové aplikace se starou se nám podařilo dosáhnout hlavních očekávaných atributů, tedy: • • • •

zjednodušení architektury, zjednodušení obsluhy a údržby, zrychlení zpracování na stejném HW, získání cenné zkušenosti pro vývojový tým.

Kromě těchto materiálních statků se nám ještě podařilo dosáhnout také z  hlediska vývojáře významného duševního statku, když jsme se vyhnuli poměrně nezáživné až otravné práci v podobě tupého přepisování starého kódu. Jan Vrána

Díky ETL technologii byla implementace změn většinou poměrně jednoduchá, rychlá a bez zbytečných chyb. Po několika iteracích se nám podařilo najít elegantní cestu, jak předmětnou datovou pumpu realizovat tak, aby byla přehledná, výkonná a zároveň udržovatelná. Hlavní část ETL procesu pro datovou pumpu je znázorněna na Obrázku 3. Když jsme měli nalezenu uspokojivou cestu nebo kostru řešení, zbývalo už „jen“ ji naplnit požadovanou funkčností (jednotlivými validacemi, operacemi pro vkládání dat do databáze, atd.) a tu pak ještě otestovat a odladit. Vyvinutí funkčnosti bylo díky zvolenému řešení poměrně jednoduché a rychlé. Následné ladění ale bylo vzhledem ke komplikovanosti problematiky výrazně delší,

Obrázek 3 – ETL proces datové pumpy

3

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

N

A

M

Í

R

Manažerský informační systém pomáhá provést Zdravotní pojišťovnu ministerstva vnitra bouřlivými vodami

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Spolehlivě předpovídat budoucnost je nemožné, ale ti, kdo vnímají lépe vazby a složitosti současné situace, se dovedou snadněji rozhodovat a odhadovat budoucí vývoj. Úkolem manažerů každé společnosti je co nejlépe posoudit současný stav a pozici podniku na trhu, jeho příležitosti a hrozby. Každá velká změna je signalizována příznaky, které ji předcházejí. Hodnota včasné informace pak spočívá v tom, že vedení má dostatečný čas k přijetí patřičných rozhodnutí o adekvátní reakci na signalizovanou změnu.

Charakteristika zákazníka Zdravotní pojišťovna ministerstva vnitra ČR (ZP  MV  ČR), založená v roce 1992, je s 1,2 miliony pojištěnců největší zaměstnaneckou zdravotní pojišťovnou v  ČR. Má rozsáhlou síť více než 25 000 smluvních zdravotnických zařízení po celé ČR, díky nimž zajišťuje svým pojištěncům kvalitní, dostupnou a moderní zdravotní péči. V  posledních letech výrazně podporuje prevenci a zdravý životní styl prostřednictvím projektu Zdraví jako vášeň s  Pavlem Křížem. Od září roku 2009 ZP  MV  ČR svým klientům nabízí unikátní elektronický produkt Karta života, jejíž součástí je mj. i  osobní účet klienta s  údaji o výdajích na zdravotní péči za poslední tři roky. Karta života je klientům k dispozici po zadání PIN a hesla na internetu a od roku 2011 i na chytrém telefonu. Údaje z ní mohou klienti získat na svůj mobil i  prostřednictvím SMS zprávy.

Výchozí situace zákazníka Sílící konkurenční tlaky v systému zdravotního pojištění ČR v  druhé polovině devadesátých let přiměly ZP MV ČR hledat dostatečně kvalitní, přesný a komplexní nástroj k  získávání, analýze a reportování dat – zejména z oblasti zdravotní péče, financí a procesů – významných pro zajištění kvalitních služeb svým pojištěncům, pro optimalizaci obchodních vztahů se smluvními zdravotnickými zařízeními a pro zvyšování efektivity a konkurenceschopnosti podnikání ZP MV ČR a její schopnosti rychle a flexibilně reagovat na změny vnitřního a vnějšího prostředí.

Systém DAPO integruje informace z provozních systémů, zpracovává stanovený reporting a poskytuje nástroje pro zpracování ad-hoc dotazů. Údaje jsou dle stupně oprávnění poskytovány pracovníkům pojišťovny na intranetu v prostředí portálu. DAPO zpracovává a kombinuje informace z oblasti zdravotního pojištění i z  oblasti účetnictví a díky portálovému řešení umožňuje i začlenění dalších informačních systémů. V prostředí portálu je rovněž vybudováno Call Centrum. V  první verzi byl datový portál postaven na technologii společnosti MicroStrategy.

Vysoký komfort práce pro koncového uživatele se logicky projevil i v počtu koncových uživatelů. Po přechodu celého řešení se počet koncových uživatelů navýšil z cca 15 na více než 100 a dále narůstá. Nezanedbatelnou výhodou pro zákazníka je také skutečnost, že koncoví uživatelé systému nyní pracují s aplikacemi zcela intuitivně a nevyžadují žádná speciální školení. Podstatným způsobem klesly požadavky na vytváření reportů či ad hoc analýz specialisty IT. Uživatelé jsou schopni si potřebné analýzy dělat sami.

Projekt se úspěšně rozvíjel a během následujících let byla vytvořena řada datových skladů a datových tržišť. I když datový portál ZP  MV  ČR představoval ve své době moderní a mocný nástroj pro podporu řízení, byl zde prostor ke zlepšení: jakékoliv úpravy definovaných výkazů vyžadovaly zapojení specialistů IT a uživatelé se také často potýkali s nepříjemně dlouhými odezvami systému. To byla tehdy ovšem standardní situace všech řešení Business Intelligence.

Analytické informace o aktuální situaci i trendech ve všech významných oblastech  podnikání ZP  MV  ČR nejsou dnes výsadou několika jedinců ve vedení či ve specializovaných útvarech, ale jsou dostupné všem zaměstnancům, kteří je potřebují pro svoji práci. To umožňuje jak rychlejší, kvalitnější a  operativnější rozhodování na všech úrovních řízení, tak i   lepší komunikaci mezi vedením společnosti a  jejími zaměstnanci. Použitá technologie podporuje delegování některých rozhodnutí z úrovně vrcholového vedení na střední management v  duchu nejmodernějších trendů v  řízení organizací (každý pracovník v organizaci má k dispozici informace, které potřebuje ke svému rozhodování).

Naše řešení

Roku 2008 přišla společnost KOMIX s  námětem vylepšení systému na bázi zajímavého produktu QlikView a nové technologie IMA – In Memory Analysis. Tato technologie řeší problém dlouhých odezev pramenící z nutnosti neustálé komunikace s databázovými servery, kde jsou uložena jak zdrojová data, tak informace o struktuře datového skladu. QlikView ukládá data v komprimované podobě do operační paměti a díky patentované asociativní technologii je schopno výrazně zkrátit doby odezev – třeba místo 10 minut na jednotky vteřin.

Společnost KOMIX byla pro ZP  MV  ČR zajímavá svými specifickými znalostmi  podnikání zdravotní pojišťovny, získanými během  více než pětileté spolupráce s  Oborovou zdravotní pojišťovnou (OZP). V roce 2001 byl spuštěn společný projekt DAPO – vytváření a rozvoj datového portálu. Rozsah služeb poskytovaných společností KOMIX se neomezil na dodání hotového nástroje, ale obsahoval i aktivní účast na návrhu celého systému včetně koncepce a obsahu generovaných reportů.

ZP  MV  ČR byla jedním z prvních zákazníků, u něhož byl produkt QlikView na tak velká data nasazen. Prvním realizovaným projektem byl převod datového tržiště „Kmen pojištěnců“. I u zákazníka se plně potvrdily již otestované vlastnosti, zejména pak zkrácení doby odezvy z minutových časů na odezvy v podstatě okamžité, či maximálně několikavteřinové. Po úspěšném ověření pak bylo rozhodnuto převést k začátku roku 2010 do prostředí QlikView celé stávající řešení.

4

Hodnocení – přínos pro zákazníka

ZP  MV  ČR je dnes dle publikovaných finančních i výkonnostních parametrů jedna z nejlépe hodnocených zdravotních pojišťoven ČR, která se díky kvalitnímu řízení velice dobře vypořádává s  náročnými situacemi a požadavky, jimž v turbulentním prostředí českého zdravotnictví posledních let musí čelit. Výsledky hospodaření ZP MV ČR dokazují, že její ekonomická situace je dlouhodobě stabilní. Lékaři a zdravotnická zařízení řadí ZP MV ČR k nejspolehlivějším zdravotním pojišťovnám s  komplexními, kvalitními a flexibilními službami a   velmi dobrou platební disciplínou. A  svou zásluhu na těchto výsledcích ZP MV ČR má i manažerský informační systém, vyvíjený společností KOMIX. Hynek Krátký

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

DATA MINING – příklad shlukové analýzy

N

A

M

Í

R

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Oblast data miningu (pokročilých analýz dat) bývá z vnějšího pohledu vnímána jako oblast téměř hermetických tajemství. V tomto článku chci názorně ukázat jednu konkrétní analytickou techniku, kterou data miningové nástroje využívají. Jde o techniku shlukování (angl. clustering), kterou se v množině analyzovaných objektů – v komerční sféře nejčastěji v množině zákazníků – hledají podskupiny, které jsou si svými charakteristikami podobné. Technik shlukování se využívá celá řada, v tomto článku budu ilustrovat, jak pracuje asi nejrozšířenější a nejnázornější z nich, tzv. shlukování K-means.

Výchozí situace Představme si, že máme k dispozici o každém zákazníkovi dva údaje: jeho věk a výšku. Množinu zákazníků můžeme graficky znázornit například tak, jak je uvedeno na Obrázku 1.

č. 2 je již toto „rozdělení“ znázorněno přerušovanými čárami. V prvém kroku se tak ovšem zdaleka nemusí podařit rozdělit všechny body optimálně. Bod označený čtverečkem by – opticky viděno – měl spíše patřit ke shluku „nižší mladší“ než k shluku „vyšší“, ke kterému ho takovéto matematické rozdělení v tomto kroku přiřadilo. Pokud nicméně provedeme již popsaný postup s  posunem semínek do „těžiště“ jim nejbližších bodů, situace se změní. Obrázek 4 – Nové hranice shluků po posunu „semínek“ Uvedený postup se nyní může iterativně opakovat a může být ukončen tehdy, jestliže již posuny těžišť jsou podle nějakého kritéria velmi „krátké“. Výsledkem iterativního posouvání centroidů jsou hodnoty věku a výšky, které tvoří „průměrné hodnoty“ všech prvků, které do daného shluku patří.

Obrázek 1 – Grafické znázornění výchozích dat o zákaznících Našim úkolem je tedy najít zákazníky, kteří jsou si „blízko“ v  tom smyslu, že mají podobné hodnoty věku a/nebo výšky. V našem případě to není těžké udělat náhledem bez jakékoli matematiky – zdá se, že z grafického znázornění můžeme najít tři skupiny: nižší věk i výška, vyšší se středním věkem a konečně skupinu s vyšším věkem.

Závěr

Obrázek 2 – Náhodně zvolená „semínka“ středů předpokládaných shluků

Jak takovou věc ale algoritmizovat? Uvedená metoda K-means začíná ve své nejjednodušší podobě tak, že je předem stanoven počet shluků1. Řekněme, že v  našem případě využijeme předběžného náhledu a stanovíme počet shluků na tři. Algoritmické shlukování začneme tím, že do prostoru náhodně „zasejeme“ tři „semínka“ (angl. seeds), tedy tři dvojice hodnot věk – výška, které budou představovat hypotetické středy tří budoucích shluků. Naše tři semínka prohlásíme za „středy“ shluků, které hledáme. Víme ovšem, že kvůli náhodnosti jejich zvolení může toto být jen stěží na první pokus realitou. V  dalším kroku uděláme následující výpočet: vezmeme každý z  bodů výchozích dat, najdeme k němu nejbližší semínko a posuneme každé ze semínek náhodně zasetých v  předchozím kroku do vypočteného těžiště z právě těch bodů, které jsou danému původnímu semínku nejblíže. Na obrázku

Výše uvedený postup patří mezi ty nejzákladnější. „Vzdálenost“, která je mezi semínky a jednotlivými body měřena, jsme blíže nespecifikovali – v našem přiblížení jsme ji počítali jako euklidovskou vzdálenost souřadnic, což ovšem není jediná možnost. Podstatnější pro reálné aplikace shlukování ovšem je, že os, v jejichž rámci shlukování probíhá, bývá typicky mnohem více než dvě, kde je „shlukování“ možné provést ručně bez podpory sofistikovanějších nástrojů. Častý počet proměnných, které do shlukování vstupují, je mezi deseti a dvaceti, leckdy i významně více.

Obrázek 3 – Nové středy shluků Vidíme, že nové středy shluků (angl. centroidy) označené křížky jsou již mnohem více tam, kde bychom je očekávali. Pokud bychom měřili vzdálenost bodů od nových těžišť nyní, rozdělení do shluků vyjde tak, jak je znázorněno na obrázku 4. Nyní vidíme, že dříve problematický bod označený čtverečkem je již přiřazen do shluku, kde bychom ho očekávali (nižší mladší).

Jinou otázkou je, jaký počet shluků pro obchodní aplikace hledáme. Pro aplikace typu „nalezni nejčastější typologie v množině zákazníků“ se obvykle počet shluků pohybuje mezi 5 a 15. Jinou možností je s  pomocí algoritmu shlukování hledat nestandardní, minoritní vzorce chování, zejména pro účely detekce podvodů. V takovém případě se počty shluků často nastavují na několik desítek, počty případů v jednotlivých shlucích jsou tak menší, a určité shluky tak mohou obsahovat „nestandardní”, resp. potenciálně fraudulentní, chování. Základní výhodou techniky shlukování je, že umožní nalézt relativně malé množství typologií ve velkém množství dat.

5

U

V

Y

T

V

O

Ř

Í

M

E

Technika shlukování má ale i své nevýhody. Mezi hlavní nevýhody patří, že nalezené “centroidy” představují “průměrnou” hodnotu shluku. Kam ale zahrnout hraniční případy? Jestliže označíme shluk vlevo dole na našich obrázcích “menší mladší” či rovnou “děti”, patří tam skutečně případ označený čtverečkem, který je tam zařazen “matematicky”, ale ve skutečnosti spíše odpovídá střednímu věku?

V

Á

M

Ř

E

Š

E

Takových a dalších okolností spojených s technikami shlukování bychom našli více, jejich řešení je pak věcí konkrétní aplikace. V každém případě patří (po predikčních technikách) shlukování k často používaným a užitečným technikám data miningu.

N

Í

N

A

M

Í

R

Poznámka: Obecnější popisy jsou dostupné (z pera autora např. starší články online: http://www.systemonline.cz/clanky/data-mining-v-praxi.htm nebo http://www.adastra.cz/120_mereni-vysledku-kampani.aspx), ale pro nezasvěceného čtenáře příchuť neproniknutelného tajemství po přečtení nezmizí.

Existují velmi mnohé modifikace, které tento předpoklad nevyžadují, zde zůstáváme u jednoduchého příkladu.

1

Martin Šály

SDMT – zpracování dat s velmi složitou strukturou

. . . . . . . . . . . . . . . . . . .

Pod pojmem „veliká“ nebo „rozsáhlá“ data jsou většinou vnímána data velikého objemu – s velikým počtem záznamů, jejichž zpracování klade vysoké nároky na paměť, disky a procesor. Před časem jsme byli konfrontováni s požadavkem, který, jak se ukázalo, vedl na systém s velmi vysokou datovou náročností, avšak v  poněkud netradičním smyslu. Jednalo se o požadavek na vytvoření nástroje pro správu, vizualizaci a administraci nastavení telekomunikační sítě GSM dnešního operátora O2.

Problematika GSM sítě GSM síť se skládá ze stovek technologických oblastí uspořádaných do desítek síťových elementů (ústředen, HLR, RNC, MGC, ISS,…) různých typů a složitosti. Každý síťový element má svou různě složitou vnitřní strukturu. Od jednoduchých opakovačů až po složité páteřní komunikační uzly. Jednotlivé uzly jsou spolu svázány vazbami různých úrovní a typů. Některé vazby mají přímo fyzickou podobu kabelů spojujících jednotlivá zařízení. Jiné vazby mají mnohem méně hmatatelnou podobu vzájemně si odpovídajícího nastavení příslušných parametrů svázaných uzlů. Toto nastavení přímo vyplývá ze struktury komunikačních uzlů.

Obrázek 1 – Vazba mezi aktivními prvky sítě přes hodnoty parametrů Mají-li spolu dva prvky komunikovat, např. Ústředna Praha s Ústřednou Brno – viz Obrázek 1, musí v  obou z nich existovat v jejich směrovacích tabulkách takové položky, které mají za následek nasměrování části komunikace do správných fyzických propojení (např. drátů), fyzicky spojujících oba komunikační uzly. Mohou také existovat i mnohem jemnější vazby, které představují empirická pozorování nebo zkušenosti, jak se dané prvky vzájemně nepřímo a odvozeně ovlivňují. Sníží-li se například z nějakých důvodů propustnost jednoho uzlu, je potřeba přesměrovat část komunikace na některé jiné uzly, a zajistit tím dostatečnou propustnost celé sítě.

6

Některé části a parametry sítě mohou navíc mít jiný než přímo komunikační charakter. Část uzlů komunikační sítě se například zabývá evidencí uživatelů a tarifikací používání sítě, poskytováním dalších nadstavbových funkcí a služeb atd. Správa takové sítě spočívá v udržování a nastavování jednotlivých parametrů v příslušných komunikačních uzlech tak, aby síť jako celek vykazovala požadované vlastnosti (např. celkovou propustnost, odolnost vůči lokálním výpadkům, poskytování doplňkových služeb, atd.). Typickou administrační úlohou správy je například příprava sítě na plánovanou změnu rozložení zátěže přesměrováním části zátěže na méně zatížené uzly, rekonfigurace sítě při výpadku některých uzlů, začlenění nových uzlů do sítě nebo naopak, odebrání nepoužívaných nebo vadných uzlů ze sítě, změna způsobu adresování (číslování) koncových stanic, změna způsobu tarifikace používání sítě, zavedení nové služby do sítě atd.

parametrů všech uzlů v síti a dohledáváním parametrů, jichž se bude daná změna týkat. To je práce velice náročná, ale hlavně neefektivní a  je častým zdrojem chyb.

Každý zásah do sítě vyžaduje velice dobrou znalost její technologické konstrukce a fyzické topologie a   logických vazeb, ale také detailní znalost aktuálního nastavení všech parametrů ve všech komunikačních uzlech, kterých se příslušná změna týká. Před zásahem do systému musí obsluha shromáždit, prostudovat a dát vzájemně do souvislostí informace o stávajícím stavu a následně navrhnout nové nastavení jednotlivých parametrů tak, aby měl zásah požadovaný efekt. S rostoucím rozsahem a složitostí sítě velice rychle roste množství informací, které musí obsluha pro naplánování a provedení každé změny zohlednit. V síti, která je rozsahem ekvivalentní například komunikační síti v ČR, vyžaduje každá jen trochu větší změna usilovnou práci mnoha lidí, kteří většinu času tráví procházením výpisů aktuálních hodnot všech

• Složité získávání informací o aktuálním nastavení parametrů sítě. Informace bylo nutné získávat z různých zdrojů (binární konfigurační data, textové výpisy), které neměly jednotnou formu.

V  komerčním prostředí je obrovský tlak na jedné straně na pružnost, tj. na rychlost zavádění nových služeb sítě, a na druhé straně na zvyšování spolehlivosti sítě, protože každá minuta výpadku sítě přestavuje obrovské přímé ztráty v podobě ušlého zisku a ještě větší ztráty v podobě poškození dobrého jména operátora. Počítačová podpora v podobě systému SDMT měla umožnit správcům sítě rychle a efektivně procházet a prohlížet jednotlivé části sítě, jejich nastavení a vzájemné vazby, jejich vzájemné porovnávání i  sledování vývoje v čase a velice tak usnadnit a zefektivnit administrační zásahy. Hlavní problémy, které měl systém SDMT řešit, byly:

• Práce všech plánovačů nad jednotnými daty. Při plánování změny neměli jednotliví plánovači snadný přístup k dříve naplánovaným a dosud nerealizovaným změnám a vycházeli tak ve svých plánech z nesprávných vstupů. • Automatizovaná správa požadavků na změnu. Požadavky na změnu neměly jednotnou formu a komunikace s realizátory požadavků (předání požadavku a zpětná vazba o jeho realizaci) nebyla automatizovaná.

U

V

Y

T

V

O

Ř

Í

M

E

• Automatizovaná i uživatelská kontrola provedených změn, možnost zobrazit stav sítě v  libovolném historickém okamžiku. Kontroly, že požadované změny byly provedeny korektně, bylo nutné provádět opět ručně a vše manuálně porovnávat. Aby mohl počítač poskytovat požadované informace rychle a efektivně, je nutné do něj uložit informace o nastavení celé sítě se vší složitostí všech parametrů a jejich vzájemných vazeb. To je právě jedna z úloh, které lze snadno formulovat a řešit v malém rozsahu, ale jejíž výpočetní nebo paměťová složitost rychle roste s rostoucím rozsahem sítě. Efektivní načtení a uložení informací o spravované síti a jejich následné zpracování je hlavním a  nejdůležitějším problémem vytvoření popisované počítačové podpory správy telekomunikační sítě. Jedná se o problém uložení rozsáhlého obecného grafu a následných operací nad ním.

Technické řešení Požadavky

Technologické požadavky na nový systém vycházely zejména z parametrů sítě, kterou měl spravovat. Uvažovaná GSM síť sestává z:  • Cca 200 komplexních uzlů (síťových prvků s různě složitou vnitřní strukturou). • Komplexní uzly se skládají z konkrétních tabulek parametrů a nastavení (entit), kterých je celkem cca 13 000 zhruba 400 typů.

V

Á

M

Ř

E

Š

E

Dalšími důležitými požadavky byly ekonomické požadavky: • Nízké pořizovací náklady a • Nízké provozní náklady. Do kategorie nefunkčních požadavků patřila: Vysoká provozní efektivita zpracování, vysoký výkon.

Dostupné technologie Při zvažování možných metod pro implementaci systému pro správu uvedené sítě bylo nutné hledat metody použitelné na platformě relační databáze, protože alternativní platformy neposkytovaly očekávaný výkon a dlouhodobou stabilitu architektury. Z  popsaných parametrů je zřejmé, že se jedná o skutečně rozsáhlou síť, pro uložení a zpracování takové sítě běžně používané databázové systémy neposkytují dobrou podporu. Platforma relační databáze v zásadě nabízí dva základní přístupy pro budování aplikace: • Aplikace řízená strukturou dat, • Aplikace řízená obsahem dat. Aplikace řízená strukturou dat zachycuje maximum logiky v  podobě struktury a vazeb jednotlivých tabulek v  databázi a odpovídajících částí programového kódu aplikace pro obsluhu jednotlivých tabulek. Data zpracovává bez toho, že by se příliš řídila jejich obsahem. Schématicky tuto variantu znázorňuje Obrázek 2.

• Entity jsou propojeny vazbami, kterých je cca 20  000. Aktuální hodnoty jednotlivých údajů jsou čerpány z různých souborů stahovaných z jednotlivých síťových prvků. • Celkem se obraz stavu sítě čerpá z cca 600 souborů a

V  souvislosti s  obměnami a modernizací technologií jednotlivých komunikačních uzlů dochází k průběžným změnám struktury a obsahu zejména vstupních souborů. Za jeden rok dojde průměrně ke změně cca 5 % vstupních údajů (7 000 atributů).

Í

N

A

M

Í

R

uvažovanou složitost datového modelu by ale programový kód byl extrémně rozsáhlý s neúnosnými náklady na jeho vývoj a další údržbu a rozvoj. Aplikace řízená obsahem dat naproti tomu ukládá všechna data v  co nejuniverzálnější relační struktuře a maximum logiky zachycuje obsahem dat, tj. hodnotami a vzájemnými vazbami jednotlivých řádků tabulek. V případě uvažované GSM sítě by to bylo uložení grafu v obecném tvaru uzel – hrana. Schématicky tento přístup znázorňuje Obrázek 3.

Obrázek 3 – Schéma aplikace řízené obsahem dat V tomto případě by všechny spravované informace včetně struktury a topologie celé sítě i hodnoty jednotlivých parametrů byly uloženy ve zjednodušeném případě ve dvou relačních tabulkách. Programový kód pro obsluhu naznačeného schématu by byl ve srovnání s předchozím případem řádově menší, tudíž levnější na vývoj a následnou údržbu a rozšiřování. Pro uvažovanou složitost a rozsah spravované sítě však aplikace postavená na tomto principu vykazuje fatální výkonnostní nedostatky. Pro získání jedné hodnoty jednoho konkrétního parametru je potřeba položit několik dotazů do uvedené relační struktury. Jelikož v  uvedených tabulkách by byly uloženy všechny údaje včetně statické topologie a struktury sítě, atributů, jejich vazeb a aktuálních i historických hodnot, byl by počet jejich řádků v  řádu stovek milionů až miliard záznamů, což i při použití indexů vede na dlouhé doby vyhodnocení jednotlivých dotazů. Vyhodnocení přehledových dotazů, pro které je potřeba získat a porovnat veliké množství hodnot atributů by trvalo neúnosně dlouhou dobu.

• Jednotlivé tabulky (entity) se skládají ze sloupců (atributů), těch je celkem cca 200 000 a jejich vzájemně provázaných hodnot jsou desítky až stovky milionů.

• celkem cca 140 000 položek (atributů) vstupních souborů.

N

Obrázek 2 – Schéma aplikace řízené strukturou dat Aplikace vybudovaná tímto přístupem umožňuje maximálně využít potenciálu relační technologie vč. možnosti individuálního ladění jednotlivých dotazů a poskytne tak nejvyšší provozní výkon. Pro

Uvedené dvě na platformě relační databáze standardně dostupné metody bohužel vykazují zásadní nedostatky, které prakticky vylučují jejich reálné použití pro implementaci uvažovaného problému.

Použité řešení Aby bylo možné implementovat správu sítě uvažované složitosti, museli jsme vyvinout novou meto-

7

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

N

A

M

Í

R

du uložení a správy dat, která by převzala výhodné vlastnosti obou zmiňovaných metod a zároveň eliminovala jejich zásadní nedostatky. Jedná se především o: • Zásadní redukci složitosti aplikace a tím i nákladů na vývoj a údržbu oproti aplikaci řízené strukturou dat při maximálním zachování její provozní výkonnosti nebo • zásadní zlepšení výkonnostních parametrů oproti aplikaci řízené obsahem dat při maximálním zachování její jednoduchosti a tím i nízkých nákladů na vývoj a údržbu. Hledání nové metody tedy bylo směrováno následujícími hlavními požadavky: • Zobecnění většiny podobných a opakovaných částí, zejména v oblasti statické struktury a topologie sítě a zachycení a řízení těchto závislostí formou „obsahu“ dat, tj. metadat. (vylepšení oproti aplikaci řízené jen strukturou dat). • Oddělení metadat od „business“ dat, což přinese jednak větší přehlednost a snazší údržbu metadat ale zejména zásadní snížení objemu tabulek, ve kterých jsou uložena metadata a tím zásadní zrychlení vyhodnocování dotazů nad metadaty (na strukturu a topologii sítě). • Maximální využití možností relační technologie pro uložení a správu „business“ dat, aby bylo možné dosáhnout co nejlepšího provozního výkonu. Metodu splňující uvedené parametry se podařilo vyvinout a s její pomocí úspěšně implementovat systém, který uvedenou GSM síť dokáže efektivně uložit a zpracovávat. Tuto metodu jsme nazvali Dynamické Relační uložení Dat (DRD) a schéma aplikace na ní založené je znázorněno na Obrázku 4. Metoda Dynamického relačního uložení dat je založena na následujících principech: • Většina údajů o struktuře a topologii spravované sítě (tj. údaje o uzlech, jejich vzájemných vazbách, vnitřní struktuře jednotlivých uzlů a  tabulek parametrů a jejich vazbách), jakožto i o vstupních souborech, ze kterých se čerpají aktuální data nastavení sítě a informace o jejich vazbách na konkrétní atributy tabulek parametrů jednotlivých uzlů jsou uloženy v  podobě metadat v pevné statické relační struktuře (levá část schématu). To umožňuje, aby většina obslužných programů byla univerzální a nezávislá na konkrétní topologii a struktuře spravované

8

Obrázek 4 – Schéma aplikace s dynamickým relačním uložením dat sítě a tudíž, aby příslušný programový kód byl řádově méně rozsáhlý, tedy levnější na výrobu a  údržbu. Uložení strukturních metadat do pevné relační struktury také umožní mnohem rychlejší vyhodnocování dotazů na strukturu sítě, které jsou při použití univerzálního přístupu velmi časté. • Jednotlivé tabulky parametrů síťových uzlů a  hodnoty jejich atributů vč. historických hodnot jsou uloženy nativně jako tabulky relační databáze s  příslušnou strukturou (pravá část schématu). Tyto tabulky jsou vytvářeny a případně modifikovány dynamicky na základě obsahu statického popisu struktury sítě. • Jednotlivé operace s  hodnotami atributů jsou realizovány jako dynamicky sestavované SQL příkazy, které provádějí standardní DML operace a mohou tudíž plně využít výhod a výkonu nativních operací relační databáze. Takto vytvořených tabulek je sice vysoký počet, to ale reálně ničemu nevadí, protože k nim přistupuje výhradně aplikace na základě obsahu metadat. Díky tomuto způsobu uložení a zpracování „business“ dat je možné velmi efektivně a rychle vyhodnocovat i rozsáhlé „přehledové“ dotazy nad celou spravovanou sítí.

Vlastnosti řešení Popsaná metoda Dynamického relačního uložení dat umožnila vyvinout systém pro vizualizaci a správu parametrů GSM sítě popsaných parametrů. Vznikl tak systém, který je do dnešní doby unikátní. Z  uživatelského hlediska přináší systém SDMT správcům GSM sítě zejména: • Zásadní zjednodušení a zrychlení všech plánovacích úkolů. Pracovníci plánování nemusí před každou plánovanou změnou manuálně prohledávat a kontrolovat tisíce stran tištěných výpisů nastavení nebo klást desítky on-line dotazů do technologických uzlů. Aplikace SDMT jim na pár kliknutí poskytne všechny relevantní informace. „Business“ výsledkem je zásadní urychlení např. zavádění nových služeb do sítě nebo rekonfigurace sítě např. v případě výpadku nějaké části. • Zásadní snížení chybovosti procesu plánování pramenící zejména z  chyb lidského faktoru v  podobě manuálního procházení textových a on-line výpisů, ale také z faktu, že údaje v textových výpisech byly často už zastaralé a neplatné. Z „business“ hlediska je výsledkem výrazné zvýšení spolehlivosti sítě, což má velmi vysoký přímý ekonomický dopad.

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

• Zásadně redukovala objem programového kódu a tudíž náklady na jeho vytvoření a údržbu oproti aplikaci řízené strukturou dat díky zobecnění většiny obslužných algoritmů a jejich řízení obsahem metadat.

Na druhou stranu, metoda Dynamického relačního uložení dat ve vysoké míře zachovala žádoucí vlastnosti obou referenčních metod: • Došlo jen k  mírnému poklesu provozní výkonnosti oproti aplikaci řízené strukturou dat z důvodu režie s načítáním metadat při generování výkonných SQL příkazů a proto, že jednotlivé výkonné SQL příkazy není možné individuálně optimalizovat. • Došlo jen k  mírnému nárůstu objemu programového kódu aplikace oproti aplikaci řízené obsahem dat z  důvodu nutnosti interpretovat obsah metadat a generovat odpovídající výkonné SQL příkazy.

N

A

Obrázek 5 – Porovnání vlastností metod Použitá technologie práce s  košatou a dynamicky se vyvíjející strukturou dat umožnila systému SDMT poskytnout uživatelům komfortní nástroj pro definici vlastních reportů nad sledovanými daty. V  těchto reportech si uživatel sám nastaví, jaké oblasti spojené přes jaké vazby chce sledovat; určí si vstupní podmínky a kromě ad-hoc spouštění přímo v  aplikaci si může určit i časy jejich pravidelného spouštění a ukládání do databáze nebo textových výstupů. Typickými příklady takových reportů je např. sledování vazeb GT analýz s  GT resulty přes všechny síťové elementy, sledování kompletních routingových cest pro vybrané circuit group ve vybraných ústřednách, kompletní výpisy vazeb service setů a triggerů ve všech ústřednách apod. Uživatelé si tak mohou sami vytvořit potřebné výstupy, které jim umožňují efektivně řídit zadávání změn.

R

• Relativně veliký objem dat • Velmi vysoká vnitřní složitost • Dynamicky se měnící struktura. Tento charakter mají například následující oblasti: • Modelování a správa distribuovaného řídicího systému. • Modelování a správa distribuční a produktovodné sítě. • Modelování a správa obchodní a logistické sítě. • Modelování, správa a odhalování závislostí v ekonomických, technologických a jiných procesech. • Další.

Podařilo se nám vyvinout dosud unikátní systém SDMT, který je schopen s  využitím všech výhod

Jan Vrána

V  KOMIXu soustavně zlepšujeme všechny služby poskytované našim zákazníkům. K  těmto službám patří i analýza – a to jednak ve formě samostatně poskytované studie a konzultace, častěji však analýza jako součást projektů vývoje softwaru na míru a projektů jeho údržby a  rozvoje. Správně zpracovaná analýza a návrh IS je nejen nezbytným předpokladem pro efektivní vývoj, údržbu a další rozvoj informačního systému, je především předpokladem toho, že prostředky na IT budou vynaloženy účelně, tzn. na účinnou podporu procesů zákazníka a na splnění jeho potřeb a očekávání. Pokud chcete zvýšit jistotu ochrany těchto investic a zajímáte se o kvalitu přebírané analýzy nebo sami analýzy vytváříte, je tento článek určen právě pro vás.

Rozhodování na základě faktů je jedním z  pilířů všech standardů pro zajištění kvality. Měření kvality a produktivity je součást procesu zlepšování (cyklus

Í

Metoda Dynamického relačního uložení dat a systém SDMT byly vyvinuty pro správu konfiguračních parametrů GSM sítě, ale jejich použití může být mnohem širší. Své uplatnění mohou s  úspěchem nalézt i v dalších systémech, které mají kombinaci následujících vlastností:

JAK MĚŘIT KVALITU A PRODUKTIVITU ANALÝZY?

Proč měřit?

M

Vývoj systému a jeho komerční využití umožnila účelově vyvinutá metoda Dynamického relačního uložení dat, která efektivně kombinuje přirozené metody uložení a správy dat v  relační databázi, odstraňuje jejich zásadní nedostatky a zachovává jejich výrazné přednosti.

Závěr Porovnání vlastností jednotlivých metod je znázorněno na Obrázku 5.

Í

robustního prostředí relační databáze efektivně uložit a spravovat datový systém s velmi vysokou mírou složitosti, konkrétně konfigurační data GSM sítě sestávající z  datové sítě desítek až stovek milionů hodnot jednotlivých atributů konfiguračních parametrů jednotlivých aktivních prvků GSM sítě.

Z technologického hlediska metoda Dynamického relačního uložení dat prokázala požadované vlastnosti a umožnila vytvořit reálně použitelnou aplikaci pro správu rozsáhlé datové sítě. Zejména odstranila nežádoucí vlastnosti základních metod, tj.:

• Zásadně zlepšila provozní výkonnost oproti aplikaci řízené obsahem dat, tj. snížila dobu vyhodnocení operací nad spravovanou sítí. Zlepšení provozní výkonnosti je umožněno díky mnohem lepšímu využití nativních vlastností relační databáze.

N

PDCA, Plan-Do-Check-Act ). Měřit chceme proto, abychom mohli najít slabá místa v procesu analýzy a byli schopni ověřovat, že se nám je daří zlepšovat. Kvalitnější analýza výrazně ovlivňuje kvalitu a pro-

9

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

U

V

Y

T

V

O

Ř

Í

M

E

duktivitu celého procesu vývoje softwaru. Každá odhalená chyba v  analýze ušetří náklady na vývoj a  předejde nespokojenosti našeho zákazníka.

Lze to vůbec měřit? Když se zamyslíte nad tím, jak konkrétně kvalitu a  produktivitu analýzy měřit, dostanete více otázek než odpovědí: • Počtem stránek popisu požadavků a use case, které analytik napíše za den? Není lepší, když analytik navrhne jednoduché a efektivní řešení na půl stránky? • Je lepší ten analytik, který odevzdá kvalitní a  precizní práci ale po očekávaném termínu nebo v nevhodné úrovní podrobnosti, anebo je lepší ten, který odevzdá práci včas, ale je to nedomyšlené řešení, které bude potřeba při vývoji upřesňovat? • Je lepší analytik, který dokáže přesně a detailně vývojářům popsat navrhované řešení ale nedokáže naslouchat názorům a prioritám zákazníka, nebo ten analytik, který dokáže výborně komunikovat se zákazníkem a získat si jeho důvěru, ale srozumitelně specifikovat požadavek pro vývojáře nedokáže?

Jak to tedy měřit? Analýza není šroub ani rohlík, nelze ji poměřovat podle váhy, rozměrů, zakřivení, složení, chutě či trvanlivosti. Analýza je výsledkem tvůrčí činnosti a volba správné metriky má svá úskalí. Lze měřit analýzu například: • Přezkoumáním (angl. review) požadavků a analytických modelů a návrhů – nebo alespoň jejich vzorku jiným analytikem nebo testerem oproti definovaným checklistům (hodnotí se např. jednoznačnost, testovatelnost, úplnost a soulad s předchozími dokumenty apod.)?

V

Á

M

Ř

E

Š

E

zákazník, vedoucí projektu, programátor, tester, ale i jiný analytik (třeba ten, který se má starat o  další rozvoj systému a kvalitní analytickou dokumentaci ocení až v „daleké“ budoucnosti). Jak provést takové hodnocení, aby nevneslo rozpory do týmu, aby autor hodnocených výstupů nechápal takové hodnocení jako kritiku svých chyb, které může udělat každý, ale jako snahu o zlepšení výstupů celého týmu? • Sebehodnocením analytika podle stanovených kritérií? Bude mít takové hodnocení nějakou objektivní vypovídací schopnost nebo je užitečné už jenom v  tom, že pomůže analytikovi zamyslet se nad tím, jak to příště dělat lépe?

Jak začít Začít je potřeba zmapováním současného stavu a  určením hlavních oblastí, které chceme zlepšovat a na které se zaměříme. Jako jinde i zde platí, že je lepší začít s  několika málo jednoduchými metrikami. Je potřeba počítat s tím, že metriky se mohou měnit podle toho, jak se bude měnit oblast zájmu, na kterou se zaměříme. Pro začátek je vhodné určit minimum sledovaných charakteristik a určit jednotný způsob měření a vyhodnocování.

N

Í

0 – Neděláme vůbec nebo děláme nedostatečně

• Počtem hodin věnovaným na opravu chyb způsobených požadavky?

Prezentaci způsobu analýzy na projektu a její hodnocení provádí hlavní analytik, který je zodpovědný za analytické výstupy.

10

Í

R

1. Zadání na základě požadavků – Analytik vytváří zadání pro vývojáře na základě zdokumentovaných a schválných požadavků od zadavatele.

Nesprávný přístup: požadavky na vývoj a na změny pouze v emailech od různých lidí, roztroušeno v zápisech ze schůzek apod.

2. Plán analytické dokumentace – Na webových stránkách projektu je uveden souhrn všech dokumentů a modelů, které jsou v rámci projektu vytvářeny, včetně jejich umístění a pravidel aktualizace.

Nesprávný přístup: Dokumentace vzniká živelně, nestíhá se aktualizovat. Není chybou, pokud nějaký model vznikne v  průběhu vývoje, pomůže dalšímu postupu a dále se již neaktualizuje, protože svůj účel již splnil. Vždy ale musí být předem definováno, které dokumenty a modely se aktualizovat budou, aby byla zajištěna dlouhodobá udržovatelnost systému.

3. Popis funkcionality – Funkcionalita aplikace je popsána z hlediska používání aplikace pro dosahování cílů uživatelů (use case).

Nesprávný přístup: Je popsán pouze vzhled obrazovek a algoritmy, ale není zřejmé, k čemu slouží.

4. Popis procesu – Je popsána návaznost jednotlivých funkcionalit.

2 – Splněno, ale cítíme možnost na zlepšení

• Hodnocením výstupů analytika těmi, kteří je používají? Výstupy analýzy používají: koncový

M

1 – Splněno s problémy

• Množstvím změnových požadavků způsobených nedostatečnou specifikací původních požadavků, které nesplnily skutečné potřeby businessu?

• Shodou se standardy? Je ale pro daný typ projektu „požadovaná“ dokumentace odpovídající a zohledňuje skutečné individuální potřeby projektu?

A

s  požadavky, ale i údržba a rozvoj jeho systému, je v  dobrých rukou. Výčet dále uvedených zásad není zcela univerzální pro každou firmu, je dán tím, v čem se chce firma zlepšit nebo na co klade důraz. Sledované zásady se mohou postupně v čase měnit podle toho, na co se firma zaměří.

Například: V  KOMIXu sdílíme znalosti a zkušenosti z  oblasti analýzy napříč jednotlivými projektovými týmy a skupinami. Probíhají interní prezentace o způsobu analýzy na projektu, kde si mezi sebou analytici vyměňují své zkušenosti. V rámci těchto prezentací provádíme i hodnocení úrovně analýzy na projektu podle definovaných zásad (charakteristik kvality). Každé hodnocené zásadě je přiřazena hodnota 0 až 3 podle stupně naplnění zásady na konkrétním projektu.

N

3 – Na projektu splněno uspokojivě, nemáme potřebu měnit

Dále jsou uvedeny některé z  takto hodnocených zásad. Jedná se o skupinu zásad analýzy, které jsou zaměřeny především na zvýšení zastupitelnosti analytiků a na zvýšení dlouhodobé udržovatelnosti systému tak, aby náš zákazník mohl mít oprávněnou důvěru, že nejen vytvoření systému v souladu

Nesprávný přístup: Funkcionalita je sice popsána pomocí use case, ale není jasná jejich návaznost v rámci business procesu.

5. Dokumentace dat – Je zdokumentován význam datových položek (v databázi, na obrazovkách, v datových zprávách).

Nesprávný přístup: datové položky nejsou zdokumentovány, spoléhá se pouze na pochopení významu podle názvu datové položky, někdy jsou ale položky jako „datum“ nebo „částka“ nebo „příznak“ nejednoznačné.

6. Trasovatelnost – Je zajištěna trasovatelnost, tj. je možné dohledat vazbu mezi požadavky

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

N

A

M

Í

R

(včetně změnových požadavků a požadavků na opravu chyb), funkcionalitou aplikace, obrazovkami, rozhraními, daty. Pravidla zajištění trasovatelnosti na projektu jsou popsána.

Nesprávný přístup: nelze předem určit dopad změny do aplikace a rozsah přetestování.

7. Metriky pro odhad – Jsou evidovány metriky pro rozsah analytických prací i pro rozsah funkcionality vyvíjeného systému. Tyto metriky jsou ve spojení s projektovými metrikami o skutečné pracnosti použitelným podkladem pro odhad pracnosti dalších projektů.

Nesprávný přístup: metriky se nesbírají nebo jsou známé jen skutečné celkové pracnosti bez vztahu k  rozsahu projektu, takže pro odhad pracnosti nových projektů neexistují dostatečné podklady.

8. Přezkoumání – Na projektu probíhá přezkoumání věcné správnosti a úplnosti výstupů tak, aby každý výstup byl zkontrolován alespoň jednou další osobou, než je autor. Problémy se daří odhalovat včas. Nejedná se o formální kontrolu, například zda dokument obsahuje popis procesu podle šablony a bez pravopisných chyb, ale o věcnou kontrolu, zda popis procesu je správný a úplný.

Nesprávný přístup: Případná chyba v analýze nemůže být odhalena před odevzdáním výstupů.

Nyní tedy máme díky „sledovací“ metrice představu o stavu analýzy ve sledovaných oblastech a můžeme se zaměřit na opatření ke zlepšení ve zvolené oblasti. Předtím se ale zastavme ještě u problematiky přezkoumání výstupů analýzy.

Přezkoumání Přezkoumání (angl. peer review) hraje důležitou úlohu v  nalezení věcných nedostatků analýzy, jako je například srozumitelnost, jednoznačnost, úplnost, ověření, zda analýza dává odpověď právě na ty otázky, které je potřeba řešit v této konkrétní fázi projektu atd. A proto si zaslouží více pozornosti. Určitě je vhodné, když se s  analýzou v  předstihu seznámí architekt, hlavní programátor, hlavní tester. Ti však analýzu hodnotí především ze svého pohledu (požadavky na architekturu, srozumitelnost zadání k  programování, testovatelnost). Přezkoumání by měl provádět někdo, kdo se zabývá nejen formální shodou se standardy (například že existuje popis procesu se všemi formálními náležitostmi), ale zabývá se i věcnou správností a úplností analýzy z pohledu potřeb zákazníka.

Obrázek 1 – Příklad stavu analýzy pro projekty hodnocené za určité období (průměrné hodnoty z hodnocených projektů) Je potřeba počítat s tím, že přezkoumání je i mezilidský problém, protože autor přezkoumávaného výstupu může mít pocit, že je kritizován on osobně. Připomínky musí být čistě k věci a musí panovat shoda v tom, že v zájmu celého týmu i firmy je, když chybu najde kolega, než když ji najde až zákazník, a to třeba až ve fázi realizace, kdy odstranění chyby je řádově nákladnější. Nic nezkazí jenom ten, kdo nic nedělá. Přínosem přezkoumání je nejen nalezení chyb, ale i  prevence chyb. Proto je lepší, když je přezkoumání provedeno už ve fázi, kdy je hotovo jen 20 % výstupů a je nalezena chyba (neúplnost, nesprávné zacílení), která se ve zbývajících 80 % práce už nebude opakovat, než čekat, až bude hotovo 100  % práce, ve které ale může být více chyb a jejich náprava bude pracnější a bude na ni méně času. Tento přístup se ale opět často střetává s obavou autora dávat z ruky ke kontrole nehotovou práci, protože v ní mohou být nalezeny chyby.

Těmito opatřeními jsou především: • Stanovení odpovědností v procesu (každý ví, co má dělat a za co zodpovídá); • Výměna zkušeností a školení pro danou oblast (ví, proč to má dělat); • Kontrolní seznamy (checklisty) pro jednotlivé činnosti procesu a vzory výstupů (ví, podle čeho to má dělat a jakých častých chyb se vyvarovat); • Zavedení cílené metriky pro sledování účinnosti opatření (lze zjistit, zda to tak doopravdy dělá a zda to pomáhá procesu vývoje softwaru). Zvyšování kvality analýzy je dlouhodobý proces, v  jeho průběhu se postupně může měnit oblast, na kterou se zaměřujeme a kterou se snažíme zlepšovat. Je lépe zaměřit se na jednu oblast a pro ni rychle připravit výše uvedená opatření, než se pomalu snažit řešit problematiku analýzy v celé šíři.

Vyplatí se to! Přezkoumání má i další nepřímé přínosy: rozšíření znalostí projektu, produktu, problematiky businessu zákazníka na další analytiky. To umožňuje zastupitelnost analytiků při práci na stejném nebo podobném projektu.

Co dál? Vracíme se opět k  Demingovu PDCA cyklu. Na základě zjištěných hodnot sledovaných charakteristik určíme oblasti, na které je vhodné se zaměřit (například trasovatelnost, sběr metrik pro pracnost, přezkoumání výstupů…), a naplánujeme opatření ke zlepšení zjištěného stavu a ke zvýšení kvality analýzy.

Především pro prevenci budoucích chyb (narozdíl od testování, kde hledáme už existující chyby) má smysl provádět i přezkoumání analytických výstupů. Pokud by se odhalením alespoň jedné chyby v analýze ušetřilo 1 člověkoden práce na opravách následků včas neodhalené chyby (následky ve skutečnosti mohou být ale i řádově větší), potom se takové přezkoumání analýzy vyplatí. I kdyby to na pracnost vyšlo stejně, nedojde ke snížení důvěry zákazníka v kvalitní služby.

Tomáš Vahalík

11

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

NAŠE STOPA V HISTORII ČR

Ř

E

Š

E

N

Í

N

A

M

Í

R

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2002 – 2005

NAŠE VÝZNAMNÉ PROJEKTY

Zátěžové testování aplikací pro Volby 2002 (ČSÚ) Aplikace Evropský integrovaný tarif Společenství (TARIC) pro Generální ředitelství cel Informační systém rizik celních deklarací (ERIAN) pro Generální ředitelství cel Aplikace Národní integrovaný tarif (NIT) pro Generální ředitelství cel Nemocenská – zpracování hlášení o pracovní neschopnosti pro ČSSZ Provozní informační systém Vojenské zdravotní pojišťovny Informační systém pro výrobu, správu a evidenci řidičských průkazů pro Ministerstvo dopravy ČR

2000 – 2002 Eurotel – Aplikace na podporu plánování změn v telekomunikační síti (SDMT) Manažerský informační systém Zdravotní pojišťovny ministerstva vnitra Aplikace pro sjednávání, správu a evidenci smluv cestovního pojištění pro Vitalitas pojišťovnu, a.s.

1999 – 2000 Statistika důchodového zabezpečení pro ČSSZ Faktoringové financování skladových vozů ve společnosti ŠkoFIN, s. r. o

1995– 1999 Informační systém logistiky (ISL) pro Ministerstvo obrany ČR Statistický IS zahraničního obchodu (CeSta) pro Generální ředitelství cel

1992 – 1995 Provozní informační systém OZP (IZOP) Systém evidence majetku Magistrátu hlavního města Prahy

TECHNOLOGIE, KTERÉ JSME PŘINESLI

1992

1993

1994

1995

CASE Westmount CASE SELECT IQ QUERY – inteligentní systém pro reporting SUPERNOVA – objektové vývojové prostředí České třídění do Informixu

1996

1997

1998

1999

2000

2001

2002

2003

2004

2005

MERCURY (HP) – testovací a monitorovací nástroje Westmount OMT (IBM)

DOORS (IBM) – řešení pro správu a definici požadavků Jasmine (CA) – portálové řešení

První velký (tísíce uživatelů) zátěžový test SAP (pro společnost Telecom)

Clarity (CA) – Project & Portfolio Management MERCURY ITG (HP) – Project & Portfolio Management

12

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

N

A

M

Í

R

2012 2010 – 2012 Návrh a realizace nových procesů pro matriční události, procesy na ohlašovnách a soudech pro Ministerstvo vnitra ČR Podpora logistiky při sběru a třídění sčítacích formulářů při Sčítání lidu, domů a bytů 2011 (MV ČR) Systém pro zpracování žádostí o elektronické občanské průkazy (MV ČR) Systém pro pořizování a zpracování dat pro výdej dokladu o povolení k pobytu (MV ČR)

Napojení informačního systému Evidence obyvatel na základní registry (MV ČR) Napojení informačních systémů Ministerstva spravedlnosti ČR na základní registry (Ministerstvo spravedlnosti)

2008 – 2010 Vytvoření centrálního systému pro autentizaci uživatelů (Identity management systém) pro Národní technickou knihovnu Zpracování otisků prstů pro biometrické cestovní pasy Integrace informačního systému Evidence obyvatel s CzechPOINTem a datovými schránkami Napojení systému Insolvenčního řízení na ostatní systémy ČSSZ Vytvoření centrálního systému pro autentizaci uživatelů (Identity management systém) pro České vysoké učení technické Systém pro příjem a správu žádostí o dotace na zateplení (Zelená úsporám) (SFŽP)

2005 – 2008 Projekt cestovních dokladů s biometrickými prvky (Ministerstvo vnitra ČR) Napojení národního informačního systému do Schengenského informačního systému (Ministerstvo vnitra ČR) Aplikace Zakázky pod lupou (zveřejňování informací o veřejných zakázkách) pro Magistrát hlavního města Prahy 2006

2007

2008

2009

2010

2011

2012

Wili Introscope (CA) – Monitoring a optimalizace J2EE aplikací Tridion (SDL) – Web Content Management MERCURY BAC (HP) – monitoring aplikací

Bezpečnostní řešení od společnosti KOBIL QlikView (QlikTech) – nástroj business intelligence s unikátní in-memory analýzou CRM nástroje CAS od společnosti CAS Software AG

Cyber-Ark – nástroje na zabezpečení a správu privilegovaných uživatelů, aplikací a důvěrných informací

13

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

N

A

M

Í

MANAŽERSKÝ SYSTÉM V PŘEDNÍM DŘEVAŘSKÉM PODNIKU AGROP NOVA a.s.

R

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Jedním z  významných partnerů společnosti KOMIX je také společnost DATA-Software, která dodává ekonomický systém MAGIS a jako manažerskou nadstavbu tohoto systému využívá BI nástroj QlikView. Mezi velmi úspěšné aplikace vyvinuté a nabízené společností DATA-Software patří prostředky pro datovou analýzu a rozbory. Tyto aplikace náleží do kategorie tzv. Business Intelligence a jsou velmi vyhledávanými nástroji pro sledování dlouhodobých trendů, vyhledání úzkých míst v podnikovém hospodaření, posuzování úspěšnosti obchodních strategií a sledování kritických ukazatelů v podnikových procesech. Teprve analýzou dlouhodobých dat se lze v mnoha případech dobrat příčin problémů, které doutnají pod každodenní činností v podniku a jsou skryty v záplavě jiných údajů. Proto jsou součástí námi nabízených řešení prostředky pro vytváření a  plnění datových skladů a pro analýzu dat v datových skladech.

Charakteristika zákazníka Podnik Agrop Nova a.s. je jedním z největších a nejmodernějších výrobců velkoplošných vícevrstvých desek (SWP) v Evropě, sídlo společnosti i výroba jsou v České republice.

Aplikace QlikView 1 – Hlavní obrazovka top-managera s „budíky“ hlavních ukazatelů obchodování

Továrnu ročně opouští přes 640 kamiónů (1.200.000  m2) SWP desek. Dále pak je podnik výrobcem moderního stavebního systému NOVATOP, určeného pro montované dřevostavby. Základem tohoto programu je SWP deska.

Výchozí situace a řešení Aplikace MIS (Manažerský informační systém) byla v tomto podniku vybudována jako nadstavba nad podnikovou aplikací MAGIS PRO. Aplikace MIS zahrnuje datový sklad, automaticky plněný daty z  aplikace MAGIS PRO, který je denně aktualizován. Především pak MIS zahrnuje prezentační vrstvu, která je postavena na specializované a pokročilé BI technologii QlikView (výrobcem je společnost QlikTech). Tato vrstva, určená přímo uživatelům, se vyznačuje výjimečnou uživatelskou přívětivostí a především okamžitou odezvou na prakticky jakýkoliv dotaz uživatele.

Funkce aplikace MIS QlikView Požadavky managementu podniku AGROP, pokud jde o pokročilé rozbory a datovou analýzu, směřovaly především na nejrůznější rozbory výsledků obchodování. Cílem bylo maximálně

14

Aplikace QlikView 2 – Příklady zadání filtrů pro pohledy, příslušné záložky jsou označeny obvykle Výběr n

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

N

A

M

Í

R

zjednodušit vytváření podkladů pro rozhodování, týkajících se ziskovosti jednotlivých zakázek, hlavně pak ale odvozené údaje ohledně ziskovosti sortimentů výrobků, skupin výrobků, ziskovosti odběratelů, četnosti vyráběných rozměrů a kvalit výrobků a to vše v přehledném znázornění vývoje v čase a s vykreslením trendů. Součástí aplikace MIS v  podniku AGROP je mimo jiné poměrně velmi propracovaný systém pro přepočet poskytovaných slev a různých typů přirážek (např. za distribuci) na jednotlivé ukazatele sortimentu (kvalitu, rozměry, individuální kód výrobku) i na odběratele, aby bylo možno dosáhnout maximálně objektivního hodnocení ziskovosti jak u sortimentu, tak u odběratelů. Výsledkem je průběžně a denně aktualizovaný komplexní manažerský systém, který je dnes hlavním a věrohodným zdrojem informací pro majitele podniku, ostatní členy managementu a vlastně i všechny obchodníky. Příkladem pravidelně vyhodnocovaných a sledovaných ukazatelů pomocí aplikace MIS jsou: odběratelé, jednotlivé položky sortimentu (kódy výrobků, kvality, dřevina), prodané množství v m2 / m3 /  kusech, prodej je sledován ve finančním vyjádření (Kč, EUR), kromě výrobních nákladů jsou sledovány i ostatní náklady spojené s prodejem a distribucí (dopravné, provize, slevy, množstevní bonusy). Aplikace MIS umní vypočítat a prezentovat dosažené marže (hrubé i čisté s promítnutím obchodních nákladů), a to podle všech sledovaných ukazatelů: zakázek, odběratelů, sortimentu a sortimentních skupin, regionů apod. Finanční ukazatele lze přepočítat podle automaticky stahovaného kurzového lístku do libovolné měny. Aplikace umí analyzovat také stavy skladů hotové výroby (k  datu nebo stavy aktuální). Dodaná aplikace obchodních analýz byla později doplněna o rozbory marketingových informací, jejichž zdrojem jsou data z  předprodejních procesů a týkají se poptávek a nabídek a hodnocení jejich úspěšnosti. Aplikace MIS se zabývá zdrojem poptávek, předběžnými cenovými údaji, prodejními a projekčními partnery podniku AGROP, vyhodnocení konkrétních marketingových akcí.

Aplikace QlikView 3 – Vývoj obchodní marže (za veškerý sortiment) za období po měsících

Aplikace QlikView 4 – Podíl prodeje jednotlivých výrobků za vybrané období

Přínosy pro uživatele Celá aplikace MIS byla uvedena do provozu během dvou měsíců, Jedná se o velmi krátkou dobu, vezmeme–li v  úvahu rozsah aplikace a samozřejmý požadavek na přesnost a ověřitelnost informací generovaných aplikací MIS. V dalších 2 až 3 měsících byla aplikace ještě dopilována o  některé podrobnosti.

Hlavním přínosem aplikací MIS pro uživatele je okamžitý přístup k  důležitým informacím, která ovlivňují každodenní i strategická rozhodnutí. Aplikace MIS se stala ve velmi krátké době běžnou součástí porad managementu. Na rozdíl od standardních výstupů ERP aplikací je

možné pomocí MIS informace získat ad-hoc podle okamžité potřeby, a to i díky patentovanému způsobu uložení dat a s okamžitou odezvou bez ohledu na rozsah dat a strukturu zdrojových tabulek. Právě tato pružnost, jednoduchost a rychlost s jakou jsou generovány odpovědi na prakticky libovolnou kombinaci vstupních parametrů je uživateli nejvíce ceněna.

15

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

N

A

M

Í

R

Vyjádření majitele podniku AGROP NOVA, Ing. Jiřího Oslizla: „Od roku 2008 v  souvislosti s  recesí na evropském trhu došlo k  významnému poklesu marží u většiny produktů. Naši zákazníci jsou stále citlivější na cenu. Aplikace MIS nám denně pomáhá při vyhodnocování některých speciálních nabídek ve vazbě na aktuální marži dosahovanou průběžně v daném měsíci. Zvláště cenný je velmi jednoduchý rozbor marží podle jednotlivých výrobků u konkrétních odběratelů. Vzhledem k tomu, že standardní výrobky jsou v největším cenovém tlaku, optimalizujeme za použití MISu prodejní ceny u speciálních výrobků tak, abychom v součtu dosáhli kladných čísel. Za pomocí tohoto rozboru se pak můžeme objektivněji rozhodnout, zda má smysl realizovat každý konkrétní kontrakt. Každý den tak máme v  MISu operativně kompletní přehledy prodeje, které pak jednou měsíčně hodnotíme na obchodní poradě z nejrůznějších úhlů pohledu a i díky MISu můžeme objektivně a rychle přijímat nápravná opatření.“ Ing. Jan Pártl DATA-Software spol. s r.o.

UNIT TESTY

Aplikace QlikView 5 – Podíl prodeje podle jednotlivých regionů za vybrané období

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Testování softwaru je empirický technický výzkum kvality testovaného produktu nebo služby, prováděný za účelem poskytnutí těchto informací všem zainteresovaným stranám. Toť jedna z mnoha definic. Z hlediska rozsahu můžeme testování rozdělit na unit testy, integrační testy, funkční testy, zátěžové testy, akceptační testy atd. Tento článek bude zaměřen převážně na unit testy, jejich základní principy a jejich výhody a nevýhody. Hlavním smyslem jednotkových testů je ověření funkcionality psaného kódu a včasný záchyt a detekce chyb. Ačkoliv funkční či integrační testování má stejný cíl, jednotkové testy jsou v některých ohledech univerzálnější a mocnější. Podle statistik dokáží integrační testy pokrýt zhruba 70 % aplikace. Pokud chceme jít dále a pokrývat zbývající části, budeme muset zřejmě sáhnout k unit testům. Prostřednictvím unit testů je možné snadno nasimulovat chybové stavy, podmínky a různé situace, jejichž příprava v rámci integračního testování bývá o dost složitější. Funkční či integrační testy jsou v tomto ohledu daleko hrubší a potřebují ke svému běhu alespoň část funkční aplikace. Většina projektů nemá potíže s tím, že by neobsahovaly žádné testovací mechanismy. Pokud to někdo myslí s prací programátora vážně a zodpovědně, jistě si nějaký takový mechanismus vytvoří. Problém je většinou ve způsobu testování. Často bývá funkcionalita vyvíjeného softwaru testová-

16

na skrze finální podobu uživatelského rozhraní (UI) či různých externích rozhraní. Stisk tlačítka nebo vyvolání služby spustí sérii událostí, při kterých spolu interagují různé třídy a komponenty,

aby společně vytvořily požadovaný výsledek. Pokud test selže, znamená to, že selhala operace jako celek, a může být těžké dohledat, která z  komponent toto selhání způsobila. Jinými slovy

U

V

Y

T

V

O

Ř

Í

M

E

existuje více tzv. bodů selhání, což logicky znesnadňuje diagnostiku. Pokud máte na projektu unit testy, zkuste si jen tak cvičně odpovědět na následujících několik otázek. 1) Můžete spustit a vyhodnotit výsledek unit testu, který jste vytvořili před dvěma týdny nebo před měsícem? 2) Může kterýkoliv člen týmu spustit a vyhodnotit výsledek unit testu, který byl vytvořen před dvěma měsíci? 3) Je možné spustit a vyhodnotit výsledky všech vytvořených unit testů během několika minut? 4) Je možné spustit všechny unit testy, které jste vytvořili, stiskem jediného tlačítka? 5) Je možné napsat základní unit test během několika minut? Pokud alespoň v jednom případě zní odpověď „ne“, pak je tu jistá pravděpodobnost, že vámi zvolený testovací mechanismus nejsou unit testy. Zcela jistě je to určitý druh testů a zcela jistě jsou pro daný projekt potřebné a užitečné. V porovnání s unit testy mají ale nevýhodu minimálně v těch bodech, na které jste byli nuceni odpovědět záporně. Tímto se dostáváme k základním pravidlům, které by měly jednotkové testy splňovat. Lze je zapsat zkratkou F.I.R.S.T. a tady jsou: Fast (rychlý) – Testy by měly být rychlé. Měly by běžet rychle. Pokud běží pomalu, nebudete je chtít spouštět příliš často. Pokud je nebudete spouštět často, nenaleznete včas problémy, abyste je mohli řešit jednoduchým způsobem. Budete se obávat čištění kódu a ten nakonec začne degenerovat. Independent (nezávislý) – Testy by neměly na sobě záviset. Jeden test by neměl nastavovat podmínky pro druhý test. Každý test by se měl spouštět nezávisle a mělo by být možné testy spouštět v libovolném pořadí. Nástroje typu JUnit, NUnit to také tak dělají. Pokud uděláte testy závislé na pořadí, někdy vám projdou a někdy ne. Pokud budete psát testy, které na sobě závisejí, selhání prvního testu způsobí kaskádu selhání těch ostatních. To způsobí potíže při diagnostice a skryje chyby, které by následné testy odhalily. Repeatable (opakovatelný) – Testy by měly být opakovatelné v jakémkoliv prostředí. Pokud nejsou spustitelné v jakémkoliv prostředí, máte vždy výmluvu, proč vám testy neprošly. Self-Validating (samovyhodnocující) – Testy by

V

Á

M

Ř

E

Š

E

měly mít výstup ve formě logické hodnoty. Buď prošly, nebo neprošly. Nemělo by se stávat, že bude nutné číst protokolovací soubor nebo porovnávat dva různé textové soubory, aby se zjistilo, zda testy prošly. Nadstavbou samozřejmě můžou být různé grafické reporty, ale primárním výstupem by mělo být „prošlo“, nebo „neprošlo“. Pokud se testy nedokážou vyhodnotit samy, může být jejich selhání věcí subjektivního názoru a jejich spouštění může následně vyžadovat pracné ruční vyhodnocování. Timely (aktuální) – Testy by se měly psát aktuálně. Neměli byste začínat psát ostrý kód, dokud nebudete mít alespoň rozmyšlený způsob jeho otestování. Pokud budete rozmýšlet a psát testy po ostrém kódu, můžete zjistit, že je obtížné ostrý kód testovat. Můžete dokonce zjistit, že je ostrý kód po čase špatně navržený a prakticky netestovatelný. Přístup TDD přímo vyžaduje tvorbu testů před samotnou tvorbou ostrého kódu.

Stuby a vyřešení závislostí Závislost na okolí, externích knihovnách, ale také na dalších třídách a modulech v rámci aplikace je jedním z typických problémů testovaného kódu. Příkladem těchto závislostí mohou být třídy či knihovny zajišťující přístup k souborovému systému, databázi, mail serveru, webové službě atd. Pokud chceme mít pod kontrolou testy, je nutné mít pod kontrolou i části aplikace, na kterých testovaný kód závisí. Při psaní bychom se měli soustředit na podstatu testu a nikoliv na přípravu a správnou konfiguraci okolního prostředí. Z tohoto důvodu používáme stuby, jakožto náhradu externích závislostí. Stuby fungují jako jakási vrstva s možností přesměrování či záměny jedné implementace (typicky produkční) za jinou (testovací). Pro rozbití těchto závislostí existuje řada patternů a refaktorizačních technik (Factory Pattern, IoC, Extract and Override, atd.), jejichž podrobnější popis lze najít buď na webu, nebo v příslušné literatuře.

Mock objekty Stuby tedy využíváme proto, abychom zajistili hladký a na prostředí nezávislý průběh testu v případě, že testovaný kód obsahuje nějaké další závislosti. Někdy je ale žádoucí namísto výsledného stavu testovaného objektu (state based testing) otestovat interakci tohoto objektu s okolím (interaction testing). V takovýchto případech je možné použít tzv. mockovací objekty. Testovaná třída pak komunikuje s mock objektem, který zaznamenává historii a interakci s okolím, aniž by volal skutečné metody. Mockovaný objekt lze následně využít pro ověření, zda test prošel, či neprošel. Stuby a mocky lze libovolně kombinovat. Platí zde zásada, že test může obsahovat více stubů, ale měl by obsahovat

N

Í

N

A

M

Í

R

pouze jeden mock. Pokud mocků obsahuje více, pak pravděpodobně testujete více než jednu věc.

Izolační frameworky Ručně psané stuby a mocky mají jednu zásadní nevýhodu a tou je zcela jistě efektivita a čas, který je potřeba na návrh a vytvoření takovýchto tříd. Naštěstí existuje relativně jednoduché řešení v  podobě znovupoužitelných knihoven, které tento proces výrazně zjednodušují, zrychlují a snižují pravděpodobnost zanesení chyby. Těmto knihovnám se říká Izolační frameworky. Není to nic jiného než sada API, která poskytuje možnost vytváření tzv. dynamických stubů a mocků. Jinými slovy umožňují vytvářet tyto třídy za běhu, čímž odpadá nutnost návrhu a ručního psaní. Pokud kód nelze otestovat v izolaci s využítím stubů a mocků popř. izolačních frameworků, pak to obvykle znamená, že kód není dostatečně flexibilní a měl by být refaktorován.

Práce s „legacy“ kódem Kde začít v případě, že máme starou aplikaci bez testů se spoustou strašidelných tříd, které na první pohled vnikly způsobem copy–paste–rename? Existuje známé pravidlo, které říká, že 80 % chyb se nachází ve 20 % kódu. Cílem je tedy najít těch 20 %. Většinou každý tým dokáže stanovit, která oblast nebo část aplikačního kódu je nejvíce problematická. Prostor pro tvorbu testů se vyskytuje také při opravě chyb těchto aplikací. Další možností jsou verzovací nástroje, kde lze též získat statistiky ohledně oblastí, které jsou často měněné a opravované, a které by tudíž mělo smysl stabilizovat a pokrývat. Důležité je v tomto ohledu začít psát testy a stabilizovat kód s tím, že lepší design je možné udělat později.

Závěr Unit testy nejsou pouze části kódu sloužící k zachycení chyb, ale napomáhají též řídit design aplikace. Kromě toho mohou posloužit také jako dobrá programátorská dokumentace, což oceníte vždy, když se budete k aplikaci vracet a zjišťovat, jak kód fungoval. Pro psaní unit testů by neměl platit dvojí standard, tj. že na ostrém kódu si dáváme záležet, zatímco testy „flákáme“. Rozhodně zde neplatí, že psaní nečistých testů je lepší než nepsat nic! Psaní nečistých testů je z hlediska další údržby aplikace stejné, nebo snad i horší než nemít testy žádné. Zdroje: • Roy Osherove – The Art Of Unit Testing (Manning) • Petar Tahchiev, Felipe Leme, Vincent Massol, Gary Gregory – JUnit in Action (Manning) Zdeněk Křepela

17

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

N

APLIKAČNÍ PORTÁL OZP ON-LINE V ROCE 2012

A

M

Í

R

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

V roce 2012 se na aplikačním portálu Oborové zdravotní pojišťovny, který se nyní nově jmenuje OZP ON-LINE, odehrála celá řada významných změn a událostí. Nejen v souvislosti s marketingovými kampaněmi OZP došlo k výraznému nárůstu počtu klientů portálu. Pro uživatele byla doplněna řada nových funkcí a služeb, web i portálové aplikace dostaly nový kabát, ovládání aplikací je nyní ještě jednodušší a intuitivnější. V neposlední řadě došlo k přirozené selekci a „usazení“ použitých technologií a infrastruktury.

Propagace a klienti Portál OZP ON-LINE je primárně orientován na veřejnost, což se odráží v marketingových kampaních a pozornosti, kterou OZP věnuje nabízeným funkcím pro pojištěnce. Marketing OZP se téměř výhradně zaměřil na propagaci aplikace VITAKARTA, což je produkt třetí strany a pro OZP klíčová aplikace portálu OZP ON-LINE.

Obrázek 1 – Graf nárůstu počtu identit pojištěnců

OZP pro propagaci využila řadu komunikačních kanálů – Internet, billboardy, vlastní časopis Bonus a  dokonce i televizní seriál. Synergie těchto snah se nadmíru pozitivně projevila v  nárůstu počtu identit pojištěnců, jak je vidět na níže uvedeném grafu – viz Obrázek 1. Prudký start počtu identit „Pojištěnců“ na začátku roku 2012 souvisí s nasazením nové verze jejich evidence, která nyní umožňuje zastupovat například rodinné příslušníky, tj. je možné evidovat tzv. „zástupy“. Růst byl mohutně podpořen migrací zástupů z centrálního systému. „Přirozený“ nárůst pojištěnců na tento trend navázal a naplánovaný limit 70 tisíc (což je cca 10 % registrovaného kmene pojištěnců) bude brzo prolomen. Poznámka: Na Zdravotní zařízení a Zaměstnavatele je primárně orientován Portál ZP, což je společné řešení šesti zdravotních pojišťoven (všech kromě VZP a ZPMV).

Vzhled V  souladu s komplexní změnou vzhledu prezentačního webu OZP dostaly portálové aplikace jednotný a moderní vzhled. Byla změněna navigace přesunem nabídkového menu z pravého bočního panelu „o úroveň výš“ – viz Obrázek 2 – získaly aplikace větší plochu pro informace. Na vhodných místech aplikací byly doplněny dobře srozumitelné piktogramy a navigační prvky – viz Obrázek 3.

Funkce

Obrázek 2 – Nový vzhled aplikace OZP ON-LINE

18

Klientům nyní OZP ON-LINE nabízí řadu nových funkcí, které jim uspoří vyplňování papírových formulářů nebo cestu k přepážce na pobočce pojišťovny. Prostřednictvím aplikace „Změna údajů klienta“ mohou ze svého webového prohlížeče nahlásit aktualizace následujících údajů:

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

N

A

• osobních údajů – tituly, jméno, příjmení, telefony, atd., • bankovního spojení, • adresu bydliště či kontaktní adresy – viz Obrázek 4, • e-mailové adresy. Dále si mohou prohlédnout údaje o OSVČ pokud je v této kategorii pojištěnec evidován. Další novou a velmi užitečnou funkcí je podání přehledu OSVČ – nyní již v  „legislativní verzi pro rok 2011“ – viz Obrázek 5. Tato služba uspoří klientům OZP cestu na pobočku (nebo na poštu) a OZP se zase vyhne potenciálně chybovému „vytěžování“ dat z papírového formuláře.

Obrázek 4 – Změna údajů klienta

Před vlastním zpracováním Přehledu OSVČ si může klient OZP prohlédnout přehled v  OZP evidovaných platebních povinností nebo seznam evidovaných úhrad došlých do OZP v roce 2011. Další novou a žádanou aplikací je již zmíněné „zastupování“, které umožní spravovat údaje například za rodinné příslušníky. Aktualizovaný systém evidence identit umožňuje OZP pružně zařazovat zastupované osoby – viz. Obrázek 6 – a klientům pohodlné přepínání. Pro podporu klientů byly dále doplněny funkce pro změnu hesla a pro zapomětlivé „záchranná aplikace“ pro obnovu zapomenutého hesla.

Technologie a infrastruktura Z provozního hlediska se celý systém „stabilizoval“ v  prostředí aplikačních serverů JBoss a Weblogic s  databází Oracle v  prostředí virtualizovaných li-

Obrázek 3 – Piktogramy a navigační prvky aplikace OZP ON-LINE

Obrázek 5 – Formulář „Přehled OSVČ“

19

M

Í

R

U

V

Y

T

V

O

Ř

Í

M

E

nuxových operačních systémů (CentOS a RedHat). Zaběhly se systémy správy, zálohování, statistik, monitoringu, auditu a logování. Novinkou je zavedení inteligentních formulářů firmy Software 602 (pořizování přehledů OSVČ). Aplikace na bázi formulářů je tedy nyní možné dále rozvíjet a rozšiřovat. Systém odesílání SMS přes softwarovou bránu od O2 byl pro případ selhání posílen hardwarovou SMS bránou a celek byl zastřešen do virtuální SMS brány. Služby této brány mohou být využity nejen

V

Á

M

Ř

E

Š

E

k autentizaci klientů ale i jako zvláštní komunikační a informační kanál. V uplynulém roce byla nezávislou firmou provedena na žádost OZP druhá vlna penetračních testů, které dopadly velmi dobře a ve finálním hodnocení byly systému vytknuty jen drobné či kosmetické nedostatky.

Plány do blízkého i vzdálenějšího budoucna Pro další blízké i vzdálenější období se plánuje další rozvoj funkcionality pro všechny druhy klientů

N

Í

N

A

M

Í

R

OZP, velký prostor je například v oblasti podávání žádostí či výkazů prostřednictvím formulářů apod. Dále bude rozšiřována integrace s okolními portály, weby a službami. Již nyní je OZP ON-LINE integrován s „Portálem ZP“ a jeho prostřednictvím na vybraný informační systém zdravotnických zařízení (pilotní provoz). Pracuje se na přesměrování na webové aplikace pojišťovny Vitalitas, které klientům poskytne rychlé sjednání cestovního pojištění.

Martin Lipš

Obrázek 6 – Seznam evidovaných zástupů

JSOU DATABÁZE STÁLE MODERNÍ?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Ať už je odpověď na otázku v nadpisu jakákoliv, existuje konference, která se tak již dlouho jmenuje. Ano, jde o konferenci Moderní databáze. Hned úvodem je třeba říci, že konference Moderní databáze je především národní konferencí. Jejím účelem vždy bylo seznamovat odbornou veřejnost s novinkami v oblasti zpracování dat.

Prehistorie Moderních databází V prvním ročníku konference v r. 1986, kdy se jmenovala Databáze pro minipočítače a mikropočítače, se dokonce přednášelo detailně o souborech, indexaci a principech konceptuálního a databázového modelování. Rozebíral se síťový, hierarchický a  relační databázový model, návrh relační databáze či normální formy relací. Délka příspěvku do sborníku nebyla omezena, jak tomu je dnes na konferencích obvyklé. Např. sborník této první konference měl 113 stránek a napsali jej dva autoři a zároveň také zakladatelé konference – prof. RNDr. Jaroslav Pokorný, CSc. a RNDr. Ing. Petr Kučera. Sborník mohl být využit, a také tomu tak bylo, jako učební text. Na historii konference Moderní databáze lze ukázat, jak takové národní konference vznikaly. Vždy šlo o  skupinu nadšenců, na kterou se nabalovali další. Tito lidé dnes na konferencích obvykle tvoří její řídící výbor (steering commitee). Důležité bylo rovněž nalézt instituci, která konferenci zorganizuje. V 80. letech se nabízely Domy techniky Československé vědeckotechnické společnosti (ČSVTS). V daném případě to byl Dům techniky ČSVTS Ústí nad Labem (později firma z něho vzniknuvší), který

20

konferenci organizoval na velmi dobré úrovni v letech 1986 – 1997. Takto pojatá databázová konference měla v prvních letech stabilizované množství příspěvků (ne více než 11) a rovněž i skupinu několika autorů (kromě již zmíněných např. i tehdejší výrazná postava v  databázové komunitě – P. Vršek, zaměstnanec Federálním cenovém úřadu). Nosná témata konference zahrnovala např. v roce 1987 návrh databázových systémů. Hovořilo se zde i o problémech, které už dnes nikoho nezajímají, např. o dynamických strukturách organizace souborů, které jsou dnes běžné ve výbavě každého SŘBD (Systém řízení báze dat), např. B+-stromy. Ročník 1989 byl věnován databázím na osobních počítačích. Zájem byl např. o jazyk SQL, QBE a metodologie pro převod z  konceptuální úrovně do prostředí dBASE.

Jak dál po roce 1989 Od roku 1990 se stabilizoval název konference na Moderní databáze. Její zaměření reaguje na současný stav databázového software u nás a zejména na metody, které jsou u tvorby databázového software v  pozadí a které mohou být zajímavé

pro správce databáze či aplikační programátory. Prezentují se metody organizace dat, ale i tehdejší SŘBD na PC (dBASE IV a další). Diskutují se rovněž CASE nástroje a SŘBD jako PROGRESS a Informix, které se vyvíjejí v  dalších dvou dekádách a jsou známy i dnešní generaci databázových odborníků. Přibývají autoři z firem, které databáze začínají komerčně využívat a zakládat na nich svou existenci. Postupně se na konferencích Moderní databáze objevují články o jazycích 4. generace a také o  nových, objektově-orientovaných databázích, do kterých se vkládaly velké naděje. Vedle stabilních autorů P. Kučery (KOMIX) a J. Pokorného (MFF UK) přibývají další autoři z akademické sféry jako V. Řepa (VŠE) či K. Richta (FEL ČVUT, později MFF UK).

U

V

Y

T

V

O

Ř

Í

M

E

V  roce 1996 je dost místa věnováno objektovým metodikám a praktickým ukázkám jejich použití. Prezentují se dnes již exotické databáze jako JASMINE, ale také např. programovací techniky (jazyk JAVA) důležité pro tvorbu aplikací s  databázovou podporou. V roce 1997 a několika dalších letech je na konferencích Moderní databáze prezentována řada příspěvků věnovaných technikám datových skladů. Objevují se autoři z  firem jako SAS, Software AG, Informix, Sybase, kteří prezentují principy a funkčnost svých systémů, účastnici se rovněž dozvídají o databázích jako je Caché. Pozornost se obrací k  tvorbě aplikací v  prostředí webu a business intelligence.

V

Á

M

Ř

E

Š

E

Autorsky se pravidelně angažují odborníci z firmy KOMIX s.r.o. Tato firma rovněž od roku 2000 přebírá organizaci konference. Moderní databáze tehdy pružně reagují na příchod XML. Vedle základů XML technologií bylo možné se seznámit s produkty jako je TAMINO XML databáze. Postupně se také stabilizuje model příspěvků na dva až tři z akademické sféry, ostatní od oborníků z firem. V dalších letech se pokračuje s  XML, webovými službami, objevují se referáty o návrhu a bezpečnosti internetových aplikací, kvalitě dat v  informačních systémech.

N

Í

N

A

M

Í

R

bývá pro jakoukoliv konferenci obvykle její labutí písní. Kupodivu v roce 2010 pokračuje konference dál se  zaměřením na zejména na business intelligence. Po další pauze v roce 2011, kdy konference přešla na model pořádání jednou za dva roky, tu je rok 2012 a s ním i další ročník Moderních databází s  podtitulem Architektura informačních systémů. Ptáte se, a  co ty databáze? Natožpak moderní? Ano, moderní jsou dnes např. NoSQL databáze. A nejenom o  nich bude na konferenci řeč. Vždyť hlavním tématem tohoto ročníku je Zpracování velkých objemů dat a transakcí.

Pár let hledání, současný stav Ročník 2006 je významný tím, že se po něm pořádání konference na tři léta přeruší. Tento jev

Jaroslav Pokorný Matematicko-fyzikální fakulta Univerzity Karlovy

ÚSPĚŠNÁ RECERTIFIKACE SYSTÉMU ENVIRONMENTÁLNÍHO ŘÍZENÍ A BEZPEČNOSTI PRÁCE

. . . . . . . .

V polovině července 2012 společnost KOMIX s.r.o. úspěšně absolvovala recertifikační audity na systém environmentálního řízení (EMS) dle normy ČSN EN ISO 14001:2005 a Management bezpečnosti a ochrany zdraví při práci (BOZP) dle normy ČSN OHSAS 18001:2008. Norma ČSN OHSAS 18001:2008, pro posuzování bezpečnosti a ochrany zdraví při práci (BOZP), stanovuje požadavky na systém managementu BOZP tak, aby umožnila společnosti KOMIX s.r.o. řídit svá rizika BOZP, minimalizovat je a zlepšovat výkonnost managementu bezpečnosti a ochrany zdraví při práci. Systém managementu bezpečnosti a  ochrany zdraví při práci je založen na principech moderního managementu a svojí strukturou navazuje na normy řady ISO 9000 a řady ISO 14000, a umožňuje tak začlenění do integrovaného managementu společnosti (IMS) KOMIX s.r.o. Norma ČSN EN ISO 14001:2005 umožňuje realizaci efektivního systému řízení šetrného k životnímu prostředí. Identifikace environmentálních aspektů (činností), které mají dopad na životní prostředí, jejich hodnocení z hlediska významnosti, a poté řízení, monitorování a neustálé zlepšování jsou klíčové požadavky této normy a vedou k snižování dopadů činnosti naší společnosti na životní prostředí. Recertifikace obou managementů, kterou prováděla certifikační společnost CQS, byla provedena poprvé jako integrovaný recertifikační audit obou systémů řízení (EMS a BOZP). Tým auditorů společnosti CQS prověřil všechna pracoviště a neidentifikoval žádnou neshodu. Audity tak potvrdily, že systém EMS a BOZP je zaveden a zlepšován v souladu s požadavky norem ISO a společnost CQS vydala nové certifikáty splatností do roku 2015. Tím

byl také zahájen další tříletý cyklus, během kterého certifikační společnost CQS bude provádět každý rok dozorové audity. Společnost KOMIX s.r.o. si uvědomujeme dopad svých aktivit na životní prostředí a má na zřeteli také otázky životního prostředí v procesu našeho rozhodování. Snaží se proto o trvalé zlepšování životního prostředí snižováním negativních vlivů na životní prostředí a vytváření bezpečného pracovního prostředí pro své zaměstnance. Oba recertifikované managementy jsou součástí integrovaného managementu společnosti KOMIX s.r.o., do kterého patří také: • certifikovaný systém managementu kvality dle ČSN EN ISO 9001 (QMS),

Obrázek 1 – Integrovaný systém managementu kvality společnosti KOMIX s.r.o.

• management kvality projektu dle ČSN EN ISO 10006 (QPM),

Charakteristika integrovaného systému • management IT služeb dle ČSN ISO/IEC 20000-1 (ITSM) a • management bezpečnosti informací dle ČSN EN ISO 270001 (ISMS). Vysokou kvalitu produktů a poskytovaných služeb tak nyní zaručuje celkem šest certifikátů, které jsou uznávány v celé Evropské unii i ve světě.

Systém managementu kvality je ve společnosti KOMIX s.r.o. udržován a zlepšován již 10 let. První certifikát systému managementu jakosti dle normy ČSN EN ISO 9001 získala společnost již v roce 2002 a od té doby byl postupně rozšiřován integrovaný management o další certifikované managementy. Vzhledem ke snaze o co nejvyšší efektivitu a účinnost zavedených systémů proběhla v  roce 2006

21

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

N

A

M

Í

R

zvyšovat jeho spokojenost produkty a poskytovanými službami,

integrace jednotlivých systému do jednoho integrovaného systému. Systém integrovaného managementu je v naší společnosti vybudován na základě norem ISO 9000, které stanovují požadavky na systémy kvality. K této základní části systému byly přidány specifické požadavky na ochranu životního prostředí dle norem řady ČSN ISO 14000 (2006), na ochranu zdraví a bezpečnost při práci dle norem řady ČSN OHSAS 18000 (2009), kvality projektů ČSN ISO 10006 (2009), kvality IT služeb ČSN ISO/IEC 20000-1 (2009) a bezpečnosti informací ČSN ISO/IEC 27001 (2010). Tímto způsobem vznikl ucelený integrovaný systém, který minimalizuje rozsah dokumentace, zvyšuje její přehlednost a snižuje náklady potřebné na tvorbu, zavádění a správu systému.

identifikace cílů, rozsahu a politiky certifikovaných managementů a procesní přístup – model PDCA (Plan-Do-Check-Act/Plánuj-dělej-kontroluj-jednej). Integrované jsou také procesy, které zabezpečují řízení dokumentů a záznamů, interní audity, monitorování a měření, zajišťování zdrojů, způsob měření efektivity, řešení nápravných a preventivních opatření, přezkoumání systémů managementu, kontinuální zlepšování a řízení rizik, které jsou společné pro všechny integrované managementy.

Stávající procesy řízení byly vždy v  průběhu implementace jednotlivých certifikovaných managementů přepracovány a optimalizovány podle implementovaných norem ISO. Některé interní audity se provádí také integrovaně. Integrována je

Uplatňováním a dalším rozvojem integrovaného systému řízení deklaruje management společnosti KOMIX s.r.o. zájem:

• neustále zlepšovat image společnosti a zvyšovat její konkurenceschopnost.

• klást důraz v orientaci na zákazníka a neustále

Jiří Feřtek

Klíčové přínosy integrace nebo implementace jednotlivých systémů managamentu na společném základě jsou zejména v oblasti snížení nákladů, časové náročnosti pro management, duplikace a  byrokracie.

• poskytovat produkty splňující požadavky a potřeby zákazníka i legislativních předpisů, • neustále zvyšovat zainteresovanost zaměstnanců na plnění úkolů společnosti, vytvářet motivující a bezpečné pracovní prostředí, • vyhodnocovat efektivitu procesů ve společnosti a zavádět opatření pro neustálé zlepšování, • určovat a poskytovat potřebné zdroje pro zajištění funkce a rozvoje integrovaného systému řízení, plnění stanovených cílů a smluvních závazků společnosti,

Společnost KOMIX s.r.o. se stala na začátku roku 2012 příjemcem finanční podpory v  rámci programu OPPA na vzdělávání svých zaměstnanců z fondů EU. V  nadcházejících dvou letech se cílová skupina z  řad zaměstnanců společnosti bude školit v oblasti soft skills, cizích jazyků (anglického jazyka zaměřeného na oblast ICT), v IT certifikacích a odborných školeních. Zaměstnanci získají vyšší kvalifikaci, což zlepší jejich postavení na trhu práce a společnost ji zároveň s radostí využije při poskytování služeb svým klientům.

22

U

V

Y

T

V

O

SUDOKU

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

N

A

M

Í

R

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ČLOVĚK NENÍ ŽIV JEN PRACÍ, aneb i v práci se zasmějte

. . . . . . . .

Wikipedia: „Já vím všechno!“ Google: „Najdu všechno!“ Facebook: „Já znám všechny.“ Internet: „Beze mě, jste v háji.“ Elektřina: „A tak se uklidníme jo?!“ Uhlí a Uran se na sebe podívají a pak propuknou v hysterický smích.

Chlap vytáhne cigaretu z krabičky, dá ji do úst a  zapálí. Dívka mu na to odpoví: „Co to děláš, ty nevidíš, že na krabičce je varování, že kouření vážně škodí zdraví?“ Kluk odpoví: „Lásko, já jsem programátor. My na warning kašlem, nás zajímají jenom errory.“

Anketa na ulici, moderátor se ptá kolemjdoucích: „Máte zkušenosti s virtuálním sexem?“ Kolemjdoucí muž: „S jakým sexem?“ Kolemjdoucí administrátor: „S virtuálním čím?“

Uživatel: „Proč bych měl platit nějakej poplatek za vypalovačku a média, když nebudu nic krást?“ Zákonodárce: „Protože máte nástroj.“ Uživatel: „Tak to mě zavřete za znásilnění sousedky!“ Zákonodárce: „Vy jste znásilnil sousedku?“ Uživatel: „Ne, ale mám nástroj!“

Blondýna volá na helpdesk Microsoftu. Blondýna: „Haló, nejde mi počítač!“ Helpdesk: „Dobrá, co máte na monitoru?“ Blondýna: „Květináč.“ Helpdesk: „Ne, ne, to si nerozumíme; mám na mysli, co je tam napsáno.“ Blondýna: „Jo aha, už chápu: SONY“

Je to v pytli, na disku už máme místo jenom vpravo... Cože?!? No píše to: „No space left on this device“!

23

U

V

Y

T

V

O

Ř

Í

M

E

V

Á

M

Ř

E

Š

E

N

Í

N

A

M

Í

DĚKUJEME VŠEM NAŠIM KLIENTŮM ZA PŘÍZEŇ A DŮVĚRU

KOMIX s.r.o. Avenir Business Park, Radlická 751/113e, 158 00 Praha 5, Tel.: +420 257 288 211, [email protected], www.komix.cz. Redakční zpracování: kolektiv pracovníků KOMIX s.r.o. © KOMIX s.r.o. 2012

R

U