Культура потребления корпоративных программных продуктов
Культура никогда не меняется внезапно, но она неизбежно трансформируется под влиянием внешних обстоятельств. То, что происходит сегодня в потреблении корпоративных программных продуктов, разительно отличается от того, что было еще пять лет назад. Давайте сравним два типа потребления и поймем, как мы пришли к такой модели и как это повлияет на развитие отрасли.
Лучшие практики, реализованные в коде
Как выглядело потребление с начала российского капитализма вплоть до 2022 года? К корпоративному клиенту приезжали продавцы и инженеры от крупного иностранного вендора и рассказывали, чем живет весь мир, какие новые функции появились в их продуктах, какие ценности они сулят. Корпоративный клиент удивлялся и думал, может ли он при его нынешней зрелости применить этот чудесный продукт у себя в цифровой системе. Были в ходу зарубежные выставки, где российские корпоративные клиенты приобщались к лучшим мировым практикам. Также были популярны референс-визиты в какую-нибудь европейскую, канадскую или американскую компанию — для компании-производителя было дешевле оплатить такую поездку, чем втягиваться в пилотный проект в российской компании. Нефтяников возили в Норвегию, таможенников — в Канаду, и т. п.; где для какой отрасли конкретный производитель договорился, там делали «центр отраслевой экспертизы» и реально водили экскурсии.
Это немного напоминало приобщение туземцев к цивилизации, но уже не было обидно, ведь от автоматизации «сделано в России» мы отказались добровольно, хотя до начала нулевых работали еще советские системы автоматизации — начисляли зарплату, готовили финансовую и бухгалтерскую отчетность, управляли производством. Двести лет капитализма по сравнению с нашим едва ли десятком — не грех и поучиться, чтобы быстрее догнать.
То, что немцу хорошо, русскому нехорошо
Автор сам неоднократно участвовал в таких процессах, помогая иностранным производителям и российским корпоративным клиентам найти общий язык, а потом и договориться о сотрудничестве. Тогда часто использовали убийственный аргумент: «мы продаем вам не код, мы продаем вам десятилетия опыта, выраженные в коде». И да, преклоняясь перед этим опытом, компании часто предпочитали перестроить свои процессы под программный продукт, а не просить производителя переделывать продукт под их текущие процессы. Еще один популярный аргумент: «если автоматизировать ваш бардак, получится автоматизированный бардак». Подразумевалось, что если делать все, как описано в продукте, то «бардак» сам собой исчезнет. Иногда это и правда работало, например, в логистике — отлаженные десятилетиями процессы, под которые писались западные продукты, действительно были оптимальнее органически выросших наших.
Посложнее было на производстве: советская культура выращивала руководителей от производства, эдаких «прошедших путь от ученика мастера до директора завода» — такие люди управляли через производство, им количество выплавленного металла или километры пробуренных скважин говорили о состоянии компании больше, чем финансовые документы. Западная культура управления через финансы, когда директор может легко менять отрасли, сегодня руководить производством напитков, а завтра — авиакомпанией, плохо приживалась в нашем климате. Поэтому иностранные системы управления производством требовали большей кастомизации. Не говоря уже о финансовых системах — специфика российских требований регуляторов отпугивала западных производителей финансовых систем, за исключением разве что аналитических, в которых не надо было отвечать за результат.
Автор сам был жертвой такой автоматизации: в начале нулевых в Россию привезли чудного зверя CRM (Customer Relationship Management), которую большинство российских коммерческих директоров тогда использовало как продвинутую записную книжку с контактами клиентов и с возможностью планирования встреч. Всю мощь подобных решений мы осознали только лет десять спустя, и сегодня без такой системы не работает ни один коммерческий директор. Правда, справедливости ради нужно сказать, что и сами системы стали функциональнее, интегрировались с соцсетями, интернет-рекламой, обросли аналитикой и гораздо успешнее показывают свою эффективность. Как-то один владелец компании на семинаре по CRM сказал буквально: «Вы просите за это 100 тысяч долларов, на эти деньги я могу открыть филиал в миллионнике, и точно знаю, как и когда мне эти деньги вернутся. Как и когда мне вернутся деньги с вашего CRM, я не понимаю». Так что не всегда лучшие практики, отлитые в коде, находили в стране благодарных поклонников, все-таки стоили они немало.
Теперь лучшие практики реализуют не вендоры
Но уже больше четырех лет к нам не приезжают делиться опытом. Теперь не производители рассказывают корпоративным пользователям, что новенького появилось на рынке, а корпоративные пользователи рассказывают российским вендорам, что нужно сделать, чтобы продукт им понравился. Первые годы такой ситуации казалось, что заказчики отрываются на производителях. Если раньше в ответ на просьбу что-то добавить или поменять в продукте заказчик слышал от иностранного производителя вежливое «ваше мнение очень важно для нас, и мы обязательно передадим его в разработку», означающее буквально «нет, никогда», то теперь российскому производителю можно буквально диктовать расположение и цвет любой кнопки, выдумывать любые функции. Дошло до того, что, когда хотят похвалить российского производителя, про него говорят «они быстро доделывают под наши требования». Правда, технический долг (обещание что-то доделать) не всегда отдают вовремя, несмотря на подписанные гарантийные письма, а то и не отдают никогда — рынок уже видел дефолты по техдолгу.
Так что, наигравшись с «как скажем, так и сделают», заказчики столкнулись с тем, что российские продукты, которые делаются «с колес», не совсем удовлетворяют современным задачам цифровизации, особенно в тех компаниях, которые имеют опыт работы с передовыми иностранными продуктами.
Тут стратегии компаний разделились: одни решили расти вместо с российскими производителями, другие начали писать продукты сами. Большинство компаний, конечно, используют гибридные модели — что-то покупают, а что-то разрабатывают сами. Самостоятельную разработку подстегнули государственные меры поддержки ИТ-отрасли — многие крупные компании вывело ИТ-отделы в самостоятельные юрлица, чтобы сохранить ИТ-команды, получили налоговые льготы, ИТ-ипотеку и бронь от мобилизации. Потом условия получения статуса ИТ-компании стали ужесточаться — и вот уже нужно капитализировать разработку, регистрировать ее как продукт и иметь доминирующую выручку от его реализации. То есть «не пишешь продукт — не ИТ-компания», хочешь ей быть — программируй. Поэтому сегодня в крупных компаниях с большими цифровыми системами программистов больше, чем в тех компаниях, которые работают на рынок.
Недостатки «домашней» разработки
Программы, которые пишутся для себя, очень сложно продать еще кому-то — ведь никто не будет писать универсальный продукт, когда надо реализовать в коде конкретные процессы конкретной компании. Исключения, конечно, есть, но даже очень хороший продукт в «кровавом энтерпрайзе» сам себя не продает, а расходы на маркетинг и продажи в этом сегменте легко могут быть выше, чем расходы на разработку. На такое готовы очень редкие компании из тех, чей основной бизнес — все же не программирование.
Нельзя сказать, что какой-то путь правильный, а какой-то нет — каждый владелец цифровой системы принимает решения сам, исходя из внешних и внутренних ограничений. Автор видел, как заказчики растят своих подрядчиков: заставляют подрядчиков искать других клиентов, даже оплачивают им тренеров на маркетинг и продажи. Такое нужно, чтобы маленький разработчик не стал заложником мажоритарного клиента, чем больше клиентов, тем эффективнее на них «размазывается» стоимость разработки, а пользовательский опыт каждого клиента достается всем остальным. Очень мудрое решение, направленное на то, чтобы растить рынок, но оно не дает быстрых результатов, это игра в долгую и требует стратегического мышления, которое в условиях сегодняшней неопределенности есть не у всех.
Конечно, с точки зрения всей ИТ-индустрии, идеально было бы, чтобы уникальные разработки не оставались внутри компаний-разработчиков, а доставались и остальным, но сиюминутные задачи цифровизации противоречат этой большой цели. Уникальные внутренние ИТ-разработки могут давать даже не-ИТ-компании какие-то рыночные преимущества за счет оптимизации процессов и выходов на новые способы зарабатывания денег, ими надо сначала захотеть, а потом и научиться делиться. Для гарантированного внутреннего спроса и ресурсов на найм разработчиков и построения инфраструктуры для разработки у крупных не-ИТ-компаний сегодня есть еще один козырь — данные, которые внутри можно использовать как хочешь. Внешние разработчики должны очень постараться, чтобы получить банковские данные для обучения своих нейросетей — банку их надо обезличить, на это нужны ресурсы. Банковские же внутренние разработчики могут работать с сырыми данными, и это экономит много ресурсов.
Доминирование внутреннего заказчика
Однако продукт, созданный для себя, и продукт, созданный для продажи, — это два разных продукта. Упаковка внутреннего продукта для продажи на внешний рынок — непростая задача: у иных потенциальных пользователей другие процессы, другая инфраструктура, другой пользовательский опыт. Обычно в не-ИТ-компаниях таким занимаются в последнюю очередь или не занимаются вообще, поскольку приоритет имеет внутренний заказчик и между кастомизацией продукта для внешнего заказчика и созданием новых функций для внутреннего при конфликте ресурсов будет выбран последний.
Существующий российский рынок разработчиков программного обеспечения уникален — это рынок маленьких и средних компаний, обслуживающих огромные компании. Если SAP, Microsoft, Oracle — это компании, соизмеримые по размеру с их клиентами, то «1С» и «Лаборатория Касперского», крупнейшие в России производители программного обеспечения, не дотягивают по обороту и количеству сотрудников даже до средних компаний — своих клиентов. Поэтому искушение нанять несколько сот программистов с ФОТ в миллиард рублей иногда выглядит эффективнее, чем купить ПО на те же деньги, но в долгосрочной стратегии развитие и поддержка внутреннего продукта может выглядеть уже не так эффективно.
Концентрация экспертизы по разработке в заказчиках – к чему это может привезти
Возвращаясь к названию статьи о культуре потребления программных продуктов: если раньше производители вели заказчиков в светлое ИТ-будущее, то сегодня заказчики ведут производителей, а если те не идут, сами становятся производителями. Это не приведет к созданию российских «Майкрософтов» и «Ораклов». А без этого не будет инноваций и возврата к культуре, в которой производители экспериментируют и удачные эксперименты показывают будущим клиентам. Если сохранятся сегодняшние тенденции, то экспертиза будет оставаться внутри потребителей (они же и разработчики) и не станет тиражироваться — скажем честно, продвижение программных продуктов не самая сильная сторона внутренней разработки.
Кажется, уже последние «ждуны» смирились с тем, что как раньше уже никогда не будет, ограничения сохранятся долго, а значит, надо строить свой внутренний рынок с возможностью развития на дружественные зарубежные рынки. Давление бюджетами — «сделайте как скажем, а то не купим» — распространенная сейчас схема сотрудничества, но она все же должна уступить место более традиционной форме. Само собой, органически, рыночными методами, рынок не сложится. Здоровый рынок корпоративного софта — это когда клиенты говорят о своих болях, а производители придумывают, как их закрыть. Если этого не делать, то мы вполне можем прийти к «чоболизации» (от корейского термина «чоболь» — многопрофильный финансово-промышленный холдинг) — большинство программных продуктов и, если шире, инноваций будет рождаться в крупных не-ИТ-компаниях (банках, телекомах, энергетических, нефтяных и других компаниях). Это начнет распылять ресурсы, поскольку у каждой компании появятся свои продукты, а результаты инноваций не достанутся другим компаниям, особенно конкурентам.
Играет ли такая ситуация на руку ИТ-индустрии — вопрос риторический.
Опубликовано 10.07.2026
