Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Úloha : Návrh koncepce sourcingu IT
Návrh koncepce sourcingu IT
Kód úlohy

Standardní kód úlohy v MBI.

:
U035A
Autor návrhu úlohy

Jméno a příjmení autora úlohy

:
Voříšek, J. (KIT, VŠE)), Krejčí, P. (FIT, ČVUT), Antony, M. (FIT, ČVUT), Přibáň, M. (FIT, ČVUT)
Datum poslední úpravy

Datum poslední úpravy úlohy ve tvaru rrrr.mm.dd.

:
2013-12-18
Předpokládaná pravděpodobnost užití v praxi

Předpokládaná pravděpodobnost užití úlohy v praxi, hodnoty 0 - 1. Např. 0,7 - úlohu lze využít v 7 z 10 podniků. Hodnoty jsou průběžně testovány a upřesňovány na základě anket a průzkumů.

:
0.8
Charakteristiky úlohy

Charakteristiky úlohy

1. “Návrh sourcingu IT“ – cíl, účel
  • Cílem úlohy je stanovit základní pravidla a přístupy k rozhodování o zajištění IT služeb a IT zdrojů , tj. interními, resp. vlastními kapacitami, nebo externími dodavateli a poskytovateli těchto služeb.
2. Obsah úlohy
  • Návrh sourcingu je orientován na způsob zajištění IT služeb a IT zdrojů potřebných pro realizaci těchto služeb. Řeší otázky rozvoje a provozu informatiky z pohledu variantních řešení vlastními kapacitami oproti externím .
  • Rozhodování se vztahuje, jak na nově připravované projekty, tak na již provozované aplikace a infrastrukturu. Rozlišuje se tak mezi outsourcingem rozvoje a outsourcingem provozu.
  • Vedle toho úloha zahrnuje i rozhodování o možných formách outsourcingu , včetně různých služeb realizovaných na bázi cloud computingu (SaaS, PaaS, IaaS).
3. Podmínky úspěšnosti úlohy
  • Společnost má definovanou architekturu IT služeb a má nákladové analýzy jednotlivých služeb, tedy kolik stojí danou službu provozovat interně / externě.
  • Rozdělení služeb do jednotlivých kategorií podle jejich kritičnosti je podstatným předpokladem pro rozhodování o jejich formě zajištění. Pro strategické služby je totiž třeba provádět důkladnější analýzu variant sourcingu a být přísnější v hodnocení jednotlivých kritérií, nežli u služby komoditní.
4. Doporučené praktiky
  • Před rozhodnutím o koncepci sourcingu je důležité uvědomit si měnící se požadavky na kompetence IT pracovníků . Zatímco při interním poskytování služeb společnost vyžaduje především technicky zdatné zaměstnance, se zvyšující se mírou outsourcingu se zvyšuje naopak potřeba obchodních kompetencí. Nedoporučuje se technické pracovníky automaticky pověřit starostí o outsourcingové smlouvy, nýbrž se předtím přesvědčit o jejich obchodních kompetencích, případně řízením dodavatelů pověřit jiné pracovníky.
  • Koncepce sourcingu je strategické rozhodnutí a tedy tato činnost by měla být realizována vyšším managementem.
  • Rozdělení služeb do kategorií by mělo být prováděno nejen pracovníky IT, nýbrž ve spolupráci s byznysem, aby byla identifikovaná skutečná hodnota a kritičnosti služby.
5. “Návrh sourcingu IT“ - klíčové aktivity

5.1. Tvorba pravidel pro rozhodování o sourcingu
  • Před samotným rozhodováním o způsobu zajištění konkrétních služeb je nutné stanovit pravidla pro rozhodování , která budou platná ve všech případech. Tímto bude zajištěna jednotná vize směřování sourcingu podnikové informatiky. Pravidla by měla vytvářet prostředí pro směřování k jednomu ze základních modelů sourcingu služeb, které jsou popsány ve faktoru (F121 ).
5.2. Kategorizace IT služeb podle kritičnosti
  • Některé IT služby jsou pro podnik kritické a mají výrazný vliv na produkt společnosti nebo její pověst na trhu. Jiné služby jsou naopak spíše podpůrnou záležitostí a jejich nepřetržitá dostupnost není pro podnik kritická.
  • MBI pro potřeby řízení sourcingu rozděluje IT služby do čtyř základních kategorií podle kritičnosti na chod podniku a strategického významu:
    • Strategické služby - služby, které jsou nedílnou součástí hlavního zaměření podniku a mají přímý vliv na prodeje, spokojenost zákazníka, apod. Existence těchto služeb tvoří konkurenční výhodu a při rozhodování o outsourcingu by měli být jednotlivé varianty podrobeny nejdůkladnější analýze.
    • Infrastrukturní služby - služby, které jsou pro podnik klíčové z hlediska jeho fungování, avšak netvoří konkurenční výhodu a nemají přímý dopad na výstup společnosti. Může se jednat například o správu IT infrastruktury nebo její části.
    • Podpůrné a analytické služby - služby, které pomáhají získávat informace a znalosti pro podporu rozhodování nebo mají jiný podpůrný charakter. Tyto aplikace mohou tvořit vysokou hodnotu pro podnik, avšak krátkodobě se bez nich podnik obejde, protože nejsou kritické pro jeho operativní chod.
    • Komoditní služby - standardizované služby, které se od sebe na trhu příliš neliší. Jsou buďto dané legislativním prostředním nebo natolik standardizovány, že se liší jen minimálně. Může se jednat například o účetnictví, komunikaci apod.
