Návrh a implementace IS pro správu vozového parku na platformě IBM Maximo

Transkript

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií Studijní program: Aplikovaná informatika Obor: Informatika Návrh a implementace IS pro správu vozového parku na platformě IBM Maximo BAKALÁŘSKÁ PRÁCE Student : Jiří Snítil Vedoucí : Ing. Tomáš Bruckner, Ph.D. Oponent : Ing. et Ing. Ctibor Duda 2014

2 Prohlášení: Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze které jsem čerpal. V Praze dne 2. května Jméno a příjmení

3 Poděkování Rád bych poděkoval vedoucímu mé bakalářské práce panu Ing. Tomáši Brucknerovi, Ph.D. za jeho odborné vedení a cenné připomínky. Také bych chtěl poděkovat společnosti IBM, která mně umožnila použít jejich software při vývoji nového informačního systému a společnosti KOMFI spol. s r.o., která mně umožnila analyzovat a formulovat požadavky na nový systém, a to především paní Renatě Janíčkové a panu Karlu Matějčkovi. V neposlední řadě bych chtěl také poděkovat rodině za podporu při psaní této bakalářské práce.

4 Abstrakt Tato bakalářská práce se zabývá návrhem a implementací informačního systému pro správu vozového parku. V první části je provedena analýza a stanovení požadavků na tento nový informační systém na základě rozhovorů ve vybrané společnosti. V druhé části této práce je stručně představena platforma IBM Maximo a je analyzována její vhodnost pro vývoj nového informačního systému z hlediska podpory vývoje nových aplikací. Pro tuto analýzu jsou zvolena kritéria pro posouzení vhodnosti platformy a také je definována hranice pro přijetí platformy. V třetí části této práce je popsaná implementace nového informačního systému pro správu vozového parku. V této části jsou uvedeny nově vytvořené aplikace a použité komponenty v rámci platformy. Klíčová slova IBM Maximo, správa vozového parku, analýza požadavků, implementace systému, údržba vozidel, kniha jízd.

5 Abstract This bachelor thesis deals with the design and implementation of a new information system for vehicle fleet management. This thesis is divided into three parts. The first part is focused on the analysis of requirements for this information system based on interviews in a selected company. The second part briefly introduces IBM Maximo and analyses its suitability for a new information system from a development point of view. For this analysis there are established criteria and a defined limit, which must be met. The third part of this thesis describes the implementation of the new information system for vehicle fleet management in IBM Maximo. This part mentions newly created applications, which provide functionality to end users of this system as it is specified in the requirements in the first part of this thesis. In addition, there is enumeration and a short description of all newly defined components in IBM Maximo, which are used by these new applications. Keywords IBM Maximo, vehicle fleet management, analysis of requirements, implementation of information system, vehicle maintenance, ride book.

6 Obsah 1. Úvod Vymezení tématu a cíle práce Rešerše dalších prací Analýza a požadavky na informační systém Charakteristika společnosti KOMFI spol. s r.o Stávající stav správy vozového parku ve společnosti Způsob dosažení cíle Požadavky na nový systém a návrhy řešení Centralizovaná evidence vozidel Správa knihy jízd pro jednotlivá vozidla Údržba vozidel Zajištění životního cyklu vozidel Údržba vozidel ve vztahu ke globálním stavům vozidla Přístupnost informačního systému Skupiny uživatelů Diagram případů užití (Use Case Diagram) Aktéři v diagramu případů užití Základní charakteristika IBM Maximo Uživatelský pohled na IBM Maximo Vhodnost platformy IBM Maximo Zvolená kritéria Nástroje platformy Migrace aplikací Integrace Stanovení hranice pro přijmutí platformy Posouzení prvního kritéria - nástroje platformy Database Configuration Application Designer Workflow Designer Domains Rozšíření pomocí Javy Automation Scripts... 21

7 4.3.7 Zhodnocení kritéria - nástroje platformy Posouzení druhého kritéria - migrace aplikací Zhodnocení kritéria - migrace aplikací Posouzení třetího kritéria - integrace Zhodnocení kritéria - integrace Zhodnocení vhodnosti platformy IBM Maximo Implementace Použité technologie a software pro vývojové prostředí IBM Maximo Asset Management IBM WebSphere Application Server IBM DB DB2 Control Centre a Command Editor Eclipse Apache Subversion Omezení vývojového prostředí Metodika vývoje Vytvořené aplikace Aplikace Vozový park Aplikace Osoby Aplikace Kniha jízd Aplikace Tankování Použité komponenty Objekty Definice Aplikací Modifikace LOOKUPS Domains Uživatelské skupiny Template KPI Java třídy Vytvořený informační systém uživatelské rozhraní Možnosti typového nasazení informačního systému Závěr... 44

8 6.1 Zhodnocení splnění stanovených cílů Další náměty a možnosti rozšíření Seznam literatury Seznam obrázků Seznam tabulek Přílohy Příloha A: Obsah přiložených elektronických materiálů... 49

9 1. Úvod 1.1 Vymezení tématu a cíle práce V rámci zvýšení své konkurenceschopnosti se podniky stále snaží nalézt další možnosti úspor, a to i mimo své hlavní procesy. Jedním ze způsobů jak dosáhnout těchto úspor je zefektivnění správy aktiv společnosti. Nemusí se přitom jednat pouze o klíčová aktiva, která společnost používá ve svém hlavním předmětu podnikání, ale může se jednat i o podpůrná aktiva. Takovými podpůrnými aktivy jsou například vozidla společnosti, která nepůsobí v přepravním odvětví, ale používá svá vozidla pouze pro vlastní účely. Tato společnost musí o těchto vozidlech vést evidenci, udržovat je v provozuschopném stavu a ze zákona musí u těchto vozidel vést knihu jízd. Vzhledem k tomu, že tato vozidla nejsou přímo využívána v hlavních procesech společnosti, je jim věnována menší pozornost, která může především u menších společností vést k zanedbání údržby nebo k nesplnění legislativních požadavků. Právě tomuto tématu se věnuje tato bakalářská práce, jejímž cílem je navrhnout a implementovat informační systém pro správu vozového parku, který má pomoci především menším podnikům s evidencí a údržbou vozidel a se splněním legislativních požadavků, které vznikají při používání podnikových vozidel. Pro splnění tohoto hlavního cíle jsou dále definovány následující tři dílčí cíle. 1) Provést analýzu ve vybraném podniku s důrazem na principy a probíhající procesy týkající se správy vozového parku a na základě této analýzy stanovit a sepsat požadavky na nový informační systém. 2) Analyzovat vhodnost použití platformy IBM Maximo pro tento nový informační systém z hlediska možností vývoje nových aplikací. 3) Vytvořit nový informační systém na platformě IBM Maximo. Tato bakalářská práce se zabývá informačním systémem pro správu vozového parku od prvotní formulace požadavků až po samotnou implementaci. Vzhledem k širšímu rozsahu tématu je v této práci hlavní důraz kladen na výsledné vytvoření fungujícího informačního systému. 1.2 Rešerše dalších prací Při rešerši byly nalezeny další práce českých i zahraničních autorů, které se zabývají správou vozového parku. Například bakalářská práce Fleet Management (Kalous, 2011) se 1

10 teoreticky věnuje této problematice a následně analyzuje situaci v konkrétním podniku. Velice málo prací se však zabývá přímo implementaci systému, jehož obsahem je správa vozového parku. Tematicky nejblíže k mojí bakalářské práci jsou pravděpodobně dvě diplomové práce. První z nich je diplomová práce Fleet Management Optimisation (Soltun, 2007), která se zabývá vyvinutím softwaru pro optimalizaci využívání vozového parku pro smyšlenou společnost. Druhou z nich je diplomová práce Systém pro plánování a evidenci jízd s možností dynamického rozšíření (Růt, 2010). V této práci se autor zabývá UML analýzou, návrhem a samotnou implementací tohoto systému. Požadavky na oba tyto uvedené systémy vycházejí přímo ze zadání práce a nejsou tedy založeny na konkrétním případu. To je i hlavní rozdíl výše uvedených diplomových prací od mojí bakalářské práce, která definuje požadavky na nový informační systém na základě analýzy provedené v konkrétní společnosti. Také žádná z nalezených prací se nezabývala systémem pro správu vozového parku, který by řešil údržbu vozidel a naplnění legislativních požadavků vzhledem k potřebám menších podniků, které nepůsobí v přepravním odvětví a využívají svá vozidla především jako podpůrné prostředky při svém hlavním předmětu podnikání. 2

