2011

Nepřehlédněte: Inxmail – efektivní e-marketing v praxi KOMIX pokrývá oblast e-marketingu produktem společnosti Inxmail, který se jmenuje Inxmail Professional. Mailing v Inxmail Professional přináší marketérům a obchodníkům řadu významných výhod. Inxmail poskytuje řešení, které se

komix noviny 2010/2011

osvědčilo ve více než 1000 marketingových odděleních a agenturách. Str. 8.

Vážení čtenáři,

QlikView na všechno a pro každého minulý rok jsem si na tomto místě postěžoval, že není jednoduché psát úvodník k časopisu, který vyjde až za řadu týdnů, v situaci, která se mění každý den. Letos to je podobné. Úvodník píši před jmenováním nové vlády, ve vzduchu je řada příslibů, záměrů, ale na to, jakým způsobem budou realizovány a jak rychle, si budeme muset ještě počkat.

Produkt QlikView je nástroj Business Intelligence,

Další velkou výzvou a zároveň velkou neznámou je rozvoj eGovernmentu v naší republice. Řada projektů v oblasti eGovernmentu se stala běžnou součástí našeho života, např. datové schránky nebo CzechPoint. Pasy s čipy obsahujícími biometrické informace používáme běžně, ale třeba projekt registrů trochu tápe, nabírá zpoždění, a ani několik měsíců poté, co měly registry podle původní verze zákona fungovat, nejsou známi řešitelé některých z nich. Přitom právě CzechPoint a tento koncept k nám jezdí studovat zahraniční delegace. Domnívám se, že právě v oblasti eGovernmentu má Česká republika šanci se prosadit a tyto projekty se mohou stát naším exportním artiklem. KOMIX by samozřejmě byl rád u toho a přispěl svou prací k úspěchu těchto projektů. Vám, čtenářům, přeji, aby každý z vás v tomto čísle našich novin našel něco, co je pro něho užitečné nebo zajímavé. Naším úmyslem je poskytnout informace o tom, co v současnosti děláme a čím se zabýváme nebo informovat o nových vlastnostech námi používaných technologií. Petr Kučera

lům zkoumat velký objem dat zcela libovolným

Odborníci tvrdí, že právě období, kdy nás zasáhla krize, ukazuje, že je třeba zlepšit způsoby řízení firem a zlepšit podporu prodejních procesů. KOMIX na tento požadavek reaguje nabídkou komplexního řešení manažerských informačních systémů, podporou procesů prodeje postavenou na osvědčeném CRM řešení společnosti CAS (Computer Aided Sales) nebo nástrojem pro efektivní řízení marketingových kampaní Inxmail. Oba uvedené nástroje jsme schopni implementovat u zákazníka nebo poskytnout jako službu provozovanou na našem serveru za měsíční poplatek, a tedy bez odrazující počáteční investice. Žádná z těchto technologií ale neumí konkurovat chobotnici, která neomylně předpovídala výsledky fotbalového mistrovství světa. Bylo by zajímavé zjistit, zda byla opravdu ponechána sama sobě nebo v pozadí za ni pracoval nějaký analytický tým, a pokud tomu tak bylo, jaké technologie a metody využíval. Je zajímavé, že právě ve sportu se analýza dat zcela běžně využívá jako nástroj pro analýzu činnosti jak vlastního týmu, tak konkurence, a špičkové týmy se bez svého analytika neobejdou. Ve firmách tomu tak často není. Proč?

který je založen na patentovaném principu, tzv. asociativní in-memory analýzy (IMA). Díky této technologii QlikView umožňuje svým uživatezpůsobem bez jakýchkoliv omezení s odezvou několika málo vteřin. Str. 9.

CASting - najděte svou STAR! Pracujete s talenty a jejich informacemi včetně fotografií, videí a dalších dokumentů? Potřebuje talenty vyhledávat, výsledky předávat a komunikovat s talenty i produkcí. Pak je CASting ta správná volba pro vás. Str. 14.

JOSSO aneb systém jednotného přihlášení Podstatou systému jednotného přihlášení pracujícího s pomocí infrastruktury Java Open Single Sign On (JOSSO) je snaha zefektivnit a zjednodušit práci uživatelům, kteří jsou nuceni si pamatovat velké množství přihlašovacích údajů do různých systémů a aplikací. S JOSSO potřebujete jen jeden přihlašovací údaj. Str. 16.

Datové schránky – první krok k Národnímu digitálnímu archivu Informační systém datových schránek (ISDS) slouží k obousměrné komunikaci mezi právnickými osobami (firmami) a orgány veřejné moci. Pro uvedené organizace a úřady je tento způsob komunikace povinný a prioritní ze zákona. S implementací rozhraní Národního digitálního archivu se počítá v roce 2012. Str. 18.

Technologie – dobrý sluha, špatný pán Na počátku snahy RIA byla snaha o jednoduchost tvorby aplikací. Tato snaha trvá dodnes, ale již nyní je zřejmé, že složité GUI nelze vytvořit jednoduše. Jsou-li tedy důležité zkušenosti návrháře a programátora, je důležité omezit fluktuaci těchto pracovníků a hlavně – dobře dokumentovat úroveň dosaženého poznání. Nenechte se pasivně unášet překotným vývojem RIA technologií! Str. 19.

1

Manažerské informační systémy nejen pro manažery “Decision making and the techniques and technologies to support and automate it will be the next competitive battleground for organizations.“ Tom Davenport, author of Competing on Analytics

studovat stejně pečlivě, jako fotbaloví nebo hokejoví trenéři studují hru soupeřů.

Firma jako dynamický systém

Základní požadavky na moderní MIS

Pokusme se podívat na firmu očima standardní teorie řízení, viz. obrázek. V teorii řízení máme obvykle nastaven nějaký vektor (např. sadu KPI) jako požadovaný výstup řízené sestavy a máme k dispozici vektor vstupních veličin, kterými můžeme celou soustavu řídit. Vedle toho na řízenou soustavu působí poruchy, které ji vyvádějí z rovnovážného stavu, a to se v důsledku projeví změnami hodnot na výstupu. Měříme odchylku aktuálního stavu od požadovaného - získáváme regulační odchylku – a tu zavádíme spolu s vektorem požadovaných výstupů do regulátoru (vytváříme zpětnou vazbu), který generuje řízení, jehož účelem je převést soustavu do žádaného stavu. Jak projevy poruchy, tak měřitelné reakce na řídící zásahy jsme schopni obvykle měřit až se zpožděním. To podstatné, co si musíme uvědomit je, že měřené výstupní hodnoty závisí na vnitřních stavech systému a v nelineárních systémech není z naměřeného výstupu obecně možné vnitřní stav jednoznačně určit. Firma je zcela jistě složitý nelineární systém, který nelze jednoduše popsat. Z hlediska teorie řízení má před sebou vedení firmy několik základních problémů: a) definici optimálního cíle řízení – to je podstatné strategické rozhodnutí, b) rozpoznání stavu, ve kterém se řízená společnost nachází, c) identifikaci řízeného objektu – tj. rozpoznání zákonitostí, podle kterých se firma chová, d) zjištění omezení, se kterými je třeba pracovat, a e) určení optimálního způsobu řízení tak, aby při respektování existujících omezení bylo možno dosáhnout v daném čase požadovaných cílů. V teorii automatického řízení se dále pracuje s pojmy řiditelnost a pozorovatelnost systémů. Z hlediska praxe je zejména při konstrukci mnohorozměrných systémů automatického řízení důležité vědět, zda řešení daného problému vůbec existuje. Je-li systém pozorovatelný a řiditelný, lze o řešitelnosti zadaného problému poměrně snadno rozhodnout. Pojem řiditelnosti se definuje pomocí pojmu dosažitelnosti stavu. Zhruba řečeno, stav Y je dosažitelný ze stavu X, jestliže existuje (s přihlédnutím k omezením) řízení U, které převede systém ze stavu X do stavu Y. Řiditelnost v podstatě zname-

2

ná, že všechny složky vektoru stavu závisí na vstupu systému. Podstatné je, že mohou existovat stavy X, z nichž se do stavu Y v zadaném čase nelze dostat žádným řízením z množiny, která je k dispozici. Včasné rozpoznání toho, že před management společnosti byl postaven neřešitelný úkol, je k nezaplacení. V takové situaci je pak třeba změnit cílový stav nebo omezení definující množinu přípustných řízení. Pozorovatelnost je duální pojem k řiditelnosti a v podstatě vyjadřuje to, že výstup pozorovatelného systému závisí na všech složkách vektoru stavu. Tj. změna jakékoliv složky stavu se projeví změnou výstupu, kterou lze měřit. Zůstaneme-li ještě u analogie mezi firmou a dynamickým řízeným systémem používaným v teorii regulace, můžeme si ukázat ještě jednu věc. Chcemeli rozpoznat, jak se chová řízený systém, jaké má vlastnosti, případně vytvořit jeho matematický model, zadáváme na jeho vstupy nějaké předem připravené hodnoty (třeba jednotkový skok) a měříme odezvy systému. Vztah mezi výstupem a vstupem se pak snažíme popsat matematickým modelem. Obdobně lze sledovat chování firmy tak, že studujeme, jaké jsou odezvy na různé řídící zásahy, které vedení dělá, jak reaguje firma na poruchy přicházející zvenčí. Tyto znalosti jsou pro rozhodování velice důležité, umožňují odhadnout dopady řídících zásahů nebo vnějších událostí. Měli bychom si uvědomit, že není tak úplně nutné se učit pouze z vlastních chyb/úspěchů nebo jen na vlastní firmě. Prostředí kolem nás poskytuje celou řadu příkladů úspěšných i neúspěšných strategií. Je možno se učit i z chyb a úspěchů jiných. Chování konkurenčních firem by měl management

Z výše uvedeného lze odvodit základní požadavky na manažerský informační systém (MIS). a) Pro stanovení cílů i pro určení pozice řízené společnosti na trhu musí management znát velice dobře nejen možnosti řízené firmy, ale i její pozici na trhu vůči konkurenci. Musí být schopen odhadnout (předvídat), jak se bude trh vyvíjet, jaké požadavky zákazníků nabudou důležitosti, jaké naopak důležitosti pozbudou. Musí vědět, co nového chystá konkurence. Je nutné sledovat síťové závislosti, vazby. Toto je oblast informací, kde se pracuje do značné míry s nestrukturovanými (textovými) informacemi doplňovanými strukturovanými údaji (třeba benchmarking s konkurencí na základě publikovaných ekonomických údajů). Tento požadavek vede na použití nástrojů typu Competitive Intelligence. b) Zcela jistě musí MIS poskytovat detailní informace o ekonomické situaci firmy, její zakázkové náplni, plnění plánu, využití lidského potenciálu atd. Musí být schopen prezentovat trendy vybraných veličin, umožnit hlubší analýzu těch, které jsou agregované, umožnit sledovat veličiny, které se ovlivňují, ve vzájemných vazbách. Tato část MIS pracuje převážně se strukturovanými daty z interních databází. c) Při vytváření a hodnocení strategií nebo při volbě řídících zásahů je třeba pracovat s nějakou sadou scénářů a ty je třeba hodnotit podle zvolených kritérií, pracovat s modely, provádět what-if analýzy. d) Z obrázku vidíme hned dvě oblasti, které mohou významně ovlivnit kvalitu řízení. První z nich je dopravní zpoždění ve zpětné vazbě. Čím je větší, tím obtížněji se soustava řídí. Tj. informaci musí manažer dostat bezprostředně poté, co je k dispozici.

Schéma řízení dynamického systému

informací pro konkrétního manažera lze poměřovat tím, zda změní své rozhodnutí při změně hodnot vybraných parametrů nebo v reakci na určitou událost. Tj. jedná se o rozpoznávání rizik a hodnocení jejich potenciálních dopadů na plnění stanovených cílů. Přitom se samozřejmě musí brát v úvahu komplexnost celého systému a vzájemné vazby mezi údaji, protože většinou je možno činit rozhodnutí až na základě znalosti kombinací určitých hodnot. Na druhé straně každá společnost má potřebu si svá data chránit. Není tedy možné všechny informace poskytovat všem, je třeba implementovat zásadu „nutno znát“. e) Druhou oblastí je schopnost včasného rozpoznání příznaků blížící se poruchy a měření velikosti této poruchy. Ze studie společnosti Gartner je známo, že každá významná porucha je obvykle signalizována nějakými příznaky, které jí předcházejí. Jsme-li schopni je rozpoznat, máme možnost reagovat dříve než ostatní, a tak získat konkurenční výhodu. f) Právě proto, že se řízená společnost nalézá v konkurenčním prostředí a vůbec prostředí neustálých změn, je třeba kontinuálně ověřovat reálnost a smysluplnost stanovených cílů a strategií. Tj. celý systém musí být nastaven tak, aby byl schopen sledovat cíle, které se v čase mění, a měl by být schopen - de facto sám - upozornit na situaci, kdy je třeba stanovené cíle přehodnotit, a podporovat i vlastní proces přehodnocení cílů. Lze tedy říci, že se v čase vyvíjí jak řízený, tak řídící systém – takové systémy se označují jako systémy evoluční. g) Má-li konstrukce MIS respektovat požadavky na řiditelnost a pozorovatelnost řízeného systému, musíme soubor sledovaných údajů vytvářet tak, aby vypovídal o hodnotách stavu všech důležitých veličin řízeného systému, a repertoár řídících vstupů musí být zvolen tak, aby management byl schopen ovlivnit všechny důležité stavové veličiny. h) MIS nutně musí poskytovat i prostředky pro zpětnou analýzu toho, co se dělo v minulosti. Možnost studovat dopady různých řídících zásahů nebo poruch je velice důležitá pro získání znalostí o chování firmy. Management musí znát vazby mezi údaji a MIS musí podpořit jejich vnímání ve vzájemných souvislostech. i) MIS musí redukovat záplavu dat, která jsou k dispozici, a člověku, který rozhoduje, prezentovat pouze ta data, která jsou v daném čase a pro daný účel podstatná. Měl by být vybaven mechanismy, které dovolí odlišit údaje, které jsou tzv. „v normě“ od stavů signalizujících ohrožení, riziko nebo vypovídajících o tom, že některý ze sledovaných parametrů „vypadl z definovaných mezí“ a na tyto stavy důrazně upozornit (alerty). j) MIS je často vnímán jen jako reporting pro vedení. Když se ale zamyslíme nad požadavky výše,

3

jednoznačně z nich plyne, že MIS je interaktivní nástroj pro podporu rozhodování, který musí být schopen nejen zpracovávat údaje ze svého okolí, ale musí být také schopen přijmout informace o profilu uživatele o tom, co on potřebuje, o čem rozhoduje, musí uživatele podpořit při vytváření a hodnocení různých scénářů nebo rozhodnutí. k) MIS by měl umožnit i provádění řídících zásahů a evidovat jejich plnění. Tj. měl by se stát aktivním řídícím prvkem. l) Samozřejmostí je přehledná a smysluplná prezentace informací, snadné intuitivní ovládání. m) V poslední době se klade důraz na to, aby analýzu dat, či definici/modifikaci potřebných výstupů, mohl dělat koncový uživatel (ne-IT), který zná nejlépe své (rychle se měnící) potřeby a význam dat.

Cílené poskytování informací V každé organizaci se denně dělá celá řada rozhodnutí. V zásadě je můžeme podle jejich dopadu, charakteru a frekvence dělit do tří základních kategorií: strategická, taktická a operativní. MIS by měl poskytovat informace a prostředky pro všechny tyto kategorie rozhodování a zajistit, aby všechna rozhodnutí mohla být dělána s maximální znalostí problému, který je řešen, a se znalostí dopadů daného rozhodnutí. Celá řada operativních rozhodnutí může být s dobrou podporou MIS částečně nebo plně automatizována. Kvalitu taktického i strategického rozhodování podstatně ovlivňuje komplexnost vstupních informací a možnost modelování dopadů různých rozhodnutí. Lidé na různých stupních řízení a v různých útvarech rozhodují o různých věcech. Všichni by měli dostat pro svá rozhodnutí relevantní informace a ty by měly být aktuální a dosažitelné z místa, kde je rozhodnutí třeba učinit – v řadě případů vede tento požadavek na nutnost vzdáleného přístupu k datům z mobilních zařízení.

Z toho plyne několik dalších požadavků na konstrukci MIS. a) Musí být vybaven mechanismem přístupových práv, který umožní definovat, kdo je oprávněn pracovat s jakými informacemi. b) Měl by umožnit individuální úpravy způsobu prezentace dat, jejich výběru i rozložení na obrazovce. c) Musí umožnit distribuci relevantních informací co nejblíže místu rozhodování. To v řadě případů vede k nutnosti přístupu do MIS z mobilních zařízení, což na druhé straně komplikuje zajištění bezpečnosti. Shrnutí: Moderní MIS musí být schopen pracovat jak s nestrukturovanými, tak strukturovanými daty. Musí být konstruován tak, aby byl schopen sledovat cíle, které se v čase mění, být schopen rozpoznat příznaky změn, které mohou mít závažný dopad na chod řízené společnosti, a na takové příznaky sám aktivně upozornit. Informace musí být k dispozici v co nejkratším čase a musí pokrývat všechny důležité parametry potřebné pro rozhodovací proces. Musí být prezentovány přehledným a názorným způsobem a být přístupné z místa, kde je třeba rozhodnutí udělat. Výhodou je možnost modelování, what-if analýzy, případně podpora aktivního zásahu do řízení přímo z MIS. Z hlediska architektury se pak takový MIS obvykle skládá z několika vzájemně integrovaných aplikací. Proto má KOMIX ve svém portfoliu jak nástroje pro zpracování strukturovaných dat, např. standardní BI řešení společností IBM, Microsoft, Oracle nebo QlikView (in-memory analysis, velice rychlé odezvy, what-if analýza, intuitivní ovládání podpořené automatickým využitím znalostí o vazbách mezi údaji), tak nástroje typu Competitive Intelligence jako je Knowledge XChanger společnosti Comintelli. V rámci našeho řešení jsme schopni podpořit i přímé zadávání úkolů včetně sledování jejich delegování/rozpadu na dílčí úkoly a jejich plnění. Petr Kučera

