Elektronizace vnitropodnikových procesů

Bankovní institut vysoká škola Praha Katedra informačních technologií

Elektronizace vnitropodnikových procesů

Diplomová práce

Autor:

Bc. Jindřich Pavel Informační technologie

Vedoucí práce:

Praha

Ing. Václav Šebek, CSc.

Duben, 2011

Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze dne 22. dubna 2011

Bc. Jindřich Pavel

2

Anotace Diplomová práce „Elektronizace vnitropodnikových procesů“ se všestranně zabývá systémy pro správu podnikového obsahu (anglicky Enterprise Content Management ECM). Systematicky popisuje jednotlivé komponenty používané v rámci těchto systémů, věnuje se jejich implementaci a vlivu na vnitropodnikové procesy v teorii a praxi. V praktické části práce je podrobně popsán, analyzován a vyhodnocen konkrétní projekt nasazení několika komponent pro správu podnikového obsahu u nadnárodní firmy včetně praktických doporučení.

Annotation The dissertation „Electronization of Internal Business Processes” focuses on Enterprise Content Management (ECM) solutions. It provides a systematic description of components contained in ECM systems, it deals with their implementation and impact on internal business processes in theory as well as in practice. A practical part describes, analyzes and evaluates a specific implementation project of ECM system within an international company including practical recommendations.

3

Obsah: Úvod ......................................................................................................................................................... 6 1.

2.

3.

4.

Základní vymezení ECM ................................................................................................................ 8 1.1.

ECM v kostce .......................................................................................................................... 8

1.2.

Vztah ERP a ECM systémů ...................................................................................................10

1.3.

Pohled do historie ...................................................................................................................12

1.4.

Životní cyklus dokumentu ......................................................................................................14

Komponenty ECM .........................................................................................................................16 2.1.

Pořízení dokumentů................................................................................................................18

2.2.

Vytěžení dokumentu ..............................................................................................................19

2.3.

Systém pro správu dokumentů ...............................................................................................22

2.4.

Správa záznamů......................................................................................................................22

2.5.

Řízení pracovních toků a firemních procesů ..........................................................................23

2.6.

Správa webového obsahu .......................................................................................................25

2.7.

Podpora týmové spolupráce ...................................................................................................25

2.8.

Archivace ...............................................................................................................................25

2.9.

Správa elektronické pošty ......................................................................................................26

Další vývoj ECM systémů..............................................................................................................29 3.1.

Web 2.0 ..................................................................................................................................29

3.2.

Cloud computing ....................................................................................................................30

3.3.

Další vývojové trendy v oblasti ECM ....................................................................................30

Legislativa a standardy ...................................................................................................................32 4.1.

Mezinárodní předpisy a standardy .........................................................................................33

4.2.

Legislativa v České republice ................................................................................................35

4

5.

ECM v rámci podnikové strategie ..................................................................................................41 5.1.

Nákup aplikace .......................................................................................................................43

5.2.

Vzdálené poskytování služeb (ASP) ......................................................................................44

5.3.

Software jako služba (SaaS) ...................................................................................................45

5.4.

Outsourcing ............................................................................................................................45

6.

Řízení projektů ECM .....................................................................................................................47 6.1.

Metodiky pro řízení projektů..................................................................................................47

6.2.

PMBOK..................................................................................................................................49

7.

Nasazení ECM v praxi ...................................................................................................................53 7.1.

Rámec projektu ......................................................................................................................53

7.2.

Historie projektu .....................................................................................................................56

8.

Průběh realizace .............................................................................................................................59 8.1.

Úvodní fáze projektu ..............................................................................................................60

8.2.

Popis technického řešení ........................................................................................................62

8.3.

Změna procesu .......................................................................................................................62

8.4.

Průběh projektu ......................................................................................................................64

9.

Zhodnocení pilotního projektu .......................................................................................................64 9.1.

Iniciace a zahájení projektu ....................................................................................................65

9.2.

Plánování projektu..................................................................................................................67

9.3.

Průběh projektu a jeho řízení .................................................................................................67

9.4.

Přínosy plánované a skutečné.................................................................................................69

9.5.

Doporučení pro další rozvoj ...................................................................................................71

10.

Závěrečné zhodnocení ................................................................................................................76

5

Úvod Základním tématem této práce je elektronizace vnitropodnikových procesů, což je úkol, pro jehož řešení se v rámci informačních technologií využívají technologie, které se zahrnují pod poměrně široce chápaný pojem „systémy pro správu podnikového obsahu“, neboli Enterprise Content Management (ECM). Jde o velmi rychle se rozvíjející segment IT trhu, přestože některé technologie obsažené v řešeních ECM se využívají již dlouhou řadu let. V posledním desetiletí se jednotlivé komponenty mezi sebou začaly zásadním způsobem integrovat a dnes jsou zákazníkům nabízeny komplexní systémy umožňující zpracování dokumentů (a dalšího podnikového obsahu) v digitální podobě a propojení na podnikové procesy. Poté co došlo k nasycení trhu s podnikovými informačními systémy, přesouvá se zájem společností právě k systémům ECM. Prvním úkolem, který jsem si v rámci této práce vytkl, je nejprve přehledným způsobem seznámit čtenáře s tím, co se dnes rozumí pod pojmem ECM a abych mohl dané téma prakticky uchopit, budu se poté soustředit na jednu ze základních funkcionalit, kterou je správa elektronických dokumentů a věcí s ní souvisejících. Pro praktickou část práce jsem si pak vybral jeden konkrétní projekt, kdy se mezinárodní firma rozhodla pro nasazení několika komponent z rodiny ECM systémů. Konkrétně šlo o systém umožňující digitalizaci dodavatelských faktur, automatické vytěžení jejich obsahu, schválení, integraci s podnikovým informačním systémem a následnou archivaci. Projekt byl kromě jiného zajímavý také tím, že se jednalo o první podstatnější zkušenost firmy se systémy ECM. Zde jsem si stanovil několik základních úkolů. Nejprve popíši způsob, jakým byl vybraný projekt iniciován a následně realizován a poté se ho pokusím analyzovat tak, aby bylo možno posoudit, zhodnotit a v neposlední řadě také zobecnit aspekty implementace systémů pro správu elektronických dokumentů. Rovněž se pokusím o zhodnocení vlivu dané technologie na vnitropodnikové procesy a jejich řízení. Dalším důležitým cílem je zasazení projektu do širšího podnikového rámce a jeho celkové zhodnocení s ohledem na podnikovou strategii, řízení vnitropodnikových procesů a také na způsob řízení projektu (zde použiji jednu z obecných metodik pro řízení projektů). Rovněž chci na u vybraného projektu porovnat a analyzovat očekávané a skutečné přínosy nasazeného řešení. V závěru práce se pokusím formulovat některá konkrétní doporučení, která by firmě v budoucnu mohla jednak napomoci k efektivnímu nasazení systému v dceřiných firmách a

6

pak také k dalšímu rozvoji samotného systému s ohledem na dosažení vyšší efektivity vnitropodnikových procesů – v tomto případě procesů spojených s nákupem zboží, materiálu a služeb. Projekt vybraný pro tuto práci se realizoval ve firmě, pro kterou v současné době pracuji (i když v trochu oblasti než je ECM, mám zde na starosti systém SAP), nicméně projektu jsem se účastnil v počáteční fázi a poté mohl sledovat jeho – dle mého ne příliš uspokojivý – průběh. Za hlavní přínos tak budu považovat poučenou autorskou analýzu projektu z oblasti ECM, jeho komplexní zhodnocení včetně zasazení do širších souvislostí a vyvození konkrétních závěrů a doporučení.

7

1. Základní vymezení ECM Nejprve se podívejme na oblast ECM v širších souvislostech. Budeme se věnovat vymezení systémů ECM proti tradičním podnikovým informačním systémům, krátce nahlédneme do historie a seznámíme se také s pojmem životního cyklu dokumentu. Na úplný začátek si ale na příkladu jedné prezentace ukážeme, kam dospěl technologický vývoj v oblasti ECM na prahu druhého desetiletí 21. desetiletí.

1.1.

ECM v kostce

Společnost SAP pořádá pravidelné mezinárodní konference pro vývojáře TechEd, jejichž součástí jsou také soutěžní prezentace nazvané Demo Jam. Tým, který se účastní soutěže, má šest minut na to, aby publiku předvedl zajímavou aplikaci nějakého řešení z rodiny produktů SAP. Vzhledem k omezenému času musí být prezentace stručná, efektní a nesmí postrádat vtip. Na poslední konferenci konané v říjnu 2010 v Berlíně tuto soutěž vyhrála prezentace, která nesla název „Smartpen and Paper Collaboration“ a kterou je možno zhlédnout na internetu1. Přestože soutěž má charakter podívané, je zajímavé, jak uvedená prezentace v nesmírně kompaktní podobě ilustruje, kam až dospěly aplikace z oblasti ECM na počátku druhého desetiletí 21. století a vedle toho také obsahuje téměř všechny klíčové pojmy z oblasti správy dokumentů. O co se tedy jednalo. Na pódium přišli dva soutěžící a cílem prezentace bylo ukázat, jak se může práce s tak zdánlivě neefektní a „zastaralou“ věcí jako je pero a papír uplatnit při podnikání. První z dvojice měl notebook, kde běžel modul informačního systému SAP pro řízení správy dokumentu (SAP DMS) ve kterém měla skončit informace zaznamenaná na papír. Druhý z dvojice měl k dispozici tzv. „Smartpen“, což je běžně vypadající pero, které ale umí přenášet tahy do digitální podoby a umožňuje přitom také nahrávat zvuk. Aby soutěžní příspěvek zaujal publikum, ve kterém měli drtivou převahu muži, simulovala se situace testování kvality piva, kdy první z dvojice před diváky otevřel láhev piva a prověřoval kvalitu 1

Zdroj: http://www.virtualsapteched.com/index.aspx?url=ADfvSzS/mtCv1XbyfBnQI1QgjrcSyoDIbOrfYOrQGYTVPO OTgtJSv6wSXGy/2eBOAia7Fwxl41hN*~*sr1bIKk+2gvaSn4bGSEPEWCCRg2y4PA=#C24oSkqTrXX8E30X wBKB+RZuv4ndELPIQY815w5C3ic= [online]

8

dle třech zadaných parametrů: barva, jednoduchost otevření a chuť. Druhý z dvojice si na papír napsal ony tři hodnotící parametry a pak postupně připisoval ke každému z nich výsledek praktického testu. Po dokončení zapisovatel ťukl perem na předtištěnou grafickou značku v zápatí dokumentu a tím předal informaci, že zápis je hotovo. Takto ručně vyplněný protokol se poté automaticky přenesl do modulu SAP DMS ve formátu PDF. Během přenosu dat soutěžící poznamenal, že to chvíli trvá, neboť informace jde z Berlína na VPN bránu v Lotyšsku a odtud na server umístěny v kalifornském Palo Altu a zase zpět. Přenos skončil za malý okamžik a ručně napsaný protokol se zobrazil v systému SAP. Po kliknutí na záznam, se otevřel běžný prohlížeč PDF a v něm byl zobrazen napsaný protokol. Dokument byl navíc aktivní a obsahoval zabudovanou audio stupu, takže když soutěžící najel kurzorem na třetí a nejdůležitější hodnotící parametr, tj. chuť piva, ze záznamu se ozval zaznamenaný komentář degustátora: „Ano, toto je velmi dobré pivo“. Vystoupení pochopitelně zaznamenalo velký úspěch a vyhrálo celou soutěž. Zmínili jsme, že vedle dokumentace technické pokroku můžeme z vystoupení také vydestilovat téměř všechny základní pojmy související s oblastí správy dokumentu, o kterých budeme hovořit v další části práce. Jaké tedy máme na mysli? Protokol o testování piva představuje dokument, a jelikož byl psán ručně na volný papír (ne do formuláře), jde o dokument nestrukturovaný. Automatickým převodem do digitální podoby došlo k jeho digitalizaci. Výsledný soubor PDF obsahuje také zvukovou stopu, tj. jde o soubor multimediální. Uložením souboru do modulu SAP DMS dojde k jeho archivaci a zároveň jde o začlenění do dokumentu do architektury podnikového informačního systému. Uložením se soubor stal součástí podnikového obsahu. Soubor si pak mohou oprávnění uživatelé prohlédnout – můžeme tedy s drobným přimhouřením oka hovořit o publikování. Soutěžní ukázka rovněž obsahovala tři základní fáze zpracování podnikového obsahu: vstup (pořízení dokumentu digitalizací předlohy), zpracování (uložení včetně případné úpravy) a výstup (publikace a archivace). To co ukázka z časových důvodů nemohla obsahovat, ale není těžké si to představit, je vytěžení dokumentu (rozpoznání tištěného či ručně psaného textu), doplnění o metadata (druh protokolu, datum testu, jméno degustátora atd.), a pak jeho zpracování v rámci nějakého automatizovaného podnikového procesu. Uložený dokument by ještě mohl mít nastavenu dobu uchování a po jejím uplynutí by byl automaticky skartován. Jednotlivé tučně zvýrazněné pojmy budou postupně vysvětleny v dalších kapitolách. Nejdříve si tedy vysvětlíme pojem, který nás bude provázet celou prací. Tímto pojmem je již uvedená správa podnikového obsahu neboli ECM. 9

1.2. Vztah ERP a ECM systémů Aplikační software (ASW) používaný v podnicích lze rozdělit do několika kategorií. Základní kategorii tvoří celopodnikové transakční systémy známé pod zkratkou ERP (Enterprise Resource Planning). Přestože význam zkratky již dnes není příliš přesný (tj. plánování podnikových zdrojů), neboť znamená pouze malou část toho, co podnikové systémy dnes dokáží, přesto je stále používán. Vznik ERP systémů spadá do 60. let minulého století, kdy začaly vznikat první aplikace komplexnějšího charakteru pro podporu a automatizaci nejprve výroby a postupně dospěly to dnešního stavu, kdy jsou schopny pokrýt veškeré činnosti spojené s fungování firmy, tj. logistiku (nákup, skladování, výrobu, prodej a distribuci) a finance (finanční účetnictví a controlling). ERP aplikace dnes tvoří jádro, které postupně obalily další aplikace jako je např. řízení vztahu se zákazníky (Customer Relationship Management - CRM) či naopak s dodavatelským řetězcem (Supply Chain Management – SCM) a analytické informační nástroje (Business Intelligence - BI). Pro takto komplexní informační systémy se pak používá zkratka ERP II. Typickými představiteli jsou řešení dodávané společnostmi, jako je SAP či Oracle. S ohledem na téma této práce je ale důležité, co je výstupem z ERP systémů. Jak bylo uvedeno, jedná se o systémy transakční. Typickým příkladem transakce je příjem a zpracování faktury od dodavatele. Ve finančním oddělení jsou data z faktury přepsána do ERP systému, doklad je zaúčtován a následně zaplacen. Data z faktury jsou pak uložena v příslušných databázových tabulkách ve strukturované podobě, tzn. sloupce představují jednotlivé atributy (např. číslo faktury, dodavatel, datum vystavení apod.) a řádky jsou pak tvořeny samotnými záznamy (201100765, Škoda Auto, 1. 11. 2011 atd.). Výstupem z jednotlivých transakcí jsou v ERP systémech data ve strukturované podobě. Jsme tedy schopni přesně popsat jejich strukturu. Vedle dat strukturovaných rozlišujeme ještě data nestrukturovaná a polostrukturovaná. U nestrukturovaných dat nelze popsat jejich strukturu pomocí metadat. Metadata jsou data popisující jiná data; někdy se používá termín popisné atributy. Příkladem nestrukturovaných dat může být např. dokument napsaný v textovém editoru. Žádný ERP systém sám o sobě nemůže z takového dokumentu identifikovat význam slov či částí textu. Co v textu např. znamená číslo 201100765? Jde o číslo faktury, kód výrobku či něco zcela jiného?

10

Přechod

mezi

strukturovanými

a

nestrukturovanými

daty

představují

data

polostrukturovaná (semistrukturovaná). Jde o v základě o data nestrukturovaná, u kterých jsem ale schopni rozpoznat alespoň část nějaké struktury. Jako příklad může uvést e-mailovou zprávu. Jde o dokument, který má částečně pevnou strukturu (příjemce, věc, datum a čas odeslání atd.), ale z vlastního textu nelze z pohledu informačního systému zjistit význam. Obrázek 1 názorně ilustruje kontinuum dat strukturovaných (databázová tabulka), polostrukturovaných (formulář) a nestrukturovaných (obrázek).

Obr. 1: Data versus dokumenty

Zdroj: GÖTZER, Klaus et al. Dokumenten-Management. 4. Auflage. Heidelberg : dpunkt.verlag, 2008. ISBN 978-3-89864-529-4, s. 33.

V literatuře2 se běžně uvádí, že zastoupení strukturovaných a nestrukturovaných dat přibližně odpovídá Paretovu pravidlu neboli poměru 20:80. Přibližně 20% dat ve společnosti existuje v podobě strukturované a 80% je nestrukturovaných. Pokud se tedy vrátíme k názvu této kapitoly, můžeme říci, že úlohou ERP systémů je zpracování dat výhradně ve strukturované podobě, kdežto doménou systémů pro správu podnikového obsahu jsou naproti tomu data nestrukturovaná a polostrukturovaná. Toto tvrzení si podrobněji vysvětlíme v následující kapitole věnované stručné historii systémů pro správu obsahu.

2

Např. zdroj: https://www-304.ibm.com/connections/blogs/DataCenter7/entry/80_20_rule2?lang=cs [online]

11

