pro řízení a správu vozového parku v informačním systému podniku

Mendelova univerzita v Brně Provozně ekonomická fakulta

Využití geografických dat silniční sítě pro řízení a správu vozového parku v informačním systému podniku Diplomová práce

Vedoucí práce: RNDr. Tomáš Hála, Ph.D.

Bc. Jan Grmela

Brno 2011

2

Zadání práce

Děkuji RNDr. Tomáši Hálovi, Ph.D. za cenné rady a doporučení, které mi poskytl při realizaci této diplomové práce. Dále děkuji Bc. Richardu Hartmannovi za možnost experimentálně ověřit některá, touto prací navržená, řešení v praxi.

Prohlašuji, že jsem tuto diplomovou práci zpracoval samostatně s použitím literatury, která je uvedena v seznamu.

V Brně 20. prosince 2011

....................................................

5

Abstract Grmela, Jan. Utilization of a road network geographical data for fleet control and management in a company information system. Brno: Mendel university in Brno, 2011. The diploma thesis presents the fleet management concept and it’s components. It evaluates importance and contribution of these components to the company in a company fleet management subsystem context and presents some of the commercially available solutions. It describes the modern methods for information system architecture and user interface design. The thesis suggests options for the fleet control and management web-based component using the shortest path algorithm in the road network geographical data.

Abstrakt Grmela, Jan. Využití geografických dat silniční sítě pro řízení a správu vozového parku v informačním systému podniku. Brno: Mendelova univerzita v Brně, 2011. Diplomová práce představuje pojem fleet management a jeho součásti. Hodnotí důležitost a přínos součástí pro podnik v kontextu definice požadavků na subsystém pro podporu fleet managementu IS podniku a představuje několik komerčně dostupných řešení této problematiky. Popisuje moderní nástroje pro vývoje architektury a uživatelského rozhraní webových informačních systémů. Práce navrhuje východiska realizace webové komponenty pro řízení a správy vozového parku podniku za použití algoritmu hledání nejkratších cest v geografických datech silniční sítě.

6

Seznam použitých zkratek A-GPS Assisted GPS API Application Programming Interface DARP Dial-a-Ride Problem DRM Digital Rights Management FIMS Fleet Information Management System GIS Geographic Information System GSM Global System for Mobile Communications GPS Global Positioning System IS Information System MVC Model-View-Controller OSM OpenStreetMap RIA Rich Internet Application ŘSD Ředitelství silnic a dálnic SŘBD Systém řízení báze dat TCO Total Cost of Ownership TSP Travelling Salesman Problem

7

OBSAH

Obsah 1 Úvod

8

2 Cíl práce

10

3 Řízení a správa vozového parku podniku 3.1 Principy a cíle řízení a správy vozového parku podniku 3.2 Automatizace řízení a správy vozového parku podniku 3.2.1 Vzdálené sledování vozidel . . . . . . . . . . . . 3.2.2 Analýza chování řidičů . . . . . . . . . . . . . . 3.2.3 Doporučení pro řidiče . . . . . . . . . . . . . . . 3.2.4 Odhad životního cyklu vozidel . . . . . . . . . .

11 11 12 13 14 15 16

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4 Obecné požadavky na systém pro správu vozového parku podniku 17 4.1 Definice požadavků na systém pro správu vozového parku . . . . . . . 17 4.2 Vyhodnocení požadavků před zavedením FIMS . . . . . . . . . . . . 18 5 Dostupné programové vybavení pro správu niku 5.1 TomTom Work a TomTom Webfleet . . . . . 5.2 CCS Carnet Sledování vozidel . . . . . . . . 5.3 O2 Car Control . . . . . . . . . . . . . . . . 5.4 Vodafone Sledování vozidel . . . . . . . . . . 5.5 HI Software Webdispečink . . . . . . . . . . 5.6 Radium Fleetware a Fleetware web . . . . .

vozového parku pod. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

6 Návrh služeb podporujících řízení a správu vozového parku v podniku 6.1 Sledování zeměpisné polohy vozidel . . . . . . . . . . . . . . . . . . . 6.1.1 Přijímač polohových informací . . . . . . . . . . . . . . . . . . 6.1.2 Zpracování údajů o poloze . . . . . . . . . . . . . . . . . . . . 6.1.3 Ukládání údajů o poloze . . . . . . . . . . . . . . . . . . . . . 6.1.4 Aplikační logika . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.5 Rozhraní čidel a akčních členů . . . . . . . . . . . . . . . . . . 6.1.6 Komunikační rozhraní mobilní sítě . . . . . . . . . . . . . . . 6.2 Podpora mapových služeb a služeb souvisejících s geografickými funkcemi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Komerčně dostupná geodata a služby pro práci s geodaty . . . 6.2.2 Volně dostupná data . . . . . . . . . . . . . . . . . . . . . . . 6.2.3 Uživatelské aplikace pro práci s geodaty . . . . . . . . . . . . 6.3 Sledování hodnot a parametrů vozidla . . . . . . . . . . . . . . . . . . 6.3.1 Sledování provozních parametrů vozidla na základě přímého měření . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20 20 21 22 22 23 24

25 26 27 27 27 28 28 28 29 29 30 32 33 33

8

OBSAH

6.3.2

6.4

6.5 6.6 6.7 6.8 6.9

Získání provozních parametrů vozidla na základě polohových dat a převodem již dostupných dat v systému . . . . . . . . 6.3.3 Získání provozních parametrů vozidla na základě ručního zadání uživatelem . . . . . . . . . . . . . . . . . . . . . . . . . Předávání údajů směrem z vozidla do systému a v opačném směru . 6.4.1 Předávání údajů do vozidla . . . . . . . . . . . . . . . . . . 6.4.2 Předávání údajů směrem z vozidla . . . . . . . . . . . . . . . Analytické funkce nad daty získanými při provozu systému . . . . . Automatizované generování hlášení a upozornění řidičům a fleet manažerům . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Propojení FIMS s ostatními částmi IS podniku . . . . . . . . . . . . Evidence vozidel, jejich vlastností a událostí, plánování pořízení a servisu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Řízení a správa přidělování vozidel zaměstnancům . . . . . . . . . .

. 34 . . . . .

34 35 35 35 36

. 37 . 37 . 38 . 40

7 Návrh webového rozhraní FIMS jako komponenty IS podniku 7.1 Moderní webové informační systémy . . . . . . . . . . . . . . . . . . 7.2 Funkcionalita navrženého FIMS . . . . . . . . . . . . . . . . . . . . . 7.2.1 Role zaměstnanců podniku ve FIMS . . . . . . . . . . . . . . 7.2.2 Přehled událostí . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.3 Komplexní evidence vozidel podniku . . . . . . . . . . . . . . 7.2.4 Telematické a mapové funkce . . . . . . . . . . . . . . . . . . 7.2.5 Analytické funkce FIMS . . . . . . . . . . . . . . . . . . . . . 7.2.6 Přidělování vozidel zaměstnancům . . . . . . . . . . . . . . . . 7.2.7 Podpora evidence zakázek a skladové hospodářství . . . . . . 7.2.8 Správa servisních událostí a sledování nákladů na provoz vozidel

41 41 43 43 44 45 49 56 58 59 60

8 Přínosy navržené komponenty a srovnání s existujícími řešeními 8.1 Náklady na realizaci a provoz systému . . . . . . . . . . . . . . . . 8.2 Ověření zjištěných závěrů v praxi . . . . . . . . . . . . . . . . . . . 8.3 Srovnání s komerčními systémy . . . . . . . . . . . . . . . . . . . . 8.4 Kalkulace návratnosti . . . . . . . . . . . . . . . . . . . . . . . . . .

61 61 62 64 65

. . . .

9 Závěr

67

Přílohy

72

A Snímky obrazovek dostupného programového vybavení

73

1

1

ÚVOD

9

Úvod

Doprava ve smyslu přesunu hmotných statků provází lidstvo již od dávnověku. Od starověku byla Evropa, Asie i další světadíly protkány důležitými spojovacími cestami, po kterých se tradičně statky dopravovaly. Tyto cesty byly dle nazývány podle druhu statků, které se po nich přepravovaly nejčastěji nebo podle toho, jaký význam pro dopravu měly Stezka (2011). Příkladem může být například Hedvábná stezka Jižní Asií v celkové délce asi 8 tis. km, Jantarová stezka vedoucí od Baltu do Itálie nebo, v případě Českých zemí, Zlatá stezka, která sloužila k přepravě soli (zde se označení „zlatáÿ zakládá nikoli na surovině, nýbrž na výnosnosti přepravy) z rakouských dolů na sever. Efektivitu těchto stezek dokládá například to, že španělští dobyvatelé díky kvalitní dopravní síti mohli snadno a rychle vydrancovat říši Inků při svých nájezdech do Jižní Ameriky (Slovík, 2011). Některé historické stezky se dle Hronocha (2003) postupně transformovaly na moderní silnice a dálnice a tak se částečně zachovaly až do dnešní doby. V minulosti tyto cesty vznikaly tak, aby poskytovaly co nejkratší spojení mezi výchozím a cílovým místem (tedy například mezi místem těžby suroviny a místem jejího zpracování či prodeje). Již tehdy tedy lidé aplikovali, ač nevědomky, to, čemu v dnešní době říkáme algoritmus hledání nejkratší cesty. Tehdy tyto cesty vznikaly na přirozených základech — když chci někam jít, je třeba jít určitým směrem a dorazit na místo co nejrychleji a tedy po nejkratší možné cestě. Když totiž obchodník se zbožím cestoval, nejen, že hrozilo, že se přepravované zboží zkazí (zejména v případě potravin) ale též, že za přepravu dostane méně peněz kvůli jejímu příliš dlouhému trvání. Už tehdy sice existovaly, mnohdy i dosti podrobné, mapy, kompletního zmapování se například České země dočkaly až v průběhu 16. století (Hánek, 2000). Do té doby tedy lidé museli mít informace o tom, kudy se vydat, aby se dostali do cíle své cesty, od třetí osoby nebo získat mapové podklady z více zdrojů a teprve na jejich základě výslednou cestu složit. Moderní historie výstavby dálnic, symbolu dálkové přepravy, započala v prvním desetiletí 20. století ve Spojených státech stavbou 64 km dlouhé silnice pro motorová vozidla na Long Islandu v New Yorku. Podobně se výstavba o něco později, ve dvacátých letech, rozvíjela i v Evropě stavbami závodního okruhu v Berlíně nebo 50 km dlouhé autostrády v Itálii. Stejně jako tehdy, i v dnešní době, je hlavním důvodem proč hledat nejkratší cestu v geografických datech hlavně to, abychom do cíle dorazili co nejefektivněji — tedy v nejkratším čase s nejnižšími náklady. Tyto cíle se obvykle rozšiřují ještě o další dodatečné cíle — často je vyžadováno, aby trasa vedla určitými význačnými body, (hledání je modifikováno na Problém obchodního cestujícího (Letchford, 2010)), byla vedena po určitých druzích cest, byla tvořena co nejmenším počtem křižovatek či měla profil, ve kterém se vyskytuje co nejmenší množství změn směru a podobně. Pokud se zabýváme hledáním nejkratší trasy v dnešní době, využijeme k tomuto účelu povětšinou mapu či službu poskytovanou příručním zařízením nebo některou

1

ÚVOD

10

webovou aplikací. Příkladem mohou být Google Maps1 . Je však pochopitelné, že řešení tohoto problému pro osobní potřebu je zcela jiného charakteru než řešení pro potřebu průmyslovou — tedy například v případech zásilkových služeb, dopravních společností nebo třeba jen rozvozu potravin. Rozdílů je zde mnoho — obvyklý je požadavek na automatizované hromadné zpracování bez zásahu člověka nebo zvážení dalších faktorů, které jednotliví uživatelé řeší intuitivně, nikoli algoritmicky, jakými mohou být šířka dopravních cest, výška mostních konstrukcí či nosnost vozovky. Tato práce se však nezabývá jen využitím geografických dat silniční sítě pro hledání nejkratší cesty na dané mapě, ale i souvislostmi s (zejména) ekonomickými faktory, které musí každá firma brát v potaz, chce-li svá vozidla provozovat efektivně. Pokud nejde o podnik, který se zabývá zejména přepravou zboží (tedy zejména zásilkové, poštovní a doručovací služby), nemusí nutně využívat automatizovaného řízení — stačí, když každý řidič provede zhodnocení cesty intuitivně nebo svůj cíl zadá do palubního navigačního či jiného zařízení, které dokáže nejvýhodnější trasu řidiči zjistit. Pokud však podobnou strategii použije firma, která se přímo zabývá přepravou, je to pro ni prokazatelně ekonomicky nevýhodné — britský prodejce elektroniky Sonic Megastore snížil své náklady na dopravu o 20 % nasazením automatizovaného software pro plánování cest společnosti Postcode Anywhere. Software této společnosti dokázal v testu porazit 300 ručně sestavených plánů cesty o 20 zastávkách (s prémií 250 liber pro autora nejlepšího plánu) přičemž nejlepší z ručně vytvořených plánů byl o 15 % horší než trasa navržená softwarem, navíc pochopitelně vytvořený za mnohem delší dobu (Postcode Anywhere, 2010).

1

Služba dostupná z WWW: http://maps.google.com

2

2

CÍL PRÁCE

11

Cíl práce

Diplomová práce „Využití geografických dat silniční sítě pro řízení a správu vozového parku v informačním systému podnikuÿ si klade za cíl navržení webové komponenty informačního systému podniku sloužicí pro správu vozového parku a následně provést srovnání s komerčně dostupnými řešeními této problematiky spolu s určením nákladů na instalaci a provoz srovnávaných řešení. Dílčím cílem je analýza obecných požadavků na informační systém pro správu vozového parku včetně zjištení vhodné sady funkcí, kterou by měl takový systém obsahovat. K dosažení hlavního cíle práce bude představeno několik, na českému trhu, komerčně dostupných systému a bude zhodnocena jejich funkčnost. Budou vybrána řešení zaměřující se pouze na část podnikových procesů se vztahem ke správě vozového parku, stejně tak jako řešení pokrývající většinu funkcionality zjištěné v analýze obecných požadavků. Na základě obecných požadavků a zjištěných vlastnostech komerčních systémů bude navržena funkcionalita nového informačního systému stavějícího na geografických datech silniční sítě České republiky spolu s uživatelským rozhraním, které bude pro jeho obsluhu použito.

3

ŘÍZENÍ A SPRÁVA VOZOVÉHO PARKU PODNIKU

3

12

Řízení a správa vozového parku podniku

3.1

Principy a cíle řízení a správy vozového parku podniku

Doprava zboží a osob je, zvláště v současnosti, velmi důležitým, stále rostoucím oborem. Od roku 1970 do roku 2000 se objem přepravy v zemích EU zdvojnásobil. Dle studie Evropské komise se bude tempo růstu dále zvyšovat — do roku 2030 má vzrůst nákladní přeprava v Unii o ohromujících 90 %. Zajímavá na tomto číslu není ani tak jeho hodnota, nýbrž ta skutečnost, že téměř celý tento růst se má uskutečnit prostřednictvím silniční dopravy (Goel, 2007). Jak název oboru napovídá, správa vozového parku podniku (či častěji používaný anglický termín fleet management) se zabývá všemi aspekty efektivní péče a údržby vozů (obvykle osobních a nákladních automobilů, může však jít i o letadla, lodě a další dopravní prostředky v závislosti na oboru, ve kterém se společnost pohybuje), které má podnik k dispozici pro výkon nebo pro pomoc při výkonu své podnikatelské činnosti (Powell a Topalogu, 2002). O fleet managementu se dá hovořit dle Kozla (2010) taktéž jako o „souboru činností vedoucích ke snižování nákladů na provoz firemních vozidel při dodržení vnitrofiremních předpisů, zajištění provozuschopnosti, bezpečnosti zaměstnanců a za udržení spokojenosti uživatelů vozového parkuÿ. Dle Langa (2005) se společnosti aplikující správu vozového parku zabývají zejména těmito čtyřmi činnostmi: • analyzovaním skutečného stavu vozového parku podniku s ohledem na hospodárnost (kontrola nákladů na pořízení, provoz a opravy) s cílem zjistit možnosti úspory variabilních nákladů; • zjištěním možností výhodného nákupu a leasingu vozidel — například sale-andlease-back2 či analýzy obstarání a investic kapitálu; • sledováním vývoje nákladů na provoz vozového parku — analýzy dlouhodobé spotřeby paliva, analýzy opotřebení, možnosti paušalizace nákladů na servis vozidel v závislosti na objemu předpokládaných oprav, volba pojištění vozidla či omezení doby, po kterou je vozidlo nevyužíváno; • omezením nadměrné velikosti vozového parku a zajištění prodeje ojetých vozidel. Tyto operativní činnosti a opatření jsou dle Kozla (2010) doplněny o strategické funkce, které fleet management plní: • definice flotilových potřeb podniku; • pořízení vozového parku; • nastavení podmínek dodávek s dodavateli; 2

Prodej a zpětný pronájem majetku

3.2

Automatizace řízení a správy vozového parku podniku

13

• návrhy úsporných opatření; • spolupráce s personálním oddělením na car policy (tedy podmínkami nákupu, užívání nebo prodeje vozidel); • jednání s dodavateli. Výsledkem těchto analýz a příslušných opatření má být zejména snížení nákladů na provoz, zvýšení efektivity využití vozidel, ale i zajištění přehledu o nákladech na provoz vozidel. V současné době, díky pokroku v telekomunikacích a elektronických systémech, bývá správa vozového parku podniku vnímána nejen jako teoretický obor založený na kalkulacích efektivity (například vhodných dopravních cest, financování vozidel a podobně), ale i jako obor stále silněji propojený s telematikou. Přibyl (2001) popisuje telematiku jako obor, který se zabývá propojením dopravy, telekomunikačních a informačních systémů s cílem zvýšit bezpečnost a plynulost provozu prostřednictvím (obvykle centralizovaného) sběru dat a řízení. Do aplikované telematiky spadá i například problém obchodního cestujícího řešený v reálném světě, ovlivněném stavem dopravních cest, dopravních nehod či komplikací způsobených příliš velkým počtem vozidel (tedy nedostatečnou kapacitou nebo nevhodně navrženými doopravními cestami). S tím, jak se obory telematiky a fleet managementu propojují, stírají se rozdíly mezi tím, které problémy spadají do kterého oboru. Dá se předpokládat, že tyto obory splynou, neboť již dnes jsou oba pojmy v literatuře často volně zaměňovány — hovoří se například o „sledování vozidel ve správě vozového parku podnikuÿ, což by dříve byla problematika spadající spíše do oboru telematiky (Powell a Topalogu, 2002).

3.2


Mimo otázku, zda je pro společnost vhodnější zvolit interní osobu (tedy jednoho či více zaměstnanců), který bude mít řízení a správu vozového parku na starosti, či zda si najmout externí subjekt, je nasnadě otázka, jakými prostředky vozový park podniku spravovat. Moderní fleet management a telematika nabízí vozidlům a systémům vozidla spravujícím mnoho prostředků, které do řízení vozového parku zapojit (Powell a Topalogu, 2002). Jde zejména o tyto: • vzdálené sledování vozidel (nejen v vztahu k poloze vozidla, ale i co se týče provozních parametrů jako je spotřeba, doba jízdy, rychlost a podobně); • analýza chování řidičů a doporučení pro řidiče; • zabezpečení vozidel a jejich vzdálené řízení (například odpojení zapalování v době, kdy se vozidlo nemá používat);

3.2


14

• odhad životního cyklu vozidel — tedy například určení okamžiku, kdy se má vozidlo odebrat do servisu v závislosti na provozních parametrech, stáří a využití. Všechny tyto prostředky jsou obvykle propojeny do jednoho programového celku — systému pro správu vozového parku podniku. 3.2.1

