Portál pro podporu servisních činností poskytovaných formou outsourcingu

Bankovní institut vysoká škola Praha Katedra Matematiky, statistiky a informačních technologií

Portál pro podporu servisních činností poskytovaných formou outsourcingu Diplomová práce

Autor:

Michal Hrbáč Studijní obor informační technologie a management

Vedoucí práce:

Praha

Ing. Vladimír Beneš

Březen 2011

Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. .

V Praze, 30. 3. 2011

Michal Hrbáč

Poděkování: Chtěl bych tímto poděkovat vedoucímu práce Ing. Vladimíru Benešovi za konzultace, vstřícnost a cenné rady, které vedly k úspěšnému dokončení této diplomové práce.

Anotace:

Hlavním cílem této práce je přestavit konkrétní řešení, které je nasazeno a provozováno v prostředí jedné soukromé firmy a je využíváno pro podporu servisních činností, které tato firma poskytuje svým zákazníkům. V závěru je zhodnocen přínos nasazení této aplikace.

Annotation:

Main goal of this essay is introducing the specific solution, which is deployed and run in an enviroment of one private company and is used to support service/maintenance activities, which this particular company provides to its customers. The contribution of deploying this application is evaluated in the conclusion at the end of this essay..

Obsah Úvod 7 Úvodní slovo ....................................................................................................................................................... 7 Souhrn informací o společnosti ........................................................................................................................... 7 1. Online systém pro celý životní cyklus různorodých servisních aktivit..................................... 9 1.1. Jak se začalo......................................................................................................................................... 9 1.2. Vize .................................................................................................................................................... 10 1.2.1. Pasportizace................................................................................................................................... 10 1.2.2. Smluvní vztah se servisními organizacemi ................................................................................... 11 1.2.3. Převzetí zabezpečovací techniky klienta do vlastní správy ........................................................... 11 1.2.4. Jednotný ceník komponent a prací ................................................................................................ 11 1.2.5. Online systém ................................................................................................................................ 12 1.2.6. Propojení s účetním systémem ...................................................................................................... 12 1.2.7. Přístup partnerských servisních firem ........................................................................................... 12 1.2.8. Zabezpečení aplikace .................................................................................................................... 12 1.3. Outsourcing ........................................................................................................................................ 13 2. Výběr vhodného řešení ................................................................................................................ 14 2.1. Rozhodnutí, jakým směrem se vydat ................................................................................................. 14 2.2. Souhrn poptávkového dokumentu...................................................................................................... 15 3. Vývoj modulu servisních činností a jeho implementace do stávajícího systému ................. 17 3.1. Základní požadavky ........................................................................................................................... 17 3.2. Spolupráce s dalšími firmami............................................................................................................. 19 3.3. Technologické požadavky.................................................................................................................. 19 3.4. Návrh technického řešení ................................................................................................................... 20 3.5. Databázová vrstva .............................................................................................................................. 21 3.5.1. Primární klíče ................................................................................................................................ 22 3.5.2. Práce s UNICODE znakovou sadou .............................................................................................. 22 3.5.3. Vedení historie záznamů ............................................................................................................... 22 3.6. Vrstva aplikačního serveru................................................................................................................. 23 3.7. 4.7 Vrstva webového prohlížeče ........................................................................................................ 23 3.7. 4.7 Vrstva webového prohlížeče ........................................................................................................ 24 3.7.1. Design oken................................................................................................................................... 24 3.7.2. Navigace mezi okny ...................................................................................................................... 25 3.7.3. Kontroly dat ve formulářích .......................................................................................................... 27 3.7.4. Odlišnost pro prohlížeč Mozilla Firefox ....................................................................................... 27 3.8. Zabezpečení přístupu k datům ........................................................................................................... 28 3.9. Uživatelské role ................................................................................................................................. 29 3.10. Přístup k zakázkám ............................................................................................................................ 30 3.11. Servisní modul - servis zařízení ......................................................................................................... 32 3.11.1. Zařízení ......................................................................................................................................... 32 3.11.2. Požadavky na servis ...................................................................................................................... 33 3.11.3. Servisní zásahy .............................................................................................................................. 33 3.11.4. Schvalování servisního zásahu ...................................................................................................... 34 3.11.5. Servisní položka Ceník.................................................................................................................. 34 3.11.6. Komponenty .................................................................................................................................. 35 3.11.7. Inspekce zařízení ........................................................................................................................... 35 3.11.8. Nová instalace zařízení.................................................................................................................. 35 3.11.9. Faktury přijaté ............................................................................................................................... 35 3.11.10. Fakturace zákazníkovi .............................................................................................................. 36 3.11.11. Číselníky................................................................................................................................... 36 3.11.12. Bezpečnostní specialista ........................................................................................................... 36 3.11.13. Verze pro externí uživatele ....................................................................................................... 37 3.11.14. Datový model ........................................................................................................................... 39 3.12. Implementace servisního modulu ...................................................................................................... 40 3.13. Práce se servisním modulem .............................................................................................................. 40 3.13.1. Podmenu – Zařízení ...................................................................................................................... 41 3.13.2. Podmenu – Požadavky na servis ................................................................................................... 49 3.13.3. Podmenu – Servisní zásahy ........................................................................................................... 51

5

3.13.4. Schvalování servisního zásahu ...................................................................................................... 55 3.13.5. Podmenu – Komponenty ............................................................................................................... 56 3.13.6. Podmenu – Servisní položky ......................................................................................................... 57 3.13.7. Podmenu – Bezpečnostní specialisté ............................................................................................. 59 3.13.8. Podmenu – Inspekce zařízení ........................................................................................................ 60 3.13.9. Podmenu – Nová instalace zařízení............................................................................................... 60 3.13.10. Podmenu – Faktury přijaté - podklady ..................................................................................... 62 3.13.11. Podmenu – Faktury přijaté - zpracování ................................................................................... 62 3.13.12. Číselníky................................................................................................................................... 63 4. Testování a vyhodnocení ............................................................................................................. 65 4.1. Testování ............................................................................................................................................ 65 4.2. Vyhodnocení ...................................................................................................................................... 66 4.3. Závěrečné shrnutí ............................................................................................................................... 67 Literatura .............................................................................................................................................. 68 Seznam obrázků .................................................................................................................................. 69

6

Ú Úvvoodd Úvodní slovo Pro svoji práci jsem si vybral téma, které je přímo spojené s projektem, na kterém již řadu let pracuji. Navazuje na moji bakalářskou práci na téma Internetové portálové aplikace a jejich využití v praxi . Ta byla zaměřena na popis portálového internetového systému, který je nasazen v ostrém prostředí soukromé firmy. Tento systém je již řadu let provozován jako podpora provozních složek soukromé bezpečnostní služby (dále jen SBS) a pomáhá provozním manažerům v řízení jejich provozních aktivit pro více než 4000 pracovníků na území celé České republiky. Ve své diplomové práci tedy navazuji na tento projekt a představím řešení, na jehož vývoji, testování a implementaci jsem se aktivně podílel a jehož hlavním tématem je aplikace, která umožňuje řídit celý životní cyklus servisních služeb, které nabízí již zmíněná bezpečnostní služba svým zákazníkům. Jelikož hlavní předmět podnikání této soukromé společnosti jsou bezpečnostní služby, nabízené servisní služby se týkají bezpečnostních systémů.

Souhrn informací o společnosti Jak už jsem se zmínil, poskytuje SBS svým zákazníkům bezpečnostní služby. Služby jsou poskytovány několikerým způsobem: -

prostřednictvím fyzické ostrahy - pomocí strážných, kteří pracují přímo u klienta na stanovištích, které klient určí nebo které mu doporučíme,

-

prostřednictvím mobilní služby – pracovníci se pohybují v dané oblasti buď ve služebních vozidlech coby tzv. revírní hlídky a nebo jsou to pěší patroly (v daných lokalitách je výhodnější nebo nutné zajišťovat

služby prostřednictvím pěších

patrol), -

prostřednictvím zabezpečovacích systémů a monitorovací služby – na dohledovém centru jsou zpracovávány informace z mnoha tisíc připojených objektů klientů SBS,

-

prostřednictvím tzv. integrované bezpečnosti – SBS poskytuje svým klientům komplexní služby, mnohdy plný outsourcing bezpečnostních služeb, kdy na SBS

7

klient přenáší veškeré zajištění všech záležitostí, týkající se bezpečnosti. Tomuto bodu se budu dále více věnovat.

8

11.. O Onnlliinnee ssyyssttéém m pprroo cceellýý žžiivvoottnníí ccyykklluuss rrůůzznnoorrooddýýcchh sseerrvviissnníícchh aakkttiivviitt 1.1.

Jak se začalo Když se v SBS začali zabývat myšlenkou, že budou nabízet svým klientům zajištění

plného outsourcingu bezpečnostních služeb, narazili na řadu otázek, které musely být zodpovězeny. Většina klientů nepožaduje takovouto službu, požadavky klientů jsou většinou spojené s objednávkou služeb fyzické ostrahy, monitoringu, revírních služeb případně kombinací některých z nich. V SBS se ale odhodlali nabídnout svým zákazníkům víc, a to převzetí celé bezpečnostní problematiky a zajištění všech aktivit s tím spojených. Zabezpečit podporu pro výkon fyzické ostrahy či monitoringu pro ně nebyl problém, jelikož je to jejich hlavní obchodní artikl. Co bylo nové, bylo zajištění celého rozsahu servisních aktivit bezpečnostních systémů na všech objektech klienta. Byl stanoven postup, jak se tohoto nelehkého úkolu zhostit. Měl několik fází: - popis, jak by chtěli, aby takový systém fungoval, - sondáž trhu, zda už takový systém, či jeho část, není někde provozován, - poptávka firem zabývajících se vývojem podobných aplikací, - výběr partnera, analýza, smlouva, dodávka systému, - zaškolení, zkušební provoz, ostrý provoz, Pro potřeby tohoto projektu vzniknul tým, kde byly zastoupeny všechny zapojené složky. Já jsem byl do týmu delegován a stanoven odpovědným za technickou realizaci projektu.

9

1.2.

Vize I když v SBS neměli s touto činností zkušenosti, byly sepsány všechny body, jenž

byly považovány za důležité pro zajištění servisních služeb klientů. Vyšlo se z příkladu, či typické situace, kdy nějaký fiktivní klient má např. 10 poboček, v nich je v každé provozován elektronický zabezpečovací systém (EZS), kamerový systém, v polovině z nich pak elektronický protipožární systém (EPS) a v polovině systém kontroly vstupu (SKV), na hlavní pobočce je umístěn speciální trezor a ve všech pobočkách je nainstalován systém pro přenos signálů na pult centralizované ochrany. Klient má pobočky po celé republice a o tyto systémy se mu stará několik servisních firem. Pokud se bude chtít nabídnout klientovi převzetí správy těchto různorodých systémů, musí být SBS schopna zabezpečit toto: -

inventarizace/pasportizace všech servisovaných systémů,

-

sjednání smluvního vztahu se všemi stávajícími servisními partnery klienta,

-

možnost převzít stávající techniku klienta do vlastní správy,

-

zajistit pro klienta jednotný ceník komponent a servisních činností,

-

provozovat online systém, kam bude možné zadávat požadavky klienta a kde bude možné vidět celou historii jednotlivého servisního případu

-

tento systém provázat s účetním systémem tak, aby byl maximálně automatizován přenos účetních záznamů spojených s fakturací servisních úkonů od smluvních servisních firem na straně jedné a data pro přípravu fakturace směrem ke klientovi na straně druhé

-

online systém zpřístupnit všem partnerským servisním firmám

-

zajistit vysokou úroveň zabezpečení tohoto systému

1.2.1. Pasportizace Pro zjištění, jakou všechnu zabezpečovací techniku má klient na svých zakázkách umístěnu a provozovánu musí být zajištěn přístup ke všem revizním zprávám, ve kterých jsou podrobné informace o provozovaných systémech. Na základě těchto údajů budou zpracována data ze servisních zpráv do elektronického systému tak, aby se s nimi dalo v budoucnu pracovat. Přístup k těmto údajům je možné získat až po podpisu smlouvy se zákazníkem. Musí být smluvně stanoven termín, do kdy budou tato data pořízena.

10

1.2.2. Smluvní vztah se servisními organizacemi Jelikož je velmi pravděpodobné, že klient bude mít více smluvních partnerů, kteří se mu starají o zabezpečovací systémy, kamerové systémy, systémy na kontrolu vstupu, trezory, elektronické protipožární systémy, atp., musíme být připraveni oslovit všechny tyto partnery klienta a smluvně zajistit pokračování jejich servisních smluv. Tentokrát ale bude smlouva mezi naší firmou a servisním partnerem klienta. Klient tak získá jediného partnera, se kterým bude komunikovat ohledně bezpečnosti ve svých objektech.

1.2.3. Převzetí zabezpečovací techniky klienta do vlastní správy Po úspěšné pasportizaci a inventuře všech položek zabezpečovacích systémů bude získán úplný přehled o provozované technice, jejím stáří a zárukách, revizích, firmách, které revize a servis zajišťují. Následně může být od klienta formálně převzata všechna technika do vlastní správy SBS. Prakticky to znamená, že po převzetí

se SBS stane pro klienta jediným

partnerem, který mu bude moct zajist celou agendu spojenou s provozem a údržbou zabezpečovacích systémů. Při nových investičních akcích (mám na mysli např. rekonstrukci některého ze zabezpečovacích systémů u klienta nebo pořízení nového) pak SBS provede návrh a následně také realizaci celého projektu. Jelikož se musí počítat s tím, že klient bude působit v rámci celé republiky, SBS musí být schopna nabídnout klientovi své specialisty v každé oblasti resp. v každém regionu.

1.2.4. Jednotný ceník komponent a prací Pro zjednodušení všech operací bude především pro klienta výhodné, pokud se na dané období stanoví jednotný ceník komponent zabezpečovacích systémů. Znamená to, že ceny komponent a práce spojené se servisní činností budou dány smluvně a nebude možné je v daném období měnit. Klient tak může velmi přesně odhadnout, kolik jej bude provoz zabezpečovacích systémů v daném období stát.

11

1.2.5. Online systém Pro správný provoz celého projektu bude muset být vyvinut nějaký software,

který

umožní

evidovat

všechny

pasportizované

položky

zabezpečovacích systémů, sledovat jejich stáří, záruční doby, termíny revizí, sledovat celý cyklus servisních případů, Další podmínkou je zpřístupnění dat uživatelům dle parametrizace tak, aby se dalo zajistit, že každý uživatel bude mít přístup pouze k jeho datům. Výstupy budou specifické dle potřeb konkrétního klienta, resp. potřeb servisních partnerských organizací.

