SOD-контроли: определение, типовые шаги, реализация в бизнес-процессах и ERP-системах

Подробности: Опубликовано: 21.02.2026 10:05; Автор: Степанов Дмитрий Юрьевич; Просмотров: 29

Корпоративные информационные системы и учетная политика организации при применении автоматизированной формы ведения учета

Аннотация: в статье рассматривается процедура Segregation of Duties, известная под сокращением SOD, обеспечивающая разграничение обязанностей сотрудников и позволяющая предотвратить ошибки пользователей, минимизировать риски мошенничества и исключить конфликты интересов. Анализируются шаги имплементации принципов SOD в работу организации: создание SOD-матрицы, присвоение ролей и полномочий, контроль SOD-конфликтов посредствам регулярного аудита и автоматизированного мониторинга. Описываются особенности внедрения SOD в бизнес-процессы, реализуемые в информационных системах. Формулируется вывод о том, что SOD есть осознанная потребность текущего времени, гарантирующая управляемость и целостность критически значимой информации.
Ключевые слова: segregation of duties sod, матрица sod, ведение матрицы sod в SAP, sod риски, sox контроль что это, SAP GRC, SAP GRC risk management, ролевая модель в 1С, роли в 1С, 1С роли пользователя, SAP роли, полномочия роли SAP, SAP роли пользователя, разграничение ответственности, разграничение права и обязанности, компенсирующий контроль.
Скачать: PDF (статья), PDF (выпуск №33).

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

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

Детективный контроль позволяет выявлять подобные случае по мере возникновения неблагоприятных событий. Наоборот, предиктивный контроль пресекает подобные исходы на корню. Именно на последних мы и остановим внимание в данной статье. Применительно к программному обеспечению подобный вид проверок тесно связан с термином SOD (Segregation of Duties).

Цель данной работы состоит применение методологии SOD в проектах внедрения корпоративных информационных систем, что обеспечит реализацию бизнес-процессов компании в ИТ-решении образом, исключающим/минимизирующим мошеннические действия со стороны работников. Достижение заявленной цели потребует решения следующих задач:

обзор элементов SOD;
рассмотрение типовых шагов SOD;
реализация SOD в бизнес-процессах и ERP-системах.

1. Определение, назначение и примеры SOD

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

Определение 1. Segregation of Duties (SOD) – процедура службы внутреннего контроля компании, нацеленная на предотвращение единоличного выполнения всех операций бизнес-процесса сотрудником, способное привести к ошибкам, искажению информации и мошенничеству [1]. Дословный перевод с английского «разграничение обязанностей».

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

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

2. Шаги имплементации SOD-контролей

Внедрение процедур SOD в регулярные процессы организации требуют выполнения указанных 5-ти шагов:

выявить критичные бизнес-процессы;
создать реестр SOD-рисков и SOD-матрицу;
присвоить роли и ответственных;
установить механизмы контроля;
вести регулярный аудит и мониторинг.

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

Построение реестра и матрицы SOD ведется следующим образом. Выбранные процессы декомпозируются на операции. Для всевозможных пар операций выявляются, анализируются и качественно оцениваются риски. Согласно [1], выделяют типовые операции, выполнение которых рекомендуется осуществлять согласно принципу распределения ответственности (табл. 1).

Табл. 1. Типовые бизнес-задачи, выполняемые различными сотрудниками

№	Область	Задача
1	Финансы	Создание и согласование финансовых документов должно вестись разными людьми, чтобы исключить необдуманные решения и дополнительные затраты.
2	Финансы	Лицо, создающее бухгалтерскую проводку, не должно участвовать в их сверке, что минимизирует искажение финансовой отчетности.
3	Сбыт	Создание заказов на продажу и их отгрузка выполняется отличными ответственными, что препятствует изменению заказов в случае задержки их исполнения.
4	Сбыт	Отгрузка товаров и проведение платежей осуществляется несколькими сотрудниками, что снижает риск нарушения правил кредитного лимитирования при отправке продукции клиенту.
5	Закупки	Регистрация заказов поставщику и оприходование товаров на склад реализуется разными работниками, что снижает затоваривание склада и дефицит продукции.
6	Кадры	Объявление вакансии, сбор резюме, проведение интервью и принятие решения о найме соискателя ведется несколькими HR-сотрудниками, что снижает риск найма неподходящего работника.
7	Кадры	Вовлечение в операции начисления зарплаты и ведения данных сотрудника различных работников исключает риск изменения учетных данных для оплаты необоснованной заработанной платы.

