Přejít na obsah

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.

Ř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