11 2. Analýza a požadavky na informační systém Tato kapitola si klade za cíl analyzovat a formulovat požadavky na nový informační systém pro správu vozového parku. Analýza a formulace požadavků pro tento informační systém probíhala ve společnosti KOMFI spol. s r.o. formou rozhovorů. Tyto rozhovory byly vedeny s paní Renatou Janíčkovou odpovědnou pracovnicí za správu vozového parku a s panem Ing. Karlem Matějčkem generálním ředitelem a majitelem společnosti. 2.1 Charakteristika společnosti KOMFI spol. s r.o. Společnost KOMFI spol. s r.o. je tradiční český výrobce strojů. Na trhu působí již více než dvacet let a při výrobě strojů zajišťuje vlastní vývoj, konstrukci, výrobu, montáž, servis a prodej. V rámci České Republiky má celkem čtyři provozovny, hlavní sídlo v Lanškrouně, výrobní závod ve Svébohově, montážní haly v Novém Městě na Moravě a v Litomyšli (KOMFI, 2014). Tyto provozovny jsou z hlediska správy vozového parku podstatné, protože je mezi nimi zajišťována přeprava materiálů a strojů vlastními vozidly. Další důležitou součástí vozového parku společnosti jsou vozidla určená pro obchodní zástupce a technické specialisty společnosti, kteří jezdí přímo za klienty a na veletrhy do zahraničí. Ti si tato vozidla půjčují pouze na konkrétní cestu. Další a menší skupinu vozidel tvoří vozidla manažerů, kteří mají vozidla pro své výhradní používání. 2.2 Stávající stav správy vozového parku ve společnosti Ve společnosti chybí globální pohled na správu vozidel. Jednotlivá střediska spravují svá vozidla samostatně a využívají svůj vlastní systém, který je často v papírové podobě. Z tohoto důvodu je obtížné a zdlouhavé získat data pro rozhodování a řízení společnosti na strategické úrovni. S tím souvisí i časově náročné získávání informací o aktuálním stavu vozového parku. U vozidel není jednotně vedená evidence oprav a údržby zahrnující celkovou historii vozidla od pořízení až po vyřazení. Knihy jízd jsou vyplňovány v papírové podobě a poté jsou ručně přepisovány do elektronické podoby. 2.3 Způsob dosažení cíle Následující kapitola obsahuje analýzu a požadavky na nový informační systém pro správu vozového parku. Pro vytvoření analýzy a formulaci požadavků byla zvolena metoda rozhovorů, které byly prováděny v sídle společnosti. Tyto rozhovory byly vedeny v několika iteracích s časovým odstupem. V průběhu rozhovorů byly definovány jednotlivé požadavky na systém, které jsou uvedeny v následující kapitole v chronologickém pořadí tak, jak v čase probíhaly samotné schůzky. Pokud byl požadavek příliš obecný, byl pro něj 3

12 vypracován konkrétnější návrh, který je uveden pod daným požadavkem. Tento návrh byl následně v další iteraci rozhovorů diskutován a případně odsouhlasen. Pokud návrh nebyl společností odsouhlasen, byl přepracován a přenesen do další iterace rozhovorů. Důraz byl kladen na podchycení všech legislativních požadavků, které by měl systém splňovat a zároveň na eliminaci zbytečných činností, které společnost musí vykonávat, jako je například přepis knihy jízd z papírové podoby do elektronické. Tyto požadavky a návrhy řešení jsou zcela odstíněny od technologické koncepce a implementačních charakteristik, jedná se tedy o konceptuální úroveň návrhu informačního sytému (tzv. princip tří architektur). Tento konceptuální návrh určuje, co bude obsahem informačního systému (Řepa, 1999). 2.4 Požadavky na nový systém a návrhy řešení Centralizovaná evidence vozidel Cílem tohoto požadavku je zajistit centralizovanou, jednotnou evidenci vozidel. V této evidenci budou přístupná k nahlédnutí všechna vozidla společnosti. U jednotlivých vozidel budou zobrazeny základní parametry, které jsou uvedeny v technickém průkazu vozidla. U každého vozidla bude přiřazena odpovědná osoba a ze systému bude možné zjistit kontaktní údaje na tuto osobu, minimálně ovou adresu a telefonní číslo. Tato evidence vozidel bude přístupná všem zaměstnancům, kteří budou mít zřízen přístup do tohoto informačního systému. Je ale potřeba zajistit, aby jednotliví zaměstnanci při nahlížení do této evidence viděli pouze vozidla, na která mají oprávnění, a to vzhledem ke svému pracovnímu zařazení v rámci společnosti. Návrh řešení: Rozdělit vozidla do třech kategorií. a) Výroba Tato vozidla jsou používána k přepravě strojů, materiálů a nářadí v rámci výroby a běžného provozu společnosti. Jedná se především o pracovní vozy typu dodávka či pickup. 4

13 b) Obchod Tato vozidla jsou používána obchodníky a techniky, kteří vozidla využívají pro cesty za klienty nebo pro cesty na veletrhy. Jedná se především o reprezentativní vozidla. c) Manažerská vozidla Tato vozidla jsou určena pouze pro výhradní používání jedním uživatelem, a to uživatelem, který je označen jako odpovědná osoba za vozidlo. Proto tento uživatel bude mít jako jediný z běžných uživatelů k tomuto vozidlu přístup. Pro odlišení budou tyto vozidla označena speciální značkou. Formálně však budou zařazena do skupiny Výroba nebo Obchod. Tyto vozidla tedy bude možné jednoduše začlenit do těchto skupin tím, že se jim odebere tato speciální značka. Na základě tohoto rozdělení budou zřízeny uživatelské skupiny pro výrobu a pro obchod. Uživateli systému bude přidělena uživatelská skupina a podle tohoto nastavení se zobrazí pouze patřičná vozidla. Uživateli bude povoleno být ve více skupinách. Pokud uživateli bude přiřazeno manažerské vozidlo, bude mu toto vozidlo také zobrazeno. Běžným uživatelům systému budou manažerská vozidla skryta Správa knihy jízd pro jednotlivá vozidla U jednotlivých vozidel bude vedena kniha jízd. V této knize budou evidovány jednotlivé cesty uskutečněné daným vozidlem. V rámci jednoho záznamu vloženého do knihy jízd budou evidovány tyto údaje: datum cesty, odkud kam, účel cesty, nákladové středisko, počáteční stav tachometru, konečný stav tachometru, řidič vozidla. Údaj řidič vozidla bude automaticky vyplněn právě přihlášeným uživatelem. V rámci záznamu v knize jízd bude možné přiřadit tankování. Tankování bude evidovat počet litrů, jenž byl natankován, cenu za litr, celkovou cenu a druh paliva. V rámci záznamu tankování bude uvedena osoba, která za tankování zaplatila. Tento údaj bude také automaticky vyplněn, právě přihlášeným uživatelem. V rámci jednoho záznamu v knize jízd bude možné založit více záznamů o tankování. Každý uživatel informačního systému bude moci založit záznam do knihy jízd k danému vozidlu a bude moci přiřadit tankování k dané jízdě. Bude ale zakázáno vkládat záznamy za jinou osobu. Musí ale existovat role, která toto oprávnění mít bude. Návrh řešení: Vytvořit pro všechny uživatele obecnou skupinu, která bude mít sadu základních oprávnění. Bude také definovaná rozšířená skupina Správce vozového parku, která bude mít rozšířená práva, mezi které bude také patřit vkládání údajů za jinou osobu. 5

14 2.4.3 Údržba vozidel V rámci evidence jednotlivých vozidel, budou vedeny záznamy o údržbě daného vozidla. Tyto záznamy umožní nahlédnutí na kompletní historii vozidla vzhledem k provedeným servisům a technickým kontrolám. Systém umožní uživatelům založit nový záznam o údržbě vozidla. Tento záznam umožní uživateli zaevidovat poruchu vozidla, absolvovanou servisní prohlídku vozidla a absolvovanou technickou kontrolu vozidla. Systém umožní zobrazit vozidla, která potřebují opravu tak, aby správce vozidel mohl vozidlo identifikovat a odvézt do servisu, případně zajistit jeho opravu. Ze systému musí být jednoduše zjistitelné, která vozidla jsou provozuschopná a která vyžadují opravu. Návrh řešení: Na základě vkládaných záznamů o poruše vozidla systém bude měnit tzv. globální stav vozidla (viz následující kapitola). Tento stav bude změněn na základě poruchy a to buď na stav Špatný stav nebo na stav Nepojízdné a to na základě volby uživatele, který poruchu vkládá. Podrobný popis a vysvětlení těchto stavů je uveden v následující kapitole, protože se přímo týká životního cyklu vozidla Zajištění životního cyklu vozidel Systém by měl zajistit sledování životního cyklu vozidel od pořízení po vyřazení. Pro taktické řízení společnosti by měl systém umožnit rychle zobrazit vozidla, která jsou schopná provozu a vozidla, která mají poruchu a potřebují opravu. Pro strategické řízení společnosti by měl systém umožnit zobrazit již vyřazená vozidla a vozidla zvažovaná ke koupi. Vozidlem zvažovaným ke koupi se rozumí vozidlo, které není majetkem společnosti, ale pouze bylo vyhledáno u obchodníků jako vozidlo vhodné pro potřeby společnosti. K tomuto vozidlu bude možné přiřadit základní parametry a zadat rozsáhlý komentář. Systém poté umožní pracovníkům odpovědným za nákup vozidel tyto vozidla zobrazit. U vyřazených vozidel budou dostupná historická data, především evidence knihy jízd a údržby vozidel. K vyřazeným vozidlům nebude umožněno běžným uživatelům vkládat nové záznamy do knihy jízd a do evidence údržby. Toto omezení se netýká uživatele v roli Správce vozového parku. Tomu tato možnost zůstane a bude mu tedy umožněno doplnit data zpětně. Návrh řešení: Každému vozidlu bude přidělen atribut tzv. globální stav. Tento stav bude určovat, v jaké fázi životního cyklu vozidlo je. Následující tabulka uvádí výčet všech těchto globálních stavů s jejich stručným popisem. 6

