Mobilní aplikace

2013/2014

Komix Fórum Vážení čtenáři, přemýšlíte někdy o tom, pro koho má vaše práce smysl? My v KOMIXu ano. Je pro nás důležité vědět, že tady nejsme kvůli tomu, abychom „dělali business“, nýbrž proto, abychom umožnili milionům lidí projít nejrůznějšími životními situacemi. Posuďte sami, jak se nám daří naplňovat naše heslo „Dáváme technologiím smysl“: »» Více než 100 tisíc narozených dětí, více než 90 tisíc novomanželů a více než 200 tisíc stěhujících se osob projde ročně naším systémem evidence obyvatel. »» V loňském roce jsme při první přímé prezidentské volbě zpracovávali petiční archy s více než půl milionem podpisů. »» Náš software obsloužil více než 4 miliony lidí, kteří si zažádali o biometrický pas nebo nový občanský průkaz. »» Pro Českou správu sociálního zabezpečení spravujeme údajovou základnu s daty více než 10 milionů klientů. »» Zdravotní pojišťovny v  našich informačních systémech evidují přes 1 200 000 pojištěnců.

1 2 3 4 5 6 7 9 12

»» V programu Nová zelená úsporám bylo prostřednictvím našeho systému během prvních 24 hodin od spuštění alokováno téměř 350 milionů korun pro více než 1 400 žadatelů. »» S našimi systémy přichází přímo či nepřímo do styku každý, kdo si koupí nové auto s financováním od ŠkoFINu, vyváží nebo dováží zboží z nebo do zahraničí nebo studuje literaturu z Národní technické knihovny. Vyrábíme zkrátka software pro lidi a chceme, aby jim dobře sloužil. Že se přitom neobejdeme bez vysoké odbornosti – která mimochodem byla pro KOMIX vždy charakteristická – je samozřejmé… pokračování na další straně.

13 14 16 17 18 21 23 26

 /

Úvodník ředitele společnosti

 /

Sjednocení přístupu k základním registrům v rezortu Ministerstva spravedlnosti

 / Projekt GloNet – glokální podniková síť

 /

Nové občanské průkazy

 / Mobilní aplikace pro Vitalitas pojišťovnu

 /

Ověřování petic pro přímou volbu prezidenta ČR

 /

Nástroj QlikView pomáhá řídit výrobu v nadnárodní skupině SKB

 /

Služby BI s přidanou hodnotou pro společnost REDA

 /

QlikView: Finanční reporting jinak a lépe

 /

BSC a KPI – účinné nástroje pro měření a řízení výkonnosti podniků

 / Ilustrace využití jazyka R pro účely pokročilých datových analýz

 / Novinky na Portálu OZP ON-LINE  / SEMOS – security monitoring solution  / Testování interního a externího webu – v čem je rozdíl?  / Integrace s WSO2

 / Cyber-Ark v zahraniční praxi

 / Dáváme technologiím smysl aneb business consulting v KOMIXu 1

pokračování ze strany 1 Softwarové aplikace stále více určují podobu světa, ve kterém žijeme, a utvářejí novou podobu oborů jako je doprava, zdravotnictví, energetika, veřejná správa. A to nemluvím třeba o  telekomunikacích, finančním sektoru či zábavním průmyslu, ty totiž razantní proměnou umožněnou využíváním informačních technologií už dávno prošly. Organizace dnes disponují tera-, penta-, exa- či zettabyty dat, jež na ně chrlí podnikové informační systémy, inteligentní technologická čidla, platební systémy, mobilní telefony, digitální snímací systémy a další zdroje. Vypořádat se s  tímto ohromným množstvím dat není jenom výzva technologická, nýbrž také výzva intelektuální. Jak proměnit data na informace, jak z informací vytřídit právě ty, které jsou relevantní pro rozhodnutí, které je potřeba udělat v určitém kontextu tak, aby výsledek rozhodnutí byl žádoucí a optimální? Velmi se tak vzdalujeme od klasické podoby informačního systému, který na dobře popsaných a  strukturovaných datech prováděl operace dané definovanými algoritmy tak, aby dosáhl očekáva-

ného výsledku. Ve světě velkých dat – ano, neodpustím si módní buzzword – často hledáme zákonitosti či vzorce chování, o nichž dopředu nevíme ani jaké jsou, ani zda vůbec existují. Brodíme se záplavou nestrukturovaných dat a snažíme se vytěžit informace, které pro nás mají význam. Pro zaměstnance KOMIXu to znamená, že rozvíjíme svoji odbornost v  nových oblastech, jako jsou zpracování strukturovaných i nestrukturovaných dat, rychlé databáze a  paralelní zpracování dat, nástroje pro statistickou analýzu a  vizualizaci dat. Cíl je stále stejný – dát technologiím smysl, dát smysl také datům a informacím. Naše účast ve významných projektech, které jsem zmínil v úvodu, by nebyla možná bez dobře fungující spolupráce s našimi partnery, jakými jsou společnosti Atos, HP, IBM nebo QlikTech. Společně zrealizované projekty jsou nejlepším příkladem toho, jak lze ku prospěchu zákazníků skloubit technologickou vyspělost a  kompetenci globálního dodavatele s kreativitou a znalostmi lokální IT firmy. Nespoléháme ovšem pouze na produkty našich partnerů, nýbrž vyvíjíme i produkty vlastní. Velmi úspěšný je napří-

klad software pro elektronickou rizikovou analýzu (ERIAN). Jedná se o  univerzální expertní systém se znalostní databází spravovanou uživatelem. Správa rozhodovacích pravidel je zabezpečena tak, aby do systému mohli vybraní uživatelé vkládat pravidla důvěrného charakteru, která představují klíčové know-how příslušné organizace. Na Celní správě České republiky je tento systém schopen ve špičkách podle komplexních pravidel zpracovávat tisíce celních deklarací za hodinu. Další uplatnění našel ERIAN také v  oblasti finančnictví a KOMIX s ním uspěl i v mezinárodních projektech v Srbsku a na Ukrajině. Tento zpravodaj k vám přichází v nové grafické podobě a  s  novým logem. Po dvaceti letech jsme se rozhodli naše logo změnit tak, aby bylo nápadité, sympatické a  snadno rozeznatelné. Doufám, že se nám to povedlo a  že tak budete vnímat nejen naše logo, nýbrž i práci, kterou pro Vás odvádíme – nápaditou, kvalitní a smysluplnou. Přeji vám příjemné čtení. Tomáš Rutrle / Ředitel a jednatel společnosti KOMIX s. r. o.

Sjednocení přístupu k základním registrům v rezortu Ministerstva spravedlnosti

Z

 avedení základních registrů ve veřejné správě v  roce 2011 sjednotilo datovou základnu, kterou si do té doby budovala každá instituce samostatně. Vyvstal ale nový problém: „Jak na tuto jednoduchou strukturu napojit velmi rozmanitou množinu agendových informačních systémů (AIS), využívajících tato data k  podpoře vlastních pracovních procesů?“ Počet těchto systémů jde u některých institucí do stovek a stejně rozmanité dosud byly i technické způsoby jejich komunikace s jednotlivými evidencemi. Jak lze všechny tyto agendové systémy napojit na základní registry a nezvýšit přitom již tak obrovskou složitost struktury informačního systému?

Charakteristika zákazníka Jedním z  ústředních orgánů státní správy ČR je Ministerstvo spravedlnosti (dále také „MSp“), do jehož působnosti patří soudy, státní zastupitelství, Probační a  mediační služba a  vězeňství. Rezortní organizace tedy zahrnují soudy všech úrovní (nejvyšší a  vrchní soudy, okresní a  krajské soudy), 2

Dáváme technologiím smysl

»» »» »» »» »» »»

agendu probační a mediační, agendu registru rejstříku trestů, agendu okresních soudů, agendu krajských soudů, agendu vrchních a nejvyšších soudů, agendu všech stupňů státních zastupitelství, »» agendu vězeňské služby. Každou z  těchto agend podporuje jeden či více agendových informačních systémů, které požadují data ze základních registrů – registr obyvatel (ROB), registr právnických osob (ROS), registr územní identifikace, adres a  nemovitostí (RUIAN) a  registr práv a povinností (RPP).

státní zastupitelství (nejvyšší a vrchní zastupitelství, okresní a  krajská zastupitelství), Probační a mediační službu, Justiční akademii, Vězeňskou službu ČR, Institut pro kriminologii a sociální prevenci.

Výchozí situace zákazníka

Rezort justice zajišťuje 8 základních agend: »» agendu ministerstva spravedlnosti,

Ministerstvo spravedlnosti, stejně jako všechny další orgány veřejné správy, stálo před úkolem napojit na základní registry,

Resort justice Soudy IS n

IS 1

IS 2

Ministerstvo spravedlnosti

Rejstřík trestů

Státní zastupitelství

Vězeňská služba

Probace a mediace

Komunikační brána

Vnější rozhraní eGON ISZR

ROB

ROS

Obrázek 1 – Rezort justice

spuštěné do ostrého provozu 1. července 2011, veškeré agendové informační systémy všech rezortních organizací. Vedení rezortu přitom požadovalo takové řešení, které by minimalizovalo náklady na úpravy těchto aplikací a bylo natolik flexibilní, aby umožňovalo budoucí úpravy jednotlivých agendových systémů v  důsledku legislativních změn, aniž by bylo třeba neustále upravovat programové řešení rozhraní na základní registry. Komplikaci projektu představovala neustálenost základních registrů (v druhé polovině roku 2011 ještě probíhaly některé úpravy jejich webových služeb), dále potom nutnost spolupráce s  velkým počtem dodavatelů rezortních agendových informačních systémů.

Naše řešení Velkou výhodou společnosti KOMIX před jinými dodavateli byla prokázaná zkušenost s  podobným projektem u  stejného zákazníka – před 3 lety řešil KOMIX otázku,

RUIAN

RPP

ORG

Komunikační brána KMX_GTW pracuje důsledně na principu webových služeb s pevnou strukturou rozhraní definovanou ze strany registrů. Dalším jejím principem je sjednocení řízení přístupových práv, protože k  registrům již nepřistupují jednotlivé aplikace samostatně, ale prostřednictvím této komunikační brány. Celý projekt byl dodán v  potřebném rozsahu, požadované kvalitě a v určeném termínu. Realizační část byla spuštěna v únoru 2012, pilotní provoz v červnu 2012. Projekt byl ukončen v červenci 2012.

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

Podobně jako při prvním projektu se prokázaly hlavní výhody tohoto řešení v jednodušší správě celé IT infrastruktury (naše řešení posiluje jednotné prvky v  aplikačjak zajistit a zdokonalit komunikaci někoním prostředí rezortu), ve vyšší bezpečlika agendových informačních systémů nosti přístupů i možnosti ministerstva zíss  databází CEO (centrální evidence obykat přehled o komunikaci všech rezortních vatel). Řešení bylo postaveno na myšlence institucí (a těch jsou stovky) se základními jednotné komunikační brány, jakožto jedregistry. notného místa pro přístup k základním reNejvětší předností tohoto řešení je gistrům v rámci rezortu. MSp spolu s tímto jeho univerzálnost – princip komunikační řešením navíc získalo také přehled o  rozbrány mezi existusahu a  objemu jícími aplikacemi komunikace podNejvětší předností tohoto a  základními reřízených organizařešení je jeho univerzálnost. gistry lze použít cí, zjednodušení v  různých prosprávy aplikací středích, bez ohledu na množství a věcný a zajištění autorizace přístupů včetně vyšší i  technický charakter agendových inforúrovně zabezpečení. mačních systémů, tedy i u jiných institucí Koncepci jednotné komunikační bráveřejné správy. Toto řešení – ve srovnání se ny pro rezort justice použila společnost zdánlivě přímočařejším, ovšem technicky KOMIX i  v  tomto případě. Potřeba úprav podstatně těžkopádnějším uzpůsobením jednotlivých AIS se tak minimalizuje a zárovšech jednotlivých aplikací pro komunikaveň je ponechána maximální volnost jejich ci s registry – si vyžádá mnohem méně úsidalšímu rozvoji. Je snížena i jejich závislost lí, času a tedy i finančních prostředků. na případných změnách základních registrů (jejich webových služeb) – to vše se vyřeší pouze úpravami komunikační brány. Miloš Poláček / Projektový manažer

Nové občanské průkazy

S

polečnost KOMIX zajistila významnou část projektu nových občanských průkazů pro občany České republiky, vydávaných od ledna 2012. Odpovídala za návrh a implementaci softwarového jádra celého systému. Toto jádro zajišťuje komunikaci mezi několika stovkami výdejních míst na místních úřadech po celé republice, centrálními registry a státní tiskárnou cenin, státní podnik, která průkazy centrálně vyrábí.

Výchozí situace zákazníka Potřeba jednodušší komunikace občana s úřady, jakož i návaznost na projekt centrálních registrů veřejné správy vyvolaly změnu podoby občanských průkazů ČR. Nové, tzv. elektronické občanské průkazy (eOP) měly mít šikovnější formát kreditní karty a  obsahovat čip, umožňující nahrát 3

na tento průkaz elektronický podpis či výhledově další průkazy (např. řidičský průkaz nebo průkaz zdravotní pojišťovny). V  důsledku organizačních nejasností při přípravě mohl projekt začít teprve v srpnu 2011, přičemž nové občanské průkazy se měly začít vydávat již 2. ledna 2012. Zákazník, Ministerstvo vnitra ČR a  jeho hlavní dodavatel STÁTNÍ TISKÁRNA CENIN, státní podnik (dále jen „STC“), potřebovali vybudovat systém výdeje nových občanských průkazů včetně organizačního zázemí, výdejních míst v obcích (novinkou bylo např. pořizování fotografií žadatelů při podání žádosti), zajištění centrální výroby průkazů v STC a vývoj softwarové aplikace, která by tento systém řídila. To vše během cca 4 měsíců. Výhodou bylo, že pro vymezený úkol bylo možné využít existující infrastrukturu z podobného projektu CDBP (výdej nových pasů s biometrickými prvky).

Náš přístup – průběh projektu Společnost KOMIX se do projektu zapojila jako subdodavatel společnosti ATOS IT Solutions and Services, s. r. o. – hlavního dodavatele STC. Zatímco ATOS a  jeho další subdodavatelé zajišťovali zejména infrastrukturu a  integraci projektu, naším úkolem bylo vyvinout vlastní jádro systému – tj. příslušnou softwarovou aplikaci. Pro to, že si nás dodavatel k tomuto úkolu vybral, hovořily naše získané zkušenosti z předchozího podobného projektu – vydává-

ní biometrických cestovních pasů (projekt CDBP), kde jsme získali znalost agendy vydávání průkazů pro občany. Svůj úkol jsme stihli realizovat včas a v požadované kvalitě. Při realizaci jsme využili metod agilního programování včetně sestěhování celého realizačního týmu do jedné místnosti.

Výsledek – přínos pro zákazníka První pracovní den roku 2012 se začaly na několika stovkách míst po celé republice žádosti o vystavení nových občanských průkazů přijímat a následně zpracovávat. Tato skutečnost byla zaregistrována prakticky všemi médii. Kritizovány byly pouze dlouhé fronty v některých místech, způsobené delším odbavováním (fotografie byly pořizovány většinou až u přepážky) a také náporem lidí, kterým platnost občanského průkazu skončila již v závěru předchozího roku a kteří dostali jen dočasný doklad, aby si mohli pořídit občanský průkaz nový. Pro koncového zákazníka, Ministerstvo vnitra, byl úspěšný start tohoto projektu jedním z kroků na cestě ke spuštění centrálních registrů, které se uskutečnilo k 1. červenci 2012. Společnosti ATOS, našemu bezprostřednímu zákazníkovi v projektu, jsme pomohli splnit obtížný úkol, který bylo třeba realizovat v šibeničním termínu. Kolektiv autorů

Ověřování petic pro přímou volbu prezidenta ČR

H

