Näin rakensimme POS-laitteiden ja tilausten kaupallisen elinkaaren

Kassajärjestelmän kauppa ei ole enää yksinkertainen, kun sama sopimus kattaa päätteet, skannerit, tulostimet, maksulaitteet, ohjelmistotilaukset, asennuksen, koulutuksen ja tuen. Jokaisella sopimusrivillä voi olla erilaiset konfigurointisäännöt, sopimusehdot, toimitusvaiheet ja laskutusaikataulut. Jos arkkitehtuuri yhdistää vain CRM-tietueet ERP-tietueisiin, yritys ei vieläkään pysty luotettavasti seuraamaan, mitä on myyty, hyväksytty, toimitettu, asennettu, laskutettu, muutettu tai uusittu.

Toteutimme yhdysvaltalaiselle vähittäiskaupan teknologiatoimittajalle POS-laitteiston kaupallisen elinkaaren Salesforcen ja SAP:n välille. Tässä artikkelissa selitämme koko toteutusta kuvaavan asiakastarinan taustalla olevat suunnitteluratkaisut: järjestelmien vastuut, tuotemallinnuksen, konfiguroinnin, hinnoittelun, tilausten orkestroinnin, toimitukset, laskutuksen ja myynnin jälkeiset muutokset.

Keskeinen suunnitteluratkaisu

Käsittelimme projektia liikevaihtoarkkitehtuurin toteutuksena, emme erillisenä CPQ-käyttöönottona. Jokaisen kaupallisen päätöksen oli pysyttävä hyödynnettävissä tiimeille ja järjestelmille, jotka vastasivat tilausten täyttämisestä, kirjanpidosta ja jatkuvasta asiakassuhteesta.

Mitä toteutuksen piti ratkaista

Asiakas oli siirtänyt myyntiorganisaationsa HubSpotista Salesforce Sales Cloudiin, ja SAP säilyi toiminnanohjausjärjestelmänä. Yksinkertainen tuoteluettelointegraatio synkronoi tuotetiedot, mutta se ei luonut luotettavaa polkua myyntimahdollisuuden sulkemisesta tilauksen hyväksymiseen, toimitukseen, asennukseen, laskutukseen ja uusimiseen.

Erilaisten tulomallien yhdistäminen

Yhden kaupan oli katettava kertamaksulliset laitteet, määräaikaiset ohjelmistotilaukset, jatkuva tuki, palvelut ja erilaiset laskutusvälit.

Konfigurointiriski

Komponenttien yhteensopivuutta ja toisistaan riippuvia määriä oli vaikea hallita luomatta satoja lähes identtisiä myyntinimikkeitä eli SKU-koodeja.

Erillään toimivat toteutusprosessit

Suljettu myyntimahdollisuus ei osoittanut, että SAP oli hyväksynyt tilauksen tai että varasto-, toimitus- ja asennustyöt olivat valmistuneet.

Asiakkuuden muutosten hajanainen käsittely

Uudet toimipisteet, päivitykset, peruutukset ja uusimiset käsiteltiin uutena myyntinä sen sijaan, että ne olisi käsitelty muutoksina olemassa oleviin laitteisiin ja tilauksiin.

Projektissa yhdistettiin siksi Salesforce-toteutus integraatioiden ja toimintamallin suunnitteluun. Tavoitteena ei ollut yksi yleiskäyttöinen päätietojärjestelmä vaan yksi määräävä vastuutaho kullekin tietoalueelle sekä hallittu elinkaaritapahtumien välitys.

Arkkitehtuuri: operatiivisiin toimintoihin yhdistetty kaupallinen kerros

Toteutimme Salesforce Agentforce Revenue Managementin kaupalliseksi kerrokseksi Salesforce Sales Cloudin päälle. SAP säilyi fyysisten tuotteiden perustietojen, hankintakustannusten, varaston, lähetysten ja kirjanpitotietojen määräävänä lähteenä. Ratkaisu yhdisti pilvipalvelujen ominaisuudet hämärtämättä myynnin, operatiivisen toteutuksen ja kirjanpidon välisiä rajoja.

1. Määritimme vastuut tietoalueittain

Aloitimme kenttätason vastuumallista. Synkronoidut kopiot sallittiin, mutta jokaisella arvolla säilyi yksi määräävä lähde. Yhteiset tunnisteet, voimaantulopäivät ja versiotiedot yhdistivät Salesforcen kaupallisen tarjonnan SAPin fyysiseen nimikkeeseen.

SAPin kustannustiedot synkronoitiin Salesforceen katelaskentaa varten, mutta niitä ei voinut muokata SAPin ulkopuolella. Tämä on sama vastuunjaon ensisijaisuuden periaate, jota sovellamme hallitussa SAPin ja Salesforcen integraatiossa.