5.3. Tvorba kritérií pro hodnocení variant sourcingu
  • Pro každou službu lze stanovit sadu kritérií , která mohou ovlivnit rozhodnutí o způsobu jejího zajištění.
  • Součástí této činnosti je základní katalog kritérií , rozděleného do jednotlivých oblastí dle dopadu. Tento katalog není závazný a lze ho rozšířit o libovolná jiná kritéria. Úloha kritéria předkládá jako příklady.
  • Každé kritérium lze ohodnotit na stupnici od 0 do 5 , kde:
    • 0 – varianta sourcingu kritérium nesplňuje vůbec,
    • 5 – varianta sourcingu kritérium splňuje v plném rozsahu.Strategický význam:
  • Dodavatel služby umožní změnu a inovaci služby / aplikace dle mých požadavků?
    • 0 – služba / aplikace je pevně definována, není možné ji měnit,
    • 5 – službu / aplikaci dodavatel libovolně upraví dle mých požadavků,
  • Služba / aplikace má pozitivní vliv na podnikovou image
    • 0 – negativně ovlivní podnikovou image,
    • 5 – výrazně vylepší podnikovou image,
  • Službou / aplikací nabydu strategické znalosti
    • 0 – služba / aplikace mi nepřináší žádné znalosti,
    • 5 – služba / aplikace přináší strategické znalosti a cenné know-how

Finanční přínosy a náklady:

  • Služba / aplikace redukuje vytížení nebo počet zaměstnanců
    • 0 – využití služby / aplikace zvýší vytížení pracovníků nebo zvýší jejich počet,
    • 5 – využití služby / aplikace výrazně zredukuje počet pracovníků nebo jejich vytížení
  • Služba / aplikace redukuje náklady na komunikaci
    • 0 – služba / aplikace zvýší náklady na komunikaci,
    • 5 – služba / aplikace výrazně sníží náklady na komunikaci,
  • Služba / aplikace redukuje náklady na dopravu,
  • Služba / aplikace redukuje daňovou zátěž

Dopad na podnikové procesy:

  • Schopnost služby / aplikace se přizpůsobit měnícím se podnikovým procesům
    • 0 – procesy jsou pevně definované a nelze je měnit,
    • 5 – procesy lze libovolně editovat interními zaměstnanci
  • Schopnost služby / aplikace používat standardizované procesy dle stávajících metodik,
  • Schopnost služby / aplikace měřit výkon prováděných procesů
    • O – výkon procesů není možné měřit
    • 5 – pro měření procesů lze interními zaměstnanci definovat uživatelské metriky
  • Schopnost služby / aplikace modelovat role v procesech na závislosti změnách organizační struktury
    • 0 – role jsou pevně dány,
    • 5 – role lze libovolně editovat a vytvářet nové role
  • Flexibilita kapacity služby / procesu z pohledu měnícího se počtu a složení uživatelů
    • 0 – pevně stanovený počet licencí daného druhu
    • 5 – možnost libovolně měnit počet licencí různých druhů
  • Flexibilita kapacity služby / procesu z pohledu měnících se požadavků na dostupnost
    • 0 – pevně stanovená dostupnost aplikace,
    • 5 – dostupnost aplikace je plně volitelná dle požadavků
  • Schopnost službu / aplikaci přizpůsobovat interními kapacitami
    • 0 – sebemenší změna musí být provedena externími specialisty,
    • 5 – Definování nových procesů je možné provést interními pracovníky

Architektura :

  • Služba je kompatibilní s preferovaným uživatelským prostředním (např. operačními systémy, mobilními zařízeními, apod.),
  • Služba je kompatibilní s preferovaným serverovým prostředním,
  • Služba je kompatibilní s preferovaným databázovým prostředním,
  • Služba je kompatibilní s preferovaným vývojovým prostředím,
  • Služba je kompatibilní s back-end systémy,
  • Služba je kompatibilní s preferovaným middleware systémem,
  • Služba je kompatibilní s preferovaným síťovým prostředím.

