Zadání aplikace k ERP má být jasné dřív, než začne vývoj. Ne proto, aby vznikl dlouhý dokument, ale aby bylo předem zřejmé, jaký proces aplikace řeší, kdo ji bude používat, odkud bere data a kdo ponese odpovědnost za výsledek.
Dobré zadání aplikace k ERP zároveň brání tomu, aby nová webová aplikace jen obcházela ERP místo toho, aby ho rozumně rozšířila.
U aplikací napojených na ERP bývá nejdražší ne samotné programování, ale nejasné rozhodování během projektu. Když se teprve ve vývoji zjistí, že obchod, sklad a účetní chápou stejný proces jinak, aplikace začne suplovat chybějící dohodu ve firmě. To je špatný základ.
Tento checklist pomůže připravit zadání tak, aby aplikace k ERP rozšířila systém smysluplně. Ne aby vznikl další systém vedle něj. Když je aplikace k ERP navržená podle procesu a dat, bývá jednodušší na provoz i další rozvoj.
Shrnutí v kostce
Zadání aplikace musí začít procesem, ne obrazovkami.
ERP má zůstat hlavním zdrojem pravdy pro data, která řídí firmu.
Před vývojem musí být jasní uživatelé, role, výjimky, schvalování i vlastnictví dat.
Dobré zadání neřeší jen ideální stav, ale i chyby, storna, ruční zásahy a provozní odpovědnost.
Pokud si firma není jistá procesem, má smysl začít konzultací, ne rovnou vývojem.
1. Jaký proces má aplikace k ERP skutečně řešit?
První otázka nezní, jak má aplikace vypadat, ale který firemní proces má zlepšit. Objednávky partnerů, reklamace, schvalování požadavků, skladové pohyby, servisní agenda nebo zákaznický portál mají každý jinou logiku.
Do zadání patří popis současného stavu: co se dnes dělá ručně, kde vznikají chyby, kdo čeká na koho a co se musí přepisovat do ERP. Teprve potom dává smysl kreslit obrazovky.
Dobré zadání pojmenuje i hranici aplikace. Některé kroky má řešit webová aplikace, jiné má dál držet ERP. Pokud tato hranice chybí, aplikace se snadno rozroste do malého paralelního ERP.
2. Kdo bude aplikaci používat a s jakými právy?
Webová aplikace k ERP obvykle nemá jednoho uživatele. Používá ji obchodník, skladník, zákazník, partner, účetní, servisní technik nebo manažer. Každý potřebuje jiné informace a jiné oprávnění.
V zadání má být jasné, kdo smí data vidět, kdo je smí měnit a kdo pouze schvaluje. Jiný režim potřebuje interní uživatel a jiný externí partner. U B2B portálu například nestačí říct, že partner vidí objednávky. Je potřeba vědět, zda vidí jen své objednávky, objednávky celé firmy, faktury, individuální ceny nebo stav skladu.
Práva se nevyplatí nechávat na konec. Patří mezi základní rozhodnutí architektury.
3. Která data jsou v ERP a která vznikají v aplikaci?
ERP má být u klíčových obchodních a provozních dat zdrojem pravdy. Typicky jde o zákazníky, produkty, ceny, skladovou dostupnost, objednávky, faktury, dodací adresy nebo schválené číselníky.
Aplikace může vytvářet vlastní data, například požadavky, komentáře, přílohy, pracovní stavy nebo historii úkonů. I tam ale musí být jasné, co se má vracet zpět do ERP a co zůstane jen v aplikaci.
Oblast
Typická otázka do zadání
Riziko při nejasnosti
Zákazníci
Kdo je zakládá a kde se aktualizují?
Duplicity a rozdílné kontakty
Ceny
Čtou se přímo z ERP, nebo se kopírují?
Chybné nabídky a spory s partnery
Sklad
Stačí orientační dostupnost, nebo přesný stav?
Slibování zboží, které není k dispozici
Objednávky
Kdy se zapisují do ERP?
Ztracené nebo duplicitní objednávky
Přílohy
Kam se ukládají a kdo je spravuje?
Nejasná auditní stopa
4. Jak budou fungovat integrace a datové toky?
Napojení na ERP není jen technická položka v rozpočtu. Je to dohoda o tom, kdy a jak data tečou mezi systémy. Některé informace se mají číst v reálném čase, jiné stačí synchronizovat v dávkách.
U zadání aplikace je potřeba rozhodnout, zda má aplikace volat ERP přímo, přes API, přes integrační vrstvu, nebo přes datové exporty. Stejně důležité je vědět, co se stane při výpadku. U Business Central je vhodné ověřit také oficiální možnosti napojení aplikací na Business Central, aby aplikace k ERP nestála na křehkém exportu nebo ručním obcházení systému. Může uživatel pokračovat? Má se objednávka uložit a odeslat později? Nebo se proces zastaví?
Čím blíže je aplikace obchodnímu nebo skladovému provozu, tím přesnější musí být pravidla pro integraci.
5. Jaké výjimky se budou dít v běžném provozu?
Zadání často popisuje ideální cestu. Jenže provoz firmy stojí na výjimkách: zákazník změní objednávku, partner překročí kredit, zboží není skladem, skladník načte špatnou položku, někdo potřebuje storno nebo ruční opravu.
Výjimky není možné všechny odhadnout dokonale. Jde ale pojmenovat ty časté a drahé. Právě tam vzniká největší rozdíl mezi aplikací, která funguje v prezentaci, a aplikací, která funguje každý den.
Do zadání patří minimálně odpověď na otázky: kdo smí výjimku vyřešit, kde se o ní vede záznam, zda se zapisuje do ERP a jak se pozná, že je uzavřená.
6. Kde probíhá schvalování a kdo rozhoduje?
Schvalování je častý důvod pro vývoj webové aplikace. Firma nechce, aby požadavky běhaly e-mailem, v Excelu nebo po telefonu. To dává smysl, pokud jsou pravidla schvalování jasná.
Před vývojem je potřeba popsat, jaké stavy proces má, kdo je mění a kdy se požadavek považuje za schválený. Jinak vznikne aplikace, ve které sice existuje tlačítko Schválit, ale nikdo neví, co přesně znamená.
Dobré zadání rozlišuje pracovní stav, obchodní stav a účetní nebo skladový dopad. Ne všechny změny musí hned měnit ERP.
7. Jaké reporty a přehledy budou potřeba?
Manažerský přehled se má navrhovat společně s procesem. Pokud se řeší až na konci, často chybí data, podle kterých má report fungovat.
Uživatelé potřebují operativní přehledy: co čeká na akci, co je po termínu, kde je chyba a co se nepřeneslo do ERP. Vedení firmy potřebuje jiný pohled: objemy, stavy, trend, vytížení, rychlost zpracování nebo obchodní dopad.
Do zadání proto patří i metriky úspěchu. Aplikace nemá být jen nová obrazovka. Má zkrátit čas, snížit chyby, zrychlit objednávky nebo dát lepší kontrolu.
8. Kdo aplikaci vlastní po spuštění?
Po nasazení vývoj nekončí. Někdo musí rozhodovat o změnách, prioritách, nových rolích, číselnících a provozních pravidlech. Pokud vlastnictví chybí, každá drobná úprava se mění ve spor mezi IT, obchodem a provozem.
Zadání má určit business ownera aplikace, technického správce a kontaktní osoby za jednotlivé procesy. Stejně důležitá je dohoda, jak se budou sbírat požadavky na změny a kdo je bude schvalovat.
Aplikace napojená na ERP má dlouhodobý dopad. Proto potřebuje dlouhodobého vlastníka.
9. Jak bude vypadat testování a pilotní provoz?
Testování aplikace k ERP nemůže být jen klikání přes obrazovky. Musí projít reálné scénáře, data, role, integrace a výjimky. Ideální je použít vzorky skutečných objednávek, zákazníků, skladových stavů nebo požadavků.
Pilotní provoz pomůže odhalit, co v zadání chybělo. Měl by mít jasný rozsah, skupinu uživatelů a pravidlo, kdy se aplikace považuje za připravenou pro širší nasazení.
Bez pilotu se chyba v procesu často objeví až ve chvíli, kdy ji vidí zákazník nebo partner.
Kdy začít vývojem a kdy nejdřív konzultací?
Vývojem má smysl začít, když firma ví, jaký proces řeší, kdo rozhoduje, jaká data jsou v ERP a jaký má být výsledek. Pokud tyto věci nejsou jasné, je lepší začít krátkou analýzou.
Konzultace před vývojem není brzda projektu. Je to způsob, jak zabránit tomu, aby se draze vyvíjelo řešení pro špatně pojmenovaný problém.
Časté otázky
Musí být zadání aplikace detailní technická specifikace?
Nemusí. Na začátku je důležitější jasný popis procesu, uživatelů, dat a očekávaného výsledku. Technická specifikace vzniká až potom, co je jasné, co má aplikace dělat a proč.
Co když firma neví, jestli upravit ERP, nebo vyvinout aplikaci?
To je běžná situace. Rozhodnutí by mělo vycházet z procesu, dat a uživatelských potřeb. Některé požadavky patří do ERP, jiné je vhodnější řešit navazující webovou aplikací.
Jak dlouho trvá připravit dobré zadání aplikace?
Záleží na rozsahu. U jednodušší aplikace často stačí několik workshopů a kontrola datových vazeb. U většího portálu nebo integrační aplikace je potřeba hlubší analýza procesů a pilotní scénáře.
Proč nestačí nakreslit obrazovky?
Obrazovky ukazují, co uživatel vidí. Neřeší ale zdroj dat, odpovědnosti, schvalování, výjimky ani dopad na ERP. Bez těchto rozhodnutí je návrh obrazovek jen část zadání.
Další krok
Pokud připravujete aplikaci k ERP, začněte jasným zadáním procesu. Podívejte se také na možnosti zakázkových aplikací a domluvte si konzultaci přes kontaktní formulář. Quartex Praha Vám pomůže připravit zadání aplikace k ERP a rozlišit, co má zůstat v ERP a co dává smysl řešit samostatnou aplikací.
Zadání webové aplikace k ERP: 9 věcí, které musí být jasné před vývojem
Zadání aplikace k ERP má být jasné dřív, než začne vývoj. Ne proto, aby vznikl dlouhý dokument, ale aby bylo předem zřejmé, jaký proces aplikace řeší, kdo ji bude používat, odkud bere data a kdo ponese odpovědnost za výsledek.
Dobré zadání aplikace k ERP zároveň brání tomu, aby nová webová aplikace jen obcházela ERP místo toho, aby ho rozumně rozšířila.
U aplikací napojených na ERP bývá nejdražší ne samotné programování, ale nejasné rozhodování během projektu. Když se teprve ve vývoji zjistí, že obchod, sklad a účetní chápou stejný proces jinak, aplikace začne suplovat chybějící dohodu ve firmě. To je špatný základ.
Tento checklist pomůže připravit zadání tak, aby aplikace k ERP rozšířila systém smysluplně. Ne aby vznikl další systém vedle něj. Když je aplikace k ERP navržená podle procesu a dat, bývá jednodušší na provoz i další rozvoj.
Shrnutí v kostce
1. Jaký proces má aplikace k ERP skutečně řešit?
První otázka nezní, jak má aplikace vypadat, ale který firemní proces má zlepšit. Objednávky partnerů, reklamace, schvalování požadavků, skladové pohyby, servisní agenda nebo zákaznický portál mají každý jinou logiku.
Do zadání patří popis současného stavu: co se dnes dělá ručně, kde vznikají chyby, kdo čeká na koho a co se musí přepisovat do ERP. Teprve potom dává smysl kreslit obrazovky.
Dobré zadání pojmenuje i hranici aplikace. Některé kroky má řešit webová aplikace, jiné má dál držet ERP. Pokud tato hranice chybí, aplikace se snadno rozroste do malého paralelního ERP.
2. Kdo bude aplikaci používat a s jakými právy?
Webová aplikace k ERP obvykle nemá jednoho uživatele. Používá ji obchodník, skladník, zákazník, partner, účetní, servisní technik nebo manažer. Každý potřebuje jiné informace a jiné oprávnění.
V zadání má být jasné, kdo smí data vidět, kdo je smí měnit a kdo pouze schvaluje. Jiný režim potřebuje interní uživatel a jiný externí partner. U B2B portálu například nestačí říct, že partner vidí objednávky. Je potřeba vědět, zda vidí jen své objednávky, objednávky celé firmy, faktury, individuální ceny nebo stav skladu.
Práva se nevyplatí nechávat na konec. Patří mezi základní rozhodnutí architektury.
3. Která data jsou v ERP a která vznikají v aplikaci?
ERP má být u klíčových obchodních a provozních dat zdrojem pravdy. Typicky jde o zákazníky, produkty, ceny, skladovou dostupnost, objednávky, faktury, dodací adresy nebo schválené číselníky.
Aplikace může vytvářet vlastní data, například požadavky, komentáře, přílohy, pracovní stavy nebo historii úkonů. I tam ale musí být jasné, co se má vracet zpět do ERP a co zůstane jen v aplikaci.
4. Jak budou fungovat integrace a datové toky?
Napojení na ERP není jen technická položka v rozpočtu. Je to dohoda o tom, kdy a jak data tečou mezi systémy. Některé informace se mají číst v reálném čase, jiné stačí synchronizovat v dávkách.
U zadání aplikace je potřeba rozhodnout, zda má aplikace volat ERP přímo, přes API, přes integrační vrstvu, nebo přes datové exporty. Stejně důležité je vědět, co se stane při výpadku. U Business Central je vhodné ověřit také oficiální možnosti napojení aplikací na Business Central, aby aplikace k ERP nestála na křehkém exportu nebo ručním obcházení systému. Může uživatel pokračovat? Má se objednávka uložit a odeslat později? Nebo se proces zastaví?
Čím blíže je aplikace obchodnímu nebo skladovému provozu, tím přesnější musí být pravidla pro integraci.
5. Jaké výjimky se budou dít v běžném provozu?
Zadání často popisuje ideální cestu. Jenže provoz firmy stojí na výjimkách: zákazník změní objednávku, partner překročí kredit, zboží není skladem, skladník načte špatnou položku, někdo potřebuje storno nebo ruční opravu.
Výjimky není možné všechny odhadnout dokonale. Jde ale pojmenovat ty časté a drahé. Právě tam vzniká největší rozdíl mezi aplikací, která funguje v prezentaci, a aplikací, která funguje každý den.
Do zadání patří minimálně odpověď na otázky: kdo smí výjimku vyřešit, kde se o ní vede záznam, zda se zapisuje do ERP a jak se pozná, že je uzavřená.
6. Kde probíhá schvalování a kdo rozhoduje?
Schvalování je častý důvod pro vývoj webové aplikace. Firma nechce, aby požadavky běhaly e-mailem, v Excelu nebo po telefonu. To dává smysl, pokud jsou pravidla schvalování jasná.
Před vývojem je potřeba popsat, jaké stavy proces má, kdo je mění a kdy se požadavek považuje za schválený. Jinak vznikne aplikace, ve které sice existuje tlačítko Schválit, ale nikdo neví, co přesně znamená.
Dobré zadání rozlišuje pracovní stav, obchodní stav a účetní nebo skladový dopad. Ne všechny změny musí hned měnit ERP.
7. Jaké reporty a přehledy budou potřeba?
Manažerský přehled se má navrhovat společně s procesem. Pokud se řeší až na konci, často chybí data, podle kterých má report fungovat.
Uživatelé potřebují operativní přehledy: co čeká na akci, co je po termínu, kde je chyba a co se nepřeneslo do ERP. Vedení firmy potřebuje jiný pohled: objemy, stavy, trend, vytížení, rychlost zpracování nebo obchodní dopad.
Do zadání proto patří i metriky úspěchu. Aplikace nemá být jen nová obrazovka. Má zkrátit čas, snížit chyby, zrychlit objednávky nebo dát lepší kontrolu.
8. Kdo aplikaci vlastní po spuštění?
Po nasazení vývoj nekončí. Někdo musí rozhodovat o změnách, prioritách, nových rolích, číselnících a provozních pravidlech. Pokud vlastnictví chybí, každá drobná úprava se mění ve spor mezi IT, obchodem a provozem.
Zadání má určit business ownera aplikace, technického správce a kontaktní osoby za jednotlivé procesy. Stejně důležitá je dohoda, jak se budou sbírat požadavky na změny a kdo je bude schvalovat.
Aplikace napojená na ERP má dlouhodobý dopad. Proto potřebuje dlouhodobého vlastníka.
9. Jak bude vypadat testování a pilotní provoz?
Testování aplikace k ERP nemůže být jen klikání přes obrazovky. Musí projít reálné scénáře, data, role, integrace a výjimky. Ideální je použít vzorky skutečných objednávek, zákazníků, skladových stavů nebo požadavků.
Pilotní provoz pomůže odhalit, co v zadání chybělo. Měl by mít jasný rozsah, skupinu uživatelů a pravidlo, kdy se aplikace považuje za připravenou pro širší nasazení.
Bez pilotu se chyba v procesu často objeví až ve chvíli, kdy ji vidí zákazník nebo partner.
Kdy začít vývojem a kdy nejdřív konzultací?
Vývojem má smysl začít, když firma ví, jaký proces řeší, kdo rozhoduje, jaká data jsou v ERP a jaký má být výsledek. Pokud tyto věci nejsou jasné, je lepší začít krátkou analýzou.
Konzultace před vývojem není brzda projektu. Je to způsob, jak zabránit tomu, aby se draze vyvíjelo řešení pro špatně pojmenovaný problém.
Časté otázky
Musí být zadání aplikace detailní technická specifikace?
Nemusí. Na začátku je důležitější jasný popis procesu, uživatelů, dat a očekávaného výsledku. Technická specifikace vzniká až potom, co je jasné, co má aplikace dělat a proč.
Co když firma neví, jestli upravit ERP, nebo vyvinout aplikaci?
To je běžná situace. Rozhodnutí by mělo vycházet z procesu, dat a uživatelských potřeb. Některé požadavky patří do ERP, jiné je vhodnější řešit navazující webovou aplikací.
Jak dlouho trvá připravit dobré zadání aplikace?
Záleží na rozsahu. U jednodušší aplikace často stačí několik workshopů a kontrola datových vazeb. U většího portálu nebo integrační aplikace je potřeba hlubší analýza procesů a pilotní scénáře.
Proč nestačí nakreslit obrazovky?
Obrazovky ukazují, co uživatel vidí. Neřeší ale zdroj dat, odpovědnosti, schvalování, výjimky ani dopad na ERP. Bez těchto rozhodnutí je návrh obrazovek jen část zadání.
Další krok
Pokud připravujete aplikaci k ERP, začněte jasným zadáním procesu. Podívejte se také na možnosti zakázkových aplikací a domluvte si konzultaci přes kontaktní formulář. Quartex Praha Vám pomůže připravit zadání aplikace k ERP a rozlišit, co má zůstat v ERP a co dává smysl řešit samostatnou aplikací.
Tagy:
Nejnovější příspěvky
Kategorie
Štítky