Sistema de Consulta de Salud – Remedi: estudio de caso
El trabajar en un sistema de Centro de Llamadas sacó toda la preparación de pregrado en SSADM (Análisis de Sistemas Estructurado y Método de Diseño es un método de cascada desarrollado por el Departamento del Tesoro Británico) y como siempre, el trabajar en algo en lo que estudiaste no siempre se aplica en el mundo real cuando llega el momento de la verdad. La cascada es cosa del pasado, rara vez se trabaja en el diseño de sistema de esa forma en la actualidad en el mundo de Agile (donde hay quienes dicen que Agile está muerta) y que la Agencia CentraldeInformática y Telecomunicaciones que desarrolló el SSADM ahora se ha transformado en otra cosa. El informe era delgado (tome una empresa, principalmente el sistema de Interfaz de línea de comandos—esos sistemas en blanco de azul brillante donde uno tiene que tipiar los comandos de memoria) llenos de la lógica comercial y reproducidos en un ambiente de MDI (Interfaz de Múltiples Documentos). Los requisitos ligeros son algo que a nosotros nos gusta considerar como una muestra de confianza de que seremos capaces de completar el proyecto exitosamente.
El sistema que ahora es parte de Simplyhealth Group, tiene cerca de 60 consultores en el sitio disponibles a cualquier hora y que atienden las consultas de los usuarios sobre consultas médicas y evalúan su cualificación para las políticas de seguro médico principalmente a través de sus planes de seguro médico para los empleados de la empresa.
El autor de los requisitos, Richard Chan, fue un héroe en el departamento de Gestión de Proyectos internos de Remedi pero para nosotros, él era la razón por la que estábamos confinados en una habitación, trabajando en los 200 Casos de Uso. Todavía recuerdo su sonrisa irónica cuando nos los entregó—debidamente impresas para intensificar lo difícil que sería el proceso. Trabajamos en los importantes requisitos reunidos en aproximadamente 30 días para brindar un borrador del núcleo de la Interfaz de Usuario para los interesados de la Gerencia Media que tenían una supervisión diaria del sistema antes de llevarlo a la Junta del Proyecto para continuar trabajando en la transformación. Una vez que se realizaron los ajustes, se envió el proyecto al equipo de desarrollo para asegurar que las sugerencias fueran factibles—y por supuesto—siempre surgen cosas cuando la mezcla de la galleta está en el tazón. El equipo de desarrollo dirigido por Paul Shave observó y señaló como podíamos hacer ajustes.
En un inicio nos enfocamos en intentar trazar una visión general del sistema (lo cual abandonamos dado que el sistema estaba establecido y no buscábamos hacer ninguna mejora en la lógica empresarial en segundo plano). Además, el sistema era particularmente amplio, y consideramos que tenía poco valor para brindar una visión general del sistema. Hemos detectado que a menudo, los servicios pueden ser vendidos como proyectos que son importantes, pero que pueden ser completados por el personal interno con las habilidades apropiadas en conjunto con el desarrollo de un nuevo producto. De esta forma, los recursos se emplean mejor para el cliente. El aspecto más desafiante de este proyecto fue por supuesto, adentrarnos y alcanzar rápidamente la velocidad del dominio, absorbiendo los nuevos términos del glosario, comprendiendo la lógica empresarial detrás del sistema y uniendo como eso podría tener un impacto en la nueva Interfaz de Usuario.
Resumen
Nunca se lleva a cabo la Experiencia de Usuario aislada de los aspectos empresariales, especialmente en el ambiente corporativo. Ya se había dedicado una cantidad considerable de trabajo etnográfico en la comprensión del rol de los consultores de sistemas en términos de incrementación de la productividad y la maximización de la conservación de consultores. Mientras que se plantearon diferentes cuestiones en términos del desarrollo de prácticas operacionales óptimas, la interfaz GUI basada en Windows proporcionada era bienvenida por el personal existente y al parecer produjo un aumento en el compromiso de los consultores con el negocio en general. Quizás la percepción del sistema mejorado también facilitaría el trabajo diario del consultor (lo que era parte de la misión, así como la mejora de la habilidad para generar informes del sistema) ayudó a que se haga realidad esa posibilidad.
Paul Shave dirigió el equipo de desarrollo en el proyecto Remedi.
Si busca perfeccionar su informe y mejorar la competitividad de sus productos al mejorar sus Experiencias de Usuario, comuníquese con nosotros y trabajaremos con usted y su equipo para cumplir sus objetivos.
Publicado después para que coincida con el plazo del proyecto.
Ahora Remedi es parte del Simplyhealth Group.