There are at least as many ways to create a business plan as there are companies creating them. There are no obvious rights or wrongs when approaching the planning process. Plans for different purposes vary both in detail level, time span and in the involvement from different parts of the organization. The aim of IFS Business Planning is to offer support for different approaches and serve as a toolbox, where everyone will find bits and pieces that fits with the way their company or group of companies operates.
The basic structure of the business plan consists of four levels.
There are numerous ways of operational planning within or outside IFS that of course should be reused in the business plan. This is either done using the external file functionality or any of the existing integrations, such as depreciation plans and revenue recognition forecasts.
Manual transactions are preferably entered using purpose built planning templates in the excel add-in IFS Business Reporter, but can also be entered using the Planning Unit page. From the manually entered transaction other transactions can automatically be created using the planning rule functionality.
In addition to the integrations that reuses already existing planning, it is
also possible to create transactions from Personnel Planning where you can
import information from the employee file in IFS Human Resources and use for
your personnel cost planning.
The administrators will prepare different planning templates using IFS Business Reporter. The planning templates can be created anyway that fit the organization and contain both business plan logic (planning rules) and excel logic. For example different templates can be created to support the different steps and units of the business plan.
To support more generic reports/templates it is possible to use the planning dimension value list connected to the planning unit as repeater. That means that for example all accounts connected to a value list will have a row in the template. It is also possible to use your own period definitions in the plan. If you for example want to plan monthly for the first year of the plan and quarterly for the second.
For both planning drivers and planning transactions (accounts) there are two information sources, one for Valid Versions and one for All Versions. When in the planning process, it could be useful working with all versions since that makes it possible to plan for more than one version of the planning unit simultaneously. If planning unit versions are not used or if the aim is to design reports for a completed plan, valid versions should be used.
If you want to design a report on account level but still want to make it possible to perform write-back on a more detailed level (for example with comments) this is possible by selecting the Transaction Level Write-Back option on the Options tab of the design row.
As an alternative to Business Reporter, the planner can enter planning transactions manually in the Planning Entry page.
Many planning processes contains large number of spreadsheets with a lot of calculation logic being sent across the organization. Since spread out in many places it might be difficult to centrally control the calculation logic. Also, if changes are to be made, the same change often has to be done in many different places. To avoid this the planning rules has been developed.
Planning Rules can either be Transaction Based or Balance Based. Both types of rules are defined in the Planning Rule page.
Transaction based rules are triggered on save and automatically creates new
transaction rows within the same planning unit as the transaction triggering the
rule (Note: In order to apply transaction base rules on transaction rows
transferred from Revenue Recognition Forecasts, the rules need to be
re-executed). Examples of transaction-based rules are:
Balance Based rules are triggered manually at any time from the Planning Rules Execution tab of the Business Plan page and is based on planning balances. The new transactions are created in a separate target unit. Example of transaction based rules are:
Business plan drivers of Planning type can be used in the selection part of the planning rules and drivers of Assumption type can be included in the calculation logic of the rule. For example, the planning driver could be number of objects sold and the assumption driver the price of the object. If you want to use the same planning rule with different period values for different planning dimension values, for example cost centers, this need to be defined in the Assumption Driver Planning Dimensions tab of the Business Plan page.
The main purpose of this development is to include the already existing information regarding employees in your planning. Most benefits of the development will be received by companies using the Employee Files in IFS Human Resources but it is also possible to enter the employee information manually.
Personnel planning makes it possible to plan your personnel related cost in a more detailed way than on a planning transaction. It has its own security setting which makes it possible to exclude sensitive salary information for a regular planner.
The personnel planning process can be divided into four blocks.
The first two blocks are performed by a business planning administrator with or without access to IFS Human Resources. Mapping the employees to a specific business plan or planning unit is done by a plan administrator. The planner then modifies the period values when necessary and transfer the personnel planning transactions to regular planning transactions.
The base value of the planning item can either be imported from HR or entered manually and serves as a base for the period values. For personnel planning items defined as calculated, the period values are calculated using other planning item period values, assumption driver period values or fixed period values.
When planning on a higher level, an aggregated planning employee has to be mapped to the relevant planning unit. The planning values for the planning employee is then calculated (as an average or a sum) from the not aggregated employees of the plan or unit. This functionality is typically used to create start values for high level planning since all calculations are based on planning values and not specific period values.
Since personnel planning is integrated with IFS Human Resources it is possible to import employees, salaries and degree of occupation. Several attributes connected to the employee file are also visible in personnel planning which helps the administrator to map the employees to the correct units within the plan. If organization changes are made in IFS Human Resources this is indicated in personnel planning, helping the administrator to keep the employee mapping up to date.
Using the information source Business Planning Employees in combination with Business Planning Personnel Transactions makes it possible to add additional employees to a planning unit and to perform write-back on personnel planning item period values.
In addition to the transactions sources originating from within the business planning component, there are other sources that can be used to import/transfer planning transactions.
On planning unit level, there are two different statuses for two different purposes:
The Planning Unit Status is used in a process based plan where the unit status can differ depending on what step of the plan it belongs to. This status can be controlled from the planning step.
The Approval Status is used for the approval process and can be set per unit as well as for nodes in a planning unit structure. The approval status can be used independently of the planning unit status. The approval statuses for nodes and planning units can be analyzed using the Business Planning Structure Status information source.
There are three levels of administrators within business planning:
There are a lot of advantages using IFS Business Planning compared to spreadsheet planning. Using the built-in tools makes it easy and much less time consuming to administrate changes and update planned values.
The planning value list is an effective tool to use when defining which
planning dimensions to use. For example, when using the same value list for all
planning units included in a specific step and halfway through the planning
realizing that an additional account is needed. All that needs to be done is to
add the account to the value list and all entry forms will be updated
accordingly.
Both transaction based rules, balance based rules and calculated personnel
planning items can be re-executed/re-calculated any number of times. If for
example the calculation logic of a planning rule is changed or if an assumption
driver period value is changed, the rule/item can easily be re-executed or
re-calculated and all output transactions updated accordingly.
There are a lot of overview pages to support administrating large plans with a
large amount of planning units, planning users and planning dimensions.
It is possible to plan using a mix of period balances and accumulated balances within the same business plan. Accumulated balances can be used for balance sheet planning. When planning on accumulated balances, period balances are automatically calculated in the background. There is support for write-back on accumulated amounts and to define planning rules which calculates accumulated amounts.
The planning dimension Planning Scenario can be used to plan for
different scenarios within the same plan. When creating reports, define which
scenarios to include, if any. The scenario can be used as deltas or as an
alternative plan depending on your preferences. When the planning has been
completed it is possible to create a finalized copy of the plan excluding the
scenarios that should not be valid.
There is also a possibility to plan for different Versions of the same
planning unit. This is typically used when the planning unit responsible need an
alternative version of the planning unit to play around with. The versions are
alternative units and there must always be one defined as valid.
It is possible to connect an accounting structure to the planning unit. This can be useful if you want to plan on a higher level by connecting a planning only code part value to each node of the accounting structure. The same accounting structure can of course also be used when the planning entries are done from Business Reporter.
It becomes more and more important to find alternative ways to plan for groups of companies since operational and legal organization structures more seldom align. To support this, business planning is tightly linked with IFS Group Consolidation and makes it possible to plan on any level of a group consolidation structure.
If there is a one-to-one relationship between the business plan and a reporting entity, the transfer to group consolidation is done in a similar way as reporting a budget version.
If you want to plan for more than one reporting entity in the same business plan this can easily be done using the planning dimension Planning Entity. A planning entity can also represent a group of companies, e.g. node in the consolidation structure, depending on the purpose of the plan. The planning entity can then be used to transfer balances to a planning type reporting entity within Group Consolidation.
When the planning entities within a business plan have different accounting currencies it is recommended to use a reporting currency for analytical purposes.
Business Analytics with pre-defined information sources can be used to compare planning amounts with actuals in transaction, accounting or reporting currency.