Система управления банком

1. Система бюджетного управления

Система бюджетного управления (СБУ) – ключевой элемент системы управления банком.

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

Основными задачами системы бюджетного управления являются:

• Построение бюджетов банка как в соответствии с требованиями акционеров, так и с внутренними требованиями банка;
• Организация процесса эффективного управления Банком;
• Обеспечение взаимосвязи между стратегией и оперативной деятельностью банка;
• Максимально эффективное использование всех ресурсов банка;
• Оптимизация затрат;
• Обеспечение координации, кооперации и коммуникации деятельности различных подразделений банка;
• Доведение планов до сведения руководителей групп банковских продуктов, подразделений;
• Контроль и оценка эффективности работы на местах путем сравнения фактических и плановых данных;
• Выявление потребностей в денежных ресурсах и оптимизация финансовых потоков.

На Рисунке 1 показаны состав и взаимодействие основных объектов СБУ:

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

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

В самом начале разработки методики СБУ принимаются некоторые ключевые решения:

• Выбор вида СБУ (см. варианты на Рисунке 2)
• Выбор типа и разработка финансовой структуры:
  • Региональная, клиентская или продуктовая финансовая структура;
  • Определение перечня бизнес направлений (бизнесов);
  • Выделение структурных подразделений в ЦФО;
  • Классификация ЦФО по их видам (центр затрат, центр дохода, центр маржинального дохода, центр прибыли, центр инвестиций);
  • Детализация ЦФО до уровня ЦБО (Мини банков);
  • Составление иерархии ЦФО, соответствующей порядку формирования финансового результата;
  • Закрепление ответственности руководителей за каждым ЦФО.
• Корректировка годового бюджета:
  • Выбор модели корректировок на основе плановых или фактических значений;
  • Порядок подготовки данных для корректировок.
• Контроль исполнения план-факт
• Трансфертное ценообразование
• Аллокация косвенных затрат

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

2. Проблематика внедрения управленческого учета

2.1. Традиционный подход

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

В частности, такое базовое понятие как «управленческий учет» очень часто служит синонимом системы управления банком. Типовой набор задач в управленческом учете при традиционном подходе (далее будем обозначать коротко ТрадУУ), как правило ограничивается оценкой рентабельности подразделений банка, продуктов и клиентов. В последнее время многие банки также оценивают рентабельность канала продаж. Безусловно, задачи управления современным банком гораздо шире, в следующем Разделе №2.2 мы вернемся к этому вопросу.

Долгое время ТрадУУ рассматривался как подсистема бухгалтерского учета, обеспечивающая руководителей информацией, используемой для планирования, управления и контроля за деятельностью организации. Во многом это связано с тем, что учетные регистры бухучета предоставляют полную, систематическую и выверенную информацию о фактах хозяйственной деятельности. В том случае, если в этих регистрах отсутствовали необходимые аналитики, проводилась операция «обогащения» счетов аналитическими признаками для целей ТрадУУ (например, признаки «клиентский менеджер», «статья актива-пассива», «отрасль» и др). При наиболее продвинутом подходе утверждался отдельный управленческий план счетов (в том числе на основе МСФО) и данные первичного бухучета корректировались по специальному алгоритму, позволяющему получать финансовые отчеты в виде баланса и отчета о прибылях и убытках не только по банку, но также по профит-центрам, клиентским сегментам и группам продуктов.

Можно отметить например такие виды корректирующих проводок:

• Аллокации АХР (административно-хозяйственные расходы);
• Проводки фондирования (на основе трансфертных цен);
• Проводки на разницу в учетных принципах бухучета и управленческого учета (например, признание расходов или доходов в разных периодах, амортизация комиссий и др.).

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

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

Описанный в данном Разделе №2.1 ТрадУУ не позволяет в полной мере обеспечить руководство информацией о себестоимости продуктов, доходности каналов продаж и клиентов. Полученные результаты по профит-центрам и сегментам продуктов и клиентов являются агрегированными и запаздывающими по причине ориентации на бухучет. Необходимо далее развивать ТрадУУ, использовать учетные объекты, позволяющие преодолеть имеющие недостатки, а также применять специальные методики, повышающие детализацию за счет использования, например, современных методов аллокации затрат. Более подробно об этой проблематике и современных методах решения – в следующем Разделе №2.2.

2.2. Управленческий учет для поддержки стратегического менеджмента банка

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

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

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

• Высокая степень детализации учета и отчетности – вплоть до уровня отдельного клиента и продукта;
• Множественные предварительные и вероятностные оценки (то есть присутствие показателей, не отражающих фактические проводки):
  • Величина риска (ожидаемые и потенциальные потери, основанные на параметрах риска);
  • Затраты «по нормативам» (например, нормативы затрат на выдачу кредита);
  • Различные качественные оценки, — такие как показатели ликвидности за пределами регулируемой текущей ликвидности. То есть часто принимаются решения на основе трендов и сценариев поведения активов и пассивов, а также собственных приближенных оценок, основанных на внутрибанковской практике.

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

Таким образом, возникает необходимость введения новых объектов учета в дополнение к традиционным — данным бухучета. В мировых банках широко распространена практика «сделочной» модели учета, при которой на уровне сделки (кредит, депозит, торгуемый финансовый инструмент) естественным образом определяются необходимые признаки и показатели – такие как продукт, профит-центр, ответственный менеджер, номинал сделки, комиссия, денежный поток, залоговое обеспечение и др..Так как сделка является бизнес-объектом, то все ее параметры практически не зависят от изменений в бухуучете, что радикально упрощает разработку и поддержку СтрУУ. Более того, по этим же причинам становится доступным так называемый параллельный учет, когда на основе параметров сделок и учетных событий в процессе жизненного цикла сделок можно одновременно построить схему проводок по национальным стандартам и по МСФО. Многим банкам более привычен процесс трансформации национального бухучета в МСФО, однако преимущества параллельного учета неоспоримы, когда речь заходит об автоматизации отчетности по МСФО, точности расчета амортизации финансовых инструментов, оценке их стоимости по рынку и по модели, оценке рисков и др..

Безусловно, существуют определенные сложности перехода банка на сделочную модель учета. В первую очередь это возможности существующих АБС, в особенности если они ориентированы на формирование бухгалтерских проводок. Однако и в этом случае нами могут быть даны методологические и ИТ рекомендации, а также проведена работа по переходе на перспективную сделочную модель и поддержку СтрУУ.

В заключение данного Раздела №2.2 рассмотрим базовый пример подхода к расчету рентабельности традиционных объектов ТрадУУ в концепции сделочной модели, характерной для СтрУУ.

Проанализируем Рисунок 3 со структурой доходности кредитной сделки и профит центра «Кредитный департамент», заключившего данную сделку.

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

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

Для этого надо:

• Провести аллокацию косвенных затрат с уровня профит-центра «Кредитный департамент» на уровень конкретной кредитной сделки;
• Уточнить прямые операционные затраты по факту на уровне конкретной сделки, в том числе переоценить показатели риска.

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

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

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

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

3. Аллокация ресурсов

3.1. Аллокация денежных ресурсов (трансфертное ценообразование)

Прежде всего трансфертное ценообразование FTP (Funds Transfer Pricing) является эффективным средством определения доходности ЦФО банка. Эта задача решается путем построения финансовых отчетов по ЦФО в результате учета покупки-продажи ресурсов между фондирующими и фондируемыми ЦФО (как правило – это профит-центры). В частности, реализация проводок фондирования возможна уже при внедрении ТрадУУ, основанного на бухучете, о чем упоминалось в Разделе №2.1 настоящего документа.

Более детально такие проводки и схема работы, основанная на трансфертном ценообразовании, показаны на Рисунке 4:

Отчеты по профит-центрам агрегируются до уровня банка, при этом исключаются следующие внутренние позиции:

• Балансовые позиции фондирования казначейства департаментом вкладов на сумму «ВклФонд» и последующее фондирование казначейством кредитного департамента на сумму «КредФонд». При простейшем применении FTP эти суммы должны быть равны, то есть фондирование кредитного департамента идет за счет казначейства, которое покупает эти ресуры у департамента вкладов и не использует привлечение с рынка. Возможность привлечения с рынка показана как опция, поскольку при обычной работе казначейства работают обе возможности фондирования: от клиентов и с рынка. Более того, рыночная ставка в модели FTP конкурирует с внутренней и влияет на методику FTP.
• Позиции ОПУ по процентным доходам и расходам со стороны всех трех вовлеченных в процесс FTP подразделений. В самом общем случае процентная маржа между привлечением (проценты по депозитам) и размещением (проценты по кредитам) делится на три неравные части: казначейство приобретает ресурсы у департамента вкладов по трансфертной ставке, обеспечиващей доходность департамента вкладов «ДохФонд1=РасхФонд1» и продает эти ресурсы кредитному департаменту по трансфертной ставке, обеспечивающей доходность казначейству на сумму «ДохФонд2 – ДохФонд1» («ДохФонд2=РасхФонд2»). Достаточно часто казначейство играет роль «зарабатывающего» подразделения в схеме FTP, поскольку на практике фондирование длинных кредитов часто идет за счет коротких депозитов. Соответственно казначейству дается возможность управлять потенциальным процентным риском за счет доходности в схеме FTP. Попутно отметим, что, принимая на себя процентный риск, казначейство по крайней мере частично снимает его с кредитного департамента.

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

