CPQ ja ERP – kuka omistaa tarjouksen ja kuka tilauksen?

“Meillähän on jo ERP, miksi tarvitsemme erillisen CPQ:n?”

Kysymys tulee vastaan lähes jokaisessa asiakaskeskustelussa, ja se on täysin looginen. ERP pyörittää jo tuotteita, asiakkaita ja varastosaldoja. Miksi ihmeessä tarjouslaskenta pitäisi viedä toiseen järjestelmään?

Koska myyminen ja toimittaminen ovat kaksi täysin eri asiaa.

ERP loistaa siinä, mitä tapahtuu kaupan lukitsemisen jälkeen. Se on kuitenkin todella kankea työkalu silloin, kun myyjä istuu asiakkaan kanssa ja yrittää vasta rakentaa sopivaa pakettia. ERP on hallinnollinen järjestelmä. Tarjouksen tekeminen taas on luova prosessi.

Missä raja kulkee?

CPQ (Configure, Price, Quote) vastaa kysymykseen: “Mitä asiakas tarvitsee ja mitä se maksaa?” Se auttaa myyjää valitsemaan oikeat komponentit ja laskee hinnan reaaliajassa.

ERP taas herää henkiin kun muste on jo paperissa. Se kysyy: “Mitä on myyty ja paljonko se vaatii varastosaldoa?”

Ongelmat alkavat, kun myyjät pakotetaan tekemään CPQ:n työt ERP:ssä. Myyjä yrittää rakentaa asiakkaalle monimutkaista kokoonpanoa järjestelmässä, joka on suunniteltu näyttämään varastosaldon historiaa. Tuloksena myyjät turhautuvat ja kaivavat esiin omat salaiset Excel-laskurinsa.

Miksi ERP:tä sitten yritetään käyttää kaikkeen?

Yleensä siksi, että ERP oli talossa ensin. Se on niellyt valtavasti rahaa ja aikaa, joten on täysin ymmärrettävää yrittää puristaa siitä irti kaikki mahdollinen. Kun tuotteet ja asiakkaat ovat jo järjestelmässä, tarjouslaskennan hoitaminen samassa putkessa tuntuu äkkiseltään järkevältä.

Mutta ERP:n tuotedata on tehty logistiikalle. Se tuntee SKU-koodit ja ostohinnat. Se ei ymmärrä, voiko tuotetta A käyttää yhdessä tuotteen B kanssa, tai miten asiakaskohtainen sopimusalennus vaikuttaa kymmenen eri komponentin pakettihintaan.

Toinen syy on se, että CPQ:n hyödyt ovat hankintavaiheessa vaikeammin mitattavissa. Nopeampi myyntisykli ja vähentyneet tarjousvirheet eivät näy suoraan missään raportissa, ennen kuin järjestelmä on käytössä.

Miten työnjako oikeasti toimii?

Nyrkkisääntö on yksinkertainen: tarjous elää CPQ:ssa, kunnes siihen saadaan asiakkaan kuittaus. Vasta hyväksytty tilaus siirretään ERP:iin.

Arjessa tämä menee suurin piirtein näin:

1. Tuotedata ja pohjahinnat valuvat ERP:stä (tai PIM:stä) CPQ:n suuntaan.
2. Myyjä tekee tarjouksen CPQ:ssa. Järjestelmä pitää huolen säännöistä, yhteensopivuuksista ja oikeista alennuksista.
3. Asiakas hyväksyy tarjouksen.
4. CPQ lähettää ERP:iin valmiin paketin: kuka osti ja mitä ostettiin.
5. ERP hoitaa toimituksen ja laskutuksen.

Kumpikin työkalu tekee sen, missä se on hyvä. ERP:n ei tarvitse opetella sääntömoottorin logiikkaa, eikä CPQ:sta tarvitse vääntää varastonhallintaa. Vain lukittu lopputulos siirtyy eteenpäin.

Tarjous elää CPQ:ssa, kunnes tilaus lukitaan ja siirretään ERP:iin

cpq.adafy.com

Integraatiossa ei kannata ahnehtia

ERP-integraatiossa näkee usein saman virheen. Yritetään rakentaa valtava massasynkronointi, joka siirtää kaiken asiakashistoriasta alkaen kerralla. Se on varma tapa saada projekti jumiin puoleksi vuodeksi.

Fiksumpaa on aloittaa kapeasti. REST API:n kautta CPQ:sta voi hakea tuotetiedot ja työntää valmiin tilauksen ERP:iin, eikä tiedostoja tarvitse siirrellä käsin. Sama rajapinta taipuu myöhemmin muuhunkin, vaikka asiakasportaaliin.

Muutamaan asiaan kannattaa silti varautua:

• Kuka päättää hinnan? Jos sekä ERP että CPQ yrittävät laskea loppusummia omilla säännöillään, tiedossa on ongelmia. Anna CPQ:n laskea tarjoushinta ja käske ERP:n hyväksyä se tilauksen tullessa sisään.
• Tuotedatan laatu. ERP:ssä tuote saattaa olla yksi yksinkertainen koodirivi. CPQ:ssa se sama tuote voi vaatia satoja riippuvuuksia ja yhteensopivuussääntöjä. Dataa joutuu lähes poikkeuksetta rikastamaan jossain välissä.

Kumpi ongelma teillä todellisuudessa on?

Jos mietit vielä, kannattaisiko nykyistä ERP:tä vain hieman viilata, käy läpi tämä lyhyt lista:

1. Laskevatko myyjät hintoja sivuun tehdyillä Excel-laskureilla?
2. Pitääkö myyjien muistaa ulkoa, mitkä tuotteet sopivat yhteen?
3. Kaatuuko tilauksia toimitusvaiheessa siihen, että tarjous oli teknisesti mahdoton toteuttaa?
4. Onko myyntijohtaja sokea tarjousten tilanteelle ennen kuin ne muuttuvat tilauksiksi ERP:ssä?

Jos vastasit useampaan kyllä, olette luultavasti saavuttaneet ERP:n rajat myynnin työkaluna.

Vika ei silti ole ERP:ssä. Se tekee todennäköisesti juuri sen, mihin se on aikanaan hankittu. Tarjouslaskenta ei vain koskaan ollut sen tehtävä.

Kun järjestelmät asetetaan oikeisiin rooleihinsa, molemmat toimivat paremmin. Myyjät saavat keskittyä ratkaisujen rakentamiseen nopean työkalun avulla. IT ja talous saavat pitää ERP:n puhtaana turhasta sotkusta, ja sisään tulevat tilaukset ovat valmiiksi oikeassa muodossa.

Adafy CPQ:n headless-arkkitehtuuri ja REST API on suunniteltu nimenomaan siihen, että data siirtyy kivuttomasti järjestelmien välillä. Emme pakota korvaamaan vanhaa, vaan rakennamme sen rinnalle sujuvan myyntiprosessin. Jos kuulostaa tutulta, jutellaan lisää tilanteestanne.