Jak připravit firmu na výběr systému workflow/BPM/RPA/ERP/CRM, abyste se nestali závislí na dodavateli?

Poté sepište požadavky, které chrání před závislostí: export dat a historie případů v otevřeném formátu, zdokumentované API, procesy zapsané ve standardu BPMN, právo na vlastní konfiguraci a jasná pravidla ukončení smlouvy. Pojmenujte rizika, která dnes dokážete identifikovat. Nebuďte naivní a sepište všechna rizika. Nabídky porovnávejte na vlastních scénářích a v celkových nákladech za několik let (investice plus opakující se provozní náklady). Licence, obnovy, školení, udržování týmu, změny, migrace. Zamyslete se nad tím, jak pravděpodobné je, že dodavatel ztratí klíčové konzultanty, rozhodne se nahradit administrátory a vývojáře umělou inteligencí nebo přestane podporovat stávající operační systém.

Tento příspěvek je určen vedení firem a komunálních společností, které chtějí uspořádat oběh dokumentů, nákladových faktur, smluv nebo žádostí a stojí před výběrem systému workflow, tedy nástroje, který vede případ od jedné osoby ke druhé podle stanovených pravidel. K výběru jsou obvykle tři cesty: hotová platforma BPM, nástroj low-code nebo dedikovaný systém vytvořený na zakázku; níže uvedené zásady platí pro všechny z nich. Hodí se i finančním ředitelům, protože to oni obvykle platí za důsledky špatného rozhodnutí.

Proč závislost na dodavateli vzniká už na startu

Závislost zřídka vzniká z jediného špatného rozhodnutí. Obvykle začíná dříve, než si to firma uvědomí: procesy jsou popsány v nástroji dodavatele, a ne ve vlastních dokumentech; data a historie případů jsou ve formátu, který nelze snadno vyjmout; konfiguraci zná pouze implementační partner; a smlouva mluví hodně o implementaci a málo o tom, co se stane, když chce firma odejít. Po několika letech stojí změna systému více než jeho udržování, i když přestal odpovídat potřebám.

Krok 1. Popište procesy, než začnete jednat s dodavateli

Než vznikne poptávka, vyplatí se popsat oběhy, které má systém obsluhovat: kdo případ zakládá, kdo ho schvaluje a v jakém pořadí, jaké jsou výjimky a prahové hodnoty (například jiná cesta nad určitou částkou), jaké jsou lhůty a jakou stopu rozhodování je třeba zachovat pro případ auditu. Nejlépe je to zapsat ve standardu BPMN, kterému rozumí různé nástroje. Pak popis procesu patří firmě, a ne systému.

Bez takového popisu porovnáváte prezentace dodavatelů, ne řešení. Každá ukázka vypadá dobře, protože dodavatel předvádí svůj nejlepší scénář, ne Váš nejobtížnější výjimečný případ.

Krok 2. Zjistěte, co už máte

Část oběhů lze často obsluhovat v nástrojích, které firma už má: v CRM, v oborových systémech, v systému spisové služby nebo v kancelářském balíku. Někdy je závěrem analýzy, že nový systém není potřeba a stačí změna postupu nebo konfigurace. Taková inventarizace také ukáže integrace, které bude muset nový systém obsluhovat, například se systémem finančního účetnictví a KSeF, a místa, kde se dnes ztrácí informace. Více: inventarizace IT systémů.

Krok 3. Požadavky, které chrání před závislostí

Tyto požadavky je vhodné zapsat do poptávky jako podmínky, ne přání:

1. Export dat a historie případů v otevřeném, zdokumentovaném formátu, kdykoli a bez dalšího poplatku.
2. Zdokumentované API pro integraci s dalšími systémy, s právem na jeho využití i jinými dodavateli.
3. Procesy zapsané ve standardu (BPMN), které lze exportovat a znovu sestavit jinde.
4. Právo na konfiguraci vlastním týmem nebo libovolným partnerem, s dokumentací změn.
5. Pravidla ukončení smlouvy: přechodné období, pomoc s migrací dat a její náklady známé předem.
6. Volba partnera pro údržbu: zda lze po implementaci přejít k jiné implementační firmě bez ztráty podpory výrobce.

