Рациональное импортозамещение: как от копирования в IT перейти к переосмыслению

Стресс или закаливание

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

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

Со стороны заказчика — это очевидная остановка в развитии. Можно долго выжимать возможности настроечных параметров, но законсервированные системы не получают обновлений. Не владея исходным кодом, невозможно проводить серьезные доработки. Есть вариант с обвязкой основной системы вспомогательными скриптами, доработками и заменителями, но такая «капуста» с каждым днем становится менее эффективной и более дорогой в поддержке и эксплуатации. А главное — не поддается модернизации. В моей практике были примеры, когда даже на очень удобном инструменте и вокруг него за годы работы накручивали такие слои бизнес-логики и заплаток, что процесс его замены становился невозможен не из-за отсутствия аналогов, а потому что никто уже не помнил, как он работает.

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

С другой стороны, если пересмотреть подход к замене систем, то вместо «стресса ради стресса» можно подойти к замещению как к инструменту усиления и развития.

Копирование или реинжиниринг

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

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

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

В новых реалиях бизнес провел два года. Это позволило ему переосмыслить свои цели и подход: вместо гонки за импортозамещением компании стали задумываться о том, что им на самом деле нужно. Российский технологический ландшафт заметно отличается от зарубежного и продолжает меняться в сторону усиления этих отличий: вендоры уходят, их замещают российские разработки, старые интеграции перестают нести ценность для бизнеса. Нужна ли российской компании система, которая помогает проверять контрагента на соответствие санкционным спискам? Что будет более ценным для российского бизнеса — штатная интеграция решения с Microsoft Dynamics AX (система для автоматизации управления предприятием. — Forbes) или 1C? Очевидно, реальные потребности компаний в России другие. Но поначалу такие функции копировали не задумываясь, боясь нарушить целостность системы.

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

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

Грибной дождь на рынке разработки

Уровень осознания потребностей вырос, но остался открытым другой вопрос: кто поможет российским компаниям со сложной разработкой?

Уже через год после начала исхода зарубежных вендоров количество аккредитованных российских IT-компаний выросло в пять раз: с 4000 до 19 000 организаций. Сегодня Минцифры вносит коррективы в программу поддержки отечественного IT, поэтому в 2023 году аккредитацию сохранили только 17 000 компаний — но все равно рост очевиден.

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

Какой из этих путей выбрать — зависит от целей, задач и подхода к экономике процесса (смотреть на IT как на точку создания прибыли или как на важный обеспечивающий процесс).

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

Второй вариант — инхаус. Те, кто пробовали силами двух-трех разработчиков по-быстрому создать аналог Jira (таск-менеджер, сервис для управления проектами. — Forbes), понимают, что подобные затеи авантюрны. В продуктах такого масштаба слишком много неочевидных для внешнего наблюдателя связей. К тому же инхаус-команду дорого содержать, а со временем сам продукт становится настолько сложным, что его невозможно поддерживать силами небольшого подразделения. Также инхаус-разработка всегда отстает. Она работает реактивно — после поступления задачи от бизнеса, а не исходя из конъюктуры рынка и внешних факторов. И без возможности принести общие тренды индустрии.

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

Не замещать чужое, а создавать новое

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

Когда начался исход зарубежных вендоров с российского рынка, мы видели эффект «грибного дождя»: IT-компании пытались заполнить освободившиеся ниши по принципу «кто первый». При этом компании-заказчики не вполне осознавали, что чистый аналог SAP, Slack, Jira или любого другого решения им на самом деле не нужен. В итоге результат никого не устроил.

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

Поэтому, если резюмировать решение вопроса ушедших вендоров, важно определиться:

• Что из требований к продуктам создает ценность, а что «просто так принято»?
• Видите ли вы IT-службу как центр прибыли или это обеспечение основного бизнеса? Стоит ли вкладываться в инфраструктуру долгосрочного самообеспечения?
• Как выбрать партнера, который создаст ценность и принесет развитие, а не уйдет с рынка после спада волны замещения?

Эти вопросы позволят выбрать для себя оптимальную стратегию и превратить замену систем из проблемы в точку развития.

Ссылка на материал