Согласно исследованиям, более 50% проектов по внедрению хранилищ данных и аналитических приложений заканчиваются неудачей. Такую неутешительную статистику нам озвучили сотрудники лаборатории IBM в Ирландии, где ведется разработка и поддержка индустриальных моделей данных, включая модель данных банковских хранилищ. Это было неожиданно. Особенно, если учесть, что информация была озвучена делегации топ-менеджеров Государственного сберегательного банка Украины, которые в 2011 году приехали в Дублин, чтобы ближе познакомиться с моделью IBM Banking Data Warehouse (IBM BDW).
Не знаю, как мне удалось тогда убедить руководство приступить к созданию такого хранилища. В одном из разговоров мой бывший шеф, член правления и финансовый директор банка, сказал: «Если бы я знал, во что я ввязываюсь, я бы еще раз хорошо подумал». Но, видимо, иногда в жизни бывают моменты, когда сама судьба сталкивает нужных людей в нужное время и в нужном месте. И тогда ты задаешь себе простой вопросы: если не я, то кто, и, если не сейчас, то когда?
Сегодня, оглядываясь назад, можно выделить семь факторов, благодаря которым стал возможен успех нашего проекта.
1. Заинтересованность первого лица
Итак, статистика по успешным проектам неутешительная. С высоты моего нынешнего опыта могу сказать, что в действительности число успешных проектов еще меньше. Даже если IT-система вводится в эксплуатацию, это не означает, что она будет жизнеспособна, будет развиваться и поддерживаться в долгосрочной перспективе. Иногда ввод в эксплуатацию – это лучший способ закрыть неудачный проект, отчитавших об успехах перед правлением или собственниками банка.
В таких сложных IT-проектах, как внедрение хранилищ и построение систем отчетности, параллельно с проектом автоматизации происходят системные и глубокие изменения в процессах банка, затрагиваются интересы и сферы ответственности ключевых менеджеров. Неизбежно происходит серьезная перестройка всего банка. Поэтому одним из главных факторов успеха все же является желание председателя и, как минимум, одного из его ключевых заместителей, изменить банк, сделать его более управляемым и прозрачным.
2. Финансовый директор – лучший бизнес-спонсор
Именно финансовый директор в силу служебных обязанностей отвечает перед национальным банком, регуляторами и возможными инвесторами за предоставление достоверной и полной финансовой информации. А с внедрением в Украине и России международных стандартов финансовой отчетности (МСФО), раскрытие информации становится отраслевым стандартом, особенно, если банк ищет внешние заимствования на международных рынках капитала.
Кроме того, именно у финансового директора в руках бюджет и штатное расписание, что немаловажно, как для нормального финансирования текущих расходов проекта и удержания команды высококвалифицированных разработчиков, так и для капитальных инвестиций в оборудование и программное обеспечение.
Роль бизнес-спонсора такого проекта может взять на себя и операционный директор, и директор по IT. Но, как правило, они озадачены другими системными вопросами, которые находятся в зоне их непосредственной ответственности (централизация бэк-офиса, автоматизация и оптимизация бизнес процессов). Хранилище и система отчетности играют для них второстепенную роль.
3. Прямое подчинение менеджера спонсору проекта
Наличие спонсора необходимое, но недостаточное условие успеха. Проект должен возглавить надежный менеджер с опытом в банковском бизнесе, пониманием IT-технологий, знаниями в области моделирования и работы с данными. Кроме того, менеджер должен обладать четким видением будущего и пониманием тенденций развития системы отчетности.
Ключевым фактором успеха является прямое подчинение менеджера проекта бизнес-спонсору, регулярная отчетность и обратная связь между ними. Это в разы повышает эффективность управления и снимает многие проектные риски на старте.
Менеджер проекта должен обладать не только хорошими лидерскими качествами, но также быть хорошим психологом. Умение слушать людей, понимать и примирять разные точки зрения – это те неоценимые качества, без которых эффективное управление отношениями и управление информацией в проекте просто невозможны.
Менеджер должен уметь общаться с людьми на разных уровнях организационной иерархии, знать, как, кому и когда доносить нужную информацию. А главное, он должен понимать, зачем он это делает, какой результат он хочет получить, воздействуя на систему, и, какую цену он готов заплатить за этот результат.
4. Внутреннее управление проектом при создании новых функций
Один из ключевых выборов для менеджера, который инициирует проект, является выбор между внутренним и внешним управлением проектом. Ему необходимо решить – брать ли ответственность на себя или перепоручить эту роль внешней компании.
На старте нашего проекта в 2011 году на рынке Украины уже было начато несколько проектов по внедрению хранилищ на основе IBM BDW. Но на тот момент у IT-партнеров IBM в Украине не было знаний не только в части моделирования IBM BDW, но и в части поддержки других программных продуктов IBM InfoSphere Information Server, которые необходимы для полноценного внедрения хранилищ данных. Не было и локальных консультантов, которые способны были бы эти знания и опыт передать команде разработки.
Мне было очевидно, что для успеха проекта просто необходимо найти надежного западного IT-консультанта, который сможет обучить команду на этапе разработки и обеспечить необходимое качество ведения проекта. Именно из-за этого понимания, и возникла необходимость организовать визит в Дублин, о котором я упомянула вначале статьи. Необходимо было понять, кто из партнеров IBM за рубежом способен передать уникальные знания разработчикам и бизнес-аналитикам в Украине.
Как потенциальный менеджер проекта, я очень хорошо осознавала, что местные IT-компании будут учиться моделированию и построению хранилища вместе с нами. При этом мы не сможем напрямую контролировать и удерживать их сотрудников, которые будут приобретать уникальные знания за счет работы с западными консультантами.
Было принято решение ввести внутреннее управление проектом, чтобы, в том числе, создать и сохранить новые навыки и уникальные, даже для западного рынка, компетенции внутри организации.
5. Создание отдельного подразделения
Проектная команда по сути была вписана в функциональную организацию финансово-экономического департамента, в жесткие рамки иерархической структуры банка. На ранних этапах проекта было создано отдельное подразделение систем информации для менеджмента или Management Information Systems (MIS) с абсолютно новыми функциями.
Кроме того, проектные роли были вложены в штатное расписание, насколько это было возможно. При этом проектные роли по сути превалировали над штатными должностями. Я осознанно нивелировала иерархическую структуру подчинения и выстроила между членами команды плоскую горизонтальную коммуникацию.
Основным условием была 100% фокусировка подразделения на участии в проекте. В будущем это подразделение должно было стать собственником хранилища и системы отчетности. Это снимало возможное напряжение в проектной команде. Люди понимали, что и после окончания проекта у них будет постоянная работа, перспективы развития и карьерного роста.
6. Вовлечение владельцев источников в команду на аутстафинге
В рамках подразделения MIS было создано пять команд, каждая из которых решала свою задачу: бизнес-анализ и моделирование; разработка процедур загрузки данных ETL и метаданными; разработка отчетов BI; разработкой WEB-приложений для хранилища; выгрузкой данных из систем-источников хранилища.
Последняя команда была сформирована из сотрудников компании-разработчика основных источников данных. Мы привлекли команду дата-аналитиков и разработчиков на аутстафинге. Это ускорило коммуникации, упростило процесс разработки выгрузок данных и в разы ускорило маппинг данных источников на модель данных хранилища (Source to Target).
Первый релиз был внедрен в рекордно короткие сроки в течение девяти месяцев по методу Waterfall и по нынешним временам с очень скромным бюджетом. Во время последующих релизов команда освоила гибкое управление проектом по методу Agile.
7. Мотивация команды и миссия проекта
Важнейшим фактором была готовность людей обучаться, работать с новыми программными продуктами, осваивать сложную модель IBM BDW. Как менеджеру проекта, мне было абсолютно понятно, что люди должны быть мотивированы не только и не столько деньгами, сколько перспективой получения новых знаний и освоения новых инновационных технологий.
Наверное, во многом успех проекта был обусловлен тем, что мне удалось связать мотивы топ-менеджмента банка, личные мотивы членов команды и мои личные мотивы как консультанта. Но главное мне удалось показать команде внедрения высший смысл их работы: прозрачность и управляемость одного из системообразующих банков страны. Кроме того, прозрачная отчетность была основным требованием внешних институциональных инвесторов, которые хотели войти в капитал банка. Это могло изменить в лучшую сторону инвестиционный климат страны в целом.
К моменту ввода хранилища в тестовую эксплуатацию команда MIS чувствовала невероятный подъем. Это произошло 24 декабря 2012 накануне католического рождества. Дата была символичной. Девять месяце прошло, и родилось наше детище. Мы это сделали, мы действительно это сделали. Но как показала история, это было лишь начало нового этапа жизни.
8. Желание заказчика продолжать изменения
Хранилище ясно проявило проблемы с данными в системах-источниках: некорректное ведение справочников, хранение истории… Проблемы с данными отражали наши проблемы не только в архитектуре источников-данных, но и пробелы в процессах и функциях банка. Это напрямую затрагивало интересы и сферу ответственности многих менеджеров среднего и высшего звена. И именно в этот момент вступили в игру совсем другие факторы и мотивы.
На этом этапе развития проекта топ-менеджменту приходиться отвечать себе на главный вопрос: действительно ли нам нужна прозрачная отчетность, хотим ли мы понятную систему поощрений, хотим ли мы менять правила игры? В этот момент решается дальнейшая судьба системы информации. И, как в известной поговорке, часто возникает ситуация «наказания невиновных и награждения непричастных».
На этом этапе нужны воля и желание председателя и бизнес-спонсора продолжать изменения. Именно здесь возникает необходимость внедрять политики и процедуры управления данными, закреплять новые роли и ответственность пользователей за данные, которых ранее в банке не было.
Эти процессы и роли (Data Stewards, Business Experts, Bank Data Managers, Data Quality Managers, Data Owners), уже давно стали стандартом в западных банках. Нашим же банкам еще только предстоит внедрять их в свою практику и процессы.
9. Благодарные пользователи – ключ к успеху
Мы в свое время недооценили важность вовлечения бизнес-пользователей отчетов на ранних этапах проекта. Именно их участие в определение терминов, в разработке требований к отчетам, справочникам, алгоритмам расчетов является важнейшим фактором успеха проекта на этапе тестирования и ввода в эксплуатацию.
Это помогает пользователям легче принять ответственность за формируемую отчетность, стать собственниками данных и включиться в процессы управления данными после ввода в эксплуатацию. Благодарные пользователи – ключ к дальнейшему развитию хранилища и системы информации.
10. Нужен Chief Data Officer
В моем нынешнем проекте в венском Erste Bank, где также внедряется хранилище на основе IBM BDW, меня поразил тот факт, что весь банк (от членов правления до рядовых сотрудников) разговаривает на языке моделирования, на языке атрибутов и терминов модели данных.
Основная цель Erste Bank на ближайшие годы связана не с улучшением обслуживания и лояльности клиентов, а с Data Excellence. Бонусы и ключевые показатели (KPI) топ-менеджмента банка напрямую связаны с качеством данных. Для решения проблем с данными часто требуется эскалация на уровень соответствующего комитета (Operational Decision Committee) или правления. Возникает абсолютно новая управленческая роль – директор по данным (Chief Data Officer). В Европе такой топ-менеджер входит в состав правления банка, и такой подход уже стал отраслевым стандартом.
11 -я не подходить к внедрению корпоративного хранилища данных как к внедрению ERP или учётных систем это разные вещи.
12 -я ни на шаг не отходить от выбранной методики или методологии
13-я соблюдать весь технологический цикл разработки, попытка сократить время, перепрыгнув через шаг - это типичная ошибка.
14-я раз и навсегда запомнить на всю жизнь - в слове ETL нет слова "очистка данных". За чистоту данных в КХД всегда отвечает источник