Vartojimo apskaita ir kainodara: inžinerija prieš finansus

Įvadas

Naudojimu pagrįstas ir mišrus kainodaros modelis retai būna nekintamas. Kai kainodaros logika yra kietai užkoduota, kiekvienas pakopos ar kredito limito pakeitimas virsta techniniu užklausimu. Tai lėtina finansų skyrių darbą ir kelia nepasitenkinimą programuotojams. Taigi, kas turėtų būti atsakingas už naudojimo matavimą ir ant jo pagrįstą kainodarą? Paaiškinkime tai.

Kodėl kainodaros pokyčiai dabar yra tokie dažni

Kainodara nebėra sprendimas, kurį nustatęs gali pamiršti. Konsultacinės įmonės „hy“ ir „OMR Reviews“ parengtoje „SaaS ir AI kainodaros ataskaitoje“, remiantis „Growth Unhinged“ duomenimis, teigiama, kad trys iš keturių JAV programinės įrangos įmonių per pastaruosius metus pakeitė savo kainodarą. Tai didžiulis pokytis.

Keičiasi ir modeliai. „hy“ atliktoje 180 programinės įrangos įmonių apklausoje paaiškėjo, kad 37 % jau naudoja naudojimu pagrįstus modelius, o 59 % derina daugiau nei vieną kainodaros rodiklį, pavyzdžiui, apmokėjimą už kiekvieną vartotoją kartu su API apimtimi. Pridėkite kreditus, atlikite eksperimentus, patobulinkite paslaugų paketus – ir pokyčiai tampa norma, o ne išimtimi.

Kaip kainodaros logika galiausiai tampa inžinierių kompetencija

Paprastai tai įvyksta atsitiktinai. Iš pradžių programuotojas koduoja rodiklį: suskaičiuoja API iškvietimus, taiko tarifą, o bendrą sumą įtraukia į sąskaitą. Tai veikia, todėl niekas to nekvestionuoja.

Vėliau kainodara keičiasi. Naujas lygis, nemokama kvota ar kitoks viršijimo tarifas reiškia, kad kažkas pateikia užklausą, laukia sprinto laiko tarpo ir tikisi, kad naujoji versija nesutrikdys sąskaitų išrašymo. Vykdymo laikas pailgėja, o kiekviena nauja versija kelia tam tikrą riziką. Finansų skyrius galiausiai atsiduria eilėje, kurios jis nekontroliuoja.

Hibridiniai modeliai šią situaciją dar labiau pablogina. Kuo daugiau komponentų sudaro kaina, tuo daugiau vietų kode gali pasislėpti pokyčiai.

Inžinierių nustatytų kainų kaina

Šios išlaidos yra realios, net jei jų neįrodo jokia skaičiuoklė.

• Lėtas įgyvendinimas: kainodaros idėja gali savaitėmis laukti, kol bus atliktas produktų kūrimo darbas.
• Klaidos: logika, paslėpta kodo gilumoje, finansų skyriui yra sunku suprasti, todėl sąskaitose dažnai atsiranda klaidų.
• Finansų skyriaus „aklosios zonos“: jei finansų skyrius negali pamatyti, kaip buvo apskaičiuotas skaičius, ginčų sprendimas užtrunka ilgiau.
• Alternatyviosios sąnaudos: inžinieriai prižiūri apskaitos kodą, o ne kuria produktą.

Štai mano nuomonė: jei kainos pakeitimui reikia diegti kodą, jūsų kainodara juda pagal jūsų išleidimo kalendoriaus tempą, o ne pagal rinkos tempą

Už ką turėtų būti atsakingas finansų skyrius, o už ką – inžinerijos skyrius

Atsakomybė nėra „vienas arba kitas“. Padalinkite ją pagal sprendimo tipą.

Inžinerijos skyrius yra atsakingas už įvykių stebėjimą, duomenų srautus ir naudojimo duomenų tikslumą šaltinyje.

Finansų ir produktų komandos yra atsakingos už rodiklių apibrėžimus, kainų taškus, paketų sudėtį ir kreditus.

Štai paprastas testas. Jei pokytis susijęs su tuo, kas fiksuojama, jis priklauso inžinerijos skyriui. Jei jis susijęs su tuo, kaip užfiksuotas naudojimas paverčiamas pinigais, jis priklauso finansų ir produktų skyriams. Pavyzdžiui, sprendimas, kad planas apima 1 500 API iškvietų vietoj 1 000, yra kainodaros sprendimas. Užtikrinti, kad kiekviena iškvieta būtų užregistruota tiksliai vieną kartą, yra inžinerijos užduotis.

Kainodaros pokyčių valdymas

Kontrolės perdavimas be apsauginių priemonių sukelia chaosą. Tai yra bendrosios gerosios praktikos, nesusijusios su jokiu konkrečiu įrankiu:

• Patvirtinimai: prieš įgyvendinant pakeitimus, būtina gauti finansų ir produkto skyrių vadovų patvirtinimą.
• Testavimas: prieš įdiegimą peržiūrėkite poveikį realiems naudojimo duomenims.
• Versijų valdymas: kiekvieną kainodaros konfigūraciją tvarkykite versijomis, kad galėtumėte lyginti versijas arba grįžti prie ankstesnės versijos.
• Įsigaliojimo datos: Nustatykite, kada pakeitimas įsigalioja ir kaip traktuojami jau užregistruoti naudojimo duomenys ciklo viduryje.
• Audito seka: užfiksuokite, kas, ką ir kada pakeitė.

Laikykite tai kainodaros kodo peržiūra. Niekas neišleidžia kodo be antros poros akių, ir kainoms reikia tokio paties dėmesio.

Finansų skyriaus vadovaujamo kainodaros nustatymo prielaidos

Finansų skyrius negali valdyti to, kuo negali pasitikėti. Pirmiausia reikalingi trys pagrindai.

Tikslūs naudojimo duomenys. Pasikartojantys arba trūkstami įvykiai pakenks bet kokiai kainai, kurią nustatysite remdamiesi jais.

Sutartos rodiklių apibrėžtys. Jei produktų skyrius „aktyvų vartotoją“ apibrėžia vienaip, o finansų skyrius – kitaip, jūsų sąskaitos už jus išspręs šį ginčą, ir ne pačiu maloniausiu būdu.

Patikimi šaltiniai. Naudojimo duomenys paprastai saugomi duomenų saugykloje, už API arba failuose. Pasirinkite vieną duomenų registravimo sistemą kiekvienam rodikliui ir laikykitės jos.

Klausimai, kuriuos reikia užduoti prieš perkeliant atsakomybę už kainodarą

Suburkite finansų direktorių, produkto vadovą ir inžinerijos vadovą į vieną kambarį ir aptarkite šiuos klausimus:

1. Kokius kainodaros pakeitimus atlikome pernai ir kiek laiko užtruko kiekvieno iš jų įdiegimas?
2. Ar kiekvienam apmokestinamam rodikliui yra nustatyta viena sutarta apibrėžtis?
3. Ar finansų skyrius gali atsekti, kaip naudojimo rodiklis tapo sąskaitos eilute?
4. Kas tvirtina pakeitimą ir kaip jį išbandome prieš įdiegiant?
5. Kur saugomi naudojimo duomenys ir kas atsakingas už jų tikslumą?

Jei negalite atsakyti į du ar tris iš šių klausimų, tai yra jūsų išeities taškas.

Kainodaros keitimas neperkuriant naudojimo matavimo

Čia gali padėti įrankiai. Remiantis „Zenskar“ puslapiu „Naudojimo matavimas“, komandos gali apibrėžti apmokestinamus rodiklius paprasta kalba ir leisti dirbtiniam intelektui (AI) parašyti agregavimo logiką arba parašyti individualų SQL kodą sudėtingai logikai. Naudojimo duomenys gali būti gaunami iš šaltinių, tokių kaip „Postgres“, „Athena“ ir „MySQL“, perduodami per API arba įkelti kaip CSV failas. Tas pats rodiklis gali būti pakartotinai naudojamas skirtinguose produktuose, sutartyse ir sąskaitos eilutėse.

Svarbiausia nuosavybės atžvilgiu yra tai, kad naudojimu pagrįsta apskaitos programinė įranga turėtų leisti keisti tarifų pakopas, viršijimo mokesčius ir apskaitos dažnumą nepriklausomai nuo naudojimo. Apskaitos logiką taip pat galima modifikuoti ciklo viduryje, netrikdant duomenų srauto. Vienas rodiklis gali palaikyti skirtingus kainodaros modelius skirtingose sutartyse, užtikrinant pastovią apskaitą, o kainodara – toliau vystosi.

Išvada

Sveikiausias modelis yra bendras. Inžinieriai užtikrina, kad naudojimo duomenys būtų tikslūs ir nuolat teikiami. Finansų ir produktų skyriai, laikydamiesi aiškių valdymo taisyklių, nustato tų duomenų vertę. Koks kainodaros pakeitimas šiuo metu laukia jūsų inžinierių eilėje?

Pagrindinės išvados:

• Kietai užkoduotas kainodaros modelis paverčia kiekvieną pakopos ar kredito koregavimą inžineriniu užklausimu.
• Pasiskirstykite atsakomybę pagal sprendimų tipą: inžinieriai atsako už naudojimo duomenų surinkimą ir tikslumą, o finansų ir produktų skyriai – už rodiklių apibrėžimus, kainas, paketus ir kreditus.
• Pirmiausia įdiekite apsaugos priemones: patvirtinimus, testavimą, versijų valdymą, įsigaliojimo datas ir audito seką.
• Finansų skyriaus vadovaujamam kainodaros nustatymui reikalingi aiškūs naudojimo duomenys, suderinti rodiklių apibrėžimai ir viena duomenų registravimo sistema kiekvienam rodikliui.
• Naudokite penkis klausimus prieš perdavimą, kad nustatytumėte savo pradinį tašką.
• Pasirinkite įrankius, leidžiančius keisti kainodarą be matavimo sistemos pertvarkymo.