Standardním postupem je poměřovat důležitost událostí a informací jejich dopadem na plnění cílů společnosti, její vize a mise. Význam určitého typu

3

Úvaha na téma informace, znalostní báze… a co dál? Prostředí Knihovny, ve smyslu souborů informací shromážděných na jednom místě, nejsou jen doménou veřejných institucí (obecních či městských knihoven), škol anebo vědeckých ústavů či univerzit. Potřeba shromažďovat a uchovávat informace, znalosti, postupy, tipy a fígle se dříve či později objeví v každém pracovním prostředí, kde se něco tvoří, buduje a vymýšlí. Ať jsou to nanomateriály, informační systémy anebo dřevěné hračky. Samozřejmě, se složitostí a komplikovaností práce se zároveň zvětšuje i balík informací, které je třeba uchovávat. Firma, jakou je KOMIX s.r.o., zabývající se vývojem software, jeho aplikací a správou, a především pak kolektiv firmy, který se živí hledáním řešení rozmanitých ale specifických úloh v oblasti informatiky, takovým prostředím bezesporu je. Pokusme se charakterizovat naše pracoviště podle toho, jací lidé v něm působí a jaký je jejich vztah k informacím, znalostem a zkušenostem: - pracovník – specialista – je to člověk vesměs úzce zaměřený na svůj obor, ve kterém se výborně orientuje a v němž dosahuje vysoké úrovně specifických znalostí, - pracovník – praktik – je zase člověk, který se důkladně a obvykle dost dlouho zabývá danou problematikou, během své praxe získal celou řadu jinde nedostupných zkušeností, - pracovník – fluktuant – toto je člověk, který během své kariéry obvykle projde různými pracovišti, ať v rámci jedné firmy nebo mezi firmami. Jsou to taková pracoviště, kde může co nejlépe uplatnit své schopnosti a získat při tom nové zkušenosti. Z tohoto pohledu se dá shrnout, že v prostředí (softwarové) firmy se nakládá s informacemi, které jsou úzce zaměřené na danou problematiku. V mnoha případech jsou to znalosti a dovednosti, které vyplynou až z praxe a nelze je získat jinou běžnou cestou (absolvováním vzdělávací instituce, z literatury).

A jak s řešením nových úkolů? Proces může být následující: 1. shromažďování znalostí - nejprve se hledá ve vlastní paměti, zda jsme něco podobného už nevykoumali, pak je to snadné. Když se nám ale potřebných znalostí nedostává, obracíme se na externí zdroje: - do literatury, manuálů, poznámek, - na internet, do manpages, na diskusní fóra, - na kolegy. Samozřejmě každý k tomu přistupuje podle své povahy.

4

2. řešení problému - získané informace kompilujeme, navrhneme si řešení, vypracujeme, odzkoušíme a předáme. 3. reflexe - na tu obvykle není čas, protože před námi už čeká něco nového, další zadání. Přitom je tento krok velmi důležitý a měl by být svázaný s následujícím, na který se však často zapomíná. Tímto krokem je: 4. zdokumentování – (zobecnění) a zaznamenání vypracovaných postupů (how-to), zaznamenání získaných znalostí, minimálně informací o informacích (rešerše).

Mám informaci, kam s ní? Když nepřeskočíme výše zmíněný poslední bod – zdokumentování - vyvstane další problém. Totiž, jakým způsobem získané a vytvořené informace uchovat. Tedy uložit a uchovat je tak, aby se daly znovu využít. Běžně se k zaznamenání využívá papírová forma, rukopisně anebo tiskem. Jednak je to rychlé, relativně levné, je to ale také snadné a tradiční (ačkoliv ještě tradičnějšího papyru a pergamenu se dnes už bohužel neužívá). Výsledek - ve skříni se kupí složky s dokumenty a poznámkami a popsané sešity. Další možnost je uchovávat dokumenty v systému složek a souborů ve svém počítači. Nebo jinou oblíbenou formou jsou záložky ve webovém prohlížeči. Jakkoliv je autor záznamů pečlivý, tento způsob nebývá příliš efektivní. Jednak se řada informací ztrácí, překryta novými záznamy, a hlavně, vytvářené soubory dat (poznámky, textové soubory) jsou v rámci pracoviště disjunktní a prakticky využitelné jen jejich autorem. V současnosti je ovšem k dispozici celá řada programových nástrojů na správu dokumentů, souborů, včetně utilit pro vytváření metainformací (autor, stáří dokumentu, verze) a indexování obsahu. Když se ale zamyslíme nad charakterem informací, jaký se uvádí výše, není jisté, zda by běžné DMS (Document Management System) právě nám vyhovovaly. Potřebujeme totiž systém, v němž by bylo možné, aby: 1. byl obsah systému široce dostupný, 2. šlo nově získanou informaci snadno zaznamenat, 3. zaznamenanou informaci bylo možné rychle najít, 4. byly úkony spojené s úpravou obsahu uživatelsky orientované, tj. aby bylo jasné, kdo, kdy a co vložil, změnil a odstranil. Případně, aby bylo možné nastavit nějaká pravidla omezující/rozšiřující uživatelská oprávnění,

5. bylo možné pracovat s různými typy dokumentu (text, multimedia, soubory).

On-line encyklopedie Výše uvedené body splňuje dnes již celosvětově známý software mediawiki. Tento software je základem pro většinu Wikipedií světa. Wikipedie, kterou známe jako webovou encyklopedii, rozšířenou a používanou v mnoha lokalizacích, se dá poměrně snadno využít i v „uzavřeném“ firemním prostředí právě k tomu účelu, který potřebujeme. 1. S wikipedií se pracuje v prostředí (libovolného) internetového browseru; 2. Vytvořit obsahovou stránku je možné v okně wikipedie: - jako prostý text, s využitím formátovacích značek wikipedie, které není složité zvládnout, - s využitím případného wysiwyg editoru, - nebo je možné text vytvářet v externím editoru a exportovat do formátu wikipedie (to umožňuje například OpenOffice). 3. Hledání v obsahu probíhá podle konkrétních názvů položek – záznamů, následně fultextovým vyhledáváním. Informace se dají kategorizovat a tematicky seskupovat. 4. Výchozí vlastností encyklopedie je, že každý uživatel může vytvářet a upravovat její obsah a má přístup ke všem položkám obsahu, kromě položek systému a správy. Prostředí je uživatelsky orientované, tj. každý uživatel se může identifikovat, vytvořit si pro sebe vlastní uživatelské konto. To lze samozřejmě modifikovat a omezit možnost zakládání kont svépomocí, anebo nastavit mapování uživatelů proti nějaké externí databázi. V návaznosti na to je rovněž možné definovat pravidla nakládání s obsahem na principu jmenných prostorů, kterými se systém rozčlení, a uživatelských rolí k nim vázaných. 5. Obsah encyklopedie se prvotně vytváří jako text – případně doplněný obrázky. Nicméně do systému se dají importovat i další typy souborů – multimedia (flash, video, zvuk), soubory ke stažení (přípustné formáty souborů lze definovat v konfiguraci). Mediawiki software použivají pro vytvoření vlastní znalostní báze nejen webové projekty, například dále zmiňovaný Moodle (www.moodle.org), ale i instituce, například ČVUT, Masarykova univerzita Brno, některé ústavy a fakulty Univerzity Karlovy.

Malý oslí můstek.. Informace nestačí jen vytěžit a uchovat v systému znalostní báze, je také potřeba čas od času zařídit, aby se dostaly k nějaké cílové skupině – v našem případě dalším specialistům, informatikům. Běžně se pořádají v rámci kolektivu, pracoviště či firmy školení a workshopy. Je také možné sepsat a distribuovat nějaké to how-to, manuál či prezentaci. Oba přístupy mají ale své vady na kráse. V případě faceto-face konfrontace je to jednorázovost a neopakovatelnost akce, takže ten, kdo se jí nezúčastní, přijde o mnoho podstatného. K dispozici zbudou jen podpůrné materiály, sylabus či prezentace, a musíme se tak spolehnout na zprostředkované informace od účastníků akce. Naopak materiály dodané v nějaké printable ready verzi mohou být komplexní a vyčerpávající, ale už v okamžiku, kdy se dostanou k uživateli, jsou ve větší či menší míře zastaralé. Rovněž tu hraje velkou roli sama cílová osoba a její nálada, únava, soustředění a ochota se učit.

LMS LMS je zkratka pro Learning Management System, který častěji a nepřesně označujeme jen jako e-learning.

Source pod licencí GNU GPL). Použitím LMS můžeme dostat proces vzdělávání takříkajíc „pod kontrolu“. Správně navržený e-learning zajišťuje: - Přístup ke vzdělávacímu obsahu pro tutora (učitele, vyučujícího) a účastníka (žáka) nezávisle na místě a čase, oba pracují ve virtuální třídě dle svých potřeb a možností. Samozřejmě až na vyjímky, kdy jde například o on-line konferenční uspořádání; - Možnost kontroly aktivity účastníků ze strany učitele, včetně využití nástrojů pro hodnocení. Je zde snažší přizpůsobit se individuálním schopnostem a potřebám každého účastníka; - Systémy často umožňují vazbu do PIM (Personálního informačního managementu) firmy, školy, instituce; - Zpětnou vazbu mezi účastníkem a vyučujícím. E-learning vytváří prostředí pro komunikaci a pro kooperativní jednání mezi jednotlivými účastníky, i když je mezi nimi třeba geografická bariéra; - Jednou z nejsilnějších zbraní při použití LMS je jiný přístup ke vzdělávacímu procesu, než na jaký jsme zvyklí. Účastník e-learningového kurzu není jen pasivním objektem vzdělávání, kdy kantor jest ten, kdo učí, žáci pak ti, kteří se učí. Účastník se naopak stává aktivním prvkem tvorby vzdělávacího obsahu.

Pod tím pojmem se nám asi nejčastěji vybaví různé vzdělávací aktivity v prostředí internetu, od kurzů tantrické jógy, přes jazykové kurzy, až po systémy univerzitního distančního vzdělávání. Za tím vším je ale vždy nějaký softwarový nástroj pro řízení vzdělávacího procesu.

Účastníky je možné rozčlenit do pracovních skupin pro zpracování úlohy a využít na jedné straně kooperační a na druhé straně kompetiční prostředí pro to, aby co nejefektivněji zvládli dovednosti a znalosti.

