Dnes se chci ve svém článku zabývat způsoby, jak CAFM systémy podporují průběh řešení procesů facility management služeb (FM), které pokrývají jako jednu ze svých klíčových systémových částí. Jde o klíčovou funkci jakéhokoliv procesního SW řešení. A vzhledem k tomu, že CAFM systémy představují SW podporu FM služeb, je takové systémové pokrytí nezbytnou součástí každého CAFM systému.
V praxi se tak průběh procesu, zkráceně workflow (WF), používá zejména pro:
- Oběh dokumentace, kdy workflow určuje jasný postup od „koho“ „komu“ má být dokumentace dle jejího charakteru nebo typu předána a případně i validována
- Schvalování, kdy workflow určuje kolik osob a kterých osob dle role či pozice, typu dokumentu či objemu finančních prostředků apod., má dokument schválit, resp. vyjádřit souhlas s příslušným typem dokumentu. V praxi tak může jít o schválení vydané objednávky, tj. schválení nákupu služeb nebo zboží, schválení cenové nabídky, schválení převodu majetku atd., atd.
- Průběh vyřešení požadavku, kdy workflow určuje způsob předávání vyřešení nějakého problému nebo požadavku od zadavatele k řešiteli (řešitelům) zpět k validaci zadavatelem a případně následnými úkony fakturace, optimalizace procesu apod.
V praxi facility managementu a využití CAFM systému se můžeme setkávat se všemi třemi typy workflow, primárně a nejčastěji však se způsobem třetím, který je vlastní zejména Helpdeskové funkci CAFM systému a tomu se chci v následujícím textu věnovat především.
Řešit workflow procesy u poskytovatele FM služeb nebo u konečného uživatele?
Principiálně je jedno, jestli se zabýváme workflow procesů u poskytovatele FM služeb nebo u konečného uživatele. V obecné rovině jde stále o jedno a totéž, jen funkci řešitele požadavku nezajišťuje externí poskytovatel FM služeb, ale interní útvar, odpovědný za realizaci FM služeb, zejména pak za správu a provoz nemovitostí, které jsou primárními FM službami v jakémkoliv segmentu trhu, organizacích či institucích státní správy a samosprávy.
Jde však o klíčovou funkci, jež klade vysoké nároky na její pochopení pro všechny zúčastněné role, které se na procesu podílí. Představíme-li si tedy, že žadatelem o jakýkoliv proces správy a provozu budovy může být jakýkoliv uživatel, pak to tedy znamená, že znalost příslušného workflow by měla být vlastní každému z nás. SW nástroje však umí významně jakýkoliv proces standardizovat, a právě pro běžného žadatele, rozuměj zadavatele vstupního požadavku, zjednodušit a omezit do takové úrovně, že tento nepotřebuje workflow znát, neboť pro něj jsou běžnými stavy Založeno – Vyřešeno bez jakékoliv jeho další účasti na procesu. S takovýmto workflow se každý z nás setkává denně např. při jakémkoliv internetovém nákupu, kde vstupní workflow pro stav Založeno představuje výběr zboží nebo služby a její sumarizaci v nákupním košíku a dále pak úkon definice dopravy a způsobu zaplacení a v případě okamžité platby pomocí platební karty i proces úhrady za vybrané.
Jakými dalšími stavy workflow se nákupní proces řídí, již jako nakupující nepotřebujeme znát, nicméně notifikace, kterými nás prodávající nebo následně dopravce zboží, častuje v naší e-mailové schránce napovídá, kdo a jakými stavy našeho nákupu se zabývá. Stav Vyřešeno je pak pro nás faktické převzetí zboží či užití služby a více se tímto procesem nezabýváme. Že však pro druhé tento proces neskončil napovídají další e-maily se žádostí o hodnocení nákup či užití služby, mnohdy s celou řadou konkrétních dotazů. Podobně jsme součástí workflow při zadání platby ze svého internetového bankovnictví, kde stavem Založeno je vyplnění platebního formuláře a stavem Vyřešeno výdajový pohyb na bankovním účtu. Jaké další stavy a úkony jsou prováděny mimo nás už nevíme a v zásadě nás ani nezajímají.
Podobně je tomu při definici workflow, když určujeme průběh vyřízení požadavku jakéhokoliv uživatele budovy, jehož trápí rozbitá židle, nefunkční žaluzie, horko nebo zima a další a další potřeby, které jsou nezbytné k výkonu jeho práce. I tohoto uživatele zajímají především stavy Založeno, jejímž jsou autorem a stavy Vyřešeno, kdy je nezbytné opraveno, nezbytné dodáno a uživatel toto přebírá fakticky nebo i pomocí CAFM systému. V uvedených případech již WF někdo vydefinoval a nastavil a jako žadatel máme pramalou možnost jej ovlivnit či navrhovat. Jsme jen součástí procesu.
Uživatelsky definovaná workflow
CAFM systémy ve snaze poskytnout plný komfort nejen zadavatelům, ale zejména řešitelům, poskytují uživatelsky definovaná workflow, která znamenají, že jako osoba odpovědná za řešení konkrétních situací a činností, si takové WF můžete definovat v návaznosti na vybraný druh činnosti a své vlastní potřeby a standardy své organizace či instituce. A díky pestré konfigurační možnosti svého CAFM systému ho takto nastavit, resp. nechat nastavit (to záleží na vaší funkci roli v CAFM systému.
Je jasné, že různé činnosti a různé FM služby jsou také různě vyřizovány a přesně takto různé, může být workflow, které si pro tu kterou činnost vymyslíte. V dobrém CAFM systému nejsme jejich množstvím nijak limitováni. Jejich správná definice však předpokládá:
- Vaši dokonalou znalost celého procesu té které činnosti ve vaší organizaci (zkrátka „jak to chodí“ nebo jak by to „chodit mělo…“)
- Vaši dokonalou znalost prostředí vaší organizace či instituce (znalost organizační struktury, středisek a útvarů a jejich kompetencí…)
- Vaše kompetence nebo znalosti kompetence finančních rámců dalších rolí (co můžete vy nebo někdo ve vaší organizaci v jaké cenové hladině…)
- Vaši znalost CAFM systému, který užíváte a jeho možností (co všechno od jaké úrovně si můžete diktovat do úrovně., která je „natvrdo“ naprogramovaná…)
Znalost CAFM systému
Zejména poslední část je tedy velmi významná pro každého manažera na jakékoliv úrovni řízení, neboť bez této znalosti nikdy nebude dosaženo efektivního užívání CAFM systému. Svou nezastupitelnou roli samozřejmě hrají kompetence a dovednosti administrátorů CAFM systému, a to nejen v oblasti SW, ale zejména v oblasti procesní. Pochopit nastavený proces, pochopit jednotlivé stavy WF, pochopit role, které do procesu vstupují a zejména pak úkony a činnosti, které představují přechody z jednoho stavu procesu do stavu dalšího je předpokladem i jejich dobré práce.
Ve své lektorské praxi a výuce SW podpory Facility managementu v různých kurzech a na vysokých školách se zabývám i cvičeními na toto téma (je-li pro to časový prostor). Pouhé vysvětlení celé problematiky nestačí, a tak potřeba praxe a vlastního vyzkoušení si nastavení toho nejlepšího a nejefektivnějšího WF v rámci cvičení je jasnou ukázkou složitosti a širokého záběru tohoto tématu. To se samozřejmě týká i mých nových kolegů nejen v týmu CAFM, ale i provozních či facility manažerů, jež jsou trvalou součástí takřka každé konfigurace WF pro vybraný proces.
S nejjednoduššími procesy se tak lze setkat u opakovaných činností (revize, pravidelné úklidy, preventivní činnosti a další opakující se úkony…) a s nejsložitějšími pak v těch procesech, do kterých je zapojeno několik osob či zúčastněných středisek či subjektů. Zde je vyžadován rychlý průběh a co nejrychlejší vyřízení jakéhokoliv požadavku. Onen požadavek, zejména pak řešení operativních požadavků a Helpdesků, však může obsahovat atributy, které mohou dělat WF složitějším a tzv. jej větvit. To může být případ cenových nabídek, může to být případ interní komunikace před předáním na řešitele nebo složitost schvalování realizace v návaznosti na další úkony fakturace a schválení fakturačních podkladů, může to být případ reklamací a zpětné předání na řešitele požadavku atd., atd. Stavy procesu Založeno a Vyřešeno tak mohou být doplněny o celou řadu dalších stavů a vzájemných přechodů mezi stavy, které mohou znamenat navýšení o jednotky až desítky stavů či přechodů.
Běžným takovým případem jsou již citované cenové nabídky a jejich variabilita. Běžnými stavy je CN schválena či CN neschválena. V prvním případě běží proces dále k řešiteli, ale co se stavem neschválené CN? Co tento stav v procesu znamená? Definice je na uživateli, resp. příslušném manažeru a v takovýchto případech se jasně a hned projeví dovednosti, které v této oblasti nelze nabýt jinak, než jedním z výše uvedených kompetenčních bodů. A v tomto větvení WF lze pokračovat třetím stavem, např. Odloženo, který znamená, že CN sice není schválena k realizaci, ale není také neschválena a zadavatel stavu Odloženo má prostě nějaký čas na posouzení CN, zajištění prostředků nebo jen prostě potřebuje realizaci, rozuměj i fakturaci, posunout na další rozpočtové období apod. Potom k citovanému dotazu ke stavu CN neschválena přísluší dotaz: „co dál se stavem Odloženo“? Ano, primárně stav Odloženo provážeme s předchozími dvěma a buď CN schválíme nebo ne. A pokud CN neschvalujeme – co toto neschválení znamená? Že je proces u konce? Nebo chceme jen upřesnění či další alternativu předkladatele či něco dalšího po zpracovateli cenové nabídky?
Obdobných dotazů a dalšího směřování se dočkáme u každého schvalovacího procesu, kdy některá z rolí procesu má to či ono validovat nebo naopak. Procesy tím často vracíme zpět a je třeba dobré znalosti interních procesů, aby toto vrácení bylo směřováno do takového stavu, se kterým si jeho držitel (ten, komu je takový stav určen) bude vědět rady. Za držitele stavů lze tedy považovat každého, jemuž je ten či onen úkon právě tímto stavem svěřen. Další složitosti se dočkáme, je-li těchto osob více a není jím pouze jedna osoba. Pak je vhodné doplnit do WF představ, který je určen dispečerské roli, která rozhodne o řešiteli dalšího stavu a směřuje tedy požadavek k tomu pravému.
Zrychlení celého procesu pomocí správných SW
Jedním z významných efektů, kterých lze správnou volbou celého WF pomocí SW nástroje docílit, je zrychlení celého procesu, neboť „je-li na mě a požadavky k mému vyřízení vidět“, mám přirozenou snahu tento svůj úkon vyřešit co nejrychleji a předat požadavek do dalšího úkonu – do dalšího stavu WF, tedy „zbavit se jej“. Je proto přirozené, že nezbytnou součástí každého workflow – a známe to sami z příkladů, uvedených v úvodu tohoto článku – jsou notifikace. Kdysi užívané notifikace pomocí SMS zpráv nahradily e-mailové notifikace, zahrnující neomezený textový prostor pro všechny detaily požadavku, a především potenciál příloh, ať už fotografií nebo cenových nabídek, předávacích protokolů, pracovních listů, nákupních dokladů, podkladů fakturace až k vlastní faktuře, jejíž odeslání jako finalizace procesu může být – a v práci často bývá – běžnou součástí navrženého WF. Chytré mobily tak jsou dnes součástí vybavení nejen manažerských pozic, ale i pozic výkonných pracovníků v terénu.
V neposlední řadě je v souvislostí s workflow procesů třeba zmínit KPI indikátory. Právě konkrétní stavy a samozřejmě datum a čas jejich nastavení tou kterou rolí v procesu, pomáhají k přesné identifikaci splnění či nesplnění sjednaného indikátoru a jejich prezentace v SW nástroji. Díky tomu se není třeba dohadovat, zda bylo či nebylo provedeno, systém svým algoritmem – odečtu jednoho data a času od jiného – toto jasně určuje a deklaruje všem zúčastněným. A zde se může ukrývat další záludnost v lidském zdroji, který je nedílnou součástí všech těchto procesů. Tím je soulad CAFM systému s praxí realizované FM služby. Často se stává – a dobrým nastavením WF by se stát nemělo – že je práce či požadovaný úkon realizován, ale v CAFM systému nikdo tuto realizaci nenastavil, nikdo nevalidoval provedení. Způsobů řešení je zde několik, ale tyto již vydají na celý další článek, který se zabývá lidskými zdroji, jejich spolehlivostí a také nastavením motivačních prvků, neboť nic nás k něčemu, do čeho se nám nechce nemotivuje víc, než „odměna“ na konci procesu… ale to až zase někdy příště…
Z uvedeného jasně vyplývá, že právě workflow a jeho využití v CAFM systémech je nezbytným předpokladem plnění řídících cílů nasazení tohoto SW nástroje a také efektivním nástrojem díky využití jeho automatizačních funkcí.
Jan Talášek, CAFM konzultant a lektor
Hledáte specialisty v oblasti facility služeb?
Jsme předním hráčem na trhu Facility managementu. Ozvěte se nám a získejte nezavázanou nabídku.