Vzdálené sledování vozidel

Technologie vzdáleného sledování vozidel je založena na dvou složkách (Al-Hanbali, 2007): • určení zeměpisné polohy vozidel; • předání informace o poloze společnosti. Pro určení zeměpisné polohy se v současnosti ponejvíce používá Global Positioning System Americké armády. Tento systém pracuje na principu triangulace při znalosti časového razítka minimálně ze tří satelitů (prosté určení polohy), lépe však ze čtyř (určení polohy včetně nadmořské výšky). Systém se skládá z celkem 32 družic nesoucích přesné atomové hodiny a vysílací aparaturu (Beaglesoft, 2010). Mimo GPS je v současnosti dostupný ruský systém GLONASS a probíhá budování evropského systému Galileo, který má, mimo jiné, za účel omezit závislost dostupnosti navigačních dat na americké vládě (ESA, 2011). Zařízení využívající tyto systémy nejsou v současnosti tolik rozšířená a proto je většina praktických aplikací řešena za pomoci systému GPS. Předání informace o poloze vozidla je obvykle realizováno datovým spojením, v komerčně dostupných zařízeních nejčastěji prostřednictvím mobilní datové sítě GSM. Periodicky nebo při změně polohy zařízení jsou data odesílána prostřednictvím sítě na určený cílový počítač, který se postará o jejich další zpracování a uložení. Vzdálené sledování vozidel je jednoznačným trendem správy vozového parku podniku. Podle studie společnosti Aberdeen Group z roku 2008 zkoumající organizace zamýšlející využít systém pro sledování vozidel (Aberdeen Group, 2008) je pro 73 % firem největším přínosem této technologie zlepšení služeb zákazníkům kvůli rychlejší reakční době na jejich požadavky. Dalšími význačnými důvody pro využití technologie sledování vozidel jsou tyto: • snížení nákladů na provoz vozového parku (46 % společností); • zvýšení produktivity při provozu vozidel (41 % společností); • prodloužení životnosti vozidel (16 % společností). Skutečné úspory, plynoucí z nasazení sledovacího systému, závisí na mnoha faktorech (zejména velikost flotily, charakter provozu vozidel, dopravní podmínky v místě provozování a další), průměrné úspory u společnosti provozující 20 vozidel

3.2


15

se pohybují kolem 25 % nepředvídatelných nákladů na servis vozidel (Gps Fleet Management Weblog, 2008). Obecně, vzdálené sledování vozidel fleet manažerovi poslouží k následujícím účelům: • ke kontrole, zda se vozidla pohybují po určených trasách, což lze dále využít k: – ověření, zda řidiči dodržují navržený plán; – kontrole, zda se zbytečně neplýtvá financemi za palivo a časem násobnými cestami při přepravě osob nebo zboží. • ke vzdálené kontrole technického stavu vozidel; • k možnosti odhadu času dojezdu do cílového místa (například pro přepravní služby informující zákazníky); • k optimalizaci tras na základě poloh čerpacích stanic a jejich cen paliva; • pro automatické vedení knihy jízd (a tedy zajištění zákonné povinnosti dokumentace pro doložení, že se vozidlo využívá k podnikatelským účelům); • ke statistickým analýzám umožňujícím lépe zkalkulovat délku a cenu přepravy na základě zkušeností s předchozí přepravou mezi výchozím a cílovým umístěním. 3.2.2

Analýza chování řidičů

Přínosy analýzy chování řidičů Dle společnosti Traffilog, jednoho z předních světových poskytovatelů systémů pro analýzu chování řidiců na silnicích, je řidič a způsob, jakým řídí vozidlo, nejdůležitějším faktorem ovlivňujícím spotřebu paliva a opotřebení vozidla (Enviweb, 2011). Systém, který tato společnost poskytuje, diagnostikuje v reálném čase akceleraci, brzdění a zatáčení. Z těchto údajů jsou následně nejen řidičům, ale i fleet manažerům poskytována doporučení pro zlepšení stylu jízdy, což ve svém důsledku vede ke snížení spotřeby paliva a zmenšení opotřebení vozidla. Dále tato doporučení mají vliv na sníženou nehodovost, což dále snižuje neočekávané náklady na provoz vozového parku. Návratnost pořizovací ceny systému se dle Traffilogu pohybuje v závislosti na rozsahu a způsobu provozování vozového parku i kolem tří měsíců. Dosažené úspory díky analyzování chování řidiče reprezentuje následující seznam: • úspora paliva 5–16 %; • snížení opotřebení vozu 15–35 %; • snížení nákladů na pneumatiky 10–40 %; • snížení prostojů o 15–25 %.

3.2


16

Princip fungování analytického systému Systém pro analýzu chování se skládá ze tří součástí — jednak je tvořen jednotkou pro určení zeměpisné polohy, dále komunikačním modulem pro přenos dat do centrály a poslední součást tvoří modul komunikující se sběrnicí vozidla. Díky tomu má systém přístup nejen k obecně dostupným veličinám jako je zrychlení nebo údaj o poloze, ale i k údajům jako je okamžitá spotřeba paliva, zbývající množství paliva v nádrži, rychlost měřená vozidlem a podobně. V kabině vozidla může být umístěn indikátor, který může řidiči, po nastavení, signalizovat například překročení rychlosti, nevhodný styl jízdy a podobně. Tato varování se nejen ukládají, ale mohou být i odesílána zodpovědným osobám. Systém disponuje databázi vozidel a jejich jízdních parametrů na jejichž základě je následně možné generovat doporučení pro řidiče při zvážení jejich konkrétního jízdního stylu. Systém též tato data dokáže agregovat do podoby souhrnu, z něhož si může fleet manažer udělat dobrý přehled o všech řidičích flotily (Enviweb, 2011). 3.2.3

Doporučení pro řidiče

Společnost využívající fleet management by měla mít nastavenou tzv. car policy, vnitřní směrnici firmy definující pravidla pro celý životní cyklus vozidla. Netýká se tedy jen samotného provozu, ale i nákupu, prodeje, či údržby vozidla. Hlavními body dokumentu car policy by měly být následující: • pravidla pro přidělování služebních vozidel zaměstnancům; • postupy při pořízení nového vozidla; • pravidla pro obměnu vozového parku; • vymezení zodpovědnosti za vozidlo; • provozní pravidla pro údržbu a servis; • pravidla pro soukromé využívání vozidel; • nastavení systému školení a kontroly způsobilosti • postupy v případě dopravní nehody; • pravidla prodeje vyřazených vozidel. Car policy šetří náklady společnosti neboť definuje jasná pravidla pro všechny procesy související s provozování vozového parku jak pro řidiče, tak pro řídící pracovníky (tedy fleet manažery). Car policy by měla taktéž stanovit pravidla pro výpočet TCO3 vozidla — tedy celkové skutečné náklady, které v souvislosti s pořízením a provozem vozidla vznikají. Samotná existence a používání car policy snižuje i náklady na lidské zdroje pro správu vozového parku neboť dobře nastavená pravidla umožní 3

Celkové náklady na vlastnictví.

3.2


17

snížení počtu zaměstnanců, kteří mají ve firmě péči o vozový park jako svoji hlavní činnost. Car policy by měla být nastavena nejen na základě vytyčení cílů, které chceme ve firmě pomocí nařízení dosáhnout, ale i na základě analýzy současného stavu (tedy například obvyklého chování řidičů) s důrazem na volbu vhodných nástrojů pro případné zlepšení nevyhovujícího stavu (Flotila, 2011). 3.2.4

Odhad životního cyklu vozidel

Kvalitní fleet management může být manažerovi přínosem i v otázkách týkajících se životního cyklu vozidel. Nejde jen o pořízení či prodej vozidel (což řeší pravidla nastavená car policy), ale i prostý odhad, kdy bude společnost potřebovat jaké modely vozidel a jakým způsobem je bude využívat. Tyto otázky jsou totiž, spíše než na podnikových pravidlech, závislé na aktuálním stavu podniku — tedy objemu přepravovaného zboží či dodávaných služeb. Pokud je fleet manažer dobře obeznámen s tím, jakým způsobem jsou vozidla využívána, dokáže lépe odhadnout, jaký objem je třeba pořídit nebo prodat v závislosti na aktuálních potřebách firmy. Prostřednictvím fleet managementu, a tedy posuzování provozních parametrů vozidel, je též možné efektivněji přistupovat nejen k výběru druhů, ale i konkrétních modelů a značek vozidel, ať už v závislosti na zkušenostech s předchozím provozem nebo potřebách podniku. Manažer může stanovit dodatečná pravidla pro provoz a údržbu vozidel nebo například nařídit generální opravu vozidla, pokud jeho parametry již neodpovídají požadovaným. Přestavba či generální oprava může být v porovnání s pořizovací cenou nového vozidla výhodnější, ač je známo, že pořizovací cena tvoří méně než 50 % celkových nákladů na vlastnictví vozidla (Nemec, 2009).

4

OBECNÉ POŽADAVKY NA SYSTÉM PRO SPRÁVU VOZOVÉHO PARKU PODNIKU

4

18

Obecné požadavky na systém pro správu vozového parku podniku

4.1

Definice požadavků na systém pro správu vozového parku

Prostředky pro správu vozového parku jsou v dnešní době reprezentovány zejména softwarovým a hardwarovým vybavením vozidel a informačních systémů podniků (CCG Systems, 2011). Správce vozového parku (fleet manažer) má díky programovým nástrojům dobrý přehled o událostech týkajících se vozového parku podniku, stavu vozidel či požadavcích řidičů. Programové vybavení pro správu vozového parku podniku poskytuje zejména tyto funkce: • sledování polohy vozidel; • sledování stavu a provozních parametrů vozidel; • analýzy a agregovaná data získaná při provozu programového vybavení; • automatické generování hlášení a doporučení jak pro řidiče, tak pro fleet manažera; • přehled o vozidlech, jimiž podnik disponuje včetně finančních aspektů jejich provozu; • řízení a správu servisních úkonů na základě plánovaných i mimořádných událostí; • správu přidělování vozidel zaměstnancům a statistiky používání; • finanční analýzy týkající se provozu a vlastnictví vozidel; • sledování a řízení dopravních tras vozidel a přepravy zboží či služeb. Od systému je dále vyžadována možnost napojení na stávající informační systém podniku — tedy dobrá interoperabilita a možnost funkce v roli komponenty informačního systému. Má-li být fleet management efektivní, je třeba zajistit dobrou integraci s ostatními procesy podniku a vhodné nastavení vazeb tak, aby nesloužila vozidla fleet managementu, ale fleet management efektivnímu provozu vozidel. Důležitost integrace systému pro fleet mangement vzrůstá spolu s tím, čím víc je podnik orientován (tedy jádro podnikání je na tyto činnosti zaměřeno) na poskytování služeb, u nichž se uplatňuje přeprava ať už zboží nebo služeb. Mimo tyto konkrétní požadavky je třeba zde hovořit i obecných architektonických požadavcích na informační systém (Konečný, 2010), zde vztažených k účelům fleet managementu. Na informační systém jsou dále kladeny tyto požadavky: • podpora strategických cílů podniku — v případě IS pro fleet management (fleet information management system — FIMS) zejména podpora efektivního řízení vozového parku a přepravy zboží či služeb;

4.2

Vyhodnocení požadavků před zavedením FIMS

19

• datová, hardwarová i softwarová integrace — začlenění FIMS nejen do softwarové platformy IS podniku, ale též do hardwarových složek systému jako jsou servery či samotná řízená a kontrolovaná vozidla; • otevřenost systému — schopnost FIMS přijímat další technické a softwarové komponenty a snadné včlenění změn při provozu; • snadná pochopitelnost IS — přístupnost FIMS pro uživatele zahrnující nejen snadnou a efektivní práci (což dále umožňuje i snazší kontrolu výstupů), ale i vhodné nastavení množiny činností vyžadovaných po uživateli (například přihlašování k vozidlu či zadávání dat o tankování paliva); • efektivnost a spolehlivost zpracování dat — FIMS musí být vytvořen tak, aby pracoval efektivně a spolehlivě a zároveň umožňoval škálování. Je vyžadována přijatelná doba odezvy systému, zabezpečení proti narušení při poruchách i odolnost proti zneužití dat. Podle Vymětala (2009) má dále informační systém být přínosem podniku v procesním řízení, využívá zejména tedy: • snahu o optimalizaci podnikových činností; • kritické zhodnocení a zavedení nejlepších používaných praktik v oboru; • učení se ze zkušeností na realizovaných projektech; • používání modelovacích technik.

4.2


Stejně jako před pořízením (nebo vlastním vývojem) a implementací kteréhokoli jiného systému pro podporu podnikových procesů, je třeba před pořízením FIMS zvážit skutečnou potřebnost tohoto systému a správně nastavit nejen požadavky, na které bude při jeho nasazení kladen největší důraz, ale i postup zavedení, resp. nahrazení současných procesů zavedením FIMS (CCG Systems, 2011). Kroky před zavedením FIMS (a tedy i pro zjištění potřeby zavedení) jsou následující: • analýza podnikových procesů ve vztahu k vozovému parku a jeho provozování; • sběr požadavků jako důvodů k zavedení FIMS (od manažerů i jiných zaměstnanců); • zjištění skutečného stavu a možností integrace současných systémů podniku (týká se jak IS — účetnictví, evidence majetku, tak například modelů vozidel či jiného hardware, u něhož předpokládáme interakci s FIMS); • analýza způsobu využívání vozidel vzhledem k jejich druhům a pracovnímu zařazení řidičů;

4.2


20

• analýza způsobu provádění servisu a doplňování paliva vozidel; • zvážení, které prvky ze současného hardware, software a systémů mají zůstat v provozu i po nasazení nového FIMS spolu s úvahou o rozumnosti takovéhoto kroku vzhledem k životnosti (i morální) a opotřebení hardware, software a systémů. Tyto analýzy a úvahy by měl provádět tým s dobrým povědomím o fungování podniku, jeho majetku, procesech a propojení s informačními systémy nebo externí dodavatel specializovaný na dodávky systémů pro podporu fleet managementu, který má výhodu nezaujatého pohledu na procesní fungování podniku a zároveň je obvykle lépe informován o všech aspektech implementace FIMS v podnicích. V případě, že bude vyhodnocení požadavků provádět tým složený přímo ze zaměstnanců podniku, je zde výhoda lepší specifikace požadavků na FIMS tak, že bude přesně odpovídat skutečným potřebám uživatelů v podniku a nehrozí zde riziko dodávky „krabicového řešeníÿ, které bude nutné následně draze a zdlouhavě uzpůsobovat potřebám podniku. Zároveň je u takového týmu podstatné ponechání rozhodnutí nikoli na osobách zodpovědných za technické zabezpečení provozu IS, ale na managementu podniku, který dokáže lépe odhadnout strategické přínosy implementace. V každém případě, ať už jde o externí či interní tým, je třeba, aby tento tým specifikoval kompletní sadu požadavků, určil časový průběh realizace a stanovil nákladové podmínky implementace. Přesné a úplné specifikování požadavků před počátkem implementace s dobře vytvořeným harmonogramem usnadní nejen skutečnou realizaci systému, ale i kontrolu právě z pozice managementu podniku.

5

DOSTUPNÉ PROGRAMOVÉ VYBAVENÍ PRO SPRÁVU VOZOVÉHO PARKU PODNIKU

5

21

Dostupné programové vybavení pro správu vozového parku podniku

Pokud webovému vyhledávači v České republice položíme dotaz na fleet management nebo správu vozového parku podniku, výsledkem hledání bude ve značném počtu případů řešení stavějící na standardizované platformě. Řešení často pocházejí z vývojových laboratoří zahraničních společností, jsou však dostupná i některá původní česká řešení, jak popisuje Strašák (2011). Nejčastěji nasazovanými FIMS jsou tyto: • TomTom Work (prostřednictvím společnosti D&COMM); • Carnet sledování vozidel; • O2 Car Control; • Vodafone Sledování vozidel (prostřednictvím služby AutoGPS společnosti Eurosat CS); • HI Software Webdispečink; • Radium Fleetware a Fleetware web. Tyto systémy ve všech případech nabízejí funkcionalitu vzdáleného sledování vozidel, liší se však množstvím dalších funkcí a jen některé z nich je možné označit za komplexní software pro správu vozového parku. Služby určení polohy na základě údajů ze zařízení umístěných na palubě vozidel poskytují (mnohdy i zdarma) i desítky dalších českých a zahraničních služeb, tyto však nedisponují dostatečnou funkcionalitou tak, aby bylo možné je v podniku nasadit v roli FIMS. V následujícím textu bude provedena analýza pouze takových řešení, která poskytují oproti prostému sledování vozidel (fleet tracking) nějakou přidanou hodnotu. Snímky základních obrazovek uvedených systémů jsou k dispozici v příloze.

5.1

TomTom Work a TomTom Webfleet

Systém TomTom Work (D&COMM, 2011) je komplexní systém, který v sobě nezahrnuje jen sledování vozidel, ale i funkce pro správu vozového parku, interaktivní rozhraní pro řidiče, které je zajišťováno prostřednictvím vozidlového navigačního zařízení propojeného s informačním systémem (společností TomTom označovaného jako „Connected navigationÿ) i webové rozhraní Webfleet (TomTom, 2011) umožňující správu vozového parku nejen prostřednictvím specializovaného softwaru, ale i prostého webového prohlížeče. Celkové spektrum TomTom Work zahrnuje tyto funkce: • sledování polohy vozidel;

5.2

CCS Carnet Sledování vozidel

22

• obousměrnou komunikaci mezi centrálou a vozidlem pro předání informací řidiči (např. změna cíle cesty) i pro přenos informací od řidiče (např. neočekávané zpoždění); • přenos cestovních příkazů do navigačního modulu ve vozidle; • podrobné výkaznictví shrnující události za určené období pro jedno vozidlo i celý vozový park — sledování přestávek, překročení rychlosti, generování knihy jízd; • snadnou přenositelnost komunikační jednotky mezi vozidly; • propojení systému s mapovým software a systémem pro příjem aktuálních dopravních informací s možností úpravy dopravních cest na základě přijatých informací; • navigační pokyny a mapové podklady uzpůsobené nejen osobním, ale i nákladním vozidlům (při zadání rozměrů, rychlosti, hmotnosti a dalších parametrů vozidla); • podpora digitálních tachografů vozidel pro určení pracovní doby, přidělení pracovního zatížení řidičům a tvorbu výkazů pro mzdové ohodnocení řidičů; • rozhraní pro integraci do IS podniku; • monitorování nestandardního chování řidičů (překročení rychlosti, vjezd do zakázaných zón).

5.2

CCS Carnet Sledování vozidel

Společnost Carnet monitorování vozidel, s.r.o. nabízí na českém trhu vlastní systém Sledování vozidel (Carnet, 2011) pro sledování a správu vozového parku. Systém je založen na vozidlové jednosměrně komunikující jednotce pro určení polohy a webovém rozhraní. Systém nabízí následující funkce: • sledování polohy vozidel; • monitorování provozních parametrů vozidel jako je rychlost, měření stavu paliva či teploty v nákladním prostoru; • zabezpečení vozidel proti krádeži spolu se službou vyhledání vozidla zásahovou službou; • generování knihy jízd; • statistické a grafové funkce — generování reportů podle řidiče, vozidla v časovém rozsahu — hlídání spotřeby, propočty průměrné spotřeby, dodržování pracovní doby, výpočty náhrad za služební jízdy a další; • evidenci vozidel v majetku podniku včetně technických parametrů, převáženého nákladu, majetkových vztahů, opotřebení či termínů (např. servisních zásahů);

5.3

O2 Car Control

23