1.3. Pohled do historie Vraťme se k příkladu s pořízením faktury od dodavatele. Již někdy před čtyřiceti lety se došlé faktury začaly pořizovat výše uvedeným způsobem do ERP systémů (např. první verze finančního modulu SAP vznikla v roce 1973), tj. obsah faktury byl „rozpoznán“ pracovníkem účetního oddělení, data byla ručně přepsána do informačního systému a faktura byla zaúčtována. Zaúčtování standardně ještě předcházelo schválení příslušným zodpovědným pracovníkem či pracovníky prostřednictvím vlastnoručního podpisu. Po zaúčtování se papírový originál faktury se dal do pořadače a uložil do archivu. Z příkladu je zřejmé, že vlastní proces zaúčtování faktury do ERP systému byl doprovázen celou řadou manuálních činností nepodporovaných systémem ERP: • manuální přepsání dat z faktury do ERP systému • schválení faktury vlastnoručním podpisem (to je spojeno s fyzickým oběhem dokladu po firmě) • archivace dokladu v papírové formě (papír existuje pouze v papírové podobě a je „odtržený“ od příslušného účetního dokladu v ERP systému • komunikace kolem obchodního případu probíhala telefonicky či písemně; v 80. letech se přidala možnost faxových zpráv

A právě zájem vyřešit tyto nedostatky stál na počátku procesu, na jehož konci dnes máme k dispozici komplexní systémy pro správu podnikového obsahu. Pojďme se tedy podívat na jejich historii. Přibližně v první polovině 80. let začala vznikat první řešení, která se specializovala na digitalizaci dokumentů (tj. převedení papírového dokladu do elektronické formy), jejich bezpečnou archivaci s možností vyhledávat a distribuovat a s případným zaintegrováním do ERP systémů. Postupně se k digitalizaci přidaly technologie umožňující automatické rozpoznání znaků na dokladu a jejich převod do textové podoby. V polovině 90. let pak vývoj dále pokročil s bouřlivým rozvojem internetu a zaváděním elektronické pošty a dalších nástrojů pro podporu skupinové spolupráce (Groupware). Tato dekáda byla také charakterizována vznikem a následným rozmachem specializovaných systémů pro podporu oběhu elektronických dokumentů. Pro řízení oběhu dokumentů se často používá anglický termín „workflow“. Jde tedy o systémy podporující řízení pracovních toků či

postupů.

Pro

systémy

zajišťující

výše

12

uvedené

úlohy

spojené

s nakládáním

s elektronickými dokumenty se začal používat zastřešující pojem systém pro správu dokumentů (Document Management System - DMS). Převládajícím trendem prvního desetiletí našeho století bylo integrování jednotlivých komponent do podoby komplexního systému, který by zákazníkovi mohl nabídnout všechny funkcionality vyhovující jeho požadavkům v rámci jednoho produktu či přesněji řečeno jedné platformy. Termín ECM poprvé vymezila americká nezisková organizace AIIM (Association for Information and Image Management) v roce 2001. Zde se dostáváme k definici toho, co to vlastně správa podnikového obsahu je. ECM lze definovat např. jako „technologii, která poskytuje prostředky pro vytváření / sběr, správu / zabezpečení, ukládání / uchování / likvidaci, publikování / distribuci, prohledávání, personalizaci a prezentaci / prohlížení / tisk veškerého digitálního obsahu”3. Jde o definici spíše technologického charakteru, popisující co vše systémy ECM nabízejí. Můžeme ale použít i poněkud obecnější definici, která říká, že správou podnikového obsahu se rozumí „technologie, metody a nástroje sloužící k získávání, řízení, uložení, zachování a doručení obsahu a dokumentů vztahujících se k procesům organizace. ECM nástroje a strategie umožňují řízení nestrukturovaných informací organizace všude, kde tyto organizace existují.“4 Vývoj systémů pro správu dokumentů (DMS) byl rozvinut nejen technologicky, ale také koncepčně a systémově. Proto bylo slovo „dokument“ (Document) nahrazeno slovem „obsah“ (Content), která má širší obsah. Slovo podnik (Enterprise) ve zkratce ECM pak zdůrazňuje, že systémy ECM se nějakým způsobem týkají celého podniku. V praxi často dochází k volnému zaměňování pojmů ECM a DMS. Systémy DMS představují historicky starší pojem a dnes jsou chápány jako jedna ze součástí systémů ECM. Jaký je rozdíl mezi pojmem obsah a dokument? Slovo obsah má širší a obecnější charakter a je jím myšleno veškeré informační vlastnictví dané společnosti. Obsah samozřejmě může tvořit jak faktura v elektronické podobě (dokument), ale stejně tak to může být soubor nesoucí zvukovou či video informaci, obsah podnikového webu nebo dokonce znalost. To vše je dnes chápáno pod pojmem podnikový obsah a účelem systémů ECM je tento obsah spravovat. Pro definici pojmu dokument lze odkázat na zákon č. 499/2004 o archivnictví a spisové službě, který za dokument považuje „každý písemný, obrazový, zvukový, elektronický nebo

3

Zdroj: GÁLA, Libor; POUR, Jan; ŠEDIVÁ, Zuzana. Podniková informatika. 2.vyd. Praha: Grada Publishing, 2009. ISBN 978-80-247-2615-1, s. 157. 4

Zdroj: http://www.aiim.org/What-is-ECM-Enterprise-Content-Management [online]

13

jiný záznam, ať již v podobě analogové či digitální, který vznikl z činnosti původce“5. Z pohledu informatiky se pak dokumentem rozumí „základní jednotka dat, kterou evidujeme jako celek“6.

1.4. Životní cyklus dokumentu Pojďme se ještě jednou vrátit k příkladu se zpracováním faktury dodavatele, neboť na něm můžeme dobře demonstrovat význam základního pojmu v oblasti správy dokumentů, kterým je tzv. životní cyklus dokumentu. Stručně řečeno jde o fáze, kterými dokument může v podniku postupně procházet od přijetí (zde přijetí obálky s fakturou na podatelně), až po archivaci či případnou skartaci dokumentu po vypršení předepsané archivační doby. Obecně se rozlišují fáze pořízení, zpracování a výstupu. Na obrázku č. 2 jsou znázorněny jednotlivé fáze životního cyklu včetně konkrétních operací s dokumenty.

5

Zdroj: Zákon č. 499/2004 Sb. ze dne 30. června 2004 o archivnictví a spisové službě a o změně některých zákonů. 6

Zdroj: GÁLA, Libor; POUR, Jan; ŠEDIVÁ, Zuzana. Podniková informatika. 2.vyd. Praha: Grada Publishing, 2009. ISBN 978-80-247-2615-1, s. 143.

14

Obr. 2: Fáze životního cyklu podnikového obsahu

Zdroj: KUNSTOVÁ, Renáta. Efektivní správa dokumentů : Co nabízí Enterprise Content Management. 1. vyd. Praha : Grada, 2009. ISBN 978-80-247-3257-2, s. 29.

Základním úkolem systémů ECM je tedy poskytnou takové nástroje (komponenty), metody a strategie, které umožní zpracovat všechny fáze životního cyklu dokumentu. A právě jednotlivým komponentám je věnována následující kapitola.

15

2. Komponenty ECM Základní model ECM definovaný sdružením AIIM je zobrazen na obrázku 3. Model popisuje pět základních oblastí, které pokrývají systémy ECM: Capture, Deliver, Store, Preserve, Manage.

Obr. 3: Základní model ECM

Zdroj: http://de.academic.ru/dic.nsf/dewiki/396016 [online]

Capture (Pořízení) Pořízení a zařazení dokumentu. V praxi jde nejčastěji o převod papírových dokumentů do elektronické podoby skenováním, ale může se jednat i o začlenění již existujících elektronických dokumentů v jiných systémech (e-mailové zprávy či video záznamy) do aplikace pro správu obsahu. Dokumenty bývají klasifikovány metadata či indexy, aby je bylo možno dále řízeně zpracovávat, a často se využívají technologie pro automatické vytěžování dat.

16

Deliver (Dodávka) Zde jde o řízení výstupu, čímž je myšleno buď zpracování a zpřístupnění dokumentů uživatelům ke zpracování, nebo příprava dokumentů pro vstup do dalších systémů nebo na koncová zařízení typu mobilních telefonů.

Store (Uložení) Jde o uložení „živých“ dokumentů, tedy takových, které se ještě mohou upravovat. Do této oblasti se zařazuje zálohování a obnova dat.

Preserve (Archivace) Archivací je myšleno dlouhodobé uložení již neměnných dokumentů. Klíčovým pojmem pro archivaci je „compliance“, neboli splnění všech zákonných požadavků kladených na organizaci.

Manage (Správa) Správa obsahu a přístupu k němu. Sem se zařazují funkcionality typu správa záznamů, řízení pracovních toků (workflow) či podpora spolupráce.

Pro pokrytí všech požadavků na komplexní správu dokumentů (obsahu) se systémy ECM sestávají z celé řady komponent, které jsou vzájemně provázány a integrovány. Historicky vznikaly jednotlivé komponenty samostatně (např. e-mailové systémy a technologie pro vytěžování dat), ale vývojovým trendem posledních let je doposud víceméně samostatné komponenty provázat a integrovat do jediného funkčního celku a nabízet je zákazníkovi jako komplexní modulární řešení. V rámci ECM se nejčastěji hovoří o následujících komponentách: • Pořízení dokumentů (Capture) • Systém pro správu dokumentů (Document Management Systém) • Správa záznamů (Records Management) • Řízení pracovních toků a firemních procesů (Workflow / BPM) • Správa webového obsahu (Web Content Management) • Podpora týmové spolupráce (Collaboration)

17

• Archivace (Archiving) • Správa elektronické pošty (E-mail Management)

V následující části si stručně vysvětlíme význam každé z nich.

2.1. Pořízení dokumentů Prvním krokem bývá pořízení dokumentu a jeho předání k dalšímu zpracování. Pokud je na začátku dokument v papírové formě (listinný dokument), musí se nejprve převést do digitální podoby. Pro digitalizaci se používá anglický termín Imaging. Zařízením pro digitalizaci listinných dokumentů je skener. Skenery se vyrábějí v mnoha variantách od jednoduchých a levných kancelářských zařízení až po velmi výkonné stroje umožňující denně naskenovovat obrovské množství dokumentů. Příkladem vyspělého zařízení mohou být skenery, které používá společnost Google pro projekt digitalizace knih a které jsou schopny po vložení knihy automaticky knihu prolistovat po jednotlivých stránkách a naskenovat, nebo takzvané 3D skenery schopné snímat třírozměrné předměty. Pro výběr vhodného skeneru pro nějakou specifickou činnost je potřeba zvážit několik základních parametrů: množství a typ skenovaných dokumentů, požadovaná rychlost a kvalita obrazu skenování. Samotné naskenování předlohy je dnes běžně doplněno o tři další funkce či přesněji řečeno technologie: automatické vylepšení obrazu, automatické rozpoznání dat a jejich následné vytěžení.

Automatické vylepšení obrazu Jde o technologii, která automaticky vylepší nasnímaný obraz předlohy tak, že výsledný obraz je dokonale čitelný, i když původní předloha byla nekvalitní (např. ručně psaný doklad na průklepovém papíře). Nejznámějším produktem je dnes zřejmě Virtual Rescan od firmy Kofax. Při čištění obrazu jsou odstraněny šedivé plochy a různé nečistoty, vyhlazeny hrany písma, korigován kontrast apod. Obrázek 4 ukazuje, jak vylepšení předlohy vypadá v praxi. Vyčištění obrazu je velmi důležité jak pro čitelnost samotného obrazu, tak pro další fázi, která po naskenování může následovat a tou je automatické rozpoznání znaků písma v dokumentu.

18

Obr. 4: Ukázka funkce VRM pro vyčištění skenovaného obrazu

Zdroj: http://www.visioneer.com/vrs/ [online]

Rozpoznání znaků Jedná se o technologii, která v naskenovaném a vyčištěném dokumentu rozpozná znaky a umožní tak další následné prohledávání dokumentu či jeho vytěžení. Systémy pro automatické rozpoznávání písma jsou historicky nejstarší technologií využívanou v ECM systémech – první funkční řešení existovaly již v padesátých letech minulého století. Obecně se rozeznávají tyto technologie: • OCR (Optical Character Recognition): rozpoznávání tištěného písma • ICR (Intelligent Character Recognition): rozpoznání ručně psaného písma • OMR (Optical Mark Reading): rozpoznání zaškrtnutých značek (typicky na různých formulářích) a převedení na konkrétní hodnotu (ano/ne, a/b/c apod.) • BCR (Bar Code Reading): rozpoznání čárových kódů Po naskenování předlohy a rozpoznání znaků následuje indexace dokumentu, neboli opatření dokumenty metadaty (popisnými atributy), což je strukturovaná informace o dokumentu umožňující základní charakteristiku: druh dokumenty, datum, počet stran, zpracovatel apod. Posledním krokem je tzv. vytěžení dokumentu

2.2. Vytěžení dokumentu Technologie OCR umožní v naskenovaném dokumentu rozpoznat jednotlivé znaky. Cílem vytěžení je takto rozpoznaným znakům přidělit význam. Vytěžování dokumentu (Data Capture) se nejprve začalo používat u strukturovaných dokumentů. Příkladem mohou být různé formuláře a dotazníky s jasně definovanou strukturou. Pro takovýto dokument se

19

v systému vytvoří příslušná šablona, která jasně definuje, na jakém místě ve formuláři se nalézá jaký údaj a jaké hodnoty zde lze očekávat (např. otázka č. 1 v testu a možnost zaškrtnuté odpovědi a, b nebo c nebo pole pro PSČ na obálce dopisu). Komplikovanější situace nastává u dokumentů polostrukturovaných. Typicky se jedná např. o fakturu. Na jednu strunu sice každý dodavatel používá pro fakturu jiný formát, ale na druhou stranu lze předpokládat, že obsah faktury bude ve všech případech velmi podobný, tj. na dokladu bude datum vystavení a splatnosti, identifikační číslo odběratele i dodavatele, celková částka apod. Pro vytěžování se nejprve postupovalo stejně jako by šlo o dokument strukturovaný, ale pro každý typ dokladu (např. faktura od konkrétního dodavatele) se musela vytvořit samostatná šablona, která přesně definovala, na kterém místě dokladu se nachází jaký údaj, což bylo velmi neefektivní. V poslední desetiletí se ale prosadilo a rozšířilo sofistikovanější řešení vytěžování polostrukturovaných dat pracující s rozsáhlými sadami nadefinovaných pravidel. Příkladem takového pravidla může být hledání a rozpoznání identifikačního čísla organizace (IČ). Systém po automatickém rozpoznání znaků bude hledat na dokumentu sled znaků uložený ve slovníku (IČ, IČO, IČ:, IČO: atd.) a jakmile ho nalezne, bude předpokládat, že číslo za touto zkratkou je v tomto případě identifikační číslo organizace. Pro ověření se ještě používají různé validační kontroly (např. IČ nesmí být delší jak 12 znaků apod.). Na základě takto definovaných pravidel systém rozpozná údaje na dokumentu a výsledek předloží zpracovateli dokumentu, který na obrazovce vidí jak naskenovaný obraz, tak výsledek vytěžení a dokument verifikuje, neboli zkontroluje vytěžený text. Moderní systémy toto činnost zjednodušují tím, že při rozpoznání systém sám ohodnotí, s jakou jistotou byl text rozpoznán a je-li tato jistota menší než nastavená hodnota (např. 20%), je pole barevně zvýrazněno a obsluha ihned vidí, na jaké pole se má soustředit. Špatně rozpoznaný text je možno opravit ručně, vybrat ze slovníku či přetáhnout ručně z naskenované předlohy. Na obrázku 5 je ukázka validace. V pravé části je náhled na naskenovaný doklad a v prostřední je okno pro validaci, kde se zobrazují jednotlivá vytěžovaná pole a u každého z nich je vidět jednak automaticky nalezené zdrojové pole na dokladu a k němu přečtenou (vytěženou) hodnotu.

20

Obr. 5: Ukázka obrazovky pro validaci vytěžených dat

Zdroj: vlastní (kopie obrazovky z aplikace Kofax Transformation Modules od společnosti Kofax).

Systémy pro vytěžování dat také bývají vybaveny samoučící funkcí, takže jakmile je jednou chybně rozpoznaný text ručně korigován, systém si opravu vyhodnotí, uloží a při dalším dokladu stejného typu použije doplněné pravidlo, což neustále zvyšuje procento úspěšně rozpoznaných údajů. V případě vytěžování faktur se uvádí, že úspěšnost se pohybuje kolem 70% po instalaci systému (existují národní knihovny pravidel) a po zaběhnutí úspěšnost stoupne na hodnoty kolem 90%. Nakonec je potřeba stručně zmínit čárové kódy a jejich roli při digitalizaci dokumentů. Jak bylo uvedeno výše, technologie BCR umožňuje automaticky rozpoznat a přečíst čárový kód. Čárový kód sám o sobě je nositelem určité informace. Při digitalizaci dokumentů se čárový kód používá zejména kvůli jeho jednoznačné identifikaci (dokumentu je přiděleno interní číslo obsažené v čárovém kódu) a pro rychlé spárování dokumentu v papírové a digitální formě. Po přijetí a digitalizaci dokumentu nastává fáze jeho zpracování a k tomu slouží systém pro správu dokumentů

21

2.3. Systém pro správu dokumentů O systému pro správu či řízení dokumentů neboli DMS (Document Management System) představuje centrální a nejdůležitější komponentu v rámci ECM. V praxi se oba pojmy někdy zaměňují, ale DMS je nutno chápat jako součást ECM. Systém DMS primárně představuje centrální uložiště elektronických dokumentů a poskytuje tyto základní služby pro jejich zpracování: • řízení přístupových práv k dokumentům • správa verzí • sledování historie • vyhledávání dokumentů (fulltextové a dle metadat) • uzamčení dokumentu (základ pro konzistentní úpravu jednoho dokumentu více uživateli)

Účelem DMS systémů není práce s obsahem dokumentu. Samotná editace souboru probíhá v nějaké specializované aplikaci (např. MS Word), ale uložení souboru, jeho sdílení a správa je úkolem DMS systému. Důležitou charakteristikou je také to, že DMS primárně slouží pro ukládání „živých“ souborů, které se mohou průběžně upravovat a měnit. To odlišuje systémy DMS od systémů pro správu záznamů.

2.4. Správa záznamů Systémy pro změnu záznamů RM (Record Management) slouží pro uložení a správu již neměnných dokumentů. Záznamem se rozumí dokument, „který podléhá regulatorním opatřením a legislativním předpisům a musí s ním být v organizaci nakládáno jinak než s běžným dokumentem“7. Typickým příkladem záznamu jsou např. daňové doklady, u kterých příslušný zákon definuje, jak dlouho musí být uchovávány. Klíčovým slovem, které je často používáno v této souvislosti je „compliance“, neboli schopnost organizace dostát všem zákonným požadavkům.

7

Zdroj: KUNSTOVÁ, Renáta. Efektivní správa dokumentů : Co nabízí Enterprise Content Management. 1. vyd. Praha : Grada, 2009. ISBN 978-80-247-3257-2, s. 65.

22

Základními funkcemi RM je tedy bezpečné uložení a zpřístupnění dokumentů, schopnost systému zabezpečit a prokázat neměnnost dokumentu po celou dobu uložení, snadné vyhledání a možnost nastavit řízenou skartaci dokumentu po uplynutí nastavené doby archivace. Součástí systémů RM je nastavený archivační plán, který přesně říká, jaké dokumenty (záznamy) se budou archivovat, za jakých podmínek a po jak dlouhou dobu. Také určuje, kdo bude mít k archivovaným záznamům přístup. Aby bylo možno prokázat pravost digitálního dokumentu, využívají se k tomu účelu elektronické podpisy a značky a časová razítka. Více o nich bude řečeno v další části této práce. Systémy RM neslouží pouze pro záznamy v digitální podobě ale také pro záznamy fyzické, takové, které není možno digitalizovat. Ty je potřeba jednoznačně identifikovat (např. čárovým kódem či technologií RFID) a klasifikovat a RM systém pak pomáhá řídit jejich archivaci stejně jako u záznamů digitálních. Často se v souvislosti se správou záznamů hovoří o tzv. spisové službě. Spisovou službou se ale rozumí podpora řízení oběhu dokumentů v rámci podniku či státní instituce od přijetí až po konečné vyřízení a uzavření případu. Oblast RM je tedy primárně spojená se specifickým druhem archivace. Požadavky spisové služby jsou realizovány jinou technologií z oblasti ECM a tou jsou systémy pro řízení pracovních toků.

2.5. Řízení pracovních toků a firemních procesů Podle definice sdružení Workflow Management Coalition (WfMC) se pod pojmem workflow rozumí „automatizace nějakého podnikového procesu (celého či jen části), během kterého jsou dokumenty, informace či úlohy předávány od jednoho účastníka k druhému ke zpracování a to podle sady procedurálních pravidel“8. Typickým příkladem procesu může být již zmiňované přijetí faktury od dodavatele, zpracování, schválení, zaúčtování a proplacení. Systémy pro řízení pracovních toků umožňují nadefinovat daný proces dle zadání a tento proces pak řídit, kontrolovat a vyhodnocovat. Výše zmíněné sdružení WfMC rozlišuje čtyři základní typy workflow podle určení:

Produkční workflow: slouží pro řízení velkého množství úloh v rámci základních podnikových procesů s vysokou přidanou hodnotou. Charakteristikou je integrace systému 8

Zdroj: http://www.wfmc.org/Download-document/Workflow-An-Introduction.html [online]

23

workflow do různých podnikových aplikací a z toho vyplývající pevná struktura návrhu procesu. Administrativní workflow: určeno pro řízení podpůrných procesů uvnitř organizace. Oproti produkčnímu má administrativní workflow jednoduchý návrh a týká se většiny zaměstnanců, např. schvalování dovolené. Workflow pro podporu spolupráce: určeno pro užší pracovní skupiny, typicky spojeno s prací nad nějakým dokumentem či projektem Ad hoc workflow: pro podporu nahodilých procesů, uživateli umožňuje rychle a pohodlně nastavit požadovaný proces

Workflow systémy byly ve vyspěle podobě k dispozici již na začátku prvního desetiletí 21. století. V první fázi se víceméně jednalo o postupné posouvání nějakého dokumentu či úlohy od zadání k ukončení. Pak ale teorie managementu přišla s pojmem procesního řízení a koncept workflow systémů byl zásadním způsoben povýšen, protože tyto byly doplněny o pokročilé funkce umožňující podnikové procesy modelovat, navržený model testovat a po spuštění výsledky průběžně analyzovat a vyhodnocovat. Workflow systémy se tak staly technologickou podporou pro řízení podnikových procesů neboli Business Process Management (BPM). V BPM se využívá zejména produktivní workflow. BPM se tak stávají nástrojem pro realizaci podnikové strategie a z ní odvozených podnikových procesů. Monitorovací a analytické nástroje přispívají nejen k dosažení a udržení efektivnosti procesů, ale také k jejich neustálému zlepšování. Jednou z charakteristik BPM je integrace obsahu z různých aplikací (např. ze systémů ERP, CRM či BI) a výsledkem je schopnost komplexně navrhnout a realizovat podnikový proces na různých na sobě nezávislých infrastrukturách a aplikacích. Pokud bychom měli rozlišit BPM a workflow, můžeme říci, že „zatímco BPM pomáhá automatizovat komplexní podnikové procesy napříč organizací, workflow systémy pomáhá standardizovat interakce mezi lidmi a obsahem“9. Uvedeno na konkrétním příkladu, tak pro BPM je v případě nějakého finančního ústavu typický proces např. zpracování žádosti o hypotéku (jde tedy o proces klíčový s vysokou přidanou hodnotou) a o workflow můžeme mluvit např. v případě schválení služební cesty. 9

Zdroj: JENKINS, Tom. Managing Content in the Cloud. 1st Edition. Ontario : Open Text Corporation, 2010.

ISBN 978-0973066289, s. 189.

24

2.6. Správa webového obsahu V dnešní době je role internetu pro firmy zcela klíčová a úkolem systému pro správu podnikového obsahu (Web Content Management – WCM) je sběr, řízení a publikace podnikového obsahu prostřednictvím internetových technologií. Základním principem systémů WCM je oddělení obsahu, který připravují různí zaměstnanci podniku, od formy publikování tohoto obsahu, kterou je webová stránka. Cílem této koncepce je poskytnout garantovaný obsah v jednotném a standardizovaném prostředí. Princip je vychází z redakčních či publikačních systémů (Content Management System - CMS), ale představuje jejich rozvinutější podobu. Zejména se jedná o integraci systémů WCM s podnikovými informačními systémy, které slouží jako zdroj publikovaných dat.

2.7.

Podpora týmové spolupráce

Účel této komponenty je zřejmý: podpora efektivního způsobu spolupráce více lidí. Do této kategorie se zařazují obecně známé technologie jako je e-mail, instant messaging, intranet a extranet či podpora virtuálních týmů (vytváření webových pracovních skupin, kde se účastníci týmu sdílí dokumenty a využívají komunikační nástroje typu videokonferencí).

2.8. Archivace Archivace je poslední zde uvedenou komponentou ECM a představuje nezbytný základ pro celý systém správy dokumentů. Archivace dokumentů je obdobou fyzických archivů uskladňujících dokumenty v papírové formě. Také v případě digitální archivace jsou nejdůležitějšími požadovanými funkcemi spolehlivost uložení spolu s rychlou dostupností a řízeným vyřazováním (skartací) podle platných zákonů. V praxi existují varianty, kdy organizace vedou vedle sebe jak papírový (listinný) tak elektronický archiv a v některých případech se využívá pouze archiv elektronický, kdy se papírové dokumenty po digitalizaci skartují. Tato plně elektronická varianta je odvislá od typu dokumentu a příslušných zákonů a vyhlášek. Zjednodušeně se dá říci, že chce-li se organizace rozhodnout pouze pro elektronickou archivaci dokumentů, které podléhají zákonným předpisům (např. daňové doklady), musí technologicky zabezpečit prokázání pravosti dokumentu (tj. že dokument po dobu archivace nebyl modifikován) a jeho datování

25

(dokument vznikl v uvedeném datu). Toho se dosahuje použitím speciálních archivačních médií (např. WORM – Write Once, Read Many či UDO – Ultra Density Optical) a technologií elektronické značky a časových razítek – více v další části.

2.9. Správa elektronické pošty Elektronická pošta je základní komunikační prostředek internetu a firmy touto formou komunikují s obchodními partnery a vyřizují vnitropodnikovou agendu. V mnoha případech je e-mail využíván nejen pro sdílení informací a dokumentů, ale slouží uživatelům také jako dokumentové uložiště. Obrovská a neustále se zvětšující množství e-mailových zpráv navíc doplněných o přílohy zabírá velké množství diskového prostoru na poštovních serverech a klade zvýšené nároky na výkon a zálohování. Cena za udržování takového systému je vysoká. Navíc je celkem logické, že pouze malá část zpráv je i po delší době aktivní, neboli že se s nimi dále pracuje, popř. je z nějakého důvodu důležitá pro obchodní procesy (objednávky, sdělení apod.). Obrázek 6 názorně ilustruje, že podíl neaktivních (dočasných) e-mailových zpráv v celkovém objemu činí přibližně 85%. Smazáním těchto zpráv by tak podnik mohl ušetřit čtyři pětiny kapacity poštovního serveru.

Obr. 6: Neaktivní e-mailové zprávy zabírají až 85% diskového prostoru na poštovním serveru

Zdroj: JENKINS, Tom. Managing Content in the Cloud. 1st Edition. Ontario : Open Text Corporation, 2010. ISBN 978-0973066289, s. 103.

Právě potřeba zefektivnit proces ukládání starých zpráv stála u zrodu specializovaných systémů pro správu elektronické pošty (E-mail Management). Účelem těchto systémů je rychle a přehledně přesunout zprávy z prostředí poštovního serveru do specializovaného

26

uložiště pro dlouhodobou archivaci e-mailových zpráv. Cena za jednotku paměti je na takovém uložišti pochopitelně mnohokrát menší než na poštovním serveru. Aby komfort pro uživatele byl co nejvyšší, přesun vybrané zprávy do archivu nutně neznamená, že tuto zprávu ve svém poštovním klientu neuvidí – i nadále se zpráva zobrazuje v přehledu došlých či odeslaných zpráv, ale jedná se jen o informativní „výtah“ ze zprávy, což je rozlišenou speciální ikonou. Pokud se uživatel chce k archivované zprávě vrátit, stačí na náhled zprávy kliknout a originál se v přijatelné době obnoví, neboli vrátí zpět z archivu. Důležité při zavádění systémů pro správu elektronické pošty je, aby si firma stanovila přesný plán a politiku pro zálohování zpráv. V mnoha případech mohou e-mailové zprávy také podléhat různým legislativním opatřením a je nezbytně nutné zajistit, aby se tento druh zpráv neztratil. Vedle legislativních požadavků e-maily mohou obsahovat informace a znalosti důležité pro úspěšný provoz organizace a tato má přirozený zájem pro zachování a pohodlné vyhledání takových zpráv. V tomto případě je důležitá klasifikace, neboli jakým způsobem označit důležité zprávy, které mají být uloženy. Zde se nabízí celá řada řešení a možných přístupů a volba záleží na konkrétním případu. Klasifikace může být manuální (v takovém případě je spolehlivost vždy sporná) či automatická. Nejčastěji používaná automatická metoda je založena na individuální roli uživatele uvnitř organizace. Pro každou z takto nastavených rolí jsou nastavená zvláštní pravidla. Jiným řešením mohou být sdílené adresáře: např. konkrétní projekt má společný adresář, který je k dispozici všem účastníkům projektu v jejich emailovém systému a tento adresář je označen k zálohování. Důležitým parametrem je také nastavení, jak dlouho se mají zprávy archivovat. I zde mohou vstoupit do hry legislativní požadavky určující po jaké době je organizace povinna zprávy smazat (např. oblast ochrany osobních údajů). V případě nedodržení riskuje organizace finanční postih a to je dalším důvodem, proč firmy nasazují systémy pro správu elektronické pošty. V některých případech mohou mít e-mailové zprávy také charakter záznamu (např. daňové přiznání podepsané elektronickým podpisem) a v tomto případě některé pokročilé systémy nabízejí integraci komponenty pro správu elektronické počty s komponentou pro správu záznamů. Na závěr je nutno krátce zmínit vliv tzv. „cloudových“ (viz též kapitola 4.2 Cloud computing) řešení na archivaci e-mailů. Tento koncept radikálně přehodnocuje cenu za objem uložených dat. Např. Google v současné době nabízí ve svém řešení pro korporátní sféru standardní

27

velikost e-mailové schránky pro uživatele 25GB a za nevelký poplatek je možno úložný prostor dále zvětšovat. Obdobnou nabídku lze nalézt i u dalších firem. Tato informace má jen ilustrovat, že tlak na archivaci pouze kvůli úspoře místa na poštovním serveru postupně ztrácí na významu, ale jsou-li důvodem nasazování systému pro správu elektronické počty legislativní požadavky, kterých celosvětově neustále přibývá, pak význam takových řešení nijak neztrácí na svém významu, ba naopak vzrůstá.

28

3. Další vývoj ECM systémů ECM systémy se samozřejmě neustále dále vyvíjí a reagují na nové trendy a koncepty v oblasti informačních systémů. V této kapitole jsou stručně pojednány základní charakteristiky tohoto vývoje.

3.1. Web 2.0 Pod pojem Web 2.0 se rozumí tvorba internetového obsahu samotnými uživateli. Trend byl zahájen v prvních letech 21. století projekty typu. Wikipedia (založena na principu wiki, neboli možnost zadávání či editace obsahu přímo uživateli), následovaly blogy a diskusní fóra a dnes tento trend vrcholí tzv. sociálními médii reprezentovanými systémy jako je. Facebook či YouTube, kdy bylo přeměněno klasické schéma šíření informací formou monologu (model one-to-many) do podoby dialogu (model many-to-many). Pojem Web 2.0 znamená webové aplikace, které podporují tuto novou podobu komunikace a jde především o funkce tvorby, vyhledávání, prezentace a spotřeby informací. Důležitou charakteristikou je uzpůsobení obsahu konkrétnímu uživateli (personalizace). Webem 2.0 se také rozumí rozličné technologie využívající web jako platformu pro spolupráci a komunikaci, které existují v podobě uživatelsky jednoduchých, lehce rozšiřitelných aplikací, které jsou k dispozici v podobě on-line služeb. Co to znamená pro ECM systémy? Velmi jednoduše řečeno je to „jen“ další zdroj informací a znalostí, který je potřeba zachytit, zpracovat a efektivním způsobem využít ve prospěch fungování dané firmy. „Kombinací nástrojů pro spolupráci a sociální média ECM 2.0 vytváří kontext pro obsah, umožňuje propojit lidi za účelem tvorby nových myšlenek, které jsou základem pro inovaci“10. V praxi se dopad týká zejména modulu pro správu webového obsahu a modulu pro podporu týmové spolupráce. Stručně řečeno jde o integraci služeb spojovaných s konceptem Web 2.0 (blogy, sociální sítě, wiki, sdílení videa, mashups atd.) do prostředí podnikových webů, kde slouží jako další nástroje podporující produktivitu práce a jejich zapojení do budování a rozšiřování znalostní báze podniku. 10

Zdroj: JENKINS, Tom. Managing Content in the Cloud. 1st Edition. Ontario : Open Text Corporation, 2010.

ISBN 978-0973066289, s. 16.

29

3.2. Cloud computing Cloud computing není přesný technický pojen, ale jde spíše o metaforu konceptu, který spojuje webové technologie (přesněji řečeno webové služby) a poskytované dle potřeby zákazníka z datových center disponujících obrovským výpočetním výkonem a paměťovou kapacitou. Zákazník si pořizuje a konzumuje jednotlivé služby, aniž by ho musela zajímat konkrétní technologie. Koncept cloud computingu slibuje revoluční změnu v oblasti informačních technologií, protože se v něm jedná o hlavně o „pronájem“ konkrétní požadované služby a mnohem méně či vůbec o nákup a správu fyzické infrastruktury. Ve své podstatě to je obdoba toho, jakým způsobem spotřebováváme služby typu dodávka elektřiny či vody, kde nás nezajímá, jak se k nám služba dostane, a platíme jen za spotřebovanou část. Tento model dodávky se nazývá SaaS (Software-as-a-Service) a jde tedy o pronájem aplikací. Existují ještě další dva modely a to IaaS (Infrastructure-as-a-Service), kdy si zákazník pronajme pouze konkrétní technickou infrastrukturu (servery a datová uložiště) a PaaS (Platform-as-a-Service), kdy si zákazník pronajme vybranou platformu (operační systém a vývojové prostředí) a nad ní si přes standardizovaná rozhraní vytváří vlastní aplikace. Cloud computing se pochopitelně začal využívat i pro komponenty ECM systémů a to nejčastěji dle modelu SaaS, kdy velcí dodavatelé nabízejí zákazníkům k „pronájmu“ služby ECM jako jsou nástroje pro skupinovou spolupráci, správu dokumentů včetně archivace, řízení pracovních toků atd. Všechny jsou přístupné přes internetový prohlížeč, takže jediné, co zákazník potřebuje je přístup k internetu. V případě cloud computingu nabývají na důležitosti aspekty ochrany dat, zabezpečení pro případ pádu systému a s tím související obnova dat.

3.3. Další vývojové trendy v oblasti ECM Zajímavým trendem je rychlé pronikání aplikací typu Open Source Software (aplikace je zdarma k dispozici a zákazník si může upravovat zdrojový kód) do oblasti ECM produktů. Výhodou jsou nižší pořizovací náklady a náklady za údržbu. Nevýhodou je nižší úroveň podpory. Tato nevýhoda se postupně zmenšuje s tím, jak přibývá instalací Open Source produktů mezi zákazníky.

30

Dalším trendem je nejen neustálé prohlubování integrace jednotlivých komponent ECM systémů mezi sebou, ale hlavně v integrování s ERP systémy. Vrátíme-li se na začátek, můžeme říci, že se začíná postupně smazávat propast mezi strukturovanými a nestrukturovanými daty. Uživatel si tak dnes např. na jedné obrazovce může prohlížet u zákazníka jak data nestrukturovaná pocházející z ECM systému (smlouvy, digitalizované objednávky, záznamy o návštěvách obchodníků apod.), tak i data strukturovaná, jejichž zdrojem je ERP systém či spíše datový sklad (např. obrat za požadované časové období na úrovni konkrétního produktu, obrat a marže kumulovaně za celou firmu atd.).

31

4. Legislativa a standardy V textu již několikrát zaznělo slovo „compliance“, neboli splnění všech zákonných požadavků kladených na organizaci. Potřeba splnit všechny nároky legislativních předpisů je jedním z hnacích motorů pro pořizování a nasazování řešení ECM. Jednotlivé země, průmyslová odvětví či organizace neustále produkují nespočetné množství zákonů, směrnic, nařízení a standardů a úkolem firem je zajistit fungování firmy tak, aby těmto zákonům a nařízením vyhověla a to co nejefektivnějším způsobem. V opačném případě se firma může vystavit peněžitým pokutám, ztrátě důvěryhodnosti u svých zákazníků či dokonce může riskovat nucené zastavení činnosti. Počet existujících regulací dramaticky narostl jednak po sérii finančních skandálů v prvním desetiletí 21. století (viz případy pádů firem jako Enron či WorldCom), tak během finanční krize, kde se ukázalo, že stávající regulace buď zcela selhala, nedostačovala či vůbec neexistovala. Odhaduje se, že dnes celosvětově existuje více jak sto tisíc základních předpisů. Obrázek 7 Jenkins ukazuje několik z nich.

Obr. 7: Přehled základních předpisů

Zdroj: JENKINS, Tom. Managing Content in the Cloud. 1st Edition. Ontario : Open Text Corporation, 2010. ISBN 978-0973066289, s. 38.

32

To je důvodem, proč je dnes pojem „compliance“ tolik skloňován a ostře sledován ze strany akcionářů či vlastníků podniku. Cílem je „zabezpečit, že vnitropodnikové procesy jsou nastaveny konzistentním způsobem, kritické informace jsou řízeny a zaměstnanci byli vyškoleni a jsou schopni (spolu)pracovat v rámci nastavených standardů.“11 Z výše uvedeného vyplývá, že systémy ECM představují klíčovou technologii pro dodržování „compliance“. Každá organizace generuje během svého podnikání dokumenty a probíhají v ní podnikové procesy. Obojí se stává předmětem různých zákonných předpisů a standardů a právě systémy ECM jsou ze své definice technologickým nástrojem na podporu a řízení těchto vstupů a výstupů a dokumentace průběhu podnikových procesů. Hlavními komponentami ECM pro dodržování souladu s legislativou je archivace pro zajištění bezpečného uložení definovaných živých dokumentů a jejich efektivní vyhledávání, dále komponenta pro správu záznamů, tj. takových dokumentů, které mají charakteristiku záznamu (jsou neměnné) a u nichž je potřeba řídit celý životní cyklus (neboli od vzniku po smazání záznamu) a poslední důležitou komponentou s ohledem na zajištění „compliance“ je řízení podnikových procesů (BPM). Jakmile si (velmi zjednodušeně řečeno) organizace nastaví procesy, pak BPM velmi výrazně zjednodušuje a zefektivňuje jejich průběh, protože se stará nejen o průběh celého procesu (resp. jednotlivých úloh, z nichž se proces sestává), ale umožňuje také procesy navrhovat a vyhodnocovat. Nyní se podíváme na některé legislativní předpisy a standardy a začneme u zahraničních.

4.1. Mezinárodní předpisy a standardy Ze zahraničních předpisů si můžeme uvést americký zákon Sarbanes-Oxley Act (SOX), který předepisuje dokladovatelnost všech klíčových účetních operací. Účetnictví musí být vedeno dle mezinárodního standardu (US GAAP či evropský IFRS). Vedle toho předepisuje systém pravidelných vnitřních kontrol, které by měly vést především k odhalování kritických míst či nedodržování pracovních postupů a k přijímání nápravných opatření. Zákon vznikl 11

Zdroj: JENKINS, Tom. Managing Content in the Cloud. 1st Edition. Ontario : Open Text Corporation, 2010.

ISBN 978-0973066289, s. 53.

33

jako reakce na finanční skandály a jeho hlavním cílem je zabezpečit, že prezentované informace o hospodaření podniku jsou důvěryhodné a spolehlivé. Dalším důležitým americkým zákonem je Health Insurence Portability and Accountability (HIPAA), který se týká nakládání se záznamy o pacientech (zdravotnická dokumentace včetně záznamů z vyšetření apod.). Zákon ukládá povinnost, aby elektronicky uchovávaná data byla prokazatelná (tj. nemohlo dojít k dodatečné úpravě), aby bylo zajištěno bezpečné zálohování dat a přístup k nim. Jde sice o americké zákonné normy, ale díky globalizaci se tyto zákony (mnohdy v upravené verzi) skrze dceřiné společnosti amerických firem rozšířily do celého světa a mimo území USA bývají mnohdy přijímány jako standard de jure. Z evropských zákonných norem je třeba uvést tzv. Basel II, což je soubor pravidel a postupů vedoucích k zajištění finanční stability bank. Jde o metodiku, která slouží ke zjištění tzv. kapitálové přiměřenosti – jinými slovy solventnosti bank. Pokud jde o standardy (tj. požadavky, které sice nevyplývají ze zákona, ale které je ale možno či v některých případech dokonce nutno přijmout) tak v mezinárodním prostředí se dnes především jedná o normu ISO 9001, která specifikuje základní požadavky na tzv. systém řízení jakosti v organizacích (Quality Management System - QMS). Norma je určena pro organizace, které potřebují prokázat svoji schopnost trvale poskytovat produkty v souladu s příslušnými předpisy a požadavky svých zákazníků a její implementace tedy slouží organizacím především k prokázání vlastní důvěryhodnosti nejen před odběrateli (a to i potencionálními v případě účasti ve výběrových řízení), ale také před dalšími partnery jako jsou např. banky, investoři či veřejná správa. ISO 9001 je primárně zaměřeno na systematické zvyšování spokojenosti zákazníka a je navrženo na trvalé zlepšování celého systému. Norma ISO 9001 je nejpoužívanější normou z řady ISO 9000, která byla poprvé definována v polovině osmdesátých let minulého století a která prošla celou řadou revizí. Normy byly nejprve převzaty Evropskou unií (European Norms – EN) a následně zařazeny do soustavy českých (technických) norem ČSN. Jedná se o následující normy: ČSN EN ISO 9004:2001 (Směrnice pro zlepšování výkonnosti), ČSN EN ISO 9000:2006 (Základní principy a slovník) a ČSN EN ISO 9001:2009 (Požadavky). Všechny výše uvedené legislativní předpisy a standardy se týkají fungování organizací a systémy ECM slouží „pouze“ jako podpora správy a řízení dokumentů a podnikových procesů. Systém ISO ale obsahuje také normy, které se přímo dotýkají oblasti správy dokumentů. Jde o normu ISO 15489, která se zaměřuje na správu záznamů a to v rámci celého životního cyklu záznamu od vzniku až po případnou likvidaci. ISO 15489 byla následně rozšířena normou ISO 23081, která upřesňuje použití metadat při správě záznamů. 34

Samotným metadatům je pak ještě věnována samostatná norma ISO 15836, která vznikla přijetím standardu Dublin Core, který definuje standard metadatových prvků sloužící pro vyhledávání v elektronických zdrojích. Standard Dublin Core je součástí systémů ECM. V další části se budeme věnovat české legislativě, která souvisí s tématem této práce.

4.2. Legislativa v České republice Také legislativa České republiky nemohla nereagovat na technologický pokrok a přibližně od roku 2000 se objevují zákony, které se dotýkají správy elektronických dokumentů a zacházení s nimi. Druhým zásadním popudem byl vstup do Evropské unie a přebírání unijní legislativy. Z nejdůležitějších zákonů zde můžeme uvést zákony a vyhlášky o svobodném přístupu k informacím (1999), ochraně osobních údajů (2000), informačních systémech veřejné správy (2000), elektronickém podpisu (2000 a 2004), elektronických podatelnách (2004), archivnictví a spisové službě (2004 a 2009), elektronických úkonech a autorizované konverzi dokumentů (2008 a 2009) a informačním systému datových schránek (2009). V následující části si vysvětlíme jednotlivé pojmy, neboť se s nimi bude pracovat v praktické části práce.

4.2.1.

Dokument

Zákon 499/2004 Sb. o archivnictví a spisové službě v paragrafu d definuje dokument jako „každá písemná, obrazová, zvuková nebo jiná zaznamenaná informace, ať již v podobě analogové či digitální, která byla vytvořena původcem nebo byla původci doručena“. Důležité je, že zákon alespoň v takto obecné rovině klade na roveň dokumenty v klasické listinné podobě a dokumenty elektronické (také se používá pojem datová zpráva). Takže z právního pohledu je listina i datová zpráva dokument a oboje je považováno za písemnost. Nikde není řečeno, že písemností je myšlen dokument na papíře. Písemnost by bylo možno definovat jako hmotný nosič, který obsahuje určitou informaci. Tato informace byla někým zapsána, aby mohla být později přečtena určitou osobou. Jestliže dokument vznikl nejprve jako listina a tato byla následně digitalizována, hovoříme o faksimile. Pokud dokument vnikl v elektronické podobě, jde o digitální dokument. V obou případech se ale jedná o elektronický dokument. V praxi se hlavně řeší první situace, tj. digitalizace listinného dokumentu do elektronické podoby. V tomto případě je z právního pohledu klíčovým problémem jednak věrnost a

35

přesnost převodu do digitální formy, dále dokazování pravosti dokumentu a nakonec uchování digitálních dat (např. zákon o DPH přesně vymezuje, po jak dlouho dobu musí být uchovávány daňové doklady). Pokud bychom se vrátili k našemu příkladu s digitalizací došlých faktur, tak předpokládejme, že organizace po naskenování faktury papírovou fakturu kvůli úspoře nákladů za archivaci ihned skartuje. Otázkou pak je, jak bude před finanční kontrolou dokazovat, že digitální obraz faktury skutečně vznikl k deklarovanému datu převzetí (což souvisí s účetním období a odpočtem DPH) a že přesně odpovídá originálnímu dokumentu, neboli že nejde o digitální padělek. Základní technologie, které slouží k prokázání pravosti, jsou elektronický podpis nebo elektronická značka, časové razítko a zajištěné uložiště. Pokud jde o praxi, tak obecně se sice stav české legislativy chápe tak, že umožňuje uchovávání pouze elektronických dokumentů, ale díky tomu, že zákony bohužel nejsou zcela konzistentní a důsledné, dostávají se firmy do konfliktů se státními orgány a výsledkem většinou bývá, že po naskenování jsou papírové předlohy ihned uloženy do archivu pro případ důkazní nouze a oběh dokumentu probíhá jen v jeho elektronické podobě (faksimile).

4.2.2.

Elektronický podpis a elektronická značka

Obecně lze říci, že elektronický podpis má na elektronickém dokumentu zcela stejný význam jako vlastnoruční podpis na dokumentu listinném. Funkce obou forem podpisu je tedy stejná, ale liší se ve způsobu, jakým byly vytvořeny. Elektronický podpis je prostředek identifikace (zajištění totožnosti) a autentizace (ověření totožnosti) při elektronické komunikaci. Z technického pohledu jde o „údaje v elektronické podobě, které jsou připojené k datové zprávě nebo jsou s ní logicky spojené, a které slouží jako metoda k jednoznačnému ověření identity podepsané osoby ve vztahu k datové zprávě“12. V praxi se pod pojmem elektronický podpis rozumí podpis s využitím tzv. komerčního certifikátu, což je certifikát vzniklý na vztahu komerčních subjektů. Typickým příkladem využití takového certifikátu může být elektronické bankovnictví či podepisování zpráv elektronické pošty. Certifikát sice obsahuje údaje potřebné pro autentizaci podepsané osoby, ale z pohledu české legislativy nemůže být akceptován pro komunikaci se státními orgány.

12

Zdroj: Zákon č. 499/2004 Sb. ze dne 30. června 2004 o archivnictví a spisové službě a o změně některých zákonů.

36

Z toho důvodu zákon definuje také tzv. zaručený elektronický podpis, který původní definici rozšiřuje o další funkce uvedené v zákoně: • „je jednoznačně spojen s podepisující osobou, • umožňuje identifikaci podepisující osoby ve vztahu k datové zprávě, • byl vytvořen a připojen k datové zprávě pomocí prostředků, které podepisující osoba může udržet pod svou výhradní kontrolou, • je k datové zprávě, ke které se vztahuje, připojen takovým způsobem, že je možno zjistit jakoukoliv následnou změnu dat“13

Důvěryhodnost je zde zabezpečena (důvěryhodnou) třetí stranou. Jde o tzv. certifikační autoritu, neboli firmu, která vydává certifikáty a zajišťuje jejich ověřování. Pro komunikaci se státní správou je ale potřeba mít tzv. kvalifikovaný elektronický podpis, což je podpis opatřený kvalifikovaným certifikátem, neboli certifikátem od jedné ze státem přesněji řečeno Ministerstvem vnitra - akreditovaných certifikačních autorit. Technicky spočívá zaručený elektronický podpis na principu asymetrické kryptografie využívající tzv. soukromý a veřejný klíč a funguje tímto způsobem: nejprve se ze zprávy, kterou chceme elektronicky podepsat, za pomoci speciálního algoritmu (tzv. hashovaní funkce) vytvoří tzv. otisk či výtah dokumentu (hash). Otisk se používá z čistě praktických důvodů, protože algoritmus umožňuje z jakkoli velké zprávy vytvořit výstup o konstantní délce (velikost otisku bývá několik stovek bitů) a platí, že otisk je vždy naprosto jedinečný pro konkrétní zprávu a dal by se přirovnat k otisku prstu na listinném dokumentu. Pokud by se zpráva sebeméně upravila, vždy se tím změní i výsledný otisk. Jde o jednosměrnou funkci; z otisku se nikdy nedá vytvořit původní zpráva. Takto vzniklý otisk se následně zašifruje soukromým klíčem podepisující osoby. Původní zpráva se nešifruje, neboť to není primárně účelem elektronického podpisu. Příjemce zprávy dešifruje došlý otisk zprávy použitím veřejného klíče odesílatele (veřejný klíč vzniká výpočtem se soukromého klíče a ověření pravosti veřejného klíče je úkolem certifikační autority). Jestliže se příjemci podaří zprávu dešifrovat, má jistotu o identitě autora otisku. V druhém kroku se z došlé zprávy vygeneruje otisk zprávy, a jestliže se tento shoduje s dešifrovaným otiskem, má příjemce jistotu nejen o identitě odesílatele ale i o tom, že zpráva nebyla v průběhu přenosu nijak upravena. 13

Zdroj: Zákon č. 227/2000 Sb. ze dne 29. června 2000 o elektronickém podpisu a o změně některých dalších zákonů.

37

Vedle elektronického podpisu existuje i tzv. elektronická značka. Technicky jde o elektronický podpis, ale rozdíl je ve vlastníkovi. Zatímco elektronický podpis je svázán s konkrétní fyzickou osobou, tak elektronická značka patří osobě právnické. Bylo-li řečeno, že elektronický podpis je obdobou otisku prstu, tak elektronická značka odpovídá otisku úředního razítka. V praxi se elektronická značka využívá tam, kde je třeba ze zákona důvěryhodným způsobem označovat velké objemy datových zpráv v krátkém časovém období a kde využití zaručeného elektronického podpisu nepřichází z organizačních či finančních v úvahu. Příkladem mohou být agendy typu automatické potvrzení příjmu elektronických zpráv.

4.2.3.

Časové razítko

Pojem časové razítko je úzce spojen s elektronickým podpisem a řeší problém s prokázáním data podpisu. Elektronický podpis totiž neobsahuje důvěryhodnou informaci o tom, kdy elektronický podpis vznikl a zda podepsaný dokument skutečně v té době existoval. Při elektronickém podpisu je převzat systémový čas počítače a ten pochopitelně nemá žádnou právní váhu. Z toho důvodu vznikla technologie časových razítek a ta zajišťuje jak prokazatelné určení data podpisu, tak důkaz existence daného dokumentu (zprávy) před uvedeným časem. Technicky je časové razítko obdobou elektronického podpisu: ze zprávy se vytvoří otisk, který se odešle třetí straně, tzv. autoritě časových razítek (Time Stamping Authority - TSA), která vrátí elektronicky podepsaný otisk obsahující datum a čas vystavení, identifikaci autority a sériové číslo časového razítka. Časové razítko se používá např. v elektronických podatelnách, při uzavírání smluv, v internetových obchodech, ale technologie také řeší problém u dokumentů s dlouhou archivační dobou. V praxi se může lehce stát, že je potřeba ověřit platnost podpisu v okamžiku, kdy původní certifikáty ztratily svoji platnost (vystavují se totiž standardně na dobu jednoho roku). Pokud chybí důvěryhodný údaj o datu vzniku dokumentu, nelze prokázat platnost podpisu v době platnosti certifikátu. Podobně časová razítka řeší situaci, kdy dojde např. ke krádeži soukromého klíče podepisující osoby a jeho zneužití. Certifikační autorita vydaný certifikát po nahlášení ztráty přidá na seznam zneplatněných certifikátů, ale bez časového razítka pak není možné prokázat, který dokument byl podepsán skutečným vlastníkem a který osobou, která klíč zneužila, tj. osobou, které dokument podepsala již v době zneplatnění certifikátu.

38

V praxi se pak postupuje tak, že se použijí obě technologie – elektronický podpis a časové razítko – a tím se propojí identita osoby podepisující konkrétní dokument (a zaručí jeho neměnnost) s časovým okamžikem, před kterým dokument prokazatelně existoval.

4.2.4.

Datová schránka

Vznik datových schránek umožnil zákon č. 300/2007 Sb., který datovou schránku definuje jako „elektronické úložiště, které je určeno k

a) doručování orgány veřejné moci, b) provádění úkonů vůči orgánům veřejné moci, c) dodávání dokumentů fyzických osob, podnikajících fyzických osob a právnických osob.“14

Jinými slovy jde o typ zvláštní schránky se zajištěným vysokým stupněm bezpečnosti, jejímž prostřednictvím dochází k výměně dokumentů jednak mezi jednotlivými orgány státní správy, dále mezi těmito orgány a firmami, popř. občany a mezi jednotlivými firmami pro výměnu vybraných dokumentů obchodního charakteru (např. faktury).

4.2.5.

Elektronické podatelny

Jde v podstatě o elektronickou verzi klasické podatelny. Účelem je přijímat datové zprávy podepsané zaručeným elektronickým podpisem a mohou to být různé elektronické dokumenty doručené na paměťových nosičích či zprávy elektronické pošty. Elektronické podatelny vznikly kvůli zefektivnění komunikace orgánů veřejné správy s právnickými či fyzickými osobami a slouží jak k příjímání, tak také odesílání datových zpráv. Elektronické podatelny mohou těžit z existence pokročilých systémů ECM, které umožňují dokumenty evidovat, pohodlně vyhledávat, řídit oběh úkolů spojených se zpracováním zprávy či tento proces automatizovat. Dalšími výhodami je zvýšení bezpečnosti a možnost pohodlného sdílení dokumentů mezi jednotlivými institucemi. V souvislosti s datovými schránkami a elektronickými podatelny je nutno ještě zmínit pojem spis.

Je to opět obdoba spisu papírového, neboli skupina dokumentů (v tomto případě

elektronických), které se týkají jednoho úředního případu. Z pohledu systémů ECM jde o 14

Zdroj: Zákon č. 300/2008 Sb. ze dne 19. srpna 2008 o elektronických úkonech a autorizované konverzi dokumentů.

39

možnost slučovat elektronické dokumenty (ale i audio či video záznamy) pod jednu hlavičku – spisovou značku. V následující kapitole se budeme věnovat tématu této práce v širší perspektivě – předmětem zájmu bude vtah systémů ECM a podnikové strategii.

40

5. ECM v rámci podnikové strategie Systémy ECM patří ke komplexním produktům, které mají pro danou organizaci strategický význam. Rozhodnutí pro jejich nasazení je strategicky stejně důležité jako např. výběr podnikového informačního systému, systému pro řízení vztahů se zákazníky či Business Inteligence. Implementace ECM systému představuje pro každou organizaci náročný úkol, který je nutně spojen s velkými finančními náklady, vyžaduje množství volných lidských zdrojů a znamená zásadní změnu pro fungování organizace, kdy se mění stávající procesy a způsob práce s podnikovým obsahem (nestrukturovanými daty). Systémy ECM jsou oproti ostatním výše uvedeným strategickým IT produktům specifické v tom, že se týkají většiny zaměstnanců, protože téměř ve všech podnikových procesech hrají dokumenty (tedy hlavní předmět ECM) důležitou roli. Implementace ECM systému také dlouhodobě mění a určuje způsob, jakým organizace zpracovává a řídi oběh a uchování svých dokumentů a podnikového obsahu vůbec. Jde tedy ve všech ohledech o rozhodnutí strategické a mělo by logicky zapadat do celkové strategie podniku. Strategie podniku by se měla v ideálním případě odvíjet od poslání firmy, což je základní a stručná definice vysvětlující vlastní smysl existence firmy. Z poslání pak vychází vize, která rámcově definuje, kam chce firma dlouhodobě směřovat a jak způsobem se má rozvíjet. Rozpracování vize do konkrétní podoby je úkolem podnikové strategie, která formuluje konkrétní cíle a činnosti podniku v dlouhodobém horizontu (většinou do pěti let). Rozpracování podnikové strategie pak vznikají dílčí strategie pro jednotlivé oblasti a jednou z těchto strategií je i strategie informační, jejímž cílem je „formulovat základní koncept dalšího rozvoje informatiky, tzn. vymezit hlavní možnosti a úlohy v rozvoji IS/ICT po stránce obsahové, technologické i organizační“15. Informační strategie tak slouží jako základní nástroj pro dlouhodobé řízení rozvoje a provozu informatiky. Tvorba každé strategie (podnikové i dílčí) se sestává z několika kroků. Nejprve je potřeba analyzovat současný stav, aby organizace přesně věděla, kde se nachází. V dalším kroku se formuluje, kam se chce organizace dostat – tedy určit si cíle. Je-li znám cíl, je třeba rozmyslet způsob (strategii), jakým je možno cíle dosáhnout. Po výběru vhodné strategie se může 15

GÁLA, Libor; POUR, Jan; ŠEDIVÁ, Zuzana. Podniková informatika. 2.vyd. Praha: Grada Publishing, 2009. ISBN 978-80-247-2615-1, s. 387.

41

přikročit k její implementaci. Po implementaci je třeba nový stav monitorovat a vyhodnocovat. Informační strategie je (či by měla být) nedílnou součástí strategického řízení podniku a v žádném případě by se nemělo jednat jen o výhradní záležitost oddělení informačních technologií. Pokud tedy firma zvažuje nasazení systému ECM – přesněji řečeno určitých komponent – měla by mít velmi dobře promyšleno, jak tento systém bude zapadat do stávající infrastruktury, jak budou jednotlivé komponenty integrovány mezi sebou a dalšími systémy, jaký bude dopad na procesy probíhající uvnitř podniku, jak se změna dotkne jednotlivých uživatelů a samozřejmě by měly být jasně definované také přínosy včetně přínosu pro naplňování dlouhodobých podnikových cílů. Protože se jedná o tak komplexní infrastrukturu, je nutno se vyvarovat nepromyšlených kroků, kdy se pod tlakem nějakého konkrétního požadavku pořídí komponenta, která sice daný problém vyřeší, ale bude se jednat o izolovanou technologii, která se lehce může stát brzdou rozvoje v dlouhodobé perspektivě, protože bude spotřebovávat neadekvátní množství podnikových zdrojů. Pří rozhodnutí nasadit ECM systém – tedy zpracovávat a řídit nestrukturovaná data v podniku – je vhodné směrovat ke standardizaci; tedy k omezení komplexnosti a technologické rozmanitosti. Pro rozhodnutí o strategii pro ECM je nutno vedle strategických cílů podniku (jak je bude ECM konkrétně podporovat) také zvážit další faktory. Jedním z těchto faktorů jsou regulatorní požadavky. Je nutno dobře analyzovat, jaké zákony, vyhlášky či standardy ovlivňují činnost daného podniku. Jde o témata jako je ochrana dat a přístup k nim, sledování historie, ochrana proti nežádoucím změnám, zabezpečení likvidace dokumentů apod. Dalším faktorem je nabídka systémů ECM na trhu a jejich praktická realizovatelnost. Jak bylo uvedeno, cílem by měla být standardizace celého systému,

odmítnutí

proprietárních

řešení

a

nestandardních

formátů,

minimalizace

individuálních změnových požadavků a nejrůznějších výjimek. Také počet dodavatelů by měl být co nejvíce redukován. Důležité je rovněž zvážit provoz systému. Jak bylo popsáno, systémy ECM se sestávají z množství komponent a firma by měla velmi dobře analyzovat a rozhodnout, které komponenty bude (a v jakém pořadí a rozsahu) nasazovat. Implementace systému ECM nikdy není jednorázový projekt, ale staví se postupně. V praxi se velmi často začíná vybudováním datového uložiště doplněného o systém pro správu dokumentů, pak se přidají komponenty pro podporu týmové spolupráce a systémy pro správu webového obsahu (zejména řešení podnikového portálu). 42

Důležité je, aby organizace byla nejprve schopna přesně definovat svoje potřeby na základě důkladné analýzy a definovat požadovaný cílový stav. Musí být zcela jasně definováno, jaké cíle se sledují nasazením systému ECM. Je-li jediným cílem snížení nákladů, nikdy nebude možno plně využít potenciál, který systémy ECM nabízejí. Další důležitou otázkou je, jakým způsobem bude nový systém pořízen a provozován. Systémy ECM se nijak neliší od dalších aplikací podnikové informatiky a je tedy možno zvažovat několik základních modelů:

