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

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

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

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

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

Наименование вопроса

Краткое описание

1

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

Выявление основных требований по реализации операций, определение цели и показателей эффективности процесса

2

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

Определение основных целей/ задач проекта, ограничений, ролей и ответственности. Связь с процессными показателями.

3

Изучение набора данных

Реализация процедур/ операций в соответствии с поставленными целями/ задачами, ограничениями. Интеграция. Пошаговое выполнение.

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

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

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

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

Вопрос

Примеры описания

Примечание

Корректное

Неполное

1

Кто

Оператор станка

Пользователь модуля

При изменении оргструктуры могут оставаться старые наименования должностей

2

Когда

В течение 1 часа

По мере необходимости

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

3

Что

Регистрирует событие о неисправности в форме «Сообщение о неисправности» информацию о неисправности: дата/ время, описание.

Заносит в ИС информацию о событии

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

4

В каком объеме

Заполняет следующие атрибуты: тип оборудования, описание, дата/ время возникновения, приоритет

5

Доп. условия

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

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

Условия могут быть разбросаны на разных уровнях: в регламенте указано определение критичности, а в пользовательской инструкции – время реагирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 2:

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

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

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

Рисунок 3:

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

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

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

Рисунок 4:

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

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

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

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

Рисунок 5:

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

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

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

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

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

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

Общий вывод

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


1. Ассоциация «Институт внутренних аудиторов» (Ассоциация «ИВА»), зарегистрированная в 2000 г., является профессиональным объединением более чем 4000 внутренних аудиторов, внутренних контролеров и работников других контрольных подразделений российских компаний и организаций. Подробности на сайте www.iia-ru.ru

2. Имеется в виду процесс, который автоматизирован за счет использования аудируемой ИС.

3. При раскрытии термина использованы материалы презентации «ИТ-аудит в рамках регулярного аудита», автор Степаненко Дмитрий Александрович, ссылка на источник - https://fbk-pravo.ru/upload/docs/10_IT-audit.pdf

4. Прежде всего подразумевается производственная культура персонала.

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

6. В реальности взаимосвязей и документов может быть больше, приведенные примеры адаптированы для упрощения понимания.

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

9. Массив оборудования «без ремонта» был детализирован до конкретных подразделений и ФИО ответственных.

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

11. Нормативно-справочная информация.

12. Ввиду ограниченности времени на внедрение ИС, обычно контур проекта ограничивают пилотной выборкой, например, на несколько подразделений.

13. По терминологии ITIL 2011v3, Change Management. Отдельный вопрос для полноценного исследования.