• bezkontaktní identifikace řidiče vozidla; • podporu importu údajů o čerpání paliva.

5.3

O2 Car Control

Systém O2 Car Control (Telefónica, 2011) poskytuje mimo sledovacích funkcí i mnoho dalších funkcí fleet managementu. Stejně jako systém Carnet, i O2 Car Control realizuje svoji činnost prostřednictvím jednotky pro sledování polohy vozidla a přenášení dalších stavových údajů z vozidla a webového rozhraní pro správu. Car Control disponuje následující funkcionalitou: • sledování polohy vozidel; • vykazování ujetých kilometrů s možností odlišení soukromých a služebních jízd; • bezkontaktní identifikace řidičů; • získání informací o způsobu jízdy (aktuální rychlost, spotřeba paliva); • sledování tras vozidel s vyhodnocením pohybu vozidla na trase; • generování přehledů a statistik vozidel (průměrné spotřeby, rychlosti, počty jízd); • generování knihy jízd; • sledování výdajů za čerpání paliva s možností importu; • analytické funkce pro vyhodnocení způsobu jízdy řidičů; • evidence vozidel v majetku podniku včetně podrobností o pořízení, provozu a vlastnostech vozidla; • logistické funkce pro správu přepravy.

5.4

Vodafone Sledování vozidel

Společnost Vodafone poskytuje služby fleet managementu prostřednictvím společnosti Eurosat CS, jejich webové aplikace AutoGPS (Eurosat CS, 2007). Tato poskytuje nabídku sledování rozličných vozidel, ale i osob, jejich evidenci a správu. I systém AutoGPS je založen na principu jednotky umístěné ve vozidle komunikující s informačním systémem. FIMS AutoGPS disponuje následujícími funkcemi: • sledování polohy vozidel; • informace o tankování a stavu paliva v nádrži a porovnání se skutečným stavem získaným z ručně zadaných nebo importovaných dat;

5.5

HI Software Webdispečink

24

• sledování nejčastějších cílů vozidla a porovnání poměru služebních a soukromých jízd; • vyhledávání vozidel dle parametrů; • vytváření tiskových sestav na základě sumarizace ujetých kilometrů, průměrné spotřeby a průměrné ceny paliva; • generování knihy jízd; • sledování dalších výdajů spojených s provozem vozidla; • možnost rozšíření jednotky o měření provozních stavů průmyslových vozidel (např. bagr je v činnosti); • hlídání překročení vymezených hranic pro provoz vozidla; • správa jednotek včetně evidence přenesených dat, stavu baterie, signálu a dalších systémových údajů; • správa vozidel.

5.5

HI Software Webdispečink

HI Software poskytuje službu Webdispečink (HI Software, 2011), která pracuje též na principu komunikační jednotky umístěné ve vozidle a propojení s informačním systémem, nabízí však i propojení s palubním navigačním zařízením a předávání zpráv a polohových informací ze systému řidiči i opačným směrem. Webová aplikace Webdispečink nabízí tyto funkce: • sledování polohy vozidel; • automatická tvorba knihy jízd s rozlišením služebních a soukromých jízd; • generování záznamů o provozu vozidla, příkazů k jízdě a cestovních výlohách řidiče; • komunikace s řidiči a silniční navigace; • měření spotřeby paliva; • měření teploty nákladového prostoru, otáček a teploty motoru, zatížení náprav; • plánování tras, optimalizace rozvozů a svozů zboží; • vyhodnocení vytížeností průmyslových strojů na základě průběhu otáček stroje; • oboustranná komunikace řidič–dispečink prostřednictvím doplňkové navigační jednotky s možností přenosu vzkazů, úkolů a polohových údajů; • volitelné zabezpečení vozidla proti krádeži včetně sledování pultem centralizované ochrany;

5.6

Radium Fleetware a Fleetware web

25

• mobilní aplikace pro sledování vozidel v terénu;

5.6

Radium Fleetware a Fleetware web

Software Fleetware (Radium, 2010) společnosti Radium poskytuje v kombinaci s palubní jednotkou funkce související se sledováním polohy a správy vozového parku podniku. Fleetware je klasická stolní aplikace (podobně jako TomTom Work), existuje však webová verze s menším rozsahem funkcí Fleetware web, která plní spíše jen funkci sledovacího software s knihou jízd. Plný rozsah funkcí stolního softwaru je následující: • sledování polohy vozidel; • generování knihy jízd; • elektronická identifikace řidičů; • přepínání soukromých a služebních jízd; • integrace s podnikovými IS jako je SAP, Helios nebo Abra; • prostředí pro analýzu spotřeby pohonných hmot a čerpání; • modul pro sledování práce na zakázkách; • sledování motohodin, histogram otáček; • plánování jízdních řádů s automatickým sledováním dojezdů; • zakázání vjezdu, opuštění či stání v zadaných oblastech; • textová komunikace s řidičem; • zaznamenávání informací z čidel ve vozidle a jejich identifikace (např. otevření kurfu mimo oblast vykládky); • ochrana vozidel proti krádeži, sledování bezpečnostní agenturou.

6

6

NÁVRH SLUŽEB PODPORUJÍCÍCH ŘÍZENÍ A SPRÁVU VOZOVÉHO PARKU V PODNIKU

26

Návrh služeb podporujících řízení a správu vozového parku v podniku

Předtím, než je možné začít s návrhem a popisem služeb podporujících řízení a správu vozového parku v podniku, je třeba si položit otázku, které oblasti fleet managementu současné systémy úspěšně řeší a kde jsou naopak nedostatky, které by měl nový systém pokrývat a případně jakou další, nezmíněnou, funkcionalitu by bylo vhodné, v souladu s obecnými požadavky na systém podporující fleet management, do systému začlenit. Společnou vlastností všech dříve zmíněných systémů je dobrá podpora funkcí směřujících k zobrazení a ukládání zeměpisné pozice vozidel spolu s analytickými možnostmi přímo souvisejícími s touto funkcionalitou. Systémy se však liší co do kvalitativních i kvantitativních parametrů ostatních funkcí přímo nesouvisejících se sledováním vozidel. Na základě požadavků uvedených v kapitole 4 „Obecné požadavky na systém pro správu vozového parku podnikuÿ bylo určeno, že je třeba, aby systém disponoval následující funkcionalitou: • sledováním zeměpisné polohy vozidel; • podporou mapových služeb a služeb souvisejících s geografickými funkcemi; • sledováním hodnot a parametrů vozidla; • předáváním údajů směrem z vozidla do systému a v opačném směru; • analytickými funkcemi nad množinou dat získaných při provozu systému; • automatizovanými, inteligentními funkcemi pro generování hlášení a upozornění řidičům i fleet manažerům; • propojením do ostatních částí IS podniku včetně zadávání zakázek, skladového hospodářství, informací o zákaznících společnosti a účetního systému; • evidencí vozidel v majetku firmy včetně všech pořizovacích a provozních parametrů s vazbou na IS evidence majetku podniku; • správou provozních údajů o vozidlech, plánováním pořízení, servisu a prodeje vozidel; • řízením a správou přidělování vozidel zaměstnancům, evidencí událostí při provozu a evidencí používání vozidel zaměstnanci. Tyto funkce definují základní komponenty informačního systému pro podporu fleet managementu. Funkce byly vybrány na základě zkušeností z používání komerčně dostupných služeb — tedy ty, které byly při testovacím provozu nejvíce využitelné v souladu s obecnými doporučeními pro FIMS, byly vybrány pro další analýzu. Do sady funkcí určených komerčními řešeními byly poté přiřazeny i funkce,

6.1

Sledování zeměpisné polohy vozidel

27

které nebyly v testovaných systémech k dispozici vůbec nebo jen v omezené míře ale přesto by bylo vhodné je zařadit do návrhu nového systému. Některými evropskými společnostmi bývají funkce sledování hodnot a parametrů vozidla, oboustranná komunikace mezi vozidlem a systémem, analytické funkce, inteligentní hlášení a propojení do ostatních částí IS podniku souhrnně označovány jako fleet controlling (ySystem, 2011). Tento termín je v marketingové komunikaci používán zejména českou společností ySystem, která termín zřejmě vytvořila a poprvé použila na veletrhu v Mnichově v roce 2007 (CCB, 2007).

6.1


Pro sledování zeměpisné polohy vozidel (a přenos dat do informačního systému) je obvykle v praxi využívání integrovaný modul disponující rozhraním pro určení polohy pomocí GPS či jiného geolokačního systému, softwarem pro zpracování a ukládání dat a komunikaci s informačním systémem. Modul obvykle disponuje i dalšími vstupy a výstupy (Černý, 2005), které umožňují nejen získávání dat přímo z počítače řídícího automobil, ale jejich zadávání a dále připojení specializovaných čidel a akčních členů automobilu (například detekce otevření kufru, měření teploty v nákladovém prostoru nebo blokování zapalování). Blokové schéma vozidlové jednotky je zobrazeno na ilustraci 1.

Obr. 1: Blokové schéma modulu sledování zeměpisné polohy vozidel

6.1


6.1.1

28

Přijímač polohových informací

Přijímač polohových informací je citlivý rádiový přijímač vybavený buď integrovanou anténou (jednodušší či přenosné moduly pro sledování zeměpisné polohy) nebo připojením k anténě samostatné, která může být umístěna za oknem nebo na venkovním povrchu vozidla, což zlepšuje příjem v obtížných situacích a zvyšuje kvalitu poskytovaných polohových dat. Přijímač pracuje i ve vnitřních prostorách a místech bez přímého výhledu na oblohu, jeho přesnost se však snižuje a zpomalují se reakce na změnu polohy (Carter, 1997). 6.1.2

Zpracování údajů o poloze

Blok zpracování údajů o poloze, v dnešní době nejčastěji realizovaný jako samostatný GPS modul, je autonomní jednotka, poskytující na výzvu polohová data. Volitelně může být propojena i s modulem komunikace s mobilní sítí, což zrychluje prvotní určení zeměpisné polohy. Toto propojení (nazývané Assisted GPS, A-GPS) využívá datové spojení do mobilní sítě, která poskytuje prostřednictvím svých vysílačů, přibližnou polohu zařízení v prostoru. Zařízení disponující A-GPS tedy nemusí shromáždit tak velké množství časových razítek z navigačních satelitů než je poloha určena. A-GPS má význam zejména v husté městské zástavbě, která nejen že komplikuje jasný výhled na oblohu, ale kvůli odrazům a lomům signálu i jeho dekódování. V městské zástavbě je navíc větší hustota pokrytí mobilní sítí, což dále přispívá ke zpřesnění údajů o poloze poskytnutých přijímači z mobilní sítě (Skytel, 2004). 6.1.3

Ukládání údajů o poloze

Poté, co je na dotaz řídícího bloku (zde označen jako „Aplikační logikaÿ) zjištěna zeměpisná poloha, je třeba ji uložit pro pozdější použití. Obvyklá praxe je, že jednotka, ve chvíli, kdy nemá spojení s mobilní síti (nebo v této síti není k dispozici datový komunikační kanál), ukládá údaje o poloze spolu s dalšími informacemi, jako je síla a kvalita polohového signálu nebo například stav napájení jednotky pro sledování zeměpisné polohy vozidel, do paměti pro pozdější využití. Poté, jakmile je spojení mobilní sítí opět navázáno, jsou údaje z paměti přečteny a odeslány do informačního systému pro další zpracování. Některá levnější zařízení tímto blokem nedisponují (nebo jej mají omezený jen na bezprostředně nutnou kapacitu pro zpracování přijatých polohových údajů). Též se vyskytují zařízení, která mají tento blok rozšířený s tím, že naopak nejsou tato zařízení vybavena blokem komunikace s mobilní sítí. Tato zařízení, moduly tzv. pasivní logistiky, je nutné periodicky připojovat k informačnímu systému pro zpětné vyčtení polohových dat zaznamenaných za dobu, po kterou byl modul v provozu (Štěpánek, 2008).

6.1


6.1.4

29

Aplikační logika

Blok aplikační logiky je jádrem vozidlové jednotky. Jednotka disponuje následující funkcionalitou: • další zpracování polohových dat; • nastavování uživatelských parametrů pro zpracování dat; • algoritmy pro řízení datových spojení s informačním systémem a komunikaci (TCP/IP, Ethernet); • reakce na události jednotky nebo jejího okolí (např. v závislosti na vstupech); • předávání příkazů pro akční členy jednotky; • registrace a správa oprávněných uživatelů (systémů) pro komunikaci. Všechny činnosti a události spravuje jednotka současně — obvykle je možné komunikovat s jednotkou více různými cestami (data, hlas, SMS) i jednotku různými způsoby konfigurovat. Pokud je jednotka vybavena rozhraním například pro propojení s navigačním modulem vozidla (kupříkladu pro předávání zpráv uživateli a informačnímu systému), je tento připojen právě k bloku aplikační logiky. V řídícím bloku jsou vyhodnocována polohová data i ve smyslu manipulace s jednotkou jako je například hlášení o změně polohy (tedy rozjetí vozidla), změně umístění jednotky mimo vymezené hranice, informace o jejím zapnutí či vypnutí, zaplnění paměti a podobně. 6.1.5

Rozhraní čidel a akčních členů

Volitelně může být vozidlová jednotka vybavena čidly a akčními členy. Tyto umožňují rozšířit základní funkcionalitu spočívající v hlášení polohy o další možnosti. Čidla jednotky mohou být využívána například k snímání teploty (užitečné například pro podniky převážející zboží podléhající rychlé zkáze), stavu palivové nádrže, skutečné rychlosti dle počítače vozidla, okamžité spotřeby, stavu otevřenosti kufru či dveří, úrovně zaplnění nákladového prostoru a podobně. Naproti tomu akční členy mohou sloužit nejen k vzdálenému řízení prvků vozidla (indikátor překročení povolené rychlosti či doporučení k jízdě na odstavné parkoviště za účelem přestávky), ale i jako opatření například proti krádeži (odpojení zapalování, spuštění alarmu v případě pohybu vozidla v nepracovní době). 6.1.6

Komunikační rozhraní mobilní sítě

Ač je možné nalézt na trhu jednotky, které mobilní síť nepoužívají a komunikují jiným způsobem, například přes satelit (Spot, 2011), ve velké většině případů jsou vozidlové jednotky vybaveny modulem pro komunikaci pomoci GSM (nebo CDMA ve Spojených státech a některých dalších zemích) či 3G a tedy datových protokolů

6.2

Podpora mapových služeb a služeb souvisejících s geografickými funkcemi

30

GPRS/EDGE/HSPA. Blok komunikačního rozhraní je, podobně jako blok přijímače polohových informací, vybaven citlivou anténou a je samostatným modulem vozidlové jednotky. Mimo zprostředkování modemových funkcí (tedy datového spojení přes mobilní síť do informačního systému) disponuje blok komunikačního rozhraní i telefonními funkcemi (například zprostředkování zvukového pozadí v okolí přijímače) a funkcí krátkých textových zpráv. Tyto jsou použity nejen pro počáteční nastavení, ale dle Strašáka (2011) je možno touto cestou provádět i zjištění polohy a dalších údajů o jednotce na dotaz uživatele.

6.2


Pokud uvažujeme jako součást FIMS subsystém pro sledování vozidel, je nepochybně třeba poskytnout uživateli nejen možnost zobrazení souřadnic, na kterých se vozidla nacházejí, ale i zobrazení polohy nebo trasy na mapě, vyhledání vozidel podle jejich aktuální polohy nebo zjištění nejbližších vozidel. Tato funkcionalita se však neobejde bez dostatečně rozsáhlé množiny geografických dat a funkcí či algoritmů s nimi pracujících. Pro řešení tohoto problému v zásadě dva přístupy (Grmela, 2009): 1. využití komerčně dostupných geografických dat a služeb; 2. volně dostupná data a in-house4 vyvinuté či upravené aplikace pro práci s nimi. Nejdůležitějšími funkcemi, které by měla mapová služba do FIMS přinést, jsou tyto: • mapové podklady pro zobrazování polohy a trasy vozidel; • analytické nástroje pro převod mezi souřadnicemi a místními názvy (například pro vyzvedávání a doručování zásilek); • nástroje pro měření vzdálenosti a plochy; • volitelně rozšiřitelné uživatelské rozhraní umožňující ovládání funkcí a zobrazování mapových podkladů. Další funkce, které služba přinese, mohou zvyšovat komfort práce s daty nebo nabízet další analytické a syntetické možnosti pro práci s geodaty. 6.2.1

Komerčně dostupná geodata a služby pro práci s geodaty

Momentálně asi nejznámější službou nabízející geodata je projekt Google Maps společnosti Google. Aplikace disponuje rozsáhlým rozhraním s podporou pro Javascript, JSON, XML či Flash, jehož pomocí jsou zpřístupněny níže uvedené funkce (Google, 2011): 4

Software vyvinutý vývojáři organizace, kteří jej budou využívat.

6.2


31

• zobrazování mapy pro zadaný rozsah souřadnic včetně možnosti použití vlastních mapových podkladů; • převod zeměpisných názvů na souřadnice (geokódování) a převod souřadnic na místní názvy (reverzní geokódování); • výpočet vzdálenosti či plochy mezi zadanými místy; • vyhledávání nejkratší cesty mezi zadanými místy s širokou škálou nastavení ovlivňujících výpočet (omezení na určité druhy tras, možnosti volby druhu vozidla, uvážení dopravní situace a podobně); • zobrazování uživatelských bodů či oblastí na mapě a manipulace s nimi. Z výše uvedeného plyne, že primárně jsou Google Maps určeny nikoli pro automatizovaný provoz bez uživatelského rozhraní (ač je část funkcionality dostupná i nezávisle), ale spíše pro přímé použití v uživatelském rozhraní aplikace jako jeho součásti. Dalšími službami, které nabízejí API pro uživatelskou práci s geografickou aplikací, jsou například Mapy.cz společnosti Seznam nebo Bing Maps společnosti Microsoft. Obě tyto služby nabízejí obdobný rozsah funkcí jako Google Maps, v prvním případě je však nejlépe zajištěno mapové pokrytí českého území, v případě druhém jsou nejlépe pokryty Spojené státy. Neuvažujeme-li použití výhradně v těchto zeměpisných lokalitách, jsou výhodným kompromisem právě Google Maps, které nejen že mají kvalitní mapové podklady (Ciepluch a kol., 2010), ale podporují dobře i internacionalizaci5 . Mimo výše uvedené služby jsou k dispozici i komerční geodata a nástroje pro práci s geodaty dalších společností jako je například TomTom, Navteq, Tele Atlas a ViaMichellin či z českých společností Plan Studio, Kartografie nebo Geodis. Nástroje a geodata těchto společností jsou poskytována za úplatu a v určitém rozsahu. Tato data disponují širším rozsahem parametrů a větší podrobností než data nabízená zdarma (při splnění licenčních podmínek), je však ke zvážení, zda se takováto investice, v případě konkrétního mapového subsystému FIMS, vyplatí — je třeba zvážit nejen potřebnost podrobnějších geodat a služeb širšího rozsahu, ale i další faktory jako je například poskytované aplikační a uživatelské rozhraní či úplnost pokrytí území, na němž bude podnik svůj vozový park provozovat. 6.2.2

Volně dostupná data

Většina světově dostupných geodat je k dispozici výhradně na komerční bázi, ač často pod licencí umožňující nekomerční či alespoň neautomatizované použití zdarma. Důvod k tomuto je prostý — pořizování kvalitních geodat je velmi nákladný dlouhodobý 5

přizpůsobení uživatelského rozhraní a zobrazených hodnot místu použití (oddělovač desetinných míst, měna, míry, váhy, . . .)

6.2


32

