A nezapomínejme přitom na to, že jsou minimálně dvě skupiny uživatelů tohoto nástroje, ti co incidenty hlásí a ti co je řeší. Incident může být uživatelem nahlášen telefonicky, mailem nebo přes webové rozhraní, což je z pohledu řešitele ta nejlepší varianta a z pohledu uživatele mnohdy ta nejhorší, bohužel. Bez ohledu na to, jakým způsobem je incident nahlášen, vždy by měl být spuštěn proces, jehož výsledkem by mělo být vyřešení daného incidentu. Proto také incident management zavádíme. 

Životní cyklus incidentu

Incident se během svého životního cyklu obvykle nachází v jednom z níže uvedených stavů. Vzhledem k tomu, že nástrojů na incident management je mnoho (a jeden je lepší než druhý), jsou tyto stavy pojmenovány různě, a proto musíme provést určité zobecnění.

• Detected – incident je někým nebo něčím detekován. V tomto stavu incident existuje mimo systém a ještě nebyl nahlášen na helpdesk.
• Registered – incident je v nástroji něčím nebo někým zaevidován
• Assigned – helpdesk incident vyhodnotil a přidělil ho k řešení konkrétní osobě nebo řešitelskému týmu
• Confirmed – pokud bylo přidělení incidentu helpdeskem správné, daná osoba nebo řešitelský tým incident přijetí incidentu potvrzuje
• Refused – pokud bylo přidělení incidentu helpdeskem chybné a daná osoba nebo řešitelský tým není kompetentní k řešení incidentu daného typu, tak incident odmítá. Incident se v takovém případě buď vrací na helpdesk, který musí provést nové přiřazení nebo ho může sama řešitelská skupina poslat na jinou z jejich pohledu vhodnější skupinu.
• Analyzed – incident je řešitelským týmem analyzován a je hledáno to nejrychlejší možné řešení. Cílem je, aby co nejvíce incidentů vyřešila první úroveň podpory a na další úrovně podpory se dostávalo incidentů co nejméně.
• Suspended – někdy řešitelský tým potřebuje doplnit od uživatele určité informace a po tuto dobu, co se čeká na informace od uživatele, se incident nachází v tomto stavu
• Solved – v okamžiku, kdy řešitelská skupina najde řešení daného incidentu, označuje incident za vyřešený
• Accepted – řešení je uživatelem akceptováno
• Rejected – řešení je uživatelem odmítnuto
• Closed – poté, co je řešení uživatelem akceptováno, může být incident uzavřen.

U všech stavů by mělo být definováno, jak dlouho se může incident v daném stavu nacházet. A u jednotlivých incidentů by mělo být možné tuto dobu změnit. Minimálně by měla být stanovena maximální doba řešení incidentu, resp. kdy nejpozději by měl incident přejít do stavu Closed. Je otázka, zda v okamžiku, kdy byl již incident jednou uzavřen, umožnit jeho znovuotevření, anebo založit incident nový s odkazem na ten původní. V okamžiku, kdy je čas řešení incidentu překročen, měl by na to být příslušný pracovník upozorněn.

Intuitivní rozhraní

Jestliže chcete, aby vám uživatelé hlásili incidenty prostřednictvím webového formuláře, musí být takovéto rozhraní naprosto intuitivní. Pokud uživatelské rozhraní (GUI) nebude intuitivní, nebude takovýto systém uživateli přijat a budou ho odmítat. A vězte, že ke zlepšení situace nepomůže ani sebelepší školení. Uvědomte si, že vzhledem k tomu, že uživatel obvykle nehlásí incident každý den, musí ihned pochopit, co a kam má přesně zapsat. Pokud chcete, aby uživatelé váš nástroj používali, nemělo by být k jeho použití nutné absolvovat nějaké školení nebo studovat dlouhý manuál. Jinými slovy, nástroj sám by měl uživatele vést a upozorňovat ho na to, co a kam má zapsat. Dovoluji si tvrdit, že drtivá většina uživatelů, kteří vám budou incident tímto způsobem hlásit, s počítačem běžně pracuje a je zvyklá, že určité věci fungují ve většině aplikací stejně a očekávají, že nejinak tomu bude i ve vaší aplikaci. Ovládací prvky by proto měly být na obvyklých místech. Bohužel nezřídka se ta stává, že nejen uživatelé, ale i řešitelské týmy mají problémy s danou aplikací pracovat. 

Efektivní workflow

Nástroj by měl umožňovat snadné předávání incidentu mezi jednotlivými řešitelskými skupinami. Přeposlání incidentu na další řešitelskou skupinu musí být stejně jednoduché, jako když přeposíláte e-mail. Krátce po nasazení nástroje na incident management je třeba počítat s tím, že první úroveň podpory bude některé incidenty směrovat na špatné řešitelské skupiny. Pokud helpdesk neanalyzuje, kdo nakonec incident daného typu řešil, může se stát, že bude incident přiřazovat pořád špatně. V opačném případě by se měl počet chybně přiřazených incidentů v delším časovém horizontu postupně snižovat. Předpokladem však je, že vybraný nástroj umí budovat databází znalostí (knowledgebase) a efektivně v ní vyhledávat již jednou řešené incidenty. Vždy by měla být stanovena osoba dohlížející na vyřešení incidentů v rozumném čase. Pokud není stav řešení incidentů v systému nikým monitorován, hrozí, že jednotlivé řešitelské skupiny budou jim přidělené incidenty odmítat nebo si ho budou mezi sebou přeposílat jako „horký brambor“. 

Komunikace s uživatelem

Incident by měl být v systému evidován pod jedním číslem, pouze by se měl měnit jeho status a řešitelská skupina. Uživatel, který incident nahlásil, by měl mít možnost sledovat, v jakém stavu se incident nachází. Měl by proto dostat e-mail obsahující číslo incidentu a odkaz, na kterém může stav řešení incidentu sledovat. V okamžiku, kdy se incident dostane do stavu Vyřešeno (Solved), měl by uživatel dostat e-mail s požadavkem na akceptování daného řešení. Poté, co je řešení uživatelem odsouhlaseno (Accepted) měl by incident přejít do stavu uzavřen (Closed) a uživateli by měl být zaslán informativní mail o uzavření incidentu. 

E-mailová notifikace řešitelů

Nástroj by měl umět zaslat notifikaci o tom, že řešitelské skupině byl přiřazen incident. Není možné počítat s tím, že člen řešitelského týmu se bude celý den sledovat frontu, jestli se tam náhodou něco neobjevilo. Možnost zasílání této informace by měla být zpřístupněna všem uživatelům vybraného nástroje, a měli by mít možnost si to sami nastavit. Je zřejmé, že tým, který je plně alokován na řešení incidentů a přijde mu jich několik za hodinu asi žádnou e-mailovou notifikaci potřebovat nebude, protože by ho jen vyrušovala. Avšak tým, kterému chodí jeden incident za den nebo za týden ano, protože jinak nebude reagovat v požadovaném čase. Notifikace nemusí být jen mail, může se jednat i o ikonu v tray, která se změní svůj status nebo popup okno, které se objeví v okamžiku, kdy je incident dané řešitelské skupině přidělen.

Vyhledávání

Dalším velice častým problémem některých nástrojů je, že se v nich velice špatně vyhledává. Víte, že podobný incident jste již jednou řešili, ale pochopitelně si již nepamatujete jeho číslo. Nástroj by tedy měl umožnit sestavit takový dotaz, aby bylo možné zadat klíčové slovo, jméno řešitele nebo řešitelské skupiny a případně období, kdy jste incident řešili.

Závěr: Uvědomte si prosím, že uživateli je jedno, kolik řešitelských týmu na řešení jeho incidentu spolupracuje a jak je řešení jeho incidentu náročné. Uživatel svou povinnost splnil v okamžiku, kdy vám incident nahlásil a to způsobem, který ho stál určité úsilí. Přiznejme si, že pro většinu uživatelů je mnohem jednodušší a pohodlnější zvednout telefon a incident nahlásit tímto způsobem. Vyplňování jakéhokoliv formuláře uživatele obtěžuje. Když už vám uživatel incident prostřednictvím webové aplikace nahlásil, řešte ho. Nevracejte mu incident s tím, že tam něco špatně vyplnil. Vůbec nejhorší je, když řešitelský tým vrátí incident uživateli v nejzazším možném termínu s tím, že něco špatně vyplnil. Když víte, že uživatel něco špatně vyplnil – opravte si to a neobtěžujte ho s tím. S největší pravděpodobností uživatel podobný problém v nejbližší době stejně hlásit nebude, takže argumentovat tím, že to děláte proto, aby to uživatel vyplnil příště správně, je nesmysl. Když už máte potřebu uživatele poučovat, udělejte to v okamžiku, kdy je jím nahlášený incident vyřešen.

Related posts:

