Conventional on-premise installations of ERP are now rapidly being replaced by ERP as service. Although ERP becomes more accessible and no longer requires local infrastructure, current selection methods do not take full advantage of the provided agility. In this paper we present AMES (Agile Method for ERP Selection), a novel method for ERP selection which better utilizes the strengths of service oriented ERP. AMES is designed to shorten lead time for selection, support identification of essential system requirements, increase learning during the selection process and increase control over the subsequent ERP implementation. These properties of the method will help user organizations to make better and faster decisions when selecting ERP.
In light of service orientation of packaged software, long-standing sequential practices
for selection will now give room to more agile methods. Although software
development has radically changed due to the emergence of agile development
methods such as Agile Model Driven Development [
In this short paper our goal is to sketch out an agile method for ERP selection. We will use design science to design and evaluate our method. The method is evaluated using action research at a small entrepreneurial firm. The benefits of such method would be to shorten lead time for selection, increase knowledge building about requirements and system capabilities during the selection phase, decrease supplier dependency during selection and to initiate data migration during selection. The prime beneficiaries of such a method are user organizations, and organizations representing users, such as Business Application Software Developers Association2.
The article is organized as follows. In the next chapter we will present methodological and empirical basis for AMES. In chapter three we will describe the method and use running examples to illustrate it. In chapter four, we assess AMES using informed arguments and finally, in chapter five, conclusions are made together with suggestions for future research. 2
This section describes the research strategy used, the objectives of AMES, and present the user organization where the method was designed and applied. The action research conducted at the user organization is presented as a running example in Chapter 3. 2.1
For developing the method, we have used design science [
The overall objective is to solve the problem, sketched out above, by developing an
agile method for selecting service based ERP. User organizations will more quickly
identify ERP software with greater organizational fit [
2.3
AMES has been designed during an ERP selection process at a small entrepreneurial
firm with 10 employees called Activio [
This section describes AMES, which consists of three phases: Envision, Iterate and
Decide, see Figure 1. Envision consists of two activities, Iterate of three activities and
Decide of two activities. The boxes behind Iterate depict multiple iterations.
3 Correspond to principles 1, 2, 4, 6, 7 and 10 of the Agile Manifesto [
The relationships between the phases are marked 1-3 in Figure 1. The first relationship (1.) between Envision and Iterate shows that user organizations move from Envision to Iterate but it is also possible that user organizations return to Envision after one or more iterations if needed, e.g. when they have increased their knowledge about system capabilities and want to include more system candidates. The second relationship (2.) between Iterate and Decide show that user organizations move to a decision when there is no need for further iterations. However, depending on the outcome of the decisions, user organizations may want to return to Iterate to evaluate additional requirements or return to Envision (3.) to re-start the project. 3.1
AMES was constructed using Agile Model Driven Development [
The phase Envision aims at establishing a preliminary understanding of the goals and
scope of using the system. The phase includes two activities: Initial Value Statement
and Initial Project Modeling. The activity Initial Value Statement aims at describing
the benefits and the value created by the project. Typically ERP is adopted for
strategic, operational or technical reasons [
Running example The initial value statement formulated by Activio described the motives for selecting ERP as a combination of strategic and operational. The strategic motive was to establish an organizational structure which enabled Activio’s business to continue to grow. The operational motive was to replace manual procedures for material requirements planning by structured and integrated processes.
The Initial Project Modeling at Activio included a rough understanding of the organization and the critical processes which was based on interviews and discussions with the CEO and the person responsible for logistics. This understanding was used to define initial requirements and a preliminary scope of the project. Moreover, a gross list of candidate systems was complied. 3.3
The phase Iteration aims at identifying the ERP solution which best satisfies the user organization’s requirements. During this phase, requirements are iteratively defined, and evaluated against the candidate systems. Through iterating, essential requirements are identified and system candidates successively removed from the candidate list.
The phase includes three activities: Define Requirements, Analyze System Capabilities and Test Driven Evaluation. In the activity Define Requirements information is collected from the organization and requirements are defined based on this information. In the activity Analyze System Capabilities this information is used to make an analysis of the capabilities of the candidate systems. Work is performed in parallel to make accurate analyzes and assumptions against the requirements and involve participants from several functional areas. Based on these analyzes, requirements may be refined. The candidate systems are then evaluated against the requirements in the activity Test Driven Evaluation. The issues and problems that arise lay the foundation for new and refined requirements for the next iteration. Running example A total of four iterations were conducted at Activio. Candidate systems were evaluated against the requirements. Suppliers were frequently contacted in order to resolve issues that arose and Activio employees were continuously involved in resolving requirements issues. Meetings were arranged at the end of iterations and results from the evaluations were presented. At each meeting the evaluated requirements were demonstrated in the candidate systems. The candidate systems were accessed either as software as services or as downloaded demo versions from internet. During demonstrations new requirements were formulated and issues brought up by Activio’s employees were included in the next iteration.
There were three candidate systems left after the second iteration: Mamut,
Visma and Specter. During the third iteration the requirements became more detailed
and specific which made it possible to achieve greater organizational fit [
The phase Decide aims at coming to a conclusion whether to choose any of the evaluated ERP solutions or not. It consists of two activities: Apply Exit Critera and Go/No-go. The purpose of the activity Apply Exit Critera is to establish guidelines for when the requirements specification and the organizational fit is acceptable. The exit criteria define when the evaluation is completed and when a decision can be made. A general guideline is to stop iterating when the user organization does not identify any more essential requirements and only desirable and optional are formulated. The next activity is to decide whether to continue with a subsequent implementation of any of the candidate systems. The decisions can be of different types:
2. Decide to keep the old system and not continue with implementation
3. Return to Iterate to evaluate new requirements or new candidate systems
4. Combine parts of different systems and return to Iterate to evaluate the combined
system
Decisions are based on the test results complemented supporting information about
total cost of ownership and supplier reliability [
Running example After the fourth iteration at Activio no new essential requirements were identified and it was decided to stop the evaluation and move on to decision. The decision support material was complemented with information about cost estimates and supplier information and reference customers. The full process, from Envision to Decide, took 10 weeks to perform. 4
The method has not yet been empirically evaluated in a thorough way, but we here offer an evaluation in the form of informed argument. Increase requirements quality during the selection phase. By formulating requirements not only from user expectations but also from increased knowledge about system capabilities it is possible to formulate more essential, detailed and relevant requirements from the perspective of the user organization. Instead of guessing in advance, users can base their requirements on better knowledge about opportunities and limitations of the candidate systems at hand. Increase detailed knowledge about system capabilities during the selection phase.
During a conventional and sequential ERP selection process, it is difficult to fully
understand the capabilities of a specific system and user organizations easily
become dependent on knowledge transfer from suppliers’ sales representatives.
Through test driven evaluations, users can practically try-out how their
requirements fit with a particular system.
Decrease lead time for selection. AMES emphasizes prototyping and iteration to
let user requirements evolve and avoid that the selection process stagnates and that
time is wasted. The selection process took 10 weeks at Activio compared to
between 21-30 weeks as experienced by user organizations applying the methods
developed by the Business Application Software Developers Association [
The above objectives are related to each other. Some of the objectives interact positively, e.g. increase requirements quality during the selection phase is supported by increase detailed knowledge about system capabilities during the selection phase. While other objectives need to be balanced against each other, e.g. time v.s. quality where decrease lead time for selection need to be balanced against increase requirements quality during the selection phase. 5
In this paper, we have proposed a new method for ERP selection. The characteristics of the method include an agile and iterative approach to selecting ERP as service. The method has been successfully used at a small entrepreneurial firm where stakeholders appreciated involvement and early tests and found that AMES supported increased understanding and essential requirements identification. A main advantage of the method is that essential systems requirements evolve iteratively during recurring test driven evaluations, knowledge about detailed system capabilities develop during the selection period and that the decision lead time can be shorter than when using conventional selection methods.
Future work will include a second iteration of method design where aspects such as risk management and more detailed activities for establishing a well-balanced list of candidate systems. We also intend to evaluate the method in more organizations of different size, organizational settings and industries.
In design science, communication is often neglected, and a challenge for future research is to effectively transfer the method to practice. A suggestion is therefore to establish a professional service that supports effective transfer of methods to practice use in organizations.