Вроде бы внедряем цифровые решения, а получаем техдолг, сбои и выгоревшую команду. Большинство российских компаний сталкивается с одинаковыми стратегическими ошибками при цифровизации. В этой статье я разберу на живых примерах три главные ловушки для первых лиц: почему импортозамещение без стратегии угрожает операционной устойчивости, как недооценка команды превращает дорожную карту в провалы и чем опасна «экономия» на архитектуре. Знаете, как иногда бывает в ремонте: решили срочно поменять сантехнику, а в итоге затопили и свою квартиру, и соседей. Примерно так же работает импортозамещение IT-систем без продуманной стратегии управления рисками.
Возьмем реальный пример из практики одного банка (не буду указывать конкретнее). Когда банк начал масштабный переход с зарубежных решений на собственную платформу, выяснилось, что просто взять и заменить Oracle или SAP — нельзя. Эти системы десятилетиями были «нервной системой» банка: они управляли и расчетами, и рисками, и клиентскими операциями. Прямой перенос на новую платформу грозил тем, что в какой-то момент банк мог просто не посчитать деньги клиентов или провести платежи с ошибками. О каких же в этом случае рисках идет речь?
Например, риск «дня ноль» — это когда новая система формально работает, но не готова к реальной нагрузке. Известен случай, когда новая CRM ретейлера не выдержала наплыва клиентов в «черную пятницу», и онлайн-продажи просели на 40% за день.
Следующий риск — это риск технологических разрывов: старый софт может делать вещи, о которых все забыли, но без которых бизнес-процессы рушатся. Например, в той же банковской среде западные системы расчета кредитных рисков часто содержат уникальные алгоритмы, аналоги которых в российских решениях до сих пор не созданы.
Что делать? Самый практичный подход — управлять импортозамещением как портфелем рисков, а не только как IT-проектом. Сначала делаем технический аудит «привычек», и это не то, что система делает по документации, а как она реально используется. Часто оказывается, что 20% функционала критичны для бизнеса, а остальное — рудименты или вспомогательные решения.
Затем используем тактику параллельного пилотирования: как в авиации, где есть пилот и второй пилот. Новая система работает рядом со старой, пропуская через себя 10–15% операций. Так мы находим слабые места без остановки бизнеса.
И главное — создаем «дорожную карту рисков». В ней честно пишем: в первую неделю возможны сбои отчетности, во вторую — замедление транзакций, к третьей выходим на стабильность. Это позволяет бизнесу подготовиться, а IT — не работать в режиме пожара.
Ошибка в оценке команды, когда даже гениальная дорожная карта превращается в список проваленных проектов
Представьте, что вы дали школьной футбольной команде задачу обыграть питерский «Зенит». Звучит маловероятно, хотя теоретически, конечно, возможно. Именно это происходит, когда руководство утверждает амбициозную дорожную карту цифровизации, не оценив реальный уровень своей IT-команды.
Когда крупный федеральный ретейлер начинал масштабную цифровизацию, выяснилось, что существующая команда не готова одновременно поддерживать текущие системы и внедрять новую платформу управления товарными потоками. Это привело к тому, что пилотный проект в десяти гипермаркетах столкнулся с постоянными сбоями: новые процессы не работали, а старые начали «сыпаться» из-за нехватки внимания. Люди стали волноваться и уходить, и на рынок вышли интересные специалисты с опытом, которых подхватили конкуренты.
Основные риски — это:
- Риск «двойной нагрузки» — одна и та же команда не может одновременно «рулить» текущими системами и строить новые.
- Риск тихого выгорания — когда пробелы в знаниях сотрудники маскируют сверхурочной работой, а руководство узнает о проблеме только после массовых увольнений.
- Риск цепочечного сбоя — одна недооцененная команда (например, отдел тестирования) может затормозить всю цифровую трансформацию в процессе IT-разработки.
Что делать? Применяем оценку успешности реализации спринтов — даем команде пробный проект на 2–3 недели и смотрим не только на результат, но и на процессы: как справляются с ошибками, как оценивают сроки, как взаимодействуют между собой. То есть делаем своеобразный аудит.
Внедряем регулярную «диагностику навыков» — не формальный HR-опрос, а практические кейсы по технологиям из дорожной карты. Как в другом банке, где проводят внутренние хакатоны, где оценивают не только знания, но и скорость освоения новых технологий сотрудниками.
Создаем «карту зависимостей компетенций» — если для дорожной карты нужны пять ключевых навыков, а в команде уверенно владеют только тремя, это не приговор, а план действий по найму или обучению. Хотя, конечно, можно и отказаться от проекта 😊
Архитектурная экономия на тот случай, когда сиюминутная выгода оборачивается многолетним техдолгом
Как если бы вы построили дом на слабом фундаменте, чтобы сэкономить, и сначала все рады скорости и низкой стоимости, но потом каждую перепланировку приходится согласовывать с тем, что стены могут поползти.
В 2010-х годах один банк активно развивался через поглощения, и каждый новый актив приходилось «вшивать» в существующую архитектуру. Быстро и дешево это делали через временные решения и прямые интеграции. Когда таких «пришитых» систем стало много, выяснилось, что запуск нового кросс-продукта требует изменений в 15–20 разных системах, а это существенно замедляет цикл time-to-market.
Чем опасен такой подход: техдолг блокирует развитие — новые фичи упираются в старые ограничения. Стоимость изменений растет лавинообразно: правка в одном месте ломает три другие. Команда тратит 60–70% времени не на развитие, а на работу с легаси конструкциями.
Управление риском:
- Внедряем принцип «эволюционной архитектуры» — любые временные решения имеют четкий срок жизни и план по замене. У этого плана есть конкретная фамилия и дата выполнения.
- Регулярно проводим «технический аудит долгов» — оцениваем, сколько стоит поддерживать текущую архитектуру.
- Вводим правило «20% времени на рефакторинг», когда команды обязаны часть спринта тратить на улучшение кода.
В общем, архитектура — это не только про технологии, а про управление затратами и денежным потоком. Именно поэтому инвестиции в архитектуру поддаются тем же экономическим правилам, что инвестиции в проект, где должны учитываться положительные и отрицательные денежные потоки, дисконтирование, а самое главное — риски.
