}w!"#$%&'()+,-./012345<ya

Transkript

1 }w!"#$%&'()+,-./012345<ya MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Úprava a nasazení software pro podporu firemní spolupráce DIPLOMOVÁ PRÁCE Bc. Jan Mayer Brno, jaro 2013

2 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: Mgr. Jiří Kolář ii

3 Poděkování Chtěl bych poděkovat vedoucímu práce Mgr. Jiřímu Kolářovi za pomoc a rady při vzniku této práce. Dále bych chtěl poděkovat všem zaměstnancům firmy inqool a.s., především Mgr. Petrovi Halmovi, Mgr. Tiborovi Szabovi a Mgr. Matúšovi Zamborskému za příležitost spolupracovat s nimi při vytváření své diplomové práce. V neposlední řadě bych chtěl poděkovat celé své rodině za neustálou podporu. iii

4 Shrnutí Cílem práce je najít vhodné softwarové řešení pro začínající IT firmy. Nejprve se proto práce věnuje způsobům vedení vývojových týmů. Následně se v práci projednávají potřeby těchto firem a stanovíme základní podmínky, které by měl software pro IT společnosti splňovat. Pro praktické využití software nejprve zanalyzujeme konkrétní IT firmu inqool a.s. a poté navrhneme a formalizujeme procesy, podle kterých se budou ve firmě provádět nejčastější činnosti. Pro modelové činnosti pak stanovíme metriky, podle kterých budeme hodnotit software a najdeme optimální řešení dle obecně stanovených podmínek i požadavků firmy. Následně softwarové řešení upravíme pro docílení maximální efektivity a nasadíme pro praktické užití do firmy inqool. Na závěr zhodnotíme výsledky, které naše práce přinesla. iv

5 Klíčová slova Projektový management, ERP, agilní metody, Scrum, Redmine, Alfresco, Trello, OpenERP, BPMN v

6 Obsah 1 Úvod Motivace Cíle Struktura práce Důležité pojmy Malý a střední podnik Open source Software as a Service ERP systém CRM systém Systém pro správu verzí Lightweight Directory Access Protocol Business Process Modeling Representational State Transfer Informační systém Práce vývojářských týmů Code and Fix Vodopádový model Spirálový model Agilní metody Kritiky agilní metodologie Základní typy agilních technik Motivace pracovníků Command and Control Motivace založená na odměnách Identity Management Method Management Práce týmů v kontextu softwarových nástrojů Pilíře menších a středně velkých společností Firma z pohledu klasického projektového managementu 30 1

7 4.1.1 Co? Jak? Kdy? S kým? Za kolik? Stavební kameny IS Obecné vlastnosti IS Správa projektů Důležité vlastnosti software pro správu projektů Vhodné vlastnosti software pro správu projektů Správa dokumentů Document Management System (DMS) Důležité vlastnosti software pro správu dokumentů Vhodné vlastnosti software pro správu dokumentů Správa kontaktů Důležité vlastnosti software pro správu kontaktů Vhodné vlastnosti software pro správu kontaktů Přechod firmy na nový systém Vyvolání vědomí naléhavosti Sestavení koalice schopné prosadit a realizovat změny Vytvoření vize Komunikace transformační vize Odbourání překážek Vytváření krátkodobých vítězství Využití výsledků a podpora krátkých změn Zakotvení nových přístupů do firemní kultury Analýza ve firmě Firemní struktura Systém přidělování HW Současně používané programy Organizace a plánování Správa stráveného času zaměstnanců Ukládání dokumentů Komunikace s klienty Chybějící prvky a vlastnosti

8 5.5 Návrh nových procesů Stanovení kritérií pro hodnocení software Kritéria pro první fázi testování Kritéria pro správu projektů Kritéria pro správu kontaktů Kritéria pro správu dokumentů Cena řešení Přesnější kritéria pro druhou fázi Stanovení metriky pro porovnání zlepšení Zhodnocení dostupných produktů První fáze Systémy pro správu projektů Systémy pro správu souborů Systémy pro správu kontaktů Druhá fáze Obchodní scénář Projektový scénář Scénář po ukládání dokumentů Hodnocení scénáře Výsledky hodnocení Implementace a nasazení systému Spojení Trello a Redmine Použité komponenty Ruby Redmine Redis Trello API Redmine API Implementace skriptu Nasazení software Přechod firmy inqool na nový systém Srovnání oproti předchozímu řešení Návrhy do budoucna Další firmy Závěr A Obsah CD

9 Kapitola 1 Úvod 1.1 Motivace Posledních několik let můžeme považovat za dobu, ve které vzniklo velké množství technologických firem. Významná část těchto společností jsou firmy, které se zabývají vývojem software. Průměrně každé tři měsíce vzniká technologická společnost, která časem dosahuje hodnoty miliardy dolarů [31]. Přitom všechny tyto firmy na začátku svého života řeší podobné problémy, které se týkají organizace práce svých přibývajících zaměstnanců, ukládání a distribuce znalostí, sdílení dokumentů a komunikace s klienty. Protože jsou tyto firmy velice specificky omezeny, musí takovéto softwarové řešení splňovat řadu podmínek. Většinou se jedná o omezení finanční a personální. Proto je potřeba při hledání firemní softwarové páteře klást důraz na nízkou cenu, rychlé nasazení, jednoduchou škálovatelnost a hlavně efektivní řešení každodenních rutinních úkolů, které zaměstnance nesmí odvádět od jejich hlavní práce. Při vedení firmy bývají zaměstnanci zaneprázdněni naplňováním cílů firmy, proto je pro ně většinou velmi obtížné uvolnit si dost času, aby provedli širokou analýzu trhu. Toto může často vést k tomu, že při výběru softwarového řešení nezváží všechny zmíněné proměnné. Stejně tak začínajícím firmám chybí čas na formální definování procesů a jejich optimalizaci, která často znamená i úpravu použitého software. Většina mladých softwarových firem tak stojí před rozhodnutím, zda-li věnovat značné prostředky na důslednou analýzu, nebo se spokojit s řešením, které nemusí být pro firmu optimální. 4

10 1. ÚVOD 1.2 Cíle Práce si klade za cíl definovat potřeby malých a středních IT firem z pohledu informačních systémů a následné nalézt vhodný softwarový produkt, který by tyto potřeby maximálně naplňoval. Nalezený software pak bude nasazen do firmy inqool a.s., která svými vlasnostmi odpovídá definici našich cílových firem. Přínosem praktické části práce bude tedy jak nasazení nového softwarového systému a nových pracovních procesů do firmy inqool a.s., tak i popis úpravy a zavedení softwarového řešení, aby mohlo být jednoduše nasaditelné do dalších firem z naší cílové skupiny. Abychom mohli považovat práci za úspěšnou, musí být nasazené řešení pro firmu inqool a.s. efektivnější a výhodnější než řešení současné. 5

11 1. ÚVOD 1.3 Struktura práce V prvních dvou kapitolách klademe důraz na teorii. Budeme se věnovat stanovení základních pojmů a způsobu práce vývojářských týmů v posledních letech s důrazem na agilní způsoby řízení projektů. Ve třetí kapitole pak vyvodíme závěry, které jsou důležité ke stanovení metriky, s jejíž pomocí budeme poměřovat vhodnost software. Probereme zde také operativu softwarových firem z pohledu informačního systému a knowledge managementu. Ve čtvrté kapitole si vysvětlíme klady a zápory současných řešení ve firmě inqool a.s. a zmapujeme aktuální workflow. Při výběru a úpravě software musíme brát v potaz současný způsob práce, který ve firmě vznikl zcela organicky. Kdyby přechod na nové řešení pro zaměstnance znamenal zásadní změnu, kterou by nevnímali jako změnu k lepšímu, mohli by software odmítnout. V páté kapitole stanovíme metriku, podle které budeme určovat vhodnost řešení. V kapitole s číslem šest projdeme všechny možnosti, které jsou na trhu k dispozici, a vybereme optimální řešení pro firmu inqool a.s. s přihlédnutím na všechny dříve zmíněné aspekty. Sedmá kapitola obsahuje hodnocení dostupných softwarových produktů podle stanovených kritérií a postup při výběru vhodného řešení. V závěrečné části práce pak popíšeme proces úpravy a nasazení softwarového řešení do firmy inqool a.s. a zhodnotíme výsledky a úspěšnost, s jakou jsme splnili stanovené cíle práce. 6

12 Kapitola 2 Důležité pojmy Před tím, než se dostaneme k samotné problematice, je potřeba přesněji definovat, co si má čtenář představit pod některými základními pojmy, které jsou pro pochopení celé práce nezbytné. 2.1 Malý a střední podnik Analýzy Českého Statistického Úřadu (ČSÚ, [38]) dokládají, že tyto podniky tvoří významnou část tržní ekonomiky v České republice. V roce 2006 byl podíl malých a středních podniků na celkovém počtu podniků roven 99,85% a jejich podíl na výkonech celé podnikatelské sféry činil 51,45%. Dle dokumentu vypracovaného ČSÚ dělíme podniky podle počtu zaměstnanců do 3 základních kategorií: drobné (1-9 zaměstnanců), malé (10-49 zaměstnanců) a střední ( zaměstnanců). V rámci Evropské unie se pro kategorizaci velikosti podniků používají kromě počtu zaměstnanců také jiná měřítka (např. vlastnická struktura a další). Pro naše požadavky je dělení podle ČSÚ dostačující. 2.2 Open source Původ open source můžeme datovat už od roku 1985, kdy R. Stallman založil Free Software Foundation. Na tu později v roce 1998 navázala Open Source Foundation, podle níž může být software označen jako open source pouze pokud splňuje 10 stanovených podmínek [37]. Tyto podmínky ve zkratce popisují, že software musí mít 7

13 2. DŮLEŽITÉ POJMY k dispozici čitelný zdrojový kód, který musí být volně distribuovatelný a v žádné své verzi se nesmí stát tajným. Jakým způsobem je možné software a jeho zdrojový kód distribuovat, je stanovené v licenci, se kterou je software vydáván. Mezi nejznámější open-source licence patří tyto: General Public License (GPL) byla vytvořená R. Stallmanem pro projekt GNU. Běžný uživatel může zdrojový kód zkoumat a upravovat bez potřeby zveřejnění, ale odvozené práce si musí zachovat původní svobody. V současné době je nejnovější třetí verze této licence. Lesser General Public License (LGPL) je volnější úpravou GPL, která autorovi navíc dovoluje spojovat software z otevřeného i uzavřeného zdrojového kódu. Affero General Public License (AGPL) vznikla pro potřeby používat software na síti jako SaaS. Aktuálně je AGPL ve třetí verzi. Apache License narozdíl od GPL patří k permisivním licencím. To znamená, že dovoluje, aby byl software postavený na zdrojovém kódu distribuován s jinou licencí. Aktuálně je tato licence ve verzi 2.0. Berkley Source Distribution License (BSDL) je licencí s poměrně krátkým textem. Primárně se v něm snaží chránit autora a nezakazuje jakoukoliv úpravu a distribuci kódu. Massachusetts Institute of Technology License (MITL) představuje nejvolnější licenci z našeho výčtu. Prakticky jen zbavuje autora veškeré zodpovědnosti. Mozila Public Licence vznikla primárně pro potřeby distribuce software Mozilla. Představuje kompromis mezi BSD a GPL licencí [16]. 2.3 Software as a Service Software jako služba je běžně používaný český překlad pro tuto anglickou formulaci. Software as a service (SaaS, [13]) si lze jednoduše 8

14 2. DŮLEŽITÉ POJMY představit jako softwarovou službu, které je placená svými pravidelnými odběrateli (tedy zákazníky). SaaS je definovaná třemi základními faktory: Odběratel si nekupuje žádný software. Odběratel si neinstaluje žádný produkt na svůj počítač (ani na domácí počítač, ani na server). Pro tento bod jsou definované výjimky v případě, že si uživatel musí nainstalovat nějakou jednoduchou aplikaci, která se serverem komunikuje, ale není jádrem služby. Služba je opakovaně placena v daných intervalech. Toto platí, pokud má služba placený model, existují ale i SaaS, které jsou financovány například z reklamního systému a pro zákazníky jsou zdarma. 2.4 ERP systém Anglická zkratka ERP reprezentuje (Enterprise Resource Plannig, [46]), což můžeme volně přeložit jako plánování podnikových zdrojů. Ve zkratce jde o software, jehož úkolem je pokrýt plánování a řízení všech klíčových interních firemních procesů (tedy celou transformaci zdrojů na výstupy). Systém pokrývá procesy na všech úrovních od strategie až po operativu. 2.5 CRM systém Customer relationship management (CRM, [48]) je proces shromažd ování, zpracování a využití informací o zákaznících, který je podporovaný databázovou technologií. Umožňuje tak pochopit a předvídat potřeby zákazníků a podporuje oboustranou komunikaci mezi nimi a firmou. Jako CRM systém je označována právě softwarová, hardwarová a popřípadě i personální část firmy, která tento úkol naplňuje. 9

15 2. DŮLEŽITÉ POJMY 2.6 Systém pro správu verzí Programátoři při vývoji programu vytváří soubory se zdrojovým kódem. Systémy pro správu verzí řeší problémy, kdy je potřeba, aby na zdrojových kódech spolupracovalo současně více programátorů. Systémy mají na starosti slučování různých verzí souborů, integraci, zálohování všech změn a další. Problém správy verzí řeší programy jako Concurrent Verison System (CVS), Subversion (SVN) nebo GIT. Rozbor práce verzovacích systémů a jejich nasazování v kontextu kontinuální integrace je nad rámec této publikace. Více informací k tomuto tématu se nachází v seznamu literatury [18]. 2.7 Lightweight Directory Access Protocol Jedná se o rozšířený protokol (LDAP, [6]), který popisuje správu adresářových služeb přes sít. Adresářové služby zpravidla ukládají velmi komplexní hierarchické struktury záznamů. Jako jednoduchý příklad pro využití protokolu můžeme uvažovat aplikaci, která potřebuje autentizovat uživatele. Při připojování uživatele se aplikace pomocí LDAP připojí k adresářové službě a dotáže se na všechny záznamy o uživatelském účtu. 2.8 Business Process Modeling Modelování business procesů je podle Ryan K. L. Ko (BPM, [25]) definované jako podpora business procesů použitím metod, technik a software pro návrh, kontrolu a analýzu operačních procesů, jež zahrnují lidi, organizace, dokumenty a další zdroje informací. Standard BPMN (Business Process Model and Notation, [35]) představuje unifikovaný způsob jak graficky znázornit business procesy. Původním autorem této notace je Business Process Management Initiative (BPMI), která se v roce 2005 stala součástí Object Management Group. Specifikace je aktuálně ve verzi 2.0 a volně dostupná na webu [35]. 10

