Я не начинаю IT-аудит с перечня программ: сначала смотрю, где решение застревает

Я не начинаю IT-аудит с перечня программ. Такой список полезен, но сам по себе он редко объясняет, почему руководитель ждёт цифры три дня, менеджер вручную переносит заказ между системами, а команда боится выключить старый сервис.

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

Инвентаризация отвечает не на тот вопрос

Представьте склад, на котором аккуратно переписали все стеллажи, но не заметили, что кладовщик каждое утро ходит за нужной деталью на другой конец здания. Инвентаризация верна, а путь остался дорогим.

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

С чего я начинаю разговор

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

Дальше полезны пять вопросов:

1. Какое решение должен принять человек?
2. Какие данные он использует и откуда им доверять?
3. Кто может остановить или исправить шаг?
4. Как выглядит исключение и где оно становится видимым?
5. По какому признаку понятно, что результат достигнут?

Эти вопросы просты, но они переводят обсуждение из «нам нужна новая система» в «у нас теряется конкретное решение». Иногда после такого разбора оказывается, что новую систему покупать рано: сначала нужно договориться о владельце данных или убрать один ручной перенос.

Карта решения важнее красивой архитектурной схемы

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

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

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

Где обычно прячется риск

Первое место — ручное «временно». Файл выгружают раз в неделю, цену сверяют по телефону, доступ выдают из личной учётной записи. Временная мера не всегда плоха. Проблема начинается, когда она стала частью критичного пути, но её никто не назвал и не контролирует.

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

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

Не путать симптом с причиной

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

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

Как разговаривать с командой без защиты привычного порядка

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

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

Выбирать изменение по цене бездействия

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

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

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

Что должно остаться после аудита

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

Например, не «улучшить интеграцию», а «назначить источник статуса оплаты, убрать ручное копирование в учётную систему и проверить десять реальных заказов после изменения». Такой язык соединяет бизнес-задачу и работу команды разработки.

Как не превратить аудит в бесконечное исследование

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

Это спокойнее, чем пытаться «оцифровать всё», и честнее по отношению к команде. Архитектура растёт из принятых решений и реальных ограничений, а не из красивого списка продуктов.

Короткая проверка перед стартом

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

После этого перечень систем тоже понадобится. Но он перестанет быть началом и станет полезной частью ответа на главный вопрос: что мешает компании принимать решение вовремя и спокойно.