5.1. Nákup aplikace Jde o stále nejčastěji používaný způsob, kdy si organizace koupí specializovaný produkt a vybere dodavatele, který systém nastaví („customizuje“) dle zadání. Předpokládá se, že v v tomto případě je aplikace také provozována na vlastní infrastruktuře. Výhodou je, že organizace má celý systém plně ve své správě a nastavený dle vlastních požadavků. Naopak nevýhodou je náročnost, cena implementace a náklady na správu. Není-li přesně formulovaná cílová funkcionalita systému a projekt řízen příslušně profesionálním způsobem (a to jak ze strany dodavatele tak i zákazníka), plánované náklady se mohou díky dodatečným změnovým požadavkům dramaticky zvýšit a s nimi pochopitelně i doba realizace. Výjimkou nejsou ani projekty, které se nepodařilo vůbec dokončit. Organizace také může zvážit pořízení open source produktu. V tomto případě ušetří peníze za pořízení licencí, ale pochopitelně musí i zde počítat s náklady na implementaci a na pořízení technické infrastruktury. Obecně se dá říci, že nákup komerčního produktu je pochopitelně dražší, ale firma může počítat jednak s rychlejší implementací, neboť implementační modely bývají založeny na praxí ověřených technikách a postupech, tzv. best practices. Díky tomu i provozní podpora bývá kompetentnější než v případě produktů založených na open source. Ty si vybírají především menší firmy, jejichž požadavky na systém nebývají tak komplexní a kterým nevadí výše uvedené nevýhody a mohou tak významně těžit z nižší pořizovací i provozní ceny. Varianta provozování aplikace ve vlastní režii rovněž klade značné nároky zdroje oddělení informačních technologií, které musí pořídit a udržovat infrastrukturu, na které je systém provozován: databázové a aplikační servery, zálohovací zařízení, skenovací pracoviště apod. Aby se náklady spojené s pořízením a provozováním aplikace minimalizovaly, vznikl model ASP.

43

5.2. Vzdálené poskytování služeb (ASP) Model ASP (Application Service Provider) znamená oddělení vlastnictví dané aplikace od jejího používání. Zjednodušeně řečeno jde o to, že poskytovatel služeb ASP pořídí a provozuje aplikaci na vlastní infrastruktuře a nabízí zákazníkům její využívání přes vzdálený přístup, buď prostřednictvím webového prohlížeče, nebo speciálního klienta. Organizace tak nemusí řešit náklady a problémy spojené s pořízením a provozováním aplikace, tj. nemusí investovat do softwaru a hardwaru, používání aplikace se stává nezávislé na konkrétním místě, nemusí se zvyšovat personální náklady a řešit průběžnou aktualizaci programového vybavení. Místo investičních nákladů, které není možno dát po pořízení cele do nákladů, platí zákazník „pouze“ za průběžné používání. Větší ekonomická výhodnost tohoto řešení spočívá na faktu, že poskytovatel služeb ASP provozuje na jedné infrastruktuře systém pro více zákazníků najednou a tím se mohou náklady efektivněji rozdělit mezi více subjektů. Z tohoto faktu ale také mohou plynout nevýhody, neboť aby mohl být systém provozován pro více zákazníku najednou, musí logicky dojít k jisté standardizaci, která může být pro některé případné zájemce příliš omezující. Problematickým se také může ukázat požadavek na hlubší integraci systému s dalšími aplikacemi u zákazníka. Model ASP přináší rovněž nové požadavky na zajištění vztahu mezi poskytovatelem a zákazníkem. To je předmětem smlouvy o poskytování služeb (Service Level Agreement SLA), kde je nutno přesně specifikovat obsah a rozsah poskytovaných služeb, jejich dostupnost, postup řešení vzniklých problémů a garantovanou dobu řešení, zabezpečení dat apod. Dále je nutno věnovat pozornost tomu, aby způsob vyúčtování byl zcela transparentní (včetně sankcí při nedodržení stanovených podmínek). Nesmí být opomenut ani způsob a podmínky, jakými může dojít ke zrušení smlouvy a jak bude odchod od poskytovatele přesně realizován. Model ASP je dnes vnímám jako překonaný. To, že poskytovatel služeb není autorem poskytované aplikace, ale pouze si ji pronajal od výrobce a provozuje ji na své infrastruktuře a aplikace je sdílena více zákazníky, kteří musí mezi sebou určitý nezbytný funkční standard, je příčinou, že zákazník nemůže dostat potřebnou flexibilitu (a ztížená možnost inovace je kritický faktor v současné ekonomice), resp. pouze za cenu neadekvátních nákladů. ASP ale představoval odrazový můstek pro další model pořízení a provozu aplikace, kterým je tzv. SaaS.

44

5.3. Software jako služba (SaaS) Princip modelu SaaS je obdobný modelu ASP a přímo z něj vychází: poskytovatel služeb typu SaaS provozuje aplikaci na své infrastruktuře a tuto aplikaci (přesněji řečeno služby poskytované aplikací) nabízí zákazníkům prostřednictvím webových služeb přístupných přes internet z webového prohlížeče. Zatímco ale v případě ASP jsou provozovány klasické monolitní podnikové aplikace pouze na sdílené infrastruktuře poskytovatele, u SaaS jde o pružné aplikace postavené přímo na webových službách a využívající servisně orientovanou architekturu (Service Oriented Architecture – SOA). Aplikace jsou nabízené samotnými výrobci a počty uživatelů mohou jít do tisíců. Zákazník nepořizuje licence, ale předplácí si používání konkrétních služeb v určitém časovém období. Oproti ASP nabízí model SaaS zákazníkům rychlejší implementaci a nižší náklady. Nezanedbatelným faktorem je uživatelsky vstřícné prostředí, které snižuje náklady spojené se zaškolováním pracovníků. Poskytovatelé služeb SaaS využívají technologii cloud computing (viz kapitola 4.2), která jim poskytuje „neomezený“ výkon pro poskytování služeb svým zákazníkům. Model SaaS se pro systémy ECM jako velmi výhodný a na trhu dnes existuje celá řada poskytovatelů. Jedná o „klasické“ výrobce systémů ECM, kteří své produkty upravili pro novou generaci technologií, standardů a architektur a vytvořili tak nový prodejní model. Největší nevýhodou aplikací SaaS je velmi omezená možnost upravovat (customizovat) aplikace SaaS dle požadavku zákazníka a poměrně komplikované je rovněž napojení na již provozované informační systémy (typicky např. na ERP).

5.4. Outsourcing Posledním zde zmíněným modelem, který přichází do úvahy v případě ECM je outsourcing. Outsourcingem se rozumí zajišťování vybraných služeb a činností třetí stranou neboli externí firmou. Podob outsourcingu může být celá řada. V souvislosti s ECM je zde nutno uvést varianty outsourcingu z pohledu informačních technologií a z pohledu procesního. V případě IT pohledu, lze uvažovat o předání všech činností souvisejících s implementací, popř. údržbou nového systému na vybraného dodavatele. To je dnes již klasické schéma, které někdy bývá označováno jako částečný outsourcing. Vyšším stupněm je outsourcing vývoje, kdy je na poskytovatele outsourcingu přesunuta celá správa provozu aplikací a infrastruktury.

45

Infrastruktura může být buď majetkem poskytovatele, nebo zůstává v majetku zákazníka, ale poskytovatel je plně zodpovědný za její provoz. V případě ECM je možno se setkat s tím, že na poskytovatele se přesune celý proces včetně zajištění lidských zdrojů.

Často jde např. o procesy spojené s digitalizací listinných

dokumentů, kdy poskytovatel pro zákazníka zajišťuje skenování a vytěžení dokumentů, jejich předání zákazníkovi v elektronické podobě včetně metadata a následně archivaci listinných dokumentů. Podobně může zajištěn provoz podatelny, resp. její transformace na podatelnu elektronickou, kdy je veškerá příchozí pošta poskytovatelem digitalizována, klasifikována a využitím komponenty pro automatizaci procesů předána zákazníkovi k internímu zpracování.

46

6. Řízení projektů ECM Samotný výběr a nasazení systému ECM pro organizaci představuje velmi náročný organizační a technický úkol, ke kterému musí být přistoupeno jako k projektu. Jedna z definic popisuje projekt jako „dočasné úsilí vynaložené na vytvoření unikátního produktu, služby, nebo určitého výsledku“16. Implementace systému ECM je jednorázová a unikátní aktivita, která má jasně stanovený počátek a konec, má přesně definovaným zadáním (výstupem) a radikálně mění prostředí podniku, pro který znamená kvalitativní změnu. Pro dobu implementace je třeba vytvořit projektový tým, který po předání systému do provozu rozpuštěn. Zde je několik strategických aspektů, které je třeba brát od počátku do úvahy: • vytvoření dlouhodobé vazby na konkrétní produkt • dopad na všechny či většinu podnikových procesů • dodržení existujících legislativní požadavků a oborových standardů (compliance) • silná integrace do stávající infrastruktury IT (nejde-li o SaaS či ASP) – ECM je strategický produkt

Jak bylo popsáno v předchozí kapitole, rozhodnutí o nasazení systému ECM by mělo důsledně vycházet z podnikové strategie a do této strategie zapadat. Mělo by tedy jít o uvědomělé rozhodnutí vrcholového managementu. Ten by pak ale měl probíhajícímu projektu poskytovat pozornost a aktivní podporu po celou dobu realizace.

6.1. Metodiky pro řízení projektů Jakmile tedy padne strategické rozhodnutí o tom, že organizace má zájem o nasazení systému ECM, mělo by se dále postupovat standardním způsobem, tj. cestou projektového řízení. Pro řízení projektů existuje několik základních a mezinárodně uznávaných metodik, které jsou si v základní kostře podobné, ale liší se v důrazech na jednotlivé aspekty řízení projektu, v počtu procesů, v míře orientace na praktický či teoretický přístup apod. 16

Zdroj: PMI. PMBOK Guide. Third Edition. Pennsylvania: PMI, 2004. ISBN 1-930699-45-X, s. 5.

47

6.1.1.

Obecné metodiky pro řízení projektů

Z nejznámějších obecných metodik pro řízení projektů zde můžeme uvést standard PMBOK, což je zkratka pro „Project Management Body of Knowledge“, standard PRINCE2 neboli „PRojects IN Controlled Environments“ či IPMA (International Project Managament Associaton). Původ prvních dvou metodik sahá do 80. let minulého století, kde vznikly jako metodiky řízení IT projektů a obě se poměrně brzy staly respektovaným standardem pro řízení jakéhokoli typu projektu. Struktura PMBOK má spíše charakter jakéhosi „průvodce“, který vedoucího projektu postupně vede jednotlivými fázemi projektu a v každé mu říká, jaké faktory má vzít do úvahy či jaké informace potřebuje znát. PMBOK je komplexní a charakteristický množstvím rozličných doporučení a popisů, což v některých fázích může vést k jisté vágnosti. PRINCE2 je zaměřen více prakticky a je striktněji orientován na procesy, resp. životní cyklus projektu. Oproti PMBOK je více „metodický“. Třetí zmíněná metodika IPMA se od prvních dvou poněkud odlišuje a to tím, že je založen na schopnostech a dovednostech vedoucího projektu. Nejde tedy o přesnou „kuchařku“, která detailně popisuje jednotlivé fáze životního cyklu projektu, ale jedná se spíše o soubor doporučení pro jednotlivé kroky v rámci určitého projektu a je ponecháno na vedoucím projektu, které kroky a v jaký okamžik udělá. Tato metodika se tedy spíše soustřeďuje na rozvoj osobnosti projektového vedoucího, který – disponuje-li potřebnými kompetencemi – sám správně určí, jak konkrétní projekt zrealizovat. IPMA rozlišuje a rozvíjí tři druhy kompetencí: technické (znalost konkrétních technik potřebných pro řízení projektu), kontextové (schopnost vnímat projekt v konkrétním kontextu) a behaviorální („měkké“ dovednosti důležité pro vedení týmu, vyjednávání či řešení konfliktů). Každopádně metodiky se mohou zaměňovat či vzájemně doplňovat a celá řada velkých projektových či projektově řízených firem na jejich základě vybudovala svoje vlastní standardy. Protože jedním z vytčených cílů této práce je také zhodnocení průběhu projektu implementace systému pro elektronické schvalování faktur, tak aby bylo možno provést zhodnocení strukturovaným způsobem, rozhodl jsem se pro tento účel využít metodiku PMBOK. PMBOK jsem zvolil jednak kvůli zaměření na metodické pojetí řízení projektu a pak také na značném rozšíření této metodiky v prostředí nadnárodních firem (a firma, kde se realizoval sledovaný projekt je je nadnárodním koncernem), kde platí de facto za uznávaný světový

48

standard. Proto v následující kapitole nejprve čtenáře podrobněji seznámím s principy zvolené metodiky.

6.2. PMBOK Metodika (či standard) PMBOK byla vyvinut americkým institutem PMI (Project Management Institute) a díky tomu je rozšířena zejména v Severní a Jižní Americe a skrze americké nadnárodní firmy se postupně rozšířil i do zbytku světa. Metodika PMBOK stanovuje tři základní oblasti v každém projektu: • Životní cyklus projektu a organizace • Pět skupin procesů • Devět znalostních oblastí Životní cyklus projektu Životní cyklus projektu popisuje základní fáze, kterými projekt prochází a jaké mají být vstupy a výstupy pro každou fázi (viz obr. 8). Pro každou fázi je pak dále popsáno, jaká činnost se má provést, kdo se má zapojit, jak jednotlivé fáze řídit a co má být kritériem pro akceptaci jednotlivých dodávek, tj. činností, ze kterých se projekt sestává.

Obr. 8: Životní cyklus projektu

Zdroj: PMI. PMBOK Guide. Third Edition. Pennsylvania: PMI, 2004. ISBN 1-930699-45-X, s. 23.

PMBOK také definuje tzv. zájmové skupiny, což jsou lidé (popř. organizace a instituce), které se aktivně zapojují do projektu a mají (či mohou mít) vliv na jeho průběh a výsledek. Jde především o tyto osoby či skupiny: 49

• Projektový manažer. Osoba zodpovědná za vlastní řízení projektu • Členové projektového týmu. Skupina lidí, kteří projekt provádí. • Tým vedení projektu. Členové projektového týmu, kteří se přímo podílejí na řízení projektu • Sponzor. Osoba, která projekt financuje (přímo či zprostředkovaně). • Vlivná osoba. Osoba, která není přímo zapojená do projektu, ale která díky své pozici v organizaci může mít kladný či záporný vliv na průběh projektu. • Zákazník. Uživatel výsledného produktu.

Skupiny a oblasti PMBOK definuje 44 procesů, které jsou rozdělené do pěti skupin (Project management process Group): Zahájení (Initiating) > Plánování (Planning) > Realizace (Executing) > Monitorování a kontrola (Monitoring and controlling) > Uzavření (Closing). Metodika PMBOK skupiny procesů nechápe – jak by se mohlo na první pohled zdát – jako jednotlivé fáze projektu, ale skupiny jsou využívány ve všech fázích životního cyklu projektu. Jde o rozvedení klasického Demingova cyklu Naplánuj – Udělej – Zkontroluj – Zasáhni” (Plan – Do- Check – Act Cycle) do metodiky PMBOK, jak je znázorněno na obrázku 9.

Obr. 9: Životní cyklus projektu

Zdroj: PMI. PMBOK Guide. Third Edition. Pennsylvania: PMI, 2004. ISBN 1-930699-45-X, s. 40.

Vedle skupin PMBOK rozděluji znalosti a zkušenosti do devíti základních oblastí (Project management knowledge areas): vedle základní integrace projektových aktivit jde a řízení

50

rozsahu projektu, nákladů, času, kvality, lidských zdrojů, rizik, komunikace a nákupu. Obrázek 10 ilustruje provázanost skupin s oblastmi znalostí a v takto vzniklé matici pak výše uvedených 44 procesů (4.1 až 12.6).

Obr. 10: Vztah mezi skupinami a oblastmi

Zdroj: PMI. PMBOK Guide. Third Edition. Pennsylvania: PMI, 2004. ISBN 1-930699-45-X, s. 70.

51

Pro každý ze 44 procesů PMBOK definuje vstupy, výstupy a doporučené nástroje a techniky pro jejich realizaci. Vstupy se rozumí např. doporučení, jaké konkrétní faktory mohou na daný proces působit a je třeba je vzít do úvahy. V nástrojích a technikách uživatel nalezne např. z praxe vycházející šablony různých dokumentů, seznamy kontrolních bodů apod. Obdobným způsobem jsou pak definovány výstupy z daného procesu.

Jak bylo řečeno, každý projekt nasazení systému ECM je natolik komplexní, že jeho realizace bez vědomého využití metodiky (standardní či firemní) bude představovat velké riziko pro úspěšné dokončení projektu. Úspěšným dokončením se je myšleno, že projekt byl realizován ve stanovém čase, za stanovenou cenu a za využití stanovených zdrojů. Při hledání dodavatele by se tak zákazník měl velmi zajímat, zda uchazeč o zakázku používá nějakou metodiku či nikoli.

52

7. Nasazení ECM v praxi Další část práce je zaměřena na praktické využití některých komponent ECM; konkrétně o systém umožňující digitalizaci dodavatelských faktur, automatické vytěžení obsahu, schválení, integraci s podnikovým informačním systémem a následnou archivaci. Čtenáře nejprve seznámím se způsobem, jakým došlo k rozhodnutí o nasazení tohoto systému, dále pak jak probíhal projekt nasazení, abych následně mohl tento konkrétní příklad analyzovat, vyhodnotit a nabídnout některá doporučení pro další rozvoj. Praktická část vychází z konkrétního projektu realizovaného u jedné nadnárodní mediální firmy, kterou budeme v rámci této práce kvůli anonymizaci označovat vymyšleným názvem Media House. Firma Media House dnes působí na evropském a asijském trhu a zaměstnává téměř 8000 lidí a vedle vydávání klasickým produktů jakými jsou noviny a časopisy, také provozuje televizní stanice, webové servery a množství vlastních tiskáren. Firma Media House vstoupila na středo- a východoevropský trh v 90. letech 20. století a vybudovala dceřiné firmy v České a Slovenské republice, Maďarsku, Srbsku a Rumunsku. V Asii podniká na mediálním trhu Číny a Vietnamu. V polovině roku 2010 došlo k zásadní organizační změně: vedení firmy rozhodlo o vložení svých středoevropských firem do společného podniku vybudovaného spolu s jiným evropským mediálním gigantem. Z obecných trendů, které silně působí na způsob podnikání, je třeba zmínit dramatický zlom ve způsobu distribuce obsahu, kdy trend zcela jednoznačně směřuje k využívání digitálních médií. Cílem firmy je dosáhnout do roku 2014 dvacetiprocentního podílu prodeje právě z digitálních médií označovaných také jako nová média.

7.1. Rámec projektu Přestože mateřská firma vlastnila pobočky ve střední Evropě po téměř dvě desetiletí, nikdy se nepodařilo prosadit hlubší standardizaci a konsolidaci procesů či systémů a infrastruktury. To je pochopitelné pokud jde o oblast byznysu (rozuměna tvorba, výroba a distribuce obsahu a prodej inzerce), protože v oblasti médiích obecně panují velké obchodní či kulturní odlišnosti

53

