Business process reengineering and process standardization
7244
post-template-default,single,single-post,postid-7244,single-format-standard,bridge-core-1.0.5,ajax_fade,page_not_loaded,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-18.1,qode-theme-bridge,wpb-js-composer js-comp-ver-6.0.2,vc_responsive
Business process reengineering

Business process reengineering and process standardization in various Microsoft Dynamics NAV installations

Global companies take different approaches to the business process reengineering depending on the area of business activity that the process standardization is going to affect. Efforts towards strict process standardization are made in case of manufacturing or logistic processes in particular. Slightly bigger differences between accounting processes result from the need to take into account local legal requirements. The greatest flexibility is usually allowed in sales processes as companies believe that as long as good results are produced, local sales processes should not be changed.

standard

Standardization of business processes in various subsidiaries of the same company – a chance to promote the best processes in all company branches worldwide

A wide range of options within sales processes

Even if the project involves a high level of flexibility in sales processes in subsidiaries, thestandardization often affects other areas, for example accounting setup, a unified chart of accounts, logistics (item numbers, inventory control). Central management of master datafacilitates standardization of customer cards in various companies. Thus, the standardized ERP system (Microsoft Dynamics NAV – Navision) affects also the sales processes, for instance thediscount policy.
The problem with sales processes can be solved by developing alternative solutions such as enabling or disabling some of the system options. A good example of such approach is discount policy differences between Great Britain and southern France. Generally, in the UK the customer gets a standard price for the product and pays extra for all additional services. In southern Europe, where the customer gets a price for the product and is offered a discount for expanding the range of services, such an approach is unthinkable. As these two attitudes stand in opposition only one option can be selected.

How to enable various options in one consolidated, global Microsofty Dynamics NAV system?

There are two possible scenarios. The tool for price import is the same in both options and works the same in the UK and France. However, the tool for discount import for Navision is used only in France. The companies in the UK use the additional cost functionality. During roll-out of theconsolidated Navision system in a location we make a decision whether to opt for  the discount or “extra charge” option and then make proper settings. However, there were subsidiaries that used both options, depending on the customer they were working for.

Business process reengineering in the area of manufacturing or logistics

Generally, in global companies all processes except sales are not so easily adjustable. It is correct to e.g. introduce the same production process in all subsidiaries. Our customers are often confident that implementing the same ERP system in all locations will ensure similar processes and unified way of working. The truth is that ERP systems such as Microsoft Dynamics NAV offer some level of process flexibility. The same item can be produced in several different ways. Therefore, it is important to take into account that no matter if business process reengineering is one of the objectives of the project based on Global Template (System Core).

Process standardization via settings or functionality

In practice, standardization means that the headquarters make a decision about how selected processes should be carried out in all subsidiaries. For instance, a decision may be made that in case of assembly management there is always one stage of the production routing. If it is a global group assumption for the entire manufacturing process, there is no analysis of the manufacturing process before the local roll-out. The process is already defined during the stage of developing Global Template and it is the result of the group policy. Microsoft Dynamics NAV implementation partner sets up selected processes in the system. Users with appropriate permissions in a given subsidiary have the ability to modify the manufacturing process. If the headquarters make a decision that local users should be denied that possibility, it is necessary to make relevant modifications in the ERP system. A good example of standardization within the functionality isproduction BOM standardization described by one of my colleagues. What we have is a Design BOM (Master BOM) that is created by the company responsible for its design. As part of the Design BOM, components and their quantities needed to produce a given item are defined. Then, each subsidiary that produces the selected item creates its own production BOM based on theDesign BOM in the central database (it will be used only in the selected location) and it is next replicated to the local database. From that place, the process is imposed from start to finish. Subsidiaries are not able to create production BOMs on their own as they must be created in the central database. In this case, a local user is not able to change the process by changing system settings.

Which option will be better?

A decision whether a process will be standardized via settings or functionality is already made at the stage of Global Template preparation, that is in the second phase of the project carried out in compliance with NAV Global Standardization and Roll-out Methodology. At that point, together with the customer we ponder on the most optimal ways of modelling the process in the global ERP system. We also analyze whether the process will be implemented via settings in the local systems or whether fixed adjustments will be make in the process (via the functionality). In the second scenario, any changes are forbidden. The question to be answered is whether persons responsible for processes in subsidiaries should be allowed to modify them? In my opinion, a user who is more likely to “break” something in the system will be more aware of what he is doing. Secondly, if fixed changes are made in the process (in the functionality), we block a number of system options. That’s why, in my estimation, it is better to implement the process only via settings.