Na tomto přelomovém místě bych rád vyjádřil poděkování především svým rodičům a celé mé rodině za jejich péči a výchovu, které se mi dostalo a která mě vedla ke vzdělání na vysoké škole – rodinné alma mater Matematicko-fyzikální fakultě Univerzity Karlovy. Zároveň patří poděkování mému vedoucímu práce, panu profesoru J. Královi, za jeho výuku, která mě přivedla k problematice Informačních systémů a umožnila mi napsat tuto diplomovou práci. Poděkování patří také všem ostatním pedagogům, kteří mě vedli po cestě poznání. V neposlední řadě bych chtěl poděkovat všem svým přátelům a kolegům v zaměstnání i odborných kruzích. Děkuji vám všem.
Prohlašuji, že jsem svou diplomovou práci napsal samostatně a výhradně s použitím citovaných pramenů. Souhlasím se zapůjčováním práce. V Praze dne 16. 7. 2009
Bc. Otto Gold
1
Obsah 1 2
Úvod .......................................................................................................................................................5 Teoretická část........................................................................................................................................6 2.1 Podnikový informační systém ........................................................................................................6 2.1.1 Šíře informačního systému .....................................................................................................6 2.2 ERP systémy na trhu .......................................................................................................................7 2.2.1 Společnost SAP AG .................................................................................................................7 2.2.2 Společnost Microsoft ..............................................................................................................8 2.2.3 Společnost Oracle ...................................................................................................................9 2.2.4 České ERP systémy .................................................................................................................9 2.3 Uživatelské rozhraní a jeho kvalita ...............................................................................................10 2.3.1 Použitelnost - Usability .........................................................................................................10 2.3.2 Human-Computer Interaction ..............................................................................................11 2.3.3 Interaction design .................................................................................................................11 2.3.4 User-centered design ...........................................................................................................11 2.3.5 Efekt vylepšení „Usability“ ...................................................................................................12 2.3.6 Metody zlepšování Usability.................................................................................................12 2.3.7 Heuristiky pro návrh UI.........................................................................................................13 2.4 Pořizování dat do SAP ERP ............................................................................................................14 2.4.1 Licence SAP ...........................................................................................................................14 2.4.2 Přehled technologií pro tvorbu UI v SAP ..............................................................................14 2.5 Technologie elektronických formulářů.........................................................................................16 2.5.1 IBM Forms ............................................................................................................................16 2.5.2 Cardiff Software....................................................................................................................16 2.5.3 Microsoft Infopath................................................................................................................16 2.5.4 602 XML ................................................................................................................................16 2.6 Použitelnost SAP a formulářů .......................................................................................................17 2.6.1 Použitelnost SAP ...................................................................................................................17 2.6.2 Hlavní problémy použitelnosti SAP ......................................................................................17 2.6.3 Použitelnost formulářů .........................................................................................................18 2.7 Pořizování dat do SAP pomocí Adobe Forms ...............................................................................19 2.7.1 Přínosy technologie e-formulářů pro běžného uživatele .....................................................20 2.7.2 Porovnání e-formulářů a webových stránek ........................................................................20 2.7.3 2.7.4
Důležité pojmy a různé typy formulářů ................................................................................21 Integrace Adobe elektronických formulářů do SAP .............................................................22
2.7.5 Licenční modely Adobe PDF Forms ......................................................................................23 3 Praktická část ........................................................................................................................................24 3.1 Analýza příčin ...............................................................................................................................24 3.2 Využití formulářů pro pořizování dat ...........................................................................................25 3.3 Usability systému..........................................................................................................................26 3.4 Popis zkoumaných informačních systému ...................................................................................27 3.4.1 Definice popisných ukazatelů ...............................................................................................27 2
3.4.2 3.4.3 3.4.4
Výběr demonstrační problematiky .......................................................................................29 Popis konkrétních systémů...................................................................................................30 Zobecnění popisu systému ...................................................................................................33
3.5 Definování modelu pro měření Usability systému .......................................................................34 3.5.1 Návrh kritérií pro hodnocení Usability systému při pořizování dat do IS.............................35 3.5.2 Interpretace navržených stupnic hodnocení pro jednotlivá kritéria ....................................38 3.5.3 Hodnocení skupin uživatelů a rozhraní ................................................................................40 3.6 Příprava modelu pro hodnocení Usability systému .....................................................................41 3.7 Měření Usability systému .............................................................................................................42 3.7.1 Zlepšování Usability systému ...............................................................................................45 3.7.2 Různé způsoby modelování systému ...................................................................................46 4 Měření Usability zkoumaných systémů................................................................................................47 4.1 Měření Usability systému A ..........................................................................................................47 4.1.1 4.1.2
Model systému .....................................................................................................................47 Ohodnocení systému ............................................................................................................47
4.1.3 Hodnocení Usability..............................................................................................................50 4.2 Měření Usability systému B ..........................................................................................................51 4.2.1 Model systému .....................................................................................................................51 4.2.2 Ohodnocení systému ............................................................................................................51 4.2.3 Hodnocení Usability..............................................................................................................53 5 Závěr .....................................................................................................................................................54 6 Literatura ..............................................................................................................................................55 6.1 Citované zdroje .............................................................................................................................55 6.2 Ostatní zdroje ...............................................................................................................................57 7 Přílohy ...................................................................................................................................................58
3
Abstrakt Název práce:
Prostředky zjednodušující pořizování dat v rozsáhlých podnikových informačních systémech v prostředí SAP
Autor:
Bc. Otto Gold
Katedra (ústav):
Katedra softwarového inženýrství
Vedoucí diplomové práce: prof. RNDr. Jaroslav Král, DrSc. email vedoucího:
[email protected]
Abstrakt:
Diplomová práce se zabývá otázkou, jak jsou různá uživatelská rozhraní do informačního systému vhodná pro různé skupiny uživatelů IS. Autor v práci zkoumá jaký dopad má použití vhodného nebo nevhodného rozhraní na efektivitu pořizování dat uživatelem v měřítku rozsáhlého informačního systému. Práce analyzuje požadavky uživatelů na IS a jeho uživatelská rozhraní a jak dobře rozhraní požadavky uživatelů splňují. Autor práce navrhuje exaktně měřit kvalitu vztahu rozhraní a uživatelů a exaktním postupem hledat deficity v takovém vztahu. Technologii e-formulářů autor používá pro demonstraci moderních inovativních uživatelských rozhraní, které mohou lépe vyhovět potřebám některých skupin uživatelů.
Klíčová slova:
informační systémy společnosti SAP, uživatelská rozhraní, Usability rozhraní, pořizování dat do informačních systémů
Title:
Means simplifying data entry in large ERP based on SAP framework
Author:
Bc. Otto Gold
Department:
Department of Software Engineering
Supervisor:
prof. RNDr. Jaroslav Král, DrSc.
Supervisor's e-mail address:
[email protected] Abstract:
The thesis deals with the problem how are the various information system user interfaces suitable for the various groups of users of the IS. The author examines the impact of using suitable or unsuitable user interface on data entry process effectiveness in the scale of large IS. The thesis studies the user demands on IS and its interfaces and how well the interfaces solve these users demands. Author of the thesis suggests the measurement of the relationship quality between the users and the interface and using the exact method of search for the deficiencies in this relationship. The eforms technology is used to demonstrate that the new-fashioned and innovative user interfaces exists and can solve some users demands in the appropriate manner.
Keywords:
SAP-based information systems, user interfaces, Usability of user interface, process of data entry to information system
4
1 Úvod Dnešní organizace – komerční firmy, státní organizace, školy a další - se neobejdou bez podpory IT nástrojů. Význačnou pozici mezi těmito nástroji hraje informační systém. Systém má pomoci efektivně řídit stále složitější děje, které v organizaci probíhají a spravovat data, která se v průběhu těchto dějů zpracovávají. Rostoucí složitost dějů v organizacích vyžaduje kontinuální rozvoj informačního systému. Jednou z aktuálních reakcí dodavatelů IS na tuto situaci je zdokonalování integrace dat a služeb systémů. Integrace má umožnit organizaci pracovat ideálně s jediným datovým zdrojem, který každý uživatel využívá v kontextu své vlastní konkrétní práce, a využívá přitom jednotnou metodiku. Jak roste vliv IS na chod organizace, roste i přímý vliv jeho uživatelů na produktivitu organizace a další ukazatele výkonu. Dodavatelé IS hledají stále nové metody a nástroje jak rozvíjet a zdokonalovat uživatelské rozhraní. Každé, i dílčí vylepšení uživatelského rozhraní, má značný dopad na efektivitu práce s IS. Kromě zrychlení práce uživatelů v systému lze dosáhnout také změn v postojích lidí k informačním technologiím. Z uvedených důvodů jsou investice do přípravy kvalitních uživatelských rozhraní oprávněné. Také v oboru IS se prosazuje aktuální trend komfortizace, kdy vývojáři usilují o co nejvhodnější začlenění nových uživatelských rozhraní do práce uživatelů. Před několika lety byl hlavním trendem ve vývoji uživatelských rozhraní vývoj webových rozhraní informačních systémů a tzv. portály, která integrují do jednoho elektronického pracoviště všechny data a služby, které uživatel využívá ke své práci. Webová rozhraní výrazně posunula použitelnost informačních systémů blíže k uživatelům. Výrazně se vylepšila použitelnost systémů pro uživatele, kteří nejsou výhradně technicky orientováni a kteří používají ke své denní práci pouze zlomek funkčnosti systému. Aktuální novinkou ve vývoji uživatelských rozhraní jsou tzv. elektronické formuláře. Autoři těchto řešení se snaží vytvořit technologii, která posune jednoduchost a intuitivnost uživatelského rozhraní na další úroveň. Toho se snaží dosáhnout elektronizací běžných papírových formulářů, se kterými se člověk setkává celý život a které doprovázejí činnosti v každé organizaci. Přes značné investice do technologií elektronických formulářů ze strany předních dodavatelů software a informačních systémů není jasné, jak široké uplatnění e-formuláře naleznou v denní práci. Svá řešení elektronických formulářů připravují firmy celosvětového i regionálního významu – Adobe, Microsoft nebo IBM celosvětově nebo společnost 602 pro regionální trh. Vyvinuté aplikace pracují jako samostatné systémy nebo jako další uživatelské rozhraní pro existující informační systémy. Je samozřejmé, že využít tento nový přístup nelze vždy a všude. Cílem předkládané diplomové práce je:
Popsat technologii e-formulářů a navrhnout její účelné zapojení do množiny technologií pro vývoj uživatelských rozhraní SAP systému, Navrhnout, jak mohou e-formuláře zvýšit efektivitu pořizování dat do IS SAP, Změřit efektivitu pořizování dat před a po zapojení rozhraní založených na e-formulářích, Navrhnout postup, jak měřit efektivitu pořizování dat do systému podle toho, jak se mění množina a kvalita uživatelských rozhraní, Demonstrovat na konkrétních systémech, jak se mění efektivita pořizování dat podle množiny uživatelských rozhraní, Na základě dosažených výsledků navrhnout způsob, jak měřit efektivitu pořizování dat do IS a jak na základě takto získaných exaktních dat navrhnout rozvojová opatření pro zvýšení této efektivity.
5
2 Teoretická část 2.1 Podnikový informační systém Dnes již si nedokážeme představit fungování žádné organizace bez informačních technologií. Potřeba rozsáhlejšího informačního systému v organizaci je úměrná náročnosti a provázanosti úkolů, které organizace řeší. V případě malých organizací stačí každému uživateli používat na své stanici kancelářské aplikace. Každý uživatel zvládá své úkoly samostatně nebo ve spolupráci s jedním z kolegů, se kterými může osobně spolupracovat. Žádný problém není tak rozsáhlý, aby nebylo možno ho rozložit na úkoly, které nezvládne jednotlivec v kancelářské aplikaci. Od určité fáze rozvoje organizace však už není možno úlohy řešit jednotlivě. Tento stav souvisí především s:
Počtem pracovníku organizace, počtem pracovníků v jednom oddělení apod., Regionálním rozvojem, kdy je potřeba koordinovat práci více poboček atd., Objemem práce, kdy pracovníci mají přesně vymezený úkol, na kterém spolupracuje více lidí (typicky napříč odděleními nebo dokonce regionálně), Požadavky na přesnost, rychlost, bezpečnost, spolehlivost apod.. V této fázi rozvoje organizace je vhodné implementovat podnikový informační systém. Ten umožní řešené úlohy vhodně integrovat a umožnit uživatelům spolupráci na řešených úkolech. Základem této integrace je integrace dat, kdy všichni uživatelé systému pracují s daty v jednotné databázi. Aplikační logika podnikového IS se stará o to, aby každý uživatel systému viděl svou specifickou část sdílené databáze dle úloh, které vykonává. Funkčnost systému je obvykle rozdělena na moduly dle jednotlivých hlavních agend (Účetnictví, Mzdy, Řízení skladu, Plánování, Řízení výroby atd.). V rámci modulů jsou přiřazeny uživatelům role, které určují, jak jednotliví uživatelé přistupují v podnikovém systému ke svým úlohám, která data a funkce jsou oprávněni používat apod. Pro podnikové informační systémy se vžila anglická zkratka ERP (Enterprise Resource Planning Systém). Velmi kvalitní vymezení pojmu ERP uvádí Wikipedia (heslo: Enterprise resource planning) [1].
2.1.1 Šíře informačního systému Data zapsaná do IS tvoří jen menší, i když nejvíce formalizovanou část údajů a informací, které jsou v organizaci zpracovávány. Lze navrhnout jednoduchou hierarchii dat dle jejich vazby k informačnímu systému, podobně jako to uvádí Basl, Blažíček [2] :
úroveň 1: Informační systém realizovaný IT prostředky – informace jsou zpracovávány především prostřednictvím relační databáze, lze využít automatizace pomocí IT nástrojů, úroveň 2: Širší formalizovaný informační systém – informace zpracovávané pomocí kancelářského softwaru nebo v papírové, ale ve strukturované podobě; data by bylo možno v budoucnu integrovat do informačního systému, úroveň 3: Volný informační systém organizace – informace, kterými organizace a její zaměstnanci disponují, ovšem tyto informace nemají vhodnou podobu a formu pro zpracování formálními prostředky a pro začlenění do IS. Tato diplomová práce mimo jiné navrhuje, jak vybraná data z širšího IS organizace (úroveň 2) začlenit pomocí elektronických formulářů do IS realizovaného IT prostředky (úroveň 1).
6
2.2 ERP systémy na trhu Následující stručný přehled uvádí vybrané význačné dodavatele ERP systémů na českém trhu. Účelem je, zasadit pozici společnosti SAP a jejího produktu SAP Business Suite do kontextu trhu ERP technologií. Uvedené informace čerpají ze zdrojů jednotlivých dodavatelů a také Přehledu IS *3+.
2.2.1 Společnost SAP AG Produkty společnosti SAP v oblasti podnikových informačních systémů mají dlouhou tradici vývoje. Společnost SAP za 30 let své existence uvedla na trh celou řadu verzí, které se vžily pod označením R2, R3, SAP All-in-one, SAP Business Suite apod. Implementace SAP představuje přizpůsobení standardních modulů potřebám konkrétní organizace. Implementací SAP získá organizace kromě samotného systému také rozsáhlé know-how, kterým je funkčnost systému podložena. SAP Business Suite zahrnuje například následující moduly, což uvádí Wikipedia *4+ nebo Basl, Benda [5]: MM (Material Management), HR (Human Resources), FI (Finance), SD (Sales and Distribution) a další. Technologická platforma SAP NetWeaver, na které jsou produkty SAP postaveny, zahrnuje rozsáhlou škálu nástrojů pro integraci. Wikipedia [6] uvádí mimo jiné tyto: XI (Exchange Infrastructure) na výměnu zpráv mezi systémy, Portál integruje ve webovém prohlížeči různé datové zdroje a aplikace do virtuálního pracoviště, SAP Webflow je nástrojem pro modelování procesů v rámci systémů SAP i mimo ně a další. Systém je postaven na jazyce ABAP. Tento jazyk je optimalizován pro snadné provádění databázových operací a návrh jednoduchých uživatelských rozhraní. Jazyk ABAP je v aplikacích SAP integrován s mnoha technologickými standardy třetích stran. Specifickou pozici v rámci portfolia má aplikace Business One, která se stala předmětem nedávné akvizice a nesdílí jádro s hlavní SAP ERP aplikací Tato aplikace je určená především pro malé a střední podniky. Zjednodušeně lze říci, že kromě Business One má SAP jeden stěžejní produkt, který prodává v různých konfiguracích. Tabulka č. 1: Tabulka popisuje aktuální stav využití ERP produktů firmy SAP v ČR. Sap Business One
SAP All-in-one
Přibližně 110
Počet instalací produktu
SAP Business Suite
Splývá s Business Suite
Přes 800
3 - 6 měsíců
6 měsíců
Pro jakou velikost podniku je produkt určen malé podniky (obrat do 100 mil. Kč) středně velké podniky (obrat 100 mil. - 1 mld. Kč) velké podniky (obrat nad 1 mld. Kč) Reference Průměrná doba implementace u podniku střední velikosti
1- 2 měsíce
Velikost nejmenší a největší instalace (v počtu uživatelů)
1 / 60
Hlavní referenční zákazníci
do 50 / nad 2000 uživ. Do 10 / nad 6000 uživ.
Angločeská, Panep Hero Czech, Misan
SIKO KOUPELNY, RABAT ČR, SAAR GUMMI, FOSFA
7
ČEZ, ŠKODA Auto Česká spořitelna Ministerstvo vnitra
2.2.2 Společnost Microsoft ERP systémy společnosti Microsoft používají značku MS Dynamics. Jedná se o dva produkty – menší systém NAV (dříve NAVISION) a větší AX (dříve AXAPTA). Oba systémy společnost Microsoft získala akvizicemi podniků, které systémy vyvinuly. Jednou z předních výhod ERP systémů společnosti Microsoft je úzká integrace s široce používanými nástroji MS Office, případně nástroji elektronické pošty Outlook a Exchange. Společnost Microsoft uvádí, že Dynamics NAV přináší integrované řešení pro podporu:
Řízení financí (účetní nástroj, sledování trendů, flexibilní správa účetnictví, reporting a další), Řízení dodavatelského řetězce - SCM (podpora výroby a distribuce, implementace obvyklých výrobních filosofií atd.), CRM a E-Business, Zaměstnanecký portál (webový přístup uživatelů do ERP systému s nižšími nároky na licenci a odbornost uživatelů, poskytuje elektronické pracoviště mimo hlavní ERP). ERP systém Dynamics AX obsahuje podobné moduly jako NAV a navíc přidává další: Marketing, Řízení projektů, Obchod a marketing, Lidské zdroje a další. Uživatelské rozhraní systému AX je možno upravovat pomocí nástroje MorpX a vývoj aplikační logiky systému probíhá ve vlastním jazyce X++. To je překvapivé s ohledem na to, že společnost Microsoft nabízí kvalitní nástroje pro vývoj v rozšířenějších jazycích (C#, C++ atd.) především produktem Visual Studio. Ilustraci jazyka X++ nabízí Wikipedia (heslo: Axapta) *7+. Tabulka č. 2: Tabulka stručně popisuje aktuální stav využití ERP produktů Microsoft v České republice. Dynamics AX
Dynamics NAV
80
680
4 - 8 měsíců
4 měsíce
1 / 3000 (zahraniční reference)
1 / 500
NOWACO, Datart, Meopta-Optika, Královopolská, A.S.A., Český Caparol, FenStar, ORCO Prague, LINDAB s.r.o., Meggle s.r.o.
AAA Auto, Mountfield, Auto Palace Praha, Nemocnice Na Homolce, Krajský úřad Plzeňského kraje, Jednota SD Opava
Počet instalací produktu (počet zákazníků) Pro jakou velikost podniku je produkt určen malé podniky (obrat do 100 mil. Kč) středně velké podniky (obrat 100 mil. - 1 mld. Kč) velké podniky (obrat nad 1 mld. Kč) Reference Průměrná doba implementace u podniku střední velikosti Jaká je velikost nejmenší instalace (v počtu uživatelů) Hlavní referenční zákazníci
a
největší
8
2.2.3 Společnost Oracle Hlavní produktem na poli ERP společnosti ORACLE je produkt E-Business Suite. Jeho filosofie i dodávané moduly systému jsou velmi podobné jako u systému SAP. Hlavní moduly jsou: CRM, Financials, Human Resources Management, Logistics, Mobile Supply chain Applications, Order Management, Transportation Management, Warehouse Management Systems . Před akvizicí společností Oracle byla společnost Siebel dodavatelem úspěšného CRM řešení. Po akvizici v roce 2005 byl Siebel integrován do E-Suite jako CRM. Jednou z velkých výhod ERP řešení Oracle je úzká technologická spolupráce s RDBMS Oracle, které patří ke špičce v oboru databázových nástrojů. Tabulka č. 3: Tabulka stručně popisuje aktuální stav využití ERP produktů firmy Oracle v ČR. více než 100
Počet instalací produktu (počet zákazníků)
5 / 1200
Velikost nejmenší a největší instalace (v počtu uživatelů)
České aerolinie, a.s. OEZ s.r.o., VÍTKOVICE, a.s. JABLONEX GROUP a.s.
Hlavní referenční zákazníci
2.2.4 České ERP systémy Značnou část trhu s ERP systémy ovládají regionální dodavatelé. Hlavním důvodem je především geografická blízkost a společný jazyk se zákazníky. Dalším důvodem je také finanční hledisko, kdy regionální systémy lze pořídit (včetně služeb a podpory) za cenu výrazně nižší než systémy globálních dodavatelů. Regionální dodavatelé také dokážou lépe postihnout specifika trhu a jeho potřeb, a to včetně legislativy. Regionální ERP systémy nedisponují stejně širokým portfoliem jako ty globální, to však ani není cílem. Cílem regionálních dodavatelů je uspokojovat potřeby regionálně působících organizací, které jsou odlišné od globalizovaných společností, kde má velký ekonomický i strategický význam využívat ve všech částech světa stejný informační systém. Poznámka: Autor diplomové práce si nekladl za cíl provést rešerši českých dodavatelů ERP. Tabulka č. 4: Pro porovnání využití ERP systémů regionálních a globálních dodavatelů uvádí tabulka informace o vybraných českých ERP systémech. Systémy do tabulky byly vybrány náhodně. Dodavatel Počet instalací produktu (počet zákazníků)
Karat
Vema
ABRA
268
4 000
15000 (z toho 3000 pro ERP systém)
Pro jakou velikost podniku je produkt určen malé podniky (obrat do 100 mil. Kč) středně velké podniky (obrat 100 mil. - 1 mld. Kč) velké podniky (obrat nad 1 mld. Kč)
(Express, Advance) (Advance, Enterprise) (Enterprise)
Reference Průměrná doba implementace u podniku střední velikosti
3 - 5 měsíců
3 měsíce
2 měsíce
Velikost nejmenší a největší instalace (v počtu uživatelů)
1 / 206
1 / 300
1 - 2500 zaměstnanců
Hlavní referenční zákazníci
HORTIM International, Rodinný pivovar BERNARD, Hanácká Kyselka, CIDEM HRANICE, GRAPO
9
Kancelář prezidenta republiky, Úřad vlády ČR, ČSOB a. s., Ministerstvo financí ČR, FAB a. s.
Armáda spásy, Českomoravský fotbalový svaz, EXIM tours, JRC, Logos, SONY czech,
2.3 Uživatelské rozhraní a jeho kvalita Abychom mohli hovořit o efektivitě práce uživatele v systému, je potřeba formálně definovat, jak uživatel se systémem komunikuje a jaké faktory ovlivňují jeho práci v systému. Uživatelské rozhraní (UI z anglického User Interface, nebo GUI z anglického Graphic UI) můžeme velmi jednoduše definovat jako komunikační kanál mezi uživatelem a systémem. Kvalita uživatelského rozhraní podmiňuje vztah uživatele ke zpřístupňovanému systému [8]. Poznámka: Takto definuje problematiku GUI například Wikipedia (heslo: Graphical User Interface) [9]). Když hovoříme o UI, máme na mysli aktuální generaci uživatelsky přátelských rozhraní a systémů (userfriendliness, user-friendly). Stanovení principu tzv. „přátelskosti“ je však vágním vyjádřením a neexistuje dohodnutý způsob měření nebo stanovení co je a co již není „User-friendly“. Termín user-friendliness [10+ lze chápat například jako:
Synonymum k pojmu “snadný k užívání”,
Vykazování kvality “lidského přátelství”, tj. existuje předpoklad, že vztah člověk - počítač je interpersonální povahy a komunikace by měla být s ním příjemná,
Uvedená vlastnost „přátelskost“ je ryze neformálního charakteru. Protože vlastnost není nijak formálněji popsána, nelze ji vhodným způsobem měřit a následně využít ke srovnání různých uživatelských rozhraní. Pro porovnávání uživatelských rozhraní definujeme pojem „Usability“, který kombinuje různé parametry rozhraní (intuitivnost, jednoduchost, zpracování chyb, dostupnost nápovědy atd.) do jednoho ukazatele. Usability překládáme jako Použitelnost. O použitelnosti a jejím zkoumání podrobně referuje další kapitola. Poznámka: V textu kapitol jsou vyznačena tvrzení, která budou dále použita pro aplikaci v oblasti využití formulářů jako hlavní zkoumané technologie pro tvorbu GUI.
2.3.1 Použitelnost - Usability Obecně Usability vyjadřuje míru obtížnosti použití nástroje k provedení zadaného úkolu. Usability (ve vztahu k softwaru) vyjadřuje, jak „obtížně“ se softwarový nástroj ovládá a jak je přizpůsoben dobrému použití uživatelem. [11] Přesněji se jedná o průnik výsledků ukazatelů jako například, jak dané rozhraní umožňuje pracovat efektivně, rychle, bez chyb apod. Tato práce využívá pojem „Usability IS a jeho GUI“, především proto, aby na základě rozdílu v Usability jednotlivých rozhraní pro různé skupiny uživatelů bylo možné navrhnout sadu opatření, které povedou ke zvýšení Usability IS pro uživatele. Tuto sadu opatření a návrhů naleznete v praktické části této práce. Pro porovnávání či měření Usability lze definovat různá kritéria, například tato:
Přehlednost GUI pro uživatele,
Schopnost vyhledat potřebná data a funkce,
Dostupnost nejčastěji používaných funkcí (uspořádání GUI podle frekvence využití prvků),
A další ukazatele, které ovlivňují pohodlní a efektivitu uživatele v denní práci…
Stěžejním dokumentem pro Usability a další kvalitativní požadavky na software je Evropská norma ISO 9241 (kapitola 10 – „Dialogue principles“), která se zabývá hlavně:
Přizpůsobením systému problému řešenému uživatelem,
Přizpůsobením očekáváním uživatele,
Možností personalizace dle přání uživatele,
Přizpůsobením pro lepší pochopení a naučení se pro uživatele a „samo-popisnost“,
Schopností vyrovnat se s chybami a dalšími doporučeními.
10
2.3.2 Human-Computer Interaction HCI je vědní obor, který se zabývá zkoumáním komunikace uživatele se (softwarovým) systémem skrz rozhraní a vlastnostmi tohoto komunikačního vztahu. Jedná se o variantu obecné ergonomie přizpůsobené pro potřeby zkoumání ergonomie softwarových nástrojů. Jde o hraniční obor, který využívá poznatků jiných oborů a vhodně je kombinuje. Zároveň je důležité, že výsledky jsou vhodně aplikovatelné a přinášejí měřitelný (a finančně vyjádřitelný) efekt. Obor se zabývá prací v těchto oblastech (jak uvádí *12]):
Metodologiemi a postupy návrhu uživatelských rozhraní (jak navrhnout rozhraní pro daný problém, pro daného uživatele a daná omezení a s ohledem na to, aby byly splněny konkrétní požadavky na určité vlastnosti - př. minimalizace chyb, intuitivnost pro jednorázové použití atd.),
Technologiemi a implementací navržených uživatelských rozhraní,
Technikami ohodnocení a porovnání UI z hlediska definovaných atributů,
Rozvojem existujících a vývojem nových způsobů interakce,
Modely interakce a chování.
Výsledky jsou v oblasti software/ IS okamžitě ekonomicky aplikovatelné v různých podobách: oblíbenost a komerční úspěšnost, prožitek z používání („user-experience“), rychlost práce, redukce chyb a další navržené postupy a úpravy.
2.3.3 Interaction design Obor „Interaction design“ (jak ho definuje například *13+) se snaží vylepšovat „Usability“ zkoumaného systému ve dvou fázích:
Analýzou řešeného problému uživatelem a konkrétní potřeby uživatele (otázky: co, kdo a proč),
Návrhem a implementací řešení problému (řešení jak).
Charakteristické je osobní zkoumání uživatelů, při pohovorech nebo zkoumáním chování uživatele při řešení úloh na pracovišti atd. Tato osobní spolupráce s uživatelem má značný pozitivní efekt na identifikaci uživatele s vyvinutým řešením nebo aplikací (označme jako tvrzení 1) a na informovanost uživatele o možnostech řešení (průnik možností systému a očekávání uživatele snižuje pocit frustrace z toho, že systém nesplňuje očekávání).
2.3.4 User-centered design Ústřední myšlenkou oboru je, že „Uživatel je centrálním a určujícím činitelem celého informačního systému“ *14]. Bez respektování potřeb konkrétních uživatelů systém pracuje do jisté míry naprázdno a z ekonomického hlediska neefektivně. Jedním z postupů práce pomocí user-centered designu je prototypování, což formuláře umožňují velmi dobře (označme jako tvrzení 2). Zároveň od fáze prototypování je uživateli jasné, jaké jsou možnosti, a vnímá vysokou angažovanost na výsledku, protože se na něm sám podílí. Je obvyklé, že dle požadavků uživatele iterativně probíhá nový vývoj pro zlepšení práce uživatele nebo opravy vzhledu a chování se stejným cílem (označme jako tvrzení 3).
11
2.3.5 Efekt vylepšení „Usability“ Aplikace postupů pro zlepšení Usability v prostředí podnikových systémů si klade za cíl především ekonomický přínos. Proto je zajímavé zkoumat efektivitu vynaložení prostředků na vylepšení usability („Return of Investments (ROI) of Usability“). ROI lze pro přehlednost rozdělit na více pod-částí – například interní a externí, jak uvádí *15+. Z hlediska uživatele nás zajímá především uvedená interní ROI, externí zajímá především dodavatele technologie nebo informačního systému. Příklady možné interní návratnosti investic na vylepšení použitelnosti systému/ rozhraní:
Snížení objemu chyb,
Zvýšení produktivity uživatelů,
Zrychlení procesů,
Snížení objemu dotazů na help-desk, snížení objemu asistence uživatelů, zdržení při potížích,
Snížení nákladů na školení a uživatelskou podporu,
Dosahování úspor v úpravách systému, jestliže implementační proces zohledňuje „usability“ od počátku vývoje,
Subjektivně lepší pocit z práce.
Příklady externích benefitů jsou: zvýšení objemu prodeje/ implementací systému/ technologie, snížení nákladů na podporu zákazníků, loajalita zákazníků atd.
2.3.6 Metody zlepšování Usability Příklady metod zlepšování Usability uvádí například *16+ takto:
Cognitive Walkthrough – zkoumání, jestli vyvinutý prototyp splňuje dobrou použitelnost ve vztahu k aktuálnímu pod-cíli, při postupu od počátku do vyřešení cíle. Důraz je kladen na sladění Usability pro jednotlivé cíle s cílem hlavním a na úpravy použitelnosti s ohledem na dílčí kroky. Focus Groups – metoda pracuje se skupinou uživatelů. Účelem je získat zpětnou vazbu na předložené návrhy a především seznámit se s předpoklady, očekáváními a požadavky budoucích uživatelů systému. Skupinová povaha práce je efektivnější než práce s každým účastníkem testování zvlášť a vede k formulaci konsensuálních myšlenek. GOMS (zkratka pro „Goals, Operators, Methods, and Selection Rules“) – teoretická metoda, která pracuje s definicí základních objektů a operací s nimi a z těchto prvků modeluje chování uživatele. Metoda může poskytnout poměrně kvalitní matematická vyjádření chování uživatele v systému (jestliže například ohodnotíme dílčí operace časy atd.). Prototyping – metoda, kdy vývojáři připraví zjednodušený model systému, v průběhu vývoje je možné míru zjednodušování snižovat, takže uživatel má model budoucí aplikace k dispozici v různých stádiích vývoje od nákresů, přes snímky budoucích obrazovek, jednoduchých webových stránek modelujících aplikaci, verzi aplikace v budoucím vzhledu a chování kromě řešení specifických problémů; na základě zkušeností s prototypy může vývojový tým aplikovat změny vyžádané uživatelem co nejdříve. Task Analysis – analytická metoda, kdy předmětem zkoumání jsou cíle, kterých je třeba dosáhnout a především způsobu jak uživatel těchto cílů dosahuje v reálném provozu aplikace; Na základě chování je možné předkládat návrhy na zlepšení jednotlivých kroků procesu nebo jejich návaznosti Usability Inspection – metoda revize Usability, kdy na základě definovaných standardů a vzorů kontrolujeme, jestli vyvinutá aplikace tyto vzory a standardy vhodně aplikuje do praxe. User Testing – metoda vyhodnocování formálně definovaných testů chování uživatelů na skutečných aplikacích, kdy na základě výsledků lze navrhovat úpravy s ohledem na vylepšování jednotlivých ukazatelů 12
2.3.7 Heuristiky pro návrh UI Příkladem aplikace heuristik pro vylepšení použitelnosti aplikace jako metody, ve smyslu výčtu metod výše, může být následující sada pravidel od J. Nielsena *17+. Nielsen sestavil sadu heuristik, které se dodnes používají jako možný základ pro revizi navrhovaného designu software z hlediska použitelnosti. Vznikl stručný seznam pravidel, která kontrolují jednotlivé částí GUI, které mohou působit problematicky pro chování a následnou orientaci uživatele v programu. Výčet navrhovaných heuristik (ve stručné adaptované formě):
Znázornění stavu systému – uživatel musí být stále informován o tom, co systém dělá, Čitelný vztah mezi systémem a světem uživatele – uživatel musí rozpoznat v systému své pojmy, Svoboda ovládání – systém by měl mít označenu „únikovou cestu“ a funkce Zpět a Vpřed, Dodržování standardů a chování – v systému by měly platit jednotné standardy ovládání, Prevence chyb – vhodnými nástroji je třeba upozorňovat uživatele, že může způsobit chybu, Znázornění údajů systémem – při složitých akcích uživatele je důležité uživateli všechny relevantní údaje neustále zobrazovat, aby uživatel nebyl nucen „vzpomínat“ na předchozí průběh práce nebo se v práci vracet, Nástroje urychlení pro profesionálního uživatele - umožnit uživateli automatizaci práce vedoucí k urychlení rutiny, Minimalistický design – dialogy by neměly obsahovat věci, které přímo nesouvisí a mohou rušit, „Návodnost“ jak opravit chyby – popis chyb by měl být netechnický a vést uživatele k řešení, Dostatek nápovědy a dokumentace – vše orientovat na vyřešení problému uživatele.
13
2.4 Pořizování dat do SAP ERP 2.4.1 Licence SAP Licenční politika společnosti SAP předurčuje jejich ERP pro velké a finančně silné společnosti. Ale i ty se dnes snaží minimalizovat náklady spojené s implementací a provozováním ERP. Důsledkem finanční náročnosti profesionálních SAP licencí, umožňujících plnohodnotný přístup do SAP ERP (vkládání, editaci, zpracování, tisk a ukládání zpracovávaných dat) je, že provozovatelé ERP se snaží omezovat přístup k ERP. Což ve finále výrazně snižuje efektivitu vynaložených investic. Rozvoj informačních technologií v posledních letech ale nabízí řešení tohoto problému. Technologie pro tvorbu uživatelského rozhraní mimo SAP ERP sice vyžadují další licence, ale jejich přidaná hodnota je vysoká. Tyto technologie:
Jsou mnohem levnější než profesionální licence samotného SAP ERP, Umožňují zprostředkovat klíčové funkce pro pořízení resp. zobrazení potřebných dat a informací široké skupině zaměstnanců, tak aby se jimi dala zajistit plná elektronizace podnikových procesů, Jejich obsluha je mnohem komfortnější a jednodušší pro uživatele s nižší úrovní počítačové gramotnosti, čímž lze výrazně snížit náklady na školení uživatelů IS.
2.4.2 Přehled technologií pro tvorbu UI v SAP Následující přehled je hrubým rozdělením technologií pro tvorbu uživatelského rozhraní v SAP. V rámci každého z prostředí existuje více způsobů jak UI vytvořit, které vypadají velmi podobně, nebo se dokonce totožného vzhledu dosahuje různými prostředky. Markantní podobnost všech technologií vývoje nalezneme především u SAP portálu (webové rozhraní pro data a aplikace). Pomocí technologií ABAP WebDynpro, Java WebDynpro, BSP a dalších dosahujeme téměř totožného výsledku (pomíjíme pokročilé funkce nebo komfort a efektivitu vývoje). Následující přehled prezentují odlišnosti uživatelského rozhraní na procesu Pořizování docházky.
SAP GUI – „tlustý“ klient SAP ERP Obrázek č. 1: Jeden z možných způsobů zadání docházky zaměstnance operátorem SAP. Vysoká finanční náročnost licence SAP ERP znamená, že s tímto nástrojem obvykle nepracuje běžný uživatel.
14
SAP Portál – webové rozhraní SAP Obrázek č. 2: Standardní nástroj (dodávaný SAP) pro zadávání vlastní docházky zaměstnancem pomocí webového prohlížeče. Aplikace obsahuje méně funkcí než ERP aplikace ilustrovaná výše. Uživatel má méně možností udělat chybu při zpracování docházky. Zadávání je vícefázové a stav procesu pořizování docházky je nahoře graficky znázorněn.
SAP Interactive Forms by Adobe Obrázek č. 3: Návrh elektronického formuláře pro pořizování docházky analogicky jako to umožňovaly předchozí aplikace. Návrh klade důraz především na intuitivnost použití. Formulář se vyplňuje analogicky, jak se to dnes provádí na papírový formulář nebo např. do MS Excelu a lze ho elektronicky podepsat.
Využitím Nielsenových heuristik pro návrh UI uvedených v kapitole 2.3.2 lze posoudit posun uživatelské přístupnosti webové aplikace oproti výše ilustrované ERP aplikaci a dále oproti formuláři. Využitím poznatků o charakteru práce skupin uživatelů v kapitole 2.3.4, že vhodným uživatelem webového prostředí a uživatelem ERP aplikace jsou příslušníci odlišných skupin. To samé platí pro navrhovaný formulář, který dále usnadňuje práci a je přístupný odborně méně zdatným zaměstnancům.
15
2.5 Technologie elektronických formulářů Tato práce se zabývá především pořizováním dat do IS pomocí elektronických formulářů společnosti Adobe. Existují však další řešení elektronických formulářů. V následujícím přehledu jsou naznačeny alternativy k technologii Adobe včetně stručně shrnutých nebo ilustrovaných technologických a aplikačních odlišností. Srovnání produktů e-formulářů na trhu uvádí například Murphy [18]. Specifickou pozici v následujícím přehledu má technologie 602 XML forms, protože se jedná o řešení české společnosti. Je proto popsána detailněji, ačkoli nedosahuje parametrů globálních řešení. Vhodné oficiální zdroje o řešeních jednotlivých dodavatelů jsou jejich webové stránky [19a-d].
2.5.1 IBM Forms IBM je kromě společnosti Adobe silným subjektem na poli elektronických formulářů. Nabízí vizuální nástroj pro návrh formulářů, který může efektivně obsluhovat školený uživatel a vývojář. Nástroj využívá nejnovějších trendů například v podobě využití XML, webových služeb, SOA (Service Oriented Architecture) atd. Pozice IBM a Adobe na trhu se poněkud liší, výhodou Adobe je integrace formulářů s nástrojem Reader, výhodou IBM je integrace do širokého portfolia nástrojů podnikových IS a kancelářského software (WebSphere Portal, produkty IBM Workplace, Lotus Notes/Domino a další). IBM se také více profiluje otevřenými standardy (jako XForms), zatímco Adobe je z větší části proprietární platforma. Pro vývoj se používá aplikace Designer a pro zpracování potom Viewer. V tomto je technologie IBM podobná Adobe, ačkoli Adobe Reader je rozšířen po celém světě bez ohledu na zpracování formulářů.
Obrázek č. 4: Ilustrace vývojového prostředí IBM Forms. Vývoj probíhá vizuálně využitím palety standardních komponent (na obrázku vlevo).
2.5.2 Cardiff Software Tato společnost nabízí technologii inteligentních dokumentů (elektronických formulářů) pod názvem LiquidOffice Forms. Hlavním předností produktu je integrace do kvalitního BPM („Business Process Management“ nástroje). Technologická kvalita produktu není taková jako u IBM, Adobe nebo Microsoftu, ale postačí většině konvenčních organizací. Celková kvalita formulářové platformy závisí na tom, jak vhodně splní BPM nástroj požadavky na zpracování procesů v rámci organizace.
2.5.3 Microsoft Infopath Prostředí pro návrh opět vyhoví odborníkovi i školenému uživateli, stejně jako v případě Adobe a IBM. Výhodou technologie je především provázání s dalšími produkty Microsoft - ve fázi vývoje to je podpora ze strany Visual Studio, ve fázi zpracování pak integrace a podpora poštovního klienta Outlook a balíku aplikací Microsoft Office (lze vytvořit formulář z dokumentů aplikací Office). Výhodou je možnost publikovat formuláře v HTML a zpracovávat pomocí prohlížeče, což nevyžaduje instalaci klientské aplikace.
2.5.4 602 XML Předností společnosti 602 na českém trhu je především regionální původ společnosti. Firma disponuje vlastním formulářovým řešením, které už mnohokrát na lokálním trhu implementovala. Řešení však rozhodně nedosahuje světových parametrů. Parametry řešení nevyhovují ani aktuální iniciativě Evropské unie pro zavádění elektronických formulářů do veřejné správy a tady bude muset 602 do technologie dále investovat nebo ji implementovat pouze v nekritických aplikacích. 16
2.6 Použitelnost SAP a formulářů 2.6.1 Použitelnost SAP Otázkou použitelnosti, designu a efektivity práce se v rámci společnosti SAP AG zabývá útvar SAP Design Guild. Základní přehled aktivit uceleně poskytuje webová prezentace právě tohoto útvaru *20+. Se SAP Usability úzce souvisí principy designu a strategie designu SAP do budoucna. Velice stručně a přehledně o tom referuje stránka „SAP’s Visual Design Vision and Mission“ *21+. Na poli designu SAP vyvinul nový obecný design, který bude postupně aplikovat pravděpodobně na všechny produkty, aktuálně lze design posoudit pro nové SAP CRM *22+. Kromě interní práce SAP Design Guild a interních návrhářů je primární aktivitou SAP na poli použitelnosti systému pro uživatele veřejné testování (pro vybrané registrované uchazeče) *23, 24+.
2.6.2 Hlavní problémy použitelnosti SAP Níže uvedený výčet problematických bodů v použitelnosti SAP ERP pochází z rešerší publikovaných na internetu, ze zkušeností několika desítek uživatelů, konzultantů a vývojářů a oficiálních SAP zdrojů, které uvádí, na které problémy se aktuálně zaměřují. Pro účely této práce je důležité, že tyto problémy se do značné míry vztahují k ovládání informačního systému SAP velmi komplexním a složitým uživatelským rozhraním SAP GUI (viz výše v kapitole 2.4.2). Jedná se například o následující problematické oblasti:
Náročná a rozsáhlá nastavitelnost jednoho nástroje namísto vývoje více oddělených a jinak přizpůsobených nástrojů činí obrazovky nepoužitelnými, instalaci a nastavení nástrojů obtížnými: o Pro uživatele je složité najít způsob jak v aplikaci vyřešit svůj problém, o Neexistuje jednoduchý tok práce na obrazovce, o Nadbytečnost velké části ovladačů pro dokončení jednotlivých úloh, nemožnost „skrýt“ tyto ovladače uživateli, o Velký počet ovladačů je častým zdrojem chyb a obtíží pří následném ladění a testování, o Mnoho úkolů v SAP je třeba řešit po částech v různých nástrojích, o A další problémy, Grafické rozhraní a prostředí pro uživatele se řeší až dodatečně (například: EnjoySAP initiative – [25], [26]), Konfrontace uživatele se standardními aplikacemi SAP často vyvolává negativní emoce (což má za následek odmítání uživatele pracovat se systémem).
17
2.6.3 Použitelnost formulářů V předchozím textu autor vyznačil tvrzení, na kterých lze demonstrovat, jak jsou formuláře použitelnější technologií pro vývoj GUI. Tato tvrzení byla:
(T1) Osobní spolupráce s uživatelem při vývoji formulářů má značný pozitivní efekt na identifikaci uživatele s vyvinutým řešením nebo aplikací grafický návrh formulářů lze snadno provádět na papír nebo velmi snadno graficky v návrhové aplikaci, (T2) Jedním z postupů práce pomocí user-centered designu je prototypování, což formuláře velmi dobře umožňují lze snadno tvořit prototypy formulářů, a to i samotným budoucím uživatelem, (T3) Dle požadavků uživatele probíhá nový vývoj pro zlepšení práce uživatele nebo opravy vzhledu a chování se stejným cílem iterativně v souladu s předchozím lze velmi dobře iterativně upravovat prototypy formulářů a vyhovět většině požadavků uživatele díky jednoduchosti a volnosti grafického návrhu (a to i v průběhu produktivního provozu).
Další tvrzení o Usability z odborné literatury, které lze vhodně aplikovat na formuláře:
(T4) Komunikace s objekty (např. s dialogovými informačními systémy) má 2 základní přístupy, které rozdělujeme a posuzujeme na základě: o Předchozích zkušeností, o Očekávání, jak systém bude pracovat při jeho užití [27], velmi dobře se uplatní fakt, že elektronické formuláře svou uživatelskou zkušeností („User experience“) a filosofií mají vycházet tradičních papírových formulářů, což uživateli usnadňuje aplikaci předchozí zkušenosti a do značné míry ovlivňuje jeho očekávání,
(T5) Uživatel je často přehlcován informacemi z obrazovek počítačů nebo dialogových informačních systémů. Může k tomu přispívat i nevhodný design informací prezentovaných na displeji, nejenom například technická kvalita výstupního zařízení [28] volnost grafického návrhu formulářů umožňuje tvořit téměř bezpracně design přímo na míru, (T6) Dialogový informační systém s dobře navrženým uživatelským rozhraním vyžaduje minimální přípravu uživatele k využívání [29] jednoduchost design formulářových aplikací je předurčuje k plnění nárazových úloh bez speciálního školení, instrukce lze popsat snadno při zadání úloh nebo připojit textové vysvětlivky do designu elektronického formuláře stejně jako se to dělá u papírových formulářů, (T7) Uživatelé při zpracováni nelineárních aplikací (například webové stránky, zanořující se detaily v aplikaci apod.) často ztrácejí přehled, souvislosti, zapomínají, jaké úkoly vlastně chtěli sledovat [30] lineární charakter formuláře podporuje zpracování dané problematiky přehledně, chronologicky, proces zpracování lze to podpořit kontrolou přístupu do políček (read-only atd.) nebo zvýrazňováním (tj. že v první kroku jsou odemčeny pro změnu pouze pole relevantní pro tento krok, pro druhý krok stejně atd.)
Lze také dohledat množství informací o ladění Usability webových stránek nebo formulářů. Často se jedná o kombinaci - webové formuláře, protože samostatné elektronické formuláře nejsou dosud běžnou praxí. Rady týkající se návrhu webových formulářů [31] lze však vhodně aplikovat i pro samostatné elektronické formuláře.
18
2.7 Pořizování dat do SAP pomocí Adobe Forms Technologie Adobe Forms je příkladem inovativního typu uživatelského rozhraní, jejichž zapojení do informačního systému může pomoci zlepšit efektivitu pořizování dat do IS zejména u některých skupin uživatelů. Elektronické formuláře zastupují další inovativní technologie pro vývoj uživatelských rozhraní do IS, jejichž využití autor navrhuje pro zlepšování Usability informačního systému pro uživatele. Detailní analýza formulářů slouží jako demonstrace toho, nakolik se inovativní rozhraní může lišit od rozhraní běžně používaných – co nového rozhraní umožňuje a jaké poskytuje příležitosti pro uživatele. Na následujícím obrázku je uveden příklad elektronického formuláře, který vznikl podle konkrétní šablony, aktuálních číselníků, pravidel firemního designu, zabezpečení, požadavků na data apod. Obrázek č. 5: Formulář pro schválení podnikového projektu
Popis práce s formulářem pro schválení projektu: Konkrétní uživatelé si formulář mohou dle aktuální potřeby vzájemně předávat jako soubor PDF (emailem, na flash disku atd.), K použití formuláře opravňuje uživatele „vlastnictví formuláře“ a případně schopnost prokázat se platným elektronickým podpisem nebo certifikátem, K použití formuláře stačí mít nainstalován Adobe Reader (Adobe udává pokrytí přes 90% všech celosvětově používaných počítačů – ideálně tedy tzv. „Zero client Installation“), prohlížeč je zdarma, Vyplněná data lze zabezpečovat elektronickým podpisem a certifikáty, tímto způsobem lze plně nahradit podepisování papírového dokumentu (vzhled elektronického podpisu může imitovat skutečný podpis, tj. výsledný dokument může být analogií podepsaného papíru, ale proces podepisování je plně elektronizován), 19
2.7.1 Přínosy technologie e-formulářů pro běžného uživatele
Jednoduché a intuitivní ovládání formuláře, Formulář může vést uživatele při vyplňování, na základě částečného vstupu doplňovat části dat, kontrolovat tvar a správnost zpracovávaných dat, Návrh i vzhled formuláře pracují s jednoduchými pojmy a objekty (text, pole k vyplnění, tlačítko) Formuláře se navrhují intuitivním vizuálním nástrojem, Ve fázi designu i zpracování vypadá formulář stejně, formulář vypadá stejně na obrazovce i při tisku, Formuláře mohou být snadno průběžně před-vyplňovány daty v kontextu zpracování, Formulář fyzicky existuje jako běžný soubor typu PDF, data jsou součástí PDF souboru, přičemž data lze oddělit ve formě XML souboru.
2.7.2 Porovnání e-formulářů a webových stránek Technologie elektronických formulářů není doposud široce rozšířená. Její přínos a použitelnost demonstruje autor diplomové práce srovnáním s jedním z nejrozšířenějších uživatelských rozhraní pomocí webových formulářů. Poznámka: Uvedené argumenty pro e-formulář se vztahují k platformě Adobe Interactive Forms a nemusí být univerzálně platné pro všechny formulářové aplikace od konkurenčních výrobců. Tabulka č. 5: Porovnání vlastností elektronických formulářů a webové aplikace (webových formulářů) z hlediska použití uživatelem. e-formulář
Webový formulář
Instance
Pro uživatele je důležité, že formulář fyzicky existuje jako PDF soubor obsahující data. Existuje něco hmatatelného v daný okamžik.
Uživatel vyplňuje data, která se zpracují bez toho, že by uživatel něco hmatatelného získal. Z hlediska člověka laika neexistuje žádný záznam, že se něco stalo.
Vzhled formuláře
Formulář může obsahovat pokročilé grafické prvky i jejich formátování díky grafické části portfolia Adobe.
Formulář je limitován formátováním XHTML/ CSS nebo vyžaduje použití jiných složitějších technologií.
Samostatnost
S formulářem lze pracovat bez připojení k IS, protože existuje jako PDF soubor, který si ukládá data.
Webový formulář nelze použít bez napojení na konkrétní informační systém a napojení na nějaký RDBMS.
Tisk výsledku
Formuláře jsou stejné na obrazovce i při tisku. Jsou přirozeně tisknutelné.
Webový formulář je potřeba pro tisk přepracovat do vhodnější podoby.
Elektronický podpis
Je přirozeně podporován. Je co podepsat (aktuální stav formuláře).
Použití je problematické, není co podepsat.
Intuitivnost
e-formuláře se úmyslně vizuálně navrhují tak, aby se s nimi dalo pracovat stejně jako s papírovými formuláři. Mají zcela samostatně význam výsledného „papíru“.
Webový formulář je typicky součástí nějakého systému, bez kterého nemůže pracovat. Orientace v systému může být pro uživatele problém. Web formulář samostatně nemá žádný význam.
Spolupráce
Uživatelé mohou spolupracovat na vyplňování jedné instance formuláře. Analogie zpracování papíru.
Pro každého uživatele zapojeného do vyplňování se tvoří nový formulář nebo jeho varianta.
20
2.7.3 Důležité pojmy a různé typy formulářů Následující přehled vymezuje vybrané důležité pojmy, které jsou důležité pro pochopení možností Adobe formulářů, a tato práce s nimi dále pracuje. Interaktivní/ ne-interaktivní (tiskový) formulář – Tato vlastnost formuláře určuje, jakým způsobem je možno formulář využít. Jestliže je formulář interaktivní, je možné, aby ho uživatel vyplňoval v aplikaci Reader a uložil vyplněná data (což běžně není možné). Jestliže formulář není interaktivní, jedná se o formulář, který je ekvivalentem elektronického papíru (proto také označení tiskový). V této variantě použití slouží formulář pouze ke zveřejnění informací. Formulář může být následně vytištěn nebo odeslán obchodnímu partnerovi jako elektronická faktura (nebo podobný typ dokladu). Vlastnost „být interaktivní“ je předmětem licence Adobe/ SAP. Tuto vlastnost vývojář explicitně nastavuje při tvorbě formuláře v systému SAP. Pro pořizování dat, kterým se zabývá tato diplomová práce, má význam pouze interaktivní formulář. Zmínky o tiskovém formuláři v této práci autor používá pro zjednodušení technicky náročných pasáž. Tiskový formulář obsahuje ve zjednodušené podobě stejné komponenty jako formulář určený pro zpracování uživatelem. Dynamický/ statický formulář – Jestliže je formulář dynamický, může se dynamicky měnit jeho vzhled. Dynamičnost formuláře nesouvisí s jeho interaktivitou. Formulář může být zároveň neinteraktivní a dynamický, takový formulář slouží jako tisková sestava a jeho vzhled se mění dynamicky podle informací, které jsou do něj vyplněny. Statický formulář nemůže měnit svůj vzhled na základě skriptované funkčnosti. V případě, že je formulář statický, nelze například přidávat a odebírat elementy formuláře (řádky tabulky, podmínečné zobrazování atd.). Statičnost formuláře do značné míry omezuje jeho použití pro uživatele. Ve statickém formuláři nelze využít výhod, které technologie Adobe nabízí, aby usnadnila uživateli vyplňování formuláře. Proto z hlediska pořizování dat má smysl hovořit spíše jen o dynamickém formuláři. Online/ Offline zpracování – Nejedná se přímo o vlastnost formuláře, ale o způsob, jak je formulář vytvořen a jak bude používán uživatelem. Online formulář je přímým ekvivalentem webové aplikace, formulář zde slouží především pro účely formátování vzhledu „obrazovky“ a ostatní funkce a možnosti formuláře navíc oproti webové aplikaci jsou potlačeny. Formulář při zpracování uživatelem stále komunikuje s databází SAP a uživatel je neustále přihlášen (opět přímá analogie webové aplikace). Při offline zpracování formulář vzniká v systému SAP, je předán uživateli k použití a formulář dále nekomunikuje se systémem SAP, dokud to uživatel nevyžaduje. Formulář spolupracuje se SAP systémem, jestliže je formulář předán ke zpětnému zpracování (vytěžení a uložení dat) nebo součástí chování formuláře je komunikace s externí webovou službou (pro odeslání nebo přijetí dat). Při offline zpracování se využívá vlastnosti, že formulář umí pracovat mimo kontakt s databází SAP, drží vyplněná data v rámci PDF souboru a uživatel se při zpracování formuláře nemusí přihlašovat. Ke zpracování formuláře uživatele opravňuje jeho prosté vlastnictví nebo lze uživatele ověřit například pomocí elektronického podpisu. Formulář pro online zpracování nemůže fungovat zcela samostatně, musí být integrován do nějaké (webové) aplikace, která se stará o řízení zpracování. V případě Adobe formulářů v SAP se jedná o WebDynpro nebo BSP webovou aplikaci. WebDynpro/ BSP formulářová aplikace – online formulářová aplikace, která nemůže pracovat samostatně, formulář musí být integrován do konvenční SAP webové aplikace. Integrace je možná do starší aplikace BSP (Business Server Pages) nebo novější WebDynpro aplikace. Novější technologii WebDynpro lze využít ve variantách pro jazyky Java a ABAP (proprietární jazyk společnosti SAP). 21
2.7.4 Integrace Adobe elektronických formulářů do SAP Přehled všech podstatných technologických, logických a dalších informací o integraci technologií Adobe a SAP přináší následující tabulka. Jedná se o stručný popis všech důležitých pojmů, které jsou dále vysvětleny podrobněji, budou-li tyto pojmy zásadní pro pochopení tématu diplomové práce. Následující výčet je adaptován z oficiální stránky SAP [32] a Saramago [33]. Tabulka č. 6: Souhrn faktů o integraci technologie Adobe Forms do systémů na bázi SAP Softwarové komponenty na serveru Softwarové komponenty na klientu
Uložení formulářů
Základní informace o licenci
Minimální požadavky na jádro SAP systému
SAP Web AS 6.40 Java/ ABAP Adobe Document Services – komponenta pro generování formulářů (skupina webových služeb Adobe) Adobe Credential – komponenta umožňující používat interaktivní formuláře LiveCycle Designer - vizuální nástroj pro tvorbu formulářů. Tento nástroj je integrován do nástrojů vývoje pro SAP. Pro objekty ABAP je to integrace do ABAP Workbench a pro objekty Java je to integrace NetWeaver Developer Studio (editor Eclipse pro SAP). SAP NetWeaver Developer Studio (spolupracuje s LC Designérem, viz výše) - pro tvorbu Java objektů formuláře v SAP SAP GUI 6.40 (grafický klient pro SAP) s nainstalovaným LC Designerem (lépe verze 7.10, obsahuje také novější LC Designér). Active Component Framework – umožňující vyplňovat interaktivní formuláře ve webových aplikacích WebDynpro Adobe Reader 6.0.2 (nebo novější) – prohlížeč PDF formulářů na klientské stanici, k použití zdarma ABAP objekt: Šablona formuláře a další nutné zdroje (především grafické prvky atd.) se ukládají do SAP databáze (jako při běžném ABAP programovém vývoji) Java objekt: Objekty se ukládají do DTR (Design Time Repository). Při běhu formulářového scénáře jsou objekty (šablona a nutné zdroje pro její zpracování) získány z databáze a komponenta ADS renderuje formulář spolu s předanými daty do fyzického formuláře, který obdrží uživatel (prohlížeč ho předá do Adobe Reader k zobrazení). Zpracování vyplněného formuláře při nahrání zpět do systému: komponenta ADS oddělí XML data od XML schránky formuláře. Využití formulářů pro tiskové scénáře není licencováno nad rámec licence ERP. Licence je potřebná navíc pro scénáře s interaktivními formuláři. Licence je nutná pouze pro produktivní provoz formulářů (tj. jsou využívány uživateli produktivního systému SAP ERP). SAP NetWeaver ’04 - WebDynpro Java (interaktivní scénář, vývoj v jazyce Java pro WebDynpro technologii), ABAP Workbench (tisk, vývoj v jazyce ABAP) - SAP NetWeaver ‘04 SAP ERP ECC 5.0 - Internet Service Request (online workflow procesy s formuláři ve WebDynpro aplikacích) SAP NetWeaver 7.0 - Guided Procedures (offline workflow procesy s formuláři), WebDynpro ABAP (interaktivní scénář WebDynpro v jazyce ABAP)
22
2.7.5 Licenční modely Adobe PDF Forms Následující přehled ilustruje licenční politiku Adobe formulářů v SAP. Ceny licencí za použití formulářů jsou výrazně nižší, než kdyby uživatelé využívali profesionální licenci pro přístup přímo do SAP ERP. Na základě tohoto rozdílu lze využít Adobe formuláře pro licenční optimalizaci u těch uživatelů, kteří využijí pouze zlomek funkčností SAP systému. Následující informace o licencích uvádí například Gopal [34].
SAP/ Adobe formuláře dle aplikace
Neinteraktivní formuláře (tiskové) – licence zdarma, resp. je součástí licence za používání ERP,
Standardní interaktivní formuláře SAP – zdarma, jestliže jsou používány ve standardní podobě (v podobě dodané SAP) nebo používány jen po kosmetickou modifikaci (přizpůsobení vizuálnímu manuálu firmy atd., nemění se funkčnost a logika formuláře),
Zákaznické (vyvinuté) nebo radikálně modifikované standardní formuláře – licenčně zpoplatněno, dle počtu uživatelů a počtu formulářů (výklad pojmů: Zákaznická modifikace – úprava standardní šablony formuláře standardu SAP tak, že se mění logika připojení formuláře k aplikacím, dochází k rozšíření nebo změně logiky použití; Zákaznický formulář – vytvoření zcela nového formuláře dle libovolných potřeb zákazníka).
Úrovně licence SAP/ Adobe
Starter Kit - Opravňuje k vytvoření až 5 interaktivních formulářů, které budou využívat všichni uživatelé bez omezení. Tyto formuláře mohou být jednak zcela zákaznické nebo dodávané interaktivní formuláře standardu SAP. Stejný formulář ve více jazykových verzích se započítává pouze jednou. Tato varianta licence může být zakoupena každým zákazníkem pouze jednou. Cena pro „Starter Kit” je 45,000 EUR.
Enable the Enterprise - Opravňuje k vývoji až 20 zákaznických formulářů a modifikace VŠECH SAP předpřipravených formulářů. Pro tuto licenci není prerekvizitou zakoupit Starter Kit. Cena pro “Interactive Forms based on Adobe – Enable the Enterprise” je 30 EUR per SAP Named User.
Additional Forms Bundles - Vývoj dalších 20 zákaznických formulářů. Cena je 10 EUR per SAP Named User. Vyžaduje licenci “Interactive Forms based on Adobe – Enable the Enterprise” (předchozí položka).
23
3 Praktická část V této části diplomové práce autor nejdříve analyzuje příčiny a důsledky přetrvávajících bariér při pořizování dat do IS a následně navrhuje a rozpracovává metodiku, pomocí které lze: (a) Provést hodnocení efektivity pořizování dat pro jeden i více konkrétních informačních systémů, (b) Změřit efektivitu případných opatření, které by měly vést ke „zlepšení“ způsobu pořizování dat do těchto systémů, (c) Vyhodnotit i případné finanční dopady a přínosy těchto změn. Aplikování metodiky pro měření efektivity při pořizování dat do IS v praxi pak autor demonstruje na několika konkrétních IS, se kterými měl možnost se blíže seznámit. Autor se při zpracování této práce nechal volně inspirovat metodikou FMEA (odborné zdroje například [34], [35], [36]).
3.1 Analýza příčin V praxi existuje řada bariér, které uživatelům znesnadňují pořizování dat do IS. Mezi ty nejčastější patří:
(P1) Chybí prostředky na licence pro uživatele,
(P2) Pracoviště nejsou vybavena potřebnou technikou pro práci s IS,
(P3) Není dostatečně upravena pracovní náplň uživatelů pro práci s IS, v práci vzniká časová tíseň, nebo jiné okolnosti, které nedovolují zaměstnancům správně pracovat s IS,
(P4) Systém neurychluje a nezjednodušuje práci uživatelů, úsilí věnované práci s IS není adekvátní přínosu, který uživatelé od IS získají zpět,
(P5) Zaměstnanci nejsou na práci s IS odborně připraveni,
(P6) Uživatelé mohou mít osobní bariéry v používání počítačové techniky.
Důsledky těchto bariér jsou mimo jiné následující:
(D1) Zpracování celé řady důležitých podnikových procesů je iniciováno mimo informační systém, data a informace o průběhu procesů se promítají do IS se zpožděním, mnohdy v neúplné nebo dokonce chybné podobě,
(D2) Dochází ke ztrátě validity předávaných dat a informací,
(D3) Zbytečné prodlužování délky realizace podnikových procesů,
(D4) Přetrvává vysoký podíl ručního zpracování (přepisování) dat, potřeba dodatečných kontrol ve snaze eliminovat chyby vzniklé ručním pořizováním dat do IS,
(D5) Velké množství důležitých dat a informací je zpracováváno zcela mimo IS (elektronická pošta, telefon, kancelářské programy, tištěné dokumenty), mnohdy bez možnosti jakékoliv kontroly a s vysokým bezpečnostním rizikem. Data a informace zpracovávané mimo informační systém pak nemohou být zpřístupněna všem, kteří by je potřebovali. Obrázek č. 6: Schéma zpracování dat mimo IS
24
Schéma ukazuje, jak se část podnikového procesu dostává zcela mimo kontrolu IS. Dochází k tomu i přesto, že data související s procesem lze do IS zapsat. Průběh procesu a data s tím související se nakonec do IS stejně zaznamenají. V označeném úseku vzniká riziko, že data, zapsaná do IS, mohou být neaktuální vzhledem ke stavu procesu nebo obsahovat chyby způsobené ručním přepisem. Aktualizace nebo doplnění dat se děje mimo kontrolu IS. Vzniknou dvě verze dat - jedna verze je zapsaná v IS, ale zastaralá a chybná, druhá není zapsaná v IS, ale již je opravená a aktuální. Další konkrétní problémy s pořizováním dat do systému SAP jsou uvedeny v kapitole 2.6.2 Hlavní problémy použitelnosti SAP.
3.2 Využití formulářů pro pořizování dat Po mnoho let existence IS SAP mohl uživatel pro přístup do systému využít jen klient SAP GUI (popsaný v teoretické části v kapitole 2.4.2 Přehled technologií pro tvorbu UI v SAP). S rozvojem internetu přibyla možnost využít pro přístup do systému SAP webové rozhraní (SAP EP portál, kapitola 2.4.2). Teprve v posledních letech si společnost SAP intenzivněji uvědomuje problémy uvedené v předchozí kapitole a jejich vážné důsledky pro efektivitu práce s IS. Proto se do svých řešení snaží integrovat množství nových alternativních technologií pro přípravu uživatelských rozhraní. Charakteristické pro tyto nové technologie je, že poskytují nové možnosti, které dříve neexistovaly. Jsou přizpůsobené odlišným potřebám různých skupin uživatelů a pracovních úloh, jsou jiným způsobem licenčně omezeny a zpravidla kladou i jiné (nižší) požadavky na odbornost uživatele atd. Jednou z těchto moderních a velice progresivních technologií jsou i elektronické Adobe formuláře, které autor diplomové práce navrhuje použít jako jedno z nových rozhraní pro pořizování dat. Argumenty ve prospěch této technologie lze odvozovat od problémů uvedených 3.1 (odkaz na konkrétní příčinu nebo důsledek argumenty uvozuje), které elektronické formuláře zcela eliminují:
(P1) Licence elektronických formulářů jsou levnější než licence ostatních technologií UI,
(P2) Provoz formulářových aplikací je nenáročný na vybavení pracoviště výpočetní technikou – postačí prohlížeč formulářů (Adobe Reader) a přístup k internetu/ intranetu,
(P4) Formuláře jsou jednoduše ovladatelné a lze je snadno upravovat. Náklady na přípravu prototypové formulářové aplikace jsou minimální. Rovněž náklady na realizaci potřebných změn v již existujících formulářích jsou minimální. Formuláře lze levně a jednoduše přizpůsobit odlišným potřebám,
(P5) Jednoduché ovládání formulářů nevyžaduje proškolení budoucích uživatelů. Formuláře jsou také díky této vlastnosti vhodné pro zpracovávání nahodilých úloh, když si již uživatel nepamatuje, jak úlohu zpracovával minule,
(P6) Vzhled a zpracování elektronických formulářů je velmi blízké zpracování papírových formulářů (uživatelská zkušenost navazuje na očekávání uživatele, jak to uvádí tvrzení č. 4 z kapitoly 2.6.3 teoretické části). Díky této vlastnosti práci s elektronickými formuláři zvládnou i uživatelé s nízkou počítačovou gramotností,
(D1) Formuláře mohou pracovat i mimo IS (a připojení k síti), a mohou tedy být vhodným spojovacím článkem mezi formalizovaným prostředím IS a papírovými doklady. Formuláře lze kvalitně tisknout a distribuovat tj. lze podporovat formulářové procesy i pro uživatele, kteří nemohou nebo nechtějí pracovat s počítačem,
(D2) Dle rychle se měnících požadavků lze levně a rychle upravovat vzhled a chování formulářů tzv. na míru uživatelům,
25
(D3) Nahrání obsahu formuláře do DB, namísto předávání papírového dokumentu a jeho následného ručního přepisování do IS, redukuje čekací lhůty jednotlivých účastníků v procesu. Lhůty již nejsou závislé na předání dat v procesu od člověka k člověku. Proces se zrychluje a doba jeho zpracování může podléhat důslednému řízení,
(D4) Neformálním způsobem lze pomocí formulářů integrovat libovolný podnikový proces s IS, tj. data jsou pořizována v průběhu procesu elektronicky přímo do IS, což odstraňuje potřebu jejich dalšího manuálního zpracování. Pokud je z jakéhokoli důvodu potřeba data zpracovávat i papírově (podepsaný dokument k archivaci apod.), lze takový dokument z IS vytisknout. Data není třeba dodatečně přepisovat mezi kancelářskými dokumenty (nestrukturovaná data) a databází (strukturovaná data),
(D5) Přístup k datům je řízen oprávněním a má k nim přístup kdokoli, kdo je k tomu oprávněn ze svého profilu v informačním systému, zatímco původně bylo potřeba někoho žádat o poskytnutí dat zpracovávaných mimo IS.
3.3 Usability systému Pro potřeby měření efektivity pořizování dat do IS pomocí různých nástrojů a technologií se autor nechal inspirovat zkoumáním pojmu Usability (popsán v teoretické části, v kapitole 2.3.1 Použitelnost - Usability) a na základě této původní Usability nově definuje Usability/použitelnost systému. Autor práce navrhuje při zkoumání Usability systému používat původní metody a pojmy, ale důraz nyní klade na to, že informační systém má:
Více uživatelů - Systém má řádově více uživatelů než je velikost skupiny pro ověřování původní Usability (dle různých studií stačí skupina 6-7 osob). Různí uživatelé vnímají Usability svých aplikací různě – mají jiné požadavky na nástroje IS, které používají ke své práci.
Fixní funkčnost – Organizace získává zaplacením licence určitou standardní funkčnost systému, kterou nelze libovolně a hlavně ne jednoduše měnit dle výsledků Usability testů nebo momentálních požadavků uživatelů. Organizace je nucena maximálně využívat mnohdy i složité nástroje pro přizpůsobení systému, které připravil výrobce. Řešení problému s nízkou standardní Usability systému lze sice řešit přepracováním nevyhovujících částí IS, ale je to velmi neekonomické a popírá to důvod, proč organizace konkrétní IS zavedla.
Více kroků - Procesy v informačním systému zpracovává více uživatelů v různých rolích, s různými potřebami a pracujících v různých aplikacích. Tj. testování původní Usability více menších aplikací je ekvivalentní jednomu testování Usability systému.
Více rozhraní - Při testování původní Usability se obvykle testuje použitelnost aplikace s jedním rozhraním. V informačním systému můžeme zpravidla volit z více alternativních rozhraní pro vybranou funkčnost tj. vybrat takové rozhraní, které nejlépe vyhovuje pro konkrétního uživatele v konkrétní situaci). Správná volba uživatelského rozhraní má výrazný vliv na spokojenost uživatele a tudíž i na výslednou Usability systému
V dalším textu se autor především zabývá fakty, že IS má velké množství různých uživatelů a disponibilních nástrojů resp. rozhraní, jejichž vliv považuje autor diplomové práce za klíčový při zkoumání efektivity pořizování dat do systému.
26
3.4 Popis zkoumaných informačních systému Jedním z cílů diplomové práce je demonstrovat aplikování metodiky pro měření efektivity při pořizování dat na konkrétních příkladech. V následující kapitole je navržen a popsán soubor atributů pro popis systémů.
3.4.1 Definice popisných ukazatelů Autor navrhuje popsat zkoumané systémy pomocí čtyř základních skupin ukazatelů relevantních pro pořizování dat, a to skupinami: Uživatelé (ti, kdo data do IS pořizují), Aplikace a Uživatelská rozhraní (to, co uživatelům umožňuje pořizovat data), Nástroje (to, co umožňuje některé kroky pořizování dat například integrovat a automatizovat), Proces – úlohy (to, co určuje, jaká data se pořizují, kdo data pořizuje a jakým způsobem), V rámci těchto skupin následně autor definuje další atributy IS, které mají bezprostřední vliv na efektivitu pořizování dat do těchto systémů a které dle mínění autora reflektují takové skutečnosti jako velký počet uživatelů, velké množství zpracovávaných a pravidelně se opakujících úloh, existenci řady uživatelských rozhraní, variabilitu podporovaných procesů-úloh apod. Jsou to atributy pro: Popis zaměstnanců a uživatelů v organizaci:
Rozdělení zaměstnanců s podobnými požadavky na IS do skupin, což nám umožní řešit požadavky nikoli na úrovní jednotlivců, ale na úrovni celé skupiny současných i potencionálních uživatelů, Počty zaměstnanců v těchto skupinách, které mimo jiné vypovídají o významu a postavení jednotlivých skupin v organizaci respektive o nákladech, které je potřeba alokovat při úpravách IS pro potřeby dané skupiny, Přístup zaměstnanců v těchto skupinách k IS, jestliže zaměstnanci mají přístup do systému, lze porovnáním jejich počtu s počtem zakoupených licencí usuzovat o tom, jaká část zaměstnanců je skutečnými uživateli IS, Počty zaměstnanců vybavených odpovídající výpočetní technikou pro práci s IS.
Popis systémů, aplikací a rozhraní v systému organizace:
Přehled používaných aplikací a systémů od různých dodavatelů, který vypovídá o případných potřebách integrace těchto nástrojů s cílem minimalizovat rizika a náklady spojené s provozováním systémů různých dodavatelů. Obecně platí, že čím více aplikací a systémů různých dodavatelů organizace používá, tím větší jsou pak režijní náklady na správu této architektury (náklady na ruční přepis dat mezi systémy resp. náklady na výměnu dat mezi těmito systémy, náklady na kontrolu kvality přenášených dat, náklady na školení uživatelů v obsluze různých systémů a aplikací apod.). Druhy a počty uživatelských rozhraní. Některé aplikace a systémy mají pouze jedno uživatelské rozhraní, např. velice rozšířený MS Office. V případě informačních systémů je obvyklé, že se k uloženým datům dá přistupovat přes více různých rozhraní, přičemž každé z těchto rozhraní může více nebo méně vyhovovat různým skupinám uživatelů. Na druhou stranu skutečnost, že rozhraní je pro informační systém k dispozici automaticky neznamená, že ho organizace využívá (může využívat, chce využívat). Často bývá používání dalších uživatelských rozhraní zpoplatněno zvláštní licencí.
27
Informace, jestli se disponibilní uživatelská rozhraní používají či nikoli. Z toho, jaké systémy organizace používá, lze odvodit, jaká uživatelská rozhraní pro daný systém jsou od dodavatele k dispozici. Je ale potřeba rozlišit, že rozhraní existuje a že ho organizace skutečně používá. Rozhraní, která od dodavatele existují, ale organizace je dosud nepoužívá, mohou být ekonomicky výhodná nebo mohou lépe vyhovovat požadavkům některých uživatelům na ovládání IS. Typy a počty zakoupených a skutečně využívaných licencí. Porovnáním těchto údajů s celkovým počtem zaměstnanců například indikuje, do jaké míry je přístup k IS pro jednotlivé skupiny omezen resp. rozšířen.
Popis speciálních nástrojů a aplikací IS umožňujících podporované procesy-úlohy:
Automatizovat (workflow a kombinace manuálního a automatického zpracování), Integrovat tj. například sjednotit správu nebo zpracování úloh v systémech a aplikacích od různých dodavatelů a mnohdy vyvinutých v různých prostředích, Archivovat tj. uchovávat data, informace, dokumentaci o průběhu zpracování jednotlivých úloh v elektronické podobě, Propojit IS kancelářskými aplikacemi.
Popis IS podporovaných procesů: V této části diplomové práce definuje autor atributy umožňující popis takových skutečností jako:
Která část funkcionalit IS je předmětem zkoumání neboli u kterých procesů budeme hodnotit efektivitu pořizování dat do IS, Jaké skupiny uživatelů jsou do výkonu těchto procesů zapojeny, Pomocí jakých uživatelských rozhraní, nástrojů resp. aplikací jsou jednotlivé úlohy zpracovávány.
Atributy popisu procesů:
Míra zpracování procesu v IS – ukazatel, který je zcela zásadní pro Usability systému. Jestliže je proces jednotlivými uživateli zpracováván v IS úplně a automatizovaně, je jeho Usability maximální. Usability procesu klesá, jestliže jsou v IS zpracovávány například pouze některé kroky procesu, jestliže iniciace procesu probíhá mimo IS nebo proces obsahuje velký počet manuálních úkonů uživatele. Aby byla míra zpracování různých procesů mezi sebou porovnatelná, definoval autor škálu pro popis této skutečnosti. Navržená škála pro hodnocení míry zpracování procesu v IS je čtyř-stupňová: A. Elektronická iniciace procesu-úlohy a plně automatizovaný přenos zpracovávaných dat v průběhu celého procesu, B. Manuální iniciace procesu, část činností zpracovávána mimo IS, část činností je automatizována s přímým zápisem do IS, C. Manuální iniciace procesu, převážná většina dat a informací je zpracována mimo IS s následným manuálním přepisem výsledných dat do IS, D. Žádná část procesu není zpracována v IS, data související s procesem nejsou zapisována do IS. Aplikace – slovní popis, v které částí IS nebo kterou jeho aplikací je proces-úloha zpracováván, Rozhraní – slovní popis, přes jaké rozhraní aplikace bude zpracování probíhat, má smysl jen u částí systému, které dovolují přístup přes více rozhraní.
28
3.4.2 Výběr demonstrační problematiky Autorem popsané informační systémy jsou určeny pro oblast personalistiky. Nejenom, že tento obor je autorovi blízký, ale jsou to IS, se kterými měl autor možnost se detailně prakticky seznámit. Klíčovými procesy pro oblast HR jsou (průnik na základě zdrojů [38], [39], [40], [41], [42], [43+ a další): Získávání zaměstnanců – proces od poptávky po zařazení nového zaměstnance do organizace, Vzdělávání a trénink – proces zlepšování pracovního výkonu formou vzdělávání, Hodnocení zaměstnanců – proces hodnocení pracovního výkonu a pracovního chování, Personální administrace – proces zpracování osobních a pracovně-právních dat zaměstnanců, Odměňování – proces přípravy a zpracování mezd včetně zanesení do podnikového účetnictví, Organizační management – proces definice a správy organizační struktury organizace, Time management – proces evidence a zpracování docházky, Personální reporting – proces přípravy podkladů pro manažerské rozhodování v oboru HR. Výše uvedené tzv. personální sub-procesy jsou téměř totožné se standardními funkcionalitami komerčně dostupných personálních informačních systémů včetně SAP. Pro oblast Personalistiky jsou dle autorova názoru relevantní čtyři základní skupiny uživatelů, které mají na personální IS homogenní požadavky. Jak se tyto požadavky liší lze uvést například[37]: Obrázek č. 7: Jedno z možných rozdělení uživatelů IS podle jejich požadavků.
A dále například: potřebná přesnost použití (míra detailu), administrativní charakter použití nebo tvorba nových hodnot, povinnost použití (povinnost nebo benefit) a další charakteristiky práce, které jednotlivé skupiny od sebe výrazně odlišují. Skupiny uživatelů pro personální IS:
Vedoucí zaměstnanci – zaměstnanci, kteří nesou manažerskou odpovědnost za své podřízené, Pracovníci útvaru personalistiky – personalisté - odborníci na výše uvedené procesy Personalistiky, Klíčoví uživatelé personálního IS – personalisté specialisté, kteří mají podstatně hlubší odborné znalosti o personálním IS, než mají jeho řadoví uživatelé, jde zejména o takové znalosti jako: jak systém přizpůsobit a nastavit aktuálním potřebám řadových personalistů, jak vytvořit nové reportingové sestavy, jak funguje přenos dat do jiných systémů apod., Ostatní zaměstnanci – zaměstnanci, kteří nepatří do žádné z výše uvedených skupin. Tato diplomová práce se zabývá především informačním systémem SAP, který disponuje pro zvolenou oblast Personalistiky standardním modulem SAP HR. Zároveň měl autor možnost se seznámit i s dalšími aplikacemi a systémy, které personalisté používaly při své práci. 29
Pro přehlednost je potřeba uvést jaké aplikace (a jejich rozhraní) pro zpracování Personalistiky autor použil při popisu konkrétních systémů. Autor na základě zjištěných faktů a vlastní praxe navrhuje rozlišovat následující uživatelská rozhraní:
Vstup do SAP HR přes SAP GUI (pořízena data se zpracovávají v SAP HR DB), Vstup do SAP HR přes SAP Portál (data se zpracovávají v SAP HR DB), Vstup do SAP HR přes Adobe formuláře (data se zpracovávají v SAP HR DB), Rozhraní SAP aplikace mimo ERP (data jsou pořízena přes uživatelské rozhraní non-SAP aplikace, ale integrační vazbou jsou zapsána do databáze SAP HR), Rozhraní aplikace integrované se SAP (data jsou pořízena přes uživatelské rozhraní non-SAP aplikace zapsána do DB non-SAP systému, ale prostřednictvím integrační vazby systém SAP může data z non-SAP systému získávat dle potřeby), Rozhraní externí aplikace (data se zpracovávají zcela mimo SAP HR DB a přenos dat je možný jen ručním přepisem nebo jednorázovým dávkovým přenosem).
3.4.3 Popis konkrétních systémů Některé informace o systémech nebylo možné získat přesně, protože podléhají obchodnímu tajemství. Ze stejného důvodu není možné přiřadit uvedené systémy konkrétním organizacím. Tabulka č. 7: Popis personálního informačního systému A Skupiny uživatelů
Systémy a rozhraní
Nástroje
Procesy
Název skupiny Vedoucí zaměstnanci Personalisté Z toho klíčoví uživatelé – specialisté pro práci s IS pro HR Ostatní zaměstnanci Název systému SAP ERP SAP ERP SAP ERP Non-SAP systém Určení Automatizace (WF) Integrace (XI) Archivace (RM, DMS) Propojení s kanc. aplikacemi Proces - úlohy Získávání nových zaměstnanců Vzdělávání, trénink Hodnocení a rozvoj Personální administrace Odměňování Organizační management Time management Personální reporting
Počet zaměstnanců 750 15 10
Přístup do IS Ne Ne Ano
5 235 Rozhraní SAP GUI SAP Portál Adobe formuláře Klient non-SAP systému Nástroj --------Míra zpracování v IS C C C C C C C C
Ne Používá se Ano Ne Ne Ano Dostupnost Ne Ne Ne Ne Aplikace Non-SAP sys. Non-SAP sys. Non-SAP sys. Non-SAP sys. SAP ERP Non-SAP sys. Non-SAP sys. MS Excel
Licence 5 ----10
Rozhraní Klient non-SAP Klient non-SAP Klient non-SAP Klient non-SAP SAP GUI Klient non-SAP Klient non-SAP MS Excel
Komentář: Přesto, že se personální procesy týkají všech zaměstnanců společnosti, že potenciál pro zkvalitnění (zrychlení, zjednodušení, zlevnění apod.…) prácí souvisejících s výkonem dílčích personálních činností, zpřístupněním IS všem zaměstnancům společnosti apod. je obrovský, tak ve společnosti A:
30
Skupina Uživatelé: Pouze 10 z 6000 zaměstnanců pracuje s personálním informačním systémem – což indikuje, že: o Organizace má z peněz vynakládaných na IS jen minimální zpětný efekt, prostředky jsou vynakládány neefektivně nebo zcela nevhodně, o Existuje velký prostor pro zapojení dalších skupin zaměstnanců do práce s IS, jejich zapojení by mohlo zvýšit efekt IS na organizaci, vzhledem k aktuálnímu stavu, několikrát, o Při rozšiřování počtu uživatelů IS bude potřeba vydat velký objem finančních prostředků na licence, aktuálně má licenci zcela nedostatečný počet uživatelů vzhledem k celkovému počtu zaměstnanců, o Mzda klíčových uživatelů IS je v důsledku jejich malého počtu nadhodnocena, protože je na nich organizace existenčně závislá, jejich ztráta může ochromit část provozu organizace. Většina zaměstnanců vůbec nepracuje s IS: o Zaměstnanci nemají přehled o tom, jaké informace o nich organizace udržuje a nemohou se podílet na správě (aktualizaci) těchto dat (např. osobní data, záznamy o absolvovaných vzdělávacích akcích atd.), o Zaměstnanci nejsou zapojeni do řešení problémů a procesů, které se jich týkají, nemají přístup k relevantním pokladům pro svou práci. Vedoucí zaměstnanci nepracují s IS: o Management nemá aktuální podklady pro řízení, ve chvíli, kdy dostanou ručně zpracované reporty, jsou tyto již zastaralé, o Management používá data a informace zpracovávána personálním IS zcela výjimečně, protože jejich příprava trvá velmi dlouho a zatěžuje jinou skupinu zaměstnanců. Skupina Aplikace:
Organizace využívá pro oblast personalistiky dva hlavní informační systémy: o Organizace musí platit odborníky na oba systémy, což zvyšuje její mzdové náklady, o Nikdo ze zaměstnanců nemá odbornost zároveň pro oba systémy, proto systémy v podstatě nespolupracují a není nikdo, kdo by identifikoval způsoby spolupráce pro procesy procházející napříč oběma systémy, o Lze předpokládat, že organizace bude do budoucna usilovat o začlenění jednoho systému do druhého, protože se jedná o podmnožinu funkčností většího systému, o Náklady na techniku, školení i v dalších oblastech se provozem dvou systémů zdvojnásobují. Systémy nejsou nijak integrovány: o Ruční přepis dat mezi systémy je zdrojem chyb a prodlení, o Systémy jsou „úzkými hrdly“ při realizaci personálních sub-procesů (proces v jednom systému potřebuje mít partnera v druhém systému apod. Skupina Nástroje: Organizace nevyužívá žádné automatizační nástroje: o Pokud by organizace chtěla výkon některých činností automatizovat, týkalo by se to jen velmi malého počtu uživatelů, efekt automatizace by byl zanedbatelný. Procesy: Všechny personální činnosti jsou realizovány mimo IS a teprve jejich výsledky (s výjimkou zpracování mezd) jsou zapisovány do IS manuálně: o Tento fakt je pravděpodobně způsoben nedostupností IS, okamžité zlepšení by bylo možno očekávat zvýšením počtu zaměstnanců pracujících v IS, o Neexistuje centrální přístup k datům, libovolný oprávněný uživatel nemůže získat potřebná data, protože nebyla do IS zapsána, resp. autor dat nemá do IS přístup, o Data zapsaná do IS slouží spíše jako archiv než jako databáze provozních dat organizace než se data dostanou do IS, jsou mnohdy již zastaralá,
31
Tabulka č. 8: Popis personálního informačního systému B Skupiny uživatelů
Systémy a rozhraní
Nástroje
Procesy
Název skupiny Vedoucí zaměstnanci Personalisté Z toho klíčoví uživatelé – specialisté pro práci s IS pro HR Ostatní zaměstnanci Název aplikace/ systému SAP ERP SAP ERP SAP ERP Externí HR aplikace (nábor) Určení Automatizace (WF) Integrace (XI) Archivace (RM, DMS) Propojení s kanc. aplikacemi Proces - úlohy Získávání nových zaměstnanců Vzdělávání, trénink Hodnocení a rozvoj Personální administrace Zpracování mezd Organizační management Time management Personální reporting
Počet zaměstnanců 46 14 2
Přístup do IS Ano Ano Ano
504 Rozhraní SAP GUI SAP Portál Adobe formuláře Webové rozhraní Nástroj SAP Workflow ------Míra zpracování v IS C B C A C C B A
Ano Používá se Ano Ano Ne Ano Dostupnost Ano Ne Ne Ne Aplikace Externí ap. SAP ERP MS Word SAP ERP SAP ERP SAP ERP SAP ERP SAP ERP
Licence 60 500 --Ano, dostatek
Rozhraní Webové r. SAP Portál MS Word SAP Portál SAP GUI SAP Portál SAP GUI SAP Portál
Komentář: Skupina Uživatelé
Všechny skupiny zaměstnanců pracují s IS – ukazatel indikuje, že: o Personální IS je velmi dobře začleněn do denních pracovních úloh většiny zaměstnanců, o Lze předpokládat, že nemalý počet procesů bude částečně nebo plně elektronizován, o Organizace má velký rozpočet na IT a vynaložila nemalé prostředky na nákup licencí IS, o Větší počet skupin uživatelů než počet rozhraní může znamenat, že ne všechny skupiny uživatelů jsou optimálně podporovány v systému organizace Skupina Aplikace
Organizace používá SAP Portál – tato informace indikuje, že: o Organizace průběžně kultivuje personální IS pro potřeby různých uživatelů, o Lze předpokládat, že organizace bude dále kultivovat systém větším počtem rozhraní, o Část uživatelů vyřizuje své požadavky na IS přímo, aniž by zatěžovala odborné uživatele, což má pozitivní vliv na výkonnost odborníků v jiných oblastech jejich práce. Organizace používá externí HR aplikaci, která není integrována s hlavním IS – to indikuje, že: o Uživatelé se mohou vyhýbat přenosu dat mezi oběma systémy (aby šetřili čas a práci), o Organizace přichází o příležitosti plynoucí z výměny dat mezi externí HR aplikací a interním personálním IS, o Je možné, že s oběma systémy pracují různé skupiny uživatelů, což může mít za následek zpoždění procesů probíhajících mezi těmito systémy, o Přenos dat mezi systémy zatěžuje uživatele manuální prací, odvádí je od jiné práce, představuje riziko zavlečení chyb a zpomaluje procesy.
32
Skupina Nástroje
Organizace automatizuje procesy Workflow – spolu s počtem zaměstnanců pracujícím v IS tato informace indikuje, že výkon části personálních procesů organizace je automatizován – procesy pracují rychleji, s minimální mírou ruční práce. Organizace neintegruje různé aplikace – problémy jsou již popsány v předchozím odstavci aplikace, Organizace používá neintegrovaný externí systém Organizace nepoužívá sofistikovanější archivační nástroje – ukazatel indikuje, že když organizace potřebuje archivovat data, dělá to jejich tiskem a zařazením do osobního spisu zaměstnanců. Organizace nevyužívá propojení IS s kancelářskými aplikacemi – ukazatel indikuje, že výměna dat mezi kancelářskými aplikacemi (především MS Excel nebo podobné) a hlavním informačním systémem se děje zejména manuálním exportem dat, což způsobuje: o že výkon personálních procesů se zbytečně prodlužuje, o Že mohou vznikat chyby způsobené ručním přepisem, o Že určitou část pracovní doby vybraní uživatele tráví činností bez přidané hodnoty. Skupina Proces - úlohy
Proces získávání nových zaměstnanců se provádí v externí aplikaci bez integrace – způsob realizace neumožňuje efektivně zpracovat danou problematiku, protože vstupy se pořizují v externím systému, zatímco výsledky procesu – přijatí zaměstnanci se pořizují do hlavního systému, Proces hodnocení a rozvoje se provádí mimo IS a pouze výsledky procesu se zapisují do IS způsob realizace přináší zaměstnancům velké množství manuální práce, a to nejenom při přenosu ručně pořízených dat do IS, ale zejména při následném zpracování stovek výsledků individuálního hodnocení. Tento personální proces je velkou příležitostí pro rozvoj systému do budoucna, Personální administrace a reporting jsou plně automatizovány a kdykoli k dispozici – způsob realizace procesů minimalizuje náklady na manuální práci a zrychluje odezvu organizace na problémy a příležitosti
3.4.4 Zobecnění popisu systému Navržený postup popisu obou zkoumaných personálních systémů a jejich jednotlivé atributy (ukazatele) jsou volně rozšiřitelné, lze je upravovat a zpřesňovat dle potřeby následujícími směry:
Horizontální zobecnění - Autor si zvolil příklad pro oblast Personalistiky. Navrženým způsobem lze ale popsat IS i pro jiné oblasti, například pro proces Obchodu a logistiky by skupina procesy obsahovala položky jako Nákup, Prodej, Manipulace skladu (výdej, příjem), Oceňování skladových zásob a další. Vertikální zobecnění – Navrženou metodu popisu systému lze použít pro vyšší i nižší úroveň detailu. Analogicky by se postupovalo na vyšší úrovni, než jsou procesy Personalistiky nebo Obchodu, tj. na úrovni celé organizace. Pak ve skupině procesy by se zadaly hlavní procesy celé organizace, což mohou být právě procesy Personalistika, Obchod, Výroba, Správa majetku, Finanční účetnictví a další podle charakteru činnosti organizace. Podle procesů by se pak změnily i skupiny uživatelů a aplikace. Například by přibyly specifické skupiny uživatelů jako „Zákazníci“, „Zaměstnanci ve výrobě“ „Obchodníci“ apod. Museli bychom také upravit množinu sledovaných aplikací a rozhraní. Některé aplikace a rozhraní, které umožňovaly zpracovávat úlohy z personální oblasti, by byly nahrazeny aplikacemi a jim odpovídajícími rozhraním, které umožňují zpracovat úlohy pro oblast obchodu, výroby apod. (CRM). Analogicky by se prováděl popis systému o úroveň níže – tj. zvolila by se užší (detailnější) oblast zkoumání. Přizpůsobily by se skupiny uživatelů relevantní pro zkoumaný detail a nástroje použitelné v konkrétním detailu.
33
3.5 Definování modelu pro měření Usability systému Jak již bylo uvedeno v úvodu diplomové práce, jsou z pohledu efektivity pořizování dat do IS zcela stěžejní uživatelé. Ze stejné myšlenky vychází disciplíny, které zkoumají metody návrhu IS. Sebelepší IS, bez akceptace ze strany uživatelů, má pro organizaci minimální přínos. To je důvod, pokud finanční prostředky související s pořízením IS nemají být znehodnoceny, abychom vynaložili maximální úsilí, buď již při samotné implementaci IS, nebo alespoň při jeho dalším rozvoji, na přizpůsobení uživatelských rozhraní všem budoucím uživatelům (aby si IS své uživatele získal nebo je alespoň neodradil). Z popisů IS, se kterými měl autor diplomové práce možnost se podrobně oznámit (viz předchozí kapitola 3.4.3 Popis konkrétních systémů) už známe skupiny uživatelů, které jsou pro oblast personalistiky relevantní, jaké jsou jejich požadavky na IS resp. uživatelská rozhraní a jaké jsou současné technologické možnosti personálních IS na bázi SAP. V této kapitole autor představí model, pomocí kterého lze zhodnotit (změřit), jak dobře se uživatelům v informačním systému pracuje. Model navržený autorem diplomové práce, je založen na myšlence, že použitelnost (Usability) systému pro uživatele je ekvivalentní tomu, jak je IS prostřednictvím používaných uživatelských rozhraní schopen při pořizování dat uspokojit požadavky uživatelů. Mezi objekty uživatelé a uživatelská rozhraní existuje řada možných vazeb. Každé rozhraní do jisté míry splňuje požadavky uživatelů, některá rozhraní však požadavky splňují lépe, jiná hůře. Tedy některá z možných vazeb mezi uživateli a uživatelským rozhraním je kvalitnější, vhodnější a měla by být v systému významnější a naopak. Podstatou navržené metody měření Usability systému je, zhodnotit informační systém pomocí sady hodnotících kritérií, které jsou popsány v následujících kapitolách, a následně hledat mezi objekty modelu ty vazby, které vykazují nejvyšší míru splnění požadavků (uživatelů na systém). Obrázek č. 8: Schéma párování prvků z modelu technologií UI (nahoře) a modelu skupin uživatelů (dole). Aplikace A2 a Skupina uživatelů S1 tvoří pár. Například aplikace A2 uspokojuje požadavky uživatelů ze skupiny S1 určitou měrou. Pro aplikaci A1 nemá IS organizace dosud využití. Skupina S4 dosud nepracuje s IS apod.
34
3.5.1 Návrh kritérií pro hodnocení Usability systému při pořizování dat do IS Obecně platí, že hodnocení lze provést správně tehdy, když se různí hodnotitelé shodnou nejen na tom, co má být předmětem hodnocení, ale také jakým způsobem bude hodnocení provedeno. Autor si v rámci této diplomové práci rovněž vytkl za cíl, nejenom definovat sadu hodnotících kritérií pro stanovení usability systému při pořizování dat do IS, ale současně demonstrovat jejich použití v praxi. Výhodu navrženého přístupu autor práce vidí v tom, že změnou množiny kritérií a případně úpravou stupnic lze přizpůsobovat hodnocení různým účelům a různým hodnotitelům.
Počítačová gramotnost
Odbornost v IT – vyjadřuje, jaké požadavky na uživatele klade konkrétní technologie UI. Pro práci s elektronickým formulářem není třeba být odborně vybaven. Zatímco při práci s klientem SAP GUI a aplikacemi, ke kterým klient poskytuje uživateli přístup, je třeba mít nemalou uživatelskou zkušenost. Při práci se SAP GUI je třeba chápat, jaké objekty v systému existují a jak se zpracovávají, oproti tomu ve formuláři stačí vyplnit vhodně označená pole formuláře.
Školení – vyjadřuje, jak složité a finančně náročné je pro uživatele naučit se pracovat s aplikacemi v konkrétním uživatelském rozhraní. U vhodně navrženého formuláře postačuje zpravidla vyplnění několika málo hodnot na jedné obrazovce s následným odesláním do IS ke zpracování. Při práci se SAP ERP přes SAP GUI je naopak potřeba pracovat s informacemi z více obrazovek, vracet se v procesu zpracování, volit správnou cestu mezi mnoha možnostmi pokračování, aby uživatel dokončil zadaný úkol. Formulář nevyžaduje, ale také ani neumožňuje zpracovat jiná data, než jsou obsahem formuláře.
Kvalita nápovědy pro práci s IS – vyjadřuje potřebu nápovědy pro řešení situací i to, jak je technologie vhodná pro sdělování nápovědy. Ve formuláři je vhodné psát jednoduché instrukce pro vyplňování tak, jak by byly uvedeny v papírové podobě formuláře (př. Na poštovní poukázce). Při práci v SAP GUI lze s nápovědou pracovat několika způsoby, hledat přidružená témata, volit na základě nápovědy jiné pracovní postupy atd.
Finance
Licence – vyjadřuje průměrné (odhadované) náklady na licenci umožňující použití nástrojů připravených od výrobce pro tuto technologii UI. Plná licence pro práci přímo v SAP ERP přes SAP GUI umožňuje uživateli zpracovat stonásobně větší objem problematiky (v praxi ale jeden uživatel z tohoto objemu využije prakticky jen malou část) než licence pro práci v SAP portál (webové rozhraní). Licence je však podstatně levnější. Stejný posun následuje od SAP portálu k formulářům – opět nižší licenční náklady za méně funkcionality. Náklady na přizpůsobení IS pro pořizování dat – vyjadřuje průměrné (odhadované) náklady na netriviální úpravy aplikací (ryze individuálního charakteru dle přání konkrétní organizace), především opravy logiky a vzhledu, které nelze realizovat nastavením (parametrizací, customizací) standardních aplikací Náklady na vývoj – vyjadřuje průměrné (odhadované) náklady na vývoj aplikace pro konkrétní rozhraní. Vývoj pro různá rozhraní vyžaduje, aby tým vývojářů byl jinak velký a používal zcela jiné kompetence. Pro komplexní aplikace v SAP ERP lze předpokládat potřebu většího týmu s převažující kompetencí „ABAP vývojářů, která je ve světě SAP standardem, na rozdíl od toho vývoj e-formulářů může provádět i jeden vývojář s klíčovou kompetencí „příprava formulářů v LiveCycle Designéru“, která naopak není zcela běžná. 35
Rutinní provoz
Automatizace při pořizování dat – měří, jestli technologie umožňuje nějakými mechanismy automatizovat běžné úlohy, například před-nastavením prostředí, před-vyplněním defaultními hodnotami atd. Některé skupiny uživatelů provádějí denně desítky podobných úloh a nástroj automatizace, který by čas zpracování těchto rutinních úloh alespoň částečně zkrátil, by při hromadném nasazení pro mnoho uživatelů mohl znamenat výraznou časovou (a tedy i finanční) úsporu a rozhodně by měl vliv i na vnímání práce uživateli (že software jejich práci skutečně usnadňuje a tím jim pomáhá). Frekvence pořizování dat – vyjadřuje, pro jak časté resp. pravidelné používání je rozhraní vhodné neboli zda při jeho používání dochází k častému a pravidelnému osvěžování si znalostí práce s IS nebo naopak, zda technologie UI je vhodná pro zpracování nárazových úloh opakujících se po delší přestávce. Dle potřeb uživatele, charakteru jeho práce a dostupného uživatelského rozhraní se mění pravidelnost použití aplikací. Například ovládání SAP ERP přes SAP GUI slouží pro zpracování každodenních úloh, a toto denní opakování umožňuje uživateli opakovat si automatismy při ovládání tohoto složitého prostředí. Oproti tomu jednoduchost elektronického formuláře ocení uživatel při zpracování jednorázových zřídka opakovaných úloh (žádost o dovolenku atd.). Jednoduchost formuláře umožňuje vést uživatele při práci krok za krokem bez nutnosti potřebných návyků na straně uživatele. Objem pořizovaných dat – různí uživatelé, podle své pracovní náplně, pořizují různý objem dat – specialisté na práci s informačním systémem a klíčoví uživatelé pořizují velké objemy dat a potřebují to provádět velmi efektivně, aby je velký objem příliš časově neomezoval. Běžní uživatelé, kteří s IS nepracují denně nebo pouze v omezeném rozsahu, naopak pořizují jen zlomek objemu dat specialistů. Počet nutných ovládacích prvků (na obrazovce) pro pořizování dat – z použité technologie lze odvodit průměrný počet ovladačů (tlačítek, výběrů, záložek, tabulek, seznamů) v aplikaci. Odbornost uživatele a mnoho dalších faktorů včetně osobních určuje, jaký počet ovladačů je uživatel schopen a ochoten používat a jaký počet už je naopak matoucí, zpomaluje práci nebo způsobuje, že uživatel dělá chyby. Počet souvisejících operací (na jedné obrazovce) při pořizování data – nástroje IS na bázi SAP, dostupné přes SAP GUI, jsou, jak už bylo řečeno, určeny pro zpracování více úloh najednou, což ale ocení zpravidla jen velmi kvalifikovaný uživatel. Naopak formuláře bývají ryze jednoúčelové. Další technologie UI stojí, počtem možných úloh zpracovávaných v jedné aplikaci, někde mezi těmito dvěma póly. Čím více úloh lze vykonat v jedné aplikaci tím, je výhodnější pro kvalifikovanějšího uživatele a samozřejmě naopak. Vyšší počet nástrojů v jedné aplikaci umožňuje bez opouštění aplikace měnit zpracovávaný úkol - to je výhodné pro odborně zdatného uživatele s různorodými úkoly. Takový uživatel ví jaké ovladače a funkce aplikace je potřeba vybrat. Jestliže s nástrojem pracuje méně zkušený uživatel, je naopak pravděpodobné, že vyšší počet možných způsobů zpracování a tomu odpovídajících ovladačů ho bude zdržovat, mást a působit tak, že uživatel bude dělat zbytečné chyby. Míra linearity zpracování – vyjadřuje tok akcí na obrazovce (v aplikaci), vyjadřuje, jestli při práci uživatel vidí vše potřebné na jedné obrazovce nebo jestli musí data získávat z více zdrojů, jestli je nucen postupovat v menu a obrazovkách do hloubky a zpět nebo naopak, jestli uživatel postupuje při práci lineárně (zleva doprava, shora dolů), nemusí se vracet a má všechny potřebné informace k dokončení úlohy na jednom místě. Příkladem lineárního zpracování je elektronický formulář, který má evokovat práci s papírovým formulářem, uživatel vyplňuje formulář od shora dolů a všechny relevantní informace je možné (a vhodné) uživateli před-vyplnit. Komplexní úlohy specialisté řeší spíše ve složitě organizovaném SAP GUI nebo jiných nástrojích vhodných pro komplexnější řešení. 36
Ochrana proti chybám - pořizovaná data se dotýkají určitého počtu „objektů“ (například určitého počtu uživatelů) informačního systému. Podle toho, jak široký a kritický dopad pořizovaná data mají na zbytek IS resp. další skupiny uživatelů, je vhodné chránit kvalitu dat již na úrovni uživatelského rozhraní. Některá rozhraní poskytují ochranu uživatele, aby nepořídil nevalidní a nesmyslná data, už z principu, jak jsou navrženy, nebo je v nich tuto ochranu poměrně jednoduché (a levné) vyvinout. Naopak jiná rozhraní nepředpokládají kritičnost pořizovaných dat nebo je ochrana ponechána k vyvinutí v každém konkrétním případě znovu. Analogicky podle pracovní náplně uživatele je potřeba uživatele při procesu pořizování dat chránit různě sofistikovaně. Při pořizování faktury do IS se předpokládá, že se faktura bude vztahovat k mnoha dalším objektům v IS – platí se existujícímu dodavateli, platí se za odebrané zboží, platí se na platný účet atd. Nápověda hodnot, které pravděpodobně uživatel použije, nebo alespoň indikace nevalidního vstupu vůči jiným objektům v systému (chybné integrity dat vůči stavu IS) je u tak kritické aplikace důležitá.
Poznámka: Výše popsaná interpretace jednotlivých kritérií byla použita pro hodnocení možností technologie. Interpretace hodnotících kritérií pro skupinu Uživatelů je obdobná a vychází z faktu, že uživatelé mají určité možnosti plynoucí z jejich postavení v organizaci (například kritérium „Ochota investovat do licence“ vyjadřuje, jak je organizace ochotna investovat do licence pro nové rozhraní pro danou skupinu uživatelů) nebo z osobních dispozic uživatelů pro práci s IS (například kritérium „Schopnost pracovat nelineárně“, které vyjadřuje, jestli je uživatel připraven ovládat aplikaci se složitým tokem akcí, s více obrazovkami a potenciálně proměnlivým počtem a pořadím akcí, jak je zvyklý pracovat s IT apod.). Na příkladu kritérií „Ochota investovat do licence“ (pro hodnocení uživatele) a „Náklady na licenci“ (pro hodnocení rozhraní) lze ukázat, jak spolu obě kritéria souvisí: Jestliže je ochota organizace investovat do licence nízká a zároveň rozhraní vyžaduje jen nízké náklady na licenci, pak tato skupina uživatelů je vhodná pro zvolené rozhraní a naopak.
37
3.5.2 Interpretace navržených stupnic hodnocení pro jednotlivá kritéria Odbornost v IT
Nízká – uživatel nemá (nepotřebuje) žádné nebo jen základní znalosti práce s počítačem, obtížně se přizpůsobuje a učí nové věci, Střední – uživatel pracuje s počítačem denně, ale pouze na základní uživatelské úrovni, je schopen akceptovat drobné změny a novinky a přizpůsobit se jim, Vysoká – uživatel v rámci své práce, pracuje s IS rutinně, nedělá mu problém učit se něco nového a přizpůsobovat se. Školení pro práci s IS
Nízká – uživatel nemá přístup k žádnému nebo jen občasnému a základnímu školení práce s IS, Střední – uživatel má přístup ke školení práce s IS, ale pouze v nejnutnější minimální míře, aby dokázal plnit svěřené povinnosti v informačním systému, Vysoká – uživatel má možnost průběžného školení v práci s IS dle aktuálních potřeb. Nápověda
Nízká – uživatel se dokáže orientovat jen na základě informací na obrazovce, není schopen ani ochoten pracovat s nápovědou,
Střední – uživatel dokáže pracovat s připravenou nápovědou nebo na základě jednoduchých instrukcí nápovědy, je schopen vyřešit problémy na základě vzdáleně předaných instrukcí, Vysoká – uživatel je zvyklý pracovat s pomocí nápovědy, vyžaduje její stálou přítomnost a intenzivně ji využívá ve své denní práci, v práci s IS je samostatný.
Licence
Nízká – organizace není ochotna investovat žádné nebo jen zcela minimální poplatky za licence pro přístup do informačního systému,
Průměrná – organizace je ochotna investovat prostředky, aby zapojila do procesů další uživatele, zejména tam kde to je účelné a potřebné, přičemž tyto prostředky nesmí vybočit z výše nákladů vynakládaných na tohoto uživatele v jiných oblastech jeho práce, Vysoká – organizace je připravena investovat dostatek prostředků za licence pro přístup do IS přes různá uživatelská rozhraní tak, aby maximálně zvýšila efektivitu práce s IS pro co nejširší okruh zaměstnanců. Náklady na přizpůsobení
Nízká – organizace není ochotna investovat prostředky do detailního přizpůsobování nástrojů pro uživatele v systému, Průměrná – organizace je ochotna v odůvodněných případech investovat prostředky do přizpůsobení nástrojů IS dle skutečných potřeb uživatele, Vysoká – organizace investuje dostatek prostředků do přizpůsobení nástrojů IS nejenom dle potřeb ale i dle specifických požadavků uživatele tak, aby dokázal pracovat s IS rychleji a efektivněji.
Náklady na vývoj Analogie přizpůsobení, zde se jedná o vývoj zcela nových nástrojů, nikoli jejich přizpůsobení od dodavatele. Automatizace při zpracování dat
Nízká – uživatel potřebuje vykonat úlohy přesně podle toho, co zadá a uloží do IS, bez zásahu IS do procesu práce, Průměrná – uživatel je schopen využít možnost uložit si často používaná nastavení aplikace nebo podobná drobná automatizační opatření, Vysoká – uživatel si plně uvědomuje výhody plynoucí z automatizace pravidelně se opakujících rutinních činnosti, je schopen a ochoten plně využívat resp. si i sám připravit automatizační mechanismus nebo zadat jeho přípravu dodavateli IS. 38
Frekvence pořizování dat do IS
Pravidelně – uživatel pravidelně a ve velice krátkém časovém horizontu pořizuje data do IS, zpravidla denně a kontinuálně v průběhu celé pracovní doby, Nepravidelně – uživatel pořizuje data do IS nepravidelně v delším časovém horizontu (zpravidla týdně a měsíčně), Nárazově - uživatel pořizuje data do IS v dlouhodobém časovém horizontu (měsíčně a více) a zpravidla zcela nahodile,
Objem pořizovaných dat Velký – uživatel pořizuje velký objem dat (mnohdy kritických dat ovlivňujících práci a chování velké skupiny dalších uživatelů), Průměrný – uživatel pořizuje data do IS v omezeném objemu (data ovlivňující práci a chování omezené skupiny dalších uživatelů), Malý – uživatel pořizuje data ve velmi omezené míře, zpravidla jde o data úzce svázána s osobou a charakterem práce jednoho konkrétního uživatele. Počet (nutných) ovládacích prvků (na obrazovce) pro pořizování dat - počet ovládacích prvků pro pořízení dat úzce souvisí s jejich objemem, variabilitou a kritičností:
Nízký – uživatel pro pořízení dat, za která je osobně odpovědný, potřebuje a současně upřednostňuje standardní, naprosto minimální počet „ovladačů (funkcionalit)“ na jedné obrazovce,
Průměrný - uživatel pro pořízení dat, za která je osobně odpovědný, potřebuje a současně upřednostňuje širší škálu „ovladačů (funkcionalit)“ na jedné obrazovce,
Vysoký - uživatel pro pořízení dat, za která je osobně odpovědný, nutně potřebuje širokou škálu „ovladačů (funkcionalit)“ na jedné obrazovce umožňujících pořízení dat různým způsobem, bez nutnosti pro každou úlohu přepínat mezi elementárními nástroji. Počet souvisejících operací (na jedné obrazovce) při pořizování data
Nízký – od uživatele je vyžadováno pořízení dat, za která je osobně odpovědný, v původní surové a jednoznačné podobě, pořizovaná data jsou zpravidla přísně účelová (exaktní),
Průměrný - od uživatele je vyžadováno pořízení dat, za která je osobně odpovědný, s určitou mírou předzpracování a osobní interpretace, pořizovaná data zpravidla nejsou přísně účelová a vyznačují se určitou mírou volnosti a kreativity,
Vysoký - uživatel pro pořízení dat, za která je osobně odpovědný, nutně potřebuje širokou škálu „ovladačů“ s rozsáhlými možnostmi nastavení procesu pořizování dat (customizaci) a různorodý přístup a pohled k dané problematice (předzpracování pořizovaných dat),
Míra linearity zpracování při pořizování dat
Lineární – uživatel je schopen a ochoten při pořizování dat postupovat pouze od začátku do konce, bez jakýchkoliv odboček (nutnosti rozhodování, doplňování a různých způsobů interpretace) Průměrná – uživatel pracuje v posloupnosti úkolů od počátku do konce, je schopen a ochoten v jednotlivých případech zvolit variantní řešení, Zanořující – uživatel musí a je schopen zpracovat svou úlohu v náročném prostředí, kde je třeba pracovat s více zdroji, kombinovat vstupy, interpretovat a vybírat nevhodnější varianty řešení. Ochrana proti chybám při pořizování dat Vysoká – uživatel potřebuje, s ohledem na úroveň svých znalostí, počítačové gramotnosti a kritičnost jim pořizovaných dat, vysokou míru ochrany proti chybám při pořizování dat, Průměrná - uživatel potřebuje, s ohledem na úroveň svých znalostí, počítačové gramotnosti a kritičnost jim pořizovaných dat, střední míru ochrany proti chybám při pořizování dat, Nízká – data pořizovaná uživatelem nejsou kritická pro práci ostatních uživatelů IS, zpravidla nevyžadují vysokou míru ochrany proti případným chybám, existují další kontrolní mechanismy schopné zabránit případným fatálním důsledkům.
39
3.5.3 Hodnocení skupin uživatelů a rozhraní V následujících tabulkách autor práce, na základě svých praktických zkušeností, dle zjištěného stavu v existujících IS a dle rétoriky společnosti SAP o uživatelských rozhraních, definuje pro vybrané skupiny uživatelů a uživatelská rozhraní z výše uvedených (uživatelé kapitola 3.4.2 Výběr demonstrační problematiky a rozhraní kapitola 2.4.2. Přehled technologií pro tvorbu UI v SAP) potřebné, nutné, žádoucí, vhodné, postačující apod. podmínky pro efektivní práci s IS při pořizování dat (tzv. normativ nebo také standard). Vůči tomuto základu bude následně autor poměřovat, do jaké míry takto vymezené požadavky naplňují konkrétní IS A a B. Tabulka č. 9: Hodnocení požadavků uživatelů dle navržené sady kritérií – stanovení normativu Kritérium Počítačová gramotnost Odbornost v IT Školení Nápověda Finance Licence Náklady na přizpůsobení Náklady na vývoj Rutinní provoz Automatizace při pořizování dat Frekvence pořizování dat Objem pořizovaných dat Počet nutných ovladačů Počet souvisejících operací Míra linearity při pořizování dat Ochrana proti chybám dat
Skupina Personalisté
Skupina Manažeři
Skupina Zaměstnanci
(potřeba)Vysoká (potřeba)Vysoká (potřeba)Vysoká
(stačí) Střední (stačí) Střední (stačí) Střední
(jen) Nízká (jen) Nízká (jen) Nízká
Vysoká Průměrná Průměrná
(vhodná) Průměrná (vhodná) Vysoká (vhodná) Vysoká
(jen) Nízká (jen) Nízká (jen) Nízká
Průměrná Pravidelně Velký Vysoký Vysoký Zanořující Vysoká (kritické)
Vysoká Nepravidelně Průměrný Průměrný Průměrný Průměrná Průměrná
Nízká Nárazově Malý Nízký Nízký (jen) Lineární Nízká
Tabulka č. 10: Hodnocení možností a podmínek použití uživatelských rozhraní dle navržené sady kritérií. Kritérium Počítačová gramotnost Odbornost v IT Školení Nápověda Finance Licence Náklady na přizpůsobení Náklady na vývoj Rutinní provoz Automatizace při pořizování dat Frekvence pořizování dat Objem pořizovaných dat Počet nutných ovladačů Počet souvisejících operací Míra linearity pořizování dat Ochrana proti chybám dat
Rozhraní SAP GUI
Rozhraní SAP Portál
Rozhraní formuláře
Vysoká Vysoká Vysoká
Střední Střední Střední
Malá Malá Malá
Vysoké Průměrná Průměrná
Průměrná Vysoké Vysoké
Nízké Nízké Nízké
Průměrná Pravidelně Velký Vysoký Vysoký Zanořující Vysoká
Vysoká Nepravidelně Průměrný Průměrný Průměrný Průměrná Průměrná
Nízká Nárazově Malý Nízký Nízký Lineární Nízká
40
3.6 Příprava modelu pro hodnocení Usability systému V informačním systému můžeme sledovat velké množství nejrůznějších objektů (uživatelů, aplikací, technologií, požadavků apod.). Pokud se ale chceme zaměřit pouze na „zlepšení Usability systému pro uživatele“ je potřeba nějakým způsobem tento počet objektů snížit. V opačném případě bychom byli nuceni zpracovávat detaily pomocí původní Usability. Výsledky dosažené pomocí původní Usability by pak nebyly aplikovatelné na celý systém. Proto by i dopad navržených opatření nebyl dostatečně vypovídající. Zpracování detailů pomocí původní Usability nám nedá odpovědi na takové otázky jako: Investice, do kterých částí IS, budou mít největší efekt na růst efektivity práce uživatelů s IS? Jak zpracovávat v IS co největší objem procesů a co pro to udělat? Investice, do kterých částí IS, přinesou největší úspory v rámci celé organizace? Výsledky zkoumání původní Usability by zahltilo zpracovatele analýzy detailními požadavky, které by měly význam pouze pro jednotlivé uživatele nebo malou skupinu uživatelů. Množina skupin uživatelů se vhodně konstruuje ze skupin, které byly identifikovány při popisu systémů (kapitola 3.4.3 Popis konkrétních systémů). Obvykle se rozlišují skupiny uživatelů jako:
Management obecně Zaměstnanci, Specialisté v rámci konkrétní odbornosti, Specialisté pro práci s IS v rámci konkrétní odbornosti (supervizoři).
Množina nástrojů je poměrně pevně daná standardními nástroji, rozhraními a aplikacemi SAP. Množinu lze konstruovat z oblastí, uvedených již v kapitole 3.4 Popis systému. Při přípravě modelu pro hodnocení Usability IS je potřeba mít na zřeteli také následující doporučení:
Je vhodné vytvořit modely širší, než jaký je aktuální stav systému. Jestliže bychom vytvořili model přesně podle aktuálního stavu IS, například bychom do modelu nezahrnuli konkrétní skupinu uživatelů jenom proto, že pro ně momentálně není v IS k dispozici vhodné rozhraní, mohli bychom promarnit příležitost identifikovat případných zlepšení IS. V kapitole 3.4.3 v popisu systému A je uvedeno, že dvě ze tří sledovaných skupin nepracují v informačním systému. Tím, že jsou skupiny přesto zahrnuty do modelu, dává příležitost okamžitě je začít začleňovat do IS. Pokud by skupiny nebyly do modelu začleněny, při zkoumání systému by nebylo vidět, že existují nedostatky IS, které je třeba řešit.
Skupiny uživatelů i technologie definujeme tak, aby byly dostatečně odlišné. Pro přípravu párování je v další kapitole definována množina kritérií, podle kterých ohodnocujeme různé páry - uživatele a technologie. Dvě skupiny uživatelů nebo dvě aplikace nejsou příliš odlišné, když se liší v ohodnocení jednoho kritéria z množiny v našem případě 13-ti kritérií. Jestliže jsou objekty mezi sebou málo odlišné, znamená to, že podrobnost modelu je příliš vysoká nebo že zkoumané objekty nevyužívají celou šíři prostoru. Z hlediska IS, aby byl zachován nadhled zkoumání i následných opatření, nemá smysl definovat zvlášť skupiny pracovníci Výroby a pracovníci Expedice jen proto, že pracovníci Expedice mají naplánována dvě školení pro práci s IS ročně, zatímco pracovníci Výroby nikoli. Tj. protože se liší ohodnocení obou skupin jen v jednom kritériu (dostupnost školení nízká a střední), nemá smysl skupiny definovat zvlášť.
41
3.7 Měření Usability systému Jak autor předeslal v úvodu Praktické části, Usability systému stanovuje tak, že porovnává požadavky uživatelů a možnosti aplikací a jejich rozhraní. Skupiny a aplikace, jejichž vztah se hodnotí, byly definovány v předchozí kapitole Příprava modelu systému. Parametry vztahu (relace), které pro hodnocení autor používá, byly také již uvedeny v předchozím textu v kapitole Interpretace kritérií měření. Nyní využijeme výsledek hodnocení požadavků skupin uživatelů a možností aplikací podle navržených kritérií, které byly uvedeny dříve v kapitole 3.5.3. Na základě ohodnocení bude dále možné provést samotné stanovení Usability systému. V systému, mezi objekty skupin uživatelů na jedné a aplikacemi a rozhraními na druhé straně, existuje množství potenciálních vazeb. Skupina uživatelů může využívat všechny dostupné aplikace a rozhraní, a naopak všechny skupiny uživatelů mohou využívat jednu aplikaci a rozhraní (kardinalita vazby je M:N). Hodnocení slouží k tomu, abychom nalezli pro každou dvojici objektů tu nejkvalitnější vazbu, tj. abychom dokázali říct, jak nejlépe systém splňuje potřeby a očekávání uživatelů. Pro ilustraci provedeme zhodnocení vazeb definované skupiny uživatelů Manažeři (popsanou v kapitolách 3.4.2 a 3.5.3) na 3 různá definovaná rozhraní IS (popsaná v kapitole 2.4.2 Přehled technologií pro tvorbu UI v SAP a ohodnocena v kapitole 3.5.3). Hodnocení vztahu objektů provedeme tak, že jestliže:
Se ohodnocení kritéria pro uživatele (např. objem pořizovaných dat uživatelem je velký) a pro rozhraní (vhodné pro pořizování velkého objemu dat) shoduje, započteme jeden bod,
Se ohodnocení kritéria pro uživatele (např. objem pořizovaných dat uživatelem je průměrný) a pro rozhraní (vhodné pro pořizování velkého objemu dat) liší o jeden stupeň stupnice, započteme půl bodu,
Jsou ohodnocení kritéria pro uživatele (např. objem pořizovaných dat uživatelem je malý) a pro rozhraní (vhodné pro pořizování velkého objemu dat) od sebe vzdálena více než o 2 stupně, započte se nula bodů. Maximální počet bodů odpovídá součtu bodů počtu kritérií. Výsledná Usability systému pro skupinu uživatelů je pak poměr získaného a maximálnímu počtu bodů pro všechna kritéria). Poznámka: Tento způsob bodování umožňuje hledání alternativ lépe, než kdybychom započetli bod pouze při absolutní shodě ohodnocení potřeb uživatelů a možností rozhraní.
42
Tabulka č. 11: Stanovení Usability systému pro skupinu Manažeři, kdyby pracovali v následujících třech rozhraních. Sloupec vedle každého rozhraní obsahuje získané body. Kritérium
Skupina Manažeři (normativ)
Rozhraní SAP GUI (normativ)
Rozhraní SAP Portál (normativ)
Rozhraní Formuláře (normativ)
Odbornost v IT Školení Nápověda Finance
Průměrná Průměrná Průměrná
Vysoká Vysoká Vysoká
½ Střední ½ Střední ½ Střední
1 Malá 1 Malá 1 Malá
½ ½ ½
Licence Náklady na přizpůsobení Náklady na vývoj Rutinní provoz
Střední Vysoká Vysoká
Vysoké Průměrná Průměrná
½ Průměrná ½ Vysoké ½ Vysoké
1 Nízké 1 Nízké 1 Nízké
½ ½ ½
Automatizace při pořizování dat Frekvence pořizování dat Objem pořizovaných dat Počet nutných ovladačů Počet souvisejících operací Míra linearity při pořizování dat Ochrana proti chybám dat Celková Usability rozhraní
Vysoká Nepravidelně Průměrný Průměrný Průměrný Průměrná Průměrná
Průměrná Pravidelně Velký Vysoký Vysoký Zanořující Vysoká
½ ½ ½ ½ ½ ½ ½
1 1 1 1 1 1 1
½ ½ ½ ½ ½ ½ ½
Počítačová gramotnost
6,5/13 = 50%
Vysoká Nepravidelně Průměrný Průměrný Průměrný Průměrná Průměrná 13/13 = 100%
Nízká Nárazově Malý Nízký Nízký Lineární Nízká 6,5/13 = 50%
Ohodnocením jsme zjistili, že ze tří možných vazeb je nejlepší vazba uživatelů „Manažeři“ a rozhraní „SAP Portál“. Zjištění lze interpretovat tak, že rozhraní SAP Portál poskytuje nejlepší možnosti, jak uspokojit přání a očekávání skupiny uživatelů Manažeři. Lépe než další dvě testovaná rozhraní. Jestliže v organizaci dosud neplatí, že Manažeři pracují v Portálu, doporučuje se systém o tuto možnost doplnit. Ohodnocením pro všechny kombinace skupin uživatelů a rozhraní získáme informaci, které dvojice objektů (uživatel – rozhraní) jsou nejvhodnější, a proto doporučené pro převedení do praxe. Kombinací výsledků lze také navrhnout celkovou Usability systému například jako aritmetický průměr přes všechny maximální vazby, které jsme v systému identifikovali a hodnotili. Autor navrhuje součet a nikoli součin, protože při posuzování efektivity při pořizování dat do IS změna podmínek pro Manažery nijak významně neovlivní podmínky pořizování dat pro Zaměstnance nebo jiné skupiny. Lze navrhovat i jiné varianty výpočtu celkové Usability systému. Například vztáhnout kvalitu vazby na významnost skupiny uživatelů. Nabízí se jedna ze dvou variant:
Využít koeficient významnosti skupiny uživatelů – vhodnou volbou koeficientu lze zachovat možnost vyjadřovat Usability v procentech, což je velmi vypovídající
Využít prostý počet uživatelů ve skupině – Usability systému při této variantě bude velmi významně proměnlivá podle počtu uživatelů zapojených do práce v IS a méně vyjadřovat kvalitu vztahu „uživatel a rozhraní“, výsledky budou opět dobře porovnatelné.
43
Obrázek č. 9: Příklad - v systému existují tyto maximální vazby včetně vyjádření, co znamená kvalita vazby pro celkovou Usability systému (hodnoty nenavazují na předchozí příklad):
Interpretace příkladu na obrázku č. 9: Usability systému pro skupiny uživatelů jsme stanovili výše uvedeným způsobem pomocí kritérií:
Nechť Odborní uživatelé (personalisté) používají SAP GUI, a nechť Usability systému je 85%,
Nechť Manažeři používají SAP GUI, a nechť Usability systému je 55%,
Nechť Ostatní zaměstnanci nepracují v IS, v tomto případě je Usability systému 0%.
Celkovou Usability systému pak spočteme jako: (85% + 55% + 0%) / (počet skupin = 3)= 47% Poznámka: Provedené ohodnocení je demonstrační a má ukázat postup, jak stanovit Usability systému pro skupiny uživatelů. V případě upravené množiny skupin uživatelů, množiny kritérií nebo při jiné volbě stupnic nebo bodování shody požadavku (uživatel) a možností (rozhraní) výsledky nebudou tak jednoznačné. Na uvedeném způsobu stanovení Usability systému lze také číselně demonstrovat potřebu integrovat různé aplikace a systémy do jednoho celku. Jestliže je aplikace integrovaná do hlavního IS (například výměnou XML zpráv, EDI, IDoc nebo jinými způsoby výměny dat), tak její Usability přispívá do Usability celého systému. Jestliže však aplikace integrovaná není, benefity z jejího používání se do Usability hlavního systému nepromítnou. Lze dokonce zvažovat, že se Usability systému sníží, protože z používání dvou neintegrovaných aplikací vznikají nové režijní náklady. Matematická interpretace faktu, že dva systémy nejsou integrovány je násobení jejich Usability (protože například Usability 50% lze vyjádřit jako 0,5, takže dva neintegrované systémy, z nichž každý má Usability 50%, mají celkovou Usability 0,5 * 0,5 = 0,25 = 25%). Příklad: Hypotetická organizace provozuje informační systém. Polovina uživatelů pracuje v IS a druhá polovina do IS nemá přístup a pracuje s tabulkovým kalkulátorem MS Excel. Jestliže je IS schopen importovat tabulky z Excelu a exportovat do něj data z databáze (tj. oba systémy jsou integrovány), výsledná Usability je vysoká. Pokud ale musíme data z Excelu do IS přepisovat ručně a naopak, Usability systému výrazně klesá.
44
3.7.1 Zlepšování Usability systému V předchozí kapitole 3.7 bylo popsáno, jak lze stanovit Usability systému pomocí autorem navrženého modelu. Tím získáme vstup pro následné zlepšování Usability systému. Náplní procesu zlepšování je:
Definice cílové Usability systému (např. chceme zlepšit Usability systému o 15%),
Příprava variant cílového modelu pro hodnocení systému, který má mít požadovanou Usability (varianty modelu zpracováváme proto, že k cílové Usability vede více možných cest),
Příprava postupu realizace (náklady, očekávané výnosy, personální zdroje atd.).
Model s požadovanou cílovou Usability systému lze odvodit od aktuálního modelu systému, který jsme použili v předchozí kapitole, a to jedním z následujících způsobů:
Zapojením nové skupiny uživatelů do systému – do modelu se přidá skupina zaměstnanců, která dosud nemá z různých důvodů přístup do IS. Uspokojením požadavků této nové skupiny uživatelů nějakým vhodným dostupným rozhraním Usability vzroste s ohledem na to, že Usability systému jsme v kapitole 3.7 definovali jako aritmetický průměr Usability pro jednotlivé skupiny uživatelů a nezapojená skupina výsledek zhoršovala.
Rozdělení existující skupiny uživatelů IS – v existujícím modelu se jedna skupina, která se ukáže být nehomogenní z hlediska požadavků uživatelů, tj. to co vyhovuje jedné části skupiny, nemusí vyhovovat jiné části, rozdělí na dvě nové skupiny, které jsou vůči hodnocenému uživatelskému rozhraní homogennější. Pro každou novou skupinu se bude hledat nová vazba na rozhraní. Pravděpodobně jedné z nových skupin bude původně přiřazené rozhraní vyhovovat a pro druhou novou skupinu se bude hledat, vhodnější rozhraní.
Přidáním nového rozhraní do systému pro uživatele – přidat do modelu systému nové rozhraní lze jen na základě technického vývoje IS. Téměř vždy se do modelu přidá rozhraní, které dodavatel systému nově do systému integroval. Pouze ve výjimečných případech se přidá nové rozhraní na základě vývoje v samotné organizaci, tj. že organizace integruje svůj informační systém s externí aplikací, která bude poskytovat rozhraní přístupu uživatelů k datům. Vývoj vlastních rozhraní, resp. vlastních integračních vazeb bývá finančně velmi náročný.
Zlepšení vybrané vazby mezi vybranou skupinou uživatelů a rozhraním – v kapitole 3.7 bylo uvedeno, jak se měří Usability systému pro uživatele – pomocí ohodnocení množiny kritérií a výběrem nejlepšího výsledku. Nejlepší výsledek Usability rozhraní pro uživatele nemusí být 100% (všechny kritéria jsou splněna), výsledek může být horší než 100% a přesto maximální. Usability systému vzroste, jestliže identifikujeme kritéria, která nejsou vhodně splněna, a provedeme opatření, která upraví ohodnocení požadavků uživatelů nebo možnosti rozhraní.
Na základě operací, pomocí kterých jsme navrhli úpravu modelu systému lze následně analyzovat, jaké požadavky a dopad bude opatření mít. Dopad na Usability byl vstupním požadavkem. Nyní lze z operace s modelem systému odvodit dopady do reálného světa.
45
3.7.2 Různé způsoby modelování systému Výše popsanou metodiku a model autor navrhnul tak, aby postihl vztah mezi Usability aplikace v původním významu (viz Teoretická část, kapitola 2.3.1), kde existujícími způsoby můžeme testovat a měřit použitelnost jednoho rozhraní pro jednoho konkrétního uživatele, a navrhovanou Usability systému, kde Usability stanovujeme pro zobecněné objekty – skupiny uživatelů (sjednocují je podobné požadavky kladené na IS) a skupiny nástrojů (autor navrhuje, že sjednocujícím prvek je technologie rozhraní). Je zřejmé, že existuje vztah mezi tím, že se svým softwarovým pracovním nástrojem je „spokojen“ jeden konkrétní uživatel, že nějak je se svými softwarovými nástroji „spokojena“ je skupina, jejíž je ten konkrétní uživatel členem, že to tudíž ovlivňuje „spokojenost“ větších a větších skupin, až je možno hovořit o celkové „spokojenosti“ organizace s informačním systémem. Tuto „spokojenost“ autor chápe jako navrhovanou Usability systému (v původním smyslu Usability, ale tentokrát pro větší celky a navrhuje ji měřit na různých úrovních detailu a dávat vhodnými hierarchickými vztahy do souvislosti. Následující obrázek (č. 10) demonstruje na jakých různých úrovních například lze Usability systému zkoumat. Na levém obrázku zkoumáme „obecný vztah“ uživatelů k informačnímu systému. Na prostředním obrázku zkoumáme vztah konkrétní skupiny uživatelů a konkrétního (vhodného) rozhraní nebo aplikace. Na obrázku zcela vpravo rozdělujeme Odborné uživatele ještě na pod-skupiny podle zpracovávané problematiky (procesu), provádíme kombinaci Usability analýzy s funkční analýzou. Příklad: V demonstrační oblasti – Personalistice – se část lidí stará o zpracování mezd a jiná část o přípravu podkladů pro manažerské rozhodování. Požadavky těchto lidí jsou mírně odlišné, stejně jako nástroje informačního systému, které používají. Při každém zvýšení detailu zkoumání systému – rozdělení rozhraní nebo skupiny uživatelů na další pod-části:
Vzrůstá přesnost modelu (vzrůstá homogenita požadavků skupin uživatelů atd.),
Klesá dopad zjištěných problémů a nápravných opatření na celý systém.
Obrázek č. 10: Různá úroveň zkoumání Usability pomocí navrženého modelu.
Analogicky lze postupovat i z jiných úhlů pohledu:
Pro skupinu „Odborní uživatelé“ měřit Usability pro různé nástroje SAP ERP (tj. různé aplikace používající rozhraní SAP GUI): SAP GUI aplikace pro mzdy, SAP GUI aplikace pro reporting a další. (Tj. při změně detailu zkoumání zafixujeme skupinu uživatelů a měníme rozhraní),
Pro rozhraní „SAP GUI“ měřit Usability pro různé pod-skupiny uživatelů. (tj. zafixujeme rozhraní). Adaptací navržené metody lze zkoumat například také vztah skupin uživatelů a funkčnosti IS – nikoli jak se systém uživatelům ovládá (zkoumání Usability v této práci), ale jak standardní funkčnost SAP (systému) odpovídá požadavkům uživatelů (jednalo by se o jiný účel zkoumání mimo rámec této práce). Jiné možné pohledy z jakých informační systém zkoumat autor uvedl v kapitole 3.3 Usability systému a rozpracoval v této práci vztah uživatelů a rozhraní. 46
4 Měření Usability zkoumaných systémů V kapitole 3.4.3 autor popsal existující informační systémy, na kterých demonstruje navržené postupy. V kapitole 3.5.1 byla navržena sada kritérií, kterou lze postihnout vztah požadavků uživatelů a možností rozhraní IS. Pomocí těchto kritérií byl následně v kapitole 3.5.5 popsán postup, jak z ohodnocení definovaných kritérií pro konkrétní skupinu uživatelů a konkrétní uživatelské rozhraní IS odvodit Usability systému. V této kapitole autor provede ohodnocení uvedených dvou systémů A a B:
Připraví modely systémů (na základě popisu uvedeného v kapitole 3.4.3),
Stanoví Usability těchto systémů (prostřednictvím ohodnocených modelů),
U vybraných nalezených nedostatků vztahů mezi požadavky uživatelů a používaným rozhraním navrhne autor některé z možných způsobů nápravy, aby ilustroval, že dosažené výsledky lze aplikovat do praxe.
Všechna hodnocení se porovnávají se „standardem“ ohodnocení (normativem) uvedeným v kapitole 3.5.3 Hodnocení skupin uživatelů a rozhraní. Porovnáním konkrétního systému a standardu se lze okamžitě orientovat v silných a slabých stránkách zkoumaného systému a navrhovat opatření k nápravě deficitů, odstranění neefektivit nebo využití nových příležitostí. Poznámka: Pro zachování stručnosti a přehlednosti příkladů jsou tabulky ohodnocení konkrétních skupin uživatelů systémů A a B a také rozhraní přesunuta do příloh práce.
4.1 Měření Usability systému A 4.1.1 Model systému Organizace disponuje pro oblast personalistiky dva IS: SAP ERP a non-SAP systém. Z definovaných skupin uživatelů pracují s IS pouze „Personalisté“, ale organizace by ráda umožnila využívat alespoň jeden z obou systémů pro podporu personální práce i další skupině uživatelů a to „Manažerům“. Obrázek č. 11: Model systému A
4.1.2 Ohodnocení systému Potřebujeme znát hodnocení objektů využívajících IS:
Ohodnocení požadavků skupiny „Personalisté“ na IS,
Ohodnocení možností rozhraní SAP GUI (použijeme standardní ohodnocení rozhraní uvedeno v kapitole 3.5.3),
Ohodnocení možností rozhraní pro non-SAP systém (aplikaci). Pro budoucí zapojení skupiny „Manažeři“ (požadavek organizace) potřebujeme znát také ohodnocení předpokládaných potřeb uživatelů v této skupině, a to podle aktuálního stavu v organizaci. Lze porovnat s typickým ohodnocením skupiny „Manažeři“ uvedeným v kapitole 3.5.3.
47
Tabulka č. 12: Hodnocení Usability rozhraní pro skupinu uživatelů Personalisté v systému A. Kritérium Počítačová gramotnost Odbornost v IT Školení Nápověda Finance Licence Náklady na přizpůsobení Náklady na vývoj Rutinní provoz Automatizace pořizování dat Frekvence pořizování dat Objem pořizovaných dat Počet nutných ovladačů Počet souvisejících operací Míra linearity pořizování dat Ochrana proti chybám dat Celková Usability rozhraní
Personalisté v systému A
Rozhraní SAP GUI
Rozhraní non-SAP
Střední Střední Vysoké
Vysoká Vysoká Vysoká
½ ½ 1
Střední Střední Střední
1 1 ½
Průměrná Nízká Nízká
Vysoké Průměrná Průměrná
½ ½ ½
Průměrná Vysoké Vysoké
½ 0 0
Nízká Pravidelně Velký Průměrná Průměrná Průměrná Vysoká
Průměrná ½ Pravidelně 1 Velký 1 Vysoký ½ Vysoký ½ Zanořující ½ Vysoká 1 8,5/13 = 65%
Nízká Pravidelně Velký Vysoký Vysoký Zanořující Vysoká 8,5/13 = 65%
1 1 1 ½ ½ ½ 1
Interpretace: Z výsledků v tabulce 12 plyne, že používaná rozhraní do obou systémů jsou pro potřeby skupiny „Personalisté“ stejně vhodná. Z výsledků lze také usoudit, proč organizace využívá oba systémy přibližně stejně a ani osobní pohled uživatelů (jak se jim se systémy pracuje a který preferují) nepřiměl organizaci k přechodu pouze na jeden systém. Z výsledků také plyne, na co bychom se měli zaměřit při návrhu rozvojových opatření tohoto konkrétního systému – hodnocení kterých kritérií je třeba zlepšovat. Na základě výsledků uvedených v tabulce č.12 lze organizaci doporučit: (1) Integraci obou systémů (SAP a non-SAP) do jednoho celku s automatizovanou výměnou dat, protože pokud neexistuje závažný funkční důvod pro upřednostnění jednoho systému (jeden systém něco neumí), nelze dle hodnocení Usability doporučit upřednostnění ani jednoho systému na úkor druhého. (2) Rozdělení skupiny „Personalisté“ tak, aby každá ze dvou nových skupin používala pouze jeden ze systémů a jedno rozhraní. Pravděpodobně tak bude možno dosáhnout lepších výsledků při příštím hodnocení díky tomu, že: o Náročnější úlohy budou zpracovávat uživatelé SAP, pro to jim bude nutno poskytnout vhodnou podporu v podobě školení atd. Způsob práce uživatele bude možné v průběhu času zefektivňovat investicemi do přizpůsobení jimi používaných nástrojů tak, aby lépe vyhovovaly jejich rozvíjejícím se potřebám o Méně náročné úlohy budou zpracovávat uživatelé non-SAP systému. Tito uživatelé budou využívat pouze existující funkčnost, protože náklady a problémy spojené s úpravou existujícího systému jsou velmi nepříznivé vůči možnostem (a ochotě) organizace je hradit. (3) Zjednodušení používaných nástrojů (především méně komplikované obrazovky, menší počet ovládacích prvků atd.), které umožní i méně schopným uživatelům efektivně vykonávat svěřenou práci.
48
Tabulka č. 13: Hodnocení Usability rozhraní pro skupinu uživatelů Manažeři v systému A. Kritérium Počítačová gramotnost Odbornost v IT Školení Nápověda Finance Licence Náklady na přizpůsobení Náklady na vývoj Rutinní provoz Automatizace pořizování dat Frekvence pořizování dat Objem pořizovaných dat Počet nutných ovladačů Počet souvisejících operací Míra linearity pořizování dat Ochrana proti chybám dat Celková Usability rozhraní
Manažeři v systému A
Rozhraní SAP GUI
Rozhraní SAP Portál
Rozhraní non-SAP
Nízká Nízká Nízká
Vysoká Vysoká Vysoká
0 0 0
Střední Střední Střední
½ Střední ½ Střední ½ Střední
½ ½ ½
Průměrná Nízká Nízká
Vysoké Průměrná Průměrná
½ ½ ½
Průměrná Vysoké Vysoké
½ Průměrná 0 Vysoké 0 Vysoké
½ 0 0
Nízká Nárazově Průměrný Nízká Nízký Lineární Vysoká
Průměrná ½ Pravidelně 0 Velký ½ Vysoký 0 Vysoký 0 Zanořující 0 Vysoká 1 3,5/13 = 27%
Vysoká Nepravidelně Průměrný Průměrný Průměrný Průměrná Průměrná 5/13 = 38%
0 ½ ½ ½ ½ ½ ½
1 0 ½ 0 0 0 1
Nízká Pravidelně Velký Vysoký Vysoký Zanořující Vysoká 4,5/13 = 35%
Interpretace: Z výsledků uvedených v tabulce 13 plyne, že SAP GUI není pro skupinu „Manažeři“ vůbec vhodné. Pokud bude nutno rozhodnout o rozhraní pro manažery mezi uvedenými rozhraními, z pohledu Usability je téměř ekvivalentní, když „Manažeři“ budou používat existující non-SAP systém nebo společnost bude instalovat webové rozhraní SAP – Portál. Skutečnost, že se non-SAP systém v organizaci již používá, jednoznačně hovoří pro začlenění skupiny „Manažeři“ do IS prostřednictvím non-SAP klienta (tedy jen do non-SAP systému). Jestliže by organizace vyžadovala zapojení nových uživatelů do IS prostřednictvím rozhraní s vyšší Usability, bylo by nutno hledat další integrovatelná rozhraní. Můžeme se pokusit ověřit hypotézu, že pro uživatele skupiny „Manažeři“ by bylo vhodné používat jako rozhraní do IS e-formuláře.
49
Tabulka č. 14: Hodnocení Usability e-formulářů pro skupinu uživatelů Manažeři v systému A. Kritérium Počítačová gramotnost Odbornost v IT Školení Nápověda Finance Licence Náklady na přizpůsobení Náklady na vývoj Rutinní provoz Automatizace pořizování dat Frekvence pořizování dat Objem pořizovaných dat Počet nutných ovladačů Počet souvisejících operací Míra linearity pořizování dat Ochrana proti chybám dat Celková Usability rozhraní
Manažeři v systému A
Rozhraní formuláře
Malá Malá Malá
Malá Malá Malá
1 1 1
Průměrná Nízká Nízká
Nízké Nízké Nízké
½ 1 1
Nízká Nárazově Průměrný Nízký Nízký Lineární Vysoká
Nízká Nárazově Malý Nízký Nízký Lineární Nízká 11/13 = 85%
1 1 ½ 1 1 1 0
Interpretace: Z výsledku v tabulce 14 plyne, že můžeme hypotézu „pro Manažery je vhodné používat pro přístup do IS rozhraní e-formuláře“ považovat za prokázanou. Z výsledku dále plyne, že bude potřeba používání formulářů mírně přizpůsobit - důležitým požadavkem uživatelů je být chráněn před zanesením chyby do IS při pořizování dat, což e-formuláře nepodporují zcela automaticky a bezpracně. Lze proto očekávat, mírně zvýšené náklady na nasazení formulářů z tohoto důvodu. Zajímavé také je, nakolik se požadavky „Manažerů“ této organizace liší od standardních/ obvyklých požadavků středního managementu průměrné organizace (lze porovnat s hodnotami uvedenými v 3.5.3.) Lze předpokládat, že postupně se budou požadavky manažerů v organizaci A přibližovat standardním požadavkům průměrných manažerů, a to jak se bude upevňovat povědomí o nutnosti a prospěšnosti používání IS u této skupiny uživatelů, celková vyspělost organizace a zkušenost manažerů v práci s IS. Na základě výsledků hodnocení Usability lze doporučit nasazení technologie e-formulářů jako vhodného uživatelského rozhraní pro přístup uživatelů „Manažeři“ do informačního systému A.
4.1.3 Hodnocení Usability Usability systému popsaného modelem je: Zjištěná Usability rozhraní SAP GUI pro skupinu „Personalisté“ je 65%. Zjištěná Usability rozhraní non-SAP klienta pro skupinu „Personalisté“ je 65%. Jestliže zanedbáme fakt, že systémy nejsou propojeny automatickou výměnou dat pak je výsledná Usability systému (65% + 65%) / 2 = 65%. Pokud tento fakt vezmeme v úvahu, pak se celková Usability systému sníží na (65% * 65%) = (0,65 * 0,65) = 42% (dle závěru kapitoly 3.7). Usability systému, pokud zapojíme skupinu „Manažeři“ do práce v IS: Jestliže zapojíme „Manažery“ do IS pomocí non-SAP klienta (do non-SAP systému) a pro skupinu „Personalisté“ použijeme vyšší hodnotu Usability, pak celková Usability je (65%+ 35%) / 2 = 50% Jestliže ale zapojíme „Manažery“ do práce v IS pomocí e-formulářů, pak celková Usability takového systému bude (65% + 85%) / 2 = 75% Z výše uvedeného vyplývá, že pokud zapojíme skupinu uživatelů „Manažeři“ do práce s IS (pouze SAP) je možné zlepšit původní Usability systému z 65% pro 10 uživatelů na 75% pro 765 uživatelů. 50
4.2 Měření Usability systému B 4.2.1 Model systému Definovaná skupina (kapitola 3.4.3) „Personalisté“ pracuje se systémem přes rozhraní SAP GUI. Definovaná skupina „Manažeři“ pracuje v IS přes webové rozhraní SAP portál. „Ostatní zaměstnanci“ dosud v IS nepracují. Účelem analýzy je zjistit, jak vhodně „Ostatní zaměstnance“ zapojit do práce s IS. Obrázek č. 12: Model systému B
4.2.2 Ohodnocení systému Potřebujeme znát hodnocení objektů pracujících s IS:
Ohodnocení požadavků skupin „Personalisté“ a „Manažeři“ na IS,
Ohodnocení rozhraní SAP GUI a SAP Portál (použijeme standardní ohodnocení uvedeno v 3.5.3),
Ohodnocení možností rozhraní do non-SAP část (aplikaci) personálního IS. Pro zapojení skupiny „Zaměstnanci“ potřebujeme také znát ohodnocení potřeb uživatelů, a to podle aktuálního stavu v organizaci. Lze porovnat se standardním ohodnocením uvedeným v kapitole 3.5.3. Pokusíme se prokázat hypotézu, že „pro zaměstnance organizace B bude vhodné použít e-formuláře“. Tabulka č. 15: Hodnocení Usability rozhraní SAP GUI pro skupinu uživatelů Personalisté v systému B. Kritérium Počítačová gramotnost Odbornost v IT Školení Nápověda Finance Licence Náklady na přizpůsobení Náklady na vývoj Rutinní provoz Automatizace pořizování dat Frekvence pořizování dat Objem pořizovaných dat Počet nutných ovladačů Počet souvisejících operací Míra linearity pořizování dat Ochrana proti chybám dat Celková Usability rozhraní
Personalisté v systému B
Rozhraní SAP GUI
Vysoká Vysoká Vysoká
Vysoká Vysoká Vysoká
1 1 1
Vysoké Střední Nízké
Vysoké Střední Střední
1 1 ½
Vysoká Pravidelně Velký Vysoký Vysoký Zanořující Vysoká
Střední Pravidelně Velký Vysoký Vysoký Zanořující Vysoká 12/13 = 92%
½ 1 1 1 1 1 1
51
Interpretace: Z výsledků tabulky 15 vyplývá, že SAP GUI je vhodné rozhraní pro skupinu „Personalisté“ v systému B. Organizaci lze však na základě výsledků dále doporučit, aby:
Zvýšila objem prostředků dostupný pro vývoj nové a nestandardní funkcionality, kterou odborní uživatelé /personalisté mohou využít pro to, aby ještě zefektivnili svou práci v IS
Hledali způsob, jak ještě více automatizovat v IS rutinní úlohy, aby odborní uživatele měli prostor zvýšit podíl řídící a kreativní práce v IS místo vykonávání provozních úloh.
Tabulka č. 16: Hodnocení Usability rozhraní SAP Portál pro skupinu uživatelů Manažeři v systému B. Kritérium Počítačová gramotnost Odbornost v IT Školení Nápověda Finance Licence Náklady na přizpůsobení Náklady na vývoj Rutinní provoz Automatizace pořizování dat Frekvence pořizování dat Objem pořizovaných dat Počet nutných ovladačů Počet souvisejících operací Míra linearity pořizování dat Ochrana proti chybám dat Celková Usability rozhraní
Manažeři v systému B
Rozhraní SAP Portál
Střední Vysoká Střední
Střední Střední Střední
1 ½ 1
Vysoká Průměrná Nízká
Průměrná Vysoké Vysoké
½ ½ 0
Vysoká Nepravidelně Průměrný Průměrný Průměrný Průměrná Průměrná
Vysoká Nepravidelně Průměrný Průměrný Průměrný Průměrná Průměrná 10,5/13 = 81%
1 1 1 1 1 1 1
Interpretace: Z výsledků v tabulce 16 vyplývá, že SAP Portál je vhodné rozhraní pro uživatele skupiny „Manažeři“. Organizaci lze na základě výsledků doporučit, aby:
Zvážila možnost úspor za školení pro práci s IS pro skupinu uživatelů „Manažeři“. Z výsledků hodnocení totiž vyplývá, že uživatelé mají ke školení větší přístup než je potřeba, tj. je možné, že některá školení uživatelů pro práci s IS jsou zbytečná a bylo by možno za ně ušetřit.
Náklady na licence pro přístup do IS převyšují potřeby této skupiny zaměstnanců. Organizaci lze doporučit přezkoumání využívání současných licencí, aby se odhalily případné duplicitní poplatky (například někteří uživatelé mohou mít zakoupenu licenci zároveň pro práci v SAP GUI i přes SAP Portál, efektivně však dokážou využít jen jednu).
Existující rezervy nebo úspory lze využít pro vývoj nových a nestandardních funkčnosti, které by mohly zefektivnit a zpříjemnit práci dalším uživatelům.
52
Tabulka č. 17: Hodnocení Usability rozhraní SAP Portál a formuláře pro skupinu uživatelů Zaměstnanci v systému B (pro ověření hypotézy). Kritérium Počítačová gramotnost Odbornost v IT Školení Nápověda Finance Licence Náklady na přizpůsobení Náklady na vývoj Rutinní provoz Automatizace pořizování dat Frekvence pořizování dat Objem pořizovaných dat Počet nutných ovladačů Počet souvisejících operací Míra linearity pořizování dat Ochrana proti chybám dat Celková Usability rozhraní
Zaměstnanci v systému B
Rozhraní SAP Portál
Rozhraní formuláře
Malá Malá Malá
Střední Střední Střední
½ Malá ½ Malá ½ Malá
1 1 1
Průměrná Průměrná Nízká
Průměrná Vysoké Vysoké
1 Nízké ½ Nízké 0 Nízké
½ ½ 1
Nízká Nárazově Malý Nízká Nízká Lineární Nízká
Vysoká Nepravidelně Průměrný Průměrný Průměrný Průměrná Průměrná 6/13 = 46%
0 ½ ½ ½ ½ ½ ½
1 1 1 1 1 1 1
Nízká Nárazově Malý Nízký Nízký Lineární Nízká 12/13 = 92%
Interpretace: Na základě výsledků uvedených v tabulce 17 je zřejmé, že elektronické formuláře vhodně splní potřeby uživatelům skupiny „Zaměstnanci“ pro nenáročný a jednoduchý přístup do IS organizace. Dokonce při pohledu na sekci finance je vidět, že:
Náklady na použití formulářů jsou nižší, než jaké je ochotna organizace pro přístup zaměstnanců do IS vynaložit,
Náklady na použití elektronických formulářů jsou nižší než při použití rozhraní SAP portál, a že eformuláře mnohem lépe vyhovují zjištěným potřebám uživatelů Na základě výsledků hodnocení Usability lze doporučit nasazení technologie e-formulářů jako vhodného uživatelského rozhraní pro přístup uživatelů „Zaměstnanci“ do informačního systému B.
4.2.3 Hodnocení Usability Usability systému popsaného modelem je: Zjištěná Usability SAP GUI pro skupinu „Personalisté“ je 92%. Zjištěná Usability SAP Portálu pro skupinu „Manažeři“ je 81%. Celkově tedy Usability systému je: (92% + 81%) / 2 = 87% (dle kapitoly 3.7) Usability systému pokud zapojíme skupinu „Zaměstnanci“ do práce v IS pomocí formulářů: Zjištěná Usability SAP GUI pro skupinu „Personalisté“ je 92%. Zjištěná Usability SAP Portálu pro skupinu „Manažeři“ je 81%. Zjištěná Usability formulářů pro skupinu „Zaměstnanci“ je 92% Celkově tedy Usability systému je: (92% + 81% + 92) / 3 = 88% (dle kapitoly 3.7) Jestliže budou uživatelé „Zaměstnanci“ zapojeni do práce s IS pomocí rozhraní e-formuláře, dojde ke změně Usability systému z 87% pro 60 uživatelů 88% pro 560 uživatelů. Změna Usability systému nebude výrazná, díky zvýšenému počtu zapojených uživatelů však výrazně stoupne Usefulness systému (tj. systém bude mít lepší význam pro chod organizace). 53
5 Závěr Jak již bylo uvedeno v úvodní kapitole této práce, uživatelé informačního systému mají v dnešní době klíčový vliv na efektivní chod organizace (a tento vliv se stále zvyšuje). Tento vliv je pozitivní, jestliže uživatelé mají k IS přístup, jsou schopni a ochotni se systémem pracovat, jsou schopni pracovat rychle, efektivně, bezchybně. Všechny tyto otázky lze spolu-řešit zkoumáním Usability systému, jak ji autor navrhuje v této diplomové práci. Zkoumání Usability systémů nelze chápat jako hlavní cíl, ale pouze jako prostředek, jak lze zjistit, jak „dobře“ mohou uživatelé pracovat s IS, respektive jak dobře jim to rozhraní IS umožňuje s ohledem na jejich očekávání, požadavky, možnosti a omezení. Usability systémů dává odlišný pohled na použití a rozvoj IS, než jaký je běžný ve většině organizací, se kterými se měl autor možnost seznámit. V organizacích se běžně používají tvrzení, že s IS se nepracuje:
Protože je to moc drahé,
Protože uživatelé jsou nevzdělaní,
Protože systém nemá ty správné funkce, které potřebujeme apod. Funkční deficity IS zlepšování Usability systému nenahradí, ale pomůže tomu, aby existující zdroje a nástroje (technické, finanční i personální) systému byly využívány správně a efektivně a nové a budoucí zdroje nebyly vynakládány zbytečně nebo opětně neefektivně. Situace, že informační systém obsahuje funkční zpracování nějaké problematiky a procesů, ale uživatelé s nimi nechtějí, neumějí nebo jim není umožněno pracovat, jsou v organizacích běžné. Autor práce se zaměřil při zkoumání problémů s používáním IS na dva klíčové objekty:
Uživatelé jako reprezentace požadavků na IS a
Rozhraní jako nástroje splnění požadavků a definoval pro vztah těchto dvou objektů měřitelnou kvalitu. Pro měření kvality tohoto vztahu definoval kritéria, která slouží jako příklady (které lze doplnit nebo nahradit vhodnějšími) aspektů vztahu uživatelů k informačnímu systému z hlediska Usability. Pomocí zjednodušení rozsáhlého informačního systému na vztahy objektů dvou typů skupin uživatelů a rozhraní systému dosáhl autor práce vhodného zjednodušení vztahů panujících mezi mnoha možnými objekty IS (funkční moduly IS mohou být dalším typem objektu atd.). Problémy a jejich řešení, které autor popsal na základě zkušeností z praxe, se ukázaly vhodně řešitelné modelováním vztahů. Dosažené výsledky jsou také jednoduché k interpretaci a názorné k prezentaci. Zpřesňování uvedené metody bude vyžadovat, aby byla použita nezávisle různými hodnotiteli pro různé informační systémy. Lze předpokládat, že ke zpřesňování bude docházet především v oblasti:
Úpravy množiny kritérií pro hodnocení vztahu požadavků uživatelů a možností rozhraní,
Návrhu opatření, které povedou ke zlepšení sledovaných vztahů uživatelé – rozhraní, a tedy ke zlepšení Usability systému konkrétního IS v budoucnu.
Technologie e-formulářů Adobe, kterou autor práce zkoumal nejpodrobněji, se ukázala být pro organizace velmi atraktivním a inovativním rozhraním, které velmi dobře splňuje požadavky části uživatelů na informační systém. Předložené argumenty pro použití formulářů:
Usability formulářů a jejich vhodné doplnění množiny rozhraní informačního systému a
akceptovatelná licenční politika a technické nároky přesvědčily popsanou organizaci A, aby zvažovala budoucí využití technologie Adobe e-formulářů ve svém IS, a organizaci B, aby začala aktivně začleňovat e-formuláře do svého informačního systému.
54
6 Literatura 6.1 Citované zdroje [1]
Enterprise Resource Planning, Wikipedia, internet:
[2]
http://en.wikipedia.org/wiki/Enterprise_resource_planning Basl J., Blažíček R.: Podnikové informační systémy, Grada, Praha, 2008
[3] [4] [5] [6]
Přehled ERP informačních systémů, internet: http://www.systemonline.cz/prehled-informacnich-systemu/erp-systemy/ SAP R/3, Wikipedia, internet: http://en.wikipedia.org/wiki/SAP_R/3 Basl J., Benda L.: Podpora podnikových procesů produkty SAP, Oeconomia, Praha, 2003 NetWeaver, Wikipedia, internet: http://en.wikipedia.org/wiki/Netweaver
[7] [8]
Programovací jazyk X++, Wikipedia, internet: http://en.wikipedia.org/wiki/Axapta Papík R.: Vyhledávání informací II. Uživatelské rozhraní a vlivy oboru “Human computer interaction“, Ústav informačních studií a knihovnictví FF UK, 2001, http://knihovna.nkp.cz/NKKR0102/0102081.html
[9]
Graphical user interface, Wikipedia, internet: http://en.wikipedia.org/wiki/Graphical_user_interface Trenner L.: How to win friends and influence people: definitions of user-friendliness in interactive computer systems, Journal of Information Science, Vol. 13, No. 2 , 1987 Usability, Wikipedia, internet: http://en.wikipedia.org/wiki/Usability Human-computer Interaction, Wikipedia, internet: http://en.wikipedia.org/wiki/Human-computer_interaction Interaction design, Wikipedia, internet: http://en.wikipedia.org/wiki/Interaction_design
[10] [11] [12] [13] [14] [15] [16]
Königová M.: Teorie vědeckých informací. In INFOS’84 : zborník zo 14. Informatického seminára s medzinárodnou účasťou, Bratislava, ALFA, 1984 Marcus A.: Return on Investment for Usable User- Interface Design: Examples and Statistics, internet: http://www.amanda.com/resources/ROI/AMA_ROIWhitePaper_28Feb02.pdf Usability Techniques, internet: http://www.sameerchavan.com/web_ui_techniques.htm
[17]
Nielsen, J.: Heuristic evaluation, Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods, John Wiley & Sons, 1994, New York, NY
[18] [19a]
Murphy B.: e-Forms Software, The Forrester Wave, 2006, prezentace, internet: http://www.adobe.com/enterprise/pdfs/eForms_Wave.pdf IBM Forms, webová prezentace společnosti IBM, internet:
[19b]
http://www-01.ibm.com/software/lotus/forms/ Cardiff Software Forms, webová prezentace společnosti, internet:
[19c] [19d] [20]
http://www.cardiff.com/products/liquidoffice_eforms/index.html Microsoft Infopath Forms, webová prezentace společnosti, internet: http://office.microsoft.com/cs-cz/infopath/HA101672661029.aspx 602 XML Forms Server, webová prezentace společnosti, internet: http://www.602.cz/602xml_form_server/zakladni_popis SAP Design Guild Resources, SAP AG, 2009, internet: http://www.sapdesignguild.org/resources/resources.asp 55
[21] [22] [23] [24]
SAP’s Visual Design Vision and Mission, SAP AG, 2009, internet: http://www.sapdesignguild.org/resources/print_visualdesign_strat.asp UI Guidelines for SAP CRM, SAP AG, 2009, internet: http://www.sapdesignguild.org/resources/CRM-UI-Guidelines-Customers.pdf Veřejné testování nových produktů a aplikací SAP, SAP AG, 2009, internet: http://usability.sap.com/Help/PublicHelp.aspx Přehled (FAQ) o projektu SAP Usability Testing, SAP Labs, 2009, internet: http://www.saplabs.com/usability/faq.asp
[25]
EnjoySAP: A Success Story, SAP AG, April 2000, internet: http://www.sapdesignguild.org/editions/philosophy_articles/enjoy_success.asp
[26]
Erxleben K., Gebauer A.: EnjoySAP - Success Factors Involved in the Introduction of a UserOriented Software Development Process, SAP AG, 2000, internet: http://www.sapdesignguild.org/editions/philosophy_articles/hmd_enjoy_usab/hmd_enjoy _usab.pdf Norman, D. A., the Design of Everyday Things, 1988; New York, Doubleday Publishing Group
[27] [28] [29] [30] [31] [32]
[33]
[34]
[34] [35] [36] [37] [38] [39] [40]
Jacobson, R.E.: Information design, The MIT Press, 1999, Cambridge
Rowley, J.E.: The basics of systems analysis and design for information managers, Clive Bingley, 1992, London Foss, C.L.: Tools for reading and browsing hypertext, Inform. Process Mgmt, 1989 Luke Wroblewski: Best practices for form design, WEB FORM DESIGN, 2008, internet: http://www.lukew.com/resources/articles/WebForms_LukeW.pdf Sap Interactive Forms by Adobe FAQ – webová stránka s „nejčastěji kladenými otázkami“, SDN SAP - komunitní webová stránka vývojářů pro SAP https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/2a8a0a37-03010010-f794-aecd1bb426e0 Saramango, N.: Platform business Development, Office of the EMEA CTO, September 2008, prezentace, internet: http://www.sap.com/croatia/company/events/2008/worldtour/pdf/02_4_SAP_Interactive _Forms_based_on_Adobe.pdf Gopal, S.: SAP Interactive Forms by Adobe, SAP Summit, 2008, Singapore, prezentace, internet: http://www.sap.com/singapore/company/events/summit08/asset/Final%20Presentation% 20-%20Breakout/Ballroom%202/EIM/Adobe_SAP%20interactive%20form.pdf Failure mode and effects analysis, Wikipedia, internet: http://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis Metoda FMEA, internet: http://www.kvic.cz/showFile.asp?ID=2109 FMEA Info Centre, Everything you want to know about Failure Mode and Effect Analysis, internet: http://www.fmeainfocentre.com/ Arnold, H.: What HR can learn from the successes of easyJet, eBay and Amazon, Umantis Hr Solutions, 2006, Barcelona Personální informační systém Vema, internet: http://www.vema.cz/default.aspx Personální informační systém Odysea 2001, internet: http://www.asei.cz/produkty-odysea.htm Personální informační systém Elanor, internet: http://www.elanor.cz/
56
[41]
[42] [43]
Modul pro Personalistiku SAP ERP, internet: http://help.sap.com/saphelp_46c/helpdata/en/b7/c447ed9d5411d189b60000e829fbbd/co ntent.htm Stehlík, R.: Personální činnosti, Seminárky.cz, internet Stýblo, J.: Budoucí směry rozvoje podnikového lidského kapitálu, Česká manažerská asociace, internet
6.2 Ostatní zdroje
Maasen, Schoenen, Frick, Gadatsch: SAP R/3 kompletní průvodce, Computer Press 2007, Brno Kolektiv autorů: BC480 Creating PDF-Based Print Forms Using the Interactive Forms Solution Participant Handbook (elektronické školení), SAP AG Germany, 2005, internet Král J., Demner J.: Softwarové inženýrství, Academia, Praha, 1991 Rickayzen, A.: User Interfaces Made Easy: How to Design Forms-Based Processes in Manager SelfServices (MSS), SAPinsider, SAP AG, internet Pokorný, J.: Databázové systémy a jejich použití v informačních systémech, Academia, Praha, 1992 Molnár, Z.: Moderní metody řízení informačních systémů, Grada, Praha, 1992 Široký, J.: Informační systémy, internet: http://homen.vsb.cz/~s1i95/ISVDAS/is/IS_uvod.htm SAP Web Application Server, Wikipedia, internet: http://en.wikipedia.org/wiki/SAP_Web_Application_Server Waloszek, G.: Have You Ever Heard of Performance-Oriented (UI) Design?, SAP User Experience, SAP AG, 2008 Informační systémy, Wikipedia, internet: http://cs.wikipedia.org/wiki/Informa%C4%8Dn%C3%AD_syst%C3%A9m ABAP R/4, Wikipedia, internet: http://en.wikipedia.org/wiki/ABAP Marghescu, D.: Usability Evaluation of Information Systems: A Review of Five International Standards, Department of IT, Turku Centre for Computer Science, Åbo Akademi University Kolektiv autorů: Adobe Document Services Configuration Guide, 2007, SAP AG, internet: https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/30a9630b-4f89-2a10-6fabe311b3ffd9a6
57
7 Přílohy Tabulka č. 18: Ohodnocení požadavků uživatelů v systému A Kritérium Výklad hodnotícího kritéria
Personalisté společnost A
Manažeři společnost A
Jaká je současná úroveň IT odbornosti? Jaká je možnost proškolení práce s IS? Jaké jsou nároky na dostupnost a kvalitu nápovědy při práci s IS (pořizování a zpracování dat)?
Střední Střední Vysoké
Nízká Nízká Nízké
Jaká je ochota společnosti investovat do nových licencí umožňujících práci s IS? Jaká je ochota společnosti investovat do přizpůsobení IS potřebám a požadavkům této skupiny uživatelů?
Průměrná
Průměrná
Nízká
Nízká
Jaká je ochota společnosti investovat do vývoje IS, tak aby lépe vyhovoval potřebám a požadavkům této skupiny uživatelů?
Nízká
Nízká
Automatizace při pořizování dat Frekvence pořizování dat Objem pořizovaných dat Počet ovladačů při pořízení dat
Jaká je potřeba automatizovat dílčí úlohy při pořizování dat pro uživatele dané skupiny? Jak často uživatel dané skupiny potřebuje pořizovat data? Jaký objem uživatelem pořizovaných dat při řešení jedné elementární úlohy? Jaká je potřeba uživatelů dané skupiny používat při pořizování dat do IS více nebo méně "ovladačů"?
Nízká
Nízká
Pravidelně
Nepravidelně
Velký
Průměrný
Průměrná
Nízká
11
Počet souvisejících operací
Jaká je schopnost uživatelů využívat další operace související s pořízením (zejména předzpracováním) dat?
Průměrná
Nízký
12
(ne)Linearita pořizování dat
Jaká je schopnost uživatelů dané skupiny pracovat při pořizování dat do IS ne-lineárně?
Průměrná
Lineární
13
Ochrana proti chybám
Jaká je potřeba chránit uživatele, aby nepořídil chybná data?
Vysoká
Vysoká
Poč. gramotnost 1 2 3
Odbornost Školení Nápověda
4
Finance Licence
5
Náklady na přizpůsobení
6
Náklady na vývoj
Rutinní provoz 7 8 9 10
58
Tabulka č. 19: Ohodnocení rozhraní dostupných v systému A Kritérium
Výklad hodnotícího kritéria
Non-SAP klient
Jaké jsou požadavky na odbornost IT pro práci v daném UI? Jaké jsou nároky na zaškolení pro práci s daným UI? Jak kvalitní je nápověda pro práci s daným UI?
Průměrné
Jaká je cena licencí umožňujících práci s daným UI? Jaké jsou finanční náklady na přizpůsobení daného UI individuálním požadavkům uživatelů? Jaké jsou finanční náklady na vývoj dle specifických požadavků uživatelů?
Střední
Jaké jsou možnosti daného UI automatizovat dílčí úlohy při pořizování dat?
Nízké
Pro jakou frekvenci práce je UI vhodné
Pravidelně
Pro jaký objem pořizovaných dat je UI nejlépe přizpůsobeno? Kolik souvisejících operací při pořízení dat může systém nabídnout? S jakým množstvím ovladačů je nutno při pořizování dat pracovat? Jak je UI vhodné pro složitější než lineární (odshora dolů nebo zleva doprava) organizování pořízení dat? Jaká je schopnost UI chránit uživatele před chybným pořízením dat?
Velký
Poč. gramotnost 1
Odbornost
2
Školení
3
Nápověda Finance Licence
4 5
Náklady na přizpůsobení
6
Náklady na vývoj
7
Rutinní provoz Automatizace při pořizování dat
8 9 10 11 12
13
Frekvence pořizování dat Objem pořizovaných dat Počet ovladačů při pořízení dat Počet souvis. operací (ne)Linearita pořizování dat Ochrana proti chybám
59
Průměrné Průměrné
Vysoké
Vysoké
Vysoký Vysoký Zanořující
Vysoká
Tabulka č. 20: Ohodnocení požadavků uživatelů v systému B Kritérium Výklad hodnotícího kritéria
Personalisté společnost B
Manažeři společnost B
Zaměstnanci společnost B
Jaká je současná úroveň IT odbornosti? Jaká je možnost proškolení práce s IS? Jaké jsou nároky na dostupnost a kvalitu nápovědy při práci s IS (pořizování a zpracování dat)?
Vysoká Vysoká Vysoká
Střední Vysoká Střední
Malá Malá Malá
Jaká je ochota společnosti investovat do nových licencí umožňujících práci s IS? Jaká je ochota společnosti investovat do přizpůsobení IS potřebám a požadavkům této skupiny uživatelů? Jaká je ochota společnosti investovat do vývoje IS, tak aby lépe vyhovoval potřebám a požadavkům této skupiny uživatelů?
Vysoká
Vysoká
Průměrná
Průměrná
Průměrná
Průměrná
Nízká
Nízká
Nízká
Jaká je potřeba automatizovat dílčí úlohy při pořizování dat pro uživatele dané skupiny? Jak často uživatel dané skupiny potřebuje pořizovat data? Jaký objem uživatelem pořizovaných dat při řešení jedné elementární úlohy? Jaká je potřeba uživatelů dané skupiny používat při pořizování dat do IS více nebo méně "ovladačů"? Jaká je schopnost uživatelů využívat další operace související s pořízením (zejména předzpracováním) dat?
Vysoká
Vysoká
Nízká
Pravidelně
Nepravidelně
Nárazově
Velký
Průměrný
Malý
Vysoký
Průměrný
Nízká
Vysoký
Průměrný
Nízká
Jaká je schopnost uživatelů dané skupiny pracovat při pořizování dat do IS nelineárně? Jaká je potřeba chránit uživatele, aby nepořídil chybná data?
Zanořující
Průměrná
Lineární
Vysoká
Průměrná
Nízká
Poč. gramotnost 1 2 3
Odbornost Školení Nápověda
4
Finance Licence
5
Náklady na přizpůsobení
6
Náklady na vývoj
Rutinní provoz 7
Automatizace při pořizování dat
8
Frekvence pořizování dat Objem pořizovaných dat Počet ovladačů při pořízení dat
9 10
11
Počet souvisejících operací
12
(ne)Linearita pořizování dat
13
Ochrana proti chybám
60
