Вимірювання споживання та ціноутворення: інженерія проти фінансів

Вступ

Ціноутворення на основі використання та гібридне ціноутворення рідко бувають статичними. Коли логіка ціноутворення жорстко запрограмована, кожне коригування тарифного плану або ліміту кредитів перетворюється на технічний запит. Це уповільнює роботу фінансового відділу та викликає роздратування у розробників. Тож хто повинен відповідати за облік використання та ціноутворення, побудоване на його основі? Давайте розберемося.

Чому зміни цін зараз відбуваються так часто

Ціноутворення більше не є рішенням, яке можна встановити раз і назавжди. Звіт про ціноутворення в сферах SaaS та штучного інтелекту (AI), підготовлений консалтинговою компанією hy та OMR Reviews на основі даних Growth Unhinged, свідчить, що три з чотирьох американських компаній-розробників програмного забезпечення змінили свою цінову політику протягом останнього року. Це значні зміни.

Змінюються й моделі ціноутворення. Згідно з опитуванням hy, проведеним серед 180 компаній-розробників програмного забезпечення, 37% вже використовують моделі, засновані на використанні, а 59% поєднують більше одного показника ціноутворення, наприклад, оплату за користувача разом з обсягом використання API. Додайте до цього кредити, експерименти та коригування пакетів послуг — і зміни стають нормою, а не винятком.

Як логіка ціноутворення переходить у відання інженерів

Зазвичай це відбувається випадково. На початку розробник жорстко кодує показник: підраховує виклики API, застосовує тариф, надсилає загальну суму до рахунку-фактури. Це працює, тож ніхто це не ставить під сумнів.

Потім цінова політика еволюціонує. Новий тарифний рівень, безкоштовний ліміт або інша ставка за перевищення означають, що хтось створює заявку, чекає на слот у спринті та сподівається, що реліз не порушить процес виставлення рахунків. Терміни виконання подовжуються, і кожен реліз несе певний ризик. Фінансовий відділ зрештою опиняється в черзі, яку він не контролює.

Гібридні моделі ще більше погіршують ситуацію. Чим більше складових має ціна, тим більше місць у коді може приховати зміна.

Вартість ціноутворення, що належить інженерам

Ці витрати реальні, навіть без електронної таблиці, яка б їх підтверджувала.

• Повільне впровадження: ідея щодо ціноутворення може тижнями чекати на реалізацію, відступаючи на другий план перед розробкою продукту.
• Помилки: логіка, прихована в коді, важко зрозуміла для фінансового відділу, тому помилки часто виявляються у рахунках-фактурах.
• «Сліпі зони» фінансового відділу: якщо фінансовий відділ не бачить, як було розраховано ту чи іншу цифру, вирішення суперечок займає більше часу.
• Альтернативні витрати: інженери займаються обслуговуванням коду для виставлення рахунків замість розробки продукту.

Ось моя думка: якщо зміна ціни вимагає розгортання коду, ваше ціноутворення рухається зі швидкістю вашого календаря релізів, а не зі швидкістю вашого ринку

Що має бути у компетенції фінансового відділу, а що — у компетенції інженерного відділу

Відповідальність — це не вибір між тим чи іншим. Розподіліть її за типом рішення.

Інженерний відділ відповідає за інструментарій для відстеження подій, канали передачі даних та точність даних про використання на рівні джерела.

Фінансовий відділ та відділ продукту відповідають за визначення метрик, цінові точки, пакети послуг та кредити.

Ось простий тест. Якщо зміна стосується того, що фіксується, вона належить до сфери інженерії. Якщо ж вона стосується того, як зафіксоване використання перетворюється на гроші, вона належить до сфери фінансів та продукту. Наприклад, рішення про те, що тарифний план включає 1 500 викликів API замість 1 000, — це рішення щодо ціноутворення. А забезпечення того, щоб кожен виклик реєструвався саме один раз, — це завдання інженерії.

Управління змінами цін

Передача контролю без захисних механізмів призводить до хаосу. Це загальні найкращі практики, не пов’язані з жодним конкретним інструментом:

• Затвердження: перед впровадженням змін потрібно отримати підпис відповідальних осіб з фінансового відділу та відділу розробки продукту.
• Тестування: перед запуском слід перевірити вплив змін на реальні дані використання.
• Версіонування: Ведіть версії кожної конфігурації ціноутворення, щоб мати змогу порівнювати версії або повертатися до попередніх.
• Дати набрання чинності: визначте, коли зміна набуває чинності та як обробляються дані про використання, вже зафіксовані в середині циклу.
• Журнал аудиту: фіксуйте, хто, що та коли змінив.

Уявіть собі це як рецензування коду для ціноутворення. Ніхто не випускає код без додаткової перевірки, і ціни заслуговують на таку саму увагу.

Передумови для ціноутворення під керівництвом фінансового відділу

Фінансовий відділ не може володіти тим, чому не може довіряти. На першому місці — три основи.

Чисті дані про використання. Дублювання або відсутність подій підривають будь-яку ціну, яку ви встановлюєте на їх основі.

Узгоджені визначення показників. Якщо відділ продукту визначає поняття «активний користувач» одним чином, а фінансовий відділ — іншим, ваші рахунки-фактури вирішать цю суперечку за вас, і не на вашу користь.

Надійні джерела. Дані про використання зазвичай зберігаються у сховищі даних, за API або у файлах. Оберіть одну систему обліку для кожного показника та дотримуйтесь її.

Питання, які слід задати перед передачею відповідальності за ціноутворення

Зберіть фінансового директора, керівника відділу продукту та керівника відділу розробки в одній кімнаті й обговоріть такі питання:

1. Які зміни в ціноутворенні ми внесли минулого року, і скільки часу знадобилося на впровадження кожної з них?
2. Чи має кожен показник, що підлягає оплаті, одне узгоджене визначення?
3. Чи може фінансовий відділ відстежити, як показник використання перетворився на рядок у рахунку-фактурі?
4. Хто затверджує зміну та як ми її тестуємо перед впровадженням?
5. Де зберігаються дані про використання, і хто відповідає за їхню точність?

Якщо ви не можете відповісти на два або три з цих питань, це і є ваша відправна точка.

Зміна ціноутворення без перебудови системи обліку

Саме тут можуть допомогти відповідні інструменти. Згідно зі сторінкою Zenskar, присвяченій обліку використання, команди можуть визначити показники, що підлягають оплаті, простою мовою і дозволити штучному інтелекту написати логіку агрегації, або написати власний SQL-код для складної логіки. Дані про використання можна отримувати з таких джерел, як Postgres, Athena та MySQL, передавати через API або завантажувати у форматі CSV. Один і той самий показник можна повторно використовувати для різних продуктів, контрактів та позицій рахунку.

Для забезпечення відповідальності важливо, щоб програмне забезпечення для виставлення рахунків на основі використання дозволяло змінювати тарифні рівні, надлишки та періодичність виставлення рахунків незалежно від обсягів використання. Логіку виставлення рахунків також можна змінювати в середині циклу без порушення роботи конвеєра даних. Один показник може лежати в основі різних моделей ціноутворення для різних контрактів, забезпечуючи стабільність обліку в міру зміни цін.

Висновок

Найкраща модель — це спільна модель. Інженери забезпечують точність і безперебійність потоку даних про використання. Фінансовий відділ та команда продукту визначають цінність цих даних у рамках чіткого управління. Які зміни в ціноутворенні зараз чекають у вашій черзі інженерних завдань?

Ключові висновки:

• Жорстко запрограмовані ціни перетворюють кожне коригування рівня або кредиту на технічний запит.
• Розділіть відповідальність за типом рішень: технічний відділ відповідає за збір та точність даних про використання, а фінансовий відділ та відділ продукту — за визначення показників, цінові точки, пакети послуг та кредити.
• Спочатку встановіть захисні механізми: затвердження, тестування, управління версіями, дати набрання чинності та аудиторський слід.
• Ціноутворення під керівництвом фінансового відділу потребує чітких даних про використання, узгоджених визначень показників та єдиної системи обліку для кожного показника.
• Скористайтеся п’ятьма запитаннями перед передачею повноважень, щоб визначити свою відправну точку.
• Обирайте інструменти, які дозволяють змінювати ціни без переробки механізмів обліку.