REDISEÑO DE LA ORGANIZACION MEDIANTE SISTEMAS DE INFORMACION

1. 3 Parte REDISEÑO DE LA ORGANIZACION MEDIANTE SISTEMAS DE INFORMACION

2. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO OBJETIVOS • Cómo podría cambiar la manera de trabajar de una organización el hecho de construir un nuevo sistema? • Cómo puede asegurarse una compañía de que los nuevos sistemas de información que construya encajen en sus planes de negocio? • Qué pasos se requieren para construir un nuevo sistema de información?

3. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO OBJETIVOS • Con qué métodos alternativos se cuenta para construir sistemas de información? • Existen técnicas o métodos de construcción de sistemas que nos ayuden a construir aplicaciones de comercio electrónico y de negocios en línea con más rapidez?

4. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO RETOS PARA LA ADMINISTRACION • Principales riesgos e incertidumbre en el desarrollo de sistemas • Determinar dónde pueden tener el mayor impacto estratégico los nuevos sistemas y procesos de negocios

5. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Administración de la Empresa Digital • Los Sistemas varían ampliamente en cuanto a su objetivo o misión y en cuanto a los proceso por ejecutar. Por ejemplo Sistemas en la industria minera , manufacturera, en la banca , empresas de servicios, etc.

6. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Estrategias / Necesidades Corporativas Solicitudes de Aplicaciones por parte de los Usuarios finales Estrategias / Necesidades de cada Unidad de Negocio Plan de Sistemas de Informació n Proceso de asignación de pioridades y recursos

7. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Estrategia de negocio Funciones y procesos de negocio ACTIVIDADES DE LA EMPRESA Diseño y ejecución de acciones para conseguir objetivo Planificación de Objetivos Control (de resultados de acciones contra objetivos) Sistemas de Información Registro de transacciones Transacciones Entorno ORGANIZACION

8. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO • Los sistemas de Información en la Organización deben responder para qué están. • Lo anterior implicará el diseño de la estructura de datos que acabará siendo la base de datos del SI.

9. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Planificación de TI/SI a partir de la estrategia del Negocio • Lista de proyectos a desarrollar en los próximos 3 - 5 años • Situación actual al momento de la preparación del plan • Prioridades de cada Proyecto • Detalle de los proyectos a desarrollar el primer año. • Mecanismos de evaluación adecuados • Lista de actividades de la empresa donde la TI pueda utilizarse como herramienta de soporte para aumentar su eficacia

10. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Enlace de los Sistemas de Información con el Plan de Negocios • Plan de Sistemas de Información • Mapa que indica la dirección de desarrollo de los sistemas, el modo de proceder , la situación actual, la estrategia administrativa , el plan de implementación y el presupuesto

11. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Contenido de un Plan de Sistemas de Información • Propósito del Plan • Panorama global del contenido del Plan • Cambios en la situación actual de la empresa • Plan estratégico de la empresa • Organización actual y futura del negocio • Procesos clave de negocios • Estrategia administrativa • Plan Estratégico de Negocio • Situación actual • Organización actual del negocio • Entornos cambiantes • Principales objetivos del plan de negocios • Sistemas Actuales • Principales sistemas que apoyan las funciones y procesos de negocios • Capacidad actual de infraestructura • Hardware • Software • Base de Datos • Telecomunicaciones e Internet • Dificultades para cumplir con los requerimientos de negocios • Demandas futuras anticipadas

12. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Contenido de un Plan de Sistemas de Información • Nuevos desarrollos • Proyectos de nuevos sistemas • Descripción de proyectos • Razón de ser del negocio • Capacidades requeridas de la nueva infraestructura • Hardware • Software • Base de datos • Telecomunicaciones e Internet • Estrategia administrativa • Planes de adquisición • Acontecimientos importantes y marco de tiempo • Reordenación organizacional • Reorganización interna • Controles administrativos • Principales iniciativas de capacitación • Estrategia de personal

13. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Contenido de un Plan de Sistemas de Información • Plan de implementación • Dificultades anticipadas de la implementación • Informes de progreso • Requerimientos de presupuestos • Requerimientos • Ahorros potenciales • Financiamiento • Ciclo de adquisiciones

14. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Establecimiento de requerimientos de Información Organizacional • Análisis empresarial (planeación de negocios) • Análisis de los requerimientos de información de toda la organización que examina a esta última en términos de unidades, funciones , procesos de datos organizacionales. • Ayuda a identificar la entidades y atributos clave de los datos de la organización

15. Figura 12-1 LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Matriz de Procesos/Clases de Datos Grupos de Aplicación Lógica Planeación Administración general Administración de programas Apoyo C= creadores de datos U= usuarios de datos

16. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Establecimiento de requerimientos de información Organizacional • Análisis estratégico o factores cruciales para el éxito (FCE) • Una pequeña cantidad de metas operativas fácilmente identificables a las que les dan forma la industria, la empresa , el gerente y el entorno más amplio y de las cuales se cree que aseguran el éxito de una organización . • Se utilizan para determinar los requerimientos de información de una organización

17. Figura 12-2 LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Uso de FCE para desarrollar sistemas FCE de Gerente B FCE de Gerente D FCE de Gerente A FCE de Gerente C Conjuntar + analizar FCE individuales Desarrollar acuerdos sobre FCE de la compañía Definir FCE de la compañía Utilizar FCE para desarrollar prioridades del sistema de información Definir DSS y bases de datos

18. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Ejemplo Metas y FCE

19. LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Desarrollo de sistemas y cambio organizacional • Automatización: uso de la computadora para acelerar la realziación de tareas existentes • Racionalización de procedimientos: La agilización de procedimientos operativos estandarizados, eliminando los cuellos de botella obvios para que la automatización haga mas eficiente los procedimientos operativos • Reingeniería de procesos de negocios: Rediseño radical de los procesos de negocios, combinando los pasos para reducir las pérdidas y eliminando las tareas repetitivas, de uso intensivo de papel, con el propósito de mejorar costos, calidad y servicio al mismo tiempo que maximizar los beneficios de la tecnología de la información • Cambio de paradigma: Reconceptualización radical de la naturaleza del negocio y de la naturaleza de la organización

20. Figura 12-3 LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Cambio organizacional conlleva riesgos y recompensas ALTO Cambios de paradigmas RIESGO Reingeniería Racionalización BAJO Automatización RENDIMIENTO ALTO BAJO

21. REINGENIERIA DE PROCESOS DE NEGOCIOS Y MEJORA DE PROCESOS Reingeniería de Procesos de negocios • Reingeniería de Procesos de Negocios • El proceso de agilizar los procedimientos de negocios para que los documentos se puedan mover fácil y eficazmente de un lugar a otro • Si se rediseñan radicalmente los procesos de negocios antes de aplicar el poder de la computación , las organizaciones cuentan con la posibilidad de obtener rendimientos bastantes significativos de sus inversiones en tecnología de la información

22. REINGENIERIA DE PROCESOS DE NEGOCIOS Y MEJORA DE PROCESOS Rediseño del procesamiento de hipotecas en Estados Unidos ANTES DE LA REINGENIERIA Enfoque de escritorio a escritorio Origen del préstamo , solicitud en papel Información de crédito Análisis de crédito y aseguramiento Procesamiento de la solicitud Generación del documento Aprobación y cierre Precalificación • Estimados de límite del préstamo • Opciones de estructuración del préstamo • Estimados del pago mensual máximo • Documentos de la solicitud • Documentos de la autorización de divulgación • Documentos de conformidad • Hojas de cálculo de análisis de crédito • Cálculos al cierre • Documentos del cierre • Preparación de administración del préstamo • Avalúo • Búsqueda del título • Verificación y clasificación de crédito Administración del préstamo en múltiples ubicaciones por especialistas en análisis de crédito y calificadores de riesgo Cobros , bancarrotas y ejecución hipotecaria Procesamiento e informes sobre pagos Administración de cuentas en depósito Servicios a clientes • Contabilidad de seguro de riesgo • Contabilidad de seguro de hipoteca privada • Contabilidad de impuestos de la propiedad • Contabilidad de Pagos • Estado de cuenta • Informe de impuestos • Consultas de saldos • Consultas de cuentas en depósito • Solicitudes de estados de cuenta • Avisos de pago atrasado • Administración de cuentas de deudores Figura 12-4a

