Tarbimise mõõtmine ja hinnakujundus: inseneriteadus vs rahandus

Sissejuhatus

Kasutamisel põhinev ja hübriidne hinnakujundus on harva staatiline. Kui hinnakujunduse loogika on koodi sisse kirjutatud, muutub iga taseme või krediidilimiidi muudatus tehniliseks probleemiks. See on aeglane finantsosakonnale ja frustreeriv arendajatele. Kes peaks siis vastutama kasutuse mõõtmise ja sellele tugineva hinnakujunduse eest? Selgitame seda välja.

Miks hinnamuutused on nüüd sagedased

Hinnakujundus ei ole enam otsus, mille saab kord paika panna ja unustada. Konsultatsioonifirma hy ja OMR Reviewsi koostatud SaaS-i ja tehisintellekti hinnakujunduse aruanne, mis viitab Growth Unhingedi andmetele, näitab, et kolm neljandikku USA tarkvaraettevõtetest muutis viimase aasta jooksul oma hinnakujundust. See on suur muutus.

Ka hinnamudelid on muutumas. hy uuringus, milles osales 180 tarkvaraettevõtet, kasutab 37% juba kasutamisel põhinevaid mudeleid ja 59% kombineerib rohkem kui ühte hinnamõõdikut, näiteks kasutajapõhist arveldust koos API-kasutuse mahuga. Lisage krediite, tehke katseid, kohandage pakette – ja muutused muutuvad pigem normiks kui erandiks.

Kuidas hinnakujunduse loogika satub inseneride kätte

See juhtub tavaliselt juhuslikult. Alguses programmeerib arendaja näitaja koodi sisse: loendatakse API-kõnesid, rakendatakse tariifi ja saadetakse kogusumma arvele. See toimib, seega keegi seda ei sea kahtluse alla.

Siis hindade kujundamine areneb edasi. Uus tasem, tasuta kvoot või teistsugune ületamise määr tähendab, et keegi esitab pileti, ootab sprindi aega ja loodab, et uus versioon ei häiri arveldamist. Täitmisaeg venib ja iga versiooni väljalaskmine toob endaga kaasa teatud riski. Rahandusosakond satub ootama järjekorda, mida ta ei kontrolli.

Hübriidmudelid muudavad olukorra veelgi halvemaks. Mida rohkem komponente hinnal on, seda rohkem kohti võib muutus koodis peituda.

Inseneride poolt määratud hinnakujunduse maksumus

Kulud on reaalsed, isegi kui neid ei tõenda ükski arvutustabel.

• Aeglane käivitamine: hinnakujunduse idee võib jääda tootearenduse tööst nädalateks maha.
• Vead: Koodi sisse peidetud loogikat on rahandusosakonnal raske lugeda, mistõttu ilmnevad vead sageli arvetel.
• Rahandusosakonna pimedad kohad: kui rahandusosakond ei näe, kuidas number arvutati, võtab vaidluste lahendamine kauem aega.
• Alternatiivkulu: insenerid hooldavad arvelduskoodi selle asemel, et toodet arendada.

Minu seisukoht on järgmine: kui hinnamuutus nõuab koodi kasutuselevõttu, liigub teie hinnakujundus versioonikalendri kiirusel, mitte turu kiirusel

Mida peaks haldama rahandusosakond ja mida inseneriosakond

Vastutus ei ole kas-või-küsimus. Jagage see otsuste tüübi järgi.

Inseneriosakond vastutab sündmuste jälgimise, andmevoogude ja kasutamisandmete täpsuse eest allikas.

Rahandusosakond ja tootearendus vastutavad näitajate määratluste, hinnatasemete, pakettide ja krediitideeest.

Siin on lihtne test. Kui muudatus puudutab seda, mida kogutakse, kuulub see inseneriosakonna vastutusalasse. Kui see puudutab seda, kuidas kogutud kasutamisandmed rahaks muundatakse, kuulub see rahandus- ja tootearendusosakonna vastutusalasse. Näiteks otsus, et pakett sisaldab 1 500 API-kõnet 1 000 asemel, on hinnakujundusega seotud otsus. Iga kõne täpse ühekordse registreerimise tagamine on inseneriosakonna ülesanne.

Hinnamuutuste juhtimine

Kontrolli üleandmine ilma piiranguteta kutsub esile kaose. Need on üldised parimad tavad, mis ei ole seotud ühegi konkreetse tööriistaga:

• Heakskiitmine: enne muudatuse kasutuselevõttu on vaja rahandusosakonna ja tootearenduse nimelist heakskiitu.
• Testimine: Enne kasutuselevõttu tuleb eelvaatena kontrollida mõju tegelikele kasutamisandmetele.
• Versioonihaldus: hoidke iga hinnakonfiguratsiooni versioonina, et saaksite versioone võrrelda või tagasi pöörduda.
• Jõustumiskuupäevad: määrake kindlaks, millal muudatus jõustub ja kuidas käsitletakse tsükli keskel juba registreeritud kasutust.
• Auditeerimisjälg: Registreerige, kes, mida ja millal muutis.

Mõelge sellele kui hinnakujunduse koodiülevaatusele. Keegi ei lase koodi välja ilma teise paari silmadeta, ja hinnad väärivad sama hoolt.

Finantsosakonna juhitud hinnakujunduse eeltingimused

Rahandusosakond ei saa omada seda, millesse ta ei saa usaldada. Esikohal on kolm alustala.

Puhas kasutamisandmestik. Duplikaadid või puuduvad sündmused õõnestavad iga hinna, mille nende põhjal kehtestate.

Kokkulepitud mõõdikute määratlused. Kui tootearendus määratleb „aktiivse kasutaja” ühel viisil ja rahandusosakond teisel, lahendavad teie arved selle vaidluse teie eest – ja mitte just sõbralikult.

Usaldusväärsed allikad. Kasutamisandmed asuvad tavaliselt andmehoidlas, API taga või failides. Valige iga mõõdiku jaoks üks registreerimissüsteem ja pidage sellest kinni.

Küsimused, mida küsida enne hinnakujunduse vastutuse üleandmist

Kutsu finantsjuht, tootearenduse juht ja tehnilise osakonna juht ühte ruumi kokku ja arutage läbi järgmised küsimused:

1. Milliseid hinnamuudatusi tegime eelmisel aastal ja kui kaua võttis iga muudatuse kasutuselevõtt aega?
2. Kas igal arveldataval näitajal on üks kokkulepitud määratlus?
3. Kas rahandusosakond suudab jälgida, kuidas kasutamisnäitaja muutus arve real olevaks andmeks?
4. Kes kiidab muudatuse heaks ja kuidas me seda enne kasutuselevõttu testime?
5. Kus asuvad kasutamisandmed ja kes vastutab nende täpsuse eest?

Kui te ei suuda vastata kahele või kolmele neist küsimustest, on see teie lähtepunkt.

Hindade muutmine ilma mõõtmise ümberkorraldamiseta

Siin võivad abiks olla tööriistad. Zenskar’i kasutuse mõõtmise lehekülje kohaselt saavad meeskonnad määratleda arveldatavad näitajad lihtsas keeles ja lasta tehisintellektil kirjutada koondamislogiika või kirjutada keerulise loogika jaoks kohandatud SQL-koodi. Kasutust saab hankida allikatest nagu Postgres, Athena ja MySQL, edastada API kaudu või laadida üles CSV-failina. Sama näitajat saab korduvalt kasutada erinevate toodete, lepingute ja kirjetega.

Omandiõiguse seisukohalt on oluline, et kasutamisel põhinev arveldustarkvara võimaldaks tasemeid, ületamisi ja arveldusperioodi muuta kasutamisest sõltumatult. Arveldusloogikat saab muuta ka tsükli keskel, ilma et see häiriks andmevoogu. Üksainus näitaja võib toetada erinevaid hinnamudeleid erinevates lepingutes, hoides arvestuse stabiilsena, samal ajal kui hinnakujundus areneb.

Kokkuvõte

Kõige tervem mudel on jagatud mudel. Arendajad tagavad kasutamisandmete täpsuse ja voolu. Rahandus- ja tootemeeskond vastutavad selge juhtimiskorra raames selle eest, milline on nende andmete väärtus. Milline hinnamuutus ootab praegu teie arendajate järjekorras?

Peamised järeldused:

• Koodis fikseeritud hinnakujundus muudab iga taseme või krediidi muudatuse tehniliseks päringuks.
• Jagage vastutus otsustüübi järgi: tehniline osakond vastutab kasutamisandmete kogumise ja täpsuse eest, samas kui rahandus- ja tootearendusosakond vastutavad näitajate määratluste, hinnapunktide, pakettide ja krediitide eest.
• Kehtestage esmalt kaitsemeetmed: heakskiitmine, testimine, versioonihaldus, jõustumiskuupäevad ja auditeerimisjälg.
• Rahandusosakonna juhitud hinnakujundus vajab puhtaid kasutamisandmeid, kokkulepitud mõõdikute määratlusi ja ühte registreerimissüsteemi iga mõõdiku kohta.
• Kasutage viit üleandmisele eelnevat küsimust, et leida oma lähtepunkt.
• Valige tööriistad, mis võimaldavad hindu muuta ilma mõõtmissüsteemi ümber ehitamata.