a v podstatě jde o lokální produkty (oproti firmám prodávajícím „globální komodity“ typu spotřebního zboží). Méně pochopitelné to ale je v oblasti podpůrných oddělení (backoffice), která nejsou nijak vázána na konkrétní místo a jejichž procesy jsou poměrně standardní. Jediným standardem, který se podařilo realizovat, byla implementace finančního a controllingového modulu podnikového informačního systému SAP a to ve všech zemích regionu. Poté se ještě přidalo řešení SAP pro Business Intelligence. Důvod byl jasný: poskytnou konsolidovaný reporting pro vedení společnosti. Všechny ostatní informační systémy - které generují zisk a mají kritický charakter pro běh firmy jako je inzertní a distribuční systém a systém pro tiskárny – jsou proprietární a liší se organizace od organizace. Vedení společnosti se průběžně snažilo jistý stupeň standardu prosadit, ale nikdy se ho nepodařilo realizovat. Důvodem je jednak vnitřní kultura firmy (mediální či třeba reklamní firmy jsou z principu „uvolněnější“), dále fakt, že jde o firmu rodinnou a ne např. o firmu kótovanou na burze, která podléhá tlaku ze strany akcionářů a předpisům a standardům pro akciové společnosti. Řízení je spíše „demokratické“ a jednotlivé organizace mají velkou soběstačnost a nezávislost a vedení neumí. To vše bylo důvodem, proč se např. nikdy nedovedl k finální podobě projekt vybudování globálních adresářových služeb na technologii od firmy Microsoft (Active Directory), který měl být základem pro jednotnou podnikovou síť a následné využívání centralizovaných služeb (např. intranetový portál). Výsledkem bylo, že se sice v centrále podniku globální adresářová služba zprovoznila a propojila s jednotlivými sítěmi v mateřské zemi, ale replikace dat nikdy pořádně nefungovala. Konkrétních důvodů byla celá řada; od heterogenního prostředí (různé síťové operační systémy v jednotlivých zemích) až po neschopnost prosadit standard pro pole, která se budou v Active Directory udržovat. Projekt se táhl několik let, stál značné množství peněz a výsledek byl naprosto nepřesvědčivý. Důležitou otázkou je, proč se např. k tomuto projektu vůbec přistupovalo. Bylo to z důvodu předpokladu, že firma bude postupně sjednocovat svoje systémy. Tento „předpoklad“ ale nevycházel z nějaké hlubší analýzy, nýbrž byla to „samozřejmá“ představa vedoucích pracovníků oddělení informačních technologií v mateřské firmě a nebyl za tím jiný důvod, než že takto „se to dělá u velkých firem“. Takže se předpokládalo, že jestliže se budou sjednocovat aplikace, musí být zabezpečen standardizovaný přístup k síťovým zdrojům. To samozřejmě je logická úvaha, ale v okamžiku zahájení projektu nebylo přesně známo, k přesně jakým aplikacím provozovaným centrálně v mateřské společnosti se bude přistupovat. Existovaly pouze „předpoklady“ a „výhledy“; 54

většinou ve formě nejrůznějších prezentací. Tímto se dostáváme k jádru problému a tím je naprosto chybějící strategie. Jak bylo popsáno výše, v ideálním případě by firma měla vypracovat strategii, která bude ve středně a dlouhodobém výhledu definovat, kam chce firma směřovat a jak chce vytyčené cíle dosáhnout. Zmiňovali jsme pomyslnou pyramidu, jejíž vrcholek představuje formulované základní poslání firmy, které je pak postupně více a více upřesňováno a rozpracováváno přes vizi, podnikovou strategie až ke strategiím dílčím. Firma Media House nikdy takto vypracovanou strategii neměla. Úsilí skončilo formulováním poslání a vize, což byl víceméně formální akt, a dále se již nepokračovalo. Jedná se zde tedy o typický případ, kdy absence jasně určeného strategického směřování spoluzapříčinila nejasné rozhodování a chování a v konečném důsledku stála firmu velké množství zbytečně vynaložených peněz. Ještě zde – vzhledem k tématu této práce - zmíníme projekt nasazení ECM systému SharePoint od firmy Microsoft. Systém se pořizoval s tím, že bude využit jako technologie pro intranetový portál a pro podporu spolupráce a měl být první z koncernových aplikací. Byl tedy zakoupen včetně licencí pro všechny zaměstnance, pořídilo se potřebné hardwarové zařízení a byly zprovozněny vybrané komponenty (podpora spolupráce a portálové řešení). Záhy se ukázalo, že nedotaženost projektu Active Directory se projevila tím, že portál nebyl spolehlivě přístupný, takže uživatelé se po několika neúspěšných pokusech o přihlášení dalších pokusů vzdali a portál celkem pochopitelně ignorovali. Další věcí byl obsah. Vzhledem k tomu, že za rozhodnutím o provozování portálu byla jen snaha, aby „byl“, tak se nijak nepromýšlel jeho obsah. Pouze se zodpovědnost za obsah přidělila oddělení pro řízení vztahů s veřejností (což byla ve většině zemí jedna osoba), takže předpokládaným výsledkem byl natolik chudý obsah, že nikomu nestál za pozornost. Takže technická nespolehlivost přístupu a nezajímavý obsah způsobily, že návštěvnost portálu bylo minimální. Pokud jde o komponentu pro podporu týmové spolupráce (sdílení dokumentů, poznámek či úkolů v rámci jednotlivých projektů), tak tato se používala pouze v mateřské společnosti a nebyla dále vůbec nabízena ani propagována. Důvodem byla zkušenost s portálem a na druhé straně nezájem o podobná řešení ze strany jednotlivých zemí. Příčiny neúspěchu projektu byly stejné: šlo v podstatě o projekt navržený, prosazený a řízený IT oddělením, kdy cíl projektu byl formulován velmi vágně. Na počátku byl projekt

55

SharePoint deklarován jako koncernový, ale nakonec se využíval pouze v mateřské společnosti. V organizaci nebyla žádná síla, která by na tomto faktu chtěla něco změnit. Jaké bylo další pokračování? Systém SharePoint se tedy zamrazil, dále nerozvíjel a po přibližně dvou letech provozu padlo rozhodnutí, zbavit se správy technické infrastruktury a přejít na technologii „cloud computing“ kvůli předpokládané úspoře nákladů. Ve výběrovém řízení vyhrála firma Google a koncern pořídil její řešení Google Apps pro korporátní sféru obsahující tyto služby: e-mail, instant messaging, kalendář, webové stránky a sdílení dokumentů. V okamžiku, kdy vznikají tyto řádky, je nový systém nasazen již půl roku ve všech organizacích, nepodařilo se dosáhnout předpokládaných úspor a ani se jim přiblížit a v anketě spokojenosti s novým produktem, kterou dělala mateřská firma, vyšlo, že pouze 30% uživatelů je s produktem spokojeno. Kromě standardních funkcí (e-mail, kalendář) sytém nenabízí další přidanou hodnotu. Např. sdílet dokumenty mezi více uživateli sice lze, ale efektivní skupinová práce nad jedním dokumentem je možná pouze pokud jsou dokumenty vytvářené v kancelářských aplikacích od firmy Google. V opačném případě je možno soubory pouze ukládat. Systém také nenabízí žádnou podporu pro řízení pracovních toků, resp. nabízí jen řešení třetích stran, která jsou (zatím) pro větší společnosti zcela nevyhovující. Hlavním faktorem pro změnu strategicky významného sytému byla snaha o snížení nákladů. Nejen že se nepodařilo tento předpoklad naplnit, ale zároveň se ve firmě objevila technologie od dalšího výrobce, čímž se prohlubuje diverzita používaných systémů. Tolik pro ilustraci prostředí, do kterého vstupoval projekt pro elektronické schvalování faktur.

7.2. Historie projektu Zpracování dodavatelských faktur patří v každé firmě k nejdůležitějším procesům. Důvodem je, že proces je spojen s finančními výdaji firmy a tím tedy s řízením toku hotovosti a finanční situací podniku. Dodavatelské faktury jsou také výsledkem objednávkového procesu a většinou navazují na dodání objednaného produktu či služby. Objednávka (popř. i poptávka) spolu s dodávkou a fakturou za ni dohromady zahrnují celý proces nákupu (anglicky procurement). Pakliže se firma rozhodne, že nějaký proces převede z papírové do elektronické podoby, většinou začíná právě u schvalování došlých faktur. Stejně tomu bylo u společnosti Media House. Původní impuls vzešel z české organizace, neboť zde pracovalo množství lidí, kteří elektronické schvalování faktur znali z předchozích zaměstnání a uvědomovali si, jaký se zde

56

skrývá potenciál pro zefektivnění interních procesů. Mateřská společnost neměla o podobný systém zájem, neboť (jak bude popsáno dále) jejich proces schvalování byl zcela odlišný od způsobu, který byl používán v ostatních zemích a skutečně na první pohled se zdál jako dobře fungující. Co ale mateřská společnost používala, bylo řešení pro skenování dodavatelských faktur, jejich archivace na zabezpečeném uložišti a propojení naskenované faktury s odpovídajícím účtovacím dokladem ve finančním modulu SAP. Výsledkem je, že uživatel, který v SAP pracuje se zaúčtovanými dodavatelskými fakturami, si může kdykoli přímo z prostředí SAP zobrazit vzorový doklad a nemusí ho hledat v papírovém archivu. Ukázka řešení je na obrázku 11.

Obr. 11: Ukázka propojení naskenované faktury se zaúčtovaným dokladem

Zdroj: vlastní (kopie obrazovky z finančního modulu ERP systému SAP a prohlížeče Livelink Viewer).

Media House pro tento účel pořídil řešení od firmy OpenText a sice moduly Archive Server (centrální uložiště) a modul Archiving for SAP Solutions umožňující zmíněné propojení naskenovaného dokladu s účetním dokladem v SAP.

57

Vedle toho bylo plánováno pořídit další moduly pro zálohování zpráv elektronické pošty a také transakčních dat systému SAP. Nepodařilo se mi při sběru podkladů vzhledem ke značnému časovému odstupu zjistit (toto se odehrálo kolem roku 2006), proč projekt nepokročil a zůstalo z něho pouze řešení pro archivaci došlých faktur, ale leccos napovídá výše uvedené. Každopádně, když se česká organizace dozvěděla o tomto řešení, projevila zájem o jeho nasazení. Vzhledem k tomu, že se jednalo o převzetí již existujícího řešení, kdy nebylo potřeba řešit vybudování infrastruktury a samotnou implementaci, ale pouze vybudování skenovacích pracovišť a přizpůsobení systému SAP a archivu pro novou firmu, nasazení proběhlo ve velmi krátkém čase. Jak bylo uvedeno výše, po nasazení se česká organizace poohlížet po možnosti rozšířit stávající řešení o elektronické schvalování došlých faktur. Samotná digitalizace zvyšovala uživatelský komfort, ale nenabízela významnější zefektivnění celého procesu, jehož největším problémem byla chybějící kontrola (typická otázka: u koho se teď doklad nachází) a následkem toho faktury proplacené po termínu splatnosti. Proces také představoval velkou administrativní zátěž díky tomu, že papírová faktura musela fyzicky obíhat po firmě a např. v případě tiskáren i mezi odlehlými lokalitami (v České republice má Media House tiskárnu v Praze a Ostravě). Z dalších nevýhod je třeba jmenovat nutnost ručně přepisovat údaje z faktury do informačního systému SAP, což je doprovázeno množstvím chyb. Protože firma OpenText patří k předním světovým výrobcům ECM, první úvaha směřovala pro využití specializovaného řešení pro schvalování faktur, která tato společnost nabízí (modul Account Payable for SAP). Předběžná poptávka ukázala, že cena se rámcově pohybuje kolem částky 1,5 milionu Kč. Bylo jasné, že výdaj v této výši lze zdůvodnit pouze u řešení, které by bylo možno nasadit v rámci celého koncernu. Bohužel ale v té době mateřská firma ani jiná organizace v regionu o elektronické schvalování faktur neprojevila žádný zájem a pouze pro Českou republiku byl výdaj jen velmi těžko obhajitelný. Snaha prosadit toto řešení alespoň pro Českou republiku a doufat, že konkrétní příklad nakonec přesvědčí i ostatní, skončila, když vedení společnosti nařídilo radikální snížení nákladů (to bylo ještě před finanční krizí). Nikdo již neměl vůli snažit se prosazovat takto nevyjasněný projekt. Hlavním iniciátorem v České republice byl finanční ředitel, ale jeho pozice byla oslabená, protože projekt v mateřské společnosti prosazoval sám, bez podpory generálního ředitele českého vydavatelství, který byl zaměřen výhradně na obchod a procesní věci (navíc v podpůrném finančním oddělení) pro něj nebyly středem zájmu.

58

Po nějaké době téma ožilo a česká organizace se snažila zjistit, zda by se požadované funkce nedalo dosáhnout nějakým levnějším lokálním řešením. V neprospěch takové varianty mluvil od začátku fakt, že by bylo potřeba ke stávajícím dvěma „těžkým technologiím“ (SAP a OpenText) přidat třetí, navíc lokální. Brzy se od této snahy opustilo o to i z důvodu, že mateřská firma oznámila záměr nasadit do celého koncernu produkt SharePoint (viz předchozí). Takže se čekalo, než se systém spustí a následně došlo k uvedeným problémům. Mezitím ale došlo k zásadnímu obratu na straně mateřské firmy, kdy nový vedoucí účtárny projevil zájem o řešení pro elektronické schvalování faktur a tento záměr získal podporu ze strany finančního ředitele koncernu. Celý projekt se tak spustil znovu, tentokrát přímo v mateřské firmě, kde se měl realizovat pilotní projekt a po jeho skončení se systém měl postupně nasadit v ostatních zemích.

8. Průběh realizace Pro představu o rozsahu samotného procesu zpracování dodavatelský faktur ve firmě Media House nejprve v následující tabulce uvedu několik základních údajů:

Stát mateřská firma Česká republika Maďarsko Rumunsko Slovensko Srbsko Celkem

Počet faktur [ročně] Počet FTEs * 80 000 8 12 000 4 15 000 4 20 000 4 6 000 1 15 000 4 148 000 25

Počet účtáren 6 3 3 1 1 14

* Ekvivalent zaměstnance na plný úvazek, angl. Full-Time Equivalent – FTE. V tomto případě počet jednotek spojených s procesem zpracování faktur ve finančních odděleních.

Objem peněz, který skrze tento proces každoročně projde, činí přibližně 20 miliard Kč (za všechny země).

59

8.1. Úvodní fáze projektu Jakmile byl získán předběžný souhlas ze strany koncernového finančního ředitele, prvním krokem, který následoval, byla příprava dokumentu, který se jmenoval „Specifikace požadavků pro elektronické schvalování faktur“. Dokument nejprve popsal stávající stav a následně se věnoval tomu, co by obnášel nový projekt: základní cíle a rozsah projektu, hlavní funkcionality budoucího systému, předpokládané přínosy, rámcový odhad ceny a předpokládaných úspor, dopady na stávající procesy a IT infrastrukturu. Na přípravě tohoto zakládajícího dokumentu jsem se podílel a mohl při tom využít zkušeností, které jsem získal při prověřování možnosti nasadit systém v České republice. Dokument v závěru doporučuje jako další postup přípravu tzv. detailního konceptu, který by již velmi přesně specifikoval požadavky na systém. Tento dokument pak měl být základem pro výběrové řízení. Vzhledem k neexistenci potřebných znalostí a zkušeností uvnitř firmy, bylo doporučeno, aby detailní koncept byl vypracován za spolupráce s externí firmou Finanční ředitel koncernu takto navržený postup (a předpokládané náklady s tím spojené) odsouhlasil a v průběhu přibližně dvou měsíců byl detailní koncept vypracován. Dle zadání vznikl přibližně stostránkový dokument podrobně popisující jednotlivé požadavky. Na jeho přípravu byla najata jedna z firem, která se na základě předběžné poptávky ucházela o účast ve výběrovém řízení. Firma nebyla vybrána dle nějakých požadovaných parametrů. Členy výběrové komise byl vedoucí finančního oddělení, zástupce vedoucího oddělení IT a šéf koncernového kompetenčního centra SAP a některých částí výběrového řízení jsem se také účastnil jako zástupce východoevropského regionu. Specifikace požadavků vznikala dle zadání švýcarské mateřské firmy a v podstatě se jednalo o rozvedení zadávajícího dokumentu do větších podrobností. Koncept obsahoval kapitoly: analýza stávajícího stavu, předpokládané přínosy, rozsah projektu, podoba schvalovacího procesu, kalkulace návratnosti investice, požadavky na dodavatele řešení a samozřejmě shrnutí pro management. Situace a požadavky v ostatních zemích nebyly v dokumentu popsány; vycházelo se ze zkušenosti, že proces schvalování je v rámci firmy velmi podobný a také se předpokládala standardizace celého procesu. Příprava směřovala k přípravě a realizaci pilotního projektu, následného vyhodnocení a přípravy nasazení systému ve zbývajících zemích formou koncernové šablony (tzv. rollout). Takto vzniklý dokument byl pak rozeslán na uchazeče o účast ve výběrovém řízení a díky míře jeho podrobnosti se očekávalo, že budou maximálně eliminovány nejasnosti a tím pádem

60

budou jednotlivé nabídky velmi dobře srovnatelné. Výběr oslovených firem neprobíhal příliš systematickým způsobem – každý z členů výběrové komise mohl doporučit firmy, které nějakým způsobem znal. Jednomyslná shoda panovala na tom, že se musí jednat o existující a již vyzkoušené řešení (tzv. Out-of-the-Box). Varianta vlastního vývoje nebyla uvažována. O čem se ale jednalo, bylo řešení zadání přímo v prostředí systému SAP, ze kterého je ve firmě Media House nasazen finanční, controllingový a částečně také skladový modul (pouze v mateřské společnosti) a pak také varianta řešit zadání v prostředí výše zmíněné platformy Microsoft SharePoint, tzn. včlenění procesu do prostředí předpokládaného celopodnikového ECM systému. Obě varianty – přestože se z teoretického pohledu jevily jako koncepční - byly poměrně záhy zamítnuty. Varianta SAP z toho důvodu, že počet uživatelů budoucího řešení pro schvalování faktur se blížil tisícovce a každý z nich by tak potřeboval „těžkého“ klienta SAP na svém počítači a musel by zde pracovat v uživatelsky nepříliš vstřícném prostředí. Standardně SAP v základních modulech disponuje funkcionalitou pro nastavování schvalovacího procesu, ale tato je poměrně rigidní a předpokládá pokročilou standardizaci firmy a to nebyl a není případ firmy Media House. Firma SAP samozřejmě nabízí velmi pokročilá řešení pro běh aplikací ve webovém prostředí (platforma NetWeaver) i sofistikovaná řešení pro navrhování a řízení procesů (modul SAP BPM), ale Media House provozuje pouze „klasické“ moduly ERP a vybudování nové infrastruktury by bylo ve všech ohledech natolik náročné, že se od této varianty upustilo. Pokud jde o realizaci v prostředí Microsoft SharePoint, tak zde bohužel v okamžiku poptávky neexistovala žádná odzkoušená řešení pro schvalování faktur. Jak bylo uvedeno, požadavkem bylo řešení, které by již někde bylo v provozu a systém mohl v ideálním případě vycházet z „best practices“. Microsoft SharePoint se v tomto pohledu jevil pouze jako vývojová platforma, kde by bylo potřeba vyvinout aplikaci zcela od začátku, a pro tuto cestu firma nedisponovala potřebnými lidskými zdroji a také neexistence procesních standardů byla vyhodnocena jako zásadní kritický faktor. To byly příčiny pro zamítnutí této varianty. S poptávkovým dokumentem bylo osloveno šest firem. Po vyhodnocení nabídek byl výběr následně zúžen na firmy tři. Všechny nabízely technicky velmi podobná řešení za přibližně stejné ceny. Výběrová komise prověřila reference a každou z firem si následně pozvala k další prezentaci řešení, kde se nabídka projednávala ve větším detailu. Konečný výběr pak proběhl celkem rychle. Vzhledem k vyrovnanosti cen, se rozhodujícím kritériem stala vyzrálost a rozšířenost řešení mezi zákazníky. Výběrové řízení tak vyhrálo 61

řešení od finské firmy Basware (www.basware.com), kterou zastupoval její partner, firma RR Donnelley. Firma Basware se dlouhodobě soustřeďuje na komplexní řešení pro řešení podpory celého nákupního procesu nákupu od objednávky až po zaplacení. Jde o modulární systém, který je připraven pro integraci velkým množstvím systémů ERP na světovém trhu. Pro účel firmy Media House – poptávající pouze řešení pro schvalování faktur – se zvolil specializovaný modul Basware Invoice Processing (dále jen Basware IP) v kombinaci s technologií od firmy Kofax pro automatické vytěžování obsahu faktur Kofax Transformation Modules (dále jen KTM).

