Otázka č. 30

Publikováno: 7. 4. 2014

Mějme situaci, kterou můžeme najít u mnoha velkých mezinárodních firem, které se rozhodly konsolidovat poskytování některých infrastrukturních IT služeb (WAN, Internet, DC apod.).

Poskytovatel služeb druhého typu (Service Provider Type II) poskytuje některé infrastrukturní IT služby několika jiným Poskytovatelům služeb prvního typu (Service Provider Type I), kteří jsou součástí vždy příslušné podnikové jednotky a které poskytují businessu většinou aplikační služby (tok služeb ukazuje přiložený obrázek). Služby jsou definovány v katalogu služeb, zpoplatněny, ale bez penalizace. Poskytovatel služeb druhého typu X je z formálních důvodů součástí jedné z podnikových jednotek, kterým poskytuje služby a poskytuje vyjímečně i pár služeb přímo businesu některých podnikových jednotek (šipky 12,13).

Otázka: Jak nazývat smlouvu mezi Poskytovatelem služeb druhého typu (Service Provider Type II) a Poskytovatelem služeb prvního typu (Service Provider Type I) z pohledu Poskytovatele služeb druhého typu (šipky 1,2,3,4) – je to OLA nebo SLA? A co dohody dle šipek 5-8 a 12,13?

Definice v ITILu je poněkud nejasná, jelikož definuje OLA jako dohodu mezi odděleními téže organizace. Co si však představit pod “toutéž organizací” v tomto případě poněkud komplexnější struktury firmy s více poskytovateli služeb? Co je ještě stejná organizace a co už ne? Pokud bude potřeba upřesnění, rád dodám.

ODPOVĚĎ

Odpověď Vladimíra Kufnera

  • ITIL na otázky tohoto typu určitě standardně neodpoví, toto je poměrně specifická situace. Asi bych nesouhlasil, že to je otázka typu Foundation.
  • Osobně bych se určitě přikláněl deklarovat tento vztah jako OLA, i když se asi fakticky jedná o 2 relativně nezávislé business entity (mlčky ale předpokládám, že patří jedné „matce“). Hlavním důvodem pro mne je skutečnost, že se neuplatňuje penalizace, na druhou stranu trochu proti působí zase to, že se za takto poskytovanou službu platí – to by spíše preferovalo UC.
  • Jestli jsem to správně pochopil, jedná se o infrastrukturní služby – ve většině případů „neviditelné“ pro business uživatele, nad kterými je nadstavbově vytvářené aplikační služby, opět důvod pro to zvolit spíše OLA.
  • Určitě bych doporučil použít nějaké pragmatické řešení, které případně respektuje i podpůrný SW nástroj pro SLM. Ve většině případů se tam nečiní rozdíl mezi SLA a OLA/UC (některé systémy toto ani nerozlišují). Důležité je to, aby zvolený podpůrný nástroj uměl kalkulovat cílové datumy řešení incidentů (Deadlines) pro tyto služby podle existující OLA/SLA, resp. měřit a evaluovat dosažené úrovně služeb.
  • Terminologicky je to podle mne spíše „buřt“. Když bychom ale měli zvolit, tak já hlasuji pro OLA. Variantou názvu může být i interní SLA, což je termín, který donedávna používal T-Mobile vůči T-Systems nebo co dnes používá ČEZ.

 

Odpověď Vladimíra Váni

Využil bych „ISO/IEC TR 20000-3 Guidance on scope definition and aplicability of ISO/IEC 20000-1“.
V tomto technickém reportu je řada příkladů jak definovat rozsah nasazení SMS mezi řadou poskytovatelů služeb s různými vazbami. Takže zde je důležité, co si nadefinujeme jako poskytovatele služeb, na kterého budeme aplikovat SMS.

Pokud Service providera typu II zahrneme do rozsahu hodnoceného poskytovatele služeb, přikláněl bych se k OLA. Pokud bude mimo definovaný rozsah (a platí se za ni), může to být dokonce i UC. Takže zde pomineme organizační začlenění, ale budeme se řídit podle rozsahu definovaného pro potřeby auditu ISO/IEC 20000.

Upozorňuji, že takto jsem to nikde definováno nenašel – ani ve zmíněném TR. Je to jen návrh přístupu a vůbec netvrdím, že správný :).

Odpověď Jiřího Skály

Já si naopak myslím, že je to učebnicová otázka na úrovni ITIL Foundation a žádný problém v tom nevidím. Pokud ITIL něco popisuje opravdu srozumitelně, tak je to OLA, SLA, UC a jejich vztahy.

Je jasné, že 5-8 jsou SLA a 9-11 jsou UC. U vztahů 1-4 záleží na tom, jaký status mají BU1-BU4, tato informace není explicitně řečena. Odpověď tedy musím uvést variantně:

  1. Pokud jsou BU1-BU4 samostatné právnické osoby, tzn. každá z nich má samostatné IČ, pak 1 = OLA a 2-4 = UC
  2. Pokud je celá Enterprise jedinou právnickou osobou s jediným IČ, pak 1-4 = OLA

Co se týče 12-13, tak ty je třeba zrušit, ať je status BU1-BU4 jakýkoli. Na tomto stavu je totiž principiálně špatně to, že BU1 Business a BU2 Business přijímají služby od dvou providerů. Ovšem protože není smysluplné, aby uživatelé museli služby vybírat ze dvou katalogů, tak pravděpodobně každá z obou business jednotek má u sebe nějakého integrátora, který služby od X a Z integruje do jednoho katalogu, který pak předkládá svým uživatelům. Čili schéma, které by správně znázorňovalo skutečnost, vypadá nějak takhle, viz příloha SLA_OLA_v1_JSK.vsd. Správné řešení je tedy 12-13 zrušit, a tyto služby přidat do 1, resp. 2, tzn. všechny služby od providera X bude přijímat provider Y, resp. Z, který je zakomponuje do katalogu pro BU1, resp. BU2. No, ale abych odpověděl na otázku, co tedy v dnešním stavu představují 12 a 13:

  1. Pokud jsou BU1-BU4 samostatné právnické osoby: 12 = SLA a 13 = UC
  2. Pokud je celá Enterprise jedinou právnickou osobou: 12-13 = SLA

Než jsem tuto odpověď dopsal, přišla reakce Vládi Váni, a musím mu dát za pravdu v tom, že to, jak se co jmenuje, je nepodstatné. Důležité jsou principy. A ty jsou v případě 12 a 13 porušeny. Takže to, co je na tomto stavu třeba prioritně řešit, není otázka nadpisů v jednotlivých dokumentech, ale skutečnost, že ve dvou případech dochází k tomu, že jedna business jednotka odebírá služby od dvou providerů.

Štítky: , ,
Autor:: Kateřina Mrkvičková