Меньше мнений — больше цифр: как управлять без иллюзий и чем может помочь BPMS. Часть 2 Метрика «чистых» заявок: управляем скоростью через возвраты После обновления процесса к базовым добавился еще один важный показатель — доля «чистых» заявок (без единого возврата). Логика простая: возвраты и есть главный убийца скорости. Мы отдельно посчитали время прохождения «чистой» заявки — около 30 минут — и начали управлять динамикой этой доли. За полгода доля «чистых» заявок выросла с 0,01 до 70%, и стало напрямую видно, как снижение возвратов ускоряет весь поток. Отдельный инсайт: сила прозрачных данных — в управлении поведением сотрудников. Любая система управления (agile, холакратия, BPMS) работает лучше всего, когда «быть плохим» становится публично неудобно. В agile это видно на коротких спринтах и дейли: если нет результата, это сразу очевидно команде. С BPMS было так же: на митингах вместо абстрактного «где моя заявка?» мы выводили историю заявки на экран и быстро приходили к конкретике — регион, офис, сотрудник, где именно «рождаются» возвраты. Когда возвраты стали видны в разрезе людей, обнаружилась огромная разница в качестве: при одной и той же системе у одних заявки проходят за минуты, у других — тянутся неделями из‑за ошибок и возвратов. В итоге мы точечно «дожимали» конкретные причины и конкретные команды/офисы, потому что слабое место почти всегда — человеческий фактор. В терминах ТРИЗ идеал — процесс, который выполняет функцию без лишних элементов: чем меньше ручного участия, тем стабильнее качество и скорость. Если ставить цель «открывать счет за 30 минут», люди улучшают текущую схему. Если сформулировать как «без людей и моментально», появляются другие решения — ответ уже спрятан в вопросе. Но практика все равно упирается в человеческий фактор. Мы завели борд «лучшие/худшие» и на встречах прямо созванивались с участниками, чтобы понять, где ломается поток. Типичный паттерн: если у продажника не получается, формально виноват он, но в голове виноваты система и «айтишники». Нужна Poka-Yoke — «защита от ошибок», учитывающая реальное поведение пользователей. Это помогло выровнять работу всех участников: в рамках BPMS процесс стал прозрачным, лишних вопросов стало меньше. Дальше — управленческий цикл: раз в 3 недели — общий митинг автоматизаторов и исполнителей, с заранее согласованными целевыми и локальными метриками, анализом проблем и предложениями. Тогда это разговор по цифрам, который приводит к улучшениям по всему процессу. Кто масштабирует изменения: «инновации сверху» или ценность снизу В какой-то момент встает вопрос: почему идти именно в данные и кто двигает изменения — «верх» или «низ»? Часто в компаниях старой школы топ-менеджер создает «отдел инноваций», сам не разбираясь в технологиях. Для продуктовых команд такой отдел не авторитет: он приходит «продавать» инициативы, а в ответ получает сопротивление — выглядит как лишний workflow без понятной пользы. Инсайт в том, что «инновациям сверху» нельзя ходить по подразделениям и уговаривать. У них нет веса, пока нет доказанной ценности. Рабочая схема другая: ценность должен «продавать» тот, кому реально помогли. Я прихожу с цифрами и показываю, как инструменты улучшили метрики процесса, — и уже я рекомендую этот отдел и его решения. Тогда история масштабируется естественно: не команда инноваций доказывает, что она нужна, а внутренний клиент говорит: «Было так, стало так, вот кто помог». То же самое работает для акционеров и топ-руководства: им нужны конкретные результаты, а не обещания. Когда мы внедряли BPMS, я пришел к председателю правления с измеримыми эффектами на живых клиентах и реальных процессах. После этого стало очевидно, что систему стоит масштабировать внутри банка.