VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE FAKULTA INFORMATIKY A STATISTIKY VYŠŠÍ ODBORNÁ ŠKOLA INFORMAČNÍCH SLUŽEB BAKALÁŘSKÁ PRÁCE

Rozměr: px
Začít zobrazení ze stránky:

Download "VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE FAKULTA INFORMATIKY A STATISTIKY VYŠŠÍ ODBORNÁ ŠKOLA INFORMAČNÍCH SLUŽEB BAKALÁŘSKÁ PRÁCE"

Transkript

1 VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE FAKULTA INFORMATIKY A STATISTIKY VYŠŠÍ ODBORNÁ ŠKOLA INFORMAČNÍCH SLUŽEB BAKALÁŘSKÁ PRÁCE NÁVRH ŘEŠENÍ PRO VYHLEDÁVÁNÍ A NÁSLEDNÉ UZAVŘENÉ TICKETŮ PRO ÚČELY OBS TÝMU SERVICE DESKU 1. ÚROVNĚ SPOLEČNOSTI CSC. ASSEL ABDIRAKHMAN 2012

2 P R O H L Á Š E N Í Prohlašuji, že jsem bakalářskou práci na téma Návrh řešení pro vyhledání a následné uzavření ticketů pro účely OBS týmu Service Desku 1. úrovně společnosti CSC vypracovala samostatně a použila pouze zdrojů, které cituji a uvádím v seznamu použité literatury. V Praze dne 21. května podpis autora

3 Poděkování: Děkuji paní PhDr. Heleně Kučerové za podporu při dokončení mého studia a konsultace při napsání této práce. Dále děkují společnosti CSC Computer Science s.r.o. za poskytnutou informací a vstřícný přístup. Zvláště děkuji mým rodičům a příteli za víru v mou schopnost všechno zvládnout.

4 Abstrakt: Tato bakalářská práce se zabývá návrhem dočasného řešení, které by pomohlo zaměstnancům Service Desku 1. úrovně společnosti CSC ve vyhledaní seznamu potřebných ticketů v systému pro registraci IT případů, jejich porovnání s seznamem čísel případů zaregistrovaných v systému spolupracující společnosti OBS a následné uzavření ticketů, které již jsou na straně OBS uzavřené. Teoretická část práce obsahuje vysvětlení problému samotného, popis formátů, které jsou generovány reportingovými nástroji obou spolupracujících společnosti a možnosti použití každého z nich pro řešení problému. Praktická část obsahuje popis prostředí v němž se problém řeší, popis vybrané funkcionality reportingových nástrojů obou systému, návrh a postup vytvoření vhodných reportů. Poslední části je návrh možných řešení pro hlavní problém a výběr nejvhodnějšího z těchto řešení. Abstract: This thesis is designed to create a temporary solution that would help employees of the 1. level Service Desk in CSC corporation to search needed tickets in the incident registration system, then compare them with case numbers registered in a system of a co-working OBS company and as a result of that comparison find and close tickets that are already closed in the OBS system. Theoretical part of this thesis consists of a detailed problem description, description of a formats that are generated by reporting tools of both of the co-working corporations and possibility of their use for the problem resolution. Practical part contains description of the environment in which is this problem solved, description of the functionality of the reporting tools used in the systems mentioned, design and process of creating appropriate reports. The last part deals with a design of a possible solutions for the main problem and selection of the best fitted of them.

5 OBSAH I.Úvod II.Popis prostředí Co je ITIL? Jaká cykly ITIL nás zajímají z hlediska této práce?...7 Service Design... 7 Service Operation Registrace Případu Stavy otevřených případů Jak najít frontu případů konkrétního týmu...26 III.Řešení problému Metoda hledání ticketů k uzavření...29 Varianta s tickety ve stavu Closed...31 Varianta s tickety v jiném stavu než Closed...31 Porovnání způsobu...31 Vytvoření reportu obsahujícího všechny tickety předané OBS Vytvoření reportu v MSS...39 Porovnání seznamu v Excel a následné uzavření ticketu v Remedy...42 IV.Závěr Zdroje

6 I. Úvod. Téma teto bakalářské práce vychází z reálné situace se kterou jsem se setkala během své práce na pozici agentů v týmu OBS SME (Subject Matter Expert) na Service Desku 1. úrovně společnosti CSC Computer Science s.r.o. Mou hlavní pracovní náplni na této pozici je poskytování informaci a porady agentům Service Desku, které jsou jediným styčným bodem mezi koncovým uživatelem a dodavatelem služeb. Poskytovaná informace se týká vymezení služeb, které společnost OBS dodává koncovému uživateli. Porada většinou agentům pomáhá určit co poruchu učinilo, a v případě, že je to problém, který by OBS vyřešila, jaké přesně informace pro stanovení příčin poruchy a jejich následné odstranění bude OBS od Service Desku potřebovat. V případě, že agent zaregistrovaný ticket pošle OBS, nejprve se ten ticket ocitne ve frontě která se nazývá OBS Focal, a o ni se stára náš tým. Agent z našeho týmu zkontroluje úplnost a přesnost údajů, které tam agent zadá, v případě, že ticket není vyhovujícím způsobem vyplněn, pošle ho zpátky agentovi s poznámkami o tom, co v nich chybí a jestli je to vůbec případ pro OBS. V případě, že je ticket vyplněn správně a nic v něm nechybí, pošleme ho přímo na OBS, a to se nazývá to bridge the ticket, což by se dalo přeložit jako přemostit případ. Použiti tohoto výrazu je opodstatněno tím, že mezi systémem, který pro registraci případů používá CSC, a systémem OBS existuje takzvaný bridge neboli můstek, který data uložena v jednom systému přenese do druhého. Někdy se ale stane to, že z nějakého důvodu ten můstek data poprvé vůbec nepřenese a ticket se ocitne ve frontě, která se nazývá OBS failed to bridge tickets. V tomto případě je jednou z našich odpovědnosti zkontrolovat ten ticket znova a zkusit ho přemostit ještě jednou, když to nepůjde i po druhé, tak se pošle ticket do naši osobní fronty a zahájí se manuální proces předání případu OBS. Někdy se může také stati, že se počáteční přemostění ticketu podaří, ale během vyšetřování případu, kdy nemáme možnost zkontrolovat to, jestli se data v ticketu obnovují nebo ne, najednou přestane můstek data přenášet a nikdo o tom neví. Může se stát, že se případ na straně OBS zavře, ale na straně CSC zůstane otevřený i po dobu několika měsíců, což způsobí porušení dohody o úrovní poskytovaných služeb (SLA Service Level Agreement). Takových ticketů může v systému být velice hodně, a jelikož náš tým má na starosti hlídaní fronty OBS, je naši povinnosti nějakým způsobem takové tickety uzavřít. Jediným doposud dostupným způsobem je otevření každého ticketu zvlášť a manuální porovnání poznámek a statusu v obou systémech, což není přijatelné, jelikož, za prve, může být ticketů ve frontě 2

7 až několik stovek, za druhé, otevření jediného případu a procházení různými záložky každého ticketů může vzít od 10 do 15 minut. Úkolem této práce je navrhnout značně automatizované řešení, které by potřebovalo minimální zásah od agentu, bylo poměrně lehké při použití a pomohlo by efektivně takové případy uzavírat. 3

8 II. Popis prostředí. CSC je velkou korporací, která na trhu B2B představuje jednu z největších společností poskytujících řešení a služby pro podporu vnitřních podnikových procesů těsně využívajících IS/ICT tohoto podniku. Pro poskytování svých služeb používá CSC standardů a nejlepších praktik, které jsou téměř totéž jako standard pro odvětví IT. Jedním z takových standardů je ITIL. CSC má certifikaci z příslušných mezinárodních certifikačních autorit jako ISEB a EXIN. Dá se říct, že jádrem byznysu CSC je management IT služeb, o čemž v podstatě celý ITIL je. 1. Co je ITIL? ITIL je zkratkou pro Information Technology Infrastructure Library, což se dá přeložit jako Knihovna Infrastruktur Informačních Technologií. ITIL je vlastně souborem nejlepších praktik pro ITSM (IT Service management řízení IT služeb). ITSM se ve své řádě zabývá spojením IT služeb s potřebami podniku, mysli na to jak efektivněji dodat IT služby pro podniky, jejichž hlavní činnosti je v podstatě práce s informací. Fyzicky sebou ITIL současně představuje řadu 5 hlavních publikaci, každá z kterých pokrývá jeden životní cyklus ITSM. Poslední verze ITIL je známá jako ITILv3 nebo ITIL edice Vytvoření ITIL bylo zahájeno vládou Velké Británie v druhé půlce 80. let minulého století. [1] Podnětem pro napsání nějakého rámce pro IT služby stal rychlý rozvoj těchto služeb a jejich všeobecné zavedení hlavně v státních orgánech. Cílem napsaní posloužilo celkové zvýšení efektivity státních IT Infrastruktur. Autoři této práce, které pracovali pro CCTA (Central Computer and Telecommunications Agency), sloučili nejlepší praktiky a zásady existující a používané v té době většinou v průmyslech. Tento soubor autoři pojmenovali jako Government Infrastructure Management Method (GITMM Metoda řízení státní infrastruktury). Později v roce 1989, když se ukázalo, že se o tu práci zajímají nejen státní podniky a organizace byl tento soubor přejmenován jako ITIL. Během 90. let zasloužila si ta knihovna celosvětovou popularitu, jelikož na ten okamžik byla nejkompletnějším souborem nejlepších praktik a standardů v řízení IT. Teď bych se chtěla pokusit krátce vysvětlit, co v podstatě ITIL v3 znamená, jelikož si myslím, že pro pochopení nejen cíle této práce ale vůbec pochopení proč se to má řešit, je velice důležité vědět o čem ITIL je. Po vysvětlení konceptů ITIL, zaměřím se na jednotlivé cykly a prvky ITIL, které se bezprostředně tykají termínu Service Desk. 4

9 Podle mě nejlepší analogie pro ITIL byla představena společnosti CompuCom ve videu, které je dostupné na youtube.com [2]. Představte si, že jste v restauraci a udělali jste objednávku. Po nějaké době Vám přinesou dezert a hned po dezertu dostanete americké brambory a vodu, ale smažený řízek, který je sice opravdu dobrý, Vám přinesou až nakonec večeři spolu s citronem, který byste chtěli přidat do vody, kterou již máte vypitou. Všechno co jste chtěli Vám sice přinesou, ale ne ve vhodnou dobu a ne jak byste toho přáli. Vůbec to není servis, který byste chtěli dostat. A většina z IT oddělení nebo podniků fungují akorát stejně, protože používají starých principů, které vedou IT podle technologií ne podle potřeb uživatelů nebo zákazníků. Dodají Vám servery, sítě, počítače jako potravinářský obchod potraviny pro restaurací. Oni spravují technické složky, kdežto byznys potřebuje informační služby, které přinesou mu hodnotu. Akorát tento problém adresuje ITIL, tak že předefinovává IT tak aby dodával Informační Služby zvyšující hodnotu podniku. Podle ITIL existuje 5 hlavních cyklu dodání těchto služeb, které můžeme přirovnat s cykly probíhající při založení a následném vedení restauraci. Založit opravdu dobrou sít' restauraci je těžké. Všechno začíná takovými klíčovými rozhodnutí jako výběr opravdu dobré kuchyně, návrh vnější a vnitřní úpravy restauraci tvořící určitou atmosféru tak ale aby ceny byli přijatelné pro adresovanou skupinu spotřebitelů. Tohle-to všechno má za cíl přitáhnout do podniků stálou klientelu a v restauračním byznysu se to nazývá Motiv restaurace (Restaurant Theming). Nejhlubší ležící ITIL cyklus, který se nazývá Strategie Služeb (Service Strategy), je totéž jako Restaurant Theming. Ten cyklus je určen pro to aby dal dohromady podnik a IT služby pro vytvoření byznys případů a určení cíli podniku, které ve své řadě definují co bude dělat IT. Po tom, co je definován Motiv restaurací, musí se navrhnout Menu, což má na starosti šéfkuchař, který musí uvést do rovnováhy suroviny, výrobu, náklady a dodavatelé tak, aby se v každém podniku podávalo to nejlepší jídlo. ITIL to nazývá Návrh Služeb (Service Design). Tento cyklus definuje Informační Služby které sledují potřebám byznys případů, při tom ale berou v úvahu úhrnné potřeby celého podniku nebo společnosti. Po tom co se nadefinuje Menu restauraci, nedají se kuchyně jen tak hned do vaření všech jídel. Před tím než to začnou dělat, provedou cvičební pokusy, připraví se a zdokumentují výsledky. Dělá se to proto, aby byli požadované pokrmy dobré a spolehlivě hotové tehdy, kdy budou na to zákazníci připravené. ITIL to nazývá Předání Služeb (Service Transition). V tomto cyklu plánuje IT spouštění služeb a změn v podniku tak aby 5

10 se dosáhlo maximálního prospěchu podniku. Číšníci v restauraci jsou samozřejmě zaměřené na dodání pokrmů, vědí totiž co každý jejich zákazník chce, a co by měla začít následujícím krokem připravovat kuchyně. Dá se říct, že v podstatě vládnou celkovou spokojeností zákazníků. V ITIL se tomu říká Provozování nebo Spravování Služeb (Service Operation). Tady takové prostředky jako Service Desk mají na starosti neboli vlastní odpovědnost dodávání Informačních Služeb zákazníkům včasně, v odpovídající kvalitě a v případě, že s dodávanými služby nastane nějaký problém, také mají na starosti ho vyřešit. A nakonec, tak jako ve všech dobrých restauracích existuje pán vrchní, který se stará o koordinací aktivit a dodržení standardů podniku, tak i v ITIL existuje 5. cyklus, který se nazývá Nepřetržitý Cyklus Zdokonalení Služeb (Continual Service Improvement Cycle). Tento cyklus existuje pro stálé měření a vylepšení přínosu, který musí IT přinášet podniku. 6

11 Cykly ITIL. Zdrojem obrázku 2. Jaká cykly ITIL nás zajímají z hlediska této práce? Jelikož situace, ke které se má navrhnout řešení, nastala na půdě Service Desku CSC a má vliv na statistická data, která ukazují jestli se dodržuje dohoda o úrovni poskytovaných služeb, bude nás především zajímat cyklus Spravování Služeb a Návrh Služeb. Jelikož podle pořadí stojí Návrh Služeb neboli Service Design před Spravováním Služeb neboli Service Operation, začneme z krátkého popisu cílů a úkolů tohoto cyklu jako prvního. Service Design. Hned po tom co jsou odsouhlaseni strategické servisy, které se mají poskytovat, mají se tyto servisy navrhnout. Má se navrhnout jejich podrobné schéma, které bude obsahovat celý balíček faktorů, které se mají brát v úvahu. Na oficiálních stránkách věnovaných ITIL, které jsou zřízené a obnovováni APM Group Ltd ve spojení s Cabinet Office, což je v podstatě součást Britské Vlády, je publikovaná úvodní přehlední studie o ITIL, která 7

12 poskytuje takovou definici pro Service Design: Návrh vhodných a inovativních IT služeb, v sobě zahrnujících jejich architekturu, procesy, politiku a dokumentaci, tak aby byli splněné současné sjednané a budoucí byznys požadavky [1]. Jaké jsou hlavní aspekty, které se mají brát do úvahy při navržení nových služeb nebo změn starých? Takových hlavních aspektů je 5 [3]: Řešení Služby (Service Solutions). Cílem pro Service Design je navrhnout nové nebo změněné služby pro zavedení do současně a skutečně existujícího prostředí. Tady slovo skutečně je velice důležité, protože pochopení potřeb, skutečně existujících v tom daném prostředí, je pro návrh naprosto nezbytné. Musíme si ujasnit, jaké jsou funkční požadavky které má zákazník nebo podnik, jakého stavu těmito požadavky chce dosáhnout. Samozřejmě že nic bez těchto požadavků nemůžeme začít navrhovat nebo stavět. Musíme také pochopit jaké tyto služby budou potřebovat zdroje a schopnosti, abychom věděli jestli na to skutečně všechno máme. Nechceme zákazníkovi slibovat něco, co v realitě nemůžeme poskytnout. Procesy (Processes). Pro řízení a hlavně podporu všech systémů a služeb, které budeme poskytovat, musíme se postarat o zavedení správných nebo, když je potřeba, pozměnění existující procesů. Uvažujme třeba existující současně na Service Desku problém s zavedením podpory bezdrátového připojení pro zákazníky. Agentům Service Desku a pracovníkům zákaznické společnosti, které jsou koncovými uživateli, bylo oznámeno, že začínaje z půlky března zahájí náš Service Desk podporu bezdrátového připojení k vnitřním korporativním sítím, což znamená, že při nějakém problému s připojením bude koncový uživatel kontaktovat nás. Ohledně zahájené podpory byli vytvořené skripta v Knowledge Management Tool dostupná pro agenty, kde bylo detailně popsáno jak se má uživatel připojit, co všechno se má nastavit, a v případě že to nebude fungovat, má se zaregistrovat incident a pošle se na OBS pro vyřešení. Jenomže když takový případ skutečně nastal, OBS řekla, že, za prve, konečnou dohodu o bezdrátovém připojení se zákazníkem nemá, protože provoz bezdrátového připojení je v testovací fázi, a, za druhé, i kdyby tento problém řešila, tak by neměla na to možnost, jelikož problém spočívá v tom, jak je nastaven profil tohoto uživatele a k tomu má přístup jenom jeden z týmů CSC spravující uživatelské účty. Kvůli tomu, že byl navržen špatný proces, řešil se tento případ velice dlouhou dobu a nakonec byl uživatel natolik poskytovaným servisem frustrovaný, že o tom napsal dopis svému vrcholovému 8

13 vedení. Tady je otázkou jestli se to opravdu mělo řešit Service Deskem, nebo měl koncový uživatel poruchu nahlásit někomu, kdo je za testový provoz odpovědný. Návrh vhodného procesu v sobě také zahrnuje určení závazků a odpovědnosti pro role, a to tak, aby při tom měli lidi, které mají tyto role plnit, určité znalosti a včasnou informaci, které jim v tom pomůže. Případ uvedený nahoře je velice dobrou ukázkou toho, že se mají procesy k poskytovaným službám být navržené a dohodnuté se všemi strany správně. Architektura Technologie (Technology Architectures). Z hlediska technologie je velice důležité, že architektura technologie nově navrhované služby je kompatibilní a vůbec zapadá do celkové architektury již existujícího systému. Jako případ tady můžeme uvést jednoho ze zákazníků CSC, ale konkrétní název společnosti uvádět nebudu, jelikož taková informace je delikátní. Servery tohoto zákazníku běží na různých verzích Micrisoftích operačních systémů Windows Server. Takhle to bylo téměř ze samotného začátku, a když byla potřeba operační systém a technologií modernizovat, zase se kupovali řešení od Microsoft. Tak se to dělalo kvůli tomu, že tyto systémy již zákazníkem a jeho dodavateli jiných služeb byli známy a tím se ještě nemuseli všechny jiné systémy přebudovávat. I když třeba řešení postavené na bázi Linux bývají velice dobré, přebudování celého systému pod nich bude zákazníkovi stát víc než použit řešení od Microsoft. Podpůrné Systémy (Supporting Systems). Před tím, než začít poskytování nových služeb, musíme se přesvědčit, že na to máme odpovídající podpůrné systémy. CSC, jakožto obrovská společnost jejíž hlavní činnosti je ITSM, již takový systém má. Tento systém ale není její vlastní výtvor, kupuje ho od společnosti BMC Software, která se speciálně zaměřuje na návrh takových systémů. Od BMC Software má CSC zakoupený celý balíček produktů, které jsou součásti skupiny produktů pod názvem Remedy, a to BMC Remedy IT Service Management Suite. Tento. Tento balíček obsahuje takové produkty jako: BMC Asset Management; BMC Change Management; BMC IT Incident Management ; BMC Problem Management; BMC Knowledge Management; 9

14 BMC Service Request Management; atd. (tady musím poznamenat, že CSC nejspíš má od BMC Software zakoupené ještě produkty dovolující sledovat analytická data, související se splněním stanovených SLA a vnitřních ukazatelů určených zlepšit celkové výsledky. S těmito produkty jsem ale jakožto agent Service Desku nepřišla do styku). Pro řešení problému stanoveného pro tuto práci budeme většinou pracovat s funkcionalitou BMC Remedy IT Service Management Incident Management. V dalších bodech práce bude také uvedeno jak se k této aplikaci nebo spíš systému přestupuje. Systémy Měření a Metriky (Measurement Systems and Metrics). Po návrhu a zavedení nových služeb se má nějakým způsobem kontrolovat, zdá jsou poskytována dle domluvených cílů nebo plánů. Na to jsou navržené systémy měření a metriky, podle kterých se měří úroveň poskytovaných služeb. Jak se takové metriky stanoví a kde jsou zdokumentované si popíšeme v dalších bodech, protože pro pochopení konkretních metrik se má také pochopit, co je Service Desk a jaké jsou jeho hlavní funkce a cíle. Tady si ještě řekneme, proč se také musí měřit úroveň poskytovaných služeb? To jestli naměřené veličiny odpovídají stanoveným cílům pomáhá nejen uspokojovat požadavky zákazníků, ale i předpovídat trendy a podle získané statistiky určovat krizové a nebezpečné body, na které se má dát zvláštní pozornost. Systémy Měření tak pomáhají včasně předpovědět a odstranit hrozící nebezpečí. Popsané aspekty dávají jenom přehled klíčových principů a cílů podle kterých se řídí cyklus Service Design, tady ale nebudu popisovat podrobněji všechny aktivity a procesy probíhající v tomto cyklu, jenom je uvedu tady jako seznam, vyjímaje jednoho bodu, který z hlediska teto práci od nás si zaslouží trošku větší pozornost: Service Catalogue Management (SCM) v podstatě katalogizace všech služeb poskytovaných zákazníkovi všemi dodavateli služeb; Service Level Management (SLM) stanovení, sjednání a dokumentace cílových bodů poskytovaných IT služeb, nedělitelnou části tohoto managementu je stanovení úrovně poskytovaných služeb Service Level Agreements (SLA); Capacity Management řízení a evidence všech zdrojů potřebných pro možnost poskytování IT služeb poptávaných zákazníky; 10

15 Availability Management řízení dostupnosti poskytovaných služeb, což je v podstatě zajištění toho, aby služby byli dodané včas, vhodným způsobem, a kdy je zákazník opravdu potřebuje, při tom se mají brát do úvahy náklady, které nese zákazník; IT Service Continuity Management (ITSCM) - zajištění toho, aby v případě nepředvídaných situaci měli jsme plán jak obnovit a zajistit poskytování služeb, především pro kritické oblasti podniku. V podstatě management rizik; Information Security Management (ISM) zajištění a řízení informační bezpečnosti tak, aby to odpovídalo korporativním pravidlům zákazníků. Tato aktivita je těsně spojená s bezpečnostní politikou prováděnou vedením podniku; Supplier Management v podstatě hlídání toho, aby dodavatele IT služeb a služby které dodávají odpovídali stanoveným cílům, nákladům, celkovým cílům podniku a vůbec pro nás byli výhodné. Service Operation. Jakmile všechny služby které se mají dodat byli navrženi v cyklu Service Design a otestována v cyklu Service Transition, přichází cyklus Service Operation, který má na starosti všechny služby konečně zákazníkovi dodat. Tento cyklus nebo stadium nám ukáže jestli v předchozích stadiích byla udělána dobrá práce. Cíle tohoto cyklu tedy můžeme definovat takto: Koordinovat a vykonávat všechny aktivity a procesy spojené s efektivním dodáním a řízením služeb na sjednané úrovní řídit infrastruktury technologií používaných pro dodání a podporu služeb; Koordinovat lidí které řídí technologie, procesy a služby. Klíčové procesy probíhající v tomto cyklu napříč všech funkcí tohoto cyklu jsou [1]: Proces řízení události (Event Management Process). Události je změna stavu, která má hodnotu nebo je důležitá pro Konfigurační Prvky (Configuration Item) nebo IT Službu. [5] Události mohou být: Informativní událost. Je důležité takové události vědět a je sledovat, nejsou ale příliš urgentní. Je to jako zelená barva ukazující, že je všechno v pořádku. Příkladem by mohla být notifikace o tom, že zálohování dat proběhlo úspěšně. Varující události. Takové události mohou mít špatný vliv, jestliže se s nimi nic 11

16 neudělá. Analogií je žlutá barva ukazující, že něco není jak by mělo být. Příkladem by mohla být též varování o ukončení zálohování dat, ale tato akce zaujala o 20% více času než obvykle. Výjimečné události. Mají okamžitý vliv, a je to červená barva ukazující, že něco je špatně. Obvykle po nastání takové události se hned registruje Incident. Příkladem může být to, že zálohování dat vůbec nebylo dokončeno kvůli poruchám v systému. Tady je důležité rozlišovat co je informativní, co je varující a co je výjimečná událost, protože v některých případech i informativní událost může mít výjimečný a okamžitý vliv. Proces Řízení Případů (Incident Management Process). Případem (Incident) je neplánované přerušení IT služby anebo snížení kvality teto služby. Selhání konfiguračního prvku, které ještě nemá vliv na poskytovanou službu je také případem. Pro lepší pochopení tohoto procesu tady představím diagram (viz Obrázek Proces Řízení Případů - Incident management process ), který ukazuje všechny aktivity v pořadí v jakém by měli správně být a pár pojmů tady také vysvětlím. Z hlediska teto práce je totiž zajímavé vědět co je Hierarchická a Funkční Eskalace Případu. Když je potřeba zahájit Funkční Eskalaci, to znamená, že agent Service Desku, který zaznamenal a kategorizoval po počáteční analýze pochopil, že nemá na vyřešení tohoto Případu prostředky a příslušné znalosti, a proto tento Případ předá řešícímu týmu 2. nebo 3. úrovně. Příkladem tady akorát může být předání Případu pro vyřešení OBS, jelikož OBS je v podstatě řešitel 2. úrovně. Hierarchickou Eskalaci je potřeba zahájit třeba tehdy, kdy se nemůže vůbec najít příslušný proces podle kterého se má postupovat dále nebo tento Případ potřebuje dohled ze strany Vedení. Základní koncepce Řízení Případů: obnovit dodání Služeb jakmile to půjde, nejlépe hned; dostat uživatele zpět do práce také nejlépe hned; řídit Případ od identifikaci do uzavření; a to všechno musí odpovídat sjednaným SLA. 12

17 Proces Řízení Případů - Incident management process 13

18 Proces Splnění Požadavků (Request Fulfillment Process). Tady požadavkem na službu je požadavek od uživatele na informaci, poradu, standardní změnu anebo na přístup k IT službě. Zajímavé je to, že ITIL Service Operation Book nedává definici cíle pro tento proces, to ale neznamená, že cíl tady není. Cílem můžeme nazvat Vyřízení všech požadavků na služby co nejefektivněji a to v rámcích stanovených pravidel a cílů pro služby [6]. Proces managementu přístupových práv (Access Management Process) nedílnou součásti procesu Splnění Požadavků, která zajišťuje to, že jenom příslušná skupina uživatelů bude mít přístup k příslušným službám podle stanovených pravidel a procesů. Proces Řízení Problémů (Problem Management Process). Problém je příčinou jednoho nebo více Případů. Příčina na moment vytvoření záznamu není obvykle známá, a Proces Řízení Problémů je zodpovědný za další vyšetření. Cílem tohoto procesu je v podstatě najít příčinu vyskytujících se Problémů, najít pro ty Problémy dobré řešení, tak aby se již více nevyskytovali anebo alespoň eliminovat důsledky, které ty Problémy přináší. Tady jde o pro-aktivní chování, které by udělalo celý systém poskytovaných IT služeb pro uživatele a zákazníky spolehlivější a stabilnější. Existují také takové aktivity, které se nedá zařadit ani do jednoho z výše popsaných procesů a takových aktivit je hodně, proto je tady nebudu popisovat všechny, jenom uvedu pár příkladů: monitorování a kontrola, řízení infrastruktur a jiné. Existuje 4 klíčových funkcí které se zařazují do cyklu Service Operation, jsou to: Funkce Service Desku. Service Desk je jediným "styčným bodem" (Single Point of Contact) mezi dodavatelem a koncovými uživateli těchto služeb; Funkce Technického managementu - Technical Management Function; Funkce Managementu Aplikací - Application Management Function; Funkce managementu IT Provozu - IT Operations Management Function. Nejvíce z těchto funkcí nás samozřejmě zajímá funkce Service Desku a pro ní jsem věnovala další část teto práci. 14

