Переход на открытое программное обеспечение: когда он окупается, а когда нет

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

Из чего складывается стоимость перехода

• Миграция данных и настроек, включая то, что накопилось за годы и не документировано.
• Доработка недостающей функциональности, которая в коммерческом продукте была из коробки.
• Обучение и снижение производительности на период адаптации.
• Поддержка: собственная команда или подписка у интегратора, что фактически возвращает часть лицензионных платежей.
• Интеграции со смежными системами, которые придётся переписывать.

Когда переход оправдан

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

Как считать

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

Такую оценку мы делаем в рамках оценки перехода на open source, отдельно по каждому классу систем, а не по всему ландшафту сразу.

Промежуточные варианты

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

Где чаще всего недооценивают трудоёмкость

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

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

Связь с общей экономикой ИТ

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

Что проверить в продукте до решения

Полезно посмотреть на проект как на поставщика: кто им управляет, как часто выходят обновления, сколько активных участников, что происходило при обнаружении уязвимостей. Такая проверка делается по той же логике, что и технологический Due Diligence коммерческого продукта.