Учет лицензий и подписок в SMB: реестр и контроль продлений

Что обычно идет не так с лицензиями и подписками в SMB

Лицензии и подписки чаще ломаются не из-за злого умысла, а из-за бытовых мелочей. Кто-то оплатил сервис с личной карты, кто-то подключил второй тариф "на всякий случай", а потом ушел из компании. Через пару месяцев это выливается в двойные списания, потерянные доступы и неприятные разговоры с бухгалтерией.

Корень проблемы почти всегда один: нет единого места, где видно, что именно куплено, на каких условиях и кто за это отвечает. Без такого списка легко не заметить, что в другом отделе уже есть лицензии на тот же инструмент, что части сотрудников не хватает прав, а у части они лишние. Поэтому учет вспоминают, когда уже случилась неприятность: сервис отключили или пришел неожиданный счет.

Потери не ограничиваются деньгами. Обычно всплывают и другие риски:

• Простои: продажи не видят CRM, бухгалтерия не может выставить счет, команда не входит в почту.
• Штрафы и споры: нарушили условия лицензии, превысили число пользователей, не сохранили документы по покупке.
• Безопасность: бывшие сотрудники остаются с доступом, у сервиса нет владельца, MFA не включена.
• Репутация: клиенты видят задержки, срываются сроки, внутри растет хаос.

Учет становится по-настоящему нужен, когда SaaS-сервисов становится больше 8-10 и никто не может назвать их все, появляются филиалы/удаленка/подрядчики, растет текучка, а покупки идут "где получилось" (IT, финансы, руководители команд, срочные запросы).

Хорошая новость в том, что большую часть проблем закрывает простой реестр и понятные правила владения сервисами. Это не бюрократия, а страховка от отключений и лишних оплат.

Какие лицензии и подписки стоит учитывать

Важнее учитывать не "все подряд", а то, что может внезапно остановить работу или незаметно съедать бюджет. Начните с минимального набора и расширяйте реестр по мере того, как стабилизируются покупки.

Полезно фиксировать подписки разных моделей, потому что у них разные риски: где-то переплата за лишних пользователей, где-то забытые устройства, где-то ограничения по серверу.

Обычно встречаются модели:

• По пользователям: почта, офисные пакеты, CRM, сервис-деск, дизайн, аналитика.
• По устройствам: антивирус, MDM, удаленный доступ, кассовое ПО.
• По серверу/ядрам: базы данных, виртуализация, резервное копирование, защитные шлюзы.
• По проекту/команде: таск-трекеры, репозитории, CI/CD, тестирование.
• По объему: облачное хранилище, e-sign, рассылки, телефония (минуты, номера).

Дальше - реальность платежей. Подписки бывают ежемесячные и годовые, с автопродлением или без. Самая болезненная комбинация: годовая подписка с автопродлением и без заранее закрепленного бюджета. Списание происходит внезапно, а отмена часто уже не возвращает сумму.

Отдельно проверьте, где реально "сидят" расходы. В реестре стоит фиксировать источник оплаты и канал покупки: корпоративные карты (включая виртуальные), счета от партнеров/реселлеров, маркетплейсы и магазины приложений, а также докупки внутри самих сервисов (места, хранилище, минуты).

Если ресурсов мало, начните с критичного: учетные записи и почта, доступ к файлам, бухгалтерия, продажи и поддержка, резервное копирование и безопасность. Типичный сценарий риска: менеджер оплатил сервис рассылок "на пробу", включил автопродление, ушел, а через три месяца накопились списания, и база клиентов уже привязана к инструменту. Реестр нужен именно для этого: чтобы было понятно, что куплено, кем оплачено и что произойдет при продлении.

Владельцы сервисов: кто за что отвечает

Если у сервиса нет владельца, он быстро становится "ничьим": подписка продлевается по инерции, доступы разрастаются, а списания замечают постфактум. Поэтому в учете важно держать не только названия и суммы, но и конкретных людей, которые принимают решения.

