Фантастические риски и где они обитают: как выбрать ПО для бизнеса

Часто мы выбираем продукты, основываясь только на их функциональности. Например, если захотелось салат, то мы не задумываясь покупаем его в магазине. Разбираться, что было в составе и когда истекает срок годности, мы будем только если отравились. Также и с программным обеспечением или технологиями для автоматизации.

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

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

Непосредственно проприетарной лицензии свойственны ограничения на коммерческое использование, распространение и модификацию.

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

Наконец, если заказчик окажется в кризисной ситуации и пропустит лицензионный платеж за программное обеспечение, то потеряет возможность его использовать, под угрозой окажутся данные компании и отдельные бизнес-процессы.

Чтобы избежать всех этих рисков, лучше выбирать ПО с открытым кодом.

На рынке есть мнение, что отсутствие vendor lock — это отсутствие вендора. То есть отсутствие сервиса, реакции на возникающие проблемы и возможности получить ответ на вопрос по продукту. Однако у любого сильного open source решения есть автор — это может быть конкретная компания, фонд или сообщество. Поэтому при выборе продукта с открытым кодом нужно разобраться, кто его развивает и какие опции поддержки предлагаются.

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

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

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

Будет полезно в целом изучить процесс разработки на GitHub или другом ресурсе. У сильного продукта коммиты происходят регулярно, к тому же, можно увидеть их авторов. Это скажет о решении больше, чем, например, дорожные карты.

Один из самых важных вопросов при выборе продукта — наличие на рынке специалистов, которые способны работать с ним, поддерживать и развивать. Если вендор использует редкие технологии или сертифицирует специалистов по многоуровневой шкале на коммерческой основе, то «стоимость» разработчиков будет очень высокой. Такая модель в первую очередь свойственна для проприетарных технологий, к примеру, одной широко известной на рынке СУБД из Германии, но не только для них. Оптимальный вариант — если решение с открытым кодом использует популярные среди разработчиков технологии и языки, а также обеспечивает максимально низкий порог входа за счет бесплатных и поддерживаемых в актуальном состоянии обучающих материалов в открытом доступе: тренингов, видеокурсов, текстовых мануалов. В этом случае заказчик сможет не только легко найти специалистов, но и выбрать среди них.

Показателем качества продукта являются референсы, количество пользователей и их мнения. Чтобы проверить это, можно зайти на площадку свободной поддержки — форум или другой ресурс. Это позволит узнать размер сообщества, его удовлетворенность, возникающие у пользователей проблемы, способы и скорость их решения. Можно даже пообщаться с кем-то из пользователей тет-а-тет. Если у 100 000 пользователей все получается и продукт развивается, то очень низка вероятность, что у кого-то одного что-то пойдет не так.

В России много сильных игроков, которые делают решения с открытым кодом. Среди них например компания BellSoft — один из мировых лидеров среди контрибьюторов Java. Или Базальт СПО, которые уже 20 лет делают решения системного уровня как для серверов, так и для рабочих станций. Мы в Haulmont с 2008 года занимаемся созданием сложных корпоративных приложений, с 2015 года разрабатываем собственную технологическую платформу CUBA и инструменты разработки на ней. Сегодня наше решение используют около 23 000 разработчиков по всему миру. И мы, в отличие от многих, практикуем DogFooding, то есть используем собственные инструменты. На платформе CUBA построены наши внутренние системы, наши заказные решений и наши продукты, которые успешно продающиеся в 40 странах мира.

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