19 3. Registrace Případu. Celý proces začíná registraci Případu neboli, jak je obvykle nazývají agenti Service Desku, ticketu v systému. Za prvé, musí se agent přihlásit do systému, který se běžně mezi agenty nazývá Remedy. Na to aby se přihlásil použije agent své údaje, které se nazývají Global Pass credentials. Tyto přihlašovací údaje jsou propojené s dalšími systémy, které agent používá během práce, proto jsou Globální. Remedy je dostupné jenom přes připojení VPN a při tom, musí se používat zařízení, které je přidáno k potřebné doméně, a vůbec je mu připojení povoleno. Jiná možnost připojení je přímo v kanceláři CSC a to přes kabel, protože CSC WiFi připojení neschvaluje, jelikož podle CSC není bezpečné. Odkaz, který používají pracovníci Service Desku je https://emealeveragedremedy.emea.csc.com Na Obrázku č.1 vidíte přihlašovací bránu pro Remedy. Obrázek 1: Přihlašovací brána Po tom, co je agent přihlášen do Remedy, uvidí regulérní agenti stránku, na které jich zajímají jenom 2 odkazy, a to na Knowledge Management Console a Incident Management Console. Tady se dá říct, že obyčejné agenti máji přístup jenom k těmto odkazům, jiné možnosti se jim prostě neotevřou, a to je opodstatněno tím, že ke své práci je ani nepotřebuji. Jelikož nás v tuto chvíli zajímá jenom registrace případu, přešla jsem 15

20 přímo ke stránce Incident Management, část které vidíte na Obrázku č. 2 Obrázek 2: stránka Incident Management Po otevření ovládacího panelu Incident Management pro registraci nového případu, musí agent otevřít stránku New Incident. Po kliknutí na New Incident se objeví nové okénko, ve kterém se máji vyplnit jméno a příjmení koncového uživatele, který případ nahlásil. Po vyplnění těchto údajů se klikne na Search (viz Obrázek č.3) 16

21 Obrázek 3: Hledaní uživatele V případě, že existuje jediný uživatel s takovým jménem, detaily profilu tohoto uživatele se vyplní automaticky, v opačném případě objeví se okénko, které vidíte na Obrázku č. 4. A tam bude muset agent vybrat správného uživatelé podle dalších detailu, které mu v tom pomohou. Například, telefonní číslo nebo druhé jméno uživatelé. 17

22 Obrázek 4: Vyběr správného uživatele Po té, co byl vybrán správný profil uživatele, vyplní se jeho údaje, a agent může postupovat dál kontrolou těchto údajů. Spolu s detaily uživatele se objeví i číslo případu, které systém automatický tomuto případu přidělí. Toto číslo se nazývá Incident Number/ID nebo ticket number, a začíná se jako EU-INC... (viz Obrázek č.5). V případě, že údaje uživatele jsou zastaralé a nejsou aktuální, bude muset je agent pozměnit a svou změnu uložit. To, jestli jsou tyto údaje aktuální nebo nejsou, je velice důležité zejména v incidentech týkajících se OBS z toho důvodu, že když se bude muset do místa, kde je něco přímo fyzický rozbité nebo nefunkční, poslat technik, bude muset OBS přesně vědět kam se technik posílá a musí se tomu technikovi poskytnout mapy ukazující sítovou topologií budov, kde se koncový uživatel nachází. Znalost takové topologie totiž práci a odstranění poruch usnadňuje a urychluje. Toto je první důvod, proč tyto údaje aktualizovat. Druhý ale neméně důležitý důvod je v tom, že pro účely kontroly a reportingu chce CSC uchovávat i ty adresy, které již nejsou aktuální třeba proto, že zákazník tam již žádnou kancelář nemá. Na druhou stranu OBS pokaždé svou bázi aktualizuje a má tam zaregistrované jenom současné lokace. Ke každé lokaci v systému OBS je přiděleno svoje ID a po předání případu OBS, se tento případ uloží do jejich 18

23 databáze tak, aby se dalo jeho spojit s nějakou existující lokaci, což v případě neaktuální lokace nebude možné a ticket se vůbec nepodaří přemostit. Takže když nejsou některé z údajů uživatele aktuální, stiskne agent tlačítko Modify. Obrázek 5: Vygenerované Incident ID Na stránce Modify se obvykle objeví všechna kontaktní údaje uživatelé. Při vytváření nového profilu uživatele nám Remedy prostě nedovolí ho uložit, jestliže nějaká základní informace jako například telefonní číslo nebo ová adresa tam chybí (viz Obrázek č.6). 19

24 Obrázek 6: Stránka Modify Po tom, co jsou data zkontrolována a je vybrán správný uživatel, musí agent vyplnit další nezbytné informace, jako popis problému, kategorizace případu ad. Jestliže problém, který má uživatel, leží v nějaké kategorie, například problém s IP telefonii, což určitě má na starosti OBS, muže agent vybrat z nabídky Templatu vhodný pro vyplnění. 20

25 Obrázek 7: Tlačítko Select Template Jakmile stiskne agent Select Template tlačítko, objeví se mu okénko s různými šablony. A pro OBS případy jednou z nejčastěji používaných šablon může být OBS Avaya Telephony Template. Pro náhled si tuto šablonu vybereme a podíváme se, co všechno tato šablona potřebuje po agentovi vyplnit a co vyplní sama. 21

26 Obrázek 8: Výběr šablony Po výběru šablony se automaticky nám předvyplní téměř všechno v horní části stránky (viz Obrázek 9). Obrázek 9: Předvyplněná pole Poličko Summary by mělo byt potom agentem pozměněno tak, aby obsahovalo specifičtější krátký popis problému. Dále Status ticketu je vždy při generovaní případu a vyplněni šablony bude ve status Assigned, což se během vyřešení případu mění. O tom, jaké mohou byt statusy ticketu si řekneme později. Polička Technical Severity, Impact, Urgency, Business Criticality a Priority nás v tuto chvíli až tak nezajímají a to, jak se 22

27 určuji, muže být předmětem dlouhé diskuze. Notes bude obsahovat šablonu, kterou musí agent povinně vyplnit. Pro otevření okénka Notes, stiskne se čtvereček vedle tohoto polička. Na Obrázku 10 je vidět jak vypadají Notes. Obrázek 10: Notes - poznámky Po vyplnění potřebných údajů se stiskne Ok a přejde se do dalších lišt, které se mají vyplnit nebo zkontrolovat. Ze všech lišt, které se máji zkontrolovat nebo vyplnit, nás zajímají jenom ty, co jsou ukázané na obrázcích číslo 11 a 12. Obrázek č.11 nám ukazuje lištu, která se nazývá Work Info. Tato lišta obsahuje veškerou informaci o to, co se během vyřešení případu vůbec dělalo. Kdy byl koncový uživatel kontaktován, jaké informace se od něho ten, kdo ho kontaktoval, dozvěděl, jaký řešící tým kdy tento případ pro vyšetření převzal, proč ho převzal, co se po vyšetření dozvěděl a proč ho předal dál anebo jak ho vyřešil tohle-to všechno musí Work Info obsahovat. Obdobný systém má i OBS, proto po tom, co se případ předá nebo přemostí se do OBS, začíná se každá změna, přidaný komentář nebo poznámka automatický odrážet v Remedy, což je pro sledování průběhu vyřešení případu nezbytné. Kromě toho, že se odrážejí v Remedy poznámky, také se mění stav ticketu v závislosti na tom, jaký stav mu přidělí v systému OBS. Problém, který se tady řeší je akorát v tom, že se někdy kvůli nějakým změnám na straně OBS, může se ticket přestat obnovovat. Přestane se 23

28 přenášet Work Info a přestane se obnovovat stav ticketu, což není dobře protože ticketů, které jsou přidělené OBS je veliké množství a sledování každého případu zvlášť není možné, jelikož to zabírá hodně času a tím i peněz. Jak už bylo řečeno na začátku, otevření ticketu v obou systémech a jejich následné porovnání může někdy vzít až kolem minut. Obrázek 11: Lišta Work Info Obrázek 12: Lišta Assignment Obrázek č.12 nám ukazuje lištu, kde se můžeme dozvědět, kdo se současně vyřešením anebo zkoumáním případu zabývá. V případě, že se po zaregistrování případ pošle na OBS, musí se nejprve předat týmu Service Desk Prague OBS Focal, který 24

29 zkontroluje zdá se případ týká OBS a jestli všechny potřebné informace jsou uvedené v ticketu. Stává se totiž tak, že agent, který přijal hovor, zaregistruje ticket a pošle nám ho s naprosto nepochopitelným popisem problému nebo tam neukáže jak vůbec zkoušel uživateli pomoct, anebo tam nedoplní nezbytné pro vyřešení případu informace. Po zkontrolování se ticket bud pošle dál přímo na OBS nebo se vrátí zpátky pro doplnění potřebných údajů. Dělá se to tak proto, že po tom, co se ticket pošlé přímo na OBS, vytvoří se v jejich systému jedinečné číslo tohoto ticketu a vytvoří se takzvaný můstek, který, jak už bylo řečeno dřív, automatický předává zprávy ze systému OBS do Remedy. Ze strany Service Desku CSC se může ten ticket aktualizovat novými detaily, ale nesmí se při tom měnit tým, ke kterému je tento ticket přidělen, jelikož to ten můstek hned zruší a někdo potom bude muset ten ticket převzat do vlastní fronty a sloužit tak pro něho živým můstkem tak, že ho bude každé 2 hodiny otevírat v obou systémech a změny v jednom systému přenášet do jiného. Tady vstává otázka: Proč se nesmí ten ticket prostě znovu přemostit do systému OBS? Odpověď je jednoduchá. Jelikož se ticket znovu přemostí do OBS, vytvoří se v jejich systému nový případ, což jednak způsobí redundanci dat a zbourá to statistické výsledky, a jednak po každém takovém vytvoření případu bude muset zákazník anebo odběratel služeb zaplatit zvlášť za každý případ i když se faktický týká jenom jednoho koncového uživatele. Takové příhody zákazník rád nemá a proto se mají kontrolovat. Proto byl vytvořen tým OBS Focal, který se snaží to hlídat a pokud je to možné posílat přímo na OBS takové tickety, které mají veškeré potřebné a nepotřebné informace tak, aby se nevraceli zpátky a nemuselo se žádat od agentu po jejich doplnění. Je to tím, že agenty Service Desku pro získání dalších informací většinou mají kontaktovat koncového uživatele, což může zabrat hodně času a při pracovní zátěži, kterou mají na Service Desku, není snadné ten čas najít a vůbec na to nezapomenout, což zase přidává práci týmu OBS Focal, protože členové týmu agentům mají pokaždé připomínat, že mají potřebné informace získat co nejrychleji. 4. Stavy otevřených případů. Po tom, co se vytvoří nový případ a přiřadí se konkretnímu týmu, co má ho vyřešit anebo poslat ho dal, musí se uložit a po tom, co se uloží, objeví se tento případ neboli ticket v určité frontě případů. Pro uložení vyplněného případu musí agent jednoduše stisknout tlačítko Save. Hned po uložení ticketu přidá se mu status Assigned, což v podstatě znamená, že je ticket přidělen konkrétnímu týmu nebo jednotlivci v týmu, a musí se na něm hned začít pracovat. Pro lepší pochopení je níže popsáno co znamenají 25

30 jednotlivé stavy neboli Status ticketů. New : Při vytvoření nového případu bude jeho status automatický ve stavu New dokud nebudou všechna povinná polička doplněna potřebnou informací a nebude případ uložen. Po uložení případu se změní jeho stav na Assigned. Assigned : Případ byl přidělen konkrétnímu týmu nebo jednotlivci pro vyřešení, ale nebylo ještě potvrzeno jeho přijetí. In Progress : Přijetí případu bylo potvrzeno a odpovědný tým začal na jeho vyřešení pracovat. Ve skutečnosti to funguje tak, že po tom, co se případ přidělí týmu počítá se za přijatý a SLA hodinky začínají cvakat. Pending : Práce nad případem byla dočasně pozastavená kvůli nějakému důvodu, kterým často bývá zdržení ze strany koncového uživatelé. Takové opodstatněné pozastavení práce také pozastavuje hodinky počítající SLA. Resolved : Služba byla znovu vrácená a to bud s řešením permanentním nebo takovým, které funguje trošku jinak ale přivede ke stejným výsledkům (workaround). Tady je potřeba aby řešení problému bylo potvrzeno ze strany zákazníka. Closed : Zákazník nebo koncový uživatel potvrdil řešení problému a od doby co byl případ převeden do stavu Resolved uteklo 5 dni. Po 5 dnech bude případ automatický systémem převeden do stavu Closed. Zákazník nebo koncový uživatel totiž má 5 dni na to aby se znovu ozval Servis Desku a oznámil, že se problém vrátil anebo poskytnuté řešení mu nefunguje. 5. Jak najít frontu případů konkrétního týmu. Pro účely teto práce Vám ukážu jak se hledá fronta pro konkretní Resolver Group, v tomto případe to bude Service Desk-Prague OBS Focal. Prvním krokem bude otevřeni okénka Search Incident z Incident management Console, které vypadá stejně jako okénko New Incident až na to, ze poličko Incident Number není vyplněno, a muže se tam zadat a najít konkretní číslo incidentu. Na to abychom mohli najít celou frontu ticketu potřebujeme přejít v Advanced search režim. Jakmile to uděláme, objeví se nám v dolní častí stránky Search Line na které můžeme nadefinovat dotaz (String), který nám najde co potřebujeme. Dá se říct, ze dotazovací jazyk v tomto případě docela podobny části SQL dotazu, až na to ze tady uživatel nemusí vědět strukturu tabulek a vůbec databáze. Tady se všechno může primo naklikat. Konečný 26