lem MV ČR byla, kromě vlastní organizace voleb, také registrace prezidentských kandidátů na základě kontroly náležitostí kandidátních listin; u  kandidátů s petiční podporou voličů pak na základě kontroly platnosti údajů uvedených na petičních arších. Ověřování údajů z  prezidentských petic probíhalo automatizovaně ve dvou základních krocích. V  prvním kroku bylo provedeno naskenování petičních archů do digitalizovaných obrazů a stanoven celkový počet záznamů osob, které petici podepsaly. Následně byly náhodným výběrem z petičních archů zvoleny dva kontrolní vzorky obsahující záznamy 8 500 petentů. Tyto záznamy s informacemi o  petentech byly převedeny do datových vět a určeny k dalšímu ověření. Druhým krokem bylo ověření ztotožnění petentů s  údaji dvou kontrolních zdrojů: základního registru obyvatel (ROB) a informačního systému evidence obyva-

istoricky první přímá volba prezidenta České republiky se uskutečnila v  lednu roku 2013, do té doby byl prezident volen nepřímo, Parlamentem ČR. Češi tak poprvé získali možnost vybrat si novou hlavu českého státu, nástupce dosavadního prezidenta Václava Klause. Podle zákona o  přímé volbě prezidenta ČR může kandidáta na prezidenta navrhnout skupina minimálně 20 poslanců či 10 senátorů. Kandidátem se může stát i  jakýkoliv občan, který dosáhl věku 40 let a  jehož nominace je podpořena peticí podepsanou minimálně 50 tisíci voliči (petenty). A právě kontrola a  automatizované ověřování údajů na petičních listinách prezidentských kandidátů představovala nelehký úkol.

Charakteristika zákazníka Subjektem zodpovědným za organizaci, převzetí, zpracování a vyhodnocení kandidátních listin, jejichž součástí jsou i  petiční archy, bylo určeno Ministerstvo vnitra České republiky (dále jen „MV ČR“). Úko4

Dáváme technologiím smysl

tel (ISEO). Petenti zařazení do náhodně vybraných vzorků byli nejprve ztotožněni se záznamy v kontrolních zdrojích, následně bylo na základě údajů získaných z kontrolních zdrojů ověřeno naplnění zákonných požadavků na platnost záznamu na petici.

Výchozí situace Plněním zakázky „Automatizace ověření petice pro přímou volbu prezidenta“ byla pověřena společnost HEWLETT­ PACKARD s. r. o. (dále jen „HP“), která spolupracovala na zajištění jednotlivých fází projektu s dalšími subdodavateli. V  oblasti dodávky služeb zpracování petičních archů, skenování, stanovení celkového počtu záznamů petentů, vytvoření kontrolních vzorků a  převedení záznamů vybraných petentů do datových vět spolupracovala HP se společností Scanservice a. s. V oblasti vývoje, implementace a provozní podpory informačního systému Petice (dále jen „IS Petice“) pro podporu ověřování správnosti údajů obsažených v datových větách kontrolních vzorů byla partnerem HP společnost KOMIX s. r. o.

Naše řešení Úkolem společnosti KOMIX byl vývoj a implementace IS Petice, který řešil tři základní úlohy. První úlohou bylo tzv. ztotožnění petenta s osobou evidovanou v základním registru obyvatel (ROB) a informačním systému evidence obyvatel (ISEO). Tento krok byl proveden nejprve automaticky, pokud při ztotožnění nebyl zjištěn souhlas údajů, pokračovalo se manuálně, tzv. ztotožněním operátorem. Druhou úlohou bylo ověření platnosti záznamu každého ztotožněného petenta z  pohledu naplnění zákonem stanovených podmínek, což se dělalo také proti údajům z  kontrolních zdrojů dat. Petent musel nejpozději v  druhý den voleb dosáhnout věku 18 let, nesměl zemřít dříve, Archy petice Kandidát a jeho štáb

Skenováni

Kontrola, evidence, protokolární převzetí

IS Petice

Pracovníci zákazníka

Evidence, řízení a optimalizace zpracování

Obrazy stránek do IS Petice

Obrazy stránek ke zpracování

OCR

než mohl dle zákona započít sběr podpisů pod petice, musel mít právní způsobilost a  české státní občanství. Kromě toho byl ještě ověřován duplicitní výskyt stejného petenta v  rámci vybraného kontrolního vzorku každé petice. Třetí úlohou bylo zpracování statistik  – podkladů pro finální rozhodnutí MV  ČR, zda kandidát splňuje podmínky pro přijetí kandidatury či nikoliv. Rozhodnutí o kandidatuře bylo prováděno v souladu s postupem vyhodnocení kontrolních vzorků tak, jak jej definuje zákon o přímé volbě prezidenta. Ministerstvo vnitra bylo ve velmi nezáviděníhodné situaci, kdy čas na řešení, čas na celé zpracování dat petic, který nebylo možno prodloužit z  důvodu zákonných

Automatické ztotožnění

Základní Registr ROB

Manuální ztotožnění

Metadata archů petice

IS Evidence obyvatel

Ověření platnosti Výběr vzorků

Vybrané archy

Platní petenti

Pořízení dat vzorků Tvorba výstupů Data vzorků

Neplatní petenti

Neztotožnění petenti

Reporty, statistiky, podklady pro rozhodnutí

Odborní pracovníci zákazníka ROZHODNUTÍ O REGISTRACI

lhůt, a značný zájem veřejnosti vyžadoval maximálně efektivní, rychlé a sladěné kroky všech zúčastněných pracovních skupin. Navíc sbírané údaje obsahovaly osobní data jak kandidátů, tak i petentů, což vyžadovalo vyšší režim zabezpečení.

Hodnocení – přínos pro zákazníka Od začátku bylo zřejmé, že první přímé volbě prezidenta České republiky, resp. jí předcházejícím krokům, je nutné věnovat maximální úsilí, jak na straně ministerstva, tak na straně dodavatele služeb. Předpokladem byla úzká součinnost řešitelských týmů na všech úrovních. Pravidelné pracovní schůzky, okamžité vzájemné informování o všech aspektech, které by mohly mít vliv na zpoždění vůči stanovenému harmonogramu, denní kontakt pracovníků. Vedoucí pracovníci zapojených odborů ministerstva byli pod značným tlakem veřejnosti i médií. První přímá volba vyžadovala interpretaci nového zákona, který dosud nebyl použit, a celý postup vyhodnocení kontrolních vzorků musel být jednoznačný, prokazatelný, zdokumentovaný a auditovatelný. Podíváme-li se zpětně na dodané řešení a služby, zjistíme, že zejména profesionální přístup řešitelů a příkladná spolupráce zákazníka a dodavatelů, zajistily úspěšné dokončení zakázky, a  to nejen po stránce informatické, ale především splnění zákonných úkolů a termínů Ministerstva vnitra. Miloš Poláček / Projektový manažer

Obrázek 1 – IS Petice – schéma zpracování

Nástroj QlikView pomáhá řídit výrobu v nadnárodní skupině SKB

K

Charakteristika zákazníka  důsledkům globalizace patří spojování podniků z různých zemí do kapitálových nadnárodních skupin. Řádově větší rozměr podnikání znamená výzvu pro manažery: pro jejich rozhodování již nestačí přímá zkušenost „z terénu“, jak tomu bylo doposud v prostředí podniku střední velikosti s dlouhou tradicí, kde se všichni znali navzájem; mnohem více se musí orientovat v datech a číslech. K tomu je však třeba mít k dispozici nástroj, který zajistí sběr dat na jedno místo a umožní se na ně podívat požadovaným pohledem. To vše rychle a bez nutnosti zapojení programátorů. Není to tak jednoduché, jak se zdá.

PRAKAB PRAŽSKÁ KABELOVNA, s. r. o., výrobce energetických a telekomunikačních kabelů, je členem skupiny SKB, vlastněné rakouskou společností SKB Industrieholding GmbH. Společnost PRAKAB působí na evropském trhu jako výrobní centrum skupiny. Historie výroby kabelů v této společnosti, sídlící v Praze – Hostivaři sahá již do roku 1921. V  roce 1992 se stává součástí 5

skupiny SKB. Dnes je moderním průmyslovým závodem s více než 31 000 m² výrobních ploch, 360 zaměstnanci a patří k nejdůležitějším ve svém oboru. Skupina SKB má výrobní závod i  na Slovensku v  Nitře a  v  Kyjevě na Ukrajině, v posledních letech udržuje stálou expanzi.

Výchozí situace zákazníka Růst podniku i  celé skupiny v  posledním desetiletí (2005 – ustavení skupiny SKB a vybudování závodu na Slovensku, 2007 – výstavba nových výrobních hal v  Praze, 2008 – nová výrobní zařízení podstatně zvyšující výrobní kapacity) zvýšilo potřebnost kvality podkladů pro rozhodování vedení pražské společnosti i  celé skupiny v Rakousku. Jedním z opatření vedoucích k tomuto cíli byl záměr vybudovat manažerský informační systém, zpracovávající zejména data z výroby a prodeje. V květnu 2011 vypsala tedy pražská společnost výběrové řízení na řešení BI – MIS pro celou skupinu SKB.

Naše řešení Řešení společnosti KOMIX vycházelo z úspěšného postupu v jiných podobných případech: unikátní vlastnosti produktu QlikView nám umožnily velmi rychle pro zákazníka vyvinout a  v  praxi nasadit pilotní řešení, které bylo v  listopadu 2011 vyzkoušeno ve společnosti PRAKAB, kdy na serveru společnosti PRAKAB byly umístěny 3 pilotní aplikace pro 3 podniky skupiny. Pilotní projekt byl úspěšný, a  to

Obrázek 1 – Ukázka z aplikace PRAKAB QlikView

i  v  náročných podmínkách postupně se vyvíjejícího zadání. Poté, kdy se uživatelé mohli konkrétně seznámit s výhodami tohoto pilotního řešení, následoval návrh optimálního licenčního modelu pro celou skupinu, dále roll-out řešení oblasti PRODEJ na celou skupinu SKB Industrieholding, obsahující mj. lokalizaci v  ČR, Rakousku i  na Slovensku. Součástí projektu byla i migrace historických dat za poslední 3 roky.

Hodnocení – přínos pro zákazníka Provozní aplikace zákazníka získala díky této manažerské nadstavbě velkou hodnotu i  pro vedení společnosti, neboť nyní umožňovala hodnocení prodejů dle období, prodejců, zákazníků, druhu výrobků i nákladů na vstupní materiál a stavu skladů.

Projekt byl pro zákazníka zajímavý také z  toho pohledu, že cestou jednotlivých konkrétních kroků takto získal komplexní jednotné řešení pro celou nadnárodní skupinu (smluvním partnerem dodavatele byla od počátku mateřská společnost v Rakousku). Realizovaný projekt se zaměřil na zpracování dat z  výrobního provozního systému, tj. na sledování výroby, prodejů, pohybů materiálu, polotovarů a hotového zboží ve skladech. Vedení společnosti předběžně schválilo rozšíření záběru MIS i  na oblasti účetnictví, logistiky, atd.; realizaci těchto vizí v  současné době blokují vysoké ceny vstupních surovin (kovy) i další zákonitosti hospodářského cyklu odvětví. Pavel Seibert / Projektový manažer

Služby BI s přidanou hodnotou pro společnost REDA

J

 ​edno čínské přísloví praví: chceš-li nasytit bližního na jeden den, chyť mu rybu; chceš-li ho nasytit na celý život, nauč ho ryby chytat. Společnost KOMIX umí obojí – podle potřeb zákazníka. V projektu pro společnost REDA dokázala jednak implementovat základní řešení BI, jednak předat patřičné know-how tak, aby zákazník pokračoval v  rozvoji řešení vlastními silami, což výrazně snížilo celkové náklady na vlastnictví řešení (TCO).

Charakteristika zákazníka Společnost REDA a. s. se zabývá výrobou, prodejem a  potiskem reklamních a  dár6

Dáváme technologiím smysl

kových předmětů a  s  tím souvisejících služeb. Vznikla roku 1991 a  od té doby se vyvinula ve společnost, která se ročním

obratem přesahujícím 600 miliónů Kč řadí mezi nejvýznamnější hráče na trhu reklamních a dárkových předmětů nejen v České republice, ale i  v  Evropě. Sídlí v  Brně, kde vlastní rozsáhlý výrobní areál, má pobočky ve 4 českých městech. S  ročním obratem přesahujícím 600 miliónů Kč a  počtem 235  zaměstnanců patří mezi nejvýznamnější hráče na trhu reklamních a dárkových předmětů nejen v  České republice, ale i v Evropě. Společnost má dceřiné společnosti na Slovensku, v Polsku a v Číně.

Výchozí situace zákazníka Roku 2007 byl v celé společnosti zaveden provozní systém K2 (komplexní provozní informační systém). Tím byla vytvořena integrovaná základna pro zpracování dat z  různých oblastí činností společnosti. Se stabilizací tohoto provozního systému i se vzrůstajícím objemem dat, které postupem doby obsahoval, se pozornost vedení stále více zaměřovala na kontrolingovou nadstavbu, umožňující flexibilní zpracování různých dat a přípravu pro kvalifikovaná manažerská rozhodnutí, zejména v  oblastech vyhodnocování nákladů, výnosů a optimalizace stavu skladů.

Naše řešení V  roce 2011 se uskutečnil kontakt mezi představiteli obou společností. Specialisté

té společnosti KOMIX jsou stále k dispozispolečnosti KOMIX během několika dnů ci pro konzultace a náročnější technickou vyvinuli a  dodali zákazníkovi pilotní řešení podporu. založené na technologii QlikView (tzv. SIB – Seeing Is Believing). To potvrdilo očekávání zákazníka, takže spolupráce pokračovala Hodnocení – přínos pro zákazníka zakoupením licencí QlikView, vyškolením Spolupráce se společností KOMIX vytvořitýmu REDA pro práci s  tímto nástrojem la zákazníkovi podmínky pro jeho vlastní a  následné podpoře při napojení QlikView rozvoj; expertní znalosti a zkušenosti KOna data ze systému MIXu, jakož i  záSlužba BI jako integrální K2 a  dalších exterkladní řešení (naních zdrojů, jakož pojení datových součást know-how i následné přípravě struktur provozníanalytických řešení a reportů z oblasti finanho systému K2) představovaly základnu, cí, prodeje, skladů a dalších. na níž v následujících letech mohli zaměstProtože zákazník disponoval vlastnínanci zákazníka vystavět a rozvíjet řešení, mi kapacitami IT, byl zvolen model spokteré je dnes vnímáno jako integrální soulupráce založený na přenosu know-how. část know-how společnosti REDA. Veškerý další rozvoj řešení BI tedy probíhá v režii společnosti REDA, ovšem specialisTomáš Třmínek / Senior Sales Manager

QlikView: Finanční reporting jinak a lépe Třetím výkazem je výkaz cashflow, neboli výkaz o  pe inanční reporting je problematika, která něžních tocích, který zobrazuje trápí naprostou většinu firem. Jednak je skutečné příjmy a výdaje peněz potřeba podávat finanční výkazy státve firmě. ním orgánům a  jednak každého ředitele Skutečné hodnoty z  výše zajímá, jak si jeho firma stojí, ať jde o peuvedených výkazů je následně kárnu, soukromou kliniku, půjčovnu aut potřeba porovnávat s  plánem. anebo IT  firmu. Proto jsme se tématem K  původnímu plánu někdy přifinančního reportingu začali zabývat i my bývá i jeho aktualizovaná verze, v KOMIXu v QlikView týmu. V současnosti která se pravidelně upravuje na toto řešení využíváme nejen v naší společzákladě současných událostí. nosti, ale využívají ho i další firmy z oblasti Tuto aktualizovanou verzi lze telemarketingu, finančního poradenství sestavovat například za pomonebo bankovního sektoru. ci obchodního výhledu, neboli forecastu. Ten představuje obchodní příležitosti s  odhadem tržeb, příCo do finančního reportingu patří mých nákladů a  pravděpodobností, s  jaFinanční reporting je poměrně široký pokou se obchod podaří uzavřít. jem, a proto na dalších řádcích krátce shrPoslední zvláštní kategorií jsou klíčové neme, jaké výkazy do něj vlastně mohou ukazatele (zkráceně KPI neboli Key Perpatřit. formance Indicators). Na základě souboru Předně jde o  výsledovku, neboli výtěchto ukazatelů dokáže firma rychle vykaz zisků a  ztrát. Tento výkaz zobrazuje, hodnocovat, jak si stojí. Ukazatele si každá jaké měla firma tržby a  náklady ve zvolefirma volí, má pro ně nastavené metriky a cíném období členěné dle daného předpilové hodnoty, průběžně je sleduje a zjišťuje, su. Předpis je jednak zákonný (pro potřejestli se pohybují v  pozitivních či negativby účetní závěrky) a jednak si firmy často ních hodnotách, případně jaký mají trend. vytvářejí své vlastní manažerské pohledy. Dalším výkazem je rozvaha, která zobrazuje majetek firmy a  zdroje k  jeho Obvyklé problémy krytí. Člení se dle zákonného předpisu Málokterý účetní systém zahrnuje moža vždy zobrazuje stav k danému datu. nosti reportingu, případně když už je

