Описание проблемы
Я столкнулся со следующими проблемами при анализе существовавшего процесса:
• 80% задач поступает ad hoc
• приоритеты задач постоянно меняются
• нет возможности осуществлять планирование работ
• отсутствует гармоничность в развитии систем
• нет «установленных правил игры» при реализации изменений
Как внутренний эффект – эмоциональное выгорание персонала, падение производительности труда, отсутствие эффекта новаторства.
Основная цель Банка – максимально быстро и качественно выводить новые продукты на рынок. Почему этого не происходило? Я покажу три самых распространенных сценария. Уверен их можно встретить и в других финансовых организациях.
Для наглядности будем запускать новый кредитный продукт – Кредитная карта. Заказчиком будет выступать розничный бизнес, основной исполнитель – внешний подрядчик (будем использовать модель аутсорсинга, которая распространена в ряде организаций), внутреннее ИТ выполняет сервисную функцию. И самое главное: все ситуации будут вымышленные, а совпадения случайны.
Заказчик начинает реализацию проекта, проводит встречи с Исполнителем. Результат формирование паспорта проекта на реализацию продукта.
В паспорт попадают все требования и процессы, которые описывает наш Заказчик, основываюсь на процессе продажи:
• Поля анкеты клиента;
• Требования к фронт системе (продажа, верификация);
• Ролевая модель;
• Требования к интеграции с системами;
• Драфт процесса продажи.
И тут мы приходим к первой ошибке: после утверждения концепта и старта работ оказываются непроработанными (или неучтенными): участие фин. мониторинга в процессе идентификации продукта (черные списки, списки террористов и т.д).
Потребуется доработка процесса продажи, изменение форм, добавление интеграций, новых ролей. Как следствие: изменение сроков и бюджета проекта. Как часто бывает — одно подразделение не может знать всех процессов других подразделений.
Наш Заказчик проводит встречи со всеми бизнес подразделениями, процесс становится максимально проработанным, но отсутствует архитектурное описание реализации функционала в бизнес системах. Заказчик описывает представление продуктового каталога, исполнитель реализовывает продуктовый каталог в своей системе (то есть в системе, которую он знает). В процессе пилота оказывается, что часть параметров должны быть настроены в АБС (основной учетной системе Банка), в противном случае будет отсутствовать возможность корректного начисления процентов.
Что имеем – дополнительные расходы на синхронизацию систем (параметров кредитного продукта) или трудозатраты перенос ведения продуктового каталога в АБС. В первом случае увеличиваются операционные расходы на сопровождение продукта, во втором увеличение сроков и бюджета проекта.
Третий возможный случай – параллельные изменения в основных системах, инициированные другими подразделениями или изменений требований законодательства. Самый простой пример, добавление или изменение полей анкеты клиента, изменение их обязательности.
Поиск решения
Наша задача была выстроить эффективный процесс внедрения, для этого необходимо было вовлечь все бизнес подразделения в процесс управления изменениями, а также снизить конфликты за ресурс ИТ. Для этого мы стали смотреть в сторону гибких методологий, чтобы использовать их артефакты в улучшении внутренних процессов.
Первое – мы стали смотреть как происходит внедрение в аналогичных организациях. Но многие крупные организации внедряют гибкие процессы лишь формально – приходит руководитель к ИТ отделу и говорит: «Так, с сегодняшнего дня начальник отдела становится скрам мастером, проводим стендапы и рисует спринты». Данное изменение в корне ничего не меняет, кроме названий (руководители проводят краткосрочное планирование, совещания с подчиненными и т.д.). Иногда к обсуждению команды ИТ приглашают одного человека из бизнеса, но обсуждения на таких встречах носит сугубо технический характер, поэтому профита от этого не получается.
Мы предложили совсем другую модель, объединиться вокруг продуктов, включив в команду представителей от всех подразделений участвующих в процессах, связанных с данных продуктов(как продажа, так и обслуживание). Второе значимое нововведение – жизненный цикл банковского продукта начинается от лида и заканчивается в момент закрытия или перепродажи сделки.
Этап 1 – Фиксация идеи, Подготовка CR, Предварительная оценка.
Любой участник команды описывает реализуемое изменение для предварительного анализа, используя для этого формат user-story, которое в итоге попадает в беклог бизнес-аналитика. Бизнес аналитик организовывает еженедельные встречи, где изменения обсуждаются с участием владельца продукта, аналитиков и других бизнес подразделений, участвующих в процессе. После этого этапа изменения попадают в беклог продукта.
Этап 2 – Установка приоритетов и планирование реализации
Планирование задач заключается в определении перечня задач из беклога, которые будут включены в ближайший спринт. За приоритезацию задач отвечает непосредственно владелец продукта, он же несет ответственность за экономическую целесообразность работ и качество реализованного продукта. Команда добивается успеха или совершает ошибки как единое целое.
Этап 3 – Разработка, тестирование, релиз.
Владелец продукта получает результат каждого спринта на тестирование и может влиять на дальнейший ход, например, корректировать перечень дальнейших работ. Все изменения продукта объединяются в релизы, которые состоят из нескольких спринтов длительностью 2-4 недели.
Заключение
Как завершение статьи, приведу пример команды из розничного бизнеса, за которой может быть закреплен наш вымышленный продукт — Кредитная карта:
Управление кредитных карт и эквайринга (Владелец продукта)
• Управление финансового мониторинга
• Управление контроля финансовых и операционных рисков
• Управление сопровождения банковских операций
• Управление информационных технологий
• Управление платежных систем
Комментарии (11)
alek_sys
14.09.2017 11:59Спасибо за статью, хороший анализ процессов, но все же остается несколько неоднозначное впечатление… Даже сам очень формальный и "казенный" язык (простите, если это сделано намеренно) как-то не вяжется с "гибким" подходом и people over processes. Agile это же не про спринты и команду, сидящую вместе, это просто один из компонентов. Agile это изменение в ментальности и процессах вообще. И главное это уход от мысли "Мы точно знаем, какой продукт должен быть на выходе".
Гибкий процесс как раз уходит от этого постулата и взамен говорит "Давайте работать гибко и реагировать на потребности пользователей", а например ни один из ваших процессов не вовлекает… конечных пользователей.
Многие большие компании и банки пытаются внедрить скорее wagile (waterfall + agile), т.е. утвердить scope, требования и иногда даже сроки заранее, а внутри просто разбить разработку на спринты, упуская важный момент, что цель спринта (вообще итерации) и частой доставки продукта это получить обратную связь от пользователей и понять, а то ли мы вообще делаем? Если разработка идет спринтами, но поставка для конечных пользователей делается через два года разработки, то есть ли вообще ценность в спринтах?
Я крайне рекомендую книгу The Lean Startup, Эрик Рейс там много рассуждает, как agile и lean подходы могут работать в больших предприятиях.
Balynsky Автор
14.09.2017 12:12Спасибо за комментарий. Полностью согласен с Вашим мнением, что в процесс напрямую не вовлечены конечные пользователи, именно поэтому я очень аккуратно говорил о том, что используются элементы гибких методологий, а не полностью переход на Agile (фактически применение управленческих практик для организация процесса).
Вовлечение конечных пользователей в этом случае проходит исключительно Пользователь -> Точка обслуживания -> Владелец продукта. И Владелец продукта всегда выступает своеобразным фильтром с видением «Мы точно знаем, какой продукт должен быть на выходе», но это уже совсем другая проблема.
Гораздо большее зло — концентрация на организационной структуре организации, а не на конечном продукте. Именно с этой проблемы мы и начали.
P.S. За рекомендацию спасибо, я обязательно возьму книгу к прочтению.
nikolayv81
15.09.2017 22:29|цель спринта (вообще итерации) и частой доставки продукта это получить обратную связь от пользователей и понять, а то ли мы вообще делаем?
Всё же пользователи в оригинале (по Сазерленду) это, вроде как, не клиенты банка а "клиенты команды"?
Банк не может выдать финансовый продукт клиенту в сыром виде, это может обойтись слишком дорого.
Electrohedgehog
14.09.2017 12:15Ваша статья малоинформативна, запутана и явно предназначена не для этого сайта. Одно написание слова «банк» с заглавной буквы достойно минуса.
Balynsky Автор
14.09.2017 12:23Спасибо за высказанное мнение. В этой статье слово Банк — имя собственное, а не нарицательное. Назовем это орфографической привычкой :)
santal
15.09.2017 11:49+1Это у всех банковских так :). Все происходит от того, что во всех документах пишется что-нибудь типа: ООО «Тырыпырыбанк» (далее «Банк»).
sshmakov
15.09.2017 11:06Мы предложили совсем другую модель, объединиться вокруг продуктов, включив в команду представителей от всех подразделений участвующих в процессах, связанных с данных продуктов(как продажа, так и обслуживание). Второе значимое нововведение – жизненный цикл банковского продукта начинается от лида и заканчивается в момент закрытия или перепродажи сделки.
Команда продолжает существовать, пока продукт продается и обслуживается?
Любой участник команды описывает реализуемое изменение для предварительного анализа, используя для этого формат user-story, которое в итоге попадает в беклог бизнес-аналитика.
В результате к пром у вас описание продукта состоит из собранных user-story и бэклога?
Владелец продукта получает результат каждого спринта на тестирование и может влиять на дальнейший ход
Можете поделиться статистикой, сколько обычно времени занимает реализация нового продукта от идеи до установки в пром. эксплуатацию? Подозреваю, что сложные продукты владелец замучается тестировать на начальных этапах.Balynsky Автор
15.09.2017 12:27Команда продолжает существовать, пока продукт продается и обслуживается?
Без этого терялся бы смысл данных изменений. Более того, команда отмечается и за продажу и за обслуживание продукта. То есть весь воркфлоу пока продукт или не будет закрыт или перепродан.
В результате к пром у вас описание продукта состоит из собранных user-story и бэклога?
Да, именно так в трекере и выглядит.
Можете поделиться статистикой, сколько обычно времени занимает реализация нового продукта от идеи до установки в пром. эксплуатацию? Подозреваю, что сложные продукты владелец замучается тестировать на начальных этапах.
Из практики — если строится абсолютно новый продукт с разработкой новых процессов в сопровождающих подразделениях, то минимум 6-9 месяцев (с учетом обучения персонала и пилотов).
Если мы говорим о похожих продуктах (Например, кредит наличными есть, а нужно добавить кредитную карту), то такие процессы можно выводить до 2-3 месяцев (присутствует больше организационных задач и бюрократических процедур, так как сама разработка уже будет минимальна).
pnetmon
Неа...
santal
А за что человеку минус влепили?
Он прав. Основная цель любой коммерческой организации это получение прибыли. Каким именно образом получается прибыль: обналичка, химия с облигациями/векселями/гарантиями или действительно — с помощью максимально быстрого и качественного выведения новых продуктов это уже вопрос к руководству. Но я честно говоря по последнему способу не очень много банков наблюдаю. Эльвира Сапхизадовна судя по всему — тоже :)
Balynsky Автор
Абсолютно верно.
А цель, которую ставили в Банке — это как раз модернизация (процессов, систем и т.д.) для ускорения вывода продуктов(или их изменения под потребности рынка) и повышения их качества. Это навеяно в частности появившимися финтех стартапами и недостаточной «поворотливостью» банков с другой стороны.