Рассуждения об опенсорсе

Обсудим, в каких ситуациях опенсорс подходит крупному и среднему бизнесу для замещения ушедших с рынка инструментов.

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

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

Поиск замены более недоступному инструменту — действительно весьма распространенная причина внедрения сегодня. Но никакой крупный проект не существует в вакууме. Кроме условия «использовать российское» у бизнеса, а тем более у крупного, всегда есть ряд ограничений и требований, которые приходится учитывать. Поэтому на моей практике, в том числе в последний год, внедрение опенсорса чаще начинается с необходимости удовлетворить бизнес-требованиям, а импортозамещение выступает второстепенным условием. Так что и говорить о проектах будем в комплексе, опираясь на аргументы, которые были и остаются актуальными, вне зависимости от новостной повестки.

Не разработка с нуля и не проприетарный продукт

Начнем с базового позиционирования.

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

Собственная разработка

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

Ряд особенностей системы, в частности гибкость, должны закладываться на начальных этапах планирования архитектуры, или впоследствии их нельзя будет реализовать. Каждая такая «особенность» по-своему удорожает разработку, поэтому должна быть экономически обоснованной. Иными словами, проект должен быть основан не только на глубоком понимании текущего положения вещей в бизнесе, но и на представлении о наиболее вероятном пути его развития. При этом учесть все возможные пути тоже нельзя — слишком дорого.

В целом собственная разработка — это высокие требования к команде, большие сроки и стоимость реализации, а также риски, что инструмент так и не будет закончен.

Покупка проприетарного продукта

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

Зачастую эти несоответствия обусловлены как раз особенностями компании — ее ноу-хау. Банк выбирает свой способ скоринга клиентов, страховая по-своему считает риски и т.п. Как подстраиваться под такие ситуации, зависит от особенностей конкретного продукта. Иногда необходимо подстраивать свои бизнес-процессы под инструмент (под best practice, рекомендованные консультантами разработчика). А в каких-то системах может быть предусмотрена настройка таких моментов.

Любая кастомизация будет оплачиваться отдельно по тарифам вендора или его официального партнера. А реалистичность такой кастомизации зависит от конкретного продукта.

Решение на опенсорс-платформе

Внедрение решения на базе платформы с открытым исходным кодом в определенных ситуациях позволяет оптимизировать затраты и риски. Поскольку в основе — опенсорс, оплата лицензии и привязка к одному поставщику отсутствуют. Но при этом в решении уже есть некий «каркас», вокруг которого можно строить реализацию индивидуальных потребностей.

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

Мне в опенсорсе нравится гибкость с точки зрения сроков внедрения. Когда мы запускали CRM в стартапе, базовые необходимые задачи (звонки, продукты, интеграцию с веб-мастерами) сделали примерно за месяц. Это ровно тот срок, который был им необходим для найма людей, их обучения и т.д. То есть стартап сразу запустился с CRM. Но конечно же, инструмент потом дорабатывали под изменения и рост компании. А в банке мы честно дорабатывали систему по объемному ТЗ около 6 месяцев, и это не считая долгой отладки интеграций и загрузки начальных данных.

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

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

С опенсорсом возможна глубокая кастомизация под задачу

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

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

Распространенный сценарий, когда кастомизация требуется не сегодня, а когда-нибудь в будущем. Это как в примере с запуском отдела продаж — базовые «хотелки» для CRM есть и сегодня, в принципе им удовлетворяет широкий круг решений. Взять проприетарное решение можно достаточно быстро (иногда просто по клику на сайте — в аренду). Однако непонятно, когда бизнес упрется в ограничения тарифа или коммерческого продукта в целом, которые окажутся для него критичными.

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

В нашей практике встречались даже запросы на доработки на уровне архитектуры (из-за требований службы безопасности заказчика). Было и перестроение логики системы. Например, для подразделения крупного международного консалтингового агентства в сфере бизнес-недвижимости мы совмещали в одной CRM несколько разных воронок продаж, у каждой из которых своя логика расчета маржинальности (причем, еще и с учетом мультивалютности). Эти доработки заняли у нас около 5 месяцев. Но с клиентом продолжаем работать уже почти 7 лет — автоматизируем новые процессы, поддерживаем изменения в бизнесе и т.п.

