Как аудит информационных систем помогает сократить расходы на ИТ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

После этого проверяем ключевые предположения. Достаточно ли для подключения CRMпередавать данные о заявках или придётся менять порядок обновления их статусов? Где получать данные для новых отчётов и как их построение повлияет на работу кабинета? Технический аудит программного обеспечения в этом случае должен дать ответы, основанные на изучении системы и доступных показателях. Если данных для вывода пока нет, специалисты фиксируют, что именно нужно измерить или проверить дополнительно.

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

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

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

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

DIGITAL SECTOR разрабатывает и развивает корпоративные веб-системы: личные кабинеты, партнёрские порталы и внутренние сервисы. В таких проектах важно учитывать не только новые функции, но и действующие правила работы, роли пользователей, данные и интеграции. Например, при обновлении личного кабинета VEKA мы сохранили правила обработки заявок и существующий маршрут их передачи партнёрам, одновременно переработав интерфейс и код системы.

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

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