16 2. DŮLEŽITÉ POJMY 2.9 Representational State Transfer První zmínka o této technologii (REST, [42]) pochází již z roku REST představuje architekturu, ve které komunikuje server s klienty pomocí bezstavových připojení. Na serveru je uložen pouze dlouhodobý stav a klient se může k jednotlivým prostředkům připojit pouze pomocí přesně definované sady indetifikátorů prostředků. V kontextu webu hovoříme o tak zvaných Uniform Resource Identifiers (URI, [42]). V praxi se jedná o určení prostředku pomocí URI a zavolání jedné ze čtyř akcí, které s prostředkem můžeme provést. GET stáhne ze serveru aktuální verzi prostředku. POST odešle na server data o prostředku. Server si je uloží jako nový záznam. PUT odešle na server upravená data dříve stáhnutého prostředku. Server si uloží novou verzi. DELETE smaže prostředek uložený na serveru Informační systém Pojem informační systém (IS, [10]) je velice obecné označení pro soubor technologických metod a prostředků pro sběr, přenos a uchování dat. V našem kontextu budeme o IS hovořit jako o kompletním softwarovém řešení pro uložení, správu a vhodné poskytování veškerých elektronických dat, které jsou významné pro fungování firmy. 11

17 Kapitola 3 Práce vývojářských týmů Celá společnost se vlivem digitální kultury transformuje. Nejedná se pouze o změnu způsobu, kterým komunikujeme a ukládáme informace, jedná se hlavně o transformaci toho, jak přemýšlíme, žijeme a pracujeme. Posledních několik let je motivace zaměstnanců podrobena systematickému vědeckému zkoumání. Zaměstnavatelé se vlivem poznatků na toto téma postupně orientují nejen na uspokojování pořeb svých zákazníků, ale i na uspokojování potřeb svých zaměstnanců. Do popředí se začíná dostávat myšlenka, že jen spokojený zaměstnanec může pomáhat k vytváření spokojených zákazníků [34]. Záměrem této publikace není detailně vyjmenovat všechny postupy a techniky, kterými se vydávají společnosti při vycházení vstříc svým zaměstnancům. Nicméně stojíme před výběrem a nasazením informačního systému do moderní společnosti. Pro správné uchopení problému musíme tedy zohlednit i faktory určující komfort zaměstnanců. Prvním z nich je přívětivost programu pro zaměstnance. Práci s programem by měl zaměstnanec brát když ne přímo jako zábavnou tak aspoň ne jako frustrující. Ruku v ruce s tímto hlediskem jde i efektivita aplikace. Zaměstnanci musí nabízet rychlé a přehledné prostředí pro každodenní práci. V neposlední řadě musí systém i v plné šíři podporovat způsoby práce, které moderní společnosti považují za standard. Podívejme se tedy na historický vývoj běžně používaných technik práce vývojářských týmů a poté se zaměřme na agilní metodiky, které jsou v posledních několika letech přejímány softwarovými společnostmi [2]. V našem přehledu se nebudeme příliš orientovat na dopad agilních technik na zvýšení motivace zaměstnanců ani na kvalitu výsledného produktu. Tato srovnání byla daleko detailněji 12

18 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ popsána v jiných pracích, jež jsou k nalezení v seznamu literatury. 3.1 Code and Fix Jedná se o velice jednoduchý intuitivní způsob práce (Code and Fix, [33]). Volný překlad by mohl znít jako programování a opravy. V zásadě se jedná o systém s nulovým plánováním. Programátoři vyvíjejí software a pokud v průběhu vývoje narazí na chyby nebo problémy, zařídí jejch nápravu. Po opravě chyb pokračují opět v dalším vývoji. Nevýhodou tohoto systému je minimální návrh architektury projektu. Software vyvinutý touto metodou je obtížně udržovatelný, a proto je použitelný pouze pro jednoduché projekty. 3.2 Vodopádový model Předchozí model je přirozeným kontrastem k tomuto modelu (Waterfall, [41]). Celý vodopádový model je založený na silném plánování. Dopředu se naplánují fáze vývoje produktu i s odhady časových náročností a během vývoje produktu se projektový manažer snaží dodržet vytvořený plán. Fáze vodopádového modelu se mohou lišit jak do počtu, tak do pojmenování. V zásadě ale musí být dodrženo, že se vývoj může přesunout do další fáze až poté, kdy je současná fáze plně dokončena. Stejně jako vodopád nemůže téci nahoru, je cesta do předchozí fáze velice obtížně realizovatelná. Další charakteristickou vlastností vodopádového modelu je absence komunikace se zákazníkem. Zákazník dodá své požadavky a po dokončení vývoje je mu předán hotový produkt. Vodopádový model se mnohokrát ukázal jako ne zcela vhodný pro vývoj software, mimo jiné právě z důvodu, že se požadavky zákazníka neustále vyvíjejí a mění [12]. 3.3 Spirálový model Během osmdesátých let vývojáři experimentovali s různými alternativami k vodopádovému modelu. Na oblibě začaly získávat in- 13

19 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ Obrázek 3.1: Vodopádový model vývoje software krementální a iterativní přístupy. Inkrementální přístupy se vyznačují pravidelným vytvářením a uvolňováním fungujícího kódu po malých částech. Iterativní přístup pak do plánů zahrnuje i nabírání zpětné vazby od zákazníků a odhaduje čas potřebný k její analýze a implementaci (Spiral model, [12]). V roce 1986 došlo ke zveřejnění Spirálového modelu pro vývoj software. V tomto modelu je viditelný jak vodopádový přístup, tak i přístup iterativní. Můžeme v něm také najít silnou inspiraci v Demingově cyklu (PDCA, [32]). Software při aplikování spirálového modelu v principu neustále prochází čtyřmi fázemi. Nejprve určíme cíle, alternativy a omezení. Následně alternativy vyhodnotíme a vyvodíme rizika, poté dojde k samotnému vývoji s ověřováním a nakonec plánujeme další fáze. 3.4 Agilní metody V únoru roku 2001 skupina vývojářů kladoucích důraz na rychlý a efektivní vývoj softwaru položila základy agilnímu vývoji pomocí sepsání Agile manifesto [15]. Agilní princip navrhuje vývoj ve 14

20 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ formě po sobě jdoucích cyklů, kdy každý další si bere poučení z cyklů předchozích. Protože si autoři velmi zakládali na jednoduchosti návrhu, samotné Agile manifesto v originále sestává z reprezentativních 68 slov. Dále je pak rozvedeno do 12 principů, kterými by se měl vývoj řídit. Od samého základu klade agilní metodologie důraz na přímou a pravidelnou komunikaci lidí. At se jedná o komunikaci v rámci týmu nebo o komunikaci se zákazníkem. Přímá komunikace totiž, na rozdíl od psaní dlouhé dokumentace a dalších formalit, značně urychluje a zpřesňuje vývoj. V další řadě bere agilní manifest změnu zadání jako něco přirozeného a vítaného. Změny se přirozeně stávají a nemá jakýkoliv význam proti nim bojovat. Tímto se staví do přímé konfrontace s vodopádovým modelem. Od roku 2001 prošel agilní vývoj řadou zkoušek a byl rozveden do rozličných směrů. Jádro celé filozofie však zůstává stále atraktivní a firem, jež na agilní vývoj přechází, stále přibývá Kritiky agilní metodologie Po více než deseti letech od zformulování manifestu upozorňují i samotní zastánci agilních technik na jeho nedostatky a navrhují možné úpravy. Můžeme zmínit ku příkladu Toma Gilba, který ve své práci (Value-Driven Developlment Principles and Values, [20]) zmiňuje deset dalších bodů, které jsou ve dvanácti principech Agile manifesto bud nedotažené nebo opomenuté. Obecně se snaží upozornit spíše na to, že Agile manifesto mluví pouze o samotném vývoji a nikoliv o businessu, který by měl být vyvíjeným softwarem podporován. I další body Gilbovy kritiky manifest spíše rozšiřují, než že by ho od základů bořily, proto se v našem přehledu budeme držet původního znění manifestu. Nejlépe totiž vystihuje metodologii, podle které by se měl provádět celý vývoj softwaru, a tudíž i filozofii, které by se měly používané nástroje podřídit. 15

21 3.4.2 Základní typy agilních technik Scrum 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ je nejznámější a obecně nejpoužívanější agilní metodou (Scrum, [2]). Je možno jej aplikovat v malých i středně velkých týmech. (Větší týmy jsou obecně nevyhovující pro agilní přístup.) V základní podobě Scrumu pro malé týmy můžeme rozdělit tři základní role. Důležité je upozornění, že se jedná o dynamické role, nikoliv o pevné pracovní pozice. Proto někdo, kdo zastává jednu roli v týmu A, může zastávat jinou roli v týmu B. Stejně tak Scrum nezakazuje změnu rolí za běhu, staví se však proti přetěžování rolí - tedy proti tomu, aby lidé v rámci jednoho týmu zastávali několik rolí zároveň. Product Owner zastupuje zákazníka (dle anglické terminologie je zákazník stakeholder). Tuto roli musí zastávat člen týmu, který je se zákazníkem v kontaktu, zná přesně jeho požadavky a je si vědom přidané hodnoty, kterou pro něj produkt má představovat. Může pak přesně formulovat User Stories (budou popsány dále), kontrolovat výstupy dříve než jsou předvedeny zákazníkovi a při jakékoliv nejasnosti v zadání rozhodovat sám nebo zákazníka rychle kontaktovat. Scrum Master naopak řeší požadavky a problémy samotného týmu. Organizuje pravidelná jednání a zastává na nich pozici mediátora. Stará se také o vhodné zázemí členů týmu a pracuje na odstranění jakékoliv překážky, která ostatním členům brání v práci. Není vedoucím týmu, pouze vytváří bariéru mezi týmem a rušivými vlivy. Také dohlíží na dodržování Scrum metodiky. V žádném případě se nejedná o manažera týmu. Team Members neboli zbývající členové týmu jsou ti, na kterých stojí správné a včasné doručení produktu. Z našeho pohledu IT firmy se jedná o vývojáře, grafiky analytiky a další. Doporučený počet členů týmu je 3 až 9. Scrum mluví o samoorganizujícím týmu, takže žádné další role není potřeba přesně přiřazovat, nebot vykrystalizují samy. 16

22 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ Kromě rolí definuje Scrum i další pojmy, kterým je potřeba porozumět pro správné pochopení a nasazení techniky. V následném popisu si proto zároveň projdeme i další pojmy, které metodologie definuje, abychom měli přehled kompletní. User Stories popisují požadavky na funkcionalitu programu. Na začátku vývoje je potřeba získat od zákazníka zadání projektu. Tým toto zadání zanalyzuje a pokusí se ho rozdělit na jednotlivé atomické problémy. Tyto problémy označuje Scrum jako User Stories. Každé User Story přiřadí členové týmu odhadovanou složitost. Protože je každý tým a každý projekt hodně specifický, Scrum striktně zakazuje odhad v hodinách. Doporučuje odhad inspirovaný velikostmi triček. Dostáváme tedy vzestupný seznam: XS, S, M, L, XL, XXL a tak dále. Během prvních několika iterací bude Scrum Master schopen přiřadit přesnější časovou náročnost k jednotlivým úkolům. Product Backlog je seznamem všech analyzovaných User Stories. I tento seznam není pouze statickým plánem. V průběhu vývoje se budou měnit požadavky zákazníka a může docházet jak k mizení funkcí, které se časem ukázaly jako nepotřebné nebo zastaralé, tak i k přidávání jiných požadavků, které nově vyvstaly. Sprint je předem stanovená časová perioda vývoje. Některé články popisující Scrum věnují zásadní význam nultému Sprintu (Sprint Zero), který obsahuje nastavení podmínek, úvodní analýzu a vytvoření prvního základního produktu. V oficiální knize The Scrum Guide [43] ale žádný takový význam prvnímu běhu přikládán není, a proto budeme na všechny Sprinty pohlížet jako na rovnocenné. Délka každého Sprintu je v rámci projektu konstantní a metodologie doporučuje stanovit délku od dvou do čtyř týdnů (dle povahy projektu). Plannig Meeting je úvodní poradou Sprintu, na které se vyberou User Stories z Product Backlogu a stanoví se ty, které budou implementovány během aktuálního Sprintu. Vyberou se takové úkoly, které jsou relevantní pro zákazníka a zároveň jejichž součet obtížností nepřesahuje odhad, který je tým schopen za Sprint splnit. 17