Rizika:

  • Zkušenosti dodavatele s poskytováním daného typu služby,
  • Úroveň vyspělosti dané technologie,
  • Máme zkušenosti s tímto typem projektu
    • 0 – první sourcingový projekt,
    • 5 – více než 10 úspěšně dokončených projektů podobného typu,
  • Finanční stabilita dodavatele,
  • Outsourcingem služby / aplikace nedojde ke ztrátě know-how,
  • Úroveň kvalifikace personálu dodavatele,
  • Řešení vyhovuje podnikovým bezpečnostním standardům
    • 0 – absolutně nevyhovuje a není zde možnost nápravy,
    • 5 – plně vyhovuje.
5.4. Vyhodnocení kritérií sourcingu - jednotlivé části
  • Výběr kritických (obligatorních) kritérií – pro danou službu jsou vybrána kritéria, která jsou pro rozhodnutí o variantě kritická a bez jejichž splnění nemá smysl o variantě uvažovat.
  • Vyhodnocení kritických kritérií – pokud daná varianta sourcingu jedno z kritických kritérií nesplňuje, poté nemá smysl o ní dále uvažovat.
  • Vyhodnocení všech kritérií – každé z vybraných kritérií je ohodnoceno na stupnici od 0 do 5, kde:
    • 0 – varianta sourcingu kritérium vůbec nesplňuje,
    • 5 - varianta sourcingu kritérium plně splňuje
  • Výpočet indexu pro danou variantu – jednotlivé „body“ udělené vybraných kritériím se sečou a vyjádří jako procento z maximálního počtu bodů dle následujícího vzorce:
    • x = ( 100 * sum(Bi) ) / (5 * n), kde
    • x = zjišťovaný index,
    • sum(Bi) = součet udělených bodů,
    • n = celkový počet vybraných kritérií,
  • Vyhodnocení indexu – vyhodnocení varianty (posouzení vypočteného indexu) je závislé na kategorii kritéria dle činnosti č. 2 (Kategorizace služeb podle kritičnosti). MBI doporučuje níže uvedené kritické hodnoty. Pokud varianta dosahuje alespoň kritické hodnoty, lze zajištění služby zkoumanou metodou doporučit.

Doporučené kritické hodnoty pro vypočtené indexy dle kategorií služeb :

  • Strategické služby – 90 %,
  • Infrastrukturní služby – 75 %
  • Podpůrné a analytické služby – 70 %,
  • Komoditní služby – 60 %.
5.5. Outsourcing provozu IT
  • Pokud podnik uvažuje o outsourcingu již provozované služby, je třeba brát v úvahu několik důležitých aspektů, které nemusí být na první pohled patrné. Při přechodu totiž nedochází pouze k měsíčnímu placení předepsané ceny, ale objevuje se zde celá řada „skrytých“ nákladů a otázek s přechodem spojených.
  • Mezi otázky , které by měly být kladeny, patří například:
    • Kdo bude vlastníkem aktiv? Bude dodavatel služby aktiva pouze spravovat nebo je odkoupí?
    • Kdo bude dělat údržbu služby?
    • Kdo bude dělat upgrade služby?
    • Jaké budou podmínky změnového řízení?
    • Jaký bude dopad na mé podnikové procesy, pokud se obsah služby přechodem změní?
    • Jakým způsobem bude nakládáno s osobními údaji a citlivými daty? V které zemi budou data uložena?
    • Jaké budou náklady na školení uživatelů, pokud se obsah služby změní?
    • Jsem připraven / mám personální kapacity pro řízení vztahu s dodavatelem?
    • Mám stanovenou exit strategii, pokud bych se chtěl navrátit do původního stavu?
    • Nehrozí, že dodavatel svoji činnost v dohledné době skončí? Je ekonomicky stabilní?
    • Jak vyřeším přebytek personálních zdrojů, které se díky outsourcingu uvolní?
    • Jaký bude nákladový model? Nebudou zde další skryté a neúměrně vysoké náklady? (například podpora, rozšíření, apod.).
6. Poznámky, reference
  • Pořadí fází testování je většinou následující:
    • Funkční testy po jednotlivých celcích, které probíhají v průběhu vývoje (tedy ještě před samotným předáním aplikace do testování).
    • Integrační testy jsou spouštěny po dodání alespoň určitých celků a kontrolují komunikaci mezi jednotlivými komponentami,
    • Po předání aplikace do testování a tzv. release jsou spuštěny smoke testy (je doporučeno tyto testy spouštět automaticky místo manuálně). Tyto testy mají za cíl ověřit stav nasazené verze, zda je v testovatelném stavu na systémové testování. Prochází pouze základními flow a zjišťují, zda aplikace někde nepadá a neexistují tak nějaké bloky pro testování.
    • Po úspěšných smoke testech dochází k systémovému testování ověřujícímu celkové fungování aplikace. Toto testování je často spojeno s UAT testy a většinou probíhá pomocí testovacích scénářů (testovanými business vlastníky a testery) a testovacích požadavků (testovanými pouze testery).
    • V průběhu poslední periody jsou také spuštěny penetrační a zátěžové testy . Zátěžové testy lze opět lépe simulovat automatickými testy.