15 Tabulka 1: Názvy globálních stavů vozidla a jejich krátký popis. (zdroj: autor) Název globálního stavu Popis stavu Ke koupi Vozidla zvažovaná ke koupi. Provozuschopné Provozuschopná vozidla Špatný stav Provozuschopná vozidla vyžadující servis. Nepojízdné Nepojízdná vozidla. Vyřazeno Vyřazená vozidla. Systém na základě těchto stavů umožní filtrování, čili zobrazení vozidel jen s určitým globálním stavem. Stav Ke koupi bude sloužit pro zobrazení evidence vozidel zvažovaných ke koupi. Při přidání nového záznamu vozidla do centralizované evidence společnosti, bude těmto vozidlům automaticky přiřazen stav Ke koupi, to znamená, že tento stav bude také využit pro první zaevidování vozidla, které již společnost používá. Založit nové vozidlo v jiném než v tomto stavu nebude možné. Pouze uživatel v roli správce vozového parku, bude moci založit nové vozidlo v tomto stavu a doplnit k němu komentář, například odkaz na prodejce či jiný popis. Ke koupi bude jediný globální stav, ze kterého bude moci uživatel v roli správce systému odstranit vozidlo z centralizované evidence. Přechod z globálního stavu Ke koupi bude moci vykonat pouze uživatel v roli správce vozového parku a to pouze do stavu Provozuschopné. Vozidla, která mají globální stav Provozuschopné, jsou provozuschopná a cílem používaných vozidel je mít tento stav. Tento stav indikuje, že vozidlo nepotřebuje žádnou opravu ani servis. K vozidlu je možné přidávat záznamy jízd a záznamy o údržbě vozidla. Podle typu přidávaného záznamu o údržbě vozidla, je měněn globální stav vozidla do stavu Špatný stav nebo do stavu Nepojízdné. Toto bude jediný způsob, jak bude moci běžný uživatel systému změnit globální stav vozidla. Globální stav vozidla Špatný stav označuje vozidlo, které je provozuschopné, ale vyžaduje opravu či servisní prohlídku. Může se jednat například o pravidelné výměny oleje, doplnění provozních kapalin, dohuštění pneumatik apod. Tento stav vozidla se automaticky vyvolá na základě vložení záznamu do evidence údržby vozidla. Jakmile se porucha odstraní, systém automaticky změní globální stav vozidla zpět do stavu Provozuschopné. Globální stav vozidla Nepojízdné označuje vozidlo, které není provozuschopné a vyžaduje opravu. V záznamech o údržbě vozidla bude možné identifikovat příčinu tohoto stavu. Tento stav se automaticky vyvolá po vložení záznamu do evidence poruch vozidla obdobně jako stav Špatný stav. V momentě, kdy příčina tohoto stavu bude odstraněna, systém vrátí globální stav vozidla na Provozuschopné. Z jakéhokoli stavu, kromě stavu Ke koupi, bude mít uživatel v roli správce vozového parku možnost změnit stav vozidla na Vyřazeno. Tento stav eviduje vozidla, která 7

16 společnost používala, ale jsou již vyřazena z majetku společnosti. Může se například jednat o vozidla odprodaná či zešrotovaná. Pro přehlednost dva následující obrázky zobrazují možné změny globálního stavu vozidel. První z nich je z pohledu uživatele v roli Správce vozového parku. Druhý obrázek je z pohledu běžného uživatele systému. Šipky znázorňují, z jakého globálního stavu lze přejít na jaký stav. Obr. 1: Možné globální stavy vozidel z pohledu uživatele v roli správce vozového parku (zdroj: autor) 8

17 Obr. 2: Možné globální stavy vozidel z pohledu běžného uživatele (zdroj: autor) Údržba vozidel ve vztahu ke globálním stavům vozidla Na základě předchozích dvou kapitol je patrná závislost životního cyklu vozidla na jeho záznamech o údržbě. Tyto záznamy o údržbě také obsahují rozdílná data a to jak záznamy o poruchách vozidla, tak záznamy o jeho servisních prohlídkách a technických kontrolách. V rámci těchto záznamů o údržbě také vznikl nový požadavek a to umožnit uživateli v roli Správce vozového parku kontrolovat, které poruchy jsou v jakém stavu rozpracovanosti a to především zda porucha je nově zaevidovaná, nebo se již pracuje na jejím odstranění, nebo je vyřešená. Proto byl vypracován následující návrh řešení, který obsahuje tento nový požadavek a objasňuje vztah mezi záznamy o údržbě vozidla a globálních stavech vozidla. Návrh řešení: Při vkládání nového záznamu do sekce údržba vozidla uživatel systému zadá typ tohoto záznamu. Tento typ v podstatě reprezentuje událost, která vedla k nutnosti založit tento záznam. Uživatel bude mít na výběr z těchto typů záznamů: drobná závada porucha údržba technická prohlídka silničního vozidla Drobná závada reprezentuje závadu na vozidle, která nebrání v jeho používání a vozidlo je stále provozuschopné. Může se jednat například o podhuštěné pneumatiky nebo chybějící kapalinu v ostřikovačích. Typ porucha reprezentuje poruchu na vozidle, která brání v jeho používání. Vozidlo s touto poruchou není provozuschopné. Může se jednat například o defekt pneumatiky nebo vybitou autobaterii. 9

18 Záznam typu údržba eviduje provedenou údržbu na vozidle. V tomto typu záznamu jsou uvedeny opravy vozidla a veškeré servisní zásahy. Například se takto mohou evidovat výměny oleje a ostatních provozních kapalin, výměny filtrů, brzdových destiček a podobně. Z toho vyplývá, že pokud existuje porucha vozidla, která vyžaduje servisní zásah, bude tento servisní zásah uveden v tomto typu záznamu. Tento záznam bude obvykle vložen uživatelem v roli Správce vozového parku. Naproti tomu samotná porucha bude evidována v typu drobná závada nebo porucha a bude obvykle vkládána uživatelem, který poruchu na vozidle zaznamenal. Technická prohlídka silničního vozidla je typ záznamu, který eviduje zákonem vyžadovanou kontrolu technického stavu vozidla. U všech čtyř typů záznamu bude mít uživatel možnost vložit krátký výstižný popis události, která se na vozidle vyskytla, a také bude mít možnost vložit k danému záznamu rozsáhlý formátovaný text, který umožní detailní popis této události. V každém záznamu o údržbě bude také evidovaná osoba, která tento záznam založila. Tato osoba bude automaticky vyplněna právě přihlášeným uživatelem do systému. Uživatel v roli Správce vozového parku bude mít možnost tuto osobu změnit, a to například pro případ, kdy záznam zakládá za jinou osobu, která mu událost nahlásila přes telefon nebo . Pro kontrolu stavu rozpracovanosti při řešení typů údržby drobná závada a porucha bude definován takzvaný stav rozpracovanosti. Tento stav bude nabývat následujících hodnot: nový rozpracovaný vyřešený Tento stav bude moci měnit pouze uživatel v roli Správce vozového parku. Podle tohoto stavu bude umožněno filtrování a ze systému bude jednoduše zjistitelné, které drobné závady a poruchy vozidla jsou ve stavu nový nebo ve stavu rozpracovaný tak, aby je Správce vozového parku mohl efektivně řešit. Stav nový bude výchozí hodnota pro typ záznamu údržby drobná závada a porucha. Stav rozpracovaný bude sloužit k označení závady nebo poruchy, na které se pracuje, například je již domluvený termín v servisu, nebo je již objednaná chybějící součástka (žárovka, pojistka apod.). Stav vyřešený označuje drobnou závadu nebo poruchu, která je vyřešená a již nemá vliv na aktuální stav vozidla. Při změně stavu rozpracovanosti na stav vyřešený bude automaticky zaznamenáno datum, kdy byla tato změna provedena. Ve všech těchto stavech bude možné měnit a doplňovat informace v poznámce a v detailním popisu tak, aby bylo možné sledovat průběh jednotlivých záznamů údržby na jednom místě. Změny stavů budou probíhat pouze jednosměrně, tedy nebude možné například stav rozpracovaný změnit na nový. Pro přehlednost následující obrázek 10

19 znázorňuje průběh změny stavů v rámci záznamů údržby typu drobná závada a porucha. Obr. 3: Znázornění průběhu změny stavů pro záznam údržby typu drobná závada a porucha (zdroj: autor) Pro záznamy údržby typů technická prohlídka silničního vozidla a údržba bude definován pouze jeden stav evidováno, který jim bude po vytvoření záznamu automaticky přiřazen. Tento stav bude jediný, který budou mít záznamy o údržbě těchto typů. Z výše popsaných typů záznamů o údržbě vozidla je patrná přímá vazba mezi globálním stavem vozidla a jednotlivými záznamy o údržbě. Zatímco typy technická prohlídka silničního vozidla a údržba vazbu na globální stav nemají, protože se jedná pouze o evidenci provedených úkonů na vozidle. Typy drobná závada a porucha přímo globální stav ovlivňují. Existuje-li na vozidle alespoň jeden záznam typu porucha ve stavu nový nebo rozpracovaný je vozidlo neschopné provozu a jeho globální stav musí být nastaven na nepojízdné. Pokud tento záznam neexistuje, ale existuje alespoň jeden záznam typu drobná závada ve stavu nový nebo rozpracovaný, musí být globální stav vozidla nastaven na špatný stav. Pokud tyto záznamy neexistují nebo již jsou ve stavu vyřešený vozidlo bude označeno globálním stavem provozuschopné. Celou tuto logiku bude systém automaticky vyhodnocovat a příslušně měnit globální stav vozidla, podle aktuálního stavu všech záznamů v části údržba vozidla. Povinností uživatele v roli Správce vozového parku tedy bude pouze zajišťovat opravu nahlášených poruch a drobných závad na vozidle a patřičně aktualizovat stavy těchto záznamů a to podle skutečného průběhu jednotlivých oprav Přístupnost informačního systému Informační systém pro správu vozového parku by měl být jednoduše přístupný uživatelům. Neměla by být potřeba instalace aplikace na pracovní stanici, ale celý systém by měl být přístupný například pomocí webové aplikace. Uživatel by tak měl mít možnost zadat údaje přímo ve vozidle a to prostřednictvím svého mobilního telefonu nebo tabletu, který má připojení k internetu. 11

