Что не так с собственной разработкой, и почему она (почти) всегда проигрывает готовым решениям. Пытаемся разобраться

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

Но коллеги, объясните, почему так происходит?! Почему компания, которая занимается производством продуктов питания или промышленного оборудования, начинает создавать ERP, CRM-систему и т.д.?

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

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

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

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

Причина #2. Безопасность. Желание иметь только свой софт и ни от кого не зависеть. На самом деле независимость — это миф. К нам приходят компании, которые самостоятельно разработали систему и попали к ней в заложники. Почему так происходит? Когда ты разрабатываешь продукт в отрыве от рынка, то список задач, который нужно реализовать, формируется не под действием реальных необходимых факторов, а под действием внутренних сил. И побеждает тот, кто из корпоративных заказчиков, грубо говоря, применил бОльшую силу. Иногда делают все очень быстро и причем такие вещи, которые в итоге не используются. Много ресурсов расходуется впустую, на реальном рынке так не происходит. Часто бывает так, что люди, вместо того, чтобы задуматься над эффективностью, закрывают какие-то дыры кодом. В итоге появляется куча разного функционала и костылей. И такое решение только мешает. Система в безопасности, но, в то же время, она не позволяет развиваться.

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

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

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

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

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

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

Или еще пример — транспортная компания Монополия. Их продукт — это IT-сервис, который объединяет грузоперевозчиков и отправителей. У них выстроена разработка внутри: это их продукт и они его продают в открытом конкурентном рынке.

Что делать с политическими причинами? С первой (где “сын маминой подруги”), когда кому-то просто необходимо внедрить собственную разработку, честно скажу — не знаю. Наверное, такое явление просто имеет место быть. Тем компаниям, в которых распространены 2 последних сценария, можно рекомендовать трансформироваться и становиться в какой-то мере IT-компанией. В данном случае нужно понимать, что результатом трансформации будет цифровой продукт, который нужно будет продавать на рынок. Но не CRM или ERP-система для внутреннего использования.

Если вы производите промышленное оборудование, то зачем вам разрабатывать свои решения? Да, в вашем оборудовании может быть софт, который управляет этим оборудованием. Но, скажем, CRM — это не часть продукта.

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

Я задумался — зачем, это же очень дорого. Это отдельное приложение, которое не является для компании основным продуктом, а на него работает целая команда. Причем, к нам тогда приходили даже не разработчики, а разного рода менеджеры. Продукт-овнеры и вот эти все "красивые названия". То есть в реальности к ним добавится еще как минимум несколько человек, которые это все будут руками делать.

Для сравнения: команда разработки одного из наших вендоров, который занимается чат-ботами, состоит из 12 человек. Плюс 5-7 менеджеров. И у меня в голове не сходится. Вот двадцать человек выпускают систему на рынок, ее стоимость распределяется между всеми клиентами, которые платят за подписку. И какая-то одна компания тратит ресурсы более десятка сотрудников на свой побочный продукт — это же очевидно дороже. Они ходят, смотрят кейсы на рынке, когда вендор сам такие кейсы собирает от самых разных клиентов и потом реализует их в своем решении. Какой смысл заниматься собственной разработкой?

Чтобы проверить адекватность этих рассуждений, мы с Евгением Иванченко провели эксперимент. Взяли анонимное ТЗ на CRМ-систему клиента и посчитали стоимость. Оказалось, что разработка системы с нуля в 3 раза (!!!) дороже. Стоимость человеко-часа у нас одинаковая, но разработка с нуля проигрывает за счет больших объемов и сроков разработки.

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

Все расчеты показывают, что собственная разработка дороже.

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

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

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

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

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

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