Adopción paralela

La adopción paralela es un método para transferir de un sistema (TI) anterior a un sistema (TI) de destino en una organización. Para reducir el riesgo, el sistema antiguo y el nuevo funcionan 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:

• Big Bang adopción/Plunge Adopción: Una adopción grande implica transferir a toda la organización del viejo sistema al nuevo sistema en un cambio instantáneo. Esta es la opción más barata pero si el nuevo sistema falla, la organización está en grandes problemas. También abre riesgos para que el sistema no sea aceptado por sus usuarios. Sin embargo, este puede ser el único enfoque a tomar cuando los dos sistemas no pueden coexistir o activar el nuevo sistema es una emergencia.
• Adopción gradual (también conocida como conversión gradual): En la aplicación gradual de la adopción, la organización está transfiriendo gradualmente a un nuevo sistema en diferentes fases, por módulo o subsistema. Algunos sistemas son incapaces de ser introducidos en piezas ya que es demasiado dependiente en todo el sistema. El uso de la adopción gradual tiene menos riesgos, pero causa las mayores perturbaciones debido a que toma el mayor tiempo para transferir del antiguo sistema al nuevo.
• Adopción piloto: El método piloto de adopción se utiliza para las grandes organizaciones que tienen múltiples ubicaciones o departamentos en gran medida independientes. El nuevo sistema se introduce en uno de los lugares o departamentos y se extiende a otros lugares o departamentos con el tiempo. (limitado límite si un nuevo sistema es un fracaso) (Turban, 2002)

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 que existen 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 para la descripción del proceso. El término adopción paralela se denota en estas fuentes, aunque es consistente en cada fuente como: conversión paralela, ejecución paralela, ejecución en paralelo, transición paralela e implementación paralela. Esto parece ser así porque una descripción genérica del proceso no necesita una clasificación distinta. Hay bastantes métodos de implementación estándar, en los que 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 se puede considerar mejor como un método de ingeniería de sistemas para la 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 más grande anterior. Las actividades se dividen en cuatro fases principales:

• Definir la estrategia de aplicación, que se ocupa del tipo de estrategia de aplicación debe ejecutarse.
• Ejecución previa, que tiene que ver con la construcción de una planificación de todos los aspectos y requisitos relacionados con la aplicación.
• Organización preparada La organización debe prepararse adecuadamente de acuerdo con la fase anterior.
• Conversión se ocupa del proceso de conversión real y de cerrar el proceso de conversión; proceder con el nuevo sistema.

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, pueden subdividirse en más de un concepto. Un par de rectángulos cerrados superpuestos indican un concepto cerrado, lo que significa que puede subdividirse 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 está 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 una 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 los riesgos (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. La ejecución simultánea de dos sistemas implica una inversión en recursos humanos. Además de una buena preparación del personal (adicional), este tiene que atravesar un período estresante de ejecución en paralelo en el que los procedimientos se cruzan (Rooijmans, 2003, Eason, 1988). Se deben realizar esfuerzos para garantizar la coherencia de los datos y evitar la corrupción de los mismos entre los dos sistemas (Chng et al. 2002, Yusuf, 2004). No sólo para el proceso de conversión en sí, sino también para capacitarlos 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 debería 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 los requisitos, tanto de TI como de la organización. Puede encontrar más información sobre el análisis de requisitos y la gestión de cambios en otros lugares. Para la adopción en paralelo, el requisito de TI más importante (si corresponde) es la atención a la ejecución simultánea de los dos sistemas. En la fase de conversión hay un intervalo de tiempo en el que el sistema antiguo es el sistema principal. 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 dirección (Brown, Vessey, 1999). Brown et al. (1999) identifican dos roles distintos que la alta dirección puede iniciar: los llamados roles de patrocinador y defensor:

• “Un patrocinador de proyectos es responsable del apoyo presupuestario y de garantizar que los principales representantes empresariales desempeñen un papel en el equipo del proyecto. ”
• “El campeón del proyecto puede o no ser miembro formal del equipo del proyecto, pero puede desempeñar un papel clave en los esfuerzos de gestión del cambio”

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 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 establecieron. 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. Aquí 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 consiste, por tanto, en un plan para el cambio organizacional en todos los 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.

• Estrategia de trabajo / Plan Rollback: Siendo distintos de los otros escenarios de adopción, también integrados en el escenario de conversión es la estrategia de trabajo o contingencia con un plan de retroceso. La estrategia integral de trabajo se define en un ámbito más amplio en otra entrada, pero en este contexto indica que se define en el cuadro anterior: Un plan de respaldo; estrategia adoptada, en el escenario de conversión para evitar errores en el proceso de conversión e intentar trabajar en torno a ellos, para que la implementación pueda tener éxito. (Microsoft, 2004). El plan de devolución, como una posible estrategia de solución de trabajo, se inicia si algo sale mal en la fase de conversión. Dado que los dos sistemas funcionan simultáneamente, en una adopción paralela, el plan de devolución indica que la base de datos u otro sistema que maneja las transacciones debe ser totalmente retraceable en el sistema anterior (Microsoft, 2004). De hecho, la adopción paralela proporciona por definición este plan de devolución debido a su naturaleza de un sistema líder y un sistema de respaldo (no líder).
• Indicadores de criterios: Dado que el escenario de conversión es un plan de ejecución de la transferencia de los dos sistemas, también implica criterios cuantificables. Las necesidades de TI y de organización redefinidas se están transfiriendo a componentes mensurables. Cuando los criterios no se cumplen en la conversión de los ensayos, se debe implementar la estrategia de solución de trabajo.

La fase de conversión propiamente dicha ya está en marcha. Durante este proceso, la organización se encuentra en un período de estrés (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 cumplan 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.

• Atrapaciones automáticas: Capturas que están siendo transferidas por un sistema automatizado, creado en la fase de preparación de la organización. Este sistema transfiere automáticamente los datos o la información al nuevo sistema cuando la conversión va del antiguo sistema líder al nuevo sistema líder. El beneficio de un sistema automatizado es que es rápido y preciso. La desventaja es que lleva tiempo producir un sistema de transferencia en una etapa anterior.
• Atrapa a mano: Cuando la conversión real implica sólo una pequeña cantidad de tiempo, o la complejidad de la información que debe transferirse al nuevo sistema es pequeña, una organización puede optar por transferir las capturas manualmente. La ventaja de este procedimiento es que no hay necesidad de un sistema (programa de software) para transferir la información y los posibles problemas que vienen con tal tipo de programa de transferencia. El intercambio es la precisión y el tiempo. Se necesita una cantidad considerable de tiempo extra, para transferir la captura manualmente y es más vulnerable para los pequeños errores humanos (Rooijmans, 2003). Además, la inversión adicional en horas de trabajo ya es elevada; un sistema de captación manual coloca aún más presión sobre el personal.

Hay 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 una implicación política. Cuando el sistema que se va a cambiar afecta al público en general y no se trata solo de un sistema interno que se está modificando, hay 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 hay menos riesgos involucrados.

Una serie de lecciones aprendidas de una serie de 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:

• La evaluación del riesgo y la planificación para imprevistos es muy importante
• Funciones del equipo del proyecto
• Construir hitos específicos (como PRINCE2) que incluyen planes de entrenamiento y pruebas
• Identificar riesgos potenciales y ejecutar su plan de contingencia cuando sea necesario
• Communicate project status
• Los cambios deben estar debidamente autorizados
• La estrategia de conversión debe examinar cuidadosamente los requisitos de datos
• Los datos nuevos y modificados deben ser probados contra las normas de validación
• Construir un plan completo de devolución
• Cuando sea posible, negociar una conversión piloto

La conversión paralela también presenta al menos dos dificultades que pueden hacer que su uso sea poco práctico en el siglo XXI, aunque era una práctica habitual en la industria cuando las entradas consistían en mazos de tarjetas perforadas o carretes de cinta. Son las siguientes:

1. No resulta práctico esperar que los usuarios finales, ya sean clientes, trabajadores de la línea de producción o prácticamente cualquier otra persona, realicen cada transacción dos veces a través de diferentes interfaces.

2. Las diferencias de tiempo entre dos sistemas interactivos multiusuario pueden producir resultados diferentes incluso cuando ambos sistemas funcionan correctamente, son consistentes internamente y podrían usarse con éxito por sí solos.

En consecuencia, 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.

• Software de producto adopción: Big Bang adopción
• Adopción gradual
• Adopción (ejecución del software)
• Regatta: método de adopción
• Gestión del cambio
• Ingeniería de responsabilidad
• Rollback (gestión de datos)
• Gestión de riesgos
• Ingeniería de software
• Aplicación

• Andersson I. Hanson, K. (2003). Difusión tecnológica en una organización de software, Licentiate Thesis in applied Information Technology, Universidad de Goteborg
• Brown, C.V. " Vessey, I. (1999). ERP Implementation Approaches: Hacia un Marco de Contingencia, Proceedings of the 20th International Conference on Information Systems, Charlotte, NC, 13-15 de diciembre, 411-416.
• Chng, S., " Vathanophas V. (2002). Hacia un sistema empresarial interorganizador: un estudio de grupo focal. La 6a Conferencia de Asia del Pacífico sobre Sistemas de Información (PACIS 2002). Tokio, Japón. 2 a 4 de septiembre de 2002.
• Lee, O. (2004). Un estudio de caso del sistema DMV de Nevada, Journal of the Academy of Business and Economics, Volumen 3
• Ribbers, P. & Schoo, K.C. (2002). Diseño de programas complejos de implementación de software, 35a Conferencia Internacional Hawai sobre Ciencias del Sistema (HICSS'02), Volumen 8
• Yusuf, Y. " Gunasekaran, A. " Abthorpe M.S. (2004). Ejecución de proyectos de sistemas institucionales: Estudio de caso del ERP en Rolls-Royce. International Journal of Production Economics87, 251-266.

• Daft, R.L. (1998). Teoría y diseño organizativos. West: International Thomson
• Eason, K. (1988). "Capítulo 9, Implementación y Apoyo", en: Tecnología de la información y cambio organizacional. Londres: Taylor & Francis
• Turban, E. " Mclean, E. " Wetherbe J. (2002) " Cap. 14, Building information systems " , en: Tecnología de la información para la gestión. Nueva York: John Wiley & Sons, inc
• Rooimans, R. Theye, M. de, " Koop, R. (2003). Regatta: ICT-implementaties als uitdaging voor een vier-met-stuurman. La Haya: Diez Hagen en Stam Uitgevers.

• Replatforming Line of business Applications from UNIX to Windows. (2004), versión 1.0 Microsoft, Consultado el 5 de marzo de 2006 [1]
• Implementing a portfolio accounting system: Lecciones de las trincheras (2004), Venture Financial Systems Group Ltd, Consultado el 6 de marzo de 2006 [2]