Техническая библиотека CITForum.ru CITKIT.ru - все об Open Source Форумы Курилка
Все новости / Все статьи Деловая газета - шквал(!) IT-новостей :: CITCITY.RU
Первая полоса ИТ-Инфраструктура Телекоммуникации Безопасность BI Интеграционные платформы КИС IT-бизнес Ширпотреб Точка зрения

22.10.2017

Новости:


Все новости

Business Intelligence

Проблемы интеграции данных

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

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

Причины неудач глобальных интеграционных проектов

Многие крупные организации пытаются осуществить интеграцию всех своих данных, но далеко не у всех это получается. Однако неудачи объясняются не только технологическими причинами, но и рядом других факторов. Вот основные их них.

  1. Разнообразие и лавинообразный рост информации.
    За последнее десятилетие произошел настоящий взрыв как структурированной, так и неструктурированной информации. По некоторым оценкам, в расчете на каждого человека ежегодно производится 800 мегабайт информации. Рост крупных организаций часто происходит за счет приобретения других компаний. Но с точки зрения управления данными консолидация отдельных компаний и информации из распределенных и разнообразных источников еще не обязательно означает консолидацию в форме единого корпоративного Хранилища данных. Обеспечение последовательного доступа к таким разнообразным данным является одной из главных проблем для многих компаний.
    Проблема также усложняется отсутствием общих стандартов номенклатуры данных и информации в таких компаниях. Этот недостаток общих стандартов представляет собой основной барьер для последовательной и согласованной организации данных. Как показывает опыт, несмотря на то, что каждый сотрудник согласен с необходимостью разработки таких стандартов, добиться их принятия в масштабах всей компании бывает нелегко.

  2. Постоянные изменения бизнеса.
    Наивно полагать, что консолидация данных когда-то заканчивается. Корпорации постоянно осуществляют новые инвестиции, внедряют новые или модернизируют существующие бизнес-процессы для использования появляющихся возможностей, осуществляют слияния или приобретения, меняют операционные модели. В современном деловом мире невозможно игнорировать происходящие изменения, поскольку способность оперативно реагировать на запросы потребителей означает вопрос выживания бизнеса как такового. Такая гибкость неразрывно связана со способностью IT-систем приспосабливаться к этим изменениям с той же скоростью, с какой они происходят.
    Постоянные изменения в бизнесе затрудняют реализацию проектов по консолидации данных. Чем грандиознее и продолжительнее проект, тем сильнее он зависит от изменений в бизнес-процессах.

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

  4. Противоречия между "глобальными" и "локальными" требованиями.
    Большинство крупных организаций состоят из целого ряда относительно автономных операционных единиц. Такие группы компаний регулярно меняются в результате различных реорганизаций, приобретений и изъятия капиталовложений. Бизнес-приоритеты (и, соответственно, потребности в информации) могут существенно отличаться в различных частях организации.
    Например, небольшая местная компания, входящая в бизнес-группу, может захотеть открыть небольшое предприятие, предлагающее специализированные услуги по уборке с использованием своих продуктов. Ей необходимо действовать быстро, чтобы занять место на еще свободном рынке. Менеджеру, отвечающему за управление и оптимизацию своей категории продуктов по всему миру (например, промышленные уборочные машины), может потребоваться информация о рентабельности и доле рынка каждого продукта по странам. Доступ к общей интегрированной бизнес-информации окажется полезным и для местной компании, и для бизнес-группы. Но местное предприятие должно действовать немедленно, а менеджер категории понимает, что сбор всей необходимой ему информации может потребовать определенного времени.
    Из этого примера очевидна глубокая разница приоритетов, требований и подходов. Это противоречие между "глобальными" и "локальными" нуждами затрудняет взаимопонимание и осуществление проектов интеграции. В таких обстоятельствах, как один из возможных выходов, иногда предлагается использовать более радикальный подход: отдельные компании должны подчиняться общим требованиям. В принципе это правильный подход, но если в организации уже глубоко укоренилась "индивидуалистическая" психология, то ее изменение может потребовать значительного времени, которое часто недооценивают и которое не всегда есть в реальности. Помимо этого, компаниям не стоит форсировать процесс принятия общих стандартов, чтобы не потерять те возможности, которые дает более гибкий подход.
    Соблюдение баланса конфликтных приоритетов - это серьезная проблема управления проектом интеграции. Если одна группа приоритетов приносится в жертву другой, то это может лишь ухудшить положение организации. Необходимо отдавать себе отчет в том, что существуют различные нужды и приоритеты, и все они должны приниматься во внимание.

  5. Неизбежный риск крупных проектов.
    Уже сама мысль о необходимости заставить высшее руководство компании принять решение и прийти к согласию относительно стратегических глобальных приоритетов и стандартов, необходимых для создания общего корпоративного Хранилища данных, может привести в уныние. Крупные интеграционные проекты подвержены риску по двум основным причинам. Во-первых, адаптация к новым бизнес-требованиям требует слишком большой работы по изменению уже сложившихся механизмов. Во-вторых, количество необходимых ресурсов иногда достигает таких величин, что это становится слишком дорогостоящим мероприятием.
    Одно из решений, предлагавшихся для этой проблемы, - разбиение интеграционного проекта на несколько отдельных частей путем создания некоторого набора индивидуальных Хранилищ данных и их последующего связывания в форме "свободной федерации". Преимущество такого подхода - снижение остроты проблемы и осуществление проекта в виде последовательных шагов. Аналогичный подход, который использовался многими организациями, - создание ряда витрин данных (наборов так называемых "очищенных" данных), что часто поощряется поставщиками инструментов BI или системными интеграторами. Но в реальности это часто оборачивается тем, что организации получают предметно-ориентированные Хранилища (которые фактически являются витринами данных), не связанные между собой, что ведет к значительному дублированию данных и большим расходам на поддержку этих систем.
    Такие подходы осложняются еще и отсутствием организационной структуры, необходимой для поэтапного осуществления столь амбициозного проекта. Небольшое количество технически квалифицированного персонала, способного создать программное обеспечение для работы в этих непростых условиях, означает довольно высокий уровень риска. Ограниченное число представителей бизнеса, обладающих полномочиями для согласования приоритетов с основной массой организации, подверженной постоянным переменам, существенно сокращает выбор потенциальных кандидатов на роль управляющих глобальными интеграционными проектами.
    Своевременное осуществление глобального интеграционного проекта в рамках установленного бюджета оказывается очень проблематичным без технической архитектуры готового программного продукта, допускающего сосуществование локальных модификаций и согласованного общего подхода.

