REDISEÑO DE LA ORGANIZACION MEDIANTE SISTEMAS DE INFORMACION

Presentación del tema: "REDISEÑO DE LA ORGANIZACION MEDIANTE SISTEMAS DE INFORMACION"— Transcripción de la presentación:

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

2 Qué pasos se requieren para construir un nuevo sistema de información?
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 RETOS PARA LA ADMINISTRACION
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 Administración de la Empresa Digital
LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO 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 Estrategias / Necesidades Corporativas
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 ACTIVIDADES DE LA EMPRESA
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 Planificación de TI/SI a partir de la estrategia del Negocio
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 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 Plan de Sistemas de Información
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 Contenido de un Plan de Sistemas de Información
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 Contenido de un Plan de Sistemas de Información
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 Contenido de un Plan de Sistemas de Información
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 Establecimiento de requerimientos de Información Organizacional
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 Matriz de Procesos/Clases de Datos
LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Matriz de Procesos/Clases de Datos Grupos de Aplicación Lógica Figura 12-1 Planeación Administración general Matriz de clases de datos y procesos. Este diagrama delinea qué clases de datos se requieren para apoyar procesos organizacionales particulares y qué procesos son los creadores y usuarios de datos Administración de programas Apoyo C= creadores de datos U= usuarios de datos

16 Análisis estratégico o factores cruciales para el éxito (FCE)
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 Uso de FCE para desarrollar sistemas
LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Uso de FCE para desarrollar sistemas Figura 12-2 FCE de Gerente A FCE de Gerente B FCE de Gerente C FCE de Gerente D Conjuntar + analizar FCE individuales Desarrollar acuerdos sobre FCE de la compañía Definir FCE de la compañía El enfoque de FCE se basa en entrevistas con gerentes importantes para identificar sus FCE. Los FCE individuales se conjuntan para desarrollar FCE para toda la empresa . Entonces se pueden construir sistemas para transmitir información sobre estos FCE Utilizar FCE para desarrollar prioridades del sistema de información Definir DSS y bases de datos

18 Ejemplo Metas y FCE Ejemplo Metas FCE
LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Ejemplo Metas y FCE Ejemplo Metas FCE Referente a ganancias Utilidades por acción Industria automotriz Rendimiento de la inversión Estilo Participación de mercado Sistema de calidad del conocimiento Control de costos Estándares de energía No lucrativo Cuidado de salud excelente Integración regional con otros hospitales Cumplimiento de regulaciones gubernamentales Monitoreo mejorado de reglamentaciones Necesidades futuras de salud Uso eficiente de recursos

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 Cambio organizacional conlleva riesgos y recompensas
LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO Cambio organizacional conlleva riesgos y recompensas Figura 12-3 ALTO RIESGO Cambios de paradigmas Reingeniería Las formas más comunes de cambio organziacional son la automatización y la racionalización. Estas estrategias de movimiento y cambio relativamente lentos presentan rendimientos modestos con poco riesgo. Un cambio más rápido y amplio , como la reingeniería y cambios de paradigmas, conlleva recompensas altas pero implica grandes posibilidades de fracaso Racionalización BAJO Automatización RENDIMIENTO BAJO ALTO

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 Procesamiento de la solicitud Análisis de crédito y aseguramiento Generación del documento Precalificación Aprobación y cierre 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 Avalúo Búsqueda del título Verificación y clasificación de crédito Cálculos al cierre Documentos del cierre Preparación de administración del préstamo 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 Pagos Estado de cuenta Informe de impuestos Contabilidad de seguro de riesgo Contabilidad de seguro de hipoteca privada Contabilidad de impuestos de la propiedad 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

25

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

27

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 Métodos para definir los Requerimientos de Información
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 Sistemas Socio-Técnicos:
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 Lo anterior implica análisis de una serie de variables relevantes:
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: Programación
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 Conversión en Paralelo:
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 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 NUEVO SISTEMA ANTIGUO

51 OPERACIÓN Y MANTENCION:
Una vez terminado el sistema en su implementación debe usarse para satisfacer las necesidades de información por las cuales se generó. Sin embargo tenemos que los sistemas de información están inmersos en un medio dinámico, por lo que debe estar sujeto a ciertos cambios que lo adapten a las situaciones del entorno que provoquen modificaciones en sus procesos de transformación de la información. Mantención  soporte continuado al sistema de manera que se mantenga viable.

