"Когда правила пишут изолированно — каждое подразделение создаёт идеальный мир для своей задачи, — они неизбежно сталкиваются в реальности. Нарушение, это не всегда злой умысел. Чаще всего это единственный способ завершить работу, когда процессы взаимно блокируют друг друга. Проблема не в людях, а в системной ошибке проектирования контроля."
Почему политики компании создают конфликты
Разработка внутренних политик редко бывает централизованной. Финансовая служба минимизирует издержки, юристы снижают правовые риски, а отдел информационной безопасности защищает данные. Каждая группа действует в рамках своих KPI, не согласовывая требования с другими. В результате вместо единой системы управления рисками появляется набор автономных барьеров. Эти барьеры не интегрированы, что приводит к конфликтам при исполнении.
Простой пример: операционный регламент требует срочной поставки оборудования для критического проекта. Политика ИБ, в свою очередь, обязывает проводить трёхмесячную сертификацию любого нового оборудования. Менеджер по закупкам оказывается в ситуации, где любое решение нарушает правила: задержка проекта или игнорирование требований безопасности.
Конфликты усугубляются асинхронным обновлением документов. Законодательные изменения требуют быстрого внедрения, но внутренние шаблоны договоров, формы согласования и базы знаний обновляются с задержкой. Возникает промежуток времени, когда действовать по старым правилам нельзя, а новых инструкций ещё нет. Это вынуждает сотрудников принимать решения в условиях правового вакуума, что формирует риск неформальных согласований.
Наконец, стремление перестраховаться порождает избыточные требования. Например, для минимизации риска мошенничества финансовый контроль может ввести пятиэтапную проверку всех платежей, включая рутинные. Это резко замедляет все процессы. Правило не предусматривает исключений для низкорисковых операций. В результате сотрудники вынуждены тратить непропорционально много времени на стандартные задачи или искать обходные пути.
Выявление и формализация противоречий в правилах
Первое действие при обнаружении конфликта — его документирование в официальной системе, а не в личной переписке. Создайте обращение в системе управления инцидентами или тикет-системе с меткой «Конфликт внутренних политик». В описании укажите:
- Конкретные документы и их пункты (название, версия, раздел).
- Описание операционной задачи, которая не может быть выполнена.
- Конкретный пример пересечения требований.
Пример формулировки: «Политика закупок (версия 2.1, пункт 5.3) требует заключить договор в течение трёх рабочих дней после одобрения. Политика информационной безопасности (версия 3.0, пункт 4.7) запрещает подписывать договор с вендором до прохождения им полной проверки, срок которой — 10 рабочих дней. Без договора проверка не может быть начата формально».
Следующий шаг — перевод проблемы в язык бизнес-рисков с измеримыми последствиями. Это повышает приоритет решения. Пример: «Из-за блокировки формирования счёта в ERP (требуется статус «Проверено юристом», а юрист в отпуске) отгрузка товара клиенту задерживается. Потенциальные потери — 500 тысяч рублей в день из-за срыва контрактных сроков».
Используйте термины «операционный риск» и «несогласованность процедур». Это позволяет службе compliance воспринимать проблему как дефект системы контроля, а не как частную жалобу. Регулярная фиксация таких случаев формирует базу для системного редизайна политик.
Ловушка формальной ответственности сотрудника
Во многих регламентах присутствует формулировка: «Сотрудник обязан знать и соблюдать все действующие нормативные документы». Это создаёт юридическую ловушку, так как документы обновляются без явных уведомлений. Новая версия загружается в корпоративный портал, где фиксируется факт обновления. Рассылка, инструктаж или выделение изменений часто отсутствуют. При этом в случае инцидента сотрудник отвечает за незнание актуальной версии, хотя механизмов для её систематического отслеживания у него нет.
Электронные курсы и тесты по compliance часто служат не столько для обучения, сколько для создания доказательной базы. Факт прохождения теста фиксируется с метаданными: дата, результат, IP-адрес. Курс может не затрагивать сложные сценарии с коллизиями правил. После его прохождения система считает сотрудника «ознакомленным». В случае проблем аргумент «я не знал» становится недействительным, независимо от реальной сложности применения правил на практике.
Процедуры согласования с распределённой ответственностью создают видимость контроля. Каждый участник проверяет свой участок: юрист — формулировки, финансист — суммы, специалист ИБ — риски обработки данных. Никто не отвечает за целостность операции и совместимость требований друг с другом. Если операция окажется проблемной, найти ответственного невозможно — формально все этапы были пройдены. Это превращает процесс в ритуал, где каждый ставит подпись, не неся реальной ответственности за конечный результат.
Действия при требовании руководителя нарушить регламент
Устное распоряжение «сделай сейчас, оформим позже» — один из самых рискованных сценариев. Автоматизированные системы учёта фиксируют каждое действие. Если договор создан до получения финансового одобрения, система зафиксирует нарушение. При последующем аудите в журнале будет подпись о соблюдении всех процедур. Возникает двойная ловушка: реальное нарушение и формальное подтверждение его отсутствия. Сотрудник остаётся единственным, чьи действия имеют цифровой след.
Минимизация рисков начинается с переноса устного распоряжения в письменный канал. Отправьте сообщение в корпоративном мессенджере или по электронной почте: «Для выполнения задачи по заключению договора с компанией «Х» до 14:00 требуется отступление от пункта 3.2 Политики закупок, так как финансовое согласование отсутствует. Подтвердите, пожалуйста, принятие решения об отклонении от регламента». Это не отказ, а документирование. Руководитель либо примет ответственность, либо пересмотрит задачу.
В зрелой системе должна существовать легальная процедура для временного отклонения от политики. Она не требует длительных согласований. Например, форма «Заявка на исключение» с обязательными полями: причина, бизнес-обоснование, срок действия, ответственный руководитель. Такая заявка рассматривается службой compliance в сжатые сроки и становится юридическим основанием для действий, а не поводом для последующих санкций.
Проактивное обновление политик: от реактивного к адаптивному контролю
Система внутреннего контроля остаётся эффективной только при наличии постоянной обратной связи от бизнес-процессов. Внедрите в отчётность по завершению проектов обязательный вопрос: «Какие пункты регламентов создавали затруднения при выполнении задач?» Ответы должны собираться и анализироваться на предмет выявления паттернов. Например, если большинство задержек происходит на этапе проверки ИБ из-за необходимости неформальных уточнений, это сигнал к пересмотру процедуры, а не к дисциплинарным мерам.
Создайте открытый для сотрудников «Реестр конфликтов политик». Это может быть форма в корпоративной системе или таблица с доступом на добавление записей. Каждая запись содержит:
- Краткое описание конфликта.
- Ссылки на противоречащие документы.
- Пример бизнес-ситуации.
- Предлагаемое решение.
Еженедельная рабочая группа из представителей compliance, юридического отдела и ключевых бизнес-подразделений проводит ревью этого реестра. Большинство конфликтов можно разрешить незначительными правками, часть потребует пересмотра политик, а некоторые — внедрения новых инструментов.
Ключевые политики не должны пересматриваться исключительно по календарному графику. Внедрите триггерные пересмотры, инициируемые бизнес-событиями. Например:
- Политика по работе с контрагентами автоматически выносится на обсуждение после входа компании на новый региональный рынок.
- Политика по удалённому доступу пересматривается после инцидента с утечкой данных через неподконтрольное устройство.
Это позволяет обновлять правила до того, как они станут препятствием, а не после возникновения кризиса.
Превращение compliance в инструмент для бизнеса
Требуйте от разработчиков политик создания «чек-листов исполнителя» — одностраничных схем для типовых операций. Например, чек-лист для запуска нового IT-сервиса:
- Заполнить форму заявки в службу поддержки.
- Приложить описание функционала и диаграмму потоков данных.
- Получить предварительную оценку рисков от ИБ.
- Согласовать бюджет с финансовым отделом.
- Зарегистрировать сервис в корпоративном реестре.
Такой чек-лист не заменяет политику, но делает её применимой на практике, снижая количество ошибок и ускоряя обучение.
Лоббируйте внедрение адаптивных маршрутов согласования. Вместо жёсткой последовательности «руководитель → финансовый директор → юрист» используйте логику, основанную на параметрах заявки. Маршрут строится динамически.
| Условие в заявке | Проверка | Добавляемый согласующий |
|---|---|---|
| Сумма сделки превышает лимит | Да | Финансовый директор |
| Задействованы персональные данные | Да | Ответственный за ИБ / compliance |
| Контрагент из юрисдикции повышенного риска | Да | Юридический отдел |
| Ни одно из условий не выполнено | — | Только непосредственный руководитель |
Это исключает лишние этапы согласования для стандартных операций, сокращая время и нагрузку на руководителей.
Инициируйте создание рабочей группы по операционным исключениям — комитета из представителей бизнеса и контроля. Его задача — оперативно (в течение одного дня) рассматривать случаи, когда работа блокируется устаревшими или конфликтующими правилами. Решения группы документируются и становятся прецедентами. Если одна и та же коллизия возникает регулярно, это основание для изменения регламента. Такой подход делает систему контроля гибкой и показывает её способность адаптироваться к реальным потребностям бизнеса.