1. Bezpečnostní incident: Drahý incident management
2. Bezpečnostní incident: stanovení závažnosti incidentu
3. Bezpečnostní incident

IT governance je zaměřeno na strategické řízení IT, které by mělo vycházet ze strategických business plánů společnosti. Strategii IT definuje jeho vrcholový management, zastoupený nejčastěji CIO (Chief Information Officer), který též zajišťuje komunikaci mezi IT a obchodními útvary a odpovídá vrcholovému managementu dané společnosti. CIO definuje organizační strukturu a poslání jednotlivých útvarů, předkládá stávající možnosti a omezení IT, definuje požadavky na zdroje, pravidla, způsob měření a kontrol, např. dle COBIT.

IT management podléhající CIO je naproti tomu zaměřen na taktické a operativní řízení uvnitř IT. Jeho cílem je zajišťovat každodenní dodávku služeb, které IT svým zákazníkům poskytuje a to v požadované kvalitě. IT management se zabývá řešením problémů, které souvisí s běžným vývojem, zaváděním a provozem informačních systémů např. dle ITIL.

IT Governance by se dal za použití COBIT definovat např. takto: 

• Strategický soulad (Strategic Alignment) – IT strategie by měla být vytvářena na základě business strategie. Bohužel spousta firem toto jednoduché pravidlo nepochopila a snaží se vytvářet IT strategii bez toho, aniž by detailně znala business cíle.
• Dodávání hodnoty (Value Delivery) – IT by mělo přispět ke snížení nákladů, vyšším výnosům a tedy i lepšímu zhodnocení investic, měřené např. jako ROI.
• Řízení zdrojů (Resource Management) – předpokladem pro dodávání hodnoty by mělo být efektivní využití dostupných zdrojů (lidí, aplikací, infrastruktury a informací)
• Řízení rizik (Risk Management) – business by měl mít určitou záruku, že investice nebude zmařena, a proto by měla být řízena rizika spojená s provozem, pořízením a vývojem.
• Měření výkonnosti (Performance Measurement) – Aby byla zajištěna požadovaná kvalita, je nutné služby a procesy měřit, vyhodnocovat a optimalizovat. Nezapomínejte, že pokud něco nejste schopni měřit, nemůžete to řídit.

Za pilíře IT governance lze označit: 

• strategii – jasně formulovaná strategie vycházející z cílů společnosti,
• procesy – správně navržené a dobře fungující procesy,
• organizační strukturu – vhodná organizační struktura,
• zdroje – odpovídající infrastruktura, aplikace, lidé,
• katalog služeb – seznam služeb, které IT poskytuje,
• SLA – správně sepsaná smlouva o dodávce služeb,
• metriky – jasná kritéria a pravidla měření výkonnosti.

Závěr: Business požadavky vedou k investicím do IT zdrojů (to znamená do infrastruktury, aplikací, lidí.) Tyto zdroje jsou pak využívány v rámci procesů, které by měly businessu poskytnout služby a informace, díky kterým může business dosáhnout svých cílů. Procesy, zdroje a cíle musí být systematicky vyhodnocovány, stejně jako rizika, kterým musí společnost čelit, jedině tak lze zajistit, že zdroje budou efektivně využívány. Zavedení metodik typu COBIT nebo ITIL by nemělo být cílem, ale pouze prostředkem k dosažení daného cíle.

Related posts:

1. COBIT tajemství zbavený

Metodika CobiT (Control OBjectives for Information and related Technology) je považována za soubor těch nejlepších praktik pro řízení informatiky (IT Governance), které by měly umožnit dosažení strategických cílů organizace díky efektivnímu využití dostupných zdrojů a minimalizaci IT rizik.

Metodika CobiT Je určena především pro executive management a osoby provádějící audit. Poprvé byla vydána v roce 1996 organizací ISACA. První vydání zahrnovalo rámec metodiky (framework). Ve druhém vydání z roku 1998 přibyly auditní postupy (audit guidelines), sada implementačních nástrojů (implementation toolset) a rozpracované procesy a detailní cíle (control objectives). Ve třetím vydání z roku 2000 přibyly manažerské postupy (management guidelines) a byl inovován rámec metodiky, tentokrát však již pod hlavičkou ITGI (IT Governance Institute), což je nezisková organizace založená ISACA. Ve verzi 4.0 z roku 2005 bylo těchto několik dokumentů sloučeno do jednoho, což byl velice rozumný krok a konečně v roce 2007 vyšel CobiT ve verzi 4.1 o rozsahu 213 stran, který rozděluje IT do 4 domén, které zároveň tvoří i hlavní kapitoly knihy, v rámci kterých je popsáno 34 procesů:

• Plánování a organizace (Plan and Organise) – 10 procesů:
  • PO1 Define a strategic IT plan.
  • PO2 Define the information architecture.
  • PO3 Determine technological direction.
  • PO4 Define the IT processes, organisation and relationships.
  • PO5 Manage the IT investment.
  • PO6 Communicate management aims and direction.
  • PO7 Manage IT human resources.
  • PO8 Manage quality.
  • PO9 Assess and manage IT risks.
  • PO10 Manage projects.
• Akvizice a implementace (Acquire and Implement) – 7 procesů:
  • AI1 Identify automated solutions.
  • AI2 Acquire and maintain application software.
  • AI3 Acquire and maintain technology infrastructure.
  • AI4 Enable operation and use.
  • AI5 Procure IT resources.
  • AI6 Manage changes.
  • AI7 Install and accredit solutions and changes.
• Dodání a podpora (Deliver and Support) – 13 procesů:
  • DS1 Define and manage service levels.
  • DS2 Manage third-party services.
  • DS3 Manage performance and capacity.
  • DS4 Ensure continuous service.
  • DS5 Ensure systems security.
  • DS6 Identify and allocate costs.
  • DS7 Educate and train users.
  • DS8 Manage service desk and incidents.
  • DS9 Manage the configuration.
  • DS10 Manage problems.
  • DS11 Manage data.
  • DS12 Manage the physical environment.
  • DS13 Manage operations.
• Monitorování a vyhodnocování (Monitor and Evaluate) – 4 procesy:
  • ME1 Monitor and evaluate IT performance.
  • ME2 Monitor and evaluate internal control.
  • ME3 Ensure compliance with external requirements.
  • ME4 Provide IT governance.

Pokud se podíváme na zaměření jednotlivých domén, nemůže naší pozornosti ujít, že se ve své podstatě nejedná o nic jiného než klasický PDCA cyklus, kde Demingově fázi PLAN odpovídá Plánování a organizace (Plan and Organise), fáze DO je zastoupena doménou Akvizice a implementace (Acquire and Implement) + Poskytování a podpora (Deliver and Support) a posledním dvěma fázím CHECK+ACT odpovídá doména Monitorování a vyhodnocování (Monitor and Evaluate).

COBIT podobně jako ITIL vychází ze skutečnosti, že aby podnik mohl dosahovat svých cílů (Business goals), vznáší business požadavky (Business Requirements), které generují požadavky na IT zdroje (IT resources), jež jsou zapojeny do IT procesů (IT processes) přinášející businessu požadovanou službu a informace (Enterprise Information). Dle COBIT by měly informace, která IT poskytuje, splňovat těchto 7 kritérií: 

• důvěrnost (confidentiality) – požadavky zahrnující oblast ochrany důležitých informací proti neautorizovanému použití (prozrazení);
• integrita (integrity) – požadavky týkající se přesnosti a kompletnosti informace ve vztahu k požadavkům podnikání a jeho očekáváním;
• dostupnost (availability) – požadavky vztahující se k dostupnosti informace pro podnikání (nyní, ale i v budoucnosti). A dále požadavky na ochranu potřebných zdrojů (např. datových, technologických);
• efektivita/účelnost/účinnost (effectiveness) – požadavky na včasné doručování relevantních informací ve správném, konzistentním a použitelném tvaru;
• hospodárnost (efficiency) – požadavky na zpracování informací (nejekonomičtějším a nejproduktivnějším způsobem) prostřednictvím optimálního využívání zdrojů informatiky;
• soulad (compliance) – požadavky týkající se udržování souladu se zákony, regulacemi, směrnicemi a kontraktačními podmínkami, které se týkají procesů podnikání (hlavních podnikových procesů);
• spolehlivost (reliability) – požadavky vztahující se k přínosu informace pro rozhodování manažerů. 

Splnit tato kritéria je však možné pouze v okamžiku, kdy IT disponuje potřebnými zdroji a má zavedené odpovídající procesy. V CobiT jsou každému procesu věnovány obvykle 4 strany. Na první straně pojmenované Process Description je proces vždy stručně na několika málo řádcích popsán. U každého procesu je uvedeno, jaký požadavek resp. potřebu podniku daný proces pomáhá uspokojovat a na co se proces zaměřuje resp. co je jeho cílem a jak tohoto cíle dosáhnout a jak ho měřit. Vzhledem k tomu, že k realizaci procesu jsou obvykle potřeba následující zdroje: 

