How to replace an enterprise software system the right way
Motivations and Business Processes Analysis as a preparatory step in the replacement of an enterprise software system
Sometimes a client wants to replace a software system with a new one. This can happen for a variety of reasons: perhaps the software solution is no longer being actively developed, or the business processes have changed to such an extent that the software is no longer suitable for achieving certain organization goals.
Particularly complex is the case with the replacement of enterprise systems, software systems that play an essential role in the efficient and effective execution and management of business processes that span across functionally diverse and/or geographically distant departments.
The situation becomes even more complicated if the customer finds him or herself in a vendor lock-in condition (i.e. in a relationship of dependence on the software supplier), such that its replacement and the switch to another software or supplier involves significant costs and risks.
How to move in such a situation, in order to develop a feasibility study that takes into account different possible scenarios, such as in-house software development or use of SaaS solutions?
Before starting any analysis of this type, there are, in my opinion, some preparatory steps to take.
Analysis of motivations
A good first step is a detailed analysis of the reasons for switching from one software system to another.
In this regard, the motivations analysis proposed by TOGAF (The Open Group Architecture Framework) is well suited for this purpose. Essential in this framework are the concepts of stakeholder, meaning, value, drivers, assessments, goals, outcomes, principles, requirements and constraints, which we define below.
A stakeholder represents the role of an individual, a team or an organization (or classes of them) and its points of interest with respect to a software system. Example: “Customer”
A meaning is the body of knowledge present in, or the interpretation given to, a concept in a specific context. A stakeholder can also be associated with a meaning if one wants to emphasize for example the relevance of their relationship. Example: “Insurance Policy notification”
A value is the relative value, usefulness or importance derived from a concept. It usually applies to the external appreciation given to goods, services, information, knowledge or money. Example: “Be insured”
A driver is an external or internal condition that motivates an organization to redefine its goals and implement the changes necessary to achieve them. Example: “Customer satisfaction”
An assessment is the result of an analysis of the current state of the company with respect to a driver and highlights any strengths, weaknesses, opportunities or risks, thus motivating a correction of the goals already identified or allowing new ones to be set. Example: “Complaining customers”
A goal represents a statement of intent or a desirable end state for an organization and its stakeholders. Example: “Reduce waiting times at the helpdesk”
An outcome is a high-level, business-oriented result produced by an organization. Example: “First place ranking achieved in a given customers portal”
Principles define properties that the software system should have. They are generic properties that apply to any software system within a given context and are motivated by goals or drivers. Example: “Systems should be customer facing.”
A requirement defines a property necessary to achieve a goal and/or realize one or more principles. In this sense, a requirement represents a “means” to realize a goal. Example: “Provide on-line information service”
A constraint, finally, is a factor that limits the realization of the goals. It can be a restriction on the implementation of the system (for example, a specific technology that must be used), or a restriction on the implementation process (for example, time or budget constraints). Example: “Must use MIT license”
The relationships between these so-called “motivation elements” can be diverse. Fig. 1 shows one possible form.
Analysis of involved resources, capabilities and value streams
The second step is to identify the resources, capabilities and value streams of the organization that may be directly or indirectly affected by the replacement of the software system in question.
A resource is an asset owned or controlled by an individual or an organization. Resources are divided into tangible (financial assets, physical assets) and intangible (human skills, reputation, etc.).
A capability is, in turn, an ability possessed by an individual, an organization or a system aimed at achieving a goal or delivering value by realizing an outcome.
At last, a value stream is intended as a sequence of activities that create a relevant, measurable, result for an internal or external customer.
Analysis of involved business processes
Finally, the third step is to categorize the business processes relevant to the value streams expressed by the software system you wish to replace.
A business process is a related set of activities that produce tangible added value from an initial request. The activities are carried out by actors with appropriate means. The business aspect of the process is expressed through the result, which must be relevant to an internal or external customer and, if possible, measurable.
Identification, qualification and modeling are the methodological tools that help to represent business processes and make them communicable.
The identification of a process can have different forms and degrees of complexity, starting from a simple list and laddering up to a graph representation. The system we propose is a halfway point and consists of describing the processes by compiling an analysis grid for each one. This is organized around common properties such as: finality, trigger event, input, output, key performance indicators (KPIs), governance, resources used, main actors, and collaborators.
The following table (fig. 2) supplies an example of an analysis grid for the business process: “order delivery”.
The qualification aims to summarize the qualitative aspects of a process, using indicators such as: duration, frequency, number of participants, complexity, etc.
The modeling, finally, uses graphical notations (fig. 3) in order to supply one detailed representation of the business processes. The BPMN is a standard for this area. (https://www.bpmn.org/)
Conclusions
The more relevant the software to be replaced, the more important it is to perform a proper analysis of how it is used within the organization. By analyzing the rationale for switching from one software solution to another, and properly understanding and documenting the resources, capabilities and business processes involved, it is possible to develop an optimal transformation strategy that minimizes costs and risks, helping to identify the most appropriate solutions.
Desfray, Philippe, and Gilbert Raymond. 2014. Modeling Enterprise Architecture with TOGAF. Burlington: Morgan Kaufmann
Magal, Simha, and Jeffrey Wird. 2011. Integrated Business Processes with ERP Systems. New York: Wiley.