proces (Polovinčák, 2011) a pořizování obecně použitelných geodat (tedy využitelných veřejností) mimo zvláštní, typicky oborové, případy, není snadné financovat. Proti této skutečnosti lze postavit zřejmě nejznámější a nejrozsáhlejší geografický projekt, jenž nabízí geodata zdarma — OpenStreetMap. Tento projekt je spoluvytvářen tisíci uživateli a funguje na podobném principu jako webová encyklopedie Wikipedie. Všechna data projektu OpenStreetMap nejen že je možné získávat a upravovat prostřednictvím definovaného rozhraní (OSM Wiki, 2011), ale i stáhnout jako celek pro další použití, což může být, v případě budování samostatného mapového modulu FIMS, velmi užitečná vlastnost. Data OpenStreetMap jsou nabízena za jednotných licenčních podmínek dle licence Open Database License. Základními principy ODbL jsou následující body (OKF, 2011): • můžete databázi kopírovat, distribuovat a používat; • můžete vytvářet práce na základě databáze; • můžete databázi upravovat, transformovat a stavět na ní. Všechna tato práva vám náleží za splnění následujících podmínek: 1. musíte u každého veřejného použití databáze nebo z ní vycházejících prací uvést autora. Pro další použití nebo redistribuci databáze nebo prací z ní vycházejících musíte dát jasně najevo licenci, vztahující se na databázi, a ponechat nedotčené všechny poznámky k původní databázi. 2. Pokud veřejně používáte upravenou verzi databáze nebo práce z ní vycházející, musíte upravenou databázi nabízet pod licencí ODbL. 3. Pokud redistribuujete databázi nebo nebo její upravenou verzi, můžete použít technických prostředků omezujících manipulaci s prací (například DRM6 ) pokud nabídnete i verzi bez těchto omezení. Z povahy projektu OpenStreetMap není možné zajistit úplnou jistotu dodržení kvality a dostatečné podrobnosti geodat ve všech popisovaných lokalitách. Podklady jsou totiž tvořeny převážně nadšenci a to nikoli tam, kde podklady chybí nebo jsou nedostatečné ale tam, kde je taková práce pro uživatele nejpřitažlivější. Z toho důvodu je rozumné o OpenStreetMap uvažovat spíše jako o alternativním zdroji s výhodnými licenčními podmínkami, než jako o zdroji geodat, na kterém je zodpovědně možné postavit komerčně nasazený mapový modul FIMS. V případě geografického omezení zájmu jen na Českou republiku je k dispozici množství dalších volných zdrojů, jejichž seznam uvádí ve své prezentaci Řezník (2008). Pro účely dopravních úloh zmiňuje prezentace geodata silniční sítě poskytovaná Ředitelstvím silnic a dálnic České republiky (ŘSD). Řezník zmiňuje význačné rysy těchto dat: 6

Digital Rights Management — správa digitálních práv k obsahu — nastavení omezení přístupu ke zdrojům.

6.2


33

• k dispozici je shapefile7 se silničními úseky, uzly a finální pasport; • data neobsahují přesné průběhy komunikací, ale pouze přímé spojnice mezi uzly; • data neobsahují údaje z intravilánu8 ; • data jsou dobře využitelná pro úlohy síťové analýzy — vzorně navržená struktura atributových dat; • data lze propojit s daty jiné datové sady a získat tak kvalitní podklad pro například navigační úlohy. Tyto vlastnosti geodata ŘSD předurčují pro použití v automatizovaných systémech pro dopravní úlohy, což je z části i případ mapového modulu využitelného ve FIMS. Pokud k datům ŘSD ČR přiložíme i mapová data uvedená ve výše zmíněné prezentaci, můžeme z volně dostupných zdrojů poměrně snadno sestavit množinu geodat dostatečnou pro uvažovaný účel použití v mapovém modulu FIMS. Je zde však jasné územní omezení na Českou republiku, což může, ale nemusí být problém v závislosti na cílové skupině uživatelů informačního systému pro podporu fleet managementu a geografickém zaměření podniku. 6.2.3

Uživatelské aplikace pro práci s geodaty

Stejně jako je možné rozdělit data na zpoplatněná a volně dostupná, podobná je i tržní situace v oblasti software pro práci s geodaty. Chceme-li se zorientovat na množství nabízeného GIS9 softwaru, dobrým průvodcem nám může být obsáhlý seznam encyklopedie Wikipedia (2011). Zde je třeba se zaměřit zejména na software nikoli z kategorie aplikací desktopových (tedy určených pro přímé použití), nýbrž na software kategorie mapových serverů, databází prostorových dat a knihoven pro webové i newebové služby pro práci s geodaty. Význačným softwarem, který spadá do této kategorie, jsou následující aplikace a knihovny: • mapové servery Mapnik, Geoserver, MapGuide Open Source a MapServer; • prostorové databáze PostGIS (rozšíření pro SŘBD PostgreSQL), TerraLib a SpatiaLite (rozšíření pro SŘBD SQLite); • newebové knihovny GeoTools, GDAL a Orfeo toolbox; • webové knihovny OpenLayers, MapFish, GeoBase a GeoMajas; • katalogizační aplikace GeoNetwork opensource. 7

Geografický soubor obsahující grafickou reprezentaci tvarů a rozměrů prvků mapy. Zastavěná část obce nebo obecně zastavěná plocha. 9 Geografický informační systém. 8

6.3

Sledování hodnot a parametrů vozidla

34

Výše uvedené aplikace a knihovny spadají do kategorie software s otevřeným kódem a lze je tedy využít zdarma a případně uzpůsobit uvažovanému použití v informačním systému, což je při vývoji uživatelského FIMS výhodné. Mimo tyto otevřené aplikace existuje v každé z kategorií mnoho komerčního software, který sice obvykle disponuje větším rozsahem funkcí a lepšími garancemi správné funkce, není zde však taková možnost uživatelských úprav, kvůli čemuž může být dokonalé začlenění software do FIMS obtížné. Tento software je navíc obvykle zpoplatněn a často používá proprietární souborové formáty pro zobrazování a ukládání dat (Comparison . . . , 2011).

6.3


Použití vozidlového modulu není jediná cesta, jak získat provozní data vozidla evidovaného v informačním systému pro podporu fleet managementu, ač jde často o cesta nejsnazší a nejefektivnější. V některých případech (například z úsporných důvodů či z důvodu snadné portability10 ) nedisponuje vozidlový modul vstupy (popsanými v kapitole 6.1.5) pro čtení provozních parametrů vozidla a aplikace je tedy nucena tato data získat jiným způsobem. Způsobů, jak provozní parametry získat, je několik: 1. dopočítáváním ze získaných polohových dat; 2. převodem jiných dostupných dat systému; 3. ručním zadáním uživatelem — ať už fleet manažerem nebo řidičem. 6.3.1

Sledování provozních parametrů vozidla na základě přímého měření

Je-li ve vozidle přítomen modul vybavený příslušnými rozhraními, může informační systém získávat provozní parametry vozidla přímo, na základě měření. Ve vozidle můžeme měřit širokou sadu parametrů, jejíž rozsah závisí na tom, jakými komunikačními rozhraními a čidly jsou jednotka a vozidlo vybaveny. V informačním systému můžeme pro následné i okamžité analýzy využít například tyto parametry: • rychlost vozidla (následně pro vyhodnocení efektivity dopravy či okamžitě pro informování řidiče o možném dopravním přestupku, máme-li k dispozici geodata popisující profil maximální rychlosti na trase); • zrychlení vozidla — lze měřit přímo akcelerometrem jednotky nebo získávat z datové sběrnice vozidla (následné určení nebezpečného stylu jízdy nebo okamžité varování dispečinku o nenadálé události); • měření teploty — zde můžeme zjišťovat nejen teplotu přímo ve vozidle, ale měřit i teplotu například v nákladovém prostoru, teplotu motoru či teplotu 10

Přenosnost mezi vozidly.

6.3


35

jiných důležitých součástí (kupříkladu oleje u převážně stacionárního stavebního stroje); • detekce otevření dveří či kufru — může sloužit k vyvolání poplachu například u bezpečnostní služby převážející ceniny ve chvíli otevření dveří mimo oblast nakládky nebo vykládky. Též lze využít pro omezení rizika neoprávněné manipulace s nákladem samotným řidičem mimo místa, kde by s ním mělo být manipulováno; • měření spotřeby a hladiny paliva v nádrži — může být sledována spotřeba vozidla a hladina paliva v nádrži a tyto veličiny následně porovnány s účetním stavem nákupu paliva či technickými údaji poskytovanými výrobcem vozidla; • zjišťování neoprávněného pohybu ve vozidle — budeme-li uvažovat i použití bezpečnostních funkcí ve vozidle, může být k jednotce připojen snímač pohybu v kabině vozidla a jeho údaje dále srovnávány například s polohou či předpokládanou pracovní dobou uživatele vozidla; • měření dalších provozních parametrů vozidla — otáčky motoru, emise CO2 . Jistě by bylo možné vymyslet ještě mnoho dalších diskrétních i spojitých vstupů, na které lze reagovat či je evidovat, zvláště pokud uvažujeme vozidla v různých oborech lidské činnosti (a též uvažujeme, že nemusí jít jen o automobily ale třeba i o vlaky či lodě), výše uvedené veličiny jsou základními, které mají ve sledovacím subsystému FIMS největší ekonomický přínos. 6.3.2

Získání provozních parametrů vozidla na základě polohových dat a převodem již dostupných dat v systému

Znalost aktuální polohy, historických poloh vozidla a propojení s dalšími subsystémy IS podniku nám umožňuje značnou část dat, která FIMS potřebuje ke své činnosti, dopočítat bez toho, aby nám tato data musela poskytnout přímo vozidlová jednotka. Níže jsou uvedeny příklady toho, jaká data lze jakým způsobem získat: • výpočet průměrné spotřeby vozidla založený na dokladech z účetního subsystému; • odhad pravděpodobného řidiče vozidla na základě znalosti trasy a míst, na která řidič dojíždí nebo kde má bydliště nebo určení řidiče na základě podnikových pravidel pro přidělování vozidel; • odhad rychlosti vozidla na základě rozdílů mezi zeměpisnými souřadnicemi a znalosti časového razítka souřadnic a následná možnost zjištění pravděpodobného přestupku při znalosti profilu maximální rychlosti na trase.

6.4

Předávání údajů směrem z vozidla do systému a v opačném směru

6.3.3

36

Získání provozních parametrů vozidla na základě ručního zadání uživatelem

Uživatelé vozidla i fleet manažeři mají možnost (v rámci rozsahu svých pravomocí) zasahovat do dat ukládaných systémem a mají možnost tato data i doplňovat. Pokud vozidlový modul nedisponuje prostředky pro přímé získávání dat z vozidla, systém neobsahuje funkcionalitu umožňující transformaci polohových nebo jiných dat na provozní parametry, nebo není převod z jiných dat možný, je nutné, aby byla tato data do systému doplněna ručně. Můžeme například uvažovat situaci, kdy vozidlo nedisponuje zařízením pro identifikaci řidiče. Každý řidič si tak vede svůj deník jízd, kde si poznačí kdy vozidlo přebíral, od koho a komu jej předával. Stejně tak může být tento deník umístěn přímo ve vozidle a jednotlivé osoby používající vozidlo se do něj postupně zapisují spolu s kilometrickým stavem nebo časovým údajem. Stejným způsobem je možné dopočítávat náklady na palivo nebo zjišťovat poměr soukromých a služebních jízd. Tato ruční evidence však ze své podstaty zvyšuje chybovost zadávaných dat, umožňuje ukládání nepřesných (ať už záměrně či nikoli) dat a komplikuje pracovní povinnosti zaměstnancům, kteří mají následně tendenci si práci zjednodušovat (například neeviduje se krátká výměna řidičů kvůli nutnému zápisu do knihy) což může mít za následek nekompletní nebo chybná data v systému. Ruční evidence činností by se dala chápat i jako funkcionalita, která je v rozporu s požadavky na systém uvedenými v kapitole 4.1 „Definice požadavků na systém pro správu vozového parkuÿ, konkrétně požadavkem na snadnou použitelnost.

6.4

Předávání údajů směrem z vozidla do systému a v opačném směru

Některé ze současných komerčně dostupných FIMS disponují funkcionalitou umožňující oboustrannou komunikaci mezi systémem (se kterým pracuje zaměstnanec dispečinku) a uživatelem, řidičem vozidla. Tato funkcionalita přináší nesporné výhody jak pro řidiče, tak dispečery, zvyšuje efektivitu využití a snižuje náklady vozového parku. 6.4.1

Předávání údajů do vozidla

Má-li systém možnost komunikovat směrem do vozidla, záleží na možnostech jeho i vozidlového modulu, jaké množství informací dokáže řidiči předat. Může jít jen o prostou signalizaci o překročení maximální dovolené rychlosti nebo o komplexní komunikační rozhraní na bázi textových zpráv. Řidič tak může například dostávat pokyny o změně cíle jeho cesty, nutnosti naložení dalšího nákladu, informace o neočekávaných událostech na cestě či požadavku na servis u nejbližšího zákazníka. K těmto údajům mohou být přiložena i polohová nebo jiná data (například pro identifikaci zboží či zákazníka), což spolu s vhodným hardwarovým řešením umožňuje přímou navigaci řidiče do cílového místa či jinou automatizovanou službu.

6.5

Analytické funkce nad daty získanými při provozu systému

6.4.2

37

Předávání údajů směrem z vozidla

Řidič často potřebuje komunikovat s centrálou — ať už jde o informaci týkající se nečekané dopravní situace na trase a pozdního příjezdu k zákazníkovi nebo jen průběžně s informacemi o nákladu či stavu zakázek. Směrem z vozidla mohou být předávány například i nouzové pokyny v případě napadení vozidla převážejícího ceniny nebo automaticky v případě nehody vozidla vybaveného potřebnými systémy a propojením na vozidlový modul. I tato část FIMS může být řešena různě složitě v závislosti na požadavcích podniku nebo implementačních možnostech systému. Například FIMS společnosti TomTom umožňuje, s příslušným hardware, oboustrannou komunikaci ve formě textových zpráv a předávání úkolů. Pro komunikaci je využíván již existující datový kanál předávající polohové údaje, využití textové komunikace tedy ekonomicky podnik nezatíží více než prosté použití vozidlového modulu.

6.5

Analytické funkce nad daty získanými při provozu systému

Hovoříme-li o analytických funkcích systému, myslíme tím funkce, které poskytují fleet manažerům a dalším uživatelům agregátní data, grafické reprezentace údajů či trendové informace umožňující odhad budoucího vývoje. Nemusí se jednat jen o analýzy aktuálního stavu (počet vozidel na cestě, průměrná vzdálenost od parkovacího místa), ale i o analýzy dlouhodobého charakteru. Fleet manažer by měl být především osoba, která se stará o ekonomický a efektivní provoz vozového parku, musí tak sledovat nejen to, komu jsou vozidla přidělena, kdy je třeba je poslat do servisu, ale i to, jakým způsobem jsou využívána, zda je tento způsob v souladu s car policy a zda jde o nejefektivnější způsob jejich provozu. Přínosem pro fleet manažera může být skutečnost, že systém poskytuje tyto analýzy: • analýzu průměrné spotřeby paliva s odhadem trendu; • analýzu poměru situací „vozidlo v provozuÿ proti „vozidlo na parkovištiÿ; • analýzu využívání vozidel pro soukromé účely; • analýzu poruchovosti (třeba i v závislosti na řidiči); • analýzu tras, po nichž se vozidlo pohybovalo — nejen pro zjištění, zda je vozidlo využíváno skutečně jen k tomu, k čemu je určeno, ale i pro optimalizaci svozu nebo rozvozu zboží či služeb; • analýzu průběhu celkových nákladů na vlastnictví vozidla (pořízení, palivo, servis a další podnikové služby); • výkazy řidičů za období evidující množství jízd, jejich délku, cíle, výdaje řidičů a podobně; • analýzu stylu jízdy řidičů.

6.6

Automatizované generování hlášení a upozornění řidičům a fleet manažerům

38

Na základě analýz může fleet manažer lépe odhadnout skutečné potřeby zaměstnanců (řidičů), aniž by s nimi musel o jejich potřebách hovořit. Zároveň má k dispozici mnohem silnější nástroj kontroly správné pracovní činnosti, což může posloužit v důsledku jako důkazní materiál ve prospěch podniku při neshodách o práci řidiče, manipulaci se zbožím nebo dodávkami služeb.

6.6

Automatizované generování hlášení a upozornění řidičům a fleet manažerům

Vyspělý FIMS by měl fleet manažerovi i řidičům co nejvíce usnadňovat práci a plnit úkoly, které je možné algoritmizovat, automaticky bez přičinění zaměstnanců podniku. Výhodou může být v tomto případě dostatečné propojení do ostatních modulů informačního systému podniku. Systém by proto měl podporovat možnosti automatického zasílání hlášení a upozornění (reporting) řidičům i fleet manažerům. Příkladem vhodných informačních celků, které by měly být začleneny do reportingu jsou tyto: • hlášení potřeby přestávek řidičům; • hlášení očekávaných dopravních problémů na cestě řidičům (aby se mohli těmto problémům vyhnout) i dispečerům (aby mohli informovat zákazníka o zpoždění na trase); • hlášení o nečekaném pohybu vozidla mimo (obvyklou) pracovní dobu dispečerům; • hlášení poruchy na vozidle dispečerům; • hlášení o nutnosti navštívit servis řidičům; • hlášení o nedodržení doporučeného stylu jízdy řidičům i dispečerům. Tyto celky se týkají obecného podniku, bez uvážení konkrétního obchodního zaměření. Pokud bychom uvažovali konkrétní druh podniku (velkoobchod, stavební firma, rozvážková firma), došli bychom k seznamu o něco delšímu, kde by byly zmíněny další položky, které mohou lépe podpořit fungování daného podniku a jeho schopnost rychle reagovat.

6.7

Propojení FIMS s ostatními částmi IS podniku

Informační systém fleet managementu je možné provozovat jako samostatný celek (častý jev případě systémů nabízených formou SaaS11 ) nebo jej, ať už přímo či nepřímo, napojit na existující nebo budovaný informační systém podniku (ISP). Čím těsnější toto propojení je, tím efektivněji může FIMS pracovat, a tím více může 11

Software as a Service — poskytování software jako služby. Uživatel si, místo pořízení, software jen pronajímá. Obvykle bývá následně software poskytován vzdáleným přístupem.

6.8

Evidence vozidel, jejich vlastností a událostí, plánování pořízení a servisu

39

z FIMS čerpat i podnikový informační systém. Níže je uvedeno několik příkladů toho, jak může propojení omezit nutnost duplicitního zadávání dat nebo jen zajistit automatizaci některých procesů dosud vykonávaných ručně nebo na bázi paušálního hodnocení: • přenos evidenčních dat o vozidlech z ISP do FIMS; • přenos pracovních výkazů zaměstnanců z FIMS do ISP, srovnání služebních a soukromých cest; • vzájemná kontrola nákladů na palivo porovnání ujetých vzdáleností zjištěných sledovacím modulem s hodnotami o spotřebě a hladiny v nádrži dle sledovacího modulu a s hodnotami z dokladů o nákupu paliva z účetního modulu ISP; • přenos zakázek ke zpracování a údajů o zákaznících z ISP do FIMS; • přenos informací o zpracování zakázek z FIMS do ISP; • přenos údajů o servisních intervalech a požadavcích na servis mezi FIMS a ISP (oběma směry); • přidělování zakázek pracovníkům a vozidlům na vhodné trase nebo v nejmenší vzdálenosti k zákazníkovi.

6.8


