Управление проектом Хранилища данных

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

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

С какими же факторами риска сталкиваются организации при внедрении ХД?

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

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

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

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

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

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

Состав рабочей группы проекта

Участники

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

Опыт менеджера проекта

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

Корпоративное представление и назначение ХД

От менеджера проекта требуется значительную часть времени посвящать  формированию полного и исчерпывающего понимания корпоративного представления (corporate vision), включающего:

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

Этот метод дает надежную основу для управления жизненным циклом проекта,  принятием решений и такими операциями, как:

• расстановка приоритетов,
• определение масштабов,
• сбор требований,
• рассмотрение возможностей внедрения.

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

Методология управления проектом

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

На этапе планирования менеджер проекта должен донести до  участников и заинтересованных сторон следующие моменты:

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

Требования к Хранилищу

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

Неудивительно, если бизнес-требования кардинально поменяются в какой-то момент. Клиент может со временем увидеть все совсем в ином свете. Рекомендуется привлекать к сбору требований представителей отделов разработки и тестирования. Для успеха проекта очень важно задействовать всех участников на самой ранней стадии.

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

Мониторинг состояния проекта и информация о его реализации

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

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

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

Проверка и оценка

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

Лучше всего тщательно оценить преимущества и последствия этих процедур, прежде чем выбирать подход. Проверка и оценка требуют немалых средств и ресурсов, иногда расходы на эти операции составляют от 10% до 30% всей стоимости проекта. С другой стороны, затраты на исправление ошибок, обнаруженных после внедрения, могут достигать и 200%. Проверка и оценка помогут:

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

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

Проверка концепции

Проверка концепции должна продолжаться не более 30-45 дней и включать в себя:

• внедрение сокращенной версии разделенной на компоненты архитектуры Хранилища в одной технической среде, где применяются процессы извлечения, продвижения, проверки, очистки, консолидации и предоставления данных;
• использование компонентов программного обеспечения ХД, таких как ETL-инструменты, BI, моделирование данных;
• многоуровневую инфраструктуру для базы данных, среднего слоя, Web-сервисов и клиентских компонентов;
• реализацию сокращенной стратегии сбора данных из одной или двух исходных систем;
• реализацию сокращенной стратегии предоставления данных с использованием некоторой прозрачной предметной области;
• применение разработанных стандартов и процедур для моделирования данных, разработки и администрирования ETL, а также разработки и управления BI;
• реализацию сокращенных стратегий проверки программных средств, поддержки и подготовки, а также соответствующей стратегии функционирования и технического обеспечения.

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

Программа ХД

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

• полная стоимость владения (Total cost of ownership — TCO) растет;
• технические средства плохо настроены;
• показатели уровня обслуживания не контролируются;
• исполнительное руководство и заинтересованные лица недовольны результатами и эффективностью.

Тщательно разработанные стратегии помогают разрешить эти затруднения и сформировать основу для наиболее удачной программы ХД.

Стратегии должны охватывать правила и процедуры для проверки, управления, улучшения и развития Хранилища.

В частности, к ним относятся:

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

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

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

На рис. 1 показан цикл внедрения ХД. Каждая фаза представляет собой новый цикл.

Рис. 1. Жизненный цикл разработки системы

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

Проверка успешности проекта

Можно сказать, что продукт достаточно качественный и дает хорошие результаты для бизнеса, если:

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

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

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

Публикации

1. Управление проектом Хранилища данных (Data Warehouse Project Management), Тим Фьюри (Tim Furey).

2. Управление проектом Хранилища данных (Data Warehouse Project Management), Кен Пол (Ken Pohl).

3. Каковы основные факторы риска в проекте внедрения ХД? (What are the major risk factors in a data warehouse project implementation? ).

Автор: По материалам зарубежных сайтов