Aside from the more traditional financial consolidation and planning requirements, project reporting is critical to one of our clients’ operations. They need a sub-ledger to manage the financial information of their numerous ongoing and planned projects as part of this. They used to manage these projects in Excel before deploying OneStream. At any given time, they have hundreds of active projects, with thousands more being added each month.
They must record contract size, customer, location, product classification, revenue and costs by many major buckets, how much of the project remains, and gross margin for each project. On the planning side, they must forecast income and reservations for the next months. This client also requires numerous project-level reports, such as the ability to determine which projects or customers have the largest effect or to flag projects that are problematic. To supplement their more normal cube-based Actuals and Planning reporting methods, the aggregated project information from this sub-ledger must be loaded into the consolidation cube just like any other sub-ledger.
Many planning apps on the market are created using a multidimensional cube technique, which allows for fast slicing and dicing of summary level data. These solutions, on the other hand, aren’t usually well-suited to handle vast amounts of comprehensive data for planning and reporting. OneStream is the first CPM platform that combines the relational and cube concepts into a single solution.
Typical financial cubes struggle to capture data down to the transaction level, whether it’s for an individual employee, a project, a fixed asset, or a GL journal, for which there might be thousands of things arriving and departing over time. This type of transactional data is best suited to storage in a relational database or table. That is, in reality, how General Ledgers, Payroll/HR/Fixed Asset Registers, and other financial records are created. When this type of data is supplied into a cube for easier slicing and dicing reporting, the transactional information is often aggregated out of the data, so the cube has no knowledge of or access to the item level detail.
Traditional consolidation and planning systems often only provide cubes and slicing/dicing reports centered on cubes. Transactional systems, on the other hand, contain data down to the item or transaction level but aren’t as adept at slicing and dicing to detect exceptions.
Then there’s OneStream. OneStream’s Intelligent Finance platform has a comprehensive range of cube-centric slicing and dicing features. OneStream also has the capacity to enter, retain, compute, and report on relational/transactional stored data, which is a rather unique capability. This OneStream feature allows you to create sub-ledgers in OneStream relational tables, which sit alongside OneStream cubes and are all accessible through a single application/user interface. Employee planning, lease or fixed asset management, or, in the case of my client, project-level reporting and planning, are just a few examples of what these sub ledgers may be used for.
People Planning, Sales Planning, and a more generic Thing Planning are all part of OneStream’s MarketPlace family of “relational blend” products.
All relational mix systems feature a “Registration” where users enter/maintain the details of the objects they want to manage, as well as a “Plan” where different OneStream computed values are kept depending on what’s in the register and maybe other sources of data.
These solutions contain a calculation engine that allows you to specify which calculations should be done between the Register and the Plan. Users would input workers, department, location, type, status, and basic salary into the Register for things like People Planning, and the Plan would store the OneStream calculated monthly salaries, benefits, taxes, and so on by employee. After the data has been entered into the Register and the Plan has been generated, this sub-ledger-like data may be loaded into OneStream (or even transferred to another system) in the same way that General Ledger data is. Later in this blog article, I’ll go through reporting choices.