Уровни зрелости ИТ в банках
Download as PPTX, PDF0 likes426 views
Документ рассматривает уровни зрелости информационных технологий (ИТ) в банках и влияние регуляторов на изменения в этой области. Обсуждаются различные исторические этапы развития банковских архитектур и методологии оценки зрелости, такие как CMMI и SOA. Также рассматриваются типичные ошибки организаций, препятствующие их гибкости, и принципы внедрения современных ИТ-систем.
Уровни зрелости ИТ в банках
- 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
- 18. 19 IT == Креативность и оптимизация.