Корпоративное Хранилище данных

Корпоративное Хранилище данных - это применение комплексной модели бизнеса, включающей такие важные элементы бизнеса, как потребители, продукты, время, география, иерархия продаж и рынок. Иногда эти элементы именуются измерениями (dimensions), т.к. они определяют контекст бизнес-транзакций. Это база данных, где объединяются и структурируются данные атомарного уровня из несовместимых источников, и в результате получается единый массив корпоративных данных, позволяющий оперативно и точно принимать решения, направленные на поддержку стратегических и тактических бизнес-инициатив.

Сегодня существует 4 основных подхода к построению корпоративного Хранилища данных: создание Хранилища по условиям заказчика, Хранилище данных на основе систем планирования ресурсов предприятия (Enterprise Resource Planning, сокр. ERP), виртуальное Хранилище и новый тип - настраиваемое Хранилище.

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

  1. Обеспечивать определенную скорость доступа и гибкость, что включает:
    • итеративный подход к внедрению, позволяющий учитывать меняющиеся бизнес-требования. Возможность быстрого обеспечения решения для конкретной области бизнеса, а также дальнейших расширений;
    • возможность быстрого создания прототипов, чтобы новые бизнес-требования могли быть оперативно изучены вместе с пользователями;
    • отсутствие жестких схем, т.к. пользователи часто обнаруживают, что им нужна совсем другая информация из Хранилища, чем они первоначально предполагали.
  2. Обеспечивать масштабируемость:
    • подход должен быть масштабируемым для того чтобы общий проект мог быть разделен на несколько отдельных (более мелких) проектов, направленных на удовлетворение различных приоритетов, имеющихся в тех или иных подразделениях организации. Это также упростит общее внедрение, т.к. позволит избежать осуществления очень крупных проектов;
    • в идеале Хранилище должно легко расширяться для включения новых сфер бизнеса или наборов данных транзакций. Например, должна существовать возможность сначала создать Хранилище для областей продаж и маркетинга, а затем включить в него сферу финансов.
  3. Обеспечивать расширяемость:
    • по мере развития, роста и изменения бизнеса неизбежно появляются потенциальные новые источники данных (например, при приобретении другой компании). Очень важно иметь возможность быстро включить эти новые источники данных в Хранилище без сложной и длительной реконструкции последнего.
  4. Обеспечивать ориентацию на пользователей:
    • часто Хранилище может использоваться как цельный источник данных для создания различных подмножеств данных, таких как витрины или кубы, что облегчает разработку отчетности. Хранилище должно поддерживать процесс создания таких витрин и помогать пользователю в извлечении наборов данных;
    • конструктивное решение Хранилища данных должно позволять бизнес-пользователям принимать участие как в первоначальной разработке Хранилища, так и в последующих изменениях его дизайна, связанных с изменениями требований бизнеса. Как показывает опыт, чем больше вовлечены пользователи в общее проектирование Хранилища, тем более вероятно, что будет удовлетворять требованиям бизнеса. Например, в Хранилище должен учитываться тот факт, что один и тот же субъект бизнеса в одних случаях может рассматриваться как клиент, а в других - как поставщик.
    • в идеале Хранилище данных должно быть легко адаптируемым, чтобы пользователи могли работать только на уровне бизнеса, не осложняя себе жизнь, например, названиями таблиц. Также изменения в Хранилище, связанные с изменениями в бизнесе, не должны требовать выгрузки всех данных и их повторной последующей загрузки. Это замедляет развитие бизнеса и затрудняет способность быстро реагировать на изменения.
  5. Обеспечивать способность реагировать на изменения и осуществлять бизнес-моделирование:
    • Хранилище данных должно обладать способностью учитывать временную зависимость и вариабельность, т.е. поддерживать так называемую "корпоративную память": информацию о прошлом, настоящем и будущем бизнеса. Организации хотят иметь такие Хранилища, которые могут функционировать в течение длительного периода времени и хранить историческую информацию. В течение этого периода некоторые объекты могут измениться. Если эти исторические данные не сохраняются, то сравнение состояний одного и того же объекта во времени окажется невозможным;
    • необходима функция поддержки планирования бизнес-сценариев, т.е. способность рассматривать и анализировать данные в различных аспектах, включая исторические тенденции. Это необходимо для изучения будущих возможностей бизнеса. Помимо этого, часто возникают новые сценарии и структуры отчетности, которые должны быть включены в Хранилище до того, как они вступят в силу. Это также важно для планирования различных сценариев.

