Product software implementation method

A product software implementation method is a systematically structured approach to effectively integrate a software based service or component into the workflow of an organizational structure or an individual end-user.

This entry focuses on the process modeling (Process Modeling) side of the implementation of “large” (explained in complexity differences) product software, using the implementation of Enterprise Resource Planning systems as the main example to elaborate on.

Overview

A product software implementation method is a blueprint to get users and/or organizations running with a specific software product.

The method is a set of rules and views to cope with the most common issues that occur when implementing a software product: business alignment from the organizational view and acceptance from human view.

The implementation of product software, as the final link in the deployment chain of software production, is in a financial perspective of a major issue.

It is stated that the implementation of (product) software consumes up to 1/3 of the budget of a software purchase (more than hardware and software requirements together).

Implementation complexity differences

The complexity of implementing product software differs on several issues. Examples are: the number of end users that will use the product software, the effects that the implementation has on changes of tasks and responsibilities for the end user, the culture and the integrity of the organization where the software is going to be used and the budget available for acquiring product software.

In general, differences are identified on a scale of size (bigger, smaller, more, less). An example of the “smaller” product software is the implementation of an office package. However there could be a lot of end users in an organization, the impact on the tasks and responsibilities of the end users will not be too intense, as the daily workflow of the end user is not changing significantly. An example of “larger” product software is the implementation of an Enterprise Resource Planning system. The implementation requires in-depth insights on the architecture of the organization as well as of the product itself, before it can be aligned. Next, the usage of an ERP system involves much more dedication of the end users as new tasks and responsibilities will never be created or will be shifted.

Examples of other "larger" product software are:

• Enterprise resource planning software
• Customer relationship management software
• Content management system software
• Human resource management systems
• Supply chain management software

Software customization and Business Process Redesign

Process modeling, used to align product software and organizational structures, involves a major issue, when the conclusion is drawn that the product software and the organizational structure do not align well enough for the software to be implemented. In this case, two alternatives are possible: the customization of the software or the redesign of the organizational structure, thus the business processes.

Customizing the software actually transforms the product software in tailor-made software, as the idea of standardized software no longer applies. This may result in loss of support on the software and the need to acquire consultancy when issues arise in the usage of the software. Customizing however results in a situation where the organizational integrity is not adjusted, which puts less pressure on the end users, as less changes or shifts in workflows are required. This fact may positively add to the acceptance of any new (product) software application used and may thus decrease the implementation time and budget on the soft side of the implementation budget.

Redesigning business processes is more sensible for causing resistance in the usage of product software, as altered business processes will alter tasks and responsibilities for the end users of the product software. However, while the product software is not altered, better support, training and service levels are possible... because the support was created for the specific integrity of the software.

Implementation Frameworks

The guiding principle versus the profession

Another issue on the implementation process of product software is the choice, or actually the question, to what extent an implementation method should be used.

Implementation methods can on the one hand be used as a guiding principle, indicating that the method serves as a global idea about how the implementation phase of any project should run. This choice leaves more room for situational factors that are not taken into account in the chosen method, but will result in ambiguity when questions arise in the execution of the implementation process.

On the other hand methods can be used as a profession, meaning that the method should be taken strict and the usage of the method should be a profession, instead of a guiding principle. This view is very useful if the implementation process is very complex and is very dependent on exact and precise acting. Organizational and quality management will embrace this view, as a strict usage of any method results in more clarity on organizational level. Change management however might indicate that more flexibility in an implementation method leaves more room for the soft side of implementation processes.

Implementation frameworks

Apart from implementation methods serving as the set of rules to implement a specific product or service, implementation frameworks serve as the project managed structure to define the implementation phase in time, budget and quality.

Several project management methods can serve as a basis to perform the implementation method. Since this entry focuses on the implementation of product software, the best project management methods suitable for supporting the implementation phase are project management methods that focus on software and information systems itself as well. The applicability of using a framework for implementation methods is clarified by the examples of using DSDM and Prince2 as project management method frameworks.

DSDM

The power of DSDM is that the method uses the principles of iteration and incremental value, meaning that projects are carried out in repeating phases where each phase adds value to the project. In this way implementation phases can be carried out incrementally and add value to important project aspects such as the degree of acceptance, awareness and skills within every increment [F. Von Meyenfeldt, Basiskennis project management, Academic Service 1999]. In addition to the management of chance scope, increments are also usable in the process modeling scope of implementation phases. Using increments can align process models of business architectures and product software as adding more detail in every increment of the phase draws both models closer. The DSDM also has room for phased training, documentation and reviewing.

Prince2

As with DSDM, the Prince2 method acknowledges implementation as a phase within the method. Prince2 consists of a set of processes, of which 3 processes are especially meant for implementation. The processes of controlling a stage, managing product delivery and managing stage boundaries enable an implementation process to be detailed in with factors as time and quality. The Prince2 method can be carried out iteratively but is also suitable for a straight execution of the processes.

The profits for any implementation process being framed in a project management framework are:

Clarity

An implementation framework offers the process to be detailed in with factors such as time, quality, budget and feasibility.

Iterative, incremental approach

As explained, the possibility to execute different phases of the implementation process iteratively enables the process to be executed by incrementally aligning the product to be implemented with the end-user (organization).

Embedded & Generic methods

One way to implement product software is through usage of an embedded method or model. Embedded models are part of the auxiliary materials (see: definition of product software) that come with the software package.

Implementing a software product using an embedded model implies not only that the model is (mostly) only usable with the specific software product, but also that the product can or should only be implemented using the model. Embedded methods can thus be seen as very specific ways implementing product software.

Examples of software products with an embedded method are:

Implementing SAP (SAP R/3), using the ARIS embedded model.

Implementing the Baan ERP system, using Dynamic Enterprise Modeling (DEM).

Implementing Oracle E-Business Suite, using Oracle Application Implementation Method (AIM).

Generic implementation methods are not meant for a specific software product but for common usage in implementing product software products. This usage is going to be elaborated on using the example of implementing product software using Object Process Methodology. This methodology is very useful in for example ERP modeling: the modeling of ERP systems in order to implement it into an organizational structure.

Assessments

Using an embedded method brings the power that the method is designed to implement the software product that the method comes with. This suggests a less complicated usage of the method and more support possibilities. The negative aspect of an embedded method obviously is that it can only be used for specific product software. Engineers and consultants, operating with several software products, could have more use of a general method, to have just one way of working.

Using a generic method like ERP modeling has the power that the method can be used for several ERP systems. Unlike embedded methods, the usage of generic methods enables engineers and consultants that operate in a company where several ERP systems are implemented in customer organizations, to adapt to one specific working method, instead of having to acquire skills for several embedded models. Generic methods have however the lack that implementation projects could become too situational, resulting in difficulties and complexity in the execution of the modeling process, as less support will be available.