Má-li podnik efektivně spravovat svůj vozový park, musí jej mít kvalitně zaevidován. Pro základní splnění požadavku na evidenci vozidel stačí prostý seznam vozidel, k němuž obvykle bývají přiřazený konkrétní osoby (řidiči). Tento seznam postačuje pro mnoho z činností, kterými FIMS disponuje, chybí zde však přidaná hodnota, která zvyšuje komfort práce s FIMS a rozšiřuje analytické možnosti systému. Dobrým příkladem komplexní evidence vozidel a jejich vlastností je systém O2 Car Control (Telefónica, 2011), který u každého vozidla v evidenci ukládá následující parametry: • název vozidla, jeho model, barva, typ a SPZ; • oddělení, které vozidlo provozuje a výchozí řidič vozidla; • účel, které vozidlo má; • pořizovací cenu, datum pořízení a vyřazení; • kontakt na zodpovědnou osobu za provoz a osobu zodpovědnou za pořízení; • typ paliva, kapacita nádrže, spotřebu (kombinovanou, ve městě, mimo město na dálnici a mimo dálnici); • počáteční stav tachometru při začlenění do systému, limit počtu ujetých kilometrů pro služební i soukromé jízdy;

6.8


40

• maximální rychlost vozidla; • údaje o vozidlové jednotce; • motohodiny; • údaje o čerpacích kartách vozidla; • fotografie vozidla; • pracovní dobu pro období, denní rozpisy, místa určená k parkování; • definované trasy vozidla; • přehled a plánování servisních úkonů. Evidence dále disponuje modulem ukládajícím historii operací s vozidlem, je tak možné sledovat, jaké jeho charakteristiky se měnily a který uživatel s nimi pracoval. Důležitou položkou seznamu je plánování servisních úkonů. Jak bylo zmíněno v kapitole 3.2.4 „Odhad životního cyklu vozidelÿ, tvoří pořizovací náklady méně než 50 % celkových nákladů na vlastnictví vozidla. Druhá polovina je tvořena náklady na palivo a servisními náklady. Konkrétní rozložení nákladů v amerických dolarech (centech na ujetou míli) ukazuje na příkladu tahače s návěsem Coyle a kol. (2011): • mzdy řidiče — 75,2¢; • palivo a daně — 47,9¢; • pronájem nebo pořízení vozidla — 46,5¢; • další, blíže neurčené náklady — 38,0¢; • odpisy — 13,0¢; • pojištění — 9,2¢; • údržba vozidla — 5,4¢; • daně a licence — 4,7¢; • pneumatiky — 2,7¢; • další mzdové náklady a benefity — 132,14¢. Celková průměrná cena přepravy v roce 2006 byla 3,75 USD na míli jízdy. Dle společnosti Innovative Maintenance Systems je pro sledování servisu vozidel třeba, aby FIMS podporoval vedení kvalitní evidence, nabízel možnost preventivního plánování oprav v závislosti na jednotlivých servisních intervalech (v kilometrech či časových jednotkách), sledování průběhu oprav a nákladů na opravy a evidenci historie servisu a opotřebené vozidel (IMS, 2009).

6.9

6.9

Řízení a správa přidělování vozidel zaměstnancům

41

Řízení a správa přidělování vozidel zaměstnancům

Společnost využívající car policy — tedy společnost, která má nastavena pravidla pro přidělování vozidel, může tato pravidla zavést nejen formou určitého dokumentu, může je však začlenit i do FIMS a část úloh zautomatizovat s možností kontroly dodržování pravidel. Dispečer systému pro podporu fleet managementu má přehled o vozidlech, jejich stavu a aktuálním přidělení zaměstnancům a může tyto skutečnosti snadno porovnat s požadavky nastavenými car policy nebo může některé z těchto činností provádět systém autonomně. FIMS též může poskytovat analýzy provozu a návratnosti investice do vozidel a na základě těchto údajů asistovat manažerovi při rozhodování o pořízení či prodeji vozidel. Stejně tak může být systém nápomocen nejen při aplikaci car policy, ale i při jejím sestavování a úpravách na základě skutečných zjištěných dat v systému.

7

NÁVRH WEBOVÉHO ROZHRANÍ FIMS JAKO KOMPONENTY IS PODNIKU

7

42

Návrh webového rozhraní FIMS jako komponenty IS podniku

Na základě požadavků na informační systém pro správu vozového parku a vlastností, ať už daných obecnými požadavky na takový systém nebo vlastností zamýšlených na základě rozsahu existujících služeb, je sestaven návrh FIMS nového. Zároveň je využito dřívě zjištěných poznatků v problematice aplikace algoritmu hledání nejkratších cest v silniční síti (Grmela, 2009). V případě návrhu webového rozhraní je této funkcionality využito v subsystému mapových a telematických funkcí pro vyhledávání doporučených tras vozidel a v analytickém podsystému pro zpětnou optimalizaci tras.

7.1

Moderní webové informační systémy

Současné trendy navrhování a vývoje webových informačních systémů, vzhledem k očekávané komplexnosti nabízených služeb, je možné popsat následujícími zásadami: • používání pokud možno existujících ověřených komponent; • omezení vlastního vývoje funkcionality; • vyvážené postavení čistě navržené12 architektury a výkonnostních aspektů systému; • snadná použitelnost a jednoduchost ovládání; • rychlost a flexibilita rozhraní; • připravenost na nasazení v různých rolích a na různých zařízeních. Tyto zásady jsou založeny na předpokladu, že je vývoj vlastního kódu dražší a časově náročnější než užití či pořízení kódu již vyvinutého, což ve vysoce konkurenčním prostředí znevýhodňuje vývoj vlastních aplikací. Na tyto dvě zásady se váže i vyvážené postavení návrhu architektury a výkonu systému — často upřednostníme elegantní řešení, které spoří náklady na vývoj a čas i když je jeho výkonnostní přínos systému je ve výsledku nižší. Snadná použitelnost a jednoduchost ovládání jsou jasné trendy současné doby. Uživatelé raději používají systém, který má dobře navržené uživatelské rozhraní a raději se k jeho používání vracejí. A co víc, dobře navržené rozhraní a jednoduché ovládání zvyšují produktivitu a efektivitu systému jako celku a tedy podporují účel, k němuž byl systém vytvořen. S použitelností se pojí i požadavek na rychlost a flexibilitu rozhraní. Rychlé rozhraní se dobře používá. Stejně tak rozhraní flexibilní, nabízející možnost uživatelských úprav, zajišťuje, že uživatelé budou systém 12

Dle teoretických zásad pro výstavbu IS.

7.1

Moderní webové informační systémy

43

používat nikoli tak, jak jim bylo určeno vývojovým týmem, ale tak, jak to vyhovuje jim samým. Připravenost pro nasazení v různých rolích a na různých zařízeních staví na stále se zvětšujícím počtu zařízení, které s informačním systémem potřebují komunikovat. A nemusí to být jen prostřednictvím webového prohlížeče jakožto primárního rozhraní, které je systémem nabízeno. Z toho důvodu musí moderní systém podporovat snadnou změnu uživatelské vrstvy architektury či nabídnout stejnou funkcionalitu zcela jiným způsobem, jiným rozhraním. K těmto všem požadavkům bývá připodobňován architektonický návrh ModelView-Controller, zkráceně MVC. Architektura MVC staví na předpokladu nahraditelnosti každé části informačního systému a důsledné separaci aplikační logiky, datového skladu a prezentační vrstvy (Rockway, 2007): • model plní roli datového skladu. V této roli může vystupovat stejně dobře SŘBD stejně jako prostý textový soubor se seznamem položek; • View plní roli uživatelského rozhraní. Uživatelské rozhraní může mít podobu šablony pro generování webové stránky nebo může jít o libovolný jiný soubor, který je (transformovanou) reprezentací Modelu; • Controller je aplikační logika systému. Controller je řídícím prvkem systému — pracuje z daty z Modelu a poskytuje výsledky View. Stará se o obsluhu celé aplikace a právě Controller bývá jediným prvkem, který není tzv. „výměnnýÿ, tedy jeho změnou bychom dostali, na rozdíl od Modelu a View, jinou aplikaci. Dalším trendem vývoje hypertextu a standardu HTML jsou tzv. Rich Internet Applications (RIA), bohaté internetové aplikace. Tyto aplikace jsou vytvořeny s důrazem na uživatelskou přívětivost a snaží se odpoutat od původního pohledu na webovou aplikaci jako prostou sadu stránek, mezi nimiž uživatel přechází. Místo toho je tyto aplikace tvořeny proměnnými obrazovkami podobnými klasickým stolním aplikacím za podpory HTML5, Javascriptu a technologií jako je Adobe Flash či Sun JavaFX. RIA lze charakterizovat následujícími vlastnostmi (Deb a kol., 2007): • reaktivnost a interaktivita — zpracování je realizováno z velké části na klientu, nikoli na serveru; • bohaté uživatelské rozhraní — RIA se snaží dosáhnout u aplikací kvality uživatelského rozhraní stolních aplikací za použití grafických prvků, zvuku, videa a dalších technologií zobrazování; • široký dosah — záměrem RIA je zpřístupnění aplikací kdykoli a kdekoli; • komunikace v reálném čase — zpřístupnění možností spolupráce a sdílení informací na internetu prostřednictvím instant messagingu, videa na požádání, audio a videokonferencí a podobně.

7.2

Funkcionalita navrženého FIMS

7.2

44


Cílem návrhu funkcionality FIMS není zahrnout do systému všechny funkce, které by jen mohl takový systém obsahovat, aby uspokojil všechny skupiny uživatelů. Cílem je vybrat ty funkce, které skutečně mají pro uživatele reálný přínos a které při správě vozového parku nejvíce využijí (ať už v roli řidiče, dispečera nebo fleet manažera). Po zhodnocení funkcí nabízených existujícími FIMS a obecných požadavků na FIMS byly zvoleny k návrhu tyto funkce: • komplexní evidence vozidel podniku; • telematické a mapové funkce; • analytické funkce; • funkce pro podporu car policy; • podpora evidence zakázek a skladové hospodářství; • správa servisních událostí a sledování nákladů na provoz vozidel. V následujících kapitolách budou představeny návrhy možností implementace pro zajištění splnění výše uvedených požadavků. Každá z výše uvedených funkcí představuje v rámci uživatelského rozhraní aplikace jednu položku hlavní nabídky, která je stále dostupná. Mimo to jsou v hlavní nabídce zobrazeny i některé další, často využívané funkce jako je přehled událostí a funkce pro práci se zaměstnanci v rámci FIMS. Pod položkami hlavní nabídky se skrývají samostatné obrazovky, které budou popsány a graficky nastíněny v dalším textu. 7.2.1

Role zaměstnanců podniku ve FIMS

Do systému pro správu vozového parku podniku přistupují v rámci jeho používání různí osoby v určitých rolích. Třemi základními rolemi uživatelů, které se v rámci FIMS vyskytují a na jejichž základě je definována funkcionalita a přístupová práva, jsou tyto: • vedoucí fleet manažer — vedoucí správy vozového parku, zodpovědný za práci podřízených fleet manažerů — osoba v řídící a kontrolní funkci, definuje práva a povinnosti podřízených fleet manažerů — strategické řízení; • fleet manažer — osoby spravující vozový park, přidělující vozidla řidičům, sledující výkazy a statistiky — taktické řízení; • dispečer — osoba zodpovědná za aktuální provoz vozového parku, jeho optimální funkci a komunikaci s řidiči — operativní řízení; • řidič — zaměstnanec, osoba řídící vozidlo a plnící zadané úkoly v rámci pracovního zařazení.

7.2


45

Mimo osob v těchto čtyřech rolích pracují se systémem pravidelně další dvě osoby — osoba v roli správce systému a osoba v roli účetní. Správce systému zajišťuje správný chod všech jeho funkcí, prověřuje zabezpeční, kontroluje výkon a práci uživatelů se systémem. Jeho úkolem je maximalizovat dostupnost systému a jeho výkon při zachování kvality poskytovaných služeb. Jeho funkce je zejména dozorová, sleduje tedy provoz v systému, zasahuje v případě potřeby a informuje své nadřízené (tedy obvykle technického ředitele podniku). Osoba v roli účetní do systému přistupuje pravidelně jelikož zde existuje možnost využívání vozidel pro soukromé účely, což je třeba ošetřit v účetnictví podniku na základě jízdních výkazů. Ostatní účetní informace (doklady o čerpání paliva, doklady o zaplacení leasingu či úvěru a podobně) může FIMS ověřovat přímo v účetním systému, existuje-li propojení, zde je však třeba z účetního systému nejen číst ale i do něj zapisovat. Podstatu role účetní ve FIMS definuje zákon č. 586/1992 Sb., o daních z příjmů, ve znění pozdějších předpisů, kde § 6, odst. 6 hovoří takto: „Poskytuje-li zaměstnavatel zaměstnanci bezplatně motorové vozidlo k používání pro služební i soukromé účely, považuje se za příjem zaměstnance částka ve výši 1 % vstupní ceny vozidla za každý i započatý kalendářní měsíc poskytnutí vozidlaÿ (Podnikatel.cz, 2008). Účetní musí tedy operuje s cenou účetní cenou vozidla (cenu vozidla vč. DPH nebo vstupní cenu pronajímatele) a následně stanovuje nepěněžní příjem zaměstnance mimo jeho obvyklou mzdu. Do FIMS mohou vstupovat osoby v dalších rolích, ať už zaměstnanci podniku nebo externisté. Tyto osoby obvykle nepracují se systémem pravidelně v rámci svých pracovních povinností, je jim přidělován rozsah dostupných funkcí krátkodobě a nárazově (nemusí tedy např. mít stálý účet v systému). Je třeba mít na paměti, že v rolích fleet manažer a dispečera může vystupovat i více osob současně a je tedy důležitá nejen vertikální (vedoucí manažer–manažer–dispečer–řidič), ale i horizontální (např. manažer–manažer) komunikace v rámci týmu. 7.2.2

Přehled událostí

Osoba pracující s FIMS musí mít v prvé řadě dobrý přehled o událostech, které se staly v posledních několika hodinách či dnech. K získání takového přehledu slouží obrazovka Přehledu událostí13 , na které se zobrazují poslední události od nejnovější. V základní představě zobrazuje Přehled tyto události: • potvrzení úmyslu plnit zadaný úkol řidičem, požadavky na další úkoly nebo připomínky k existujícím • informace o příjezdu vozidla do místa plnění úkolu — tedy provedení nějaké služby či naložení nebo vyložení zboží; • údaje o nových zakázkách podniku, které vyžadují využití přepravy; 13

V literatuře obvykle nazývána „dashboardÿ.

7.2


46

• upozornění o překročení doporučených hodnot vozidla (rychlost, náklad, teplota, . . .); • potvrzení čerpání paliva; • a další údaje o změně stavu vozidel nebo položek ve FIMS.

Obr. 2: Uživatelské rozhraní — Přehled událostí

Tyto údaje jsou vždy opatřeny časovým razítkem. Je uveden původce události spolu s možností otevřít podrobné informace k dané události či s událostí dále pracovat. Návrh uživatelského rozhraní je znázorněn na obrázku 2. 7.2.3

Komplexní evidence vozidel podniku

K evidenci vozidel, jak bylo popsáno v kapitole 5 „Dostupné programové vybavení pro správu vozového parku podnikuÿ, existují u komerčních systémů různé přístupy k tomu, jak podrobně a jakým způsobem evidovat jádro vozového parku, tedy vozidla. Některé systémy se zabývají pouze evidencí vozidlové jednotky a samotné vozidlo v systému v podstatě nefiguruje, jiné umožňují u vozidla uvést mnoho údajů souvisejících s jeho pořízením i provozem.

7.2


47

Bylo rozhodnuto, že evidence vozidel podniku bude disponovat následující funkcionalitou: • zadání a změna výrobních parametrů vozidla; • evidence a nastavení práv řidičů k vozidlům; • určení rozpisů a pracovní doby vozidla; • přiřazení a změna vozidlové telematické jednotky; • přihlášení k používání vozidla; • nastavení účelu používání vozidla; • změna technického stavu vozidla; • sledování stavu vozidla; • hlášení čerpání paliva. Vazby procesů a funkcionality evidence jsou popisuje obrázek 3. Návrh samotného uživatelského prostředí je znázorněn na obrázku 4.

Obr. 3: Diagram vazeb uživatelských rolí a procesů evidence vozidel

Zadání a změna výrobních parametrů vozidla Fleet manažer je osobou, která zařazuje vozidlo do systému. Při zařazení zadává počáteční vlastnosti vozidla jako je název, model, výrobce průměrná spotřeba, kapacita nádrže či pořizovací cena.

7.2


48

Manažer má možnost všechny tyto parametry zobrazovat a nastavovat i v průběhu vlastnictví vozidla podnikem. Existuje možnost ručního zadání finančních parametrů (pořizovací cena nebo měsíční náklady na úvěr, finanční leasing nebo pronájem) nebo čerpání těchto údajů z ekonomického subsystému IS podniku. Evidence a nastavení práv řidičů k vozidlům Vozidlo je používáno na základě příkazu k jízdě, tedy dokumentu který definuje účel a cíl cesty. Řidič může mít vozidlo přiřazené pro volné použití pro splnění pracovních povinností v daném časovém rámci určeném fleet manažerem. Pokud používá stejné vozidlo více osob, je zajištěno, aby se jejich potřeby vzájemně neovlivňovaly a osoba měla vozidlo k dispozici vždy, když má zadánu pracovní činnost, při které vozidlo potřebuje užívat. Nastavení časových plánů užívání vozidla umožňuje dalším osobám mimo řidičů a fleet manažerů sledovat, kdy je vozidlo k dispozici a lze jej tedy například převést do servisu nebo na něm provádět úpravy. Stejně tak tato informace slouží analytickému subsystému FIMS pro sledování neoprávněné manipulace s vozidlem. Systém umožňuje základní evidenci osob pracujících s vozidly a eventuálně import těchto údajů z databáze osobních údajů podnikového IS.

Obr. 4: Uživatelské rozhraní — Evidence vozidel

7.2


49

Přiřazení a změna vozidlové telematické jednotky Aby mohl FIMS fungovat efektivně a bylo nutné provádět co nejméně operací ručně, tedy v rámci pracovních povinností zaměstnanců podniku, musí být všechna vozidla vybavena telematickými jednotkami komunikujícími s informačním systémem. Po instalaci jednotky do vozidla (nebo výměně či úpravě již nainstalované) je třeba provést zařazení jednotky do systému, tedy přiřazení jednotky k vozidlu. Systém musí podporovat přenositelné jednotky, tedy jednotky, které jsou přemisťovány mezi vozidly a nejsou po dobu celého životního cyklu usazeny v konkrétním vozidle. Systém eviduje k jednotce její technické údaje a parametry a umožňuje nastavení parametrů pro spojení a komunikaci s jednotkou. Přihlášení uživatele k používání vozidla a nastavení účelu používání vozidla Uživatel má možnost se přímo (tedy provedením operace ve webovém rozhraní FIMS) nebo nepřímo (za pomoci technického řešení ve vozidle) přihlásit k jeho používání, tedy dát najevo, že hodlá vozidlo řídit. Touto operací je zavedeno jedinečné přiřazení uživatel-vozidlo, čímž nejen že je naplněna položka v seznamu časových rámců vytvářených manažerem, systém však získává i přehled o tom, kdo s vozidlem manipuluje, zda na to má oprávnění a manažerovi dává zpětnou vazbu potvrzující započetí plnění seznamu přidělených úkolů. Uživatel má při přihlášení k používání možnost zvolit, k jakému účelu vozidlo hodlá použít, resp. jaké pracovní povinnosti bude plnit nebo splnil. Po ukončení používání se uživatel odhlásí. Uživatel má možnost účel používání měnit i v průběhu své činnosti. Sledování a změna technického stavu vozidla Při používání vozidla může dojít ke změnám technického stavu a to buď očekávaným nebo neočekávaným. Očekávanými změnami jsou myšleny různé druhy technického zhodnocení — tedy přestavby nebo úpravy vozidla. Neočekávanými jsou myšleny nehody nebo poruchy vozidla. Fleet manažer nastaví po provedení změn nebo vylepšení na vozidle ve FIMS jeho nový stav nebo parametry. Jak fleet manažer, tak dispečer a řidič, může v případě nenadálých události měnit stav vozidla tak, aby odpovídal stavu skutečnému. Jednak je tak zajištěna dostatečná informovanost dalších pracovníků podniku o stavu vozidla a tedy možnost přijetí nutných opatření (například převoz vozidla do servisu), stejně tak je však zajištěno, že nebudou k vozidlu přiřazováni uživatelé po dobu jeho omezené funkčnosti. Navržená funkcionalita FIMS pokrývá potřeby průměrného českého podniku malé až střední velikosti. Hlášení o změně technického stavu mohou být podávána i automatizovaně na základě snímačů, jimiž vozidlo disponuje. Počítač vozidla, který vyhodnotí poruchu na pohonné jednotce tak například předá hlášení přímo do informačního systému bez nutnosti zásahu uživatele, což zrychluje reakční časy a zabraňuje růstu nákladů na servis, který by se mohl projevit při pozdním informování manažera nebo dispečera o této situaci uživatelem. Hlášení čerpání paliva Při provozu vozidla uživatel (řidič) doplňuje palivo vozidla. V souvislosti s touto operací vznikají v systému analýzy pro potřeby fleet manažera

7.2


50

optimalizujícího efektivitu vozového parku. Řidič po každém doplnění paliva eviduje v systému jeho cenu, objem, místo pořízení, způsob úhrady a aktuální stav celkové ujeté vzdálenosti. Palubní telematická jednotka disponující čidlem hladiny palivové nádrže umožňuje FIMS porovnat objem hlášený uživatelem a objem skutečný. Stejně tak je porovnání možno provést na základě znalosti průměrné spotřeby vozidla, ať už definované výrobcem nebo zjištěné při skutečném provozu vozidla. Hlášení uživatele jsou porovnána s údaji z účetního subsystému podniku, kam jsou předány doklady o zaplacení a kde se evidují případné transakce palivovými či platebními kartami nebo úhrady z pokladny. 7.2.4

Telematické a mapové funkce

Systém pro podporu fleet managementu disponující vozidlovými telematickými jednotkami využije subsystém pro správu geografických dat a zobrazení a práci s mapami. Toto umožní uživatelům získat lepší přehled o činnosti zaměstnanců, poloze vozidel podniku a usnadní přidělování úkolů pracovníkům, ať už na základě jejich momentálního vytížení nebo geografické polohy. Vztahy uživatelských rolí a procesů telematického a mapového subsystému zobrazuje obrázek 5, návrh uživatelského rozhraní obrázek 6. Telematický a mapový subsystém disponuje těmito funkcemi: • informacemi o silniční síti České republiky včetně technických parametrů komunikací; • zobrazováním vozidel, odběratelů, dodavatelů a dalších, pro podnik důležitých, bodů na mapovém podkladu; • oboustrannou komunikací mezi dispečerem a řidičem vozidla; • navrhováním a optimalizací tras vozidel; • automatizovanými návrhy přidělení úkolů řidičům; • hromadnými operacemi s vozidly dle geografických nebo evidenčních údajů; • propojením do systému evidence dopravních událostí, vytíženosti komunikací a počasí. Informace o silniční síti České repubiky a jejich technických parametrech V případě nasazení pro sledování vozidla na území České republiky je geografický subsystém založen na hromadně zpracovatelné grafové datové bázi silnic a dálnic nabízené Ředitelstvím silnic a dálnic České republiky a programovém vybavení umožňujícím práci s geodaty — vyhledáváním nejkratších cest a geokódováním zeměpisných souřadnic pomocí algoritmů a postupů navržených v předchozí práci (Grmela, 2009). Použití těchto algoritmů a dat sníží závislost FIMS na vnějších zdrojích dat, umožní rychlejší a automatizované hromadné zpracování dat, což je zvláště důležitým přínosem v systémech evidujících velké množství vozidel.

7.2


51

Obr. 5: Diagram uživatelských rolí a procesů telematického a mapového subsystému

Technické parametry silniční sítě nejsou poskytovateli geografických dat obvykle volně nabízeny koncovým uživatelům neboť tito pro ně nemají využití, pro běžné použití tyto informace nepotřebují. Tyto parametry je velmi nákladné a obtížné zjistit, nejsou tedy součástí geografických databází nebo aplikací pokrývajících oblast jednoho světadílu nebo celého světa. V případě užití databáze ŘSD ČR však tento problém odpadá neboť tato obsahuje nejen grafová data reprezentující silniční síť, ke každému úseku je však evidována i jeho šířka, povrch, počet jízdních pruhů a podobně. To umožní optimalizaci trasy, zvláště potřebnou v případě přepravy jinými než osobními vozidly. Cenou za tyto údaje je však územní omezení pouze na Českou republiku. Využití zakázkově vyvinutého programového vybavení pro vyhledávání nejkratších cest umožní nejen začlenění těchto údajů silniční sítě do uvažované množiny reprezentující trasu, po které se vozidla pohybují nebo mají pohybovat, ale dovoluje ve stavu, kdy má FIMS k dispozici další doplňující údaje pro výpočet (informace o dopravě, počasí a podobně), dále tento optimalizovat pro dosažení nejlepších výsledků pro konkrétní vozový park. Zobrazování vozidel, dodavatelů, odběratelů a dalších subjektů na mapovém podkladu Neméně důležitou složkou geografického subsystému FIMS jsou mapové podklady. Tyto zpřístupňují komplexní zobrazení silniční sítě uživateli (a tedy zajišťují splnění podmínky snadné použitelnosti systému) a ztotožňují její programovou reprezentaci se stavem ve skutečném světě. Uživatelé informačního systému pro

7.2


52

Obr. 6: Uživatelské rozhraní — Zobrazení vozidel na mapě

správu vozového parku tak mají dobrý přehled o tom, kde se aktuálně vozidla nacházejí, jaký je jejich cíl a za jakým účelem jsou na cestě. Stejně tak je pro dispečera zásadní zobrazení dodavatelů a odběratelů (zákazníků), které umožňuje rychle přidělovat úkoly řidičům vozidel. Výhodné je, aby součástí mapových podkladů byly i informace o dalších subjektech, které jsou pro podnik důležité. Může jít o servisní místa vozidel, čerpací stanice, pobočky podniku, bydliště zaměstnanců nebo překladiště zboží. Mapový subsystém podporuje zobrazení všech informací geografického charakteru, které má FIMS k dispozici — pro efektivní provoz vozového parku jsou zobrazovány dopravní informace či údaje o počasí. Oboustranná komunikace mezi dispečerem či manažerem a řidičem vozidla Přidáme-li k základní sledovací funkcionalitě vozidlové jednotky FIMS i možnost oboustranné komunikace — nejen ve smyslu čtení informací z čidel vozidla a zasílání povelu akčním členům ve vozidle, ale i textové či hlasové komunikace mezi řidičem a dispečerem, získáme systém umožňující efektivní plánování úkolů, snadné přiřazování nových cílů či předávání požadavků a připomínek, ať už od řidiče dispečerovi či manažerovi nebo v opačném směru. Koncová, tedy vozidlová, strana

7.2


53

systému má podobu rozšíření vozidlové jednotky o hardware a software podporující komunikaci řidiče s podnikem. Jde tak de facto o vyspělejší podobu navigačního přístroje, který dokáže přijímat a odesílat zprávy. Jejich obsahem může být prostý text, stejně tak jako polohové údaje, položky do seznamu úkolů, grafická data či data pro jiná zařízení, která má řidič k dispozici pro výkon pracovních povinností (tedy například čtečku čárových kódů, kapesní počítač a podobně). Návrh uživatelského rozhraní komunikačního subsystému je znázorněn na obrázku 7.

Obr. 7: Uživatelské rozhraní — Komunikace mezi řidiči a dispečery

Manažer či dispečer může řidiči při zjištění nového požadavku zákazníka zajistit předání nového úkolu řidiči a zároveň předat zákazníkovi informace o vzdálenosti a předpokládaném dojezdovém času řidiče. Stejně tak řidič po přijetí a splnění úkolu může hlásit výsledný stav a odezvu zákazníka, se kterou může fleet manažer dále pracovat a předat ji případě pracovníkům podniku zajišťujícím dodržování kvality nabízených služeb. Stejný postup lze aplikovat nejen v případě osobních služeb poskytovaných pracovníkem zákazníkům, ale i v případě služeb rozvozu či svozu zboží nebo v případě nenadálých událostí na předpokládané trase řidiče, které by mohly způsobit komplikace při plnění pracovních povinností. Stejný komunikační kanál využije analytická část FIMS pro informování řidiče o nedodržení plánované trasy či dojezdového času, nutnosti přestávky při jízdě,

7.2


54

překročení hraničních hodnot doporučeného jízdního stylu či dalších okamžitých událostí. Zařazení oboustranné komunikace do funkcionality konkrétní implementace není povinné — většinu úloh fleet managementu lze plnit i bez tohoto prvku — výhody této součásti jsou však zřejmé. Navrhování a optimalizace tras vozidel Nedílnou části mapového subsystému FIMS je funkcionalita podporující správu a optimalizaci cestovních tras vozidel. Vhodný návrh tras za přispění algoritmů typu vyhledávání nejkratší cesty nebo řešení problému obchodního cestujícího (Kott, 2007), umožňuje podniku ušetřit nejen čas a náklady na dopravu, ale i poskytnout zákazníkům služby s rychlejší reakční dobou. Vyhledávání nejkratší cesty Pokud stojíme před problémem, kterak vozidlo přemístit z výchozího do cílového místa na mapě, existuje v praxi několik přístupů k jeho řešení. V malých podnicích, nejčastěji živnostenském podnikání, jsou místo algoritmizovaného řešení aplikovány postupy intuitivní, empirické — sám řidič rozhodne, na základě svých zkušeností a znalostí, o tom, jakým způsobem se do cíle své cesty dostane. Nověji řidičům asistují mobilní zařízení, která jim mohou v plánování cesty pomoci nebo ji navrhnout zcela automatizovaně, navíc s možností předávání pokynů uživateli (TechnoAssociates, 2008). Autonomní zařízení, která užívá řidič, však nejsou obvykle provázány s FIMS a nemají tedy dostatek informací k tomu, aby mohly získat optimální řešení v rámci celého podniku — nedisponují informacemi o pracovnících, vlastnostech vozidel a jejich poloze, poloze a požadavcích zákazníků a podobně. Z toho důvodu je důležitá možnost výpočtu optimální trasy (tedy nejkratší cesty) přímo systémem a přenos jejího profilu do palubního navigačního systému vozidla nebo dostatečná integrace palubního navigačního systému s FIMS. V případě navrženého FIMS uvažujeme první možnost — tedy výpočet optimální trasy přímo informačním systémem pro podporu fleet managementu. Postup výpočtu z pohledu manažera nebo dispečera FIMS je následující: • volba vozidla, jehož se bude požadavek týkat — často vozidla nejblíže cílového místa; • definice výchozího místa — může být nahrazeno aktuální polohou vozidla; • definice cílového místa; • vyžádání výpočtu trasy. Systém po získání požadavku na výpočet trasy provede vyhodnocení dodatečných podmínek: • výrobní vlastnosti vozidla, které se po trase bude pohybovat (rychlost, hmotnost, rozměry a dopravní omezení);

7.2


55

• provozní vlastnosti vozidla — místo v nákladovém prostoru, pracovní doba řidiče, stav palivové nádrže, . . .; • aktuální dopravní situace v oblasti (pro provedení hrubého odhadu trasy, například jen na základě prosté spojnice vzdušnou čarou); • aktuální počasí v oblasti. Na základě těchto informací a znalosti silniční sítě, reprezentované grafem, může FIMS vypočítat nejkratší cestu mezi uzly grafu a tedy optimální cestu. Dodatečné podmínky jsou využity pro změnu ohodnocení hran grafu (tedy časové náročnosti průjezdu komunikací), změnu grafu (odebrání hran z důvodů hmotnosti vozidla překračující limit nebo nesplňující minimální rychlost) a úprav koeficientů výpočetního algoritmu. Příkladem vhodného algoritmu pro tyto účely je algoritmus Shooting Star implementovaný programovým balíkem Mroute (Grmela, 2009). Tento algoritmus využívá, na rozdíl od standardních grafových algoritmů, údaje o vzájemné geografické poloze uzlů (křižovatek) a dokáže dobře pracovat s grafy obsahujícími souběžné hrany různých ohodnocení (Patrushev, 2007). Systém dále disponuje funkcionalitou pro kontrolu optimality již absolvovaných cest (tedy porovnáním cesty doporučené a navržené) a dále možností změnit již navrženou trasu i v průběhu jejího průjezdu vozidlem na základě nových informací (dopravní omezení, nehoda, změna počasí či požadavku klienta). Problém obchodního cestujícího Organizace, pro které je zásadní rozvoz či svoz zboží či služeb (jedná se tedy o přepravní nebo servisní firmy), využijí častěji, místo prostého hledání nejkratší cesty z výchozího do cílového bodu, algoritmus, který najde nejkratší cestu mezi více body na trase. Jde tedy o body, které musí pracovník podniku navštívit bez předem určeného pořadí jen s požadavkem na optimální časovou náročnost nebo minimální vzdálenost (záleží na prioritách podniku a konkrétním nastavení výpočtu). Problém obchodního cestujícího je možno řešit stejným programovým balíkem, který je využit při realizaci Mroute — totiž knihovny pgRouting. Tato knihovna, pracující v prostředí SŘBD PostgreSQL, implementuje algoritmus pro řešení TSP14 založený na genetickém algoritmu. (pgRouting Community, 2011) Častějším případem, než je čistý problém obchodního cestujícího, však může být potřeba řešit variantu tohoto problému nazývanou Dial-a-ride, zkráceně DARP. Problém lze charakterizovat takto: • převoz zboží z výchozího do cílového místa; • vozidlem lze převážet více kusů zboží najednou; 14

TSP — travelling salesman problem.

7.2


56

• je učeno, kdy má být zboží z výchozího místa vyzvednuto a kdy má být v cílovém místě; • čas vyzvednutí a doručení není specifikován přesně nýbrž intervalem; • čas vyzvednutí nebo doručení nemusí být znám a určuje jej dispečer; • každé zboží lze převážet jen po určitou maximální dobu; • vozidlo má určenou maximální kapacitu; • vozidla začínají a končí svoji cestu na určených místech. Cílem je nalézt cestu s minimálními náklady při dodržení výše uvedených omezení. K řešení DARP se používá metoda větvení a mezí (Røpke, 2005). Implementace funkcionality FIMS umožňující řešit nejen prostý TSP, ale i DARP (opět prostřednictvím knihovny pgRouting) přináší rozšířené možnosti pro optimalizaci převozních tras zejména pro podniky typu přepravní služba. Automatizované návrhy přidělení úkolů řidičům Podniky, ve kterých je FIMS využíván k přidělování pracovních úkolů řidičům, musí čelit omezení tvořeném lidským faktorem — tedy dispečerem, který sleduje vozidla, jejich stav, požadavky řidičů a požadavky ostatních oddělení podniku. Bylo by jistě možné navyšovat množství dispečerů tak, aby dokázali zpracovat větší množství informací a požadavků, podobně jako se to děje v aplikacích, kde je člověk zatím nenahraditelný jakými jsou například dispečeři letového provozu. (Getline, 2005) V méně rizikových aplikacích si můžeme dovolit ponechat FIMS větší autonomii a algoritmizovat úkony, které by jinak museli plnit lidé. Automatizované návrhy přidělení úkolů řidičům reprezentují fukcionality systému, která získává informace z oddělení komunikace se zákazníky a odbytu a ze systému skladového hospodářství. Na základě těchto údajů může systém dispečerovi navrhnout určité přepravní požadavky automatizovaně jen s tím, že je dispečer schválí jako odůvodněné, aniž by sám musel tyto návrhy vytvářet. Hromadné operace s vozidly dle geografických nebo evidenčních údajů Systém podporuje možnosti hromadného výběru vozidel a operace s nimi. Výběr může být založen nejen na prosté volbě v seznamu vozidel nebo zvolení vozidla na mapovém podkladu, ale i na základě společných vlastností vozidel, a to jak výrobních a provozních parametrů (model, hmotnost, množství paliva v nádrži, . . .), tak na základě jejich geografických vztahů jakými jsou poloha, pozice v rámci navržené trasy, vzdálenost od výchozího či cílového místa, pozice vůči ostatním vozidlům nebo vzdálenost od dalších bodů zájmu15 . 15

Místa důležitá z hlediska uživatele systému, označovaná taktéž „POIÿ — Points Of Interest.

7.2


57

Propojení do systému evidence dopravních událostí, vytíženosti komunikací a počasí Systém by mnoho ze své funkcionality nemohl vykonávat efektivně, pokud by neměl k dispozici dynamické informace o silniční síti. Je tedy třeba zajistit propojení s veřenými i soukromými zdroji dopravních dat — v případě České republiky jde zejména o organizaci Ústřední Automotoklub ČR, shromažďující ověřené dopravní informace (ÚAMK, 2011) a dále soukromé služby (poskytující i informace o vytíženosti komunikací), do nichž jsou informace zasílány samotnými řidiči. Informace o počasí poskytuje v České republice státní organizace Český hydrometeorologický ústav (ČHMÚ, 2011) stejně jako mnoho dalších soukromých subjektů. 7.2.5

Analytické funkce FIMS

Kniha jízd Mimo okamžitých informací poskytuje FIMS i nástroje pro zpětnou analýzu uložených dat. Z hlediska zákonných nařízení je zřejmě nejpodstatnější službou automatizované generování knihy jízd. Náhled na rozhraní analytické části FIMS poskytuje obrázek 8. Povinnost vést knihu jízd není sice v zákonných normách České republiky explicitně zmíněna, plyne však z § 31 odst. 9 zákona ČNR č. 337/1992 Sb., o správě daní a poplatků, ve znění pozdějších předpisů: „Daňový subjekt prokazuje všechny skutečnosti, které je povinen uvádět v přiznání, hlášení, vyúčtování nebo k jejichž průkazu byl správcem daně v průběhu daňového řízení vyzvánÿ a dále z pokynu Ministerstva financí ČR č. D-190 k jednotnému postupu při uplatňování některých ustanovení zákona č. 586/1992 Sb., ve znění pozdějších předpisů, který uvádí „Pro účely daňových výdajů na pohonné hmoty, pokud správce daně nestanoví jinak, vede poplatník evidenci jízd tak, aby takto vynaložené výdaje (náklady) mohl prokázat (§ 24 odst. 1 zákona). V evidenci jízd jsou uváděny minimálně tyto údaje: datum jízdy, cíl jízdy, účel jízdy, ujeté km. Dále poplatník vede údaje o typu vozidla, státní poznávací značce, stavu ujetých km k 1. lednu (případně k datu zahájení činnosti) a k 31. prosinci kalendářního roku (případně k datu ukončení činnosti)ÿ (Poradce, 2011). Zákonné normy sice byly v roce upraveny novelou zákona č. 304/2009 Sb., které ustanovila možnost paušalizovat náklady na provoz vozidla místo povinnosti prokazovat skutečné výdaje pro účely výpočtu daně z příjmů, do této změny však nespadá nárok na odpočet daně z přidané hodnoty. Plátce DPH má právo uplatnit odpočet DPH na plnění, jehož přijetí potvrdí daňovým dokladem. Pro účely odpočtu DPH z nákladů na provoz vozidla tedy i nadále pro podniky — plátce DPH — platí de facto povinnost vést knihu jízd i kdyby uplatňovaly odpočet daně z příjmů paušálem. (BusinessInfo.cz, 2011) Systém tak dle výše uvedeného generuje na základě uložených dat dokument splňující požadavky Ministerstva financí, čímž umožní prokázat, že bylo vozidlo skutečně využíváno k podnikatelské činnosti. Další analytické funkce FIMS poskytuje svým uživatelům analytické funkce, které umožňují získat lepší přehled o činnosti vozového parku podniku, efektivitě jeho

