Уровни зрелости ИТ в банках

Василий Мельничук2011

Регуляторы и контролёры

Банк

Центробанк

Налоговая служба

Фонд гарантирова-ния вкладов

Комиссия по ценным бумагам

Пенсионный фондПрокуратура

МВС

Антимоно-польный комитет

FATF

2

Стандарты

Финансовый учет по

националь-ным

стандартамНалоговый

учет по националь-

ным стандартам

IFRS

PCI-DSS

ISO 2700xSarbanes–Oxley Act

Basel III

CobIT

MiFID

Стандарты соответствия и учёта

3

Что нас принуждает к изменениям?

Фактическая способность организации к изменениям

Акционеры

Конкуренция

Регуляторы

4

15.9

84.1

Доля ІТ витрат в загальноадміністративних

витратах

IT бюджетДругие затраты

5.5

94.5

Середня доля ІТ персонала

IT персоналДругой персонал

ІТ бюджет в банках Европы

Средняя доля ІТ персонала?

Доля ІТ в общеадминистративных

затратах

5

25

75

Доля ІТ витрат в загальноадміністративних

витратах

По требованию регуляторов

Другие ИТ затраты

Доля затрат на выполнение требований регуляторов в IT

бюджете

Эры развития архитектуры банковского учреждения

• Докомпьютерная эра. 1980-1990 гг.Попытки использовать компьютеры в качестве замены печатным

машинкам.

• Эра автоматизации учёта. 1990-2000 гг.Создание большого количества компаний, предлагающих различные

проприетарные системы учета банковских операций, операций учета основных средств, персонала, CRM-систем и др.

• Эра эластизации. 2007- длится.Перестройка архитектуры для получения гибкости в быстром

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

6

Различные методики определения TTM= Time To Market

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

требованиями. Не лучший метод для финансовых учреждений. Зачастую решаются человеческими ресурсами без надлежащей аналитики.

• Сократить ресурсы, особенно ручную работу.Некоторые ошибочно отождествляет короткий TTM с экономией

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

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

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

7

CMMI= Capability Maturity Model Integration

9

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

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

Уровень 3: определен (defined). Во всех проектах процессы соответствуют заданному корпоративному стандарту, так называемому стандартному процессу организации.

Уровень 4: управляемый на базе количественных показателей (quantitatively managed). Процессы становятся предсказуемыми и появляется возможность управлять такими параметрами проекта, как количество ошибок, трудоемкость, объем переделок и т.д.

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

10

Принципы SOA= Service Oriented Architecture

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

платформе Windows, но и на конкурентных платформах - Linux, AIX, HP-UX и т.д.; работать с объектами АБС можно не только из-под стандартного клиента от производителя.

• Архитектура не зависит от языка программированияМодули (сервисы) пишутся на любом языке по независимости или

слабой зависимости от других сервисов или платформ.

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

в комплексные решения. Универсальным переводчиком должна выступать «сервисная шина» (Enterprise Service Bus)

Упрощенная модель SOA

11

SOA

Сервис

Договор на обслуживани

еВнедрение

Бизнес логика Данные

Интерфейс доступа

Библиотека сервисов

Сервисная шина

Application – интерфейс

пользователя

12

Классические ошибки организаций, снижают их «эластичность»

• Внедрение систем, а не стандартовКлассическим примером является волевое внедрение систем учета без

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

• Введение жестких форматов обмена даннымиПримеры – клиринговые файлы Центробанка. Зато есть большое количество

международных консорциумов, определяющие открытые стандарты к форматам обмена данными.

• Определение одинаковых приоритетов для всех проектов, непоследовательность в построении архитектуры

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

13

Последовательность построения архитектуры

CBS

• Оценка потенциала АБС (и стратегии ее разработчика) для дальнейшего развития и интеграции с будущими решениями

• Внедрение / замена АБС как главной платформы учета• Активация системы класса Business Intelligence для построения управленческой

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

ESB

• Внедрение сервисной шины свободно умеет «общаться» с различными транзакционными или учетными системами

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

• Разработка сервисов (или использование уже имеющихся)

SFS• Sales Force Solutions - оценка и внедрение систем эффективных продаж /

анализа клиентов (CRM, Front-End, Customer MIS)• Разработка и внедрение системы определения и оценки KPI (коэффициент

полезного действия) персонала

14

SCRUM, XP vs Классические подходы к проектам. SCRUM:

Портфель задач

Регулярный пересмотр

приоритетов и портфеля

задач

15

SCRUM, XP vs Классические подходы к проектам. SCRUM:

Задача Результат

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

16

SCRUM, XP vs Классические подходы к проектам. Классический подход:Описание требований и границ проекта, показателей успешности проекта, определение проектной команды, спонсоров, членов Управляющего комитета, определение рисков и бюджета. Уже через три месяца приоритеты меняются, при недолжном внимании требования и риски - почти никогда не адаптируются.

Steering Committee

17

Над чем думать?

Организации промышленных стандартов Финансовых Услуг

www.acord.org

www.fixprotocol.org www.acord.org

www.ifx.org

www.swift.com www.twiststandards.org

www.nacha.org

Организации промышленных стандартов Вычислительных Услуг

www.w3c.org www.ieee.org www.ietf.org www.ws-i.org www.oasis-open.org

18

Резюме

„Once a company experiences the benefits of real process change, it generally develops an appetite for continuous process change. The work is never done, but scope and pacing are important.”

Jim Champy

19

IT == Креативность и оптимизация.