ВРМ по Демингу. Опыт реализации проекта «Ипотека» в Европейском трастовом банке

Автор: Дмитрий Бахтин, Директор департамента информационных технологий КБ «ЕВРОТРАСТ» (ЗАО)
Издание: Банковские технологии 10 2012

О том, что будущее в управлении бизнес-процессами принадлежит BPM-технологиям, сейчас говорят многие. К сожалению, многочисленные положительные оценки не подкрепляются таким же числом практических примеров внедрения Business Process Management. В чем тут дело? Может быть, BPM-техноло-гии не так хороши, как о них толкуют? Может быть, речь идет о разрекламированном и раскрученном продукте, ценность которого на поверку сомнительна? Думаю, что причина другая.

Прежде всего, внедрение системы управления на базе Business Process Management — процесс сложный и дорогостоящий. Такой проект невозможно завершить в течение 2-3 месяцев. Кроме того, BPM-технологии годятся не для всякого случая. Это то самое лекарство, которое следует принимать только по назначению врача, и обязательно в строгом соответствии с его предписанием. В противном случае BPM становится чем-то вроде рояля, используемого в качестве журнального столика. Самая большая потребность во внедрении BPM-технологий, безусловно, имеется в финансовой сфере. Руководители банков, финансовых компаний, задумывающиеся над необходимостью интенсифицировать работу, сделать ее более эффективной, вполне осознанно приходят к решению перейти на систему управления на базе Business Process Management. Правда, пока практического опыта внедрений накоплено немного. Но он все-таки есть, в том числе и у нас, в Европейском трастовом банке. О том, как и для чего мы внедряли у себя BPM-технологии, мне и хотелось бы рассказать.

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

Для Европейского трастового банка оптимизация выдачи ипотечных кредитов — вопрос очень важный. Банк наш ориентирован на обслуживание физических лиц, имеет разветвленную сеть (34 региональных подразделения). При такой сложной структуре хороших результатов можно достичь в том лишь случае, если все подразделения банка, участвующие в процессе, работают как единый механизм. Любой кредит — это дело всего банка, не только того филиала или офиса, где его выдают. Поэтому для нас переход на систему управления при помощи BPM-техноло-гий был назревшим вопросом, который необходимо было решать. Поставив перед собой задачу перейти к управлению ипотечным проектом, используя инструментальные средства управления бизнес-процессами, мы понимали, что сделать все сразу и в короткий срок не получится — слишком велик объем работ. Поэтому вместе с нашими партнерами из компании БИС, которые занимались разработкой и внедрением проекта на базе Intalio|BPMS, мы подготовили поэтапный план, который сейчас успешно реализуется.

Любой специалист, работающий в сфере экономики, знаком с концепцией Деминга по управлению качеством. Его формула PDCA, описывающая циклически повторяющийся процесс принятия решения, используемый в управлении качеством, имеет прямое отношение к нашему случаю. Правда, в несколько модифицированном виде. Еще раз повторю, что реализовать весь проект сразу в полном масштабе очень сложно, здесь предпочтительнее пошаговые действия. Именно так мы и подошли к реализации нашего проекта. Распланировав (Plan) весь процесс и подойдя к стадии выполнения (Do), мы декомпозировали его на подпроцессы, которые, в свою очередь, раздробили на процедуры, применяя, таким образом, классическую формулу PDCA (планирование — выполнение — проверка — корректировка) в полном объеме сначала к более мелким частям всего процесса. И только отладив до конца все части подпроцесса, переходили к более верхнему уровню.

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

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