Владелец сервиса - не обязательно IT. Чаще это руководитель функции, которая получает ценность: финансы для бухгалтерии, продажи для CRM, HR для найма, маркетинг для рассылок. Его задача - подтверждать, что сервис нужен, и что количество лицензий и тариф соответствуют реальному использованию.

Роли обычно распределяются так:

• Владелец сервиса: подтверждает необходимость, состав пользователей и уровень тарифа, согласует изменения.
• Финансы (или ответственный за оплаты): видит списания, хранит документы, контролирует лимиты и способ оплаты.
• Технический админ (IT, ИБ или подрядчик): управляет доступами, настройками, интеграциями и безопасностью.
• Резервный владелец: подменяет основного в отпуске или при увольнении.

Полезно сразу разделить "кто решает" и "кто платит". Например, руководитель продаж решает, сколько лицензий CRM нужно на следующий квартал, а бухгалтерия следит, чтобы оплата шла от компании и не была привязана к личной карте сотрудника.

За безопасность тоже должен быть назначен конкретный ответственный: кто отключает доступ ушедшим, кто включает MFA, кто проверяет админские права. Не так важно, внутренний это сотрудник или внешний админ - важно, чтобы имя было в реестре.

Чтобы ответственность не исчезала, заранее зафиксируйте правила замены владельца: резервный человек, админка через корпоративные учетные записи и обязательная передача дел при увольнении.

Простой реестр: что записывать, чтобы он работал

Реестр не обязан быть идеальным. Он должен за минуту отвечать на три вопроса: что купили, кто отвечает и когда принимаем решение по продлению. Для SMB чаще всего достаточно одной таблицы (Excel/Google Sheets) и понятного процесса обновления.

Базовый набор полей можно держать компактным:

• Сервис и назначение.
• Тип и тариф.
• Количество и стоимость (в месяц/год, при необходимости отдельно НДС).
• Поставщик и оплата (контакт, счет/номер заказа, способ оплаты, валюта).
• Даты и продление (старт, конец, автопродление да/нет, дата напоминания).

Дальше добавьте то, что реально спасает от потери доступа: кто админ и кто его заменяет, где лежат учетные данные (сейф/менеджер паролей и у кого доступ), и что делать при уходе сотрудника (передача админства, смена почты, включение MFA).

Статусы тоже полезны, но без усложнений. Договоритесь о двух-трех понятных вариантах, например: активно, на проверке, к отключению. "На проверке" означает, что владелец до даты уведомления собирает факты (использование, нужные лицензии, риски). "К отключению" означает, что решение принято, и готовится план выгрузки данных и остановки сервиса.

Как настроить учет за 7 шагов

Нужны единый список, назначенные владельцы и напоминания о продлениях. Быстрый запуск можно сделать за вечер, а дальше поддерживать по 10 минут в неделю.

1. Выберите место для реестра. Обычно хватает общей таблицы, где право редактирования есть у 2-3 ответственных.

2. Соберите стартовый список. Поднимите выписки и счета за 3-6 месяцев, письма с инвойсами, историю платежей по корпоративным картам, а также списки приложений в админках (Microsoft 365, Google Workspace, CRM и т.д.).

3. Сверьте, кто реально платит. Отдельно проверьте личные карты сотрудников и платежи подрядчиков. Если сервис критичен, оплата должна быть оформлена на компанию.

4. Назначьте владельцев. На каждый сервис нужен бизнес-владелец и технический контакт.

5. Сверьте пользователей и тариф. Сравните активных пользователей в сервисе с тем, за что вы платите. Часто экономия находится в лишних местах и забытых аккаунтах.

6. Проставьте даты продлений и напоминания. Минимум: за 30 и за 7 дней до списания, плюс отметка автопродления.

7. Расставьте приоритеты. Отметьте критичные сервисы (почта, бухгалтерия, телефония, доступы) и "быстрые деньги" (подписки с перерасходом мест). Если в CRM оплачено 25 лицензий, а активных 18, это повод сразу закрыть лишние аккаунты и уменьшить план.

Контроль продлений: календарь и правила решений