Pro naše prostředí jsme se zaměřili na LMS Moodle, který je vcelku v domácím prostředí rozšířený (a za určitých podmínek ho lze využívat jako Open

Jak tedy využít LMS v rámci našeho modelu softwarové firmy? Příkladů může být mnoho. Často zmiňovanou úlohou je plán integračního procesu nové-

5

ho zaměstnance. Příchozí pracovník je nucen v co nejkratší době zvládnout různé obecné úlohy – seznámit se s pracovním prostředím firmy a jeho pravidly, podstoupit povinná školení (BOZP, požární ochrana, etika pro pracovníky firmy) a dále se adaptovat na svou novou práci a její náplň. Postupné absolvování dílčích kurzů firemního e-learningu podle schématu sestaveného šikovným personalistou není špatný nápad. Jinou zvažovanou úlohou je potřeba specializace – rozšíření znalostí. Pokud jde o opakující se situaci, je mnohem efektivnější, aby existoval e-learningový kurz (udržovaný na aktuální úrovni), než pořádat další a daší školení jednou za čas. K již absolvovaným kurzům se mohou jejich účastníci vracet podle své potřeby. E-learningovou formu můžeme také použít na podporu svých produktů směrem k zákazníkům – je to efektivnější, než aktualizovat dokumentaci a pořádat nová školení pro tytéž účastníky.

A na závěr poznámka, jak spolu souvisí znalostní báze a e-learning? Pochopitelně velmi úzce. Díky modularitě většiny LMS (Moodle nevyjímaje) bývá znalostní báze typu wikipedie součástí systému LMS anebo jsou s ním úzce propojené. Obsah báze pak slouží jako opakovatelně využitelná součást vzdělávacího obsahu jednotlivých kurzů. Nástroje wiki se také používají při vzdělávacím procesu, například při vytváření „slovníku pojmů“ pro konkrétní kurz jeho účastníky. Pavel Körner

5

Iteracemi proti rizikům Nepletu-li se, je to již potřetí, co se na stránkách komixích novin dotýkám tématiky iteračního vývoje. Možná někoho napadne: obehraná písnička. Budiž. Jsem však přesvědčen, že osvěta v této oblasti je stále aktuální a má smysl se k ní průběžně vracet. Tentokrát bych se rád na použití iteračního vývoje podíval především z hlediska eliminace klasických rizik, která přináší snad každý – nejen softwarový – projekt. První z rizik lze charakterizovat jako „riziko nesprávného pochopení“. Obzvláště dělámeli první projekt u nového zákazníka, pouštíme se do nové problematiky či začínáme pracovat s novým týmem, můžeme si být téměř jisti, že vytvořené dílo nebude 100% odpovídat potřebám uživatele. Zárodky těchto nedokonalostí vznikají již ve fázi analýzy, kdy zadavatel nesprávně formuluje své potřeby a/nebo naši analytici jim chybně porozumí. V následných fázích návrhu a implementace se tyto odchylky většinou dále prohlubují a často k nim přibývají další způsobené tím, jak analytické zadání pochopil návrhář, resp. jak návrh pochopil programátor. Druhé typické projektové riziko, které se však nezmiňuje tak často jako to výše uvedené, bych nazval „rizikem obtížných začátků“. Opět a možná ještě více než u předchozího se toto riziko uplatňuje na projektech v novém prostředí. Ať máme k dispozici sebezkušenější tým, vždy musíme počítat s tím, že na začátku každé, na daném projektu dosud neprováděné činnosti, se objeví komplikace, které jsme dopředu nebyli schopni odhadnout. Projevuje se to v úvodu analytické fáze, kdy nás často zdržuje potřeba nalezení společné řeči se zákazníkem. Podobně na začátku implementačních prací trvá nezanedbatelnou dobu, než vznikne plně funkční a efektivní vývojové prostředí. Snad nejčastěji dochází k problémům, když se vytvořené aplikace přenášejí z interního vývojového prostředí do prostředí integračních a zákaznických testů. Čím více různých subjektů se na projektu podílí, přičemž je-

jich dílčí výstupy se právě v této fázi začínají spojovat dohromady, tím větší chaos vzniká a téměř vždy dochází k ohrožení projektových termínů. Obě výše uvedená rizika mají společnou příčinu v naivní víře v soulad teorie s praxí. V prvním případě jde o přesvědčení, že jsme schopni za- Riziko spojené s problémy vznikajícími na začátku nově prováděných činností. že si vyhradíme dostatečné množství času na tesdání správně zanalyzovat a pochopit (teoreticky) tování – na většině projektů to však nebývá moža podle toho vytvořit odpovídající dílo. Ve druhém né, protože termíny jsou již dopředu napjaté a času věříme našim zkušenostem z předchozích projektů na realizaci je málo. U iteračního přístupu díky průa tomu, že jsme podobné činnosti jež mnohokrát běžné zpětné vazbě toto „riziko nepochopení“ nedělali, a jsme tudíž schopni je dobře rozplánovat. bývá zdaleka tak fatální. Na těchto domněnkách, dle praktických zkušeností často mylných, je založen vodopádový životní cyklus. Iterační přístup se naopak snaží uvedené problémy omezit průběžným ověřováním výstupů a postupným zdokonalováním projektových postupů.

Zkusme k oběma rizikům přistoupit malinko vědecky a „namodelovat“ si je, jakož i způsob jejich eliminace. Na prvním obrázku je naznačen průběh vodopádového a iteracemi řízeného projektu formou vycházející z tzv. V-modelu. Tento lze chápat jako graf zobrazující průběh množství nejistoty, že vzniká to, co zákazník skutečně potřebuje (a ve správné kvalitě) v závislosti na čase. Během analytických, návrhových a konstrukčních prací tato nejistota narůstá, protože nemáme k dispozici jasné potvrzení, že vytvářené dílo odpovídá původnímu záměru. Teprve v jednotlivých fázích testování se postupně dopracujeme k poznání, zda je dílo kvalitní (bez vad) a zda vyhovuje potřebám zákazníka. Z grafu je patrný velký rozdíl v míře nejistoty s jakou pracujeme na vodopádovém projektu (silná barevná čára) ve srovnání s iteračním přístupem (tenká barevná čára). Je zřejmé, že pokud zjistíme nějaký principální problém při testování ve vodopádem řízeném projektu, zásadním způsobem klesají naše šance na dodržení projektových termínů a kvality. Teoreticky lze riziko omezit při plánování projektu tím, Průběh vodopádového a iteracemi řízeného projektu.

6

Druhý obrázek schématicky znázorňuje riziko spojené s problémy vznikajícími na začátku nově prováděných činností (jednotlivé barvy znázorňují stejné aktivity jako na prvním obrázku). Riziko je tentokrát zobrazené jako množství chaosu na projektu v závislosti na čase. Ve vodopádovém projektu jsou sice jednotlivé „chaosy“ rovnoměrněji rozděleny do celého průběhu projektu, problém je ale v tom, že činnosti, které mají největší sklon k chaotičnosti (a tím zvyšování rizika), začínají až v pozdních fázích projektu. To je v době, kdy se typicky již dohánějí jiné skluzy vzniklé v předešlých fázích a další zdroj zmatků se již může stát fatálním (minimálně má negativní vliv na psychiku členů týmu, kteří se beztoho již dostávají do velkého tlaku). V iteračním přístupu se většina aktivit rozbíhá již v počátečních fázích projektu, což sice zvyšuje celkovou chaotičnost v tomto období (v prvních iteracích se moc skutečné práce neudělá a s tím je třeba počítat při plánování projektu), ale je to v době, kdy pro většinu členů týmu ještě není tak moc skutečné „tvůrčí“ práce a nenesou si s sebou „resty“ z předchozích fází projektu. A navíc, počáteční chaotičnost u jednotlivých aktivit nenabývá takových rozměrů, protože dílo, se kterým se v úvodních iteracích pracuje, není rozsáhlé. Důvodů pro použití iteračního vývoje je mnoho, v tomto článku jsem se pokusil podrobněji vysvětlit dva z nich. Na závěr si dovolím vytyčit údernické předsevzetí: Prosazujme a používejme na projektech iterační přístup a naučme tomu i naše zákazníky a partnery. Vyplatí se to nám i našim zákazníkům. Petr Sobotka

Co je úlohou analytika (lepidlo, most a transformátor) vány a integrovány. Na analytikovi zůstává průběžný dohled a zodpovědnost, že po věcné stránce bude dodané řešení v souladu s tím, co zákazník potřebuje. Analytik je „lepidlem“ zajišťujícím, že dílčí výstupy vývojového týmu do sebe zapadnou a budou tvořit smysluplný celek odpovídající očekáváním a cílům zákazníka. Moderní metody vývoje softwaru kladou větší důraz na týmy složené z různých rolí a z pracovníků, kteří nejsou úzce specializovaní, ale mají širší přehled a lepší předpoklady pro komunikaci mezi různými profesními rolemi uvnitř týmu. Analytik je příkladem takové role, kde je nutný širší záběr, protože analytik je mostem při komunikaci mezi uživatelem (tím, kdo má zájem na vytvoření softwaru) a technologií (vývojovým týmem). V dnešní době se ekonomická krize dotýká i informačních technologií. Hlavním cílem je ušetřit, firmy proto odkládají IT projekty nebo se omezují na projekty zaměřené na udržení zákazníků, na zvýšení efektivity a na optimalizaci interních procesů. Přednost mají krátké projekty s konkrétními a rychlými přínosy. Krátké termíny realizace jsou často spojeny s nestabilními a nejasnými funkčními požadavky zákazníka. Tato situace není lehká pro analytiky. Aby analytik dokázal odlišit podstatné od nepodstatného a mohl se soustředit na to podstatné, musí rozumět tomu, co jsou jeho hlavní úkoly ve vývojovém týmu. Předchozí věta platí pro každou roli ve vývojovém týmu, a to nejen v oblasti IT. Ale narozdíl od programátora, vedoucího projektu nebo testera, kde jsou jejich vstupy a výstupy obecně známé a jasně vymezené, u analytika je situace poněkud mlhavější. Pro někoho může být analytik zapisovatelem neuspořádaných požadavků zákazníka, pro jiného návrhářem obrazovek, databáze a algoritmů, které programátor už víceméně jen mechanicky kóduje. Pokusme se tedy vyjasnit, co by měly být hlavní úkoly analytika. Následující specifikace pracovní náplně analytika byla vytvořena odbornou skupinou analýzy (SANA) ve společnosti KOMIX.

•

•

•

•

Úlohou analytika je • Porozumět procesům, cílům a skutečným potřebám zákazníka, pro kterého pracuje, pomáhat mu hledat řešení jeho problémů, upozorňovat ho na rizika, navrhovat mu alternativy, navrhnout způsob, jak bude dosaženo a měřeno dosažení cíle. • Identifikovat zúčastněné osoby a organizace, kterých se navrhovaný systém týká. • Specifikovat jednoznačné a ověřitelné požadavky na navrhovaný systém tak, aby tento systém očekávaným způsobem podporoval pro-

7

•

•

cesy zákazníka při plnění jeho cílů. Dále specifikovat rozhraní s okolními systémy, požadavky týkající se provozování systému a další typy požadavků. K řešení technických požadavků včas přizvat příslušného specialistu. Vymezit rozsah řešení v takové úrovni podrobnosti, aby bylo dosaženo shody se zákazníkem na tom, co je předmětem nabízeného řešení a co jde nad rámec dohodnutých prací a aby bylo možné odhadnout pracnost. Rozumět potřebám vývojového týmu a umět mu specifikovat požadavky na systém takovým způsobem, aby byly dostatečným a srozumitelným podkladem pro vývoj. Požadavky mohou být dále upřesňovány se zákazníkem v mezích dohodnutého rozsahu řešení. Průběžně se účastnit vývoje řešení včetně testování s cílem dohlédnout, že po věcné stránce řešení splní potřeby a očekávání zákazníka. Vytvářet analytickou dokumentaci, která umožní dlouhodobý provoz aplikace, její rozvoj a zpracovávání změnových požadavků. Podpořit nasazení řešení u zákazníka tvorbou uživatelské dokumentace, školením, konzultacemi. Poskytovat zákazníkovi konzultace při provozu systému a při rozhodování o jeho dalším rozvoji, umět posoudit dopad případných změn.

Důležité je vědět nejen odkud a kam most vede, ale i kdo, proč a jak často po něm chodí. Podle [1] je vývoj softwaru především transformací znalostí do podoby umožňující jejich strojové použití - tím se software liší od jiných produktů. Proto je tolik důležitá trasovatelnost požadavků (schopnost vysledovat původ požadavků a způsob jejich realizace), která zachycuje tuto transformaci. Pokud se podaří znalost, která je v hlavách lidí a v dokumentech v určité firmě převést (s přispěním analytika jako mostu) do softwarové aplikace, je přínosem nejen vytvoření této aplikace, ale i získání týmu schopného znalosti z určité problémové oblasti tímto způsobem efektivně transformovat. Aplikace je nasazena, tým je rozpuštěn nebo redukován pro účely technické podpory provozu a je zde riziko, že schopnost efektivní transformace znalostí bude ztracena. Protože znalosti se vyvíjí a požadavky na software se mění, vznikne po čase znovu potřeba „přejít po mostě“. Analytik si proto musí být vědom, že dokumentování postupu transformace znalostí do kódu programu (nemusí se jednat o mnohastránkové dokumenty, ale spíše o důslednost dodržování jednoduchých pravidel zajišťujících transparentnost celého postupu) neslouží jen jednorázovému nalezení cesty na druhý břeh. Dokumentace musí umožnit přejít po mostě i v budoucnosti, kdy se vývojový tým může změnit. Odkazy: [1] http://philarmour.wordpress.com/2009/01/ Tomáš Vahalík

Na projektu pracují specialisté s různými rolemi, kteří se podílejí na celkovém řešení. Programátoři vytvářejí dílčí funkce, které jsou postupně testo-

7

Inxmail – efektivní e-marketing v praxi Všechny organizace mají potřebu informovat. Nové úspěchy, nové vlastnosti produktů, nové způsoby využití, nové impulsy pro růst a další novinky mají za cíl přilákat nové zákazníky a zapojit je do stávající komunity existujících spokojených zákazníků. Převažující psanou elektronickou formou je dnes e-mail. E-mailing využívá pro efektivní oslovení osvědčených technik písemné korespondence, jako jsou personalizovaná oslovení, individualizovaný obsah, jednotný podnikový/produktový design a pravidelná nebo individuálně vyžádaná zasílání marketingového sdělení.

E-mail však není jediný písemný elektronický komunikační kanál, který se stal důležitým nástrojem marketérů. Rostoucí zájem marketingových specialistů je soustředěn rovněž na využití populárních sociálních sítí, jako jsou Facebook, LinkedIn, Twitter, MySpace apod. Inxmail je pro komunikaci s těmito komunitními aplikacemi připraven. Doplňkové moduly pro komunikaci se sociálními sítěmi ještě znásobí účinnost zaslaného marketingového sdělení a usnadní možnost jeho virálního šíření. Některé zákaznické segmenty, jako například mladí lidé, považují navíc sociální sítě jako primární způsob vzájemné komunikace. Zaslání zprávy do sociální sítě už není jen konkurenční výhodou, je zásadním ko-

munikačním kanálem v e-marketingovém komunikačním mixu. Inxmail Professional je nejen robustní, ale i flexibilní. Robustní infrastrukturu využijí velké organizace. Celý proces e-marketingu a integrační možnosti zůstává pod kontrolou zákazníka. Ale i řada menších organizací dnes potřebuje řešení, které jim umožní dlouhodobý úspěch a profesionální užití. Nedostatek disponibilních zdrojů pro vybudování vlastní infrastruktury řeší Inxmail Professional možností hostovaného řešení. Zákazníci tak mohou využít další aplikaci, kterou nabízí KOMIX svým zákazníkům v rámci palety hostovaných služeb.

E-mailing je zkrátka schopnost zaslat elektronicky správnou zprávu správné osobě správným formátem ve správný čas. Jednoduše řečeno. Ale dokážete všechny tyto aspekty e-mailingu snadno a spolehlivě naplnit? KOMIX pokrývá oblast e-marketingu produktem společnosti Inxmail, který se jmenuje Inxmail Professional. Mailing v Inxmail Professional přináší marketérům a obchodníkům řadu významných výhod. Mezi zajímavé vlastnosti Inxmailu patří možnost zaslání velkého množství personalizovaného sdělení během velmi krátké doby (až 1 milión zpráv do jedné hodiny), oddělení tvorby obsahu od vzhledu (vzhled je dán předem definovanou šablonou), dynamická kompozice e-mailu dle segmentů příjemce (dle typologie, skupiny, geografického aspektu atd.), generování personalizovaných vrstev do PDF přílohy (podklady pro smlouvu, slevový kupon na jméno apod.), automatizované rozeslání e-mailů (narozeniny uživatele, svátek, definována akce uživatele ve webové prezentaci pro tzv. look marketing), kontrola vzhledu zprávy před jejím odesláním v různých e-mailových prohlížečích, sledování, zdali zaslání zpráv vedlo k jejich otevření atd. Schvalovací work-flow, zabudovaný reporting, otevřené a zdokumentované API, společně s celou řadou doplňkových modulů (např. CAS genesisWorld CRM, Microsoft CRM, Drupal atd.), provedení testu kvality e-mailu (antiphising, antispam), synchronizace databáze adres se systémy třetích stran a další směřují Inxmail do business oblasti, kde jsou jeho funkce velmi pozitivně oceňovány. Velmi cennou informací pro marketéry je zpětná vazba. Možnost zjistit odpovědi na otázky: Kteří zákazníci jak a kdy otevřeli zaslaný e-mail? Kdo klikl na obsažený odkaz? apod. Odpovědi na tyto otázky podávají velmi cenné informace, které umožňují nejenom vytvářet pokročilé behaviorální segmentace, ale jsou rovněž základem pro reálná vyhodnocení úspěšnosti marketingových kampaní.

8

Miroslav Žebrák

QV na všechno a pro každého Pokud o čemkoliv někde čteme, že je to na všechno, pro každého či podobně, tak se posléze velmi často ukáže, že je to spíše na nic. V následujících řádcích vám, vážení čtenáři, přiblížíme, že v případě produktu QlikView platí nadpis článku v plném rozsahu. Takže nejprve rychlé přiblížení. Produkt QlikView je založen na patentovaném principu tzv. asociativní in-memory analýzy (IMA), která umožňuje uživatelům zkoumat data zcela libovolným způsobem bez jakýchkoliv omezení. Veškerá data (metadata, ETL services, vlastní dimensionální i faktové údaje) jsou načítána z datových zdrojů a následně uložena do souboru na disku. Při práci koncového uživatele s QlikView aplikací je vždy celý soubor načten do paměti počítače, a tak je vždy k dispozici jak úplný datový model (tj. možnost zadávání jakýchkoliv kombinací výběrových kriterií), tak i všechny faktové údaje. Tímto způsobem je zajištěno, že odezvy i na velmi komplikované dotazy nad velkými soubory dat (stamiliony řádků) jsou buď okamžité či v řádu jednotek sekund. Výše uvedený popis může, v tuto chvíli ještě celkem oprávněně, budit u čtenáře jistou nedůvěru jak ve funkčnost, tak zejména ve výkonnost produktu QlikView. Stejnou či ještě větší nedůvěru jsme pociťovali i my při prvním ověřování vlastností produktu QlikView. Zvolili jsme proto cestu nejmenšího odporu a pro ověření jsme převedli do prostředí QlikView jednu z aplikací referenčního projektu datového skladu pro ZP MV ČR. Jednalo se o datové tržiště „Kmen pojištěnců“ realizované v prostředí MicroStrategy s daty uloženými v DB Informix. Rozsah datového tržiště odpovídal cca 130 mil. záznamům provozního IS, atomická tabulka faktů byla v rozsahu cca 35 mil. záznamů a pro účel testovaného souboru výstupů byla využita agregovaná faktová tabulka o rozsahu cca 9 mil. záznamů. Doby odezvy v prostředí MicroStrategy + DB Informix se pohybovaly v rozsahu cca 1 – 3 minuty pro jednodušší výstupy, přes cca 5 – 7 minut pro náročnější výstupy, až po 14 a více minut pro ty nejrozsáhlejší výstupy. Po převedení datového tržiště „Kmen pojištěnců“ do prostředí QlikView jsme s napětím očekávali výsledek. Rádi na tomto místě konstatujeme, že výsledek předčil očekávání. Doby odezvy byly buď okamžité, nebo v řádu 1 – 2 sekund pro převážnou většinu výstupů. Pouze ty nejrozsáhlejší výstupy měly „měřitelnou“ dobu odezvy v rozsahu cca 5 – 6 sekund. Zdůrazňuji, že QlikView aplikace byla realizována nad identickým rozsahem dat. Je tedy zřejmé, že po výše popsané zkušenosti jsme již neváhali a s plnou důvěrou jsme produkt QlikView nasazovali v dalších aplikacích. Po tomto poněkud rozsáhlejším úvodu se konečně dostáváme k první části tohoto příspěvku, a sice

9

QV na všechno - BI & DWH & MIS Doposud jsme byli zvyklí, že v oblasti BI & DWH & MIS jsme se z větší části zabývali tzv. nadstavbovými řešeními, kdy se z prostředí jednotlivých provozních IS načítaly vybrané údaje, ty se následně integrovaly a nad takto získanými údaji byly k dispozici různé statistické, analytické a další výstupy. Tyto principy byly beze zbytku realizovány v prostředí produktu QlikView. Zásadní skutečností je však univerzálnost a rychlost realizace projektů v prostředí QlikView. Jak mnozí víme, tak firma KOMIX s.r.o. v oblasti BI & DWH & MIS realizovala v minulosti projekty zejména pro instituce typu ČSSZ, zdravotní pojišťovny, GŘ cel a podobné instituce. Jaké změny tedy přinesla realizace srovnatelných projektů v prostředí QlikView ? a) Doba realizace Doba realizace výše uvedených projektů byly řádově člověkoměsíce. Realizace srovnatelných projektů v prostředí QlikView je výrazně kratší – jedná se o člověkotýdny. b) Oblasti nasazení - Zákaznické portfolio Díky rychlému a snadnému vytvoření projektů se podařilo proniknout s BI & DWH & MIS řešeními v prostředí QlikView i do oblastí, které doposud nebyly nijak pokryty. K dnešnímu dni je realizována řada QlikView projektů pro firmy z oblasti retailu, finančnictví na straně jedné ale také pro výrobní či provozní firmy na straně druhé.

rých jsou zapisovány údaje o provozu serverů, aplikací a další technické a technologické záležitosti. Je tedy zřejmé, že tato oblast má velmi blízko k provoznímu reportingu. Realizované QlikView aplikace pak umožňují sledování a vyhodnocování vytížení serverů, mapování provozu aplikací, identifikaci úzkých míst, dlouho trvajících činností apod. Veškeré výstupy jsou pak k dispozici v maximálně přehledném členění, umožňují sledování a vyhodnocování libovolných údajů za libovolné období v libovolném členění, vše opět s maximálním uživatelským komfortem.

QV pro každého Uživatel má pro sledování a vyhledávání požadovaných údajů k dispozici skutečně interaktivní nástroj. Pro práci s aplikací v prostředí QlikView potřebuje pouze ty činnosti a znalosti, které využívá v prostředí MS Windows (používání myši, označení seznamu, výčtu položek, označení výseku grafu). Při práci s aplikací v prostředí QlikView není uživatel žádným způsobem omezován. Odezvy na libovolná zadání jsou i při velkých objemech dat (stamiliony záznamů) okamžité či v řádu jednotek sekund. Aplikace v prostředí QlikView poskytují koncovým uživatelům na jednotlivých úrovních údaje v požadovaném členění a s okamžitou dobou odezvy. K dispozici mohou být jak přehledové údaje (např. dashboardy), tak samozřejmě jakékoliv tabulkové či grafické údaje, např. v níže uvedeném členění.

c) Oblasti nasazení – Provozní reporting Jak již bylo výše uvedeno, drtivá většina BI & DWH & MIS řešení byla doposud určena pro tzv. nadstavbová řešení. S osvojením produktu QlikView nově s výhodou pokrýváme i celé či významné části provozního reportingu, tj. reportingu, který byl doposud řešen převážně v prostředí provozních IS či nesystémovými doplňkovými způsoby (MS Excel a podobně). Příkladem za všechny může být např. realizace klasických výstupů typu Rozvaha či Výsledovka. Řešení v prostředí QlikView tedy přináší zásadní výhody z prostředí BI & DWH & MIS (uživatelský komfort, jedna verze pravdy, rychlost atd.) i pro koncové uživatele z prostředí provozního reportingu. d) Oblasti nasazení – Technologický reporting Nejprve snad kratičce, čemu pro účel tohoto článku říkáme technologický reporting. Máme na mysli zejména vytěžování příslušných log souborů, do kte-