31 řetězec, který se používá pro hledaní ticketu v naši frontě vypadá takto: 'Support Company*' = "CSC" AND 'Support Organization*' = "Service Desk" AND 'Assigned Group*+' = "Service Desk-Prague OBS Focal" AND 'Status*' < "Resolved" Udělá se tento dotaz tak, ze se najde na stránce anebo na konkretní liště stránky nadpis Support Company a jednoduše se na něho klikne, což způsobí objeveni tohoto atributu v Search line ve správném formátu. Jestliže potřebné kriterium nemůžete najít, dá se použit rozbalovací lišty Fields, která nabídne všechny atributy, které se mají nadefinovat. Dále uvedeme, ze by Support Company melo rovnat CSC a tak pokračujeme dal, než vymezíme všechny kriteria hledaní. Kus řetezce 'Status*' < "Resolved" znamená, ze se najdou všechny tickety ve statusu Assigned, In Progress a Pending. Dá se říct, ze na to abychom našli všechny tickety v potřebné frontě, může postačit hledací řetězec nadefinovaný takto: 'Assigned Group*+' = "Service Desk-Prague OBS Focal" AND 'Status*' < "Resolved" bez kusu 'Support Company*' = "CSC" AND 'Support Organization*' = "Service Desk" tohle-to ale čas hledaní prodlužuje tak, že během něho může Internet Explorer zkrachovat. Po tom, co jsme dotaz nadefinovali, v levém horním rohu stiskneme tlačítko Search. Obrázek 13: Hledaní fronty týmu 27

32 Tady vidíte jak vypadá fronta pro Service Desk-Prague OBS Focal, o kterou se stará můj tým. Obrázek 14: Fronta OBS Focal Pro bezpečnostní účely data, která patři uživatelům budou zamalována barvou. Tickety, které jsou v statusu Assigned musí být ověřené a bud se pošlou dal anebo se vrátí zpátky agentovi. Tickety, které jsou ve stavu Pending, většinou jsou akorát ty, které ze samého začátku nemohli z nějakého důvodu být k OBS přemostěné a teď stojí v osobní frontě členů týmu a musejí se obnovovat ručně. 28

33 III. Řešení problému. Cílem této práce je navrhnout řešení, které pomůže pracovníkům týmu OBS Focal rychle a jednoduše najít tickety, které již jsou uzavřené na straně OBS a hromadným způsobem je uzavřít na straně Service Desku v Remedy. Nejlepším řešením pro tento problém by bylo odstranění původu problému, a to odladění samotného můstku mezi dvěma systémy. Toto by ale potřebovalo vědět jak oba tyto systémy fungují, jak jsou naprogramované a vůbec celou jejich strukturu. V daném případě jak už bylo řečeno dřív, systém který používá CSC patří třetí straně, a to společnosti BMC Software Inc., která tento systém vyvinula. Dá se říct, že komplexita obou systému není jednoduchá a zkoumání jejich architektury zaujme nejen hodně času ale také k tomu potřeba sehnat povolení a přístup. Jaké jádro pro svůj systém používá OBS nebylo docela jasné, jelikož jak se zdálo ze slov pracovníků Help Desku OBS, se kterými jsem měla možnost provést kratký rozhovor, používají systém, který se nazývá Clarify, a ten také OBS nepatří. Na druhou stranu, my jakožto třetí strana máme přístup k jejich systému přes webové rozhrání, které se nazývá My Service Space a tady je odkaz pro veřejnost: servicespace.orange-business.com/mssloginform/public/welcome-action.do Jak jsem pochopila z dopisování s týmem podporujícím MSS (zkrátka od My Service Space) tento produkt, byl vyroben speciálně pro OBS a současně se postupně přechází od starého systému k novému, a tým MSS přebírá starost o systém od vývojářů Clarify. Po rozhovoru s pracovníky CSC, které tady pracovali ještě před tím než společnost OBS přešla k novému systému, ticketů které selhali bylo mnohém víc než teď, což poukazuje na to, že nový systém je v nějakém smyslu lepší než starý. Po tom, co jsem se dozvěděla o těchto detailech, ukázalo se že vedení Help Desku OBS o problému s můstkem ví, a současně ze strany vývojářů začala práce nad jeho odstraněním. Avšak se neví kdy bude tento problém plně odstraněn, a tak se má navrhnout dočasné řešení s použitím funkcionality a prostředků obou systémů dostupných pro obyčejné pracovníky Service Desku CSC. Metoda hledání ticketů k uzavření. Před tím než navrhnout technickou stránku řešení je potřeba určit metodu podle které se budou tickety hledat. V MSS existuje možnost najít všechny tickety, které jsou již ve stavu Closed, ale 29

34 jenom když zadáme nějaký časový interval ve kterém se mají takové tickety hledat. Z tohoto reportu by se dalo vyčlenit jediný bod spojení ticketů v systémech OBS a CSC, a to Vendor Ticket Number číslo ticketu dodavatelé. Vendor Ticket Number na straně OBS obvykle představuje sedmimístné číslo, kdežto na straně CSC toto číslo bude ve formátu A::EQUANT::XXXXXXX, kde XXXXXXX představuje číslo ticketu ze strany OBS. V Remedy je toto číslo zapsáno v takovém formátu kvůli tomu, že OBS není jediným dodavatelem služeb zákazníku, existuji ještě takové dodavatelé jako Getronics. A::EQUANT:: je svérázné automatické označení ticketů předaných OBS. Nicméně po přidání označení A::EQUANT:: před každým číslem ticketu získaného z reportu z systému MSS, dalo by se vytvořit hledací string, který by vypadal přibližně tak: 'Support Company*' = "Orange Business Services" AND 'Support Organization*' = "Vendor" AND 'Assigned Group*+' = "EUR-OBS Voice and Data" AND 'Vendor Ticket Number'="A::EQUANT::XXXXXXX" OR 'Vendor Ticket Number'="A::EQUANT::YYYYYYY" OR... atd dokud nebudou vyjmenované všechny tickety, které se mají najít. Jenomže jednak, jak se ukázalo při experimentálním pokusu, v Remedy pomoci takto definovaného stringu hledat se nedá, Remedy totiž ukazuje varování o tom, že Vendor Ticket Number není nadefinované jako pole podle kterého se může hledat. Jednak, i když by se dalo pomoci tohoto řetězce tyto tickety najít, značná část těchto ticketů nehledě na problém s můstkem už budou uzavřené, a opakovaně je uzavřít Remedy také nedá. Takto nakonec vychází, že jediný kriterium, podle kterého se dá hromadně najít tickety k uzavření, je Incident ID přidělené ticketům systémem CSC a musejí se hned najít tickety které jsou problémem bezprostředně postižené. Reportingový systém Remedy umožňuje najít všechny tickety předané v systému formálně vytvořenému týmu s názvem EUR-OBS Voice and Data. Samotné uložení ticketu ve frontě tohoto týmu, jak už bylo řečeno dřív, spouští vytvoření můstku mezi MSS a Remedy pro tento ticket. Takto získaný seznam ticketů, bude obsahovat tickety na kterých se současně pracuje a tickety, které již jsou faktický vyřešené. Jelikož se v MSS dá vytvořit report obsahující data tykající se jak ticketů ve stavu Closed, tak i ticketů ve stavech znamenajících, že se na nich současně pracuje, vstává tady otázka jak reporty z obou systému lépe porovnávat a jaký report lépe v MSS vytvořit. Pokusím se tady obě varianty probrat a vybrat z nich nejlepší. Předběžně řeknu, že nezávisle na tom jaká bude na konci vybrána varianta, bude report z MSS obsahovat, mimo jiných poli, taková pole jako Incident ID (pro větší jasnost toto pole označím jako OBS Incident ID ) a Customer Reference (toto je vlastně Incident ID, které přidělilo tomuto ticketu Remedy). Report 30

35 vytvořený v Remedy bude určitě obsahovat pole Incident ID (CSC Incident ID) a Vendor Ticket Number (OBS Incident ID ve formátu A::EQUANT::XXXXXXX ). Varianta s tickety ve stavu Closed. Předpokládejme, že vytvořili jsme report obsahující všechny tickety ve stavu Closed ze systému MSS. Máme také vytvořený report v Remedy obsahující seznam ticketů současně předaných EUR-OBS Voice and Data. Co bude výsledkem porovnání těchto ticketů? V ideálním stavu by ani jedna položka těchto seznamu neměla být ve shodě, protože by uzavřené tickety OBS v seznamu otevřených ticketů CSC neměli vyskytovat. Jelikož současný stav ideální není, ty shody přece najdeme a Incident ID těchto shodných ticketů se musí poznamenat a vytvoří se z nich potom hledací řetězec pro hromadné uzavření ticketů. Varianta s tickety v jiném stavu než Closed. Teď předpokládejme, že máme report obsahující všechny tickety z určitého časového intervalu ve stavu jiném než Closed a report z Remedy. Tady by v ideálním stavu všechny tickety měli být v plné shodě beze zbytku. Jelikož tento stav ideální není, zůstanou v seznamu vytvořeném v Remedy tickety, které nebudou mít vůbec žádný protějšek. Ticketů v seznamu z Remedy bude prostě víc, a ty tickety které nemají žádnou shodu se mají poznamenat a vytvoří se z nich hledací řetězec pro hromadní uzavření ticketů. Porovnání způsobu. Pro porovnaní těchto způsobů musím tady vysvětlit některé zvláštnosti nebo spíš problémy se kterými se setkáváme při předaní ticketů OBS. Když uděláme Assign ticketu na OBS, tak ne vždycky se podaří ticket přemostit poprvé, a jak už jsem řekla dřív, vždy to zkoušíme udělat podruhé za 5 nebo 10 minut po prvnímu pokusu, a to jestli ovšem se ten ticket ukazuje ve frontě failed to bridge tickets. Jakým způsobem se pozná jestli není ticket přemostěn? Pozná se to podle pole Vendor Ticket Number, které bud bude prázdné nebo místo obvyklého formátu ukazuje dlouhé číslo, které je v podstatě TimeStamp. Někdy ale může nastat situace, že se ten ticket ve skutečnosti přemostí a na straně OBS se vytvoří jejich Incident ID, při tom se ale ten Incident ID neukáže v našem systému. Jelikož my nevíme jestli se ten incident na straně 31

36 OBS vytvořil nebo ne, přemostíme ten ticket podruhé, a to se nám podaří ticket z fronty failed to bridge zmizí, což bude znamenat, že konečně číslo Vendor Ticket Number je ve správném formátu a podařilo se ho vůbec získat, jenomže je tu háček, protože se nám ho podařilo získat podruhé, vytvořilo se v systému OBS druhé Incident ID ke stejnému ticketu. OBS takové věci nemá rada, a Incident ID, které se vytvořilo jako poslední udělá jako Child Ticket pro to, co se vytvořilo dřív, což způsobí to, že ticket v Remedy přejde do stavu Pending a k tomu, bude mít špatné Vendor Ticket Number, při tom v systému OBS bude hodně duplikátů. Co taková situace způsobí při porovnání ticketů? Při porovnání s tickety v jiném stavu než Closed, a v případě, že budeme porovnávat Incident ID od OBS a Vendor Ticket Number v Remedy, zůstanou nám bez protějšku tickety, které ve skutečnosti nejsou ještě uzavřené, ale my je nebudeme moci vyloučit, protože bychom měli projít vytvořeným seznamem ručně, což pro nás není přijatelné, a proto k tomu budeme muset mezi sebou ještě porovnat Incident ID od Remedy a Customer Reference uložené v MSS. Při tom ale stejně v tom nebudeme mít jasno a pořád to budeme muset probírat, protože uzavřít případ, který ještě nebyl vyřešen pro nás není přijatelně. V případě, že budeme porovnávat s tickety ve stavu Closed, jakékoliv spojení mezi čísly ticketů bude přijato, jelikož víme, že jsou definitivně uzavřené. Takovým způsobem vychází, že nejlépe porovnávat podle první varianty. Teď přejdeme k jednotlivým krokům, které je potřeba udělat pro uzavření těch ticketů. Vytvoření reportu obsahujícího všechny tickety předané OBS. První krokem pro vytvoření reportu obsahujícího všechny tickety na daný okamžik předané OBS je najít všechny tickety, které jsou v stavu Assigned nebo Pending ve frontě nominální skupiny pro OBS a to EUR-OBS Voice and Data. Jak se to může udělat bylo popsané dřív v bodě Jak najít frontu případů konkrétního týmu. Tady se ale má brát do úvahy to, že při hledaní všech ticketů pro OBS, bude systém také do výsledků zahrnovat ty tickety, které byli zaregistrované v Service Desku rozmístěném v Monrealu a obsluhujícím uživatele z Německé pobočky zákazníka, ke které my jakožto řešící tým nemáme vztah a proto musíme Německé tickety ze seznamu vyloučit. Výsledný hledací řetězec bude vypadat tak: 'Support Company*' = "Orange Business Services" AND 'Support Organization*' = "Vendor" AND 'Assigned Group*+' = "EUR-OBS Voice and Data" AND 'Status*' < "Resolved" AND 'Company*+'!= "ZFS Germany" 32

37 Obrázek 15: Seznam ticketu předaných OBS Po tom co najdeme všechny tickety musíme je všechny zvýraznit a na to se zmáčkne tlačítko Select all. Až budeme mít je zvýrazněné stiskne se tlačítko Report a objeví se nám okénko ve kterém si můžeme vybrat bud vytvoření vlastní kostry pro report nebo vybrat z existující nabídky. Jelikož takového reportu, který chceme ještě v nabídce neexistuje, vytvoříme si nový, který nazveme OBS test. Pro jeho vytvoření vybereme volbu Create. Zajímavé na teto stránce je to, že i když existuje lišta ve které se má vybrat typ reportu, je v ní jenom jeden typ, a to AR System jak je vidět na Obrázku