23. REINGENIERIA DE PROCESOS DE NEGOCIOS Y MEJORA DE PROCESOS Rediseño del procesamiento de hipotecas en Estados Unidos Administración del préstamo por especialistas en seguros y cuentas en depósito Transferencia al mercado secundario Valor y riesgo • Inventario de préstamos • Cálculos de pérdidas y ganancias • Administración del riesgo • Administración de compra y venta de préstamos • Concentración de préstamos • Remesa de préstamos DESPUES DE LA REINGENIERIA Enfoque de equipo Procesamiento de préstamos por equipos de representantes que manejan todos los casos Equipo que origina el préstamo Centro de producción regional Información del cliente Computadora portátil del representante de campo Centro de producción regional Administración de préstamos por especialistas que trabajan en equipo Límite de crédito preaprobado Equipo de administración de préstamos Red de acceso conmutado o intranet Figura 12-4b

24. REINGENIERIA DE PROCESOS DE NEGOCIOS Y MEJORA DE PROCESOS Pasos para lograr una reingeniería efectiva • El personal directivo superior tiene que desarrollar una amplia visión estartégica. • La gestión debe comprender y medir el desempeño de los procesos existentes como base de referencia. • La Tecnología de Información debe ser considerada en el proceso de diseño desde el principio. • La infraestructura de TI debe ser capaz de apoyar cambios en el proceso de negocio

26. CICLO DE VIDA DE UN PROYECTO DE SOFTWARE • Enfoque : apoyo a las tareas de la organización. • Fases Principales ( varía según autor): • Estudio Factibilidad • Análisis de Requerimientos de Información • Diseño • Construcción • Conversión o implementación • Operación y mantenimiento • Evaluación

28. ISO 12207 Propósito • Establecer un marco común para el ciclo de vida del software para • adquirir, suministrar, desarrollar, operar y mantener software • gestionar, controlar y mejorar el marco • como base para el comercio internacional de software Una arquitectura de alto nivel para el ciclo de vida • Modularidad • Cohesión: un proceso por función principal • Acoplamiento: interfaces mínimas • Responsabilidad • Un proceso bajo la responsabilidad de una parte (de un acuerdo – relación cliente-proveedor -)

29. ESTUDIO DE FACTIBILIDAD - Investigación Preliminar • La investigación preliminar comienza con la solicitud de una persona, administrador o especialista en sistemas. Su objetivo es recibir la ayuda de un sistema de información para solucionar un problema. • Cuando se forma la solicitud comienza la Investigación Preliminar, que contiene tres partes: • Aclaración de la solicitud • Estudio de factibilidad • Aprobación de la solicitud Aclaración de la solicitud Antes de considerar cualquier investigación de sistemas, la solicitud de proyecto debe Examinarse para determinar con precisión lo que el solicitante desea. En cualquier caso, Antes de seguir adelante, la solicitud de proyecto debe estar claramente planteada.

30. Estudio de Factibilidad El Estudio de Factibilidad es parte del resultado de la Investigación Preliminar, es Realizado por un grupo pequeño de personas y determina si la organización está en condiciones de realizar el proyecto. Generalmente el estudio puede debe ser de tipo técnico, legal y operacional. Factibilidad Técnica Estudio de Factibilidad Factibilidad Económica Factibilidad Operacional Factibilidad Técnica Con el equipamiento actual, la tecnología disponible de software y personal. ¿Puede Realizarse el proyecto?. De requerirse nueva tecnología. ¿Cúal es la posibilidad de desarrollarla?.

31. Factibilidad Económica Los beneficios que se obtendrán del sistema, ¿superarán los costos de construirlo?. Si no desarrollamos el sistema, ¿Cuáles serán los costos para la organización sin este nuevo sistema? Factibilidad Operacional Una vez desarrollado e implementado, ¿será utilizado el sistema?. ¿Cuál será la resistencia de los usuarios al cambio que proveerá este nuevo sistema?. Esta resistencia, ¿disminuirá los beneficios potenciales del nuevo sistema? También existe la posibilidad de estudiar la Factibilidad Legal del desarrollo de un sistema de información administrativa, dependiendo de la organización en la cual se desarrolle y de las normas legales o constitucionales que limiten procedimientos administrativos de la Organización. Otro aspecto es el estudio de Viabilidad del Proyecto de desarrollo que indica si en la organización están dadas las condiciones, a todo nivel, para desarrollar el nuevo sistema.

