Аудит оценки качества данных в информационной системе

Авторы: Дмитрий Кашин, CIA, Николай Белых, CIA, EMBA Stockholm School of Economics, члены Ассоциации «Институт внутренних аудиторов»¹

1. Общая концепция оценки качества данных в действующих информационных системах

Большинство информационных систем на предприятиях являются достаточно ценными источниками информации для аудитора, что в комплексе с действующими локально-нормативными актами (далее – ЛНА), может формировать полноценную картину существующей реализации процесса или целой группы процессов. Однако, прежде чем перейти к формированию суждений на основании данных в существующей информационной системы (далее – ИС), необходимо определить качественный состав хранимой информации, что позволит сделать вывод о доверии и выбрать пути дальнейшего использования. В данной статье будут рассмотрены практические методы по оценке качества данных в действующих информационных системах с целью формирования независимого мнения о существующем уровне использования системы и/или ценности данных в ИС для проведения аудита процесса², в том числе с использованием современных средств автоматизации.

В целом, по мнению автора, подобная проблематика контрольного мероприятия является составляющей ИТ-аудита ИС. Что он из себя представляет? Это процесс³ сбора и анализа свидетельств для оценки того, насколько ИС и ее компоненты: адекватно обеспечивают сохранность активов и поддерживают целостность данных; предоставляют соответствующую и надежную информацию; помогают в достижении целей компании; экономно используют ресурсы компании; имеют эффективные внутренние контроли, которые обеспечивают разумную уверенность в том, что цели достигнуты и нежелательные события будут предотвращены или замечены и исправлены своевременно. Основная задача: получить уверенность в том, что информационная система реально помогает пользователю/ владельцу в достижении целей.

Общее содержание (основные вопросы) подобного аудита будут выглядеть следующим образом:

№	Наименование вопроса	Краткое описание
1	Поиск и анализ действующих ЛНА	Выявление основных требований по реализации операций, определение цели и показателей эффективности процесса
2	Анализ действующих документов проекта по внедрению ИС	Определение основных целей/ задач проекта, ограничений, ролей и ответственности. Связь с процессными показателями.
3	Изучение набора данных	Реализация процедур/ операций в соответствии с поставленными целями/ задачами, ограничениями. Интеграция. Пошаговое выполнение.

В комплексе данные вопросы позволят убедиться в достижении целей/ задач проекта по внедрению ИС. Но если основная цель вашего аудита – оценка качества данных без определения причин и степени влияния на процесс, то пункты 1 и 2 возможно исключить полностью, а пункт 3 сократить (упрощенный формат – зеленая область на схеме ниже) до проверки реализации процедур/ операций. Эта же логика, в схематичном исполнении, с учетом иерархии реализации от общего к частному, и существования целевой (проверяемой) ИС, а также массива данных (БД), представлена ниже (рис.1):

1. Поиск и анализ действующих ЛНА

Основные задачи, решаемые на данном этапе путем изучения ЛНА: определение цели/ основных показателей процесса и детализации его операций. Показатели процесса крайне важны для определения эффективности автоматизации данного процесса (внедрения целевой ИС), а детализация основных операций поможет вам понять основную логику и объекты (документы) процесса – ключевые сущности, которым в последующем будет уделено особое внимание. Дополнительно возможно обратить внимание на версионность ЛНА в момент внедрения средства автоматизации – сравнение двух редакций поможет определить влияние итогов автоматизации на проект в целом. Например, данное сопоставление позволяет выявить и объективно подтвердить/ опровергнуть существенные изменения в процессе, что является признаком внедрения best practice. Либо, отсутствие существенных изменений будет свидетельствовать об автоматизации процесса AS IS. Также в совокупности с анализом действующих инструкций пользователя, а также проектной документацией (в рамках пункта 2) целесообразно проверить уровень регламентации действий пользователя и выдвинуть гипотезу о достаточности данного уровня. Для самопроверки нужно получить ответ на основные вопросы, используя совокупность существующих документов.

Рассмотрим пример занесения информации о неисправности оборудования на производстве:

№	Вопрос	Примеры описания		Примечание
		Корректное	Неполное
1	Кто	Оператор станка	Пользователь модуля	При изменении оргструктуры могут оставаться старые наименования должностей
2	Когда	В течение 1 часа	По мере необходимости	Если в документации заявлено использование временных триггеров типа «ежемесячно/ еженедельно» и т.д., то стоит обратить внимание на их конкретную реализацию в интерфейсе ИС
3	Что	Регистрирует событие о неисправности в форме «Сообщение о неисправности» информацию о неисправности: дата/ время, описание.	Заносит в ИС информацию о событии	Детализация возможна на уровне пользовательских инструкций. Дополнительные контроли по правилам занесения на уровне ИС/ исполнительной документации.
4	В каком объеме	Заполняет следующие атрибуты: тип оборудования, описание, дата/ время возникновения, приоритет
5	Доп. условия	Если неисправность вызвала остановку производственной линии, то занесение происходит в течение 10 минут после выявления с дублированием информации по средствам телефонной связи дежурному механику.	Если неисправность является критичной, необходимо оперативно занести информацию в систему и сообщить дежурному механику.	Условия могут быть разбросаны на разных уровнях: в регламенте указано определение критичности, а в пользовательской инструкции – время реагирования.