23 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ Sprint Backlog uchovává seznam User Stories rezervovaných pro aktuální Sprint. Každý člen týmu si na sebe postupně bere úkoly. Po dokončení jednoho si vezme další a tak pokračuje dokud Sprint neskončí. Daily Scrum stanovuje denní operativu. Scrum doporučuje provádět každé ráno schůzky ve stoje (Stand Up Meetings), na kterých si členové řeknou, co se jim povedlo za včerejší den implementovat a jaké mají plány pro dnešní den. Na jednání se tedy zhodnotí, jestli tým stíhá časový plán, nebo jestli vývoji něco stojí v cestě a je potřeba překážku odstranit. Sprint Review je schůzka vedená na závěr Sprintu. Zde je prezentováno, čeho se povedlo za Sprint dosáhnout. Tým a ostatní zúčastněné strany zde probírají jak výsledky Sprintu, tak i další postup ve vývoji. Sprint Retrospective je další schůzkou vedenou na závěr Sprintu. Zde se účastníci domlouvají, co by v příštím Sprintu mohlo být provedeno lépe. Probírané je hlavně fungování týmu s ohledem na komunikaci a procesy. Dynamic Systems Development Method Tato technika je taktéž řazená mezi agilní metodiky, přestože historicky sahá až do roku 1994 (DSDM, [22]). Metoda je filozofií podobná Scrumu. Hlavní rozdíl mezi DSDM a jinými technikami je stanovení času jako fixní hodnoty a funkcionality programu jako hodnoty variabilní. Většina postupů naopak bere zadání funkcionality jako výchozí konstantu, dle které je pak doba trvání vývoje odhadovaná. Na rozdíl od jiných agilních technik se DSDM soustředí spíše na rychlé dodání produktu s vysokou přidanou hodnotou než na samotnou práci týmu. DSDM popisuje techniky, podle kterých by mělo jít jednoduše stanovit, které vlastnosti projektu jsou nezbytné a budou implementované přednostně. Technika DSDM definuje až 10 rolí v týmu, tedy výrazně více než dříve představený Scrum [14]. 18

24 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ Obrázek 3.2: Model techniky Scrum 19

25 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ Obrázek 3.3: Model Sprintu v rámcí techniky Scrum 20

26 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ Kanban Tento systém vznikl jako součást Toyota Production System v první polovině 20. století (Kanban, [44]). Používá se dodnes, aby zabránil zbytečné nadprodukci na výrobních linkách. Jeho hlavní předností je čistá vizuální forma, kterou převzali a pro své potřeby upravili i vývojáři software. V principu se jedná o tabuli vertikálně rozdělenou podle stavů, ve kterých se mohou jednotlivé úkoly nacházet. V IT se typicky jedná o stavy jako to do, doing, done, released. Jednotlivé stavy se samozřejmě liší podle požadavků konkrétních projektů. Samotné úkoly se pak ve formě lístečků horizontálně posunují mezi jednotlivými stavy. Toto znázornění úkolů a stavů vytváří vizuální zpětnou vazbu o celkovém postupu projektu. Obrázek 3.4: Ukázka kanban tabule, převzaté z [23] Spojením Agilního vývoje softwaru a kanbanu můžeme dle [23] hovořit o paradigmatu Agile kanban. Na začátku každé iterace dojde k rozdělení všech potřebných funkcí na User Stories, které pak rozdělíme na jednotlivé úkoly a uložíme je do prvního sloupce. Tím se první sloupec našeho kanbanu stává Sprint Backlogem, ze kterého si programátoři berou úkoly, pracují na nich a po dokončení je uvolňují. Když dojde k předčasnému ukončení všech úkolů ve Sprintu, můžeme snadno přidat další úkoly tím, že rozdělíme další 21

27 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ User Story z Product Backlogu a úkoly přidáme na kanban. Pokud se naopak úkoly dokončit nepodaří, zůstanou na kanbanu i po dokončení Sprintu. Obrázek 3.5: Hierarchie úkolů v Agile kanban 3.5 Motivace pracovníků Pohled na problém motivace pracovníků se během existence lidstva dramaticky vyvíjel. Způsob vedení lidí odrážel vždy atmosféru dané doby. Každá doba měla své manažery, kteří vedli své lidi způsoby, které vycházely z aktuálních potřeb historických epoch. Pro zjednodušení můžeme vývoj rozdělit na čtyři hlavní typy vedení lidí: Command and Control Vedení založené na rozkazování a kontrole vyžaduje absolutní poslušnost a slepé následování úkolů, které od managementu přicházejí (C&C, [8]). V historickém vývoji hrálo významnou roli a dominovalo velké části institucí. Jedná se o striktní vojenský typ řízení, který naprosto odmítá kreativitu a samostatnost podřízených. V IT sektoru tento systém nemá prakticky žádné opodstatnění. 22

28 3.5.2 Motivace založená na odměnách 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ Tato metoda je v dnešní době často používaná pro zvýšení motivace pracovníků. Zaměstnanci jsou více odměňováni, pakliže odvádí lepší výsledky. Celý systém stojí na myšlence, že největší motivací pro zaměstnance je číslo na jeho výplatní pásce. Bylo však opakovaně dokázáno, že pro většinu zaměstnanců není výše platu rozhodujícím motivačním prvkem [8]. Navíc zaměstnanec ztrácí zaměření na výsledný produkt a prosperitu firmy. Protože je pracovník postaven do role, kdy by se měl zajímat hlavně o svoji odměnu, vytváří tato metoda podhoubí pro podvádění. Nezáleží-li na samotném produktu, ale pouze na odměně za něj, není zaměstnanec tlačen k tomu, aby dodal nejlepší a nejvhodnější produkt, ale k tomu, aby odvedl takovou práci, která bude nejvíce odpovídat hodnoceným kritériím. Například odměňování programátorů podle počtu odevzdaných řádků kódu nevede k psaní programů rychleji, ale pouze k tomu, že programátoři vytváří rozvláčný a dlouhý zdrojový kód Identity Management Method Způsob motivace zaměstnanců přes sdílení společného cíle. Jako příklad efektivity této metody můžeme vzít společnost Apple, která dává svým zaměstnancům pocit, že vytváří jedinečné produkty (IMM, [47]). Další důležitým prvkem pro úspěšné zavedení této motivační metody jsou častá setkání zaměstnanců v mimopracovních podmínkách. Motivovat pracovníky přes IMM většinou vyžaduje, aby manažer dobře znal každého svého zaměstnance a dokázal ho patřičně směrovat a oceňovat. V neposlední řadě musí společnost působit dojmem, že svým zaměstnancům plně věří a nesmí před nimi skrývat žádné důležité informace Management 3.0 Tento termín byl poprvé představen ve stejnojmenné knížce od Jurgena Apella [5]. V této knížce se autor snaží podat ucelenější pohled na celou problematiku motivování zaměstnanců, než ji nabízí IMM. 23

29 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ Autor tak popsal 7 bodů, které vzniknou spojením myšlenek Agilního manifestu s disciplínou managementu. Tyto body jsou: Nabudit lidi Největší hodnota, kterou firma vlastní, jsou právě její zaměstnanci, jejich znalosti a jejich touha a schopnost pracovat. Zplnomocnit týmy Agilní vývoj závisí na samoorganizujících týmech. Pouze tyto týmy totiž dokáží plně využít potenciál motivovaných lidí. Nastavit bariéry I kreativní práci musí být správně nastaveny bariéry. S žádnými nebo špatně nastavenými mantinely může dojít k chaosu nebo vyhoření. Rozvíjet kompetence Jedním ze základních předpokladů pro úspěšný agilní vývoj jsou právě členové týmu, kteří mají potřebné dovednosti. Proto se členové i manažeři musí vzájemně podporovat v dalším vzdělávání. Tuto myšlenku prezentuje i Peter Senge v knížce The Fifth Discipline, kde proces nikdy nekončícího rozvíjení kompetencí označuje pojmem Personal Mastery (Personal Mastery [45]). Zdůrazňuje, že lidé, kteří stavu Personal Mastery dosahují, rozvíjí nejen své pracovní, ale i osobní a společenské schopnosti. Růst struktury Je mylnou představou, že v agilních týmech není potřeba žádná struktura. Bez struktury by došlo ke zmatku v zodpovědnostech a komunikaci. Pro manažery je tedy žádoucí správně nastavit strukturu týmu. 24

30 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ Neustále vylepšovat Jedna z nejdůležitějších vlastností, která přínáší organizaci stabilitu, je neustálý vývoj a vylepšování. Učení se novému a poučení z vlastních chyb je i podle Petera Senge jednou z pěti hlavních disciplín, které vedou k úspěšnému fungování učících se organizací [45]. 3.6 Práce týmů v kontextu softwarových nástrojů Po uvedení do současné problematiky vývoje software a způsobu vedení týmů si můžeme položit otázku, co by měl splňovat nástroj pro vhodnou spolupráci samoorganizujících týmů. Vezměme tedy 12 principů Agilního manifestu jakožto základ, kterým se inspiruje většina současných softwarových společností, a podívejme se, jak tyto zásady ovlivní pohled na informační systém [15]. Naší nejvyšší prioritou je vyhovět zákazníkovi časným a průběžným dodáváním hodnotného softwaru. [15, princip 1] Tento bod manifestu je zaměřený na schopnosti, disciplínu a správné odhady členů týmu. Musíme si tedy položit otázku - jak může informační systém pomoci ke zvýšení těchto vlastností týmu? Především práce v systému musí být velice rychlá aby programátory nezdržovala od samotného vývoje. Pokud by kvůli software docházelo ke zbytečným prodlevám, členové týmu by ho neviděli jako výhodu a nechtěli by s ním pracovat. Z agilního pohledu by s programem měli zaměstnanci pracovat dobrovolně, protože by si měli uvědomovat výhody, které přináší. Systém také musí zjednodušovat odhadování obtížnosti jednotlivých úkolů. Musí z něj být jednoduše a rychle patrné, kde se v rámci vývoje nacházíme, kolik stanovených úkolů máme již za sebou a kolik jich zbývá. Stejně tak musí systém každému zaměstnanci umožňit zapsat, kolik času na jednotlivých úkolech strávil. Tento záznam přinese výhody jak pro samotný přehled odhadů, tak pro přesnější dokumentaci o odvedené práci pro zákazníka. Vizuální zpětnou vazbu a jednoduché měnění stavu úkolů nejlépe splňují systémy, se kterými se dá pracovat ve stylu kanbanu. 25

31 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ Pouhým pohledem je možno přesně určit, kde se projekt nachází a kdo na čem pracuje. Měnit stavy úkolů můžeme jednoduchým přetahováním mezi sloupci. Vítáme změny v požadavcích, a to i v pozdějších fázích vývoje. Agilní procesy podporují změny vedoucí ke zvýšení konkurenceschopnosti zákazníka. [15, princip 2] Zmíněná zásada agilního software stojí v opozici proti klasickému plánování a detailním Ganttovým grafům (Ganttův graf, [40]). Nebudeme proto po software vyžadovat možnost plánovat tímto způsobem dlouhodobě dopředu, naopak se zaměříme na to, aby bylo vytváření nových a úprava stávajících úkolů co nejjednodušší a nejrychlejší. Dodáváme fungující software v intervalech týdnů až měsíců, s preferencí kratší periody. [15, princip 3] Tato zásada charakterizuje princip agilní práce. V našem informačním systému musí být pro členy týmu jasně odlišitelné úkoly náležící aktuální iteraci od úkolů, které tým už nezajímají, bud protože už byly splněny, nebo protože se s jejich realizací počítá až v budoucí iteraci. Úkoly hotové z minulých iterací můžeme v běžných programech bud archivovat nebo odfiltrovat díky stavu hotovo. Pokud ve zvoleném programu pro projektovou zprávu nebude možno odfiltrovat úkoly, které patři k budoucím iteracím, je možné tento požadavek řešit například vytvořením dvou projektů. Jeden pro seznam budoucích úkolů a druhý pro projekt fyzický ( Plán pro projekt web, Práce na projektu web ). Lidé z byznysu a vývoje musí spolupracovat denně po celou dobu projektu. [15, princip 4] Komunikace je velmi důležité téma. Je potřeba organizovat pravidelné osobní schůze, komunikovat telefonicky, mailem, chatem. Požadavkem na software z tohoto pohledu je především agregace kontaktů jak na zákazníka, tak i na členy firmy ( , telefon, jabber). Dále by systém mohl napomáhat v jednoduché organizaci osobních schůzek a jako platforma pro zaznamenávání zápisů ze schůzek s distribucí zúčastněným stranám. 26

32 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ Budujeme projekty kolem motivovaných jednotlivců. Vytváříme jim prostředí, podporujeme jejich potřeby a důvěřujeme, že odvedou dobrou práci. [15, princip 5] Bod pojednává o příjemném prostředí. Často zaměstnanci upřednostňují svobodu v pohybu. Mnoho pracovníků dnes pracuje z domu, z kaváren, z horských chat a dalších exotických míst. Náš informační systém tedy musí být stejně pohodlně přístupný z jakékoliv lokace a jakéhokoliv zařízení (počítejme dnešní triádu tablet, telefon, notebook). Software na správu projektů v podobě webové aplikace je v dnešní době logickou volbou. Velkou výhodou by pro informační systém bylo, kdyby nabízel i plně funkční mobilní aplikaci nebo alespoň responsive design web pro zjednodušení práce z mobilních zařízení (Responsive design, [30]). Dalším ukazatelem, který vytváří příjemné prostředí, je samotný vzhled a ovládání aplikace. Jedná se o jednu z nejdůležitějsích charakteristik jakéhokoliv programu, a proto ji i zahrneme při výběru metriky pro hodnocení software. Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace. [15, princip 6] Jakým způsobem spolu budou komunikovat jednotliví členové týmu neovlivníme přímo v software. Vývojáři často pracují z různých míst po světě. V některých nadnárodních společnostech se spolupracovníci v životě neviděli. Informační systém může maximálně zjednodušit organizování schůzek a uchovávat kontakty na všechny členy, aby spolu mohli případně komunikovat přímou formou (telefonicky, domluvit si osobní schůzku). Hlavním měřítkem pokroku je fungující software. [15, princip 7] Kvalita kódu je ovlivněna jak znalostmi a schopnostmi vývojářů, tak i jejich vzájemnou komunikací a vhodnou specifikací. Informační systém nemůže přímo ovlivnit schopnosti vývojářů, měl by ale poskytnout vhodnou platformu pro komunikaci a ukládání znalostí. 27

