ERP implementation: detailed process descriptions and requirements

Bas Beuger
Posted by Bas Beuger on Jan 9, 2013

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 describe how to elaborate the identified processes in order to specify the requirements. In my first blog regarding ERP implementation I presented an effective approach for ERP implementation.The approach
In my second blog I discussed the firs
t three steps of this approach. In this blog I continue with the last two steps of this approach (step 4 and 5) which results in an effective preparation for the ERP implementation.

Step 4: Elaborate processes

In stDetailing the processesep 3 we identified the strategic, generic and remaining processes. Based on the classification of the processes we elaborate each of these processes to a certain extent into process descriptions. A workshop is a good means to bring all relevant employees together in order to retrieve their knowledge and combine it with the available information on the processes. By using a visual modelling language (such as BPMN 2.0) we can easily review the retrieved processes with other process stakeholders, who were not involved in describing the process (e.g. stakeholders in business units abroad). One should seek for balance; include enough people with respect to content (and to create commitment), but including too many people is extremely time consuming. Just as with the process architecture, each individual should have a common understanding of the process description (e.g. the involved employees, department managers and process owners). Since these process descriptions result in the main requirements of the ERP system, all process stakeholders should review and agree on the final process descriptions.

Because of time and budget constraints we cannot elaborate each of the identified processes into great detail. For the ‘remaining’ processes – which are often supporting processes – the IGOE descriptions are an efficient means. We describe the Input of the process (what goes in?), the Guides that regulate the process (e.g. legislation and policies) the Output of the process (what is the result?) and the Enablers (what people and resources do we need?). This provides a global overview of what the process is about, without spending too much time on describing the whole process into detail.

Example IGOE description

Step 5: Identify basic requirements

After completing the process descriptions one can specify the requirements. For each type of process (strategic, generic and ‘remaining’) one can choose how detailed the requirements should be elaborated. The input for this ‘last’ step can be retrieved throughout the whole process of performing the previous steps of the approach. Most of all during the workshops in which the process descriptions are created, since these involve the people who are doing the actual work. 

We can distinguish three types of requirements:

  • (Strategic) business requirements
    (Strategic) business requirements focus on the requirements that are necessary in the light of future development initiatives of the business. Examples are the support of an online web shop and the acquisition of new business (units) and/or products. One should also keep in mind that plans for major changes in the organizational design can result in specific business requirements regarding the ERP system. 
  • Functional requirements
    These are the requirements that are directly derived from the work that is carried out in the process. When elaborating the process, one acquires a good understanding of the sequence of the activities that are performed (workflow) and the information that is required in these activities (information requirements).

  • Non-functional requirements
    These are the requirements concerning quality attributes. These requirements are often specified on a later moment in time, although some non-functional requirements become clear during the creation of the process models. Examples of these non-functional requirements are availability, scalability, flexibility and usability. 

These are the last two steps of my proposed approach for effective ERP implementation. These steps enable you to create detailed process descriptions and specify the requirements that should be met by the ERP system. The last blog will discuss some pitfalls and opportunities that exist during the implementation of an ERP system. So stay tuned and if you have any questions please leave a comment.  

Forrester Wave Enterprise Architecture 2017


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