Razvoj softvera: programiranje B2B portala za naručivanje uz ERP

Programiranje B2B portala za naručivanje omogućava odobrenim kupcima da vide svoj katalog i cene, šalju i ponavljaju porudžbine i prate dokumenta, uz sinhronizaciju sa ERP-om. Obim definišite po fazama: prvo nalozi, cene i porudžbine, zatim plaćanja i odobravanja. Portal koji od prvog dana pokušava da obuhvati sve obično se pokreće kasno i slabo se koristi.

Šta su ERP i programiranje B2B portala za naručivanje?

B2B portal za naručivanje je brendirani veb-kanal na kom se odobreni distributeri i poslovni kupci prijavljuju i samostalno obavljaju poslove: pregledaju katalog dostupan svom nalogu, vide dogovorene cene, sastavljaju porudžbinu ili ponavljaju prethodnu i pronalaze dokumenta vezana za svoj nalog — ponude, porudžbine, fakture, knjižna odobrenja i isporuke. ERP ostaje centralni sistem evidencije; portal je prozor u te podatke, uz pravila o tome šta svaki nalog sme da vidi i uradi.

Vredi razlikovati portal od tri srodna rešenja sa kojima se često meša:

• Veb-prodavnice. Maloprodajne cene, otvorena registracija i plaćanje karticom. Distributerski portal je suprotan: pristup se odobrava za svaki nalog, cene su ugovorne, a plaćanje se obavlja prema dogovorenim uslovima, a ne prilikom naplate.


• Korisničkog dela na marketinškom sajtu. Koristan je za preuzimanje dokumenata i tikete podrške, ali bez kataloga, cena i logike poručivanja ne uklanja nijedan poziv prodajnom timu.


• PDF cenovnika poslatog imejlom. Tako većina distributera posluje pre uvođenja portala: cenovnik je tačan na dan slanja, zastareo već sledeće nedelje i ne može da se pretražuje po nalogu.

Tabela funkcionalnosti: obavezno, preporučeno, kasnije

Stranice dobavljača obično navode sve funkcionalnosti odjednom. Definisanje faza omogućava da se prvo izdanje zaista isporuči. Tabela razvrstava česte funkcionalnosti prema tome šta je potrebno za prvo izdanje, šta se obično dodaje u drugom i šta može da sačeka podatke o stvarnoj upotrebi:

Tabela A: funkcionalnost | namena | faza (1/2/3) | zavisnost od ERP-a

Prva faza je izdanje koje menja način rada: kada distributer može da se prijavi, vidi svoje cene, ponovi prošlomesečnu porudžbinu i pošalje je u ERP, pozivi i tabele počinju sami da ustupaju mesto portalu. Faze 2 i 3 dodaju finansijske i upravljačke slojeve, za koje organizacija prethodno mora da donese odluke o kreditiranju, finansijama i odobravanju kako bi ih softver mogao da sprovede.

Integracija ERP-a i CRM-a

Integracija odlučuje da li je portal odraz poslovanja ili brošura sa prijavom. Pre izbora arhitekture potrebni su pisani odgovori na četiri pitanja:

1. Smer sinhronizacije. Matični podaci — nalozi, proizvodi, cene i uslovi — prenose se iz ERP-a na portal. Porudžbine, zahtevi za ponudu i plaćanja vraćaju se u ERP. Za sve ostalo treba jasno odrediti odgovornu stranu: ko sme da menja cenu i gde se ta promena evidentira?


2. Učestalost sinhronizacije. Noćna obrada, periodično osvežavanje tokom dana ili skoro trenutno ažuriranje. Praktično pravilo: cene i kreditna stanja opravdavaju češću sinhronizaciju od slika proizvoda, pa je kombinovani pristup uobičajen — ključni podaci češće, sadržaj kataloga ređe.


3. Obrada grešaka. Kada ERP ne radi ili zapis ne prođe proveru, šta portal radi: stavlja ga u red čekanja, odbija ga ili prikazuje poslednje poznato stanje uz jasno obaveštenje? Tiha greška može da navede distributera da naruči po prošlonedeljnoj ceni, što postaje vaš spor, ne njegov.