Пример идентифицированных и ранжированных SOD-рисков для пары бизнес-операций, доступных к выполнению заданному сотруднику, дан в табл. 2. Оценивание рисков необходимо для выбора из их множества лишь наиболее значимых и последующего их исключения и/или снижения.

Табл. 2. Фрагмент реестра SOD-рисков

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

Используя полученные результаты, строится SOD-матрица, в которой красным отмечаются ячейки с наибольшим рангом рисковой ситуации (рис .1).

Рис. 1. Пример SOD-матрицы

Построенная матрица SOD позволяет выявить области высокорисковых процессов, то есть определяет, какие пары бизнес-операций должны быть запрещены к одновременному выполнению тем или иным должностным ролям и сотрудникам. Запрет устанавливается следующим образом:

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

Бизнес и программные полномочия, выданные сотрудникам для осуществления регулярных процессов, подлежат систематическому мониторингу, для чего устанавливаются точки контроля. Последние представляют собой механизмы, позволяющие осуществлять проверку SOD-матрицы в режиме реального времени. Если SOD затрагивает активность, исполняемую вне ПО, одним из способов контроля следования процедуре разграничения обязанностей может служить заранее продуманная выборочная кросс-проверка твердых копий договоров, актов, накладных, листов ознакомления и др., с целью выявления нарушений. При использовании ИС для отражения бизнес-процессов компании, в ней заблаговременно разрабатываются специализированные программы, позволяющие отображать выданные пользователям роли и полномочия, а также проверять их соответствие SOD-матрице.

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

3. SOD в ERP-системах

Внедрение SOD-контролей для реализации бизнес-процессов в информационных системах ведется по классической каскадной модели имплементации [2], однако можно отметить и ряд специфичный моментов (табл. 3). На этапе анализа требований формируется реестр процессов, в разрезе операций 3-4 уровней декомпозиции которых собираются общие потребности. Построенная верхнеуровневая TO-BE модель будущего решения позволяет сформулировать лишь общие SOD-требования: состав ролевой модели и понимание средств контроля выданных ролей и полномочий [3].

Детальная работа над SOD ведется на фазе проектирования. В ходе детализации требований в разрезе бизнес-процессов ИС обсуждаются вопросы, связанные с SOD. Построенный по итогам обсуждения процессов реестр рисков позволяет сформировать SOD-матрицу. Последняя служит ключевым источником правды для реализации ролей и полномочий пользователей в разрабатываемой программной системе, оформленных в одноименных документах проектного решения и матрицы. Однако в отличие от SOD-матрицы указанные документы апеллируют не столько бизнес-операциями, сколько наименованиями технических ролей в ПО, позволяющих им выполнить [4].

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

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

проанализировать имеющийся функционал SOD для определения возможности его обновления и повторного использования с учетом актуальной SOD-матрицы;
провести неоднократный ретест бизнес-процессов в ПО для проверки работы актуализированных ролей и полномочий;
деактивировать устаревший функционал SOD в продуктивной системе.

Механизмы проверки SOD могут реализовываться как в составе внедряемого ПО, так и в отдельном программном решении, например, SAP GRC, контролирующим соблюдение принципов разграничения обязанностей прочих ИС.

Табл. 3. Активности по имплементации SOD в информационной системе

№	Этап проекта для реализации SOD	Опция 1. Инициатива по процедуре SOD, проводимая вместе с внедрением ПО	Опция 2. Инициатива по процедуре SOD, проводимая после внедрения ПО
1	Анализ требований	Выявление критичных бизнес-процессов; сбор требований к ролям и полномочиям в разрезе процессов; генерация требований к механизмам контроля ролей и полномочий;	Аналогично опции 1;
2	Проектирование	Подготовка реестра SOD-рисков и SOD-матрицы; проектирование ролей и полномочий с учетом матрицы SOD; дизайн средств контроля соблюдения принципов SOD;	Аналогично опции 1; анализ существующих ролей, полномочий, средств SOD-контроля и возможности их доработки/переиспользования в ПО;
3	Реализация	Разработка и настройка ролей и полномочий; реализация механизмов SOD-контроля;	Аналогично опции 1;
4	Тестирование	Испытание ролей и полномочий; проверка средств контроля SOD;	Аналогично опции 1;
5	Переход к промышленной эксплуатации	Перенос ролей и полномочий, а также средств контроля в продуктивную среду; обучение пользователей механизмам контроля SOD; присвоение ролей и полномочий ответственным пользователям.	Деактивация в ПО устаревших ролей, полномочий и средств контроля SOD; аналогично опции 1.

