Кривое зеркало, или Что пишут на модные темы в ИТ

Что обещают производители решений для автоматизации регуляторной отчетности в своих публикациях в СМИ и все ли обещания выполняются? Ответ на эти вопросы для портала Bankir.ru дан в экспертной статье Intersoft Lab.

PR-формат текста изначально ограничивает содержание сообщения. Поэтому маркетологи, как правило, используют PR-публикации для привлечения внимания к проблеме – создания в хорошем смысле этого словосочетания модной обсуждаемой темы. Одни модные темы приходят, что называется «от жизни»; например, в ушедшем году обсуждались подходы к выработке и реализации антикризисной ИТ-стратегии банков; другие – с Запада. Высший пилотаж маркетологов заключается в формировании интереса к темам, актуальность которых станет очевидной потребителям только завтра. В банковских информационных технологиях (ИТ), от которых сегодня на 70% зависит успех бизнеса, высокая скорость внедрения инноваций требует проактивного подхода к получению новой информации.

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

Чтобы не быть голословной, приведу несколько примеров из рекламных текстов в области ВРМ-решений (Business Performance Management, управление эффективностью бизнеса). Сегодня здесь в числе модных тем – модели данных для построения банковских хранилищ данных (ХД) и решения для подготовки регуляторной отчетности.

Про желаемое и действительное

Популярная сегодня концепция отраслевых моделей данных предполагает применение в качестве основы для построения ХД и ВРМ-систем логической модели, которая максимально полно описывает все области деятельности организации. Отраслевая логическая модель банка, то есть визуальное представление объектов именно этой предметной области, их атрибутов и взаимосвязей, является прототипом базы универсального банковского хранилища. На основе логической модели осуществляется физическое моделирование структур хранения первичных данных и расчетных показателей (витрин данных) достаточных для решения целого комплекса взаимосвязанных задач управления и анализа. Платформы для построения банковских хранилищ поставляются с уже готовыми структурами данных, механизмами создания витрин и вычисления показателей. Модель является каркасом для создания индивидуального ВРМ-решения банка, который можно последовательно наполнять данными, получая на каждом этапе полезный для заказчика результат. Вместе с тем системы, реализованные на таких платформах, гарантированно не пострадают при наращивании прикладной функциональности.

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

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

Но, скажем прямо, без доработок, а иногда и перестройки существующих бизнес-процессов успешное внедрение прикладных решений на основе хранилищ данных невозможно. Дело в том, что переход на новый качественный уровень анализа и принятия управленческих решений требует как минимум нового качества ведения учета. Простого перекладывания данных из учетных систем в базу данных ХД недостаточно для получения результата. Использование модели диктует требования к составу и качеству исходных данных для подготовки различных видов аналитической, управленческой и регламентной отчетности. Становится прозрачной цепочка: данные-расчетные показатели-отчеты. «Прочитав» ее в обратном порядке, легко увидеть, какие данные должны быть в хранилище, чтобы выпускать ту или иную отчетную форму. Ничто не берется ниоткуда - когда первичные данные отсутствуют в хранилище, выпустить по ним отчет нельзя. В проектах практически всегда задействуют процедуры обогащения данных, как на этапе ETL-процесса, так и непосредственно в хранилище. На 100% устранить таким способом дефицит первичной информации не получается. Возникает необходимость вносить изменения в формы ввода первичных данных и технологию работы операционистов, которые должны вводить в систему больше атрибутов сделок и др.

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

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

Про осознанное и бессознательное

Разберем другой показательный пример. В опубликованном в СМИ кейсе об опыте автоматизации обязательной отчетности для Банка России компания-автор сообщает о реализации пакета сложных отчетных форм, в том числе 115, 118, 125, 128, 155, 302, 316, на основе кредитного портфеля банка, собранного в хранилище в рамках первого этапа проекта.

Даже из названия формы 0409115 «Информация о качестве активов кредитной организации» очевидно, что ее подготовка требует загрузки в хранилище данных по всем активам банка. То есть, кроме собственно кредитов юридических и физических лиц, ипотечных, авто- потребительских и межбанковских кредитов, необходимо собирать данные по акциям, векселям, облигациям, сертификатам, аккредитивам. Для формы 0509125 «Сведения об активах и пассивах по срокам востребования и погашения», помимо ссуд, потребуются данные по депозитам физических и юридических лиц, привлеченным межбанковским кредитам, векселям, облигациям, обеспечениям, гарантиям. Для формы 0409302 «Сведения о размещенных и привлеченных средствах» - депозиты и пластиковые карты.

Как из публикации понять, в каком объеме решение на самом деле было реализовано в банке? Наиболее вероятная гипотеза – в ходе проекта в хранилище загрузили и очистили данные по кредитам и подготовили не всю, а часть информации для выпуска перечисленных отчетных форм. Скорее всего, она выгружается в Excel-таблицы и передается бухгалтерам для дальнейшей обработки. Подход очень жизненный – работа бухгалтера по подготовке формы облегчается в части сбора и выверки данных по кредитам; на начальных этапах проекта это тоже полезный результат. Правда, это означает, что как минимум три отчета из перечисленных в кейсе пока НЕ «реализовали», а, рапортуя о достигнутых результатах, несколько приукрасили действительность. Вторая возможная причина допущенной некорректности – в данный момент у компании нет опыта автоматизации указанных отчетных форм. Узость проектной практики приводит к досадным ошибкам в публикациях.

***

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

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

Автор: Ю. Амириди

Источник: Bankir.ru, 2010.5.14