• aplikace,
• infrastruktura (HW, SW, OS, síť),
• lidé a
• informace

a ne vždy je potřeba je zapojit všechny, tak CobiT u každého procesu uvádí, které přesně to jsou. Poté následuje strana pojmenovaná Control Objectives, která se věnuje popisu cílů opatření, obvykle nepřesahujících jednu stranu. Na další straně, pojmenované Management Guidelines, jsou pak vyjmenovány vstupy (inputs) a výstupy (outputs) z daného procesu a z jakých činností se celý proces skládá. Ve formě RACI tabulky (RACI chart) je zachycen vztah mezi jednotlivými činnostmi (activities) a funkcemi (functions), které: 

• dané činnosti fyzicky vykonávají (Responsible),
• nesou za splnění odpovědnost (Accountable),
• je potřeba s nimi postup konzultovat (Consulted),
• včas je informovat (Informed).

U všech procesů jsou uvedeny stejné funkce a to: CIO, CFO, CEO, Business Executive, Business Process Owner, Head Operations, Chief Architect, Head Development, Head IT Administration, PMO, Compliance – Audit – Risk and Security. Na téže straně je pak schematicky znázorněn vztah mezi cíly a metrikami (Goals and Metrics), procesy a činnostmi a popsán způsob, jak je měřit. Poslední čtvrtá strana, pojmenovaná Maturity Model, se věnuje popisu jednotlivých stupňů vyzrálosti a poskytuje též návod jak vyzrálost daného procesu vyhodnotit. Je zřejmé, že musíme také sledovat a měřit jak jsou dosahovány cíle aktivit, procesů, IT a businessu. Kromě konkrétních cílů je pro každý proces definováno šest obecných cílů, které jsou označeny zkratkou PC+číslo a pro aplikace analogicky AC+číslo.

Závěr: S publikací CobiT se velice dobře pracuje a člověk se v ní rychle orientuje, neboť vše je vyvedeno přehledné tabelární formě s pevně danou strukturou. Nicméně přes výše uvedené skutečnosti se nemohu ubránit dojmu, že z celého řízení informatiky se dělá až příliš velká věda a CobiT je navíc psán jazykem, kterým běžný CIO prostě nehovoří, což snazšímu zavedení IT Governance nepřispívá a CobiT se tak stává pouhým nástrojem v rukou auditorů, bohužel.

Poznámka: V CobiT se mimo jiné také dočtete, že vaše cíle by měly být SMARRT (Specific, Measurable, Actionable, Realistic, Results-oriented, Timely). Přitom donedávna všem stačilo, když jejich cíle byly SMART;-) Jsem zvědav, s čím na nás pánové vyrukují v další verzi CobiT, na které se intenzivně pracuje.

A jaké jsou vaše zkušenosti s metodikou CobiT?

Related posts:

1. ITIL tajemství zbavený
2. IT Governance

Kromě běžných náležitostí jako je identifikace smluvních stran, místo plnění smlouvy apod., by ve smlouvě o outsourcingu mělo být uvedeno, jaké služby a v jaké kvalitě se společnost zavazuje dodávat, jak bude probíhat vyhodnocování kvality těchto služeb, jaká je cena za tyto služby a jaké jsou sankce v případě neplnění. Nezapomínejte také do smlouvy uvést, jaká je hodinová sazba za služby, které ve smlouvě uvedeny nejsou. Smlouva o outsourcingu (Service Level Agreement), zkráceně SLA by měla obsahovat minimálně: 

• rozsah služeb
• popis metrik
• cílové hodnoty
• přípustné odchylky
• způsob měření
• ceny za služby
• sankce a prémie
• závazky a záruky
• přechod procesu na poskytovatele
• délku smluvního vztahu
• řízení dalšího vztahu
• ukončení smluvního vztahu

Výše uvedený výčet se nesnaží být vyčerpávající nebo definovat pořadí jednotlivých kapitol SLA. Vždy je třeba se zamyslet nad tím, zda smlouva pamatuje na možná rizika. Např. pokud je předmětem SLA vývoj SW, neměli byste zapomenout smluvně ošetřit vlastnictví zdrojových kódů. Pokud uvažujeme o outsourcingu ICT, pravděpodobně bude předmětem SLA minimálně jedna z následujících oblastí: 

• Správu a rozvoj infrastruktury
• Podpora vybraných aplikací
• Podpora koncových uživatelů
• Vývoj SW

Předpokladem pro uzavření kvalitní SLA je identifikace, analýza a popis jednotlivých procesů, během kterého dochází k vytváření tzv. process maps. Podstatnou součástí popisu procesů by mělo být popsání jeho jednotlivých fází a počtu pracovníků, kteří se na nich podílí a především jaké tento proces generuje náklady. Pokud nejsme schopni popsat stávající proces, nejenže nebudeme schopni popsat, co vlastně chceme, ale nebudeme ani schopni objektivně posoudit zda by převedením procesu na poskytovatele došlo ke zlepšení procesu a snížení nákladů na základě předložených nabídek. Při hodnocení nabídek potenciálních dodavatelů by měly být vzaty v úvahy minimálně tyto faktory:

• Kvalita předložené nabídky – míra detailu do jaké potenciální partner popsal jednotlivé služby. Tím si ověřujeme, že rozumí tomu, jaké služby od něho požadujeme.
• Spolehlivost dodavatele – více než sledování nejrůznějších certifikací doporučuji věnovat dostatek času ověření referencí, neboť certifikace se dají koupit.
• Cena – v podstatě se jedná o hlavní kritérium, které rozhoduje v naprosté většině případů o tom, zda se společnost rozhodne danou službu zajišťovat vlastními prostředky nebo ji koupí jinde.

Nezapomínejte také na revizi SLA, neboť ICT je oblast, která se neuvěřitelně rychle vyvíjí, lehce se tak může stát, že budete vyplácet prémie za něco, co už je dávno standardem nebo platit za poskytované služby mnohem více, než je současná tržní cena. Outsourcing lze ve své nejjednodušší podobě schématicky znázornit takto:

• Operation – jedná se o zajištění běžného provozu, kterým může být vývoj SW, podpora aplikací a uživatelů, správa a rozvoj infrastruktury ať už vlastními prostředky nebo externím poskytovatelem této služby.
• Discovery – zjištění, analýza a popis procesů, návrh procesu po jeho vytěsnění a smluvní podmínky, kterému předchází oslovení možných partnerů, analýza a vyhodnocení předložených nabídek a výběr dodavatele.
• Transition – předání daného procesu dodavateli.

Poznámka: Outsourcing se obvykle realizuje jako projekt. A po skončení tohoto projektu zpravidla dochází k propuštění zaměstnanců na pozicích, které byly předmětem outsourcingu. Tato známá skutečnost může v zaměstnancích vyvolat averzi vůči této změně a snahu celý projekt outsourcingu bojkotovat. Určitým řešením je outplacement tj. převedení těchto zaměstnanců k externímu poskytovateli. Pokud jde o management, tomu je vhodné nabídnout významné posty u dodavatele. V neposlední řadě by měl být sponzorem projektu manažer nacházející se minimálně o dvě úrovně výše než je útvar, kterého se outsourcing dotkne. V opačném případě nebude mít zájem na úspěšné realizaci projektu, protože se bude cítit ohrožen.

Related posts:

1. Outsourcing ICT: rizika o kterých se nemluví
2. Senior specialista ICT Outsourcing – Praha

Jako vůbec nejčastější důvod se uvádí, že společnost, která se rozhodne některé své činnosti, jež nesouvisí přímo s předmětem jejího podnikání, svěřit jiné, na danou činnost se specializující společnosti, se pak bude moci plně soustředit jen na svůj business a dosáhnout tak lepších hospodářských výsledků a obstát v boji s konkurencí. Je tomu ale opravdu tak?

Hlavním a ve většině případů často také jediným důvodem, který mnohé společnosti vede k rozhodnutí některé své činnosti outsourcovat (převést na externího dodavatele), jsou zpravidla nižší náklady na zajištění dané činnosti prostřednictvím outsourcingového partnera. Mezi činnosti, které lze outsourcovat patří samozřejmě i IT. Rozhodnutí zda danou činnost outsourcovat nebo nikoliv vychází nejčastěji z následujícího obrázku.

Obrázek se snaží zachytit skutečnost, že běžnou opakující se činnost můžeme snadno převést na jinou společnost, která se na ní specializuje (1). Naproti tomu opakující specifickou činnost je lepší si ponechat, protože na trhu pravděpodobně nenajdeme partnera, který by byl schopen ji pro nás v požadované kvalitě a ceně zajistit (2). Na činnost, která je sice běžná, ale provádíme ji jen výjimečně, si můžeme vždycky někoho najmout (3). A konečně na činnost, která se vykonává jen zřídka a je specifická, můžeme využít služeb nejrůznějších konzultačních firem (4).

