Как сделать BI-проект менее рискованным

Многие BI, несмотря на неплохой проектный менеджмент, терпят крах. Успешные проекты, связанные с business intelligence и хранилищами данных, имеют по крайней мере одну общую характеристику - явный учет возможного риска. BI-проекты пронизаны рисками, начиная с проблем, связанных с качеством данных, и кончая значением полученной аналитической информации, которое ниже ожидаемого. Эти угрозы часто приводят к приостановке всего проекта. Проект, над которым я работал несколько лет тому назад, убедил меня в том, как важно уменьшать риски. Компания владела 20 совершенно разными торговыми предприятиями в разных странах мира. Ей требовалось получать точную отчетность о текущих продажах, а также вести хронологическую историю изменений в партиях заказов на различных предприятиях.

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

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

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

Используйте спиральный подход

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

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

В нашем примере с 1 млн. долларов в основе проекта лежал метод, использующий документацию. Компания сначала разработала очень подробные и профессиональные документы, и тем не менее при разработке она столкнулась с проблемами качества данных. Если бы она выбрала подход, рассматривающий риск, то проблемы преобразования и интеграции данных выявились бы заранее, что позволило бы рассмотреть альтернативные решения.
BI-проекты неизбежно связаны со спорными или неизвестными моментами, которые необходимо разрешить, прежде чем появится уверенность в успехе. Подходы RBA (rules-based audit) и POC (proof of concept) представляют собой методы анализа рисков и осуществляются на втором участке спирального подхода.

Выявите риски, прежде чем делать инвестиции

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

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

Осуществление анализа RBA/POC - это процесс, состоящий из следующих пяти шагов:

1. Идентифицировать потенциальные риски и выбрать метод анализа рисков (RBA и/или POC), чтобы определить масштаб и диапазон потенциальных проблем и пролить свет на возможные альтернативы.

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

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

4. Выполнить RBA-анализ. Сначала определите бизнес-правила, необходимые для преобразования исходных данных в любую целевую структуру, которая потребуется для последующего анализа. Как только правила будут определены, вы сможете попытаться построить целевые таблицы. Технология (платформа, программное обеспечение и т. п.), используемая для этих структур, не имеет значения. Важно только одно, могут они быть построены или нет. Вопросы технологии - это задача POC-теста. Если предположить, что целевые таблицы могут быть построены, то последним шагом станет проверка результатов, то есть самих данных. Сможете ли вы агрегировать продажи, сгруппированные по заказам и продуктам за последний квартал, и получить точный результат?

5. Выполнить полномасштабный POC-тест. После того как на основе RBA-анализа вы убедитесь, что можете создать целевые таблицы, необходимо произвести их линейное увеличение. Выберите достаточный объем реальных производственных данных. Установите среду тестирования. Если вы не можете использовать для POC-теста реальные условия, в которых происходит обработка данных, то следует эмулировать их как можно точнее. Создайте метрики, поддающиеся проверке. Затем вам нужно будет измерить производительность за определенное время и потраченные ресурсы платформы, включая CPU, память, дисковое пространство и т. п. Проверьте согласование результатов теста POC с результатами RBA. Полученные целевые данные должны соответствовать результатам RBA.

***

Игнорировать риски при осуществлении BI-проектов безрассудно и наивно. Невозможно полностью избежать рисков, но можно включить в сам проект такие методики анализа рисков, как RBA и POC. Используемые вместе, эти методики дадут вам четкое понимание тех проблем, которые встретятся впереди, чтобы вы смогли рассмотреть альтернативы или пересмотреть вашу стратегию. Методики RBA и POC не только эффективны, но и дешевы по сравнению с полномасштабным проектом.