Průvodce ERP

Jak poznat dodavatele ERP, který rozumí vašemu provozu

Konzultace s dodavatelem ERP přímo ve firemním provozu

Seznam modulů je při výběru ERP užitečný, ale sám o sobě neříká, zda bude systém odpovídat každodenní práci firmy. Stejně důležitý jako software je proto výběr dodavatele ERP: jeho schopnost pochopit, kudy firmou procházejí informace, zboží a doklady, kde vznikají chyby a které situace potřebují zaměstnanci řešit bez zbytečných oklik.

Neexistuje jeden nejlepší ERP systém pro všechny firmy. Rozhoduje shoda mezi potřebami konkrétního provozu, možnostmi systému a přístupem dodavatele. Jak poznat partnera, který tuto souvislost chápe?

ERP se nevybírá pouze podle tabulky funkcí

Dva systémy mohou mít v nabídce stejné položky: sklad, objednávky, nákup, výrobu, expedici, fakturaci i účetnictví. Na papíře pak vypadají téměř zaměnitelně. Rozdíl se ukáže teprve ve chvíli, kdy místo názvu modulu položíte konkrétní provozní otázku.

Například položka „sklad“ ještě nevysvětluje, jak systém ověří dostupnost zboží pro objednávku, rezervuje zásobu, zpracuje částečné dodání, dohledá šarži nebo napraví rozdíl zjištěný při expedici. Podobně označení „fakturace“ neříká, z jakého dokladu faktura vznikne, kdo ji může opravit a jak se údaje předají účetnictví.

Funkční seznam pomáhá vytvořit první přehled. Rozhodnutí by ale mělo vycházet z konkrétních scénářů, které odpovídají reálné práci vaší firmy.

Dobrý dodavatel se nejdříve ptá

Dodavatel, který chce provozu porozumět, nezačne dlouhou prezentací všech možností systému. Nejdříve si potřebuje ujasnit, jak dnes práce probíhá a jakého výsledku chce firma dosáhnout. Měl by se ptát například:

  • Jak vzniká zákaznická objednávka?
  • Přichází ručně, z e-shopu, přes API nebo EDI?
  • Kdo ověřuje dostupnost zboží?
  • Jak se řeší částečné dodání?
  • Může mít jedna dodávka více balíků?
  • Používají se skladové pozice, šarže, expirace nebo výrobní čísla?
  • Kde vzniká faktura?
  • Kdo kontroluje expedované zboží?
  • Jak probíhá inventura?
  • Jaké údaje se dnes přepisují mezi několika programy?
  • Které výjimky pracovníci řeší nejčastěji?
  • Které informace jsou pouze v tabulkách, papírech nebo hlavách pracovníků?

Odpovědi vedení jsou důležité, ale samy nestačí. Jiný pohled má obchodník přijímající objednávku, skladník hledající zboží, pracovník expedice balící zásilku, účetní kontrolující doklady nebo mistr plánující výrobu. Právě tito lidé znají každodenní zdržení, ruční opravy a výjimky, které v procesní mapě často nejsou vidět.

Potřebuje vidět skutečný provoz

Návštěva skladu, výroby nebo expedice dokáže během krátké doby odhalit souvislosti, které se v zasedací místnosti popisují obtížně. Dodavatel může vidět například:

  • ruční přepisování údajů,
  • papírové seznamy používané vedle systému,
  • obcházení skladu kvůli zjištění skutečného stavu,
  • několik různých označení stejného zboží,
  • místa, kde práce stojí a čeká na informaci,
  • samostatné tabulky mimo hlavní systém,
  • postupy vzniklé kvůli dlouhodobým omezením původního programu.

Smyslem prohlídky není automaticky převést každý starý postup do nového ERP. Některé zvláštnosti jsou pro firmu nezbytné, například kvůli dohledatelnosti, kontrole nebo požadavkům zákazníků. Jiné jsou pouze zvykem či reakcí na omezení starého systému.

Zkušený dodavatel obě situace rozliší. Nejdříve ověří, zda potřebu pokrývá standardní proces nového systému, jeho nastavení nebo rozumná změna pracovního postupu. Teprve potom má smysl uvažovat o úpravě na míru.

Umí popsat celý proces, nejen jednotlivý modul

ERP propojuje části firmy, které na organizačním schématu mohou patřit různým oddělením. Proto by ukázka neměla vypadat jako série oddělených prezentací skladu, obchodu a účetnictví. Dodavatel by měl na jednom konkrétním příkladu projít celý tok:

  1. přijetí objednávky,
  2. ověření dostupnosti,
  3. nákup chybějícího zboží,
  4. příjem do skladu,
  5. vyskladnění,
  6. kontrolu expedice,
  7. vytvoření zásilky,
  8. fakturaci,
  9. předání údajů účetnictví.

U každého kroku má být zřejmé, odkud se data berou, kdo je doplňuje, co systém převezme automaticky a kde probíhá kontrola. Důležité je také vědět, zda se informace přepisují, nebo se mezi kroky bezpečně přenášejí.

Taková ukázka odhalí nejen možnosti jednotlivých modulů, ale hlavně jejich návaznost. Právě na rozhraní mezi odděleními a systémy totiž často vzniká čekání, dvojí práce nebo nejasná odpovědnost.

Ptá se také na výjimky

Standardní ukázková objednávka se správnými údaji a zbožím skladem obvykle proběhne hladce. Skutečnou znalost provozu prověří až otázky na situace, které se nevejdou do ideálního scénáře:

  • Co se stane, když část zboží není skladem?
  • Jak se zpracuje objednávka rozdělená do více dodávek?
  • Jak se řeší jedna výdejka rozdělená do více balíků?
  • Co se stane, když čtečka načte neznámý kód?
  • Jak se postupuje, když se skutečný stav liší od systému?
  • Jak se dohledá konkrétní šarže nebo výrobní číslo?
  • Co se stane při výpadku připojení nebo externí služby?
  • Jak se opraví chybně zadaný doklad?
  • Kdo může změnu provést a lze ji zpětně dohledat?

Nejde o to, aby dodavatel na místě slíbil jednoduchou odpověď na každou možnost. Měl by však umět situaci rozebrat, ukázat standardní chování systému a otevřeně označit místa, která vyžadují ověření, nastavení nebo další návrh.

Rozlišuje standardní řešení, nastavení a vývoj na míru

Stejný požadavek může na první pohled působit jako nutnost programování, ale ve skutečnosti existují tři odlišné situace:

  • Požadavek řeší standardní funkce. Je součástí běžného systému a lze jej použít bez vývoje.
  • Požadavek lze vyřešit nastavením. Systém potřebuje vhodně nakonfigurovat, určit pravidla, oprávnění, číselné řady nebo návaznosti.
  • Požadavek vyžaduje úpravu či integraci. Firma má skutečně specifickou potřebu nebo je nutné propojit ERP s externí službou.

Dodavatel by měl předem srozumitelně říct, do které skupiny požadavek patří, co navržené řešení ovlivní a co přesně bude součástí nabídky. U úpravy na míru je důležité znát její rozsah, způsob testování, návaznost na aktualizace a odpovědnost za rozhraní.

Programování není automaticky špatně, ale nemá nahrazovat správné nastavení ani rozumnější standardní postup. Dobré řešení používá zakázkový vývoj tam, kde přináší jasný provozní přínos.

Dokáže pracovat s reálnými daty

Ukázková databáze s několika dokonale vyplněnými kartami předvede princip systému. Neodhalí však duplicity, nejednotné kódy, chybějící vazby ani formáty, se kterými firma skutečně pracuje.

Proto je užitečné během výběru projít několik anonymizovaných nebo testovacích příkladů:

  • skutečnou strukturu skladové karty,
  • vzorek objednávky,
  • dodavatelský ceník,
  • používané čárové kódy,
  • příklad faktury,
  • požadovaný export,
  • výstup z e-shopu nebo jiného systému.

Na reálném vzorku může dodavatel včas upozornit na chybějící údaje, duplicity, rozdílné identifikátory nebo potřebné mapování. Firma současně získá konkrétnější představu, co bude před převodem dat nutné vyčistit a kdo za tuto práci odpovídá.

Má plán převodu dat a spuštění systému

Převod dat není technický detail, který se vyřeší až těsně před spuštěním. Ovlivňuje návaznost práce, počáteční stavy i důvěru uživatelů v nový systém. Dodavatel má umět vysvětlit:

  • která data se budou převádět,
  • odkud se získají a v jakém formátu,
  • jak se před importem zkontrolují,
  • zda proběhne zkušební import,
  • jak se ověří počáteční skladové stavy,
  • co zůstane dostupné jen v původním systému,
  • kdy se zastaví práce ve starém programu,
  • jak proběhne ostré spuštění,
  • kdo bude odpovědný za kontrolu jednotlivých oblastí.

Zkušební převod dává čas upravit mapování i zdrojová data, aniž by byl ohrožen běžný provoz. Praktické kroky a kontrolní otázky jsme podrobněji popsali v článku Jak připravit data před přechodem na ERP.