Samozřejmostí je pak možnost zobrazení požadovaného detailu i volbou příslušného výseku z grafického výstupu, jak je zřejmé z předchozího a na následujícím obrázku.

9

tailní pohledy i na nejnižší úroveň detailu, • v rámci QlikView aplikace mohu interaktivně zadávat jakékoliv kombinace výběrových kriterií v libovolném členění v rámci celého datového modelu, • odezvy na jakýkoliv způsob zadávání na jakékoliv úrovni jsou okamžité či v řádu jednotek sekund.

Vedle výše uvedených globálních či detailnějších výstupů je samozřejmě v rámci jedné QlikView aplikace k dispozici i příslušná detailní informace, např. v následující podobě:

Z výše uvedeného přehledu jsou tedy zřejmé tyto základní vlastnosti aplikací v prostředí QlikView: • jedna každá QlikView aplikace v sobě může zahrnovat jak globální přehledové výstupy, tak i de-

Více než tříleté zkušenosti s realizací projektů v prostředí QlikView nám zcela jednoznačně potvrdily optimisticky avizovanou skutečnost z nadpisu tohoto článku – QlikView je skutečně na všechno a skutečně pro všechny. Pavel Seibert, Tomáš Třmínek

Reporting a analýza obsluhy ICT požadavků Téměř při všech lidských činnostech, jejichž cílem je poskytovat služby většímu počtu zákazníků, vznikla pracoviště, jejichž hlavním úkolem bylo sloužit těmto zákazníkům jako kontaktní místo. Místo, kde si mohou službu objednat, kde jim jednodušší záležitosti na počkání vyřídí a složitější zaevidují, nejistého zákazníka uklidní a seznámí ho s postupem, jak a kdy bude jeho požadavek vyřizován a co je či naopak není očekáváno od něho. Zaevidované požadavky čekající na další zpracování přirozeně nemohou zůstat jen v paměti obsluhujících, ale každé takové pracoviště mělo a má svůj systém evidence. Takové pracoviště není objevem ICT průmyslu a nemusíme si ho představit jen jako kontaktní místo velkých telekomunikačních operátorů vybavené IP telefonií a CRM systémem světových parametrů. Hotelová recepce sice obsluhuje mnohem méně klientů než provozovatel elektrické sítě, na druhé straně spektrum služeb, které hotelovým hostům zajišťuje, je o poznání širší. Tak či onak zákazníci získali jistotu, kam se mohou se svým požadavkem obrátit a dodavatel má nad požadavky soustředěnými do jednoho místa snazší kontrolu. ky nebo prostřednictvím datových sítí, nevystačí s jednoduchou evidencí požadavků v papírové podobě, ba ani s elektronickou evidencí ve formě dokumentů tabulkových kalkulátorů. Taková pracoviště musí být vybavena programy, které nejen evidují došlý požadavek, ale umožňují sledovat průběh řešení od začátku do konce, plánovat termíny a sledovat zdroje. Pro pracoviště tohoto typu se vžil název Help Desk. Základní filosofie všech softwarových nástrojů pro evidenci požadavků, které se někdy označují jako „Trouble Ticket“ nebo „Issue“ systémy, je velmi podobná. • Každý došlý požadavek musí být zaevidován tak, aby bylo jasné, kdo a kdy ho vznesl a bylo možné se vracet k historii jeho řešení. • Umožňují sledování průběhu řešení a komunikaci mezi uživateli a řešiteli. • Umožňují dohledání odpovědnosti za  vyřízení nebo nevyřízení požadavku. • Nabízejí statistiku a reporting činností.

Pochopitelně, že na větších pracovištích, která pokrývají rozlehlé regiony, obsluhují za den desítky a stovky klientů a komunikují s nimi telefonic-

10

Když jsme v roce 2006 vybírali pro potřebu našich interních i navenek poskytovaných služeb technické podpory vhodný „Trouble Ticket“ nástroj, hodnotili jsme produkty od těch nejvíce renomova-

ných, přes systémy psané tuzemskými výrobci až po produkty ze světa Open Source software. Volba nakonec z více důvodů padla na Open Source balík OTRS (Open Ticket Request System). Chtěl bych na tomto místě podotknout, že v době výběru jsme měli velmi jasnou představu o tom, jak chceme mít dále technickou podporu organizovánu a jaké vlastnosti od softwarového produktu očekáváme. Díky ujasnění vlastních pracovních procesů a „přívětivému“ způsobu administrace se budoucí administrátoři začali začátkem ledna s produktem OTRS seznamovat a prvého března téhož roku jsme spustili OTRS pro podporu vlastních zaměstnanců, která bez větších změn funguje dodnes. V čase implementace jsme jednoznačně upřednostňovali vlastnosti, které se týkají řízení životního cyklu požadavku a které byly u všech hodnocených softwarových balíků velmi podobné. Na první úzká místa námi vybraného řešení jsme narazili při přípravě našich služeb na certifikaci podle normy ISO 20000-1, která vychází z metodiky ITIL. Pracoviště Help Desk se začalo nazývat Service Desk a nad službami, které koncoví uživatelé využívali, jsme definovali procesy, které mají provoz těchto služeb zajišťovat. Tedy podle označení ITIL procesy Incident, Problem a Change Management. Norma vyžaduje, aby byly jak uvedené procesy, tak vlastní služby řízeny. Klíčovou otázkou je, co vše si představit pod pojmy řízení procesu a získání kontroly nad požadavky. Řídit znamená mimo jiné být schopen měřit. Nepostačuje už tedy, že se na žádný požadavek nezapomene a že se informace o jeho vyřízení dostanou do účtárny. Lidé, kteří mají řízení služeb v popisu práce, jistě velmi dobře vědí, jaké hodnoty sledovat, aby měli správný přehled. Jiná otázka je, zda software, kte-

rý používají, umí primární čísla ukládat a vypočíst z nich požadovanou statistickou hodnotu. Přestože primární data byla v databázi našeho Service Desku uložena, museli jsme se na začátku spokojit s reporty o počtu nových či vyřešených požadavků za časové období, přehledu neuzavřených požadavků a díky možnosti exportovat data do Excelu s časem potřebným k řešení podle jednotlivých řešitelů nebo zákazníků. Velmi nám chyběly metriky, které popisují kvalitu služby směrem ke koncovému uživateli, jako je maximální doba odezvy nebo vyřešení požadavku. Situace byla o to komplikovanější, že u různých služeb a různých zákazníků byly garantované hodnoty těchto metrik odlišné. Přitom uvedené metriky vypovídají o tom, do jaké míry podmínky, ke kterým jsme smlouvou zavázáni, plníme. Usuzovat na základě těchto metrik, zda máme v kapacitách rezervu či zda s dalším zákazníkem může být kvalita poskytovaných služeb ohrožena, není v podstatě možné. Pracné a nedokonalé zjišťování pomocí SQL dotazů se změnilo poté, co jsme využili příležitosti, která se nabízela ve vyzkoušení nástroje pro Business Intelligence QlikView, který naše společnost na českém trhu distribuuje. Ukázalo se, že ani „drobná“ aplikace pro podporu Service Desk není dost malá k tomu, aby nad ní nešlo implementovat „přiměřený“ managerský informační systém pro několik málo uživatelů. Přiměřenost spočívala jak v ceně licencí, tak v jednoduchosti softwarové architektury a z ní plynoucích nároků na hardwarové vybavení. Příjemným překvapením byl krátký čas, v jakém se aplikaci podařilo vyvinout, rychlost s jakou pracuje a především statistické a analytické informace, které máme díky ní k dispozici. Rychlost vyřizování požadavků dnes můžeme hodnotit podle maximální i průměrné doby odezvy nebo doby řešení. Obě metriky mohou být dále kategorizovány podle typu požadavků, jejich priority, zadavatelů i jednotlivých řešitelů. Pro služby typu technické podpory bývá charakteristické, že převážná část požadavků je sice obsloužena v nějakém typickém čase, menší část je ale vyřízena v čase, který ten typický výrazně převyšuje. Pro posouzení tohoto jevu používáme namísto průměrných hodnot statistické veličiny medián a percentil. Např. v jedné skupině požadavků je průměrná doba jejich řešení 8 dnů, nicméně • 50 % je vyřešeno už za 3 dny, • 60 % je vyřešeno do 4 dnů, • 75 % je vyřešeno v průměrných osmi dnech, • 80 % je vyřešeno za 11 dnů a • 90 % za 15 dnů, což je téměř dvojnásobek průměrné doby. Maximální doba řešení byla potom 65 dnů. Vidíme, že asi 20 % požadavků podstatným způsobem zhor-

11

šuje kvalitu služby a v samostatném okně si lze prohlédnout seznam požadavků, které do tohoto souboru patří. Detailní zkoumání historie jednotlivých případů je ovšem možné jen přímo v „Trouble Ticket“ systému. Podle podobných dimenzí lze prohlížet i pracnost potřebnou pro řešení požadavků. Ta je ještě rozšířena o pohledy dle jednotlivých řešitelů a zadavatelů. Vidíme, kolik bylo na řešení požadavků vykázáno času celkem a kolik v jednotlivých měsících, kolik hodin vykázali jednotliví pracovníci podpory a pro které zadavatele. Výstupní informace jsou prezentovány formou tabulek i přehledných sloupcových a spojnicových grafů a jiných grafických prvků.

Použití Business Intelligence nástroje výrazně rozšířilo vlastnosti běžného Trouble Ticket systému. Jeho cena za licence a implementaci byla přitom v relaci s cenou za implementaci základního Open Source balíku. Oblast reportingu a analýzy dat máme pokrytu v rozsahu, který přesahuje naše původní očekávání a změní-li se v budoucnu v tomto ohledu naše potřeby, nejsme s úpravami odkázáni na výrobce software, což si přiznejme, je v případě krabicového řešení téměř nerealizovatelná představa. Otakar Ludvík

Doba obsluhy požadavků, 80tý percentil

Přehled vykázaných hodin

11

Školíme Jak se můžete dočíst nejen na stránkách komixích novin, jedním z produktů, které společnost KOMIX s úspěchem nabízí, je software QlikView z oblasti Business Intelligence. QlikView umožňuje rychlou a kvalitní analýzu velkých objemů dat a uživatel, který absolvuje některé z našich školení, může všechny možnosti tohoto nástroje s úspěchem využívat. Školení, která KOMIX nabízí, jsou vedena certifikovanými lektory a doplňují tak naši nabídku licencí a implementačních služeb produktu QlikView.

menzí (úhlů pohledu). Posluchači se dozví, k čemu je vhodný jaký objekt, jak vytvářet objekty nové nebo kopírovat existující objekty a upravovat jejich vlastnosti. Seznámí se s možnostmi formátování a jednotného nastavení designu, dále s vytvářením komplexních reportovacích sestav, možnostmi exportu nebo s použitím záložek. V rámci školení Designer se používají již připravené datové struktury načtené do QlikView dokumentů.

Developer

Úvodem je třeba poznamenat, že běžný koncový uživatel, který používá připravené reporty v QlikView pro svoji analytickou činnost a intuitivně pomocí myši provádí filtrování dat, žádné školení nepotřebuje, postačí mu pouze krátké zaškolení. Školení je tedy určeno uživatelům, kteří mají zájem sami načítat data do QlikView a vytvářet nové reportovací objekty – tabulky či grafy. Síla QlikView spočívá kromě jiného v jeho jednoduchosti a jednoduchá je i příprava školení. V základní architektuře je QlikView provozováno lokálně na PC jednotlivých uživatelů, takže stačí během chvíle QlikView nainstalovat, ošetřit licenční záležitosti, nahrát si na PC připravené QlikView dokumenty s příklady a školení může začít.

Druhé školení nazvané Developer je zaměřeno na načítání dat z různých zdrojů do QlikView dokumentů (souborů). Jediný QlikView dokument totiž obsahuje jak definované objekty, tak reportovaná data v potřebných strukturách. Posluchači jsou seznámeni s načítáním dat z databází, textových souborů nebo Excelu, kombinací několika datových zdrojů v rámci jednoho dokumentu, tvorbou vazeb mezi tabulkami nebo jejich potlačením. Školení zahrnuje použití funkcí při skriptování, optimalizaci skriptu a různé operace nad zdrojovými daty, které zajistí optimální podobu datových struktur v QlikView dokumentu tak, aby „designéři“ mohli snadno vytvářet kvalitní reporting. Školení Developer je tedy určeno těm uživatelům, kteří budou načítat podniková data ze zdrojových databází do QlikView.

Designer

Průběh školení

Školení nazvané Designer seznámí účastníky se všemi typy reportovacích objektů v QlikView, přiblíží jim možnosti definování výrazů (metrik) a di-

Osnovu obou výše uvedených školení naleznete na webu společnosti KOMIX (http://www.komix.cz) v sekci Produkty a služby - Školení – Prostředí Qli-

Pro koho jsou školení určena

kView. Samozřejmě se náplň obou školení částečně prolíná, a protože spolu obě části úzce souvisí, je vhodné, aby alespoň někteří posluchači absolvovali obě části. Na druhou stranu, použití QlikView pro čistě koncového uživatele je velmi snadné, takže není nutné, aby se „pro jistotu“ zúčastnil vývojářského školení. Školení je prováděno nad cvičnými daty popisujícími obchodní firmu, která prostřednictvím svých prodejců vyřizuje objednávky svých zákazníků z celého světa. Občas zákazníci požadují, aby školení bylo prováděno nad jejich vlastními daty. Podle našich zkušeností je ale lepší vyzkoušet si všechny běžné problémy a jejich řešení na školících datech a příkladech, čímž posluchač získá jistý nadhled při práci s QlikView a není omezen svými specifickými požadavky či podmínkami. Pokud po absolvování školení přetrvávají nejasnosti, jak si poradit s reportingem nad vlastními daty, nabízí KOMIX další spolupráci formou konzultací nebo samostatného vývoje.

Těšíme se na Vás Doba každé části školení je 1,5 dne. Často si zákazník objedná obě části najednou a během tří dnů jsou uživatelé vyškoleni. Dostanou samozřejmě kompletní písemné materiály popisující náplň školení. Školení je možné připravit v prostorách naší společnosti nebo u zákazníka. Pokud tedy chcete využívat všechny možnosti produktu QlikView, rádi Vás uvítáme na našich školeních. Petr Matoušek

Využití BI nástroje

pro reporting a analýzy v rámci dotačního programu Zelená úsporám Případová studie pojednává o využití Business Intelligence nástroje QlikView pro potřeby Státního fondu životního prostředí v rámci administrace žádostí dotačního programu Zelená úsporám. Ve studii jsou naznačeny oblasti využití nástroje QlikView jako nadstavbového řešení k informačnímu systému IS GIS od firmy KOMIX s.r.o. a jsou zdůrazněny přínosy této aplikace pro běžnou operativu. Informační systém IS GIS dnes slouží ke komplexní administraci žádostí v programu Zelená úsporám. V průběhu jeho vývoje byly postupně definovány potřebné funkcionality pro evidenci žádostí o dotaci včetně Krycích listů technických parametrů. V programu Zelená úsporám je v IS GIS registrováno za 1 rok existence již cca 20 tisíc žádostí o dotaci. Kromě identifikačních údajů o žadateli a nemovi-

12

tosti s realizovaným opatřením jsou u každé žádosti evidovány desítky technických údajů, které jsou kontrolovány z důvodu ověření splnění podmínek programu Zelená úsporám. Původní požadavky na reportování pomocí několika předdefinovaných sestav a generovaní exportních souborů ve formátu xls pomocí cca 30 výběrových kriterií se postupně ukázaly jako nedostatečné. Předdefinované sestavy byly základem pro měsíční reporty a reporty pro ekonomický úsek SFŽP. V okamžiku, kdy nový požadavek na report obsahoval dosud nedefinovaná výběrová kriteria, nebylo možné jej rychle splnit bez úpravy aplikace IS GIS. Z výše zmíněných důvodů došlo na podzim roku 2009 ze strany SFŽP k rozhodnutí využít nabídky společnosti KOMIX vyzkoušet si práci s ná-

strojem ze skupiny Business Intelligence. SFŽP následně po úspěšném ověření nástroje v pilotním provozu zakoupil licence nástroje QlikView. Předpokládaný přínos aplikace se začal ukazovat s prvními požadavky na funkčnosti a na plno se projevil při tvorbě prvních reportů. Pro práci s daty byl nástroj QlikView zvolen jako uživatelsky definovatelný nástroj pro snadný a rychlý reporting jak v předdefinovaných sestavách, tak i pro „ad hoc“ reporty. Tvorba těchto uživatelsky definovaných reportů je pro středně pokročilého uživatele poměrně jednoduchá a nevyžaduje spolupráci dodavatele aplikace. Při tvorbě náročnějších sestav (např. definování výpočtů emisí skleníkových plynů) byly výpočty definovány analytikem společnosti KOMIX a následně prověřeny specialis-

tou úseku GIS. Tvorba výpočtového modelu trvala cca 2 dny, a tím se výrazně zkrátila potřeba času a náročnost celého zavedení automatizace složitých výpočtů. Díky možnosti definovat v prostředí QlikView pohledy na všechna data evidovaná v IS GIS se objevila další důležitá funkcionalita nástroje QlikView jako masivního nástroje pro analýzu chybovosti těchto dat. Požadavky na „ad hoc“ reporty se díky zájmu médií rapidně zvýšily. V minulosti tyto požadavky znamenaly často celodenní práci s daty. Při používání aplikace QlikView trvají tyto reporty jen několik minut. Při základním porovnání procesů, funkčnosti, nároků na zdroje (HW, SW, pracovníci a jejich kvalifi-

kace), kvality a rychlosti výstupů a jejich použitelnosti je možné deklarovat, že používáním nástroje QlikView došlo k výraznému urychlení a zkvalitnění výstupů, úspoře času a potřebných personálních

kapacit SFŽP. Vzhledem ke kladnému přijetí aplikace současnými uživateli se v budoucnu předpokládá i případné další rozšíření a využití nástroje QlikView v rámci SFŽP. Jiří Tománek

Rozhovor o informačním systému dotačního programu Zelená úsporám Dotační program Zelená úsporám administrovaný Státním fondem životního prostředí mohl úspěšně odstartovat také díky informačnímu systému GIS dodaného společností Komix. Nejen o systému GIS, ale také o dotačním programu jako takovém, jsme si povídali s odborným garantem Ing. Zdeňkem Osmanczykem, vedoucím Oddělení informační podpory SFŽP. Dobrý den pane Osmanczyku, mohl byste mi prosím na úvod říci něco blíže o informačním systému GIS? V čem jsou jeho přínosy? Jaké údaje se v IS GIS evidují? Jedná se o aplikaci, která umožňuje sledovat a vyhodnocovat celý životní cyklus žádostí o dotaci od jejího přijetí, kontroly správnosti údajů, schvalovacího procesu až po vyplacení podpory. Kromě identifikačních údajů o žadateli jsou v systému evidovány také desítky technických údajů o nemovitosti, na niž byla úsporná opatření realizována. Všechny údaje jsou pečlivě kontrolovány z důvodu ověření splnění podmínek programu Zelená úsporám. Kdy byl zahájen provoz této aplikace? Tento informační systém pro evidenci žádostí o dotace z programu Zelená úsporám vyvinula firma Komix na jaře roku 2009 jako zakázkovou aplikaci pro Státní fond životního prostředí. Dotační program byl oficiálně vyhlášen na Den Země, 22. dubna 2009, teď již bývalým ministrem životního prostředí panem Martinem Bursíkem. Program Zelená úsporám asi není třeba představovat. Zajímalo by nás ale, o co lidé v tomto dotačním programu nejvíce žádají?

last C). Z více různých opatření, která do oblasti C spadají, je nejpopulárnější instalace solárně-termických kolektorů. V této oblasti je tedy nejvíce alokovaných peněz? Přestože v oblasti C je evidován nejvyšší počet žádostí o dotace, tak největší objem podpory připadá na zateplení rodinných a bytových domů, tedy na oblast A. Zde se projevil vliv velkých projektů bytových družstev žádajících o podporu na zateplení bytových panelových domů. Tyto žádosti čerpají největší podíly v objemu dotací, jejich příjem byl však počátkem září pozastaven.

