Uvod
Cenovne politike, ki temeljijo na porabi, in hibridne cenovne politike so redko statične. Ko je logika oblikovanja cen trdno zakodirana, se vsaka sprememba stopnje ali kreditnega limita spremeni v tehnično zahtevo. To upočasnjuje delo finančnega oddelka in je frustrirajoče za razvijalce. Kdo naj torej skrbi za merjenje porabe in cenovno politiko, ki temelji na njej? Razjasnimo to.
Zakaj so spremembe cen zdaj pogoste
Cenovno oblikovanje ni več odločitev, ki jo enkrat določiš in nato pozabiš. Poročilo o cenah SaaS in AI, ki sta ga pripravila svetovalno podjetje hy in OMR Reviews ter se sklicujeta na podatke Growth Unhinged, navaja, da so tri od štirih ameriških podjetij za programsko opremo v zadnjem letu spremenila svoje cene. To je veliko gibanja.
Spreminjajo se tudi modeli. V raziskavi podjetja hy, v kateri je sodelovalo 180 podjetij za programsko opremo, 37 % že uporablja modele, ki temeljijo na porabi, 59 % pa kombinira več kot eno merilo za določanje cen, na primer zaračunavanje na uporabnika skupaj z obsegom API-ja. Dodajanje kreditov, izvajanje poskusov, prilagajanje paketov – spremembe postajajo pravilo in ne izjema.
Kako logika oblikovanja cen konča v rokah inženirjev
Ponavadi se to zgodi po naključju. Na začetku razvijalec trdno zakodira merilo: prešteje API-klice, uporabi ceno, skupni znesek pa pošlje na račun. Deluje, zato tega nihče ne dvomi.
Nato se oblikovanje cen razvija. Nova stopnja, brezplačni dodatek ali drugačna stopnja za prekoračitev pomeni, da nekdo odpre zahtevek, čaka na prosto mesto v sprintu in upa, da izdaja ne bo motila zaračunavanja. Čas izvedbe se podaljšuje, vsaka izdaja pa prinaša določeno tveganje. Finančni oddelek na koncu čaka v vrsti, nad katero nima nadzora.
Hibridni modeli to še poslabšajo. Več komponent ima cena, več mest v kodi se lahko skriva sprememba.
Stroški cenovne politike, ki jo določa inženiring
Stroški so resnični, tudi brez preglednice, ki bi jih dokazovala.
- Počasni uvodi: Ideja o cenah lahko tedne čaka v ozadju razvoja izdelka.
- Napake: Logika, zakopana v kodi, je za finančno službo težko berljiva, zato se napake pogosto pojavijo na računih.
- Slepe točke finančnega oddelka: Če finančni oddelek ne more videti, kako je bila izračunana številka, traja reševanje sporov dlje.
- Alternativni stroški: Inženirji vzdržujejo kodo za zaračunavanje namesto da bi razvijali izdelek.
Tukaj je moje mnenje: če sprememba cene zahteva razporeditev kode, se vaše oblikovanje cen giblje s hitrostjo vašega koledarja izdaj, ne pa s hitrostjo vašega trga
Kaj naj bo v pristojnosti finančnega oddelka in kaj v pristojnosti inženirskega oddelka
Odgovornost ni izključujoča. Razdelite jo glede na vrsto odločitve.
Inženiring je odgovoren za instrumentacijo dogodkov, podatkovne poti in točnost podatkov o uporabi pri viru.
Finančni oddelek in oddelek za izdelke sta odgovorna za opredelitve kazalnikov, cenovne točke, pakete in kredite.
Platforma "vse v enem" za učinkovito SEO
Za vsakim uspešnim podjetjem stoji močna kampanja SEO. Vendar je ob neštetih orodjih in tehnikah optimizacije težko vedeti, kje začeti. Ne bojte se več, ker imam za vas prav to, kar vam lahko pomaga. Predstavljam platformo Ranktracker vse-v-enem za učinkovito SEO
Končno smo odprli registracijo za Ranktracker popolnoma brezplačno!
Ustvarite brezplačen računAli se prijavite s svojimi poverilnicami
Tukaj je preprost test. Če sprememba zadeva to, kaj se zajema, sodi v pristojnost inženiringa. Če zadeva to, kako se zajeta uporaba pretvori v denar, sodi v pristojnost finančnega oddelka in oddelka za izdelke. Na primer, odločitev, da paket vključuje 1.500 API-klicev namesto 1.000, je odločitev o cenah. Zagotavljanje, da se vsak klic zabeleži natanko enkrat, je naloga inženiringa.
Upravljanje sprememb cen
Predaja nadzora brez varnostnih ograj vodi v kaos. To so splošne najboljše prakse, ki niso vezane na nobeno posamezno orodje:
- Odobritve: Pred uvedbo spremembe v produkcijo je potrebno pridobiti podpis odgovorne osebe iz finančnega oddelka in oddelka za izdelek.
- Testiranje: Pred uvedbo si oglejte vpliv na dejanske podatke o uporabi.
- Različice: Vsaki konfiguraciji cen dodajte različico, da lahko primerjate različice ali se vrnete na prejšnjo različico.
- Datumi veljavnosti: Določite, kdaj sprememba začne veljati in kako se obravnava uporaba, ki je bila zabeležena že sredi cikla.
- Revizijska sled: Zabeležite, kdo je kaj spremenil in kdaj.
Razmišljajte o tem kot o pregledu kode za oblikovanje cen. Nihče ne objavi kode brez drugega para oči, in cene si zaslužijo enako pozornost.
Predpogoji za oblikovanje cen pod vodstvom finančnega oddelka
Finančni oddelek ne more prevzeti odgovornosti za tisto, čemur ne more zaupati. Na prvem mestu so trije temelji.
Čisti podatki o uporabi. Podvojeni ali manjkajoči dogodki spodkopavajo vsako ceno, ki jo določite na njihovi podlagi.
Dogovorjene definicije kazalnikov. Če oddelek za izdelke opredeli »aktivnega uporabnika« na en način, oddelek za finance pa na drug način, bodo vaše fakture rešile spor namesto vas – in to na neprijazen način.
Zanesljivi viri. Podatki o uporabi so običajno shranjeni v podatkovnem skladišču, za API-jem ali v datotekah. Izberite en sistem evidentiranja za vsak kazalnik in se ga držite.
Vprašanja, ki jih je treba zastaviti pred prenosom odgovornosti za določanje cen
Zberite finančnega direktorja, vodjo oddelka za izdelke in vodjo inženiringa v eni sobi ter skupaj obravnavajte naslednje:
- Katere spremembe cen smo uvedli lani in koliko časa je trajalo, da je bila vsaka od njih uvedena?
- Ali ima vsak zaračunljiv kazalnik eno dogovorjeno definicijo?
- Ali lahko finančna služba sledi, kako je podatek o porabi postal postavka na računu?
- Kdo odobri spremembo in kako jo preizkusimo, preden začne veljati?
- Kje se nahajajo podatki o porabi in kdo je odgovoren za njihovo točnost?
Če ne morete odgovoriti na dve ali tri od teh vprašanj, je to vaša izhodiščna točka.
Sprememba cen brez prenove merjenja
Tu lahko pomagajo orodja. Glede na stran Zenskarja o merjenju porabe lahko ekipe opredelijo merila za zaračunavanje v preprostem jeziku in pustijo, da umetna inteligenca napiše logiko agregacije, ali pa za kompleksno logiko napišejo prilagojeno kodo SQL. Podatke o porabi je mogoče pridobiti iz virov, kot so Postgres, Athena in MySQL, jih posredovati prek API-ja ali naložiti kot CSV. Enako merilo je mogoče ponovno uporabiti za različne izdelke, pogodbe in postavke.
Za lastništvo je pomembno, da programska oprema za zaračunavanje na podlagi porabe omogoča, da se stopnje, presežki in pogostost zaračunavanja spreminjajo neodvisno od porabe. Logiko zaračunavanja je mogoče spremeniti tudi sredi cikla, ne da bi to motilo tok podatkov. En sam kazalnik lahko podpira različne cene v različnih pogodbah, pri čemer merjenje ostaja stabilno, medtem ko se cene spreminjajo.
Zaključek
Najboljši model je skupni model. Inženiring skrbi za točnost in nemoten pretok podatkov o uporabi. Finančni oddelek in oddelek za izdelke v okviru jasnega upravljanja določata vrednost teh podatkov. Katera sprememba cen trenutno čaka v vaši inženirski čakalni vrsti?
Ključne ugotovitve:
- Trdno zakodirano oblikovanje cen spremeni vsako prilagoditev stopnje ali kredita v tehnično zahtevo.
- Razdelite odgovornosti glede na vrsto odločitve: tehnična služba je odgovorna za zajemanje in točnost podatkov o porabi, medtem ko sta finančna služba in oddelek za izdelke odgovorna za opredelitve kazalnikov, cenovne točke, pakete in kredite.
- Najprej vzpostavite zaščitne mehanizme: odobritve, testiranje, različice, datume veljavnosti in revizijsko sled.
- Cenovno oblikovanje pod vodstvom finančnega oddelka potrebuje čiste podatke o uporabi, dogovorjene opredelitve kazalnikov in en sistem evidentiranja za vsak kazalnik.
- Uporabite pet vprašanj pred predajo, da najdete svojo izhodiščno točko.
- Izberite orodja, ki omogočajo spremembo cen brez ponovne vzpostavitve merjenja.