20 2.4.7 Skupiny uživatelů Všechny uživatele systému je nutné rozdělit do uživatelských skupin. Tyto uživatelské skupiny přidělí uživatelům patřičné funkce, tedy jejich roli v rámci systému, a dále jim zpřístupní pouze náležitá data, a to na základě výše zmíněných požadavků. Je potřeba, aby v rámci systému existovala skupina, která bude mít přidělená veškerá práva a přístup k datům napříč celým podnikem. Tato skupina bude určená například pro vrcholné vedení společnosti. Návrh řešení: Vzhledem k požadavkům na tento informační systém je nutné vytvořit uživatelské skupiny na základě dvou různých pohledů a to z pohledu funkcionality systému a z pohledu přístupu k datům. Z pohledu funkcionality systému se jedná o to, jakou roli uživatel v rámci systému zastává, a tedy jaké činnosti v rámci systému vykonává. Pro znázornění funkčních požadavků na systém je vhodné využít Diagram případů užití (Use Case Diagram) (Fowler, 2009). Pro přehlednost je tento diagram uveden zvlášť v následující kapitole. Na základě tohoto diagramu jsou poté definovány skupiny uživatelů, které budou odpovídat rolím uživatelů systému. Z pohledu přístupu k datům budou existovat dvě skupiny oprávnění. Jedna skupina Výroba a druhá skupina Obchod. Na základě těchto skupin budou uživateli zobrazena vozidla pouze z té části podniku, ke které má přístup. Uživatel bude moci být v obou skupinách a tak bude mít přístup ke všem vozidlům společnosti. Výjimku tvoří takzvaná manažerská vozidla, ke kterým bude mít přístup z běžných uživatelů pouze odpovědná osoba vozidla. Toto rozdělení se vztahuje pouze na běžné uživatele systému. Specifické role jako je správce vozového parku bude mít vždy přístup ke všem vozidlům. Tento návrh řešení tedy předpokládá, že uživatel systému bude zároveň minimálně ve dvou skupinách. V jedné, která mu přidělí funkce systému na základě jeho role, a v druhé, která mu přidělí oprávnění pracovat s daty, a to na základě jeho pracovního zařazení v rámci společnosti. 12

21 2.5 Diagram případů užití (Use Case Diagram) Pomocí následujícího diagramu případů užití je popsáno chování systému z hlediska uživatele. Tento diagram specifikuje, jaké typy uživatelů systém používají a jaké činnosti vykonávají (Bruckner, et al., 2012). Tento diagram přehledně zobrazuje, jakou funkcionalitu má přiřazenou konkrétní uživatelská role. Diagram se skládá z aktérů, případů užití a vztahů mezi nimi. Aktér je znázorněn symbolem panáčka a představuje roli, kterou uživatel má v rámci systému. Případ užití je znázorněn v diagramu elipsou a specifikuje funkcionalitu systému, kterou má aktér k dispozici a snaží se pomocí ní dosáhnout určitého cíle. Vztah mezi aktérem a případem užití je znázorněn čarou zakončenou šipkou a vyjadřuje tok informace. Šipka zde určuje, která strana zahajuje interakci. V následujícím diagramu případu užití jsou také použity specifické vztahy generalizace/specializace a extend. Vztah generalizace/specializace je znázorněn trojúhelníkovou šipkou, která nemá výplň a je zakreslena od potomka k předkovi. Tento vztah reprezentuje stav, kdy jeden aktér zahrnuje všechny případy užití jiného aktéra. Jak je vidět z diagramu níže, aktér Správce vozového parku je specifičtějším aktérem než aktér Běžný uživatel a dědí od něj všechny jeho vazby na případy užití. Tato vazba generalizace/specializace se používá pro zjednodušení diagramu. Druhým vztahem, který je v diagramu použit, je vztah extend. Tento vztah představuje rozšíření základního případu užití jiným případem užití, který se nemusí provést vždy, ale například pouze na základě dané podmínky. 13

22 Obr. 4: Diagram případů užití (zdroj: autor) Aktéři v diagramu případů užití Na základě všech požadavků definovaných v kapitole 2.3 Požadavky na nový systém a návrhy řešení, byly vytvoření aktéři s názvy Běžný uživatel, Správce vozového parku a Vedení. Aktér s názvem Běžný uživatel představuje základního uživatele systému. Jedná se o pracovníka společnosti, který využívá vozidla společnosti, ale jeho pracovní pozice se netýká správy vozového parku. 14

23 Aktér s názvem Správce vozového parku představuje pracovníka společnosti, v jehož odpovědnosti je správa vozového parku společnosti. Tento aktér má k dispozici veškerou funkcionalitu aktéra Běžný uživatel, která je rozšířena o specifické funkce jeho role. Aktér s názvem Vedení představuje pracovníka společnosti, který se podílí na strategickém řízení společnosti, nebo má jinou vrcholovou funkci. Tento aktér má k dispozici stejnou funkcionalitu jako aktér Správce vozového parku. Vzhledem k požadavkům společnosti a tomu, že jeho role v systému je diametrálně odlišná od aktéra Správce vozového parku, je uveden jako aktér zvlášť. Výhodou tohoto rozdělení může být například budoucí rozšíření systému o manažerské funkce, nebo naopak omezení některých funkcí výlučně pro tuto roli. Jak je vidět z diagramu případů užití, z pohledu funkcionality systému budou vytvořeny další tři uživatelské skupiny, na základě kterých bude uživatelům systému zpřístupněna požadovaná funkcionalita. Názvy těchto skupin budou shodné s názvy aktérů. 15

24 3. Základní charakteristika IBM Maximo Cílem této kapitoly je stručně představit platformu IBM Maximo a popsat její základní charakteristiky. IBM Maximo je softwarové řešení postavené na platformě Java 2 Enterprise Edition. Využívá komponentový přístup architektury softwaru, který ji umožňuje zajistit znovu použitelnost jednou vytvořených aplikací, integraci s externími aplikacemi a omezuje nežádoucí dopady při změně či nahrazení jednotlivé aplikace. Základní komponentou poskytující funkčnost jádra pro IBM Maximo je Tivoli Process Automation Engine (IBM, 2014c). Maximo lze použít jak pro malé lokální podniky, tak pro rozsáhlé nadnárodní podniky s mnoha divizemi (IBM, 2010). IBM Maximo může být nasazeno na komerčních aplikačních serverech, které poskytují základní infrastrukturu a služby tak, jak jsou definovány standardem J2EE. Mezi tyto aplikační servery patří WebSphere Application Server a WebLogic Application Server (IBM, 2013). Maximo používá vertikálně více vrstvenou architekturu, kdy prezenční vrstva, aplikační business vrstva a vrstva zprostředkující přístup k datům jsou od sebe vzájemně odděleny. Jednotlivé aplikace v Maximu jsou dále zapouzdřené do horizontálních modulů (IBM, 2010). Tuto strukturu znázorňuje následující obrázek. 16

25 Obr. 5: Znázornění více vrstvené architektury Maxima (zdroj: (IBM, 2010)) Uživatelský pohled na IBM Maximo Uživatelské rozhraní IBM Maximo je založeno na internetovém prohlížeči, který zastává funkci takzvaného tenkého klienta. Tento tenký klient zprostředkovává přístup k funkcím systému a to bez nutnosti instalace dalších aplikací na straně uživatele. Tento přístup odbourává obvyklé problémy klasického, dnes již staršího přístupu, kdy bylo potřeba instalovat u uživatele takzvaného tlustého klienta. Mezi tyto obvyklé problémy patřila například správa verzí, konflikty s kompatibilitou softwaru na konečné stanici. Maximo respektuje webové standardy, a proto v dnešní době, kdy většina zařízení jako jsou například mobilní telefony, tablety a notebooky má internetový prohlížeč jako součást svého základního programového vybavení, lze říci, že s jakýmkoli tímto zařízením, lze pracovat s informačním systémem postaveným na platformě IBM Maximo, jedinou podmínkou je samozřejmě připojení k internetu (IBM, 2010). 17

