Měření spotřeby a stanovení cen: technický pohled vs. finanční pohled

Úvod

Ceny založené na využití a hybridní ceny jsou málokdy statické. Pokud je logika stanovování cen pevně zakódována, každá úprava cenové úrovně nebo kreditního limitu se promění v technický ticket. To je pro finanční oddělení zdlouhavé a pro vývojáře frustrující. Kdo by tedy měl mít na starosti měření využití a na něm založené stanovování cen? Pojďme si to ujasnit.

Proč jsou změny cen nyní tak časté

Cenotvorba již není rozhodnutím typu „nastav a zapomeň“. Zpráva „SaaS & AI Pricing Report“ od poradenské společnosti hy a OMR Reviews, která cituje data společnosti Growth Unhinged, uvádí, že tři ze čtyř amerických softwarových společností změnily v uplynulém roce své ceny. To je značný pohyb.

Mění se i cenové modely. V průzkumu společnosti hy, do kterého se zapojilo 180 softwarových firem, již 37 % používá modely založené na využití a 59 % kombinuje více než jeden cenový ukazatel, například účtování na uživatele spolu s objemem API. Přidávejte kredity, provádějte experimenty, upravujte balíčky služeb – a změna se stává spíše normou než výjimkou.

Jak se logika cenového modelování dostává do rukou vývojářů

Obvykle k tomu dojde náhodou. Na začátku vývojář pevně zakóduje metriku: spočítá volání API, aplikuje sazbu a celkovou částku zašle na fakturu. Funguje to, takže to nikdo nezpochybňuje.

Pak se cenová politika vyvíjí. Nová cenová úroveň, bezplatný limit nebo jiná sazba za překročení limitu znamenají, že někdo podá žádost, čeká na místo ve sprintu a doufá, že vydání nové verze nenaruší fakturaci. Doba realizace se prodlužuje a každé vydání s sebou nese určité riziko. Finanční oddělení nakonec čeká ve frontě, kterou nemůže ovlivnit.

Hybridní modely tuto situaci ještě zhoršují. Čím více složek má cena, tím více míst v kódu se může změna skrývat.

Náklady na cenotvorbu řízenou vývojáři

Náklady jsou reálné, i bez tabulky, která by je dokládala.

• Pomalé zavádění: Návrh cenové změny může týdny čekat v pozadí za vývojem produktu.
• Chyby: Logika ukrytá v kódu je pro finanční oddělení těžko čitelná, takže se chyby často objevují na fakturách.
• Slepá místa finančního oddělení: Pokud finanční oddělení nevidí, jak byla určitá částka vypočítána, trvá vyřešení sporů déle.
• Alternativní náklady: Inženýři se věnují údržbě fakturačního kódu místo vývoje produktu.

Tady je můj názor: Pokud změna ceny vyžaduje nasazení kódu, vaše cenotvorba se řídí tempem vašeho kalendáře vydávání verzí, nikoli tempem trhu

Co by mělo spadat do kompetence finančního oddělení a co do kompetence vývojového týmu

Odpovědnost není otázkou „buď, anebo“. Rozdělte ji podle typu rozhodnutí.

Technické oddělení má na starosti monitorování událostí, datové potrubí a přesnost údajů o využití přímo u zdroje.

Finanční oddělení a produktové oddělení mají na starosti definice metrik, cenové hladiny, balíčky a kredity.

Zde je jednoduchý test. Pokud se změna týká toho, co se zaznamenává, patří do kompetence technického oddělení. Pokud se týká toho, jak se zaznamenané využití promění v peníze, patří do kompetence finančního a produktového oddělení. Například rozhodnutí, že tarif zahrnuje 1 500 volání API namísto 1 000, je cenové rozhodnutí. Zajištění toho, aby každé volání bylo zaznamenáno přesně jednou, je úkol pro technické oddělení.

Řízení změn cen

Předání kontroly bez ochranných opatření vede k chaosu. Jedná se o obecné osvědčené postupy, které nejsou vázány na žádný konkrétní nástroj:

