This is going to be the first of many blog posts where I will be posting my experiences with various projects that I've been involved for the last seven years ! I do regret that I should have done this much earlier, since now I am having a hard time remembering things I did few years back !
The basic philosophy of any Hyperion Planning implementation is always the same: Shifting client's Planning and Budgeting processes from tiring Excel based spreadsheets to quick and easy Essbase cubes. Actual data is brought in from another system, mostly some ERP system like Oracle ERP, SAP etc. This data needs to be pushed to Hyperion systems. Various implementations use variety of techniques to achieve this.
Lets talk about fast food restaurant business. I will be dividing this posts in various sections:
Fast Food business Budgeting and Forecasting philosophy:
Restaurant business is very tricky, especially when it comes to fast food restaurants like McDonald's or Domino's Pizza. Margins per food item sold are not very high, so you want to sell more at any given time while keeping the costs at a minimum. What are the costs involved ? Well, it can be as small as tissue papers or sauce sachets to as big as automated cooking machines (French Fries' making machine, ovens etc). Then there is the cost of human resources, electricity, water. Not to mention, food wastage adds a lot to costs of running a FF restaurant.
To make matters even complicated, FF restaurants plan on a daily basis unlike monthly or weekly in most manufacturing business. So, planners will meticulously plan for each day at the start of each month (or the end of previous month). Why ? Simply because human eating patterns vary. Next week there is some football match, so people are going to be glued to their TVs, ordering Pizzas. Some Marvel Comic movie is going to get released in the theatre next to your outlet, more people will have some junk food for the next two weeks. Some holiday is coming, people will prefer to stay indoors, so no business.
Planning and Budgeting in Hyperion Planning:
Hyperion Planning deals with overall business and the motive of that is to have P&L and Balance Sheet reports, along with some Sales or Expenses reports.
Point to be noted here is that inventory planning, that is, how many buns you will order for next week or how many burgers you need to sell tomorrow, are not covered in Hyperion Planning model. We must, for the sake of simplicity, concentrate on 'Revenue' of an outlet.
Keeping that in mind, we try to keep the Sales account hierarchy as simple as possible. Instead of listing revenue from each food item sold, we only have Food sales.
Keeping this in mind, we arrive at what can be our possible dimensions:
----------------------------------------------------------------------------------------------------------------------
Account: Hierarchy must be derived from their existing P&L and other reports. ERP structure can also be used as a reference although ERP can be too detailed. So we might have to prune it to fit in our system.
Period: One of the important dimensions which needs careful thought as it cannot be changed later. Food Budgeting and Planning can be done either at a daily, weekly or monthly level. Daily and Weekly Planning requires custom period hierarchy which can complicate things further especially when leap years and week adjustments are considered. One advantage of having daily or weekly calendar is you can do more with your Hyperion applications. e.g. weekly sales plan, daily sales report, trend analysis etc.
When using on-premise Hyperion system, this can be achieved easily as you can have multiple applications with varying Period dimensions. Same cannot be the case with PBCS as there is a limitation of one application and Period dimension is shared across the cubes. We need to keep this in mind when proposing a solution to the client.
When your start month is different than January, months of a FY can spill over to the next year in Planning application, this is a point worth noting. It can be handled using correct aliases along with period specific calculations.
Entity: Usually Entity dimension is simpler in case of FF restaurant chains. Outlets usually roll up in an uncomplicated manner, say, one outlet rolls up to a city, which rolls up to a district, which rolls up to a state and then a country.
What complicates matters here is the classification of outlets: Some can be classified based on the number of tables (size), business hours (24x7), newly opened (this decides whether it can be considered for next year's budget) just to name a few. Discuss this with the client in order to come to an agreement as to which one is going to be the primary roll up and whether other attributes can be accommodated in it.
Custom Dimensions : Product: Consider this only if client is planning and budgeting by food items (in my case, they did not). In some cases, Food Sales by products can be accommodated within Account dimension itself.
Assets : Assets can be accommodated within account hierarchy if the calculations are simple else we might need to have a separate dimension created.
Manpower/ HR: Ideally, this should be taken up in a separate application altogether. Depending on whether it is a PBCS implementation or on-premise, we must decide what best solution can be offered.
-------------------------------------------------------------------------------------------------------------------------
Business Logic:
Sales and Cost of Sales calculations are simple, based on year on year percentage growth. Since seasonality is crucial in food business, we usually consider figures of the month (or lowest level member) of previous year for calculating Budget figures of same month of next year.
Weekly/Daily sales analysis, Manpower planning (on a daily basis) can be complicated. This can severely impact delivery timelines as it increases testing and validation time. We must keep this in mind while committing to the client.
Depreciation logic is same as the one in manufacturing business, Hyperion Calc manager has in-built depreciation calculation functions which are pretty straight forward.
Data Integration: FDMEE and ODI remain the best choices for catering to data integration solutions. Before we begin with the implementation, we must at all cost, finalize this part of the system as it is the foundation of Hyperion solution. On a PBCS environment, this can be very simple as we cannot use any other tool than FDMEE.
Data forms and Reports: Reports are easier said than done. It is better to present a few sample reports to the client while the design and implementation is in progress. Their demands can be catered to by doing minor changes before the application is finalized. Since data forms are the first things which users interact with the system, letting them get a hang of the system right from the start is a good practice.
The basic philosophy of any Hyperion Planning implementation is always the same: Shifting client's Planning and Budgeting processes from tiring Excel based spreadsheets to quick and easy Essbase cubes. Actual data is brought in from another system, mostly some ERP system like Oracle ERP, SAP etc. This data needs to be pushed to Hyperion systems. Various implementations use variety of techniques to achieve this.
Lets talk about fast food restaurant business. I will be dividing this posts in various sections:
Fast Food business Budgeting and Forecasting philosophy:
Restaurant business is very tricky, especially when it comes to fast food restaurants like McDonald's or Domino's Pizza. Margins per food item sold are not very high, so you want to sell more at any given time while keeping the costs at a minimum. What are the costs involved ? Well, it can be as small as tissue papers or sauce sachets to as big as automated cooking machines (French Fries' making machine, ovens etc). Then there is the cost of human resources, electricity, water. Not to mention, food wastage adds a lot to costs of running a FF restaurant.
To make matters even complicated, FF restaurants plan on a daily basis unlike monthly or weekly in most manufacturing business. So, planners will meticulously plan for each day at the start of each month (or the end of previous month). Why ? Simply because human eating patterns vary. Next week there is some football match, so people are going to be glued to their TVs, ordering Pizzas. Some Marvel Comic movie is going to get released in the theatre next to your outlet, more people will have some junk food for the next two weeks. Some holiday is coming, people will prefer to stay indoors, so no business.
Planning and Budgeting in Hyperion Planning:
Hyperion Planning deals with overall business and the motive of that is to have P&L and Balance Sheet reports, along with some Sales or Expenses reports.
Point to be noted here is that inventory planning, that is, how many buns you will order for next week or how many burgers you need to sell tomorrow, are not covered in Hyperion Planning model. We must, for the sake of simplicity, concentrate on 'Revenue' of an outlet.
Keeping that in mind, we try to keep the Sales account hierarchy as simple as possible. Instead of listing revenue from each food item sold, we only have Food sales.
Keeping this in mind, we arrive at what can be our possible dimensions:
----------------------------------------------------------------------------------------------------------------------
Account: Hierarchy must be derived from their existing P&L and other reports. ERP structure can also be used as a reference although ERP can be too detailed. So we might have to prune it to fit in our system.
Period: One of the important dimensions which needs careful thought as it cannot be changed later. Food Budgeting and Planning can be done either at a daily, weekly or monthly level. Daily and Weekly Planning requires custom period hierarchy which can complicate things further especially when leap years and week adjustments are considered. One advantage of having daily or weekly calendar is you can do more with your Hyperion applications. e.g. weekly sales plan, daily sales report, trend analysis etc.
When using on-premise Hyperion system, this can be achieved easily as you can have multiple applications with varying Period dimensions. Same cannot be the case with PBCS as there is a limitation of one application and Period dimension is shared across the cubes. We need to keep this in mind when proposing a solution to the client.
When your start month is different than January, months of a FY can spill over to the next year in Planning application, this is a point worth noting. It can be handled using correct aliases along with period specific calculations.
Entity: Usually Entity dimension is simpler in case of FF restaurant chains. Outlets usually roll up in an uncomplicated manner, say, one outlet rolls up to a city, which rolls up to a district, which rolls up to a state and then a country.
What complicates matters here is the classification of outlets: Some can be classified based on the number of tables (size), business hours (24x7), newly opened (this decides whether it can be considered for next year's budget) just to name a few. Discuss this with the client in order to come to an agreement as to which one is going to be the primary roll up and whether other attributes can be accommodated in it.
Custom Dimensions : Product: Consider this only if client is planning and budgeting by food items (in my case, they did not). In some cases, Food Sales by products can be accommodated within Account dimension itself.
Assets : Assets can be accommodated within account hierarchy if the calculations are simple else we might need to have a separate dimension created.
Manpower/ HR: Ideally, this should be taken up in a separate application altogether. Depending on whether it is a PBCS implementation or on-premise, we must decide what best solution can be offered.
-------------------------------------------------------------------------------------------------------------------------
Business Logic:
Sales and Cost of Sales calculations are simple, based on year on year percentage growth. Since seasonality is crucial in food business, we usually consider figures of the month (or lowest level member) of previous year for calculating Budget figures of same month of next year.
Weekly/Daily sales analysis, Manpower planning (on a daily basis) can be complicated. This can severely impact delivery timelines as it increases testing and validation time. We must keep this in mind while committing to the client.
Depreciation logic is same as the one in manufacturing business, Hyperion Calc manager has in-built depreciation calculation functions which are pretty straight forward.
Data Integration: FDMEE and ODI remain the best choices for catering to data integration solutions. Before we begin with the implementation, we must at all cost, finalize this part of the system as it is the foundation of Hyperion solution. On a PBCS environment, this can be very simple as we cannot use any other tool than FDMEE.
Data forms and Reports: Reports are easier said than done. It is better to present a few sample reports to the client while the design and implementation is in progress. Their demands can be catered to by doing minor changes before the application is finalized. Since data forms are the first things which users interact with the system, letting them get a hang of the system right from the start is a good practice.
1 comment:
This is a wonderful blog Thanks for sharing great topics about the oracle financials topic and really worth reading were started in the blog for more details please can below our visit.
Oracle fusion financials training
Post a Comment