Adopción paralela

La adopción paralela es un método para transferir información entre un sistema informático anterior y uno nuevo dentro de una organización. Para reducir riesgos, ambos sistemas funcionan simultáneamente durante un tiempo determinado. Si se cumplen los requisitos del nuevo sistema, el anterior se desactiva. Este proceso requiere una planificación y un control rigurosos, así como una inversión considerable en horas de trabajo.

Esta entrada se centra en el proceso genérico de adopción paralela. Se utilizan ejemplos reales para proporcionar una interpretación más significativa del proceso, si es necesario. Además, se emplea un modelo de datos de proceso para visualizarlo, con el objetivo de ofrecer una visión general completa de todos los pasos involucrados en la adopción paralela. Sin embargo, el énfasis estará en las características únicas de la adopción paralela. Algunas características comunes, en particular las relacionadas con la definición de una estrategia de implementación, que se aplican a los cuatro tipos genéricos de adopción, se describen en Adopción (implementación de software) .

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; a continuación se ofrecerá más información sobre este tema. Los otros tres métodos de adopción son:

• Adopción integral /Adopción radical: Una adopción integral implica la transferencia de toda la organización del sistema antiguo al nuevo de forma instantánea. Esta es la opción más económica, pero si el nuevo sistema falla, la organización se enfrenta a graves problemas. Además, conlleva el riesgo de que el sistema no sea aceptado por sus usuarios. Sin embargo, puede ser la única opción viable cuando los dos sistemas no pueden coexistir o cuando la activación del nuevo sistema es urgente.
• Adopción por fases (también conocida como conversión gradual): En la implementación de la adopción por fases, la organización migra gradualmente a un nuevo sistema en distintas etapas, módulo por módulo o subsistema. Algunos sistemas no pueden implementarse por partes, ya que dependen demasiado del sistema completo. Si bien la adopción por fases conlleva menos riesgos, también genera mayores interrupciones debido al tiempo que requiere la transición del sistema antiguo al nuevo.
• Adopción piloto: El método de adopción piloto se utiliza en grandes organizaciones con múltiples ubicaciones o departamentos en gran medida independientes. El nuevo sistema se introduce en una de las ubicaciones o departamentos y se extiende gradualmente a las demás. (Límite limitado en caso de que el nuevo sistema falle) (Turban, 2002)

En algunos casos, la conversión paralela puede no ser una estrategia adecuada. Por ejemplo, si el nuevo sistema presenta cambios significativos en el esquema que impiden que los elementos de datos se completen correctamente, esto puede provocar imprecisiones o corrupción de datos. Además, si el sistema se basa en tecnología comercial estándar (COTS) y la documentación del proveedor especifica que varias aplicaciones no pueden compartir la misma base de datos, la conversión paralela podría no ser factible. Por ejemplo, productos como Siebel de Oracle pueden tener tales restricciones. Del mismo modo, otros productos COTS pueden tener limitaciones en lo que respecta a parches o actualizaciones importantes que requieren claves de licencia únicas, lo que podría causar problemas con los cambios en la base de datos y la funcionalidad del sistema.

Parece haber pocas convenciones respecto al proceso de adopción paralela. Varias fuentes (por ejemplo, Turban, 2002; Eason, 1988; Rooijmans, 2003; Brown, 1999) no utilizan un único nombre para describir el proceso. El término " adopción paralela" se utiliza en estas fuentes, aunque de forma consistente, como conversión paralela, ejecución paralela, ejecución en segundo plano, transición paralela e implementación paralela. Esto parece deberse a que una descripción genérica del proceso no requiere una clasificación específica. Existen varios métodos de implementación estándar, donde se describen diferentes técnicas de adopción, a menudo en un contexto práctico: un caso 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 considerarse 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 difiere de la decisión de cambiar un sistema en una organización y puede considerarse una posible vía para lograr ese objetivo. Sin embargo, existen varios factores que se tienen en cuenta para determinar la mejor estrategia de implementación . Además, el éxito de la implementación puede depender en gran medida del método de adopción. (Lee, 2004)