2. Erotimme tuotteet myynti- ja laskutusmalleista

Kassapääte, kolmivuotinen ohjelmistotilaus ja vuosittainen tuki voivat olla samalla tarjouksella toimimatta samalla tavalla. Mallinsimme erikseen sen, mikä tuote on, miten se myydään ja miten se laskutetaan.

Tuotemalli

Fyysiset nimikkeet, ohjelmistot, palvelut, ominaisuudet, suhteet ja myöhemmissä prosessivaiheissa tarvittavat tunnisteet.

Myyntimalli

Kertaluonteiset tai määräaikaiset sitoumukset, mukaan lukien alkamis- ja päättymispäivät sekä uusimiskäytännöt.

Laskutusmalli

Laskutuksen ajankohta ja laskutusväli, jotka pidetään erillään kaupallisen sitoumuksen kestosta.

Tämän erottelun ansiosta laitemyynnin tuotot, jatkuvat tuotot, sopimuksen kokonaisarvo, tilauskaudet ja tulevat velvoitteet pysyivät näkyvissä ilman, että tuoteluetteloon piti luoda oma versio jokaiselle mahdolliselle kaupalliselle muunnelmalle.

3. Konfiguroimme kelvolliset ratkaisut ennen hinnoittelua

Täydellinen vähittäiskaupan ratkaisu saattoi sisältää kassapäätteen, skannerin, kuittitulostimen, maksupäätteen, kassaohjelmiston, varastonhallintatilauksen ja tuen. Kuvasimme ratkaisun tuotepakettien, tuoteominaisuuksien, yhteensopivuussääntöjen, pakollisten komponenttien, poissulkujen ja määrällisten riippuvuuksien avulla.

Advanced Configuratorin säännöt saattoivat edellyttää tiettyä komponenttia, estää mahdottoman yhdistelmän, piilottaa asiaankuulumattoman vaihtoehdon, näyttää tilanteeseen sopivan viestin tai vaikuttaa koko kauppaan. Valvontapiste sijoitettiin tarkoituksella varhaiseen vaiheeseen: virheellisen ratkaisun ei pitäisi koskaan edetä hinnoitteluun, sopimuksen tekemiseen, tilaamiseen tai tilauksen täyttämiseen.

Miksi tällä oli merkitystä

Konfigurointi ei ollut pelkästään myyjän käyttökokemusta parantava ominaisuus. Se hillitsi SKU-koodien määrän kasvua ja suojasi varasto- ja asennustiimejä vältettävissä olevilta poikkeustilanteilta prosessin myöhemmissä vaiheissa.

4. Keskitimme hinnoittelun ja otimme poikkeamat hallintaan

Mallinsimme hinnoittelumenettelyt ja hinnan oikaisut Salesforceen, jotta tuote, konfiguraatio, määrä, asiakassopimus, maa, tilauskausi ja kampanjaehdot voitiin huomioida johdonmukaisessa kaupallisessa lopputuloksessa. SAP toimitti ajantasaiset kustannustiedot katteen tarkastelua varten.

Erotimme myös lasketun hinnan myyjän pyytämästä alennuksesta. Hyväksyntäkäytännöillä voitiin näin arvioida alennusta, katetta, kaupan arvoa ja muita kaupallisia tekijöitä. Tavanomaiset kaupat etenivät ilman tarpeettomia väliintuloja, kun taas suuremmat poikkeamat ohjattiin asianmukaiselle myynnin, kaupallisen toiminnon tai taloushallinnon hyväksyjälle.

Nämä valvontamekanismit toteutettiin Salesforce Revenue Cloudin avulla osana laajempaa elinkaarta, ei erillisinä, vain tarjoukseen liitettyinä laskelmina.

5. Säilytimme kaupallisen tarkoituksen tilauksesta sen täyttämiseen

Tarjous sisälsi muutakin kuin määrän ja yksikköhinnan. Se säilytti päivämäärät, riippuvuudet, tilauksen täyttämistä koskevat vaatimukset, laskutusaikataulut ja uusimisvelvoitteet, jotta tilaus ja myöhempien prosessivaiheiden järjestelmät saattoivat toimia sopimuksen mukaisesti kokoamatta sitä uudelleen.

1. Konfiguroi kelvollinen laitteiden, ohjelmistojen, palvelujen ja tuen yhdistelmä.
2. Laske hinnat ja katteet ja ohjaa sitten hyväksyttäväksi vain määritetyt ehdot täyttävät poikkeamat.
3. Aktivoi tilaus, joka säilyttää sovitut ehdot, päivämäärät, määrät ja riippuvuudet.
4. Luo tilauksen täyttämissuunnitelma, tehtävät, välitavoitteet ja API-toiminnot Dynamic Revenue Orchestratorilla.
5. Anna SAPin hallita varastoa ja lähetyksiä sekä palauttaa tilatiedot Salesforceen.
6. Seuraa asennusta Salesforce Field Servicen avulla yhdessä tilauksen täyttämissuunnitelman muiden osien kanssa.

