Praktické využití technologie mobilních zařízení v plynárenství (koncern RWE Group v ČR)

České vysoké učení technické v Praze Fakulta elektrotechnická

Diplomová práce

Praktické využití technologie mobilních zařízení v plynárenství (koncern RWE Group v ČR) Bc. Petr Lauko

Vedoucí práce: Ing. Radim Havlík Studijní program: Elektrotechnika a informatika strukturovaný magisterský Obor: Informatika a výpočetní technika květen 2007

Poděkování Chtěl bych poděkovat vedoucímu diplomové práce, Ing. Radimu Havlíkovi, za metodickou pomoc při práci na tomto díle.

Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č.121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Ústí nad Labem dne 30.4.2007

______________________

Abstract The main target of this diploma thesis is to find out possibilities, how to implement technologies of pocket computers in gas industry, especially in RWE Group in CZ. Aim of this work is to make an analysis, to suggest a solution and to evaluate the solutions (according to IT infrastructure and business processes). The result is detailed pre-project study.

Abstrakt Hlavním úkolem této diplomové práce je nalézt možnosti, jak využít technologie kapesních počítačů v plynárenském průmyslu, zejména v RWE Group v ČR. Cílem práce je provést analýzu, navrhnout řešení a na závěr zhodnotit řešení (s ohledem na IT infrastrukturu a podnikové procesy). Výsledkem je detailní předprojektová studie.

OBSAH 1

Úvod 1.1 1.2 1.3 1.4

2

4

5

6

Profil společnosti RWE Stručný přehled vývoje IT v RWE Přínos diplomové práce Metodika

Řešení – část I. – Podpora managementu – Mobilní kancelář 2.1 2.2 2.3 2.4 2.5

3

1

Úvod do problematiky Specifikace cíle Analýza současného stavu Návrh řešení Zhodnocení

2 3 4 5 7 8 10 13 14 29

Řešení – část II. – Podpora odečítačů – Sběr odečtů

31

3.1 3.2 3.3 3.4 3.5

32 34 37 43 49


Řešení – část III. – Podpora montérů – Mobilní pracovní příkazy

51

4.1 4.2 4.3 4.4 4.5

52 54 57 63 73


Závěr diplomové práce

75

5.1 5.2 5.3 5.4

76 77 78 79

Stručná rekapitulace navrhů řešení Zhodnocení přínosů a nedostatků řešení Detekce možných rizik – pro realizaci Závěr

Přílohy 6.1 6.2 6.3 6.4 6.5

81 Přehled kapesních počítačů využívaných v RWE Příslušenství kapesních počítačů Vývoj komunikačních technologií Benchmark technologií GPRS a EDGE Vývoj technologie Bluetooth

82 91 95 99 101

Seznam použité literatury [1]

KLÁSEK Jindřich. Palm pro manažery i fanoušky Praha: Computer Press, 2001. 340s. ISBN: 80-722-6410-9

[2]

KURUC Jiří, JANEČEK Vladislav. Tipy a triky pro Pocket PC, 2. vydání Praha: Computer Press, 2004. 124s. ISBN: 80-251-0195-9

[3]

PUŽMANOVÁ Rita. Bezpečnost bezdrátové komunikace aneb jak zabezpečit Wi-Fi, Bluetooth, GPRS či 3G Praha: Computer Press, 2005. 184s. ISBN: 80-251-0791-4

[4]

PUŽMANOVÁ Rita. Moderní komunikační sítě od A do Z, 2. vydání Praha: Computer Press, 2006. 432s. ISBN: 80-251-1278-0

[5]

TKÁČ Josef, ZAORAL Ondřej. Průvodce světem kapesních počítačů aneb Praha: Grada Publishing, 2005. 208s. ISBN: 80-247-1227-X

[6]

TRNEČKA Ivan. PDA aneb kapesní počítače pro každého Praha: Computer Press, 2002. 96s. ISBN: 80-865-9315-0

KAPITOLA 1.

ÚVOD

1.1

Profil společnosti RWE

1.2

Stručný přehled vývoje IT v RWE

1.3

Přínos diplomové práce

1.4

Metodika

1.1 Profil společnosti RWE

Společnost RWE je třetí největší evropskou energetickou skupinou se sídlem v Německu. Hlavními trhy jsou Německo, Velká Británie a střední a východní Evropa. Elektrickou energií, plynem a vodou zásobuje v Evropě celkem 44 milionů zákazníků. Zastřešuje pět divizí – RWE Power, RWE Trading, RWE Energy, RWE npower a RWE Systems. Společnosti skupiny RWE v ČR organizačně patří pod divizi RWE Energy. RWE Transgas řídí jejich činnost a jeho hlavními obchodními aktivitami jsou dovoz zemního plynu a obchod se zemním plynem. Do skupiny RWE v ČR patří regionální distribuční společnosti Západočeská plynárenská (ZČP), Středočeská plynárenská (STP), Severočeská plynárenská (SČP), Východočeská plynárenská (VČP), Severomoravská plynárenská (SMP) a Jihomoravská plynárenská (JMP). Od 1. 1. 2007 se z každé této společnosti oddělila činnost přepravy zemního plynu. Regionální distribuční společnosti se tak staly obchodníky s touto komoditou a provozovateli distribuční soustavy jsou společnosti mající v názvu slovo „Net“, např. STP Net. Součástí skupiny RWE v ČR je také RWE Plynoprojekt, který nabízí kompletní projektovou, konzultační, poradenskou a investorskoinženýrskou činnost. RWE v České republice rovněž vlastní společnost RWE Transgas Net. Ta zajišťuje tranzitní přepravu zemního plynu přes území ČR pro zahraniční obchodní partnery a vnitrostátní přepravu zemního plynu tuzemským partnerům. Zajišťuje rovněž provozování podzemních zásobníků a přepravu zemního plynu, který je v nich uskladněn.

1.2 Stručný přehled vývoje IT v RWE

V rámci divize RWE Energy působí na území ČR společnost RWE Energy Customer Services CZ, která je od začátku roku 2005 centrálním poskytovatelem služeb v oblasti informačních systémů a technologií v rámci ČR. V roce 2005 byl spuštěn centrální helpdeskový systém, který umožnil procesně podpořit centralizaci IT a zkvalitnil tak služby koncovým uživatelům v rámci skupiny. Během tohoto roku se také v rámci sjednocování informačních systémů a technologií připravovalo sjednocení finančních (SAP Classic) a grafických informačních systémů (SAP PM/GIS). V závěru roku 2005 se úspěšně provedl roll out tohoto řešení do všech společností skupiny. Od 1.ledna 2006 využívá celá společnost centrální systém SAP Classic, který nahradil do té doby lokální systémy mySAP.com, a centrální systém SAP PM/GIS (GNOSIS). Na začátku roku 2006 byl uveden do provozu nový Intranet společnosti RWE, který výrazně posílil možnosti komunikace a přístupu ke sdíleným informacím. Spuštění systému elektronického schvalování dokumentů DMS přineslo kvalitativně vyšší úroveň schvalovacích procesů, založených nyní na elektronickém oběhu dokumentů a jejich kontinuální evidenci. V průběhu roku 2006 se v rámci pilotního projektu prováděla implementace zákaznického informačního systému SAP IS-U. Tento systém má za úkol nejen nahradit různorodá a dosud i lokální řešení, ale má za úkol celou skupinu připravit na otevření trhu s energiemi, který si žádá velmi významné změny nejen v informačních systémech, ale i v samotné organizaci a procesech. V závěru roku 2006 se úspěšně provádí implementace systému SAP IS-U v rámci celé skupiny pro kategorii maloodběru a domácností. V roce 2007 se pokračuje v implementaci informačního systému SAP IS-U migrací kategorií středního a velkoodběru. Od 1.ledna 2007 bylo v rámci poskytovaných služeb pro distribuční společnosti skupiny RWE v ČR spuštěno jednotné Call Centrum, které poskytne zvýšenou hodnotu pro koncové uživatele. Rok 2007 bude pro společnost opět ve znamení zásadních strukturálních změn.

1.3 Přínos diplomové práce Tato práce se věnuje možnostem využití technologií kapesních počítačů v plynárenském průmyslu – konkrétně v prostředí skupiny RWE v ČR. Cílem této práce je zejména zmapování dosavadního využití této technologie v rámci skupiny, analýza přínosů a nedostatků již realizovaných projektů a návrh nových řešení pro implementaci této technologie. Výstup by měl posloužit RWE pro plán rozvoje IT v oblasti kapesních počítačů, měl by ukázat možnosti a oblasti jejich dalšího využití v rámci plynárenství, a také by měl poukázat na nedostatky současných řešení, včetně předložení návrhu na jejich odstranění. Při konzultaci s vedoucím diplomové práce byly vytipovány tři oblasti implementace, na které jsem se zaměřil. - Mobilní kancelář, řešící obecné principy mobilního přístupu k datům - Sběr odečtů, řešící problematiku hromadného sběru a zpracování dat - Mobilní pracovní příkazy, řešící vázbu mobilního řešení s informačním systémem

Záměrně byly vybrány oblasti, které měly vždy různé specifické požadavky na danou technologii. Myslím si, že se právě dobrou volbou těchto zcela odlišných oblastí podařilo demonstrovat to, že lze tuto technologii implementovat téměř v jakékoliv oblasti. Samozřejmě, že to znamená někdy velmi specifické požadavky na samotná zařízení či programové řešení, ale i toto je v rámci této práce dobře patrné. Při práci na tomto tématu jsem využil svých bohatých zkušeností z projektů, které jsem v dané oblasti v rámci skupiny RWE zrealizoval. Velkou výhodou je pro mě i to, že v tomto prostředí pracuji již 5 let a 2 projekty v této oblasti jsem měl na starosti. Shodou okolností oba tyto projekty souvisí s našimi oblastmi, takže jejich hodnocení zazní v rámci detailní analýzy výchozího stavu. I pro mě bylo s odstupem času velmi zajímavé zhodnotit svou práci, připustit si chyb, kterých jsme se dopustili, a dokázat si z nich vzít ponaučení pro návrh nového řešení. Z tohoto důvodu si myslím, že je tato práce zajímavým podkladem pro případné další projekty.

1.4 Metodika Nyní si trochu objasníme to, jak jsem k celé diplomové práci přistupoval. Je to nezbytné k tomu, aby byly pochopeny jednotlivé závěry. Členění dle oblastí v zadání bylo zachováno. Záměrně jsem diplomovou práci rozdělil do 3 částí tak, aby každá část odpovídala každé oblasti. V rámci těchto částí jsem prováděl obdobné kroky tak, aby byly závěrečné výstupy vzájemně porovnatelné. Vždy jsem se zaměřil na následující oblasti: úvod, specifikaci cíle, analýzu současného stavu, návrh mého řešení a závěrečné zhodnocení. Nyní si podrobně projdeme, co se pod každou z částí skrývá, aby byl text diplomové práce lépe pochopitelný. 1.4.1

Úvod do problematiky

V těchto částech jsem se pokusil vždy co nejobecněji popsat to, co se v rámci společnosti v dané oblasti odehrává. Samozřejmě, že problematika tzv. mobilní kanceláře může být každému jasná, ale třeba takové procesy týkající se sběru odečtů a nebo řešení pracovních příkazů při údržbě plynárenského majetku, to už člověku mimo plynárenství moc neřekne. Každopádně po přečtení této části by Vám mělo být vždy jasné, v jaké oblasti a jaké procesy se budou odehrávat. 1.4.2

Specifikace cíle

V těchto částech jsem se zaměřil na to, abych pokud možno jazykem uživatele definoval požadavky na samotné řešení problému. Snažil jsem se v této fázi vyvarovat jakýchkoliv náznaků řešení či posuzování současných řešení. Po prostudování této části by mělo být patrné to, co se budeme snažit návrhem řešení vyřešit – máme specifikovaný cíl. 1.4.3

Analýza současného stavu

Před tím, než ale můžeme přistoupit k návrhům realizace, je ještě nutné znát současný stav, případně historický vývoj v dané oblasti. To má za cíl tato část. Po jejím přečtení by mělo být čtenáři jasný současný stav a měl by tak být schopen pochopit případné vazby návrhu řešení na současný stav. Zde si musíme uvědomit, že v reálném životě to takto opravdu funguje a i když se nám může zdát původní technologie jakkoliv nepoužitelná, nikdy neuškodí udělat analýzu, jaké měla pozitivní a jaké negativní vlivy na prostředí společnosti. Minimálně se tak můžeme poučit z předchozích chyb, vyvarovat se jim a neodsoudit nové řešení již v zárodku k neúspěchu. 1.4.4

Návrh řešení

Nyní jsme se dostali k nejzajímavější části, samotnému návrhu řešení. K tomu, abychom byli schopni zcela správně pochopit důvody návrhu, je nutné prostudovat a pochopit předchozí části. Samozřejmě, že jsem se i já mohl ve svých návrzích splést a dopustit se tak nějaké chyby, která by se projevila až při samotném projektu nebo implementaci. Proto jsem se snažil vždy ne zcela logická rozhodnutí co

nejvíce vysvětlit, aby byly známy důvody mého rozhodnutí. Může se totiž stát, že tyto důvody pominou, a pak by mé řešení nebylo zcela nejoptimálnější. Snažil jsem se v této části držet původní specifikace cílů a dál tak rozvíjet návrh, jak tohoto dílčího požadavku a jakými nástroji docílit. Samozřejmě, že se třeba některé nové požadavky na řešení objeví až ve fázi návrhu řešení, tak jak tomu bývá i v reálných projektech. Proto je nutné, aby specifikace cíle nebyla pouze z pohledu uživatele, ale i z pohledu technika IT. Já jsem v této práci záměrně specifikaci cíle pojal jako ryze uživatelskou, aby více korespondovala s tím nejhorším případem z reálného života, než s ideálním případem. Samozřejmě, že jsem dodatečně vzešlé požadavky do řešení promítl. Tato část by nám tedy měla vždycky říci, jakým způsobem při návrhu postupovat, jakou technologii použít a jakým způsobem, aby bylo dosaženo specifikovaného cíle a navíc celé řešení zapadlo do koncepce RWE. 1.4.5

Zhodnocení

V závěrečné fázi se pokouším odhadnout dopady řešení – pozitivní i negativní. Snažím se např. detekovat případná rizika při implementaci a určit jak pracné a drahé by řešení mohlo být. Samozřejmě že neplatí vždy, že peníze jsou rozhodující, ale je to ten rozhodující faktor, zda se vůbec nějaká řešení podaří zrealizovat. Zejména v podnikatelské sféře se očekává, že vynaložené prostředky se společnosti vrátí dříve, než je celá investice finančně odepsána (zpravidla 4 roky). Vzhledem k velkému tempu vývoje IT si ale musíme uvědomit, že 4 roky jsou naprosto nevyhovující doba – během tak dlouhé doby jsou IT prostředky nedostačující technicky, kapacitně a jsou v podstatě morálně zastaralé. Ať se koukneme na vývoj procesorů, jejich neustálé zrychlování, na vývoj operačních systémů, jejich neustálé zdokonalování, stále musíme brát do úvahy, že to co platí dnes, může být za rok nebo dva nedostatečné nebo špatné. To samé platí i pro diplomové práce zabývající se IT problematikou.

KAPITOLA 2.

ŘEŠENÍ – ČÁST I. Podpora managementu Mobilní kancelář

2.1


2.2

Specifikace cíle

2.3


2.4

Návrh řešení

2.5

Zhodnocení

2.1 Úvod do problematiky – Mobilní kancelář Trendem dnešní doby je snaha mít přístup ke všem informacím téměř odkudkoliv. Nikdo se již nechce spokojit s tím, aby se dozvěděl důležité informace až druhý den ráno, jakmile dorazí do své kanceláře a zapne si svůj stolní počítač. Chceme tyto informace získat co nejdříve, jakmile se objeví. A protože nechceme být omezení nutností sedět pouze ve své kanceláři, chceme aby tyto informace byly schopny k nám samy doputovat kdykoliv a kamkoliv. Podívejme se blíže na potřeby takového typického představitele tohoto segmentu pracovníků – středního nebo vrcholového manažera. Jeho náplní práce není žádná rutinní činnost, kterou by vykonával pouze ve své kanceláři, po dobu pracovní doby. Spíše je to naopak. Když se podíváme na harmonogram manažera a srovnáme ho s harmonogramem jiného zaměstnance, který svou náplň práce převážně tráví v kanceláři při rutinní činnosti, uvědomíme si obrovský rozdíl. Například takový účetní bude mít harmonogram z 90% prázdný, což bude představovat jeho rutinní činnost. Bude v něm mít pouze jednou týdně naplánovánu lekci anglického jazyka, pravidelnou týdenní poradu s ředitelem a možná nějakou schůzku projektového týmu. Jak vypadá takový harmonogram manažera? Především zde najdeme daleko více naplánovaných akcí – poměr bude spíše opačný, než tomu bylo u účetního. Bude zde více schůzek, porad, jednání a úkolů, které nebudou souviset s rutinní činností manažera. Dalším jevem, který zde bude častý je souběh několika akcí současně – manažer si plánuje veškeré alternativy, neboť do poslední chvíle neví, zda a které akce se bude moci účastnit a která se např. konat nebude. V harmonogramu se také budou objevovat i jiné akce, než jen pracovní – manažer, který dokáže efektivně plánovat svůj pracovní čas, umí této dovednosti využít i pro organizování svého volna. Dokáže si přehledněji plánovat např. rodinné akce, oslavy s přáteli, sportovní zápasy apod. Je to dáno i tím, že u manažera není tak zcela jasná hranice toho, kdy pracuje a kdy má již volno. Není to dáno tím, zda je na svém pracovišti, či nikoliv. Naopak manažer si často nosí práci domů a využívá tak každičké chvilky, kdy ho napadne něco zásadního, co by byla škoda hned nezužitkovat. Naopak účetní má pevně danou hranici, kdy je v práci a pracuje, a kdy je mimo zaměstnání a má volno. Je to také dáno tím, že účetní nemá možnost rozhodnout se, že např. tuhle práci si vezme domů. Proč vlastně taková názorná ukázka? Ukázali jsme si hlavně jednu důležitou věc, že ne každé zaměstnání je vhodné pro využití tzv. mobilní kanceláře. Pojďme se nyní teda podívat na potřeby vhodného adepta pro využití řešení „mobilní kanceláře“ a pokusme se pro tohoto vzorového pracovníka navrhnout co nejoptimálnější skladbu využití mobilního zařízení k tomu, aby ho vnímal jako opravdu nepostradatelného pomocníka.

Když si uvědomíme skutečné potřeby manažera a uvědomíme si, že je pro něho nutností služebně cestovat a přitom být neustále v kontaktu s partnery, popř. mít přehled o děním ve společnosti. Nejraději by měl takový nástroj, který by mu poskytoval funkcionalitu jeho kanceláře neustále a kdekoliv. Začíná se nám pomalu rýsovat to, co se skrývá za označením „mobilní kancelář“. Je to především nástroj k tomu, abychom bez ohledu na to, kde se zrovna nacházíme, měli přístup k prostředkům, které máme ve své kanceláři, abychom s nimi mohli pracovat, jako kdybychom seděli v kanceláři a abychom je mohli sdílet s kýmkoliv, s kým potřebujeme, bez ohledu na to, kde se kdo z nás zrovna nachází. Definic pojmu „mobilní kancelář“ bychom jistě našli více, v rámci této diplomové práce si však tento termín vydefinujeme takto: Definice: „Mobilní kancelář“ je soubor nástrojů a prostředků IT techniky, který nám slouží při výkonu práce k eliminování všech omezení vyplývajících z našeho momentálního pobytu mimo naše obvyklé pracoviště – např. kancelář apod.

2.2 Specifikace cíle Po tomto obecném vysvětlení toho, co vše se očekává od řešení tzv. Mobilní kanceláře, se budeme již konkrétně zabývat řešením pro střední a vrcholové vedení v rámci RWE. Pod pojmem vrcholové vedení v rámci RWE budeme chápat členy představenstev jednotlivých akciových společností, ředitele divizí. Střední vedení je tvořeno řediteli úseků, kteří organizačně spadají pod vrcholové vedení. Typické pro střední a vrcholové manažery je využívání služeb asistentů. Proto se v návrhu zaměříme i na možnost užší spolupráce s asistenty na dálku. Pojďme se nyní podívat detailněji na jednotlivé nástroje manažera a pojďme se je včlenit do opravdu efektivního návrhu řešení mobilní kanceláře. 2.2.1

Poštovní schránka (e-mail)

V dnešní době je e-mail jedním z nejvýznamnějších komunikačních kanálů obecně. Slouží k rychlému vyměňování informací či hromadnému informování adresátů. V případě manažera lze říci, že se jedná o jeden z hlavních pracovních nástrojů, které potřebuje každý den. Dnešní doba je již na tomto komunikačním kanále tak závislá, že se pomalu stává standardem mezi komunikačními prostředky. K tomu přispívá i implementace různých bezpečnostních prvků a podpisových certifikátů, aby se eliminovaly jediné bezpečnostní nedostatky, které elektronická pošta proti klasické papírové poště má. Požadavky na tento nástroj jsou následující. Navržené řešení musí umožnit - mobilní a plnohodnotný přístup k e-mailové schránce - příjem, čtení a odesílání zpráv, včetně přikládání příloh - využití elektronického podpisu - sdílení poštovní schránky s asistentkou, včetně možnosti jejího používání v zastoupení 2.2.2

Kalendář

S efektivním organizováním a plánováním času souvisí potřeba přístupu do harmonogramu, kde si může manažer organizovat a zaznamenávat své plánované aktivity. Tuto oblast jsme si již vysvětlili dříve, pojďme si rovnou vyspecifikovat požadavky na tento nástroj. Navržené řešení musí umožnit - plnohodnotný přístup ke kalendáři - plnohodnotné organizování času – plánování, upomínání - automatickou aktualizaci mezi PDA a serverem (nejlépe vzdálenou, bezdrátovou, automatickou) - sdílení kalendáře s asistentkou

2.2.3

Kontakty

