Contorizarea consumului și stabilirea prețurilor: inginerie vs. finanțe

Introducere

Tarifarea bazată pe utilizare și cea hibridă sunt rareori statice. Când logica de stabilire a prețurilor este codificată rigid, fiecare modificare adusă unui nivel sau unei alocări de credit se transformă într-un tichet de asistență tehnică. Acest lucru încetinește procesul financiar și este frustrant pentru dezvoltatori. Deci, cine ar trebui să se ocupe de măsurarea utilizării și de stabilirea prețurilor pe baza acesteia? Să lămurim acest aspect.

De ce modificările de preț sunt acum frecvente

Stabilirea prețurilor nu mai este o decizie pe care o iei o dată și apoi o uiți. Raportul privind prețurile pentru SaaS și AI realizat de firma de consultanță hy și OMR Reviews, care citează date de la Growth Unhinged, arată că trei din patru companii de software din SUA și-au modificat prețurile în ultimul an. Este o schimbare semnificativă.

Și modelele se schimbă. În sondajul realizat de hy pe un eșantion de 180 de companii de software, 37% utilizează deja modele bazate pe utilizare, iar 59% combină mai multe metrici de stabilire a prețurilor, cum ar fi facturarea pe utilizator alături de volumul API-urilor. Adăugați credite, efectuați experimente, ajustați pachetele, iar schimbarea devine norma, mai degrabă decât excepția.

Cum ajunge logica de stabilire a prețurilor să fie controlată de departamentul de inginerie

De obicei, acest lucru se întâmplă din întâmplare. La început, un dezvoltator codifică fix un criteriu: numără apelurile API, aplică o rată, trimite totalul către factură. Funcționează, așa că nimeni nu pune la îndoială acest lucru.

Apoi, stabilirea prețurilor evoluează. Un nou nivel de tarifare, o alocare gratuită sau o rată diferită pentru depășiri înseamnă că cineva deschide un tichet, așteaptă un slot în sprint și speră ca lansarea să nu perturbe facturarea. Termenul de execuție se prelungește, iar fiecare lansare implică un anumit risc. Departamentul financiar ajunge să aștepte într-o coadă pe care nu o controlează.

Modelele hibride agravează această situație. Cu cât un preț are mai multe componente, cu atât mai multe locuri în cod se pot ascunde schimbările.

Costul stabilirii prețurilor de către departamentul de inginerie

Costurile sunt reale, chiar și fără o foaie de calcul care să le dovedească.

• Lansări lente: O idee de stabilire a prețurilor poate rămâne în așteptare săptămâni întregi, în urma activității de dezvoltare a produsului.
• Erori: Logica ascunsă în cod este greu de interpretat de către departamentul financiar, astfel încât greșelile tind să apară pe facturi.
• Punctele oarbe ale departamentului financiar: Dacă departamentul financiar nu poate vedea cum a fost calculată o cifră, disputele durează mai mult până la rezolvare.
• Costul de oportunitate: Inginerii se ocupă de întreținerea codului de facturare în loc să dezvolte produsul.

Iată părerea mea: dacă o modificare de preț necesită o implementare de cod, stabilirea prețurilor se desfășoară la viteza calendarului de lansări, nu la viteza pieței

Ce ar trebui să fie în responsabilitatea departamentului financiar și ce ar trebui să fie în responsabilitatea departamentului de inginerie

Responsabilitatea nu este de tipul „ori una, ori alta”. Împărțiți-o în funcție de tipul deciziei.

Departamentul de inginerie este responsabil de instrumentarea evenimentelor, fluxurile de date și acuratețea datelor de utilizare la sursă.

Departamentul financiar și cel de produs sunt responsabile de definițiile indicatorilor,de nivelurile de preț,de pachetele de servicii șide credite.

Iată un test simplu. Dacă modificarea se referă la ceea ce se înregistrează, aceasta ține de departamentul de inginerie. Dacă se referă la modul în care utilizarea înregistrată se transformă în bani, aceasta ține de departamentul financiar și de cel de produs. De exemplu, decizia ca un plan să includă 1.500 de apeluri API în loc de 1.000 este o decizie legată de stabilirea prețurilor. Asigurarea faptului că fiecare apel este înregistrat exact o singură dată este o decizie legată de inginerie.

Guvernanța modificărilor de preț

Predarea controlului fără mecanisme de protecție duce la haos. Acestea sunt bune practici generice, care nu sunt legate de un anumit instrument:

• Aprobări: Este necesară aprobarea expresă din partea departamentului financiar și a celui de produs înainte ca o modificare să fie implementată.
• Testare: Previzualizați efectul asupra datelor reale de utilizare înainte de punerea în funcțiune.
• Versiuni: Mențineți fiecare configurație de prețuri în versiuni, astfel încât să puteți compara versiunile sau să reveniți la o versiune anterioară.
• Date de intrare în vigoare: Definiți momentul în care se aplică o modificare și modul în care este tratată utilizarea deja înregistrată la jumătatea ciclului.
• Jurnal de audit: Înregistrați cine a modificat ce și când.

Gândiți-vă la asta ca la o revizuire a codului pentru stabilirea prețurilor. Nimeni nu lansează cod fără o a doua pereche de ochi, iar prețurile merită aceeași atenție.

Condiții prealabile pentru stabilirea prețurilor condusă de departamentul financiar

Departamentul financiar nu poate deține controlul asupra a ceea ce nu poate considera de încredere. Trei elemente fundamentale sunt esențiale.

Date de utilizare curate. Evenimentele duplicate sau lipsă subminează orice preț pe care îl stabiliți pe baza acestora.

Definiții convenite ale indicatorilor. Dacă departamentul de produs definește un „utilizator activ” într-un fel, iar departamentul financiar în altul, facturile voastre vor decide disputa în locul vostru, și nu într-un mod plăcut.

Surse fiabile. Datele de utilizare se găsesc de obicei într-un depozit de date, în spatele unui API sau în fișiere. Alegeți un singur sistem de înregistrare pentru fiecare indicator și rămâneți la acesta.

Întrebări pe care trebuie să le pui înainte de a transfera responsabilitatea pentru stabilirea prețurilor

Adunați directorul financiar, șeful departamentului de produs și șeful departamentului de inginerie într-o singură încăpere și discutați următoarele aspecte:

1. Ce modificări de prețuri am făcut anul trecut și cât timp a durat implementarea fiecăreia?
2. Fiecare indicator facturabil are o singură definiție convenită?
3. Departamentul financiar poate urmări modul în care o valoare a utilizării a devenit o linie de factură?
4. Cine aprobă o modificare și cum o testăm înainte de a o pune în aplicare?
5. Unde sunt stocate datele de utilizare și cine este responsabil pentru acuratețea acestora?

Dacă nu puteți răspunde la două sau trei dintre acestea, acesta este punctul vostru de plecare.

Modificarea prețurilor fără a reconstrui sistemul de măsurare

Aici pot fi de ajutor instrumentele specializate. Conform paginii „Usage Metering” a Zenskar, echipele pot defini indicatorii facturabili în limbaj simplu și pot lăsa AI-ul să scrie logica de agregare sau pot scrie cod SQL personalizat pentru logica complexă. Datele de utilizare pot fi extrase din surse precum Postgres, Athena și MySQL, transmise printr-un API sau încărcate ca fișier CSV. Același indicator poate fi reutilizat pentru diferite produse, contracte și articole de factură.

Aspectul important pentru proprietate este că software-ul de facturare bazat pe utilizare ar trebui să permită modificarea nivelurilor, a depășirilor și a frecvenței de facturare independent de utilizare. Logica de facturare poate fi, de asemenea, modificată în mijlocul ciclului fără a perturba fluxul de date. Un singur indicator poate alimenta diferite modele de stabilire a prețurilor în cadrul contractelor, menținând măsurarea constantă în timp ce prețurile evoluează.

Concluzie

Cel mai sănătos model este cel partajat. Departamentul de inginerie asigură acuratețea și fluxul datelor de utilizare. Departamentele financiar și de produs dețin controlul asupra valorii acestor date, în cadrul unui sistem clar de guvernanță. Ce modificare de preț așteaptă în coada de așteptare a departamentului de inginerie chiar acum?

Puncte cheie:

• Prețurile codificate transformă fiecare ajustare a nivelului de tarifare sau a creditelor într-un tichet de asistență tehnică.
• Împărțiți responsabilitățile în funcție de tipul deciziei: departamentul de inginerie este responsabil de colectarea și acuratețea datelor de utilizare, în timp ce departamentele financiar și de produs sunt responsabile de definițiile indicatorilor, prețuri, pachete și credite.
• Stabiliți mai întâi măsurile de protecție: aprobări, testare, gestionarea versiunilor, date de intrare în vigoare și o pistă de audit.
• Stabilirea prețurilor condusă de departamentul financiar necesită date clare privind utilizarea, definiții convenite ale indicatorilor și un singur sistem de înregistrare pentru fiecare indicator.
• Folosiți cele cinci întrebări de dinaintea predării pentru a vă găsi punctul de plecare.
• Alegeți instrumente care permit modificarea prețurilor fără a fi necesară refacerea sistemului de măsurare.