Снести нельзя оставить: что покажет аудит информационной системы
Система тормозит, интеграции сбоят, а доработки тянут за собой новые проблемы. Кажется, что проще всё переделать с нуля. Но сначала стоит понять реальный масштаб проблемы и не ошибиться с бюджетом.
Зачем нужен технический аудит действующей системы
Представим условный кабинет для работы с партнёрами. Через него поступают заявки, партнёры отмечают результаты работы, а руководители следят за обработкой. Отчёты стали открываться медленно, и сотрудникам приходится вручную выяснять, что произошло с отдельными заявками. При этом компания хочет получать данные о заказах из 1С и передавать сведения в CRM. DIGITAL SECTOR разбирает такие ситуации через технический аудит: он помогает понять, где именно находится проблема и какой объём изменений действительно нужен.
Оставить кабинет как есть — значит сохранить ручные проверки и отложить новые функции. Заказать внедрение исправлений тоже непросто: разработчик пока не знает, какие модули затронет интеграция. Возникает предложение разработать новый кабинет с нуля. Кажется, что это хороший вариант, но его бюджет тоже не получается посчитать просто по функциональному ТЗ.
А руководителю нужно выбрать вариант и согласовать расходы. При этом неизвестно, где возникают проблемы, как меняется статус заявки и какие части системы зависят от этих правил. А значит, любая смета будет основана на предположениях.
Сначала нужно установить причины и границы изменений. Для этого и проводят технический аудит.
Проверка системы перед решением
Перед проверкой нужно сформулировать ключевой вопрос. Для нашего примера с личным кабинетом он звучит так: можно ли интегрировать CRM и добавить новые отчёты в действующую систему, какие части придётся изменить и нужно ли разрабатывать новый кабинет? От ответа на этот вопрос зависит, какие данные нужно собрать и какие части системы проверить в первую очередь.
Как проходит проверка
Специалисты, которые проводят аудит, собирают документацию, историю доработок и сведения об ошибках. Разработчики объясняют устройство кабинета, а сотрудники показывают, как обрабатывают заявки и где им приходится сверять данные вручную. Затем специалисты проверяют эти объяснения по коду и работе системы: воспроизводят задержки, прослеживают движение заявки, смотрят обмен с другими программами.
Основные направления проверки
Архитектура и зависимости показывают, какие функции затронет доработка. Состояние кода и технический долг помогают понять, почему изменение одного правила требует работы в нескольких модулях. Документация и тесты показывают, можно ли выпустить обновление без ошибок в прежних сценариях. Отдельно оценивают нагрузку, права доступа и другие ограничения, способные повлиять на выбранный план.
Важны и связи с внешними сервисами. Например, при разработке виджета уведомлений DIGITAL SECTOR учитывал источники событий, авторизацию и ограничения инфраструктуры заказчика.
Дорабатывать действующую систему или разрабатывать с нуля?
Результаты аудита нужны не сами по себе, а чтобы сравнить возможные сценарии дальнейшей работы с системой. В зависимости от того, где находится проблема и насколько глубоко она затрагивает текущую архитектуру, компании может быть достаточно точечной доработки, частичной модернизации или разработки нового решения.
Доработать действующую систему
Допустим, отчёт замедляет один запрос к базе данных, а для новой интеграции достаточно изменить отдельный компонент. Разработчики исправляют запрос, настраивают обмен и проверяют связанные функции. Пользователи продолжают работать в привычной системе.
Риски: не заметить зависимости за пределами изменяемого компонента. Тогда уже после старта разработки могут появиться дополнительные работы, а сроки и смету придётся пересматривать.
Модернизировать часть системы
Если одни и те же правила повторяются в нескольких модулях, каждая новая функция требует изменений сразу в нескольких местах. Похожая ситуация возникает, когда веб-система и внешняя программа по-разному обновляют общие данные. Тогда может потребоваться переработка обработки данных или обмена между системами с сохранением остальных работающих компонентов.
Риски: не учесть переходный период. Обновлённые части какое-то время будут работать рядом с прежними, поэтому понадобятся дополнительные проверки. Иначе изменение одного процесса может нарушить другие.
Разработать новую систему с нуля
Этот вариант имеет смысл рассматривать, когда ограничения затрагивают основные процессы и модернизация отдельных компонентов не решает запланированных задач. Но новая система должна принять действующие данные, поддерживать нужные пользователям сценарии и взаимодействовать с внешними сервисами. Пока переход не завершён, прежнюю систему тоже придётся обслуживать.
Риски: недооценить объём работ. Помимо нового интерфейса и функций придётся переносить данные, восстанавливать бизнес-правила, настраивать интеграции и поддерживать старую систему до перехода на новую.
Данные для принятия решения
Аудит информационных систем должен дать руководителю подтвержденную картину ограничений: где находится причина проблемы, какие функции затронет исправление и какие риски остаются у каждого варианта. В результатах также фиксируют вопросы, на которые пока нельзя ответить, например отсутствие данных о работе кабинета под будущей нагрузкой.
На этой основе специалисты формируют последовательность действий и предварительный объём работ. Компания может сравнить доработку, модернизацию и замену по содержанию проекта. Точную смету составляют после выбора варианта и определения его границ.
Когда отдельный аудит не нужен
Если разработчики хорошо знают кабинет, правила работы описаны, а новая функция затрагивает понятный компонент, задачу можно оценить обычным способом. Например, для изменения одного отчёта с известным источником данных отдельное обследование всей системы будет лишней работой.
Поэтому вопрос, дорабатывать систему или делать заново, лучше решать не по количеству накопившихся проблем, а по их причинам и масштабу. Иногда достаточно исправить отдельный компонент, а иногда аудит показывает, что ограничения затрагивают систему целиком.