Overview
Business Process Management (‘BPM’) can be combined with various aspects of enterprise-wide operating systems to produce an integrated view of the relationship between people, processes and systems. This allows a holistic approach to the optimisation of performance across the organisation.
By incorporating and extending the BPM approach into the way large complex Enterprise Resource Planning systems (‘ERP’) are designed, built, deployed and used, an additional set of synergies and insights becomes available. This can then be used to facilitate various change management and internal control processes relating to managing the ERP system over its life cycle as well as to increase the efficiency with which software implementation and upgrades are managed and reduce errors.
Why use BPM with your ERP?
BPM is a means of recording the activities undertaken by individuals in the organisation in order to achieve work outcomes and drive forward the business. It is important that these activities are performed effectively and efficiently, to react promptly to customer needs and maintain competitiveness.
Various methodologies are available to analyse business processes and identify slack time, waste and other inefficiencies that hold back performance; from this, improvements may be made.
In today’s world, however, organisations are strongly dependent upon operating within the three strands of people, process and system. In particular, Enterprise Resource Planning (‘ERP’) systems that underpin large organisations play a major role in planning and coordinating complex interrelated activities across different functions. They also collect, store and route the huge amounts of data involved so that it is delivered to individuals just at that moment when a human decision is needed and used to run automated processes when it is not.
By applying the BPM methodologies to the ERP system, it is possible to optimise all three parts of the people-process-system combination in a structured manner. In addition, detailed information from the BPM approach may be used to identify and manage the impact of changes, both at the time of implementation and when software updates are released.
Including ERP Detail in the Process Hierarchy
Part of BPM methodology is to define the process in several hierarchical levels; often, five levels are used… but this is not set in stone. The levels typically run from Level 1, which represents a major end-to-end process area (sometimes called a value chain), such as Order to Cash (‘OTC’), down to Level 5 which is the individual process step; for example, ‘Send sales confirmation to customer’.
The levels are built up using a branched structure – like an organisation chart – where each group of items in a level come under a parent item in the level above. Usually, this is complemented by a hierarchical numbering structure that reflects the parent-child relationship between steps in each of the levels. This structure is visualised by creating flowcharts, or ‘models, for the different levels; each ‘box’ in a higher-level model will be expanded to become a complete new model at the next level down.
By ensuring that all steps executed by the system are included in the process hierarchy, a full understanding of the role of each system and its impact on the overall operation can be understood and optimised. Where several systems exist in the landscape, the system interfaces between them become focus points in the same way that hand-offs (process interfaces) between teams of people are focus points when looking at the human component.
Rather than simply naming the system involved, each system-supported process step should be fully detailed in terms of which module or transaction is involved and other key parameters. Combining this detail with the BPM information allows various facets of ERP management activity, both during implementation and post go-live operation, to be executed more efficiently.
The following sections list the ways in which ERP documentation may be linked to the BPM and how that information may be used.
Linking BPM and ERP Documentation
When an ERP system is developed and deployed, there are many information items that are managed and documented by the project, such as configuration choices, data structures, user roles, controls, etc. These can be related to the process by tagging them with the process step numbers.
For example, if developers build an interface that passes data between two systems, then it can be tagged with the process step number that sends the data packet and also the process step that receives the data packet in the other system. In a complex interface, there may be several process steps that are involved in each system. By tagging the process steps that ‘use’ the interface, we now have documentation that identifies the process impact if that interface is modified at some time in the future.
Further, if we have assigned a user role to each process step, then we can also understand which jobs – and which individuals performing those jobs – will be affected by the modified interface and this allows training materials to be targeted to the people that need it.
User Roles and Authorisations
Each level 5 process step can be tagged with the exact transaction code or screen that is used to execute it within the ERP system. At the same time, the step is assigned to a technical role; for example, the process step ‘Send sales confirmation to customer’ might be assigned to a technical role called ‘Sales order processing’.
A number of technical roles can then be bundled together to create job roles such as ‘Sales order clerk’; these job roles are assigned to real people in the organisation. By using the technical roles as building blocks, a wide variety of job roles can be developed whilst maintaining a simple relationship at the process step level.
By running a report of the process step to role assignments, it is possible to construct a complete picture of the system transactions and / or screens that each job needs to use. This can then be used as the basis for building and maintaining the authorisation objects needed by the system’s user access control.
User access control is typically a complex area, but this approach allows those authorisations to be visualised through the process flowcharts in a way that is easily accessible by process owners, system owners and users.
Training Materials
Training materials can be put together on a modular basis that corresponds to the sub-processes in the BPM model. These materials will include all the end-to-end steps and include screenshots from the system, business reasoning to be used, information regarding internal controls, etc. Non-system steps are also included.
Because the process is linked to the user roles… and these, in turn, are linked to jobs, it is now possible to assemble individual training packages covering the parts of the overall process each person manages.
When future changes are made to the business process, the ERP system or related functionality, the BPM-role-training model may be used to target change management and supplementary training onto the individuals who are impacted.
Internal Controls
In addition to ‘built-in’ controls that are set within the ERP system functionality, there will be other limitations, check-points, quality checks, etc that are included in the process design to ensure that regulatory requirements and product standards are adhered to.
Typically, an organisation may create policies that identify risks that must be managed within the enterprise. These risks will be defined and assigned to risk owners who then identify the controls needed to ensure operations are conducted within acceptable bounds. These controls will also be assigned to the people who will execute them and to control owners – normally supervisors – who will monitor that they are being carried out day-to-day. Finally, internal (or external) auditors would access the risks and controls framework to acquire input for their periodic compliance inspections.
By adding the internal controls to the BPM model at the process step level, this confirms the correct roles and users that have been identified as executors and makes it easier to ensure that the pertinent information has been included in user training materials. As with general training above, changes to controls can quickly be mapped to the users concerned and the new way of working rolled out and established.
Where the controls are to be managed by automated processes, by setting limits to user access or through approval workflows in the ERP system, the linkage of the control to the process steps helps the development team realise where a control is involved. Consequently, they can easily identify the appropriate risk and control owners who need to validate any changes to configuration or data.
Other RICEFW Objects
When a new ERP system is ‘taken out of the box’ and prepared for deployment there are several elements that are worked on that commonly go under the not-so-beautiful acronym RICEFW: reports, interfaces, configuration (pre-defined switches that change how the software works), enhancements (customised programming to add functionality), forms and workflows.
Each of these can be identified, included in the BPM model and cross-referenced to the process steps. As above, this allows the impact of these software elements to be related to the process, the users and internal controls that interact with them. This means that IT development teams can quickly identify the correct stakeholders who can assist in agreeing the functional design and later testing of the system.
Also, by ensuring that functional and technical information is properly captured at the time of system design and build – in particular, the business process logic or technical design rationale for why a certain option was selected – complete documentation is available for those tasked with making RICEFW adjustments in the future.
Business Process Ownership
At the heart of a good BPM set-up is the concept of process ownership.
At the development stage of a large ERP implementation, it is very common to appoint business process owners (‘BPO’) to each of the Level 1 processes and they work with stakeholders within the business to understand their requirements and develop the future ‘to be’ process model. They work as a process owner team to ensure that processes are efficiently integrated ‘sideways’ with other functional areas and they work with the IT development teams to ensure that business requirements are fed into the design, properly tested and, ultimately, delivered to the user community.
Ideally, the BPOs are appointed from within the business so that they understand the unique needs of the enterprise but, for reasons of individual availability or a need for prior ERP project experience, they may come from outside. Either way, it is important that they are seen and trusted as properly representing the business during the design and build stage.
As deployment comes to an end, it is necessary to consider how business process ownership and the wider BPM structures that have been built up will transition from ‘project mode’ to become part of ‘business as usual’
That might mean BPOs dropping back into a functional role whilst retaining a percentage of time working for the whole enterprise or external project team members transferring to permanent roles. In either case, there needs to be a shift from design-and-deploy towards dealing with day-to-day process issues and queries and working with the on-going IT support teams to identify software tweaks and developments that feed into quarterly or annual software updates.
When the original ERP project closes, change governance procedures need to be adapted for BAU operation so that the BPM and system documentation structure that has been built up is maintained and kept up-to-date. If this is not done, the ability to easily visualise and manage the people-process-system relationships described above will become less reliable and inefficient. As the BAU teams are likely to be relatively small, they will be dependent upon good process and design documentation; loss of these features makes it more likely that expensive external resources would be required to support issue fixing or implement system changes.
Conclusion
BPM is an essential part of the overall architecture of an organisation; by integrating it with multiple aspects of the ERP systems used to drive the business, a coherent and effective mechanism for documenting people-process-system relationships can be achieved that facilitates both the deployment and on-going operation.
At Ownet, our consultants have breadth and depth of experience in BPM and ERP usage across many diverse business sectors and corporate life-cycle stages.
Business Process Management in an ERP Context