• Совершенствование управления эффективностью подразделений банка и бонусных схем;
• Определение доходных и недоходных продуктов и бизнес-направлений;
• Совершенствование ценообразования, согласованная политика ценообразования и объема продаж по конкретным видам активов/пассивов;
• Совершенствование организационной структуры банка, уточнение роли Комитета по управлению активами и пассивами и казначейства. Помимо отмеченных аспектов управления рисками именно на казначейство как правило возлагается ответственность за назначение трансфертных цен. В целом же принципы назначения FTP представляют собой результат консенсуса между бизнес-подразделениями банка, в том числе по причине влияния на бонусные схемы.

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

• Различных корректировок (учет ФОР, досрочного погашения кредита, поправки на ликвидность и др.)
• Расширения перечня доходных операций по которым будет применяться трансфертное ценообразование, например:
  • Торговые операции;
  • Ресурсы, не имеющие срока погашения:
    • Наличные денежные средства, драгметаллы и средства на активных корреспондентских счетах;
    • Средства на корреспондентских пассивных счетах, текущих и депозитах до востребования, а также остатков в торговом портфеле;
    • Собственные средства банка (капитал).

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

Необходимость учета различных внешних и внутренних факторов и решение организационных вопросов делают задачу разработки методики FTP нетривиальной. Это тот случай, когда предложение «лучших практик» не работает и разработка методики должна осуществляться в тесном контакте с банком по принципу анализа различных подходов по выбору лучшего, наиболее применимого в данных условиях работы банка. По этой причине на начальном этапе постановки управленческого учета и разработки методики СБУ мы рекомендуем ограничиться экспертной оценкой в назначении конкретных трансфертных цен для конкретных сделок или портфелей сделок. Фактически речь идет не об алгоритмах формирования FTP, а о составлении и периодическом обновлении матрицы фондирования.

3.2. Аллокация косвенных затрат

Существующие технологии аллокации косвенных затрат по объектам управленческого учета позволяют достичь необходимой детализации при отнесении затрат на наиболее значимые объекты учета: ЦФО (включая профит-центры), продукты, каналы продаж, клиенты. В этом контексте в процессе внедрения системы управления банком в первую очередь необходимо привести в соответствие аллокации фактических данных аллокациям СБУ.

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

Что касается аллокаций на ЦФО, то многие банки успешно решают задачу оценки прибыльности профит-центров на основе фактических данных. Эти аллокации основаны на ссылочной базе (например, площадь или численный состав ЦФО), но такой подход трудно обосновать при аллокации на продукт или клиента: достаточно привести примеры, когда один сотрудник банка ЦФО занимается несколькими клиентами и продуктами. Тем более что и аллокации косвенных затрат по ссылочной базе на ЦФО являются своего рода общепризнанным компромиссом.

Другая проблема заключается в том, что при внедрении СБУ нередко формируется финансовая структура, поддерживающая в первую очередь сам процесс СБУ. Для процесса аллокаций это в частности означает следующее:

• Введение искусственных Центров учета косвенных затрат:

В ряде случаев это дает положительный эффект, поскольку такие затраты целенаправленно «разводятся» по бюджетным статьям с прямыми затратами и упрощается весь процесс СБУ;

• Использование каскадной аллокации:

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

Таким образом, описанная в данном Разделе №3.2 проблема несоответствия аллокаций по плану и факту дополняет проблему в Разделе №2.1, но является как бы зеркальной к ней, потому что здесь практики управленческого учета по факту наоборот опережают процессы СБУ. Мы рекомендуем совершенствавать методики аллокаций по факту и постепенно развивать СБУ, сближая аллокации в системе бюджетирования с аллокациями по факту. Для этого можно предложить два сценария развития СБУ, но они будут более понятны, если мы проясним особенности использования современных методик аллокаций.