1.2.6. Propojení s účetním systémem Propojení této aplikaci se stávajícím účetním systémem je základní podmínkou správného provozu. V účetním systému jsou veškeré informace týkající se klientů, jejich zakázek, ale také dodavatelů, tedy i partnerských servisních firem. Software pro podporu servisních činností musí být propojen se stávajícím účetním systémem tak, aby se data přebírala, resp. předávala definovaným způsobem mezi těmito dvěma systémy.

1.2.7. Přístup partnerských servisních firem Protože je nezbytné, aby partnerské firmy tento systém také mohly vyžívat, musí být zajištěno, aby měly k aplikaci přístup. Znamená to vytvořit rozhraní, pomocí nějž se k aplikaci mohou připojit a pracovat s ní.

1.2.8. Zabezpečení aplikace Vzhledem k povaze dat je velmi důležitá vysoká úroveň zabezpečení aplikace. Systém bude provozován výhradně v intranetovém prostředí, v rámci VPN1.

1

Virtual private network – systém pro bezpečné propojení více počítačů prostřednictvím veřejného internetu 12

1.3.

Outsourcing Outsourcing je dlouhodobý smluvní vztah s někým vně vlastní organizace na

poskytování služeb v jedné nebo více oblastech. Tolik říká jedna z definicí. Pro jednoduchost lze říci, že tímto pojmem můžeme označovat vždy pouze takové případy, kdy k poskytování všech souvisejících služeb dochází současně a poskytovatel těchto služeb se specializuje na jejich ucelené bloky2. V minulosti vedla tato specializace např. ke vzniku logistických firem3, nebo později ke vzniku tzv. systémových integrátorů4. Outsourcing lze považovat za obchodní rozhodnutí, jehož cílem je snížení nákladů nebo

soustředění

se

na

hlavní

podnikatelské

aktivity

firmy,

v zájmu

5

konkurenceschopnosti . Důvody pro rozhodnutí zavést outsourcing můžeme rozdělit do čtyř kategorií: 6 a)

konkurenční – cílem je získat konkurenční výhodu, čili jedná se o strategické rozhodnutí,

b)

věcné – cílem je zdokonalení v oblasti hlavní činnosti,

c)

finanční – snížení nákladů nebo zvýšení výnosů. Finanční hledisko je důležitým faktorem pro hodnocení outsourcingového projektu zavedeného z jiného důvodu než finančního,

d)

organizační – zploštění organizační struktury a zjednodušení manažerské práce.

2

RYDVALOVÁ P., RYDVAL J,.Outsourcing ve firmě, 2007 Logistická firma je definována jako integrátor, který propojuje činnosti mnoha specialistů. Pro logistiku v rozsáhlých dodavatelských řetězcích se uvádí označení 3PL nebo 4PL 3PL – 3rd party logistics – výrobce + obchodník + logistický podnik 4PL – 4th party logistics - výrobce + obchodník + logistický podnik + informační technologie. V tomto modelu se využívají dokonalé informační technologie a řetězec disponuje experty na strategické řízení. Spolupráce v rámci 3PL a 4 PL je založena na Dlouhodobých smluvních vztazích. 4 Systémový integrátor je na základě smlouvy pověřen komplexním řešením informačního sytému klienta. Jednotlivé odborné úkony může zajistit dalšími dodavateli, nicméně garantem, který odpovídá za kvalitu služeb svého subdodavatele je stále odpovědný smluvně ustanovený systémový integrátor. 5 Více viz http://cs.wikipedia.org/wiki/Outsourcing 6 Voříšek, J., Strategické řízení informačního systému a systémová integrace, Management Press, Praha, 1997 3

13

22.. V Výýbběěrr vvhhooddnnééhhoo řřeeššeenníí 2.1.

Rozhodnutí, jakým směrem se vydat Při rozhodování, jakým způsobem zajistit, aby výše uvedené podmínky byly splněny,

bylo nutné zodpovědět stěžejní otázku, zda SBS chce nový systém a nebo chce rozšířit stávající portálový systém. Každá z těchto dvou variant měla svoje zastánce i odpůrce. Jejich názory byly pro rozhodnutí důležité a pokusím se je stručně shrnout: a) pro stávající portálový systém -

zavedená aplikace, která je osvědčená a vyzkoušená,

-

všechny potřebné datové vazby na stávající ekonomické systémy jsou hotové a funkční, projekt tedy bude rychlejší a levnější,

-

dodavatel, který nám aplikaci dodává pracuje i na dalších aplikacích především pro ekonomický úsek a má tedy velkou znalost vnitropodnikového řešení SBS, její organizační struktury, atd. Bude tedy pro dodavatele mnohem snazší reagovat na potřeby SBS,

-

dodavatel pracuje pro SBS řadu let, je tedy ze strany SBS ověřený,

b) pro nový systém -

oddělit stávající systém od nového, protože bude řešit úplně jinou problematiku,

-

získat jiného dodavatele aplikace, protože stávající nemá dostatečné kapacity, aby včas a v termínu aplikaci dokončil a předal,

Po dlouhých jednáních bylo dosaženo názoru, že pro potřeby SBS bude dostatečné, pokud bude osloven stávající dodavatel portálového systému a bude u něj poptáno rozšíření již zavedeného portálového systému. Vzniknul tým, který měl za úkol realizovat tento projekt. Jako první úkol týmu bylo připravit poptávkový dokument. Jeho obsahem mělo být podrobné zadání a popis celého systému. Na základě tohoto zadání měl dodavatel poskytnout svůj vlastní návrh softwarového řešení, které celou problematiku zaštítí.

14

2.2.

Souhrn poptávkového dokumentu V této kapitole budou uvedeny jednotlivé body, které byly obsahem poptávkového

dokumentu: -

aplikace bude provozována ve stejném prostředí jako je stávající portálový systém (dále PS),

-

k aplikaci budou mít přístup i dodavatelské servisní organizace a také klienti, resp. určení zaměstnanci klienta,

-

pro přístup externích subjektů musí být nastaven systém zabezpečeného přístupu prostřednictvím VPN,

-

každý klient či dodavatelská servisní organizace bude mít přístup pouze ke ,,svým“ datům, tzn. že klientovi budou zobrazena pouze data týkající se klienta, dodavatelské servisní organizaci pak data, týkající se zakázek, na kterých poskytují našim klientům servisní činnosti,

-

aplikace bude schopna řídit celý tok servisního případu od zadání, přes realizaci, kontrolu, až po uzavření a fakturaci,

-

v aplikaci budou evidovány všechny servisované položky s vazbou na konkrétní zakázku klienta, bude zde evidován až úplný detail každého zařízení7,

-

součástí evidence bude také systém kontroly a reportingu pravidelných revizí, záručních dob, apod.,

-

u každé položky (bude-li to možné) bude evidována její pořizovací cena, datum instalace, datum plánované revize, datum ukončení záruční doby,

-

součástí aplikace bude jednotný ceník servisních zařízení, komponent a prací, který bude individuální pro každého klienta,

-

tento ceník bude závazný pro všechny smluvní servisní dodavatelské organizace, tzn. že servisní organizace nebude moci použít jinou položku než tu, která je uvedena v tomto ceníku. Ceník bude obnovován nejméně jednou ročně, a to na základě oboustranné dohody s klientem,

-

zakázky klienta budou rozděleny mezi bezpečnostní specialisty (dále jen BS), kteří budou mít v daném regionu na starosti zakázky klienta. BS bude zodpovědný za komunikaci s klientem v dané oblasti a za komunikaci

7

Např. bude zde evidováno zařízení pro Systém kontroly vstupu a také všechny jeho součásti, jako čtečky, terminály, tiskárny, monitory, centrální jednotky, UPS, atd. 15

s konkrétní servisní dodavatelskou organizací. BS je osoba, která bude rozhodovat o správnosti realizovaného servisního zásahu, a bude hlavním partnerem pro klienta, resp. zaměstnance klienta v daném regionu. Po přihlášení do aplikace se BS zobrazí pouze ty zakázky, které jsou v jeho působnosti, -

aplikace musí zajistit dočasné přidělení zakázek jednoho BS jinému BS po dobu nepřítomnosti prvního z nich(dovolená, nemoc, atd.),

-

aplikace bude využívat stávající propojení s ekonomickým systémem Hélios Oranže, bude z něj přebírat informace o zakázkách, zákaznících a dodavatelích. Toto je již v PS implementováno, takže se pouze použije stávající funkcionalita,

-

aplikace umožní automaticky zpracovat podklady pro vygenerování dodavatelské faktury a při likvidaci této faktury v ekonomickém systému připraví elektronický podklad pro rozúčtování jednotlivých položek na dané zakázky/nákladová střediska,

-

aplikace umožní vygenerovat podklady pro fakturu vydanou směrem ke klientovi, a to na základě všech odsouhlasených a fakturovaných servisních činností, které byly klientovi v daném období poskytnuty,

-

aplikace bude obsahovat celou řadu kontrolních sestav, které budou nastaveny dle potřeb konkrétního zákazníka,

-

aplikace bude umožňovat export dat do formátu xls8 a uložení sestav do formátu pdf9,

-

aplikace umožní zadat konverzní cenovou tabulku u každé položky (včetně kumulace fakturačních položek) či služby tak, aby bylo možné provést automatickou předfakturaci všech položek směrem od dodavatelské servisní firmy směrem ke klientovi.

Na základě těchto parametrů připravil dodavatel nabídku, po jejíž odsouhlasení vedením SBS začal dodavatel s vývojem a implementací tohoto modulu.

8 9

XLS – přípona souborů vytvořených v aplikaci Microsoft Excel PDF – Portable Document Format – souborový formát vyvinutý firmou Adobe tak, aby byly čitelné kdekoliv bez ohledu na hardware a software, ve kterém byly pořízeny 16

33.. V m sseerrvviissnníícchh ččiinnnnoossttíí Výývvoojj moodduulluu aa jjeehhoo iim mpplleem meennttaaccee ddoo ssttáávvaajjííccííhhoo ssyyssttéém muu Jak už bylo zmíněno, bude tento modul implementován do stávajícího portálového systému. Ve stručnosti připomenu, jak tento portálový systém vypadá a jak pracuje. Celý portálový systém je popisován v mé bakalářské práci z roku 2009 s názvem Internetové portálové aplikace a jejich využití v praxi.10

3.1. Základní požadavky Soukromá bezpečnostní služba poskytuje svým zákazníkům bezpečnostní služby. Interně je SBS rozdělena do pěti divizí, z nichž čtyři poskytují přímé bezpečnostní služby zákazníkům (Guarding, Bank Security, Mobile Patrols, Monitoring & Alarms), nově pátá pak poskytuje zákazníkům servisní činnosti. Obrázek 1 - schéma jednotlivých divizí GUARDING Fyzická ostraha objektů

BANK SECURITY Specializovaná ostraha bank

+

Servisní činnosti

MOBILE PATROLS Revíry a výjezdy autohlídky

MONITORING & ALARMS Pulty centrální ochrany , zabezpečení objektů

Zdroj: Vlastní úprava

Provozní Systém (dále jen PS) má za úkol podpořit manažery jednotlivých zakázek při přípravě podkladů pro fakturaci zákazníkům a při přípravě podkladů pro výplatu mezd zaměstnancům. Dále PS centralizuje evidenci informací o jednotlivých zakázkách, nahrazuje řadu rutinních ručně prováděných činností a poskytuje informace pro další činnosti, jako je například kontrola oprávněnosti fakturovaných částek dodavateli služeb 10

Hrbáč M., Internetové portálové aplikace a jejich využití v praxi, bakalářská práce BIVŠ, 2009 17

na jednotlivých zakázkách atd. V neposlední řadě PS zmenšuje potřebu ručního přepisu informací a zjednodušuje předávání informací mezi pracovníky SBS. PS je schopen pokrýt požadavky jednotlivých divizí, které jsou s ohledem na způsob jejich práce v určitých ohledech různorodé, neboť divize Guarding a Bank Security fungují v odlišném režimu než zbývající divize. PS je schopen spolupracovat s dalšími IT systémy v rámci SBS, zejména pak s ERP systémem Helios Orange, ve kterém je vedeno účetnictví společnosti. Dalším klíčovým systémem, se kterým je PS schopen spolupracovat, je IIS Ekonom, ve kterém je zpracovávána oblast personální a mzdové agendy společnosti. Pro komunikaci s manažery jednotlivých zakázek komunikuje PS v určitých případech prostřednictvím elektronické pošty a nebo prostřednictvím GSM brány zasílá vybraným osobám SMS zprávy. Dalším systémem, který čerpá z PS informace, je reportingový systém DWH11.

Obrázek 2-schéma systému PS Další systémy

Portál provozního systému

Komunikace

Helios

Webový server

eMailový server

IIS Ekonom

Databázový server

GSM brána


11

Název DWH byl zaveden při implementaci BI (business intelligence) řešení a je využíván pro reporting, tvorbu rozpočtů a generování různých sestav pro potřeby všech úrovní řízení společnosti 18

3.2. Spolupráce s dalšími firmami Jak jsem již uvedl, SBS poskytuje své služby zákazníkům prostřednictvím zakázek. S každým zákazníkem může být současně aktivní libovolný počet zakázek, nicméně každá zakázka je vždy spojena jen s jedním zákazníkem. Obrázek 3- schéma spolupráce s dalšími firmami


Pokud je zapotřebí poskytovat zákazníkovi služby z více divizí (např. přes den požaduje zákazník na své pobočce službu strážného a přes noc je napojen na PCO), jsou pro jednotlivé služby vytvořeny samostatné zakázky pro příslušné divize. Každá zakázka je tedy přiřazena jedné z divizí a ve většině případů jsou všechny služby spojené s realizací dané zakázky prováděny příslušnou divizí. V určitých případech však může dojít k situaci, kdy jsou služby provedeny i jinou divizí - v tom případě je možné volitelně dodatečně realizované služby přesunout na zakázku dotyčné divize. Typicky se jedná o situaci, kdy je zákazník připojen na PCO - máme tedy zakázku divize Monitoring & Alarms - a po nahlášení narušení objektu provede výjezd divize Mobile Patrols.

3.3. Technologické požadavky Základní požadavkem na PS je realizace ve formě tzv. tenkého klienta, kdy uživatelé pracují s daty pouze prostřednictvím webového prohlížeče, neboť pracují i na počítačích zákazníků, kam není možné instalovat klientskou část aplikace. Jako webové prohlížeče

19

