Informační systém pro správu a provozování dopravního areálu

Kapitola je z knihy Správa dopravní infrastruktury v souvislostech, kterou vydala Vysoká škola logistiky o.p.s. Zdarma ke stažení na vslg.cz/aktuality/vysoka-skola-logistiky-vydala-knihu-sprava-dopravni-infrastruktury-v-souvislostech/.

Budování informačního systému pro podporu facility managementu je náročná a dlouhodobá činnost. V následujícím textu je na konkrétním příkladu demonstrována reorganizace pracovních postupů s využitím nového softwaru, jehož úkolem není pouhá evidence dat, ale též standardizace pracovních postupů a racionalizace práce v oblasti facility managementu. Současně je ukázáno nejen propojení mezi technickými a ekonomickými daty, ale zmiňována je též důležitost organizace práce a mezilidských vztahů. Případová studie vychází z aplikace softwaru v konkrétní firmě – autobusovém nádraží. [102]

Cíl 1: Poukázat na složitost věcných a finančních toků v podniku vlastnícím a spravujícím areál pro dopravu

Cílem této kapitoly je ukázat na případové studii komplexnost věcných a finančních toků v podniku vlastnícím a spravujícím areál pro dopravu.

Cíl 2: Analýza potřeb, tvorba a aplikace vnitropodnikového informačního systém pro vlastníka areálu pro dopravu

Cílem je analyzovat potřeby, představit tvorbu a aplikaci vnitropodnikového informačního systému pro vlastníka areálu pro dopravu.

Úvodní úvahy

Facility management. Pojem, který vstoupil do České republiky poměrně nedávno, a proto si jej člověk spojuje primárně s činnostmi, které souvisí s tradiční správou nemovitostí. V moderním pojetí je však facility management chápán jako systém integrovaného řízení podpůrných služeb ve společnostech. Definice vycházejí z terminologie ČSN EN 15221 Facility management, ISO 41 000 Facility management, ale také z různých publikací a článků a koneckonců i názorů odborníků v této oblasti. Tak, jak se vyvíjí facility management, tak se vyvíjejí i jeho definice. Takzvaná „3P definice“ říká, že facility management je metoda, jak v organizacích sladit pracovní prostředí, pracovníky a pracovní činnosti. Zahrnuje v sobě principy obchodní administrativy, architektury, humanitních a technických věd. „5P definice“ posouvá do středu pozornosti facility managementu „člověka“. Facility management má za cíl zajistit pro zaměstnance či uživatele budovy nebo návštěvníka takové pracovní nebo užitné prostředí, které bude vykazovat čtyři základní parametry (prostory, procesy, udržitelnost a ekonomickou efektivitu). [97]

Součástí facility managementu, a to často velmi podstatnou, je právě správa majetku movitého a nemovitostí. Nejde však jenom o prostý seznam činností a úkolů, které je potřeba zajistit k tomu, aby nemovitosti sloužily tak, jak se od nich očekává. Ve své podstatě jde o celý systém činností, z nichž konečný uživatel nemovitostí vidí jen malou část. Tu navíc často vnímá velmi zjednodušeně subjektivním pocitem – někdy dokonce jen hodnocením jsem spokojen / nejsem spokojen.

K tomu, aby mohl facility manager poskytovat kvalitní službu, potřebuje široké informace o majetku. Jde nejen o informace technické, ale také o ekonomiku ale, též o organizaci celého systému, jehož cílem je tzv. „mít věci v pořádku“ a umožnit co nejlepší služby v oblasti facility managementu.

Evidence majetku je komplikovaný proces charakterizovaný zejména tím, že jeho evidence musí nejen být vytvořená, ale také pravidelně revidovaná podle skutečného stavu. Majetek v evidenci musí být popsaný, musí mít své číslo, zapsanou pořizovací hodnotu, kdy byl pořízen a místo, kde se nachází. Efektivnost evidence majetku zvyšuje využití počítačových systémů. Facility manager by měl pravidelně sledovat a analyzovat stav majetku. [90]