Podobné, co jsme si řekli vyspecifikovali pro Kalendář, musí platit i pro Kontakty. Není asi nutné zdůrazňovat, že pro manažera jsou kontakty jednou z nejcennějších informací. Nezáleží na tom, zda se jedná o kontakty ryze obchodní nebo osobní, zda se jedná o partnera v obchodním styku nebo zda se jedná o kolegu z dávného projektu. Pro manažera je typické to, že se jeho adresář kontaktů velmi rychle rozrůstá, aniž by z něj byly průběžně vyřazovány kontakty na osoby, s kterými již manažer není tak často ve styku. Souvisí to s tím, jak moc si těchto informací cení a jak efektivně je umí využívat ve svůj prospěch. S ohledem na to, co jsme si nyní řekli, můžeme vyspecifikovat následující požadavky. Navržené řešení musí umožnit - přístup k jednomu adresáři kontaktů (synchronizací nebo online) – eliminace duplicit - pořízení nových kontaktů z PDA i z PC (synchronizací nebo online) - sdílení adresáře kontaktů s asistentkou Tyto tři nástroje manažera tvoří do jisté míry celek. Když se podíváme i na trend ve vývoji poštovních klientů pro PC, můžeme tento trend rovněž objevit. Kontakty a samotná poštovní schránka spolu vždy souvisely, přesto ve velmi dávné době tomu tak rovněž nebylo. Plánování schůzek a aktivit již tak automaticky nemusí každý vnímat jako součást vhodnou k integraci. Obrovským přínosem této integrace je to, že např. samotné plánování schůzky udělá pouze organizátor akce. Pozvaní účastníci obdrží prostřednictvím pošty výzvu k akceptaci a nebo zamítnutí své účasti – tato akce se zcela automaticky promítne i do kalendáře, kde se buď nová akce objeví a nebo neobjeví. Integrace s poštovním klientem tomuto kalendáři dává velmi užitečnou vlastnost. V prostředí PC si můžeme uvést jako představitele Microsoft Outlook z řad komerčních produktů a ThunderBird (součást tzv. OpenOffice) z řad tzv. opensource produktů. 2.2.4

Kancelářské aplikace

Další oblastí, kterou je nutno rovněž vyřešit, je možnost práce s tzv. kancelářskými soubory. Co si pod tímto názvem představit? Nejjednodušší je představit si toto na PC, vybaveném např. balíčkem aplikací Microsoft Office (komerční produkt) nebo OpenOffice (opensource). Jedná se o tři základní typy aplikací – textových editor pro tvorbu dokumentů, tabulkový procesor pro tvorbu reportů nebo grafů a nakonec nástroj pro tvorbu a spouštění prezentací. Samozřejmě, že se v kancelářských balíčcích začínají objevovat stále další a další nástroje – např. nástroje pro práci s lokálními databázemi, editory matematických rovnic apod. Pro práci na PDA však budou postačovat prvně jmenované tři nástroje.

Navržené řešení musí umožnit - zobrazení a základní práci se soubory standardu Microsoft Office – (DOC, XLS a PPT) 2.2.5

Internet / Intranet

Dalším požadavkem, ale také stejně významným, je možnost přístupu k síti internetu a intranetu – tj. vnitřní firemní síti nebo-li podnikové síti. Zde je nutné nejen samotné spojení přenášející data, ale i Internetový prohlížeč – nástroj, který nám dokáže správně zobrazit internetové stránky jako na PC. Na PDA budeme pouze limitováni velikostí displeje. Navržené řešení musí umožnit - přístup k síti internet a intranet – zabezpečená podniková síť - zobrazení HTML a WAP stránek – s ohledem na velikost displeje 2.2.6

Bezpečnost

Nyní se dostáváme do oblasti, kterou je nutné spíše řešit z hlediska IT a pouze do něj promítnout případné potřeby uživatele. Ze strany uživatelů jsou restrikce v důsledku bezpečnosti vnímány spíše negativně, jako nařízení, která je nutná dodržovat a která mají negativní vliv na uživatelský komfort. Jakmile se však uživatel stane obětí ztráty dat nebo napadení nějakým virem, jeho vnímání se v této oblasti změní. Při návrhu řešení budeme řešit tyto 3 základní oblasti: zálohování (bránící nechtěné ztrátě dat), zabezpečení (bránící neoprávněnému zneužití dat) a bezpečný způsob komunikace (bránící odposlechům v rámci počítačové sítě). Navržené řešení musí umožnit - implementaci bezpečnostní politiky IT RWE (SECPOL) - zabezpečení PDA proti nechtěné ztrátě údajů (zálohování) - zabezpečení PDA proti zneužití údajů při odcizení (PIN, krytování) - používání zabezpečené komunikace (vlastní IT infrastruktura, VPN kanály)

2.3 Analýza současného stavu V této části se nyní pokusíme zmapovat dosavadní vývoj v dané oblasti. Je nutné si uvědomit, že před příchodem RWE na český energetický trh, byly všechny plynárenské společnosti jako zcela samostatné subjekty. Z toho důvodu byl i rozvoj samotného IT na velmi odlišných úrovních – dokonce bych řekl, že právě vyspělost IT odrážela hospodářské úspěchy a ekonomickou sílu jednotlivých společností. Podobně tomu je obecně – velmi silné a stabilní podniky investují do IT nemalé prostředky, protože si dobře uvědomují, že tyto investice se mohou v rámci úspěšných projektů velmi rychle vracet. Co se týče PDA a řešení pro manažery, neexistoval v žádné společnosti v rámci RWE žádný standard. Výběr koncových zařízení (notebooků, PDA, mobilních telefonů) byl ryze individuální záležitostí, a více se dbalo na požadavky manažera se odlišovat či vzbudit pozornost, než na to, aby se zachovávala programová kompatibilita, schopnost připojení apod. Samozřejmě, že každé PDA z principu má v sobě kancelářské aplikace. Bohužel ale to samo o sobě nestačí, abychom uměli vždy maximálně a v jakémkoliv prostředí využít na plno všechny vlastnosti. Rovněž ne každý přístroj uměl zcela vše. Proto bych si dovolil situaci ještě rok zpátky zhodnotit jako zcela neudržitelnou. Řešením této situace bylo to, že se výběr PDA zcela svěřil po odborné stránce odborníkům IT. Situace se zlepšila a konečně bylo možné začít nějakým způsobem budovat řešení, která mohla přinášet více užitků než vrásek na tváři IT techniků. Přesto stále nejsou splněny dvě základní podmínky pro jednotné řešení. Není jasně definovaná platforma PDA (chybí standard definující konkrétní modely) a stále je v rámci RWE více poštovních serverů, dokonce různých technologií – Microsoft Exchange Server a Domino Lotus Notes od IBM. Analýza současného stavu - neexistuje jednotná platforma kapesních počítačů v rámci koncernu RWE - neexistuje standard definující skupiny použitelných přístrojů pro konkrétní oblasti - decentralizace poštovních serverů – navíc různé platformy (MS, IBM, NOVELL)

2.4 Návrh řešení Nyní máme vydefinovány požadavky na samotné řešení, udělali jsme analýzu současného stavu, takže můžeme přistoupit k návrhu nového řešení. 2.4.1

Serverová část – poštovní server

Jak jsme již zmínili v analýze, velkým nedostatkem současného stavu je decentralizace a různorodost poštovních serverů. Pokud máme navrhnout skutečně efektivní řešení, mělo by být vybudována na jedné technologii a nejlépe na jedné instanci serveru. Soustřeďme se nyní na dvě otázky – jak provést centralizaci a na jaké platformě řešení vybudovat. Nejdříve pojďme vyřešit umístění, protože to je nejjednodušší otázka. V rámci koncernu RWE bylo v Brně vybudováno datové centrum, které je dimenzováno tak, aby bylo schopno poskytovat HW zázemí pro provoz všech informačních systémů ve společnostech v rámci koncernu RWE ve střední a východní Evropě. Z tohoto pohledu neexistuje lepší lokalita k umístění centrálního poštovního serveru pro celou ČR. Druhou otázkou je výběr platformy, kde je již prostor k hlubším debatám. Již jsme si zmínili, že v rámci ČR existují tři různé produkty – Exchange Server od společnosti Microsoft a Lotus Notes od společnosti IBM. Převládající je v rámci ČR produkt Microsoftu. Jedinou opravdu zásadní nevýhodou produktu Microsoft je to, že se stává velmi často terčem útoků hackerů a virů. V důsledku toho je úspěšnost dočasného vyřazení serveru z provozu v důsledku napadení vyšší, než u konkurenčního produktu. Neznamená to ale, že by byly produkty v tomto směru zásadně rozdílné po stránce kvality. Naopak je nutné uvědomit si, s jakou rychlostí dokáže Microsoft na zjištěné bezpečnostní díry reagovat. Otázkou zůstává, zda by i ostatní konkurenti byli schopni odolávat takovým útokům a za jakou cenu. Pro svůj návrh řešení jsem zvolil produkt Microsoft Exchange Server. Důvody jsou následující : - lepší provázanost s operačním systémem a poštovním klientem na klientské straně (PDA) - nižší cena řešení (mezinárodní kontrakt RWE a Microsoftu poskytující výhodné cenové podmínky) - snadnější implementace (v rámci RWE je to nejrozšířenější řešení – snadná centralizace)

Řešení - centralizace poštovních serverů – 1 server pro celou ČR - fyzické umístění serveru v Brně (datové centrum pro střední Evropu, velká úroveň zabezpečení) - platforma pro poštovní server - Microsoft Exchange Server (od společnosti Microsoft) Poznámka: V rámci postupné integrace jednotlivých distribučních společností do struktury RWE dochází ke sjednocování poštovních domén na jednotnou koncernovou – tj. doménu rwe.cz. Sjednocení domén není nutné pro provedení námi navržené centralizace, bylo by možné i provozování více domén na jednom serveru současně. Naopak potřeba sjednotit domény přímo vybízí k centralizaci poštovních serverů. 2.4.2

Koncová zařízení – kapesní počítače

Jako nezbytná součást skutečně efektivního návrhu je standardizace zařízení. Je nezbytné, aby se definovala omezená množina zařízení s ohledem na používaný operační systém, technické parametry a programové vybavení. Pokud toto nebude zajištěno, stále se budeme potýkat s neefektivním nákupem koncových zařízení, bude pro nás náročné jejich údržba z hlediska IT, nemůže být zaručena 100% funkčnost atd. Hlavním cílem této fáze je navržení standardních koncových zařízení, která budou splňovat veškeré požadavky uživatele a budou fungovat v rámci navrhovaného řešení. Dopředu je ale nutné zdůraznit, že ze strany uživatele obecně převládá neochota takovýmto standardům se podřizovat. Proto je skutečně nutné toto řešit citlivě, do fáze výběru třeba i zahrnout nějaké zástupce konečných uživatelů. Ideální je v rámci pilotního projektu možnost vyzkoušení několika variant při běžném používání několika uživateli. Někomu se může toto zdát jako nepodstatná fáze, kterou by vyřešil sám rozhodnutím tzv. od stolu. Je nutné si ale uvědomit, že námi navrhované řešení má sloužit koncovým uživatelům, navíc se jedná o vrcholové vedení společnosti. Z našeho pohledu je nutné omezit množinu koncových zařízení na minimum – ideálně na jeden konkrétní typ. Proto zde je nutná součinnost s uživatelem, aby výsledný standard vyhovoval oběma stranám. Pokud se nám toto nepodaří, nemůžeme hovořit o efektivním řešení – buď by uživatel nebyl spokojen s navrženým koncovým zařízením, nebo bychom nebyli schopni hromadným nákupem jednoho typu zrealizovat tento projekt za nízké náklady a následně by i technici IT měli problémy při údržbě více druhů zařízení. V rámci této diplomové práce tuto část musíme vynechat, ale při skutečné implementaci by to nebylo možné. Začněme tedy s výběrem koncového zařízení s pohledu technického - operačním systémem. Přestože jsou na trhu i jiné platformy, než je platforma Microsoft (např. Palm), je přece jen platforma PocketPC nejrozšířenější. Navíc je zde velkou výhodou maximální možná provázanost funkcí koncových zařízení s Microsoft Exchange Serverem – což je výhodou jednoho výrobce obou součástí. Z toho důvodu jako platformu jsem zvolil operační systém Microsoft Windows Mobile. Tento operační

systém již od roku 2003, tj. od verze Microsoft Windows Mobile 2003, umožňuje vzdálenou synchronizaci se serverem přes protokol TCP/IP pomocí nástroje, který je integrován přímo v operačním systému – Microsoft ActiveSync. To je jedna z podmínek, kterou musíme při výběru koncového zařízení zohlednit. Proto navrhuji využití operačního systému Microsoft Windows Mobile 2005 a výše. Vybrali jsme si operační systém, zjistili jsme potřeby uživatelů – nyní můžeme přejít k již samotnému výběru zařízení. Při samotném výběru koncového zařízení je ale nutné přihlédnout i ke kvalitě samotného výrobce a úrovni následné podpory. Je nutné, aby výrobky byly spolehlivé, kvalitní a v případě, že se přece jen nějaký problém objeví, aby byl dodavatel schopen problémy co nejlépe řešit. Např. velmi rychle uvolňovat opravné balíčky, poskytovat ovladače, dodávat v krátkých termínech náhradní díly a nebo řešit reklamace. To jsou oblasti, které nás zajímají z pohledu toho, že musíme koncovým uživatelům nabídnout i skutečně kvalitní podporu. Řešení musí zohlednit nejen samotnou prvotní dodávku zařízení, ale i následnou podporu z hlediska IT. Ideálním postupem je nejdříve dohodnutí si podmínek podpory s uživateli, a na základě toho vyjednat podmínky s dodavatelem. Cílem v této fázi je i to, aby s uživatelem byly definovány termíny na odstranění případných závad, které musíme umět dodržet. Možnost je dohodnutí takových lhůt u dodavatele nebo případně vytvoření nějaké rezervní zásoby těchto zařízení. Každopádně vždy bychom se měli snažit dodržet termíny požadované ze strany zákazníka a k tomu přizpůsobovat dodací podmínky a velikost havarijních zásob. V tuto chvíli si může rovnou říci, že se nám okruh potenciálních výrobců značně snižuje a zůstávají nám pouze značkoví výrobci, např. HP, Fujitsu-Siemens, Acer, Asus atd. Musíme si uvědomit, že nějakým zásadním způsobem se dále výrobci od sebe již neliší, co se týče výbavy je téměř každý model srovnatelný s druhým. Jedná se zkrátka o segment, kde je malý prostor na odlišnost a je zde nepřeberná nabídka přístrojů. V tuto chvíli přicházejí ke slovu již ne zcela pro každého logické argumenty – mající vliv na celkovou cenu řešení. V takových situacích, kde již konečný výběr dodavatele nemá zásadní dopad na kvalitu produktu, je pro společnost cenově výhodnější rozšířit již nějaké stávající výběrové řízení nebo kontrakt o tento produkt. Dojde tak k tomu, že se zvedne celkový objem garantovaného odběru dodavateli, na což může dodavatel příznivě zareagovat cenou. O to je to zajímavější, když se namísto lokálního výběru PDA pro ČR rozhodnete využít již uzavřeného celosvětového kontraktu RWE na dodávku PC a notebooků s jedním dodavatelem – HP. Taková situace ale nenastává vždy, že by mohl výběr PDA být ponechán pouze cenovému srovnání. Teď trochu předběhnu a dopředu uvedu, že třeba v rámci dalších řešení v rámci této diplomové práce – tj. kapitola č.3 - „Sběr odečtů“ a kapitola č. 4 - „Mobilní pracovní příkazy“, bude situace jiná a ukážeme si naopak to, jak technické požadavky převáží faktor ceny.

HP iPAQ HW 6915

HP iPAQ RW 6815

HP iPAQ HX 2790

HP iPAQ RX 5900

Obrázek č.1: Ukázka PDA zařízení společnosti HP

Řešení - výrobce a dodavatel = HP (globální dodavatel PC a notebooků pro RWE) - operační systém – Microsoft Windows Mobile 2005 a vyšší (ActiveSync přes TCP/IP) - konkrétní možné modely (detailní specifikaci naleznete v kapitole č. 6 - přílohy) HP iPAQ hx2790 HP iPAQ hw6915 HP iPAQ rx5900 HP iPAQ rw6815 - dodací lhůty na nákup nových zařízení = 2 dny - lhůty na provedení záručních a pozáručních oprav = 5 dní - rezervní zásoba koncových zařízení = 5 % z celkového počtu (odhad cca 12ks z 250ks) - zajistit dodržování nákupu pouze definované množiny zařízení vnitřními přepisy společnosti (IT standard pro oblast kapesních počítačů – součást interních směrnic RWE) 2.4.3

Synchronizace se serverem

Součástí operačního systému PDA bývají i synchronizační nástroje, které nám slouží k přenášení informací mezi PDA a PC. Trendem poslední doby je ústup od synchronizace pomocí synchronizačních kolíbek, kabelů nebo přenosů na krátké vzdálenosti – tj. IrDA či Bluetooth. Začíná se stále více využívat toho, že PDA zpravidla již mají integrován i GSM/GPRS modul, a tím jsou schopny fungovat jako plnohodnotný mobilní telefon. Poslední verze synchronizačních nástrojů Microsoft ActiveSync jsou přímo integrovány do operačního systému Microsoft Windows Mobile 2003 a vyšších verzí, a umožňují právě synchronizaci poštovních zpráv, schůzek kalendáře a kontaktů přes GSM/GPRS spojení – přes TCP/IP spojení. Jelikož jsme toto hledisko již zohlednili v předchozí části, při výběru operačního systému kapesních počítačů, nebudeme zde opakovat to, co již zaznělo v předchozí části. V rámci této části bych však rád zmínil řešení, které bylo využíváno v minulosti před příchodem Windows mobile 2003 a které by mohlo být alternativou pro projekty, kde by nebylo z nějakého důvodu možné využívat Microsoft Windows Mobile 2003 a vyšší. Touto alternativou je řešení od společnosti O2 Telefónica – kdysi nazývané Eurotel Office Connector. Krátce si vysvětleme princip fungování tohoto řešení. Jednalo se o dvě části – serverovou a klientskou. Klientská část spočívala v instalaci aplikace, která se uměla připojit do sítě internet pomocí GSM/GPRS spojení a pomocí tohoto spojení synchronizovat data, stejně jako pomocí synchronizační kolébky (alternativa za dnešní ActiveSync). Naopak serverová část byl doplněk zákazníkova poštovního serveru, byl poskytován operátorem Eurotel v rámci této služby, jako nedílná součást, a nedělal nic jiného, než export a import dat jak směrem k poštovnímu serveru, tak směrem do

GSM/GPRS sítě kapesnímu počítači. Pro větší společnosti, které mají svůj poštovní server toto byl zbytečný mezičlánek, pro obyčejné uživatele, kteří chtěli tuto službu využívat soukromě a nebo neměli k dispozici vlastní poštovní server, toto bylo velmi elegantní řešení. Toto řešení v minulosti práve eliminovalo absenci nového Microsoft ActiveSyncu a jako první umožňovalo vzdálenou synchronizaci kapesního počítače s poštovním serverem. S příchodem Microsoft Windows Mobile toto řešení ustupuje, neboť nutnost dodatečné instalace jak na straně klienta, tak na straně serveru, se stává jeho velkou nevýhodou. Pokud využíváte platformu Microsoftu je úplná integrace tohoto řešení jak do operačního systému v kapesním počítači, tak do poštovního serveru. Jelikož je operační systém uložen přímo v ROM paměti kapesního počítače, není třeba žádná dodatečná instalace. V případě, že nechcete využívat platformu Microsoftu na kapesním počítači, nebo pokud nedisponujete vlastním poštovním serverem, je pro Vás stále přijatelnou alternativou využití řešení operátorů mobilních služeb – tzv. Office Connector. A jaké jsou nejvýznamnější přínosy v tom, že se zavádí vzdálené synchronizace dat? Především to je komfort, s jakým synchronizace probíhá, a rychlost, s jakou máte okamžitě k dispozici aktuální stav. Uveďme si to na krátkém příkladu toho, jak funguje spolupráce manažera s jeho asistentkou v případě, že je mimo kancelář. Má v kapesním počítači aktuální stav svého kalendáře, poštovní schránky i kontaktů. Potká se s novým klientem, se kterým si chce rovnou dohodnout schůzku, vzít si na něj veškeré kontakty a případně mu poslat na schůzku v předstihu nějaké materiály. Kdysi by toto musel řešit telefonicky se svou asistentkou, která jako jediná znala jeho aktuální denní program. Ta mohla fungovat jako prodloužená ruka a všechno toto zajistit za manažera, ale formou toho, že toto udělala za něj v kanceláři. Novým trendem je to, že manažer se sám podívá do svého kalendáře a naplánuje si schůzku. Okamžitě po synchronizaci toto ví i jeho asistentka, tudíž mu nemůže nevědomky naplánovat jinou aktivitu v tutéž dobu. Rovněž není nyní problém pro manažera přijmout namísto papírové vizitky vizitku elektronickou, pomocí technologie Bluetooth či přes GSM síť ve formě SMS zprávy. Jakmile má tento kontakt, může okamžitě z kapesního počítače odeslat e-mail s požadovanými podklady. To vše je nyní schopen udělat přímo při krátkém setkání s partnerem mimo kancelář. Podobné nástroje se stávají nezbytné pro opravdu efektivní fungování a dobrý Time Management. Řešení Jelikož vše potřebné bylo již zohledněno při výběru koncového zařízení, pouze zrakapitulujeme - využít součásti operačního systému Microsoft Windows Mobile 2005 a vyšší (nástroj Microsoft ActiveSync s podporou komunikace přes TCP/IP)

2.4.4

Kancelářské aplikace (PIM aplikace)

Pod pojmem PIM aplikace si můžeme představit aplikace pomáhající nám organizovat náš čas, práci a kontakty. Jsou to přesně ty funkce, které se začínají na straně stolních počítačů integrovat do poštovního klienta – např. Microsoft Outlook nebo ThunderBird. V kapesních počítačích jsou to zcela zvláštní aplikace, úzce spojené se samotným operačním systémem. Jsou zpravidla integrovány v operačním systému, tudíž již při samotném výběru kapesního počítače musíme na toto dbát. Tím, že jsme si již definovali platformu a operační systém, není zde prostor na nějaké zásadní návrhy řešení. Proto si v rámci této části řešení pouze představíme dodávané aplikace. Microsoft Office Word Mobile Aplikace Microsoft Office Word Mobile zahrnuje všechny funkce potřebné k vytváření textových dokumentů – např. obchodních návrhů, konceptů atd. Dokumenty je možné otevírat, zobrazovat a upravovat na cestách po zemi i v letadle. Změny se mohou uložit na mobilní zařízení, odeslat emailem do kanceláře k další kontrole nebo přenést do počítače po návratu do kanceláře. Mezi funkce aplikace patří i kontrola pravopisu, příkazy Najít a Nahradit, odrážkové seznamy, formátování textu a mnoho dalších. Aplikace poprvé zahrnuje i podporu tabulek. Po vytvoření nebo úpravě dokumentu aplikace Word Mobile jej můžete synchronizovat s počítačem, odeslat kolegovi nebo odeslat jako přílohu e-mailu. Microsoft Office Excel Mobile S aplikací Microsoft Office Excel Mobile ve vašem zařízení můžete bez omezení vytvářet nové tabulky nebo upravovat dokumenty vytvořené na stolním počítači, i pokud nejste ve své kanceláři – např. můžete aktualizovat cenové nabídky. Kdekoliv na cestách můžete zpracovávat podklady, vytvářet výpočtové vzorce, kontrolujte údaje o prodeji nebo pouze procházet své osobní výdaje během cesty vlakem. Nejste omezeni pouze na úpravy tabulek a grafů: můžete snadno a rychle vkládat nové listy a tvořit nové grafy. Pokud kopírujete tabulky ze zařízení Pocket PC do stolního počítače, budou automaticky převedeny do verze pro stolní počítač. Microsoft Office PowerPoint Mobile Aplikace Microsoft Office PowerPoint Mobile Vám umožní během cesty pracovat na zlepšení přesvědčivosti vaší prezentace. Můžete např. využít dlouhé cesty k nácviku její představení. Můžete zobrazit celou prezentaci, vyzkoušet si načasování, zkontrolovat pořadí a všechny aktivní odkazy v prezentaci. Komentáře můžete zaslat e-mailem svému týmu nebo je předat pomocí služby MSN Messenger, pokud chcete získat okamžitou reakci. Váš tým může upravenou prezentaci odeslat zpět emailem přímo do vašeho mobilního zařízení. Při předvádění prezentace zákazníkovi oceníte, že jste si ji nejdříve vyzkoušeli. Prezentaci můžete v zařízení nastavit jako časovaný sled snímků. Podporovány jsou i odkazy na adresy URL.