8.2. Popis technického řešení Navržené řešení vychází z integrace modulu Basware IP s podnikovým informačním systémem SAP (přesněji řečeno jeho finančním modulem), s uložištěm dokumentů Livelink Archive a řešením KTM. Celý proces byl navržen do následujících kroků: • Naskenování faktury a vytěžení vybraných dat z hlavičky dokladu v KTM • Validace vytěžených dat a jejich odeslání z KTM do Basware IP • Předběžné pořízení dokladu v Basware IP a odeslání dokladu ke schválení prostřednictvím tlustého klienta aplikace (IP Master) • Schválení faktury prostřednictvím webového klienta (IP ThinClinet) • Finální kontrola schválené faktury a její odeslání do systému SAP k automatickému zaúčtování • Platba faktury proběhne v systému SAP a informace o jejím provedení se přenáší zpět do Basware IP

8.3. Změna procesu Obecně se rozlišují dva možné scénáře pro archivování faktur: Early Archiving a Late Archiving. V případě prvního scénáře jsou dokumenty nejprve digitalizovány a dále jsou již zpracovány pouze v elektronické podobě. To je běžné v případě centrálního příjmu došlé pošty do firmy. Scénář Late Archiving naopak předpokládá, že doklad je kompletně zpracován v papírové podobě a až na konci procesu dochází k jeho digitalizaci a archivaci.

62

Bylo zmíněno, že mateřská společnost již dlouhou dobu skenovala a ukládala došlé dokumenty. Proces byl nastaven dle scénáře pro pozdní archivaci. Došlé faktury byly adresovány přímo k rukám pracovníků, kteří si produkt či službu objednali. Ti byli vyškoleni tak, že na fakturu nalepili speciální nálepku s čárovým kódem a políčkem pro účtovací předpis, na ni se podepsali, připojili číslo svého střediska, účtu či zakázky a takto připravený doklad poslaly vnitřní poštou buď k dalšímu schválení. Jakmile byl doklad tímto způsobem schválen, byl posledním schvalujícím odeslán do účtárny, která fakturu naskenovala, zaúčtovala a zaplatila. Největší nevýhodou této varianty bylo to, že došlé faktury nebyly nijak centrálně registrovány a finanční oddělení se k nim dostalo až na konci po jejich schválení a nad jejich oběhem nemělo naprosto žádnou kontrolu. To byl jednak problém s ohledem na řízení finančních toků (cash flow), protože neexistovala informace, v kdy se v budoucnu má zaplatit jaká částka, dále to značně komplikovalo možnost uplatnění slevy za včasnou platbu a nezanedbatelné byly i problémy s dohledáváním dokumentů, protože občas docházelo ke ztrátě dokladu. Logicky padlo rozhodnutí změnit tento scénář, zřídit centrální adresu pro zasílání faktur a došlé faktury nejprve naskenovat a až poté poslat k odsouhlasení – viz předchozí kapitola. Pokud jde o ostatní země, tak v nich byl tento – pro mateřskou organizaci nový - schvalovací proces zaveden. Došlé faktury byly nejprve finančním oddělením předběžně pořízeny v systému SAP, opatřeny průvodním listem (tzv. košilkou) a odeslány vnitřní poštou ke schválení. Po schválení se faktura s příslušnými podpisy vrátila zpět do finančního oddělení a byla zaúčtována a zaplacena. Sice existovala registrace došlých faktur, ale opět zcela chyběla jakákoli kontrola nad schvalovacím procesem a zvláště měl-li doklad projít několik oddělení, často se stávalo, že se vrátil až po uvedeném termínu splatnosti, nebo se občas ztratil docela. Mateřská společnost tedy musela podstatným způsobem změnit stávající proces. Také padlo rozhodnutí provést změny v organizační struktuře. Vedle samotného vydavatelství patří firmě rovněž necelá desítka tiskáren a některé z nich měly vlastní účtárnu, kde se zpracovávaly došlé faktury. Změna se týkala vybudování střediska sdílených finančních služeb (Shared Service Center Finance). Cílem bylo centralizovat příjem všech dodavatelských faktur do jednoho místa. Zde se faktury měly naskenovat, vytěžit a v elektronické podobě odeslat ke schválení do jednotlivých poboček a originál faktury v papírové formě uložit do archivu. Tam, kde dříve existovaly samostatné účtárny, se tyto nijak nerušily a samotné zaúčtování a zaplacení se i nadále provádělo decentralizovaně.

63

8.4. Průběh projektu Poté co bylo ve výběrovém řízení zvoleno řešení od firmy Basware a jeho dodavatel, výsledek byl prezentován vedení firmy, které následně projekt oficiálně odsouhlasilo. Prvním krokem projektu bylo vypracování tzv. Detailního konceptu pro nasazení sytému Basware IP. Dokument podrobně popisoval nastavení jednotlivých funkcí systému („co bude systém dělat“) a měl také představovat základ pro další dokumenty: popis technického řešení a řešení rozhraní a také pro tzv. testovací katalog, který měl definovat kritéria pro akceptaci řešení. Za projekt byl oficiálně na straně firmy Media House odpovědný vedoucí účtárny (funkce vedoucí projektu na straně zákazníka), který ale vlastní realizaci plně delegoval na svého podřízeného. Na straně dodavatele řešení byl funkcí vedoucího projektu pověřen konzultant, který řešení zároveň realizoval. Vedle toho byl definován řídící výbor pro řešení případných problémů, které by nebylo možno vyřešit na úrovni vedoucích projektu. Detailní koncept byl připraven během dvou měsíců a následně akceptován oběma stranami. Vlastní realizace pilotního projektu v mateřské firmě začala v říjnu 2009 a dle plánu měl systém naběhnout do provozu v únoru 2010. Skutečnost byla ale takové, že realizace projektu byla zpožděna o více jak jeden rok. Termín spuštění byl několikrát oznámen a poté vždy odložen. Postupně se systém nasazoval v menších účtárnách jednotlivých tiskáren, ale největší podnik, kterým je samotné vydavatelství Media House a kde je zpracováváno téměř 80% všech faktur, přešel na nový systém až po více jak roce po původně předpokládaném termínu.

9. Zhodnocení pilotního projektu Původně plánovaný termín spuštění nového systému se tedy nepodařilo dodržet a zpoždění bylo velmi dramatické – pilotní projekt trval více jak trojnásobek plánované doby. Jestliže čas tvoří vedle nákladů a dostupnosti zdrojů základnu pro řízení projektu, tak přinejmenším z tohoto hlediska nelze projekt považovat za úspěšný. V této kapitole se na základě uvedených faktu pokusím o zhodnocení průběhu projektu. Jedna z předchozích kapitol se krátce věnovala mezinárodním standardům pro řízení projektů. Abych mohl projekt posoudit strukturovaným způsobem, zvolil jsme za základ metodiku PMBOK (Project Management Body of Knowledge) – viz kapitola 7.1.1. Na obrázku č. 12 je v přehledné podobě zobrazena obecná osnova (integrace) projektu, kterou použijeme pro základní orientaci v projektu.

64

Obr. 12: Vývojový diagram integrace projektu

Zdroj: PMI. PMBOK Guide. Third Edition. Pennsylvania: PMI, 2004. ISBN 1-930699-45-X, s. 82.

9.1. Iniciace a zahájení projektu Metodika PMBOK doporučuje ve fázi zahájení sestavit dva základní dokumenty: Zakládající listinu projektu (Project Charter) určenou pro sponzory projektu a poté Předběžnou definici předmětu projektu (Preliminary Project Scope). Připomenu, že v přípravné fázi byly vytvořeny dva dokumenty, jež sice byly pojmenovány odlišně, ale jejichž smysl se blížil dokumentům dle standardní metodiky: nejprve vznikla specifikace požadavků, což byl dokumentu určený pro vedení firmy, který obecně popisoval, 65

co je základním smyslem navrhovaného řešení: jaké problémy se projektem řeší a jaký je konkrétní cíl. Šlo o „prohlášení, že existuje potřeba dosáhnout určitých cílů společnosti prostřednictvím realizace projektu“17. Po schválení této specifikace vedením společnosti (deklarace souhlasu s navrhovaným projektem a schválení dalších kroků v projektu) vznikl tzv. detailní koncept, který zpřesnil, jak má budoucí systém vypadat. Vzhledem k nedostatku interní zkušenosti v oblasti správy elektronických dokumentů, byla snaha minimalizovat riziko spojené s chybným výběrem budoucího řešení, a proto byla na přípravu detailního konceptu pozvána externí firma. Tento postup považuji za účelný a pragmatický. Na konci úvodní fáze tedy bylo jasné, co je smyslem projektu, co je vyžadováno od budoucího řešení, jaké jsou předpokládané náklady projektu a rovněž očekávané přínosy. Jak bylo uvedeno, firma Media House nemá vypracovanou podnikovou strategii a tak nebylo možno budoucí řešení včlenit do širšího rámce. Pouze „intuitivně“ (tj. nebylo formalizováno) se předpokládalo, že vzhledem k aktuální situaci v oblasti infrastruktury IT je nutno vybrat specializované řešení třetí strany, které rozšiřuje počet existujících platforem uvnitř firmy (SAP a Microsoft SharePoint) - viz kapitola 8.1. Spíše než o rozhodnutí o strategických potřebách firmy se tak jednalo o rozhodnutí poskytnout technologickou podporu pro vybraný interní proces na základě obecné zkušenosti. Spouštěcím mechanismem projektu byla primárně konkrétní potřeba finančního oddělení. Za nedostatek zde považuji nedostatečné rozpracování otázek spojených s riziky a omezeními. Tyto byly popsány pouze v obecné rovině, ale nebyly nijak dále rozvedeny. Žádný z dokumentů také blížeji nerozpracovával otázku potřeby interních zdrojů. Ani aspekty nasazení systému v dalších zemích nebyly rozpracovány. Jako hlavním důvod pro takto detailní analýzu byl uváděn nedostatek interních lidských zdrojů. Jak již bylo uvedeno, firma Media House není procesně či projektově orientována a k řešením podobných úkolu se přistupovalo vždy „pragmaticky“. To považuji za legitimní přístup, ale – jak se později ukázalo – podcenění náročnosti projektu na spotřebu lidských zdrojů, bylo zřejmě největším nedostatkem úvodní fáze.

17

Zdroj: SVOZILOVÁ, Alena. Projektový management. 1.vyd. Praha: Grada Publishing, 2006. ISBN 80-247-

1501-5, s. 73.

66

9.2. Plánování projektu Konkrétní postup byl popsán výše: proběhlo výběrové řízení, vítězem se stala firma RR Donnelley s produktem Basware, byl připraven tzv. Detailní koncept pro nasazení sytému Basware IP. Šlo o technicky zaměřený dokument, který by se dal definovat také jako cílový koncept. Cílem plánovací fáze projektu je „definice hlavních faktorů a sestavení plánových dokumentů projektu“18. Základním dokumentem (výstupem) je dle PMBOK plán projektu, který se ale sestává z několika (pod)plánů specifických pro jednotlivé aspekty projektu jako je plán řízení projektu (harmonogram včetně milníků), plán řízení předmětu projektu (rozpis činností), plán pro řízení nákladů, plán řízení rizik, plán obsazení projektu atd. (viz kapitoly 5 až 12 na obrázku 12). Ve fázi plánování konstatuji několik základních nedostatků. Jediný oficiální projektový dokument vniklý v této fázi byl pouze zmíněný technicky orientovaný detailní koncept, který sice obsahoval zmínky i o dalších aspektech projektu, ale žádný z nich nebyl více rozpracován. Projekt tak začínal pouze s popisem cílové funkcionality, ale plán projektu nebyl vůbec řešen. Neexistoval plán rizik, plán kvality ani žádný jiný plán. Smlouva s dodavatelem řešení sice obsahovala základní časový rámec projektu, ale nebyly Další část budu věnovat konkrétnímu zhodnocení celého projektu a doporučením pro firmu Media House na další nasazení a rozvoj aplikace.

9.3. Průběh projektu a jeho řízení Průběh projektu nemohu označit za uspokojující. Největším problémem bylo obrovské zpoždění, do kterého se projekt dostal. To mělo několik zásadních příčin. První z nich vidím v tom, že se sice v počáteční fázi investovalo hodně času do definice toho, co by měl systém poskytovat, ale byl zcela ignorován aspekt realizace projektu v podmínkách konkrétní organizace – vycházelo se víceméně pouze z odhadů. Jako další příčinu vidím nedostatečně a nesprávně sestavený projektový tým. Celý projekt se víceméně odehrával jen mezi dvěma osobami: konzultantem ze strany dodavatele a na straně firmy Media House zaměstnancem účtárny, který byl pro tuto činnost delegován svým nadřízeným a který na projektu pracoval vedle své běžné denní agendy. Ani na jedné straně

18

Zdroj: SVOZILOVÁ, Alena. Projektový management. 1.vyd. Praha: Grada Publishing, 2006. ISBN 80-2471501-5, s. 109.

67

nebyl určen skutečný vedoucí projektu. Papírově sice existoval řídící výbor, ten se ale nikdy nesešel. Je zarážející, že vedení firmy o probíhající projekt projevovalo tak malý zájem. Během realizace jsem měl dojem, že se strany vedení byl projekt chápán jako něco, co bylo vnitřní záležitostí účtárny. Nikdy nebyla aktivně řešena skutečnost, že termín zahájení byl opakovaně vyhlášen a opakovaně posunut. O řízení projektu se tak nedá příliš mluvit, projekt žil tak trochu vlastním životem. Jestliže na straně firmy Media House bylo chybou svěřit projekt někomu, kdo ho měl na starosti vedle svých dalších činností (ze kterých mu nebylo výrazně sleveno), tak paradoxně na straně dodavatele panoval obdobný stav. Konzultant, který byl zodpovědný za nastavení systému (a který měl v jedné osobě vykonávat i roli vedoucího projektu), pracoval souběžně i na dalších projektech a dle vyjádření jednoho účastníka projektu, byl sice odborně na výši, ale k řešení problémů přistupoval neorganizovaně až chaoticky. Vznikla tak velmi zajímavá situace: oběma stranám - zákazníkovi i dodavateli – neuspokojivý stav v podstatě vyhovoval a tím, že pro vedení (a to opět obou stran) projekt neměl téměř žádnou důležitost, se nepřistoupilo k žádným nápravným opatřením. Projekt se tak k cíly dostával víceméně samospádným pohybem. Z obou stran chyběl aktivní tlak na dokončení projektu, což je vhledem k celkovým nákladům (téměř 6 miliónů Kč) nepochopitelné. Zjišťoval jsem také to, jak bylo realizováno změnové řízení, neboli jak se postupovalo v situaci, kdy se v průběhu projektu ukázalo, že bude od systému požadována jiná funkcionalita, než jak bylo popsáno v cílovém konceptu. I zde se projevil zvláštní průběh projektu. K těmto situacím samozřejmě došlo, ale protože konzultant ze strany dodavatele měl neustále problémy s dodržením slíbených termínů, tak tyto vícepráce neúčtoval. Člověk zodpovědný za projekt na straně firmy Media House si také stěžoval ne kvalitu prováděných změn: aplikace vykazovala množství chyb (s ohledem na to, že šlo o typizované řešení) a bylo potřeba velkého úsilí pro testování. Běžně se prý stávalo, že nová úprava znehodnotila nějaké předchozí nastavení. Ani tento kritický faktor nebyl aktivně řešen. PMBOK definuje ještě vedle řízení projektových prací jako samostatnou oblast projektovou kontrolu. Z uvedeného je vidět, že tato v podstatě nebyla řešena a podobně tomu bylo i s uzavřením projektu. Bylo zmíněno, že detailní koncept předpokládal vznik dokumentu, který by přesně stanovil akceptační kritéria, ale nikdy k tomu nedošlo. V okamžiku psaní těchto řádek byl sice systém v provozu, ale k formálnímu ukončení projektu ještě nedošlo.

68

9.4. Přínosy plánované a skutečné Obecně mohu přínosy nového systému rozdělit do dvou kategorií: přínosy kvantitativní a kvalitativní. Přínosy kvantitavní jsou přínosy spočitatelné a nejčastěji se v této souvislosti používá parametr návratnosti investice (Return on Investment – ROI). U kvalitativních přínosů jde o zlepšení stávajícího stavu, které ale nejde nominálně ocenit. Také u sledovaného projektu se v inicializační fázi argumentovalo oběma typy přínosů. Pokud jde o kvalitativní zlepšení procesu schvalování elektronických faktur, uváděly se např. tyto přínosy: • získání kontroly nad celým procesem zpracování došlých faktur (monitorování, vyhodnocování, automatické eskalace apod.) • zkrácení času potřebného pro zpracování došlé faktury včetně zaplacení • snížení chybovosti v průběhu celého procesu (ztráta dokladu během schvalování, zadání chybných údajů apod.) • možnost schvalovat faktury, i pokud je vedoucí pracovník mimo firmu • podpora pro lepší řízení peněžních toků Je pravdou, že např. kritérium zkrácení času zpracování by šlo zcela jistě kvantifikovat a firma Media House tuto možnost zvažovala, ale ukázalo se to natolik pracné (časové snímky přes celou organizaci), že se od toho úmyslu rychle ustoupilo. Pokud jde o kvalitativní kritéria, tak většina z nich se krátce po nasazení systému potvrdila. Proces zpracování faktur se stal mnohem plynulejším a finanční oddělení získalo naprostý přehled o tom, v jakém stavu a u koho se jakákoli došlá faktura nachází. Obraz faktury popř. další přílohy a historie schvalování se staly přístupnými pro všechny účastníky schvalovacího procesu, čímž se snížil počet dotazů na finanční oddělení. Jak jsem zjistil při sběrů podkladů pro analýzu, tak zcela jiná situace panuje u kvantitativních kritérií. Dokument se specifikací požadavků pro výběrové řízení obsahoval vypočet předpokládané návratnosti investice. Bylo zmíněno, že firma Media House se neodhodlala přesně změřit časovou náročnost ve všech částech stávajícího procesu. Vycházelo se tak z odhadu, který poskytla externí firma připravující specifikaci pro výběrové řízení a který se odvolával na praktické zkušenosti s obdobným řešením u dalších firem.

69

Odhad úspory vycházel ze zkušenosti, že nasazením řešení pro elektronické schvalování faktur se uspoří 20 až 40% času pracovníků, kteří se účastní procesu schvalování. Spočítal se tedy počet pracovníků, kteří došlé faktury zpracovávají (resp. ekvivalent zaměstnance na plný úvazek, angl. Full-Time Equivalent - FTE), vynásobil se průměrnou mzdou v daném oddělení a z celkové částky se spočítala předpokládaná úspora uvedených 20 až 40%. Návratnost investice (neboli podíl provozního příjmu a vstupní investice) po přepočtu vycházela na dva až tři roky, což je samo o sobě velmi dobrý výsledek a zároveň se tento odhad shodoval s údajem, se kterým běžně operují různí dodavatelé obdobného řešení zaručující rychlou návratnost investice po implementaci systému. V době přípravy této práce byl systém v provozu pouze krátkou dobu, ale když jsem zjišťoval při rozhovoru se zodpovědným pracovníkem skutečný stav, vyplynulo, že předpokládaných kvantitativních úspor se v žádném případě nepodaří dosáhnout. Jak bylo uvedeno, sice se zřídilo centrální pracoviště, kde se došlé faktury skenují a vytěžují (vytěžují se pouze data z hlavičky dokumentu) a následně se – již v elektronické podobě – rozesílají do jednotlivých organizačních jednotek ke schválení a následně do jednotlivých účtáren k zaúčtování a zaplacení. Zkušenost s vytěžováním dat je sice veskrze pozitivní, ale vzhledem k tomu, že vytěžená data je stejně potřeba validovat a v případě chyby opravit, tento krok příliš času neušetří. Každopádně se ukazuje, že díky automatickému vytěžování se výrazně zvyšuje kvalita den, ale to už je zase kvalitativní ukazatel. Pokud jde o další kroky v procesu, tak pro schvalování je výhodou, že doklad nemusí po firmě cestovat vnitřní poštou, ale vše běží elektronicky. Vzhledem k tomu, že interní pošta pochopitelně dopravuje množství dalších dokumentů, než jsou jen interní faktury, nebylo možno propustit žádného zaměstnance. A pokud jde o zaúčtování a zaplacení faktury, tak zde k žádné výrazné změně ani dojít nemohlo. Samotné zaúčtování musí v této konfiguraci proběhnout ručně. Vzhledem k tomu, že zaúčtování se přesunulo ze systému SAP do klienta systému Basware IP, odkud se data do SAP přenáší automaticky na pozadí, došlo spíše k mírnému nárůstu pracnosti, protože webový klient třetí strany nemůže nikdy nabídnout takový komfort jako je tlustý klient cílového systému, tj. SAP. Zkušenost tedy naznačuje, že k časové úspoře sice došlo, ale tato je rozprostřena mezi velké množství pracovníků, ale nový systém žádného z nich plně nenahradí, neboli nepředpokládá se v souvislosti s nasazením systému s propouštěním, spíše se vychází z toho, že systém ušetří část práce a takto uspořený čas bude zaměstnanec věnovat jiným pracovním aktivitám a spíše se může omezit nábor nových zaměstnanců v souvislosti s nárůstem obchodních aktivit firmy.