Totéž platí pro RPA, ERP a CRM

Tyto zásady platí pro každý systém, který uspořádává práci firmy. Vždy se však vyplatí začít otázkou, čeho chceme dosáhnout, protože na odpovědi závisí, zda vůbec volíme správnou třídu nástroje.

RPA. První otázka zní: proč zrovna RPA, a ne BPM? Softwarový robot přebírá opakující se činnosti člověka v existujících systémech, ale proces nemění; BPM uspořádává samotný proces. Pokud je cílem odlehčit lidem od přepisování dat mezi systémy, robot může stačit. Pokud je cílem nový, kratší oběh případů, robot často starý postup jen konzervuje. Robot také závisí na obrazovkách a formátech jiných systémů: každá jejich změna ho může zastavit, proto je dobré znát náklady na údržbu scénářů a mít jejich popis mimo nástroj výrobce.

ERP. Zde zní klíčová otázka: má nám ERP přinést osvědčené postupy a hotové procesy, nebo má podporovat naše vlastní procesy, které budují konkurenční výhodu? V prvním případě se vyplatí držet se standardu systému a omezovat úpravy, protože každá komplikuje aktualizace a změnu partnera. Ve druhém případě se někdy lépe osvědčí jednoduchý ERP obestavěný pružným systémem BPM, ve kterém se mění procesy, jimiž se firma odlišuje, bez zásahů do jádra. V obou případech musí jít finanční, skladová a personální data i integrace s KSeF a bankami vyjmout v plném rozsahu, včetně historie.

CRM. Než začneme porovnávat nabídky, vyplatí se ujasnit, co pod pojmem CRM rozumíme: uspořádání procesů zákaznického servisu, vícekanálový prodej, nebo platformu pro získávání zakázek. Jsou to tři různé projekty, s jinými uživateli, jinými integracemi a jiným měřítkem úspěchu. Bez ohledu na variantu by měl být export databáze klientů s historií kontaktů a souhlasů a API do prodejních a servisních systémů podmínkou v poptávce, ne doplňkem.

Krok 4. Porovnejte celkové náklady, ne cenu licence

Nabídky je vhodné sestavit v celkových nákladech za několik let: nákup a implementace, údržba a licence, rozvoj a náklady na ukončení smlouvy. Nejlevnější licence bývá nejdražší ve třetím roce, kdy každá změna procesu znamená placenou zakázku u jediného partnera. Porovnání je nejlepší dělat na Vašich scénářích: ať každý dodavatel předvede stejný obtížný případ z Vaší firmy. Více k hodnocení nabídek: hodnocení nabídek a jednání s dodavateli.

Krok 5. Přejímka a smlouva o údržbě

Systém je vhodné přejímat podle předem dohodnutých testovacích scénářů a kritérií, ne podle prohlášení dodavatele. Smlouva o údržbě by měla stanovit, v jakém čase se odstraňují chyby, kdo a za kolik zavádí změny, a potvrzovat ujednání o exportu dat a ukončení smlouvy.

Příklad z praxe

Ve skupině dceřiných společností mezinárodního koncernu firma používala centrální ERP systém a zároveň potřebovala automatizovat finanční procesy ze skupiny procure-to-pay, a to v souladu s firemními nákupními směrnicemi (corporate purchasing guidelines). Silné bylo pokušení sáhnout po korporátních nástrojích pro týmovou práci, ty se ale ukázaly jako poměrně drahé a nesplňovaly požadavky na nezávislost ani snadný odchod, kdyby nastaly problémy.

Na setkáních se zainteresovanými stranami jsme připravili podrobný popis požadavků, který šel nad rámec standardních funkcí hotových řešení. Vypracovali jsme několik alternativních způsobů integrace s oborovými systémy a mechanismy omezující riziko vendor lock-inu u jednoho dodavatele. Výsledkem byla ucelená aplikační strategie založená na standardech a prostředí, ve kterém nové oběhy vznikají agilně, prostřednictvím prototypování na krátkých setkáních s vlastníky procesů, včetně netechnických. Toto prostředí obestavuje ERP systém: poskytuje velkou flexibilitu tam, kde se firma odlišuje, bez nákladů na velké implementace.