jsou pro realizaci tohoto projektu stanoveny prohlížeče MS Internet Explorer verze 6.x a vyšší nebo Mozilla FireFox verze 2.x a vyšší Rozlišení monitorů pracovních stanic je dohodnuté minimálně na 1024x768 pixelů, proto je design aplikace navrhován tak, aby uživatelé s tímto rozlišením mohli s PS pracovat. Aplikační řešení samozřejmě podporuje rolování v oknech. Někteří uživatelé jsou připojeni prostřednictvím málo průchodných technologií (GPRS/EDGE/4G/3G, nízkokapacitní připojení do internetu), proto musí být PS realizován tak, aby s ním i tito uživatelé mohli pracovat v přiměřených dobách odezvy.

3.4. Návrh technického řešení Aplikace je vyvíjena ve třívrstvé architektuře.

Obrázek 4 - schéma třívrstvé architektury

Základní vrstvu představuje databázový server, kde jsou data ukládána do relační databáze MS SQL Server 2008 R2. Přístup k jednotlivým tabulkám pro změnu dat není povolen, veškeré změny jsou prováděny prostřednictvím uložených procedur. Druhou vrstvu představuje aplikační server, v tomto projektu je to MS Internet Information Server. V rámci aplikačního serveru jsou spouštěny komponenty vyvinuté v prostředí .NET (pokud není řečeno v dokumentu jinak, pak vždy pro .NET Framework 3.0). Třetí vrstvu představuje webový prohlížeč, v rámci kterého je provozována klientská část aplikace. S ohledem na některé specifické požadavky na aplikační řešení může být nutné upravit nastavení prohlížeče – toto nastavení může záviset na požadované

funkcionalitě

a

je

uvedeno

v


administrátorské příručce příslušné části aplikace (např. musí být vždy povoleno použití skriptování na straně klienta). Jednotlivé vrstvy můžeme ještě dále rozdělit do menších komponent a skupin. Např. v databázové vrstvě jsou použity tabulky pro uložení dat, uložené procedury pro

20

modifikaci a získávání dat, pohledy (view) pro upravený pohled na data, databázové funkce, triggery apod. V rámci aplikačního serveru je vytvořena řada komponent, např. pro zjednodušení práce s databází, práci s logy apod. Na klientské straně jsou jako dílčí části použity CSS styly, JavaScriptové funkce a samozřejmě vlastní HTML kód (generovaný .NET Frameworkem a MS IIS).

3.5. Databázová vrstva Databázová vrstva slouží k ukládání dat a zabezpečuje jejich zpřístupnění uživatelům pomocí definovaného rozhraní. Změny dat nejsou prováděny z vyšší vrstvy (tedy z aplikačního serveru) přímo SQL příkazy typu INSERT, UPDATE, DELETE, ale jsou prováděny prostřednictvím uložených procedur. Nad každou tabulkou nebo sadou tabulek je vytvořena skupina uložených procedur, která tyto operace zajistí. Výhodou tohoto principu je zabezpečení řízeného přístupu k datům – procedura nejprve zkontroluje, zda uživatel má právo provádět příslušnou operaci (např. zda má právo založit nový záznam na základě členství v uživatelské roli v rámci aplikace), poté provede další potřebné kontroly (např. vyplnění logicky povinných položek, existence očekávaných dat v dalších tabulkách), provede změny nejen v dotyčné tabulce ale i v dalších souvisejících tabulkách (např. vytvoří záznam v historii). Další výhodou je, že uživatel nemusí mít fyzická práva k práci s tabulkou na úrovni databáze (např. členství ve skupině data_reader nebo data_writer), ale stačí mu práva spouštět příslušnou uloženou proceduru. Nevýhodou tohoto principu je vyšší pracnost tvorby aplikace a nemožnost číst data mimo rozhraní vytvořenými procedurami. Z toho důvodu může být vhodné některé uživatele zařadit do skupiny data_reader, díky čemuž je mít právo číst libovolná data, ale změny je opět muset provádět prostřednictvím uložených procedur. Uživatelé s PS pracují pod svým MS Windows účtem (princip Single Sign On) stejně tak pracují i s databází pod svým skutečným uživatelským účtem (Integrated security). Díky tomu lze až v uložených procedurách identifikovat uživatele podle jeho uživatelského jména a tento údaj se nemusí předávat mezi jednotlivými vrstvami a zamezí se podvržení identity uživatele.

21

3.5.1. Primární klíče Primární klíč je určen pro identifikaci každého záznamu v tabulce MS SQL. Primární klíče jsou generovány automaticky a pro nastavování hodnot umělých primárních klíčů v tabulkách je využita možnost automatického generování v rámci MS SQL využitím IDENTITY. Datový typ každého primárního klíče je BIGINT a to i pro tabulky, kde je předpokládán malý počet záznamů (číselníky). Při ukládání dat do tabulek je ponecháno automatické generování hodnot vždy, pokud je to možné – ruční vkládání ovlivněné nastavením SET IDENTITY_INSERT je využíváno výjimečně. Pokud je pro některé záznamy primární klíč typu řetězec (VARCHAR), není v takovém případě automatické generování použito.

3.5.2. Práce s UNICODE znakovou sadou S ohledem na současný stav, kdy není nutné ukládat znaky z UNICODE znakové sady, jsou všechny části PS řešeny tak, že UNICODE znaky nejsou zpracovávány a je zpracovávána pouze znaková sada Windows 1250.

3.5.3. Vedení historie záznamů Pro řadu informací požadujeme vedení jejich historie, tedy sledování změn v průběhu času pro jednotlivé záznamy. Tato evidence je realizována formou tzv. historických tabulek, kdy ke každé tabulce obsahující data (která chceme takto sledovat) je vytvořena další tabulka (její název je se sufixem _HIST). Historická tabulka obsahuje všechny sloupce z původní tabulky, doplněné dalšími informacemi – např. autor, datum a čas zápisu záznamu není v původní tabulce, ale pouze v historické. Historické tabulky standardně neobsahují žádné cizí klíče ani indexy z důvodu rychlejšího zápisu – cizí klíče jsou definovány pro zabezpečení integrity databáze. Pokud budou data z HIST tabulek zobrazována, budou vytvořeny pouze takové indexy, které zajistí rychlé zobrazení dat (např. podle primárního klíče původní tabulky). Historická tabulka obsahuje unikátní sloupec s hodnotami generovanými pomocí Identity – tento sloupec může nebo nemusí být nastaven jako primární klíč. V HIST tabulkách je např. opakovaně

22

zapisována informace o jedné zakázce vždy, když jsou informace v hlavním záznamu editovány. Zápisy do historických tabulek můžeme v principu provádět dvěma způsoby: - prostřednictvím triggerů - z uložených procedur Pro potřeby PS využíváme druhý způsob, tedy vytváření historie prostřednictvím uložených procedur.

3.6. Vrstva aplikačního serveru Ve vrstvě aplikačního serveru je vytvořeno několik komponent, jako např. komponenty pro práci s databází, GSM bránou, odesílání pošty apod. Na obrázku je zobrazena ukázka rozhraní jedné z komponent, konkrétně komponenty pro práci s databází MS SQL.

3.7. Obrázek 5- rozhraní komponenty pro práci s db MS SQL


23

