Знакомство с проектами по бизнес-аналитике, и описанными в этом номере журнала, и обсуждаемыми на публичных мероприятиях, позволяет отметить как некоторые общие их черты, так и некоторые любопытные особенности, которые со временем, возможно, станут общепринятой практикой.
Одно из общих наблюдений заключается в констатации простого факта: переход от решения частных аналитических задач к построению централизованных хранилищ данных как базы любых аналитических приложений уже произошел, причем не только в крупнейших холдингах, но в компаниях более скромного размера. Промышленно построенных хранилищ, пригодных для комплексного применения, по‑прежнему очень мало, хотя такие проекты по мере возможностей не останавливали даже в кризис. Доля «самостройных» хранилищ, более или менее сложно организованных на стандартных базах данных, до сих пор высока, и их преимуществом продолжает считаться гибкость: своя рука владыка.
Какие же именно приложения использовать? Нетривиальную мысль высказывает директор по информационным технологиям компании «МегаФон» Константин Юнов в этом номере, стр. 36: не страшно, даже и с точки зрения поддержки, если в компании схожие задачи решают разными инструментами. Во всяком случае, на определенном этапе это вполне нормально, хотя, строго говоря, не оптимально. Со временем произойдет естественный отбор, полагает Юнов, и сложится более экономичная конфигурация, в любом случае с применением не одного-единственного продукта, а все же их набора.
Это примечательно практическое мнение хочется подчеркнуть, так как почти в любой сфере применения бизнес-приложений на определенной стадии возникает этот спор: одно или много? Комплексное решение, где «все есть», или множество инструментов? И каждый раз, насколько можно заметить, по мере набора опыта и зрелости ИТ-руководители приходят к мысли, что ни одно продаваемое как комплексное решение не является достаточным. И вновь составляется пазл, только уже обычно более высокого уровня. Видимо, бизнес-аналитика — не исключение.
Построение самих хранилищ сталкивается с целым рядом проблем. Полно и четко о них рассказывал Валерий Артемьев из «Центра информационных технологий Банка России» в своем докладе на профильной конференции по BI, проведенной в октябре 2010 AHConferences. Комплексный проект по развитию информационно-аналитической системы идет в банке уже несколько лет. По ходу создания хранилища данных, ядра этой системы, стало ясно, что в основном это организационно-методологическая, а не технологическая задача. Участие в ее решении специалистов функциональных подразделений оказалось недостаточным, их роль должна была бы быть более значительной. Было признано, что необходима особая организационная структура для корпоративного управления данными. Наряду с этим потребовалась методология создания, непрерывного развития, сопровождения хранилища. Много вопросов вызвали и громоздкая архитектура хранилища, и разработка политики формирования витрин. Несмотря на то что масштаб проекта в «Банке России», конечно, уникален, все это общие проблемы, и комплексного подхода к их решению, примеров реализации долговременной стратегии построения аналитических систем не приходится наблюдать.
Очистка данных, обеспечение их целостности и непротиворечивости повсеместно остаются камнем преткновения. Сложности выходят далеко за рамки технических вопросов, в основном упираясь во взаимодействие различных подразделений, бывают связаны и с юридическими ограничениями. Чаще всего, к сожалению, проблема очистки данных комплексно не решается и даже далеко не сразу осознается организацией. Например, проблема, характерная для банковской отрасли (о ней говорил Олег Подкопаев в интервью в № 2/2011, стр. 30 «Дела банкирские»): данные транзакционных систем перед помещением в хранилище проходят очистку, но обратно в свои «родные» системы не попадают. Уже однажды выверенные справочники по разным, в том числе юридическим причинам, невозможно оказывается применять везде, где это необходимо с точки зрения ИТ. Эта проблема актуально не только для банковской, но и для многих других отраслей. Отличие в том, что на финансовую сферу, как более зрелую и развитую, уже работают специализированные ИТ-компании, занятые именно очисткой данных. Возможно, что подобные узкоспециализированные предложения услуг появятся со временем и в других отраслях.
Более общей и тоже нерешенной является проблема управления метаданными в целом, выбор схем управления ими, алгоритмы их консолидации, связывание в общем репозитории. Согласованность описаний и свойств данных — вопрос, в теории известный, а как его решать практически, в подавляющем большинстве случаев совершенно не ясно. Более того, чаще всего он звучит в докладах как истина, мучительно доставшаяся в ходе построения аналитической системы. С метаданными связаны и другие вопросы, решаемые с большим трудом: множество их представлений и связность, унификация форматов обмена ими, их историчность и версионность, коллективное их ведение. Эти вопросы поднимались в докладе Валерия Артемьева не случайно: масштаб имеет значение, и только наиболее развитые и крупные организации начали уже осознавать эти вопросы как целый блок практических проблем, а не как отвлеченные теоретические построения. Но можно предположить, что скоро очередь дойдет и до множества остальных организаций.
В «Банке России» при построении аналитической системы столкнулись и с рядом других трудностей. Мы привыкли к тому, что государственные учреждения, тем более финансовые, строго регламентируют не только свою, но и чужую работу, и, однако, сложности не были уникальными. Программисты отвергают инструменты бизнес-аналитики, а пользователи ориентированы на регламентированные отчеты. Поэтому чаще всего средства разработки отчетности более развиты, чем BI‑средства. Требуется типизация этих BI‑средств, структур витрин данных и для упрощения разработки, и для сопровождения приложений. Используется множество режимов работы, и приходится типизировать и настраивать пользовательские интерфейсы. Чтобы обеспечить масштабируемость, необходим «серьезный тюнинг», как сказал Артемьев, многозвенных приложений и инфраструктуры. Слабости инфраструктуры сразу дают себя знать и при организации удаленной работы, оборачиваясь недостаточной производительностью.
По сути дела, серьезное внедрение BI-инструментов, стремление иметь надежно и достоверно работающую аналитику приводит к необходимости заново пересмотреть весь ИТ-ландшафт, расчистить слабые, несбалансированные места как в инфраструктуре, так и в ПО, оптимизировать архитектуру, наладить управление данными, в общем, провести «генеральную уборку» всего ИТ‑хозяйства. И это бы полбеды, но при этом еще и связи между подразделениями, порядок их взаимодействия тоже придется пересмотреть и навести порядок больший, чем был ранее, что далеко выходит за рамки полномочий любого отдельного департамента. Неудивительно, что проекты по BI идут не быстро. Очень забавно поэтому слышать агитацию интеграторов и вендоров, когда они обещают дать красивые витрины с диаграмками уже через несколько недель после старта проекта. Любопытно, что и в деле визуализации данных, оказывается, поле еще совершенно не паханое, о чем толково рассказано в статье Ю. Кудрявцева (этот номер журнала, стр. 33). BI всегда выглядела как более-менее красивая надстройка над другими ИТ‑системами, или скорее, в реальности, пристройка сбоку. При желании иметь достоверную аналитику она потребует усилий не меньших, чем внедрение собственно учетных, транзакционных систем.
