Как провалить проект внедрения опенсорса

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

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

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

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

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

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

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

Так или иначе, используя проприетарное решение, риск не получить вообще ничего существенно ниже. Но за лицензии придется заплатить, а если решение куплено по подписке, платить придется регулярно. Любая кастомизация будет оплачиваться отдельно, а ее реализуемость зависит от конкретного продукта.

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

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

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

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

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

Вот как следует действовать, если хотите провалить проект.

У опенсорса, как правило, есть некая “готовая сборка”, которая удовлетворит базовые требования. Но зачастую это малая часть того, что может платформа - вершина айсберга. Основные возможности платформы в ее расширяемости.

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

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

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

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

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

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

Не все понимают, что продукт с открытым исходным кодом - это не про бесплатный сыр. Но если не говорить об экзотике, внедрить его будет дешевле, чем поставить сторонний продукт или разработать свое.

Стоимость проприетарного инструмента для крупного бизнеса складывается из трех компонент:

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

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

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

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

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

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

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

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

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

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

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

Однако этот выбор придется сделать. Иначе все ограничится базовым функционалом.

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

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

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

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

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

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

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

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

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

Лично я работаю с внедрением опенсорсной CRM уже 14 лет. Опыт показывает, что платформа с открытым исходным кодом может быть достойной альтернативой проприетарному продукту или собственной разработке. Однако важно “уметь ее готовить”. Если начинать проект без оглядки на особенности работы с опенсорсом, совершая все перечисленные ошибки, то с большой долей вероятности он так и не будет закончен.

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