4.7 Vrstva webového prohlížeče 3.7.1. Design oken Jako základní barva pozadí jednotlivých oken je použita systémová barva tlačítek dle nastavení MS Windows - BUTTONFACE (#ECE9D8). Všechny ostatní prvky mimo DataGridu mají zachovánu standardní barvu popředí, pozadí i textu. Tlačítka v oknech jsou situována doprava nahoru, zarovnaná buď svisle nebo vodorovně. Každé okno musí mít nadpis, který určuje, jaká část aplikace je spuštěna. Popisky (Labels) jednotlivých polí jsou zarovnány pod sebe na levý okraj. Pole, která nejsou editovatelná mají nastavený atribut ReadOnly na hodnotu True. Aby bylo možné kopírovat texty z jednotlivých polí pro využití ClipBoard, je ponechána hodnota Enabled = True. Pokud je to možné, je vhodné signalizovat povinná pole změnou atributů popisky – tučným fontem a fontem odlišné barvy (modrá barva Navy). Okno aplikace je otevíráno do okna, ve kterém nejsou běžné prvky prohlížeče – menu, toolbar, adress bar apod. Aplikace se tedy tváří jako opravdová aplikace.

24

Zdroj: printscreen z aplikace

Obrázek 6 - rozdíl designu aplikací12

3.7.2. Navigace mezi okny Uživatel může prostřednictvím aplikačního menu v horní části okna prohlížeče zobrazit v drtivé většině případů seznam záznamů. V seznamu je možné změnit řazení záznamů klepnutím na záhlaví seznamu. Nad seznamem jsou pole pro definici filtrů, pomocí kterých můžeme vyhledat jen určitou sadu záznamů (odfiltrovat nežádoucí záznamy). Hledání je možné buď přes přesné zadání hodnoty určitého sloupce v seznamu, nebo pomocí části textu, jak je znázorněno na ilustrativním obrázku.


Obrázek 7 - použití tlačítka Filtr

12

Na obrázcích je znázorněn rozdíl designu aplikací v klasickém okně prohlížeče – levý obrázek a v okně bez navigačních prvků – pravý obrázek. Mimo jiné získáme také větší prostor pro vlastní aplikaci. Samozřejmě musíme mít na paměti, že zkušenější uživatelé snadno otevřou aplikaci i do obvyklého designu – tomuto však nelze zamezit a proto se tímto problémem nezabýváme. 25

Řazení i vyhledávání (filtrace) záznamů je možné přes všechny sloupce ze seznamu. Opakovaným klepnutím na záhlaví sloupce dojde ke změně pořadí řazení (vzestupně, sestupně). Pokud je v seznamu více záznamů, je zobrazen vždy pouze omezený počet záznamů a další sada je zobrazena na vyžádání uživatelem (tzv. stránkování záznamů). Stránkování může být v některých formulářích záměrně potlačeno, v tom případě, pokud seznam obsahuje více záznamů, než je možné zobrazit na monitoru je nutné v okně rolovat. Ze seznamu je možné přejít na detail záznamu. Detail nerozlišuje režim zobrazení a editace – pokud má uživatel práva editovat záznam, je rovnou v režimu editace. Samozřejmě pokud má pouze právo záznam zobrazit (např. protože je záznam aktualizován v Heliosu a do PS je pouze přebírán), nemůže záznam editovat a všechna pole jsou pouze pro čtení. Případné mazání (rušení) záznamů je realizováno opět z detailu záznamu a není možné provést jej ze seznamu. Vyvolání formuláře pro založení nového záznamu je možné buď ze seznamu, nebo z detailu záznamu. Přechod mezi formuláři seznamu, nového záznamu a detailu je schématicky znázorněn na obrázku. Zdroj: printscreen z aplikace

NOVÝ

SEZNAM

DETAIL RUŠENÍ

Obrázek 8 - schéma přechodu mezi formuláři Mezi určitými formuláři je možné přecházet přímo do detailu určitého záznamu – např. do detailu zakázky jsou přímé odskoky z přípravy podkladů pro fakturaci i mzdy.

26

3.7.3. Kontroly dat ve formulářích Ve formulářích je prováděno několik typů kontrol ještě před odesláním na server, aby se zmenšila zátěž serveru a také snížila komunikaci po síti. Typické kontroly jsou: - kontrola zadání povinných hodnot - zadaná data jsou správného datového typu - zadaná data jsou v povolených rozsazích

Obrázek 9 - kontrola dat ve formuláři


Všechny kontroly jsou realizovány prostředky .NET frameworku. Na každé

stránce,

kde

jsou

realizovány

kontroly,

je

umístěn

objekt

ValidationSummary. Umístěn je vždy poblíž tlačítek pro odeslání dat. Jako barva textu (ForeColor) je nastavena červená (Red), volba ShowMessageBox je nastavena na True. DisplayMode zůstává BulletList. Jednotlivé kontroly jsou poté vytvořeny tak, aby byly zobrazovány do společného místa (Display = None).

3.7.4. Odlišnost pro prohlížeč Mozilla Firefox Vzhledem k vlastnosti prohlížeče Mozilla Firefox musí uživatelé pracující s tímto prohlížečem zadat při spuštění aplikace své uživatelské jméno a heslo. Firefox tyto informace neumí převzít z MS Windows, ale požaduje jejich zadání. Poté je předá aplikačnímu serveru IIS a uživatel dále pracuje bez nutnosti znovu tyto údaje zadávat. Mozilla Firefox neumožňuje vyvolání modálního dialogu pomocí funkce ShowModalDialog. Proto jsou editační okna otevřena do okna, které vypadá jako modální dialogové okno, nicméně pokročilý uživatel se dokáže přepnout do základního okna aplikace.

27

3.8. Zabezpečení přístupu k datům Uživatelé PS pracují s aplikací prostřednictvím internetového prohlížeče. V rámci PS není samostatná evidence a správa hesel uživatelů, ale přihlašovací údaje jsou přebírány z LDAP databáze Active direktory (Centrální správa uživatelů). Pokud v rámci práce na PC již jsou přihlášeni do domény BA, je jejich uživatelské jméno z MS Windows použito jako přihlašovací jméno do PS a uživatelé tedy již nemusí zadávat své přihlašovací údaje. Pokud nejsou přihlášeni do domény (např. pracují na počítači u zákazníka), vynutí si zadání přihlašovacích údajů již webový server (při spuštění PS v prohlížeči) a provede ověření zadaných údajů proti informacím, které si PS převzal z databáze LDAP. S PS tedy vždy pracují již ověření uživatelé. Díky tomu není nutné řešit v rámci PS ukládání a ochranu hesel uživatelů, čímž se zvýší zabezpečení celého systému. Pro definici seznamu uživatelů, kteří mají mít přístup k PS, je v rámci LDAP vytvořena speciální skupina uživatelů. Pouze pro tuto skupinu uživatelů je v rámci nastavení virtuálního adresáře na IIS povolen přístup k PS a seznam uživatelů z této skupiny je přebírán do databáze uživatelů PS. V rámci PS je možné provést zablokování uživatelského účtu, které způsobí okamžité znemožnění práce daného uživatele (další databázový příkaz již nebude proveden). Obrázek 10 - - přihlašovací dialog PS


28

3.9. Uživatelské role Uživatelské role zprostředkovávají uživatelům přístup k jednotlivým funkcionalitám PS. K jaké funkcionalitě PS má mít uživatel přístup, závisí na jemu přidělených uživatelských rolích. Uživatel může mít přiděleno více rolí najednou, v průběhu času se může přidělení rolí měnit a samozřejmě mu také nemusí být přidělena žádné role – v takovém případě nemůže s PS pracovat, stejně jako kdyby nebyl vůbec uživatelem aplikace. Zařazování uživatelů do jednotlivých rolí je prováděno v rámci PS a není přebíráno z centrální databáze LDAP. Zařazování je možné provádět buď z formuláře detailu uživatele (jako je znázorněno na obrázku), nebo obdobným způsobem je možné v detailu role přidávat a odebírat jednotlivé uživatele do dané role. Seznam rolí je pevně spojen s funkcionalitou PS a není možné jej měnit uživatelsky, je definován dodavatelem PS. Stejně tak není možné uživatelsky měnit, které činnosti smí provádět ta která role, i toto je zabudováno v aplikaci a případná změna vyžaduje zásah do zdrojového kódu aplikace či do nastavení, které není přístupné uživatelům.

Obrázek 11 - detail definice rolí Zdroj: printscreen z aplikace

29

3.10.

Přístup k zakázkám

Každý uživatel má nadefinovaný seznam zakázek, se kterými může pracovat. Přiřazené role jsou platné pro všechny zakázky, není možné provést individuální změnu pro jednu zakázku (tedy pokud je uživatel Personalistou a Velitelem objektu, pak má obě tyto role na všechny přiřazené zakázky a není možné, aby na některých zakázkách vystupoval v roli Personalista a na některých v roli Velitel objektu). Definice seznamu přiřazených zakázek se provádí opět ve formuláři detailu uživatele, případně v detailu zakázky je možné určit, kteří uživatelé mají mít k dané zakázce přístup. Vzhledem k hierarchii zakázek má uživatel přístup i do zakázek podřízených přímo přiřazené zakázce – manažer zakázky tedy přiřazením své zakázky získá přístup i do ostatních podřízených zakázek automaticky. Pokud tedy v zobrazeném příkladu zadáme přístup uživateli do zakázky 90162, získá automaticky přístup i do dalších sedmi zakázek.

90162

12345

92716

128376

182892

182738

115262

15426

17283

15247

17263

14435

Obrázek 12 - schéma hierarchie zakázek Zdroj: printscreen z aplikace

Na dalším obrázku je pak znázorněno, jak je možné přiřadit uživateli přístup k jednotlivým zakázkám. Existuje zde i možnost zadat přístup ke všem zakázkám.

Obrázek 13 - definice přístupu pomocí zakázek Zdroj: printscreen z aplikace 30

Nově je v PS zavedena možnost nastavit uživateli přístup k datům ne pomocí zakázek ale prostřednictvím Nákladového střediska. Každá zakázka má u sebe nadefinováno své nákladové středisko. Je tedy možné nastavit přístup i pomocí tohoto atributu.

Obrázek 14 - definice přístupu pomocí nákladového střediska Zdroj: printscreen z aplikace

Ostatní informace spojené s aplikací PS je možné získat v mé již zmíněné bakalářské práci, která se popisu této aplikace podrobně věnuje. V dalším textu se budu zabývat pouze nově přidanou funkcionalitou servisního modulu.

31

3.11.

Servisní modul - servis zařízení

Servis zařízení v rámci PS umožňuje evidovat veškeré klíčové informace, které vznikají v rámci správy majetku a zařízení zákazníka. Slouží jak pro interní potřebu společnosti Securitas, tak i pro zpřehlednění výkazů směrem k zákazníkovi a externím servisním firmám. V rámci servisu zařízení je nutné zaevidovat jednotlivá zařízení (např. EZS nebo trezory), která jsou předmětem servisní činnosti společnosti vůči zákazníkovi. Pro každé zařízení je možné evidovat komponenty nebo položky, ze kterých se skládá. Je možné evidovat také veškerou dokumentaci, která je k danému zařízení, komponentě či položce potřebná13 . Pro každé zařízení je možné evidovat požadavky na servisní zásahy, ať už se jedná o opakované zásahy (např. pravidelné roční či půlroční revize), nebo nečekané závady a další požadavky. Na základě těchto požadavků jsou evidovány servisní zásahy. V rámci servisního zásahu vznikají podklady pro fakturaci nejen zákazníkovi, ale také podklady pro fakturaci ze strany servisních firem - tyto by neměly fakturovat nic, co nebude evidováno v PS. Dále jsou realizovány podpůrné činnosti typu evidence Inspekcí na zařízeních a tvorba nových rozpočtů. Protože v okamžiku tvorby tohoto dokumentu některé činnosti byly pozdrženy, budou definitivně dokončeny a popsány až v pozdějších fázích realizace.

3.11.1.

Zařízení

Zařízení je základní komponentou pro celý modul Servisu zařízení a majetku. Zařízení představuje jeden logický celek, který je instalovaný u zákazníka a pro který evidujeme další informace14. K zařízení jsou evidovány Požadavky na servisní zásah a následně také Servisní zásahy. Zařízení se může skládat z Položek nebo Komponent. Každá komponenta, kterou chceme v systému evidovat, musí být nejprve založena v seznamu komponent.

13

příručky, popisy instalací, revizní zprávy apod. je možné evidovat v PS, jsme limitování pouze velikostí jednotlivých souborů, která je nastavena na 128 MB 14 zařízením je např. EZS, trezor apod. 32

Pro zařízení může být zapotřebí zadat pravidelně se opakující revize nebo kontroly. V tom případě nemusíme zadávat opakovaně jednotlivé požadavky, ale můžeme je zadat pomocí pravidelně opakovaného. Dále můžeme vytvořit nový požadavek na servisní zásah ad hoc – např. porucha nebo nějaký jiný problém, který hlásí zástupce zákazníka. Jednotliví BS mohou vykonávat na zařízeních inspekci. V tom případě je možné zaevidovat si základní informace o provedené inspekci – kdo a kdy ji provedl a s jakým výsledkem. K zařízení si můžeme do systému uložit libovolný počet v podstatě libovolných souborů (jsme limitováni pouze velikostí souborů, která je nastavená společně pro celé PS). Sem můžeme ukládat různou dokumentaci popisující instalaci, protokoly, zprávy, příručky apod. K zařízení si můžeme připojit i libovolný počet textových poznámek.

3.11.2.

Požadavky na servis

Požadavky na servisní zásah vznikají buď jako pravidelně se opakující, například roční revize zařízení. Druhým způsobem jsou nečekané požadavky, kdy zákazník hlásí nějakou chybu nebo problém na zařízení. Požadavek musí být v systému evidován nejpozději v okamžiku, kdy chceme evidovat servisní zásah.

3.11.3.

Servisní zásahy

Servisní zásah představuje činnost dodavatelské servisní firmy, který u zákazníka provádí činnost. Servisní zásah musí být vždy založen na Požadavku na servis. Není možné vytvořit zásah, pro který by požadavek neexistoval. Servisní zásahy vždy vytváří externí servisní firma15. Pro externí firmy je k dispozici verze systému s omezenými přístupovými právy. Externí společnost mimo jiné nemůže schválit servisní zásah - to může provést pouze interní bezpečnostní specialista. Při jedné návštěvě u zákazníka mohou být vyřešeny například závady a zároveň i pravidelná revize. Standardně je vyřešen jen jeden požadavek, ale je možné přidat jich i více. Není možné ale mít servisní zásah, který by neměl žádný požadavek. Pro každý požadavek, který jsme daným zásahem vyřešili, bychom měli nastavit v detailu požadavku, že je vyřešený a případně vyplnit i potřebná pole. Po nastavení příznaku, že je požadavek vyřešený a jeho uložení již není požadavek možné editovat. 15 pokud za externí firmu eviduje data interní asistentka nebo operátorka, budeme stejně mluvit o externí firmě – to může nastat např. v případě, že dodavatelská servisní firma nedisponuje výpočetní technikou, na které by bylo možné aplikaci provozovat

33

Pro servisní zásah zadáváme seznam položek z ceníku, které mají být fakturovány. Standardně zde musejí být zadány všechny položky, které nám bude chtít fakturovat servisní firma. Při založení nového záznamu o servisním zásahu jsou zde načteny nejčastěji používané fakturační položky, které je možné nastavit v číselníku Typ požadavku na servisní zásah. V rámci servisního zásahu může dojít k instalaci nových nebo odebrání již evidovaných komponent a položek u zařízení - např. jsou nainstalována tři nová PIR čidla. Po schválení servisního zásahu bezpečnostním specialistou dojde k přenosu zde evidovaných změn k zařízení.

3.11.4.

Schvalování servisního zásahu

Dodavatelská servisní firma vytvoří záznam o servisním zásahu. V průběhu tvorby je zásah ve stavu Rozpracovaný. Poté, co jej servisní firma dokončí, předá jej ke schválení bezpečnostnímu specialistovi. V té chvíli je záznam ve stavu Čeká na schválení. BS může záznam o zásahu vrátit servisní firmě k doplnění nebo přepracování – v tom případě by měl telefonicky informovat příslušného uživatele ze servisní firmy, nebo by měl zapsat poznámku do záznamu o zásahu. Pokud BS záznam vrátil, bude ve stavu Vráceno k doplnění. Bezpečnostní specialista může také záznam schválit - v tom případě dojde k převedení záznamu do stavu Schváleno a k jeho uzavření - nadále jej není možné žádným způsobem měnit. Při schválení může bezpečnostní specialista ještě zvolit, že mají být jako vyřešené nastaveny všechny požadavky na servis, které jsou uvedené v daném zásahu. Po schválení dojde k přenosu záznamů ze záložky Fakturace do standardního zpracování podkladů pro fakturaci zákazníkovi a také k přenosu podkladů pro tvorbu faktur přijatých, tedy fakturace ze strany dodavatelské servisní firmy vůči naší společnosti.

3.11.5.

Servisní položka Ceník

Servisní položky představují ceník - pokud chceme fakturovat nějakou práci nebo materiál, musíme je nejprve zadat do ceníku. Pro každou položku můžeme zadávat její cenu, včetně období platnosti této ceny (můžeme tedy s dostatečným předstihem připravovat ceníky na nový rok). Struktura ceníku vychází z podkladů od České spořitelny. K položce si můžeme do systému uložit libovolný počet v podstatě libovolných souborů (jsme limitováni pouze velikostí souborů, která je nastavená společně pro celé

34

PS). Sem můžeme ukládat různou dokumentaci popisující instalaci, protokoly, zprávy, příručky apod. K servisní položce si můžeme připojit i libovolný počet textových poznámek.

3.11.6.

Komponenty

Komponenty nám umožňují evidovat jednotlivé části zařízení, u kterých chceme mít informace o jednotlivých výrobních číslech položek. Komponenta je založena na ceníkové položce a o ní se liší pouze tím, že navíc zaznamenáme konkrétní výrobní číslo daného kusu. Pro jednotlivé Typy požadavků na servisní zásah je možné určit, jaké servisní (ceníkové) položky jsou pro tento typ požadavku nejčastěji fakturované. Takové položky jsou potom načteny do formuláře při evidenci Servisního zásahu a uživatel je může jednoduše použít pouhým doplněním počtu použitých jednotek (např. jen zadá 10 km do položky doprava).

3.11.7.

Inspekce zařízení

Jednotliví bezpečnostní specialisté mohou vykonávat na zařízeních inspekci. Stručný popis provedené inspekce je možné zaevidovat právě v této části PS. Při zadání detailu inspekce vybereme bezpečnostního specialistu, který inspekci provedl, zadáme datum provedení inspekce a zapíšeme stručný popis. Volitelně si můžeme zapsat i poznámku k provedené inspekci.

3.11.8.

Nová instalace zařízení

Nová instalace zařízení umožňuje evidovat různé varianty rozpočtů pro nové instalace nebo rekonstrukce zařízení u zákazníka. Pro jednotlivé verze můžeme nastavit i servisní firmy, které mají mít možnost rozpočet připravit16.

3.11.9.

Faktury přijaté

Pokud mluvíme o fakturách přijatých, pak se jedná o faktury vystavené dodavatelskými servisními firmami, které naše společnost přijímá ke zpracování. Ve faktuře mohou být zahrnuta data pouze ze schválených servisních zásahů. Externí firma má možnost vytisknout si podklady pro vytvoření faktury, a nesmí fakturovat jinou částku, než která vyplývá z těchto evidovaných podkladů. 16

tato funkcionalita bude spuštěna v další fázi projektu 35

Pod pojmem zpracování faktur přijatých rozumíme proces, kdy párujeme přijatou fakturu na schválené servisní zásahy. Pro každou přijatou fakturu si zadáme její hodnotu bez DPH17. V celém PS pracujeme vždy s cenami bez DPH a jeho hodnota nás tedy nezajímá. Dále zadáme servisní společnost, od které jsme fakturu přijali a období, za které je vystavena a následně můžeme přidávat servisní zásahy, které jsou zahrnuté v dané faktuře. Přenos faktur přijatých do Heliosu není v první fázi automatizovaně podporován, ale předpokládáme jej v další fázi.

3.11.10.

Fakturace zákazníkovi

Na základě schválených servisních zásahů vznikají podklady pro fakturaci zákazníkovi. Ceny pro zákazníka vycházejí z ceníků, kde jsou udržovány ceny nákupní (tyto ceny fakturují servisní firmy nám) a ceny prodejní (tyto ceny fakturujeme my zákazníkovi). U každého záznamu v servisním zásahu je možné určit, jestli má nebo nemá být fakturován zákazníkovi. Pokud se má fakturovat, dojde v okamžiku schválení zásahu k přenosu podkladů do standardního procesu fakturace v PS. Ve formulářích pro fakturaci jsou připravené záložky Servis, na kterých jsou vidět obvyklým způsobem podklady vzniklé v novém modulu. Co se týká dalšího zpracování podkladů a faktur, tyto se nijak neliší do již rutinně prováděné fakturace zákazníkům.

3.11.11.

Číselníky

Pro potřeby modulu Servis zařízení vznikla řada číselníků. Číselníky bude nutné nastavit tak, aby usnadnily práci uživatelům – například nejčastěji používané položky v číselníku Typ požadavku na servis mohou výrazně zjednodušit zadávání výkazů o servisních zásazích.

3.11.12.

Bezpečnostní specialista

Pro potřeby Servisu zařízení byla rozšířena funkcionalita formuláře pro evidenci uživatelů, kdy je možné nastavit, že daný uživatel je bezpečnostním specialistou

17

DPH – daň z přidané hodnoty - je dopočtena automaticky pouze pro přehlednost 36

(zaškrtnutím příslušné volby v detailu záznamu). Uživatelé označení jako bezpečnostní specialisté mohou schvalovat servisní zásahy18.

3.11.13.

Verze pro externí uživatele

Mimo interních uživatelů, pro které se vytvořený modul stane nedílnou součástí PS, budou Servis zařízení používat také externí uživatelé. Pro ně vznikla samostatná .NET verze webové aplikace, která je spuštěna na samostatném virtuálním webu v rámci IIS. Dále byla vytvořena samostatná databáze (PS_EXTERNI, resp. PS_EXTERNI_TEST). V těchto databázích nejsou uložena žádná data, jsou zde uloženy procedury, které pouze zavolají další uložené procedury v „ostrých“ databázích a předají jim příslušné parametry. I v případě kompromitace databáze pro externí uživatele tedy nedojde k žádnému úniku dat. Zůstávají zachovány standardní nastavování přístupových oprávnění, pouze pro externí uživatele bude založena samostatná skupina uživatelů PS_EXTERNI a do externí verze PS se dostanou pouze uživatelé z této skupiny. Při zadávání uživatelů do Active Directory19 tedy bude nutné nastavit členství ve skupině PS_EXTERNI. Pro každého externího uživatele bude nutné nastavit v „ostré“ databázi také členství v uživatelské roli „Externí uživatel – servis“, protože uživatel, který není členem žádné role, nemůže pracovat v PS. Pro externí uživatele je mírně modifikován design formulářů, ale základní prvky zůstaly zachovány, jak je vidět z následující ukázky formuláře. Součástí je i samostatná nápověda, kde je popsán pouze tento modul.

18

V tomto okamžiku mohou schvalovat servisní zásahy všichni uživatelé interní části Servisu zařízení, protože je nutné mít dostupnou tuto funkcionalitu i pro všechny testovací uživatele 19 Active Directory je implementace adresářových služeb LDAP firmou Microsoft pro použití v prostředí systému Microsoft Windows 37

Obrázek 15 - Požadavky na servisní zásah Zdroj: printscreen z aplikace

38

3.11.14.

Datový model

Pro potřeby modulu Servis zařízení vznikla řada nových tabulek a procedur. Pro všechny záznamy je obvyklým způsobem evidována historie změn. Pouze pro hrubý přehled přikládám ukázku digramu, na kterém jsou zachyceny tabulky pro Servis zařízení a vazby na nejbližší evidence (zakázky, zákazníka, servisní firmy apod.) cis_komponenta_druh cis_komponenta_druh_id kod popis poznamka poradi znamka

srv_instalace

bigint not null varchar(3) not null varchar(20) not null varchar(255) null varchar(5) null timestamp not null

cis_komponenta_stav cis_komponenta_stav_id kod popis poznamka poradi znamka


srv_komponenta srv_komponenta_id srv_polozka_id cis_komponenta_stav_id cis_vlastnictvi_id kod popis cena_nakup cena_prodej vychozi vyrobni_cislo nakup prodej zaruka_do poznamka znamka

bigint bigint bigint bigint varchar(10) varchar(50) decimal(12,2) decimal(12,2) char(1) varchar(30) datetime datetime datetime varchar(255) timestamp

not null not null not null null not null not null null null not null null null null null null not null

srv_polozka srv_polozka_id cis_komponenta_druh_id druh skupina kod nazev popis vychozi poznamka zaruka poradi nabizet nahrada_polozka_id znamka

bigint bigint varchar(5) varchar(50) varchar(30) varchar(50) varchar(1000) char(1) varchar(1000) int varchar(5) char(1) bigint timestamp

not null not null not null not null not null not null not null not null null null null not null null not null

srv_instalace_id fir_zakaznik_id zak_zakazka_kod nazev datum kontakt_jmeno kontakt_telefon kontakt_mail kontakt_fax adresa poznamka znamka

bigint not null bigint not null varchar(15) null varchar(50) not null datetime not null varchar(30) null varchar(20) null varchar(30) null varchar(20) null varchar(100) null varchar(255) null timestamp not null

srv_instalace_verze srv_instalace_verze_id srv_instalace_id verze datum_vytvoreni popis znamka

bigint not null bigint not null int not null datetime not null varchar(255) null timestamp not null

srv_instalace_polozka

srv_polozka_cena srv_polozka_cena_id srv_polozka_id datum_od datum_do cena_nakup cena_prodej poznamka znamka

bigint not null bigint not null datetime not null datetime null decimal(12,2) null decimal(12,2) null varchar(255) null timestamp not null

srv_instalace_polozka_id srv_instalace_verze_id srv_polozka_id pocet cena_nakup cena_prodej poznamka znamka

bigint bigint bigint int decimal(12,2) decimal(12,2) varchar(50) timestamp

not null not null not null not null not null not null null not null

srv_instalace_firma srv_instalace_firma_id bigint not null srv_instalace_verze_id bigint not null fir_servis_id bigint not null znamka timestamp not null

srv_zarizeni_komponenta

cis_smlouva cis_smlouva_id kod popis poznamka poradi znamka


srv_zarizeni_komponenta_id srv_zarizeni_id srv_komponenta_id umisteni poznamka znamka

bigint not null varchar(3) not null varchar(20) not null varchar(255) null varchar(5) null char(1) not null timestamp not null

srv_zarizeni_polozka_id srv_zarizeni_id srv_polozka_id pocet poznamka znamka

bigint bigint bigint int varchar(255) timestamp

adm_uzivatel

not null not null not null null null not null

srv_zarizeni_polozka

cis_vlastnictvi cis_vlastnictvi_id kod popis poznamka poradi fakturovat znamka

bigint bigint bigint varchar(30) varchar(255) timestamp

not null not null not null not null null null

srv_specialista srv_specialista_id adm_uzivatel_id jmeno prijmeni telefon email platny znamka

bigint not null bigint not null varchar(20) not null varchar(20) not null varchar(20) null varchar(40) null char(1) not null timestamp not null

adm_uzivatel_id jmeno login email telefon zam_zamestnanec_id blokace typ vsechny_zakazky fir_agentura_id fir_vyjezdovka_id fir_servis_id specialista_servis jmen prijmeni znamka

bigint varchar(50) varchar(50) varchar(255) varchar(20) bigint char(1) char(1) char(1) bigint bigint bigint char(1) varchar(25) varchar(25) timestamp

not null not null not null null null null not null not null not null null null null not null not null not null not null

fak_polozka fak_polozka_id reg_cislo nazev skupina_zbozi jednotka poradi typ_polozky zruseno znamka

srv_inspekce srv_inspekce_id srv_zarizeni_id srv_specialista_id datum popis poznamka znamka

zak_specialista zak_specialista_id bigint not null zak_zakazka_kod varchar(15) not null srv_specialista_id bigint not null znamka timestamp not null

cis_stredisko cis_stredisko_kod varchar(30) not null nazev varchar(40) not null

bigint bigint bigint datetime varchar(2000) varchar(255) timestamp

not null not null not null not null not null null not null

srv_zarizeni fir_zakaznik

fak_faktura_radek fak_faktura_radek_id fak_faktura_hlava_id zak_zakazka_kod fak_polozka_id jednotka pocet cena_jednotka cena objednavka cis_stredisko_kod specifikace stat_zakazka pausal extra rozdeleni_faktur fak_skupina_faktur typ_polozky stat_zakazka_znak poznamka znamka

bigint bigint varchar(15) bigint varchar(10) decimal(7,2) decimal(12,2) decimal(12,2) varchar(30) varchar(30) varchar(200) varchar(15) char(1) char(1) varchar(30) varchar(30) varchar(30) char(1) varchar(500) timestamp

not null not null not null not null not null not null not null not null null null null null null null null null null null null not null

zak_servis zak_servis_id zak_zakazka_kod fir_servis_id srv_servis_fakturace_id fak_polozka_id sys_polozka_stav_kod fak_faktura_radek_id datum rok mesic den tyden pocet jednotka cena_jednotka cena cis_stredisko_kod objednavka specifikace rozdeleni_faktur poznamka znamka

bigint varchar(15) bigint bigint bigint char(1) bigint datetime int int int int decimal(7,2) varchar(10) decimal(12,2) decimal(12,2) varchar(30) varchar(30) varchar(200) varchar(30) varchar(500) timestamp

not null not null not null not null not null not null null not null not null not null not null not null not null not null not null not null not null null null null null not null

fir_zakaznik_id nazev druhy_nazev ico dic segment segment_cislo misto adresa poznamka znamka

bigint not null varchar(100) not null varchar(100) null varchar(20) null varchar(15) null varchar(35) null int null varchar(100) null varchar(255) null varchar(255) null timestamp not null

zak_zakazka zak_zakazka_kod nazev druhy_nazev popis ukonceno datum_start_plan datum_start_skut datum_konec_plan datum_konec_skut cis_stredisko_kod nadrizena_kod nadrizena_popis manazer_kod manazer_popis fir_zakaznik_id zakaznik_popis zak_produkt_id produkt poznamka znamka hj ns

varchar(15) varchar(100) varchar(100) varchar(255) char(1) datetime datetime datetime datetime varchar(30) varchar(15) varchar(120) varchar(15) varchar(120) bigint varchar(100) bigint varchar(45) varchar(255) timestamp varchar(20) varchar(20)

not null not null null not null not null null null null null null null null null null null null null null null not null null null

bigint not null bigint not null int not null int not null varchar(20) null decimal(12,2) not null decimal(12,2) not null varchar(255) null timestamp not null

srv_faktura_servis bigint bigint bigint timestamp

not not not not

sys_polozka_stav

not null not null not null null null null not null null null null null null null not null null null null null null null null null null null null not null


null null null null

bigint bigint bigint datetime char(5) bigint varchar(15) bigint varchar(30) varchar(20) varchar(30) varchar(20) varchar(100) bigint bigint bigint bigint varchar(20) datetime varchar(20) char(1) datetime char(5) varchar(255) varchar(255) varchar(255) timestamp

srv_servis_fakturace

cis_pozadavek cis_pozadavek_id fak_polozka_id kod popis poznamka poradi fps znamka

bigint not null bigint not null varchar(3) not null varchar(30) not null varchar(255) null varchar(5) null varchar(20) null timestamp not null

srv_servis_fakturace_id srv_servis_id srv_polozka_id fak_polozka_id jednotka pocet cena_jednotka_nakup cena_nakup cena_jednotka_prodej cena_prodej objednavka cis_stredisko_kod sys_polozka_stav_kod specifikace rozdeleni_faktur poznamka fakturovat znamka

cis_pozadavek_polozka cis_pozadavek_polozka_id bigint not null cis_pozadavek_id bigint not null srv_polozka_id bigint not null znamka timestamp not null

cis_typ_revize srv_zarizeni_pozadavek srv_zarizeni_pozadavek_id srv_zarizeni_id cis_pozadavek_id cis_kniha_servis_id datum_od datum_do popis pocet jednotka lhuta znamka


srv_pozadavek_id srv_zarizeni_id cis_pozadavek_id datum_plan cas_plan fir_zakaznik_id zak_zakazka_kod cis_zadrzeni_id kontakt_jmeno kontakt_telefon kontakt_mail kontakt_fax adresa fir_servis_id cis_kniha_servis_id srv_zarizeni_pozadavek_id cis_teritorium_id typ_vzniku datum_vzniku cislo_objednavky vyreseno datum_vyreseni cas_vyreseni popis_zavada popis_reseni poznamka znamka

sys_polozka_stav_kod char(1) not null popis varchar(50) not null

cis_teritorium cis_teritorium_id kod popis poznamka poradi znamka

srv_pozadavek

bigint not null varchar(100) not null varchar(100) null varchar(20) null varchar(15) null varchar(35) null int null varchar(100) null varchar(255) null varchar(255) null timestamp not null

srv_faktura_servis_id srv_servis_id srv_faktura_id znamka

cis_zadrzeni

srv_faktura srv_faktura_id fir_servis_id rok mesic cislo castka castka_s_dph poznamka znamka

bigint varchar(20) varchar(30) datetime datetime datetime char(1) bigint bigint bigint varchar(15) bigint varchar(20) bigint varchar(30) varchar(20) varchar(30) varchar(20) varchar(100) datetime datetime varchar(255) bigint bigint bigint timestamp

cis_zadrzeni_id kod popis poznamka poradi znamka

fir_servis fir_servis_id nazev druhy_nazev ico dic segment segment_cislo misto adresa poznamka znamka

srv_zarizeni_id kod vyrobni_cislo nakup prodej zaruka_do aktivni cis_zadrzeni_id cis_teritorium_id fir_zakaznik_id zak_zakazka_kod cis_smlouva_id cislo_smlouvy cis_vlastnictvi_id kontakt_jmeno kontakt_telefon kontakt_mail kontakt_fax adresa pronajem_od pronajem_do poznamka fir_servis_id srv_specialista_id srv_komponenta_id znamka

bigint not null varchar(30) not null varchar(100) not null varchar(3) not null varchar(10) null varchar(5) null varchar(30) null char(1) not null timestamp not null

bigint bigint bigint bigint datetime datetime varchar(255) int char(1) int timestamp

not null not null not null not null null null not null not null not null not null not null

cis_typ_revize_id kod popis koeficient znamka

cis_kniha_servis not null not null not null not null null not null not null null null null null null null null null null null not null not null null not null null null null null null not null

cis_kniha_servis_id kod popis poznamka poradi znamka


bigint bigint bigint varchar(15) bigint datetime char(5) varchar(255) char(1) bigint bigint datetime timestamp

not null not null not null not null not null not null null not null not null null null null not null

rok int mesic int den int tyden int

Obrázek 16 – diagram modulu Servis zařízení Zdroj: vlastní úprava pomocí Case nástroje Powerdesigner)