33 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ Systém wiki se v posledních letech těší velké oblibě jako platforma pro spolupráci při vytváření dokumentů (Wiki, [28]). Snadná editace obsahu a verzování plní všechny požadavky na ukládání znalostí. Informační systém by proto měl ke každému projektu umožnit ukládání správných postupů a důležitých informací obdobným způsobem, jako to umožňuje systém wiki. Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržet stálé tempo trvale. [15, princip 8] Sponzoři, vývojáři i uživatelé často připomínkují programy v průběhu jejich používání bez ohledu na agilní metodiky, iterace nebo sprinty. Aby bylo dosaženo udržitelného vývoje a oprav chyb, musí být všechny tyto požadavky uchovávány a pravidelně vyhodnocovány. Je potřeba vyhodnotit všechny chyby od těch, jež vznikají jen nepozorností uživatele, až po ty, jež jsou naopak chybami kritickými a které musí být opraveny s nejvyšší prioritou. Systém pro zaznamenávání chyb se v angličtině nazývá bug tracker. Trh obsahuje širokou škálu komplexního softwaru pro zaznamenání chyb. Pro rychlý agilní vývoj nám však stačí jen jednoduchá metoda, nicméně při stanovení metriky musíme brát v potaz i tento požadavek. Jednoduchost umění maximalizovat množství nevykonané práce je klíčová. [15, princip 9] Toto pravidlo platí jak pro vývoj, tak i pro práci se software. Proto budeme hodnotit jeho minimalismus a jednoduchost. Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu. [15, princip 10] Sebemotivace a touha po neustálem vzdělávání a vytváření nejlepších výsledků je něco, co IS nemůže ovlivnit. Jedná se o vlastnosti vývojářů, které by pro ně měly být naprosto přirozenými. Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů. [15, princip 11] 28

34 3. PRÁCE VÝVOJÁŘSKÝCH TÝMŮ Efektivní fungování samoorganizujícího se týmu je silně ovlivněno správným balancováním se sdělování informací. Každý člen týmu musí vědět, které problémy je vhodné řešit se kterou skupinou lidí a které informace se vyplatí zaznamenat do databáze znalostí projektu. Při nevhodném nakládání s informacemi může dojít jak k zahlcení všech členů týmu (při přílišném dokumentování), tak i naopak k chybám vyplývajících z rozhodnutí učiněných bez kompletní znalosti problému. Typickou chybou tohoto druhu je známé reinventig the weel, kdy pracovníci věnují čas řešení problému, který před nimi už někdo vyřešil. Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti. [15, princip 12] Pro udržení stability a stabilního růstu je tento bod velice významný. Je neustále opakován v různých pramenech, již dříve jsme zmiňovali Learning Organisation od Peter Sange [45] nebo Management 3.0 od Jurgena Apello [5]. Z pohledu IS by bylo vhodné, aby samotný tým pravidelně reflektoval svou práci se systémem. Na základě nových poznatků pak tým může případně sám upravovat zdrojový kód programu, aby IS maximálně odpovídal firemním procesům. Tohoto může být docíleno, pakliže si systém firma vytvoří sama nebo použije již funkční open-source software. 29

35 Kapitola 4 Pilíře menších a středně velkých společností Na závěr minulé kapitoly jsme prošli prvky, které by software měl splňovat z pohledu agilní metodiky. Tu jsme zvolili, protože popisujeme koncept IS, který budou používat firmy, jež se zabývají vývojem software. V následující kapitole projdeme konkrétní vlastnosti, které by software měl splňovat. 4.1 Firma z pohledu klasického projektového managementu Dle metodologie projektového řízení se můžeme na zakládání menší firmy nebo na její jednotlivé zakázky podívat jako na projekty [40]. Tato metodologie nám při plánování projektu klade 5 základních otázek, na které bychom měli před započetím práce získat odpověd. Těchto 5 otázek projektového řízení bude mít samozřejmě pro každou firmu jiné odpovědi. Podíváme se, jak se tyto otázky prolínají s agilními technikami a jestli by mohl informační systém pomoci v hledání příslušných odpovědí Co? At již budeme ve firmě vyvíjet zakázkový software nebo jen poskytovat SaaS, musíme vědět, co a pro koho vytváříme. IS by nám měl tedy poskytnout vhodné úložiště pro dokumenty, které definují zadání a úložiště kontaktů na zákazníky a stakeholdery. 30

36 4. PILÍŘE MENŠÍCH A STŘEDNĚ VELKÝCH SPOLEČNOSTÍ Jak? Klasický projektový management popisuje jako odpověd na tuto otázku rozdělení závislostí jednotlivých částí projektu. Z pohledu Agilního vývoje jsou všechny důležité závislosti členům týmu známé. Závislosti se promítají do pořadí, podle kterého jsou jednotlivé úkoly seřazeny v Backlogu. Opět nám zde tedy vyvstává potřeba definovat v rámci IS úkoly, které se budou řešit aktuálně, a úkoly, které je potřeba řešit v budoucnosti Kdy? Srovnáme-li, jak tuto otázku řeší Scrum, a jak na ni odpovídá klasický PM, dostaneme se vždy k závěru, že je velmi důležité ukládat časové/obtížnostní náročnosti úkolů (popřípadě User Stories). Obecně je můžeme pojmenovat jako odhady. Zda je budeme ukládat jako bezrozměrná čísla, nebo jako hodinové odhady, není z pohledu software důležité S kým? Klasický management se dívá na lidskou práci jako na zdroje. Agilní vývoj naopak staví samotné pracovníky více do popředí. Protože nás zajímá agilní práce, nechceme centralizovaný direktivní systém s přiřazováním práce jednotlivým zdrojům. Zaměstnanci musí mít možnost přebírat si úkoly sami. Pro zlepšení psychologického dojmu z komunikace se skutečnými lidmi by bylo vhodné, aby systém nabízel možnost přidat fotky ke každému zaměstnanci. Zvýšila by se tím i podvědomá přívětivost systému, zaměstnanec by neměl pocit, že pracuje s pouhými daty Za kolik? Klasický PM dává odpověd na otázku Za kolik? až na závěr, kdy už máme odhadnuto, který pracovník bude na kterých úkolech pracovat. Při aplikaci Scrumu se odhadu trvání úkolů také využívá. Technika je ale navržena tak, aby chybné odhady měly co nejmenší negativní dopad na vývoj projektu. V klasickém PM můžou mít chybné odhady na úspěch projektu fatální dopad. 31

37 4. PILÍŘE MENŠÍCH A STŘEDNĚ VELKÝCH SPOLEČNOSTÍ IS může přispět k upřesnění odhadů tím, že nabídne možnost zapisovat odhadovanou délku trvání jednotlivých úkolů a také každému zaměstnanci umožní ukládat, kolik času na úkolu strávil. 4.2 Stavební kameny IS Definicí většiny požadavků, které jsou v dnešní době kladeny na IS menších IT firem, se pomalu dostáváme k modelu, jak by měl takovýto software skutečně vypadat a co všechno by měl splňovat Obecné vlastnosti IS Rozdělme požadavky pro systém na dvě skupiny. Na ty, které musí být v systému bezpodmínečně obsaženy, a na ty, jenž jsou pro firmu přínosné, ale nejsou nezbytně nutné. Navíc některé úkony označíme za kritické. U těch budeme vyžadovat, aby je uživatelé mohli provádět s maximální efektivitou a minimální komplexností. Důležité vlastnosti software Z předchozích kapitol vyplývá, že se v první řadě musí jednat o online aplikaci pracující ve webovém prohlížeči, která bude nainstalovaná na firemních serverech. Tím bude splněna stálá dostupnost aplikace a firma zároveň nebude muset spoléhat na uchování svých nejdůležitějších dat u třetích stran. Tento požadavek zároveň navádí i k tomu, abychom se věnovali především open-source řešením, které si můžeme jak nainstalovat na vlastní server tak i dle vlastní potřeby upravit. Optimální by bylo nalézt jeden systém, který bude splňovat všechny naše požadavky. Pakliže se ale nepodaří najít celistvý systém, budeme muset vybrat více programů, mezi kterými bude jednoduché sdílet data a přihlašovací údaje uživatelů (zaměstnanců firmy). Vhodné vlastnosti software Bylo by vhodné, aby pro maximální komfort uživatelů informační systém měl i aplikaci pro mobilní zařízení (tablety, mobilní telefony) 32

38 4. PILÍŘE MENŠÍCH A STŘEDNĚ VELKÝCH SPOLEČNOSTÍ nebo alespoň webovou aplikaci pro tato zařízení vhodně uzpůsobenou. 4.3 Správa projektů Jádrem celé firmy je informační systém, jádrem informačního systému je správa projektů. Chod firmy se točí kolem plánování, vytváření a přiřazování úkolů Důležité vlastnosti software pro správu projektů V první řadě systém pro projektovou správu musí umožňovat kompletní správu uživatelských účtů a práv. To znamená vytváření nových uživatelů, správu hesel, správu kontaktů na uživatele, nastavování přístupových práv a nastavení viditelnosti objektů. Budeme předpokládat nízkou fluktuaci zaměstnanců, a proto nebudeme tento proces považovat za kritický. Další podmínkou pro práci se software je vytváření projektů a následné připojování zaměstnanců, kteří na projektu spolupracují. Stejně tak by projekty neměly být viděny od zaměstnanců, kteří k nim připojeni nejsou. U každého projektu je pak potřeba vytvářet a upravovat úkoly. Práce s úkoly je kritický úkon, který by měl probíhat s maximální efektivitou. Software tedy budeme mezi sebou porovnávat taktéž podle rychlosti, s jakou je možno manipulovat s úkoly. Každý úkol může bud čekat bez přiřazení, nebo být přiřazen na pracovníka, který na něm plánuje pracovat. Software musí být schopen přehledně zobrazit úkoly, na kterých dělá zvolený zaměstnanec. Kritický je úkon, kdy si zaměstnanec úkol přiřazuje sám na sebe (bere úkol za svůj a začne na něm pracovat). Stejně tak musí sytém umožňovat zaměstnancům k úkolům přidávat počet odpracovaných hodin a minut. Zaznamenávání času je kritickým úkonem, proto by bylo ideální, aby měl u každého úkolu zaměstnanec tlačítko pro začátek práce na úkolu a konec práce na úkolu, aby docházelo k automatickému zaznamenávání stráveného času. Stejně tak systém musí umožňovat přehledný výpis stráveného času na každém projektu a také pro jednotlivé zaměstnance. 33

39 4. PILÍŘE MENŠÍCH A STŘEDNĚ VELKÝCH SPOLEČNOSTÍ Tato funkcionalita velmi usnadní jak vyplácení mzdy zaměstnanci, tak i fakturaci zákazníkovi. Každý úkol bude během svého životního cyklu procházet několika stavy. Ty mohou být pro každý projekt nebo alespoň pro každou firmu lehce rozdílné, proto by měl systém umožňovat úpravu těchto stavů. Přepínání úkolu mezi stavy je úkon, který se bude opakovat velice často, a proto se opět jedná o úkon kritický. Systém by měl jednoduchým způsobem umožňovat udržování seznamu úkolů, které jsou pro daný projekt relevantní, ale nepatří do aktuální iterace. Z pohledu Scrumu se tedy jedná o Project Backlog. Tento seznam nesmí být součástí seznamu úkolů patřících do aktuální iterace (Sprint Backlogu) mimo jiné i z psychologických důvodů, aby se zaměstnanci necítili přeúkolovaně při pohledu na všechnu práci, která ještě nebyla započata. Pokud nebude systém tuto funkci podporovat, bylo by možné ukládat potřebné úkoly do vlastního vedlejšího projektu. V tom případě by měl systém podporovat jednoduché přesouvání úkolů mezi projekty Vhodné vlastnosti software pro správu projektů Pro osobnější pocit při práci se systémem by bylo vhodné udržovat ke každému uživateli jeho fotku. Software by měl umožňovat uložit odhadovanou dobu/složitost každého úkolu. Pokud toto nebude systém umožňovat explicitně, je možné vždy připsat odhadovanou složitost úkolu k jeho popisu. Přehledný pohled na splněné a rozpracované úkoly umožňuje kanban. Tomuto přístupu jsme se již věnovali v předchozí kapitole. I komerční software pro vedení agilních projektů často kanban nabízí (napříkal GreenHopper od firmy Atlassian nebo Kanban Board v Microsoft Visual Studiu 2012). Bylo by vhodné, aby vybraný software tento pohled podporoval. O pojmu bug tracking jsme se již zmiňovali. Značné urychlení firemních procesů by přineslo, kdyby klienti a uživatelé mohli do systému sami přidávat chyby, na které v software narazili. Pokud tuto funkci nebude systém podporovat, může být pro klienty vytvořen speciální projekt nebo dokument, kam mohou nalezené chyby psát. 34

40 4. PILÍŘE MENŠÍCH A STŘEDNĚ VELKÝCH SPOLEČNOSTÍ 4.4 Správa dokumentů Touto problematikou se zabývá Enterprise Content Management (ECM, [27]). Do českého jazyka je tento pojem překládán jako správa firemního obsahu. Zatím neexistuje ustálený pohled na to, co všechno do firemního obsahu spadá. Dle [27] můžeme jako firemní obsah brát prakticky jakýkoliv soubor strukturovaných nebo nestrukturovaných informací. Můžeme zde proto řadit i y, weby, multimédia a znalosti (firemní dokumentace a postupy). Pro velké firmy i státní orgány má správa dokumentů zásadní význam. Často je potřeba do ní zahrnout i skenování a ukládaní tištěných dokumentů, převod skenovaných dokumentů do textové podoby, celý workflow dokumentů a mnoho dalších prvků [24]. V naší práci se však zaměřujeme na menší firmy operující v sektoru IT. Ty by se ale měly z praktických důvodů snažit o minimalizaci nedigitální podoby dokumentů (snadnější úprava, manipulace, distribuce atd.). Pro tyto firmy má daleko větší význam řešit správu souborů v populárních formátech jako je odt, doc, docx, xls, pdf, videa, html či wiki stránky, obrázky, grafické návrhy a další formy elektronického obsahu. Ke správnému uložení potřebujeme znát jak samotná data, tak i jejich kontext (metadata). Například číslo 1205 je pouhou hodnotou a nedává nám žádnou informaci, když nevíme, zda se jedná o letopočet nebo popisné číslo domu. Pro plné ukládání informací a jejich správné načítání musíme ukládat ke každým datům i metadata. Požadavky pro ukládání dat jsou tedy z pohledu naší hypotetické firmy velice obecné. Zaměříme se primárně na uchovávání digitálních dat, které musí splňovat několik bodů Document Management System (DMS) Systém pro správu dokumentů je důležitou komponentou ECM. Jedná se o program nebo skupinu programů, která udržuje informace o elektronických dokumentech. Zpravidla takový systém uchovává metadata i všechny verze dokumentů, zodpovídá za bezpečnost uchování a umožňuje vyhledávání v dokumentech. Pro komunikaci DMS přes internet je definovaný protokol zvaný Content Management Interoperability Services (CMIS, [7]). 35

