La adopción paralela es un método para transferir entre un sistema ( TI ) anterior a un sistema (TI) objetivo 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 del 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.
Descripción general
Esta entrada se centra en el proceso genérico de adopción paralela; Los ejemplos (del mundo real) se utilizan 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 está destinado a proporcionar una descripción completa de todos los pasos involucrados en la adopción paralela, pero se hará hincapié en las características únicas de la adopción paralela. Algunas características comunes, especialmente 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) .
Otros tipos 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; A continuación se proporcionarán más conocimientos sobre este tema. Los otros tres métodos de adopción son: Adopción de software de producto : Adopción de Big Bang (también conocida como Conversión directa, estrategia slam dunk o de pavo frío) , Adopción por fases y Adopción piloto.
- Adopción de software de producto: Adopción de Big Bang / Adopción de inmersión : Una adopción de Big Bang implica transferir a toda la organización del sistema antiguo al nuevo en un cambio instantáneo. Ésta es la opción más barata, pero si el nuevo sistema falla, la organización se verá en un gran problema. 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 la activación del nuevo sistema es una emergencia.
- Adopción por fases (también conocida como conversión gradual) : en la implementación de adopción por fases, la organización se está transfiriendo gradualmente a un nuevo sistema en diferentes fases, por módulo o subsistema. Algunos sistemas son incapaces de introducirse por partes, ya que dependen demasiado de todo el sistema. El uso de la adopción por fases tiene menos riesgos, pero causa la mayoría de las interrupciones debido a que lleva más tiempo transferir del sistema antiguo al nuevo.
- Adopción piloto: el método de adopción piloto se utiliza para grandes organizaciones que tienen varias ubicaciones o departamentos en gran parte independientes. El nuevo sistema se introduce en una de las ubicaciones o departamentos y se extiende a otras ubicaciones o departamentos a lo largo del tiempo. (límite limitado si un nuevo sistema falla) (Turban, 2002)
Hay varios casos en los que la conversión en paralelo no puede considerarse una estrategia de conversión viable. Primero, considere si el nuevo sistema contiene cambios de esquema significativos. Los elementos de datos requeridos por un sistema que no están siendo llenados por el otro pueden conducir, en el mejor de los casos, a inexactitudes y, en el peor de los casos, corrupción de datos. Otra preocupación es si el sistema se basa en la tecnología comercial del consumidor (COTS). Si la documentación de un proveedor COTS indica que más de una aplicación no puede compartir la misma base de datos, la conversión en paralelo 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 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 falsamente un sistema paralelo que se ejecuta en la misma base de datos como un intento de sortear los controles de licencias y, por lo tanto, deshabilitar el sistema.
Colocar en proceso de implementación
Parece haber pequeñas convenciones sobre el proceso de adopción paralela. Varias fuentes (por ejemplo: Turban, 2002, Eason, 1988, Rooijmans, 2003, Brown, 1999) no utilizan un solo nombre de descripción de proceso. El término adopción paralela se indica en estas fuentes, aunque coherente por fuente como: conversión en paralelo, ejecución en paralelo, ejecución en la sombra, transición en paralelo e implementación en paralelo. Este parece ser el caso porque una descripción genérica del proceso no necesita una clasificación distinta. Hay varios 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 se puede ver 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 verse como un medio posible para lograr ese objetivo. Sin embargo, hay bastantes factores que se están teniendo 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
El proceso de adopción paralelo 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 pasando por todos los procesos identificados en la figura 1, mientras se abordan brevemente las actividades comunes que son necesarias para cualquiera de las estrategias de conversión identificadas.
La Figura 1 ofrece una descripció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 paralela de actividades, las actividades se vuelven a unir en una línea negra similar. Cuando no hay una flecha de una actividad a otra, esto indica que son agregados de una actividad mayor arriba. Las actividades se dividen en cuatro fases principales:
- Definir la estrategia de implementación , que se ocupa del tipo de estrategia de implementación que se debe ejecutar.
- Pre-implementación , que tiene que ver con la construcción de una planificación de todos los aspectos y requerimientos involucrados en la implementación.
- Preparar la organización La organización debe prepararse adecuadamente de acuerdo con la fase anterior.
- La conversión se ocupa del proceso de conversión real y el cierre del proceso de conversión; continuar con el nuevo sistema.
Las principales fases 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 se puede subdividir en más conceptos, pero no es de mayor interés para el proceso de adopción paralelo. La figura en forma de diamante indica que el concepto vinculado a él, sirve como un concepto agregado y que este concepto consiste en 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 de la figura 1 se definen en la tabla 2. Debajo de las tablas se proporcionará más contexto para estas subactividades en el proceso.
Actividad | Descripción |
---|---|
Definir la estrategia de implementación | La estrategia de implementación se determina en esta etapa temprana. (Brown, Vessey, 1999) |
Crear secuencia de comandos de implementación maestra | Se realiza el primer análisis de requisitos inicial, que consta de los requisitos a continuación. (Venture, 2004) |
Planificación del tiempo de construcción | Se está construyendo una primera planificación del proceso de implementación. (Rooijmans, 2003) |
Definir los requisitos organizativos | Los requisitos organizativos se definen aquí (Rooijmans, 2003). |
Definir los requisitos de TI | Se determinan los requisitos de TI (Rooijmans, 2003) |
Actividad | Descripción |
---|---|
Requisitos de instalación | Para preparar la organización, se instalan los requisitos definidos. Se está preparando la organización y se está instalando la TI en máquinas de prueba. (Rooijmans, 2003, Eason, 1988, Microsoft, 2004) |
Requisitos de prueba | Los requisitos se prueban para ver si la organización está lista para la implementación (Rooijmans, 2003) |
Redefinir el script de implementación maestro | El script de implementación maestro se refina con la nueva información recopilada en el proceso con las actividades a continuación. (Rooijmans, 2003) |
Definir indicadores de criterios | Para probar el nuevo sistema, se están creando indicadores de criterios. (Rooijmans, 2003, Microsoft, 2004) |
Formular un plan de solución temporal / reversión | Además, se elabora un plan de solución alternativa con un escenario de reversión. Con estos planes, la organización puede respectivamente intentar corregir los errores que se cometen y retroceder si falla la implementación en una determinada etapa del proceso. (Microsoft, 2004, Rooijmans, 2003) |
Realizar conversión de prueba (segmentaria) | En organizaciones muy complejas, puede resultar beneficioso realizar una conversión de prueba antes de la puesta en marcha. (Microsoft, 2004, Rooijmans, 2003) |
Actividad | Descripción |
---|---|
Ponte al día | Se inicia el proceso de conversión, varias actividades se ejecutan en paralelo. Durante esta etapa, se están poniendo al día utilizando el sistema antiguo. El antiguo sistema está a la cabeza, pero el nuevo funciona en paralelo. Todos los cambios en el sistema, deben colocarse en el nuevo sistema. (Microsoft, 2004, Rooijmans, 2003) |
Sistema de control | El sistema está siendo controlado en todo momento por el sistema de control. Con los indicadores definidos y las características de ejecución del sistema, se rastrean los errores y los errores. (Microsoft, 2004, Rooijmans, 2003) |
Ejecute el sistema antiguo líder | El viejo sistema está liderando; procesar los datos reales. |
Ejecutar nuevo sistema | El nuevo sistema funciona en paralelo con el antiguo y se supervisa de cerca. (Microsoft, 2004, Rooijmans, 2003) |
Traducir ponerse al día en el nuevo sistema | Si se cumplen los criterios, las actualizaciones se traducen y se transfieren al nuevo sistema y el proceso de conversión pasa a su siguiente etapa. (Microsoft, 2004, Rooijmans, 2003) |
Ejecute la estrategia de solución temporal / reversión | Si no se cumplen los criterios, se lleva a cabo la estrategia de solución temporal o la estrategia de reversión, según la naturaleza de los errores. (Microsoft, 2004, Rooijmans, 2003) |
Ponte al día | Las actualizaciones se realizan por motivos de seguridad, incluso cuando el nuevo sistema es líder. (Microsoft, 2004, Rooijmans, 2003) |
Ejecutar sistema antiguo | El sistema antiguo funciona como respaldo, por motivos de seguridad. |
Ejecute un nuevo sistema líder (1) | El nuevo sistema es líder y está en pleno funcionamiento. Todas las transacciones y cambios en el sistema se manejan aquí. (Microsoft, 2004, Rooijmans, 2003) |
Actividad | Descripción |
---|---|
Ejecute un nuevo sistema líder (2) | Todos los controles y actualizaciones están cerrados. El nuevo sistema es el único en funcionamiento. (Microsoft, 2004, Rooijmans, 2003) |
Desactivar el sistema antiguo | El sistema antiguo ya no es necesario y está desactivado. (Microsoft, 2004, Rooijmans, 2003) |
Los conceptos de la figura 1 se definen en la tabla 2-1 a continuación.
Concepto | Definición |
---|---|
Estrategia de implementacion | La estrategia que se elegirá para implementar el nuevo sistema. Las opciones son big bang, por fases, adopción paralela, conversión piloto o una combinación de esos cuatro. (Turbante, 2002, Rooijmans, 2003) |
Script de implementación | Versión sin procesar del escenario de conversión real, que consta de requisitos organizativos, requisitos de TI y una planificación inicial del tiempo. (Venture, 2004, Eason, 1988) |
Requisitos organizativos | Requisitos dentro de la organización que deben estar presentes para una implementación exitosa. Se ocupan de optimizar (cambiar) la organización para el nuevo sistema. Los temas involucrados pueden ser: Gestión de recursos humanos, cambio de organigramas y nuevas estructuras comerciales. (Rooijmans, 2003) |
Requisitos de TI | Los requisitos de tecnología de la información son los requisitos de software y hardware, las opciones de plataforma, teniendo en cuenta el presupuesto y los sistemas existentes. (Rooijmans, 2003) |
Planificación del tiempo | Una planificación en la que se asigna a las actividades un período de tiempo en el que deben completarse, proporcionando una imagen general del proyecto de implementación con respecto al tiempo disponible. (Eason, 1988) |
Requisitos | |
Conformidad | La conformidad tiene que ver con el cumplimiento de los requisitos. (ISO 9000) |
Escenario de conversión | El script de implementación redefinido, teniendo en cuenta la conformidad con los requisitos. Además, el escenario de conversión consiste en una solución alternativa y un plan de reversión. El escenario de conversión es el anteproyecto del proyecto de implementación. (Rooijmans, 2003) |
Estrategia de solución alternativa | Un plan de respaldo; estrategia adoptada, en el escenario de conversión para evitar errores en el proceso de conversión e intentar solucionarlos, de modo que la implementación aún pueda tener éxito. (Rooijmans, 2003) |
Indicadores de criterios | Criterios cuantificables y medibles con respecto a los requisitos, para determinar si el proceso de implementación fue exitoso. (Rooijmans, 2003) |
Plan de reversión | Plan que facilite invertir la dirección de la replicación para volver al sistema antiguo sin pérdida de datos o información. (Microsoft, 2004) |
Prueba de conversión | Conversión de prueba segmentaria, antes de que se lleve a cabo la conversión real, con el objetivo de estar mejor preparados frente a incertidumbres o problemas en el proceso de conversión real. (Microsoft, 2004) |
Sistema antiguo | El sistema antiguo: cuando lidera = verdadero; el sistema antiguo maneja las transacciones del sistema en vivo: Las principales entidades operativas que componen el producto, por ejemplo, hardware, software. También un enfoque organizado y disciplinado para realizar una tarea, por ejemplo, un sistema de notificación de fallas (ISO 9000) |
Nuevo sistema | El nuevo sistema (objetivo): El nuevo sistema, cuando lidera = verdadero; el nuevo sistema maneja las transacciones del sistema en vivo. Las principales entidades operativas que componen el producto, por ejemplo, hardware, software. También un enfoque organizado y disciplinado para realizar una tarea, por ejemplo, un sistema de notificación de fallas (ISO 9000) |
Control | El sistema de control general que comprende indicadores de desempeño, así como una evaluación de confiabilidad y puesta al día. El sistema de control es muy amplio y es el sistema de comando central para convertir el sistema antiguo y administrar el nuevo durante el proceso de adopción en paralelo. (Rooijmans, 2003, Microsoft, 2004) |
Actuación | La evaluación cuantificable del rendimiento del sistema antiguo y nuevo sirve como entrada para el sistema de control. (Rooijmans, 2003) |
Evaluación de confiabilidad | Una evaluación cuantitativa de la confiabilidad de un producto, sistema o parte del mismo. Dichas evaluaciones generalmente emplean modelos matemáticos, resultados de pruebas directamente aplicables al producto, datos de fallas, cifras de confiabilidad estimadas y estimaciones de ingeniería no estadística. (ISO 9000) |
Ponerse al día | Los Catch ups consisten en copias de seguridad creadas de forma automática o no automática del sistema utilizando el sistema antiguo, que se traducirán en el nuevo sistema. (Rooijmans, 2003) |
Actualización automática | Recuperaciones creadas automáticamente (Rooijmans, 2003) |
Ponerse al día a mano | Catch ups creados por entrada manual (Rooijmans, 2003) |
Determinación de la estrategia de implementación paralela
La adopción paralela va precedida de la determinación de la estrategia de implementación, que no es exclusiva de la adopción paralela, pero puede verse como parte del proceso de gestión del cambio en el que entra una organización. (Lee, 2004). Algunos factores que intervienen en la determinación de una estrategia de implementación con respecto a los métodos de adopción se describen con más detalle en Adopción (implementación de software) .
Riesgo versus costos
La razón por la que una organización elige la adopción paralela en favor de una conversión piloto, big bang o adopción por fases es a menudo una compensación entre costos y 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 a la organización que dos sistemas funcionen 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) , que tiene que pasar por un período estresante de ejecución paralela donde los procedimientos se cruzan entre sí. (Rooijmans, 2003, Eason, 1988) Se deben poner esfuerzos en la consistencia 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 para manejar el nuevo sistema.
Cuando es necesario que el nuevo sistema se implemente siguiendo un enfoque de big bang, el riesgo de falla es alto (Lee, 2004). Cuando la organización exige mucho que se cambie el sistema antiguo (heredado), la compensación entre los costos adicionales involucrados por un enfoque paralelo menos riesgoso debería favorecer esos costos adicionales (Lee, 2004), a pesar de esto, vemos que la adopción de ERP sigue a una adopción big bang en la mayoría de los casos (Microsoft, 2004, Yusuf, 2004).
Esto significa que una organización debe pensar con claridad 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 .
Desarrollar un script de implementación
Requisitos de TI
Para preparar adecuadamente la organización, es necesario un análisis de requisitos tanto de TI como de requisitos organizativos. Puede encontrar más información sobre el análisis de requisitos y la gestión de cambios en otro lugar. 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 principal. Para transferir los datos del sistema antiguo en el período de actualización al nuevo sistema, debe haber un módulo de transición disponible (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 .
Requisitos organizativos
Además de los requisitos de TI, los requisitos organizativos requieren cuestiones de gestión de recursos humanos como la formación del personal , lidiar con una estructura organizativa quizás cambiante , una organización orgánica o características de organización mecanicista de la organización (Daft, 1998) y lo más importante: el apoyo de la alta dirección. (Brown, Vessey, 1999). Brown y col. (1999) identifican dos roles distintos que la alta dirección puede iniciar: los llamados roles de patrocinador y campeón:
- "El patrocinador de un proyecto es responsable del apoyo presupuestario y de garantizar que los representantes comerciales clave desempeñen un papel en el equipo del proyecto".
- "El campeón 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 en paralelo es muy estresante y requiere empleados bien preparados que puedan lidiar con los errores que se están cometiendo, sin ser conservadoramente ansiosos por el antiguo sistema. (Eason, 1988)
Planificación del tiempo
Es muy importante tener un plan detallado de conducción del nuevo sistema en una organización (Lee, 2004, Eason, 1988). Lo más importante sobre la planificación del tiempo para una conversión en paralelo es no apresurar las cosas 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), 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 .
Preparando la organización
Evaluación de requisitos
La evaluación de requisitos implica redefinir el script de implementación. Deben probarse los requisitos de TI y (si es posible) organizativos que se establecieron. Se pueden ejecutar algunas pruebas en las que se pueden evaluar las responsabilidades organizativas (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 ponen los recursos disponibles para evaluar, la implementación puede no tener éxito como consecuencia directa. Después de esta evaluación, el script de implementación se redefine en un escenario de conversión más explícito.
Escenario de conversión
Por tanto, el escenario de conversión consiste en un plan para el cambio organizativo en todos los aspectos. Sin embargo, hay dos temas que aún no recibieron la atención que merecen en el alcance de la adopción paralela.
- Estrategia de solución alternativa / plan de reversión: a diferencia de los otros escenarios de adopción, también se integra en el escenario de conversión la estrategia de solución alternativa o de contingencia con un plan de reversión . La estrategia de solución alternativa se define en un ámbito más amplio en otra entrada, pero en este contexto indica como se define en la tabla anterior: Un plan de respaldo; estrategia adoptada, en el escenario de conversión para evitar errores en el proceso de conversión e intentar solucionarlos, de modo que la implementación aún pueda tener éxito. (Microsoft, 2004). El plan de reversión, como una posible estrategia de solución, se inicia si algo sale mal 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 maneja 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 líder y un sistema de respaldo (no líder) .
- Indicadores de criterios: Dado que el escenario de conversión es un modelo de ejecución de la transferencia de los dos sistemas, también implica criterios cuantificables. Los requisitos organizativos y de TI redefinidos se están transfiriendo a componentes medibles. Cuando no se cumplen los criterios en la conversión de prueba, se debe implementar la estrategia de solución alternativa.
Conversión
La fase de conversión real está ahora en su lugar. Durante este proceso, la organización se encuentra en un período estresante (Eason, 1988, Rooijmans, 2003). Los dos sistemas funcionan en paralelo de acuerdo con el escenario de conversión y el nuevo sistema está siendo monitoreado de cerca. Cuando se cumplan los criterios del nuevo sistema, el sistema antiguo dejará de ser el sistema líder y el nuevo sistema tomará el relevo. Las actualizaciones que forman parte de la estrategia de solución alternativa son las copias de seguridad del sistema anterior y proporcionan los medios para la ingeniería de confiabilidad y la recuperación de datos . Hay dos tipos de formas de ponerse al día: ponerse al día automáticamente y ponerse al día a mano. (Rooijmans, 2003). Si corresponde , también se puede implementar un servicio de respaldo remoto .
Sistema de control
- Actualizaciones automáticas: actualizaciones 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 pasa del antiguo sistema principal al nuevo sistema principal. El beneficio de un sistema automatizado es que es rápido y preciso. La desventaja es que se necesita tiempo para producir un sistema de transferencia en una etapa anterior.
- Actualización manual: cuando la conversión real implica solo 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 la actualización 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 este tipo de programa de transferencia. La compensación es precisión y tiempo. Se necesita una cantidad considerable de tiempo adicional para transferir las actualizaciones manualmente y es más vulnerable a pequeños errores humanos (Rooijmans, 2003). Además, la inversión adicional en horas laborales ya es alta; un sistema de recuperación manual ejerce aún más presión sobre el personal.
Evaluación / Relevancia práctica
Hay varias lecciones que se pueden aprender de los estudios de caso: El caso del sistema DMV de Nevada, descrito por Lee (2004), aprende que la implementación de un nuevo proceso también puede tener implicaciones políticas. Cuando el sistema que se cambiará afecta al público en general y no solo se está cambiando un sistema interno, hay algunas presiones más 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 retrasos, 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 opte por la adopción paralela, ya que hay menos riesgo involucrado.
Una serie de lecciones aprendidas de una serie de escenarios reales de implementación de un nuevo sistema de cartera, realizado por una empresa de consultoría empresarial (Venture, 2004) muestra algunas lecciones interesantes aprendidas en el campo. parecen encajar perfectamente con los temas mencionados para un proceso de adopción paralelo genérico, basado en una combinación de trabajo científico. Resumir:
- La evaluación de riesgos y la planificación de contingencias (soluciones alternativas) son muy importantes
- Asignar roles al equipo del proyecto
- Construya hitos específicos (como PRINCE2 ) que incluyan planes de entrenamiento y prueba
- 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 probarse con las reglas de validación
- Construya un plan de reversión completo
- Cuando sea posible, negocie una conversión piloto
También existen al menos dos dificultades con la conversión en paralelo que pueden hacer que su uso no sea práctico en el siglo XXI, aunque era un elemento básico de la práctica de la industria cuando las entradas consistían en mazos de tarjetas perforadas o carretes de cinta. Estos son:
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 diferentes interfaces.
2. Las diferencias de tiempo entre dos sistemas interactivos multiusuario pueden producir correctamente resultados diferentes incluso cuando ambos sistemas funcionan correctamente, son coherentes internamente y pueden utilizarse con éxito por sí mismos.
Como resultado, la conversión en paralelo está restringida a unas pocas situaciones específicas en la actualidad, como los sistemas contables donde la verificabilidad absoluta de los resultados es obligatoria, donde los usuarios son todos internos de la organización y comprenden este requisito, y donde no se puede permitir que el orden de las actividades afectar la salida. En la práctica, los métodos de conversión piloto y por fases son más relevantes en la actualidad.
Ver también
- Adopción de software de producto: Adopción de Big Bang
- Adopción por fases
- Adopción (implementación de software)
- Regata: método de adopción
- Gestión del cambio
- Ingeniería de confiabilidad
- Rollback (gestión de datos)
- Gestión de riesgos
- Ingeniería de software
- Implementación
Referencias
Artículos
- Andersson I. Hanson, K. (2003). Difusión de tecnología en una organización de software, Tesis de Licenciatura en Tecnología de la Información aplicada , Universidad de Goteborg
- Brown, CV y Vessey, I. (1999). Enfoques de implementación de ERP: Hacia un marco de contingencia, Actas de la 20ª Conferencia Internacional sobre Sistemas de Información , Charlotte, NC, 13-15 de diciembre, 411-416.
- Chng, S. y Vathanophas V. (2002). Hacia un sistema empresarial interorganizacional: un estudio de grupo focal. La Sexta Conferencia de Asia Pacífico sobre Sistemas de Información (PACIS 2002). Tokio, Japón. 2 al 4 de septiembre de 2002.
- Lee, O. (2004). Un estudio de caso del sistema DMV de Nevada, Revista de la Academia de Negocios y Economía , Volumen 3
- Ribbers, P. y Schoo, KC (2002). Diseño de programas de implementación de software complejos, 35a Conferencia Internacional Anual de Ciencias de Sistemas de Hawái (HICSS'02) , Volumen 8
- Yusuf, Y. y Gunasekaran, A. y Abthorpe MS (2004). Implementación de proyectos de sistemas empresariales: un estudio de caso de ERP en Rolls Royce. Revista Internacional de Economía de la Producción , 87, 251-266.
Libros
- Daft, RL (1998). Teoría y diseño organizacional. Oeste: Internacional Thomson
- Eason, K. (1988). "Capítulo 9, Implementación y soporte", en: Tecnología de la información y cambio organizacional. Londres: Taylor y Francis
- Turban, E. & Mclean, E. & Wetherbe J. (2002) “Capítulo 14, Sistemas de información de edificios”, en: Tecnologías de la información para la gestión. Nueva York: John Wiley & Sons, inc
- Rooimans, R., Theye, M. de y Koop, R. (2003). Regata: Implementaciones de TIC als uitdaging voor een vier-met-stuurman. La Haya: Ten Hagen en Stam Uitgevers.