Raconteur розбирає витрати компаній на програмне забезпечення й AI-інструменти. Аналітики звертають увагу на розрив між договорами, рахунками, даними використання та датами продовження. Без спільного огляду компанія може домовитися про знижку, але знову купити більше ліцензій, ніж їй потрібно.
Ключові інсайти
Що не варто робити з великими оцінками переплати
Матеріал Саймона Чандлера спирається зокрема на дані Spendesk про європейські компанії з 50–250 працівниками. Наведені в ньому оцінки не можна автоматично поширювати на весь бізнес. Саме відсутність огляду власних договорів, а не чужа середня цифра, є приводом перевірити закупівлі.
Редакційний розбір: почати з найближчого продовження
Уявімо компанію, де невдовзі продовжується річний договір на робочу платформу. Закупівельник має ціну й дату, IT — список облікових записів, а керівники команд знають, яка робота реально виконується в системі. Поки ці відомості не зіставлено, жодна функція не має повної основи для рішення.
Міжфункціональна взаємодія потрібна до переговорів із постачальником. Для кожної групи ліцензій варто з’ясувати, хто користується платформою, для якої роботи та чи потрібен саме поточний пакет. Активний вхід у систему не завжди означає потребу в усіх оплачених можливостях, а рідке використання може підтримувати важливу сезонну операцію.
Розрізняти зайве місце і критичний доступ
У нашому гіпотетичному випадку обліковий запис колишнього працівника та доступ фахівця, який працює лише під час річної звітності, не можна однаково назвати невикористаними. Перший потребує перевірки закриття, другий — розуміння робочої потреби та доступного типу ліцензії.
Розподіл повноважень має визначати, хто підтверджує цю потребу і хто погоджує зміну пакета. Рішення про скорочення місць не повинне залишати команду без доступу посеред роботи. Спочатку потрібні підтвердження власника процесу, маршрут збереження необхідних даних і дата переходу, потім — нове замовлення.
Перевірити, чи інструменти справді виконують однакову роботу
Для нашого прикладу окремо розгляньмо двох AI-помічників у різних підрозділах. Якщо один працює в підтримці клієнтів, а другий допомагає з внутрішніми документами, спільна здатність генерувати текст ще не робить їх взаємозамінними. Потрібно порівняти робочі задачі, інтеграції та вимоги до доступу.
Операційна модель допомагає пов’язати інструмент із конкретним результатом. Коли дві команди оплачують однакову функцію для тієї самої роботи, можна перевірити спільне рішення. Коли задачі різні, механічне об’єднання створить нові витрати на перенесення й налаштування. Ці витрати також мають бути видимими до відмови від підписки.
Повернутися до постачальника з уточненою потребою
Після такого розбору предмет переговорів змінюється. Компанія обговорює не тільки знижку на торішній обсяг, а потрібні місця, пакет, строк і умови зміни кількості. Пропозиції варто порівнювати на однаковій основі: нижча ставка за довше зобов’язання не завжди є кращим рішенням для поточної потреби.
Управлінський ритм у нашому прикладі має залишити відповідального за договір і після підписання. Він стежить за зміною потреби та строком наступного рішення. Тоді перевірка використання стає частиною керування програмними витратами, а не разовою кампанією перед автоматичним продовженням.
Головні тези
- Аналітик Forrester Фарам Медхора радить зібрати договори, платежі, використання та строки продовження в одному огляді й починати великі переукладення завчасно.
- Порівнювати ціни потрібно за зіставними пакетами, кількістю користувачів і строками. Сама різниця вартості між компаніями ще не доводить переплату.
- Кілька AI-постачальників не обов’язково дублюють один одного: інструменти можуть виконувати різну роботу. Перевіряти слід конкретне використання, а не лише схожі назви продуктів.
Що це означає для CEO
До переговорів про знижку погодьте потрібний обсяг і пакет. Зведіть договір, використання та дату продовження в один огляд, а скорочення ліцензій підтверджуйте з власниками робочих процесів.