7.2


58

Obr. 8: Uživatelské rozhraní — Analytické funkce

fungování, ale i o vztazích mezi vozovým parkem a požadavky dalších oddělení podniku. Analýzami, které FIMS nabízí jsou tyto: • analýza spotřeby paliva vozidel; • analýza využívání vozidel pro služební účely; • analýza chování řidičů při využívání vozidel; • výkazy pohybu vozidel za časové období; • kontrolní mechanismus pro porovnávání účetně evidovaných nákladů na palivo proti údajům o spotřebě a hladině paliva v nádrži vozidla; • analýza anomálií v chování řidičů a vozidel (neočekávaný přejezd za hranice, pohyb bez zapnutého motoru, náhlá změna množství paliva v nádrži, . . .); • analýza četnosti a intenzity využívání jednotlivých vozidel; • analýza přepravovaného nákladu či poskytovaných služeb podle vozidla nebo řidiče;

7.2


59

• analýza docházky („dojížďkyÿ) řidičů do firmy; • analýza plnění jízdních přestávek. Systém pracuje na základě analýzy časových řad, z nichž jsou algoritmickou cestou vyvozovány závěry a ty následně prezentovány fleet manažerovi prostřednictvím grafů, tabulek či textových doporučení. Údaje mohou být ze systému exportovány nebo předány uživatelům vozidel (například jako součást žádosti o vysvětlení). Funkce pro podporu car policy Mnoho z bodů, které definuje dokument nazývaný car policy, je možné kontrolovat a vynucovat automatizovaně. Další body je možné v systému jen zobrazovat — osoby se s nimi mohou snáze seznámit a zachovat se dle předpisů, nařízení a doporučení, která jsou popisována. Systém umožňuje manipulaci s car policy (tedy změnu dokumentů) na základě odsouhlasení zainteresovaných osob spolu s archivací historie změn pro následnou kontrolu. 7.2.6

Přidělování vozidel zaměstnancům

V systému fleet manažer definuje práva jednotlivých zaměstnanců k vozidlům v majetku firmy. Na základě této informace může FIMS nejen ověřovat, zda a jak zaměstnanci využívají vozidla, která jim byla přidělena, ale i omezit jejich používání, disponuje-li vozidlová jednotka možnostmi pro odepření přístupu nebo nastartování vozidla na základě identifikace řidiče. Využívání vozidel pro soukromé účely Vozidlo disponuje možností nejen identifikovat řidiče, ale zároveň evidovat i účel, k němuž má být nebo je používáno. Na základě pravidel definovaných v systému je řidiči povoleno vozidlo využívat pro soukromé účely s tím, že je jeho pohyb evidován stejně jako v případě služebního využití, jen je dispečer a fleet manažer informován o tom, že nejde o služební jízdu a není tedy například možné zaměstnanci přidělovat úkoly nebo požadovat plnění jiných pracovních povinností, alespoň pokud tak nebylo dříve dohodnuto nebo nebyla k dohodě využita obousměrná komunikace vozidlové jednotky. Vymezení zodpovědnosti za vozidlo Stejně jako má FIMS možnost sledovat, kdo vozidlem momentálně disponuje, kdo jej používá, tak zde existuje funkcionalita pro sledování zodpovědnosti za vozidlo. V každém okamžiku je známo, která osoba zodpovídá za stav vozidla spolu s informací, jaký tento stav je a jaká je historie změn. Stav je možné změnit. Nastavení systému školení a kontroly způsobilosti řidičů Ve FIMS je provedena evidence školení řidičů a jejich způsobilosti. Na základě těchto informací je fleet manažer informován o nutnosti dalšího proškolení zaměstnanců když se blíží termín konce platnosti aktuálního školení řidiče. Stejně tak je evidována způsobilost řidičů

7.2


60

a to ať už co do časového nebo rozsahového charakteru jejich způsobilosti (řidičského oprávnění). Další nařízení a doporučení car policy Položky dokumentu car policy jako jsou pravidla pro pořízení a obměnu vozového parku a prodej vozidel jsou stanovena pro fleet manažera nebo další osoby, které mají pravomoci disponovat majetkem podniku, subsystém správy car policy jen zobrazuje. Tato pravidla mohou být však volitelně propojena s informacemi o vozovém parku, které má FIMS v evidenci. Subsystém car policy tak například může upozorňovat na stáří vozidel či umožňovat vzájemné srovnání vozidel v majetku podniku. Podobně jsou evidovány postup v případě dopravní nehody. Dopravní nehodu může řidič hlásit prostřednictvím vozidlové jednotky, je-li po nehodě funkční, s tím, že jsou o této události neprodleně informovány odpovědné osoby podniku, které řidiči asistují při řešení následků nehody. Pravidla provádění servisu vozidel jsou sice nastavena v rámci car policy, jejich aplikace je však řízena subsystémem Správy servisních událostí. 7.2.7

Podpora evidence zakázek a skladové hospodářství

FIMS disponuje propojením do skladového subsystému IS podniku a evidence zakázek. Fleet manažer a dispečer tak mohou provádět své pracovní povinnosti v rámci FIMS, aniž by museli přecházet do jiných subsystémů IS podniku. Navržené uživatelské rozhraní Evidence zakázek popisuje obrázek 9. Zakázky, které mají být zpracovány pracovníky podniku pohybujícími se vozidly, jsou tak přímo předávány těmto pracovníkům, včetně všech potřebných podrobností, obousměrným komunikačním rozhraním mezi vozidlem a dispečinkem. Fleet manažer a dispečer má tyto možnosti práce s evidencí zakázek a skladovým hospodářstvím: • zobrazování aktuálních zakázek se vztahem k vozovému parku (nutnost přepravy zboží nebo osob); • přiřazování pracovníků k zakázkám; • zobrazování stavu plnění zakázek a informací k jejich plnění; • zobrazení požadavků ze skladového subsystému IS podniku; • přiřazení pracovníků k interním zakázkám podniku v rámci manipulace se skladovými zásobami; • práce s požadavky zákazníků a komunikace s nimi při plnění úkolů. 7.2.8

Správa servisních událostí a sledování nákladů na provoz vozidel

Správa servisních událostí je nedělitelnou součástí fleet managemetu jelikož právě náklady servis se spolu s náklady na provoz vozidel nejvíce podílejí na finanční zátěži

7.2


61

Obr. 9: Uživatelské rozhraní — Evidence zakázek

podniku tvořené vlastnictvím vozidla (i při zvážení samotného pořízení, úvěru, finančního leasingu či pronájmu). Dobře nastavené kontrolní mechanismy FIMS nejen že umožňují fleet manažerovi získat dobrý přehled o tom, kdy jak a s jakými náklady se vozidla servisují, ale nabízejí mu i možnost tyto náklady snížit konsolidací servisních služeb pod jednoho poskytovatele, který následně dokáže nabídnout výhodnější cenu (objemové slevy). Subsystém servisních událostí a sledování nákladů musí poskytovat následující funkce: • získání přehledu o servisních intervalech vozidel; • zobrazení průběhu nákladů na servis a provoz vozidel; • možnost manipulace se servisními intervaly, určování podnikových intervalů kontrol a oprav vozidel; • zobrazení hlášení zaměstnanců o poruchách a nehodách vozidel; • zobrazení a úprava kapitoly servisu dokumentu car policy — nastavení pravidel pro servis vozidel; • evidence záručních podmínek a garančních prohlídek vozidel;

7.2


62

• analýza anomálií poruchovosti vozidel. Sledování nákladů na provoz vozidel se netýká jen nákladů na palivo, ale i dalších přímých i nepřímých nákladů, které v souvislosti s provozem vozidla vznikají. Jde zejména o mzdové náklady řidičů, fleet manažerů a dalších zaměstnanců podniku, kteří mají co do činění s pořízením vozidla a jeho účetní správou v podniku.

8

PŘÍNOSY NAVRŽENÉ KOMPONENTY A SROVNÁNÍ S EXISTUJÍCÍMI ŘEŠENÍMI

8

63

Přínosy navržené komponenty a srovnání s existujícími řešeními

8.1

Náklady na realizaci a provoz systému

Návrh webové komponety informačního systému byl představen panu Martinu Kluskovi, vedoucímu vývoje webových aplikací ve společnosti iMakers, s.r.o. pro zhodnocení implementačních nákladů navrženého řešení. Společnost iMakers, s.r.o. se zabývá vývojem webových a mobilních aplikací a má zkušenosti s projekty obdobného rozsahu. Cenové ohodnocení jednotlivých součástí v Kč bez DPH lze shrnout následujícím seznamem: • komplexní evidence vozidel podniku — 20 tis. Kč; • telematické a mapové funkce — 25 tis. Kč; • analytické funkce — 15 tis. Kč; • funkce pro podporu car policy — 10 tis. Kč; • podpora evidence zakázek a skladové hospodářství — 20 tis. Kč; • správa servisních událostí a sledování nákladů na provoz vozidel — 15 tis. Kč. Celkem tedy předpokládané náklady na vývoj webové komponenty systému byly odhadnuty na 105 tisíc Kč, bude-li vše vyvíjeno na míru konkrétnímu informačnímu systému podniku. V případě použití hotových řešení lze náklady na vývoj některých součástí snížit — například při použití typového software dodaného s telematickou jednotkou klesne cena telematického subsystému o cca 10 tis. Kč, podobně může být cena snížena, nebudeme-li požadovat obousměrnou komunikaci s řidiči a tedy přidělování úkolů prostřednictvím FIMS. Náklady na pořízení telematických jednotek se pohybují dle hrubého průzkumu 16 trhu na cca 2 tisících Kč za kus základního modelu bez vozidlového rozhraní pro čtení vstupů a přibližně 4 tisících Kč za modely disponující vozidlovými vstupy. Modely disponující obousměrnou komunikací nejsou volně v prodeji, jde o zákaznická řešení dodavatelů FIMS. Budeme-li však uvažovat například použití tabletu s rozšiřujícím rozhraním pro sledování parametrů vozidla a komunikačním modulem mobilní sítě, je možné cenu odhadnout přibližně na 15 tisíc Kč za kus. Vozidlové jednotky v podobě tabletu disponují širším rozsahem funkcí (např. možnost přenosu multimediálního obsahu nebo používání webového IS přímo z vozidla) než komerčně nabízené navigační jednotky, mohou mít tedy pro řidiče přínos v rámci fleet managementu i v dalších úkolech souvisejících s výkonem zaměstnání. Mimo nákladů na pořízení webové komponenty a telematických jednotek je třeba hodnotit i náklady na provoz systému. Uvažujme použití FIMS na území 16

Položení dotazu „trackerÿ do webovému vyhledávači a následné porovnání nabízených cen v elektronických obchodech.

8.2

Ověření zjištěných závěrů v praxi

64

České republiky a využití datové komunikace sítěmi mobilních operátorů. Jediné další náklady, které mimo přenosů dat vznikají, jsou náklady na provoz webového serveru poskytujícího IS podniku — budeme-li uvažovat výrazné zvýšení zátěže a tedy nutnost použití dedikovaného webového serveru, pohybujeme se dle pana Klusky v nákladech přibližně 300 Kč měsíčně při použití virtualizace.17 Dle zjištění z webových stránek českých operátorů činí měsíční náklady na „neomezenýÿ18 datový tarif pro přenos dat přibližně 500 Kč měsíčně, konkrétní měšíční ceny shrnuje následující seznam: • Telefónica O2 — 500 Kč vč. DPH (2 GiB omezení); • T-Mobile — 499 Kč vč. DPH (3 GiB omezení); • Vodafone — 525 Kč vč. DPH (3 GiB omezení). Vhodnou optimalizací časových intervalů komunikace a objemu přenášených dat bychom však mohli dosáhnout i na nižší tarify, které mají datové přenosy omezeny například na 500 až 600 MiB za cenu přibližně poloviční než v případě neomezených tarifů. Pořizovací náklady v úrhnu při využití všech navržených funkcí webové komponeny IS jsou tvořeny těmito položkami: • pořízení systému — 105 tisíc Kč; • pořízení vozidlových jednotech — 15 tisíc Kč za každé vozidlo. Dále, měsíční náklady na provoz tvoří tyto položky: • provoz serveru FIMS — 300 Kč; • provoz vozidlových jednotek — 500 Kč za každé vozidlo. Celková výše nákladů je tedy, v případě podniku s 10 vozidly 255 tisíc Kč pořízení a dále měsíčně 6300 Kč za provoz.

8.2


Uvedené návrhy funkcionality systému pro podporu fleet managementu byly prezentovány Bc. Richardu Hartmannovi, manažerovi brněnského podniku obchodujícího s druhotnými surovinami PlusMinus Production, s.r.o. Na základě vzájemné dohody byla vytvořena minimální implementace subsystému sledování vozidel dle technických údajů komunikačního protokolu vozidlové telematické jednotky CVPL-G204 zjištěných Strašákem (2011). Společnost PlusMinus Production, s.r.o. disponuje následujícími vozdily: • 3 nákladní vozidla MAN s návěsem o kapacitě 10 t nákladu; 17 18

Nikoli tedy skutečného (hardwarového), nýbrž virtuálního serveru. Stále je uplatňována regulace nadměrného stahování dat.

8.2


65

• 2 osobní vozidla značek Opel a BMW. Podnik aktuálně zaměstnává 12 osob, z toho 4 osoby na řídících pozicích, 5 pracovníků zpracování papíru a 3 řidiče nákladních vozidel. Dvě osoby se podílejí na samotném řízení firmy, jedna osoba je zodpovědná za výrobu a poslední osoba v řídící funkci se zabývá obchodní činností v rámci regionu Čechy. Společnost využívá na míru vyvinutý webový informační systém pro fakturaci, řízení vztahů se zákazníky a skladové hospodářství. Systém disponuje specializovanou funkcionalitou pro řízení procesu zpracování druhotných surovin. Nákladní vozidla jsou využívána pro převoz sběrného papíru do střediska společnosti, kde je tento tříděn a lisován do určených rozměrů. Následně probíhá jeho přeprava na odběrná místa společností vykupujících papír za účelem recyklace. Osobní vozidla společnost využívá pro služební cesty obchodníků a vedoucích provozu ke klientům (tedy podnikům vyžadujícím odvoz odpadního papíru). Sledovací systém v podobě vozidlových jednotek byl na pokyn manažera společnosti umístěn ve vozidlech a uveden do provozu v druhé polovině roku 2011. Po dvoutýdenním záběhu a nastavení probíhal měsíční zkušební provoz. Po dobu zkušebního provozu byly evidovány zejména údaje o poloze a rychlosti vozidel. Manažer zodpovědný za uvedení systému do provozu, provedl na konci zkušebního období, koncem roku 2011 shrnutí dosažených výsledků, rozdílů oproti předchozímu období, po které nebyly v podniku nasazeny žádné prostředky fleet managementu. Tyto je možné vyjádřit níže uvedenými body: • lepší informovanost zákazníků díky znalosti polohy kamionů přepravujících papír; • vyšší kontrola obchodníků uživajících podniková vozidla, snížení počtu neohlášených soukromých užití vozidla v pracovní době; • získání přehledu o trasách kamionů a následná možnost optimalizace v součinnosti s řidiči; • přehled nad chováním obchodníků co se týče dodržování maximální dovolené rychlosti; • zjištění nedodržování povinných přestávek řidičů kamionů; • příležitost pevně stanovit pravidla pro řidiče podniku co se týče užívání vozidel. Na základě zjištěných údajů o pohybu vozidel odhadl manažer podniku v rámci variabilních nákladů možné úspory paliva v rozmezí 10 až 20 % měsíčně spolu se zkrácením přepravních časů pro vyřízení denních zastávek řidičů kamionů ze současných 8,7 hodin na přibližně 7,6 hodin a tedy následné zvýšení kapacity podniku při současném technickém vybavení o 15 %. Co se týče fixních nákladů, byl manažerem zmíněn jasný přínos definicí pravidel car policy, která mohou v budoucnu fixní náklady podniku snížit volbou vhodného způsobu financován vozidel. Manažer zvažuje nasazení komplexnějšího systému zahrnujícím většinu touto prací navrhované funk-

8.3

66

Srovnání s komerčními systémy

Tab. 1: Srovnání navrženého FIMS se současnými komerčními systémy Název funkcionality

TT

CN

O2

VF

WD FW

Cena instalace (tis. Kč) Měsíční cena provozu (tis. Kč) Sledování vozidel Autom. tvorba knihy jízd Obousměrná kom. s řidičem Čtení vozidlových vstupů Plánování tras a rozvozů Mobilní aplikace Integrace s podnikovými IS Analýza chování řidičů Podrobná evidence vozidel Sledování výdajů na palivo Bezkontaktní ident. řidičů Zabezp. vozidel proti krádeži

250 5 4 4 4 4 4 4 4 4 4 4 4 6

116 6,7 4 4 6 4 6 6 6 6 4 4* 4 4

165 5 4 4 6 6 6 6 6 4 4 4* 4 6

60 2 4 4 6 4 6 6 6 6 6 4 6 6

168 7,1 4 4 4 4 4 4 6 6 6 4 4 4

200 6,2 4 4 4 4 6 6 4 6 6 4 4 4

Navržený systém 255 6,2 4 4 4 4 4 6 4* 4 4 4 4* 6

TT — TomTom Work, CN — Carnet sledování vozidel, O2 — O2 Car Control, VF — Vodafone Sledování vozidel, WD — HI Software Webdispečink, FW — Radium Fleetware. Hvězdička u symbolu značí omezení dané funkcionality nebo dodatečné podmínky pro její dostupnost. Cena instalace a provozu je kalkulována pro 10 vozidel v Kč bez DPH včetně obousměrné komunikace řidič-dispečink (pokud je podporována). Údaje o ceně získány z webových stránek a od obchodníků poskytovatelů.

cionality a jeho začlenění do současného webového informačního systému podniku pro správu skladu, udržování styků se zákazníky a fakturaci. Na základě pozitivních výsledků z testovacího provozu byla vytvořena reálná možnost ověření a implementace navržených řešení.

8.3

Srovnání s komerčními systémy

Pokud uvažujeme reálně existující funkcionalitu komerčních systémů zhodnocených v kapitole 5 „Dostupné programové vybavení pro správu vozového parku podnikuÿ a navrženou funkcionalitu jako údaj o tom, zda systém disponuje či nedisponuje danou funkcionalitou, je možné provést tabulkové porovnání existujících systémů s navrženým FIMS. Toto srovnání přináší tabulka 1. Systémy s největším funkčním rozsahem jsou TomTom Work, HI Software Webdispečink a Radium Fleetware. Tyto systémy plně vyhovují požadavkům na komplexní pokrytí potřeb fleet managementu podniku. Ve srovnání s těmito systémy

8.4

Kalkulace návratnosti

67

