«Ты проверяешь не код, а скрытые обязательства. Под каждым слоем технологии лежит финансовый и репутационный риск. Российский контекст добавляет свои фильтры: проверки регуляторов, импортозамещение, кадровые договорённости. Часто смотрят на последний год, но ошибки, заложенные пять лет назад, уже не исправить».
Что такое Due Diligence и почему он решает всё
Due diligence, это системная проверка всех аспектов бизнеса перед сделкой. Это не аудит на соответствие стандартам, а оценка реальных рисков, которые перейдут к новому владельцу. В IT-сфере фокус смещается с материальных активов на нематериальные: код, данные, интеллектуальную собственность, команду и цифровые процессы. Пропущенная ошибка на этом этапе может превратить перспективный стартап в долгосрочный судебный спор или проект по замене всей инфраструктуры.
Семь направлений проверки вместо одиннадцати
Классические методики предлагают десяток направлений проверки, но в российских IT-сделках критичными становятся семь.
1. Проверка активов: что на самом деле покупается
Здесь мало составить реестр серверов и лицензий. Нужно подтвердить права на каждый значимый актив.
- Права на код и ПО: Проверяются репозитории, история коммитов, наличие сторонних библиотек и их лицензии (GPL, MIT, Apache). Ключевой вопрос: есть ли в коде компоненты, написанные внештатными разработчиками или подрядчиками, на которые нет чёткого договора о передаче прав? Нередко обнаруживаются скрипты, написанные «по дружбе» и не оформленные юридически.
- Интеллектуальная собственность: Патенты, товарные знаки, доменные имена. Проверяется чистота патентов, сроки регистрации доменов, соответствие товарных знаков реально используемым названиям продуктов.
- Оборудование и инфраструктура: Составляется инвентаризационная опись. Особое внимание — к оборудованию, взятому в лизинг или аренду, а также к технике, физически находящейся в офисе, но юридически принадлежащей сотрудникам (BYOD-политика).
2. Юридический аспект: скрытые обязательства и споры
Проверяются все договоры, которые могут создать обязательства для нового владельца.
- Договоры с клиентами (SLA): Анализируются гарантии uptime, штрафы за простой, условия расторжения. Долгосрочные контракты с низкой маржинальностью становятся обузой.
- Договоры с поставщиками: Условия с облачными платформами, хостинг-провайдерами, CDN. Есть ли в них штрафы за досрочное прекращение? Часто стоимость миграции с закрывающегося российского аналога зарубежного сервиса не заложена в сделку.
- Судебные истории и претензии: Запрашивается информация о всех текущих и потенциальных судебных разбирательствах, в том числе о невыполненных претензиях со стороны клиентов или регуляторов.
3. Финансовая проверка: как работают IT-затраты
Финансовая картина в IT часто искажена из-за особенностей учёта.
- Структура затрат: Анализируется, какая часть расходов идёт на зарплаты, на инфраструктуру, на лицензии. Резкий рост инфраструктурных затрат может сигнализировать о неэффективной архитектуре.
- Капитализация R&D: Проверяется, как компания учитывает затраты на разработку: списывает на расходы или капитализирует. Это влияет на балансовую стоимость и будущие амортизационные отчисления.
- Долговые обязательства: Учитываются не только банковские кредиты, но и технические долги перед командой, выражающиеся в необходимости масштабного рефакторинга.
4. Регуляторный compliance: ФСТЭК, 152-ФЗ, импортозамещение
Это направление стало критичным для российских компаний, работающих с госсектором или персональными данными.
- Соответствие 152-ФЗ: Проверяется наличие модели угроз, политики обработки ПДн, назначен ли ответственный. Несоответствие грозит многомиллионными штрафами.
- Требования ФСТЭК: Для систем, относящихся к ГИС, проверяется наличие всех необходимых сертификатов и протоколов защиты информации. Отсутствие — прямое препятствие для работы с рядом заказчиков.
- Импортозамещение: Составляется матрица используемого ПО: операционные системы, СУБД, средства разработки. Оцениваются риски и стоимость перехода с иностранного ПО на российские аналоги, если это необходимо для контрактов.
5. Технический аудит: состояние кода и инфраструктуры
Проводится глубокий анализ того, как устроена технологическая часть бизнеса.
- Архитектура и документация: Существует ли актуальная техническая документация? Насколько система монолитна или микросервисна? Оценивается связность и сложность кодовой базы.
- Инфраструктура как код (IaC): Проверяется наличие конфигураций для Terraform, Ansible или аналогов. Их отсутствие означает, что инфраструктура, это «рукописные» настройки в головах системных администраторов, что является ключевым риском.
- Безопасность: Проводятся или анализируются результаты последних пентестов, аудитов безопасности кода (SAST), проверки зависимостей (SCA). Ищутся известные уязвимости в используемых стеках.
6. Кадровый аспект: кто создаёт ценность
В IT-компании главный актив — люди. Их уход после сделки может обнулить её ценность.
- Ключевые разработчики: Кто является носителем экспертизы по ядру продукта? Проверяются трудовые договоры, наличие соглашений о неконкуренции (хотя в России их сила ограничена) и условий о передаче прав на результаты интеллектуальной деятельности.
- Мотивация и бонусы: Анализируются схемы мотивации (опционы, KPI), которые могут быть привязаны к текущему владельцу. Необходимо смоделировать, как изменится поведение команды после сделки.
- Организационная структура: Выявляются «силовые линии» и неформальные лидеры, от которых зависит принятие решений и скорость разработки.
7. Операционная деятельность: как всё работает изо дня в день
Проверяются процессы, а не только их описание.
- DevOps и CI/CD: Насколько процессы сборки, тестирования и развёртывания автоматизированы? Существует ли «фабрика сборки» или каждый релиз, это ручная работа и молитва.
- Мониторинг и инцидент-менеджмент: Есть ли система мониторинга ключевых метрик? Как компания реагирует на сбои? История инцидентов может показать хронические проблемы инфраструктуры.
- Бэкапы и DRP: Проверяется не только факт наличия резервных копий, но и процедура их тестового восстановления. Последняя успешная проверка — главный показатель.
Порядок действий: не параллель, а последовательность
Проверку не стоит запускать по всем направлениям одновременно. Эффективная последовательность создаёт фильтры, отсекая заведомо провальные сделки на ранних этапах.
- Предварительный анализ и NDA. Подписание соглашения о неразглашении. Сбор открытых данных: судебные базы, реестры товарных знаков, отзывы на профильных платформах.
- Юридический и финансовый срез. Проверка базовой юридической чистоты и финансовой устойчивости. Если здесь обнаруживаются непреодолимые проблемы (крупные иски, скрытые долги), дальнейшую проверку можно останавливать.
- Регуляторный аудит. Оценка compliance с 152-ФЗ и отраслевыми требованиями. Для IT-компаний, не работающих с ПДн или госсектором, этот этап может быть упрощён.
- Глубокий технический и кадровый Due Diligence. Самый ресурсоёмкий этап. Включает анализ кода, интервью с ключевыми техлидами, оценку инфраструктуры. Здесь выявляется реальная техническая ценность и риски.
- Формирование отчёта и переговоры. Все найденные риски ранжируются по критичности и стоимости нивелирования. Это становится основой для корректировки цены сделки или включения в договор гарантий и компенсаций (representations and warranties).
Частые ошибки и слепые зоны
- «Зелёная» команда. Покупка компании с перспективным продуктом, но командой из неопытных junior-разработчиков. После ухода одного-двух senior’ов развитие продукта останавливается.
- Технический долг как чёрный ящик. Его объём часто скрывается или недооценивается продавцом. Необходимо заказывать независимый аудит кода, а не полагаться на внутренние отчёты.
- Зависимость от одного человека или клиента. Если 80% выручки или 90% экспертизы по ядру системы зависят от одного субъекта, это фундаментальный бизнес-риск, а не IT-проблема.
- Игнорирование российской специфики регуляторики. Несертифицированное криптосредство для хранения паролей или иностранный мессенджер для служебной переписки могут стать причиной предписаний от ФСТЭК.
Итог: превратить проверку в инструмент
Due Diligence, это не формальность для отчётности инвестору, а основной инструмент управления рисками при слиянии и поглощении. Его цель — не сорвать сделку, а сделать её прозрачной. Правильно проведённая проверка позволяет не только снизить цену, но и составить реалистичный план интеграции и развития на годы вперёд. В российских реалиях к классическим техническим и финансовым рискам добавляется слой регуляторных требований и вопросов технологического суверенитета, что делает Due Diligence не просто полезной, а обязательной практикой.