Компанию накрыл ИТ-хаос: как с ним справиться

Обилие ИТ‑систем часто принимают за признак зрелости, но это может маскировать технический и организационный долги. Какие 5 повторяющихся симптомов помогут отличить нормальный рост от ИТ‑хаоса, знает Артур Зайнуллин, IBS

По данным НИУ ВШЭ, 75,7% российских организаций, использующих цифровые технологии, работают с платформами автоматизации бизнес-процессов. Теперь связанный набор систем — обычная среда для бизнеса, а качество взаимодействия между ними напрямую влияет на операции.

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

Провести границу между нормальным ростом и системной проблемой в этих условиях помогают пять повторяющихся симптомов хаоса в области ИТ:

1. Ручная работа стала частью штатного процесса. Например, в таком случае без ручной выгрузки, сверки или переноса данных нельзя закрыть заказ, оплатить счет, отгрузить товар или подготовить отчет.
2. Сбои повторяются на стыке систем. Даже если отдельные приложения доступны, заказ может не проходить из клиентской системы в учетную, статус — не возвращаться на сайт, документ — не попадать в архив, а платеж — не связываться с договором.
3. Изменения стали долгими и непредсказуемыми. Если оценка простой доработки занимает недели, это часто означает, что зависимости неизвестны и команда закладывает дополнительное время для компенсации рисков.
4. Бизнес зависит от знаний отдельных людей. Незаменимый эксперт кажется сильным активом, пока он доступен, но в критически важных процессах это еще и единая точка отказа.
5. У подразделений разные версии правды. В разных отчетах могут быть разные правила и моменты отсечек, и это нормально. Однако расхождения данных становятся опасными, если правила не описаны и руководители не знают, какие показатели использовать.

Чтобы на основе этих признаков оценить остроту проблем в организации, можно использовать управленческую шкалу из трех уровней.

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

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

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

Эта управленческая шкала не норматив, она лишь примерно отражает оптимальные схемы действий и калибруется примерно за три–шесть месяцев с учетом особенностей отдельной компании. При этом важно понимать, что задержки процессов могут быть связаны не только с недостатками ИТ-архитектуры, но и с дефицитом кадров, проверками (согласования, тестирование, требования безопасности и регуляторные процедуры) или спецификой управления задачами.

Скрытая стоимость ИТ-долга

ИТ-долг редко выражается в одной строке бюджета. Его оплачивают подразделения — дополнительным временем на сверки, простоями, повторной разработкой и задержкой запуска продуктов. Такие потери можно приблизительно оценить по формуле: годовая стоимость = ручной труд + повторные сбои + переделки + потерянная маржа из-за задержек + ожидаемый ущерб от рисков.

Допустим, 25 сотрудников тратят на сверки по три часа в неделю. При полной стоимости часа в 1500 руб. — это 5,4 млн руб. в год (за 48 рабочих недель). 14 повторных сбоев по восемь часов с участием десяти человек добавляют 1,68 млн руб. Еще 1000 часов переделок по 3500 руб. стоят 3,5 млн руб. В случае задержки на месяц продукта с плановой маржой 2 млн руб. суммарные годовые потери под влиянием этих факторов могут составить не меньше 12,58 млн руб.

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

Примеры управления ростом и риском на российском рынке

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

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

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

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

Что можно сделать с ИТ-хаосом

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

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

До начала работ фиксируют исходную точку: количество часов ручных операций, повторные сбои, время восстановления сервиса, срок выпуска изменения, объем переделок, неописанные критичные интеграции и процессы без владельцев. Потом утверждают цель и срок — например, за 12 недель сократить повторные сбои на 40%, ручные сверки — на 300 часов в месяц, а восстановление — с четырех часов до одного. Через 8–12 недель команда решает, продолжить, изменить гипотезу или остановиться. Если нет динамики, значит нужно проверить точность оценки проблемы и полномочия владельца, а не увеличивать бюджет.

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

Порядок без новой бюрократии

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

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

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

ИТ на вырост — это не серверы и лицензии с запасом, а способность руководства компании ответить на четыре вопроса:

1. Какой бизнес-процесс пострадает, если мы изменим эту систему?
2. Кто отвечает за результат и данные?
3. Сколько стоит текущая проблема для компании?
4. По каким показателям будет понятно, что решение сработало?

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