La adopción paralela es un método de transferencia entre un sistema ( TI ) anterior y un sistema (TI) de destino en una organización. Para reducir el riesgo, el sistema antiguo y el nuevo se ejecutan simultáneamente durante un período de tiempo, después del cual, si se cumplen los criterios para el nuevo sistema, el sistema antiguo se desactiva. El proceso requiere una planificación y un control cuidadosos y una inversión significativa en horas de trabajo.
Esta entrada se centra en el proceso genérico de adopción paralela; se utilizan ejemplos (del mundo real) para una interpretación más significativa del proceso, si es necesario. Además, se utiliza un modelo de datos de proceso para visualizar el proceso, que pretende proporcionar una visión general completa de todos los pasos implicados en la adopción paralela, pero se hará hincapié en las características únicas de la adopción paralela. En Adopción (implementación de software) se describen algunas características comunes, especialmente las que definen una estrategia de implementación, que se aplican a los cuatro tipos genéricos de adopción .
Además de la adopción paralela, se pueden identificar otros tres tipos genéricos de adopción. La elección de un método de adopción específico depende de las características de la organización; más adelante se proporcionará más información sobre este tema. Los otros tres métodos de adopción son:
Existen varios casos en los que la conversión paralela no puede considerarse una estrategia de conversión viable. En primer lugar, considere si el nuevo sistema contiene cambios de esquema significativos. Los elementos de datos requeridos por un sistema que no están siendo completados por el otro pueden conducir, en el mejor de los casos, a imprecisiones de datos y, en el peor, a corrupción de datos. Otra preocupación es si el sistema depende de tecnología comercial lista para usar (COTS). Si la documentación de un proveedor de COTS indica que más de una aplicación no puede compartir la misma base de datos, entonces la conversión paralela no es una opción. Un ejemplo serían los productos Siebel de Oracle. Otros productos COTS también pueden imponer restricciones cuando los parches o las actualizaciones importantes requieren claves de licencia únicas. Una vez aplicados, pueden realizar cambios en la base de datos que podrían hacer que la aplicación detecte erróneamente un sistema paralelo que se ejecuta contra la misma base de datos como un intento de eludir los controles de licencia y, por lo tanto, deshabilitar el sistema.
Parece haber pocas convenciones en relación con el proceso de adopción paralela. Varias fuentes (por ejemplo: Turban, 2002, Eason, 1988, Rooijmans, 2003, Brown, 1999), no utilizan un único nombre de descripción del proceso. El término adopción paralela se denota en estas fuentes, aunque consistente por fuente como: conversión paralela, ejecución paralela, ejecución paralela, corte paralelo e implementación paralela. Esto parece ser el caso porque una descripción genérica del proceso no necesita una clasificación distinta. Hay bastantes métodos de implementación estándar, donde se describen diferentes técnicas de adopción pero a menudo en un contexto práctico; escenario de caso del mundo real o un conjunto más completo de técnicas de implementación como Regatta: método de adopción, SIM y PRINCE2 . En general, la adopción paralela puede verse mejor como un método de ingeniería de sistemas de implementación de un nuevo sistema.
En principio, el método de adopción paralela es diferente de la decisión de cambiar un sistema en una organización y puede considerarse como un medio posible para lograr ese objetivo. Sin embargo, hay muchos factores que se tienen en cuenta para determinar la mejor estrategia de implementación . Además, una implementación exitosa puede depender en gran medida del método de adopción. (Lee, 2004)
El proceso de adopción paralela no se puede representar sin prestar atención a los pasos previos a la conversión real, es decir, la construcción de un escenario de conversión y la identificación y prueba de todos los requisitos . Por lo tanto, el proceso se explica repasando todos los procesos identificados en la figura 1, al tiempo que se abordan brevemente las actividades comunes que son necesarias para cualquiera de las estrategias de conversión identificadas.
La figura 1 ofrece una visión general del proceso de adopción en paralelo. El lado izquierdo muestra el flujo de actividades que contribuyen al proceso. Las actividades que se ejecutan simultáneamente están precedidas por una línea negra gruesa. Cuando finaliza la ejecución en paralelo de las actividades, las actividades se vuelven a unir en una línea negra similar. Cuando no hay una flecha que vaya de una actividad a otra, esto indica que son agregados de una actividad mayor anterior. Las actividades se dividen en cuatro fases principales:
Las fases principales se subdividen en otras actividades que se describirán brevemente en las tablas 1-1 a 1-4.
El lado derecho del modelo describe los datos involucrados en los procesos. Algunos de estos conceptos, representados como un par de rectángulos abiertos superpuestos, se pueden subdividir en más de un concepto. Un par de rectángulos cerrados superpuestos indican un concepto cerrado, lo que significa que se puede subdividir en más conceptos, pero no es de mayor interés para el proceso de adopción paralela. La figura con forma de diamante indica que el concepto vinculado a ella sirve como un concepto agregado y que este concepto consta de los otros conceptos. Finalmente, la flecha abierta representa una relación superclase-subclase. El concepto vinculado con la flecha es la superclase de los conceptos que están vinculados a ella. Esta sintaxis en la figura 1 es de acuerdo con los estándares del Lenguaje de Modelado Unificado ( UML ). Los conceptos en la figura 1 se definen en la tabla 2. Más contexto para estas subactividades en el proceso se dará debajo de las tablas.
Los conceptos de la figura 1 se definen en la tabla 2-1 a continuación.
La adopción paralela está precedida por la determinación de la estrategia de implementación, que no es exclusiva de la adopción paralela, pero puede considerarse como parte del proceso de gestión de cambios en el que se embarca una organización (Lee, 2004). Algunos factores que intervienen en la determinación de una estrategia de implementación en relación con los métodos de adopción se describen con más detalle en Adopción (implementación de software) .
La razón por la que una organización opta por la adopción paralela en lugar de una conversión piloto, una adopción masiva o una adopción por fases suele ser un equilibrio entre los costes y el riesgo (Andersson, Hanson, 2003). La adopción paralela es el método de adopción más caro (Chng, Vathanopas, 2002, Microsoft, 2004, Anderson et al., 2003), porque exige que la organización ejecute dos sistemas en paralelo durante un período determinado. Ejecutar dos sistemas simultáneamente significa que se debe realizar una inversión en Recursos Humanos . Además de una buena preparación del personal (extra) , este tiene que pasar por un período estresante de ejecución en paralelo donde los procedimientos se cruzan entre sí. (Rooijmans, 2003, Eason, 1988) Se deben realizar esfuerzos en la coherencia de los datos y en la prevención de la corrupción de datos entre los dos sistemas. (Chng et al. 2002, Yusuf, 2004) No solo para el proceso de conversión en sí, sino también en la formación de los mismos para manejar el nuevo sistema.
Cuando es necesario implementar un nuevo sistema siguiendo un enfoque de big bang, el riesgo de fracaso es alto (Lee, 2004). Cuando la organización exige mucho del sistema antiguo (heredado) que se cambie, la compensación entre los costos adicionales involucrados por un enfoque paralelo menos riesgoso, debe ser a favor de esos costos adicionales (Lee, 2004), a pesar de esto, vemos que la adopción de ERP sigue una adopción de big bang en la mayoría de los casos (Microsoft, 2004, Yusuf, 2004).
Esto significa que una organización debe pensar claramente sobre su estrategia de implementación e integrar esta decisión en su análisis de gestión de riesgos o gestión de cambios .
Para preparar la organización adecuadamente, es necesario un análisis de requisitos tanto de TI como de requisitos organizacionales. Puede encontrar más información sobre análisis de requisitos y gestión de cambios en otros lugares. Para la adopción paralela, el requisito de TI más importante (si corresponde) es la atención para ejecutar los dos sistemas simultáneamente. En la fase de conversión hay un intervalo de tiempo, donde el sistema antiguo es el sistema líder. Para transferir los datos del sistema antiguo en el período de recuperación al nuevo sistema, debe haber un módulo de transición disponible (Microsoft, 2004). Otros métodos de implementación no tienen este requisito directamente. Puede encontrar más información sobre los requisitos de TI en Ingeniería de software .
Además de los requisitos de TI, los requisitos organizacionales requieren cuestiones de gestión de recursos humanos como la capacitación del personal , el manejo de una estructura organizacional que puede cambiar , una organización orgánica o una organización mecanicista (Daft, 1998) y, lo más importante: el apoyo de la alta gerencia (Brown, Vessey, 1999). Brown et al. (1999) identifican dos roles distintos que la alta gerencia puede iniciar: los llamados roles de patrocinador y defensor:
Un proceso de adopción paralela es muy estresante y requiere de empleados bien preparados que puedan lidiar con los errores que se están cometiendo, sin volver a adoptar el viejo sistema de forma conservadora (Eason, 1988).
Es muy importante tener un plan detallado de cómo llevar a cabo el nuevo sistema en una organización (Lee, 2004, Eason, 1988). Lo más importante de la planificación del tiempo para una conversión paralela es no apresurarse y no tener miedo de posibles retrasos en la fase de conversión real (Lee, 2004). También puede ser muy beneficioso trabajar con hitos claramente definidos (Rooijmans, 2003), de forma similar al método PRINCE2 . Puede encontrar más información sobre la planificación del tiempo en Planificación y planificación estratégica .
La evaluación de los requisitos implica la redefinición del guión de implementación. Se deben probar los requisitos de TI y (si es posible) de la organización que se hayan establecido. Se pueden realizar algunas pruebas en las que se puedan evaluar las responsabilidades de la organización (Rooijmans, 2003) así como los requisitos de TI. En este caso también es importante contar con el apoyo y la participación de la alta dirección (Eason, 1988). Si no se ponen a disposición recursos para la evaluación, la implementación puede fracasar como consecuencia directa. Después de esta evaluación, el guión de implementación se redefine en un escenario de conversión más explícito.
El escenario de conversión es, por tanto, un modelo para el cambio organizacional en todos sus aspectos. Sin embargo, hay dos temas que aún no han recibido la atención que merecen en el ámbito de la adopción paralela.
La fase de conversión propiamente dicha ya está en marcha. Durante este proceso, la organización se encuentra en un período estresante (Eason, 1988, Rooijmans, 2003). Los dos sistemas funcionan en paralelo según el escenario de conversión y el nuevo sistema se supervisa de cerca. Cuando se cumplen los criterios del nuevo sistema, el antiguo dejará de ser el sistema principal y el nuevo asumirá el control. Las actualizaciones que forman parte de la estrategia de solución alternativa son las copias de seguridad del antiguo sistema y proporcionan los medios para la ingeniería de fiabilidad y la recuperación de datos . Hay dos tipos de formas de realizar actualizaciones: actualizaciones automáticas y actualizaciones manuales (Rooijmans, 2003). Si corresponde, también se puede implementar un servicio de copia de seguridad remota .
Existen varias lecciones que se pueden aprender de los estudios de casos: el caso del sistema DMV de Nevada, descrito por Lee (2004), muestra que la implementación de un nuevo proceso también puede tener implicaciones políticas. Cuando el sistema que se va a cambiar afecta al público en general y no se trata solo de un sistema interno, existen algunas presiones adicionales que influyen en la organización. En este caso, conceptos como la imagen y la reputación de la empresa pueden cambiar drásticamente si los clientes se enfrentan a más demoras, por ejemplo, en la comunicación o en el pedido de productos. Se sugiere que si el sistema es políticamente sensible, se debe prestar más atención al método de conversión y, preferiblemente, se opta por la adopción paralela, ya que implica menos riesgos.
Una serie de lecciones aprendidas de varios escenarios de casos reales de implementación de un nuevo sistema de cartera, realizados por una empresa de consultoría empresarial (Venture, 2004), muestran algunas lecciones interesantes aprendidas en el campo. Parecen encajar perfectamente con los problemas mencionados para un proceso de adopción paralela genérico, basado en una combinación de trabajo científico. Para resumir:
Existen también al menos dos dificultades con la conversión paralela que pueden hacer que su uso sea poco práctico en el siglo XXI, aunque era un elemento básico de la práctica industrial cuando las entradas consistían en mazos de tarjetas perforadas o carretes de cinta. Son las siguientes:
1. No es práctico esperar que los usuarios finales, ya sean clientes, trabajadores de la línea de producción o casi cualquier otra persona, ingresen cada transacción dos veces a través de interfaces diferentes.
2. Las diferencias de tiempo entre dos sistemas interactivos multiusuario pueden producir resultados diferentes incluso cuando ambos sistemas funcionan correctamente, son internamente consistentes y podrían usarse con éxito por sí solos.
Como resultado, la conversión paralela se limita actualmente a unas pocas situaciones específicas, como los sistemas contables en los que es obligatoria la verificabilidad absoluta de los resultados, en los que todos los usuarios son internos de la organización y comprenden este requisito, y en los que no se puede permitir que el orden de las actividades afecte a los resultados. En la práctica, los métodos de conversión piloto y por fases son hoy más pertinentes.