06.07.10 Минное поле BI

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

–Как организовать процесс моделирования данных в соответствии с потребностями бизнеса? Кто и как должен выявлять эти потребности, формировать модель и актуализировать ее?

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

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

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

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

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

Такое распределение обязанностей объясняется значительным числом сложных моментов и деталей, которые могут серьезно повлиять на выбор модели. В зависимости от задачи применяются различные подходы к проектированию хранилищ данных («сверху вниз» или «снизу вверх»), выдвигаются разные требования к системе ведения НСИ (например, необходимость параметризации и гармонизации справочников, поддержка версионности), возможностям проверки и валидации данных.

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

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

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

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

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

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

— Как наилучшим образом организовать процессы сбора, выверки и обработки исходных данных?

Николай Кацан: Для этого достаточно вспомнить лишь некоторые требования к загружаемой информации: она должна быть полной, достоверной, непротиворечивой, а самое главное — своевременной!

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

Петр Травкин: Как правило, все данные, анализ которых планируется проводить, уже имеются в базах данных различных корпоративных систем, таких как, например, EPR и CRM. На практике часто встречается и такой источник данных, как Excel, с которым внедряемая система также должна уметь беспрепятственно работать. На этапе сбора и обработки необходимо четко определиться прежде всего с количеством источников, и если их несколько, выявить все возможные пересечения и дубликаты.

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

Максим Балаш: Организацию процессов сбора, выверки и обработки исходных данных целесообразно начинать с разработки соответствующего регламента. Его задача — установить, какие именно данные, из каких источников, с какой детализацией и в какие сроки должны предоставляться. Определяет регламент и ответственных за выполнение отдельных операций.

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

Павел Бритов: Прежде всего нужно понять, доступны ли разработчику настоящие, «живые» данные — или разработка будет вестись на тестовых примерах; покрывают ли эти примеры все возможные случаи расхождений и ошибок в исходных данных. В самом начале работ требуется составить четкий план тестирования и сформулировать критерии приемки результата. Опыт показывает, что так можно минимизировать число исправлений на этапе опытной эксплуатации.

Николай Кацан: Особое внимание нужно обратить на следующие аспекты. При создании промышленного решения, которое планируется развивать, применение средств Data Integration (DI) является остро необходимым, поскольку число ETL-процессов очень быстро достигает такого количества, когда не обойтись без промышленных средств их сопровождения. Конечно, DI не является классическим элементом BI-систем, но происходит это в основном потому, что большинство поставщиков BI-решений не имеют в своей линейке программных продуктов для загрузки информации — или эти продукты не решают такой задачи в полной мере.

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

— Как было отмечено, вопрос организации сбора, выверки и обработки исходных данных тесно перекликается с задачей обеспечения необходимого качества итоговых данных. Как этого добиться?

Николай Кацан: Прежде всего необходимо осознавать, что обеспечение качества данных — процесс, а не «большая красная кнопка», одним нажатием которой решаются все проблемы.

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

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

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

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

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

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

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

Петр Лещенок: Для выверки исходных данных в BI-системе можно разработать специальные формы и отчеты, при помощи которых будут сопоставляться различные показатели и отображаться результаты сравнения. Алгоритмы перекрестного контроля показателей можно настроить и в кубе (встроенный контроль). А наличие функций Drill Down и Drill Through позволяет мгновенно углубиться в любой показатель, чтобы исследовать, на основании каких исходных данных он сформирован. Таким образом, риск возникновения ошибок будет минимизирован.

Дарья Судьбина: Качество и ценность данных, которые видит конечный пользователь у себя на экране в виде набора аналитических инструментов (таблиц, графиков, спидометров), напрямую зависит от источника, на основании которого формируются отчеты. Несмотря на то что большинство современных BI-решений предлагает встроенные инструменты ETL (Extract-Transform-Load), наиболее правильным подходом при их внедрении является создание хранилища данных, а не подключение нескольких источников напрямую к инструментам BI-системы. С одной стороны, это неизбежно толкает компанию на инвестиционные затраты по созданию ХД, с другой — позволяет провести контроль загружаемой информации, которая в дальнейшем используется для анализа. Данные из первоисточника (например ERP-системы), к сожалению, не всегда могут быть полезны, поскольку в базе иногда хранится много невыверенных и некорректно учтенных документов, которые при попадании в аналитический массив существенно искажают «картину мира». Поэтому при формировании хранилища и дальнейшем его наполнении можно проводить многоуровневую проверку качества данных: первый раз — — при загрузке из хранилища в кубы для при загрузке данных в хранилище, а второй анализа.

Максим Балаш: Для обеспечения необходимого качества данных для конечных пользователей BI-системы в составе хранилища данных целесообразно выделять два сегмента — «оперативный» и «выверенный». В оперативном сегменте ХД собираемые данные должны проходить несколько стадий проверки. Первичная проверка включает в себя контроль целостности исходных данных, проверку изменений в классификаторах и справочниках, проверку ключевых контрольных значений. Окончательная стадия проверки должна включать более сложные процедуры логического контроля данных и метаданных, анализ сопоставимости и непротиворечивости загружаемой информации.