Položme si nyní otázku, jakým způsobem může specializovaná firma dosáhnout nižších nákladů? Možností je vskutku celá řada, ostatně v příspěvku jak snížit náklady na IT jich je pár desítek uvedeno. Stejný přístup ke snížení nákladů by mohla samozřejmě volit přímo i společnost, která o outsourcingu uvažuje, nicméně ta obvykle není schopna příslušné změny, které by vedly ke snížení nákladů, realizovat. Je však outsourcing IT výhodný i v případě, že společnost již realizovala řadu kroků, které vedly ke snížení nákladů na IT? Může i v takovém případě outsourcingový partner dosáhnout ještě nižších nákladů? Jistěže může, ale je s tím spojeno několik ne zcela zanedbatelných rizik.

Zneužití informací
Jednou z možností jak mít nižší náklady jsou tzv. úspory z rozsahu. Těch však běžná společnost obvykle nemůže zcela využít. Ne však outsourcingový partner, který se obvykle nenachází v pozici monopsonu. To znamená, že odběratelem jeho služeb není jediná společnost, ale zpravidla své služby poskytuje minimálně několika dalším společnostem. To mu umožňuje využívat nejrůznějších množstevních slev na vybrané HW a SW produkty a jiných výhod. Právě skutečnost, že se outsourcingový partner nenachází v pozici monopsonu, ale své služby poskytuje více společnostem, představuje riziko, že např. SW produkt, který pro vás na zakázku vyvíjí a jehož vývoj vy platíte, může být nabídnut i vaší konkurenci, se kterou má též uzavřenou smlouvu o poskytování služeb. Posloužili jste tak v podstatě jako pokusný králík a konkurenční výhoda spojená s nasazením produktu je nejistá, protože u konkurence může být pro vás vyvinutý SW produkt nasazen s jiným designem jen o něco později a s nižšími náklady.

Horší kvalita poskytovaných služeb
Dalším často uváděným tvrzením je, že outsourcingový partner dokáže dodat požadovanou službu minimálně ve stejné kvalitě a za nižší cenu. Kromě již zmíněných úspor z rozsahu dosahuje poskytovatel služeb nižší ceny i díky nižším mzdovým nákladům. (Společnost může mít dokonce i vyšší mzdové náklady, které ale bývají kompenzovány výnosy.) Jak je to ale možné, když je obecně známo a nejrůznější průzkumy výše platů v IT to i potvrzují, že platy IT pracovníků ve firmách, kde IT není hlavním předmětem podnikání, jsou obvykle nižší než ve firmách, které IT služby poskytují? No, obvykle se to řeší tak, že outsourcingová společnost má několik expertů a pak velké množství externistů (rozuměj brigádníků – studentů). Má tedy k dispozici dostatečný počet osob pro plnění dodávky podle smlouvy. Ale zvýše uvedeného důvodu vám těžko může zaručit požadovanou úroveň kvality poskytovaných služeb, ač ve smlouvě, kterou s vámi uzavřela, se k tomu zavazuje. Je tomu tak prostě proto, že jinak by musela zaměstnávat stejný počet expertů jako jste zaměstnávali vy a pak by logicky nemohla být v této oblasti lacinější. Jinými slovy, dnes může váš server spravovat expert, zatímco zítra to může být student, který u dané společnosti nastoupil na brigádu, protože expert je na dovolené nebo řeší složitější problém u jiného zákazníka. Při výběru vhodného dodavatele je třeba se zajímat i o to, jaká je fluktuace jeho zaměstnanců. Pokud se fluktuace v dané společnosti pohybuje v řádu několika desítek procent, měl by to pro vás být jasný signál, že v dané společnosti není něco v pořádku a na kvalitu jejich služeb se nemůžete absolutně spolehnout.

Dražší služby
Časem se můžete stát pro společnost, která vám IT služby poskytuje, dojnou krávou, protože se na ní respektive na jejich produktech stanete zcela závislí. Vaše náklady pak budou naopak růst a vy si toho nebudete ani vědomi, protože vy bona fide koupíte všechno, co vám doporučí. Stejně tak vás outsourcer nebude přesvědčovat o tom, že to co chcete, vlastně vůbec nepotřebujete nebo že byste to mohli jinde pořídit laciněji. Naopak, danou službu vám velice rád poskytne nebo příslušný SW produkt ochotně vyvine, protože vy mu za to dobře zaplatíte. V době, kdy jste měli vlastní IT tomu tak docela nebylo, protože to bylo zainteresováno na vašem zisku, aspoň doufám. Také problémy a požadavky nebudete moci řešit s outsourcingovým partnerem tak, jak jste byli doposud zvyklí se svým IT, tj. ústně dohodou. Právě naopak, na všechno bude papír a byrokracie výrazně vzroste, neboť všechno bude muset být zdokumentováno a schváleno. V ekonomii se tomu říká transakční náklady a ty mohou být značné. Počítejte s tím, že za všechno zaplatíte, protože postupně budete zjišťovat, že to co potřebujete, není součástí smlouvy o outsourcingu. Problém je, že v okamžiku, kdy se uzavírá smlouva o outsourcingu, si spousta společností neuvědomuje, co všechno jejich IT dělá, resp. jaké služby poskytuje. To je mimo jiné dáno i tím, že téměř žádná společnost nemá zavedeny všechny procesy tak, jak je popisuje např. ITIL a též katalog služeb poskytovaných jejich ICT je neúplný. To je dáno např. tím, že zavedení některých procesů by pro ně bylo příliš nákladné a návratnost mizivá. Profesionální poskytovatel služeb však většinou procesů zavedených má, protože se mu to vyplatí.

Závěr: To, že outsourcing je vždy výhodný, je mýtus. Problém spočívá i v tom, že spousta manažerů rozhodujících o outsourcingu nemá dostatek znalostí v této oblasti a není schopna sepsat RFP a vybrat toho nejvhodnějšího dodavatele a uzavřít kvalitní SLA. V takovém případě mohou být některé služby dokonce dražší, neboť outsourcingový partner nikdy neudělá víc, než má uvedeno ve smlouvě a také transakční náklady mohou představovat nezanedbatelnou položku v cenové kalkulaci. Zapomínat byste neměli také na to, že outsourcingový partner může informace, ke kterým se dostal, prodat konkurenci stejně jako produkt, který pro vás vyvíjel.

Related posts:

1. Outsourcing ICT: uzavíráme SLA
2. Senior specialista ICT Outsourcing – Praha

Otestujte si svého potenciálního zaměstnavatele a zkuste se ho např. u přijímacího pohovoru zeptat, zda budete moci využívat k soukromým účelům přidělené auto, notebook, mobilní telefon a konektivitu do internetu.  Dle zákona č. 262/2006 Sb., zákoník práce, Část třináctá – Společná ustanovení, Hlava VIII: Ochrana majetkových zájmů zaměstnavatele a ochrana osobních práv zaměstnance a § 316 odstavce 1 totiž: “Zaměstnanci nesmějí bez souhlasu zaměstnavatele užívat pro svou osobní potřebu výrobní a pracovní prostředky zaměstnavatele včetně výpočetní techniky ani jeho telekomunikační zařízení.” Ať je postoj zaměstnavatele jakýkoliv, je vhodné to vědět, můžete se tím vyhnout nepříjemnému překvapení v podobě výpovědi z důvodu porušení zákoníku práce.

Automobil
Nebývá to tak časté, ale na některých pozicích bývá zaměstnancům nabízen jako benefit služební automobil. Ve služebním automobilu však i přes možnost jeho využití k soukromým účelům spatřují někteří zaměstnanci ztrátu soukromí, neboť zaměstnavatel v případě, že vám dá automobil k dispozici, očekává, že budete připraveni se na pracoviště dostavit kdykoliv, kdy vám zavolá.

Mobilní telefon
Dalším, dnes již poměrně častým, benefitem bývá mobilní telefon s možností využít ho i k soukromým hovorům. Na prvním pohled to nemusí být špatné, ale setkal jsem se spoustou případů, že zaměstnanec o tento benefit prostě nestál. Mobilní telefon již měl, a měl i zaplacený tarif. Ve služebním mobilu viděl spíše ztrátu soukromí. Zaměstnavatelé totiž často zaměstnance nutí, aby ho měli zapnutý pořád a to i po skončení pracovní doby a o víkendu.

Notebook
Dalším často nabízeným benefitem je služební notebook, ale zkuste na něm pracovat 8 hodin. Bez docking station, externí klávesnice, myši a velkého LCD displeje je taková práce spíše utrpením. A to už vůbec nemluvím o vývojářích, kteří by měli mít k dispozici dokonce dva velké LCD displeje. Na jednom by měli vyvíjet a na druhém by měli mít zobrazenou specifikaci. Jen v takovém případě lze hovořit o efektivitě.

