Kaya’s customers are using predominantly an ERP application of the Microsoft stack, being Dynamics AX or D365 for Finance (and Operations/Supply Chain); given the size and complexity of processes to be supported Business Central and its D365 successor are not common at our clients. As ERP stands for Enterprise Resource Planning one could, and should, expect that an ERP solution can be used to (easily) plan resources (financial, human, material) of a company/enterprise. In reality this appears to be not so easy and user friendly as one would hope and expect.
Functionality for forecasting, budgeting and planning in D365/Dynamics AX
In Dynamics AX and its successor D365 for Finance & Supply Chain there is functionality present to do forecasting and planning like MRP, production planning, project planning (Work Breakdown Structure), cash flow prognosis, forecasts on purchase and sales, project and ledger budgets. When using this functionality, it appears that configuration is not easy (initially) and requires quite an effort. After that, the forecast/budget/planning in many cases must be created with a periodic option.
For some of this functionality like MRP this is not a problem as input for such processes is based on inventory transactions which are registered in the solution and form a solid basis for the MRP run. This is however not applicable for all functionalities mentioned above. Especially where financial planning is involved D365 and its predecessors are lacking flexibility. Creating an additional scenario and calculate that is cumbersome and error prone and results in additional transactions in the system.
Common forecasting and budgeting process
So, what usually happens is that a financial forecast is calculated outside D365, mostly in Excel (Excel is still widely used at financial departments in conjunction with accounting software for the standard financial activities). Usually various scenarios are calculated, and one scenario is designated to be the (next) budget. After this has been done the result is uploaded into D365/AX.
Once the budget is uploaded transactions are posted and reporting is done on actuals versus budget (on multiple periods, comparing previous periods to present periods, year to date etc.) In some cases, this reporting is even done outside D365/AX by exporting transactional data to a Data warehouse or to Excel (there are lots of organizations who still rely on Excel for their reporting needs). Organizations that rely on Excel for their reporting needs often experience internal conflicts as staff/departments create their own reports which are supposed to report on the same issue, but the data reported on is open for multiple interpretation or uses a slightly different data set.
So, where does this come down to? There is a need for flexibility in planning and budgeting (like present in Excel) but the reporting should be more rigid (like the transactions stored in D365/AX). How to realize that? That will be the subject of the next part of this series of blogs.
Look for other related blogs at https://kaya-consulting.com/category/board/