F

obsahuje, jedná se často o  reporty velice jednoduché – ve formě tabulky, grafu či nějakého jednoho vypsaného čísla. Takovéto reporty bývají neobratné, špatně upravitelné a často jsou dodávané „tak jak jsou“, bez možnosti zobrazená data nějak dále analyzovat, filtrovat, rozebírat. Firmy se proto často uchylují k  exportu dat do Excelu, kde nad nimi nějaký šikovný IT specialista vystaví celý finanční reporting plný vzorců, maker a tlačítek. Je to nejčastější způsob řešení, a to i přes to, že skýtá mnoho problémů. První kategorie problémů by se mohla jmenovat „Jak na to?“. Reportu zpravidla rozumí jeho tvůrce (v lepším případě) a pak ten, kdo s reportem už aspoň čtvrt roku intenzivně pracuje. Ostatní stále tápou, kde, co a  jak hledat. Těžká ovladatelnost a malá srozumitelnost pak mohou ústit v množství vyrobených chyb, kdy aplikace neukazuje buď nic, anebo se tváří, že funguje, ale ukazuje špatně (což je možná ta horší varianta). Když už máme vytvořené řešení, ve kterém lze data alespoň jakž takž podrobněji analyzovat, dostáváme se do kategorie problémů „Co potom?“. Sem spadají otázky ředitele na IT specialistu typu: „Nešlo by tyto dvě položky místo sem sčítat tam a tuto položku z tohoto součtu oddělit a přičíst ji až tady?“. Odpověď většinou 7

zní: „Ne.“, přinejlepším: „Ano, ale…“ Tyto reporty většinou nejsou na nějaké dynamické měnění připraveny, takže každá změna znamená časově náročnou úpravu. Navíc čím větší změna, tím větší riziko, že se někde něco nenaváže, převáže, odváže a  celá aplikace se rozsype jak hromádka z karet, takže dát ji dohromady bude stát další hromadu času. Měnit tedy předpisy pro jednotlivé výkazy, případně mít pro jeden příkaz předpisů více, je při tomto způsobu reportingu tak náročné, že se to někdy ani nakonec nevyplatí dělat. Silnější stránkou Excelu se může na první pohled zdát možnost vytváření What­-If analýz, neboli analýz, kde si uživatel nějakou část dat namodeluje a  zbytek se dle toho dopočítá. Jelikož v  Excelu je dovoleno napsat cokoli kamkoli, neměl by to být problém – přepíše se pár vzorečků a  je to! Bohužel je tu stále hrozba vzniku nekonzistence dat, vzorečků, filtrů či všeho najednou, a to na jednom či více listech aplikace a pak už není vůbec těžké, aby se uživatel naprosto ztratil v  tom, kde je, co je skutečnost, co je namodelováno a  co z toho je vlastně správně.

objekty, které spolu nějak tematicky souvisí. To zvyšuje přehlednost a  srozumitelnost a usnadňuje ovladatelnost. Jelikož je výpočtový vzorec pro každý sloupec uveden pouze jednou, nemůže dojít k  tomu, že by se na některém řádku počítalo něco jinak než na jiném. Zároveň platí, že jakýkoliv výběr, který je v  aplikaci proveden, se promítne úplně do všech záložek v celé aplikaci, takže uživatel vždy na všech místech kouká na stejná data. Samozřejmě existuje možnost, jak tuto vlastnost potlačit, ovšem to jde o opodstatněné případy, kde je to opravdu potřeba. Aplikace nepracuje s  daty na harddisku, ale přímo v  operační paměti, která je mnohonásobně rychlejší. Reakce jsou proto stále bleskové i  při velkých objemech dat. Velké objemy dat jí zase dovoluje zpracovávat kompresní mechanismus, který data až pětinásobně zmenší. Díky tomu a  díky tzv. asociativnímu propojení dat je možné v  okamžiku přecházet z  agregovaných dat k  nejjemnějšímu detailu a zase zpět, nacházet souvislosti mezi daty, a rychle a snadno se tak dopátrat příčiny hledaného problému.

Klíčové vlastnosti řešení v prostředí QlikView

Vlastnosti jednotlivých reportů

QlikView tým společnosti KOMIX vytvořil sadu aplikací, které výše zmíněnou problematiku komplexně pokrývají: »» Finanční reporting – globální aplikace, která čerpá a  propojuje data z  účetního, mzdového a  projektového systému, v budoucnu bude čerpat i z obchodního systému. »» Obchodní reporting – detailně rozpracovává analýzu práce obchodníků a  zobrazuje výhledy na uzavření zakázek v  nejbližším období a  s  nimi spojené tržby a přímé náklady. »» Cashflow – speciální report pro analýzu cashflow. »» Plánování – speciální report pro analýzu plánu a pro pomoc při vytváření plánu nového. V  této části popíšeme klíčové vlastnosti celého řešení i jednotlivých reportů, a budeme tak postupně ukrajovat z výše zmíněných problémů.

Základním stavebním kamenem celé aplikace je manažerská výsledovka. Z té vychází většina výstupů. Aplikace umožňuje porovnání jednotlivých řádků výsledovky oproti plánu, zobrazení výsledovky pro jednotlivá oddělení a  za jednotlivé projekty. Uživatel může velice snadno a rychle pomocí množství filtrů dohledat konkrétní řádky z hlavní knihy, na kterých byly za-

Globální vlastnosti aplikace Každá aplikace je rozdělena do více částí (záložek), ve kterých jsou shromážděny 8

Dáváme technologiím smysl

Obrázek 5 – Cash Flow

účtovány „podezřelé“ transakce. Vybraný detail pak zanalyzuje a rozhodne, jedná-li se o  chybu, případně kde chyba vznikla, nebo alespoň zjistí, jak ji dále hledat. Zobrazení výsledovky po odděleních umožňu-

Obrázek 1 – Plánování

Obrázek 2 – KPI

Obrázek 3 – Forecast & What if analýza

Obrázek 4 – Finanční reporting

je vedoucím vidět výsledky svého oddělení, obdobně výsledovka po projektech umožňuje to samé vedoucím projektů. Velkou výhodou aplikace Finančního reportingu je, že je částečně řízena metadaty. Respektive je tak řízena struktura zobrazování dat. Pro strukturu manažerské výsledovky byl vytvořen řídící soubor, který jasně a přehledně znázorňuje, které položky se kam mají slučovat, a také jej lze snadno upravovat. Stejný mechanismus jako pro manažerskou výsledovku pak funguje i pro rozvahu a standardní výsledovku. Rovněž je možné mít předpisů pro stejný výkaz více a  členit si data různým způsobem. To se hodí například ve chvíli, kdy je potřeba mít data zobrazena dle různých účetních osnov (např. české, slovenské a konsolidační) nebo při potřebě více manažerských pohledů na výsledovku. Použití metadat rovněž umožňuje snadné znovupoužití aplikace v jiných firmách. Aplikace dále rozpočítává mzdové náklady dle hodin odpracovaných na projektech. Jinými slovy mzda zaměstnance, která je normálně účtována na oddělení, do kterého zaměstnanec patří, je přerozdělena mezi oddělení, na jejichž projektech zaměstnanec pracoval. Vše se samozřejmě děje v  agregované formě pomocí vypočtených relativních koeficientů, kterými se přenásobí čísla z  účetnictví, takže je nemožné dostat se ke mzdovým údajům konkrétních zaměstnanců. Dalšími klíčovými reporty v  aplikaci jsou reporty zobrazující KPI neboli klíčo-

vé ukazatele. Ty umožňuje aplikace vidět všechny přehledně najednou, je možné sledovat jejich stav i průběh. Report s  obchodním výhledem zobrazuje nejen informace o tom, jaké zakázky jsou rozjednané, jaký je na nich odhad celkových tržeb a přímých nákladů a jaká je fáze jejich dojednání (tzn. s jakou pravděpodobností to dopadne tak, jak je odhadnuto), ale také umožňuje podrobnou analýzu obchodní činnosti v  minulosti. Umí pracovat se změnami parametrů v  čase, takže lze porovnávat stavy ke dvěma rozdílným libovolným datům. Je možné takto sledovat výkony obchodníků, porovnávat prodejnost jednotlivých produktů či úspěšnost uzavření zakázky u jednotlivých odběratelů. Analýza Cashflow vychází z  přijatých a vydaných faktur a z dat obchodního výhledu. Na základě data splatnosti již vydaných či přijatých faktur, které však dosud nebyly zaplaceny, a údajů o tom, jaké další příjmy a výdaje firmu očekávají ve vybraném období, je sestaven přehled příjmů a  výdajů v  čase. Termíny příjmů a  výdajů je možno upřesnit na základě platební historie daného odběratele, respektive dodavatele dle libovolného algoritmu. Dále lze datumy úhrady pohybovat libovolně pomocí What-If analýzy, tzn. uživatel ručně nastaví, kdy budou vybrané faktury zaplaceny a jestli vůbec budou zaplaceny. Aplikace vše přehledně graficky zobrazí, a  dokáže tak uživateli poskytnout včasné varování o  blížících se problémech a  ná-

sledně mu pomůže při rozhodování o tom, co platit, co neplatit, kdy to platit a na které faktury si dát pozor, jelikož jejich nezaplacení by mohlo být kritické. Report pro plánování přehledně porovnává navzájem skutečnost s  plánem a minulým rokem. Tam, kde končí současná data, začínají data forecastu a  lze tak predikovat, jak se budou věci vyvíjet v nejbližší době. Pomocí What-If analýzy lze pozměňovat data budoucnosti a modelovat tak kýžené situace, což pomáhá k lepšímu určování cílů a priorit.

Výhled V  budoucnosti budou všechny aplikace dále rozvíjeny a  vylepšovány, předpokládá se implementace dalších částí aplikace Finančního reportingu. Především půjde o  integraci rozvahy, standardní výsledovky, analýzy cashflow a obchodních výhledů. S tím jsou spojené nové klíčové ukazatele, které tak bude možno sledovat. Potenciál finančního reportingu spatřujeme zejména v tom, že je pro všechny v  podstatě stejný, většina firem jej nutně potřebuje a  Excel jim už nestačí. Navíc je jednoduché z  celého „balíku“ finančních reportů vyčlenit jen ty, které zákazník potřebuje, anebo naopak poskytnout komplexní finanční reporting jako celek. Další otevřenou možností je prodej finančního reportingu jako komponenty do finančních systémů. Jan Kunst / Analytik BI

BSC a KPI – účinné nástroje pro měření a řízení výkonnosti podniků

M

ezi nejrozšířenější koncepty řízení výkonnosti  v podnikové praxi patří Balanced Scorecards (BSC). Důvodem využití tohoto konceptu je jeho strategické pojetí výkonnosti a  současně zaměření na hodnototvorné procesy, jejichž úspěšné řízení vede k  pozitivnímu vlivu na zákaznická a  finanční

Manažerský systém Balanced Scorecard BSC je strategický manažerský systém, který podniky používají především: »» k vyjasnění a převedení vize a strategie do konkrétních cílů, »» ke komunikaci a propojení strategických plánů a měřítek, »» k plánování a stanovení cílů a sladění strategických iniciativ, ke zdokonalení strategické zpětné vazby a procesu učení se.

měřítka výkonnosti. Nejdůležitější vlastností konceptu BSC je vertikální provázanost podnikových procesů a kaskádové členění cílů při využití cíleně vybraných KPI.

Koncept BSC lze účelně propojit s dalšími koncepty řízení výkonnosti (např. model EFQM, ABC, koncept EVA, benchmarking), a  využít tak jejich synergické efekty pro měření a  řízení hodnototvorného řetězce podniku. Základem konceptu BCS je strate9

Balanced Scorecard indikátor

cíl

indikátor

cíl

stav

EBIT

11,5 % 13 %

stav

trend

Počet nových produktů na trhu

4

3

Pohledávky po splatnosti 2013/12

90 %

Spokojenost s prac. podmínkami

80 %

75 %

Plán provozních nákladů

100 % 95 %

Spokoj. zam. s kulturou a hodnotami

80 %

85 %

Počet odborných článků v tisku

13

8

100 %

Produktivita na FTE – poměr 2013/12 105 % 104 %

Finance

Vize Strategie Cíle

Zákaznící indikátor

cíl

stav

Zakázkové krytí – plán

945

Počet nových zákazníků

10

Počet reklamací na zakázku Dodržení harmon. zakázek

ROI, EBIT

Finanční

Věrnost zákazníků

Inovace a růst

Zákazníků Přesná dodávka Perspektiva

Interní procesy

indikátor

cíl

stav

870,54

Fluktuace zaměstnanců

5%

4,2 %

8

In-time odezva Service Desku

99,5 % 97 %

0,30

0,20

Cena kanc. ploch na FTE (Kč ročně)

5 300

5 250

95 %

85 %

Spotřeba energie na m2 (kWh ročně)

180

179

Obrázek 1 – Příklad zobrazení BSC

trend

trend

trend

Doba trvání procesu

Kvalita procesu

Odborné vědomosti pracovníků

Interních procesů

Inovací a růstu

Obrázek 2 – Kauzální vztahy BSC

tace prosté tabulky dat. Co je ale naprosto gie, která se rozpadá do jednotlivých cílů „Všechna dobrá KPI zásadní: KPIs vyvolávají akce důležité pro přiřazených do čtyř perspektiv: finanční, musí iniciovat akci. řízení byznysu. zákaznické, interních procesů a  inovací. Zvolené indikátory musí být zaměMezi jednotlivými cíli v  perspektivách je Bezcenné je takové KPI, řeny na chování, ke kterému chceme kauzální vztah – to znamená, že splnění které při neočekávané změně motivovat, a  do oblastí, které nás předjednoho vede ke splnění druhého. nepřinutí někoho poslat email, nostně zajímají: jsou to procesy a faktoNázorným příkladem je následující zvednout telefon nebo vydat ry kritické pro byznys nebo které nejvíc obrázek. Rentabilita vloženého kapitálu potřebují zlepšení. Z  obchodního hleROI nebo zisk EBIT jsou klasickým hlavním se rychlým krokem diska by to měla být např. nejméně spocílem podniku. Pro dosažení tohoto cíle je hledat pomoc.“ kojená skupina klientů nebo nejvlivnější v dnešní době nezbytná orientace na záEric T. Peterson, autor The Big Book of segment trhu. kazníky jako firemní přístup. Snažíme se Key Performance Indicators tedy o  rychlejší uspokojování potřeb zákazníků, čehož dosahujeme zlepšováním Vertikální členění interních procesů. To má pozitivní vliv jak na kvalitu výrobků, tak KPIs by měly motivovat pracovníky ke konkrétní akci a ve svém důi na vývojové, výrobní a dodací lhůty. Předpokládá to ovšem, že sledku k žádoucím firemním cílům, např. ke snížení nákladů, počtu pracovníci jsou podporováni a správně motivováni a že systémy reklamací, závad nebo ke zvýšení prodeje, produkce, produktivity a procesy jsou dále rozvíjeny. či k urychlení cesty výrobku na trh. Vzhledem k tomu, že k dispozici máme knihovnu několika set možných indikátorů, je správný a cílený výběr KPI zásadní pro následné výsledky měření a jejich Klíčové indikátory výkonnosti přínosy pro rozhodovací proces manažerů. Pro dosažení cílů v rámci BSC se jako měřítka používají klíčové indikátory výkonnosti, což je nejčastější český ekvivalent pro obecně užívaný anglický termín Key Performance Indicators (KPIs). KPIs jsou fenoménem, který provází ve firmách většinu pokusů Generální ředitel měřit a řídit výkonnost firmy. Pro svoji relativní jednoduchost se používají často EBIT, ROI, Podíl na trhu, Růst produktivity, Obrátka zásob, Zisk po divizích i  jako solitérní nástroj bez vazby na výše sofistikované koncepty řízení výkonnosti, bývají také součástí ekonomických a provozních softwarových nástrojů. V  dalším Finanční ředitel Obchodní ředitel textu se proto budeme podrobněji věnoEBID, ø marže, % nových zakázek, EBIT, ROI, Vývoj pohledávek, vat tomuto atributu řízení výkonnosti. % problémových klientů, ø pracnost zakázky, Náklady na zpracování 1 faktury, Likvidita Hlavní myšlenkou KPIs, která zhodnoWin/Loss rate, Retention rate cuje jejich využití, je prezentace technických dat jazykem relevantním pro byznys, Vedoucí účtárny Marketing manager tzn. místo suchých čísel se používají výrazné grafiky a  agregované údaje: poměry, Počet vydaných Fa, Počet Fa zpracovaných, Návštěvnost webu, Míra konverze, ø náklad Pracnost 1 Fa, Počet Fa na FTE, na kampaň, Počet kontaktů na kampaň, % plnění podíly, sazby, procenta a průměry. KPIs svoPočet chyb na FTE market. rozpočtu jí konstrukcí podporují časové souvislosti a zdůrazňují změny a trendy místo prezenObrázek 3 – Příklady vertikálního člennění KPIs 10