Microsoft Outlook Mobile Aplikace Microsoft Outlook Mobile nabízí nepřekonatelné možnosti přijímání a zasílání zpráv z mobilních zařízení. Známé nástroje aplikace Microsoft Outlook a podpora příloh ve formátech aplikací Microsoft Word, Excel a PowerPoint vám umožní zvýšit produktivitu i mimo kancelář. Většinu zařízení se systémem Windows Mobile můžete nepřetržitě bezdrátově synchronizovat prostřednictvím mobilního operátora nebo Wi-Fi hotspotu. Váš Kalendář, Kontakty a Úkoly budou vždy aktuální. Synchronizaci můžete provést také po návratu do kanceláře. S novou sadou Messaging and Security Feature Pack získáte technologii Direct Push. To znamená, že již nikdy nebudete muset na své e-maily čekat. Zprávy se zobrazí ve vašem mobilním telefonu ve stejný okamžik jako na stolním počítači. Bezdrátová synchronizace umožňuje synchronizovat zařízení s počítačem a pracovat s e-maily během připojení nebo v režimu offline. Microsoft Internet Explorer Mobile Aplikace Microsoft Internet Explorer Mobile umožňuje procházet web online nebo stahovat stránky a číst je v režimu off-line. Ať se rozhodnete pro jakoukoli činnost, tato aplikace byla optimalizována pro rychlá i pomalá připojení, což znamená, že můžete zvolit graficky bohaté stránky, máte-li připojení s dostatečnou rychlostí, nebo pouze textové stránky, pokud máte pomalé připojení. Můžete procházet dopravní informace, vyhledávat aktuality, mapovat situaci na trhu nebo kontrolovat předpověď počasí na následující dny. Můžete vybrat zobrazení celé stránky pouze v jednom sloupci pro snazší procházení.

Obrázek č.2: Ukázka aplikací Microsoft Office Mobile

2.4.5

Bezpečnost

Jak již bylo zmíněno ve specifikaci požadavků z oblasti bezpečnosti, budeme se zabývat třemi základními oblastmi z hlediska bezpečnosti. - zálohování dat – obrana proti nechtěné ztrátě dat z důvodu závad, poruch apod. - zabezpečení dat – obrana proti přístupu k datům a zneužití v případě krádeže zařízení apod. - zabezpečení komunikace – ochrana proti odposlechu komunikace na síťové úrovni Každou hrozbu je nutno řešit zvlášť k tomu určenými nástroji. Pojďme nyní postupně projít každou z oblastí a podrobně si navrhnout, jakými mechanismy budeme hrozby eliminovat na minimum. Zálohování dat Nechtěné ztrátě dat v důsledku poruchy přístroje můžeme předcházet zálohováním (tzv. Backup). K těmto případům může dojít nejen HW poruchou samotného přístroje, ale rovněž i například ztrátou elektrické energie. Je nutné si totiž uvědomit, že kapesní počítače nedisponují datovými úložišti nezávislými na elektrické energii, jako jsou např. pevné či optické disky u počítačů. Přesto i u kapesních počítačů existuje možnost, jak data zálohovat na média nezávislé na zdroji elektrické energie – touto možností je používání paměťových karet. Samozřejmě, že můžeme toto zálohování provádět zcela sami bez nějakého dodatečného programového vybavení tak, že svá data budeme ukládat pouze na paměťovou kartu. Existují však daleko propracovanější zálohovací nástroje, které nám umožní daleko lepší využití a zautomatizování. Příkladem může být např. produkt společnosti Sunnysoft nazvaný BackupManager 4.0. Tento nástroj umí nejen plánování zálohovacích akcí, ale umí spuštění zálohování podmínit i systémovým událostem – touto událostí může být např. nízký stav hlavní baterie. Program sám zareaguje na tuto událost provedením kompletní zálohy. Dalším přínosem tohoto řešení je to, že se nezálohují pouze uživatelská data, ale je možné zálohovat i individuální nastavení operačního systému až na úrovni instalovaných aplikací a nastavení v registru Windows. Máme-li takto provedenou zálohu, můžeme pouhým vložením paměťové karty do jiného obdobného přístroje obnovit prostředí, které jsme měli před zálohováním. Není k tomu třeba nějakých technických znalostí, záloha je ve formě samorozbalovacího souboru a tak si obnovu může provést sám uživatel kdekoliv bez asistence technika. Kontrola přístupu a šifrování dat Další důležitou oblastí v bezpečnosti je kontrola přístupu a šifrování dat. Tyto nástroje mají jediný účel. Když už dojde k fyzickému odcizení zařízení nebo zkopírování dat z paměťové karty, musí zamezit jejich neautorizovanému použití. Data je nutné chránit před jejich možným zneužitím. Pro tuto oblast zabezpečení jsme zvolil produkt SafeBoot Enterprise. Je to účinný nástroj, který využívá tzv. dvousložkovou předbootovací identifikaci. Stručně si vysvětlíme, o co se jedná. Před tím, než je možné nabootování operačního systému, je nutné se identifikovat. Identifikace se provádí na základě

dvou údajů. Prvním je něco, co známe, druhým je něco, co vlastníme. Pod pojmem něco, co známe, si představme klasické zabezpečení pomocí PINu – je to zpravidla krátké čtyřmístné číslo, které se využívá např. u mobilních telefonů či bankovních karet. Bohužel toto zabezpečení samo o sobě nestačí – PIN je možné odhalit podrobným sledováním při jeho zadávání, popř. ho lze získat i nechtěným či vynuceným prozrazením. Proto je zde i druhá část identifikace, která je založena na vlastnictví druhé, nezbytné části identifikace. Hojně se využívají tzv. RSA klíčenky, které v pravidelných intervalech generují zpravidla 6-ti až 8-mi znakové heslo. Nebudeme si zde popisovat podrobněji princip, jakým tyto technologie (AES-256 a RSA PC5-1024) fungují, neboť by toto zajímavé a velmi obsáhlé téma bylo samo o sobě na diplomovou práci. Spokojíme se pouze s vysvětlením základního principu dvousložkové předbootovací identifikace. Aby mohlo dojít ke zmíněnému zneužití dat, jsou nutné zajistit tři věci současně – fyzické vlastnění dat (kapesní počítač nebo paměťová karta), znalost PINu a vlastnictví bezpečnostní Smart Karty (automatický generátor druhé části identifikace). Dalšími nástroji, které se v této oblasti začínají objevovat, jsou vzdáleně vyvolávané sebedestrukční mechanismy. Existují již taková řešení, která v případě ztráty přístroje umí zajistit to, že prostřednictvím odeslané SMS zprávy z konkrétního určeného telefonního čísla dokáží v přístroji vyvolat smazání uživatelských dat. Samozřejmě, že žádné řešení nezabrání zneužití zcela na 100%, snahou je však redukovat potencionální rizika na přijatelnou úroveň, která pak spíše hraničí s nepravděpodobnou teoretickou možností, než s potencionálním rizikem.

Obrázek č.3 – Srovnání obyčejné identifikace a dvousložkové předbootovací identifikace

Zabezpečení komunikace Pro zabezpečení samotné komunikace se nám nabízejí velmi silné nástroje, kterými můžeme hrozby odposlechů datové komunikace zredukovat na přijatelné minimum. V první řadě si musíme dopředu objasnit, jakým stylem budeme řešit přístup k intranetu a internetu. Primárně budeme umožňovat kapesním počítačům pouze přístup prostřednictvím VPN spojení do firemního intranetu. Toto spojení budeme využívat jako jediné, případný přístup na internet budeme řešit kontrolovaným přístupem z vnitřní sítě RWE přes Proxy Server a FireWall. Obrácená varianta, kdy bychom primárně přistupovali do internetu a pouze pro přístup do vnitřní sítě bychom navázali VPN spojení, se sice může zdát jednodušší, ale z hlediska potencionální hrozby méně vhodná. Výhodou námi navrženého řešení je i to, že v kapesním počítači musí být nastaveno pouze jedno VPN připojení, což zjednodušuje administraci přístrojů. Navázání VPN připojení je umožněno přímo v operačním systému – jsou nabízeny dva základní způsoby – PPTP a IPSec. Jako další mechanismus, který navrhuji implementovat v rámci zajištění vyšší bezpečnosti komunikace je využití privátního přístupového bodu v rámci GSM sítě. Toto jsou služby, které poskytují samotní operátoři mobilních telekomunikačních služeb a spočívají na jednoduchém principu. Na úrovni GSM oddělí Vaši komunikaci od komunikace ostatní, čímž zase snižujete prostor potencionálních útoků. Nebudeme zabíhat do detailů tohoto řešení, pouze si objasníme princip, aby byl patrný jeho přínos. Toto zabezpečení se řeší na úrovni GSM – definuje se omezená skupina SIM karet, kterým se pro datovou komunikaci vyčlení samostatný komunikační kanál. Tento kanál pak není z GSM sítě vyveden do internetu, ale přímo do demilitarizované zóny zákazníka – tzv. DMZ. Tím je docíleno toho, že není možno zneužít „odposlechu“ na úrovni GSM/GPRS, ani na úrovni následné internetové komunikace mezi operátorem a zákazníkem. Tyto produkty nabízí společnost O2 Telefónica pod názvem OnePort a společnost T-Mobile pod názvem Direct. Řešení - všechna PDA budou vybavena paměťovými kartami o velikosti 2 GB (SD, CompactFlash) - součástí všech PDA bude software pro automatický backup dat - zálohování (produkt Sunnysoft Backup Manager 4.0 - nastaven na zálohování při poklesu energie na 10 %) - součástí všech PDA bude software pro dvousložkovou předbootovací identifikaci - zabezpečení (produkt SafeBoot Enterprise pro PDA – stejné řešení bude použito i pro notebooky) - bude zřízeno samostatný přístupový bod pro přístup ze sítě GSM do sítě RWE – privátní linka (APN pro přístup z GSM a přímý komunikační kanál mezi operátorem a RWE) - všechna PDA se budou připojovat pomocí APN RWE do demilitarizované zóny (tzv. DMZ) (v rámci DMZ budou mít přístup k intranetu a přes proxy server a firewall i do internetu) - všechna PDA budou mít zakázán jakýkoliv jiný způsob připojení (přímo do internetu) (omezením služeb poskytovaných operátorem na konkrétních SIM kartách)

Internet

GSM

APN

Firewall Mobilní operátor

APN (RWE)

Firewall

Direct / OnePort (přímé spojení)

Firewall RWE pracovník

RWE Demilitarizovaná zóna (DMZ)

RWE – vnitřní síť

Mail Server Datové centrum

Obrázek č.4: Komunikační schéma – Mobilní kancelář

2.4.6

Další využití elektronické pošty v kapesních počítačích

Uvědomuji si, že v této oblasti jsem svým návrhem nepřinesl z pohledu použitých aplikací nic zásadního. Těžko bychom vymýšleli něco nového, co ještě nebylo implementováno a co by nešlo řešit jiným způsobem. O to více jsem se v této části návrhu soustředil na zabezpečení. Nyní si ale ukážeme na jedné opravdu praktické ukázce to, jak lze například využít pouhého poštovního klienta k aktivní komunikaci s informačním systémem. Pro naši ukázku jsem si zvolil jednu z významných činností, kterou provádí naše cílová skupina uživatelů – manažeři. Je to elektronické schvalování dokumentů v rámci definovaných WorkFlow v DMS (Document Management System). Tento systém slouží pro zefektivnění, zrychlení a zpřehlednění oběhu dokumentů uvnitř společnosti. Definovaná WorkFlow korespondují s vnitřními předpisy a podpisovým řádem společnosti RWE. V rámci těchto WorkFlow lze řešit i dočasné zástupy v nepřítomnosti, případně automaticky navrhnout mechanismy upomínání či předání jinému schvalovateli, v případě, že oslovený včas nereagoval. V rámci RWE je jednotným informačním systémem SAP, v rámci kterého bylo implementováno i řešení společnosti SAP pro oběh a schvalování dokumentů (smluv, požadavků a objednávek). Systém SAP je obecně velmi dobře přizpůsobivý (tzv. nastavitelný). Jedná se o jeden z mála systémů, který má otevřené rozhraní pro změnu grafického uživatelského rozhraní (GUI), má vlastní programovací jazyk (ABAP) a prostředky pro tvorbu nových uživatelských modulů a definici vlastních datových rozhraní (např. do aplikací a systémů mimo SAP). Implementací samotného DMS se zjednodušil proces schvalování – odpadlo fyzické obíhání dokumentů, celkově se však stalo to, že došlo k drobnému nárůstu doby, kterou dokument probíhal schvalovacím kolečkem. Jednou z příčin bylo to, že schvalování vyžadovalo provedení několika akcí přímo v systému SAP, což nepodporovalo mobilitu schvalovatelů. Z tohoto ohledu nepřinesl nový systém žádné výrazné zlepšení. Proto bylo provedeno následující – DMS bylo rozšířeno o funkci rozesílání výzev ke schválení a následnému přijetí akceptací či zamítnutí, vše prostřednictvím elektronické pošty. Součástí příchozích zpráv jsou dokumenty, ke kterým se schvalovatel vyjadřuje. A nyní již asi chápete ten obrovský význam mobilní kanceláře, která se tak stává urychlující prvkem celého řešení. Někdo může namítnout, že to je sice drobnost, ale mnohdy právě v těchto drobnostech jsou velmi efektivní a přitom levná řešení.

Návrh řešení - využít PDA k provozování aplikací a systémů založených na elektronické poštovní komunikaci (např. schvalování v systému DMS) - úprava všech stávajících internetových a intranetových aplikací i pro zobrazení na PDA (možnost využití přístupu do vnitřní sítě – intranet, webové rozhraní informačních systémů apod.) - implementace nových systémů s možností webového rozhraní pro PDA (Business Datawarehouse nad systémem SAP, intranetové katalogy pro objednávání, atd.)

2.5 Zhodnocení Zhodnoťme si nyní tuto část implementace řešení pro manažery – mobilní kancelář. Rovnou je třeba si uvědomit, že tato část návrhu řešení nebyla zaměřená na nějaké hledání zásadních ekonomických úspor, šlo zde o vytvoření řešení pro mobilní přístup k datům, které spíše zkvalitní úroveň práce uživatelům. Povedlo se nám vytvořit si nezbytný základ pro další dvě oblasti řešení, ve kterých jsme se již zabývali konkrétnějším využitím na úrovni aplikační. V případě dočasného řešení pro oblast sběru odečtů se nám hodilo řešení mobilní kanceláře, které znamenalo úsporu oproti dosavadnímu řešení, aniž bychom něco výrazně museli řešit. Pro manažery RWE se nám podařilo navrhnout komfortní a ucelené řešení, které umožňuje efektivní fungování v každodenním pracovním životě. Dali jsme tak reálnou podobu pojmu „mobilní kancelář“.

Navrhl jsem řešení … z hlediska finančních úspor - šetřící výrazným způsobem čas manažerů z hlediska procesní optimalizace - umožňující schvalování smluv a objednávek v DMS pomocí e-mailové komunikace - sloužící jako základ pro další řešení postavená na principu komunikace e-mailem - sloužící jako základ pro další řešení postavená na principu intranetové aplikace z hlediska zvýšení kvality - efektivně využívající přístup k datům kdykoliv a kdekoliv - umožňující uživatelům neomezovat se na prostředí kanceláře

KAPITOLA 3.

ŘEŠENÍ – ČÁST II. Podpora odečítačů Sběr odečtů

3.1


3.2

Specifikace cíle

3.3


3.4

Návrh řešení

3.5

Zhodnocení

3.1 Úvod do problematiky – Sběr odečtů Trendem dnešní doby je elektronické pořizování dat, jejich elektronický přenos a s tím spojené řešení zabezpečení. Pomalu ustupuje papírový sběr dat, který je ve srovnání s elektronickým výrazně pomalejší, ale je zejména i zdrojem mnoha chyb. Proto jsme si jako druhou oblast implementace vybrali klasického představitele aplikace zajišťující sběr dat, kterou je pořizování odečtů spotřeb plynu. Proces, jakým probíhá sběr odečtů spotřeb plynoměrů není jednoduchý, proto než přistoupíme k samotné specifikaci zadání na vytvoření aplikace, tak se pokusíme celý proces vysvětlit. Nejdříve je ale nutné uvést, že se poměrně výrazně liší způsob sběru odečtů pro zákaznické kategorie MO/DOM (maloodběratelé a domácnosti) a pro zákaznické kategorie VO/SO (velkoodběratelé a střední odběratelé). Oba tyto případy si podrobně popíšeme, aby bylo zcela zřejmé, v čem se liší a jaký má tento rozdíl dopad na navržené řešení. Popišme si tedy první skupinu – MO/DOM. Jedná se o zákazníky, kteří plyn využívají v domácnosti na vaření případně i pro potřeby vytápění domu. Jsou to zákazníci s tzv. ročním fakturačním cyklem – tj. jednou za rok se jim musí vystavit faktura na základě zjištěného stavu plynoměru a údaj o spotřebě odpovídá spotřebovanému plynu za předchozí období 1 roku. Aby mohla být vystavena faktura, je nutné nejdříve získat hodnotu udávající spotřebu z plynoměru. Jak asi tušíte, nebylo by v lidských silách toto uskutečnit vždy v jeden okamžik. Přiměřený počet těchto odečtů je cca 100 – 200 / 1 den / 1 odečítače. Samozřejmě velmi záleží na lokalitě – snáze se provádí odečty ve větších městech – např. v panelácích, kde na jednom místě jsou desítky odběratelů. Naopak nejhorší situace je v řídce osídlených pohraničních oblastech. Každopádně všichni odběratelé jsou rozdělení do logisticky optimalizovaných celků, do tzv. odečtových tras. Samotný návrh těchto tras je velmi složitý proces, který se provádí jednou za 3-5 let, a byl by jistě jako dobrý námět pro nějakou optimalizační úlohu. Pro potřeby našeho projektu budeme toto považovat za zajištěné. Druhá skupina se od předchozí liší v četnosti návštěv a v množství odečtů. Vysvětlíme si rozdíl podrobněji. Kategorie zákazníků VO/SO je fakturována pravidelně měsíčně na základě skutečných stavů. Zatím co nám u předchozích stačila jedna hodnota, zde musíme přenést hodnoty pro každý den. Tato kategorie je totiž specifická v tom, že si dopředu smluvně objednává kapacitu sítě na každý den zvlášť a za výrazné nečerpání nebo výrazné překročení těchto limitů je zákazníkovi fakturováno ještě tzv. penále za nedodržení smluvního odběru. Pozornému čtenáři se jistě v hlavě zrodí dotaz, jak se tedy tyto denní odečty získávají – každý den někdo kontroluje stav počítadla? Naštěstí tomu tak není. Přestože je zde rovněž plynoměr pouze s jedním počítadlem a bez paměti, přesto je možné získávat i

tzv. hodinové odečty. Technicky je toto zajištěno tak, že je každý plynoměr osazen ještě dodatečným elektronickým zařízením - tzv. přepočítávačem. Plynoměr pak vysílá elektronické impulsy do přepočítávače, který monitoruje spotřeby v reálném čase a ukládá si je do své paměti. Pro naši potřebu je nutné získávat konečný stav ke každému dni. Přenos těchto hodnot je z přepočítávače možný buď přes rozhraní RS232 a nebo přes IrDA rozhraní. Nyní, když jsme si objasnili rozdíl v těchto dvou typech odečtů, podívejme se blíže na práci samotného odečítače, který proces vykonává. Tento pracovník obdrží každý den soupis odběrných míst, která je nutno odečíst. Odběrným místem je chápána bytová jednotka či rodinný dům, může to být ale i nějaký výrobní podnik, využívající plyn k výrobě. Jakmile obdrží odečítač tento soupis práce – nazývaný odečtový list – může vyrazit do terénu. Každý odečtový list obsahuje podrobné informace i odběrném místě. Jsou k dispozici základní údaje o majiteli odběrného místa, o adrese, umístění v rámci objektu, o identifikačním čísle plynoměru a o jeho typu. S těmito údaji v ruce pořizuje hodnoty z plynoměrů, které se pak zpět dostávají do systému, který na základě pořízených hodnot vypočte spotřebu a vystaví odpovídající fakturu. Všimněte si, že doposud jsme se snažili si celý proces vysvětlit bez toho, aniž bychom uváděli technologie, jaké k tomu odečítač používá. Je totiž značně rozdílná situace v rámci všech distribučních společností koncernu RWE. Zatímco někde zajišťovali tuto službu pomocí papírových podkladů, jinde již několik let úspěšně provozovali aplikaci založenou na technologii WAPu. Toto si ale blíže představíme až v rámci mapování dosavadního vývoje řešení.

3.2 Specifikace cíle Jak jsme si zmínili již v úvodu této kapitoly, je nutné rozlišovat dva základní typy odečtů a s tím spojené dva odlišné procesy. Samozřejmě, že naší snahou bude tyto rozdíly v maximální možné míře eliminovat a navrhnout tak pokud možno co nejuniverzálnější řešení. Pojďme si tedy vyspecifikovat požadavky na obě dvě části řešení společné. Základním požadavkem tohoto řešení je to, aby systém spolupracoval se zákaznickým informačním systémem, kterým je systém SAP IS-U. V tomto systému jsou uložena veškerá data o odběrných místech, o odběratelích, o měřících přístrojích, o historii odečtů a spotřeb, o fakturovaných částkách a platební bilanci zákazníků. V krátkosti si řekněme, že je to systém, ve které je vše nezbytné týkající se činnosti společnosti RWE s prodejem plynu koncovým zákazníkům.

