Specialty Cubes
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!
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.
