In Pigment, you can build many things: Revenue forecasting, P&L Reporting, plan for your headcount & how to recruit it, balance sheet, cash flow, align your supply to your forecasted demand, etc
All of this will exist in your Workspace and could even be in one App. However, there’s another option. Pigment brings a ground breaking innovation to the business modeling space where planning can be distributed across Apps in real-time, natively (meaning implementing these costs you no time) and protected from any data import/export issues.
This article aims to explain the concepts of distributed planning so you can decide how to best apply this to your business.
Distributed Planning: How does it work in Pigment?
Any App in Pigment can share its Dimensions and data (any Block, technically speaking) with other apps in the Workspace. You can see which Blocks are shared by looking for the shared icon in the Block explorer.
Sharing a Block is simple, Go to the settings of that Block > Sharing & usages > Share List
Once that is done, any other App in the workspace can use that Block for its own purposes. All there is to do is to activate the sharing in the Library menu of your Pigment App:
Any Block built from the shared Block will be instantly impacted by any changes made to the Block in the source App. For example, if you add a country (in the source App), it is available in real time everywhere it is used. All in less than 10 clicks.
Note: access rights apply across Apps and they are a major driver of the decision to split Apps, we will discuss that below.
Typically, Apps will share the common business Dimensions (country, cost center, time etc), source data (actuals from accounting, headcount by cost center) and output data (revenue forecast, new hires per period etc).
Why split Apps: main drivers to consider
Sometimes the decision to split Apps comes naturally and obviously: your sales ops team will have its own Revenue forecasting, Finance will have its own forecasting app and HR will have a recruiting app.
Below, you’ll find a few things to consider if you are weighing up splitting your Apps even further.
Reason 1: Segregation of duty
The #1 thing to consider is who will be the main users & admins of the App.
If one group of users will be solely focused on that one functionality, that’s a good hint it should be its own App.
Will one of your modelers be solely focused on one particular functionality and should not be allowed to modify the rest? Stand-alone App.
Is your data set super sensitive? Make it its own App. It’s a lot simpler to limit user access to just that one App.
A typical example in this category would be an HR Staff Costs App that contains the individuals and their salary. Only one team (HR) would access this App.
Reason 2: Organization of the Blocks & ease of modeling
When we start building on Pigment, we will quickly find ourselves with a large number of Blocks: Dimensions, data loads, Metrics, Metrics, Metrics… Even with strong naming conventions, and organizing Blocks into folders, it can still become too much.
Does one functionality require dozens of Blocks, yet only one Block (containing the final results) will be shared with the rest of the model? Make it its own App!
This is also valid if the names of the Blocks are very close in two functionalities: split one into its own App.
A typical example - Revenue forecasting requires many Blocks but only one Metric (final revenue by desired Dimensions) needs to be shared with the rest of the Apps.
Reason 3: Different versions of Dimensions
We’ll start this one with an example. A specific part of your business requires very different (or even slightly different) Dimensions from the rest of your business. They might require a longer timescale for historical reasons or a list of countries that is slightly different from the common one because that part of the business is based on a legacy system. You could work with two different Month/Country Dimensions in one App, but that can be confusing (especially when typing a formula or creating a new Block).
You can build the same logic into its own App and then do a simple mapping exercise to match the Dimensions. This will allow data to be shared.
Reason 4: Cadence of planning & scenario cycle
When you plan for your business, you don’t necessarily plan for 100% at the same cadence. Do you review your OPEX spend plan every month? Headcount every week? Revenue every day? Do you do 10 scenarios for your revenue but only one for the rest? Sounds like your revenue planning is a good candidate to be its own App.
A special App: the HUB
The HUB is a special App that we strongly recommend you implement in all situations, even the simplest one. Done correctly, it offers a lot of benefits and will simplify your life when you increase your usage of Pigment.
Find below the reasons to use a HUB.
One source of Truth
The HUB should be the App where all the common Dimensions of your business are stored. For example, Region, Cost Center, Product, Chart of account, Time, Versions etc.
Doing this will finally give you the bespoke one source of truth.
However, this is not just limited to Dimensions. In the HUB, you can also put in your common business data. For example, actuals from Accounting, opportunities from SFDC, etc. Any external data that will be shared between your Apps is a good candidate!
A rule of thumb: if a Dimension or data will be used by 2 or more Apps, it should be in the HUB.
However, don’t put everything in there just for the sake of it. There are valid reasons why a Dimension should be in another App. For example, headcount and payroll should sit in an HR App and be shared from there (see Reason 1).
Smooth User Access Management
As the HUB will contain the shared Dimensions, it is the natural place to define user access & derive it from the HUB.
In Pigment, user access is on 2 axes:
-
Action: what you can do, based on your role (open a Board, edit a Block, change access). A user will have a role on every App they need access to, and those roles can differ depending on the App. Using a HUB, a user will just need a role in the HUB (to access shared Dimensions) and a role in their main App
-
Access Rights: what Dimension you can see and write on. This is very often driven by Region & Cost Center. You can assign this in the HUB and derive access rights in all Apps from the HUB. Simple & efficient.
If that part isn’t clear to you, please review our article on user Access Management.
Current Limitations to consider
-
While a user can jump from a Board in one App to a Board of another App easily, you can only put a List widget of a dimension in a Board of its own App.
-
Users of an App will (at least) need a READ role in each App that is sharing a Block with the App.
Example of architecture:
Example 1: Finance only:
HUB - FP&A App - HR Staff Costs
Example 2: Distributed XFN:
HUB - Actuals - FP&A - HR Staff Costs - Recruiting (TA) - Sales Forecasting (Sales Ops)
Example 3: Supply Chain:
HUB - Demand Planning - Inventory Planning - S&OP