El proceso de adopción paralela no puede representarse sin prestar atención a los pasos previos a la conversión propiamente dicha, a saber, la construcción de un escenario de conversión y la identificación y comprobación de todos los requisitos . Por lo tanto, el proceso se explica repasando todos los pasos identificados en la figura 1, abordando brevemente las actividades comunes necesarias para cualquiera de las estrategias de conversión identificadas.

La Figura 1 ofrece una visión general del proceso de adopción paralela. 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 paralela de las actividades, estas se unen nuevamente mediante una línea negra similar. Cuando no hay una flecha que conecte una actividad con otra, esto indica que son agregados de una actividad mayor superior. Las actividades se dividen en cuatro fases principales:

• Definir la estrategia de implementación , que trata sobre el tipo de estrategia de implementación que se debe ejecutar.
• La fase previa a la implementación consiste en elaborar un plan que abarque todos los aspectos y requisitos relacionados con la implementación.
• Preparar la organización La organización debe prepararse adecuadamente de acuerdo con la fase anterior.
• La conversión abarca tanto el proceso de conversión propiamente dicho como la finalización del proceso de conversión, pasando por la implementación del 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 relevante para el proceso de adopción paralela. La figura en forma de diamante indica que el concepto vinculado a ella actúa como un concepto agregado y que este concepto está compuesto por los demás conceptos. Finalmente, la flecha abierta representa una relación de superclase-subclase. El concepto vinculado a la flecha es la superclase de los conceptos vinculados a ella. Esta sintaxis en la figura 1 se ajusta a los estándares del Lenguaje Unificado de Modelado ( UML ). Los conceptos de la figura 1 se definen en la tabla 2. Se proporcionará más contexto sobre estas subactividades del proceso 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, lo cual no es exclusivo de la adopción paralela, sino que puede considerarse parte del proceso de gestión del cambio en el que se embarca una organización (Lee, 2004). Algunos factores que influyen en la determinación de una estrategia de implementación con respecto a los métodos de adopción se describen con mayor detalle en Adopción (implementación de software) .

La razón por la que una organización elige la adopción paralela en lugar de una conversión piloto, una adopción masiva o por fases suele ser una compensación entre costes y 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 a la organización que dos sistemas funcionen en paralelo durante un cierto período. El funcionamiento simultáneo de dos sistemas implica una inversión en recursos humanos . Además de una buena preparación del personal (adicional) , que debe pasar por un período estresante de funcionamiento en paralelo donde los procedimientos se cruzan. (Rooijmans, 2003, Eason, 1988) Se deben hacer esfuerzos para garantizar la coherencia de los datos y prevenir 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 para capacitarlos en el manejo del nuevo sistema. Cuando es necesario implementar el nuevo sistema mediante un enfoque de cambio radical, el riesgo de fracaso es elevado (Lee, 2004). Si la organización exige un cambio significativo del sistema antiguo (heredado), la compensación entre los costes adicionales y un enfoque paralelo menos arriesgado debería favorecer dichos costes (Lee, 2004). Sin embargo, observamos que la adopción de ERP suele seguir un enfoque de cambio radical (Microsoft, 2004; Yusuf, 2004). Esto implica que una organización debe reflexionar detenidamente sobre su estrategia de implementación e integrar esta decisión en su análisis de gestión de riesgos o de gestión del cambio .

