Zvýšení produktivity administrativy

17. 09. 2005 Petr Opletal

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. Přesněji řečeno "nepotřebujete ho".

Zvýšení produktivity administrativy

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ě.

Způsob zpracování informací 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. 

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. Obvykle se tyto obavy 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 co je rozumné. 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 nebo ú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.

Je to sice škoda práce, ale hlavní škoda vzniká tím, že v historii daného kontaktu se tato transakce neobjeví. Je obtížné dohledat všechny dokumenty, které se příslušného člověka týkají - a to i když existují pravidla pro názvy souborů, protože není k dispozici nástroj, který by je vynucoval či alespoň kontroloval.

O úpravě a vzhledu textových dokumentů škoda mluvit, 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ů. Musíme pochopit, že běžný uživatel prostě žádné vlastní formátování nastavovat nesmí.

Data v tabulkovém procesoru

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ř. 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, resp. 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ž je 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. 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 – danou aplikaci zákazník potřebuje pouze k tomu, aby si vytiskli hezký Ganttův diagram (popř. aby návrh plánu prací předal v požadované podobě zadavateli zakázky). 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! Navíc skutečnost je taková, že příslušný tabulkový procesor 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 50 a 80 % (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ř. 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ř. 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 většinou 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ř. 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í elektronické pošty. Rozumí se organizace složek, pravidla, techniky, využití funkčnosti klientské aplikace atd. To je na první pohled tak jednoduchá záležitost, že jednodušší být nemůže. Z tohoto úhlu by to tedy každý spolupracovník měl být schopen zvládnout. To znamená najít si (sám pro sebe?!) rozumný postup. Zkušenosti ovšem říkají, že právě toto vůbec není jednoduché.

Co je v pozadí? Je obtížné zodpovědně říci, jaké znalosti jsou potřeba k tomu, abychom našli "přijatelný" způsob. 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í? <tohle mělo být formulováno jinak> Kolik kapacity je potřeba pro vstřebání rozumného množství informací umožňující 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 (nevynalézat kolo).

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, tak 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ěl 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, tak nejvíce kapacity spotřebujeme 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ř. 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. Víceméně 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.) a popř. zadá parametry navrhované transakce, další zpracování může proběhnout podle příslušného algoritmu automaticky. Pokud je struktura tabulky nová, popř. 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 může být 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í sebou nese podstatnou výhodu. Např. 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 – třeba zpracování reklamací, smluv, hlášení pro různé orgány, vyřizování stížností, vystavování a evidence plných mocí apod.

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 ochotni 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ř. 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 – 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é, 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 50 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í, rozšíření kapacity v případě potřeby, 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 aplikací". 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í standardní a rozšiřující 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í technickoorganizační podmínky. Pravidla 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.

Data a dokumenty

Jedna z oblastí, která doznává v poslední době velmi rychlého rozvoje, je separace dat. To je pravděpodobně jedna z klíčových výhod komerčního software od podobných aplikací, které nemají tento charakter a většinou ani srovnatelné funkce. Je totiž pravda, že potřebnou funkčnost standardizovaným způsobem lze zajistit pouze s využitím adekvátně standardizované funkčnosti na straně serveru. Není možno se zabývat technickou stránkou architektury, která umožňuje efektivní spolupráci.

Podívejme se ovšem z uživatelského hlediska, o co v praxi jde.

  • Nutno zapojit mozek (struktury, …) … nemůže to dělat paní „Vomáčková“ …
    Sice chybí možnost jednoduše procházet dokument a značkovat příslušné části dokumentu jako datový obsah a takto vytvořenou šablonu datové struktury potom aplikovat na ostatní dokumenty tohoto typu.
  • Otázka – jak (kdy, čím, proč) se vyplatí standardizovat
    Vždyť přece typicky tabulky se pořád vyvíjejí … každou novou verzí …
    Jasně – jde pouze (typicky) o tabulku
  • Příklad – kalkulační list zakázky. Několik verzí, ve kterých se střídá Word a Excel, občas snaha to zkombinovat … ve skutečnosti je „nutná“ potřeba (pro jednotlivce) to provázat s kalendářem, úkoly a navíc pokud si to chcete odsouhlasit se zákazníkem, tak i zapojit e-mail.
    Chybí nebo nechybí možnost jednoduše propojit definici dat s prvky uživatelského rozhraní obsaženými v dokumentu a přenášet vlastnosti (např. formát dat, povinné vyplnění, číselník atd.).
    … tady jde o čistě technickou záležitost pro vlastní potřebu – jak se mají (???) používat CustomXML, XSD a placeholder-y, aby to alespoň trošku dávalo smysl?
  • Proč nepoužíváme aplikace rozumně
    • Zápas běžného uživatele s textovým procesorem.
    • Nevyužívání možností prezentačního software (předdefinovaných polí, formátů, poznámek, pozadí, …).
    • Jak je to se školením? Jakou formu má mít? Lze se mu „zcela“ vyhnout? Kdy je to efektivní? Jak má vypadat? Chceme školit obecné dovednosti nebo pomoci lidem efektivně plnit jejich konkrétní pracovní povinnosti?
  • Neschopnost používat úkoly v systémech groupware.
  • Neschopnost mít pořádek v poště. Neschopnost odeslat odkaz místo příloh.
  • Neumí základní klávesové zkratky. Místo klávesových kombinací se přes desetistránkový dokument přesouvají držením šipky doprava.
  • Neumí zadat takový výraz, podle kterého se alespoň něco najde.
  • Jak funguje moderní organizace
  • Jak organizovat informace
  • Centralizovat! Klasifikovat! Formalizovat!
  • Zrušit černé deníčky (převést všechny platné a hodnotné informace z hlav lidí a jejich podpůrných evidencí do centralizovaného systému).
  • Eliminovat nepřehledné stromy adresářů v souborovém systému.
  • Zakázat lokální disky. Centralizovat správu a nastavení všech aplikací.
  • Kde to jde, mít šablony.
  • Inteligentní dokumenty
  • Nepřepisovat údaje z obrazovek podnikového IS ani nekopírovat "exporty".
  • Umět se dotázat na data ... a vědět, "že tam někde jsou".
  • Vědět, že existuje něco jako datový sklad.
  • Zpřístupnit číselníky.
  • Ale především všechny reálné transakce zaznamenat do relačních dat, aby se daly provázat s dalšími.
  • Navíc standardní možnosti pro propojení na konkrétní záznamy z databáze jsou poněkud omezené. Zejména při zadání řídícího identifikátoru je jednoduchá funkčnost pro uživatelské rozhraní (tzn. nabídka seznamu) zjevně nedostačující, protože potřebujeme mít možnost uplatnit např. ostatní již zadané údaje – např. zákazníka, datum či jiné informace, které usnadní dohledání či zajistí správnost položek. Také onen řídící údaj, který určuje propojení do databáze, by asi neměl být uživatelsky srozumitelný název, ale spíše databázový klíč, který by měl zůstat skrytý.