- Přehledy IS
- APS (25)
- BPM - procesní řízení (23)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (31)
- CRM (52)
- DMS/ECM - správa dokumentů (19)
- EAM (17)
- Ekonomické systémy (68)
- ERP (75)
- HRM (28)
- ITSM (6)
- MES (33)
- Řízení výroby (36)
- WMS (28)
- Dodavatelé IT služeb a řešení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (41)
- Dodavatelé CRM (38)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (66)
- Informační bezpečnost (48)
- IT řešení pro logistiku (48)
- IT řešení pro stavebnictví (26)
- Řešení pro veřejný a státní sektor (27)


















![]() | Přihlaste se k odběru zpravodaje SystemNEWS na LinkedIn, který každý týden přináší výběr článků z oblasti podnikové informatiky | |
![]() | ||
Automatizujte administrativu!
Připadá vám standardní kancelářský software drahý? V takovém případě nejspíše nevyužíváte ani oněch pověstných deset procent funkčnosti. Je až tragikomické, jak občas arogantně přehlížíme možnosti ulehčení práce a zvýšení kvality informací. Pokud nemají obavy o efektivnost své práce uživatelé, měli by je mít manažeři, kteří zodpovídají za jejich produktivitu.


Doba se mění. Množství informací, které je potřeba zpracovat, se oproti tradiční organizaci zmnohonásobilo. To vede k rozsáhlé dělbě práce, která se navíc vyvíjí tak rychle, že nestačíme reagovat ani metodicky, ani technicky. Proto vznikají multiplicity – stačí se podívat na správu kontaktů. Přitom kancelářské aplikace již velmi dlouho nabízejí prostředky, jak využít propojování dokumentů mezi sebou, se zdroji dat a další automatizační scénáře. Jsou firmy, ve kterých jen okrajové rozšíření funkčnosti klienta elektronické pošty údajně ušetří desítky procent kapacity lidí v administrativě.
Lidé, kteří pracují s kancelářskými aplikacemi (čímž se myslí textový procesor, tabulkový procesor, program pro elektronickou poštu a případní příbuzní), by měli mít poměrně často pocit, že jim jejich práce nejde tak dobře, jak by měla. Tedy že by se některé operace dělat nemusely, nebo by se měly dát podstatně zjednodušit. Rozhodně by jim mělo vadit, pokud musí pořád cosi dohledávat, opravovat apod. Jenže typický uživatel ani jeho manažer obvykle netuší, že by se jejich práce dala radikálně zjednodušit. Je to pravděpodobně negativní důsledek představy, že pro využití kancelářských aplikací není potřeba nic dělat. Ta vyplývá z vyvolaného dojmu, že výrobce se postaral, aby jeho aplikace mohl „používat každý“.
Pokud uživatelé nemají obavy o efektivnost své práce, měli by je mít manažeři, kteří zodpovídají za jejich produktivitu. Jenže obvykle se tyto obavy jaksi nedostavují. Má to dvě příčiny – manažeři často nevnímají zodpovědnost za trvalé zvyšování produktivity svého týmu jako součást své role, a především ani uživatelé, ani manažeři nemají dostatečnou představu o tom, co všechno je možné. A jak známo, IT support většinou nechce mít představu ani o možnostech technologií, ani o potřebách uživatelů.
Obvyklá podoba práce
Pro demonstraci možností automatizace použijeme nejzákladnější scénář. To jsou data kontaktu. Naprostá většina uživatelů textového procesoru v něm občas vytváří dokument, který má obsahovat údaje o určitém kontaktu (osobě nebo firmě – ať už jako adresu dopisu, údaje ve smlouvě, nebo jenom identifikaci při hlášení či vystavení plné moci). Obvykle postupujeme tak, že si příslušnou osobu najdeme v podnikovém informačním systému nebo v adresáři (v horším případě ve vizitkách nebo někde v poznámkách na papíře).
Měli bychom vědět, že téměř vždy jde nějakým způsobem zkopírovat hodnotu a vložit ji někde jinde. Jenže ono to není tak jednoduché... Určitě každý zná situaci, kdy odněkud cosi zkopíruje, a když to chce někam vložit, tak s tím jsou neskutečné problémy. Možná proto řada lidí údaje opisuje (dost často takovým způsobem, že si nejdříve příslušný záznam vytisknou) do příslušného dokumentu v textovém procesoru. O formátování textových dokumentů mluvit nebudeme, to je velmi speciální kapitola sama pro sebe a určitě téma, které souvisí s podnikovou kulturou, grafickým manuálem a rozvojem dovedností spolupracovníků.
Hodně známý a triviální je příklad využití vazeb v tabulkovém procesoru (dohledání údajů podle zadaného identifikátoru – k tomu se ještě vrátíme z hlediska „korektnosti“ i zde zmíněné konstrukce). Podstatou je to, že kdesi existuje seznam položek a ty mají mimo názvu ještě další údaje – například kód (EAN či cokoli jiného), cenu, hmotnost, atomovou váhu nebo popis vlastností. Tuto položku a její vlastnosti používáte ve svém výpočtu (typicky je to nabídka, respektive kalkulační list, což je vcelku rozumné použití tabulkového procesoru).
Název dané položky si pamatujete, ale rozhodně nenosíte v hlavě celou tabulku. Zcela jistě víte, nebo alespoň tušíte, že musí být možno dané údaje po zadání identifikace položky dohledat. Přesto to už pět let děláte tak, že si otevřete příslušný seznam, listováním najdete danou položku – a protože ty údaje jsou v jiném pořadí a jinak formátované, než potřebujete, tak je pro jistotu raději opíšete.
Negativní důsledky
Lidé se snaží zvládnout své úkoly. Považují za normální, že si s využitím aplikací musí poradit sami. Protože nemají k dispozici potřebná pravidla a nástroje, zoufale hledají pomocnou ruku na konci vlastního ramene. Každý se s tím, co má dělat, rve, jak umí. Výsledky vidíme všude kolem sebe – provizoria a nedodělky, nekonzistentní data, multiplicity, chyby, konflikty.
Katastrofickým scénářem je to, když velká stavební firma plánuje své zakázky v tabulkovém procesoru a následně tyto údaje mechanicky přepisuje do aplikace podporující řízení projektů. V tomto formátu totiž zákazník požaduje plán prací. Aby nedošlo k mýlce – potřebuje jej pouze k tomu, aby si vytisknul hezký Ganttův diagram. Na otázku, proč to tak dělají, existuje odpověď: protože s těmi tabulkami to „každý“ umí... Zkuste si pro tuto situaci domyslet všechny souvislosti! Příslušný tabulkový procesor pochopitelně každý používá, jak se to metodou pokus–omyl naučil.
Pravděpodobné plýtvání kapacitou lidí, kteří pracují na přípravě zakázky, je mezi padesáti a osmdesáti procenty (bez jakéhokoli doplňování funkčnosti). Takže když si vezmeme řádově desítku lidí, kteří na tom pracují několik týdnů, jedná se o zhruba člověkorok na každou zakázku. A kdybychom jen okrajově doplnili funkčnost standardní aplikace na podporu řízení projektů, tak se pracnost přípravy zakázky může snížit na těžko odhadnutelný zlomek současného stavu. Například u jedné firmy rekonstruující městské osvětlení jsme propojili řízení projektu s jejich geografickým informačním systémem, který dodával informace o počtu svítidel, a s nákupem, kde se řešilo objednávání materiálu – a ejhle, nástroj pro řízení projektů mohl vytvářet pracovní úkoly, evidoval odvedenou práci a dal se plnohodnotně použít pro skutečné řízení projektu.
Uvedené příklady jsou jenom ilustrativní. Určitě si vybavíte spoustu podobných situací. Obecně platí, že nerozumné je cokoliv opisovat, hledat údaje čtením, vytvářet něco, co už bylo jednou vytvořeno, neuložit si to, co jsem udělal atd. Navíc je velmi pravděpodobné, že u řady činností si člověk neuvědomí, že dělá něco zbytečně složitě, či přímo nesmyslně. Za každý nový (neuvedený na www.contros.cz/priklady) příklad, který pošlete, máte možnost získat zdarma řešení. Samozřejmě jsou i odstrašující příběhy, demonstrující to, že se nasazením IT v organizaci nikdo nezabýval – například když uživatelé mají v tabulkovém procesoru tak velké objemy dat, že to tabulkový procesor nezvládá nebo se musí budovat složité mechanismy, aby se vůbec daly najít ty informace, které jsou potřeba. Spíše pro pobavení by měla být absurdní historka o dokumentu, který obsahoval tisíce různých textů vytvářených řadu let od vzniku firmy. Nebo to, že sekretářka po několika letech používání textového procesoru zjistila, že se dokument dá i uložit.
Podpora a dovednosti
A dostáváme se k jedné z klíčových otázek – jak by mělo vypadat zajištění IT gramotnosti? Na spoustě míst se setkáváme s názory, že školení počítačových dovedností je drahé. Tedy neefektivní – za vynaložené prostředky a čas nezískáme užitek, který potřebujeme. To má řadu příčin a souvislostí, které nemáme prostor rozebírat, ale určitě se jim budeme věnovat někdy příště. Je vůbec správná představa, že jsou to právě uživatelé, kteří musí získat více IT dovedností? Neměl by to být náhodou někdo jiný? Někdo, kdo by měl pomáhat manažerům (protože po těch už vůbec není korektní chtít, aby se věnovali profesionálnímu zvládnutí IT problematiky)? Na tyto otázky se pokusíme odpovědět v závěru článku.
Uživatelé se nesnaží nalézt efektivnější metody práce a možná je ani najít nemohou. Dokonce mají problém i s uplatněním hotového řešení. Například v případě výše zmíněného dohledávání dat v tabulkách byla potřebná funkčnost doručena – vytvořen ukázkový sešit s podrobným popisem dvou vyhovujících přístupů. Ovšem uživatel, který si stěžoval, že by takovouto funkčnost potřeboval, najednou tvrdí, že nemá čas se tím zabývat. Jenže pozor! Nejspíš to není chyba přístupu tohoto uživatele. On totiž opravdu není a možná ani nemá být hodnocen za to, že hledá efektivnější pracovní postupy (zní to strašlivě). Za obvyklých okolností platí, že čím víc námahy vynaloží, tím lépe bude hodnocen.
Přesně tady si musíme položit otázku – čím (vším) se má běžný uživatel zabývat? Zkusme naprosto triviální příklad – zpracování příchozí elektronické pošty. To je na první pohled tak jednoduchá záležitost, že jednodušší být nemůže. Každý spolupracovník by tedy měl být schopen najít si sám pro sebe rozumný postup. Zkušenosti ovšem říkají, že to vůbec není jednoduché. A co je v pozadí? Nejspíše to, že běžný uživatel má dost práce se svou vlastní profesí – ať už je to bankovní úředník, obchodník či účetní. Je korektní po nich chtít, aby se zabývali funkčností IT? Je tato oblast samostatnou profesí, nebo není? Kolik kapacity je potřeba pro vstřebání rozumného množství informací umožňujícího navrhnout pracovní postupy, které s dostatečnou pravděpodobností nemají zásadní negativní efekty a přiměřeně využijí potenciál nasazených aplikací? Nehledě k potřebě zohlednit týmové (celopodnikové) zájmy a sdílet získané know-how.
Technologické možnosti
Mělo by být normální, že když není možno používat jediný centrální celopodnikový seznam (firemních) kontaktů, tak seznamy kontaktů, které fungují v různých systémech (v typické organizaci existují přinejmenším v systému elektronické pošty a základním podnikovém informačním systému) musí být synchronizovány. Není možné se smířit s tím, že nám kdosi říká, že to „nejde“. Prostě by nemělo být možné, abychom o jediném subjektu měli více rozdílných údajů či aby, když je kontakt zadán v jednom systému, jej bylo potřeba zadávat ještě někde jinde podruhé. Což pochopitelně platí nejenom pro kontakty.
Speciální případ je to, když nejsou k dispozici úplná data a je potřeba dohledat údaje o příslušném subjektu v nějakých veřejně dostupných informačních zdrojích. Dnes už asi není, či spíše nemělo by být problém připojení k internetu, takže mám k dispozici spoustu užitečných informačních zdrojů. Z těchto zdrojů je obvykle velmi jednoduché získat přímo data (konkrétně u našeho příkladu osob je skvělým příkladem živnostenský rejstřík). Data se dají relativně snadno získat i z jiných zdrojů. Pokud je to tedy možné, měli bychom takto získaná data zkompletovat a uložit do centrální databáze a teprve následně je systémově použít.
Problémem v tomto případě zdaleka není jen bezprostřední produktivita práce, ale zejména kvalita dat, nutnost řešení případných problémů vzniklých tím, že jsme použili nesprávné údaje a další vyvolané komplikace. Navíc pokud není zcela jasné, jakým způsobem kdy kdo údaje použil či změnil, spotřebujeme nejvíce kapacity na dohledávání toho, co se vlastně stalo – pokud to vůbec budeme dělat. Vidíme uživatele zoufale hledající potřebné údaje. Zdlouhavě ověřují, která verze dat vlastně platí. Jak často se stane, že si přepíší novější verzi dokumentu tou starší?
Ideální scénář
Jednoduché otázky vyžadují jednoduché odpovědi. Určitě znáte situaci, kdy zvenčí (protože co se týče interních tabulek, to je jiné téma) přijde přílohou elektronické pošty tabulka, do které externí partner potřebuje doplnit cosi z transakcí, které jste s ním za minulé (či pro budoucí) období realizovali (například vyúčtování bonusů a poplatků obchodnímu řetězci). Obvykle některý z pracovníků obchodní administrativy vezme šanony s fakturami, vyhledá faktury příslušného partnera, opisuje si údaje a potom velmi pracně a s vysokou pravděpodobností chyb vyplňuje zaslanou tabulku.
Vynaložením nijak dramatického úsilí lze dosáhnout radikální změny a snížení spotřeby času ze dnů na minuty. Téměř všechno může probíhat automaticky či s minimální a komfortní interakcí s uživatelem. U elektronické pošty lze víceméně poloautomaticky reagovat na všechny zprávy s přílohami určitého typu. Ze zprávy se zjistí, o kterého partnera se jedná. Přiložená tabulka se analyzuje a zjistí se, jestli ji algoritmus „zná“ (jestli na ni může uplatnit šablonu datové struktury). Pokud lze data z tabulky interpretovat a uživatel potvrdí typ zpracování (např. ono vyúčtování, cenová architektura, návrh akčních položek apod.), popřípadě zadá parametry navrhované transakce, další zpracování může proběhnout podle příslušného algoritmu automaticky. Pokud je struktura tabulky nová, případně je nová transakce, kterou je potřeba provést, vytvoří systém nebo uživatel požadavek na doplnění funkčnosti.
Může se zdát, že vytvoření potřebné funkčnosti je příliš nejisté nebo náročné. Ale ve skutečnosti je to naopak – ruční či jakékoli nesystémové zpracování musí být logicky náročnější a méně spolehlivé než vytvořit nový scénář v existujícím prostředí (rámec, který umožňuje interpretovat data, propojit je s vlastními datovými sklady či přímo provozním systémem, provést potřebné výpočty – vše probíhá tam, kde je to nejefektivnější, zde v databázovém systému). Povinnost systémového zpracování s sebou nese podstatnou výhodu. Například v naznačeném scénáři přinutí příslušného manažera, aby přesně definoval příslušnou funkčnost. Navíc díky centralizovanému řešení bude pravděpodobně možno s jednoduchými úpravami použít scénář i pro jiné zákazníky.
Algoritmus vytvoří či vyplní požadovanou tabulku a po odsouhlasení ji pošle danému zákazníkovi. Není možné, aby ji „omylem“ poslal některému jinému zákazníkovi, který by s údivem zjistit, jaké ceny má od nás jeho konkurent. A toto je relativně komplexní scénář. Určitě vidíte kolem sebe desítky mnohem jednodušších příkladů – třeba zpracování reklamací, smluv, hlášení pro různé orgány, vyřizování stížností, vystavování plných mocí atd.
Zpřístupnění dat
Hlavní výhodou systémového řešení je to, že se minimalizuje prostor pro chyby, duplicitní práci, zvyšuje se pravděpodobnost účelného využití dat a disponibilní funkčnosti. Jedna podstatná poznámka – navrhovaný přístup není ani náhodou určen pouze pro velké organizace. Naopak – ty si zjevně mohou dovolit plýtvat kapacitou a nebýt ochotny přizpůsobovat se potřebám partnerů. Největší význam má racionalizace využití kancelářských aplikací právě pro menší firmy, u kterých se víc než o úspory jedná o schopnost zvládnout vyžadované úkony – spolupracovat potřebným způsobem a ve stanovených termínech.
Základní otázka, kterou musíme zodpovědět, je to, jestli by měla být data, která jsme (v případě přijetí myšlenky o standardizaci a synchronizaci) pracně sjednotili, kopírována – nebo když tedy tvrdíme, že to jde jednoduše zařídit, tak rovnou synchronizována – do nějaké tabulky tabulkového procesoru. Využijeme příklad se seznamem (například produktů, ale klidně to může být tabulka mzdových tříd nebo seznam klasifikovaných neshod), který máme v tabulkovém procesoru a úspěšně jsme vyřešili to, aby se nám při použití aktualizovaly vázané údaje. Ano, je relativně snadné převzít data z databáze do tabulkového procesoru a můžeme pracovat, jak jsme byli zvyklí. Jenom je sporné, jestli je to tak správně. Jistě, je to tak nejjednodušší. Jenže vůbec není jisté, jestli to tak má být.
Je tento scénář rozumný (či spíše přijatelný) a máme ho podporovat? Jednoduchá odpověď zní, že nikoliv. Data patří do databází. Když chceme v nějakém dokumentu používat data z databáze, je potřeba zajistit, aby tato data byla od obsahu dokumentu jasně oddělena a tím zajištěno, že v případě změny dat dojde i k potřebné změně obsahu dokumentu. Proto je potřeba zajistit, aby údaje, které byly automaticky doplněny z databáze, byly uživatelsky nemodifikovatelné (zamčené) a aktualizovaly se v případě potřeby. Jenže to zdaleka není všechno. Jak bylo naznačeno již výše, klíčovým požadavkem je především to, aby z kancelářských aplikací bylo možno centrálně uložená data plnohodnotně aktualizovat – to znamená s dodržením referenční i doménové integrity. A to dnes také není – či spíše neměl by být – vůbec žádný problém.
Je potřeba od naší IT podpory vyžadovat, abychom měli k dispozici co nejjednodušší možnost připojit se z libovolné kancelářské aplikace ke všem existujícím seznamům (osoby, tj. zákazníci, dodavatelé, spolupracovníci aj., zařízení, projekty, artikly, objednávky, faktury – prostě všechna podniková data), zobrazit a využít z nich vše, na co máme oprávnění, a jednoduše propojit tyto údaje do našich dokumentů, e-mailů či plánovaných schůzek. Ve skutečnosti to vůbec není složité, stačí jednoduché doplňky kancelářských aplikací a korektní řešení přístupu k aplikačním databázím.
Doporučení
Standardní kancelářské aplikace mají tak velké množství funkcí, že se v nich nejspíše nevyznají už ani jejich tvůrci. Co je na nich v posledních pár letech obzvlášť zajímavé, to je naprosto zásadní rozvoj podpory pro zvyšování produktivity. Bohužel nové nástroje a mechanismy nejsou vidět a vzhledem k zažité podobě administrativní práce nás ani nenapadne nové vlastnosti hledat a zkoušet.
Doporučení je, abychom pro tuto oblast využili profesionální podporu. Oblastí je myšlena komplexně produktivita lidí využívajících kancelářské aplikace, a zejména oblast konsolidace a zpřístupnění podnikových dat. Profesionální podporou se rozumí člověk, který této oblasti skutečně rozumí. Pokud jsme firma s méně jak padesáti lidmi využívajícími kancelářské aplikace a podniková data, možná se nám nevyplatí získat a zapracovat vlastního specialistu. V takovém případě ovšem není možno rezignovat – právě u menších firem může mít absence určitých funkcí fatální důsledky – je potřeba zajistit tuto podporu formou outsourcingu. Zapojení externího dodavatele přinese užitek i v případě vlastního specialisty – zejména ve smyslu získání existujících řešení a sdílení zkušeností, případného rozšíření kapacity, systematického rozvoje dovedností vlastního člověka a v řadě dalších aspektů.
Role pro tuto podporu není správce sítě, ale někdo, kdo by měl být označován jako specialista (či možná manažer) produktivity, možná správce dat a funkčnosti. Z velké části tvoří jeho kvalifikaci schopnost vytvářet inteligentní dokumenty a potřebnou dodatečnou funkčnost zajišťující napojení na datové zdroje organizace. Jeho povinností je také rozvoj nezbytných dovedností uživatelů k využívání doručené funkčnosti.
Slíbené doporučení ke „školení“ – především dobře promyslet a zodpovědně zjistit a ověřit, jaké dovednosti k čemu konkrétně lidé ve svých rolích skutečně potřebují. Je velmi pravděpodobné, že obecná (veřejná) školení příliš nepomohou a jejich hodnocení jako „drahá“ je oprávněné. Lidi pravděpodobně není žádoucí „školit“ (ve smyslu vysvětlovat, co je „možné, úžasné…“) – chce to závazná realistická pravidla a k nim odpovídající technicko-organizační podmínky. Pravidla, to znamená definovat povinnosti a vymáhat jejich plnění.
Dobrá zpráva na závěr je, že ve spolupráci s MS Inovačním Centrem v Brně uspořádáme sérii workshopů, na kterých budete moci získat spoustu konkrétních doporučení, návodů. Navíc si sami můžete určit, jakým tématům se chcete věnovat.
e-mail: petr.opletal@autori.ccb.cz
www.SystemOnLine.cz


![]() ![]() | ||||||
Po | Út | St | Čt | Pá | So | Ne |
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 1 | 2 | 3 | 4 |
5 | 6 | 7 | 8 | 9 | 10 | 11 |
Formulář pro přidání akce
15.5. | Konference SCADA Security |
22.5. | Akce pro automobilové dodavatele "3DEXPERIENCE... |
12.6. | Konference ABIA CZ 2025: setkání zákazníků a partnerů... |
29.9. | The Massive IoT Conference |