С опенсорсом такое вполне реально. Конечно, чем масштабнее доработки, тем дороже они будут стоить. Но о затратах нужно говорить отдельно.

Опенсорс — не бесплатно и не всегда дешевле проприетарного продукта

• Лицензии. Оплачиваются единоразово или за период, проект внедрения — поэтапно. В случае крупного бизнеса это сотни тысяч долларов в год.
• Проекта внедрения. Его стоимость закладывается в смете.
• Поддержки. В определенном объеме она может закладываться в лицензионные платежи. Сверх этого объема обычно включается почасовая ставка, размер который определяется или согласуется с вендором (обычно она заметно выше стоимости часа работы среднего разработчика с рынка труда).

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

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

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

Стоимость проекта внедрения неоднозначна. В зависимости от потребностей бизнеса она может оказаться как дешевле, так и дороже проприетарного инструмента. Как правило, вариант «дороже» как раз подразумевает внесение экзотических изменений (иначе выгоднее действительно внедрить продукт от вендора). В этом случае важно то, насколько эти изменения критичны для бизнеса.

Последующая поддержка определяется стоимостью работы разработчиков. Стоимость часа специалиста, работающего с опенсорсной платформой, может быть в 1,5 — 2 раза ниже ставки разработчика под дорогие проприетарные системы. Но объем трудозатрат зависит от проекта.

В сухом остатке — за опенсорс придется в любом случае заплатить. Как я отмечал выше, весьма вероятно, что проект окажется дешевле, чем внедрение проприетарного решения. Но в общем случае это не гарантировано.

Опенсорс вполне безопасен, если грамотно выбирать платформу

Согласно распространенному мифу проприетарное решение от вендора безопаснее опенсорса. Но на мой взгляд это вопрос, требующий обсуждения.

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

В то же время от закладок в закрытых решениях никто не застрахован. Не имея возможности проанализировать исходники, вы никогда не заметите признаков их активности, пока они не сработают. Гарантом для клиента является «доброе имя» вендора или сертификация, если вендор прошел эту процедуру. Но далеко не все инструменты для крупного бизнеса сертифицированы.

Так или иначе, если для решения вопросов безопасности с опенсорсом и продуктом собственной разработки можно что-то сделать собственными силами, то с проприетарным инструментом все в руках производителя. И не только в вопросе безопасности.

Опенсорс исключает блокировку на вендоре и подрядчике, но не дает гарантий развития

Крупному бизнесу сложно менять используемые продукты и партнеров по разработке.

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

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

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

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

Сравнивая опенсорс с собственной разработкой, сложно объективно оценить деньги, но можно поговорить о рисках.

При разработке собственной платформы с нуля заказчик очень зависит от подрядчика и его команды (или собственной команды, если все происходит инхаус) — какой на проекте будет архитектор, насколько глубоко он продумает систему с точки зрения нагрузок, безопасности и прочих требований. Если по каким-то причинам этот человек с проекта уйдет, придерживаться стандартов качества уже не получится. А если уйдет вся команда, проект попросту встанет. Даже при наличии подробной документации срок введения в курс дела новой команды начинается от нескольких месяцев.

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

У любого преимущества есть обратная сторона. В данном случае отсутствие одного производителя или команды, отвечающей за развитие, — это отсутствие гарантии уверенного развития продукта определенным курсом в течение длительного времени.

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

У опенсорсного решения не обязательно есть вендор. Иногда за платформу в основе несет ответственность только некоммерческое сообщество, которое может прекратить свое существование или сменить вектор развития. А даже если вендор есть, он не связан с заказчиками договорными обязательствами. Единственная гарантия для клиента — искать зрелые опенсорсные решения, которые существуют годами, курируются большими сообществами и поддерживаются в том числе коммерческими организациями. Linux — отличный пример. Практика показывает, что если вокруг опенсорсной платформы формируется целое сообщество компаний, которые ее внедряют и кастомизируют, вероятность, что она развивается в ногу со временем, достаточно высока.

Вместо итогов

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

Автор:

Луневский Дмитрий, директор по развитию компании Куб3