Бесконечные согласования ради галочки могут испортить любой процесс. Когда юристы получают требования, которые их не касаются, бизнес-аналитики ходят по кругу с вопросами вроде «Я меняю процесс сбора согласия, с кем мне это утвердить?», а новые сотрудники теряются в ролях — всё это негативно влияет хоть на аналитику, хоть на продакшн.

Нам и нашему банку нужно, чтобы все внутренние процессы были отлажены практически до идеала. Указанные выше «согласования, которые есть, чтобы быть» такому часовому механизму не подходят.

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

Для начала введём в курс дела

Мы бизнес-аналитики в ИТ-подразделении Газпромбанка, где каждый процесс проходит под строгим надзором регуляторов. Наша работа — оптимизировать процессы, автоматизировать рутину (например, заменить ручной ввод данных сканированием паспортов) и внедрять новые функции. Банк — это сложная экосистема со множеством ролей, взаимосвязанных процессов, рисков и внешних ограничений. Любое изменение требует тщательной проработки, чтобы соответствовать стандартам и не создавать бреши с точки зрения безопасности.

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

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

Проблема: согласования ради согласований

Главная наша головная боль — культура перестраховки. Философия «Мы всегда так делали» приводила к тому, что бизнес-аналитики отправляли требования на согласование всем подряд — юристам, безопасности, комплаенс — и обо всём подряд, даже когда это не требовалось от слова «совсем».     Например, изменение визуального отображения формы или автоматизация ручных процессов в работе мидл-офиса отправляли в юридическую службу (sic!).

В итоге:

• Экспертные подразделения тратили ресурсы на нерелевантные задачи.

• Время выпуска фич увеличивалось из-за ожидания ненужных «Да-да, посмотрели».

• Не было чётких критериев, что согласовывать, а что — нет.

• Кто-то настаивал на согласовании «на всякий случай», другие отвечали: «Не нужно вовлекать в это всех».

• Без единого понимания ролей и артефактов процесс буксовал, а time-to-market рос.

Поиск решения: как навести порядок

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

Наш подход строился на двух решениях:

1. Чек-листы

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

Чек-листы разместили на внутренней вики (Confluence) в разделе лиги бизнес-аналитиков, разделив по блокам: 1) розничный, 2) малый и средний бизнес, 3) крупный и крупнейший бизнес.

2. Автоматизация

Чтобы упростить работу всем (и, в частности, новеньким) бизнес-аналитикам, мы создали интерактивную форму в Excel. Бизнес-аналитик отмечает, что меняется в процессе (например, «Задействован клиент» или «Изменяется технология»), и форма выдаёт список нужных согласующих. Это экономит время и снижает риск ошибок. Форма покажет, кто из экспертов нужен и какой с ним формат взаимодействия (JIRA или внутренняя система согласования), а ещё результат можно выгрузить в Word для отчёта.

Но оставалась проблема тиражирования: нам нужно было убедить всех, что всё вышеназванное — не наша фантазия, а согласованный и надёжный стандарт.

Что мы сделали: чек-лист и плейбук в деталях

Чек-листы

Чек-листы сфокусированы на формировании логических связей, например:

• Меняется ли тип подписи? — Идём к юристам.

• Задействован ли клиент? — Согласовываем с комплаенс.

• Изменяется ли технология обработки данных? — Запрашиваем мнение службы безопасности.

Каждое из семи подразделений определило свои критерии, чтобы исключить ненужные согласования. Чек-листы размещены на внутренней вики (Confluence), где любой бизнес-аналитик может их открыть и проверить. По мере повышения зрелости процессов чек-листы упрощаются. Например, после повсеместного внедрения простой электронной подписи (ПЭП) согласование её тиражирования на новые продукты стало ненужным: технология уже проверена.

Плейбук

Чтобы закрепить тиражирование и сделать процесс прозрачным, мы создали плейбук — универсальный справочник в формате карточек. Каждая карточка описывает:

Роль: кто и за что отвечает (например, бизнес-аналитик, владелец продукта, юрист и соответствующие им процессы).