disponuje navržený systém o něco užším spektrem funkcí, kde jsou omezení, mimo jiné, daná příkladem kalkulace tabletu s komunikačním rozhraním, který nedisponuje všemi funkcemi komerčně dostupných jednotek (například bezkontaktní identifikací řidiče). Na druhou stranu řešení vozidlové jednotky pomocí tabletu přináší podniku výhody další rozšiřitelnosti a širších možností spolupráce pro řidiče – například podporu složitého multimediálního obsahu nebo možnost vzdáleného přístupu do IS podniku, což je funkcionalita, jakou jednoúčelové komunikační vozidlové jednotky komerčně dostupných systémů nenabízejí. Co se týče nákladů na instalaci, je navržený systém sice nejdražší ze všech hodnocených, což je dané zejména nutností vlastního vývoje celého software, existuje zde však prostor pro úspory při využití typizovaných komponent namísto kompletního vývoje na zakázu. Dále je třeba brát v úvahu skutečnost, že ne všechny komerčně nabízené systémy disponují možnostmi napojení na podnikový informační systém, a pokud ano, tak v ceně nejsou zahrnuty poplatky za instalaci propojení a převod dat. Navržený systém je odpočátku přizpůsoben na míru současnému podnikovému IS a tudíž bude jeho integrace těsnější než v případě ostatních dostupných řešení. Cena měsíčního provozu je srovnatelná s komerčně dostupnými řešeními a stejně jako v případě pořizovací ceny, i zde lze náklady snížit — buď použitím nižšího tarifu, pokud bude systém navržen pro přenos dostatečně malého objemu dat z telematických jednotek, nebo formou rámcové smlouvy s operátorem, která by se v případě 10 vozidel již jistě byla pro operátora zajímavá a ten by podniku mohl poskytnout výhodnější cenové podmínky. Zcela je z návrhu vynechán vzdálený dozor a ochrana proti krádeži, neboť tato problematika spadá do oblasti fleet managementu jen okrajově. Integrace s podnikovými IS je též do jisté míry volitelná funkcionalita jelikož je návrh koncipován s úvahou, že je FIMS projektován přímo pro konkrétní informační systém a jeho přenositelnost do jiného systému není zvláště požadována.

8.4


Použijeme-li údaje získané v kapitole 8.1 a zároveň využijeme informace od manažera podniku obchodujícího s papírem, jsme schopni sestavit přibližný odhad doby návratnosti pro konkrétní podnik. Od pana Hartmanna byly získány tyto informace o provozu vozidel podniku: • Každé nákladní vozidlo podniku ujede za měsíc přibližně 2500 km; • každé osobní vozidlo ujede za měsíc přibližně 4000 km; • náklady na 1 km činí u nákladního vozidla 29 kč/km; • náklady na 1 km činí u osobního vozidla 4 kč/km. Pro určení konkrétního snížení nákladů firmy se třemi nákladními a dvěma osobními vozidly vlivem zavedení FIMS by bylo možné využít odhadu manažera

8.4


68

týkajícího se zrychlení obsluhy denních tras nákladních vozidel, tento údaj by však nepostihl použití osobních vozidel. Pro účely výpočtu se tedy budeme se držet údajů uvedených v literatuře, spodní hranice úspor ve výši 10 % (Finance.cz, 2011). Náklady na pořízení systému pro 5 vozidel činí 180 tisíc Kč, měsíční náklady na provoz 2800 Kč.

Obr. 10: Graf vývoje nákladů na provoz FIMS (čárkovanou čarou) a úspor plynoucích z FIMS (plnou čarou)

Z obrázku 10, grafu popisujícího odhadované kumulativní náklady na provoz systému pro správu vozového parku a přínosy (ve výši kumulativních úspor nákladů na provoz vozidel), je patrné, že návratnost navrženého řešení činí přibližně 9 měsíců od uvedení do provozu. Za tuto dobu se náklady na pořízení a provoz vyrovnají s přínosy (FIMS se tedy podniku zaplatí) a dále bude systém podniku přinášet už jen další úspory.

9

9

ZÁVĚR

69

Závěr

Na základě studia dostupných materiálu týkajících se správy vozového parku, vzdáleného sledování vozidel a architektonických rysů informačních systému byl vytvořen návrh funkcionality nového systému. Byl proveden průzkum trhu, následné testování a zhodnocení komerčně nabízeného software. Výsledkem hodnocení poznatek, že software nabízený na českém trhu se značně liší ať už co do funkčnosti i uživatelského rozhraní. Jistou zajímavostí je i fakt, že ne všechny zkoumané komerční systémy disponují komplexní evidencí vozidel podniku. Evidence vozidel plní roli roli základního stavebního kamene fleet managementu podniku. Místo toho se zde projevil jistý posun v chápání FIMS českými dodavateli spíše jako systému pro sledování vozidel než jako systému v prvé řadě vozidla evidujícího a zabývajícího se pravidly car policy. Poznatky zjištěné při studiu existujícího software spolu s informacemi z dalších zdrojů hovořících o technických i provozně-ekonomických aspektech fleet managementu sloužily k vytvoření představy o systému, který by splňoval svou funkcionalitou požadavky malého až středního českého podniku. V návrhu byly využity dřívější poznatky týkající se využití algoritmu pro hledání nejkratších cest v geografických datech silniční sítě — konkrétně v mapovém subsystému pro návrh doporučených tras vozidel a dále v subsystému analytickém pro zpětnou analýzu optimality cest již absolvovaných. Byly nastíněny možnosti rozšíření současného návrhu v souvislosti s charakterem podnikatelské činnosti, oboru, jímž se podnik zabývá. Navržený systém byl dále srovnán s existujícími řešeními. Díky dohodě s podnikem obchodujícím s druhotnými surovinami byla experimentálně ověřena některá tvrzení o přínosech zavedení systému pro správu a řízení vozového parku do podniku s výhledem na možnost skutečné realizace prací navržené funkcionality a služeb. Navržená webová komponenta informačního systému podniku v cenovém srovnání vychází v pořizovacích nákladech sice jako nejdražší avšak s těsnější integrací s informačním systémem. Jelikož jde o software vyvinutý na zakázku, je vyšší cena odůvodněná možností přizpůsobit jej přesně potřebám zákazníka a též použitím vozidlových jednotek v podobě tabletů, které disponují další, dodatečnou funkcionalitou jako je podpora složitého multimediálního obsahu nebo možnost vzdáleného přístupu do IS podniku. Pořizovací cenu je případně možné snížit využitím typového SW jako součástí webové komponenty nebo použitím telematických jednotek s užším rozsahem funkcí. Měsíční náklady na provoz navrženého software jsou obdobné jako u ostatních komerčně dostupných řešení. V případě použití hodnot úspor uvedených v literatuře a odhadu ceny realizace a provozu navrženého systému byla určena přibližná návratnost webové komponenty informačního systému pro podporu správy vozového parku podniku v délce 9 měsíců od uvedení do provozu.

LITERATURA

70

Literatura Aberdeen Group. Improving Productivity and Profitability through Service Fleet Management. Boston: Aberdeen Group, 2008. Al-Hanbali, N. a kol. Geospatial Information Modeling and Implementation for Navigation, Tracking and Address Location Services in Jordan. Al-Balqa: Al-Balqa Applied University, 2007. . API in OpenStreetMap Wiki [on-line], 2011 [cit. 2011-10-18]. Dostupný na: http://wiki.openstreetmap.org/wiki/API. Beagle software. Understanding GPS Technology. [on-line], 2010. [cit. 2011-07-23]. Dostupný na: http://www.beaglesoft.com/gpstechnology.htm. BusinessInfo.cz. Tzv. zrušení knihy jízd ve vztahu k DPH. [on-line], 2011 [cit. 2011-12-11]. Dostupný na: http://www.businessinfo.cz/cz/clanek/dan-z-pridane-hodnoty/ tzv-zruseni-knihy-jizd-ve-vztahu-k-dph/1001635/54798/. Carnet monitorování vozidel. Naše služby spojené s aplikací CarNet. [on-line], 2011. [cit. 2011-10-04]. Dostupný na: http://www.sledovaniaut.cz/produkty/ monitorovaci-system-carnet/sluzby-a-doplnky_19.html. Carter, C. Principles of GPS. Westlake Village: Allen Osborne Associates, 1997. CCB. CADnews 12. července 2007 — Track 2.0 v ostrém provozu. [on-line], 2007. [cit. 2011-10-12]. Dostupný na: http://www.cad.cz/news/archiv/cadnews_07-07-12.htm#Track20vostrmprovozu. CCG Systems. Selecting Software. [on-line], 2011. [cit. 2011-08-14]. Dostupný na: http://www.ccgsystems.com/selectingsoftware.php. Ciepluch, B., Jacob, R. a Winstanley, A. Comparison of the accuracy of OpenStreetMap for Ireland with Google Maps and Bing Maps. Maynooth: National University of Ireland Maynooth, 2010. Comparison of geographic information systems software in Wikipedia [on-line], 2011 [cit. 2011-10-23]. Dostupný na: http://en.wikipedia.org/wiki/Comparison_of_ geographic_information_systems_software. Coyle, J. J. a kol. Management of Transportation. Andover: Cengage Learning (EMEA), 2011. 540 s. ISBN 978-0-324-78920-1. Černý, M. Komunikace CAN v automobilu [diplomová práce]. Praha: České vysoké učení technické v Praze, 2005. Český hydrometeorologický ústav. Historie ústavu. [on-line], 2011 [cit. 2011-12-10]. Dostupný na: http://portal.chmi.cz/portal/dt?portal_lang= cs&menu=JSPTabContainer/P5_0_O_nas/P5_2_Historie_ustavu&last=false.

LITERATURA

71

D&COMM. Proč Tom Tom Work? [on-line], 2011. [cit. 2011-09-20]. Dostupný na: http://www.zkancelare.cz/proc-tom-tom-work/. Deb, B., Bannur, S. G. a Bharti, S. Evolution of Rich Intenet Applications (RIA). Bangalore: Infosys, 2007. Enviweb. AutoLocator přináší úspory. [on-line], 2011. [cit. 2011-07-23]. Dostupný na: http://www.enviweb.cz/clanek/doprava/86924/autolocator-prinasi-uspory. European Space Agency. What is Galileo? Paris: European Space Agency, 2011. Eurosat CS. Auto manažer — kompletní správa a sledování vozového parku. [on-line], 2007. [cit. 2011-10-04]. Dostupný na: http://vodafone.auto-gps.eu/. Finance.cz. Fleet Management 2011: Úspory a efektivní řešení v hlavní roli! [on-line], 2011. [cit. 2011-12-16]. Dostupný na http://www.finance.cz/zpravy/finance/ 303761-fleet-management-2011-uspory-a-efektivni-reseni-v-hlavni-roli-/. Flotila. České firmy stále podceňují Car Policy. [on-line], 2011. [cit. 2011-08-02]. Dostupný na: http://www.e-flotila.cz/index.php/sekce01/sprava-flotily/ 206-ceske-firmy-stale-podcenuji-car-policy. Getline, M. What exactly does an airline dispatcher do?. McLean: USA Today, 2005. Gps Fleet Management Weblog. Reducing Fleet „Soft Costsÿ with GPS Tracking Can Save You Big Money! [on-line], 2008. [cit. 2011-07-23]. Dostupný na: http://gpsfleetmanagement.wordpress.com/2008/09/07/ reducing-fleet-soft-costs-with-gps-tracking-can-save-you-big-money/. Grmela, J. Aplikace algoritmu hledání nejkratší cesty v geografických datech silniční sítě České republiky [bakalářská práce]. Brno: Mendelova univerzita v Brně, 2009. Goel, A. Fleet telematics: real-time management and planning of commercial vehicle operations. . Berlin: Springer, 2007. 200 s. ISBN 978-0387751047 Google Google Maps Javascript API V3 Reference. [on-line], 2011 [cit. 2011-10-17]. Dostupný na: http://code.google.com/intl/cs/apis/maps/documentation/ javascript/reference.html. Hánek, P. 250 let století zeměměřičství. Praha: Klaudian Praha, 2000. 73 s. ISBN 80-902524-0-0. HI Software Development. Webdispečink — elektronická kniha jízd — on-line sledování vozidel. [on-line], 2011. [cit. 2011-10-04]. Dostupný na: http://www. webdispecink.cz/o-sluzba-elektronicka-kniha-jizd-gps-sledovani-vozidel/. Hornoch, O.. Rozhodnutí o vedení 1/38 (E59) po historické trase Císařské silnice. [on-line], 2003. [cit. 2011-07-05]. Dostupný na: http://www.mbudejovice.cz/vismo/dokumenty2.asp?id_org=9890&id=1703. Innovative Maintenance Systems. Fleet Maintenance Pro. [on-line], 2009 [cit. 2011-11-29]. Dostupný na: http://www.mtcpro.com/fleetmtc.htm.

LITERATURA

72

Konečný, V. Integrované informační systémy. Brno: Mendelova univerzita v Brně, 2010. Kott, M. Problém obchodního cestujícího. Ostrava: Vysoká škola báňská — Technická univerzita Ostrava, 2007. Kozel, R. I střední a malé firmy mohou mít kvalitní fleet management! Praha: Mobility Vision, 2010. Lang, H. Manažerské účetnictví: teorie a praxe. Praha: C. H. Beck, 2005. 216 s. ISBN 80-7179-419-8. Letchford, A. N. Traveling Salesman Problem. Swansea: Lancaster University Management School, 2010. List of geographic information systems software in Wikipedia [on-line], 2011 [cit. 2011-10-23]. Dostupný na: http: //en.wikipedia.org/wiki/List_of_geographic_information_systems_software. Nemec, M. Životní cyklus vozidla a jeho spolehlivost. Praha: České vysoké učení technické v Praze, 2009. Open Knowledge Foundation. ODC Open Database License (ODbL) Summary. [on-line], 2011 [cit. 2011-10-18]. Dostupný na: http://opendatacommons.org/licenses/odbl/summary/. Patrushev, A. Shortest path search in real road networks with pgRouting. North Vancouver: Orkney, 2007. pgRouting Community. Traveling Sales Person (TSP). [on-line], 2011 [cit. 2011-12-07]. Dostupný na: http://www.pgrouting.org/docs/1.x/tsp.html. Podnikatel.cz. Služební auto pro osobní potřebu zaměstnance? Jak na to? [on-line], 2008 [cit. 2011-12-17]. Dostupný na http://www.podnikatel.cz/clanky/ sluzebni-auto-pro-osobni-potrebu-zamestnance/. Polovinčák, R. B. Virtuální webové mapové služby pro podnikové aplikace [diplomová práce]. Brno: Mendelova univerzita v Brně, 2011. Poradce. Povinnost vedení knihy jízd. [on-line], 2011 [cit. 2011-12-11]. Dostupný na: http: //www.i-poradce.cz/SubPages/OtvorDokument/Clanok.aspx?\idclanok=52155. http://www.podnikatel.cz/clanky/sluzebni-auto-pro-osobni-potrebu-zamestnance/ Postcode Anywhere. RouteOptimiser.com „Significantly Outperformsÿ Human Route-Planning. Worcester: Postcode Anywhere, 2010. Powell, W. B. a Topaloglu, H. Fleet Management. Princeton: Princeton University, 2002. Přibyl, P. a Svítek, M. Inteligentní dopravní systémy. Praha: BEN — technická literatura, 2001. 543 s. ISBN 80-7300-029-6.

LITERATURA

73

Radium. Fleetware 6+. [on-line], 2010. [cit. 2011-10-04]. Dostupný na: http://www.radium.cz/produkty/fleetware-6/. Rockway, J. Accelerating Perl Web Application Development. Olton: Packt Publishing, 2007. 200 s. ISBN 978-1-847190-95-6. Røpke, S. The dial a ride problem (DARP). København: Københavns Universitet, 2005. Řezník, T. Další dostupné zdroje geodat v ČR. Brno: Masarykova univerzita, 2008. Skytel. Assisted GPS. Herndon: Skytel, 1997. Slovík, J. Kde byla postavena první dálnice na světě? [on-line], 2011. [cit. 2011-07-05]. Dostupný na: http://www.dalnice.com/historie/prvni_dalnice/prvni_dalnice.htm. Spot. SPOT Personal Tracker. [on-line], 2011 [cit. 2011-10-17]. Dostupný na: http://www.findmespot.eu/en/index.php?cid=101. Strašák, J. Informační systém pro správu vozového parku [diplomová práce]. Praha: České vysoké učení technické v Praze, 2011. Stezka in Wikipedie [on-line], 2011 [cit. 2011-07-05]. Dostupný na: http://cs.wikipedia.org/wiki/Stezka. Štěpánek, J. Využití satelitní navigace v provozu vozidel [diplomová práce]. Brno: Mendelova univerzita v Brně, 2008. TechnoAssociates. Two Trends in Evolution of the Automotive Navigation Systems that Ensure In-Vehicle Comfort. [on-line], 2008 [cit. 2011-12-05]. Dostupný na: http://e2af.com/trend/080212.shtml. Telefónica Czech Republic. O2 Car Control — O službě. [on-line], 2011. [cit. 2011-10-04]. Dostupný na: https://carcontrol.cz.o2.com/web/OSluzbe.aspx. TomTom Business Solutions. WEBFLEET — Nejdůležitější údaje [on-line], 2011. [cit. 2011-09-20]. Dostupný na: http://business.tomtom.com/cs_cz/products/webfleet/highlights/. Ústřední Automotoklub ČR. Profil společnosti. [on-line], 2011 [cit. 2011-12-10]. Dostupný na: http: //www.uamk.cz/index.php?option=com_content&view=article&id=25&Itemid=28. Vymětal, D. Informační systémy v podnicích — teorie a praxe projektování. Praha: Grada Publishing, 2009. 142 s. ISBN 978-8-024730-46-2. ySystem. Fleet Controlling. [on-line], 2011 [cit. 2011-10-12]. Dostupný na: http://www.ysystem.eu/index.php/cs/ytrack/48-fleet-controlling-co-to-je.

Přílohy

A

A

SNÍMKY OBRAZOVEK DOSTUPNÉHO PROGRAMOVÉHO VYBAVENÍ

75

Snímky obrazovek dostupného programového vybavení

Obr. 11: TomTom Work — Mapa se zobrazení polohy vozidel

Obr. 12: TomTom Work — Výkaznictví

A


Obr. 13: TomTom Work — Grafové funkce

Obr. 14: TomTom Work — Evidence vozidel

76

A


Obr. 15: Carnet sledování vozidel — Mapa se zobrazení trasy vozidla

Obr. 16: Carnet sledování vozidel — Kniha jízd

77

A


Obr. 17: Carnet sledování vozidel — Statistické funkce

Obr. 18: Carnet sledování vozidel — Evidence vozidel

78

A


Obr. 19: O2 Car Control — Zobrazení mapy pro sledování vozidel

Obr. 20: O2 Car Control — Kniha jízd

79

A


Obr. 21: O2 Car Control — Výkazy vozidel

Obr. 22: O2 Car Control — Správa vozidla v evidenci

80

A


Obr. 23: Vodafone Sledování vozidel — Zobrazení mapy pro sledování vozidel

Obr. 24: Vodafone Sledování vozidel — Kniha jízd

81

A


Obr. 25: Vodafone Sledování vozidel — Výkaz provozu vozidla

Obr. 26: Vodafone Sledování vozidel — Statistika čerpání paliva

82

A


Obr. 27: HI Software Webdispečink — Zobrazení mapy pro sledování vozidel

Obr. 28: HI Software Webdispečink — Kniha jízd

83

A


Obr. 29: HI Software Webdispečink — Optimalizace tras

Obr. 30: HI Software Webdispečink — Statistika spotřeby paliva

84

A


Obr. 31: Radium Fleetware web — Zobrazení mapy pro sledování vozidel

Obr. 32: Radium Fleetware web — Kniha jízd

85

A


Obr. 33: Radium Fleetware web — Výkaz ujetých vzdáleností

Obr. 34: Radium Fleetware web — Výkaz stání vozidla

86

pro řízení a správu vozového parku v informačním systému podniku

Recommend Documents