Dáváme technologiím smysl

Pro jednotlivé úrovně řízení platí pravidlo diferencovaného vertikálního výběru: »» top management – obvykle se využívá cca 5–7 KPIs strategického charakteru, »» střední management – pracuje je stejným setem KPIs jako top management, k tomu má každý manažer 3–5 KPIs taktického charakteru podle typu útvaru, »» operativní management – sleduje především specifická provozní KPIs podle příslušné funkční náplně a  k  tomu vybrané indikátory vyššího typu. Důležité pravidlo při využití je klasické „méně je více“ – jednotlivá osoba by neměla mít ve své kompetenci více než 10 KPIs, protože při vysokém počtu lze jen obtížně zajistit řádné sledování a potřebné reakce.

Vlastnosti KPI Správná aplikace KPIs má důležité zásady, jejichž využití zajistí funkční výsledky. Každý jednotlivý indikátor by měl splňovat tato kritéria: »» Dostupnost: Pracnost a  náklady na získání dat musí být vyváženy přínosy, které užití KPIs následně přinese. »» Měřitelnost: Měření by měla být kvantifikovatelná tak, aby shrnutí a zobrazení bylo objektivní. »» Smysluplnost: Měření má konkrétní vztah k definovaným cílům a podporuje je. »» Včasnost: Efektivní rozhodnutí musí být založeno na informacích aktuálních v daném čase. »» Ověřitelnost: Data použitá pro výpočet KPIs musí být ověřitelná v přesnosti i vhodnosti pro daný účel. »» Přivlastnění: K  lepšímu výkonu přispěje, když každé KPI má svého „vlast-

níka“ – konkrétního manažera nebo tým, kteří jsou odpovědní za výsledky měření a mohou je ovlivnit.

Co hrozí při měření Hlavní úskalí systémů měření výkonnosti pomocí KPIs spočívají především v chybném zpracování a vyhodnocení dat. Může jít zejména o následující situace: »» Zpracovává se příliš mnoho dat: důsledkem může být nedostatek soustředění na skutečně klíčová témata pro řízení podniku. »» Měření probíhá příliš často: zbytečné úsilí, zbytečné náklady, malá přidaná hodnota. »» Příliš řídká měření: chybí včasné varování, a proto se potenciální problémy mohou objevit pozdě. »» Sběr zbytečně velkého množství dat: stejnou vypovídací schopnost provádí nízká efektivita zpracování.

Katalogový list KPI – výroba Kód KPI

AB 1235

Název

% dodržení výrobního harmonogramu

Definice

Měří do jaké míry je dodržován výrobní harmonogram.

Kalkulace

Zaměření

% Production schedule attainment

A = aktuální výroba (počet)

C = Aktuální výrobní čas

B = plánovaná výroba (počet)

D = Plánovaný výrobní čas

Výpočet

[ ( A / B ) × ( C / D ) ] × 100

Typ

složený výpočet

Trend

stoupající je pozitivní

Účel

Vyhodnotit dosažení výrobního harmonogramu a jeho přesnost

Úroveň

operativní

Cíl měření

kvalita

Typ měření

kvantitativní

Období pro sběr dat

týden

Obvyklá frekvence reportingu měsíc Datový profil

Integrita dat

vysoká

Možnost automatizace

doporučená

Omezení

obtíže mohou vznikat pokud výrobní harmonogram není jednoznačně definován a sledován

Vhodnost pro benchmarking

ano

Příklady hodnot

červená < 70 %, žlutá 70 – 90 %, zelená > 90 %

Poznámka

Cíle by měly být nastaveny při zvážení rizik a jiných neplánovaných situací, které mohou vzniknout během výrobního procesu a ovlivnit délku nebo objem výroby (např. neplánovaná údržba). Vysoká úroveň tohoto indikátoru ukazuje přesnost a efektivnost v dosažení objemu a času výroby.

Cíle

Obrázek 4 – Příklad karty jednoho KPI

11

»» Obsah měřených dat neodpovídá celkové strategii: to je aspekt, který je třeba nastavit na začátku procesu a pak případně i upravovat podle změn a vývoje klíčových procesů. »» Redukce obsahu dat: pokud dochází při výpočtu k  přílišné agregaci dat, může výsledek maskovat vliv na konkrétní události nebo trendy. Společnost KOMIX ve své aplikační praxi pro zákazníky využívá dlouholeté zkušenosti konzultačního a  aplikačního týmu v  oblasti BSC a KPI. Máme k dispozici rozsáhlou knihovnu KPIs, která má třídění jak podle jednotlivých cca dvaceti odvětví, tak i podle konkrétních funkčních oblastí: Finance, Účetnictví, Prodej, Nákup, Výroba a řízení jakosti, Lidské zdroje, ICT, Marketing a komunikace, Řízení projektů, Inovace, Služby aj. Ke tvorbě knihovny KPI jsme využili jak vlastní zkušenosti tak i mezinárodní zdroje, které fungují většinou na bázi sdílené uživatelské zkušenosti a hodnocení užitečnosti (např. www.kpilibrary.com, www.ap-institute.com).

lem, stanovíme vhodnou strukturu a obsah KPIs v návaznosti na BSC. Výstupem etapy návrhu jsou vypracované mapy BSC a jejich propojení s procesním modelem, KPI matice a Komunikační plán změny. Ve třetí etapě nastává implementace prostřednictvím konkrétního SW řešení. Konkrétní prezentační vrstva (tj. druh software) vyplývá především z možností a potřeb klienta, často bývá využíván aktuální ERP systém nebo se instaluje samostatná vrstva ve formě MIS, např. produkt QlikView, se kterým máme rozsáhlé referenční zkušenosti. Výstupem této etapy je fungující aplikace v pilotním provozu a příslušná programová dokumentace. Poslední etapu řešení je post-implementace, tedy období, kdy se má potvrdit správnost nastavení sytému BSC a  výběru KPI. Probíhá v ní revize celého nastavení, úprava interní legislativy a  nastavení procesů reportingu. Současně probíhá intenzivní komunikační program směrem k zaměstnancům a zaškolení příslušných uživatelů.

Schéma projektu Společnost KOMIX svým zákazníkům nabízí v oblasti měření a řízení výkonnosti podniků a  organizací komplexní služby obvykle ve formě samostatného projektu ve čtyřech fázích. Součástí základní analýzy potřeb klienta je As-Is analýza, identifikace problémů a  příležitostí, porovnání stávajícího stavu s  best-practice, výstupem je návrh modelu řízení výkonnosti a roadmapa implementace změny. V etapě návrhu řešení vytváříme strukturu BSC pro definované organizační jednotky, propojíme BSC s  procesním mode-

Závěr Při nabídkách projektů v  oblasti Performance Management se snažíme být vůči klientům velmi flexibilní v  rozsahu i  obsahu projektu. Vždy vycházíme z konkrétní situace, očekávání klienta, finančních možností a  rychlé pre-sales analýzy. Výsledkem pak je cílený produkt, který řeší definovanou problematiku a realizuje konkrétní přínosy podle projektu. Miroslav Bauer / Senior Business Consultant

Dáváme technologiím smysl aneb business consulting v KOMIXu

S

polečnost KOMIX na trhu působí již více než 20 let a za tu dobu si získala pověst spolehlivého dodavatele softwarových řešení pro státní i komerční sektor. Za dobu své existence přinesl KOMIX na český trh řadu zajímavých technologií, jako například produkty společnosti Mercury (nyní HP), CASE systém firmy Westmount, monitorovací nástroj Wily (dnes CA) a další. I díky těmto aktivitám si KOMIX u velké části trhu vybudoval pověst technologické společnosti.

Toto vnímání je správné, ale je to pouze jeden z  úhlů pohledu. Pokud se podíváme na projekty, které KOMIX realizoval zejména v  sektoru komerčních zákazníků, je zřejmé, že KOMIX řadě významných subjektů pomohl s řešením nikoli jen technologických, ale především obchodních a  provozních problémů. KOMIX pro subjekty, jako například Eurotel nebo ŠkoFIN, navrhnul souhrnně způsob jejich řešení a  následně řešení s  využitím IT technologií dodal. KOMIX tedy kromě dodávky technologií úspěšně nabídnul zákazníkům své know-­how. Tím naplnil nové motto společnosti KOMIX: DÁVÁME TECHNOLOGIÍM SMYSL. Řada našich zákazníků se již v minulosti přesvědčila, že KOMIX na rozdíl od některých IT společností není pouhým dodavatelem technologií či programátorských prací, ale společností, která chápe obchodní a provozní cíle zákazníka a rozumí jeho problémům 12

Dáváme technologiím smysl

a potřebám. Zákazníkům pomáhá naplnit jejich firemní vizi a dodává jim komplexní řešení. Žijeme v době, kdy se na trhu objevuje stále více nových a zajímavých technologií. Stále častěji se i  management společností potkává s anglickými slovy a výrazy, jako cloud nebo big data a se zkratkami jako ESB, SOA atd. Proč ale tyto věci do společnosti zavádět? Pomohou nám tyto výrazy opravdu zvýšit prodej, zajistit nějaké úspory? KOMIX se soustředí na potřeby a  obchodní cíle zákazníka. Aby tuto roli plnil co nejefektivněji a pomohl zákazníkům k ekonomickému růstu či například ke zvýšení kvality jeho služeb, rozhodl se v roce 2012 založit skupinu BUSINESS CONSULTING.

Náš tým a naše zkušenosti

silné a slabé stránky a najít cestu k dalšímu zlepšení a hospodářskému růstu. Za necelý rok se podařilo vybudovat tým Členové našeho konzultačního týmu seniorních business konzultantů, který porealizovali nebo se podíleli na významných krývá oblast procesního řízení (mapování projektech, jako je například řízení vývoje a zavedení), včetně identifikace a nastaveinformačního systému pro celní a  daňové ní KPI (performance management), dále řízení a  rizikové analýzy pro Celní sprákompetenci v  obchodním a  strategickém vu ČR, návrh informačního systému pro poradenství za využítí pokročilých anaIntegrovaný záchranný systém, v  oblasti lýz dat a  nestrukturovaných informací finančních služeb jsme realizovali data (advanced analytics – data mining, text mining projekty pro mining). Realizujeme detekci podvodného také podporu směPomáháme naplnit chování, predikce výřování strategického firemní vize a dodáváme voje zákaznického zározvoje společnosti ve komplexní řešení jmu pomocí časových vztahu k  rozvoji ICT. řad a  segmentace zá­ Konzultační tým je kazníků. Vylepšovali jsme také procesní také schopen pomoci s přípravou projektu řízení v  několika organizacích. Za jena financování ze strukturálních fondů EU. den z  nejvýznamnějších projektů, který Oddělení Business consultingu KOMIXu je má tým Business consultingu KOMIXu tedy schopno ukázat nezávislý pohled na v gesci, lze považovat projekt v Národní organizaci jako takovou, identifikovat její

technické knihovně (NTK), kde se definovala strategie rozvoje NTK, byla dodána agenda pro celorepublikovou správu elektronických informačních zdrojů nakupovaných z veřejných prostředků a vybudován manažerský systém pro sledování výkonnosti knihovny.

Závěr KOMIX tedy disponuje týmem, který umí pokrýt široké portfolio problémů svých zákazníků, a  to nejen z  oblasti vývoje a  dodávky software. Tím může KOMIX nabídnout komplexní řešení problému zákazníka. David Procházka / Sales and Marketing Director Martin Podveský / Senior Business Consultant

Ilustrace využití jazyka R pro účely pokročilých datových analýz vou dat v prostředí databázového serveru, které je pro zpracování, čištění, agregace atd. velkého objemu dat optimalizované. Uvedenou architekturu jsme využili i v prvním projektu, který jsme ve společnosti KOMIX s využitím jazyka R realizovali.

J

azyk R se stává v oblasti statistiky a pokročilých datových analýz (data miningu) fenoménem, který v současnosti stojí za pozornost. Pro vzrůstající oblibu R 1 lze najít několik důvodů. Patří mezi skupinu open source nástrojů, které v základní verzi nevyžadují licenční poplatky (GNU 3 licence), a je proto k dispozici široké odborné veřejnosti s širokou podporou. Jazyk R je velmi bohatý, současně má úspornou syntaxi a je důsledně objektově orientovaný. R komunita vyvinula plejádu specializovaných modulů pro řešení analytických úloh daného typu, ale také nadstavby, které umožňují realizovat typové úlohy i bez nutnosti programování. 2 Jazyk R je interpretem, tato vlastnost nicméně v době vzrůstajícího výkonu hardware není na obtíž 3 .

Souhrnný popis procesu analýzy

Určitým omezením prostředí R (v  základních verzích) je jeho „in-memory“ chování: výpočty probíhají v operační paměti počítače, která musí mít dostatečnou velikost. Tato vlastnost představuje omezení při zpracování velkých vstupních datových

souborů; konkurenční komerční produkty jako SAS EM nebo IBM SPSS modeler umožňují na pozadí mezivýsledky ukládat do dočasných souborů na disk. Jedna možnost, jak s uvedeným omezením pracovat, 4 je doplnit proces využití jazyka R přípra-

1 Zpracování vstupních dat (SQL)

3 Analýza a skórování (R)

2 Příprava dat pro analytický nástroj (SQL -> R)

Projekt, který jsme ve společnosti KOMIX realizovali, zahrnoval zpracování velkého objemu vstupních dat (stovky milionů řádků), jejich čištění, agregaci a  přípravu pro analytické zpracování jazykem R. Toto jsme realizovali v  prostředí MS SQL 2012. Úloha v jazyce R pak pracovala s předpřipravenými údaji, řešila vlastní analýzy a zápis výsledků analýz („skórování“) zpět do databáze MS SQL. Následně již prostředky SQL byla provedena finalizace zpracování,

4 Zápis výsledků skórování (R -> SQL)

5 Dodatečné

zpracování, příprava výstupů (SQL)

Obrázek 1 – Příklad procesu pokročilé analýzy dat s využitím jazyka R

13

včetně uplatnění omezujících podmínek a  příprava dat pro výstupní sestavy prezentované koncovému uživateli. Souhrnně lze tento proces popsat diagramem na Obrázku 1 z předchozí strany. Uvedená architektura představuje určité základní řešení, které se pro daný účel dobře osvědčilo, nicméně ho lze obměňovat, například lze posouvat hranici mezi R a  SQL co se týká datového zpracování. Kritériem zde může být objem vstupních dat – ve zmíněném případě byl jejich objem tak velký, že jsme upřednostnili základní zpracování v prostředí SQL.