41 4. PILÍŘE MENŠÍCH A STŘEDNĚ VELKÝCH SPOLEČNOSTÍ Důležité vlastnosti software pro správu dokumentů Potřebujeme ukládat data k jednotlivým projektům. Grafické návrhy jednoho projektu by neměly kolidovat s návrhy jiného projektu. Proto bude potřeba k jednotlivým dokumentům také nastavovat viditelnost dle příslušnosti k projektům. Data musí být uložena hierarchicky, aby přesně reflektovala stromovou strukturu, na kterou jsou uživatelé zvyklí z počítačových souborových systémů. Pro maximální flexibilitu a bezpečnost musí systém archivovat každou změnu dokumentu. Toto chování systému označíme jako verzování. Významnou součástí správy dokumentů je také možnost v nich vyhledávat. Software tedy musí mít fulltextové vyhledávní i nad dokumenty v binárních formátech (MS Office, LibreOffice). Pro zjednodušení workflow musí mít zaměstnanci možnost přihlásit se k odběru informací o změnách souboru. Kdykoliv dojde k nahrání nové verze, budou všichni přihlášení uživatelé na změnu upozorněni Vhodné vlastnosti software pro správu dokumentů Pro zjednodušení práce s dokumenty by bylo vhodné mít k nim přístup jak přes webové rozhraní (popřípadě mobilní aplikaci), tak i přímo přes souborový systém uživatele. Mluvíme tu tedy o možnosti připojit se k dokumentům pomocí protokolů jako jsou Network File System (NFS, [1]) nebo File Transfer Protocol (FTP, [7]). 4.5 Správa kontaktů Program pro správu kontaktů je v dnešní době nedílnou součástí jakékoliv společnosti. Pro naší softwarovou firmu bude potřeba aplikace, která svojí funkcionalitou spadá do množiny systémů vyvýjených pro CRM neboli obchodní oddělení firem. Tyto systémy jsou v podnicích klíčové pro správnou funkci obchodních oddělení. V CRM systémech zaměstnanci udržují seznamy osob a firem (tak zvané leads ), které by bylo vhodné kontaktovat nebo které 36

42 4. PILÍŘE MENŠÍCH A STŘEDNĚ VELKÝCH SPOLEČNOSTÍ už kontaktovány byly. Ke každé položce v seznamu je potřeba vést záznamy o tom, jak komunikace s lead probíhá. V systému je potřeba taktéž uchovávat zápisy z jednání a konkrétní znění dohod i s cenovými nabídkami, aby obchodníci měli přehled a firma působila konzistentně Důležité vlastnosti software pro správu kontaktů V některých případech je potřeba přidávat kontakty na jednotlivé osoby, v jiných zase naopak na celé firmy, popřípadě zaměstnance do firem sdružovat. Toto jsou tři základní vlastnosti, které musí CRM systém splňovat, aby mohl být plnohodnotně využíván. Dále musí náš CRM umožňovat ukládání zápisů z jednání, telefonátů a mailů. Komunikace mezi firmami probíhá neustále nejen v době vyjednávání proto je žádoucí mít kdykoliv k dispozici celou její historii Vhodné vlastnosti software pro správu kontaktů Ke komunikaci se zákazníky také patří vytváření a organizování schůzek, kterých se účasní několik stran. Proto by bylo vhodné, kdyby náš systém pomohl zorganizovat schůzku, automaticky na ni všechny členy pozval a požádal je o potvrzení účasti. Některé komerční CRM systémy (například CapsuleCRM) usnadňují archivaci ové komunikace pomocí odesílání její kopie na definovanou ovou adresu poskytnutou CRM systémem. Jakýkoliv , který na tuto adresu příjde, je automaticky archivován a přiřazen odpovídajícímu klientovi v CRM systému. 4.6 Přechod firmy na nový systém Zavedení nových pracovních postupů a nasazení nového IS ve firmě je velmi razantní změnou. Aby se nám povedlo takovou změnu provést úspěšně, budeme při procesu vycházet z metodologie J. Kottera, který věnoval více než 30 let právě analýze změny. Ve své práci prezentuje 8 hlavních kroků pro úspěšné provedení změny [26]. Proces úspěšné změny dle Kottera prochází všemi těmito kroky a většinou právě v tomto pořadí: 37

43 4. PILÍŘE MENŠÍCH A STŘEDNĚ VELKÝCH SPOLEČNOSTÍ Vyvolání vědomí naléhavosti Změně nejvíce pomůže, pokud si ji přeje celá společnost. Proto je důležité vytvořit pocit potřeby změny. Tento pocit je vhodným podnětem pro motivaci posouvat věci ve firmě dále. Pro vytvoření naléhavosti však nestačí jen ukazovat grafy s křivkami znázorňujícími, jak je současný stav pro firmu nevýhodný. Kotter navrhuje především otevřený, upřímný a přesvědčivý dialog o tom, co se právě děje na trhu a u konkurence. Jakmile o změně začne mluvit více lidí uvnitř firmy, potřeba začne stavět sama na sobě lavinovým efektem Sestavení koalice schopné prosadit a realizovat změny Přesvědčení lidí, že je změna důležitá, často vyžaduje vedení a podporu klíčových lidí uvnitř firmy. Změnu nestačí jen navrhnout a organizovat, je potřeba ji i vést. Pro správné prosazení změny je nezbytné najít výkonné vedoucí napříč celou firmou z různých firemních pozic a různou expertýzou. Tým zformovaný z takovýchto přesvědčených lidí je pro úspěšné zavedení změny zásadní Vytvoření vize Změna často sestává z různých nápadů, které postupně vyplývají při diskuzi nad současným stavem. Tyto nápady a útržky je potřeba zaštítit jednotnou vizí. Ucelená vize pomůže lidem pochopit, proč je žádáme dělat něco nového a měnit věci, na které jsou zvyklí. Když lidé sami pochopí, čeho se snažíte změnou dosáhnout, začnou jim změny dávat smysl v širším kontextu Komunikace transformační vize Co je s vizí provedeno po jejím vytvoření určuje její úspěch. Vize musí být často opakovaná napříč firemním prostředím, protože jinak by mohla zapadnout nebo být vytlačena jinou představou. Nestačí vizi předávat jen na určených setkáních, je potřeba o ní mluvit kdykoliv máme příležitost. 38

44 4. PILÍŘE MENŠÍCH A STŘEDNĚ VELKÝCH SPOLEČNOSTÍ Odbourání překážek Pakliže se proces změny dostal až do tohoto stádia, znamená to, že změně všichni rozumějí a často se o ní ve firmě mluví. Je tedy důležité položit si otázku, co stojí realizaci změny v cestě. Může se jednat jak o současné procesy tak i o zavedené struktury. Je proto potřeba neustále rozpoznávat a odstraňovat bariéry, které stojí změně v cestě. Lidem dodá odstranění bariér motivaci v pokračování, protože uvidí, že změna je opravdu možná Vytváření krátkodobých vítězství Není nic, co by motivovalo lidi víc než úspěch. Je dobré ukázat celé společnosti dílčí úspěchy už v začátcích procesu. Je potřeba, aby bylo poměrně rychle vidět, že změna opravdu dává smysl. V opačném případě je velká šance, že proces neustojí tlak kritky a nedojde k jeho úspěšnému dokončení Využití výsledků a podpora krátkých změn Jeden z hlavních důvodů, proč velká část změn selže, je podle Kottera stanovení úspěchu příliš brzy. Opravdové změny musí jít daleko hlouběji a jejich výsledky by měli být rozsáhlejší než jen pár prvních krátkodobých vítězství. Například uvolnění prvního produktu, který je podpořen novým procesem, je krátkodobé vítězství. Teprve úspěšné uvolnění deseti takovýchto produktů ukáže opravdový přínos změny. Než se však firma dostane k desátému produktu musí změna stále probíhat a proces musí být neustále vylepšován Zakotvení nových přístupů do firemní kultury Aby se jakákoliv změna udržela, musí se stát pevnou součástí celé společnosti. Kultura společnosti většinou určuje, jak se má ve firmě postupovat. Proto by měly být hodnoty naší vize viditelné v každodenní firemní práci. Stejně tak je důležité, aby současní ani nově příchozí lídři změnu nepřestali podporovat. V této kapitole jsme vycházeli z obecných předpokladů, které by měla většina firem naplňovat. Díky tomu jsme definovali obecné 39

45 4. PILÍŘE MENŠÍCH A STŘEDNĚ VELKÝCH SPOLEČNOSTÍ vlastnosti, které by měl IS pro menší IT firmy obsahovat. Na závěr jsme prošli body, kterými by měla změna firemního IS procházet, aby došlo k jeho úspěšnému zavedení. V dalším textu se budeme věnovat konkrétněji analýze procesů ve firmě inqool a.s., pro kterou budeme software vybírat a nasazovat. 40

46 Kapitola 5 Analýza ve firmě Firma InQool a.s. je mladou IT společností založenou v roce V současné době se zaměřuje jak na tvorbu zakázkového software, tak i na vývoj vlastních produktů, kterým sama zajišt uje marketing a prodej. 5.1 Firemní struktura Firma InQool je akciovou společností, kterou vedou tři výkonní manažeři. Částečně se jejich funkce překrývají, můžeme však díky nim firmu rozdělit na tři primární struktury. Personání a projektový manažer zodpovídá především za nabírání nových zaměstnanců, za organizaci jejich práce a jejich adekvátní odměňování. Ředitel technologií odpovídá za vývoj software. Plánuje strukturu a vhodnou implementaci projektů, vybírá pro ně vhodné technologie a zpracovává cenové odhady. Výkonný ředitel řeší hlavně obchodní záležitosti firmy. Především tedy jedná se stávajícími i potenciálními klienty a prezentuje firmu a její produkty. Na starosti má teké celý obchodní a marketingový tým. Ve firmě dále pracují zaměstnanci jako jsou programátoři, sít oví administrátoři, grafici, obchodníci a další. Pro naše potřeby nemusíme rozlišovat, zda-li jsou daní zaměstnanci externí, tedy osoby samostatně výdělečně činné, nebo zda se jedná o interní trvalé zaměstnance firmy. Z pohledu organizace práce se nejedná o rozdílné typy, 41

47 5. ANALÝZA VE FIRMĚ Obrázek 5.1: Struktura fimy inqool a.s. protože i stálým zaměstnancům nabízí firma inqool volnou pracovní dobu a možnost pracovat odkudkoliv. Velká část zaměstnanců firmy inqool jsou prezenční studenti, proto je nepravidelná pracovní doba jednou s typických vlastností firmy. V předchozí kapitole jsme rozebírali Scrum a jeho pozitivní vliv na vývoj software. Z důvodu nepravidelné pracovní doby ale nebude možné ve firmě striktní Scrum nasadit. Při návrhu organizování práce se tedy agilními metodikami můžeme pouze inspirovat. Do firmy budeme muset nasadit řešení, které vytvoří jistý kompromis mezi doporučenou agilní metodikou a tím, co si ve firmě mohou z její podstaty dovolit. 42

48 5. ANALÝZA VE FIRMĚ 5.2 Systém přidělování HW Ve velkých firmách většinou zaměstnanci z bezpečnostních důvodů dostávají firemní počítače (popřípadě i telefony a další zařízení). V menších firmách toto často z různých důvodů zvykem není, například protože firmy své zaměstnance nechtějí omezovat ve výběru. Tyto firmy tedy nasazují politiku Bring your own device (BYOD, [9]). Za cenu nižších nákladů tím riskují možnost bezpečnostního úniku, pokud zaměstnanci nemají své počítače dostatečně zabezpečeny. To, že zaměstnanci mohou pracovat odkudkoliv na svých vlastních zařízeních, je součástí firemní politiky i ve společnosti inqool. Za správu přístupových údajů zaměstnanců je ve firmě zodpovědný centrální LDAP server. Všechny služby s podporou LDAP jsou přes něj synchronizované. 5.3 Současně používané programy Ve firmě se současně používá několik programů pro správu projektů, sdílení dokumentů, organizaci času a komunikaci s klienty. Tento heterogenní způsob práce bez centrálizovaného systému výrazně snižuje efektivitu zaměstnanců a vedoucích pracovníků. Zároveň také současné řešení neumožňuje spolehlivou zálohu a jednotné vyhledávání ve všech firemních záznamech Organizace a plánování V současné chvíli používá firma inqool na organizování práce svých zaměstnanců program Mantis. Zaměstnancům tento systém nevyhovuje, protože není přehledný, obsahuje spoustu nadbytečných informací, které nevyužívájí, a běžné úkony v něm zabírají zbytečně mnoho času. Jméno: Mantis BT Web: < Licence: GNU GPL 43

49 5. ANALÝZA VE FIRMĚ Kategorie programu: Systém pro zaznamenávání chyb (bug tracking system) Technické detaily: Mantis je naprogramovaný v PHP a kompatibilní s MySQL, MS SQL a PostgreSQL. Podporované systémy pro instalaci jsou Windows, Linux, Mac OS a OS/2. Obrázek 5.2: Program Mantis BT Jedná se o robustní systém pro evidenci chyb u velkých projektů, které mají tisíce uživatelů. K tomuto byl program primárně určen a tuto funkci plní správně. Zároveň je použitelný jak při práci na proprietárním software, tak i pro open-source projekty. Program ale není vhodný pro vedení vývoje projektů. Každý záznam v databázi považuje Mantis jako nahlášení chyby, kterou je potřeba odhalit a opravit. Proto ke každé chybě nabízí i číslo řádku, na kterém se chyba nachází, popis opravy, verzi programu, u které došlo k opravě, a další pro vývoj nových projektů zbytečné položky Správa stráveného času zaměstnanců V současné chvíli firma inqool nemá žádný způsob jak ukládat, kolik času strávili zaměstnanci na jednotlivých úkolech. Zaměstnanci 44

50 5. ANALÝZA VE FIRMĚ pouze ukládají do Excel dokumentu celkový čas, který strávili daný den v práci. Toto firmě neumožňuje jakýmkoliv způsobem určovat délku odpracované doby pro jednotlivé zákazníky Ukládání dokumentů Důležitost perzistence firemních dokumentů již byla probírána v předchozí kapitole. V současné době ve firmě inqool není nasazené žádné unifikované řešení pro správu firemního obsahu. Zaměstnanci firmy používají k předávání dokumentů podle potřeby především dvě webové služby. Jméno: Dropbox Web: < Licence: Tento software je proprietární. Není možné získat jeho zdrojové kódy a je nabízený jako SaaS. Základní velikost úložného prostoru je nabízena zdarma. Rozšiřování velikosti a další funkce jsou zpoplatněny. Kategorie programu: Jednoduchá služba pro online ukládání souborů Technické detaily: Služba je aktivní už od roku Program je napsaný v jazyce Python a nabízí jak přístup ke službě přes webové rozhraní, tak i klienty pro řadu populárních platforem (Microsoft Windows, Linux, Mac OS X, ios, Android a další). Program Dropbox nabízí možnost pracovat se soubory jak přes webové rozhraní, tak i pomocí aplikace, která synchronizuje soubory fyzicky na disku klienta. S kolegy je možné sdílet a synchronizovat celé složky pomocí sdílených adresářů nebo jen nabízet aktuální verze jednotlivých souborů pomocí HTTP odkazů. Ve firmě inqool jsou na práci s programem Dropbox zvyklí a vyhovuje jim. Díky přímému připojení souborů na disk uživatele je služba velice efektivní. Hlavní nedostatky jsou uzavřenost služby a nutnost platit za sdílený obsah. Stejně tak přidání nového zaměstnance do systému vždy znamená nastavování všech složek s projekty, ke kterým by měl dostat přístup. Ideální by tedy bylo najít alternativu uživatelsky velice podobnou službě Dropbox. 45

51 5. ANALÝZA VE FIRMĚ Obrázek 5.3: Program Dropbox Jméno: Google Drive Web: < Licence: Tento software je proprietární. Není možné získat jeho zdrojové kódy a je nabízený jako SaaS. Základní velikost úložného prostoru je nabízená zdarma, rozšiřování velikosti a další funkce jsou zpoplatněny. Kategorie programu: Služba pro online ukládání souborů a online spolupráci Technické detaily: Google nabízí kompletní textový editor, tabulkový editor a aplikaci pro vytváření prezentací ve webovém rozhraní. Dále nabízí možnost synchronizovat soubory na klientském disku pomocí podobné služby jako Dropbox. Klient v současné době podporuje systémy Microsoft Windows, Mac OS X, Android, ios a Chrome OS, neexistuje oficiální podpora pro linux. Google Drive je služba velmi podobná předchozímu Dropboxu. Přidanou hodnotu, kterou svým zákazníkům nabízí navíc, je synchronizované upravování dokumentů pomocí webového rozhraní. Tato možnost z něj dělá vynikající prostředek pro online týmovou spolupráci. Ve firmě inqool je tato funkcionalita využívána pro komunikaci s klienty, ukládání zpráv z porad i zapisování docházky 46

52 5. ANALÝZA VE FIRMĚ Obrázek 5.4: Program Google Drive zaměstnanců Komunikace s klienty Přestože vztahy s klienty řeší v současnou chvíli prakticky pouze jeden člověk, vznikla ve firmě samovolně potřeba využívat CRM systém. Tento jev upevňuje tvrzení z předchozí kapitoly, kdy jsme postavili CRM systém mezi tři nejdůležitější pilíře IS malých IT firem. Jméno: Capsule CRM Web: < Licence: Tento software je proprietární. Není možné získat jeho zdrojové kódy a je nabízený jako SaaS. Základní funkce jsou nabízené zdarma, rozšiřování počtu uživatelských účtů v rámci jedné organizace a další funkce jsou zpoplatněny. Kategorie programu: CRM systém Technické detaily: Program běží jako webová aplikace, na serveru je napsaný v jazycích Java a Scala. V prohlížeči se kód opírá o backbone.js. Tato aplikace podobně jako Dropbox nebo Trello plní svůj úkol velice dobře. Práce v ní je velice přímá a efektivní. Splňuje dokonce téměř všechny funkční požadavky, které jsme stanovili na CRM systém v předchozí kapitole. Umožňuje i organizovat čas a vytvářet 47

53 5. ANALÝZA VE FIRMĚ Obrázek 5.5: Program CapsuleCRM úkoly. Jejím hlavním nedostatkem je proprietární licence a poplatek za využívání v závislosti na velikosti organizace. V rámci bezplatného využívání je možné, aby do systému měli přístup jen dva uživatelé. Protože se snažíme najít finančně nejvýhodnější variantu pro společnost inqool, pokusíme se najít alternativu i tomuto systému. 5.4 Chybějící prvky a vlastnosti Z pohledu na společnost, který jsme představili v předešlých odstavcích, chybí v současném IT řešení firmě inqool několik prvků a vlastností, které by plnohodnotný informační systém měl obsahovat. V první řadě jsme předeslali, že systém by měl být pokud možno co nejvíce jednolitý a konzistentní. Tento požadavek, jak bylo nastíněno v předchozích odstavcích současné, řešení ve firmě inqool rozhodně nesplňuje. Stejně tak současná řešení nedávají možnost, aby firma mohla mít data uložená u sebe na svém serveru, protože většina služeb, jež inqool využívá, je nabízená pouze ve formě SaaS. Z konkrétních prvků systému chybí firmě například centralizovaný seznam pracovníků, kde by na sebe jednotliví zaměstnanci mohli sehnat kontakt v případě, že by potřebovali řešit naléhavé zá- 48

54 5. ANALÝZA VE FIRMĚ ležitosti. Dále firma nemá vypracovaný způsob jak ukládat informace o přesném objemu času, který její zaměstnanci strávili na jednotlivých úkolech. Zapisuje se pouze celkový čas, který byl strávený na projektu. 5.5 Návrh nových procesů Po analýze stávajících postupů vývoje produktů ve firmě inqool jsme vytvořili unifikované diagramy, které vznikly sloučením firemní kultury s metodikou Scrum. Je na nich znázorněno, jak by se ve firmě mělo postupovat při řešení zakázky. Grafy prezentují jak postup při vývoji software, tak i úkony, které budou požadovány po informačním systému. Protože pro téměř každý úkon je potřeba interakce s IS, není v grafu pro přehlednost IS vyznačen. (Měl by být zakreslen jako back box entita.) Interakci s IS vyžaduje každý úkol, který je označený jako User Task. (Dle BPMN notace obsahuje ikonku uživatele.) Model práce na projektu 5.6 představuje způsob, jak bude ve firmě inqool při vytvoření nového projektu manažer a obchodní zástupce pracovat s informačním systémem. Diagram 5.7 pak znázorňuje průběh sprintů v rámci práce na projektu. V modelech je patrná inspirace v agilních technikách, která se projevuje především v definici backlogů a v iterativním přístupu k vývoji. Modely představují chování systému a fáze, kterými prochází při interakci s uživateli. Díky formálně definovaným potřebám můžeme nyní začít pro firmu inqool hledat vhodné softwarové zázemí. Při vývoji systémů je naprosto běžné, že zákazník při testování nebo i plném provozu narazí na implementační nebo funkční chyby. Model 5.8 představuje proces, podle kterého bude ve firmě inqool docházet k zaznamenávání chyb. Procesy pro shromažd ování obchodních kontaktů a vyjednávání při vzniku nové zakázky jsou zaznamenány na diagramech 5.9 a

55 5. ANALÝZA VE FIRMĚ Obrázek 5.6: Model procesu práce na projektu 50

56 5. ANALÝZA VE FIRMĚ Obrázek 5.7: Model procesu Sprint při práci na projektu 51

57 5. ANALÝZA VE FIRMĚ Obrázek 5.8: Model procesu na zaznamenávání chyb při vývoji 52

58 5. ANALÝZA VE FIRMĚ Obrázek 5.9: Model procesu představující vznik nového projektu 53

59 5. ANALÝZA VE FIRMĚ Obrázek 5.10: Model práce obchodního zástupce 54

60 Kapitola 6 Stanovení kritérií pro hodnocení software Na trhu je k dispozici rozsáhlé množství software pro správu projektů, dokumentů a kontaktů. Testovat detailně každý program by bylo příliš náročné, proto testování rozdělíme na dvě fáze. První fázi můžeme přirovnat k prohledávání do šířky. Stanovíme si jednoduchá kritéria, která musí software splňovat, a pokud jim bude jeho funkcionalita odpovídat nebo bude svou funkci plnit výrazně lépe než konkurenční produkty, postoupí do druhé fáze. Takto rychle otestujeme širokou škálu řešení, která trh nabízí. Druhá, detailní fáze testování pak bude probíhat nad výrazně menší množinou produktů. 6.1 Kritéria pro první fázi testování Všechna softwarová řešení musí obecně vyhovovat následujícím podmínkám. 1. Software musí pracovat jako služba přes webové rozhraní. 2. Musí být možné software nainstalovat, provozovat a data ukládat na vlastním serveru. 3. Pakliže se jedná o open-source projekt, nesmí být zastaralý a musí mít aktivní komunitu. 4. Software musí mít možnost synchronizovat uživatele pomocí protokolu LDAP, abychom mohli využít stávající infrastrukturu. 55

61 6. STANOVENÍ KRITÉRIÍ PRO HODNOCENÍ SOFTWARE Kritéria pro správu projektů 1. Systém musí podporovat vytváření projektů, přidávání uživatelů a vytváření úkolů. 2. Projekty musí být viditelné pouze pro uživatele, kteří jsou k nim přihlášeni. 3. K úkolům musí být možné přidávat čas, který na něm pracovníci strávili. 4. U úkolů musí být možné měnit stavy (hotovo, rozpracováno a další). 5. Software musí nabídnout každému zaměstnanci možnost zobrazit seznam všech jeho kolegů Kritéria pro správu kontaktů 1. Musí být možno přidávat jak kontakty na celé společnosti, tak i kontakty na jednotlivé lidi. 2. Kontakty na pracovníky musí být možné agregovat pod firmu. 3. Ke každému kontaktu musí být možnost přidávat komentáře a shrnutí z jednání Kritéria pro správu dokumentů 1. Ukládání dokumentů do hierarchické struktury. 2. Nastavování přístupových práv všem uživatelům. 3. Fulltextové vyhledávání v dokumentech Cena řešení Z důvodu minimalizace nákladů na nasazení a provoz software firma inqool trvá na open-source řešení, proto budeme brát v potaz pouze otevřené projekty, které můžeme nasadit na firemní servery. 56

62 6. STANOVENÍ KRITÉRIÍ PRO HODNOCENÍ SOFTWARE Otázku, zda-li použití otevřeného software opravdu náklady redukuje, projednávala například studie [38], která došla k pozitivním závěrům. Další výhodou je, že programátoři z firmy si také budou moci dále aplikace upravovat podle svých potřeb. I z pohledu soukromí se jedná o výhodné řešení (firma uchovává svá vlastní data). 6.2 Přesnější kritéria pro druhou fázi Na druhou fázi testování již budeme mít připravenou množinu softwaru, o které víme, že splňuje naše základní požadavky na funkcionalitu. Budeme tedy testovat především vlastnosti uživatelského rozhraní jednotlivých produktů. Pro objektivní měření těchto vlastností budeme vycházet z metriky Scenairo-Based UX metrics scorecard (SBUMS, [21]), kterou pro měření vlastností UI navrhuje Phil H.Goddard, Ph.D. z Human Factors International. Připravíme si scénáře, které nás zajímají v rámci navržených procesů pro firmu inqool z předchozí kapitoly, a otestujeme, s jakou efektivitou je možno tyto scénáře provádět ve vybraných aplikacích. Abychom odhalili, zda budou programy efektivní právě pro naše potřeby, použijeme pro simulaci ty úkony, které v procesech obsahují cyklické a časté opakování. Obchodní scénář: Obchodní zástupce právě narazil na zajímavého zákazníka a uzavřel s ním dohodu. Chce ted do systému přidat novou zakázku. Projektový scénář: Projektový manažer potřebuje požádat zaměstnance, aby vytvořil HTML a CSS kód pro novou šablonu v PSD formátu z programu Photoshop. Scénář pro práci s dokumenty: Grafik vytvořil několik grafických návrhů webu a uloží je přes webové rozhraní na společný server. Rychlost, s jakou můžeme scénář pomocí daných nástrojů provést, pak budeme hodnotit za pomocí spojením měřítek, které na- 57

63 6. STANOVENÍ KRITÉRIÍ PRO HODNOCENÍ SOFTWARE vrhuje SBUMS a měřitek, které odpovídají požadavkům sledované firmy. Konkrétně budeme hodnotit z těchto pohledů: Navigace určuje, jak jednoduché je dostat se z úvodní stránky k provedení našeho scénáře a jak intuitivní jsou všechny kroky. Zároveň budeme tyto jednotlivé kroky počítat. Za krok považujeme nutnost posunout se dále ve struktuře webu. Tedy vyplnění položky formuláře není krokem, zatímco odeslání celého formuláře nebo kliknutí na odkaz krokem je. Důležitým měřítkem je také práce s obsahem (ukládání dokumentů, nebo textu) a možnost napojení systému na další služby. Obsah jednotlivých stránek, které nás provází při naší cestě úkolem, je také významné měřítko. Samozřejmě by mělo být obsahu co nejméně a měl by být co nejvíce relevantní našemu úkolu. Systém by neměl zobrazovat zbytečné informace. Prezentace je celkový dojem ze systému a grafická přívětivost. Interakce si klade otázku, zda-li způsob, jakým s námi systéme komunikuje, odpovídá našim předpokladům a zda-li nám podle toho také pomáhá vhodně jednat. Integrace nám udává, jak moc je komplikované propojit aplikaci s dalšími systémy. Hodnotíme zde zejména dostupné přídavky pro aplikaci a pokročilost Application Programming Interface (API, [4]), tedy rozhraní, které nám aplikace nabízí pro přípojení jiných služeb. Knowledge management znamená, jak systém pracuje se znalostmi a dokumentací u projektů, popřípadě na kolik je schopen využít pro tuto správu software jiných stran. Přístupnost rozděluje body podle toho, zda-li nám produkt může nabídnout mobilní aplikaci nebo alespoň plnohodnotný mobilní web. Protože produkty hodnotíme relativně, nikoliv absolutně (jak popisuje původní SBUMS), budeme rozdávat čísla v závislosti na tom, kolikátý se daný produkt umístil ve srovnání s ostatními (tedy 1 znamená nejlepší). 58