Обязанности: что делает эта роль на каждом этапе.

Чек-лист: критерии согласования для этой роли.

Плейбук построен по этапам изменения процессов: discovery (формирование концепции) и delivery (реализация). Он включает в себя восемь ролей, среди которых:

• Владелец продукта.

• Владелец канала (например, фронт-офис или «Газпромбанк Бизнес-Онлайн»).

• Бизнес-аналитик.

• ИТ-инженер (включая разработчиков, системных аналитиков, DevOps).

• Эксперты: юристы, безопасники, онбординг, технолог операционного блока и пр.

Также в плейбуке описано 10 артефактов, создаваемых на разных этапах. Примеры:

Бизнес-требования: документ с описанием задачи.

BPMN-схемы: визуализация процесса.

Отчёт по пользовательскому тестированию (UT): обратная связь от бета-клиентов по новой фиче, чтобы мы доработали её перед массовым запуском.

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

Внедрение

Чек-листы: разработка заняла две недели. Мы собрали данные по согласованиям за полгода, выделили самые частые сценарии и обсудили критерии с каждым из семи подразделений. Эксперты были заинтересованы, так как сами тратили время на ненужные согласования.

Excel-форма: создание и тестирование заняло около месяца. Форма до сих пор дорабатывается, чтобы учитывать новые процессы и изменения в JIRA.

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

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

Всё размещено на вики, а яркий визуальный формат (карточки вместо скучных Word-доков) неплохо повышает вовлечённость.

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

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

• Живые кейсы: показывали экспертам, как они тратят время на неважные согласования. Например, юридической службе не нужно проверять переименование поля с «Дата выдачи» на «Дата выдачи паспорта».

• Аналитику: ретроданные за полгода подтвердили, что многие согласования были избыточными.

• Плейбук как артефакт тиражирования: эксперты сами согласовали свои роли и чек-листы, что сняло вопросы о правильности подхода.

• Эскалацию: поддержка руководства помогла преодолеть сопротивление типа «Мы сами знаем, как работать». Когда сверху сказали: «Это классная идея!» — у скептиков не осталось выбора, кроме как подключиться.

Мы старательно уходили от абстрактного «Надо согласовать» к конкретному «Если меняешь подпись — иди к юристам, если меняешь интерфейс — достаточно инструкции».

Результаты и метрики

Точные цифры мы ещё уточняем, но уже заметны:

• Снижение итераций: меньше клонирующих друг друга согласований.

• Ускорение time-to-market: новые фичи выходят на рынок быстрее, так как мы экономим не часы — десятки часов.

• Экономия человеко-часов: эксперты тратят время только на релевантные задачи.

• Рост зрелости и автоматизация ряда процессов.

Что ещё важно знать перед внедрением

1. Что делать, если чек-лист не покрывает кейса?

Плейбук описывает маршрут запроса консультации, например, поставить задачу в JIRA конкретному эксперту или связаться с контактным лицом подразделения. Это быстрее, чем назначать встречу.

2. Чем отличается чек-лист от плейбука?

Чек-лист — критерии согласования («Что делать»). Плейбук — справочник с ролями, этапами и артефактами («Как, когда и с кем»).

3. Как поддерживать актуальность?

Плейбук описывает маршрут: поставить задачу в JIRA конкретному эксперту или связаться с контактным лицом. Например, для юриста есть выделенный контакт, который отвечает в приоритетном порядке. Плюс к этому — связка матрицы RACI (Responsible, Accountable, Consulted, Informed), которая у нас уже давно существует в методологии производственного процесса ИТ, и наших чек-листов бизнес-аналитиков. В RACI мы убрали упоминание конкретных департаментов и ввели понятие «Заинтересованные стороны». Чек-листы и плейбук уточняют, кто эти стороны и когда их вовлекать, что делает процесс гибким к изменениям.

Мораль

Мы не отменили согласований — мы убрали согласования ради согласований. Чек-листы и плейбук дали команде чёткие правила взаимодействия, сократили время на выпуск продуктов и разгрузили экспертов. Теперь мы работаем быстрее, а главное — эффективнее.