Příklady zpracování v jazyce R Pro načtení vstupních dat do prostředí jazyka R jsme využili modul RODBC umožňující propojení na MS SQL prostřednictvím ODBC. Následující fragment kódu představuje vytvoření přípravné tabulky r_regrese1, do které budou později ukládány skórovací hodnoty regrese: # Vytvoření napojení na MS SQL require (RODBC) channel <- odbcConnect („local MSSQL“,uid=“abc“,pwd=“abcpassword“) # Vytvoření prázdné tabulky r_regrese1 sqlQuery(channel,“begin try drop table r_ regrese1 end try begin catch end catch“) sqlQuery(channel,“create table r_regrese1 (Kod int, R2 float, Model nvarchar(max))“)

Jako příklad načtení údajů z  MS SQL do prostředí R uveďme možnost načíst do proměnné „seznam“ v prostředí R vybraný obsah tabulky ta_pripady: #Vytvoření seznamu odborností, pro které se budou počítat percentily seznam<-sqlQuery(channel,“select distinct Kod from ta_pripady where isnull(Kod,‘‘) <> ‚‘“) Následující fragment kódu umožní získat regresní model a  provést skórování – zápis výstupů daného modelu zpět do databáze MSSQL (ilustrativní příklad – nejsou ošetřeny všechny logické vazby): # analýza – návrh regresního modelu regrese<-lm(Hodnota ~ prediktor1+ prediktor2+prediktor3 ,data =vals) # sumarizace výstupů mdlout <-summary(regrese) R2 <- mdlout$adj.r.squared Model <- capture.output(mdlout) #určení skórů pro všechny případy predikce<-predict(regrese, newdata=vals) #zápis skórů pro všechny případy for (i in 1:length(predikce)) {sqlQuery (channel,paste(„insert r_regrese1_predikce values („,vals$klic[i],“,“,predikce[i],“)“,sep=““))} V  uvedeném ilustrativním příkladu obsahuje tabulka r_regrese1_predikce predikované hodnoty (skóry) na základě

modelu „regrese“ realizovaného v  jazyce R. Proměnné R2 a  Model, které jsou rovněž naplněny, se mohou ukládat do jiné databázové tabulky a s jejich využitím pak provést vyhodnocení parametrů modelu a dokumentaci již mimo prostředí R.

Závěr V článku jsme hovořili o „jazyce R“ a uváděli ilustrativní příklad jeho propojení s prostředím relační databáze. Základní prostředí jazyka R dnes nabízí řadu modulů, které základní vlastnosti značně rozšiřují. Rodina modulů R obsahuje bohaté možnosti práce s  grafikou, testování a  výběr nejvhodnějšího modelu atd. Svou zralostí představuje plnohodnotný nástroj pro využití v oblasti statistiky a data miningu. Martin Šály / Business Senior Consultant

1  Svr.

například průzkum specializovaného serveru kdnuggets dostupný na adrese: http://www.kdnuggets. com/polls/2012/analytics-data-mining-programminglanguages.html. 2  Jako příklad uveďme moduly rattle nebo Rcommander. Široké portfolio modulů je dostupné s  možností jednoduché instalace prostřednictvím sítě serverů s  názvem „cran“. 3  R umožňuje i  multiprocesorové zpracování. Úplná optimalizace pro multiprocesorové zpracování je ovšem k dispozici ve vyšších (placených) licencích Enterprise. 4  Vyšší licence jazyka R toto omezení překonávají, také v základní licenci existují moduly, které se snaží toto omezení obcházet, jejich využití ovšem vývoj komplikuje.

Projekt GloNet – glokální podniková síť

V

 poslední době lze spatřit ve výrobě přechod k produktům přizpůsobitelným individuálním požadavkům zákazníků a s nimi související nabídce doplňkových služeb, které toto přizpůsobení zajišťují. Tyto produkty zahrnují mnoho různých vlastností a potřebují zdroje, které jsou málokdy k dispozici v jednom podniku. Pro kompletaci vyžadují často spolupráci více subjektů. Komplexní multidodavatelský produkt s  vysokým stupněm přizpůsobení zahrnuje přidružené služby (např. podpora údržby, asistenční průvodci atd.). Již při přípravě nabídky dochází k zapojení zákazníků do vytváření detailní definice a konfigurace produktu, porovnání variant či do modifikace navržených řešení. Důležitými termíny, které vystihují principy spolupráce, jsou co-creation a co-innovation.

Poskytnutí adekvátní ICT podpory evropským malým a středním podnikům (SME) může znamenat konkurenční náskok před výrobci z jiných regionů, kteří jsou zaměřeni na masovou výrobu standardizovaných produktů. Překonání ekonomické krize vyžaduje, aby se společnosti soustředily na export, a  to především do roz14

Dáváme technologiím smysl

víjejících se trhů, jakými jsou Brazílie, Rusko, Indie, Čína. To je ovšem pro SME složité, pokud podnikají samostatně, a možnost vstoupit na trh v rámci spolupracující nadnárodní skupiny dodavatelů může jejich vstup na zahraniční trhy značně usnadnit.

Cíl projektu

GloNet je výzkumným projektem Evropské Unie, spolufinancovaný Evropskou komisí v  rámci programu ICT FP7. Cílem je vytvoření glokální podnikové sítě zaměřené na zákaznickou spolupráci. Pojem glokální označuje propojení globálního podnikání s lokálními dodavateli a zákazníky. Projekt začal v září roku 2011 a jeho konec je naplánován na září 2014. GloNet zkoumá pokroky ve využití internetu a  souvisejících služeb cloud computingu, zejména v oblasti podpory obchodních procesů a podnikání na internetu. Vyvíjí platformu, která bude na

Service provision space

Collaborative solution space (co-creation playground)

(along PLM)

Deploy Product design

Cyber space

konci projektu připravena nabídnout podnikatelům prostor pro nové příležitosti v  podnikání a  obchodu pomocí služeb internetu. Výzkumný úkol je zaměřen na identifikaci služeb nezbytných pro vytvoření komunikační platformy, která podpoří obchodní operace virtuálních podniků a  nabídne prostor pro inovativní činnosti. Jako typické podnikatelské oblasti, ve kterých má smysl aplikovat uvedené koncepty, byly zvoleny solární elektrárny (typický příklad podnikání, kde se kombinuje spolupráce mezi firmami zajišťujícími výrobu technologií, výstavbu elektrárny, zákazníkem a firmami, které se následně starají o podporu provozu) a inteligentní budovy.

Product model + support services

Cloud-based pool of resources

Společnost KOMIX je členem sedmičlenného konsorcia sestávajícího z obchodních společností a akademických institucí. Obchodní společnosti jsou zastoupeny institucemi z Německa, Dánska, Španělska a České republiky, akademickou část týmu tvoří univerzity z Portugalska a Holandska. Projekt spojuje odborné znalosti a  schopnosti zastupujících členů realizačního týmu, především v  oblastech collaborative networking, servisně orientované architektury (SOA), Cloud computingu, obchodních procesů (vč. BPM – Business Proces Modeling), Knowledge managementu (KM) a řízení vztahů se zákazníky (CRM).

Physical space

Konsorcium projektu Local supplier

Customer

Geo-region A

Pool of European Manufacturers

Geo-region B

Obrázek 1 – Ekosystém GloNet

Základní struktura aktivit a výstupů projektu Pracovní balíky projektu GloNet lze rozdělit do následujících skupin: »» analýza požadavků, definice hlavních scénářů, návrh základních konceptů, stanovení pojmů, architektura systému založená na službách (SOA), definování poskytovaných služeb a funkcí, návrh datových rozhraní a datového modelu, »» rozvoj softwarové platformy a realizace navržených funkcí, »» vytvoření pilotního řešení v oblasti solárních elektráren a inteligentních budov, »» diseminace a  exploitace, tj. šíření myšlenek projektu GloNet ve sféře akademické a podnikatelské, využití výstupů projektu a snaha o nastartování dalších navazujících aktivit, »» technická integrace a řízení projektu.

Základní koncept řešení GloNet má za úkol poskytnout takové ICT řešení, které podporuje mobilitu malých a středních podniků, na které výzkum projektu cílí. Jednou ze základních myšlenek projektu je podpora dvou typů spolupráce: »» dlouhodobé (trvalé) spolupráce mezi subjekty, které jsou angažované v dané oblasti businessu; pro tento účel jsou definovány tzv. Virtual Breeding Environments (VBE), »» krátkodobé spolupráce zaměřené na dosažení konkrétního cíle, jakým může být např. společný vývoj nového produktu/ služby nebo zajištění podpory konkrétnímu zákazníkovi; k tomuto slouží tzv. Virtual Organizations (VO).

Hlavní funkční oblasti Vytvořené softwarové řešení pokrývá následující oblasti funkcí a služeb: »» základní správu kolaborativního prostoru Virtual Breeding Environment (VBE) (členové a jejich profily, kompetence, hodnotový systém, výkonnostní ukazatele, skupiny), »» podporu pro zajištění důvěry mezi partnery, analýza společného hodnotového systému a odhalování potenciálních konfliktů, »» podporu hledání partnerů, navazování vztahů a  uzavírání smluv, »» podporu vzniku a  existence krátkodobých konsorcií, do kterých se typicky zapojují zákazníci a lokální dodavatelé, »» řízení rizik spolupráce.

Platforma a ICT nástroje Platforma je založena na technologii cloud computingu, tj.  poskytuje software jako službu, ke které má uživatel přístup pomocí internetu. Zvolený způsob umožní větší pružnost a propojitelnost zdrojů spravovaných virtuálních podniků a  usnadní vytváření podnikatelských ekosystémů třetími stranami, které jsou schopny vytvářet přidružené sítě, vytvářet nové virtuální podniky bez jakéhokoliv většího technického zásahu IT profesionála. Základem platformy je řešení firmy CAS – výrobce CRM systémů, které je rozšířeno o  nové vlastnosti definované projektem GloNet a pomocí webových služeb propojeno s dílčími aplikacemi, které zajišťují některé specializované funkce. Cílem je maximální využití open source technologií a standardů (např. OSGi). 15

Závěr Projekt GloNet řeší otázku, jak lze pomocí inovativních internetových služeb podpořit podnikání malých a středních podniků a  jejich expanzi na zahraniční trhy. Je zřejmé, že potenciál technologií cloud computingu a  SaaS není zcela využit. Využití brání převažující obavy ze ztráty nebo zneužití citlivých dat, z kybernetických útoků na internetové aplikace nebo z  nedostatečného připojení k  interneto-

vým sítím, které nedosahuje ve vybraných státech Evropské Unie, potažmo dalších evropských či světových státech, takové úrovně, jaká by byla potřebná pro úspěšnou implementaci takovéto komunikační platformy do fungování organizací, zákazníků a spotřebitelů. Proto i  myšlenka GloNetu s  sebou může nést značná rizika při její implementaci a  akvizici nových uživatelů/zákazníků. V  rámci Evropské Unie, kdy v  tuto chvíli

nejsou sjednocené legislativní rámce, např. při výběrových řízeních, v  oblasti kybernetické bezpečnosti či jednotné obchodní zvyklosti, které se často liší stát od státu, se může zdát myšlenka takovéto „nadnárodní businessové sociální sítě“ značně složitě uskutečnitelná v podmínkách, které panují např. na českém trhu. Petr Sobotka / Projektový manažer Vít Kovařík / Marketingový specialista

Mobilní aplikace pro Vitalitas pojišťovnu

J

pojištění se v  průběhu let ale mohou měnit, hlavně co se týká výše jejich ceny. A  samotný výpočet pojistného není úplně jednoduchý. Kromě stáří klienta, typu cesty (služební/ turistická) a  destinace (Evropa/ svět) jej ovlivňují i příspěvky a tarify pro pojištěnce partnerských zdravotních pojišťoven. Bylo tedy nutno celý výpočet provádět na serveru a  stranu klienta používat pouze na zadávání dat. Toto řešení také umožňuje nastavovat parametry výpočtu na jednom místě jak pro mobilní, tak pro internetovou aplikaci. Není úplně pravda, že data jsou přes aplikaci pouze odesílána na server. Do mobilu je přeci jen ukládán důležitý výstup, kterým jsou kartičky pro dané pojistky. Díky tomu jsou k dispozici i bez přístupu na internet. Výzvou bylo i samotné propojení aplikace s  platební bránou České spořitelny, a. s. Zde je nutné vyhodnocovat úspěšnost či neúspěšnost platby a podle toho reagovat a umožnit opakování platby pro úspěšné ukončení sjednávání touto či jinou ces-

elikož se trend pomalu, ale jistě posouvá ze světa stolních počítačů do světa mobilních přístrojů, nechceme ani my zaspat dobu. Proto bylo naší snahou i na tomto poli ukázat, že pro nás mobilní technologie nejsou problémem. Nabídli jsme našemu dlouholetému zákazníkovi Vitalitas pojišťovně, a.s. rozšíření způsobu uzavírání pojistek o mobilní prostředí. Konkrétně nativní aplikaci pro platformu Android ve variantě online pro sjednání pojištění s offline částí pro zobrazení pojistných kartiček. Tato nabídka byla s nadšením přijata a my jsme se mohli vrhnout do díla.

Jedná se o  zdánlivě jednoduchou aplikaci pro sjednávání cestovního pojištění. Je možné si vybrat pojištění na krátké cesty nebo dlouhodobé pobyty a pro vášnivé lyžaře je připravené specializované pojištění zimních sportů. Cesta k uzavření pojištění je velmi rychlá. Zadají se základní údaje o zahraniční cestě a pojištěných osobách. Aplikace poté zašle pojistnou smlouvu a  další náležitosti e-mailem. Pro pohodlí klienta je asistenční kartička uložena přímo v mobilu. Aplikace mu umožňuje i online platbu pomocí platební brány České spořitelny, a. s. A je zde samozřejmě možnost přečíst si přímo v mobilu Všeobecné podmínky uzavíraného pojištění.

Co bylo nutné řešit a jak jsme to řešili Jak bylo v úvodu uvedeno, jedná se zdánlivě o  jednoduchou aplikaci. Podmínky 16

Dáváme technologiím smysl

tou. I  zde informace o  úspěšnosti plateb funguje na straně serveru a aplikace pouze reaguje na jeho podněty. Nemalou výzvou byl i grafický návrh. Nejdříve bylo nutné rozmyslet rozsah jednotlivých obrazovek a  vyhodnotit jaké všechny komponenty budou použity. Poté vznikl grafický manuál, který obsahuje informace o  tom, jaké obrázky budou pro jakou komponentu použity jako podklad. Dále byla vytvořena sada ikon pro jednotlivá tlačítka a funkční prvky. Bylo potřebné ošetřit samozřejmě i  další věci. Drobnosti typu: jak posouvat data při zadávání intervalu od, do, když je tu ještě třetí možnost změny, kterou je celkový počet dní. Nebo ty těžší, jako je ukončování aplikace (zde bylo nutno nejdříve odstranit historii veškerých kroků a pak teprve ukončovat); Ošetřit hlášením chování aplikace při výpadku spojení; Zajistit možnost ukončení platnosti dané verze aplikace, pokud by došlo ke změnám produktů v  rozsahu, který by již neumožňoval řádně sjednat pojištění. V  takový moment je potřeba, aby klient nemohl nové pojištění sjednávat. Tato věc byla ošetřena změnou funkčnosti tlačítka, které u neplatné verze aplikace (dáno parametrem v  databázi)

pouze zobrazí hlášení o neplatné verzi. Zároveň musí být klientovi umožněno zobrazit kartičku k již sjednanému pojištění, což bylo umožněno posunem kontroly platnosti aplikace až na tlačítka přistupující do sjednávací části.

Závěrem Cesta k mobilním aplikacím je možná různými způsoby a pro každou aplikaci je určitě potřeba správně vybrat vhodnou variantu řešení. V našem případě si myslíme, že jsme zvolili správně i z toho pohledu, že