Para preparar adecuadamente la organización, es necesario un análisis de requisitos tanto de TI como organizativos. Puede encontrar más información sobre el análisis de requisitos y la gestión del cambio en otras fuentes. Para la adopción paralela, el requisito de TI más importante (si corresponde) es la atención a la ejecución simultánea de ambos sistemas. En la fase de conversión, existe un intervalo de tiempo en el que el sistema antiguo es el sistema principal. Para transferir los datos del sistema antiguo al nuevo durante el período de puesta al día, debe estar disponible un módulo de transición (Microsoft, 2004). Otros métodos de implementación no tienen directamente este requisito. 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 organizativos requieren cuestiones de gestión de recursos humanos , como la capacitación del personal , el manejo de una estructura organizativa posiblemente cambiante , las características de organización orgánica o mecanicista de la organización (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:

• “El patrocinador del proyecto es responsable del apoyo presupuestario y de garantizar que los representantes clave de la empresa participen en el equipo del proyecto.”
• “El responsable del proyecto puede ser o no un 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 empleados bien preparados que puedan afrontar los errores que se cometan, sin aferrarse de forma conservadora al sistema antiguo. (Eason, 1988)

Es fundamental contar con un plan detallado para la implementación del nuevo sistema en una organización (Lee, 2004; Eason, 1988). Lo más importante en la planificación temporal para una conversión paralela es no precipitarse y no temer posibles retrasos durante la fase de conversión propiamente dicha (Lee, 2004). También puede resultar muy beneficioso trabajar con hitos claramente definidos (Rooijmans, 2003), de forma similar al método PRINCE2 . Para obtener más información sobre la planificación temporal, consulte la sección de Planificación y Planificación estratégica .

La evaluación de requisitos implica redefinir el guion de implementación. Se deben probar los requisitos de TI y, de ser posible, los requisitos organizativos. Se pueden realizar pruebas para evaluar tanto las responsabilidades organizativas (Rooijmans, 2003) como los requisitos de TI. En este punto, es fundamental contar con el apoyo y la participación de la alta dirección (Eason, 1988). Si no se proporcionan los recursos necesarios para la evaluación, la implementación puede fracasar. Tras esta evaluación, el guion de implementación se redefine en un escenario de conversión más explícito.

El escenario de conversión constituye, por lo tanto, un plan maestro para el cambio organizacional en todos sus aspectos. Sin embargo, existen dos temas que aún no han recibido la atención que merecen en el ámbito de la adopción paralela.

• Estrategia de solución alternativa / Plan de reversión: A diferencia de otros escenarios de adopción, el escenario de conversión también integra una estrategia de solución alternativa o de contingencia con un plan de reversión . Esta estrategia se define con mayor detalle en otra entrada, pero en este contexto se refiere a lo siguiente, como se indica en la tabla anterior: un plan de respaldo; estrategia adoptada en el escenario de conversión para prevenir errores en el proceso y tratar de solucionarlos, de modo que la implementación pueda ser exitosa (Microsoft, 2004). El plan de reversión, como una posible estrategia de solución alternativa, se inicia si algo falla en la fase de conversión. Dado que los dos sistemas se ejecutan simultáneamente en una adopción paralela, el plan de reversión indica que la base de datos u otro sistema que gestiona las transacciones debe ser completamente rastreable en el sistema heredado (Microsoft, 2004). De hecho, la adopción paralela proporciona por definición este plan de reversión debido a su naturaleza de un sistema principal y un sistema de respaldo (no principal) .
• Indicadores de criterios: Dado que el escenario de conversión constituye un modelo para la transferencia de los dos sistemas, también implica criterios cuantificables. Los requisitos organizativos y de TI redefinidos se transforman en componentes medibles. Si no se cumplen los criterios durante la conversión de prueba, se debe implementar una estrategia alternativa.

La fase de conversión propiamente dicha ya está en marcha. Durante este proceso, la organización atraviesa un periodo 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 monitoriza de cerca. Cuando se cumplen los criterios del nuevo sistema, el antiguo deja de ser el sistema principal y el nuevo toma el relevo. Las recuperaciones, que forman parte de la estrategia de solución alternativa , son copias de seguridad del sistema antiguo y proporcionan los medios para la ingeniería de fiabilidad y la recuperación de datos . Existen dos formas de realizar recuperaciones: automáticas y manuales (Rooijmans, 2003). Si procede, también se puede implementar un servicio de copia de seguridad remota .

• Actualizaciones automáticas: Se trata de actualizaciones que se transfieren mediante un sistema automatizado, creado durante la fase de preparación de la organización. Este sistema transfiere automáticamente los datos o la información al nuevo sistema cuando se realiza la migración del antiguo sistema principal al nuevo. La ventaja de un sistema automatizado es su rapidez y precisión. La desventaja es que requiere tiempo para crear un sistema de transferencia en una etapa temprana.
• Actualización manual: Cuando la conversión requiere poco tiempo o la complejidad de la información a transferir al nuevo sistema es baja, una organización puede optar por realizar la actualización manualmente. La ventaja de este procedimiento es que no se necesita un sistema (programa informático) para transferir la información y se evitan los posibles problemas que conlleva este tipo de programa. La desventaja radica en la precisión y el tiempo. La actualización manual requiere una cantidad considerable de tiempo adicional y es más susceptible a pequeños errores humanos (Rooijmans, 2003). Además, la inversión adicional en horas de trabajo ya es elevada; un sistema de actualización manual supone una presión aún mayor para el personal.

Existen varias lecciones que se pueden extraer de los estudios de caso: El caso del sistema del DMV de Nevada, descrito por Lee (2004), demuestra que la implementación de un nuevo proceso también puede tener implicaciones políticas. Cuando el sistema que se va a modificar afecta al público en general y no se trata solo de un sistema interno, existen 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 mayores retrasos, por ejemplo, en la comunicación o en la realización de pedidos. Se sugiere que, si el sistema es políticamente sensible, se debe prestar mayor atención al método de conversión y, preferiblemente, optar por la adopción paralela, ya que implica menos riesgo. Una serie de lecciones aprendidas de varios casos reales de implementación de un nuevo sistema de cartera, llevadas a cabo por una consultora empresarial (Venture, 2004), muestran algunas lecciones interesantes extraídas del campo. Estas parecen encajar perfectamente con los problemas mencionados para un proceso genérico de adopción paralela, basado en una combinación de trabajos científicos. En resumen:

• La evaluación de riesgos y la planificación de contingencias (soluciones alternativas) son muy importantes.
• Asignar roles al equipo del proyecto
• Establecer hitos específicos (como PRINCE2 ) que incluyan planes de capacitación y evaluación.
• Identifique los riesgos potenciales y ejecute su plan de contingencia cuando sea necesario.
• Comunicar el estado del proyecto
• Los cambios deben estar debidamente autorizados.
• La estrategia de conversión debe examinar cuidadosamente los requisitos de datos.
• Los datos nuevos y modificados deben someterse a pruebas de validación.
• Elabore un plan de reversión exhaustivo.
• Cuando sea posible, negocie una conversión piloto.

Además, la conversión en paralelo presenta al menos dos dificultades que podrían hacerla poco práctica en el siglo XXI, a pesar de ser una práctica habitual en la industria cuando las entradas consistían en mazos de tarjetas perforadas o bobinas de cinta. Estas son:

1. No es práctico esperar que los usuarios finales, ya sean clientes, trabajadores de la línea de producción o prácticamente cualquier otra persona, introduzcan 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í mismos.

En consecuencia, la conversión paralela se limita hoy en día a unas pocas situaciones específicas, como los sistemas contables donde la verificabilidad absoluta de los resultados es obligatoria, donde todos los usuarios son internos a la organización y comprenden este requisito, y donde el orden de las actividades no puede afectar el resultado. En la práctica, los métodos de conversión piloto y por fases son más relevantes actualmente.

• Adopción de software de producto: Adopción masiva
• Adopción por fases
• Adopción (implementación de software)
• Regata: método de adopción
• Gestión del cambio
• Ingeniería de confiabilidad
• Reversión (gestión de datos)
• Gestión de riesgos
• Ingeniería de software
• Implementación

• Migración de aplicaciones empresariales de UNIX a Windows. (2004), versión 1.0 Microsoft , consultado el 5 de marzo de 2006.
• Implementación de un sistema de contabilidad de cartera: Lecciones aprendidas en la práctica (2004), Venture Financial Systems Group Ltd , consultado el 6 de marzo de 2006.