ZDE - Komix

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