Při správě a provozu budov jakožto i v komplexním procesu facility managementu je použití informačních a komunikačních technologií velmi široké a zahrnuje zejména tradiční výpočetní techniku a dále technologické prvky. Vedle klasických osobních počítačů se tak setkáváme s různými čidly a senzory monitorujícími provoz budov, s terminály a informačními panely, technickými prvky využívajícími systémy čárového kódu, audio a video prvky, specifickými technologiemi „inteligence budov“ a přirozeně komunikačními prvky zahrnujícími klasické telefonní technologie i moderní komunikační prvky. [116]

Cíle a vize nového informačního systému

Nový informační systém ke správě nemovitostí vznikal v průběhu několika let tzv. za pochodu a byl de facto reakcí na situaci, která do té doby ve firmě panovala. Dalo by se mluvit o „době excelové“. Postupně se však začala rozšiřovat struktura činností firmy a takový stav nebylo možné (ba ani požadované) nadále udržovat.

Hlavním cílem nového systému tedy bylo:

• sjednocení datové základny k nemovitostem,
• online přístup k informacím o nemovitostech pro zaměstnance společnosti,
• standardizace typických (zejména pravidelných) reportů,
• snížení pracnosti reportů,
• snížení závislosti zhotovení ekonomických reportů na možnostech účtárny,
• manažerské sledování zvolených technických (př. obsazenost místností) a ekonomických ukazatelů (plán vs. skutečnost).

Nově budovaný informační systém otevřel diskusi o dosud málo řešených tématech:

• formální vymezení odpovědnosti za jednotlivé části agendy k nemovitostem,
• racionalizace pracovních postupů společnosti a popis jejich formálního obsahu,
• vymezení jasných pravidel práce (a komunikace) mezi zaměstnanci,
• diverzifikace rizik souvisejících s evidencí dat o nemovitostech, tj. rozložení práce s evidencí dat mezi více zaměstnanců, alokace pracnosti směrem ke zdroji dat.

Snahou bylo vytvořit takový systém, který by co možná nejvíce odpovídal pojetí ve smyslu „ať data do systému zadává ten, kdo je má“ a „ať data využívá ten, kdo je potřebuje“. Snahou samozřejmě bylo motivovat uživatele systému k jeho plnění a využívání, což často vedlo tvůrce systému k tomu přístupu „prosím, plň do systému data, my ti za to zjednodušíme jiné tvé jiné povinnosti“. Úspory (hlavně časové) a pozitivní efekty nového řešení musely být zřejmé i běžným uživatelům systému, nezřídka lidem bez VŠ vzdělání. [104]

Fáze vývoje informačního systému

Záměrem vedení firmy bylo původně vlastně pouhé převedení excelové evidence (Budov, Inženýrských sítí, Smluv a Klientů) do moderního hávu. Brzy se však ukázalo, že je nutné nabízet lidem s přechodem na nový styl evidence vysokou přidanou hodnotu a záměry a přístup bylo třeba velmi brzy přehodnotit. Z původně plánované malé aplikace, která bude hotova „za 3 měsíce“, tak vznikl robustní systém, který se v konečném důsledku vytvářel několik let, což však nelze vnímat nikterak negativně, ba naopak. Je to vyjádření maximálního úsilí i úspěchu projektu, neboť IS NEMO se stal nedílnou součástí fungování společnosti.

Informační systém se vyvíjel zhruba v těchto fázích:

• Areály (vč. Objekty, Patra, Místnosti), Inženýrské sítě,
• Smlouvy a Objednávky, Klienti,
• Účetní (nákladová) střediska, Účetní doklady a Platby (zejm. bankovní transakce),
• Majetek, Revize,
• Výstupy, Reporty.

Průběžně a často, hlavně z důvodů lepší argumentace vůči uživatelům systému, vznikaly různé podpůrné funkce zahrnuté v části Administrace (výstupy – výpis z databáze, přístupová práva – pro lepší systematizaci pracovních procesů, kontrolní hlásiče – upozorňování na nesrovnalosti v datech, filtry bankovních transakcí – usnadňující práci atd.).

Následně se do systému přidělávaly původně neplánované moduly: Parking, Ubytovna a hostel, Úschovna zavazadel, Evidence příjezdů a odjezdů autobusů, Vozový park, WC a další.