64 6. STANOVENÍ KRITÉRIÍ PRO HODNOCENÍ SOFTWARE 6.3 Stanovení metriky pro porovnání zlepšení Abychom mohli přesně určit jak naše řešení ovlivnilo pracovní výkon zaměstnanců, musíme stanovit metriku, podle které budeme změnu počítat. Jak jsme již zmiňovali, našim hlavním poždavkem na nástroj je jeho efektivita. Chceme minimalizovat čas, který zaměstnanci musí trávit s nástrojem na správu úkolů a naopak maximalizovat čas, který jim zbyde na samotnou práci. Stanovíme si tedy Key Performace Indicator (KPI, [36]) jako dobu, kterou zaměstnanci stráví ve webovém prohlížeči na stránkách nástroje pro organizaci práce. Tuto dobu budeme měřit pomocí rozšíření do prohlížeče Chrome, které se nazývá Time Tracker [17]. Primárně je určeno pro sledování objemu času stráveného na jednotlivých stránkách. Aby program posloužil našemu záměru, nastavíme čítač na nulu a uvidíme, o jak velký časový úsek se zaměstnancům odpočet u firemních nástrojů zvýší za týden práce. Po nasazení našeho řešení do firmy počkáme dostatečně dlouho, než si zaměstnanci na práci s programem zvyknou, a provedeme opětovné měření. Nakonec porovnáme výsledky a vyvodíme závěry. 59

65 Kapitola 7 Zhodnocení dostupných produktů Tato kapitola se věnuje praktickému výběru vhodného software popsaným způsobem dle stanovených kritérií. 7.1 První fáze Systémy pro správu projektů Jméno: trac Web: < Licence: Upravená BSD licence Kategorie programu: Primárně se jedná o program na zaznamenávání chyb (bug tracking). Spadá tedy do podobné kategorie jako dříve zmiňovaný Mantis a není pro naše potřeby příliš vhodný. Primární programovací jazyk: Python Závěr: Program nepodporuje ukládání stráveného času zaměstnanců. Obecně se jedná spíše o aplikaci z kategorie bug tracking než systém pro správu projektů. Jméno: WebIssues Web: < Licence: AGPL Kategorie programu: Bug Tracking Primární programovací jazyk: PHP Závěr: Tento program také nepodporuje ukládání stáveného času 60

66 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Obrázek 7.1: Ukázka programu trac zaměstnanců a jeho podstatou je spíše zaznamenávání chyb než zadávání úkolů pro vývoj nových projektů. Jméno: Mantis BT Obrázek 7.2: Ukázka programu WebIssues Web: Licence: GPL Kategorie programu: BugTracker Primární programovací jazyk: PHP Závěr: Na program jsme již narazili v předchozí části práce. Nepodporuje ukládání stráveného času zaměstnanců. Není vhodný jako 61

67 systém pro správu projektů. 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Jméno: BugZilla Obrázek 7.3: Ukázka programu Mantis BT Web: < Licence: MPL Kategorie programu: BugTracker Primární programovací jazyk: Perl Závěr: Bugzilla je další ukázkou programu primáně pro bug tracking, který není příliš vhodný pro plánování a správu projektů. Jméno: Redmine Web: < Licence: GPL Kategorie programu: Webová aplikace pro správu projektů Primární programovací jazyk: Ruby Další funkce: Jako doplněk je možno k systému doinstalovat CRM systém i kanban pohled na úkoly. Taktéž je možno použít systém pro správu informací o projektech (knowledge management) díky integrované wiki a ukládání souborů. 62

68 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Obrázek 7.4: Ukázka programu BugZilla Závěr: Jedná se o program pro správu projektů. Redmine je velice obsáhlý a obsahuje velké množství doplňků, pomocí kterých je možno funkcionalitu dále upravovat. Komunita kolem projektu je široká a aktivní. Program umožňuje i ukládat strávený čas k jednotlivým úkolům. Systém odpovídá našim požadavkům. Obrázek 7.5: Ukázka programu Redmine Jméno: ClockingIT Web: < Licence: MIT/X11 Kategorie programu: Webová aplikace pro ukládání úkolů a stráve- 63

69 ného času Primární programovací jazyk: Ruby 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Závěr: Komplexní systém pro evidenci projektů a stráveného času s integrovaným chatem a seznamem kontaktů. Projekt ale není dále vyvíjen ani upravován. Poslední úprava kódu byla provedena před třemi lety. Obrázek 7.6: Ukázka programu ClockingIT Jméno: FengOffice Community Edition Web: < Licence: AGPL Kategorie programu: Software pro spolupráci týmu Primární programovací jazyk: PHP Závěr: FengOffice je primárně nabízený jako SaaS. My jsme se ale zaměřili na Comunity Edition, která je open source. Feng Office nabízí vytváření projektů, úkolů, seznamu zaměstnaců i ukládání stráveného času k jednotivým úkolům. V současné verzi ale není možné zjistit, kolik času který zaměstnanec dohromady odpracoval. Systém tedy neodpovídá naším požadavkům. Jméno: PHProjekt 64

70 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Obrázek 7.7: Ukázka programu FengOffice Community Edition Web: < Licence: LGPL Kategorie programu: Správce úkolů Primární programovací jazyk: PHP Závěr: Projekt je sice aktivní, ale v současné chvíli nepodporuje všechny potřebné funkce a není ani plně dokončený. Obrázek 7.8: Ukázka programu PHProjekt Jméno: Codendi Community Edition Web: < 65

71 Licence: GPL 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Kategorie programu: Systém pro správu projektů Primární programovací jazyk: PHP Závěr: Program je obsáhlý a na první pohled nepřehledný. Ve své komunitní verzi navíc nepodporuje kompletní funkcionalitu. Pro naše potřeby je tedy nevhodný. Obrázek 7.9: Ukázka programu Codendi Community Edition Jméno: Trello Web: < Licence: Nabízeno zdarma jako SaaS pro libovolné využití Kategorie programu: Aplikace pro sdílení a organizování úkolů Primární programovací jazyk: JavaScript (node.js, backbone.js) Závěr: Trello je velice efektivní program pro organizování menších a středně velkých týmů pomocí kanbanu. Nabízí i mobilní aplikaci s plnou funkčností pro všechny populární platformy. Za využívání všech funkcí programu není potřeba platit žádné poplatky a autoři slibují, že se tato politika v budoucnu nezmění. Z našich požadavků nesplňuje možnost nasazení aplikace na vlastním serveru a ukládání stráveného času. Protože je aplikace výrazně efektivnější a přehlednější než ostatní, postupuje i přes nedostatek se stráveným časem do druhého kola. 66

72 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Obrázek 7.10: Ukázka programu Trello Jméno: Collabtive Web: < Licence: GPL Kategorie programu: Systém pro správu projektů Primární programovací jazyk: PHP Závěr: V tomto programu není možno přiřazovat úkoly zaměstnancům. Z našeho pohledu je nevyhovující. Obrázek 7.11: Ukázka programu Collabtive Jméno: Web2project Web: < Licence: GPL 67

73 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Kategorie programu: Webová aplikace pro správu projektů Primární programovací jazyk: PHP Závěr: Systém není přehledný a neodpovídá našim požadavkům na jednoduchou a přímočarou aplikaci. Tato webová aplikace by byla vhodnější na správu velkých projektů ve společnostech, které kladou větší důraz na robustnost než na efektivitu nástroje. Jméno: XPlanner+ Obrázek 7.12: Ukázka programu Web2project Web: < Licence: LGPL Kategorie programu: Nástroj pro podpru agilního vývoje Primární programovací jazyk: Java Závěr: Webová aplikace splňuje požadavky na agilní vývoj. Nabízí možnost definovat iterace a User Stories. Jejím velkým nedostatkem je však nízká přehlednost a neaktivita komunity. Vývoj projektu více jak rok stojí. Jméno: IceScrum Web: < Licence: AGPL 68

74 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Obrázek 7.13: Ukázka programu XPlanner+ Kategorie programu: Webová aplikace pro striktní Scrum vývoj Primární programovací jazyk: Java Závěr: Tato webová aplikace je vhodná pro týmy, které plánují nasadit striktní Scrum. To ale není situace, která by se týkala firmy inqool. Obrázek 7.14: Ukázka programu IceScrum Jméno: Zimbra Web: < Licence: Zimbra Public License 69

75 Kategorie programu: Webový mailový klient Primární programovací jazyk: Java 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Další funkce: Aplikace Zimbra může být díky doplňkům taktéž použita jako CRM systém. Závěr: Zimbra je komplexni mailový klient vhodný pro týmovou spolupráci. K dispozici ke stažení je také mnoho rozšíření. Primárně je však Zimbra navržená pro práci s maily, organizování práce není silnou stránkou programu. Jméno: KForge Obrázek 7.15: Ukázka programu Zimbra Web: < Licence: GPL Kategorie programu: Portál pro správu velkých projektů Primární programovací jazyk: Python Závěr: Aplikace nabízí rozsáhlou funkcionalitu. Navržená je však pro správu velkých open-source projektů, jejichž vývoje se účastní stovky lidí. Pro menší firmu s desítkou zaměstnanců vhodná není. Jméno: Launchpad 70

76 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Obrázek 7.16: Ukázka programu KForge Web: < Licence: AGPL Kategorie programu: Portál pro správu velkých projektů Primární programovací jazyk: Python Závěr: Aplikace je velice podobná programu KForge. A stejně tak je koncipovaná pro správu open-source projektů, nikoliv pro firmu s desítkou zaměstnanců. Jméno: OpenERP Web: < Licence: AGPL Kategorie programu: Komplexní ERP systém Primární programovací jazyk: Python Další funkce: OpenERP je možno použít taktéž jako plnohodnotný CRM systém. Závěr: Webová aplikace je komplexní a nabízí správu velkých firem od projektů přes sklady až po knihu jízd a obědy pro zaměstnance. 71

77 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Obrázek 7.17: Ukázka programu Launchpad Kdybychom však použili pouze pár modulů z nabídky, dostaneme jednoduchý a přehledný systém pro správu kontaktů a projektů. Aplikace nabízí i ukládání stráveného času a kanban pohled na rozpracované projekty. Systém odpovídá našim požadavkům. Obrázek 7.18: Ukázka programu OpenERP Jméno: Tryton Web: < Licence: GPL Kategorie programu: Komplexní ERP systém Primární programovací jazyk: Python 72

78 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Závěr: Jedná se o klon OpenERP. V současné době nemá funkční webové rozhraní. Obrázek 7.19: Ukázka programu Tryton Jméno: Teamlab Office Open Source Version Web: < Licence: AGPL Kategorie programu: Správa projektů a online kanceláře Primární programovací jazyk: C# Závěr: Komerční verze aplikace splňuje většinu našich požadavků. Open-source verze je již půl roku beze změny a nenabízí plnou funkcionalitu. Jméno: Tree.io Web: < Licence: Creative Commons Attribution-NonCommercial 3.0 License Kategorie programu: Správa projektů a online kanceláře Primární programovací jazyk: Python 73

79 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Další funkce: Tree.io nabízí funkcionalitu CRM systému. Závěr: Jedná se o webovou službu, která splňuje všechny naše požadavky na organizování práce a ukládání stráveného času. Systém nabízí i ukládání kontaktů. Dokonce Tree.io nabízí i integrovaný chat. Tento systém odpovídá našim požadavkům. Jméno: Tactic Obrázek 7.20: Ukázka programu Tree.io Web: < Licence: Eclipse Public License Kategorie programu: Správa projektů vytvářejících digitální média Primární programovací jazyk: Python Závěr: Jedná se o program, jehož primárním cílem je spravovat vývoj digitálního obsahu. Je napsaný přímo pro firmy, které vytváří grafiku, modely a multimédia. Pro firmu, která primárně vytváří software, vhodný není. Jméno: ADempiere Web: < Licence: GPL Kategorie programu: Kompletní implementace ERP systému 74

80 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Obrázek 7.21: Ukázka programu Tactic Primární programovací jazyk: Java Závěr: Velice komplexní aplikace pro správu ERP vhodná pro podniky, které pracují s fyzickými komoditami. Pro organizování projektů věnujících se vývoji aplikací je nevhodná. Obrázek 7.22: Ukázka programu ADempiere Jméno: LibrePlan Web: < Licence: AGPL 75

81 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Kategorie programu: Implementace ERP systému Primární programovací jazyk: Java Závěr: Komplexní ERP systém, jeho hlavní předností jsou možnosti plánování a generování Ganttových diagramů. Pro námi stanovené potřeby je systém příliž rozsáhlý. Jméno: Plandora Obrázek 7.23: Ukázka programu LibrePlan Web: < Licence: LGPL Kategorie programu: Komplexní plánování zdrojů a výdajů Primární programovací jazyk: Java Závěr: Jedná se o komplexní projekt, který nabízí finanční a časové plánování podniků. Pro naše potřeby řízení vývojových projektů je nevhodný Systémy pro správu souborů Jméno: Apache Jackrabbit Web: < 76