4. Usklađivanje. Kako znate da je svaka porudžbina sa portala postala tačno jedan dokument u ERP-u — bez duplikata, praznina i nepotpuno konvertovanih zapisa? Rešenje je operativni izveštaj koji neko svakodnevno čita tokom prvih meseci, a njegova provera je i jedan od testova prihvatanja u nastavku.

Višejezični katalozi i više valuta

Izvoznici se s oba pitanja susreću rano, a odluke jeftinije je doneti unapred nego naknadno ugrađivati u rešenje.

Jezici. Za katalog su potrebni prevodi naziva proizvoda, kategorija i dokumenata; strukturi naloga potrebno je jezičko podešavanje za svaki nalog kako portal ne bi tražio od istog kupca da bira jezik pri svakoj poseti. Važne su dve praktične odluke: odredite ko je odgovoran za prevode i koliko često ih ažurira — kupcu koji primeti propuste, delimično preveden katalog deluje lošije od kataloga samo na engleskom — i odlučite da li dokumenta (ponude, fakture) prate jezik interfejsa ili ostaju na jeziku koji zahteva vaš finansijski sistem. Ovo drugo pitanje nije tehničko: faktura na pogrešnom jeziku predstavlja računovodstveni problem.

Valute. Cene dogovorene u jednoj valuti treba prikazivati u toj valuti bez obzira na lokaciju posetioca; mešanje valute prikaza i ugovorne valute dovodi do sporova. Ako nalog posluje u više valuta, pravilo mora da bude u podacima ERP-a, a ne u podešavanjima portala. Portal nikada ne sme sam da izmišlja konverziju.

Obe teme uklapaju se u plan po fazama: izvoznik koji prodaje na tri tržišta može u prvoj fazi da pokrene portal na jezicima koji se zaista koriste u porudžbinama na ta tri tržišta, a dodatne jezike kataloga da uvede kad se pojavi potreba. Opšte pravilo za jezički sadržaj na komercijalnim sajtovima — jedan odgovorni vlasnik, jedna izvorna datoteka i jedan postupak ažuriranja — opisano je na stranici o internet marketingu, a isto važi i za katalog na portalu.

Bezbednost i uloge

Portal je ulaz u vaše poslovne podatke, zato su ključna pitanja dizajna zapravo pitanja pristupa:

• Pristup se odobrava, ne registruje samostalno. Vaš tim kreira svaki nalog na osnovu naloga u ERP-u. Alternativa — otvorena registracija uz naknadno odobrenje — privlači neželjene prijave i zamagljuje ko je kupac.


• Dozvole zasnovane na ulogama. Kupac može da sastavlja i šalje porudžbine do određenog limita; odobravalac može da ih pusti; korisnik sa pravom uvida može samo da čita dokumenta. Limiti po ulozi deo su komercijalnih uslova, a ne tehnički detalj: oni određuju ko u organizaciji vašeg kupca može da ga obaveže.


• Izolacija naloga. Najozbiljniji rizik u ovoj vrsti proizvoda jeste da jedan distributer vidi cene ili dokumenta drugog. Vidljivost podataka po nalogu mora izričito da se testira; to je jedan od testova prihvatanja u nastavku.


• Evidencija aktivnosti. Treba sačuvati ko je poslao porudžbinu, ko ju je odobrio, ko je promenio cenu i kada — kao podatke, ne samo kao datoteke zapisnika koje neko mora da bude ubeđen da pročita. U trgovini se sporovi češće rešavaju ovom evidencijom nego sećanjem.


• Identitet i jedinstvena prijava. Za veće distributere često je potreban SSO povezivanjem sa njihovim direktorijumom. To je zahtev koji vredi obraditi u kasnijoj fazi: većina naloga dobro funkcioniše uz pozivnice i lozinke dok centrala ne zatraži federaciju identiteta.