Даже при хорошем учете деньги чаще всего теряются на продлениях: подписка списалась сама, тариф вырос, а пользователи давно не заходят. Это лечится не сложной системой, а дисциплиной и короткими правилами.

Удобная схема напоминаний - 60-30-7:

• За 60 дней владелец проверяет факты и готовит варианты.
• За 30 дней принимается решение и при необходимости запускается покупка/смена тарифа.
• За 7 дней финальная проверка: счет оплачен, доступы не потеряются, автопродление выставлено правильно.

Перед продлением не спорьте на уровне "кажется, надо". Быстро проверьте:

• активность за последние 30-90 дней (не количество заведенных аккаунтов);
• подходит ли тариф реальному сценарию;
• нет ли дублирования функций;
• изменились ли требования по безопасности/хранению/отчетности;
• что сломается, если не продлить, и есть ли план Б.

Чтобы избежать неконтролируемых списаний, держите простое правило: автопродление включено только там, где есть владелец и понятный лимит (по бюджету или количеству мест). Во всех остальных случаях автопродление лучше выключить и продлевать вручную по решению.

Решение фиксируйте прямо в реестре одной строкой: продлить как есть, уменьшить (места/тариф), заменить (и срок миграции), отключить (и дата выгрузки).

Процесс покупок и изменений: чтобы реестр не устаревал

Реестр устаревает не потому, что он "плохой", а потому что покупки и изменения проходят мимо него. Для SMB критично одно правило: любой новый сервис, расширение подписки или разовая покупка попадают в реестр в тот же день, когда принято решение.

Сделайте единый вход для заявок: один email, чат с закрепленным шаблоном или короткая форма. И заранее определите, кто имеет право запрашивать новый сервис: обычно руководители команд и 1-2 ответственных со стороны IT и финансов.

Мини-форма согласования

Согласование должно быть коротким, но обязательным. Хватает пяти пунктов:

• цель (зачем нужен сервис и кому);
• владелец (кто отвечает за доступы и продление);
• бюджет (сумма и источник);
• срок (месяц, год, разовая покупка);
• альтернатива (чем уже пользуемся и почему не подходит).

Если владельца нет, покупку не делайте: потом будет некому отвечать за продление и отключение.

Правило тестового периода

Для нового SaaS договоритесь, что тест всегда с датой окончания и человеком, который принимает решение. Например, маркетинг берет 14 дней на инструмент рассылок: владелец фиксирует в реестре дату конца теста и ставит напоминание за 3 дня - "покупаем или закрываем". Без этого тесты незаметно превращаются в платные подписки.

Изменения внутри подписок тоже проводите через тот же вход. Докупили 10 мест - обновите количество, цену и дату следующего списания. Купили разовую лицензию - отметьте "не продлевается", но укажите, где хранится ключ и документы, и что делать при замене компьютера. Это особенно важно, когда параллельно закупается железо и инфраструктура, например рабочие станции или серверы: изменения должны сходиться в одном источнике правды.

Частые ошибки и ловушки

Первая проблема в SMB - учет держится на одном человеке. Сегодня это "офис-менеджер, который все помнит", завтра он в отпуске или увольняется, и никто не знает, где даты продлений, кто админ и на какую карту привязана оплата. Реестр должен жить в процессе, а не в голове.

Вторая ловушка - "сервис общий, значит ничей". Когда нет владельца, продление превращается в суету за 1-2 дня до списания: кто-то просит оплатить "чтобы не отключили", а потом месяцами выясняется, нужен ли сервис вообще.

Третья, тихая, но дорогая ошибка - лицензии не связаны с людьми и командами. Тогда платите за ушедших сотрудников, а новичку покупаете еще одну лицензию, потому что "свободных нет". Сюда же относится ситуация, когда несколько отделов делят один тариф, но никто не отвечает за распределение.

Отдельный риск - админские доступы. Часто учитывают пользователей и стоимость, но забывают про главного администратора, резервный способ входа, почту для восстановления и MFA. Потеря одной учетной записи иногда отрезает доступ сразу ко всему.