38 Obrázek 16: Vytvoření reportu v AR Systému Jakmile stiskneme Create, objeví se nám okno, ve kterém musíme vyplnit potřebná pole. V poli Report Name si podle přání napíšeme název reportu, což pro nás jak už jsem řekla dřív, bude OBS test. Polička Server Name a Form Name budou automatický předvyplněná a my nebudeme je měnit, jelikož na to není potřeba. Jinak, Server Name je server na kterém se nachází forma která ze které se má udělat report. Toto pole je nepovinné. V případě, že nebude specifikováno, automatický se předpokládá, že forma je na současném serveru. Form Name je název formy ze které se budou brát data pro report. Report Format - formát ve kterém bude report generován. Toto je implicitní formát pro tento report, který ale může být přepsán v průběhu generování reportu v závislosti na tom, jak bude definován cílový bod generování. Z nabídky Formátů si vybereme typ Column, protože chceme aby naše data byla zobrazována ve sloupcích. Locale je místo uložení reportu, které také nezávazné pro vyplnění. Report Set - soustava reportů se kterým 34

39 chceme tento report spojit. Toto pole také nebudeme vyplňovat jelikož současně s žádnou soustavou tento report spojovat nepotřebujeme. Obrázek 17: Výplnění formátu a obshahu reportu Jakmile budeme mít vyplněnou horní část údajů o reportu, přejdeme do lišty Fields, ve které si vybereme jaká pole chceme vidět v našem reportu. Tato pole můžeme podle sve volby volně přidávat nebo naopak odebírat. Jelikož jsme si vybrali sloupcově orientovaný report, můžeme si určovat pořadí ve kterém chceme ty sloupce vidět. K tomu také můžeme určit i šířku těchto sloupců. Poli které si můžeme do reportu přidat je velice hodně a proto nebudu je všechny tady vyjmenovávat, jelikož některé z nich pro naše účely se vůbec nehodí a některé se ani nebudou moci vyplnit. Z nabídky těchto poli považují za nutné do reportu zahrnout taková pole jako Vendor Ticket Number, Incident ID, Status, SLA Responded, Reported to Vendor Date a Company. Zkoušela jsem do reportu také přidávat pole Vendor Responded Date, Site ID a jiné pole ukazující především různé časové údaje, ukázalo se ale, že tato pole v konečném reportu ukazují v čistě číselném formátu, který zaujme hodně času pro převod do čitelného a člověkem pochopitelného formátu. Pole Vendor Ticket Number v reportu potřebujeme kvůli porovnání s Číslem Případu ze strany OBS. Pole Incident ID potřebujeme pro vytvoření výsledného řetězce podle kterého se budou hledat tickety k uzavření. Pole Status, Reported to Vendor Date a Company potřebujeme pro analytické účely. My totiž nevíme, co způsobuje přerušení předávání dat, a můžeme začít alespoň analýzou toho, v jakém stavu většinou toto porušení můstku nastává, jaké lokace jsou tím nejvíc postižené a kdy byl každý ticket 35

40 předán OBS. Pokus analyzovat lokaci je odůvodněn tím, že často při předání ticketu OBS se vyskytuje situace, kdy hned vidíme, že ticket nebyl přemostěn a důvodem je to, že systém OBS některé označení lokaci nebo Site ID jako platnou lokaci nepřijme. Může se stát, že jsou tyto věci mezi sebou spojené. Další lišta která nás zajímá je Sorting, ve které si můžeme určit pořadí podle kterého budou řádky v našem reportu uspořádané. Doporučuji je seřadit podle datu, kdy byl ticket předán a to v stoupajícím pořadí, jelikož z největší pravděpodobnosti tickety které selhali být obnovovány budou v takovém pořadí na začátku seznamu. Obrázek 18: Výběr seřazení Ostatní nejsou pro nás zajímavé, jelikož v nich nemůžeme pro sebe něco použitelného nadefinovat. Pro další informaci o dalších lištách viz Příloha 1. Pro uložení vytvořeného reportu stiskneme tlačítko Save v levém horním rohu a zase přejdeme do stránky, kde se dá v seznamu reportů po obnovení najít náš nový report a podle něho již dostat konkretní data se kterými budeme dál pracovat. Tady bych chtěla poznamenat, že se tento report má vytvořit jenom jednou, dále bude ten samý report přístupný pro všechny členy týmu OBS Focal. 36

41 Obrázek 19: Save Obrázek 20: Run report Po tom, co svůj report najdeme v seznamu reportů, budeme si muset vybrat kam chceme ten report nahrát. Máme volby si ho nahrát na obrazovku a do souboru. Jelikož s daty budeme potom ještě pracovat, nahrajeme report do souboru. Dál nás zajímá v jakém formátu ten report chceme. Remedy AR systém totiž je umí generovat v čtyřech formátech a to jsou:.csv tento formát se dá otevřít jako obyčejný Excel soubor. Dá se ho také otevřít v Notepadu, a kdybych pro řešení tohoto problému psala celý malý program tak bych ho otevírala akorát tam, jak se ale ukáže později, budeme muset pro řešení problému použít Excel..rep tento formát se dá otevřít také v Notepadu a také se dá ho v přehlednějším 37

42 stavu prohlížet v obyčejném Internet prohlížeči..arx - tento formát se otevírá stejným způsobem jako předchozí. a.xml formát xml je velice dobrá věc, která se může otevřít v hodně různých programech včetně Wordu, Excelu, Accesu a hodně jiných. Pro účely teto práce si vybereme formát.csv, jelikož jak už jsem řekla pro vyřešení problému použijeme funkcí Excelu. Odůvodněním tady je to, že z bezpečnostních důvodů není možné pracovníkům CSC bez odpovídajícího povolení instalovat žádné nové aplikace. Ovšem že by se dalo pro pracovní účely vytvořený program nainstalovat, ale sehnaní na to povolení zaujme více času, než by se chtělo. Při tom také každý ze členů OBS Focal týmu by měl svému vedoucímu vysvětlit proč ten program potřebuje. Napsaní programu, který by tento problém řešil automaticky zaujme možná více času a opravdu řečeno na to postačí funkcionality, kterou má Microsoft Excel 2010 před nedávném nainstalovaný na každý počítač Service Desku. Dalším důvodem pro výběr k řešení Excele je to, že jediný formám ve kterém se dá vygenerovat report v systému MSS je.xls. Takže potom, co si vybereme formát.csv také si vybereme Character Encoding, což doporučuji Windows-1252, které se používá defaultně v produktech Microsoft. Teď, když máme všechno nastavené zbývá kliknout Run a za pár vteřin budeme mít hotový report. 38

43 Vytvoření reportu v MSS. Na začátku se do systému přihlásíme. Obrázek 21: Přihlašovací stránka Potom uvidíme úvodní stránku a tam přejdeme do incident dashboard. 39

44 Obrázek 22: odkaz do incident dashboard Na teto stránce klikneme na tlačítko generate report a přejdeme do tvorby potřebného reportu. Obrázek 23: generate report Na stránce Reporting, si vymezíme časový úsek na kterém chceme zkontrolovat existenci neuzavřených na straně CSC tucketů. Doporučuji tady před tím než to zadávat podívat se do reportu vytvořeného v Remedy, tam totiž uvidíte, jaký je nejstarší ticket, který se až dosud řeší. 40

45 Obrázek 24: stránka Reporting, výběr časového úseku Po tom, co zadáme časový úsek, nadefinujeme jaké chceme v reportu vidět sloupce a v jakém pořádku. Obrázek 24: definice sloupců v reportu Všechny sloupce které vidíte vybrané na Obrázku 24 doporučuji do reportu přidat. Z již známých důvodů tam chceme Incident ID, Customer Reference a Country, Site ID a Site Address potřebujeme protože je nemůžeme uvidět v reportu v Remedy a Case Type 41

46 potřebujeme pro vyloučení jiných typu Případů než Incident. Obrázek 25: Kritéria hledání Na stránce Filter Criteria si určíme kritéria podle kterých chceme hledat. Jelikož náš Service Desk nepodporuje takové země jako Německo, SSA a Rakousko, musíme je z hledání vyloučit. Potom jak už jsem řekla budeme hledat jenom tickety typu Incident a také chceme aby Customer Reference v našem reportu začínalo jako EU-INC, protože OBS má hodně různých označení pro různé typy incidentů, ale je to jejich interní věc, pro nás je důležité aby Customer Reference pro nás začínalo jako EU-INC. Jakmile budeme všechny kritéria mít zadané, klikneme OK a generate report. Po chvíli budeme mít druhý report a můžeme začít s jejich porovnání v Excelu. Porovnání seznamu v Excel a následné uzavření ticketu v Remedy. Pro větší přehlednost tady ukážu jak vypadají reporty v Excelu. Na Obrazcích 26 a 27 vidíte report z Remedy a MSS podle uvedeného pořadí. 42

47 Obrázek 26: Report z Remedy Obrázek 27: Report z MSS Pro porovnání takto formátovaných záznamů musíme pro začátek oba reporty otevřít a jeden z reportu nakopírovat do listu druhého, například nakopírujeme report z MSS do reportu od Remedy. Po tom si otevřeme třetí list, a přejdeme do záložky View, tam najdeme položku Macros a klikneme na Record Macro. Obrázek 28: Record Macro 43

48 Po tom co vybereme volbu Record Macro začne Excel zaznamenávat každý krok který uděláte v teto aplikaci. Velice dobré vysvětlení toho co je Macros, jak funguje, jak se může napsat a na co se používá je na oficiálních stránkách pro Office Microsoft, odkaz najdete v zdrojích[7]. Tady ale musím vysvětlit proč pro řešení porovnání ticketů v Excel používáme Macros. Odpověď je jednoduchá, reporty které máme jsou v různých formátováních a musíme je dat dohromady. Na to abychom je dali dohromady, nakopírovali vedle sebe potřebné seznamy, očistili to co se má očistit, jako například odstranění části A::EQUANT:: ze sloupce Vendor Ticket Number, musíme udělat malé a docela jednoduché kroky, takových kroků ale bude hodně, a my budeme muset je opakovat každý týden nebo měsíc. Akorát pro úsporu času a celkové automatizaci kroku to děláme. Stačí jednou ty kroky pomoci Macrosu zapsat a už s tím nebudeme mít problém. Takže teď musíme zapsat nebo zaznamenat posloupnost kroků, které nám pomohou vytvořit seznam ticketů k uzavření. 1. Za prvé musíme svůj Macros pojmenovat a popsat. Uděláme to a klikneme OK. 2. Teď přejdeme do listu s reportem z Remedy, zvýrazníme sloupec který v sobe obsahuje Vendor Ticket Number a očistíme ho od části A::EQUANT:: a to tak, že stiskneme klavesy CTRL+F, tam přejdeme do lišty Replace, v poli Find what zadáme A::EQUANT:: a stiskneme Replace all. 44

49 3. Vedle sebe do třetího listu nakopirujeme Incident ID od CSC, očištěný Vendor Ticket Number, Customer Reference a Incident ID od OBS. 4. Zvýrazníme sloupce Incident ID od CSC a Customer Reference, v horní části dokumentu přejdeme do lišty Home a najdeme tam Conditional Formating, klikneme na to, přejdeme do Duplicate Values jak je to ukázáno na obrázku niž. Vybereme si Duplicates a barvu, kterou chceme zvýraznit tickety, které se mají uzavřít. 45

50 5. V horním pravém rohu najdeme Sort and Filter, stiskneme Filter. 46

51 6. Klikneme na Incident ID od CSC a vybereme volbu Filter by color. Hotovo, konečně máme seznam ticketů k uzavření. 7. Ty tickety okopírujeme a vložíme do nového listu, tak aby jejich seznam začínal na 4. řádku. Do prvního řádku a prvního sloupce nakopírujeme tohle: Support Company*' = "Orange Business Services" AND 'Support Organization*' = 47

