Процессная модель банка: почему реестр схем перестал

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

Что именно изменилось в подходе ПСБ

В тексте ПСБ процессная модель описана как один из взглядов на организацию, а не как её единственно верное описание. Это важная развилка. Пока процессный контур живёт как реестр схем, им обычно пользуются для наведения порядка: нарисовали, согласовали, положили на полку. Но когда модель становится частью корпоративной архитектуры, она начинает работать как управленческий язык: через неё связывают стратегию, операционные цепочки и ИТ-опоры.

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

Что меняется	Почему важно бизнесу	Что проверить
От реестра блок-схем к архитектурному слою	Модель начинает влиять на решения, а не только хранить описание работы	Есть ли у модели место в управленческом цикле, а не только в репозитории
От «шагов процесса» к набору атрибутов: критичность, участники, ответственные, SLA, ИТ-связи	Видно, где сосредоточен риск и кто отвечает за сбой	Заполнены ли эти атрибуты по критичным процессам
От одной управленческой логики к нескольким	Снижается конфликт между функциями, продуктами и проектами	Есть ли механизм согласования противоречий между разными взглядами на организацию

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

Почему это меняет затраты, сроки и операционный риск

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

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

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

Положение Банка России № 850-П по операционной надёжности добавляет ещё один слой: технологические процессы должны быть увязаны с бизнес-процессами и с ИТ-инфраструктурой, на которую они опираются. И связи нужно регулярно проверять на актуальность. С управленческой точки зрения это уже не «документация для отчёта», а механизм, который помогает понять: если меняется система, где именно ломается цепочка выполнения работы и кто обязан это заметить первым.

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

Как собрать модель, которая работает, а не украшает отчётность

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

Начать с критичных сквозных процессов.
Не надо сразу описывать всё предприятие. В первую очередь берут то, что влияет на клиента, деньги, регуляторные обязательства и устойчивость.
Зафиксировать не только шаги, но и ответственность.
У процесса должен быть владелец, центры компетенций, участники и понятный результат. Без этого модель остаётся схемой без управленческого веса.
Прописать критичность и стыки.
Самые дорогие потери обычно происходят не внутри подразделения, а на передаче результата между ними. Поэтому в модели важны SLA на стыках и правила реакции на отклонение от целевой схемы.
Связать процесс с ИТ-опорой.
Если процесс завязан на конкретные системы, это нужно фиксировать явно. Тогда любая замена или сбой системы сразу виден в бизнес-контексте.
Регулярно проверять актуальность связей.
Это не разовая акция, а постоянная практика. Модель должна обновляться по мере изменения систем, оргструктуры и регуляторных требований.

Какие результаты даёт архитектурный подход к процессам

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

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

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

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

Источники

Положение Банка России от 08.04.2020 № 716-П «О требованиях к системе управления операционным риском в кредитной организации и банковской группе» — https://cbr.ru/Queries/UniDbQuery/File/90134/50
Положение Банка России от 03.08.2023 № 850-П «О требованиях к обеспечению операционной надёжности кредитных организаций» — https://cbr.ru/Queries/UniDbQuery/File/90134/52
Методические рекомендации Росимущества по организации процессного управления в компаниях с государственным участием — https://rosim.gov.ru/documents/776543

Генерация изображения

Модель: qwen-image-2.0
Провайдер: alibaba