32. Aprobación de la Solicitud Aquellos proyectos que son factibles y viables para la organización, deben ser aprobados. En algunos casos el desarrollo puede comenzar inmediatamente. Si el equipo de desarrollo tiene muchos proyectos para realizar, la administración decide el orden en que se llevarán a cabo de acuerdo a la importancia que se le asigne a cada uno. Después de aprobar la solicitud del proyecto, se estima su costo, el tiempo necesario para terminarlo y las necesidades de personal; con esta información se determina donde ubicarlo dentro de la lista existente de proyectos.

33. Análisis de los Requerimientos de Información (Análisis de Sistema) En esta etapa se deben comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Se deben estudiar los procesos de una empresa para entender las siguientes preguntas: ¿Qué es lo que se hace? ¿Cómo se hace? ¿Con que frecuencia se presenta? ¿Qué tan grande es el volumen de transacciones o de decisiones? ¿Cuál es el grado de eficiencia con el que se efectúan las tareas? ¿Existe algún problema? Si existe un problema, ¿qué tan serio es? Si existe un problema, ¿cuál es la causa que lo origina? Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles Relacionados con los procesos de la empresa, sus opiniones sobre porqué ocurren las cosas, Las soluciones que proponen y sus ideas para cambiar el proceso.

34. El éxito de un sistema depende principalmente de la satisfacción de los usuarios • Las estadísticas muestran que el 50% de los errores se producen por un deficiente análisis de requerimientos. Métodos para definir los Requerimientos de Información • Centrados en la detección de las necesidades globales de la Organización • Centrados en la Definición de requerimientos para aplicaciones específicas Métodos orientados hacia necesidades de la Organización se destacan: • Factores Críticos de Éxito (FCE) • Interrogación a los ejecutivos de los elementos críticos que permiten un buen desempeño de un trabajo • Reuniones periódicas guiadas por expertos • Lista de factores sobre los cuales debe proporcionarse un conjunto de sistemas, mediciones e indicadores. • Evaluación y control

35. Análisis de Procesos: • Se apoya en la idea que los grupos de decisiones/acciones, relacionados con la administración de los recursos de la empresa. • Son la base de apoyo y el punto de partida que los sistemas de información deben brindar • Ejemplo: BDP ( Business Systems Planning) que se centra en la elaboración de un plan maestro y una arquitectura general de datos para la generación o desarrollo de sistemas en una organización. • Métodos centrados en la definición de requerimientos para aplicaciones específicas • Análisis de Sistemas Socio-Técnicos: • Comienza con la separación del sistema en dos: Subsistema técnico y subsistema social. • Plantea la definición de los requerimientos de cada subsistema para luego compatibilizar ambas especificaciones desde una perspectiva global, considerando la interacción entre los distintos elementos y el comportamiento de los usuarios afectados por el sistema

36. Análisis de Entradas- Salidas: • Una aplicación se visualiza como un sistema que tiene entradas, salidas y un proceso. • Sugiere un enfoque Top-Down ( de arriba hacia abajo) , que va progresando sucesivamente mediante descomposiciones. • Ejemplo de este método lo constituye el método de diseño estructurado . En general la mayoría de los métodos requieren la participación o interacción entre usuarios y analistas. Lo anterior implica análisis de una serie de variables relevantes: • Restricciones de los individuos como procesadores de información y encargados de resolver problemas. • La variedad y complejidad de los requerimientos de información • Los complejos esquemas de interacción entre los individuos que participan en el proceso de análisis de requerimientos

37. Diseño del sistema Aquí se establece la forma y detalles con los cuales el sistema cumplirá los requerimientos De la etapa de análisis. Diseño Lógico Diseño del sistema Diseño Físico En la etapa de diseño se subdivide en dos etapas llamadas: Diseño Lógico y Diseño Físico. En el Diseño Lógico se identifica el Qué es lo que hará el sistema que se construirá y en el Diseño Físico se identifica el Cómo se efectuaran estas actividades.

