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

• Отсутствие системной гибкости
• Слишком сложная, особенно SQL -> чрезвычайно большое количество отчетов
• Нехватка централизации
• Низкая способность интегрировать данные из различных источников
• Быстрое снижение производительности
• Неясная логика отчетности

Более того, ваши данные не чисты и прозрачны, а грязные, как и сама система OLTP. Взгляните что это все значит в light-версии (это только отчеты, начинающиеся на А, всего 100+ отчетов):

Это огромное количество SQL-отчетов обычно ведет к невидимой «армии гномов», которая тяжело работает над сохранением жестко закодированной логики каждого отчета от самоуничтожения. В результате, компании приходится тратить огромное количество денег на «гномов», на «воду против ежедневных пожаров» и еще больше денег на сладости для злых клиентов, которые находят ужасные ошибки (как например та, которую мы нашли – расчет миллиардов потенциальной экономии, ведущей к неверным рекомендациям и т.д.) Все, что было сверху мы заменили 3(!) MDX-отчетами с стильными графиками, как этот:

или этот: 

Как это сделать вам?

Начните с поиска первоклассного BI Architect, который основал в нашей компании хранилище данных BI на основе Kimball. Но это не единственное, что вам стоит рассмотреть – это не спасает вас от плохого кода и плохого контроля версий (это ведет к нулевой системной гибкости). Хоть наша BI система полностью загружена на TFS сервер и может спокойно быть перемещена на любой новый сервер одним щелчком мыши:

• SQL Server Database Project  позволяет выполнять плавную разработку схемы  хранилища данных, добавочное развертывание, контроль потери данных и быстрое восстановление
• SSIS Projects утилизирует Execute Package Task   в раздельные потоки используя Master Packages. Это в том числе отключает горизонтальное масштабирование и эффективное распараллеливание, потому что каждый пакет Master может быть перемещен на другой сервер.   В добавок, мы следуем нескольким базовым принципам, которые позволяют нам объединить любую сложную логику в ту же схему:
• Избегайте хранимые процедуры. Используйте их только в случай больших вычислений, который не могут быть выполнены через индексированную таблицу или представления.
• Используйте представления для загрузки данных в DWH. Избегайте очистку данных в SSIS
• Избегайте большого количества кода SSIS. Гораздо проще будет поддерживать вид SQL чем пакет SSIS в веб-форме.
• Сосредоточьтесь на T-SQL.  Избегайте C# насколько это возможно
• Предотвратите потерю данных во время ETL, если что-то пойдет не так
• SSAS проекты они в Африке SSAS. Однако, разбейте логику SSAS на несколько частей, особенно, если вам необходимо сократить время ответа на запрос.
• 99% MDX в инструментах отчётности значительно сокращает количество необходимого кода.  После того, как базовые отчеты готовы, большинство других кодов - это просто модифицированный копи паст.  Так же хотелось бы отметить, что серверы MD-OLAP гораздо быстрее, чем Datawarehouse RDBMS серверы. И еще один важный принцип от Александра: НЕ ИСПОЛЬЗУЙТЕ МНОГО SSRS. Это значит, используйте MDX где это только возможно, по максимуму. Вычисляйте итоги, промежуточные итоги, сложные выражения в MDX, благодаря этому вам не придется обновлять 100+ отчетов, если изменится бизнес-логика – вы только обновите MDX на необходимом уровне.

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

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

Заключение

Более чем 250 отчетов были преобразованы в примерно 50 отчетов, 35 из них сейчас доведены до внешних клиентов и могут начать приносить прибыль в скором времени.

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

Перейдите от кое-как сделанного отчетного решения к масштабируемой архитектуре предприятия на основе данных системы принятия решений. Отличное сокращение общей стоимости владения и количества инцидентов: от 80/20 до 10/90, почти 5/95 в расписании бизнес-аналитика. Больше никаких крохотных гномов за автоматизацией.

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

(Перевод статьи Георгия Зубриенко)

No Comments