Прежде всего речь идет о методике ABC (Activity Based Costing – учет затрат по процессам), которая позволяет эффективно решить проблему аллокаций на такие учетные объекты, как продукты, каналы продаж, клиенты. Аллокации по ссылочной базе используются в банках повсеместно, но они ограничены объектами ЦФО. Любая детализация таких аллокаций до уровня других учетных объектов (например, продукты), также возможна, но должна проводиться по согласованию с клиентом, поскольку она заранее будет содержать определенную погрешность. Однако это погрешность осознаваемая и мы можем рекомендовать внедрение такого подхода как компромиссный и временный вариант при переходе на методику ABC Costing.

На начальном этапе внедрения ABC Costing при составлении карты процессов следует руководствоваться следующей классификацией процессов:

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

Поскольку связь основных процессов с требуемыми объектами учета не вызывает сомнений, то задача сводится к аллокации затрат на эти процессы и в определении количественной связи процессов с учетными объектами. Рисунки 4 и 5 иллюстрируют ответы на эти вопросы с точки зрения бизнес-схемы и расчетной схемы процессного учета затрат на основе ABC Costing. В частности, бизнес-схема поясняет, что аллокация (распределение) на основе процессного учета осуществляется не посредством предполагаемых баз аллокаций, а на основе вполне конкретных потребностей по работе с продуктами и клиентами через каналы продаж. Эта потребность выражается через необходимость проведения операций в составе процессов, а выполнение процессов обеспечивается определенными ресурсами (см. Рисунок 5). Вся цепочка взаимосвязи «снизу-вверх» становится понятной на качественном уровне и согласовывается при выполнении проекта ABC Costing.

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

Затраты на банковский продукт1 = (Тариф Процесса1) * Кол-во1 + (Тариф Проц2) * Кол-во2

Аналогично рассчитываются затраты на другие объекты учета: канал продаж и клиент, а также на уровень сделки.

В отличие от традиционного учета затрат по элементам затрат, учет затрат по процессам ABC Costing предоставляет, как правило, иную структуру суммарной прибыли – см. Рисунок 7. При этом сами элементы затрат сохраняются в структуре затрат по процессам, что позволяет проследить их от источника до получателя: продукт, клиент и др.

Характерно, что для ABC Costing неважно какие затраты распределять – прямые или косвенные, что явно указано на Рисунке 6.

Попроцессный учет, в частности, показывает, как косвенные затраты понижают прибыльность многих продуктов, а также почему клиенты могут выглядеть более прибыльно, чем они являются с точки зрения традиционного учета затрат. Самое важное различие состоит в том, что калькуляция по методу АВС-Costing учитывает объем продаж, степень сложности и инновационности, а также другие аспекты, тогда как традиционная система учета их опускает. Еще одно применение метода – контроль над ценовыми характеристиками финансовых продуктов и осознанное выставление тарифов для клиентов, в том числе вариация тарифов, — например, в различных регионах могут быть различные тарифы.

В заключение обзора метода ABC Costing отметим, что у этого метода есть две разновидности. Выше мы рассматривали традиционный метод ABC Costing. Однако на волне некоторых трудностей с внедрением ABC Costing, вызванных сложностью его внедрения, стал активно развиваться и приносит хорошие результаты так называемый Временной учет затрат на основе процессов – TDABC Costing (Time-Driven Activity-Based Costing). Метод TDABC основан на вычислении тарифа некоторого «обобщенного» процесса, когда общие затраты (как правило, за месяц), аллоцированные на профит-центр, делятся на суммарное время, затраченное сотрудниками профит-центра для работы с различными процессами, признанными значимыми для аллокации затрат. Далее для выяснения, сколько затрат выделяется на отдельный бизнес-процесс, этот «обобщенный» тариф умножается на время, необходимое для выполнения этого конкретного процесса.

Опыт использования метода ABC по сравнению с TDABC показывает, что второй метод проще во внедрении и прозрачнее, поскольку позволяет оценить недозагрузку сотрудников. Кроме этого, традиционный ABC Costing значительно усложняется (вплоть до полного пересчета) при модификации процессов (новые параметры, документы и др.) и требует более массовых и сложных ИТ-вычислений.

Метод TDABC Costing рекомендуется использовать для типовых, повторяемых процессов (особенно для розничного банковского бизнеса) В то же время традиционный метод ABC Costing более подходит для использования в сложных, плохо формализуемых процессах (корпоративное кредитование и private banking – неплохие примеры для рассмотрения традиционного метода ABC Costing).

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