26 4. Vhodnost platformy IBM Maximo V této kapitole budou stanovena kritéria, na základě kterých bude posouzena vhodnost platformy IBM Maximo pro vytvoření informačního systému pro správu vozového parku. Základem informačních systémů jsou aplikace, které v rámci těchto informačních systémů sdružují určitou část funkcionality a zpřístupňují tuto funkcionalitu uživateli. Tyto aplikace tedy tvoří základní stavební kameny informačního systému. Proto tyto kritéria budou volena vzhledem k tomu, jak tato platforma podporuje vývoj nových a úpravu stávajících aplikací. 4.1 Zvolená kritéria Nástroje platformy Prvním kritériem pro vyhodnocení vhodnosti platformy bude identifikace, zda platforma poskytuje nástroje k vývoji nových a úpravě stávajících aplikací. První podmínkou pro splnění tohoto kritéria je, že platforma musí obsahovat minimálně nástroje, které umožní vytvořit uživatelské rozhraní aplikace a definovat jim datovou základnu. V rámci tohoto kritéria také bude identifikováno, zda a jakým způsobem lze definovat business logiku aplikací, tedy jak lze do aplikace vložit pravidla o tom, jak má data vytvářet, zobrazovat, měnit, validovat a ukládat. Druhou podmínkou pro splnění tohoto kritéria je tedy nalezení alespoň jednoho způsobu, jak lze do aplikací zapsat business logiku Migrace aplikací Při vývoji nových nebo úpravě stávajících aplikací jsou většinou vývojová, testovací a produkční prostředí od sebe oddělena a po otestování jsou aplikace přenášené z jednoho prostředí na druhé. Platforma by měla tento přenos podporovat a obsahovat nástroje, které tento přenos usnadní. Proto v rámci tohoto druhého kritéria bude identifikováno, zda platforma obsahuje nástroje, které usnadní tento přenos aplikací z jednoho prostředí na druhé. Pro splnění tohoto kritéria musí být identifikován alespoň jeden tento nástroj Integrace Výměna dat a integrace je dnes neodmyslitelnou součástí požadavků téměř na každý rozsáhlejší informační systém. Může se jednat jak o integraci v rámci jedné společnosti, v které je provozováno více informačních systémů, tak se může jednat i o integraci s externími partnery nebo zákazníky. Zajistit, aby tato spolupráce různých systémů 18

27 probíhala v pořádku může být velice finančně a časově náročné. Proto je vhodné, aby platforma nabízela funkcionalitu, která tuto integraci usnadní. Pro splnění tohoto kritéria tedy platforma musí obsahovat prostředky, které aplikacím pomohou zajistit integraci s jinými systémy tak, aby tuto integraci nemusely aplikace řešit samostatně v rámci své funkcionality. 4.2 Stanovení hranice pro přijmutí platformy Celkem byly stanoveny tři kritéria pro přijmutí platformy jako platformy vhodné pro vytvoření informačního systému pro správu vozového parku. Jak je z kritérií patrné, nejdůležitějším a také nejobsáhlejším kritériem, je kritérium první s názvem nástroje platformy. Pokud toto kritérium nebude splněno, platformu jako celek nelze použít pro vytvoření nového informačního systému. Při nesplnění druhého kritéria, platformu bude možné použít, ale nasazení informačního systému bude komplikované, protože přenos nově vytvořených aplikací na provozní prostředí bude náročný. Při nesplnění třetího kritéria bude možné platformu také použít, ale z dlouhodobého hlediska nebude použití platformy zcela ideální, protože veškerá integrace s ostatními systémy bude muset být řešena pomocí úprav a rozšíření konkrétních aplikací. Na základě výše uvedené úvahy je stanovena tato hranice pro přijmutí platformy. Aby platforma byla přijata jako vhodná pro vytvoření nového systému, musí splňovat kritérium první nástroje platformy a současně alespoň jedno další kritérium migrace aplikací nebo integrace. 4.3 Posouzení prvního kritéria - nástroje platformy Platforma IBM Maximo poskytuje širokou škálu způsobů a nástrojů pro vývoj a úpravu aplikací. Tyto nástroje lze použít jak k modifikaci již existujících aplikací, tak i k vytvoření nových aplikací. Většina těchto nástrojů je přístupná přímo v rámci platformy. V následujících podkapitolách jsou popsány nejdůležitější identifikované způsoby a nástroje, které platforma umožnuje použít k vývoji nových aplikací nebo k úpravě stávajících aplikací Database Configuration Pomocí této aplikace je možné vytvářet a měnit objekty. Tyto objekty v zásadě reprezentují tabulku v databázi (ale nemusí tomu tak být vždy). Aplikace v tomto objektu umožňuje přidávat a měnit atributy, indexy a relace. Tato aplikace tak vytváří abstraktní vrstvu mezi vývojářem a samotnou databází, a tím ho odstiňuje od závislosti na konkrétní databázi. Tyto objekty následně využívají ostatní aplikace, které běží na platformě IBM Maximo. Tento přístup umožňuje, že jednou vyvinutá aplikace na této platformě bude fungovat i na 19

28 jiné instalaci Maxima, i když tato instalace bude využívat jinou databázi, než na které byla aplikace původně vyvinuta. Momentálně jsou platformou Maximo podporované databáze DB2, Oracle a Microsoft SQL Server. (IBM, 2013) Application Designer Tato aplikace umožňuje vytvářet a měnit uživatelské rozhraní nových a stávajících aplikací. V rámci tohoto uživatelského rozhraní umožňuje manipulaci s prvky, které tvoří samotnou aplikaci. Těmito prvky můžou být jak jednoduchá textová pole, tak i složité struktury, které pracují s daty v různých datových objektech. Tato aplikace také umožňuje export editovaného uživatelského rozhraní do XML. V tomto souboru XML jsou prvky aplikace definovány v elementech s parametry. Tento soubor lze ručně upravit a zpět nahrát do Application Designeru. Tento přístup je například vhodný při editaci rozsáhlých aplikací, kdy je možné výrazně upravit uživatelské rozhraní editované aplikace v poměrně krátkém čase Workflow Designer Workflow designer je aplikace, která umožňuje vytvářet a měnit workflow. Pomocí těchto workflow, lze mapovat probíhající procesy v organizaci do aplikací v rámci platformy Maximo. Tato aplikace používá pro znázornění modelovaného procesu přehledné grafické rozhraní, které je podobné grafickému znázornění používaném při klasickém procesním modelování. Pro správnou funkčnost workflow v rámci platformy Maximo, je potřebná součinnost více aplikací, které přímo či nepřímo podporují workflow vytvořená ve Workflow Designeru. Mezi tyto aplikace například patří Workflow Administration, Roles, Actions, Communication Templates, Escalations a další. Detailní informace o použítí workflow v rámci IBM Maxima lze nalézt například v (IBM, 2007) Domains Tato aplikace umožňuje vytváření a modifikaci číselníků. Nejedná se pouze o statické číselníky, které zpřístupňují předem definované hodnoty, ale může se jednat o dynamické číselníky, které se generují v reálném čase na základě stanovených podmínek Rozšíření pomocí Javy V rámci platformy IBM Maximo je možné k vývoji nových nebo k modifikaci stávajících aplikací použít své vlastní třídy napsané v programovacím jazyku Java. Tyto třídy musí implementovat rozhraní dané platformou a pro jejich vývoj je nutné použít klasické vývojové prostředí jako je například Eclipse nebo NetBeans. Tento přístup umožňuje využít robustního jazyka Java a tím i otvírá nové možnosti při vytváření aplikací na této platformě. Je potřeba zdůraznit, že použití vlastních tříd vyžaduje dobrou znalost jak 20

29 platformy IBM Maximo, tak i programovacího jazyka Java. Tento přístup také klade nároky na důkladnější testování při vývoji aplikací na této platformě Automation Scripts Od verze 7.5 platforma Maximo umožňuje použití i takzvaných automatizačních scriptů. Tyto skripty lze psát v jazyce Javascript nebo Jython a lze je použít k rozšíření funkcionality aplikací, které jsou založeny na této platformě (Bhattacharyya a Sriramadhesikan, 2011). Lze tedy říci, že jsou do jisté míry alternativou k rozšíření pomocí Javy Zhodnocení kritéria - nástroje platformy Celkem bylo identifikováno šest základních nástrojů, které platforma umožňuje použít k vytváření a úpravě aplikací. Pro splnění první podmínky kritéria bylo nutné nalézt prostředky nebo nástroje podporující vytvoření uživatelského rozhraní a definici datové základny. K vytváření a modifikaci uživatelského rozhraní slouží aplikace Application Designer. Pro vytváření a změnu datové základny lze použít aplikaci Database Configuration. První podmínka tohoto kritéria je tedy splněna. Druhou podmínkou pro splnění kritéria bylo nutné nalézt nástroje, které umožňují definovat business logiku aplikace. Platforma IBM Maximo toto umožňuje pomocí aplikace Workflow Designer. Také je možné business logiku vepsat do vlastních Java tříd, které implementují rozhraní dané platformou. Alternativu k tomuto přístupu tvoří takzvané Automation Scripts, kdy platforma umožňuje definovat business logiku použitím jazyků Javascript a Jython. Tato druhá podmínka je také splněna. Obě dvě podmínky v prvním kritériu jsou platformou splněny. Z hlediska prvního kritéria je tedy platforma vhodná pro implementaci nového informačního systému. 4.4 Posouzení druhého kritéria - migrace aplikací Aplikace vyvinutá na jedné konkrétní instalaci Maxima může být přenesena na jinou instalaci pomocí aplikací v modulu Migration Manager. Mezi tyto aplikace patří Migration Manager, Migration Groups, Object Structures. (IBM, 2008a) Pro migraci je potřeba určit, jaká aplikace a které její součásti budou předmětem migrace. Tento obsah je následně uspořádán do balíků. Celý proces migrace vyžaduje několik kroků, kdy některé je nutné provést na zdrojovém prostředí a další na cílovém. (IBM, 2014d) 21