• Zaštita podataka. Na podatke kupaca na portalu važe iste obaveze koje kompanija već ima za svoju evidenciju kupaca. Za poslovanje u Turskoj to je okvir KVKK, a za evropske kupce GDPR — tema detaljnije obrađena na stranici o eksternalizaciji IT usluga u kontekstu saradnje sa razvojnim partnerom.

Razvoj po meri ili platforma

Izbor nije apstraktno pitanje razvoja po meri ili gotovog rešenja; radi se o tome koji sloj zapravo kupujete.

Tabela B: pristup | šta dobijate | za šta ste odgovorni | kada odgovara

Većina izvoznika pri prvom izboru opredeli se za srednju mogućnost, ali treba izbeći pretpostavku da je ona jeftina: konektor je proizvod koji zahteva održavanje, pa se taj trošak ponavlja. Okvir za odluku — podesiti, kupiti ili razviti — detaljno je obrađen na stranici o ERP-u po meri ili kao gotovom rešenju. Ova stranica dodaje proveru specifičnu za portal: bez obzira na izbor, cene po nalogu i prenos porudžbine u ERP moraju dokazivo biti tačni, a izabrani pristup treba da omogući tu proveru uz najniže ponavljajuće troškove.

Uvođenje po fazama i testovi prihvatanja

Uvođenje portala može tiho da podbaci ako „radi“ znači samo da je „demonstracija radila“. Za svaku fazu treba pripremiti pisane testove prihvatanja i sprovesti ih sa stvarnim nalozima i podacima:

1. Vidljivost kataloga po nalogu. Prijavite se kao dva različita distributera; svaki mora da vidi tačno svoj skup proizvoda, bez ikakvog traga o skupu drugog. Ovo se namerno testira, ne podrazumeva.


2. Tačnost cena. Za uzorak naloga i artikala, cena na portalu mora da bude jednaka ceni u ERP-u, uključujući pravila na kojima se zasniva (grupa cena, nivo, ugovor). Ovaj test štiti poslovni odnos: pogrešna cena na portalu gora je od pogrešne cene u ponudi jer ju je kupac video kao važeći dogovor.


3. Ispravnost porudžbine. Porudžbina poslata na portalu mora da postane tačno jedan dokument u ERP-u, sa ispravnim artiklima, količinama, jedinicama i cenama, što potvrđuje i izveštaj o usklađivanju. Testirajte i putanju greške: porudžbina blokirana pravilom treba jasno da objasni razlog, umesto da neprimetno ne uspe.


4. Statusi i dokumenta. Faktura i isporuka evidentirane u ERP-u treba da se pojave u prikazu odgovarajućeg naloga na portalu, sa ispravnim statusom i u dogovorenom roku sinhronizacije.


5. Uslovi i limiti. Kredit i uslovi plaćanja za svaki nalog moraju pravilno da se prikazuju, a porudžbine koje prema pravilima treba blokirati ili označiti za proveru moraju biti blokirane ili označene. Testirajte granične vrednosti, ne samo uobičajene slučajeve.


6. Svakodnevne navike. Ponavljanje porudžbine, brza porudžbina po šifri artikla i pretraga — sa spiskovima proizvoda dva vaša stvarna distributera, a ne demonstracionim katalogom. Usvajanje portala zavisi od ove tri putanje, a kvalitetno testiranje košta samo deo izrade.

Često postavljana pitanja

Da li nam je ERP potreban unapred?

Ne treba vam novi sistem, ali su vam potrebni pouzdani matični podaci na jednom mestu: nalozi, proizvodi, cenovnici i uslovi. Ako se oni nalaze samo u tabelama, portal će automatizovati greške iz tabela za svaki nalog, što je gore nego da nastavite sa telefonskim naručivanjem. U tom slučaju prvo treba stabilizovati podatke — često u postojećem ERP-u koji se nedovoljno koristi — a tek potom uvesti portal. O toj odluci iz ugla ERP-a govori stranica o Odoo-u za trgovinske kompanije.

Mogu li kupci da imaju sopstvene cenovnike?