В заключение приведем два рекомендуемых сценария развития СБУ для сближения с управленческим учетом с точки зрения использования аллокаций, о чем говорилось в начале данного Раздела:

• Краеугольный камень ABC Costing – расчет тарифов процессов. При использовании в процессах СБУ тарифов, рассчитанных при фактическом распределении, возможен нормативный учет затрат на продукты, каналы продаж и клиентов. Для этой цели в том числе рекомендуется развивать регулярное планирование на уровне профит-центров, отвечающих за клиентские сегменты и продуктовые линии. В конечном итоге у этих подразделений должен сформироваться подход как к оценке прибыльности клиентов и отдельных продуктов на уровне нормативных тарифов по факту, так и возможные обоснованные корректировки этих тарифов.

Разработка СБУ на основе методики AB Budgeting – Activity-Based Budgeting (Процессно-ориентированное бюджетирование). При этом планирование строится от потребности в ресурсах для выполнения определенного объема продаж продуктов группам клиентов и достижения определенного уровня прибыльности бизнес-подразделений. Процессы ABB идут как бы в обратном направлении от процессов ABC Costing. При ABC Costing распределяется уже сформированный пул ресурсов, в то время как при AB Budgeting объем ресурсов формируется напрямую от объема операций с клиентами по определенным продуктам.

4. Подходы к внедрению системы управления рисками

Тема управления рисками – одна из ключевых, однако ее важность далеко не всегда соответствует вниманию, которое уделяется этой теме на проектах построения системы управления банком. Чаще всего встречается ситуация, когда департамент риск-менеджмента слабо вовлечен в процесс разработки принципов СБУ, аллокации затрат и денежных ресурсов. Между тем эти три темы, в том или ином виде обсужденные ранее, ближе всего затрагивают задачи управления рисками. В частности, совершенствование системы управления рисками отмечалось в Разделе №3.1 при использовании механизма трансфертного ценообразования.

На Рисунке 8 показаны взаимосвязи в работе различных подразделений банка, прямо или косвенно решающие пересекающиеся задачи, в том числе задачи управления рисками. В частности, такой задачей является ценообразоване с учетом риска:

В разделе №2.2 мы рассматривали маржинальную доходность сделки (см. Рисунок 3). Чем больше вероятность дефолта контрагента, с которым заключена данная кредитная сделка, тем больше должны быть затраты на риск: резерв на ожидаемые потери и аллокация капитала на непредвиденные потери. Как правило, на практике этот фактор учитывается посредством увеличения ставки по кредиту, но далеко не всегда на основе индувидуальных условий данной сделки. Последовательно проведенный проект внедрения системы управления банком позволяет это сделать, в том числе на основе полной себестоимости кредитной сделки, что отмечалось в Разделе №3.2.

Для достижения максимального результата в решении задачи управления рисками могут понадобиться специализированные системы, рассчитывающие параметры риска, такие как вероятность дефолта, сумма под риском и др.. Однако значительных результатов можно добиться и при использовании BI технологий и офисного приложения Excel. На Рисунке 9 приведен пример реализации такой системы и возможные результаты от ее внедрения для системы управления кредитными рисками:

В Разделе 5 приводится пример приложения SAP BEx, работающего на основе Excel, что позволяет реализовать необходимые расчеты и сформировать отчеты в рамках продуктов SAP BI.

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

Метод миграции просрочек заключается в том, что все кредиты портфеля делятся на несколько корзин в зависимости от длительности просрочки по кредиту. Так, в первую корзину могут быть включены кредиты, не имевшие просрочки; во вторую — кредиты с просрочкой от 1 до 30 дней; в третью — от 31 до 60 и т.д. Последней является корзина дефолтных кредитов. Процедура разбиения портфеля на корзины выполняется регулярно, с периодичностью, зависящей от шага разбиения. Уже по результатам двух разбиений можно оценить вероятность перехода кредитов между двумя смежными корзинами. Кредиты заданной корзины в течение месяца либо переходят в смежную корзину (например, из «31–60» в «61–90»), либо остаются в исходной корзине. Следовательно, вероятность перехода между смежными корзинами равна отношению численности этих корзин по данным за два смежных месяца. Перемножая эти вероятности, для любой корзины, мы можем оценить вероятность перехода в корзину дефолтов. Теперь, имея значения переходных вероятностей, остается подсчитать остаток задолженности по кредитам каждой из корзин и умножить его на вероятность перехода в корзину дефолтов. Сумма полученных величин дает ожидаемые потери портфеля без учета возмещений после дефолта.