39

srv_servis_polozka srv_servis_polozka_id srv_servis_id srv_polozka_id pohyb pocet poznamka znamka

bigint bigint bigint char(1) int varchar(255) timestamp

not null not null not null not null not null null not null

srv_servis_komponenta

srv_servis srv_servis_id fir_servis_id fir_zakaznik_id zak_zakazka_kod srv_zarizeni_id datum cas popis schvaleno srv_specialista_id cis_typ_revize_id schvaleno_dne znamka

bigint not null varchar(3) not null varchar(20) not null decimal(6,4) not null timestamp not null

srv_servis_komponenta_id srv_servis_id srv_komponenta_id cis_komponenta_stav_id pohyb poznamka umisteni znamka

bigint bigint bigint bigint char(1) varchar(255) varchar(30) timestamp

not null not null not null null not null null null not null

srv_servis_pozadavek srv_servis_pozadavek_id bigint not null srv_servis_id bigint not null srv_pozadavek_id bigint not null znamka timestamp not null

bigint bigint bigint bigint varchar(10) decimal(7,2) decimal(12,2) decimal(12,2) decimal(12,2) decimal(12,2) varchar(30) varchar(30) char(1) varchar(200) varchar(30) varchar(500) char(1) timestamp

not null not null not null not null not null not null not null not null not null not null null null not null null null null not null not null

