Аудит ИТ-отдела: с чего начать

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

Константин Попандопуло

Технический директорUmbrella IT

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

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

В ходе аудита описывается: 

● То, как сейчас работает ИТ-департамент — AS IS; 

● То, как он должен работать —  TO BE. 

Сравнение текущего и целевого состояния помогает обнаружить проблемы и узкие места. На основе этого анализа и формируются детализированные рекомендации. 

Планирование и подготовка

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

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

Стандартный скоуп аудита

Мы разработали собственную программу полного аудита ИТ-отдела и придерживаемся этого плана в работе. Список блоков обширен, но можно выделить главные пункты, общие для большинства проектов. 

Что мы аудируем: 

● Организационную структуру департамента, роли, зоны ответственности и обязанности сотрудников; 

● Качество взаимодействия между бизнесом и ИТ-структурой; 

● Эффективность коммуникации: через какие каналы ведется, насколько часто и продуктивно; 

● Потребности бизнес-подразделений в ИТ: насколько цифровые услуги и решения соответствуют бизнес-потребностям; 

● Риски при текущем состоянии департамента; 

● Технологии, используемые для управления и разработки, их актуальность и соответствие потребностям организации; 

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

● Систему управления человеческими и материальными ресурсами, знаниями, регламентами; 

● Этапы разработки от системной аналитики до доставки результата; 

● Уровень удовлетворенности и лояльности сотрудников с точки зрения HR (опрос NPS — Net Promoter Score). 

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

Формирование команды 

Аудитом должны заниматься опытные эксперты. Мы, например, привлекаем на такие проекты только старших специалистов (Senior) и лидеров команд (Team Leads). В состав команды аудита обычно входят: 

● Проектный менеджер — руководит процессами и выступает экспертом по анализу проектной части; 

● Аккаунт-директор — участвует в выявлении проблем бизнеса и формировании рекомендаций; 

● Системный аналитик — играет ключевую роль во всесторонней оценке ИТ-отдела и поиске слабых мест в работе систем и процессов; 

● Ассистенты — помогают системному аналитику и проектному менеджеру с административными задачами.

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

Сбор данных 

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

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

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

Приоритизация и оценка рисков 

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

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

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

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

Документирование 

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

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

Финальный отчет — объемный официальный документ, включающий всю информацию по проекту: AS IS, TO BE, рекомендации. Вместе с ним передаем заказчику протоколы, записи интервью с заинтересованными сторонами, оригиналы изображений отчета (диаграммы бизнес-процессов, карты коммуникаций и т. д.). 

Презентация включает визуализированные материалы с минимальным количеством текста. Именно этот документ показывают на защите проекта для демонстрации выполненной работы.

Распространенные ошибки 

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

1. Подготовить график встреч и согласовать его с заказчиком и стейкхолдерами. 

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

3. Обязательно запротоколировать встречи. После сбора и структурирования всей информации скомпилировать данные — они войдут в финальный отчет. 

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

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

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

***

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

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