Na úplném začátku celého informačního systému bylo logicky potřeba kromě cílů a vizí definovat několik axiomů, na kterých je celý systém postaven. Jelikož je základním stavebním prvkem systému „místnost“ (ať už nazvaná jako kancelář, reklamní panel či lavička), bylo potřeba začít zde a ujasnit si odpovědi na otázky:

• Je POZEMEK samostatný databázový prvek nebo pouze parametr OBJEKTU?
• Je PATRO samostatný databázový prvek nebo pouze parametr MÍSTNOSTI?
• Jsou ÚČETNÍ STŘEDISKA tvořena z jednotlivých OBJEKTŮ nebo z MÍSTNOSTÍ?

Z těchto a dalších otázek pak pramenily odpovědi ve smyslu:

• Jedno účetní středisko odpovídá právě jednomu objektu.
• K jedné místnosti může být v 1 den přiřazen pouze 1 měřák daného média – voda, elektřina, plyn, teplo (jinými slovy, danou místnost nelze databázově napojit na více měřáků).

Databázové objekty jako základ pro pasportizaci nemovitostí

Postupně tak vznikla struktura databázových objektů, které daly základ pro pasportizaci evidovaných nemovitostí v hierarchii: (POZEMEK) – AREÁL – OBJEKT – (PATRO) – MÍSTNOST, přičemž Pozemek jsme pojali jako parametr Objektu (Budovy) a Patro jako parametr Místnosti. Samozřejmě v jiných provozech či firmách by toto pojetí mohlo být zavádějící a nedostatečné.

Jelikož je informační systém relační databáze, kromě samotných vazeb mezi jednotlivými prvky (položkami) databáze jsou evidovány i různé údaje popisující tyto prvky. Například u místností jde o: název a číslo místnosti, plochu místnosti, druh místnosti, objekt (příp. středisko) a jeho patro, v němž se místnost nachází a platnost (existuje) od – do. U měřáků na inženýrských sítích zase: název měřáku, číslo měřáku, druh média, typ měřáku (opět nutná klasifikace), nadřazený měřák, platnost měřáku od – do, měření (vlastní, z faktury), napojené místnosti atd.

Jedním z požadavků vedení společnosti bylo on-line vyhodnocování obsazenosti kancelářských prostorů. Právě sledování pronájmů a správa obsazenosti budov patří k nejvíce aplikovaným službám facility managementu [91]. Bylo potřeba vytvořit klasifikaci evidovaných místností nazvanou „druh místnosti“, neboť bez zařazení místnosti do té či oné kategorie takové vyhodnocení nebylo možné. A jak se ukázalo, není z pohledu „druhu místnosti“ snad rozmanitějšího areálu, než je autobusové nádraží, které je plné různých ploch a zákoutí. Jakmile byly popsány nemovitosti (či zjednodušeně řečeno to, co lze pronajímat), přišla druhá fáze, tedy fáze připojování všeho, co s nimi souvisí. A potřeba klasifikace (místností, měřáků, smluv atd.) ještě zesílila.

Další kardinální otázkou byla evidence změn údajů v čase. Někdy je potřebné historii změn evidovat (změna velikosti místnosti v důsledku stavebních úprav), jindy ne (oprava špatně zadaných dat). Někdy je změna vyvolána vnějšími vlivy (změna názvu klienta), někdy vlastní činností podniku (stavební úpravy) a někdy interní potřebou uživatele databáze (přejmenování měřáku). Jaké změny mohou nastávat a které je pro zdárné fungování systému nutno zohlednit, jsme přicházeli postupně.

Toto poznání bylo drobnou zkouškou toho, zda se tvůrce programu bude schopný popasovat s náročnějšími moduly, resp. s moduly, jejichž plnění daty si vyžádalo koordinaci mnohem většího záběru činností, dat a samozřejmě uživatelů. A to i bez ohledu na platnou legislativu, která je zejména v oblasti účetních dokladů striktní.

Informační systém především jako podpora uživatelů, nejen managementu