3.12.

Implementace servisního modulu

Pro vývoj aplikace jsme v prostředí PS založili novou databázi s názvem PS_vyvoj a novou aplikační část v nichž byly prováděny veškeré práce spojené s rozšířením PS o modul servisních činností. Nastavili jsme přístup pro testovací uživatele, kteří průběžně prováděli testování. Průběh testování bude popsán v dalším textu. Implementace probíhala v několika fázích, kdy se vždy otestovala daná funkcionalita podle scénářů. V konečné fázi vývoje byla aplikace předána jako celek k plnému otestování a převzetí do ostrého provozu. V následujících kapitolách popíšu celý systém tak jak je navržen, včetně práce s ním.

3.13.

Práce se servisním modulem

Uživateli, který má přiřazenu roli Servis zařízení, se po přihlášení do PS zobrazí nové menu s tímtéž názvem – viz obrázek.

Obrázek 17 - menu Servis zařízení Zdroj: printscreen z aplikace

Jak je na obrázku vidět, pod tímto menu se skrývá několik podmenu, která si nyní popíšeme.

40

3.13.1.

Podmenu – Zařízení

Zařízení je základní komponentou pro celý modul Servisu zařízení a majetku. Zařízení představuje jeden logický celek, který je instalovaný u zákazníka a pro který evidujeme další informace (typickým zařízením je např. EZS, trezor apod.). K zařízení jsou evidovány Požadavky na servisní zásah a následně také Servisní zásahy. Zařízení se může skládat z Položek nebo Komponent. Vybereme-li podmenu Zařízení, zobrazí se nám seznam všech evidovaných zařízení na kartě Servisovaná zařízení. V seznamu vidíme zařízení, která jsou evidována v systému. V horní části můžeme buď pomocí standardních filtrů nebo tzv. rychlých filtrů zmenšit množství záznamů zobrazených v hlavní části formuláře. Pokud je aktuálně přihlášený uživatel bezpečnostním specialistou, je pro něj standardně nastaven rychlý filtr tak, aby měl zobrazená jen zařízení, která mu náleží.

Obrázek 18 - Seznam servisovaných zařízení bez filtru Zdroj: printscreen z aplikace

41

Obrázek 19 - Seznam servisovaných zařízení s rychlým filtrem pro BS Zdroj: printscreen z aplikace

Můžeme otevřít formulář pro založení nového záznamu pomocí tlačítka Nový záznam. Formulář pro pořízení nového záznamu vypadá takto.

Obrázek 20 - formulář pro založení nového zařízení Zdroj: printscreen z aplikace

42

Pro nové zařízení máme dostupná jen základní pole o zařízení na záložce Základní údaje. U zařízení můžeme nastavit, zda je či není aktivní. Rozdíl mezi nimi je pouze ten, že v dalších seznamech jsou neaktivní zařízení nabízena pouze na vyžádání. Tím můžeme skrýt zařízení, která již nejsou servisována nebo naopak která dosud nejsou zprovozněna. Kód produktu zadáme natolik popisný, abychom mu rozuměli - např. EZS Spořitelna Rudná, Trezor Náchodská P-9 apod. Zadáme výrobní číslo zařízení, jeho datum nákupu, prodeje a datum konce záruky. Zadáme typ vlastnictví, přičemž je zadáváme z pohledu zákazníka. Dále zadáme zákazníka a zakázku, na které je zařízení přiřazené. Pokud zakázka není v seznamu dostupných zakázek, je nutné se obrátit na oddělení kontrolingu, aby zakázku zadali do systému Helios a následně ji přenesli do PPS U zařízení můžeme nastavit servisní firmu, která obvykle provádí servis tohoto zařízení. Dále můžeme zadat informaci o umístění zařízení (tzv. objekt), pokud nám nestačí údaje načtené ze zakázky. Zadáme servisního specialistu, který se bude o dané zařízení starat. Dále můžeme zadat Typ zadržení (např. Čeká na schválení specialistou) a Teritorium (např. Hradec Králové). Můžeme si poznamenat i typ smlouvy a její číslo, kterou máme se zákazníkem uzavřenou. A také si můžeme poznamenat, od kdy do kdy je zařízení pronajaté zákazníkovi. Po zadání základních údajů můžeme pomocí tlačítka Uložit zavřít detail a vrátit se do seznamu. Nebo pomocí Uložit a nový ihned otevřeme formulář pro zadání dalšího zařízení. A nebo pomocí Uložit a editovat uložíme základní údaje a budeme moci zadávat data do dalších záložek. Ze seznamu zařízení můžeme přejít do detailu záznamu pomocí ikony

v prvním

sloupci seznamu. Detail zařízení se skládá z několika záložek. Záložka Základní údaje je popsána výše. Na záložce Komponenty můžeme evidovat komponenty a další položky, ze kterých se celé zařízení skládá. V horní části záložky evidujeme komponenty s výrobním číslem. Každá komponenta, kterou chceme v systému evidovat, musí být nejprve založena v seznamu komponent. Můžeme přiřadit novou komponentu k zařízení (tlačítko Nový záznam), případně již dříve přiřazenou komponentu odebrat ikonou nebo zobrazit detail komponenty ikonou. Pro každou komponentu si můžeme zapsat poznámku a případně změnit její umístění (např. Ve skladu, U zákazníka apod.). 43

Dále můžeme v části Soupis ostatních položek zaevidovat další položky ceníku, ze kterých se zařízení skládá - například 5x čidlo PIR pro EZS. Opět si můžeme zapsat poznámku a přidávat nebo měnit informace obvyklým způsobem.

Obrázek 21 - záložka komponenty Zdroj: printscreen z aplikace

í

Obrázek 22 - formulář pro zadání nové komponenty pro zařízení

Obrázek 23 – formulář pro zadání nové položky v zařízení



Oba tyto seznamy můžeme ovlivnit také zadáním komponent nebo položek, které byly přidány nebo odebrány v rámci servisního zásahu. Pro zařízení může být zapotřebí zadat pravidelně se opakující revize nebo kontroly. K tomu účelu je zde záložka Pravidelné kontroly a revize. V tom případě nemusíme zadávat opakovaně jednotlivé požadavky, ale můžeme je zadat pomocí pravidelně

44

opakovaného. Při zadávání zadáme Servisní knihy a Typ požadavku. Dále zadáme interval, ve kterém se mají požadavky vytvořit (pokud nezadáme konec intervalu, budou vytvořeny požadavku do konce roku 2020). Dále zadáme Popis (např. Měsíční prohlídka) a zadáme četnost - v našem příkladu zadáme 241 Měsíců. Dále zadáme, kolik dní před termínem má být vyvoláno upozornění servisní firmě. Stiskem tlačítka Uložit dojde k vygenerování požadavků na servisní zásah, které budou zobrazeny na další záložce (s mírným zpožděním cca 2-3 sekund). Při změně nebo smazání záznamu dojde i ke smazání a případně novému založení požadavků, které vznikly na základě daného hromadného zadání.

Obrázek 23 - formulář pro zadání pravidelné činnosti Zdroj: printscreen z aplikace

Na záložce Požadavky vidíme seznam požadavků, které mohly být vytvořené hromadně podle výše uvedeného popisu.

45

Obrázek 24 - záložka požadavky Zdroj: printscreen z aplikace

Dále zde můžeme vytvořit nový požadavek na servisní zásah. Pomocí tlačítka Nový záznam zobrazíme formulář, kde v horní části zadáme Servisní knihu a Typ požadavku. Dále zadáme datum a volitelně i čas, kdy má být požadavek vyřešen.

Obrázek 25 - formulář pro zadání požadavku na servis Zdroj: printscreen z aplikace

Po vyřešení zaškrtneme příslušné pole a zapíšeme datum (případně opět i s časem) vyřešení tohoto požadavku. POZOR. Po schválení již není možné požadavek žádným způsobem měnit, bude jej možné pouze zobrazovat.

46

V pravé horní části můžeme změnit Typ zadržení a případně Teritorium a také si poznamenat číslo objednávky, na základě které tento požadavek vznikl. Ve střední části formuláře jsou informace o zákazníkovi, zakázce, objektu a servisní firmě - tyto údaje jsou předvyplněny z informací zadaných v základních údajích zařízení a je možné je pro daný zásah změnit. Ve spodní části formuláře je prostor pro popsání závady, způsobu vyřešení a případné poznámky.

Na základě požadavků na servisní zásah vznikají servisní zásahy, tedy konkrétní práce servisní firmy na zařízení. Jsou uloženy na záložce Servisní zásahy. Na této záložce vidíme seznam servisních zásahů, které byly provedené na dané záložce. Standardně jsou zobrazeny pouze schválené zásahy, ale můžeme si odškrtnutím příslušného pole zobrazit i rozpracované záznamy o servisním zásahu. Z této záložky můžeme zobrazit detail vybraného servisního zásahu, není možné založit nový servisní zásah.

Obrázek 26 - seznam servisních zásahů Zdroj: printscreen z aplikace

Obrázek 27 - detail servisního zásahu – základ Zdroj: printscreen z aplikace

47

Obrázek 28 - detail servisního zásahu – fakturace Zdroj: printscreen z aplikace

Jednotliví bezpečnostní specialisté mohou vykonávat na zařízeních inspekci. Stručný popis provedené inspekce je možné zaevidovat přávě na záložce Inspekce. Ve formuláři pro zadání detailu inspekce vybereme specialistu, který inspekci provedl, zadáme datum provedení inspekce a zapíšeme stručný popis. Volitelně si můžeme zapsat i poznámku k provedené inspekci.

Obrázek 29 - detail formuláře pro zadání inspekce Zdroj: printscreen z aplikace

K zařízení si můžeme do systému uložit libovolný počet v podstatě libovolných souborů (jsme limitováni pouze velikostí souborů, která je nastavená společně pro celý PS) a to na záložku Soubory. Sem můžeme ukládat různou dokumentaci popisující instalaci, protokoly, zprávy, příručky apod. K zařízení si můžeme připojit i libovolný počet textových poznámek a to na záložce Poznámky.

48

3.13.2.

Podmenu – Požadavky na servis

Požadavky na servisní zásah vznikají buď jako pravidelně se opakující, například roční revize zařízení. Druhým způsobem jsou nečekané požadavky, kdy zákazník hlásí nějakou chybu nebo problém na zařízení. Požadavek musí být v systému evidován nejpozději v okamžiku, kdy chceme evidovat servisní zásah. Seznam evidovaných požadavků je dostupný například z menu Servis zařízení Požadavky na servis (další možností je zobrazit seznam požadavků na servis konkrétního zařízení)

Obrázek 30 - seznam požadavků na servis Zdroj: printscreen z aplikace

V seznamu vidíme požadavky, které jsou evidovány v systému. V horní části můžeme buď pomocí standardních filtrů nebo tzv. rychlých filtrů zmenšit množství záznamů zobrazených v hlavní části formuláře. Standardně jsou zobrazeny požadavky na aktuální měsíc, které nejsou vyřešené. Pokud je naplánované datum vyřešení požadavku shodné nebo menší než aktuální datum, pak je takový záznam v seznamu znázorněný červenou barvou písma Do detailu záznamu můžeme přejít pomocí ikony

v prvním sloupci seznamu.

Můžeme také otevřít formulář pro založení nového záznamu pomocí tlačítka Nový záznam.

49

Požadavek je možné ze seznamu nevratně smazat ikonou

ve druhém sloupci

seznamu. Doporučujeme mazání provádět pouze v případě, že je duplicitně založený nějaký požadavek. Pokud chceme požadavek vyřadit ze seznamu tak, abychom se mohli podívat, proč jsme jej vyřadili, je možné zapsat si v detailu záznamu do pole Poznámka vysvětlení a požadavek nastavit jako vyřešený. Tím zůstane evidovaný v systému, ale nebude se již dále nabízet v seznamu nevyřešených požadavků. Pokud chceme na základě požadavku přímo vytvořit záznam o servisním zásahu, můžeme použít ikonu

ve třetím sloupci seznamu.

Nahoře ve formuláři zadáme ID zařízení, pro které chceme zaevidovat nový požadavek na servis. Pokud ID (jednoznačný identifikátor) neznáme, můžeme pomocí tlačítka

zobrazit seznam evidovaných zařízení a z něj zařízení vybrat pomocí ikony

.

Tím dojde k přenesení informací od zařízení do formuláře požadavku na servis. V horní části formuláře je dále možné zadat Servisní knihu a Typ požadavku. Dále zadáme datum a volitelně i čas, kdy má být požadavek vyřešen. Po vyřešení zaškrtneme příslušné pole a zapíšeme datum (případně opět i s časem) vyřešení tohoto požadavku. POZOR. Po schválení již není možné požadavek žádným způsobem měnit, bude jej možné pouze zobrazovat. V pravé horní části můžeme změnit Typ zadržení a případně Teritorium a také si poznamenat číslo objednávky, na základě které tento požadavek vznikl. Ve střední části formuláře jsou informace o zákazníkovi, zakázce, objektu a servisní firmě - tyto údaje jsou předvyplněny z informací zadaných v základních údajích zařízení a je možné je pro daný zásah změnit. Ve spodní části formuláře je prostor pro popsání závady, způsobu vyřešení a případné poznámky.

50

Obrázek 31 - Požadavek na servis Zdroj: printscreen z aplikace

3.13.3.

Podmenu – Servisní zásahy

Servisní zásah představuje činnost servisní firmy, kdy se u zákazníka provádí servisní činnost. Servisní zásah musí být vždy založen na Požadavku na servis. Není možné vytvořit zásah, pro který by požadavek neexistoval. Servisní zásahy vždy vytváří externí servisní firma (pokud za externí firmu eviduje data interní asistentka nebo operátorka, budeme stejně mluvit o externí firmě). Pro externí firmy je k dispozici verze systému s omezenými přístupovými právy. Externí společnost mimo jiné nemůže schválit servisní zásah - to může udělat jen interní bezpečnostní specialista. Seznam evidovaných servisních zásahů je dostupný například z menu Servis zařízení - Servisní zásahy (další možností je zobrazit seznam zásahů konkrétního zařízení)

Obrázek 32 - Seznam servisních zásahů Zdroj: printscreen z aplikace

51