Da. Cene po nalogu su osnovna funkcionalnost ove vrste proizvoda, a ne dodatak: grupe cena, stepenaste cene ili pojedinačni ugovori čuvaju se u ERP-u i prikazuju za svaki nalog. Važno je insistirati na tome da portal nikada sam ne obračunava cene: prikazuje ono što je u ERP-u, a svaka cena koju distributer vidi može da se poveže sa dogovorom koji je vaš tim sklopio.

Kako se odobravaju porudžbine?

Obično postoje dva nivoa. U organizaciji vašeg kupca, odobravanje je njegova odgovornost: kupac predlaže, odobravalac pušta porudžbinu, po potrebi uz određene limite — portal može da podrži te uloge u trećoj fazi. U vašoj organizaciji porudžbina stiže u ERP i prolazi kroz uobičajeni postupak obrade. Portal ne zamenjuje kontrole prodajnog tima; uklanja ponovno unošenje podataka i pozive potrebne oko njega.

Može li portal da podrži više jezika?

Može i treba, ali obim odredite za svaku fazu. Prevod kataloga, jezičko podešavanje za svaki nalog i prevedena dokumenta tri su različita zadatka. Pokrenite prvu fazu na jezicima koje aktivna tržišta koriste u porudžbinama, a ostale dodajte kada postoji stvarna potražnja. Pravila upravljanja — jedan odgovorni vlasnik prevoda i jedna putanja ažuriranja — navedena su u višejezičnom odeljku iznad.

Ko je vlasnik podataka?

Vi: nalozi, cene, porudžbine, dokumenta i istorija ostaju evidencija kompanije u ERP-u. To treba izričito navesti u ugovoru sa timom koji razvija portal: pristup hostingu, izvorni kod ili konfiguracija i izvoz podataka pri raskidu saradnje. Stranica o eksternalizaciji IT usluga obrađuje intelektualnu svojinu i uslove izlaska u širem kontekstu ugovora o razvoju.

Kako da uvedemo distributere u korišćenje portala?

Počnite od naloga koji najviše naručuju, lično im pošaljite pozivnicu i u prvoj poruci navedite tri stvari: podatke za prijavu, njihov cenovnik prikazan na ekranu i osobu koju mogu da pozovu. Zatim pratite pokazatelj koji je zaista važan — ne broj prijava, već udeo ponovljenih porudžbina pristiglih preko portala. Paralelan rad (porudžbina poslata preko portala pa potvrđena telefonom) normalan je nekoliko nedelja. Prestaje kada portal dokazano ispravno prikazuje cene i dokumenta, što treba da potvrde prethodno navedeni testovi prihvatanja.

Izvori i standardi

• Tipičan skup funkcionalnosti opisan na ovoj stranici (nalozi, cenovnici po nalogu, ponavljanje porudžbine, fakture i knjižna odobrenja, vidljivost po nalogu, uloge sa limitima, odloženo plaćanje i platni servisi) zasniva se na spiskovima mogućnosti koje dobavljači navode za B2B portale za naručivanje uopšte. Ova stranica ne obećava rezultate, troškove ni rokove.
• Dva uobičajena pristupa uvođenju (portal u okviru ERP-a i platforma za trgovinu, kao što je Shopify, sinhronizovana sa ERP-om posredničkim softverom ili konektorima) predstavljena su kao ponavljajuće mogućnosti; ne tvrdi se da postoji partnerstvo sa bilo kojim dobavljačem platforme.
• Tvrdnje o procesima i upravljanju prate stranice ovog sajta: ERP po meri ili kao gotovo rešenje, RFP kontrolna lista za dobavljače, Odoo za trgovinske kompanije i eksternalizacija IT usluga iz Turske (obaveze zaštite podataka, intelektualna svojina i uslovi izlaska, planiranje pilot-projekta).
• Ova stranica ne sadrži primere klijenata, budžete za portale ni trajanje projekata; obim, faze i komercijalni uslovi određuju se za svaki projekat u ponudi.

Povezane stranice

Razvoj softvera · ERP po meri ili kao gotovo rešenje · RFP kontrolna lista za dobavljače · Odoo ERP za trgovinske kompanije · Internet marketing · Zatražite ponudu