Vznikaly tak stavové jevy, které bylo také potřeba nově definovat a naučit se s nimi pracovat. Jak z hlediska databáze, tak z pohledu organizace činností a pracovních postupů jednotlivých lidí, tak z pohledu databáze jako softwaru. Jedná se o fázi smlouvy (v návrhu, podepsána pouze správcem nemovitosti, podepsáno pouze klientem, realizována, ukončena, nerealizována), fázi objednávky (v očekávání, v oběhu, vyřízena), fázi dokladu (v očekávání, v oběhu, vyřízen) a dalších součástí systému.

Logicky se tak začaly množit různé funkce, které bylo potřeba uživatelům vytvořit, aby jejich práce se zadáváním dat nebyla hodnocena negativně. Ať už vedením společnosti (z důvodů utlumení řečí typu „oni furt zadávají data, ale pro manažerské řízení je to k ničemu“), tak i jimi samotnými („proč to zadávám, když mi je to k ničemu“). Ke každému modulu tak přibyly funkce: Vyhledávání, (základní) Výstupy a několik dalších funkcí, na nichž se dal jasně a rychle demonstrovat přínos nového informačního systému.

Vytvoření databáze zahrnující údaje o výše uvedených prvcích systému umožnilo poprvé v historii společnosti rozpočítávat přijaté faktury za spotřebu médií mimo složité excelové tabulky, což se v následujících letech ukázalo jako klíčové. Kromě personálních změn uvnitř společnosti totiž enormně vzrostl tlak na schopnost argumentovat, proč byla dotyčnému klientovi přefakturována právě taková spotřeba médií s důrazem na detail.

Vždy bylo nutné vytvořit nejen teoretický postup pracovních činností, ale vytvořit adekvátní softwarovou podporu a přesvědčit uživatele, že je navrhovaný postup efektivnější a lepší. O složitosti vývoje napovídá i obrázek výše, na kterém je zachycena provázanost modulů, o jejichž data se opírá algoritmus na rozpočítání přijaté faktury za spotřebu médií. K přesvědčování uživatelů často pomáhalo to, že jim byla nabídnuta určitá „protislužba“. Prakticky totiž současně docházelo k poznání, že nařizování shora nemá smysl, protože v takovém případě nemá dostatečnou motivaci zadávat data co nejlépe a pouze plní jakousi povinnost. Současně rostlo i poznání, že některé věci je potřeba ředitelsky „rozhodnout“, což platilo zejména v případě, kdy se muselo postoupit dál a tábory odpůrců a zastánců byly srovnatelné. V případě dat k médiím však hrál softwarové systematizaci do karet hlavně velký objem dat nutných ke zpracování, což bylo nad možnosti excelu a odděleně (nesynergicky) pracujících jednotlivců. Všichni tedy potřebu softwaru chápali a naštěstí táhli, jak se říká, za jeden provaz.

Člověk v centru pozornosti tvůrců systému pro facility management

Společně s rozšiřováním systému se začaly logicky vynořovat neustále častěji reakce na evidovaná data: Kdo to zadal? Kdo mohl změnit mnou zadaná data? Kdo to všechno vidí? Kdy to vidí? Zprvu čistě evidenčně pojatá databáze tedy začala získávat novou dimenzi, tj. začali jsme ji využívat pro organizaci práce. Zprvu odmítavý postoj některých uživatelů se ale brzy začal měnit pozitivním směrem, neboť se začaly krystalizovat odpovědi na otázky:

• Kde seženu ta data?
• Kdo je dává do systému?
• Kdy je dává do systému?

Postupně se tak díky budování softwaru začala přirozeně vytvářet schémata činností – work flow, které by se jinak tvořilo velmi složitě. Software navíc umožnil kontrolu zadávaných dat, což bylo v excelu prakticky nemožné.

Sestavování pracovních procesů, které bylo do jisté míry abstrahováním logických vazeb, tedy muselo přinést odpovědi na otázky:

• KDO zadává data? (konkrétní osoba, skupina osob, někdo ze skupiny osob)
• CO dotyčný zadává? (databázovou položku / parametry)
• KDY jsou data zadávána? (pravidelně, po nějaké události, na něčí vyzvání)
• JAK jsou data zadávána? (jednotlivě, hromadně (speciální funkce)
• CO dotyčný k zadání dat potřebuje? (zdroj dat)
• PROČ jsou data zadávána? (k čemu je evidence dat potřeba / na co mají tato data vliv)
• KDO jím zadaná data využívá? (kdo data sleduje / potřebuje, tj. komunikační kanály)

Na vedoucím projektu záleželo, aby zvolil vhodnou (a často velmi empatickou) komunikaci s uživateli v případě, že systém vykazoval nějaké nesrovnalosti v datech, příp. v jejich interpretaci. Vytváření systému a softwaru pro správu nemovitostí bylo sice obecně ředitelem společnosti podporováno, ale vedoucí projektu neměl vůči finálním uživatelům nadřazenou roli. Tento postup přinesl mnohé problémy při zavádění, neboť některé inovace přinesly odpor uživatelů, nicméně potřeba vyargumentovat finální řešení vždy vedla k optimálnímu řešení z pohledu všech účastníků procesu (zadavatelů, uživatelů, programátorů).

Systém, který v prvním roce fungování používalo maximálně cca 5 lidí, se postupně rozrostl o další moduly, zejména o modul Účetní doklady. Spuštění tohoto modulu byl moment, který rozšířil software do celého vedení firmy, neboť ekonomické reporty (pohledávky a závazky, výnosy a náklady na účetních střediscích atd.) se začaly z části vytvářet na základě dat v databázi. Teprve v tomto okamžiku se vedení firmy zbavilo velké míry závislosti na ekonomických datech ukládaných na lokálních počítačích. A teprve v tomto okamžiku začal být vyvíjený software vnímán jako určitý kontrolní nástroj pro lepší řízení prováděných činností. Samozřejmě je potřeba si uvědomit, že kontrola s sebou nese jak pozitivní, tak negativní emoce, čili i u této fáze to chtělo trpělivost a čas, než si vše sedlo. Z pohledu architekta systému bylo zajímavé sledovat i odlišný přístup k systému u lidí, kteří ho vyvíjeli či spoluvyvíjeli a těch, kteří k němu přišli už k jako nezpochybnitelné součásti řízení podniku.

Narůstající množství evidovaných dat, vzájemně provázaných modulů a vlastně skryté organizačně-pracovní vazby vedly následně k tomu, že bylo potřeba definovat přístupová práva uživatelů. V terminologii softwaru šlo tedy o zpřístupnění celých položek (Místnosti, Doklady atd.), pouze jejich částí (karty), konkrétních údajů (jen něco na kartě) příp. ke speciálním funkcím.

Kromě definice „k čemu má dotyčný přístup“ bylo potřeba stanovit, jaká úroveň přístupu k tomu bude (zákaz, čtení, zápis a zámek). Původní nastavení systému v duchu „ať mají právo jen na to, co potřebují ke své práci“ se s výměnou vedení firmy změnilo na přístup „ať vidí vše, kromě toho, co vidět nesmí“ (ať už z důvodů zákona o ochraně osobních údajů či obchodního tajemství společnosti).

Vraťme se ještě ke kontrole evidovaných dat. Představte si člověka, který pečlivě zadává „svá“ data a pak mu někdo říká, že to či ono je špatně nebo že to má být jinak. Proto zprvu prováděl kontrolu dat architekt systému. Zjištěné nesrovnalosti pomohly k úpravě pracovních procesů, zlepšení klasifikací a lepšímu pochopení vkládaných dat. Do určité míry teprve zpětně jsme spolu s programátory vytvářeli kontrolní mechanismy a automatická upozornění na datové nesrovnalosti (kontroly přímo při ukládání dat či souhrnné noční kontroly). A protože počet takto generovaných problémů rostl a nebylo v silách administrátora systému data v takovém rozsahu hlídat, začali jsme postupně – samozřejmě po vyčištění problémů – kousek po kousku – kontrolní činnost převádět na samotné zadavatele dat.

Vývoj týmu zpracovatelů systému a komunikace s uživateli

Postupně tak tvůrci systému přešli z pozice analytiků a programátorů, v další fázi organizátorů a kontrolorů, do pozice rádců a pomocníků. Konečně začal systém plnit svoji funkci naplno. Cílem zavádění systému přece bylo systematizovat, zjednodušit a pomáhat, nikoliv mentorovat a nutit. Ale jedno bez druhého nejde.

Co vlastně rozhodlo o úspěšnosti projektu, který do určité míry vznikal na základě potřeb uživatelů, a ne na základě direktivního z rozhodnutí vrcholového managementu? Kromě lidského přístupu ke všem zúčastněným (nad nikoho se nepovyšuj a před nikým se neponižuj) to byla i maximální snaha o systematizaci firmy, která se v průběhu vytváření systému změnila z malé servisní firmy o pár lidech do společnosti s 200 zaměstnanci.

K tomu však bylo potřeba průběžně vycházet vstříc požadavkům zejména těm nejsilnějším oddělením v organizaci, zejména pak účtárně, která snad v každém podniku vyžaduje určitý specifický přístup. I přes různě složitá období se to autorům podařilo a díky vzájemné spolupráci byla omezena mj. násobná evidence dokladů. Lze kontrolovat oběh účetních dokladů (všechny požadavky na vystavení faktury jdou výhradně přes nový software), podávat online přehled o pohledávkách a závazcích a podařilo se nám zautomatizovat mnoho činností (generování splátkových kalendářů, párování úhrad, kontrolní hlášení, formalizované sestavy, kontrolní funkce a hlásiče atd.) a vytvořit synergický systém, jehož cílem je z pohledu účtárny jediné – mít v pořádku účetnictví a klid od finančního úřadu.

Účtárna. Jedno důležité oddělení firmy. Vedení. Druhé důležité vedení firmy. Dva útvary, dva různé pohledy na tatáž data. Na řadu přišlo poznání, že je rozdíl mezi pohledem účetní a pohledem manažera. Zatímco první se dívá spíš zpětně (co bylo) a hlídá si většinou spíš detaily a termíny daňových přiznání, pohled manažerů zajímá i výhled do budoucnosti a často potřebuje i data agregovaná, navíc mnohdy v jiném členění, než jaké poskytuje účetní osnova a zákon o účetnictví. V této fázi se začala projevovat kvalita naší práce nepřímo, neboť manažerský pohled se často opíral o členění položek podle námi definovaných klasifikací a fází.

Poznatky z aplikace systému

Odhadovat strukturu, obsah, pravidelnost, důležitost a množství reportů bylo velmi těžké, neboť vzhledem k původně (v době navrhování systému) velmi roztříštěnému množství informací a pracnému způsobu evidence bylo velmi těžké definovat cíl. Do určité míry tedy kladně zapůsobila skutečnost, že všichni tvůrci systému měli kladný vztah k číslům a statistikám a byli schopní si s dostatečným předstihem (a neskromně podotýkám i díky kvalitnímu vysokoškolskému vzdělání) představit, jaké reporty, výstupy a sestavy budou vedení společnosti zajímat. Pro úplnost snad jen dodejme, že reporty (tabulky a grafy) vznikaly postupně, a to v několika skupinách:

• technické (př. počet a plocha pronajímaných místností apod.),
• ekonomické (př. počet účetních dokladů, náklady, pohledávky apod.),
• organizační a procesní (počet zaměstnanců, počet úkolů apod.).

Budování FM systému ve společnosti mělo mnoho úskalí, nicméně se vše podařilo i díky lidsky vstřícnému postoji klíčových osob. Zprvu zamítavý postoj účtárny (a dalších systematizovaných oddělení) vůči „novému kontrolnímu“ systému vedl díky mnoha účelově a věcně dojednaným kompromisům k vytvoření efektivního systému, díky kterému je možné hledat řešení vzniklých problémů a situací. Architekt systému byl postaven do složité situace, kdy měl sice podporu ředitele a nadřízenou roli vůči programátorům softwaru, nicméně neměl přímé pravomoci a nadřazenost vůči konečným uživatelům systému. Určitou roli sehrál i fakt, že se člověk na poli FM pohyboval krátce, a tudíž byl člověk nezkušený. Na jednu stranu velká nevýhoda však dotyčného nutila klást zvídavé otázky, které v konečném řešení vedly k vytvoření unikátního systému, který zohlednil různé anomálie provozu nemovitostí ve velmi specifickém areálu.