52 Las alteraciones mayores que signifiquen el rediseño lógico de parte del sistema se debiera entender como nuevos proyectos, los que se detectarían en la etapa de evaluación. La experiencia muestra que las mantenciones mayores generalmente se abordan en forma sucesiva y no como proyectos independientes. Las estadísticas muestra que aproximadamente el 70 % de los recursos de los departamentos de TI se gastan en mantenimiento de los sistema antiguos y es extremadamente caro.

53 EVALUACION: A fin de medir el grado de satisfacción de sus usuarios y verificar si cumple con sus objetivos. Todo sistema debe someterse a una evaluación que permita tomar medidas correctivas oportunamente. Un sistema nuevo debería evaluarse al menos dos veces en el semestre que sigue a su puesta en marcha, para detectar así las necesidades de mayor capacitación o para detectar actitudes que puedan conducir el deceso del sistema. Si la evaluación arroja como resultado la necesidad de realizar cambios significativos en un sistema se debe iniciar un ciclo de vida que parte con el estudio de factibilidad de los cambios, o con el desarrollo de un sistema distinto.

54 Impacto de Nuevas Tecnologías en el Desarrollo de Sistemas
El enfoque del ciclo de vida surgió como necesidad del desarrollo de sistemas tradicionales, es decir, orientados al procesamientos de transacciones. Con el tiempo ha variado el tipo de sistemas demandados y también han surgido nuevos métodos y herramientas para desarrollar aplicaciones sólo varían la importancia relativa y la velocidad de las etapas del proceso. Ejemplos : prototipado, Orientación al Objeto, etc.

55 Analizar los sistemas como cambio organizacional planeado
Contenidos: Visión del desarrollo de los sistemas de información. Administración del proyecto. Instrumentos y técnicas de administración. Factores humanos y organizacionales.

56 Visión de los sistemas de información (Panorama del desarrollo de los SI)
El desarrollo de sistemas son las actividades que se orientan a la producción de una solución de sistemas de información para un problema organizacional o para el aprovechamiento de una oportunidad. Existen múltiples enfoques para desarrollar sistemas.

57 Enfoques para desarrollar sistemas
El ciclo de vida tradicional de sistemas. Elaboración de prototipos. Desarrollo con paquetes de software de aplicaciones. Desarrollo por los usuarios finales. Acudir a proveedores externos.

58 El ciclo de vida tradicional de sistemas
Pese a su carácter estructurado, no existe una descripción única y generalizada acerca de este proceso: Variación en el número de etapas. Variación en la denominación de las etapas. Sin embargo, si se compara el contenido de las etapas, se observa un alto grado de coincidencia.

59 El ciclo de vida tradicional de sistemas Comparación entre Manual de SIA I y Administración de los sistemas de Información de Laudon & Laudon MANUAL DE SIA I LAUDON & LAUDON Investigación preliminar Análisis de sistemas Determinación de requerimientos “ Diseño del sistema Diseño de sistemas Desarrollo de software Programación Prueba de los sistemas Pruebas Implantación y Evaluación Conversión (+convers. datos) Producción y mantenimiento

60 Ventajas y desventajas del ciclo de vida
Apropiado para el procesamiento de transacciones y SIA, o en general, en donde los requerimientos son altamente estructurados y bien definidos. También es apropiado para sistemas técnicos complejos. Es muy costoso y consumidor de tiempo. Es inflexible y desmotiva el cambio. Es poco apropiado para las aplicaciones orientadas a la toma de decisiones.

61 Elaboración de prototipos
Consiste en el desarrollo de un sistema no funcional, rápido y barato para que los usuarios finales lo evalúen. El prototipo avalado por los usuarios puede ser usado como marco de referencia para crear el sistema definitivo. El proceso de desarrollo de un diseño preliminar, de probarlo, afinarlo y probarlo de nuevo, se ha denominado proceso iterativo de desarrollo de sistemas. Las etapas del desarrollo por prototipos están en el manual de SIA I

62 Elaboración de prototipos
Es menos formal que el ciclo de vida. Los requerimientos se determinan dinámi-camente a medida que el prototipo se construye. El análisis, diseño e implantación del sistema ocurren al mismo tiempo.