30 4.4.1 Zhodnocení kritéria - migrace aplikací Platforma IBM Maximo obsahuje modul Migration Manager, který obsahuje aplikace, které usnadňují přenos aplikací na různé instalace platformy Maximo. Proto je toto kritérium splněno. 4.5 Posouzení třetího kritéria - integrace Platforma IBM Maximo obsahuje Integration Framework, který usnadňuje integraci aplikacím. Tento Framework podporuje několik komunikačních modů, mezi které patří Webové služby (Web services), HTTP, Java Message Service (JMS) messaging, Database interface tables, XML and flat files (IBM, 2008b). Aplikace může integraci s jiným systémem zahájit pomocí tohoto frameworku na základě akce uživatele nebo například na základě vzniku určité události. Framework podporuje také dávkové zpracování příchozích a odchozích zpráv Zhodnocení kritéria - integrace Aplikace vyvinuté na platformě IBM Maximo mohou pro integraci s jinými systémy využít Integration Framework. Tento Framework je součástí platformy a poskytne jim potřebnou funkcionalitu. Není tedy potřeba, aby samotné aplikace řešily integrační rozhraní v rámci své funkcionality. Platforma obsahuje prostředky, které aplikacím usnadňují integraci s jinými systémy, a proto je toto kritérium splněno. 4.6 Zhodnocení vhodnosti platformy IBM Maximo Platforma IBM Maximo splňuje všechna tři kritéria definovaná pro posouzení vhodnosti této platformy pro systém pro správu vozového parku. Obsahuje nástroje pro vývoj a úpravy aplikací, nástroje usnadňující přenos aplikací mezi různými instalacemi platformy a také obsahuje framework, který aplikacím zprostředkovává integraci s ostatními systémy. Tím platforma IBM Maximo splnila stanovenou hranici pro přijmutí platformy a lze prohlásit, že na základě definovaných kritérií je platforma IBM Maximo vhodná k vývoji nových aplikací, které budou tvořit nový informační systém pro správu vozového parku. 22

31 5. Implementace Tato kapitola popisuje implementaci nového informačního systému pro správu vozového parku na platformě IBM Maximo. Tento nový informační systém je vytvořen tak, aby splňoval požadavky definované na systém pro správu vozového parku, které jsou uvedeny v kapitole 2. Pro splnění těchto požadavků jsou v platformě IBM Maximo vyvinuty nové aplikace, které jsou v této kapitole uvedené a popsané. Tato kapitola také popisuje způsob, jakým probíhal samotný vývoj a obsahuje výčet a stručný popis použitých technologií a softwaru. Jsou zde také uvedeny vytvořené a použité komponenty v rámci platformy Maximo, které zajištují funkčnost aplikací. V závěru této kapitoly jsou také přiložené klíčové obrazovky nově vytvořeného systému a jejich výřezy se stručným vysvětlením, a to především v souvislostech k požadavkům kladených na tento nový informační systém. 5.1 Použité technologie a software pro vývojové prostředí V této kapitole jsou uvedeny použité technologie a použitý software pro vytvoření informačního systému pro správu vozového parku IBM Maximo Asset Management 7.5 IBM Maximo je rozsáhlé a robustní softwarové řešení na které lze pohlížet různými způsoby. IBM Maximo můžeme chápat jako spustitelný produkt Maximo Asset Management. Tento produkt se skládá z šesti základních modulů, kdy každý modul obsahuje řešení generalizované sady požadavků. Lze tedy říci, že se v tomto případě jedná o typový aplikační software. Mezi tyto moduly patří: Asset Management, Work management, Service management, Contract management, Inventory management a Procurement management. (IBM, 2014a) V každém tomto modulu se nacházejí aplikace, které poskytují uživateli určitou část funkcionality. Kromě tohoto pohledu, můžeme na Maximo pohlížet také jako na technologickou platformu. Pojem platforma je v tomto případě chápán ve svém širším pojetí tak, jak je například uveden v (Bruckner, et al., 2012) tedy, že se jedná o souhrn hardwaru, základního softwaru a služeb, které umožňují provoz a/nebo vývoj aplikací, které jsou přenositelné v rámci tohoto souhrnu. Maximo tuto definici splňuje, protože v rámci tohoto produktu lze provozovat a vyvíjet nové aplikace, které jsou přenositelné na jiné instance Maxima. Způsoby jakými Maximo umožňuje vývoj a úpravu aplikací jsou uvedeny v kapitole Vhodnost platformy IBM Maximo, kde jsou tyto nástroje detailněji popsány. Vzhledem ke zcela specifickým požadavkům na informační systém pro správu vozového parku, které jsou definovány v kapitole 2.4 Požadavky na nový systém a návrhy řešení, tato bakalářská práce přistupuje k softwaru IBM Maximo jako k technologické platformě, na které lze vyvinout a provozovat nové aplikace. Tyto nově vyvinuté aplikace tak mohou 23

32 přesně splňovat stanovené požadavky a podporovat stávající zavedené procesy probíhající v konkrétní společnosti IBM WebSphere Application Server 7.0 IBM WebSphere Application Server 7.0 je použit jako aplikační server pro IBM Maximo, který pro platformu Maximo zajišťuje základní infrastrukturu a služby IBM DB Pro uložení dat byla použita databáze IBM DB 2 ve verzi 9.7. DB2 je robustní relační databáze, která je schopná zpracovávat velké objemy dat a je přizpůsobená pro podnikové informační systémy. Jak již bylo zmíněno v předchozí kapitole, aplikace Database Configuration v rámci platformy Maximo odstiňuje závislost mezi aplikacemi provozovanými na této platformě a konkrétní databází. Je tedy možné nově vytvořené aplikace přenést na jiné prostředí Maximo, kde může být použita jiná databáze. Může se například jednat o databázi DB2 v jiné verzi nebo o databázi jiného výrobce DB2 Control Centre a Command Editor DB2 Control Centre je uživatelsky přívětivé rozhraní pro práci s databází, které dovoluje vykonat většinu úkonů potřebných pro nastavení a konfiguraci databáze DB2. Command Editor je grafický nástroj pro práci s SQL. Pomocí Command Editoru je možné generovat a upravovat příkazy napsané v jazyce SQL. Tento nástroj také umožňuje pracovat s výsledným výstupem a například zobrazit grafické znázornění přístupového plánu pro příkazy SQL. Tyto dva nástroje byly v rámci implementace vozového parku použity pro monitorování a údržbu databáze, kontrolu datových struktur databáze a pro zálohy testovacích dat použitých k prověření nového informačního systému Eclipse Eclipse je multiplatformní vývojové prostředí, určené pro programování v jazyce Java. Toto prostředí může být rozšířeno pomocí pluginů o podporu dalších programovacích jazyků jako je například C, C++, Fortran, JavaScript, PHP, Scala a další. V rámci těchto pluginů lze Eclipse rozšířit i o další užitečné nástroje jako jsou například nástroje používané k modelování v notaci UML a BPMN. Projekt Eclipse původně vznikl na půdě IBM jako proprietární software, jehož cílem bylo sjednotit různá vývojářská prostředí používaná a nabízená zákazníkům. Později v roce 24

33 2001 byl projekt transformován a uvolněn pro širokou komunitu jako open source (Eclipse, 2014). Při vývoji informačního systému pro správu vozového parku byl Eclipse použit pro vytvoření nových Java tříd, které zajišťují business logiku nově vytvářeným aplikacím v platformě IBM Maximo Apache Subversion Apache Subversion je verzovací systém, který byl použit ke správě zdrojových kódů aplikací vyvinutých v rámci platformy. Jednalo se především o zdrojové kódy Java a XML definice aplikací. 5.2 Omezení vývojového prostředí Maximo podporuje přes 20 jazyků, mezi kterými je i čeština (IBM, 2014b). Pro vývojové prostředí byla použita anglická verze platformy Maximo 7.5, proto i nově vyvíjené aplikace zachovávají angličtinu jako výchozí jazyk. Všechny pojmy používané v rámci kapitoly 2.4 Požadavky na nový systém a návrhy řešení byly přeloženy do angličtiny. Tím je zajištěna jazyková konzistence mezi platformou a aplikacemi. Při použití na produkčním prostředí je samozřejmě možné použít češtinu jako výchozí jazyk. Platforma IBM Maximo podporuje i více jazyků současně, kdy každý uživatel může s aplikacemi pracovat v jiném jazyku, na základě jeho preference (Beuchert, 2013). 5.3 Metodika vývoje Při vývoji informačního systému pro správu vozového parku byly použity agilní přístupy a principy vývoje softwaru s týdenním vývojovým cyklem. Tento týdenní vývojový cyklus přibližně reflektoval iterace rozhovorů, prováděné přímo ve společnosti v rámci analýzy. Cílem jednoho vývojového cyklu bylo implementovat požadavky a odsouhlasené návrhy, které byly definovány předchozí týden v rámci analýzy a to tak, aby během další této iterace bylo možné novou funkcionalitu přímo demonstrovat. V případě, že vzhledem k rozsahu požadavků nebylo možné tento cíl splnit, bylo snahou alespoň připravit takzvaný mock-up 1. Tento mock-up měl za cíl přiblížit budoucím uživatelům funkcionalitu systému, aniž by byla kompletně implementována. Jednalo se především o návrhy uživatelského rozhraní a rozmístění ovládacích prvků s vysvětlením principů, jak budou tyto prvky fungovat a čeho bude možné pomocí těchto ovládacích prvků v systému dosáhnout. Tímto způsobem bylo možné celý systém včas demonstrovat zadavatelům 1 Mock-up reprezentuje při vývoji softwaru návrh nedokončené části systému, který je určený pro předvedení budoucím uživatelům (Chung a Zhang, 2003) 25

34 v přívětivé a srozumitelné podobě a včas odhalit případné změny požadavků kladené na nově vytvářený systém, které byly řešeny v rámci analýzy systému. 5.4 Vytvořené aplikace Pro zajištění požadované funkcionality informačního systému byly vytvořeny následující aplikace, které tuto funkcionalitu zpřístupňují uživatelům Aplikace Vozový park Tato aplikace je základní aplikací zpřístupňující většinu funkcionality definované v požadavcích na informační systém. K této aplikaci mají přístup jak běžní uživatelé systému, tak uživatel v roli Správce vozového parku. Vzhledem k zařazení právě přihlášeného uživatele do systému tato aplikace nabízí pouze funkcionalitu a data, ke kterým má uživatel přístup Aplikace Osoby Aplikace osoby umožňuje spravovat všechny uživatele vozidel, jedná se tedy i o uživatele, kteří nemají zřízen přístup do informačního systému pro správu vozového parku společnosti, ale vozidla společnosti mohou využívat. K této aplikaci má přístup pouze uživatel v roli Správce vozového parku a umožňuje mu vytvořit novou osobu, kterou poté může používat v aplikaci Vozový park, například přiřadit ji jako odpovědnou osobu za vozidlo, evidovat za ni uskutečněné jízdy nebo tankování. Tato aplikace také umožňuje zobrazit všechna vozidla, za která zvolená osoba zodpovídá. V případě, že je v informačním systému založen nový účet pro uživatele, který mu zajišťuje přístup do systému, je mu automaticky vytvořen i patřičný záznam v této aplikaci a je možné tohoto nového uživatele okamžitě používat v rámci systému Aplikace Kniha jízd Tato aplikace je pomocnou aplikací a má k ní přístup pouze uživatel v roli Správce systému. Zatímco aplikace Vozový park dokáže zobrazovat knihu jízd vázanou pouze na určité vozidlo, tato aplikace Kniha jízd umožňuje zobrazit záznamy pro všechna vozidla najednou. Umožňuje tak Správci vozového parku vyhledat jakoukoli konkrétní jízdu aniž by věděl, jakým vozidlem byla uskutečněna. Také si například může pomocí této aplikace jednoduše zobrazit všechny jízdy uskutečněné konkrétním uživatelem nebo v konkrétní den. 26

35 5.4.4 Aplikace Tankování Obdobně jako aplikace kniha jízd je aplikace tankování pomocnou aplikací, ke které má přístup pouze uživatel v roli Správce vozového parku. Tato aplikace dokáže zobrazit veškerá tankování pro všechna vozidla společnosti. Umožňuje filtrování a slouží zatím především ke hromadnému přehledu o realizovaných tankováních. Běžní uživatelé k této aplikaci nemají přístup, protože základní aplikace Vozový park jim umožňuje zobrazit všechna tankování v rámci jednoho zvoleného vozidla i všechna tankování v rámci jednotlivých cest realizovaných daným vozidlem. 5.5 Použité komponenty Tato kapitola obsahuje výčet a popis nově vytvořených komponent v rámci platformy IBM Maximo. Tyto jednotlivé komponenty tvoří uvedené aplikace, anebo jim zajišťují určitou část funkcionality. Názvy jednotlivých komponent jsou vytvořeny v anglickém jazyce. Aby tyto nové komponenty byly jednoznačně odlišeny od ostatních komponent tvořící jiné aplikace v rámci platformy IBM Maximo, mají zvolen jednotný prefix VF_. Tato zkratka vznikla od slovního spojení Vehicle Fleet, který v překladu znamená vozový park. Tento výčet použitých komponent je především užitečný při migraci informačního systému na jinou instanci platformy IBM Maximo Objekty Pro uchování specifických dat pro potřeby nového informačního systému byly vytvořeny následující nové objekty. Tyto objekty jsou začleněny do platformy IBM Maximo a tvoří tak s ostatními objekty, které v této platformě již existují, datovou základnu pro nový informační systém pro správu vozového parku. VF_VEHICLES Tento objekt uchovává údaje o vozidlech. VF_MAINTENANCE Tento objekt uchovává údaje o provedených údržbách vozidla. VF_FUELING Tento objekt uchovává údaje o uskutečněných tankováních. VF_JOURNEYLIST Tento objekt uchovává údaje o uskutečněných jízdách. 27

36 5.5.2 Definice Aplikací Samotné definice nově vytvořených aplikací jsou uvedeny v následujících strukturách, které je možné pomocí aplikace Application Designer exportovat do XML. Název této struktury pak odpovídá názvu dokumentu XML. VF_FLEET Definice aplikace Vozový park. VF_PEOPLE Definice aplikace Osoby. VF_JOURNEY Definice aplikace Kniha jízd. VF_FUELING Definice aplikace Tankování Modifikace LOOKUPS Lookups je systémový dokument XML, který obsahuje nastavení pro zobrazení generovaných dynamických číselníků v rámci platformy IBM Maximo. Pro potřeby nového informačního systému byly do tohoto dokumentu přidány následující položky: vf_globalstatus Definuje zobrazení pro číselník globálních statusů vozidel. vf_valuelist Definuje zobrazení pro základní vzhled číselníků. vf_valuelistsortbydescrip Definuje základní zobrazení číselníků řazených dle popisku jednotlivých položek číselníku. vf_persontovehicle Definuje zobrazení pro číselník dynamicky generující seznam použitelných osob v rámci informačního systému. 28

37 5.5.4 Domains Pro nový informační systém byly vytvořeny následující Domains. Tyto Domains definují zdrojová data nebo určují zdrojovou datovou základnu pro číselníky použité v rámci platformy. VF_DEPARTMENT Definuje přípustné hodnoty pro zařazení vozidla v rámci oddělení společnosti. VF_FUELTYPES Definuje přípustné hodnoty pro druh paliva používaného ve vozidlech. VF_GLOBALSTATUS Definuje přípustné hodnoty pro globální stav vozidel. VF_MAINTENANCEEVEN Definuje přípustné hodnoty pro událost, vedoucí k založení záznamu v sekci údržba vozidla. VF_PERSONTOFUELING Definuje přípustné hodnoty pro osoby, které provedly tankování. VF_PERSONTOJOURNEY Definuje přípustné hodnoty pro osoby, které absolvovaly danou cestu vozidlem. VF_PERSONTOMAINTEN Definuje přípustné hodnoty pro osoby, uvedené v sekci údržba vozidla. VF_PERSONTOVEHICLE Definuje přípustné hodnoty pro odpovědné osoby za vozidlo. VF_STATUSMAINTENAN Definuje přípustné hodnoty pro stavy údržby vozidla. VF_TRANSMISSION Definuje přípustné hodnoty označující typ převodovky vozidla. VF_TYPEOFVEHICLE Definuje přípustné hodnoty označující typ vozidla. 29

38 5.5.5 Uživatelské skupiny Pro splnění požadavků na různou funkcionalitu v rámci definovaných rolí a zpřístupnění jen určitých dat, vzhledem k pracovnímu zařazení pracovníků, byly vytvořeny následující skupiny: VF_COMMON Základní skupina zpřístupňující funkcionalitu pro běžné uživatele. VF_BUSINESS Skupina zpřístupňující data pro obchodní oddělení. VF_MANUFACTURE Skupina zpřístupňující data pro výrobní oddělení. VF_ADMIN Skupina určená pro uživatele v roli Správce vozového parku. VF_MANAGEMENT Skupina určena pro vrcholové vedení společnosti Template Pomocí Template lze definovat specifickou úvodní obrazovku systému. Tato obrazovka je zobrazena uživateli po přihlášení, kdy mu zobrazí potřebná data specifická k jeho roli v systému a také slouží jako hlavní rozcestí, na které se lze kdykoli vrátit. Pro potřeby informačního systému byly vytvořeny dva nové Templates. Vehicle Fleet administrator Vehicle Fleet common Vehicle Fleet administrator používají uživatelé v roli Správce vozového parku, zatímco template Vehicle Fleet common používají běžní uživatelé KPI Key performance indicator (KPI) je komponenta v rámci platformy IBM Maximo, kterou lze použít pro grafické znázornění ukazatele výkonosti. Tuto komponentu lze přidat přímo do výše uvedeného Template. Uživatel systému tedy hned po přihlášení vidí klíčové ukazatele a na základě nich se může rozhodnout podniknout příslušnou akci. 30

