In-house разработка или покупка готового решения?
Представить сегодня компанию без CRM, ERP и иных инструментов управления бизнесом - невозможно, а истории их внедрения зачастую более кровавые, чем первые сезоны "Игры престолов". Но сегодня мысли вслух о том, какая стратегия внедрения более эффективна - собственная разработка или покупка коммерческого продукта?
В моей практике ответ на этот вопрос никогда не был очевидным. В разные периоды и в разном контексте выбирали разный путь. Но в последние годы окончательно пришёл к понимаю, что позиция, на которой стоял долгое время, не была правильной.
За много лет работы в авиационной отрасли через мои руки прошло множество проектов. Вот лишь некоторые из них:
➡️ ERP для управления проектами - 100% собственная разработка, пережила множество версий и улучшений. Бюджеты, сроки, управление задачами, планирование и трудозатраты, KPI - полный комплект! Назвали, кстати, Skynet, чем всегда веселили наших французских коллег 😉
➡️ PDM система управления данными по незавершённому производству - полностью in-house инструмент в тесной связке с 1С. На выходе получилась конфетка, хотя и стоила мне 3-х лет разработки.
➡️ PLM Teamcenter для управления жизненным циклом конструкторской документации - коммерческий продукт, который серьёзно допиливали под наши процессы. Было непросто, но на выходе сделали красиво!
➡️ HR-платформа для управления персоналом - собственная разработка, куда запихнули почти все процессы : рекрутинг, адаптация, обучение, развитие карьерного трека. Жаль, не все успели сделать, как задумывалось - 2022 г. внес свои коррективы.
➡️ SmartWiki для управления знаниями компании - взяли open source движок и допилили его под себя. Получили годную корпоративную вики не хуже Confluence.
➡️ А ещё были ITSM и SAM продукты, CRM-системы управления заявками, не говоря уже о десятках более локальных инструментов.
Сейчас, глядя на все это отстраненно, понимаю, что в большинстве случаев путь самостоятельной разработки "под себя" был неэффективным. Не неправильным, а именно не эффективным, особенно на длинном горизонте.
Разберём по пунктам:
🔆 Соответствие требованиям заказчика Не существует идеальных инструментов, которые as is на 100% ложатся в требования заказчика. Итог любого бенчмарка - выбор между "подходит на 90% и на 80%". Здесь таится первая ловушка - запуская собственную разработку, ты ожидаешь получить идеальный продукт под свои текущие процессы. Но процессы меняются, ведь и рынок, и бизнес постоянно в движении. В результате получаем бесконечный цикл адаптации к изменениям. При этом как правило самые критичные требования закрываются рыночными решениями или после небольшой доработки.
🔆 Команда поддержки и культура разработки Собственная разработка всегда критично зависит от команды разработчиков и наличия культуры создания ИТ-продуктов. Последняя, объективно, в инжиниринговых компаниях не всегда достаточно развита, если не брать в расчёт огромных монстров индустрии, где есть целые департаменты ИТ разработок и поддержки ПО. Плюс фактор команды, которая сегодня есть, а через 5 лет многих уже может и не быть, а поддерживать созданные продукты как-то надо.
🔆 Цена вопроса За долгие годы не видел ни одного подобного проекта, где плановая и фактическая стоимость разработки и внедрения были бы сопоставимы. А с учётом последующего улучшения продукта, это становится бездонной ямой, пожирающей всегда ограниченные ресурсы.
В сухом остатке пришел к глубокому убеждению, что в моей области оптимальным решением является покупка готового продукта и его доработка силами разработчика и небольшой команды на стороне бизнеса. Здесь больше управляемости и надежности в эксплуатации.
Не претендую на абсолютную истину. Мир бизнеса в разных областях прекрасен во всем своем разнообразии ситуаций и контекстов, и каждый выбирает наилучший для него путь!
PS. Картинку попросил сгенерировать ChatGPT на основании текста поста, с иронией и в стиле рисованного комикса. Вышло не бесспорно, но мило! 😃
· 21.02
Не увидел RFI и RFP что-то, что навевает грустные опасения о статье
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 21.02
Весь набор RFx - это понятная и прозаичная история работы с рынком. Пост же скорее про идеологию и опыт. Поясните в чем опасения возникли? 😀
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 21.02
В том, что вы безапелляционно заявили, что «ERP - 100% собственная разработка»
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 21.02
Так оно так и было 😃 По итогам бенчмарка не нашли приемлемое решение и тогда пошли в разработку с нуля собственной ERP. 100% своими силами 😉 Получили отличный нишевый продукт, который прекрасно решал все наши задачи, но попутно получили массу проблем, связанных с In-house разработкой. Полезный урок 😀
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 21.02
Зависит, опять таки, от ритуалов и процедур RFx. При особом желании можно захреначить туда no-code требования, а потом пилить свой in-house по другим. И, как показывает практика, если на рынке нет 90% решения из-за «особенностей процессов» (будь то даже b2g), то проблема не в рынке, а в процессах. И, решаясь на in-house, вы не оптимизируете процессы и не проводите аудит и role-flow, а просто оцифровываеие ваш процессуальный фарш
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 21.02
Отлично понимаю, о чем вы говорите! И именно к этим выводам со временем и пришёл (о чем собственно весь пост). А проблема реальная была не столько в фарше процессов (они стандартные для задач проектирования в авиации, вся методология описана), сколько в очень специфичной системе проектного финансирования. Понятно, что любую систему можно допилить под себя, но тогда мы решили как решили.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 21.02
Ох уж эти проблемы с прозрачностью финансирования :) я в свое время ушел из проекта просто потому, что решили «внедрять в Mars»
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 21.02
Нее, там прозрачность как раз 200% была 😃 Другая беда: требовалось подстроиться под модель финансирования с точки зрения всей архитектуры и логики на стороне ключевого заказчика. К себе не пускали, потому и пришлось городить огород 😂
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён