Бесплатный курс Oracle Hyperion Planning

http://ivan-shamaev.ru/oracle-hyperion-planning/ - платные консультации по Hyperion Planning


Бесплатный курс Oracle Hyperion

Planning. Приложения и бюджетирование

Для начала изучения системы Oracle Hyperion Planning я хочу порекомендовать

ознакомиться со следующими сферами знаний, дабы упростить себе восприятие

материала:

- OLAP-технология;

- SQL запросы;

- MDX запросы;

- Трехуровневая архитектура web-приложений (WebLogic,IIS,Database);

- Основы построения и описания бизнес-процессов;

- Основы бюджетирования и бухгалтерского учета.

Агрегация – процесс сбора данных из нижестоящих объектов и их агрегирования в

вышестоящие. После ввода или загрузки данных в подчиненные объекты выполняется

консолидация с целью суммирования данных по предприятию. Термины «агрегирование»

(aggregation) и «сведение» (roll-up) также означают процесс консолидации.

Администратор – специалист, инсталлирующий и сопровождающий систему, включая

создание учетных записей пользователей и обеспечение защиты информации.

Аналитическое направление – объект базы данных, характеризующий определённый

аспект анализируемой предметной области и содержащий информацию, объединенную

единой тематикой. Например, база данных Sample Basic содержит такие аналитические

направления, как Time (период), Accounts (счета), Product (продукция), Market (рынок

сбыта, т.е. регион).

Бизнес-правило – логическое выражение или формула, созданные в приложении, чтобы

получить ожидаемый набор конечных данных.

Бюджет – количественное выражение плана (чаще всего в денежном выражении)

деятельности Представительств, филиалов, подразделений ЦА или Предприятия в целом

на определённый период времени.

Вспомогательная информация – количественное выражение плана (чаще всего в

денежном выражении) деятельности Представительств, филиалов, подразделений ЦА или

Предприятия в целом на определённый период времени.

Данные – значения (денежные или неденежные), связанные с пересечением по запросу.

Детализация – процесс постепенного вывода подробных данных относительно

выбранного направления путем развертывания родительского элемента для отображения

дочерних элементов. В результате развертывания могут быть выявлены иерархические

взаимосвязи, например взаимосвязи между родительским и дочерним объектами,

родительским и дочерним счетами, а также между суммирующим периодом и базовым

периодом времени. Например, в результате детализации могут быть выявлены

иерархические взаимосвязи между годом и кварталами или между кварталом и месяцами.

Дочерний элемент-элемент, имеющий над собой родителя в схеме базы данных. У

дочернего элемента могут быть элементы-братья, находящиеся с ним на одном уровне в

схеме базы данных.

Загрузка данных – процесс заполнения базы данных данными. В результате заполняются

значения ячеек, определяемые структурой схемы базы данных.

Иерархия – набор многомерных взаимосвязей в схеме, часто создаваемый в схеме

данных. Например, родительские элементы, дочерние элементы и поколения

представляют иерархию.

Источник данных – внешние данные, например текстовый файл, электронная таблица

или база данных SQL, загружаемые в базу данных Essbase Analytic Services.

http://ivan-shamaev.ru/oracle-hyperion-planning/


http://www.cfin.ru/itm/olap/cons.shtml

http://sql-ex.ru/

http://habrahabr.ru/post/66356/

http://ivan-shamaev.ru/web-architecture-design/

http://iiba.ru/business-process-modeling-and-management/

http://ivan-shamaev.ru/planning-and-budgeting/

http://online-buhuchet.ru/shag-1-osnovy-buxucheta/



Консолидация – см. Агрегация

Корректировка – внесение изменений в планы и бюджеты Предприятия, обусловленное

возникновением отклонений в условиях и результатах деятельности Предприятия по

сравнению с запланированными.

Метаданные – структурные элементы приложения, которые описывают и хранят данные.

Многомерность означает преобразование двумерных данных, распределенных по полям

и строкам, в многомерный куб. Грани куба представляют собой аналитические

направления. Аналитическое направление – это структурный элемент куба, определяемый

с помощью метаданных. Метаданные также отражают понимание данных пользователем.

Внутри многомерного куба информацию можно одновременно видеть в различных

аналитических направлениях (продажи по месяцам, по продуктам, по всем рынкам).

Например, все месяцы, кварталы, года и т.д. составляют аналитическое направление типа

“время”; все города, регионы, страны и т.д. составляют “географическое” направление.

Аналитические направления обеспечивают простой и наглядный способ организации и

отбора данных для их извлечения, исследования и анализа.

Отчет – макет, динамически определяющий содержимое и форматирование отчета.

Заполнение данными форм отчета происходит после запуска отчетов.

Панель инструментов – панель с пиктограммами, представляющими команды системы.

Пиктограммы используются для быстрого вызова команд меню.

Планировщик – специалист, который может вводить, передавать, а также просматривать

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

данных, выполнять бизнес-правила, а также использовать надстройку электронных таблиц

Hyperion Planning.

Поколение – термин, описывающий положение элемента в иерархии аналитического

направления. Поколения считаются сверху вниз.

Потомок – любой элемент, находящиеся в схеме данных ниже родителя. Например, в

аналитическом направлении, содержащем данные по годам, кварталам и месяцам, «второй

квартал» и «апрель» будут потомками элемента «Year».

Предок – элемент, для которого существуют элементы более низкого уровня. Например, в

аналитическом направлении, содержащем данные по годам, кварталам и месяцам,

элементы «первый квартал» и «2001 год» будут предками элемента «апрель».

Приложение – взаимосвязанный набор направлений, элементов направлений и типов

планов, связанных с базой данных и используемых для проведения анализа и/или

формирования отчета.

Псевдоним – альтернативное название направления, элемента или описания.

Cрез данных – функция, которая позволяет работать с элементами направлений, не

назначенными строке, столбцу или оси страниц. Например, можно назначить измерение

валюты в срезе данных и выбрать элемент евро. После выбора среза данных в форме

ввода данных, все данные в форме отображаются в евро.

Страница – вывод информации в таблице чаще всего предствленной осью Z, либо

выпадающий список.

Счет – направление, представляющее собой учетный контейнер, указывающий на

местоположение и первичную природу данных.Создается структура счетов, позволяющая

составителям бюджетов вводить данные по всем планируемым позициям до нужного

уровня детализации.

Уровень – термин, описывающий положение элемента в иерархии аналитического

направления. Уровни считаются снизу вверх.

Форма ввода – окно с сеткой, в котором пользователи могут вводить данные в базу в

окне Web-браузера. Отдельные значения элементов направлений постоянны, что

позволяет пользователям видеть данные в определенном контексте.

Центр ответственности – представительство, филиал, подразделение ЦА, полностью

отвечающее за величину, целесообразность и экономическую обоснованность затрат





(доходов).

Элемент – отдельный компонент, составляющий аналитическое направление.

Ячейка – единица данных, представляющая собой пересечение направлений в

многомерной базе данных; пересечение строки и столбца в рабочем листе.

Hyperion Essbase – OLAP–система, предназначенная для создания широкого спектра

аналитических приложений и являющаяся основой платформы бизнес–интеллекта

(Business Intelligence, BI). Благодаря современной технологии аналитической обработки

данных в режиме реального времени (On–Line Analytical Processing) Hyperion Essbase

позволяет структурировать и представлять данные в разрезе различных аналитических

направлений. В результате Hyperion Essbase превращает данные в ценную информацию,

которая помогает руководителям принимать более обоснованные решения.

Hyperion Planning – интернет-ориентированное специализированное решение для задач

планирования и бюджетирования, основанное на многомерном представлении

экономической информации и организации эффективного взаимодействия участников

бюджетного процесса.

Smart View – надстройка для электронных таблиц, которая позволяет формировать

рабочие листы Excel для ввода, форматирования, анализа данных приложения Hyperion

Planning.

Oracle Hyperion Planning это решение для планирования, бюджетирования и

прогнозирования с помощью Microsoft Excel и Web, обеспечивающее интеграцию

процессов финансового и операционного планирования. Hyperion Planning предоставляет

возможности для глубокого анализа бизнес-операций и их влияния на финансовые

результаты компании с помощью тесно интегрированных моделей финансового и

операционного планирования.

Hyperion Planning предлагает мощный функционал управления рабочими процессами,

включая уведомления по E-mail, оповещения и списки задач, позволяя пользователям

отслеживать текущие изменения планов и бюджетов и сообщать об этом. Помимо

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

узкие места в производительности, проводить анализ «что-если…» и тестирование

сценариев.

В своем составе продукт имеет две преднастроенные модели: Oracle Hyperion Workforce Planning позволяет Вам быстро и эффективно планировать

кадровую статистику, зарплату и компенсации в масштабах всей организации.

Автоматически соединяясь с БД кадров, данная система помогает Вам оценить влияние

кадровых решений на бизнес компании в режиме реального времени.

Oracle Hyperion Capital Asset Planning позволяет Вам планировать существующие и

новые активы, их использование, транзакции и амортизацию одновременно анализируя их

влияние на такие показатели, как уровень прибыли, балансовый отчет и финансовые

потоки.





Структура модели



http://ivan-shamaev.ru/wp-content/uploads/2013/05/structure_of_models.png

http://ivan-shamaev.ru/wp-content/uploads/2013/05/return_on_assets.png



Oracle’s Enterprise Performance Management



http://ivan-shamaev.ru/wp-content/uploads/2013/05/oracle-epm-system.jpg



Oracle EPM 11.1.2.1 – в разрезе бизнес процессов

Oracle Essbase – Универсальный OLAP-сервер для сбора, обработки и представления

информации в различных аналитических разрезах. Основной элемент BI-платформы

Hyperion.

Oracle Hyperion Planning – Специализированная система для решения задач

планирования и бюджетирования, позволяющая организовать формирование, контроль и

анализ исполнения планов с охватом всех предприятий и подразделений корпорации.

Oracle Hyperion Financial Management – Система для консолидации и трансформации

финансовой отчетности, финансового анализа и поддержки принятия стратегических

финансовых решений.

Oracle Profitability and Cost Management – Система бизнес-моделирования и реализации

методов функционально-стоимостного анализа. Позволяет формировать и анализировать

возможные сценарии, оптимизировать использование ресурсов и прогнозировать

рентабельность.

Oracle Hyperion Strategic Finance – Система стратегического финансового

моделирования.

Oracle Hyperion Performance Scorecard – Решение для реализации элементов

стратегического управления на основе сбалансированной системы показателей (Balanced

Scorecard) и аналогичных методик. Позволяет описывать корпоративные цели и

контролировать их достижение.



http://ivan-shamaev.ru/wp-content/uploads/2013/05/Oracle_EPM_11.1.2.1_Hyperion.png



Архитектура Planning

Oracle Hyperion Planning подключен как к Oracle Essbase, так и к Реляционной базе

данных (БД). Список объектов, которые хранятся в СУБД и Oracle Essbase приведен на



http://ivan-shamaev.ru/wp-content/uploads/2013/05/Oracle_hyperion_planning_architecture.png

http://ivan-shamaev.ru/wp-content/uploads/2014/07/Hyperion_Planning_Architecture.jpg



рисунке:

RDBMS

Security (Безопасность): Права пользователя, системные роли, права доступа

пользователей/групп составляют безопасность приложения Oracle Hyperion Planning.

Безопасность планирования определяет, какие пользователи имеют доступ и к чему

пользователь имеет доступ в приложении планирования.

Metadata (Метаданные): Приложение Oracle Hyperion Planning состоит из измерений и

элементов (членов) измерений. Имена измерений, имена элементов, свойства этих

элементов и измерений создаются в виде метаданных, которые сохраняются в Oracle

Relational Database и Oracle Essbase.

Foreign exchange rates (Курсы иностранных валют): Exchange Rate (обменный курс) –

курс, по которому одна валюта конвертируется в другую. Приведем простой пример, 47

INR (индийская рупия) = 1 USD (доллар США). Организации не являются локальными,

они являются глобальными и ведут свой бизнес в нескольких странах, которые имеют

различную валюту. Поэтому планирование “на лету” в различных валютах –

необходимость для бизнеса в современных условиях глобализации.

Process management details (Детали управления процессами): Управление процессом –

это обзор процесса составления бюджета организации. У каждой организации есть своя

иерархия и ей соответствует собственный процесс утверждения бюджетов. Детали

управления процессами помогают определить цепочку утверждения бюджета компании от

начала до конца.

Annotations/supporting details (Аннотации/дополнительная информация): Аннотации

– это дополнительная информация, которая добавляется к ячейке или блоку планирования

(элементу цепочки утверждения бюджета). Данная информация информирует

пользователя о значениях ячейки или служит комментариями к блоку планирования.

Вспомогательная информация для ячейки – это встроенный калькулятор, при помощи

которого можно детализировать, как вычислялась то или иное значение ячейки.

Data forms (Формы данных): Формы данных – это электронные таблицы для ввода

данных плановиками. Определения формы данных хранится в реляционном источнике, а

вводимые данные сохраняются в Oracle Essbase.

User variables (Пользовательские переменные): Пользовательские переменные

создаются для того, чтобы ограничить число элементов, отображаемых в формах данных.

Планировщик должен видеть элементы, которые имеют к нему отношение.



http://ivan-shamaev.ru/wp-content/uploads/2013/05/Oracle_hyperion_planning_essbase_RDB.png



Следующая информация сохраняется только в Oracle Essbase: Data (Данные): Введенные пользователем или планировщиком данные в приложение

планирования хранятся в Oracle Essbase.

Calculation scripts/business rules (Калькуляционные скрипты/бизнес-правила): В

планировании и бюджетировании, типовые расчеты, такие как вычисление аллокаций,

расчет выручки, расчет расходов, калькуляция балансового отчета и так далее, можно

реализовывать с помощью бизнес-правил или калькуляционных скриптов.

Бизнес-правила – расчеты, реализованные в системе на специальном языке. Как правило,

бизнес-правила прикрепляются к формам ввода и могут запускаться автоматически при

определенных действиях пользователей (открытии или сохранении данных формы ввода).

Substitution variables (Подстановочные переменные): Подстановочные переменные

используются в бизнес-правилах для того, чтобы не переписывать каждый раз

фиксируемый элемент измерения для расчета, а с помощью подстановочной переменной

подставлять нужное значение во все скрипты, где это необходимо. Также подстановочные

переменные используются в формах данных.

Security of Oracle Hyperion Planning is the responsibility of Hyperion Shared Services.

Hyperion Shared Services ensures the secure environment of not only Oracle Hyperion Planning

but also of the whole Oracle EPM product suite. Hence, all Oracle EPM products, including

Oracle Hyperion Planning rely on Hyperion Shared Services for User authentication and

authorization. We can do the following security activities using Hyperion Shared Services.

User authentication and authorization: Oracle Hyperion Shared Services obtains the

identification credentials of a user such as user ID and password and validates these credentials

against native directory of relational database or External User directories, which are corporate

user identity management systems. Post authenticating, Oracle Hyperion Shared Services takes

care of the user authorization too.

User directory configuration: Oracle Hyperion Shared Services can be configured to external

user directories such as Sun Java System Directory Server and Microsoft Active Directory,

which are LDAP-based, for User Authentication.

User provisioning: Oracle Shared Services provisions user and groups. Users of Oracle EPM

products need to be provisioned with the roles specific to the roles of the product. For example,



http://ivan-shamaev.ru/wp-content/uploads/2013/05/shared-services-architecture.png



Oracle Hyperion Planning product has roles like Administrator, Provisioning manager, Planner,

Interactive User and View User, and users are provisioned according to their usage and

requirement.

Java Application Server and Web Server

We understood that Oracle Hyperion Planning is a Web-based planning, budgeting, and

forecasting application and users/planners can access the application on their browsers using a

simple URL (that is an HTTP request).

A WebServer serves pages for viewing in a web browser. Hence, we need a WebServer that

receives HTTP requests from users and sends out the result in response to the users upon

processing the request by WebApp server. After the WebServer receives a user’s request, that is,

a HTTP request, the subsequent responsibility is of Application server which serves the business

logic to application programs.

Therefore, J2EE Application server and a WebServer are a part of the architecture. Apache

Tomcat and Apache Web Server have been respectively the default embedded Java container

(J2EE App server) and embedded Web Server till recently.

But in 11.1.2 version, Tomcat is no longer the default embedded J2EE server, it’s replaced by

WebLogic. Apache is no longer the default Web Server; it’s replaced by Oracle HTTP Server.

EPM Architect Dimension Server

As said earlier that Planning application can be created in two ways – one way is Classic and the

other way is using EPM architect.

EPM Architect Dimension Server is applicable for Oracle Hyperion Planning applications,

which are created using EPM Architect.

EPMA integrates the maintenance of Oracle Hyperion EPM products such as Hyperion Financial

Management, Profitability and Cost Management, and Oracle Hyperion Planning.

Продукты и их URL

Продукт URL

Hyperion Shared

Services http://[Hostname]:[WebServerListenPort]/interop/

EPM Workspace http://[Hostname]:[WebServerListenPort]/workspace

Administration

Service http://[Hostname]:[WebServerListenPort]/easconsole/console.html

Oracle Hyperion

Planning

Application Wizard

http://[Hostname]:WebServerListenPort]/HyperionPlanning/AppWizard.jsp





Функциональная диаграмма EPMA

EPM Architect

EPMA modules.pdf (Google Disk)

6 EPMA Modules:

Dimension Library

Application Library

Calculation manager

Data Synchronization

Application Upgrades

Library Job console

Application Library



https://drive.google.com/file/d/0BxOg0amRzk9vZExlZ1VMMm41Y3c/edit?usp=sharing

http://ivan-shamaev.ru/wp-content/uploads/2013/05/Functional_diagram_EPMA.jpg

http://ivan-shamaev.ru/wp-content/uploads/2013/05/application_library.png



There is one more library — the application library. This is the module that is actually

responsible for creation of a Planning application. This is not only responsible for Planning

application creation, it also lets us create other Performance Management applications. This

library enables us to manage all Performance Management applications, which includes creating,

editing, and deploying applications. It displays all the applications that are created using EPM

architect. It does not show any application that was not created using EPMA.

The uses of the Application library module are listed as follows:

• Creating an application

• Duplicating an application

• Deleting an application

• Opening an application

• Validating and deploying an application

• Re-registering an application with shared services

• Synchronizing between applications

Data Synchronizer

Now, this data synchronization is an effective way of synching data between EPM applications.

It can also synchronize between EPMA applications and interface tables/external sources.



http://ivan-shamaev.ru/wp-content/uploads/2013/05/data_synchronizer.png



Dimension Library

Applications have dimensions, which are the basic building blocks. We need to note that EPMA

is not a luxury of only Hyperion Planning application. He is an architect who serves all of his

clients of Oracle Hyperion Performance Management applications such as Hyperion Planning,

Hyperion financial management, and so on.

Dimension Library is a centralized location from which you can manage dimensions and

dimension properties. It includes features such as adding, deleting, and modifying dimension

members/member properties.

Hence, it’s termed the Dimension Library; in short, it’s the library of dimensions. Dimension

library does not have a preset list of dimensions by the virtue of installation. We need to either

import dimensions or create dimensions within the library.

The following are some uses of Dimension Library:

• First and foremost, its usage is to manage dimensions from a central location. Catering to many

Performance Management Applications

• Secondly, we can add/delete/modify members and dimensions

• The final usage is to set properties of both dimensions and members of an application Shared

Library is the library of dimensions, which is meant to be shared by Performance Management

Applications.

Приложения состоят из измерений, которые являются, по сути, их основными

строительными блоками. Dimension Library (Библиотека измерений) – это

централизованное место, из которого вы можете управлять измерениями и их свойствами.

Dimension Library включает в себя такие функции, как добавление, удаление и изменение

элементов измерения/свойств элементов.

Dimension Library не имеет предустановленного списка измерений. С помощью

Dimension Library необходимо создать или импортировать измерения в библиотеку.

Shared Library (Общая библиотека) – это библиотека измерений, которые должны быть

общими для всех приложений Performance Management.



http://ivan-shamaev.ru/wp-content/uploads/2013/05/dimension_library.png



Здесь измерения делятся на два типа:

• Local (Локальные): Эти измерения создаются внутри приложения. Измерения могут

быть созданы в приложении путем перетаскивания измерений из общей библиотеки в

Application View. Затем оно может быть определено как локальное измерение.

Изменения в локальном измерении производятся на стороне приложения. Изменения в

общих измерениях не оказывают влияния на локальные измерения.

• Shared (Общие): Эти измерения, которые являются общими по своей природе и

доступны для всех приложений. Внося изменения в измерение

(добавление/удаление/изменение элементов измерения) в общей библиотеке,

автоматически изменяются shared dimension в во всех приложениях (при нажатии

refresh).

The main difference between a local dimension and a shared dimension is that in case of a

shared dimension any changes made to a dimension in the Shared Library will automatically get

impacted and inherited to all the applications in which the shared dimension is present.

For example, there is a Planning Application and HFM Application. Both of these applications

have a common dimension ‘Entity’, which is a shared dimension. Now, any change made to this

dimension-’Entity’ in ‘shared library’ would automatically bring the same change to the ‘Entity’

dimension within an application in which it’s present. Therefore, the dimensional changes would

impact both the Planning Application and HFM Application, as ‘Entity’ is a shared dimension.

Whereas, if the Entity Dimension has been a local dimension in both HFM and Hyperion

Planning Application, any changes made to the Entity dimension in Hyperion Planning

Application would have no impact on the Entity Dimension in the HFM Application as they are

not ‘shared’ in nature.



http://ivan-shamaev.ru/wp-content/uploads/2014/07/Shared_library.png



Dimension Mapping

Library Job Console



http://ivan-shamaev.ru/wp-content/uploads/2013/05/dimension_mapping.png

http://ivan-shamaev.ru/wp-content/uploads/2014/07/Library_Job_Console.gif



Planning и Essbase

Компоненты Oracle Essbase

Essbase Analytics Module (Block Storage) - модуль Analytic Services создает базу

данных в основе, которой лежит понятие блок – это таблица, состоящая из всех

возможных вариантов плотных направлений, и эти блоки размещаются на

пересечении разряженных направлений. Данный модуль поддерживает запись

значений с помощью пользовательских приложений и предназначен для

комплексного финансового анализа. Направление - это самый верхний уровень

иерархии измерения.

Enterprise Analytics Module (ASO Aggregate Storage) - Этот модуль Analytic

Services создает «агрегированную» базу данных, в себе хранит элементы нулевого

уровня, автоматически рассчитывая все значения более высокого уровня, по своей

структуре чем –то напоминает ROLAP.

Административная консоль Analytic Administration Services - интерфейс

администратора базы данных Analytic Services

Интеграционная консоль — Essbase Integration Studio (не развивается,

предшественик Essbase Integration Studio )



http://ivan-shamaev.ru/wp-content/uploads/2013/05/hyperion_cube_services.gif



Essbase SpreadSheat Add-in for Excel - программное решение предназначено для

получения AD-HOC отчетов в Microsoft Excel, оно непосредственно подключается

к многомерной базе данных. Развитие остановлено.

Smart View for Office - Позволяет получить доступ к данным из всего пакета

программ Microsoft Office, отличается от Essbase SpreadSheet технологическим

решением. Усиленно развивается.

EssCMD - Интерфейс командный строки, предназначен для проведения

административных задач, таких как остановка приложения, запуск сервисных

утилит, резервное копирование и др.

MaxL DDL - Интерфейс командный строки, для проведения административных

задач

Essbase API - Это инструмент разработчика программного обеспечения, позволяет

обращать к многомерной базе данных из VB, C, или JAVA.

Essbase

Объекты Essbase, которые настраиваются в Essbase Administration Services

Console

- Substitution Variables (локальные переменные для приложений);

- Rules (Правила/скрипты);

- Sequences (Последовательности);

- Macros (Макросы);

- Global Variables (Глобальные переменные).

Типы переменных в EAS (Essbase):

Способы ведения расчетов в Essbase:

1) Консолидация на основе структуры измерений Простой способ расчета, описывающий арифметические действия, выполняемые над

элементом при его консолидации (агрегации) в родительский элемент. Настройки расчета



http://ivan-shamaev.ru/wp-content/uploads/2013/05/Oracle_Hyperion_Essbase_variable_types.png



задаются свойствами элемента и относительным положением элементов в измерении. Тип

консолидации можно изменить на один из следующих:

( + ) элемент прибавляется к текущему результату

( – ) элемент вычитается из текущего результата

( * ) текущий результат умножается на значение элемента

( / ) текущий результат делится на значение элемента

( % ) элемент делится на текущий результат и умножается на 100

( ~ ) элемент не участвует в консолидации по данной иерархии

( ^ ) элемент не участвует в консолидации по всей модели

2) Формулы элементов Этот тип расчетов также относится к элементам измерений и позволяет рассчитывать их

значения через заданную формулу. Относительное положение элементов роли не играет.

Формулы, помимо описанных выше арифметических операций, могут также содержать

дополнительные функции.

На следующем примере Variance = @VAR(Actual, Budget) – разница между значениями в

Actual и Budget, а Variance % = @VARPER(Actual, Budget) – та же разница в процентном

выражении.

Иногда более эффективным оказывается не хранение предрасчитанного результата, а

выполнение динамического расчета при запросе к элементу (свойство Dynamic Calc).

Особенностью первых двух видов расчета является то, что они работают при полном

пересчете куба. Для более сложных расчетов существуют Calc scritps.

3) Расчетные скрипты (Calculation scripts) Как и формулы элементов, этот инструмент может включать в себя разнообразные

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

ускорения вычислений за счет сокращения обрабатываемого объема данных и полностью

контролировать порядок проведения расчетов. Для разработки скриптов в Essbase есть

специальный инструмент, Calculation Script Editor, который предоставляет возможность

визуального выбора элементов измерений, стандартных команд и функций, а также

обеспечивает проверку и подсветку синтаксиса. Расчетные скрипты хранятся и

выполняются отдельно для каждого приложения или куба.

Для приложений, содержащих несколько кубов (как, например, у приложений Hyperion

Planning), используется еще более серьезный способ описания вычислений – бизнес-

правила (Business Rules).

4) Бизнес-правила (Business Rules) По сути, те же расчетные скрипты, но с расширенными возможностями. Они находятся в

отдельном узле дерева объектов Essbase Administration Services Console.

5) Макросы в Essbase (Macros) Макросы – это функции, которые могут использоваться в Бизнес-правилах. Параметры



http://ivan-shamaev.ru/wp-content/uploads/2013/05/create_rule.png



функции задаются в квадратных скобках, например [param1], и указываются в круглых

скобках при вызове макроса, например, %clear_data_organization(“ORG102″).

Они находятся в отдельном узле дерева объектов Essbase Administration Services Console.

6) Последовательности в Essbase (Sequences) Последовательности – это последовательность бизнес-правил, которая задает порядок

выполнения бизнес-правил. Может вызываться из Essbase или из Web-форм. Они

находятся в отдельном узле дерева объектов Essbase Administration Services Console.

Краткий свод основных принципов эффективных правил essbase. - Использование в определении среза данных всех направлений. В FIX нужно полностью

определять область расчетов

- Нужно осуществлять расчеты только по нулевым уровням многомерной модели

(Антипатерн)

- При агрегации данных нужно учитывать структуру метаданных в кубе, т.е. определить

срезы, по которым не нужны рассчитываемые агрегаты. Например, в мультивалютном

приложении, нужно исключить показатели валют на которых не происходит расчет

отчетности группы.

- Контроль пользовательского ввода данных. Простые правила по проверке качества

данных

- Контроль агрегации пустых блоков

- Создаем блоки преимущественно с помощью DATACOPY, на втором месте стоит

DATAEXPORT && CDF , затем SET CREATEBLOCKONEQ

- Использование CALCMODE для оптимизации расчетов

- Различные значения параметров для оптимизации кеша калькулятора и др.(команды

SET) в части расчетов нулевого уровня и в блоке агрегации

- Использование подстановочных переменных для параметризации расчетов,

использование Run-TimePromts, для фокусировки расчета



http://ivan-shamaev.ru/wp-content/uploads/2013/05/create_sequence.png



Пример скрипта калькуляции (business rule)

/*Очистить прогнозные данные*/

FIX (“Генерация”,”Потребление”)

CLEARDATA “Сценарий 1″;

ENDFIX;

/*Копировать факт в сценарий 1*/

FIX (“Тип”,@LEVMBRS (“Период”, 0))

DATACOPY “Факт” TO “Сценарий 1″;

ENDFIX

/*Агрегация*/

FIX (“Тип”,”Сценарий 1″)

CALC DIM (“Период”);

ENDFIX

/* Построить прогноз по дням*/

FIX (“Генерация”,”Потребление”,@LEVMBRS (“Период”, 1))

DATACOPY “Факт” TO “Сценарий 1″;

“Сценарий 1″(

@TREND(@ANCESTORS(&FIRSTP,-1):

@ANCESTORS(&CURP,-1),,,,,@ANCESTORS(&NEXTP,-1):

@ANCESTORS(&ENDP,-1),LR,7);

);

ENDFIX

/* Построить прогноз по часам*/

FIX (“Сценарий 1″)

“Генерация”=(“Тип”/@PARENT (“Период” ,”Тип”))*@PARENT (“Период” ,”Генерация”)

;

“Потребление”=(“Тип”/@PARENT (“Период” ,”Тип”))*@PARENT (“Период”

,”Потребление”);

ENDFIX

/*Агрегация*/

FIX (“Факт”,”Сценарий 1″,”Генерация”,”Потребление”)

CALC DIM (“Период”,”Регион”);

ENDFIX

Компоненты Essbase и настройки

Outlines Редактирование древовидных структур для иерархий измерений Редактирование

правил консолидации и математических отношений между элементами измерений

Essbase – Настройка транзакций При однопользовательских расчетах рекомендуется

устанавливать Commited access, для многопользовательского ввода данных и расчетов –

Uncommited access. В рамках настройки транзакций задается параметр “commit blocks” в

свойствах каждого куба приложения в EPMA.

Системные файлы Essbase Essbase.cfg – файл конфигурации Essbase сервера.

essxxxxx.pag – Файлы данных Essbase





essxxxxx.ind – Файл с индексами

dbname.esm – Центральный файл, который содержит контрольную информацию,

используемую для восстановления БД

dbname.tct – Таблица управления транзакцией

dbname.ind – Free fragment file for data and index free fragments

dbname.otl – Outline файл, в котором определяются все метаданные для баз данных и

каким образом данные хранятся

Rules Files Импорт данных из источников данных в целевые базы данных Oracle Essbase

Загрузка данных и иерархий измерений Rules Files поддерживаются для файловых

источников и SQL-источников.

Создание “Rules Files” 1. Открыть источник данных;

2. Установить свойства источника;

3. Ассоциировать “rule” с схемой “outline” БД;

4. Если необходимо, форматировать файл;

5. Определить метод загрузки значений;

6. Определить свойства полей;

7. Проверить корректность описаний;

8. Сохранить “rule”;



http://ivan-shamaev.ru/wp-content/uploads/2013/05/Load_value_of_dimRules_Files.png



9. Выполнить “rule”.

Блочное и Агрегатное хранилища

Источник информации по BSO и ASO

Блочное хранилище, в документации и литературе по Essbase обозначаемое

аббревиатурой BSO (от англ. block storage option) — исторически первый

реализованный способ хранения многомерных данных, реализованный в продукте,

и отражённый в патенте 1992 года. Блочное хранилище ориентировано на

«уплотнённое хранение» (англ. dense storing) данных, перезапись в куб (англ. write-

back), в том числе на уровне агрегатов, и ускоренный пересчёт результатов.

Благодаря этим свойствам наиболее широкое использование получило в

приложениях финансового планирования, в которых требуется интерактивный

многокритериальный подбор параметров по фиксированным формулам. Основные

ограничения блочного хранилища — около 1 млн допустимых элементов

измерений (может быть несколько увеличено в случае применения

секционирования или гибридного хранения) и 252 ячеек на блок в базе данных.

Таким образом, блочное хранилище считается практически целесообразным для

кубов с 6-8 измерениями, со сложными вычислениями и частой перезаписью

данных.

Агрегатное хранилище (ASO — англ. aggregate storage option) создано как

альтернативный способ хранения данных в 2003 году, в версии Essbase 7, с целью

расширения применимости продукта для хранилищ со значительным количеством

измерений. Одной их характерных особенностей ASO является эффективное

хранение — в сравнении с блочным хранилищем агрегатные занимают

существенно меньше дискового пространства. При этом, по сравнению с блочными

хранилищами существенно ограничены функциональные возможности: в

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

(можно перезаписывать только терминальные ячейки, «нулевой уровень»), не

поддерживаются сценарии вычислений (англ. calculation scripts, поддерживаются

только вычисления, представимые одной формулой).В противовес используемому

«плотному» хранению, агрегатное хранилище оптимально для разреженного

хранения (англ. sparse storing). Кроме того, в отличие от блочных, в агрегатных

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

одного измерения, динамических иерархий, получения срезов данных.Агрегатное

хранилище поддерживает до 216 иерархий на одно измерение, до 4,3 ПБайт

физического объёма куба, до 252 комбинаций хранимых уровней измерений, до

264 ячеек может быть обойдено в одном запросе к агрегатному хранилищу.



http://ru.wikipedia.org/wiki/Essbase

http://ivan-shamaev.ru/wp-content/uploads/2013/05/Load_data_Essbase_tools.png



Вычисления в Block Storage Essbase

Data Load Difference – ASO and BSO



http://ivan-shamaev.ru/wp-content/uploads/2013/05/Calculations_in_Block_Storage_Essbase.png

http://ivan-shamaev.ru/wp-content/uploads/2013/05/ASOBSO_Dataload_Differences.png



Порядок вычислений

Calculation Scripts - Вычисляют всю или часть базы данных;

- Управляют порядком вычисления;

- Совершают сложные вычисления;

Операторы Консолидации Операторы консолидации определяют способ консолидации значений к родительскому

элементу:

• Addition (+)

• Subtraction (-)

• Multiplication (*)

• Division (/)

• Percent (%)

• Exclude from consolidation (~) – Does not use the member in the consolidation to its parent.

• Never consolidate (^) – Does not use the member in any consolidation in any dimension.

Разделяемые значения «Shared Members» • Не хранят данные

• Создают индексный указатель на хранимое значение

• Всегда являются значением уровня 0 «level 0 members»

• Размещаются после (ниже) хранимых элементов в схеме «outline»

Интеллектуальные «Intelligent» вычисления Пересчитываются только блоки данных, которые отмечены как “Измененные”.



http://ivan-shamaev.ru/wp-content/uploads/2013/05/order-of-evaluation.png



Essbase – Database Partitioning

Типы Partition Transparent Partition позволяют пользователям манипулировать данными, хранящимися в

отдаленных местах, как если бы они были частью локальной базы данных. В этом смысле

они очень похожи на механизм VIEW в реалиционных БД. Удаленные данные берутся из

источника всякий раз, когда пользователь, находящиеся в получателе, делает

соответствующий запрос. Пользователям не требуется знать, где хранится информация,

так как они видят ее как часть своей локальной базы данных.

ЧИТАТЬ ПОДРОБНЕЕ>>>

Replicated partitions

Transparent partitions

Linked partitions

Основные понятия

Replicated Partitions Традиционный подход

Копия данных

Множество источников

Ручная репликация



http://essbase.ru/archives/41

http://ivan-shamaev.ru/wp-content/uploads/2013/05/basic_concepts.png



Только «Block storage»

Transparent Partitions «Окно» между БД

Бесшовная передача

Текущие данные



http://ivan-shamaev.ru/wp-content/uploads/2013/05/target_base_data.png



Требуется синхронизация «Outline»

Linked Partitions Точка перехода

Связывает объекты

Различные схемы

Нет репликации

Нет синхронизации схем



http://ivan-shamaev.ru/wp-content/uploads/2013/05/transparent_partitions.png



Источники

Создание Partitions



http://ivan-shamaev.ru/wp-content/uploads/2013/05/linked_partitions.png

http://ivan-shamaev.ru/wp-content/uploads/2013/05/create_partition_steps.png



Идентификационная информация

• Исходная и Целевая БД

• Пользователь

• Права на запись на Целевой

• Права на чтение на Исходной

Проектирование «Aggregate Storage Partition» • Поддерживаются «Transparent» и «Linked»

• Комбинируется с «Block»

• Расширение аналитических возможностей



http://ivan-shamaev.ru/wp-content/uploads/2013/05/create_partition_steps_2.png



• Нет синхронизации

XREF vs Partitions

Часто необходимо обмениваться данными между кубами. Для этого в Essbase есть

специальные инструменты:

- XREF

- XWRITE

- Replicated Partition

- Transparent Partition

XREF – cамый простой и безболезненый способ получить данные из другого куба,

минусы – это низкая производительность и проблемы с созданием блоков (в 11.1.2

добавили @XWRITE).

Не рекомендую использовать XREF в формулах динамических элементов (Dynamic Calc)

т.к. на больших срезах это приводит к потере производительности.

Пример использования: получить значение по ограниченному срезу.

Replicated partition – если вам надо копировать блоки нижнего уровня 1:1 без всяких

расчетов и транформаций, то что надо. Есть функциональность по переносу только

обновленных данных.

Пример использования: передать данные по статье A по нижнему уровню из Source в

Target.

Transparent partition – мощный инструмент для маштабирования. Если сравнивать с

Oracle RDB – это аналог view или updateable view. Имеет ряд особенностей связанных с

тем, что данные не хранятся в Target кубе, а подтягиваются налету.

Пример: в Target по данным из партиции невозможно создать блоки, выгрузить данные с

помощью Dataexport и т.д. Но что очень интерестно – из Target можно обновлять данные в



http://ivan-shamaev.ru/wp-content/uploads/2013/05/create_aggregate_storage_partition.png



Source!

Пример использования: разделение приложения на Факт и План с партицией по

сценарию, разделение по странам, версиям и т.д.



http://ivan-shamaev.ru/wp-content/uploads/2013/05/XREF_table.jpg



Location Aliases – как создать?



http://ivan-shamaev.ru/wp-content/uploads/2013/05/LocationAliases.png



@XWRITE и @XREF

@XWRITE и @XREF – это две вычислительные команды которые могут быть

использованы для следующих операций.

Например, у Вас есть две базы данных (два куба), которые называются A1 и B1, и они оба

имеют разные структуры, которые приведены ниже.

Outline куба A1 выглядит следующим образом:

Outline куба B1 выглядит следующим образом:



http://ivan-shamaev.ru/wp-content/uploads/2013/05/NewLocationAliases.png

http://ivan-shamaev.ru/wp-content/uploads/2013/05/XREF_XWRITE_DATA_A1.png

http://ivan-shamaev.ru/wp-content/uploads/2013/05/XREF_XWRITE_DATA_B1.png



@XREF

Например, мы хотим перенести данные со среза sales->Jan->East->Budget->2011 куба A1

положить на срез East_Sales->Jan->Dept_101->2011 куба B1. Приведенный скрипт ниже

написан в правиле, которое выполняется на кубе B1 и которое копирует данные из куба

A1 в куб B1.

FIX(“Jan”,”Dept_101”,”2011”) “East_Sales”=@XREF(_A1alias_,”Sales”,”Budget”); ENDFIX

• _A1alias_ является location alias куба A1, который выступает в качестве источника

данных для @XREF, т.е. указывает откуда мы берем данные. Location alias _A1alias_

настраивается для куба B1 (Edit->Location Alias). Куб B1 называется целевым и именно

куб B1 указывается при запуске правила.

• @XREF – всегда ссылается на ячеку с данными, образуемую сочетанием имен

элементов, которые указываются в FIX statement и элементами указанных в @XREF. В

данном примере Sales и Budget – это члены из куба A1 (их может и не быть в кубе B1).

• Всякий раз, когда мы планируем получить значение из среза данных другого куба, мы

должны запустить этот расчет. Поэтому, когда мы запускаем это вычисление, оно всегда

будет “лезть” в куб A1 и искать там срез данных, которые нам необходимы. Поэтому,

данная операция требует большее время, по сравнению с операциями, которые

производятся внутри одного куба.

• Если вы хотите скопировать более одного члена из того же измерения, мы должны

написать несколько @XREF формул.

• Мы также можем использовать эту команду в формулах для элемента (member formulas).

@XWRITE

@XWRITE – функция, которую обычно называют старшим братом @XREF. @XWRITE –

это функция в новых версиях Oracle Hyperion, которая заполняет почти все пробелы,

существовавшие в XREF.

@XWRITE – это функция, которая позволяет калькуляционному скрипту передать

данные другой базе данных Essbase или другому приложению (в отличие от метода

“получения данных” XREF). Эта новая функция стала доступна в версии Oracle Hyperion

11.1.2.0 и более поздних версиях. Главное ограничение этой функции заключается в том,

что она работает только для перемещения данных из BSO приложения в BSO приложение.

BSO в ASO не поддерживается, и еще не известно, будет ли Oracle реализовывать данную

функциональность

@XWRITE предназначен для передачи данных между базами с очень похожей

размерностью (т.е. с очень схожими измерениями, например, приложение для

планирования).

Синтаксис функции @XWRITE следующий @XWRITE (expression, location alias [,mbrList])

Первый входной параметр функции – это выражение. Этот элемент измерения Вы

планируете переместить из базы-источника в целевую базу. Вы можете выбрать в поле

“выражение” только один член.

Второй входной параметр – это location alias (настраивается в EAS).

Третий (последний) входной параметр, mbrList – это ячейка или пересечение ячеек, куда

необходимо переместить данные. Если в целевой базе нет измерений, которые есть в базе-

источнике, то вам необходимо описать элементы измерений, на которые будут

перемещаться данные. Производительность функции @XWRITE лучше, если для поля

“выражение” используется элемент из плотного измерения. Но в любом случае,

необходимо протестировать несколько вариантов и выбрать наиболее производительный





и возможный вариант.

Пример (перемещаем данные из куба A1 в куб B1):

FIX(“Jan”,”East”,”Budget”,2011”) “Sales” (

@XWRITE(“Sales”,_B1alia_,”East_Sales”,”Dept_101”); ); ENDFIX

Запуск Workspace

Workspace – единый интерфейс для всех продуктов Oracle Hyperion. EPM Workspace –

это компонент Foundation Services, с помощью которого можно получить доступ к

продуктам EPM System, таким как Oracle Hyperion Planning, Fusion Edition и Oracle

Hyperion EPM Architect, Fusion Edition, а также компонентам Oracle Hyperion Reporting

and Analysis, например Oracle Hyperion Interactive Reporting и Oracle Hyperion Web

Analysis.

Доступ к EPM Workspace можно получить двумя способами: используя URL-адрес, предоставленный администратором, или с помощью ссылки

приложения Oracle.

Для запуска Workspace необходимо использовать адрес

URL: http://hostname:19000/workspace/index.jsp.

Задачи EPM Workspace: 1) Просмотр документов и информационных панелей;

2) Предоставление доступа к следующим продуктам:

- Financial Management

- Performance Scorecard

- Приложения Planning доступны пользователям, имеющим соответствующие права и

доступ

- Oracle Business Intelligence включает продукты Oracle Business Intelligence Answers,

Oracle Business Intelligence Interactive Dashboards, Oracle Business Intelligence Delivers, BI

Publisher, Oracle Siebel Marketing и Oracle BI Disconnected Analytics.

- Profitability and Cost Management

3) Планирование пакетов, заданий или событий для автоматического формирования

отчетов или выдачи уведомлений

4) Создание документов Web Analysis и Interactive Reporting, книг или пакетов





Пользовательский интерфейс Workspace

The EPM Workspace user interface includes these areas: 1. Menu Bar – Commands and sub-commands that organize tasks and modules.

2. Standard toolbar – Buttons for performing tasks.

3. View pane – Area that provides buttons that enable jumps between panels (each panel having

a specific use and corresponding controls) and displays the list of documents and modules

(Hiding this pane provides a larger content frame in which to use EPM Workspace. Select View,

then View Pane to hide and display).

4. View Pane or Content Area Adjuster – Setting to adjust the size of the View pane and

content area.

5. Content area – Area in which you view active-module documents, tasks, or files



http://ivan-shamaev.ru/wp-content/uploads/2013/05/EPM_Workspace_user_interface.png



Открытие приложений

Через EPM Workspace можно открыть приложение. Необходимо зайти в меню: File-

>Open->Applications->{Тип приложения, например Planning}->{Наименование

приложения}.

Презентация (Google Disk): Dimensionality & Dimensions of Hyperion Planning.pptx

Измерения в Planning

Измерения делятся на локальные (Local Dimensions) и общие (Shared Dimensions)



https://drive.google.com/file/d/0BxOg0amRzk9vQzhQeTNOaV9ZY0U/edit?usp=sharing

http://ivan-shamaev.ru/wp-content/uploads/2014/07/EPM_Workspace_Open_application.png

http://ivan-shamaev.ru/wp-content/uploads/2013/05/Local_and_shared_dimensions.png



Выбор типов измерений при создании приложения:

Таблица с характеристиками типов измерений

Группы измерений Измерение Стандартные

измерения Workforce

Основные

средства

Все типы планов: Entity * * *

Version * * *

Scenario * * *

Account * * *

Year * * *

Period * * *

Alias * * *

Меры: Employee

*

План основных

средств: Asset Class

*

Line Item

*

Настраиваемые

измерения:

14

доп.измерений

Прочие измерения: Attribute

Smart List

UDA

* *

Add Dim

Описание измерений в дополнение к таблице The Entity dimension contains members for HR organizations (departments, for example)

enabled in the HCP plan, and for General Ledger organizations (cost centers) enabled in Plan



http://ivan-shamaev.ru/wp-content/uploads/2014/07/Types_of_dimensions_hyperion_planning.gif



Type 1, 2, or 3.

The Account dimension contains salary, job code, employee, and allocation properties entered

by planners. It also contains compensation expense accounts, personnel expenses, and loaded

General Ledger natural account segment or chart field values. Create account members for all

budgeted items.

An alias is just like an alias in everyday life, it is just another name for member, for account you

could have an account member name called A90001, this is not very descriptive and not the best

for reporting or for users to view so you could give it an alias of “Balance Sheet”. В

приложении можно выбрать определенный Alias, к которому в дальнейшем будут

привязаны все псевдонимы элементов других измерений.

The Employee dimension contains employed workers in your organization. Employees are

typically paid compensation and benefits through the employer’s payroll application. This

dimension is created if you use Employee budget detail or Position and Employee budget detail.

Through attribute dimensions, you group and analyze members of standard dimensions based

on the member attributes (characteristics).

For example, you can compare:

1) The profitability of noncaffeinated products that are packaged in glass;

2) To the profitability of noncaffeinated products packaged in cans.

Измерение Attribute должно иметь только одну связь и только с одним базовым

измерением (связь указывается при создании приложения). В измерении Attribute можно

создавать иерархию, но при выборе в свойствах связанного измерения можно назначать

атрибут, у которого нет потомков (иначе не разворачивается приложение). С измерениями

атрибутов могут быть связаны только разреженные базовые измерения. Для элемента

связанного измерения можно выбрать только один элемент измерения Attribute. В

приложении может существовать несколько измерений Attribute и несколько измерений

Attribute можно привязать к одному и тому же измерению.

Возможные типы измерения: text, boolean, number, date.

Smart List: С помощью данного измерения можно создавать выпадающие списки в

формах данных для пользователей. При назначении ячейке формы измерения Smart List,

вводить данные в нее запрещается.

A UDA is a User defined attrbute, it is basically just a name that you create and it can be tagged

against members, you can use them to group and retrieve data based on its characteristics, for

example you may want to describe a number of accounts as expense accounts, you could have a

UDA called “Expense” and then associate with the account members.

UDA – дополнительное измерение, в отличие от измерения Attribute – можно к одному

измерению привязать несколько UDA, т.е. элемент измерения может иметь много разных

признаков.

Обязательные, мультивалютные и пользовательские

измерения

Всего можно использовать до 20 измерений (ограничения “вшиты” в таблицах

метаданных):

6 обязательных;

2 мультивалютных;

12 пользовательских (14, если не используются мультивалютные измерения);

На каждом измерении могут быть заданы иерархии и формулы.





6 обязательных измерений:

Период

Год

Сценарий

Версия

Структура компании

Счет

Примеры пользовательских измерений: - Персонал;

- Товары;

- Каналы;

- Проекты;

- Покупатели (клиенты);

- Типы деятельности.

2 дополнительных измерения в мультивалютных приложениях:

Валюта (Currency).

Курс валют (HSP_Rates) – измерение (направление), обеспечивающее конвертацию

валют.

Мультивалютность Система бюджетирования должна позволять ввод данных и построение отчетов с

использованием нескольких валют, а для преобразования информации использовать

обменные курсы, заданные для соответствующих временных периодов.

1) Планирование как в одной, так и в нескольких валютах

2) Для каждого из центров финансовой ответственности указывается его локальная

валюта

3) Три типа курсов валют:

исторический (единый для всех периодов)

средний курс

курс на конец периода

4) Версии курсов:

оптимистический

пессимистический

This dimension contains a member to store exchange rate values for each currency. It also

contains a member for input values and currency overrides. This dimension can be divided into

two types as follows:

1) Input members

2) Currency rate members

If an application has three currencies, would have three corresponding members as follows:

- HSP_Rate_USD

- HSP_Rate_EUR

- HSP_Rate_INR





Плотные и разреженные измерения

Многомерные множества данных как правило бывают разреженными:

Данные распределены не равномерно.

Данные не существуют для большинства комбинаций элементов.

Одни части многомерных данных более разрежены, чем другие.

Dense Плотная.

Многомерная база данных считается плотной, если относительно высокий процент (по

крайней мере, 10%) возможных комбинаций ее измерений содержит данные.

Sparse Разреженность.

Многомерная база данных называется разреженной, если относительно большой процент

ячеек содержит пустые (утраченные) данные. Вполне обычны такие наборы данных,

которые содержат 1%, 0.01% и даже меньшую долю возможных данных.

Sparse aggregates Разреженные агрегаты. Во избежание такого явления как “взрыв” БД,

базы данных OLAP большой емкости должны содержать относительно небольшое число

заранее вычисленных показателей. Предварительно должно быть вычислено минимальное

количество возможных суммарных значений. Остальные агрегаты рассчитываются “на

лету” на основе уже имеющихся.

1) Плотные (dense) измерения Использовать нужно всегда т.к. это ведет к уменьшению

размера блока => размер куба будет меньше => производительность расчетов улучшится,

производительность извлечения данных (retrieve) меняется незначительно +/- 1%!

Необходимо только избегать динамических элементов с комплексными формулами т.е.

когда при расчете формулы необходимо смотреть в другие блоки. Кандидаты на

изменения типа храния на динамический – родители или любой элемент с простой

формулой.

Примеры (Период и Статья – плотные, Страна – разряженные):

Кварталы (Q1, Q2, Q3, Q4) – можно сделать динамическими

(+) Acc_Total: Выручка итого(+) Acc_01: Выручка A (+) Acc_02: Выручка Б Статью

Acc_Total можно сделать динамической



http://ivan-shamaev.ru/wp-content/uploads/2013/05/sparse-dense-dimensions.png



Статья: Prof_01 = Acc_01 / Acc_Total – можно сделать динамической (расчет в

пределах одного блока)

Статья: Prof_Russia = Acc_Total->Entity_Russia – нужно делать хранимой т.к. при

распаковке любого блока (расчете или просмотре) Essbase будет смотреть на блок

по стране Entity_Russia

2) Разряженные (sparse) измерения Использовать можно только для уменьшения

времени агрегации, при этом ухудшается время извлечения данных (retrieve).

Пример:

(+) Entity_Russia – dynamic(+) Entity_Msc – store (+) Entity_Spb – store Если

пользователь строит запрос по Entity_Russia, то серверу необходимо прочитать 2

дополнительных блока по Msc и Spb

Когда не нужно делать динамическими плотные элементы:

Когда элемент участвует в выгрузках (report script, dataexport)

Когда элемент участвует в партициях

Когда элемент участвует в создании блоков (datacopy с динамических элементов не

работает)

Когда на элементе хранят расчетные данные (аллокации, элиминации)

3) Выводы Динамические элементы – это хорошая возможность улучшить

производительность, но конечно же со своей спецификой.





Создание блоков данных

Data blocks are created for the combination of sparse dimensions. We use the Create Blocks

action to ensure that all the blocks are created from the sparse dimension combinations. Create

Blocks actions are not applicable to the members with the property of Dynamic calc or Label

only and the reason being that the block is not created as these members are not stored in the

database physically, and also provide a reference to the chapter/section where we have discussed

storage types.

Создание блоков данных и получение данных Блок данных не создан, пока в блок не введены данные (причем, если Вы ввели данные, а

потом удалили их, то блок без специальной команды не удалится);

Essbase Analytics проверяет, существует ли блок;

Если блок не существует, то блок создается;

Данные попадают в блок данных.

Выбор настроек агрегирования, хранения данных и

вычислений

Типы хранения элементов измерений: - Store (Хранимый, по умолчанию);

- Dynamic Calc and Store (Динамический расчет и хранение);

- Dynamic Calc (Динамический расчет);

- Share (Разделяемый – расшаренный элемент для параллельной иерархии в том же

измерении);

- Never Share (Неразделяемый);

- Label Only (Элемент-метка).



http://ivan-shamaev.ru/wp-content/uploads/2013/05/Actions_create_blocks.png



Агрегация: + Сложение

- Вычитание

* Умножение

/ Деление

% Процент

~ Игнорирование

Создание ассоциаций между измерениями

Dimension associations (ассоциации измерений) позволяют присваивать классы

безопасности и валюты измерениям и элементам измерений. Например, для измерения

Entity, вы можете создать ассоциации с классами безопасности и измерениями валюты.

Ассоциации создаются на уровне измерения и наследуются всеми членами под

измерением. Ассоциации измерений создаются в Dimension Library.

Dimension associations используются для обозначения взаимосвязей между измерениями

в рамках Общей библиотеки (Shared Library) и приложений. Например, в рамках

приложений консолидации есть свойства измерения Account (Статьи), которые ссылаются

на класс безопасности, нестандартные пересечения измерения (Custom1TopMember), и так

далее, которые непосредственно связаны с другими измерениями. Dimension associations

позволяют определить отношения между этими свойствами и другими измерениями, что

позволяет Вам выбрать значение (элемент) напрямую из измерения, с которым создается

взаимосвязь.

Dimension associations создаются для всех свойств, в которых значение свойства связано с

элементом другого измерения. После создания ассоциаций, Вам необходимо активировать

их в приложении.



http://ivan-shamaev.ru/wp-content/uploads/2013/05/relation-planning-essbase-epm_architect.png



Редактирование ассоциаций измерений:

Активировать все ассоциации измерений:



http://ivan-shamaev.ru/wp-content/uploads/2014/07/Edit_dimension_association.png

http://ivan-shamaev.ru/wp-content/uploads/2014/07/activate_all_associations.png



View Dimension Association:



http://ivan-shamaev.ru/wp-content/uploads/2014/07/View_Dimension_Association.gif



Работа с Grid Editor

Grid Editor отображает элементы и свойства, которые были выбраны в wizard. Поскольку

элементы и свойства могут отличаться, в зависимости от категории измерения, вы можете

выбрать определенную категорию для отображения в верхней части Grid Editor.



http://ivan-shamaev.ru/wp-content/uploads/2014/07/epma_grid_editor.png



Элементы отображаются в виде строк слева. Свойства отображаются в виде столбцов.

Добавление валют и псевдонимов

Автоматизация заданий Perfomance Management

Architect

Терминология: Аналитическое измерение (Измерение) – аналитический признак. Измерение содержит

набор элементов.

Иерархия – определяет правила, по которым группируются элементы в измерении. В

одном измерении может быть несколько иерархий, называемых альтернативными.

Альтернативная иерархия – иерархия разделяемых элементов. Альтернативная

иерархия основана на существующей иерархии в структуре БД, но использует в

измерении альтернативные уровни. Альтернативная иерархия позволяет отображать одни

и те же данные с разных точек зрения.



http://ivan-shamaev.ru/wp-content/uploads/2014/07/epma_grid_editor_main.png

http://ivan-shamaev.ru/wp-content/uploads/2014/07/Currency_Dimension_View.png



Презентация по настройке измерений:

Dimension settings.pdf (Google Disk)

Общий порядок добавления новых элементов в

измерения рабочего приложения Hyperion Planning

Добавление нового элемента в измерения ЦФО, Бюджетные статьи, Сценарий и

другие измерения в приложении Hyperion Planning: 1. Создаем в иерархии новый элемент с необходимыми настройками.

2. Анализируем в каких формах этот элемент должен использоваться.

3. Анализируем в каких дополнительных иерархиях должен использоваться новый

элемент.

4. Анализируем какие права доступа необходимо дать по новому элементу.

5. Анализируем в какие скрипты необходимо внести изменения.

6. Если необходимо – настраиваем бюджетные блоки по данному элементу (данный пункт

касается в первую очередь измерений ЦФО, Версия, Сценарий).

7. Редактируем отчеты в системе или выгрузки в файловые системы и базы данных

(внешние аналитические системы), если это необходимо.

Обзор временных периодов

В системе бюджетирования все данные привязываются к определенному временному

периоду, а не к ячейке. это свойство позволяет автоматически агрегировать данные в

соответствии с иерархией временных периодов (месяц-квартал-год), а также сопоставлять

различные данные за соответствующие интервалы времени.

Измерения Period и Year

You specify a time period and year for each value. Base time periods, such as months, are

automatically rolled up to summary time periods, such as quarters and total year. As

administrators, you specify base time periods and distribution of weeks in the Period dimension

when you create application views. You use the year dimension to add years to the calendar.

Члены динамических временных рядов

Описание элементов динамического временного ряда (Dynamic Time Series,

DTS)

You can use Dynamic Time Series (DTS) members to create reports that show period-to-date

data, such as quarter-to-date expenses. DTS members are created automatically during

application creation, and can be used with members of the Period dimension. To set up DTS, you

enable a predefined DTS member and associate it with a generation number (and, optionally, an

alias table and alias name). For example, to calculate quarter-to-date values, you can enable the

Q-T-D member and associate it with generation number 2. You can then use the Q-T-D DTS

member to calculate monthly values up to the current month in the quarter.

Planning предоставляет восемь предопределенных DTS элементов: • H-T-D: History-to-date



https://drive.google.com/file/d/0BxOg0amRzk9vNWJLS1dZcDdJYm8/edit?usp=sharing



• Y-T-D: Year-to-date

• S-T-D: Season-to-date

• P-T-D: Period-to-date

• Q-T-D: Quarter-to-date

• M-T-D: Month-to-date

• W-T-D: Week-to-date

• D-T-D: Day-to-date

The DTS members provide up to eight levels of period-to-date reporting. Your data and database

outline determine which members you can use. For example, if the database contains hourly,

daily, weekly, monthly, quarterly, and yearly data, you can report day-to date (D-T-D), week-to-

date (W-T-D), month-to-date (M-T-D), quarter-to-date (Q-T-D), and year-to-date (Y-T-D)

information. If the database contains monthly data for the past 5 years, you can report year-to-

date (Y-T-D) and history-to-date (H-T-D) information, up to a specific year. If the database

tracks data for seasonal time periods, you can report period-to-date (P-T-D) or season-to-date (S-

T-D) information.

It is recommended that you avoid assigning time balance properties (such as First and Average)

to members set for dynamic calculations if you plan to use the members in Dynamic Time Series

calculations. Doing so may retrieve incorrect values for parent members in your accounts

dimension.

Настройка элементов динамического временного ряда (Dynamic Time

Series, DTS)

Вызов DTS в старом интерфейсе



http://ivan-shamaev.ru/wp-content/uploads/2014/07/Creating_DTS_Old_Menu.png



Вызов DTS в новом интерфейсе (11.1.2.x)

Интерфейс настройки предопределенного динамического временного ряда



http://ivan-shamaev.ru/wp-content/uploads/2014/07/Creating_DTS_New_Menu.jpg

http://ivan-shamaev.ru/wp-content/uploads/2014/07/Dynamic_Time_Series.png



Отображение DTS в Essbase:

Сценарий и Версия

The Scenario and Version dimensions represent the broadest categories of data in your

application. Scenario describes the type of data that a plan includes, such as budget, actual, or

forecast, as well as the time span that the plan covers. Version allows for flexibility and iterative

planning cycles. For example, your application could have two versions, Working and Final, for

each scenario. You can also use versions to model possible outcomes based on different

assumptions about interest rates, growth rates, and so on. For example, your application an have

a Best Case and Worst Case version for each scenario.

Создание сценариев

Scenario – определяет класс данных (Бюджет, Прогноз, Факт, Месячный отчет).

Введение в сценарии В любой достаточно крупной организации планирование носит многовариантный

характер. Для этого автоматизированная система должна позволять описывать различные

вариации планов и бюджетов; при этом подразумевается, что любой из версий может

соответствовать собственная процедура согласования.

В системе Hyperion Planning многовариантность планирования реализуется при помощи

аналитических направлений «Сценарии» (Scenario) и «Версии» (Version). Каждая

комбинация сценария и версии содержит свой собственный набор данных. После того как

пользователи-планировщики завершают ввод данных для объекта (ЦФО) по конкретному



http://ivan-shamaev.ru/wp-content/uploads/2014/07/DTS_in_Essbase.png



сценарию и версии, они могут инициировать процедуру согласования и утверждения в

соответствии с заданной организационной процедурой. Сценарии могут охватывать

различные промежутки времени. При описании сценария указывается категория данных

(например, «плановые», «фактические» или «прогнозируемые»), а также

соответствующие данному сценарию период времени и таблица курсов валют.

Когда планировщики вводят данные, соответствующие определенному сценарию, то им

доступны только годы и периоды в пределах установленного для данного сценария

диапазона (периоды за пределами диапазона показываются в режиме «только для

чтения»).

Если бюджетная модель является мультивалютной, то за сценарием должна быть

закреплена таблица обменных курсов. Если за разными сценариями закрепить разные

таблицы курсов, это даст возможность моделировать последствия различных допущений

относительно котировок валют.

Например, если организация желает сформировать два плана продаж — на один и на три

года, — то в системе для этого можно будет создать два сценария: «План продаж на

текущий год» и «Прогноз продаж на три года». Разумеется, каждому из планов будет

соответствовать свой горизонт планирования и плановые периоды. При этом каждый план

будет формироваться разными пользователями, с разными схемами рассмотрения,

согласования и утверждения. Кроме того, для каждого из планов можно указать свою

таблицу курсов валют.

Примеры сценариев: Actual – Actual results for a period. Actual results are loaded from the ledger and are available

to be viewed through the PennHist reporting application. Actual results are loaded from the

ledger on a monthly basis at month-end, and any revisions to prior months will be picked up.

Operating – Operating budget for a period. Operating budgets are loaded from the ledger and

are available to be viewed through the PennHist reporting application. Operating budgets are

loaded from the ledger on a monthly basis at month end and any revisions to prior months will

be picked up.

Forecast – Forecast for the Current Year. Current Year forecasts are updated by the Planning

user via the PennPlan application, and are loaded on a periodic basis during the day to PennHist

for reporting and analysis.

Budget – Budget for the next year and future years. Budgets are managed by the Planning user

via the PennPlan application and are loaded on a periodic basis to PennHist for reporting and

analysis.

Создание версий

Введение в версии Версии бюджета придают процессу планирования дополнительную

гибкость и могут иметь различную интерпретацию по отношению к определенному плану,

например:

— предварительный или окончательный вариант плана;

— оптимистическая, пессимистическая или наиболее вероятная оценка показателей;

— внутренние или внешние данные.

Версии не зависят от отдельных сценариев. Например, если создать оптимистическую

и пессимистическую версии, то их можно будет использовать в сочетании с любым из

сценариев.

Версии могут быть двух видов: восходящие (Standard bottom-up) и целевые (Standard

target).

В первом случае планировщики могут вводить данные только в элементы низшего

уровня. Элементы родительского уровня автоматически агрегируются на основании

значений низшего уровня и доступны только для чтения.





Например, данные вводятся для Ленинградской и Архангельской областей, а общее

значение по Северо-Западному региону агрегируется на их основе.

Целевые версии позволяют вводить данные на любом уровне иерархии. Для

распределения значений от родительских элементов к их потомкам можно использовать

бизнес-правила.

Например, можно ввести целевое значение для общих расходов в элемент «Европа» и с

помощью бизнес – правила получить значения для Ленинградской и Архангельской

областей на основании некоторой базы распределения (например, численности

населения).

Целевые версии позволяют устанавливать целевые показатели на определенном уровне

управления. Планировщики, работающие с восходящими версиями, могут соотносить эти

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

Например, у элемента «Общие продажи продукции» могут быть дочерние элементы

«Розничные продажи», «Оптовые продажи» и «Дистрибьюторы». Бюджетный аналитик

может ввести значение «10 000» для «Общих продаж продукции» по объекту

«Краснодарский край» в целевой версии (и тем самым установить целевой показатель

продаж по Краснодарскому краю). Планировщики, в свою очередь, могут ввести значения

в восходящей версии отдельно по розничным, оптовым и дистрибьюторским продажам. В

идеале сумма значений низшего уровня будет составлять 10 000 и позволит показать, как

достигается цель бюджета. Данные можно копировать из одной версии в другую, при этом

позволительно выбирать объекты, данные которых должны копироваться. Например, в

предварительной версии сценария годового дохода могут быть данные по Центральному и

Южному регионам, которые можно взять за отправную точку окончательной версии.

Права доступа к элементам аналитических направлений «Сценарий» и «Версия» можно

назначать для групп или отдельных пользователей (планировщиков и бюджетных

аналитиков). Эти права определяют, может ли пользователь или группа просматривать

и/или изменять данные.

Пример элементов измерения Версия: Working – The version that is being worked on. All changes take place in the “Working”

version.

Final – The final version of the budget refers to the version that is loaded to the ledger in June

and becomes the “Original Budget” for the subsequent budget year. The final version is also

used for anything that comes from the ledger, including prior year actuals, current year actuals,

and the operating budget.

Элементы измерения Организация/Организационной

структуры (Entity)

This is key dimension that defines business organization hierarchy, workflow, and Entity

responsibilities in an organization. Entity dimension shows the flow of Planning information

through organization. Can establish an entity for each group or responsibility centre that submits

a budget plan. This dimension typically includes geographic regions, departments, or divisions,

depending on your requirements.





Типы счетов

Используемые типы счетов в Hyperion Planning:

Expense (Расходы) – затраты на ведение бизнеса

Revenue (Доходы) – источники дохода

Asset (Актив) – ресурсы компании

Liability and Equity (Обязательства и Собственный капитал) – Остаточный

интерес или обязательств перед кредиторами

Saved assumption (Сохраненное допущение) – Централизованное планирование

допущений для обеспечения согласованности приложения

Свойства баланса по времени:

Flow (Поток) – Aggregate of all values for a summary time period as a period total.

First (Первый) – Beginning value in a summary time period as the period total.

Balance (Баланс) – Ending value in a summary time period as the period total.

Average (Среднее) – Average for all the child values in a summary time period as the

period total.

Fill (Заполнить) – The value set at the parent is filled into all its descendents. If a child

value changes, the default aggregation logic applies up to its parent. Consolidation

operators and member formulas overwrite Fill values when the members are recalculated.





Создание иерархий счетов



http://ivan-shamaev.ru/wp-content/uploads/2013/05/Account_dimensions_hierarchies.png



Создание Smart Lists

Шаг 1 – Создаем Smart List

Шаг 2 – Заполняем свойства Smart List



http://ivan-shamaev.ru/wp-content/uploads/2014/07/Create_Smart_List.png

http://ivan-shamaev.ru/wp-content/uploads/2014/07/Smart_List_Properties.png



Шаг 3 – Вводим элементы Smart List



http://ivan-shamaev.ru/wp-content/uploads/2014/07/Elements_Of_Smart_List.png



Шаг 4 – Предварительный просмотр Smart List



http://ivan-shamaev.ru/wp-content/uploads/2014/07/Preview_Smart_List.png



Шаг 5 – Связываем Smart List и элемент измерения Account

Что такое метаданные системы Hyperion Planning?

Имена измерений, имена элементов измерений и их свойства, права доступа и другие

объекты системы – все это является метаданными. Например, измерение “Статьи”

содержит иерархию. Информация о том, какая статья как располагается в иерархии

измерения “Статьи” описывается в метаданных. Метаданные в системе Oracle Hyperion

хранятся в таблицах реляционной базы данных Oracle. Метаданные разделяются по

функциональному принципу и хранятся в разных Schemas Oracle Database. Для каждого

нового приложения Planning (или другого, например, для Hyperion PCM) создается новая

схема (новый пользователь). В качестве логина можно использовать наименование

приложения, например, APP_2014.

Описание таблиц с метаданными системы Hyperion Planning (устаревшее)



http://ivan-shamaev.ru/wp-content/uploads/2014/07/Hyperion_Planning_Tables_Metadata.pdf

http://ivan-shamaev.ru/wp-content/uploads/2014/07/Associate_Smart_List_with_Account.png



Архитектура хранения и обращения системы к

метаданным



http://ivan-shamaev.ru/wp-content/uploads/2013/05/manage_metadata.png



Обзор файлов загрузки метаданных

Account dimension (load metadata file)

Employee dimension (load metadata file)

Entity dimension (load metadata file)

Scenario dimension (load metadata file)



http://ivan-shamaev.ru/wp-content/uploads/2014/07/Account_dimension_load_metadata.png

http://ivan-shamaev.ru/wp-content/uploads/2014/07/Employee_dimension_load_metadata.png

http://ivan-shamaev.ru/wp-content/uploads/2014/07/Entity_dimension_load_metadata.png

http://ivan-shamaev.ru/wp-content/uploads/2014/07/Scenario_dimension_load_metadata.png



Форматирование файлов загрузки

Текстовые файлы можно собирать из Excel-файлов. Соответственно, правку файлов

загрузки измерений можно осуществлять в Excel. С помощью VBA все элементарно

автоматизируется и правится очень быстро. Пример файла Excel:

Процесс загрузки метаданных

Подробнее читайте здесь:

EPMA Loading dim members via flat-file.pdf (Google Disk)

Rebuild a Classic Hyperion Planning 11.1.2.1 to EPMA 11.1.2.2 Planning Application

(Google Disk)

Загрузка метаданных из интерфейсных таблиц

Using Interface Tables to Import Metadata into Oracle Hyperion Planning, Fusion

Edition 11.1.2.pdf (Google Disk)

Dynamic Integrations For Multiple Hyperion Planning Applications.pdf (Google Disk)



https://drive.google.com/file/d/0BxOg0amRzk9vMTJLVWZqclI2Yjg/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vVERLUjBvYTUwMVE/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vVERLUjBvYTUwMVE/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9veWNBNy1SekxUb00/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9veWNBNy1SekxUb00/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vTjdPc3QxMG9qbkU/edit?usp=sharing

http://ivan-shamaev.ru/wp-content/uploads/2014/07/Format_metadata_dimension.png

http://ivan-shamaev.ru/wp-content/uploads/2014/07/Load_Dimension_From_Flat_File.jpg



Процесс создания приложения

Creating-Classic-Planning-Applications-in-Oracle-Hyperion-Planning-Fusion-Edition-

11-1

Hyperion Essbase and Planning Training.pdf (Google Disk)

Creating an Oracle Hyperion Planning Application – the Classic Way

Create Hyperion Planning Application (EPMA)

Creating Oracle Hyperion Planning Applications with EPMA.pptx

Процесс создания и настройки приложения состоит из следующих пунктов:



http://ivan-shamaev.ru/wp-content/uploads/2013/05/Creating-Classic-Planning-Applications-in-Oracle-Hyperion-Planning-Fusion-Edition-11-1.pdf

http://ivan-shamaev.ru/wp-content/uploads/2013/05/Creating-Classic-Planning-Applications-in-Oracle-Hyperion-Planning-Fusion-Edition-11-1.pdf

https://drive.google.com/file/d/0BxOg0amRzk9vcmI3d2RDNHg2WUU/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vVzhhX3BFVjN3R1E/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vSjJUc2RaYVZnNTQ/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vZ3AxWk1ISzAwaWM/edit?usp=sharing

http://ivan-shamaev.ru/wp-content/uploads/2014/07/process_of_creating_and_configuring_hyperion_plannign_application.jpg



Схема взаимосвязей между элементами приложения

Схема настроек для измерений в каждом из типов плана

в одном приложении



http://ivan-shamaev.ru/wp-content/uploads/2013/05/relationships_between_the_elements_and_settings.png

http://ivan-shamaev.ru/wp-content/uploads/2013/05/settings-of-cubes.png



Структура функциональной архитектуры приложения

Hyperion Planning

Настройка установок производительности

Определение структуры данных и производительности приложения: 1) Производительность выше, если ячейки, которые необходимы для расчета или

формирования отчета, принадлежат одному блоку;

2) Учитывайте тип направлений при настройке расчетов;

3) При добавлении плотного направления число ячеек в блоке возрастает

экспоненциально.

Как изменить года в приложении Hyperion Planning?

Иногда возникает ситуации, когда необходимо либо удалить лишние года, либо добавить

предшестующие года в приложении без удаления старого и создания нового приложения.

В моем случае нужно было актуализировать тестовое приложение, при этом удалив

лишние года, которые тянулись хвостом от внедрения системы. На момент задачи я

работал с версией 11.1.1.3. Возможно реализация подобной задачи в других версиях

отличается, но, в принципе, механизм не должен измениться. Чтобы

изменить/добавить/удалить года, необходимо изменить данные следующих таблиц:

HSP_CALENDAR, HSP_ALIAS, HSP_MEMBER, HSP_OBJECT,

HSP_UNIQUE_NAMES, HSP_MRU_MEMBERS.

Для облегчения анализа таблиц, в тестовом приложении я удалил все элементы

измерений, формы, смарт списки и т.д., т.е. оставил только каркас приложения. Советую



http://ivan-shamaev.ru/wp-content/uploads/2014/07/Architecture_for_hyperion_planning_application.png



сделать бэкап каждой из обозначенных таблиц, дабы иметь возможность вернуться

обратно. Делал данные манипуляции по изменению годов с двумя приложениями,

поэтому все должно работать. Возможно “дешевле” будет удалить приложение и создать

новое, но я с опасением отношусь к удалению приложений, т.к. были случаи, когда ломал

систему (на этапе своего обучения hyperion planning, возможно из-за корявого обращения

с метаданными). Поэтому я за вариант Change Years in Planning без удаления приложения.

Возможно у меня “кривые руки” и существует более разумный способ – буду рад, если

подскажите.

Валидация приложений



http://ivan-shamaev.ru/wp-content/uploads/2014/07/EPMA_Application_Library_validate_application.jpg



Развертывание приложений

Валюты и обменные курсы

Ввод курсов валют 1) Все бюджеты формируются в локальной валюте ЦФО и конвертируются в валюты

отчетности.

2) Курсы валют задаются отдельно для каждого сценария (например, для плана, факта,

прогноза и альтернативного плана)

3) Для каждого сценария возможен ввод нескольких типов курсов:

- Исторический

- На начало года

- Средний курс каждого периода

- Курс на конец каждого периода



http://ivan-shamaev.ru/wp-content/uploads/2014/07/EPMA_Application_Library_deploy_application.jpg



Создание правил загрузки данных (Rule File)



http://ivan-shamaev.ru/wp-content/uploads/2014/07/1_Data_Prep_Editor.png





http://ivan-shamaev.ru/wp-content/uploads/2014/07/2_Global_Properties.png





http://ivan-shamaev.ru/wp-content/uploads/2014/07/3_Data_Load_Properties.png





http://ivan-shamaev.ru/wp-content/uploads/2014/07/4_Data_Load_Values.png





http://ivan-shamaev.ru/wp-content/uploads/2014/07/5_Head_Definition.png





http://ivan-shamaev.ru/wp-content/uploads/2014/07/6_Data_Sourse_Properties.png

http://ivan-shamaev.ru/wp-content/uploads/2014/07/7_Validate.png



Загрузка данных с помощью правил загрузки данных

(Rule File)



http://ivan-shamaev.ru/wp-content/uploads/2014/07/Select_Load_Data.png

http://ivan-shamaev.ru/wp-content/uploads/2014/07/Select_Data_File.png



Обзор безопасности Planning

Система безопасности EPM System состоит из двух взаимодополняемых уровней,

управляющих правами доступа пользователей и разрешениями:

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

- Инициализация прав доступа (проверка подлинности с учетом ролей)

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



http://ivan-shamaev.ru/wp-content/uploads/2014/07/Select_Rule_File.png

http://ivan-shamaev.ru/wp-content/uploads/2014/07/Status_of_load_process.png



Пользователи EPM System должны пройти аутентификацию, после чего их данные

инициализации будут проверены с целью определения, к каким приложениям EPM System

им предоставлен доступ. По умолчанию пользователи вводят имя пользователя и пароль

на экране входа в систему продукта для получения права доступа ко всем продуктам EPM

System через службу единой регистрации (SSO).

Можно также настроить продукты EPM System на работу с агентом безопасности,

позволяющим подключить ранее аутентифицированных пользователей к продуктам EPM

System. Кроме того, можно использовать другие механизмы аутентификации, например

аутентификацию с помощью сертификатов клиентов, пользовательскую аутентификацию

Java и Kerberos.

Механизмы аутентификации пользователей совместно используются продуктами EPM

System и применяются для проверки учетных данных пользователей для настроенных

каталогов пользователей. Аутентификация пользователей наряду с авторизацией для

конкретных продуктов предоставляет пользователям доступ к продуктам EPM System.

Авторизация осуществляется через инициализацию прав доступа.

SSO – это процесс проверки подлинности сеанса и пользователя, позволяющий

пользователям продуктов EPM System ввести свои учетные данные только один раз, в

начале сеанса, после чего получить доступ к множеству продуктов. SSO устраняет

необходимость отдельной регистрации в каждом из продуктов, к которым пользователь

имеет доступ.

Компоненты, поддерживающие SSO, описываются в следующих разделах: • стандартный каталог

• каталоги пользователей

Стандартный каталог обращается к реляционной базе данных, используемой Shared

Services, для поддержки инициализации прав доступа и хранения встроенных данных,

таких как учетные записи пользователей по умолчанию, а также дополнительных

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

Функции стандартного каталога: • Ведение и управление учетными записями стандартных пользователей

• Центральное хранилище для всех сведений EPM System, связанных с инициализацией

прав доступа; здесь хранятся данные об отношениях между пользователями, группами и

ролями

Каталоги пользователей обращаются к любому корпоративному пользователю и

системе управления идентичностью, совместимой с продуктами EPM System. Продукты

EPM System поддерживают несколько каталогов пользователей, включая каталоги на

основе протокола LDAP, например OID, Sun Java System Directory Server (ранее – SunONE

Directory Server) и Microsoft Active Directory. Реляционные базы данных и стандартное

хранилище SAP также поддерживаются в качестве каталогов пользователей. Можно

настроить множество внешних каталогов пользователей в качестве поставщика

информации о пользователях и группах для продуктов EPM System. Каталоги

пользователей, используемые с продуктами EPM System, должны содержать учетную

запись каждого пользователя, обращающегося к продуктам EPM System. С целью

ускорения инициализации прав доступа пользователи могут быть назначены группам во

внешних каталогах пользователей или группам в стандартном каталоге.

Обзор поставки пользователей и групп

В стандартном каталоге по умолчанию содержится учетная запись пользователя admin.

Пароль для этой учетной записи определяется в EPM System Configurator в процессе





настройки конфигурации. С использованием этой учетной записи можно выполнять все

задачи администрирования стандартного каталога и Shared Services. Все пользователи

EPM System, где бы они ни были определены – в стандартном каталоге или в каком-либо

внешнем каталоге пользователей, – считаются членами группы WORLD; это единственная

группа, создаваемая в стандартном каталоге по умолчанию. WORLD представляет собой

логическую группу. Каждый пользователь Shared Services наследует все роли,

назначаемые этой группе. Пользователь получает всю совокупность разрешений, которые

назначены непосредственно ему или содержащим его группам (в том числе группе

WORLD). Если развертывание Shared Services выполнено в делегированном режиме,

группа WORLD, наряду с пользователями, будет содержать и другие группы. Если

делегированный список пользователя включает группу WORLD, этот пользователь в ходе

поиска сможет находить всех пользователей и все группы.

Пользовательские роли

Инициализация прав доступа (проверка подлинности с учетом ролей) Параметры

безопасности приложения EPM System определяют доступ пользователя к приложениям,

используя концепцию ролей.

Роли – это разрешения, определяющие доступ пользователя к функциям приложения. Для

дальнейшего уточнения доступа пользователя к своим артефактам, таким как отчеты и

элементы, некоторые продукты EPM System применяют списки управления доступом

(ACL) на уровне объектов. Каждый продукт EPM System предоставляет несколько

стандартных ролей, ориентированных на различные задачи. Каждое приложение,

принадлежащее продукту EPM System, наследует эти роли. Заранее определенные роли из

приложений, зарегистрированных с помощью Shared Services, отображаются в консоли

Shared Services Console. Можно также создать пользовательские роли, комбинирующие

стандартные роли, для удовлетворения определенных требований. Эти роли используются

для инициализации прав доступа.

Процесс предоставления пользователям и группам ролей, принадлежащих приложениям

EPM System, называется инициализация права доступа. Стандартный каталог и

настроенные каталоги пользователей являются источниками информации о пользователях



http://ivan-shamaev.ru/wp-content/uploads/2014/07/SharedServices.png



и группах при инициализации прав доступа. С помощью консоли Shared Services можно

просматривать и инициализировать права доступа пользователей и групп из всех

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

проверки подлинности:

Наименование

роли Описание в Shared Services

Планировщик Планировщик

Интерактивный

пользователь Интерактивный пользователь

Администратор Администратор

Просмотр

пользователя Просмотр пользователя

Массовое

распределение Массовое распределение

Доступ для записи

служб аналитики Доступ для записи служб аналитики

Approvals

Administrator

Controls the Planning Approvals process and can perform actions on

planning units to which they have write access. This role comprises the

Approvals Ownership Assigner Approvals Process Designer, and

Approvals Supervisor roles of Planning

Approvals

Ownership Assigner

Performs the tasks that a Planner role can perform plus, for any member of

the planning unit hierarchy to which they have write access, they can

assign owners, assign reviewers, and specify users to be notified

Approvals Process

Designer

Performs the tasks that can be performed with the Planner role and

Approvals Ownership Assigner role, plus, for any member of the planning

unit hierarchy to which they have write access, they can change the

secondary dimensions and members for the Entities to which they have

write access, change the scenario and version assignment for a planning

unit hierarchy, edit data validation rules for data forms to which they have

access

Approvals

Supervisor

For any member of the planning unit hierarchy to which they have write

access, they can stop and start a planning unit and take any action on a



http://ivan-shamaev.ru/wp-content/uploads/2013/05/shared_services.jpg



Наименование

роли Описание в Shared Services

planning unit. Users with this role can perform the preceding actions even

if they do not own the planning unit. However, they cannot change any

data in a planning unit unless they own it

Task List Access

Manager Assigns tasks to other users

Ad Hoc User Views and modifies Smart Slices and performs ad hoc operations

Ad Hoc Grid

Creator

Performs the tasks that an Ad Hoc User can perform, plus creates and

saves Smart Slices

Администратор бюджетов – специалист финансово-экономического профиля, который

координирует и направляет все процессы, связанные с формированием, контролем и

анализом исполнения бюджета. Именно он отвечает за содержательную часть настроек

системы и за соответствие этих настроек утвержденной методологии планирования и

бюджетирования. Этот сотрудник обладает полным набором прав доступа;

Аналитик бюджетов – сотрудник финансового департамента, исполняющий роль

«связующего звена» между руководителями подразделений и финансовой службой

компании. Его функции заключаются в просмотре, анализе, изменении и представлении

плановых и бюджетных данных, именно он разрабатывает и внедряет правила и модели

планирования, а также создает отчеты для руководства;

Составитель бюджетов (планировщик) – сотрудник, представляющий определенное

структурное подразделение и отвечающий за бюджеты на уровне подразделения и/или

проекта. Этот специалист вводит в систему информацию (вместе с аннотациями),

анализирует бюджетные данные и представляет их на рассмотрение, контролирует

состояние плана или бюджета.

Предоставление прав доступа

1. Через Shared Services Console добавляется новый пользователь и назначаются роли

данному пользователю (правая кнопка мыши, меню Инициализировать). Нового

пользователя необходимо также добавить в Essbase.

2. Зайти в приложение, выбрать пункт меню Администрирование – Приложение –

Настройки.

3. Установить: Режим обслуживания приложения – включить использование приложения

для: “Все пользователи”.

4. Для форм данных добавить доступ данному пользователю.

5. Присвоить доступ к измерениям данному пользователю (Администрирование –

Управление – Измерения). Доступ можно давать как отдельным пользователям, так и

группам.

Добавление доступа к элементам измерений Добавить доступ можно к следующим,

предопределенным измерениям: Account, Entity, Scenario, Version. Тип доступа к

элементам: Чтение, Запись, Нет. Доступ можно настраивать для: Элемент, Дочерние,

Дочерние элементы (включительно), Потомки, Потомки (включительно).

Делегированное администрирование в Shared Services Имеется функционал

построения иерархии администраторов. Каждому администратору назначаются

пользователи, которых он видит и которым он назначает права доступа.





Иллюстрация настройки прав доступа

Пояснения к рисунку: Роли – системные роли, заданные для конкретного продукта Hyperion (например, для

Hyperion Planning в систему зашиты определенные роли, их пользователь не может

менять). Роли определяют права доступа к тому или иному функционалу приложений

платформы Oracle Hyperion.

Группа – группа пользователей, включающая в себя набор ролей по каждому

приложению, к которому группа будет иметь права доступа. Права доступа и доступ к

функциональности приложения наследуются от ролей по каждому приложению.

Пользователь – объект в системе Hyperion Shared Services Console, который содержит в

себе набор ролей по каждому приложению (права доступа к приложению и доступная

функциональность наследуются от ролей), либо пользователь может входить в одну или

несколько Групп и наследовать совокупность прав доступа от этих Групп.

Права доступа (Запись) к формам данных позволяют редактировать состав формы

данных, расположение компонентов формы, состав бизнес-правил, связанных с формой, и

т.п. Права доступа на чтение дают возможность пользователю открывать форму.

Права доступа к измерениям уже влияют на сам ввод данных в приложении. Если на

какое-то одно измерение отсутствуют права доступа на запись, или имеется запрет записи

(в виде исключения), то пользователь не сможет осуществить ввод данных.



http://ivan-shamaev.ru/wp-content/uploads/2013/05/configuring_access_rights_in_hyperion_planning_applications.png



Иллюстрация настройки прав доступа для бизнес-правил, sequences и

макросов (Essbase Security)

Настройка аудита изменений в приложениях

Setting_Up_an_Audit_Trail_in_Planning

Как проводить аудит по пользователям, ролям и

группам пользователей в системе Hyperion Planning?

Суть задачи: составить актуальную карту доступа к приложению с учетом аналитик

пользователи, группы, роли. Где можно получить информацию: Hyperion Shared Services

Console Зачем все это нужно: для описания ввода данных по бюджетному процессу, а

именно чтобы учесть все группы и пользователей, которые участвуют в бюджетном

процессе.

Вариант 1 решения задачи. Шаги выполнения задачи:

1. Открыть Hyperion Shared Services Console -> Директории пользователей -> Native

Directory.

2. На элементе “Пользователи” нажать правую кнопку мыши и выбрать из контекстного

меню “Просмотреть отчет”.

3. Далее выбирая различные параметры отчета можно получить набор отчетов по

приложению.

4. Выгружаем отчеты в формат csv. Возможные отчеты: – Пользователь – Группа – Роль-

Пользователь – Роль-Группа

5. Обрабатываем выгруженные отчеты в Excel вручную или с помощью макросов (VBA),

если это необходимо.

Вариант 2 решения задачи В Oracle Database необходимо сделать join нескольких таблиц

(HSP_OBJECT, HSP_ACCESS_CONTROL, HSP_USERINGROUP, HSP_OBJECT_TYPE) и

определить какие пользователи к каким группам относятся, их доступ к отдельным

объектам в системе.



http://ivan-shamaev.ru/wp-content/uploads/2013/05/Setting_Up_an_Audit_Trail_in_Planning.docx

http://ivan-shamaev.ru/wp-content/uploads/2014/07/security_configuration_scripts_and_other_linkages.png



Как проводить аудит описаний и псевдонимов

элементов измерений приложения Hyperion Planning?

SELECT tbl1.OBJECT_NAME CODE_MEMBER, tbl2.THE_STRING DESC_STRING,

tbl4.OBJECT_NAME ALIAS_NAME

FROM APP_2015.HSP_OBJECT tbl1

LEFT JOIN APP_2015.HSP_STRINGS tbl2 ON tbl1.DESCRIPTION=tbl2.STRING_SEQ

LEFT JOIN APP_2015.HSP_ALIAS tbl3 ON tbl1.OBJECT_ID=tbl3.MEMBER_ID

LEFT JOIN APP_2015.HSP_OBJECT tbl4 ON tbl3.ALIAS_ID=tbl4.OBJECT_ID

WHERE tbl1.OBJECT_TYPE=’32′ AND tbl4.OBJECT_TYPE=’10′

ORDER BY CODE_MEMBER

Форма ввода (форма данных) – представление данных в виде таблицы, позволяющее

пользователям вводить данные в базу данных, а также просматривать и анализировать

данные и сопутствующий текст. Значения отдельных элементов измерений фиксированы,

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

Презентация (Google Disk):

Data Forms in Hyperion Planning.pptx

Best Practices for Designing for Data Forms.pdf

The new Planning Web Form Designer and the creation of formula calculated form

content.docx

Применение псевдонимов (Alias) в формах (Data Form): При создании формы, необходимо на вкладке “Макет” перенести имеющиеся измерения в

столбцы и строки. Далее необходимо нажать на элемент в строке или столбце, справа в

свойствах таблицы данных появятся свойства измерения. Включить отображение

псевдонимов. Отображение псевдонимов в формах настраивается отдельно для каждой

формы. Через EAS можно установить активный Alias для каждого измерения.

Настройка форм данных

Порядок выполнения бизнес-правил в формах: 1. Запускать вручную выполнение бизнес-правил (по умолчанию)

2. Выполнять при загрузке

3. Выполнять при сохранении

Создание составных форм данных

Составная форма собирается из уже готовых простых форм. При создании необходимо

указать те простые формы, которые будут входить в составную форму. А также

необходимо настроить отображение параметров выбора Pages (страницы, т.е. среза).

Составные формы влияют на производительность системы, поэтому их необходимо

использовать только в случаях, когда с помощью простых форм невозможно

удовлетворить то или иное функциональное требование.



https://drive.google.com/file/d/0BxOg0amRzk9vVG94TU9nTTBtVUU/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vcm1RQjh4cTR3SzA/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vbTVlSUJZTHVRdTg/view?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vbTVlSUJZTHVRdTg/view?usp=sharing



Как проектировать и создавать формы данных в

Hyperion Planning? (Best Practices)

Рекомендации по дизайну (проектированию) форм данных

• Выбирать в строках и столбцах формы данных Dense-измерения;

• Размещать Sparse-измерения на страницах или срезах (Point of View – POV);

• Размещать Static-измерения в срезе (POV) и скрывать эти измерерния там, где они не

несут важной информации для пользователя.

• Размещать Scenario, Version and Year измерения на странице везде, где это возможно.

• Использовать динамические пользовательские переменные (dynamic user vairables) и

переменные подстановки (substitution variable) как можно больше.

• Используйте опции для бизнес-правил “Запуск при сохранении” и “Запуск при

открытии” формы данных там, где бизнес-правила могут быть выполнены в течение

короткого промежутка времени (например, менее 30 секунд). Все другие бизнес-правила

должны запускаться в ручном режиме.

• Для версий Hyperion Planning 9.3.0 и более поздних – запускайте длительные бизнес-

правила не через формы данных.

• Ограничивайте количество составных форм данных до двух форм там, где это возможно.

• Используйте опцию “Скрыть отсутствующие данные (skip #MISSING values)”, чтобы не

отображать пустые ячейки на форме. Используется в основном на некоторых отчетных

формах, где не критична информация о пустых значениях.

• Разделяйте одиночные очень большие формы данных на несколько меньших форм

данных с меньшим (количеством строк и столбцов). Например, можно сделать разные

формы для разных подразделений, для разных групп статей, для разных продуктов. Все

зависит от контекста ситуации.

• Минимизируйте использование аннотаций к счету в формах данных.

• Используйте функцию “Mass Allocate” только в формах данных, в которых это

абсолютно необходимо. Эта функция выполняет расчет скриптов, которые могут повлиять

на значения данных, находящихся на пересечениях не доступных для пользователя.

Иными словами, данные могут измениться там, куда пользователь не имеет доступа. Это

приведет к некорректным данным в системе и может повлиять на корректность всех

бюджетов в ходе бюджетной кампании.

Пример оптимального дизайна: Account (Статьи) – Строки

Time Period (Временные периоды) – Колонки

Entity and other dimensions (Финансовая структура и другие Измерения) – Страница/Срез

(POV)

Пример неоптимального дизайна: Entity (Финансовая структура) – Строки

Year (Год) – Колонки

Account, Time Period, and other Dimensions (Статья, Временные периоды и другие

Измерения) – Страница/Срез

Рекомендации по производительности

• Запуск вычислений скриптов при сохранении или при загрузке формы требует

дополнительных ресурсов от сервера Essbase для каждой операции открытия формы или

сохранения данных в форме, выполняемые конечными пользователями. Если необходимо





использовать запуск расчета скрипта при открытии или сохранении формы, то

необходимо использовать переменные runtime prompts для уменьшения объемов запусков

расчетов и минимизации влияния на пользователей сервера Essbase.

• Когда пользователи получают доступ к форме данных с членами, которые динамически

рассчитываются или которые имеют внутри себя формулы (member formula), сервер

Essbase дополнительно нагружается. Данное воздействие наиболее остро влияет на

ресурсы сервера.

• Наибольшее влияние на производительность формы данных оказывает размер сетки.

Размер сетки состоит из ряда строк и столбцов. Размер сетки удваивается, если

приложение использует несколько валют.

• Отрегулируйте число ячеек по отношению к памяти клиентской машины конечного

пользователя. Определить количество ячеек можно умножив количество строк на

количество столбцов.

• Опция “Скрыть отсутствующие блоки” для строк позволяет разместить большие

разреженные измерения в строка, обеспечивая хорошее время отклика, если частота

обращений к форме низкая. Извлекаются только блоки данных. Например, когда

используя эту опцию, Вы размещаете измерение “Сотрудник”, содержащее в себе тысячи

элементов в строках, и помещаете организацию на странице или POV. То в дальнейшем

извлекаются только сотрудники выбранного подразделения.

• Используя опцию “Скрыть отсутствующие данные” может повысить

производительность. Однако, перед использованием этой опции, рекомендуется

проверить ее влияние на производительность.

• Использование аннотаций к статьям (измерение типа Account) влияет на

производительность. Используйте эту опцию только в том случае, если аннотации к

статьям необходимы.

• Администратору следует определить формы данных, используя динамические

пользовательские переменные, чтобы сузить размерности формы данных, которые

необходимы для пользователей. Конечные пользователи могут установить значение

пользовательской переменной в настройках.

• Когда выполняется первая загрузка в Planning, первые запросы в приложении могут

занимать много времени, потому что кэши (caches) не были загружены. Поэтому

рекомендуется, чтобы администратор или продвинутый пользователь предзагрузил

наиболее используемые пользователями формы данных до начала массового

использования сервера Planning после каждой перезагрузки сервера Planning.

• Настоятельно рекомендуется, чтобы администраторы протестировали

производительность форм данных, чтобы убедиться, что производительность интерфейса

соответствует ожиданиям пользователей. Формы данных должны быть протестированы в

сценарии “Использование одним пользователем” и в сценарии “Использование

несколькими пользователями” до внедрения форм в “производство”. В том числе должен

быть выполнен тест одной формы несколькими пользователями одновременно.

• Состав формы данных кэшируется при входе пользователей в приложение Planning.

Один кэш создается для описания состава формы данных, поэтому использование памяти

не зависит от количества пользователей, просматривающих формы данных. Однако,

использование памяти возрастает, если нескольким пользователям необходимо ввести

данные в поля формы данных одновременно.

Скрытие пустых данных в формах: Planning имеет следующую базовую последовательность сокрытия информации (т.е.

убрать от пользователя пустые строчки) на формах данных, в зависимости от настроек

“Скрыть отстутствующие блоки” и “Скрыть отсутствующие данные”.

1. На первом шаге, Planning оценивает состав элементов измерений формы данных и

создает сетку для отправки в Essbase.





2. Если опция “Скрывать отсутствующие блоки” выбрана для строк формы:

2.1. Запрос Planning в Essbase определяет какие элементы в составе формы данных

определяют блоки данных (data blocks). Этот запрос обычно занимает лишь несколько

миллисекунд. (Эта опция наиболее эффективна для разреженных измерений и она не

должна использоваться для плотных измерений.)

2.2. Затем Planning определяет какие элементы имеют доступные блоки данных в Essbase

и какие элементы не ограничены фильтрами безопасности для пользователя (т.е.

отсеиваются элементы, к которым у пользователя нет прав доступа).

3. Далее, Planning создает сетку и отправляет информацию в Essbase для заполнения сетки

данными. (Построенная сетка, как правило, очень мала, так что в результате данные

быстро извлекаются из Essbase).

4. Если выбирается опция “Скрывать отсутствующие данные”, то Planning скрывает

данные для любых пустых элементов. (Эта опция, как правило, выполняется быстро.

Однако, если большой объем данных имеют пустые значения, или имеются пустые блоки

– без данных, процесс с этой опцией требует некоторое время).

5. Planning затем запрашивает в реляционной базе данных (Oracle Database) информацию

по вспомогательной информации (supporting details) и тексту в ячейке (cell text). И

окрашивает ячейку.

6. Веб-форма данных представляется пользователю.

Управление пользовательскими переменными

Пользовательские переменные фильтруют элементы, отображаемые на форме, позволяя

сосредоточить внимание только на интересующих пользователя элементах, например, на

расходах отдела.

1. Администрирование -> Управление пользовательскими переменными. Создаем

переменную.

2. Файл -> Параметры -> Параметры пользовательской переменной. Для каждого

пользователя выбираем 1 элемент из измерения, которое выбрано в переменной.

3. Администрирование -> Управление формами данных. В настройках формы в измерении

выбираем пользовательскую переменную.

Ввод данных в формы данных

Форма ввода данных – это сетки по подобию электронных таблиц со строками и

столбцами для ввода данных.

На начальной странице можно работать в расширенном или в основном режиме.

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

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

установленных администратором. Для переключения в другой режим выберите команду в

меню «Вид». В зависимости от действующего режима можно выбрать команду «Вид >

Расширенный режим» или «Вид > Основной режим».

Пользователь при заполнении данных может дать комментарий к каждой ячейке.

Вспомогательная информация – возможность предоставить более детальное раскрытие





данных введенных в ячейку. К каждой ячейке можно прикрепить документ.

Работа со Smart View

Для начала работы со Smart View необходимо добавить URL-адрес провайдера – Hyperion

Provider. Расположение – http://localserver:8300/HyperionPlanning/SmartView. Выбираем

сервер Essbase -> Приложение -> Куб приложения. Дальше становятся доступны формы,

списки задач и workflow. Доступный функционал Smart View:

Отправить данные

Обновить

Комментарии к ячейкам

Вспомогательная информация

Вложение документов

Заблокировать ячейку

Детализация

Расчет

o Бизнес-правила

o Правила для формы

Настроить

o Корректировка

o Распределение в таблице

o Масс-распределение в таблице

Далее

o Консоль заданий

o Формула элемента

o Указания

Утверждения

Копировать версию

Работа с Ad Hoc Analysis

Ad hoc reporting – отчеты, которые не являются стандартными (экспромт) для

организации и для которых хранилище или витрина данных не оптимизирована в части

повышения быстродействия. Эти отчеты генерируются с помощью

нерегламентированных запросов (ad hoc query) к базе, хранилищу или витрине данных.

Обычно такая отчетность требуется для поддержки принятия решений в исключительных



http://ivan-shamaev.ru/wp-content/uploads/2014/07/supporting_information.png



ситуациях, когда регулярные отчеты не обеспечивают достаточно информации. При этом

пользователю не нужно знать sql, таблицы базы данных, метаданные и прочую

техническую информацию.

Работа в режиме оффлайн

There is value in being able to access a budgeting system while disconnected from the system.

Whether you’re on a plane or staying in a remote location, there’s inevitably a time when a

deadline is looming and you just have to finish your work. Hyperion Planning provides a

solution for this dilemma through the offline capabilities of the Smart View Excel add-in tool.

Smart View is a tool that allows you to pull Hyperion Planning data web forms into Excel. Once

a form is in Excel, you can essentially perform all the same functions that you can in Planning

web. With Smart View, you can input data and save it to Essbase, use the adjust data feature,

enter supporting detail and cell text, and run business rules and calc scripts. You even have the

same look and feel as a web form with expandable parent members, page drop-down boxes,

green read-only cells, and yellow updated cells.

The process for taking a Planning data form offline in version 11 is fairly simple: 1) The application has to first be enabled for offline usage. Set this by going to Administration ->

Manage Properties -> Application Properties and setting ENABLE_FOR_OFFLINE to true. This

is the default setting.

2) Next, you need to enable individual data forms for offline usage. Edit a form, go to the Other

Options tab, and click the Enable Offline Usage box.

3) Open the data form(s) in Smart View and click Take Offline. You can choose to take a single

form, multiple forms, or an entire form folder and its contents offline.

4) Select the page dimension members to store offline. You can either choose to take all page

members or just a subset.

5) Provide a connection name and click Finish.

At this point, the necessary application components are copied from the server to your local

machine. Basically, a smaller version of the application is created on your system, including

necessary outlines, calc scripts, dimension members, data, substitution variables, and web forms.

The download can be quite large depending on the number of items you choose to include. To

minimize the download time and system footprint, you will want to limit the web forms and page

dimensions to only those that you will truly need. Once all the components complete their

download, you can work in your subset of the application to your heart’s content, all while being

disconnected from the network. You can essentially perform the same operations as if you were

still connected, with the following exceptions:

- When you save information, you are saving it to your local machine.

- When you log into the application in Smart View, you no longer log in through the Common

Provider. You now go to Independent Provider Connections and open your offline connection

there (named in step 5 above).

- Currency conversion is not supported for offline usage. This offline connection can be accessed

as many times as you’d like, continually opening, saving, and closing it until it’s synchronized

back to the server.

Take the following steps to push any updates in your offline connection back up to the

network server: 1) Open the offline connection.

2) Click Sync Back To Server.

3) Log into the application on the server.

4) Select which forms, folders, and page members to sync back. After the upload is complete, I

generally delete the offline Independent Provider Connection to remove the application files

from my machine.





Обзор бизнес-правил и Calculation Manager

Бюджетная модель предприятия может потребовать более сложных расчетов, чем те

арифметические действия, которые определяются иерархией аналитических направлений.

Для этого в системе предусмотрены средства описания бизнес-правил. С их помощью

можно производить сложные многошаговые вычисления, применять сложные

экономические правила и распределения, а также применять глобальные параметры (то

есть предпосылки и допущения, являющиеся общими для нескольких счетов). Например,

можно создать процедуру, предусматривающую агрегирование информации по

накладным расходам, с последующим отнесением этой суммы на центры затрат, на основе

некоторой базы распределения (например, метража производственных площадей или

численности сотрудников).

Бизнес-правила также можно использовать для описания отношений между сценариями и

версиями. Например, план доходов компании может быть сформирован в двух вариантах:

стандартный и в расчете на интенсивный рост. Тогда можно создать бизнес-правило,

которое будет автоматически рассчитывать показатели с поправкой на интенсивный рост,

увеличивая значения стандартной версии на 20%.

Бизнес-правила обладают следующими преимуществами перед Calc Scripts: - Запрос входных значений переменных

- Представление бизнес-правил в графическом виде

- Использование Макросов (Macro)

– выделенных в отдельную сущность часто используемых частей расчетного скрипта

- Выстраивание последовательностей бизнес-правил (Business Rules Sequences) с

сохранением значений входных элементов по умолчанию

- Более тонкая настройка прав доступа пользователей к расчетам (как индивидуально к

каждому правилу/последовательности, так и к Проектам (Projects), объединяющим

произвольный набор бизнес-правил)

- Возможность запуска напрямую из командной строки без необходимости написания

дополнительных MaxL/Esscmd скриптов, необходимых для автоматизации запуска Calc

Scripts

В то же время, имеются и некоторые недостатки: - Логи запуска и выполнения бизнес-правил гораздо скуднее, чем логи расчетных

скриптов

- Отсутствие в Business Rules Editor таких приятных мелочей Calculation Script Editor как

поиск с заменой, отмена последнего действия и отсутствие необходимости сохранения

скрипта перед запуском его валидации





Процесс создания бизнес-правил

Рассмотрим основные первоначальные опции настройки правил: SET AGGMISSG

SET CACHE

SET CALCPARALLEL

SET CALCTASKDIMS

SET CCTRACKCALC

SET CLEARUPDATESTATUS

SET CREATENONMISSINGBLK

SET CREATEBLOCKONEQ

SET DATAEXPORTOPTIONS

SET DATAIMPORTIGNORETIMESTAMP

SET EMPTYMEMBERSETS

SET FRMLBOTTOMUP

SET FRMLRTDYNAMIC

SET LOCKBLOCK

SET MSG

SET NOTICE

SET REMOTECALC

SET UPDATECALC

SET UPTOLOCAL

Работа с Calculation Manager

Документ с описанием работы с Calculation Manager (Google Disk): Oracle Hyperion

Calc Manager.docx

Запуск бизнес-правил в приложении Hyperion Planning

Запустить бизнес-правила можно из меню или из формы данных (внизу слева

отображаются доступные бизнес-правила для данной формы):



https://drive.google.com/file/d/0BxOg0amRzk9vcEdiN0VhNEdXeEk/view?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vcEdiN0VhNEdXeEk/view?usp=sharing

http://ivan-shamaev.ru/wp-content/uploads/2014/07/Run_business_rule_1.png



Выбираем бизнес-правило и запускаем:

Выбор Runtime Prompt переменных (на картинке кривой перевод):

Управление циклом утверждения бюджетов через

Planning Units

Planning Units (Бюджетный Блок) – пересечение трех обязательных измерений

(Сценарий, ЦФО, Версия) и одного дополнительного измерения (опционально, в

зависимости от необходимости), с помощью которых моделируется цепочка согласования

бюджетов.

Уровни объектов бюджетирования: 1. Организация в целом;

2. Агрегированные центры прибыли и затрат (уровень бизнес или функционального

направления);

3. Центры прибыли, центры затрат, центры доходов, центры инвестиций;

4. Продукт, клиент, канал сбыта.





http://ivan-shamaev.ru/wp-content/uploads/2013/05/Planning-Units.png



Типы ЦФО при анализе прибыльности в бюджетном процессе:

Управление Planning Unit – создание и сопровождение



http://ivan-shamaev.ru/wp-content/uploads/2013/05/cost-center.png

http://ivan-shamaev.ru/wp-content/uploads/2013/05/planning_unit_manage_1.jpg









Статусы бюджетных блоков

Приложение Planning контролирует бюджеты с помощью блоков планирования, которые

представляют собой сектора данных на пересечении сценариев, версий и объектов. Это

базовый элемент для подготовки, аннотирования, согласования и утверждения данных

плана.

Блоки планирования могут находится в одном из шести статусов: - Не запущен: Начальный статус всех блоков планирования. Администратор начинает

процесс согласования, запуская блок планирования с помощью действия Запустить, в

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







- Первый проход: Начальный статус блоков планирования, выбранных для процесса

составления бюджета. Во время Первого прохода у блоков планирования нет владельцев.

Пользователи, обладающие соответствующим доступом, могут вводить данные и

передавать блоки планирования, находящиеся в статусе Первого прохода. Кроме того,

администраторы могут исключить некоторые или все объекты из блоков планирования,

находящихся в статусе Первого прохода. Готовые к согласованию блоки планирования

переводятся из статуса Первый проход в статус На рассмотрении. При этом им

назначаются владельцы. Как настроить получение уведомление по электронной почте о

назначении владельцем блока планирования см. в разделе Настройка электронной почты.

- На рассмотрении: Блок планирования переводится в этот статус после выполнения

действия Переместить, во время которого определяется пользователь-рецензент этого

блока планирования. Только текущий владелец и администратор могут изменять данные

или выполнять действия с блоками планирования в статусе На рассмотрении. В этом

статусе блоки планирования могут пройти несколько циклов передачи другим

пользователям, завершения рассмотрения и отклонения, пока не будут окончательно

утверждены.

- Завершен: Блок планирования переводится в этот статус после выполнения действия

Завершить. Только текущий владелец и администратор могут изменять данные или

выполнять действия с блоками планирования в статусе Завершен. При завершении

согласования блока планирования его владелец не меняется.

- Не завершен: Блок планирования переводится в этот статус после выполнения действия

Отклонить. Только текущий владелец и администратор могут изменять данные или

выполнять действия с блоками планирования в статусе Не завершен.

- Утвержден: Блок планирования переводится в статус Утвержден после выполнения

действия Утвердить. При этом владельцем блока планирования становится

администратор. Только администратор может изменять данные и работать с

утвержденными блоками планирования. После утверждения всех блоков планирования

цикл составления бюджета завершается.

Примечания: - Во всех статусах, кроме статуса Не запущен, пользователи с доступом для чтения могут

просматривать данные, просматривать статус процесса, просматривать историю его

согласования, а также читать и добавлять новые примечания.

- Некоторые статусы процесса согласования блоков планирования могут быть опущены.

Например, администратор может утвердить запущенный блок планирования в любом

статусе.

- Процесс рассмотрения можно осуществить на более высоком уровне с родительскими

объектами.





Схема согласования бюджетных блоков



http://ivan-shamaev.ru/wp-content/uploads/2013/05/planning_workflow.png



Интерфейс управления процессом согласования

Изменение статуса блока планирования



http://ivan-shamaev.ru/wp-content/uploads/2013/05/workflow_management.png

http://ivan-shamaev.ru/wp-content/uploads/2013/05/workflow_change_status.png



Копирование данных между версиями

С помощью страницы Копирование версий можно копировать данные из одной версии

снизу-вверх или целевой версии в выбранный сценарий или в другую версию снизу-вверх

или целевую версию того же сценария. Например, можно создать версию “Наилучший

вариант” и скопировать часть или все данные этой версии в версию “Наихудший

вариант”, чтобы быстро создать отправную точку для новой версии. Можно выполнять

копирование из версии снизу-вверх в целевую версию и обратно.

Помните: - В версию снизу-вверх копируются только выбранные элементы нулевого уровня.

- При копировании в целевую версию, копируются все выбранные элементы.

- С целью защиты данных в утвержденных бюджетных блоках копирование версии в

утвержденные бюджетные блоки не выполняется.

Примечание. Для успешного копирования данных необходимо при определении

критериев копирования данных указать по крайней мере один элемент измерений Scenario

(Сценарий), Account (Счет), Entity (Объект), Period (Период) и Version (Версия).

Копирование версии: 1. В меню формы Файл выберите команду Рабочий поток, а затем – Копировать версию.

2. В списке Сценарий выберите сценарий, который требуется скопировать.

3. В списке Копировать из выберите версию, из которой необходимо скопировать данные.

4. В списке Копировать в выберите версию, в которую необходимо скопировать данные.

5. Нажмите кнопку Перейти. Объекты для выбранной версии отображаются в списке

Доступные объекты.

6. В списке Доступные объекты выберите объекты, в которые необходимо скопировать

данные. В списке Доступные объекты перечислены объекты (бюджетные блоки),

принадлежащие текущему пользователю, который обладает правом записи. Можно

копировать объекты со статусом Не запущен или Первый проход.

7. Щелкните , чтобы добавить объект в список Выбранные объекты, или щелкните , чтобы

добавить все объекты из списка Доступные объекты. Щелкните или , чтобы удалить

объекты из списка Выбранные объекты.

8. Примечание. Для копирования комментариев или аннотаций, связанных со счетами,

выберите параметр Копировать аннотации счета. Будут скопированы только аннотации

выбранных объектов. Если выполняется копирование в версию снизу-вверх, будут

скопированы только объекты нулевого уровня (и их аннотации).

9. Примечание. Чтобы копировать текст ячейки, используйте параметр Копировать текст

ячейки.

10. Примечание. Чтобы копировать сопутствующую вспомогательную информацию,

используйте параметр Копировать вспомогательную информацию.

11. Нажмите кнопку Копировать данные.

Примечание. Дождитесь сообщения о завершении копирования версии перед загрузкой

следующей веб-страницы.





Управление списками заданий

Рабочее место пользователя – представляет собой список последовательно

сгруппированных задач, описывающих порядок формирования бюджета Компании.

Настройка электронной почты

Если электронная почта настроена, а уведомления включены, приложение Planning

уведомляет пользователей об их назначении владельцами бюджетных блоков. Внешний

вид вкладки Параметры приложения для владельца приложения отличается от внешнего

вида для других пользователей, поскольку владелец приложения должен указать

почтовый сервер приложения до того, как другие пользователи включат уведомления по

электронной почте.

Чтобы настроить и включить уведомления по электронной почте для себя: 1. Выберите Файл, затем Параметры.

2. Щелкните пиктограмму Planning и выберите Параметры приложения.

3. В поле Адрес электронной почты введите свой адрес электронной почты.

4. В диалоговом окне Включить уведомления по электронной почты выберите Да или Нет.

5. Примечание. Чтобы владелец приложения мог получать копии уведомлений по

электронной почте выберите для параметра “Копия для владельца приложения” значение

Да.

6. Если пользователю нужно получать уведомления по электронной почте о завершении

или ошибках в запущенных им заданиях (например, бизнес-правилах), в окне

Уведомление консоли заданий выберите Да.

7. Нажмите кнопку Сохранить. Теперь пользователь будет получать уведомления о

назначении его владельцем бюджетных блоков. Тема письма будет иметь следующий

формат: НОВЫЙ ВЛАДЕЛЕЦ: план АБВ (сценарий, версия, объект).



http://ivan-shamaev.ru/wp-content/uploads/2013/05/task_management.png



8. Повторите эти действия для каждого из приложений, для которых требуется включить

функцию уведомления по электронной почте.

Состав системы бюджетирования и ее интеграция с

другими системами

Основные элементы процесса бюджетирования

Стратегический контур планирования: - Целевые показатели деятельности;

- Бюджет доходов и расходов;

- Бюджет движения денежных средств;

- Бюджет инвестиций и капитальных вложений;

- Баланс.

Годовой контур планирования: - Бюджет продаж продукции;

- Бюджет запасов;

- Бюджет производства;

- Бюджет капитальных затрат на строительство;

- Бюджет ИТ/Автоматизации;

- Бюджет на маркетинг;

- Бюджет персонала;

- Бюджет инвестиций;

- Мастер бюджеты (БДР, БДДС, Баланс).

Распределение расходов (аллокации) в годовом контуре планирования: 1) Распределение косвенных расходов обслуживающих подразделений на центры

прибыли (пропорционально использования площади объекта, численности персонала,

объему продаж и т.п.);

2) Распределение доходов и расходов на продукты (по коэффициенту трудозатрат или

пропорционально доходу и т.п.);

3) Распределение доходов и расходов на группы клиентов (пропорционально доходу и

т.п.).



http://ivan-shamaev.ru/wp-content/uploads/2013/05/composition-of-budgeting-system.png



Настройка правил аллокаций

1. Метод прямой аллокации – сумма расходов за один шаг распределяется по ЦФО

пропорционально значениям заданного драйвера аллокации;

2. Метод каскадной аллокации – сумма расходов распределяется по ЦФО за несколько

шагов в заданной последовательности. На каждом шаге рассчитываются разные

коэффициенты распределения и драйвер аллокации может быть разным.

3. Метод матричной (перекрестной) аллокации – коэффициенты распределения

рассчитываются сразу для всех шагов аллокации. Является более точным методом по

сравнению с каскадным.

Схемы взаимосвязей между бюджетами

Взаимосвязи между бюджетами (pdf-файл)>>>

Взаимосвязи между функциональными и основными бюджетами.pdf >>>

Взаимосвязь между основными формами финансовой отчетности:

Баланс отражает состояние активов и пассивов компании в конкретный момент времени.

Отчет о прибылях и убытках показывает, как капитал собственников изменился за

период между двумя балансами в результате коммерческой деятельности. Отчет о

движении денежных средств также показывает изменения за отчетный период, однако

касается остатков денежных средств (и эквивалентов денежных средств) за период между

двумя последовательными балансами.



http://ivan-shamaev.ru/wp-content/uploads/2014/07/Relationship_between_budgets.pdf

http://ivan-shamaev.ru/wp-content/uploads/2014/07/relationship_between_many_budgets.pdf

http://ivan-shamaev.ru/wp-content/uploads/2014/07/relationship_between_balance_pnl_cashflow.png



Связь между финансовыми отчетами:



http://ivan-shamaev.ru/wp-content/uploads/2014/07/relationship_between_the_financial_statements.png



Схема управленческого учета:

Лучшие практики по бюджетированию:



http://ivan-shamaev.ru/wp-content/uploads/2014/07/scheme_of_management_accounting.png

http://ivan-shamaev.ru/wp-content/uploads/2014/07/Budget_process_best_practice.png



Схема взаимосвязей между балансом, отчетом о прибылях и убытках и отчетом

движения денежных средств



http://ivan-shamaev.ru/wp-content/uploads/2014/07/relationship_balance_cash_flow_statement_and_pnl.png



Бюджетирование производственного предприятия



http://ivan-shamaev.ru/wp-content/uploads/2013/05/budget-of-production.png



Еще одна схема процесса бюджетирования производственного предприятия:

Бюджетирование в банке

Бюджетирование в Банке – это элемент управленческой технологии, методологии и

подхода, который включает процесс составления, доведения и корректировки финансовых

планов (результатов деятельности Банка имеющих четкое финансовое отражение);

оперативного учета и контроля операций в разрезе организационно-бюджетной структуры

Банка в соответствии с принятыми бюджетными правилами и регламентом.

Планово-бюджетное управление как технология управления включает:

Методику

Организацию

Информационное обеспечение



http://ivan-shamaev.ru/wp-content/uploads/2013/05/budget-of-production2.png



Многомерное представление данных для Банка:

Основные блоки бюджетного процесса в коммерческом Банке:



http://ivan-shamaev.ru/wp-content/uploads/2013/05/Multidimensional_Data_Model.png

http://ivan-shamaev.ru/wp-content/uploads/2013/05/the_main_blocks_of_the_budget_process_in_a_commercial_bank.png



Бюджетный цикл в банке



http://ivan-shamaev.ru/wp-content/uploads/2013/05/scheme-of-the-budgeting-process-in-banks.png

http://ivan-shamaev.ru/wp-content/uploads/2013/05/budget_process_steps.jpg



Бюджетирование в ритейле/торговой компании



http://ivan-shamaev.ru/wp-content/uploads/2013/05/retail_budget.gif



Бюджетирование в страховании

Бюджетирование в нефте-газовой сфере



http://ivan-shamaev.ru/wp-content/uploads/2013/05/budgeting-in-insurance.png

http://ivan-shamaev.ru/wp-content/uploads/2013/05/budget_oil.png



Бюджетирование в строительстве

Пример плана управления проектом

Этап 1. Определение проекта

Определение бизнес-требований

Архитектура бизнес-процессов

Предварительная функциональная и техническая архитектура

Разработка расширений/дополнительного ПО (рассылка писем на основании

данных аудита, Java Script для проверки значений, настройка соответствия

справочников, загрузка данных)

Подготовка окружения

Обучение проектной группы

Управление проектом

Этап 2. Аудит первого и второго этапов

Модель бизнес потоков

Настройка и демонстрация групп бизнес-процессов в системе

Функциональная и техническая архитектура

Стратегия тестирования

Создание демо-примера для показа



http://ivan-shamaev.ru/wp-content/uploads/2013/05/scheme-of-the-budgeting-process-in-building.png



Обучение проектной команды

Подготовка тестового окружения Контрольные точки

Этап 3. Проектирование

Функциональный дизайн расширений

Описание настроек системы в рамках тестовой среды

Описание настроек прав доступа в рамках тестовой среды

Сценарии тестирования системы

Этап 4. Построение

Технический дизайн расширений/дополнительного ПО

Тестирование расширений

Инструкции пользователя

Тестирование системы

План запуска в эксплуатацию

Этап 5. Переход

Донастройка системы

Создание инструкций

Обучение пользователей

Права доступа

Установка ПО на рабочие места пользователей

Документы

Пример этапов реализации проекта Hyperion Planning

1. Инсталляция, настройка серверов, среды разработки, миграции

2. Определение состава стандартных (обязательных) измерений Hyperion Planning: Статьи

финансовых бюджетов, ЦФО, Сценарии, Версии, Валюта

3. Определение состава пользовательских измерений Hyperion Planning: Продукты,

Каналы продаж, Уровни аллокации, Статьи для операционных бюджетов и др.

4. Определение локаций для измерений, состав форм ввода

5. Разработка структуры измерений в приложении

6. Разработка слоев приложений для хранения вводимых данных, технических данных,

расчетных данных, импортированных данных и т.д.

7. Разработка форм ввода для операционных бюджетов, финансовых бюджетов, бюджетов

капитальных затрат и финансовой деятельности, Бюджетов управления персоналом

- Разработка структуры каталогов для прогнозных форм

- Разработка структуры каталогов для плановых (бюджетных) форм

- Разработка структуры каталогов для фактических форм

- Разработка структуры каталогов для форм с техническими данными и различными

коэффициентами (в т.ч. для аллокации)

8. Реализация алгоритмов расчета бюджетов во взаимосвязях между собой

9. Разработка алгоритмов аллокаций

- Аллокация расходов, не отнесящихся к конкретным подразделениям на целевые

подразделения.

- Аллокация арендных расходов на отдельные подразделения

- Аллокация управленческих расходов

- Аллокация общехозяйственных расходов





- Аллокация складских расходов

- Аллокация транспортных расходов

- Аллокация маркетинговых расходов

- Аллокация IT затрат на подразделения

- Аллокация доходов

- и т.д.

10. Отчетность: Отчет о прибылях и убытках (P&L), Отчет ДДС, Балансовый отчет

11. Настройка загрузки фактических данных из учетных систем

12. Настройка workflow, цепочек утверждений бюджетов

13. Настройка системы прав доступа

- Настройка пользователей, групп пользователей и ролей пользователей в Hyperion Shared

Services Console

- Настройка прав доступа к формам и измерениям в Hyperion Planning

14. Реализация возможностей drill-through (расшифровки) по фактическим данным

15. Реализация копирования данных из одной версии и сценария в другую пару версия и

сценария

16. Отчетность для сверки прогноз-план-факт

17. Процесс контроля отклонений факта от плана

18. Отчетность для проверки рассчитанных аллокаций





Типовая схема проекта внедрения Hyperion Planning

(“Ланит”)



http://ivan-shamaev.ru/wp-content/uploads/2013/05/project_statements.jpg



Пример хода реализации проекта

На практике описанный подход к реализации проекта детализируется

последовательностью следующих фаз и шагов:

Инициирование проекта 1) Приказ о формировании бюджетного комитета объединенной организации (группы

компаний);

2) Приказ о старте проекта построения системы бюджетирования на уровне всей

объединенной организации (группы компаний) с назначением ответственного за проект –

(как правило, данную функцию выполняет финансовый директор);

3) Выбор нескольких бизнес-единиц в качестве «пилотных» для внедрения системы

бюджетирования и назначение ответственного от каждой бизнес-единицы;

4) Выбор компаний-подрядчиков, осуществляющих управленческий консалтинг и

внедрение информационной системы;

5) Оценка требуемых ресурсов (временных и материальных) для выполнения проекта для

«пилотных» бизнес-единиц;

6) Организацию рабочей группы проекта, включающую всех ответственных за проект

менеджеров объединенной организации (группы компаний) и «пилотных» бизнес-единиц,

а также представителей проектных команд компаний-подрядчиков;

7) Наделение рабочей группы полномочиями по принятию решений, обязательных для

всех бизнес-единиц, вовлеченных в «пилотный» проект

Цель данной фазы – официально стартовать проект, определить участников проекта, их

полномочия и ответственность, сделать оценку сроков и стоимости, а также создать

укрупненный план реализации.

Планирование проекта 8) Детализация задач в плане (содержание, ресурсы, стоимость);

9) Определение промежуточных этапов;

10) Идентификация рисков и планирование управления рисками;

11) Планирование управления изменениями

На данной фазе определяется, как должен управляться и выполняться проект.

Реализация проекта 12) Изменение оргструктуры «пилотных» бизнес-единиц: создание/реорганизация

подразделений, участвующих в сопровождении бюджетного процесса и бюджетном

контроле;

13) Разработка и согласование регламентов выполнения бюджетного процесса (на уровне

идентификации последовательности шагов и исполнителей) для каждой «пилотной»

бизнес-единицы и объединенной компании (группы компаний);

14) Разработка модели бюджета объединенной компании (группы компаний) и

«пилотных» бизнес-единиц;

15) Развертывание информационной системы; первоначальная настройка модели и

процессов согласования и утверждения бюджета;

16) Разработка структуры и процедур наполнения единого информационного хранилища

фактической информации (интеграция с системами автоматизации управленческого и/или

финансового учета) для дальнейшего её импорта в систему автоматизации

бюджетирования с целью проведения план-факт анализа;

17) Комплексная настройка и доработка информационной системы (функциональность

системы автоматизации бюджетирования и её интеграция с хранилищем фактических

данных);

18) Обучение ключевых пользователей;

19) Тестовые испытания с привлечением ключевых пользователей;

Мониторинг проекта 20) Управление содержанием, сроками и стоимостью;





21) Управление изменениями;

22) Управление рисками;

23) Отчетность по выполнению проекта

На трех последних фазах следует остановиться отдельно. По сути, это не

последовательные, а итерационно-выполняемые группы задач: в рамках каждой итерации

необходимо выполнять и задачи и планирования, и реализации, и мониторинга.

Результатом каждой итерации должен быть хотя и ограниченный, но согласованный набор

и изменений оргструктуры, и регламентов, и информационной системы (с настроенной

моделью бюджета и автоматизированными процессами согласования и утверждения). И

фактически результат работы управленческих консультантов должен являться

непосредственно постановкой задачи на автоматизацию, описанной на языке, понятной

бизнес-пользователям.

Участники проекта



http://ivan-shamaev.ru/wp-content/uploads/2013/05/project-participants.png



ORACLE AIM

В проекте внедрения системы используется стандартизированный подход методологии

AIM. Данный подход представляет собой разделение процесса проектирования

архитектуры на набор специфических задач, обеспечивающих эффективную работу

группы архитекторов, своевременную коммуникацию с другими функциональными

группами и гарантирующих успешное завершение всего процесса при успешном

выполнении каждой задачи.

Методика внедрения приложений Oracle (AIM) является базовым инструментом при

организации и проведении пуско-наладочных работ по внедрению Приложений на

сложных, территориально распределенных объектах автоматизации. Этот метод состоит

из четко определенных, хорошо управляемых процессов, охватывающих все этапы

внедрения приложений. AIM представляет собой интегрированный подход, помогающий

правильно спланировать и отследить все этапы внедрения, что обеспечивает достижение

желаемого результата в пределах временных и бюджетных рамок проекта. AIM

определяет рабочие требования в начале проекта и обеспечивает их наглядность в течение

всего внедрения. При использовании данного метода появляется четкое понимание

рабочих требований, которым должна отвечать построенная система. Несмотря на то, что

методология разработана для средних и больших проектов, она также применима и для

малых по масштабу проектов. Изначально метод создавался для внедрения Oracle

Applications, однако он может с успехом применяться с минимальными изменениями и

для других технологий, а также программных продуктов.

AIM состоит из следующих фаз:

Обследование • руководство Предприятия руководит и поддерживает проект, что ясно понимается всеми

вовлеченными в проект сторонами;

• цели и задачи проекта ясно сформулированы;

• активное участие ключевых сотрудников Предприятия в проекте;

• доступ к информации по существующим бизнес-процессам. Анализ операций


• глубокое понимание реорганизуемых бизнес-процессов и соответствующей стандартной

функциональности внедряемой прикладной системы.

Проектирование решения • ясно задокументированные настроечные параметры системы;

• составленные на основе новых бизнес-процессов сценарии тестирования системы;


• адекватные знания возможностей и функций прикладной системы и технологий

разработки;

• соблюдение границ проекта при выполнении проектирования разработок;

• утвержденный процесс контроля за изменениями границ проекта.

Реализация • документация по разработке (функциональный и технический дизайн);

• тестирование программы конвертации данных для обеспечения переноса;

• достаточность времени и ресурсов.

Переход • реальные ожидания всех участвующих сторон;

• утвержденный план перехода;

• соответствующая техническая и прикладная архитектура;

• обученные конечные пользователи; понимание всеми сотрудниками новых задач и

своего вклада в изменения организации;

• удовлетворительная производительность при приемочных тестах.

Запуск/Эксплуатация





• обученные конечные пользователи; понимание всеми сотрудниками новых задач и

своего вклада в изменения организации;

• аккуратный сбор информации об истории транзакций, объемах данных;

• соответствующая техническая и прикладная архитектура;

• обеспеченная техническая поддержка Oracle.

AIM – статья про стандарт

ORACLE PJM

Методология Управления Проектами Oracle PJM (Project Management Method) определяет процедуры и контрольные точки для решения задач управления проектом, что

позволяет координировать выполнение проектных работ, и предлагает шаблоны

проектных документов. Задачи PJM организованы в процессы, которые помогают понять,

какие задачи управления проектом и в какой последовательности должны быть

выполнены для достижения намеченной цели:

- В процессе Контроля и отчетности определяются границы и подход к проекту,

осуществляется управление изменениями и контроль проблем, рисков и спорных

вопросов. В этом процессе происходит подготовка отчетности о ходе работ и состоянии

проекта, используемой для контроля Плана Качества.

- В процессе Управления Работами определяются работы, выполняемые в проекте, и

отслеживается их выполнение и сдача Заказчику.

- В процессе Управления Ресурсами устанавливаются требования к составу и

квалификации персонала для реализации проекта, а также требования к используемому

оборудованию, и отслеживается их выполнение. – В процессе Управления Качеством

определяются критерии качества для обеспечения соответствия проекта заданным целям и

ожиданиям на протяжении всего жизненного цикла проекта.

- Процесс Управления Конфигурацией хранит, организует, отслеживает и контролирует

все входящие и исходящие компоненты проекта. Он также обеспечивает единое

хранилище информации по проекту. Задачи внутри каждого процесса привязаны к

деятельности по управлению проектом на всем его протяжении. Такая деятельность

интегрирована в план проекта, который, в свою очередь, поделен на фазы и показывает,

когда именно соответствующие задачи должны быть осуществлены.

- Во время фазы Планирования проекта определяются рамки работ, границы проекта,

стандарты качества, временной график и стоимость. Также утверждается организация

проекта и ресурсы, и назначаются ответственные за те или иные задачи. Фаза

Планирования этапа уточняет задачи и планы проекта, а также процедуры для

конкретного этапа.

- Задачи фазы Контроля выполняются параллельно с выполнением этапов реализации

проекта. Здесь выполняется контроль, руководство и отчетность по проекту.

- Задачи фазы Завершения этапа обеспечивают окончание и сдачу-приемку результатов

соответствующего этапа реализации проекта. Фаза Завершение проекта знаменует

успешное завершение проекта и урегулирование всех оставшихся нерешенными вопросов



http://www.cfin.ru/itm/standards/manual_oracleaim.shtml

http://ivan-shamaev.ru/wp-content/uploads/2013/05/oracle_pjm.jpg



до закрытия проекта. Методология PJM поддерживается автоматизированными

средствами ведения библиотеки проекта, и при необходимости Заказчику предоставляется

возможность контроля, согласования и утверждения проектных документов посредством

использования электронной почты, веб-браузера и офисных приложений, таких как MS

Word и MS Project.

СКАЧАТЬ ДИСТРИБУТИВ AIM & PJM >>>



https://drive.google.com/file/d/0BxOg0amRzk9vRldrTkpBNEpXbms/edit?usp=sharing



Варианты реализации (взято из презентации

“Ситроникс”)

Сравнение вариантов реализации

• What’s New in Oracle Hyperion Planning and Budgeting Solutions 11.1.2.3.pdf (Google

Disk)

• Oracle_Hyperion_Planning_11_Essentials - EXAM 1Z0-533 сертификация с ответами

• Hyperion_Planning_4.1_Consultant_EXAM_1Z0-259 - сертификация для

консультантов Hyperion Planning с ответами

• Exam Name – Hyperion Planning 4.1 Administrator (Demo)

• Hyperion Planning 9.3 Administrator I & II (Exam Code 1Z0-272)



https://drive.google.com/file/d/0BxOg0amRzk9vU1dJY1Z3VTlqTUE/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vU1dJY1Z3VTlqTUE/edit?usp=sharing

http://ivan-shamaev.ru/wp-content/uploads/2013/05/Oracle_Hyperion_Planning_11_Essentials.pdf

http://ivan-shamaev.ru/wp-content/uploads/2013/05/Hyperion_Planning_4.1_Consultant_EXAM_1Z0-259.pdf

https://drive.google.com/file/d/0BxOg0amRzk9vWmRnd1RFU0wwRVE/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vaFRWb1JxSzV6QW8/edit?usp=sharing

http://ivan-shamaev.ru/wp-content/uploads/2013/05/project.png

http://ivan-shamaev.ru/wp-content/uploads/2013/05/project_realization.png



1) Oracle Hyperion Performance Lab

2) Getting Started with Oracle Hyperion Planning 11

3) Oracle Essbase 11 Development Cookbook

4) О продуктах Oracle Hyperion

5) Заметки администратора

Презентации из интернета (Google Disk) в открытом

доступе

FY 2013-14 Smart View Training Manual.pdf

FY13 Budgeting Software Training.pdf

Hyperion Essbase Basics.pdf

Hyperion Forecast Training Guide.pdf

Hyperion Look & Feel Preview.pdf

Hyperion Planning 9.3 Create and Manage Applications – Volume II. Student Guide.pdf

Hyperion-Essbase-Tutorials.pdf

Oracle Hyperion Planning Calculation Manager – Fusion Edition, 11.1.1.pdf

PLANNING APPLICATION CREATION.doc

University of California, San Francisco – Hyperion Planning Overview.pdf

Internal Workings of Essbase-ASO & BSO Secrets Revealed MIOAUG

Lab 2.2 Calculation Scripts – Essbase

Optimizing Oracle Essbase Formulas & Calc Scripts

Pre-Tuning and Sizing Your Hyperion Planning and Essbase Applications Before Building

Anything

Sydney – Top 10 Essbase Optimization Tips that Give You 99 Percent Faster Calculations

Practice Oracle Hyperion Planning 11-1-2-2

Введение в бюджетирование. Финансовая структура

Achieving a Common Goal – Hyperion Center of Excellence.pdf

Budget Training Manual Updated for FY11 Budget.pdf

HP Preview Aug2013.pdf

Hyperion Planning Application Reference Manual.pdf

Hyperion Planning user manual.pdf

Introductory Training Guidelines.pdf

OAUG Insight 2013-q2.pdf

Oracle Essbase 11.1.2 Bootcamp – Student Guide (Volume 1).pdf

Oracle Essbase 11.1.2 Bootcamp – Student Guide (Volume 2).pdf

Oracle Essbase 11.1.2 Bootcamp – Activity Guide.pdf

Oracle HP – Планово-бюджетное управление для банков (Борлас).pdf

Smart View Basics Presentation (4-4-13).pdf

Workforce Planning Resource Guide for Public Sector Human Resource Professionals.pdf

Создание и инициализация приложения Hyperion Planning 11.1.2.pdf

Edward J. Cody – The Business Analyst’s Guide to Oracle Hyperion Interactive Reporting 11 –

2010.pdf

Oracle Hyperion 11.1.2.2 Tips and Tricks.pdf

FY 2014-15 Smart View Training Manual.pdf

Detailed Design (Hyperion Planning) – University of British Columbia.pdf

Hyperion Planning – Training Manual Finance Administrators (Symphony).pdf



http://essbase.ru/

https://docs.google.com/file/d/0BxOg0amRzk9vR2JrMHNfMjF3Uzg/edit?usp=sharing

https://docs.google.com/file/d/0BxOg0amRzk9vLWNsTDhCSWZZYkE/edit?usp=sharing

http://hyperionsoft.blogspot.ru/

http://hyperion-planning.blogspot.ru/

https://drive.google.com/file/d/0BxOg0amRzk9vdExvLWdEdjFrbHM/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vR2I5eDlfQUJyLU0/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vNWNIUzhGR1lyUjA/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vQUJ5ZnA4STkzSnM/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9venIxd0Z3UmluTnc/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vSmdMZVo5OVlhMFU/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vbVdWTlFJYW03UnM/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vczRtYVc1c3dyV28/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vQXVIQ0IxY3FVWEE/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vQnI4QVR1RjlCSWM/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vc081MGJPTDRnQ0U/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vZHc0a3lYRlQ1ck0/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vN3VqSklsRFlWY28/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vcnZSRjlrSlRkOU0/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vcnZSRjlrSlRkOU0/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vQTJmMWxScUV3a0U/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vb040NllncFRtMzQ/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vYUR2NWREczNQV28/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vdmxGek9mZmFPczQ/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vVXR5QnRpMC0wNTQ/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vYlBaUFNiNDRhUFU/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vZnJwNF85ZFJYams/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vZzZUT09vX2QxOHM/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vUTgwWFJVT21DT1k/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vMXAxVjdIeFFEd0E/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vMUQwbXRjUEVSRnc/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vVVl4Tk9rbUQtYm8/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vbm9uMV9VVzdKVXc/view?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vNnJmT0RObWpWVDA/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vYVBSLXp2QTRUSlk/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vakttRUVGb0stb00/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vbnVfVXJUVkVMcnc/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vVjVzRGh3WmFuQ1k/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vVjVzRGh3WmFuQ1k/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vcmdtbjFVckJOQlU/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9veUcwZ1lac3hiZDA/edit?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vS0FUbGprYmdUanM/view?usp=sharing

https://drive.google.com/file/d/0BxOg0amRzk9vVVVBUXpVcnVtTnM/view?usp=sharing