na to, kolik někdy i  nečekaných úkolů se na nás v  průběhu realizace vyrojilo, byly všechny úspěšně vyřešeny. Miroslav Benkovský / Databázový specialista

Novinky na Portálu OZP ON-LINE

R

ok 2013 byl pro Portál OZP ON-LINE ve znamení stabilizace provozu a  zaplňování „mezer“ chybějících aplikací. Další vlaštovkou v integraci s externími portály a webovými aplikacemi bylo napojení na cestovní pojištění Vitalitas. Dále byla implementována nová verze Přehledu OSVČ ve zcela novém kabátě i  technologii. V  souvislosti s  tím byl proveden úspěšný zátěžový test této aplikace. A  ještě před zveřejněním těchto novin bude na portále uvedena do provozu aplikace pro podrobné zobrazení platební bilance zdravotnických zařízení.

Propojení na cestovní pojištění Vitalitas Cestovní pojištění Vitalitas je nyní pro klienty Portálu OZP ON-LINE a  jejich blízké osoby dostupné skutečně jen na pár kliknutí. Nejprve je na Portálu OZP ON-LINE potřeba vybrat ze seznamu osob (zástupů). Poté jsou všechny potřebné osobní údaje bezpečně předány z  Portálu OZP ON-LINE aplikaci cestovního pojištění Vitalitas, stačí pouze doplnit počet dnů a „typ cesty“, zkontrolovat údaje a provést platbu – třeba online platební kartou.

Nový přehled OSVČ a zátěžový test Staronová aplikace pro podání přehledu OSVČ v roce 2013 byla realizována bez „formulářových technologií“, tentokrát s  běžným formulářem v  html. Propagace použití aplikace byla ze strany OZP podpořena výzvou k  elektronickému podání přehledu v  přímé komunikaci OZP s  pojištěnci OSVČ a marketingovou kampaní.

Vzhledem k  očekávanému velkému vytížení nejen portálové aplikace pro podání přehledu OSVČ, ale i celého systému v úzkém časovém intervalu, bylo rozhodnuto ověřit propustnost celého systému zátěžovým testem. Pro provedení zátěžového testu byl použit nástroj Apache JMeter. Virtuální uživatelé tohoto nástroje simulovali činnost reálných uživatelů.

dů za hodinu bylo už vytížení procesorů aplikačního serveru kolem 90 % a hrozilo přetížení jednotlivých jader. Úzkým místem celého systému byl identifikován aplikační server, na úrovni middleware to byl WebLogic AS. V souladu s vyhodnocením zátěžového testu byly následně optimalizovány (posíleny) parametry infrastruktury komponent systému portálu. Špičky užití aplikace byly úspěšně překonány a  podání přehledů OSVČ proběhlo v roce 2013 zcela hladce.

Platební bilance zdravotnických zařízení Nejnovější aplikací na Portálu OZP ON-LINE je zcela nová aplikace „Platební bilance“, která v  prostředí webového prohlížeče poskytne poskytovatelům zdravotních služeb aktuální, přehledné i  podrobné informace o  jejich platební bilanci, tedy zejména o  fakturách/ zakázkách a  jejich stavu zpracování. Aplikace je přístupná klientům Portálu OZP ON-LINE, vystupu-

Zátěžový test ověřil, že aplikace je připravena na předpokládanou roční špičku 1  500 přehledů/hodinu. Jako mezní hodnotu pro běžný provoz jsme vyhodnotili 2 000 přehledů za hodinu. Při tomto zatížení bylo vytížení procesorů aplikačního serveru na 70 %. Při zatížení 2 500 přehleObrázek 3 – Formulář podání Přehledu OSVČ

Obrázek 1 – Výběr osob pro cestovní pojištění

Obrázek 2 – Rekapitulace před sjednáním cestovního pojištění

Obrázek 4 – Zatížení při referenčním běhu

17

Obrázek 5 – Graf dob odezev na uživatelském rozhraní

jícím v roli poskytovatele zdravotních služeb a  autentizovaným na Portálu ZP. Pro všechny ověřené uživatele – klienty Portálu ZP v roli zdravotnického zařízení – je aplikace jednotná. Dílčí služby portálové aplikace „Platební bilance“ byly řešeny formou prezentace tabulkových výstupů a zprostředkují uživatelům informace o  proplacených zdravotních službách ze čtyř pohledů: »» pohled účetní – pohled na faktury/zakázky jako celek,

Obrázek 6 – Platební bilance

»» pohled dle data poskytnutí služby  – pohled na služby poskytnuté v daném období, »» pohled na doklady – pohled na podrobné informace o  dokladech vyúčtovaných zakázek, »» přehled záloh / doplatků / srážek / vratek.

Technická podpora Součástí námi poskytovaných služeb je vedle rozvoje i  kompletní technická podpora. V roce 2013 zahrnovala servis 7 × 24,

tj.  nepřetržitý dohled včetně nocí, víkendů a  svátků od našich správců. V  rámci podpory byl dále vypracován havarijní plán včetně návrhu rozvoje dalšího zabezpečení systému a  aplikačního prostředí Portálu OZP ON-LINE. V této oblasti jsme dále zapracovali na vylepšení správy systému a  její automatizaci – realizace automatických odstávkových oken systému, optimalizace parametrů jednotlivých prostředí, posílení robustnosti a odolnosti systému atd. Všech uvedených úkolů jsme se zhostili velmi dobře.

Výhled na další období V  následujícím období očekáváme na Portálu OZP ON-LINE doplňování dalších aplikací, integraci s okolím a možná nás bude čekat výměna nejslabšího článku řešení – náhrada WebLogicu za JBoss. Martin Lipš / Vedoucí oddělení ZP

Semos – security monitoring solution Monitorování a vyhodnocování stavu bezpečnostních parametrů IT systémů

O

rganizace a  obchodní společnosti musí často vykonávat svoji činnost v  souladu s  různými bezpečnostními normami a předpisy (požadavky regulátora, normy ISO, podnikové směrnice), které stanovují či doporučují nastavení konfigurací operačních systémů, databází, aplikací atd. (dále jen „IT systémy“). Určují tedy, za jakých podmínek by IT systémy měly pracovat. Jaký je ovšem skutečný stav jejich konfigurací? Jak byla aplikována bezpečnostní politika? Na to nám odpoví pravidelné monitorování stavu IT systémů.

»» Správu, řízení monitorování a  sběr dat z  IT systémů včetně uchovávání jejich historie. »» Vyhodnocování získaných hodnot bezpečnostních parametrů, notifikace správcům IT systémů. »» Přípravu podkladů pro audit bezpečnosti.

KOMIX se této problematice věnuje od loňského roku, kdy pro významnou českou banku připravil studii „Cross platform baseline monitoring“. Studie vznikla na podporu nově vzniklého oddělení Security Operation Center a navrhla jeho organizaci, podpůrné procesy a přinesla i základní návrh IT řešení. Na základě této studie se KOMIX rozhodl pro vytvoření vlastního produktu. A  tak vznikl v létě roku 2013 SEMOS. Co přináší?

Východisko

SEMOS je řešení, které zajistí soulad skutečného nastavení IT systémů s  platnou bezpečnostní politikou. Podporuje tyto procesy v organizaci: »» Definici a  správu politik pro monitorování konfigurací IT systémů.

Během studie jsme vycházeli zejména z  doporučení CIS (Center for Internet Security), což jsou uznávaná doporučení pro nastavování bezpečnostních parametrů IT systémů. Jejich cílem je maximálně systémy zabezpečit, tj. například zajistit, aby byly vypnuté nepotřebné služby, aby

18

Dáváme technologiím smysl

přihlašovací práva byla správně nastavena atd. Doporučení jsou popsána poměrně detailně, lze podle nich přímo bezpečnostní parametry nastavit. Kromě doporučení CIS se jako zdroj pro nastavení bezpečnostní politiky používají např. Common Criteria, dále se také vychází z legislativních požadavků, firemních/ skupinových směrnic či zkušeností z praxe.

Bezpečnostní parametry Bezpečnostní politika obsahuje konkrétní opatření, kterými se jednotlivé IT platformy mají řídit. Tato opatření specifikují nastavení konkrétních parametrů IT systémů. Těch jsou většinou desítky až stovky a lze je

COMPARE & EVALUATE & NOTIFY

Security Operator CIS Benchmarks Common Criteria

Security Monitoring Solution

SET EXCEPTIONS

Report for audit

Auditor

COLLECT PARAMETERS

DEFINE RULES

Jak to funguje

Security Manager

SET PARAMETERS

Enterprise IT Instruction

IT Infrastructure

Exceptions

IT Administrator

Obrázek 1 – Základní schéma procesu

Webová aplikace pro řízení monitorování

LDAP server

Notifikační subsystém

Monitorované IT systémy MS Windows Server, HP UNIX, Linux...

Monitorovací server Správa uživatelů

Workflow

Reporting Oracle, IBM DB2, MS SQL Server...

Mail server Aplikační server

Konfigurační DB (CMDB)

»» přístupová práva k systémům, souborům a databázím, »» nastavení a  kontrola bezpečnostních parametrů služeb, »» parametry síťových služeb, »» aktualizace softwaru, »» přístupová práva k síťovým službám, »» nastavení Firewallu, »» nastavení VPN atd.

Datová pumpa

Monitorovací framework

Databáze

MS IIS, Websphere, Apache...

Firewall, router...

SEMOS podporuje procesy v oddělení provozu IT a v oddělení bezpečnosti IT, viz Obrázek 1: Základní schéma procesu. Schéma základního procesu lze zjednodušeně popsat takto: Security Manager na základě např. doporučení CIS a  za pomoci administrátorů IT vytváří bezpečnostní politiku pro každou monitorovanou platformu (např. OS MS Windows Server 2008). IT Administrátor na základě této politiky nastaví hodnoty parametrů do příslušných serverů. A pak je tady SEMOS, který pravidelně a  automatizovaně sbírá hodnoty nastavených bezpečnostních parametrů. Současně má k  dispozici pravidla (dle přijaté bezpečnostní politiky), která nastavuje Security Operator, a  jež určují správné hodnoty bezpečnostních parametrů. SEMOS porovná zjištěnou hodnotu parametru s hodnotou požadovanou a výsledek zaznamená do databáze. Pokud je zde neshoda, pak upozorní e-mailem jak Security Operátora, tak Administrátora příslušného IT systému. Ten je pak povinen v určené době sjednat nápravu, tj. nastavit správnou hodnotu bezpečnostního parametru. Pozn.: Požadavek na opravu může být také řešen např. zasláním tiketu do Servicedesk systému.

Výjimky Obrázek 2 – Základní schéma architektury

zařadit do různých skupin, např.: Account Policy, Audit Policy, User Account Control, User Rights, Network Security atd. (viz „CIS Windows Server 2008 Benchmark“). Hodnoty bezpečnostních parametrů se často nemění, ale jejich kontrola je přesto obtížná. Pokud má společnost např. 100  IT systémů (operačních systémů, databází, webových serverů, aktivních prvků,  …), pak by administrátor měl kontrolovat např. 10 000 parametrů. Ověření tak

velkého množství parametrů nelze ručně zvládnout, a  proto má automatizovaná kontrola smysl. Pro představu dále uvádíme nejpoužívanější skupiny bezpečnostních parametrů, které je možné monitorovat: »» uživatelské účty, »» správa hesel, »» logování, »» řízení auditních záznamů,

Další funkcí na podporu vyhodnocování bezpečnostní politiky jsou výjimky. Ty umožňují na určitou dobu (tj. dobu platnosti výjimky) změnit vyhodnocení výsledku monitorování. Pokud není možné z  provozních důvodů příslušné pravidlo vyhodnocení dodržet, pak IT Administrátor požádá o  výjimku a  ta výsledek vyhodnocení změní nebo příslušné pravidlo deaktivuje. Celý tento proces (žádost, schválení, aktivace, deaktivace) je řízen pomocí workflow.

19

Architektura Na Obrázku 2 uvádíme základní schéma architektury monitorovacího systému: SEMOS se skládá z následujících částí: »» Webová aplikace, která řídí celý systém a  která umožňuje definovat šablony pro monitorování (bezpečnostní parametry, monitorované IT systémy), automaticky vyhodnocovat stav monitorovaných parametrů a prezentovat ho uživatelům. V  případě problému zasílá notifikaci správci příslušného monitorovaného IT systému. Dále připravuje reporty a podklady pro audit. »» Databáze je základním prvkem řešení. Uchovává šablony pro monitorování jednotlivých typů IT systémů, disponuje seznamem monitorovaných IT systémů, zaznamenává hodnoty monitorovaných bezpečnostních parametrů včetně historie. Systém zaznamenává veškeré operace týkající se změn nastavení systému, vyhodnocování neshod či řízení výjimek. »» Monitorovací framework, který zajišťuje sběr dat, tj. hodnot bezpečnostních parametrů z  IT systémů. Momentálně používáme systém Nagios (open source), nicméně naše řešení je otevřené počítá s  použitím i  jiného monitorovacího systému (např. Zabbix, Tivoli apod.).

Napojení na externí systémy (tj. systémy zákazníka) SEMOS, ani jakýkoli jiný profesionální systém, by nemohl reálně pracovat bez napojení na další systémy zákazníka. V  případě SEMOSu vidíme jako nezbytné napojení na: »» Konfigurační databázi (CMDB, Configuration Management DataBase), která obsahuje informace o  jednotlivých IT systémech. Předpokládáme, že ve finální verzi bude SEMOS načítat seznam IT systémů s tím, že pravidelná aktualizace je nutná a ad-hoc zjišťování informací také. »» Dále je nezbytné napojení na Mail server, jehož prostřednictvím jsou zasílána upozornění zodpovědným osobám, a  i  na Adresářový server (LDAP server), díky němuž pracujeme s rolemi a právy v systému. 20

Dáváme technologiím smysl

Obrázek 3 – SEMOS – status history

Co lze monitorovat?

SEMOS a jeho rozvoj

Každé zařízení, které je schopno nějaké Během léta 2013 byla připravena zákomunikace s  monitorovacím serverem, kladní verze aplikace SEMOS. Ta je plně je možné monitorovat. K ovládání IT sysfunkční a  může být nasazena v  prostřetémů zatím používáme variantu přímého dí zákazníka. Nicméně pro plné využití přístupu, tj. zaslání předpokládáme její příkazu pro sejmutí další rozvoj: vytvoSEMOS může hodnot bezpečnostření Správce bezvýrazně pomoci ního parametru přípečnostních politik, při budování bezpečnosti. mo na monitorovaný vytvoření rozhraní Dává jistotu, že IT infraIT systém. na CMDB systémy, Jinou variantou doplnění dalších struktura je nastavena je umístění SW agenplatforem pro modle bezpečnostní politiky. ta na monitorovaný nitorování atd. IT systém, který pak sám nebo na žádost monitorovacího Závěr serveru provede sejmutí hodnot a  jejich Implementace SEMOSu může významzaslání monitorovacímu serveru. ně pomoci při budování bezpečného Řešení je koncipováno jako otevřené, informačního systému v  organizaci díky tedy každý zákazník si může definovat tomu, že SEMOS umožňuje pravidelné a připojit svoje vlastní IT systémy. a  automatizované zjišťování skutečného stavu konfigurací IT systémů i  jejich vyhodnocování. Dává tak jistotu jak řediteli Monitorované bezpečnosti, tak řediteli IT provozu, že IT systémy/platformy IT infrastruktura je nastavena dle bez»» MS Windows server, HP-UX, Solaris, pečnostní politiky. Nikdo se pak nemusí IBM AIX, Red Hat Linux, SUSE Linux, obávat neočekávaného auditu. A  pokud »» MS Internet Information Server, je audit předem nahlášený, pak nemusí Oracle Application Server, Apache, několik dní věnovat přípravě na audit – Tomcat, JBoss podklady má totiž k dispozici ve formě re»» MS SQL Server, Oracle Database, portů. A má k dispozici i podklady o řízení IBM DB2, Sybase Adaptive Server, neshod, výjimek atd. PostgreSQL, MySQL »» LDAP, MS Active Directory, Novell eDirectory Jiří Makalouš / Projektový manažer »» MS Exchange Server »» Firewally

