Systém řízení zakázek v servisní firmě

Systém řízení zakázek je jedno místo, kde zakázka vzniká, mění stav a končí. Nejde v prvé řadě o software, ale o pravidlo: každá zakázka má právě jeden záznam, jednoho odpovědného člověka a stav, který odpovídá skutečnosti. Software to pravidlo jen vynucuje. Bez něj se řízení rozpadne na e-maily, poznámky a paměť jednoho člověka.

• Jeden záznam na jednu zakázku. Druhý záznam znamená, že se dva lidé rozejdou v tom, co platí.
• Stav zakázky má říkat, kdo dělá další krok. Stav, ze kterého to nepoznáte, je zbytečný.
• Odpovědnost patří jménu, ne oddělení. Zakázka bez odpovědného člověka čeká nejdéle.
• Zakázka vzniká v okamžiku hlášení, ne až při plánování.
• Uzavírá ten, kdo za ni odpovídá, a až když nechybí výkaz, materiál ani podpis.

Co musí systém řízení zakázek zvládnout

Čtyři věci, a více jich na začátku není potřeba. Zaprvé přijmout zakázku odkudkoli, tedy z telefonu, e-mailu i od technika z terénu, a udělat z ní jeden záznam. Zadruhé přiřadit odpovědného člověka. Zatřetí ukázat stav tak, aby bylo zřejmé, kdo má udělat další krok. Začtvrté uchovat, co se u zakázky stalo a kdo to zapsal.

Vše ostatní, tedy fakturace, sklad, ceníky a schvalování, je nadstavba. Firmy, které začínají od nadstavby, obvykle skončí u dlouhého zavedení a základ zůstane nedořešený.

Test, jestli základ funguje, je jednoduchý. Vezměte zakázku starou tři měsíce a zjistěte, kdo u zákazníka byl, co vyměnil a proč se termín dvakrát posunul. Jestliže to trvá déle než několik minut, systém řízení zakázek zatím nemáte, i kdyby byl nainstalovaný.

Stavy, které stačí

Stav není popis nálady zakázky, ale informace o tom, kdo je na tahu. Následující sada pokrývá běžný servisní provoz a dá se zúžit nebo rozšířit podle oboru.

Dva stavy z tabulky se v praxi nejčastěji vynechávají a právě ony drží nejvíce zakázek: čekání na zákazníka a čekání na materiál. Bez nich se obojí jeví jako běžící práce a nikdo nesleduje, jak dlouho už se čeká.

Odpovědnost patří jménu

Zakázka přiřazená oddělení nemá odpovědného. Zakázka přiřazená jménu ho má, a to i tehdy, když na ní pracuje více lidí. Odpovědný člověk nedělá práci, ale hlídá, že se zakázka hýbe.

Nejčastější chyba je ztotožnit odpovědnost s technikem. Technik odpovídá za provedení zásahu, nikoli za to, že zákazník nedodal přístup nebo že se čeká na díl. Jakmile se tyto dvě role smísí, zakázka zamrzne ve chvíli, kdy technik odjede na jinou práci.

Praktické pravidlo: každý den je někdo schopen odpovědět na otázku, co brání uzavření kterékoli otevřené zakázky. Pokud takový člověk není, odpovědnost není přiřazená, jen se to tak tváří.

Odkud se zakázky sbírají

Ze čtyř zdrojů: telefon, e-mail, hlášení technika z terénu a plán pravidelných prohlídek. Každý z nich má vlastní past.

Telefon svádí k odloženému zápisu, protože příjemce hovoru je obvykle zaneprázdněný. E-mail svádí k tomu, že zůstane e-mailem a zakázka z něj nikdy nevznikne. Hlášení technika se často řeší na místě a do systému se nedostane vůbec. Pravidelné prohlídky se plánují jednou ročně a mezitím se na ně zapomene.

Společné řešení je jediné a nepříjemné: zakázka vzniká v okamžiku hlášení, ne až když se plánuje. I zakázka bez termínu a bez podrobností je lepší než čtyři dny stará zpráva v cizí schránce.

Zakázky a historie drží u jedné zakázky výkazy techniků, interní poznámky, přílohy i záznam každé změny, takže se dohledávání nedělá v e-mailech. Praktický dopad je vidět při reklamaci, kdy je nutné doložit, co se u zákazníka provedlo a kdy.

Postup zavedení bez velkého projektu

1. Vypište stavy, které skutečně používáte, i kdyby byly zatím jen v hlavě. Teprve pak je zkraťte na čtyři až šest.
2. Ke každému stavu určete, kdo je na tahu. Stav, u kterého to nedokážete říct, škrtněte.
3. Určete u každé otevřené zakázky odpovědného člověka jménem.
4. Přeneste do systému jen otevřené zakázky. Historie se dopisovat nemusí, uzavřené zakázky nikdo neřídí.
5. Domluvte pravidlo o vzniku zakázky při hlášení a týden ho sledujte.
6. Po týdnu projděte, které stavy nikdo nepoužil, a zrušte je.

Šestý krok se vynechává nejčastěji a je přitom nejlevnější. Nepoužívané stavy nezůstávají neškodné, protože ostatní přestanou stavům věřit.

Řízení zakázek a plán jsou dvě různé věci

Zakázka říká, co se má udělat a v jakém je to stavu. Plán říká, kdo to udělá a kdy. Firmy je často slučují do jednoho seznamu a potom se diví, že jim ze seznamu nejde vyčíst ani jedno.

V plánovací tabuli jsou technici v řádcích a dny ve sloupcích, takže nasazení vzniká tažením přes buňky a kolize se ohlásí při zápisu. Zakázka zůstává tam, kde patří, a v plánu je vidět jen její nasazení.

Rozdíl se projeví ve chvíli, kdy se zakázka nestihne. V seznamu zmizí, protože je „po termínu“. V dělené podobě zůstane otevřená ve svém stavu a v plánu se jen přesune na jiný den.

Aby stav odpovídal skutečnosti

Systém řízení zakázek stojí a padá s tím, jestli se stavy přepínají včas. Přepisování z papíru večer v kanceláři to nezajistí, protože se dělá po směně a s odstupem.

Mobil pro techniky běží v prohlížeči, technik v něm otevře svůj den, zahájí práci a při ukončení vykáže provedené úkony i poznámku pro kancelář. Stav se tak mění v okamžiku, kdy se událost stala, a kancelář nemusí volat s dotazem, jak to dopadlo.

Ve firmách, kde se zásahy hlásí až zpětně, bývá rozdíl mezi stavem v systému a skutečností jeden až dva dny. To je právě ta doba, po kterou se zákazníkovi nedá odpovědět na dotaz, v jaké fázi jeho zakázka je.

Kdy to řešit nemusíte

Dokud běží jedna nebo dvě zakázky současně a plánuje je jeden člověk, sešit funguje a nový nástroj přinese více práce než užitku. Totéž platí pro firmy, které neplánují lidi v čase.

Zlom nastává tehdy, když se začne stávat, že dva lidé mění tutéž zakázku a jeden o tom neví, nebo když se zákazníkovi nedá odpovědět bez obvolávání techniků. Od té chvíle nejde o pořádek pro pořádek, ale o to, aby odpověď existovala dříve, než ji někdo bude potřebovat.

Časté dotazy