KOMIX NOVINY 2010/2011

Nepřehlédněte:
Inxmail – efektivní e-marketing v praxi
KOMIX pokrývá oblast e-marketingu produktem
společnosti Inxmail, který se jmenuje Inxmail
Professional. Mailing v Inxmail Professional přináší marketérům a obchodníkům řadu významných výhod. Inxmail poskytuje řešení, které se
komix noviny 2010/2011
osvědčilo ve více než 1000 marketingových odděleních a agenturách. Str. 8.
Vážení čtenáři,
QlikView na všechno a pro každého
minulý rok jsem si na tomto místě postěžoval, že není jednoduché psát úvodník k časopisu, který
vyjde až za řadu týdnů, v situaci, která se mění každý den. Letos to je podobné. Úvodník píši před
jmenováním nové vlády, ve vzduchu je řada příslibů, záměrů, ale na to, jakým způsobem budou
realizovány a jak rychle, si budeme muset ještě počkat.
Produkt QlikView je nástroj Business Intelligence,
Další velkou výzvou a zároveň velkou neznámou
je rozvoj eGovernmentu v naší republice. Řada
projektů v oblasti eGovernmentu se stala běžnou součástí našeho života, např. datové schránky nebo CzechPoint. Pasy s čipy obsahujícími biometrické informace používáme běžně, ale třeba
projekt registrů trochu tápe, nabírá zpoždění,
a ani několik měsíců poté, co měly registry podle
původní verze zákona fungovat, nejsou známi řešitelé některých z nich. Přitom právě CzechPoint
a tento koncept k nám jezdí studovat zahraniční
delegace.
Domnívám se, že právě v oblasti eGovernmentu
má Česká republika šanci se prosadit a tyto projekty se mohou stát naším exportním artiklem. KOMIX
by samozřejmě byl rád u toho a přispěl svou prací
k úspěchu těchto projektů.
Vám, čtenářům, přeji, aby každý z vás v tomto čísle našich novin našel něco, co je pro něho užitečné nebo zajímavé. Naším úmyslem je poskytnout
informace o tom, co v současnosti děláme a čím se
zabýváme nebo informovat o nových vlastnostech
námi používaných technologií.
Petr Kučera
lům zkoumat velký objem dat zcela libovolným
Odborníci tvrdí, že právě období, kdy nás zasáhla
krize, ukazuje, že je třeba zlepšit způsoby řízení firem a zlepšit podporu prodejních procesů. KOMIX
na tento požadavek reaguje nabídkou komplexního řešení manažerských informačních systémů,
podporou procesů prodeje postavenou na osvědčeném CRM řešení společnosti CAS (Computer
Aided Sales) nebo nástrojem pro efektivní řízení
marketingových kampaní Inxmail. Oba uvedené
nástroje jsme schopni implementovat u zákazníka
nebo poskytnout jako službu provozovanou na našem serveru za měsíční poplatek, a tedy bez odrazující počáteční investice.
Žádná z těchto technologií ale neumí konkurovat
chobotnici, která neomylně předpovídala výsledky fotbalového mistrovství světa. Bylo by zajímavé zjistit, zda byla opravdu ponechána sama sobě
nebo v pozadí za ni pracoval nějaký analytický tým,
a pokud tomu tak bylo, jaké technologie a metody
využíval. Je zajímavé, že právě ve sportu se analýza dat zcela běžně využívá jako nástroj pro analýzu
činnosti jak vlastního týmu, tak konkurence, a špičkové týmy se bez svého analytika neobejdou. Ve firmách tomu tak často není. Proč?
který je založen na patentovaném principu, tzv.
asociativní in-memory analýzy (IMA). Díky této
technologii QlikView umožňuje svým uživatezpůsobem bez jakýchkoliv omezení s odezvou
několika málo vteřin. Str. 9.
CASting - najděte svou STAR!
Pracujete s talenty a jejich informacemi včetně
fotografií, videí a dalších dokumentů? Potřebuje
talenty vyhledávat, výsledky předávat a komunikovat s talenty i produkcí. Pak je CASting ta
správná volba pro vás. Str. 14.
JOSSO aneb systém jednotného přihlášení
Podstatou systému jednotného přihlášení pracujícího s pomocí infrastruktury Java Open Single Sign On (JOSSO) je snaha zefektivnit a zjednodušit práci uživatelům, kteří jsou nuceni si
pamatovat velké množství přihlašovacích údajů
do různých systémů a aplikací. S JOSSO potřebujete jen jeden přihlašovací údaj. Str. 16.
Datové schránky – první krok k Národnímu
digitálnímu archivu
Informační systém datových schránek (ISDS)
slouží k obousměrné komunikaci mezi právnickými osobami (firmami) a orgány veřejné moci.
Pro uvedené organizace a úřady je tento způsob komunikace povinný a prioritní ze zákona.
S implementací rozhraní Národního digitálního
archivu se počítá v roce 2012. Str. 18.
Technologie – dobrý sluha, špatný pán
Na počátku snahy RIA byla snaha o jednoduchost tvorby aplikací. Tato snaha trvá dodnes,
ale již nyní je zřejmé, že složité GUI nelze vytvořit
jednoduše. Jsou-li tedy důležité zkušenosti návrháře a programátora, je důležité omezit fluktuaci
těchto pracovníků a hlavně – dobře dokumentovat úroveň dosaženého poznání. Nenechte se
pasivně unášet překotným vývojem RIA technologií! Str. 19.
1
Manažerské informační systémy nejen pro manažery
“Decision making and the techniques and technologies to support and automate it will be the next
competitive battleground for organizations.“
Tom Davenport, author of Competing on Analytics
studovat stejně pečlivě, jako fotbaloví nebo hokejoví trenéři studují hru soupeřů.
Firma jako dynamický systém
Základní požadavky na moderní MIS
Pokusme se podívat na firmu očima standardní teorie řízení, viz. obrázek. V teorii řízení máme obvykle nastaven nějaký vektor (např. sadu KPI) jako požadovaný výstup řízené sestavy a máme k dispozici
vektor vstupních veličin, kterými můžeme celou
soustavu řídit.
Vedle toho na řízenou soustavu působí poruchy,
které ji vyvádějí z rovnovážného stavu, a to se v důsledku projeví změnami hodnot na výstupu. Měříme odchylku aktuálního stavu od požadovaného - získáváme regulační odchylku – a tu zavádíme
spolu s vektorem požadovaných výstupů do regulátoru (vytváříme zpětnou vazbu), který generuje
řízení, jehož účelem je převést soustavu do žádaného stavu. Jak projevy poruchy, tak měřitelné reakce na řídící zásahy jsme schopni obvykle měřit až
se zpožděním.
To podstatné, co si musíme uvědomit je, že měřené
výstupní hodnoty závisí na vnitřních stavech systému a v nelineárních systémech není z naměřeného
výstupu obecně možné vnitřní stav jednoznačně
určit. Firma je zcela jistě složitý nelineární systém,
který nelze jednoduše popsat.
Z hlediska teorie řízení má před sebou vedení firmy
několik základních problémů:
a)definici optimálního cíle řízení – to je podstatné
strategické rozhodnutí,
b)rozpoznání stavu, ve kterém se řízená společnost
nachází,
c)identifikaci řízeného objektu – tj. rozpoznání zákonitostí, podle kterých se firma chová,
d)zjištění omezení, se kterými je třeba pracovat, a
e)určení optimálního způsobu řízení tak, aby při respektování existujících omezení bylo možno dosáhnout v daném čase požadovaných cílů.
V teorii automatického řízení se dále pracuje s pojmy
řiditelnost a pozorovatelnost systémů. Z hlediska
praxe je zejména při konstrukci mnohorozměrných
systémů automatického řízení důležité vědět, zda řešení daného problému vůbec existuje. Je-li systém
pozorovatelný a řiditelný, lze o řešitelnosti zadaného
problému poměrně snadno rozhodnout.
Pojem řiditelnosti se definuje pomocí pojmu dosažitelnosti stavu. Zhruba řečeno, stav Y je dosažitelný ze stavu X, jestliže existuje (s přihlédnutím k omezením) řízení U, které převede systém ze
stavu X do stavu Y. Řiditelnost v podstatě zname-
2
ná, že všechny složky vektoru stavu závisí na vstupu systému. Podstatné je, že mohou existovat stavy
X, z nichž se do stavu Y v zadaném čase nelze dostat žádným řízením z množiny, která je k dispozici. Včasné rozpoznání toho, že před management
společnosti byl postaven neřešitelný úkol, je k nezaplacení. V takové situaci je pak třeba změnit cílový stav nebo omezení definující množinu přípustných řízení.
Pozorovatelnost je duální pojem k řiditelnosti
a v podstatě vyjadřuje to, že výstup pozorovatelného systému závisí na všech složkách vektoru stavu.
Tj. změna jakékoliv složky stavu se projeví změnou
výstupu, kterou lze měřit.
Zůstaneme-li ještě u analogie mezi firmou a dynamickým řízeným systémem používaným v teorii regulace, můžeme si ukázat ještě jednu věc. Chcemeli rozpoznat, jak se chová řízený systém, jaké má
vlastnosti, případně vytvořit jeho matematický model, zadáváme na jeho vstupy nějaké předem připravené hodnoty (třeba jednotkový skok) a měříme
odezvy systému. Vztah mezi výstupem a vstupem
se pak snažíme popsat matematickým modelem.
Obdobně lze sledovat chování firmy tak, že studujeme, jaké jsou odezvy na různé řídící zásahy, které
vedení dělá, jak reaguje firma na poruchy přicházející zvenčí. Tyto znalosti jsou pro rozhodování velice
důležité, umožňují odhadnout dopady řídících zásahů nebo vnějších událostí.
Měli bychom si uvědomit, že není tak úplně nutné
se učit pouze z vlastních chyb/úspěchů nebo jen
na vlastní firmě. Prostředí kolem nás poskytuje celou řadu příkladů úspěšných i neúspěšných strategií. Je možno se učit i z chyb a úspěchů jiných. Chování konkurenčních firem by měl management
Z výše uvedeného lze odvodit základní požadavky
na manažerský informační systém (MIS).
a) Pro stanovení cílů i pro určení pozice řízené společnosti na trhu musí management znát velice
dobře nejen možnosti řízené firmy, ale i její pozici na trhu vůči konkurenci. Musí být schopen
odhadnout (předvídat), jak se bude trh vyvíjet,
jaké požadavky zákazníků nabudou důležitosti,
jaké naopak důležitosti pozbudou. Musí vědět,
co nového chystá konkurence. Je nutné sledovat
síťové závislosti, vazby. Toto je oblast informací,
kde se pracuje do značné míry s nestrukturovanými (textovými) informacemi doplňovanými strukturovanými údaji (třeba benchmarking
s konkurencí na základě publikovaných ekonomických údajů). Tento požadavek vede na použití nástrojů typu Competitive Intelligence.
b)Zcela jistě musí MIS poskytovat detailní informace o ekonomické situaci firmy, její zakázkové náplni, plnění plánu, využití lidského potenciálu atd. Musí být schopen prezentovat trendy
vybraných veličin, umožnit hlubší analýzu těch,
které jsou agregované, umožnit sledovat veličiny, které se ovlivňují, ve vzájemných vazbách.
Tato část MIS pracuje převážně se strukturovanými daty z interních databází.
c)Při vytváření a hodnocení strategií nebo při
volbě řídících zásahů je třeba pracovat s nějakou sadou scénářů a ty je třeba hodnotit podle
zvolených kritérií, pracovat s modely, provádět
what-if analýzy.
d) Z obrázku vidíme hned dvě oblasti, které mohou
významně ovlivnit kvalitu řízení. První z nich je
dopravní zpoždění ve zpětné vazbě. Čím je větší,
tím obtížněji se soustava řídí. Tj. informaci musí
manažer dostat bezprostředně poté, co je k dispozici.
Schéma řízení dynamického systému
informací pro konkrétního manažera lze poměřovat tím, zda změní své rozhodnutí při změně hodnot vybraných parametrů nebo v reakci na určitou
událost. Tj. jedná se o rozpoznávání rizik a hodnocení jejich potenciálních dopadů na plnění stanovených cílů. Přitom se samozřejmě musí brát
v úvahu komplexnost celého systému a vzájemné
vazby mezi údaji, protože většinou je možno činit
rozhodnutí až na základě znalosti kombinací určitých hodnot.
Na druhé straně každá společnost má potřebu si
svá data chránit. Není tedy možné všechny informace poskytovat všem, je třeba implementovat zásadu „nutno znát“.
e)Druhou oblastí je schopnost včasného rozpoznání příznaků blížící se poruchy a měření velikosti této poruchy. Ze studie společnosti Gartner je známo, že každá významná porucha je
obvykle signalizována nějakými příznaky, které jí předcházejí. Jsme-li schopni je rozpoznat,
máme možnost reagovat dříve než ostatní, a tak
získat konkurenční výhodu.
f)Právě proto, že se řízená společnost nalézá
v konkurenčním prostředí a vůbec prostředí neustálých změn, je třeba kontinuálně ověřovat reálnost a smysluplnost stanovených cílů a strategií. Tj. celý systém musí být nastaven tak, aby
byl schopen sledovat cíle, které se v čase mění,
a měl by být schopen - de facto sám - upozornit
na situaci, kdy je třeba stanovené cíle přehodnotit, a podporovat i vlastní proces přehodnocení
cílů. Lze tedy říci, že se v čase vyvíjí jak řízený, tak
řídící systém – takové systémy se označují jako
systémy evoluční.
g)Má-li konstrukce MIS respektovat požadavky
na řiditelnost a pozorovatelnost řízeného systému, musíme soubor sledovaných údajů vytvářet tak, aby vypovídal o hodnotách stavu všech
důležitých veličin řízeného systému, a repertoár řídících vstupů musí být zvolen tak, aby management byl schopen ovlivnit všechny důležité stavové veličiny.
h)MIS nutně musí poskytovat i prostředky pro
zpětnou analýzu toho, co se dělo v minulosti.
Možnost studovat dopady různých řídících zásahů nebo poruch je velice důležitá pro získání
znalostí o chování firmy. Management musí znát
vazby mezi údaji a MIS musí podpořit jejich vnímání ve vzájemných souvislostech.
i) MIS musí redukovat záplavu dat, která jsou k dispozici, a člověku, který rozhoduje, prezentovat
pouze ta data, která jsou v daném čase a pro
daný účel podstatná. Měl by být vybaven mechanismy, které dovolí odlišit údaje, které jsou
tzv. „v normě“ od stavů signalizujících ohrožení,
riziko nebo vypovídajících o tom, že některý ze
sledovaných parametrů „vypadl z definovaných
mezí“ a na tyto stavy důrazně upozornit (alerty).
j) MIS je často vnímán jen jako reporting pro vedení. Když se ale zamyslíme nad požadavky výše,
3
jednoznačně z nich plyne, že MIS je interaktivní nástroj pro podporu rozhodování, který musí
být schopen nejen zpracovávat údaje ze svého
okolí, ale musí být také schopen přijmout informace o profilu uživatele o tom, co on potřebuje,
o čem rozhoduje, musí uživatele podpořit při vytváření a hodnocení různých scénářů nebo rozhodnutí.
k) MIS by měl umožnit i provádění řídících zásahů
a evidovat jejich plnění. Tj. měl by se stát aktivním řídícím prvkem.
l) Samozřejmostí je přehledná a smysluplná prezentace informací, snadné intuitivní ovládání.
m)V poslední době se klade důraz na to, aby analýzu dat, či definici/modifikaci potřebných výstupů,
mohl dělat koncový uživatel (ne-IT), který zná nejlépe své (rychle se měnící) potřeby a význam dat.
Cílené poskytování informací
V každé organizaci se denně dělá celá řada rozhodnutí. V zásadě je můžeme podle jejich dopadu, charakteru a frekvence dělit do tří základních kategorií:
strategická, taktická a operativní.
MIS by měl poskytovat informace a prostředky pro
všechny tyto kategorie rozhodování a zajistit, aby
všechna rozhodnutí mohla být dělána s maximální znalostí problému, který je řešen, a se znalostí dopadů daného rozhodnutí. Celá řada operativních rozhodnutí může být s dobrou podporou MIS
částečně nebo plně automatizována. Kvalitu taktického i strategického rozhodování podstatně ovlivňuje komplexnost vstupních informací a možnost
modelování dopadů různých rozhodnutí.
Lidé na různých stupních řízení a v různých útvarech rozhodují o různých věcech. Všichni by měli
dostat pro svá rozhodnutí relevantní informace a ty
by měly být aktuální a dosažitelné z místa, kde je
rozhodnutí třeba učinit – v řadě případů vede tento požadavek na nutnost vzdáleného přístupu
k datům z mobilních zařízení.
Z toho plyne několik dalších požadavků na konstrukci MIS.
a) Musí být vybaven mechanismem přístupových
práv, který umožní definovat, kdo je oprávněn
pracovat s jakými informacemi.
b)Měl by umožnit individuální úpravy způsobu
prezentace dat, jejich výběru i rozložení na obrazovce.
c) Musí umožnit distribuci relevantních informací
co nejblíže místu rozhodování. To v řadě případů vede k nutnosti přístupu do MIS z mobilních
zařízení, což na druhé straně komplikuje zajištění bezpečnosti.
Shrnutí: Moderní MIS musí být schopen pracovat
jak s nestrukturovanými, tak strukturovanými daty.
Musí být konstruován tak, aby byl schopen sledovat cíle, které se v čase mění, být schopen rozpoznat příznaky změn, které mohou mít závažný
dopad na chod řízené společnosti, a na takové příznaky sám aktivně upozornit. Informace musí být
k dispozici v co nejkratším čase a musí pokrývat
všechny důležité parametry potřebné pro rozhodovací proces. Musí být prezentovány přehledným
a názorným způsobem a být přístupné z místa, kde
je třeba rozhodnutí udělat. Výhodou je možnost
modelování, what-if analýzy, případně podpora aktivního zásahu do řízení přímo z MIS.
Z hlediska architektury se pak takový MIS obvykle
skládá z několika vzájemně integrovaných aplikací.
Proto má KOMIX ve svém portfoliu jak nástroje pro
zpracování strukturovaných dat, např. standardní BI
řešení společností IBM, Microsoft, Oracle nebo QlikView (in-memory analysis, velice rychlé odezvy,
what-if analýza, intuitivní ovládání podpořené automatickým využitím znalostí o vazbách mezi údaji), tak nástroje typu Competitive Intelligence jako
je Knowledge XChanger společnosti Comintelli.
V rámci našeho řešení jsme schopni podpořit i přímé zadávání úkolů včetně sledování jejich delegování/rozpadu na dílčí úkoly a jejich plnění.
Petr Kučera
Standardním postupem je poměřovat důležitost
událostí a informací jejich dopadem na plnění cílů
společnosti, její vize a mise. Význam určitého typu
3
Úvaha na téma informace, znalostní báze…
a co dál?
Prostředí
Knihovny, ve smyslu souborů informací shromážděných na jednom místě, nejsou jen doménou veřejných institucí (obecních či městských knihoven),
škol anebo vědeckých ústavů či univerzit. Potřeba
shromažďovat a uchovávat informace, znalosti, postupy, tipy a fígle se dříve či později objeví v každém pracovním prostředí, kde se něco tvoří, buduje
a vymýšlí. Ať jsou to nanomateriály, informační systémy anebo dřevěné hračky. Samozřejmě, se složitostí a komplikovaností práce se zároveň zvětšuje
i balík informací, které je třeba uchovávat.
Firma, jakou je KOMIX s.r.o., zabývající se vývojem
software, jeho aplikací a správou, a především pak
kolektiv firmy, který se živí hledáním řešení rozmanitých ale specifických úloh v oblasti informatiky, takovým prostředím bezesporu je. Pokusme
se charakterizovat naše pracoviště podle toho, jací
lidé v něm působí a jaký je jejich vztah k informacím, znalostem a zkušenostem:
- pracovník – specialista – je to člověk vesměs
úzce zaměřený na svůj obor, ve kterém se výborně
orientuje a v němž dosahuje vysoké úrovně specifických znalostí,
- pracovník – praktik – je zase člověk, který se důkladně a obvykle dost dlouho zabývá danou problematikou, během své praxe získal celou řadu jinde nedostupných zkušeností,
- pracovník – fluktuant – toto je člověk, který během své kariéry obvykle projde různými pracovišti, ať v rámci jedné firmy nebo mezi firmami. Jsou to
taková pracoviště, kde může co nejlépe uplatnit své
schopnosti a získat při tom nové zkušenosti.
Z tohoto pohledu se dá shrnout, že v prostředí
(softwarové) firmy se nakládá s informacemi, které jsou úzce zaměřené na danou problematiku.
V mnoha případech jsou to znalosti a dovednosti, které vyplynou až z praxe a nelze je získat jinou
běžnou cestou (absolvováním vzdělávací instituce,
z literatury).
A jak s řešením nových úkolů?
Proces může být následující:
1. shromažďování znalostí - nejprve se hledá
ve vlastní paměti, zda jsme něco podobného už nevykoumali, pak je to snadné. Když se nám ale potřebných znalostí nedostává, obracíme se na externí zdroje:
- do literatury, manuálů, poznámek,
- na internet, do manpages, na diskusní fóra,
- na kolegy.
Samozřejmě každý k tomu přistupuje podle své povahy.
4
2. řešení problému - získané informace kompilujeme, navrhneme si řešení, vypracujeme, odzkoušíme a předáme.
3. reflexe - na tu obvykle není čas, protože před
námi už čeká něco nového, další zadání. Přitom je
tento krok velmi důležitý a měl by být svázaný s následujícím, na který se však často zapomíná. Tímto
krokem je:
4. zdokumentování – (zobecnění) a zaznamenání vypracovaných postupů (how-to), zaznamenání
získaných znalostí, minimálně informací o informacích (rešerše).
Mám informaci, kam s ní?
Když nepřeskočíme výše zmíněný poslední bod –
zdokumentování - vyvstane další problém. Totiž,
jakým způsobem získané a vytvořené informace
uchovat. Tedy uložit a uchovat je tak, aby se daly
znovu využít.
Běžně se k zaznamenání využívá papírová forma,
rukopisně anebo tiskem. Jednak je to rychlé, relativně levné, je to ale také snadné a tradiční (ačkoliv
ještě tradičnějšího papyru a pergamenu se dnes už
bohužel neužívá). Výsledek - ve skříni se kupí složky
s dokumenty a poznámkami a popsané sešity.
Další možnost je uchovávat dokumenty v systému
složek a souborů ve svém počítači. Nebo jinou oblíbenou formou jsou záložky ve webovém prohlížeči.
Jakkoliv je autor záznamů pečlivý, tento způsob nebývá příliš efektivní. Jednak se řada informací ztrácí, překryta novými záznamy, a hlavně, vytvářené soubory dat (poznámky, textové soubory) jsou
v rámci pracoviště disjunktní a prakticky využitelné
jen jejich autorem.
V současnosti je ovšem k dispozici celá řada programových nástrojů na správu dokumentů, souborů, včetně utilit pro vytváření metainformací (autor,
stáří dokumentu, verze) a indexování obsahu.
Když se ale zamyslíme nad charakterem informací, jaký se uvádí výše, není jisté, zda by běžné DMS
(Document Management System) právě nám vyhovovaly.
Potřebujeme totiž systém, v němž by bylo možné, aby:
1. byl obsah systému široce dostupný,
2. šlo nově získanou informaci snadno zaznamenat,
3. zaznamenanou informaci bylo možné rychle najít,
4.byly úkony spojené s úpravou obsahu uživatelsky orientované, tj. aby bylo jasné, kdo, kdy
a co vložil, změnil a odstranil. Případně, aby bylo
možné nastavit nějaká pravidla omezující/rozšiřující uživatelská oprávnění,
5. bylo možné pracovat s různými typy dokumentu (text, multimedia, soubory).
On-line encyklopedie
Výše uvedené body splňuje dnes již celosvětově
známý software mediawiki. Tento software je základem pro většinu Wikipedií světa.
Wikipedie, kterou známe jako webovou encyklopedii, rozšířenou a používanou v mnoha lokalizacích, se dá poměrně snadno využít i v „uzavřeném“
firemním prostředí právě k tomu účelu, který potřebujeme.
1. S wikipedií se pracuje v prostředí (libovolného)
internetového browseru;
2. Vytvořit obsahovou stránku je možné v okně wikipedie:
- jako prostý text, s využitím formátovacích značek wikipedie, které není složité zvládnout,
- s využitím případného wysiwyg editoru,
- nebo je možné text vytvářet v externím editoru a exportovat do formátu wikipedie (to umožňuje například OpenOffice).
3. Hledání v obsahu probíhá podle konkrétních názvů položek – záznamů, následně fultextovým
vyhledáváním. Informace se dají kategorizovat
a tematicky seskupovat.
4. Výchozí vlastností encyklopedie je, že každý uživatel může vytvářet a upravovat její obsah a má
přístup ke všem položkám obsahu, kromě položek systému a správy.
Prostředí je uživatelsky orientované, tj. každý
uživatel se může identifikovat, vytvořit si pro
sebe vlastní uživatelské konto. To lze samozřejmě modifikovat a omezit možnost zakládání
kont svépomocí, anebo nastavit mapování uživatelů proti nějaké externí databázi. V návaznosti na to je rovněž možné definovat pravidla nakládání s obsahem na principu jmenných
prostorů, kterými se systém rozčlení, a uživatelských rolí k nim vázaných.
5. Obsah encyklopedie se prvotně vytváří jako text
– případně doplněný obrázky. Nicméně do systému se dají importovat i další typy souborů –
multimedia (flash, video, zvuk), soubory ke stažení (přípustné formáty souborů lze definovat
v konfiguraci).
Mediawiki software použivají pro vytvoření vlastní znalostní báze nejen webové projekty, například
dále zmiňovaný Moodle (www.moodle.org), ale
i instituce, například ČVUT, Masarykova univerzita
Brno, některé ústavy a fakulty Univerzity Karlovy.
Malý oslí můstek..
Informace nestačí jen vytěžit a uchovat v systému
znalostní báze, je také potřeba čas od času zařídit,
aby se dostaly k nějaké cílové skupině – v našem
případě dalším specialistům, informatikům. Běžně se pořádají v rámci kolektivu, pracoviště či firmy
školení a workshopy. Je také možné sepsat a distribuovat nějaké to how-to, manuál či prezentaci. Oba
přístupy mají ale své vady na kráse. V případě faceto-face konfrontace je to jednorázovost a neopakovatelnost akce, takže ten, kdo se jí nezúčastní, přijde o mnoho podstatného. K dispozici zbudou jen
podpůrné materiály, sylabus či prezentace, a musíme se tak spolehnout na zprostředkované informace od účastníků akce. Naopak materiály dodané
v nějaké printable ready verzi mohou být komplexní a vyčerpávající, ale už v okamžiku, kdy se dostanou k uživateli, jsou ve větší či menší míře zastaralé.
Rovněž tu hraje velkou roli sama cílová osoba a její
nálada, únava, soustředění a ochota se učit.
LMS
LMS je zkratka pro Learning Management System,
který častěji a nepřesně označujeme jen jako e-learning.
Source pod licencí GNU GPL).
Použitím LMS můžeme dostat proces vzdělávání
takříkajíc „pod kontrolu“. Správně navržený e-learning zajišťuje:
- Přístup ke vzdělávacímu obsahu pro tutora (učitele, vyučujícího) a účastníka (žáka) nezávisle na místě a čase, oba pracují ve virtuální třídě dle svých potřeb a možností. Samozřejmě až na vyjímky, kdy jde
například o on-line konferenční uspořádání;
- Možnost kontroly aktivity účastníků ze strany učitele, včetně využití nástrojů pro hodnocení. Je zde
snažší přizpůsobit se individuálním schopnostem
a potřebám každého účastníka;
- Systémy často umožňují vazbu do PIM (Personálního informačního managementu) firmy, školy, instituce;
- Zpětnou vazbu mezi účastníkem a vyučujícím.
E-learning vytváří prostředí pro komunikaci a pro
kooperativní jednání mezi jednotlivými účastníky,
i když je mezi nimi třeba geografická bariéra;
- Jednou z nejsilnějších zbraní při použití LMS je jiný
přístup ke vzdělávacímu procesu, než na jaký jsme
zvyklí. Účastník e-learningového kurzu není jen
pasivním objektem vzdělávání, kdy kantor jest ten,
kdo učí, žáci pak ti, kteří se učí. Účastník se naopak
stává aktivním prvkem tvorby vzdělávacího obsahu.
Pod tím pojmem se nám asi nejčastěji vybaví různé vzdělávací aktivity v prostředí internetu, od kurzů tantrické jógy, přes jazykové kurzy, až po systémy univerzitního distančního vzdělávání. Za tím
vším je ale vždy nějaký softwarový nástroj pro řízení vzdělávacího procesu.
Účastníky je možné rozčlenit do pracovních skupin pro zpracování úlohy a využít na jedné straně
kooperační a na druhé straně kompetiční prostředí pro to, aby co nejefektivněji zvládli dovednosti
a znalosti.
Pro naše prostředí jsme se zaměřili na LMS Moodle, který je vcelku v domácím prostředí rozšířený
(a za určitých podmínek ho lze využívat jako Open
Jak tedy využít LMS v rámci našeho modelu softwarové firmy? Příkladů může být mnoho. Často zmiňovanou úlohou je plán integračního procesu nové-
5
ho zaměstnance. Příchozí pracovník je nucen v co
nejkratší době zvládnout různé obecné úlohy – seznámit se s pracovním prostředím firmy a jeho pravidly, podstoupit povinná školení (BOZP, požární
ochrana, etika pro pracovníky firmy) a dále se adaptovat na svou novou práci a její náplň. Postupné absolvování dílčích kurzů firemního e-learningu podle schématu sestaveného šikovným personalistou
není špatný nápad.
Jinou zvažovanou úlohou je potřeba specializace –
rozšíření znalostí. Pokud jde o opakující se situaci,
je mnohem efektivnější, aby existoval e-learningový kurz (udržovaný na aktuální úrovni), než pořádat
další a daší školení jednou za čas. K již absolvovaným kurzům se mohou jejich účastníci vracet podle své potřeby.
E-learningovou formu můžeme také použít na podporu svých produktů směrem k zákazníkům – je to
efektivnější, než aktualizovat dokumentaci a pořádat nová školení pro tytéž účastníky.
A na závěr poznámka, jak spolu souvisí
znalostní báze a e-learning?
Pochopitelně velmi úzce. Díky modularitě většiny LMS (Moodle nevyjímaje) bývá znalostní báze
typu wikipedie součástí systému LMS anebo jsou
s ním úzce propojené. Obsah báze pak slouží jako
opakovatelně využitelná součást vzdělávacího
obsahu jednotlivých kurzů. Nástroje wiki se také
používají při vzdělávacím procesu, například při
vytváření „slovníku pojmů“ pro konkrétní kurz
jeho účastníky.
Pavel Körner
5
Iteracemi proti rizikům
Nepletu-li se, je to již potřetí, co se na stránkách komixích novin dotýkám tématiky iteračního vývoje. Možná někoho napadne: obehraná písnička. Budiž. Jsem však přesvědčen, že osvěta v této oblasti
je stále aktuální a má smysl se k ní průběžně vracet.
Tentokrát bych se rád na použití iteračního vývoje
podíval především z hlediska eliminace klasických
rizik, která přináší snad každý – nejen softwarový
– projekt. První z rizik lze charakterizovat jako „riziko nesprávného pochopení“. Obzvláště dělámeli první projekt u nového zákazníka, pouštíme se
do nové problematiky či začínáme pracovat s novým týmem, můžeme si být téměř jisti, že vytvořené dílo nebude 100% odpovídat potřebám uživatele. Zárodky těchto nedokonalostí vznikají již
ve fázi analýzy, kdy zadavatel nesprávně formuluje své potřeby a/nebo naši analytici jim chybně porozumí. V následných fázích návrhu a implementace se tyto odchylky většinou dále prohlubují a často
k nim přibývají další způsobené tím, jak analytické
zadání pochopil návrhář, resp. jak návrh pochopil
programátor.
Druhé typické projektové riziko, které se však nezmiňuje tak často jako to výše uvedené, bych nazval „rizikem obtížných začátků“. Opět a možná ještě více než u předchozího se toto riziko uplatňuje
na projektech v novém prostředí. Ať máme k dispozici sebezkušenější tým, vždy musíme počítat s tím,
že na začátku každé, na daném projektu dosud neprováděné činnosti, se objeví komplikace, které
jsme dopředu nebyli schopni odhadnout. Projevuje se to v úvodu analytické fáze, kdy nás často zdržuje potřeba nalezení společné řeči se zákazníkem.
Podobně na začátku implementačních prací trvá
nezanedbatelnou dobu, než vznikne plně funkční a efektivní vývojové prostředí. Snad nejčastěji
dochází k problémům, když se vytvořené aplikace
přenášejí z interního vývojového prostředí do prostředí integračních a zákaznických testů. Čím více
různých subjektů se na projektu podílí, přičemž je-
jich dílčí výstupy se právě v této fázi začínají spojovat dohromady,
tím větší chaos vzniká a téměř vždy dochází k ohrožení projektových termínů.
Obě výše uvedená rizika mají společnou příčinu v naivní víře v soulad
teorie s praxí. V prvním
případě jde o přesvědčení, že jsme schopni za- Riziko spojené s problémy vznikajícími na začátku nově prováděných činností.
že si vyhradíme dostatečné množství času na tesdání správně zanalyzovat a pochopit (teoreticky)
tování – na většině projektů to však nebývá moža podle toho vytvořit odpovídající dílo. Ve druhém
né, protože termíny jsou již dopředu napjaté a času
věříme našim zkušenostem z předchozích projektů
na realizaci je málo. U iteračního přístupu díky průa tomu, že jsme podobné činnosti jež mnohokrát
běžné zpětné vazbě toto „riziko nepochopení“ nedělali, a jsme tudíž schopni je dobře rozplánovat.
bývá zdaleka tak fatální.
Na těchto domněnkách, dle praktických zkušeností často mylných, je založen vodopádový životní cyklus. Iterační přístup se naopak snaží uvedené
problémy omezit průběžným ověřováním výstupů
a postupným zdokonalováním projektových postupů.
Zkusme k oběma rizikům přistoupit malinko vědecky a „namodelovat“ si je, jakož i způsob jejich eliminace. Na prvním obrázku je naznačen průběh vodopádového a iteracemi řízeného projektu formou
vycházející z tzv. V-modelu. Tento lze chápat jako
graf zobrazující průběh množství nejistoty, že vzniká to, co zákazník skutečně potřebuje (a ve správné kvalitě) v závislosti na čase. Během analytických,
návrhových a konstrukčních prací tato nejistota narůstá, protože nemáme k dispozici jasné potvrzení, že vytvářené dílo odpovídá původnímu záměru.
Teprve v jednotlivých fázích testování se postupně dopracujeme k poznání, zda je dílo kvalitní (bez
vad) a zda vyhovuje potřebám zákazníka. Z grafu
je patrný velký rozdíl v míře nejistoty s jakou pracujeme na vodopádovém projektu (silná barevná
čára) ve srovnání s iteračním přístupem (tenká barevná čára). Je
zřejmé, že pokud zjistíme nějaký principální
problém při testování
ve vodopádem řízeném projektu, zásadním způsobem klesají
naše šance na dodržení projektových termínů a kvality. Teoreticky lze riziko omezit při
plánování projektu tím,
Průběh vodopádového a iteracemi řízeného projektu.
6
Druhý obrázek schématicky znázorňuje riziko spojené s problémy vznikajícími na začátku nově prováděných činností (jednotlivé barvy znázorňují stejné aktivity jako na prvním obrázku). Riziko je
tentokrát zobrazené jako množství chaosu na projektu v závislosti na čase. Ve vodopádovém projektu jsou sice jednotlivé „chaosy“ rovnoměrněji rozděleny do celého průběhu projektu, problém je ale
v tom, že činnosti, které mají největší sklon k chaotičnosti (a tím zvyšování rizika), začínají až v pozdních fázích projektu. To je v době, kdy se typicky
již dohánějí jiné skluzy vzniklé v předešlých fázích
a další zdroj zmatků se již může stát fatálním (minimálně má negativní vliv na psychiku členů týmu,
kteří se beztoho již dostávají do velkého tlaku).
V iteračním přístupu se většina aktivit rozbíhá již
v počátečních fázích projektu, což sice zvyšuje celkovou chaotičnost v tomto období (v prvních iteracích se moc skutečné práce neudělá a s tím je třeba počítat při plánování projektu), ale je to v době,
kdy pro většinu členů týmu ještě není tak moc skutečné „tvůrčí“ práce a nenesou si s sebou „resty“
z předchozích fází projektu. A navíc, počáteční chaotičnost u jednotlivých aktivit nenabývá takových
rozměrů, protože dílo, se kterým se v úvodních iteracích pracuje, není rozsáhlé.
Důvodů pro použití iteračního vývoje je mnoho,
v tomto článku jsem se pokusil podrobněji vysvětlit dva z nich. Na závěr si dovolím vytyčit údernické
předsevzetí: Prosazujme a používejme na projektech iterační přístup a naučme tomu i naše zákazníky a partnery. Vyplatí se to nám i našim zákazníkům.
Petr Sobotka
Co je úlohou analytika (lepidlo, most a transformátor)
vány a integrovány. Na analytikovi zůstává průběžný dohled a zodpovědnost, že po věcné stránce
bude dodané řešení v souladu s tím, co zákazník
potřebuje. Analytik je „lepidlem“ zajišťujícím, že
dílčí výstupy vývojového týmu do sebe zapadnou
a budou tvořit smysluplný celek odpovídající očekáváním a cílům zákazníka.
Moderní metody vývoje softwaru kladou větší důraz na týmy složené z různých rolí a z pracovníků,
kteří nejsou úzce specializovaní, ale mají širší přehled a lepší předpoklady pro komunikaci mezi různými profesními rolemi uvnitř týmu. Analytik je příkladem takové role, kde je nutný širší záběr, protože
analytik je mostem při komunikaci mezi uživatelem
(tím, kdo má zájem na vytvoření softwaru) a technologií (vývojovým týmem).
V dnešní době se ekonomická krize dotýká i informačních technologií. Hlavním cílem je ušetřit, firmy proto odkládají IT projekty nebo se omezují na projekty zaměřené na udržení zákazníků, na zvýšení efektivity a na optimalizaci interních procesů. Přednost mají krátké projekty s konkrétními a rychlými přínosy. Krátké termíny realizace jsou často spojeny s nestabilními a nejasnými
funkčními požadavky zákazníka.
Tato situace není lehká pro analytiky. Aby analytik dokázal odlišit podstatné od nepodstatného
a mohl se soustředit na to podstatné, musí rozumět tomu, co jsou jeho hlavní úkoly ve vývojovém
týmu. Předchozí věta platí pro každou roli ve vývojovém týmu, a to nejen v oblasti IT. Ale narozdíl
od programátora, vedoucího projektu nebo testera, kde jsou jejich vstupy a výstupy obecně známé
a jasně vymezené, u analytika je situace poněkud
mlhavější. Pro někoho může být analytik zapisovatelem neuspořádaných požadavků zákazníka, pro
jiného návrhářem obrazovek, databáze a algoritmů, které programátor už víceméně jen mechanicky kóduje. Pokusme se tedy vyjasnit, co by měly být
hlavní úkoly analytika.
Následující specifikace pracovní náplně analytika
byla vytvořena odbornou skupinou analýzy (SANA)
ve společnosti KOMIX.
•
•
•
•
Úlohou analytika je
• Porozumět procesům, cílům a skutečným potřebám zákazníka, pro kterého pracuje, pomáhat mu hledat řešení jeho problémů, upozorňovat ho na rizika, navrhovat mu alternativy,
navrhnout způsob, jak bude dosaženo a měřeno
dosažení cíle.
• Identifikovat zúčastněné osoby a organizace,
kterých se navrhovaný systém týká.
• Specifikovat jednoznačné a ověřitelné požadavky na navrhovaný systém tak, aby tento
systém očekávaným způsobem podporoval pro-
7
•
•
cesy zákazníka při plnění jeho cílů. Dále specifikovat rozhraní s okolními systémy, požadavky
týkající se provozování systému a další typy požadavků. K řešení technických požadavků včas
přizvat příslušného specialistu.
Vymezit rozsah řešení v takové úrovni podrobnosti, aby bylo dosaženo shody se zákazníkem
na tom, co je předmětem nabízeného řešení a co
jde nad rámec dohodnutých prací a aby bylo
možné odhadnout pracnost.
Rozumět potřebám vývojového týmu a umět mu
specifikovat požadavky na systém takovým způsobem, aby byly dostatečným a srozumitelným
podkladem pro vývoj. Požadavky mohou být
dále upřesňovány se zákazníkem v mezích dohodnutého rozsahu řešení.
Průběžně se účastnit vývoje řešení včetně testování s cílem dohlédnout, že po věcné stránce řešení splní potřeby a očekávání zákazníka.
Vytvářet analytickou dokumentaci, která
umožní dlouhodobý provoz aplikace, její rozvoj
a zpracovávání změnových požadavků.
Podpořit nasazení řešení u zákazníka tvorbou
uživatelské dokumentace, školením, konzultacemi.
Poskytovat zákazníkovi konzultace při provozu
systému a při rozhodování o jeho dalším rozvoji, umět posoudit dopad případných změn.
Důležité je vědět nejen odkud a kam most vede,
ale i kdo, proč a jak často po něm chodí. Podle [1]
je vývoj softwaru především transformací znalostí
do podoby umožňující jejich strojové použití - tím
se software liší od jiných produktů. Proto je tolik
důležitá trasovatelnost požadavků (schopnost vysledovat původ požadavků a způsob jejich realizace), která zachycuje tuto transformaci. Pokud se
podaří znalost, která je v hlavách lidí a v dokumentech v určité firmě převést (s přispěním analytika
jako mostu) do softwarové aplikace, je přínosem
nejen vytvoření této aplikace, ale i získání týmu
schopného znalosti z určité problémové oblasti
tímto způsobem efektivně transformovat. Aplikace je nasazena, tým je rozpuštěn nebo redukován
pro účely technické podpory provozu a je zde riziko, že schopnost efektivní transformace znalostí
bude ztracena.
Protože znalosti se vyvíjí a požadavky na software se mění, vznikne po čase znovu potřeba „přejít po mostě“. Analytik si proto musí být vědom,
že dokumentování postupu transformace znalostí do kódu programu (nemusí se jednat o mnohastránkové dokumenty, ale spíše o důslednost
dodržování jednoduchých pravidel zajišťujících
transparentnost celého postupu) neslouží jen jednorázovému nalezení cesty na druhý břeh. Dokumentace musí umožnit přejít po mostě i v budoucnosti, kdy se vývojový tým může změnit.
Odkazy:
[1] http://philarmour.wordpress.com/2009/01/
Tomáš Vahalík
Na projektu pracují specialisté s různými rolemi,
kteří se podílejí na celkovém řešení. Programátoři vytvářejí dílčí funkce, které jsou postupně testo-
7
Inxmail – efektivní e-marketing v praxi
Všechny organizace mají potřebu informovat. Nové
úspěchy, nové vlastnosti produktů, nové způsoby
využití, nové impulsy pro růst a další novinky mají
za cíl přilákat nové zákazníky a zapojit je do stávající komunity existujících spokojených zákazníků.
Převažující psanou elektronickou formou je dnes
e-mail. E-mailing využívá pro efektivní oslovení osvědčených technik písemné korespondence,
jako jsou personalizovaná oslovení, individualizovaný obsah, jednotný podnikový/produktový design a pravidelná nebo individuálně vyžádaná zasílání marketingového sdělení.
E-mail však není jediný písemný elektronický komunikační kanál, který se stal důležitým nástrojem
marketérů. Rostoucí zájem marketingových specialistů je soustředěn rovněž na využití populárních
sociálních sítí, jako jsou Facebook, LinkedIn, Twitter,
MySpace apod. Inxmail je pro komunikaci s těmito
komunitními aplikacemi připraven. Doplňkové moduly pro komunikaci se sociálními sítěmi ještě znásobí účinnost zaslaného marketingového sdělení a usnadní možnost jeho virálního šíření. Některé
zákaznické segmenty, jako například mladí lidé, považují navíc sociální sítě jako primární způsob vzájemné komunikace. Zaslání zprávy do sociální sítě
už není jen konkurenční výhodou, je zásadním ko-
munikačním kanálem v e-marketingovém komunikačním mixu.
Inxmail Professional je nejen robustní, ale i flexibilní. Robustní infrastrukturu využijí velké organizace. Celý proces e-marketingu a integrační možnosti
zůstává pod kontrolou zákazníka. Ale i řada menších organizací dnes potřebuje řešení, které jim
umožní dlouhodobý úspěch a profesionální užití.
Nedostatek disponibilních zdrojů pro vybudování
vlastní infrastruktury řeší Inxmail Professional možností hostovaného řešení. Zákazníci tak mohou využít další aplikaci, kterou nabízí KOMIX svým zákazníkům v rámci palety hostovaných služeb.
E-mailing je zkrátka schopnost zaslat elektronicky
správnou zprávu správné osobě správným formátem ve správný čas. Jednoduše řečeno. Ale dokážete všechny tyto aspekty e-mailingu snadno a spolehlivě naplnit?
KOMIX pokrývá oblast e-marketingu produktem
společnosti Inxmail, který se jmenuje Inxmail Professional. Mailing v Inxmail Professional přináší marketérům a obchodníkům řadu významných výhod.
Mezi zajímavé vlastnosti Inxmailu patří možnost zaslání velkého množství personalizovaného sdělení
během velmi krátké doby (až 1 milión zpráv do jedné hodiny), oddělení tvorby obsahu od vzhledu
(vzhled je dán předem definovanou šablonou), dynamická kompozice e-mailu dle segmentů příjemce (dle typologie, skupiny, geografického aspektu
atd.), generování personalizovaných vrstev do PDF
přílohy (podklady pro smlouvu, slevový kupon
na jméno apod.), automatizované rozeslání e-mailů
(narozeniny uživatele, svátek, definována akce uživatele ve webové prezentaci pro tzv. look marketing), kontrola vzhledu zprávy před jejím odesláním
v různých e-mailových prohlížečích, sledování, zdali zaslání zpráv vedlo k jejich otevření atd. Schvalovací work-flow, zabudovaný reporting, otevřené
a zdokumentované API, společně s celou řadou doplňkových modulů (např. CAS genesisWorld CRM,
Microsoft CRM, Drupal atd.), provedení testu kvality e-mailu (antiphising, antispam), synchronizace
databáze adres se systémy třetích stran a další směřují Inxmail do business oblasti, kde jsou jeho funkce velmi pozitivně oceňovány.
Velmi cennou informací pro marketéry je zpětná
vazba. Možnost zjistit odpovědi na otázky: Kteří zákazníci jak a kdy otevřeli zaslaný e-mail? Kdo klikl
na obsažený odkaz? apod. Odpovědi na tyto otázky podávají velmi cenné informace, které umožňují
nejenom vytvářet pokročilé behaviorální segmentace, ale jsou rovněž základem pro reálná vyhodnocení úspěšnosti marketingových kampaní.
8
Miroslav Žebrák
QV na všechno a pro každého
Pokud o čemkoliv někde čteme, že je to na všechno, pro každého či podobně, tak se posléze velmi
často ukáže, že je to spíše na nic. V následujících řádcích vám, vážení čtenáři, přiblížíme, že v případě produktu QlikView platí nadpis článku v plném rozsahu.
Takže nejprve rychlé přiblížení. Produkt QlikView
je založen na patentovaném principu tzv. asociativní in-memory analýzy (IMA), která umožňuje uživatelům zkoumat data zcela libovolným způsobem
bez jakýchkoliv omezení. Veškerá data (metadata,
ETL services, vlastní dimensionální i faktové údaje)
jsou načítána z datových zdrojů a následně uložena do souboru na disku. Při práci koncového uživatele s QlikView aplikací je vždy celý soubor načten
do paměti počítače, a tak je vždy k dispozici jak úplný datový model (tj. možnost zadávání jakýchkoliv
kombinací výběrových kriterií), tak i všechny faktové údaje. Tímto způsobem je zajištěno, že odezvy
i na velmi komplikované dotazy nad velkými soubory dat (stamiliony řádků) jsou buď okamžité či
v řádu jednotek sekund.
Výše uvedený popis může, v tuto chvíli ještě celkem
oprávněně, budit u čtenáře jistou nedůvěru jak
ve funkčnost, tak zejména ve výkonnost produktu
QlikView. Stejnou či ještě větší nedůvěru jsme pociťovali i my při prvním ověřování vlastností produktu QlikView. Zvolili jsme proto cestu nejmenšího odporu a pro ověření jsme převedli do prostředí
QlikView jednu z aplikací referenčního projektu datového skladu pro ZP MV ČR. Jednalo se o datové
tržiště „Kmen pojištěnců“ realizované v prostředí
MicroStrategy s daty uloženými v DB Informix. Rozsah datového tržiště odpovídal cca 130 mil. záznamům provozního IS, atomická tabulka faktů byla
v rozsahu cca 35 mil. záznamů a pro účel testovaného souboru výstupů byla využita agregovaná faktová tabulka o rozsahu cca 9 mil. záznamů. Doby
odezvy v prostředí MicroStrategy + DB Informix se
pohybovaly v rozsahu cca 1 – 3 minuty pro jednodušší výstupy, přes cca 5 – 7 minut pro náročnější výstupy, až po 14 a více minut pro ty nejrozsáhlejší výstupy. Po převedení datového tržiště „Kmen
pojištěnců“ do prostředí QlikView jsme s napětím
očekávali výsledek. Rádi na tomto místě konstatujeme, že výsledek předčil očekávání. Doby odezvy
byly buď okamžité, nebo v řádu 1 – 2 sekund pro
převážnou většinu výstupů. Pouze ty nejrozsáhlejší výstupy měly „měřitelnou“ dobu odezvy v rozsahu cca 5 – 6 sekund. Zdůrazňuji, že QlikView aplikace byla realizována nad identickým rozsahem dat.
Je tedy zřejmé, že po výše popsané zkušenosti
jsme již neváhali a s plnou důvěrou jsme produkt
QlikView nasazovali v dalších aplikacích. Po tomto
poněkud rozsáhlejším úvodu se konečně dostáváme k první části tohoto příspěvku, a sice
9
QV na všechno - BI & DWH & MIS
Doposud jsme byli zvyklí, že v oblasti BI & DWH &
MIS jsme se z větší části zabývali tzv. nadstavbovými řešeními, kdy se z prostředí jednotlivých provozních IS načítaly vybrané údaje, ty se následně integrovaly a nad takto získanými údaji byly k dispozici
různé statistické, analytické a další výstupy. Tyto
principy byly beze zbytku realizovány v prostředí
produktu QlikView.
Zásadní skutečností je však univerzálnost a rychlost realizace projektů v prostředí QlikView. Jak
mnozí víme, tak firma KOMIX s.r.o. v oblasti BI &
DWH & MIS realizovala v minulosti projekty zejména pro instituce typu ČSSZ, zdravotní pojišťovny,
GŘ cel a podobné instituce.
Jaké změny tedy přinesla realizace srovnatelných
projektů v prostředí QlikView ?
a) Doba realizace
Doba realizace výše uvedených projektů byly řádově člověkoměsíce. Realizace srovnatelných projektů v prostředí QlikView je výrazně kratší – jedná se
o člověkotýdny.
b) Oblasti nasazení - Zákaznické portfolio
Díky rychlému a snadnému vytvoření projektů se
podařilo proniknout s BI & DWH & MIS řešeními
v prostředí QlikView i do oblastí, které doposud nebyly nijak pokryty. K dnešnímu dni je realizována
řada QlikView projektů pro firmy z oblasti retailu, finančnictví na straně jedné ale také pro výrobní či
provozní firmy na straně druhé.
rých jsou zapisovány údaje o provozu serverů, aplikací a další technické a technologické záležitosti.
Je tedy zřejmé, že tato oblast má velmi blízko k provoznímu reportingu. Realizované QlikView aplikace
pak umožňují sledování a vyhodnocování vytížení
serverů, mapování provozu aplikací, identifikaci úzkých míst, dlouho trvajících činností apod. Veškeré výstupy jsou pak k dispozici v maximálně přehledném
členění, umožňují sledování a vyhodnocování libovolných údajů za libovolné období v libovolném členění, vše opět s maximálním uživatelským komfortem.
QV pro každého
Uživatel má pro sledování a vyhledávání požadovaných údajů k dispozici skutečně interaktivní nástroj.
Pro práci s aplikací v prostředí QlikView potřebuje
pouze ty činnosti a znalosti, které využívá v prostředí MS Windows (používání myši, označení seznamu,
výčtu položek, označení výseku grafu).
Při práci s aplikací v prostředí QlikView není uživatel žádným způsobem omezován. Odezvy na libovolná zadání jsou i při velkých objemech dat (stamiliony záznamů) okamžité či v řádu jednotek sekund.
Aplikace v prostředí QlikView poskytují koncovým
uživatelům na jednotlivých úrovních údaje v požadovaném členění a s okamžitou dobou odezvy.
K dispozici mohou být jak přehledové údaje (např.
dashboardy), tak samozřejmě jakékoliv tabulkové či
grafické údaje, např. v níže uvedeném členění.
c) Oblasti nasazení – Provozní reporting
Jak již bylo výše uvedeno, drtivá většina BI & DWH &
MIS řešení byla doposud určena pro tzv. nadstavbová řešení. S osvojením produktu QlikView nově s výhodou pokrýváme i celé či významné části provozního reportingu, tj. reportingu, který byl doposud
řešen převážně v prostředí provozních IS či nesystémovými doplňkovými způsoby (MS Excel a podobně). Příkladem za všechny může být např. realizace
klasických výstupů typu Rozvaha či Výsledovka. Řešení v prostředí QlikView tedy přináší zásadní výhody z prostředí BI & DWH & MIS (uživatelský komfort,
jedna verze pravdy, rychlost atd.) i pro koncové uživatele z prostředí provozního reportingu.
d) Oblasti nasazení – Technologický reporting
Nejprve snad kratičce, čemu pro účel tohoto článku
říkáme technologický reporting. Máme na mysli zejména vytěžování příslušných log souborů, do kte-
Samozřejmostí je pak možnost zobrazení požadovaného detailu i volbou příslušného výseku z grafického výstupu, jak je zřejmé z předchozího a na
následujícím obrázku.
9
tailní pohledy i na nejnižší úroveň detailu,
• v rámci QlikView aplikace mohu interaktivně zadávat jakékoliv kombinace výběrových kriterií
v libovolném členění v rámci celého datového
modelu,
• odezvy na jakýkoliv způsob zadávání na jakékoliv
úrovni jsou okamžité či v řádu jednotek sekund.
Vedle výše uvedených globálních či detailnějších
výstupů je samozřejmě v rámci jedné QlikView aplikace k dispozici i příslušná detailní informace, např.
v následující podobě:
Z výše uvedeného přehledu jsou tedy zřejmé tyto
základní vlastnosti aplikací v prostředí QlikView:
• jedna každá QlikView aplikace v sobě může zahrnovat jak globální přehledové výstupy, tak i de-
Více než tříleté zkušenosti s realizací projektů v prostředí QlikView nám zcela jednoznačně potvrdily optimisticky avizovanou skutečnost z nadpisu
tohoto článku – QlikView je skutečně na všechno
a skutečně pro všechny.
Pavel Seibert, Tomáš Třmínek
Reporting a analýza obsluhy ICT požadavků
Téměř při všech lidských činnostech, jejichž cílem je poskytovat služby většímu počtu zákazníků,
vznikla pracoviště, jejichž hlavním úkolem bylo sloužit těmto zákazníkům jako kontaktní místo.
Místo, kde si mohou službu objednat, kde jim jednodušší záležitosti na počkání vyřídí a složitější
zaevidují, nejistého zákazníka uklidní a seznámí ho s postupem, jak a kdy bude jeho požadavek vyřizován a co je či naopak není očekáváno od něho. Zaevidované požadavky čekající na další zpracování přirozeně nemohou zůstat jen v paměti obsluhujících, ale každé takové pracoviště mělo a má
svůj systém evidence. Takové pracoviště není objevem ICT průmyslu a nemusíme si ho představit
jen jako kontaktní místo velkých telekomunikačních operátorů vybavené IP telefonií a CRM systémem světových parametrů. Hotelová recepce sice obsluhuje mnohem méně klientů než provozovatel elektrické sítě, na druhé straně spektrum služeb, které hotelovým hostům zajišťuje, je o poznání širší. Tak či onak zákazníci získali jistotu, kam se mohou se svým požadavkem obrátit a dodavatel
má nad požadavky soustředěnými do jednoho místa snazší kontrolu.
ky nebo prostřednictvím datových sítí, nevystačí
s jednoduchou evidencí požadavků v papírové podobě, ba ani s elektronickou evidencí ve formě dokumentů tabulkových kalkulátorů. Taková pracoviště musí být vybavena programy, které nejen evidují
došlý požadavek, ale umožňují sledovat průběh řešení od začátku do konce, plánovat termíny a sledovat zdroje. Pro pracoviště tohoto typu se vžil název Help Desk.
Základní filosofie všech softwarových nástrojů pro
evidenci požadavků, které se někdy označují jako
„Trouble Ticket“ nebo „Issue“ systémy, je velmi podobná.
• Každý došlý požadavek musí být zaevidován tak,
aby bylo jasné, kdo a kdy ho vznesl a bylo možné
se vracet k historii jeho řešení.
• Umožňují sledování průběhu řešení a komunikaci mezi uživateli a řešiteli.
• Umožňují dohledání odpovědnosti za vyřízení
nebo nevyřízení požadavku.
• Nabízejí statistiku a reporting činností.
Pochopitelně, že na větších pracovištích, která pokrývají rozlehlé regiony, obsluhují za den desítky a stovky klientů a komunikují s nimi telefonic-
10
Když jsme v roce 2006 vybírali pro potřebu našich
interních i navenek poskytovaných služeb technické podpory vhodný „Trouble Ticket“ nástroj, hodnotili jsme produkty od těch nejvíce renomova-
ných, přes systémy psané tuzemskými výrobci až
po produkty ze světa Open Source software. Volba
nakonec z více důvodů padla na Open Source balík OTRS (Open Ticket Request System). Chtěl bych
na tomto místě podotknout, že v době výběru jsme
měli velmi jasnou představu o tom, jak chceme
mít dále technickou podporu organizovánu a jaké
vlastnosti od softwarového produktu očekáváme.
Díky ujasnění vlastních pracovních procesů a „přívětivému“ způsobu administrace se budoucí administrátoři začali začátkem ledna s produktem OTRS
seznamovat a prvého března téhož roku jsme spustili OTRS pro podporu vlastních zaměstnanců, která
bez větších změn funguje dodnes.
V čase implementace jsme jednoznačně upřednostňovali vlastnosti, které se týkají řízení životního cyklu požadavku a které byly u všech hodnocených softwarových balíků velmi podobné.
Na první úzká místa námi vybraného řešení jsme
narazili při přípravě našich služeb na certifikaci
podle normy ISO 20000-1, která vychází z metodiky
ITIL. Pracoviště Help Desk se začalo nazývat Service Desk a nad službami, které koncoví uživatelé využívali, jsme definovali procesy, které mají provoz
těchto služeb zajišťovat. Tedy podle označení ITIL
procesy Incident, Problem a Change Management.
Norma vyžaduje, aby byly jak uvedené procesy, tak
vlastní služby řízeny. Klíčovou otázkou je, co vše si
představit pod pojmy řízení procesu a získání kontroly nad požadavky. Řídit znamená mimo jiné být
schopen měřit. Nepostačuje už tedy, že se na žádný
požadavek nezapomene a že se informace o jeho
vyřízení dostanou do účtárny.
Lidé, kteří mají řízení služeb v popisu práce, jistě
velmi dobře vědí, jaké hodnoty sledovat, aby měli
správný přehled. Jiná otázka je, zda software, kte-
rý používají, umí primární čísla ukládat a vypočíst
z nich požadovanou statistickou hodnotu. Přestože primární data byla v databázi našeho Service
Desku uložena, museli jsme se na začátku spokojit
s reporty o počtu nových či vyřešených požadavků za časové období, přehledu neuzavřených požadavků a díky možnosti exportovat data do Excelu
s časem potřebným k řešení podle jednotlivých řešitelů nebo zákazníků.
Velmi nám chyběly metriky, které popisují kvalitu
služby směrem ke koncovému uživateli, jako je maximální doba odezvy nebo vyřešení požadavku. Situace byla o to komplikovanější, že u různých služeb a různých zákazníků byly garantované hodnoty
těchto metrik odlišné. Přitom uvedené metriky vypovídají o tom, do jaké míry podmínky, ke kterým
jsme smlouvou zavázáni, plníme. Usuzovat na základě těchto metrik, zda máme v kapacitách rezervu či zda s dalším zákazníkem může být kvalita poskytovaných služeb ohrožena, není v podstatě
možné.
Pracné a nedokonalé zjišťování pomocí SQL dotazů se změnilo poté, co jsme využili příležitosti, která se nabízela ve vyzkoušení nástroje pro Business
Intelligence QlikView, který naše společnost na českém trhu distribuuje. Ukázalo se, že ani „drobná“
aplikace pro podporu Service Desk není dost malá
k tomu, aby nad ní nešlo implementovat „přiměřený“ managerský informační systém pro několik
málo uživatelů. Přiměřenost spočívala jak v ceně licencí, tak v jednoduchosti softwarové architektury
a z ní plynoucích nároků na hardwarové vybavení.
Příjemným překvapením byl krátký čas, v jakém se
aplikaci podařilo vyvinout, rychlost s jakou pracuje
a především statistické a analytické informace, které máme díky ní k dispozici.
Rychlost vyřizování požadavků dnes můžeme hodnotit podle maximální i průměrné doby odezvy
nebo doby řešení. Obě metriky mohou být dále kategorizovány podle typu požadavků, jejich priority,
zadavatelů i jednotlivých řešitelů. Pro služby typu
technické podpory bývá charakteristické, že převážná část požadavků je sice obsloužena v nějakém
typickém čase, menší část je ale vyřízena v čase,
který ten typický výrazně převyšuje. Pro posouzení
tohoto jevu používáme namísto průměrných hodnot statistické veličiny medián a percentil. Např.
v jedné skupině požadavků je průměrná doba jejich řešení 8 dnů, nicméně
• 50 % je vyřešeno už za 3 dny,
• 60 % je vyřešeno do 4 dnů,
• 75 % je vyřešeno v průměrných osmi dnech,
• 80 % je vyřešeno za 11 dnů a
• 90 % za 15 dnů,
což je téměř dvojnásobek průměrné doby. Maximální doba řešení byla potom 65 dnů. Vidíme, že
asi 20 % požadavků podstatným způsobem zhor-
11
šuje kvalitu služby a v samostatném okně si lze prohlédnout seznam požadavků, které do tohoto souboru patří. Detailní zkoumání historie jednotlivých
případů je ovšem možné jen přímo v „Trouble Ticket“ systému.
Podle podobných dimenzí lze prohlížet i pracnost
potřebnou pro řešení požadavků. Ta je ještě rozšířena o pohledy dle jednotlivých řešitelů a zadavatelů. Vidíme, kolik bylo na řešení požadavků vykázáno
času celkem a kolik v jednotlivých měsících, kolik
hodin vykázali jednotliví pracovníci podpory a pro
které zadavatele. Výstupní informace jsou prezentovány formou tabulek i přehledných sloupcových
a spojnicových grafů a jiných grafických prvků.
Použití Business Intelligence nástroje výrazně rozšířilo vlastnosti běžného Trouble Ticket systému.
Jeho cena za licence a implementaci byla přitom
v relaci s cenou za implementaci základního Open
Source balíku. Oblast reportingu a analýzy dat
máme pokrytu v rozsahu, který přesahuje naše původní očekávání a změní-li se v budoucnu v tomto
ohledu naše potřeby, nejsme s úpravami odkázáni
na výrobce software, což si přiznejme, je v případě
krabicového řešení téměř nerealizovatelná představa.
Otakar Ludvík
Doba obsluhy požadavků, 80tý percentil
Přehled vykázaných hodin
11
Školíme
Jak se můžete dočíst nejen na stránkách komixích
novin, jedním z produktů, které společnost KOMIX
s úspěchem nabízí, je software QlikView z oblasti Business Intelligence. QlikView umožňuje rychlou a kvalitní analýzu velkých objemů dat a uživatel, který absolvuje některé z našich školení, může
všechny možnosti tohoto nástroje s úspěchem využívat. Školení, která KOMIX nabízí, jsou vedena
certifikovanými lektory a doplňují tak naši nabídku licencí a implementačních služeb produktu QlikView.
menzí (úhlů pohledu). Posluchači se dozví, k čemu
je vhodný jaký objekt, jak vytvářet objekty nové
nebo kopírovat existující objekty a upravovat jejich
vlastnosti. Seznámí se s možnostmi formátování
a jednotného nastavení designu, dále s vytvářením
komplexních reportovacích sestav, možnostmi exportu nebo s použitím záložek. V rámci školení Designer se používají již připravené datové struktury
načtené do QlikView dokumentů.
Developer
Úvodem je třeba poznamenat, že běžný koncový
uživatel, který používá připravené reporty v QlikView pro svoji analytickou činnost a intuitivně pomocí myši provádí filtrování dat, žádné školení nepotřebuje, postačí mu pouze krátké zaškolení. Školení
je tedy určeno uživatelům, kteří mají zájem sami
načítat data do QlikView a vytvářet nové reportovací objekty – tabulky či grafy. Síla QlikView spočívá kromě jiného v jeho jednoduchosti a jednoduchá je i příprava školení. V základní architektuře je
QlikView provozováno lokálně na PC jednotlivých
uživatelů, takže stačí během chvíle QlikView nainstalovat, ošetřit licenční záležitosti, nahrát si na PC
připravené QlikView dokumenty s příklady a školení může začít.
Druhé školení nazvané Developer je zaměřeno
na načítání dat z různých zdrojů do QlikView dokumentů (souborů). Jediný QlikView dokument totiž
obsahuje jak definované objekty, tak reportovaná
data v potřebných strukturách. Posluchači jsou seznámeni s načítáním dat z databází, textových souborů nebo Excelu, kombinací několika datových
zdrojů v rámci jednoho dokumentu, tvorbou vazeb
mezi tabulkami nebo jejich potlačením. Školení zahrnuje použití funkcí při skriptování, optimalizaci
skriptu a různé operace nad zdrojovými daty, které zajistí optimální podobu datových struktur v QlikView dokumentu tak, aby „designéři“ mohli snadno vytvářet kvalitní reporting. Školení Developer
je tedy určeno těm uživatelům, kteří budou načítat podniková data ze zdrojových databází do QlikView.
Designer
Průběh školení
Školení nazvané Designer seznámí účastníky se
všemi typy reportovacích objektů v QlikView, přiblíží jim možnosti definování výrazů (metrik) a di-
Osnovu obou výše uvedených školení naleznete
na webu společnosti KOMIX (http://www.komix.cz)
v sekci Produkty a služby - Školení – Prostředí Qli-
Pro koho jsou školení určena
kView. Samozřejmě se náplň obou školení částečně prolíná, a protože spolu obě části úzce souvisí,
je vhodné, aby alespoň někteří posluchači absolvovali obě části. Na druhou stranu, použití QlikView
pro čistě koncového uživatele je velmi snadné, takže není nutné, aby se „pro jistotu“ zúčastnil vývojářského školení. Školení je prováděno nad cvičnými
daty popisujícími obchodní firmu, která prostřednictvím svých prodejců vyřizuje objednávky svých
zákazníků z celého světa. Občas zákazníci požadují, aby školení bylo prováděno nad jejich vlastními
daty. Podle našich zkušeností je ale lepší vyzkoušet
si všechny běžné problémy a jejich řešení na školících datech a příkladech, čímž posluchač získá jistý nadhled při práci s QlikView a není omezen svými specifickými požadavky či podmínkami. Pokud
po absolvování školení přetrvávají nejasnosti, jak
si poradit s reportingem nad vlastními daty, nabízí
KOMIX další spolupráci formou konzultací nebo samostatného vývoje.
Těšíme se na Vás
Doba každé části školení je 1,5 dne. Často si zákazník objedná obě části najednou a během tří dnů
jsou uživatelé vyškoleni. Dostanou samozřejmě
kompletní písemné materiály popisující náplň školení. Školení je možné připravit v prostorách naší
společnosti nebo u zákazníka. Pokud tedy chcete
využívat všechny možnosti produktu QlikView, rádi
Vás uvítáme na našich školeních.
Petr Matoušek
Využití BI nástroje
pro reporting
a analýzy v rámci dotačního programu Zelená úsporám
Případová studie pojednává o využití Business
Intelligence nástroje QlikView pro potřeby Státního
fondu životního prostředí v rámci administrace žádostí dotačního programu Zelená úsporám. Ve studii jsou naznačeny oblasti využití nástroje QlikView
jako nadstavbového řešení k informačnímu systému IS GIS od firmy KOMIX s.r.o. a jsou zdůrazněny
přínosy této aplikace pro běžnou operativu.
Informační systém IS GIS dnes slouží ke komplexní
administraci žádostí v programu Zelená úsporám.
V průběhu jeho vývoje byly postupně definovány
potřebné funkcionality pro evidenci žádostí o dotaci včetně Krycích listů technických parametrů.
V programu Zelená úsporám je v IS GIS registrováno za 1 rok existence již cca 20 tisíc žádostí o dotaci. Kromě identifikačních údajů o žadateli a nemovi-
12
tosti s realizovaným opatřením jsou u každé žádosti
evidovány desítky technických údajů, které jsou
kontrolovány z důvodu ověření splnění podmínek
programu Zelená úsporám.
Původní požadavky na reportování pomocí několika předdefinovaných sestav a generovaní exportních souborů ve formátu xls pomocí cca 30
výběrových kriterií se postupně ukázaly jako nedostatečné. Předdefinované sestavy byly základem
pro měsíční reporty a reporty pro ekonomický úsek
SFŽP. V okamžiku, kdy nový požadavek na report
obsahoval dosud nedefinovaná výběrová kriteria,
nebylo možné jej rychle splnit bez úpravy aplikace IS GIS. Z výše zmíněných důvodů došlo na podzim roku 2009 ze strany SFŽP k rozhodnutí využít
nabídky společnosti KOMIX vyzkoušet si práci s ná-
strojem ze skupiny Business Intelligence. SFŽP následně po úspěšném ověření nástroje v pilotním
provozu zakoupil licence nástroje QlikView. Předpokládaný přínos aplikace se začal ukazovat s prvními požadavky na funkčnosti a na plno se projevil
při tvorbě prvních reportů.
Pro práci s daty byl nástroj QlikView zvolen jako uživatelsky definovatelný nástroj pro snadný a rychlý
reporting jak v předdefinovaných sestavách, tak
i pro „ad hoc“ reporty. Tvorba těchto uživatelsky
definovaných reportů je pro středně pokročilého
uživatele poměrně jednoduchá a nevyžaduje spolupráci dodavatele aplikace. Při tvorbě náročnějších sestav (např. definování výpočtů emisí skleníkových plynů) byly výpočty definovány analytikem
společnosti KOMIX a následně prověřeny specialis-
tou úseku GIS. Tvorba výpočtového modelu trvala cca 2 dny, a tím se výrazně zkrátila potřeba času
a náročnost celého zavedení automatizace složitých výpočtů.
Díky možnosti definovat v prostředí QlikView pohledy na všechna data evidovaná v IS GIS se objevila další důležitá funkcionalita nástroje QlikView jako
masivního nástroje pro analýzu chybovosti těchto
dat. Požadavky na „ad hoc“ reporty se díky zájmu
médií rapidně zvýšily. V minulosti tyto požadavky
znamenaly často celodenní práci s daty. Při používání aplikace QlikView trvají tyto reporty jen několik minut.
Při základním porovnání procesů, funkčnosti, nároků na zdroje (HW, SW, pracovníci a jejich kvalifi-
kace), kvality a rychlosti výstupů a jejich použitelnosti je možné deklarovat, že používáním nástroje
QlikView došlo k výraznému urychlení a zkvalitnění výstupů, úspoře času a potřebných personálních
kapacit SFŽP. Vzhledem ke kladnému přijetí aplikace současnými uživateli se v budoucnu předpokládá i případné další rozšíření a využití nástroje
QlikView v rámci SFŽP.
Jiří Tománek
Rozhovor o informačním systému
dotačního programu Zelená úsporám
Dotační program Zelená úsporám administrovaný Státním fondem životního prostředí mohl
úspěšně odstartovat také díky informačnímu systému GIS dodaného společností Komix. Nejen
o systému GIS, ale také o dotačním programu jako takovém, jsme si povídali s odborným garantem
Ing. Zdeňkem Osmanczykem, vedoucím Oddělení informační podpory SFŽP.
Dobrý den pane Osmanczyku, mohl byste mi
prosím na úvod říci něco blíže o informačním
systému GIS? V čem jsou jeho přínosy? Jaké
údaje se v IS GIS evidují?
Jedná se o aplikaci, která umožňuje sledovat a vyhodnocovat celý životní cyklus žádostí o dotaci od jejího přijetí, kontroly správnosti údajů, schvalovacího procesu až po vyplacení podpory. Kromě
identifikačních údajů o žadateli jsou v systému evidovány také desítky technických údajů o nemovitosti, na niž byla úsporná opatření realizována. Všechny
údaje jsou pečlivě kontrolovány z důvodu ověření
splnění podmínek programu Zelená úsporám.
Kdy byl zahájen provoz této aplikace?
Tento informační systém pro evidenci žádostí o dotace z programu Zelená úsporám vyvinula firma Komix na jaře roku 2009 jako zakázkovou aplikaci pro Státní fond životního prostředí. Dotační
program byl oficiálně vyhlášen na Den Země, 22.
dubna 2009, teď již bývalým ministrem životního
prostředí panem Martinem Bursíkem.
Program Zelená úsporám asi není třeba představovat. Zajímalo by nás ale, o co lidé v tomto
dotačním programu nejvíce žádají?
last C). Z více různých opatření, která do oblasti C
spadají, je nejpopulárnější instalace solárně-termických kolektorů.
V této oblasti je tedy nejvíce alokovaných peněz?
Přestože v oblasti C je evidován nejvyšší počet žádostí o dotace, tak největší objem podpory připadá na zateplení rodinných a bytových domů, tedy
na oblast A. Zde se projevil vliv velkých projektů bytových družstev žádajících o podporu na zateplení bytových panelových domů. Tyto žádosti čerpají největší podíly v objemu dotací, jejich příjem
byl však počátkem září pozastaven.
A kolik žádostí bylo dosud podáno a jaký je přibližný finanční objem dotací?
Počet celkově podaných žádostí v programu překročil už 38 tisíc a tyto žádosti představují zhruba
12 miliard korun podpory. Schválených žádostí bylo
ke konci července více než 23 tisíc a prostředky rezervované na dotace činily bezmála 5 miliard korun. Vyplaceno bylo již téměř 7 tisíc žádostí.
Tak velký počet evidovaných žádostí představuje poměrně velké objemy dat. Jak u Vás probíhá jejich vyhodnocování?
Vyhodnocování žádostí probíhá na základě pravidelných měsíčních reportů dle předefinovaných
výběrových kritérií. Tyto reporty jsou pak postupovány ke schválení Radě fondu a zahraničním kupcům emisních povolenek. K detailnějšímu vyhodnocování je také aktivně využíván moderní nástroj
Business Intelligence QlikView.
Na jak dlouho je plánován dotační program Zelená úsporám? Máte v plánu dál rozvíjet informační systém GIS?
V srpnu 2010 byla podepsána s firmou Komix nová
smlouva na rozvoj a technickou podporu tohoto
úspěšného projektu, která vzešla z výběrového řízení a je platná po dobu trvání programu Zelená
úsporám, tj. do konce roku 2012.
Rozhovor vedl Jiří Tománek
Nejvíce žádostí evidujeme na podporu investic
v oblasti využití obnovitelných zdrojů energie (ob-
13
13
CASting – najděte svou STAR!
Záře světel, odrazy blesků fotoaparátů, nahrávací studia a předváděcí mola vždy a spolehlivě přitahují pozornost celé řady uchazečů o získání kariéry v mediální branži. Všichni jsou přesvědčení,
že oni jsou ti praví, nejhezčí a nejlepší pro získání
role v právě natáčeném filmu či seriálu, pro umístění cover fotografie do časopisu nebo pro promenádu na molu. Ale zákazník je náročný, vyžaduje konkrétní kritéria. Talent musí být dostatečně zajímavý,
mluvit anglicky, turecky a mít modré oči, blond
vlasy, jezdit na koni, střílet z kuše a kdo ví co ještě.
A jak se v tom velkém množství různých lidí vlastně
mám vyznat? Jak ho mám najít? Ne, není to noční
můra, je to realita. Desetitisíce fotografií a videí útočí na moje smysly. Bože, prosím zachraň mě, potřebuji systém. Volám S.O.S. Haló, Komix? Prosím, rychle, potřebuji CASting!
Haló, tady KOMIX. Jasně, za chvíli jsme u vás.
Co je CASting? CASting je multimediální webová
aplikace určená pro evidenci, vyhledávání a filtraci
talentů dle konkrétních požadavků zadavatele. CASting usnadňuje každodenní práci uživatelů pracujících s velkým množstvím talentů a k nim ukládaných informací. CASting vytváří předpoklady pro
řízené sdílení informací a disponuje systémem uživatelských práv. CASting je zabezpečené řešení,
které disponuje celou řadou bezpečnostních mechanismů. Z technického hlediska je CASting robustní škálovatelnou vícejazyčnou aplikací využívající moderní web 2.0 technologie. CASting je také
řešením pro budoucnost, je otevřeným systémem
pro další rozvoj a integraci se systémy třetích stran.
Komu je CASting určen? Je jedno, jestli jste malá
castingová či modelingová agentura, fotografické studio nebo velká televizní společnost, CASting
respektuje všechny velikosti firem. Pokud pracujete s talenty a jejich informacemi (včetně fotografií,
CASting
videí a dalších dokumentů) a potřebujete talenty
vyhledávat, výsledky předávat a komunikovat s talenty i produkcí, je CASting správná volba pro vás.
Jaké jsou základní výhody práce s CAStingem?
• Možnost evidence talentů s mnoha upřesňujícími údaji,
• rychlé vyhledání talentu,
• možnost vyhledání talentu podle všech uložených údajů,
• bohatá podpora multimédií (foto, video),
• integrovaný Document management system,
• podpora tiskových sestav ve formátu PDF,
• vysoká dostupnost a stabilita aplikace,
• přístup k datům odkudkoliv,
• a mnoho dalších...
CASting je založen na filozofii xRM (anything relationship management). Základní entitou je talent,
k němuž je ukládána velká množina vztažených informací. Navíc jsou prostřednictvím vazeb (relations) sledovány různé i další typy sekundárních informací (dokumenty, obrázky, videa, agentury,
projekty a další). Vazby umožňují sledovat komplexní pohled na aktivity spojené s talentem.
Mezi výjimečné a silné stránky CAStingu patří použité uživatelské rozhraní a práce s multimédii. Uživatel pracuje s CAStingem ve webovém prohlížeči
a přitom má pocit, že pracuje v prostředí operačního systému. Multimediální soubory jsou v CAStingu využívány na 100 %. Miniatury, vysoké rozlišení, plynulé přehrávání HD videí jsou samozřejmostí.
Mezi výhody práce v CAStingu patří i hierarchické
ukládání a vyhledávání dle dovedností, značkování
jednotlivých záznamů štítky (tagy), utajení talentu,
možnost tvorby vlastních filtrů a kolekcí. Zajímavou
funkcí je i sledování příbuzenských a jiných vazeb
mezi jednotlivými talenty. Samozřejmostí je i vysoká kvalita tiskových výstupů ve formátu PDF, umožňující okamžité sdílení výstupních sestav formou emailu. Komunikace je možná na úrovni individuální
či hromadného e-mailu a dopisu.
Výše zmíněné i nezmíněné možnosti a vlastnosti předurčují CASting k využití zejména v dynamických společnostech, které jsou si vědomi ceny informací a které pochopily, že i pro kvalitní práci
s informacemi v oblasti show byznysu je třeba kvalitního nástroje, který šetří čas a tím i peníze.
Miroslav Žebrák
14
SONEF – aneb schvalování dokumentů v praxi
Tento článek je věnovaný aplikaci, která vám může pomoci zefektivnit řízení vaší společnosti v oblasti procesu schvalování dokumentů, např. smluv, nabídek či dovolenek. V následujícím textu se
dozvíte nejen to, čím vám tato aplikace může být prospěšná, ale také se v jednotlivých částech článku podíváme pod pokličku technologického konceptu.
Koncept schvalování dokumentů, který byl dlouhou dobu provozován ve spoustě společností, byl
založen na oběhu papírů a nutnosti vyjádření se
k nim standardním způsobem. Tento princip narážel
na řadu omezení, kdy schvalovatelé dostávali k vyjádření dokumenty v papírové formě a byli nuceni provádět spoustu mechanických činností. Zlepšení tohoto procesu nastalo elektronizací dokumentů, kdy
se již tyto dokumenty nepsaly na psacích strojích, ale
vytvářely se pomocí textových procesorů a schvalovatelé se již vyjadřovali k takto elektronicky připravené podobě. Tato změna přinesla podstatné zlepšení. Pokud však společnost neměla vyřešený proces
oběhu dokumentů, většinou docházelo k postupnému schvalování, kdy byl dokument takzvaně uzamčen a dále po úpravách předán do dalšího kola, což
přinášelo řadu problémů. Tady jistě můžete namítat,
že je tento postup postačující. Každý ze schvalovatelů si vytvoří svoji revizi dokumentu a ve stanovenou
dobu se z těchto revizí vytvoří další verze dokumentu pro nové kolo vyjádření. V některých případech je
tato námitka oprávněná. Pokud však proces schvalování bereme v širším konceptu s ohledem na to, jaké
možnosti by nám měl poskytovat (například možnost zařazení schvalovatelů do procesu schvalování,
kdykoliv se podívat na vyjádření jednotlivých schvalovatelů v jednotlivých kolech schvalování, stanovit
práva uživatelů k informacím, informovat schvalovatele o nutnosti vyjádřit se a v neposlední řadě mít
možnost řídit samotný proces schvalování), tak vidíme, že si s pouhými revizemi nad dokumentem nevystačíme.
Pokud jste se dočetli až sem, tak jistě čekáte odpověď na otázku: „Co s tím?“ Tuto otázku jsme si položili v naší společnosti také. Jako odpověď vznikl
nástroj, který řeší potřeby, které jsme v rámci schvalovacího procesu měli. Prvním krokem bylo stanovení požadavků na nástroj. Další neméně významnou částí celého řešení bylo také zvolení správného
technologického konceptu. Základním požadavkem byla možnost navrhovat schvalovací formuláře přímo v uživatelském rozhraní připravované
webové aplikace a dále potřeba ovládat celý proces zpracování. Pro tvorbu uživatelského rozhraní
jsme zvolili technologii Microsoft s označením Silverlight. “Zasvěcený” již jistě tuší, že právě využitím
této technologie jsme byli schopni uplatnit vlastnosti, které předtím nebyly ve webovém rozhraní zcela obvyklé. Jak se říká, jablko nepadá daleko
od stromu, a Microsoft také v rámci řízení zpracová-
15
ní procesu vyslyšel nářky uživatelů, kde ve své technologii Microsoft .NET 3.5 dodává ucelenou část
pod názvem Microsoft Workflow Foundation. Tato
technologie naše očekávání v řízení procesu toku
dat splňovala. Aby se funkce připravované aplikace
daly využívat pomocí obecného rozhraní, jako třetí do této party byla přibrána technologie Windows
Communication Foundation, která sloužila pro přípravu aplikačního serveru. Vytvořením technologických pilířů a se znalostmi požadavků na aplikaci již nic nebránilo tomu, aby aplikace jako taková
vznikla.
Výsledkem našeho snažení je aplikace, která umožní efektivní a pružnou elektronizaci schvalovacích
procesů ve společnosti. Leckdo si řekne, že aplikace
tohoto typu, které jsou šité na míru, mají omezenou
schopnost přizpůsobit se. Toto tvrzení však neplatí pro naše řešení. Klíčovou vlastností této aplikace
je snadné vytváření nových schvalovacích formulářů, a to od základních, jako je schválení dovolené, až po složitější, jako jsou smlouvy nebo nabídky,
kde do vstupních podmínek schvalovacích procesů vstupují výpočtová pole, různé číselníky, ale také
vzájemné vazby. Možnost vytváření a změny toku
zpracování je další neméně významná vlastnost,
kterou tato aplikace nabízí. Pokud mluvíme o toku
zpracování, musíme si také říci něco o pravidlech.
Pravidla mohou být jednoduchá, kdy si v některých případech vystačíme s odesláním formuláře
ke schválení na svého nadřízeného, až po složitější, do kterých se promítají různé koeficienty ohodnocení rizika, dle kterých se řídí zařazení schvalovatelů do samotného procesu schvalování. Flexibilitu,
s jakou lze v našem případě navrhovat formuláře
pro jednotlivé druhy dokumentů, a také jejich toky
zpracování, lze ocenit v případě, kdy je nutno jednotlivé procesy upravovat až na základě reálné zkušenosti s fungováním procesu jako takového.
V další části tohoto textu se podíváme blíže na jednotlivé části aplikace. Hlavní částí, se kterou se uživatel setká vždy po procesu autentizace/autorizace, je rozcestník. Jak sám název napovídá, pod
tímto pojmem se skrývá přehled, na kterém uživatel nalezne například seznam typů dokumentů,
jejich zařazení do kategorií dle aktuálního kontextu, ale také přehled atributů pro tyto dokumenty.
Ukázkou úvodního prostředí rozcestníku může být
níže uvedený obrázek, na kterém můžete vidět tři
typy dokumentů a dále jejich zařazení do předdefinovaných kategorií.
Jak můžete vidět, dokumenty jsou zařazovány
do jednotlivých kategorií podle pravidel. V kostce
k nim lze položit následující dotazy:
1.Jsem povinným schvalovatelem dokumentu?
Takto definované dokumenty vidím v kategorii
dokumenty k posouzení.
2.Jedná se o dokument, ke kterému se mohu
nepovinně vyjádřit? Takto definované dokumenty vidím v kategorii dokumenty na vědomí.
3.Již jsem se k dokumentu vyjádřil? Takto definované dokumenty vidím v kategorii posouzené
dokumenty.
4.Mám z titulu role právo zobrazit nějaké dokumenty? Takto definované dokumenty vidím v kategorii všechny dokumenty spolu s ostatními.
V rámci popisu pravidel pro jednotlivé kategorie je
patrné, že výše zmíněná pravidla jsou popsána dosti z nadhledu. Do pravidel, ve které kategorii se dokument objeví, vstupuje také aktuální kolo schvalování. Role, do které byl uživatel v systému zařazen,
může podstatným způsobem zasáhnout do zobrazení počtu dokumentů v poslední ze specifikovaných kategorií - všechny dokumenty (viz. ad 4).
Pohled schvalovatele byl již naznačen a jeho úkolem je vyjádřit se, a to buď kladně, nebo záporně.
Aby však mohl schvalovatel dokument schválit, je
potřeba dokument do procesu schvalování vložit.
K tomuto slouží proces založení nového dokumentu, ve kterém dojde nejen k vložení schvalované-
Rozcestník
15
ho dokumentu, ale také je třeba uvést další informace potřebné pro proces schvalování (informace
o ceně, rizicích, dodavateli/odběrateli, pokyny pro
schvalovatele, kalkulace atd.). Proces je ukončen
zvolením schvalovatelů a následným odesláním
dokumentu do daného kola schvalování. Zde je
třeba říci, že pro přehlednost systému vznikla ještě jedna kategorie náhledu, která nebyla zmíněna,
a to spravované dokumenty. Již tušíte, že tuto kategorii vidí vlastníci dokumentu, neboli ti, kteří dokument založili. Co se stane po odeslání dokumentu
do procesu schvalování? Po odeslání dokumentu ke schválení jsou schvalovatelům rozeslány in-
formační e-mailové zprávy obsahující základní atributy schvalovaného dokumentu a dále také odkaz,
pomocí kterého se schvalovatel dostane k informacím ke schvalovanému dokumentu. V procesu
dochází k vyjádření schvalovatelů a k pokračování
toku zpracování dle stanovených pravidel. Na konci procesu, který může být vícekolový, je dokument
schválen, nebo zamítnut.
ale jejich popis by byl mnohem delší, než si tento
článek předsevzal.
Aplikace má také mnoho dalších funkcí (do kterých patří mimo jiné integrace s LDAP nebo Active Directory, správa číselníků, tabulek, rolí, uživatelských nastavení, návrh formulářů a podobně),
Martin Janček
Závěrem lze říci, že i když určitě existuje řada společností, které stále dávají přednost schvalování
pomocí „papírování”, tak nám se v rámci společnosti tento progresivnější přístup osvědčil a můžeme ho jen doporučit.
Systém jednotného přihlášení s pomocí infrastruktury
Java Open Single Sign On (JOSSO)
Podstatou systémů jednotného přihlášení Single Sign On (SSO) je snaha zefektivnit a zjednodušit
práci uživatelům, kteří jsou nuceni si pamatovat velké množství přihlašovacích údajů do různých
systémů a aplikací. V případě použití systému SSO uživatel používá pouze jeden přihlašovací údaj.
Ostatní si za něj pamatuje systém SSO, takže soulad se všemi politikami a požadavky není dotčen.
Systém SSO se tak stává jednotným vstupem do všech aplikací.
JOSSO také přichází s nativní podporou širokého
spektra aplikačních serverů, a to:
JBoss, Tomcat, Weblogic, Websphere, Geronimo,
Jetty, Apache 2.2 (PHP, Perl, Python, ...), Microsoft
IIS (ASP, .NET, ...).
• Modulárnost, umožňující implementaci vlastních
identity komponent;
• Nativní podpora serverů Apache Http 2.x pro
zpřístupnění SSO dalším technologiím jako:
Ruby, PHP, Python, Perl atd.;
• Integrace do aplikací standardu JEE;
• Jednoduchá integrace s Java Spring Security;
• Možnost využití X.509 certifikátů pro autentizaci;
• Podpora LDAP a Windows Authentification
(NTLM);
• Funkce „Zapamatovat přihlášení“;
• Podpora pro resetování hesla;
• Klientské API pro PHP nebo ASP.
Instalace
JOSSO od verze 1.8 obsahuje instalační konzoly
(Deployment Console), která umožňuje snadnou
a velmi rychlou instalaci JOSSO komponent typu
brána (Gateway) a agent (Agent).
Důvod vzniku a masivní nasazování systémů SSO
ve světě je velmi jednoduchý: nároky na bezpečnost přihlašovacích údajů omezují komfort uživatelů. Názorně je to vidět na problematice hesel,
kde jsou kladené různé požadavky na: minimální
délku, složitost, četnost změn, kontrolu již jednou
použitých hesel ve stejném systému apod. Bohužel tato vynucená složitost vede často ke snižování produktivity uživatelů. Opravdu je reálné, aby si
běžný uživatel pamatoval desítky dlouhých a často měněných hesel? Nevede to naopak k obcházení
bezpečnostních politik?
JOSSO Gateway
JOSSO Gateway, též nazývaná Identity Provider
(IdP) je odpovědná za obstarávání uživatelských
identit, jejich ověřování a zpřístupnění. Samotný
proces instalace brány pomocí konzole spouští následující úlohy:
S vyřešením těchto problémů nám pomáhají právě systémy SSO, jež vedou k optimalizaci a zjednodušení bezpečnostních procesů a následné zvýšení
produktivity uživatelů a správců aplikací. Uživateli
je umožněno pracovat s aplikacemi jako by se jednalo o jednu komplexní aplikaci bez nutnosti opětovného přihlašovaní, které už za něj obstarává samotný systém SSO.
Dalšími přínosy jsou menší počet zásahů technické podpory a nemožnost obcházení bezpečnostních politik.
Java Open Single Sign On (JOSSO)
Java Open Single Sign On je open source produkt
firmy Atricore, která ho vyvíjí od roku 2004 a také
stojí za jeho komerční podporou. Mezi klíčové
vlastnosti tohoto řešení patří:
• Cross-domain/cross-organization SSO;
• Podpora SAML;
16
Úvodní stránka testovací aplikace
o Definice unikátního identifikátoru a kontextu
připojované aplikace.
• Konfigurace aplikace
o Konfigurace deskriptoru webové aplikace
(web.xml standardu JEE).
Všechny konfigurační soubory jsou ve formátu
XML.
Atricore Identity Bus
Atricore Identity Bus je dalším rozšířením exitující nebo připravované JOSSO infrastruktury. Identity Bus poskytuje seskupení identit (Identity Federation) pro organizace, které požadují integraci
vlastních nesourodých vnitropodnikových aplikací
nebo aplikací napříč korporacemi. V případě potřeby využívaní a řetězení uživatelských identit od různých poskytovatelů je Identity Bus vhodným doplněním.
Standardní přihlašovací stránka, která je součástí instalace
• Kontrola zvolené cílové platformy;
• Generování a instalace AES klíče potřebného pro
zabezpečení komunikace mezi agentem a bránou;
• Nastavení standardní konfigurace;
• Umístění JOSSO Gateway (josso.war) na server.
Po úspěšné instalaci IdP je možno v instalačním adresáři dohledat log o detailním průběhu instalace.
JOSSO Agent
JOSSO Agent, jinak nazýván také Service Provider
(SP), je odpovědný za zpracování všech požadavků k přihlášení a je jediným oprávněným klientem
IdP. Proces instalace agenta pomocí konzole spouští následující úlohy:
•
•
•
•
•
Kontrola zvolené cílové platformy
Instalace knihoven třetích stran
Instalace agenta
Nastavení konfigurace
Konfigurace zvoleného aplikačního serveru
Test instalace
Pomocí JOSSO konzole je možné také nainstalovat ukázkovou aplikaci pro otestování základních
funkčností systému SSO. Instalační proces v tomto
případě provede pouze umístění testovací aplikace
na zvolený aplikační server. Po zadání URL testovací aplikace do prohlížeče se zobrazí úvodní stránka,
která uživateli sděluje, že je anonymním návštěvníkem a pro přístup k chráněným zdrojům je potřebné přihlášení.
V případě zahájení přihlašování (kliknutím na tlačítko „Login“) je uživatel automaticky přesměrován
na hlavní přihlašovací stránku systému jednotného
přihlášení JOSSO.
17
Pro přihlášení můžeme použít předpřipravenou
uživatelskou identitu a její autentizační údaje (jméno: „user1“, heslo: „user1pwd“). Po úspěšném přihlášení se již zobrazí stránka z chráněné oblasti testovací aplikace.
Začlenění aplikace do systému jednotného přihlášení JOSSO
Způsob začlenění je závislý na typu aplikace. Pro
aplikace standardu JEE je postup následující:
• Konfigurace Gateway
o Způsob ověřování identit:
 konfigurace vlastností připojení k relační databázi,
 konfigurace vlastností připojení k LDAP,
konfigurace identit v případě uložení dat
na souborovém systému.
o Povolení funkce „Zapamatovat přihlášení“.
o Povolení přístupu jednotlivým agentům.
o Možnost úpravy vzhledu přihlašovací
a odhlašovací stránky.
• Konfigurace Agent
Mezi klíčové vlastnosti Atricore Identity Busu patří:
• Podpora SAML;
• Federace SSO může být realizována propojením
různých datových zdrojů, řetězením uživatelských identit od různých poskytovatelů;
• Transparentní SSO – dostupnost SSO Agentů pro
mainstreamové AS jako BEA Web Logic, Websphere, JBoss, Tomcat atd.;
• Procesní orientace – popis toku identity zpráv
pomocí standardních BPM notací;
• Design založený na standardech - SAML, WSTrust, SPML, Java EE, OSGi;
• Plugin architektura.
V tuto chvíli je open source verze Identity Busu dostupná pouze v beta verzi a její nasazení do běžného provozu se nedoporučuje. Je možné zakoupit
komerční verzi (možnost výběru z několika variant),
nebo vyčkat do dokončení první open source verze.
Další úrovně zabezpečení
Jelikož systém SSO poskytuje přístup k mnoha aplikacím a systémům jenom na základě jedné uživatelské autentizace, zvyšuje se tím také riziko zneužití autentizačních údajů v případě, že jsou odcizené
nebo poskytnuté třetím osobám. Proto SSO řešení
vyžaduje zvýšenou pozornost na ochranu identit
a autentizačních údajů. Ochranu je možno navýšit
kombinací s některými dalšími známými metodami, jako jsou klientské certifikáty, čipové karty a tokeny (jednorázové heslo, SMS atd.).
Závěr
V porovnání s ostatními dostupnými open source
řešeními systému SSO (OpenSSO, JA-SIG CAS, Shibboleth) je JOSSO velice efektivní, snadno realizovatelná a výkonná infrastruktura poskytující rozšířené možnosti přizpůsobení požadavkům konkrétní
implementace.
Martin Ptáček
Lukáš Anderko
17
Datové schránky - první krok
k Národnímu digitálnímu archivu
Informační systém datových schránek (ISDS) byl uveden do provozu koncem roku 2009. Slouží především pro obousměrnou komunikaci mezi právnickými osobami (firmami vedenými v obchodním
rejstříku) a orgány veřejné moci. Pro uvedené organizace a úřady je tento způsob komunikace povinný a prioritní ze zákona.
Řešení společnosti KOMIX
Společnost KOMIX podporuje komunikaci s ISDS
rozšířením služeb workflow systému WOIS – pomocí jeho nové komponenty ZPDS. Komponenta ZPDS
je rozhraním WebServices napojena na spisovou
službu zákazníka. Komunikace se spisovou službou
je obousměrná, přičemž sledováno je doručení dokumentu. Dokumenty jsou do spisové služby předávány v perspektivním formátu PDF/A včetně příloh a XML obálky.
Formát PDF/A je vyvinut speciálně pro dlouhodobou archivaci – počítá se změnou IT technologií
v horizontu několika desítek let. Výhodou tohoto
formátu je nezávislost na prostředí operačního systému a dále aplikace pro zpracování. Typickým příkladem jsou v dokumentu použité fonty, které jsou
v případě PDF/A neseny uvnitř dokumentu (v případě PDF jsou používány fonty operačního systému).
Připravte se
Spisové služby, jsou-li vůbec v organizaci zavede-
ny, slouží často pouze k evidenci přijaté pošty na
podatelně a odeslané pošty na výpravně, neobsluhují celé workflow písemnosti v organizaci. ISDS
dává spisové službě podstatně důležitější roli v IS
než doposud a nutí provozovatele spisové služby
k zavedení celého workflow (především z důvodu
podepisování elektronickým podpisem). ISDS si vynucuje také úpravu spisového řádu (vyřizování písemností s pomocí elektronické spisové služby) a
podpisového řádu (použití certifikátů jako elektronických podpisů). Nezbytné je také řešení obousměrné konverze mezi papírovou a elektronickou
podobou dokumentů.
Dodavatelé spisových služeb by měli vyřešit archivaci dokumentů a doručenek z ISDS ve formátu
ISDS včetně elektronických podpisů a značek – tyto
podklady budou nezbytné při účasti v exekučním
a insolvenčním řízení (dříve odeslané dokumenty
a jejich doručenky budou používány jako přílohy).
Hlavní úkoly spisové služby v blízké
budoucnosti
Dodavatelé spisových služeb by měli řešit všeobecnou podporu formátu PDF/A. Tento formát bude
vyžadován při předání dokumentů do Národního
digitálního archivu.
V dohledné době začnou vycházet prováděcí vyhlášky k implementaci rozhraní Národního digitálního archivu, s jehož zavedením se počítá v roce 2012.
Anonymizace provozních dat
Jak nejsnáze umožnit prozrazení citlivých osobních údajů z vaší aplikace? Netrapte se vymýšlením
vymyšleného. V praxi se již vícekrát osvědčilo použít při vývoji, testování či školení živá data. Šikovně tak obejdete provozní bezpečnostní opatření a vymezení okruhu oprávněných uživatelů dat.
A stačilo málo, aby loupežník splakal nad výdělkem
- zamaskovat citlivou část dat nebo alespoň zamaskovat, koho se osobní data týkají. Druhá varianta,
označovaná jako anonymizace či deidentifikace,
se zdá být méně pracná a ohleduplnější k osobám
i k datům - fiktivní a přitom realistická data získáme
vhodným pozměněním hodnot položek, podle kterých by mohly být osoby identifikovány.
letého řidiče nepřidaly k dlužné pokutě za nesprávné parkování další pokutu za řízení vozidla bez řidičského oprávnění.
Avšak ani anonymizace není úplně jednoduchá. Potřebujeme, aby transformace identifikačních položek zachovávaly vzhled a smysluplnost dat, jejich
logiku a vnitřní vazby. Například pro rodné číslo to
znamená zachovat jeho syntaxi, podmíněnou dělitelnost jedenácti a jedinečnost. Znamená to zachovat i vztah rodného čísla k dalším položkám, jako
je pohlaví, datum narození a případné další výskyty rodného čísla jakožto vazební položky. Znamená
to možná i omezit velikost transformace rodného
čísla, aby nám pak třeba aplikační kontroly pro tří-
Kromě rodného čísla maskujeme i další položky. Samozřejmostí je příjmení, s nímž se sveze i jméno a titul. Maskujeme též adresy, telefonní čísla, e-mailové
adresy a další kontaktní údaje, které by bylo možné zneužít k zásahu do soukromí a práv osoby i bez
znalosti její identity. Bývá dobrým zvykem, aby hodnoty adresních položek, jmen a titulů patřily do příslušných číselníků, což by zde nemělo činit problém
- různé varianty náhodného výběru z číselníků jsou
jedním z nejčastějších maskovacích postupů.
Obecně formulováno, měli bychom asi maskovat
18
Pomiňme víceméně právní problém, zda je přípustné, abychom místo původního rodného čísla dlužníka použili (samozřejmě neúmyslně) rodné číslo
našeho souseda.
Milan Číha
všechny položky, které samy o sobě nebo v kombinaci s jinými a/nebo při omezeném okruhu osob
nezřídka nabývají výjimečných a ověřitelných hodnot, jako např. nemovitý majetek nebo zaměstnavatel a pracovní zařazení. Prozíravý anonymizátor
možná nenechá bez povšimnutí ani položky, které
nabývají výjimečných hodnot pouze zřídka, a maskuje alespoň tyto jejich hodnoty. V každém případě nehledí na to, zda podle položky může osobu
identifikovat pouze obzvláště nadaný subjekt, jak
je tomu například u čísel kreditních karet a bankovních účtů.
Samostatnou kapitolou jsou objemné položky
s nestrukturovanými nebo obsahově nesešněrovanými daty, která mohou obsahovat vodítka k identifikaci osob. Nad způsobem maskování životopisů,
žádostí, úředních poznámek a fotografií osob budeme asi muset chvíli rozmýšlet, abychom se vyhnuli jak zbytečné výpočetní náročnosti maskování, tak nerealistické jednotvárnosti výsledných dat,
jíž bychom se snadno domohli pomocí úsporných
maskovacích hodnot „blablabla“ a „do koše“ a po-
takový výřez dán několika výchozími tabulkami,
relacemi referenční integrity, na jejichž základě se
k výchozím záznamům přibalují záznamy související, a specifickými výběrovými podmínkami na záznamy a případně i na sloupce tabulek.
Po návrhu a vývoji datových výřezů a maskování
už zbývá jen anonymizaci spustit. Potřebujeme-li
snadno a opakovaně dosáhnout rychlých výsledků, použijeme pro uvedené činnosti specializovaný produkt, jako je IBM Optim Test Data Management + Data Privacy Option. Daný produkt nabízí
řadu zabudovaných maskovacích funkcí a číselníků
a nabízí i možnost vyvinout vlastní funkce. Umožňuje vytvářet datové výřezy z nejrůznějších databází a platforem, transformovat v nich data a vkládat
je zpět či do jiných databází se zachováním datových vazeb i přes hranice databází. Uživatelské rozhraní produktu a repositář návrhových metadat
usnadňují prvotní návrh anonymizace, jeho modifikace a opakovatelnost použití pro podobné účely.
Produkt ovšem není žádný shareware - díky bohu.
Kdyby jej IBM dávala zadarmo, ještě by nás to mohlo zavléci do Řecka.
mocí náhodného výběru z číselníku komprimovaných fotografií naší oblíbené pornohvězdy.
Při návrhu a provádění anonymizace dat můžeme ušetřit i svůj strojový čas, omezíme-li se jen
na podmnožinu provozních dat nezbytně nutnou
pro dané testování či školení. Jinými slovy, jak při
anonymizaci, tak při dalším používání anonymizo-
vaných dat, bývá výhodné pracovat s konzistentním a uceleným výřezem živých dat, který by byl
dostatečně reprezentativní pro daný účel a zároveň
i méně objemný a náročný na zdroje než živá data.
Máme-li štěstí, lze reprezentativní a přiměřeně velký datový výřez popsat jako výběr podle nějaké dimenze prostupující všemi daty (teritorium, organizační jednotka, období apod.). Nejčastěji je však
Firma IBM nabízí i další produkty pro ochranu důvěrnosti dat. Příbuzný produkt Optim Data Privacy Solution vznikl zřejmě revizí architektury, technologií a uživatelského rozhraní předchozího
produktu poté, co ho IBM získala akvizicí společnosti Princeton Softech. Nový produkt je s předchozím interoperabilní – umožňuje například zadávat do něj úlohy a exportovat i importovat jejich
specifikace. Návrh a vývoj anonymizace je možné
provádět též pomocí univerzálních vývojových nástrojů InfoSphere Data Architect a Optim Development Studio. Další produkt Optim Data Redaction je specializován na odstraňování citlivých údajů
z formulářů a dokumentů v obvyklých kancelářských formátech. Bližší informace o těchto a podobných softwarových nástrojích společnosti IBM
naleznete například na stránkách http://www-01.
ibm.com/software/data/optim/protect-data-privacy/ a http://www.ibm.com/developerworks/data/
library/techarticle/dm-0910optimprivatizeddata/
index.html.
Jan Rada
Technologie – dobrý sluha, špatný pán
RIA
RIA (Rich Internet Application) je stále horké téma,
technologický vývoj v této oblasti je stále bouřlivý. Na počátku byly webové aplikace s velice omezenou ergonomií použitelné spíše na prohlížení
hromadných dat, nikoli na jejich aktualizaci (prostřednictvím protokolu HTTP docházelo k výměně
celých stránek). Postupem času došlo ke zdokona-
19
lení webových aplikací do takové míry, že se jejich
uživatelské rozhraní vzhledem i schopnostmi přiblížilo aplikacím typu „tlustý klient“. Zlepšení ergonomie umožnilo i aktualizaci hromadných dat (asynchronní výměna dat na pozadí a aktualizace části
stránky pomocí techniky AJAX).
RIA aplikace však nejsou výhradně technologie,
které používají v roli klienta webový prohlížeč.
Nové technologie, staré zásady
Technologie JavaScript, DOM (Document Object
Model) a technika Ajax sice poskytují větší možnosti, ovšem za cenu zvýšených nároků na tvorbu
aplikace. Ještě před érou AJAXu se pro tvorbu GUI
používala technologie Java - Swing, která nebyla
úspěšná, kromě jiného také kvůli složitosti tvorby
GUI. Rozdíl ve složitosti tvorby náročnější webové
19
technologie, a postupným vývojem a údržbou rozsáhlých aplikací?
Osvědčené postupy
I v tomto případě platí staré pravidlo: „Musíte vědět, co chcete.“ Tedy konkrétně - vytvořte evidenci
požadavků na GUI. Rozhodněte se, jakou míru podobnosti s MS Windows budete požadovat. Zvažte, jak velké nároky na jednotlivé komponenty GUI
budete mít. Na základě zpracování evidence požadavků se rozhodněte, kterou technologii pro tvorbu GUI využijete.
Poté použijte další osvědčené pravidlo: „Co není
dokumentováno, nebude nikdy dodrženo.“ Uchovejte výsledky své práce v metodice pro tvorbu GUI
- popište pravidla pro vzhled a chování GUI.
Proces volby technologie GUI
aplikace v AJAXu a Swing GUI se postupně zmenšuje (srovnáváme-li GUI s alespoň přibližně stejnými
schopnostmi). V poslední době se totiž snižuje náročnost na tvorbu GUI v technologii Swing díky novým a moderním nadstavbám nad Swingem.
Swing poskytuje opravdu velké možnosti pro tvorbu
GUI. Zároveň podporuje zásady, které jsou obecně
platné už od vzniku OOP (Object Oriented Programming). Jednou z hlavních dobrých zásad je oddělení
komponent uživatelského rozhraní od komponent
aplikační logiky. Zachování této podmínky umožňuje rozdělení aplikace do vrstev a při pečlivém návrhu
usnadňuje přechod na novou technologii GUI s minimálním dopadem na aplikační logiku. Tento způsob tvorby aplikací je označován jako MVC (Model –
View – Controller). Swing komponenty architekturu
MVC důsledně podporují.
Moderní technologie RIA aplikací také podporují
oddělení uživatelského rozhraní od aplikační logiky, zprvu však šlo spíše o oddělení technologické
– oddělení stylu HTML stránek od generace jejich
datového obsahu. O zavedení MVC do RIA aplikací
se snaží například frameworky JSF (Java Server Faces) a Spring.
Z pohledu začátečníka a programátora jednoduchých aplikací je přístup MVC zbytečná složitost.
Pokročilý programátor rozsáhlých aplikací jej považuje za nezbytný nástroj.
Má to svá „ale“
I ta nejmodernější AJAX aplikace však nakonec vygeneruje HTML, které je zobrazováno v prohlížeči.
To je sice velká výhoda, ale zároveň i velká nevýhoda celé této skupiny řešení – zobrazené HTML (případně interpretace JavaScriptu) totiž závisí na typu
prohlížeče, jeho verzi a nastavení. Zajistit neome-
20
zenou přenositelnost nezávisle na uvedených parametrech prohlížeče je prakticky nemožné. Aplikace
závislé na prohlížečích mají tedy trvale problémy s
přenositelností.
Připomínám, že Swing pracuje nezávisle na prohlížeči - má vlastní běhové prostředí JRE.
Závěr
Všimněte si, že celý postup vychází z požadovaných
vlastností GUI (bere v úvahu zkušenosti uživatele s
GUI MS Windows) a od nich odvozuje používanou
technologii. Východiskem tedy rozhodně nemusí být právě módní technologie (Flash, Java FX) v takovém případě bychom mohli mít po několika
týdnech nebo dokonce měsících snažení aplikaci
s nevyhovující ergonomií – prostě proto, že módní technologie nemusí vyhovovat našim potřebám.
Revoluce nebo evoluce?
AJAX aplikace dávají programátorovi při tvorbě GUI
velkou svobodu. Je to však vždy výhoda? Jistě nikoli
– uživatel, který je zvyklý na GUI MS Windows, bude
mít s revolučním přístupem ke vzhledu a chování
GUI jistě problémy.
Při pokusu o napodobení vzhledu a chování GUI MS
Windows (integrální vlastnost komponent Swingu) však opět narazíme na schopnosti technologií
AJAX. Schopnosti Swingu jsou v této oblasti omezené, schopnosti AJAX aplikací jsou ještě omezenější – mezi MS Windows GUI a GUI AJAX aplikace
je tedy již citelný rozdíl.
Efektivita při tvorbě aplikací
Jedním z rozhodujících kritérií při tvorbě rozsáhlých aplikací s delší dobou života je efektivita vývoje. Vysoké požadavky jsou kladeny nejen na rychlost vzniku aplikace, ale především na snadnou
údržbu a rozvoj.
V takovém případě se ocitnou v popředí zájmu klasické OO (Object Oriented) vlastnosti – dobře zapouzdřené komponenty s možností opakovaného
použití. Takové komponenty musí být obecné, jejich vlastnosti musí být dobře řiditelné parametry.
Tyto vlastnosti však něco stojí – jejich dosažení u
každé nové technologie chvíli trvá. Jak tedy zmenšit rozpor mezi rychlostí, jakou vznikají nové RIA
Na počátku snahy RIA byla snaha o jednoduchost
tvorby aplikací. Tato snaha trvá dodnes, ale již nyní
je zřejmé, že složité GUI nelze vytvořit jednoduše.
Jsou-li tedy důležité zkušenosti návrháře a programátora, je důležité omezit fluktuaci těchto pracovníků a hlavně – dobře dokumentovat úroveň dosaženého poznání. Nenechte se pasivně unášet
překotným vývojem RIA technologií!
Milan Číha
Vybudování democentra SAP v Komixu
KOMIX má dlouholeté zkušenosti s testováním softwarových aplikací a tvorbou metodik testování pro různé zákazníky. Občas jsme se setkávali s povzdechem: „Kdybyste tak uměli testovat SAP...“
Před 2 lety přišla první konkrétní nabídka na spolupráci se zákazníkem v této oblasti. Od té doby
komunikujeme se zákazníky, kteří mají SAP implementován, abychom pronikli do této samostatné
a specifické kapitoly v oblasti testování a přemýšlíme, jak to zařídit, abychom byli schopni poradit, jak
testování SAPu zefektivnit a optimalizovat. Když se
k tomu asi před rokem přidala další konkrétní nabídka na spolupráci, tentokrát od samotného SAPu,
neváhali jsme a nabídku přijali. A tak začala práce
na vybudování democentra pro optimalizaci testování SAP aplikací.
Na vytvoření a údržbě democentra se současně podílejí 3 společnosti: SAP, HP a KOMIX. SAP dodal licence a know-how pro SAP Backend systémy a SAP
nástroje na podporu testování, HP poskytlo licence
a know-how pro HP nástroje na podporu testování
a KOMIX prostředí a know-how z oblasti testování
a znalosti HP nástrojů, protože je již dlouhá léta autorizovaný HP Software Business Partner, a to nejen
pro oblast testování.
Co je cílem democentra
Pro efektivní testování je potřeba skloubit 3 základní faktory:
• mít lidi zaškolené v dané problematice – v tomto
případě znalé SAPu,
• mít definované metodiky a postupy testování,
• mít vhodné nástroje, které celý proces podpoří
a zefektivní.
Cílem democentra je postupně ukázat, jakým způsobem je možno dosáhnout optimalizace testování v dané oblasti.
• Lidé – předpokládáme, že hlavními zodpovědnými osobami za testování SAP jsou a zůstanou klíčoví uživatelé. Jde hlavně o to jak jim testování co
nejvíce usnadnit a zpřehlednit.
• Metodika - vycházíme z toho, co je již k dispozici:
• standardy pro testování definované SAP,
• metodiky, které jsou obsaženy v nástrojích.
• Nástroje - pro podporu procesu testování jsou
na trhu k dispozici nástroje firmy HP, které využívá pro testování nových verzí i sám SAP, a pro další zvýšení efektivity vyvinul k nástrojům řadu akcelerátorů.
Praktické a dlouholeté zkušenosti z oblasti testování s danými nástroji nám umožňují nastavit proces
a metodiku testování přímo na míru dané organizaci.
21
Jaký přínos má democentrum pro zákazníky
Služby democentra probíhají na dvou úrovních. Na
jedné straně pořádá zapojená trojice společností
pravidelné půldenní semináře, které jsou pro registrované účastníky zcela zdarma.
Program zahrnující jednotlivé oblasti testování
je v tuto chvíli naplánován do jara příštího roku,
bude ale samozřejmě upravován a doplňován tak,
aby odpovídal preferencím a potřebám zákazníků.
Aktuální témata jednotlivých seminářů jsou následující:
• Základy funkčního testování s využitím SAP QC
by HP;
• Automatizace testování SAPu metodou BPT s využitím SAP QC by HP a SAP TAO;
• Příprava dat pomocí SAP TDMS;
• Organizace a řízení testů s využitím SAP SM – napojení na SAP QC by HP;
• Funkční testování s využitím SAP SM;
• Zátěžové testování SAPu s využitím SAP LR by HP.
Druhou hlavní náplní nového democentra bude organizace akcí dle konkrétních požadavků zákazníka. Na konkrétních datech bude možno předvést
řešení pro danou firmu, případně realizovat formou
Proof of Concept pilotní projekt ve spolupráci se zákazníkem pro ověření vhodnosti vybrané technologie testování.
vhodné pro prezentace testování na základě zájmu
zákazníků. Procesy jsou dále doplňovány s růstem
zájmu zákazníků o testování SAP aplikací.
Solution Manager (SAP SM)
Integrovaný SAP SM obsahuje adaptér pro HP testovací nástroje. Propojení obou nástrojů umožňuje využití Blueprintů implementovaných SAP systémů v SAP SM projektech jako zdroj dat pro testovací
požadavky v projektech testování HP Quality Center. Na tyto požadavky se v systému HP QC vytvoří
testy, které se z prostředí HP QC rovněž provedou,
a výsledky testů se předají zpět do projektu SAP
SM. Při dalších kolech testování se přidávají do projektů SAP SM další výsledky z běhů testů a aktuálně
vytvářená výstupní zpráva o testování z projektu
SAP SM obsahuje komplexní informace o tom, v jakém stavu se aktuálně nacházejí testy implementovaných SAP procesů.
TDMS
SAP TDMS je softwarová aplikace, která umožňuje
jednoduše vytvářet neproduktivní testovací prostředí s relevantním extraktem podnikových dat
pro testování. Tím TDMS obecně pomáhá minimalizovat požadavky a náklady na infrastrukturu snížením objemu dat ve vývojových, testovacích a školících systémech. Dokáže provádět automatické
replikace používaných dat včetně znepřístupnění
citlivých dat.
Pracovní stanice a SAP Frontend
Co democentrum obsahuje
Democentrum je vybaveno dvěma virtualizačními servery. První server obsahuje virtuální stroje
se SAP Backend systémy Enterprise Resource Planning (ERP), Solution Manager (SAP SM) a aplikaci
Test Data Migration Server (TDMS). Vše je instalováno v prostředí Linux s připojením na SAP On-line Service System (OSS). Druhý server má instalovány virtuální stroje s operačními systémy Windows,
obsahující HP Quality Center server (QC) a virtualizované pracovní stanice. Na pracovních stanicích je
instalován SAP Frontend a testovací nástroje HP –
Quality Center a QuickTest Professional a jsou přístupné vzdáleně z Internetu.
SAP Backend systémy
ERP
SAP ERP je systém určený pro plánování podnikových zdrojů. Jedná se o softwarový systém společnosti SAP, který je používán jako informační páteř
pro vedení celého podniku. V democentru KOMIX
obsahuje pouze některé speciálně vybrané procesy
Pracovní stanice obsahují následující software: SAP
GUI pro Windows, SAP Tools, HP QC klient, HP QTP
a SAP TAO.
SAP GUI pro Windows
Tvoří prostředí SAP Frontend pro přístup k uživatelským aplikacím na SAP ERP systémech. Aplikace jsou spouštěné jako jednotlivé SAP transakce
podnikových procesů. Prostředí je určeno pro práci
koncových uživatelů SAP aplikací i pro práci testerů
on-line s on-line transakcemi.
Vybavení Democentra SAP
Virtualizační server pro
SAP Backend systémy
Virtualizační server pro
SAP Frontend a HP SW
HP QC
server
SolMan
TDMS
Pracovní
stanice 1*
ERP 1
Pracovní
stanice 2*
ERP 2
Vzdálený
přístup
*SW pracovních
stanic:
–  SAP GUI
–  SAP Tools
–  SAP TAO
–  HP QC s BPT
–  HP QTP pro SAP
parametrizovaných testovacími daty. Skripty lze
snadno vytvářet nahráváním uživatelské činnosti v SAP aplikacích a upravit je dalším programováním. Skriptovacím jazykem je VBScript. Pro optimalizaci přípravy a údržby automatizovaných
testů slouží HP technologie Business Process Testing (BPT). Technologie SAP TAO, která dokáže využívat integraci se SAP systémy, vede k dalšímu zvýšení efektivity tvorby funkčních automatizovaných
testů a k urychlení procesu testování.
Kompletní možnosti integrace
Schéma integrace SAP SM a HP QC
SAP TAO
HP Quality Center (HP QC) - SAP QC by HP
Jedná se o softwarový produkt společnosti HP pro
efektivní řízení procesu testování. Řešení v democentru SAP v KOMIXu integruje nástroje HP pro manuální a automatizované funkční testování se SAP
nástroji SM a TAO tak, aby bylo možné seznamovat
zákazníky s procesem testování SAP aplikací a poukázat na výhody daného řešení. Úroveň integrace
může být různá a přizpůsobena konkrétním požadavkům zákazníka.
HP QuickTest Professional (HP QTP)
- součást SAP QC by HP
Jedná se o softwarový produkt HP pro automatizaci funkčního testování v prostředích MS Windows.
V rámci produktů SAP je označen názvem SAP QC
by HP. Tento softwarový nástroj dokáže automatizovat testování použitím spustitelných skriptů
TAO představuje softwarovou technologii společnosti SAP pro urychlení procesu automatizovaného testování ve vazbě na HP testovací nástroje HP
Quality Center a HP QuickTest Professional. TAO integruje ERP systém s HP Quality Center a jeho síla
spočívá v tom, že dokáže pro jednotlivá okna implementovaných SAP aplikací v prostředí SAP GUI
automaticky vygenerovat tzv. Business Process
komponenty včetně vstupních parametrů. Tyto
komponenty se použijí v HP nástrojích jako elementární stavební prvky automatizovaných funkčních testů. Do TAO technologie lze integrovat i SAP
SM a využívat v něm obsaženou Business Process
analýzu ke zjištění dopadu změn v SAP systémech
na komponenty pro testování.
HP LoadRunner (HP LR) - SAP LR by HP
ván i HP LoadRunner (v terminologii SAPu jde o produkt SAP LR by HP). Jde o softwarový nástroj určený pro provádění zátěžových a výkonnostních testů
nejen SAP aplikací. Umožňuje z jednoho místa řídit
zátěž stovek nebo tisíců současně pracujících virtuálních uživatelů, kteří realizují síťovou komunikaci stejně jako reálně pracující uživatelé SAP aplikací.
Vhodně zvolený typ zátěžového testu a jeho správné
načasování umožní včas eliminovat slabá místa systému a případné kolize výkonu systému v provozu.
Závěr
Pokud vás technologie i program democentra zaujaly, neváhejte nás kontaktovat na e-mailové adrese:
[email protected]. Jsme připraveni odpovědět na vaše
dotazy, případně vám tuto problematiku předvést
„naživo“.
V další etapě bude do prostředí democentra instaloMiloslav Richter, Alena Řezníková
KOMIX FTS
KOMIX FTS (Functional Testing Suite), nástroj pro podporu a řízení manuálního funkčního testování, vznikl jako alternativa k licencovaným nástrojům, které sice poskytují bohatou funkcionalitu a vysoký uživatelský komfort, ale také s sebou přinášejí značná omezení ve formě licencování.
KOMIX FTS (dále jen FTS) nepřináší tak bohaté možnosti a tak vysoký uživatelský komfort jako licencované nástroje, ale přesto svojí funkcionalitou postačuje pro evidenci a řízení procesu manuálního funkčního testování. Hlavními přednostmi KOMIX FTS je zejména jeho jednoduchost, snadná a rychlá instalace a konfigurace, výrazně nižší pořizovací cena a v neposlední řadě také licenčně
neomezený počet uživatelů.
FTS je webová aplikace psaná v PHP a vychází
z open-source nástroje pro řízení testování distribuovaného pod licencí GPL. Tento open-source nástroj byl týmem pracovníků KOMIXu odladěn a upraven tak, aby co nejlépe podporoval proces testování
od definice požadavků přes návrh a provádění testů až po bugtracking. Od původního systému se FTS
značně liší, a to zejména svojí vnitřní logikou.
FTS je rozčleněn do několika částí (modulů), které
jsou mezi sebou vzájemně provázány. Pro samotné
řízení procesu testování jsou určeny moduly Aplikace, Požadavky, Testy, Běhy testů, Hlášení a Reporty.
K administraci nástroje a jednotlivých projektů potom slouží moduly Administrace a Správa uživatelů.
Práce na projektu (hned po zavedení projektu
do systému a po jeho jednoduché konfiguraci) začíná v modulu Aplikace, kde zavedeme aplikace, kte-
22
rých se bude testování týkat a u každé aplikace zavedeme také libovolný počet plánovaných releasů,
v rámci kterých následně evidujeme testovací scénáře.
V modulu Požadavky evidujeme libovolnou strukturu požadavků, které lze členit ve stromové struktuře a mohou být různého typu (funkční, technické,
požadavky na testování apod.). K požadavkům jdou
přikládat přílohy libovolného formátu. U požadavků lze snadným způsobem udržovat vazby na releasy a také na testy, které tyto požadavky pokrývají.
Modul Testy slouží pro návrh a evidenci testovacích
případů. Každý test se skládá z hlavičky, popisu testu a libovolného počtu kroků. U každého kroku testu lze evidovat akci uživatele (testera), vstupní data
a očekávaný výsledek. Samozřejmostí je také možnost nahrání přílohy.
Po návrhu testovacích případů (Test cases) v modulu Testy mohou být tyto testy přiřazovány do testovacích scénářů, které jsou evidovány v modulu
Aplikace a které jsou přímo navázány na release.
U každého testu zařazeného do scénáře lze určit
jeho pořadí v rámci tohoto scénáře.
Modul Běhy testů slouží jednak ke spouštění testů zařazených do scénářů a jednak k evidenci běhů
testů. U každého ze spuštěných testů je uchovávána historie jeho běhů, pochopitelně s výsledky jednotlivých běhů. Při spuštění testu je testerovi zobrazena obrazovka se seznamem kroků testu
(včetně vstupních dat a očekávaných výsledků).
Tester má možnost zaznamenat skutečné chování systému buď na úrovni jednotlivých kroků testu,
nebo na úrovni celého testu. V případě zjištění neshody lze přímo z běhu testu vyvolat formulář pro
evidenci chyby (hlášení).
Pro bugtracking slouží modul Hlášení. U chyb lze
kromě popisu a různých strukturovaných informací
uchovávat také přílohy a vazby na test a běh testu,
který vedl k odhalení chyby. Pokud je chyba zadána
přímo z běhu testu, jsou tyto vazby evidovány zcela
automaticky, pokud není zadána přímo z testu, lze
vazbu přidat ručně, nebo ponechat chybu bez návaznosti na konkrétní test.
FTS má minimální požadavky na software a hardware. Pro provoz postačuje operační systém Windows nebo Linux, aplikační server s podporou PHP
a databáze MySQL, pro podporu e-mailových funkcí FTS je potřeba také server SMTP.
KOMIX je schopen poskytnout FTS jako samostatný software, nebo spolu s dalšími službami, které
souvisejí se zavedením a následným provozem nástroje, jako například instalace, konfigurace a pro-
gramové úpravy, školení uživatelů, návrh metodiky,
uživatelská podpora nebo outsourcing testování.
Zájemcům, kteří by se rádi seznámili s nástrojem
KOMIX FTS detailněji, je možné po dohodě poskytnout přístup na předváděcí prostředí FTS po dobu
jednoho týdne.
Lukáš Michálek
DALŠÍ ZLEPŠOVÁNÍ integrovaného managementu KOMIXu
Rok 2009 byl pro společnost KOMIX s.r.o. z hlediska získání dalších certifikací a rozšíření integrovaného managementu systému (IMS) společnosti velice
úspěšný. V únoru proběhla úspěšně závěrečná certifikace managementu IT služeb a získali jsme certifikát managementu IT služeb dle normy ČSN IEC
ISO 20000-1. V červenci naše společnost získala certifikát managementu bezpečnosti a ochrany zdraví
při práci (BOZP) dle normy ČSN OHSAS 18001. V listopadu, v rámci Evropského týdne kvality a mezinárodní konference v Národním domě na Vinohradech v Praze, na akci „Večer s Českou kvalitou“,
jsme získali ocenění v rámci Programu Česká kvalita a právo užívat značku „Certifikované služby IT“.
Nakonec v prosinci 2009 společnost KOMIX s.r.o.
získala také nejnovější certifikát dle normy ČSN ISO
10006 pro oblast řízení jakosti projektů a zároveň
úspěšně obhájila při dozorovém auditu certifikát
systému řízení jakosti podle ČSN EN ISO 9001:2009
a certifikát pro poskytování IT služeb ČSN ISO/IEC
20000-1, včetně recertifikace managementu pro
oblast životního prostředí, podle normy ČSN EN
ISO 14001. Pro naše zákazníky je možná nejzajímavější certifikát managementu jakosti projektu, který se přímo týká dodávek produktů a služeb, které
jim naše společnost poskytuje.
23
Řízení projektů
V průběhu roku 2009 tým našich pracovníků vytvořil novou metodiku pro řízení projektů, která byla
postupně ověřena také na pilotních projektech.
Tato metodika je výrazně podporována IS CLARITY a je navržena v souladu se standardy ČSN EN ISO
9001 a ČSN ISO 10006. Tato skutečnost umožnila získat certifikát dle normy ČSN ISO 10006, který potvrzuje, že vytvořená metodika řízení projektů a aplikace všech procesů managementu jakosti při řízení
realizovaných projektů splňuje kritéria kvality mezinárodně uznávaného standardu ČSN ISO 10006,
který je určen pro management jakosti projektů.
Při řešení projektu je vždy veškeré úsilí zaměřeno
ke splnění cíle projektu. Výstup z projektu ale musí
být také konkurenceschopný a je potřebné, aby
také splňoval požadavky zákazníka jak po stránce
technické, provozní, estetické, bezpečnostní, ekologické nebo spolehlivosti, tak i ekonomické. Projekt musí být také dobře a efektivně řízen.
Každý projekt je v naší společnosti evidován, plánován, monitorován a také řízen v IS CLARITY. To
se týká nejen všech projektů určených pro naše zákazníky, ale také ostatních interních projektů režijních nebo rozvojových, pro které je zákazníkem
naše společnost. Kontrola kvality na úrovni projek-
tového manažera zahrnuje sledování plnění plánu
projektu, čerpání zdrojů, vykazování času stráveného na projektu a také zabezpečení jakosti produktu. Jedná se například o monitorování plnění
stanovených milníků projektu, akceptačních výstupů jednotlivých etap projektu a stanovených akceptačních kritérií těchto výstupů s cílem určit, zda
skutečnost odpovídá specifikaci a požadavkům zákazníka. Kontrola kvality na úrovni vedení společnosti KOMIX s.r.o. zahrnuje monitorování průběhu všech projektů nebo vybrané množiny projektů
pomocí Status reportu, který obsahuje informace o stavu a průběhu projektu. Reporty určené
pro jednotlivé projektové manažery nebo vedení
společnosti obsahují informace o stavu a průběhu projektu a umožňují tak přijímat včasná nápravná nebo preventivní opatření v případě odchylek
od stanoveného plánu projektu nebo stanovených
parametrů kvality.
Nedílnou součástí řízení projektu je také identifikace a řízení rizik. Vedoucí projektu v pravidelných intervalech hodnotí postup projektu a vyhodnocuje
také rizika projektu, tj. kvantifikuje pravděpodobnost aktivace rizika, velikost jeho dopadu na projekt, navrhuje preventivní opatření a krizové scénáře. Zároveň má možnost eskalovat případný
Ukázka portletu monitorujícího stav projektů podle pracnosti
problém na úroveň vedení společnosti. Je to způsob vyvolání zásahu z vyšší úrovně řízení, pokud
vedoucí projektu vyhodnotí problém jako urgentní, nebo se daný problém již snažil řešit, ale řešení je nad jeho síly, nebo nemá dostatečnou pravomoc rozhodnout.
Další součástí řízení projektu je identifikace a řízení požadavků na změny. Změnou u projektu je
odchylka od projektového plánu, která má dopad
na rozsah, cenu, jakost nebo harmonogram projektu. Zdrojem těchto odchylek může být okolí projektu (zejména zákazník) a také jednotlivé procesy
projektu. Požadavek na změnu se může týkat zadání projektu, plánu projektu, návrhu řešení, požadavků zákazníka na produkt, nebo i jednotlivých dokumentů projektové dokumentace. Změny
je možné realizovat naplánováním, např. nového
úkolu nebo celé etapy (při rozsáhlejších změnách,
kdy je nutné koordinovat zdroje a výstupy). Změny menšího rozsahu jsou řešeny operativním postupem, tj. zadáním konkrétních úkolů v rámci projektového týmu. Vlastní realizace změny probíhá až
na základě schváleného návrhu řešení a upraveného projektového plánu nadřízeným zaměstnancem
vedoucího projektu.
Součástí řízení projektu v IS CLARITY je také plánování zdrojů projektu a průběžné sledování vykazování času stráveného na projektu. To umožňuje
managementu provádět efektivnější rozhodování,
které je vždy založené na aktuálních podkladech,
které slouží k provádění a schvalování změn, včetně
úprav směrného plánu a interní kalkulace projektu.
Další zlepšování integrovaného managementu
V integrovaném managementu je kladen důraz
na zkvalitňování a zlepšování nejen jednotlivých
procesů a certifikovaných částí managementu, ale
také na celý integrovaný management. Je potřebné, aby i celý integrovaný management byl funkční
a efektivní. Zlepšování musí být zaměřeno především na hlavní procesy podílející se přímo na tvorbě produktu (týká se to zejména procesů v oblasti
obchodu, řízení projektů a tvorby jednotlivých produktů a poskytování služeb), ale i na celek. Cílem je
zavést nejen reporting jednotlivých procesů, ale integrovaný reporting, který umožňuje monitorovat
a přejímat informace z různých zdrojů a procesů.
24
Budování integrovaného managementu ve společnosti KOMIX s.r.o.
K tomuto účelu se v naší společnosti začala využívat
technologie nástroje QlikView, který umožňuje načítat podniková data z různých zdrojů, která následně uloží v komprimované formě do operační paměti. Pomocí tohoto nástroje je velmi jednoduché
dívat se na data z různých pohledů a analyzovat tak
více různých hypotéz. Díky technologii komprese
dat v paměti počítače postačí pro použití aplikace
i běžný notebook. Všechny objekty jsou propojeny,
výběr dat se provádí snadno a interaktivně výběrem jednotlivých položek. Prezentované výsledky
umožňují lepší rozhodování.
Nyní se integrovaný management systém společnosti KOMIX s.r.o. skládá z:
• managementu kvality (QMS) - ČSN EN ISO
9001:2009,
• managementu jakosti projektů (QMP) - ČSN ISO
10006:2006,
• environmentálního managementu (EMS) - ČSN
EN ISO 14001:2005,
• managementu bezpečnosti a ochrany zdraví při
práci (BOZP) - ČSN OHSAS 18001:2006,
• managementu IT služeb (ITSM) - ČSN ISO/IEC ISO
20000-1:2006.
V současné době je také stále větší důraz kladen na
bezpečnost informací. Na základě požadavků zákazníků, výsledků analýzy stávajícího stavu a provedeného auditu bezpečnosti informací rozhodlo vedení společnosti KOMIX s.r.o. o implementaci
managementu bezpečnosti informací (ISMS) podle normy ČSN ISO/IEC 27001. Podle plánu implementace je nyní dokončena implementace tohoto nového managementu a do konce roku 2010 je
naplánován vlastní certifikační audit 1. a 2. stupně,
který provede společnost CQS (Sdružení pro certifikaci systémů jakosti).
Jiří Feřtek
Jste závislí na internetu?
Závislí na internetu jste, když:
 Přijdete domů a políbíte domovskou stránku své
partnerky.
 Odmítáte odjet na dovolenou tam, kde není přístup k internetu a zásuvky pro nabíjení notebooku a telefonu.
 V noci se vám zdají sny v HTML.
 Při psaní poznámek si píšete za každou větou .cz.
 Při vypínání počítače máte podobný pocit, jako
byste dostávali kopačky.
 Všichni vaši přátele mají ve jménu @.
 V noci se každé dvě hodiny budíte a kontrolujete
došlou poštu.
Taxikáři řeknete, aby jel do http://radlicka.751/113e/novy.dum/prosklene.dvere.cz.
 Dívka, kterou jste naposledy sbalil, byla jenom
jpeg v nízkém rozlišení.
 Namísto adresy bydliště zadáváte svůj e-mail.
 V lahůdkách při objednání šunky sdělíte, že nechcete, aby byla #008000.
Chytré výzkumy
Pusťte děti k internetu, budou více číst
Nechte děti surfovat na internetu. Podle průzkumu
totiž děti, které často brouzdají na internetu, také
více čtou, a to nejen články na síti, ale i v tištěných
mediích. Toto zjištění vyplývá z výzkumu KidsVerbrauch Analyse 2009. Průzkum také potvrzuje, že si
tištěná média a internet vzájemně nekonkurují, ale
spíše se podporují.
Firmy neumějí komunikovat se
zákazníky
Dle celosvětového průzkumu společnosti Genesys Telecommunications Laboratories se firmám nedaří efektivně komunikovat se
zákazníky. Přestože se téměř tři
čtvrtiny firem poskytujících služby
zákazníkům snaží se svými klienty optimálně komunikovat, úspěšných je jen zlomek. Slabinou je zejména neosobní komunikace, která
nezohledňuje individuální požadavky či zájmy zákazníka a jeho důležitost pro firmu. Jen 35 procent
call center spojuje VIP zákazníky s
nejlépe vyškolenými operátory.
CRM systémy používá 56 % velkých společností
CRM využívá 56 % velkých společností v Evropě a Severní Americe,
17 % firem plánuje jeho pořízení do
dvou let. Vyplývá to z nedávné studie společnosti Forrester Research.
Analýza zároveň zjišťovala priority
velkých společností v oblasti říze-
25
ní vztahů se zákazníky. Firmy působící na B2B trhu
nejčastěji uváděly získání nových zákazníků, udržení stávajících zákazníků, zvýšení jejich loajality
a prodej více produktů či služeb stávajícím zákazníkům. V případě společností, které se orientují na
koncové spotřebitele (B2C), je hlavním cílem udržení stávajících zákazníků a zvýšení jejich loajality,
následuje zlepšování zkušeností zákazníků s výrobkem či službou a získání nových zákazníků.
Ve třetině firem s méně než 100 počítači nezodpovídají za bezpečnost dat odborníci
Ve třetině menších a středních firem nezabezpečují data IT odborníci. Odborníky v oblasti IT často
nahrazuje vedení společnosti, výjimkou nejsou ani
pracovníci odlišných úseků či dokonce asistentky.
Toto zjištění vychází od společnosti SODATSW, která provedla průzkum mezi bezmála dvěma tisíci firmami s počtem zaměstnanců v rozmezí 100 až 500.
Pijte alkohol, budete žít déle
Abstinenti mají menší důvod k radosti a opilcům
přibyl argument k obhajobě alkoholu. Poslední studie ukázaly, že lidé, kteří se alkoholu vyhýbají, umírají dříve než opilci. Texaský tým sledoval po dobu
dvaceti let 1824 osob ve věku 55 až 65 let. Mírná
konzumace alkoholu, což znamená jedna až tři jednotky alkoholu denně, zdraví prospívá nejvíce. Různé studie podle časopisu Time ukazují, že alkohol
v přiměřeném množství prospívá srdci, krevnímu
oběhu i společenskému životu.
chvilka poezie
Jedou takhle manažer, automechanik a programátor autem. Auto se náhle porouchá a zastaví.
Manažer povídá: „Jen klid, vše je OK, mám tu mobilní telefon, zavoláme si taxíka a pojedeme dál.“
Mechanik povídá: „Není třeba, já jsem mechanik
a mám tu nářadí. Za dvě hodinky to opravím a bude
to v pořádku.“
Programátor povídá: „A nestačilo by třeba jen vystoupit a nastoupit?“
Potkali se dva čerti, smutný a veselý. Ten veselý se ptá:
„Co ti je, že si takový smutný?“
„Ale, pracovní problémy. Dělám na příjmu a v posledním čase nám dělají starosti programátoři.“
„Jaké starosti?“
„Například včera: Jeden nám tam zlikvidoval polovičku oddělení motorovou pilou, než se nám podařilo vysvětlit mu, že to není další level DOOMu.“
.........................................................................................................................
Proč má programátor vedle manželky ještě milenku?
Manželka si myslí, že je u milenky a milenka si myslí, že je u manželky... a on si zatím může v klidu programovat.
.........................................................................................................................
Padá server, přej si něco!
TEST - Poznáte svou osobnost?
Zodpovězte poctivě následující otázky a poznamenejte si počty jednotlivých odpovědí a, b,
nebo c, které jsou Vám nejblíže.
b) každý den
c) nikdy, jednou měsíčně ji celou vyměním
Počítač ráno zapínáte:
a) při příchodu do práce
b) ihned po probuzení, ještě dřív, než si dojdu na wc
c) počítač je stále zapnutý, takže ho jen probudím
Svou partnerku/svého partnera si vybíráte:
a) podle hardwaru
b) podle softwaru
c) podle toho, kolik zná klávesových zkratek
Za kolegy máte:
a) samé nuly
b) samé jedničky
c) kombinaci nul a jedniček
Počítač vypínáte:
a) při odchodu z práce
b) těsně před usnutím
c) proč by se měl počítač vypínat?
Dovolenou vybíráte podle:
a) rychlosti a kvality internetového připojení
v hotelu
b) klimatu nejpříznivějšímu pro můj notebook
c) když mě nějaká destinace zajímá, najdu si o ni
reportáž na YouTube a nemusím nikam jezdit
Používáte papírový diář?
a) Ano, respektuji tradice
b) Už jsem o tom slyšel, ale přesnému využití
nerozumím
c) Pa… co?
Pracovní e-maily čtete:
a) v pracovní době
b)nečtu
c)neustále
Jak často si čistíte klávesnici od zbytků jídla?
a) nečistím, u počítače se zásadně nestravuji
Vyhodnocení testu:
Převažuje odpověď A
Počítač používáte, ale nevyužíváte všech
možností, které Vám tato moderní technologie
nabízí. Což je důkazem Vašeho velkého potenciálu
v tomto oboru. Musíte jen změnit názor na počet
nul ve Vašem okolí.
26
Převažuje odpověď B
S počítačem jste dobří kamarádi a v oboru
IT Vás hned tak něco nepřekvapí.
Umíte šetřit přírodu, protože Váš počítač není
v provozu nonstop a nekupujete si papírový diář,
čímž jste ušetřili minimálně polovinu menšího
stromu.
Převažuje odpověď C
IT technologie jsou ve Vašem srdci pevně zakódovány a tento kód nelze na rozdíl od systému
Windows nabourat. Vaši kolegové se mohou spolehnout, že pokud Vám pošlou e-mail, dostanou
na ni odpověď 24 hodin denně, 7 dní v týdnu, což
ale v některých situacích může být i na škodu.
Výsledek tajenky: Zkuste to vypnout a zapnout.
křížovka
sudoku
27
Děkujeme všem našim
klientům za přízeň
a důvěru
KOMIX s.r.o.
Avenir Business Park, Radlická 751/113e, 158 00 Praha 5, Tel.: +420 257 288 211, [email protected], www.komix.cz, Redakční zpracování: kolektiv pracovníků KOMIX s.r.o.
DTP a produkce: SDP V.I.P. Servis, s.r.o.
© Komix s.r.o. 2010