ZADANI BANELARSKE PRACE. ipsrce vvsox6 ucnni TECHNTcKE v Pnazn Faxulre rnformacnich rncnnolocri

ipsrcE vvsox6 ucnni TECHNTcKE v Pnazn Faxulre rNFoRMacNicH rncnNolocri

ZADANIBANELARSKEPRACE Informainf syst6m pro grafick€ a webdesignov6studio

N6zev: Student:

Adam BiiiStE

Vedoucf:

Ing. Pavel Ndplava

Studijniprogram:

Informatika

Studijnf

obor:

Katedra: Platnost

Web a multim6dia (bakal6islcj) Katedra sofbwarovdho inZenfrstvi

zad6nf:

do konce letnfho semestru 20L2/L3

Pokyny pro vypracovdnf Provedte anal!,zuprocesri, probl6mfi a aktudlnf situace vybran6ho grafick6ho a web designov6ho studia. Na z6,klad1anal'fzy navrhndte informadnf syst6m, kterf bude podporovat ifzenf firmy, komunikaci se zS,kaznikya vlastni vlivoj produktfi. Zam6ite se piedev5im na ndvrh uZivatelsk6horozhra.ni.V zS,v6ruprdce provedte alespohz6kladni vyhodnocenf piinosri a n6.kladri na zavedenfsyst6mu. Seznam odborn6 literatury Dod6. vedouci pr6ce

'"''g'*/"/${ l:

';

r:'

tl r

T.C u r .9 . L:,: '

Ing. Michal Valenta, Ph.D, vedoucikatedry

i .,..:,.

"i,.' '"'..-.

.:'

:

{r ti

/

i ti t

ll/ttt , {/ { /YL"\-/ f f 1i"dt \-"\prof. Ing. Pavel TVrdik, CSc. ddkan

V Praze dne 11. dubna 2012

/

České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství

Bakalářská práce

Informační systém pro grafické a webdesignové studio Adam BIČIŠTĚ

Vedoucí práce: Ing. Pavel Náplava

16. května 2012

Poděkování Rád bych poděkoval všem, kteří byli jakkoli nápomocni při tvorbě této bakalářské práce. Především děkuji vedoucímu práce Ing. Pavlu Náplavovi za věcné připomínky, otevřený přístup a obecně velmi efektivní a odbornou spolupráci. Děkuji také kolegům Vladimíru Kovářovi a Michalu Deckerovi za jejich názory a konzultace nad návrhem systému.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.

V Praze dne 16. května 2012

..................... 7

České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Adam BIČIŠTĚ. Všechna práva vyhrazena.

Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Adam BIČIŠTĚ. Informační systém pro grafické a webdesignové studio: Bakalářská práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

Abstract This bachelor’s thesis deals with the design of an information system for a particular company - graphic and webdesign studio. First of all, the current situation of the company is assesesed and focused on weaknesses in its management system. Furthermore, an analysis is made and an appropriate solution is suggested. The design of the solution describes the basic structure and features of the system. Then it talks mainly about user interface. The conclusion contains an evaluation of the benefits for the company, including basic economic indicators. Keywords Information system, User interface, Environment interaction, Design, Company management, Webdesign.

Abstrakt Tato bakalářská práce se zabývá problematikou návrhu informačního systému pro konkrétní firmu – grafické a webdesignové studio. Nejdříve je zhodnocena současná situace firmy se zaměřením na nedostatky v oblasti systému pro řízení. Je provedena analýza, na základě které je navrženo vhodné řešení. 9

Samotný návrh popisuje strukturu a základní vlastnosti systému, dále se zaměřuje zejména na uživatelské rozhraní. Závěr práce obsahuje vyhodnocení přínosů systému pro společnost, včetně základních ekonomických parametrů. Klíčová slova Informační systém, uživatelské rozhraní, interakční prostředí, návrh, řízení firmy, webdesign.

10

Obsah Úvod 17 Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1 Představení společnosti 1.1 Obecná charakteristika . . . . . . . . . 1.2 Interní struktura firmy . . . . . . . . . 1.3 Firemní procesy . . . . . . . . . . . . . 1.4 SWOT analýza společnosti . . . . . . 1.5 Shrnutí současného stavu a doporučení

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

19 19 19 20 23 26

2 Návrh řešení 2.1 Souhrn obecných požadavků na systém . . . . 2.2 Analýza dostupných řešení vůči požadavkům 2.3 Rámcový návrh řešení . . . . . . . . . . . . . 2.4 Popis návrhu a základní vlastnosti systému . 2.5 Shrnutí navrhované koncepce . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

29 29 30 32 32 36

3 Specifikace platformy informačního systému 3.1 Struktura a základní logika systému . . . . . . . 3.2 Metodika vývoje a zavádění služeb do systému . 3.3 Uživatelské rozhraní systému . . . . . . . . . . . 3.4 Shrnutí klíčových vlastností navrhovaného řešení

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

37 37 39 41 50

4 Vyhodnocení přínosů 4.1 Náklady na vývoj . . . . . . . . . . . 4.2 Základní vyhodnocení investice . . . 4.3 Způsob a plánování vývoje . . . . . . 4.4 Celkové zhodnocení přínosů systému

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

53 53 55 56 57

11

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . .

. . . .

. . . .

Závěr

59

Literatura

61

A UML Diagramy

63

B Seznam použitých pojmů a zkratek

67

C Obsah přiloženého CD

69

12

Seznam obrázků 1.1

Znázornění interní struktury firmy . . . . . . . . . . . . . . . . . .

20

2.1 2.2 2.3

Diagram znázorňující obecný přístup k řešení nového systému. . . Struktura součástí navrhovaného řešení. . . . . . . . . . . . . . . . Využití principu architektury orientované na služby. . . . . . . . .

32 33 36

3.1 3.2 3.3

Diagram hierarchie řízení práv. . . . . . . . . . . . . . . . . . . . . Uživatelské prostředí systému Unicorn Universe . . . . . . . . . . . Znázornění UI systému Unicorn Universe a jeho využití plochy pro obsah a podpůrné prvky. . . . . . . . . . . . . . . . . . . . . . . . . Koncept řešení uživatelského rozhraní. . . . . . . . . . . . . . . . . Wireframe - Základní layout uživatelského prostředí systému. . . . Wireframe - Uživatelské prostředí při otevřeném panelu. . . . . . . Hlavní ovládací panel a jeho prvky. . . . . . . . . . . . . . . . . . . Wireframe - Hlavní menu systému . . . . . . . . . . . . . . . . . . Wireframe - Notifikace . . . . . . . . . . . . . . . . . . . . . . . . . Wireframe - Zprávy . . . . . . . . . . . . . . . . . . . . . . . . . . Wireframe - Autorizovaní uživatelé . . . . . . . . . . . . . . . . . . Wireframe - Kalendář . . . . . . . . . . . . . . . . . . . . . . . . . Wireframe - Stav uživatele . . . . . . . . . . . . . . . . . . . . . . Sada Wireframů - Systémové nastavení. . . . . . . . . . . . . . . .

38 42

3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14

A.1 UML - Proces „Tvorba webové prezentace“ . . . . . . . . . . . . . A.2 UML - Proces „Realizace nového vizuálního stylu, příprava tiskových dat“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

43 45 45 46 47 47 48 48 49 49 50 51 64 65

Seznam tabulek 1.1 1.2

Výstupní tabulka SWOT analýzy . . . . . . . . . . . . . . . . . . . Zavedení systému v rámci SWOT analýzy . . . . . . . . . . . . . .

26 27

2.1

Přehled vybraných produktů a jejich srovnání vůči požadavkům. .

31

4.1 4.2

Odhadované náklady na vývoj platformy IS. . . . . . . . . . . . . . Odhadované náklady na vývoj služeb interního IS. . . . . . . . . .

54 55

15

Úvod Řízení podniku je založeno na správném systému sběru, uchování a distribuce informací. Informační systémy, ať již v jakémkoli provedení, rozsahu a záběru, jsou proto základním nástorojem řízení organizací.(8) Bakalářská práce se zaměřuje na konkrétní firmu, která vykazuje nedostatky právě v oblasti systematizace řízení a zavedení informačního systému se jeví jako logický krok. Cílem je navrhnout na základě analýzy současné situace vhodné řešení. Vzhledem k rozsahu problematiky návrhu takovéhoto informačního systému, bylo zadání zúženo na rámcový návrh řešení se zaměřením na uživatelské rozhraní. Návrh je koncipován pro internetový systém, resp. systém zpřístupněný přes webový prohlížeč. Cílem není detailní návrh struktury, architektury či implementačních specifik, nýbrž koncept řešení obohacen o provedení interakčního prostředí systému. Z vlastní zkušenosti mohu říci, že robustní informační systémy, ať již webového či desktopového provedení, obecně často trpí uživatelsky velmi nepřívětivým prostředím. Oblastem uživatelského rozhraní a obecně UX (Userexperience)1 se přikládá proto stále větší důležitost. Počítačové systémy dávno nejsou určeny jen školeným odborníkům, ale měly by být snadno použitelné prakticky kýmkoli. Uživatelská rozhraní spotřebních zařízení či aplikací se proto v současnosti velmi rychle mění. Pozorovat lze jednoznačně snahu dosahovat maximální jednoduchosti a zároveň intuitivnosti prostředí.(3) Tento trend již pomaleji proniká do oblastí rozsáhlých korporátních systémů, které jakoby byly právě rozsahem svých funkčností předurčeny k netriviálnímu až nepřívětivému uživatelskému rozhraní. Mým cílem bylo navrhnout rozhraní takovým způsobem, aby poskytovalo robustní řešení, a to zároveň co nejjednodušší a maximálně intuitivní formou. Při návrhu jsem vycházel ze současných trendů uživatelských rozhraní, vlastních zkušeností a obsahu 1 User experience (UX), v češtině také Uživatelský prožitek, je podle definice normy ISO 9241-210 vnímání a způsob reagování plynoucí z použití určitého produktu či služby. (18)

17

Úvod vybraných předmětů absolvovaných ve škole.2 Inspiroval jsem se také současným vývojem UI na mobilních platformách. Snažil jsem se navrhout takové rozhraní, aby bylo velmi jednoduše pochopitelné, interaktivní a pro uživatele přitažlivé.

Motivace Tuto práci jsem si vybral zejména z důvodu, že řešená problematika je náplní mé praxe, a jsem spoluzakladatelem firmy, na kterou se práce zaměřuje. Mým dlouhodobým úkolem je ve firmě řešit právě současnou absenci jednotného systému a jeho provázání na obchodní model firmy. Všechny tyto oblasti jsou v práci rozebírány. Klíčový je pro mě pak samotný návrh uživatelského rozhraní, protože jsem přesvědčen, že i systémy těchto typů lze vytvářet tak, aby jejich použití bylo atraktivní a zábavné. Webové provedení a návrh UI má také přímou vazbu na můj studijní obor – Web a multimédia.

Struktura práce Práce je členěna podle logické posloupnosti činností prováděných za účelem sestavení relevantního návrhu. V prvé řadě je představena společnost, její struktura, procesy a na základě analýzy je zhodnocen její současný stav. Z toho vyplývající souhrn požadavků, je pak základním podkladem pro návrh konceptu řešení. Dále je rozpracována základní struktura a logika systému, princip řízení přístupových práv a způsob vývoje a provozu služeb systému. V další části se práce soustředí na návrh uživatelského rozhraní. Na závěr je provedena úvaha nad výsledným přínosem a je vyhodnocena investice do navrhovaného řešení.

2

Jedná se jmenovitě o předměty Web a multimédia (BI-WMM), Tvorba webových aplikací (BI-TWA), Základy softwarového inženýrství (BI-ZSI), Tvorba informačních systémů (BI-TIS) a Tvorba uživatelského rozhraní (BI-TUR)

18

Kapitola

Představení společnosti 1.1

Obecná charakteristika

Grafické a webdesignové studio Wavevision s.r.o. se formuje od roku 2005. Primární produkci tvoří realizace nových vizuálních stylů včetně grafického zpracování nejrůznějších tiskovin. Vedle grafických prací je pak zásadní vývoj webových stránek a individuálních internetových aplikací na zakázku. V současnosti tvoří cca 70% obratu právě vývoj webů a aplikací.3 Jedná se o malou firmu (6 – 8 zaměstnanců + několik externích spolupracovníků). V současnosti jsou hlavními klienty malé firmy či fyzické osoby. Pro klienty z řad větších firem jsou běžné spíše dílčí práce. Společnost v současné době řeší především nedostatečně dynamický růst a málo pružné reakce na změny charakteru a množství poptávaných služeb. Cílem je zvýšit kapacitu a produkci v současném segmentu. Dlouhodobým cílem je pak zvýšit profesionalitu nabízených služeb a získat nové střední až velké korporátní klienty. Společnost vstoupila rychle na trh, v krátkém časovém intervalu vyrostla do současné podoby, ale nyní je dosažení těchto cílů omezováno nedostatečnou dynamikou.

1.2

Interní struktura firmy

Společnost se dělí na dvě základní části. První část, resp. pracovní úsek, zajišťuje Marketing a design. Reprezentuje jej kreativní a umělecký ředitel, který pod sebou zastřešuje jak grafické a webové designéry tak i návrháře uživatelského rozhraní. Druhým úsekem je pak Vývoj webů a software, který zastřešuje vývojový a IT ředitel. V rámci této části operují kodéři, vývojáři a testeři. Poslední úsek jsou Další služby, kam spadá např. zajištění tisku, fotografie, copywriting, webhostingové služby a ostatní doplňkové produkty. 3 Veškeré údaje o společnosti jsou prezentovány na základě poskytnutých interních dat firmy.

19

1

1. Představení společnosti

Obrázek 1.1: Znázornění interní struktury firmy

Tato část již nemá stanovenou strukturu a pro analýzu není důležitá, proto jí dále neuvažujeme. Jednotlivé role a funkce ve struktuře jsou vzhledem k nižšímu počtu zaměstnanců sdílené. Např. Webdesignér může zastávat zároveň roli UX Designera stejně jako vývojář roli kodéra. Alternativou je také zajištění kapacity od externích spolupracovníků. Dva základní úseky společnosti mezi sebou velmi aktivně spolupracují a zakázky jsou u většiny případů produkcí obou úseků. Např. vývoj webové prezentace začíná u grafických a webových návrhářů, následně se přesouvá ke kodérům a programátorům. Vzhledem k malé velikosti a zároveň provázanosti úseků spadá řízení veškerých činností, ať již produkčních, obchodních či strategických, pod jednu řídící jednotku – vedení společnosti. Strukturu firmy zobrazuje obrázek 1.1.

1.3

Firemní procesy

Základní produkci a nejvýznamější podíl na zisku firmy představují dvě základní činnosti. Jedná se o Tvorbu webové prezentace a Realizaci nového vizuálního stylu včetně přípravy tiskových dat. Zmíněné činnosti fungují procesně a je tedy možné tyto primární procesy popsat a modelovat. Veškeré ostatní činnosti a to zejména obchodní činnosti, kontrola, plánování, řízení lidských zdrojů a znalostí jsou prováděny operativně dle aktuální 20

1.3. Firemní procesy potřeby. Nemá proto význam je v současnosti popisovat procesně.

1.3.1

Popis procesně řízených činností firmy

Popis procesu: Tvorba webové prezentace Uvažujeme běžné zadání na návrh a realizaci kreativně zpracované webové prezentace. Proces není omezen pouze na jednoduché webové prezentace, ale popisuje i vývoj složitějších internetových aplikací. V případě tohoto procesu jsou zapojeny oba úseky firmy, jak Marketing a design, tak Web a software. Po zpracování požadavku je třeba analyzovat zadání a potřeby zákazníka a sumarizovat veškeré informace, které definují cíl nové webové prezentace či aplikace. Následně úsek designu navrhuje uživatelské rozhraní a jeho grafické zpracování. Po odsouhlasení grafiky jsou připraveny podklady pro kódování. Úsek webů následně zajistí kompletní realizaci a nasazení do provozu. 1. Zpracování nového požadavku zákazníka. 2. Sestavení specifikace a cenové nabídky. 3. Odsouhlasení specifikace a cenové nabídky zákazníkem. 4. Příprava návrhu uživatelského rozhraní, WireFrames. 5. Podle rozsahu a charakteru zakázky příprava prototypu. 6. Podle rozsahu a charakteru zakázky uživatelské testování prototypu, zpracování výstupů a případná úprava uživatelského rozhraní. 7. Předání podkladů grafikovi a tvorba grafického návrhu uživatelského rozhraní. 8. Odsouhlasení grafického návrhu zákazníkem. 9. Připravení a kompletace grafických podkladů ke kódování a programování. 10. Kódování a programování (kódování a programování může běžet za určitých podmínek paralelně). 11. Testování a ladění. 12. Prezentace zákazníkovi. 13. Zpracování případných připomínek zákazníka. 14. Nasazení webové prezentace. UML4 diagram znázorňující proces viz. příloha A.1. 4 UML (Unified Modeling Language) je v softwarovém inženýrství grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů. (17)

21

1. Představení společnosti Popis procesu: Realizace nového vizuálního stylu, příprava tiskových dat Jedná se o proces nad komplexní službou v úseku Marketingu a designu. Zákazník přichází s požadavkem tvorby buď zcela nové vizuální komunikace pro nový projekt či obchodní aktivitu, nebo redesign současného vizuálu. Taková služba v prvním kroku zahrnuje analýzu potřeb zákazníka a jeho zadání. Je nutné sumarizovat a stanovit veškerá vstupní data a informace, aby vytvářený vizuál plnil správně svou funkci. Po přípravách následuje navrhování konceptu, proces odsouhlasování a připomínkování, tvorba grafického manuálu a případně také příprava konkrétních materiálů k tisku. 1. Zpracování nového požadavku zákazníka. 2. Sestavení specifikace a cenové nabídky. 3. Odsouhlasení specifikace a cenové nabídky zákazníkem. 4. Příprava návrhu uživatelského rozhraní, WireFrames. 5. Podle rozsahu a charakteru zakázky příprava prototypu. 6. Podle rozsahu a charakteru zakázky uživatelské testování prototypu, zpracování výstupů a případná úprava uživatelského rozhraní. 7. Předání podkladů grafikovi a tvorba grafického návrhu uživatelského rozhraní. 8. Odsouhlasení grafického návrhu zákazníkem. 9. Připravení a kompletace grafických podkladů ke kódování a programování. 10. Kódování a programování (kódování a programování může běžet za určitých podmínek paralelně). 11. Testování a ladění. 12. Prezentace zákazníkovi. 13. Zpracování případných připomínek zákazníka. 14. Nasazení webové prezentace. UML4 diagram znázorňující proces viz. příloha A.2. 22

1.4. SWOT analýza společnosti

1.4

SWOT analýza společnosti

Aby bylo možné lépe definovat konkrétní problémy společnosti, byla provedena SWOT analýza.5 Na jejím základě bude postaven vhodný způsob řešení. Současná situace neumožňuje stabilně rozšiřovat kapacity, je obtížné přijímat větší zakázky a udržet tak potřebnou dynamiku firmy. Již z úvodních informací vyplývá, že problémem nejsou samotné produkční a vývojové činnosti, které jsou procesně dobře zavedeny, ale pravděpodobně nesystémové řízení souvisejících či podpůrných činností, a to zejména v oblastech obchodu, plánování a lidských zdrojů. Aby bylo možné problematiku současné situace lépe popsat, zaměřil jsem se podrobněji na jednotlivé části SWOT analýzy.

1.4.1

Silné stránky (Strengths)

Flexibilní struktura firmy Firma má jednoduchou strukturu, která umožňuje flexibilně přizpůsobovat způsob řízení a organizace práce. Je tak možné poměrně rychle a nenáročně zavádět nové systémy či metodiky řízení. Procesně zavedené primární činnosti firmy Dvě procesně řízené čínnosti, které vytváří hlavní produkci a zisk firmy (viz. sekce 1.3.1), dlouhodobě nevykazují neefektivitu či jiné problémy. Procesy jsou z hlediska produkce i obchodu dobře nastaveny a zavedeny. Kvalita produktů Firma řeší minimum reklamací a zpětná vazba od klientů je pozitivní. Doposud nebyla zaznamenána ztráta klientů. Daří se tak dlouhodobě udržovat vysokou kvalitu poskytovaných služeb. Oblast financí Společnost je finančně dlouhodobě zdravá a není zatížena úvěry, což lze považovat za silnou stránku. Technické zázemí Počítačová infrastruktura a celkové technické zázemí firmy je vyhovující. Na velikost společnosti lze spíše hovořit o nadstandardním zázemí, které umožňuje v tomto ohledu bezproblémový růst.6 5 SWOT analýza je metoda, jejíž pomocí je možno identifikovat silné (ang: Strengths) a slabé (ang: Weaknesses) stránky, příležitosti (ang: Opportunities) a hrozby (ang: Threats), spojené s určitým projektem, typem podnikání, podnikatelským záměrem, apod. (16) 6 Společnost provozuje vlastní webový, databázový a e-mailový server v datacentru se značnou výkonovou rezervou. V kancelářích je pak zálohový, testovací a datový server.

23


1.4.2

Slabé stránky (Weaknesses)

Systém pro řízení činností, kontrolu či plánování Řízení činností v oblasti obchodu, kontroly, plánování, lidských zdrojů či znalostí, je zásadní pro stabilní růst.(5) Tyto činnosti a jejich řízení ve firmě nejsou podporovány žádnými systémovými nástroji a operativní přístup k jejich vykonávání je zdrojem neefektivity produkce. Toto negativně ovlivňuje výkon firmy, čímž často znemožňuje příjem rozsáhlejších zakázek. Obecně je růst za takovéhoto stavu problematický. Řešení této situace je proto klíčovou podmínkou pro dosažení dynamického růstu společnosti. Finanční nestabilita Přesto, že firma není zatížena úvěry, potýká se zejména s problematickou ziskovostí projektů a zakázek. Zároveň s ohledem na svou velikost vykazuje poměrně vysoké provozní a režijní náklady. Ty jsou tvořeny zejména náklady na provoz a údržbu infrastruktury, nájemným či náklady na účetní servis. Dlouhodobě tak firma není schopná vytvářet dostatečnou finanční rezervu a stabilně vykazovat uspokojivý zisk. Omezený finanční kapitál následně neumožňuje adekvátní rozvoj a investice. Nesystémová komunikace se zákazníky Byla identifikována potřeba nástroje pro řízení a zároveň zprostředkování komunikace se zákazníky. Ta probíhá nyní zpravidla e-mailem či telefonicky. Zákazník nemá možnost nikde sledovat průběh prací na jeho projektu. Výstupy jsou pak zákazníkovi opět zasílány e-mailem, stejně jako zákazníkovo připomínky či podklady z jeho strany. Absence jednotné a efektivní vývojové platformy Mezera je pozorována také v absenci jednotné vývojové platformy pro webové aplikace. Ve firmě bylo vyvinuto již mnoho různých řešení, ale prakticky u každé zakázky se vyvíjí vše znovu. Drtivá většina produkovaných webových aplikací vyžaduje navíc webové administrační prostředí a u většiny případů není zejména díky individuálnímu přístupu možné nasadit volně dostupné redakční systémy. Pro takovéto aplikace se tedy vždy vyvíjí administrační rozhraní na míru od základů i přesto, že by bylo možné stavět na hotových komponentách a jednotném systému.

1.4.3

Příležitosti (Opportunities)

Situace na trhu Jak na základě obchodních aktivit, tak přímých referencí firmy, je poměrně vysoký předpoklad možností zisku nových zakázek. 24

1.4. SWOT analýza společnosti Pokud bychom se podívali obecně na současnou situaci na trhu, podle přední analytické společnosti IDC výdaje na IT v České republice v roce 2011 poklesly v porovnání s předchozím rokem o 2,6% na 5,12 miliard USD. Zatímco výdaje na software a IT služby mírně vzrostly. Trh v oblasti marketingu, IT služeb a zejména software je v České republice mimo dočasné výkyvy dlouhodobě rostoucí a jeho další růst lze předpokládat i do budoucna.(23) Z dlouhodobého hlediska je možné kalkulovat se spíše rostoucí tendencí počtu nových obchodních příležitostí. Obchodní situace firmy a její postavení na trhu jsou příznivé. Možnosti rozšíření portfolia služeb Firma má možnosti rozšiřovat produkty zejména v oblasti servisních a paušálních služeb. Výslovně aktuální je rozvoj trhu v oblasti „Software as a service“ produktů(15) a je tedy vhodné do této oblasti rozšířit produktové portfolio. Jak bylo zmíněno, firma dodává k webovým aplikacím často administrační řešení. V případě vývoje jednotné platformy se jeví jako vhodná příležitost zavést vlastní řešení individuálních redakčních a administračních systémů, které následně poskytovat jako službu.

1.4.4

Hrozby (Threats)

Nezvládnutí poptávky zákazníků a jejich odchod Za současných kapacit nelze přijímat rozsáhlejší projekty a zakázky. Rozšiřování kapacit je problematické (viz. sekce 1.4.2). Toto může v případě rostoucích požadavků od současných zákazníků znamenat jejich odchod. Konkurence velkých či stabilních firem Na trhu je v oblasti IT a Marketingu velmi silná konkurence. U velkých, ale i u menších stabilních společností hrozí pro firmu obtížně dosažitelná technologická vyspělost. Zároveň díky finančnímu kapitálu mohou silnější konkurenti rychleji vstupovat na nové trhy a omezovat tak nové příležitosti.

1.4.5

Souhrný výstup SWOT analýzy

Klíčové závěry analýzy jsou shrnuty v tabulce 1.1.

25


Tabulka 1.1: Výstupní tabulka SWOT analýzy

1.5

Shrnutí současného stavu a doporučení

Z provedené SWOT analýzy vyplývá několik zásadních skutečností. Z hlediska obchodu a situace na trhu je společnost v dobré pozici. Při dalším rozvoji může stavět na základní produkci, která je procesně řízena a tyto primární procesy jsou zavedeny dobře. Jednoduchá a flexibilní struktura společnosti umožňuje efektivně zavádět nové systémy a metodiky řízení. Zásadním problémem je zcela nesystémové operativní řízení souvisejících a podpůrných činností. Obecně chybí systém pro efektivní a přehledné řízení činností v oblasti obchodu, kontroly, plánování, lidských zdrojů či řízení znalostí. To je klíčový problém zamezující příjmu větších zakázek, rozšiřování kapacit a vůbec větší dynamice firmy. Tato situace se pak nebezpečně promítá do hrozby odchodu zákazníků, vzhledem k neschopnosti pokrýt jejich rostoucí poptávku. Pro komplexní řešení situace je navrhován vývoj nového informačního systému. Ten bude ve smyslu minimalizace slabých stránek a maximalizace příležitostí řešit absenci řídícího systému i vývojové platformy. Stane se zároveň součástí produktového portfolia a jako vedlejší efekt tak umožní využít sledované příležitosti na trhu v oblasti "Software as a service"produktů. Shrnutí přínosů individuálního informačního systému: • Zavedení systému jako nástroje pro řízení, kontrolu a plánování. • Zajištění přehledu a organizace veškerých činností firmy.

26

1.5. Shrnutí současného stavu a doporučení

Tabulka 1.2: Zavedení systému v rámci SWOT analýzy

• Možnost implementace modulu pro komunikaci se zákazníky eliminuje současnou neefektivitu v této oblasti. • Systém umožní vývoj a provoz administračních systémů či libovolných webových aplikací, čímž odstraní současnou absenci jednotné vývojové platformy. • Provoz administračních systémů bude nabízen jako služba, čímž se rozšíří produktové portfolio. Předpokládaný efekt v návaznosti na SWOT analýzu znázorňuje tabulka 1.2. Červeně jsou zde vyznačeny potlačené či zcela eliminované body, zeleně naopak nové či maximalizované. V tabulce je patrné zejména potlačení většiny slabých stránek a jejich přeměna na silné stránky. Zároveň jsou díky systému maximalizovány veškeré sledované příležitosti. Hrozbu konkurence nelze systémem přímo eliminovat, stejně jako nelze přímo řešit současnou situaci nízkého finančního kapitálu firmy.

27

Kapitola

Návrh řešení Navrhovaný informační systém (dále jen systém) bude zcela specifickým a individuálně vyvíjeným softwarem. Na základě provedené analýzy existujících řešení bylo uznáno za vhodné vyvinout vlastní systém. Důvodem je zejména fakt, že dostupné systémy neumožňují zkombinovat provoz interního IS s možností poskytovat administrační systémy jako službu (viz. sekce 2.2). Zároveň v takovém případě odpadá možnost vlastní vývojové platformy. Musel by tak vzniknout soubor více systémů, který by požadavky pokryl, což není žádoucí. Hlavním cílem je dosáhnout maximálně jednoduchého a univerzálního řešení, na ktérém bude moci firma dlouhodobě stavět. Návrh se nejdříve zaměřuje na obecný popis principu řešení a specifikaci základních vlastností navrhovaného systému. Dále jsou popsány veškeré součásti řešení a způsoby vývoje či provozu služeb v rámci systému.

2.1

Souhrn obecných požadavků na systém

Požadavky lze logicky seskupit do třech pilířů. Provoz interního informačního a komunikačního systému Firma potřebuje na míru řešený informační systém, který bude jednak podporovat řízení v rámci specifického prostředí firmy, tak komunikaci se zákazníky. Tím je myšlen provoz služeb zajišťující např. projektový management, znalostní bázi, správu finančních výkazů, fakturaci, apod. Pro podporu komunikace se zákazníky je žádoucí možnost zřízení speciálního rozhraní, přes které by mohli zákazníci sledovat průběh projektů, zadávat požadavky či poskytovat podklady. Obecně by měl být systém modulární a mělo by být kdykoli možné funkčnosti a využití systému rozšiřovat.

29

2

2. Návrh řešení Vytvoření firemní vývojové platformy Je požadováno vytvoření vývojové platformy, která umožní zejména efektivně vyvíjet back-end7 webovým aplikacím a jednoduše stavět individuální administrační a redakční systémy. Princip využití takové platformy bude vysvětlen dále. Poskytování administračních a redakčních systémů jako službu Administrační rozhraní pro vyvíjené klientské aplikace a systémy musí být umožněno snadno provozovat pro různé skupiny uživatelů a tento provoz licencovat, resp. poskytovat jako službu.

2.2

Analýza dostupných řešení vůči požadavkům

Vedle možnosti vytvářet nový systém se nabízí možnost využít dostupné řešení na trhu. Pokud bychom však uvažovali možnosti českých i zahraničních produktů v oblasti informačních systémů, nebyli bychom schopni jedním produktem zajistit ani většinu požadovaných přínosů systému. Tento předpoklad byl ověřen na vybraných produktech, které jsou zejména na českém trhu známé a rozšířené. Bylo vycházeno z informací, které dané společnosti o svých produktech poskytují na webových stránkách. Vedle informačních systémů byly ověřeny stejným způsobem také možnosti známých redakčních systému. Výsledky podpory základních požadavků vybraných produktů shrnuje tabulka 2.1.8 Na trhu jsou jednoduše dostupná řešení pokrývající funkce informačního systému. Problematická je v této oblasti ale integrace individuálního řešení pro komunikaci s klienty. Řešení, přes které by mohli klienti odevzdávat požadavky a zároveň přijímat výstupy není zpravidla přímo podporované a vyžaduje náročnou customizaci. Vedle toho redakční systémy, které by teoreticky bylo možné přizpůsobit pro jejich poskytování jako službu, nepodporují funkčnosti informačních systémů. Vytvoření firemní vývojové platformy je pochopitelně od podstaty individuální záležitost. Tento požadavek nelze logicky splnit zavedením jakéhokoli dostupného řešení. Splnění tedy vyžaduje vývoj vlastního systému. 7 Back-end je označením pro výkonnou část aplikace. Vedle toho Front-end označuje rozhraní mezi uživatelem a výkonnou částí aplikace. (10) 8 Použité zdroje: http://www.helios.eu/ http://www.abra.eu/ http://unicornuniverse.eu/ http://www.sas.com/ http://wordpress.org/ http://www.drupal.cz/

30

2.2. Analýza dostupných řešení vůči požadavkům

Tabulka 2.1: Přehled vybraných produktů a jejich srovnání vůči požadavkům. Provoz interního informačního a komunikačního systému

Vytvoření firemní vývojové platformy

Poskytování administračních a redakčních systémů jako službu

Helios

Ano, ale bez přímé podpory funkce komunikace s klienty

Ne

Ne

ABRA Software

Ano, podpora komunikace s klienty pouze díky integraci e-mailových účtů

Ne

Ne

Unicorn Universe


Ne

Ne

SAS


Ne

Ne

Wordpress, Drupal, a jiné běžné redakční systémy

Ne

Ne

Teoreticky, nutnost přizpůsobit prostředí.

31

2. Návrh řešení

Obrázek 2.1: Diagram znázorňující obecný přístup k řešení nového systému.

Pokud bychom měli využít dostupná řešení, museli bychom zavádět samostatně Informační systém a zvlášť redakční systém, který bychom optimalizovali pro SaaS (Software as a service) model. Vývojovou platformu bychom museli v každém případě budovat individuálně. Takové řešení by bylo zcela neflexibilní. Jednotlivé systémy by zároveň vyžadovali rozsáhlou customizaci, což společně s násobenou náročností na jejich pochopení a zavedení výrazně snižuje efektivitu takovéhoto řešení. Tímto je tedy potvrzeno, že tvorba nového systému, který bude od základů vyvíjen tak, aby splnil veškeré požadavky, je v našem případě optimální.

2.3

Rámcový návrh řešení

Z rozdělení a logické organizace požadavků vyplývá, že pokud bude vytvořena optimální vývojová platforma, na které půjde stavět a provozovat různorodé služby, budou splněny všechny požadavky. Jinými slovy, cestou není vytvářet přímo specifický informační systém splňující nativně veškeré požadované funkce, ale vytvořit vhodně platformu informačního systému. Ta umožní provozovat jak interní informační a komunikační systémy, tak jakékoli externí řešení. Na platformě bude možné aplikace efektivně vyvíjet a následně jejich provoz poskytovat jako službu. Na obrázku 2.1 je pomocí jednoduchého diagramu znázorněn model řešení s ohledem na splnění všech hlavních požadavků.

2.4

Popis návrhu a základní vlastnosti systému

Navrhovaný systém musí bý vystavěn tak, aby nejen umožnil efektivní vývoj, ale zároveň kompletně zastřešil správu uživatelů a licencí, umožnil komunikaci mezi provozovanými službami (resp. aplikacemi), zajistil efektivní organizaci 32

2.4. Popis návrhu a základní vlastnosti systému

Obrázek 2.2: Struktura součástí navrhovaného řešení.

a agregaci informací pro uživatele a zároveň propojení mezi uživateli. Systém, jakožto platforma, tedy zahrne kompletně veškeré podpůrné služby informačního systému, které stojí nad samotnými výkonnými částmi,9 resp. službami či jejich celky. Samotnými výkonnými částmi pak mohou být jak informační systémy tak nejrůznější administrační rozhraní. Vše pak bude možné licencovat a poskytovat jako službu.

2.4.1

Základní součásti návrhovaného řešení

Celé řešení zahrnuje součásti od čistě technických, až po uživatelské či obchodní. Na základě stanovených principů a vztahů v systému, definici uživatelských rolí a práv a celé logické struktury systému je postavena jeho architektura. Na základě definované architektury je pak implementována platforma jako taková. Ta následně poskytuje zejména komplexní API pro vývoj aplikací a služeb do systému, dále definuje jednotné Uživatelské rozhraní a umožňuje při vývoji využívat hotové komponenty. Platforma zároveň zastřešuje správu uživatelských účtů včetně komplexního řízení uživatelských práv a rolí. Nakonec jsou součástí také podpůrné služby systému. Jedná se například o zprostředkování komunikace mezi uživateli, notifikační centrum či kalendář. Princip logického uspořádání součástí navrhovaného řešení zobrazuje diagram na obrázku 2.2. Dále uvádím přehled všech součástí, které obsahuje platforma systému. 9

Výkonnou částí je v tomto případě myšlena taková funkčnost systému, kterou jeho uživatel od systému očekává, či která ho motivuje k jeho použití. Může to být například aplikace pro fakturaci či komplexní služba projektového řízení. Naopak ne přímo výkonné části, které poskytuje platforma, slouží např. pro zprostředkování komunikace uživatelů v rámci systému, kalendář a další funkce, které ač mohou být pro uživatele důležité, nejsou jím vnímany jako primární.

33

2. Návrh řešení Aplikační rozhraní platformy (API) Rozhraní poskytuje veškerým službám vyvíjeným a provozovaných na systému přístup k platformě a jejím funkcím. Tím je myšlena komunikace s podpůrnými službami či využití nástrojů pro práci s uživatelskými účty. Uživatelské rozhraní (UI) Platforma pevně stanovuje uživatelské rozhraní, principy ovládání a navigace, včetně grafického provedení. U implementace služeb je možné proto využívat připravené šablony, případně rozhraní upravovat při dodržování stanovených zásad a pravidel. Komponenty Platforma poskytuje již hotové, globálně použitelné a parametrizovatelné komponenty, které může jednoduše využívat libovolná služba. Může se jednat např. o formulářové elementy (html editor, nahrání souboru,...), prvky uživatelského rozhraní (kontextové menu, dialogová okna,...) či komplexnější funkční součásti (tabulka pro výpis a editaci dat, správa fotogalerie,...). Uživatelská správa Kompletní řízení licencí, uživatelských účtů a jejich oprávnění zahrnuje také platforma. Podpůrné služby platformy Podpůrné služby reprezentují základní nástroje, které je možné v rámci systému unifikovat a poskytnout všem uživatelům. Přístup libovolných aplikací a výkonných služeb k těmto funkcím je zajištěn pomocí API. Mezi podpůrné služby patří: • Nastavení Každý uživatel má možnost nastavit si jednak své informace, provádět dostupné systémové nastavení a v případě, že je majitel licence, je mu umožněno spravovat v rámci licence uživatelské účty. • Autorizace uživatelů Předpokladem k tomu, aby mohli mezi sebou uživatele systému jakkoli interagovat, je jejich vzájemná autorizace. Systém zprostředkovává proces autorizace uživatelů a následně jejich správu. Služby systému mohou využívat autorizované uživatele a implementovat pak libovolné akce mezi uživateli. • Notifikace Systém poskytuje standardizovanou formu notifikací. Služby systému 34

2.4. Popis návrhu a základní vlastnosti systému tak mohou zasílat uživatelům libovolné informace či vyžadovat od uživatelů akce. Veškeré notifikace v systému jsou pak agregovány a přihlášenému uživateli přehledně prezentovány. • Kalendář Systémový kalendář centralizuje časově určená data z celého systému. Služby mohou posílat do kalendáře veškeré údaje, které jsou konkrétně časově určeny. • Zprávy Platforma obsahuje rozhraní pro jednoduché zasílání zpráv. Je podporováno zasílání zpráv více uživatelům a ke zprávám lze připojovat různé přílohy či odkazovat na součásti systému. • Přehled Sekce systému, která sdružuje klíčové informace z vybraných služeb systému. Každá služba může mít implementován tzv. Widget, což je v našem případě část aplikace, která stručně prezentuje její klíčové výstupy. Widgety v přehledu si může každý uživatel libovolně nastavovat a vytvářet si tak zcela personalizovanou sekci poskytující jemu relevantní přehled nad celým systémem.

2.4.2

Princip implementace výkonných služeb systému

Celý systém se řídí principy architektury orientované na služby (SOA).10 Platforma, se všemi svými součástmi, poskytuje prostor pro vývoj a provoz různorodých služeb. Jednotlivé služby systému představují dílčí funkčí celek či aplikaci. Může to být např. aplikace pro správu financí, fakturaci nebo aplikace pro projektové řízení. Skupiny těchto služeb pak mohou vytvářet komplexní informační systémy. Každá služba implementovaná na platformě jednak využívá její součásti, ale zároveň je sama o sobě stavěna tak, aby byla výkonnou součástí širšího systémového celku. Právě v duchu SOA tedy každá služba disponuje vlastním rozhraním, přes které poskytuje funkčnosti ostatním aplikacím a stejně tak sama může využívat pro svůj provoz ostatní služby. Princip je ilustrován obrázkem 2.3.

10

Service-oriented architecture (SOA) je soubor principů a metodologií pro návrh systémů a aplikací, které jsou tvořeny interoperabilními službami. Provázané služby, jakožto komponenty dílčích funkčností, pak vytváří komplexní systémy. (14)

35

2. Návrh řešení

Obrázek 2.3: Využití principu architektury orientované na služby.

2.5

Shrnutí navrhované koncepce

Na základě analýzy požadavků a zároveň dostupných řešení na trhu, bylo shledáno jako nejlepší řešení vývoj vlastního systému. Samotný koncept je pak postaven na požadavku realizace vývojové platformy, který se stává pro řešení klíčový. Vyplývá z něj, že není žádoucí vytvářet od základu rozsáhlý systém, který bude nativně splňovat veškeré požadavky. Je naopak optimální vytvořit univerzální platformu, která umožní právě takovýto systém následně efektivně vyvíjet, provozovat a využít také obchodně. Platforma bude částečně systém implementovat (zahrnuje UI, komponenty, uživatelskou správu či podpůrné služby systému) ale zejména vytvoří prostředí, v rámci kterého půjde velmi efektivně vyvíjet již konkrétní služby a ty případně dále provozovat jako službu. Tento model splňuje veškeré stanovené požadavky. Další kapitola se věnuje již konkrétním specifikům platformy a zaměřuje se na provedení systému a jeho uživatelské rozhraní.

36

Kapitola

Specifikace platformy informačního systému 3.1 3.1.1

Struktura a základní logika systému Licence, sektory a služby

Veškeré poskytované služby v systému jsou zastřešeny licencí. V rámci licence, která je individuálně parametrizována podle zákazníkovo požadavků, jsou k dispozici dané služby. Ty jsou provozovány v rámci jednotlivých skupin služeb, tzv. sektorů. Pod licencí lze vytvořit libovolné množství uživatelských účtů a provozovat libovolné množství sektorů a služeb. Zákazník si z pozice správce licence pak může vytvářet uživatelské účty a nastavovat jim oprávnění do vybraných služeb, resp. sektorů, které jsou v rámci licence k dispozici. Licence je základní obchodovatelná jednotka a je tedy klíčovým prvkem obchodního modelu systému. Licence zahrnuje určitý okruh funkčnosti a služeb poskytovaných v systému a poskytuje určitý počet uživatelů. Na základě těchto parametrů je pak určována cena za pořízení či její provoz. Aby bylo možné služby v systému poskytovat a spravovat v rámci logických celků, stojí mezi licencí a službami ještě sektor. Ten vymezuje určitý okruh služeb, které spolu logicky souvisí. Služby v sektoru tak vytvářejí širší funkční celek. Sektory mohou být určovány jak podle funkčností služeb, tak např. podle organizační struktury firmy. Sektory tedy vytvářejí komplexnější fukční jednotky či informační systémy. Příklad: Firma ABC má v systému jednak služby, které zajišťují redakční a administrační prostředí jejího webového portálu a zároveň účetní aplikace a služby pro podporu řízení. V rámci své licence provozuje tyto služby ve třech sektorech – Správa webu (tento sektor obsahuje služby zajišťující redakční a administrační systém webu), Účetnictví (tento sektor obsahuje účetní aplikace), Management (tento sektor obsahuje služby pro podporu řízení firmy).

37

3

3. Specifikace platformy informačního systému

Obrázek 3.1: Diagram hierarchie řízení práv.

Speciální případ sektoru je ještě tzv. osobní sektor. Ten může být poskytnut uživatelům, pokud jsou v rámci licence provozovány nejrůznější osobně využitelné služby. Může to být např. služba e-mailového klienta, sdílení dat, osobní poznámky či úkoly. Osobní sektor je narozdíl od běžných specifický tím, že je unikátní pro každého uživatele a je tak individuálně parametrizovatelný.

3.1.2

Řízení přístupových práv

Systém zastřešuje metodiku pro komplexní řízení uživatelských práv, která využívá hierarchii vycházející ze struktury systému. Práva mohou být proto řízeny na úrovni licencí, sektorů, služeb a konkrétních aktivit v rámci služby. Pro usnadnění řízení práv se aplikují uživatelské role, které zastřešují vždy určitou skupinu práv. Základní hierarchie je znázorněna na obrázku 3.1. Řídit práva napříč celou hierarchií je umožněno Správci licence. Ten určuje práva všem uživatelům v rámci licence a může řídit přístup na úrovni sektorů, služeb i aktivit. Zároveň může nastavovat sektorům či službám jejich správce. Správce sektoru má kontrolu nad řízením práv v rámci sektoru a níže. Může určovat správce služeb. Správce služby může řídit práva nad konkrétní službou a aktivitami. Nad touto základní hierarchií stojí ještě správce systému, což není nikdo jiný než provozovatel, resp. kompetentní osoba spravující systém.

Aktivity Aktivita identifikuje konkrétní požadavek či operaci v rámci služby. Ve struktuře služby, jakožto webové aplikace, je aktivita chápána jako vykonání konkrétního požadavku, případně signál či vytvoření komponenty. Příkladem takovéto akce může být zobrazení stránky, odeslání formuláře, apod. 38

3.2. Metodika vývoje a zavádění služeb do systému Uživatelské role Práva a jejich určení se dělí na explicitní a implicitní. Explicitní práva jsou ta, která jsou určena přímo podle výše uvedené hierarchie až na úroveň jednotlivých aktivit. Explicitní určení práv je však realizováno spíše při nestandardním nastavení či nutnosti specifického nastavení určitého oprávnění. Základní nastavení podléhá tzv. Implicitním právům – to jsou soubory práv (uživatelské role) definované např. na základě pozice uživatele ve struktuře organizace. Uživatelské role slouží pro komplexní definování práv v rámci celého systému, napříč celou hierarchií. Role jsou typicky určeny podle organizační struktury v reálném prostředí, tzn. např. obchodník, operátor, účetní,... Nadefinované role lze pak jednoduše přidávat konkrétním uživatelům. Tím jsou uživateli poskytnuta veškerá práva, která se k dané roli váží. Každý uživatel může mít více rolí a vedle těchto implicitních práv, lze každému uživateli určit práva explicitně, tzn. určit nezávisle například přístup do konkrétní aplikace či umožnit konkrétní aktivitu. Příklad: Jako uživatelské role mohou být například vytvořené „Účetní“, „Správce webu“, „Fakturant“ či „Ředitel“. Účetní bude mít definován přístup do sektoru „Účetnictví“, „Správce webu“ do sektoru pro správu webu, „Fakturant“ do sektoru „Účetnictví“ ale jen do vybraných služeb určených pro fakturaci a „Ředitel“ bude mít přístup do všech sektorů.

3.2 3.2.1

Metodika vývoje a zavádění služeb do systému Služba jakožto aplikace a její struktura

Každá služba v systému je implementována jako nezávislá aplikace, která je pouze zavedena do systému pomocí aplikačního rozhraní platformy. Tento model umožňuje zejména efektivní přizpůsobování aplikace či její redistribuci. Základní struktura aplikace • Výkonná část Zde jsou umístěny back-endové zdrojové kódy. Tato část pro uživatele není přímo dostupná. – Zdrojové soubory Veškeré zdrojové kódy všech vrstev aplikace. Jejich další struktura je odvislá od použité technologie. – Widget Každá aplikace obsahuje implementaci Widgetu, který je umístitelný na stránku přehledu. – Data Adresář pro uchování libovolných dat. 39

3. Specifikace platformy informačního systému • Veřejná část Zde jsou umístěny soubory front-endu, které jsou přímo přístupné uživateli. Mohou to být obrázky, CSS styly, Javascripty apod.

3.2.2

Princip vývoje aplikací

Součástí platformy je rozhraní pro vytvoření nových aplikací (resp. Služeb) do systému. Rozhraní automaticky připraví pro aplikaci základní sandbox (výchozí adresářová struktura), přidělí aplikaci ID a zavede jí do systému. Aplikační programátor má pak možnost ve vývojovém režimu aplikaci spouštět a testovat v prostředí systému.

Šablonový vývoj Klíčová vlastnost, která zajišťuje maximální efektivitu při vývoji koncepčně a funkčně podobných služeb, je možnost při založení nové aplikace zvolit určitou šablonu. Šablony jsou vytvářeny z libovolných aplikací, tzn. každá aplikace může být převedena do šablony. Při založení nové aplikace pak vývoj nezačíná u prázdného sandboxu, ale prakticky v různém stádiu dokončení aplikace. Příklad: Šablona může být např. aplikace pro správu článků webu. Při založení takovéto aplikace může vývoj znamenat pouze optimalizaci funkčních prvků šablonové aplikace. Ve chvíli, kdy je aplikace připravena k použití, může se připojit pod určitou licenci a nasadit do zvoleného sektoru.

3.2.3

Typy aplikací v systému

Podle způsobu nasazení se aplikace dělí do dvou základních skupin.

Obecná (unifikovaná) aplikace Je taková aplikace, která obsluhuje v jediné implementaci více nezávislých subjektů. Tzn. aplikaci pod jedním datovým úložištěm a jednou spuštěnou instancí využívá více uživatelů napříč sektory či licencemi. Typicky se jedná např. o aplikace osobních sektorů (poznámky, úkoly,...) kdy není nutné a ani žádoucí implementovat každému uživateli aplikaci individuálně. Největší výhodou takovýchto aplikací je jednoduchá distribuce uživatelům – stačí pouze nastavení aplikace do určitého sektoru, bez jakýchkoli nákladů na vývoj. Zároveň je pak snadné aplikaci udržovat – v případě opravy či vydání nové verze je aktualizace provedena jednoduše všem uživatelům. 40

3.3. Uživatelské rozhraní systému Specifické aplikace Pro běžné implementace služeb se typicky vyvíjí tzv. Specifické aplikace. Takové aplikace jsou implementovány čistě pro konkrétní použití v určitém sektoru. Aplikace je optimalizována svou vnitřní logikou a datovým úložištěm pro konkrétní použití. V případě potřeby jejího nasazení do jiného sektoru je tedy nutné aplikaci převést na šablonu a následně implementovat znovu jako specifickou.

3.3

Uživatelské rozhraní systému

Návrh uživatelského rozhraní se soustředí jednak na způsob vymezení prostoru pro rozhraní spuštěné služby (tzn. primárního obsahu systému). Zároveň pak na rozhraní veškerých funkcí a podpůrných služeb platformy.

3.3.1

Problémy rozhraní běžných IS a obecné trendy UI

Informační systém je zpravidla software poskytující velké množství informací a funkčností. Tato vlastnost je základním důvodem vzniku nepřehledných a příliš komplikovaných rozhraní. Jako podklad pro analýzu budeme uvažovat internetovou službu Unicorn Universe.11 Tato na trhu dostupná služba má s naším řešením mnoho společného – jedná se o flexibilní webový systém, který umožňuje provozovat libovolné informační systémy. Výchozí vzhled uživatelského rozhraní tohoto systému je zobrazen na obrázku 3.2. Rozhraní systému lze rozdělit podle obsahu a funkčních prvků na dvě základní skupiny: • Podpůrné prvky Jsou veškeré části systému, které v danou chvíli nepřináší uživateli užitek, kvůli kterému systém používá. Jsou to veškeré sekundární informace netýkající se přímo obsahu, navigační prvky, doplňkové funkčnosti systému, okolní grafické prvky. apod. • Obsah Jsou zobrazená data, informace či nástroje, které jsou pro uživatele v daný moment skutečně relevantní. Obsah je ta část rozhraní, která je důvodem proč uživatel systém používá. Pokud bychom na systému Unicorn Universe analyzovali uživatelské rozhraní vzhledem k poměru plochy věnované podpůrným prvkům a samotnému obsahu, zjistíme, že podpůrné prvky spolu s nevyužitou plochou okna prohlížeče zabírají průměrně až 56% plochy. Vedle toho pak zbývá pro samotný obsah pouze 44% plochy. 11

Zdroj informací a obrázků k systému Unicorn Universe: http://unicornuniverse.eu

41


Obrázek 3.2: Uživatelské prostředí systému Unicorn Universe

Na obrázku 3.3 můžeme vidět zobrazené rozhraní při velikosti okna prohlížeče 1280x800px. Šířka aktivní plochy systému je fixní, proto v případě většího rozlišení obrazovky nelze využít více prostoru po stranách. V tomto případě obsahuje prostor pro obsah 44% plochy a vzhledem k trendu vyšších rozlišení a širokoúhlých zobrazovacích zařízení (2) může být procento často ještě menší. Tento příklad je jednoduchou ilustrací současného problému většiny webových informačních systémů a obecně většiny robustnějších internetových aplikací či služeb. Systémy disponují množstvím funkcí a informací, které jsou uživateli zobrazeny 100% času práce se systémem. Uživatel je ale ve většině času práce vůbec nepotřebuje a jejich zobrazení je zcela zbytečné. Uživateli je podstatné zobrazit danou informaci vždy až ve chvíli, kde je pro něj relevantní. (22) (6)

42

3.3. Uživatelské rozhraní systému

Obrázek 3.3: Znázornění UI systému Unicorn Universe a jeho využití plochy pro obsah a podpůrné prvky.

Příklad: Uživatel nepotřebuje vidět kalendář, dokud v něm na dnešek nemá novou schůzku. Nepotřebuje vidět své úkoly, dokud nemá být upozorněn na nový úkol či blížící se termín odevzdání. (To samozřejmě neznamená nedostupnost možnosti zobrazit přehled událostí či úkolů v případě, kdy to uživatel vyžaduje.) V současnosti je jednoznačný trend budovat maximálně jednoduchá rozhraní, která jsou zaměřena právě na obsah. Tento směr je dán mimo jiné i masovým rozvojem mobilních zařízení, kde je klíčová právě jednoduchost rozhraní a zobrazení uživateli jen toho, co požaduje.(7) Návrh rozhraní by tak měl být maximálně přizpůsobivý různým zobrazovací plochám (tzv. Responsive design).(4) V tomto směru lze označit zejména velikostně fixované layouty12 za chybu, stejně jako pevně zobrazené podpůrné informace a prvky. Cílem je naopak vytvářet co nejjednodušší a nejčitelnější prostředí, ve kterém bude maximální možný prostor věnovaný obsahu a naopak minimální podpůrným informacím a ovládacím prvkům. Hlavním cílem návrhu je tedy správně definovat primární obsah, tzn. ten, který uživatel od systému očekává, a tomu věnovat maximální prostor v rozhraní systému. Zároveň je třeba ostatní informace poskytované systémem vhodně prezentovat uživateli podle jejich aktuální důležitosti a relevance. 12

Layout je jiným označením pro grafické rozvržení.

43


3.3.2

Koncepce uživatelského rozhraní navrhovaného systému

Primárním cílem návrhu UI systému bylo efektivní oddělení základní navigace a podpůrných služeb, funkcí a informací od hlavního obsahu, resp. rozhraní spuštěné aplikace. Vedle požadavku na maximalizaci obsahové plochy a minimalizaci plochy pro podpůrné prvky, bylo zároveň důležité rozhraní navrhnout tak, aby bylo maximálně přizpůsobivé velikosti zobrazovací plochy. Výsledkem je rozdělení základního layoutu do třech částí: • Hlavní ovládací panel Horizontální lišta, která agreguje veškerou funkčnost a informace, které jsou zastřešeny platformou systému. Zároveň obsahuje základní navigaci, tzn. zajišťuje pohyb mezi sektory a službami. Tento panel je fixován na horní hranu zobrazovací plochy a má výšku cca 30 – 40px. • Rozhraní spuštěné aplikace Samotný obsah právě spuštěné služby (resp. aplikace). Tato plocha zabírá naprostou většinu plochy zobrazovacího zařízení. • Patička Prostor obsahující základní informace o systému a zejména odkazy na nápovědu či helpdesk. Patičku tvoří horizontální prostor ukotvený ke spodní hraně zobrazovací plochy a má výšku cca 20 – 30px. Celé rozhraní je horizontálně dynamické, tzn. jeho obsah a forma zobrazení se přizpůsobuje automaticky podle šířky zobrazovací plochy tak, aby byl vždy využit maximální prostor. Aby byla funkčnost a obsah hlavního ovládacího panelu a patičky přístupný stále, jsou tyto prvky fixovány na horní a spodní hranu zobrazované plochy (viewportu) a prostor pro rozhraní spuštěné aplikace má vlastní vertikální posuvník. Princip řešení je zobrazen na obrázku 3.4. Tento koncept zajišťuje běžně prostor pro obsah více než 90%. Při zobrazení o velikosti 1280x800px se jedná zhruba o 92% celkové plochy.

3.3.3

Provedení uživatelského rozhraní

Uživatelské rozhraní funkcí, které zprostředkovává platforma systému je soustředěno do hlavního ovládacího panelu. Rozhraní každé služby může být individuální (mělo by ovšem dodržovat stanovené standardy a zásady GUI). Obrázek 3.5 ukazuje návrh uživatelského řešení v podobě Wireframu. Hlavní panel ve svém výchozím zobrazení obsahuje pouze zcela fundamentální informace a tlačítka základních funkčností. Ve chvíli, kdy je uživatelem nějaká funkčnost zvolena, panel se rozbalí na požadovanou plochu a umožní tak přístup k potřebným informacím či funkčnostem. 44


Obrázek 3.4: Koncept řešení uživatelského rozhraní.

Obrázek 3.5: Wireframe - Základní layout uživatelského prostředí systému.

45


Obrázek 3.6: Wireframe - Uživatelské prostředí při otevřeném panelu.

Tento model zajišťuje zejména efektivní využití plochy rozhraní, kterou zabírá pouze ve chvíli, kdy uživatel dané funkce či informace požaduje. Prostorově velmi nenáročný panel v případě potřeby upozorňuje na důležitou informaci či událost. Není tak nutné zabírat uživateli prostor, který může využít pro služby, na jejichž obsah se v danou chvíli soustředí. Uživatelské prostředí ve chvíli rozbaleného hlavního panelu zobrazuje obrázek 3.6. Vedle praktického řešení flexibilního využívání prostoru se tímto řešením stává panel interaktivním prvkem, který zvyšuje přitažlivost používání celého systému. Je obecně dokázáno, že čistě zábavné, ač funkčně nepodstatné zpracování, může velmi pozitivně ovlivnit přijímání celého rozhraní.(1) V našem případě toto provedení navíc nemá žádný vedlejší vliv na použitelnost a naopak se funkčnost a přitažlivost provedení dobře doplňují. V případě, že si uživatel přeje mít určitou sekci hlavního panelu zobrazenou stále, a omezení výšky spuštěné aplikace mu nevadí, je možné nechat panel rozbalený. Je tak možné např. využívat libovolnou službu systému a mít zároveň otevřený kalendář.

3.3.4

Hlavní ovládací panel

Hlavní panel zahrnuje zcela kompletní funkčnost platformy a veškerou potřebnou navigaci v rámci systému. Při návrhu hlavního panelu bylo apelováno na vhodnou agregaci funkčností do minimálního počtu ovládacích prvků. Uživatelé čtou stránky zkratkovitě, nehodlají přemýšlet nad funkčností a klikají obvykle na první možnost, která se jim zdá vhodná pro splnění jejich požadavku.(6) Veškerá funkčnost panelu je tedy podána velmi stručně a co nejnázorněji, pomocí jednoduše identifiko46


Obrázek 3.7: Hlavní ovládací panel a jeho prvky.

Obrázek 3.8: Wireframe - Hlavní menu systému

vatelných piktogramů. V levé části je umístěno tlačítko menu, v pravé pak ikony základních funkcí a služeb platformy. Pokud je v nějaké podpůrné službě nová událost, či dosud nepřijatá informace, nachází se údaj s počtem těchto informací vedle dané ikonky. Nová událost či informace může být navíc doprovázena zvukovým signálem a rozblikáním dané ikonky v panelu – uživatel je tak vždy dostatečně důrazně informován a je na něm, kdy danou událost či informaci zpracuje. Dále je pak v panelu umístěno uživatelovo jméno s jeho stavem, tlačítko pro nastavení systému a odhlášení. Ovládací panel včetně jeho prvků znázorňuje obrázek 3.7. Menu Jedná se o hlavní a jedinou navigaci po službách systému. Pod menu se nachází přehled veškerých služeb, které jsou systémem poskytovány, resp. které jsou v roli přihlášeného uživatele dostupné. Všechny služby jsou členěny do skupin podle sektorů a jako první je uveden vždy Přehled (Dashboard). Pokud je uživatel správce sektoru, je vedle názvu sektoru navíc umístěno tlačítko umožňující vstup do sekce pro správu sektoru. Provedení znázorňuje obrázek 3.8. 47


Obrázek 3.9: Wireframe - Notifikace

Obrázek 3.10: Wireframe - Zprávy

Notifikace Sekce notifikací je centrem veškerých informací a zároveň požadavků přicházejících směrem k uživateli, jak ze samotné platformy, tak ze služeb jako takových. Mohou to být jak čistě informační záležitosti, např. v podobě informace o nové verzi systému, tak notifikace od služeb, které vyžadují i určitou akci uživatele, např. potvrzení. To může být potvrzení autorizace uživatele, přijetí pozvánky na schůzku, přijetí delegovaného úkolu v rámci projektového řízení, apod. Každá notifikace obsahuje vedle samotného sdělení informaci jakou službou (resp. aplikací) byla vyvolána. Dále pak může obsahovat odkazy pro libovolné akce, např. přechod do dané aplikace, či potvrzení, přijetí, apod. Provedení notifikací znázorňuje obrázek 3.9.

Zprávy Systém umožňuje v rámci systému jednoduchou a rychlou komunikaci mezi uživateli, včetně podpory skupinové komunikace. Provedení zpráv znázorňuje obrázek 3.10. 48


Obrázek 3.11: Wireframe - Autorizovaní uživatelé

Obrázek 3.12: Wireframe - Kalendář

Autorizovaní uživatelé Přehled uživatelů, se kterými je přihlašený uživatel v rámci systému ve spojení. V této sekci má uživatel přehled, kdo je momentálně přihlášen v systému a je dostupný. Může si pak zobrazit jeho podrobné informace a uživatele kontaktovat. Lze zde také jednoduše hledat v rámci systému uživatele a do seznamu autorizovaných uživatelů přidávat nové. Provedení znázorňuje obrázek 3.11.

Kalendář Systémový kalendář je centrem veškerých událostí či akcí, které lze vázat na konkrétní datum. Libovolné služby mohou do systémového kalendáře uživateli ukládat jakékoli informace. Služba projektového řízení tak může uživateli v kalendáři zobrazovat termíny dokončení úkolů, účetní systém může upozorňovat na termíny plateb, apod. Vedle standardního měsíčního kalendáře jsou v panelu zobrazeny nadcházející události podle data jejich konání. Každá událost obsahuje vedle termínu název, popis a jakou službou byla do kalendáře vložena. Provedení znázorňuje obrázek 3.12. 49


Obrázek 3.13: Wireframe - Stav uživatele

Stav uživatele Systém automaticky nastavuje uživatelův stav, podle jeho aktivity v systému. Pokud je vykázána aktivita v posledních pěti minutách, je stav udržován na „aktivní“, v opačném případě je nastaven na „neaktivní“. Při odhlášení ze systému pak „odpojený“. Tento stav je viditelný pro ostatní autorizované uživatele a je důležitou informací při živé komunikaci či organizování práce v rámci systému. Kliknutím na indikátor stavu v panelu může uživatel kdykoli automatické určování stavu systémem přerušit a zvolit stav podle vlastní volby. Provedení znázorňuje obrázek 3.13. Nastavení V sekci nastavení lze provádět veškeré možné úpravy účtu, systému či přístupových údajů. Zároveň pokud je uživatel správce licence, je mu umožněno zakazovat služby poskytované v rámci licence a kompletně řídit přístupy ke všem sektorům, které jsou pod licencí provozovány. Provedení je znázorněno sadou wireframů na obrázku 3.14. Funkční prototyp rozhraní je k dispozici na přiloženém CD. Viz. příloha C.

3.4

Shrnutí klíčových vlastností navrhovaného řešení

Navrhované řešení je ve srovnání s běžnými informačními systémy a jejich provedením velmi specifické. Nejedná se o konkrétní systém ale o platformu, na které bude možné stavět libovolné systémy a aplikace. Zároveň je navrženo pro informační systém netradiční uživatelské prostředí. To se snaží aplikovat zejména pozorované moderní trendy a mé poznatky ze studia a praxe. Rozhraní je vytvořeno tak, aby byl systém jednoduše použitelný pro každého, aniž by byla jakkoli omezována funkčnost a rozsah systému.

50

3.4. Shrnutí klíčových vlastností navrhovaného řešení

Obrázek 3.14: Sada Wireframů - Systémové nastavení.

Souhrn klíčových vlastností: • Struktura systému je členěna do třech základních úrovní – licence, sektory a služby. Licence je obchodovatelná jednotka zahrnující uživatelské účty a daný okruh poskytovaných služeb. Služby jsou sdružovány do tzv. sektorů, které tvoří obecnější funkční celky systému. • Zmíněná struktura zároveň definuje úrovně řízení přístupových práv. Od správce licence se kompetence rozpadají až na správce služby. V rámci služby lze ovlivňovat práva až do úrovně tzv. aktivit. • Soubory přístupových práv jsou zahrnuty v uživatelských rolích. Ty určují tzv. implicitní práva. Každý uživatel může mít určené práva navíc explicitně, což jsou konkrétní oprávnění mimo uživatelské role. • Služby systému, jinak také aplikace, mají jednotně definovanou struk51

3. Specifikace platformy informačního systému turu. Pro urychlení vývoje aplikací je možné stavět na tzv. šablonových aplikací. • Aplikace v systému jsou podle principu jejich nasazení děleny na obecné (unifikované) a specifické. Obecné běží v jediné instanci pro široké spektrum uživatelů, narozdíl od specifických, které jsou vyvíjeny vždy individuálně pro konkrétní použití. • Uživatelské rozhraní využívá moderních trendů jednoduchých rozhraní a inspiruje se ze současných rozhraní mobilních zařízení. Klíčový je důraz na obsah, je proto minimalizován prostor pro podpůrné prvky a maximalizován prostor pro samotný nosný obsah systému. • Veškerá funkčnost platformy je soustředěna do jednoho hlavního panelu, přes který je uživateli zpřístupněno ovládání systému a jeho funkcí.

52

Kapitola

Vyhodnocení přínosů Vývoj navrhovaného řešení a jeho zavedení lze rozdělit na dvě základní etapy. V první je třeba kompletně připravit platformu informačního systému, tak jak zde bylo specifikováno. V následující etapě je nutné implementovat samotné výkonné služby systému, jejichž návrh je však nad rámec této práce. Po skončení první etapy lze již využívat platformu k vývoji zakázkových řešení a systém zavést do obchodního modelu firmy. Charakter řešení předurčuje systém k internímu vývoji. Je žádoucí, aby vývojáři, kteří budou zároveň aplikačními programátory a správci nového systému, byli přímo do vývoje začleněni. Na základě finančních údajů firmy a kvalifikovaného posudku rozsahu navrhovaného řešení byl stanoven odhad nákladů na vývoj systému včetně základního vyhodnocení investice.13

4.1

Náklady na vývoj

Podle odhadu náročnosti jednotlivých fází vývoje a aktuálně běžných hodinových nákladů firmy, byl sestaven pilotní odhad celkových nákladů na vývoj. Náklady jsou uvedeny v tabulce 4.1. Vývoj platformy informačního systému U hodinového rozložení prací je pozorována zvýšená dotace pro činnosti věnované návrhu, které se v součtu přibližují dotaci pro implementační část. Vzhledem k tomu, že se jedná o vývoj platformy, je právě samotný návrh a jeho preciznost klíčová. Implementace je díky míře podrobnosti návrhu následně výrazně efektivnější. Přímé náklady na vývoj platformy byly odhadnuty na 418 000,- Kč. K celkové ceně je přičtena rezerva ve výši 10%, která činí ±42 000,- Kč. Celkové 13 Veškeré odhady v rámci této kapitoly byly stanoveny na základě mých dosavadních zkušeností a ve firmě pozorované praxi.

53

4

4. Vyhodnocení přínosů Tabulka 4.1: Odhadované náklady na vývoj platformy IS.

Položka

Předpokládaný počet člověkohodin

Hodinová sazba

Náklady

Uživatelské testování prototypu. Sestavení specifikace UI.

40

600,- Kč

24 000,- Kč

Funkční specifikace. Návrh architektury.

130

700,- Kč

91 000,- Kč

Grafický návrh rozhraní.

60

650,- Kč

39 000,- Kč

Implementace systému.

240

750,- Kč

180 000,- Kč

Testování, ladění a zavedení systému.

40

700,- Kč

28 000,- Kč

Řízení projektu.

70

800,- Kč

56 000,- Kč

náklady jsou tedy stanoveny na 460 000,- Kč. Další fází je vývoj samotných služeb interního informačního systému. Tato etapa již bude plně využívat novou vývojovou platformu. V odhadu je tedy uvažována vysoká míra zefektivnění celého procesu vývoje. U implementace může jít např. až o 50 – 70% snížení hodinové dotace. Do služeb interního informačního systému uvažujeme vývoj těchto základních aplikací: • Projektové řízení včetně rozhraní pro klienty • Znalostní báze • Fakturace U stanovení nákladů vývoje těchto služeb je třeba zdůraznit čistě orientační charakter. Jedná se o velmi obecný odhad nákladů vývoje základních služeb, sestavený zejména pro ilustraci potenciální míry efektivity vývoje na platformě a sestavení základního odhadu návratnosti investice. Odhadované náklady jsou uvedeny v tabulce 4.2. 54

4.2. Základní vyhodnocení investice Tabulka 4.2: Odhadované náklady na vývoj služeb interního IS.

Položka

Předpokládaný počet člověkohodin

Hodinová sazba

Náklady

Specifikace služeb. Zpracování UI.

40

600,- Kč

24 000,- Kč

Implementace.

130

750,- Kč

97 500,- Kč

Testování, ladění a nasazení služeb.

30

700,- Kč

21 000,- Kč

Řízení projektu.

40

800,- Kč

32 000,- Kč

Náklady na vývoj služeb interního informačního systému Zde lze již pozorovat velmi nízkou náročnost sestavení specifikace a zpracování UI – i tyto činnosti jsou významně zefektivněny využitím platformy, stejně jako samotná implementace. Potřeba grafického návrhu je eliminována zcela. Přímé náklady na vývoj služeb interního IS na platformě byly odhadnuty na 174 500,- Kč. K celkové ceně je přičtena rezerva ve výši 10%, která činí ±18 000,- Kč. Celkové náklady jsou tedy stanoveny na 193 000,- Kč.

4.2

Základní vyhodnocení investice

Vstupní informace • Vývoj webů a aplikací tvoří 70% obratu při zisku 15%. • Zbylých 30% obratu tvoří ostatní služby při zisku 25%, tzn. celková půrměrná ziskovost je 18%. • Celkový roční obrat z prodeje služeb se pohybuje okolo 3 mil. Kč. Předpokládaný přínos systému • Zrychlení vývoje u webů a aplikací díky zavedení jednotné platformy, tzn. snížení nákladů průměrně o 15%. Tzn. zvýšení ziskovosti až o ±13% bodů. • Celkové zefektivnění činností po zavedení interního informačního systému způsobující plošné snížení nákladů firmy o 4 – 6%. Tzn. zvýšení 55

4. Vyhodnocení přínosů celkové ziskovosti veškeré produkce o ±4% bodů. Při zavedení vývojové platformy společně s interním informačním systémem lze předpokládat roční zvýšení zisku z vývoje webů a aplikací o 273 000,Kč. Díky plošnému snížení nákladů po nasazení interního informačního systému lze pak předpokládat celkové zvýšení zisku o dalších 120 000,- Kč. Celkem je tedy předpoklad ročních úspor díky zavedení systému ve výši 393 000,- Kč. Na základě předpokládaných přínosů je zřejmá návratnost investice již do dvou let. Při celkových nákladech 653 000,- Kč na vývoj systému a celkovému zisku 786 000,- Kč po dvou letech, je návratnost investice (ROI) ve výši 20%.14 Tento výsledek může být v praxi ovlivněn mírou využití započítané rezervy a zároveň zvoleným způsobem realizace, který může mít na výši nákladů také vliv. (viz. sekce 4.3) V tomto orientačním vyhodnocení dále není zohledněn potenciál rozšiřování kapacit firmy a zvýšení rozsahu zakázek, což je mimo jiné očekávaný důsledek vzniklých úspor. Zároveň nejsou kalkulované nově vzniklé výnosy generované poskytováním systému jako služby. Tyto oblasti by si pro odhad výnosů vyžadovali podrobnou marketingovou analýzu.

4.3

Způsob a plánování vývoje

Vývoj systému je nastaven jako interní v rámci firmy, pro kterou je navrhován. To s sebou nese určitá specifika, která je třeba uvažovat při plánování samotné realizace. Vzhledem k velikosti firmy bude vývoj nepochybně znamenat zásadní vytížení lidských zdrojů. Je proto nutné zvážit, jakou formu s ohledem na omezení výkonu firmy a rychlosti vývoje zvolit. První variantou je omezení výkonnosti firmy na minimum a alokování většiny zdrojů do vývoje. Za navrhovaného řešení a současných kapacit firmy by bylo možné systém takto realizovat do dvou měsíců.15 Zároveň by to však způsobilo v tomto období dramatický pokles zisku či dočasné ztráty. Tím se logicky navýšují náklady na vývoj. Druhou variantou je volit průběžný vývoj při nízkém zatížení zdrojů. Tím bude snížena výkonnost firmy jen minimálně a náklady budou rozloženy do delšího období. Rychlost vývoje se tak zároveň až několikanásobně sníží. Přesný termín a způsob realizace vývoje lze plánovat také s ohledem na sezónní vytíženost či vývoj spojit přímo s konkrétní zakázkou. Tím může být dosaženo rychlého vývoje při minimálních ztrátách. 14

Return On Investment (Návratnost investice) je metoda zhodnocení profitu investovaného kapitálu v procentech, podle vztahu ROI = ((čistý zisk – počáteční investice) / počáteční investice) * 100 [%]. (13) V našem případě bylo uvažováno zhodnocení do dvou let, tzn. (133/653)*100 = 20,37. Vzhledem ke krátkému horizontu dvou let, nebylo nutné uvažovat NPV (čistou současnou hodnotu). (12) 15 Celková náročnost vývoje byla stanovena na 820 člověkohodin, což činí při alokování 3 lidí na plné vytížení cca 7 týdnů.

56

4.4. Celkové zhodnocení přínosů systému Varianta zaměřit se čistě na vývoj systému firmu vystavuje nejen vnitřním finančním rizikům, ale zároveň obchodním rizikům, neboť bude produkce a tím pádem i obchod omezen na minimum. Na druhou stranu u dlouhodobého průběžného vývoje hrozí ztráty díky neefektivitě a obecně také není vhodné v rychle měnícím se obchodním prostředí firmy realizaci příliš prodlužovat. Jako vhodná varianta se proto jeví spíše rychlejší vývoj, který však naplánovat tak, aby se odehrál v obchodně slabším období a byl ideálně spojen s realizací konkrétní zakázky, čímž budou eliminovány finanční rizika.

4.4

Celkové zhodnocení přínosů systému

Z pilotního odhadu nákladů a přínosů jednoznačně vyplývá, že zavedení systému je pro firmu velmi výhodné. Návratnost investice (ROI) ve výši 20% do dvou let je velmi vysoká, přičemž není do tohoto výpočtu jakkoli zahrnut další obchodní přínos, který firmě zavedením systému také vznikne. Vzhledem k tomu, že se systém stane základní vývojovou platformou pro webové aplikace, bude tím dosaženo významné redukce přímých nákladů u tohoto typu zakázek. Obecně by tím měl být potlačován problém dlouhodobě nedostatečné ziskovosti a zároveň se firmě rozšíří prostor pro nastavování cen. Důležitá je také vazba na obchodní model firmy. Systém umožní rozšířit portfolio služeb o nový produkt, čímž využije sledované příležitosti na trhu a může rozšířit segment zákazníků. Tato vlastnost je z obchodního hlediska velmi zajímavá a jedná se o důležitý benefit. Zásadním přínosem systému je zavedení účinného nástroje pro řízení činností uvnitř firmy. Ty jsou až na dvě výrobní činnosti ve firmě nyní řešeny operativně. Současný způsob jejich provádění a řízení je hlavní problém nedostatečné dynamiky firmy. Jedná se zejména o obchod, kontrolu, plánování a řízení lidských zdrojů či znalostí. Podpora systému zajistí například efektivní sdílení a organizaci informací, přehled o dostupných kapacitách a jejich vytížení či organizaci obchodních činností a řízení vztahů se zákazníky. Budou tak eliminovány ztráty informací, zajištěno efektivnější využití zdrojů a dosaženo přesnějšího plánování. Díky tomu bude možné lépe garantovat termíny, spolehlivěji řešit požadavky klientů a přijímat rozsáhlejší zakázky.

57

Závěr Cílem práce bylo navrhnout vhodné řešení pro specifické požadavky grafického a webdesignového studia Wavevision. Na základě analýzy současného stavu firmy byly identifikovány hlavní problémy, které jsou způsobovány jednak absencí interního informačního systému, tak neefektivním vývojem webových aplikací bez používání jednotné vývojové platformy. Povedlo se navrhnout takové řešení, které splnilo požadavky v jednom systému a má přímou vazbu k obchodnímu modelu firmy. Jsou tak nejen minimalizovány pozorované slabé stránky podniku a obohaceny ty silné, ale zároveň jsou naplňovány aktuální příležitosti na trhu. Orientační zhodnocení přínosů, provedené na základě předpokládaných důsledků zavedení systému navíc ukazuje velmi vysokou míru efektivity navrhovaného řešení. Při interním vývoji systému jsou s ohledem na jeho rozsah náklady na implementaci relativně nízké a návratnost je vysoká i bez kalkulace potenciálních dlouhodobých obchodních přínosů. Je ale nutné provést důkladnější plánování a načasování vývoje tak, aby byly eliminovány ztráty vycházející z omezení zdrojů potřebných pro běžný provoz firmy. Pro návrh byla zásadní oblast uživatelského rozhraní. Záměrem bylo navrhnout co nejjednodušší a maximálně intuitivní prostředí aniž by byla narušena robustnost a rozsah funkčností celého systému. Návrh byl inspirován moderními trendy a rozhraními současných mobilních zařízení. Výsledkem je prostředí, které je na první pohled velmi odlišné od konvenčních informačních systémů. Zdali je tato koncepce opravdu vhodná a bude u uživatelů úspěšná, by v prvé řadě mělo ukázat uživatelské testování prototypu, které je plánované následně. Jak bylo řečeno v úvodu, celé řešení je vystavěno na reálných podkladech s přímou vazbu na konkrétní společnost a tím i mojí praxi. Práce je tedy přínosem jednak pro zmíněnou firmu tak i pro mě osobně. Výstupy budou aplikovány do praxe a dál zpracovávány v reálném prostředí. Vzhledem k tomu, že součástí je také částečně funkční prototyp uživatelského rozhraní, je možné snadno přejít k uživatelskému testování. Dále je možné po návrhu architek59

Závěr tury systému a zpracování grafiky uživatelského rozhraní, přejít k samotné implementaci. Takový je také očekávány postup.

60

Literatura (1) Anderson, S. P.: Přitažlivý interaktivní design. Computer Press, Brno, 2012. (2) Awio Web Services LLC: W3Counter - Global Web Stats. [cit. 2012-0503]. Dostupné z WWW: (3) Chuck Longanecker: What to Expect in 2010: UX/UI Design Simplicity. [cit. 2012-05-04]. Dostupné z WWW: (4) Ethan Marcotte: Responsive Web Design. [cit. 2012-05-03]. Dostupné z WWW: (5) Jaromír Veber, J. S. a. k.: Podnikání malé a střední firmy. Grada Publishing, Praha, 2008. (6) Krug, S.: Nenuťte uživatele přemýšlet. Computer Press, Brno, 2007. (7) McNeil, P.: Inspirativní webdesign. Computer Press, Brno, 2011. (8) Petr Sodomka, H. K.: Informační systémy v podnikové praxi. Computer Press, Brno, 2010. (9) Wikipedia: The free encyclopedia.: API. [cit. 2012-05-04]. Dostupné z WWW: (10) Wikipedia: The free encyclopedia.: Front and back ends. [cit. 201204-23]. Dostupné z WWW: (11) Wikipedia: The free encyclopedia.: Layout. [cit. 2012-05-04]. Dostupné z WWW: 61

Literatura (12) Wikipedia: The free encyclopedia.: Net present value. [cit. 2012-05-04]. Dostupné z WWW: (13) Wikipedia: The free encyclopedia.: Return on investment. [cit. 201205-04]. Dostupné z WWW: (14) Wikipedia: The free encyclopedia.: Service-oriented architecture. [cit. 2012-04-28]. Dostupné z WWW: (15) Wikipedia: The free encyclopedia.: Software as a Service. [cit. 2012-0418]. Dostupné z WWW: (16) Wikipedia: The free encyclopedia.: SWOT. [cit. 2012-05-06]. Dostupné z WWW: (17) Wikipedia: The free encyclopedia.: Unified Modeling Language. [cit. 2012-05-02]. Dostupné z WWW: (18) Wikipedia: The free encyclopedia.: User experience. [cit. 2012-0412]. Dostupné z WWW: (19) Wikipedia: The free encyclopedia.: Uživatelské rozhraní. [cit. 201205-04]. Dostupné z WWW: (20) Wikipedia: The free encyclopedia.: Vývojová platforma. [cit. 201205-04]. Dostupné z WWW: (21) Wikipedia: The free encyclopedia.: Wireframe. [cit. 2012-05-04]. Dostupné z WWW: (22) William Lidwell, J. B., Kritina Holden: Univerzální principy designu. Computer Press, Brno, 2011. (23) Česká informační agentura: Český trh IT v roce 2012 podle IDC. [cit. 2012-05-07]. Dostupné z WWW:

62

Příloha

UML Diagramy

63

A

A. UML Diagramy

Obrázek A.1: UML - Proces „Tvorba webové prezentace“

64

Obrázek A.2: UML - Proces „Realizace nového vizuálního stylu, příprava tiskových dat“

65

Příloha

Seznam použitých pojmů a zkratek API Zkratka pro Application Programming Interface označuje v informatice rozhraní pro programování aplikací. Tento termín používá softwarové inženýrství. Jde o sbírku procedur, funkcí či tříd nějaké knihovny (ale třeba i jiného programu nebo jádra operačního systému), které může programátor využívat. (9) IS Informační systém Layout Angl. plán, rozvrh. Znamená grafické rozvržení tiskové nebo elektronické stránky, případně i jiné plochy. (11) Platforma (vývojová) Vývojová platforma je základ aplikace vyvinutý odborníky, který může vývojář použít k vývoji vlastního programu. Programátor se už nemusí starat vždy znovu o stejné úkoly, jako jsou např. spuštění aplikace, systém oken a práce s nimi, budování GUI, spouštění akcí, ukládání stavu aplikace, procesy na pozadí, aktualizace aplikace. (20) Platforma IS V kontextu práce se jedná o specifickou vývojovou a distribuční platformu, na které lze vytvářet a provozovat informační systémy či libovolné aplikace. Podpůrná služba V kontextu práce a navrhovaného systému se jedná o funkčnost, kterou poskytuje platforma systému. Ta slouží zpravidla k řízení toků informací mezi službami a uživateli či k jiným sekundárním funkcím systému. Jedná se např. o kalendář, notifikační centrum nebo systémové nastavení. Služba V kontextu práce a navrhovaného systému se jedná o výkonné aplikace, které uživateli, či skupině uživatelů, přinášejí požadovanou funkčnost systému. 67

B

B. Seznam použitých pojmů a zkratek SOA Service-oriented architecture (Architektura orientovaná na služby)(14) SWOT Metoda, jejíž pomocí je možno identifikovat silné (ang: Strengths) a slabé (ang: Weaknesses) stránky, příležitosti (ang: Opportunities) a hrozby (ang: Threats), spojené s určitým projektem, typem podnikání, podnikatelským záměrem, apod. (16) UI Uživatelské rozhraní (angl. User Interface) je souhrn způsobů, jakými lidé (uživatelé) ovlivňují chování strojů, zařízení, počítačových programů či komplexních systémů. (19) UML UML (Unified Modeling Language) je v softwarovém inženýrství grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů. (17) UX User experience, v češtině také Uživatelský prožitek, je podle definice normy ISO 9241-210 vnímání a způsob reagování plynoucí z použití určitého produktu či služby. (18) Wireframe Jinak také "drátěný model"se v oblasti vývoje webových prezentací či aplikací používá pro náhled nového řešení. Jde o návrh definující funkci a obsah stránek webu, pro lepší pochopení. (21)

68

Příloha

Obsah přiloženého CD

readme.txt...................................stručný popis obsahu CD ui-prototype...................adresář se spustitelným prototypem UI text ....................................................... text práce bp-adam-biciste ............ zdrojová forma práce ve formátu LATEX bp-adam-biciste.pdf...................text práce ve formátu PDF 69

C

ZADANI BANELARSKE PRACE. ipsrce vvsox6 ucnni TECHNTcKE v Pnazn Faxulre rnformacnich rncnnolocri

Recommend Documents