Specialty Cubes

RonnieKarpinsk
New Contributor III

Hello,

I am looking to connect with folks who have implemented specialty cubes to manage data for sales, HR, Projects, Treasury, etc. We are exploring the capability of building a digital transformation roadmap using a cube approach, similar to how Essbase can be used. We are considering using the register to utilize larger data sets and other functionalities. Would love to hear your experiences. Thanks!

Regards,

Ronnie

2 ACCEPTED SOLUTIONS

Henning
Contributor III

Hi Ronnie,

The experience is as diverse as the possibilities in OneStream. It depends on the requirements in each possible project. What is it used for exactly? What are the reporting requirements? How much data are we talking about? What is the target data model going to look like? How is the data going to be processed? What are the workflow and security requirements? These are some of the questions that help you determine whether you might want to look into using a specialty cube or register or customer table or drill back to source (etc.) as you already pointed out. All approaches work very well, if implemented correctly in accordance with the general good design practices. 

The OneStream Navigator offers more insights into what to consider and when to explore which option in more depth. In particular the "Designing an Application" course has some useful content around that. The OneStream books are a good resource as well (available on Amazon).

From my experience, HR data is better put in a register or custom table. Do not put employee names and / or employee IDs into the Cube, use a register or custom table for that! Transaction level data should also never be in the cube. Higher level data such as non-SKU or non-transaction based data may also be put in a cube, depending on the exact requirements. Projects could make sense in either, but usually a register or custom table makes more sense as most companies have a great number of projects going on, which also do not always last very long. However, companies such as mining companies that have e.g. 100 projects in the next 50 years could also opt for a specialty cube as their kind of projects are more stable and less fluid. Data in the cube should reflect more 'stable' data. Employees and transactions change frequently which will then result in a high maintenance effort as well as generally producing very large datasets that are better handled in a table or register.

Also make sure you do not put everything into one cube (which you already know as otherwise you would not have asked this question the way you did). Split the different datasets up in a way that makes sense and takes into consideration the process. Highly granular and frequently changing data (e.g. employees or transactions) should make use of non-cube options.

I hope that helps!

View solution in original post

camagruder
New Contributor III

We are using 15 cubes.  10 cubes are used by different FP&A teams for loading and calculating forecasts within their own workflows using different UD members.  One of those cubes is for Treasury to load forecast.  3 cubes are used for reporting, 1 cube used for loading assumptions, and one cube is used for Stress Testing.  The 10 line of business cubes use extensible dimensionality so those teams have their own workflows for the cost centers they manage as well as alternate hierarchies without impacting our Corporate-managed hierarchies.  We load detailed HR data to BiBlend and only load aggregrated headcount to the line of business cubes for forecasting ST&B.  

View solution in original post

6 REPLIES 6

Henning
Contributor III

Hi Ronnie,

The experience is as diverse as the possibilities in OneStream. It depends on the requirements in each possible project. What is it used for exactly? What are the reporting requirements? How much data are we talking about? What is the target data model going to look like? How is the data going to be processed? What are the workflow and security requirements? These are some of the questions that help you determine whether you might want to look into using a specialty cube or register or customer table or drill back to source (etc.) as you already pointed out. All approaches work very well, if implemented correctly in accordance with the general good design practices. 

The OneStream Navigator offers more insights into what to consider and when to explore which option in more depth. In particular the "Designing an Application" course has some useful content around that. The OneStream books are a good resource as well (available on Amazon).

From my experience, HR data is better put in a register or custom table. Do not put employee names and / or employee IDs into the Cube, use a register or custom table for that! Transaction level data should also never be in the cube. Higher level data such as non-SKU or non-transaction based data may also be put in a cube, depending on the exact requirements. Projects could make sense in either, but usually a register or custom table makes more sense as most companies have a great number of projects going on, which also do not always last very long. However, companies such as mining companies that have e.g. 100 projects in the next 50 years could also opt for a specialty cube as their kind of projects are more stable and less fluid. Data in the cube should reflect more 'stable' data. Employees and transactions change frequently which will then result in a high maintenance effort as well as generally producing very large datasets that are better handled in a table or register.

Also make sure you do not put everything into one cube (which you already know as otherwise you would not have asked this question the way you did). Split the different datasets up in a way that makes sense and takes into consideration the process. Highly granular and frequently changing data (e.g. employees or transactions) should make use of non-cube options.

I hope that helps!

Thank you for the feedback and advice! This is very helpful! My company falls under manufacturing and I am looking for suggestions and ideas of how we can benefit from a specialty cube approach without things getting out of hand. I have a lot of ideas of how to utilize the register and am looking forward to exploring more. 

camagruder
New Contributor III

We are using 15 cubes.  10 cubes are used by different FP&A teams for loading and calculating forecasts within their own workflows using different UD members.  One of those cubes is for Treasury to load forecast.  3 cubes are used for reporting, 1 cube used for loading assumptions, and one cube is used for Stress Testing.  The 10 line of business cubes use extensible dimensionality so those teams have their own workflows for the cost centers they manage as well as alternate hierarchies without impacting our Corporate-managed hierarchies.  We load detailed HR data to BiBlend and only load aggregrated headcount to the line of business cubes for forecasting ST&B.  

Thanks for sharing! Your setup sounds exactly what I envision for my company. Would you be willing to meet with me for 30 minutes sometime to hear more about your setup and journey to get where you are?

My email is ronnie.karpinski@theshyftgroup.com 

Hi,  Would you be able to jump on a call to discuss this and what your feelings/experience is on multi-cube vs single cube?

 

Hi, multi-cube solutions are to be preferred. Please see e.g. this bulletin prepared by Peter Fugere:
https://community.onestreamsoftware.com/t5/Blueprint-Bulletins/Bulletin-3-Extensibility/ta-p/991

Here he lays out why multiple cubes should be used and has this recommendation: "All applications should be designed to use extensibility. Specifically, they should use multiple cubes and create breaks in dimensions when possible."