38. Los elementos que se determinan en la etapa de diseño son los reportes y demás salidas que debe producir el sistema, también se desarrolla un bosquejo de las pantallas que se esperan que aparezcan cuando el sistema esté terminado; también se indica los datos de entrada, los que serán calculados y los que deben ser almacenados. Se determinan las estructuras de archivo y dispositivos de almacenamiento. La información detallada del diseño se proporciona al equipo de programación para comenzar la fase de desarrollo de software.

39. DISEÑO LOGICO ( Qué hace) Bajo la perspectiva del diseño estructurado de sistemas , el Diseño Lógico se refiere a un conjunto de pautas que permiten generar una jerarquía de módulos de los elementos de un sistema, a fin de que éste pueda modificarse fácilmente. Su objetivo es la obtención de un modelo del sistema apoyado en la utilización de técnicas gráficas que permiten la comunicación entre usuarios y especialistas. Se habla de Diseño Lógico ya que esta etapa se debe realizar en forma totalmente conceptual, prescindiendo de las restricciones físicas a las que el sistema podría estar sujeto. DISEÑO FISICO (Cómo lo hace) En esta etapa se definen detalles requeridos para la construcción del sistema de información. A partir del diseño lógico define una solución particular del sistema. De la concepción conceptual se pasa hacia compromiso con aspectos materiales concretos.

40. FASES RELEVANTES EN EL DISEÑO FISICO • Diseño de Salidas: Definición exacta de los informes, listados, pantallas y documentos que le sistema debe generar. • Aspectos a considerar: contenido – características de los datos – medio en el cual se generará ( impreso , pantalla, accionamiento, sonido) – disposición de los datosde cada salida. • Diseño de las Entradas: Detalle de las entradas necesarias para generar las salidas previamente diseñadas. Especificación de los registros , los archivos de donde se extraerán, el medio de almacenamiento donde residen o dispositivos partir de donde serán capturadas las entradas (teclado, lector óptico, mouse, pantalla sensible, etc.) • Diseño de los Procesos Computacionales: Definición de la transformación de las distintas entradas para la generación de las salidas. • Aspectos involucrados: validación de las entradas , descripción de las formulas o cálculos que se efectúen, especificación de los archivos temporales que se generen y la descomposición del proceso en todos sus módulos.

41. Diseño de los Archivos: Detalle de todos los distintos tipos de archivos involucrados en el diseño ( maestros, temporales, transacciones, históricos, etc.) y de cada uno de ellos la descripción ( nombre, extensión, descripción de sus campos). • Paralelamente en la fase de Diseño Físico se toman las decisiones acerca de la TI (Tecnologías de Información) necesarias para la solución que se esta planteando. Dado a que s un proceso complejo por la diversidad y variedad de alternativas , lo que dificulta el proceso de comparación y la cuantificación exacta de los beneficios a reportar hacia la organización, se debe abordar cuidadosamente incorporando al menos los siguientes criterios: • Conocer el Costo Total de una determinada tecnología revisando los costos ocultos: • Costo de implementación • Seguros involucrados • Equipos de respaldo requeridos • Capacidad y proyección de crecimiento futuro • Entrenamiento • Traslados • Es indispensable justificar por qué y para qué se esta adquiriendo o contratando una determinada tecnología de información.

42. Establecer dentro de los criterios de selección , una serie de elementos complementarios ( características del proveedor y sus servicios, consideraciones de obsolescencia y compatibilidad): • Respecto al Proveedor: • Confiabilidad • Solidez financiera • Prestigio • Apoyo a la puesta en marcha • Servicio técnico • Fórmulas de financiamiento • Formas de Pago • Etc. • Respecto de la Tecnología: • Compatibilidad con la tecnología existente • Compatibilidad con la tecnología a adquirir en el futuro • Posibilidad de crecimiento modular • Nivel tecnológico del componente computacional

43. CONSTRUCCION: Se inicia una vez terminado el Diseño Lógico y Diseño Físico. Este proceso se divide en dos etapas relevantes: • Programación • Pruebas (testing) Programación: Las actividades de esta etapa principalmente consiste en confeccionar los programas a la medida, de acuerdo a los requerimientos del diseño. También se puede instalar o modificar software comprados a terceros. La elección depende del costo de cada alternativa. En empresas pequeñas donde no hay programadores se pueden contratar servicios externos de programación. También se hace la documentación de los programas y un manual del sistema que indica la justificación de la programación de los diferentes procedimientos.