V seznamu vidíme záznamy o zásazích, které jsou evidovány v systému. V horní části můžeme buď pomocí standardních filtrů nebo tzv. rychlých filtrů zmenšit množství záznamů zobrazených v hlavní části formuláře. Standardně jsou zobrazeny zásahy za aktuální měsíc, které nejsou schválené. Pokud je aktuálně přihlášený uživatel bezpečnostním specialistou, je pro něj standardně nastaven rychlý filtr tak, aby měl zobrazené jen zásahy na zařízeních, která mu náleží. Do detailu záznamu můžeme přejít pomocí ikony


Pokud chceme založit nový požadavek, máme několik možností. První z nich je otevřít formulář pro založení nového záznamu pomocí tlačítka Nový záznam. V tom případě musíme znát ID požadavku na servisní zásah (pokud ID neznáme, můžeme je vybrat ze seznamu evidovaných požadavků). Dále můžeme zásah založit ze seznamu požadavků, jak je popsáno v kapitole Požadavky na servis. Při založení nového záznamu o servisním zásahu jsou dostupná pouze pole na záložce Základ. Je předvyplněno datum realizace servisního zásahu na aktuální datum. Z řešeného požadavku jsou přebrány informace o servisní firmě. Dále jsou zobrazeny základní informace o požadavku.

Obrázek 33 - nový záznam o servisním zásahu Zdroj: printscreen z aplikace

Pokud jsme omylem založili servisní zásah z chybného požadavku, můžeme formulář zavřít bez uložení tlačítkem Zavřít bez uložení. Pokud jsme založili záznam správně, uložíme data tlačítkem Uložit a editovat. Tím dojde k založení záznamu o servisním zásahu, budou zpřístupněny další záložky a jako aktivní bude nastavena záložka Fakturace.

52

Na první záložce s názvem Základ můžeme zadávat seznam požadavků, které jsme vyřešili daným servisním zásahem. Při jedné návštěvě u zákazníka mohou být vyřešeny například závady a zároveň i pravidelná revize. Standardně je vyřešen jen jeden požadavek, ale je možné přidat jich i více. Není možné ale mít servisní zásah, který by neměl žádný požadavek. Přidání dalšího požadavku provedeme pomocí tlačítka Nový záznam na záložce základ. Pokud potřebujeme odebrat požadavek ze servisního zásahu, použijeme ikonu ve druhém sloupci seznamu požadavků Z formuláře zásahu můžeme otevřít detail požadavku pomocí ikony

v prvním

sloupci seznamu. Pro každý požadavek, který jsme daným zásahem vyřešili, bychom měli nastavit v detailu požadavku, že je vyřešený a případně vyplnit i potřebná pole. POZOR po nastavení příznaku, že je požadavek a jeho uložení tlačítkem Uložit již není požadavek možné editovat, ani v případě že neuložíme záznam o servisním zásahu.

Obrázek 34 - Detail servisního zásahu – základ Zdroj: printscreen z aplikace

Na záložce Fakturace zadáváme seznam položek z ceníku, které mají být fakturovány. Standardně zde musejí být zadány všechny položky, které nám bude chtít fakturovat servisní firma. Při založení nového záznamu o servisním zásahu jsou zde načteny nejčastěji používané fakturační položky, které je možné nastavit v číselníku Typ požadavku na servisní zásah. Pokud se zde požadovaná položka nenachází, můžeme ji přidat z formuláře, který otevřeme pomocí tlačítka Nový záznam. Následně je zobrazen detail fakturované položky, kde můžeme změnit výběr položky z ceníku, případně změnit počat kusů nebo zadat poznámku.

53

Počet kusů a poznámku můžeme změnit následně i přímo z formuláře servisního zásahu. Navíc zde můžeme nastavit, zda má být daná položka fakturována zákazníkovi. Pokud chceme některou položku odebrat, můžeme ji smazat pomocí ikony

ve druhém sloupci

seznamu položek.

Obrázek 35 - detail servisního zásahu – fakturace Zdroj: printscreen z aplikace

V rámci servisního zásahu může dojít k instalaci nové nebo odebrání již evidované komponenty u zařízení - např. je odebrán rekordér a namontován jiný. V této záložce můžeme zadat seznam komponent, které byly při daném servisním zásahu přidány/odebrány. Po schválení servisního zásahu specialistou dojde k přenosu zde evidovaných změn k zařízení, jak jsme popisovali v kapitole Zařízení.

Obrázek 36 - detail servisního zásahu – komponenty Zdroj: printscreen z aplikace

V rámci servisního zásahu může dojít k instalaci nových nebo odebrání již evidovaných položek u zařízení - např. jsou nainstalována tři nová PIR čidla. V této záložce můžeme zadat seznam položek, které byly při daném servisním zásahu přidány/odebrány. Po schválení servisního zásahu specialistou dojde k přenosu zde evidovaných změn k zařízení, jak jsme popisovali v kapitole Zařízení.

54

Obrázek 37 - detail servisního zásahu – položky Zdroj: printscreen z aplikace

K záznamu o servisním zásahu můžeme připojit libovolný počet souborů, např. dokumentaci popisující instalaci, protokoly, zprávy, příručky apod. Jsme limitováni pouze velikostí souborů, která je nastavená společně pro celé PPS.

Obrázek 38 - detail servisního zásahu – Soubory Zdroj: printscreen z aplikace

3.13.4.

Schvalování servisního zásahu

Externí firma vytvoří záznam o servisním zásahu. V průběhu tvorby je zásah ve stavu Rozpracovaný. Poté, co jej servisní firma dokončí, předá jej ke schválení bezpečnostnímu specialistovi. V té chvíli je záznam ve stavu Čeká na schválení.

Obrázek 39 - okno pro výběr stavu servisního zásahu Zdroj: printscreen z aplikace

Specialista může záznam o zásahu vrátit servisní firmě k doplnění nebo přepracování - v tom případě by měl telefonicky informovat příslušného uživatele z externí firmy, nebo by měl zapsat poznámku do záznamu o zásahu. Pokud specialista záznam vrátil, bude ve stavu Vráceno k doplnění. Specialista může také záznam schválit - v tom případě dojde k

55

převedení záznamu do stavu Schváleno a k jeho uzavření - nadále jej není možné žádným způsobem měnit. Při schválení může specialista ještě zvolit, že mají být jako vyřešené nastaveny všechny požadavky na servis, které jsou uvedené v daném zásahu (v tom případě použije volbu Schválit a vyřešit). Změna stavu se provádí pomocí přepínačů vedle tlačítka pro uložení. Po schválení dojde k přenosu záznamů ze záložky Fakturace do standardního zpracování podkladů pro fakturaci zákazníkovi a také k přenosu podkladů pro tvorbu faktur přijatých, tedy fakturace ze strany externí firmy vůči naší společnosti.

3.13.5.

Podmenu – Komponenty

Komponenty nám umožňují evidovat jednotlivé části zařízení, u kterých chceme mít informace o jednotlivých výrobních číslech položek. Komponenta je založena na ceníkové položce a od ní se liší pouze tím, že navíc zaznamenáme konkrétní výrobní číslo daného kusu. Seznam evidovaných komponent je dostupný z menu Servis zařízení - Komponenty V seznamu vidíme komponenty, které jsou evidovány v systému. V horní části můžeme buď pomocí standardních filtrů nebo tzv. rychlých filtrů zmenšit množství záznamů zobrazených v hlavní části formuláře. Do detailu záznamu můžeme přejít pomocí ikony


Můžeme také otevřít formulář pro založení nového záznamu pomocí tlačítka Nový záznam.

Obrázek 40 - detail komponenty zařízení Zdroj: printscreen z aplikace

56

Přestože každá komponenta musí být založena na záznamu z číselníku servisních položek, máme možnost u komponenty změnit většinu informací. Rozdíl mezi servisní položkou a komponentou je pouze v tom, že servisní (ceníková) položka není evidována pod svým výrobním číslem. U komponent naopak výrobní čísla evidujeme a může také zaznamenávat, kde je komponenta umístěna (např. u zákazníka, v servisu, ve skladu apod.) U komponent si můžeme poznamenat jejich datum nákupu, prodeje a případně i konce záruční doby.

3.13.6.

Podmenu – Servisní položky

Servisní položky představují ceník - pokud chceme fakturovat nějakou práci nebo materiál, musíme je nejprve zadat do ceníku. Pro každou položku můžeme zadávat její cenu, včetně období platnosti této ceny (můžeme tedy s dostatečným předstihem připravovat ceníky na nový rok). Struktura ceníku vychází z podkladů od stávajícího klienta. Seznam evidovaných komponent je dostupný z menu Servis zařízení - Servisní položky.

Obrázek 41 - seznam servisních položek Zdroj: printscreen z aplikace

57

V seznamu vidíme položky, které jsou evidovány v systému. V horní části můžeme buď pomocí standardních filtrů nebo tzv. rychlých filtrů zmenšit množství záznamů zobrazených v hlavní části formuláře. Standardně jsou v seznamu zobrazeny pouze aktuálně platné ceny. Pomocí volby Zobrazit rozšířený seznam s historií ceny položky můžeme zobrazit i všechny zadané ceny, tedy kompletní přehled vývoje cen pro každou položku Do detailu záznamu můžeme přejít pomocí ikony


Můžeme také otevřít formulář pro založení nového záznamu pomocí tlačítka Nový záznam. Druh komponenty, který zadáváme u položky, vychází z prvotního rozdělení ceníku na jednotlivé listy v MS Excelu, dodaného klientem. Přestože nyní je ceník spravován v PS, zvyklost velí toto rozdělení zachovat. Dále je nutné zadat, zda se jedná o dodávku, nebo montáž. V některých částech modulu pro evidenci servisu majetku a zařízení se zobrazují pouze položky s typem Dodávka, jinde Montáž a někde obě varianty. Pro položku můžeme zadat Skupinu (hrubší rozdělení v ceníku) a tři povinné hodnoty - Kód, Název a Popis. Volitelně si můžeme zadat délku záruky v měsících a pořadí zobrazování v seznamech. Dále můžeme pomocí zaškrtávacího pole nastavit, jestli má být daná položka zobrazována ke zpracování v nabídkových seznamech.

Obrázek 42 - detail servisní položky Zdroj: printscreen z aplikace

Na záložce Ceny je zobrazen seznam všech evidovaných cen u položky. Pokud chceme změnit platnost nebo další hodnoty v ceně, zobrazíme formulář pomocí ikony v prvním sloupci. Cenu můžeme smazat pomocí ikony

ve druhém sloupci. Nový

záznam o ceně zadáme v okně, které otevřeme pomocí tlačítka Nová cena

58

Pro jednotlivé Typy požadavků na servisní zásah je možné určit, jaké servisní (ceníkové) položky jsou pro tento typ požadavku nejčastěji fakturované. Takové položky jsou potom načteny do formuláře při evidenci Servisního zásahu a uživatel je může jednoduše použít pouhým doplněním počtu použitých jednotek (např. jen zadá 10 km do položky doprava) Zde můžeme určit, v jakých typech požadavků má být daná servisní položka nabízena jako nejčastěji používaná

Obrázek 43 - servisní položka - karta nejčastěji používané Zdroj: printscreen z aplikace

K položce si můžeme do systému uložit libovolný počet v podstatě libovolných souborů (jsme limitováni pouze velikostí souborů, která je nastavená společně pro celé PPS). Sem můžeme ukládat různou dokumentaci popisující instalaci, protokoly, zprávy, příručky apod. K servisní položce si můžeme připojit i libovolný počet textových poznámek

3.13.7.

Podmenu – Bezpečnostní specialisté

Tento formulář je vlastně číselník všech bezpečnostních specialistů, kteří mají odpovědnost za jednotlivé zakázky klienta. To, je-li uživatel PS bezpečnostním specialistou, se nastavuje v detailu uživatele PS, viz následující obrázky.

Obrázek 44 - seznam bezpečnostních specialistů Zdroj: printscreen z aplikace

59

Obrázek 45 - detail nastavení uživatele s vazbou na roli bezpečnostního specialisty Zdroj: printscreen z aplikace

3.13.8.

Podmenu – Inspekce zařízení

Jednotliví bezpečnostní specialisté mohou vykonávat na zařízeních inspekci. Stručný popis provedené inspekce je možné zaevidovat právě v této části PS. Při zadání detailu inspekce vybereme specialistu, který inspekci provedl, zadáme datum provedení inspekce a zapíšeme stručný popis. Volitelně si můžeme zapsat i poznámku k provedené inspekci.

Obrázek 46 - detail karty inspekce zařízení Zdroj: printscreen z aplikace

3.13.9.

Podmenu – Nová instalace zařízení

Nová instalace zařízení umožňuje evidovat různé varianty rozpočtů pro nové instalace nebo rekonstrukce zařízení u zákazníka. Pro jednotlivé verze můžeme nastavit i servisní firmy, které mají mít možnost rozpočet připravit. Seznam evidovaných komponent je dostupný z menu Servis zařízení - Nová instalace zařízení. V seznamu vidíme instalace, které jsou evidovány v systému. V horní části můžeme pomocí standardních filtrů zmenšit množství záznamů zobrazených v hlavní části formuláře.

60

Do detailu záznamu můžeme přejít pomocí ikony


Můžeme také otevřít formulář pro založení nového záznamu pomocí tlačítka Nový záznam. Pro novou instalaci si zadáme její název a odhadované datum realizace. Dále musíme vybrat zákazníka a volitelně i zakázku, na které se bude instalace provádět (může nastat situace, že zakázka ještě neexistuje a bude doplněna až později). Volitelně si můžeme poznamenat informace o objektu, kde bude instalace realizována.

Obrázek 47 - detail instalace zařízení Zdroj: printscreen z aplikace

Ve spodní části formuláře evidujeme jednotlivé verze rozpočtů. Novou verzi založíme tlačítkem Nový záznam. Již evidovanou verzi otevřeme ikonou sloupci. Verzi můžeme nevratně smazat pomocí ikony

v prvním

ve druhém sloupci.

Otevřeme-li detail verze instalace, máme k dispozici 2 záložky. Na záložce Firmy můžeme definovat externí firmy, které mají mít možnost pro danou verzi rozpočtu zadávat položky na druhé záložce. Pokud žádnou externí firmu nezadáme, bude daná nová instalace dostupná pouze interním uživatelům PS.

Obrázek 48 - detail verze instalace záložka Položky Zdroj: printscreen z aplikace

61

Na záložce Položky můžeme evidovat jednotlivé servisní (ceníkové) položky, které budou použity při realizaci. Součet cen těchto položek nám dává celkovou cenu instalace.

3.13.10.

Podmenu – Faktury přijaté - podklady

