Аудит ERP-системы (ERP Audit)

Аудит ERP-системы (ERP Audit) — систематическая проверка того, что комплексная система планирования ресурсов предприятия (ERP) корректно настроена, обеспечивает целостность данных, соответствует требованиям контроля доступа и разделения обязанностей, и реально используется способом, соответствующим заложенным в неё бизнес-процессам, а не превратилась в дорогостоящую систему, частично обходимую сотрудниками через параллельные Excel-таблицы и неформальные процессы.

Задокументированный реальный кейс, показывающий цену теневого процесса вне формальной корпоративной системы: в 2012 году модель оценки риска (Value at Risk), на которую опиралась стратегия хеджирования лондонского подразделения JPMorgan Chase, работала не через формальную корпоративную систему, а через цепочку Excel-таблиц, данные между которыми вручную копировались сотрудниками из одной таблицы в другую. В одной из формул при пересчёте показателя волатильности сотрудник разделил величину на сумму двух значений вместо их среднего — техническая ошибка, которая примерно вдвое занизила расчётный показатель риска и позволила трейдерам наращивать позиции, фактически находясь в темноте относительно реального масштаба риска. Итоговые потери по позиции получили название «Лондонский кит» и составили 6,2 миллиарда долларов, а последующие регуляторные штрафы против JPMorgan Chase превысили 920 миллионов долларов. Официальное внутреннее расследование банка прямо указало на то, что критически важная модель риска работала на непроверенных вручную электронных таблицах вместо контролируемой корпоративной системы с должным разделением обязанностей и проверкой формул. Это прямая иллюстрация принципа: формальное наличие ERP или корпоративной системы управления рисками ничего не значит, если реальные критичные расчёты фактически происходят в неконтролируемых теневых таблицах, куда аудит системы даже не заглядывает.

Происхождение и исследовательская база

Методология аудита корпоративных информационных систем, включая ERP, во многом опирается на фреймворк COBIT (Control Objectives for Information and Related Technologies), разработанный Ассоциацией аудита и контроля информационных систем (ISACA) и Институтом ИТ-управления, впервые опубликованный в 1996 году. COBIT предоставляет менеджерам, аудиторам и пользователям ИТ общепринятый набор мер, индикаторов, процессов и лучших практик для максимизации выгоды от использования информационных технологий и выстраивания соответствующего ИТ-управления и контроля в компании. В отношении данных COBIT рассматривает целостность данных не как изолированный, самостоятельный объект контроля, а как результат взаимодействия архитектуры системы, безопасности, подотчётности, операционных процессов и обеспечения гарантий качества.

Типовые компоненты аудита ERP-системы: проверка разделения обязанностей (segregation of duties) в системе — недопущение ситуации, когда один пользователь имеет права одновременно инициировать и утверждать одну и ту же транзакцию, что создаёт возможность мошенничества или ошибки без независимой проверки; проверка целостности мастер-данных (master data) — насколько корректны и непротиворечивы базовые справочники системы (клиенты, поставщики, товарные позиции, план счетов), поскольку ошибки в мастер-данных каскадно распространяются на все последующие транзакции и отчёты; проверка соответствия настроенных в системе бизнес-процессов реальным операционным процессам компании; выявление «теневых» параллельных процессов (shadow IT) — случаев, когда сотрудники обходят ERP-систему через отдельные Excel-таблицы или иные неформальные инструменты из-за неудобства или неполноты функциональности системы.

Ключевое диагностическое наблюдение аудита ERP: наличие широко распространённых «теневых» Excel-процессов рядом с формально внедрённой ERP-системой — почти всегда индикатор того, что система либо не полностью покрывает реальные потребности бизнес-процессов, либо воспринимается пользователями как избыточно неудобная для повседневного использования — само по себе наличие дорогостоящей ERP-системы не гарантирует, что компания реально управляется через неё, а не через параллельную неформальную инфраструктуру.

Ключевые идеи и принципы

1. Принцип: разделение обязанностей в системе — структурная защита от мошенничества и ошибок.

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

2. Принцип: ошибки в мастер-данных каскадно распространяются на все последующие транзакции.

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

3. Принцип: наличие теневых параллельных процессов — индикатор реального, а не формального использования системы.

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

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: не проверяют матрицу прав доступа на предмет конфликтов разделения обязанностей.

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

   Как избежать

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

2. Ошибка 2: не уделяют приоритетного внимания проверке качества мастер-данных.

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

   Как избежать

   приоритизировать проверку целостности мастер-данных как объект аудита с наибольшим каскадным потенциальным эффектом ошибок.

3. Ошибка 3: не выявляют наличие теневых параллельных процессов вне ERP-системы.

   Аудит подтверждает формальное наличие настроенной ERP-системы, не проверяя, действительно ли реальные операции проходят через неё, а не через обходные Excel-таблицы или иные неформальные инструменты.

   Как избежать

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

4. Ошибка 4: не проверяют формулы и логику расчётов в теневых таблицах, обслуживающих критически важные для бизнеса решения.

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

   Как избежать

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

5. Ошибка 5: не проверяют, какой объём ручного копирования данных между системами и таблицами существует на пути критичного расчёта.

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

   Как избежать

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

План внедрения

1. Неделя 1: провести проверку матрицы прав доступа на конфликты разделения обязанностей

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

2. Неделя 2: провести проверку целостности мастер-данных

   Проанализировать корректность и непротиворечивость ключевых справочников системы — клиентов, поставщиков, товарных позиций, плана счетов.

3. Неделя 3: выявить теневые параллельные процессы через интервью с пользователями

   Опросить реальных пользователей системы на предмет использования обходных Excel-таблиц или иных неформальных инструментов.

4. Неделя 4: сформулировать план устранения выявленных проблем

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

   Далее: встраивание в регулярный цикл — установить периодичность повторного аудита ERP-системы по мере её обновления и расширения новыми модулями.

Как реализовать этот план с помощью фрейма «Аудит ERP-системы (COBIT)» в OrgDevTools

Фрейм собирает все проверки аудита в одном месте: матрицу прав, качество справочников и картину теневых процессов. Цифры он считает сам и показывает в итогах первую проблему, которую стоит закрыть. Это бесплатный тренажёр: на нём удобно отработать логику аудита на своих данных, даже если у вас пока нет выгрузок целиком.

Книги по теме

ISACA — «COBIT 2019 Framework: Governance and Management Objectives». Официальный фреймворк для аудита и управления корпоративными информационными системами, включая ERP.