Process Driven ERP Implementation: Business Process Management Approach to ERP Implementation

Abstract

One of the most indicated reasons for ERP implementation failure is that the organization failed to recognize the impact the system would have on business processes. A possible solution to this could be to use an approach focusing on process change when implementing ERP systems. In this research paper, we take a look at Enterprise Resource Planning systems implementation from a Business Process Management point of view. It attempts to improve ERP implementations, which are frequently unsuccessful, with insight provided through the BPM Paradigm. The focus lies on the phases and activities in the two concepts as well as defined success factors which targeting the similar objectives. The data collection was conducted in the form of interviews with respondents from two companies in Bosnia and Herzegovina and Croatia that conducts ERP implementations. It was concluded that the first four phases of BPM fit the frameworks of ERP implementation. What authors found interesting is findings suggesting the main enabling activity to be process modelling. Also CFS for ERP and BPM were compared, and the conclusion is that both are targeting similar aspects–operational business processes.

1 Introduction

The role of Enterprise Resource Planning (ERP) systems in managing business processes has expanded significantly over the past decade from an emphasis on specific business areas such as sales, manufacturing or purchasing, to broader use throughout the company.

ERP systems are standardized software that includes modules for practically every aspect of an enterprise. Comes with best practice (an in-built process suggestion) of how a business should work and how data should flow within the organization. On the other hand, while the built-in processes in an ERP often can be considered best practices, there is no guarantee that they will work better than the current processes in an organization [1]. Instead of making a system completely adapted to the company’s processes, an ERP system offers a set of processes for the organization to follow [2]. While the main job of the system is to improve the flow of information in an organization, it’s inevitable that the business processes are affected as well [3]. In fact, using an ERP as a solution to solve operational problems such as ineffective business processes is frequently stated as motivation for the implementation [4]. But, we are witness of high numbers ERP projects which do not satisfies initial customer expectations. As Fig. 1 shows, less than 50% of implementations achieve expected benefits, while only 17% of the companies experienced more than eighty percent of their projected benefits.

Fig. 1.

Expected benefits for ERP projects (Panorama Consulting Solutions Report 2012)

Research done by the consulting group Panorama Consulting Solutions shows that one of the reasons that ERP implementations take longer than expected or fail to achieve their expected benefits can be attributed to the high degree of code customization used to tailor ERP systems to business requirements (business process requirements) (see Fig. 2). The research shows that 60% of companies perform some degree of customization which can contribute to longer implementation times and higher costs. (Panorama Consulting Solutions Report 2012).

Fig. 2.

Degree of customization in ERP projects (Panorama Consulting Solutions Report 2012)

As we see in Fig. 2. ERP systems implementations tend to be conservative, regarding the scope of customization and change. And this is the issue for the most customers – they are not satisfied with the extend of system modification in favor of their own business processes. In order to better manage and improve business processes, BPM (Business process management) become one of the crucial point to every competitive business.

As it is stated by [5], BPM takes a softer approach to process change and instead of being rapid and radical the change is seen as an evolutionary procedure. BPM with a focus on evolutionary change, collaboration and with the goal to give the control over IT back to the business people [5]. BPM also advocate a focus on change of business processes rather than creation of business processes to fit the changing nature of today’s business.

Since it’s highly recognized we can conclude there are strong linkages between ERP implementation and process change (e.g. Shang and Seddon [1]; Aladwani [6]), and there should also be a possibility to combine an approach focused on process redesign (BPM) with an ERP implementation. In next paragraphs, we will go deeper in explanation of similarities/differences between ERP and BPM. First we will give brief description of ERP and BPM, and then compare their Critical Success factors in other see are they targeting the similar problems. After it we will go through ERP and BPM implementation methodologies.

1.1 ERP, ERP CFS and SAP ERP Implementation Methodology

ERP systems are standardized software that includes modules for virtually every aspect of an enterprise. Comes with best practice (an in-built process suggestion) of how a business should work and how data should flow within the organization. It’s however important to critically examine what these processes look like and not take for granted that they are best practice for the implementing company’s specific business [6]. Klaus et al. [7] suggest that this is one of the causes of ERP implementation failures, because the view of functions is too limited. They suggest that a broader view must be used when implementing ERP.

Critical success factors can be created to compare and improve implementation methods. For this research, we have also compared the CSFs of ERP and BPM implementations. Multiple studies have identified different CSFs for ERP implementations. One of these studies by Somers and Nelson [8], identified 22 CSFs. Their list was compiled from a meta-study of over 110 cases of ERP implementations. This list was used by Akkermans and van Helden [9] who let 52 managers rate these CSFs and compiled a ranked list of the 22 CSFs. In our study, we will use this ranked list to compare it with our list of BPMS CSFs (Table 1).

Table 1. List of BPMS CSFs

In this ranked list, we can see that there is little focus on the effect of ERP systems on the business processes in the organization, but we can conclude that all CFS targeting the operational improvement of companies, which indirectly suggesting improvement of business processes.

SAP ERP Implementation Methodology

As the ERP implementation methodology we chose to investigate SAP ERP methodology, which is one of the most widely used The SAP ASAP 8 methodology comprises of six phases as highlighted in Fig. 4., which is a disciplined approach to managing complex projects, organizational change management, solution management, & industry specific implementations. The SAP ASAP 8 methodology is the enhanced Delivery model with templates, tools, questionnaires, and checklists, including guide books and accelerators. ASAP 8 empowers project teams to utilize the accelerators and templates built in to SAP solutions. The Agile add-on is available in SAP Solution Manager. Figures 2, 3 and 4 explains various phases of SAP ASAP 8 Methodology.

Fig. 3.

New SAP methodology – SAP activate on premise project (SAP 2017)

Fig. 4.

BPM lifecycle

• 1. Prepare - This phase encompasses the entire project preparation and planning activities with infrastructure, hardware/network sizing requirements completed. It involves setting up the infrastructure, team, project goals, charter, and agree upon schedule, budget, risk baseline, proof-of-concept planning if applicable with implementation sequence. The project manager on the ground will discuss with the customer project manager to identify risks early on with a mitigation plan. The PM will be responsible for drafting a high-level project plan with all milestones with a detailed task level plan chalked out with critical dependencies. Each phase deliverable should be agreed between both parties. Finally, a project organization, steering committee is organized with assigned resources.

• 2. Explore - This is the most crucial phase of the project for a project manager as he just about to steer the ship, like a captain. The objective of this phase is to be on a common platform on how the company plans to run SAP for their business operations. Thus, a PM is responsible for analyzing the project goals and objectives and revise the overall project schedule if required. In simple terms, it is the critical requirements gathering phase, A PM might use appropriate tools to collect requirements with required traceability. The result is the Business Blueprint, which is a detailed flow of business process AS-IS, how they run the business operations with a TO-BE mapped in SAP, on how these business operations will run in SAP. Depending on the implementation complexities, number of business process, Blueprint workshops might span for a few days or weeks or even months, in a complex environment. The output of this phase is the baseline configuration in SAP with detailed custom code requirements analysis done.

• 3. Realize - In simple terms, realization is the actual development phase of the project, where you’d configure, develop custom code and conduct required testing. It involves coding-unit testing-integration testing-User acceptance testing (UAT). As per the business blueprint and mapping the SAP system as agreed with business, all the business process requirements will be implemented. In reality, there are two major work packages: (a) Baseline (major scope); and (b) Final configuration (remaining scope). The success of any implementation project relies on how closely you’re able to develop custom code, test and release it to the UAT phase, in order to support adequate testing by the users. Also, the challenge is to adopt changes as indicated during the UAT. This phase is resource intensive and the team is at peak team size to ensure all deliverables are met and sign-off. Often times Integration fail due to lack of test data, and testing in a “PRD” like environment to be able to test all critical business scenarios. A good practice is to copy a “PRD”-like environment and start testing if the system already exists. If it is GreenField environment, ensure adequate test data is available to test it rigorously.

• 4. Deploy - Final preparations before cutover to production ensure that that the system, users, and data are ready for transition to productive use. The transition to operations includes setting up and launching support, then handing off operations to the organization managing the environment.

1.2 BPM, BMP CFS and Implementation Methodology

BPM is a series of methods, techniques and tools to analyze, design and improve processes that take place in a company [10]. BPM resolves around processes and implementation of IT systems around these processes. Lee and Dale [10] suggest that multiple paths have to be taken when implementing IT-systems, a method that can handle the implementation of IT-systems in every situation is impossible.

BPM CFS

Through literature research of scientific papers we have searched for keywords like CSF BPM, CSF BPMS implementation, critical success factors of business process management and critical success factors of business process management implementation. We found a list of CSFs concerning BPM implementations. These CSFs originated from different BPMS methods like Cordys@work, BPMS implementation method, Goal driven BPM, and Nine-step approach. For a complete overview of different BPM related implementation methods we refer to Ravesteyn and Versendaal paper [11]. From their list of CSFs we determined which factors are process- orientated.

We aim for process oriented CSFs to constrain the scope of this research, and to keep to the core of BPM, which are processes. Also, other CSFs are more function- orientated, meaning the use of these CSFs will not broaden the view of ERP implementations. The CSFs are extracted from the research of Ravesteyn and Versendaal work (Table 2).

Table 2. Critical success factors of BPM implementaion

The following critical success factors of BPM implementations have been found:

BPM Implementation Methodology

It’s divided into eight parts and stretches from discovery to analysis in a continuous cycle. Similar life cycles have been presented by van der Aalst et al. [12] as well as Netjes et al. [13]. The two-latter compressed the life cycle to only being four and five phases respectively. However, the extra phases in Smith and Fingar [5] are often present in the other life cycle definitions as well, but then as activities instead of full phases.

We will go in detail explanation of each phase of BPM lifecycle.

• 1. Discovery. The discovery of a process means finding out how something is done or can be done and should provide a clear picture of how the process works, both internally and externally. This process mining can be done either manually by mapping out the business or automatically by introspection of legacy system code. The goal is the same, to make ingrained processes explicit and provide an understanding of the business as a whole.

• 2. Design. The input in this phase is either a need for a new process or an already existing process that through the diagnosis phase has shown weaknesses. If it’s the latter, the objective is to create an alternate process where improvements have been done to those areas of the process the diagnosis found weak (Netjes et al. [13]). The emphasis lies on the performance of the process and what the internal structure looks like. The activities in the design phase are modelling, manipulating and redesign of the processes after they’ve been discovered. All the elements of the process, the actors, resources, rules and relationships are determined and tested in different scenarios with the help of simulation. Process metrics should be set in order for business analysts to be able to spot any variances and quickly react to competitive pressure or opportunities in the market. Smith and Fingar [5] point out that the modelling notation used should include behavioral aspects of the process and be compact in nature to be able to include abstract business concepts. The modelling in BPM is meant to be done by business analysts rather than software developers who usually create models to interpret the business in order to create a system that supports it [5]. The output of the phase is a process definition that states process structure, resource structure, allocation logic and interfaces.

• 3. Deployment. The deployment phase means that the process is rolled out to the involved people, applications and connected processes. The process is moved from the modelling board to the real business and the necessary resources are distributed. Smith and Fingar [5] claim that in the new era of BPM, all this can be done with minimal manual intervention and without additional technical steps. They state that IT is capable of doing this through in advance using a projection of the process to integrate application components. The process can also be mapped and bound to standardized interfaces to work between organizations, business units and management systems.

• 4. Execution. When the conditions for the process are set in the deployment phase, the process goes live and is carried out by the participants. Generally, the execution is performed by a process management system that controls the flow of data, translates where needed and stores data about a process. In the execution phase the attention shifts from the internal structure of the process to how it works in a specific context and what factors in the context that can change [13]. Some of these environmental aspects are information on arriving cases and availability and behavior of the internal as well as external resources involved in the process. By the van der Aalst et al. [12] this phase is called the enactment phase and represents the launch or execution of the process through a chosen tool, often an IT tool.

• 5. Interaction. Process portals and process desktops are used to let people interact with business processes. The tools act as a gateway between manual work and automation, and lets people manage, observe, monitor and intervene within processes. BPM represents processes as data and it is Smith and Fingar’s [5] presumption that techniques will emerge that lets users create, read, write, modify and extend process description in a manner similar to how HTML editors work today.

• 6. Monitoring and Control. This phase represents the maintenance of the process in a way similar to how maintenance of an Information system works. Activities include making sure sufficient resources are allocated, dealing with unexpected errors and making sure the technical environment works as it should. By identifying variances in the flow and alerting process owners, temporary bottlenecks can be prevented by the adding of extra resources. Minor changes to the internal structure are done in the form of adding, removing or changing participants. The monitoring involves tracking of the input throughout the whole process in order to see that it works as smooth as possible. Both data on individual cases and aggregate performance of the workflow is recorded [13]. The data collected can then be used as input for the diagnosis in the analysis phase in order to identify any improvement possibilities.

• 7. Optimization. The optimization aspect means a process of continuous improvement of single processes, classes of processes and the business as a whole. It’s the activity that closes the BPM life cycle since it takes the feedback from process performance analysis and returns it as input for a new design phase. Process optimization becomes possible when the result of the monitoring is used to determine whether changes can be made to reduce costs, increase effectiveness or similar [12]

• 8. Analysis. The measuring of process performance and the analysis of the results is what really makes a difference when it comes to business improvement [5]. The data from the control phase makes it possible to diagnose processes and decide whether they can be improved in any way. The aggregate data becomes the subject of process mining, business process intelligence and data mining techniques to identify factors that makes the process not function optimal [13]. Business Intelligence in the form of business metrics like activity-based costing or key performance indicators should be extracted directly from processes in order to see exactly what affects them. This data can be compared to history, benchmarked to best practice or compared to other similar processes. Once again simulation becomes an important technique, since it can help in providing information on how changes can improve a process.

2 Theoretical Framework

The theoretical framework builds upon three keystones of articles and books; those focusing on providing ERP and BPM implementation frameworks, those debating the relationship between Process Management and ERP and BPM critical success factors.

This paper sets out to investigate what possibilities exist to combine the strategic approach of BPM with ERP implementation. In order to do this the two concepts must be thoroughly explored, the phases in ERP implementation must be determined as well as what activities these phases consist of. Achieving a detailed description through quantitative means is a possibility but then the holistic picture of an implementation could be missed. In a quantitative survey for example, much of the researcher’s control is lost once the survey is sent out, meaning that if the data wasn’t sufficient to show the full picture of an implementation another complementary survey would have to be sent. In qualitative research, it’s on the other hand possible to quickly and freely move between collection of data and theoretical analysis [14].

Furthermore, a qualitative approach is best used when variables not easily can be identified and when there is a need to present a detailed view of the topic [15].

Out of the five methodologies described by Creswell [15] the study has the most similarities with a case study. First, the setup of the research matched the description of case studies by Yin [16]. The research question is an exploratory “what”- question, there is no need for control over behavioural events and it focuses on contemporary events. We decided to use interviews in other to collect data. Methodologically, the strength with interviews is that they are targeted and focuses directly on the researched topic [16].

Choosing few respondents can be beneficial when the problem is not thoroughly explored and in need of indepth analysis (Kvale, 1996) We had a choice between approaching businesses that had recently implemented an ERP system, seek contact with consulting firms that conduc them more often or to collect data from both sides. It was decided that respondents from consulting companies would be the most suiting for the research paper, since it would give access to a wider spectrum of data that still were as detailed as if a “normal” business would be chosen for the study. Methodologically, the strength with interviews is that they are targeted and focuses directly on the researched topic [16].

2.1 Case Studies: JP Elektroprivreda BiH (Company A) and B4B (Company B)

Company A: JP Elektroprivreda BiH d.d.

JP Elektroprivreda Bosne i Hercegovine d.d. Sarajevo (Public Enterprise Electric Utility of Bosnia and Herzegovina) is a joint stock company in which 90% of the capital is owned by the Federation of BiH, and 10% is owned by minority shareholders.

Electric utility activities performed by the Company as public services are:

• Generation of electricity for unqualified (tariff) customers

• Electricity distribution

• Electricity supply for unqualified (tariff) customers.

JP Elektroprivreda BiH has about 15.000 employees which are supported by internal IT organization. Integral part of IT organization is SAP internal team with over 15 people supporting about 1000 users.

Company B: B4B d.o.o. Zagreb

b4b d.o.o is the leading regional SAP consulting company with the head office in Zagreb and since April 2001 it has been a SAP partner for Croatia, Slovenia, Bosnia and Herzegovina, Serbia and Montenegro, Albania, Romania and Slovakia. b4b d.o.o has around +100 employees and more than +90 consultants with rich business and IT experience gained and proven by numerous SAP implementations in Croatia and in the region. b4b d.o.o belongs to the elite society of Croatian “knowledge exporters”.

We chose 3 participants from both companies. All participants are the ERP consultants, with over 10 years of experience in SAP ERP implantations. Also, they are all Manager levels in their companies (from junior consultants to mangers) which should indicate solid knowledge in both technical and process aspects.

2.2 Discussion on Interviews with Expert from Company A and Company B

Some might argue that combining ERP implementation and BPM isn’t possible due to the difference in organizational level they are conducted at. BPM calls itself a strategic approach while an ERP is meant to enhance the operational functionality of a business. However, by looking at the concepts in the form of phases, both concepts can be found on a tactical level. The specific activities in each phase relates to tasks performed on a day to day basis, either by participants in an implementation project or a process manager.

In BPM, the actual management and monitoring of processes is on a tactical level where process owners can make adjustments to solve short-term problems like temporary bottlenecks. BPM initially focuses on the discovery, design, deployment and execution of one of organizations core operational aspects, its business processes. These processes are the same that is going to be affected by the ERP system, therefore making it possible to use BPM in an ERP implementation. The life-cycle match can be shown by describing the similarities between the phases in BPM and the phases in ERP implementation:

Discovery.

To find out how something is done or how it can be done can be seen as one of the earliest activities in the preparation for implementing an ERP system. This phase can therefore only really be connected to ERP if an ERP system is decided as the way of putting the process change into practice.

This means activities like setting up preliminary goals for the implementation and evaluating different ERP vendors.

In company B’s methodology the business processes are communicated to the consultants in the first phase in order for them to understand what the business really is. Since the activities aren’t included in Company A method and not found in Ross and Vitale [3] or Markus et al. [18] the connection of this phase to ERP implementation is questionable. However, the introspection of the business most likely means that the project has started, at least from the business point of view. For an integration of the concept to function, the process mining and discovery must be done by business first and then communicated to the consultants.

Design.

Smith and Fingar [5] state that the main activities in the design phase are modelling, manipulation and redesign of business processes. This is to be done using a modelling notation understandable by business analysts and thereby cutting of the long chain from requirement specification to executable code. The design phase in BPM in many ways corresponds to the design phase described in ERP frameworks and to the GAP-phase presented in the paper. It can be argued that since an ERP system comes with a predefined set of processes, why and how should these then be modelled? The answer lies partly in what Parr and Shanks [4] describes in their “Re-engineering”-phase where a mapping should be done between the current business processes and the functions of the ERP (GAP analysis).

This means the modelling is three-tiered and becomes essential in ensuring a fit and making sure the business learns what the change will be like.

The choices proposed by Ross and Vitale [3] about process change and process standardization very much affect what modelling effort is needed in the implementation. These decisions will determine to what extent the system needs to be customized. The taxonomy by Parr and Shanks [4] is useful when determining if BPM can play a beneficial role in ERP implementations. Vanilla implementations, which involves few sites and adoption of the process suggestion embedded in the ERP require less modelling since there is no mapping and no major design of the system solution needed. It is hard to believe that Vanilla implementations will be sufficient for companies with well-developed legacy system.

Also, implementations that falls under the “Comprehensive” category that involve multiple sites in different countries and a lot of modules mean a much bigger change with more people and business units affected. The need for customization increases in order for the ERP to work with existing core processes. In large implementations there are usually a need for integrations, either with necessary legacy systems or with clients and suppliers. This adds up to all three modelling activities being needed; design of processes, mapping of processes to the system and design of the system itself.

Deployment.

While the description of deployment by SAP implementation methodology is that the process is rolled out automatically to all participants, they also mention it to be a preparation for the execution. By preparing integration with legacy systems or external systems the transition to the new process goes through with little friction. Company A uses the SAP implementation methodology that include a phase of final preparation, where the business makes the last adjustments before the system goes live. Also as interviewee mentioned integration with old systems or other stakeholders systems aren’t uncommon when implementing ERP systems. The deployment activities in BPM could be used to make sure these integrations work when the system finally goes live. A step in that direction can be seen in the Business process management suite in Company B’s ERP system, where an enterprise collaborator is used to communicate with other systems in the organization. By using such a tool, all other systems could prepared for the launch of the ERP system.

Execution.

When all preparation is complete, the new process is executed with the help of a process management system according to Smith and Fingar [5]. However, the execution itself is all about setting the process in motion and making sure all participants can fulfil their tasks and have the necessary resources allocated to them. The execution is the equivalent of the go live of an ERP system, which in effect means that all the new processes are used.

While the comparison shows that the initial four steps of BPM can be combined with an ERP implementation, there is no match between the remaining steps and the project of implementing an ERP system. Interaction, monitoring and control, optimization and analysis emphasizes the “management” in BPM and has to do with the ongoing work of supervising and enhancing business processes. It can be argued that the Shakedown and Onward and upward phases of Markus et al. [18]) describes these activities in an ERP context but what it does is really stating the obvious, that there is a time of ups and downs after implementing an ERP. Both the Ross and Vitale [3] and Parr and Shanks [4] frameworks include similar phases labelled Continuous improvement, Transformation and Enhancement but also they lack specific description of activities. The last step in both Company A and Company A (since they used the same methodology) method is Go Live support, where adjustments to the system or extended training for the users are the main activities.

When it comes to maintenance and management of the processes that is not a part of the implementation. The rest of the phases in BPM can therefore not be said to fit in an ERP implementation. However, that is not to say that an ERP system can’t facilitate these activities of managing business processes. It’s beyond the scope of this thesis to investigate that further, but the fact that most ERP system has a workflow module and that BPM is based on Workflow Management makes it a possibility worth investigating. If it should prove to be possible, the third wave of Process Management could be built upon the ERP technology of today. The Process flow integrator module in Company B has the functionality for process modelling and process description as described by BPM theory. It however lacks the functionality for management, monitoring and diagnosis which also is stated as the difference between WfMS and BPMS by van den Aalst et al. [12]. The match between the phases of ERP implementation and BPM relies on one big assumption. While Smith and Fingar [5] continuously couples BPM with specified technology in the form of BPMS, that kind of technology is not a necessity for the discovery or the design parts of BPM. In fact, van den Aalst [12] and Netjes et al. [13] do not involve IS until after the design, in the enactment phase and execution phase respectively. What this means is that in order for the proposed match to hold, the decision to use ERP as the IT solution of choice must be taken already in the discovery phase of the BPM life cycle.

As the all participants concluded the main enabler of connecting ERP and BPM methodologies would be intermedia – such as business process modelling tool/notation.

By using a modelling language like BPMN (or other) in the process modelling, users can more easily understand and have more control over how the ERP system will impact business processes.

Process Modelling

Process Modelling and the use of BMPN is an essential part of the use of BPM in ERP implementations. Using BPMN means that the new processes becomes understandable by the business and individuals from the business side can take bigger part in the designs of the processes, customization of the system and the mapping between them. It can greatly help in reducing the errors in the GAP document, which later becomes a source of resistance according to interviewee from Company B. This could be resolved since there no longer would have to be a consultant trying to understand what it is the business really want the new system to do. Instead, the business side could themselves learn BPMN and model the way they want their business to work with the new ERP system. The mapping of the current processes to the system could be done by the business and the consultants together. After those two design activities, the consultants could then design the system solution with the help of BPMN, making the final solution understandable by the business that then better could target their training and prepare for the transition. The process flow integrator in Company B’s product claims to have a functionality for process modelling where a notation is used that requires no computer language skills.

To fully enable the BPM approach, the next step would be to use the BPM module from the start in an ERP implementation. In doing this, it becomes a tool for the implementation of the ERP system by providing modelling possibilities as well as a tool for managing processes after the system has gone live. Since it’s already a part of the ERP system, the BPM module would handle the deployment of the new processes in the way a BPMS would do, as suggested by Smith and Fingar [5].

3 Conclusion

This paper researched how an ERP implementation could be improved by using a BPM based strategy. The resulting conclusions of the study are as follows - there is a fit between the activities in the first four phases of BPM and ERP implementation. The discovery, design, deployment and execution of processes are possible to integrate with activities in an ERP implementation. The final step of an ERP implementation is taken a short time after the system has gone live and is in many ways similar to the execution of processes in BPM.

Also, the CFS of BPM and ERP are not the same, but targeting the similar aspects – business process, which are the key focuses of both implementations.

The main activity that can connect the concepts is Process Modelling using a notation understandable by individuals in the business and that corresponds to immediate changes to the system. By using a modelling language like BPMN in the process modelling, users can more easily understand and have more control over how the ERP system will impact business processes.

To let the business be a part of the actual process modelling and customization of the system could make sure the end result matches the expected result. It also means that the gap between business and configuration of IT systems is eliminated, a central idea of BPM.