Пристальный взгляд на проблемы хранилищ данных

Специалисты по внедрению хранилищ данных рассматривают типичные причины срыва
проектов.

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

Создание хранилища данных требует серьёзного рассмотрения всех сопутствующих рисков и выработки способов «противодействия» с целью сокращения вероятности неудачного завершения проекта.

По мнению Стива Барлоу (Steve Barlow), одного из основателей ассоциации хранилищ данных для здравоохранения (Healthcare Data Warehousing Association), на практике наиболее часто встречаются следующие причины провала проектов.

1.     Участие и поддержка со стороны руководства недостаточны или отсутствуют

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

2.     Конечные пользователи не вовлечены в проект

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

3.     Невозможность объять необъятное

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

4.     Отсутствие убедительного бизнес-императива

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

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

Кроме того, по оценке Пола Тимара, есть ряд и других причин, почему проекты построения хранилища данных могут оказаться неуспешными.

1.     Не определены критерии оценки успеха

Сама по себе осведомлённость о бизнес-целях не гарантирует успеха. Каждая конкретная бизнес-цель должны быть измерима. Если результат невозможно оценить, неизбежны сложности с расчетом расходов, а затем и проблемы при следующей реструктуризации проекта (обычно она происходит каждые 3-5 лет).

2.     Внедрение хранилища данных конвейерным способом

Сверхспециализация становится серьёзной проблемой в сегодняшних проектах. В то время, как отрасли с более долгой историей хорошо осведомлены о негативных последствиях чрезмерного разделения труда и принимают меры, чтобы компенсировать их, в случае с хранилищами данных похоже, что  история повторяется заново. Провал грозит любому проекту, каждый участник которого вносит свой вклад, применяя узкий диапазон навыков и не видя общей картины, либо вовсе не принимая её во внимание. Это очень популярное решение – создавать конкретные роли, чтобы сократить расходы, однако оно крайне редко окупается. Затраты просто перемещаются из начала в конец проекта, где удивительным образом умножаются. Здесь приходится нанимать профессионалов, чтобы исправить положение дел.

3.     Построение оперативного склада данных вместо хранилища данных

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

4.     Игнорирование важных ролей при формировании проектной группы

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

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

5.     Непонимание целевой архитектуры и используемых инструментов

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

6.     Непорядочность в бюджетном вопросе и атмосфера притворства

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

Публикации

1. Стив Бэрлоу (Steve Barlow). Шесть причин, почему хранилища данных в медицинских учреждениях терпят неудачу (6 Reasons Why Healthcare Data Warehouses Fail). 20 ноября 2014 г.
2. Пол Тимар (Paul Timar). Семь смертных грехов создания хранилищ данных (7 Deadly Sins of Data Warehousing). 18 ноября 2014 г.

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