CRM i ERP u prodaji: gdje završava pipeline, a… | ORKA

CRM i ERP u prodaji: gdje završava pipeline, a… | ORKA

CRM završava ondje gdje komercijalni tim treba prijeći s namjere kupnje na operativno obvezujuću transakciju. ERP počinje kada ponuda, narudžba ili drugi dogovoreni okidač zahtijeva provjeru artikala, cijena, zaliha, rokova isporuke, kreditnih uvjeta i knjiženja. Dobra integracija prodaje ne briše tu granicu. Ona je čini jasnom i povezuje podatke bez dvostrukog unosa.

CRM je radni prostor prodajnog tima. U njemu nastaju i razvijaju se:

Takav model odgovara na pitanja: tko je kupac, što pokušava riješiti, u kojoj je fazi razgovor i kakva je prognoza prihoda. Primjerice, Orkasta CRM za prodajni pipeline može poslužiti kao mjesto za vođenje prilika, aktivnosti i prodajne discipline prije nego što posao uđe u izvršenje.

ERP upravlja podacima i postupcima koji moraju ostati dosljedni kroz narudžbu, skladište, isporuku, računovodstvo i izvještavanje. Tipični ERP sadržaj uključuje:

ERP zato ne bi trebao biti samo odredište podataka iz CRM-a. On je sustav izvršenja i poslovne evidencije. Ako CRM prikazuje optimističnu procjenu, ERP mora prikazati ono što je naručeno, raspoloživo, isporučivo i financijski evidentirano.

Granica nije uvijek ista za svaku tvrtku. Ovisi o prodajnom modelu, vrstama artikala, proizvodnji po narudžbi, ugovornim cijenama i razini decentralizacije prodaje. Ipak, korisno je odvojiti četiri trenutka.

Lead, prvi kontakt, poziv, prezentacija, potreba kupca i procjena potencijala pripadaju CRM-u. U toj fazi nema razloga otvarati ERP kupca ni rezervirati zalihe samo zato što postoji interes.

Pogrešan pristup je automatsko slanje svakog leada u ERP. Rezultat mogu biti duplicirani kupci, nepotpuni podaci i šifrarnik opterećen zapisima bez poslovne vrijednosti.

Prodajni pipeline treba zadržati faze prilike, procijenjeni iznos, vjerojatnost i planirani datum zaključenja. Te vrijednosti služe upravljanju prodajom i procjeni budućeg opterećenja, ali nisu isto što i potvrđena narudžba.

ERP može primati podatke potrebne za okvirno planiranje, ako proces to opravdava. No takav prijenos mora jasno označiti status: prognoza nije nalog, a planirana potražnja nije rezervirana zaliha.

Ponuda je najčešće prijelazna točka. CRM može sastaviti komercijalni prijedlog, dok ERP osigurava važeće artikle, cijene, raspoloživost i uvjete. U jednostavnijem modelu prodavatelj bira ERP artikle unutar CRM-a, a ponuda nastaje u CRM-u. U strože kontroliranom modelu ponuda ili njezine stavke nastaju u ERP-u, dok CRM prikazuje njihov status uz priliku.

Nije presudno gdje korisnik klikne za izradu dokumenta. Presudno je utvrditi koji sustav vodi pojedinu činjenicu. Na primjer:

Okidač prijenosa može biti prihvaćena ponuda, potpisani ugovor, zaprimljena narudžbenica kupca ili ručna potvrda odgovorne osobe. Odabrani okidač treba odgovarati stvarnom procesu, ne samo tehničkoj mogućnosti integracije.

Nakon otvaranja ERP prodajnog naloga, ERP vodi izvršenje. CRM treba primiti povratne informacije korisne prodaji: broj naloga, status obrade, planirani datum isporuke, isporučenu količinu, broj računa ili signal blokade. Ne mora preuzeti svaki računovodstveni detalj. Cilj je prodavatelju dati pouzdan kontekst bez pretvaranja CRM-a u drugu glavnu knjigu.

Zamislimo prodavatelja koji pregovara s postojećim kupcem o isporuci opreme i prateće usluge. U CRM-u vodi kontakte, sastanke, potrebu, priliku, očekivani iznos i datum odluke. U ponudi želi prikazati konkretne artikle.

Integracija tada može raditi ovim redoslijedom:

Ovaj posljednji detalj je važan. Posao može biti komercijalno dobiven prije isporuke, ali ne smije se zamijeniti s ostvarenim prihodom, isporučenom količinom ili naplaćenim računom. Svaka mjera treba zadržati vlastitu definiciju.

Integracija bez jasnih identifikatora često stvara duplikate i nepouzdane veze. Naziv kupca nije dovoljan identifikator: može se promijeniti, može postojati više društava sličnog naziva, a prodajni kontakt može raditi za više pravnih subjekata.

Prije implementacije vrijedi dogovoriti najmanje sljedeće:

Uz identifikatore treba definirati vlasništvo nad poljima. Ako prodavatelj promijeni telefon kontakta u CRM-u, smije li se promjena vratiti u ERP? Ako računovodstvo izmijeni platni uvjet u ERP-u, treba li CRM prikazati novu vrijednost ili samo upozorenje? Odgovor nije univerzalan, ali odluka mora biti zapisana.

Pouzdana integracija prodaje obično koristi selektivnu sinkronizaciju. Ne treba slati svaku CRM bilješku u ERP niti svaki ERP zapis skladišnog kretanja u CRM.

Koristan početni opseg često obuhvaća:

Treba odrediti i tehnička pravila: smjer prijenosa, učestalost, obradu pogrešaka, ponavljanje neuspjelih prijenosa, zapis promjena i postupak za ručnu korekciju. Dvosmjerna sinkronizacija nije automatski zrelija. Ona povećava potrebu za pravilima pri sukobu podataka.

Jedan sustav ne može bez posljedica preuzeti sve uloge drugoga. Ako ERP preuzme rano upravljanje prilikama, prodavatelji mogu izgubiti brzinu i pregled nad aktivnostima. Ako CRM postane mjesto za konačne cijene, zalihe i račune, raste rizik odstupanja od operativne evidencije.

Poseban oprez traže:

U takvim slučajevima integracija treba prikazati stvarno stanje procesa, a ne simulirati jednostavan tijek koji u praksi ne postoji.

Prije odabira konektora ili izrade API specifikacije, nacrtajte put od prvog kontakta do knjiženja računa. Uz svaki korak označite vlasnika, obvezne podatke, poslovni status i sustav u kojem nastaje konačna evidencija.

ORKA u ERP i procesnom screeningu može pomoći strukturirati takvu provjeru: razdvojiti prodajni pipeline od izvršenja, prepoznati ključne identifikatore i odrediti opseg integracije koji odgovara stvarnom radu prodaje, skladišta i računovodstva.

Recommended articles