Что произошло
Первая волна импортозамещения решала задачу со сроком: заменить продукт иностранного вендора до даты, после которой его использование становилось невозможным или рискованным. Критерии выбора соответствовали задаче — наличие в реестре отечественного ПО, совместимость с текущими системами, срок поставки и внедрения. Цена обсуждалась во вторую очередь, качество сопровождения — в третью. Выбирали то, что можно поставить быстро.
Сегодня значительная часть компаний прошла эту волну и живёт с её результатами. Результаты неоднородны. Часть решений работает и развивается. Часть работает, но каждое изменение превращается в переговоры с подрядчиком. Часть требует повторной замены, потому что поставщик не выдержал нагрузки или не выполнил дорожную карту. По отраслевым опросам и по нашему опыту проектов, вопрос «что заменить» уступил место вопросу «во что это обходится в год и что будет через три года».
Критерии выбора сместились. Вместо срока замены — управляемость инфраструктуры: насколько компания контролирует то, что у неё стоит. Вместо наличия в реестре — предсказуемость поддержки: кто и в какие сроки решит проблему. Вместо совместимости на момент внедрения — возможность развивать систему: во что обойдётся следующее изменение и кто его сможет сделать.
Это сдвиг от логики закупки к логике владения. Закупка заканчивается актом приёмки, владение — нет.
Анатомия сдвига
Почему скорость перестала быть критерием
Сроки замены для большинства категорий известны и зафиксированы. Компании, которые ещё не начали, планируют по датам, а не в режиме аврала. Кроме того, быстрые замены первой волны показали характерную картину: система стоит, работает, но не развивается, потому что при выборе никто не проверял, как в ней делаются изменения. В итоге затраты переместились из графы «лицензии» в графу «сопровождение и доработки», и эта графа оказалась больше.
Скорость по-прежнему важна как ограничение — есть даты, которые нельзя сдвинуть. Но среди решений, которые в даты укладываются, выбирают не то, которое внедряется быстрее, а то, которым потом дешевле владеть.
Стоимость следующего изменения как метрика
Самый полезный вопрос при сравнении решений — не «сколько стоит внедрение», а «сколько будет стоить типовое изменение через год». Под изменением понимается конкретный перечень: добавить поле в форму, подключить новую систему, построить новый отчёт, обновить версию платформы, перенести на другую инфраструктуру, расширить число пользователей.
Стоимость изменения складывается из нескольких компонентов, и каждый можно проверить до покупки:
- Доступ к коду и конфигурации. Если изменение может сделать только вендор, стоимость определяет вендор.
- Документация. Если изменение требует реверс-инжиниринга, к стоимости работы добавляется стоимость исследования.
- Тестовое покрытие и среды. Если нет автоматических проверок и тестового контура, каждое изменение тестируется вручную в продуктиве.
- Доступность людей. Если компетенция по системе есть только у одного человека, изменение ждёт его очереди.
- Открытость интерфейсов. Если интеграция возможна только через проприетарный коннектор, каждая новая связь — отдельный контракт.
Вопрос вендору или подрядчику формулируется так: «Покажите, как в вашей системе выполняется вот это изменение, кто его делает, сколько занимает и что для этого нужно от нас». Ответ — конкретный или уклончивый — говорит больше, чем презентация.
Заменяемость подрядчика
Управляемость инфраструктуры сводится к простому тесту: что произойдёт, если завтра подрядчик перестанет работать. Не из-за конфликта — по любой причине: продажа бизнеса, уход ключевых людей, смена приоритетов. Ответы делятся на три группы: «ничего, продолжим сами или с другими», «остановимся на месяцы», «не знаем».
Признаки заменяемости, которые проверяются до подписания договора:
- Код и конфигурации хранятся в репозитории заказчика, а не у подрядчика.
- Инфраструктура описана как код, развёртывание воспроизводимо без участия конкретного человека.
- Документация актуальна и включает не только «как пользоваться», но и «как устроено» и «как менять».
- В договоре зафиксированы права на результат, порядок передачи и обязательства по передаче знаний.
- Есть хотя бы один инженер заказчика, который участвовал в работе и понимает систему.
Подрядчик, который сопротивляется этим требованиям, сообщает о себе важное: его модель заработка построена на незаменимости. Подрядчик, который принимает их как норму, зарабатывает на качестве следующей работы.
Документация и открытые интерфейсы
Открытые интерфейсы — это не идеологический выбор, а экономический. Система с документированным API, стандартными протоколами обмена и понятными форматами данных подключается к чему угодно силами любой команды. Система с закрытым интерфейсом подключается только силами вендора и только на его условиях.
Что считать открытым интерфейсом на практике:
- Доступ к данным через SQL или документированный API, а не только через экспорт из интерфейса.
- Обмен событиями через стандартные брокеры, например Kafka, или документированные веб-хуки.
- Спецификация API в машиночитаемом формате, например OpenAPI, с версионированием.
- Возможность выгрузить все данные в открытом формате при расторжении договора.
Документация здесь — не формальность, а часть продукта. Отсутствие документации по интерфейсам означает, что интерфейс закрыт, даже если технически он существует.
Экономика владения на горизонте трёх-пяти лет
Стоимость владения считается по компонентам, и у каждого свой источник. Полезно оформить таблицу и заполнить её для каждого варианта — включая вариант «ничего не менять», если он допустим.
| Компонент | Что входит | Где искать данные |
|---|---|---|
| Лицензии и подписки | Стоимость права использования, рост при масштабировании | Коммерческое предложение, правила лицензирования |
| Инфраструктура | Серверы, хранилища, сеть, резервирование | Требования вендора, собственные расчёты |
| Внедрение и миграция | Работы, перенос данных, параллельная эксплуатация | Предложение подрядчика, оценка своих затрат |
| Сопровождение | Поддержка вендора, внутренняя команда, инциденты | Условия SLA, штатное расписание |
| Изменения | Типовые доработки за период по каталогу изменений | Ответы вендора на вопросы о стоимости изменений |
| Люди | Обучение, найм, удержание специалистов по системе | Рынок труда, планы по персоналу |
| Риск выхода | Стоимость повторной замены при уходе вендора | Оценка заменяемости, условия договора |
Горизонт в три-пять лет выбран не случайно. Меньше — не видны затраты на изменения и риски вендора. Больше — слишком много неопределённости. В этом горизонте разница между вариантами обычно проявляется в строках «изменения» и «люди», а не в строке «лицензии».
Дешёвое внедрение с дорогими изменениями обходится дороже, чем дорогое внедрение с дешёвыми изменениями, — на любом горизонте длиннее года.
Как это выглядит на практике
Производственная компания и миграция базы данных. При замене СУБД выбрали вариант с минимальным сроком и ценой внедрения. Подрядчик перенёс данные и схему, система заработала. Через несколько месяцев потребовалось изменить структуру хранения под новый отчёт — выяснилось, что миграционные скрипты, тестовые данные и описание нестандартных решений остались у подрядчика, занятого другими проектами. Изменение, которое своя команда сделала бы за дни, заняло недели переговоров. На следующем этапе компания включила в критерии выбора передачу всех артефактов и участие своих инженеров.
Банк из первой сотни и выбор платформы. Сравнивались два решения. Первое — дешевле и быстрее, с закрытым API и обязательным сопровождением вендора. Второе — дороже на этапе внедрения, с открытым API, документацией и возможностью доработок своими силами. Банк составил каталог типовых изменений на три года и запросил у обоих вендоров оценку каждого. Суммарная стоимость владения второго варианта оказалась ниже уже на втором году, и решение приняли в его пользу.
Розничная сеть и отложенная замена. Система, подлежащая замене, работала стабильно, а сроки позволяли подождать. Вместо быстрой замены компания вложилась в слой адаптеров: вынесла интеграции в отдельный сервис с открытыми интерфейсами. Когда пришло время замены, менять пришлось только систему, а не все связи с ней. Замена прошла как плановая работа, а не как проект спасения.
Что это значит для российской компании
Регуляторные требования никуда не делись: реестр отечественного ПО, требования к субъектам КИИ со сроком 1 января 2028 года для значимых объектов, требования 152-ФЗ к хранению данных. Они формируют обязательный спрос. Но обязательный спрос создаёт рынок поставщиков, а не рынок качества. Наличие в реестре подтверждает происхождение, а не управляемость.
Отечественный рынок решений неоднороден, и это нормально для рынка, который вырос быстро. Есть зрелые продукты с историей внедрений, открытыми интерфейсами и командой поддержки. Есть продукты на базе открытого кода с минимальными изменениями — для них важен вопрос, кто будет переносить исправления при расхождении с исходным проектом. Есть продукты, которые существуют как обещание дорожной карты. Различить их можно только по критериям выше: как делаются изменения, что с документацией, что с заменяемостью.
Кадровый рынок усиливает эффект. Специалистов по отечественным платформам меньше, чем по замещаемым продуктам, и они дороже. Решение, для сопровождения которого нужны редкие специалисты, автоматически дороже во владении. Решение на распространённом стеке — PostgreSQL, Linux, стандартные протоколы — сопровождается людьми, которых можно найти.
Закрытый контур добавляет требование: подрядчик работает внутри периметра заказчика, в его процессах, на его инфраструктуре. Это ограничивает выбор подрядчиков, но одновременно упрощает контроль: результат остаётся в контуре, передача происходит по факту работы, а не по акту.
Мы исходим из того, что проект должен окупаться для заказчика, и готовы отказаться от него, если экономика не сходится. Такой подход возможен только при открытых критериях сравнения — когда заказчик сам видит, где польза, а где формальное выполнение требования.
Что делать: пошагово
- Составьте каталог изменений. Перечень из десяти-двадцати изменений, которые с высокой вероятностью потребуются за три года: интеграции, отчёты, масштабирование, обновления, смена инфраструктуры. Это ваш инструмент сравнения — общий для всех вариантов.
- Определите критерии и способ проверки каждого. Для каждого критерия — не оценка «хорошо/плохо», а конкретный вопрос вендору и конкретный артефакт, который подтверждает ответ.
- Запросите оценку стоимости изменений. Отправьте каталог всем участникам сравнения и попросите оценить каждое изменение: кто делает, сколько занимает, что нужно. Отказ или общий ответ — это тоже данные.
- Проверьте заменяемость. Запросите примеры документации, доступ к тестовому стенду, условия передачи кода и данных. Поговорите с компаниями, которые уже эксплуатируют решение, — про изменения, а не про внедрение.
- Посчитайте владение на три-пять лет. По таблице компонентов, для каждого варианта, включая вариант отложенной замены, если он допустим по срокам.
- Проведите пилот с реальным изменением. Не демонстрацию, а выполнение одного изменения из каталога на тестовом контуре силами вашей команды при поддержке вендора. Время и трудности пилота — лучший прогноз стоимости изменений.
- Закрепите условия в договоре. Права на результат, репозиторий заказчика, передача знаний, условия выхода, выгрузка данных. Это дешевле обсуждать до подписания.
- Примите решение по стоимости владения, а не по цене внедрения. И зафиксируйте, по каким критериям оно принято, — чтобы через год можно было проверить прогноз.
Таблица критериев, которую мы используем в сравнениях, выглядит так:
| Критерий | Что проверяем | Признак риска |
|---|---|---|
| Стоимость изменения | Оценка типовых изменений из каталога | Общие ответы, «зависит от задачи» |
| Заменяемость подрядчика | Код и конфигурации у заказчика, воспроизводимое развёртывание | «Мы всё сделаем сами, вам не нужно» |
| Открытость интерфейсов | Документированный API, стандартные протоколы, выгрузка данных | Интеграции только через вендора |
| Документация | Описание устройства и порядка изменений | Только пользовательские инструкции |
| Предсказуемость поддержки | SLA, порядок эскалации, история инцидентов | Поддержка через личные контакты |
| Кадровая доступность | Наличие специалистов на рынке, стек | Уникальный стек без сообщества |
| Дорожная карта | Выполненные обещания за прошлые периоды | Только будущие планы |
| Условия выхода | Порядок передачи, выгрузка данных, права | Нет раздела о расторжении |
Типичные ошибки
- Сравнение по цене внедрения. Почему плохо: цена внедрения — меньшая часть стоимости владения, и она известна точнее всего, поэтому на ней сосредотачивается внимание. Что вместо: сравнение по стоимости владения с каталогом изменений.
- Реестр как критерий качества. Почему плохо: реестр подтверждает соответствие формальным требованиям, а не зрелость продукта. Что вместо: реестр — обязательное условие, а выбор среди тех, кто ему соответствует, — по управляемости.
- Договор без условий выхода. Почему плохо: заменяемость проверяется в момент, когда договориться уже сложно. Что вместо: права, передача, выгрузка данных — в договоре до подписания.
- Оценка по обещаниям дорожной карты. Почему плохо: обещание не имеет стоимости для вендора и имеет для вас. Что вместо: смотреть на выполнение прошлых обещаний и брать в расчёт только то, что есть.
- Отсутствие своего инженера в проекте. Почему плохо: после ухода подрядчика знание уходит вместе с ним. Что вместо: как минимум один сотрудник заказчика участвует в работе с первого дня, и это условие договора.
Как понять, что вы на верном пути
- Для каждого решения в ландшафте известна стоимость типового изменения, и она проверена хотя бы одним реальным изменением.
- Код, конфигурации и описание инфраструктуры каждого решения находятся в репозиториях компании.
- Для каждого подрядчика есть ответ на вопрос «что будет, если он уйдёт», и этот ответ не «остановимся».
- Сравнение вариантов проводится по одной таблице критериев с зафиксированными способами проверки.
- Стоимость владения рассчитана на три-пять лет и пересматривается ежегодно по факту.
- В ИТ-службе есть сотрудники, которые могут внести изменение в каждую ключевую систему, — или известен план, как их получить.
Вопросы, которые нам задают
Открытые интерфейсы и передача кода — не выйдет ли дороже на старте? Обычно да, ненамного — за документацию, тесты, участие ваших инженеров. Эта разница окупается первым же изменением, которое вы сделали сами или с другим подрядчиком. Если изменений не планируется вообще, система, вероятно, не критична, и её выбор не стоит такого анализа.
Как оценивать стоимость изменений, если вендор отказывается давать оценки? Отказ — уже оценка: стоимость изменений будет определяться вендором в момент, когда у вас не будет альтернатив. Если решение всё же выбрано, включите в договор фиксированные ставки и сроки на изменения по каталогу.
Что делать, если решение уже внедрено и оказалось неуправляемым? Не менять сразу. Сначала вынести интеграции в отдельный слой с открытыми интерфейсами, получить доступ к коду и конфигурациям, обучить своих людей. Это снизит стоимость последующей замены и, возможно, сделает её ненужной.
Начните с одной системы, которую предстоит заменить в ближайший год: составьте для неё каталог изменений и запросите оценки у претендентов. Разница в ответах покажет, кто из них продаёт внедрение, а кто — владение.