A kolik žádostí bylo dosud podáno a jaký je přibližný finanční objem dotací? Počet celkově podaných žádostí v programu překročil už 38 tisíc a tyto žádosti představují zhruba 12 miliard korun podpory. Schválených žádostí bylo ke konci července více než 23 tisíc a prostředky rezervované na dotace činily bezmála 5 miliard korun. Vyplaceno bylo již téměř 7 tisíc žádostí. Tak velký počet evidovaných žádostí představuje poměrně velké objemy dat. Jak u Vás probíhá jejich vyhodnocování? Vyhodnocování žádostí probíhá na základě pravidelných měsíčních reportů dle předefinovaných výběrových kritérií. Tyto reporty jsou pak postupovány ke schválení Radě fondu a zahraničním kupcům emisních povolenek. K detailnějšímu vyhodnocování je také aktivně využíván moderní nástroj Business Intelligence QlikView. Na jak dlouho je plánován dotační program Zelená úsporám? Máte v plánu dál rozvíjet informační systém GIS? V srpnu 2010 byla podepsána s firmou Komix nová smlouva na rozvoj a technickou podporu tohoto úspěšného projektu, která vzešla z výběrového řízení a je platná po dobu trvání programu Zelená úsporám, tj. do konce roku 2012. Rozhovor vedl Jiří Tománek

