Parallel deployment is the method to transfer between the previous system (IT) to the target system (IT) within an organization. To reduce risk, old and new systems run simultaneously for some time after that, if the criteria for the new system are met, the old system is disabled. This process requires careful planning and control and significant investment in working hours.
Video Parallel adoption
Overview
This entry focuses on the generic process of parallel adoption; An example (real world) is used for a more meaningful interpretation of the process if necessary. In addition the data-processing model is used to visualize the process intended to provide a complete picture of all the steps involved in parallel adoption, but the emphasis will be placed on the unique characteristics of parallel adoption. Some common characteristics, especially defining an implementation strategy, are applicable to the four generic adoption types described in Adoption (software implementation).
Maps Parallel adoption
Other adoption types
In addition to parallel adoption, three other generic adoption types can be identified. The choice for a particular adoption method depends on the characteristics of the organization; more insights on this topic will be given below. Three other adoption methods are: Adoption Product Software: Big Bang Adoption (Also known as Direct Conversion, slam dunk, or cold turkey strategy), Gradual adoption and Pilot adoption.
- Product Adoption Adoption: Big Bang Adoption/Plunge Adoption: Big-bang adoption requires the transfer of entire organizations from the old system to the new system in an instant switch. This is the cheapest option but if the new System fails, the organization is in big trouble. It also opens the risk for the system not to be accepted by its users. However, this may be the only approach that should be taken when the two systems can not coexist or activate the new system is an emergency.
- Staged implementation (Also known as phased conversion): In the implementation of phased implementation, organizations gradually transfer to new systems in different phases, per module or sub-system. Some systems can not be introduced in chunks because they are too dependent on the whole system. The use of gradual adoption has a smaller risk, but it causes the biggest disruption because it takes the longest time to transfer from the old system to the new one.
- Pilot adoption: Pilot adoption methods are used for large organizations with multiple locations or most independent departments. The new system is introduced in one of the locations or departments and extended to other locations or departments from time to time. (limited limits if the new system fails) (Turban, 2002)
There are some examples where parallel conversions can not be considered as viable conversion strategies. First consider whether the new system contains significant schema changes. The data elements required by one system that are not filled by another can cause the best data inaccuracies and at the worst damaged data. Another concern is if the system relies on the consumer of the shelf technology (COTS). If the COTS vendor documentation states that more than one application can not share the same database, then parallel conversion is not an option. An example is the Siebel Oracle product. Other COTS products may also place restrictions when large patches or upgrades require a unique license key. Once implemented, they can make database changes that may cause the app to mis-detect parallel systems running against the same database in an attempt to gain license control and thus disable the system.
Place in the implementation process
There seems to be little convention about the parallel adoption process. Some sources (eg 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 operation, walking shadow, parallel cutting and parallel implementation. This seems to be the case because the generic description of the process does not require a different classification. There are several standard implementation methods, where different adoption techniques are described but often in a practical context; Real-world case scenarios or a more comprehensive set of implementation techniques such as Regatta: adoption methods, SIM and PRINCE2. In general, parallel adoption can be seen as a method of System Engineering implementation of a new system.
In principle, the method of parallel adoption differs from the decision to change a system within an organization and can be seen as a possible possibility to achieve that goal. However, there are several factors that are taken into account in determining the best implementation strategy. In addition, successful implementation can be highly dependent on adoption methods. (Lee, 2004)
The process is
The process of parallel adoption can not be represented without regard to the steps before the actual conversion, namely the construction of conversion scenarios and the identification and testing of all requirements. The process is therefore explained through all the processes identified in Figure 1, while addressing the general activities required for one of the briefly identified conversion strategies.
Figure 1 provides an overview of the parallel adoption process. The left side describes the flow of activity that contributes to the process. The activity that runs simultaneously is preceded by a thick black line. As the parallel activity proceeds, the activities are reassembled in a similar black line. When there is no arrow from activity to other activity, it indicates that they are the aggregate of the larger activity above. Activities are divided into four main phases:
- Determine the implementation strategy , which relates to the type of implementation strategy to run.
- Pre-deployment , which is concerned with planning all aspects and requirements involved in implementation.
- Prepare organization The organization must be set up correctly in accordance with the previous phase.
- Conversions deals with the actual conversion process and closes the conversion process; continue with the new system.
The main phase is subdivided into other activities which will be briefly described in tables 1-1 to 1-4.
The right side of the model describes the data involved in the process. Some of these concepts, described as a pair of overlapping open square, can be divided into more than one concept. A pair of enclosed overlapping rectangles show a closed concept which means it can be subdivided in more concepts, but no more appealing to parallel adoption processes. The shape of a diamond figure shows that the concept associated with it, serves as an aggregate concept and these concepts are composed of other concepts. Finally the open arrow shows a super subclass class relationship. The concept associated with arrows is a super class of concepts associated with it. This syntax in figure 1 conforms to the Unified Modeling Language (UML) standard. The concept in Figure 1 is defined in table 2. Further context for this sub activity in the process will be given under the table.
The concepts of Figure 1 are defined in Table 2-1 below.
Define parallel implementation strategy
Parallel application is preceded by defining an implementation strategy, which is not unique to parallel adoption, but can be seen as part of the change management process incorporated by the organization. (Lee, 2004). Several factors involved in defining implementation strategies regarding adoption methods are described more closely in Adoption (software implementation).
Risk versus cost
The reason for organizations to choose parallel adoption that supports pilot conversion, big bang or gradual adoption is often a trade-off between cost and risk (Andersson, Hanson, 2003). Parallel adoption of the most expensive adoption method (Chng, Vathanopas, 2002, Microsoft, 2004, Anderson et al., 2003), because it demands from the organization that two systems run parallel for a certain period of time. Running two systems simultaneously means that investment in Human Resources should be done. In addition to good preparation of personnel (extra), which must go through a tense period of parallel running where the procedure is crossed. (Rooijmans, 2003, Eason, 1988) Efforts should be placed on data consistency and prevent data corruption between the two systems. (Chng et al. 2002, Yusuf, 2004) Not only for the conversion process itself, but also in training them to handle the new system.
When needed for the new system to be implemented after the big bang approach, the risk of failure is high (Lee, 2004). When the organization strongly demands a long (inherited) system to be changed, the exchange between the additional costs involved for a less risky parallel approach should benefit the additional cost (Lee, 2004); nevertheless, we see that ERP adoption follows a big bang adoption in many case (Microsoft, 2004, Yusuf, 2004).
This means that organizations should think clearly about their implementation strategy and integrate this decision in Risk management or Change management analysis.
Develop an implementation script
IT-Requirements
To prepare the organization with both requirements analysis of both IT requirements as well as organizational requirements is required. More information on requirements analysis and change management can be found elsewhere. For parallel adoption, the most important IT requirement (if any) is the concern to run two systems simultaneously. In the conversion phase there is a timeslot, where the old system is the leading system. To transfer data from the old system in the catch-up period to the new system, there must be an available transition module (Microsoft, 2004). Other implementation methods do not directly have this requirement. More information about IT requirements can be found in Software Engineering.
Organizational requirements
In addition to IT-requirements, organizational requirements require issues of Human Resource Management such as, training of personnel, dealing with changing organizational structures, organic organization or organizational characteristics Organizational mechanics (Daft, 1998) and most importantly: Top management support (Brown, Vessey , 1999). Brown et al. (1999) identifies two key roles that can be initiated by superiors: so-called sponsors and champions:
- "The project sponsor is responsible for budget support and ensures that key business representatives play a role in the project team."
- "The project champion may or may not be a formal member of the project team, but may play a key role in change management efforts"
The process of parallel adoption is very stressful and requires well-prepared employees who can deal with errors that are being made, without being conservatively passionate about the old system. (Eason, 1988)
Planning time
It is important to have a detailed plan for implementing a new system within an organization (Lee, 2004, Eason, 1988). The most important thing about planning time for parallel conversions is not in a hurry and not afraid of possible delays in the actual conversion phase. (Lee, 2004). It can be very useful also to work with clearly defined milestones (Rooijmans, 2003), similar to the PRINCE2 method. More information on time planning can be found in Strategic Planning and Planning.
Preparing the organization
Needs evaluation
The requirements evaluation involves redefining the implementation script. The IT requirements and (if possible) of the created organization must be tested. Some tests can be run where organizational responsibilities can be evaluated (Rooijmans, 2003) as well as IT requirements. It is also important to have the support and involvement of top management (Eason, 1988). If they do not provide resources to evaluate, their implementation may fail as a direct consequence. After this evaluation, the implementation script is redefined to a more explicit conversion scenario.
Conversion scenario
The conversion scenario thus consists of a blueprint for organizational change in all aspects. However, there are two topics that have not received proper attention within the scope of parallel adoption.
- Resolution strategy/Backlinks: Being different from other implementation scenarios, also integrated in conversion scenarios is a contingency solution or strategy with a rollback plan. Problem-solving strategies are defined within a wider scope in other entries, but in this context it shows as defined in the above table: A backup plan; strategies taken, in a conversion scenario to prevent errors in the conversion process and strive to work around them, so that the implementation can still succeed. (Microsoft, 2004). The rollback plan, as one possible solution strategy, begins when something goes wrong in the conversion phase. Since both systems run simultaneously, in parallel adoption, the rollback plan indicates that other databases or systems that handle transactions must be entirely traceable in legacy systems (Microsoft, 2004). Even parallel adoption provides per definition of this rollback plan due to the nature of leading systems and backup systems (non-reputable).
- Criteria Indicators: Since conversion scenarios are blueprints for transfer of both systems, they also contain quantitative criteria. The redefined IT and organizational requirements are being transferred to measurable components. When the criteria are not met in experiment conversion, the solution strategy must be applied.
Conversions
The actual conversion phase now exists. During this process, the organization is in a tense period (Eason, 1988, Rooijmans, 2003). Both systems run parallel to the conversion scenario and the new system is being closely monitored. When the new system criteria are met, the old system will cease to be the primary system and the new system takes over. The catch up that is part of the solution strategy is the back up of the old system and provides the means for reliability engineering and data recovery. There are two ways to catch up: catch up and catch automatically by hand. (Rooijmans, 2003). If applicable, the remote backup service may also be used.
System control
- Automatic retrieval: Searches that are transferred by an automated system, created in preparing an organizational phase. The system automatically transfers data or information to the new system when the conversion goes from the old system to the new system. The benefits of an automated system are fast and accurate. The disadvantage is it takes time to produce the transfer system at an early stage.
- Retrieving by hand: When actual conversions take little time, or the complexity of the information to be transferred to a new system is small, organizations may choose to transfer catch up manually. The advantage of this procedure is not the need for a system (software program) to transfer information and possible problems that come with some sort of transfer program. The trade-off is the accuracy and timing. It takes a lot of extra time, to transfer the catch manually and more vulnerable to small human errors (Rooijmans, 2003). Moreover, additional investment in working hours is high; manual systems pursue the place even more pressure on personnel.
Practical Evaluation/Relevance
There are several lessons to be learned from the case study: The Nevada DMV system case, described by Lee (2004), learns that implementation to a new process can also have political implications. When the system to be changed affects the general public and not only the internal system being changed, there are some pressures that affect the organization. In this case, concepts as corporate image and reputation can change drastically if customers are faced with more delay in terms of communication or ordering of goods. It is suggested that if the system is politically sensitive, more attention should be paid to the conversion method and preferably parallel adoption is selected, as there is less risk involved.
A series of lessons from a number of actual scenarios that employ a new portfolio system, conducted by a business consulting firm (Venture, 2004) show some interesting lessons learned from the field. they seem to fit perfectly with the issues mentioned for the generic parallel adoption process, based on a combination of scientific work. To summarize:
- Planning a risk and contingency assessment (settlement) is very important
- Set the project team role
- Create specific milestones (like PRINCE2) that include training and test plans
- Identify potential risks and run your emergency plan if necessary
- Communicate project status
- Changes must be authorized accordingly
- The conversion strategy needs to carefully check the data requirements
- New and modified data must be tested against the validation rule
- Create a comprehensive rollback plan
- If possible, negotiate pilot conversions
There are at least two difficulties with parallel conversions that may make its use impractical in the 21st century, although that is the point of industrial practice when the input consists of a pile of cards or rolls of ribbons. This is:
1. It is impractical to expect an end user, be it a customer, a production line worker or nearly anyone else, to enter each transaction twice through a different interface.
2. The time difference between two multi-user interactive systems can correctly produce different results even when both systems operate correctly, internally consistent, and can be used successfully by themselves.
Consequently, parallel conversions are limited to certain current situations, such as accounting systems where absolute credibility of outcomes is mandatory, where users are all internal to the organization and understand these requirements, and where sequence of activities can not be allowed to influence output. In practice, experimental and gradual conversion methods are more relevant today.
See also
- Product Adoption: Big Bang Adoption
- Gradual implementation
- Adoption (software implementation)
- Regatta: adoption method
- Change management
- Reliability engineering
- Rollback (data management)
- Risk management
- Software Engineering
- Deployment
References
Articles
- Andersson I. Hanson, K. (2003). Diffusion of technology in the software organization, Thesis License in Applied Information Technology , University of Goteborg
- Brown, C.V. & amp; Vessey, I. (1999). ERP Implementation Approach: Towards a Contingency Framework, Proceedings of the 20th International Conference on Information Systems , Charlotte, NC, December 13-15, 411-416.
- Chng, S., & amp; Vathanophas V. (2002). Toward an Inter-Organizational Enterprise System: Focus Group Studies. 6th Asia Pacific Conference on Information Systems (PACIS 2002). Tokyo, Japan. September 2-4, 2002.
- Lee, O. (2004). Case Study Nevada DMV System, Journal of Business and Economy Academy , Volume 3
- Ribbers, P & amp; Schoo, K.C. (2002). Designing a Complex Software Implementation Program, the 35th International Hawaiian Annual Conference on System Science (HICSS'02) , Volume 8
- Joseph, Y & amp; Gunasekaran, A. & amp; Abthorpe M.S. (2004). Implementation of enterprise system project: ERP case study at Rolls Royce. International Journal of Production Economics , 87, 251-266.
Books
- Daft, R.L. (1998). Organizational theory and design. West: Thomson International
- Eason, K. (1988). "Chapter 9, Implementation and Support," at: Information Technology and Organizational Change. London: Taylor & amp; Francis
- Turban, E & amp; Mclean, E. & amp; Wetherbe J. (2002) "Chapter 14, Building information systems", in: Information Technology for management. New York: John Wiley & amp; Boy, inc
- Rooimans, R., Theye, M. de, & amp; Koop, R. (2003). Regatta: ICT-implementatie and voor een vier-met-stuurman. The Hague: Ten Hagen en Stam Uitgevers.
External links
- Repeats the Business Applications Path from UNIX to Windows. (2004), version 1.0 Microsoft , Retrieved 5 March 2006 [1]
- Implementing a portfolio accounting system: Lessons from the trenches (2004), Venture Financial Systems Group Ltd , Retrieved 6 March 2006 [2]
Source of the article : Wikipedia
0 Comments