Привет!

Я Саша Гордеева, руковожу процессным офисом в ПСБ.

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

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

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

Регуляторная база как драйвер процессной модели

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

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

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

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

Процессный взгляд как один из управленческих подходов

Корпоративная архитектура демонстрирует, что крупная организация никогда не живёт в одном единственном управленческом подходе. В реальности одновременно сосуществуют несколько логик – функциональная, процессная, продуктовая, проектная, риск-подход, финансовый подход и так далее. И каждая из них по-своему “права”, но по-своему же создаёт ограничения.

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

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

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

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

Все эти подходы, а также и некоторые другие, одновременно работают в банке. Процессный взгляд является одним из разрезов анализа деятельности в организации (view), а не «интегратором всего». Мы осознаем место процессов в общей архитектуре и выстраиваем синхронизацию с другими существующими подходами в рамках всей работы банка.

Роли архитектурных сущностей в банке

В архитектуре банка мы сознательно используем несколько разных «языков описания деятельности»: функции, процессы, сервисы, продукты, бизнес‑способности. Каждый из них фокусируется на своём срезе — от распределения ответственности до клиентской ценности и устойчивых сильных сторон организации.

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

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

Как мы оценивали зрелость процессного управления в ПСБ

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

Чтобы зафиксировать стартовую точку, мы провели оценку с привлечением ключевых подразделений – владельцев и участников процессов. Мы оценивали зрелость процессного управления как управленческой практики, а не просто объёмы описанных или регламентированных процессов. 

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

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

Методика оценки зрелости процессного управления

При подготовке к оценке зрелости мы опирались на несколько источников. В качестве рамки уровней зрелости мы использовали пятиуровневую логику CMMI и аналитический подходы (в том числе Gartner), адаптировав формулировки под контур процессного управления в банке. Для описания измерений зрелости и критериев мы брали идеи из TOGAF и BIAN – прежде всего в части увязки процессов с другими слоями архитектуры, – а также из стандартов ISO / ГОСТ по управлению качеством и операционными рисками. Отечественные работы В.В.Репина, Р.А.Исаева, А.К.Коптелова помогли приземлить эти модели на российскую практику: мы использовали их в формулировке управленческих аспектов, структуры опросников и интерпретации уровней зрелости.

Методика включает 259 критериев, сгруппированных по 8 направлениям оценки: архитектура процессов; установка стратегических целей Банка; система стимулирования руководителей на улучшение процессов через КПЭ; практика описания и анализа процессов; практика оптимизации процессов и внедрения изменений; стандартизация процессов; контроль и аудит; корпоративная система обучения персонала методам процессного управления.

На низких уровнях зрелости (оценка 1–2) процессы либо слабо формализованы, либо описаны фрагментарно, процессная модель не используется в управлении и редко обновляется. Средний уровень (3) означает, что ключевые процессы описаны, но связь с управленческими решениями и показателями остаётся точечной. Высокие уровни зрелости (оценка 4–5) мы фиксировали там, где процессная модель встроена в регулярное управление: у процессов есть назначенные владельцы, описания актуализируются, показатели встроены в систему КПЭ, а модели реально используются при планировании изменений и работе с рисками.

В результате в методике появились несколько измерений зрелости: 

• отражённость ключевых областей деятельности в процессной модели;

• качество и актуальность описаний;

• наличие владельцев процессов и регламентов управления;

• связь процессов с KPI и рисками;

• интеграция процессной модели с ИТ-архитектурой;

• роль модели в управленческих и архитектурных решениях.

Для каждого измерения мы определили шкалу уровней зрелости от 1 до 5 с описанием того, как выглядит практика на каждом уровне – от фрагментарных, слабо используемых описаний до встроенной в управление модели, поддержанной метриками, ВНД и архитектурными связями.

Фактически методика представляет собой матрицу «измерение зрелости × уровень», где для каждого аспекта (процессная модель, владельцы, KPI, риски, ИТ-связи, использование в управлении) описано, как выглядит практика на уровнях 1–5. Это позволяет и провести разовую диагностику, и использовать эту матрицу как опорную рамку при обсуждении развития процессного управления.

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

В представленном примере четыре направления диагностики преодолели третий уровень зрелости, что может указывать на наличие базовой процессной архитектуры: процессы в значительной мере задокументированы, стандартизированы и интегрированы с другими бизнес-процессами как входящая информация для последующих шагов. Установлен ряд отклонений (отступлений от третьего уровня зрелости в диапазоне +/-0,5 пунктов), что свидетельствует о неравномерном развитии практики даже внутри относительно зрелых направлений.

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

От реестра процессов к архитектурному взгляду

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

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

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

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

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

Если смотреть на банк через архитектурную призму, удобно разделять, как минимум, два крупных слоя: бизнес-уровень и уровень и уровень ИТ-архитектуры. 

На бизнес-уровне мы работаем с такими сущностями, как цели, бизнес-способности, продукты, бизнес-процессы, роли и сервисы. На ИТ-уровне – с информационными системами, системными сервисами, данными и инфраструктурой.

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

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

Бизнес-процессы в корпоративной архитектуре банка

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

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

Заключение 

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

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