Если хотите простой набор "красных флажков", отлавливайте заранее:

• реестр редактирует один человек без замены;
• у сервиса нет владельца, который решает "продлевать или закрывать";
• оплаты идут с личных карт или без понятной схемы по юрлицам;
• не записаны админ-аккаунты и контакты восстановления;
• лицензий больше, чем активных пользователей.

Быстрый чеклист: что проверять регулярно

Чтобы учет не превращался в разовый проект, держите короткую регулярную проверку. Лучше 20 минут по расписанию, чем внезапная блокировка доступа или лишние списания.

Практичный ритм для большинства SMB:

• Раз в месяц: сравнить реестр с выпиской по карте/счету, отметить новые подписки и неожиданные списания, проверить изменения по пользователям.
• Раз в квартал: открыть топ-10 расходов и попросить владельцев подтвердить использование; выбрать 1-2 кандидата на оптимизацию.
• Раз в год: инвентаризировать договоры и условия, отдельно проверить автопродления и даты срабатывания.

Два момента, когда ошибки обычно стоят дороже всего: перед продлением и при увольнении сотрудника. Перед продлением получите подтверждение владельца и заранее решите, что делаете (продлеваем/уменьшаем/отключаем/меняем). В день ухода сотрудника отключите доступ, перенесите владение (админка, почта для счетов, доступ к платежам), а затем решите, можно ли переиспользовать лицензию.

Пример из жизни SMB: реестр на 12 сервисов

Компания на 40 человек быстро росла и подключала инструменты по мере надобности: CRM, видеосвязь, почту, бухгалтерию, задачи, файловое хранилище и другие подписки. В итоге набралось 12 сервисов, а покупали их кто и когда успевал.

Проблема проявилась в один месяц, когда совпали два крупных продления. Одно оплатили в последний момент, второе пропустили, потому что счет ушел на бывшего сотрудника. Сервис заблокировал доступ, отдел продаж на полдня остался без CRM, а бухгалтерия потом долго разбиралась со срочным платежом и штрафом.

Решение оказалось простым: один реестр в таблице, назначенные владельцы и календарь продлений. В реестре оставили только то, что помогает принимать решения: сервис и назначение, владелец, тип оплаты и период, количество лицензий и кому выданы, дата продления и дедлайн оплаты.

Владельцами стали руководители функций: продажи за CRM, финансы за бухгалтерию, HR за онбординг, IT за почту и доступы. Договорились, что при любом изменении владелец обновляет запись.

Через два месяца изменения стали заметны в быту: меньше срочных оплат, бюджет стал понятнее, новичков подключали быстрее, а "мертвые" лицензии перестали висеть годами.

Следующие шаги: закрепить процесс и масштабировать контроль

Когда реестр уже работает, следующий риск обычно связан с ростом: становится больше сервисов, появляются филиалы, усиливаются требования по безопасности и комплаенсу, а доступы раздаются быстрее, чем их успевают контролировать. В какой-то момент одной таблицы действительно может стать мало.

Выбирайте следующий шаг по реальной боли. Если чаще страдают деньги - усиливайте контроль продлений и уведомлений. Если страдают доступ и безопасность - начните с прав, групп и отключения аккаунтов при уходе. Если страдают согласования и отчетность - готовьте интеграцию с учетными системами и закупками.

Чтобы переход прошел спокойно, заранее соберите базовый "пакет данных": список сервисов по отделам, владельцев и запасных ответственных, правила продлений и критерии решений, принципы доступа и план действий при увольнении, историю оплат и документы.

В небольшой компании изменения обычно ведут IT и финансы: один отвечает за доступы и пользователей, второй за оплату и лимиты. Если сервисов много, есть филиалы или нужны регламенты под проверки, эту часть часто проще поручить интегратору, а внутри оставить владельцев и контроль.

Если нужна помощь с организацией корпоративных сервисов и инфраструктуры, GSE.kz как системный интегратор может подключиться: от проектирования контроля доступа и настройки процессов до поддержки 24/7, чтобы ключевые системы работали стабильно и предсказуемо.