MODLRWhat is MODLR?
MODLR has been designed and purpose built to address Performance Management and Financial Planning & Analysis needs as a single platform of integrated components. No aspect of MODLR has been purchased independently and integrated, the suite has been designed to work together harmoniously from inception.
Platform Capability
MODLR is a Performance Management Operating System for Small, Medium and Large Enterprise. The platform includes functionality to complete the Performance Management Lifecycle including (but not limited to):
- Business Modelling - Creating a Business Model which simulates business operations, leveraging data detailing the historical performance to produce forward looking simulations, forecasts and budgets.
- This supports more than two orders of magnitude more data in live modelling than standard spreadsheets.
- This supports automating the flow of new information into the data model at regular intervals (each Minute, Hourly, Daily, Weekly, Monthly)
- Security and Workflow - Provide secure and workflow-based access to business models for the purpose of allowing managers to collaboratively and concurrently, input changes to modelling assumptions, weight historical datasets to acknowledge operational anomalies and model multiple what-if scenarios.
- Business Intelligence Reporting - Provide visually compelling and customer branded reporting across a multitude of mediums and formats sourced in real-time from the Business Models designed on the platform and Datasources which fed into them.
The Standard Setup
Assuming the most common use-case for the MODLR platform this section will step through the standard approach to utiizing the platform capabilities.
Scenario: Financial and Operational Planning
1. Connecting to Actuals
Setup a process to export journal and summary level information from source systems such as the ERP platform. Alternativly model developers can upload this information as CSV format for the subsequent steps.
TIP
There are some modelling scenarios which do not require historical datasets, such as when modelling a new business or business department in a new field where existing baselines are not applicable.
This collection of processes should raise Email or SMS alerts should the source system be inaccessible or should the consistancy of data fail some automated testing.
2. Build the Dimensions (Company Structures)
Chart of Accounts, Department, Cost Centre etc - These dimensions can be built manually but it is typically best to have these automated from the source datasets for Actual information.
A Scenario dimension should be established which includes Actual, Draft Forecast, Draft Budget along with Final Forecast, Final Budget. This provides a workflow for planning which includes the Draft scenarios having calculation logic on them and the Final scenarios being a copy/paste-values version is an efficient way of storing non-changing scenarios (The Final scenarios).
TIP
An unlimited number of scenarios can be added and used for what-if modelling.
Forecast scenarios can have Actual data overriding historical months providing full year composite views.
INFO
While this is a proposed structure for a Scenario dimension, each model can have difference structures and may actively avoid this paradigm in favor of some other methodology.
3. Build the central data cubes
Profit and Loss and Balance Sheet are typically the central components to an integrated financial and operational planning solution.
This step includes setting up processes which will regularly import the information from Step 1 to populate the Profit and Loss and Balance Sheet cubes within the Actual scenario.
This collection of processes should include a reconciliation mechanism and should utilize email or SMS based alerts should issues occur.
4. Establish sub-models for various components of the Profit and Loss
Sub-models are typically designed to model Revenue, Variable Costs and Operating Spend and feed their resulting figures back into the Profit and Loss and Balance Sheet where applicable.
INFO
As an example, a Revenue sub-model for a FMCG enterprise may include planning sales at a SKU level and account for sale and cost pricing changes.
This added granularity (SKU) is not included in the central Profit and Loss, however the outputs of this model would flow through the the Profit and Loss and the Balance Sheet
5. Distribute access via an Application
Access to the model can now be setup through a designated application. Here users can be added with access to specific portions of the Business Structures (Dimensions), Specific Sub-models (via Screens) or a compination of the two.
INFO
At this step, access to specific scenarios would be provided.
At the start of a planning round, WRITE access to that Draft scenario would be provided.
Users would likely have READ access to Actual and Final scenarios at all times.
6. Planning Round Completion
At the finalization point of a planning round the chosen Draft scenario would be archived into the Final scenario. User access would be adjusted so that users can no longer change the Draft scenarios and key messaging would be updated in the application.
Business As Usual
During all stages of the planning lifecycle -
- Actual information would continue to be populated from source systems at a regular interval. This occurs most commonly each night.
- The model would be available to users for reporting and variance analysis, whereby users could access management reporting for their area of operation and be able to see variances to targets and add richly formatted commentary on the variances and operational performance.