Počítá se školením a podporou po spuštění

Implementace nekončí instalací programu. Uživatelé potřebují pochopit nejen ovládání obrazovek, ale také svou roli v novém společném procesu. Skladník, obchodník, účetní a vedoucí výroby proto obvykle nepotřebují stejné školení.

Plán by měl zahrnout:

  • proškolení jednotlivých skupin uživatelů,
  • možnost procvičit reálné situace,
  • dostupnou pomoc při zahájení provozu,
  • jasný způsob hlášení problémů,
  • postup řešení aktualizací,
  • další rozvoj systému podle měnícího se provozu firmy.

Před podpisem smlouvy je proto namístě zjistit, kdo bude podporu poskytovat, v jakých časech je dostupná, jak se určují priority požadavků a co patří do sjednaných služeb.

Umí otevřeně říct, co systém neumí

Důvěryhodný dodavatel neslibuje automaticky splnění každého přání. Dokáže rozlišit, co systém umí nyní, co bude potřeba nastavit, co lze účelně doprogramovat a co by bylo nepřiměřeně složité nebo provozně nevhodné.

Někdy je nejlepší odpovědí změna firemního postupu. Jindy má smysl integrace nebo přesně vymezená úprava. Podstatné je, aby firma znala varianty, jejich dopady a omezení ještě před rozhodnutím.

Otevřené přiznání hranic systému je při výběru ERP cennější než obecný slib, že „všechno půjde“. Umožňuje porovnat nabídky podle skutečného rozsahu, ne podle optimistických formulací.

Varovné signály při výběru dodavatele

Zvýšenou pozornost si zaslouží situace, kdy dodavatel:

  • představuje pouze funkce a téměř se neptá,
  • slibuje splnění všeho ještě před poznáním provozu,
  • nedokáže předvést celý průchod konkrétního dokladu,
  • nezajímá se o výjimky a chybové situace,
  • neřeší kvalitu vstupních dat,
  • nemá jasný postup zkušebního převodu,
  • neurčí, co je standard a co placená úprava,
  • nepopíše podporu po spuštění,
  • nedokáže vysvětlit návaznost na ostatní systémy,
  • nutí zákazníka rozhodovat pouze podle ceny licence.

Jeden signál nemusí automaticky znamenat nevhodného partnera. Pokud se jich ale objevuje více a dodavatel nedokáže nejasnosti konkretizovat, firma by měla před podpisem vyžádat podrobnější návrh řešení.

Otázky, které má firma položit před podpisem smlouvy

Následující checklist pomůže porovnat dodavatele nad stejnými praktickými tématy:

  • Můžete na našem příkladu ukázat celý proces od objednávky po fakturu?
  • Které naše požadavky řeší standardní systém?
  • Které požadavky vyžadují nastavení, integraci nebo programovou úpravu?
  • Jak proběhne převod dat?
  • Kdo odpovídá za jejich kontrolu?
  • Jak bude probíhat testování?
  • Jaké budou další náklady kromě licence?
  • Jak se řeší aktualizace?
  • Kdo nám pomůže po spuštění?
  • Jak systém komunikuje s naším e-shopem, bankou, dopravci nebo účetnictvím?
  • Co se stane při chybě nebo výpadku některé navazující služby?
  • Jak lze systém později rozšířit?

Odpovědi si nechte popsat co nejkonkrétněji a vztáhněte je k vlastním datům a procesům. Snáze tak odlišíte hotovou funkci od předpokladu, který bude teprve potřeba ověřit.

Přístup MJSoft k implementaci MAXimu

Informační systém MAXim vyvíjíme a nasazujeme v reálných firmách více než 25 let. Při návrhu řešení potřebujeme nejdříve pochopit skutečný provoz zákazníka: práci jednotlivých rolí, návaznost dokladů, pohyb zboží i místa, kde dnes vzniká ruční práce nebo čekání.

Podle potřeb konkrétní firmy propojujeme sklad, obchod, výrobu, expedici, fakturaci, účetnictví, e-shopy, dopravce a další služby. Možnosti napojení podrobněji představujeme v přehledu integrací systému MAXim.

Pokud standardní funkce nestačí, posoudíme, zda je vhodnější nastavení, integrace, účelná programová úprava nebo změna procesu. Cílem implementace informačního systému není pouze nainstalovat program, ale vytvořit společný tok dat, který odpovídá reálné práci firmy a je srozumitelný jeho uživatelům.

Vybíráte nový ERP systém a chcete nejdříve ověřit, zda bude odpovídat skutečnému provozu vaší firmy? Nezávazně s námi projděte svoje procesy a požadavky.