Еще один важный аспект — BPM-технологии работают только там и тогда, когда имеется точное описание бизнес-процесса. Не надо думать, что речь идет о некой подготовительной работе: если такого описания нет, не стоит и браться за внедрение BPM. Когда мы готовили такое описание, мы последовательно изложили: кто, что и в какой последовательности делает — кто проверяет, кому передает, что является входом для каждого этапа или подпроцесса, что результатом. Мы нарисовали подробную карту бизнес-процесса, которую пришлось неоднократно дополнять и уточнять. И только получив точное представление и описание того, как должен строиться процесс оформления ипотечного кредита, мы смогли написать правильное техническое задание для разработчиков. Мы подсчитали, что при оформлении кредитной заявки надо в общей сложности заполнить порядка 180 полей. Это значительный объем, при котором количество ошибок при вводе также велико. Не потому, что люди плохо работают, а просто человеку свойственно ошибаться. Кроме того, заявкой занимается не один сотрудник, и, следовательно, все вместе они увеличивают риск неправильного действия.

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

Сегодня в банке система подготовки к выдаче ипотечного кредита уже выстроена и работает вполне четко. Заявка проходит несколько этапов, она выпадает не на конкретного исполнителя, а на роль. Скажем, первая роль — сбор необходимой информации о клиенте и ввод данных по нему. Кто именно выполняет эту работу — не так важно, главное, чтобы все было сделано правильно. Для этого используется информация из базы данных всех филиалов банка, также запрашиваются данные из бюро кредитных историй, и из других источников. Далее кредитный инспектор вносит информацию о продукте, который хочет получить заемщик. Переход с одной экранной формы на другую осуществляется обычным нажатием кнопки «далее» в интерфейсе системы. Если все заполнено верно — автоматически откроется следующая страница, если что-то пропущено — программа сообщит об этом сотруднику. Невозможность отправиться на следующий уровень с ошибкой или с заполненными данными — это своеобразная «защита от дурака», которую мы очень ценим.

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

Мы уже упоминали о формуле Деминга. Пожалуй, нам удалось наладить работу в соответствии с этим принципом также и при реализации автоматического отражения данных по кредиту в ЕИС (единая информационная система) АИЖК. Подобного механизма пока нет ни в одном банке, а в Евротрастбанке он уже успешно опробован. Чтобы данные по кредиту попали в ЕИС АИЖК, нужно либо занести их вручную, со всеми вытекающими возможными ошибками, связанными с человеческим фактором (как уже озвучивалось ранее — это заполнение порядка 180 полей, и прикрепление более 35 сканов документов), либо интегрироваться с ЕИС. Собственно, что и было сделано нашими разработчиками — специалистами компании БИС. Есть система-источник — база заявок в Intalio|BPMS. Далее, после прохождения определенных этапов обработки и принятия решения, заявки отражаются в определенном интерфейсе, позволяющем сформировать XML-файл, соответствующий XSD-схеме, для импорта данных в ЕИС через интеграционную шину. Работы по реализации были разбиты на поэтапную разработку. На текущий момент в таком режиме уже успешно функционирует загрузка данных по кредиту. Следующий этап — обогащение выгруженного файла сканами документов. Поскольку в работе обычно находится не один десяток кредитных заявок, такая система для нашего банка очень удобна, так как экономит время и позволяет избегать многих ошибок.

Создание системы работы с ипотечными кредитами — дело сложное и, прямо скажем, недешевое. Но, во-первых, необходимое. Во-вторых, окупаемое. По нашим подсчетам, если система позволит увеличить оборачиваемость активов, задействованных в ипотечных программах, хотя бы на 10-15%, то срок окупаемости составит всего 5-6 месяцев, что позволяет банку гарантированно получить как увеличение доходов, так и улучшение его финансовых показателей. Есть и еще одно преимущество: система позволяет значительно сэкономить на экспертизе, так как при ручной обработке количество ошибок на различных этапах достаточно велико и требует обязательной процедуры — экспертизы каждой заявки. В Европейском трастовом банке работа по внедрению BPM-технологий продолжается и сегодня уже понятно, насколько она банку необходима. Думаю, наш опыт может послужить хорошим примером другим финансовым институтам, которые на пути решения: внедрять BPM или работать по-прежнему.

Скачать статью в pdf.