70

9.5. Doporučení pro další rozvoj Uvedené skutečnosti ilustrují fakt, že v případě firmy Media House se k výběru a implementaci systému přistupovalo nanejvýš utilitárním způsobem. Padlo rozhodnutí převést nejdůležitější interní proces (nejdůležitější s ohledem na řízení financí podniku) do elektronické formy a za tím účelem se vybralo a nasadilo konkrétní technické řešení. Iniciace a zahájení procesu proběhlo v podstatě standardním způsobem, ale jak jsem ukázal, plánování a realizace projektu probíhala nesystematicky. Nicméně systém se podařilo uvést do provozu, i když ve velkém zpoždění. V další části se chci věnovat doporučením, jak by se mohlo v případě firmy Media House dále postupovat a jakým směrem uvažovat.

9.5.1.

Nasazení systému v dalších zemích

Dle plánu měl být systém postupně nasazen i v dalších zemích. V průběhu pilotního projektu ale došlo k zásadní organizační změně: dceřiné společnosti ve střední a východní Evropě byly vloženy do společného podniku (joint venture) s jinou mezinárodní firmou působící v oblasti médií. Z toho důvodu byly všechny větší projekty pozastaveny a dochází k jejich revizi. Pokud by ale padlo rozhodnutí v projektu pokračovat (což se zdá být reálné), doporučuji pečlivě vyhodnotit pilotní projekt v mateřské firmě. Pokud jde o řízení projektu, tak zde doporučuji udělat několik zásadních změn. Nejdůležitějším podmínkou je aktivní podpora projektu ze strany nového vedení po celou dobu projektu. Jde sice o zřejmě nejčastěji opakovanou pravdu při řízení projektu, ale jak ukazuje zkušenost u firmy Media House, zdaleka ne samozřejmou. Pro zvýšení motivace vedoucích pracovníků (máme na mysli především finanční ředitele) v jednotlivých zemích, doporučuji určit projekt nasazení systému pro elektronické schvalování faktur jako jeden z klíčových cílů, dle kterého budou hodnoceni. Další podmínkou je důkladná příprava projektového plánu. S tím také souvisí důkladná analýza stávajícího stavu. V průběhu pilotního projektu byla zcela jistě odladěna celá řada věcí (integrace Basware IP s informačním systémem SAP, se systémem pro vytěžování dat i se stávajícím uložištěm), ale rozdíly lze očekávat ve způsobu schvalování faktur. Přestože ve všech společnostech byl před několika lety implementován tzv. interní kontrolní systém, což je v podstatě zjednodušená verze zákona Sarbanes-Oxley (SOX), který kromě jiného předepisuje, jakým způsobem má být schvalována faktura, tak skutečnost je taková, že schvalovací proces se v mezi jednotlivými zeměmi poměrně odlišuje. Aby se projekt neutopil v poměrně komplikovaném nastavování schvalovacích procesů (systém neobsahuje workflow

71

engine, vše je řešeno pomocí skriptů), doporučuji po zmapování stávajících schvalovacích procesů definovat jeden podnikový standard – i když třeba s více variantami - a ten následně prosadit. Dalším důležitým aspektem je zapojování „správných“ lidí do projektu od samého začátku. Jak jsem ukázal, velkou chybou v pilotním projektu bylo, že do výběru řešení nebyl přizván nikdo z budoucích uživatelů a veškerá jednání probíhala v poměrně úzkém kruhu. Vzhledem k tomu, že systém je již nasazen v mateřské společnosti, navrhuji, aby se v každé zemi řešení nejprve odprezentovalo široké skupině budoucích uživatelů a následně se v průběhu debaty identifikovaly různé zvláštnosti či speciality. Debata také ukáže naladění té které organizace k budoucímu systému a pomůže vytipovat správné klíčové uživatele. Vzhledem k tomu, že proces schvalování faktur vypadá ve většině společností dost podobně, mohu doporučit vedení definovat a prosadit jeden standard, který by se naimplementoval ve všech zemích. Další důležitou věcí jsou role a jejich obsazení. Popsal jsem, že pilotní projekt byl realizován („řízen“) dvěma lidmi. Dle mého jde o velkou chybu, která velmi přispěla ke zpoždění projektu. Při implementaci v dalších zemích je třeba především vytvořit a dobře obsadit roli projektového vedoucího s jasně vymezenými kompetencemi. Role projektového vedoucího musí být jasně oddělena od role zákazníka (uživatele). Vzhledem k rozdílným kulturám uvnitř jednotlivých národních organizací chci také doporučit zmapování role, kterou definuje PMBOK jako tzv. influencers, neboli lidé, kteří mohou (i když nutně nemusí být spojeni s výsledným produktem) projekt pozitivně či negativně ovlivnit. Cílem bude jakási mapa, která ukáže, kdo může projekt podporovat či naopak brzdit a dle toho navrhnout příslušnou strategii. Lidský faktor v projektu a aktivní zapojení důležitých lidí do projektu bude zřejmě nejdůležitějším úkolem, protože pokud jde o technickou stránku projektu, lze předpokládat, že v průběhu pilotního projektu se samotný systém odladil. Jestliže organizace tedy bude mít dobře zmapovanou a zanalyzovanou stávající situaci, bude vědět, jaký má být cílový stav a bude mít mechanismy, jak toto rozhodnutí prosadit, musí být nezbytně nutné připravit přesný plán projektu a tento (u)řídit, což byla věc, která se při pilotním projektu zcela ignorovala. Předpokladem je, že sponzor projektu bude o průběh projektu projevovat aktivní zájem. Také činnost řídícího výboru musí být pravidelná, tj. musí se pravidelně scházet a vyhodnocovat průběh projektu a v případě problémů tyto řešit. To vše v pilotním projektu bylo zanedbáno a vedlo k velkému zpoždění.

72

9.5.2.

Další rozvoj systému

Předchozí kapitola jsem věnoval doporučením pro to, aby nasazení projektu v dalších zemích proběhlo úspěšně. Nyní se podívám na postavení a možný další rozvoj nasazené aplikace s ohledem na konkrétní prostředí podniku Media House. Již bylo zmíněno, že firma nemá žádnou plnohodnotnou strategii a že k nasazení systému vedla konkrétní praktická potřeba – převést papírové schvalování faktur do elektronické podoby – a tím byl předurčen i výběr konkrétního řešení. Rozhodnutí nakoupit specializované řešení pro jednu konkrétní oblast nepovažuji za strategickou chybu s ohledem na nějaké budoucí celopodnikové řešení ECM. Pořízené řešení od firmy Basware se specializuje na celý proces pořizování a tento je obecně poměrně specifický: jde o uzavřenou procesní oblast, která se sestává z klasického řetězce poptávka > objednávka > dodávka > fakturace > zaplacení. Každý článek tohoto řetězce je úzce spojen s podnikovými informačními systémy a základem je zde dobré zaintegrováním jednotlivých aplikací do sebe. Toto vše pořízené řešení nabízí. Ze strategického hlediska dle mého tak nebude chybou, pokud by společnost měla v budoucnu jeden specializovaný systém pro schvalování faktur, zatímco všechny ostatní schvalovací procesy by byly řešeny v nějakém podnikovém systému ECM. Připomenu, že systém od společnosti Basware pracuje tak, že ze zdrojových systémů jako je např. SAP přebírá data (kmenová data dodavatelů či účtů, data objednávek, nákupních smluv atd.), která vytažena do prostředí systému Basware slouží pro schválení faktury nebo také objednávky (viz dále) a po schválení tuto informaci vrací zpět do zdrojového systému. Velkou výhodou je schopnost systému spolupracovat s různými ERP systémy a návrh řešení založený na velkém množství postupů ověřených praxí (best practices). Výsledkem je výrazné zefektivnění celého procesu pořizování, včetně zajištění shody s předpisy, automatizace jednotlivých procesů a možnost plné kontroly nad všemi procesy spojenými s pořizováním zboží či služeb. Firma Media House se rozhodla víceméně „pouze“ nahradit stávající systém schvalování faktur v papírové podobě systémem elektronickým a jedinou procesní změnou byla centralizace došlých faktur a jejich skenování a vše ostatní zůstalo v podstatě beze změny. To je dle mého hlavní důvodem, proč projekt splňuje předpokládané kvalitativní přínosy, zatímco u kvantitativních tomu tak není. Nasazení modulu pro schvalování faktur bych tedy doporučil pouze jako první krok směrem k zefektivnění celého nákupního procesu.

73

Pokud jde o technickou část, tak v ideálním případě by systém pracoval také s objednávkami či dodavatelskými smlouvami. V konečné podobě by se neodsouhlasovaly faktury, ale už objednávky a při dodání zboží či služby by systém pouze zkontroloval, zda dodávka odpovídá schválené objednávce (či smlouvě) a pokud ano, tak faktura by se zpracovala automaticky. Platformu Basware by bylo nutno napojit na další informační systémy, např. na výrobní systém v tiskárnách, který generuje objednávky. Ve výsledku by pak došlo k zásadnímu zrychlení a zefektivnění celého pořizovacího procesu. Tento krok by byl ale spojen s dramatickou procesní změnou. Nutným předpokladem bude nezbytná centralizace nákupního procesu (zcela jistě by nešlo „zkopírovat“ stávající proces do elektronické podoby jako v případě schvalování faktur) a zde by se jednalo o strategické rozhodnutí, kterému by musela předcházet velmi podrobná analýza. Nejsem zcela přesvědčen, že v současnosti by takový krok byl v silách společnosti Media House. Pokud jde o drobnější změny s větší šancí na realizaci, mohu firmě Media House jistě doporučit rozšíření stávajícího archivního uložiště o technologii elektronické značky a časového razítka, což by umožnilo uchovávat došlé faktury v elektronické podobě a ušetřit základy za archivaci listinných dokumentů. Otázkou ale je, nakolik by lidé zodpovědní za dodržování zákonných předpisů spojených s daňovými doklady (tj. finanční ředitelé) měli chuť a odvahu, šetřit právě na tomto místě. Přístup je obecně zatím spíše konzervativní. Při analýze jsem ale zjistil, že např. česká pobočka platí externí archivační firmě přibližně půl milionu Kč za archivaci a k tomu navíc kolem sto tisíc Kč za vyhledání dokumentů a jejich odeslání zpět do firmy. Alespoň tento náklad by bylo možno při důkladné digitalizaci dokumentů ušetřit. I tak bych firmě Media House doporučil zavést potřebné technologie pro výhradně elektronickou archivaci co nejdříve, přestože přístup ke zrušení listinného archivu je zatím velmi opatrný: jakmile někdy v budoucnu dojde k obratu (a s ohledem na současný vývoj soudím, že k tomu jistě dojde) a padne rozhodnutí, že dokumenty budou archivované výhradně v elektronické podobě, bude možno zpětně zrušit obrovské množství papírových archiválií, protože jejich digitální obraz již bude opatřen příslušnou technologií (elektronická značka a časové razítko). Jestliže se roční náklady za archivaci jen u jedné organizace pohybují kolem půl milionu korun, jde o investici, která se vrátí. Každopádně bych chtěl zdůraznit jednu zásadní věc a to, že stávající řešení dává vedení společnosti do rukou jednu důležitou možnost: proces zpracování a schvalování dodavatelských faktur se implementací řešení od firmy Basware stal nezávislým na místě. To znamená, že vedení může zvážit další možnou úsporu tím, že by se zredukoval počet účtáren a vybrané činnosti by se centralizovali. Např. v České republice je firma Media 74

House zastoupena vydavatelstvím a dvěma tiskárnami (v Praze a Ostravě) a každá jednotka má svoji vlastní účtárnu. Systém pro elektronické schvalování dodavatelských faktur tak odstranil technickou bariéru pro takové rozhodnutí a v tom vidím zřejmě největší strategickou výhodu nového systému. Nakonec bych chtěl připojit jednu poznámku. Je nutno si uvědomit, že veškeré kalkulace pro návratnost investice vycházejí z ceny obvyklé v západní Evropě či v Severní Americe. Náklady práce v České republice jsou v oblasti účetních služeb přibližně třikrát nižší (a dále na východ se rozdíl pochopitelně ještě prohlubuje), což dramaticky mění ukazatel návratnosti investice a z čistě ekonomického hlediska tak činí podobné projekty jako nevýhodné. Tím se ale oklikou dostáváme zpět ke strategii firmy a k tomu, co bylo řečeno. Návratnost investice je samozřejmě důležitým ukazatelem pro schválení a realizaci projektu, ale dle mého názoru by to neměl být ukazatel jediný. Každý velký projekt by měl představovat konkrétní reakci na stanovené strategické cíle a pak může nastat situace, kdy i dlouhá návratnost investice nebude znamenat zásadní překážku pro schválení projektu, protože bude jasné, jaké cíle jsou projektem sledovány v dlouhodobém horizontu a pak např. nový systém může primárně představovat prostředek k dosažení těchto cílů a to i bez ohledu na skutečnou (či zdánlivou) finanční nevýhodnost.

75

10. Závěrečné zhodnocení Tuto diplomovou práci jsem zahájil popisem jedné kongresové prezentace, která velmi efektně ilustrovala, kam dospěly systémy pro správu podnikového obsahu v roce 2010. Ano, technologie zaznamenala převratný pokrok a oblast ECM patří v oblasti informačních technologií k těm nejrychleji se rozvíjejícím. V první části práce jsem čtenáře nejprve přehledným a konzistentním způsobem seznámil s možnostmi systémů pro správu podnikového obsahu a také s tím, jaké přínosy lze jejich nasazením očekávat. V prakticky zaměřené části jsem na příkladu konkrétního projektu realizovaného mezinárodní mediální firmou – šlo o převod procesu zpracování a schvalování dodavatelských faktur z papírové do elektronické podoby – názorně ukázal, že přestože systémy ECM dnes nabízejí ohromující možnosti, je cesta k úspěšnému osvojení těchto technologií zdlouhavá a náročná. V uvedeném příkladu se jednalo o první rozsáhlejší nasazení komponent ECM (digitalizace dokumentů, řízení pracovních toků a archivace) do prostředí firmy. Navíc se jednalo o firmu, která neměla zkušenost s projektovým a procesním řízením ani jasnou podnikovou strategií. Domnívám se, že analýza realizovaného projektu především názorně ukázala, že pragmaticky pojaté rozhodnutí převedení stávajícího procesu z papírové do elektronické podoby je určitě možné a vzhledem ke konkrétní situaci i opodstatněné, ale je nutno počítat s tím, že možnosti systému pak nebudou plně využity a to zejména, jde-li o úsporu přímých nákladů spojených s daným procesem. Také jsem ukázal, že zatímco kvalitativní přínosy byly v tomto konkrétním příkladě neoddiskutovatelné, očekávané kvantitativní ukazatele se z uvedených důvodů nepodařilo naplnit. V doporučeních jsem pak popsal další možný rozvoj, který by přispěl k razantnějšímu zefektivnění interních procesů spojených s firemním nákupem (a jehož je schvalování faktur základní součásti) a poukázal, že pro takto zvolený cíl je nezbytnou podmínkou zájem a aktivní zapojení vedení firmy. Názorně jsem ukázal, že právě vědomý zájem vedení firmy o interní procesy a snaha dosáhnout metodickým přístupem vyšší operativní efektivity, je nezbytnou podmínkou pro další rozvinutí potenciálu ukrytého v pořízené technologii. Vedle procesního pohledu jsem se také zabýval vztahem dané technologie ke strategii firmy. Přestože je vysoce žádoucí, zasadit takto komplexní produkt do širšího strategického rámce, tak ve sledovaném případě jsem konstatoval, že volba specializovaného řešení byla s ohledem na okolnosti oprávněná a systém lze v budoucnu dále systematicky rozšiřovat a přispívat tak

76

k vyšší efektivitě vnitropodnikových projektů, jak jsem se pokusil názorně ilustrovat v předposlední části práce. Poslední oblastí, kterou jsem sledoval, byla samotná realizace projektu. Pro systematické posouzení průběhu projektu jsem si vybral jednu ze standardních metodik pro obecné řízení projektu (PMBOK). Právě v samotném řízení projektu jsem konstatoval a podrobně popsal největší nedostatky. Opět se zde potvrdilo klasické pravidlo, že pro úspěch projektu je jednou z nejdůležitějších podmínek aktivní podpora vedení firmy po celou dobu projektu. Přestože jde o pravdu neustále opakovanou, znovu a znovu se tato zásadní chyba opakuje a byl to i případ uvedeného projektu. Přestože se technologický pokrok neustále zrychluje a možnosti informačních technologií dosahují netušených možností, je třeba mít neustále na paměti, že to je a vždy bude pouze jedna část případného úspěchu. Bez poučeného strategického (a taktického) myšlení, které zasazuje nové technologie do širšího rámce prostředí podniku a jeho cílů a bez důsledného projektového řízení, nelze dosáhnout přínosů, které nové technologie přinášejí. Doufám, že tato obecně platná tvrzení se podařilo v této práci názorně ilustrovat.

77

Seznam použité literatury GÁLA, Libor; POUR, Jan; ŠEDIVÁ, Zuzana. Podniková informatika. 2.vyd. Praha: Grada Publishing, 2009. ISBN 978-80-247-2615-1. GÖTZER, Klaus et al. Dokumenten-Management. 4. Auflage. Heidelberg : dpunkt.verlag, 2008. ISBN 978-3-89864-529-4. JENKINS, Tom. Managing Content in the Cloud. 1st Edition. Ontario : Open Text Corporation, 2010. ISBN 978-0973066289. KUNSTOVÁ, Renáta. Efektivní správa dokumentů : Co nabízí Enterprise Content Management. 1. vyd. Praha : Grada, 2009. ISBN 978-80-247-3257-2. PROJECT MANAGEMENT INSTITUTE (Corporate Author). A Guide to the Project Management Body of Knowledge (PMBOK Guide). Third Edition. Pennsylvania: PMI, 2004. ISBN 1-930699-45-X. SVOZILOVÁ, Alena. Projektový management. 1.vyd. Praha: Grada Publishing, 2006. ISBN 80-247-1501-5. Zákon č. 227/2000 Sb. ze dne 29. června 2000 o elektronickém podpisu a o změně některých dalších zákonů. Zákon č. 499/2004 Sb. ze dne 30. června 2004 o archivnictví a spisové službě a o změně některých zákonů. Zákon č. 300/2008 Sb. ze dne 19. srpna 2008 o elektronických úkonech a autorizované konverzi dokumentů.

Internetové stránky

http://de.academic.ru http://www.aiim.org http://www.ibm.com http://www.virtualsapteched.com http://www.visioneer.com http://www.wfmc.org

78