Аудит 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-системы не гарантирует, что компания реально управляется через неё, а не через параллельную неформальную инфраструктуру.
Ключевые идеи и принципы
Принцип: разделение обязанностей в системе — структурная защита от мошенничества и ошибок.
Пользователь, обладающий одновременно правами на инициирование и утверждение одной и той же транзакции (например, создание поставщика и утверждение платежа этому поставщику), обходит механизм независимой проверки — аудит должен явно проверять матрицу прав доступа на предмет подобных конфликтов полномочий.
Принцип: ошибки в мастер-данных каскадно распространяются на все последующие транзакции.
Некорректная запись в базовом справочнике системы (неверный план счетов, дублирующиеся карточки клиентов или поставщиков) искажает все последующие отчёты и транзакции, построенные на основе этих данных — проверка целостности мастер-данных является приоритетной, поскольку её ошибки имеют наибольший каскадный эффект.
Принцип: наличие теневых параллельных процессов — индикатор реального, а не формального использования системы.
Формальное внедрение ERP-системы не гарантирует, что все реальные операции компании проходят именно через неё — широкое использование параллельных Excel-таблиц или иных обходных инструментов сигнализирует о разрыве между формальным и реальным управлением бизнес-процессами.
Ограничения, слепые зоны и критика
Аудит ERP-системы требует значительной технической экспертизы как в самой платформе (структура данных, конфигурация модулей), так и в бизнес-процессах компании — команда, обладающая только техническими знаниями системы, но не понимающая реальную специфику бизнес-процессов, рискует упустить содержательные, а не только технические расхождения.
Проверка разделения обязанностей и матрицы прав доступа особенно сложна в небольших организациях с ограниченным штатом — физическое разделение ролей между разными сотрудниками не всегда практически осуществимо при малом числе персонала, что требует компенсирующих контрольных механизмов вместо чистого структурного разделения.
Аудит фиксирует текущее состояние настройки и использования системы, но ERP-системы регулярно обновляются, дорабатываются и расширяются новыми модулями — разовый аудит устаревает по мере эволюции системы, требуя периодического повторения, а не единовременной проверки.
Типовые ошибки
Ошибка 1: не проверяют матрицу прав доступа на предмет конфликтов разделения обязанностей.
Пользователи обладают одновременно правами инициирования и утверждения одних и тех же типов транзакций, что создаёт возможность мошенничества или ошибки без независимой проверки, оставаясь незамеченным до реального инцидента.
Как избежать: систематически проверять матрицу прав доступа на конфликты разделения обязанностей и устранять их или вводить компенсирующие контрольные механизмы.
Ошибка 2: не уделяют приоритетного внимания проверке качества мастер-данных.
Аудит фокусируется на проверке отдельных транзакций, не проверяя корректность и непротиворечивость базовых справочников системы, ошибки в которых каскадно искажают все последующие отчёты.
Как избежать: приоритизировать проверку целостности мастер-данных как объект аудита с наибольшим каскадным потенциальным эффектом ошибок.
Ошибка 3: не выявляют наличие теневых параллельных процессов вне ERP-системы.
Аудит подтверждает формальное наличие настроенной ERP-системы, не проверяя, действительно ли реальные операции проходят через неё, а не через обходные Excel-таблицы или иные неформальные инструменты.
Как избежать: явно выявлять и анализировать наличие теневых параллельных процессов, интервьюируя реальных пользователей системы о фактической практике их работы.
Ошибка 4: не проверяют формулы и логику расчётов в теневых таблицах, обслуживающих критически важные для бизнеса решения.
Ошибочная формула в модели расчёта риска JPMorgan (деление на сумму вместо среднего) осталась незамеченной, потому что таблица, где она находилась, не проходила формальной технической проверки и рецензирования, которым подвергаются расчёты внутри контролируемой корпоративной системы.
Как избежать: Для любой обнаруженной теневой таблицы, влияющей на критически важные бизнес-решения, проводить формальную техническую проверку формул и логики расчётов — точно так же, как это делается для настроенных отчётов внутри корпоративной системы.
Ошибка 5: не проверяют, какой объём ручного копирования данных между системами и таблицами существует на пути критичного расчёта.
Данные для модели риска JPMorgan вручную копировались между несколькими электронными таблицами — каждый акт ручного копирования создавал самостоятельную точку риска ошибки, независимо от корректности исходных данных и итоговой формулы.
Как избежать: Явно картировать цепочку ручного копирования данных между системами и таблицами для критичных расчётов — каждая точка ручного переноса данных без автоматизации является самостоятельным источником риска, который нужно выявлять и устранять отдельно.
Главное, что нужно знать
Аудит ERP-системы (методология COBIT, ISACA, 1996) — проверка настройки, целостности данных и реального использования комплексной системы управления ресурсами.
Разделение обязанностей в системе — структурная защита от мошенничества, требующая проверки матрицы прав доступа на конфликты полномочий.
Ошибки в мастер-данных имеют наибольший каскадный эффект, распространяясь на все последующие транзакции и отчёты.
Наличие теневых параллельных Excel-процессов — индикатор разрыва между формальным внедрением и реальным использованием системы.
Аудит требует периодического повторения, поскольку ERP-системы регулярно обновляются и дорабатываются.
План внедрения
Неделя 1: провести проверку матрицы прав доступа на конфликты разделения обязанностей
Выявить пользователей с одновременными правами инициирования и утверждения одних и тех же типов транзакций.
Неделя 2: провести проверку целостности мастер-данных
Проанализировать корректность и непротиворечивость ключевых справочников системы — клиентов, поставщиков, товарных позиций, плана счетов.
Неделя 3: выявить теневые параллельные процессы через интервью с пользователями
Опросить реальных пользователей системы на предмет использования обходных Excel-таблиц или иных неформальных инструментов.
Неделя 4: сформулировать план устранения выявленных проблем
Определить конкретные корректирующие действия по устранению конфликтов доступа, ошибок мастер-данных и теневых процессов.
Далее: встраивание в регулярный цикл — установить периодичность повторного аудита ERP-системы по мере её обновления и расширения новыми модулями.
Как реализовать этот план с помощью фрейма «Аудит ERP-системы (COBIT)» в OrgDevTools
Фрейм состоит из четырёх карточек на вкладке «Карточки», каждая соответствует одной неделе плана внедрения выше.
Неделя 1 — карточка «Проверка матрицы прав на разделение обязанностей». Сюда вносится, что никто не должен одновременно инициировать и утверждать одну и ту же транзакцию — отсутствие такой проверки прямо повторяет ошибку 1.
Неделя 2 — карточка «Целостность мастер-данных — приоритет проверки». Сюда вносится проверка базовых справочников, ошибки в которых каскадно искажают все последующие транзакции — отсутствие приоритета для этой проверки прямо повторяет ошибку 2.
Неделя 3 — карточка «Выявление теневых Excel-процессов». Сюда вносятся результаты интервью с реальными пользователями — индикатор разрыва между формальным внедрением и реальным использованием, невыявление которого прямо повторяет ошибку 3.
Неделя 4 — карточка «Соответствие настроенных процессов реальным». При формировании плана устранения проблем сюда вносится, действительно ли система отражает реальные бизнес-процессы компании.
Вкладка «Итоги» явно предупреждает, если матрица прав не проверена или мастер-данные не проверены как приоритет. Кнопка создания задачи формирует задачу «Проверить разделение обязанностей, целостность мастер-данных и выявить теневые процессы».