Интеграция с помощью федерализации

Единое корпоративное Хранилище данных может быть неплохим архитектурным решением для интеграции информации всей компании. Многие организации выбрали этот путь в полном соответствии с требованиями своего бизнеса. Такое Хранилище является хорошей отправной точкой для определения того, какая архитектура лучше всего подходит для конкретного бизнеса. Как уже говорилось выше, неоднократно осуществлялись попытки создать или связать воедино набор более мелких специализированных Хранилищ данных. Такая структура обычно называется федерацией.

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

Федеративная архитектура отражает организационную структуру путем разделения полномочий между центральной структурой и ее полуавтономными составляющими или "федеративными членами".

Ее цель - сбалансировать два "экстремума": всеобъемлющее корпоративное Хранилище данных, обслуживающее все регионы и области бизнеса, и отдельные автономные региональные или отраслевые Хранилища. К сожалению, часто создается корпоративное Хранилище, которое обслуживает только центральный офис компании, т.е. инструменты финансовой консолидации фактически становятся корпоративным Хранилищем данных. Федеративная модель Хранилища данных предполагает, что внутри иерархии Хранилищ может производиться обмен данными, бизнес-моделями и отчетными структурами, что способствует местной автономии и настройке под нужды потребителей. В то же время федеративное Хранилище может обеспечивать глобальный контроль и определенную степень стандартизации. Федеративное Хранилище данных состоит из целого ряда отдельных Хранилищ, которые работают полу-автономно, обычно географически или организационно разобщены, но тем не менее представляют единое большое Хранилище данных. В случае однородного бизнеса может создаваться одно корпоративное Хранилище данных, но оно также подвержено риску в случае приобретения новых компаний.

Например, на корпоративном уровне может быть определена общая структура продукта для конкретной области бизнеса и отправлена в Хранилище данных той или иной географической бизнес-группы как стандарт.

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

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

В следующей статье мы подробнее расскажем о различных подходах к созданию федеративных Хранилищ.

Публикации

Дэвид Уэддингтон (David Waddington). Архитектурный подход к интеграции информации: обзор проблемы федеративных Хранилищ данных. (An Architected Approach to Information Integration - Federated Enterprise Data Warehousing Overview).



Intersoft Lab

Последние комментарии:

Самое интересное:


© 2004–2009 Проект CITCITY.ru