63 Ventajas y desventajas de la Elaboración de prototipos
Los prototipos son especialmente útiles para el diseño de la interfase con el usuario final. Estimulan el involucramiento intenso de los usuarios finales. No son adecuados para todas las aplicaciones. Están mejor adaptados para las aplicaciones más pequeñas. ¡CUIDADO con avanzar muy rápido hacia un modelo operativo! Se pueden obviar algunos requerimientos. NO olvidar la actualización de la documentación. Adecuado para aplicaciones orientadas hacia el manejo sencillo de datos. Los grandes sistemas deben ser divididos en partes, para cada una de las cuales se construirá un prototipo. Como el sistema puede cambiar con tanta facilidad, la documentación puede no mantenerse bien actualizada.

64 Desarrollo con paquetes de software de aplicaciones
Los paquetes pueden seleccionarse como una estrategia de desarrollo bajo las siguientes circunstancias: Donde las funciones son comunes para muchas empresas. En donde los recursos para el desarrollo interno de SI son escasos.

65 Ventajas del desarrollo con paquetes de software de aplicaciones
Ahorro en el diseño. Ahorro en la mantención. Incorpora las mejores prácticas (best practices) de la industria. Impacto potencial en los procedimientos organizaciones (también puede ser una desventaja).

66 Desventajas del desarrollo con paquetes de software de aplicaciones
Existe en algunos casos la necesidad de adaptar el paquete, ya sea alterando el código fuente o agregando programas de fachada y de traspatio. Esto último puede elevar sustancialmente el costo de implantación.

67 Desarrollo por usuarios finales
Consiste en el desarrollo por los usuarios finales con poca o ninguna asistencia formal de parte de los especialistas técnicos. Esto ha sido posible gracias a las herramientas de cuarta generación y a los costos decrecientes del Hw.

68 Ventajas del desarrollo por usuarios finales
Mejora en la definición de los requeri-mientos. Involucramiento y satisfacción de los usuarios. Control del proceso de desarrollo de sistemas por los usuarios. Disminuir el rezago en cuanto al desarrollo de aplicaciones.

69 Desventajas del desarrollo por usuarios finales
Revisión y análisis insuficiente cuando las funciones de analistas y usuarios ya no están separadas. Falta de normas adecuadas y controles para el aseguramiento de la calidad. Datos no controlados. Proliferación de los sistemas privados de información.

70 Administración del desarrollo por usuarios finales
Uso de Centros de información. Un centro de información es una unidad dentro de la organización que proporciona capacitación y apoyo a los usuarios finales. Establecer políticas, procedimientos y normas para la computación de usuarios finales (Hardware, Software).

71 Recurriendo a proveedores externos
Si la empresa no desea recurrir a sus recursos internos para desarrollar y operar los SI, puede contratar a una institución externa que se especialice en proporcionar estos servicios.

72 Ventajas de acudir a proveedores externos
Economía. Calidad en el servicio. Predecibilidad. Flexibilidad. Hace que los costos fijos pasen a ser variables. Liberación de recursos humanos para otros proyectos. Liberación de capital financiero.

73 Desventajas de acudir a proveedores externos
Pérdida de control. Vulnerabilidad de la información estratégi-ca. Dependencia.

74 Cuando acudir a proveedores externos
Cuando existe una oportunidad limitada de la empresa para distinguirse ante la competencia a causa de una aplicación de un SI. Cuando la predecibilidad de la interrupción de los SI no es muy importante. Cuando concesionar servicios al exterior no aleja a la empresa del know how técnico para innovaciones futuras en los SI. Cuando las capacidades de SI de la empresa son limitadas, ineficaces o técnicamente inferiores.

75 Administración de la concesión a proveedores externos
El establecimiento de la estrategia tecnológica es una de las áreas en las que las empresas no deberían ceder a los proveedores externos. “La tarea estratégica debe permanecer en casa”. Deben administrar al proveedor externo de la misma manera en que administrarían a sus propios departamentos internos de SI. Diseñar los contratos cuidadosamente, de manera que los servicios se ajusten si la naturaleza del negocio cambia.

76 Desafíos del desarrollo de sistemas
Determinación de la estrategia adecuada para el desarrollo de sistemas. Controlar el desarrollo de los SI fuera del departamento de SI. Seleccionar una estrategia de desarrollo de sistemas que se adapte a la arquitectura de la información y al plan estratégico de la empresa. El tercer desafío se refiere a lo que ocurre en el largo plazo. Esto es especialmente válido si se mezcla el uso de paquetes, el uso de proveedores externos y el desarrollo por los usuarios finales.