1.
Уровни зрелости ИТ в банках
Василий Мельничук
2011

2.
Регуляторы и контролёры
Банк
Центробанк
Налоговая
служба
Фонд
гарантирова-
ния вкладов
Комиссия по
ценным
бумагам
Пенсионный
фонд
Прокуратура
МВС
Антимоно-
польный
комитет
FATF
2

3.
Стандарты
Финансовый
учет по
националь-
ным
стандартам
Налоговый
учет по
националь-
ным
стандартам
IFRS
PCI-DSS
ISO 2700x
Sarbanes–
Oxley Act
Basel III
CobIT
MiFID
Стандарты соответствия и учёта
3

4.
Что нас принуждает к изменениям?
Фактическая способность организации к
изменениям
Акционеры
Конкуренция
Регуляторы
4

5.
15.9
84.1
Доля ІТ витрат в
загальноадміністративних
витратах
IT бюджет
Другие
затраты
5.5
94.5
Середня доля ІТ персонала
IT
персонал
Другой
персонал
ІТ бюджет в банках Европы
Средняя доля ІТ
персонала?
Доля ІТ в
общеадминистративных
затратах
5
25
75
Доля ІТ витрат в
загальноадміністративних
витратах
По
требованию
регуляторов
Другие ИТ
затраты
Доля затрат на выполнение
требований регуляторов в IT
бюджете

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

7.
Различные методики определения TTM
= Time To Market
• Как можно скорее внедрить бизнес идею.
Применяется в индустрии, незарегулированной законодательными
требованиями. Не лучший метод для финансовых учреждений.
Зачастую решаются человеческими ресурсами без надлежащей
аналитики.
• Сократить ресурсы, особенно ручную работу.
Некоторые ошибочно отождествляет короткий TTM с экономией
расходов в будущем, и иногда на такие акции уменьшение
показателя ТТМ тратится больше человеко-часов, чем
планируется сэкономить.
• Получить гибкость к изменениям.
Быстрое внедрение новой линейки продуктов без остановки
производства (отвлечение персонала на тестирование,
обновление ПО, обучение) путем прозрачной интеграции новинок в
существующую архитектуру - это идеальное использование
методики определения ТТМ.
7

8.
CMMI
= Capability Maturity Model Integration
9
Уровень 1:
начальный (initial).
Четкая организация
процессов
отсутствует,
процессы
непредвиденные,
нет определенных
правил и процедур
разработки, успех
программных
проектов обычно
является заслугой
отдельных лиц.
Уровень 2:
управляемый
(managed).
Процессы
определяются и
документируются,
но они
сфокусированы на
организации
конкретного
проекта, то есть не
стандартизированы
и могут отличаться
в различных
проектах.
Уровень 3:
определен
(defined). Во всех
проектах процессы
соответствуют
заданному
корпоративному
стандарту, так
называемому
стандартному
процессу
организации.
Уровень 4:
управляемый на
базе
количественных
показателей
(quantitatively
managed). Процессы
становятся
предсказуемыми и
появляется
возможность
управлять такими
параметрами
проекта, как
количество ошибок,
трудоемкость, объем
переделок и т.д.
Уровень 5:
оптимизированный
(optimizing).
Процессы находятся
в состоянии
постоянного
совершенствования,
компания может
внедрять
существенные
инновации в
процессы на основе
анализа
количественных
показателей,
идентифицировать
корневые причины
проблем проектов и
предотвращать их
появление.

9.
10
Принципы SOA
= Service Oriented Architecture
• Архитектура не привязана к определенной технологии
Например, сервер базы данных может находиться не только на
платформе Windows, но и на конкурентных платформах - Linux,
AIX, HP-UX и т.д.; работать с объектами АБС можно не только из-
под стандартного клиента от производителя.
• Архитектура не зависит от языка программирования
Модули (сервисы) пишутся на любом языке по независимости или
слабой зависимости от других сервисов или платформ.
• Сервисы имеет подобный интерфейс доступа
Для эффективного использования сервисов их нужно интегрировать
в комплексные решения. Универсальным переводчиком должна
выступать «сервисная шина» (Enterprise Service Bus)

10.
Упрощенная модель SOA
11
SOA
Сервис
Договор на
обслуживание
Внедрение
Бизнес логика Данные
Интерфейс
доступа
Библиотека
сервисов
Сервисная
шина
Application –
интерфейс
пользователя

11.
12
Классические ошибки организаций, снижают их
«эластичность»
• Внедрение систем, а не стандартов
Классическим примером является волевое внедрение систем учета без
оценки возможностей дальнейшего развития этих систем или интеграции с
другими решениями. В результате покупки банка или слияния, персонал
банка проходит через многочисленные миграции на другие архитектурные
решения без очевидного эффекта.
• Введение жестких форматов обмена данными
Примеры – клиринговые файлы Центробанка. Зато есть большое количество
международных консорциумов, определяющие открытые стандарты к
форматам обмена данными.
• Определение одинаковых приоритетов для всех проектов,
непоследовательность в построении архитектуры
Поскольку различные подразделения банка имеют разные векторы
интересов, в банках спонтанно создаются инициативные группы, которые
при фактическом несостоятельности банка проработать все требования
вовремя, пытаются пролоббировать наивысший приоритет именно для их
инициативы. Это несет сокрушительный удар по технической эластичности
банка.

12.
13
Последовательность построения архитектуры
CBS
• Оценка потенциала АБС (и стратегии ее разработчика) для дальнейшего
развития и интеграции с будущими решениями
• Внедрение / замена АБС как главной платформы учета
• Активация системы класса Business Intelligence для построения управленческой
отчетности и отчетов по внезапным требованиях контролирующих органов
ESB
• Внедрение сервисной шины свободно умеет «общаться» с различными
транзакционными или учетными системами
• Подключение спутникового систем (основные средства, персонал, зарплата,
карточный процессинг, системы быстрых переводов)
• Разработка сервисов (или использование уже имеющихся)
SFS
• Sales Force Solutions - оценка и внедрение систем эффективных продаж /
анализа клиентов (CRM, Front-End, Customer MIS)
• Разработка и внедрение системы определения и оценки KPI (коэффициент
полезного действия) персонала

13.
14
SCRUM, XP vs Классические подходы к проектам. SCRUM:
Портфель задач
Регулярный
пересмотр
приоритетов
и портфеля
задач
Выполнение
одной задачи
за один раз

14.
15
SCRUM, XP vs Классические подходы к проектам. SCRUM:
Задача Результат
Высвобождение исполнителей от рутинной работы, вывод в
отдельный офис, посвящение времени только на выполнение одной
дискретной задачи в течение недели - максимум двух. Обязательное
условие - увидеть конечный результат.

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

16.
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.orgwww.oasis-open.org

17.
18
Резюме
Jim Champy

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