Testování interního a externího webu – v čem je rozdíl?

Funkčnost

Přenositelnost

I

nternetový věk s  sebou přinesl řadu celospolečenských změn, jejichž dosah zatím možná nelze ani zcela dohlédnout. Interpersonální komunikace se přesouvá z osobních setkání na sociální sítě, obchod probíhá čím dál více na e-shopech a v oblasti vzdělávání se stále více prosazuje e-learning. Není však ambicí tohoto článku provádět sociologickou sondu mapující veškeré dopady této proměny informační společnosti. Účel tohoto pojednání je mnohem prostší – zaměřit se na kvalitu tohoto druhu komunikace, lépe řečeno na kvalitu jeho komunikačního prostředí – webové aplikace.

Jak snadné je přenést software do jiného prostředí?

Udržovatelnost Jak snadné je software měnit?

Jsou v softwaru dostupné požadované funkce?

Bezporuchovost Jak je software spolehlivý?

ISO/IEC 9126

Účinnost

Použitelnost Je software snadno použitelný?

Jak je software účinný?

Obrázek 1 – Charakteristiky kvality podle ISO/IEC 9126

Okno do dvora nebo výkladní skříň Webové aplikace se vyznačují některými specifiky. Díky jasnému oddělení prezentační vrstvy od aplikační logiky je snadné provádět změny designu webových strá-

nek a dochází k nim velmi často. Webové prohlížeče mají také určitá omezení, která limitují návrh a implementaci uživatelského rozhraní webových aplikací. A přestože stále roste podíl klientských aplikací

pro mobilní zařízení, tradiční webové rozhraní zůstává i  nadále pro webové aplikace dominantní. Podotýkám, že až doposud se bavíme o  obou typech webových aplikací: externích i  interních.

Charakteristika

Externí webové aplikace

Interní webové aplikace

Funkčnost (vhodnost, přesnost, interoperabilia, bezpečnost dat)

Funkčnost by měla být pouze a právě taková, jakou očekává a požaduje pro svůj účel zákazník. Přílišná komplikovanost je na škodu. Uživatel musí mít dojem, že jeho data jsou v „dobrých rukou“.

Funkčnost by měla poskytnout pro každou uživatelskou roli instrumenty pro vykonávání svěřené práce. Aplikace musí poskytovat pravdivé údaje, vysoké nároky jsou na integraci aplikací mezi sebou tak, aby nebylo nutno jeden údaj zadávat do více systémů.

Bezporuchovost (zralost, odolnost proti vadám, obnovitelnost)

Webová aplikace, která není v provozu v režimu 24 × 7, je výrazně znevýhodněna vůči konkurenci. Vzhledem k nezbytnosti permanentních updatů prakticky za provozu jsou kladeny extrémní požadavky na proces release managementu.

Aplikace může být mimo pracovní dobu odstavena pro profylaxi, updaty a opravy chyb. Musí však být 100% zajištěna možnost rollbacku v případě nezdaru provedené aktualizace.

Použitelnost (srozumitelnost, zvládnutelnost, provozovatelnost, atraktivnost)

Uživatel musí získat pocit, že snadno dosáhne toho, co od aplikace očekává, že se pohybuje v důvěrně známem prostředí, které respektuje moderní trendy, ale zároveň se nevymyká zaběhnutým de facto standardům. Do této oblasti zařadíme i potřebu vícejazyčnosti.

Na zaškolení personálu je vždy potřeba určit časový prostor. Srozumitelnost je i zde měřítkem, primární je však odpovídající podpora služeb a procesů. Atraktivnost zde není tak důležitá.

Účinnost (efektivita při používání, chování v čase, využití zdrojů)

Vzhledem ke frekvenci využívání internetových aplikací ze strany veřejnosti není účinnost aplikací tak dalece důležitým hlediskem.

Toto hledisko je rozhodující pro správnou intranetovou aplikaci. Složité a nepřehledné rozhraní může výrazně snížit efektivitu práce.

Udržovatelnost (analyzovatelnost, změnitelnost, stabilita, testovatelnost)

Vzhledem k neustálé potřebě změny v aplikaci je splnění této charakteristiky zásadní pro úspěšnost produktu.

Rovněž u tohoto typu aplikací je nezbytné dodržet pravidla pro možnost kontinuálního rozvoje aplikace.

Přenositelnost (adaptabilita, instalovatelnost, koexistence, nahraditelnost)

Současný trend cloudových řešení klade na přenositelnost aplikací velký důraz. Je tak zajištěna nezávislost na konkrétním provozním prostředí a jeho poskytovateli.

Virtualizace umožňuje při dodržení pravidel pro přenositelnost transfer celého provozního prostředí včetně konfigurace na jiný HW v rámci organizace.

Tabulka 1 – Charakteristika kvality

21

Každý z nich však má již z principu svého využití odlišný charakter. Externí webové aplikace jsou jedním ze základních prodejních kanálů a jako takové musí mít odlišné vlastnosti od interních. Musí zejména zaujmout kupujícího, nabídnout mu co nejjednodušeji to, co právě shání (a něco navíc), dodržovat jisté ergonomické standardy. K aplikaci přistu-

puje široká veřejnost, proto musí vykazovat odpovídající dostupnost, robustnost a odolnost proti bezpečnostním útokům. Naproti tomu interní webové aplikace slouží především pro „vnitropodnikové využití“. Jejich vlastnosti se tedy odvíjí především od podpory interních služeb a procesů organizace. Nemusí mít tedy zvláště slušivý „kabát“, mohou mít spartánský

vzhled, avšak měly by být dobře použitelné a  především spolehlivé, aby zbytečně nesnižovaly efektivitu práce zaměstnanců.

Na počátku byly požadavky Testování začíná jako vždy u  požadavků. A  zde začínají rovněž odlišnosti interních a externích webových aplikací. Zkusme si tedy vytipovat hlavní požadavky kladené

Použitý typ testů

Charakteristika

Externí webové aplikace

Funkční (ověření funkčních vlastností vůči popisu v návrhu)

Funkčnost, použitelnost

Testy v obou případech ověřují funkčnost podle specifikace.

Systémové (ověření, že kompletně integrovaná aplikace splňuje požadavky)

Funkčnost, bezporuchovost, udržovatelnost

Internetové aplikace mají zpravidla jedno uživatelské rozhraní. Systémové testy E2E tedy probíhají přes rozhraní jedné aplikace.

Důraz je kladen na E2E testy při součinnosti více podnikových aplikací na jedné službě nebo procesu.

Použitelnosti (ověřuje, zda uživatelské rozhraní je snadno pochopitelné a použitelné)

Použitelnost, účinnost

Testy se soustředí na snadnost použití, správnou ergonomii, soulad s de facto standardy i moderními trendy. Testy mohou provádět nezasvěcení uživatelé bez dokumentace a sleduje se intuitivnost aplikace.

Testy se soustředí na účinnost používání, snadnost dosažení a provedení určité funkce, jednoznačnost výstupů.

Akceptační (UAT, testování SW aplikace uživateli – zástupci zákazníka jako podklad pro akceptaci díla a převod užívacích práv na odběratele)

Funkčnost, bezporuchovost,

–

Zástupci zákazníka provádí testy v dohodnutém rozsahu vůči specifikovaným požadavkům. Splnění akceptačních kritérií je podkladem pro převzetí díla.

Alfa / Beta (uživatelské testy, prováděné skupinou potenciálních uživatelů)

Funkčnost, bezporuchovost

U internetových aplikací tato forma testů nahrazuje akceptační testování zákazníkem.

–

