Customizing the modelling solution

This article outlines the main options and considerations for customizing Orgvue's org modelling solutions.

How should modelling ‘Actions’ be labelled?

Position level ‘Actions’ are specified during a modelling project:  positions can be added, changed, flagged for removal or kept unchanged.

The labels which are applied to the modelling Actions can be customised if the Advanced Solution is being used.  This provides consistency with the language and terminology used in your organization.
 

Is time tracking required and what increments and initiatives should be reported?

If the Advanced Solution is being used, there is the option to enable time tracking. 

When time tracking is enabled:

• An effective date for planned actions is specified

• The evolution of the organization over time can be visualized based on the pattern of planned actions

The time increments can be specified which fit with your transformation requirements or business reporting cadence.
For example

• Wave 1:  Q1 2004
• Wave 2:  Q2 2004
• Wave 3:  Q3 2004
• Wave 4:  Q3 2004

You can also track design changes by grouping them into different initiatives. Org modelling typically include multiple initiatives, each with different effects, such as reduction in one area, investment in another. By grouping actions into initiatives, you can view and understand the impact of the actions associated with each initiative.

Should any values be added to my modelling properties?

When modelling the ‘to-be’ organization, positions are defined using property values. For example, users can change the location of a position by changing its geography property value from “North” to “South”.

Any property values which already exist in the baseline dataset will be included for users to select.

It is possible that upstream org design work has identified new elements for the ‘to-be’ organization.  For example:

• A new business unit which is opening

• A new function, sub-function, or department

• Operations in a new country, or a new site location.

As these have not previously existed, they do not appear as values for the relevant properties in your baseline dataset. 

They can be added so that they can be selected from a drop-down menu when positions are modelled. This removes the risk of typos creating data-quality issues when values are manually entered.

Which change impacts should be reported?

The org modelling solutions automatically report the impact of planned actions.  The example below shows the change in the size and cost of the Chief Revenue Officer’s reporting line.

Using the Org Modelling Guided Experience, the reported differences are limited to

• Team Cost, based on the cost property which was selected at the set-up stage of the workflow

• Team Size, based on headcount, or FTE.

Using the advanced solution, any number property in the baseline dataset can be used for impact reporting.  Typical properties include FTE in addition to headcount, span of control and additional cost properties such as target bonus.

What ‘change reasons’ should be specified?

When designing the ‘to-be’ organization, changes will be planned for different reasons. It's important to capture the reasons because sometimes it's hard to see from the change itself. For example, when you change the reporting line for a position, the reason could be that you have closed its manager position, or that the whole team is moving to a new department.

Documenting the reason for positions being added, removed, or changed.

• Provides a record of the rationale for the change which can be referred to later

• Enables positions to be grouped by ‘change reason’ to support implementation activities (for example, accessing a list of all positions closing due to outsourcing)

Pre-setting change reasons maintains data consistency.  The default categories can be customized using either the Guided Experience or the Advanced Solution.  The most common change reasons are:

• Decrease scope (usually for positions being demoted or downgraded) 

• Increase scope (usually for positions being promoted or upgraded) 

• Relocation (usually for positions being changed to another country/city, e.g., from UK to US) 

• Move to new team (usually for positions with changing reporting lines) 

• Other changes (for other minor changes, such as position title changes) 

In addition, reasons for new positions opening include Insourcing, Investment, New market/product line, etc. And reasons for closing positions, such as Outsourcing, Closing market/product line, etc. 

Which elements should be included the cost property? 

Analysing the cost of the ‘to-be’ organization is a key benefit of modelling in Orgvue.  No time is lost manually reconciling change impacts.

But what should be include in the cost property?
Generally, in addition to the base salary, there are bonuses, incentives, benefits, etc. included in the total compensation. When modelling your organization, you could choose to only use salary or the fully loaded cost. If you want to include all cost components, the first way to do this is to apply certain rates to the base salary. For example,  

• Salary (20,000) 

• Bonus – 5% of the salary (1,000) 

• Incentive bonuses – 5% of the salary (1,000) 

• Benefits – 25% to be applied on Salary + Bonus + Incentive bonuses (5,500) 

• Total compensation (27,500) 

Furthermore, these rates can be different depending on the location, function or other elements. For example, you could apply a 10% bonus rate to sales employees and a 5% bonus rate to non-sales employees. 
If the organization has a global scope, you will also need to consider exchange rates to see the cost impact from a company-wide perspective. Exchange rates can be set to automatically look up by country.

How should position costs be entered?

There are two ways to capture the future cost of a position:

1. Manual entry:  The cost associated with the position is entered for a new position or updated for a changed position.  This requires time-consuming manual work and risks errors.

2. Automatic generation through a Rate Card:  The cost associated with the position is calculated and populated based on a lookup table.  The lookup table specifies the cost values based on – for example – the location and grade of the position.

• When a position is added, as soon as the properties used to define the Rate card values are populated, the cost is generated.

• When a position is changed, it’s rate card cost value is automatically updated, and the designer can choose whether to apply this cost,or maintain an existing cost value.

For a fuller introduction see Rate card lookups for calculating position costs.