Другой пример – использование статистического инструментария в составе Excel и часто присутствующего в составе Хранилищ данных. Построив на основе миграции просрочек модель поведения «хороших» и «плохих» заемщиков, можно ее провалидировать с помощью статистической обработки: хорошие результаты дает коэффициент Accuracy Ratio.

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

5. Взаимосвязь решения бизнес-задач с внедрением ИТ-приложений

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

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

Зафиксируем базовые особенности использования ИТ-решений для задач управления банком:

• Основной платформой для Системы управления банком является Хранилище данных, предоставляющее инструментарий для загрузки оперативных данных из внешних систем или поддерживающее ручной ввод данных (например, при бюджетировании). При необходимости, средствами Хранилища данных осуществляется преобразование этих данных.
• Специализированные ИТ-приложения работают на основе BI технологий и тесно интегрированы с Хранилищем данных. Эти приложения относятся к классу решений EPM (Enterprise Performance Management) и имеют встроенные возможности для реализации алгоритмов бюджетирования, аллокаций затрат и др.
• Очень важно при выполнении проекта и формировании конечного результата отличать задачи обработки данных (загрузка, формирование OLAP модели данных) от проведения алгоритмизированных массовых вычислений на основе этих данных. В последнем случае необходимо максимально использовать специализированные ИТ-приложения. На Рисунке 8 этот блок расчетов и вычислений показан в средней части вертикали управления банком, в области оперативного анализа и отчетности.
• Однако клиентам не следует слишком полагаться на встроенные возможности ИТ-приложений. Приобретая такое приложение, клиент приобретает только возможность реализации типового решения. Не прояснив особенности внедрения методик и их последовательность, не согласовав эти особенности с банком, не рекомендуется настраивать как ИТ-систему в целом, так и специализированные ИТ-приложения, входящие в эту систему. Более того, не все бизнес-задачи решаются с помощью специализированного ПО. В частности, методика трансфертного ценообразования не имеет однозначного «ответственного» ИТ-приложения. В этом случае решается вопрос об оптимальном внедрении методики с помощью одного или нескольких наиболее подходящих модулей ПО.

При выполнении проекта происходит уточнение отдельных бизнес-задач и формируется декомпозированная целевая бизнес и ИТ-архитектура. В качестве примера детализации рассмотрим декомпозицию бизнес-задачи «Консолидированная управленческая отчетность», представленную на Рисунке 8 на уровне управления банком – см. Рисунок 11. На рисунке показано, как эта отдельная задача представляется в виде Системы управленческой отчетности (СУО) и распадается на уровни и преднастроенные взаимосвязи внутри СУО, обеспечивая ролевое использование информации и логику поиска решения при идентификациии проблемы на уровне управления банком (например, отклонение ключевого показателя).

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

В качестве примера выбора конкретного набора продуктов и соответствующей архитектуры (см. Рисунок 12) мы предлагаем следующие аналитические программные продукты компании SAP, которые позволяют полностью покрыть ИТ-потребности проекта внедрения системы управления банком, описанные в настоящем документе:

• Business Warehouse: Хранилище данных и средство формирования аналитических отчетов на основе инструментария Business Explorer (BEx). При необходимости может предоставить инструментальные средства статистического анализа данных;
• Business Planning and Consolidation: инструментарий для автоматизации процесса бюджетирования и формирования бюджетных форм и отчетов;
• Profitability and Cost Management: инструментарий для автоматизации процессов аллокации затрат и выручки на различные аналитические объекты учета;

Business Objects: инструментарий для создания системы управленческой отчетности, имеющей дополнительные функциональные возможности по сравнению с Business Explorer, упомянутым выше.

6. Заключение

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

• Сочетание методологической и внедренческой практики позволит:
  • Разработать оптимальную «маршрутную карту» внедрения;
  • Исключить часто встречающийся разрыв между бизнес-подразделениями банка и проектной командой исполнителя;
  • Повысить ценность от выполнения проекта при достижении стратегических целей банка.
• Этапное выполнение методологических и внедренческих задач «от простого к сложному», основанное на собственном опыте исполнителя, позволит:
  • Снизить риски внедрения системы в банке;
  • Обоснованно принимать ключевые решения при выполнении проекта по заранее разработанной «маршрутной карте».