Vysoká škola ekonomická v Praze

Fakulta informatiky a statistiky

katedra informačních technologií

 

 

Řízení služeb informatiky
v podmínkách outsourcingu

 

disertace

 

 

Doktorand:               Ing. Tomáš Bruckner

Školitel:                    Prof. Ing. Jiří Voříšek, CSc.

Obor:                         Informatika

 

 

 

© 2001 Tomáš Bruckner

 

b r u c k n e r @ v s e . c z

http://nb.vse.cz/~bruckner

http://kit.vse.cz

 

Lze volně šířit pouze vcelku a bez úprav. Při citaci uvádějte odkaz:

Bruckner, T.: Řízení služeb informatiky v podmínkách outsourcingu. disertační práce, Praha, VŠE, 2001.

 

 

Praha, květen 2001

Abstrakt

Text se zabývá kompetencemi podnikové informatiky, popisuje situaci možného outsourcingu informatiky z hlediska světových trendů a z pohledu procesů podniku, s ohledem na možnost komplexního outsourcingu oblasti informatiky, částečného operativního outsourcingu informatiky a outsourcingu jiných obchodních procesů. Určuje principy řízení procesů v informatice, které umožní operativní outsourcing, principy řízení požadavků a změn v podniku v návaznosti na řízení procesů a principy, které mohou pomoci účinně řídit potřeby informatické podpory v podniku. To ústí v určení principů služeb informatiky, principů celostního řízení služeb informatiky a principů řízení jednotlivých služeb. Dále je popsán model možného řízení služeb a jejich zdrojů, specifika vlastnictví informatických zdrojů a jsou určeny principy měření efektů (splnění potřeb pomocí informatiky) a principy měření plnění služeb informatiky.

Základním hlediskem je pohled (interního) zákazníka podnikové informatiky. Veškeré aktivity v informatice jsou řízeny primárně s ohledem na zákazníka, na důvody, proč informatiku potřebuje, na produkt, který mu informatika poskytne, a na efekt, který to zákazníkovi přináší. Aktivity v informatice jsou zejména pojaty jako procesy, u nichž z hlediska jejich řízení za možnosti outsourcingu není důležitý jejich průběh, ale především jejich výsledek, produkt, a to jsou služby podnikové informatiky. Rozumnou hranicí mezi zákazníkem informatiky, poskytovatelem informatiky a ředitelem podnikové informatiky jsou právě tyto služby. Způsob sjednání jejich předmětu, parametrů i ceny je podstatný pro možnost a operabilitu jejich řízení a pro rozdělení odpovědností mezi příjemce a poskytovatele, ať jsou to interní ekonomické subjekty v podniku nebo subjekty externí. Kromě hlediska služeb je při abstrakci od průběhu procesů zmíněn také pohled řízení zdrojů informatiky a jeho provázání s primárním řízením prostřednictvím služeb.

 

 

Klíčová slova

Informatika, Organizace, Outsourcing, Informační systém, Informační technologie, Proces, Řízení, Služby informatiky, Metriky

 

 

 

 

 

Abstract

Paper deals with competence of enterprise informatics, describes situation of possible informatics outsourcing from the view of global trends and from the view of enterprise processes, with respect of possibility of complex IT activities outsourcing and other business process outsourcing. The paper defines principles of process management in informatics which enable operative outsourcing, principles of requirement and change management in context of process management, and principles, which can help to manage needs for IT support in enterprise actively. It results to definition of principles of IT services, principles of  IT services entirety management and principles of particular service management. Furthermore is described a model of possible services and resources management, specificity of IT resources ownership, and principles of effects (needs realisation by informatics) measurement, and principles of IT services measurement.

Basic view of the paper is view of (internal) customer of enterprise informatics. Entire activities in informatics are managed primarily with respect to customer, to reasons why he needs IT, to product, which enterprise informatics provides him, and to an effect which is brought to customer by that. Activities in informatics are primarily approached as processes, which, from the management in possibility of outsourcing point of view, are not important as the process course itself, but foremost as its result only – a product, and that is the enterprise informatics service. Just this service is reasonable border between customer of informatics, provider of informatics and CIO. The way of conclusion of its subject, parameters and price is fundamental for possibility and operability of its management and for responsibility distribution between service customer and provider, whether they are enterprise internal economical subjects or external ones. Except the view of services there is in abstraction from the process course mentioned a view of resources management and its connection to primarily management through the services.

 

 

Keywords

Informatics, Organisation, Outsourcing, Information system, Information technology, Process, Management, IT services, Metrics

 

 

 

 

 

Abstrakt

Der Text beschäftigt sich mit der Kompetenz der Betriebsinformatik, beschreibt die Situation des möglichen Informatik-Outsourcings vom Standpunkt der Welttendenzen und Unternehmensprozesse, mit Rücksicht auf  die Möglichkeit des Komplex-Outsourcings des Informatik-Bereichs, speziell Operativ-Outsourcing der Informatik und Outsourcing  der anderen Betriebsprozesse. Definiert die Prinzipien der Prozess-Verwaltung in der Informatik, die das Operativ-Outsourcing ermöglichen, Prinzipien der Verwaltung der Anforderungen und Änderungen im Betrieb in Anknüpfung auf die Prozess-Verwaltung und die Prinzipien, die wirksam helfen können, die Bedürfnisse der informativen Unterstützung im Betrieb zu verwalten. Dies mündet in die Bestimmung der Prinzipien der Informatik-Dienste, Prinzipien der Gesamt-Verwaltung der Informatik-Dienste und Prinzipien der Verwaltung der einzellnen Dienste. Weiter wird das Modell der möglichen Verwaltung der Dienste und deren Quellen, die Spezifik des Eigentums der informatischen Quellen beschrieben und es werden die Prinzipien der Effekt - Bewertung (Bedürfnis-Erfüllung mittels Informatik) und die Prinzipien der Effekt - Bewertung der Informatik - Dienste bestimmt.

Der Elementar-Standpunkt ist die Ansicht des (internen) Klienten der Betriebs-Informatik. Sämtliche Aktivitäten in der Informatik werden primär mit Rücksicht auf den Klienten, auf die Gründe  warum er die Informatik benötigt, auf das Produkt welches ihm die Informatik leistet und auf den Effekt das dem Klienten gebracht wird, geleitet. Die Aktivitäten in der Informatik werden insbesondere als solche Prozesse begriffen, bei denen vom Standpunkt ihrer Verwaltung unter der Outsourcing-Möglichkeit nicht ihr Verlauf, sondern vor allem ihr Resultat, das Produkt wichtig ist, und das sind die Dienste der Betriebs-Informatik. Die vernünftige Grenze zwischen dem Klienten der Informatik, dem Anbieter der Informatik und dem Leiter der Betriebs-Informatik sind gerade diese Dienste. Die Art und Weise der Vereinbarung dieses Gegenstandes, Parameter und Preis sind stichhaltig für die Möglichkeit und Operabilität ihrer Verwaltung und für die Aufteilung der Verantwortung zwischen dem Empfänger und Anbieter, ob es sich um interne ökonomischen Subjekte im Betrieb oder externe Subjekte handelt. Außer dem Standpunkt der Dienste ist bei der Abstraktion vom Prozessenverlauf auch der Standpunkt  der Verwaltung der Informatik-Quellen und sein Zusammenhang mit der Primär - Verwaltung mittels Dienste erwähnt.

 

Schlüsselworte

Informatik, Organisation, Outsourcing, Informationssystem, Informationstechnologie, Prozess, Verwaltung, Informatik-Dienste, Bewertung

 

 

 

 

 

 

Obsah:

1      Úvod

2      Outsourcing informatiky v dnešním světě

2.1       Kompetence podnikové informatiky

2.2       Procesní pohled na informatiku podniku

2.3       Strategické plánování informatiky

2.4       Rostoucí komplexita v informačních technologiích

2.5       Dodavatelské zajištění informatiky

3      Distribuce řízení na procesy

4      Řízení požadavků a změn v informatice

4.1       Vznik přání, potřeby

4.2       Možnost splnění přání informatikou

4.3       Znalost místa pro sdělení přání na informatiku

4.4       Schopnost formulovat přání na informatiku

4.5       Proces řízení požadavků a proces řízení změn

5      Služby podnikové informatiky

5.1       Architektura služeb

5.2       Členění služeb informatiky

5.3       Aplikační služby

5.4       Předmět aplikačních služeb

5.4.1        Návaznost potřeby a předmětu služby

5.4.2        Předmět služby a vývoj informačního systému

5.4.3        Předmět služby a způsob dosažení výsledku

5.5       Cena aplikačních služeb

5.6       Řízení zdrojů

5.7       Uživatelské infrastrukturní služby

5.8       Centrální řídící aktivity v IS

6      Model zdrojů a služeb informatiky

6.1       Matice aplikační služby / zdroje

6.2       Použití modelu v řízení outsourcingu

6.3       Jiné než aplikační služby v modelu

7      Vlastnictví prostředků IT při outsourcingu služeb

8      Měření služeb IS a jejich efektů

8.1       Měření efektů

8.2       Měření služeb

8.3       Měření zdrojů

9      Závěry

10        Použitá literatura

11        Přílohy

1.     Použité termíny

2.     Případová studie – manažerský IS

3.     Outsourcingové kontrakty v ČR

4.     Checklist smlouvy na outsourcing

 

1       Úvod

Tato práce je zaměřená na jeden aspekt řízení podnikové informatiky zejména středních a velkých podniků, a to na aspekt služeb, který je podmínkou pro možnost řízení podnikové informatiky v modelu operativního outsourcingu.

 

Disertace navazuje na diplomovou práci Outsourcing IS/IT [Bruckner1] a na monografii Outsourcing informačních systémů [BrVo], a je jejich rozšířením. Základy problematiky uvedeny v těchto publikacích zde nejsou opakovány.

 

Cíl disertace:

Komplexně popsat podmínky a principy, které v řízení podnikové informatiky umožní účinně řídit informatické služby při možnosti jejich outsourcingu a v situaci současných světových trendů nabídky trhu IT a trhu služeb IS/IT, a to uceleně jako alternativu ke konvenčnímu současnému řízení podnikové informatiky.

 

Dílčí cíle:

·          Určit kompetence podnikové informatiky.

·          Popsat současnou situaci možného outsourcingu informatiky z hlediska světových trendů a z pohledu procesů podniku, a to s ohledem na možnost komplexního outsourcingu oblasti informatiky, částečného operativního outsourcingu informatiky a outsourcingu jiných obchodních procesů.

·          Určit principy řízení procesů v informatice, které umožní operativní outsourcing.

·          Určit principy řízení požadavků a změn v podniku v návaznosti na řízení procesů a principy, které pomohou účinně řídit potřeby a přání na informatickou podporu v podniku.

·          Určit principy služeb informatiky, principy celostního řízení služeb informatiky i principy řízení jednotlivých služeb.

·          Popsat model možného řízení služeb a jejich zdrojů, popsat specifika vlastnictví informatických zdrojů.

·          Určit principy měření efektů (splnění potřeb pomocí informatiky) a principy měření plnění služeb informatiky.

 

Vývoj na trhu informačních technologií a na trhu nabídky informatických služeb je v posledních letech velmi dynamický a umožňuje podnikům zajistit informatiku novými způsoby, zejména outsourcingem. Současný pohled na řízení outsourcingu i informatiky tyto trendy dostatečně neakcentuje a tedy za vývojem nabídky zaostává. Proto dochází při řízení externích informatických služeb často k nezdaru.

Vytvoření nového komplexního pohledu na řízení informatických služeb a jeho principů z pohledu podniku (jehož hlavní činností není primárně informatika) je tedy pro optimální řízení z poptávající strany nezbytné. Tento aspekt ospravedlňuje práci jak z hlediska akademického, tak praktického.

Smysl práce spočívá i v podrobném a principiálním rozvedení podmínek outsourcingu a tedy v umožnění stability a vývoje outsourcingových vztahů v informatice tak, aby to bylo efektivní z pohledu podnikových procesů, podnikové informatiky, dodavatele i obecně.

 

Vzhledem k charakteru disertace není vhodné pojmy definovat v úvodu práce, ale jsou vytvářeny postupně v textu. Uceleně jsou pojmy vysvětleny v příloze práce.

 

 

Metodika dosažení stanovených cílů

Postup dosažení primárního cíle byl rozdělen do dílčích cílů, které určují strukturu disertace.

 

Základní principy řízení informatiky z hlediska služeb byly získány ze základních principů outsourcingu, a dále byly vzaty v úvahu zejména tržní principy založené na zájmech jednotlivých stran a současné trendy (jak je uvedeno v textu).

 

Kromě těchto aspektů byly vzaty v úvahu praktické zkušenosti s vytvářením a řízením outsourcingového vztahu zejména mezi Jihočeskou energetikou, a.s. a Gedos Synergií, a.s. [BruDvPl], a další zkušenosti z některých podniků a řízení jejich informatiky a outsourcingu.

 

Během vzniku textu docházelo k analýze možností v jednotlivých konkrétních situacích, které v daném momentu problematiky mohou nastat. Některé myšlenky řízení služeb informatiky vznikly jako náhlý nápad, některé jako vhodné řešení problematických praktických situací. Principy těchto řešení jsem ve světové teoretické literatuře ani v konkrétních případech podnikové praxe nenašel. Hlavním problémem práce bylo popsat podrobně podmínky, předpoklady a východiska těchto řešení, aby bylo možné je jednak vědecky přijmout jako možné přístupy řešení podnikové informatiky, a jednak bezpečně uplatnit v konkrétních praktických případech.

Z původních postupů a popisů byl text zkrácen tak, aby byly dostatečně výstižně a kompaktně popsány naléhavé principy, ale zároveň aby text zůstal v dostatečné míře srozumitelný.

 

Snahou bylo problematiku zformovat do logicky koherentního, ale zároveň myšlenkově otevřeného uceleného tvaru tak, aby byly v textu vždy včas uvedeny veškeré nutné věcné podmínky myšlenkových konstrukcí, a aby pohledy na problém služeb informatiky v podmínkách outsourcingu byly vždy vysvětleny v celé jejich komplexnosti, případně nutnosti. Tento přístup znamená, že jakákoliv část textu navazuje logicky na část předchozí, a je nutné číst od začátku, aby veškerá barvitost a nutnost myšlenek byla čtenáři bezezbytku zřejmá.  Tento přístup byl zachován i přes případnou obtížnost textu při zběžném čtení. Pro koherenci textu bylo také nutné zabývat se myšlenkami, které nejsou zcela nové, zejména v částech, které se týkají řízení požadavků a změn.

 

Konfrontace s konvenčními přístupy k řízení podnikové informatiky jsou uvedeny vždy na místech, kde je vhodné nebo nutné na rozdíl upozornit.

 

Výsledkem práce je tato disertace jako úvaha, doplněná o specifické části problematiky v přílohách.

 

Problematika vzhledem k jejímu charakteru nebyla pojata kvantitativně. Problematika kvantifikace v otázkách měření služeb a efektů služeb byla opět pro srozumitelnost popsána narativně, ale tak, aby to nebylo na újmu její exaktnosti.

 

Stav řešení problematiky v ČR a ve světě je uváděn v průběhu textu a souborně jej odráží použitá literatura.

Problematika outsourcingu je řešena zejména v komerční oblasti mimo akademickou sféru, a to ve firmách, které se zabývají poskytováním outsourcingových služeb nebo ve firmách, které se zabývají konzultační činností v oblasti outsourcingu ([OI], [Gartner] a další). Jejich rozpracování problematiky však není obvykle veřejně dostupné, vyjma útržků. V akademické sféře je uvedená problematika řešena na Fakultě informatiky a statistiky VŠE[1]. Na toto rozpracování text v některých částech navazuje.

Ve světě se problematikou outsourcingu informatiky akademicky zabývají zejména D. Minoli, M. Lacity, J. Halvey, R. Hirschheim, B. Melby M. F. Corbett a další[2].

 

Zde zvolené pojetí pohledu na informatiku jako na služby a zejména akcent na operativní outsourcing považuji za nový přístup a ve světové ani tuzemské literatuře jsem je uceleně rozpracované neobjevil.

 

Text je členěn v návaznosti na dílčí cíle práce.

 

obr. 1,  Struktura disertace

2       Outsourcing informatiky v dnešním světě

Tato kapitola popisuje stav, možnosti a problémy využití outsourcingu IS v dnešní situaci na trhu z hlediska podniku, který je nucen zajistit informatickou podporu svého podnikání.

V celém textu se budeme zabývat podnikovou informatikou, a tedy úvodem vymezíme kompetence informatiky v podniku.

Nejprve se podíváme na postavení informatiky při procesním pohledu na podnik. Zjistíme, že povětšinou se jedná o podpůrný proces. Některé součásti informatiky však jsou strategické. Ukážeme, že vývoj v oblasti IT je tak rychlý, že cyklus strategického plánování v oblasti informatiky podniku se zkracuje někdy až na jeden měsíc.

Dále se zaměříme na trend rostoucí komplexity v informačních technologiích. Ukážeme, co tento termín znamená a jaké má dopady na řízení informatiky. Podíváme se dále na vliv tohoto trendu na lidské zdroje v informatice a na vztahy s více dodavateli.

Podíváme se na informatiku podniku z hlediska jejího dodavatelského zabezpečení. Vymezíme dnes nejběžnější způsob a srovnáme jej s dvěma modely řízení informatiky, s modelem totálního outsourcingu informatiky a s modelem, který předpokládáme bude tvořit trend nejbližších let, s modelem „CIO jako IT broker“.

U modelu „CIO jako IT boker“ se podíváme na výrazné trendy, které využití tohoto modelu podporují, a to na trend ASP – Application Service Providers a na trend mezipodnikové obchodní integrace (B2B), obojí v souvislosti s rozvojem Internetu. U modelu totálního outsourcingu pak především na trend integrace aplikací a dat podniku.

Zjistíme, že dodavatelské zajištění i procesní přístup k informatice vynucuje pohled služeb informatiky, nikoli pohled zdrojů a činností, jaký je dosud běžný. V souvislosti s nastíněnými novými možnostmi zjištění informatiky podniku dále ukážeme problémy a rizika, které musí podniky nově řešit. Zjistíme, že podstatným problémem je specifikace služeb informatiky tak, aby skutečně mohlo dojít k transferu odpovědnosti na poskytovatele, což je uváděno jako ne vždy dosažitelná výhoda outsourcingu.

Na závěr kapitoly vymezíme podmínky modelu operativního outsourcingu, a tím ospravedlníme obsah dalšího textu.

2.1    Kompetence podnikové informatiky

Na informatiku podniku lze pohlížet různými způsoby. Kompetence informatiky je nutné definovat, aby bylo zřejmé, jaké funkce tato oblast pro podnik má, a jaké jsou tedy odpovědnosti a pravomoci ředitele informatiky CIO. Zároveň je smyslem definice kompetencí informatiky podniku odebrat některé možnosti ostatním složkám podniku.

 

Z pohledu řízení podniku lze informatiku chápat jako fenomén, který zcela ovlivňuje dnešní přístup k podnikání a řízení podniku, se zahrnutím typů systémových přístupů, reinženýringu podnikových procesů, znalostních přístupů, učící se organizace, informační společnosti a dalších různých faktorů a principů moderního podnikového managementu, které nějakým způsobem akcentují důležitost informací pro řízení. Typické je, že k rozvoji teoretické disciplíny podnikového managementu často přispívají právě teoretici z oblasti informatiky. Zde se na podnikovou informatiku takto celostně dívat nebudeme.

 

Jinou možností je dívat se na informatiku podniku z technologického pohledu, jako na možnosti a způsoby využití technologií nebo na technologické způsoby vývoje informačních systémů. Tento pohled také nepoužijeme.

 

Zde zvolíme pohled, který je střední cestou mezi těmito dvěma uvedenými, a vymezíme zde kompetence podnikové informatiky, tak jak je chápána v mnoha podnicích. I tento pohled je při řízení podniku nepřehlédnutelný a důležitý, a přestože neakcentuje informatiku v celé její barvitosti, uvidíme dále, že je pro naši problematiku nejvhodnější.

 

Kompetencí informatiky podniku je v plném rozsahu řídit aktivity, které jsou spojené se zajištěním služeb informačních technologií, tedy služeb počítačového zpracování informací a elektronické komunikace (a to dnes včetně komunikace hlasové), pro ostatní aktivity v podniku, zejména podnikatelské, nebo přímo pro zákazníka podniku.

 

Tuto kompetenci nese obvykle ředitel informatiky, Chief Information Officer, který je důležitou součástí vrcholového řízení podniku. Pod jeho řízením kompetenci informatiky obvykle zajišťuje nějaký útvar, divize, funkční místo, kterému zde říkáme oblast informatiky, nebo zkráceně informatika podniku.

 

Kompetenci informatiky vymezujeme jako služby počítačového zpracování informací. To je důležité, protože součástí odpovědnosti za zpracování dat není odpovědnost za obsah a správnost vstupních dat tohoto zpracování. Odpovědnost za obsah dat tedy není součástí kompetence informatiky podniku a ponecháme ji podporovaným oblastem v podniku.

 

S ohledem na velmi úzkou souvislost informační technologie a organizace podniku (procesního uspořádání, toku dokumentů apod.) bývá často k informatice přiřazena i oblast organizace podniku. Přesto oblast organizace nepovažujme za součást informatiky, je to jiná kompetenční oblast, která jen z některých důvodů bývá často správně zařazena do kompetencí jedné osoby, ředitele informatiky CIO.

 

Toto obecné vymezení kompetencí informatiky podniku vyděluje z řízení zbylých oblastí podniku specializovanou oblast, která prožívá velmi rychlý a často nesnadno sledovatelný technologický rozvoj. Tato specializace umožní sledování a zachycení trendů v těchto technologiích a jejich možné začlenění a využití pro podnik, a zároveň umožní ostatním složkám řízení podniku koncentrovat se na své kompetence, bez nutnosti zabývat se složitou problematikou informačních technologií. Zároveň oddělení řízení informatiky neznamená nebezpečí zanedbání této oblasti ve vrcholovém řízení, protože ředitel informatiky je členem vrcholového vedení podniku.

 

Přestože je obecné určení kompetencí informatiky výstižné, je nutné je pro konkrétní případ podnikové praxe vymezit mnohem přesněji, aby nemohlo dojít ke kompetenčním sporům. Důležité je zajistit, aby informatika podniku skutečně byla centrálně řízena a aby nebylo možné v podniku nakupovat služby informatiky jiným kanálem než právě prostřednictvím podnikové informatiky. Vhodné vymezení je možné například určením hranic informatiky, tedy služeb nebo oblastí, u kterých není zcela zřejmé, zda jsou součástí informatiky nebo jiné podnikové oblasti. Jiným způsobem může být například určení úplným výčtem.

 

My zde určíme kompetence informatiky právě specifikací služeb, které může v podniku obvykle nabídnout.

 

Je nutné zdůraznit zatím ne zcela samozřejmou věc, která je však v posledních letech trendem, a sice, že do podnikové informatiky začíná být zvykem zahrnovat také veškeré komunikační a telekomunikační služby, které bylo dříve obvyklé řídit separátně. Zde tedy zahrneme do kompetencí informatiky i tuto oblast.

2.2    Procesní pohled na informatiku podniku

Zde se podíváme na informatiku podniku jako na proces. Tento pohled je základem pro veškeré další úvahy.

Zaveďme si pracovní definici procesu jako sled činností, které jsou orientovány na vytvoření nějakého výsledku, produktu, který je určen někomu, komu budeme říkat zákazník procesu.

V podniku probíhá mnoho procesů, které mají své zákazníky. Pokud zákazníkem procesu je zákazník podniku, který plní cíle podniku (generuje obrat apod.), může podnik považovat takový proces za klíčový neboli hlavní proces podniku (core process). Z dlouhodobého hlediska je vhodné za hlavní procesy podniku považovat ty z nich, které jsou motorem dlouhodobé konkurenceschopnosti podniku, tedy které jsou dlouhodobě schopny získat nebo udržet zákazníky. Ostatní procesy, aby měly v podniku smysl, by měly nějakým způsobem podpořit hlavní procesy – hlavní procesy by měly být jejich zákazníky, nebo by měly být řídícími procesy, které jiné procesy ovládají.

 

Odhlédněme od toho, že pomocí informačního systému můžeme řídit, sledovat nebo restrukturalizovat podnikové procesy a podívejme se na informatiku podniku také jako na takový proces. V takovém případě nás musí zajímat

·          jaký výsledek, jaký produkt informatika vytváří,

·          a pro jakého zákazníka.

Produkt informatiky můžeme chápat jako služby informačního systému. Vrátíme se k nim později. Kdo je zákazníkem, kterému jsou tyto služby poskytovány? Příjemci služeb informatiky jsou jednak uživatelé a jednak zákazníci informatiky. Tyto dva pojmy od sebe odlišíme.

Obvykle se o zákaznících procesu informatiky hovoří jako o uživatelích. Zde však tento termín nebudeme v tomto smyslu používat, přestože by to v textu bylo přehlednější. Mezi zákazníkem informatiky a uživatelem služeb informatiky je totiž rozdíl. Zákazníkem je ten, kdo rozhoduje o využití těchto služeb. To nemusí být nutně vždy uživatel. Může to být třeba řídící pracovník, který služby nějaké konkrétní části informačního systému vůbec neužívá. Naopak, někteří uživatelé mají nařízeno užívat služby informačního systému tak, jak jsou, a jejich přání nejsou významná, a tedy nejsou zákazníky informatiky. Někdy dokonce služby informatiky nemusí mít žádného uživatele, například v případě, že výstupy informačního systému užívá pouze jiný automatizovaný informační systém. Je nutné tedy požadovat po čtenáři zvýšenou pozornost, protože se na některých místech v textu budou vedle sebe vyskytovat termíny „zákazník informatiky“ a „zákazník podporovaného procesu“ (rozuměj procesu podporovaného informatikou), což může být na první pohled matoucí.

 

Podstatným hlediskem je, že zákazník informatiky je

·          buď uvnitř podniku

·          nebo vně podniku.

Uvnitř podniku jsou to zákazníci a uživatelé – pracovníci podniku, vně jsou to buď dodavatelé nebo zákazníci podniku. Pokud jsou zákazníky informatiky osoby, které jsou zároveň zákazníky podniku, pak může být informatika podniku (nebo její část) hlavním procesem podniku.

Pokud to tak není, pak je informatika podpůrným procesem podniku, který by měl, ať už přímo nebo zprostředkovaně, podpořit procesy, které pro podnik hlavními jsou. Obvykle je informatika podpůrným procesem.[3]

 

Pokud zákazník plní cíle podniku, měl by podnik plnit přání (potřeby) zákazníka, aby jej získal k plnění svých cílů nebo při tom udržel. Pokud produkt hlavního procesu podniku nesplní přání (potřeby) zákazníka lépe než produkt konkurence, zákazníka nezíská nebo neudrží. To tvoří tlak na dobrou znalost a co nejlepší plnění přání (potřeb) zákazníka. Totéž se týká procesů. Podpůrné procesy jsou v podniku proto, aby vhodně podpořily procesy hlavní (které plní přání zákazníka podniku), tedy by měly plnit přání svých zákazníků – pracovníků podniku, kteří zajišťují hlavní procesy. Analogicky je tedy vhodné i podpůrné procesy, respektive jejich produkty v podniku podrobit konkurenci, aby tak byl vytvořen tlak na orientaci procesů na zákazníka. To ovšem neznamená realizovat v podniku proces několikrát (i když i to je zajímavé řešení), ale spíše podrobit produkt procesu a jeho cenu srovnání s případným zajištěním externím, tedy outsourcingu.

Toto řízení může být účinným způsobem řízení procesů, jak uvidíme dále. V případě, že úspory z rozsahu mohou převýšit transakční náklady takových aktivit, můžeme v budoucnu čekat rozdrobení podniků na holé hlavní procesy, protože lze předpokládat, že z důvodu úspor z rozsahu bude možné zajistit procesy efektivněji externě.

 

I v případě, že podpůrné procesy podniku nejsou v konkurenčním prostředí, je vhodné, aby plnily přání (potřeby) svých zákazníků (tedy hlavních procesů podniku případně jiných podpůrných procesů). Argumentem pro to je skutečnost, že tímto způsobem se promítnou zpětně do všech procesů podniku přání (potřeby) zákazníka podniku (viz obr. 2). Vnitropodnikový monopol podpůrných procesů v podniku je však v takovém případě nutné redukovat mocenským (manažerským) řízením produktu podporovaného procesu a jeho nákladů, aby byly srovnatelné s konkurencí, tedy benchmarkingem. Výhodou tohoto přístupu je i připravenost procesů na jejich případné vystavení konkurenci v budoucnu.

 

obr. 2,  Řetězec plnění přání

 

Takový přístup umožňuje řízení podniku prostřednictvím zájmů. Hovoříme-li o „přání“ nebo „potřebách“, je nutné počítat s tím, že přání a potřeby mají vždy lidé, a nikoli podniky nebo procesy. V případě koncového spotřebitele je situace jasná, jedná se o jeho vlastní přání nebo potřebu. V případě zákazníka-podniku jde o přání (potřebu) jeho zaměstnanců, kteří rozhodují o nákupu. V případě produktu procesů uvnitř podniku jde o přání zaměstnanců, kteří rozhodují o využití produktu procesu, případně těch, kteří jej užívají. Tyto principy umožní distribuovat řízení na úroveň procesů. To znamená nechat protagonisty procesů plnit co nejlépe přání svých zákazníků, a nechat je přitom rozhodovat o tom, jaké produkty kterých podpůrných procesů k tomu použijí. Tím budou svými potřebami a svým přáním řídit výstupy podpůrných procesů a zprostředkovaně i jejich průběh. Toto je ale kritické místo: zde musíme předpokládat (a ovšem i kontrolovat), že přání protagonistů procesu – zákazníka jsou shodná s tím, co je potřeba, aby tyto procesy byly efektivní. S tím lze počítat pouze v případě, že jsou odpovědnosti nastaveny tak, aby byly vytvořeny následující podmínky:

·          protagonisté procesů mají zájem na co nejlepším plnění přání zákazníků svých procesů, což znamená, že jsou hodnoceni podle toho, jak dalece plní cíle zákazníka, případně podle toho, jak zákazníci plní cíle podniku.

·          protagonisté procesů mají zájem na tom, aby náklady na jejich procesy byly co nejnižší, což znamená, že jsou hodnoceni podle toho, jak nízké mají náklady nebo jaké mají úspory.

·          protagonisté procesů jsou chráněni proti pokušení předchozí dvě podmínky porušovat.

Této problematice bude věnována kapitola Distribuce řízení na procesy.

 

Mluvíme-li zde obecně o podpůrných procesech, máme na mysli zejména informatiku podniku. Můžeme tedy shrnout:

Informatika podniku by měla produkovat takový výstup, aby plnila přání svých zákazníků, tedy buď přímo zákazníků podniku nebo ostatních procesů v podniku.

 

Situaci v managementu mnoha českých podniků, kdy produkt podniku není podřízen přání zákazníka, s lítostí pomineme.

 

Pro ozřejmění uveďme příklad o rozhodování, zda je informatika hlavním procesem.

Banka poskytuje svým klientům přístup k zůstatku a operacím s běžným účtem prostřednictvím Internetu. Podívejme se, jak pohlížet na informatiku banky z hlediska procesů. Produktem hlavního procesu banky je poskytnutí služeb běžného účtu klientovi.

1.       Produktem informatiky je jednak podpořit poskytování služeb běžného účtu zákazníkovi banky. Zákazníkem procesu informatiky je v tomto případě hlavní proces banky – poskytování služeb běžného účtu. Proces informatiky může snížit náklady na tento hlavní proces (např. oproti zpracování papírových platebních příkazů), tím zlevnit službu a získat nebo udržet zákazníky banky.

2.       Informatika vedle toho klientovi banky zprostředkovává služby běžného účtu. Je tedy zprostředkovatelem služby a přidává k ní hodnotu pro klienta (nemusí dojít do banky s příkazem). Zároveň je tedy zákazníkem informatiky banky klient banky.

Proces informatiky zde tedy má dva zákazníky a měl by plnit přání každého z nich, respektive ta přání, která podpoří zájmy obou zároveň.

Vzhledem k tomu, že je informatika orientovaná také přímo na klienta banky, může být hlavním procesem banky. Pak je na úvaze banky, zda jej za svůj hlavní proces bude považovat. Management může uvažovat:

-          Služby tohoto procesu jsou jednoduché. Na sdělení zůstatku a operacích s běžným účtem přes Internet nelze nic moc vymyslet a všechny banky je budou mít za několik let shodné. Není to náš hlavní proces.

-          Nebo: Služby operací s běžným účtem na Internetu zajistíme vždy lépe a komfortněji pro zákazníka než naše konkurence a tím si získáme mnoho dalších zákazníků této služby. Je to náš hlavní proces.

Pokud by se banka rozhodla, že informatický proces zajištění přístupu k zůstatku a operacím s běžným účtem není hlavním procesem, pak může uvažovat o jeho outsourcingu. Pak může vzniknout na trhu poskytovatel, který se bude pro více bank a jejich klienty zabývat právě takovými službami.

 

Dále v textu budeme procesy informatiky pojímat primárně jako procesy podpůrné. Jak uvidíme dále, není to na újmu. Pokud by se pro podnik informatika stala procesem hlavním, na zde uvedených principech řízení se mnoho nezmění. Některá hlediska, ze kterých je nutné proces řídit, však přibudou nebo se stanou naléhavějšími, zejména pohled konkurence, marketingu a prodeje.

2.3    Strategické plánování informatiky

Nyní máme hledisko určení, zda je nějaký informatický proces v podniku procesem podpůrným nebo procesem hlavním. Nyní určíme, co rozumět procesem strategickým, a zaměříme se na možnost chápat i podpůrné procesy jako strategické.

Zatímco při určování, zda je nějaký proces hlavním, hraje roli především jeho orientace na zákazníka a předpokládaný vliv na budoucí plnění cílů podniku, zejména konkurenceschopnost, tedy hledisko aktivní na trhu, při určování, zda je proces strategický, může být vedle aktivního pohledu důležité další, pasivní hledisko, a to schopnost dodavatelského trhu zajistit produkt procesu, tedy nákup.

Hlavní proces můžeme vždy považovat za strategický. I zde je ale nutné pasivní hledisko, obvykle je však splněno implicitně. Pokud má být produkt procesu důležitý pro konkurenceschopnost podniku na trhu, je nutné produkt procesu umět zajistit, a to nejen interně (což může management přímo ovlivňovat), ale i za pomoci subdodávek (materiálu, meziproduktů apod.). Pokud je podnik schopen tyto subdodávky na dodavatelském trhu snadno nakoupit, pak dodavatelské procesy, které je generují, pro podnik nejsou strategickými. Pokud je například kvalita subdodávek nedostatečná nebo existuje jen málo a ještě nespolehlivých dodavatelů, je vhodné, aby podnik uvažoval o začlenění dosud dodavatelského procesu do interního hlavního procesu.

Z hlediska řízení informatiky podniku je ale zajímavější pohled na podpůrné procesy. I podpůrné procesy mohou být strategické ze zcela stejného (dodavatelského) důvodu. Hlavní procesy vyžadují pro svou podporu produkt podpůrného procesu. Pokud je podnik schopen tento produkt snadno nakoupit, tedy existuje tržní nabídka ve vhodném rozsahu a parametrech, pak takový podpůrný proces strategickým nenazveme. Pokud ale taková dostatečná nabídka není, pak i podpůrný proces může být pro podnik strategickým. Pokud by jej podnik nezajistil interně, nebylo by možné hlavní proces vhodně podpořit a jeho výsledek by nebyl konkurenceschopný.

 

S tím souvisí schopnosti a kompetence podniku vůbec proces zajistit. Pokud pohled možnosti nákupu transformujeme do pohledu podnikových schopností a kompetencí, můžeme podmínku reformulovat: Výstupy strategických  procesů musí být podnik schopen zajistit lépe, než jak je možné je nakoupit na trhu. Pokud z hlediska nabídky trhu není proces považován za strategický, pak je pohled schopností a kompetencí podstatným pro rozhodování, zda proces zajistit interně nebo jej outsourcovat (jeho produkt nakoupit).

 

Shrňme: Za hlavní proces považujeme takový proces, jehož produkt je orientován na zákazníka plnícího cíle podniku a který podnik považuje za důležitý z hlediska dlouhodobé konkurenceschopnosti. Za strategický proces považujeme hlavní procesy, a dále procesy, jejichž produkt je pro podnik nezbytný, ale tento produkt nelze snadno zajistit dodavatelsky.

 

Uveďme příklad:

Podnik vyrábí nějaké výrobky a prodává je. To je jeho hlavní a tedy strategický proces. Pro výrobu ale potřebuje nutně elektrický proud.

Výroba elektrického proudu a dodávka do místa výroby je pro podnik podpůrným procesem, ale patrně nebude procesem strategickým. Elektrická energie je sice pro podnik nezbytná, ale i přestože na trhu dodávek elektrické energie je pouze jeden dodavatel či distributor, nakoupit elektřinu v požadovaném rozsahu je snadné a bezproblémové.

To ovšem nemusí platit například po válce, kdy je energetická soustava zničena. V takovém případě se proces výroby a dodávky energie stává pro podnik strategickým, a je vhodné, aby se jeho zajištěním podnik strategicky zabýval.

Další situace může nastat, když dodávky elektrické energie mají časté výpadky, které jsou pro podnik (pro jeho hlavní proces – výrobu) kritické, protože výroba musí běžet z nějakých strategických důvodů kontinuálně. Pak dodávku elektrické energie z veřejné sítě sice lze snadno nakoupit, ale nelze ji považovat za produkt v takových parametrech, které jsou pro podnik dostatečné. Potom lze za strategický proces určit například zajištění dodávky elektrické energie nepřetržitě 24 hodin denně. Tento proces může například podnik zajistit interně, přičemž zdroji, které tento proces bude využívat, bude jednak snadno dostupná dodávka z veřejné sítě s výpadky a jednak přídavný generátor elektrické energie na naftu, který při výpadku veřejné sítě zajistí parametry požadované na podporu hlavního procesu podniku dodávkou elektrické energie.[4]

 

Takto zavedenými pojmy není jistě vystižena veškerá barvitost a všechny nuance pojmu „strategický“. Berme tyto definice jako účelové pro naši problematiku a potažmo i pro návod pro rozhodování, které podnikové aktivity považovat za důležité a které za méně důležité pro podnik, zejména z pohledu procesů informatických a jejich možného outsourcingu. To ovšem nic neubírá jejich obecnosti.

 

Lze tedy určit, které informatické procesy v podniku považovat za strategické a které nikoliv. Produkty informatických procesů, zvláště pokud jde např. o služby aplikačního software typu ERP, jsou pro podnik specifické a vyžadují dlouhou přípravu, než lze tyto služby užívat. Při posuzování, zda takové podpůrné informatické procesy jsou strategické, je pak hlavním problémem určení

·          které služby informatiky, v jaké míře a jakých parametrech jsou pro podnik nezbytné, co je nutné a co zbytný luxus;

·          jak lze tyto služby zajistit dodavatelsky, tedy jaká je nabídka na trhu těchto služeb, případně zda tento trh vůbec existuje;

·          a jak dalece je toto dodavatelské zajištění pro podnik „snadné“, tedy zvláště jaké jsou transakční náklady na jejich nákup.

 

V dnešní době se na trhu informačních a komunikačních technologií a informačních systémů a služeb objevují nové produkty nebo produkty ve stále se zlepšujících parametrech. Některé tyto produkty sice mohou být spotřebitelské, ale častěji se jedná o produkty pro podporu jiných procesů podniku. Z pohledu podniků, jejichž hlavním procesem není poskytovat právě tyto produkty, tedy jsou tyto produkty produkty podpůrných procesů, které pro podnik nejsou strategické (snadno je lze nakoupit). Trendem je rostoucí nabídka právě produktů, které bylo obvyklé zajišťovat v podnicích interně. Procesy, jejichž výsledkem v podniku byly tyto produkty, pokud dříve byly pro podniky strategické, strategickými přestávají být, a to opět z důvodu, že je nově lze nakoupit na dodavatelském trhu. Podniky tedy jsou nuceny nově uvažovat o tom, zda je zajišťovat nadále interně nebo je nakupovat, tedy o outsourcingu.

Nejde ovšem jen o produkty dříve zajišťované interně, ale objevují se i produkty zcela nové. O těch jsou podniky nově nuceny uvažovat jako o možném využití pro své hlavní procesy, jako o nových produktech pro své zákazníky, viz příklad o službách běžných účtů přes Internet výše, nebo alespoň pro optimalizaci hlavních procesů například snížením nákladů na komunikaci nebo zvýšením pracovního výkonu zaměstnanců, což se může ukázat jako nezbytný parametr produktu informatiky z hlediska zajištění dlouhodobé konkurenceschopnosti produktů podniku.

 

Toto rozhodování o strategii v oblasti procesů informatiky je z důvodů agility nabídky trhů informačních a komunikačních technologií a informačních systémů a služeb téměř kontinuální. V oblasti strategie informatiky podniku je mnohem zřetelnější nutnost zkracování strategických plánovacích cyklů než v oblasti podnikových strategií vůbec (přestože rozhodně není naléhavější). Cyklus revize strategie informatiky dnes začíná být nutný alespoň měsíční a cyklus kompletní obnovy strategie alespoň roční.[5] Dnes tedy není výjimkou změna strategických cílů informatiky ze dne na den. Je tedy nutno počítat se zvyšující se pravděpodobností zastavení informatických projektů v brzkých fázích rozběhu, ale i těsně před dokončením, s ohledem pouze na budoucnost ze startovní čáry a bez ohledu na již proinvestované a vynaložené prostředky. Tento trend také tlačí na eliminaci rizika špatné investice do informatiky, a nahrává možnostem informatické procesy spíše outsourcovat. Z toho důvodu můžeme tedy reálně očekávat odliv informatiků z podniků – zákazníků služeb IS/IT k podnikům – dodavatelům těchto služeb. Zároveň ale bude pro podniky přinejmenším vhodné, aby se lidé odpovědní za strategické řízení podniku, tedy vrcholoví manažeři, dobře orientovali ve světě informatiky.

 

Rozhodování o tom, které části informatiky podniku jsou pro podnik strategické, nelze outsourcovat. To je část řízení informatiky, která by vždy měla zůstat v rukách podniku.

 

Přestože informatika stále více ovlivňuje i chod podniků s neinformatickými produkty, většina informatických procesů může stále pro podniky zůstat podpůrnými a nestrategickými. Je však nutné informatiku vhodně řídit tak, aby mohla být vždy včas informaticky podpořena konkurenceschopnost hlavních procesů podniku. Sofistikované strategické řízení informatiky je tedy pro podnik a jeho produkt nezbytné[6]. Zde uvedený pohled odlišuje strategické řízení informatiky (nezbytné pro konkurenceschopnost) od produktivních procesů v informatice, které skutečně ze své podstaty často zůstávají podpůrnými (nejsou-li to procesy hlavní, orientované na zákazníka).

 

Z toho plynou požadavky na řízení informatiky podniku, tedy požadavky na ředitele informatiky a na jeho odpovědnost. Rolí CIO je tedy:

·          Nabízet a navrhovat hlavním procesům možnost zvýšení jejich konkurenceschopnosti pomocí informatiky.

·          Organizovat produktivní procesy informatiky, aby podpořily přání podporovaných procesů.

Ke kompetencím ředitele informatiky se ještě vrátíme.

 

Shrňme ještě jednou, jaké procesy jsou pro podnik strategické, a jaké tedy není vhodné outsourcovat. Jsou to:

·          hlavní procesy, které jsou motorem dlouhodobé konkurenceschopnosti podniku,

·          procesy, jejichž produkty nelze snadno nakoupit na trhu,

·          procesy, jejichž produkty podnik umí zajistit lépe, než jak je lze na trhu nakoupit.

 

 

obr. 3,  Rozhodování „make or buy“, hlavní a strategické procesy

2.4    Rostoucí komplexita v informačních technologiích

Dále se zaměřme na některé výrazné trendy, které bychom mohli shrnout pod termín rostoucí složitost v informačních technologiích. Nejprve vysvětlíme podstatu rostoucí komplexity v informačních technologiích, popíšeme komplexitu na příkladu distribuovaných aplikací, poté se zaměříme na vliv tohoto trendu na lidské zdroje v informatice, na přístup podniků ke vztahům s více dodavateli a na nový termín „únava ze změn“.

 

Za základní a nejtíživější trend v oblasti informačních technologií, který má dnes a bude mít i v brzkém budoucnu podstatný vliv na řízení podnikových informačních systémů a technologií, můžeme považovat rostoucí komplexitu informačních technologií. Tento trend v sobě zahrnuje několik aspektů dnešního světa informačních technologií, a na ty se zde podíváme.

Podstata rostoucí komplexity spočívá v rychlém technologickém rozvoji v oblasti informačních technologií. Jedná se o celou škálu technologií od stále rychlejších procesorů přes měnící se standardní sestavy počítačů, různé metody a metodiky vývoje informačních systémů, nová aplikační a databázová prostředí až po změny architektur a celkového pohledu na informační systémy. Rozvoj technologií neprobíhá jednou cestou, ale neustále vzniká širší pole použitelných technologií pro řešení jednoho problému. Pro řízení informatiky podniku je dnes velmi náročné (na čas a specializovanou kvalifikaci) a nákladné sledovat neustále nově se objevující trendy a rozhodovat o jejich využití a integraci mezi stávající systémy.

Samotný technologický vývoj však největším problémem pro řízení informatiky podniku není. Ideálně by dokonalejší a efektivnější technologie měla podniku pomoci, realita je ale opačná. Z technologického vývoje dělá problém skutečnost, že s postupem času se v podniku vedle sebe kupí stále více různých použitých technologií. Čím více je v informačním systému použito technologií, tím je náročnější informační systém řídit a tím vyšší jsou náklady na údržbu a na drobné změny. Nutnost zabývat se řízením změn v IS je proto stále naléhavější.

 

Pro názornost uvedeme dostatečně barvitý příklad situace:

Dnes lze v jednom podniku najít centralizované aplikace, které spolupracují s novějšími distribuovanými aplikacemi a s desktop aplikacemi na osobních počítačích a nově i s intranetovými aplikacemi. Tyto aplikace používají několik různých databázových systémů. Aplikace kancelářského systému jsou pro různé uživatele implementovány současně v několika po sobě jdoucích vzájemně neslučitelných verzích. Osobní počítače mají různé operační systémy a různé konfigurace, zaměstnanci začínají používat připojení k podnikovému informačnímu systému ze svých domovů a pomocí mobilních zařízení. Spolupráce mezi různými aplikacemi byla řešena předáváním textových souborů a dnes běží projekty jejich vzájemného on-line provázání. V dokumentaci k centrálním aplikacím v COBOLu se vyzná posledních několik zaměstnanců, nové intranetové aplikace vyvíjí několik mladých nadšenců ve svém oblíbeném vývojovém nástroji inkrementálně. Pouze tito lidé jsou schopni kvalifikovaně provádět v aplikacích drobné změny. Distribuované aplikace byly dodány jako softwarový balík. Parametrizace a drobné změny v aplikaci je nutné vždy při nové verzi balíku testovat, zda budou pracovat shodně jako v minulé verzi a zda budou pracovat vůbec. Nové verze balíku je nutné stále nakupovat, protože starší verze dodavatel přestane po určité době podporovat a údržba pak již nebude vůbec možná. Při migracích do nových verzí aplikačního balíku je nutné posílit výpočetní výkon serverů, přenosovou kapacitu sítí a konfigurace klientských pracovišť. Specialisté, kteří jsou schopni řešit podrobné problémy v aplikaci, se nevyznají v lokálních podmínkách a cena jejich práce je srovnatelná s cenou práce stovky zedníků. Licenční politika dodavatelů software se neustále mění a od jednoho dodavatele v podniku existují desítky typů licencí k užívání software. Navíc dále zvyšují komplexitu nově hromadně používané síťové aplikace s uživatelem řízenou komunikací, zejména globální elektronická pošta, stahování souborů nebo mezinárodní výzkum pomocí služby World Wide Web. A aplikační pohled je jen jeden z mnoha, kterými je možné rostoucí komplexitu dokumentovat.

 

obr. 4,  Rostoucí komplexita podnikových IT

 

Jakmile dojde k rozšíření informačního systému podniku o nějakou část zahrnující novou technologii, je nutné tuto technologii do stávajícího systému zaintegrovat. S rostoucím počtem technologií v podniku je to stále komplikovanější. Současnou a jistě správnou praxí je zahrnout tuto integraci do jednoho projektu spolu s dodávkou nové technologie. Novým trendem v podnikové informatice však jsou projekty, jejichž výsledkem není nic jiného než integrace již stávajících aplikací do lépe spolupracujícího systému.

 

Vidíme, že stále více technologií vedle sebe v informačním systému podniku postupem času nese nároky na stále více specializovaných zdrojů a stále vyšší náklady na údržbu. Kdo se snaží udržet v podniku technologií co nejméně, patrně ušetří. Je ale možné, že díky tomu ztratí své zákazníky, což může být důsledkem nižší efektivnosti hlavních procesů než u konkurence, nebo zanedbáním některého technologického trendu s možnou orientací přímo na zákazníky – například Internetu. Snaha o udržení jednoduchosti ale často ani vůbec není možná, zejména při fúzích a slučování podniků, nebo prostě proto, že nabídka staré technologie postupem času zmizí z trhu a změny v informatice musí být koordinovány se změnami v podnikání i poté.

 

Komplexita distribuovaných aplikací

Když se například objevily distribuované aplikace na trhu, zavládlo pro ně velké nadšení a všechny aplikace byly „klient-server“. Výhody distribuovaných aplikací jsou nesporné a migrace do tohoto modelu byla často ekonomicky oprávněná. Mnoho projektů však ukázalo, že se jedná o problém významně rozsáhlejší, než podniky původně očekávaly. Podle [Integris] byly nejtíživější problémy tři: nedostatečné technologické znalosti, neočekávané náklady a výrazně podhodnocené odhady nákladů na podporu a údržbu než byly později náklady skutečné, zejména podhodnocené náklady na správu systémů, na kterých se podílí více dodavatelů. Náklady na distribuované aplikace jsou při pohledu zpět skutečně vysoké, Gartner Group [Gartner] odhaduje průměrné roční náklady TCO na distribuované systémy na 50 tisíc USD na jednoho uživatele. Podpora a údržba distribuovaných systémů pak tvoří průměrně 50 až 75% celkových nákladů. Zajímavé budou i zatím nedostupné analýzy nákladů na současný žhavý trend – aplikace na bázi Internetu a internetových prohlížečů. U těchto technologií můžeme očekávat podobně vysoká čísla.

 

Lidské zdroje v informatice

Počet technologií rychle roste, roste tedy i poptávka po informatických odbornících, kteří tyto technologie ovládají a jsou schopni je v podnikové informatice zajistit. Počet informatiků roste sice také, ale zdaleka ne tak rychle, jak roste poptávka po nich. Dokladem toho může být rozšíření imigračních kvót – zelených karet pro takové odborníky v USA, nebo jejich zavedení v Německu. V USA přitom v roce 1999 bylo odhadem 346 tisíc a v Evropě 260 tisíc neobsazených míst, na které se nedostávalo odborníků v oblasti informačních technologií [Gartner]. Podle studie ITAA (Information Technology Association of America) se za posledních deset let v USA ztrojnásobil počet zaměstnanců v odvětvích software a hardware [Integris]. Deficit lidských zdrojů je o to větší v českých podmínkách, kdy odborníci odcházejí pracovat za vyššími příjmy do jiných zemí. Z hlediska podniků, které podnikají v jiném odvětví než v informatice, lze pak pociťovat

·          jednak odliv nejlepších pracovníků k firmám, pro které je informatika hlavní činností,

·          a jednak potřebu velmi specializované kvalifikace pracovníků, ale v menším rozsahu než na plný úvazek.

Oba tyto aspekty vedou k outsourcingu lidských zdrojů. Na nejnižší úrovni k dočasnému nákupu „holých“ lidských zdrojů v „bodyshopu“, přes nejrůznější konzultační služby až po služby procesů informatiky.

S růstem počtu technologií se také snižuje masovost jejich nasazení, a přestože poptávka po specialistech roste, jejich časové využití konkrétním podnikem je nižší. Jednotku pracovní síly – jednoho člověka však nelze dělit. Je tedy nutné, aby člověk byl buď specialistou na více technologií, což vzhledem ke kapacitě lidských schopností znamená snížení kvalifikace, nebo aby byl specialista využit pro více podniků, které jej potřebují vždy jen krátce.

S růstem počtu technologií a s jeho rychlostí je spojen také problém přípravy pracovníků. Zde se velmi mění podstata výuky na vysokých školách. Školy již nevychovávají specialisty v určité technologii, ani toho nejsou schopny. Pokud by se školy zaměřily na určitou technologii (například na určitý programovací jazyk), znamenalo by to, že zanedbávají ostatní technologie, které jsou na trhu k dispozici a v praxi používány. Kromě toho by také bylo nutné, aby škola sama byla původcem technologie, aby mohla připravovat odborníky v její aktuální verzi, která je konkurenceschopná s konkurenčními technologiemi a kooperativní s nově se objevujícími technologiemi, se kterými může spolupracovat. Takový vývoj technologií školy zajišťují výjimečně, spíše je v rukách komerčních firem, které technologii i prodávají a implementují v podnicích, a tedy mají dostatek prostředků i zkušeností pro vývoj potřebných. Příprava odborníků je tedy věcí spíše dodavatelských firem. Školy se zaměřují ve výuce informatiků stále více na výuku ke kooperativitě, týmové práci, flexibilitě a schopnosti permanentně se učit a použít nové technologie. Člověk, který takovým oborem projde, by tedy měl být ve smyslu použití technologií univerzálním. Aby ale takoví lidé byli v praxi použitelní okamžitě, bez nutnosti další průpravy ve firmách, zajišťují školy specializaci právě v kooperaci s informatickými firmami, které ovšem takto předpřipraveného specialistu často rádi zaměstnají sami, než aby jej nechali všanc trhu pracovní síly. Lidský zdroj v informatice je tedy spíše surovinou, jejímž zpracováním až do výsledného potřebného specialisty je nutné se zabývat a je nutné umět takový neustálý proces uřídit.

 

Vztahy s více dodavateli

S rostoucí komplexitou informačních technologií podniky mají vztahy se stále více dodavateli částí informačních systémů. Zejména při vývojových projektech nebo při změnách v informačních systémech je nutné koordinovat dodávky několika dodavatelů, které vedou k jedné ucelené funkční části informačního systému. Mimo jiné touto koordinací se zabývá disciplína Systémová integrace. Průměrný podnik řídí v jeden okamžik průměrně 100 vztahů s dodavateli zároveň, cca 70 s dodavateli hardware a cca 40 s dodavateli software.[7] Dále průměrný podnik věnuje řízení vztahů s dodavateli pouze 4% času managementu a pouze 2% času informatiků, a to i přes jejich nespornou důležitost. Je těžké si představit, že by stejná pozornost byla věnována řízení informatiky zabezpečované interně. Dnes je výrazným trendem řídit sofistikovaně vztahy se zákazníky (CRM – Customer Relationship Management), což je zajisté důležitější. Ovšem vztahy s dodavateli nejsou také zanedbatelné, mimo jiné i z výše uvedeného dodavatelského hlediska určování strategických procesů. Tento text se zabývá mimo jiné právě řízením vztahu s dodavateli (v oblasti informatiky).

 

Únava ze změn

V souvislosti s rostoucí komplexitou a s nutností sledovat vývoj a změny v technologiích se objevuje nový termín „Change Fatigue“ – únava ze změny. Únava ze změny se objevuje zejména u firem podnikajících v informačních technologiích, ale i v jiných podnicích a také v útvarech, které zajišťují podnikovou informatiku, a to z nekoordinovaně, rychle a neustále přicházejících změn v technologiích, v obchodních pravidlech a zvyklostech, v legislativě, v situaci na trhu a podobně. Organizace, které chtějí na všechny změny přiměřeně reagovat, jsou pod obrovským tlakem, neustále se „reengineerují“ za pochodu, reagují na přání a potřeby zákazníků a snižují náklady všude, kde je to možné. Taková práce není klidným a stabilním zaměstnáním a na pracovníky i management působí stres, který může vést až k rezignaci.

 

Důsledkem těchto faktorů prostředí je, že se role informatiky v podniku dnes posouvá od vývoje aplikací k plánování infrastruktury, integraci a podpoře uživatelů a k řízení změn a vztahů s dodavateli.

2.5    Dodavatelské zajištění informatiky

Nyní se podíváme na možnosti a trendy dodavatelského zajištění informatiky podniku.

Dnes nejobvyklejším způsobem zabezpečení informatiky podniku je tento model: Podnik zajišťuje interně provoz podstatné části svého informačního systému a interně zabezpečuje i jeho drobné změny a přírůstky. Jedná-li se o rozsáhlejší nový vývoj nové části informačního systému nebo jeho generační obměnu, je to zabezpečeno komplexně prostřednictvím dodavatelů, kteří se dnes nazývají „dodavatelé řešení“ nebo „systémoví integrátoři“. Řízení vývoje se omezuje na řízení požadavků a na výběr dodavatele, za řízení samotného projektu odpovídá zpravidla dodavatel. Prostředky potřebné pro provozování informačního systému podnik obvykle nakupuje a vlastní. Některé části informačního systému je dnes obvyklé provozovat prostřednictvím dodavatelů. Jedná se například o webhosting, vzdálenou správu sítí LAN, samozřejmě i telekomunikační služby a další.

Jak bylo výše zmíněno, nabídka zejména služeb informačních systémů roste a přináší pro podniky nové možnosti dodavatelského zabezpečení informatiky a nutnost nového rozhodování, zda některé procesy zajišťovat interně nebo zda je outsourcovat. Služby, které se začínají objevovat, jsou například služby využití kapacit výpočetních středisek, vzdálený dodavatelský provoz podnikových aplikací, pronájem stanic PC a další.

 

Kromě těchto trendů je také nutné zmínit možnost zabezpečení informatiky totálním outsourcingem – možnost, kterou během uplynulého desetiletí mnoho podniků ve světě využilo. Totální outsourcing můžeme chápat jako dlouhodobou rezignaci na možnost informatiky být strategickým procesem. V tomto modelu je veškeré řízení informatiky kromě strategického dlouhodobě předáno poskytovateli. Obvykle je tento poskytovatel právě jeden a měl by odpovídat za finální produkt informatiky pro podnik. Podnik může informatiku operativně a střednědobě řídit prostřednictvím věcných požadavků, rozhodování o technologii má v rukou poskytovatel. Smlouvy na totální outsourcing s dodavateli jsou obvykle dlouhodobé, na pět až deset let.

Trend outsourcingu ve velkém rozpoutal outsourcingový kontrakt Kodaku, podepsaný 2. září 1989 s IBM (ISSC, DEC a BL).[8] Dnes po deseti letech můžeme hodnotit jeho dopad a výsledky. Co se dopadu týče, byl obrovský a významně změnil pohled velkých podniků na oblast informatiky a zejména na vlastnictví aktiv IT. Dnes tvoří outsourcing informatiky obrovský světový trh s ročním obratem přes 100 miliard USD, který stále roste a v roce 2005 má podle IDC dosáhnout hodnoty 151 miliard USD [Field]. Přes úspěchy prvních let outsourcingu Kodaku existují o nákladové výhodnosti této transakce pochybnosti. Přesto Kodak pokračuje v outsourcingu dále, takže outsourcing jako strategie byl patrně přijat jako úspěšný.

Totální outsourcing informatiky je také silným nástrojem pro technologickou, aplikační a datovou integraci informačního systému podniku. Informační systém celého podniku má v řízení jeden odborný dodavatel, který má zájem na co nejefektivnější kooperaci všech částí informačního systému. Přístup k tvorbě outsourcingových vztahů a kontraktů však je obvykle takový, že odpovědnost za celkový produkt informatiky není na poskytovatele přenesena beze zbytku, nebo alespoň v takové míře, v jaké je to, jak ukážeme dále, možné. Smlouvy o kvalitě služeb totiž mají mnoho vrstev. Smluvně se specifikuje předmět i kvalita hardware uloženého ve výpočetním středisku poskytovatele, základního software, který na něm běží, aplikačního software atd., a to i v technologické rovině, a to v bezpochyby správném smyslu „je-li služba přesně specifikována, není pochyb o tom, co se má poskytovat“. Pokud ale k informatice přistupujme jako k procesu, který má určitý produkt pro podporu jiných procesů v podniku, je hned zřejmé, že smluvně (v předmětu, objemu a kvalitě) by měl být specifikován právě a pouze tento produkt. Technologie, která jej zajišťuje, pro podnik zajímavá vůbec není, a její výběr a parametry by měly být zcela v kompetenci a odpovědnosti poskytovatele. To je základní myšlenka outsourcingu,[9] která je však zmíněným přístupem eliminována. Jak ji lze realizovat, vyplyne z dalšího textu.

Z našeho pohledu na dlouhodobý outsourcing je dále zajímavé, že v mnoha případech během trvání kontraktu může nastat v podniku situace, kdy některou část informatiky by management rád řídil sám, a do mechanismu vztahu podniku a poskytovatele je nutné takovou možnost dodatečně implementovat.

Totálnímu outsourcingu se podrobněji věnuje kniha [BrVo].

 

V posledních letech se situace v řízení informatiky posouvá k modelu někdy zvanému „CIO jako IT broker“. V tomto modelu je řediteli informatiky přisouzena role tzv. „brokera“, který podle potřeby podniku operativně buď zajišťuje zabezpečení produktů informatiky interně, nebo, což je častější, nakupuje operativně produkty procesů informatiky od externích dodavatelů. Významný posun od chápání totálního outsourcingu nebo i outsourcingu jednotlivých částí oblasti informatiky, které bylo nosné v uplynulém desetiletí, je právě v operativnosti nového modelu. Například outsourcing datového centra nebo správy stanic PC byl v minulosti chápán jako dlouhodobé a nevratné rozhodnutí s pětiletým nebo delším dopadem. Dnes, vezmeme-li v úvahu zkrácení cyklů revize strategie informatiky a vývoj nabídky na trhu, začíná již být nutné outsourcovat informatiku operativně, s možností rozhodování o změně dodavatelů ze dne na den.

 

Takový přístup je novinkou především u služeb podnikových aplikací. V té souvislosti je nutné zmínit trend nabídky tzv. ASP – Application Service Providers – Poskytovatelů aplikačních služeb. ASP jsou poskytovatelé služeb softwarových aplikací, které provozují na vlastním hardware (nebo na hardware jiného poskytovatele, nikoli však na hardware podniku – zákazníka) a které jsou přístupné po Internetu.[10] Služby v sobě integrují software, hardware, síťové technologie a vhodné konzultační služby do jednoho balíku. K jejich využití je z technologického hlediska potřeba pouze připojení k Internetu a internetový prohlížeč na osobních počítačích uživatelů podniku – zákazníka. ASP mohou poskytovat své aplikace velkým i malým podnikům i spotřebitelům, podle typu aplikace. U aplikací pro podniky se kontrakty na využití služeb zatím pohybují v délce několika let.[11] Ceny jsou obvykle vázány buď na počet uživatelů nebo na počet transakcí.

Výhody užití služeb ASP jsou tyto: Podnik nepotřebuje žádné specializované zařízení – hardware, nepotřebuje implementovat, spravovat, udržovat či migrovat aplikační software, a ke všem těmto činnostem nemusí v podniku udržovat potřebné zdroje, které jsou navíc na straně ASP předmětem úspor z rozsahu, a služba tedy může být navíc levnější než při interním zajištění.

O využití služeb ASP se nehovoří jen u okrajových nebo jednoduchých aplikací, zajímavými jsou zde především možnosti outsourcingu velkých aplikací typu ERP (Enterprise Resource Planning), SCM (Supply Chain Management) či CRM (Customer Relationship Management). Poskytování služeb aplikací ERP a SCP prostřednictvím ASP patrně také umožní snadnější kooperaci menších podniků v konkurenci velkým dodavatelským řetězcům, a dále například propojování podniků prostřednictvím Internetu (EDI), kdy například administrace obchodních případů budou moci probíhat fyzicky mezi jednotlivými ASP, nebo dokonce v rámci jednoho ASP, podobně, jako peněžní toky probíhají mezi bankami nebo v rámci jedné banky místo mezi podniky samotnými. Zároveň se vytváří prostor pro usnadnění různých fúzí podniků, případně pro vnitropodnikovou informační propojenost business units nebo procesů obdobně, jako by to byly různé podniky. Dnes hojné aktivity mezipodnikové integrace prostřednictvím Internetu by se měly těmito skutečnostmi zabývat.

Při pohledu na možnost poskytování služeb aplikací (ASP) se nabízí ihned myšlenka na „velkou čtyřku“ Baan, Oracle, PeopleSoft a SAP. Na to, zda budou ve službách ASP dominovat tyto softwarové balíky nebo se objeví někdo další, si musíme počkat. Tento typ poskytování software zatím zdaleka nepřináší obrat, který je možný dnes obvyklým prodejem licencí. V budoucnu se odhaduje růst tohoto trhu, ale pro odhady konkrétních čísel nejsou dostatečné podklady.

 

Nástupem modelu „CIO jako IT broker“, tedy tím, jak podniky získávají stále více zkušeností s výběrem poskytovatelů a s outsourcingovými transakcemi, nastává situace, že klesá poptávka po konzultačních službách, které se týkají výběru a kontraktace s poskytovatelem. Světová cena takových služeb se může pohybovat podle rozsahu outsourcingu až kolem jednoho miliónu USD za podporu při jedné smluvní transakci, což už je zajímavá úspora. Zajímavý obchod s těmito službami tedy očekává pokles. Podle některých analytiků (McGuire) však i v budoucnu bude pro konzultační služby tohoto typu dostatečná poptávka, a to především z toho důvodu, že outsourcingové kontrakty jsou dnes větší a komplexnější než kdykoli dříve. Také podniky začínají využívat konzultačních služeb pro řízení vztahu již běžícího outsourcingového kontraktu, při jeho údržbě a změnách, protože často i samotné udržování komplexního vztahu vyžaduje experta.

 

Zamysleme se, proč zrovna oblast informatiky je z hlediska dodavatelského zabezpečení pro outsourcing vhodná, nebo jinými slovy, proč právě procesy, které zajišťují služby informačních systémů pro podnik, začíná být možné operativně outsourcovat.

První důvod se zdá být zřejmý, je to existence a možnosti světové de-facto standardizované komunikační infrastruktury – Internetu. Druhým důvodem je to, že produkt procesů informatiky podniku jsou vždy právě informace – nehmotný produkt. Internet umožňuje distribuci informací (produktů informatických procesů) po celém světě z jednoho místa nebo sběr informací z celého světa do jednoho místa s velmi nízkými přepravními náklady. To umožňuje jednotné globální zajištění obdobných informatických procesů pro různé podniky a tedy velké úspory z rozsahu i velké transakční úspory.

 

Nemůžeme zapomenout ani na výrazný trend tzv. „Business Process Outsourcing“, tedy outsourcingu procesů, zejména podpůrných (rozuměj jiných než informatiky), tedy trend rozpadu podniků na holé procesy, jak bylo naznačeno v úvodu. Tržní nabídka služeb procesů, jako jsou personalistika, logistika a další existuje již dlouho. Zatím však podniky takové aktivity obvykle zajišťují interně. Jaký vztah má ale možnost outsourcingu takových (neinformatických) procesů k outsourcingu informatiky? Jak jsme uvedli, informatiku můžeme chápat jako podpůrný proces, který podporuje jiné procesy podniku. Pokud podnik interně zajišťuje ty „jiné“ procesy, můžeme outsourcovat jejich podporu – informatiku. Podnik ale může i ty „jiné“ procesy outsourcovat (zvlášť jsou-li také podpůrné). Outsourcuje-li podnik celý proces, pak, až na výjimky, nemá smysl o jejich informatické podpoře vůbec uvažovat, protože se předpokládá, že ji v potřebném rozsahu zajistí poskytovatel produktů toho „jiného“ procesu.

 

Uveďme příklad na personalistice.

Proces personalistiky zajišťuje v podniku výběr, školení, evidenci pracovníků a výpočet jejich mezd. Tyto aktivity je pro zvýšení výkonnosti vhodné podpořit informačním systémem – řekněme aplikací personalistika a mzdy. Podnik má možnost zajišťovat si personalistiku interně, zvláště pokud se jedná o strategický proces. Protože ale informatické zajištění personalistiky strategické není, může je outsourcovat, a nakupovat služby aplikace personalistika a mzdy například od nějakého ASP. Pracovníci personalistiky podniku budou k takové aplikaci přistupovat vzdáleně ze svých osobních počítačů přes Internet. Pokud ale ani personalistika není pro podnik strategická, může podnik outsourcovat přímo celou tuto oblast. Podnik pak bude nakupovat služby procesu personalistiky od poskytovatele, který bude personalistiku zajišťovat na trhu pro různé subjekty. Jak si ji zajistí tento poskytovatel informaticky, je jeho věc.

 

Outsourcing celého procesu je oproti outsourcingu jeho informatické podpory zajisté drastičtější, ale patrně také efektivnější možnost restrukturalizace podniku. Nabídka na trhu však zatím nedoznává takového rozvoje jako nabídka služeb informatiky, což vysvětlujeme tím, že produkty takových procesů nejsou na rozdíl od produktů procesů informatiky nehmotné, a tedy se setkávají s většími bariérami rozšíření až globalizace (a úspor z rozsahu) než služby informačních systémů.

 

Z problematiky a zejména z příkladu je zřejmé, že přístup operativního outsourcingu je v případě informatiky jednoduchý jen zdánlivě, ale ve skutečnosti přináší obrovské problémy především v integraci jednotlivých částí podnikového informačního systému.

U našeho příkladu s personalistikou je například nutné zajistit integraci aplikace personalistiky například s informačním systémem pro ekonomiku podniku (a s dalšími). V případě interního provozu takové aplikace je integrace často složitá a nákladná. V případě, že bude aplikaci provozovat externí subjekt (ASP nebo poskytovatel služeb personalistiky), můžeme očekávat integračních problémů mnohem více.

Kromě integrace je dalším problémem operabilita. V situaci, kdy podnik rozhoduje o tom, zda outsourcovat proces personalistiky nebo zda jej zajišťovat interně, informatické zajištění by mělo být připraveno takové organizační rozhodnutí podniku respektovat a bez zbytečně velkých transakčních a dodatečných nákladů operativně upravit rozhraní ostatních částí informačního systému s aplikací personalistika a mzdy.

 

obr. 5,  Business Process Outsourcing vs. IT Outsourcing

 

Krátce srovnejme operativní a dlouhodobý přístup k outsourcingu informatiky. Operativní outsourcing informatiky má tu výhodu, že outsourcingová transakce není tak riziková jako u dlouhodobého outsourcingu. Již nezáleží vše na předkontraktační fázi, protože pokud by při definici vztahu došlo k nějaké chybě, je vždy možnost dodavatele operativně vyměnit.

Operativní model outsourcingu však ztrácí některé výhody outsourcingu dlouhodobého, a to zejména možnost prodeje stávajících aktiv informačního systému a převod zaměstnanců poskytovateli. Poskytovatel totiž tato břemena je ochoten přijmout často právě proto, že má záruku dlouhodobé závislosti podniku na svých službách a tedy záruku postupného zaplacení takové investice.

 

Obecně panuje velký optimismus a očekávání, že se služby ASP rychle rozšíří pro velké podniky. To ale není oprávněná představa. Velké podniky nedávno dokončily velmi rozsáhlé investice do zajištění „problému roku 2000“ u svých systémů a nelze očekávat, že by v dohledné době uvažovaly o jejich obměně, natož tak drastické. Obrat ke službám ASP můžeme očekávat spíše u podniků, které se již svých aktiv IS/IT zbavily prodejem poskytovateli při dlouhodobém outsourcingu v uplynulých letech, a dnes nebo v budoucnu, kdy vyprší dlouhodobý outsourcingový kontrakt, se mohou rozhodovat již bez velkého břímě investic do IT. Z tohoto pohledu můžeme pokládat dlouhodobý outsourcing spojený s převodem aktiv a zaměstnanců na poskytovatele za vývojový předstupeň operativního outsourcingu. V nejbližších letech tedy můžeme očekávat, že dlouhodobý outsourcing nevymizí a bude nadále jedním z možných zajištění informatiky podniku, a dokonce můžeme očekávat příklon k takovému způsobu zajištění, protože v budoucnu umožní podniku snáze využít outsourcingu operativního, který se dnes objevuje jako možnost nová.

 

obr. 6,  Outsourcing dlouhodobý a operativní - vývoj

 

Tento text je o podmínkách, které jsou pro řízení informatiky v modelu „CIO jako IT broker“ v podniku i na trhu nutné. Shrňme podmínky, které byly dosud zmíněny a které můžeme identifikovat jako nutné pro model operativního outsourcingu informatiky:

 

a, informatické aktivity musí být v podniku vhodně organizačně členěny, aby bylo možné je vystavit konkurenci na trhu;

 

b, musí existovat dostatečná nabídka služeb informatiky, a to opět ve vhodném členění, tak, aby reflektovala přání více podniků na straně poptávky;

 

c, musí existovat poměrně nenákladná možnost srovnání konkurujících služeb;

 

d, informační a komunikační infrastruktura musí být dostatečná pro vzdálené poskytování služeb informatiky.

 

Ad a, a b, – Tyto dvě podmínky můžeme interpretovat takto: musí vzniknout trh takových služeb. Zpočátku musíme očekávat trh diverzifikovaný, kde bude nabízeno mnoho služeb, které budou spíše méně nahraditelné a které si budou konkurovat hlavně tím, že se budou odlišovat. Pokud se však najde první velký globální podnik, který trh autentifikuje tím, že začne využívat určité služby určitým způsobem, budeme moci očekávat standardizaci aplikačních služeb informatiky. To se týká zejména služeb aplikačního software – ASP. To bude pro operativní outsourcing služeb informatiky obdobným signálem jako outsourcing informatiky Kodaku před deseti lety. Služby informatiky totiž mohou být z určitého pohledu pro mnoho různých podniků obdobné. Bez čekání na autentifikaci trhu rozvineme tuto myšlenku v části Služby podnikové informatiky. To, jaké služby a jakým způsobem mohou být poskytovány, totiž nezáleží na svévoli hráčů na trhu, ale určitá architektura může být odvozena z principů technologií, ze současné praxe řízení informatiky a z předpokládané logiky případného budoucího trhu.

 

Ad a – Vhodným organizačním členěním informatiky rozumějme nejen služby informatiky, ale zároveň procesy, které tyto služby zajišťují. Řízení takových interních procesů by mělo být obdobné řízení outsourcovaných procesů, aby byly snadno operativně nahraditelné (a nebylo tedy nutné je považovat za strategické pouze z důvodu nevhodného řízení). To znamená již zmíněnou distribuci řízení na řízení prostřednictvím zájmů. O tom pojedná kapitola Distribuce řízení na procesy.

 

Ad b, – o nabídce těchto služeb viz výše – ASP.

 

Ad c, – Aby byly produkty procesů srovnatelné, musí být jejich efekt nějakým způsobem měřitelný. Efektem zde v souladu s předchozími principy musíme myslet plnění přání zákazníka, případně plnění potřeb nutných pro to, aby byl zákaznický (podporovaný) proces efektivní. Někdy můžeme zprostředkovaně měřit i sekundární efekty, tedy například právě zvýšení efektivity podporovaného procesu. Měření efektů procesů informatiky věnujeme kapitolu Měření služeb IS a jejich efektů. Měření efektů informatiky bylo a dosud je problematické. Právě outsourcing je jev, který do problému přirozeným způsobem může vnést a také vnáší světlo. Při poskytování služeb informačních systémů komerčně je již totiž měřit výsledek nezbytné.

 

Ad d, – Světová informační a komunikační infrastruktura – Internet je dnes na takové úrovni, že služby typu ASP umožňuje. Vzhledem k tomu, že k zákazníkovi se přenáší obvykle pouze prezentační vrstva systému, což v případě podnikových aplikací je v maximální míře text, neklade model vysoké nároky na přenos velkých objemů dat. Dnešní veřejný globální Internet však není pro vzdálené služby aplikačního software ideální, protože jeho princip dnes neumožňuje vyhrazení přenosového okruhu pro určitý typ přenosů, a tedy nelze garantovat dobu odezvy, důležitý kvalitativní parametr, jak je to možné například v rozsáhlých sítích jiného typu. Tento problém patrně vyřeší principy Internetu budoucnosti, u kterého však nemůžeme očekávat celosvětové veřejné a komerční prosazení v nejbližších letech. Již dnešní někteří poskytovatelé připojení Internetu (ISP – Internet Service Providers) poskytují službu zvanou QoS (Quality of Service), která zákazníkovi určitou přenosovou kapacitu může vyhradit. Tato služba je však využitelná pouze v rámci sítí ovládaných tímto jedním poskytovatelem. Patrně právě z tohoto důvodu se zejména v USA hovoří o vhodnosti propojení služeb ISP a ASP (spíše se ale hovoří o aplikačních službách pro spotřebitele).[12] Poskytovatelé Internetu totiž mohou dobu odezvy vlastních aplikačních služeb pro své zákazníky služeb připojení k Internetu garantovat, a tím mají výraznou konkurenční výhodu oproti službám ASP na poskytovatelích připojení nezávislých. Naopak poskytováním služeb ASP třeba i veřejně po Internetu, ale s garantovanou QoS pouze pro vlastní zákazníky připojení, mohou ISP pro sebe získávat i zákazníky jinak spokojené u jiných poskytovatelů připojení. Technologická vlastnost protokolu TCP/IP dnes brání ideální globalizaci služeb ASP a patrně právě nemožnost garance doby odezvy bude asi největší slabinou těchto služeb.

 

To byl tedy úvod k podmínkám rozšíření nového modelu outsourcingu. V dalších částech se na ně podíváme podrobněji. Jak vyplyne z dalšího, nejde jen o podmínky nového modelu operativního outsourcingu, ale i o principy, které lze obecně užít pro řízení informatiky a které mohou být použitelné i při interním zajištění informatiky i při outsourcingu totálním či dlouhodobém.

3       Distribuce řízení na procesy

V minulé kapitole jsme ukázali, že pro umožnění modelu „CIO jako IT broker“, resp. modelu operativního outsourcingu, je třeba splnění několika podmínek. Jednou z nich bylo vhodné organizační členění a řízení informatiky podniku, aby bylo možné služby informatiky snadno nahrazovat službami různých dodavatelů. Členění služeb bude rozvinuto později a zde se podíváme na řízení procesů v informatice.

Nejprve popíšeme principy distribuce řízení na procesy a řízení prostřednictvím zájmů a na závěr kapitoly uvedeme základní funkce centrálního řízení informatiky a jeho důležitost.

 

V modelu „CIO jako IT broker“ se těžiště řízení informatiky dostává na organizaci a řízení nákupu služeb informatiky, tedy nákupu výsledku procesů. Oproti tomu dnešní řízení informatiky je zpravidla zaměřené nikoliv na výsledek procesů – služby, ale na průběh procesů v informatice a řízení zdrojů těchto procesů (pracovníky, hardware, …). Popíšeme podrobněji některé aspekty distribuce řízení na procesy a řízení prostřednictvím zájmů, a specifikujeme aspekty řízení tohoto přístupu, které není vhodné distribuovat, ale naopak je vhodné ponechat na centrálním řízení informatiky.

 

Pokud je například nutné zajistit informační systém pro podporu kontrolingu podniku, je dnes obvyklým řešením vybrat dodavatele, který dodá softwarový produkt, hardware, odborně navrhne přizpůsobení software pro podnik, vyškolí personál v podniku, který bude systém užívat, provozovat a udržovat, a systém implementuje. Podnik si zakoupí licenci užívat software a potřebný hardware a tento pak vlastní. Také zaměstnává odborné informatické lidské zdroje, které chod systému zajišťují. Podnik sice outsourcoval vývoj informačního systému (tedy změnu v informatice), ale proces běžného poskytování služeb pro vnitřního zákazníka (patrně pro útvar kontrolingu) zajišťuje interně, z interních nebo nakoupených zdrojů.

V našem modelu by podnik při změně, tedy při nákupu, vývoji a implementaci informačního systému obdobně vybíral dodavatele, ale při plánování zajištění provozu, běžného poskytování služeb informačního systému, by stál před otázkou, zda pro toto použít vlastní zdroje (existující hardware a personál), nebo zda nechat břemeno vlastnictví aktiva zaměstnání odborníků na poskytovateli, který bude v budoucnu systém provozovat a podniku poskytovat jen jeho služby. Z hlediska plánování zdrojů je nutné toto rozhodnutí dělat již před započetím vývoje.

Je zřejmé, že pokud podnik chce užívat služby informačního systému pro kontroling, aniž by si jej koupil nebo sám provozoval, je nutné umět přesně specifikovat, jaké služby, v jakých parametrech a za jakou cenu hodlá užívat.

 

V přístupu orientovaném na řízení zdrojů a nikoli výsledných služeb informatiky jsou transakční náklady na změnu poskytovatele vysoké, protože je nutné vždy je doprovodit organizační změnou, novou specifikací požadavků, předmětu služeb, parametrů služeb a technologií vztahu s dodavatelem. Takové budoucí nutné náklady na změnu lze interně omezit. Zde uvedeme model, jakým toho lze docílit.

Aby budoucí náklady na změnu poskytovatele služeb byly co nejmenší, je vhodné, aby vztahy k možným poskytovatelům byly formálně a organizačně shodné nebo alespoň co nejvíce podobné.

Vztahy mezi zákazníkem a poskytovatelem jsou ovšem věcí obou těchto subjektů. Dnes můžeme sledovat, zejména v případě dlouhodobých outsourcingových vztahů, formální připravenost k organizaci a technologii vztahu zejména na straně poskytovatelů, kteří při výběrovém řízení po úvodní studii (resp. due diligence) navrhují organizaci a technologii vztahu zákazníkovi. To pro podnik znamená, že s každým poskytovatelem ho čeká více nebo méně rozdílné řízení a administrace vztahu.

 

Tato část problému sice skýtá možnost zefektivnění a úspor, ale problém je ještě rozsáhlejší. Vezmeme-li v úvahu možnost rozhodování mezi službami interních procesů nebo nákupem služeb externího poskytovatele, vychází nám, že je navíc vhodné, aby způsob organizace a řízení vztahu s poskytovateli byl co nejvíce podobný řízení a organizaci vztahů k vlastním interním procesům.

 

Chovat se k vlastním procesům v podniku stejně jako k dodavatelům nebylo vždy přirozené, ale často je to efektivní, což může naznačovat i hojné využití tzv. business units nebo nákladových středisek uvnitř podniku, které mezi sebou mají vnitropodnikové smlouvy a jsou organizovány tak, aby v rámci podnikového kontrolingu byly pokud možno ekonomicky autonomní a v některých případech i ziskové. Tuto problematiku zde obecně nebudeme rozvíjet,[13] ale zaměříme se na některé aspekty, které z toho pro řízení informatiky plynou jako vhodné, a to především jako východisko pro možnosti specifikace služeb informatiky a měření služeb, kterými se budeme zabývat později.

 

Zde tedy popíšeme, jak se postavit k vnitřním procesům informatiky, aby byly snadno zaměnitelné za služby externích procesů, a tedy aby nebylo nutné zbytečně (z organizačních důvodů) považovat některé části informatiky za strategické.

Řídit informatiku jako podpůrný proces uvnitř podniku znamená řídit zdroje, které jsou k dispozici (interně nebo dodavatelsky), a tyto zdroje využít pro vytváření produktů procesu informatika. Proces informatiky má více produktů (více služeb) a jak uvidíme, je vhodné organizovat procesy informatiky (subprocesy procesu informatika) tak, aby každá autonomní služba byla výsledkem autonomního procesu. Je-li autonomní služba výsledkem autonomního procesu, pak pokud se rozhodneme tuto službu nakoupit externě, není nutná složitá reorganizace, ale stačí zrušit interní proces, který ji zajišťoval (a ovšem řešit co se zdroji, které interní proces využíval).

 

Na nejnižší úrovni se lze rozhodovat, zda interně zajistit nebo nakoupit zdroje pro informatické procesy, tedy rozhodovat se, zda podnik má k dispozici potřebné lidské zdroje, potřebný výpočetní výkon nebo přenosovou kapacitu počítačových sítí, nebo zda tyto zdroje nakoupí u dodavatelů (body shop, pronájem přenosových linek, pronájem hardware). Zde popisovaný přístup se však netýká zdrojů, ale již výsledku informatiky – služeb, které poskytuje ostatním podnikovým procesům.

 

Zatím podniky vidí těžiště řízení informatiky v řízení zdrojů, zde se ale zaměřme a položme důraz na řízení informatiky jako řízení služeb. Informatiku podniku se pokusíme rozčlenit na autonomní procesy, které poskytují autonomní služby (o tom viz dále). Abychom zajistili možnost operativního rozhodování, zda určité služby zajišťovat interně nebo nakupovat, je vhodné řídit tyto interní informatické procesy stejně, jako řídit procesy, jejichž produkt (služby) podnik nakupuje od poskytovatele.

To v podstatě znamená neřídit je téměř vůbec. Řídit procesy, které probíhají u poskytovatele, lze pouze tím, že specifikujeme, co si od něj chceme koupit a za jakých podmínek. Tak by bylo možné charakterizovat i přístup k interním procesům, řídit je tedy pouze specifikací a parametry výsledku – služby, kterou poskytují ostatním procesům. Tento přístup neeliminuje nutnost řízení zdrojů informatiky, a to patrně nejlépe centrálního pro celý podnik, ani řízení kvality, eliminuje však centrální řízení vlastního procesu, činností a jejich sledu, tedy způsobu, jakým se k produktu procesu – službě dojde. Proto tomuto přístupu říkejme distribuce řízení na procesy.

Procesy tedy v tomto případě budou řízeny autonomně a je tedy nutné stanovit osobu (osoby) odpovědnou za proces a oprávněnou jej interně řídit. Zadáním pro proces (a tyto osoby) bude tedy produkt – služba a její parametry, omezením budou určitá pravidla, která je nutné při řízení procesu dodržet (řízení kvality v podniku, pravidla využití podnikových zdrojů, atd.), ale dále je nutné také řídit zájmy takového procesu (osoby za něj odpovědné). Tomu říkejme řízení prostřednictvím zájmů. Výše již byly řečeny podmínky efektivity takového přístupu:

·          protagonisté procesů mají zájem na co nejlepším plnění přání zákazníků svých procesů,

·          protagonisté procesů mají zájem na tom, aby náklady na jejich procesy byly co nejnižší,

·          protagonisté procesů jsou chráněni proti pokušení předchozí dvě podmínky porušovat.

 

Tyto zájmy lze vhodně podpořit celou škálou motivačních nástrojů. Zde je důležité zmínit hlavně vystavení procesu konkurenci externích poskytovatelů.

Uvedené podmínky jsou dostatečné v případě, že platí pro všechny procesy v podniku. Vytvářejí prostředí, ve kterém protagonisté hlavních procesů, kteří se snaží co nejlépe a s co nejnižšími náklady plnit přání zákazníků podniku, vyvíjejí tlak na služby podpůrných procesů (tedy i na informatiku), aby plnila co nejlépe jejich přání a ovšem za co nejnižší cenu. Protagonisté těchto podpůrných procesů se pak obdobně snaží plnit přání svých zákazníků s co nejnižšími náklady. Teoreticky se jedná o autonomní a automaticky efektivní model s distribuovaným řízením, obdobný trhu, ale na rozdíl od něj uvnitř podniku.[14] Pokud uvedené podmínky neplatí obecně v celém podniku, je nutné centrálním řízením zasahovat proti možným vznikům neefektivity, zejména proti přáním zaměstnanců, která nejsou v souladu s potřebami procesu pro plnění přání zákazníků.[15]

Zastavme se u třetí podmínky, chránění proti pokušení. I v případě, že jsou vhodně zvoleny motivační nástroje pro zajištění zájmů osob odpovědných za procesy i dalších pracovníků procesů informatiky, existuje stále nebezpečí, že tito protagonisté procesů budou mít ještě zájmy jiné. V oblasti informačních technologií, kde panuje mezi dodavateli tvrdý boj o zákazníka, to je především nebezpečí uplácení pracovníků odpovědných za nákup. Zejména v případě velkoobjemových dodávek je vysoké riziko, že motivaci pracovníků vybrat dodavatele co nejefektivněji přebije významná peněžní motivace – úplatek ze strany dodavatele. Toto nebezpečí je nutné eliminovat zejména pravidly nákupu, která však často také omezují jeho efektivitu a zvláště rychlost.

„Neviditelná ruka“ distribuce řízení na procesy a řízení prostřednictvím zájmů je sice vhodným principem distribuce starosti centrálního a vrcholového řízení podniku na jednotlivé dílčí procesy, ale nelze se na ni spolehnout vždy a stoprocentně. Případné neefektivity a pokušení jsme zmínili a jistě existují i další. Není tedy patrně možné podnik nechat žít pouze z těchto principů, ale centrální řídící zásahy osob odpovědných za skupiny procesů jsou nutným kontrolním mechanismem. Tato distribuce řízení by také neměla eliminovat výhody rozsahu podniku, což jsou především úspory z rozsahu. Některé aktivity, zejména řízení zdrojů a nákup, je vhodné pro velký podnik zajišťovat centrálně, a tedy procesní uspořádání podniku by mělo být voleno tak, aby tyto výhody samovolná expanze interní podnikavosti neeliminovala. Z toho důvodu je vhodné centrálně kontrolovat služby procesů, aby se v některých částech nepřekrývaly, a zdroje procesů, aby, pokud je to možné, procesy mohly využívat výsledky ostatních podnikových procesů jako své zdroje. To je předmětem procesního řízení a procesní restrukturalizace podniků (BPR).

 

Shrňme tedy model řízení informatiky „CIO jako IT broker“: Centrální řízení informatiky (ředitel informatiky – CIO, Chief Information Officer) řídí služby, které získává od interních procesů nebo nakupuje od externích poskytovatelů. Zároveň určuje pravidla pro interní procesy, především pro řízení kvality a zájmů, ale neřídí přímo činnosti a procesy. Zároveň centrálně koordinuje zajištění zdrojů, které interní procesy pro zajištění svých služeb požadují. Tímto přístupem jednak získá centrální řízení informatiky výhodu outsourcingu – možnost řídit bez znalostí, a jednak je dána pracovníkům procesu relativní svoboda a možnost rozvinout produkt svého procesu sice uvnitř podniku, ale na tržních principech a v konkurenci s možnými externími poskytovateli.

Zde je vidět, že podnikavost je možné uplatňovat nejen na trhu (entrepreneurship), ale také uvnitř podniku (intrapreneurship)[16].

 

obr. 7,  Zdroje a produkty procesů informatiky

 

Komentář k obrázku: Schéma ukazuje procesy v podniku z hlediska jejich zdrojů a produktů. Centrální řízení informatiky podniku je zde koncentrováno do dvou aktivit, do řízení služeb informatiky a do řízení zdrojů informatiky. Primární je řízení služeb, kde lze rozhodovat, zda služby nakoupit nebo zajistit interně. Interní i externí procesy, které služby zajistí, nejsou řízeny přímo, ale pouze poptávkou po jejich výstupu (předmětem, parametry a cenou služeb). Pokud je rozhodnuto zajistit služby interně, je nutné procesům, které tyto služby vyprodukují, také zajistit potřebné zdroje, a to opět buď interně, v podniku, nebo nákupem u dodavatelů. Služby procesů informatiky jsou poskytovány ostatním procesům v podniku (informatické procesy zde nepatří mezi hlavní procesy podniku). Produkt informatiky podniku je zprostředkovaně promítnut do produktu podniku pro zákazníka podniku, a dále až pro konečného spotřebitele produktu. Pokud jsou mezipodnikové vztahy založeny na tržních principech a vnitropodnikové vztahy na distribuci řízení a řízení pomocí zájmů, jsou vytvořeny podmínky, aby se přání a potřeby spotřebitele promítly do produktu informatiky podniku i do požadavků informatiky na své vstupy.

 

V našem modelu je hlavním momentem možnost rozhodování, zda služby informatiky nakoupit, či je zajistit interně. Při tomto rozhodování je podstatná specifikace služeb v předmětu a parametrech (tomu se bude věnovat kapitola Služby podnikové informatiky), a dále také porovnání ceny služeb, za kterou jsou ochotni službu poskytnout jednotliví poskytovatelé, a ceny služeb, kterou je nutno vynaložit na interní zajištění služeb.

Z hlediska řízení informatiky podniku není podstatné a ovlivnitelné, jakým způsobem cenu kalkuluje poskytovatel. To platí ovšem v případě, kdy je podnik schopen ověřit poskytnutí služby, jeho objemové a kvalitativní parametry. Pokud tomu tak není, je často nutné ovlivňovat i tvorbu ceny u poskytovatele, například počty odpracovaných hodin pracovníků poskytovatele a jejich cenu podle odborné kvalifikace, podobně jako je tomu při nákupu zdrojů pro procesy informatiky – bodyshopu. Takový přístup ale eliminuje výhody outsourcingu a pro řízení takových vztahů je nutná podstatně rozsáhlejší znalost na straně podniku, než jaká je nutná při řízení prostřednictvím autonomních, dobře definovaných a kontrolovaných služeb.

Chová-li se podnik k autonomním procesům zajišťovaným interně obdobně jako k externím poskytovatelům, může to znamenat, že i kalkulace ceny služeb interních procesů může být ponechána na autonomii řízení informatických procesů. To je do jisté míry opodstatněná myšlenka. Podobně jako při jiných činnostech je ale nutné, aby protagonisté informatických procesů dodrželi celopodniková pravidla, v tomto případě pravidla nákladového řízení.

 

Procesní uspořádání podniku, autonomie procesů, distribuce řízení na procesy a řízení prostřednictvím zájmů předpokládají odpovídající nákladové řízení podniku. Pokud mají osoby odpovědné za procesy mít zájem na co nejlevnějším zajištění produktů svých procesů, je kromě motivace k tomuto zájmu nutná ještě skutečná kontrola nákladů, které na vytvoření produktu jejich proces vynaloží. To znamená, že pokud nějaký proces v podniku využije produkt jiného procesu (v našem případě služeb informatiky), je nutné, aby náklady na tento produkt podpůrného procesu (náklady na službu informatiky) byly podporovanému procesu přičteny k tíži. Kontrolingový systém podniku musí tuto možnost nějakým způsobem zahrnout.

Podpůrný proces tedy musí umět kalkulovat cenu svých služeb, tedy balík nákladů vztažený k určité jednotce užití produktu procesu, který právě podle jeho užití bude přičítán k tíži podporovaným procesům.

Zde je opět vidět již výše zmíněná možnost rozpadu podniku na holé hlavní procesy: V tomto modelu je maximálně eliminována celková režie podniku a je rozpuštěna na režii jednotlivých procesů. To dává větší flexibilitu i rozsáhlým podnikovým kolosům.

Dále je možné, pokud je v podniku definován kontrolingový systém vzájemného rozhraní využití služeb procesů a služeb zdrojů, aby každý proces kalkuloval cenu svého produktu jinou metodou, a to takovou, která je pro daný proces a jeho produkt nejvhodnější.[17]

Pokud jsou všechny aktivity podniku zapojeny do takového kontrolingového systému produktivních procesů, pak může být cena koncového produktu podniku kalkulována pouze na základě nákladů hlavního procesu, kterému jsou již všechny náklady podpůrných procesů přičteny.

 

Nás bude zajímat možnost co nejvhodnější kalkulace služeb informatiky. Specifikace architektury služeb bude podřízena i tomu, aby produkt informatiky mohl být co nejvhodněji cenově kalkulován. Přitom je lhostejné, zda tato kalkulace bude použita pro vnitropodnikové přeúčtování nákladů, nebo pro ocenění služeb poskytovaných na trhu. Rozdílem ovšem je, že podpůrné procesy v podniku by neměly být ziskové, a tedy bude kalkulace ochuzena o marži.

 

Protagonisté procesů se tedy budou moci rozhodovat o tom, zda nakoupí služby uvnitř podniku nebo od poskytovatele i podle ceny. Je ale vhodné, aby toto rozhodování bylo centrálně koordinováno, a to z několika důvodů:

a)       předmětná specifikace produktu,

b)       náklady na změnu,

c)       režie procesu a interní cena,

d)       zvýhodnění interních procesů,

e)       úspory z rozsahu při nákupu.

 

V podstatě jsou tyto oblasti důvodů obecné. Vysvětlíme je ale právě na případu informatiky.

 

Ad a, Protagonisté procesů v podniku sice využijí služby informatiky, ale nemusí být odborně kvalifikování pro to, aby věděli, jaké jsou možnosti a limity možných služeb informatiky (viz též rostoucí komplexita výše). Nemusí  být schopni odborně (a tedy s eliminací rizik a dodatečných nákladů) specifikovat předmět a parametry své poptávky po informatických službách. To může vést ke špatnému rozhodnutí, které přinese rizika a dodatečné náklady. Veškeré služby informačních systémů také musí být dostatečně integrovány, aby aplikace dostatečně kooperovaly a aby byl udržen konzistentní podnikový datový model. To je možné zajistit pouze centrálním řízením.

 

Ad b, Zvláště při poskytování služeb informatiky je velmi rozsáhlá část nákladů na služby věnována přípravě jejího užívání, tedy změně. Podporovaný proces a jeho protagonisty zajímá především užití služby. Její příprava, v rozsáhlých případech tedy celá vývojová část životního cyklu informačního systému, je na centrálním řízení informatiky. Tuto část mohou protagonisté neinformatických procesů podcenit, nebo ji vůbec nemusí vzít v úvahu, přestože v nákladech hraje velmi významnou roli.

 

Ad c, Na služby informatiky je vhodné dívat se z hlediska celého podniku také z hlediska režijních nákladů procesu. V mnoha případech jsou i režijní náklady informatiky podstatné, někdy mohou tvořit až 90% ceny služeb,[18] což ovšem není žádoucí (k tomuto problému se ještě dostaneme). Pokud informatika kalkuluje svou režii do ceny svých vnitropodnikových služeb, je tak patrně děláno nějakou formou rozprostření na všechny poskytované jednotky služby, například prostým průměrem. Pokud se některý z podporovaných procesů rozhodne ukončit užívání služby, pak tento proces patrně ušetří, ale režie, kterou proces informatiky bude mít dále stejnou (alespoň z krátkodobého hlediska), bude nutné rozpočítat na ostatní příjemce služeb informatiky, a těm se tedy nálady naopak zvýší. Řešení může být například ve společném operativním rozhodování zákazníků služeb informatiky a centrálního řízení informatiky. Tento problém pomůže řešit právě operativní outsourcing, kdy se informatika podniku zbaví dlouhodobých závazků, zejména aktiv informatiky (hardware a software) a zaměstnanců. Takové řešení však spíše pouze sníží podíl režie na celkové ceně produktu, než aby problém zcela vyhladilo. Dále může tento problém pomoci řešit i sofistikovaný způsob kontrolingového uspořádání podniku.

 

Ad d, V některých případech je vhodné interní zajištění služeb podpořit výhodami oproti externím poskytovatelům. Důvodem může být například dostatečné využití specializovaného zdroje a například umožnění interního zajištění strategického procesu, který však tento zdroj využije jen částečně, a podobně. Pak může být trpěno i nákladnější interní zajištění služby než alternativní nákup služby od poskytovatele. Přestože se zde zaměřujeme na ekonomické aspekty problematiky, můžeme uvést i některé jiné důvody zvýhodnění interního zajištění. Je to například sociální hledisko, kdy podnik plní svou sociální funkci zaměstnáváním pracovníků například v určité lokalitě, přestože je to s ohledem na možnosti nákupu služeb od poskytovatele poměrně neefektivní. V takovém případě je ale nutné důkladně zvažovat dlouhodobou konkurenceschopnost.

 

Ad e, Dále je role centrálního řízení sužeb procesu v úsporách z rozsahu zejména při nákupu služeb procesů a zdrojů. Pokud nakupuje podnik jednotně služby procesů (ale i téměř cokoli jiného), je pro dodavatele zajímavějším partnerem a má možnost získat některé, zejména cenové, výhody. Lze také účinněji (centrálně) řídit pokušení pracovníků porušit zájmy podniku (viz výše).

 

Z těchto důvodů tedy nehovoříme o možnosti samostatného rozhodování protagonistů procesů, ale o rozhodování IT brokera, ředitele informatiky, který by měl být pro celý podnik centralizovaný. Přesto je ale důležitý právě tlak podporovaných procesů na své náklady, a tedy i na využití služeb informatiky a jejich parametry. To by měl být v souladu s výše nastíněným modelem rozhodující faktor při rozhodování o informatice v podniku. Dále je nutné, aby organizačně bylo zajištěno, aby centrální složka při chodu podniku nepůsobila jako zbytečně zpomalující prvek, jak je to obvyklé například při zavedení oddělení centrálního nákupu v podniku.

 

Řízení informatiky je tedy jednou z centrálních kompetencí podniku, podobně jako řízení investic nebo lidských zdrojů. Je tedy nutné, aby předmět těchto kompetencí byl jasně a srozumitelně obecně definován pro veškeré ostatní složky podniku, aby bylo zřejmé, jakým způsobem se mají k informatice chovat při potřebách nebo přáních na podporu, která souvisejí s informatikou.

 

Nyní se podívejme na podmínky zde popisovaného modelu šířeji a souhrnně. Chceme, aby bylo možné zavést soutěž informatických služeb s externími a distribuovat řízení informatiky. Aby služby informatiky přirozenou cestou (prostřednictvím plnění přání a potřeb) mohly navazovat na podporované činnosti v podniku a zprostředkovaně dosahovaly až k zákazníkovi podniku nebo až ke spotřebiteli, je obecně nutné zavést v podniku vnitřní ekonomické vztahy. Aby bylo možné zavést vnitřní ekonomické vztahy, musí být splněny podmínky:

·          je nutné, aby uvnitř v podniku byly autonomní jednotky, které budou subjekty vnitřních ekonomických vztahů,

·          je nutné, aby existovaly vnitřní pravidla a procedury dohadování na podmínkách vnitřních ekonomických vztahů.

Přestože se nám jedná pouze o služby informatiky, je nutné, aby takové autonomní jednotky byly ustanoveny v celém podniku, nebo alespoň mezi potenciálními příjemci služeb informatiky. Toto vnitřní ekonomické členění je věcí organizace nákladového řízení – kontrolingu podniku. V tomto textu jsme celou problematiku začali vysvětlovat v členění podniku na procesy, a to z důvodu výše argumentovaných trendů takového členění. Pro existenci vnitřních ekonomických vztahů však není podmínkou přímo ustanovení procesů jako autonomních ekonomických jednotek. Obdobně lze za ekonomické jednotky považovat organizační útvary, odštěpné závody, nebo i jednotlivé zaměstnance podniku. Zde se ale i nadále přidržíme procesního pohledu, protože se z hlediska podpůrných činností a jejich ocenění, a tedy z hlediska rozpouštění režie podniku, jeví jako nejprogresivnější.[19] Důležitým momentem je, že vnitřní ekonomické jednotky splňují podmínky řízení prostřednictvím zájmů (viz výše).

Další uvedenou podmínkou je existence vnitřních pravidel pro dohadování o podmínkách vnitřních ekonomických vztahů. Tuto podmínku by měl plnit systém kontrolingu podniku. Je vhodné, aby tento systém kontrolingu dostatečným způsobem umožnil aplikovat specifika poskytování služeb informatiky. Zajištění tohoto souladu by měl mít v kompetenci ředitel informatiky (CIO), který odpovídá za centrální řízení informatiky, jak bylo argumentováno výše. Je nutné, aby dohody mezi zákazníky služeb informatiky a jednotkami (zde procesy), které je poskytují, byly obdobné případným vztahům podniku s externími dodavateli. Jak uvidíme dále, jedná se především o dohody na předmětu poskytovaných služeb, na jejich objemu, kvalitě a ceně. Pro sjednávání takových parametrů služeb je zavedená praxe prostřednictvím tzv. SLA, Service Level Agreements. Sjednávání poskytování služeb informatiky je velmi složité a mnoho lidí i mezi odborníky má o jejich možnostech a o možnostech jejich sjednání zkreslené představy, které mohou vést k dodatečným a často i skrytým nákladům. Proto je vhodné, aby toto sjednávání bylo speciálně u oblasti informatiky sofistikovaně centrálně řízeno. Na problémy, které tuto tezi podpoří, a na možnosti řešení se podíváme v kapitole Řízení požadavků a změn v informatice.

4       Řízení požadavků a změn v informatice

V této kapitole budeme analyzovat možná přání a potřeby na podporu informatiky. Nejprve se podíváme na problematická místa vzniku a formulace přání. Dále popíšeme problematiku řízení přání na informatiku v procesech řízení požadavků a změn.

Protože potřeby informatiky jsou reflektovatelné nesnadno a efekty informačních systémů je často míjejí, věnujeme jim podstatnou část tohoto textu a budeme je považovat za primární pohled na podnikovou informatiku. Definujeme zde podstatné problematické oblasti potřeb informatiky a ty, které se přímo týkají přání, uvedeme v této kapitole. Problémy, které se týkají specifikace služeb pro plnění potřeb a měření, zda skutečně splněny byly, uvedeme v kapitolách dalších.

 

Nejprve zaveďme základní princip pro služby informatiky, který ovšem v mnoha případech řízení podnikové informatiky není dodržen. Přání (potřeby) vnitropodnikových zákazníků informatiky by měla být odhalena v jejich podstatě a v principech, které se vážou k procesům, které mají podpořit, a měly by být poskytnuty takové služby informatiky, které tato přání (potřeby) splní. Takto jednoduše formulované pravidlo se zdá být až zbytečné tím, jak je samozřejmé. Z praxe však lze vidět, že je od něj často odhlíženo, a to patrně z důvodu příliš vysoké složitosti informačních systémů, jak bylo popsáno výše.

 

Zamyslíme se nad problémy, které uvedené pravidlo zatemňují a porušují.

 

Podívejme se nejprve na vznik potřeby nebo přání od začátku. Potřeba nebo přání může vzniknout jako nápad osob zajišťujících nějaký proces, aby jej zajistili pro svého zákazníka lépe a levněji. Otázkou je, zda toto přání lze splnit za pomoci informatiky. Že je to objektivně možné, ovšem nestačí. Navíc je nutné, aby osoby, které mají potřebu či přání, napadlo nebo se nějakým způsobem dozvěděli, že to lze. Toho je možné dosáhnout u obvykle informatikou řešených problémů dostatečnou informovaností o nabídce služeb informatiky. To neplatí, pokud jde o problém nestandardní. Pak vhodná konstelace nastane v závislosti na tvořivosti a kooperativitě lidí, kteří mají nápad – přání, potřebu.

Nyní tedy protagonisté procesů mají přání (potřebu) a tuší, že je možné je splnit pomocí informatiky. Dále je nutné, aby věděli, na jaké místo se se svou potřebou v podniku obrátit. Pokud vědí i to, je nutné nějakým způsobem potřebu formulovat. Poté, co je potřeba formulována, je nutné specifikovat službu informatiky (nebo více služeb), která tuto potřebu může splnit. Pokud je specifikován takový požadavek na službu, je nutné specifikovat podstatné parametry služby a její cenu.

Dále nesmíme zapomenout na kontrolní činnost, protože během seznamování s možnostmi informačních technologií je snadné zapomenout na jejich prvotní potřebu a může docházet k rozsáhlým výdajům na neopodstatněné funkce aplikací nebo na přehnaný komfort a jakost služeb. Musíme tedy specifikovat i způsob, jakým sledovat, zda služba je skutečně poskytnuta v požadovaných parametrech, zda služba skutečně plní přání či potřebu podporovaného procesu, a dále zda toto splnění přání skutečně mělo kladný vliv na podporovaný proces.

Pokud všechny tyto aspekty vezmeme v úvahu, můžeme hovořit o informatických službách ve smyslu plnění přání zákazníka. Všechny tyto aktivity jsou však zdrojem problémů, které mohou vést k porušení základního uvedeného pravidla, a dojde-li k tomu, skutečné podpoření procesů informatikou není kontrolovatelné.

Zejména u rozsáhlých softwarových aplikací je funkcionalita tak složitá, že k problémům v některé fázi dojde téměř s jistotou. Proto je nutné celý proces plnění potřeby vnitřních zákazníků, jak je zde uveden, mít zcela pod kontrolou.

 

Pro přehlednost uveďme celý postup jako seznam problematických míst:

1.       vznik přání, potřeby

2.       možnost splnění přání pomocí informatiky

3.       znalost možnosti splnění přání pomocí informatiky

4.       znalost místa pro sdělení přání na informatiku

5.       schopnost formulovat přání na informatiku

6.       specifikace požadavku na službu informatiky, která přání splní

7.       specifikace parametrů a ceny služby

8.       specifikace měření plnění (parametrů) služby

9.       specifikace měření plnění přání

10.    specifikace vlivu splnění přání na podporovaný proces

 

Abychom připravili problematiku pro specifikaci služeb a způsobů měření služeb informatiky v dalších kapitolách (tedy problematické oblasti 6 až 10), popíšeme nejprve zde podrobněji problematická místa 1 až 5.

 

4.1    Vznik přání, potřeby

V této části uvedeme podstatné aspekty formování přání a potřeb na oblast informatiky v podniku. Nejprve si vymezme pojem přání či potřeby na informatiku. V souladu s textem výše budeme pojmy přání a potřeba užívat společně s tím, že označují totéž[20].

Zákazník může mít libovolná přání a je na dodavateli, zda mu je splní. Pokud se jedná o tržní nabídku služeb, dodavatel se snaží plnit přání zákazníků i v případě, že jsou nesmyslná, a to z toho důvodu, že jeho cílem je obvykle výše obratu a zákazník zaplatí i za splnění nesmyslného přání.

To ovšem uvnitř podniku není rozumné. Z hlediska celkových nákladů a efektivity podniku není vhodné plnit jakákoliv přání vnitřních zákazníků, ale pouze přání smysluplná.

Z toho důvodu při distribuci řízení na procesy není vhodné hodnotit podpůrné procesy podle výše obratu, protože výše jejich obratu je přímo úměrná výši nákladů jimi podporovaných procesů a protagonisté podpůrných procesů by tedy měli zájem na vyšších nákladech podniku.

 

Zde se podívejme na to, jaká přání pokládat za smysluplná.

Podle systému zprostředkovaného plnění přání zákazníka podniku až přání spotřebitele na základě přání na podpůrné procesy je nutné, aby podpůrný proces plnil svým produktem taková přání, která přispějí k lepšímu splnění přání zákazníků podporovaného procesu, nebo přispějí k jejich splnění s nižšími náklady (jak bylo již uvedeno výše). Takovým přáním říkejme smysluplná.

Je otázkou, zda hodnocení smysluplnosti přání nechat pouze na osobách odpovědných za nákup produktů podpůrných procesů, nebo zda je nějakým způsobem ovlivňovat centrálně. Podívejme se na faktory, které efektivitu mohou obecně ovlivnit:

·          prospěchářství vnitřních zákazníků,

·          dobrá vůle, ale neznalost vnitřních zákazníků.

 

V případě informatiky můžeme první faktor – prospěchářství najít například v touze některých zaměstnanců po pro ně neopodstatněných technologických hračkách, zejména v přenosných osobních počítačích, v případě telekomunikací v exkluzivních mobilních telefonech, někdy i ve vynuceném přístupu k nepotřebným službám. Tento problém je nutné řešit primárně řízením efektivnosti uvnitř podporovaného procesu, ale přístup informatiky jej také může ovlivnit (viz dále).

 

Dobrá vůle, ale neznalost je situací, kdy zákazník chce podpořit svůj proces informatikou, ale neví přesně, jakým způsobem to udělat. Informační technologie jsou obor, jehož znalost je přisuzována pouze vyvoleným, patrně z důvodu technické náročnosti na znalosti, z důvodu rostoucí komplexity atd. Proto se zákazníci často spolehnou na znalé osoby, které pro ně nějaké technologie zajistí, a rezignují na kontrolu skutečného splnění svého přání nebo na přínosy. Přestože je to velmi udivující, v mnoha podnicích jsou nakoupeny vynikající technologie bez náznaků kontroly jejich přínosů.

Jiným případem je, že své přání zákazník sám promítá do jeho technologického zajištění, aniž by ho vůbec napadlo artikulovat důvody tohoto technologického zajištění, tedy jeho očekávaný přínos pro proces. Této tendenci zákazníků k „zatemněnosti“ přání dále nahrává postoj mnoha odborníků na informační technologie, kteří cítí schopnost a kompetenci problém zákazníka technologicky vyřešit.

Problém plnění přání zákazníka sice je informačně-technologický, ale až v druhé řadě. V první řadě je to věcný odborný problém podporovaného procesu, ve druhé řadě se jedná o problém řízení informatiky, a teprve ve třetí řadě jde o technologické řešení.

 

obr. 8,  Problém přání na informatiku

 

Tuto tezi vysvětleme. Jak bylo řečeno v části Rostoucí komplexita v informačních technologiích, problém informatiky je stále více v řízení změn a vztahů s dodavateli a největším problémem je uřídit rostoucí počet technologií v podniku. Z toho důvodu je velmi naléhavé veškeré aktivity v informatice řídit z hlediska jejich integrace do celkového informačního systému a z hlediska efektivity informačního systému. Je tedy nutné jakékoliv technologické řešení podřídit centrálnímu řízení informatiky podniku, posouzení z hlediska celkové integrace, strategie, zdrojů a kompetencí, a zajistit jeho soulad se všemi, třeba i složitými pravidly informatiky podniku. To platí i pro sebemenší změny. Pro jakékoliv samostatné aktivity technologických nadšenců v podniku dnes není místo, protože znamenají velmi vysoké riziko velmi vysokých dodatečných nákladů na integraci a zajištění budoucího provozu takových technologických anomálií. Stejně tak je velmi pravděpodobné, že bez sofistikovaného řízení technologické řešení mine skutečné věcné potřeby podporovaného procesu.

 

Je tedy nutné vhodným řízením zamezit možnosti zákazníků nesprávně překládat své věcné potřeby do požadavků na technologie, a stejně tak nesprávnému pochopení přání zákazníků informačně technologickými odborníky. Metody a techniky zajištění smysluplnosti přání existují a nebudeme je zde rozvádět.[21]

 

Shrňme vše uvedené do jedné podmínky: zákazník informatiky musí mít jasno, jaký parametr svého procesu (své činnosti, svého podniku apod.) chce pomocí služeb informatiky zlepšit. To by mělo být zadáním pro informatiku. Poté je možné mu pomoci. Je lhostejno, zda zákazník informatiky ví o tom, jakou technologií to lze udělat, nebo zda o tom nemá tušení. Rozhodování o technologii necháme na nabídce plnění přání informatickými procesy.

To je tedy kompetence zákazníka informatických procesů. Je zřejmé, že zákazník musí být odborníkem v předmětné oblasti svého procesu, ale nikoli už v oblasti informatiky. To ovšem s sebou přináší možnost, že zákazníka vůbec nemusí napadnout, že nějaký parametr jeho procesu lze podpořit informatikou. Pro tuto znalost již je třeba přehledu ve světě informatiky. Ovšem je velmi žádoucí, aby osoby odpovědné za hlavní procesy v podnicích, případně vrcholové vedení podniku vůbec, se v informatice orientovaly. Pro konkurenceschopnost podniku to může být přínosem. Není to však podmínkou. Zde jsme přiřadili odpovědnost za sledování možností informatiky a za nabízení možností podpořit konkurenceschopnost hlavních procesů řediteli informatiky – CIO. V takovém modelu je ovšem opačně nutné, aby se ředitel informatiky orientoval v hlavních procesech podniku a v jejich kompetencích. Kompetence hlavních procesů jsou však shodné s kompetencemi celého podniku a je nemyslitelné, aby vrcholový vedoucí, jímž ředitel informatiky bezesporu je, neměl o kompetencích podniku náležitý přehled. Tento model je tedy vhodnější, chtít po řediteli informatiky znalosti kompetencí podniku je rozumnější než chtít po managementu podniku znalost oblasti informatiky[22] (s ohledem na rostoucí komplexitu). Tato úvaha ovšem nic nemění na tom, že rozhodování o podpoře procesů informatikou musí být týmové.

Na vedení informatiky je ale i zajištění toho, aby přání zákazníka informatiky byla formulována jako přání podpořit konkrétní parametr podporovaného procesu. Přestože jde v důsledku o podpoření konkurenceschopnosti hlavního procesu, pokud je toho dosaženo podporou tohoto procesu, tedy informatika není orientována na zákazníka podniku a není hlavním procesem, ale pouze podporuje hlavní proces, je nutné specifikovat přesně, jak tento podporovaný proces informatika podpoří. Spokojení se s tím, že informatická podpora nebude měřitelná a že ke zvýšení konkurenceschopnosti dojde nějakým ne zcela jasným a měřitelným způsobem, znamená přerušit řetězec produktů procesů vedoucí k zákazníkovi podniku (nebo až ke spotřebiteli) a řízený přáním zákazníka podniku (nebo až spotřebitele), a tedy porušení principů řízení prostřednictvím přání a zavedení svévole. Měřitelnost podpory informatiky můžeme zajistit právě tím, že zákazník informatiky ve svém procesu (v oblasti, které rozumí) specifikuje parametry, které chce pomocí informatiky podpořit a jak (zda zvýšit či snížit měřitelný parametr apod.).

 

Vidíme, že problematika přání a potřeby služeb informatiky, tedy zejména zavádění automatizovaných informačních systémů, velmi úzce souvisí s problematikou řízení přínosů informačních systémů. Zdaleka ne všechny podniky se metodicky zabývají přínosy informačního systému před jeho zavedením, a ex post jsou přínosy často definovány uměle, aby došlo k ospravedlnění vynaložených nákladů. To je způsobeno jednak přístupem vedení k problému a jednak obtížností jejich vyčíslení.[23]

Odhadnout přínosy informačního systému skutečně může být obtížné. Proč tomu tak ale je? Patrně z toho důvodu, že při rozhodování o zavedení informačního systému často není známa ani výše nákladů na jeho zavedení, ani veškerá podrobná aplikační funkcionalita, kterou budou pracovníci užívat, ani organizační změny, které nové informační toky budou vyžadovat. Tyto faktory závisí na technologii (zaváděné technologii IS nebo technologii vývoje – zavádění) a díky své rozsáhlosti a podrobnosti někdy ani nemohou být při rozhodování vedení známy. Dodavatelé softwarových řešení se však při prodeji zaměřují na vedení podniku, které rozhoduje o nových informačních systémech v podniku a dokáží je ke svému řešení naklonit. V takovém případě je na nižších úrovních skutečně nutné přínosy „hledat“.

 

Zde však razíme myšlenku, že přínosy informačního systému jsou v mnoha případech velmi dobře měřitelné. Podmínkou pro to je zavádět informační systém jako řešení přání nebo potřeby nějakého procesu. Pokud skutečně existuje reálná potřeba informačního systému, na základě které je zaveden, lze vždy ex post měřit, jak dalece byla tato potřeba naplněna. Je bohužel možné, že v některých případech skutečný přínos (skutečnou míru splnění přání) lze předem pouze nepřesně odhadovat. Takovými skutečnostmi lze ale omlouvat pouze poskytování služeb informatiky vnitropodnikově. V době, kdy je mnoho služeb založeno na komerční bázi, se přirozeným způsobem objevují měřitelné charakteristiky služeb, které lze pro míru plnění přání vhodně použít. Navíc, pokud lze přínos pouze odhadovat, je nutné měřit pravděpodobnost a faktory, které jej ovlivní, a dále riziko, že nebude naplněn v dostatečné míře. Tím lze odhady velmi zpřesnit a zprůhlednit.

 

To ovšem neznamená, že zde popisovaná problematika není použitelná i pro problematiku „hledání přínosů“, naopak. I v případě, že je rozhodnuto zavést informační systém na základě reálné potřeby nebo přání, je někdy nutné očekávané přínosy dohledávat. Je to z toho důvodu, že informační systém, který vyřeší a podpoří určitou konkrétní potřebu procesu, může mít zároveň mnoho dalších efektů, a to i kladných i záporných, o kterých je vhodné předem vědět. Kromě toho, někdy je z hlediska úspory z rozsahu a z hlediska úspory na nutné pozdější integrační aktivity vhodné, aby byla obnova informačního systému řešena komplexně. Pak je vhodné zavést i některé části informačního systému, které podniku (nebo určitým jeho procesům) přinesou efekty, do kterých podnik investovat nechce, ale dodatečné náklady na jejich zajištění jsou při současném zajištění s požadovanou službou informačního systému velmi nízké.

 

Co se týče kladných možných efektů, je vhodné nabídnout je potenciálním příjemcům (zákazníkům) těchto efektů v podniku, aby rozhodli, zda jsou pro jejich procesy vhodné, a tím vyvolat jejich potřebu či přání, jehož míra splnění je v případě, že je efekt akceptován, opět ex post měřitelná. Pokud jsou možné dodatečné přínosy shledány potřebnými, mohou se také jejich vnitřní zákazníci podělit o náklady s původními zákazníky, jejichž přání aktivitu zavedení informačního systému vyvolalo (pokud to nejsou titíž), a tím se snižují náklady oběma z nich.

Záporné možné efekty jsou horší. Opět je nutné poradit se v podniku s těmi, koho se rizika těchto záporných efektů dotýkají. S nimi je nutné odborně ohodnotit riziko a toto ohodnocení je vhodné vzít v úvahu při rozhodování, zda vůbec bude informační systém zaveden či ne. Dále je nutné specifikovat faktory, které negativní přínos ovlivňují, a při vývoji informačního systému jejich prostřednictvím tlačit na minimalizaci rizika.

 

V každém případě platí, a to i v případě informačních systémů: Cokoli dělám, musí mít pozitivní efekt, a ten lze vždy určit a měřit. Pokud to pozitivní efekt nemá, nemá smysl to dělat. Úkolem managementu je zajistit, aby tento zmíněný efekt byl pozitivním pro podnik (pro vlastníky, zákazníka, zaměstnance …).

Existuje ovšem možnost, že pozitivní efekt sice existuje, ale je neartikulovaný, nerozpoznaný, ale pouze tušený. Taková situace je nebezpečná, protože pak znamená, že v dané oblasti není podnik dostatečně pod kontrolou. Z tohoto pohledu je oblast informatiky mnoha tuzemských podniků mimo kontrolu totálně. Outsourcing takovou situaci řešit může, ovšem efekty musí být definovány předem. Skutečnost, že je informatika mimo kontrolu, pro outsourcing není dobrým důvodem, což ukazuje mnoho případů.[24]

 

Problémy hodnocení přínosů informačních systémů nastávají zejména v případě, kdy nejsou dostatečné zkušenosti s vývojem informačního systému. Obecně lze říci, že to je v kterémkoli podniku, který se vývojem informačních systémů nezabývá jako svojí hlavní činností. (Výjimkou ovšem je podnik, kde právě nový informační systém zavedli, taková zkušenost však přichází příliš pozdě.) To znamená již zmíněnou nutnost specializace v oblasti informatiky, která nahrává budoucímu hojnému rozšíření outsourcingu.

 

Potřeby na informatiku však nemusí vždy vyústit do zavádění nového informačního systému. Přání vnitřního zákazníka může často splnit pouhá rada nebo nějaká drobná aktivita osob provozujících již používaný informační systém. Jak rozsáhlé aktivity je nutné pro splnění přání vnitřního zákazníka provést, jak to bude obtížné a nákladné, nelze často snadno a okamžitě určit. Často je nutná konzultace s odborníky, často je nutné provést technické šetření a podobně. Také z toho důvodu není možné, aby rozsah technologického zajištění svého přání specifikoval sám zákazník, nebo aby o něm dokonce rozhodoval. Zákazník se pak může rozhodovat až poté, co je mu ze strany podnikové informatiky nabídnuto řešení jeho potřeby, a to na základě informatikou odhadnutých parametrů: času řešení, nákladů (ceny), ale především míry splnění jeho přání. Proto, aby tyto odhady bylo možné udělat, je nutná nejen technologická znalost (kterou lze nakupovat), ale hlavně znalost přání a potřeby zákazníka. Z toho důvodu je nutné, aby osoby, které budou technologické řešení zajišťovat, znaly dobře přání zákazníka, a tedy je nutné toto přání dostatečně specifikovat. Jak bylo řečeno výše, je vhodné, aby měl zákazník jasno v tom, jaké parametry svého procesu chce informatikou podpořit. Sám o sobě však zákazník nemusí vědět, v čem má mít z pohledu informatiky jasno, a tedy je nutné na straně informatiky zjišťování přání vnitřního zákazníka řídit.

 

Dále je vhodné také odlišovat přání zákazníků (osob, které mají kompetenci rozhodovat o svých věcných oblastech) a přání uživatelů, kteří mohou mít dobré nápady, ale pro to, aby mohli požadovat splnění svého přání, nemají dostatečnou kompetenci. Vhodným řízením je nutné nikoli taková přání eliminovat, ale v rozumném souhrnu je předložit právě osobám kompetentním, které je mohou přijmout za své a zákaznicky je zlegalizovat. Obdobně lze nakládat s přáními a nápady informatiků.

 

Shrňme tedy: Informatiku podniku je nutno řídit tak, aby přání a potřeby zákazníků informatiky na informatiku byly formulovány v měřitelných parametrech procesu (činnosti) zákazníka, aby mohlo být později měřeno, jaký efekt měla informatická služba na tento parametr.

4.2    Možnost splnění přání informatikou

V procesu plnění přání jsme jako druhý kritický moment uvedli možnost splnění přání zákazníka informatikou. Z tohoto pohledu musíme rozlišit:

·          zákazníkova představa o možnosti splnění jeho přání,

·          skutečná současná technologická možnost splnění přání,

·          schopnost informatiky podniku toto splnění zajistit.

 

Jak už bylo uvedeno, zákazník nemusí mít představu o možnosti splnění jeho přání, a někdy je to dokonce lepší, protože toto posouzení by mělo být v kompetenci centrálního řízení informatiky podniku. Skutečnost, zda zákazník představu má a jakou, je tedy důležité pouze z hlediska uvědomění si přání na informatiku, případně z hlediska politických a mimoekonomických vztahů uvnitř podniku.

 

Další otázkou je skutečná technologická možnost splnění přání. Kompetencí podnikové informatiky je tuto možnost posoudit a udělat si rámcovou představu o možném řešení.

Pro to je potřebná dostatečná orientace na trhu služeb informatiky, na trhu tzv. komplexních řešení v informačních systémech, na softwarovém trhu, případně na trhu informatických lidských zdrojů. To znamená pro ředitele informatiky (CIO) neustálou nutnost vzdělávání v možnostech služeb a technologií a neustálou orientaci v nabídce na zmíněných trzích. Na základě takových znalostí může podniková informatika navrhnout (nejlépe variantně) možné služby, které mohou přání splnit. Důležitá je také schopnost rámcového odhadu důležitých parametrů služeb a celkových nákladů (a to včetně tzv. skrytých nákladů) na zajištění služby.

Dále je k posouzení řešení nutná znalost o současném zajištění informatických služeb uvnitř podniku, neboť mnoho přání zákazníků bude patrně možné řešit drobnou úpravou stávajících služeb, nebo přání dokonce již splněna jsou.

 

Podle možnosti splnění přání informatikou můžeme přání klasifikovat takto:

·          přání lze splnit již poskytovanou službou (ve stávajících parametrech),

·          přání lze splnit modifikací již poskytované služby,

·          přání lze splnit zavedením nové služby.

Tato klasifikace je pro řízení informatiky v našem modelu „CIO jako IT broker“ podstatná. Promítne se nejen do řízení plnění přání zákazníka, ale zprostředkovaně i do vztahů s externími poskytovateli služeb.

Vlastností mnoha informatických služeb je, že aby vůbec bylo možné je poskytovat, je potřeba vynaložit nějaké aktivity a prostředky. Někdy se jedná o parametrizaci softwarového balíku, někdy o úpravu programů, někdy se jedná o rozsáhlý mnohaměsíční projekt. Tato klasifikace je významná především z pohledu určení nákladů na změnu, tedy z nákladů na splnění přání. Protože řízení změn v informačním systému je opět velmi rozsáhlou a komplexní záležitostí, je vhodné toto řízení nějakým způsobem distribuovat, aby vedení informatiky (CIO) nebylo zahlceno nutností řešit mnoho drobných změn. Zároveň je ale nutné vrcholově rozhodovat o změnách, které si vyžádají vysoké náklady a využijí mnoho zdrojů. Proto uvedené členění lze interpretovat nebo reformulovat pomocí nákladů na změnu:

·          náklady na změnu, která umožní splnění přání, jsou nepatrné,

·          náklady na změnu, která umožní splnění přání, se pohybují do určitého limitu,

·          náklady na změnu, která umožní splnění přání, se pohybují nad tímto limitem,

 

Odhad těchto nákladů na změnu není často jednoduchou věcí. Je nutné vzít v úvahu zejména zajištění celkové logické integrity informačního systému, spolupráci jednotlivých různých subsystémů a návaznost a souvislosti jednotlivých informatických služeb a souvisejících podnikových procesů. Odhad se týká především vývojových aktivit v informačních systémech, což je metodicky mnohokrát a podrobně propracovaná oblast (a tedy se jí zde nevěnujeme).

 

Dalším speciálním typem způsobu plnění přání zákazníka je oprava špatně poskytované služby a zajištění jejího (opětovného) poskytování v dohodnutých parametrech. V předchozí klasifikaci bychom mohli tento případ zařadit pod kategorii „přání lze plnit již poskytovanou službou“. Z hlediska vnitroekonomických vztahů i vztahů s dodavatelem je toto zařazení důležité. Ze zákaznického hlediska totiž je služba řádně zakoupena a měla by být i řádně poskytována. Pokud řádně poskytována není a informační systém vyžaduje nějakou opravu, je to věcí toho, kdo službu poskytuje, a oprava by měla být provedena na jeho účet. Náklady v tomto případě nemusí být nepatrné, ale nenese je zákazník, a proto jsou nepatrné alespoň z jeho pohledu. Nutnost opravy a opětovné poskytování služby v dohodnutých parametrech ale nemusíme považovat za přání zákazníka, ale pokud takovou nutnost zákazník nebo uživatel poskytovateli služby sdělí, můžeme to považovat za informaci o tom, že služba není poskytována v pořádku, a za požadavek na zjednání nápravy.

 

Dalším aspektem možnosti splnění přání je schopnost podnikové informatiky přání zajistit. Zde přichází ke slovu rozhodování, zda splnit přání interními prostředky, nebo zda splnění nakoupit od poskytovatele. Toto rozhodování závisí na postoji podniku ke službě informatiky (zda je hlavní či strategická), na schopnostech a možnostech zdrojů podnikové informatiky a ovšem na nabídce na trhu služeb informatiky (viz výše).

 

Také je nutné zmínit, že dodavatelé software a informačních systémů při prodeji často argumentují jeho přínosy pro zákazníka. Takovou argumentací mohou vzbudit potřebu nebo přání. Ne vždy se ale slíbené přínosy skutečně dostaví. Pokud ale dodavatelé přínosy nabízejí, mohou se také zavázat k tomu, že přínosů bude dosaženo, a pomocí služeb informatiky to mohou zajistit nebo podpořit. I z tohoto důvodu zde specifikujeme přání na informatiku v tomto duchu. Roli hraje i skutečnost, že dodavatel ví, jakým způsobem může být pomocí jeho produktu (software) přínosu dosaženo, zatímco zákazník to vědět nemusí. Dodavatele je tedy nutné v plnění jeho závazku kontrolovat, což v případě plnění přání jako přínosů informatiky není jednoduché. Tento aspekt je pro řízení informatiky podstatný a celý tento text s ním počítá.

4.3    Znalost místa pro sdělení přání na informatiku

Dalším kritickým bodem při plnění přání zákazníka informatiky byla znalost zákazníka, kam se má obrátit se svým přáním na informatiku. Pokud má zákazník nějaké přání, měl by vědět, komu ho sdělit, na koho se se svým problémem obrátit.

V této problematice musíme začít základním předpokladem: Zákazník (resp. uživatel) toho musí vědět o informatice co nejméně, případně nemusí vědět nic.

Proto musíme předpokládat, že ani nebude vědět, kam se se svým přáním obrátit.

Ovšem můžeme nutit zaměstnance podniku, aby četli interní směrnice, ve kterých jim sdělíme konkrétní kontaktní místa, ale nelze spoléhat na to, že si to jednak budou pamatovat a jednak podle toho.také konat. Naopak, musíme předpokládat že budou jednat i jinak. To ovšem znamená, že by mohli zajistit řešení svých problémů nějakým způsobem, který může do informatiky zanést problémy, jako neintegritu, nutnost dodatečných nákladů, nemožnost měření přínosů a podobně. Tomu je nutné vhodným řízením zabránit. A zde se podívejme na nástroje, jakými je to možné.

 

Prvním nástrojem je zavést jednotné místo pro sběr všech přání a požadavků. Takové centrum se obvykle nazývá helpdesk, hotline nebo callcentrum, podle toho, jaké další funkce nese. Veškerá přání vnitřních zákazníků je tedy vhodné směrovat na toto místo.

 

Pokud je zavedeno toto jednotné místo, je vhodné udělat tomuto místu dostatečnou reklamu, aby vnitřní zákazníci o něm měli alespoň tušení. Ovšem je pravděpodobné, že s drobnými potřebami se budou raději obracet například na své známé v informatice, se kterými se znají a potkávají a kteří jim přání splní na osobní bázi. To může z hlediska komplexity informačního systému vést opět k neodhadnutelným a neřiditelným budoucím problémům. Proto je vhodné zavést druhý nástroj: opatření, které zakáže všem pracovníkům v oblasti informatiky plnit přání zákazníků a uživatelů služeb informatiky, aniž by to přání prošlo zmíněným centrálním místem. Zavedení tohoto opatření může sice krátkodobě působit negativně na vztahy mezi zaměstnanci a také patrně zvýší transakční náklady na předávání drobných požadavků a řešení drobných problémů, ale z dlouhodobého pohledu mnoho problémů plynoucích z komplexity informačních technologií podniku vyřeší. Za všechny uveďme příklad možné údržby aplikace i po několika kolech drobných změn a po odchodu zaměstnance, který je provedl.

 

V souladu s principem „zákazník (uživatel) nemusí vědět nic“ je vhodné zavést toto centrální místo helpdesk, hotline či callcentrum (dále říkejme třeba helpdesk) pro více účelů, než jen pro předávání přání na informatiku. Dále je možné je použít například pro rezervaci podnikových prostředků, pro řešení personálních nebo mzdových otázek a podobně. Tak lze zmíněný princip rozšířit i na zbylé podpůrné oblasti v podniku.

 

Samozřejmým předpokladem pro použití interního helpdesku je dostatečné vyškolení pracovníků, kteří budou v kontaktu s jeho uživateli, aby uměli rozpoznat, jaký typ přání na ně uživatel má, a aby věděli, jakým způsobem s tímto přáním naložit. Dále je nutné, aby přání, která jsou takto předána centrálnímu místu helpdesk, nezůstala nevyslyšena, ale dostala se k osobám, které jsou kompetentní o možnosti splnění přání rozhodnout. Je tedy nutné tento tok požadavků formálně usměrnit a řídit. Kromě toho, že přání bude nebo nebude nějakým způsobem splněno, nebo že se s  interním zákazníkem někdo spojí, aby přání projednal, je také vhodné, aby zákazník byl dostatečně informován o průběhu vyřízení jeho požadavku. Tato informovanost, ať už zajištěná aktivně ze strany helpdesku nebo dotazem na stav ze strany zákazníka, může napomoci tomu, aby byl tento způsob předávání přání skutečně uvnitř podniku využíván. Aby mohl být zákazník informován, ale také, aby bylo možné účinně tok přání řídit, je nutné, aby byla veškerá přání a dotazy na helpdesk tímto místem evidovány.

Je také vhodné zabezpečit, aby si uživatel helpdesku (zákazník informatiky) mohl zvolit, jaký typ kontaktu s tímto jednotným místem mu vyhovuje, a aby mohl své přání přednést osobně, telefonicky, elektronickou poštou, písemně, nebo i jiným způsobem.

 

Výhody tohoto přístupu jsou evidentní. Pro plánování aktivit v informatice podniku, ale i v podnikatelské činnosti je vhodné zabývat se veškerými připomínkami a přáními zaměstnanců. Pokud podnik provozuje interní helpdesk, má veškeré tyto informace zaznamenány na jednom místě, a to obvykle i ve formě, která umožňuje jejich statistické vyhodnocení. Jakým způsobem proměnit tato přání až do jejich splnění a vyhodnocení tohoto splnění, ukážeme dále v textu.

 

I přes uvedená opatření zavádějící jednotné místo není možné zabránit předávání přání jinými kanály. Například není vhodné odkázat na helpdesk vrcholové představitele podniku, když se obrátí přímo na ředitele informatiky s požadavkem na drobné úpravy na notebooku. Pro podobné případy je vhodné zavést kategorii VIP pro určité osoby, se kterými bude zacházeno zvláštním způsobem.

Obdobně je vhodné přijímat přání na informatiku i z porad vedení a plynoucích ze strategických dokumentů přímo, tedy mimo jednotné místo pro jejich předávání. Je velmi pravděpodobné, že přání a potřeby, případně nápady na rozsáhlejší akce v informatice bude vrcholové vedení řešit osobně s ředitelem informatiky. Některé z nich mohou být již profiltrovány projednáním v konkrétních odborných procesech nebo útvarech. Tento způsob sdělování přání a požadavků na informatiku je ovšem vhodný a konstruktivní. I v takovém případě však je vhodné tento způsob detailně řídit, opět aby nedošlo k problémům plynoucím z komplexity.

4.4    Schopnost formulovat přání na informatiku

Dalším z kritických momentů podle výše uvedeného seznamu je schopnost formulace přání na informatiku. Zde se opět vrátíme k typu přání, která mají do informačního systému rozsáhlý dopad, obecně k přání na novou informatickou službu (i když takové přání nemusí vždy k nové službě vést). Nejlépe je možné další problematiku vztáhnout na služby, které poskytuje aplikační software (podrobněji viz Služby podnikové informatiky), ale platí obecně.

Zatím jsme uvedli, že zákazník musí mít jasno, jaký parametr svého procesu chce podpořit.

 

Zde se podívejme na to, jaké typické parametry procesů lze informatikou podpořit, a jak tedy v našem modelu může vypadat přání na podporu informatikou.[25]

 

Obecně můžeme přání na informatiku z hlediska jiných procesů v podniku klasifikovat například takto:

·          Zvýší rychlost průběhu procesu

·          Zvýší kapacitní parametry procesu

·          Zvýší pružnost změn procesu

·          Sníží náklady procesu

·          Sníží nároky procesu na zdroje

·          Zvýší možnost kontroly procesu

·          Sníží riziko aktivit v procesu

·          Umožní určité aktivity nebo způsob průběhu procesu

 

Z hlediska řízení podniku pak můžeme přání na informatiku hodnotit z hlediska těchto faktorů

·          Podpoří cíl podniku

·          Zvýší operabilitu při hledání podnikatelských příležitostí

·          Zvýší možnost kontroly podniku

·          Sníží náklady (zefektivní využití zdrojů)

·          Sníží riziko

 

Pohled procesů a pohled celopodnikového řízení si nijak neodporují a měly by být v souladu. Jedná se o pohledy na přínosy z pohledu dvou úrovní řízení. Pokud podnik distribuuje řízení jinak než na procesy, je možné, že bude účelné podívat se na přání a efekty ještě z jiného pohledu (například funkčního, regionálního, …).

Uvedené efekty mohou být přímé, tedy mohou být přímo vyvolány službou informačního systému. Efekty mohou být ovšem i nepřímé, takové, které jsou vyvolány službou informatiky zprostředkovaně. Podniku i procesům v podniku obvykle jde o zprostředkovaný efekt, jímž je například zvýšení obratu, spokojenost zákazníka a podobně.

Z hlediska přesnosti měření a určení skutečných důvodů a účinků služeb informačního systémů je vždy nejvhodnější určení přímých efektů. Pokud jde o efekty nepřímé, je vhodné specifikovat podmínky, které ukáží, jakým způsobem se okamžité a přímé efekty promítnou do sekundárních, a umožní odhalit jednak faktory, které (kromě informatické služby) požadované efekty ovlivňují, a hlavně kauzální skoky neopodstatněných a neoprávněných očekávání od informačního systému, které mohou vzniknout, není-li plnění přání vnitřního zákazníka artikulováno právě řetězcem přímých efektů služby informatiky.

 

V kapitole Měření služeb IS a jejich efektů tyto možné efekty popíšeme podrobněji.

 

Jiným možným pohledem by bylo specifikovat potřebu určitých informací na určitých místech. Tento způsob přání na informatiku je důležité zmínit. Specifikace potřeb konkrétních typů informací na konkrétní místa je však zejména v rozsáhlém podniku velmi podrobnou záležitostí. Z hlediska drobných přání jednotlivých uživatelů tedy taková formulace přání je možná. Z hlediska zákazníka informatiky však bez podrobné analýzy tímto způsobem přání specifikovat snadno nelze. Rozsáhlá analýza, kterou informaci na které místo a ve který čas je již poměrně nákladná, a proto je vhodné ji ponechat již jako součást změny, která povede k jiným způsobem specifikované potřebě. Určitá konkrétní informace je totiž vždy potřebná k nějakému účelu a zde specifikujeme potřebu informatiky právě tímto účelem.

 

Pokud použijeme principy, že zákazník není odborníkem v informatice a nemusí nic vědět, vyplyne nám, že nemusí být vůbec schopen své přání ani v náznaku formulovat. Tento předpoklad je sice trochu přehnaný vůči pracovníkům odpovědným za podporované procesy v podniku, nicméně zavedeme ho, abychom obecně vyřešili případ, pokud by tomu tak skutečně někdy bylo, ale zejména proto, abychom dali informatice nástroj, jakým účinně řídit formulaci přání tak, aby bylo později měřitelné.

Vhodným začátkem je nechat zákazníka (resp. uživatele) zformulovat problém jakýmkoliv jemu blízkým způsobem. Tato formulace ale nemusí být vhodná pro rozhodování, zda a jakým způsobem přání splnit. Pokud tedy vhodná není, bude podkladem pro další jednání informatiků-analytiků se zákazníkem. Toto jednání může proběhnou také v případě, že zákazník není schopen zformulovat své přání vůbec (což mimochodem samozřejmě vůbec není lidský nedostatek). Jednání by mělo proběhnout za řízení komunikace informatikem, jehož cílem je zformulovat přání zákazníka do vhodné podoby. A nyní se konečně podívejme, jaká podoba je pro formulaci přání vhodná.

 

Vhodná formulace přání je taková, která:

·          specifikuje přání věcně v oblasti a jazyce procesu, který má být informatikou podpořen (tedy jazykem zákazníka),

·          specifikuje kvantifikovatelné parametry procesu (nebo jiné jednotky – podniku, pobočky), které mají být v důsledku informatiky záměrně zvýšeny nebo sníženy, a dále další parametry, které mohou být ovlivněny sekundárně;

·          specifikuje rámcovou představu o službě, která by mohla tyto parametry ovlivnit (ovšem pozitivně), pokud se jedná o aplikační službu, pak rámcová představa o aplikační funkcionalitě;

·          specifikuje rámcovou představu použití technologie pro toto zlepšení, případně odkazy na reference, kde je podobná technologie použita.

 

Zákazník patrně bude mít nějaké představy o tom, jakou službou, případně jakým typem aplikace, nebo dokonce jakou konkrétní aplikací lze jeho přání vyřešit. Pro sjednocení představ a vhodnou formulaci je možné tuto představu jako pomůcku použít, aniž by se do budoucna počítalo právě s takovým konkrétním řešením. Dnes však, pokud se nejedná o podnik na zelené louce, je obvykle již požadovaná informatická služba nějakým způsobem zajištěna. Pak je vhodné potřebu specifikovat požadovanými změnami oproti v současnosti poskytované službě.

 

Dále je v jednání vhodné začít specifikovat logické podmínky, které vedou od představy konkrétní informatické služby až k předpokládaným efektům, tedy k úpravě kvantifikovaných parametrů podporovaného procesu.

Specifikace takových podmínek pak může být komunikačním nástrojem pro dohodu nad skutečnými důvody a očekávanými přínosy služby, a pomůže specifikovat přání v jeho čisté, neopodstatněnými očekáváními neznečištěné podobě.

V podmínkách splnění potřeby lze dále specifikovat další faktory, které plnění přání ovlivňují, což může být podkladem pro rozhodování o tom, zda a jak tyto faktory také ovlivňovat, nebo jakým způsobem se takové faktory mohou promítnout do efektů služby informatiky.

 

Příklad procesního pohledu – případová studie, zjednodušeně:

Podnik se zabývá poskytováním telekomunikačních služeb. Dosud měl několik stovek zákazníků, ale předpokládá expanzi na počet několika desítek tisíc během následujících dvanácti měsíců. Způsob prodeje podnik uznal za vhodný, je dimenzován dostatečně a měnit se nebude, pouze naroste počet osob, které se prodejem a obsluhou zákazníka budou zabývat. Počet zákazníků již začal narůstat a stávající zákaznický systém je dimenzovaný na malý počet zákazníků.

Zákazníkem informatické služby je proces prodej telekomunikačních služeb koncovému zákazníkovi, který zajišťuje veškerý styk podniku se zákazníky.

V současné době informatika poskytuje procesu „prodej telekomunikačních služeb koncovým zákazníkům“ informatickou službu „zákaznický informační systém“, která má dostatečnou požadovanou funkcionalitu (vazba na tarifikaci, smlouvy, fakturace, platby a pohledávky, …).

Při jednání mezi osobou odpovědnou za proces prodeje telekomunikačních služeb (zákazníkem informatiky) a osobou odpovědnou za interní poskytování služeb informatiky dojde ke specifikaci požadavku na služby:

Přáním zákazníka informatiky je zvýšit kapacitu procesu prodeje a obsluhy zákazníka podniku ze současného jednoho tisíce na asi 80 tisíc.

Služba „zákaznický informační systém“ je vhodně definována v předmětu a parametrech. Všechny tyto jsou vyhovující a je vhodné je zachovat. Kromě dvou parametrů, které je nutné zvýšit, a to:

·          počet uživatelů současně využívajících systém,

·          maximální počet zákazníků, které je systém schopen obsloužit.

Parametry služby jsou zvoleny vhodně, protože kopírují parametry procesu prodeje telekomunikačních služeb:

·          počet uživatelů služby = lidské zdroje potřebné pro proces prodeje telekomunikačních služeb,

·          kapacita systému = možný počet obsloužených zákazníků.

Oba parametry jsou kvantifikovatelné, a dokonce jednodušeji kvantitativní, měřené v počtu lidí.

Dále byly specifikovány podmínky splnění přání (zde velmi zjednodušeně):

·          podnik chce prodávat služby více zákazníkům (počet XX, obrat XX, během doby YY) a aby to mohl udělat, musí umět tyto zákazníky získat a udržet; aby je udržel, musí poskytovat konkurenceschopné služby. Parametry služeb zákazníkovi jsou konkrétně definovány (doba realizace přípojky, počet neuskutečněných spojení, …);

·          aby zajistil konkurenceschopné parametry služeb, musí zvýšit použité vstupy procesu (počet pracovníků obsluhujících zákazníka, atd.).

Jedním z použitých zdrojů procesu je informatická služba zákaznický systém (ve specifikovaných parametrech).

Taková specifikace přání zákazníka je dostatečná. Specifikuje skutečné důvody požadavku na informatiku a zároveň obsahuje dostatek podkladů pro určení, kvantifikaci a následné měření efektů služby informatiky. O tom dále.

 

Je vidět, že podmínky splnění potřeby jsou specifikovány pouze ve změněných parametrech, zde v příkladu se jedná o „více zákazníků“. Ostatní aspekty jsou také velmi důležité, ale z hlediska změny, o kterou se jedná, jsou nepodstatné, protože zde předpokládáme, že se nemění (například způsob prodeje, činnosti prováděné během procesu prodeje a tedy ani funkcionalita zákaznického systému). Během prvních fází vývoje je nutné z pohledu systémové integrace posoudit, zda tato změna z hlediska informatiky nějak ostatní parametry může ovlivnit. To už je ale problematikou vývoje informačního systému, kterou se zde nezabýváme. [26]

 

V našem příkladě patrně bude nutné posoudit, jak dalece nárůst počtu zákazníků ovlivní dobu odezvy informačního systému, jak se promítne do možnosti zpracování fakturace do požadovaného data a podobně.

 

Z našeho pohledu je podstatné, že výsledkem takového posouzení může být návrh informatiky na další zajištění služby s pozměněnými parametry. Jakým způsobem specifikovat službu a její měření se podíváme v kapitole Předmět aplikačních služeb. Dále také ozřejmíme možnosti specifikace přání a kvantifikace efektů v méně jednoznačných případech.

 

 

Popsali jsme tedy první kritická místa řešení přání zákazníka informatiky. Dalším kritickým místům, která již se přímo týkají služeb informatiky a jejich měření, jsou věnovány speciální kapitoly (Služby podnikové informatiky a Měření služeb IS a jejich efektů).

4.5    Proces řízení požadavků a proces řízení změn

Uvedené principy a problémy by měly být v podnikové informatice řízeny. Zde se podívejme na procesy, kterými je možné a obvyklé tyto aspekty informatiky řídit. Jedná se o dva procesy, proces řízení požadavků a proces řízení změn. Oba můžeme chápat jako formalizaci postupů, které mají za úkol zajistit v podnikové informace výše uvedené principy, aby byla zajištěna dostatečná kontrola veškerých aktivit v informatice podniku a zamezilo se neřiditelným informatickým aktivitám, zejména neřiditelné expanzi drobných informatických služeb, které mohou vést k přílišnému nárůstu nekontrolovatelné komplexity v informačních technologiích podniku a neodhadnutelným dodatečným nákladům na změny a integraci. Tyto procesy mohou mít různou podobu,[27] zde se podívejme jen na podstatné aspekty jejich účelu.

 

Účelem procesu řízení požadavků je zajistit distribuci přání na služby informatiky od jejich původců k jejich kompetentním příjemcům. Tento proces obvykle realizuje výše zmíněné callcentrum, helpdesk nebo hotline. Proces tedy zahrnuje:

·          sběr požadavků,

·          jejich uložení a evidenci,

·          klasifikaci požadavků,

·          předání požadavků kompetentním místům, v některých případech přímo vyřízení,

·          převzetí zprávy o stavu vyřízení požadavku,

·          informovanost původců požadavku (dalších míst) o průběhu vyřízení,

·          různé nakládání s požadavky podle jejich priority.

 

Proces řízení změn má v informatice úkol zajistit, aby veškeré změny, které jsou v informačním systému podniku provedeny, byly předem dostatečně zváženy (jejich dopad, náklady, efekty atd.), a aby byly řádně dokumentovány a nenarušily kontrolovatelnost informatiky podniku. Účel tohoto procesu je nutné odlišit od řízení změn během informatických projektů, které je součástí řízení projektu. Zde uvedený proces řízení změn řídí změny před tím, než je pro jejich realizaci zaveden projekt (je-li).

Proces zahrnuje:

·          převzetí požadavku, jehož splnění vyžaduje změnu v informačním systému od procesu řízení požadavků,

·          posouzení a schválení změny z hlediska strategických záměrů a plánů podniku a informatiky,

·          posouzení a schválení změny z hlediska stávájícího stavu služeb informačního systému,

·          další úrovně schvalování změn, konzultace s dotčenými místy,

·          eskalace požadavků na změny, prioritizace,

·          dohoda se zákazníkem (původcem požadavku) na možnostech splnění požadavku,

·          interní dohody o realizaci změny,

·          úpravy interních dohod o provozování služeb,

·          plánování drobných změn, plánování změn v dlouhodobém výhledu, plánování projektů (rozhodování make or buy),

·          zadání projektů,

·          koordinace provedení některých změn, zajištění akceptace provedených změn,

·          provedení a testování některých drobných změn, uvedení do provozu,

·          dokumentace změn,

·          informování zúčastněných míst o průběhu provádění změn a o provedení změn.

 

Hranice mezi těmito procesy může být podle jejich konkrétní implementace v podniku různě posunuta, někdy se může jednat i o proces jeden.

Je nutno zmínit, že řízení těchto procesů z hlediska informatiky velmi úzce souvisí s řízením problémů (problem a incident management) a jejich řešení. Z přání uživatele totiž není vždy možné rozeznat, zda se jedná o požadavek na nějakou změnu v informačním systému, nebo požadavek na opravu nějaké části informačního systému, která zamezuje v řádném plnění služby v dohodnutých parametrech, kdy se jedná o problém. Dalším souvisejícím procesem, který však pro naši problematiku není podstatným, je tedy řízení problémů.

 

Zavedení těchto procesů může velmi zefektivnit práci z hlediska rostoucí komplexity a řiditelnosti informatiky pro střední a velké podniky. Tyto procesy nejsou pro zákazníky informatiky produktivní, nevytvářejí pro procesy hodnotu. Mohou ale uspořit zdroje. Přínosy zavedení těchto procesů pro podnik je tedy vhodné hodnotit prostřednictvím alternativních nákladů, tedy jako úsporu jinak vynaložených nákladů, v některých případech lze najít přínosy ve zvýšení operability podniku při změnách a ve zvýšení kontroly v oblasti informatiky. Také tyto efekty, podobně jako efekty služeb informatiky, je vhodné kvantifikovat.

Tyto procesy pomáhají informatice při komunikaci s ostatními procesy. Jsou tedy jakousi podporou prodeje produktivních služeb. Procesům, které jsou zákazníky informatiky a které jsou zdrojem požadavků pro tyto procesy, však žádné produktivní služby neposkytují. Přesto je obvyklé za služby typu callcentra platit. Taková služba má však pro zákazníka hodnotu pouze v případě, že je spojena s jinou, produktivní službou. Například je-li poskytována aplikační služba kancelářského informačního systému, lze ji poskytovat bez řízení požadavků a změn. To ale poškodí dlouhodobé řízení informatiky, nikoli bezprostředně zákazníka služeb. Pro zmíněné možnosti použití callcentra nebo helpdesku pro uživatelská hlášení problémů a poruch ve službách informačního systému to platí obdobně, přestože zde již lze sledovat vazbu možnosti callcentra na reakční dobu při řešení problému, což může být parametrem aplikační služby. Pro zákazníka informatiky je tedy naprosto nedůležité, zda spolu s nějakou službou informatiky bude moci předávat požadavky nebo ne.

Z hlediska řízení informatiky lze hodnotit služby těchto procesů jako služby, které užívají ostatní procesy, které poskytují služby informatiky. Náklady na ně je nutné vhodným způsobem zakalkulovat do produktivních služeb informačních systémů. Jakým způsobem to lze udělat ozřejmíme v kapitole Služby podnikové informatiky. To ovšem nic nemění na tom, že tyto procesy je také možné outsourcovat.

 

Zde hovoříme o použití řízení požadavků a změn pouze z hlediska informatiky, kde je potřeba takových procesů velmi naléhavá. Obdobné procesy lze ovšem využít i pro jiné oblasti v podniku, než je informatika. To platí obdobně jako u callcentra, jednotného místa pro předávání přání na informatiku.

Pokud jsou využity kapacity procesů řízení požadavků a změn i pro jiné činnosti v podniku, mohou se tyto opět o náklady na zabezpečení těchto procesů podílet. Podle způsobu jejich zabezpečení a řízení jejich nákladů lze někdy služby těchto procesů poskytovat jako zvláštní službu informatiky podniku, a to z toho důvodu, že právě v informatice byl tento proces implementován nejdříve.

 

Přestože možnosti informatiky se mění velmi rychle, pro podnik naléhavější změny probíhají v podnikatelské oblasti. Mnoho podniků dnes řídí své aktivity za uvědomění si neustálé změny. Pro tento přístup je zavedený proces řízení změn vhodný, je ovšem otázkou, jak dalece je vhodné řešit jej shodně a společně s řízením změn v informatice. V každém případě je nutné minimálně řešit návaznosti informatických změn na podnikatelské.

5       Služby podnikové informatiky

V této kapitole se zaměříme na služby informatiky. Nejprve vymezíme pojem architektury služeb. Dále se pokusíme rozčlenit služby podnikové informatiky, a to na aplikační služby, infrastrukturní neboli služby zdrojů a služby řídící. Největší důraz věnujeme službám aplikačním, popíšeme principy popisu předmětu aplikačních služeb, a to i v souvislosti s potřebou informatiky, s vývojem IS a se způsobem zajištění služby. Také popíšeme specifickou otázku ceny aplikačních informatických služeb. Krátce zmíníme některé aspekty řízení zdrojů jako východisko pro další kapitoly, podíváme se na uživatelské infrastrukturní služby v souvislosti s aplikačními a kapitolu uzavřeme argumentací nutnosti centrálních řídících aktivit v IS, které ovšem také mohou být vyčleněny v podobě řídících služeb.

5.1    Architektura služeb

Služby informatiky poskytované zákazníkovi se nyní pokusíme sjednotit do pohledu, který na „jednom papíře“ umožní jejich celostní zobrazení a tedy řízení - do architektury služeb.

 

Zavedeme architekturu služeb jako obecný komplexní pohled na předmět služeb informatiky v podniku.

 

Celostní pohled na řízení podnikových informačních systémů prostřednictvím architektur je neustále naléhavější a tedy i oblíbenější. Je to zejména z toho důvodu, že je nutné a obvyklé stále více peněz a kapacit zdrojů informatiky věnovat na integrační aktivity a projekty, které jsou zapříčiněny rostoucí komplexitou informačních technologií. Integrační aktivity směřují často k odstranění problémů a neefektivit v informačních systémech, které vznikly v minulosti právě zanedbáním integrity stále komplexnějšího systému. Dále, a to je podstatnější, jsou důvodem aktivit zaměřených na integraci částí informačních systémů v podniku změny v podnikání, které je při použití rozsáhlého a komplexního informačního systému neustále složitější operativně technologicky následovat.

 

Nejprve se podívejme na pohled na informační systém podniku a jeho architekturu podle metodiky vývoje informačního systému MDIS[28].

Základním celostním pohledem na informační systém podniku podle MDIS je globální architektura, na kterou navazují architektury dílčí. Architektury mají grafické a slovní vyjádření.

Globální architektura je vize budoucího stavu informačního systému, která zachycuje jeho základní stavební bloky a vazby mezi nimi. Stavební bloky globální architektury představují aplikace nebo skupiny aplikací v informačním systému podniku, které reprezentují současně funkce aplikace, jejich datovou základnu, aplikační software, základní software a hardware, které jsou technologickým prostředím aplikace.

Na globální architekturu navazují další celostní pohledy na informační systém, které jsou vždy jedním z vybraných hledisek. Jedná se o funkční architekturu, datovou architekturu, procesní architekturu, softwarovou a hardwarovou architekturu.

 

Metodika MDIS je metodika vývoje IS. Zde se vývojem informačního systému nezabýváme. Architektury informačního systému jsou ovšem vhodné i pro obecný pohled na řízení informatiky podniku.

 

obr. 9,  Globální architektura IS/IT

 

Globální architektura IS/IT v podstatě zobrazuje aplikační členění informačního systému, tedy věcný pohled (zákazníka) na podnikový informační systém s tím, že pro specifikaci stavebních kamenů je kromě věcného pohledu významný pohled členění celků (modulů, balíků) aplikačního software, který je pro pokrytí věcných oblastí použit.

Pro členění aplikačních služeb jsou podstatná naprosto stejná hlediska, a tedy architektura služeb může vypadat shodně s architekturou globální. Změna však nastává v primárním náhledu na tuto architekturu, kdy nás kromě „stavby“ informačního sytému zajímá pohled poskytování produktů informatiky zákazníkům. Dále se podívejme, jaké nové možnosti nám změna pohledu může přinést.

 

Pro řízení informatiky v modelu „CIO jako IT broker“ jsme výše uvedli určité předpoklady a principy. Na jejich základě můžeme nyní specifikovat vlastnosti architektury služeb informatiky a vlastnosti jejích stavebních prvků – služeb:

·          Informatická služba je produktem informatického procesu. Proto služby, které budou architekturu tvořit, budou adekvátní produktivním procesům v informatice.

·          Služby jsou poskytovány zákazníkům, každá služba v architektuře bude mít své zákazníky.

·          Služby jsou poskytovány na základě přání zákazníků. Účelnost každé služby a její přínos pro podnik bude tedy možné měřit podle míry splnění takového přání.

·          Služby jsou sjednány a poskytovány zákazníkovi v kvalitativních a kvantitativních parametrech, jejichž plnění opět může být mírou efektu pro zákazníka.

·          Služby jsou poskytovány za určitou cenu a tedy každá služba v architektuře bude cenově (nákladově) specifikována.

 

Z těchto vlastností je vidět, že vyjdeme-li z  architektury služeb, budeme moci celostně nahlédnout na:

·          služby – výstupy informatiky,

·          procesy, které výstupy informatiky zajišťují,

·          zákazníky podnikové informatiky,

·          přání a potřeby vnitropodnikových zákazníků informatiky,

·          parametry služeb – objem a kvalitu poskytovaných služeb,

·          cenu informatiky = náklady podniku na informatiku.

 

Přestože to zní velmi komplexně, nedělejme si nároky na univerzalismus. Tento pohled bude samozřejmě pouze jedním z mnoha možných.

 

Takto postavená architektura služeb je tedy dalším doplňujícím pohledem na informatiku podniku, který ji může pomoci komplexně řídit z nového pohledu.

5.2    Členění služeb informatiky

Dále se podívejme podrobněji na stavební kameny architektury služeb, tedy na služby informatiky.

 

Co vůbec máme rozumět službou informatiky. Služba informatiky je výstup oblasti informatiky v podniku, který splní přání zákazníků podnikové informatiky. Služby jsou výsledkem procesů, které probíhají v oblasti informatiky. Určení procesů, které služby zajistí, je však logicky až sekundární. Nejprve existuje potřeba služby, až poté je nutné hledat způsob jejího zabezpečení.

 

Jak jsme uvedli v kapitole Distribuce řízení na procesy, způsob, jakým bude služba zajištěna (tedy průběh informatického procesu), je jiný pohled než pohled řízení podnikové informatiky. Z hlediska ředitele informatiky je důležité pouze jaká služba a v jakých parametrech bude poskytována, a kdo tuto službu zajistí. Zabývat se tím, jakým způsobem bude služba zajištěna, je příliš operativní pohled a v zájmu ředitele informatiky je se touto úrovní rozhodování nezabývat, ale delegovat ji takovým způsobem, aby mohl operativně a snadno rozhodovat o tom, zda zajistí služby interně nebo zda je nakoupí.

 

Službu informatiky jsme definovali velmi obecně. Na základě této specifikace (a popisu procesního řízení a formulace přání na informatiku) lze služby informatiky definovat v podniku mnoha různými způsoby, a také patrně budou v každém podniku jiné. Zde se pokusíme definovat obecně základní principy specifikace služeb informatiky, a to tak, aby co nejlépe splnily následující podmínky. Splnění těchto podmínek může významně přispět k zpřehlednění kompetencí v podniku a jak uvidíme dále, je velmi obtížné je účinně podpořit jinak než vhodnou definicí služeb informatiky. Jsou to:

·          určení předmětu a parametrů služby výstižně tak, aby bylo možné určit vazbu poskytování služby na plnění přání,

·          účinné přenesení odpovědnosti za výsledek na proces, který službu zajišťuje (příp. na poskytovatele),

·          oproštění zákazníka od nutnosti znát technologické parametry informatiky, aby mohl službu účinně kontrolovat,

·          ponechání odpovědnosti za rozhodování o věcných otázkách podporovaného procesu na zákazníkovi služby,

·          autonomie služeb a možnost autonomie procesů, které je zajistí,

·          možnost zajištění optimální integrace informačního systému (a to datové, funkční, integrace uživatelského rozhraní, ale zejména integrace technologické a hardwarové, jejichž zajištění je z důvodu rostoucí komplexity stále složitější) a možnost zajištění bezpečnosti informačního systému,

·          možnost určení ceny služby tak, aby korespondovala s parametry, které jsou významné pro zákazníka, ale zároveň tak, aby odpovídala nákladům poskytovatele na zajištění služby.

 

Dodavatelé, kteří poskytují služby na trhu a kteří vzájemně soupeří o zákazníka, mají přirozenou tendenci uvedené podmínky splňovat. Proto mohou být při specifikaci služeb informatiky podniku vodítkem právě služby, které jsou nabízeny tržně. V zájmu podniku je ovšem kompetence v oblasti informatiky zprůhlednit i v případě, že o outsourcingu informatiky uvažovat nehodlá. Proto je zde popisovaný model použitelný i v takovém případě. Na druhou stranu podniky, které se rozhodují pro outsourcing informatiky z důvodu nedostatečné kontroly nad touto oblastí, mohou zavedením zde uváděných principů získat vhodné podklady pro rozhodování o outsourcingu, tedy pro to, zda vůbec outsourcovat, zajištění kterých služeb outsourcovat a jaké parametry po poskytovateli požadovat.

 

Podívejme se na služby informatiky z hlediska zákazníka a z hlediska uživatele. Pokud nám zůstanou na zřeteli principy specifikace přání na informatiku, vidíme, že služba musí nějakým způsobem zajistit splnění potřeby zákazníka, která se týká jeho věcné oblasti (procesu nebo podniku), je formulována v jazyce věcné oblasti zákazníka a je kvantifikovatelná v parametrech věcné oblasti zákazníka.

 

Je-li zákazníkem ekonom, je přání formulováno ekonomicky a měřítkem jeho splnění jsou nějaké ekonomické parametry. Je-li zákazníkem informatiky vrcholový vedoucí, je přání formulováno manažersky a měřítkem jeho plnění je parametr řízení nebo výsledků podniku. Je-li zákazníkem logistik, je přání definováno v jazyce logistiky a parametrem plnění přání je nějaký logistický parametr. (Zabýváme se podnikem, jehož hlavní činností není informatika.)

 

Informatické služby by měly korespondovat s takovými typy přání.

Podíváme-li se na oblast informatiky z aplikačního hlediska (z hlediska aplikační funkcionality), vidíme, že typy aplikací obvykle tento věcný pohled splňují. Potřeby ekonoma plní ekonomická aplikace, potřeby manažera plní manažerský systém, potřeby logistika plní logistická aplikace. Mít osobní počítač na stole není věcnou potřebou zákazníka, ale již formou jejího plnění. Při specifikaci služeb pro zákazníky tedy vyjdeme z aplikačního hlediska.

 

Z uvedeného je opět patrné, že architektura služeb je shodná s architekturou globální (podle MDIS) a rozdíl je pouze ve smyslu a použití toho, co architektura zobrazuje.

 

Potřeby zákazníka obvykle budou plněny prostřednictvím funkcí aplikačních programů. Aby však potřeba zákazníka byla splněna a uživatelé mohli funkcionalitu aplikace využívat, je nutné, aby k této funkcionalitě měli přístup, a tedy aby byly zajištěny uživatelské terminály (počítače), u kterých uživatelé aplikaci využijí, aby byl zajištěn běh serverové části aplikace někde na počítači – serveru, aby data ze serveru byla dopravena k počítači uživatele, atd. Zajištění těchto aspektů je věcí podnikové informatiky. Ovšem o žádnou z těchto věcí se zákazník informatiky nemusí zajímat, protože se netýká jeho věcné oblasti. Zákazníkovi je splněno přání poskytnutím aplikace, a jakým způsobem se aplikace dostane k uživateli, zákazník neřeší, ale nechá na odpovědnosti informatiky.

 

Služby pro zákazníky informatiky tedy můžeme dělit podle aplikačních oblastí. Takové dělení je ale nedostatečné. Vysvětleme problém na příkladě: Pokud by například uživatel užíval dvě aplikační služby a za poskytnutí každé z těchto služeb odpovídal jiný poskytovatel (autonomní proces), mohlo by se stát, že by uživatel měl k dispozici na svém pracovišti dva terminály a ke každému z nich by vedl jiný kabel sítě LAN. Je asi evidentní, že taková situace není optimální a skýtá možnosti úspor v technologické integraci. (Uvedená situace se může zdát absurdní, ale přesto se v několika podnicích stala. Pokud ale odhlédneme od počítačových aplikací, uvidíme, že obdobný případ lze vidět téměř v každé kanceláři, kde jsou oddělená zařízení - terminály telefon a počítač, a ke každému z nich je veden v budově jiný kabel –  telefonní rozvod a kabelový rozvod sítě LAN.)

 

Pokud chceme tuto neefektivitu odstranit, musíme nějak zajistit, aby subjekty odpovědné za aplikační služby (autonomní informatické procesy nebo poskytovatelé) spolu využili společnou infrastrukturu, v našem případě síť LAN a koncové uživatelské pracoviště, patrně osobní počítač PC. Chceme ovšem zároveň, aby poskytovatelé aplikačních služeb mohli být za jejich výsledek odpovědni zákazníkovi, ale zároveň, aby zákazník nebyl nucen starat se o technologii a například zajišťovat požadavky těchto poskytovatelů na průchodnost sítě LAN nebo kapacitu a konfiguraci osobního počítače.

 

Vhodným řešením je

·          zavedení dalších informatických služeb, které využijí poskytovatelé aplikačních služeb, aby své aplikační služby poskytli zákazníkovi. Autonomní informatické procesy nebo poskytovatelé aplikačních služeb by pak byli zákazníky těchto dalších služeb – těmto službám říkejme služby zdrojů nebo infrastrukturní služby.

·          zavedení dalších služeb, které si bude muset zákazník pro uživatele pořídit. aby mu mohla být poskytnuta služba aplikační. Tyto služby budou pouze podmínkou pro poskytnutí jiné služby a samostatné zákazníkovi nepřinesou žádný užitek – takové služby můžeme nazvat uživatelské infrastrukturní služby.

 

Oba tyto způsoby jsou použitelné, a to v závislosti na obsahu a technologii služeb. Vesměs se bude jednat o služby informačně technologické infrastruktury. Podstatným zjištěním tedy je, že pro specifikaci dalších služeb je důležité technologické hledisko.

 

To znamená, že členění služeb, jaké zde uvedeme, je poplatné současné technologické úrovni v informatice a není tedy obecně platné. Je možné a pravděpodobné, že se s časem bude měnit bez ohledu na potřeby zákazníků informatiky.

 

Zatím tedy můžeme pro stavbu architektury služeb použít hledisko aplikační a hledisko technologické, přičemž při technologické specifikaci potřeb procesů zajišťujících aplikační služby je vhodné zachovat principy zvolené pro specifikaci potřeb neinformatických procesů, a tím vhodně rozdělit kompetence mezi jednotlivé podmiňující se informatické služby.

 

Dalším pohledem, který do architektury zahrneme, je pohled operativního centrálního řízení služeb, který ozřejmíme dále.

 

Podle těchto principů rozdělíme služby informatiky na

·          aplikační služby – služby, které jsou poskytovány zákazníkovi, aby splnily jeho potřeby,

·          infrastrukturní služby – služby, které jsou poskytovány proto, aby bylo možné plnit služby aplikační,

·          řídící služby – služby, které mají za úkol zajistit kooperaci aktivit v informatice.

 

Jiné hledisko dělení služeb je

·          služby uživatelské – ty, které jsou poskytovány uživatelům – pracovníkům podniku,

·          služby neuživatelské, které nemají uživatele.

 

Výše v úvahách o procesním uspořádání podniku jsme specifikovali rozdíl mezi zákazníkem služby a uživatelem. Zákazník je ten, který má potřeby a rozhoduje o využití služeb a o jejich přínosech pro jeho oblast v podniku, zatímco uživatel je ten, kdo služby skutečně užívá. Někdy je zákazník uživatelem, někdy to tak být nemusí.

Služby aplikační (tedy zákaznické) jsou ve většině případů uživatelské, a služby infrastrukturní jsou obvykle neuživatelské. Existují ovšem výjimky (viz dále).

5.3    Aplikační služby

Aplikační služby lze dále v podnikovém informačním systému dělit podle věcných okruhů aplikační funkcionality, a to nejlépe tak, aby tyto okruhy odpovídaly potřebám vnitřních zákazníků, tak jak vzejdou z procesu řízení změn, a to jak z krátkodobého, tak z dlouhodobého hlediska. Operabilita změn služeb by pak měla odpovídat požadované operabilitě podniku, tedy členění služeb by mělo být provedeno tak, aby jednotlivé služby bylo možné změnit nebo nahradit v takovém časovém výhledu, v jakém podnik počítá se změnami (reorganizací) v dané věcné oblasti. Je tedy nutné zvážit časové hledisko potřeb zákazníků.

 

Jakým způsobem budou aplikační služby děleny, závisí na podniku a na aktivitách (procesech), které potřebují informatickou podporu. Zde uvedeme příklad, jak takové členění může vypadat například u výrobního podniku:

 

Aplikační (zákaznické) služby:

·          IS pro vývoj výrobků

·          IS pro řízení výroby

·          Ekonomický IS

-          Finanční IS

-          IS pro kontroling

·          IS pro marketing a prodej

-          Průzkumy a modely trhu

-          Prodej, zákazníci a smlouvy

-          Tiskové zprávy, publikace, firemní web

·          Administrativní IS

-          Kancelářský IS (Textový editor, tabulkový kalkulátor,…)

-          Elektronická pošta

-          Hlasové a faxové služby

·          Manažerský IS

·          Personální IS

-          Personalistika

-          Mzdy

·          Externí informační zdroje

-          Právní informace

-          Internet (WWW, ftp)

 

Vidíme, že jsme zvolili hledisko aplikační, ale s ohledem na současnou technologii zajištění. Služby nejsou hierarchizovány podle úrovní řízení podniku, jak je tomu například v globální architektuře, ale jednotlivé funkční oblasti jsou si rovny. Konkrétní služba může být dále dělena podrobněji na další služby. Do jaké úrovně budou služby děleny, závisí na tom, jakým způsobem se podniková informatika hodlá postavit k řízení těchto služeb, ovšem s ohledem na potřeby zákazníků a jejich vývoj.

 

V našem uvedeném členění aplikačních služeb například není dále členěna služba „IS pro řízení výroby“. To může například být proto, že:

·          službu je na této úrovni možné vhodně specifikovat předmětem, parametry a cenou (věcné hledisko),

·          služba je dnes uspokojivě celkově zajištěna jedním modulem aplikačního balíku (technologické hledisko),

·          službu není smysluplné zajišťovat zároveň více dodavateli, její funkcionalita je provázaná v rámci této aplikační oblasti a s průběhem procesu výroby natolik, že zajistit jednotlivé části této služby různými dodavateli není smysluplné (hledisko IT brokera, kde se mísí věcný i informačně technologický pohled).

 

Dále například služba „Ekonomický IS“ je rozdělena do dvou dílčích služeb „Finanční IS“ a „IS pro kontroling“. To může mít opět více důvodů, pro příklad uveďme situaci:

·          předmět a parametry každé dílčí služby lze specifikovat samostatně, v podniku jsou různí zákazníci a uživatelé pro dílčí služby (věcný pohled),

·          služba je sice zajištěna jedním aplikačním softwarovým balíkem, ale různými moduly s dobře specifikovaným rozhraním, a lze se tedy rozhodovat o způsobu zajištění na úrovni dílčích služeb – lze přenést odpovědnost za zajištění služeb na nižší úrovni (hledisko IT brokera).

 

Jako primární hledisko členění aplikačních informatických služeb je zvoleno hledisko věcné, tedy hledisko potřeby zákazníka. Toto hledisko může znamenat sloučení více aplikací nebo služeb totálně technologicky odlišných do jedné služby. To je ovšem smysluplné, protože potřeba zákazníka bude splněna souhrnem nebo kombinací těchto technologicky odlišných služeb. Ozřejměme to na příkladě služeb „IS pro marketing a prodej“ a „Administrativní IS“.

 

Služba „IS pro marketing a prodej“ byla zavedena proto, aby byl vhodně podpořen proces marketingu a prodeje v podniku, a to v určitých konkrétních měřitelných parametrech této věcné oblasti. Podle takto formulovaných potřeb byly specifikovány předměty a parametry tří služeb, jejichž poskytování má nejvhodnější vazbu na potřeby zákazníka: Služba „Průzkumy a modely trhu“ podpoří parametry procesu, který zkoumá chování trhu, služba „Prodej, zákazníci a smlouvy“ podpoří prodej a vztahy s konkrétními zákazníky (ovšem opět konkrétní určené parametry těchto činností/procesů) a služba „Tiskové zprávy, publikace, firemní web“ podpoří zveřejňování zejména propagačních informací o podniku. Každá z těchto služeb bude technologicky zcela odlišně realizována („Průzkumy a modely trhu“ např. desktop aplikací, „Prodej, zákazníci a smlouvy“ distribuovanou aplikací  a „Tiskové zprávy, publikace, firemní web“ například internetovou aplikací), ale z věcného hlediska jsou součástí služby „IS pro marketing a prodej“, orientované na konkrétního jednoho zákazníka v podniku (např. reprezentovaného obchodním ředitelem) a plnící potřeby, jejichž základem je přání zvýšení jednoho kvantitativního parametru – obratu.

 

Služba „Administrativní IS“ je naproti tomu služba zaměřená na správu podniku. Je rozdělena na služby „Kancelářský IS“, „Elektronická pošta“ a „Hlasové služby“. „Kancelářský IS“ zahrnuje služby psaní a tištění papírových dokumentů, drobných výpočtů uživatele a podobné funkce, které poskytuje kancelářský software. „Elektronická pošta“ zahrnuje možnosti příjmu a odesílání zpráv a dokumentů uvnitř podniku nebo s okolím, a „Hlasové služby“ umožňují jejich uživatelům telefonovat z pevných nebo mobilních telefonů, a to opět vnitropodnikově nebo i mimo podnik. Použití telefonů a elektronické pošty je technologicky zajištěno zcela odlišně. Přesto jsou obě tyto služby součástí jedné služby „Administrativní IS“, protože u obou se jedná o věcně shodné služby komunikace s lidmi uvnitř podniku nebo mimo podnik, jen jinou formou, a zde byly tyto činnosti zařazeny do oblasti administrativy. Navíc, technologické zajištění elektronické pošty může být technologicky velmi blízké například službě „Internet“, která je ovšem součástí služby „Externí informační zdroje“. Pokud je možné tyto služby poskytovat tak, že je možné oddělit odpovědnost za ně (za zajištění služeb v předmětu a parametrech), pak je vhodné preferovat věcné podnikové hledisko před technologickým.

 

Shrňme tedy požadavky na členění aplikačních služeb: Tyto služby je vhodné členit tak, aby v návaznosti na řízení požadavků a změn co nejvhodněji korespondovaly se smysluplnými přáními a potřebami vnitřních zákazníků, tedy aby byly uspořádány primárně z věcného pohledu zákazníků, ale zároveň je nutné vzít v úvahu možnosti technologického zabezpečení takto členěných služeb, aby bylo možné je zajistit operativně v časovém horizontu a s oddělenými odpovědnostmi za výsledek.

5.4    Předmět aplikačních služeb

Architekturu služeb informatiky tedy máme vymezenou a základní principy určení členění služeb také. Dále je ale nutné argumentovat a ozřejmit, jakým způsobem řídit služby informatiky konkrétněji.

 

Přímého řízení způsobu zajištění služby jsme se vzdali a distribucí řízení jsme ji ponechali na poskytovateli nebo autonomním procesu, který ji zajišťuje. Služby je tedy nutné řídit jiným způsobem, a to požadavky na ně a na jejich parametry.

 

V této části popíšeme principy specifikace předmětu služeb informatiky, aby tato specifikace odpovídala principům, které jsme uvedli výše, zejména:

·          aby bylo možné distribuovat řízení na procesy a tím přenést odpovědnost za službu, a to proto, aby bylo snadné operativně službu outsourcovat,

·          aby poskytování služeb mohlo mít vazbu na plnění věcných přání zákazníků informatických služeb a jeho plnění bylo měřitelné.

Podrobněji jsou tyto principy popsány v předchozím textu.

 

Služby informatiky je obvyklé specifikovat v tzv. Service Level Agreements (SLA). V těchto dokumentech je specifikován:

·          předmět služby,

·          významné objemové a kvalitativní parametry služby,

·          způsob měření a předávání ukazatelů těchto parametrů,

·          cena služby, nejlépe závislá na některých těchto ukazatelích – metrikách.

 

My se podíváme na principy specifikace všech těchto údajů.

 

Výše jsme vymezili, že se budeme k řízení interních autonomních procesů chovat obdobně jako k externím poskytovatelům. Toto pravidlo se týká zejména specifikace služeb. Proto popis předmětu a parametrů služeb bude mít shodné principy i v případě interního zajištění i v případě externího poskytovatele. Dále tedy nazývejme poskytovatelem i interní autonomní procesy, které služby zajišťují, i externí poskytovatele. Jednotná specifikace služeb pro oba případy umožní zvýšit operativitu rozhodování o outsourcingu tím, že interní dohody SLA budou při rozhodnutí službu zajistit externě podkladem pro rychlé sestavení smluvního vztahu s dodavatelem, a naopak při převádění dodavatelského zajištění dovnitř do podniku budou smlouvy s dodavatelem podkladem pro rychlou specifikaci interních ekonomických vztahů.

 

Nejprve popišme obecně, jakým způsobem pohlížet na komplex služeb z architektury služeb.

 

Předmět služby lze specifikovat mnoha různými způsoby. Základním velmi silným nástrojem, ale často a zvláště v informatice také problémem, je následující vlastnost specifikace předmětu služby:

Za to, co je specifikováno v předmětu služby, odpovídá zákazník.

Za to, jakým způsobem toho bude dosaženo, odpovídá poskytovatel služby.

 

Tato skutečnost je velmi prostá, přesto ji vysvětleme podrobněji. Specifikací předmětu služby se zákazník a poskytovatel shodnou na tom, co bude poskytovatel poskytovat a zákazník přijímat. Zároveň tím obě strany prezentují, že jsou schopny tento předmět poskytovat a přijímat. Produktivní, konající stranou je poskytovatel, pasivní, přijímající stranou je zákazník. Specifikace předmětu služby je tedy zadáním (zakázkou či objednávkou) zákazníka na plnění poskytovatele. Zákazník specifikuje, jaké plnění chce přijímat, a poskytovatel specifikuje, co je ochoten a schopen konat. Na odpovědnosti zákazníka tedy je určit „co“ má být poskytováno, a dojde-li ke shodě, odpovědností poskytovatele je „že“ to bude poskytováno a „jak“. Zákazník by tedy měl své úsilí zaměřit na specifikaci předmětu služby jako toho, co skutečně potřebuje, a způsob plnění, není-li pro zákazníka podstatný může nechat na odpovědnosti poskytovatele.

 

Tento princip je důvodem, proč je nutné, aby zákazník specifikoval své přání ve věcné oblasti, kterou řídí a ve které se dobře orientuje, a v jazyce, který ovládá. Pokud by totiž zákazník přistoupil na specifikaci služby tak, že jí dostatečně nerozumí nebo nedokáže správně odhadnout dopady plnění takové služby, znamená to, že přebírá odpovědnost za přijetí plnění, o němž neví, zda mu k něčemu bude. Taková situace nahrává vzniku různých nedorozumění a v mnoha případech také umožní vznik situací, kdy poskytovatel sice skutečně plní to, k čemu se zavázal, ale v důsledku nekompetentnosti jeho pracovníků nedojde k očekávanému kladnému efektu, nebo dokonce kdy poskytovatel oklame zákazníka tím, že si je již od začátku vědom zbytečnosti pro zákazníka.

Tím má poskytovatel odpovědnostní výhodu.

 

Přestože smluvní vztah by měl být oboustranně výhodný, z hlediska podniku se nám jedná o co nejlepší zajištění produktů podniku, a proto musíme preferovat hledisko zákazníka informatiky, a to i vůči internímu zajištění informatiky a z hlediska informatiky podniku. Dnes obvyklou technologickou specifikaci dodávek informatických produktů tedy musíme považovat za nevhodnou, a dále rozvineme principy specifikace předmětu služeb informatiky tak, aby mohly měřitelně navazovat na skutečné potřeby zákazníků.

Vhodnou specifikací předmětu služby zbavíme zákazníka nutnosti orientovat se v informatice, což z druhé strany znamená, že bude nutné, aby se poskytovatel lépe orientoval v oblasti zákazníka. Odpovědnost za zajištění služeb tedy bude (ve větší míře než je obvyklé[29]) přenesena na poskytovatele. A nad tím, aby tomu tak skutečně bylo, a zákazník věděl, že skutečně nemusí sjednávat předmět služeb v jemu nesrozumitelných termínech, by mělo bdít centrální řízení informatiky podniku.

 

Naším principem bude, aby zákazník odpovídal jen za to, co může ovlivnit a co se týká jeho věcné oblasti.

 

Je tedy zřejmé, že z hlediska zákazníka je nevhodné sjednávat s poskytovatelem poskytnutí konkrétního aplikačního software, který poběží na konkrétní databázi a na konkrétním hardware. Ale stačí specifikovat potřebnou aplikační funkcionalitu a její parametry, které povedou například ke zvýšení určitého parametru zákazníkova procesu. Zajištění poskytnutí této aplikační funkcionality pak lze nechat na odpovědnosti poskytovatele. Poskytovatel tedy pak vybere odpovídající aplikační software, vhodný systém řízení databáze a vhodný hardware.

 

Výhodu tohoto přístupu můžeme ještě více ozřejmit klasickým příkladem: Zákazník postupem času zjistí, že jeho věcné požadavky na služby informačního systému zůstaly nezměněny, ale například výkon počítače, na kterém běží aplikační software, přestal být dostatečný pro zajištění parametrů služby (například doby odezvy). Pak:

a, v případě, že předmět služby specifikoval jako software X, databáze Y a počítač Z, může dodavatel argumentovat: chtěli jste počítač Z, máte jej, pokud jej chcete vylepšit, musíte připlatit;

b, v případě, že předmět služby byl definován jako aplikační funkcionalita v určitých parametrech, pak zákazník může argumentovat: žádné sjednané parametry se nezměnily, takže nás nezajímá výkon počítače, zajímá nás, že sjednaný kvalitativní parametr služby (doba odezvy) není dodržen, a uvedení na pravou míru bude na účet poskytovatele.

 

Situace uvedená v příkladu je sice jednoznačná, ve skutečnosti ale může nastat mnoho případů mezi dvěma uvedenými extrémy, podle toho jaká odpovědnost a v jaké míře je přenesena na poskytovatele.

 

Odpovědnost, která je přenášena na poskytovatele, můžeme rozdělit na

·          odpovědnost za konečný výsledek služby,

·          odpovědnost za průběh procesu poskytnutí služby – za způsob, jakým je dosaženo výsledku,

·          odpovědnost za zdroje (vstupní prostředky) služby.

 

Již víme, že z hlediska zákazníka je vhodné specifikovat předmět z pohledu potřeb na podporu, tento pohled na přenesení odpovědnosti za výsledek rozvineme v kapitole Návaznost potřeby a předmětu služby. Odpovědnost za způsob poskytnutí služby a za její zdroje je tedy vhodné ponechat na poskytovateli v co největší míře. V části Předmět služby a vývoj informačního systému uvedeme souvislost pohledu služeb a pohledu životního cyklu informačního systému. V kapitole Předmět služby a způsob dosažení výsledku se podíváme na to, jakým způsobem se tento faktor může promítnout do specifikace předmětu služby.

5.4.1   Návaznost potřeby a předmětu služby

Předmět aplikačních služeb je z hlediska možnosti zajištění služby nejvhodnější specifikovat primárně aplikační funkcionalitou informačního systému, kterou budou uživatelé užívat. To je pohled možnosti zajištění služby.

 

Aplikační funkcionalita je vhodným pojítkem mezi světem věcné podporované oblasti a světem informatiky.

Produktem informatiky totiž není jen sama informace dodaná v čase na určité místo. Aplikační funkcionalita v sobě zahrnuje více:

·          typ informace, která je produktem informačního systému,

·          způsob zpracování a distribuce informace,

·          podstatné parametry informace (dostupnost),

·          požadavky na vstupy informací (od uživatelů nebo jiných IS) a možnosti výstupů.

Proto aplikační funkcionalita vhodně reprezentuje propojení věcné oblasti s informatikou.

Dalším důvodem je, že zajistit službu je nutné z hlediska informatiky a informatickými jazyky, zatímco z hlediska podporované oblasti funkcionalita koresponduje s problematikou dané oblasti a je užívána i uživatelsky popsána v jazyce věcné oblasti – uživatele (není to tak u všech aplikací, ale u dobrých ano).

Přesto aplikační funkcionalita nemusí být žádoucím pohledem zákazníka, a to z toho důvodu, že nepopisuje přímo možnosti a způsoby dosažení splnění věcné potřeby (tedy například snížení nároků procesu na zdroje, zvýšení rychlosti průběhu procesu, zvýšení operability při hledání podnikatelských příležitostí, snížení nákladů atd.).

Je zřejmé, že zavedením aplikační funkcionality ještě není přání zákazníka splněno. Předmětem služby by tedy neměla být pouze aplikační funkcionalita, ale i způsob, jakým se její užití promítne nebo může promítnout do splnění přání zákazníka.

 

Způsobem promítnutí aplikační funkcionality do přání zákazníka je míněno:

·          podmínky a příčiny splnění potřeby,

·          uživatelská dokumentace a školení.

 

Podmínky splnění potřeby jsme již zmínili v kapitole o Řízení požadavků a změn v informatice. Jejich účelem je popsat významné faktory, které jsou příčinou splnění přání zákazníka. Těchto faktorů může být více a mohou se vzájemně podmiňovat. V podstatě se jedná o

·          nalezení cesty, kterou je nutné projít od zavedení aplikační funkcionality ke splnění přání zákazníka, aby bylo možné konkrétně prokázat vliv informatické služby na jeho splnění,

·          nalezení významných rizik a překážek, které se na té cestě mohou objevit, a to zejména těch, jejichž vliv nelze působením informatické služby ovlivnit. Je to proto, aby bylo možné ospravedlnit nesplnění přání i v případě bezchybnosti plnění parametrů informačního systému. Touto překážkou může být vedle neovlivnitelných faktorů také například konkrétně specifikované spolupůsobení zákazníka;

·          a z druhé strany nalezení jiných cest, kterými lze přání zákazníka splnit, a upozornění na ně, aby bylo možné prokázat jinou příčinu splnění přání než je informatická služba, pokud je sice splnění přání dosaženo, ale informační systém nepracuje správně.

 

Návaznost aplikační funkcionality a potřeby zákazníka není nutné pouze popsat, ale je nutné ji také aktivně podpořit, a zaváže-li se poskytovatel k plnění přání, je tato podpora součástí jeho závazku – služby a je také v jeho zájmu. Vzhledem k tomu, že je k takové podpoře nutné konání uživatelů informačního systému, je jedním z důležitých nástrojů této podpory uživatelská dokumentace a školení a výcvik uživatelů.

Uživatelská dokumentace a školení je běžnou a nutnou součástí informačního systému. Jejím účelem však je mnohdy pouze návod, jak funkce systému užívat. To ovšem nestačí. Informační systém není zaváděn proto, aby byl užíván jen tak, ale proto, aby byl užíván tak, aby bylo splněno přání zákazníka. Uživatelská dokumentace a školení by tedy měly zahrnovat tuto účelovost, tedy měly by být zaměřeny na to, aby se uživatelé naučili funkcionalitu využívat tak, aby bylo dosaženo požadovaného efektu v jejich věcné oblasti (procesu), a tedy aby došlo ke splnění přání zákazníka informatiky. Pokud je ovšem předmět služby definován pouze aplikační funkcionalitou, poskytovatel služby (a patrně zároveň dodavatel dokumentace a školení) nemá zájem na tom, aby uživatelé užívali informační systém skutečně tak, aby k požadovanému efektu došlo.

 

Je nutné, aby všechny tyto vlivy byly co nejvíce konkrétní a průkazné, a tedy měřitelné, někdy i kvantifikovatelné nebo přímo kvantitativní.

 

Součástí popisu předmětu aplikační služby by tedy mělo být:

·          potřeba (požadovaný efekt),

·          aplikační funkcionalita,

·          logická spojitost mezi užitím funkcionality a splněním potřeby (efektem).

 

Potřeb, které jsou plněny užitím aplikační funkcionality, může být u rozsáhlých projektů informačních systémů více, a stejně tak jeden informační systém (nebo jeho část) má rozsáhlou aplikační funkcionalitu. Proto jejich specifikace i kauzální provázání nemusí být jednoduché.

 

Náklady, které podporovaný proces vynaloží na službu, by měly odpovídat potřebnému efektu. Ani v tomto modelu netvoří náklady procesů na služby informatiky pouze cena těchto služeb. Je nutné dále vzít v úvahu zejména náklady na spolupůsobení pracovníků procesu při změně (vývoji informačního systému), náklady na vyšší nutnou kvalifikaci pracovníků, nutné náklady na udržování nevyužitých zdrojů službami ušetřených atd.

 

Dále je služba definována objemovými a kvalitativními parametry. Zde je zmiňujeme jako další bod vedle předmětu smlouvy, ale z právně smluvního pohledu je popis těchto parametrů samozřejmě součástí specifikace předmětu smlouvy. Na tyto parametry se podíváme v kapitole Měření služeb IS a jejich efektů.

 

Problematiku předmětu služby zatím můžeme shrnout: Zákazníkovi jde o splnění jeho věcného přání, ale to poskytovatel nemůže zajistit. Poskytovatel může pouze poskytnout funkcionalitu informačního systému, která zákazníkovi pomůže jeho přání splnit, ale sama aplikační funkcionalita není pro podnik dostatečným plněním. Poskytovatel by tedy měl odpovídat za to, že prostřednictvím dodané aplikační funkcionality bude možné přání splnit, a mělo by být zřejmé jak.[30]

5.4.2   Předmět služby a vývoj informačního systému

V kapitole Řízení požadavků a změn v informatice jsme popsali principy specifikace potřeb (procesů, podniku) na informatickou podporu. Máme tedy nějakým způsobem formulované přání. Zde se podívejme, jakým způsobem lze dojít ke specifikaci předmětu služby tak, aby její poskytování bylo zároveň plněním přání zákazníka.

Výše jsme specifikovali, že řízením změn v informatice dojdeme k tomu, zda přání zákazníka lze splnit

a)       již poskytovanou službou (ve stávajících parametrech),

b)       modifikací již poskytované služby,

c)       zavedením nové služby.

 

Vzhledem k předmětu služby tyto tři možnosti mohou znamenat situace, kdy

a)       předmět služby je již specifikován a není nutné jej nijak měnit,

b)       předmět služby je již specifikován a je nutné jej modifikovat,

c)       předmět služby ještě není specifikován a je nutné to udělat.

 

Situací a se zde pochopitelně zabývat nebudeme. K případu b se vrátíme a začneme případem c:

 

Služby informatiky pro procesy jsou velmi často velmi sofistikované a nelze je nakoupit okamžitě a bez velkých nákladů na změny.

Vezměme v úvahu například jednoduchý případ, jako je poskytování obecných legislativních informací podnikovým právníkům. Zdá se, že je možné pouze nakoupit potřebný právní software nebo objednat právní služby poskytované na Internetu. Zároveň je ale nutné zjistit, kolik uživatelů bude tyto služby využívat a jací to jsou, zda mají nějaké speciální požadavky například na přístup k judikátům a výkladům norem, zajistit, aby tito uživatelé měli přístup ke koncové stanici PC, k síti LAN, případně k Internetu, a to v takových parametrech, které využití právních informací rozumně dovolí. Dále je nutné prověřit, zda už obdobnými informacemi někdo v podniku nedisponuje, a pokud ne, zajistit, aby v budoucnu, bude-li je někdo potřebovat, je nezískal jinak než nově zaváděnou službou. Dále je nutné zajistit souvislosti a integraci s jinými službami. Například bude vhodné, když budou mít právníci možnost přistoupit k právním informacím současně s prohlížením smluv podniku se zákazníky, ale zároveň aby si tyto dokumenty nemohl prohlédnout nikdo, kdo k nim nemá mít přístup. Dále je potřeba určit, jaké budou náklady na poskytnutí této služby, aby bylo možné určit její cenu. Do nákladů je nutné započítat nejen náklady na pořízení, ale dále náklady na podporu a školení jejich uživatelů a další. Dále je nutné posoudit, jakým způsobem získávají právníci potřebné informace dosud a v případě budoucího poskytování právních služeb informatikou tyto staré kanály zrušit. Vhodné je také zvážit, co v práci (v činnostech) právníků se změní, budou-li mít novou službu k dispozici.

To byl příklad několika aspektů. Mnohem složitější je pak situace v případě víceuživatelských systémů se složitými toky dokumentů a sdílením informací.

Důležité je v takto komplexním problému na nic nezapomenout, a aby skutečně nebylo na nic zapomenuto, používají se metodiky vývoje informačních systémů.

 

Vznik nové služby a specifikaci jejího předmětu tedy chápejme jako vývojovou aktivitu v informatice, kterou je nutno sofistikovaně jako vývoj řídit. Touto problematikou se podrobně zabývá například [Voříšek] nebo [Řepa]. Zde uvedeme pouze aspekty vývoje podstatné pro naši problematiku.

 

Je-li výstupem procesu řízení změn v informatice požadavek na zavedení nové služby, znamená to obvykle (podle metodiky vývoje) nutnost zavedení nového informačního systému nebo jeho části, a to obvykle prostřednictvím nového vývojového projektu.

 

obr. 10,  Přání na informatiku a vývoj IS

 

Přání zákazníka je nutné zpodrobnit a upřesnit, a to tak, aby v případě aplikační služby byl výsledkem požadavek na aplikační funkcionalitu informačního systému. Vedle přání tedy bude zadáním projektu i popis požadované aplikační funkcionality a dále i logické podmínky vztahu funkcionality a potřeby. Vzhledem ke složitosti tvorby informačního systému je nutné toto zpodrobňování a upřesňování provádět i během vývojových prací v několika fázích analýzy a návrhu. Přání zákazníka, které je výstupem změnového řízení informatiky a zadáním pro nový projekt, patrně bude relativně stabilní. Nelze ale vyloučit, že se bude v průběhu projektu upravovat podle postupně poznávaných možností tvořeného informačního systému. Aplikační funkcionalita a předpokládaný způsob jejího využití se také bude postupně zpřesňovat.

Přestože je možné, že se představy a potřeby během projektu změní, je vhodné neustále zachovávat a udržovat ve znalosti původní potřeby a představu o jejím plnění, aby výsledek vývoje byl použitelný pro původní účel. Pokud se v průběhu projektu najdou další potenciální přínosy, je možné je specifikovat i měřit, ovšem vedle původních, které byly důvodem k vývoji.

 

Fázemi upřesňování probíhá nejen předmět služby, ale i její cena. Během fází upřesňování by tedy mělo neustále docházet ke stále podrobnější dohodě mezi zákazníkem a poskytovatelem služby na předmětu služby a její ceně.

 

Základním pravidlem pro účinnou kontrolu ceny z hlediska zákazníka služeb je: Je nutné vědět, kolik bude stát poskytování služba před tím, než se zákazník rozhodne, zda ji bude přijímat.

Toto opět velmi triviální a přirozené pravidlo je někdy v oblasti informatiky obtížné dodržet, v zájmu zákazníka i řízení informatiky je však extrémně žádoucí na tomto pravidle důrazně trvat, a často je nutné za tuto možnost plánování budoucích nákladů patřičně zaplatit.

Uvedené pravidlo je nutné v některých případech rozšířit i o možnost ukončení poskytování služby. Ukončení poskytování služby je také změna, která má své, někdy nemalé náklady. I tyto náklady je tedy vhodné znát před rozhodnutím o využití služby.

 

Z hlediska zákazníka služeb a ostatně ani z hlediska informatiky podniku (CIO) není důležitý konkrétní průběh vývojových prací a jeho řízení. Důležité je však rozlišení minimálně těchto fází, které se mohou podle typu zvolené vývojové metodiky nacházet v různých fázích vývoje:

1.       plánování změny,

2.       změna vedoucí ze současného stavu k poskytování služby,

3.       poskytování služby.

 

Podívejme se, v čem jsou tyto fáze odlišné.

První dvě fáze by bezpochyby měly být rámcově řízeny standardní procedurou řízení změn. Patrně by se jich měli aktivně zúčastnit potenciální poskytovatelé služeb, a to jak interní, tak externí.

 

Plánování

Účelem plánování změny je rozhodnout kvalifikovaně o reálném předmětu a ceně služeb a o čase a nákladech na její zavedení. Během této fáze je nutné posoudit potřebu a požadavek na služby potenciálními poskytovateli. Dále je nutné, aby se potenciální poskytovatelé, zvláště pokud jsou externí, seznámili se standardními pravidly poskytování služeb informatiky v podniku, zejména s požadavky na kvalitu a s dalšími aspekty centrálního řízení informatiky, a dále aby ve spolupráci s kompetentními místy podnikové informatiky zjistili nutnost a možnosti technologické integrace jejich služeb do celkového informačního systému podniku. Tuto fázi lze nazvat například úvodní studie. Výsledkem této první fáze by měla být závazná nabídka potenciálních poskytovatelů v předmětu služby a ceně a v době zavádění (vývoje) a ceně za ně, a dále v požadavcích na konkrétní spolupůsobení zákazníka. Tuto fázi není možné provádět zdarma, což platí zejména z hlediska účasti externích potenciálních poskytovatelů. Náklady na tuto první fázi je tedy vhodné naúčtovat k tíži procesu (ekonomické jednotky), která ji svými potřebami vyvolala. To ovšem znamená nutnost určení její ceny a parametrů výstupů ještě před jejím zahájením, a schválení těchto údajů jednotkou, která ponese náklady. Pokud tato jednotka nesouhlasí s přičtením těchto nákladů, patrně není přání pro ni podstatné a není nutné studii provádět.

 

Změna

Na základě výsledku plánování se pak mohou osoby odpovědné za proces rozhodnout:

·          zda stále mají specifikované přání,

·          zda jim vyhovuje nabízená funkcionalita,

·          zda skutečně tato funkcionalita povede ke splnění potřeby,

·          a zda požadovaná cena je adekvátní dosažitelným efektům,

a mohou si vybrat mezi jednotlivými potenciálními poskytovateli, resp. mezi jejich nabídkami. Pokud se v této fázi dohodnou, je možné začít vývojové aktivity (projekt), již v předem známé peněžní výši a ve známém očekávaném výsledku i efektu.

Podrobněji se zde změnou zabývat nebudeme. Ale pro jeho důležitost ještě jednou reformulujeme pravidlo: Než začnou vývojové práce, je nutné předem znát a shodnout se přesně na tom, co se bude poskytovat, jaký to bude mít efekt, jaká je souvislost plnění služby a efektu a jaká bude cena za poskytované služby.

Veškerým vývojovým aktivitám v informatice zde neříkáme služby, ale říkáme jim „změna“. Sama změna totiž nepřináší zákazníkům žádný užitek, užitek přináší až výsledek změny, tedy provozování informačního systému. Vývojové služby jsou smysluplné pro informatiky, kteří později výsledek vývoje nějak poskytují dále (např. vnitřnímu zákazníkovi), nikoli ovšem pro zákazníka přímo.[31]

 

Poskytování služeb

Třetí uvedenou fází je poskytování služby, což je fáze, kdy vyvinutý systém poskytuje produktivní služby svým zákazníkům. V této fázi tedy nastává čas pro skutečné plnění potřeby či přání na informatiku a pro měření, jak dalece se to podařilo, a tedy i pro hodnocení přínosů informatické služby i poskytovatele.

 

Z hlediska zákazníka je nutné kdykoliv během vývoje i provozu informačního systému sledovat, zda přání/potřeba stále trvá, a pokud ne, je nutné zvážit, zda vývojový projekt (nebo již poskytování služby) zastavit. Pokud je účel (potřeba) služby během projektu zmařen, je nutné rozhodovat se na zelené louce, a to bez ohledu na již vložené prostředky. Často je lepší ztratit jednorázově několik miliónů za zmařený zastavený projekt, než později vydávat kontinuálně další peníze za provoz neúčelného informačního systému.

 

Fáze plánování a vývoje jsou náročné a nákladné zvláště u rozsáhlých víceuživatelských aplikací. To se týká hlavně aplikací pro řízení výroby a logistiky, ekonomických aplikací a dalších. I u těchto rozsáhlých aplikací se v brzkém budoucnu počítá s jejich operativním nákupem od poskytovatelů.[32] Jejich dnešní podoba však vyžaduje rozsáhlé přípravné akce před spuštěním jejich služeb, a to zejména parametrizaci přednastavených údajů a sladění funkcí s organizací a během podporovaného procesu. Každá dodávka takového systému je tedy pasována na míru podniku. V případě jejich operativního outsourcingu je zatím těžko představitelné, že by tuto fázi bylo možné výrazně eliminovat. V případech rozsáhlých víceuživatelských aplikací tedy outsourcing bude operativní spíše v řádech měsíců.

 

Tím jsme popsali předmět služby v případě, že na základě přání bylo rozhodnutí vytvořit novou službu. Dále popíšeme situaci, kdy již předmět služby specifikován je a potřeba je v procesu řízení změn kvalifikována jako potřeba modifikace předmětu služby (podle členění výše situace b).

 

Tyto situace je obvyklé řešit formou drobných vývojových aktivit, které jsou nazývány „small jobs“. Typickým příkladem je tvorba nových výstupních tiskových sestav aplikací. Tyto drobné vývojové aktivity obvykle obecně specifikovaný předmět služby nijak neovlivní, změní se ale specifikace aplikační funkcionality na podrobnější úrovni. I takové drobné změny je nutné vždy posuzovat z hlediska původní potřeby zákazníka a z hlediska cest k jeho splnění informačním systémem, aby během drobných úprav nedošlo k jejímu znemožnění nebo ztížení, stejně jako je nutné každou drobnou změnu konfrontovat s integritou a bezpečností informačního systému podniku.

Drobné změny jsou ovšem často spíše přáním uživatele než zákaznickým přáním. Potřeby jsou tedy rázu operativních úprav pro zlepšení uživatelského komfortu, drobné potřeby změn formy prezentace výstupů z informačního systému či potřeby drobných úprav funkcionality z důvodu dynamiky podniku a okolí. Z hlediska zákazníka je tedy vhodné delegovat rozhodování o drobných změnách na uživatele, a to často ne na všechny, ale na vybrané uživatele, kteří jsou v našich krajích známi jako „uživatelská správa“ nebo „uživatelé metodici“.

 

Je nutné zmínit také situace, kdy požadavek na velmi drobnou úpravu funkcionality nemusí být v rámci poskytované služby snadno splnitelný, a je-li vyžadován, nelze jej splnit jinak než rozsáhlým projektem. Mezi takové projekty patří mnoho projektů zaměřených na integrační aktivity. V takovém případě se aplikační funkcionalita nemusí změnit, ale změní se parametry informačního systému a s tím i možnosti a cesty splnění nových potřeb. Je tedy vidět, že i nákladné projekty bez jakékoliv úpravy aplikační funkcionality jsou z hlediska přínosů měřitelné.

Opačným případem, bohužel ne tak častým, je situace, kdy i rozsáhlé přání lze splnit již zavedeným informačním systémem, a to využitím jeho funkcionality i pro nové uživatele nebo oživením zatím nepoužívané funkcionality.

5.4.3   Předmět služby a způsob dosažení výsledku

Zatím jsme argumentovali, že součástí předmětu služby by mělo být přání, aplikační funkcionalita a způsob splnění přání pomocí aplikační funkcionality. Tím jsme určili, jakým způsobem přenést odpovědnost za výsledek (informatickou službu) na poskytovatele, tedy tím, jak je předmět specifikován, jsme ponechali odpovědnost na uživateli za věcnou správnost této specifikace, a na poskytovateli odpovědnost za to, jakým způsobem výsledku dosáhne. Zde se podíváme na to, zda a jak řídit tento způsob, jakým poskytovatel službu poskytne.

 

Popisem předmětu plnění služby může zákazník a informatika podniku řídit a kontrolovat skutečné plnění služby. Z hlediska výsledku a jeho věcných přínosů pokládáme výše uvedený popis předmětu služby za vyhovující a dostatečný. Tento popis ale dává poskytovateli možnost zvolit pro splnění služby jakékoliv prostředky. Takový princip je oprávněný: Nechme na poskytovateli, ať zařídí výsledek pomocí technologie, kterou sám vybere, ať se o takové věci nemusíme starat.

Přístup totálního vzdání se kontroly nad technologií ale není dokonalý, a to z těchto důvodů:

·          užití určité technologie může v informačním systému podniku jako celku někdy nežádoucím způsobem ovlivnit chod ostatních jeho částí,

·          užití určité technologie může ztížit udržení konzistence komplexního datového modelu podniku a spolupráci a výměnu dat mezi aplikacemi, a tím vytvořit slabá místa zejména ve spolehlivosti a dostupnosti informačního systému,

·          rezignace na přímé řízení může v případě vybrání špatného a nekompetentního poskytovatele znamenat snížení kvality poskytovaných služeb, a v návaznosti na to snížení kvality v podporovaných procesech,

·          je nutné, aby poskytovatel přistoupil na formu zavádění nových služeb a rušení starých, například aby byl ochoten závazně specifikovat předmět a cenu před započetím vývoje a byl ochoten například spolupracovat při odhadování nákladů na změny,

·          i když to není specifikováno v předmětu služby, její poskytnutí by mělo splňovat některé uživatelské standardy (např. parametry uživatelského rozhraní),

·          zajištění služby musí být v souladu s řízením podnikové bezpečnosti, což se zde týká především bezpečnosti dat.

 

Patrně bychom důvody mohli popisovat ještě podrobněji. Tento krátký popis pokládáme za dostatečný pro ozřejmění, že specifikace předmětu jen zákaznicky není dostačující.

Nesmíme však zapomenout na výše uvedené principy a důvody, které nás k nim vedly. Zmiňme hlavně

·          řízení prostřednictvím služeb, aby bylo možné operativně outsourcovat,

·          eliminace starosti vedení informatiky o technologii z důvodu rostoucí komplexity,

·          odpovědnost zákazníka jen za to, co může ovlivnit a čemu rozumí.

 

Budeme-li chtít předmět rozšířit, nesmíme tyto důvody pominout.

 

Vyřešit toto technologické ovlivnění svobody poskytovatelů při určování způsobu poskytnutí služeb lze při zachování žádoucích principů řízením centrální informatiky pomocí závazných pravidel. Zjednodušeně je možné je popsat jako: Poskytovateli, zajisti zákazníkovi popsanou službu jak umíš, ale musíš při tom splnit určité podmínky.

 

Řízení těchto podmínek, pravidel pro poskytovatele, ovšem nemusí být přímo na bedrech ředitele informatiky, lze je zajistit pomocí speciálních služeb, které jsme nazvali „řídící služby“. U některých z nich lze podobně jako u ostatních informatických služeb uvažovat o outsourcingu.

5.5    Cena aplikačních služeb

Nyní máme popsány základní principy specifikace předmětu služby. Dále se podíváme na možnosti a principy určení ceny za informatické služby.[33]

 

Popišme základní klasifikaci typů cen. Ceny za informatické služby mohou být:

1.       pevná cena (paušální cena),

2.       cena závislá na objemových a kvalitativních parametrech poskytované služby,

3.       cena za odvedenou práci a použitý materiál.

 

Určení outsourcingové ceny informatických služeb lze shrnout do čtyř základních problémů:

·          rozdělení ceny na jednorázovou složku a průběžnou složku,

·          rozdělení ceny za službu na paušál a pohyblivou složku závislou na objemu poskytnuté služby,

·          určení slev nebo sankcí za nedodržení parametrů služby,

·          určení ceny za skutečné splnění přání zákazníka.

 

Zamysleme se nad možným použitím těchto typů cen v informatice. Připomeňme, že informatické služby poskytuje buď externí poskytovatel nebo autonomní proces uvnitř podniku. Pohled na cenu zde tedy rozdělíme na

·          cenu služeb poskytovatele,

·          cenu služeb interního autonomního procesu.

Zde obecně popíšeme cenu z hlediska zákazníka a upozorníme na některé rozdíly podle tohoto členění.

 

V případě externího poskytovatele je nutné cenu specifikovat velmi opatrně. Cena je určena dohodou jako cena smluvní. Zájmem poskytovatele je, aby cena pokryla jeho náklady na službu a vytvořila zisk. Zájmem podniku je, aby cena byla přiměřená dosaženému přínosu. Z hlediska komplexity informačních technologií můžeme uvést další kritický požadavek na cenu z hlediska podniku (a to jak z hlediska zákazníka, tak z hlediska řízení informatiky): Cena musí být sjednána tak, aby umožňovala plánování a účinnou kontrolu celkových nákladů na službu. Vlastností dnešních informačních systémů totiž je, že náklady na ně zjišťované ex-post za provozu (např. úspěšnou metodikou TCO) se velmi liší od nákladů předpokládaných, často i řádově. Na cenu služby je tedy od začátku nutné pohlížet tak, aby nekontrolovatelnému nárůstu nákladů zabránila.

Není nutné pohlížet na poskytovatele s nedůvěrou jako na podvodníka, který si vytváří při sjednávání předmětu a ceny služby kohouty, které později čekají na postupné otevírání a další neplánovaný odtok peněz k poskytovateli. Je ale vhodné přinejmenším věnovat popisu předmětu a konstrukci ceny péči takovou, aby se obě strany nepochybně dohodly na očekávaném výsledku a jeho ceně. Tuto péči považujeme za kompetenci vedení informatiky podniku.

 

V případě interního procesu je situace jiná. Není zde nutné, aby poskytovatel v tomto případě vytvářel zisk, což znamená možnou úsporu. Cena služby bude tedy odpovídat nákladům na její zajištění. Pokud interní proces není zainteresován na obratu, tedy na interní ceně služby, ale pouze na výši nákladů, pak není nutné obávat se nekontrolovatelného nárůstu ceny z nekalých důvodů. Interní cena služby je tedy specifikována na základě pravidel nákladového řízení podniku a interních ekonomických vztahů. Principy tvorby ceny mohou zůstat obdobné jako v případě externího poskytovatele, aby byly podstatné aspekty služby popsány věrně a bylo možné srovnání s tržní nabídkou služby.

 

Z hlediska zákazníka a tedy i z hlediska podnikové informatiky je při sjednávání ceny vhodné udržet principy, které jsme definovali u určování předmětu služeb. V případě ceny to znamená pravidla:

·          cena je závislá pouze na proměnných, které ovlivňuje zákazník,

·          veškeré prostředky a aktivity potřebné pro plnění služeb jsou zahrnuty v ceně služby,

·          cena za službu je známá a sjednaná před tím, než započnou aktivity na zavedení služby.

 

Službu zde chápeme jako produktivní službu pro zákazníka. Proto, aby službu bylo možné poskytovat, je nutné službu zavést, respektive vyvinout a implementovat informační systém. Těmto aktivitám říkáme změna.

Od ceny za službu je tedy nutné oddělit cenu za změnu.

Z hlediska poskytovatele je vhodné určit a zaplatit cenu za změnu, aby mohl pokrýt náklady na provedení této změny. Na druhou stranu z hlediska zákazníka je určovat a platit cenu za změnu nevhodné, protože sama změna zákazníkovi nic nepřináší.

Z tohoto pohledu je nutné odlišit pohled služeb a pohled informačního systému jako investice.

 

Zde chápeme službu jako službu skutečně průběžně poskytovanou a nikoliv službu odloženou do budoucnosti. Informatická služba je tedy poskytována v okamžik, kdy uživatel užívá aplikační funkcionalitu informačního systému, případně v okamžiku, kdy na základě tohoto užití dochází ke splnění potřeby zákazníka (to platí v případě uživatelské aplikační služby).

Dosud hojně užívaný pohled na informační systém jako na investici jej chápe jinak: Je nutné informační systém vytvořit a zavést (a za to zaplatit), abychom ho mohli poté využívat a něco nám přinesl.[34]

 

Oba tyto pohledy na informatiku jsou možné a správné. Z hlediska zákazníka a tedy i z hlediska řízení podnikové informatiky je ale s postupujícím vývojem na trhu služeb informatiky vhodnější pohled služeb. Jednak tento pohled umožňuje průběžné srovnání současně využívaných služeb s alternativní nabídkou, a jednak implicitně zahrnuje nutnost komplexní znalosti nákladů na informační systém.

 

Z hlediska poskytovatele (externího i interního autonomního procesu) je však nutné dívat se na informační systém jako na investici, která se navrátí právě poskytováním služeb informačního systému zákazníkovi. Na základě toho bude kalkulována i cena.

 

Z tohoto rozdílného pohledu vyvstává otázka, jak bude cena rozdělena mezi cenu za změnu (jednorázová složka) a cenu za služby (průběžná složka). Toto je první základní problém cenotvorby outsourcingu informatických služeb.

 

Základním principem pro toto rozdělení by měla být návratnost investice poskytovatele a užitečnost služby pro zákazníka. Hovoříme-li o návratnosti investice, je ovšem nutné počítat s dobou návratnosti. Z toho důvodu je nutné u poskytovatele odlišit

·          investici využitelnou pro více zákazníků (např. hardware, hromadné licence software, obecné vývojové práce),

·          investici využitelnou pouze pro konkrétního jednoho zákazníka (např. jmenovité licence software, implementační a parametrizační práce na míru).

Investici využitelnou pro více zákazníků lze ovšem rozpustit do ceny pro všechny zákazníky, pro které je využívána. Investici do jednoho konkrétního zákazníka však musí v důsledku zaplatit tento jeden konkrétní zákazník. Tato investice do jednoho konkrétního zákazníka a nutnost jejího navrácení je důvodem:

a)       pro dohodu na ceně za změnu,

b)       pro závazek zákazníka odebírat služby po minimální určitou dobu.

V případě externího poskytovatele záleží pak na dohodě poskytovatele a zákazníka, jakým způsobem bude tato investice splacena, zda bude rozložena do ceny za průběžné poskytování služby nebo zda bude splacena jednorázově.

Je zřejmé, že pokud informatika není jednou z podnikatelských činností podniku, pak v případě zajištění služby interně nelze rozložit investici mezi více zákazníků, ale tato je použita pouze pro podnik. Z tohoto pohledu může být zajištění služby externím poskytovatelem efektivnější pomocí úspor z rozsahu a přístupu k rozsáhlejším technologickým celkům, než které jsou využitelné pouze pro jeden podnik.

 

Cenu za změnu v návaznosti na fáze zavedení nové služby (viz výše) tvoří:

·          cena za úvodní studii (za plánování změny),

·          cena za realizaci změny.

 

Objem prací nutných pro hrubou první analýzu problému a návrh řešení služby poskytovatelem (úvodní studii) je odhadnutelný podle potřeby zákazníka. Z hlediska kontroly ceny je vhodné určit cenu za úvodní studii jako jednorázovou a pevnou cenu.

 

Cena za realizaci změny a cena za službu by v tomto modelu měly být výstupem úvodní studie. Jsou-li přijatelné pro poskytovatele i pro zákazníka, může dojít k realizaci změny a zavedení služby. Cena za realizaci změny by měla být opět kontrolovatelná z hlediska celkové výše. Je možné zde využít model cena za práci a materiál, s tím, že cena je dána rozpočtem, který nesmí být překročen, nebo je možné použít celkovou cenu. Cena za realizaci změny je z principu jednorázová, může být ovšem rozpuštěna do budoucí průběžné ceny za službu, nechce-li zákazník do informatiky investovat. Sílou operativního outsourcingu však není rozpouštění ceny za změnu do ceny za službu, ale tlak na to, aby cena za změnu byla co nejnižší (tedy na minimalizaci nákladů na změnu).

 

Změnou ale rozumíme nejen zavedení nové služby. Během poskytování služby také nastávají požadavky zákazníka nebo uživatelů na drobné změny a úpravy služby za provozu IS (tzv. small jobs). K těmto aktivitám je vhodné se postavit jako ke změně i z pohledu ceny. Množství požadavků na drobné změny záleží často na aktivitě zákazníka a uživatelů, a tedy by i cenově měly být na této aktivitě závislé. Nelze je tedy zahrnout do paušální složky ceny ani do ceny závislé na objemových ukazatelích služby (viz kap. Měření služeb IS a jejich efektů). Cenu je tedy vhodné specifikovat obdobně jako u rozsáhlých změn jako jednorázovou cenu za změnu samozřejmě s tím, že každý požadavek na drobnou změnu projde procesem řízení požadavků a změn, kde bude určena jeho cena (a kde bude zajištěna integrita IS apod.). Takových požadavků však může být velké množství a z hlediska jejich cenového schvalování není možné každý hodnotit centrálním vedením (informatiky). Proto je vhodné pravomoc rozhodování o nákupu těchto drobných změn distribuovat například na jejich uživatele, kterým pak budou přičteny vnitřním kontrolingem k tíži. I při takovém opatření je nutné centrálně kontrolovat celkový objem ceny informatických služeb, a proto je vhodné celkový objem ceny zaplacené za drobné změny omezit limitem na určité období. Tento limit je vhodnou úrovní plánování ceny drobných změn na vrcholové úrovni. Za těchto podmínek je možné, aby cena drobných změn byla založena na ceně práce a materiálu.

 

Dalším problémem specifikace ceny outsourcingu je rozdělení ceny za službu na paušál a pohyblivou složku závislou na objemu poskytnuté služby.

Základním principem zde je, aby zákazník zaplatil jen za to, co skutečně chce použít nebo použije. Na základě operativního zvýšení nebo snížení využití služby zákazníkem stoupnou nebo klesnou náklady na službu. To by měla odrážet i cena. Závislost nákladů a využití služby však je velmi složitá a někdy špatně odhadnutelná. Pro zjednodušení se od této složitosti abstrahuje a cena je konstruována jako lineárně závislá na využití služby. Je na poskytovateli, aby tuto lineární závislost co nejvíce přiblížil závislosti skutečné.

 

Cena služby = Pevná složka + (Objem využití služby × Složka závislá na objemu)

 

Trendem je, že podíl pohyblivé složky na ceně roste a podíl paušálu klesá. To souvisí jednak s tím, že technologie umožňují operativnější využití, a dále s tím, že poskytovatelé umějí stále lépe alokovat své náklady.

Pohyblivá složka ceny, kterou řídí svojí aktivitou zákazník, je obvykle vždy objemová a nikoli kvalitativní. Kvalitu služby totiž operativně není možné jednoduše měnit, ta je dána konstrukcí systému dlouhodobě. Pomineme-li možnost ukončení odebírání služby, pak objem využití služby, který je svázán s cenou, je tedy na straně zákazníka jediným nástrojem operativního ovlivnění objemu nákladů na informatickou službu.

 

Dalším problémem je určení slev nebo sankcí za nedodržení parametrů služby. Tento problém nastává zejména v případě externího poskytovatele. Pokud poskytovatel neposkytuje službu řádně nebo vůbec, měl by být sankcionován a nahradit škodu. Otázka sankcí a náhrady škody ovšem není otázkou cenovou. Z hlediska operativnosti a průběhu vztahu je vhodné nehodnotit částečné nedostatky plnění sankcemi, ale systémem slev. To už je ovšem otázka tvorby ceny.

Pro hodnocení adekvátnosti plnění předmětu informatické služby jsou konstruovány kvalitativní a objemové parametry. Ukazatelé skutečné výše těchto parametrů ba se měly pohybovat v intervalech, které jsou pro dané parametry sjednané. Pokud jsou služby poskytovány jiným než sjednaným způsobem, může být použita sjednaná sleva za nedodržení úrovně služeb.

Pokud o výši ukazatele parametru služby není pochyb (je sjednán způsob jejího určení), pak je vhodné, aby se sjednané slevy promítly do ceny služby automaticky a nebylo nutné o každém dílčím snížení jednat. Systém slev je z důvodů jednoduchosti a přehlednosti opět vhodné definovat jako lineární.

Takto cenově řešené slevy za drobné vady služby by ovšem neměly vyloučit možnost zastavení plateb, penalizaci a náhradu škody v případě neplnění zásadního.

 

Je možné také specifikovat bonusy za vyšší kvalitu služeb. Tento přístup je vhodný zejména v případě, kdy zákazník vyšší kvalitu služby požaduje, ale není možné tuto kvalitu nakoupit tak, aby za její dodržení poskytovatel odpovídal. Pak je vhodné jej k vyšší kvalitě alespoň motivovat systémem bonusů. Ve většině případů však vyšší než sjednaná kvalita služeb nemá pro zákazníka přínos natolik prokazatelný, aby bylo vhodné za ni platit.

 

Posledním výše uvedeným problémem cenotvorby informatické služby je určení ceny za skutečné plnění přání. Například v případě aplikační služby jsou výše uvedené cenové principy vhodné pro stanovení ceny poskytování služeb ve formě aplikační funkcionality. Předmět služby jsme ale definovali šířeji, jako potřebu zákazníka, aplikační funkcionalitu a způsob splnění potřeby prostřednictvím aplikační funkcionality. Vzhledem k tomu, že na splnění potřeby zákazníka může mít vliv mnoho jiných faktorů než informatická služba, je otázkou, do jaké míry se má poskytovatel zavázat ke skutečnému splnění přání. Zde musíme rozlišit:

·          cena za skutečné splnění přání,

·          cena za možnost, aby bylo přání splněno (za jinak stejných podmínek).

Je vhodné najít nějakou metriku, která by akcentovala oba tyto případy. Poskytovatel by měl mít zájem jednak na tom, aby pomocí informatiky bylo možné přání splnit, a částečně i na tom, aby skutečně bylo splněno. Tato služba ceny se v případě interního zajištění může promítnout do nákladů na lidské zdroje (bude-li informatikou přání splněno, dostanete odměny). V části Měření služeb IS a jejich efektů se k tomuto problému vrátíme.

 

Z hlediska ceny je také důležitý problém vazby ceny na inflaci a na směnné kursy. Tento problém může být z hlediska kontroly nákladů jak zákazníka tak poskytovatele kritický. Vhodné je vázat na inflaci a směnné kursy pouze ty složky ceny, u nichž je tento vliv prokazatelný. V oblasti informačních technologií ceny s časem rychle klesají, a proto vliv inflace nekopírují. Na inflaci je závislá prakticky pouze cena lidských zdrojů. Na směnné kursy je vhodné navázat samozřejmě pouze to, co je dováženo ze zahraničí. Pokud by tyto principy měly být zahrnuty do tvorby ceny detailně, přestala by být cena přehledná a na straně zákazníka by bylo nutné udržovat podrobnou znalost oblasti informatiky. Z toho důvodu je někdy vhodné zahrnout vliv inflace a směnných kursů do ceny procentně odhadem.

 

Dalším aspektem, který je nutné vzít v úvahu při sjednávání ceny s externím poskytovatelem, je aspekt daňový. Zde je vhodné zmínit například problematiku DPH. Pokud je například v ceně zahrnuta údržba hardware v majetku zákazníka, je nutné tuto položku z daňových důvodů specifikovat cenově zvlášť.

 

Shrňme cenovou otázku informatických služeb:

V ceně služby jsou zahrnuty veškeré zdroje nutné pro její zajištění.

Cena služby = Cena za změnu + Cena za poskytování služby + Cena za splnění přání

Cena za poskytování služby = Pevná cena + Cena závislá na objemu – Sleva za nedodržení úrovně služby

5.6    Řízení zdrojů

Vedle řízení služeb informatiky je další oblastí, kterou jsme ponechali na kompetenci centrálního řízení informatiky, řízení zdrojů potřebných pro interní procesy, které zajišťují služby informatiky. Interní zdroje, jejich využití (prostoje) a využitelnost a zejména jejich břemena je také nutné vzít v úvahu při rozhodování o outsourcingu. Jedná se především o lidské zdroje a snadnost a možnost jejich najímání a propouštění a dlouhodobé investice do aktiv, které je vhodné ekonomicky využít nebo prokázat návratnost.

Opět je nutné podotknout, že zdroje informatiky nemusí být zdroje specializované, ale mohou to být obecné zdroje podniku, jako například kancelářské prostory, investiční prostředky a podobně.

Bezpochyby je možné nakupovat i služby zdrojů informatiky, je-li jich v podniku nedostatek, nebo není-li účelné je v podniku udržovat. Služby těchto zdrojů jsou použitelné pro procesy, zajišťující služby informatiky, nikoli ovšem pro zákazníka informatiky. Konkrétní nákupy nebo využití služeb těchto zdrojů by tedy mělo být prováděno podle přání či potřeby interních informatických procesů. Z hlediska služeb informatiky lze tedy ke zdrojům přistupovat obdobně jako k infrastrukturním neuživatelským službám.

Již jsme zmínili, že řízení zdrojů informatiky je vhodné provádět centrálně z důvodů úspory z rozsahu a že tato odpovědnost je na bedrech ředitele informatiky. Nemůžeme však očekávat, že bude vrcholově řízeno využití každého jednotlivého zdroje. Celostně, prostřednictvím architektury, je možné se na zdroje podívat:

·          buď souhrnně, aby se neztratil celostní pohled na řízení informatiky z hlediska operativního outsourcingu,

·          nebo pouze z hlediska kritických strategických zdrojů, jejichž služby nelze snadno nakoupit na trhu,

·          nebo oba tyto pohledy zároveň, tedy celostní pohled na zdroje zároveň s pohledem na zdroje strategické.

Zobrazovat mnoho různých informatických zdrojů souhrnně však znamená ztrátu vypovídací schopnosti takového zobrazení, a zároveň architekturu služeb znepřehledňuje. Zobrazení pouze strategických zdrojů zase postrádá komplexnost a celostnost pohledu. Navíc, služby zdrojů jsou využity pouze pro služby, které jsou zajišťovány interně.

Souvislosti řízení aplikačních služeb a zdrojů věnujeme kapitolu Model zdrojů a služeb informatiky.

 

Další otázkou je, zda lze outsourcovat celé řízení zdrojů informatiky. To patrně do určité míry lze.

Podívejme se například na řízení informatických zdrojů, které jsou aktivy, tedy zejména software a hardware. Mohou nastat situace, kdy jsou toto zdroje podnikové, tedy aktiva jsou majetkem podniku, a přesto tyto zdroje řídí a využívá externí poskytovatel, aby podniku poskytl službu. V takovém případě je někdy vhodné přenechat řízení těchto zdrojů včetně jejich obhospodařování na poskytovateli, tedy toto řízení outsourcovat. Tato situace přichází v úvahu zejména při rozhodnutí outsourcovat oblast informatiky totálně.

Obdobná situace teoreticky může nastat i u lidských zdrojů, ale vzhledem k tomu, že je to velmi nepravděpodobné a krkolomné, nebudeme takovou situaci uvažovat.

Problematice vlastnictví prostředků informatiky věnujeme samostatnou kapitolu.

5.7    Uživatelské infrastrukturní služby

Nyní se podívejme na služby zdrojů, které někdy nazýváme infrastrukturní služby, na služby, které jsou nutné proto, aby bylo možné poskytovat služby aplikační.

Pro zajištění aplikačních služeb je nutné užít mnoho zdrojů a jejich služeb. Některé z nich jsou služby uživatelské, tedy jsou poskytovány přímo jednotlivým uživatelům nebo jejich poskytování nebo členění je závislé na strukturaci a dislokaci uživatelů aplikačních služeb. Tyto služby zákazníkovi samy o sobě nepřináší splnění jeho potřeb, ale jsou podmínku toho, aby uživatel mohl užívat služby aplikační.

Jak uvidíme, uživatelské infrastrukturní služby slouží především pro distribuci služeb aplikačních k uživateli, případně od něj.

 

Tyto služby budou opět patrně v každém podniku členěny jiným způsobem, zde opět ozřejmíme základní principy na obecném příkladu:

 

Uživatelské infrastrukturní služby:

·          Koncové stanice PC (služby osobních počítačů umožňující přístup k aplikačním službám, spouštění klientů aplikací apod., zahrnuje hardware, operační systém, podporu a údržbu, osobní tiskárny a podobné periferie, může zahrnovat i jiné koncové terminály, např. PDA),

·          LAN (služba umožňující lokální přenos aplikačních služeb od serveru k uživateli),

·          WAN (služba umožňující vzdálený přenos aplikačních služeb),

·          Telefonní sítě (služba umožňující zejména lokální přenos aplikační služby „Hlasové služby“).

 

Například služba „Koncové stanice PC“ je službou zdrojů informatiky, protože samotné PC nepřináší zákazníkovi plnění jeho potřeb, ale přesto je službou uživatelskou, protože poskytuje zařízení, prostřednictvím kterého uživatel využívá více služeb aplikačních. Z hlediska odpovědností a z hlediska technologické povahy zařízení koncových stanic je vhodné, aby byly poskytovány přímo jmenovitým konkrétním osobám – uživatelům.

 

Z důvodu, že tyto speciální služby zdrojů mají tu vlastnost, že jsou uživatelské nebo jsou sdílené pro poskytování více aplikačních služeb, není vhodné, aby tyto služby užívali poskytovatelé aplikačních služeb jako subdodávku pro své služby, ale je vhodné, aby tyto služby uživatel nakupoval paralelně (komplementárně).

Pokud jsou aplikační služby členěny tak, aby jejich poskytovatelé (v případě vnitropodnikového zajištění pak autonomní informatické procesy) byli odpovědní za jejich výsledek, je vhodné na ně tuto odpovědnost přenést pokud možno v co největším rozsahu, a co nejvíce eliminovat závislost výsledku na spolupůsobení podniku. Čím více jsou ovšem služby závislé na službách, za které je odpovědný někdo jiný, tím větší je nutnost řídit integraci těchto služeb a spolupůsobení a tedy i větší odpovědnost a riziko podnikové informatiky. Vzhledem k rostoucí komplexitě informačních technologií a k potřebě operativních měn v podnikovém informačním systému je vhodné nutnost takového řízení co nejvíce omezovat a distribuovat je buď na autonomní interní procesy nebo na poskytovatele. Uživatelské infrastrukturní služby jsou z tohoto pohledu tedy pouze nutné zlo, a je vhodné jich specifikovat co nejméně.

V našem případě, který vychází se současných a v nejbližší budoucnosti očekávaných technologických požadavků informačních systémů, jsme specifikovali uvedené čtyři služby, které jsou z tohoto pohledu nutné.

 

Zde jsme se věnovali službám zdrojů, které na rozdíl od většiny služeb zdrojů jsou uživatelské. Z druhé strany mezi aplikačními službami najdeme služby, které na rozdíl od většiny aplikačních služeb uživatelskými nejsou. Jedná se o služby, jejichž výsledek je pro věcnou oblast v podniku přímo přínosný, ale produkt těchto služeb neužívají osoby – uživatelé, ale jsou nějakým způsobem využity automatizovaně. Příkladem může být v členění uvedeném v kapitole Aplikační služby část aplikační služby „Prodej, zákazníci, smlouvy“, která bude zajišťovat rozhraní pro komunikaci EDI se zákazníky podniku.

5.8    Centrální řídící aktivity v IS

Výše jsme vymezili služby produktivních procesů informatiky. Jakým způsobem ale naložit s aktivitami, které jsou vhodné pro optimalizaci řízení podnikové informatiky, ale zákazník informatiky je sám nepotřebuje. Jedná se například o řízení požadavků a změn a řízení technologické integrace. Vezmeme-li v úvahu, že tyto aktivity je také možné outsourcovat, měly by se v konceptu rozhodování „make or buy“ patrně také objevit.

Je nutné mít na paměti, že některé tyto služby nespadají pouze do kompetencí informatiky, a je tedy vhodné je v podniku zajišťovat v širším rozsahu než pouze pro řízení informatiky. Mezi takové aktivity patří:

·          řízení požadavků na informatiku

·          řízení změn v IS/IT

·          řízení problémů a incidentů

·          řízení bezpečnosti a kvality IS

·          řízení systémové integrace

·          řízení technologické integrace

·          řízení rozhraní aplikací

·          řízení datové integrace

·          řízení integrace uživatelského rozhraní

 

Také se musíme zabývat strategickým řízením informatiky podniku, které zde reprezentuje základní rozhodovací problém rozhodování, kterou informatickou službu zajistit interně a kterou nakoupit.

 

Tyto aktivity mají všechny řídící charakter. V procesním pohledu nejsou jejich výsledky produkty pro zákazníka (nejsou to produktivní procesy), ale jejich výsledkem je ovlivnění produktivních procesů v určený prospěch. Náš koncept informatiky jako služby pro zákazníka je tedy primárně nezahrnuje jako služby, které je možné delegovat na autonomní proces podle principů distribuce řízení.

I tyto řídící aktivity však je možné ve značné míře zajistit dodavatelsky. Pro rozhodování o jejich dodavatelském zajištění je nazývejme řídícími službami.

Spolu s outsourcingem těchto aktivit jsou jejich poskytovateli předávány i kompetence k řízení služeb ostatních poskytovatelů služeb. Tato skutečnost může velmi komplikovat odpovědnostní vztahy mezi zúčastněnými subjekty, a proto se reálně používají ponejvíce dva extrémní případy:

·          všechny řídící služby zůstávají v podniku; to je případ interního zajištění informatiky, outsourcingu zejména služeb zdrojů nebo modelu CIO jako IT broker.

·          všechny řídící služby jsou outsourcovány, což bývá zejména případ totálního (komplexního) outsourcingu, případně totálního outsourcingu na jednoho poskytovatele, kdy postupem času podnik nakupuje služby i od jiných subjektů nebo zajišťuje interně, ale tento jeden poskytovatel zajišťuje integrační aktivity v informačním systému.

6       Model zdrojů a služeb informatiky

V této kapitole se podíváme na jednoduchý model řízení služeb informatiky. V předchozím textu jsme rozčlenili služby informatiky. I v případě distribuce odpovědnosti na procesy zajišťující jednotlivé služby jsme argumentovali, že řízení zdrojů a integrace musí zůstat centrální kompetencí podnikové informatiky. Centrálně řídit zdroje je však vhodné až na výjimky výhradně v případě interního zajištění služeb, naopak v případě jejich outsourcingu se podnik jejich řízení vzdává. Zde tedy načrtneme model řízení služeb informatiky jako pohled na základní souvislosti takto členěné informatiky, zejména na souvislosti aplikačních služeb a zdrojů použitých pro jejich zajištění, a to zejména jako nástroj pro složité a komplexní rozhodování o outsourcingu jednotlivých aplikačních služeb v celkovém kontextu ostatních služeb a zdrojů informatiky.

6.1    Matice aplikační služby / zdroje

Jako základ modelu použijeme matici přiřazení zdrojů pro zajištění služeb informatiky, kde ve sloupcích jsou uvedeny aplikační služby informatiky a v řádcích podnikové zdroje informatiky (nebo služby zdrojů), které jsou pro zajištění aplikačních služeb použity (viz obrázek).

 

		Aplikační služby
		S1	S2	S3	S4	S5	S6	S7	S8	S9
Zdroje	IT zdroje	X	X	X	X	X	X	X	X	X
	Hardware	X	X	X	X	X	X	X	X	X
	Software	X	X	X	X	X	X	X	X	X
	Databáze	X	X	X	X	X	X	X	X	X
	LAN	X	X	X	X	X	X	X	X	X
	Uživatelské stanice PC	X	X	X	X	X	X	X	X	X
	…
	Lidé	X	X	X	X	X	X	X	X	X
	Programátor
	Správce sítě	X	X	X	X	X	X	X	X	X
	…
	Ostatní zdroje	X	X	X	X	X	X	X	X	X
	Budovy	X	X	X	X	X	X	X	X	X
	El. energie	X	X	X	X	X	X	X	X	X
	Vozový park
	…
	Finance	X	X	X	X	X	X	X	X	X

obr. 11,  Matice aplikační služby / zdroje

 

Řádky: Zobrazení zdrojů

Zdroje uvedené v řádcích jsou uvedeny tak, aby byl seznam co nejvíce úplný (pro umožnění komplexity rozhodování o outsourcingu - aby nebyl opomenut některý třeba zdánlivě nevýznamný aspekt). Zdroje mohou být uvedeny hierarchicky, a to v různé úrovni podrobnosti. V případě hrubšího pohledu se nejedná o konkrétní zdroje, ale o jejich typy. Při konkrétním popisu je vhodné zvolit takovou podrobnost popisu zdrojů, při které jsou již patrné rozdíly užití mezi jednotlivými službami. V případě lidských zdrojů to znamená popis kvalifikací pracovníků, v případě software to znamená popis jednotlivých použitých produktů, v případě budov to znamená popis konkrétních budov, ve kterých jsou služby zajišťovány. Pokud je úroveň rozdělení zdrojů příliš vysoká, jako například ve zde uvedené tabulce, pak není zobrazení dostatečně efektní, protože všechny služby užívají všechny typy zdrojů (což je ovšem pro rozhodování o outsourcingu také velmi podstatná informace).

Zdroje, které využívá externí poskytovatel služby jako své zdroje pro zajištění služby a jejichž využití není podnikem řízeno, není nutné v modelu uvádět, leda pro případ, že by bylo žádoucí uchovat přehled o tom, které outsourcované služby užívají které zdroje pro případné rozhodování o jejich zpětném insourcingu nebo pro kvalifikované interní rozhodování o jejich rozvoji.

 

Sloupce: Zobrazení služeb

Podobně jako zdroje mohou být v různé podrobnosti a v hierarchickém členění uvedeny i aplikační služby. Pro rozhodování „make or buy“ je vhodné takové členění služeb, které pro outsourcing přichází v úvahu. O členění služeb jsme pojednali již v kapitole Služby podnikové informatiky. (V tabulce jsou pro zjednodušení použita označení služeb S1, S2, …)

 

V buňkách tabulky je zobrazeno, která služba užívá který podnikový zdroj.

 

Je patrné, že některé zdroje mohou být použity pouze pro jednu službu (zejména aplikační software, specializovaní konzultanti apod.) a některé jsou zase použity společně pro více služeb nebo i všechny služby (sítě LAN, databáze, budova a hardware výpočetního střediska).

 

Tento model je statický, zobrazuje stav přiřazení zdrojů službám v určitém okamžiku, nezobrazuje časový vývoj. Vývoj se promítne do modelu jeho změnami. Pro rozhodování o různých variantách outsourcingu služeb tedy lze využít několik tabulek.

 

Podobnou matici lze použít i pro přehled o zákaznících jednotlivých služeb a pro řízení vztahů s nimi, pokud v řádcích nahradíme zdroje (interními) zákazníky služeb.

6.2    Použití modelu v řízení outsourcingu

Při pohledu na řízení informatiky prismatem tohoto modelu a předchozích kapitol můžeme identifikovat dvě hlavní protichůdné tendence:

1.       snaha využít co nejvíce interních zdrojů pro co nejvíce služeb, aby byly maximalizovány úspory z rozsahu,

2.       snaha alokovat co nejvíce zdrojů plně do využití jednou nebo několika málo službami, aby bylo možné uspořádat informatické procesy podle aplikačních služeb a distribuovat na ně odpovědnost za poskytnutí služby v co největším rozsahu.

 

Na tyto snahy se lze podívat jako na úlohy na modelu.

 

obr. 12,  Autonomní služba se zdroji

 

Na obrázku je zobrazen extrémní případ, kdy jsou pro zajištění služby S4 použity zdroje Z1 až Z7, a pro zajištění ostatních služeb tyto zdroje použity nejsou. Tato situace znamená, že je možné delegovat řízení zajištění služby S4 včetně řízení zdrojů Z1 až Z7.

Příkladem může být aplikační služba „Ekonomický systém SAP R3“, a zdroje Z1 až Z7 pracovníci kvalifikovaní jako specializovaní konzultanti pro funkcionalitu modulů SAP, který je použit v podniku pro zajištění pouze této služby. Řízení těchto kvalifikací není nutné zajišťovat centrálně, je možné je delegovat na proces nebo poskytovatele, který zajišťuje službu Ekonomického systému.

 

obr. 13,  Podnikový zdroj potřebný pro všechny aplikační služby

 

Druhý extrémní případ ukazuje zdroj Z3, který je použit pro zajištění všech aplikačních služeb S1 až S10. Tato situace naznačuje, že využití takového zdroje je nutné řídit centrálně.

Zde může být příkladem síť LAN. Pro zajištění téměř všech aplikačních služeb (pro jejich doručení uživateli) je nutné využít zdroj „síť LAN“. To znamená, že využití sítě LAN nemohou řídit autonomní procesy nebo poskytovatelé jednotlivých aplikačních služeb informatiky, ale je nutné je řídit centrálně. (My jsme navíc výše síť LAN uvedli jako uživatelskou službu zdroje.)

Tyto extrémní případy ovšem ve skutečnosti nastanou výjimečně, zvláště v oblasti informatiky „všechno souvisí se vším“ a pro mnoho aplikačních služeb jsou využity mnohé zdroje. Pokud je účelem modelu usnadnit distribuci odpovědností, pak je vhodné alokaci možné napomoci vhodným členěním služeb a zdrojů.

Například pro službu Ekonomický systém mohou být zdrojem pracovníci, budovy, elektrická energie, peníze atd. Zdrojem ale také mohou být služby výpočetního střediska. Pokud služby výpočetního střediska využívá více služeb a je řízena centrálně, není už nutné alokovat zdroje, které jsou nutné pro zajištění služeb výpočetního střediska (jako lidé, elektrická energie, budova atd.), na aplikační služby (na Ekonomický systém), ale je možné specifikovat službu zdroje „služby výpočetního střediska“, která bude dostatečně definovaná tak, aby bylo možné její využití různými autonomními poskytovateli aplikačních služeb, a která již bude zahrnovat využití těchto svých zdrojů.

Takový přístup bychom mohli zahrnout do modelu, kdyby matice přiřazení zdrojů službám byla vícedimenzionální. To by však bylo destruktivní, a proto zůstaneme u případné úpravy strukturálního popisu zdrojů s ohledem na tyto možnosti, případně s uvedením služby zdrojů, které využívají jiné zdroje buď ve sloupci nebo v řádku tabulky nebo jak ve sloupci tak v řádku podle potřeby. Je ovšem vhodné, aby zobrazení korespondovalo s kontrolingovým systémem podniku.

 

Při různě podrobném pohledu na strukturované zdroje se může pohled na možnost distribuce řízení zdrojů měnit. Pokud ředitel informatiky nezná alokaci zdrojů informatiky na služby informatiky dostatečně podrobně, pak v tomto modelu může zjistit pouze, že všechny služby využívají všechny typy zdrojů, a svou centrální kompetenci řízení zdrojů nemůže být bez podrobnější znalosti schopen rozpustit na autonomní procesy, a rozhodování o outsourcingu je pro něj větší neznámou. Naopak podrobnější znalost alokace zdrojů dává vedení větší možnosti účelové distribuce odpovědností v oblasti informatiky, ale na druhé straně zase klade větší nároky na trvalou velmi podrobnou znalost zdrojů.

 

Nyní se podívejme na outsourcing pohledem tohoto modelu

Z matice modelu je patrné, že je možné outsourcovat buď

·          zdroje (resp. služby zdrojů),

·          nebo aplikační služby.

 

To je zásadní rozdíl přístupů k outsourcingu. Poskytovatel může být odpovědný za provoz sítí LAN, provoz aplikačního a základního software atd. (tedy za služby zdrojů podnikové informatiky), nebo může být odpovědný „za výsledek“, tedy za aplikační služby, jak byly popsány výše. Přestože v obou případech poskytovatel dělá prakticky totéž a věcný krátkodobý výsledek také může být stejný, předmět smlouvy mezi podnikem a poskytovatelem je v obou případech velmi odlišný, odlišné jsou odpovědnosti a rizika stran a ovšem také cena služeb.

 

Dodavatelské zajištění zdrojů informatiky je odpovědnostně poměrně jednoduchá věc. Na model se podíváme spíše z pohledu outsourcingu aplikačních služeb.

 

Je-li odpovědnost za aplikační službu svěřena autonomnímu procesu nebo poskytovateli, je tento odpovědný za kompletní zajištění této služby, tedy za transformaci zdrojů, které používá až po požadovaný výstup nebo efekt pro zákazníka nebo uživatele. V modelu je patrné, že jsou-li pro využití takové služby potřebné další podnikové zdroje, je nutné specifikovat odpovědnostní „rozhraní“ mezi odpovědností za zajištění těchto zdrojů a odpovědností za zajištění služby. Při specifikaci předmětu aplikační služby, který je, jak je uvedeno v předchozím textu, popsán jako výsledek a efekt, je tedy nutné také specifikovat, které zdroje nejsou součástí předmětu služby (není v ceně služby), a jaké jsou nutně poskytnuté parametry podnikových zdrojů, aby služba mohla být poskytnuta v předmětu, rozsahu a kvalitě, ve kterých je specifikována. Takovéto požadavky na zdroje jsou velmi podobné nutnému spolupůsobení při vývoji informačního systému. V souladu s principy specifikace služeb informatiky musíme říci, že takové věci nemohou a nemusí zajímat zákazníka podnikové informatiky. Zákazník by měl koupenou službu dostat bez výmluv na použité zdroje. Řízení těchto odpovědnostních integračních vazeb je tedy na bedrech centrálního řízení informatiky, kterému v tom může pomoci zde uvedená matice.

 

 

obr. 14,  Příklad matice - nutnost odpovědnostního rozhraní

 

Na tomto obrázku například služby Logistický systém a Marketingový systém (zajištěné komplexně dodavatelsky) používají podnikové výpočetní centrum. Ve smlouvě mezi poskytovatelem a podnikem (vedením informatiky) by tedy měly být parametry výpočetního střediska, které jsou pro poskytovatele podstatné, aby mohl službu zajistit v parametrech, ke kterým se zavázal. Dále pro poskytování služby Logistický systém její poskytovatel používá podnikovou budovu I., což znamená, že je nutné smluvně zajistit, aby měl poskytovatel do této budovy přístup, a parametry, ve kterých ji potřebuje/smí používat.

 

obr. 15,  Rozdělení zdroje umožní distribuci řízení a autonomii služby

 

Další obrázek zobrazuje dvě služby Ekonomický systém a Logistický systém. Obě služby používají zdroj databáze Oracle. Dokud jsou obě služby zajištěny interně, nemusí nastat problém. Pokud se vedení informatiky rozhodne jednu ze služeb outsourcovat, bude nutné řešit společné využití zdroje „databáze Oracle“ dvěma subjekty. Model tuto nutnost připomene. Zvláště v případě databází může být kompetenční rozhraní natolik rozdílné, že je někdy vhodné zdroj také odpovědnostně rozdělit mezi subjekty a navíc ale řešit integrační problémy, které tak nastanou. V případě databází to znamená rozdělit data mezi služby, zajistit technologické oddělení dat outsourcované služby (migrovat data) a zajistit řešení datové integrace těchto dvou technologických řešení.

 

Při rozhodování o outsourcingu (nebo o distribuci odpovědnosti za služby) tedy může model dát informaci o tom, které zdroje jsou pro zajištění služby využity, a zda jsou tytéž zdroje využity i pro jiné služby. To jsou podstatné informace pro specifikaci předmětu odpovědnosti poskytovatele služby a odpovědnosti spolupůsobení podniku (poskytnutí zdrojů pro zajištění služby).

Také je to podstatná informace pro možnost komplexního rozhodování, které zdroje využívané pro službu poskytovatel od podniku převezme a které nikoliv. Již v raných úvahách o outsourcingu je vhodné ujasnit, které zdroje podnik outsourcingem uvolní pro jiné účely a které naopak chce předat poskytovateli, protože je neumí nebo nechce využít.

Cena aplikačních služeb při outsourcingu může být řádově jiná podle toho, zda je v této ceně zahrnuto využití určitých konkrétních zdrojů, nebo zda se předpokládá, že tyto zdroje zajistí podnik vedle sjednaných služeb. Náš model umožní komplexní přehled o tom, co je nebo může být předmětem odpovědnosti dodavatele a tedy také součástí sjednané ceny. To může zabránit případným budoucím sporům o tom, zda něco je nebo není zahrnuto ve službě.

6.3    Jiné než aplikační služby v modelu

Zatím jsme model chápali jako nástroj, který podá komplexní informaci pro rozhodování o outsourcingu aplikačních služeb. To koresponduje se základním řízením informatiky, které navazuje na potřeby zákazníka informatiky. Lze jej použít ovšem i pro jiné pohledy na řízení podnikové informatiky.

 

Souvislost aplikačních služeb a primárních zdrojů může být, jak již bylo řečeno, provázána mnoha dílčími službami zdrojů, které je z hlediska distribuce odpovědností v informatice také vhodné sledovat. V matici jsme zjednodušili pohled s primárním ohledem na aplikační služby.

 

Dalším možným pohledem je pohled na alokaci zdrojů informatiky kromě aplikačních služeb také k dalším službám. Podle našeho členění se jedná o služby některých zdrojů (např. uživatelské služby zdrojů) a služby řídící, kterými se stávají některé centrální kompetence podnikové informatiky, pokud CIO uvažuje i o jejich outsourcingu (například zajištění datové integrace).

Do matice tak můžeme přidat vedle aplikačních služeb další sloupce, které budou reprezentovat služby zdrojů a řídící služby, ovšem zejména účelově, v případě, že dochází k rozhodování o jejich dodavatelském zajištění nebo o distribuci odpovědností za ně na autonomní procesy.

 

obr. 16,  Matice z pohledu řízení informatiky

 

Pro zajištění těchto nově přidaných služeb ovšem je také nutné využívat zdroje, a lze tedy s nimi na modelu zacházet obdobně jako se službami aplikačními. Lze tedy sledovat jejich možné odpovědnostní oddělení od ostatních služeb, případně rozhraní při využití zdrojů.

 

Toto rozšíření modelu posouvá využití modelu do mírně odlišné roviny. Zatímco původní matice zobrazovala podnikovou informatiku v jejím účelu jako podpoře jiných podnikových procesů, rozšířená matice akcentuje primárně pohled realizační, tedy již v zajištění podnikové informatiky. Tento pohled by neměl nad pohledem účelu informatiky převážit.

 

Dalším možným rozšířením matice je zobrazení dodavatelů, kteří služby poskytují. Rozměr „dodavatelé“ může nahradit v řádcích matice zdroje.

 

obr. 17,  Matice služby / dodavatelé

 

Tento pohled je také realizačním pohledem řízení informatiky a dává celostní přehled o tom, které služby poskytují kteří dodavatelé.

 

Vedle orientace na zákazníka a na centrální řízení informatiky lze matici použít i v pohledu uživatelském, a to v přiřazení užití služeb konkrétním uživatelům v podniku. Uživatele lze pak uvádět v řádcích tabulky také strukturovaně, a to podle organizace podniku. Lze tak sledovat, kteří konkrétní uživatelé (které útvary, které procesy atd.) užívají které služby. V tomto případě má smysl uvádět ve sloupcích především uživatelské služby.

 

obr. 18,  Matice služby / uživatelé

 

Ve struktuře uživatelů lze v buňkách tabulky uvádět číselné údaje mezisoučtů uživatelů a tím mít podklad pro řízení počtu uživatelských oprávnění pro jednotlivé služby v podniku, nebo například pro řízení školení uživatelů.

 

Na závěr této kapitoly uvedeme stručné shrnutí pohledů a jejich možného využití:

 

řádky	sloupce	využití
zdroje, služby zdrojů	aplikační služby	rozhodování o make or buy aplikačních služeb, odpovědnostní oddělení služeb, odpovědnostní oddělení zdrojů, řízení alokace zdrojů, řízení rozhraní služeb a zdrojů, řízení s primárním ohledem na zákazníka informatiky
zákazník	aplikační služby	řízení vztahů se zákazníky informatiky řízení plnění potřeb (řízení efektů) strategické řízení informatiky
zdroje, služby zdrojů	služby včetně řídících a některých služeb zdrojů	dtto, řízení s primárním ohledem na zajištění centrálních kompetencí podnikové informatiky
dodavatel	služby včetně řídících a některých služeb zdrojů	přehled o interním a dodavatelském zajištění služeb
uživatel	uživatelské služby	řízení uživatelů služeb v podniku, řízení licencí, řízení školení

 

7       Vlastnictví prostředků IT při outsourcingu služeb

Důležitým faktorem, který hraje roli při specifikaci předmětu služeb, je vlastnictví prostředků informačního systému, tedy informačních technologií.

 

Při ortodoxním přijetí principů distribuce řízení na procesy bychom mohli získat názor, že v případě outsourcingu aplikační služby už podnik nemusí zajímat zdroje, které pro tuto službu poskytovatel použije. Takový přístup je však rozumný jen do určité míry.

Při běžném poskytování služby je podstatný a závazný předmět této služby, jehož specifikaci jsme vymezili výše. V takovém případě je sjednáno, co je pro podnik a zákazníka informatické služby podstatné, a co tedy musí dodavatel zajistit, a nejsou-li zdroje předmětem specifikace aplikační služby, není nutné, aby je zákazník kontroloval.

Taková ideální situace však nastane asi jen v nemnoha reálných případech. Odhlédneme od běžného poskytování služeb a podíváme se na období před začátkem běžného poskytování služeb externím poskytovatelem. Tím může být buď vývoj nové služby (nového IS) nebo převod stávajícího interního provozu na poskytovatele.

I vývoj nového informačního systému, i převod stávajícího systému na poskytovatele se neobejde bez přesné technické specifikace vyvíjeného díla nebo převáděného stavu IS a tuto technickou specifikaci musí sjednat poskytovatel se zákazníkem, což znamená, že zákazník musí do jisté míry umět řídit zdroje informatiky, které pro plnění služby použije poskytovatel.

Dalším aspektem je například integrace, kdy je nutné provozovat externě poskytovanou aplikační službu na infrastruktuře podniku a podobně.

Zcela specifickou otázkou je však otázka vlastnictví zdrojů IT při outsourcingu. Otázka majetku hraje při outsourcingu často velmi významnou roli, a proto tuto kapitolu věnujeme právě vlivu vlastnictví prostředků na služby informatiky.

 

V případě, že se jedná o interní autonomní procesy, je možné odpovědnost za službu přenést na proces bez ohledu na vlastnictví prostředků, protože ty jsou vždy v majetku podniku. Pouze pro určení ceny služby, tedy přesných nákladů na službu, je nutné využití majetku nějakým způsobem procesu naúčtovat k tíži. Slovo „pouze“ ovšem neberme příliš vážně, protože přiřadit využití aktiv v informatice procesům nebo službám není nijak jednoduché.

 

Při outsourcingu na externího poskytovatele je však hledisko vlastnictví prostředků kritickým místem možnosti přenesení odpovědnosti za službu prostřednictvím specifikace předmětu služby. Zde uvedeme základní možnosti vlastnictví aktiv při outsourcingu IS/IT:

a)       veškeré prostředky IS/IT pro poskytování služby zcela vlastní poskytovatel,

b)       veškeré prostředky IS/IT pro poskytování služby zcela vlastní podnik,

c)       některé prostředky IS/IT pro poskytnutí služby vlastní podnik a některé poskytovatel.

 

Ihned můžeme říci, že z hlediska specifikace předmětu služby je nejvýhodnější variantou ta, kdy veškeré prostředky vlastní poskytovatel. Na poskytovatele chceme přenést odpovědnost za co nejvíce faktorů, které mohou ovlivnit výslednou poskytnutou službu, kromě

·          věcných parametrů, které ovlivňuje zákazník,

·          vlastností, které jsou řízeny v informatice centrálně (kvalita, integrace, bezpečnost …).

Chceme tedy, aby o využití prostředků nutných pro zajištění služby rozhodoval v co největší míře poskytovatel, a také tyto prostředky zajišťoval. Pokud vlastnictví prostředků informatiky ponecháme na bedrech podniku, bude mít poskytovatel ztíženou možnost:

·          prostředky využít pro jiné své aktivity (pro úspory z rozsahu),

·          rozšiřovat a vylepšovat prostředky na svůj účet,

·          přestat využívat prostředky a nahradit je jinými.

Dále může činit problémy, pokud jsou prostředky (například výpočetní výkon počítače) použity i pro plnění jiné služby, která je zajištěna jiným způsobem (interně, jiným dodavatelem), a to v zejména v případě, že kapacita prostředku nedostačuje pro plnění služby, nebo v případě, kdy je nutné upravovat vlastnosti prostředku.

 

Je tedy vhodné, aby veškeré informatické prostředky nutné pro poskytnutí služby zajišťoval poskytovatel na svůj účet. V některých případech je to ale obtížné. Například v případě, že služba byla z interního provozu převedena na externího poskytovatele, a provést převod rozsáhlých aktiv na poskytovatele není vhodné, například z důvodu přílišného rozdílu účetní a tržní hodnoty, který by při převodu neblaze ovlivnil hospodářský výsledek jak podniku, tak poskytovatele.

 

V takových případech je možné specifikovat výstupy zdrojů jako další službu (službu zdroje nebo infrastrukturní službu), kterou bude poskytovatel pro zajištění služby nakupovat od podniku. Aby byla odpovědnost za takové prostředky opět přenesena na poskytovatele co nejvíce, je vhodné spíše než speciální informatické služby zdrojů jednoduše tyto prostředky poskytovateli pronajmout.

 

obr. 19,  Vlastnictví prostředků – příklady řešení

 

Příklad: Podnik používá jeden počítač (server) pro provoz aplikace A i aplikace B. Službu A poskytuje externí poskytovatel, službu B zajišťuje podnik interně (interním procesem B). Problémem je:

určit, jaké náklady jsou na službu A a jaké na službu B, a tedy jak kalkulovat cenu obou služeb,

komu přičíst náklady na provoz a údržbu počítače, jak je rozdělit,

kdo ponese náklady na rozšíření a upgrady počítače,

využití počítače při špičkách, preferovat aplikaci A nebo B?

Řešením je specifikace služby zdroje, tedy výpočetního výkonu počítače (nazveme ji C). Tato služba bude specifikována podle zde přijatých principů a bude autonomní. Službu C bude zajišťovat autonomní proces C v podniku a ten bude službu prodávat poskytovateli a procesu B, kteří ji použijí pro zajištění svých služeb. Službu je nutné specifikovat v takových parametrech, které jsou podstatné pro zákazníka (v našem případě je zákazníkem poskytovatel a proces B) a které může ovlivňovat, zde v informatických parametrech, které budou kvantifikovat potřebu výpočetního výkonu pro aplikace A a B.

 

Jiným příkladem může být nákladný počítač, který je využit výhradně pro aplikaci A, která byla nedávno outsourcována, tedy převedena z interního zajištění k poskytovateli. Vlastnictví počítače však zůstalo z jistých důvodů podniku. Zde je možné počítač pronajmout (bez specifikace jeho služeb) poskytovateli, a to za takovou cenu, aby to nebylo pro podnik prodělečné (tedy s ohledem na vnitřní úrokovou míru a návratnost investice).

 

Z hlediska specifikace předmětu a jeho následné korelace s cenou služby je nutné tyto vztahy zprůhlednit. Mohou totiž nastat dvě situace, kdy předmět služby je specifikován zcela stejně, a to správně věcně z hlediska zákazníka, a přitom je cena služby řádově rozdílná. A to právě v případě, kdy je nebo není do ceny započítáno využití nějakého prostředku (v našich příkladech počítače). Pokud je prostředek v majetku poskytovatele, je zahrnut v předmětu a ceně služby samozřejmě. Pokud je prostředek v majetku podniku, pak to již samozřejmé není. Pak je vhodné

a)       buď předmět služby vymezit tak, aby v něm využití konkrétního prostředku zahrnuto nebylo a adekvátně snížit cenu služby, což má nevýhodu v tom, že specifikace předmětu pak již nemůže být zcela podle potřeb zákazníka, ale musí být zahrnuta technologická stránka,

b)       nebo zůstane předmět specifikován komplexně s tím, že poskytovatel si prostředek pronajme nebo zakoupí jeho služby od podniku, a skutečnost, že za něj zaplatí, se promítne do výše ceny za službu.

Z hlediska průhlednosti vztahů je vhodné, aby veškeré prostředky použité pro poskytnutí služby byly zahrnuty v jejím předmětu a ceně, a proto zcela jednoznačně preferujeme variantu b, a to i přesto, že může s sebou přinášet mírné zvýšení transakčních nákladů a někdy i daňového zatížení.

 

U některých prostředků je obtížné definovat jejich služby v předmětu a parametrech tak, aby byly snadno dělitelné mezi více využití různými subjekty a v tomto směru také ocenitelné. Takových prostředků je v oblasti informatiky mnoho. Pokud se služby prostředků rozdělit a vhodně ocenit nepodaří, pak je vhodné, aby tyto prostředky byly použity pro plnění pouze jedné služby, případně, aby byly použity pro plnění pouze jedním subjektem (pouze poskytovatelem, pouze jedním autonomním procesem apod.).

 

Tato problematika se týká hlavně prostředků informatických, jejichž řízení chceme informatiku podniku zbavit a přenést jej na poskytovatele. Nesmíme ale odhlédnout ani od ostatních zdrojů, jako jsou například budovy (kancelářské prostory, úložná plocha), elektrická energie atd. I využití takových zdrojů by mělo být zahrnuto v předmětu a ceně služby. Pokud tedy poskytovatel použije při plnění služeb elektrickou energii, prostory podniku jako kanceláře pro své pracovníky nebo úložné prostory pro své zařízení a podobně, měl by za to podniku přiměřeně zaplatit.

 

V našem modelu distribuujeme řízení informatiky na procesy a z hlediska služeb se k nim chováme obdobně jako k externím poskytovatelům. Proto je tedy pohled vlastnictví prostředků významný i z pohledu interních procesů zajišťujících informatické služby. Uvedenou problematiku můžeme na interní procesy použít analogicky, z cenového pohledu ovšem na úrovni kontrolingu podniku a interního přeúčtování nákladů – vnitřních ekonomických vztahů. Veškeré prostředky potřebné pro zajištění služby procesu jsou zahrnuty v předmětu a ceně služby. Potřebné prostředky IS/IT a jiné zdroje tedy interní autonomní proces musí v rámci podniku „nakoupit“.

Pokud tento princip nebude dodržen, nezjistí vedení informatiky přesně náklady na poskytnutí služby a nebude mít dostatek podkladů pro rozhodování o outsourcingu. Bohužel ne vždy lze tento princip udržet. Může to být příliš nákladné nebo i nerealizovatelné, ale pokud je tento princip někde porušen (například procesy nenakupují elektrickou energii jako zdroj), je nutné stavět se k tomuto porušení jako ke skrytým nákladům a při rozhodování o outsourcingu a při kontrolingu k nim přihlédnout.[35]

 

Dalším aspektem vlastnictví prostředků, který zde zmíníme, je nutnost správy a evidence tohoto majetku. Pokud je z nějakých důvodů nutné, aby prostředky byly majetkem podniku, je nutné je spravovat a evidovat. Pokud je takových prostředků velké množství, nemusí tato nutnost korespondovat se zájmy informatiky zbavit se starosti o službu a tedy i o prostředky pro její zajištění. V takovém případě je možné zavázat poskytovatele kromě poskytování služby ještě ke správě a evidenci prostředků, a případně i k jejich nákupu (do majetku podniku).

 

Příklad: Uveďme tři možné způsoby specifikace předmětu při poskytování infrastrukturní služby „koncové stanice PC“ poskytovatelem z hlediska vlastnictví majetku:

a)       předmětem služby je zajistit uživateli stanici PC v parametrech, které jsou podstatné po možný běh aplikací, které bude uživatel používat, a to za paušální cenu určenou za jednu koncovou stanici. Poskytovatel zcela odpovídá za to, jaké konkrétní počítače, monitory a tiskárny nakoupí. Z hlediska podniku je podstatné pouze to, aby na nich bylo možné poskytovat určité konkrétní aplikační služby;

b)      předmětem služby je zajišťovat totéž, jako v případě a, ale koncové stanice jsou z důvodu využití podnikových investičních prostředků nakupovány do majetku podniku. Předmět služby je definován obdobně jako v případě a, a vedle toho je sjednána další služba nazvaná například „nákup a evidence PC“, jejímž předmětem je nakupovat výhodně zařízení do majetku podniku a vést o něm evidenci pro podklady účetnictví a pro podklady poskytování služby „koncové stanice PC“. Tato služba je mandátního charakteru a můžeme ji typově zařadit mezi služby řízení informatických zdrojů. Vedle toho je specifikována dohoda o pronájmu nakoupených prostředků poskytovatelem, a to za tím účelem, aby je mohl použít pro poskytování služby „koncové stanice PC“;

c)       koncové stanice jsou, podobně jako ve variantě b, nakupovány do majetku podniku. Předmětem služby ale není poskytování služby „koncové stanice PC“ uživateli tak, aby mohl používat určité aplikace. Takovou službu poskytuje uživateli informatika podniková. Předmětem služby poskytovatele je zajistit nákup, evidenci, instalaci, správu a údržbu zařízení koncových stanic. Tyto prostředky jsou majetkem podniku a poskytovatel si je nepronajímá a v jeho službách tedy nejsou cenově zakalkulovány, ale poskytuje pouze činnosti, které s jejich provozováním souvisejí. Z ceny služeb poskytovatele tedy není zřejmé, jaká je celková cena jednoho koncového pracoviště PC. Nejedná se tedy o outsourcing koncových stanic PC, ale pouze o outsourcing správy koncových stanic.

Obecně je z hlediska řízení vztahu a transakčních nákladů nejvhodnější variantou a. Pokud je nutné vlastnictví prostředků ponechat na podniku, preferujeme obecně variantu b, ale vzhledem k tomu, že zde se jedná o infrastrukturní službu, jejíž technologická specifikace je velmi podobná specifikaci věcné-zákaznické, je patrně v takové situaci vhodnou variantou c.

 

Dalším důležitým aspektem z hlediska vlastnictví je riziko, které se ovšem také projeví v ceně služeb. Pokud prostředky vlastní poskytovatel, tyto prostředky jsou poškozeny a důsledkem toho je neplnění služby, pak nese riziko poskytovatel, pokud je vlastní podnik, nese riziko podnik.

 

Situaci, kdy externí poskytovatel odpovídá za poskytnutí služby a prostředky pro její zajištění potřebné jsou v majetku podniku, však považujme za speciální a výjimečnou. Pokud tomu tak je, vždy to znamená nutnost řídit další transakce, dodatečné náklady a hlavně starost na straně podniku, a tedy určitá eliminace výhod outsourcingu. Proto, pokud je to možné, je vhodné zbavit se co nejvíce prostředků, které outsourcovaný proces používá.

8       Měření služeb IS a jejich efektů

V předchozím textu jsme analyzovali a konstruovali problematiku přání a služeb vždy s ohledem na kontrolovatelnost a měřitelnost. V této kapitole se zaměříme na principy, které lze využít při měření služeb informatiky, a uvedeme, jaké parametry a jakým způsobem je účelné měřit.

Po úvodu do problematiky postupně uvedeme podrobněji problematiku měření efektů informačního systému, problematiku měření aplikačních služeb a na závěr krátce problematiku měření zdrojů.[36]

 

Problematiku měření služeb informatiky můžeme shrnout do několika problematických okruhů:

·          měření efektů,

·          měření možnosti plnění potřeby informatickou službou,

·          měření skutečného plnění potřeby,

·          měření ostatních efektů,

·          měření služeb,

·          měření objemových a kvalitativních parametrů služeb,

·          měření zdrojů,

·          měření parametrů a systémových vlastností informačního systému,

·          měření lidských zdrojů.

 

Měření zdrojů by mělo být navázáno na měření služeb a to by mělo být navázáno na měření efektů. Tím zajistíme kontinuitu řetězce plnění potřeb.

 

obr. 20,  Měření služeb IS a jejich efektů

 

Zde se v návaznosti na předchozí kapitoly zaměříme na měření potřeb a měření služeb. Měření zdrojů zmíníme také, ale podrobně se jím zabývat nebudeme. Jedná se zejména o složitou oblast měření technologických parametrů zejména hardware a software. Tato oblast je pro implementaci a provoz informačního systému důležitá, ale z hlediska řízení podnikové informatiky v modelu CIO jako IT broker a z hlediska problematiky služeb informatiky se jedná o oblast příliš podrobnou a příliš technologickou. Některé technologické parametry a vlastnosti informačního systému ale mohou být podstatné pro měření služeb nebo efektů.

 

Problematika měření služeb je často reprezentována pojmem „metriky“, který zahrnuje měření parametrů služeb a v některých případech i měření plnění potřeb zákazníka.

Zde budeme používat následující pojmy:

metrika – měřitelná veličina,

parametr – kvantitativní nebo kvantifikovaná veličina,

ukazatel – měřený parametr služby,

hodnota parametru, hodnota ukazatele – konkrétní specifikované nebo naměřené hodnoty parametru nebo ukazatele,

kvalitativní parametr služby – pojem kvalitativní zde znamená skutečnost, že se jedná o jakost služby, nikoli o skutečnost, že sám parametr není kvantitativní.

(Pozn.: Někdy se pojem metrika používá pro ukazatel, který je použit při výpočtu ceny služby.)

 

Problematika měření je spjata s problematikou kvantifikace. Většina parametrů služeb však jsou kvantitativní ze své podstaty, kterou zde můžeme vidět v informačních technologiích, principiálně založených na výpočtech. Zejména problematika možnosti plnění potřeb, ale i některé aspekty samotných služeb, však nejsou ze své podstaty kvantitativní. U případů, kterých se to týká, tedy zmíníme možnost a smysluplnost jejich kvantifikace.

V mnoha případech jsou metriky, ať už jakostní nebo objemové ukazatele nebo metriky potřeb, promítány do ceny služeb. Pokud toto promítnutí má být provedeno výpočtem, je nutné, aby se jednalo o ukazatele nebo metriky číselné (tedy kvantitativní nebo kvantifikované).

 

Hned v úvodu musíme uvést důležitý základní princip měření informatických služeb, a to princip prokazatelnosti. Veškerá měření služeb musí být konstruována a prováděna tak, aby bylo výsledné měření nezpochybnitelné. To je nutné zejména v případě, kdy se jedná o výši ceny za poskytnuté služby, a kdy tedy jde o peníze. To, zda služba byla poskytnuta v dostatečné jakosti, zda bylo možné pomocí informačního systému splnit přání tak, jak je to v předmětu služby definováno, zda bylo dosaženo splnění potřeby, vše toto musí být zřetelné a oběma stranám nepochybné, a pokud to někdo přesto zpochybní, musí to být prokazatelné.

Tento princip je nutné mít na paměti od počátku konstrukce metrik pro konkrétní službu až po každé skutečné provádění měření jednotlivých metrik. V oblasti informatiky toto zachovat není vždy jednoduché, a proto je problematika měření podstatnou součástí problematiky informatických služeb.

 

8.1    Měření efektů

Jak již bylo několikrát výše zdůrazněno, zákazník používá informatické služby ne jen tak, ale proto, aby mu přinesly nějaký efekt, aby splnily nějakou potřebu nebo přání. Zde uvedeme, jakým způsobem lze měřit, zda informatická služba skutečně splnila nebo mohla splnit potřebu. Vedle plnění potřeb má informační systém i jiné efekty, některé pozitivní, některé negativní. Dále tedy uvedeme, jakým způsobem lze přistoupit k tomuto problému.

 

Nejprve se podíváme na měření možnosti plnění potřeby informatickou službou a měření skutečného plnění potřeby.[37]

Chceme-li měřit plnění potřeb, musíme definovat míru plnění potřeby. Tato míra bude specifikací potřeby.

Příklad typologie potřeb jsme uvedli v kapitole Řízení požadavků a změn v informatice. Zde ji pro přehlednost uvedeme znovu:

z hlediska jiných procesů:

·          Zvýší rychlost průběhu procesu

·          Zvýší kapacitní parametry procesu

·          Zvýší pružnost změn procesu

·          Sníží náklady procesu

·          Sníží nároky procesu na zdroje

·          Zvýší možnost kontroly procesu

·          Sníží riziko aktivit v procesu

·          Umožní určité aktivity nebo způsob průběhu procesu

 

z hlediska řízení podniku:

·          Podpoří cíl podniku

·          Zvýší operabilitu při hledání podnikatelských příležitostí

·          Zvýší možnost kontroly podniku

·          Sníží náklady (zefektivní využití zdrojů)

·          Sníží riziko

 

Jak je zřejmé, některé z těchto možných potřeb jsou nebo mohou být kvantitativní (například rychlost průběhu procesu, náklady procesu, …). Mnohé ostatní ale kvantitativní nejsou a o jejich kvantifikovatelnosti lze vést dlouhé diskuse. To se týká například pružnosti změn procesu, podpory cíle podniku, operability při hledání podnikatelských příležitostí atd.

 

Je-li to možné, je vhodné najít číselnou veličinu, která potřebu bude smysluplně reprezentovat. Pokud se takové řešení nenajde, je možné míru plnění přání určit jiným způsobem. Vhodným způsobem je tzv. auditní míra.

 

Auditní přístup předpokládá, že skutečnost, zda a do jaké míry bylo přání splněno, není nutné objektivně měřit (a je lhostejno, zda to je možné nebo není), ale určité odpovědné osoby jsou schopny tuto skutečnost rozpoznat a určit, a tedy je možné změřit plnění přání jejich prostřednictvím. Těmito osobami budou v našem případě patrně odpovědný zástupce zákazníka, odpovědný zástupce poskytovatele a odpovědný zástupce vedení informatiky podniku.

 

Měření v takovém případě může probíhat tak, že se sejde určená komise osob, která bude jednat o otázce, zda byla potřeba splněna, a shodnou se na závěru, nejlépe na jedné z možností, které byly jako možné výsledky měření předem určeny.

 

I auditní měření musí být nezpochybnitelné a prokazatelné. To znamená, že je nutné předem specifikovat podstatné parametry auditu. Jsou to:

·          místo a doba auditu nebo způsob jejich určení,

·          osoby, které se auditu zúčastní, nebo způsob jejich určení,

·          otázka, která bude předmětem auditu,

·          možné varianty odpovědí na otázku, ze kterých má být vybráno,

·          forma výstupu a způsob ověření výsledku auditu a jeho uložení.

 

V případě, že se auditním způsobem měří splnění přání, to znamená, že přání je definováno jako požadovaný stav. Při sjednávání předmětu služby bude sjednáno, že míra splnění přání bude určena auditně, a to jako odpověď na otázku, zda bylo požadovaného stavu dosaženo. Dále budou specifikovány možné odpovědi na tuto otázku, které budou (patrně kvalitativně) vystihovat možné budoucí stavy. Výsledkem auditu bude výběr jedné z těchto variant.

 

Příklad:

Dosavadní informační systém počítá s neměnným průběhem procesu vyřízení objednávky. Potřebou zákazníka je mít možnost proces vyřízení objednávky operativně měnit na základě měnícího se prostředí. Požadavkem na informatiku je umožnit operativní změny procesu za jinak shodné funkcionality informačního systému, který podporuje vyřízení objednávky.

Požadovaný stav je tedy definován. Možnost měnit proces je kvantifikovatelná obtížně. Proto bylo zvoleno auditní hodnocení výsledku, a to s otázkou:

·          Umožňuje informační systém zákazníkovi snadno měnit průběh proces vyřízení objednávky?

Dále byly specifikovány možné odpovědi na tuto otázku:

·          Ano, při změně je informační systém vhodně nápomocen,

·          Ano, při změně informační systém nepřekáží,

·          Ano, při změně informační systém způsobuje drobné problémy nebo zdržení,

·          Ne, při změně informační systém způsobuje podstatné problémy nebo zdržení,

·          Ne, změny nejsou v důsledku informačního systému možné.

Dále bylo určeno, že toto hodnocení proběhne po uvedení informačního systému do provozu (tj. po začátku poskytování služby) vždy v půlročním intervalu (k určitému datu). Auditu se zúčastní jedna osoba určená poskytovatelem, jedna osoba za vedení informatiky a jedna osoba za zákazníka. Všichni účastníci se musí na výsledku shodnout jednomyslně. Dále je specifikováno v obecných zásadách smluvního vztahu mezi poskytovatelem a zákazníkem, jakým způsobem se postupuje v případě, že nedojde k dohodě.

Dále je specifikováno, že o auditním rozhodnutí sepíší účastníci zápis. Jakmile je zápis o rozhodnutí sepsán, je možné opět podle specifikovaných pravidel přistoupit k zaplacení části ceny, která byla vázána na splnění této potřeby, a to ve výši podle výsledku auditu, případně k penále, byl-li výsledek negativní.

 

Auditní metriky jsou použitelné také pro měření toho, zda informatická služba, resp. aplikační funkcionalita informačního systému umožňuje splnění přání zákazníka, bez ohledu na to, zda přání bylo skutečně splněno nebo ne, a na to, zda bylo přání splněno vlivem informatické služby nebo z důvodů jiných vlivů.

 

Příklad:

Zákazník chce zkrátit dobu vyřízení objednávky z dvaceti na dva dny. Externí poskytovatel nabízí informační systém, který to umožní. Zákazník ve spolupráci s informatikou se rozhodnou, že budou od tohoto poskytovatele nakupovat informatickou službu, která jim umožní využít funkcionalitu informačního systému tak, aby ke zkrácení vyřízení doby objednávky skutečně došlo. Informatická služba je specifikována:

·          potřebou: snížit průměrnou dobu vyřízení objednávky na dva dny – to je kvantitativní snadno měřitelný parametr podporovaného procesu,

·          aplikační funkcionalitou informačního systému,

·          logickou spojitostí mezi aplikační funkcionalitou a splněním přání.

Podmínky splnění přání byly specifikovány následovně:

·          Aplikační funkcionalita optimalizuje tok dokumentu objednávky v podniku.

·          Organizace procesu bude upravena, aby vyhovovala návrhu (který je již znám z úvodní studie).

·          Uživatelé služby budou vyškoleni k správnému a efektivnímu užití služby.

·          Schvalovací místo pro objednávky bude reagovat průměrně do dvou hodin.

·          Kapacita výroby a skladu budou takové, aby reagovaly na požadavek na zboží do šesti hodin.

·          Počet objednávek bude maximálně 500 denně.

·          Pak bude průměrná doba vyřízení objednávky zkrácena na 2 dny.

Opět bylo specifikováno auditní měření, tentokráte s otázkou:

·          Umožnila informatická služba, aby došlo ke zkrácení průměrné doby vyřízení objednávky na dva dny?

V případě, že ke zkrácení průměrné doby vyřízení objednávky nedošlo, je nutné zvážit, zda byly splněny všechny uvedené podmínky. Pokud byly všechny splněny, pak patrně nebyl závazek poskytovatele splněn, protože aplikační funkcionalita spolu se splněním všech podmínek nezajistila zkrácení doby objednávky.

V případě, že ke zkrácení doby objednávky došlo, je nutné zvážit, zda skutečně došlo k plnění služby a k optimalizaci toku dokumentu prostřednictvím aplikační funkcionality. Pokud ano, pak je smysluplné se domnívat, že informatická služba je umožnila. Pokud ne, pak je naopak smysluplné domnívat se, že ke zkrácení došlo v důsledku jiného vlivu a že informatická služba je neumožnila.

Z tohoto hlediska komise při auditním měření rozhodne, a podle výsledku je opět možné přistoupit k zaplacení složky ceny vázané na umožnění plnění potřeby.

 

Tato dvě hlediska, tedy samotné přání na jedné straně a podmínky jeho splnění na druhé, je vhodné při specifikaci předmětu služby odlišit. Při měření výsledného efektu informatické služby je však možné tyto dva pohledy sloučit do jednoho auditního měření, které vezme v úvahu i skutečnost, zda bylo přání splněno, i skutečnost, zda to bylo nebo mohlo být splněno následkem poskytnutí informatické služby.

 

Měření přání i možnosti jeho splnění je v případě služeb informatiky vhodné definovat jako měření průběžné nebo periodické. Poskytování služeb má totiž také průběžný charakter. Pokud by bylo přání a měření jeho dosažení jednorázové, mohlo by to poskytovatele demotivovat k jeho plnění v budoucnu (například pokud by ve výše uvedeném příkladě byla možnost měnit proces vyřízení objednávky měřena jednorázově, pak by mohl poskytovatel tuto možnost demonstrovat pouze při prvním měření, a při dalších by například již při změně neměl zájem zákazníka na svůj účet účinně podpořit).

Jiná situace je v případě dodávky informačních systémů „na klíč“ určených pro provozování jiným subjektem než dodavatelem. Pak je možné plnění potřeby měřit a dodavatele hodnotit jen jednorázově nebo v omezeném čase po dodávce systému, protože poté již nemá dodavatel možnost plnění přání nijak ovlivnit. Takovou situací se však zde nezabýváme.

 

Z hlediska měření efektů je nutné zvážit také ostatní efekty, než je splnění přání. Pokud jde o pozitivní efekty, je vhodné o nich vědět, ale pokud zároveň nejsou definovanými potřebami v předmětu služby, není vhodné za ně platit. Co se týče negativních efektů, opět je vhodné o nich vědět, a nejsou-li v předmětu smlouvy (patrně v části souvislosti mezi funkcionalitou a přáním) definovány jako efekty sice negativní, ale očekávané a akceptované, je vhodné za ně poskytovatele buď penalizovat, nebo uplatnit náhradu škody, je-li takovým efektem škoda.

 

Určovat a měřit vznik neočekávaných efektů opět není úlohou s exaktním řešením. Nejvhodnější situací je, když většina efektů je očekávána.[38] Čím více neočekávaných efektů se při poskytování informatické služby dostaví, tím větší neodbornost a nezkušenost lze informatice přičítat. Pokud neočekávané efekty plynou ze samotné informatické služby a jejího technologického zajištění, svědčí to o neodbornosti, nezkušenosti a nezodpovědnosti poskytovatele, pokud se jedná o efekty (zde zejména negativní) plynoucí z řízení vztahů s poskytovateli, lze zmíněné vlastnosti přičíst vedení podnikové informatiky.

U neočekávaných efektů lze jejich souvislost se službou informatiky obvykle určit pouze v případě, že někoho napadne, že tato souvislost existuje. Pokud se tak stane, je opět vhodnou formou jejího ověření expertní audit, tedy posouzení odborných pracovníků, zda daný efekt a do jaké míry je důsledkem informatické služby v podniku.

 

Zde apelujeme na to, aby efekty byly jako potřeby, případně jako nutné podmínky vedoucí ke splnění potřeb, identifikovány předem a specifikovány jako součást předmětu informatických služeb právě proto, aby existovalo závazné měřítko a možnost srovnání, které efekty byly požadované a očekávané a které nikoliv.

 

Již jsme uvedli, jaké typy přání mohou být na informatickou službu definovány. Dále uvedeme, jaké negativní efekty může informatická služba mít a jaké je tedy vhodné před jejím poskytováním posoudit. Nejtíživějšími jsou:

·          zvýšení nákladů procesu (podniku), nebezpečí, že cena zajištění služby bude dlouhodobě vysoká,

·          zamezení operativním změnám v procesu (podniku), rigidita – informační systém nebude schopen kopírovat operativní změny v procesu,

·          zvýšení určitých rizik.

 

Rizikový efekt, tedy zvýšení či snížení rizik, případně vznik nových rizik je vhodné jako efekt konfrontovat a řídit v rámci a z hlediska celkového řízení bezpečnosti a rizik podniku. Pro úplnost uvedeme, že rizikový aspekt spojený s realizací služby externím dodavatelem lze účinně zmírnit pojištěním odpovědnosti za škodu. Cena tohoto pojištění může být brána jako měřítko cenového ohodnocení rizika vzniku škody.

 

Aby se nepřerušil řetězec souvislostí při řízení prostřednictvím přání, je potřeba míru očekávaných efektů (míru splnění potřeby) transformovat do míry plnění služby (jako aplikační funkcionality), a míry aplikační funkcionality dále transformovat do míry alokace a využití zdrojů.

 

Přínosy informatické služby se prostřednictvím produktů podporovaných procesů promítnou do přínosu pro zákazníka podniku, což se patrně promítne (v závislosti na obchodní podnikové strategii) ve výši obratu, případně zisku podniku. Z tohoto promítnutí (skutečného nebo plánovaného) lze usuzovat na vhodnou cenu informatických služeb v poměru k jejich přínosům a určovat, zda efekty za danou cenu stojí nebo ne.

Pokud by informační systém byl realizován formou investice, lze jeho přínos tedy hodnotit jako návratnost této investice. Řešení informatiky jako externích služeb má v sobě výhodu v možnosti považovat služby za trvalé a průběžné, a tedy v možnosti brát náklady jako běžné, neinvestiční náklady jednotlivých procesů, a v návaznosti na to také lépe hodnotit jejich přínos. Pokud je informatická služba zajišťována interním informatickým procesem a investice do informačního systému v podniku je přesto skutečně podnikem realizována, přispěje pohled služeb k podrobné alokaci nákladů a přínosů této investice na jednotlivé procesy (nebo jiné vnitřní ekonomické jednotky) podniku.

8.2    Měření služeb

Problematika měření služby zahrnuje měření toho, zda je, tak jak je sjednáno, plněn předmět služby, zde v případě aplikačních služeb ta část, která se týká aplikační funkcionality.

Aby bylo možné určit, zda je služba plněna tak, jak je sjednáno, nebo ne, je nutné velmi přesně definovat předmět služby. To jsme popsali v kapitole Předmět aplikačních služeb. Popsali jsme hrubě obsah dohody o úrovni služeb, tzv. Service Level Agreement, jako:

·          předmět služby,

·          významné objemové a kvalitativní parametry služby,

·          způsob měření a předávání ukazatelů těchto parametrů,

·          cena služby, závislá na metrikách.

 

Pro měření plnění aplikační funkcionality jsou tedy podstatné objemové a kvalitativní parametry této funkcionality.

Podstatné je, že tyto parametry a způsob jejich měření a vzájemného předávání a prokazování výsledků těchto měření je opět nutné sjednat již při definici předmětu služby.

 

Objemové parametry charakterizují službu v jejím rozsahu. Mohou tedy popisovat otázky:

·          v jakém rozsahu službu lze poskytovat,

·          v jakém rozsahu byla služba skutečně poskytnuta (využita),

·          alespoň/maximálně v jakém rozsahu služba musí být poskytnuta,

·          atd.

 

Kvalitativní parametry charakterizují službu v její jakosti. Ty mohou popisovat otázky:

·          jak dobře lze službu poskytovat,

·          jak dobře byla služba skutečně poskytnuta,

·          alespoň jak dobře musí být služba poskytnuta,

·          atd.

 

Z hlediska měření je nutné specifikovat předmět služby a jeho měřitelnost tak, aby měření mohlo v budoucnu probíhat hladce, s rozumnými náklady a hlavně prokazatelně a nepochybně. Zde upřesníme, co je vhodné specifikovat při definici předmětu služby z tohoto pohledu. Jsou to:

·          jednotlivé kvalitativní a kvantitativní parametry,

·          způsob jejich měření, prokazování a předávání výsledků,

·          rozsah, v jakém se mohou pohybovat požadavky zákazníka na tyto parametry,

·          standardní úroveň parametrů, kterou musí poskytovatel zajistit,

·          kritická mez parametrů, jejíž dosažení znamená pro zákazníka vznik škody.

 

Následně, během poskytování služby pak mohou být jednotlivé ukazatele parametrů měřeny a hodnoceny. Měřit lze parametry v těchto polohách:

·          jaká hodnota parametru byla pro období plánována,

·          jaká hodnota parametru byla v období zákazníkem požadována,

·          jakou hodnotu bylo v období možné poskytnout,

·          jaká hodnota parametru byla v období poskytovatelem skutečně poskytnuta.

 

Na základě těchto naměřených ukazatelů je možné určit, zda byl předmět služby splněn, případně je možné vypočítat cenu, která je závislá na naměřených parametrech. Pro tyto specifikované možnosti je nutné sjednat (nejlépe obecná) pravidla, která budou aplikována při hodnocení plnění a výpočtu ceny.

Můžeme zde zmínit příklad základních pravidel, kdy je možné službu považovat za splněnou:

·          Zákazník požaduje parametr v standardním rozsahu a služba je poskytovatelem poskytnuta v požadovaném rozsahu.

·          Zákazník požaduje parametr mimo standardní rozsah a služba je poskytnuta tak, že hodnota ukazatele skutečného poskytnutí je v intervalu mezi hranicí intervalu standardního poskytování služeb a požadovanou hodnotou.

Služba naopak není splněná zejména když:

·          Zákazník požaduje hodnotu parametru v rámci standardního intervalu nebo horší, a skutečně poskytnutá hodnota parametru je horší než je požadovaná hodnota.

 

V pravidlech v příkladu je používán termín „horší“ hodnota parametru. Definice pravidel by měla být důsledná, a pokud jsou pravidla definována podobným způsobem, je nutné u parametrů, kterých se to týká, rovněž specifikovat, které hodnoty jsou lepší a které horší. Pravidla musí totiž napomoci nezpochybnitelnosti a určitosti určení plnění a ceny služby, a i taková drobnost může být později při poskytování služeb zdrojem nedorozumění, a to zvláště v případě, kdy dojde k nedostatečnému plnění a z toho plynoucím sporům, kdy mohou zcela jiní lidé, než kteří vytvářeli předmět služby a vztah poskytovatele a zákazníka, hledat v definici předmětu služby různé kličky a únikové cesty.

 

V případě měření služeb lze opět použít auditní způsob měření, a to obdobným způsobem, jako v případě měření efektů. Měření služeb však je již mnohem snazší realizovat kvantitativně a automatizovaně jako přímý výstup (vedlejší produkt) informačního systému. Automatizované získávání hodnot ukazatelů je pro průběžné nebo každý měsíc opakované měření vhodnější, zejména proto, že je méně nákladné než měření auditní. I v případě automatizovaného měření ukazatelů je nutné zajistit prokazatelnost a nepochybnost jejich hodnot, a tedy určit všechny aspekty, které mohou výsledek měření ovlivnit.

 

Dále se podíváme na některé parametry služeb podrobněji.

 

Aplikační funkcionalita informačního systému je cestou ke splnění potřeby, a tedy měření služby musí být v souvislosti s jejím efektem (splněním potřeby).

Z toho plyne, že parametry, jakými je vhodné měřit poskytování služby, lze odvodit od způsobu měření efektu, tedy plnění potřeby a možnosti jejího plnění.

 

Například v případě potřeby zkrátit dobu vyřízení objednávky je vhodné měřit ukazatele informačního systému, které mají vliv na rychlost průběhu objednávky v informačním systému procesu.

 

Takové konkrétní ukazatele je nutné najít speciálně v každém jednotlivém případě podle typu potřeby, kterou má služba splnit. Kromě těchto ukazatelů však je vhodné měřit některé parametry informatických služeb obecně. Jsou to parametry, které souvisejí se splněním přání téměř vždy, protože hodnotí možnost užití aplikační funkcionality obecně.

 

Těmito parametry jsou:

·          počet uživatelů služby,

·          uživatelská dostupnost služby,

·          doba odezvy.

 

Počet uživatelů služby je základní objemový parametr (víceuživatelské) služby. U počtu uživatelů služby je nutné, podobně jako u softwarových licencí, rozlišit

·          počet současně pracujících uživatelů (kolik uživatelů může najednou využívat službu),

·          počet jmenovitých uživatelů (kolik uživatelů celkem – určených jejich jmény – může využít službu).

To jsou dva rozdílné parametry služby. Je tedy nutné specifikovat, který je v daném případě použit. Pokud to není specifikováno, je smysluplné předpokládat, že všichni jmenovití uživatelé mohou současně službu užívat.

Protože se jedná o objemový ukazatel řízený zákazníkem, je dále nutné odlišit:

·          kolik uživatelů služby požaduje zákazník,

·          kolik uživatelů služby umožňuje poskytovatel.

Z cenových důvodů se zákazník může zavázat k určitému minimálnímu počtu uživatelů služby v každém období. Naopak poskytovatel se zavazuje poskytovat službu alespoň určitému počtu uživatelů. Tyto dvě hodnoty pak tvoří standardní interval tohoto parametru.

 

Uživatelská dostupnost služby je speciální kvalitativní parametr, který definuje, jakou část celkového času bude služba uživateli dostupná. Určuje se

·          časovou specifikací celkového času (např. po-pá 03:00-23:00, so 03:00-18:00),

·          procentním určením dostupnosti z tohoto celkového času (např. 98%).

Uživatelská dostupnost služby nemůže být sjednána pouze na základě obchodního jednání, ale musí být určena na základě spolehlivosti jednotlivých komponent a služeb, ze kterých jsou informační systém a výsledná služba složeny. (Pokud je například spolehlivost počítače, na kterém běží aplikace, 99,9%, spolehlivost operačního systému 99% a spolehlivost aplikace 99,9%, nemůže být sjednána uživatelská dostupnost služby větší než 0,999x0,99x0,999= 98,8%, pokud nejsou některé z komponent zálohovány.)

Při určování uživatelské dostupnosti je nutné vyjít z potřeb zákaznického procesu. Požadovaná dostupnost totiž má značný vliv na cenu služby.

 

obr. 21,  Cena dostupnosti služeb IS

 

Při sjednávání dostupnosti je také nutné specifikovat způsob měření nedostupnosti. Bude nedostupnost měřit sám informační systém nebo bude měřena auditně? Bude-li měřena auditně, jak se bude určovat čas skutečné nedostupnosti služby?

Dostupnost také může v různých případech znamenat různou věc. Službu je možné považovat za nedostupnou:

·          v případě, že ji nelze vůbec užívat,

·          v případě, že není poskytována ve standardní hodnotě všech sjednaných ukazatelů (tj. lze ji užívat, ale ne v plném rozsahu, tak jak bylo sjednáno),

·          v situaci někde mezi těmito extrémními případy.

Interpretace pojmu dostupnosti je pro sjednávání tohoto parametru ale i všech ostatních kritickým místem poskytování informatické služby.

Dostupnost je zpravidla určena pro službu vždy jen jednou, při jejím zavádění, a pokud zákazník chce změnit tento parametr později, jedná se o změnu, která může být nákladná.

 

V souvislosti s dostupností zmíníme také parametr reakční doba. Reakční doba je doba, která uplyne od předání požadavku nebo zprávy o havárii na callcentrum (nebo jiné sjednané místo) do doby, kdy poskytovatel na tuto zprávu nějak zareaguje (vyrozumí uživatele o řešení, vyřeší problém, …). Tento parametr je vhodný u služeb, u kterých poskytovatel není odpovědný za výsledek. Typickým příkladem je externím poskytovatelem poskytovaná služba uživatelská podpora a údržba aplikace, kdy software je majetkem zákazníka. Pro služby typu outsourcing je reakční doba také použitelná, ale v některých případech je zbytečná. Pokud například dodavatel odpovídá za dostupnost systému 99%, pak je v jeho zájmu, aby tuto dostupnost skutečně poskytl a dostal zaplaceno v plné výši, a je tedy v jeho zájmu i reagovat na hlášení poruchy co nejdříve.

 

Doba odezvy je dalším významným kvalitativním parametrem aplikační informatické služby. Zpravidla se jedná o dobu odezvy transakce (což ovšem v předmětu služby musí být definováno), tedy dobu odezvy od okamžiku, kdy uživatel předá systému požadavek na informaci, do okamžiku, kdy mu je zobrazena odpověď systému na obrazovce koncové stanice (terminálu).

Tento parametr je definován zejména proto, aby informační systém nezdržoval uživatele od práce příliš dlouhou odezvou. U centralizovaných a klient-server aplikací se ustálil standard 3 sekundy doby odezvy transakce. Internetové aplikace tento dobrý standard ruší a dobu odezvy prodlužují, a často ji dokonce nemohou garantovat vůbec, což je dáno technologií současného Internetu. Zatímco uživatel mainframe si mohl odpočinout při čekání na reakci počítače jedním mrknutím, uživatel aplikace internetové se může několikrát otočit na židli.

Doba odezvy je obvykle definována obecně pro všechny transakce s tím, že je určeno několik málo typických testovacích transakcí, které měří dobu odezvy tak, aby odrážely skutečnou obvyklou odezvu informačního systému.

 

Pro konkrétní služby je možné sjednat mnoho dalších parametrů. Jak bylo již několikrát výše řečeno, je velmi vhodné, aby tyto parametry byly sjednávány v jazyce a věcné oblasti zákazníka (např. počet účetních položek), nikoliv jako technické parametry informačního systému (např. objem dat).

 

Provést měření ukazatelů služby může být závazkem poskytovatele jako součást služby. Jsou-li ukazatele měřeny automatizovaně, je poskytovatel odpovědný za správnost jejich změření stejně jako za správnost zpracování zákazníkových dat. Formální předání změřených ukazatelů za dané období může být v případě externího poskytování služby podmínkou pro fakturaci služby za dané období.

8.3    Měření zdrojů

Měřené podstatné charakteristiky informatických služeb je nutné promítnout do měření zdrojů, použitých pro plnění těchto služeb. V tomto případě se jedná o interní záležitost autonomních procesů, které službu zajišťují, případně externích poskytovatelů. Měření je nutné zajistit jednak proto, aby bylo možné alokovat náklady na poskytnutí služby a tedy je plánovat a určit cenu služby, a dále proto, aby bylo možné aplikovat řízení prostřednictvím zájmů i na zdroje procesu zajišťujícího službu, tedy na pracovníky.

Z hlediska hardware a software existují exaktní způsoby míry jejich využití přímo v informačním systému, obvykle jako jeho vedlejší produkt. Pokud při tvorbě informačního systému (tedy u zastaralých IS) nebylo počítáno s měřením jeho technologických zdrojů, je i zde možné použít měření auditní.

Z hlediska pracovníků patrně není v případě informatiky vhodnějšího způsobu než kontroling podle činností. U pracovníků lze měřit jednak jejich kvalifikaci a jednak čas, který strávili na které činnosti. Při plnění informatické služby je tedy vhodné definovat kvalifikační kategorie pracovníků, kategorie možných činností, a požadovat po pracovnících, aby každou část svého pracovního času alokovali na konkrétní činnost, a to pro konkrétního zákazníka (proces, útvar, uživatele) a pro konkrétní službu.

Takové měření zdrojů dává možnost pracovníky v informatice vůbec řídit a zároveň je i motivovat, aby jejich zájmy byly v souladu s plněním služby ve sjednaných parametrech.

Jakým způsobem to dělat již není předmětem tohoto textu.

9       Závěry

Podívali jsme se zde na některé významné trendy informačních technologií a na trendy trhu služeb informačních systémů. Tento světový tlak jsme promítli do řízení podnikové informatiky, aby bylo možné informatiku řídit v modelu operativního outsourcingu tak, aby to bylo pro podnik jako celek přínosné. Určili jsme kompetence podnikové informatiky. Pro specifikaci podmínek jsme zvolili procesní pohled na podnik, řízení prostřednictvím zájmů a distribucí řízení na procesy. Vyšli jsme z potřeb podniku a specifikovali jsme podstatné aspekty řízení požadavků na informatiku podniku a řízení změn v informatice. Zavedli jsme nový celostní pohled na informatiku, pohled služeb informatiky, a specifikovali jeho principy. Definovali jsme architekturu služeb informatiky a zaměřili se na služby informatiky orientované na vnitřního zákazníka v podniku, tedy na služby aplikační. Vymezili jsme pohled na informatiku, který považujeme z hlediska problematiky řízení za možného outsourcingu podstatný. Ukázali jsme, jaké faktory jsou podstatné při sjednávání předmětu a ceny služeb z primárního pohledu řízení podnikové informatiky a z hlediska zákazníka informatických služeb. Popsali jsme jednoduchý model jako nástroj pro řízení služeb a zdrojů informatiky a zmínili jsme zvláštní aspekty vlastnictví prostředků při outsourcingu informatiky. Problematiku jsme uzavřeli popisem použitelných způsobů měření efektů, možných efektů a parametrů služeb informatiky, a částečně i informatických zdrojů. Tím bylo cílů práce dosaženo.

 

Řízení informatiky prostřednictvím služeb považujeme za velmi silný nástroj řízení podnikové informatiky, který v měnícím se prostředí umožňuje informatiku podniku řídit operativně i tam, kde jak z hlediska interních zdrojů i dlouhodobých outsourcingových vztahů je v jiných modelech operabilita informatiky poměrně nízká.

 

Z teoretického hlediska je přínos práce možno vidět zejména

·          v ucelené koherentní argumentaci podmínek modelu „CIO jako IT broker“,

·          v artikulaci řízení služeb informatiky jako primárního přístupu řízení informatiky založené na vnitřní podnikavosti a na plnění přání – alternativní možnosti k strategickému přístupu založenému na podpoře cílů;

·          ve vymezení principů měření výsledků a přínosů informatiky, kde tradiční ex-post přístupy nejsou úspěšné.

 

Z hlediska podnikové praxe lze přínos vidět v možnosti aplikace těchto myšlenek do tvorby trhu outsourcingu, a to jak v modelu „IT broker“, tak v modelu komplexního outsourcingu – ve vzdělání zákazníků služeb informatiky v tom, co je možné po jednotlivých poskytovatelích očekávat a co je nutné řídit komplexně pro celý podnik, a v možnosti poskytovatelů oživit nabídku některým z principů.

 

10         Použitá literatura

[Avo] Avoiding Pitfalls – Three Warning Signs. the Trends report of Outsourcing Institute, in the Outsourcing Institute www site http://www.outsourcing.com.

[Barret] Barret, R.: Outsourcing Success Means Making the Right Moves. Enterprise Reengineering, jul96, http://www.reengeneering.com/articles/jul96/InfoMangement.html

[Baukney] Baukney, H.: Can We Share? CIO magazine. June 15, 2000.

[Brown] Brown, R.O.: Enterprise Networks and Information Technology within the Outsourced Enviroment. Manager's notebook 0695 (a 0795), BRP Publ. 1996. http://brp.com/netline/corner/rb0695p1.html (a rb0795p2) (10/16/96)

[Bruckner1] Bruckner, T.: Outsourcing IS/IT. diplomová práce, Praha, VŠE, 1997.

[Bruckner2] Bruckner, T.: Stav a vývoj trhu poskytovatelů outsourcingu IS/IT v ČR. Systémová integrace 4/1997 (39-47).

[Bruckner3] Bruckner, T.: Stav a vývoj trhu poskytovatelů outsourcingu IS/IT v ČR. Systémová integrace '98, sborník mezinárodní konference, VŠE, Praha, 1998, 39-54, ISBN 80-7079-808-7

[BruDvPl] Bruckner, T. – Dvořák, E. – Plojhar, V.: Řízení totálního outsourcingu informatiky JČE na dceřiný podnik Gedos Synergie. In: Pour, J. – Voříšek, J. (ed.): System Integration 2000. Praha, VŠE, 2000, s. 153-158. ISBN 80-245-0041-8

[BrVo] Bruckner, T., - Voříšek, J.: Outsourcing informačních systémů. Praha, EKOPRESS, 1998, ISBN 80-86119-07-6

[BrVo1] Bruckner, T. – Voříšek, J.: Outsourcing z hlediska zadavatelského podniku, Business World, Computer World 50/98

[BrVo2] Voříšek, J. –  Bruckner, T.: Outsourcing IS/IT z hlediska zadavatelského podniku. Systémová integrace '98, sborník mezinárodní konference, VŠE, Praha, 1998, 39-54, ISBN 80-7079-808-7

[Burke] Burke, A.: Outsourcing – How to Make It Work For You. Industrial Safety & Hygiene News, 5/1996. http://www.safetyonline.net/ishn/9605/cover.htm(10/04/96)

[Burney] Burney, K.: Darwinian Theory for ASPs: Natural Market Selection & the Survival for the „Fittest“. Cahner In-Stat Group, August 1999. http://www.cahnerinstat.com, OC9902MP.

[Cepl] Cepl, M.: K pojmu outsourcingu a základním problémům jeho smluvní úpravy. Bulletin advokacie č.9/1998 (40-47)

[ConCun] Cone, K. – Cunningham, A.: Software Outsourcing: The Multimillion Dollar Afterthought. GartnerGroup, ESP, 1997. http://www.gartner.com/hotc/esp0197.html(09/01/97)

[Corbett] Corbett, M. F.: Redefinig the Corporation: Bringing Order to a New Industry. Přednáška na The 1995/96 Outsourcing Leadership Forum, in the Outsourcing Institute www site http://www.outsourcing.com.

[D&T] Trendy informačních technologií v ČR. Deloitte & Touche Management Consulting, firemní prospekty.

[DB] D&B's outsourcing analysis key findings. Dun & Bradstreet, Inc. April 29, 1996 – CMT. http://www.dbisna.com/dbis/planning/tplannin.htm

[Donát] Donát, J.: Prázdné místo už netáhne (2). Chip CZ, 1999, č.10, s.140-142.

[Donovan] Donovan, J.J.: Business Re-engineering with Information Technology, Prentice Hall, 1994

[DoPo] Dohnal, J., Pour, J.: Architektury informačních systémů. Praha, EKOPRESS, 1997

[Drucker] Drucker, P.F.: Postkapitalistická společnost, Praha, Management Press, 1993

[Duncan] Duncan, N.: Buying Core Competencies? A Study of the Impact of Outsourcing on IT Infrastructure Flexibility.HSB Aug25, 1996. http://hsb.baylor.edu/ramsover/acis/papers/duncan.htm (10/16/96)

[Field] Field, T.: 10 Years That Shook IT. CIO Magazine, 1999, Oct. 1. http://www.cio.com/archive/100199_outsourcing.html (24/11/99)

[FloCa] Florac, W. A. – Carleton, A. D.: Measuring the software process.

[Gartner] GartnerGroup www site. http://www.gartner.com

[Gates] Gates B: The Road Ahead, Viking Pengium, New York, 1995, český překlad: Informační dálnice, Management Press, Praha, 1996

[HalMel] Halvey, J. K. – Melby, B. M.: Information Technology Outsourcing Transactions – Process, Strategies, and Contracts. John Willey, NY 1996

[HalMum] Halvey, J. K. – Mummery, D. R.: Can This Relationship Be Saved?. 15.5.1996. http://www.cio.com/CIO/051596_relate.html (02/03/97)

[HamCha] Hammer, M. – Champy, J.: Reengineering – radikální proměna firmy. Praha, Management press, 1995.

[Howarth] Howarth, B.: Outsourcing: Technology on tap. Information Economy. 3.12.1999. http://www.brw.com.au/newsadmin/stories/brw/19991203/4335.htm (26/04/00)

[Hubbard] Hubbard, D.: The IT Measurement Inversion. CIO Magazine, 1999, Apr.15. http://www.cio.com/archive/041599_checks.html (24/11/99)

[Inside] drobné zprávy uveřejněné v časopisu Inside, ISSN ?

[Integris] Struggling with IT: The Growing Complexity of Information Technology. An Integis White Paper, January 1999. http://www.us.integris.com (9/11/99)

[Jarvlepp] Jarvlepp, H.: Focus on Making Outsourcing Work for Customers. KnowledgeBase, winter 1995. http://www.inforamp.net/~jarvlepp/kbwin95.html (10/16/96)

[Keane] Integrating Application Outsourcing within an IS Strategy. in Keane, inc. www site

[Keegan] Keegan, P.: The Death of Software? UpsideToday, Sep21, 1999.

[Kiernan] Kiernan, V.M.: The Impact Of Technology On Organizational Transformations. research paper for MGT6107, Organizational Theory, March 3, 1995. http://www.isye.gatech.edu/~verner/papers/mgt6107.html(10/04/96)

[Koch] Koch, C.: Boy, that was fast. CIO magazine. Nov. 15, 2000.

[LacHir] Lacity, M. C. – Hirschhem R.: Information Systems Outsourcing, Myths, Metaphors and Realities. Chichester, John Wiley & sons 1995

[Lynch] Lynch, R.: Hans On, Hands Off, Outsourcing Leadership. CIO magazine, Aug. 15, 2000.

[Lusher] Lusher, C.: Customer Service and Support: Growing Relationships and Increasing Profits. GartnerGroup, CS3, 1996. http://www.gartner.com/whatsnew/cs3/cs3tv.html(27/09/96)

[Malhorta] Malhorta, Y.: IS Productivity And Outsourcing Policy: A Conceptual Framework and Empirical Analysis. in Proceedings of Inaugural Americas Conference on Information Systems, Pittsburgh, AIS, 1995. http://www.pit.edu/~malhorta/papers/aisppr.htm (10/09/96)

[McKie] McKie, S.: Outsourcing with ASPs in the Internet Age. Businessfinancemag.com, November/December 1999. http://businessfinancemag.com (26/4/00)

[Minoli] Minoli, D.: Analyzing Outsourcing, Reengineering information and communication systems. New York, McGraw-Hill, Inc. 1995

[MST] IT Outsourcing: Operational Improvement or Strategic Imperative? an MST working paper on outsourcing strategies,04/26/95. http://www.mstnet.com/MST/wp_os.htm (10/16/96)

[Nam] Nam, K. et a: A Two Stage Investigation of the Determinants of Information Systems Outsourcing. Hankammer School of Business Aug 25, 1996. http://hsb.baylor.edu/ramsover/acis/papers/nam.htm (10/16/96)

[OI] Drobné informace z The Outsourcing Institute web site. http://www.outsourcing.com (11/11/96)

[Pastore] Pastore, R.: Uneasy Pieces, Part 2 – Outsourcing. CIO magazine, Reality Check, 1. 6. 1996. http://www.cio.com/CIO/060196_uneasy_2.html (02/03/97)

[Paul] Paul, L. G.: I Love our Consultant but Can I Trust him? CIO Magazin Oct. 15, 2000.

[Pecha] Pecha, T.: Problémy hodnocení přínosů IS/IT pro organizaci. Systémová integrace, 1995, roč. 2, č. 4, s. 63-72. ISSN 1210-9479

[Pour] Pour, J.: Otazníky řízení podnikové informatiky. In: Pour, J. – Voříšek, J. (ed.): System Integration 2000. Praha, VŠE, 2000, s. 569-574. ISBN 80-245-0041-8

[Profily] Profily poskytovatelů služeb IS/IT na českém trhu. Systémová integrace, 2000, roč. 7, č. 1-2, s. 3-277. ISSN 1210-9479

[Robbins] Robbins, S.P.: Organization Theory – Structure, Design and Applications. London, Prentice-Hall.

[Řepa] Řepa, V. a kol.: Analýza a návrh informačních systémů. Praha, EKOPRESS, 1999

[Shachtman] Shachtman, N.: Measure Succes. Information Week, 10/26/98, Issue 706, str. 103-105. ISSN 8750-6874

[Shachtman2] Shachtman, N.: Metrics Measure Up as Outsourcing Yardstick. Computer Reseller News 11/02/98 Issue 814, str. 58-63.

[Smith] Smith, J.: Outsourcing: Beware of the Hype, Cut cost keeping projects in-house. Fivash 1995. http://colorbox.fivash.com/ce/ce.archive/ceo.sept/mcveetybackup/depts/manage.htm (10/04/96)

[SmithA] Smith. A.: Bohatství národů. … zdroje v sekundární literatuře.

[Stra01] Strassmann, P.A.: Outsourcing: A Game for Losers. Computerworld Aug21, 1995. http://www.strassmann.com/pubs/outsource-losers.html (10/09/96)

[Stra02] Strassmann, P.A.: The Myth of Best Practices. Computerworld Dec18, 1995. http://www.strassmann.com/pubs/best-myth.html (10/16/96)

[Street] Major Commercial Outsourcing Contracts. Streetnet Features, 1, 1996. http://www.streetnet.com/features/jan96/outsre-side09.html, (28/11/96)

[TopTen] The Top Ten Reasons Companies Outsource. in the Outsourcing Institute www site http://www.outsourcing.com.

[Tvrdíková] Tvrdíková, M.: Příprava řízení přínosů IS/IT. In: Pour, J. – Voříšek, J. (ed.): System Integration 2000. Praha, VŠE, 2000, s. 605-611. ISBN 80-245-0041-8

[Učeň] Učeň, P. a kol.: Metriky v informatice aneb jak objektivizovat přínos informačního systému. Grada 2001.

[Vodáček] Vodáček, L. – Vodáčková, O.: Management, teorie a praxe v informační společnosti. Praha, Management Press, 1999.

[Voříšek] Voříšek, J.: Strategické řízení informačního systému a systémová integrace, Praha, Management Press, 1997

[Wilson] Wilson, D.: Smart-Sourcing: Where Outsourcing and Value Added Expertise Converge. Acxiom 1996.  http://www.acxiom.com/wp-01.htm (10/16/96)

[ZR1] Application Service Providers: The Move to Web-Based Outsourcing Places, New Demands on Internet Servers. ZonaResearch Whitepaper 1999.  http://www.zonaresearch.com/deliverables/white_papers/wp9/index.htm (21/2/00)

 

11         Přílohy

1.   Použité termíny

 

aplikační služba	služba informatiky poskytovaná zákazníkovi a orientovaná na splnění jeho věcného (netechnologického) přání (ekonomický IS, manažerský IS, kancelářský IS, …)
aplikační funkcionalita	komplex funkcí, kterými aplikační služba nebo informační systém umožňuje pro uživatele zpracovat informace
architektura služeb	celostní pohled na služby informatiky s primárním ohledem na možnost rozhodování „make or buy“
ASP – Application Service Provider	poskytovatel aplikačních služeb, zejména na trhu, a to vzdáleně, prostřednictvím Internetu
auditní	provedené nebo získané auditem – posouzením komisí
callcentrum	jednotné místo, kam se mají lidé (zaměstnanci) obracet v určité věci (zde s požadavky a problémy související s informatikou)
CIO – Chief Information Officer	viz ředitel informatiky
dohoda o úrovni služeb	viz SLA
dostupnost	základní kvalitativní parametr informatické služby – specifikuje čas, kdy má být služba dostupná a možné procento nedostupnosti služby v tomto čase
efekt informatiky	skutečnost, že informatika splní věcnou potřebu svého zákazníka, nebo jiný dopad, očekávaný nebo neočekávaný, pozitivní nebo negativní
helpdesk	místo, které se zabývá podporou, zde uživatelů informačního systému
hlavní proces	proces, který je orientovaný na zákazníka a podnik jej uznal za motor své dlouhodobé konkurenceschopnosti
hotline	callcentrum, telefonní linka nebo číslo na callcentrum
informatický proces	proces, který spadá do kompetence informatiky podniku
informatika podniku	oblast v podniku, jejíž kompetencí je v plném rozsahu řídit aktivity, které jsou spojené se zajištěním služeb informačních technologií, tedy služeb počítačového zpracování informací a elektronické komunikace (a to dnes včetně komunikace hlasové), pro ostatní aktivity v podniku, zejména podnikatelské
infrastrukturní služba	služba informatiky, která nepřináší zákazníkovi informatiky splnění potřeb, ale je nutná proto, aby bylo možné poskytovat aplikační službu (koncové stanice, LAN, WAN, …)
IS	informační systém
ISP – Internet Service Provider	poskytovatel připojení k Internetu a souvisejících služeb
IT	informační technologie
kvalitativní parametr	parametr služby, který popisuje jakost poskytované služby
make or buy	rozhodovací problém zda službu nakoupit od externího poskytovatele nebo zda ji zajistit (procesem) uvnitř podniku
metrika	měřitelná veličina
objemový parametr	parametr služby, který popisuje rozsah poskytnutí služby
operativní outsourcing	outsourcing organizovaný tak, že se jedná o rozhodnutí krátkodobě přehodnotitelné a vratné
outsourcing	Strategický organizační nástroj. Přesun odpovědnosti za provoz funkční oblasti (činnosti) podniku na externí specializovanou firmu – poskytovatele; zpravidla včetně zaměstnanců a vlastnictví aktiv; především za účelem zaměření na hlavní činnost, dosažení světové úrovně kvality v oblasti, případně úspory nákladů.
parametr	kvantitativní nebo kvantifikovatelná veličina
podpůrný proces	proces, jehož produktem je podpora jiného procesu v podniku v jeho činnostech
poskytovatel informatické služby	externí subjekt nebo interní proces, jehož produktem je informatická služba
potřeba na informatiku	potřeba zákazníka obvykle vylepšit některý parametr jeho procesu nebo činnosti, kterou lze splnit pomocí informatiky
proces	sled činností v podniku, které jsou orientovány na vytvoření produktu pro zákazníka procesu
projekt	dočasná forma řízení změny (např. vývoje informačního systému)
přání na informatiku	viz potřeba na informatiku
přínos informatiky	viz efekt informatiky
ředitel informatiky	vrcholový vedoucí podniku, který odpovídá za řízení oblasti podnikové informatiky
řídící služba	služba, která zajišťuje centrální aspekty řízení informatiky (řízení požadavků, změn, integrity, bezpečnosti, …)
řízení požadavků	řízení přání a potřeb zákazníků a uživatelů na informatiku
řízení změn	řízení změn v informatice – promítnutí požadavků do formy jejich realizace v informačním systému (drobné změny, zadání projektu) při zajištění řiditelnosti a rozumné komplexity podnikové informatiky
SLA – Service Level Agreement	smluvní dokument mezi zákazníkem a poskytovatelem (za dohledu podnikové informatiky), který sjednává předmět, parametry, cenu a podmínky poskytování služby
služba informatiky	produkt informatiky (informačních systémů a technologií), obvykle kontinuálně poskytovaný, nehmotný a hmotně nazachytitelný, primárně orientovaný na splnění potřeb zákazníka (aplikační služba), případně na umožnění tohoto splnění (infrastrukturní služba) nebo na možnost optimálního řízení tohoto plnění (řídící služba)
strategický proces	hlavní proces podniku nebo jiný proces, jehož produkt nelze na trhu snadno nakoupit
TCO – Total Cost of Ownership	metoda odhalení nákladů na informatiku podniku, která počítá se skrytými náklady [Gartner]
ukazatel	měřený parametr služby

 

2.   Případová studie – manažerský IS

Jako celostní obrázek na problematiku poslouží případová studie aplikační služby manažerský informační systém.

 

Vznik potřeby

Porady vedení používají jako podklady týden staré ekonomické informace o podniku. Vedení cítí, že to překáží kvalitnímu rozhodování. Proto ředitel informatiky navrhne, že by bylo možné vytvořit manažerský informační systém, který by mohl poskytnou informace čerstvější a možná i některé nové.

 

Porada vedení takový návrh uvítá, uloží řediteli informatiky, aby zpracoval podrobnější návrh. Zákazníkem je tedy vedení podniku (proces vrcholového řízení). Ředitel informatiky tedy nejprve analyzuje skutečnou potřebu této informatické podpory. Pracovníci informatiky uspořádají dvouhodinový workshop s vedením, aby identifikovali skutečné potřeby a pokusili se je kvantifikovat.

 

Výsledkem je formulace přání:

Potřebujeme něco jako manažerský informační systém, co by členům vedení, představenstva a dozorčí rady a jejich sekretariátům umožnilo sledovat aktuální informace

·          ekonomické, obchodní a výrobní situaci v podniku,

·          chování zákazníků podniku,

·          chování konkurence,

a to snadno, v souhrnných číslech a grafech, kde by bylo možné odlišit skutečné a odhadované a plánované hodnoty.

K těmto informacím musí být možné definovat přístupová práva v různém rozsahu, a musí být možné, aby tyto informace byly k dispozici určitým osobám v kanceláři, na cestách a doma.

 

a, Očekáváme, že se tím zvýší přehled vedení o aktuální situaci v podniku a schopnost kvalitně rozhodovat a řídit podnik.

 

b, Na základě této skutečnosti očekáváme, že se podaří zvýšit rychlost a úspěšnost dosahování cílů podniku.

 

c, Zároveň se zvýší spokojenost akcionářů, kteří budou mít k dispozici informace, potřebné pro zadávání úkolů a hodnocení managementu, a tedy budou akcionáři lépe hodnotit vedení podniku.

 

d, Pozor, nechceme ale, aby nás splnění tohoto přání stálo moc peněz. (Jsme ochotni investovat standardní peníze do provedení studie, na základě které se dál rozhodne.)

 

e, Budou-li takové informace k dispozici, bude zde riziko, že uniknou z podniku a dostanou se nepovolaným rukám – konkurenci. To riziko musí být uspokojivě zajištěno.

 

Workshop je řízen tak, aby jeho závěr, formulace přání, vyhovoval vedení informatiky jako dostatečně přesné zadání pro definici služby. Pracovníci, kteří řídili workshop, tak dělali již s alespoň hrubou znalostí, jaké technologické řešení splnění přání přichází v úvahu, a tedy je přání formulováno tak, aby hned ze začátku nebylo jeho splnění z technologického hlediska vyloučeno.

 

Přání specifikuje:

·          nástin možného řešení – manažerský informační systém (rámcová představa o službě, která má splnit přání),

·          požadavek na aplikační funkcionalitu – nástin, jaké informace má informační systém zpracovat a jaké mají být jeho výstupem (tj. přání věcně specifikované z hlediska vedení podniku, jeho jazykem),

·          měřitelné parametry vedení podniku, které mají být ovlivněny (body a, b a c), a parametr, který může být ovlivněn, ale není to záměr (bod d, náklady a e, riziko úniku informací).

 

Toto přání je následně v rámci procesu řízení požadavků zaevidováno, je mu přiřazena priorita, a předáno procesu řízení změn v informatice k vyřízení. V procesu řízení změn je požadavek posouzen z hlediska strategických záměrů a dlouhodobých plánů v informatice a z hlediska architektury služeb informačního systému. Je rozhodnuto, že se jedná o požadavek na novou informatickou službu a její realizace je naplánována na určité období. Zpráva o tomto řešení je předána procesu řízení požadavků, který tuto informaci může poskytovat původcům požadavku (ovšem proto, že se jedná o vedení, asi se to dozvědí i jinou cestou). Dále jsou k této plánované změně přiřazovány další, zejména drobné požadavky, které s ní souvisejí.

 

Některá z těchto posouzení již proběhla minimálně v hlavě ředitele informatiky, případně zbytku vedení nebo informatiků, již při dřívějších úvahách, je ale vhodné nechat projít požadavek posouzením i formálním, včetně dokladu o výsledku tohoto posouzení, a to zejména proto, aby bylo možné přání řídit od vzniku až do jeho plnění bez ohledu na konkrétní osoby, které se na jeho plnění podílejí, a s rozumným řízením a dokladováním kvality, a aby bylo minimalizováno nebezpečí dalšího nekontrolovaného růstu komplexity informačních technologií, jakkoli je to na úkor zvýšení podnikové byrokracie.

 

Z hlediska strategického je tato informatická služba předběžně specifikována jako podpůrná a nestrategická, a to z důvodů:

·          služby manažerského IS nejsou orientovány na zákazníka podniku a nejsou motorem dlouhodobé konkurenceschopnosti podniku,

·          služby manažerského IS jsou běžné a lze je snadno nakoupit, a to patrně za cenu, která nebude výrazně přesahovat cenu interního zajištění (to ještě ovšem bude předmětem dalšího posouzení).

 

Jedná se o novou informatickou službu a je tedy nutné nově specifikovat její předmět. V určeném čase řešení tedy podniková informatika zajistí zpracování návrhu specifikace předmětu služby. Návrh je nutné zpracovat kromě hlediska zákaznického a dodavatelského také z hlediska řídících informatických služeb, tedy zejména z hlediska bezpečnosti a kvality IS a z hlediska systémové integrace.

Nejprve je hrubě specifikován předmět služby a vypracován plán poptávkového řízení na zajištění této služby. Je vypsáno výběrové řízení, kterého, má-li zájem, dostatek zdrojů a patřičné kompetence, se může zúčastnit i podniková informatika (například s právem last call).

Jeden nebo několik málo vybraných účastníků poptávkového řízení paralelně provede úvodní studii, která jednak specifikuje předmět služby podrobně (ovšem ne technologicky, ale na základě zde a ve výběrovém řízení uvedených pravidel). Specifikuje:

·          podrobně navrhovanou funkcionalitu,

·          podrobně návrh parametrů a způsobu měření ukazatelů služby,

·          způsob měření splnění definovaných potřeb (a dalších efektů),

·          navrhne technologické řešení, které bude respektovat centrální podnikové řízení bezpečnosti (riziko) a integrace (datové, technologické, uživatelského rozhraní);

·          určí požadavky na ostatní služby informatiky podniku, aby mohla být služba manažerského IS plněna (potřeby, předmět služeb a parametry, v zde uváděných principech);

·          určí trvalý způsob školení uživatelů služby, aby ji mohli použít k plnění potřeb;

·          určí závazně čas, ve kterém je schopen službu zavést;

·          určí závazně cenu, za kterou je schopen službu poskytovat (při zachování pravidel zde uvedených).

 

Zastavme se u požadavků na ostatní služby. Aby mohla být přesně rozdělena odpovědnost za jednotlivé části informatiky, ale zároveň aby si zákazník nebo vedení informatiky nemuseli ponechat konečnou odpovědnost za kooperaci jednotlivých částí IS, je nutné integraci mezi službami také odpovědnostně rozdělit, a to nejlépe opět sofistikovanou specifikací služeb a jejich parametrů.

V našem případě manažerský systém patrně bude používat data z ostatních částí informačního systému podniku. Vstup těchto dat je nutné zajistit. Odpovědný poskytovatel služeb manažerského systému musí odpovídat za výstupy jeho služby, ale nemůže beze zbytku odpovídat za to, že relevantní data v relevantní struktuře a včas do manažerského systému vstoupí. To je nutné zajistit vhodně definovanou službou jiných informatických služeb. Takové služby je vhodné definovat podle zde uvedených pravidel. Jejich zákazníky již nejsou „koncoví“ zákazníci informatiky, ale jiné informatické služby, a proto je možné definovat je v jazyku informačních technologií. V našem případě není v podniku zavedena služba, která by zajišťovala uložení dat pro aplikační služby. To znamená, že odpovědnost za uložení dat je součástí jednotlivých aplikačních služeb (to je z hlediska technologického zajištění integrity dat problémem, ale na druhé straně je to velmi výhodné z hlediska rozdělení kompetencí a odpovědností za výsledek služeb). Proto je nutné požadavek na vstupní data směrovat na ostatní aplikační služby. Během vývoje manažerského systému je tedy nutné ve spolupráci s ostatními aplikačními službami a s řízením podnikové integrace (zde hlavně datové a integrace rozhraní) posoudit možnosti výstupů dat ostatních služeb do manažerského IS. Tyto možnosti jsou promítnuty do požadavků a jsou definovány v rámci procesu řízení změn jako rozšíření ostatních aplikačních služeb, tentokráte ne pro koncového uživatele, ale pro jinou aplikační službu. Za konkrétní hodnoty dat ovšem nemohou odpovídat ani poskytovatel služby manažerského IS, ani poskytovatelé jiných aplikačních služeb. Za věcnou správnost dat musí odpovídat uživatel, který je do IS vložil (nejsou-li měřeny automatizovaně). Poskytovatelé aplikačních služeb ale musí odpovídat za to, že jsou tato data věcně správně zpracována a mezi jednotlivými službami správně předána.

 

Kromě požadavků na služby typu rozhraní aplikačních služeb pak manažerský systém definuje požadavky na infrastrukturní služby. Opět v rámci procesů řízení požadavků a změn jsou ve spolupráci s řízením bezpečnosti a integrace projednány možnosti podnikové infrastruktury a jsou specifikovány požadavky na služby této infrastruktury.

Jsou definovány zejména požadavky na přenos dat od uživatelů (ostatních aplikací) ke zpracovateli a od zpracovatele k uživateli. Jedná se tedy o požadavky na kapacitu sítí LAN a WAN, a na parametry koncové stanice a její konfigurace. V našem případě budou informace poskytovány jak v pevné podnikové počítačové síti, tak na přenosné počítače manažerů, tak na jiná mobilní zařízení, telefony nebo osobní diáře a asistenty. Služba manažerský sytém tedy patrně využije infrastrukturní služby WAN, LAN, telefonní sítě, koncové stanice PC a koncové mobilní terminály.

 

Je zřetelné, že čím méně subjektů a čím méně služeb je v podniku zajištěno, tím snadnější je rozdělení odpovědností. Ovšem složité procesy specifikace a definice služeb, které si procesy zajišťující informatické služby vzájemně poskytují, jsou pro podnikovou informatiku přínosné v možnosti řízení odpovědností a s možností kontroly komplexity podniku včetně kontroly celkových nákladů na informatiku, a v modelu více poskytovatelů služeb informatiky jsou z hlediska předcházení kompetenčních sporů nezbytné, protože jinak bude vývoj v podnikové informatice živelný a neřiditelný. S tím, že by podnik v budoucnu služby od více subjektů v budoucnu nevyužil, však počítat nelze.

 

Na základě úvodní studie se zákazník ve spolupráci s vedením informatiky rozhodne, zda službu za daných podmínek a za specifikovanou cenu chce využít, a zda tedy bude zadán projekt a změna v informatice bude provedena.

Bez ohledu na toto rozhodnutí je zpracovatelům úvodní studie zaplaceno za její vytvoření.

 

Dále bylo rozhodnuto o zavedení služby. Bylo vypracováno zadání projektu a vypracována smlouva na zavedení a poskytování služby, a to v navrhovaném předmětu a v návaznosti na závazný výstup úvodní studie.

 

Aplikační funkcionalita (jak budou informace zpracovány a komu budou kdy k dispozici) byla definována podle úvodní studie a poskytovatel se zavázal k plnění parametrů, které navrhl (například dostupnost, dobu odezvy, počet uživatelů, čas nebo zpoždění, kdy budou k dispozici určité konkrétní informace, atd.)

 

Bylo sjednáno, že poskytovatel se nezaváže přímo k plnění přání, ale zaváže se k tomu, že výsledkem služby bude možné přání splnit. Byly tedy definovány následující auditní kritéria, na jejichž splnění je v určité periodě vázáno vyplacení části ceny – bonusu:

Otázky:

a, Zvýšil se v důsledku služby manažerský IS přehled vedení o aktuální situaci v podniku a schopnost kvalitně rozhodovat a řídit podnik?

b, Podporuje služba manažerský IS rychlost a úspěšnost dosahování cílů podniku?

c, Je v důsledku služby manažerský IS možné, aby byla vyšší spokojenost akcionářů a aby lépe hodnotili vedení podniku?

 

Na všechny otázky byly určeny možné odpovědi:

i, Určitě ano,

ii, Spíše ano,

iii, Spíše ne,

iv, Určitě ne.

 

Pokud na žádnou otázku nezní odpověď iv, bude vyplacena část zadržovaných plateb za službu. Pokud na všechny otázky zní odpověď i nebo ii, bude vyplacen navíc určený bonus.

3.   Outsourcingové kontrakty v ČR

Seznam vybraných vztahů typu outsourcing, které probíhají na českém trhu, jak je poskytovatelé uvedli v průzkumu ČSSI [Profily], případně podle [Inside].

 

poskytovatel	zákazník	uživatelů	charakter služeb
APP Czech s.r.o.	STE	168	komplexní služby - aplikace, HW, sítě
Compaq Computer, s.r.o.	Český statistický úřad	800	Systém management
Compaq Computer, s.r.o.	Sazka, a.s., Radiomobil, a.s.	N/A	Desktop outsourcing
debis IT services Czech	Benzina, a.s.; Unipetrol, a.s.	N/A	provoz IT, vč. SAP R/3
EDS, s.r.o.	GM OPEL CS, s.r.o.	162	N/A
EDS, s.r.o.	Delphi-Packard Electric Systems ČR	200	N/A
GEDOS Synergie a.s.	Jihočeská energetika, a.s.	850	úplný outsourcing
Hewlett-Packard, s.r.o. CSc Computer Services CZ, a.s.	Český Telecom, a.s.	cca 13.000	podpora koncových stanic
IBM ČR, spol. s.r.o.	Barum Continental	N/A	kompletní outsourcing
ICL ČR, spol. s.r.o.	První pražská zdravotní	25	úplné převzetí správy IS/IT
Infinity, a.s.	Čedok	450	plný outsourcing služeb IS/IT
Infinity, a.s.	Kaufland	600-700	HelpDesk, správa LAN, WAN
ITS, a.s.	Strojimport	120	Provoz HW serverů
LCS Internatonal, a.s.	Národní muzeum	N/A	Zajištění provozu IS/IT včetně HW formou služby
PVT, a.s.	SCP, RM-SYSTÉM	N/A	úplný outsourcing
PVT, a.s.	IPB, a.s.	N/A	částečný outsourcing
Sybase, s.r.o.	Commerzbank	>500	systémová integrace
Varias CZ, a.s.	Voest Alpine Profilform	12	outsourcing serveru, komunikací a správy SAP R/3

 

4.   Checklist smlouvy na outsourcing

Účel:

·          Poskytnout ucelený přehled všech věcí, které je nutné smluvně řešit při outsourcingu informatiky (ať části nebo jako celku).

·          Přehled je koncipován jako věcný, formální náležitosti i způsob věcné specifikace je nutné upravit podle zvolené právní formy řešení.

·          Checklist není návrhem struktury smlouvy.

·          Může sloužit jako podklad pro plánování procesu kontraktačního řízení outsourcingu, zejména na straně zákazníka.

·          Základní možnosti právního řešení jsou uvedeny v závěru.

 

Obsah:

1. Checklist věcí, které je nutné outsourcingovou smlouvou řešit

2. Varianty právní formy řešení outsourcingové smlouvy

 

Volba právní formy (2) je závislá na zvoleném způsobu věcného řešení (1).

 

 

1. Checklist věcí, které je nutné outsourcingovou smlouvou řešit

 

A, Poskytování služeb poskytovatelem

B, Transformace stávajícího stavu na poskytování služeb poskytovatelem

C, Ukončení poskytování služeb a převod na jiného poskytovatele nebo do interního provozu

 

A, Poskytování služeb poskytovatelem

(1)            Základní sada služeb a její úpravy

·          Definice základní sady služeb. Vymezení služeb, které jsou poskytovány podle této smlouvy (služby, u kterých bude dostatečně přesně a jednoznačně určen předmět závazků, pokud půjde o smlouvu nepojmenovanou)

·          Určení principů, kterých bude použito v případě, že bude sporné (že nenastane shoda), zda služba je součástí základní sady nebo není

·          Rámec pro řešení poskytování služeb, které nejsou součástí základní sady

·          Způsob kalkulace ceny základní sady služeb (pevná cena, cena závislá na kvantitě služby, cena za práci a materiál), jakým způsobem bude upravena cena základního balíku při ubrání / přidání poskytovaných služeb

·          Rozšíření základního balíku o další služby, povinnost zajistit parametry ostatních služeb při rozšíření, dohadování ceny provozu IS před započetím vývoje

·          Zúžení základního balíku, právo zákazníka přestat odebírat

(2)            Podrobná jednoznačná specifikace služeb, které jsou součástí základní sady.

·          Systém specifikace služeb (hierarchická struktura, disjunktnost apod.)

·          Vyjmenování služeb základní sady

·          Standardní úroveň poskytovaných služeb – kvalita, množství a cena jednotlivých služeb (SLA) ve vazbě na obecnou specifikaci základní sady

·          Odpovědnost za celkový chod IS (Systémová integrace), odpovědnost za věcné a technologické vazby mezi subsystémy, které zajistí jejich kooperaci.

·          Slevy/penále za nedodržení standardní úrovně u jednotlivých služeb (SLA)

·          Specifika spolupůsobení u jednotlivých služeb (SLA)

·          Pravidla technologické obnovy (podstatných systémů)

(3)            Dodatečné služby

·          Pravidla pro objednávání / poskytování služeb, které nejsou součástí základní sady (jak budou prováděny nové nákupy hardware do majetku zákazníka)

·          Omezení práva zákazníka nakupovat služby od třetích subjektů

(4)            Změna podmínek a parametrů služeb

·          Případy, kdy vzniká právo zákazníka / poskytovatele vyvolat a dožadovat se jednání o změně podmínek a parametrů poskytovaných služeb

(5)            Doba poskytování služeb

·          Poskytování na dobu neurčitou nebo určitou

·          Kdy začne poskytovatel poskytovat služby zákazníkovi.

·          Termíny obnovování smlouvy

(6)            Jednotky, které budou zákazníky služeb poskytovatele

·          Omezení odebírání služeb v organizaci podniku zákazníka

·          Bude odebírat služby i někdo externí (mimo podnik zákazníka) v rámci této smlouvy?

·          Způsob řešení předpokládaných nebo možných významných změn organizační struktury zákazníka během trvání smlouvy

(7)            Ujednání o exkluzivitě

·          Míra omezení práva zákazníka odebírat některé služby i od jiných dodavatelů

(8)            Subdodávky

·          Omezení možnosti plnění prostřednictvím subdodávky třetím subjektem

(9)            Technické prostředky

·          Které technické prostředky vlastní (nově nakupuje) zákazník, které poskytovatel

·          Kdo je zodpovědný za údržbu jednotlivých technických prostředků

·          Ke kterým prostředkům poskytovatel poskytuje službu helpdesk

·          Které prostředky obnovuje po životnosti poskytovatel, které zákazník

·          Ke kterým prostředkům provádí poskytovatel technické zhodnocení

·          Kdo je odpovědný za pronajímání, leasing, nákup a správu vztahů s třetími stranami, které se týkají prostředků zákazníka

·          Správa a aktualizace evidence prostředků, inventarizace

(10)        Aplikační a systémový software

·          Kdo ponese náklady a odpovědnost za aplikační software

·          Licence: software licencovaný na (a) zákazníka, (b) poskytovatele, (c) zákazníka i poskytovatele

(11)        Správa a údržba aplikací

·          Přesný způsob, jak se odliší správa aplikací od vývoje aplikací

·          Seznam všech činností, které zákazník zahrnuje pod správu aplikací a požaduje je i po poskytovateli

(12)        Vývoj aplikací

·          Kdo bude odpovědný za vývoj aplikací, závazné události a procedury týkající se nového vývoje

·          Jak bude správa aplikací kvantitativně a cenově omezena

(13)        Výkonové standardy systémů

·          Specifikace výkonových standardů s ohledem na služby poskytovatele

·          Má zákazník dokumentaci nebo benchmarky současných výkonových standardů?

·          Plánoval / dokumentoval zákazník současné prostoje systémů?

·          Slevy / pokuty, které poskytovatel ponese za nedodržení standardů

·          Dodržení standardů během transformace, migrací apod.

(14)        Aktiva a odpovědnosti, které zůstanou zákazníkovi

·          Jaká aktiva a odpovědnosti zůstanou zákazníkovi

·          Bude zákazník odpovědný za dodávky spotřebního materiálu? (papír, formuláře, obálky, tonery …), pozor na personální zajištění těchto povinností u zákazníka

(15)        Místo poskytování služeb

·          Budou služby poskytovány pouze v budovách a zařízeních zákazníka?

·          Omezení poskytování služeb na určitý region.

·          Zůstane provoz služeb v budovách a zařízeních zákazníka?

(16)        Lidské zdroje

·          Budou někteří (kteří) zaměstnanci přesunuti k poskytovateli? Za jakých podmínek?

·          Odpovídá kvalifikace a přijímací procedury zaměstnanců poskytovatele předpisům pro zaměstnance (osoby pohybující se v prostorách) zákazníka?

·          Bude poskytovatel požadovat, aby zákazník určitou dobu držel určité zaměstnance? Uhradí poskytovatel zákazníkovi náklady na tyto zaměstnance?

·          Požadavky zákazníka / poskytovatele na pracovníky IS

(17)        Řízení projektů

·          Za řízení vývojových projektů odpovídá poskytovatel / zákazník

·          Jmenovitě klíčoví lidé v projektech (vedoucí projektů). Zákazník může požadovat, aby po určitou dobu poskytovatel neměnil klíčové osoby v projektech.

·          Pravidla pro personální obsazování budoucích projektů

(18)        Technologické skoky

·          Jak budou řešeny významné technologické změny v oblasti IT

(19)        Předávané informace

·          Specifikace zpráv, výkazů a sestav, které zákazník / poskytovatel předává (obsah, forma, termíny)

·          Zprávy, výkazy a sestavy během transformace, migrací apod.

(20)        Ochrana informací

·          Soulad / odchylky bezpečnostních politik zákazníka a poskytovatele, řešení odchylek

·          Smluvní pokuty za prokázaný únik chráněných informací

·          Povinnost zajištění dostatečné organizační a technologické ochrany informací poskytovatelem

(21)        Zákazníkova data

·          Jak budou řešeny chyby zpracování

(22)        Legislativa a autority

·          Odpovědnost za provedení změn v IS nutných kvůli legislativě a regulačním autoritám (s vlivem na zákazníka / s vlivem na poskytovatele)

(23)        Audity zpracování, cenové audity, benchmarky

·          Pravidelné audity, podmínky mimořádných auditů, pravidla srovnání kvality a ceny služeb s jinými podniky

(24)        Cena za služby

·          Které služby budou placeny paušálem / jednotkovou cenou za dodanou kvantitu / jednotkovou cenou za odvedenou práci / kombinací

·          Bude část ceny vázána na splnění určitých kvalitativních nebo auditních kritérií?

·          Bude cena vázána na obvyklou cenu v odvětví (benchmarky)?

·          Souvislost ceny za služby s dosavadními náklady zákazníka na outsourcovanou oblast

(25)        Dodatečné platby a bonusy

·          Případy, kdy je/není možné účtovat cenu za dodatečné služby z ceny (ve kterých případech které služby nejsou součástí ceny)

·          Případy, kdy budou poskytnuty bonusy

(26)        Vazby ceny na inflaci a kursy měn

·          Které složky ceny budou vázány na inflaci / směnné kursy?

·          Kdy a jakým způsobem se uplatní zvýšení / snížení podle inflace a směnných kursů, jaká a kým vyhlášená hodnota inflace a směnných kursů bude použita.

(27)        Daně

·          Jaké složky ceny spadají do snížené / standardní / nulové sazby DPH, jak budou tyto složky vykazovány a upravovány

·          Daňové aspekty různých forem vlastnictví / nájmů / leasingu prostředků pro poskytování služeb

(28)        Pojištění

·          Jaké pojištění jsou poskytovatel a zákazník povinni zajistit

(29)        Spolupůsobení (právo požadovat spolupůsobení)

·          Případy, kdy spolupůsobení zákazníka ovlivňuje povinnost poskytovatele dodržet parametry poskytovaných služeb

·          Interní jednotky spolupůsobení na straně zákazníka (útvar informatiky, útvar nákupu, správa budov, personalistika, strategické plánování, …)

·          Způsoby měření / dokladování dostatečnosti spolupůsobení

(30)        Pravidla komunikace a řízení změn

·          Povinnost zajistit prokazatelnost předání zprávy v určitých případech

·          Osoby odpovědné za jednání, kontaktní místo pro hlášení vad a požadavků

·          Způsob řešení nových požadavků.

·          Vazba plánování na plánovací cykly (investice, strategie, …) zákazníka

·          Povinnost stran předložit a projednat plán na příští období v určitém čase (změny základní sady, úprava cen, - pokud nedojde k dohodě, platí základní sada služeb i s cenami i pro příští období?)

 

B, Transformace stávajícího stavu na poskytovatele

(31)        Harmonogram převodu

(32)        Smlouvy, které mají být revidovány (pro zjištění, zda je nutné vyžádat souhlas třetích stran)

·          Softwarové licence

·          Pronájmy a leasing hardware

·          Smlouvy o údržbě (apod.)

·          ostatní (…)

(33)        Technické prostředky – stávající

·          Které prostředky poskytovatel odkoupí, za jakou cenu (tržní, účetní)

·          Prostředky, které nakupuje a provozuje poskytovatel, ale které po dobu životnosti (do doby odpisu) budou použity stávající v majetku zákazníka.

(34)        Aplikační a systémový software – stávající

·          Připravit seznam veškerého software dosud užívaného zákazníkem, v dělení na vlastní a licencovaný

(35)        Svolení třetích stran

·          Jak budou rozděleny náklady na zajištění potřebných svolení třetích stran při transformaci

(36)        Ocenění a audity

(37)        Lidské zdroje - transformace

(38)        Rozpracované projekty

 

C, Ukončení poskytování služeb a převod na jiného poskytovatele nebo do interního provozu

(39)        Předčasné ukončení smlouvy (vypovězení, odstoupení)

·          Kdy mohou strany vypovědět smlouvu, jak dlouhá má být výpovědní lhůta v jakých případech

·          Kdy mohou strany odstoupit od smlouvy (případy podstatného porušení)

(40)        Závazné procedury při ukončení poskytování služeb

·          Zajištění pokračování poskytování služeb jiným způsobem

(41)        Významná porušení smlouvy a práva stran z toho plynoucí

(42)        Platby při předčasném vypovězení (stornovací poplatky)

(43)        Práva a povinnosti při vypovězení a odstoupení od smlouvy

(44)        Svolení třetích stran

·          Jak budou rozděleny náklady na zajištění potřebných svolení třetích stran při ukončení smlouvy

 

 

2. Varianty právní formy řešení outsourcingové smlouvy

 

A, Poskytování služeb poskytovatelem

Nepojmenovaná smlouva

·          průběžné provozování informačních systémů

·          veškeré trvale poskytované služby

·          rámec pro ostatní smlouvy (o dílo, …)

Smlouva o dílo

·          jednorázový vývoj IS s přesně definovatelným výsledkem

·          dohodnout způsob a parametry provozování díla po jeho předání

Nájemní smlouvy, smlouvy o koupi najaté věci

·          nájem hardware

Licenčněprávní a autorskoprávní řešení

·          poskytování práva užívat software

 

B, Transformace stávajícího stavu na poskytovatele

Smlouva o prodeji (části) podniku

·          odkoupení útvaru informatiky zákazníka poskytovatelem

Kupní smlouvy

·          odkoupení aktiv (hardware, …) poskytovatelem

Pracovněprávní řešení převodu zaměstnanců

 

C, Ukončení poskytování služeb a převod na jiného poskytovatele nebo do interního provozu

Součástí nepojmenované smlouvy – způsob ukončení průběžného poskytování služeb

Smlouva o smlouvě budoucí

·          zpětné odkoupení hardware