2. Анализ действующих документов проекта

На данном этапе особенно важно понять основные параметры и ограничения, принятые при внедрении ИС, а также планируемые механизмы интеграции. При ознакомлении с основными документами проекта, такими как устав и техническое задание (далее – ТЗ), свое исследование стоит начать с формулировок цели, задач и результатов внедрения. Например, целью может выступать оптимизация затрат на процесс, а результат – «программное обеспечение внедрено», что свидетельствует об отсутствии соответствия цели и результата. Использование ряда ключевых слов в формулировках целей, задач и описании результата, например, «стандартизация, оптимизация, регламентация, минимизация/ максимизация» подразумевает большую методологическую работу помимо самой разработки и внедрения программного продукта, которая часто не проводится в полной мере. Особенно в подобных случаях следует уделить внимание контуру внедрения: чем больше контур (предприятия и подразделения), тем больше требуется методологической работы, тем больше потенциальных ошибок обычно допускается в единых справочниках, статусах, состояниях, методах обработки.

Например, единая автоматизация процесса технического обслуживания и ремонта (далее – ТОРО) с целью стандартизации и оптимизации затрат будет значительно сложнее на нескольких предприятиях, чем на одном, ввиду объективных различий (если это не устранено до проекта автоматизации) в методах ведения учета номенклатуры оборудования (название, характеристики), описании регламентных операций и культуре⁴ персонала.

Также любые стремления по «оптимизации затрат, минимизации времени протекания» должны иметь объективную методику оценки и количественное выражение достигнутых результатов. Зачастую данному вопросу в проекте не уделяется должного внимания, а основная работа в этом направлении происходит на завершающем этапе, что не позволяет провести измерение непосредственно до внедрения, сама методика оценки не учитывает прочие изменения в процессе/ орг. структуре/ объектах, которые происходят параллельно с внедрением.

Например, в качестве эффекта проекта по автоматизации процесса заявлено снижение стоимости (затрат) на проведение ТОРО. Для того чтобы объективно измерить влияние именно автоматизированной системы на процесс, нужно убедиться как минимум в следующем:

• методика измерения стоимости разработана до начала проекта, измерение произведено по данной методике до начала всех работ;

• условия измерения (количество, состав, загрузка оборудования, орг. изменения) сопоставимы;

• сам процесс ТОРО не должен измениться.

Если проект длится не более 1 года, то в рамках методики можно учесть изначальную контрольную группу (выборку), на которой производится измерение до и после проекта. В рамках реализации проекта нужно максимально детально фиксировать все события, которые могут повлиять на качественный состав, например: списание старого оборудования, ввод в эксплуатацию нового оборудования. При повторном расчете, по итогам внедрения, изначальная контрольная группа должна быть очищена от подобных изменений (позиции оборудования исключены), а первоначальный расчет – актуализирован. Но при достаточно большой общей совокупности (более 1000 единиц) и/или при длительных сроках реализации проекта (более 1 года), отслеживание изменений в контрольной группе может отвлекать значительные ресурсы, что в итоге приведет к отсутствию целесообразности применения методики и измерения эффекта в целом.

2 . Практические примеры реализации общей концепции оценки качества данных

Изучение набора данных – логика проведения аудита качества данных

В данном разделе будут рассмотрены возможные варианты⁵ поиска и подтверждения гипотез несоответствия разработанной системы существующему процессу, с примерами из практики⁶. Подобный поиск можно проводить как минимум двумя путями:

I. Сверху вниз – от общих ЛНА к ТЗ и непосредственно самой системе. Кейс – отсутствие контролей на уровне приложения.

Общее описание: данный кейс иллюстрирует пример некорректного содержимого в карточке «Единицы оборудования» в части несоответствия параметров Статус и Код АВС между собой, ввиду отсутствия контролей на уровне приложения. Возможные варианты встроенных (автоматизированных) контролей – предупреждение (например, запрет с уведомлением) и/или ограничение ввода противоречивых параметров непосредственно в форме и/или в процессе дальнейшей обработки карточки (сохранении/ изменении).

Логика исследования (рис.2):

0. На уровне ЛНА был определен изначально «сложный» параметр, который отвечал за логику соответствия Кода – Статусу у объекта «Единица оборудования». В рассматриваемом примере Статус «ОПО» не подразумевал возможность присвоения категории оборудования, отличной от «А».

1. В Концептуальном бизнес-проекте⁷ (далее – КПБ) отсутствовало описание вспомогательных механизмов заполнения/ контроля заполнения.

2. В операционной инструкции отсутствовало описание необходимого контроля.

3. На примере нескольких записей эта гипотеза была подтверждена в приложении (рис.2).

4. Из системы была произведена выгрузка всех Единиц оборудования по правилу статус = ОПО и Код не равный «А»⁸.

Рисунок 2:

Негативные последствия подобного заполнения карточки единицы оборудования (далее – ЕО) не позволяли установить требуемый план обслуживания данного типа оборудования, что создавало риски внеплановой поломки и остановки ключевого оборудования. Основная причина – ТЗ и КПБ не включали требуемые контроли и/или подсказки для пользователя на уровне приложения, ввиду отсутствия понимания значимости у разработчика.

II. Снизу вверх – от системы/ массива данных к ТЗ/КПБ и общим ЛНА. Кейс – отсутствие обязательности атрибутов в форме и их проверки на соответствие.

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

Рисунок 3:

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

Логика исследования (рис.3):

0. Факты отсутствия заполнения/ некорректные данные замечены при ознакомлении с системой (рис.4: имя сообщения «drhy» не несет смысловой нагрузки, атрибуты «ТехнМесто», «Ед.оборудов.» «Приоритет» и «ТребуемЗаверш» не содержат информации), количество отклонений подтверждено выгрузкой.

Рисунок 4:

1. Получено понимание данной функциональности в ЛНА.

2. Проверено описание в КПБ и Операционной инструкции (далее – ОИ).

В итоге выявлены различия в обязательности по атрибутам:

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

Рисунок 5:

III. Сверху вниз – от общих ЛНА к самой системе. Кейс – отсутствие возможности проведения ремонтов (неиспользование системы).

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

Общая логика отражения ремонта в ПО (реализована в системе и подтверждена на уровне ЛНА) за счет обработки двух основных сущностей:

• Оборудование – объект ремонта;

• Заказ – фактический список операций с материалами и трудозатратами.

Соответственно, для проведения ремонта необходимы единица оборудования и сформированный заказ на основании (не обязательно) технологической карты. Полная выборка данных сущностей за 2 года работы показала, что по действующему массиву оборудования (100%) существует всего 46% единиц, по которым существует хотя бы 1 заказ. Детальное исследование⁹ «оборудования без ремонта» показало, что отсутствие ремонта связано с недостаточной регламентацией требования по использованию ПО в отдельных подразделениях компании.

Общий вывод

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

1. Проверка качества данных – прежде всего

По всем атрибутам основных сущностей исследуемой системы производится проверка полноты и правильности заполнения (кейс 1 и 2), что позволяет определить:

• гипотезы о возможных несоответствиях;

• фактическую картину использования;

• направление исследования.

2. Сортировка, группировка, классификация и приоритизация найденных гипотез

В приведенных кейсах рассмотрены 3 основные группы возможных отклонений:

a. Отсутствие основных сущностей (кейс 3 – неиспользование системы). Максимальный приоритет ввиду возможного наличия причин, способных повлиять на общий вывод по аудиту в целом. Например, система не используется, так как не все требования пользователей были учтены при разработке, либо не обеспечена заявленная интеграция, либо отсутствует организационная обвязка¹⁰ процесса внедрения.

b. Отсутствие обязательных контролей (кейс 1). Средний приоритет ввиду значительного влияния автоматизированных контролей на итоговый результат процесса в целом. Например, одна из целей автоматизации любого процесса – снизить требования к компетенциям конечного пользователя путем встраивания автоматизированных контролей и подсказок, способных исключить ошибочные действия. Дополнительно стоит обратить внимание на механизмы работы с дублями, аналогами и на логику работы с ошибками/ исключениями в НСИ¹¹. Если требования по разработке данных механизмов отсутствуют в ТЗ, в исполнительной документации не прописаны процедуры обработки/ недопущения дублей, то это является индикатором дальнейших проблем при работе с ИС. Также стоит учесть пути появления дублей в системе – интеграция с иными ИС и разовый/ регулярный экспорт данных.

c. Отсутствие корректности заполнения (кейс 2). Низкий приоритет. Поскольку несоответствия в части заполнения могут присутствовать практически во всех действующих ИС, необходима 100%-ная выборка для определения объективного влияния на результат и для детализации возможных причин.

3. Детализация приоритетных групп гипотез

В соответствии с основными целями контрольного мероприятия и определенными приоритетам, происходит детализация гипотез по группам. Операции по проверке корректности заполнения являются автоматизируемыми при частом использовании. Базовый инструмент – Excel (Power Query, сводные таблицы), расширенный инструментарий – программное обеспечение по направлению Data Science/ аналитические платформы в части проверки качества исходных данных (Dataiku DSS/ Loginom).

4. Формирование общего мнения о достижении целей/ задач и результата проекта

Как правило, достижение целей/ задач и результатов проекта (параметры проекта) проверяется в момент завершения проекта. Скорее всего, данные параметры будут описывать состояние автоматизируемого процесса в целом, однако полноценно оценить их достижение возможно только через 1 год (это примерный срок, который зависит от характера ИС и методики оценки) промышленной эксплуатации. Это условная величина, на которую влияет масштаб проекта и изначальный контур¹² внедрения. Поэтому, для формирования общего мнения, с учетом подтвержденных гипотез на предыдущих этапах, стоит учесть опыт промышленной эксплуатации, а при наличии существенных доработок ИС – и сам процесс работы с изменениями¹³.

---