Zátěžové (testuje se chování aplikace v rámci očekávaného zatížení

Udržovatelnost, bezporuchovost

Při testech je potřeba ověřit zátěžové špičky, způsobené událostmi, které motivují veřejnost k masivnímu přístupu (prodej novinek na e-shopu apod.)

Zpravidla známe očekávané počty uživatelů, nedochází k nečekaným špičkovým zátěžím

Stress (testy zkoumají chování aplikace v limitních situacích, zjišťuje se robustnost systému a meze, kdy se přestane chovat očekávaným způsobem)

Udržovatelnost, bezporuchovost

Testy mají za úkol zjistit, při jaké zátěži systém přestává reagovat očekávaným způsobem. Robustnost externí webové aplikace je důležitým faktorem spolehlivosti.

–

Penetrační (simulují napadení škůdcem/hackerem, zkoumají se nalezené slabiny)

Funkčnost

Cílem je eliminovat hackerské průniky do systému a zcizení osobních dat zákazníků.

Testy autentizace a autorizace zkoumají oprávněnost přístupu podle rolí na úrovní aplikace i na úrovni celého podnikového informačního systému.

Tabulka 2 – Typy testů

22

Dáváme technologiím smysl

Interní webové aplikace

na obě kategorie webových aplikací. V Tabulce 2 na předchozí strane jsme se pokusili zdůraznit specifika obou zkoumaných typů webových aplikací podle charakteristik dle standardů kvality (ISO/IEC 9126).

TESTY BEZPEČNOSTI Penetrační testy

TESTY VÝKONU Technologický test

Konečně o tom testování Jak je patrno ze srovnávací tabulky požadavků, bude u každého z uvedených typů webových aplikací zapotřebí ověřovat přednostně odlišné vlastnosti a  použít tedy jiné typy testů. Při testování software se používá (nebo by mělo být použito) široké spektrum různých testů členěných podle různých hledisek: »» Metody – statické / dynamické, white/black box, … »» Úrovně – unit, integrační, systémové, akceptační, Alfa / Beta, … »» Typy – funkční, použitelnosti, výkonové (zátěžové, stress), bezpečnostní (penetrační), … »» Provedení – manuální, automatizované, … Nebudeme se zde zabývat typy testů, které ověřují jednotlivé fáze vývojového cyklu aplikací, jako jsou unit testy nebo integrační testy. Pro tyto testy platí v obou případech totéž – zajišťují „brány kvality“ mezi jednotlivými fázemi návrhu a  vývoje aplikací. Abychom zřetelně popsali rozdíly v  testování externích a  interních webových aplikací, zaměříme se pouze na ty testy, které zkoumají výsledný SW výrobek vůči zamýšlenému využití (validace) – tedy ve vztahu ke shora zmíněným požadavkům.

Závěr Jak vyplývá z  výše uvedeného, charakter a záměr využití se u externích (interneto-

Stress testy

Test specifikace

TESTY SYSTÉMU

Testy dokumentace

Alfa-Beta testy Testy použitelnosti

Zátěžové testy

Akceptační testy

Test migrace

Systémové testy

Funkční testy

Test obnovy ze zálohy

Test zotavení z chyb

Test konfigurace

Smoke test

Test instalace

Speciální testy

Unit testy Assembly testy

Obrázek 2 – Typy testů webových aplikací

vých) a  interních (intranetových) webových aplikací liší, je tedy potřeba volit různé typy testů. Zatímco u  testování interních webových aplikací je potřeba se zaměřit kromě funkčnosti především na efektivitu používání aplikace za předem definovaných podmínek, u  testování externích aplikací je kromě toho nezbytné testovat použitelnost, uživatelskou přívětivost, ale i  odolnost proti předem neočekávané zátěži a případným hackerským útokům. Co říci závěrem? Kvalita webových aplikací reprezentuje kvalitu jejich provozovatele a  odráží se ve vnímání jeho

zákazníků i  zaměstnanců. A  odpovídající testování jakožto nástroj zjišťování úrovně kvality je tedy neopominutelnou součástí vývojového cyklu externích i  interních webových aplikací. Zaměření testů je však vzhledem k  rozdílnému účelu pro každý typ aplikace odlišné. P. S.: A  nezapomeňme, že nejen každá legrace, ale i každý test něco stojí. Hazardovat s přízní uživatelů se však zejména u  externích webových aplikací rozhodně nevyplatí. Ivo Zelenka / Vedoucí oddělení testování a zajištění kvality software

Integrace s WSO2

P

ro systémovou integraci lze v dnešní době použít již celou řadu vyspělých nástrojů. Od open source technologií až po ucelené komerční produkty. V  tomto článku si stručně představíme enterprise service bus společnosti WSO2, která poskytuje široké portfolio produktů a služeb v oblasti systémové integrace.

Společnost WSO2 WSO2 je nadnárodní společnost založená v  roce 2005 se sídly v USA, Velké Británii a na Srí Lance. Poskytuje školící a konzultační služby v  oblasti SOA a  k  tomu jako dárkové balení kompletní enterprise middleware platformu, složenou z  několika klíčových produktů a dostupnou ke stažení z repository http://wso2.com. Veškeré tyto produkty jsou založené na dobře známých open source projektech z  dílny ASF (Apache Software Foundation) 23

DELIVERY CHANNELS Portals

Fat Clients

Cell

PDA

Applications

IVR

PRESENTATION WSO2 Gadget Server

WSO2 Application Server

BUSINESS PROCESS

BUSINESS SERVICES

WSO2 Business Process Server

DB

WSO2 Mashup Server

WSO2 Business Rules Server

WSO2 Business Activity Monitor

WSO2 Identity Server

LDAP

WSO2 Enterprise Service Bus WSO2 Governance Registry

DB

Adaptors

WSO2 Complex Event Processing Server

DATA SERVICES / CONNECTIVITY SERVICES Adaptors

WSO2 Application Server

Legacy

LOB Apps

WSO2 Data Services Server

DB

WSO2 Message Broker

File System

SERVICE-ENABLED APPLICATIONS WSO2 Application Server

POJO

JAXWS

JARs

Obrázek 1 – WSO2 kompotenty

a tedy k dispozici pod Apache License 2.0. Samotní vývojáři a zakladatelé společnosti se na vývoji některých komponent buď přímo podílejí, nebo alespoň částečně podíleli, což umožňuje poskytovat i tzv. „development services“ či “custom development” pro zákazníky.

WSO2 ESB Produkty WSO2 pokrývají mnoho oblastí podnikové integrace. V tomto článku se budeme soustředit na jádro, čímž je WSO2 Enterprise Service Bus. Pojem enterprise service bus a jeho principy jistě není potřeba v  dnešní době nějak blíže představovat. Společnosti čím dál častěji využívají tyto typy nástrojů pro budování smysluplné vnitřní architektury, založené na poskytování služeb, popř. k adaptaci 24

Dáváme technologiím smysl

či zpřístupnění vnitřních systémů externím subjektům a naopak. Důležitým kritériem bývá zachování v minulosti již vynaložených investic. WSO2 ESB je jedním z  dalších nástrojů, které umožňují systémovým integrátorům jednoduše a s minimální pracností realizovat požadované integrační scénáře. Vnitřní architekturu sběrnice je možné definovat následujícími komponentami. »» Mediatory jsou komponenty se vstupem a  výstupem, které představují určitý funkční prvek, např. validace, logování, transformace, filtrování a odesílání zpráv, iterace, load balancing atd. »» Sequence představuje zapojení několika mediátorů do tzv. pipeline. S  ohledem na zpracování požadavku lze pipeline rozdělit na vstupní (request), výstupní (response) a fault, která

umožňuje ošetřit chybové stavy, viz Obrázek 1 – WSO2 komponenty. »» Endpointy specifikují cílovou destinaci pro odchozí zprávy. Umožňují též nastavit některé parametry komunikace a politiky týkající se QoS (Quality of Services). »» Proxy service umožňují definovat virtuální služby hostované na ESB. Virtuální služby nejsou bohužel zcela odstíněné od jejich fyzické implementace. Tudíž v  rámci definice je nutné specifikovat, zda půjde např. o  HTTP konektor či službu přistupující k  FTP serveru. V rámci Proxy service existuje několik předdefinovaných šablon, které urychlují tvorbu typových scénářů. Pokud nestačí předdefinované, je možné zvolit specifickou konfiguraci a přizpůsobit nastavení na míru. »» REST API je speciální komponenta umožňující jednoduchým způsobem vystavit REST služby a vydefinovat jim požadované parametry (http metody, mapování a  url templates). REST API vzniklo bohužel až dodatečně pro podporu služeb na bázi REST/JSON a stojí tedy trochu stranou od koncepce Proxy service.

XML Smooks transformace, definice endpointů atd. Tyto zdroje je pak dále možné odkazovat a referencovat v rámci jednotlivých sekvencí a vytvářet tak přehlednější a  znovupoužitelné komponenty. »» Registry obsahují veškerá metadata a konfiguraci sběrnice. Defaultně běží v  embedded módu s  lokální databází H2. Pro produkční účely je možné přepnout na vzdálené datové úložiště a například sdílet nastavení mezi více instancemi sběrnice. »» Templates jsou parametrizovatelné předlohy ESB konfigurace. Slouží k minimalizaci redundantních částí podobně jako lokal entry. Templates lze definovat pro sekvence a endpointy.

Vzájemnou konfiguraci těchto komponent je možné zajistit přes XML nebo prostřednictvím grafického návrháře a wizardů dostupných přes webové rozhraní. K dispozici jako alternativa je též vývojové prostředí na bázi Eclipse, které ale v době psaní tohoto článku nepodporovalo tvorbu REST API. Celá sběrnice běží nad WSO2 Carbon, což v základu není nic jiného než OSGI runtime, HTTP bridge, registry a management služby WSO2 ESB okolo. Díky OSGI Consumer PROXY SERVICE jsou možné life In Sequence změny konfiguraMediator01 Send Mediator Endpoint Client ce. Defaultně se Service Provider využívá Equinox, Out Sequence Partner Service Endpoint Send Mediator Mediator02 parametricky jsou podporovány i jiná Actual Service Actual Service Fault Sequence běhová prostřeMediator03 Log Mediator dí jako např. Felix a Knoplerfish. Díky Obrázek 2 – Vnitřní architektura Equinox by mělo být vytváření nových komponent stejně »» Message store a Procesory ​ snadné jako vytváření pluginů do Eclipse. Message store je úložiště pro asynBohužel OSGI specifikace pro cílové vývochronní datové zprávy. Je možné jáře dnes stále ještě není tak snadno uchovyužít jak in-memory message store pitelná, jak bychom si přáli. (testovací účely), tak persistentní message store. Mechanismus napojení je standardizován specifikací JSRNávrh integračních scénářů 914 (JMS), tudíž jako message broker Pro popis integračních scénářů zatím může posloužit libovolný produkt neexistuje obecně platný standard jako podporující tuto specifikaci. je tomu například u  business procesů »» Local entries fungují jako lokální (BPMN 2.0). Asi nejblíže je tomu sada souborové registry, do kterých je specifikací kolem SCA (Service Commožné uložit různé textové a  xml arponent Architecture), která má za cíl tefakty. Příkladem může být definice usnadnit vývojářům a  integrátorům doslužeb (WSDL, XSD), XSLT šablony, držování SOA principů, jak v oblasti tvor-

by nových komponent, tak i ve skládání těchto komponent dohromady. WSO2 ESB používá pro popis integrace svůj vlastní proprietární jazyk na bázi XML, který vychází z  Apache Synapse. Konfigurace ESB pro daný integrační scénář pak znamená jednoduše: »» Identifikovat správnou sadu komponent »» Složit tyto komponenty do sekvencí v optimální podobě buď prostřednictvím GUI, nebo XML. Při návrhu je k dispozici též sada integračních patternů. Ve scénářích je tak možné používat komponenty typu recipient list, content based router, splitter, agregátor, resequencer, message filter atd. Robustnost těchto komponent je potřeba brát s  ohledem na požadavky. Pokud jsou hodně specifické, je možné zasáhnout i na úrovni programovacího jazyka.

Administrace Open source produkty z  této domény příliš často nedisponují nějakým zvláště sofistikovaným a komplexním GUI. Pokud ano, většinou se jedná již o komerční enterprise nadstavbu. WSO2 ESB má v tomto ohledu jednoznačně navrch a  poskytuje ucelenou grafickou konzoli, která funkčně pokrývá administraci a konfiguraci, mana­ gement, vizualizaci návrhu jednotlivých služeb a v neposlední řadě též monitoring aktuálního stavu sběrnice a  jednotlivých komponent. Stojí za zmínku, že kromě uživatelského rozhraní je možné pro monitorování využít standardizované rozhraní JMX či SNMP a předávat tak běhové metriky do různých podnikových monitorovacích nástrojů.

Závěr WSO2 ESB zaujala poměrně rychle své místo na poli vyspělých integračních nástrojů. Svědčí o tom i řada referencí a zmínky od společností Gartner a  Forrester Research. Aktuální verze 4.7.0 přináší další užitečná vylepšení, např. v oblasti REST služeb a do budoucna je tedy snad na co se těšit.

Zdeněk Křepela / Developer Zdroje : http://www.wso2.com, http://oasis-opencsa.org/sca Obrázky: http://www.wso2.com 25

Cyber-Ark v zahraniční praxi

S

prostředí, které firma spravuje, je velmi rozsáhlé a nehomogenní – 10 000 UNIX (SUSE, RedHat) a  Windows serverů, 5 IBM mainframů, 400 databází (Oracle, Microsoft, IBM), 1  500 síťových prvků. Celkově jde o  více než 20 tis. privilegovaných účtů. Vzhledem k  tomu, že správa systémů je prováděna napříč různými datacentry, která jsou na různých síťových segmentech, využila firma vlastnosti PIM Suite, kdy s centrální repozitory hesel zabezpečeně spolupracuje více Central Policy Managerů. Central Policy Manager je softwarová komponenta, jejíž instance běží v oddělených lokalitách sítě. Jsou jednotně a centrálně spravovány, vynucují nastavenou politiku hesel a přistupují k centrálnímu úložišti přístupových údajů. Samozřejmostí je z důvodu vysoké dostupnosti využití HA modulů, tedy řešení s master a backup úložištěm Enterprise Password Vault (EPV). PIM Suite je ve firmě Fiducia IT integrován s Radiusem, LDAP a centrálním systémem SIEM. Holandské finanční instituce Rabobank nebo BT Group (dříve British Telecom, Londýn, Velká Británie) ocenily při nasazování PIM Suite možnost postupného a  především bezvýpadkového nasazení produktu. Problematika jejich implementace totiž leží v  distribuovanosti v  mnoha zemích a  dceřiných společnostech (BT Group – 170 států, Rabobank – 48 států). Rabobank navíc využila možnosti nejprve realizovat Proof of Concept, na kterém si vlastnosti PIM Suite ověřila.

polečnost KOMIX je již několik let partnerem izraelské firmy Cyber-Ark, jež vyvinula v mnoha ohledech jedinečné bezpečnostní softwarové řešení. Její produkty řeší oblasti bezpečnosti, které žádné jiné dostupné programy neřeší – jedná se především o řízené, bezpečné a auditovatelné sdílení a využívání privilegovaných účtů k operačním systémům, databázím nebo cloudovým prostředím a bezpečné sdílení a výměna informací. V tomto článku bychom rádi na konkrétních případech využití v praxi demonstrovali některé zajímavé technické a organizační aspekty, které nasazení produktů Cyber-Ark přineslo zákazníkům po celém světě. I v České republice je již v několika institucích těchto řešení využíváno.

Jedním z pilířů a hlavním produktem firmy Cyber-Ark je patentované bezpečné úložiště dat – digitální trezor – Secure Digital Vault. Všechny tři skupiny produktů – Privileged Identity Management Suite (PIM Suite) včetně součásti Application Identity Manageru (AIM), Privileged Session Management Suite (PSM Suite) a Security Information Management Suite (SIM Suite) jej využívají. Secure Digital Vault jim pokrývá některé specifické oblasti bezpečnosti. Mezi ně patří zejména mnohovrstvé zabezpečení a řízení přístupu a velmi silné šifrování, využívané pro ukládání citlivých dat. PIM Suite pomáhá firmám, které mají velké množství spravovaných cílových systémů a zařízení a ke kterým je nutné bezpečně uchovávat přístupové údaje k privilegovaným účtům (root, administrator, DBA, systém apod.), zpřehlednit, automatizovat a především prokazatelně poskytovat přihlašovací údaje IT administrátorům.

Vhodné řešení pro hostingové firmy Firma CDW, přední poskytovatel hostingu a  dalších IT služeb v USA, tímto způsobem uchovává a v případě potřeby poskytuje hesla k více než 25 tis. privilegovaným účtům. CDW využívá centrálního úložiště nejen pro svou vlastní potřebu, ale poskytuje i přihlašovací údaje k hostovaným prostředím stovkám svých zákazníků. S výhodou využívá pravidelné a automatizované změny hesel, která je, včetně jejich kvality, řízena centrálně spravovanými politikami. Nepochybně velkou konkurenční výhodou je velmi přesná auditovatelnost využití privilegovaných účtů, díky které se firmě daří dodržovat všechny závazné bezpečnostní normy a legislativní předpisy – PCI-DSS, SSAE-16 (dříve SAS 70) nebo HIPAA.

Distribuovanost prostředí a integrace Německá firma Fiducia IT AG (Karlsruhe, Německo), která poskytuje IT služby řadě finančních institucí, s využitím PIM Suite dosáhla splnění německého bankovního normativu MaRisk. Systémové

26

Dáváme technologiím smysl

Soulad s bezpečnostními normami a legislativou Všechny implementace PIM Suite, někdy ve spojení s  PSM Suite, přinesly zákazníkům konkurenční výhodu v  podobě souladu s  mezinárodně uznávanými normami, v  případě BT Group (jde o  firmu působící mimo jiné i  v  USA) například soulad s  normou Sarbanes-Oxley Act (SOX). V Česku zatím legislativa, která by vyžadovala zajištění privilegovaných účtů nebo monitoring administrátorských aplikací, chybí. České firmy, především instituce z bankovního sektoru, jsou ale povinny dodržovat ustanovení Zákona o  bankách, Vyhlášky č. 123/2007 Sb. o pravidlech obezřetného podnikání bank, spořitelních a úvěrních družstev a obchodníků s cennými papíry nebo Úředního sdělení ČNB ze dne 27. května 2011 k výkonu činnosti na finančním trhu – operační riziko v oblasti informačního systému. Další bezpečnostní aspekty informačních systémů řeší

i normy ISO 27 000, pokud jsou instituce dle nich certifikovány. Výše zmíněný modul PSM Suite (Privileged Session Management Suite), který umožňuje zcela bezpečně izolovat a  monitorovat uživatelské session včetně záznamu (i ve formě videosekvencí), využily pro řízení a sledování aktivit externích dodavatelů nebo smluvně vázaných administrátorů například společnosti Rabobank nebo Global Financial Services (USA).

Obměna hard-coded hesel v aplikacích Zajímavě implementovala PIM Suite ve spojení AIM (Application Identity Managerem) jedna z největších leteckých společností v USA, jež provozuje aplikační portál pro online rezervace letenek. Problém bezpečného a nenapadnutelného uložení informací o  kreditních kartách zákazníků, které musely být uloženy v databázi až do odbavení před letem, vyřešila nasazením PIM Suite pro ochranu administrátorských účtů aplikačního a databázového serveru (včetně přímého přístupu k  databázi) a  úpravou rezervační aplikace s  využitím AIM. Aplikace nyní neobsahuje hardcoded přístupové údaje pro připojení k  databázi, ale je v  nich implementována část programového kódu, který si online vyzvedne přihlašovací údaje od běžícího Password Provideru. Přístupové údaje tak nejsou nikomu známé, jsou pravidelně měněné, jsou dostatečně bezpečné a  citlivé zákaznické údaje jsou tak velmi silně chráněny. Nasazení PIM Suite na omezený rozsah technologie je oproti plošné implementaci jedinečný. S  poměrně malou investicí tak letecká společnost splnila podmínky bezpečnostních norem PCI-DSS (Payment Card Industry vydaný Security Standards Council).

Online přístup kdykoliv a kdekoliv Finansbank (Turecko), která poskytuje bankovní produkty pro fyzické osoby, vyřešila nasazením PIM Suite problém, kdy byly přístupové údaje uloženy v  200 různých obálkách ve fyzickém trezoru. Než se administrátor fyzicky dostal do trezoru, našel správnou obálku a  mohl v  případě havárie přístup použít, uplynulo často až 30 minut času. S využitím PIM Suite se navíc již jednou použité heslo stalo nadále neplatným, protože bylo ihned po použití

automaticky změněno a nemohlo být tak případně zneužito.

PIM Suite i v průmyslu Nalezli jsme při přípravě tohoto článku i case study z oblastí, kde bychom využití PIM Suite nečekali. Firma National Gympsum Company (Charlotte, Severní Karolína, USA) je jedním z největších producentů sádrokartonových výrobků a  dalších stavebních prvků, které se vyrábí v celkem 43 výrobních závodech v  USA. Využití PIM Suite je standardní. Do jeho nasazení využívala společnost jediný účet doménového administrátora, který byl znám mnoha IT zaměstnancům, heslo k  účtu nebylo vůbec měněno ani kontrolováno jeho využití, navíc jej využívaly pro přístup k prostředkům i aplikace, které by po jeho změně přestaly být funkční. Řešením bylo

vytvoření většího množství různých účtů s omezenými právy v MS Active Directory. Pro správu hesel k  těmto účtům nasadila firma právě PIM Suite. Pro přístup aplikace Opalis k systémovým prostředkům využili modul AIM. Jedná se o zajímavé a ojedinělé využití bezpečnostních produktů firmy Cyber-Ark ve výrobním odvětví, kde bychom jej neočekávali.

Sdílení dat bezpečně, auditovatelně a bez klientského softwaru Řada firem, které implementovaly PIM Suite, zamýšlí nebo již nasadila další skupinu produktů, Sensitive Information Management Suite (SIM Suite), která využívá především modulu Inter-Business Vault (IBV). Bezpečné uložení a přenos informací včetně monitorování aktivit nad sdílenými daty využívají například pro předávání citlivých auditních záznamů a přehledů mezi provozovatelem systému a auditorem. Některé implementace SIM Suite jsou však zcela samostatné a  vlastnosti PIM Suite nemusí být zákazníky využívány. Na základě rostoucí poptávky po online ko-

munikaci implementovala izraelská pošta systém pro přenos a  ukládání elektronických dat (mailů). Hledala řešení, které bude bezpečné, spolehlivé a  s  webovým přístupem, takže vybrala Inter-Business Vault. Řešení přineslo poště významný zdroj příjmů poté, co se ke službě připojilo 50 nejvýznamnějších izraelských odesilatelů elektronické pošty (velké korporace a vládní organizace). Uživatelé mají přístup ke svému archivu zpráv po dobu sedmi let, mohou online využívat platební služby, upozornění a upomínky. Služba je pro uživatele zdarma a očekává se, že v horizontu 3 až 5 let ji bude používat většina izraelských domácností. Clearstream, velká německá společnost poskytující post-trading služby a správu cenných papírů, každý den zpracovává pro cca 2 500 zákazníků ze 110 zemí

přibližně 250  000 transakcí. S  ohledem na citlivost informací se rozhodla automatizovat řízení přístupu a  správu hesel u  privilegovaných účtů. Aby uspokojila auditory, hledala řešení, které nabízí jasný a  nezpochybnitelný záznam o  aktivitách administrátorů systémů. Pomocí PIM Suite & Inter-Business Vault implementovala bezpečnou správu a audit privilegovaných účtů a bezpečnou výměnu dat mezi interními uživateli a externími partnery.

Závěr Na výše uvedených příkladech jsou vidět praktické možnosti nasazení produktů společnosti Cyber-Ark. Tyto nástroje zvyšují důvěrnost a integritu informací nejen svými unikátními technickými vlastnostmi, ale zároveň snižují provozní náklady na správu systémů a s ní spojené požadavky na dodržování bezpečnostní politiky. David Kulhan / Zástupce ředitele Odboru systémové podpory Otakar Ludvík / Ředitel Odboru systémové podpory

27

KOMIX s.r.o.

tel. +420 257 288 211 / fax +420 257 288 221 [email protected] / www.komix.cz

od 1. 2. 2014 sídlíme na nové adrese: Drtinova 467/2A / 150 00 Praha 5

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.

Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti

V  nadcházejí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.

28

Dáváme technologiím smysl

Kontakty

Avenir Business Park Radlická 751/113e / 158 00 Praha 5