komix noviny 2010/2011

Transkript

1 Nepřehlédněte: komix noviny 2010/2011 Vážení čtenáři, 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. 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č? 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 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 osvědčilo ve více než 1000 marketingových odděleních a agenturách. Str. 8. QlikView na všechno a pro každého Produkt QlikView je nástroj Business Intelligence, 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živatelům zkoumat velký objem dat zcela libovolným způ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 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

2 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 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ů. 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ě znamená, ž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 Schéma řízení dynamického systému Základní požadavky na moderní MIS 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. 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. 2

3 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. 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, 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í. 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 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. 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 3 3

4 Ú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. 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 ( ale i instituce, například ČVUT, Masarykova univerzita Brno, některé ústavy a fakulty Univerzity Karlovy. 4

5 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. 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. 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 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. Úč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. 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é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 5

6 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ž jejich 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ů. Průběh vodopádového a iteracemi řízeného projektu. 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 zadání správně zanalyzovat a pochopit (teoreticky) a podle toho vytvořit odpovídající dílo. Ve druhém věříme našim zkušenostem z předchozích projektů a tomu, že jsme podobné činnosti jež mnohokrát dělali, a jsme tudíž schopni je dobře rozplánovat. 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, 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 testování na většině projektů to však nebývá možné, protože termíny jsou již dopředu napjaté a času na realizaci je málo. U iteračního přístupu díky průběžné zpětné vazbě toto riziko nepochopení nebývá zdaleka tak fatální. 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 6

7 Co je úlohou analytika (lepidlo, most a transformátor) 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ě testová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 procesy 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] Tomáš Vahalík 7 7

8 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 . ing 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í. ing 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 ingu snadno a spolehlivě naplnit? 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 komunikač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. 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 u 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í ů (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 ový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 u (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ý ? 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í. Miroslav Žebrák 8

9 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 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é. 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 který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í. 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 9

10 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. 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 telefonicky 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í. 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 renomovaný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 , 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- 10

11 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é. 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š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 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. Doba obsluhy požadavků, 80tý percentil Přehled vykázaných hodin 11 11

12 Š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. Pro koho jsou školení určena Ú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. Designer Š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 dimenzí (ú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 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. Průběh školení Osnovu obou výše uvedených školení naleznete na webu společnosti KOMIX ( v sekci Produkty a služby - Školení Prostředí QlikView. 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 nemovitosti 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- 12

13 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 kvalifikace), 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í? Nejvíce žádostí evidujeme na podporu investic v oblasti využití obnovitelných zdrojů energie (oblast 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 Rozhovor vedl Jiří Tománek 13 13

14 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. CASting 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. CA- Sting 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í, 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 e- mailu. Komunikace je možná na úrovni individuální či hromadného u 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

15 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á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. Rozcestník 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é

16 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 informační ové 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. 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ě), ale jejich popis by byl mnohem delší, než si tento článek předsevzal. 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. Martin Janček 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,...). 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? 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. 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). 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: 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; Úvodní stránka testovací aplikace 16

17 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. 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 Standardní přihlašovací stránka, která je součástí instalace 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. 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, WS- Trust, 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 17

18 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 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). 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 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. 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ří- Připravte se Spisové služby, jsou-li vůbec v organizaci zavedeleté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í. 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. 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, ové 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 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- 18

19 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 ibm.com/software/data/optim/protect-data-privacy/ a 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 zdokonalení 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 19

20 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. 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. Proces volby technologie GUI 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 neomezenou 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. 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 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. 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 20