Проблемы разработки автоматизированной системы управления крупного коммерческого банка на основе ключевых показателей эффективности и пути их решения

Управление на основе ключевых показателей эффективности (КПЭ) в последнее время является одним из основных трендов во всех сферах экономики и государственного управления. Возможность применения данных методов в банковском деле не вызывает сомнения [4], так как очевидна измеримость показателей деятельности как рядовых сотрудников (операционно-кассовых работников, специалистов по продажам, сотрудников ИТ-подразделений и др.), так и топ-менеджмента, отвечающего за эффективность деятельности банка в целом.

Набирающие все большую популярность автоматизированные BPM (Business Performance Management) - системы – системы управления, базирующиеся на целостном, процессно-ориентированном подходе к принятию управленческих решений, направлены на повышение способности компании оценивать свои финансовые показатели и управлять эффективностью деятельности на всех уровнях [3]. Примером такого класса систем являются системы поддержки принятия решений (СППР) [6], основанные на ключевых показателях эффективности (КПЭ, KPI).

BPM-технологии «моложе» BI-технологий. Международная организация The Data Warehousing Institute датирует появление BPM как класса программного обеспечения (ПО) 1999-2000 гг. [9]. В связи с тем что рассматриваемый класс систем является относительно молодым, в общедоступных источниках недостаточно информации о процессе внедрения BPM, основанных на КПЭ. Недостаток информации объясняется и тем, что внедрение BPM на основе КПЭ для предприятия (в частности коммерческого банка) является закрытым процессом, и предприятия стремятся сохранить в тайне подробности внедрения систем.

Рассмотрение проблем внедрения подобных систем чаще ограничивается определением перечня показателей, причем системы рассматриваются в отрыве от конкретных сфер экономики [10].

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

Актуальность работы обусловлена не только явным недостатком информации по данной тематике, но и тем, что вышеназванные применяемые в банках модели KPI не позволяют провести комплексный многосторонний анализ деятельности КБ, так как в них рассматриваются конкретные направления (например, системы КПЭ кадровых служб (HR), рисков, финансов и др.) [7,9-11]. Разрабатываемая автором система представляет собой инструмент проведения комплексного анализа состояния деятельности как всего банка в целом, так и конкретных его подразделений (как различных функциональных подразделений, так и подразделений разных уровней организационной структуры). Фактов наличия аналогов подобной системы автором не было найдено как в общедоступных источниках информации, так и при обсуждении рассматриваемых вопросов со специалистами, имеющими большой опыт работы в банковской сфере РФ.

1 .     Проблемы разработки СППРи пути их решения

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

С точки зрения бизнес-аналитики наибольший интерес представляет процесс разработки информационного обеспечения СППР, который состоит из следующих этапов [см. 8]: разработка «бизнес-кейсов» и выяснение потребности в информации;

разработка модели показателей; установление источников информации и методов ее консолидации и обработки.

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

Разработка «бизнес-кейсов» и выявление потребности в информации

Проблемы

Соответствующие работы не проведены или проведены поверхностно.

Не проводится работа с ожиданиями будущих пользователей.

Последствия

Функциональная составляющая системы не соответствует бизнес-требованиям пользователей.

Разрешимые на этапе проектирования с помощью системы кейсы не смогут быть решены при практической реализации системы.

Пути решения

Необходимо на ранних этапах реализации системы определить основные группы пользователей системы [2].

С каждой из групп пользователей необходимо провести детальную работу по составлению «бизнес-кейсов» [2]:

• o    создание экспертных групп соответствующих различным направлениям деятельности банка;

• o    моделирование ситуаций, требующих принятия управленческих решений;

o выявление необходимой для принятия решений информации.

Результаты работы необходимо задокументировать и согласовать с пользователями.

В результате проработки «бизнес-кейсов» должна быть сформирована основа для последующей разработки модели показателей.

Разработка модели показателей

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

Определение набора КПЭ

Проблемы

Уделяется мало внимания методологическим особенностям подготовки данных по показателям эффективности.

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

В связи с недостаточной проработкой «бизнес-кейсов» в модель показателей не попадают значимые блоки КПЭ, некорректно строятся декомпозиции основных показателей.