Pokud mluvíme o fakturách přijatých, pak se jedná o faktury vystavené servisními firmami a které naše společnost přijímá ke zpracování. Ve faktuře mohou být zahrnuta data pouze ze schválených servisních zásahů. Externí firma má možnost vytisknout si podklady pro vytvoření faktury, neměla by fakturovat jinou částku, než která vyplývá z těchto evidovaných podkladů. Formulář pro zobrazení podkladů můžeme vyvolat z menu Servis zařízení - FP podklady. Následně můžeme zvolit období, za které chceme podklady zobrazit, můžeme si volit servisní společnost a úroveň detailu a následně pomocí tlačítka Zobrazit načteme data.

Obrázek 49 - Podklady pro FP Zdroj: printscreen z aplikace

3.13.11.

Podmenu – Faktury přijaté - zpracování

Pod pojmem zpracování faktur přijatých rozumíme proces, kdy párujeme přijatou fakturu na schválené servisní zásahy. Seznam již evidovaných záznamů zobrazíme z menu Servis zařízení - FP zpracování. V seznamu vidíme pro zvolené období seznam již evidovaných faktur přijatých. Pokud se liší částka na faktuře s částkou vypočítanou v rámci PS, pak je takový záznam zvýrazněn červeným písmem.

62

Obrázek 50 - seznam faktur od servisů Zdroj: printscreen z aplikace

Pro každou přijatou fakturu si zadáme její hodnotu bez DPH (DPH je dopočteno automaticky pouze pro přehlednost). V celém PPS pracujeme vždy s cenami bez DPH a jeho hodnota nás tedy nezajímá. Dále zadáme servisní společnost, od které jsme fakturu přijali a období, za které je vystavena. Následně můžeme přidávat servisní zásahy, které jsou zahrnuté v dané faktuře. V horní části okna průběžně vidíme součet částek ze servisních zásahů. Přenos faktur do Heliosu je zpracován pomocí standardní funkcionality systému Helios Orange. PS připraví data v požadovaném formátu a naplní jimi příslušnou tabulku v db Helios Orange. V aplikaci Helios Orange je pak pomocí funkcionality s názvem Obecné importy umožněn import dat pro zpracování přijaté faktury.

Obrázek 51 - detail faktury od servisu Zdroj: printscreen z aplikace

3.13.12.

Číselníky

Číselníky slouží k uživatelskému nastavování seznamů a nabídek, které jsou následně používány v různých částech PPS. Umožňují poměrně snadno udržovat systém přehledný a uživatelsky přívětivý, protože na základě číselníků je možné následně filtrovat data nebo předpřipravovat některé operace tak, aby uživatel nemusel stále dokola provádět některé rutinní operace a činnosti. Typ vlastnictví majetku - je důležitý pro rozlišení, zda se jedná o majetek ve vlastnictví zákazníka, pronajatý zákazníkovi a nebo pouze zapůjčený zákazníkovi.

63

Teritoria - tento číselník slouží ke geografickému členění umístění jednotlivých zařízení, protože tato informace není obsažena u zakázky. Následně můžeme vytvářet např. přehledy, kolik servisních zásahů bylo provedeno v jednotlivých regionech apod. Typy smluv - jedná o typ smlouvy se zákazníkem Typy zadržení - obecně je využíván např. v okamžiku, kdy se zákazník stane neplatičem, nebo když specialista potřebuje pozdržet zásah např. z důvodu čekání na náhradní díly Typy požadavků na servis - jeden z klíčových číselníků modulu. Na základě typu požadavku na servis je možné připravit nejčastěji používané fakturační položky, takže uživatel při evidenci servisního zásahu bude mít výrazně usnadněnu činnost - drtivá většina fakturačních položek bude automaticky načtena a on jen doplní počty použitých jednotek (kusy,

hodiny, nebo

kilometry) Servisní knihy - slouží k podrobnějšímu dělení požadavků a zásahů. Stavy komponent - slouží k evidenci stavu komponenty, např. zda je instalována u zákazníka, ve skladu, nebo v opravě Druhy komponent - vycházejí z rozdělení ceníků dosud evidovaných v MS Excelu, kde byly na několika listech vždy sdruženy příbuzné položky. Druh komponenty v tom případě představuje jeden list (např. CCTV20) Typy revizí - pouze pomocné rozlišení, zda se jedná o roční nebo půlroční revizi.

20 CCTV - Closed-circuit television – uzavřené systémy pro kabelovou televizi, nějběžněji se používají pro monitorování důležitých oblastí

64

44.. T Teessttoovváánníí aa vvyyhhooddnnoocceenníí 4.1. Testování Po nasazení aplikace bylo hlavním úkolem otestovat, zda celý systém je dodán dle daných požadavků. Velká výhoda byla v tom, že v rámci obchodních aktivit se podařilo získat velmi významného klienta, kterého byly poskytovány všechny služby spojené se zabezpečením jeho objektů. Týkalo se to všech jeho poboček a kanceláří, kterých je po celé České republice několik desítek. Testování servisního modulu tedy mohlo probíhat na reálných datech, což bylo pro potřeby testování mnohem lepší. V průběhu testování se nevyskytly žádné problémy na úrovni aplikace. Všechny části servisního modulu pracovaly správně a vazby mezi jednotlivými komponentami byly navrženy správně. Výkon aplikace byl dostatečný, se servisním modulem se dá pracovat i na pomalém GPRS připojení. Rovněž byl otestován

nový způsob přihlášení do VPN prostřednictvím

hardwarového řešení od společnosti Fortigate21. Tento způsob přihlášení do VPN je využíván právě pro potřeby klientů a servisních organizací, kteří nemají možnost instalace VPN klienta do svého PC. K připojení k PS tedy stačí pouze internetový prohlížeč a otevřené porty pro SSL. Uživatel se nejprve přihlásí na Fortigate bránu a pokud jeho přihlášení proběhne korektně, je mu umožněno spustit PS, kde už může pracovat dle výše popsaných postupů. Změny, které byly při testování po dodavateli požadovány, byly pouze kosmetického charakteru. Týkaly se většinou drobných úprav ve formulářích, filtrech či seznamech. Servisní modul byl předán k ostrému provozu ke dni 30. 12. 2010. V současné době je provozován pro významného klienta a připravuje se spuštění datového rozhraní, které umožní některá data předávat do informačního systému klienta.

21 FORTIGATE - Fortigate appliance jsou primárním Fortinet produktem pro firewall a VPN. Tvoří jádro zabezpečení přístupu do internetu a celé zabezpečovací infrastruktury sítě. Více informací na http://www.fortigate.cz/fortigate-firewall-zabezpeceni-internetu-vpn/

65

4.2. Vyhodnocení Diplomová práce ,,Portál pro podporu servisních činností poskytovaných formou outsourcingu“ se zaměřuje především na konkrétní projekt, při jehož realizaci jsem mohl být. Práce přímo navazuje na moji bakalářskou práci ,,Internetové portálové systémy a jejich využití v praxi“, která se zabývala portálovými systémy a jejíž praktickou částí bylo popsat provozní portálový systém, který provozuje naše firma. Ve své diplomové práci jsem tedy neřešil detaily portálového systému, ty jsou k dispozici v již zmíněné bakalářské práci. Mám-li shrnout celý proces výběru, vývoje, testování a nasazení servisního modulu jako celek, musím říci, že rozhodnutí, postavit tento projekt na rozšíření stávajícího portálového systému, bylo správné. Využili jsme několikaletých zkušeností se stávajícím systémem, využili jsme praktických zkušeností dodavatele aplikace, který podobných systémů ve své historii dodal několik pro různé typy společností a získali jsme tak nástroj, který nám výrazně zjednodušil práci při zavádění nových služeb pro naše klienty. Výhodou pro nás je, že v průběhu vývoje a testování byl realizován kontrakt s významným klientem, který má několik desítek poboček a kterému poskytujeme plný outsourcing všech služeb spojených se zabezpečením jeho budov. V rámci těchto služeb pro klienta zajišťujeme rovněž školení BOZP a PO pro jeho zaměstnance, kterých je několik tisíc. Servisní modul tedy mohl být od samého počátku nasazen do ostrého provozu s reálnými daty. Školení pro uživatele z dodavatelských servisních firem proběhlo bez nejmenších problémů. Největší z nich, který byl dříve jedním z generálních dodavatelů již zmíněného významného klienta, po představení tohoto projektu projevil zájem o celý systém a uvažuje o jeho nasazení v jejich společnosti. Cíle projektu byly dosaženy a aplikace je úspěšné provozována.

66

4.3. Závěrečné shrnutí Jak bylo dříve uvedeno, můj podíl na vývoji nejenom celého portálového systému, který je od 1. 1. 2009 nasazen v ostrém provozu ale také na servisním modulu, mi umožnil vytvořit tuto diplomovou práci . Při návrhu a vývoji aplikace jsou využity veškeré zkušenosti a poznatky, které jsem v průběhu posledních deseti let získal při implementaci předchozích ne-portálových i portálových řešení. V diplomové práci je popsána celá funkcionalita servisního modulu. Můj přínos a podíl na vývoji systému vidím především v tom, že jsem velmi dobře znal celou problematiku stávajícího portálového řešení, dokázal jsem sestavit správný tým osob, který dokázal připravit a správně naformulovat zadání a jelikož jsem byl za projekt zodpovědný, dohlížel jsem na to, aby servisní modul naplnil všechna očekávání, která jsme před realizací projektu měli. Tímto jsem splnil veškeré stanovené cíle práce, které jsem uvedl v zadání. Samozřejmě, že jak portálový systém tak servisní modul je v permanentním vývoji, protože přicházejí požadavky na další funkcionalitu, tak jak přichází požadavky spojené s novými technologiemi a také s požadavky našich klientů. Pro naše klienty chceme nabízet jenom ta nejlepší řešení a tak musíme mít i naše podpůrné systémy na nejvyšší úrovni. Chceme být vždy o krok napřed před naší konkurencí a tím se od ní odlišovat. V dnešní době to ani jinak nejde.

67

LLiitteerraattuurraa [1] RYDVALOVÁ, Petra; RYDVAL, Jiří. Outsourcing ve firmě, 1.vyd., Praha: Computer Press, 2007, ISBN 978-80-251-1807-8 [2] BRUCKNER, Tomáš;VOŘÍŠEK, Jiří. Outsourcing informačních systémů, 1.vyd. Praha: EKOPRESS, 1998, ISBN 80-8691-07-6 [3] VOŘÍŠEK, Jiří. Strategické řízení informačního systému a systémová integrace. Praha: Management Press, 1999. 320 s. ISBN 80-85943-40-9 [4] HRBÁČ Michal. Internetové portálové aplikace a jejich využití v praxi, bakalářská práce 2009, Dokument je dostupný v knihovně BIVŠ Praha

68

S Seezznnaam m oobbrráázzkkůů Obrázek 1-schéma jednotlivých divizí .................................................................................................................. 17 Obrázek 2-schéma systému PS ............................................................................................................................. 18 Obrázek 3- schéma spolupráce s dalšími firmami................................................................................................. 19 Obrázek 6 - rozdíl designu aplikací....................................................................................................................... 25 Obrázek 7 - použití tlačítka Filtr ........................................................................................................................... 25 Obrázek 8 - schéma přechodu mezi formuláři ...................................................................................................... 26 Obrázek 9 - kontrola dat ve formuláři ................................................................................................................... 27 Obrázek 10 - - přihlašovací dialog PS ................................................................................................................... 28 Obrázek 11 - detail definice rolí............................................................................................................................ 29 Obrázek 12 - schéma hierarchie zakázek .............................................................................................................. 30 Obrázek 13 - definice přístupu pomocí zakázek ................................................................................................... 30 Obrázek 14 - definice přístupu pomocí nákladového střediska ............................................................................. 31 Obrázek 15 - Požadavky na servisní zásah ........................................................................................................... 38 Obrázek 16 – diagram modulu Servis zařízení ..................................................................................................... 39 Obrázek 17 - menu Servis zařízení ....................................................................................................................... 40 Obrázek 18 - Seznam servisovaných zařízení bez filtru ..................................................................................... 41 Obrázek 19 - Seznam servisovaných zařízení s rychlým filtrem pro BS .............................................................. 42 Obrázek 20 - formulář pro založení nového zařízení ............................................................................................ 42 Obrázek 21 - záložka komponenty ........................................................................................................................ 44 Obrázek 22 - formulář pro zadání ................................................................................................................... 44 Obrázek 23 - formulář pro zadání pravidelné činnosti .......................................................................................... 45 Obrázek 24 - záložka požadavky .......................................................................................................................... 46 Obrázek 25 - formulář pro zadání požadavku na servis ........................................................................................ 46 Obrázek 26 - seznam servisních zásahů ................................................................................................................ 47 Obrázek 27 - detail servisního zásahu – základ .................................................................................................... 47 Obrázek 28 - detail servisního zásahu – fakturace ................................................................................................ 48 Obrázek 29 - detail formuláře pro zadání inspekce ............................................................................................... 48 Obrázek 30 - seznam požadavků na servis ............................................................................................................ 49 Obrázek 31 - Požadavek na servis......................................................................................................................... 51 Obrázek 32 - Seznam servisních zásahů ............................................................................................................... 51 Obrázek 33 - nový záznam o servisním zásahu .................................................................................................... 52 Obrázek 34 - Detail servisního zásahu – základ.................................................................................................... 53 Obrázek 35 - detail servisního zásahu – fakturace ................................................................................................ 54 Obrázek 36 - detail servisního zásahu – komponenty ........................................................................................... 54 Obrázek 37 - detail servisního zásahu – položky .................................................................................................. 55 Obrázek 38 - detail servisního zásahu – Soubory ................................................................................................. 55 Obrázek 39 - okno pro výběr stavu servisního zásahu .......................................................................................... 55 Obrázek 40 - detail komponenty zařízení ............................................................................................................. 56 Obrázek 41 - seznam servisních položek .............................................................................................................. 57 Obrázek 42 - detail servisní položky ..................................................................................................................... 58 Obrázek 43 - servisní položka - karta nejčastěji používané .................................................................................. 59 Obrázek 44 - seznam bezpečnostních specialistů .................................................................................................. 59 Obrázek 45 - detail nastavení uživatele s vazbou na roli bezpečnostního specialisty .......................................... 60 Obrázek 46 - detail karty inspekce zařízení .......................................................................................................... 60 Obrázek 47 - detail instalace zařízení ................................................................................................................... 61 Obrázek 48 - detail verze instalace - záložka Položky ......................................................................................... 61 Obrázek 49 - Podklady pro FP .............................................................................................................................. 62 Obrázek 50 - seznam faktur od servisů ................................................................................................................. 63 Obrázek 51 - detail faktury od servisu .................................................................................................................. 63

69

Portál pro podporu servisních činností poskytovaných formou outsourcingu

Recommend Documents