Nejvíce žádostí evidujeme na podporu investic v oblasti využití obnovitelných zdrojů energie (ob-

13

13

CASting – najděte svou STAR! Záře světel, odrazy blesků fotoaparátů, nahrávací studia a předváděcí mola vždy a spolehlivě přitahují pozornost celé řady uchazečů o získání kariéry v mediální branži. Všichni jsou přesvědčení, že oni jsou ti praví, nejhezčí a nejlepší pro získání role v právě natáčeném filmu či seriálu, pro umístění cover fotografie do časopisu nebo pro promenádu na molu. Ale zákazník je náročný, vyžaduje konkrétní kritéria. Talent musí být dostatečně zajímavý, mluvit anglicky, turecky a mít modré oči, blond vlasy, jezdit na koni, střílet z kuše a kdo ví co ještě. A jak se v tom velkém množství různých lidí vlastně mám vyznat? Jak ho mám najít? Ne, není to noční můra, je to realita. Desetitisíce fotografií a videí útočí na moje smysly. Bože, prosím zachraň mě, potřebuji systém. Volám S.O.S. Haló, Komix? Prosím, rychle, potřebuji CASting! Haló, tady KOMIX. Jasně, za chvíli jsme u vás. Co je CASting? CASting je multimediální webová aplikace určená pro evidenci, vyhledávání a filtraci talentů dle konkrétních požadavků zadavatele. CASting usnadňuje každodenní práci uživatelů pracujících s velkým množstvím talentů a k nim ukládaných informací. CASting vytváří předpoklady pro řízené sdílení informací a disponuje systémem uživatelských práv. CASting je zabezpečené řešení, které disponuje celou řadou bezpečnostních mechanismů. Z technického hlediska je CASting robustní škálovatelnou vícejazyčnou aplikací využívající moderní web 2.0 technologie. CASting je také řešením pro budoucnost, je otevřeným systémem pro další rozvoj a integraci se systémy třetích stran. Komu je CASting určen? Je jedno, jestli jste malá castingová či modelingová agentura, fotografické studio nebo velká televizní společnost, CASting respektuje všechny velikosti firem. Pokud pracujete s talenty a jejich informacemi (včetně fotografií,

CASting videí a dalších dokumentů) a potřebujete talenty vyhledávat, výsledky předávat a komunikovat s talenty i produkcí, je CASting správná volba pro vás. Jaké jsou základní výhody práce s CAStingem? • Možnost evidence talentů s  mnoha upřesňujícími údaji, • rychlé vyhledání talentu, • možnost vyhledání talentu podle všech uložených údajů, • bohatá podpora multimédií (foto, video), • integrovaný Document management system, • podpora tiskových sestav ve formátu PDF, • vysoká dostupnost a stabilita aplikace, • přístup k datům odkudkoliv, • a mnoho dalších... CASting je založen na filozofii xRM (anything relationship management). Základní entitou je talent,

k němuž je ukládána velká množina vztažených informací. Navíc jsou prostřednictvím vazeb (relations) sledovány různé i další typy sekundárních informací (dokumenty, obrázky, videa, agentury, projekty a další). Vazby umožňují sledovat komplexní pohled na aktivity spojené s talentem. Mezi výjimečné a silné stránky CAStingu patří použité uživatelské rozhraní a práce s multimédii. Uživatel pracuje s CAStingem ve webovém prohlížeči a přitom má pocit, že pracuje v prostředí operačního systému. Multimediální soubory jsou v CAStingu využívány na 100 %. Miniatury, vysoké rozlišení, plynulé přehrávání HD videí jsou samozřejmostí. Mezi výhody práce v CAStingu patří i hierarchické ukládání a vyhledávání dle dovedností, značkování jednotlivých záznamů štítky (tagy), utajení talentu, možnost tvorby vlastních filtrů a kolekcí. Zajímavou funkcí je i sledování příbuzenských a jiných vazeb mezi jednotlivými talenty. Samozřejmostí je i vysoká kvalita tiskových výstupů ve formátu PDF, umožňující okamžité sdílení výstupních sestav formou emailu. Komunikace je možná na úrovni individuální či hromadného e-mailu a dopisu. Výše zmíněné i nezmíněné možnosti a vlastnosti předurčují CASting k využití zejména v dynamických společnostech, které jsou si vědomi ceny informací a které pochopily, že i pro kvalitní práci s informacemi v oblasti show byznysu je třeba kvalitního nástroje, který šetří čas a tím i peníze. Miroslav Žebrák

14

SONEF – aneb schvalování dokumentů v praxi Tento článek je věnovaný aplikaci, která vám může pomoci zefektivnit řízení vaší společnosti v oblasti procesu schvalování dokumentů, např. smluv, nabídek či dovolenek. V následujícím textu se dozvíte nejen to, čím vám tato aplikace může být prospěšná, ale také se v jednotlivých částech článku podíváme pod pokličku technologického konceptu. Koncept schvalování dokumentů, který byl dlouhou dobu provozován ve spoustě společností, byl založen na oběhu papírů a nutnosti vyjádření se k nim standardním způsobem. Tento princip narážel na řadu omezení, kdy schvalovatelé dostávali k vyjádření dokumenty v papírové formě a byli nuceni provádět spoustu mechanických činností. Zlepšení tohoto procesu nastalo elektronizací dokumentů, kdy se již tyto dokumenty nepsaly na psacích strojích, ale vytvářely se pomocí textových procesorů a schvalovatelé se již vyjadřovali k takto elektronicky připravené podobě. Tato změna přinesla podstatné zlepšení. Pokud však společnost neměla vyřešený proces oběhu dokumentů, většinou docházelo k postupnému schvalování, kdy byl dokument takzvaně uzamčen a dále po úpravách předán do dalšího kola, což přinášelo řadu problémů. Tady jistě můžete namítat, že je tento postup postačující. Každý ze schvalovatelů si vytvoří svoji revizi dokumentu a ve stanovenou dobu se z těchto revizí vytvoří další verze dokumentu pro nové kolo vyjádření. V některých případech je tato námitka oprávněná. Pokud však proces schvalování bereme v širším konceptu s ohledem na to, jaké možnosti by nám měl poskytovat (například možnost zařazení schvalovatelů do procesu schvalování, kdykoliv se podívat na vyjádření jednotlivých schvalovatelů v jednotlivých kolech schvalování, stanovit práva uživatelů k informacím, informovat schvalovatele o nutnosti vyjádřit se a v neposlední řadě mít možnost řídit samotný proces schvalování), tak vidíme, že si s pouhými revizemi nad dokumentem nevystačíme. Pokud jste se dočetli až sem, tak jistě čekáte odpověď na otázku: „Co s tím?“ Tuto otázku jsme si položili v naší společnosti také. Jako odpověď vznikl nástroj, který řeší potřeby, které jsme v rámci schvalovacího procesu měli. Prvním krokem bylo stanovení požadavků na nástroj. Další neméně významnou částí celého řešení bylo také zvolení správného technologického konceptu. Základním požadavkem byla možnost navrhovat schvalovací formuláře přímo v uživatelském rozhraní připravované webové aplikace a dále potřeba ovládat celý proces zpracování. Pro tvorbu uživatelského rozhraní jsme zvolili technologii Microsoft s označením Silverlight. “Zasvěcený” již jistě tuší, že právě využitím této technologie jsme byli schopni uplatnit vlastnosti, které předtím nebyly ve webovém rozhraní zcela obvyklé. Jak se říká, jablko nepadá daleko od stromu, a Microsoft také v rámci řízení zpracová-

15

ní procesu vyslyšel nářky uživatelů, kde ve své technologii Microsoft .NET 3.5 dodává ucelenou část pod názvem Microsoft Workflow Foundation. Tato technologie naše očekávání v řízení procesu toku dat splňovala. Aby se funkce připravované aplikace daly využívat pomocí obecného rozhraní, jako třetí do této party byla přibrána technologie Windows Communication Foundation, která sloužila pro přípravu aplikačního serveru. Vytvořením technologických pilířů a se znalostmi požadavků na aplikaci již nic nebránilo tomu, aby aplikace jako taková vznikla. Výsledkem našeho snažení je aplikace, která umožní efektivní a pružnou elektronizaci schvalovacích procesů ve společnosti. Leckdo si řekne, že aplikace tohoto typu, které jsou šité na míru, mají omezenou schopnost přizpůsobit se. Toto tvrzení však neplatí pro naše řešení. Klíčovou vlastností této aplikace je snadné vytváření nových schvalovacích formulářů, a to od základních, jako je schválení dovolené, až po složitější, jako jsou smlouvy nebo nabídky, kde do vstupních podmínek schvalovacích procesů vstupují výpočtová pole, různé číselníky, ale také vzájemné vazby. Možnost vytváření a změny toku zpracování je další neméně významná vlastnost, kterou tato aplikace nabízí. Pokud mluvíme o toku zpracování, musíme si také říci něco o pravidlech. Pravidla mohou být jednoduchá, kdy si v některých případech vystačíme s odesláním formuláře ke schválení na svého nadřízeného, až po složitější, do kterých se promítají různé koeficienty ohodnocení rizika, dle kterých se řídí zařazení schvalovatelů do samotného procesu schvalování. Flexibilitu, s jakou lze v našem případě navrhovat formuláře pro jednotlivé druhy dokumentů, a také jejich toky zpracování, lze ocenit v případě, kdy je nutno jednotlivé procesy upravovat až na základě reálné zkušenosti s fungováním procesu jako takového.

V další části tohoto textu se podíváme blíže na jednotlivé části aplikace. Hlavní částí, se kterou se uživatel setká vždy po procesu autentizace/autorizace, je rozcestník. Jak sám název napovídá, pod tímto pojmem se skrývá přehled, na kterém uživatel nalezne například seznam typů dokumentů, jejich zařazení do kategorií dle aktuálního kontextu, ale také přehled atributů pro tyto dokumenty. Ukázkou úvodního prostředí rozcestníku může být níže uvedený obrázek, na kterém můžete vidět tři typy dokumentů a dále jejich zařazení do předdefinovaných kategorií. Jak můžete vidět, dokumenty jsou zařazovány do jednotlivých kategorií podle pravidel. V kostce k nim lze položit následující dotazy: 1. Jsem povinným schvalovatelem dokumentu? Takto definované dokumenty vidím v kategorii dokumenty k posouzení. 2. Jedná se o dokument, ke kterému se mohu nepovinně vyjádřit? Takto definované dokumenty vidím v kategorii dokumenty na vědomí. 3. Již jsem se k dokumentu vyjádřil? Takto definované dokumenty vidím v kategorii posouzené dokumenty. 4. Mám z titulu role právo zobrazit nějaké dokumenty? Takto definované dokumenty vidím v kategorii všechny dokumenty spolu s ostatními. V rámci popisu pravidel pro jednotlivé kategorie je patrné, že výše zmíněná pravidla jsou popsána dosti z nadhledu. Do pravidel, ve které kategorii se dokument objeví, vstupuje také aktuální kolo schvalování. Role, do které byl uživatel v systému zařazen, může podstatným způsobem zasáhnout do zobrazení počtu dokumentů v poslední ze specifikovaných kategorií - všechny dokumenty (viz. ad 4). Pohled schvalovatele byl již naznačen a jeho úkolem je vyjádřit se, a to buď kladně, nebo záporně. Aby však mohl schvalovatel dokument schválit, je potřeba dokument do procesu schvalování vložit. K tomuto slouží proces založení nového dokumentu, ve kterém dojde nejen k vložení schvalované-

Rozcestník

15

ho dokumentu, ale také je třeba uvést další informace potřebné pro proces schvalování (informace o ceně, rizicích, dodavateli/odběrateli, pokyny pro schvalovatele, kalkulace atd.). Proces je ukončen zvolením schvalovatelů a následným odesláním dokumentu do daného kola schvalování. Zde je třeba říci, že pro přehlednost systému vznikla ještě jedna kategorie náhledu, která nebyla zmíněna, a to spravované dokumenty. Již tušíte, že tuto kategorii vidí vlastníci dokumentu, neboli ti, kteří dokument založili. Co se stane po odeslání dokumentu do procesu schvalování? Po odeslání dokumentu ke schválení jsou schvalovatelům rozeslány in-

formační e-mailové zprávy obsahující základní atributy schvalovaného dokumentu a dále také odkaz, pomocí kterého se schvalovatel dostane k informacím ke schvalovanému dokumentu. V procesu dochází k vyjádření schvalovatelů a k pokračování toku zpracování dle stanovených pravidel. Na konci procesu, který může být vícekolový, je dokument schválen, nebo zamítnut.

ale jejich popis by byl mnohem delší, než si tento článek předsevzal.

Aplikace má také mnoho dalších funkcí (do kterých patří mimo jiné integrace s LDAP nebo Active Directory, správa číselníků, tabulek, rolí, uživatelských nastavení, návrh formulářů a podobně),

Martin Janček

Závěrem lze říci, že i když určitě existuje řada společností, které stále dávají přednost schvalování pomocí „papírování”, tak nám se v rámci společnosti tento progresivnější přístup osvědčil a můžeme ho jen doporučit.

Systém jednotného přihlášení s pomocí infrastruktury Java Open Single Sign On (JOSSO) Podstatou systémů jednotného přihlášení Single Sign On (SSO) je snaha zefektivnit a zjednodušit práci uživatelům, kteří jsou nuceni si pamatovat velké množství přihlašovacích údajů do různých systémů a aplikací. V případě použití systému SSO uživatel používá pouze jeden přihlašovací údaj. Ostatní si za něj pamatuje systém SSO, takže soulad se všemi politikami a požadavky není dotčen. Systém SSO se tak stává jednotným vstupem do všech aplikací.

JOSSO také přichází s nativní podporou širokého spektra aplikačních serverů, a to: JBoss, Tomcat, Weblogic, Websphere, Geronimo, Jetty, Apache 2.2 (PHP, Perl, Python, ...), Microsoft IIS (ASP, .NET, ...).

• Modulárnost, umožňující implementaci vlastních identity komponent; • Nativní podpora serverů Apache Http 2.x pro zpřístupnění SSO dalším technologiím jako: Ruby, PHP, Python, Perl atd.; • Integrace do aplikací standardu JEE; • Jednoduchá integrace s Java Spring Security; • Možnost využití X.509 certifikátů pro autentizaci; • Podpora LDAP a  Windows Authentification (NTLM); • Funkce „Zapamatovat přihlášení“; • Podpora pro resetování hesla; • Klientské API pro PHP nebo ASP.

Instalace JOSSO od verze 1.8 obsahuje instalační konzoly (Deployment Console), která umožňuje snadnou a velmi rychlou instalaci JOSSO komponent typu brána (Gateway) a agent (Agent).

Důvod vzniku a masivní nasazování systémů SSO ve světě je velmi jednoduchý: nároky na bezpečnost přihlašovacích údajů omezují komfort uživatelů. Názorně je to vidět na problematice hesel, kde jsou kladené různé požadavky na: minimální délku, složitost, četnost změn, kontrolu již jednou použitých hesel ve stejném systému apod. Bohužel tato vynucená složitost vede často ke snižování produktivity uživatelů. Opravdu je reálné, aby si běžný uživatel pamatoval desítky dlouhých a často měněných hesel? Nevede to naopak k obcházení bezpečnostních politik?

JOSSO Gateway JOSSO Gateway, též nazývaná Identity Provider (IdP) je odpovědná za obstarávání uživatelských identit, jejich ověřování a zpřístupnění. Samotný proces instalace brány pomocí konzole spouští následující úlohy:

S vyřešením těchto problémů nám pomáhají právě systémy SSO, jež vedou k optimalizaci a zjednodušení bezpečnostních procesů a následné zvýšení produktivity uživatelů a správců aplikací. Uživateli je umožněno pracovat s aplikacemi jako by se jednalo o jednu komplexní aplikaci bez nutnosti opětovného přihlašovaní, které už za něj obstarává samotný systém SSO. Dalšími přínosy jsou menší počet zásahů technické podpory a nemožnost obcházení bezpečnostních politik. Java Open Single Sign On (JOSSO) Java Open Single Sign On je open source produkt firmy Atricore, která ho vyvíjí od roku 2004 a také stojí za jeho komerční podporou. Mezi klíčové vlastnosti tohoto řešení patří: • Cross-domain/cross-organization SSO; • Podpora SAML;

16

Úvodní stránka testovací aplikace

o Definice unikátního identifikátoru a kontextu připojované aplikace. • Konfigurace aplikace o Konfigurace deskriptoru webové aplikace (web.xml standardu JEE). Všechny konfigurační soubory jsou ve formátu XML. Atricore Identity Bus Atricore Identity Bus je dalším rozšířením exitující nebo připravované JOSSO infrastruktury. Identity Bus poskytuje seskupení identit (Identity Federation) pro organizace, které požadují integraci vlastních nesourodých vnitropodnikových aplikací nebo aplikací napříč korporacemi. V případě potřeby využívaní a řetězení uživatelských identit od různých poskytovatelů je Identity Bus vhodným doplněním.

Standardní přihlašovací stránka, která je součástí instalace • Kontrola zvolené cílové platformy; • Generování a instalace AES klíče potřebného pro zabezpečení komunikace mezi agentem a bránou; • Nastavení standardní konfigurace; • Umístění JOSSO Gateway (josso.war) na server. Po úspěšné instalaci IdP je možno v instalačním adresáři dohledat log o detailním průběhu instalace. JOSSO Agent JOSSO Agent, jinak nazýván také Service Provider (SP), je odpovědný za zpracování všech požadavků k přihlášení a je jediným oprávněným klientem IdP. Proces instalace agenta pomocí konzole spouští následující úlohy: • • • • •

Kontrola zvolené cílové platformy Instalace knihoven třetích stran Instalace agenta Nastavení konfigurace Konfigurace zvoleného aplikačního serveru

Test instalace Pomocí JOSSO konzole je možné také nainstalovat ukázkovou aplikaci pro otestování základních funkčností systému SSO. Instalační proces v tomto případě provede pouze umístění testovací aplikace na zvolený aplikační server. Po zadání URL testovací aplikace do prohlížeče se zobrazí úvodní stránka, která uživateli sděluje, že je anonymním návštěvníkem a pro přístup k chráněným zdrojům je potřebné přihlášení. V případě zahájení přihlašování (kliknutím na tlačítko „Login“) je uživatel automaticky přesměrován na hlavní přihlašovací stránku systému jednotného přihlášení JOSSO.

17

Pro přihlášení můžeme použít předpřipravenou uživatelskou identitu a její autentizační údaje (jméno: „user1“, heslo: „user1pwd“). Po úspěšném přihlášení se již zobrazí stránka z chráněné oblasti testovací aplikace. Začlenění aplikace do systému jednotného přihlášení JOSSO Způsob začlenění je závislý na typu aplikace. Pro aplikace standardu JEE je postup následující: • Konfigurace Gateway o Způsob ověřování identit:  konfigurace vlastností připojení k relační databázi,  konfigurace vlastností připojení k LDAP,  konfigurace identit v případě uložení dat na souborovém systému. o Povolení funkce „Zapamatovat přihlášení“. o Povolení přístupu jednotlivým agentům. o Možnost úpravy vzhledu přihlašovací a odhlašovací stránky. • Konfigurace Agent

Mezi klíčové vlastnosti Atricore Identity Busu patří: • Podpora SAML; • Federace SSO může být realizována propojením různých datových zdrojů, řetězením uživatelských identit od různých poskytovatelů; • Transparentní SSO – dostupnost SSO Agentů pro mainstreamové AS jako BEA Web Logic, Websphere, JBoss, Tomcat atd.; • Procesní orientace – popis toku identity zpráv pomocí standardních BPM notací; • Design založený na  standardech - SAML, WSTrust, SPML, Java EE, OSGi; • Plugin architektura. V tuto chvíli je open source verze Identity Busu dostupná pouze v beta verzi a její nasazení do běžného provozu se nedoporučuje. Je možné zakoupit komerční verzi (možnost výběru z několika variant), nebo vyčkat do dokončení první open source verze. Další úrovně zabezpečení Jelikož systém SSO poskytuje přístup k mnoha aplikacím a systémům jenom na základě jedné uživatelské autentizace, zvyšuje se tím také riziko zneužití autentizačních údajů v případě, že jsou odcizené nebo poskytnuté třetím osobám. Proto SSO řešení vyžaduje zvýšenou pozornost na ochranu identit a autentizačních údajů. Ochranu je možno navýšit kombinací s některými dalšími známými metodami, jako jsou klientské certifikáty, čipové karty a tokeny (jednorázové heslo, SMS atd.). Závěr V porovnání s ostatními dostupnými open source řešeními systému SSO (OpenSSO, JA-SIG CAS, Shibboleth) je JOSSO velice efektivní, snadno realizovatelná a výkonná infrastruktura poskytující rozšířené možnosti přizpůsobení požadavkům konkrétní implementace. Martin Ptáček Lukáš Anderko

17

Datové schránky - první krok k Národnímu digitálnímu archivu Informační systém datových schránek (ISDS) byl uveden do provozu koncem roku 2009. Slouží především pro obousměrnou komunikaci mezi právnickými osobami (firmami vedenými v obchodním rejstříku) a orgány veřejné moci. Pro uvedené organizace a úřady je tento způsob komunikace povinný a prioritní ze zákona.

Řešení společnosti KOMIX Společnost KOMIX podporuje komunikaci s ISDS rozšířením služeb workflow systému WOIS – pomocí jeho nové komponenty ZPDS. Komponenta ZPDS je rozhraním WebServices napojena na spisovou službu zákazníka. Komunikace se spisovou službou je obousměrná, přičemž sledováno je doručení dokumentu. Dokumenty jsou do spisové služby předávány v perspektivním formátu PDF/A včetně příloh a XML obálky.

Formát PDF/A je vyvinut speciálně pro dlouhodobou archivaci – počítá se změnou IT technologií v horizontu několika desítek let. Výhodou tohoto formátu je nezávislost na prostředí operačního systému a dále aplikace pro zpracování. Typickým příkladem jsou v dokumentu použité fonty, které jsou v případě PDF/A neseny uvnitř dokumentu (v případě PDF jsou používány fonty operačního systému).

Připravte se Spisové služby, jsou-li vůbec v organizaci zavede-

ny, slouží často pouze k evidenci přijaté pošty na podatelně a odeslané pošty na výpravně, neobsluhují celé workflow písemnosti v organizaci. ISDS dává spisové službě podstatně důležitější roli v IS než doposud a nutí provozovatele spisové služby k zavedení celého workflow (především z důvodu podepisování elektronickým podpisem). ISDS si vynucuje také úpravu spisového řádu (vyřizování písemností s pomocí elektronické spisové služby) a podpisového řádu (použití certifikátů jako elektronických podpisů). Nezbytné je také řešení obousměrné konverze mezi papírovou a elektronickou podobou dokumentů. Dodavatelé spisových služeb by měli vyřešit archivaci dokumentů a doručenek z ISDS ve formátu ISDS včetně elektronických podpisů a značek – tyto podklady budou nezbytné při účasti v exekučním a insolvenčním řízení (dříve odeslané dokumenty a jejich doručenky budou používány jako přílohy).

Hlavní úkoly spisové služby v blízké budoucnosti Dodavatelé spisových služeb by měli řešit všeobecnou podporu formátu PDF/A. Tento formát bude vyžadován při předání dokumentů do Národního digitálního archivu. V dohledné době začnou vycházet prováděcí vyhlášky k implementaci rozhraní Národního digitálního archivu, s jehož zavedením se počítá v roce 2012.

Anonymizace provozních dat Jak nejsnáze umožnit prozrazení citlivých osobních údajů z vaší aplikace? Netrapte se vymýšlením vymyšleného. V praxi se již vícekrát osvědčilo použít při vývoji, testování či školení živá data. Šikovně tak obejdete provozní bezpečnostní opatření a vymezení okruhu oprávněných uživatelů dat. A stačilo málo, aby loupežník splakal nad výdělkem - zamaskovat citlivou část dat nebo alespoň zamaskovat, koho se osobní data týkají. Druhá varianta, označovaná jako anonymizace či deidentifikace, se zdá být méně pracná a ohleduplnější k osobám i k datům - fiktivní a přitom realistická data získáme vhodným pozměněním hodnot položek, podle kterých by mohly být osoby identifikovány.

letého řidiče nepřidaly k dlužné pokutě za nesprávné parkování další pokutu za řízení vozidla bez řidičského oprávnění.

Avšak ani anonymizace není úplně jednoduchá. Potřebujeme, aby transformace identifikačních položek zachovávaly vzhled a smysluplnost dat, jejich logiku a vnitřní vazby. Například pro rodné číslo to znamená zachovat jeho syntaxi, podmíněnou dělitelnost jedenácti a jedinečnost. Znamená to zachovat i vztah rodného čísla k dalším položkám, jako je pohlaví, datum narození a případné další výskyty rodného čísla jakožto vazební položky. Znamená to možná i omezit velikost transformace rodného čísla, aby nám pak třeba aplikační kontroly pro tří-

Kromě rodného čísla maskujeme i další položky. Samozřejmostí je příjmení, s nímž se sveze i jméno a titul. Maskujeme též adresy, telefonní čísla, e-mailové adresy a další kontaktní údaje, které by bylo možné zneužít k zásahu do soukromí a práv osoby i bez znalosti její identity. Bývá dobrým zvykem, aby hodnoty adresních položek, jmen a titulů patřily do příslušných číselníků, což by zde nemělo činit problém - různé varianty náhodného výběru z číselníků jsou jedním z nejčastějších maskovacích postupů. Obecně formulováno, měli bychom asi maskovat

18

Pomiňme víceméně právní problém, zda je přípustné, abychom místo původního rodného čísla dlužníka použili (samozřejmě neúmyslně) rodné číslo našeho souseda.

Milan Číha

všechny položky, které samy o sobě nebo v kombinaci s jinými a/nebo při omezeném okruhu osob nezřídka nabývají výjimečných a ověřitelných hodnot, jako např. nemovitý majetek nebo zaměstnavatel a pracovní zařazení. Prozíravý anonymizátor možná nenechá bez povšimnutí ani položky, které nabývají výjimečných hodnot pouze zřídka, a maskuje alespoň tyto jejich hodnoty. V každém případě nehledí na to, zda podle položky může osobu identifikovat pouze obzvláště nadaný subjekt, jak je tomu například u čísel kreditních karet a bankovních účtů. Samostatnou kapitolou jsou objemné položky s nestrukturovanými nebo obsahově nesešněrovanými daty, která mohou obsahovat vodítka k identifikaci osob. Nad způsobem maskování životopisů, žádostí, úředních poznámek a fotografií osob budeme asi muset chvíli rozmýšlet, abychom se vyhnuli jak zbytečné výpočetní náročnosti maskování, tak nerealistické jednotvárnosti výsledných dat, jíž bychom se snadno domohli pomocí úsporných maskovacích hodnot „blablabla“ a „do koše“ a po-

takový výřez dán několika výchozími tabulkami, relacemi referenční integrity, na jejichž základě se k výchozím záznamům přibalují záznamy související, a specifickými výběrovými podmínkami na záznamy a případně i na sloupce tabulek. Po návrhu a vývoji datových výřezů a maskování už zbývá jen anonymizaci spustit. Potřebujeme-li snadno a opakovaně dosáhnout rychlých výsledků, použijeme pro uvedené činnosti specializovaný produkt, jako je IBM Optim Test Data Management + Data Privacy Option. Daný produkt nabízí řadu zabudovaných maskovacích funkcí a číselníků a nabízí i možnost vyvinout vlastní funkce. Umožňuje vytvářet datové výřezy z nejrůznějších databází a platforem, transformovat v nich data a vkládat je zpět či do jiných databází se zachováním datových vazeb i přes hranice databází. Uživatelské rozhraní produktu a repositář návrhových metadat usnadňují prvotní návrh anonymizace, jeho modifikace a opakovatelnost použití pro podobné účely. Produkt ovšem není žádný shareware - díky bohu. Kdyby jej IBM dávala zadarmo, ještě by nás to mohlo zavléci do Řecka.

mocí náhodného výběru z číselníku komprimovaných fotografií naší oblíbené pornohvězdy. Při návrhu a provádění anonymizace dat můžeme ušetřit i svůj strojový čas, omezíme-li se jen na podmnožinu provozních dat nezbytně nutnou pro dané testování či školení. Jinými slovy, jak při anonymizaci, tak při dalším používání anonymizo-

vaných dat, bývá výhodné pracovat s konzistentním a uceleným výřezem živých dat, který by byl dostatečně reprezentativní pro daný účel a zároveň i méně objemný a náročný na zdroje než živá data. Máme-li štěstí, lze reprezentativní a přiměřeně velký datový výřez popsat jako výběr podle nějaké dimenze prostupující všemi daty (teritorium, organizační jednotka, období apod.). Nejčastěji je však

Firma IBM nabízí i další produkty pro ochranu důvěrnosti dat. Příbuzný produkt Optim Data Privacy Solution vznikl zřejmě revizí architektury, technologií a uživatelského rozhraní předchozího produktu poté, co ho IBM získala akvizicí společnosti Princeton Softech. Nový produkt je s předchozím interoperabilní – umožňuje například zadávat do něj úlohy a exportovat i importovat jejich specifikace. Návrh a vývoj anonymizace je možné provádět též pomocí univerzálních vývojových nástrojů InfoSphere Data Architect a Optim Development Studio. Další produkt Optim Data Redaction je specializován na odstraňování citlivých údajů z formulářů a dokumentů v obvyklých kancelářských formátech. Bližší informace o těchto a podobných softwarových nástrojích společnosti IBM naleznete například na stránkách http://www-01. ibm.com/software/data/optim/protect-data-privacy/ a http://www.ibm.com/developerworks/data/ library/techarticle/dm-0910optimprivatizeddata/ index.html. Jan Rada

Technologie – dobrý sluha, špatný pán RIA RIA (Rich Internet Application) je stále horké téma, technologický vývoj v této oblasti je stále bouřlivý. Na počátku byly webové aplikace s velice omezenou ergonomií použitelné spíše na prohlížení hromadných dat, nikoli na jejich aktualizaci (prostřednictvím protokolu HTTP docházelo k výměně celých stránek). Postupem času došlo ke zdokona-

19

lení webových aplikací do takové míry, že se jejich uživatelské rozhraní vzhledem i schopnostmi přiblížilo aplikacím typu „tlustý klient“. Zlepšení ergonomie umožnilo i aktualizaci hromadných dat (asynchronní výměna dat na pozadí a aktualizace části stránky pomocí techniky AJAX). RIA aplikace však nejsou výhradně technologie, které používají v roli klienta webový prohlížeč.

Nové technologie, staré zásady Technologie JavaScript, DOM (Document Object Model) a technika Ajax sice poskytují větší možnosti, ovšem za cenu zvýšených nároků na tvorbu aplikace. Ještě před érou AJAXu se pro tvorbu GUI používala technologie Java - Swing, která nebyla úspěšná, kromě jiného také kvůli složitosti tvorby GUI. Rozdíl ve složitosti tvorby náročnější webové

19

technologie, a postupným vývojem a údržbou rozsáhlých aplikací?

Osvědčené postupy I v tomto případě platí staré pravidlo: „Musíte vědět, co chcete.“ Tedy konkrétně - vytvořte evidenci požadavků na GUI. Rozhodněte se, jakou míru podobnosti s MS Windows budete požadovat. Zvažte, jak velké nároky na jednotlivé komponenty GUI budete mít. Na základě zpracování evidence požadavků se rozhodněte, kterou technologii pro tvorbu GUI využijete. Poté použijte další osvědčené pravidlo: „Co není dokumentováno, nebude nikdy dodrženo.“ Uchovejte výsledky své práce v metodice pro tvorbu GUI - popište pravidla pro vzhled a chování GUI. Proces volby technologie GUI aplikace v AJAXu a Swing GUI se postupně zmenšuje (srovnáváme-li GUI s alespoň přibližně stejnými schopnostmi). V poslední době se totiž snižuje náročnost na tvorbu GUI v technologii Swing díky novým a moderním nadstavbám nad Swingem. Swing poskytuje opravdu velké možnosti pro tvorbu GUI. Zároveň podporuje zásady, které jsou obecně platné už od vzniku OOP (Object Oriented Programming). Jednou z hlavních dobrých zásad je oddělení komponent uživatelského rozhraní od komponent aplikační logiky. Zachování této podmínky umožňuje rozdělení aplikace do vrstev a při pečlivém návrhu usnadňuje přechod na novou technologii GUI s minimálním dopadem na aplikační logiku. Tento způsob tvorby aplikací je označován jako MVC (Model – View – Controller). Swing komponenty architekturu MVC důsledně podporují. Moderní technologie RIA aplikací také podporují oddělení uživatelského rozhraní od aplikační logiky, zprvu však šlo spíše o oddělení technologické – oddělení stylu HTML stránek od generace jejich datového obsahu. O zavedení MVC do RIA aplikací se snaží například frameworky JSF (Java Server Faces) a Spring. Z pohledu začátečníka a programátora jednoduchých aplikací je přístup MVC zbytečná složitost. Pokročilý programátor rozsáhlých aplikací jej považuje za nezbytný nástroj.

Má to svá „ale“ I ta nejmodernější AJAX aplikace však nakonec vygeneruje HTML, které je zobrazováno v prohlížeči. To je sice velká výhoda, ale zároveň i velká nevýhoda celé této skupiny řešení – zobrazené HTML (případně interpretace JavaScriptu) totiž závisí na typu prohlížeče, jeho verzi a nastavení. Zajistit neome-

20

zenou přenositelnost nezávisle na uvedených parametrech prohlížeče je prakticky nemožné. Aplikace závislé na prohlížečích mají tedy trvale problémy s přenositelností. Připomínám, že Swing pracuje nezávisle na prohlížeči - má vlastní běhové prostředí JRE.

Závěr Všimněte si, že celý postup vychází z požadovaných vlastností GUI (bere v úvahu zkušenosti uživatele s GUI MS Windows) a od nich odvozuje používanou technologii. Východiskem tedy rozhodně nemusí být právě módní technologie (Flash, Java FX) v takovém případě bychom mohli mít po několika týdnech nebo dokonce měsících snažení aplikaci s nevyhovující ergonomií – prostě proto, že módní technologie nemusí vyhovovat našim potřebám.

Revoluce nebo evoluce? AJAX aplikace dávají programátorovi při tvorbě GUI velkou svobodu. Je to však vždy výhoda? Jistě nikoli – uživatel, který je zvyklý na GUI MS Windows, bude mít s revolučním přístupem ke vzhledu a chování GUI jistě problémy. Při pokusu o napodobení vzhledu a chování GUI MS Windows (integrální vlastnost komponent Swingu) však opět narazíme na schopnosti technologií AJAX. Schopnosti Swingu jsou v této oblasti omezené, schopnosti AJAX aplikací jsou ještě omezenější – mezi MS Windows GUI a GUI AJAX aplikace je tedy již citelný rozdíl.

Efektivita při tvorbě aplikací Jedním z rozhodujících kritérií při tvorbě rozsáhlých aplikací s delší dobou života je efektivita vývoje. Vysoké požadavky jsou kladeny nejen na rychlost vzniku aplikace, ale především na snadnou údržbu a rozvoj. V takovém případě se ocitnou v popředí zájmu klasické OO (Object Oriented) vlastnosti – dobře zapouzdřené komponenty s možností opakovaného použití. Takové komponenty musí být obecné, jejich vlastnosti musí být dobře řiditelné parametry. Tyto vlastnosti však něco stojí – jejich dosažení u každé nové technologie chvíli trvá. Jak tedy zmenšit rozpor mezi rychlostí, jakou vznikají nové RIA

Na počátku snahy RIA byla snaha o jednoduchost tvorby aplikací. Tato snaha trvá dodnes, ale již nyní je zřejmé, že složité GUI nelze vytvořit jednoduše. Jsou-li tedy důležité zkušenosti návrháře a programátora, je důležité omezit fluktuaci těchto pracovníků a hlavně – dobře dokumentovat úroveň dosaženého poznání. Nenechte se pasivně unášet překotným vývojem RIA technologií! Milan Číha

Vybudování democentra SAP v Komixu KOMIX má dlouholeté zkušenosti s testováním softwarových aplikací a tvorbou metodik testování pro různé zákazníky. Občas jsme se setkávali s povzdechem: „Kdybyste tak uměli testovat SAP...“ Před 2 lety přišla první konkrétní nabídka na spolupráci se zákazníkem v této oblasti. Od té doby komunikujeme se zákazníky, kteří mají SAP implementován, abychom pronikli do této samostatné a specifické kapitoly v oblasti testování a přemýšlíme, jak to zařídit, abychom byli schopni poradit, jak testování SAPu zefektivnit a optimalizovat. Když se k tomu asi před rokem přidala další konkrétní nabídka na spolupráci, tentokrát od samotného SAPu, neváhali jsme a nabídku přijali. A tak začala práce na vybudování democentra pro optimalizaci testování SAP aplikací. Na vytvoření a údržbě democentra se současně podílejí 3 společnosti: SAP, HP a KOMIX. SAP dodal licence a know-how pro SAP Backend systémy a SAP nástroje na podporu testování, HP poskytlo licence a know-how pro HP nástroje na podporu testování a KOMIX prostředí a know-how z oblasti testování a znalosti HP nástrojů, protože je již dlouhá léta autorizovaný HP Software Business Partner, a to nejen pro oblast testování.

Co je cílem democentra Pro efektivní testování je potřeba skloubit 3 základní faktory: • mít lidi zaškolené v dané problematice – v tomto případě znalé SAPu, • mít definované metodiky a postupy testování, • mít vhodné nástroje, které celý proces podpoří a zefektivní. Cílem democentra je postupně ukázat, jakým způsobem je možno dosáhnout optimalizace testování v dané oblasti. • Lidé – předpokládáme, že hlavními zodpovědnými osobami za testování SAP jsou a zůstanou klíčoví uživatelé. Jde hlavně o to jak jim testování co nejvíce usnadnit a zpřehlednit. • Metodika - vycházíme z toho, co je již k dispozici: • standardy pro testování definované SAP, • metodiky, které jsou obsaženy v nástrojích. • Nástroje - pro podporu procesu testování jsou na trhu k dispozici nástroje firmy HP, které využívá pro testování nových verzí i sám SAP, a pro další zvýšení efektivity vyvinul k nástrojům řadu akcelerátorů. Praktické a dlouholeté zkušenosti z oblasti testování s danými nástroji nám umožňují nastavit proces a metodiku testování přímo na míru dané organizaci.

21

Jaký přínos má democentrum pro zákazníky Služby democentra probíhají na dvou úrovních. Na jedné straně pořádá zapojená trojice společností pravidelné půldenní semináře, které jsou pro registrované účastníky zcela zdarma. Program zahrnující jednotlivé oblasti testování je v tuto chvíli naplánován do jara příštího roku, bude ale samozřejmě upravován a doplňován tak, aby odpovídal preferencím a potřebám zákazníků. Aktuální témata jednotlivých seminářů jsou následující: • Základy funkčního testování s  využitím SAP QC by HP; • Automatizace testování SAPu metodou BPT s využitím SAP QC by HP a SAP TAO; • Příprava dat pomocí SAP TDMS; • Organizace a řízení testů s využitím SAP SM – napojení na SAP QC by HP; • Funkční testování s využitím SAP SM; • Zátěžové testování SAPu s využitím SAP LR by HP. Druhou hlavní náplní nového democentra bude organizace akcí dle konkrétních požadavků zákazníka. Na konkrétních datech bude možno předvést řešení pro danou firmu, případně realizovat formou Proof of Concept pilotní projekt ve spolupráci se zákazníkem pro ověření vhodnosti vybrané technologie testování.

vhodné pro prezentace testování na základě zájmu zákazníků. Procesy jsou dále doplňovány s růstem zájmu zákazníků o testování SAP aplikací.

Solution Manager (SAP SM) Integrovaný SAP SM obsahuje adaptér pro HP testovací nástroje. Propojení obou nástrojů umožňuje využití Blueprintů implementovaných SAP systémů v SAP SM projektech jako zdroj dat pro testovací požadavky v projektech testování HP Quality Center. Na tyto požadavky se v systému HP QC vytvoří testy, které se z prostředí HP QC rovněž provedou, a výsledky testů se předají zpět do projektu SAP SM. Při dalších kolech testování se přidávají do projektů SAP SM další výsledky z běhů testů a aktuálně vytvářená výstupní zpráva o testování z projektu SAP SM obsahuje komplexní informace o tom, v jakém stavu se aktuálně nacházejí testy implementovaných SAP procesů.

TDMS SAP TDMS je softwarová aplikace, která umožňuje jednoduše vytvářet neproduktivní testovací prostředí s relevantním extraktem podnikových dat pro testování. Tím TDMS obecně pomáhá minimalizovat požadavky a náklady na infrastrukturu snížením objemu dat ve vývojových, testovacích a školících systémech. Dokáže provádět automatické replikace používaných dat včetně znepřístupnění citlivých dat.

Pracovní stanice a SAP Frontend Co democentrum obsahuje Democentrum je vybaveno dvěma virtualizačními servery. První server obsahuje virtuální stroje se SAP Backend systémy Enterprise Resource Planning (ERP), Solution Manager (SAP SM) a aplikaci Test Data Migration Server (TDMS). Vše je instalováno v prostředí Linux s připojením na SAP On-line Service System (OSS). Druhý server má instalovány virtuální stroje s operačními systémy Windows, obsahující HP Quality Center server (QC) a virtualizované pracovní stanice. Na pracovních stanicích je instalován SAP Frontend a testovací nástroje HP – Quality Center a QuickTest Professional a jsou přístupné vzdáleně z Internetu.

SAP Backend systémy ERP SAP ERP je systém určený pro plánování podnikových zdrojů. Jedná se o softwarový systém společnosti SAP, který je používán jako informační páteř pro vedení celého podniku. V democentru KOMIX obsahuje pouze některé speciálně vybrané procesy

Pracovní stanice obsahují následující software: SAP GUI pro Windows, SAP Tools, HP QC klient, HP QTP a SAP TAO.

SAP GUI pro Windows Tvoří prostředí SAP Frontend pro přístup k uživatelským aplikacím na SAP ERP systémech. Aplikace jsou spouštěné jako jednotlivé SAP transakce podnikových procesů. Prostředí je určeno pro práci koncových uživatelů SAP aplikací i pro práci testerů on-line s on-line transakcemi.

Vybavení Democentra SAP Virtualizační server pro SAP Backend systémy

Virtualizační server pro SAP Frontend a HP SW HP QC server

SolMan TDMS

Pracovní stanice 1*

ERP 1

Pracovní stanice 2*

ERP 2

Vzdálený přístup

*SW pracovních stanic: –  SAP GUI –  SAP Tools –  SAP TAO –  HP QC s BPT –  HP QTP pro SAP

parametrizovaných testovacími daty. Skripty lze snadno vytvářet nahráváním uživatelské činnosti v SAP aplikacích a upravit je dalším programováním. Skriptovacím jazykem je VBScript. Pro optimalizaci přípravy a údržby automatizovaných testů slouží HP technologie Business Process Testing (BPT). Technologie SAP TAO, která dokáže využívat integraci se SAP systémy, vede k dalšímu zvýšení efektivity tvorby funkčních automatizovaných testů a k urychlení procesu testování.

Kompletní možnosti integrace

Schéma integrace SAP SM a HP QC

SAP TAO HP Quality Center (HP QC) - SAP QC by HP Jedná se o softwarový produkt společnosti HP pro efektivní řízení procesu testování. Řešení v democentru SAP v KOMIXu integruje nástroje HP pro manuální a automatizované funkční testování se SAP nástroji SM a TAO tak, aby bylo možné seznamovat zákazníky s procesem testování SAP aplikací a poukázat na výhody daného řešení. Úroveň integrace může být různá a přizpůsobena konkrétním požadavkům zákazníka.

HP QuickTest Professional (HP QTP) - součást SAP QC by HP Jedná se o softwarový produkt HP pro automatizaci funkčního testování v prostředích MS Windows. V rámci produktů SAP je označen názvem SAP QC by HP. Tento softwarový nástroj dokáže automatizovat testování použitím spustitelných skriptů

TAO představuje softwarovou technologii společnosti SAP pro urychlení procesu automatizovaného testování ve vazbě na HP testovací nástroje HP Quality Center a HP QuickTest Professional. TAO integruje ERP systém s HP Quality Center a jeho síla spočívá v tom, že dokáže pro jednotlivá okna implementovaných SAP aplikací v prostředí SAP GUI automaticky vygenerovat tzv. Business Process komponenty včetně vstupních parametrů. Tyto komponenty se použijí v HP nástrojích jako elementární stavební prvky automatizovaných funkčních testů. Do TAO technologie lze integrovat i SAP SM a využívat v něm obsaženou Business Process analýzu ke zjištění dopadu změn v SAP systémech na komponenty pro testování.

HP LoadRunner (HP LR) - SAP LR by HP

ván i HP LoadRunner (v terminologii SAPu jde o produkt SAP LR by HP). Jde o softwarový nástroj určený pro provádění zátěžových a výkonnostních testů nejen SAP aplikací. Umožňuje z jednoho místa řídit zátěž stovek nebo tisíců současně pracujících virtuálních uživatelů, kteří realizují síťovou komunikaci stejně jako reálně pracující uživatelé SAP aplikací. Vhodně zvolený typ zátěžového testu a jeho správné načasování umožní včas eliminovat slabá místa systému a případné kolize výkonu systému v provozu.

Závěr Pokud vás technologie i program democentra zaujaly, neváhejte nás kontaktovat na e-mailové adrese: [email protected]. Jsme připraveni odpovědět na vaše dotazy, případně vám tuto problematiku předvést „naživo“.

V další etapě bude do prostředí democentra instaloMiloslav Richter, Alena Řezníková

KOMIX FTS KOMIX FTS (Functional Testing Suite), nástroj pro podporu a řízení manuálního funkčního testování, vznikl jako alternativa k licencovaným nástrojům, které sice poskytují bohatou funkcionalitu a vysoký uživatelský komfort, ale také s sebou přinášejí značná omezení ve formě licencování. KOMIX FTS (dále jen FTS) nepřináší tak bohaté možnosti a tak vysoký uživatelský komfort jako licencované nástroje, ale přesto svojí funkcionalitou postačuje pro evidenci a řízení procesu manuálního funkčního testování. Hlavními přednostmi KOMIX FTS je zejména jeho jednoduchost, snadná a rychlá instalace a konfigurace, výrazně nižší pořizovací cena a v neposlední řadě také licenčně neomezený počet uživatelů. FTS je webová aplikace psaná v PHP a vychází z open-source nástroje pro řízení testování distribuovaného pod licencí GPL. Tento open-source nástroj byl týmem pracovníků KOMIXu odladěn a upraven tak, aby co nejlépe podporoval proces testování od definice požadavků přes návrh a provádění testů až po bugtracking. Od původního systému se FTS značně liší, a to zejména svojí vnitřní logikou. FTS je rozčleněn do několika částí (modulů), které jsou mezi sebou vzájemně provázány. Pro samotné řízení procesu testování jsou určeny moduly Aplikace, Požadavky, Testy, Běhy testů, Hlášení a Reporty. K administraci nástroje a jednotlivých projektů potom slouží moduly Administrace a Správa uživatelů. Práce na projektu (hned po zavedení projektu do systému a po jeho jednoduché konfiguraci) začíná v modulu Aplikace, kde zavedeme aplikace, kte-

22

rých se bude testování týkat a u každé aplikace zavedeme také libovolný počet plánovaných releasů, v rámci kterých následně evidujeme testovací scénáře. V modulu Požadavky evidujeme libovolnou strukturu požadavků, které lze členit ve stromové struktuře a mohou být různého typu (funkční, technické, požadavky na testování apod.). K požadavkům jdou přikládat přílohy libovolného formátu. U požadavků lze snadným způsobem udržovat vazby na releasy a také na testy, které tyto požadavky pokrývají. Modul Testy slouží pro návrh a evidenci testovacích případů. Každý test se skládá z hlavičky, popisu testu a libovolného počtu kroků. U každého kroku testu lze evidovat akci uživatele (testera), vstupní data a očekávaný výsledek. Samozřejmostí je také možnost nahrání přílohy.

Po návrhu testovacích případů (Test cases) v modulu Testy mohou být tyto testy přiřazovány do testovacích scénářů, které jsou evidovány v modulu Aplikace a které jsou přímo navázány na release. U každého testu zařazeného do scénáře lze určit jeho pořadí v rámci tohoto scénáře. Modul Běhy testů slouží jednak ke spouštění testů zařazených do scénářů a jednak k evidenci běhů testů. U každého ze spuštěných testů je uchovávána historie jeho běhů, pochopitelně s výsledky jednotlivých běhů. Při spuštění testu je testerovi zobrazena obrazovka se seznamem kroků testu (včetně vstupních dat a očekávaných výsledků). Tester má možnost zaznamenat skutečné chování systému buď na úrovni jednotlivých kroků testu, nebo na úrovni celého testu. V případě zjištění neshody lze přímo z běhu testu vyvolat formulář pro evidenci chyby (hlášení). Pro bugtracking slouží modul Hlášení. U chyb lze kromě popisu a různých strukturovaných informací uchovávat také přílohy a vazby na test a běh testu, který vedl k odhalení chyby. Pokud je chyba zadána přímo z běhu testu, jsou tyto vazby evidovány zcela automaticky, pokud není zadána přímo z testu, lze

vazbu přidat ručně, nebo ponechat chybu bez návaznosti na konkrétní test. FTS má minimální požadavky na software a hardware. Pro provoz postačuje operační systém Windows nebo Linux, aplikační server s podporou PHP

a databáze MySQL, pro podporu e-mailových funkcí FTS je potřeba také server SMTP. KOMIX je schopen poskytnout FTS jako samostatný software, nebo spolu s dalšími službami, které souvisejí se zavedením a následným provozem nástroje, jako například instalace, konfigurace a pro-

gramové úpravy, školení uživatelů, návrh metodiky, uživatelská podpora nebo outsourcing testování. Zájemcům, kteří by se rádi seznámili s nástrojem KOMIX FTS detailněji, je možné po dohodě poskytnout přístup na předváděcí prostředí FTS po dobu jednoho týdne. Lukáš Michálek

DALŠÍ ZLEPŠOVÁNÍ integrovaného managementu KOMIXu Rok 2009 byl pro společnost KOMIX s.r.o. z hlediska získání dalších certifikací a rozšíření integrovaného managementu systému (IMS) společnosti velice úspěšný. V únoru proběhla úspěšně závěrečná certifikace managementu IT služeb a získali jsme certifikát managementu IT služeb dle normy ČSN IEC ISO 20000-1. V červenci naše společnost získala certifikát managementu bezpečnosti a ochrany zdraví při práci (BOZP) dle normy ČSN OHSAS 18001. V listopadu, v rámci Evropského týdne kvality a mezinárodní konference v Národním domě na Vinohradech v Praze, na akci „Večer s Českou kvalitou“, jsme získali ocenění v rámci Programu Česká kvalita a právo užívat značku „Certifikované služby IT“. Nakonec v prosinci 2009 společnost KOMIX s.r.o. získala také nejnovější certifikát dle normy ČSN ISO 10006 pro oblast řízení jakosti projektů a zároveň úspěšně obhájila při dozorovém auditu certifikát systému řízení jakosti podle ČSN EN ISO 9001:2009 a certifikát pro poskytování IT služeb ČSN ISO/IEC 20000-1, včetně recertifikace managementu pro oblast životního prostředí, podle normy ČSN EN ISO 14001. Pro naše zákazníky je možná nejzajímavější certifikát managementu jakosti projektu, který se přímo týká dodávek produktů a služeb, které jim naše společnost poskytuje.

23

Řízení projektů V průběhu roku 2009 tým našich pracovníků vytvořil novou metodiku pro řízení projektů, která byla postupně ověřena také na pilotních projektech. Tato metodika je výrazně podporována IS CLARITY a je navržena v souladu se standardy ČSN EN ISO 9001 a ČSN ISO 10006. Tato skutečnost umožnila získat certifikát dle normy ČSN ISO 10006, který potvrzuje, že vytvořená metodika řízení projektů a aplikace všech procesů managementu jakosti při řízení realizovaných projektů splňuje kritéria kvality mezinárodně uznávaného standardu ČSN ISO 10006, který je určen pro management jakosti projektů. Při řešení projektu je vždy veškeré úsilí zaměřeno ke splnění cíle projektu. Výstup z projektu ale musí být také konkurenceschopný a je potřebné, aby také splňoval požadavky zákazníka jak po stránce technické, provozní, estetické, bezpečnostní, ekologické nebo spolehlivosti, tak i ekonomické. Projekt musí být také dobře a efektivně řízen. Každý projekt je v naší společnosti evidován, plánován, monitorován a také řízen v IS CLARITY. To se týká nejen všech projektů určených pro naše zákazníky, ale také ostatních interních projektů režijních nebo rozvojových, pro které je zákazníkem naše společnost. Kontrola kvality na úrovni projek-

tového manažera zahrnuje sledování plnění plánu projektu, čerpání zdrojů, vykazování času stráveného na projektu a také zabezpečení jakosti produktu. Jedná se například o monitorování plnění stanovených milníků projektu, akceptačních výstupů jednotlivých etap projektu a stanovených akceptačních kritérií těchto výstupů s cílem určit, zda skutečnost odpovídá specifikaci a požadavkům zákazníka. Kontrola kvality na úrovni vedení společnosti KOMIX s.r.o. zahrnuje monitorování průběhu všech projektů nebo vybrané množiny projektů pomocí Status reportu, který obsahuje informace o stavu a průběhu projektu. Reporty určené pro jednotlivé projektové manažery nebo vedení společnosti obsahují informace o stavu a průběhu projektu a umožňují tak přijímat včasná nápravná nebo preventivní opatření v případě odchylek od stanoveného plánu projektu nebo stanovených parametrů kvality. Nedílnou součástí řízení projektu je také identifikace a řízení rizik. Vedoucí projektu v pravidelných intervalech hodnotí postup projektu a vyhodnocuje také rizika projektu, tj. kvantifikuje pravděpodobnost aktivace rizika, velikost jeho dopadu na projekt, navrhuje preventivní opatření a krizové scénáře. Zároveň má možnost eskalovat případný

Ukázka portletu monitorujícího stav projektů podle pracnosti problém na úroveň vedení společnosti. Je to způsob vyvolání zásahu z vyšší úrovně řízení, pokud vedoucí projektu vyhodnotí problém jako urgentní, nebo se daný problém již snažil řešit, ale řešení je nad jeho síly, nebo nemá dostatečnou pravomoc rozhodnout. Další součástí řízení projektu je identifikace a řízení požadavků na změny. Změnou u projektu je odchylka od projektového plánu, která má dopad na rozsah, cenu, jakost nebo harmonogram projektu. Zdrojem těchto odchylek může být okolí projektu (zejména zákazník) a také jednotlivé procesy projektu. Požadavek na změnu se může týkat zadání projektu, plánu projektu, návrhu řešení, požadavků zákazníka na produkt, nebo i jednotlivých dokumentů projektové dokumentace. Změny je možné realizovat naplánováním, např. nového úkolu nebo celé etapy (při rozsáhlejších změnách, kdy je nutné koordinovat zdroje a výstupy). Změny menšího rozsahu jsou řešeny operativním postupem, tj. zadáním konkrétních úkolů v rámci projektového týmu. Vlastní realizace změny probíhá až na základě schváleného návrhu řešení a upraveného projektového plánu nadřízeným zaměstnancem vedoucího projektu. Součástí řízení projektu v IS CLARITY je také plánování zdrojů projektu a průběžné sledování vykazování času stráveného na projektu. To umožňuje managementu provádět efektivnější rozhodování, které je vždy založené na aktuálních podkladech, které slouží k provádění a schvalování změn, včetně úprav směrného plánu a interní kalkulace projektu.

Další zlepšování integrovaného managementu V integrovaném managementu je kladen důraz na zkvalitňování a zlepšování nejen jednotlivých procesů a certifikovaných částí managementu, ale také na celý integrovaný management. Je potřebné, aby i celý integrovaný management byl funkční a efektivní. Zlepšování musí být zaměřeno především na hlavní procesy podílející se přímo na tvorbě produktu (týká se to zejména procesů v oblasti obchodu, řízení projektů a tvorby jednotlivých produktů a poskytování služeb), ale i na celek. Cílem je zavést nejen reporting jednotlivých procesů, ale integrovaný reporting, který umožňuje monitorovat a přejímat informace z různých zdrojů a procesů.

24

Budování integrovaného managementu ve společnosti KOMIX s.r.o. K tomuto účelu se v naší společnosti začala využívat technologie nástroje QlikView, který umožňuje načítat podniková data z různých zdrojů, která následně uloží v komprimované formě do operační paměti. Pomocí tohoto nástroje je velmi jednoduché dívat se na data z různých pohledů a analyzovat tak více různých hypotéz. Díky technologii komprese dat v paměti počítače postačí pro použití aplikace i běžný notebook. Všechny objekty jsou propojeny, výběr dat se provádí snadno a interaktivně výběrem jednotlivých položek. Prezentované výsledky umožňují lepší rozhodování. Nyní se integrovaný management systém společnosti KOMIX s.r.o. skládá z: • managementu kvality (QMS) - ČSN EN ISO 9001:2009, • managementu jakosti projektů (QMP) - ČSN ISO 10006:2006,

• environmentálního managementu (EMS) - ČSN EN ISO 14001:2005, • managementu bezpečnosti a ochrany zdraví při práci (BOZP) - ČSN OHSAS 18001:2006, • managementu IT služeb (ITSM) - ČSN ISO/IEC ISO 20000-1:2006. V současné době je také stále větší důraz kladen na bezpečnost informací. Na základě požadavků zákazníků, výsledků analýzy stávajícího stavu a provedeného auditu bezpečnosti informací rozhodlo vedení společnosti KOMIX s.r.o. o implementaci managementu bezpečnosti informací (ISMS) podle normy ČSN ISO/IEC 27001. Podle plánu implementace je nyní dokončena implementace tohoto nového managementu a do konce roku 2010 je naplánován vlastní certifikační audit 1. a 2. stupně, který provede společnost CQS (Sdružení pro certifikaci systémů jakosti). Jiří Feřtek

Jste závislí na internetu? Závislí na internetu jste, když:  Přijdete domů a políbíte domovskou stránku své partnerky.  Odmítáte odjet na dovolenou tam, kde není přístup k internetu a zásuvky pro nabíjení notebooku a telefonu.  V noci se vám zdají sny v HTML.  Při psaní poznámek si píšete za každou větou .cz.  Při vypínání počítače máte podobný pocit, jako byste dostávali kopačky.  Všichni vaši přátele mají ve jménu @.  V noci se každé dvě hodiny budíte a kontrolujete došlou poštu.  Taxikáři řeknete, aby jel do http://radlicka.751/113e/novy.dum/prosklene.dvere.cz.  Dívka, kterou jste naposledy sbalil, byla jenom jpeg v nízkém rozlišení.  Namísto adresy bydliště zadáváte svůj e-mail.  V lahůdkách při objednání šunky sdělíte, že nechcete, aby byla #008000.

Chytré výzkumy Pusťte děti k internetu, budou více číst Nechte děti surfovat na internetu. Podle průzkumu totiž děti, které často brouzdají na internetu, také více čtou, a to nejen články na síti, ale i v tištěných

mediích. Toto zjištění vyplývá z výzkumu KidsVerbrauch Analyse 2009. Průzkum také potvrzuje, že si tištěná média a internet vzájemně nekonkurují, ale spíše se podporují. Firmy neumějí komunikovat se zákazníky Dle celosvětového průzkumu společnosti Genesys Telecommunications Laboratories se firmám nedaří efektivně komunikovat se zákazníky. Přestože se téměř tři čtvrtiny firem poskytujících služby zákazníkům snaží se svými klienty optimálně komunikovat, úspěšných je jen zlomek. Slabinou je zejména neosobní komunikace, která nezohledňuje individuální požadavky či zájmy zákazníka a jeho důležitost pro firmu. Jen 35 procent call center spojuje VIP zákazníky s nejlépe vyškolenými operátory. CRM systémy používá 56 % velkých společností CRM využívá 56 % velkých společností v Evropě a Severní Americe, 17 % firem plánuje jeho pořízení do dvou let. Vyplývá to z nedávné studie společnosti Forrester Research. Analýza zároveň zjišťovala priority velkých společností v oblasti říze-

25

ní vztahů se zákazníky. Firmy působící na B2B trhu nejčastěji uváděly získání nových zákazníků, udržení stávajících zákazníků, zvýšení jejich loajality a prodej více produktů či služeb stávajícím zákazníkům. V případě společností, které se orientují na koncové spotřebitele (B2C), je hlavním cílem udržení stávajících zákazníků a zvýšení jejich loajality, následuje zlepšování zkušeností zákazníků s výrobkem či službou a získání nových zákazníků. Ve třetině firem s méně než 100 počítači nezodpovídají za bezpečnost dat odborníci Ve třetině menších a středních firem nezabezpečují data IT odborníci. Odborníky v oblasti IT často nahrazuje vedení společnosti, výjimkou nejsou ani pracovníci odlišných úseků či dokonce asistentky. Toto zjištění vychází od společnosti SODATSW, která provedla průzkum mezi bezmála dvěma tisíci firmami s počtem zaměstnanců v rozmezí 100 až 500. Pijte alkohol, budete žít déle Abstinenti mají menší důvod k radosti a opilcům přibyl argument k obhajobě alkoholu. Poslední studie ukázaly, že lidé, kteří se alkoholu vyhýbají, umírají dříve než opilci. Texaský tým sledoval po dobu dvaceti let 1824 osob ve věku 55 až 65 let. Mírná konzumace alkoholu, což znamená jedna až tři jednotky alkoholu denně, zdraví prospívá nejvíce. Různé studie podle časopisu Time ukazují, že alkohol v přiměřeném množství prospívá srdci, krevnímu oběhu i společenskému životu.

chvilka poezie Jedou takhle manažer, automechanik a programátor autem. Auto se náhle porouchá a zastaví. Manažer povídá: „Jen klid, vše je OK, mám tu mobilní telefon, zavoláme si taxíka a pojedeme dál.“ Mechanik povídá: „Není třeba, já jsem mechanik a mám tu nářadí. Za dvě hodinky to opravím a bude to v pořádku.“ Programátor povídá: „A nestačilo by třeba jen vystoupit a nastoupit?“

Potkali se dva čerti, smutný a veselý. Ten veselý se ptá: „Co ti je, že si takový smutný?“ „Ale, pracovní problémy. Dělám na příjmu a v posledním čase nám dělají starosti programátoři.“ „Jaké starosti?“ „Například včera: Jeden nám tam zlikvidoval polovičku oddělení motorovou pilou, než se nám podařilo vysvětlit mu, že to není další level DOOMu.“ .........................................................................................................................

Proč má programátor vedle manželky ještě milenku? Manželka si myslí, že je u milenky a milenka si myslí, že je u manželky... a on si zatím může v klidu programovat. ......................................................................................................................... Padá server, přej si něco!

TEST - Poznáte svou osobnost? Zodpovězte poctivě následující otázky a poznamenejte si počty jednotlivých odpovědí a, b, nebo c, které jsou Vám nejblíže.

b) každý den c) nikdy, jednou měsíčně ji celou vyměním

