Patēriņa uzskaite un cenu noteikšana: inženierzinātnes pret finansēm

Ievads

Lietošanas apjoma un hibrīdā cenu noteikšana reti kad ir nemainīga. Ja cenu noteikšanas loģika ir stingri ieprogrammēta, katrs līmeņa vai kredītlimita pielāgojums kļūst par tehnisko uzdevumu. Tas ir lēns process finanšu nodaļai un rada neapmierinātību izstrādātājiem. Tātad, kam būtu jāatbild par lietošanas apjoma uzskaiti un uz tās balstīto cenu noteikšanu? Izskatīsim šo jautājumu.

Kāpēc cenu izmaiņas tagad notiek bieži

Cenu noteikšana vairs nav lēmums, ko var pieņemt vienreiz un par to vairs nedomāt. Konsultāciju uzņēmuma „hy” un „OMR Reviews” izstrādātajā „SaaS & AI Pricing Report” ziņojumā, atsaucoties uz „Growth Unhinged” datiem, teikts, ka trīs no četriem ASV programmatūras uzņēmumiem pēdējā gada laikā ir mainījuši savas cenas. Tas ir ievērojams pārmaiņu apjoms.

Mainās arī modeļi. „hy“ veiktajā aptaujā, kurā piedalījās 180 programmatūras uzņēmumi, 37 % jau izmanto uz lietošanu balstītus modeļus, bet 59 % apvieno vairākus cenu noteikšanas rādītājus, piemēram, norēķinus par katru lietotāju kopā ar API apjomu. Pievienojiet kredītus, veiciet eksperimentus, pielāgojiet pakalpojumu komplektus, un izmaiņas kļūst par normu, nevis izņēmumu.

Kā cenu noteikšanas loģika nonāk inženieru pārziņā

Parasti tas notiek nejauši. Sākumā izstrādātājs programmā ieprogrammē rādītāju: skaita API izsaukumus, piemēro likmi, nosūta kopējo summu rēķinam. Tas darbojas, tāpēc neviens to neapšauba.

Tad cenu noteikšana attīstās. Jauns līmenis, bezmaksas kvota vai atšķirīga pārsnieguma likme nozīmē, ka kāds iesniedz pieprasījumu, gaida sprinta laiku un cer, ka jaunā versija netraucēs rēķinu izrakstīšanu. Izpildes laiks pagarinās, un katrai jaunajai versijai ir zināms risks. Finanšu nodaļa beigās gaida rindā, kuru tā nekontrolē.

Hibrīdmodeļi šo situāciju vēl vairāk pasliktina. Jo vairāk komponentu veido cenu, jo vairāk vietu kodā var paslēpties izmaiņas.

Inženieru pārvaldītas cenu noteikšanas izmaksas

Izmaksas ir reālas, pat ja nav izklājlapas, kas tās pierāda.

• Lēna ieviešana: Cenu noteikšanas ideja var nedēļām ilgi palikt produktu izstrādes darba ēnā.
• Kļūdas: loģika, kas paslēpta kodā, finanšu nodaļai ir grūti izlasāma, tāpēc rēķinos bieži parādās kļūdas.
• Finanšu neredzamās zonas: ja finanšu nodaļa neredz, kā ir aprēķināts konkrētais skaitlis, strīdu atrisināšana aizņem vairāk laika.
• Alternatīvās izmaksas: inženieri uztur rēķinu kodu, nevis izstrādā produktu.

Šeit ir mans viedoklis: ja cenu izmaiņām ir nepieciešama koda ieviešana, jūsu cenu noteikšana notiek atbilstoši jūsu izlaides kalendāram, nevis tirgus tempam

Kas jāpieder finanšu nodaļai un kas — inženieru nodaļai

Atbildība nav „vai nu viens, vai otrs”. To vajadzētu sadalīt atbilstoši lēmuma veidam.

Inženieru nodaļai pieder notikumu instrumentācija, datu plūsmas un izmantošanas datu precizitāte avotā.

Finanšu un produktu nodaļām pieder rādītāju definīcijas, cenu līmeņi, pakalpojumu komplekti un kredīti.

Šeit ir vienkāršs tests. Ja izmaiņas attiecas uz to, kas tiek reģistrēts, tās ir inženierijas nodaļas kompetencē. Ja tās attiecas uz to, kā reģistrētā izmantošana tiek pārvērsta naudā, tās ir finanšu un produktu nodaļas kompetencē. Piemēram, lēmums, ka plānā ir iekļauti 1 500 API izsaukumi, nevis 1 000, ir lēmums par cenu. Savukārt pārliecināšanās, ka katrs izsaukums tiek reģistrēts tieši vienu reizi, ir inženierijas nodaļas uzdevums.

Cenu izmaiņu pārvaldība

Kontrolēšanas nodošana bez drošības pasākumiem rada haosu. Šie ir vispārīgi labākās prakses piemēri, kas nav saistīti ar kādu konkrētu rīku:

• Apstiprinājumi: Pirms izmaiņu ieviešanas ir nepieciešams konkrētu finanšu un produktu nodaļu pārstāvju apstiprinājums.
• Testēšana: Pirms izmaiņu ieviešanas pārbaudiet to ietekmi, izmantojot reālos lietošanas datus.
• Versiju pārvaldība: Katrai cenu konfigurācijai jābūt versijām, lai varētu salīdzināt versijas vai atgriezties pie iepriekšējās versijas.
• Spēkā stāšanās datumi: noteikt, kad izmaiņas stājas spēkā un kā tiek apstrādāti lietošanas dati, kas jau reģistrēti cikla vidū.
• Revīzijas izsekojamība: reģistrējiet, kurš, ko un kad ir mainījis.

Uztveriet to kā cenu noteikšanas koda pārskatīšanu. Neviens neizlaiž kodu bez otrā pāra acu pārbaudes, un cenām ir nepieciešama tāda pati rūpība.

Priekšnosacījumi finanšu vadītai cenu noteikšanai

Finanšu nodaļa nevar pārvaldīt to, kam nevar uzticēties. Pirmkārt ir nepieciešami trīs pamati.

Tīri lietošanas dati. Dublētie vai trūkstošie notikumi grauj jebkuru cenu, ko jūs tiem noteicat.

Saskaņotas metriku definīcijas. Ja produktu nodaļa definē „aktīvo lietotāju” vienā veidā, bet finanšu nodaļa — citā, jūsu rēķini atrisinās šo strīdu jūsu vietā, un ne visai laipni.

Uzticami avoti. Lietošanas dati parasti atrodas datu noliktavā, aiz API vai failos. Izvēlieties vienu reģistrācijas sistēmu katram rādītājam un pieturieties pie tās.

Jautājumi, kas jāuzdod, pirms pārdodat atbildību par cenu noteikšanu

Aiciniet finanšu direktoru, produktu vadītāju un inženierijas vadītāju vienā telpā un pārrunājiet šos jautājumus:

1. Kādas cenu izmaiņas mēs veicām pagājušajā gadā un cik ilgs laiks bija nepieciešams, lai katru no tām ieviestu?
2. Vai katram rēķinājamajam rādītājam ir viena saskaņota definīcija?
3. Vai finanšu nodaļa var izsekot, kā lietošanas rādītājs kļuva par rēķina pozīciju?
4. Kas apstiprina izmaiņas un kā mēs tās pārbaudām, pirms tās tiek ieviestas?
5. Kur tiek glabāti lietošanas dati un kurš ir atbildīgs par to precizitāti?

Ja nevarat atbildēt uz diviem vai trim no šiem jautājumiem, tas ir jūsu sākumpunkts.

Cenu maiņa bez mērīšanas sistēmas pārveidošanas

Šeit var palīdzēt atbilstoši rīki. Saskaņā ar Zenskar lietojuma mērīšanas lapu komandas var definēt rēķināmos rādītājus vienkāršā valodā un ļaut mākslīgajam intelektam izstrādāt apkopošanas loģiku vai arī rakstīt pielāgotu SQL kodu sarežģītai loģikai. Lietojuma datus var iegūt no avotiem, piemēram, Postgres, Athena un MySQL, nosūtīt caur API vai augšupielādēt CSV formātā. Vienu un to pašu rādītāju var atkārtoti izmantot dažādiem produktiem, līgumiem un pozīcijām.

No īpašnieka viedokļa svarīgi ir tas, ka uz lietošanu balstītai rēķinu izrakstīšanas programmatūrai jāļauj mainīt līmeņus, pārsniegumus un rēķinu izrakstīšanas periodiskumu neatkarīgi no lietošanas apjoma. Rēķinu izrakstīšanas loģiku var mainīt arī cikla vidū, netraucējot datu plūsmu. Viens rādītājs var nodrošināt dažādus cenu noteikšanas modeļus dažādos līgumos, saglabājot stabilu uzskaiti, kamēr cenas mainās.

Secinājums

Vislabākais modelis ir kopīgs. Inženieru komanda nodrošina izmantošanas datu precizitāti un plūsmu. Finanšu un produktu komandas nosaka šo datu vērtību saskaņā ar skaidriem pārvaldības noteikumiem. Kādas cenu izmaiņas šobrīd gaida jūsu inženieru komandas darba rindā?

Galvenie secinājumi:

• Cietkodēta cenu noteikšana pārvērš katru līmeņa vai kredīta korekciju par inženierijas pieprasījumu.
• Sadali atbildību atbilstoši lēmuma veidam: inženieru nodaļa atbild par lietošanas datu ieguvi un precizitāti, savukārt finanšu un produktu nodaļas atbild par rādītāju definīcijām, cenu līmeņiem, pakalpojumu komplektiem un kredītiem.
• Vispirms ieviesiet drošības pasākumus: apstiprināšanu, testēšanu, versiju pārvaldību, spēkā stāšanās datumus un revīzijas izsekojamību.
• Finanšu vadītai cenu noteikšanai ir nepieciešami precīzi lietošanas dati, saskaņotas metriku definīcijas un viena reģistrācijas sistēma katrai metrikai.
• Izmantojiet piecus jautājumus pirms nodošanas, lai atrastu savu sākuma punktu.
• Izvēlieties rīkus, kas ļauj mainīt cenas, nepārveidojot uzskaites sistēmu.