82 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Obrázek 7.24: Ukázka programu Plandora Licence: Apache License 2.0 Kategorie programu: Správce obsahu Primární programovací jazyk: Java Závěr: Apache Jackrabbit je správce repozitáře, který sám nenabízí žádné webové rozhraní. Je nutno k němu připojovat klienty například přes CMIS protokol. My hledáme programové řešení, které nám rovnou poskytne i webové rozhraní. Jméno: Nuxeo 5 Web: < Licence: LGPL Kategorie programu: Enterprise Content Management System Primární programovací jazyk: Java Závěr: Jedná se o systém pro správu digitálního obsahu, který splňuje všechny naše požadavky včetně verzování všech změn i synchronizace souborů v adresářovém systému u klienta pomocí aplikace Nuxeo Drive. Systém odpovídá našim požadavkům. Jméno: MyDMS Web: < 77

83 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Obrázek 7.25: Ukázka programu Nuxeo 5 Licence: GPL Kategorie programu: Jednoduchý systém na správu obsahu Primární programovací jazyk: C# Závěr: Systém je příliš jednoduchý, nepodporuje verzování ani synchronizaci klientského souborového systému. Jméno: Alfresco Share Web: < Licence: LGPL Kategorie programu: Enterprise Content Management System Primární programovací jazyk: Java Závěr: Jedná se o systém pro správu digitálního obsahu, který splňuje všechny naše požadavky včetně verzování všech změn. Synchronizace souborů v adresářovém systému u klienta je možno pomocí aplikace CmisShare. Systém odpovídá našim požadavkům Systémy pro správu kontaktů Jméno: Zurmo 78

84 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Obrázek 7.26: Ukázka programu Alfresco Share Web: < Licence: GPL Kategorie programu: CRM systém Primární programovací jazyk: PHP Závěr: Plně funkční CRM systém, který splňuje všechny naše požadavky. Obrázek 7.27: Ukázka programu Zurmo Jméno: SplendidCRM Web: < 79

85 Licence: AGPL Kategorie programu: CRM systém Primární programovací jazyk: C# 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Závěr: Rozsáhlý CRM systém, který pokrývá daleko více požadavků, než které jsme na systém kladli my. Jméno: FatFreeCRM Obrázek 7.28: Ukázka programu SplendidCRM Web: < Licence: MIT Kategorie programu: CRM systém Primární programovací jazyk: Ruby Závěr: Plně funkční CRM systém, který splňuje všechny naše požadavky. Jméno: SugarCRM s Sugar Community Edition Web: < Licence: AGPL Kategorie programu: Komplexní CRM systém Primární programovací jazyk: PHP 80

86 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Obrázek 7.29: Ukázka programu FatFreeCRM Závěr: Rozsáhlý CRM systém, který pokrývá daleko více požadavků, než které jsme na systém kladli my. Obrázek 7.30: Ukázka programu SugarCRM s Sugar Community Edition 81

87 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ 7.2 Druhá fáze Naším eliminačním procesem v první fázi prošly čtyři aplikace na správu projektů, tyto aplikace obsahují zároveň i CRM modul s plnou funkcionalitou, kterou vyžadujeme pro správu kontaktů. Abychom zvýšili kompaktnost celého řešení, použijeme pro správu CRM kontaktů stejný systém jako pro správu projektů. Pro správu digitálního obsahu nám zbyly celkem dvě možná řešení. Z těchto dvou vybereme takové, které půjde lépe zaintegrovat do systému na správu projektů Obchodní scénář Obchodní zástupce právě narazil na zajímavého zákazníka a uzavřel s ním dohodu. Chce ted do systému přidat novou zakázku. Redmine (plugin Contacts) Ke kontaktům je potřeba přistupovat přes samotný projekt, což bohužel ubírá navigaci. Samotné vytváření a úprava kontaktů je pak ale uživatelsky přímočará a rychlá. Modelový scénář je pak možno provést v 5 krocích. OpenERP CRM v tomoto systému nabízí mnoho možností. Uživatelsky je velmi přímočaré a efektivní, navigačně přesné a graficky zajímavé. Modelový scénář je možno provést ve 4 krocích. Z prezentačního pohledu je velmi povedená správa obchodů pomocí kanbanu. Tree.io Přístup ke kontaktům je v hlavní nabídce. Vytváření nových kontaktů ale zabírá více kroků, než u konkurenčních produktů. Pro průchod modelovým scénářem je potřeba 7 kroků. 82

88 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Tabulka 7.1: Vyhodnocení obchodního scénáře Redmine Tree.io OpenERP Navigace Obsah Prezentace Interakce Integrace Knowl. mgmt Přístupnost Projektový scénář Projektový manažer potřebuje požádat zaměstnance, aby vytvořil HTML a CSS kód pro novou šablonu v PSD formátu z programu Photoshop. Redmine Tento nástroj je přímo napsaný pro správu vývoje software. Je poměrně robustní a nabízí široké možnosti úprav a nastavení dle potřeb projektů a vývojářů. Grafická podoba nástroje je ucházející, ale z pohledu prezentace se nejedná o jednoduchý nástroj. Modelový scénář v něm vychází na 6 kroků. Další nespornou výhodou je zabudování knowledge managementu přímo v Redmine. Je možné zde ke každému projektu ukládat wiki stránky i spravovat diskuzní fóra. Stejně tak je možné systém pomocí rozšíření spojit s DMS systémem pomocí CMIS protokolu. Do Redmine jsou k dispozici přídavky pro podporu kanbanu, nenabízí však takový komfort jako kanban v Trello nebo OpenERP. OpenERP Software je určen primárně pro správu celých podniků, na rozdíl od Redmine není přímo optimalizován na správu softwarových projektů. Z grafického a prezentačního pohledu se jedná o povedený nástroj, který pro každý projekt nabízí přehledný kanban. Modelový scénář je možné v něm provést na čtyři kroky. 83

89 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Oproti Redmine se jedná o navigačně přívětivější a prezentačně přehlednější nástroj. V současné verzi však naprosto chybí jakýkoliv knowledge management a není k dispozici ani možnost propojení s DMS systémem. Tree.io V této aplikaci není možné modelový scénář provést příliš efektivně, protože Tree.io nepodporuje vkládání souborů přímo k jednotlivým úkolům. Proto je nutné úkol i dokument vložit zvlášt a celá procedura sestává z 9 kroků. Prezenčně je systém na vyšší úrovni než Redmine. Co se týká knowledge managementu systém nabízí možnosti ukládání souborů i editaci jednoduchých textových dokumentů. Nenabízí ale možnost spojit dokumenty s projekty nebo úkoly. Taktéž není k systému možno přímo připojit žádný externí DMS systém. Trello Ze všech testovaných se jedná o nejefektivnější a nejintuitivnější aplikaci na správu úkolů. Pro uložení nového úkolu s dokumentem je potřeba dle naší metriky provést pouze 2 kroky. Z pohledu navigačního, obsahového, prezentačního i interakčního se jedná o vynikající produkt. Trello nám nabízí také plnohodnotnou mobilní aplikaci a REST API, pomocí kterého může být propojené s dalšími systémy. V systému ale chybí pokročilejší knowledge management pro ukládání dokumentace o projektech a v současné verzi neumožňuje ani ukládat čas strávený na úkolech Scénář po ukládání dokumentů Alfresco Alfresco je kromě správy souborů orientováno i na spolupráci pracovníků. Pro přístup k souborům nabízí dvě webové rozhraní starší Alfresco a novější Alfresco Share. Našim potřebám více vyhovuje Alfresco Share, v dalším textu se proto zaměříme primárně na něj. Alfresco Share nabízí každému uživateli možnost přizpůsobení úvodní stránky. V rámci platformy je kromě ukládání dokumentů 84

90 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Tabulka 7.2: Vyhodnocení projektového scénáře Trello Redmine Tree.io OpenERP Navigace Obsah Prezentace Interakce Integrace Knowl. mgmt Přístupnost také možné vytvářet i fóra a wiki stránky. Tyto možnosti by mohly přinést pozitivní výsledky při práci s OpenERP, které samo o sobě knowledge management nemá. Pro spojení se systémem Redmine nebo Tree.io je však tato funkcionalita redundantní. Alfresco nabízí sdílení souborového systému přes širokou škálu protokolů (Java RMI, CIFS, WebDAV, FTP, NFS, IMAP, Windows SharePoint Services, vlastní REST). Samotná instalace systému je velice přímočará a po instalaci na servery firmy inqool systém fungoval přesně a stabilně bez jakéhokoliv problému. Pomocí aplikace CMIS Sync je možné synchronizovat obsah repozitáře s adresářovou strukturou na lokálních discích klientů podobně, jako to nabízí služba Dropbox [3]. Nuxeo Sytém nabízí hned po přihlášení stromovou strukturu dokumentů, je více orientovaný na samotné soubory než Alfresco. Dále oproti Alfrescu platforma Nuxeo nabízí méně protokolů pro připojení k vnitřnímu souborovému systému (Java RMI, CMIS, WebDAV, Windows SharePoint Services, vlastní REST). Systém nabízí i mobilní aplikaci a vlastní řešení pro synchronizaci dokumentů na discích klientů. Po instalaci do testovacího provozu na servery firmy inqool se však aplikace neprojevila jako stabilní. Systém padal pravidelně po několika hodinách. 85

91 7. ZHODNOCENÍ DOSTUPNÝCH PRODUKTŮ Hodnocení scénáře Pro naše potřeby se jedná o shodné produkty co se týče funkcionality i efektivity práce. Vzhledem k tomu, že na serverech firmy inqool Alfresco Share pracuje výrazně stabilněji než Nuxeo, rozhodli jsme se upřednostnit systém Alfresco Share. 7.3 Výsledky hodnocení Ze všech testů vyšlo průměrně nejhůře Tree.io, proto se jím nebudeme dále zabývat. Zaměstnancům firmy inqool se nejvíce líbil program Trello s mobilní aplikací a kanbanem. Redmine je vhodnější pracovní nástroj pro práci vývojářů než OpenERP, které je více orientované na obecnou práci velkých podniků. Stejně tak absence knowledge managementu dělá OpenERP nevhodné pro práci vývojových týmů. Z pohledu integrace všech služeb do jednoho systému je ideálním řešením Redmine, protože nabízí kompletní project management, CRM systém, knowledge management a plugin pro spojení s DMS Alfresco. Na druhou stranu projektová práce v Redmine ve srovnání s Trello je výrazně méně efektivní (pro testovaný proces 3x) a zaměstnanci firmy inqool jsou daleko více spokojeni s rychlejším nástrojem Trello. Po jednání s firmou inqool a přednesení všech návrhů jsme vybrali jako nejvhodnější variantu pro její potřeby spojení systémů Trello, Redmine a Alfresco. Systém Trello bude použit pro běžnou operativu spojenou s vývojem podle dříve definovaných firemních procesů. Automatickým skriptem se budou všechny úkoly pravidelně zálohovat do Redmine. Stejně tak pomocí skriptu budeme do Redmine ukládat i čas strávený na jednotlivých úkolech. Pro projekty, které vyžadují velké množství dokumentů, nasadíme Alfresco na jejich správu. Systémy Alfresco i Redmine umožňují správu uživatelů pomocí LDAP serveru, který ve firmě k autentizaci již používají. Každý zaměstnanec bude mít Trello účet, který se v Redmine spojí s identitou uloženou v LDAP. 86

92 Kapitola 8 Implementace a nasazení systému V této kapitole se budeme nejprve zabývat spojením systémů Redmine a Trello. Poté přejdeme k nasazení aplikace ve firmě inqool a zavedení nových pracovních procesů. 8.1 Spojení Trello a Redmine Aplikace Trello v současné verzi nepodporuje záznamenávání stráveného času u jednotlivých úkolů. Protože nabízí přehledný kanban, rozhodli jsme se využít jeden sloupec jako automatické stopky. Jakmile pracovník přesune kartu s úkolem do sloupce Timer, začne se mu počítat čas strávený na úkolu, jak je vidět na obrázku 8.2. Po přesunutí karty do jiného sloupce se strávený čas automaticky uloží do systému Redmine. Pakliže zaměstnanec při přesouvání karet udělá chybu, může tak vždy pomocí Redmine strávený čas upravit. Tím dostáváme maximální efektivitu pro běžné úkoly. Zároveň budou všechny úkoly a projekty (v terminologii Trello cards a boards ) automaticky synchronizovány s Redmine, aby měla firma inqool svoji práci vždy k dispozici na svém serveru a nemusela se s ukládáním dat spoléhat plně na třetí stranu. Trello se stane pouze nadstavbou s uživatelským rozhraním nad Redmine. Pokud by služba Trello náhle ukončila činnost, může firma inqool dále pokračovat projektovou správu v Redmine přesně tam, kde skončila. 87

93 8. IMPLEMENTACE A NASAZENÍ SYSTÉMU Obrázek 8.1: Program Trello se sloupcem Timer 8.2 Použité komponenty Ruby Pro programování skriptu jsme zvolili dynamický objektově orientovaný jazyk s obecným využitím (Ruby, [42]). První verze tohoto jazyka byla vydaná v roce Jeho syntaxe je ovlivněna především jazykem Perl a Smalltalk. V současné době je jazyk ve verzi 2.0 a pro tuto verzi jsou i optimalizované zdrojové kódy Redmine Tento systém jsme již dříve rozebírali. Pro jeho plnou funkcionalitu a propojení s ostatními komponentami jsme museli do Redmine doinstalovat další rozšíření. Kompletní popis instalace je uložený v digitální příloze diplomové práce. Cmis for Redmine 2.x je využíván na propojení Redmine s DMS Alfresco přes CMIS protokol [11]. Redmine Ldap Sync rozšiřuje možnosti LDAP synchronizace. Přidává možnost přesně nastavit jednotlivé položky kontaktů a přidávat ke kontaktům vlastní data. Rozšíření je nutné, 88

94 8. IMPLEMENTACE A NASAZENÍ SYSTÉMU Obrázek 8.2: Pojmenování entit v Redmine a Trello abychom v Redmine mohli uchovávat informace o Trello účtech zaměstnanců. Redmine Contacts představuje dříve zmiňované rozšíření, které umožňuje vložit do Redmnine CRM systém Redis Jedná se o databázi s efektivním ukládáním dvojic klíč-hodnota. Redis poprvé vyšel v roce Je vydáván pod BSD licencí a v současné době vývoj sponzoruje především firma VMWare (Redis, [29]). 89