Проблема отсутствия исторических данных для отчетов по проектам
Microsoft Project Server (MSPS) поддерживает большое количество инструментов для отчетности и бизнес-аналитики. Это PerformancePoint Services, Excel Services и Visio Services в составе SharePoint, а также Reporting Services (SSRS) и Analysis Services в составе Microsoft SQL Server. В качестве основного варианта источника данных для всех указанных систем отчётности используется специально предназначенная для этих целей база данных Reporting.
Однако при использовании данных из БД Reporting, невозможно построить отчёт, представляющий информацию о проектах в повременном виде, поскольку MSPS не хранит историю изменения проектных данных, а хранит лишь данные, актуальные на текущий момент времени. К примеру, эта возможность может быть необходима менеджеру проекта или иным заинтересованным лицам для получения динамики (тренда) таких показателей, как:
- Процент завершения проекта;
- Сроки прохождения отдельных контрольных точек проекта;
- Сроки выполнения проекта в целом;
- Отклонения перечисленных показателей от базовых значений.
Конечно, для определения тренда можно использовать простое сравнение фактических показателей с их значениями в базовых планах, но у этого способа есть ряд существенных минусов. Во-первых, количество возможных базовых планов ограничено, а, во-вторых, формирование базовых планов никак не автоматизировано и выполняется менеджером проекта в ручном режиме. Соответственно, есть вероятность отсутствия какого-то предусмотренного регламентом базового плана, что может привести к появлению некорректных данных в отчёте. Также проблематично синхронное создание базовых планов по нескольким проектам, что позволило бы строить отчеты по динамике целого портфеля проектов.
Решение на базе Project Server 2010 и Reporting Services
Компания Brise решила описанную проблему в рамках разработки системы отчетности для крупной нефтедобывающей компании. И мы готовы рассказать об основных идеях нашего решения.
Естественно, нам пришлось отказаться от непосредственного использования штатной БД Reporting. Мы создали специальную историческую базу данных, в которой аккумулируется вся история изменений проектных данных, необходимых для построения основных аналитических отчётов. Специальный сервис по расписанию копирует эти данные из Reporting, пополняя историческую БД. За счет использования промежуточной БД также может быть достигнута масштабируемость – возможность консолидировать данные из нескольких серверов Project.
Именно эта база данных используется в качестве источника данных для системы отчетности. При этом мы полагаемся на один из наиболее гибких и функциональных инструментов отчётности — SQL Server Reporting Services (SSRS), который позволяет создавать функциональные статические (без возможности редактирования пользователем) отчёты.
Стоит отметить, что описанная проблема также может быть решена с помощью OLAP-кубов. Однако, на наш взгляд, в данном случае использование OLAP выигрывает по производительности у обычной SQL-базы лишь при чрезвычайно больших объёмах данных. При этом осложняется модификация данных в хранилище и потребуются большие затраты на поддержку и обслуживание системы отчётности в целом.
Пример отчета: динамика изменения контрольных точек
Выше приведен пример отчёта, содержащего исторические данные, аналогичного созданному нами в рамках проекта отчётности для нефтедобывающей компании. В отчёте отображается динамика дат прохождения контрольных точек проекта (КТ). Функция на графике представляет собой зависимость даты прохождения КТ (Ось Y) от даты на которую дата прохождения актуальна (Ось X). В табличной части отчёта приведены названия контрольных точек и вспомогательные индикаторы, сообщающие статус КТ на текущую дату: пройдена ли КТ и отстаёт ли она от базового плана.
На данном примере мы видим, что у обеих контрольных точек проекта возникло запаздывание дат их прохождения, но, несмотря на это, они всё ещё не отстают от базового плана, а значит, будут пройдены вовремя.