Počítač ráno zapínáte: a) při příchodu do práce b) ihned po probuzení, ještě dřív, než si dojdu na wc c) počítač je stále zapnutý, takže ho jen probudím

Svou partnerku/svého partnera si vybíráte: a) podle hardwaru b) podle softwaru c) podle toho, kolik zná klávesových zkratek

Za kolegy máte: a) samé nuly b) samé jedničky c) kombinaci nul a jedniček

Počítač vypínáte: a) při odchodu z práce b) těsně před usnutím c) proč by se měl počítač vypínat?

Dovolenou vybíráte podle: a) rychlosti a kvality internetového připojení v hotelu b) klimatu nejpříznivějšímu pro můj notebook c) když mě nějaká destinace zajímá, najdu si o ni reportáž na YouTube a nemusím nikam jezdit

Používáte papírový diář? a) Ano, respektuji tradice b) Už jsem o tom slyšel, ale přesnému využití nerozumím c) Pa… co?

Pracovní e-maily čtete: a) v pracovní době b) nečtu c) neustále

Jak často si čistíte klávesnici od zbytků jídla? a) nečistím, u počítače se zásadně nestravuji

Vyhodnocení testu: Převažuje odpověď A Počítač používáte, ale nevyužíváte všech možností, které Vám tato moderní technologie nabízí. Což je důkazem Vašeho velkého potenciálu v tomto oboru. Musíte jen změnit názor na počet nul ve Vašem okolí.

26

Převažuje odpověď B S počítačem jste dobří kamarádi a v oboru IT Vás hned tak něco nepřekvapí. Umíte šetřit přírodu, protože Váš počítač není v provozu nonstop a nekupujete si papírový diář, čímž jste ušetřili minimálně polovinu menšího stromu.

Převažuje odpověď C IT technologie jsou ve Vašem srdci pevně zakódovány a tento kód nelze na rozdíl od systému Windows nabourat. Vaši kolegové se mohou spolehnout, že pokud Vám pošlou e-mail, dostanou na ni odpověď 24 hodin denně, 7 dní v týdnu, což ale v některých situacích může být i na škodu.

Výsledek tajenky: Zkuste to vypnout a zapnout.

křížovka

sudoku

27

Děkujeme všem našim klientům za přízeň a důvěru

KOMIX s.r.o. Avenir Business Park, Radlická 751/113e, 158 00 Praha 5, Tel.: +420 257 288 211, [email protected], www.komix.cz, Redakční zpracování: kolektiv pracovníků KOMIX s.r.o. DTP a produkce: SDP V.I.P. Servis, s.r.o. © Komix s.r.o. 2010