IT-аудит: кому и в каких случаях необходим

В предыдущей статье я рассказала об IT-концепции при оценке новых проектов и продуктов. Сейчас хочу сделать акцент на ситуациях, когда концепции на этапе presale будет недостаточно. 

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

Аудит: что это такое и для чего необходим

IT-аудит — независимая проверка и оценка существующей системы или IT-ландшафта, в который будет встраиваться планируемый к разработке продукт.

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

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

Как правило, IT-аудит имеет 2 составные части: системную и процессную. 

Системная часть включает:

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

Процессная часть включает:

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

Дополнительно на этапе IT-аудита можно провести анализ:

• безопасности IT-инфраструктуры
• API информационных систем, их объем, достаточность и качество реализации
• сервисов, предоставляемых пользователям IT-инфраструктурой
• используемых решений на предмет их актуальности и целесообразности 

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

Когда необходим IT-аудит

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

Во-первых, при разработке новой системы, которая будет встраиваться в существующие процессы компании. 

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

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

IT-аудит в данном случае поможет грамотно распределить границы системы и зоны ответственности команд.

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

Здесь мы имеем в виду самостоятельную систему, которая не только должна покрывать функциональность «здесь и сейчас», но и предполагать направление для дальнейшего развития IT-ландшафта всей организации. Система будет создавать основу, которая позволит компании наращивать покрытие автоматизацией максимального количества процессов. IT-аудит поможет заблаговременно минимизировать риски, которые могут возникнуть при развитии продукта и смежных систем в будущем, и грамотно заложить IT-архитектуру в рамках бюджета, чтобы она имела необходимый запас прочности и обеспечивала гибкость при масштабировании.

В-третьих, при доработке существующей системы при смене подрядчика.

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

В-четвертых, при доработке существующей системы, когда у заказчика есть команда.

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

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

Если IT-аудит не провести:

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

Что происходит дальше

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

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

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

• 1 этап включает в себя передачу вводной информации, определение целей проекта, проведение самого IT-аудита. Итоговый документ на данном этапе — отчет по аудиту.
• 2 этап является фазой предпроектного обследования, проведение которой на базе аудита будет более точной и быстрой. Итоговые документы — техническая и бизнес-концепция, оценка описанных работ.

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

• 3 этап включает в себя аналитическую деятельность, формирование конечной архитектуры, прорисовку дизайна и сформированное итоговое техническое задание. Итоговый документ — сформированное и согласованное техническое задание на создание или модернизацию продукта.
• 4 этап является этапом реализации и внедрения итогового продукта или MVP (минимальной жизнеспособной версии). Итог данного этапа — готовый продукт, а также руководства пользователя и другая пользовательская документация.

Резюме

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

IT-аудит необходим, когда:

• новая система будет являться основой для IT-ландшафта компании
• новая система будет встраиваться в существующий IT-ландшафт компании
• новая система будет являться заменой зарубежного продукта и будет встраиваться в текущие процессы компании
• нужно доработать существующую систему после смены подрядчика
• нужно доработать существующую систему, создаваемую несколькими распределенными командами

По итогам аудита у заказчика появляется понимание текущей ситуации в направлении IT, взаимосвязей систем между собой и их эффективности, видение узких мест. Бизнес получает рекомендации по оптимизации ИТ-инфраструктуры либо подтверждение/ опровержение ее достаточности, оценку технологической интеграции и качества текущей реализации продукта. 

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