3.2.1

Plánování odečtových tras

Součástí našeho řešení musí být modul, umožňující plánování odečtových tras. Co si pod tímto představit? Musíme být schopni rozvrhnout práci odečítačům do tzv. itinerářů a tyto itineráře jim musíme mít možnost naplánovat na konkrétní den. Tento modul nazvěme modul plánování či přípravy odečtových tras – itinerářů. Zde stojí za zmínku jeden rozdíl – zatím co odečty MO/DOM probíhají postupně každý pracovní den – plánují se na každý den, odečty VO/SO probíhají vždy na konci kalendářního měsíce, tudíž probíhají nárazově. Vstupem

seznam odčítačů, seznam odečtových tras.

Výstupem

přiřazení odečtových tras konkrétním odečítačům na konkrétní dny.

3.2.2

Příprava podkladů

Tato fáze se odlišuje v závislosti na typu odečtu. Nejprve si řekneme, jak toto probíhá u odečtů MO/DOM, poté si stejnou fázi popíšeme pro odečty VO/SO. Kategorie MO/DOM V rámci přípravy podkladů musí každý odečítač obdržet týden dopředu rozpis práce. Důvodem tohoto předstihu je to, aby mohl v dostatečném předstihu obejít odečtovou trasu a vylepit informaci o termínu, v jakém bude odečet probíhat. Toto je nezbytné, protože na rozdíl od odečítačů zjišťující spotřebu elektrické energie, odečítači plynu nemají možnost přístupu k měřidlům mimo bytovou jednotku, jak je tomu v případě elektroměrů – ty jsou zpravidla umístěny na chodbě. Jakmile je tato příprava provedena, může nastat samotný proces odečtů.

Vstupem

plán itinerářů na období jednoho týdne dopředu.

Výstupem

oznámení termínu odečtů odběratelům, příprava na realizaci odečtů.

Kategorie VO/SO Příprava podkladů pro odečty kategorie VO/SO je jednodušší. Probíhá pravidelně každý měsíc, nedochází v plánování k takovým změnám, jako u první kategorie. Zpravidla každý odečítač má svůj itinerář, který pravidelně objíždí. Vstupem

itinerář odběrných míst, která je nutno odečíst v rámci odečtové trasy.

Výstupem

příprava na realizaci odečtů.

3.2.3

Pořízení odečtů

Nyní nastává samotná fáze odečtů. Rovněž musíme zvlášť popsat oba typy odečtů. Kategorie MO/DOM Odečítač vyrazí do terény dle předem naplánované odečtové trasy. Postupně navštěvuje jedno odběrné místo za druhým a pořizuje data o odečtech. K dispozici má základní přehled o odběrných místech. Zná osobu, na kterou je odběrné místo evidováno, přesnou adresu odběrného místa, číslo bytové jednotky v rámci panelového domu, číslo a typ osazeného plynoměru, odhadovaný rozsah, v jakém by se měla spotřeba pohybovat, pokud by odběratel zásadně nezměnil charakter spotřeby. Dalším údajem je i dlužná částka, kterou odběratel případně dluží. Zatím co předchozí údaje jsou nám pochopitelné k samotnému určení místa odběru a ověření správnosti měřidla. Údaj o výši dluhu však již není k samotným odečtům nezbytný. Vychází to spíše z reálných zkušeností, kdy řada domácností je ochotna uhradit dluh na místě, neboť je pro ně problematické uhrazení dluhu jinou formou – např. starší lidé v méně zalidněných oblastech nevyužívající tak hojně služeb bankovních úřadů. Rozšíření těchto služeb bylo spíše jako vstřícný krok směrem k odběratelům. Řešení, které je cílené na ryze neplatící odběratele bude popsáno v třetí části návrhu řešení. Nezapomeňme ještě na jednu důležitou věc v rámci řešení sběru odečtů. Při samotných odečtech plynoměrů může odečítač zjistit nějakou závadu měřidla, nesoulad čísel z evidence se skutečností, případně může mít nějaké podezření na černý odběr. Tuto informaci může předat zpět do systému, který na základě těchto věcí automaticky vygeneruje pracovní příkaz pro technika, ve kterém ho vyzve k provedení konkrétní činnosti. Vstupem

veškeré údaje o odběrném místě, klientovi, měřidle a dluhu.

Výstupem

pořízení odečtu, zjištění anomálií na odběrném místě a případné inkaso dluhu

Kategorie VO/SO Odečítač vyrazí do terény dle předem naplánované odečtové trasy. Postupně navštěvuje jedno odběrné místo za druhým a pořizuje data o odečtech. K dispozici má základní přehled o odběrných místech. Zná odběratelskou firmu, na kterou je odběrné místo evidováno, přesnou adresu odběrného místa, číslo a typ osazeného plynoměru, číslo a typ osazeného přepočítávaje a odhadovaný rozsah, v jakém by se měla spotřeba pohybovat. Jakmile navštíví konkrétní odběrné místo, provede pořízení odečtů. Zde se trochu podrobněji podíváme na technologii přenosu odečtů. Plynovodní soustava je i zde osazena klasickým plynoměrem, který má analogový ciferník. Jak jsme si zmínili dříve, u tohoto segmentu odběratelů nás zajímá spotřeba denní, nikoliv celková za měsíc. Proto se ke každému plynoměru připojuje elektronické zařízení nazývané přepočítávač, jehož jedinou funkcí je uchovávat častější mezistavy – až na úroveň hodinových odečtů. Celá tato soustava plynoměru a přepočítávače funguje tak, že rotační plynoměr reaguje na proudící plyn buzením impulsů, které jsou přenášeny do přepočítávače. Z přepočítávače probíhá přenos odečtů do kapesního počítače bezdrátovým připojením. Je zde využita technologie připojení pomocí infračervených paprsků (IrDA). Zjistí-li odečítač při odečtech nějaký jednoduchý problém, může ho na místě odstranit. Tyto odečty totiž provádějí speciální montéři, kteří mimo dny odečtů provádějí instalace, výměny a demontáže plynoměrů a přepočítávačů. Podobně jako u odečtů MO/DOM i zde má možnost odečítač/montér pořídit dodatečné záznamy o anomáliích na odběrném místě, které zajistí automatické vygenerování pracovního příkazu pro montéra údržby. Vstupem

veškeré údaje o odběrném místě, klientovi, měřidle a přepočítávači.

Výstupem

pořízení odečtů a zjištění anomálií na odběrném místě.

3.2.4

Přenos informací do informačního systému

Tato fáze má za úkol jediné – přenos dat zpět do zákaznického informačního systému. Záměrně si zde proces popisujeme co nejobecněji, aby nám byl srozumitelný. Nesnažím se v této fázi mapovat dosavadní použité technologie, ani se nesnažím již zde v této fázi uvádět svůj návrh řešení. To bude až ve fázi návrhu řešení. Vstupem

naplněný itinerář odečty, případně i anomáliemi.

Výstupem

pořízení těchto dat do zákaznického informačního systému.

3.3 Analýza současného stavu Zmapování doposud používaných technologií rozdělíme opět na dvě části, podle typu odečtů. Nejdříve si vysvětlíme vývoj aplikace pro sběr odečtů MO/DOM a poté se vrhneme na složitější část, odečty VO/SO. 3.3.1

Odečty MO/DOM

Provedeme si nyní analýzu toho, jaká řešení pro danou oblast v RWE existovala. Byla to pouze dvě řešení: - řešení tzv. papír / tužka – bez využití moderních nástrojů IT - řešení WAP odečtů (součást OpenSGC) od Soluziony – implementováno v SČP, STP, VČP a ZČP Obě tato řešení si nyní detailněji projdeme a probereme jejich klady a zápory. V rámci tohoto zhodnocení se pokusíme zmínit vždy slabá místa těchto řešení, aby mohly být v rámci nového návrhu tyto nedostatky odstraněny. Řešení tzv. „papír / tužka“ První řešení bylo založeno na papírové podobě všech podkladů, na ručním vyplňování prázdných odečtových listů a následném ručním přepisování všech shromážděných hodnot do zákaznického informačního systému dle zpět doručených protokolů. V některých společnostech se k těmto aktivitám najímali nárazově brigádníci z řad studentů, kteří nejen vyráželi do terénu odečty sbírat, ale poté je případně i pořizovali do zákaznického informačního systému. Jistě uznáte, že i přes poměrně levnou pracovní sílu v podobě studentů / brigádníků, toto řešení nebylo vůbec efektivní. Způsobovalo spoustu chyb v systému, znamenalo i delší dobu samotného trvání procesu – od naplánování itineráře, až po vystavení faktury odběrateli za vypočtenou spotřebu. Tato oblast si žádala nějaké moderní řešení. Zde asi tušíte, že z tohoto řešení nelze nic zásadního při novém návrhu využít, proto pojďme rovnou ke zhodnocení:

Zhodnocení řešení tzv. „papír / tužka“ +

nezávislé na technice – vysoká spolehlivost řešení – nulové výpadky řešení

-

nízký komfort při pořizování dat – spousta ručního psaní

-

zdroj častých chyb

-

pomalé zpracování

-

vyšší náklady na dopravné a na papír

-

neefektivní z hlediska pracovních sil

-

nemožnost přeplánování během dne, jakmile odečítač vyrazí do terénu

Jak je z předchozího výčtu výhod a nevýhod patrné, nemá cenu se přínosem tohoto způsobu řešení pro případně nový návrh zabývat. Přistupme tedy k druhé variantě, která byla implementována. Řešení WAP odečtů (SČP, STP, VČP a ZČP - Soluziona) Druhá z variant byla na zakázku vytvořená aplikace pro mobilní telefony podporující WAP technologii a GPRS přenosy. Toto řešení se implementovalo v SČP, STP, VČP a ZČP jako modul zákaznického informačního systému OpenSGC. Jelikož jsem měl vedení projektu implementace tohoto řešení v SČP na starosti, můžeme si s odstupem času velmi fundovaně zhodnotit zkušenosti, na tomto projektu získané. Pojďme si tedy celý projekt zhodnotit. Zejména je nutné hned na začátku zdůraznit, že tento projekt byl navržen tak, aby komunikoval s původním zákaznickým systémem OpenSGC od dodavatele Soluziona. Jelikož došlo ke sjednocení informačních systémů a jejich náhradě novým systémem, zákaznickým systémem SAP IS-U, není možné toto popisované řešení nadále využívat v té podobě, jaké bylo. Předně si musíme říci, že při realizaci takovýchto projektů je velmi nutné důkladně provést prvotní analýzu a to nejen z hlediska financí, ale i z hlediska případných dopadů na počet pracovních míst. Obecně platí, že při implementaci těchto řešení musí být zákazník, např. v tomto případě ředitel úseku měření a odečtů, rozhodnut pro implementaci podobného řešení. Bez spolupráce příslušného úseku není možné celý projekt zdárně realizovat. O to horší situace je, pokud vyčíslení návratnosti a úspor projektu není založeno jen na snížení provozních nákladů (dopravné, papír, energie apod.), ale i na snížení počtu pracovních sil v důsledku optimalizace samotného procesu. Tento fakt zde zmiňuji záměrně, protože v rámci tohoto řešení sehrál významnou roli. Jakmile máme myšlenku pro samotnou realizaci, máme podporu vedení příslušného úseku, můžeme přistoupit k prvotní analýze projektu. V době, kdy jsme toto řešení WAP odečtů chtěli implementovat, nebylo vůbec známo, že dojde ke sjednocení jednotlivých společností do jednoho koncernu – RWE. Je to již pět let, co jsme tento projekt realizovali, v době, kdy GPRS byla žhavá novinka.

Podrobnou analýzou dosavadního řešení tzv. „papír / tužka“ a porovnáním cenové nabídky na vývoj tohoto řešení na míru jako součást OpenSGC jsme zjistili, že toto řešení nám může značně ušetřit náklady. Dosavadní řešení bylo skutečně tak neefektivní, že návratnost nového řešení byla vyčíslena na 1 rok. Níže si uvedeme detailněji to, v jakých oblastech došlo k úsporám, neboť podobné bude platit i pro zhodnocení našeho nového návrhu. Srovnání nákladů Původní náklady

Nové náklady

doprava a papír

datové služby a cena mobilního telefonu

mzdové náklady zpracovatelů

modul OpenSGC (pořízení i následná údržba)

Z důvodu poměrně dobré návratnosti jsme byli tedy schopni obhájit tento projekt i za cenu toho, že se v tu dobu jednalo skutečně o zcela průlomovou technologii a cena řešení byla velmi vysoká. Navíc řešení bylo postaveno na nově budované technologii GPRS, která měla v počátcích značné výkyvy a výpadky. Také si musíme uvědomit, že se bavíme o době, kdy bylo GPRS zpoplatňováno za množství přenesených dat, tudíž neexistovaly žádné neomezené tarify, jako je tomu dnes. Pojďme se podrobně podívat na technologii. Jak již název tohoto produktu napovídá, bylo řešení založeno na použití WAPového prohlížeče na straně klienta. Koncovým zařízením nebyl kapesní počítač, ale mobilní telefon podporující zobrazování WAP stránek. Konkrétně těmito telefony byly v SČP přístroje Siemens řady ME-45. Jednalo se o telefon s víceřádkovým displejem, podporoval přenosy GPRS a hlavně se jednalo o tzv. outdoorové provedení, které odolávalo nepřízni počasí. Nyní přejděme k serverové části. Použitý server byl ve své době standardem pro poskytování služeb webového serveru. Byl na něm instalován operační systém Linux, konkrétně distribuce SuSE. Jako webový server byl nainstalován Apache s podporou PHP stránek. Jako databáze sloužila databáze PostgreSQL. Celá aplikace byla napsaná formou PHP aplikace. Namísto klasických HTML stránek, v případě klasického dynamického webu, se generovaly WAP stránky. Toto řešení bylo velmi významným průkopníkem. Nejen že se v něm využilo OpenSource produktů, ale také to bylo první řešení, které umožnilo informačnímu systému elektronickou komunikaci s vnějšími systémy prostřednictvím internetu. V rámci tohoto projektu jsme řešili spoustu dalších dosud neznámých problémů – např. zřízení tzv. demilitarizované zóny (DMZ), zabezpečení spojení na úrovni GSM/GPRS implementací OnePortu, tehdy ještě od společnosti Eurotel – dnešní O2 Telefónica. Celkově byl tento projekt vnímán velmi kladně – zrychlil a zefektivnil proces odečtů a snížila se chybovost téměř na minimum.

Internet

GSM

APN


APN (RWE)

Firewall


Firewall RWE pracovník

WAP server RWE Demilitarizovaná zóna (DMZ)

RWE – vnitřní síť

Open SGC Datové centrum

Obrázek č.5: Komunikační schéma – WAP odečty SČP

Je nutné si ale uvědomit, že hlavní část tohoto projektu nebyla ani tak strana klienta, nýbrž strana serveru - zákaznického systému OpenSGC. Zde byl systém zásadně dopracován tak, aby uměl automatické generování itinerářů a následný příjem dat z WAP serveru. Byly zde dodělány moduly pro automatickou fakturaci takto pořízených odečtů, který rovněž velmi zásadně urychlil celý proces. Nemá cenu si zde uvádět přesné částky, kolik toto řešení celkem stálo. Bylo to vzhledem k opravdu průlomovému počinu velká investice, přesto se tato investice poměrně rychle společnosti vrátila zpět. Jak jsme si již uvedli výše, návratnost byla 1 rok. Úspory zde byly v podobě snížení cestovních nákladů – do té doby si odečítač musel každý den ráno vyzvednout papírovou verzi itinerářů a odevzdat pořízené odečty z předchozího dne. Zásadním způsobem se zredukovala spotřeba papíru a benzínu, efektivností práce mohl být snížen stav odečítačů pro oblast SČP o 2 pracovníky, tedy z původních 12 na 10 pracovníků. Rovněž bylo možno jiným způsobem využít pracovníky 2 pracovníky, kteří do té doby přepisovali data z papírů do systému. Když jsme toto všechno vyčíslili a srovnali s nutnou investici do zařízení, technologií a systémů, vyšla nám takto rychlá návratnost investic. To byl velmi příznivý fakt, zvláště když si uvědomíte, jak bylo celé řešení z hlediska naprosto průlomové technologie drahé. Ale abychom nejenom chválili, pojďme si ukázat i několik chyb a nedostatků tohoto řešení. Pojďme postupně od koncových zařízení. Výběr mobilního telefonu v outdoorovém provedení se ukázal sice jako výborný tah, bohužel však postavením řešení na mobilním telefonu znamenalo pouze možnost provozování on-line aplikace. Nyní se nám to sice nemusí zdát až jako takový problém, ale v době implementace se technologie GPRS teprve rozjížděla. Naše společnost byla prvním komerčním subjektem, který na této technologii záhy po jejím oficiálním spuštění provozoval ostré řešení. To se projevilo v začátcích velmi častými poruchami technologie GPRS. Rovněž je nutné si uvědomit, že se bavíme o době, kdy se zpoplatňoval každý bajt a neexistovaly nějaké tarify non-stop nebo unlimited, jako dnes. Navíc Vás může napadnout otázka, proč jsme vůbec vybrali telefon namísto kapesního počítače. Odpověď je jednoduchá, v té době ještě neexistoval na trhu kapesní počítač s integrovaným GSM/GPRS modulem, navíc ceny mobilů a kapesních počítačů s dotykovými obrazovkami se diametrálně lišily. Kdybych ale pominul tyto vedlejší okolnosti, určitě bych jako velké negativum pro tuto on-line aplikaci zmínil nefunkčnost při ztrátě signálu. Technologicky dokonalejším řešením by jistě bylo použití lokální databáze v samotném zařízení a pouze nárazově spouštět synchronizace v momentě, kde je signál k dispozici.

Shrnutí: + zrychlení procesů a zkvalitnění služby zákazníkovi + velké úspory a s tím spojená poměrně rychlá návratnost investic + snížení chybovosti v důsledku náhrady ruční práce + spolehlivost přístrojů v outdoorovém provedení - použití nedostatečně prověřené technologie v začátcích jejího provozu - ryze online řešení vyžadující stálé připojení – vysoká komunikační režie a závislost na GPRS signálu - nedostatečné pokrytí pro provozování ryze online aplikace – problém v pohraničí - zánik řešení s přechodem na nový systém – SAP IS-U 3.3.2

Odečty VO/SO

Podívejme se ještě na odečty VO/SO. Zde je situace jednodušší. Dodavatelé přepočítávačů totiž ke svým výrobkům dodávají přímo i software, který vyčítá hodnoty z přepočítávaje pomocí IrDA rozhraní v PDA. Výrobci podporují téměř všechny platformy. Otázkou ale zůstává, jak dále zpracujeme data, vyčtená do zařízení. Výrobci totiž neřeší vzdálené přenosy, nebo synchronizace se systémy. Ani identifikaci měřidla pomocí čtečky čárového kódu. Proto tuto variantu považujme za opravdu základní a pro naše potřeby nevyhovující. Druhou variantou je vývoj software na zakázku. Doposud jsme oba typy odečtů řešili zvlášť, s tím, že jsme nebyli jisti, zda budeme moci navrhnout společné řešení. V této situaci se to přímo nabízí, protože obě varianty spějí k vývoji na zakázku, obě řešení potřebují umět komunikovat se SAP IS-U přes rozhraní a obě řešení musí umět, na rozdíl od řešení SAP MAM a SW dodavatelů přepočítávačů, identifikaci měřidla pomocí čtečky čárového kódu. Porovnejme si ještě jednou variantu dosavadní, tj. vyčítací software výrobců přepočítávačů porovnejme s možnostmi vývoje na zakázku. Výhody a nevýhody SW a zakázku od SW dodávaného výrobci přepočítávačů + vzdálený přenos – data jsou okamžitě k dispozici v systému + rychlejší zpracování – přímý interface do zákaznického systému + snížení chybovosti v důsledku automatického interface - cena řešení – na rozdíl od SW dodávaného zdarma - délka implementace – nutno realizovat v rámci projektu – druhá varianta je hotova

3.4 Návrh řešení Nyní se dostáváme k návrhu řešení. Nejdříve bych rád rovnou zdůraznil, jak bych chtěl dále postupovat s přechodem od výše uvedeného řešení k novému. Nabízí se totiž více variant konečného řešení: Zde jsou všechna možná řešení - ruční metoda papír / tužka - WAP aplikace – vyřešit rozhraní na SAP IS-U - aplikace s lokální DB v PDA – non-SAP řešení – vyřešit rozhraní na SAP IS-U - aplikace s lokální DB v PDA – SAP řešení – SAP MAM Ruční zpracování Abychom rovnou vyloučili první metodu, pojďme si zhodnotit přínos elektronického zpracování vůči ručnímu zpracování. Zhodnocení elektronický odečtů oproti ručnímu zpracování na papírech +

snížení nákladů na provoz - benzín, papír

+

zrychlení procesu zpracování

+

uživatelský komfort - větší využitelnost

+

snížení chybovosti na minimum

+

možnost průběžného monitorování práce odečítačů

-

zvýšení nákladů na komunikaci – datové přenosy

-

počáteční investice do řešení

-

nutnost přivyknout jinému stylu práce

-

závislost procesu na funkčnosti IT zařízení a komunikaci

S přihlédnutím k tomuto srovnání, pojďme první variantu rovnou zamítnout. WAP aplikace – rozhraní na SAP IS-U Pokud vezmeme do úvahy mé zjištění a zkušenosti z původního projektu, můžeme rovnou opustit i druhou variantu - WAP aplikaci. Velkou nevýhodou je to, že jsme vázáni na signál GPRS a neustálou komunikaci se serverem – sice již existují datové tarify s neomezeným množstvím dat, takže z hlediska ceny by došlo k výrazné úspoře, ale stále je velkým omezením tohoto řešení to, že je zcela vázáno na neustálý signál a komunikaci. Toto se projevilo zejména v pohraničních oblastech, kde místy nebylo žádné pokrytí. S nástupem PDA, které mají dost velké kapacity na lokální databáze, si