Не проводится работа по поиску ответов на основные вопросы, характеризующие каждый конкретный КПЭ [2].

Последствия

Возникают методологические ошиб- ки в подготовке данных по показателям.

Затраты на получение данных по некоторым показателям значительно превышают ценность показателей.

Модель показателей не соответствует реальным требованиям бизнес пользователей.

Пути решения

После проработки «бизнес-кейсов» необходимо составить перечень направлений деятельности банка, которые планируется анализировать с помощью системы. Результатом является выделение корневых блоков показателей.

Для каждого из корневых блоков необходимо выделить подгруппы показателей

(например, внешние, финансовые, персонал, клиенты и др.).

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

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

• •    После определения перечня показателей необходимо выявить основные характеристики показателей, а именно [см. 2, 8]:

• o    описание показателя, т.е. что под собой подразумевает показатель;

• o    методика расчета показателя;

• o    единица измерения показателя;

• o    ответственное за данные по показателю лицо;

• o    тип данных (на дату (за период) накопительным итогом);

• o    динамика предоставления данных по показателю (дневная, недельная, месячная, квартальная, годовая);

• o    каким является показатель – прямым, реверсивным или нейтральным;

• o    аналитические ракурсы, в которых должен быть представлен показатель (например, в разрезе территорий, клиентских сегментов, валют и др.);

• o    с какого момента могут быть получены данные по показателю;

• o    лаг предоставления данных по показателю;

o устанавливаются ли по показателю плановые значения подразделениями банка или устанавливаются лимиты регулирующими органами.

• •    Для каждого КПЭ составить так называемую карточку КПЭ, содержащую информацию согласно выявленным основным характеристикам.

• •    Очень важно на ранних этапах составить карту лиц, ответственных за данные по каждому из показателей. Разработке этого документа необходимо уделить особое внимание, т.к. в процессе реализации системы постоянно возникают вопросы, связанные с данными по показателям [5].

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

Определение методов анализа данных по КПЭ

Проблемы

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

• •    Не прорабатываются различия в методологии расчета и интерпретации значений производных показателей (процент выполнения плана, отклонение от тренда, run rate, отклонение от значений в прошлых контрольных периодах, скорость изменения показателя и пр.) для различных показателей (абсолютные и относительные, прямые и реверсивные, на дату и накопительным итогом).

Последствия

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

• •    Снижается информативность производных показателей.

• •    Затрудняется оценка значения показателя (позитивное или негативное для бизнеса).

Пути решения

• •    Так же, как и для модели данных, основой для разработки методов анализа данных должны служить разработанные «бизнес-кейсы».

• •    Во время разработки «бизнес-кейсов» необходимо выявить основные индика-

• торы и в соответствии с этим создать систему производных показателей.

• •    При технической реализации системы предусмотреть механизм наименее трудозатратного внедрения новых способов анализа данных (методы анализа должны представлять собой независимые модули, логику которых, в случае необходимости, легко поменять) [10].

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

• • Система анализа данных должна быть единообразной для большинства показателей. Допускается выделение нескольких способов анализа данных в зависимости от групп по-

• казателей [2]. Так, способы анализа могут существенно различаться:

o для показателей в дневной, недельной и месячной динамиках;

o показателей, отраженных на дату или накопительным итогом;

o абсолютных и относительных показателей.

• •    Методика анализа данных и различной индикации показателей должна разрабатываться при обязательном сопоставлении с существующими в банке методиками [5].

Установление источников информации и методов ее консолидации и обработки

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

• •    Не рассматриваются перспективы развития источников данных.

• •    Не учитываются особенности обновления данных в источниках (временные лаги, динамика данных в источнике).

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

• •    Сложность (или невозможность) консолидации данных из различных источников.

Последствия

• •    Во время разработки может измениться структура хранения данных в источнике или источник может прекратить свое существование [1].

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

Пути решения

• •    При создании модели показателей необходимо разработать технологическую карту источников данных по показателям. В карте должно быть отражено соответствие всех показателей и источников данных [1].

• •    Определение ответственных за каждый из источников данных [1].

• •    Создание справочника источников данных, в котором будет содержаться необходимая для работы с источником информация:

• o    описание того, какого рода данные содержатся в источнике (например, данные по кредитному портфелю юридических лиц);

• o    лицо, ответственное за качество данных в источнике;

• o    периодичность обновления данных в источнике;

o необходимая техническая информация, т.е. информация, необходимая для технической реализации извлечения данных из источника.

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

• •    Реализация механизмов «ручного» ввода данных по показателям (например из Excel-файлов).

• •    Реализация механизма загрузки одного КПЭ из разных источников. Механизм хорошо сочетается с кластерной загрузкой данных по показателям. Появляется возможность создания системы фильтров данных по кластерам.

• •    В связи с тем что многие автомати-

• зированные системы-источники данных могут находиться в разработке, необходимо согласовывать график появления данных по показателям с графиками работ над системами-источниками [5].

• •    Для своевременного отслеживания возможного нарушения качества и согласованности данных необходимо разработать различные механизмы проверок:

• o    анализ выбросов;

• o    анализ нарушения логичности данных, например, с помощью задания математических зависимостей между показателями;

• o    анализ регулярности предоставления данных;

o отслеживание состояния данных по показателю (например, данные актуальны и достоверны/данные устарели, необходимо об-новлять/данные актуальны, но некорректны).

• •    При организации процесса работы с системами-источниками следует придерживаться правил работы с данными, принятых в банке (системы справочников, структуры таблиц и др.) [2].

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

• •    При обнаружении проблем с глубиной детализации данных важно своевременно проводить работу с ожиданиями потенциальных пользователей системы.

2.     Риски разработки СППР ипути их снижения

Описанные выше проблемы тесно связаны с возможностью возникновения организационных и проектных рисков.

Организационные риски

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

• •    политические;

• •    процессные и методологические;

• •    коммуникационные;

• •    риски внешней среды.

Политические риски

Описание

Риски, связанные с поддержкой проекта руководством банка, межфункциональным характером проекта, разными интересами поставщиков и потребителей управленческой информации, интересами отдельных подразделений банка [5].

Пути снижения рисков

Разработчику системы важно быть «аполитичным», по возможности не принимать участия в политических играх, но при этом важно понимать «политическую» ситуацию на проекте для определения (корректировки) целей проекта, перечня заинтересованных лиц и их ожиданий, по возможности принимать участие в распределении ролей участников процесса разработки системы [5].

Процессные и методологические риски

Описание

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

Пути снижения рисков

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

Информационные риски

Описание

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

Пути снижения рисков

При столкновении с данными рисками необходимо своевременно составлять перечень информации, к которой необходим доступ для успешной реализации системы (с подробным описанием причин и возможных последствий отсутствия доступа к необходимой информации) [5].

Коммуникационные риски

Описание

Риски, связанные с проблемами обмена информацией между подразделениями банка в ходе проекта и в рамках автоматизируемых процессов [5].

Пути снижения рисков

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

Риски внешней среды

Описание

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

Пути снижения рисков

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

Проектные риски

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

Ниже представлены выявленные разновидности проектных рисков, а также даны рекомендации по их снижению для случаев, требующих активного вмешательства разработчика системы [1, 5].

• •    Риски, связанные с нечетким определением целей и задач проекта и его сферы (в

том числе границ проекта и принятых допущений).

• •    Данная категория тесно связана с организационными рисками.

• •    Риски, связанные с неполной идентификацией заинтересованных в проекте сторон, отсутствием в команде проекта представителей заинтересованных сторон.

Пути снижения рисков

Для минимизации проектных рисков необходимо разработать карту распределения ролей участников процесса реализации системы.

• •    Риски в связи с недостаточной обеспеченностью проекта ресурсами как со стороны команды разработчиков системы, так и со стороны заказчика системы.

Пути снижения рисков

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

• •    Технические (ИТ) риски проекта. Анализ рисков данной группы в большей степени направлен на ИТ-составляющую проекта. С точки зрения бизнес-аналитики основными рисками данной категории являются риски, связанные с источниками данных (несогласованность данных из различных источников, проблемы в интеграции данных и др.).

Пути снижения рисков

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

Заключение

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