U703B : Správa provozu outsourcované aplikace

Kód úlohy:

U703B

Autor návrhu úlohy:

Antony M. (ČVUT FIT), Krejčí P. (ČVUT FIT), Přibáň M. (ČVUT FIT), Černohorský, J. (KIT, VŠE)

Datum poslední úpravy:

2015-02-06

Předpokládaná pravděpodobnost užití v praxi:

0.5

Charakteristiky úlohy

1. “Správa provozu outsourcované aplikace“ – cíl, účel

Cílem úlohy je průběžně udržovat optimální úroveň outsourcované aplikace v závislosti na skutečných potřebách podniku a optimálních nákladech.

2. Obsah úlohy

V průběhu řízení provozu outsourcované aplikace dochází ke kontinuální analýze reportů o využívání kapacity služeb reflektujících skutečné a aktuální potřeby daného podniku. Zjištěné potřeby jsou porovnávány s hodnotami atributů stanovených v rámci kontraktu a SLA . Následné vyhodnocení získaných výsledků má za cíl odhalit případné odchylky a na základě významu těchto odchylek zhotovit návrh změny kontraktu a SLA.

3. Vstupy úlohy:

Aplikační architektura (D053A ),
Katalog požadavků na IT (D042A ),
Katalog IT služeb (D111A ),
Evidence softwarových aktiv (D234A ),
Plán projektů (D123A ),
Provozní dokumentace (D711A ),
Analýza IT dodavatelů (D121A ),
Kapacitní plán v IT (D236A ),
Rozpočet IT (D325A ).

4. Výstupy úlohy:

Provozní dokumentace (D711A ), aktualizovaná,
Katalog IT služeb (D111A ), aktualizovaný,
Katalog požadavků na IT (D042A ), aktualizovaný,
Plán projektů (D123A ), aktualizovaný.

5. Podmínky úspěšnosti úlohy

Kontrakt a SLA umožňují dodatečné změny.
Existence mechanismu pro periodické získávání reportů o plnění SLA, aktuálních smluv o poskytovaných službách SLA. V případě požadavku na změnu aplikace je potřebná základní znalost:
- infrastruktury,
- integračních vazeb na interně provozované aplikace a další externě provozované aplikace.

6. Doporučené praktiky

Nutné vhodně stanovit periodicitu realizace dané úlohy. Časové rozestupy mezi jednotlivými realizacemi úlohy je vhodné stanovit podle toho, jaké služby daná aplikace poskytuje. Pro kategorizaci jednotlivých aplikací je možné použít kategorizaci služeb podle kritičnosti.
Analýzu reportů a vyhodnocování reportů je důležité provádět nejen pravidelně (například jednou za kvartál), ale také v nějakých předem stanovených termínech po provedení každé změny.
Analýza by se měla zaměřit především na parametry kontraktu a SLA . Pro každou aplikaci je vhodné stanovit si klíčové metriky, které budou pravidelně monitorovány a na které bude kladen důraz.
Po provedení změny na dané aplikaci je vhodné identifikovat parametry , které budou touto změnou ovlivněny a na ty se zaměřit.

7. “Správa provozu outsourcované aplikace“ - klíčové aktivity

7.1. Změnové řízení outsourcované aplikace

Na základě povahy požadavku na změnu (RFC) a povahy aplikace dojde k rozhodnutí o provedení / neprovedení změny . V případě provádění změny na outsourcované aplikaci je důležité položit si tyto otázky :
- Nejedná se o komoditní aplikaci? Poskytovatel nemusí být ochotný provádět změny pouze pro jednoho z odběratelů, protože by přišel o výhodu poskytování stejné služby mnoha zákazníkům. Zároveň by to pro poskytovatele (potažmo i odběratelskou společnost) znamenalo pravděpodobně zvýšení nákladů na službu. Pokud se jedná o komoditní aplikaci, je také vhodné zvážit, zda je změna nutná a není vhodnější využívat standardizované postupy, které nabízí.
- Nebudou náklady na změnu vyšší než následné přínosy? Změny v aplikaci často nemusejí znamenat jen částku zaplacenou dodavateli za provedení změn. Změna může obnášet i nové požadavky na úpravu integračních vazeb v odběratelské společnosti nebo náklady na proškolení uživatelů pro práci s novou verzí.
- Nenaruší se požadovanou úpravou dané aplikace best practices, které nezměněná aplikace poskytuje? Hromadně nabízené služby většinou obsahují procesy nastavené dle osvědčených přístupů. Před rozhodnutím o změně takové aplikace je nutné uvážit, zda změna nebude pro podnik kontraproduktivní.
- Nebude vhodnější přizpůsobit naše procesy těm, které daná aplikace nabízí? Outsourcované aplikace s sebou přinášejí určité nastavení procesů, které je osvědčilo u jiných společností (best practices).
Pokud se podnik rozhodne pro změnu, dojde k samotnému změnovému řízení (více viz úlohy ze skupiny úloh Řízení provozu podnikové informatiky -> Řízení incidentů, problémů a požadavků). V případě outsourcované aplikace bude změnové řízení ovlivněno charakterem dané aplikace a charakterem kontraktu a SLA uzavřených s dodavatelem. Pokud to zmíněné okolnosti dovolí, dojde k samotné změně, kterou opět v závislosti na daných okolnostech řídí a realizuje buď dodavatel, nebo daný podnik sám.

