Parallel adoption is a method for transferring between a previous (IT) system to a target (IT) system in an organization. In order to reduce risk, the old and new system run simultaneously for some period of time after which, if the criteria for the new system are met, the old system is disabled. The process requires careful planning and control and a significant investment in labor hours.
Overview This entry focuses on the generic process of parallel adoption. Real-world examples are used to provide a more meaningful interpretation of the process if necessary. Additionally, a process-data model is utilized to visualize the process, aiming to offer a comprehensive overview of all the steps involved in parallel adoption. However, the emphasis will be on the unique characteristics of parallel adoption. Some common characteristics, particularly those related to defining an implementation strategy, that apply to all four generic types of adoption are described in Adoption (software implementation).
Other kinds of adoption Besides parallel adoption, three other generic kinds of adoption can be identified. The choice for a specific adoption method depends on the organizational characteristics; more insight on this topic will be provided below. The three other adoption methods are:
Big bang adoption/Plunge Adoption: A big-bang adoption entails transferring the entire organization from the old system to the new system in an instant changeover. This is the cheapest option but if the new System fails, the organization is in big trouble. It also opens risks for the system not to be accepted by its users. However, this may be the only approach to take when the two systems can not coexist or activating the new system is an emergency. Phased adoption (also known as gradual conversion): In phased adoption implementation, the organization is gradually transferring to a new system in different phases, per module or sub-system. Some systems are incapable of being introduced in pieces as it is too reliant on the whole system. Using phased adoption has fewer risks, but causes the most disruptions due to it taking the most time to transfer from the old system to the new. Pilot adoption: The pilot adoption method is used for large organizations that have multiple locations or largely independent departments. The new system is introduced in one of the locations or departments and extended to other locations or departments over time. (limited boundary if a new system is a failure) (Turban, 2002) In some cases, parallel conversion may not be a suitable strategy. For example, if the new system has significant schema changes that result in data elements not being populated correctly, it can lead to data inaccuracies or corruption. Additionally, if the system relies on commercial off-the-shelf (COTS) technology and the vendor's documentation specifies that multiple applications cannot share the same database, parallel conversion may not be feasible. For instance, products like Oracle's Siebel may have such restrictions. Similarly, other COTS products may have limitations when it comes to patches or major upgrades that require unique license keys, potentially causing issues with database changes and system functionality.
Place in implementation process There seem to be little conventions regarding the process of parallel adoption. Several sources (e.g.: Turban, 2002, Eason, 1988, Rooijmans, 2003, Brown, 1999), do not use a single process-description name. The term parallel adoption is denoted in these sources, although consistent per source as: parallel conversion, parallel running, shadow-running, parallel cutover and parallel implementation. This appears to be the case because a generic description of the process does not need a distinct classification. There are quite a few standard implementation methods, where different adoption techniques are described but often in a practical context; real-world case scenario or a more comprehensive set of implementation techniques like Regatta: adoption method, SIM and PRINCE2. In general, parallel adoption can best be seen as a systems engineering method of implementation of a new system. In principle, the parallel adoption method is different from the decision to change a system in an organization and can be seen as one possible mean to achieve that goal. However, there are quite some factors that are being taken into account in determining the best implementation strategy. Moreover, a successful implementation can depend to a big extent on the adoption method. (Lee, 2004)
The process The parallel adoption process can not be represented without paying attention to the steps before the actual conversion, namely the construction of a conversion scenario and the identification and testing of all the requirements. Therefore the process is explained by going through all the identified processes in figure 1, while addressing the common activities that are necessary for any of the identified conversion strategies briefly. Figure 1 gives an overview of the parallel adoption process. The left side depicts the flow of activities that contribute to the process. Activities that run simultaneously are preceded by a thick black line. When the parallel running of activities is over, the activities are joined again in a similar black line. When there is no arrow from an activity to another, this indicates that they are aggregates of a bigger activity above. The activities are divided in four main phases:
… excerpt ends here. Continue reading the full article.