Полноценная работа SOD начинается с этапа поддержки продуктивной эксплуатации ПО в контексте пост-проекта внедрения (табл. 4).

Табл. 4. SOD-инициативы после их внедрения в ПО

№	Этап пост-проекта внедрения ПО	Активность по процедуре SOD
1	Поддержка продуктивной эксплуатации	Присвоение ролей ответственным пользователям на регулярной основе; непрерывный аудит и мониторинг SOD на основе разработанных механизмов контроля;
2	Развитие программного продукта	Усовершенствование SOD-подхода (запуск проекта по реализации SOD в объеме вносимых улучшений).

Заключение

Процедура SOD применима как для бизнес-процессов, реализуемых в программной системе, так и вне ее. Использование SOD предотвращает ошибки пользователей, минимизирует риски мошенничества и исключает конфликты интересов. Программная реализация SOD в ИС представляется настройкой ролей и полномочий для пользователей, а также разработкой средств, обеспечивающих контроль возникновения SOD-конфликтов. Типовой проект внедрения ERP-системы обычно подразумевает детальную работу над концепцией ролей и полномочий, а также матрицей ролей и полномочий, на базе которых в последствии конфигурируются технические роли в ПО [3-4]. Однако здесь допускаются две ключевые ошибки:

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

приводящие к тому, что разработанное ПО решает сугубо технические задачи, игнорируя потребности и риски бизнеса.

Внедрение механизмов Segregation of Duties не столько дань моды, сколько осознанная потребность текущего времени. Если раньше SOD ассоциировалась преимущественно с SOX-контролями, предназначенными для следования американскому закону Сарбейнза-Оксли (Sarbanes Oxley Act, SOX), то теперь в условиях повсеместной цифровизации, когда практически вся критически значимая информация хранится в программных системах, только реализация принципов SOD позволяет сохранять управляемость данными и их целостность [1]. Статистика показывает, что компания теряет около 5% от годовой выручки из-за мошеннических действий работников и, вероятнее всего, данная величина будет только увеличиваться.

Литература

HyperComply [Электронный ресурс] // What is segregation of duties and why is it important. Режим доступа: https://www.hypercomply.com/blog/segregation-of-duties (дата обращения 21.02.2026).
Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
Петров С.В. Стратегия ролей и полномочий в ERP-проектах // Корпоративные информационные системы. – 2018. – №3 (3) – с. 53-58. – URL: https://corpinfosys.ru/archive/issue-3/143-2018-3-authorizationstrategy.
Терентьев И.М. Реализация концепции ролей и полномочий в SAP ERP // Корпоративные информационные системы. – 2022. – №4 (20) – с. 25-30. – URL: https://corpinfosys.ru/archive/issue-20/207-2022-20-segregationofduties.

Выходные данные статьи

Степанов Д.Ю. SOD-контроли: определение, типовые шаги, реализация в бизнес-процессах и ERP-системах // Корпоративные информационные системы. – 2026. – №1 (33) – c. 1-7. – URL: https://corpinfosys.ru/archive/2026/issue-33/319-2026-33-sod.

Об авторе

Степанов Дмитрий Юрьевич – кандидат технических наук, доцент МИРЭА, принимал участие более чем в 10 проектах внедрения корпоративных информационных систем на базе SAP, Microsoft и Sage. Специализируется на управлении материальными потоками, сбытом и системой документов. Автор более 25 статей, в том числе публикации в журналах «Логистика сегодня», «Вопросы экономических наук», «САПер» и др. Электронный адрес автора: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Статьи выпуска №33

Реализация SOD-контролей в бизнес-процессах и ERP-системах.