Оглавление

Введение

Общие подходы к организации работы проектной группы внедрения BI решений на SAP HANA

Success-Практика использования продуктивных подходов к организации работы

Внедрение аналитических интерфейсных отчетных и управляющих форм на проекте ПАО «Газпром» ИУС Т 2

Проект внедрения отчетности BW on HANA на проекте ПАО Мегафон

Заключение

Введение

В последнее время все больше и больше компаний производят миграцию своих корпоративных ERP и BI систем на БД SAP HANA. В данный момент компания SAP предлагает поддержку следующих продуктов на основе базы данных SAP HANA:

• SAP BW on HANA,
• BW4HANA,
• BPC4HANA,
• S4HANA.

Опыт внедрения нескольких проектов BI систем полного цикла на БД HANA показал, что требуются учитывать не только технические аспекты интеграции, но и аспекты, связанные с управлением проектами и организации работы большой проектной команды. Миграция на БД HANA влечет за собой существенное изменение в особенностях моделирования и администрирования объектов и процессов переноса данных. В данной статье описаны как известные, так и новые прикладные подходы по управлению командой на примере реализации двух проектов по внедрению BI систем на БД SAP HANA:

1) внедрение информационной управляющей системы по транспортировке газа и газового конденсата ПАО «Газпром» (ИУС Т 2);

2) внедрение проекта BW on HANA в компании «Мегафон». Сначала, будут описаны общие подходы в организации работы проектной группы для уменьшения проектных рисков, затем будут описаны прикладные подходы, примененные и показавшие свою эффективность на практике.

Общие подходы к организации работы проектной группы внедрения BI решений на SAP HANA

В результате анализа опыта организации работы проектной команды по внедрению решений на базе SAP HANA, были определены как наиболее продуктивные следующие подходы к управлению группы консультантов:

• Разделение работ на максимально независимы блоки – каждый консультант должен быть ответственен за отдельный блок объектов, чтобы вести работу максимально самостоятельно и без посторонней помощи;
• Помимо ведения общей и стандартной проектной документации (техническое задание, регламент разработки, и т.д.) рекомендуется составить отдельный и наиболее краткий документ «Рекомендации для разработчика», в котором следует кратко перечислить основные правила разработки объектов HANA (использование фильтров, входных параметров, агрегаций, рекомендуемое число «нодов» (nodes) в одной Calculation View, использование различных типов Join в Calculation View, правила использования базовых Calculation View и хранимых процедур, и т.д.), что позволит существенно уменьшить время адаптации новых консультантов на проекте, в особенности тех, кто до этого не имел опыта разработки на SAP HANA;
• Разработку многократно используемых объектов SAP HANA типа Calculation View, Attribute View, и хранимые процедуры следует поручать только самым опытным консультантам уровня K3 и K4;
•  Все объекты SAP HANA (Calculation View, Attribute View, и хранимые процедуры) должны вестись в специальном реестре разработок с указанием версионности, ответственного лица, входных параметров, и наименования инфо-провайдера или интерфейса, в которых данный объект используется;
• Все «ноды» Calculation View вида Aggregation, Rank, и Projection (если внутри присутствует расчетное поле «Calculated Column») должны быть снабжены дополнительным комментарием с указанием цели использования и ссылками на техническую документацию где это необходимо – выполнение данной рекомендации поможет снизить трудозатраты на обследование Calculation View при передаче объекта новому консультанту на проекте;
• Если объект вида Calculation View используется для моделирования инфо провайдеров BW или служит источником данных для интерфейсных отчетных форм, и других приложений, то в общем описании Calculation View должна присутствовать ссылка на конечный объект. Это позволяет существенно сэкономить время обследования функциональной области разрабатываемой информационной системы для тех консультантов, которые заменяют основного консультанта, либо только вышли на проект.

Success-Практика использования продуктивных подходов к организации работы

Внедрение аналитических интерфейсных отчетных и управляющих форм на проекте ПАО «Газпром» ИУС Т 2

Проект «Информационно-управляющая система по транспортировке газа и газового конденсата (этап 2)» ИУС Т 2 являлся достаточно сложно структурированным проектом с большим числом участников, подрядных организаций, и набором различных ролей. Набор ролей на проекте был следующим:

1) Консультанты SAP BI уровня К2 и К3 (Business Objects);

2) Консультанты и архитекторы SAP HANA (уровни К3, К4);

3) Web-разработчики (JavaScript UI5 разработчики); 4) дизайнеры и методологи;

5) Руководители проектов;

6) стажеры.

Разрабатываемая система представляла собой набор логически связанных между собой UI5 интерфейсных форм, источником данных для которых являлись объекты SAP HANA типа Calculation View. Через элементы UI5 интерфейсных форм пользователям предоставлялась возможность напрямую вносить изменения (добавление, удаление, и изменение записей) в объекты БД HANA. Следование следующим подходам и рекомендациям вместе с подходами, описанными выше в управлении группой консультантов и разработчиков, обеспечило значительный прирост производительности и позволило сдать работы в срок в условиях крайне ограниченного времени, а также сэкономить до 30% трудозатрат, относительно ожидаемых.

Драйверы эффективности:

• В процессе разработки показало свою большую эффективность использование расширенного альбома интерфейсных форм (РАИФ), на которых отражались следующая информация:
  • 1) общий дизайн интерфейсной формы со всеми элементами SAP UI5 интерфейса;
  •  2) если в интерфейсной форме присутствовала панель для просмотра данных, источником для которой являлась HANA Calculation View, то на ней наглядно отражалась на тестовой выборке данных (при возможности) грануляция данных, иерархии, использование входных параметров (для расчета панели),  условные форматирования, ранжирования, и т.д.;
  • 3) для вызывающих HANA API процедуры элементов UI5 интерфейса в интерфейсной форме специально писались комментарии какая процедура должна вызываться и что она должна делать в контексте конкретной формы;
  •  4) вся дополнительная логика на интерфейсы описывалась либо дополнительными комментариями внизу формы, либо дизайнерам и методологам ставилась задача по созданию дополнительных интерфейсных форм.
• Такой подход позволил работать и осуществлять деловые коммуникации различным участникам проекта в едином и понятном информационном поле и существенно снизил трудозатраты по согласованию и интеграции различных блоков разрабатываемой ИС.
• Разработка любого интерфейса начиналась с разработки РАИФ.
• Разработку любого РАИФ необходимо организовывать в плотной связке методологов и дизайнеров, чтобы учесть все интерфейсные и бизнес детали (обычно на стандартный РАИФ, состоящий из 10-15 интерфейсных форм, необходимо зарезервировать 2-3 недели работы методологов и дизайнеров, лучше делать это в то время, когда разработчики и консультанты сдают в тестирование разработки по уже существующим РАИФ, чтобы у консультантов