techone --pruvodce=b2b-portal
B2B portál: když zákazník přestane chtít posílat objednávky e-mailem
Role, data, stavy objednávky, napojení na ERP a provozní odpovědnost. Rozsah portálu musí vycházet z konkrétního obchodního procesu.
Ve zkratce
- O čem to je
- B2B portál pro samoobslužné zákazníky: firemní odběratel se přihlásí, vidí svůj sortiment, ceny dle smlouvy, otevřené objednávky a fakturaci. Scénář pro firmy, kde EDI dává smysl jen u části partnerů.
- Klíčové vrstvy
- Portál stojí na několika vrstvách: od rolí a oprávnění přes stavový model objednávek a integraci na ERP až po audit a monitoring. Každá může selhat zvlášť.
- Cesty k portálu
- Hotová B2B platforma s ERP konektorem, vlastní vývoj přes REST API, nebo portál jako modul existujícího ERP. Volba závisí na rozsahu úprav, době do produkce a velikosti týmu.
- Časový rámec
- Termín určuje počet rolí a scénářů, složitost cen a schvalování, kvalita rozhraní ERP, migrace uživatelů a způsob akceptace. Univerzální počet měsíců není spolehlivý.
- Náklady
- Náklady ovlivňuje zvolená platforma, licence, integrace, rozsah úprav, zabezpečení a následný provoz. Odhad vznikne až z analytického návrhu.
Oblasti návrhu B2B portálu
B2B portál propojuje uživatelské rozhraní, obchodní pravidla a data z dalších systémů. Každá z těchto oblastí potřebuje vlastníka a jasný postup při chybě, jinak vzniká další místo pro ruční opravy.
Pro plně automatizovanou výměnu zpráv s velkými partnery může být vhodnější EDI integrace. Tato část se zaměřuje na portál, ve kterém pracuje přihlášený uživatel.
1. Role a oprávnění
Externí role mohou zahrnovat nákupčího a schvalovatele, interní například obchodníka a administrátora. Konkrétní oprávnění se odvozují od procesu a principu nejmenších potřebných práv. Zvlášť se řeší zastupování, změna zaměstnance a odebrání přístupu.
2. Souběžné stavy objednávky
Procesní, schvalovací, platební a logistický stav se mohou měnit nezávisle. Není nutné vždy vytvářet přesně tři nebo čtyři osy; návrh má ale zabránit tomu, aby jediný stav objednávky zakryl důležitou informaci nebo povolil neplatný přechod.
3. Datový model: referenční, konfigurační, transakční
Pro každý údaj se určí autoritativní systém. Ceny a dostupnost mohou vznikat v ERP, role v portálu nebo firemní identitě a objednávka v portálu s následným předáním do ERP. Toto rozdělení se však liší podle architektury; nelze předem říct, že se určitý typ dat nikdy neupravuje mimo ERP.
4. Integrace s ERP
Portál může využít REST API, události nebo řízenou souborovou výměnu podle možností ERP. Pro každý tok se stanoví směr, četnost, identifikátor zprávy, chování při opakování a postup při nedostupnosti cílového systému. Obecné principy popisuje služba ERP integrace.
5. Validační vrstvy
Kontroly mohou ověřovat povinná pole, obchodní podmínky, kreditní limit, dostupnost nebo logistická omezení. U každé se určí, zda objednávku blokuje, pouze varuje, nebo vyžaduje schválení. Uživatel má dostat srozumitelnou zprávu a návod k dalšímu kroku.
6. Audit a monitoring
Pro důležité operace se eviduje uživatel, čas, změněné hodnoty a vazba na integrační zprávu. Monitoring sleduje dostupnost, odezvu, chybovost a nevyřízené zprávy. Rozsah záznamů a dobu uchování je potřeba sladit s účelem, zabezpečením a ochranou osobních údajů.
Jak postavit B2B portál
Portál lze postavit na hotové platformě, vyvinout na míru nebo využít modul používaného ERP. Porovnání musí zahrnout funkční pokrytí, možnosti integrace, licence, údržbu, vlastnictví dat a budoucí změny.
Hotová B2B platforma + ERP konektor
Dává smysl, pokud standard platformy pokrývá většinu požadavků a pro vaše ERP existuje použitelné napojení. Je potřeba ověřit licenční model, možnosti úprav, podporu konkrétního konektoru a odpovědnost za aktualizace.
Vlastní vývoj + REST API integrace
Hodí se pro specifické procesy, více zdrojových systémů nebo požadavky, které hotová platforma nepokrývá. Firma získá větší kontrolu nad řešením, současně ale odpovídá za jeho další rozvoj, bezpečnost a provoz. Tuto cestu řešíme v rámci aplikací na míru.
Portál jako modul existujícího ERP
Může omezit počet samostatných komponent a využít data i oprávnění ERP. Je ale potřeba ověřit možnosti uživatelského rozhraní, rozšíření, licencování a podporu externích uživatelů v konkrétní verzi systému.
EDI nebo portál: rozhodovací mřížka
EDI a portál řeší rozdílný způsob komunikace. EDI je vhodné pro opakovanou strukturovanou výměnu mezi systémy, zatímco portál předpokládá práci člověka v uživatelském rozhraní. Firma může používat jeden nebo oba kanály podle požadavků partnerů. Akvizici a práci s obchodní příležitostí popisuje průvodce CRM pro obchodní tým.
Velikost odběratele
Velikost partnera sama nerozhoduje. Důležitější je jeho technická připravenost, objem zpráv, požadovaný standard a ochota pracovat v portálu.
Frekvence komunikace
Vyšší a pravidelný objem strukturovaných zpráv může podporovat volbu EDI. U méně častých objednávek může být praktičtější portál.
Standardizace
EDI: pevná podle specifikace partnera (EDIFACT, EANCOM, VDA). Portál: flexibilní, postupy v UI se přizpůsobují uživateli.
Lidský zásah
EDI omezuje ruční zadávání běžných zpráv, ale stále potřebuje monitoring a řešení výjimek. V portálu uživatel objednávku zadává, doplňuje nebo schvaluje.
Doba do nasazení
Termín EDI určuje specifikace a testování s partnerem. U portálu rozhoduje funkční rozsah, integrace, migrace uživatelů a akceptační testování.
Časté chyby v projektech B2B portálu
Následující oblasti je vhodné vyřešit už v návrhu a ověřit v akceptačních scénářích.
1. Portál bez aktualizace cen z ERP
Pokud smluvní cenu spravuje ERP, musí portál znát její platnost a okamžik poslední aktualizace. Podle procesu lze použít synchronní dotaz, událost nebo řízenou dávku; důležité je zabránit potvrzení objednávky s neplatnou cenou.
2. Slabě navržené přihlašování a správa účtů
Externí uživatel nemusí mít firemní účet, který lze propojit s přihlašováním do portálu. Podle klientely lze použít jednotné přihlášení (SSO), vlastní účty nebo kombinaci. Vícefaktorové ověření, obnova přístupu, deaktivace uživatele a role se navrhují podle rizika prováděných operací.
3. Žádný auditní záznam
Bez historie změn se obtížně řeší reklamace, bezpečnostní incidenty i chyby integrace. Zaznamenávat se má uživatel, čas, významná změna a vazba na příslušnou operaci v ERP. Rozsah logu musí být přiměřený účelu a ochraně osobních údajů.
4. Mobilní rozhraní řešené až nakonec
Podporovaná zařízení vycházejí z práce skutečných uživatelů. Pokud objednávají nebo schvalují na telefonu, musí se tyto scénáře navrhnout a otestovat na mobilu od začátku, ne pouze zmenšit desktopové rozhraní.
Často kladené otázky
Kolik stojí B2B portál?
Cenu ovlivňuje zvolená platforma, její licenční model, počet rolí, složitost cen a schvalování, integrace, zabezpečení a následný provoz. Konkrétní rozpočet lze připravit až nad analytickým návrhem a ověřenými možnostmi ERP.
Jak dlouho trvá analytický návrh B2B portálu?
Délku určuje počet rolí, procesních variant, zdrojových systémů a dostupnost klíčových lidí. Výstup může zahrnovat scénáře použití, oprávnění, datový model, integrační rozhraní, validační pravidla a otevřené otázky. Vývojový tým na něj může navázat, během realizace ale dál potřebuje rozhodnutí vlastníků procesu.
Funguje to s naším ERP (K2 ERP, Helios, ABRA)?
Nejdřív ověříme konkrétní verzi ERP a podporované rozhraní. Dynamics 365, K2 ERP, Helios nebo ABRA Flexi mohou podle verze nabídnout API nebo souborovou výměnu. Přímé databázové zásahy nepovažujeme automaticky za bezpečnou náhradu API; musí je podporovat dodavatel a odpovídat za ně provozní model.
Jak řešíte vychystávání z více skladů a paletové množství?
Pravidla vychystávání obvykle vlastní ERP nebo WMS, ne samotný portál. Portál může zobrazit dostupnost, povolené množství nebo návrh dorovnání podle dat, která z těchto systémů dostane. Je potřeba určit, kde se rozhoduje o skladu, šarži, FEFO či FIFO a co může uživatel změnit.
Co s mobilní podporou? Stačí responzivní web?
Responzivní web obvykle stačí pro prohlížení, objednání a schválení, pokud jsou tyto scénáře od začátku navržené pro mobil. PWA může doplnit instalaci na domovskou obrazovku, offline režim nebo oznámení, jejich podpora se ale liší podle platformy. Nativní aplikace dává smysl při hlubší práci se zařízením nebo rozsáhlém offline provozu.
Jak vypadá auditní záznam prakticky?
U významné změny lze evidovat čas, uživatele, stav před a po a vazbu na integrační operaci. IP adresa nebo další technické údaje se ukládají jen tehdy, když pro ně existuje účel a odpovídající pravidla ochrany dat. Dobu uchování neurčuje jeden univerzální pětiletý limit; stanoví se podle typu záznamu, smluvních a právních požadavků a zásady minimalizace.
Kam dál
ERP integrace (služba)
Napojení ERP na e-shop, CRM, sklad. EDI s obchodními partnery, REST API integrace.
EDI integrace pro výrobce
Automatizovaná B2B komunikace s velkými partnery. EDIFACT, ORDERS, DESADV, INVOIC.
Aplikace na míru (služba)
B2B portály, firemní aplikace, mobilní řešení napojené na ERP.
Řešíte B2B portál?
Probereme role, obchodní pravidla, zdrojová data a možnosti vašeho ERP. Potom navrhneme rozsah analýzy nebo integrace.
Domluvit konzultaci