Firma nemusí při každém provozním problému potřebovat nový systém. Někdy stačí lépe nastavit hotový nástroj, jindy propojit data, která už existují, a teprve u specifického procesu dává smysl vlastní vývoj. Nejtěžší není vybrat technologii. Nejtěžší je poznat, jak velké řešení problém skutečně vyžaduje.
Příliš malé řešení nechá tým u ručního přepisování a obcházek. Příliš velké přidá náklady, složitost a funkce, které nikdo nepotřebuje. Rozumné rozhodnutí proto nezačíná otázkou „který software koupit“, ale popisem práce, která se dnes zdržuje, ztrácí nebo nedá spolehlivě převzít.
Nejdřív problém, potom způsob řešení
Věta „potřebujeme ERP“ ještě neříká, co se má změnit. Může za ní být chybějící přehled o rozpočtu, ztracené fotografie ze zakázky, dvojí přepisování faktur nebo termíny uložené pouze v kalendáři jednoho člověka. Každá z těchto situací může potřebovat jiný zásah.
Než vznikne zadání, musí být jasné alespoň toto:
který pracovní tok se řeší a kde začíná a končí,
kdo do něj zadává data a kdo podle nich rozhoduje,
ve kterém kroku dnes vzniká chyba, čekání nebo přepisování,
co musí být po změně rychlejší, spolehlivější nebo dohledatelné,
které části současného postupu fungují a nemají se zbytečně měnit.
Podrobný postup nabízí článek o tom, jak zmapovat firemní proces před digitalizací. Výsledkem nemá být dlouhý diagram pro prezentaci. Stačí společně pochopený tok, konkrétní slabé místo a rozhodnutí, které má technologie podpořit.
Tři cesty jsou rozhodovací rámec, ne povinná metodika
Metric na veřejné stránce služby popisuje spolupráci od analýzy procesů přes návrh řešení k nasazení a zaškolení. Rozdělení na hotový systém, propojení a vlastní vývoj je v tomto článku praktický rámec pro jednu část návrhu. Není to tvrzení, že každý projekt prochází stejnými třemi kroky nebo že firma musí nakonec využít konkrétní produkt.
Jednotlivé cesty se navíc mohou kombinovat. Hotové CRM může pokrýt poptávky, existující účetní program zůstane beze změny a mezi nimi vznikne pouze bezpečné předání potřebných údajů. Vlastní vývoj se pak může omezit na jeden specifický formulář pro techniky, nikoli na náhradu všech systémů.
1. Nastavit hotový systém
Hotové řešení dává smysl tam, kde je proces běžný a firma nepotřebuje být výjimečná právě způsobem jeho evidence. Kontakty, obchodní stavy, úkoly, dokumenty nebo přehled zakázek mají podobný základ napříč mnoha firmami. Výhodou bývá rychlejší start, známý rozsah a menší množství rozhodnutí, která je potřeba udělat před prvním použitím.
Podmínkou je ochota sjednotit názvy, odpovědnosti a některé pracovní návyky. Pokud se každá výjimka okamžitě řeší novým polem nebo zvláštní obrazovkou, hotový systém se začne měnit v drahý vlastní vývoj bez jasného návrhu.
2. Propojit nástroje, které už fungují
Propojení je vhodné, když jednotlivé nástroje svou práci zvládají, ale mezi nimi se informace přepisují ručně nebo vůbec. Poptávka například vznikne ve webovém formuláři, nabídka se připraví jinde a potvrzená zakázka se znovu založí do provozní evidence.
Integrace sama o sobě špatný proces neopraví. Pokud není jasné, který systém je zdrojem platného údaje, automatizace pouze zrychlí šíření nejasnosti. Před propojením je proto potřeba určit:
která data se předávají a která zůstávají pouze ve zdrojovém systému,
kdy se přenos spouští a co se stane při chybě,
jak se pozná duplicitní nebo neúplný záznam,
kdo může propojení změnit a kdo sleduje jeho provoz,
zda současné nástroje nabízejí stabilní a bezpečný způsob výměny dat.
Někdy stačí řízený export a import. Jindy má hodnotu automatické předání přes rozhraní. Konkrétní možnost ale vždy závisí na skutečných nástrojích, jejich oprávněních, dokumentaci a podmínkách poskytovatelů. Nelze ji slíbit jen podle názvu programu.
3. Vyvinout vlastní část nebo systém
Vlastní vývoj dává smysl tehdy, když proces vytváří pro firmu podstatnou provozní hodnotu a hotové řešení by vyžadovalo trvalé obcházení. Může jít o specifický způsob výjezdu, schvalování technického zásahu, práci s objekty nebo předávání podkladů mezi terénem a kanceláří.
Argumentem pro vývoj není pouze věta „pracujeme jinak“. Rozdíl musí být popsatelný: co standardní postup neumí, kolikrát se výjimka opakuje, kdo kvůli ní čeká a jaké riziko vzniká. Vlastní řešení zároveň přináší odpovědnost za další rozvoj, testování, provoz, oprávnění a změny navazujících služeb.
Často proto není potřeba stavět celý systém od začátku. Přiměřenější může být vlastní modul nad společnými daty nebo omezená aplikace pro jeden kritický krok. Přizpůsobení systému procesu a kompletní software vyvinutý na zakázku nejsou totéž.
Rozhodovací tabulka: co porovnat před investicí
Následující tabulka není bodovací algoritmus. Pomáhá odhalit, které otázky ještě nemají odpověď a kde by rychlé technologické rozhodnutí stálo na předpokladech.
| Otázka | Spíš hotový systém | Spíš propojení | Spíš vlastní řešení |
|---|---|---|---|
| Je proces běžný napříč firmami? | Ano, rozdíly jsou hlavně v názvech a odpovědnostech | Jednotlivé části jsou běžné, ale oddělené | Klíčový krok má stabilní a podstatná specifika |
| Co dnes funguje? | Proces lze převést do jednoho nástroje | Nástroje fungují, selhává předávání dat | Chybí podpora rozhodující části práce |
| Kolik výjimek vzniká? | Málo a lze je řešit pravidlem | Výjimky vznikají hlavně na rozhraní systémů | Výjimky jsou opakované a tvoří samotné jádro procesu |
| Jak často se proces mění? | Stabilní základ, který se dá konfigurovat | Stabilní datové předání mezi známými nástroji | Pravidla jsou známá a firma dokáže řídit jejich další změny |
| Jaké je hlavní riziko? | Příliš mnoho funkcí a slabé přijetí týmem | Nejasný zdroj pravdy a neviditelné chyby přenosu | Růst rozsahu, závislosti a nákladů na údržbu |
Rozhodnutí ovlivní také dostupnost dat, přístupová práva, očekávaný počet rolí, technické možnosti dodavatelů a schopnost firmy udržet jednoznačná provozní pravidla. Tyto podmínky nelze spolehlivě odhadnout bez znalosti konkrétního prostředí.
Modelový příklad: servisní firma přepisuje zakázku třikrát
Následující situace je smyšlený modelový příklad, nikoli reference ani výsledek klienta Metricu.
Menší servisní firma přijímá požadavky e-mailem a telefonem. Administrativa je zapisuje do sdílené tabulky, vedoucí připravuje termíny v kalendáři a technik po výjezdu vyplňuje samostatný dokument. Fakturační podklady pak někdo znovu přepisuje do účetního programu. Majitel původně uvažuje o vývoji nové aplikace pro celý provoz.
Po rozdělení problému se ukážou tři odlišné potřeby:
Přijetí a přiřazení požadavku je běžný tok. Lze nejdřív ověřit, zda jej pokryje hotová evidence se stavem, vlastníkem a dalším krokem.
Předání potvrzeného výjezdu může vyžadovat pouze jednoznačná data a propojení s plánováním, pokud používané nástroje bezpečný přenos umožní.
Záznam technika v terénu má specifickou strukturu podle typu zařízení. Tady může mít hodnotu vlastní formulář nebo modul, ale až po sjednocení povinných údajů a navazujícího rozhodnutí.
Výsledkem není jeden vítěz pro celou firmu. Je jím menší a ověřitelný rozsah: hotový základ tam, kde proces není unikátní, propojení tam, kde zaniká přepisováním, a vlastní část pouze pro stabilní specifikum.
Pilot má ověřit pracovní tok, ne jen obrazovku
Ukázka systému může působit přesvědčivě, ale neověří předání odpovědnosti ani kvalitu vstupních dat. Pilot má projít skutečný pracovní tok od vzniku případu po výsledek, který potřebuje další role. U servisního požadavku to může znamenat přijetí, přiřazení, naplánování, výjezd, záznam práce a předání podkladů.
Před pilotem se určí:
který typ případu se testuje a které varianty zatím zůstávají mimo rozsah,
kdo je vlastníkem procesu a kdo může rozhodnout o změně,
jaká data musí projít bez ručního přepisování,
co se považuje za chybu a jak se vrací k opravě,
podle čeho firma rozhodne pokračovat, upravit návrh nebo pilot ukončit.
Teprve po ověření dává smysl plánovat širší nasazení. Samostatný článek popisuje, jak zvládnout přechod do CRM nebo ERP bez dvojí evidence. Výběr řešení a jeho zavedení jsou dvě různá rozhodnutí.
Co má obsahovat použitelný návrh řešení
Dobré doporučení není katalog funkcí. Má umožnit vedení firmy pochopit, proč navržený rozsah odpovídá problému a jaké předpoklady se ještě musí ověřit. Mělo by obsahovat alespoň:
problém a cílový stav popsaný provozním jazykem,
rozsah i vědomě odložené části, aby se projekt nerozrůstal skrytě,
zdroje dat a odpovědnosti za jejich správnost,
ověřené integrační možnosti, nikoli předpoklad podle marketingové stránky dodavatele,
pilot a podmínky přijetí, které lze prakticky zkontrolovat,
přechod do provozu, podporu týmu a způsob řešení změn,
rizika a závislosti včetně služeb třetích stran.
Součástí návrhu může být i doporučení zatím nic nevyvíjet. Pokud problém vyřeší jasné pravidlo, úprava odpovědnosti nebo lepší nastavení používaného nástroje, nový software by pouze zakryl příčinu.
Jak tento způsob rozhodování souvisí s Metricem
Metric veřejně staví digitalizaci procesů na tom, že se nejdřív projde současná práce, potom vznikne návrh řešení a teprve následně se řeší nasazení, přenos dat a zaškolení. Konkrétní nabídka musí vždy vycházet ze skutečných nástrojů, dat, oprávnění a rozsahu dané firmy.
Třícestný rámec z tohoto článku pomáhá vést úvodní rozhodnutí bez předem vybraného výsledku. Hotový systém není automaticky levná náhražka. Propojení není kouzelné odstranění ruční práce. Vývoj na míru není důkaz větší profesionality. Každá cesta má hodnotu pouze tehdy, když odpovídá konkrétnímu procesu a firma dokáže její přínos ověřit.
Shrnutí: správné řešení může být menší, než se na začátku zdá
Rozhodnutí mezi hotovým systémem, propojením a vývojem na míru nezačíná u funkcí. Začíná u jednoho pracovního toku, jeho slabého místa a výsledku, který firma potřebuje. Teprve potom lze posoudit, zda se má přizpůsobit proces, nastavit nástroj, propojit data nebo vytvořit vlastní část.
Smyslem není najít technologicky největší variantu. Smyslem je zvolit nejmenší ověřitelný krok, který odstraní příčinu problému a nechá prostor pro další rozvoj až ve chvíli, kdy pro něj existuje skutečná potřeba.