7.2. Kontinuální analýza reportů o využívání kapacity služeb

Cílem činnosti je k ontrolovat, zda z pohledu reálných požadavků podniku nejsou jednotlivé parametry definované v SLA příliš naddimenzované, či naopak poddimenzované . Změna požadavků může vyplývat například ze změny organizační struktury, rozšíření portfolia produktů / služeb, změny provozních modelů, apod. Vykonavatel činnosti se například zaměří na porovnání požadované dostupnosti definované v SLA a skutečných potřeb dle daných reportů.
V tomto případě si bude vykonavatel klást otázky tohoto typu:*
Není aktuální dostupnost definovaná v SLA příliš vysoká / drahá? Pro některé pracovníky nemusí být klíčové mít co nejvyšší dostupnost služby, pokud nižší (dostačující) dostupnost pokryje požadavky ve stejné míře.
- D ochází k reálnému využívání dané aplikace v celém období definovaném v SLA? Pokud pracujeme pouze 8 hodin denně 5 dní v týdnu, je možné pokusit se vyjednat vyšší dostupnost na tyto hodiny a naopak nižší pro noční hodiny a víkendy. Pokud je aplikace využívána sezónně, je také možné změnit parametry tak, aby pro daná období byla kapacita služby navýšena a pro ostatní naopak snížena. Tento přístup je možné aplikovat u řady velkých cloudových poskytovatelů.
Odpovědi na tyto a podobné otázky by měl vykonavatel najít právě v dokumentech reflektujících skutečné využívání outsourcované aplikace.

7.3. Verifikace a zhotovení návrhu na změnu parametrů kontraktu

Porovnání výsledků analýzy skutečného využívání outsourcované aplikace s daným kontraktem a následné vyhotovení návrhu na změnu kontraktu. Vykonavatel si klade otázky jako :
- Je daná služba využívána?
Potřebuji ještě tuto službu?
Neměla by být daná služba z kontraktu vyjmuta? Jsou způsoby měření plnění správně definovány?
Jsou způsoby výpočtu ceny správně definované?
Je ošetření rizik stále dostačující vzhledem ke změně obsažených služeb a jejich parametrům?
Pokud jsou součástí kontraktu i licence k dané aplikaci, je součástí činnosti i verifikace jejich počtu oproti skutečné potřebě .

7.4. Verifikace a zhotovení návrhu na změnu parametrů SLA

Činnost se zabývá porovnáním skutečných potřeb společnosti a parametry služby, které deklaruje příslušné SLA . Součástí je návrh na změnu těchto parametrů, pokud to samotná smlouva připouští. Vysoká dostupnost poskytovaná 24x7 může být například v činnosti (1) vyhodnocena jako naddimenzovaná a změna tohoto parametru může mít nemalý vliv na cenu celé služby. Na základě tohoto zjištění může být návrhem na změnu změna parametru dostupnosti služby například na 99,9% za měsíc z původních 99,99% za měsíc pro 5 dní v týdnu místo předchozích 7 dní v týdnu.
Při nastavování parametru dostupnosti je velice důležité stanovit čas, pro který je daná dostupnost deklarována. Vysoká dostupnost deklarovaná pro roční období může pro podnik znamenat jeden dlouhý (třeba i likvidující) výpadek, kdežto dostupnost deklarovaná na měsíc znamená maximální výpadek o velikosti 1/12 maximálního výpadku v případě ročního období.

7.5. Analýza technických parametrů aplikace

Do určité míry je podstatné znát technické parametry outsourcované aplikace a to především z hlediska integrace . Míra znalosti technický parametrů závisí na tom, o jaký typ outsourcingu jde . Zda je outsourcován zdroj, služba, či proces, zda jde o využití cloudu a případně jakého typu.
Například při konzumaci komoditní služby jako SaaS nemusí být znalost technických parametrů podstatná , v některých případech může být dokonce nevhodná. Naopak při využití PaaS může být znalost technických parametrů služby klíčová. Například pokud je daná aplikace postavená na technologii Java, je potřeba, aby tomu bylo běhové prostředí nasazované aplikaci přizpůsobeno.
Může se také jednat například o integrační metody, které daná aplikace nabízí . Pokud je pro společnost daná outsourcovaná aplikace klíčovou záležitostí, může se zajímat také o krizové plány daného poskytovatele pro případ havárie, apod.