rovnou můžeme otevřeně říci, že vývoj aplikací podobného charakteru bez použití lokální databáze je slepou cestou, která bude vždy limitována spolehlivostí komunikačního kanálu bez možnosti zajištění náhradního řešení. Porovnání WAP odečtů a verze s lokální databází: + odolnost vůči HW poruchám, ztrátě dat apod. – vše je uloženo na serveru - závislost na signále GPRS, výpadek = nefunkčnost - vysoká komunikační režie – neustálý přenos dat se serverem Vzhledem k tomu, že jedinou výhodu WAP řešení oproti verzi s lokální databází jsme schopni řešit pomocí SW nástrojů, můžeme rovnou tuto variantu opustit. Ve srovnání se zbylými technologiemi má totiž dále jen nevýhody. Aplikace s lokální databází Takže nyní zbývá podívat se na zbylé dvě varianty. Obě znamenají aplikaci pro PDA s lokální databází, jedno řešení je využití řešení SAP MAM, druhé řešení je vývoj aplikace na zakázku. Pojďme si nyní zhodnotit výhody SAP řešení oproti non-SAP. Vítězné řešení si detailně vyspecifikujeme. Porovnání SAP MAM proti non-SAP řešení + integrace rozhraní + možno okamžité implementace - cena řešení – SAP řešení je několikanásobně dražší - nekorespondování s procesy – malý prostor na přizpůsobení aplikační logiky procesům - absence české lokalizace – patrně bude brzy napraveno - nedokonalost řešení – např. neintegrována podpora čtečky čárového kódu S ohledem k výše uvedenému jsem se rozhodl pro návrh řešení, které bude postavené na nonSAP řešení a bude mít interface do SAP IS-U. Je to řešení, které bude společné pro oba typy odečtů, tudíž ho můžeme úspěšně řešit v rámci jednoho projektu, aniž by to pro nás v tom či onom případě znamenalo nějaký výrazný kompromis. Naopak, pro oba typy odečtů tato varianta vyšla jako nejlepší řešení s ohledem na výhody a nevýhody, a samozřejmě i s přihlédnutím na požadovaný výsledek řešení – specifikaci cíle. Hlavními faktory v rozhodování byla cena, která je u non-SAP řešení výrazně nižší, také některé funkcionality, využívající vlastnosti PDA – čtečka čárového kódu pro identifikaci měřidla. To je bohužel funkcionalita, kterou do SAP řešení bychom velmi těžce dodatečně implementovali, pokud by to vůbec bylo možné. Na druhou stranu nás non-SAP řešení bude stát více úsilí ve fázi implementace

interface do SAP IS-U. Je to však oblast, kterou jde řešit, neboť systém SAP umožňuje definici rozhraní na jako součást systému, bez toho, aniž by toto bylo nutné řešit úpravou stávajícího systému ze strany dodavatele. Trochu detailněji se podívejme na odečty VO/SO. Zde je velkou nevýhodou doba implementace a to v neprospěch námi navrženého řešení. Naštěstí lze udělat v tomto případě využít stávajících SW prostředků, doplnit je o novou technologii a do doby implementace skutečně cílového řešení můžeme provozovat řešení, které bude kompromisem obou. V konkrétním návrhu si řekneme, jak tohoto můžeme velmi efektně docílit. Pojďme však nyní postupně navrhnout kompletní řešení 3.4.1

Serverová část

Touto částí budeme předpokládat serverovou část našeho nově vyvíjeného řešení. Předpokládejme, že v rámci SAPu máme vyřešeny odečtové trasy, itineráře a umíme je exportovat přes navržený interface. Z hlediska administrace, operativního přeplánování apod. se nám vyplatí samotné plánování itinerářů na odečítače provádět mimo systém SAPu, aby bylo možno systém jednoduše monitorovat, ale co je hlavní, aby bylo možno v systému práci i průběžně přerozdělit jiným způsobem, aniž bychom museli data opět exportovat ze SAPu. Důvodem k tomu může být nějaká nečekaná havárie, případně nemoc odečítače apod. Řešení - vývoj modulu pro plánování itinerářů, administraci a monitoring řešení sběru odečtů (zde využijeme poznatků z Mobilní kanceláře a uděláme webové rozhraní pro využití PDA) - plánování tras – přidělí odečítačům na konkrétní dny konkrétní itineráře - přeplánování – možnost změny odečítače a/nebo dne odečtů konkrétního itineráře - monitorování průběžného – sledování statistik úspěšnosti, možnost tisku přehledů a reportů 3.4.2

Klientská část aplikace

Návrh se nám zjednodušil, neboť děláme jednu aplikaci pro oba typy odečtů. Po provedení detekce odběrného místa pomocí čtečky čárového kódu z plynoměru, bude nalezen a zobrazen příslušný záznam o odběrateli. PDA samo rozliší, o jaký typ odečtu se jedná a zobrazí dle toho funkcionality. Aplikace musí mít i informaci o platební bilanci odběratele a musí případně upozornit na dluh. Musí umět do systému přenést informaci o výši eventuální úhrady – i částečné. Pro samotné pořízení odečtů platí, v případě odečtu MO/DOM pouze ruční vstup jedné hodnoty, v druhém případě možnost spuštění načtení celého měsíce pomocí IrDA. Aplikace musí umět zobrazit zběžně odběrový diagram, aby bylo možno zběžnou kontrolou detekovat případné poruchy.

Řešení - vývoj jedné aplikace pro oba typy odečtů – dle odběratele se odliší funkcionalitu MO/DOM a VO/SO - identifikace odběrného místa proběhne čtečkou čárového kódu - aplikace přizpůsobí vzhled typu odečtu – zobrazí údaje potřebné pouze pro daný typ odečtu - aplikace bude upozorňovat na dluh odběratele - aplikace umožní inkaso dlužné částky, tisk příjmového pokladního dokladu nebude (bude ručně) - aplikace předá zpět informaci o inkasu a ukončí proces upomínání - aplikace vyčte odečty VO/SO pomocí IrDA rozhraní přístroje - aplikace zobrazí diagram spotřeby z naměřených denních hodnot – odběrový diagram - aplikace příjme ručně pořízený odečet MO/DOM – provede kontrolu s historií a odhadem spotřeby - aplikace využívá lokální databázi v PDA – synchronizace se serverem je dávkově - aplikace umožní pořízení komentáře k odběrnému místu v případě, že odečítač zjistí závadu na měřidle – aplikace tuto informaci přenese do systému, kde se automaticky vygeneruje pracovní příkaz – viz. další oblast implementace 3.4.3

Synchronizace – přenos dat

Tato fáze má za úkol jediné – co nejrychlejší, nejspolehlivější a nejkomfortnější přenos dat do zákaznického informačního systému SAP IS-U. Jak jsem již zmínili, chybou minulého řešení byla absence dočasné databáze, která by kompenzovala výkyvy signálu on-line aplikace. Z tohoto důvodu navrhujeme řešení, které umožňuje off-line provoz a je doplněno o automatické či uživatelsky spouštěné vzdálené synchronizace pomocí GPRS. Rovněž je nutné, aby administrativní modul uměl vyvolat synchronizaci vzdáleně – řešení např. pomocí SMS v definovaném tvaru. Řešení - synchronizace probíhá vzdáleně přes GPRS/EDGE - synchronizace se vyvolává automaticky a nebo manuálně, dle potřeby - řešení umožňuje vyvolání synchronizace na dálku, pomocí modulu administrace (tzv. vynucená synchronizace) - řešení přenese data o odečtech do systému SAP IS-U, kde se vygenerují faktury za odběr - řešení přenese data o anomáliích na odběrném místě do SAP IS-U, kde se vygenerují příkazy (vygeneruje se pracovní příkaz na definovanou činnost v modulu mobilních příkazů) 3.4.4

Koncová zařízení

Na trhu jsou nabízeny zařízení, která jsou odolná proti lehkým pádům, prachu a lehkým nečistotám. Tato zařízení mají ve vybavení i čtečku čárového kódu – jsou ideální i pro řešení skladů pro potřeby inventur. Zde trochu předběhneme a rovnou si řekneme, že koncovým zařízením bude PDA Symbol . je to zařízení, které vybereme i v rámci dalšího řešení, Mobilních pracovních příkazů. Je pro nás

jednodušší u těchto zařízení udržet jeden typ přístroje, protože můžeme využít synergických efektů a můžeme montéry využít v době nadměrných odečtů k posílení odčítačů apod. Důvody, proč jsme vybrali zrovna toto zařízení najdete v řešení Mobilních pracovních příkazů. Stručně si zde uvedeme, že je to právě odolností zařízení a integrovanou čtečkou čárového kódu, která velmi usnadňuje identifikaci měřidel a eliminuje chybovost při zadávání čísla měřidla téměř na nulu. To byl i důvod, proč toto zařízení bylo vybráno i pro následující oblast řešení. Řešení - koncové zařízení bude Symbol MT50 – průmyslová verze PDA se čtečkou čárového kódu 3.4.5

Návrh bezpečnostních prvků

Zde platí to, co již bylo řečeno v předchozí části, kapitole 2. odstavci 2.4.5 - Bezpečnost, proto pouze rychle zrekapitulujeme to, co v dané oblasti vyplývá za návrh řešení. V rámci zkušeností z provozu PDA zařízení v SČP se ukázalo jako vhodné využít nějakého zálohovacího mechanismu řešícího hrozbu ztráty dat v případě nedostatku elektrické energie. V případě mobilních pracovních příkazů je možné zařízení průběžně dobíjet v automobilu, u sběru odečtů je situace horší, protože odečítači nemají vždy k dispozici automobil. Nabízí se zde pouze jedno nekoncepční řešení, vybavit odečítače náhradní baterií pro potřeby nouze. Každopádně je dobré vybavit PDA i nějakým SW pro automatické zálohování a možnost jednoduché obnovy.