Dynamic Revenue Orchestrator antoi myynnille ja operatiivisille toiminnoille yhteisen näkymän työhön pakottamatta varastotiimejä pois SAPista. Myös toimitus säilyi erillisenä asennuksesta: laitteen vastaanottaminen ei tarkoittanut, että asiakas oli valmis käyttämään koko ratkaisua.

Toisena esimerkkinä Salesforcessa koordinoidusta operatiivisesta työstä voit lukea, miten asiakas yhdisti myynnin ja huollon toiminnan Sales Cloudin ja Field Servicen avulla.

6. Loimme laskut Salesforcessa ja hoidimme kirjanpidon SAPissa

Loimme Salesforce Billing Enginellä laskut sovittujen aikataulujen ja asiaankuuluvien operatiivisten välitavoitteiden perusteella. Laskutiedot siirtyivät sen jälkeen SAPiin kirjanpitoa varten, ja vastuunjako säilyi selkeänä: Salesforce hoiti kaupallisten laskujen luonnin, kun taas SAP ylläpiti kirjanpitotietoja.

Kaupallisen sitoumuksen yhdistäminen toimituksen ja laskutuksen välitavoitteisiin antoi myös taloushallinnolle vahvemman perustan määrittää, mitä oli myyty, toimitettu ja laskutettu ja mikä oli valmista sen tuloutusprosessiin. Toteutus ei korvannut kirjanpitoperiaatteita, eikä siinä väitetty, että pelkkä laskujen luominen tulouttaisi myynnin.

7. Teimme sopimusmuutoksista ja uusimisista osan arkkitehtuuria

Asiakassuhde jatkui ensimmäisen tilauksen jälkeen. Uusi myymälä, lisälaitteet, siirtyminen premium-tukeen, peruutus tai uusiminen muutti olemassa olevaa kaupallista kokonaisuutta.

Määritimme tapahtumien hallintaominaisuudet asiakkaan laitteiden ja tilausten ympärille. Tiimit pystyivät lähtemään liikkeelle siitä, mitä asiakas jo omisti, säilyttämään elinkaarihistorian ja tekemään sopimusmuutoksia, päivityksiä, peruutuksia ja uusimisia rakentamatta alkuperäistä kokoonpanoa uudelleen alusta asti.

Sama perusta voi myöhemmin tukea myös vaiheittain kasvavia sitoumuksia tai käyttöperusteisia maksuja, mutta käsittelimme niitä tulevina suunnittelumahdollisuuksina, joilla on omat mittaus-, hinnoittelu-, laskutus- ja kirjanpitovaatimuksensa – emme alkuperäisen toteutuksen automaattisina tuloksina.

Toteutuksesta opittua hybriditulomalleja varten

• Aloita liiketoiminnan elinkaaresta ja tietojen omistajuusmallista, älä yksittäisistä Salesforce-näkymistä.
• Määritä jokaiselle olennaiselle arvolle yksi ensisijainen omistaja ja varmista, etteivät synkronoidut kopiot toimi ensisijaisina tietolähteinä.
• Erota tuote-, myynti- ja laskutusmallit toisistaan, jotta laitteistot ja tilaukset voivat toimia rinnakkain ilman tuoteluettelon hallitsematonta paisumista.
• Estä virheelliset kokoonpanot ennen kuin ne aiheuttavat poikkeustilanteita hinnoittelussa, tilauksissa, varastossa tai asennuksissa.
• Säilytä päivämäärät, riippuvuudet, välitavoitteet ja velvoitteet jokaisessa siirrossa prosessin seuraavaan vaiheeseen.
• Suunnittele alkuperäinen myynti ja myynnin jälkeinen elinkaari yhdessä; sopimusmuutokset ja uusimiset eivät ole poikkeustapauksia.
• Pidä kaupallisen laskutuksen, operatiivisen toimituksen ja kirjanpidon vastuut selkeinä.

Aiheeseen liittyvä tapaustutkimus Salesforcen ja SAP:n tietojen synkronoinnista osoittaa, miksi ajantasaiset ERP-tiedot ja luotettava omistajuus ovat prosessin myöhempien vaiheiden automatisoinnin edellytyksiä.

Toteutus toimi yhtenäisenä tulonmuodostuksen arkkitehtuurina: tuotemallinnus ohjasi kokoonpanon määritystä, kokoonpano hinnoittelua ja tarjous tilausta ja toimitusta. Laskutus noudatti kaupallisia ehtoja ja välitavoitteita, ja asiakkaan laitteet ohjasivat kaikkia myöhempiä muutoksia.