Как стать автором
Обновить
27.71
Factory5
Цифровые решения для промышленности и логистики

Build vs buy: покупать софт у вендора или разрабатывать собственное IT-решение?

Время на прочтение6 мин
Количество просмотров4K

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

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

Build – для больших и инновационных

Российским управленцам старой закалки зачастую кажется, что их процессы уникальны, менять в них что-то – сложно и дорого, проще подстроить систему под процессы. Так начинаются попытки «натянуть ежа на мячик» – сильно кастомизировать IT-продукт под внутренние процессы предприятия, и такой путь редко завершается успехом.

А бывает так, что молодой, энергичный, немного разбирающийся в IT руководитель говорит: «Это всё можно сделать самим, сейчас посадим программиста или наберём отдел, настроим Agile-процессы, сделаем своё». Такое решение бывает связано и с тем, что компания не нашла подходящего вендора, или когда есть повышенное стремление всё контролировать. Часто это происходит в банковской сфере, где ещё и сильно пекутся о данных – компания не готова загружать их в облачные сервисы и делиться ими с партнёрами. Но даже здесь build-решения можно успешно сочетать с рыночными. 

Build актуален для крупных корпораций, где есть большие бюджеты и стремление разрабатывать своё, чтобы потом коммерциализировать. Успешный пример реализации такого подхода – «Сбер» с его «Сбертехом». Для отраслей финтеха и телекома разумно вкладываться во внутреннюю разработку, так как эти организации уже обладают существенной экспертизой в IT.  А вот у КамАЗа, который разрабатывал свою технологию для мониторинга состояния, коммерциализировать свой продукт не получилось. Всё потому, что разработка не является корпоративной компетенцией в машиностроении, в то время как работа современных банков полностью строится на IT-технологиях.

Build подходит инновационным компаниям, для которых IT – одно из направлений долгосрочной стратегии развития. При этом важно грамотно рассчитать соотношение решаемых задач и затрачиваемых ресурсов. Так, например, «Северсталь» собрала большую команду разработки, которая занимается практически всем: оптимизирует процессы производства, тестирует гипотезы по улучшениям. Но такой путь сложно назвать успешным, если трудностей несоизмеримо больше, чем количество внутренних ресурсов на их решение.

Плюсы разработки собственного ПО

  • Отсутствие цепочки «заказчик-вендор-интегратор». Это важно в тех случаях, когда у компании часто возникает потребность быстро внедрять новые фичи – нет времени на взаимодействие с вендором и оформление допсоглашений.

  • Сохранение конфиденциальных данных внутри компании.

  • Решения кастомизируются под конкретные процессы компании – это важно, когда IT является одной из корпоративных компетенций организации.

Какие трудности и риски несёт такой подход?

  • Формирование экспертизы, несвойственной основной деятельности компании, может занять много времени и ресурсов.

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

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

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

Buy – для сфер, где эффективность является базой конкурентоспособности

Альтернатива собственной разработке – взять готовое решение, где в «коробке» зашиты лучшие практики, подтвержденные международными стандартами и опытом индустрии. Барьером может послужить то, что в этом случае компании придётся менять бизнес-процессы и оргструктуру, оптимизировать работу отделов, возможно даже сокращать штат. Предприятие может сопротивляться таким переменам.

Тем не менее, покупка готового софта – наиболее разумное решение в машиностроении, пищепроме, нефтегазовой, горнодобывающей и других промышленных отраслях, где технические процессы завязаны на оборудовании. IT здесь не является корпоративной компетенцией, но от него зависит скорость и эффективность процессов – соблюдение качества продукции, производительность, time-to-market. Рыночные IT-решения для таких предприятий являются неким ориентиром на лучшие практики в индустрии: они разработаны с учётом ключевых запросов и опыта конкурентной среды.

Преимущества покупки готового софта

  • Значительная экономия времени на разработку.

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

  • Покупая рыночный софт, компания покупает и методологию – как встроить его в бизнес-процессы, тем самым оптимизировать их. Рыночные продукты помогают компаниям становиться лучше – подсвечивают зоны возможного роста, потому что отражают потребности и запросы рынка. Существуют разные классы IT-cистем: ERP – управление ресурсами предприятия, WMS – управление складом, SCADA – диспетчерское управление и сбор данных об оборудовании, BPM – управление бизнес-процессами и так далее. Вместе они образуют определённую иерархию, которая позволяет гибко управлять промышленным предприятием. В «коробочных» решениях всё это, как правило, учитывается. Попытки реализовать всё самостоятельно в одной системе могут привести к тому, что получится так называемый «мост из чугуна».

  • Даже если решение придётся «улучшать» под требования компании, это будет разумной инвестицией в партнёрство с вендором, который совершенствует свои продукты и находится на пике развития технологий.

  • Экспертный подход к разработке: в готовых IT-решениях соблюдаются все требования к доменной экспертизе и тестированию, обновления происходят своевременно – системы работают стабильно, что важно для всех отраслей промышленности.

  • Опыт внедрения IT-решения, который обязательно пригодится в будущем, когда появятся более масштабные вызовы. Это серьёзный шаг и опыт как для руководства, так и для персонала предприятия, который будет иметь большое значение в планировании и реализации дальнейшей стратегии цифровой трансформации.

  • Техническая и сервисная поддержка, а также сотрудничество с компетентным IT-партнёром, который поможет грамотно выстроить и дальнейший путь цифровой трансформации предприятия.

  • Готовые решения способны значительно ускорить time-to-market. Так, например, металлургическая и горнодобывающая компания ЕВРАЗ рассказывала на Хабре о том, как внедрила предиктивную аналитику на своём производстве за девять месяцев. По нашим подсчётам, готовое решение F5 PMM от Factory5 позволил бы решить эту задачу не более, чем за три месяца.

Трудности и риски, связанные с покупкой готового ПО

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

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

  • Необходимость донастройки существующих решений, время на которую может не соответствовать ожиданиям заказчика.

  • Vendor lock – зависимость от поставщика ПО.

Как принять решение?

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

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

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

При выборе между Build и Buy стоит отталкиваться от корпоративных компетенций компании – фокусироваться на том, что вас выделяет из числа конкурентов. Кастомизированная разработка в этой части оправдана. Всё, что нужно сделать быстро, в чём не нужно конкурировать с другими – лучше купить на рынке. Это позволит сконцентрировать внимание на главном и грамотно оптимизировать затраты. Сэкономить время и ресурсы там, где не нужна уникальность и специфичность, доверив эти области зрелым технологиям на основе лучших практик индустрии.

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

Что касается вопроса конфиденциальных данных, существует два варианта решений – Managed Cloud и On-premise. Наш опыт показывает, что заказчики чаще выбирают On-premise – пакет ПО, который клиент разворачивает на своих серверах, поддерживает и администрирует своими силами. Этот вариант позволит обеспечить дополнительную безопасность данных предприятия.

Теги:
Хабы:
Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку
Всего голосов 3: ↑2 и ↓1+1
Комментарии2

Публикации

Информация

Сайт
factory5.ai
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия

Истории