• Schvalování: Před zavedením změny do ostrého provozu je nutné získat výslovné schválení od finančního oddělení a produktového týmu.
• Testování: Před spuštění si prohlédněte, jaký dopad bude mít změna na skutečná data o využití.
• Verzování: Uchovávejte každou konfiguraci cen v různých verzích, abyste mohli porovnávat verze nebo se vrátit k předchozí verzi.
• Datum účinnosti: Definujte, kdy se změna uplatní a jak se zachází s již zaznamenaným využitím v průběhu cyklu.
• Auditní stopa: Zaznamenávejte, kdo, co a kdy změnil.

Berte to jako revizi kódu v oblasti cen. Nikdo nevydává kód bez toho, aby ho zkontroloval někdo další, a ceny si zaslouží stejnou péči.

Předpoklady pro cenotvorbu vedenou finančním oddělením

Finanční oddělení nemůže vlastnit to, čemu nemůže důvěřovat. Na prvním místě jsou tři základy.

Čistá data o využití. Duplicitní nebo chybějící události podkopávají jakoukoli cenu, kterou na jejich základě stanovíte.

Dohodnuté definice metrik. Pokud produkt definuje „aktivního uživatele“ jedním způsobem a finanční oddělení jiným, vaše faktury tento spor vyřeší za vás, a to ne zrovna příjemným způsobem.

Spolehlivé zdroje. Údaje o využití se obvykle nacházejí v datovém skladu, za API nebo v souborech. Vyberte si pro každou metriku jeden systém záznamů a držte se ho.

Otázky, které je třeba si položit před přesunem odpovědnosti za cenotvorbu

Svolejte finančního ředitele, vedoucího produktového týmu a vedoucího technického týmu do jedné místnosti a projděte si následující body:

1. Jaké změny v cenách jsme provedli v loňském roce a jak dlouho trvalo zavedení každé z nich?
2. Má každá fakturovatelná metrika jednu sjednanou definici?
3. Může finanční oddělení vysledovat, jak se údaj o využití promítl do položky na faktuře?
4. Kdo schvaluje změnu a jak ji otestujeme před jejím zavedením?
5. Kde jsou uložena data o využití a kdo odpovídá za jejich přesnost?

Pokud nedokážete odpovědět na dvě nebo tři z těchto otázek, je to váš výchozí bod.

Změna cen bez přepracování měření

Právě v tomto ohledu mohou pomoci nástroje. Podle stránky Zenskar věnované měření spotřeby mohou týmy definovat fakturovatelné metriky v běžném jazyce a nechat AI napsat agregační logiku, nebo pro složitou logiku napsat vlastní SQL. Údaje o spotřebě lze načíst ze zdrojů, jako jsou Postgres, Athena a MySQL, odeslat přes API nebo nahrát jako soubor CSV. Stejnou metriku lze znovu použít napříč produkty, smlouvami a položkami.

Z hlediska odpovědnosti je důležité, aby software pro fakturaci na základě využití umožňoval změnu cenových úrovní, limitů a frekvence fakturace nezávisle na využití. Fakturační logiku lze také upravit v průběhu cyklu, aniž by došlo k narušení datového toku. Jedna metrika může pohánět různé cenové modely napříč smlouvami, čímž se měření udržuje stabilní, zatímco se ceny vyvíjejí.

Závěr

Nejzdravější model je sdílený. Technický tým zajišťuje přesnost a plynulý tok dat o využití. Finanční a produktové týmy rozhodují o hodnotě těchto dat v rámci jasné správy. Jaká změna cenového modelu právě čeká ve vaší technické frontě?

Hlavní body:

• Pevně zakódované ceny proměňují každou úpravu cenové úrovně nebo kreditu v technický ticket.
• Rozdělte odpovědnost podle typu rozhodnutí: technický tým odpovídá za sběr a přesnost údajů o využití, zatímco finanční a produktový tým odpovídá za definice metrik, cenové hladiny, balíčky a kredity.
• Nejprve zavedeme bezpečnostní opatření: schvalování, testování, verzování, data účinnosti a auditní stopu.
• Cenotvorba vedená finančním oddělením vyžaduje čistá data o využití, dohodnuté definice metrik a jeden systém záznamů pro každou metriku.
• Využijte pět otázek před předáním k nalezení svého výchozího bodu.
• Vyberte si nástroje, které umožňují změnu cen bez nutnosti přepracovávat systém měření.