Řešení - všechna PDA budou vybavena paměťovými kartami o velikosti 2 GB (SD, CompactFlash) - součástí všech PDA bude software pro automatický backup dat - zálohování (produkt Sunnysoft Backup Manager 4.0 - nastaven na zálohování při poklesu energie na 10 %) - součástí všech PDA bude software pro dvousložkovou předbootovací identifikaci - zabezpečení (produkt SafeBoot Enterprise pro PDA – stejné řešení bude použito i pro notebooky) - bude zřízen samostatný přístupový bod pro přístup ze sítě GSM do sítě RWE – privátní linka (APN pro přístup z GSM a přímý komunikační kanál mezi operátorem a RWE) - všechna PDA se budou připojovat pomocí APN RWE do demilitarizované zóny (tzv. DMZ) (v rámci DMZ budou mít přístup k intranetu a přes proxy server a firewall i do internetu) - všechna PDA budou mít zakázán jakýkoliv jiný způsob připojení (přímo do internetu) (omezením služeb poskytovaných operátorem na konkrétních SIM kartách

Dočasné řešení pro odečty VO/SO Jelikož jsme si v rámci zhodnocení odečtů VO/SO uvedli jako nevýhodu to, že vývoj nového řešení bude nějakou dobu trvat a my máme k dispozici okamžitou možnost řešení, pokusíme se tohoto využít v náš prospěch. Můžeme využít technologii vyvinutou již pro mobilní kancelář, můžeme ji aplikovat již na koncová zařízení, která budou v konečné fázi sloužit pro sběr odečtů, a můžeme tyto dvě věci zkombinovat. Dostane se nám jedno praktické řešení, které nám umožní vzdálený přenos dat pomocí přílohy v e-mailu. Není to nijak závratné řešení, ale i po dočasnou dobu se nám podařilo vylepšit stávající řešení s nulovými náklady. Řešení - využití koncových zařízení Symbol MT50 již odečty pomocí původního software - využít řešení mobilní kanceláře k posílání dat e-mailem (dočasné řešení, efektivnější a rychlejší než fyzický svoz dat)

3.5 Zhodnocení Zhodnoťme si nyní tuto část implementace řešení pro oblast měření spotřeb plynu - sběr odečtů. Tento případ byl ukázkou toho, jak je oblast IT ovlivňována neustále probíhajícím vývojem. Řešení, které se nám zdá dnes jako to nejlepší, se může během krátké doby stát neefektivním. Pro nás to znamená jedno ponaučení – je třeba neustále sledovat trendy v oblasti IT a snažit se hledat jejich možné využití i v již existujících řešeních. To bylo nádherně patrné v tomto případě, kdy z hlediska porovnání s původním řešením byla i online aplikace jako velmi výhodné řešení. Jakmile jsem ale toto řešení podrobili srovnání s novou technologií, okamžitě se objevila oblast dalšího možného zlepšení a úspor. Je třeba toto mít na mysli a nikdy nepovažovat žádné řešení za to, které nejde dále zlepšit. Další, neméně zajímavou situací, která se při řešení této problematiky objevila, byla v potřebě nalezení dočasného řešení, které by pomohlo překlenout dobu implementace konečného řešení. Zde se nám k tomu přímo nabízelo řešení mobilní kanceláře, které jsem navrhli v první části pro manažery.

Navrhl jsem řešení … z hlediska finančních úspor - šetřící výrazným způsobem náklady na benzín a tiskoviny - šetřící výrazným způsobem mzdové náklady z důvodů optimalizace procesu - podporující snížení objemu dlužných částek za odběr plynu z hlediska procesní optimalizace - umožňující zrychlení celého procesu sběru odečtů a následné fakturace - umožňující automatické zpracování pořízených dat - umožňující centrální monitorování a koordinaci odečítačů - umožňující operativní řešení krizových situací – přeplánování - umožňující podporu právního vymáhání – inkaso dluhů - umožňující případný outsourcing sběru odečtů mimo RWE z hlediska zvýšení kvality - poskytující rychlý a efektivní pracovní nástroj uživatelům - umožňující zredukovat byrokracii na přijatelné minimum

KAPITOLA 4.

ŘEŠENÍ – ČÁST III. Podpora montérů Mobilní pracovní příkazy

2.1


2.2

Specifikace cíle

2.3


2.4

Návrh řešení

2.5

Zhodnocení

4.1 Úvod do problematiky – Mobilní pracovní příkazy Jak jsme si již v úvodu řekli a na předchozích dvou návrzích ukázali, je možné technologii PDA implementovat do mnoha různých odvětví. Nyní se podíváme na další, v rámci této diplomové práce již poslední, možnost implementace technologie PDA v plynárenství. Touto oblastí budou tzv. „Mobilní pracovní příkazy“, jako podpora montérů zajišťujících údržbu plynovodní sítě. Pojďme si v úvodu vysvětlit, co vše se za touto problematikou skrývá, abychom pochopili, co vše budeme muset v rámci návrhu řešení zrealizovat. Pojďme si nejdříve vysvětlit práci montérů, kteří provádějí údržbu plynárenské sítě. Jedná se o speciálně vyškolené montéry, kteří zejména provádějí výměny měřidel, jejich nové montáže nebo naopak demontáže apod. Plynoměr je zařízení, které monitoruje spotřebu plynu u odběratelů. Je to poměrně citlivé zařízení, které musí v pravidelných intervalech podstoupit revizi a přecejchování ve specializovaných státních zkušebnách. Za tímto účelem jsou do terénu vysíláni montéři, aby odmontovali z odběrného místa plynoměr určený na přecejchování a nainstalovali nový plynoměr. U nově připojovaných zákazníků je situace jednodušší, zde se provádí pouze osazení novým plynoměrem na nově vybudovanou plynovodní přípojku. Opačný proces, než-li je připojení nových zákazníků, je odpojení ukončených odběrů a nebo odpojení neplatičů. Zde je pak montér vyslán k odmontování přístroje a zabezpečení soustavy proti černým odběrům. Pojďme si nyní projít proces detailněji od začátku. První předpokladem, aby vznikl pracovní příkaz, je nějaká událost na odběrném místě v zákaznickém informačním systému. Touto událostí může být akce vyvolaná zákazníkem – tj. přihlášení nového odběru, nebo odhlášení odběru. Další událost, která může vyvolat generování pracovního příkazu, je dlužná částka a proces upomínání. Posledním důvodem pro vznik pracovního příkazu je potřeba provedení údržbových prací na distribuční síti – např. odeslání měřidla do zkušebny, obnova typu přístroje, podezření na zaseknutý nebo poškozený plynoměr, podezření na únik a nebo černý odběr apod. Všechny tyto akce v zákaznické systému znamenají to, že se vysílá technik do terénu. Nyní se podívejme na to, co technik má provést a jaké k tomu potřebuje informace. Nejdůležitější informací pro montéra je to, co má udělat a kde to má udělat. Typem pracovního příkazu je jasně dán pracovní postup, co se má udělat. Např. náš zmiňovaný pracovní příkaz na cejchovní výměnu. Znamená pro montéra návštěvu odběrného místa, identifikaci měřidla, kontrolu plomby na měřidle, pořízení hodnoty odečtu do protokolu, odejmutí měřidla, montáž nového měřidla, zprovoznění přípojky, ověření funkčnosti plynoměru, pořízení stavu nového plynoměru do protokolu a nakonec podepsání protokolu odběratelem.

Jakmile je výměna provedena, protokol o výměně odběratelem podepsán, může montér pokračovat v další údržbě. Na konci dne odevzdá všechny pořízené protokoly s provedenou činností. Tyto protokoly jsou následně ručně pořizovány do informačního systému – je provedena stejný proces změn v systému, aby odpovídal současnému stavu. Tato část je poměrně zdlouhavá, proces je potenciálním zdrojem mnoha chyb. Myslím si, že jsme si udělali základní představu o práci montéra, tak můžeme přistoupit ke specifikaci zadání a k následnému řešení této modelové situace.

4.2 Specifikace cíle Úkolem je navrhnout takové řešení, které bude umět pokrýt problematiku pracovních příkazů ucelenou aplikací. Pojďme si projít jednotlivé fázě procesu a při nich specifikovat detailněji požadavky na řešení. V jednotlivých fázích nebudeme zacházet příliš do detailů, které by mohly mít rozhodující vliv na vybranou technologii a konečné řešení. 4.2.1

Fáze plánování mobilních pracovních příkazů

Zde je nutné zajistit existenci modulu zákaznického systému SAP IS-U, který umí automaticky generovat pracovní příkazy na předem vydefinované události. Požadavkem je, aby tento modul byl nastavitelný, aby bylo možno konfigurovat parametry, za kterých situace nastává, bylo možno definovat typ události, která vznikne, a bylo možno měnit výčet údajů, které budou součástí interface mezi systémem SAP IS-U a aplikací pro mobilní pracovní příkazy (MPP). Požadavky na řešení: - umožnit v SAP IS-U automatické generování MPP - vzdálený přenos dat ze systému do PDA 4.2.2

Fáze provádění mobilních pracovních příkazů

V této fázi si musíme vyspecifikovat požadavky na aplikaci v PDA, na to, jaké moduly bychom zde chtěli zajistit a pro jaké účely. V této fázi musí být zajištěno to, aby montér obdržel elektronicky data o typu požadované akce, kterou má provést, aby obdržel nezbytné podklady o odběrném místě, základní informace o odběrateli a o namontovaném přístroji, kterého se akce týká. Montér požadovaný úkon provede a pořídí všechny nezbytné hodnoty, dle typu akce, do PDA, odkud je bude mít možnost vzdáleně přenést na server pro další zpracování. Souběžně s tím musí o provedené akci vytisknout protokol, který předloží odběrateli k podpisu. Jakmile je toto hotovo, může montér pokračovat v plnění dalších pracovních příkazů. Důležité v tuto chvíli je to, abychom si zmínili oblasti, které chceme v rámci tohoto řešení rovněž vyřešit, a které nevyplývají přímo z výše uvedené specifikace. Řešení v PDA by mělo obsahovat následující moduly: - pracovní příkazy (výše popsaná funkcionalita) - mobilní sklad (evidence měřidel v automobilu – nejen nových, ale i odmontovaných měřidel) - pokladna (evidence přijatých plateb a vydávání příjmových dokladů) - synchronizace (výměna dat mezi lokální databází v PDA a serverem)

Toto jsou základní oblasti, v kterých bude naším cílem zautomatizovat co nejvíce činnost a využít k tomu prostředky PDA, aby montér měl pokud možno co nejméně činností, vyžadujících použití papíru a pera. Maximum informací se musí pořizovat automaticky, případně elektronicky do PDA. Veškeré dokumenty mezi odběratelem a montérem se musí tisknout kompletně vyplněné přímo z PDA tak, aby nemohlo dojít k chybám či nejasnostem v důsledku ručního psaní. Zde stojí i za zmínku jedna skutečnost. Pro samotný návrh synchronizace a struktury interface je nutné uvědomit si, jaké kategorie dat zde máme. Z hlediska původu a následného zpracování dat, máme tyto 3 kategorie údajů: - údaj získaný ze systému, na PDA pouze k zobrazení, zpět se nepřenáší do systému - údaj získaný ze systému, na PDA se může jeho hodnota měnit, zpět se přenáší do systému - údaj nezískaný ze systému, na PDA nově pořízený, zpět se přenáší do systému Požadavky na řešení: - pracovní příkazy – zobrazení všech informací o odběrném místě v PDA (žádné papírové podklady) - pracovní příkazy – elektronické pořízení všech dat o provedené akci (žádné ruční psaní na papíry) - tisk dokumentů – tisk všech dokumentů z PDA (protokol o pracovním příkaze, příjmový doklad atd.) - skladová evidence – automatické vedení skladu plynoměrů v automobilu (výdejky, příjemky) - pokladna – modul umožňující inkaso dlužné částky - synchronizace – modul umožňující vzdálenou synchronizaci dat mezi PDA a serverem 4.2.3

Fáze zaznamenání změn v systému

V této fázi je nutné umět přijmou vzdáleně data a automaticky provést úkony v zákaznickém systému SAP IS-U, tak jak byly provedeny montérem skutečně. Systém musí zcela sám provést automaticky demontáže starých a montáže nových měřidel na odběrných místech, musí provést aktualizaci skladů plynoměrů, musí přiřadit provedené platby ke konkrétnímu zákazníkovi a případně zastavit proces upomínání, pokud byla uhrazena kompletně dlužná částka. Systém si musí sám zaznamenat stavy odečtů k jednotlivým měřidlům a v případě ukončených odběrů musí být sám schopen automaticky vystavit fakturu za odběr plynu. Zpracování všech těchto údajů je možné provádět dávkově během nočního zpracování automatických procesů. Požadavky na řešení: - elektronický příjem dat z PDA do SAP IS-U - automatická aktualizace stavu odběrného místa – nově osazená měřidla - automatická aktualizace stavu skladů plynoměrů – odebraná měřidla - automatické pořízení odečtů při provádění pracovního příkazu - automatické zpracování provedených inkas dlužných částek

- automatické zastavení procesu upomínání v případě úhrady dluhu - automatické vystavení faktur v případě ukončených odběrů – konečná faktura zákazníkovi Nyní máme v krátkosti řečeny základní požadavky na řešení – další požadavky na řešení, jakými jsou např. zabezpečení spojení, principy zálohování a zabezpečení, možnosti vzdálené administrace atd., budeme řešit až v rámci samotného návrhu.

4.3 Analýza současného stavu Provedeme si nyní analýzu toho, jaká řešení pro danou oblast v RWE existovala. Byla to pouze dvě řešení: - řešení tzv. papír / tužka – bez využití moderních nástrojů IT - řešení mService od Sunnysoft – implementováno v SČP Obě tato řešení si nyní detailněji projdeme a probereme jejich klady a zápory. V rámci tohoto zhodnocení se pokusíme zmínit vždy slabá místa těchto řešení, aby mohly být v rámci nového návrhu tyto nedostatky odstraněny. 4.3.1

Řešení tzv. „papír / tužka“

První řešení bylo založeno na papírové podobě všech podkladů, na ručním vyplňování prázdných pracovních listů a následném ručním provádění všech zrealizovaných činností v zákaznickém informačním systému dle zpět doručených protokolů. Zde asi tušíte, že z tohoto řešení moc při novém návrhu nevyužijeme, proto pojďme rovnou ke zhodnocení: Zhodnocení řešení tzv. „papír / tužka“ +

nezávislé na technice – vysoká spolehlivost řešení – nulové výpadky řešení

-

nízký komfort při pořizování dat – spousta ručního psaní

-

zdroj častých chyb

-

pomalé zpracování

-

vyšší náklady na benzín a na papír

-

nemožnost přeplánování během dne, jakmile technik vyrazí do terénu

Jak je z předchozího výčtu výhod a nevýhod patrné, nemá cenu se přínosem tohoto způsobu řešení pro případně nový návrh zabývat. Přistupme tedy k druhé variantě, která byla implementována. 4.3.2

Řešení mService (SČP - Sunnysoft)

Druhá z variant byla na zakázku vytvořená aplikace pro PDA. Toto řešení se implementovalo v rámci pilotního projektu v SČP, jehož hlavním úkolem bylo otestovat možnosti zlepšení v této oblasti. Měl jsem to štěstí, že jsem byl realizací tohoto projektu pověřen, tudíž mohu nyní s odstupem času velmi fundovaně zhodnotit zkušenosti, na tomto projektu získané. Pojďme si tedy celý projekt zhodnotit. Zejména je nutné hned na začátku zdůraznit, že tento projekt byl navržen tak, aby komunikoval s původním zákaznickým systémem OpenSGC od dodavatele Soluziona. Jelikož došlo ke sjednocení

informačních systémů a jejich náhradě novým systémem, zákaznickým systémem SAP IS-U, není možné toto popisované řešení nadále využívat v té podobě, jaké bylo. Přesto nám může posloužit k tomu, abychom si ověřili to, zda naše specifikace je tímto způsobem realizovatelná či nikoliv. Předně si musíme říci, že při realizaci takovýchto projektů je velmi nutné důkladně provést prvotní analýzu a to nejen z hlediska financí, ale i z hlediska případných dopadů na počet pracovních míst. Obecně platí, že při implementaci těchto řešení musí být zákazník, např. v tomto případě ředitel úseku údržby a správy plynárenského majetku, rozhodnut pro implementaci podobného řešení. Bez spolupráce příslušného úseku není možné celý projekt zdárně realizovat. O to horší situace je, pokud vyčíslení návratnosti a úspor projektu není založeno jen na snížení provozních nákladů (benzín, papír, energie apod.), ale i na snížení počtu pracovních sil v důsledku optimalizace samotného procesu. Tento fakt zde zmiňuji záměrně, protože v rámci tohoto řešení byl důležitým. Jakmile máme myšlenku pro samotnou realizaci, máme podporu vedení příslušného úseku, můžeme přistoupit k prvotní analýze projektu. V době, kdy jsme toto řešení Mobilních pracovních příkazů chtěli implementovat, bylo již známo, že dojde v horizontu 1-2 let k přechodu na nový zákaznický informační systém – ze systému OpenSGC na systém SAP IS-U. Z tohoto pohledu zde byly dvě možné varianty: - nejdříve implementovat SAP IS-U, poté řešit Mobilní pracovní příkazy - implementovat Mobilní pracovní příkazy tak, aby návratnost projektu byla maximálně 2 roky Podrobnou analýzou dosavadního řešení tzv. „papír / tužka“ a průzkumem trhu dodavatelů podobných elektronických řešení, jsme zjistili pro nás velmi pozitivní věc. Dosavadní řešení je skutečně tak neefektivní, že návratnost nového řešení mohla být za kratší období, přesněji za 1 rok. Níže si uvedeme detailněji to, v jakých oblastech došlo k úsporám, neboť stejné bude platit i pro zhodnocení našeho nového návrhu. Srovnání nákladů Původní náklady

Nové náklady

benzín a papír

datové služby a odpisy PDA

mzdové náklady zpracovatelů

informační systém (pořízení i následná údržba)

Z důvodu opravdu rychlé návratnosti jsme byli tedy schopni obhájit tento projekt i za cenu toho, že je to opravdu pouze dočasné řešení, které má danou oblast prozkoumat z hlediska využití PDA. Jelikož v této nemá cenu hledat žádné krabicové řešení, oslovili jsme přímo několik nejvýznamnějších dodavatelů podobných řešení založených na použití PDA. Byly to tyto společnosti: Ganymed, Grall,

Kvados, Logos a Sunnysoft. Všechny společnosti byly schopny předložit reference na svá řešení v oblasti zejména distribuce a rozvozu zásilek nebo produktů. Byla to řešení pro tzv. podomní prodej. Jako dodavatel námi poptaného řešení byla společnost Sunnysoft, která svou nabídku, i tak cenově přijatelnou, podpořila i nabídkou mobilního operátora T-Mobile, která spočívala v dodávce dotovaných koncových zařízení – PDA. Navíc společnost Sunnysoft byla a je implementátorem českého prostředí do řady vyráběných a do ČR dovážených PDA, tudíž i z tohoto pohledu jsme byli o kvalitách dodavatele přesvědčeni. V této části bych ale rád zdůraznil, že ze strany všech dodavatelů, jak se i později ukázalo, bylo námi poptané řešení Mobilních pracovních příkazů trochu podceněno – minimálně z časového a finančního hlediska. Všechny společnosti totiž předpokládaly, že budou schopni pouhým přizpůsobením svých produktů docílit požadovaného řešení. Stejná situace byla i v případě společnosti Sunnysoft. Původně navržený harmonogram projektu počítal s kompletní realizací v průběhu 4 měsíců – od prvotní analýzy, přes fázi programování, fázi testování a zkušebního provozu až po spuštění ostrého provozu. Z tohoto pohledu došlo k prodloužení celkové doby projektu, naštěstí ale z důvodu prodloužení fáze testování. Z hlediska finančního nedošlo k navýšení ceny řešení, tuto ztrátu pokryl dodavatel. Pro nás je ale důležitým poznatkem to, že celková cena řešení by ve skutečnosti mohla být o čtvrtinu původní ceny větší, čímž by se mohla prodloužit doba návratnosti o cca 3 měsíce. Ale vraťme se zpět k důvodům, proč došlo k časovému posunu projektu. Bylo to zejména z toho důvodu, že byla prodloužena fáze zkušebního provozu. V této fázi jsme po dobu 1 měsíce provozovali obě řešení – tj. polovina montérů na staré technologii s papírem a tužkou, druhá polovina montérů na nové technologii s PDA a řešením mService. V první fázi bylo původní řešení malinko výkonnější. Bylo to zejména důsledkem nedostatečného proškolení montérů a nutnosti se sžít s touto technologií. Přece jen bylo trochu zpočátku problematické pro montéry používání křehkého stylusu a dotykové obrazovky. Tyto prodlevy však kompenzovali samotným zrychlením procesu, neboť namísto ručního vyplňování formulářů pouze vytiskli pořízená data z PDA. Po týdnu, kdy si již osvojili samotné ovládání PDA, byla situace již opačná a zcela zásadním způsobem. Nemohli si již nový způsob práce vynachválit, neboť zmizelo zbytečné papírování. Pojďme se však podívat i na další fázi procesu, tj. následné zpracování dat. Již při testovacím provozu, kdy klesl počet ručně zpracovávaných pracovních příkazů na zhruba polovinu, bylo zřejmé zlepšení. U elektronický pořizovaných dat se neobjevily žádné chyby v důsledku přenosu a samotný proces provedení změn v zákaznickém informačním systému OpenSGC probíhal zcela automaticky, vždy v rámci nočního zpracování, před automatickým generováním pracovních příkazů na další den. Zde byl vidět obrovský rozdíl, neboť ruční pořízení znamenalo v celém procesu 1-2 dny zbytečného zdržení. Nemluvě o neefektivním využití lidské pracovní síly.

Samotný nájezd do produkčního provozu se shledal s podporou ze stran uživatelů tak i vedení. I samotní zákazníci ocenili skutečnost, že proces funguje rychleji a je kompletně vyřízen na místě, včetně všech protokolů atd. Pojďme se nyní seznámit s tím, v čem všem spočívá uvedené řešení mService. V tomto směru se nemůže totiž zásadně lišit ani námi navržené řešení. Serverová část část mService od Sunnysoftu - server INTEL XEON - aplikační server pro mService - databázový server (Microsoft SQL Server 2000) - interface pro generování a zpracování XML souborů část mService v OpenSGC od Soluziony - modul pro automatické řešení pracovních příkazů v OpenSGC - interface pro generování a zpracování XML souborů Klientská část - PDA zařízení T-Mobile MDA III (HTC Qtek9090) - tiskárna HP DJ450 s Bluetooth modulem - aplikace mService - lokální databáze Microsoft SQL CE

Obrázek č.6 : Komunikační schéma - mService v SČP

Pojďme si nyní srovnat to, co přinesla implementace pilotního řešení mService oproti původnímu řešení, kdy se vše dělalo papírově na místě a až poté následně ručně pořizovalo do zákaznického informačního systému. Zhodnocení přínosu MPP oproti ručnímu zpracování na papírech +

snížení nákladů na provoz - benzín, papír

+

zrychlení procesu zpracování

+

uživatelský komfort - větší využitelnost

+

snížení chybovosti na minimum

+

možnost průběžného monitorování práce montérů

-

zvýšení nákladů na komunikaci – datové přenosy

-

počáteční investice do řešení

-

nutnost přivyknout jinému stylu práce

-

závislost procesu na funkčnosti IT zařízení a komunikaci

V rámci ročních zkušeností z provozu tohoto řešení vyplynuly další problematické oblasti, které je nutno v rámci nového návrhu řešit. Problémy z ročního reálného provozu - poruchovost PDA zařízení – praskání krytů, ojediněle i displejů, v důsledku pádu na zem (nutno navrhnout jiný typ koncových zařízení, odolnější hrubějšímu zacházení) - poruchovost tiskáren – zasychání inkoustu v mrazech, praskající křehké plasty (nutno navrhnout jiný typ tiskárny – odolnější vnějším podmínkám) - výpadek záložní energie = možná ztráta dat, ojediněle se vyskytla (nutno řešit zálohováním dat – dočasně řešeno nekoncepčně nabíječkami v automobilech) Pojďme nyní přistoupit k fázi návrhu nového řešení. Vezmeme do úvahy všechny specifikované cíle, dosavadní zkušenosti v této oblasti, zjištění z reálného provozu a změny, které prodělaly informační systémy. Na základě všech těchto poznatků navrhneme nové řešení.

4.4 Návrh řešení Nyní se budeme zabývat novým návrhem řešení. K úplnému pochopení všech vazeb nám ještě chybí objasnit si změny v informačních systémech, které mají vazbu na toto řešení. Proto si nyní tyto změny popíšeme. Jak již bylo zmíněno dříve, byl zákaznické informační systém OpenSGC od dodavatele Soluziony nahrazen zákaznickým informačním systémem SAP IS-U. Spuštění produkčního provozu systému SAP IS-U bylo v prosinci roku 2006. Od této doby přestalo fungovat řešení mService implementované v SČP v rámci zkušebního projektu. Nyní opět všechny společnosti využívají stejný způsob – technologii tzv. „papír / tužka”. Jak jsme si již dříve zmínili, ověřili jsme si smysl implementace elektronického řešení již v rámci projektu v SČP. Nebudeme zde provádět toto zdůvodnění, proč projekt realizovat, a přejdeme rovnou k možnostem, jakými toto zajistit. V minulosti byla situace taková, že neexistovalo krabicové řešení, které by umožnilo fungování mobilních pracovních příkazů z původním zákaznickým informačním systémem. V případě SAP IS-U je situace trochu odlišná, neboť zde základní produkt existuje – je to produkt SAP MAU (Mobile Asset for Utilities). Proto zde vyvstávají tři základní možnosti, jak projekt realizovat. Možnosti realizace MPP -

s využitím základního řešení SAP MAU

-

s využitím základního řešení mService v SČP

-

vývojem zcela od začátku

Jelikož z hlediska efektivity je třetí možnost zcela nejméně výhodná, nebudeme se jí zabývat a rovnou přejdeme ke srovnání prvních dvou variant. Jakmile budeme mít rozhodnuto, kterou cestou své řešení budeme budovat, budeme již ve fázi návrhu konkrétní. Výhody a nevýhody řešení SAP MAU oproti mService od Sunnysoftu +

existence interface mezi SAP MAU a SAP IS-U

-

absence podpory vnitřních procesů (je to obecný nástroj pro energetické společnosti)

-

žádné zkušeností s funkčním provozem (není implementace ve střední a východní Evropě)

-

menší úroveň využití funkcionalit PDA (zálohování, vynucení synchronizace, vzdálená údržba)

-

vysoká cena řešení (implementace, licence i maintenance)

-

dlouhá návratnost (hrozba ztrátovosti v důsledku morálního zastarávání řešení)

Obrázek č.7: Ukázky aplikace SAP MAU

Z posouzení obou variant vyplývá, že z hlediska nejen finančních, ale i časových, je jednodušší implementovat řešení vybudované na bázi původní aplikace mService pro SČP. V rámci tohoto návrhu implementace se pokusíme odstranit všechny nedostatky zjištěné ročním provozem. Nyní se pojďme podívat na jedinou zásadní nevýhodu řešení mService oproti SAP IS-U, kterou je chybějící interface. Někomu se může toto zdát nyní jako velmi zásadní problém, ukážeme si ale, že tomu tak ve skutečnosti není. Jak jsme již zmínili dříve, komunikoval mService se systémem OpenSGC a to pomocí XML souborů. Z hlediska samotného obsahu aplikace mService se na potřebách nic zásadního z principu nezměnilo – minimálně v těch již provozovaných modulech. Tudíž jediné, co nám nyní zbývá, je nastavit interface vůči systému SAP IS-U tak, aby získával a předával odpovídající data stejně, jako tomu bylo s OpenSGC. A v tuto chvíli oceníme nástroje SAPu k vytváření těchto uživatelských rozhraní, jejich změnám a přizpůsobování. Z tohoto pohledu je málo informačních systémů, kde si interface můžete zrealizovat sami bez nutnosti nějakých zásadních zásahů dodavatele. Proč tomu tak je? Osobně si myslím, že je to výborný tah od společnosti SAP, protože dávají uživatelům možnost volby. Zda chtějí využít již stávající řešení SAPu – např. SAP MAU, které není dokonalé, nikdy nebude zcela nastavené dle jejich potřeb, ale alespoň nějaká možnost zde rovnou okamžitě je. Na druhé straně umožňuje spolupráci s třetími stranami, s odborníky např. v oblasti aplikací pro PDA, a podporují i případnou integraci jejich kvalitních řešení do prostředí SAPu. Tohle je možnost, jak skutečně můžete skloubit to nejlepší na trhu a vytvořit celek, který je kompaktní a přitom v každé z oblastí tzv. TOP. V tomto se politika společnosti SAP např. značně liší od společnosti Microsoft. Ten má tendenci dodávat co nejkomplexnější řešení s tím, že se snaží své produkty co nejvíce integrovat do operačních systémů, aby znemožnil konkurenci vstup do této oblasti. Někdy může být i toto výhodou, jak jsme si ukázali v případě mobilní kanceláře, kde jsme tohoto provázání na opravdu nejnižší úrovni právě využili. SAP nám umožňuje výběr - integrovat jejich řešení okamžitě – drahé, nepřizpůsobivé potřebám, průměrné ve srovnání s trhem - implementovat přes interface naše nebo jiné řešení – kvalitnější, levnější, dle našich potřeb Samotné dávkové zpracování pracovních příkazů a provádění automatických operací na měřících místech je již součástí SAP IS-U, tudíž i implementace rozhraní bude z tohoto hlediska jednodušší, než bylo kdysi integrování tohoto rozhraní do OpenSGC. Jelikož i jediný nedostatek dosavadního řešení je možné eliminovat, pojďme si před samotným návrhem ještě pro jistotu shrnout výhody řešení mService od poslečnosti Sunysoft v porovnání se SAP IS-U a nedostatky zjištěné ročním provozem, které se budeme v rámci návrhu implementace snažit odstranit.

Zhodnocení řešení mService od Sunnysoft +

zajištění všech podnikových procesů v aplikaci

+

existence otevřeného interface do libovolného systému (i SAP IS-U)

+

bohaté zkušenosti s funkčním provozem v SČP

+

cena řešení (implementace, licence i maintenance)

+

otevřenost interface SAP IS-U pro řešení třetích stran

+

existence části SAP IS-U pro zpracování pracovních příkazů

-

poruchovost PDA zařízení

-

poruchovost tiskáren – zasychání inkoustu v mrazech, praskající křehké plasty

-

ztráty dat v důsledku výpadku záložní baterie

-

absence modulu mService pro inkasování dlužných částek

4.4.1

Serverová část

Jak jsme si již uvedli výše, budeme implementovat již existující řešení. Zbývají nám však dva nové požadavky na funkcionalitu aplikace, které vyplynuly ze zkušeností z provozu. Nutno integrovat do mService - identifikace měřidla pomocí čtečky čárových kódů - modul umožňující inkaso dlužných částek a tisk příjmových dokladů Identifikace měřidla pomocí čtečky čárového kódu značně zrychlí proces identifikace zákazníka, nového plynoměru ve skladě a starého plynoměru na odběrném místě. Namísto zadávání několika ciferného čísla, případně výběru ze seznamu, bude identifikace okamžitě pomocí čtečky čárových kódů. Toto zlepšení poskytne vyšší uživatelský komfort montérům, kteří se mohou více zaměřit na svou práci, než na práci s PDA. Aplikace bude rozšířena o modul, který bude umožňovat inkaso dlužných částek a tisk příjmových dokladů. Důvodem tohoto řešení je to, že montér v tu chvíli bude schopen vyřešit pracovní příkaz na odpojení z důvodu neplacení, když se rozhodne zákazník zaplatit dluh, aniž by ho musel nutně odpojit od plynovodní sítě. Není to zcela drtivé procentu z hlediska celkových dlužných objemů, ale z hlediska počtu zákazníků se jedná o zhruba čtvrtinu lidí, kteří prostě zapomněli a nebo tomuto nevěnovali patřičnou pozornost. Typickými představiteli těchto neúmyslných dlužníků jsou starší lidé, žijící na venkovech, kteří nevyužívají moc služeb bank a pro které je značně složité, dostat se na poštu a nebo do obchodní kanceláře RWE. Pro tyto zákazníky je toto zkvalitněním poskytované služby.

Internet

GSM

APN


APN (RWE)

Firewall


Firewall RWE Demilitarizovaná zóna (DMZ) Symbol RWE – vnitřní síť

SAP IS-U Datové centrum

Obrázek č.8: Komunikační schéma – Mobilní pracovní příkazy

Zapnutí přístroje

Přihlášení do systému

Spuštění programu na PDA, kontrola přihlašovacích údajů

Přihlášení k serveru MPP, přijetí nových PP, odhlášení od serveru Přijetí PP ze serveru

Zpracování aktuálních PP, jejich řešení (příp. nevyřešení) u odběratele

Zpracování pracovních příkazů

Aktualizace pracovních příkazů

Zaznamenání odečtů

Tisk pracovních příkazů

Tisk pracovního příkazu (nebo seznamu PP) na mobilní tiskárně

Ukončení práce

Odeslání PP na server

Přihlášení k serveru MPP, odeslání PP ve zpracování, odhlášení od serveru

Odhlášení ze systému Ukončení programu na PDA

Vypnutí přístroje

Obrázek č.9: Schéma aplikace mService

Řešení - rozšíří se identifikace měřícího místa podle čísla měřidla sejmutého čtečkou čárového kódu - rozšíří modul skladu o identifikaci měřidel pomocí čtečky čárového kódu - rozšíří se interface o výši dluhu odběratele - v rámci interface bude zpět z PDA do informačního systému přenášen údaj o výši inkasa - rozšíří se mService o modul pokladna – detailní přehled o pohybech peněz během dne - přidá se tisková sestava umožňující tisk pokladních dokladů 4.4.2

Koncová zařízení

V této oblasti je nutno provést zásadní změnu. Jak se ukázalo, vybrané typy PDA i tiskáren jsou nevyhovující z hlediska odolnosti podmínkám využívání. Začněme jednodušší oblastí, kterou je výběr PDA. PDA Na trhu s PDA je situace taková, že primární cílovou skupinou jsou manažeři, nikoliv pracovníci v terénu. Přesto se na trhu začínají objevovat první přístroje, které jsou skutečně určeny pro využívání v drsných podmínkách. Bohužel malou konkurencí v tomto segmentu je cena příliš vysoká. Reálně by měla cena odpovídat maximálně dvojnásobku ceny obdobného přístroje v běžném provedení. To by umožňovalo i jednoduché rozhodování. Jsem schopen zničit více než dvě zařízení pouhým používáním? Pořídím si tedy odolnější přístroj … Z hlediska ceny toto však tak jednoduché není. Srovnám-li cenu doposud využívaného přístroje v rámci mService a tohoto odolnějšího produktu, vyjde mi děsivá skutečnost. Cena odolnějšího řešení je desetinásobně vyšší, než je cena obyčejného přístroje. Zde se nám již ukazuje to, co dělá s trhem nedostatečná konkurence v dané oblasti. Věřím, že časem se tento segment začne cenově srovnávat s manažerskými přístroji. Pro potřeby našeho řešení nám však nezbývá, než jeden z těchto odolných přístrojů vybrat. Důvodem není cena, protože si můžeme otevřeně říci, že 10 přístrojů za rok se nepodařilo zničit žádnému montérovi, natož aby se toto podařilo překonat úplně všem. Důvodem, proč musíme sáhnout pro dražší zařízení, je integrovaná čtečka čárového kódu. Je to další z věcí, která nám značně urychlí proces identifikace měřidla, zredukuje chybovost téměř na nulu a rovněž to bude mít i přínos z hlediska uživatele, kterému ubude nejhorší a nejdéle trvající činnost s PDA, kterou je právě identifikace pracovního příkazu a samotného měřidla v mobilním skladě.

Obrázek č.10: Průmyslové kapesní přístroje – Symbol

Obrázek č.11: Tiskárna HP DeskJet 450

Tiskárna Jak již bylo zmíněno v rámci vyhodnocení ročního provozu mService v SČP, byly značné problémy s tiskárnami HP DeskJet 450. Je to dáno tím, že trh není schopen nabídnou řešení v této oblasti skutečně pro potřeby outdoorového používání nebo dokonce pro průmyslový provoz. Při implementaci mService jsme pátrali po takovýchto zařízeních, ale marně. Podmínkou pro tiskárnu byl trvanlivý tisk, který by vydržel minimálně 5, nejlépe však 10 let. Navíc jsme požadovali produkt s možností tisku ve formátu A4, komunikující přes Bluetooth rozhraní a umožňující provoz na baterie. Jediné zařízení, které umožňovalo tyto požadavky rozumně splnit, byla právě tiskárna HP DeskJet 450. Záhy se však ukázalo, že tiskárna je příliš velká, křehká a není moc vhodná na nošení. V rámci rutinního provozu jsme montéry vybavili přenosnými brašnami právě pro přenos těchto tiskáren, které umožňovaly tisk i bez zbytečného vyndávání tiskárny ven. Přesto se však toto řešení nepříliš osvědčilo a spíše se začaly tiskárny stále více a více montovat na přístrojovou desku automobilů. Trochu nevýhodou tohoto řešení je to, že montér může tisknout pouze na vzdálenost cca 10 metrů, a musí do auta zajít pro dokumenty. V téhle situaci je to však jediné schůdné řešení, protože jinak musel montér zbytečně další brašnu. Ještě malým nedostatkem této tiskárny je provozní teplota, kdy se občas stávalo to, že při ponechání tiskárny přes noc v automobilu zaschla náplň inkoustu. To bylo operativně řešeno tím, že tiskárny jsou na noc ukládány mimo automobil – přispívá k tomu montáž do automobilu, usnadňující tuto manipulaci. Jsem si vědom, že v této oblasti je řešení značně nedokonalé. Bohužel momentálně není jiné lepší řešení, které by vyhovovalo specifickým potřebám. Řešení - koncové zařízení bude Symbol MT50 – průmyslová verze PDA se čtečkou čárového kódu - tiskárna bude dočasně využita stávající – HP DeskJet 450 – bude se hledat další řešení

4.4.3

Návrh bezpečnostních prvků

Zde platí to, co již bylo řečeno v předchozí částech, kapitole 2. odstavci 2.4.5 - Bezpečnost, proto pouze rychle zrekapitulujme to, co v dané oblasti vyplývá za návrh řešení. V rámci zkušeností z provozu mService v SČP se ukázalo jako nutné využití nějakého zálohovacího mechanismu řešícího hrozbu ztráty dat v případě nedostatku elektrické energie. Řešení pomocí nabíječek v automobilech má totiž jedno nebezpečí. Pokud bude využíváno rozumně, pouze v případě potřeby, nic se neděje. Pokud však bude toto řešení používáno tak, že pro jistotu bude neustále PDA dáváno k nabíjení a zase sundáváno k práci, může to mít zásadně negativní vliv na kapacitu a výdrž baterií.

Řešení - všechna PDA budou vybavena paměťovými kartami o velikosti 2 GB (SD, CompactFlash) - součástí všech PDA bude software pro automatický backup dat - zálohování (produkt Sunnysoft Backup Manager 4.0 - nastaven na zálohování při poklesu energie na 10 %) - součástí všech PDA bude software pro dvousložkovou předbootovací identifikaci - zabezpečení (produkt SafeBoot Enterprise pro PDA – stejné řešení bude použito i pro notebooky) - bude zřízen samostatný přístupový bod pro přístup ze sítě GSM do sítě RWE – privátní linka (APN pro přístup z GSM a přímý komunikační kanál mezi operátorem a RWE) - všechna PDA se budou připojovat pomocí APN RWE do demilitarizované zóny (tzv. DMZ) (v rámci DMZ budou mít přístup k intranetu a přes proxy server a firewall i do internetu) - všechna PDA budou mít zakázán jakýkoliv jiný způsob připojení (přímo do internetu) (omezením služeb poskytovaných operátorem na konkrétních SIM kartách

4.5 Zhodnocení

Zhodnoťme si nyní tuto část implementace řešení pro oblast údržby plynárenského majetku – mobilní pracovní příkazy. Tento případ byl hezkou ukázkou toho, kdy se dá s využitím již dostupných zdrojů poměrně efektivně docílit nového řešení, které reaguje na změny ostatních prostředků IT techniky. Nabízely se nám zde dvě varianty, z nichž jsme provedli výběr odpovídající skutečně reálnému rozhodování v běžné praxi. Našim úkolem bylo vytěžit maximum z dosavadních zdrojů, s vynaložením co nejmenších nákladů docílit co největších přínosů a při návrhu se zamyslet nad všemi možnými riziky a zkušenostmi z předchozích řešení. Myslím si, že se mi tohoto cíle v tomto případě podařilo dosáhnout, a že jsem mohl svůj návrh řešení demonstrovat i na skutečných poznatcích z projektu.

Navrhl jsem řešení … z hlediska finančních úspor - šetřící výrazným způsobem náklady na benzín a tiskoviny - šetřící výrazným způsobem mzdové náklady z důvodů optimalizace procesu - šetřící čas montérů pro samotné zpracování potřebných dokumentů - podporující snížení objemu dlužných částek za odběr plynu z hlediska procesní optimalizace - umožňující zrychlení celého procesu pracovních příkazů - umožňující automatické zpracování pořízených dat - umožňující centrální monitorování a koordinaci montérů - umožňující operativní řešení krizových situací – přeplánování - umožňující podporu právního vymáhání – inkaso dluhů - umožňující případný outsourcing mobilních pracovních příkazů mimo RWE z hlediska zvýšení kvality - poskytující rychlý a efektivní pracovní nástroj uživatelům - umožňující zredukovat byrokracii na přijatelné minimum

KAPITOLA 5.

ZÁVĚR

5.1

Stručná rekapitulace návrhů řešení

5.2

Zhodnocení přínosů a nedostatků řešení

5.3

Detekce možných rizik - pro realizaci

5.4

Závěr

5.1 Stručná rekapitulace návrhů řešení Rád bych zde zdůraznil jednu oblast společnou všem třem částem řešení, kterou bych záměrně uvedl jako automaticky nezbytnou část pro případně další oblasti implementace. Obecná pravidla pro řešení - vždy definovat standardy v oblasti PDA – platformu, operační systém, výrobce, konkrétní modely - implementovat bezpečnostní prvky v oblasti zálohování (Sunnysoft Backup Manager 4.0) zabezpečení (SafeBoot Enterprise a dvousložková předbootovací identifikace) komunikace (využití vlastního APN a přístup do internetu povolit pouze prostřednictvím sítě RWE) 5.1.1.

Část I. – Mobilní kancelář

Návrh řešení - sjednotit platformu poštovních serverů a provést centralizaci – pouze 1 server - cílová platforma je Microsoft Exchange Server - standardní zařízení PDA pro Mobilní kancelář je HP iPAQ HW6915 - naznačil jsem oblasti dalšího využití – budování webových aplikací pro PDA a využívání e-mailů 5.1.2.

Část II. – Sběr odečtů

Návrh řešení - sjednotit dosud dvě disjunktní oblasti – jedna aplikace pro oba typy odečtů - cílová platforma bude nově vyvinutá aplikace s interfacem do SAP IS-U - standardní zařízení PDA pro Sběr odečtů je Symbol MT50 - řešení je založeno na principu lokální databáze a vzdálených synchronizací - řešení umí využit čtečku čárového kódu k identifikaci měřidla v systému 5.1.3.

Část III. – Mobilní pracovní příkazy

Návrh řešení - cílová platforma bude řešení mService s nově vytvořeným interfacem do SAP IS-U - standardní zařízení PDA pro Mobilní pracovní příkazy je Symbol MT50 - řešení je založeno na principu lokální databáze a vzdálených synchronizací - řešení umí využit čtečku čárového kódu k identifikaci měřidla v systému

5.2 Zhodnocení přínosů a nedostatků řešení V podobném duchu, jako byl přehled, si nyní udělejme zhodnocení přínosů a nedostatků řešení. Zase budeme hodnotit zvlášť po jednotlivých oblastech. Přínosy a nedostatky + jednotnost v údržbě, provozu a využití IT (definice standardů pro oblast PDA aj.) + zvýšení bezpečnosti (implementace zálohování, zabezpečení a bezpečné komunikace) 5.2.1


Přínosy a nedostatky + jednotná platforma, společné řešení pro RWE (centralizace poštovního serveru) + možnost dalšího využití (webové aplikace pro PDA a využívání e-mailů) + řešení pro podporu manažera (umožňuje úplné fungování mimo kancelář) + zvýšení komfortu práce uživateli - platforma Microsoft je obecně cílem nejvíce útoků virů a hackerů (poštovní server) - centralizace serveru – dostupnost služby závisí více na IT infrastruktuře 5.2.2


Přínosy a nedostatky + zjednodušení a zrychlení procesu odečtů – zkrácení doby fakturace + zefektivnění – jedno řešení pro oba typy odečtů + snížení chybovosti – při pořízení i při používání čtečky čárového kódu k identifikaci měřidla + snížení chybovosti – při použítí IrDA pro přenos odečtů + snížení provozních nákladů (benzín, papír, pracovní síla) + možnost provozu i v pohraničních oblastech s nízkou úrovní signálu GPRS (off-line) 5.2.3


Přínosy a nedostatky + implementování již ověřeného řešení – pouze částečná modifikace + zjednodušení a zrychlení procesu údržby sítě + snížení chybovosti – při použítí čtečky čárového kódu k identifikaci měřidla + snížení provozních nákladů (benzín, papír, pracovní síla) + možnost provozu i v pohraničních oblastech s nízkou úrovní signálu GPRS (off-line)

5.3 Detekce možných rizik – pro realizaci Podívejme se na to opět po jednotlivých oblastech. Možná rizika - standardy PDA – chybně definovaný standard může způsobit větší problémy než žádný standard 5.3.1


Možní rizika - může se dramaticky zvýšit objem útoků na poštovní serve Microsoft Exchange Server - může se dramaticky zvýšit zátěž na IT infrastrukturu v důsledku centralizace 5.3.2


Možná rizika - v případě nějaké pokrokové technologie u výrobců plynoměrů může nastat problém s aplikací 5.3.3


Možná rizika - problém při změně rozhraní – ideální je otevřené řešení, připravenost na změny

5.4 Závěr Závěrem bych chtěl zhodnotit své zkušenosti z práce na této studii. Snažil jsem se být co nejvíce objektivní, nezaujatý a otevřeně hledat nejen pozitiva mnou navržených řešení, ale i jejich negativa a slabé stránky. Je lepší o těchto slabých stránkách dopředu vědět a případně se je snažit eliminovat jiným způsobem. Byl jsem rád, že jsem mohl v rámci této diplomové práce využít své bohaté zkušenosti z implementací těchto zařízení v rámci plynárenství, podpořené opravdu bohatými zkušenostmi z vedení dvou takovýchto projektů. Oblast IT není statická, naopak je to jedno z nejdynamičtějších odvětví průmyslu vůbec, tudíž i mnou navržená řešení mohou při samotné realizaci doznat drobných změn v důsledku objevení se nových technologií. Snad tato práce poslouží jako pomocník při rozhodování o strategických cílech v oblasti IT, při přípravě projektů v oblasti využití kapesních počítačů nebo poslouží jako případný podnět k hledání dalších možností využití i v jiných oblastech – nejen v ryze průmyslových. Věřím, že tato technologie má velmi bohatou budoucnost a bude se stále více stávat součástí našeho všedního života.

KAPITOLA 6.

PŘÍLOHY

6.1

Přehled kapesních počítačů využívaných RWE v ČR

6.2

Příslušenství kapesních počítačů

6.3

Přehled mobilních technologií GPRS, EDGE

6.4

Benchmark technologií GPRS a EDGE

6.5

Vývoj technologie Bluetooth

6.1 Přehled kapesních počítačů v RWE Cassiopeia E-100 / Cassiopeia E-125 Kapesní počítač s operačním systémem Windows CE verze 3.0, procesorem NEC VR4122 na frekvenci 150 MHz, 16 MB ROM paměti a 32 MB RAM paměti a barevným, podsvíceným displejem s rozlišením 240 x 320, schopným zobrazit 65 536 barev. Kategorie Výrobce OS Rozměry Hmotnost Ovládání Procesor Paměť ROM Paměť RAM Displej Rozlišení Barevnost Sloty Rozhraní Baterie Výdrž

Pocket PC Casio Windows CE 3.0 83 x 131 x 20 mm (š x v x t) 255 g Dotykový displej NEC VR4122 150 MHz 16 MB 32 MB podsvícený barevný LCD 240 x 320 65 536 barev Compact Flash RS232, USB, InfraRed NiMH 6 h (na baterie)

Použití: Byl využíván v minulosti pro zajištění sběru odečtů VO/SO. Pro přenos dat z přepočítávače do PDA byl používán IrDA port, pro následný přenos dat z PDA do počítače byla používána synchronizační kolébka. Zařízení, včetně vyčítacího software pro přepočítávače bylo přímo součástí dodávky přepočítávačů. Byly to prvopočátky průmyslového využívání PDA v plynárenství v ČR. Výhody / Nevýhody: +/-

v přístroji se používaly klasické AA baterie

-

choulostivý systémový konektor vespod přístroje – často se vylamoval

-

absence GSM/GPRS modulu

-

nekompatibilita jednotlivých verzí Windows CE

-

malé množství na trhu, nedostatkové zboží, nešlo doobjednat

-

neexistující autorizovaný servis

HTC Qtek 9090 / T-Mobile MDA III / Eurotel DataPhone III Kapesní počítač s operačním systémem Windows Mobile 2003, procesorem Intel PXA263 na frekvenci 400 MHz, 32 MB ROM paměti a 128 MB RAM paměti a barevným, podsvíceným displejem s rozlišením 240 x 320, schopným zobrazit 65 536 barev. Pocket PC HTC Windows Mobile 2003 72 x 125 x 19 mm (š x v x t) 205 g Dotykový displej, vysouvací klávesnice Intel PXA263 400 MHz Procesor Paměť ROM 128 MB Paměť RAM 128 MB podsvícený barevný LCD Displej 240 x 320 Rozlišení 65 536 barev Barevnost SD Sloty RS232, USB, InfraRed, Rozhraní Bluetooth, WiFi Li-Ion Baterie 4h hovoru, 16h práce Výdrž Kategorie Výrobce OS Rozměry Hmotnost Ovládání

Použití: Tento přístroj se stal v minulosti nejrozšířenějším PDA využívaným v RWE. Sloužil jako základ pro mobilní kancelář – přístup do pošty, kontaktů a kalendáře. K velké rozšíření přispělo to, že produkt byl nabízen jako dotovaný přístroj dvěma operátory. Z dalších aplikací na něm byly v minulosti provozovány odečty VO/SO (nahradil Cassiopeiu E-125) a aplikace Mobilních pracovních příkazů. Hlavně mezi manažery oblíbený přístroj. Výhody / Nevýhody: +

integrován GSM/GPRS modul

+

podpora Bluetooth a Wi-Fi

+

příznivá cena, prodej jako dotovaný přístroj u dvou operátorů

+

široká nabídka příslušenství

+

vysouvací klávesnice

-

choulostivý konektor – časem se opotřebovával a poté i vylamoval

Symbol MT50 Společnost Symbol uvedla dva nové Pocket PC handheldy (první s oládacím křížem a aplikačními tlačítky, druhý s QWERTY klávesničkou), které nabízejí OS Windows Mobile 2003, 520 MHz procesor typu Intel PXA270, 64 MB RAM, 64 MB ROM, SD/MMC slot s podporou SDIO, displej rozlišení 240 x 320 pixelů, 1560 mAh akumulátor a Wi-Fi modul. Obě PDA lze koupit ve 2 x 3 modifikacích: NAV 1D, 2D Imager a CCD Camera a QWERTY 1D, 2D Imager a CCD Camera lišících se přítomností ovladače či klávesničky a integrovaného digitálního fotoaparátu 0,3 resp. 1,1 Mpix. Jedná se o PDA outdoorová a pracovní, takže jim neuškodí ani věci jako je třeba pád z 1 m. Kategorie Výrobce OS Rozměry Hmotnost Ovládání Procesor Paměť ROM Paměť RAM Displej Rozlišení Barevnost Sloty Rozhraní Baterie Výdrž

Pocket PC Symbol Technologies Windows Mobile 2003 ? x ? x ? mm (š x v x t) ??? g Dotykový displej, klávesnice Intel PXA270 520 MHz 64 MB 64 MB podsvícený barevný LCD 240 x 320 65 536 barev SD / MMC RS232, USB, InfraRed, Audio Out, Bluetooth, WiFi, Barcode NiMH 4h hovoru, 16h práce

Použití: Tento přístroj se objevil na konci loňského roku jako outdoorová varianta PDA. Pro poněkud vyšší cenu se zatím nenasazuje plošně, je to však vhodný nástupce PDA Qtek 9090 od HTC. Jako jedno z mála zařízení na trhu, má tento přístroj integrován čtečku čárového kódu. Výhody / Nevýhody: +


+

podpora Bluetooth a Wi-Fi

+

outdoorové provedení

+

čtečka čárového kódu

-

velmi vysoká cena, neodpovídající užitné hodnotě

HP iPAQ HW6915 Kapesní počítač s operačním systémem Windows Mobile 2005, procesorem Intel PXA270 na frekvenci 416 MHz, 128 MB ROM paměti a 64 MB RAM paměti a barevným, podsvíceným displejem s rozlišením 240 x 320, schopným zobrazit 65 536 barev. Jedná se o kombinaci mobilního telefonu, fotoaparátu, PDA a navigace GPS. Všechny tyto funkce jsou v jednom zařízení. Kategorie Výrobce OS Rozměry Hmotnost Ovládání Procesor Paměť ROM Paměť RAM Displej Rozlišení Barevnost Sloty Rozhraní Baterie Výdrž

Pocket PC Hewlett-Packard Windows Mobile 2005 71 x 118 x 18 mm (š x v x t) 175 g Dotykový displej, klávesnice Intel PXA270 416 MHz 64 MB 64 MB podsvícený barevný LCD 240 x 240 65 536 barev mini SD GSM, USB, IrDA, Bluetooth, WiFi, GPS Li-Ion 6h hovoru, 20h práce

Použití: Tento přístroj se má stát náhradou přístroje Qtek 9090 od HTC v oblasti manažerských aplikací – mobilní kancelář apod. HP bylo v této oblasti vždy významným výrobcem. Uvidíme, zda si tento přístroj toto uznání zaslouží. Výhody / Nevýhody: +


+

podpora Bluetooth, Wi-Fi a GPS

+

vysoká úroveň podpory od výrobce HP

+


+

pevná klávesnice

-

menší rozměry a rozlišení displeje (na úkor klávesnice)

HP iPAQ HX2790 Kapesní počítač s operačním systémem Windows Mobile 2005, procesorem Intel PXA270 na frekvenci 624 MHz, 192 MB ROM paměti a 64 MB RAM paměti a barevným, podsvíceným displejem s rozlišením 240 x 320, schopným zobrazit 65 536 barev. Jedná se o kombinaci mobilního telefonu, fotoaparátu a PDA. Všechny tyto funkce jsou v jednom zařízení. Kategorie Výrobce OS Rozměry Hmotnost Ovládání Procesor Paměť ROM Paměť RAM Displej Rozlišení Barevnost Sloty Rozhraní Baterie Výdrž

Pocket PC Hewlett-Packard Windows Mobile 2005 77 x 119 x 16 mm (š x v x t) 164 g Dotykový displej, klávesnice Intel PXA270 624 MHz 192 MB 64 MB podsvícený barevný LCD 240 x 240 65 536 barev SD/MMC, CompactFlash GSM, USB, IrDA, Bluetooth, WiFi, GPS Li-Ion 6h hovoru, 20h práce

Výhody / Nevýhody: +

podpora Bluetooth, Wi-Fi

+


+


+

biometrický senzor

-

velký displej

-

chybí GSM/GPRS modul

HP iPAQ RW6815 Kapesní počítač s operačním systémem Windows Mobile 2005, procesorem Intel PXA272 na frekvenci 416 MHz, 128 MB ROM paměti a 64 MB RAM paměti a barevným, podsvíceným displejem s rozlišením 240 x 320, schopným zobrazit 65 536 barev. Jedná se o kombinaci mobilního telefonu, fotoaparátu a PDA. Všechny tyto funkce jsou v jednom zařízení. Kategorie Výrobce OS Rozměry Hmotnost Ovládání Procesor Paměť ROM Paměť RAM Displej Rozlišení Barevnost Sloty Rozhraní Baterie Výdrž

Pocket PC Hewlett-Packard Windows Mobile 2005 102 x 58 x 19 mm (š x v x t) 140 g Dotykový displej, klávesnice Intel PXA272 416 MHz 128 MB 64 MB podsvícený barevný LCD 240 x 240 65 536 barev mini SD GSM/EDGE, USB, IrDA, Bluetooth, WiFi Li-Ion 6h hovoru, 20h práce



+

podpora Bluetooth, Wi-Fi

+


+


-

menší rozměry a rozlišení displeje

HP iPAQ RX5900 Kapesní počítač s operačním systémem Windows Mobile 2005, procesorem Samsung SC32442 na frekvenci 400 MHz, 2 GB ROM paměti a 64 MB RAM paměti a barevným, podsvíceným displejem s rozlišením 240 x 320, schopným zobrazit 65 536 barev. Jedná se o kombinaci PDA a navigace GPS. Všechny tyto funkce jsou v jednom zařízení. Kategorie Výrobce OS Rozměry Hmotnost Ovládání Procesor Paměť ROM Paměť RAM Displej Rozlišení Barevnost Sloty Rozhraní Baterie Výdrž

Pocket PC Hewlett-Packard Windows Mobile 2005 120 x 76 x 16 mm (š x v x t) 175 g Dotykový displej, klávesnice Samsung SC32442 400 MHz 2 048 MB 64 MB podsvícený barevný LCD 240 x 240 65 536 barev SD/MMC USB, Bluetooth, WiFi, GPS Li-Ion 6h hovoru, 20h práce


podpora Bluetooth, Wi-Fi a GPS

+


+


+

velký displej

-

chybí GSM/GPRS modul

ASUS R2H (a jaká bude budoucnost ???) Tento přístroj sice nepatří do segmentu kapesních počítačů, přesto se jedná o zajímavou alternativu pro ty, kteří se nemohou rozhodnout mezi využíváním notebooku a kapesního počítače. Jedná se o tzv. ultrapřenosný počítač. Kategorie Výrobce OS Rozměry Hmotnost Ovládání Procesor Paměť RAM HDD Displej Rozlišení Barevnost Sloty Rozhraní Baterie Výdrž

Ultrapřenosné PC ASUS Windows XP Tablet Edition 234 x 133 x 28 mm (š x v x t) 830 g Dotykový displej Intel ULV Celeron M 900 MHz 768 MB 60 GB podsvícený barevný TFT 800 x 480 (max. 1024 x 768) 16 mil. barev SD, ext. DVD-CD mechanika GSM, USB, Bluetooth, LAN, WiFi, GPS, VGA, A/V-Out Li-Pol 2h práce

Tento přístroj zde uvádím pouze pro zamyšlení, kam se vývoj kapesních počítačů může dále ubírat. Trend je zřejmý, zmenšování ve všech partiích kromě displeje … zde je naopak trend takový, aby displej zabíral co největší část přístroje a umožňoval co nejlepší možné zobrazení. Jak na Vás tento přístroj působí? Mně osobně by se jako alternativa za notebook a PDA něco podobného líbilo. Uvidíme, třeba tudy bude postupovat další vývoj PDA …

6.2 Příslušenství kapesních počítačů Velmi důležitou vlastností všech prostředků výpočetní techniky je jejich rozšiřitelnost hardwarovými a softwarovými prostředky. Kapesní počítače nejsou v tomto směru výjimkou, nabízí se k nim velké množství různého příslušenství. Níže si uvedeme základní typy příslušenství, které nám mohou pomoci v efektivnější práci s kapesním počítačem. Nabíječky Velmi důležitou součástí každého zařízení je zdroj elektrické energie, kapesní počítače nejsou v tomto směru žádnou výjimkou. Standardním příslušenstvím každého kapesního počítače je síťový nabíječ. Některé modely jsou vybaveny výměnnými koncovkami pro možnost připojení do elektrické sítě v různých zemích světa. Pro někoho může být velmi zajímavou alternativou napájení z konektoru cigaretového zapalovače v automobilu, popřípadě z USB portu počítače.

Synchronizační kolébka, kabel Kdysi bylo standardem vybavovat kapesní počítače synchronizačními kolébkami, které ovšem bylo nepraktické vozit na cesty. Z praktických důvodů se od tohoto řešení definitivně ustupuje a synchronizace bývá řešena připojením klasického USB kabelu, který umožňuje současně i napájení zdroje energie, nebo bezdrátovými technologiemi. Tyto technologie zaznamenávají v posledních letech obrovský rozmach, jistě za tuto skutečnost vděčí i velké úrovni uživatelského komfortu při samotné synchronizaci.

Klávesnice Přestože drtivá většina všech kapesních počítačů je vybavena softwarovou klávesnicí, která umožňuje pomocí dotykového displeje a ovládacího pera zadávat libovolné znaky abecedy, nemusí tento způsob vyhovovat každému uživateli. Další z možných variant, jak zadat text do kapesního počítače, je psaní písma stejně jako na papír a jeho automatické rozpoznání pomocí SW uvnitř kapesního počítače. Tato možnost vyžaduje od uživatele značnou zkušenost a souhru s přístrojem, neboť je nutné opravdu striktně dodržovat psanou formu jednotlivých znaků. Některé z modelů mají hardwarové klávesnice.

Integrace tohoto příslušenství přímo do přístroje znamená ovšem jistá omezení. Klávesnice může být například výklopná, což vede k větší tloušťce samotného přístroje. Druhou variantou je umístění klávesnice na přední stranu PDA přímo pod displejem. Tato varianta znamená omezení v podobě použití menšího displeje. Poslední, pro řadu uživatelů velmi zajímavou možností, jak provádět vkládání textu klasickým způsobem pomocí všech deseti prstů, je připojení „plnohodnotné“ externí klávesnice. Připojení těchto klávesnic může být přes konektor, kdy tato klávesnice slouží rovnou jako taková polohovací kolíbka nebo držák, nebo pomocí bezdrátové technologie – jako např. Bluetooth. Dokonce existují i virtuální klávesnice, které pouze pomocí laseru promítjí na plochu stolu tlačítka a které pomocí snímání polohy prstů detekují stisknuté tlačítko.

Ovládací pero - stylus Nedílnou součástí snad každého kapesního počítače je dotykové pero – tzv. stylus. Jedná se o tenký, lehký a skladný ovládací prvek připomínající tužku na psaní. Namísto psací části je však u stylusu použit hrot z umělé hmoty. Snahou je dosáhnout stejného komfortu jako při psaní tenkým perem, přitom nezpůsobit při jeho používání na přístroji poškození displeje. Z tohoto důvodu se dotykové displeje polepují tzv. krycími fóliemi, které chrání dotykovou obrazovku před fyzickým poškozením v podobě škrábanců. Tyto ochranné fólie je možné během života přístroje obnovovat – stačí vždy strhnout a nalepit novou fólii. Podobně, jak lze nahrazovat ochranné fólie, lze nahrazovat i stylus. Buď lze dokoupit přesně stejný typ s původním, nebo například jiný stylus. Na trhu existují např. vícefunkční pera, která umožňují psaní perem nebo tužkou a která mají i jako jednu z možností umělohmotný hrot, který lní funkci stylusu. Jinou možnou kombinací je např. kombinace s laserovým ukazovátkem.

Paměťové karty Nezbytnou výbavou každého kapesního počítače je slot pro paměťové karty. Je velmi důležité mít možnost rozšířit kapacitu přístroje o další paměťové médium pro ukládání dat. Standardů těchto paměťových karet je více, záleží na konkrétním výrobci, jaký standard chce podporovat. Některé

paměťové karty se liší rozměry a tím rovněž i kapacitou dat, kterou jsou schopny uložit. Jako nejznámější standardy paměťových karet si uvedeme SecureDigital (SD), MultiMedia Card (MMC) a CompactFlash (CF). Maximální kapacitou paměťových karet SD a MMC jsou 4 GB, což odpovídá téměř 6 CD nebo 1 DVD. U paměťových karet CF je tato kapacita díky větším rozměrům samotných karet vyšší – aktuální maximální kapacita je 8 GB. Toto jsou již dostatečné kapacity k tomu, aby bylo možné do kapesního přístroje uložit opravdu velké množství dat.

Pouzdra Toto příslušenství může být vnímáno jako luxusní doplněk k PDA a nebo jako ochrana proti poškození ve zhoršených podmínkách. Pouzdra se nabízejí v různých provedením co se tvaru a materiálu týče. Nejčastěji používaná jsou kožená pouzdra, která pouze ochraňují PDA před mechanickým poškozením a lehkými pády.

GPS přijímač

Jedním z dalších využití PDA je navigace při cestování. Pro tyto účely je nezbytným příslušenstvím GPS přijímač. Některé modely PDA mají tento GPS přijímač již integrován v samotném PDA. K ostatním PDA je nutné GPS přijímač připojit např. pomocí Bluetooth rozhraní.

6.3 Vývoj komunikačních technologií Mobilní komunikace dneška a budoucnosti Stejně jako počítače, operační systémy nebo programovací jazyky, stejně tak i mobilní sítě prošly velkým a znatelným vývojem. Jednotlivé etapy vývoje mobilních sítí můžeme rozčlenit do tzv. generací. Můžeme rozlišit několik generací mobilních sítí, od čistě analogových NMT sítí, přes plně digitální sítě postavené na standardu GSM, až po sítě tzv. 3. generace (3G), které se začínají rozšiřovat. Jednotlivé generace se od sebe liší především frekvencí, ve které pracují, přenosovou rychlostí a způsobem komunikace mezi mobilním zařízením a příslušnou základnovou jednotkou. V následující tabulce je uveden stručný přehled technologií mobilních sítí. Tabulka č.1 – Mobilní technologie – přehled generací Generace

Technologie

1G 2G

NMT GSM/CSD GSM/HSCSD

2,5G 2,75G (3G) 2,75G (3G)

GPRS EDGE CDMA 450 (CDMA1x-EV-DO) UMTS

3G

CDMA 2000 - CDMA2000-1x -CDMA2000-1xEV-DO -CDMA2000-1xEV-DV -CDMA2000-3xRTT

Přenosová frekvence [MHz] 450 (900) 890 – 915 935 – 960 1 710 – 1 785 1 805 – 1 880 900, 1 800 900, 1 800 450

Rychlost přenosu dat [kbit/s] pouze hlas 9,6 max. 115, běžně 43

TDD: 1 900 – 1 920 FDD: 1 920 – 1 980 Satelity: 1 980 – 2 010 TDD: 2 010 – 2 025 FDD: 2 110 – 2 180 Satelity: 2 170 – 2 200 450, 800 1 700, 1 900 2 100

max. 2 048

max. 171, běžně 54 max. 384, běžně 100 max. 800, běžně 250

153, 307 max. 2440, běžně 500-700 max. 5000, běžně 1200 max. 2000

GPRS ( General Packet Radio Service) GPRS technologie je komunikační nadstavbou klasické GSM technologie, která byla a je primárně určena pro přenos telefonních hovorů. GPRS umožňuje v rámci již existující GSM sítě přenášet data. Technologie jako GPRS a EDGE nenahrazují technologii GSM, pouze se z ní snaží efektivně vydolovat maximum tím, že organizují přenosy úspornějším způsobem a lépe využívají dostupné kapacity.

GPRS funguje na principu přepojování paketů. Pakety jsou malé datové balíčky, které znají svou cestu, umí putovat nezávisle na sobě ke svému cíli, kde se opět spojují do jednoho celku. GPRS využívá existující síť základnových stanic BTS. Umožňuje zpřístupnit uživateli několik timeslotů nebo paralelních kanálů současně. Jejich množství záleží na momentálním zatížení dané BTS stanice a samozřejmě i na možnostech komunikačního zařízení. V pravidelném cyklu je na BTS stanici k dispozici 8 timeslotů, jež jsou uživatelům střídavě zapůjčovány při telefonování prostřednictvím GSM sítě. Sloty, které nejsou právě použity, jsou dočasně poskytnuty k zajištění přenosu dat. Pokud v daném okamžiku v dané buňce nejsou volné žádné sloty, rychlost přenosu dat dramaticky klesá až k nule – jedná se o negarantovaný přenos. Jakmile dojde k uvolnění některého z obsazených timeslotů, datový přenos se opět obnoví. Teoreticky může být využito všech 8 timeslotů v obou směrech (GPRS 8+8) a dosaženo tak teoretické rychlosti až 171,2 kb/s v každém směru. V praxi se však využívají pouze timesloty 4. Podle toho, kolik časových úseků je schopno dané zařízení podporující přenos GPRS obsloužit, se GPRS dělí do tzv. GPRS tříd. Označení: GPRS 3+1 (současná konfigurace většiny telefonů), GPRS 4+2…: první číslo udává počet timeslotů, které lze spojit při komunikaci směrem k uživateli (down-link), druhé číslo pak udává počet timeslotů, které lze spojit při komunikaci směrem od uživatele (up-link). Kromě spojování timeslotů je možno využít pro přenos i více než 1 kanál. Teoreticky lze sdružit až 8 pásem, zvolená varianta GPRS se označuje CS1 – CS4 (Coding scheme). GPRS se využívá pro doručování obsahu wapových serverů, pro přenos multimediálních zpráv MMS a samozřejmě slouží i pro mobilní připojení k internetu. Narozdíl od technologií CSD a HSCSD, kde uživatel platí poplatky za dobu připojení, je GPRS tarifikováno podle objemu přenesených dat. Uživatel se tudíž nemusí ohlížet na to, jak dlouho dané připojení probíhá. Velkou nevýhodou však je negarantovaný přenos a případně kolísající rychlost připojení, která může být v některých okamžicích i zcela nulová.

EDGE (Enhanced Data Rates for GSM Evolution) EDGE je technologie, která sama o sobě ještě neznamená takový skok kupředu, že by se dala považovat za technologii 3. generace (3G). Stejně jako technologie GPRS využívá i technologie EDGE již existující síť GSM s BTS stanicemi, danými frekvenčními pásmy, šířkou přenosových kanálů a timesloty. Obdobně jako technologie GPRS i technologie EDGE uplatňuje slučování timeslotů a využívání více kanálů. Inovací, kterou EDGE oproti technologii GPRS přináší, je však způsob modulace. Nahrazuje původní dvoustupňovou modulaci GMSK (Gaussian Minimum Shift Keying), která je použita v GPRS, efektivnější osmi úrovňovou fázovou modulací EPSK (Eight-phaseshift keying). Díky použití této modulace se zvyšuje rychlost v rámci jednoho timeslotu na 48kbit/s,

při optimálních podmínkách může být až 69,2 kbit/s. Celková maximální rychlost přenosů dat pomocí technologie EDGE tak může dosáhnout maximálně až 384 kbit/s při využití všech 8 slotů a dobrých přenosových podmínkách. Implementace technologie EDGE vyžaduje nejen změnu SW, ale i po stránce HW vyžaduje přidání dodatečného transceiveru.

UMTS (Universal Mobile Telephone System) UMTS systém je považován za klíčovou součást standartu IMT-2000. Představuje podstatný evoluční skok od sítí 2. generace. Jedná se o plně vysokorychlostní multimediální telekomunikační technologii nové generace, tzv. 3G. Na vývoji UMTS se podílela společnost NortelNetwork ve spolupráci s British Telecommunication (BT). Hlavními rozdíly oproti 2G sítím jsou: -

rozšířené frekvenční spektrum

-

vysoká přenosová rychlost (až 2Mbit/s)

-

kvalitní multimediální služby

-

celoplošné pokrytí (pozemní i satelitní komponenty)

-

plnohodnotný roaming (VHE - Virtual Home Environment - uživatel je schopen přecházet mezi sítí svého domácího operátora a sítí jiných UMTS operátorů, aniž by poznal rozdíl, má k dispozici veškeré služby v plné kvalitě).

VHE - Virtual Home Environment – pro uživatele to znamená možnost přecházet mezi sítí svého domácího operátora a sítí jiných UMTS operátorů, aniž by poznal rozdíl. I při těchto přechodech mezi sítěmi poskytovatelů technologie UMTS má vždy k dispozici veškeré služby v plné kvalitě. UMTS sítě byly navrženy tak, aby umožňovaly určitou kompatibilitu s GSM. Pracují s vyššími frekvencemi než GSM, proto je potřeba vybudovat zcela novou infrastrukturu. Některé z typů novějších BTS stanic GSM sítě jsou však schopny pracovat i s UMTS frekvencemi, čímž se mohou rovnou stát součástí obou infrastruktur.

6.4 Benchmark technologií GPRS a EDGE GPRS

EDGE

6.5 Vývoj technologie Bluetooth Infračervený port (IrDA - Infrared Data Association) Infrared Data Association, známá pod zkratkou IrDA, je organizace, která definuje standardy komunikačních protokolů pro přenos dat na krátkou vzdálenost prostřednictvím infračerveného záření. Standardy se posléze označují také zkratkou IrDA. Tyto standardy se používají pro tzv. osobní sítě (PAN), pro komunikaci s mobilními telefony, kapesními počítači apod. Komunikace pomocí IrDA vyžaduje mezi komunikujícími přístroji přímou viditelnost, má velmi omezený dosah (cca 1 metr) a poměrně nízkou přenosovou rychlost (2,4 kbit/s až 16 Mbit/s). Tento způsob připojení pomalu ustupuje modernějším způsobům připojení, nevyžadujícím přímou viditelnost mezi vzájemně komunikujícími stranami. V současnosti je téměř každý mobilní telefon a kapesní počítač vybaven infračerveným portem (IrDA), ale pomalu se stává standardem vybavovat zařízení i Bluetooth rozhraním (BT).

Bluetooth Název „Bluetooth“ vznikl jako připomínka dánského krále Haralda Blatanda (v anglickém jazyce přezdívaného Harold Bluetooh), který žil v letech 940 až 981. Svou přezdívku si vysloužil díky své velké zálibě v pojídání borůvek a ostružin. Ale proč byl právě pro název nové technologie vybrán tento panovník? Zasloužil se totiž o sjednocení různorodých a vzájemně válčících kmenů na území dnešního Norska, Švédska a Dánska. A právě toto sjednocení různorodých technologií bylo od počátku i záměrem zakladatelů. Podařilo se jim sjednotit technologie výrobců do jednoho standardu, který umožňuje vzájemně komunikovat zařízením z různých odvětví průmyslu – např. výroby počítačů, výroby mobilních telefonů, automobilového průmysl, hudebního průmyslu atd.

Vznik této technologie sahá do roku 1994, kdy zveřejnila společnost Ericsson studii zabývající se náhradou kabelových spojení mezi mobilními telefony a jejich příslušenstvím. V září 1998 byla založena skupina BSIG (Bluetooth Special Interest Group), do které původně patřilo pouze pět významných výrobců – IBM, Toshiba, Intel, Ericsson a Nokia. V současnosti patří do skupiny více než 6.000 společností a firem působících v různých odvětvích průmyslu – od výrobců počítačů a

mobilních telefonů, přes dodavatele telekomunikačních technologií, až po společnosti z prostředí automobilového nebo hudebního průmyslu. Společnou myšlenkou zakladatelů bylo vytvořit levné, energeticky nenáročné, bezdrátové spojení na krátkou vzdálenost, nahrazující množství datových kabelů s různými konektory od různých výrobců. Dalším vývojem byly moduly vybavené obecně dostupnými přístupovými body pro data a řeč a byly upraveny tak, aby mohly vytvářet příležitostné sítě – tzv. Ad-hoc sítě. První verze specifikací byla uvolněna v červenci roku 1999 a první výrobky implementující tuto verzi specifikace přišly na trh během roku 2000. V červenci 2001 byla publikována verze 1.1, která se od verze 1.0 lišila jen drobnými detaily. V listopadu 2003 vznikla další verze, verze 1.2, která se lišila rychlejším připojením a adaptivním FH (Frekvence hopping). Zatím poslední verze specifikace, verze 2.0 z konce roku 2004, má přidánu podporu EDR (Enhanced Data Rate) a umožňuje tak ještě vyšší přenosové rychlosti než doposud (až 3Mb/s). Popis fungování Bluetooth Jak bylo zmíněno již v úvodu, Bluetooth komunikuje v bezlicenčním pásmu 2,4 GHz (IndustrialScientific-Medical band - ISM), konkrétně v rozsahu 2,4000 GHz - 2,4835 GHz. Komunikační kanály jsou od sebe vzdáleny 1 MHz, což znamená, že kanálů použitelných aplikacemi Bluetooth je celkem 79. Za účelem potlačení interference s dalšími signály, používá metodu kmitočtových skoků (FHSS) s rychlostí 1600 skoků za sekundu (po 625 mikrosekundách). Frekvence se mění po každém přenosu – odeslání a příjmu – čímž je zajištěna větší kvalita spojení. Modulace signálu je prováděna pomoví Gaussovské modulace s frekvenčním klíčováním (GFSK). Verze 1.2 používá adaptivní přeskakování mezi kmitočty (AFH), které je speciálně určeno pro omezení rušení mezi bezdrátovými technologiemi v bezlicenčním pásmu 2,4 GHz. Verze 2.0 EDR používá jako rozšíření pro zvýšení přenosové rychlosti modulace PSK (Phase Shift Keying) a to π/4-DQPSK pro rychlosti do 2Mb/s a 8DPSK pro rychlosti až 3Mb/s. Standard Bluetooth rozlišuje dva stavy. Stav Master získá to zařízení, které se v konkrétním prostoru aktivuje jako první. Ostatní, které se dostanou do jeho dosahu, získávají stav Slave a jejich komunikace je řízena zařízením Master. Ten pak rovněž řídí frekvenční skoky, sestavuje komunikaci mezi ostatními čipy a přiděluje komunikační kanály. Pokud Master zjistí nějakou aktivitu ve svém okolí, začne na 16 frekvencích vysílat a to tzv. Page (pokud zná konkrétní adresu druhého zařízení), nebo Inquiry (pokud o druhém zařízení nic neví). Když nedostane žádnou odpověď, začne vysílat na dalších 16 frekvencích. Nejpozději do 2,56s od začátku vysílání by se měla obě zařízení domluvit na komunikaci. Jeden Master dokáže řídit až sedm zařízení Slave. Takto vytvořeným sítím se říká piconet a je možné je propojit přes zařízení v módu Slave, která dokáží komunikovat se dvěma Mastery, a tak

vytvořit rozsáhlejší síť nazývanou scatternet. Verze 1.2 také nabízí rozšířenou podporu pro kvalitu služby (QoS), což je velmi důležité pro provoz citlivý na zpoždění jako hlas nebo živé video. Bluetooth používá pro definování oblasti použítí daného zařízení tzv. profily. Ty zajišťují vzájemnou slučitelnost zařízení na nejvyšší softwarové úrovni. Aby zařízení mohla komunikovat, musí podporovat obě komunikující strany stejný profil. Maximální rychlost a dosah Maximální přenosová rychlost hlasu je realizována synchronním spojením o rychlosti 64 kbit/s v obou směrech. Data jsou přenášena v asynchronním módu a to buďto asymetricky - jeden směr rychlostí 723 kbit/s a opačný směr 57,6 kbit/s, nebo symetricky s rychlostí 432,6 kbit/s pro oba směry. Tabulka č.1 – Bluetooth – přenosové rychlosti Typ kanálu

Přenos

Rychlost [kbit/s]

Použití

asynchronní

symetrický

432,6 / 432,6

přenos dat

asynchronní

asymetrický

721,0 / 57,6

přenos dat

synchronní

symetrický

64,0 / 64,0

přenos zvuku

Maximální dosah Bluetooth se liší podle třídy (Class), do které zařízení spadá. Tyto třídy jsou definovány podle maximálního výstupního výkonu. Třída 1 s dosahem 100 m a maximálním výkonem 100 mW, Třída 2 s dosahem 50 m a max. výkonem 2,5 mW a Třída 3 s dosahem 10 m a max. výkonem 1 mW. Rozdělení tříd je v následující tabulce. Tabulka č.2 – Bluetooth – výkonové třídy Výkonová třída

Max. výkon [mW]

Max. dosah [m]

1

100,0 ( 20dBm )

100

2

2,5 ( 4dBm )

50

3

1,0 ( 0dBm )

10

Bezpečnost K zabezpečení komunikace přes Bluetooth se používá několik mechanismů. Na spojové vrstvě jsou používány k dosažení bezpečnosti čtyři kódy. Veřejná adresa o délce 48 bitů (je jedinečné pro každého uživatele), dva tajné klíče o délce 128 bitů a náhodné číslo délky 128 bitů (různé pro každou novou operaci). Před prvním spojením se musí obě zařízení tzv. spárovat. Toto spárování se provádí prostřednictvím zadání identifikačního čísla (PIN) na obou zařízeních. 48 bitová adresa zařízení se také používá k zakódování přenášeného hlasu či dat. K bezpečnosti přispívají i velmi rychlé frekvenční skoky a také malý dosah signálu, které velmi ztěžují případný odposlech.

Praktické využití technologie mobilních zařízení v plynárenství (koncern RWE Group v ČR)

Recommend Documents