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

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

Именно поэтому в настоящее время все больше внимания уделяется новым технологиям управления, позволяющим обеспечивать необходимые скорости изменения продуктов, технологий и компаний в целом. Многие организации сейчас занимаются внедрением и развитием технологий управления, получивших название «гибких» — таких как Agile, Scrum, Kanban, Lean.

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

Результаты опроса были ожидаемыми

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

Представим ситуацию. В какой-то понедельник руководство вашей организации объявляет: «С сегодняшнего дня мы — „бирюзовая“ организация и будем жить по-новому!» И как теперь будет выглядеть ваш понедельник? А другие дни недели? Скорее всего, они будут такими же, какими были и до этого, так как от одних слов вряд ли что-то изменится в вашей работе.

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

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

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

Недавно проведенный нами опрос содержал всего два вопроса: «Что Вы делаете, когда у вас возникают трудности в понимании процесса?» и «Как можно улучшить регламенты процессов?».

Результаты опроса были ожидаемыми. Большинство сотрудников банка (44%) при возникновении трудностей обращаются к коллегам или руководителю, а значит, отвлекают их от их работы. Лишь 29% сотрудников обращаются к регламентам процессов. При ответе на вопрос, как улучшить регламенты, мнения разошлись, но в целом можно сделать вывод, что имеющаяся версия документов требует изменений. Наглядно результаты опроса приведены на рис. 1.

Рис. 1. Результаты опроса сотрудников

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

Создание иерархии процессов

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

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

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

Рис. 2. Иерархия бизнес-процессов

Моделирование процессов производим в системе Business Studio, поэтому практический пример рассмотрим на ее основе (рис. 3).

Рис. 3. Пример иерархии процесса

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

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

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

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

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

А с кем теперь нужно согласовать изменения в действиях одной функциональной роли в рамках выполнения одного этапа сквозного бизнес-процесса? Если вносимые изменения не меняют выход этапа, т. е. меняется работа лишь внутри этапа, то согласовывать данные изменения нужно только с владельцем этого этапа. Если же изменения затронут выход из этапа, то требуется согласование с владельцем следующего этапа (для него меняется вход!) и владельцем сквозного процесса. Согласитесь, согласование с владельцем одного этапа проще, чем с владельцами всех этапов сквозного процесса (а их может быть и 15, и 20, и при этом для них вносимые изменения не имеют никакого значения).

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

Давайте рассмотрим, как на практике происходит моделирование процесса с учетом изложенной методологии.

Моделирование процесса

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

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

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

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

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

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

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

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

Иерархия внутренних нормативных документов

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

Для ответов на эти вопросы мы разработали иерархию внутренних нормативных документов, соответствующую иерархии процессов. Суть заключается в том, что каждый уровень иерархии процессов описывается соответствующим нормативным документом. Конечно, можно написать политику кредитования, которая будет включать в себя все: от принципов кредитования (возвратность, срочность, платность) до действий конкретного кассира при выдаче кредита наличными. И зачастую методологи, которые разрабатывают нормативную документацию, именно к этому и стремятся, аргументируя тем, что «будет один документ, в котором все описано», «не стоит плодить лишние документы» и т. д.

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

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

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

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

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

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

Рис. 4. Пример регламентации процесса ипотечного кредитования

Выводы

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

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

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

Рис. 5. Сокращение стоимости и сроков изменения процесса

В целом результаты внедрения описанного подхода дали существенное сокращение как времени, затрачиваемого на согласование изменений, так и стоимости процесса согласования (рис. 5). Сокращения затрат удалось достичь за счет снижения уровня согласующих лиц, а также уменьшения числа сотрудников, вовлеченных в процесс согласования.

Текст статьи опубликован по материалам журнала "Банковское дело" №4, 2018.

Март 2018 г.

Рекомендуемые материалы по тематике

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

Методика оптимизации бизнес-процессов банка (финансовой организации)

«Динамизация» банка или как сделать процесс оформления командировки незаметным