RESUMEN DEL CASO LA CURA CONTRA EL CAOS
Enviado por Juan Alberto Huapaya Vasquez • 26 de Octubre de 2019 • Tarea • 1.224 Palabras (5 Páginas) • 507 Visitas
RESUMEN DEL CASO
LA CURA CONTRA EL CAOS
El Hospital Metodista compró un sistema llave en mano de base en macrocomputadora para la facturación y los registros de los pacientes de la TDS (Sistema de Datos Técnicos). Este sistema ha dado un dolor de cabeza al Hospital, la mayor parte del tiempo se ha pasado dando manteniemiento al viejo sistema.
Lo departamenos usuarios como el laboratorio del hopistal y emergencias se sienten frustrados porque sus necesidades de cómputo no pudieron ser satisfechas, llegando a comprar sus propios sistemas.
Walter Zerrenner llegó a la dirección de información del hospital y encontró tres planes estratégicos descansando en un estante, dichos planes se desarrollaron sin ninguna aportación del usuario. Por tal razón el director trajo a un equipo para evaluar el estado del departamento de sistemas de información. La evaluación arrojó redes globales y locales incompatibles, ademas los paciententes tenían que registrar por separado en cada departamento, es decir, existía duplicidad de funciones, por si fuera poco los resultados de laboratorio se almacenaban en un sistema departamental distinto.
Los médicos se quejaban de que no podían utilizar las microcomputadoras en sus oficinas para entrar al sistema TDS para obtener infromación de pacientes, además el sistema TDS no manejaba pacientes externos.
Zerrener formó un comité de planeación de sistemas de información con los principales representantes del hospital. Se identificó tres opciones y soluciones para un sistema de información.
La primera solución significaba abandonar la enorme inversión del hospital en sistemas existentes que no trabajaban bien en los departamentos individuales.
La segunda solucióm significaba crear una interfaz por separado para cada sistema departamental.
La tercera solución implicaba obtener información de cada sistema departamental. La cual parecía la más viable.
Zerrenner hizo un modelo operativo de prueba del nuevo sistema, la cual fue llamada como Information Exchange Platform, la cual no se diseñó para capturar todos los datos de los deparramentos individuales.
Un segundo comité está decidiendo qué información se requiere en distintos departamentos, el cual adoptó la regla del 80/20, enfocándose en la información más importante, la cual proviene del área de laboratorio, radiología, demografía de pacientes e interpretación de electrocardiogramas.
ANTECEDENTES O PROBLEMAS QUE ENFRENTAN LAS EMPRESAS
Desarrollo de Software a la medida vs comprar o rentar software
Antes de elegir entre desarrollar un software a la medida o comprar o rentar, habría que tener las siguientes consideraciones:
Si la operación principal del negocio va a ser operada con un Software, es un indicador para pensar en desarrollar algo a la medida, de lo contrario la operación clave tendrá que acoplarse a las funcionalidades de un paquete que no necesariamente cubrirán las necesidades como las requerimos. Las operaciones secundarias que no son la columna vertebral pueden ser cubiertas con algún paquete general, sobre todo aquellas que se pueden acoplar a lo común como pueden ser facturación, nóminas, etc.
Otro factor importante a considerar es: ¿En cuánto tiempo necesito estar operando? Si bien es cierto, es muy probable que un paquete ya desarrollado requiera menos tiempo de implementación que uno desarrollado a la medida, y el capital invertido sea menor, existen riesgos que hay que considerar como ¿Qué cambios en mi operación debo de considerar para que este software opere como fue diseñado? Porque los sistemas ya hechos tienen una estructura a la cual debemos acoplar nuestra operación. Saber cuánto nos cuesta el licenciamiento, cuántas licencias necesitaré y poder saber si la renta mensual al mediano plazo no supera la inversión que haría en un producto propio con mayor posibilidad de extensión y hecho a la medida de mi negocio.
Revisar a quién pertenecerá el código fuente generado, así como toda la información proporcionada. Este es un criterio muy importante, ya que en caso de hacer negocio, y al final decidamos dejar la relación con el proveedor y continuar por nuestra cuenta, o con otro proveedor, será necesario ser los dueños del desarrollo, los datos y el código fuente para poder crecerlos o heredarlos.
Ir más allá de implementar y dejar funcionando la aplicación es un valor agregado que un proveedor puede ofrecer, tal como capacitar a los usuarios claves de sistema, dar un curso o sesión sobre como el sistema viene a ayudar y no a perjudicar, y además, que el proveedor ofrezca como parte del servicio el soporte en sitio de un especialista que estuvo involucrado en el desarrollo del sistema para cualquier duda o emergencia que suceda, son puntos extras que debiéramos considerar a favor de él.
...