Как компании не стать заложником айтишников

Самостоятельная разработка ПО

Вендор-лок (vendor lock) — это зависимость поставщика или клиента от продуктов или услуг одного разработчика ПО. Проще говоря, монополия. Проблема стала заметнее, когда зарубежные поставщики софта покинули российский рынок.

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

Во-первых, не все компании имеют такую возможность. Во-вторых, всегда есть риск попасть в жёсткую зависимость от своих собственных специалистов, что называется тим-лок (team lock).

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

В каких случаях это оправдано

Если речь идёт о вашем уникальном конкурентном преимуществе, и вы создаёте что-то принципиально новое, чего на рынке ещё никто не делал.

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

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

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

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

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

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

По теме. Экосистема Java: популярные инструменты и будущее языка программирования

ПО от поставщика

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

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

На что стоит обратить внимание при общении с потенциальными поставщиками

Кто продает продукт. На первом этапе обратите внимание, кто продаёт продукт со стороны вендора. Принимает ли участие в переговорах только менеджер по продажам или технические специалисты тоже?

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

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

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

Неочевидные вопросы, которые стоит задать во время референс-визита:

• из каких решений выбирали;
• почему не стали делать собственными силами;
• какие «грабли» были в проекте?

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

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

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

На 100% от таких случаев не застраховаться. Но тогда вендор должен объяснить, почему изменения невозможны. Например, они могут замедлять производительность системы и негативно влиять на её core-функцию.

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

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

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

Сроки. Еще один важный вопрос: уложится ли вендор в заявленные сроки? Хватит ли ему ресурсов? Какие риски он видит в проекте? Компания-заказчик может в полной мере не осознавать масштабы проекта и его трудности. Поэтому хорошая практика со стороны вендора — предупредить, что и когда может пойти не так.

Что же выбрать: вендорское решение или самостоятельную разработку

С одной стороны, разработать самостоятельно можно всё. Но прежде чем стартовать, узнайте, что есть на рынке, какие там возможности и сложности. Как минимум, общение с профильными вендорами поможет уточнить ТЗ для собственной команды.

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

Спросите себя, стоит ли разрабатывать новую АБС, MDM или другую систему? Или стоит вложить эти усилия в разработку того, чего ещё нет у ваших конкурентов? Готовы ли вы рискнуть карьерой, если результата в установленные сроки не будет и разработка завязнет?

Задайте себе больше вопросов:

1. Является ли вашим основным бизнесом то, что вы хотите разработать?
2. Есть ли экспертиза у вас внутри или на рынке, чтобы это разработать?
3. Уверены ли вы в том, что удастся создать рабочую систему, которая не будет отставать от того, что уже есть на рынке?

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

Фото на обложке: Freepik