За результаты всех этапов контроля должен быть определен ответственный администратор системы, который принимает решение о «допуске» данных в «выверенный» сегмент хранилища.

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

— Эффективность системы в конечном итоге во многом зависит от квалификации пользователей: в неумелых руках даже самый замечательный инструмент пользы не принесет. Как оптимально организовать обучение пользователей?

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

Петр Лещенок: Для обучения пользователей в компании необходимо создать центр компетенции по BI-системе с привлечением наиболее квалифицированных специалистов. Являясь носителями знаний, они будут обучать и консультировать других пользователей BI-системы.

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

Павел Бритов: Причем полезно еще в самом начале проекта провести семинар с пользователями, чтобы они сами на примерах смогли понять возможности системы и сформулировать свои требования уже в терминах BI. Это положительно влияет на весь ход работ.

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

Максим Балаш: Очное обучение обеспечивает непосредственный контакт с преподавателем, что позволяет оперативно уточнить информацию, переспросить, обсудить различные варианты решения той или иной изучаемой задачи.

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

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

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

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

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

Петр Травкин: Еще хотелось бы отметить, что сейчас поставщики BI-систем стремятся сделать систему как можно «дружелюбнее» к пользователям, не являющимся специалистами в области анализа данных. Более того, сегодня существуют мощные, но одновременно простые в использовании решения, которые не требуют специального обучения для бизнес-пользователей. Благодаря такому подходу некоторых поставщиков отдача от использования системы начинает ощущаться с первых минут работы с ней.

— BI-системы теснейшим образом связаны с бизнес-процессами компании. Необходима ли в связи с этим доработка и модификация BI-решения под особенности бизнес-процессов компании? Как можно оптимизировать (с организационной точки зрения) этот процесс?

Максим Балаш: Наиболее простые BI-решения, связанные, как правило, с обеспечением доступа к данным, построением несложных запросов и визуализацией их результатов и не требующие глубокого погружения в бизнес-логику заказчика (а значит, и не содержащие специализированных алгоритмов, методик и моделей), могут быть внедрены и без доработки. В этом случае достаточно правильно настроиться на существующие источники данных и предоставить необходимый перечень инструментов бизнес-аналитики.

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

Павел Бритов: На мой взгляд, BI-решений «под ключ» нет и быть не может. Задача проекта по внедрению BI — создать не систему, которая меняться не будет, а условия для самостоятельного решения конечными пользователями новых и новых возникающих аналитических задач. В этом смысле BI-система всегда меняется, приспосабливаясь к особенностям изменчивого бизнеса. Даже если взять область, которая, на первый взгляд, легко типизируема (например отчетность по рискам для банков, вроде бы регламентированную базельскими соглашениями), каждое конкретное внедрение — это изменения в методологии, иной состав и качество исходных данных, разные источники информации и прочее.

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

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

Николай Кацан: Доработка BI-решения потребуется в том случае, когда система внедрена без учета возможного развития бизнеса. Концепция Organic Enterprise, популярная на заре классических BI-систем, выделяла несколько шагов внедрения и развития решения. Так вот, одним из четырех элементов этой концепции было наблюдение за развитием системы и планирование изменений.

Корректно внедренная и поддерживаемая система развивается вместе с бизнес-процессами компании и не вызывает информационных коллапсов в ИТ-ландшафте.

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

Павел Бритов: Типичная ошибка при инициировании и проведении BI-проектов — попытка создать результат теми же методами «большого проекта», которыми внедряются системы автоматизации, ERP и СУБД. Для BI-системы практически невозможно написать техническое задание на длительный период времени. Пока будет проходить обследование бизнес-процессов, сбор требований и разработка, изменятся условия существования системы, перед бизнесом встанут новые задачи, которые придется в авральном режиме решать. Выход из этого только один — внедрение платформы BI, формирование среды оперативного реагирования на новые запросы бизнеса, создание системы короткими итерациями (длительность одного проекта BI не должна превышать 6 месяцев, а лучше ограничить объем работ до 3–4 месяцев). При этом важно, чтобы структура хранилища данных и используемая модель данных имели запас возможностей и опирались на чужой опыт, как указывалось выше.

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

Максим Балаш, заместитель генерального директора по производству компании «Прогноз»,

Павел Бритов, директор по развитию бизнеса компании Irbicon,

Ольга Горчинская, ведущий консультант по хранилищам данных и аналитическим системам компании Oracle CIS,

Николай Кацан, руководитель BI-практики компании «SAS Россия/СНГ»,

Петр Лещенок, начальник департамента перспективных проектов корпорации «Галактика»,

Дмитрий Романов, директор по развитию технологий информационного менеджмента компании «АйТи»,

Дарья Судьбина, руководитель проектов практики BPM-решений компании NaviCon Group,

Петр Травкин, руководитель проектов по развитию бизнеса компании «ФБ Консалт».