ERP implementation: high level process identification and scoping

Bas Beuger
Posted by Bas Beuger on Nov 26, 2012

Business Process Management

Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.

In this blog I will elaborate on how to scope an ERP implementation initiative on a high level. In my first blog regarding ERP implementation I presented an effective approach for ERP implementation. This encompassed a description of five steps from which I focus on the first three steps in this second blog.

The approach When we recall the proposed approach, the first three steps relate to high level identifying and scoping of the initiative. This is essential for elaborating the processes in more detail and identifying the requirements.

Step 1: Determine scope

For a large-scale project as an ERP implementation one should be aware of the consequences related to a lack of scope and/or vision. Lack of scope or vision is harmful for the support and commitment of the business and can ultimately lead to a premature termination of the initiative. The first question you should ask yourself when considering ERP implementation is for what reason you want to implement ERP. Do you experience any problems regarding the provision of information in your processes? Do you see the ERP implementation as a chance to fully standardize your business processes over several departments and business units? Are you implementing ERP for the whole organization (including business units abroad) or is the implementation limited to some parts of the organization? These basic questions have serious consequences for the execution of the project and the people that should be involved. During the project one should also communicate a clear and unambiguous vision of the project towards the business in order to create commitment to attain optimal results.

Step 2: Describe process architecture

Scoping the initiativeFor the full and definitive scoping of the project one should have a clear understanding of the process architecture of the organization. In other words; how do we create customer value? The process architecture is the basis for the subsequent steps of the approach. For lots of organizations and branches process architectures are publicly available by means of reference architectures. Examples are SCOR (supply chain organizations) and eTOM (telecom organizations). Such reference architectures provide an excellent kick-start for your preparation and save a lot of time and effort in re-inventing the wheel. Furthermore, these reference architectures are often not only known by ERP providers, but might also be known by partnering organizations in your supply chain. In turn this leads to opportunities for supply chain optimization. Obviously, tailoring a reference architecture to a specific architecture for your organization is required since reference architectures are generic (in contrast to most organizations). An important remark is that the first draft of the process architecture can be the work of a (few) business analyst(s), but eventually the process architecture should be supported by the whole organization. At first the project team and then the business should become ‘owner’ of this process architecture. The process architecture should become a representation, visualization and shared understanding of how the organization creates customer value. This can only be achieved by sharing the (concept) process architecture with key business stakeholders and incorporating their comments. During the project,  this process architecture might need some modifications and improvements based on progressive insights. The process architecture is essential for executing subsequent activities, preventing unconscious exclusion of vital business processes and is a good means to communicate to your business stakeholders.

Step 3: Identify strategic, generic and remaining processes

The process architecture provides insight in the primary and supporting processes of your organization and how these are related to each other. Now, one should prioritize the processes in terms of the extent to which we want to elaborate the identified processes in process models and identify their system requirements. Each process is labeled as either strategic, generic, or ‘remaining’. This classification is the basis for further scoping of the preparation of the ERP implementation, since strategic processes are further elaborated than generic or remaining processes.

Again, for commitment of the business the criteria for classifying the processes need to be clear and traceable. Why do we label some processes as strategic while others as generic or ‘remaining’? These criteria are determined by the project team, but should be transparent to the business. Furthermore, the criteria should cohere with the set scope, objectives and character of the project (such as available time and resources). Some examples of criteria that can be used for classifying the processes are:

  • Is the process significantly contributing to the organization’s  core competences? Is there  direct customer contact in this process? Is the process directly creating customer value? Are there any legal/political reasons for which ERPwe should exclude any risk regarding the execution of the process? These are the processes that should be labeled strategic.
  • How heavily is this process related to the other processes defined in the process architecture? The higher the interdependency, the more impact an eventual error in the process has on the business’ operations. These processes are labeled as generic processes, since they provide input for lots of other processes. Other possible candidates for these generic processes are processes that use a lot of different organizational resources for which intensive information provision by the ERP is required.
  • Processes which are not identified as strategic or generic will not be elaborated extensively during subsequent preparation activities. Though one should have a clear understanding of these processes and how these are related to the strategic and generic processes, detailed elaboration of these processes is omitted.

These are the first three steps of my proposed approach for effective ERP implementation. These steps enable you to scope the initiative and provide an high level insight in the business processes in place, which are (not) in scope of the ERP implementation. The following blog will elaborate on the last two steps in the approach: how to elaborate the identified processes in more detail and identify the requirements. So stay tuned for the following blog and if you have any questions, please leave a comment.

Request a demo


Join 10.000+ others! Get BiZZdesign's latest articles straight
to your inbox. Enter your email address below:


Subscribe to Email Updates

comments powered by Disqus