44. Construcción de Programas Documentación del Sistema Desarrollo de Software Adquisición de Software Documentación del Sistema Prueba ( Testing): En esta etapa el sistema se prueba de manera experimental para asegurarse de que no tenga fallas, es decir que funcione de acuerdo a las especificaciones y como los usuarios esperan. Las pruebas del sistema serán con usuarios de los distintos niveles de la organización: usuarios comunes, ejecutivos, directivos, etc. El objetivo es descubrir cualquier sorpresa antes que el sistema sea implementado y que la Organización dependa de él. La finalidad principal de esta etapa es la detección de errores para la operación normal del sistema

45. CONVERSION O IMPLEMENTACION DEL SISTEMA En esta fase se define Cuándo y de qué forma se introducirá el nuevo sistema. La conversión se refiere al momento en el que el nuevo sistema sustituye al que operaba previamente y la implementación se refiere a la instalación y puesta en marcha de los nuevos equipos y procedimientos que el sistema conlleva. Esta etapa genera un clima de gran expectación y gran carga de trabajo. Instalación de nuevos softwares Instalación de nuevos equipos Implantación Entrenamiento de usuarios Instalación de la aplicación Construcción de archivos de datos

46. Existen diferentes alternativas de conversión: • Paralelo • Gradualmente • Con un plan Piloto • Abruptamente Conversión en Paralelo: • Considera el funcionamiento simultáneo durante un cierto período de tiempo del sistema antiguo y del sistema nuevo. • Permite verificar consistencia de la información que entrega el nuevo sistema con el antiguo. • Es muy útil para aplicaciones orientadas al nivel operacional que tienen importancia crucial para el desempeño de la organización. SISTEMA NUEVO SISTEMA ANTIGUO

47. Presenta el inconveniente de que requiere un esfuerzo adicional a los recursos humanos de la organización. • Puede requerir mano de obra adicional para llegar a los plazos inicialmente definidos. • Generalmente se alarga el período de conversión implicando aumento en los costos y carga de trabajo. • Lo anterior ocurre principalmente cuando el sistema no ha podido ser probado o por temor a la falla.

48. CONVERSION GRADUAL: • Este método define un cierto período de tiempo en el cual el nuevo sistema va reemplazando paulatinamente las actividades del antiguo. • La organización conoce poco a poco el desempeño del sistema, minimizando el impacto derivado del cambio y evitando algunos riesgos. • El inconveniente es que no siempre las aplicaciones pueden ser convertidas en forma gradual, principalmente porque requiere de la existencia de actividades divisibles y de una comunicación entre ambos sistemas, que pueden ser costosa de operacionalizar. SISTEMA ANTIGUO SISTEMA NUEVO

49. COVERSION CON PLAN PILOTO: • Se convierte al nuevo sistema sólo una parte de la organización ( departamentos/funciones), quedando el resto del sistema operando con el antiguo. • Se puede detectar errores NO ANTICIPADOS con un mínimo de riesgo. La clave es que el segmento donde se aplica el nuevo sistema sea representativo. • Un riesgo es que el plan piloto se confunda con un test o prueba del mismo sistema y no se perciba la trascendencia de las actividades que le siguen: implementación del sistema a nivel global SISTEMA ANTIGUO SISTEMA NUEVO

50. SISTEMA NUEVO CONVERSION ABRUPTA • Requiere una muy buena planificación la conversión para reemplazar en un determinado tiempo , en toda la organización, el sistema antiguo por el nuevo. • Se reducen violentamente los costos de conversión e incide en el plano psicológico del cambio, ya que asume que todo el personal colaborará en la puesta en marcha y eliminar el antiguo sistema. • El principal inconveniente de este modelo es que ante una detección de un error grave , el efecto es sobre toda la organización, sin el respaldo del sistema antiguo. • Es adecuado para aplicaciones cuyo impacto a nivel organizacional no es muy significativo SISTEMA ANTIGUO