Internet
Brent Coker z katedry managementu a marketingu Melbournské univerzity tvrdí, že krátké přestávky včetně surfování na internetu vedou k celkové vyšší koncentraci během pracovního dne a výsledkem je až o 9% vyšší produktivita práce. Předpokladem pozitivního vlivu na zvýšení produktivity práce je ale omezená doba surfování, ta by neměla překročit 20% celkové pracovní doby. Je zvláštní, že ač kouření v pracovní době zaměstnavatelům evidentně nevadí, neboť zatímco účelem často zřizují a vyznačují prostory, kde je kouření povoleno, tak v okamžiku, kdy přijde řeč na surfování po internetu v pracovní době, jsou proti. A přitom kouření je pro zdraví člověka mnohem škodlivější.

Benefit nebo nutnost?
Automobil, služební telefon, notebook a přístup na internet není možné např. na pozici manažera, servisního technika nebo obchodního zástupce v dnešní době považovat za benefit. Je to prostě nutnost, aby tento pracovník mohl vůbec vykonávat svoji práci.

Použitelnost
Vraťme se však ještě jednou k notebookům, protože zde je patrný jasný trend v pořizování těchto zařízení i tam, kde donedávna vládly klasické desktopy. Ve svém minulém příspěvku jsem se zmínil o programu BYOC. Tato služba je založena na virtualizaci desktopů, takže je poměrně bezpečná. V první řadě jde samozřejmě o pohodlí a efektivitu. Vychází se z jednoduché úvahy, proč používat dva telefony, dvě auta a dva počítače, když by stačil jeden telefon, jedno auto a jeden počítač. Pro zaměstnavatele je jistě výhodnější, když platí náklady spojené s užitím dané věci pouze pro služební účely. Zaměstnanec si těchto věcí více váží a i je lépe opatruje, protože ví, že v případě jejich poškození nebo ztráty bude mít problémy i ve svém soukromém životě, neboť nedojede tam, kam potřebuje, nezatelefonuje si, kdy bude potřebovat a nebude si moci stáhnout poštu.

Náklady
Co se týká nákladů, nemyslím si, že by se to nevyplatilo. Životnost HW se běžně uvádí 3 roky. Každé 3 roky tak může zaměstnanec, který chce používat svůj vlastní počítač, obdržet určitou částku, řekněme třeba 1500 euro, na nákup nového zařízení. Samozřejmostí je, že nově kupovaný HW musí splňovat určité požadavky (např. musí být stanovena minimální HW konfigurace). Co se týká údržby, může útvar servisní podpory pracovat naprosto stejně jako dosud. Kromě toho může za úplatu poskytovat i služby pro soukromé užití. Co se týká SW, není problém připravit image pro virtuální desktop, který bude obsahovat veškerý pro práci potřebný SW včetně VPN pro sestavení připojení pro práci z domova.

Bezpečnost
Častým argumentem proti používání soukromých zařízení pro práci a tedy připojování do interní sítě zaměstnavatele je zvýšené riziko narušení důvěrnosti, dostupnosti a integrity dat v důsledku zavlečení škodlivého kódu a úniku důvěrných informací. To je jistě pravda, ale na druhou stranu si musíme přiznat, že cest jak škodlivý kód do společnosti zavléci nebo důvěrné informace odnést, je spousta, viz článek „Data loss protection: krádež dat“ a tohle je tedy jen jedna z nich. Navíc existují řešení, jak toto riziko eliminovat, spočívají např. v nasazení technologie 802.1x a NAC a filtrováním webu. S použitím těchto technologií je možné umožnit připojení jen těch zařízení, která splňují určité požadavky, je na nich např. certifikát, a aktuální verze antivirové ochrany, aktivován personální firewall, poslední verze OS včetně bezpečnostních záplat. Dalším řešením je též virtuální stroj, ve kterém bude spuštěn firemní OS včetně příslušných politik. V důsledku oddělení těchto prostředí nemůže dojít k šíření nežádoucího kódu do vnitřní sítě společnosti a mohou tak být na jednom počítači spouštěna 2 různá prostředí, využívána ke zcela rozdílným účelům.

A jaký je váš názor na program BYOC?

Related posts:

1. Lesk a bída HR v ČR: práce z domova

Informace uvedené v ITIL (Information Technology Infrustructure Library) vycházejí ze zkušeností „best practice“ mnoha společností na celém světě. Jedná se de-facto o mezinárodní standard pro řízení IT služeb (IT Service Management).

ITIL byl publikován poprvé v letech 1989 – 1995 u Her Majesty’s Stationery Office (HMSO) v UK se jménem Central Communications and Telecommunications Agency (CCTA) – dnešní Office of Government Commerce (OGC) a měl podobu 31 knih. (Docela by mě zajímalo, jestli to někdo kromě autorů a recenzentů opravdu celé důkladně přečetl a pak podle toho ty procesy zaváděl;-) V letech 2000 – 2004 byla původní verze revidována a následně vyšel ITIL verze 2, který čítal již jen 7 knih. V roce 2007 se objevuje ITIL verze 3, sestávající z 5 knih, které kopírují životní cyklus služby:

• Service Strategy (Strategie služeb) – tato kniha se zabývá tím, čemu se říká IT Governance a je určena spíše pro osoby, které se nacházejí na pozici CIO a popisuje tyto procesy:
  • Financial Management (správa financí)
  • Service Portfolio Management (správa portfolia služeb)
  • Demand Management (správa požadavků)