52 "Vendor" AND 'Assigned Group*+' = "EUR-OBS Voice and Data" AND 'Incident ID*'= Do druhého řádku a prvního sloupce nakopírujeme tento kus: OR 'Incident ID*'= Potom do libovolné buňky nakopírujeme tento velký kus: =CONCATENATE(A1,IF(A4<>0,CONCATENATE("""",A4,"""")),IF(A5<>0,A2,""),IF(A5<> 0,CONCATENATE("""",A5,""""),""),IF(A6<>0,A2,""),IF(A6<>0,CONCATENATE("""",A6,"""")," "),IF(A7<>0,A2,""),IF(A7<>0,CONCATENATE("""",A7,""""),""),IF(A8<>0,A2,""),IF(A8<>0,CO NCATENATE("""",A8,""""),""),IF(A9<>0,A2,""),IF(A9<>0,CONCATENATE("""",A9,""""),""),IF( A10<>0,A2,""),IF(A10<>0,CONCATENATE("""",A10,""""),""),IF(A11<>0,A2,""),IF(A11<>0,C ONCATENATE("""",A11,""""),""),IF(A12<>0,A2,""),IF(A12<>0,CONCATENATE("""",A12,""""),""),IF(A13<>0,A2,""),IF(A13<>0,CONCATENATE("""",A13,""""),""),IF(A14<>0,A2,""),IF(A14 <>0,CONCATENATE("""",A14,""""),""),IF(A15<>0,A2,""),IF(A15<>0,CONCATENATE("""",A 15,""""),""),IF(A16<>0,A2,""),IF(A16<>0,CONCATENATE("""",A16,""""),""),IF(A17<>0,A2,""),IF(A17<>0,CONCATENATE("""",A17,""""),""),IF(A18<>0,A2,""),IF(A18<>0,CONCATENAT E("""",A18,""""),""),IF(A19<>0,A2,""),IF(A19<>0,CONCATENATE("""",A19,""""),""),IF(A20<> 0,A2,""),IF(A20<>0,CONCATENATE("""",A20,""""),"")) Tento kus pro nás vytvoří hledací string z 20 tickety, protože pro Remedy najít víc než 20 konkrétních případů je tak obtížné, že během takového hledání často pro mě zkrachovala. Takže stejně se bude muset hledat po částech. Tady je část výsledného hledacího řetězce: Support Company*' = "Orange Business Services" AND 'Support Organization*' = "Vendor" AND 'Assigned Group*+' = "EUR-OBS Voice and Data" AND 'Incident ID*'="EUINC " OR 'Incident ID*'= "EU-INC " OR 'Incident ID*'= "EUINC " OR 'Incident ID*'= "EU-INC " OR 'Incident ID*'= "EUINC " OR 'Incident ID*'= "EU-INC " OR 'Incident ID*'= "EUINC " OR 'Incident ID*'= "EU-INC " OR 'Incident ID*'= "EUINC " OR 'Incident ID*'= "EU-INC "... Hledání podle stringu bylo popsáno v předchozí části teto práce, takže přejdeme k samotnému uzavření ticketů. Na stránce s výsledným seznamem v Remedy stiskneme Select All potom přejdeme do lišty Resolution. Tam vyplníme taková pole jako Resolution, Resolution Method, Cause a další. Status ticketu postavíme jako Closed a Status Reason postavíme jako Automated Resolution, jelikož taková kategorizace pro uzavření těchto případů byla schvalená ještě před tím než jsem se začala tím zabývat. 48

53 49

MS SQL Server 2008 Management Studio Tutoriál

MS SQL Server 2008 Management Studio Tutoriál MS SQL Server 2008 Management Studio Tutoriál Vytvoření databáze Při otevření management studia a připojením se ke konkrétnímu sql serveru mám v levé části panel s názvem Object Explorer. V tomto panelu

Více

Postupy práce se šablonami IS MPP

Postupy práce se šablonami IS MPP Postupy práce se šablonami IS MPP Modul plánování a přezkoumávání, verze 1.20 vypracovala společnost ASD Software, s.r.o. dokument ze dne 27. 3. 2013, verze 1.01 Postupy práce se šablonami IS MPP Modul

Více

Obsah. 1.1 Práce se záznamy... 3 1.2 Stránka Dnes... 4. 2.1 Kontakt se zákazníkem... 5

Obsah. 1.1 Práce se záznamy... 3 1.2 Stránka Dnes... 4. 2.1 Kontakt se zákazníkem... 5 CRM SYSTÉM KORMORÁN UŽIVATELSKÁ PŘÍRUČKA Obsah 1 Základní práce se systémem 3 1.1 Práce se záznamy................................. 3 1.2 Stránka Dnes.................................... 4 1.3 Kalendář......................................

Více

Nápověda pro systém ehelpdesk.eu

Nápověda pro systém ehelpdesk.eu www.ehelpdesk.eu Nápověda pro systém ehelpdesk.eu Obsah 1. Základní informace o ehelpdesk.eu... 2 1.1 Rychlé použití aplikace ehelpdesk.eu... 2 1.2 Příklady nasazení... 2 2. Příručka pro uživatele ehelpdesk.eu...

Více

36 Elektronické knihy

36 Elektronické knihy 36 Elektronické knihy Uživatelský modul Elektronické knihy slouží k přípravě a publikování informací ve formátu HTML. Tento formát je vhodný pro prezentaci informací na internetu a je široce podporován

Více

Evidence požadavků uživatelů bytů a nebytových prostor

Evidence požadavků uživatelů bytů a nebytových prostor Evidence požadavků uživatelů bytů a nebytových prostor Úvod Pro zjednodušení a zprůhlednění Vaší komunikace se správní firmou (dále jen SF ), která má na starost objekt, v němž se nachází bytový či nebytový

Více

Uživatelská příručka MWA Modul Podpora vzdálených kalibrací dle ILAC

Uživatelská příručka MWA Modul Podpora vzdálených kalibrací dle ILAC Uživatelská příručka MWA Modul Podpora vzdálených kalibrací dle ILAC Český metrologický institut sídlem Okružní 31, 638 00 Brno IČ: 00177016 Verze dokumentu: 1.1 Jazyk dokumentu: český Status: testovací

Více

KIV/SI. Přednáška č.2. Jan Valdman, Ph.D. jvaldman@dns.cz

KIV/SI. Přednáška č.2. Jan Valdman, Ph.D. jvaldman@dns.cz KIV/SI Přednáška č.2 Jan Valdman, Ph.D. jvaldman@dns.cz 8.3.2011 ITIL Information Technology Infrastructure Library ITIL v současnosti zahrnuje: Samotnou knihovnu Oblast vzdělávání a certifikace odborné

Více

Uživatelská příručka pro ředitele škol

Uživatelská příručka pro ředitele škol Národní šetření výsledků žáků v počátečním vzdělávání Uživatelská příručka pro ředitele škol Název souboru: Modul IDM - Uživatelská příručka pro ředitele škol V2.doc Strana 1 Obsah 1 Úvod... 3 2 Přihlášení

Více

PALSTAT s.r.o. systémy řízení jakosti PALSTAT CAQ verze. 3.00.01.09 Kontakty 08/2010. 1 Obsah

PALSTAT s.r.o. systémy řízení jakosti PALSTAT CAQ verze. 3.00.01.09 Kontakty 08/2010. 1 Obsah 1 Obsah 1 Obsah... 1 2 Úvod a spouštění SW Palstat CAQ... 2 2.1.1 Návaznost na další SW moduly Palstat CAQ... 2 2.2 Přihlášení do programu... 2 2.2.1 Stanovení přístupu a práv uživatele... 2 2.2.2 Spuštění

Více

Hromadná korespondence

Hromadná korespondence Kapitola dvanáctá Hromadná korespondence Učební text Mgr. Radek Hoszowski Hromadná korespondence Hromadná korespondence Představíme si jednoduchý nástroj, který nám může ušetřit velké množství práce. Je

Více

Nový způsob práce s průběžnou klasifikací lze nastavit pouze tehdy, je-li průběžná klasifikace v evidenčním pololetí a školním roce prázdná.

Nový způsob práce s průběžnou klasifikací lze nastavit pouze tehdy, je-li průběžná klasifikace v evidenčním pololetí a školním roce prázdná. Průběžná klasifikace Nová verze modulu Klasifikace žáků přináší novinky především v práci s průběžnou klasifikací. Pro zadání průběžné klasifikace ve třídě doposud existovaly 3 funkce Průběžná klasifikace,

Více

Profesis on-line 20.1.2015. Obrázky v prezentaci byly upraveny pro potřeby prezentace.

Profesis on-line 20.1.2015. Obrázky v prezentaci byly upraveny pro potřeby prezentace. Profesis on-line 20.1.2015 Obrázky v prezentaci byly upraveny pro potřeby prezentace. Adresa systému: www.profesis.cz Údaje nutné pro přihlášení: - přihlašovací jméno: sedmimístné číslo autorizace (včetně

Více

Internetový obchod Mironet

Internetový obchod Mironet České vysoké učení technické v Praze Fakulta elektrotechnická Internetový obchod Mironet Semestrální práce A2 Testování uživatelských rozhraní A4B39TUR Pavel Štíbal Stibapa1@fel.cvut.cz 2013/2014 Otevřená

Více

Použití Office 365 na telefonu s Androidem

Použití Office 365 na telefonu s Androidem Použití Office 365 na telefonu s Androidem Úvodní příručka Kontrola e-mailů Telefon s Androidem si můžete nastavit tak, aby odesílal a přijímal poštu z vašeho účtu Office 365. Kontrola kalendáře z libovolného

Více

Databázové patterny. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu

Databázové patterny. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Databázové patterny MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Obsah o Co je databázový pattern o Pattern: Přiřazení rolí o Pattern: Klasifikace Databázové patterny o Odzkoušené a doporučené

Více

26 Evidence pošty. Popis modulu. Záložka Evidence pošty

26 Evidence pošty. Popis modulu. Záložka Evidence pošty 26 Evidence pošty Uživatelský modul Evidence pošty realizuje podrobnou evidenci všech došlých a odesílaných poštovních zásilek s možností přidělovat tyto zásilky uživatelům informačního systému k vyřízení,

Více

Microsoft. Word. Hromadná korespondence. Mgr. Jan Veverka Střední odborná škola sociální Evangelická akademie

Microsoft. Word. Hromadná korespondence. Mgr. Jan Veverka Střední odborná škola sociální Evangelická akademie Microsoft Word Hromadná korespondence Mgr. Jan Veverka Střední odborná škola sociální Evangelická akademie Hromadná korespondence Funkce hromadná korespondence umožňuje vytvoření malé databáze (tabulky)

Více

End User Experience Monitoring Měření kvality IT služeb 7.10.2010, Brno Jiří Vozňák. information technology

End User Experience Monitoring Měření kvality IT služeb 7.10.2010, Brno Jiří Vozňák. information technology End User Experience Monitoring Měření kvality IT služeb 7.10.2010, Brno Jiří Vozňák information technology Základ firemní strategie Strategie firmy Lidé Procesy Nástroje Portfolio nabídky a služeb Crux

Více

Formátování pomocí stylů

Formátování pomocí stylů Styly a šablony Styly, šablony a témata Formátování dokumentu pomocí standardních nástrojů (přímé formátování) (Podokno úloh Zobrazit formátování): textu jsou přiřazeny parametry (font, velikost, barva,

Více

Uživatelská příručka MWA Modul Podpora vzdálených kalibrací dle ILAC

Uživatelská příručka MWA Modul Podpora vzdálených kalibrací dle ILAC Uživatelská příručka MWA Modul Podpora vzdálených kalibrací dle ILAC Český metrologický institut sídlem Okružní 31, 638 00 Brno IČ: 00177016 Verze dokumentu: 1.0 Jazyk dokumentu: český Status: testovací

Více

E-BILLING UŽIVATELSKÝ MANUÁL. Platí od 08.2012. www.dhlfreight.cz 840 111 308

E-BILLING UŽIVATELSKÝ MANUÁL. Platí od 08.2012. www.dhlfreight.cz 840 111 308 E-BILLING UŽIVATELSKÝ MANUÁL Platí od 08.2012 www.dhlfreight.cz 840 111 308 Obsah 1. E-BILLING 1.1 Úvod... 3 2. Registrační proces 2.1 Registrace do DHL E-BILLING... 4 2.2 Postup registrace do DHL E-BILLING...

Více

K práci je možné přistoupit následujícím způsobem. Odkaz na práci se nachází na osobním webu autora práce: http://stpr.cz/.

K práci je možné přistoupit následujícím způsobem. Odkaz na práci se nachází na osobním webu autora práce: http://stpr.cz/. 2. Seznámení K práci je možné přistoupit následujícím způsobem. Odkaz na práci se nachází na osobním webu autora práce: http://stpr.cz/. 2.1. Uživatel (učitel) Uživatelem (učitelem) se myslí osoba, která

Více

Jak si založit účet na fóru ČKR

Jak si založit účet na fóru ČKR Jak si založit účet na fóru ČKR Tento dokument byl vytvořen pro vysvětlení postupů a pojmů, se kterými se můžete setkat při registraci na fórum. V manuálu najdete informace o : pravidlech fóra a podmínkách

Více

http://www.hpl.cz hpl@hpl.cz H.P.L. Systems s.r.o. Jičínská 29 130 00 PRAHA 3, CZ Obsah

http://www.hpl.cz hpl@hpl.cz H.P.L. Systems s.r.o. Jičínská 29 130 00 PRAHA 3, CZ Obsah Obsah 1. Základní informace o aplikaci... 3 2. Základní práce s aplikací... 4 2.1. Spuštění aplikace... 4 2.2. Přihlášení do aplikace / odhlášení z aplikace... 4 3. Popis práce s BUGy... 5 3.1. Vytvoření

Více

Business Media CZ, s. r. o., člen skupiny Docu Group Company

Business Media CZ, s. r. o., člen skupiny Docu Group Company 1 Domovská stránka Hlavní lišta! POZOR! od posledního přihlášení. Pokud je v závorkách 0 neznamená to, že by pro Vás nebyl k dispozici žádný projekt. Hyperlinkové odkazy na příslušné projekty Grafické

Více

Externí Helpdesk Uživatelská příručka. verze 1.00

Externí Helpdesk Uživatelská příručka. verze 1.00 Externí Helpdesk Uživatelská příručka verze 1.00 Externí Helpdesk uživatelská příručka k webovému prostředí Copyright 2011 Triada, spol. s r. o. Triada, spol. s r. o. U svobodárny 1110/12 190 00 Praha

Více

NÁVOD NA ON-LINE objednávky parapetních desek přes web WWW.BOPAL.EU BOPAL window and door accessories, s.r.o

NÁVOD NA ON-LINE objednávky parapetních desek přes web WWW.BOPAL.EU BOPAL window and door accessories, s.r.o NÁVOD NA ON-LINE objednávky parapetních desek přes web WWW.BOPAL.EU BOPAL window and door accessories, s.r.o Veškerý nabízený sortiment parapetních desek a příslušenství objednáte jednoduše a rychle přes

Více

1. Administrace služby Bezpečný Internet přes webovou aplikaci WebCare GTS

1. Administrace služby Bezpečný Internet přes webovou aplikaci WebCare GTS 1. Administrace služby Bezpečný Internet přes webovou aplikaci WebCare GTS Pro přístup do administrace služby GTS Bezpečný Internet používejte zákaznický WebCare GTS Czech, který je přístupny přes webové

Více

Technická specifikace předmětu plnění:

Technická specifikace předmětu plnění: Technická specifikace předmětu plnění: Poskytnutí standardní služby Premier Support zahrnující konzultační a implementační podporu, řešení problémů u produktů v nepřetržitém režimu 24x7 v rámci aktuálního

Více

Uživatelská příručka MWA - Rezervační modul

Uživatelská příručka MWA - Rezervační modul Uživatelská příručka MWA - Rezervační modul Český metrologický institut sídlem Okružní 31, 638 00 Brno IČ: 00177016 Verze dokumentu: 1.1 Jazyk dokumentu: český Status: testovací Vytvořeno: Marcela Špičanová

Více

OBSAH. 48 Příručka ON-LINE KUPEG úvěrová pojišťovna, a.s. www.kupeg.cz

OBSAH. 48 Příručka ON-LINE KUPEG úvěrová pojišťovna, a.s. www.kupeg.cz DODATEK č. 1 20.1.2012 OBSAH OBSAH... 48 C. PRÁCE SE SYSTÉMEM... 49 C.1 ÚVODNÍ OBRAZOVKA PO PŘIHLÁŠENÍ... 49 C.2 NASTAVENÍ VLASTNÍCH ÚDAJŮ... 50 a. Nastavení Uživatele... 50 b. Nastavení Systému... 51

Více

Portál Algotech HelpDesk Uživatelský manuál

Portál Algotech HelpDesk Uživatelský manuál Portál Algotech HelpDesk Uživatelský manuál Vypracovali: Datum: 14. 9. 2012 Jméno Michal Zeman Jan Košátko Jan Skýpala Funkce IT specialista Project Manager Service Desk Manager Kontakt helpdesk@algotech.cz

Více

Jak vyhledávat. Vyhledávače KAPITOLA 3

Jak vyhledávat. Vyhledávače KAPITOLA 3 KAPITOLA 3 Jak vyhledávat Už víme, jak zacházet s programem Microsoft Internet Explorer, a můžeme se pustit do surfování. Ostatně, stejně jsme to při seznamování s funkcemi programu chtíce nechtíce dělali.

Více

Jak na jakost v podnikovém IT Evropský týden kvality Praha 10.11.2004

Jak na jakost v podnikovém IT Evropský týden kvality Praha 10.11.2004 Jak na jakost v podnikovém IT Evropský týden kvality Praha 10.11.2004 Jiří Sedláček AIT s.r.o, Sinkulova 83, 140 00 Praha 4 tel. 261 225 072 www.ait.cz AIT, 2004 1 Program Současné postavení IT v podniku

Více

Jednoduchý návod na základní obsluhu Prestashopu 1.6:

Jednoduchý návod na základní obsluhu Prestashopu 1.6: Jednoduchý návod na základní obsluhu Prestashopu 1.6: Správa objednávek Když přijde objednávka, systém automaticky zasílá email provozovateli eshopu a zákazníkovi. Seznam objednávek je zde: Vedle každé

Více

1 Úvod. 2 Registrace a přihlášení. Registrace). Zobrazí se stránka, kde budete mít na výběr ze dvou možností. Můžete vytvořit nové či.

1 Úvod. 2 Registrace a přihlášení. Registrace). Zobrazí se stránka, kde budete mít na výběr ze dvou možností. Můžete vytvořit nové či. 1 Úvod Aplikace XPERA Projects, která je určena pro sběr a řešení požadavků, přináší nový rozměr a efektivity mobilního klienta. Aplikace Xpera Projects pro ios znamená mít řešené případy stále s sebou.

Více

Bezdrátové routery LTE & UMTS datové a hlasové brány

Bezdrátové routery LTE & UMTS datové a hlasové brány Bezdrátové routery LTE & UMTS datové a hlasové brány Jak na to? Základní nastavení www.2n.cz 1. Základní nastavení V tomto dokumentu si popíšeme jak jednoduše nastavit základní funkci 2N SpeedRoute nebo

Více

Svolávací systém Uživatelský manuál

Svolávací systém Uživatelský manuál Uživatelský manuál TTC TELEKOMUNIKACE, s.r.o. Třebohostická 987/5 100 00 Praha 10 tel.: 234 052 111 fax.: 234 052 999 e-mail: ttc@ttc.cz http://www.ttc-telekomunikace.cz Datum vydání: 14. srpna 2013 Číslo

Více

Flexi uživatelská příručka verze 2.1

Flexi uživatelská příručka verze 2.1 Flexi uživatelská příručka verze 2.1 6. listopadu 2009 1 OBSAH 1. ÚVOD... 3 1.1 ZÁKLADNÍ POPIS A FUNKCIONALITA... 3 1.2 PŘEHLED ČINNOSTÍ... 4 1.3 UŽIVATELÉ... 4 1.4 SPRÁVCE AGENDY... 4 1.5 PRACOVNÍ POSTUPY...

Více

1.1. Správa a provozní podpora APV ROS, HW ROS a základního SW

1.1. Správa a provozní podpora APV ROS, HW ROS a základního SW Příloha č. 4 - Specifikace a informace o předmětu veřejné zakázky Předmětem veřejné zakázky je řízení projektu, správa a údržba programového vybavení pro informační systém Základní Registr osob (dále rovněž

Více

Instrukce pro vzdálené připojení do učebny 39d

Instrukce pro vzdálené připojení do učebny 39d Instrukce pro vzdálené připojení do učebny 39d Každá skupina má k dispozici jedno sdílené připojení, prostřednictvím kterého se může vzdáleně připojit do učebny 39d a pracovat na svých semestrálních projektech

Více

Školící dokumentace administrátorů IS KRIZKOM (úroveň KRAJ) (role manager, administrátor )

Školící dokumentace administrátorů IS KRIZKOM (úroveň KRAJ) (role manager, administrátor ) Školící dokumentace administrátorů IS KRIZKOM (úroveň KRAJ) (role manager, administrátor ) DATASYS s.r.o., Jeseniova 2829/20, 130 00 Praha 3 tel.: +420225308111, fax: +420225308110 www.datasys.cz Obsah

Více

1. Obecná konfigurace autentizace osob. 2. Konfigurace klienta Windows Vista

1. Obecná konfigurace autentizace osob. 2. Konfigurace klienta Windows Vista 1. Obecná konfigurace autentizace osob K autentizaci jakéhokoliv bezdrátového klienta k bezdrátové síti ISS-COP v Brně je nutné nastavit následující parametry. SSID pro učitele: ISSCOP_V1 SSID pro studenty:

Více

Administrace služby - GTS Network Storage

Administrace služby - GTS Network Storage 1. Návod k ovládání programu Cisco VPN Client (IP SECový tunel pro přístup GTS Network Storage) Program Cisco VPN client lze bezplatně stáhnout z webových stránek GTS pod odkazem: Software ke stažení http://www.gts.cz/cs/zakaznicka-podpora/technicka-podpora/gtspremium-net-vpn-client/software-ke-stazeni.shtml

Více

Manuál k e-learningovému vzdělávacímu modulu 1 MODUL HIGH-TECH POTRAVINY. Popularizace zdraví Po.Zdrav (CZ.1.07/3.1.00/37.0104)

Manuál k e-learningovému vzdělávacímu modulu 1 MODUL HIGH-TECH POTRAVINY. Popularizace zdraví Po.Zdrav (CZ.1.07/3.1.00/37.0104) 2013 Manuál k e-learningovému vzdělávacímu modulu 1 MODUL HIGH-TECH POTRAVINY Popularizace zdraví Po.Zdrav (CZ.1.07/3.1.00/37.0104) Obsah OBSAH... 1 ÚVOD... 2 PŘÍRUČKA PRO ADMINISTRÁTORA... 3 1. VYTVOŘENÍ

Více

Strom funkcí Lenovo Solution Center: Systémové nástroje (System)

Strom funkcí Lenovo Solution Center: Systémové nástroje (System) Solution Center funguje jako jednotné centrum, které sleduje stav počítače, hlásí případné problémy a pomůže s jejich řešením (proto Solution Center centrum řešení). Aplikace je mnohem přívětivější pro

Více

Zpracování ročních zpráv v IS FKVS Příručka pro koncové uživatele

Zpracování ročních zpráv v IS FKVS Příručka pro koncové uživatele Zpracování ročních zpráv v IS FKVS Příručka pro koncové uživatele vypracovala společnost ASD Software, s.r.o. dokument ze dne 1.10.2007, verze 1.01 Obsah Obsah... 2 1. Úvod... 3 2. Spuštění počítače, spuštění

Více

Použití Office 365 na iphonu nebo ipadu

Použití Office 365 na iphonu nebo ipadu Použití Office 365 na iphonu nebo ipadu Úvodní příručka Kontrola e-mailů iphone nebo ipad si můžete nastavit tak, aby odesílal a přijímal poštu z vašeho účtu Office 365. Kontrola kalendáře z libovolného

Více

Manuál QPos Pokladna V1.18.1

Manuál QPos Pokladna V1.18.1 Manuál QPos Pokladna V1.18.1 OBSAH Obsah 1. QPOS dotyková pokladna... 3 2. Jak číst tento manuál... 4 2.1. Čím začít?... 4 2.2. Členění kapitol... 4 2.3. Speciální text... 4 3. První spuštění... 5 3.1.

Více

Zkouška ITIL Foundation

Zkouška ITIL Foundation Zkouška ITIL Foundation Sample Paper A, version 5.1 Výběr z více možností Pokyny 1. Měli byste se pokusit odpovědět na všech 40 otázek. 2. Všechny svoje odpovědi vyznačte na samostatný formulář, který

Více

UŽIVATELSKÝ MANUÁL TS-HELPDESK

UŽIVATELSKÝ MANUÁL TS-HELPDESK UŽIVATELSKÝ MANUÁL TS-HELPDESK SMLOUVA (PROJEKT) ČÍSLO: STÁDIUM: Zvolte položku. ZAKÁZKA ČÍSLO: DŮVĚRNOST: Zvolte položku. ZE DNE: DATUM AKTUALIZACE: ZPRACOVAL / AUTOR: VERZE DOKUMENTU: 1. OBJEDNATEL:

Více

Uživatelská příručka

Uživatelská příručka Uživatelská příručka Popis postupu nastavení zabezpečené komunikace s CDS pomocí aplikace Outlook Express. Verze: C 23.10.2007 CDS D4_Instalace_OutlookExpressSettings.doc Strana 1 z 10 OBSAH 1 Úvod a shrnutí...4

Více

PRACUJEME S TSRM. Modul Samoobsluha

PRACUJEME S TSRM. Modul Samoobsluha PRACUJEME S TSRM Modul Samoobsluha V této kapitole Tato kapitola obsahuje následující témata: Téma Na straně Přehled kapitoly 6-1 Užití modulu Samoobsluha 6-2 Přihlášení k systému 6-3 Hlavní nabídka TSRM

Více

Vypracoval: Jiří Němeček, produktový manažer KOPOS KOLÍN a.s. Havlíčkova 432 CZ 280 94 Kolín a IV. Konfigurátor KNS

Vypracoval: Jiří Němeček, produktový manažer KOPOS KOLÍN a.s. Havlíčkova 432 CZ 280 94 Kolín a IV. Konfigurátor KNS Konfigurátor KNS Cílem programu je poskytnout zákazníkovi větší komfort při práci s výrobky firmy KOPOS. Program pracuje s výrobky produktového portfolia kabelových nosných systémů. Je velmi intuitivní,

Více

Školící dokumentace administrátorů IS KRIZKOM (úroveň ÚSÚ) role ( administrátor )

Školící dokumentace administrátorů IS KRIZKOM (úroveň ÚSÚ) role ( administrátor ) Školící dokumentace administrátorů IS KRIZKOM (úroveň ÚSÚ) role ( administrátor ) DATASYS s.r.o., Jeseniova 2829/20, 130 00 Praha 3 tel.: +420225308111, fax: +420225308110 www.datasys.cz Obsah 1.1 Historie

Více

Zpracoval Datum Verze Popis změn

Zpracoval Datum Verze Popis změn Uživatelský manuál Zpracoval Datum Verze Popis změn Grant Avakjan 29.09.2010 1.0 Vytvoření manuálu Grant Avakjan 14.10.2010 2.0 Aktualizace dokumentu Aleš Danda 2. 8. 2011 2.1 Aktualizace dokumentu popis

Více

Pomůcka/manuál pro redakční systém http://helpdesk.remax-czech.cz verze 1.0

Pomůcka/manuál pro redakční systém http://helpdesk.remax-czech.cz verze 1.0 Pomůcka/manuál pro redakční systém http://helpdesk.remax-czech.cz verze 1.0 Přihlášení do systému Na adrese http://helpdesk.remax-czech.cz, viz. obr., vyplněním příslušného uživatelského jména a hesla.

Více

ISI WEB OF SCIENCE - manuál

ISI WEB OF SCIENCE - manuál ISI WEB OF SCIENCE - manuál Obsahuje především bibliografické údaje a abstrakty článků cca 8 000 vědeckých a odborných časopisů z oblasti přírodních a společenských věd od roku 1945 do současnosti. U některých

Více

NÁVOD NA OBSLUHU INTERNETOVÉ PREZENTACE. Ataxo Czech s.r.o.

NÁVOD NA OBSLUHU INTERNETOVÉ PREZENTACE. Ataxo Czech s.r.o. NÁVOD NA OBSLUHU INTERNETOVÉ PREZENTACE Ataxo Czech s.r.o. ÚVOD Internetové stránky vytvořené společností Ataxo v rámci produktu Mini web můžete jednoduše a rychle upravovat prostřednictvím on-line administrace.

Více

Použití informačního systému Helios Orange Personalistika

Použití informačního systému Helios Orange Personalistika Použití informačního systému Helios Orange Personalistika 2014 BüroKomplet, s.r.o. Obsah 1 Kontakty... 3 2 Obecné... 4 3 Školení, lékařské prohlídky... 5 3.1 1. krok kategorie školení, lékařských prohlídek...

Více

CUZAK. Uživatelská příručka. Verze 2.0 2014

CUZAK. Uživatelská příručka. Verze 2.0 2014 CUZAK Uživatelská příručka Verze 2.0 2014 Copyright 2014 Altair Software s.r.o. Všechna práva vyhrazena. Všechna práva vyhrazena. Všechna informace, jež jsou publikována na v tomto dokumentu, jsou chráněna

Více

Lokality a uživatelé

Lokality a uživatelé Administrátorský manuál TTC TELEKOMUNIKACE, s.r.o. Třebohostická 987/5 100 00 Praha 10 tel.: 234 052 111 fax.: 234 052 999 e-mail: ttc@ttc.cz http://www.ttc-telekomunikace.cz Datum vydání: 15.října 2013

Více

Co je to E-Business Centrum

Co je to E-Business Centrum Co je to E-Business Centrum Jedná se o internetovou aplikaci, která je určena k oboustranné výměně informací mezi informačním systémem firmy Bartech, s.r.o. a zákazníkem. Přínosem jsou informace o novinkách,

Více

Moje Cisco Nejčastější dotazy

Moje Cisco Nejčastější dotazy 1. Co je Moje Cisco? Moje Cisco umožňuje mobilní, přizpůsobitelné zobrazení vašich oblíbených informací na webu Cisco.com. 2. Jak otevřít stránku Moje Cisco? Moje Cisco lze otevřít dvěma způsoby: Rozbalovací

Více

Vzorce. StatSoft. Vzorce. Kde všude se dá zadat vzorec

Vzorce. StatSoft. Vzorce. Kde všude se dá zadat vzorec StatSoft Vzorce Jistě se Vám již stalo, že data, která máte přímo k dispozici, sama o sobě nestačí potřebujete je nějak upravit, vypočítat z nich nějaké další proměnné, provést nějaké transformace, Jinak

Více

Přepínání zobrazení Použijte zobrazení kalendáře, které nejlépe vyhovuje vašemu pracovnímu postupu. Přepínejte tak často, jak chcete.

Přepínání zobrazení Použijte zobrazení kalendáře, které nejlépe vyhovuje vašemu pracovnímu postupu. Přepínejte tak často, jak chcete. Kalendář Úvodní příručka Naplánování schůzky v Lyncu Setkejte se tváří v tvář a ušetřete si cestu díky online schůzce v Lyncu 2013. Přepínání zobrazení Použijte zobrazení kalendáře, které nejlépe vyhovuje

Více

Podrobný návod pro administraci zákaznických účtů na portálu Czechiatour.eu

Podrobný návod pro administraci zákaznických účtů na portálu Czechiatour.eu 2013 Podrobný návod pro administraci zákaznických účtů na portálu Czechiatour.eu Czechiatour.eu 1.2.2013 Vážení zákazníci portálu Czechiatour.eu. Abychom Vám co nejvíce usnadnili orientaci v administraci

Více

Supplier Web Uživatelská příručka. Supplier Web. Copyright Telefónica O2 Czech Republic, a.s. All rights reserved. 1/10

Supplier Web Uživatelská příručka. Supplier Web. Copyright Telefónica O2 Czech Republic, a.s. All rights reserved. 1/10 Supplier Web 1/10 OBSAH: Supplier Web 1 ÚVOD... 3 1.1 POUŽITÍ... 3 1.2 ZNAČENÍ... 3 2 VSTUP DO APLIKACE... 4 3 OBJEDNÁVKY... 7 4 LEGAL DISCLAIMER... 10 2/10 1 Úvod 1.1 Použití Dokument slouží jako uživatelská

Více

Už ivatelska dokumentace

Už ivatelska dokumentace Už ivatelska dokumentace Aplikace Portál úspěšných projektů je určena k publikování informací o projektech realizovaných za přispění některého z Operačních programů v gesci Ministerstva vnitra České republiky.

Více

CobiT. Control Objectives for Information and related Technology. Teplá u Mariánských Lázní, 6. října 2004

CobiT. Control Objectives for Information and related Technology. Teplá u Mariánských Lázní, 6. října 2004 CobiT Control Objectives for Information and related Technology Teplá u Mariánských Lázní, 6. října 2004 Agenda Základy CobiT Pojem CobiT Domény CobiT Hodnocení a metriky dle CobiT IT Governance Řízení

Více

Pravidla a plánování

Pravidla a plánování Administrátorský manuál TTC TELEKOMUNIKACE, s.r.o. Třebohostická 987/5 100 00 Praha 10 tel.: 234 052 111 fax.: 234 052 999 e-mail: ttc@ttc.cz http://www.ttc-telekomunikace.cz Datum vydání: 7. května 2013

Více

Hromadná korespondence

Hromadná korespondence Hromadná korespondence Teoretická část: Typickým příkladem použití hromadné korespondence je přijímací řízení na školách. Uchazeči si podají přihlášku, škola ji zpracuje a připraví zvací dopis k přijímací

Více

Elektronické zpracování dotazníků AGEL. Verze 2.0.0.1

Elektronické zpracování dotazníků AGEL. Verze 2.0.0.1 Elektronické zpracování dotazníků AGEL Verze 2.0.0.1 1 Obsah 2 Přihlášení do systému... 1 3 Zápis hodnot dotazníků... 2 3.1 Výběr formuláře pro vyplnění dotazníku... 2 3.2 Vyplnění formuláře dotazníku...

Více

MS Word 2007 Šablony programu MS Word

MS Word 2007 Šablony programu MS Word MS Word 2007 Šablony programu MS Word Obsah kapitoly V této kapitole se seznámíme s: Možností využití šablon při vytváření nových dokumentů Vytvářením vlastních šablon Studijní cíle Po absolvování této

Více

Katalog NGPC (New Generation Parts Catalogue)

Katalog NGPC (New Generation Parts Catalogue) Katalog NGPC (New Generation Parts Catalogue) 1. Spuštění katalogu: Zákaznický katalog je možné najít na webových stránkách společnosti Agri CS v sekci Náhradní díly, nebo přímým zadáním adresy http:///nahradnidily-katalog-nd

Více

Dallmayr WebShop. Uživatelská příručka. Dallmayr WebShop. Uživatelská příručka. Tiliaris s. r. o. 2014. Tiliaris s. r. o. 2014 Strana 1 / 11

Dallmayr WebShop. Uživatelská příručka. Dallmayr WebShop. Uživatelská příručka. Tiliaris s. r. o. 2014. Tiliaris s. r. o. 2014 Strana 1 / 11 Dallmayr WebShop Tiliaris s. r. o. 2014 Tiliaris s. r. o. 2014 Strana 1 / 11 Obsah 1. Účel dokumentu... 3 2. Nápověda... 4 Kategorie zboží... 4 Filtrování a třídění zboží... 4 Vyhledávání... 5 Nejčastěji

Více

Redakční systém Joomla. Prokop Zelený

Redakční systém Joomla. Prokop Zelený Redakční systém Joomla Prokop Zelený 1 Co jsou to red. systémy? Redakční systémy (anglicky Content Management System - CMS) jsou webové aplikace používané pro snadnou správu obsahu stránek. Hlavním cílem

Více

MapleCloud a jeho použ ití. Vladimír Žák

MapleCloud a jeho použ ití. Vladimír Žák MapleCloud a jeho použ ití Vladimír Žák Brno, 2015 Obsah 1 Úvod... 4 2 Novinky v MapleCloud pro Maple 2015... 5 3 MapleCloud a registrace... 6 4 Použití MapleCloud přímo z Maple 2015... 7 4.1 Popis jednotlivých

Více

Manuál k produktu. fajny shop. FajnyWEB.cz 2008 (6.11.2008)

Manuál k produktu. fajny shop. FajnyWEB.cz 2008 (6.11.2008) Manuál k produktu fajny shop FajnyWEB.cz 2008 (6.11.2008) Obsah Obsah... 2 1 Popis administrace... 4 1.1 Objednávky... 4 1.1.1 Přehled... 4 1.1.1.1 Filtry a vyhledávání... 4 1.1.1.2 Seznam objednávek a

Více

OVLÁDÁNÍ APLIKACE NIS MEDEA

OVLÁDÁNÍ APLIKACE NIS MEDEA OVLÁDÁNÍ APLIKACE NIS MEDEA Martin Fráňa, DiS. Děkanát, Fakulta zdravotnických věd, Univerzita Palackého v Olomouci 1.1 Základní informace NIS MEDEA je nemocniční informační systém (NIS) od společnosti

Více

Provozní dokumentace. Seznam orgánů veřejné moci. Příručka pro běžného uživatele

Provozní dokumentace. Seznam orgánů veřejné moci. Příručka pro běžného uživatele Provozní dokumentace Seznam orgánů veřejné moci Příručka pro běžného uživatele Vytvořeno dne: 7. 7. 2011 Aktualizováno: 11. 2. 2015 Verze: 2.2 2015 MVČR Obsah Příručka pro běžného uživatele 1 Úvod...3

Více

Microsoft Office. Word hromadná korespondence

Microsoft Office. Word hromadná korespondence Microsoft Office Word hromadná korespondence Karel Dvořák 2011 Hromadná korespondence Hromadná korespondence je způsob, jak určitý jeden dokument propojit s tabulkou obsahující více záznamů. Tímto propojením

Více

Čtvrtek 3. listopadu. Makra v Excelu. Obecná definice makra: Spouštění makra: Druhy maker, způsoby tvorby a jejich ukládání

Čtvrtek 3. listopadu. Makra v Excelu. Obecná definice makra: Spouštění makra: Druhy maker, způsoby tvorby a jejich ukládání Čtvrtek 3. listopadu Makra v Excelu Obecná definice makra: Podle definice je makro strukturovanou definicí jedné nebo několika akcí, které chceme, aby MS Excel vykonal jako odezvu na nějakou námi definovanou

Více

CA Business Service Insight

CA Business Service Insight SPECIFIKACE PRODUKTU: CA Business Service Insight CA Business Service Insight agility made possible Díky produktu CA Business Service Insight budete vědět, které služby jsou v rámci vaší společnosti využívány,

Více

1. Umístěte kurzor do sloupce Datový typ na řádek s polem, ve kterém vytvořit chcete seznam.

1. Umístěte kurzor do sloupce Datový typ na řádek s polem, ve kterém vytvořit chcete seznam. 10.6.7 POSTUP TVORBY KOMBINOVANÉHO SEZNAMU 1. Umístěte kurzor do sloupce Datový typ na řádek s polem, ve kterém vytvořit chcete seznam. 2. V rozbalovací nabídce se seznamem datových typů vyberte volbu

Více

Multimediální prezentace MS PowerPoint I

Multimediální prezentace MS PowerPoint I Multimediální prezentace MS PowerPoint I Informatika Multimediální prezentace zažívají v poslední době obrovský rozmach. Jsou používány například k reklamním účelům, k předvedení výrobků či služeb. Velmi

Více

Technologické postupy práce s aktovkou IS MPP

Technologické postupy práce s aktovkou IS MPP Technologické postupy práce s aktovkou IS MPP Modul plánování a přezkoumávání, verze 1.20 vypracovala společnost ASD Software, s.r.o. dokument ze dne 27. 3. 2013, verze 1.01 Technologické postupy práce

Více

43 HTML šablony. Záložka Šablony v systému

43 HTML šablony. Záložka Šablony v systému 43 HTML šablony Modul HTML šablony slouží ke správě šablon pro výstupy z informačního systému modularis ve formátu HTML. Modul umožňuje k šablonám doplňovat patičku, dokumentaci a vázat šablony na konkrétní

Více

Metodika poradenství. Vypracovali: Jiří Šupa Edita Kremláčková

Metodika poradenství. Vypracovali: Jiří Šupa Edita Kremláčková Metodika poradenství Vypracovali: Jiří Šupa Edita Kremláčková Úvod V následujícím textu je popsán způsob vedení rozhovoru s klientem, jehož cílem je pomoci klientovi prozkoumat jeho situaci, která ho přivedla

Více

1. Pro přihlášení k odběru novinek klikněte na tlačítko Registrace nového uživatele.

1. Pro přihlášení k odběru novinek klikněte na tlačítko Registrace nového uživatele. 1. Vstup do aplikace Na adrese: http://prace.statnisprava.cz 2. První stránka aplikace 1. Pro přihlášení k odběru novinek klikněte na tlačítko Registrace nového uživatele. 2. Poté budete přesměrováni na

Více

Evidenční systém pro reklamace Wooky tabletů reklamace.wooky.cz

Evidenční systém pro reklamace Wooky tabletů reklamace.wooky.cz Evidenční systém pro reklamace Wooky tabletů reklamace.wooky.cz Na výše uvedené URL adrese je umístěno jednoduché online rozhraní pro evidenci reklamací tabletů a příslušenství Wooky. Evidenční rozhraní

Více

7. Enterprise Search Pokročilé funkce vyhledávání v rámci firemních datových zdrojů

7. Enterprise Search Pokročilé funkce vyhledávání v rámci firemních datových zdrojů 7. Enterprise Search Pokročilé funkce vyhledávání v rámci firemních datových zdrojů Verze dokumentu: 1.0 Autor: Jan Lávička, Microsoft Časová náročnost: 30 40 minut 1 Cvičení 1: Vyhledávání informací v

Více

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Obecně o IS Vývoj informačních systémů Obecně o IS Informační systém Informační systém je propojení informačních technologií a lidských aktivit směřující k zajištění podpory procesů v organizaci. V širším slova smyslu

Více

[APLIKACE PRO PŘEHRÁVÁNÍ VIDEA - PROJEKT MIAMI - SERVEROVÁ ČÁST]

[APLIKACE PRO PŘEHRÁVÁNÍ VIDEA - PROJEKT MIAMI - SERVEROVÁ ČÁST] [APLIKACE PRO PŘEHRÁVÁNÍ VIDEA - PROJEKT MIAMI - SERVEROVÁ ČÁST] [Aktualizace dokumentu: 27.8.2011 3:02:37 Verze dokumentu: 1.0 Obsah Obsah... 2 1. Struktura databáze a souborů... 3 2. Soubor registerdevice.php...

Více

9 Sledování docházky. Spuštění modulu. Záložka Výběr uživatele

9 Sledování docházky. Spuštění modulu. Záložka Výběr uživatele 9 Sledování docházky Uživatelský modul Sledování docházky realizuje pracovní výkaz zaměstnance v elektronické podobě se všemi výhodami z toho plynoucími (automatické sčítání, převody do dalšího měsíce,

Více