39 5.5.8 Java třídy Pro implementaci a rozšíření business logiky v rámci jednotlivých aplikací byly použity následující Java třídy uvedené v této kapitole. Tyto Java třídy jsou začleněny do hierarchie tříd používané v platformě IBM Maximo podle oficiální dokumentace (IBM, 2011). Balíček classes.vf.common VFConstants Třída obsahující konstanty a statické metody. FldForeignKeyInit Třída zajišťující správnou inicializaci datových podstruktur v jednotlivých datových objektech. FldCurrentUserIDInit Třída použitá ke zjištění právě přihlášeného uživatele. VfMbo VfMboRemote VfMboSet VfMboSetRemote Poslední čtyři uvedené třídy VfMbo, VfMboRemote, VfMboSet a VfMboSetRemote zajišťují začlenění informačního systému pro správu vozového parku do platformy IBM Maximo. Balíček classes.vf.beans VehicleFleetAppBean Třída zajišťující business logiku pro aplikaci Vozový park. DlgChangeToInProgress Třída zajišťující business logiku pro dialog používaný v sekci údržba při změně stavu na Rozpracovaný DlgChangeToSolved Třída zajišťující business logiku pro dialog používaný v sekci údržba při změně stavu na Vyřešený. 31

40 ChangeToOperational Třída zajišťující změnu globálního stavu vozidel na Provozuschopné. ChangeToDecommissioned Třída zajišťující změnu globálního stavu vozidel na Vyřazeno. Balíček classes.vf.vf_fueling Tyto třídy zajišťují začlenění aplikace tankování do platformy IBM Maximo. Fueling FuelingRemote FuelingSet FuelingSetRemote Balíček classes.vf.vf_journeylist FldFueling Tato třída zjišťuje, zda bylo v dané jízdě provedeno tankování. FldInitialStateKm Tato třída kontroluje, zda jednotlivé záznamy v knize tříd tvoří souvislou řadu, vzhledem ke vkládaným hodnotám tachometru. JourneyList JoueneyListRemote JourneyListSet JourneyListSetRemote Poslední čtyři uvedené třídy zajišťují začlenění aplikace Kniha jízd do platformy IBM Maximo. 32

41 Balíček classes.vf.vf_maintenance FldEvent Tato třída zajišťuje změnu globálního stavu vozidla na základě vkládaných záznamů do části údržba vozidla. Maintenance MaintenanceRemote MaintenanceSet MaintenanceSetRemote Poslední čtyři uvedené třídy zajišťují začlenění sekce údržba do platformy IBM Maximo. Balíček classes.vf.vf_vehicles FldVehicleRegistrationPlate Tato třída zajišťuje jedinečnost registračních značek vozidel. VehicleFleet VehicleFleetRemote VehicleFleetSet VehicleFleetSetRemote Poslední čtyři uvedené třídy zajišťují začlenění aplikace Vozový park do platformy IBM Maximo. 33

42 5.6 Vytvořený informační systém uživatelské rozhraní Tato kapitola obsahuje informace o nově vytvořeném informačním systému pro správu vozového parku z pohledu uživatele systému. V této kapitole jsou uvedeny klíčové obrazovky systému a jejich výřezy se stručným vysvětlením, a to především v souvislosti k požadavkům, které jsou kladeny na tento informační systém. Na obrázku číslo šest je zobrazena úvodní stránka systému umožňující přihlášení uživatele. Obr. 6: Úvodní obrazovka systému umožňující přihlášení uživatele (zdroj: autor) 34

43 Na obrázku číslo sedm je zobrazen informační systém po přihlášení uživatele v roli Správce vozového parku. V levém horním rohu jsou přístupné nově vytvořené aplikace. Vpravo největší část obrazovky zabírají náhledy na vozidla společnosti, kde je okamžitě po přihlášení vidět provozuschopná vozidla společnosti a vozidla, která potřebují opravu. Po kliknutí v tomto náhledu na určité vozidlo, je uživatel automaticky přesměrován do aplikace Vozový park a zobrazí se mu detail tohoto vozidla. V pravém dolním rohu se nachází jednoduchý ukazatel KPI, který zobrazuje poměr provozuschopných vozidel společnosti ke všem vozidlům společnosti. Obr. 7: Zobrazení systému po přihlášení uživatele v roli Správce vozového parku. (zdroj: autor) 35

44 Obrázek osm na další stránce zobrazuje detail zvoleného vozidla. V horní části jsou zobrazeny záložky. První z nich List umožňuje vyhledání a filtraci konkrétního vozidla. Druhá z nich Vehicle poskytuje základní informace o vozidle a v dolní části umožňuje zadat záznam do knihy jízd. Třetí záložka Maintenance list slouží k zobrazení evidence údržby vozidla a zpřístupňuje potřebnou funkcionalitu ke správě této sekce. Čtvrtá záložka Journey list slouží k zobrazení knihy jízd. Na rozdíl od druhé záložky, která slouží především k zadávání nových záznamů, tato záložka slouží k pohodlnému zobrazení těchto záznamů, kdy na stránku zobrazuje více záznamů najednou. Pátá záložka Fueling zobrazuje přehledně všechna tankování provedená u zvoleného vozidla. Šestá a poslední záložka umožňuje zobrazit veškeré technické detaily evidované k danému vozidlu. Obrázek devět zobrazuje aplikaci Vozový park po kliknutí na tlačítko umožňující přidat záznam do knihy jízd. Tento obrázek je zaznamenán pod uživatelem v roli Správce vozového parku, proto je možné změnit řidiče dané cesty. V pravé části obrázku je také zachycena funkcionalita, umožňující evidovat k danému záznamu jedno a více tankování. 36

45 Obr. 8: Hlavní záložka aplikace Vozový park (zdroj: autor) 37

46 Obr. 9: Přidání nového záznamu do knihy jízd (zdroj: autor) 38

47 Obrázek deset zobrazuje sekci údržba vozidla z pohledu uživatele v roli Správce vozového parku. V pravé části obrázku jsou vidět ikonky, které přehledně znázorňují stav zaevidované poruchy vozidla. Tyto ikonky slouží zároveň jako tlačítka, která umožňují uživateli v roli Správce vozového parku změnit stav dané poruchy tak, jak je uvedeno v analýze v kapitole Údržba vozidel ve vztahu ke globálním stavům vozidla. Ikonka zkřížených klíčů umožňuje změnit stav z nový na rozpracovaný. Zelená ikonka fajfky umožňuje změnit stav z rozpracovaný na vyřešený. Tuto sekci aplikace Vozový park sama automaticky kontroluje a na jejím základě mění globální stav vozidla. Obr. 10: Sekce údržba vozidla (zdroj: autor) Obrázek jedenáct zobrazuje jeden z možných způsobů, jak lze k vozidlu přiřadit odpovědnou osobu. Uživatel v roli správce vozového parku klikne na tlačítko vedle příslušného pole, tím se mu vygeneruje dynamický číselník, který načítá data z aplikace Osoby. Poté stačí ze seznamu konkrétní osobu vyfiltrovat a vybrat. Při filtrování lze použít zástupné znaky * a?, kdy * reprezentuje jakoukoli sekvenci znaků v rozmezí žádný znak až neomezeno a? reprezentuje přesně jeden jakýkoli znak. Filtr na obrázku používá k filtrování sekvenci J* v poli jméno, číselník tedy nabízí pouze osoby, jejichž jméno začíná na J. 39

48 Obr. 11: Dynamický číselník s nastaveným filtrem Uživatel v roli Správce vozového parku má také možnost místo zobrazení dynamického číselníku přejít přímo do aplikace osoby, a tam danou osobu přímo vyhledat. Tento přechod do aplikace je možný, i když osoba je již k vozidlu přiřazena. V tomto případě je uživateli zobrazen detail přiřazené osoby, kde lze nalézt informace evidované v systému o dané osobě a to především kontaktní údaje jako je , telefonní číslo a adresa bydliště. Obrázek dvanáct ukazuje možnost výběru akce, jestli použít dynamický číselník nebo přechod na aplikaci Osoby. Obrázek třináct poté ilustruje detail o uživateli v aplikaci Osoby, který je již přiřazen k vozidlu. Obr. 12: Znázornění možností použit číselník nebo aplikaci 40

49 Obr. 13: Zjištění informací o uživateli, který již je přiřazen k vozidlu. Informační systém pro správu vozového parku také kontroluje údaje vkládané uživateli do systému a provádí nad nimi základní validace. Obrázek čtrnáct znázorňuje jednu z těchto validací, kdy systém nepovolí zadat k vozidlu registrační poznávací značku, která již v systému existuje. Systém také při zadávání záznamů do knihy jízd kontroluje, jestli uváděné kilometry na sebe navazují a tvoří tak souvislou řadu. Pokud souvislou řadu netvoří, zobrazí uživateli upozornění. Uživateli je ale dovoleno tuto nevalidní hodnotu potvrdit a tím upozornění ignorovat. Tato možnost zde existuje například pro situaci, kdy jiný uživatel, který absolvoval jízdu vozidlem před vkládanou jízdou, zatím svoji jízdu do systému nevložil. Toto upozornění je zobraceno na obrázku číslo patnáct. Obr. 14: Chybová zpráva při pokusu zadat již existující registrační značku v systému (zdroj: autor) 41

50 Obr. 15: Upozornění uživatele na nenavazující hodnoty kilometrů v knize jízd (zdroj: autor) Pokud uživatel provádí změnu v systému, která má vliv na globální stav vozidla, systém uživatele požádá o potvrzení změny formou dialogového okna. Na následujícím obrázku číslo šestnáct je uveden příklad takového dialogového okna, které žádá uživatele o potvrzení změny globálního stavu vozidla ze stavu Ke koupi na stav Provozuschopné. Obr. 16: Dialogové okno požadující potvrzení změny globálního stavu (zdroj: autor) 42