Misurazione dei consumi e tariffazione: ingegneria contro finanza

Introduzione

I modelli di tariffazione basati sull’utilizzo e quelli ibridi sono raramente statici. Quando la logica di determinazione dei prezzi è hardcoded, ogni modifica a un livello tariffario o a una quota di credito si trasforma in un ticket di assistenza tecnica. Ciò rallenta il reparto finanziario e crea frustrazione tra gli sviluppatori. A chi dovrebbe quindi spettare la gestione della misurazione dell’utilizzo e della tariffazione basata su di essa? Cerchiamo di fare chiarezza.

Perché le modifiche ai prezzi sono ormai frequenti

La determinazione dei prezzi non è più una decisione che si imposta una volta per tutte. Il rapporto “SaaS & AI Pricing Report” della società di consulenza hy e di OMR Reviews, citando i dati di Growth Unhinged, afferma che tre aziende di software statunitensi su quattro hanno modificato i propri prezzi nell’ultimo anno. Si tratta di un cambiamento significativo.

Anche i modelli stanno cambiando. Nel sondaggio condotto da hy su 180 aziende di software, il 37% utilizza già modelli basati sull’utilizzo, mentre il 59% combina più di un parametro di determinazione dei prezzi, come la fatturazione per utente insieme al volume delle API. Aggiungere crediti, condurre esperimenti, modificare i pacchetti: il cambiamento diventa la norma piuttosto che l’eccezione.

Come la logica dei prezzi finisce per essere gestita dal reparto di ingegneria

Di solito succede per caso. All’inizio, uno sviluppatore codifica in modo rigido una metrica: conta le chiamate API, applica una tariffa, invia il totale alla fattura. Funziona, quindi nessuno lo mette in discussione.

Poi la tariffazione si evolve. Un nuovo livello, una quota gratuita o una tariffa di eccedenza diversa comportano che qualcuno apra un ticket, attenda uno slot per lo sprint e speri che il rilascio non interferisca con la fatturazione. I tempi di consegna si allungano e ogni rilascio comporta un certo rischio. Il reparto finanziario finisce per attendere in una coda che non controlla.

I modelli ibridi aggravano la situazione. Più componenti ha un prezzo, più punti nel codice ci sono in cui una modifica può nascondersi.

Il costo di una politica dei prezzi gestita dal reparto di ingegneria

I costi sono reali, anche senza un foglio di calcolo che li dimostri.

• Lanci lenti: un’idea di prezzo può rimanere in sospeso per settimane a causa del lavoro sul prodotto.
• Errori: la logica nascosta nel codice è difficile da interpretare per il reparto finanziario, quindi gli errori tendono a emergere sulle fatture.
• Punti ciechi del reparto finanziario: se il reparto finanziario non riesce a capire come è stato calcolato un dato, la risoluzione delle controversie richiede più tempo.
• Costo opportunità: gli ingegneri si occupano della manutenzione del codice di fatturazione invece di sviluppare il prodotto.

Ecco la mia opinione: se una modifica di prezzo richiede una distribuzione del codice, la vostra strategia di prezzi si muove alla velocità del vostro calendario di rilascio, non alla velocità del vostro mercato

Cosa dovrebbe gestire il reparto finanziario e cosa il reparto tecnico

La responsabilità non è una scelta esclusiva. Dividetela in base al tipo di decisione.

Il reparto tecnico è responsabile della strumentazione degli eventi, delle pipeline di dati e dell’accuratezza dei dati di utilizzo alla fonte.

Il reparto Finanza e il reparto Prodotto sono responsabili delle definizioni delle metriche, dei livelli di prezzo, dei pacchetti e dei crediti.

Ecco un semplice test. Se la modifica riguarda ciò che viene rilevato, spetta al reparto tecnico. Se riguarda il modo in cui l’utilizzo rilevato si traduce in denaro, spetta al reparto finanziario e a quello di prodotto. Ad esempio, decidere che un piano includa 1.500 chiamate API invece di 1.000 è una decisione relativa ai prezzi. Assicurarsi che ogni chiamata venga registrata esattamente una volta è una decisione tecnica.

Governance delle modifiche ai prezzi

Cedere il controllo senza linee guida porta al caos. Queste sono best practice generiche, non legate a uno strumento specifico:

• Approvazioni: è necessario ottenere l’approvazione esplicita sia dal reparto finanziario che da quello di prodotto prima che una modifica venga implementata.
• Test: è necessario verificare in anteprima l’effetto sui dati di utilizzo reali prima della messa in produzione.
• Gestione delle versioni: gestire ogni configurazione dei prezzi con un sistema di versioni, in modo da poter confrontare le versioni o ripristinare quelle precedenti.
• Date di entrata in vigore: definire quando una modifica diventaeffettiva e come vengono trattati i dati di utilizzo già registrati a metà ciclo.
• Registro di controllo: registrare chi ha modificato cosa e quando.

Pensatela come una revisione del codice per i prezzi. Nessuno rilascia codice senza un secondo controllo, e i prezzi meritano la stessa attenzione.

Prerequisiti per una politica dei prezzi guidata dalla finanza

Il reparto finanziario non può assumersi la responsabilità di ciò di cui non si fida. Tre principi fondamentali vengono prima di tutto.

Dati di utilizzo puliti. Eventi duplicati o mancanti compromettono qualsiasi prezzo fissato sulla base di essi.

Definizioni concordate delle metriche. Se il reparto Prodotto definisce un “utente attivo” in un modo e il reparto Finanza in un altro, saranno le vostre fatture a risolvere la questione per voi, e non in modo gentile.

Fonti affidabili. I dati di utilizzo risiedono in genere in un data warehouse, dietro un’API o in file. Scegliete un unico sistema di riferimento per ogni metrica e attenetevi ad esso.

Domande da porre prima di trasferire la responsabilità dei prezzi

Riunite il CFO, il responsabile del prodotto e il responsabile tecnico in una stanza e affrontate questi punti:

1. Quali modifiche ai prezzi abbiamo apportato lo scorso anno e quanto tempo è stato necessario per implementare ciascuna di esse?
2. Ogni parametro fatturabile ha una definizione concordata?
3. Il reparto finanziario è in grado di tracciare come un dato di utilizzo sia diventato una riga della fattura?
4. Chi approva una modifica e come la testiamo prima che entri in vigore?
5. Dove sono archiviati i dati di utilizzo e chi è responsabile della loro accuratezza?

Se non riuscite a rispondere a due o tre di queste domande, quello è il vostro punto di partenza.

Modificare i prezzi senza ricostruire il sistema di misurazione

È qui che gli strumenti possono aiutare. Secondo la pagina "Usage Metering " di Zenskar, i team possono definire le metriche fatturabili in un linguaggio semplice e lasciare che l’IA scriva la logica di aggregazione, oppure scrivere codice SQL personalizzato per logiche complesse. I dati di utilizzo possono essere estratti da fonti quali Postgres, Athena e MySQL, inviati tramite un’API o caricati come file CSV. La stessa metrica può essere riutilizzata su diversi prodotti, contratti e voci di fattura.

L’aspetto fondamentale per la gestione è che il software di fatturazione basato sull’utilizzo dovrebbe consentire di modificare le fasce tariffarie, i superamenti e la cadenza di fatturazione indipendentemente dall’utilizzo. La logica di fatturazione può anche essere modificata a ciclo in corso senza interrompere la pipeline dei dati. Un’unica metrica può alimentare diversi modelli di tariffazione tra i contratti, mantenendo stabile la misurazione mentre i prezzi evolvono.

Conclusione

Il modello più sano è quello condiviso. Il reparto di ingegneria garantisce l’accuratezza e la continuità del flusso dei dati di utilizzo. I reparti finanziario e di prodotto gestiscono il valore di tali dati nell’ambito di una governance chiara. Quale modifica dei prezzi è attualmente in coda nel vostro reparto di ingegneria?

Punti chiave:

• I prezzi fissi trasformano ogni modifica al livello tariffario o al credito in un ticket tecnico.
• Dividere le responsabilità in base al tipo di decisione: il reparto tecnico è responsabile della raccolta e dell’accuratezza dei dati di utilizzo, mentre il reparto finanziario e quello di prodotto sono responsabili delle definizioni delle metriche, dei livelli di prezzo, dei pacchetti e dei crediti.
• Mettete in atto prima di tutto le misure di sicurezza: approvazioni, test, gestione delle versioni, date di entrata in vigore e una traccia di audit.
• Una strategia di prezzi guidata dal reparto finanziario richiede dati di utilizzo puliti, definizioni delle metriche concordate e un unico sistema di registrazione per ogni metrica.
• Utilizzate le cinque domande da porsi prima del passaggio di consegne per individuare il vostro punto di partenza.
• Scegli strumenti che consentano di modificare i prezzi senza dover ricostruire il sistema di misurazione.