• Service Design (Návrh služeb) – Cílem je navrhnout takové služby, které dokáží uspokojit současné i budoucí požadavky businessu.
  • Service Catalogue Management  (správa katalogu služeb)
  • Service Level Management (správa úrovně služeb
  • Capacity Management (správa kapacit)
  • Availability Management (správa dostupnosti)
  • IT Service Continuity Management (správa kontinuity služeb IT)
  • Information Security Management (správa bezpečnosti informací)
  • Supplier Management (správa dodavatelů)
• Service Transition (Přechod služeb) zavedení služby – cílem je dodat služby požadované businessem do produkčního prostředí. Kniha popisuje tyto procesy:
  • Change Management (správa změn)
  • Service Asset and Configuration Management (správa aktiv a konfigurace)
  • Knowledge Management (správa znalostí)
  • Transition Planning and Support (Plánování a podpora přechodu)
  • Release and Deployment Management (správa releasů a nasazení)
  • Service Validation and Testing (ověření a testování služby)
  • Evaluation (Vyhodnocení)
• Service Operation (Provoz služeb) – cílem je dodávat služby v požadované kvalitě. Kniha popisuje tyto procesy:
  • Event Management (správa událostí)
  • Incident Management (správa incidentů)
  • Problem Management (správa problémů)
  • Access Management (správa přístupů)
  • Request Fullfilment (provádění požadavků)
  • IT Operation Management (správa provozu IT)
  • Application Management (správa aplikací)
  • Technical Management (technická správa)
• Continual Service Improvement (Neustálé zlepšování služeb)
  • Service Measurement (měření služeb)
  • Service Reporting (vykazování služeb)

ITIL v jednotlivých knihách popisuje procesy, které IT většinou musí vykonávat, aby vůbec mohlo fungovat a nějaké služby businessu poskytovat. ITIL se snaží dívat na poskytované služby z pohledu zákazníka, který dané služby odebírá. Předpokládá se a výsledky mnohých studií to i potvrzují, že společnosti, které své procesy zavedly podle ITIL, dosahují vyšší efektivity a jejich zákazníci mají větší záruku, že služba, za kterou platí, bude splňovat parametry uvedené v SLA. Další výhoda zavedení procesů podle ITIL spočívá v tom, že společnosti v takovém případě používají stejnou terminologii a měly by se tak díky ní lépe dorozumět se svými partnery a zákazníky. Spousta nedorozumění totiž dost často vyplývá z toho, že mnohé společnosti jen používají rozdílné pojmy pro pojmenování stejných skutečností nebo naopak stejný termín pro různé skutečnosti. Myšlenka ITIL je celkem jednoduchá, proč navrhovat a vymýšlet celý proces znovu od začátku, když už ho spousta jiných firem má zavedený a průběžně ho i vylepšuje. Bohužel, některé společnosti ITIL nepochopily a moc dobrou reklamu mu neudělaly. Spousta manažerů tak k němu přistupuje s určitými předsudky. O nejhorších zkušenostech „worst practices“ se zaváděním ITIL koneckonců pojednává i kniha ABC of ICT.

ITIL popisuje vazby mezi jednotlivými procesy a definuje jaké by měly být vstupy, výstupy, role a metriky. Vzhledem k tomu, že nositeli každého procesu jsou lidé, musí být jasně určeno, kdo za co odpovídá. V ITIL se používá pojem role, ta je přiřazena člověku nebo týmu, který pak v rámci daného procesu vykonává jednu nebo více činností. Je zřejmé, že pokud má daná role vykonávat příslušnou činnost, musí mít nejen požadované schopnosti, ale potřebuje k tomu též nástroje tj. HW, SW a musí být vybavena i odpovídajícími pravomocemi a nést určitou odpovědnost. ITIL doporučuje pro každý proces vytvořit tzv. RACI tabulku, která v záhlaví bude obsahovat role a v řádcích jednotlivé činnosti, které se musí v rámci procesu vykonat. U každé činnosti by mělo být uvedeno, kdo ji vykonává (Responsible), kdo je odpovědný za výsledek (Accountable), s kým je nutno postup konzultovat (Consult) a koho je třeba informovat (Inform). Pro úplnost je třeba dodat, že ITIL používá ještě pojem funkce a myslí tím organizační jednotku nebo tým, který určitý proces nebo aktivity v rámci daného procesu vykonává. Ač je všech pět knih, které tvoří jádro ITIL poměrně rozsáhlých – každá čítá několik set stran, detailní popis procesů v nich přesto nenajdete, neboť ITIL popisuje jen hlavní aktivity v rámci daných procesů.

Procesy ITIL snadno a rychle

Pro snadné pochopení a seznámení se jednotlivými procesy, které ITIL popisuje, si uvedeme konkrétní příklad. Uživateli nefunguje aplikace a závadu hlásí na Service Desk (z pohledu ITIL je Service Desk funkce, jejíž pojem jsme si definovali výše). Service Desk zakládá ve svém systému tzv. incident, který řeší v rámci procesu Incident Management. Tento incident však byl IT již jednou řešen a způsob řešení byl příslušným pracovníkem popsán a díky výstupům z procesu Knowledge Management operátor Service Desku snadno dohledá, že existuje řešení v podobě workaroundu, takže služba (rozuměj funkčnost aplikace) může být obnovena velice rychle (ITIL o všem co IT poskytuje hovoří jako o službě) v souladu s uzavřeným SLA a incident může být uzavřen. Vše co souvisí SLA je řešeno v rámci procesu Service Level Management. Vzhledem k tomu, že stále více uživatelů hlásí na Service Desk stejnou závadu, rozhodne se Service Desk založit ke stávajícím incidentům tzv. „problem“, který by měl odhalit skutečnou příčinu závady. Tím se startuje proces Problem Management. Ještě téhož dne je příčina závady odhalena. Bude nutné přepsat kód jedné knihovny, kterou aplikace používá. Tím se rozjíždí proces Change Management. Úprava knihovny vývojářům netrvala dlouho. Po důkladném otestování je k dispozici nová verze, která může být nasazena nejen na stanice postižených uživatelů, ale všem, kteří aplikaci používají. Uvolnění a nasazení nové verze popisuje proces Release and Deployment Management. IT musí vědět, na jakých stanicích je daná aplikace nainstalována, aby mohlo provést její upgrade na novou verzi. Vzhledem k tomu, že naše IT má zaveden proces Service Asset and Configuration management, má přehled nejen o veškerém majetku, ale i o vazbách mezí jednotlivými komponentami, takže to pro něj nebude problém. V okamžiku, kdy je na všech stanicích nainstalována nová verze aplikace, objeví se tato informace i v databázi Asset and Configuration Management nástroje a Service Desk „problem“ uzavírá. Ve stejnou dobu však do firmy nastupuje nový zaměstnanec a jeho manažer žádá o instalaci aplikace, kterou našel v katalogu služeb, které IT nabízí. Netřeba asi dodávat, že katalog je udržován v rámci procesu Service Catalogue Management.  Tento požadavek již nemusí nikdo další schvalovat a tak je tento požadavek řešen v rámci procesu Request Fullfilment. Prostřednictvím aplikace však uživatel přistupuje k datům o zákaznicích firmy a proto musí být jeho přístup k datům řízen. Manažer proto o příslušné přístupy požádá v rámci procesu Access Management. V aplikaci pracuje velké množství uživatelů a databáze, kterou aplikace využívá, obsahuje čím dál tím více dat. Je zřejmé, že stávající HW nebude v brzké době stačit a bude nutné provést upgrade dříve, než systém spadne. Je zřejmé, že se není možné soustředit jen na zajištění aktuální dostupnosti IT služeb v rámci procesu Availability Management, ale je nutné myslet i na budoucnost a včas alokovat potřebné zdroje, čemuž by se měli věnovat odpovědní pracovníci v rámci procesu Capacity Management. Toto IT však nechce spoléhat jen na to, že incident někdo nahlásí, ale raději by incidentům předešlo a proto používá monitorovací nástroje, které odpovědným pracovníkům zasílají hlášení o nestandardních událostech v systému, toto se řeší v rámci procesu Event Management. Firma si je vědoma, že v jejich systémech jsou obsažena cenná data, která ohodnotila v rámci Business Impact Analysis a proto věnuje dostatek pozornosti vypracování plánů kontinuity pro případ útoku, havárie nebo přírodní katastrofy v rámci procesu IT Service Continuity Management. Mnohým bezpečnostním incidentům však může společnost předejít implementací základní sady opatření v rámci procesu Information Security Management, jehož cílem je zajistit bezpečnost informací během celého jejich životního cyklu. Ne všechny služby si je však firma schopna zajistit sama a proto využívá služeb mnoha různých dodavatelů, které řídí v rámci procesu Supplier management. Aby IT mohlo dodávat službu, kterou si zákazník objednal musí se věnovat běžné správě a o tom pojednává proces IT Operations Management. Návrhu infrastruktury se věnuje proces Technical Management, samotným aplikacím se pak logicky věnuje proces Application Management. Je zřejmé, že všechno něco stojí a někdo musí finance spravovat a na to máme proces Financial Management. Pokud jde o proklamované soustavné zlepšování, nejedná se v podstatě o nic jiného než o klasický Demingův PDCA cyklus uplatňovaný na všechny procesy a služby, jejichž vyzrálost můžeme měřit např. za použití CMM (Capability Maturity Model) v rámci procesu Service Measurement a výsledky těchto měření poté analyzovat a prezentovat v rámci procesu Service Reporting.

Certifikace ITIL

Pokud se připravujete na zkoušku prvního stupně, tak vězte, že je koncipována tak, že se nesnaží zjistit, zda uchazeč o certifikaci procesům ITIL rozumí, ale zda zná přesný význam pojmů v ITIL používaných. A výklad některých pojmů v ITIL je značně kostrbatý, např. takto je definována služba: „Služba je prostředek dodávání hodnoty zákazníkovi tím, že zprostředkovává výstupy, jichž chce zákazník dosáhnout, aniž by vlastnil specifické náklady a rizika.“ A na vině není překlad, neboť ten je perfektní, takhle kostrbatě je to uvedeno i v originálu: „A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.“ Jestli si myslíte, že je to náhoda a ostatní pojmy jsou již popsány srozumitelněji, musím vás vyvést z omylu. Stejně složitě je definován i pojem Správa služeb, kde se píše: „Správa služeb je množinou specifických organizačních schopností pro dodávání hodnoty zákazníkům ve formě služeb.“ V originále: „Service Management is a set of specialized organizational capabilities for providing value to custmers in the form of services.“ Pro pochopení dané definice si tak musíte nastudovat další pojem, neboť téměř každá definice se na nějaký další pojem odvolává.

A jaké jsou vaše zkušenosti se zaváděním procesů podle ITIL?

Related posts:

1. COBIT tajemství zbavený
2. Senior specialista ICT Outsourcing – Praha
3. IT Governance

Někteří personalisté jaksi nezaznamenali, že v České republice došlo podobně jako v některých dalších evropských zemích ke změně struktury hospodářství od AIS k SIA. To znamená, že většina zaměstnanců pracuje v oblasti služeb (Services), méně zaměstnanců již nachází uplatnění v průmyslu (Industry) a ještě méně jich je zaměstnáno v zemědělství (Agriculture). Způsob uvažování managementu a personalistů se však, co se týká nabídky formy práce, příliš nezměnil. Jakoby nepochopili, že dnes již ve spoustě oborů není nutné, aby byl pracovník po celou pracovní dobu trvale přítomen na pracovišti.

Důvod je prostý. Zatímco dříve, kdy převažovala průmyslová výroba, která byla značně materiálově a technicky náročná, tak dnes značná část zaměstnanců pracuje v oblasti poskytování služeb. Nároky na technické vybavení pracovišť těchto zaměstnanců nejsou vysoké. Ve většině případů stačí k tomu, aby zaměstnanec mohl svou práci vykonávat jen telefon, počítač a internetová konektivita. A většina zaměstnanců toto vybavení má doma a mnohdy dokonce i kvalitnější, než jaké jim je schopen a ochoten poskytnout zaměstnavatel. Mimochodem, některé společnosti jsou si této skutečnosti vědomi a tak svým zaměstnancům nabízejí, že pro práci mohou používat svůj vlastní počítač, který si sami vyberou a na který jim přispějí. O tomto zaměstnaneckém programu se hovoří jako o BYOC (Bring Your Own Computer).

Ale zpět k práci z domova. Proč tato moderní forma práce, o kterou by jistě mělo zájem poměrně velké množství zaměstnanců, u nás není tak rozšířená jako jinde ve světě? Rizika práce z domova, o kterých jsme již psali, to nejspíš nebudou. Důvodů je mnohem více. Oproti nejvyspělejším ekonomikám jsme pozadu o mnoho let. Např. dnes tolik moderní openspace, to je něco, co bylo jinde ve světě prosazováno řekněme někdy v 80. letech. Jistě, openspace má své kouzlo a nesporně přináší i pozitivní efekty, ale všimněte si, že je často prosazován plošně, tedy i na pracovištích, kde je zcela nevhodný a kde o nějakém zvyšování výkonu nemůže být vůbec řeč.

Další problém spočívá v tom, že někteří manažeři neumí hodnotit své podřízené. Vyžadovat trvalou přítomnost na pracovišti a lpět na dodržování pracovní doby je pro některé z nich stále jednodušší než hodnotit kvalitu a kvantitu odvedené práce. Na jejich obranu je nutno podotknout, že nezřídka jsou k tomu tlačeni vedením společnosti. V této souvislosti se často hovoří o značné neefektivitě českých podniků resp. jejich zaměstnanců, kteří nevyužívají efektivně pracovní dobu. Neefektivita však často pramení pouze z neschopnosti managementu efektivně využívat dostupných lidských zdrojů a různých forem práce.

Zaměstnavatelé nabízejí svým zaměstnancům nejrůznější benefity, ale je to opravdu to, co zaměstnanci chtějí? Jsme svědky toho, že značná část pracujících za prací dojíždí a někteří tráví na cestách i několik hodin denně. Trh s nemovitostmi u nás přes značné množství realitních kanceláří pořád stále nefunguje a tak v našich krajích není zcela běžné, aby rodina s dětmi prodala svůj rodinný domek a přestěhovala se za prací na druhý konec republiky. Nejrůznější benefity ve formě slev na nejrůznější sportovní a kulturní akce tak nejsou pro zaměstnance, co dojíždí a mají rodinu, příliš zajímavé. Prostě na tyto akce nemají čas. Tito zaměstnanci by ale jistě uvítali jako benefit možnost práce z domova. A co vy?

Related posts:

1. Lesk a bída HR v ČR: benefity
2. Rizika práce z domova
3. Rizika práce z domova – pokračování

Způsob vedení vyšetřování závažného bezpečnostního incidentu, který má na svědomí vlastní zaměstnanec společnosti, vykazuje určité odlišnosti od způsobu vedení vyšetřování incidentu, který byl veden útočníkem mimo organizaci a jehož totožnost neznáme a ani netušíme.

Je zajímavé, že ač má většina ISIRT (Information Security Incident Response Team) obvykle vypracovány postupy, jak provádět vyšetřování v případech, kdy došlo k bezpečnostnímu incidentu provedeného neznámým pachatelem odněkud z internetu, tak postupy pro šetření bezpečnostních incidentů, které mají na svědomí vlastní zaměstnanci, vypracovány většinou nemají. Přestože nejrůznější průzkumy a statistiky mluví zcela jasně a jejich závěry jsou naprosto jednoznačné, společnosti si jaksi nechtějí připustit skutečnost, že až 80% útoků je vedeno právě zevnitř organizace a vypracování odpovídajících postupů nevěnují dostatečnou pozornost.

Proč v případě bezpečnostního incidentu, který spáchal vlastní zaměstnanec postupovat trochu jinak? V případě, že útok provedl neznámý pachatel odněkud z internetu, se tato skutečnost dost často stává dříve či později veřejně známou. To, že je nedostupná nějaká služba, kterou společnost poskytuje, že se na internetu objevila důvěrná data, které společnost zpracovává, nebo že daná služba nefunguje tak jak má, to je něco co, se dost dobře před veřejností utajit nedá. Nezřídka se také vlastní zaměstnanci o této skutečnosti dozvědí dříve z televize nebo z internetu, než od svého zaměstnavatele. V takovém případě obvykle společnost informace o tom, co se stalo, netají, ale naopak se snaží zaměstnance s incidentem detailně seznámit, aby případně jí mohli poskytnout relevantní informace, které by vedly k odhalení pachatele, věděli, na co si mají dát pozor a v neposlední řadě i jak mají komunikovat s médii a odpovídat na dotazy klientů společnosti.

Na tomto místě bych chtěl také zdůraznit, že ten kdo dává podnět k vyšetřování, nebo ten kdo svolává vyšetřovací tým, není obvykle ten, kdo vlastní vyšetřování vede. Je nutné si uvědomit, že osoba, která podnět k vyšetřování dává, bývá dost často i osoba, která se cítí nějak poškozena nebo poškozenou stranu zastupuje. Nejenže není způsobilá k vyšetřování, neboť nemá potřebné zkušenosti, znalosti, schopnosti a dovednosti, ale nemůže z podstaty věci ani zaujmout v rámci šetření objektivní přístup. Hrozí zde, že se vyšetřování bude ubírat jiným směrem, nedojde k včasnému a správnému zajištění důkazního materiálu nebo bude důkazní materiál zničen, případně dojde k úniku informací z vyšetřování.

Problém mimo jiné spočívá také vtom, že společnosti v této oblasti mezi sebou nespolupracují, informace o těchto incidentech nejsou nikde publikovány a tak se nelze divit, že neexistují spolehlivé postupy jak důkazy zajišťovat, tzn. jak je pořizovat, uchovávat, jak s nimi pracovat, jak je vyhodnocovat a též jak je prezentovat. Problémem je i skutečnost, že se ve většině případů často zajišťují jen „digitální” stopy a zajištění klasických stop u běžných případů neprobíhá, málokdo asi snímá otisky prstů z klávesnice, myši, výpočetní techniky a má záznamy z kamery, aby mohl prokázat, kdo s počítačem opravdu pracoval. Ideální je zajistit původní datový nosič nebo alespoň jeho kopii. Avšak i v případě, že máme k dispozici takovýto důkazní materiál, může být věrohodnost těchto důkazů přesto zpochybněna. Problém spočívá ve spojení identity v informačním systému a fyzické osoby v prostoru a čase.

Vyšetřovací tým by měl být co nejmenší. V ideálním případě by jen jeden člověk měl znát všechny informace související s daným případem. Ostatní by měli znát jen informace nezbytně nutné pro provedení požadovaných úkonů. Důvod je prostý, čím víc osob bude s detaily vyšetřování seznámeno, tím větší je pravděpodobnost, že se informace z průběhu vyšetřování dostanou až k pachateli.

Aby bylo vyšetřování úspěšné, měl by mít vyšetřovatel bez ohlášení a bez předchozího souhlasu kohokoliv z managementu přístup do všech prostor a na všechna pracoviště společnosti. Dále by měl disponovat pravomocí zabavit prostředky výpočetní techniky, které mohou obsahovat důkazní materiál, a též by měl mít možnost v okamžiku, kdy to uzná za vhodné, vést v rámci vyšetřování interview s kýmkoliv, od prostého zaměstnance až po vrcholový management, představenstvo nebo generálního ředitele. Vyšetřovatel by měl mít dále přístup do všech IS systémů společnosti, aby mohl zajistit důkazy. Pro tento účel by mu měl být na všech systémech vytvořen restriktivní účet s právy umožňujícími procházet adresářovou strukturou, zobrazovat obsah souborů a nastavovat auditing. Všichni zaměstnanci by mu měli poskytnout požadovanou součinnost např. k zajištění důkazního materiálu.

Výše uvedené je pro úspěšný průběh vyšetřování zcela zásadní. Bavíme se zde o závažných bezpečnostních incidentech, kde hrozí riziko z prodlení, riziko úniku informací, riziko zničení veškerých stop a důkazního materiálu. Vyšetřovatel musí proto těmito pravomocemi a oprávněními v IS systému disponovat ještě dřív, než k incidentu nebo k zahájení vyšetřování dojde. Z výše uvedených důvodů také není žádoucí, aby do průběhu vyšetřování, které vyšetřovatel vede, kdokoliv zasahoval. Případné námitky proti způsobu vedení vyšetřování mohou být vzneseny kýmkoliv dodatečně a musí být přezkoumány nezávislým orgánem.

Je zřejmé, že vyšetřovatel musí (pokud má společnost opravdu zájem na tom, aby se něco vyšetřilo) za účelem své práce disponovat odpovídajícími pravomocemi, a proto je nanejvýš žádoucí, aby se jednalo o osobu vybavenou nejen potřebnými znalostmi, schopnostmi a dovednostmi, ale i osobu dostatečně a vhodným způsobem prověřenou. Vyšetřovatele však musí být také možné kontrolovat a z vyšetřování v případě zjištění závažných procesních pochybení odvolat. Za tímto účelem by měl vyšetřovatel vést deník, do kterého bude zaznamenávat svůj postup, evidovat důkazní materiál a tento deník pravidelně nebo na vyžádání předkládat svému nadřízenému. Vyšetřovatel by neměl brát tento požadavek jako zbytečnou byrokracii nebo projev nedůvěry – tímto způsobem vyšetřovatel chrání především sám sebe.

Způsobů jak daného adepta na pozici vyšetřovatele prověřit, je více. Vyšetřovatel bude pravděpodobně z útvaru nebo týmu, který  v dané společnosti řeší problematiku informační bezpečnosti. Mělo by se jednat o osobu, která dlouhodobě dosahuje požadovaných výsledků a vyznává stejné hodnoty, jako společnost pro kterou pracuje. Tato osoba by měla být vybrána na základě dlouhodobého sledování. Ověření její způsobilosti k této činnosti může být provedeno testem, který bude spočívat např. ve vyšetřování jí blízké osoby. Adept však nesmí tušit, že se jedná o cvičný úkol a neměl by ani tušit, že víme o tom, že k dané osobě má nějaký vztah. Tím se velice přiblížíme skutečné realitě. Následně vyrobíme důkazy, které budou svědčit v neprospěch této osoby a budeme sledovat, jak se náš subjekt zachová, zda důkazy zničí nebo bude dělat, že je neviděl nebo bude danou osobu kontaktovat a o zahájení šetření ji informovat či ji jiným způsobem varovat. Za správný přístup se obecně považuje, že vyšetřovatel prohlásí, že nemůže být vzhledem k jeho vztahu k dané osobě objektivní a sám požádá, aby byl z šetření daného případu odvolán.

Related posts:

1. Bezpečnostní incident: stanovení závažnosti incidentu
2. Bezpečnostní incident: Drahý incident management
3. Bezpečnostní incident

A přitom možností, jak snížit náklady na IT, je spousta. Tento článek přináší naprosto konkrétní tipy, jak snížit náklady na IT. Následující seznam se nesnaží být vyčerpávající.

1. Outsourcing 

Pokud někdo dokáže danou službu např. vývoj SW nabídnout laciněji a ve stejné kvalitě, využijte toho.

2. Offshoring

Pokud můžete např. výpočetní středisko přesunout do levnější země, udělejte to.

3. Cloud computing

Zamyslete se nad tím, zda by pro vás nebyly služby, které nabízí cloud computing, v některých případech výhodnější.

4. Bodyshopping

Tam, kde nehrozí ztráta know-how a nejedná se o natolik specifickou činnost, aby se nedala rychle naučit, je možné uzavřít kontrakt se společností, která vám poskytne na určitou dobu své pracovníky, např. v době dovolených.

5. Revize smluv

Nahraďte drahé produkty a služby levnějšími a stejně kvalitními. To že před 3 lety uzavřená smlouva byla pro vás výhodná, to už dnes dávno nemusí platit. Zvažte, zda by v některých případech nebylo výhodnější mít uzavřenou smlouvu místo s několika, pouze s jedním dodavatelem.

6. Reengineering procesů

Analyzujte stávající procesy (AS-IS) a navrhněte nové řešení (TO-BE), dělejte věci efektivně. Cobit a ITIL vám v tom pomůže.

7. Automatizace

Souvisí s reingeneeringem procesů. Položte si otázku, zda nelze některé činnosti, které dělá lidská obsluha, automatizovat.

8. Reorganizace

Zamyslete se nad změnou organizační struktury a snížením počtu zaměstnanců. Podkladem pro rozhodování by měla být analýza procesů a výkonnosti zaměstnanců.

9. Školení

Ač představuje náklady, v delším časovém horizontu se vám vždy vrátí – proškolení zaměstnanci nadělají méně chyb. Do budoucna budete schopni s menším počtem zaměstnanců poskytnout stejně kvalitní služby.

10. Zákoník práce

Dodržujte ho, vytvořením optimálních podmínek pro práci a především dodržováním přestávek a pracovní doby se snižuje množství chyb.

11. Práce z domova a vzdálený přístup

Ušetříte náklady za pracovní místo, osvětlení a klimatizaci pracoviště, el. energii potřebnou k napájení počítače a v neposlední řadě i spotřebu vody.

12. Virtualizace

Konsolidujte servery, nasaďte virtualizační SW a snižte náklady na umístění, napájení, chlazení i náklady na správu těchto serverů, které rozhodně nejsou zanedbatelné.

13. Lite verze

V případě, že uvažujete o virtualizaci desktopů, nezapomínejte, že některé OS obsahují obrovské množství souborů, které nejsou pro vlastní běh vůbec potřeba a mohou být bez problémů a ovlivnění funkčnosti odstraněny. Spolu s velikostí image se tak výrazně sníží i požadavek na operační paměť a diskový prostor.

14. Úsporný režim

Zamyslete se nad snížením spotřeby celého počítače, především v době nečinnosti. Při několika 1000 počítačů již má velký význam zamyslet se nad vhodným nastavením úsporného režimu, vypínání PC, monitorů a disků.

15. Klimatizace

Chlazení v řadě tzv. inrow změňte za chlazení nad zařízením tzv. overhead. Počáteční investice je vysoká, ale velice brzy se vám vrátí.

16. Requirement engineering

Věnujte pozornost tomu, co váš zákazník vlastně chce –  neztrácejte čas vývojem něčeho, co zákazník vůbec nepotřebuje.

17. Metodika vývoje

Ne vždy jsou klasické metodiky vývoje SW nejvýhodnější, uvažujte i o agilních metodikách vývoje SW.

18. Testování SW

Důkladné testování SW v průběhu celého životního cyklu vytváří předpoklad, že dojde k včasnému odstranění chyb.

19. Tisk

Umístěte tiskárnu dál od zaměstnanců, snižte spotřebu papíru, toneru a inkoustu tím, že výchozí nastavení tiskárny změníte na černobílý a oboustranný tisk.

20. Licence

Monitorujte, jak a kým jsou jednotlivé aplikace využívány a jaký je jejich přínos pro vaši společnost. Zvažte, jaké aplikace opravdu potřebujete a zda není k dispozici jiný, levnější produkt a zda není možné více aplikací nahradit jednou.

21. Tenký klient

Pokud to jde, přejděte na tenkého klienta. Ušetříte náklady za aktualizaci, tu budete nyní muset provádět jen na serveru. Zákazník bude mít vždy aktuální a funkční verzi. Kromě SW tenkého klienta se zamyslete i nad tenkým HW klientem tj. stanici bez disku, aplikací a OS.

22. Velké disky

Tam kde to lze, používejte velké disky (jsou sice pomalejší), ale vzhledem k tomu, že spotřeba disků není výrazně závislá na jejich kapacitě, je výhodnější velký počet disků o malé kapacitě nahradit menším počtem disků o velké kapacitě.

23. SSD

Místo vysokootáčkových disků s malou kapacitou použijte Solid State Disk – obsahuje flash paměť a tudíž spotřebuje méně energie a ještě k tomu má přístupovou dobu o nějaký řád rychlejší než současné nejrychlejší pevné disky.

24. Přesun dat

Přesuňte nepoužívaná data s vysokorychlostních disků na pomalejší s nižší spotřebou. Zamyslete se nad tím, zda nenasadit nějaký SW na automatizovaný přesun (automated tiering) dat mezi disky podle toho, jak je k datům přistupováno.

25. Komprimace

Některá data lze velice úspěšně komprimovat a tím výrazně snížit požadavky na diskovou kapacitu.

26. Archivace

Data, ke kterým uživatelé tak často nepřistupují, je možné přesunout na levnější média.

27. Skartace

Spousta dat na vašich síťových discích je neaktuálních a dost často se také jedná o data, která na nich nemají vůbec co dělat, např. nelegální kopie filmů, hudebních skladeb, aplikací, ale i soukromých fotografií apod.

28. Deduplikace

V síti s velkým počtem uživatelů se dost často stává, že na discích je uložen jeden soubor několikrát, často i tolikrát, kolik je uživatelů. Při deduplikaci je uchovávána pouze jedna instance daného souboru a na ní vedou odkazy.

29. VoIP

Snižte náklady za telefonování, telefonujte přes internet.

Máte nějaký další nápad, jak snížit náklady na IT? Podělte se o něj s ostatními čtenáři v diskusi pod článkem nebo napište a my váš tip přidáme do seznamu.

No related posts.