Автор: Виталий Подоспеев, менеджер дирекции по внутреннему аудиту, член Ассоциации «Институт внутренних аудиторов»

Внутренний аудит постоянно меняется, и изменения эти касаются всех сфер профессии. Еще недавно при анализе бизнес-процесса основным методом проверки контролей была выборка, на основе экстраполяции которой делался вывод об эффективности контроля. Недостатки этого метода очевидны. Главный – трудоемкость. Размер выборки должен быть таким, чтобы репрезентативно отражать всю совокупность, но с учетом размеров совокупностей, которые в крупных компаниях могут составлять миллионы и десятки миллионов в год, минимальный размер выборки может достигать сотни экземпляров для доверительной вероятности хотя бы в 95%. При этом всегда есть шанс того, что вам «повезет», и вы просто не попадете своей случайной или псевдослучайной выборкой на тот момент времени, когда присутствовали некоторые аномалии: будь то сбой систем, потеря информации или фрод, особенно, если явление было кратковременным. А ведь исследуемый контроль может и обычно бывает не один, либо объектом исследования является не тестирование контроля, а проверка некоторой гипотезы, которая в результате анализа совокупности данных должна быть принята или опровергнута.

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

К сожалению данная схема является весьма упрощенной, так как в идеале, чтобы убедиться, что контроль работает и эффективен, нужно изучить не только сам контроль, но и его «окружающую среду», известную как General IT Controls (GITC). Нужно убедиться, что отсутствует возможность временно внести изменения или отключить данный контроль, убедиться, что все изменения, связанные с данным контролем в достаточной мере логируются и должны быть корректно авторизованы (change management). Что логи изменений также должны быть защищены от умышленного изменения, а системы компании защищены от атак как извне, так и изнутри, и так далее и так далее, что влечет за собой полноценную оценку ИТ-инфраструктуры предприятия.

Как же тогда убедиться, что в исследуемом процессе все нормально и не было аномалий, сбоев, фрода, не проводя комплексный ИТ-аудит предприятия и не обрабатывая вручную сотни и тысячи транзакций? Лучшим и самым верным способом очевидно является анализ сразу всей совокупности, поиск в ней аномалий и выводы на основе такого анализа. Это уже работа для Data-аналитика. Еще десять лет назад мы упирались в техническую сложность проведения подобного анализа, однако с тех пор data science сделала ряд огромных скачков вперед как в методах работы с данными, так и в технических средствах хранения и обработки этих самых данных, и теперь анализ совокупности данных на миллиарды записей это не что-то выдающееся, а вполне рядовая задача для работников big data подразделений крупных компаний. Внутренний аудит не может оставаться в стороне от прогресса и в данной статье мы рассмотрим несколько вариантов работы с большими данными и то, какими инструментами при этом можно пользоваться.

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

  1. Неструктурированный уровень. Огромные объемы данных хранятся в разрозненных базах данных (далее БД). Данные каждого бизнес-процесса хранятся в одной или сразу нескольких БД. Отсутствует единое хранилище – агрегатор. При задаче анализа данных необходимо понять, что нужно, в каких БД предположительно находятся необходимые данные, как получить к ним доступ напрямую или нужно заказать выгрузку у ответственных лиц.

  2. Структурированный уровень. Существует единое корпоративное хранилище данных (далее КХД). Часто оно называется аналогичным англоязычным термином Data WareHouse (DWH). В данное хранилище «стекаются» данные из значительного количества различных БД компании. Данные хранятся как есть или в агрегированном виде. Существует отдельный штат сотрудников, обеспечивающих функционирование КХД, добавление в него новых источников данных и обеспечивающих корректность и актуальность данных. Может иметься относительно дружественный интерфейс (такой как у Oracle BI, SAP BO, SAS BI и подобные), позволяющий конструировать аналитические запросы людям, не знакомым с SQL.

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

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

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

  2. Выгрузка может быть ошибочной. Зачастую, когда внутренний аудит формулирует свои требования к выгрузке, отсутствует полное понимание особенностей системы и хранения данных в ее БД. Ответственный сотрудник, непосредственно осуществляющий выгрузку, зачастую получает запрос уже в готовом виде, может не понимать цели, которой хотят добиться внутренние аудиторы, и исполнить запрос AS IS (буквально) без учета важных нюансов, так как их нет в начальном запросе. Кроме того, ответственный может просто ошибиться при написании SQL-запроса либо в работе с БД, и данные будут некорректны.

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

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

К сожалению, при таком уровне зрелости работы с данными компании у внутреннего аудита не так много инструментов для проведения сплошного анализа. Если в штате есть сотрудник, обладающий знаниями SQL, можно попытаться самостоятельно получить доступ на чтение к нужной БД, или хотя бы ее тестовой версии с релевантными данными и провести необходимый анализ путем запросов. Однако главной проблемой будет тот факт, что таких БД в компании много, у каждой из них своя внутренняя архитектура (в каких таблицах что лежит), без знания которой написать правильный запрос невозможно. Внутренняя архитектура данных в таких случаях зачастую нигде не задокументирована, и ее придется каждый раз изучать заново с привлечением ответственных сотрудников. Кроме того, не во всех случаях доступ к БД вообще можно получить, например, в силу особенностей самой информационной системы или из соображений возможного нарушения производительности продуктивной системы в результате выполнения аналитических вопросов.

Если предположить, что данные все-таки получены в нужном виде от подразделения, но они являются крайне большими (более нескольких миллионов строк, более гигабайта размером и т.п.) возникает насущная проблема: как эффективно обработать такой объем. Как известно «основной инструмент аудитора» – MS Excel – крайне плохо работает с большими объемами данных. Предположим, у нас стоит задача сопоставить данные из одной таблицы с данными из другой, то есть «подтянуть данные», что обычно делается функцией ВПР. Операция ВПР при размерах 400 000 строк одной таблицы и 300 000 строк в другой будет длиться несколько часов даже на очень мощных компьютерах. При таблицах «миллион на миллион» окончания операции за адекватное время вы гарантированно не дождетесь. Также нужно учитывать особенности самой операции ВПР: что она может подтянуть лишь первое вхождение искомого значения. А что если в обеих таблицах есть повторяющиеся значения, и вам нужны их разные комбинации?

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

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

Лучшим решением будет занести полученные данные в БД или BI-решение (подробнее о том, что это такое, далее). Первым на ум приходит MS ACCESS, в который импортируются обе таблицы и далее конструктором строятся необходимые запросы. К сожалению, как инструмент MS Access не является достаточно стабильным при работе с данными более гигабайта в текстовом виде, проблемы могут начаться еще на стадии корректного импорта данных, когда приложение просто будет «вылетать» с ошибкой без объяснения причин.

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

Что делать, если большая выгрузка есть, а специалиста-аналитика со знанием SQL нет? Для решения этой задачи был создан ряд программных инструментов, которые в последние несколько лет набирают всю большую популярность. В первую очередь стоит выделить инструменты MS Power Pivot и MS Power BI. Это так называемые инструменты BI, которые содержат интерфейс, знакомый все пользователям MS Office, однако внутри устроены совершенно по-другому. По сути, внутри этих инструментов импортируемые данные хранятся в некоем подобии БД, работа с которой осуществляется при помощи искусственного языка формул Data Analysis eXpressions (DAX). Данный язык похож на всем известные формулы в Excel, а в целом инструменты интуитивно понятны для людей, не знакомых с языками и средами программирования. Power Pivot позволяет работать с загруженными данными с помощью обычных «сводных таблиц» Excel, накладывая дополнительную аналитику, а Power BI развивает эту идею, представляя пользователю полноценную среду, в которой, например, можно настроить автоматический сбор данных из различных источников с дальнейшей их обработкой по заданным пользователям правилам.

*На картинке представлен пример использования DAX в POWER PIVOT. Данная языковая конструкция является аналогом ВПР из Excel и добавляет в данную таблицу соответствующие значения из связанной по внешнему ключу другой таблицы.

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

Инструменты от MS не являются уникальными, но, наверное, наиболее доступны по стоимости (Power Pivot вообще включен бесплатно в некоторые пакеты MS Office) и в плане легкости обучения и использования далекими от программирования сотрудниками. Из аналогичных инструментов можно выделить SAS EG и подобные, сразу содержащие в себе инструменты для визуализации обрабатываемых данных, однако они намного дальше ушли от классического MS Office, и обучение их эффективному использованию требует значительных усилий и накапливания опыта для людей, незнакомых со средами программирования.

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

Итак, в компании есть свое КХД, а это означает, что в него попадают данные из значительного числа информационных систем компании и вполне вероятно даже существует дружественный пользовательский интерфейс, позволяющий конструировать запросы путем понятных пользователю манипуляций в окне приложения либо в сводной таблице MS Excel, которая подключается к КХД в реальном времени. Чаще всего такие хранилища строятся на базе высокопроизводительных БД, специально ориентированных на аналитические задачи, например, БД TeraData. А это означает, что запросы к таблицам на миллиарды строк будут выполняться за считанные минуты.

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

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

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

Также с высокой вероятностью у вас уже внедрены и активно используются решения Process Mining, такие, например, как SAP Celonis, позволяющие анализировать и визуализировать сложные и масштабные бизнес-процессы с целью поиска аномалий или выстраивания общей картины процесса с различными «исключительными» маршрутами.

*На картинке представлен пример автоматического построения дерева процесса с использованием инструмента SAP Celonis.

Вполне вероятно, что данные, получаемые в результате аналитики вы визуализируете с помощью специализированных инструментов, таких как соответствующие библиотеки к языкам программирования Pyton, R, JavaScript либо отдельные решения, такие как ClickHouse и Tableau.

Все описанное в статье – от проверки документов по выборке «вручную» до машинного обучения собственной модели – является в настоящее время работой и задачами аудитора, как внутреннего, так и внешнего. Существующие сертификации, такие как Certified Internal Auditor (CIA) и Certified Information System Auditor (CISA), стараются идти в ногу со временем и включают хотя бы обзорно все вышеуказанное в свои курсы и выносят соответствующие вопросы на экзамен.

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