Propuesta de una arquitecturaempresarial para una empresa de salud
Item Type info:eu-repo/semantics/bachelorThesis
Authors Mendoza Zurita, Jorge Ruben; Mendizabal Pizarro, OswaldoChristian
Citation [1] M. Pizarro and O. Christian, “Propuesta de una arquitecturaempresarial para una empresa de salud,” Universidad Peruanade Ciencias Aplicadas (UPC), Lima, Perú, 2017.
Publisher Universidad Peruana de Ciencias Aplicadas (UPC)
Rights info:eu-repo/semantics/openAccess
Download date 25/06/2022 04:42:02
Item License http://creativecommons.org/licenses/by-nc-sa/4.0/
Link to Item http://hdl.handle.net/10757/623023
UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS
FACULTAD DE INGENIERÍA
DIVISIÓN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS
CARRERA DE INGENIERÍA SISTEMAS EPE
PROPUESTA DE UNA ARQUITECTURA
EMPRESARIAL PARA UNA EMPRESA DE SALUD
PROYECTO PROFESIONAL
Para optar por el título profesional de Ingeniero de Sistemas
AUTOR
MENDOZA ZURITA, JORGE RUBEN – 0000-0003-0884-9108
MENDIZABAL PIZARRO, OSWALDO CHRISTIAN – 0000-0003-2978-8519
ASESOR
LÓPEZ PÉREZ SAMANTHA DEL CARMEN - 0000-0003-3707-4698
SUBAUSTE OLIDEN DANIEL ALEJANDRO - 0000-0003-1131-1384
Lima, Noviembre de 2017
DEDICATORIA
El presente trabajo está dedicado a mi familia que son la motivación más
grande que tengo y me apoya a cumplir todas mis metas.
Oswaldo Mendizabal
El presente trabajo està dedicado a mis padres por su incanzable apoyo y
dedicación y a Mirella por la fortaleza y aprendizaje que me enseñaste.
Jorge Mendoza
3
AGRADECIMIENTOS
Agradecemos a nuestros profesores que formaron parte de nuestra formación profesional por
habernos brindado mucha dedicación y profesionalismo durante toda la carrera.
4
RESUMEN
El presente trabajo presenta y desarrolla el diseño de una arquitectura empresarial para el
proceso core Banco de sangre de la clínica Delgado perteneciente a la red de clínicas del
grupo Auna. El objetivo es identificar las brechas que se tienen para lograr alinear los
objetivos estratégicos de la organización con los objetivos de TI, para ello se realizará el
análisis actual del proceso a través del marco de trabajo TOGAF, luego se identifican los
problemas y puntos de mejora orientados a satisfacer los objetivos estratégicos de la
organización. En base a este análisis, se plantea una serie de proyectos de TI que permitan
mejorar el proceso y contribuyan de los objetivos de la organización. Asimismo, se plantea la
aplicación de las metodologias ágiles para el desarrollo de aplicaciones, con el fin de
potenciar las fortalezas del equipo de TI y mejorar sus debilidades a través de dinámicas y
herramientas que permitan mejorar la productividad y calidad de las aplicaciones.
La estructura del trabajo profesional contempla 4 capítulos, el primer capítulo presenta el
marco teórico del trabajo en donde se describen los conceptos fundamentales de las
tecnologías y métodos utilizados para el desarrollo del trabajo. En el capítulo 2 se desarrolla
la aplicación de arquitectura empresarial sobre el objeto de estudio aplicando como referencia
el marco de trabajo TOGAF. En el siguiente capítulo del trabajo describe el planteamiento de
los proyectos derivados del análisis de arquitectura empresarial utilizando la el marco de
trabajo SCRUM. En el último capítulo presenta la estructura de la prospuesta de solución que
se da en base al análisis de los capítulos anteriores.
Las propuestas desarrolladas en este trabajo profesional permitirán optimizar los sub procesos
de donación y transfusión de sangre a través de proyectos que contribuyan al logro de los
objetivos estratégicos y brinde una ventaja competitiva al objeto de estudio.
5
TABLA DE CONTENIDO
INTRODUCCIÓN ................................................................................................................... 14
CAPÍTULO 1: FUNDAMENTOS TEÓRICOS ...................................................................... 16
1.1 MARCO TEÓRICO................................................................................................. 16
1.2 OBJETO DE ESTUDIO ................................................................................................ 54
1.2.1 ORGANIZACIÓN OBJETIVO. ............................................................................. 54
1.3 MISIÓN ......................................................................................................................... 56
1.4 VISIÓN .......................................................................................................................... 56
1.5 OBJETIVOS ESTRATÉGICOS .................................................................................... 56
1.6 MAPA DE PROCESOS DE LA CLINICA DELGADO .............................................. 58
1.6.1 DESCRIPCIÓN DE LOS PROCESOS DE LA CLÍNICA DELGADO ................ 59
1.6.2 MATRIZ DE PROCESOS DE NEGOCIO VS OBJETIVOS DE NEGOCIO ...... 67
1.6.3 ROLES DE NEGOCIO........................................................................................... 70
1.7 ORGANIGRAMA ......................................................................................................... 74
1.7.1 ORGANIGRAMA GENERAL DE LA RED AUNA ............................................ 74
1.7.2 ORGANIGRAMA DE LA CLÍNICA DELGADO ................................................ 75
1.7.3 ORGANIGRAMA DE LA GERENCIA DE LA DIVISIÓN DE TECNOLOGÍAS
DE INFORMACIÓN ....................................................................................................... 76
1.8 ALCANCE DEL PROYECTO ...................................................................................... 77
1.9 OBJETIVOS DEL PROYECTO ................................................................................... 78
1.9.1 OBJETIVO GENERAL. ......................................................................................... 78
1.9.2 OBJETIVOS ESPECÍFICOS.................................................................................. 78
1.10 BENEFICIOS DEL PROYECTO................................................................................ 79
1.10.1 BENEFICIOS TANGIBLES ................................................................................ 79
1.10.2 BENEFICIOS INTANGIBLES. ........................................................................... 79
CAPÍTULO 2: ARQUITECTURA EMPRESARIAL ............................................................. 80
2.1 INTRODUCCIÓN ......................................................................................................... 80
2.2 ALCANCE ..................................................................................................................... 80
2.3 PRELIMINAR ............................................................................................................... 82
2.3.1 PRINCIPIOS DE ARQUITECTURA .................................................................... 82
2.3.2 PETICIÓN DE TRABAJO DE ARQUITECTURA............................................... 85
6
2.4 VISIÓN DE LA ARQUITECTURA ............................................................................. 88
2.4.1 DECLARACIÓN DE TRABAJO DE ARQUITECTURA .................................... 88
2.4.2 VISIÓN DE LA ARQUITECTURA ...................................................................... 94
2.5 DOCUMENTO DE DEFINICIÓN DE LA ARQUITECTURA ................................... 97
2.5.1 ALCANCE .............................................................................................................. 97
2.5.2 METAS OBJETIVOS Y LIMITACIONES ........................................................... 97
2.5.3 PRINCIPIOS DE ARQUITECTURA .................................................................... 99
2.5.4 ARQUITECTURA LINEA BASE (AS IS) .......................................................... 103
2.5.5 FUNDAMENTO Y JUSTIFICACIÓN DEL ENFOQUE ARQUITECTÓNICO 138
2.5.6 ARQUITECTURA DESTINO (TO BE) .............................................................. 139
2.5.7 ANÁLISIS DE BRECHAS................................................................................... 159
2.5.8 EVALUACIÓN DEL IMPACTO......................................................................... 174
2.9 OPORTUNIDADES Y SOLUCIONES ...................................................................... 176
2.9.1 PLAN DE IMPLEMENTACIÓN Y MIGRACIÓN ............................................. 176
2.10 CONCLUSIONES ..................................................................................................... 181
CAPÍTULO 3. MÉTODOS ÁGILES PARA EL DESARROLLO DE SOFTWARE .......... 182
3.1 INTRODUCCIÓN ....................................................................................................... 182
3.2 OBJETIVOS ................................................................................................................ 182
3.3 IDENTIFICACIÓN DE FORTALEZAS Y DEBILIDADES ..................................... 184
3.3.1 OPORTUNIDADES ............................................................................................. 185
3.3.2 AMENAZAS ........................................................................................................ 185
3.3.3 FORTALEZAS ..................................................................................................... 185
3.3.4 DEBILIDADES .................................................................................................... 187
3.4 DIAGNÓSTICO DEL GRUPO ................................................................................... 188
3.4.1 PARA EL PROCESO DE DONACIÓN DE SANGRE ....................................... 189
3.4.2 PARA EL EQUIPO DE DESARROLLO............................................................. 190
3.5 IDENTIFICACIÓN DE LAS DINÁMICAS PROPUESTAS ..................................... 191
3.6 COMPOSICIÓN DE LOS GRUPOS DE TRABAJO ................................................. 195
3.6.1 COSTO DEL EQUIPO ......................................................................................... 198
3.7 DEFINICIÓN DE LAS HERRAMIENTAS A UTILIZAR ........................................ 200
3.7.1 SPRINT BACKLOG ............................................................................................ 200
3.7.2 PLANNING POKER ............................................................................................ 200
7
3.7.3 USER STORIES ................................................................................................... 201
3.7.4 CONCLUSIONES ................................................................................................ 214
CAPÍTULO 4: ESTRUCTURA PROPUESTA .................................................................... 216
4.1 PROPUESTA DE MEJORA DE LOS PROCESOS DE DONACIÓN DE SANGRE Y
TRANSFUSIÓN DE SANGRE PARA LA CLÍNICA DELGADO ................................. 216
4.1.1 OBJETIVOS DE LA PROPUESTA ..................................................................... 216
4.1.2 ALCANCE DE LA PROPUESTA ....................................................................... 216
4.1.3 IMPACTO EN LOS OBJETIVOS ESTRATÉGICOS ......................................... 219
4.1.4 PROBLEMÁTICA ............................................................................................... 222
4.1.5 PROPUESTA DE MEJORA ................................................................................ 223
CONCLUSIONES ................................................................................................................. 241
RECOMENDACIONES ........................................................................................................ 242
GLOSARIO DE TÉRMINOS................................................................................................ 243
SIGLARIO ............................................................................................................................. 244
REFERENCIAS BIBLIOGRÁFICAS................................................................................... 246
ANEXOS ............................................................................................................................... 250
8
LISTAS ESPECIALES
ÍNDICE DE FIGURAS
Figura 1: Alcance de las diferentes arquitecturas .................................................................... 20
Figura 2 - Evoución de los frameworks para arquitectura empresarial ................................... 22
Figura 3 - Forma abreviada del Zachman Framework for Enterprise Architecture ................ 23
Figura 4 - Matriz de Arquitectura Empresarial Extendido E2AF (2011) ................................ 26
Figura 5 - Enfoque Generar de la FEAF .................................................................................. 27
Figura 6 - Método TOGAF ...................................................................................................... 30
Figura 7 - Tácticas para implementar Scrum en proyectos ...................................................... 46
Figura 8 – Ciclo del proceso de SCRUM ................................................................................ 47
Figura 9 - Entornos descritos en el marco Cynefin.................................................................. 51
Figura 10 - Dominios de Cynefin ............................................................................................ 52
Figura 11 - Arquitectura Línea Base – Mapa de Procesos Clínica Delgado ........................... 58
Figura 12 - Organigrama General Red Auna ........................................................................... 74
Fuente: Elaboración propia ...................................................................................................... 74
Figura 13 - Organigrama de la Clinica delgado ....................................................................... 75
Figura 14 - Organigrama Específico de la Gerencia de TI ..................................................... 76
Figura 15 – Proceso de control de cambios de alcance ........................................................... 90
Figura 16 – Cronograma Tentativo .......................................................................................... 93
Figura16 - Arquitectura Empresarial/Organigrama General Red Auna ................................ 103
Figura 17- Arquitectura Línea Base – Mapa de Procesos Clínica Delgado .......................... 104
Fuente: Elaboración propia .................................................................................................... 104
Figura 18 – Arquitectura Línea Base - Modelo de datos de Negocio – Donación de Sangre122
Figura 19 - Arquitectura Línea Base – Diagrama de flujo de proceso de Registro Donación de
Sangre ............................................................................................................................ 123
Fuente: Elaboración propia .................................................................................................... 123
Figura 20 - Arquitectura Línea Base – Diagrama de flujo de proceso de Donación de Sangre
........................................................................................................................................ 124
Figura 21 - Arquitectura Línea Base – Diagrama de flujo Proceso Transfusión de Sangre .. 128
Figura 22 - Arquitectura Línea Base – Modelo Lógico del Proceso Transfusión de Sangre 132
Fuente: Elaboración propia .................................................................................................... 132
9
Figura 23 - Arquitectura Línea Base – Arquitectura de aplicaciones / Diagrama de
aplicaciones .................................................................................................................... 134
Fuente: Elaboración propia .................................................................................................... 134
Figura 24 - Arquitectura Línea Base – Arquitectura tecnológica / Diagrama de infraestructura
........................................................................................................................................ 136
Fuente: Elaboración propia .................................................................................................... 136
Figura 25 - Arquitectura Destino – Diagrama de flujo de proceso Generar Cita Donación .. 140
Figura 26 - Arquitectura Destino – Diagrama de flujo de proceso Donación de Sangre ...... 141
Figura 27 - Arquitectura Destino – Arquitectura de Negocio/ Flujo Transfusión de Sangre 142
Fuente: Elaboración propia .................................................................................................... 142
Figura 28 – Arquitectura destino – Modelo de datos de negocio – Donación de Sangre ...... 143
Figura 29 – Arquitectura destino – Modelo de datos de negocio – Transfusión ................... 144
Figura 30 - Arquitectura Destino – Modelo lógico del proceso de Donación de Sangre ...... 146
Figura 31 - Arquitectura Destino – Modelo lógico del proceso de Transfusión ................... 148
Fuente: Elaboración propia .................................................................................................... 148
Para la arquitectura de datos de este proceso se integrara con las siguientes tablas que
permitirá automatizar el envío y recepción de información asignado a un paciente para
su posterior tratamiento.................................................................................................. 149
Figura 32 - Arquitectura Destino – Arquitectura de Aplicaciones / Donación de Sangre ..... 151
Fuente: Elaboración propia .................................................................................................... 151
Figura 33 - Arquitectura Destino – Arquitectura de aplicaciones / Transfusión de sangre ... 153
Fuente: Elaboración propia .................................................................................................... 153
Figura 34 - Arquitectura Destino –Arquitectura Tecnológica / Donación de Sangre............ 155
Figura 35 - Arquitectura Destino –Arquitectura Tecnológica / Transfusión de Sangre ........ 157
Figura 36 - EDT ..................................................................................................................... 178
Figura 38 - Planning Poker Fuente ........................................................................................ 201
Figura 39 – Propuesta de mejora – Mapa de procesos de la Clínica Delgado ...................... 218
Figura 40 – Propuesta de mejora - Estadistica de donaciones y transfusiones de la Clínica
Delgado .......................................................................................................................... 223
Figura 41 – Propuesta de mejora – Diagrama de Implementación de proyectos................... 231
Figura 42 – Propuesta de mejora – Valores de Scrum ........................................................... 233
Figura 43 – Propuesta – Cronograma de ejecución proyectos de mejora .............................. 239
10
ÍNDICE DE TABLAS
Tabla 1 – Marcos de Trabajo de Arquitectura Empresarial ..................................................... 21
Tabla 2 - Visión de la arquitectura en TOGAF 9..................................................................... 31
Tabla 3 - Entradas y salidas en la visión de arquitectura TOGAF........................................... 32
Tabla 4 - Arquitectura de negocios en TOGAF 9 .................................................................... 33
Tabla 5 - Entradas y salidas en la Arquitectura de Negocios TOGAF 9 ................................. 34
Tabla 6 - Arquitectura de datos en TOGAF 9.......................................................................... 35
Tabla 7 - Entradas y salidas en la Arquitectura de Datos TOGAF 9 ....................................... 36
Tabla 8 - Arquitectura de Aplicación en TOGAF 9 ................................................................ 37
Tabla 9 - Entradas y salidas en la Arquitectura de Aplicación en TOGAF 9 .......................... 38
Tabla 10 - Arquitectura Tecnológica en TOGAF 9 ................................................................. 39
Tabla 11 - Entradas y salidas en la Arquitectura Tecnológica en TOGAF 9 .......................... 40
Tabla 12 - Arquitectura Tecnológica en TOGAF 9 ................................................................. 41
Tabla 13 - Entradas y salidas en la fase Oportunidades y Soluciones en TOGAF 9 ............... 42
Tabla 14 - Documentos que analizan la aplicación de la Arquitectura Empresarial en sistemas
de salud ............................................................................................................................ 44
Tabla 15 - Tabla Objetivos Estratégicos .................................................................................. 57
Tabla 16 - Listado de Procesos clínica Delgado ...................................................................... 59
Tabla 17 - Arquitectura Línea Base – Matriz Objetivos estratégicos vs Procesos – Parte 1 ... 67
Tabla 18 - Arquitectura Línea Base – Matriz Objetivos estratégicos vs Procesos - Parte 2 .... 68
Tabla 19 - Arquitectura Línea Base – Matriz Objetivos estratégicos vs Proceso – Parte 3 .... 69
Tabla 20 - Matriz de Asignación de Responsabilidades (RAM): A: Apoya, R: Registra y M:
Modifica ........................................................................................................................... 70
Tabla 21 - Cambios en las arquitecturas .................................................................................. 81
Tabla 22 - Arquitectura Empresarial/Tabla Objetivos Estratégicos ........................................ 86
Tabla 23 – Roles y responsabilidades ...................................................................................... 90
Fuente: Elaboración propia ...................................................................................................... 91
Tabla 24 – Entregables de la propuesta de arquitectura empresarial ....................................... 91
Tabla 25 – Lista de asuntos/escenarios .................................................................................... 95
11
Tabla 26 – Arquitectura Línea Base - Listado de Procesos clínica Delgado ......................... 105
Tabla 27 - Arquitectura Línea Base – Matriz Objetivos estratégicos vs Procesos – Parte 1 . 114
Tabla 28- Arquitectura Línea Base – Matriz Objetivos estratégicos vs Procesos – Parte 2 .. 115
Tabla 29 - Arquitectura Línea Base – Matriz Objetivos estratégicos vs Procesos – Parte 3 . 116
Tabla 30 – Arquitectura Línea Base - Matriz de Asignación de Responsabilidades (RAM): A:
Apoya, R: Registra y M: Modifica ............................................................................... 117
Tabla 31 - Arquitectura Línea Base – Entradas y Salidas de proceso Donación de sangre .. 125
Tabla 32 - Arquitectura Línea Base – Entradas y Salidas de proceso Transfusión de sangre
........................................................................................................................................ 129
Tabla 33 - Arquitectura Línea Base – Descripcion Modelo Lógico ..................................... 133
Tabla 34 - Arquitectura Línea Base – Arquitectura de aplicaciones / Componentes ............ 135
Tabla 35 - Arquitectura Línea Base – Arquitectura Tecnológica/ Componentes de
Infraestructura ................................................................................................................ 137
Fuente: Elaboración propia .................................................................................................... 137
Tabla 36 - Arquitectura destino – Descripcion Modelo Lógico ........................................... 147
Tabla 37 - Arquitectura destino – Descripcion Modelo Lógico Transfusiones .................... 149
Tabla 38 - Arquitectura Línea Base – Arquitectura de Aplicaciones / Donación de Sangre . 152
Fuente: Elaboración propia .................................................................................................... 154
Tabla 40 - Arquitectura Destino – Arquitectura Tecnológica / Donación de Sangre ............ 156
Tabla 41 - Arquitectura Destino – Arquitectura Tecnológica / Transfusión de Sangre ........ 158
Fuente: Elaboración propia .................................................................................................... 158
Tabla 42 - Análisis de Brechas / Arquitectura de Negocio / Donación de Sangre ............... 160
Tabla 43 - Análisis de Brechas / Arquitectura de Negocios / Transfusión de Sangre ......... 162
Tabla 44 – Análisis de Brechas / Arquitectura de Datos / Donación de Sangre .................. 164
Tabla 45 – Análisis de Brechas / Arquitectura de Datos / Transfusión de Sangre – Parte 1
........................................................................................................................................ 165
Tabla 46 – Análisis de Brechas / Arquitectura de Datos / Transfusión de Sangre – Parte 2
........................................................................................................................................ 166
Fuente: Elaboración propia .................................................................................................... 166
Tabla 47 - Análisis de Brechas / Arquitectura de Aplicaciones / Donación de Sangre ........ 167
Tabla 48 - Análisis de Brechas / Arquitectura de Tecnológica / Donación de Sangre – Parte
1...................................................................................................................................... 168
12
Tabla 49 - Análisis de Brechas / Arquitectura de Tecnológica / Donación de Sangre – Parte
3...................................................................................................................................... 169
Tabla 50 - Análisis de Brechas / Arquitectura de Tecnológica / Transfusión de Sangre –
Parte 1 ............................................................................................................................ 170
Tabla 51 - Análisis de Brechas / Arquitectura de Tecnológica / Transfusión de Sangre –
Parte 2 ............................................................................................................................ 171
Tabla 52 – Valores para Probabilidad e Impacto ................................................................... 174
Tabla 53 – Matriz de Probabilidad e Impacto (escala relativa) ............................................. 174
Tabla 54 – Matriz de Análisis de riesgos ............................................................................... 175
Tabla 55 - Cuadro resumen de implementación .................................................................... 179
Tabla 56 - Matriz Análisis FODA ......................................................................................... 184
Tabla 57 - Composición de los grupos de trabajo .................................................................. 195
Tabla 58 - Costos del grupo de trabajo propuesto ................................................................. 198
Fuente: Elaboración propia .................................................................................................... 199
Para mayor detalle de los costos revisar Anexo 2.................................................................. 199
Tabla 59 – Tabla de SCRUM................................................................................................. 200
Tabla 60 – Propuesta de mejora – Planteamiento Sprint 0 .................................................... 211
Tabla 61 – Propuesta de mejora - Matriz de procesos de negocio vs objetivos estratégicos –
Parte 1 ............................................................................................................................ 220
Tabla 62 – Propuesta de mejora - Matriz de procesos de negocio vs objetivos estratégicos –
Parte 2 ............................................................................................................................ 221
Tabla 63 – Propuesta de mejora – Resumen Arquitectura Empresarial ................................ 224
Tabla 64 – Propuesta de mejora – Matriz de trazabilidad Proyectos/Objetivos Estratégicos 227
Tabla 65 – Propuesta de mejora - Valores para Probabilidad e Impacto ............................... 229
Tabla 66 – Propuesta de mejora - Matriz de Probabilidad e Impacto (escala relativa) ......... 229
Tabla 67 – Propuesta de mejora – Matriz de Análisis de riesgos .......................................... 230
Tabla 68 – Propuesta de mejora – Roles grupo Scrum propuesto ......................................... 234
Tabla 69 – Propuesta de mejora – Tablas de costos de los proyecto ..................................... 237
Tabla 70 – Cuadro de estimación de costos - Anexo ............................................................. 251
Tabla 71 – Análisis de Brechas / Arquitectura de Negocio / Donación de Sangre - Anexo 253
Tabla 72 - Análisis de Brechas / Arquitectura de Negocios / Transfusión de Sangre - Anexo
........................................................................................................................................ 255
13
Tabla 73 – Análisis de Brechas / Arquitectura de Datos / Donación de Sangre - Anexo .... 257
Tabla 74 – Análisis de Brechas / Arquitectura de Datos / Transfusión de Sangre – Parte 1 -
Anexo ............................................................................................................................. 258
Tabla 75 – Análisis de Brechas / Arquitectura de Datos / Transfusión de Sangre – Parte 2 -
Anexo ............................................................................................................................. 259
Fuente: Elaboración propia .................................................................................................... 259
Tabla 76 - Análisis de Brechas / Arquitectura de Aplicaciones / Donación de Sangre – Anexo
........................................................................................................................................ 260
Tabla 77 - Análisis de Brechas / Arquitectura de Tecnológica / Donación de Sangre – Parte
1 - Anexo........................................................................................................................ 261
Tabla 78 - Análisis de Brechas / Arquitectura de Tecnológica / Donación de Sangre – Parte
3 - Anexo........................................................................................................................ 262
Tabla 79 - Análisis de Brechas / Arquitectura de Tecnológica / Transfusión de Sangre –
Parte 1 - Anexo .............................................................................................................. 263
Tabla 80 - Análisis de Brechas / Arquitectura de Tecnológica / Transfusión de Sangre –
Parte 2 - Anexo .............................................................................................................. 264
14
INTRODUCCIÓN
En la actualidad los avances tecnológicos han creado una brecha entre lo que el mercado y los
consumidores demandan, y aquello que las organizaciones pueden ofrecer. El principal
problema que enfrentan las organizaciones es el hecho de emprender una transformación de
sus sistemas de trabajo a nivel tecnológico, de proceso o de gestión integral. Para lograrlo, las
organizaciones definen sus objetivos estratégicos de negocio y estos en su mayoría son
soportados por las tecnologías de información, sin embargo la tecnología no siempre está
alineada con los objetivos estratégicos, esto ocasiona que las empresas sientan que sus
inversiones se vean desperdiciadas y no se perciba al área de tecnologías de información
como un socio estratégico que permita contribuir al logro de los objetivos.
El objeto de estudio es la Clínica Delgado que pertenece a la red Auna, una red de centros de
salud en constante crecimiento a nivel asistencial y técnico. Auna, tiene muy bien definido su
nicho de mercado y como no es ajena a los avances tecnológicos, esta debe estar prepara para
los cambios que los avances obliguen y poder posicionarse en el mercado a fin de brindar una
experiencia de calidad a sus pacientes.
Para poder brindar una experiencia en salud a sus clientes, este documento plantea una
propuesta de una arquitectura empresarial para el proceso de banco de sangre del objeto de
estudio, para ello se aborda el tema en 4 capítulos en donde se describe un marco teórico que
nos da una visión general de los conceptos utilizados en el desarrollo de este trabajo.
Asimismo se aplica el marco de trabajo TOGAF para realizar el procesos de arquitectura
empresarial, a través de todas las fases definidas en este marco de trabajo, se analiza el estado
actual de los procesos de Donación de Sangre y Transfusión de sangre que son parte del
alcance a través de los 4 dominios: Negocio, Datos, Aplicaciones y Tecnología TI y luego se
plantea un escenario deseado teniendo en cuenta de alinear las propuestas de mejora con los
objetivos estratégicos de la organización.
15
La finalidad de esta tesis es poder tener una visibilidad completa de la organización y
demostrar que la tecnología puede apoyar a lograr los objetivos organizacionales, asimismo
se genera un portafolio de proyectos que ayudarán a la organización a llegar al escenario
deseado en los sub procesos de transfusión y donación de sangre.
Actualmente las metodologías ágiles para el desarrollo de software han demostrado optimizar
y agilizar el ciclo de vida del software, por ello es que en este documento se plantea la
implementación del marco de trabajo SCRUM para el desarrollo de 2 aplicaciones que son
parte de la cartera de proyectos del análisis de brechas. Se eligió este marco de trabajo en
base al análisis de complejidad y de las fortalezas y debilidades del área de TI, esto con la
finalidad de poder entregar un producto que sea más acorde a las necesidades del usuario y
que brinde una ventaja a competitiva a la organización.
16
CAPÍTULO 1: FUNDAMENTOS TEÓRICOS
1.1 MARCO TEÓRICO
Las organizaciones hoy en día independientemente de su tamaño y del sector de sus
operaciones, están en la obligación de hacer frente a mercados competitivos para conseguir
la satisfacción de sus clientes bajo la óptica de eficiencia en sus actividades y operaciones. Es
por ello que toda organización se encuentra en la obligación de dedicar esfuerzos en la
optimización de sus procesos y recursos a través de la mejora e innovación en los estándares
y buenas prácticas, con lo cual se puede decir que la empresa asegura sus objetivos
estratégicos1.
Para podernos ubicar en un contexto apropiado sobre la definición de arquitectura
empresarial, primero se debe empezar a definir:
¿Qué es la arquitectura?
A la mayoría de las personas cuando se les menciona el término de “arquitectura”
inmediatamente transportan su imaginación hacia los modelos y planos de un inmueble.
Aunque en cierta manera esto forma parte del diseño, son en realidad parte de la arquitectura.
A la hora de crear cosas como casas, puentes, automóviles y softwares una de las tareas
principales es el diseño de aquel ente. Lamentablemente no hay una definición concreta de lo
que la arquitectura puede significar para el campo de las TI, sin embargo se puede citar
algunas definiciones de instituciones con la suficiente autoridad en el campo2.
1 CFR: Repositorio Académico UPC ( 2016) – Facultad De Ingeniería – Arquitectura Empresarial
17
En el específico desarrollo de softwares el Instituto de Ingeniería de Software (SEI) de la
Carnegie Mellon University define a la arquitectura como:
“la estructura de componentes de un programa/sistema, sus interrelaciones, principios y guías
para gobernar su diseño y evolución en el tiempo” (Clements 96).
Por otro lado, el IEEE, en el estándar ANSI / IEEE Std 1471 – 2000 (IEEE 2000) define a la
arquitectura como:
“La organización fundamental de un sistema, expresado en sus componentes, las relaciones
entre cada uno y el ambiente, y los principios que controlan su diseño y evolución”
- LA ARQUITECTURA EMPRESARIAL (AE)
Quienes toman decisiones en una organización requieren de información específica que sea
presentada en forma accesible para encarar el impacto de los cambios y desarrollos que se
implementan en una empresa.
En este capítulo se aborda la descripción y control de la organización la estructura, los
procesos, las aplicaciones, los sistemas, y tecnología de una manera integrada a través lo que
se conoce como Arquitectura Empresarial.
Específicamente se enfocará los métodos y técnicas para hacer por medio de la arquitectura
empresarial, la visualización de estos modelos para varios interesados y el análisis del
impacto de los cambios.
Definición de Arquitectura Empresarial
El concepto de arquitectura empresarial tiene su origen en el año de 1987 con la publicación
del artículo de J. Zachman en la revista IBM Systems. En ese documento, Zachman establece
tanto el desafío como la visión de la arquitectura empresarial, que servirá para orientarla
2 CFR: Club de Investigación Tecnológica ( 2008 ) : Arquitectura Empresarial
18
durante los siguientes años y hasta nuestros días. En esencia, el reto consistía en administrar
la creciente complejidad que representaba el surgimiento de los sistemas de información,
soportados en sistemas computacionales (Arango, Londoño y Zapata, 2010).
Se puede determinar que el concepto se consolidó en la década de los noventas y plantea un
acercamiento holístico para la gestión de una organización. La adopción de esta visión
integral cubre los procesos de negocio, los sistemas de información, los datos e información y
comprende además la infraestructura tecnológica (Goethals, Snoeck, Lemahieu y
Vandenbulcke, 2006).
La definición planteada resalta la importancia de la AE para el éxito de una organización y de
cómo se pueden plantear soluciones holísticas para resolver problemas de gestión de la
organización. En este sentido, Lankhorts et al. (2009) refieren que:
Enterprise architecture captures the essentials of the business, IT and its evolution. The idea is that the
essentials are much more stable than the specific solutions that are found for the problems currently at
hand. Architecture is therefore helpful in guarding the essentials of the business, while still allowing
for maximal flexibility and adaptivity. Without good architecture, it is difficult to achieve business
success (p. 3).
Otro concepto planteado es que la Arquitectura Empresarial es una práctica estratégica
continua dentro de la organización con objetivos bien definidos, que permite conectar todos
los componentes de una empresa, apalancándose en la tecnología. Para llevarla a cabo existen
diferentes marcos de trabajo o frameworks que ofrecen directrices y guías para el desarrollo e
implementación de estrategias de AE en las organizaciones (Gonzáles y Álzate, 2010).
La propuesta de esta nueva gestión no solo queda en la adopción de soluciones tecnológicas
sino que se integran otras variables.
La AE depende fundamentalmente de un enfoque multidisciplinario. En este sentido, “la
Arquitectura Empresarial es una forma de representación y desarrollo de la organización a
nivel de personas, procesos y recursos. Entre algunas de las áreas que, en el ámbito de la
19
práctica y la teoría han influenciado el surgimiento de la disciplina de la AE, se tienen: la
administración de negocios, la administración pública, la investigaciones de operaciones, la
sociología, la teoría organizacional, la teoría administrativa, las ciencias de la información,
las ciencias de la computación, etc.” (Bernard, 2005, citado por Londoño, 2014)
También debe tenerse en cuenta que con mucha frecuencia en cada unidad o dependencia de
una organización se establece un marco regulatorio que en muchos casos no es acorde con los
estándares de la entidad lo que provoca problemas en la gobernabilidad tecnológica, gastos
onerosos y altos riesgos en los cambios (Sandoval, Gálvez y Moscoso, 2017).
En relación a este problema, las empresas deben tomar en cuenta nuevas formas de
organización, por lo que debe optimizar los recursos, establecer políticas y mejores prácticas
con los clientes e incluso facilitar la interoperabilidad de las tecnologías de código abierto.
De acuerdo a los conceptos revisados se puede decir que la AE es una disciplina que integra
aspectos de negocio, estrategia, proceso, tecnologías, método y componentes desde diferentes
perspectivas. Por este motivo, Lagerström et al. (2011) asegura que estos enfoques deben
quedar plasmados las cuales están definidas y varían según los enfoques que se den a una
implementación de un modelo de Arquitectura Empresarial.
Sobre esta afirmación (Tremenco. 2007) propone las visiones arquitectónicas que representan
a toda la organización:
20
Figura 1: Alcance de las diferentes arquitecturas
Fuente: Tremenco (2007)
Los beneficios de la AE aplicada con éxito dentro de una organización incluyen los
siguientes:
Mejoras en el uso de TI para impulsar la adaptabilidad del negocio
Estrechar la brecha entre el personal de negocios y grupos de TI
Mayor concentración en las metas organizacionales
Reducción de la complejidad de los sistemas de TI existentes
Mayor agilidad en los sistemas de TI
Alineación entre TI y los requerimientos del negocio
Principios de Arquitectura Empresarial
Hay varias arquitecturas y marcos arquitectónicos en uso hoy en día para la implementación
de la AE. Aunque estos marcos pueden superponerse o abordar vistas similares, estos
enfoques se han diseñado para atender necesidades específicas. Estos marcos difieren según
las partes interesadas y del entorno en el cual se desenvuelven. Los problemas representan
métodos, vocabulario común, estándares y herramientas que proporcionan un medio para
implementar e integrar las soluciones a los inconvenientes.
21
Marcos (frameworks) para la implementación de la Arquitectura Empresarial
Schekkerman (2006, citado por Arango et al., 2010) elabora un listado de los principales
marcos empleados en la AE:
Tabla 1 – Marcos de Trabajo de Arquitectura Empresarial
Framework de descripción arquitectura empresarial
zACHMAN Zachman Framework for Enterprise
Architecture
(http://www.zifa.com/)
E2AF Extended Enterprise Architecture
Framework.
(http://www.enterprise-architecture.info/)
TOGAF The Open Group Architecture Framework
(http://www.opengroup.org/togaf/)
FEAF Federal Enterprise Architecture Framework. US.
(http://www.cio.gov)
BTEP GC Enterprise Architecture and Standards.
CANADÁ.
(http://www.tbs-sct.gc.ca/inf-inf/index_e.
asp)
Fuente: Arango (2010)
Sin embargo, existen otros marcos que han ido apareciendo en el tiempo para resolver
necesidades específicas de entidades guibernamentales y privadas.
Murillo (2016) establece una línea de tiempo que muestra la evolución de los frameworks:
22
Figura 2 - Evoución de los frameworks para arquitectura empresarial
Fuente: Murillo (2016, p. 17)
Zachman Framework for Enterprise Architecture
John Zachman publicó el Zachman Framework for Enterprise Architecture en 1987 y es
considerado como uno de los pioneros en la implementación de los frameworks en AE. De
acuerdo a este marco, el mayor alcance de diseño y niveles de complejidad para implementar
sistemas de información fuerzan al uso de alguna construcción lógica (o arquitectura).
El marco plantea una taxonomía arquitectónica, en otras palabra un esquema para organizar y
categorizar artefactos arquitectónicos (documentos de diseño, especificaciones y modelos)
que toma en consideración a quién está dirigido el artefacto como a cuál asunto particular
está siendo orientado. Esta taxonomía se sustenta en los principios de la arquitectura clásica
y se basa en seis perspectivas o puntos de vista: planificador, propietario, diseñador,
constructor, subcontratista y usuario.
La segunda dimensión del marco se basa en seis preguntas básicas: qué, cómo, dónde, quién,
cuándo y por qué. El marco no provee orientación sobre la secuencia, el proceso o
implementación, sino que se enfoca en garantizar que todas las visiones estén bien
23
establecidas, asegurando un completo sistema independientemente del orden en que se
encuentren establecidos.
La siguiente figura es una propuesta para representar el marco y sus variables:
Figura 3 - Forma abreviada del Zachman Framework for Enterprise Architecture
Fuente: Wikimedia Commons (2015)
Respecto a las preguntas, Gil (2011) explica en qué consiste cada una de las interrogantes:
¿Qué? – Inventory Sets
Describe las entidades involucradas en cada punto de vista de la empresa. Los
ejemplos incluyen los objetos de negocio, datos del sistema, las tablas relacionales,
las definiciones de campo.
¿Cómo?- Process Flow
Muestra las funciones dentro de cada perspectiva. Incluyen procesos de negocio,
la función de la aplicación de software, la función del hardware del equipo, y lazo de
control del lenguaje.
24
¿Dónde? – Distribution Networks
Muestra las localizaciones y las interconexiones dentro de la empresa. Esto incluye
lugares geográficos empresariales importantes, secciones separadas dentro de una red
logística, la asignación de los nodos del sistema, o incluso las direcciones de memoria
dentro del sistema.
¿Quién? – Responsability Assignments
Representa las relaciones de las personas dentro de la empresa. El diseño de la
organización empresarial tiene que ver con la asignación de trabajo y la estructura de
autoridad y responsabilidad. La dimensión vertical representa la delegación de
autoridad, y la horizontal representa la asignación de la responsabilidad
¿Cuándo? – Timing Cycles.
Representa el tiempo, o el caso de las relaciones que establecen los criterios de
rendimiento y los niveles cuantitativos de los recursos de la empresa. Esto es útil p ara
diseñar el programa maestro, la arquitectura de procesamiento, arquitectura de
control, y dispositivos de sincronización
¿Por qué? – Motivations Intentions
Describe las motivaciones de la empresa. Esto pone de manifiesto los objetivos de la
empresa y los objetivos, plan de negocios, la arquitectura del conocimiento, y el
diseño de los conocimientos
En relación a las filas, estas están representadas por los cambios que pueden ser perspectivas
y modelos. Las filas se representan mediante combinaciones perspectiva/modelo. El marco
presenta un sistema de clasificación para registrar diferentes puntos de vista en función de sus
roles. Las perspectivas y modelos son:
Perspectiva Ejecutiva/contexto de alcance.
Perspectiva de gestión de Negocio/conceptos de negocio.
Perspectiva de la Arquitectura/lógica del sistema.
Perspectiva de Ingeniero/tecnología física.
25
Perspectiva Técnica/componentes de la herramienta.
Perspectiva Empresarial/instancias de operación
E2AF. Extended Enterprise Architecture Framework
Si bien es cierto que es una metodología conocida su uso es poco empleado en el país de
acuerdo a la literatura revisada. Este marco según Morales (2010):
“…ha sido desarrollado por el Instituto para el Desarrollo de Arquitecturas Empresariales (The
Institute For Enterprise Architecture Developments (IFEAD)). E2AF desarrolla tres principales
elementos de una manera holística: el elemento de construcción, el elemento de función y el elemento
de estilo. El estilo refleja la cultura, valores, normas y principios de una organización” (p. 19).
E2AF comprende tres elementos principales de una manera holística: el elemento de
construcción, el elemento de función y el elemento de estilo. El estilo refleja la cultura,
valores, normas y principios de una organización. Generalmente, el término de arquitectura
empresarial tiene que ver con los elementos de construcción y función sin tomar en cuenta el
aspecto del estilo. El estilo está asociado al comportamiento organizacional, valores, normas
y principios de una organización de tal manera que se refleje en sus valores corporativos
(Granja y Vallejo, 2015).
El mismo autor propone una figura donde se expresa la matriz referida a este marco:
26
Figura 4 - Matriz de Arquitectura Empresarial Extendido E2AF (2011)
Fuente: Granja y Vallejo (2015, p.54)
La matriz tiene el propósito de comunicar los aspectos arquitectónicos a los stakeholders.
Intenta responder al qué y cómo pero con un enfoque un poco más profundo y tecnificado, se
asume las modificaciones a las preguntas, de la siguiente manera:
¿por qué?: Considerando la visión, principios estratégicos, ambiente y alcance en un
nivel contextual
¿con quién?: Valor neto de las relaciones, cooperación, elementos de colaboración
dentro de un marco ambiental
¿qué?: Requerimientos y representaciones ligadas al plano conceptual
¿cómo?: Un análisis a nivel lógico de las representaciones lógicas
¿con quién?: Representación de las soluciones en el marco físico
¿cuándo?: Análisis ambiental en el plano transformacional
El marco busca determinar que el nivel de arquitectura empresarial se busca agregar valores a
las áreas que están direccionadas dentro del enfoque específico (negocios, información, etc.)
y se las cubrirá totalmente, mediante la utilización de un estándar el IEEE 1471-2000
(Román, 2011).
27
FEAF. Federal Enterprise Architecture Framework
El Marco de Arquitectura Empresarial Federal (FEAF) fue establecido en 1999 por los
directores de informática del gobierno federal de EE.UU. (Chiefs of Information Officers).
Su propósito es facilitar el desarrollo compartido de procesos e información comunes entre
las agencias federales y otras agencias gubernamentales (Federal Government of the United
States, 2013).
La meta del marco es mejorar la interoperabilidad entre las agencias de gobierno
estadounidense mediante una arquitectura empresarial para todo el gobierno federal. Este
framework es de aplicabilidad obligatoria y cubre todas las organizaciones del gobierno
(Murillo, 2016).
Precisamente el Federal Government of the United States (2013) establece los principios de
este marco mediante el siguiente gráfico:
Figura 5 - Enfoque Generar de la FEAF
Fuente: Federal Government of the United States (2013)
28
La figura muestra que el marco es una colección de modelos de referencia interrelacionados,
que están diseñados para facilitar las definiciones de las funciones de negocio, así como el
análisis y la optimización de operaciones de tecnología de información de todas las entidades
federales.
Murillo (2015) agrega que
"...el FEAF permite integrar las arquitecturas, organizar y compartir información de las diferentes
organizaciones federales, las ayuda a desarrollar sus arquitecturas, a llevar a cabo en forma ágil sus
procesos relacionados con TI y a mejorar sus prácticas de gestión de tecnologías" (p. 28).
En conjunto, el marco comprende ocho componentes:
Arquitectura Drivers
Dirección Estratégica
Arquitectura de línea de base
Arquitectura Target
Procesos de Transición
Segmentos de arquitectura
Modelos arquitectónicos
Normas
BTEP. GC Enterprise Architecture and Standards
Respecto al marco se puede establecer que:
1) es el modelo de referencia más importante del gobierno canadiense y
2) es una metodología de transformación
En relación al primer punto, el marco involucra a un lenguaje común entre el gobierno
federal, provincial y municipal. También permite modelar o mapear como una unidad,
programa o proceso gubernamental funciona. Además, describe paso a paso el proceso
iterativo que produce visiones, estrategias, planes y estándares de utilidad. Estos procesos son
necesarios para planear e implementar cada proyecto. El marco ha servicio para iniciativas
29
gubernamentales clave para el gobierno de Canadá, en especial en el Programa de Seguridad
de Tecnología de la Información.
TOGAF. The Open Group Architecture Framework
El marco fue establecido por Open Group Architecture Framework (OGAF) no solo para
constituirse un framework genérico y metodología para el desarrollo de arquitecturas técnicas
sino también en un marco de arquitectura empresarial.
TOGAF tiene los siguientes componentes:
Capacidades de la organización para establecer la Arquitectura (Architecture
Capability Framework): orienta los procesos, capacidades, roles y responsabilidades en una
organización con el fin de que pueda establecer una arquitectura determinada.
Método de desarrollo de la Arquitectura Empresarial (Architecture Development
Method): provee la forma de trabajo para los arquitectos. Es considerado la parte central del
marco TOGAF y consiste de una aproximación cíclica del desarrollo de toda arquitectura
empresarial.
Artefactos de la arquitectura TOGAF (Architecture Content Framework): plantea el
entendimiento de un todo para implementar la arquitectura empresarial y está compuesta por
cuatro arquitecturas interrelacionadas: Arquitectura de Negocios, Arquitectura de Datos,
Arquitectura de Aplicaciones y Arquitectura de Tecnología de Información (TI).
Herramientas adecuadas para el desarrollo de la Arquitectura (The Enterprise
Continuum): comprende varios modelos de referencia como el Modelo de Referencia
Técnica, los Open Group's Standards Information Base (SIB), y los bloques base de
construcción (BBIB). La idea detrás de este componente es ilustrar como las arquitecturas
son desarrolladas a través de un continuum desde las arquitecturas fundacionales a través de
sistemas de arquitecturas comunes y arquitecturas de industrias hacia la arquitectura
empresarial propia de una organización. En la siguiente figura, se describe el método
TOGAF:
30
Figura 6 - Método TOGAF
Fuente: (The Open Group, 2009)
Una característica de TOGAF es que aquí no se solicita como requisito previo la finalización de
alguna de sus fases, es decir, las fases pueden terminar incompletas, saltadas, combinadas,
reorganizadas o reconfiguradas para adaptarse a las necesidades de una situación determinada
(Murillo 2015).
La práctica común es que TOGAF permita organizar un modelo de arquitectura que emplee
una estructura que se asemeja a los puntos de vista contenidos en el enfoque. En este caso,
TOGAF debe organizarse usando paquetes que representan estos puntos de vista. Por defecto,
los puntos de vista abarcan al menos las cuatro arquitecturas de la metodología: negocios,
aplicaciones, datos y tecnología.
31
La arquitectura de seguridad planteada por TOGAF es un diseño de seguridad coherente que
aborda los requisitos y, en particular, el riesgos de un ambiente / escenario particular y
específicos para establecer qué controles de seguridad deben aplicarse. El proceso de diseño
debe ser reproducible. Esta definición está destinada a especificar que la arquitectura es un
diseño y que tiene una estructura e interfaces entre los componentes.
Las arquitecturas planteadas por TOGAF
La fase preliminar
Como se muestra en la figura 6 en esta fase se debe definir y documentar reglas y seguridad
aplicables, además de los requisitos de políticas. En TOGAF 9, la norma ISO / IEC 17799:
2005 se utiliza para la formación de seguridad políticas. Para implementar estas políticas, hay
necesidad de identificar un arquitecto de seguridad en el equipo de arquitectura. Las
consideraciones de seguridad pueden entrar en conflicto con consideraciones funcionales y el
encargado de seguridad es requerido deberá asegurar que todos los problemas sean resueltos
sin conflicto de intereses. Si el modelo de negocio de la organización abarca un grupo de
otras organizaciones, deberá establecerse un marco común donde arquitectos de diferentes
organizaciones puedan desarrollar
interfaces y protocolos para el intercambio de seguridad información relacionada con la
entidad analizada federada, incluyendo la autenticación y autorización (Open Group, 2011).
La visión de arquitectura en TOGAF
De acuerdo a la versión 9 de TOGAF (2011) esta fase debe contemplar:
Tabla 2 - Visión de la arquitectura en TOGAF 9
Objetivos Pasos
Desarrollar una visión de alto nivel de las
capacidades y el valor de negocio que se
desean obtener.
Obtener la aprobación del desarrollo de la
arquitectura de la alta dirección
Establecer el proyecto de arquitectura
Identificar los stakeholders
Confirmar y elaborar los objetivos de negocio,
motivaciones y limitaciones
Evaluar las capacidades del negocio
32
Definir el alcance
Confirmar y elaborar principios de arquitectura y
del negocio
Desarrollar la visión de la arquitectura.
Definir las propuestas de valor, mas no obtenerla
por medio de las KPI, para validar el proyecto
Identificar los riesgos de la transformación del
negocio y las actividades de mitigación
Desarrollar la declaración de trabajo de
arquitectura, para obtener los respaldos necesarios
para la ejecución del trabajo.
Fuente: The Open Group, (2013)
En relación a las entradas y salidas esperadas en este proceso:
Tabla 3 - Entradas y salidas en la visión de arquitectura TOGAF
Entradas Salidas
Petición de trabajo de arquitectura
Principios, objetivos y motivaciones del negocio
Modelo organizacional de la AE
Marco de referencia de arquitectura adoptado.
Herramientas que servirán para el trabajo.
Repositorio de arquitectura llenado con la
documentación de la arquitectura existente
Declaración de trabajo de la arquitectura aprobada
Refinamiento de los principios, objetivos y
motivaciones de negocio
Principios de arquitectura
Evaluación de capacidades
Marco de referencia de arquitectura adaptado
Definición de arquitectura actual : Arquitecturas
de alto nivel (tecnológico, aplicación, datos y de
negocio)
33
Plan de comunicaciones
Fuente: The Open Group, (2013)
La arquitectura de negocios
Ayudar a localizar a los actores legítimos que harán interactuar el producto / servicio /
proceso. De igual modo, permite a la entidad establecer que las decisiones relativas a la
autorización se basarán sobre una gran comprensión de los usuarios y de los administradores
mediante sus capacidades y características esperadas. Debe tenerse en cuenta que los usuarios
no son humanos sino que son aplicaciones de software. Estos aplicativos, atendiendo a las
necesidades administrativas, como la copia de seguridad o los operadores, deben estar
basados en la lógica de los clientes de Internet.
La siguiente tabla muestra lo propuesto en esta fase por TOGAF 9:
Tabla 4 - Arquitectura de negocios en TOGAF 9
Objetivos Pasos
Desarrollar la Arquitectura de Negocio de Destino
describiendo cómo la empresa tiene que operar
para alcanzar los objetivos de negocio, responder a
las motivaciones estratégicas definidas en la
Visión de la Arquitectura y responder a la Petición
de Trabajo de Arquitectura y las preocupaciones
de los interesados.
Identificar componentes candidatos para el Plan de
Itinerario de Arquitectura basándose en las brechas
identificadas entre la Arquitectura de Negocio de
la Línea de Base y la Arquitectura de Negocio de
Destino.
Seleccionar modelos de referencia, Puntos de Vista
y herramientas.
Desarrollar la descripción de la Arquitectura de
Negocio de la Línea de Base.
Desarrollar la descripción de la Arquitectura de
Negocio de Destino.
Realizar un Análisis de Brechas
Definir los componentes candidatos del Plan de
Itinerario
Resolver los impactos al Panorama de
Arquitectura
Conducir una revisión formal con los interesados
34
Finalizar la Arquitectura de Negocio
Crear el Documento de Definición de
Arquitectura.
Fuente: The Open Group, (2013)
En relación a las entradas y salidas esperadas en este proceso:
Tabla 5 - Entradas y salidas en la Arquitectura de Negocios TOGAF 9
Entradas Salidas
Petición de trabajo de arquitectura
Principios,objetivos de negocio y motivaciones de
negocio
Evaluación de capacidades
Plan de comunicaciones
Modelo organizacional de AE
Framework de Arquitectura adaptado,
particularmente asociado al tamaño y topología de
la compañía
Declaración de trabajo de arquitectura aprobada
Principios de arquitectura y de negocio (Si existen)
Continuum de la empresa
Repositorio de Arquitectura
Requerimientos clave refinados
Declaración de Trabajo de Arquitectura,
actualizada si fuera necesario
Principios de negocio validados, objetivos de
negocio y motivaciones de negocio
Principios de arquitectura de negocio bien
elaborados Versión preliminar del
Documento de Definición de Arquitectura
conteniendo actualizaciones de contenido:
Arquitectura de Negocio de la Línea de Base
(detallada), si fuera apropiado
35
Fuente: The Open Group, (2013)
Arquitectura de sistemas de información
Esta fase aborda la documentación de la organización fundamental de los sistemas de
tecnología de información de una empresa, representada por los principales tipos de sistemas
de información y aplicaciones que los utilizan. En esta fase hay dos pasos que se pueden
desarrollar secuencialmente o en paralelo:
Arquitectura de datos
La tabla 6 muestra los aspectos que TOGAF contempla para este aspecto:
Tabla 6 - Arquitectura de datos en TOGAF 9
Objetivos Pasos
Desarrollar una Arquitectura de Datos de Destino
que sea funcional a la Arquitectura de Negocio y a
la Visión de Arquitectura, y que responda a la vez
a la Petición de Trabajo de Arquitectura y a las
preocupaciones de los interesados
Identificar los componentes candidatos que
podrían conformar el Plan de Itinerario de
Arquitectura basándose en las brechas
identificadas entre la Arquitectura de Datos de la
Línea de Base y la Arquitectura de Datos de
Destino.
Seleccionar modelos de referencia, Puntos de Vista y
herramientas
Desarrollar la descripción de la Arquitectura de Datos
de la Línea de Base
Desarrollar la descripción de la Arquitectura de Datos
de Destino Realizar un Análisis de Brechas
Definir los componentes candidatos que conforman el
Plan de Itinerario
Resolver los impactos al Panorama de Arquitectura
Conducir una revisión formal con los interesados
Finalizar la Arquitectura de Datos
Crear el Documento de Definición de Arquitectura.
Fuente: The Open Group, (2013)
36
En relación a las entradas y salidas esperadas en este proceso:
Tabla 7 - Entradas y salidas en la Arquitectura de Datos TOGAF 9
Entradas Salidas
Petición de Trabajo de Arquitectura
Evaluación de Capacidades
Plan de comunicaciones
Modelo Organizacional de Arquitectura
Empresarial
Marco de Referencia de Arquitectura
adaptado
Principios de Datos
Declaración de Trabajo de Arquitectura
Visión de la Arquitectura
Repositorio de Arquitectura
Versión preliminar del Documento de
Definición de la Arquitectura,
conteniendo:
Arquitectura de Negocio de la Línea de
Base (de alto nivel)
Declaración de Trabajo de Arquitectura,
actualizada si fuera necesario
Principios de datos validados o nuevos
principios de datos
Versión preliminar del Documento de
Definición de Arquitectura, conteniendo
actualizaciones de contenido:
Arquitectura de Datos de la Línea de Base
Arquitectura de Datos de Destino
Vistas de la Arquitectura de Datos
correspondiente a los Puntos de Vista
seleccionados
Fuente: The Open Group, (2013)
Arquitectura de aplicación
La tabla 8 muestra los aspectos que TOGAF contempla para este aspecto:
37
Tabla 8 - Arquitectura de Aplicación en TOGAF 9
Objetivos Pasos
Desarrollar una Arquitectura de
Aplicación de Destino que sea funcional
a la Arquitectura y a la visión de
Negocio y a la Visión de la Arquitectura,
y que responda a la vez a la Petición de
Trabajo de Arquitectura las
preocupaciones de los interesados
Identificar componenes candidatos del
Plan de Itinerario de Arquitectura
basándose en las brechas identificadas
entre la Arquitectura de Aplicación de la
Línea de Base y la Arquitectura de
Aplicación de destino
Seleccionar modelos de referencia,
puntos de vista y herramientas
Desarrollar la descripción de la
Arquitectura de Aplicación de la Línea
de Base
Desarrollar la descripción de la
Arquitectura de Aplicación de Destino
Realizar el Análisis de Brechas
Definir los componentes candidatos que
conforman el Plan de Itinerario
Resolver los impactos al Panorama de
Arquitectura
Conducir una revisión formal con los
interesados
Finalizar la Arquitectira de Aplicación
Crear el Documento de Definición de
Arquitectura
Fuente: The Open Group, (2013)
38
En relación a las entradas y salidas esperadas en este proceso:
Tabla 9 - Entradas y salidas en la Arquitectura de Aplicación en TOGAF 9
Entradas Salidas
Petición de trabajo de Arquitectura
Evaluación de capacidades
Plan de comunicaciones
Modelo organizacional de Arquitectura
empresarial
Marco de referencia de Arquitectura adaptado
Principios de Aplicación
Declaración de Trabajo de Arquitectura
Visión de la Arquitectura
Repositorio de Arquitectura
Documento preliminar de Definición de
Arquitectura, conteniendo:
Arquitectura de Negocio de la Línea de Base
(de alto nivel)
Arquitectura de Negocio de Destino (de alto
nivel)
Arquitectura de Datos de Destino (detallada o
de alto nivel)
Arquitectura de Datos de Aplicación de la
Línea de Base (de alto nivel)
Declaración de Trabajo de Arquitectura,
actualizado si fuera necesario
Principios de Aplicación validados o nuevos
principios de Aplicación
Documento preliminar de Definición de
Arquitectura, conteniendo actualizaciones de
contenido:
Arquitectura de Aplicación de la Línea de
Base
Arquitectura de Aplicación de Destino
Vistas de Arquitectura de Aplicación
correspondientes a Puntos de Vista
seleccionados que responden a las
preocupaciones clave de los interesados
Especificación preliminar de
Requerimientos de Arquitectura incluyendo
actualizaciones de contenido
Resultados del Análisis de Brechas
Requerimientos de interoperabilidad de
Aplicación
Fuente: The Open Group, (2013)
39
Arquitectura Tecnológica
Aborda la documentación de la organización esencial de sistemas de tecnología de
información, representada en hardware, software y tecnología de comunicaciones.
La tabla 10 muestra los aspectos que TOGAF contempla para este aspecto:
Tabla 10 - Arquitectura Tecnológica en TOGAF 9
Objetivos Pasos
Desarrollar la Arquitectura Tecnológica de
Destino de tal manera que permita que los
componentes lógicos y físicos de datos y
aplicaciones, así como aquellos de la Visión
de la Arquitectura, correspondan a la Petición
de Trabajo de Arquitectura y respondan a las
preocupaciones de los interesados
Identificar los componentes candidatos del
Plan de Itinerario de Arquitectura basándose
en las brechas identificadas entre la
Arquitectura Tecnológica de la Línea de Base
y la Arquitectura Tecnológica de Destino
Seleccionar modelos de referencia, Puntos
de Vista y herramientas
Desarrollar la descripción de la Arquitectura
Tecnológica de la Línea de Base
Desarrollar la descripción de la Arquitectura
Tecnológica de Destino
Realizar el Análisis de Brechas
Definir los componentes candidatos del Plan
de Itinerario
Resolver los impactos en el Panorama de
Arquitectura
Conducir una revisión formal con los
interesados
Finalizar la Arquitectura Tecnológica
Crear el Documento de Definición de
Arquitectura
Fuente: The Open Group, (2013)
40
En relación a las entradas y salidas esperadas en este proceso:
Tabla 11 - Entradas y salidas en la Arquitectura Tecnológica en TOGAF 9
Entradas Salidas
Petición de Trabajo de Arquitectura
Evaluación de Capacidades
Plan de comunicaciones
Modelo Organizacional de Arquitectura Empresarial
Marco de Referencia de Arquitectura adaptado
Principios de Tecnología
Declaración de Trabajo de Arquitectura
Visión de la Arquitectura
Repositorio de Arquitectura
Documento preliminar de Definición de Arquitectura,
conteniendo:
Arquitectura de Negocio de la Línea de Base (detallada)
Arquitectura de Negocio de Destino (detallada)
Arquitectura de Datos de la Línea de Base (detallada)
Arquitectura de Datos de Destino (detallada)
Arquitectura de Aplicación de la Línea de Base
(detallada)
Arquitectura de Aplicación de Destino (detallada)
Arquitectura Tecnológica de la Línea de Base (de alto
nivel)
Arquitectura Tecnológica de Destino (de alto nivel)
Declaración de Trabajo de Arquitectura,
actualizado si fuera necesario
Principios de Tecnología validados o nuevos
principios de Tecnología (si se generaron
aquí)
Versión preliminar del Documento de
Definición de Arquitectura, conteniendo
actualizaciones de contenido:
Arquitectura Tecnológica de la Línea de
Base Arquitectura Tecnológica de Destino
Vistas de Arquitectura Tecnológica
correspondientes a Puntos de Vista que han
sido seleccionados para responder a las
preocupaciones clave de los interesados
Especificación preliminar de los
Requerimientos de Arquitectura, incluyendo
actualizaciones de contenido:
Resultados del Análisis de Brechas
Requerimientos resultantes de las Fases B y
C Requerimientos de Tecnología
actualizados
Fuente: The Open Group, (2013)
41
Oportunidades y soluciones
Se refiere a la implementación. Describe el proceso de identificación de los medios de
entrega (proyectos, programas o carteras) que proporcionan la Arquitectura de Destino
identificada en las Fases anteriores.
La tabla 12 muestra los aspectos que TOGAF contempla para este aspecto:
Tabla 12 - Arquitectura Tecnológica en TOGAF 9
Objetivos Pasos
Generar la versión inicial y completa del
Plan de Itinerario de Arquitectura,
basándose en el Análisis de Brechas y en
los componentes candidatos del Plan de
Itinerario de Arquitectura resultantes de
las Fases B, C y D
Determinar si un enfoque incremental es
requerido, y si fuera así, identificar las
Arquitecturas de Transición que
proporcionarán valor continuo de negocio.
Determinar o confirmar atributos claves
para el cambio empresarial
Determinar limitaciones del negocio para
la implementación
Examinar y consolidar resultados de los
Análisis de Brechas realizados en las Fases
B a D
Examinar los requerimientos consolidados
entre funciones de negocio relacionadas
Consolidar y reconciliar los requerimientos
de interoperabilidad
Refinar y validar dependencias
Confirmar el Grado de Preparación y
riesgos para la transformación del negocio
Formular la estrategia de Implementación
y Migración
IdentifIcar y agrupar los paquetes de
trabajo principales.
Fuente: The Open Group, (2013)
42
En relación a las entradas y salidas esperadas en este proceso:
Tabla 13 - Entradas y salidas en la fase Oportunidades y Soluciones en TOGAF 9
Entradas Salidas
Información del producto
Petición de Trabajo de Arquitectura
Evaluación de Capacidades
Plan de comunicaciones Metodologías
de planifi cación
Modelos de gobierno y marcos de
referencia
Marco de Referencia de Arquitectura
adaptado
Declaración de Trabajo de Arquitectura
Visión de la Arquitectura
Repositorio de arquitectura
Declaración de Trabajo de Arquitectura,
actualizado si fuera necesario
Visión de la Arquitectura, actualizada si
es necesario
Versión preliminar del Documento de
Definición de Arquitectura, incluyendo:
Arquitectura de Transición, número y
alcance, si existe Versión preliminar de
la Especificación de Requerimientos de
Arquitectura, actualizada si fuera
Declaración de Trabajo de Arquitectura,
actualizado si fuera necesario
Principios de Aplicación validados o nuevos
principios de Aplicación
Documento preliminar de Definición de
Arquitectura, conteniendo actualizaciones de
contenido:
Arquitectura de Aplicación de la Línea de
Base
Arquitectura de Aplicación de Destino
Vistas de Arquitectura de Aplicación
correspondientes a Puntos de Vista
seleccionados que responden a las
preocupaciones clave de los
interesados
Especificación preliminar de
Requerimientos de Arquitectura incluyendo
actualizaciones de contenido
Resultados del Análisis de Brechas
Requerimientos de interoperabilidad de
Aplicación
43
necesario Evaluación de capacidades,
incluyendo:
Capacidades de Negocio
Capacidades de TI Versión preliminar
del Documento de Definición de la
Arquitectura Versión preliminar de la
Especificación de Requerimientos de
Arquitectura Solicitudes de Cambio a
los programas y proyectos existentes
Componentes candidatos del Plan de
Itinerario de Arquitectura resultantes de
las Fases B, C y D
Fuente: The Open Group, (2013)
Aplicaciones de TOGAF en sistemas de información relacionadas a la Salud
La versatibilidad de la metodología TOGAF permite que pueda ser empleado en cualquier
organización. Uno de estos campos de aplicación es el referido a los sistemas de información
en salud.
La integración de la Arquitectura Empresarial juega un papel muy importante en la
integración de los recursos de salud como el personal, la tecnología y el proceso de entrega
de atención médica. Sin embargo, enfrentan problemas de integración por el empleo de
diferentes infraestructuras de Tecnología de Información / Sistemas de Información. En
general, estos problemas de integración ocurren en dos niveles, incluido el nivel del proceso y
el nivel IT / IS (Sajid y Ahsan 2016).
En la siguiente tabla, se muestran trabajos que han analizado la aplicación de Arquitectura
Empresarial en sistemas de salud:
44
Tabla 14 - Documentos que analizan la aplicación de la Arquitectura Empresarial en sistemas
de salud
Referencia Sistema Uso
(Wolfram, D. A. 1995) INTERNIST–I Diagnóstico general de
problemas en medicina interna.
(Ato Ogoe, 2005) MYCIN Infecciones en la sangre
(Patrick Winston and Karen A.
Prendergast 1985)
CADUCEUS Diagnóstico de 1000
enfermedades
(Lemaire J. B., Schaefer J. P.
and Martin L. A., Faris P.
1999).
QMR–Quick Medical
Reference
Helps physicians to diagnose
adult diseases.
(Aikins, J. S., Kunz J. C.,
Shortliffe E. H., Fallat R. J.
1983)
PUFF–Pulmonary
Function
Enfermedades pulmonares
(K. Henriksen, et al., 2005 ) ATHENA Control de la presión arterial.
Recomienda una guía para la
elección de medicamentos.
(Morelli R. A., Bronzino J. D.
and Goethe J. W. 1987)
CEMS Sistema para la toma de
decisiones en salud mental
(Bury, M. Humber and
J. Fox. 2001)
ERA–Early Referrals
Application
Sistema web para la toma de
decisiones para el tratamiento del
cáncer
(Ato Ogoe, 2005) GIDEON–Gloabal
Infectious Disease
and Epidemiology
Network
Diagnóstico de enfermedades
infecciosas, enfermedades
tropicales, epidemiología,
microbiología y quimioterapia
antimicrobiana.
(K. Henriksen, et. al., 2005 ) PERFEX–Knowledge
Based Interpretation
of Myocardial
SPECT Imagery
Diagnóstico de enfermedades
cardíacas
Fuente: Ibid., p. 186.
¿’Sobre el tema, Hussein (2017) asegura que la arquitectura empresarial en los sistemas de
salud:
45
The EA approach -as a strategic and planning tool –for: – identifying the main HIS components, and –
modelling the HIS complex interrelated interactions into four architectural domains, namely: business,
application, data and technology architectural domains (p. 107).
Una forma de implementar tecnologías bajo el esquema de la Arquitectura Empresarial se
basa en el Cloud Computing. Una aplicación específica se ha hecho en un marco de un
Sistema de Monitoreo de Salud Móvil (SMSM) basado en la plataforma de computación en la
nube. Esta aplicación se propone para respaldar la monitorización remota de la salud, abordar
la integración e interoperación de datos de salud (por ejemplo, hospitales comunitarios y
hospitales integrales) con el objetivo de que médicos para examinar y tratar enfermedades
infecciosas complejas (Xu et al., 2015).
SCRUM
Concepto
Scrum es un enfoque ágil para desarrollar productos y servicios. El proceso comienza por
crear una acumulación de productos, una lista priorizada de características y otras
capacidades necesarias para desarrollar un producto exitoso. En este sentido, el método
también puede ser definido como “un proceso en el que se aplican de manera regular un
conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor
resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene
origen en un estudio de la manera de trabajar de equipos altamente productivos.” (Agiles,
2014).
La principal característica de Scrum es que facilita la formación de equipos de desarrollo que
están organizados e interrelacionados por el liderazgo y visión de un proyecto. A partir de
esto los elementos del proyecto se relacionan mediante la interdependencia y la comunicación
informal entre todos los involucrados para que puedan afrontar los cambios e imprevistos
originados en su gestión. Otra característica relevante es que el cliente tiene influencia
constante en la idea y en los cambios en el proyecto en relación a lo que se quiere y lo que se
necesita produciendo vínculos de trabajo y facilidad en la predicción en la entrega de un
46
producto confiable y de calidad. Ante estas características, Scrum se constituye como una
metodología pragmática asumiendo como primera instancia que la magnitud del problema no
puede ser completamente definido ni entendido sin responder de manera rápida y flexible los
requisitos emergentes.
Se debe tener en cuenta algunas tácticas para implementar de modo correcto la metodología
Scrum. La figura No. muestra que estrategias se deben seguir:
Figura 7 - Tácticas para implementar Scrum en proyectos
Fuente: Rey (2017)
El trabajo en sí se realiza en ciclos cortos de desarrollo llamados "iteraciones", que por lo
general toman un período de tiempo de una semana a un mes calendario de duración. Al
respecto, Mariño y Alfonzo (2014) refieren que:
“SCRUM es un marco de trabajo iterativo e incremental para el desarrollo de
proyectos y se estructura en ciclos de trabajo llamados Sprints. Éstos son iteraciones
de 1 a 4 semanas, y se suceden una detrás de otra. Al comienzo de cada Sprint, el
equipo multi-funcional selecciona los elementos (requisitos del cliente) de una lista
priorizada. Se comprometen a terminar los elementos al final del Sprint. Durante el
47
Sprint no se pueden cambiar los elementos elegidos. Al final del Sprint, el equipo lo
revisa con los interesados en el proyecto, y les enseña lo que han construido.” (p.
414).
La figura 8 refleja el ciclo mencionado:
Figura 8 – Ciclo del proceso de SCRUM
Fuente: Duro (2015)
Los procesos mostrados en la figura No. son descritos por Schwaber y Sutherland (2013):
Product Backlog: La Lista de Producto es una lista ordenada de todo lo que podría ser
necesario en el producto, y es la única fuente de requisitos para cualquier cambio a
realizarse en el producto. El Dueño de Producto (Product Owner) es el responsable
de la Lista de Producto, incluyendo su contenido, disponibilidad y ordenación. Una
48
Lista de Producto nunca está completa. El desarrollo más temprano de la misma solo
refleja los requisitos conocidos y mejor entendidos al principio. La Lista de Producto
evoluciona a medida de que el producto y el entorno en el que se usará también lo
hacen. La Lista de Producto es dinámica; cambia constantemente para identificar lo
que el producto necesita para ser adecuado, competitivo y útil. Mientras el producto
exista, su Lista de Producto también existe. La lista además enumera todas las
características, funcionalidades, requisitos, mejoras y correcciones que constituyen
cambios a ser hechos sobre el producto para entregas futuras.
Sprint: es un bloque de tiempo (time-box) de un mes o menos durante el cual se crea
un incremento de producto “Terminado”, utilizable y potencialmente desplegable. Es
más conveniente si la duración de los Sprints es consistente a lo largo del esfuerzo de
desarrollo. Cada nuevo Sprint comienza inmediatamente después de la finalización
del Sprint previo. Los Sprints contienen y consisten de la Reunión de Planificación
del Sprint (Sprint Planning Meeting), los Scrums Diarios (Daily Scrums), el trabajo de
desarrollo, la Revisión del Sprint (Sprint Review), y la Retrospectiva del Sprint
(Sprint Retrospective). Durante el Sprint:
o No se realizan cambios que puedan afectar al Objetivo del Sprint (Sprint
Goal);
o Los objetivos de calidad no disminuyen; y,
o El alcance puede ser clarificado y renegociado entre el Dueño de Producto y el
Equipo de Desarrollo a medida que se va aprendiendo más.
Sprint planning: Este plan se crea mediante el trabajo colaborativo del Equipo Scrum
completo. La Reunión de Planificación de Sprint tiene un máximo de duración de
ocho horas para un Sprint de un mes. Para Sprints más cortos, el evento es usualmente
más corto. El Scrum Master se asegura de que el evento se lleve a cabo y que los
asistentes entiendan su propósito. El Scrum Master enseña al Equipo Scrum a
mantenerse dentro del bloque de tiempo. La Reunión de Planificación de Sprint
responde a las siguientes preguntas: ¿Qué puede entregarse en el Incremento
resultante del Sprint que comienza?, ¿Cómo se conseguirá hacer el trabajo necesario
para entregar el Incremento?
49
Daily Scrum: es una reunión con un bloque de tiempo de 15 minutos para que el
Equipo de Desarrollo sincronice sus actividades y cree un plan para las siguientes 24
horas. Esto se lleva a cabo inspeccionando el trabajo avanzado desde el último Scrum
Diario y haciendo una proyección acerca del trabajo que podría completarse antes del
siguiente. El Scrum Diario se realiza a la misma hora y en el mismo lugar todos los
días para reducir la complejidad. Durante la reunión, cada miembro del Equipo de
Desarrollo explica: ¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el
Objetivo del Sprint?, ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el
Objetivo del Sprint?, ¿Veo algún impedimento que evite que el Equipo de Desarrollo
o yo logremos el Objetivo del Sprint?
Sprint Review: Al final del Sprint se lleva a cabo una Revisión de Sprint para
inspeccionar el Incremento y adaptar la Lista de Producto si fuese necesario. Durante
la Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que se
hizo durante el Sprint. Basándose en esto, y en cualquier cambio a la Lista de
Producto durante el Sprint, los asistentes colaboran para determinar las siguientes
cosas que podrían hacerse para optimizar el valor. Se trata de una reunión informal,
no una reunión de seguimiento, y la presentación del Incremento tiene como objetivo
facilitar la retroalimentación de información y fomentar la colaboración. Se trata de
una reunión restringida a un bloque de tiempo de cuatro horas para Sprints de un mes.
Para Sprints más cortos, se reserva un tiempo proporcionalmente menor. El Scrum
Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su
propósito. El Scrum Master enseña a todos a mantener el evento dentro del bloque de
tiempo fijado. La Revisión de Sprint incluye los siguientes elementos:
o Los asistentes son el Equipo Scrum y los interesados clave invitados por el
Dueño de Producto;
o El Dueño de Producto explica qué elementos de la Lista de Producto se han
“Terminado” y cuales no se han “Terminado”;
o El Equipo de Desarrollo habla acerca de qué fue bien durante el Sprint, qué
problemas aparecieron y cómo fueron resueltos esos problemas;
50
o El Equipo de Desarrollo demuestra el trabajo que ha “Terminado” y responde
preguntas acerca del Incremento;
o El Dueño de Producto habla acerca de la Lista de Producto en el estado actual.
Proyecta fechas de finalización probables en el tiempo basándose en el
progreso obtenido hasta la fecha (si es necesario);
o El grupo completo colabora acerca de qué hacer a continuación, de modo que
la Revisión del Sprint proporcione información de entrada valiosa para
Reuniones de Planificación de Sprints subsiguientes.
Sprint Backlog: La Lista de Pendientes del Sprint es el conjunto de elementos de la
Lista de Producto seleccionados para el Sprint, más un plan para entregar el
Incremento de producto y conseguir el Objetivo del Sprint. La Lista de pendientes del
Sprint es una predicción hecha por el Equipo de Desarrollo acerca de qué
funcionalidad formará parte del próximo Incremento y del trabajo necesario para
entregar esa funcionalidad en un Incremento “Terminado”. La Lista de Pendientes del
Sprint hace visible todo el trabajo que el Equipo de Desarrollo identifica como
necesario para alcanzar el Objetivo del Sprint.
Según Rubin (2012), Scrum se enfoca en ofrecer trabajo, integrado y probado a las
funciones de valor empresarial mediante iteraciones que conducen a resultados rápidos.
Scrum es también adecuado para ayudar a las organizaciones a tener éxito en un mundo
complejo en el que es necesario una rápida adaptación basada en las acciones
interconectadas de clientes, usuarios, desarrolladores, patrocinadores y otras partes
interesadas. Sin embargo, la metodología no es la solución adecuada en todas las
circunstancias. Ante las complejidades se requiere de un marco que permita enfrentar
estas situaciones.
En este sentido existe el marco Cynefin que permita a las organizaciones superar los
problemas presentados en tales situaciones.
51
Cynefin
Guillén (2013) sostiene que el nombre de Cynefin es una palabra galesa cuya traducción
literal al inglés es hábitat. El origen de este marco se da para ayudar a las organizaciones en
el desarrollo de la autoconciencia y mejorar la capacidad para describir la ecología en la que
las organizaciones trabajan (Snowden, 2000)
El marco fue desarrollado por Davw Snowden en 1999, dentro de la compañía IBM, como
una forma de gestionar el capital intelectual en esa compañía. En el año 2003, Snowden junto
a Kurtz publicaron un artículo titulado The new dynamics of strategy: Sense-making in a
complex and complicated world donde hacen una descripción más completa del marco. Este
marco compara las características de cinco tipos de entornos a los que llama dominios de
complejidad conformados por el simple, caótico, complejo, complicado y desordenado.
Estos entornos se explican en la Figura 9:
Figura 9 - Entornos descritos en el marco Cynefin
Fuente: Venturo (2017)
La figura descrita abarca la comprensión de dos grandes dominios y un área central, el
trastorno, con el que se reconoce que la incertidumbre puede estar presente en ellos. Kurtz y
Snowden (2003) explican que a la derecha de la descripción está el dominio más importante,
el orden, aquel que está entre lo que se puede usar inmediatamente (lo conocido) y el que
requiere tiempo y energía para hallarlo -lo desconocido- del lado izquierdo, el dominio del
52
desorden, distinciones entre lo que se puede poner como patrón -lo complejo- y lo que se
necesita estabilizar para que los patrones emerjan -lo caótico-.
La Figura 10 describe con mayor precisión lo descrito:
Figura 10 - Dominios de Cynefin
Fuente: Kurtz y Snowden (2003)
Dominios de Cynefin
Dominio Simple
Se considera que en este dominio existen las mejores prácticas ya que las soluciones son
conocidas por todos. Aquí también se opera con problemáticas simples porque es fácil la
identificación de causas y efectos. Se sigue una serie lógica de pasos y se ejecutan de manera
53
repetitiva, una y otra vez. Como ejemplos de este dominio tenemos la construcción en serie
de un mismo producto o la instalación en muchos clientes de un mismo sistema.
Dominio Complicado
En este dominio se manifiestan problemas complejos, buenas prácticas y perfiles expertos.
Ya no hay una solución sino múltiples soluciones correctas para una misma problemática por
lo que se requiere del involucramiento de expertos para poder identificarlas. Como ejemplo
de este escenario tenemos la solución de un problema de performance en un software o base
de datos, la sincronización de semáforos en un cruce de varias avenidas, la búsqueda de
eficiencia en la distribución logística de mercaderías, entre otros
Dominio Complejo
La complejidad de los problemas provoca mayor impredictibilidad. En este entorno no
existen ni mejores ni buenas prácticas catalogadas para las situaciones. Para este caso se
necesita un examen de los resultados y la posterior adaptación. Este es el dominio de las
prácticas emergentes. Las soluciones halladas por lo general no son replicables, con los
mismos resultados, a otros problemas similares. Se requiere de experimentación y de bajo
impacto para los fallos. Es también en este entorno donde se requiere de niveles altos de
creatividad, innovación, interacción y comunicación.
Dominio Caótico
Los problemas presentados en este dominio demandan de una respuesta inmediata. Este
dominio refleja la crisis que enfrenta una organización por que la actuación inmediata debe
provocar cierto orden. En este dominio no se puede emplear Scrum porque se requiere de la
improvisación para tomar el control y sacar a la organización fuera del caos.
Dominio Desordenado
Este dominio se genera en las organizaciones cuando no saben dónde están. Es considerado
como una zona peligrosa porque no se puede medir las situaciones ni determinar la forma de
actuar. En este entorno, los especialistas interpretan situaciones y actúan en base a sus
preferencias personales. Lo recomendable es que buscar un dominio identificado para luego
diseñar la manera que dicho dominio requiera.
54
1.2 OBJETO DE ESTUDIO
1.2.1 ORGANIZACIÓN OBJETIVO.
La organización que será parte de este estudio es la Clínica Delgado que forma parte de la red
de clínicas AUNA.
Auna es una red de centro de salud que tiene como base a su producto más antiguo:
Oncosalud que tiene más de 25 años en el mercado brindando servicios enfocados en
programas oncológicos. La red AUNA tiene como valores que rigen la organización a los
siguientes3:
- Empatía: Nos ponemos en el lugar del cliente y hacemos siempre todo lo posible.
- Simplicidad: Hacemos simple/intuitivo lo complejo, expresamos solo lo importante y
de forma clara.
- Coherencia: Lo que pensamos (decisión, conceptualización y definición) lo
entregamos (ejecución y transmisión).
- Osadía: Somos pioneros y actuamos diferente.
Las clínicas que forman parte de la red Auna son las siguientes:
- Clínica Vallesur en Arequipa.
- Clínica Camino Real en Trujillo.
- Clínica Miraflores en Piura.
- Clínica Bellavista en Callao.
- Clínica Oncosalud en San Borja.
- Clínica Delgado en Miraflores.
Centros médicos:
- Centro médico Monteverde en Piura.
- Centro médico Talara en Piura.
- Centro médico Servimédicos en Chiclayo.
Red Oncosalud
3 Fuente página web de Auna: http://auna.pe
55
- Oncocenter Encalada.
- Oncocenter San Borja.
- Oncocenter Benavides.
- Oncocenter San Isidro.
Auna está enfocado en transformar la experiencia en salud para ello aplica la mejora continua
en sus procesos con la finalidad de brindar a sus pacientes la mejor calidad de servicios en
salud a través de soluciones integrales para personas y empresas.
Para efectos del desarrollo de la propuesta de arquitectura empresarial el estudio se encuentra
enfocado en la clínica Delgado de Miraflores la cual será el objeto de estudio específico.
Clínica Delgado
Historia
El día 27 de diciembre de 1928 se inauguró la Clínica Delgado, propiedad del prestigioso
cirujano Ernesto Delgado Gutiérrez. En la ceremonia de inauguración, oficiaron como
padrinos el entonces Presidente de la República, Don Augusto B. Leguía, y la señora Josefina
Gutiérrez de Delgado, madre del propietario. La Clínica Delgado cobró notoriedad nacional
cuando, el 6 de marzo de 1932, el presidente Luis M. Sánchez Cerro fue conducido
rápidamente a la clínica luego de un atentado contra su vida.
Durante los años cincuenta y sesenta, la Clínica Delgado se especializó en Ginecología y
Obstetricia, época de su “apogeo” como maternidad.
En el 2012 la Cruz Roja firma un acuerdo con Auna para construir una nueva clínica, con el
objetivo de devolver a la comunidad una clínica con altos estándares de calidad. La Clínica
Delgado renace dotada de la mejor infraestructura, tecnología de avanzada, modernos
procesos y el mejor staff del país, que en conjunto garantizan un nuevo estándar en salud en
el Perú.
56
Actualmente la clínica constituye la iniciativa más importante del Perú en el rubro de clínicas
generales y cuenta con los siguientes servicios4:
- Más de 40 especialidades médicas.
- Una amplia área privada de Emergencia con boxes independientes.
- Unidad de Cuidados Intensivos (UCI) con espacios independientes.
- Un moderno Centro de Maternidad.
- Unidad de Cuidados Intensivos Neonatal (UCIN).
- 9 salas de operaciones.
- Más de 130 habitaciones.
- Ambientes integrados y procesos pensados en el bienestar del paciente.
- Más de 720 espacios de estacionamiento.
- Helipuerto.
1.3 MISIÓN
“Transformar la experiencia en salud5”.
1.4 VISIÓN
“Ser la opción en salud6”.
1.5 OBJETIVOS ESTRATÉGICOS
Se han propuesto objetivos estratégicos para el objeto de estudio específico que es la clínica
Delgado, estos objetivos tienen relación directa con los objetivos estratégicos de la red Auna.
4 Fuente página web de la Clínica Delgado: https://clinicadelgado.pe
57
Tabla 15 - Tabla Objetivos Estratégicos
Objetivos
estratégicos red
AUNA
Objetivos estratégicos de
Clínica Delgado
Objetivos estratégicos de
TI
Posicionar la red
Auna como la
primera opción de
atención de calidad al
paciente
Asegurar reclutamiento de los
mejores profesionales de salud
Asegurar la continuidad del
negocio
Proporcionar una óptima
atención médica a los pacientes
brindándole un servicio que
satisfaga sus necesidades,
requerimientos y expectativas.
Incrementar el tráfico de
pacientes
Ser líder en
tecnología asistencial
que permita contar
con tecnología
integrada en todos los
centros de la red
Auna
Posicionar 3 centros de
excelencia: Maternidad,
Emergencia y Cardiología
Integrar la red Auna basada
en tecnología de
información
Brindar integración de
información entre los tipos de
atención Consulta Externa,
Urgencias, Hospitalización y
Cirugía.
Mantener tecnología de punta
que proporcione el soporte a
todos los procesos de la clínica
Brindar un ambiente
de trabajo de calidad
al personal que
permita manejar un
nivel de compromiso
con la red Auna
Lograr que cada empleado de la
clínica trabaje conjuntamente
orientado hacia la cultura del
paciente y sus familiares.
Hacer de TI un lugar
cómodo para trabajar y que
brinde un excelente servicio
a la organización
Fuente: Elaboración propia
5 Misión obtenida de la página institucional http://auna.pe
6 Visión obtenida de la página institucional http://auna.pe
58
1.6 MAPA DE PROCESOS DE LA CLINICA DELGADO
Figura 11 - Arquitectura Línea Base – Mapa de Procesos Clínica Delgado
Fuente: Elaboración propia
59
1.6.1 DESCRIPCIÓN DE LOS PROCESOS DE LA CLÍNICA DELGADO
Tabla 16 - Listado de Procesos clínica Delgado
ID Proceso Función Descripción de la función
1 Planeamiento Estratégico Gestionar el plan estratégico Gestionar, administrar el plan estratégico de la
empresa
2 Planificación y Desarrollo Planificar el desarrollo de la empresa Planificar las metas de la empresa y desarrollar los
objetivos para alcanzarlos
3 Marketing Estratégico de
los Servicios - Productos Gestionar el marketing estratégico
Se encarga de gestionar el marketing de los
servicios / Productos de la empresa, de manera
estratégica
4 Relaciones Institucionales Gestionar las relaciones institucionales Gestiona las relaciones institucionales con la
finalidad de que estén acorde con lo deseado
5 Gestión Legal Gestionar los temas legales Gestiona los temas legales de la empresa
6 Gestión de Calidad Gestionar la calidad en los procesos y servicios Gestiona y asegura la calidad en los procesos
7 Investigación y Docencia Realizar investigación en el ámbito médico y su
posterior docencia
Realiza las investigaciones en el ámbito médico
sobre temas aún no estudiados, y promueve la
docencia
60
ID Proceso Función Descripción de la función
8 Gestión del Talento Clínico Gestiona el talento clínico Recluta, capacita, apoya, gestiona el talento clínico
humano y tecnológico
9 Emergencia Atención de pacientes por emergencia
Realiza la atención de todos los pacientes que
llegan a la clínica bajo condiciones clínicas de
emergencia
10 Consulta Externa Atención vía consulta externa Gestionar y atender a los pacientes en el ámbito de
consulta externa
11 Hospitalización
Convencional Gestionar la hospitalización Gestionar y atender los pacientes hospitalizados
12 Hosp. críticos UCI Gestionar la hospitalización UCI Gestionar y atender los pacientes hospitalizados
en UCI
13 Cirugía Ambulatoria Gestionar las cirugías ambulatorias Realizar las atenciones por cirugía ambulatoria
14 Cirugía de Hospitalización Gestionar cirugías con hospitalización Realizar las atenciones por cirugía y derivarlas a
hospitalización
15 Dx por imágenes Gestionar las atenciones de imágenes Realiza y gestiona las atenciones con solicitud de
imágenes
61
ID Proceso Función Descripción de la función
16 Laboratorio Clínico Gestionar las atención de laboratorio clínico Realiza y gestiona las atenciones con solicitud de
laboratorio clínico
17 Laboratorio Anatomía
Patológica
Gestionar las atenciones de laboratorio de
anatomía patológica
Realiza y gestiona las atenciones de anatomía
patológica
18 Medicina Nuclear Gestión y atención especialidad Medicina Nuclear Administrar y realizar la atención clínica en las
especialidad de Medicina nuclear
19 Procedimientos Gestión y atención de procedimientos clínicos
Gestionar y realizar la atención de procedimientos
clínicos como endoscopia, tomografía, imágenes,
etc.
20 Farmacia Gestión de Farmacia Gestionar la Farmacia, inventarios, stock, ventas,
control de precios.
21 Radioterapia Gestión y atención Radioterapia Realizar la atención vía radioterapia y mantener el
control.
22 Banco de Sangre Gestión procesos Banco de Sangre
Realizar la atención al paciente, mediante entrega
de unidades de sangre para los procedimientos
requeridos
62
ID Proceso Función Descripción de la función
23 Quimioterapia Gestión y atención Quimioterapia
Realizar la atención de Quimioterapia para un
paciente a manera de clínica de día, es decir,
ambulatoria
24 Medicina Física y
Rehabilitación
Gestión y atención medicina física y
rehabilitación
Realizar la atención de la especialidad de medicina
física y rehabilitación
25 Hemodiálisis Gestión y atención Hemodiálisis Realizar la atención al paciente de Hemodiálisis
26 Nutrición y Dietética Gestión nutrición y dietética
Realizar la atención al paciente, administrar los
alimentos en base a los requerimientos
nutricionales.
27 Admisión – Caja Gestión de admisión y caja
Realizar la atención del paciente en admisión,
previo al procedimiento clínico, y el cobro
correspondiente, posterior a la atención.
28 Gestión de citas Gestión de citas para consulta externa y
procedimientos
Gestionar las citas médicas, horarios,
disponibilidad.
29 Gestión de Agendas Gestión de agendas Gestionar las agendas del médico, feriados,
disponibilidad, atenciones
63
ID Proceso Función Descripción de la función
30 Auditoría Médica Gestión de procesos de auditoría médica
Realizar la auditoría de los files del paciente, desde las
imputaciones de farmacia y prestaciones hasta su
aplicación en la cuenta del paciente, verificar coberturas
de medicamentos según
31 Cocina Gestión de cocina Realizar la atención de alimentos para los pacientes
32 Limpieza Procedimientos de limpieza Realizar la limpieza y mantener con la correcta limpieza
las instalaciones
33 Parking Asistencial Atención para parking asistencial Brindar soporte a los pacientes del parking de sus
vehículos
34 Hotelería Atención de hotelería clínica Mantener el correcto orden y limpieza de prendas como
batas, sábanas, almohadas, etc.
35 Transporte de
Pacientes Transportar a los pacientes hacia y de la clínica
Realizar el transporte de los pacientes desde y hacia la
clínica
36 Transporte de órganos Transporte de órganos desde y hacia la clínica Gestionar y realizar el transporte de los órganos desde y
hacia la clínica
64
ID Proceso Función Descripción de la función
37 Central de
Esterilización
Realizar esterilización de implementos
quirúrgicos
Realizar la esterilización de todos los instrumentos
clínicos que lo requieran
38 Gestión de Clientes Seguimiento a los clientes principales (pacientes) Gestionar a los clientes (pacientes) a fin de fidelizarlos
con la clínica
39 Acompañamiento al
paciente Asistenta social ante diversas situaciones
Realizar el acompañamiento al paciente en su estancia en
la clínica y procurar que sea de calidad
40 Seguridad del
paciente
Garantizar la seguridad del paciente dentro de las
instalaciones
Verificar y garantizar la seguridad del paciente dentro de
las instalaciones
41 Seguridad física Garantizar la seguridad del personal y paciente
conforme las estructuras
Verificar y cumplir los lineamientos de seguridad física
establecidas en la clínica
42 Seguridad Industrial Garantizar las seguridad en los procesos de
insumos clínicos
Cumplir con los requerimientos de seguridad industrial
para insumos clínicos.
43 Gestión de crisis Gestionar las crisis en todo aspecto de la empresa Realizar el seguimiento y gestión de los planes de manejo
de crisis en la clínica
44 Gestión Logística Gestión de los procesos logísticos Proceso integral logístico, compras, stock, inventarios,
almacenes
65
ID Proceso Función Descripción de la función
45 Gestión de residuos Gestión para la eliminación de residuos Asegurar la correcta eliminación de residuos
46 Lavandería Asegurar la limpieza de vestimenta de la clínica Realizar la lavandería de prendas
47 Soporte TI Asegurar el funcionamiento de los equipos TI Soporte a los procesos de la clínica, y servicios de TI
48 Mantenimiento Realizar el mantenimiento de las instalaciones Mantener las instalaciones de la clínica en buen estado
49 Control Patrimonial Gestión de los activos Control del patrimonio de la clínica
50 Ingeniería Clínica Gestionar Ingeniería clínica Revisión de ingeniería Clínica
51 Gestión y control
presupuestario Gestionar el control y presupuesto de la clínica
Realizar el presupuesto anual y el respectivo análisis de
las partidas ejecutadas versus las presupuestadas y
controlar que se cumplan y no excederse de lo
presupuestado
52 Contabilidad Realizar la contabilidad de la clínica Contabilizar las operaciones de la clínica y presentar la
información registradas en las entidades pertinentes
53 Recaudación
(Tesorería) Realizar las operaciones de flujo monetario
Realizar las operaciones de pagos y cobros, de gestionar
la caja y las distinta gestiones bancarias
54 Facturación Garantes Gestionar la facturación a garantes
Revisar, analizar, ejecutar la facturación a garantes
(compañías aseguradoras) conforme a los contratos y
porcentajes establecidos.
66
ID Proceso Función Descripción de la función
55 Liquidación
Asistencial Realizar la liquidación de la cuenta del paciente
Revisa, ejecuta, verifica la cuenta final del paciente y su
correspondiente liquidación
56 Marketing Realizar el marketing de la clínica Gestionar, evaluar y ejecutar el plan de marketing de la
clínica
57 Gestión de convenios Gestionar los distintos convenios contratados Gestionar, verificar, y asegurar los contratos a convenios
efectuados, y la correspondiente validación
58 Administración de
personal Administrar al personal en las distintas funciones Administrar al personal y sus requerimientos
59 Salud en el trabajo Gestionar la salud ocupacional Gestionar, controlar y verificar la salud ocupacional y
asegurar cumplir con los estándares de salud en el trabajo
60 Relacionamiento
Clínico Gestionar el relacionamiento clínico
Verificar y mantener las relaciones clínicas en el ámbito
asistencial
61 Gestión documentaria Gestión documentaria de los procesos de la clínica Gestionar los documentos, llevar el control de los mismos
62 Archivo clínico Administrar las historias clínicas de los pacientes Actualiza, mantener, administrar las historias clínicas del
paciente y mantenerlas en formato digital
Fuente: Elaboración propia
67
1.6.2 MATRIZ DE PROCESOS DE NEGOCIO VS OBJETIVOS DE NEGOCIO
Tabla 17 - Arquitectura Línea Base – Matriz Objetivos estratégicos vs Procesos – Parte 1
Objetivos Estratégicos red
AUNA Objetivos Estratégicos Clínica Delgado
Pla
nea
mie
nto
Est
raté
gic
o
Pla
nif
icac
ión
y D
esar
roll
o
Mar
ket
ing
Est
raté
gic
o
Rel
acio
nes
In
stit
uci
on
ales
Ges
tió
n L
egal
Ges
tió
n d
e C
alid
ad
Inv
esti
gac
ión
y D
oce
nci
a
Ges
tió
n d
el T
alen
to C
lín
ico
Em
erg
enci
a
Co
nsu
lta
Ex
tern
a
Ho
spit
aliz
ació
n C
on
ven
cio
nal
Ho
spit
aliz
ació
n c
ríti
cos
- U
CI
Cir
ug
ía A
mb
ula
tori
a
Cir
ug
ías
con
Ho
spit
aliz
ació
n
Dx
. P
or
imág
enes
Lab
ora
tori
o C
lín
ico
Lab
. A
nat
om
ía P
ato
lóg
ica
Med
icin
a N
ucl
ear
Pro
ced
imie
nto
s
Far
maci
a
Rad
iote
rap
ia
Posicionar la red Auna como la
primera opción de atención de
calidad al paciente
Asegurar reclutamiento de los mejores profesionales de salud x x x x x x x x x x x x x x x x x x x x x
Proporcionar una óptima atención médica a los pacientes
brindándole un servicio que satisfaga sus necesidades,
requerimientos y expectativas. x x x x x x x x x x x x x x x x x x x x x
Incrementar el tráfico de pacientes x x x x x x x x
Ser líder en tecnología asistencial
que permita contar con tecnología
integrada en todos los centros de la
red Auna
Posicionar 3 centros de excelencia: Maternidad, Emergencia y
Cardiología x x x x
x x x x x x x x x
Brindar integración de información entre los tipos de atención CEX,
URG, HOS, CQX x x x x x x x x x x x x x x
Mantener tecnología de punta que proporcione el soporte a todos
los procesos de la clínica x x x x x x x x x x x x x x x x x x x x x
Brindar un ambiente de trabajo de
calidad al personal que permita
manejar un nivel de compromiso
con la red Auna
Lograr que cada empleado de la clínica trabaje conjuntamente
orientado hacia la cultura del paciente y sus familiares. x x x x
x x x x x x x x x x x x x x x x
Total 7 7 7 7 4 7 7 7 6 6 6 6 6 6 4 4 4 4 4 4 4
Porcentaje 100% 100% 100% 100% 71% 100% 100% 100% 86% 86% 86% 86% 86% 86% 57% 57% 57% 57% 57% 57% 57%
Fuente: Elaboración propia
68
Tabla 18 - Arquitectura Línea Base – Matriz Objetivos estratégicos vs Procesos - Parte 2
Objetivos Estratégicos red
AUNA Objetivos Estratégicos Clínica Delgado
Ban
co d
e S
ang
re
Qu
imio
tera
pia
Nu
tric
ión
y D
ieté
tica
Med
icin
a F
ísic
a y
reh
abil
itac
ión
Hem
od
iáli
sis
Ad
mis
ión
Caj
a
Ges
tió
n d
e ag
end
as
Ges
tió
n d
e C
itas
Co
cin
a
Lim
pie
za
Ho
tele
ría
Par
kin
g A
sist
enci
al
Au
dit
orí
a M
édic
a
Tra
nsp
ort
e d
e P
acie
nte
s
Tra
nsp
ort
e d
e ó
rgan
os
Cen
tral
de
Est
eril
izaci
ón
Ges
tió
n d
e cl
ien
tes
Aco
mp
añam
ien
to a
l p
acie
nte
Seg
uri
dad
del
Pac
ien
te
Seg
uri
dad
Fís
ica
Seg
uri
dad
In
du
stri
al
Posicionar la red Auna como la
primera opción de atención de
calidad al paciente
Asegurar reclutamiento de los mejores profesionales de salud x X x x x
Proporcionar una óptima atención médica a los pacientes brindándole un
servicio que satisfaga sus necesidades, requerimientos y expectativas. x X x x x
Incrementar el tráfico de pacientes
Ser líder en tecnología asistencial
que permita contar con tecnología
integrada en todos los centros de la
red Auna
Posicionar 3 centros de excelencia: Maternidad, Emergencia y Cardiología
Brindar integración de información entre los tipos de atención CEX, URG,
HOS, CQX
Mantener tecnología de punta que proporcione el soporte a todos los
procesos de la clínica x X x x x x x x
Brindar un ambiente de trabajo de
calidad al personal que permita
manejar un nivel de compromiso
con la red Auna
Lograr que cada empleado de la clínica trabaje conjuntamente orientado
hacia la cultura del paciente y sus familiares. x X x x x x x x x x x x x x x x x x x x x
Total 4 4 4 4 4 2 2 2 1 1 1 1 1 1 1 1 1 1 1 1 1
Porcentaje 57% 57% 57% 57% 57% 29% 29% 29% 14% 14% 14% 14% 14% 14% 14% 14% 14% 14% 14% 14% 14%
Fuente: Elaboración propia
69
Tabla 19 - Arquitectura Línea Base – Matriz Objetivos estratégicos vs Proceso – Parte 3
Objetivos Estratégicos red AUNA Objetivos Estratégicos Clínica Delgado
Ges
tió
n d
e cr
isis
Ges
tió
n L
og
ísti
ca
Ges
tió
n d
e R
esid
uo
s
Lav
and
ería
So
po
rte
TI
Man
ten
imie
nto
Co
ntr
ol
Pat
rim
on
ial
Ing
enie
ría
Clí
nic
a
G. y
Co
ntr
ol
Pre
sup
ues
tal
Co
nta
bil
idad
Rec
aud
ació
n
Fac
tura
ció
n G
aran
tes
Liq
uid
ació
n A
sist
enci
al
Mar
ket
ing
Ges
tió
n d
e co
nv
enio
s
Ad
min
. d
e p
erso
nal
Sal
ud
en
el
trab
ajo
Rel
acio
nam
ien
to C
lín
ico
Arc
hiv
o C
lín
ico
Ges
tió
n d
ocu
men
tari
a
Ges
tió
n d
e la
In
form
ació
n
Posicionar la red Auna como la
primera opción de atención de
calidad al paciente
Asegurar reclutamiento de los mejores profesionales de salud
x
Proporcionar una óptima atención médica a los pacientes brindándole un
servicio que satisfaga sus necesidades, requerimientos y expectativas.
Incrementar el tráfico de pacientes
Ser líder en tecnología asistencial
que permita contar con tecnología
integrada en todos los centros de la
red Auna
Posicionar 3 centros de excelencia: Maternidad, Emergencia y Cardiología
Brindar integración de información entre los tipos de atención CEX, URG,
HOS, CQX
Mantener tecnología de punta que proporcione el soporte a todos los
procesos de la clínica x
x x
x
x
Brindar un ambiente de trabajo de
calidad al personal que permita
manejar un nivel de compromiso
con la red Auna
Lograr que cada empleado de la clínica trabaje conjuntamente orientado
hacia la cultura del paciente y sus familiares. x X x x x x x x x x x x x x x x x x x x x
Total 1 1 1 1 2 1 1 1 1 1 1 2 2 1 2 1 1 2 1 1 2
Porcentaje 14% 14% 14% 14% 29% 14% 14% 14% 14% 14% 14% 29% 29% 14% 29% 14% 14% 29% 14% 14% 29%
Fuente: Elaboración propia
1.6.3 ROLES DE NEGOCIO
Tabla 20 - Matriz de Asignación de Responsabilidades (RAM): A: Apoya, R: Registra y M: Modifica
Procesos / Áreas G
eren
cia
Gen
eral
Dir
ecci
ón
Méd
ica
Ger
enci
a C
om
erci
al
Adm
in y
Op
erac
ion
es
Rec
urs
os
Hum
ano
s
Ex
per
ienci
a C
lien
te
Con
tro
l d
e G
esti
ón
Pro
ceso
s, c
alid
ad y
segu
rid
ad a
l P
acie
nte
Cre
den
cial
es y
Pri
vil
egio
s
Ep
idem
iolo
gía
Coo
rd S
erv
icio
s
Méd
icos
Dir
ecto
r T
écn
ico
En
ferm
ería
Aud
ito
ría
Méd
ica
Ase
gu
rado
s B
rook
er
Sal
ud
Mu
jer
Pro
du
cto
s D
elg
ado
Bra
nd
ing
Adm
isió
n
Adm
inis
trac
ión
y
Lo
gís
tica
Infr
aest
ruct
ura
Fac
tura
ción
Ingen
ierí
a C
lín
ica
TI
Fin
anza
s
Leg
al
Abas
teci
mie
nto
Rel
. In
stit
uci
on
ales
Con
tro
l In
tern
o
Planeamiento Estratégico R A A A A A A A A M
Planificación y Desarrollo R A A A A A A A A M
Marketing Estratégico de
los Servicios - Productos A A A A A RM A
Relaciones Institucionales A R
M
Gestión Legal A R RM
Gestión de Calidad A A R
Investigación y Docencia A AR A M
Gestión del Talento Clínico AR AM
Emergencia R A A A A A RM A A M A A A A A A A
Consulta Externa R A A A A A RM A A M A A A A A A
Hospitalización
Convencional R A A A A A RM A A M A A A A A A
Hospitalización de críticos
– UCI R A A A A A RM A A M A A A A A A
Cirugía Ambulatoria R A A A A A RM A A M A A A A A A
Cirugía de Hospitalización R A A A A A RM A A M A A A A A A
71
Procesos / Áreas
Ger
enci
a G
ener
al
Dir
ecci
ón
Méd
ica
Ger
enci
a C
om
erci
al
Adm
in y
Op
erac
ion
es
Rec
urs
os
Hum
ano
s
Ex
per
ienci
a C
lien
te
Con
tro
l d
e G
esti
ón
Pro
ceso
s, c
alid
ad y
segu
rid
ad a
l P
acie
nte
Cre
den
cial
es y
Pri
vil
egio
s
Ep
idem
iolo
gía
Coo
rd S
erv
icio
s
Méd
icos
Dir
ecto
r T
écn
ico
En
ferm
ería
Aud
ito
ría
Méd
ica
Ase
gu
rado
s B
rook
er
Sal
ud
Mu
jer
Pro
du
cto
s D
elg
ado
Bra
nd
ing
Adm
isió
n
Adm
inis
trac
ión
y
Lo
gís
tica
Infr
aest
ruct
ura
Fac
tura
ción
Ingen
ierí
a C
lín
ica
TI
Fin
anza
s
Leg
al
Abas
teci
mie
nto
Rel
. In
stit
uci
on
ales
Con
tro
l In
tern
o
Dx por imágenes A A A A RM A A A A A A
Laboratorio Clínico A A A A RM A A A A A A
Laboratorio Anatomía
Patológica A A A A RM A A A A A A
Medicina Nuclear A A A A RM A A A A A A
Procedimientos A A A A RM A A A A A A
Farmacia A A A A RM A A A A A A
Radioterapia A A A A RM A A A A A A
Banco de Sangre A A A A RM A A A A A A
Quimioterapia A A A A RM A A A A A A
Medicina Física y
Rehabilitación A A A A RM A A A A A A
Hemodiálisis A A A A RM A A A A A A
Nutrición y Dietética A A A A RM A A A A A A
Admisión – Caja RM A A A A A RM A A A
Gestión de citas RM A A RM A
Gestión de Agendas RM A A RM A
Auditoría Médica A A A A A RM A A A A
72
Procesos / Áreas
Ger
enci
a G
ener
al
Dir
ecci
ón
Méd
ica
Ger
enci
a C
om
erci
al
Adm
in y
Op
erac
ion
es
Rec
urs
os
Hum
ano
s
Ex
per
ienci
a C
lien
te
Con
tro
l d
e G
esti
ón
Pro
ceso
s, c
alid
ad y
segu
rid
ad a
l P
acie
nte
Cre
den
cial
es y
Pri
vil
egio
s
Ep
idem
iolo
gía
Coo
rd S
erv
icio
s
Méd
icos
Dir
ecto
r T
écn
ico
En
ferm
ería
Aud
ito
ría
Méd
ica
Ase
gu
rado
s B
rook
er
Sal
ud
Mu
jer
Pro
du
cto
s D
elg
ado
Bra
nd
ing
Adm
isió
n
Adm
inis
trac
ión
y
Lo
gís
tica
Infr
aest
ruct
ura
Fac
tura
ción
Ingen
ierí
a C
lín
ica
TI
Fin
anza
s
Leg
al
Abas
teci
mie
nto
Rel
. In
stit
uci
on
ales
Con
tro
l In
tern
o
Cocina A RM
Limpieza A RM
Parking Asistencial A RM
Hotelería A RM
Transporte de Pacientes A A A A RM
Transporte de órganos RM A A A A A A
Central de Esterilización A A A RM A
Gestión de Clientes A
Acompañamiento al
paciente A
R
M A R A A A
Seguridad del paciente A A A A A RM A
Seguridad física A RM A
Seguridad Industrial A A R A RM
Gestión de crisis A A R R M
Gestión Logística A RM RM
Gestión de residuos A A RM
Lavandería RM
Soporte TI A RM
73
Procesos / Áreas
Ger
enci
a G
ener
al
Dir
ecci
ón
Méd
ica
Ger
enci
a C
om
erci
al
Adm
in y
Op
erac
ion
es
Rec
urs
os
Hum
ano
s
Ex
per
ienci
a C
lien
te
Con
tro
l d
e G
esti
ón
Pro
ceso
s, c
alid
ad y
segu
rid
ad a
l P
acie
nte
Cre
den
cial
es y
Pri
vil
egio
s
Ep
idem
iolo
gía
Coo
rd S
erv
icio
s
Méd
icos
Dir
ecto
r T
écn
ico
En
ferm
ería
Aud
ito
ría
Méd
ica
Ase
gu
rado
s B
rook
er
Sal
ud
Mu
jer
Pro
du
cto
s D
elg
ado
Bra
nd
ing
Adm
isió
n
Adm
inis
trac
ión
y
Lo
gís
tica
Infr
aest
ruct
ura
Fac
tura
ción
Ingen
ierí
a C
lín
ica
TI
Fin
anza
s
Leg
al
Abas
teci
mie
nto
Rel
. In
stit
uci
on
ales
Con
tro
l In
tern
o
Mantenimiento A A RM A
Control Patrimonial RM A
Ingeniería Clínica A A A
Gestión y control
presupuestario A A A R RM
Contabilidad A A RM A
Recaudación (Tesorería) A A RM A
Facturación Garantes A M RM M
Liquidación Asistencial A M RM M
Marketing A A A M M
Gestión de convenios A A RM RM
Administración de personal RM A A A A
Salud en el trabajo A A A
Relacionamiento Clínico A A RM M
Archivo clínico A A RM RM
Gestión documentaria A RM M
Gestión de la Información A A RM M
Fuente: Elaboración propia
74
1.7 ORGANIGRAMA
1.7.1 ORGANIGRAMA GENERAL DE LA RED AUNA
Figura 12 - Organigrama General Red Auna
Fuente: Elaboración propia
75
1.7.2 ORGANIGRAMA DE LA CLÍNICA DELGADO
Figura 13 - Organigrama de la Clinica delgado
Fuente: Elaboración propia
76
1.7.3 ORGANIGRAMA DE LA GERENCIA DE LA DIVISIÓN DE
TECNOLOGÍAS DE INFORMACIÓN
Figura 14 - Organigrama Específico de la Gerencia de TI
Fuente: Elaboración propia
77
1.8 ALCANCE DEL PROYECTO
El alcance del trabajo es proponer una arquitectura empresarial para el proceso core Banco de
Sangre del objeto de estudio en este caso la clínica Delgado. Para lograr desarrollar el trabajo
se documentó la información esencial de la empresa tanto estratégica como funcional para
que sea la base de estudio y se pueda realizar una evaluación estratégica el cual involucra el
entorno interno como externo.
Al tener claro los objetivos estratégicos del objeto de estudio y los objetivos estratégicos de
TI se realizaron las siguientes actividades:
Realizar el análisis del proceso seleccionado del mapa de procesos de la organización con la
finalidad de plantear proyectos de mejora que ayuden a cumplir con los objetivos de TI y que
a su vez tributen con los objetivos estratégicos de la organización.
Realizar el análisis del proceso de Banco de Sangre de la clínica Delgado, tomando como
base dos subprocesos que son Donación de Sangre y transfusión de sangre, se realizará el
análisis AS-IS utilizando como base el marco de trabajo TOGAF, de esta forma poder
identificar el funcionamiento del proceso en cada una de las 4 arquitecturas definidas,
Arquitectura de Negocio, Arquitectura de Datos, Arquitectura de Aplicaciones y Arquitectura
Tecnológica.
El objetivo principal será plantear alternativas de mejora en base al análisis AS-IS, a traves de
una definición de proyectos de TI que permitan ayudar a los interesados a poder resolver sus
preocupaciones y poder alcanzar la mejora deseada TO-BE. El planteamiento de los
proyectos de desarrollo se realiza a través del marco de trabajo SCRUM con la finalidad de
poder entregar aplicaciones que permitan cumplir con los requerimientos del usuario y
ayuden a la organización a cumplir con sus objetivos estratégicos que le den una ventaja
competitiva en el mercado actual.
78
1.9 OBJETIVOS DEL PROYECTO
1.9.1 OBJETIVO GENERAL.
Realizar el diseño de una arquitectura empresarial para la Clínica Delgado enfocado en los
sub procesos de Donación de sangre y Transfusión de sangre que son parte del proceso core
Banco de sangre, planteando la implementación de proyectos a través de metodologías agiles
que ayuden a alcanzar la situación deseada con mayor eficacia, cumpliendo con los
requerimientos del negocio y que permita obtener una ventaja competitiva a la organización.
1.9.2 OBJETIVOS ESPECÍFICOS.
Realizar el análisis de brechas del proceso de Banco de sangre y transfusión de sangre
en base al análisis actual con la situación deseada.
Plantear un portafolio de proyectos de mejora en base al análisis del estado actual de
los procesos de donación de sangre y transfusión de sangre.
Realizar la propuesta de implementación de 2 proyectos para los procesos de
transfusión de sangre y donación de sangre a traves del marco de trabajo SCRUM.
79
1.10 BENEFICIOS DEL PROYECTO.
1.10.1 BENEFICIOS TANGIBLES
Al implementar una arquitectura empresarial para un proceso core de la clínica se podrán
plasmar un portafolio de proyectos que brindaran algunos beneficios tales como:
- Se reducirán en un 95% los costos operativos de las actividades manuales que serán
automatizados en el portafolio de proyectos.
- Incrementar en un 30% el número de donantes de sangre a través de la aplicación
móvil y portal web.
- Agilizar en un 50% el tiempo de atención de las solicitudes de transfusión de sangre
con la integración del sistema de banco de sangre con el sistema core de al clínica.
1.10.2 BENEFICIOS INTANGIBLES.
- Alinear los objetivos de TI con los objetivos estratégicos de la clínica Delgado.
- Posicionar al área de Tecnología de Información como socio del negocio que
contribuye con el cumplimiento de los objetivos estratégicos de la organización.
- Visibilidad de la contribución de los procesos con el cumplimiento de los objetivos de
la organización.
- Contar con roles de arquitectura definidos que permita alinear los proyectos de mejora
con los objetivos estratégicos de la Clínica.
- Consolidar los sistemas de información, unificando los sistemas dispersos mejorando
el nivel de servicio y disponibilidad de los sistemas.
- Mejora de la comunicación interna.
80
CAPÍTULO 2: ARQUITECTURA EMPRESARIAL
2.1 INTRODUCCIÓN
En el presente capítulo se priorizaran los procesos de la organización por su importancia en
base al soporte que dan a los objetivos estratégicos. Asimismo, se seleccionará el proceso
estratégico más importante con la finalidad de analizar su arquitectura e identificar el impacto
al aplicar mejoras sobre el mismo.
2.2 ALCANCE
El alcance de la propuesta de arquitectura empresarial para la clínica Delgado esta basado en
las siguientes dimensiones:
Amplitud:
El objeto de estudio es la clínica Delgado que pertenece a la red de clinicas Auna.
Esta empresa brinda de servicios de salud como hospitalizaciones, emergencia,
procedimientos médicos, etc. Como parte de los procedimientos médicos se tiene el
macroproceso Procedimientos Terapéuticos que es parte de los procesos core de la
empresa y el cual está constituido por dos (7) procesos: Para el presente estudio
elegiremos el proceso de Banco de Sangre que abarca 2 sub procesos que serán
analizados.
- Donación de sangre
- Transfusión de sangre
81
Profundidad:
El alcance de este proyecto profesional abarca el diseño de la arquitectura para los sub
procesos de Donación y Transfusión que pertencen al macroproceso de
Procedimientos Terapeuticos.
Periodo de tiempo
La propuesta de arquitectura empresarial para los procesos de donación y transfusión
de sangre, comprenden el análisis de la situación actual, y las brechas que se
requieren para llegar a la situación deseada. Este proceso sera cubierto en el período
de 5 meses.
Dominios de Arquitectura
La propuesta abarcará cambios en las siguientes arquitecturas:
Tabla 21 - Cambios en las arquitecturas
Negocio Datos Aplicaciones Infraestructura
Donación de Sangre x x x x
Transfusión de Sangre x x x x
Fuente: Elaboración propia
Proceso Arquitectura
82
2.3 PRELIMINAR
2.3.1 PRINCIPIOS DE ARQUITECTURA
2.3.1.1 PRINCIPIOS DE NEGOCIO
Nombre Atraer la mayor cantidad de donantes de sangre
Código PN01
Enunciado
Se debe procurar que los donantes pasen por un flujo de proceso sencillo y
en el menor tiempo posible. Esto puede garantizar su regreso en el futuro y
la recomendación a más personas.
Fundamento Asegurar el mínimo de stock de unidades de sangre disponible en el banco
Repercusiones
Mayores unidades de sangre donadas.
Minimizar los tiempos de donación para atraer mayor cantidad de
donantes.
Nombre Minimizar el uso de documentación física
Código PN02
Enunciado Se debe evitar el uso de documentación física en las solicitudes de
requerimientos de transfusión
Fundamento Asegurar la integridad de la información requerida
Repercusiones Minimizar error humano en la solicitud de transfusión.
Minimizar los tiempos de solicitud de transfusiones de sangre.
83
2.3.1.2 PRINCIPIOS DE APLICACIONES
Nombre Brindar servicios más que aplicaciones
Código PA01
Enunciado Permitir que las aplicaciones a implementar sean compatibles con la actual
para permitir integrar, combinar y reutilizar funcionalidades.
Fundamento
Eliminar dependencias de componentes.
Evitar redundancia funcional.
Escalabilidad e interoperabilidad.
Repercusiones
Estandarización de las soluciones tecnológicas
Aseguramiento de la calidad de datos evitando sobre costos para la
reutilización.
Nombre Simplicidad de uso
Código PA02
Enunciado El usuario debe tener un mínimo de horas de capacitación para asegurar el
uso correcto de las aplicaciones
Fundamento Asegurar el correcto uso de las aplicaciones buscando la optimización en
los servicios.
Repercusiones Minimizar errores operativos por parte de los usuarios.
Cumplir con los requisitos y lineamientos establecidos al inicio.
PRINCIPIOS DE DATOS
Nombre Integración de la información
84
Código PD01
Enunciado
La información debe estar centralizada en un repositorio central, desde el
cual podrá ser accedida por otras aplicaciones pertenecientes a otras áreas
en modo de solo lectura, en caso se requiera acceder otro nivel deberá
contar con autorización
Fundamento
Información disponible.
Información integra.
Información centralizada.
Repercusiones Información integra y disponible para la organización
Seguridad de aplicaciones.
Nombre Disponibilidad de datos
Código PD02
Enunciado La información debe estar 100% disponible para asegurar el cumplimiento
del soporte por parte de los colaboradores
Fundamento Contar con información histórica que permite el análisis que apoyen las
decisiones.
Repercusiones Corregir información para el caso de emergencias.
Control de la disponibilidad de la información.
2.3.1.3 PRINCIPIOS DE TECNOLOGÍA
Nombre Transición a la nube
Código PT01
Enunciado Evaluar costo/beneficio de alojar las aplicaciones en la nube
85
Fundamento Reducción de costo de infraestructura.
Integración de aplicaciones
Repercusiones Escalabilidad de la infraestructura en caso se requiera.
Alta disponibilidad.
Nombre Tecnología actual
Código PT02
Enunciado Todo requerimiento nuevo debe ser soportado por tecnología actual
Fundamento Contar con tecnología actualizada y adecuada que permita integrar toda la
red.
Repercusiones Alta disponibilidad de las aplicaciones a causa de la integración.
Asegurar que los procesos estén soportados por la tecnología.
2.3.2 PETICIÓN DE TRABAJO DE ARQUITECTURA
2.3.2.1 PATROCINADORES DE LA ORGANIZACIÓN
La propuesta de arquitectura empresarial en la Clinica Delgado para los procesos
seleccioneados esta patrocinada por:
- Gerente de Administración y Operaciones
- Gerente de División de tecnologías de Información
- Jefe de Gobierno de TI
2.3.2.2 MISION DE LA ORGANIZACIÓN
“Transformar la experiencia en salud7”.
7 Misión obtenida de la página institucional http://auna.pe
86
2.3.2.3 OBJETIVOS DEL NEGOCIO
Objetivos
estratégicos red
AUNA
Objetivos estratégicos de
Clínica Delgado
Objetivos estratégicos de
TI
Posicionar la red
Auna como la
primera opción de
atención de calidad al
paciente
Asegurar reclutamiento de los
mejores profesionales de salud
Asegurar la continuidad del
negocio
Proporcionar una óptima
atención médica a los pacientes
brindándole un servicio que
satisfaga sus necesidades,
requerimientos y expectativas.
Incrementar el tráfico de
pacientes
Ser líder en
tecnología asistencial
que permita contar
con tecnología
integrada en todos los
centros de la red
Auna
Posicionar 3 centros de
excelencia: Maternidad,
Emergencia y Cardiología
Integrar la red Auna basada
en tecnología de
información
Brindar integración de
información entre los tipos de
atención Consulta Externa,
Urgencias, Hospitalización y
Cirugía.
Mantener tecnología de punta
que proporcione el soporte a
todos los procesos de la clínica
Brindar un ambiente
de trabajo de calidad
al personal que
permita manejar un
nivel de compromiso
con la red Auna
Lograr que cada empleado de la
clínica trabaje conjuntamente
orientado hacia la cultura del
paciente y sus familiares.
Hacer de TI un lugar
cómodo para trabajar y que
brinde un excelente servicio
a la organización
Tabla 22 - Arquitectura Empresarial/Tabla Objetivos Estratégicos
2.3.2.4 LIMITACIONES DE TIEMPO
El planteamiento de una arquitectura empresarial los procesos de Donación de Sangre y
Transfusión de Sangre será de 5 meses.
2.3.2.5 LIMITACIONES FINANCIERAS
La red Auna al cual pertenece la Clinica Delgado que es el objeto de estudio para la
aplicación de una arquitectura empresarial cuenta con la solidez económica necesaria para
87
poder ejecutar proyectos con la finalidad de conseguir los objetivos estratégicos de la
organización. El presupuesto para proyectos es de s/. 4’260,164.00 soles.
2.3.2.7 DESCRIPCIÓN DE LA SITUACIÓN ACTUAL DEL NEGOCIO
La clinica Delgado es una de las clinicas mas importantes del Perú, por el prestigio alcanzado
a traves de su calidad de servicio en todas sus especialidades y procedimientos. Esto hace que
la afluencia de pacientes sea muy alta, por lo tanto la mejora continua de los procesos es
constante. La clínica invierte en equipos medicos especializados de última generación y en
capacitación a sus trabajadores para poder mantener un estandar alto de servicio. Sin embargo
existen puntos de mejora en algunos procesos que ayuden a brindar servicios con mayor
eficiencia y eficacia.
En base a lo descrito actualmente por ejemplo se tiene un déficit muy alto de reservas de
unidades de sangre en el Banco de Sangre de la clinica Delgado debido a que la tasa de
donaciones es muy baja y eso trae muchos problemas en los casos de transfusión de sangre,
ya que muchas veces al no tener stock suficiente para poder cubrir la demanda de
transfusiones de los pacientes de piso y los pacientes de emergencia se tiene que recurrir a
los familiares para la donación o indicarles que deben de conseguir las unidades requeridas
por el paciente por su cuenta.
Tambien para el proceso de transfusiones se tiene un sistema e-Delphy en donde se registran
las transfusiones que son traidas por las enfermeras en un formulario escrito debido a que no
existe integración con el sistema core en donde se encuentra toda la información relacionada
con los pacientes. Esto hace que el proceso tome un mayor tiempo ya que el llenado de la
solicitud es manual y el traslado de la enfermera del piso al Banco hace que no se optimice el
tiempo de atencion y respuesta a las solicitudes.
2.3.2.8 DESCRIPCION DE LA SITUACIÓN ACTUAL DE LA ARQUITECTURA DE
TI
La clinica tiene un sistema de core de negocio que se encuentra desplegado a traves de la
aplicación ERP-xHIS en donde se encuentra toda la información relacionada con los
pacientes, camas, historias, etc.
88
En el caso del proceso de Donación de Sangre no existe un sistema que permita llevar un
registro de los donantes, solo se registra la sangre que ha sido donada en el sistema E-delphy
que es el que maneja el stock de Banco de Sangre. Este sistema se encuentra en el área del
Banco de Sangre y no se conecta con ninguna aplicación.
Para el caso de las transfusiones se tiene una aplicación que permite registrar las solicitudes
de transfusión que es el e-Delphy. Este programa permite llevar el control del stock del banco
de sangre (entrada y salida) con todas las caracteristicas necesarias de la sangre almacenada,
asi como tambien lleva un registro de las transfusiones solicitadas.
2.4 VISIÓN DE LA ARQUITECTURA
2.4.1 DECLARACIÓN DE TRABAJO DE ARQUITECTURA
2.4.1.1 SOLICITUD DE PROYECTO DE ARQUITECTURA Y ANTECEDENTES
Actualmente el proceso de Donación de Sangre se tienen muchos problemas de falta de
donantes y por lo tanto muy poco stock de unidades para transfusión, esto representa un
problema que afecta directamente sobre la calidad de servicio que se brinda a los pacientes de
la Clinica. Asimismo el proceso de transfusión de sangre que es un procedimiento muy
solicitado por la clinica, tiene problemas de demora debido a que el proceso de solicitud es
manual, ademas el sistema que gestiona el almacén de sangre es un sistema que solo funciona
para el area de banco de sangre y no puede ser accedida por la enfermera para que pueda
agilizar el proceso de transfusión.
Para que la empresa pueda generar valor agregado a sus pacientes en los procesos
mencionados anteriormente, el plantear una arquitectura empresarial de manera progresiva
ayudara a tener una alineación del área de TI con los objetivos estrategicos del negocio,
ayudando a plantear soluciones para lograr que estos procesos sean mas ágiles y eficazes.
Esto debido a que la arquitectura empresarial abarca los dominios de negocio, datos,
aplicaciones e infraestructura de TI.
89
2.4.1.2 DESCRIPCIÓN DEL PROYECTO DE ARQUITECTURA Y ALCANCE
Este proyecto tiene como finalidad realizar un levantamiento de la información actual tanto
en el dominio negocio, como datos, aplicaciones e infraestructura, con la finalidad de plantear
el escenario actual de cada arquitectura (AS IS) para los procesos de Donación de Sangre y
Transfusión de sangre.
En base a esto plantear el escenario deseado (TO BE), para lo cual se planterán proyectos de
mejora en base al análisis de brechas que existentes entre en análisis AS IS y TO BE.
2.4.1.3 PROCEDIMIENTOS ESPECÍFICOS PARA EL CAMBIO DE ALCANCE
Los cambios que se realicen en el alcance del proyecto deben de considerar lo siguiente:
- El equipo debe de solicitar el cambio al Arquitecto empresarial, indicando la fecha,
justificación, riesgos asociados, impacto en el negocio.
- El arquitecto empresarial es el encargado de aprobar el cambio evaluando el impacto a
nivel financiero, riesgos asociados e impacto de realizar el cambio.
- En caso el cambio sea aceptado es comunicado a todos los equipos de trabajo a través
del Arquitecto de TI.
- Se realizan los cambios necesarios en los documentos relacionados con el cambio.
- En caso sea rechazado el cambio, el Arquitecto de TI comunica los motivos al equipo
de trabajo.
En el siguiente digrama se muestra el proceso de control de cambios de alcance:
90
Figura 15 – Proceso de control de cambios de alcance
Fuente: Elaboración propia
2.4.1.4 ROLES, RESPONSABILIDADES Y ENTREGABLES
ROLES Y RESPONSABILIDADES
A continuación se detallan los roles y responsabilidades que serán parte de este proyecto:
Tabla 23 – Roles y responsabilidades
ROLES
RESPONSABILIDADES
91
Arquitecto de Negocio
Es el encargado de definir los principios de arquitectura
relacionados al negocio y de identificar aquellas mejoras
en el proceso de Banco de sangre, especificamente en los
sub procesos de Donación y Transfusión de sangre.
Arquitecto de TI
Es el encargado de brindar información de la situación
actual de los 3 dominios en los que se basará el estudio:
Aplicaciones, Datos y Tecnológica. Asimismo es el
responsable de determinar los lineamientos y principios
en cada una de estos dominios y diseñar la estrategia
necesaria para poder llegar a la situación deseada
considerando todos los aspectos importantes en cada
arquitectura.
Arquitecto Empresarial
Es el encargado de velar que la propuesta de arquitectura
empresarial se encuentren alineados a los objetivos
estratégicos del negocio. Asimismo es responsable de que
cada planteamiento cumpla con las restricciones de la
organización y que se oriente al alcance de la situación
deseada. Es el encargado de aprobar o rechazar los
cambios en el alcance del proyecto.
Fuente: Elaboración propia
ENTREGABLES
Para el desarrollo de este proyecto profesional se considerará los siguientes
entregables:
Tabla 24 – Entregables de la propuesta de arquitectura empresarial
FASE ADM
ENTREGABLE
92
Preeliminar Principios de arquitectura
Petición de trabajo de arquitectura
Visión de la arquitectura Declaración de trabajo de arquitectura
Visión de la arquitectura
Arquitectura de negocio
Documento de definición de la arquitectura Arquitectura de sistemas de información
Arquitectura tecnológica
Oportunidad y soluciones Plan de implementación de la migración
Fuente: Elaboración propia
2.4.1.5 CRITERIOS DE ACEPTACIÓN
Dentro de los principales criterios de aceptación del proyecto se plantea lo siguiente:
La propuesta de arquitectura empresarial debe de tener trazabilidad con los objetivos
estratégicos de la organización y demuestra que los objetivos de TI ayudan con el
logro de estos.
Todas las propuestas que resulten del análisis de arquitectura empresarial deben de
considerar los principios del negocio.
Cumplir con los entregables de cada una de las fases que se detalla en la Tabla 24,
detallando la situación actual (AS IS) y el escenario de mejora propuesto (TO BE).
La propuesta debe de ajustarse con el presupuesto asignado para el desarrollo de
aplicaciones que serán parte de la propuesta de mejora.
93
2 . 4 . 1 . 6 C R O N O G R A M A T E N T A T I V O
Figura 16 – Cronograma Tentativo
Fuente: Elaboración propia
94
2.4.2 VISIÓN DE LA ARQUITECTURA
2.4.2.1 DESCRIPCIÓN DEL PROBLEMA
INTERESADOS Y SUS PREOCUPACIONES
- Gerente de la clínica: El gerente que vela por cumplir los objetivos estratégicos y que la
clínica sea pionera en el rubro.
- Director médico: El director médico de la clínica es quien gestiona los temas clínicos de
todos los ámbitos y especialidades.
- Jefe de operaciones: Es el análogo del director médico, gestiona los temas no asistenciales
y que son de soporte de la operación.
- Coordinador de servicios médicos: Tiene a su cargo a todas las jefaturas de las
especialidades quienes trabajan en conjunto para brindar un servicio de calidad.
- Jefa de enfermería: Encargado de dirigir las gestiones que competen al rubro de
enfermería.
- Paciente: Encargado de recibir y validar los servicios ofrecidos por la clínica.
95
LISTA DE ASUNTOS/ESCENARIOS QUE DEBEN DE ABORDARSE
Tabla 25 – Lista de asuntos/escenarios
Situación Problemática Problema a Resolver
El flujo de la donación de
sangre se realiza de manera
manual.
Duplicación de citas, debido a que las citas se programan de
manera manual en un archivo MS Excel y está sujeto al error
humano duplicando citas a la misma hora.
La información sobre los
formularios de donantes de
sangre no cuenta con los
suficientes controles sobre los
datos ingresados
Al ser un proceso con ausencia de herramientas tecnológicas
se hace uso de formularios físicos y archivos MS Excel los
cuales son rellenados de manera manual donde los errores de
digitación son más frecuentes, Así mismo la documentación
física no tiene una adecuada gestión de almacenaje en caso se
requiera consultar alguna información a futuro.
Quejas por parte de los usuarios donantes por el retraso que
causa la excesiva cantidad de procedimientos manuales
(formularios manuales)
96
La información sobre las
solicitudes de transfusión de
sangre no cuenta con los
suficientes controles sobre los
datos ingresados
De la misma manera que el flujo de donación de sangre,
el proceso de transfusión de sangre carece de
herramientas tecnológicas se hace uso de formularios
físicos los cuales son rellenados de manera manual
donde los errores de digitación son más frecuentes, Así
mismo esta documentación física no tiene una adecuada
gestión de almacenaje en caso se requiera consultar
alguna información.
Fuente: Elaboración propia
97
2.5 DOCUMENTO DE DEFINICIÓN DE LA ARQUITECTURA
2.5.1 ALCANCE
El alcance de este documento es cubrir el análisis de la situación actual “Arquitectura Línea
Base (AS IS)” y el análisis de la situación deseada “Arquitectura destino (TO BE)” en los
cuatro dominios de arquitectura planteada por el marco de trabajo TOGAF: Arquitectura de
Negocio, Arquitectura de Datos, Arquitectura de aplicación y Arquitectura tecnológica.
La propuesta de arquitectura destino debe de estar alineado con los objetivos estratégicos de
la organización y debe de considerar las limitaciones y los principios de negocio para poder
plantear las soluciones en cada una de las arquitecturas.
2.5.2 METAS OBJETIVOS Y LIMITACIONES
OBJETIVOS/METAS
- Objetivo estratégico: Proporcionar una óptima atención médica a los pacientes
brindándole un servicio que satisfaga sus necesidades, requerimientos y expectativas.
Meta: Establecer procedimientos de calidad en la atención de los pacientes, realizar el
seguimiento a la atención y buscar información retroactiva conforme las atenciones.
- Objetivo estratégico: Incrementar el tráfico de pacientes
Meta: Brindar paquetes que aseguren la atención del paciente, de manera que puedan
comprobar la calidad y el buen servicio brindado
- Objetivo estratégico: Posicionar 3 centros de excelencia: Maternidad, Emergencia y
Cardiología
Meta: Intensificar la publicidad con casos de éxito en estos centros de excelencia
98
- Objetivo estratégico: Mantener tecnología de punta que proporcione el soporte a todos
los procesos de la clínica
Meta: Desarrollar niveles de actualización tecnológica en los temas correspondientes
a la salud, participar de los eventos tecnológicos brindados por los grandes
establecimientos
- Objetivo estratégico: Lograr que cada empleado de la clínica trabaje conjuntamente
orientado hacia la cultura del paciente y sus familiares.
Meta: Asegurar la confianza de los trabajadores, brindando un lugar seguro para
trabajar y orientado a la calidad.
LIMITACIONES
LIMITACIONES DE TIEMPO
El planteamiento de una arquitectura empresarial los procesos de Donación de Sangre
y Transfusión de Sangre será de 5 meses.
LIMITACIONES FINANCIERAS
La red Auna al cual pertenece la Clinica Delgado que es el objeto de estudio para la
aplicación de una arquitectura empresarial cuenta con la solidez económica necesaria
para poder ejecutar proyectos con la finalidad de conseguir los objetivos estratégicos
de la organización. El presupuesto para proyectos es de s/. 4’260,164.00 soles.
LIMITACIONES EXTERNAS Y DE NEGOCIO
No aplica.
99
2.5.3 PRINCIPIOS DE ARQUITECTURA
2.5.3.1 PRINCIPIOS DE NEGOCIO
NOMBRE ATRAER LA MAYOR CANTIDAD DE DONANTES DE SANGRE
Código PN01
Enunciado
Se debe procurar que los donantes pasen por un flujo de proceso sencillo y
en el menor tiempo posible. Esto puede garantizar su regreso en el futuro y
la recomendación a más personas.
Fundamento Asegurar el mínimo de stock de unidades de sangre disponible en el banco
Repercusiones
Mayores unidades de sangre donadas.
Minimizar los tiempos de donación para atraer mayor cantidad de
donantes.
NOMBRE MINIMIZAR EL USO DE DOCUMENTACIÓN FÍSICA
Código PN02
Enunciado Se debe evitar el uso de documentación física en las solicitudes de
requerimientos de transfusión
Fundamento Asegurar la integridad de la información requerida
Repercusiones Minimizar error humano en la solicitud de transfusión.
Minimizar los tiempos de solicitud de transfusiones de sangre.
100
2.5.3.2 PRINCIPIOS DE APLICACIONES
NOMBRE BRINDAR SERVICIOS MÁS QUE APLICACIONES
Código PA01
Enunciado Permitir que las aplicaciones a implementar sean compatibles con la actual
para permitir integrar, combinar y reutilizar funcionalidades.
Fundamento
Eliminar dependencias de componentes.
Evitar redundancia funcional.
Escalabilidad e interoperabilidad.
Repercusiones
Estandarización de las soluciones tecnológicas
Aseguramiento de la calidad de datos evitando sobre costos para la
reutilización.
NOMBRE SIMPLICIDAD DE USO
Código PA02
Enunciado El usuario debe tener un mínimo de horas de capacitación para asegurar el
uso correcto de las aplicaciones
Fundamento Asegurar el correcto uso de las aplicaciones buscando la optimización en
los servicios.
Repercusiones Minimizar errores operativos por parte de los usuarios.
Cumplir con los requisitos y lineamientos establecidos al inicio.
101
2.5.3.3 PRINCIPIOS DE DATOS
NOMBRE INTEGRACIÓN DE LA INFORMACIÓN
Código PD01
Enunciado
La información debe estar centralizada en un repositorio central, desde el
cual podrá ser accedida por otras aplicaciones pertenecientes a otras áreas
en modo de solo lectura, en caso se requiera acceder otro nivel deberá
contar con autorización
Fundamento
Información disponible.
Información integra.
Información centralizada.
Repercusiones Información integra y disponible para la organización
Seguridad de aplicaciones.
NOMBRE DISPONIBILIDAD DE DATOS
Código PD02
Enunciado La información debe estar 100% disponible para asegurar el cumplimiento
del soporte por parte de los colaboradores
Fundamento Contar con información histórica que permite el análisis que apoyen las
decisiones.
Repercusiones Corregir información para el caso de emergencias.
Control de la disponibilidad de la información.
102
2.5.3.4 PRINCIPIOS DE TECNOLOGÍA
NOMBRE TRANSICIÓN A LA NUBE
Código PT01
Enunciado Evaluar costo/beneficio de alojar las aplicaciones en la nube
Fundamento Reducción de costo de infraestructura.
Integración de aplicaciones
Repercusiones Escalabilidad de la infraestructura en caso se requiera.
Alta disponibilidad.
NOMBRE TECNOLOGÍA ACTUAL
Código PT02
Enunciado Todo requerimiento nuevo debe ser soportado por tecnología actual
Fundamento Contar con tecnología actualizada y adecuada que permita integrar toda la
red.
Repercusiones Alta disponibilidad de las aplicaciones a causa de la integración.
Asegurar que los procesos estén soportados por la tecnología.
103
2.5.4 ARQUITECTURA LINEA BASE (AS IS)
2.5.4.1 ARQUITECTURA DE NEGOCIO
ORGANIGRAMA DEL OBJETO DE ESTUDIO
Figura16 - Arquitectura Empresarial/Organigrama General Red Auna
Fuente: Elaboración propia
104
MAPA DE PROCESOS DE LA CLINICA DELGADO
Figura 17- Arquitectura Línea Base – Mapa de Procesos Clínica Delgado
Fuente: Elaboración propia
105
DESCRIPCIÓN DE LOS POCESOS DE LA CLINICA DELGADO
Tabla 26 – Arquitectura Línea Base - Listado de Procesos clínica Delgado
I D P R O C E S O F U N C I Ó N D E S C R I P C I Ó N D E L A F U N C I Ó N
1 Planeamiento Estratégico Gestionar el plan estratégico Gestionar, administrar el plan estratégico de la
empresa
2 Planificación y Desarrollo Planificar el desarrollo de la empresa Planificar las metas de la empresa y desarrollar los
objetivos para alcanzarlos
3 Marketing Estratégico de
los Servicios - Productos Gestionar el marketing estratégico
Se encarga de gestionar el marketing de los
servicios / Productos de la empresa, de manera
estratégica
4 Relaciones Institucionales Gestionar las relaciones institucionales Gestiona las relaciones institucionales con la
finalidad de que estén acorde con lo deseado
5 Gestión Legal Gestionar los temas legales Gestiona los temas legales de la empresa
6 Gestión de Calidad Gestionar la calidad en los procesos y servicios Gestiona y asegura la calidad en los procesos
7 Investigación y Docencia Realizar investigación en el ámbito médico y su
posterior docencia
Realiza las investigaciones en el ámbito médico
sobre temas aún no estudiados, y promueve la
docencia
106
I D P R O C E S O F U N C I Ó N D E S C R I P C I Ó N D E L A F U N C I Ó N
8 Gestión del Talento Clínico Gestiona el talento clínico Recluta, capacita, apoya, gestiona el talento clínico
humano y tecnológico
9 Emergencia Atención de pacientes por emergencia
Realiza la atención de todos los pacientes que
llegan a la clínica bajo condiciones clínicas de
emergencia
10 Consulta Externa Atención vía consulta externa Gestionar y atender a los pacientes en el ámbito de
consulta externa
11 Hospitalización
Convencional Gestionar la hospitalización Gestionar y atender los pacientes hospitalizados
12 Hosp. críticos UCI Gestionar la hospitalización UCI Gestionar y atender los pacientes hospitalizados
en UCI
13 Cirugía Ambulatoria Gestionar las cirugías ambulatorias Realizar las atenciones por cirugía ambulatoria
14 Cirugía de Hospitalización Gestionar cirugías con hospitalización Realizar las atenciones por cirugía y derivarlas a
hospitalización
15 Dx por imágenes Gestionar las atenciones de imágenes Realiza y gestiona las atenciones con solicitud de
imágenes
107
I D P R O C E S O F U N C I Ó N D E S C R I P C I Ó N D E L A F U N C I Ó N
16 Laboratorio Clínico Gestionar las atención de laboratorio clínico Realiza y gestiona las atenciones con solicitud de
laboratorio clínico
17 Laboratorio Anatomía
Patológica
Gestionar las atenciones de laboratorio de
anatomía patológica
Realiza y gestiona las atenciones de anatomía
patológica
18 Medicina Nuclear Gestión y atención especialidad Medicina Nuclear Administrar y realizar la atención clínica en las
especialidad de Medicina nuclear
19 Procedimientos Gestión y atención de procedimientos clínicos
Gestionar y realizar la atención de procedimientos
clínicos como endoscopia, tomografía, imágenes,
etc.
20 Farmacia Gestión de Farmacia Gestionar la Farmacia, inventarios, stock, ventas,
control de precios.
21 Radioterapia Gestión y atención Radioterapia Realizar la atención vía radioterapia y mantener el
control.
22 Banco de Sangre Gestión procesos Banco de Sangre
Realizar la atención al paciente, mediante entrega
de unidades de sangre para los procedimientos
requeridos
108
I D P R O C E S O F U N C I Ó N D E S C R I P C I Ó N D E L A F U N C I Ó N
23 Quimioterapia Gestión y atención Quimioterapia
Realizar la atención de Quimioterapia para un
paciente a manera de clínica de día, es decir,
ambulatoria
24 Medicina Física y
Rehabilitación
Gestión y atención medicina física y
rehabilitación
Realizar la atención de la especialidad de medicina
física y rehabilitación
25 Hemodiálisis Gestión y atención Hemodiálisis Realizar la atención al paciente de Hemodiálisis
26 Nutrición y Dietética Gestión nutrición y dietética
Realizar la atención al paciente, administrar los
alimentos en base a los requerimientos
nutricionales.
27 Admisión – Caja Gestión de admisión y caja
Realizar la atención del paciente en admisión,
previo al procedimiento clínico, y el cobro
correspondiente, posterior a la atención.
28 Gestión de citas Gestión de citas para consulta externa y
procedimientos
Gestionar las citas médicas, horarios,
disponibilidad.
29 Gestión de Agendas Gestión de agendas Gestionar las agendas del médico, feriados,
disponibilidad, atenciones
109
I D P R O C E S O F U N C I Ó N D E S C R I P C I Ó N D E L A F U N C I Ó N
30 Auditoría Médica Gestión de procesos de auditoría médica
Realizar la auditoría de los files del paciente, desde las
imputaciones de farmacia y prestaciones hasta su
aplicación en la cuenta del paciente, verificar coberturas
de medicamentos según
31 Cocina Gestión de cocina Realizar la atención de alimentos para los pacientes
32 Limpieza Procedimientos de limpieza Realizar la limpieza y mantener con la correcta limpieza
las instalaciones
33 Parking Asistencial Atención para parking asistencial Brindar soporte a los pacientes del parking de sus
vehículos
34 Hotelería Atención de hotelería clínica Mantener el correcto orden y limpieza de prendas como
batas, sábanas, almohadas, etc.
35 Transporte de
Pacientes Transportar a los pacientes hacia y de la clínica
Realizar el transporte de los pacientes desde y hacia la
clínica
36 Transporte de órganos Transporte de órganos desde y hacia la clínica Gestionar y realizar el transporte de los órganos desde y
hacia la clínica
110
I D P R O C E S O F U N C I Ó N D E S C R I P C I Ó N D E L A F U N C I Ó N
37 Central de
Esterilización
Realizar esterilización de implementos
quirúrgicos
Realizar la esterilización de todos los instrumentos
clínicos que lo requieran
38 Gestión de Clientes Seguimiento a los clientes principales (pacientes) Gestionar a los clientes (pacientes) a fin de fidelizarlos
con la clínica
39 Acompañamiento al
paciente Asistenta social ante diversas situaciones
Realizar el acompañamiento al paciente en su estancia en
la clínica y procurar que sea de calidad
40 Seguridad del
paciente
Garantizar la seguridad del paciente dentro de las
instalaciones
Verificar y garantizar la seguridad del paciente dentro de
las instalaciones
41 Seguridad física Garantizar la seguridad del personal y paciente
conforme las estructuras
Verificar y cumplir los lineamientos de seguridad física
establecidas en la clínica
42 Seguridad Industrial Garantizar las seguridad en los procesos de
insumos clínicos
Cumplir con los requerimientos de seguridad industrial
para insumos clínicos.
43 Gestión de crisis Gestionar las crisis en todo aspecto de la empresa Realizar el seguimiento y gestión de los planes de manejo
de crisis en la clínica
44 Gestión Logística Gestión de los procesos logísticos Proceso integral logístico, compras, stock, inventarios,
almacenes
111
I D P R O C E S O F U N C I Ó N D E S C R I P C I Ó N D E L A F U N C I Ó N
45 Gestión de residuos Gestión para la eliminación de residuos Asegurar la correcta eliminación de residuos
46 Lavandería Asegurar la limpieza de vestimenta de la clínica Realizar la lavandería de prendas
47 Soporte TI Asegurar el funcionamiento de los equipos TI Soporte a los procesos de la clínica, y servicios de TI
48 Mantenimiento Realizar el mantenimiento de las instalaciones Mantener las instalaciones de la clínica en buen estado
49 Control Patrimonial Gestión de los activos Control del patrimonio de la clínica
50 Ingeniería Clínica Gestionar Ingeniería clínica Revisión de ingeniería Clínica
51 Gestión y control
presupuestario Gestionar el control y presupuesto de la clínica
Realizar el presupuesto anual y el respectivo análisis de
las partidas ejecutadas versus las presupuestadas y
controlar que se cumplan y no excederse de lo
presupuestado
52 Contabilidad Realizar la contabilidad de la clínica Contabilizar las operaciones de la clínica y presentar la
información registrada en las entidades pertinentes.
53 Recaudación
(Tesorería) Realizar las operaciones de flujo monetario Realizar las operaciones de pagos y cobros, de gestionar
la caja y las distinta gestiones bancarias
54 Facturación Garantes Gestionar la facturación a garantes Revisar, analizar, ejecutar la facturación a garantes
(compañías aseguradoras) conforme a los contratos y
porcentajes establecidos.
112
I D P R O C E S O F U N C I Ó N D E S C R I P C I Ó N D E L A F U N C I Ó N
55 Liquidación Asistencial Realizar la liquidación de la cuenta del paciente Revisa, ejecuta, verifica la cuenta final del paciente
y su correspondiente liquidación
56 Marketing Realizar el marketing de la clínica Gestionar, evaluar y ejecutar el plan de marketing
de la clínica
57 Gestión de convenios Gestionar los distintos convenios contratados
Gestionar, verificar, y asegurar los contratos a
convenios efectuados, y la correspondiente
validación
58 Administración de personal Administrar al personal en las distintas funciones Administrar al personal y sus requerimientos
59 Salud en el trabajo Gestionar la salud ocupacional
Gestionar, controlar y verificar la salud ocupacional
y asegurar cumplir con los estándares de salud en el
trabajo
60 Relacionamiento Clínico Gestionar el relacionamiento clínico Verificar y mantener las relaciones clínicas en el
ámbito asistencial
61 Gestión documentaria Gestión documentaria de los procesos de la clínica Gestionar los documentos, llevar el control de los
mismos
62 Archivo clínico Administrar las historias clínicas de los pacientes Actualiza, mantener, administrar las historias
113
clínicas del paciente y mantenerlas en formato
digital
63 Gestión de la Información Gestionar correctamente la información Gestiona la información para los fines necesarios
Fuente: Elaboración propia
114
MATRIZ DE PROCESOS DE NEGOCIO VS OBJETIVOS DE NEGOCIO
Tabla 27 - Arquitectura Línea Base – Matriz Objetivos estratégicos vs Procesos – Parte 1
OBJETIVOS ESTRATÉGICOS
RED AUNA OBJETIVOS ESTRATÉGICOS CLÍNICA DELGADO
Pla
nea
mie
nto
Est
raté
gic
o
Pla
nif
ica
ció
n y
Des
arr
oll
o
Ma
rket
ing
Est
raté
gic
o
Rel
aci
on
es I
nst
itu
cio
na
les
Ges
tió
n L
ega
l
Ges
tió
n d
e C
ali
da
d
Inv
esti
ga
ció
n y
Do
cen
cia
Ges
tió
n d
el T
ale
nto
Clí
nic
o
Em
erg
enci
a
Co
nsu
lta
Ex
tern
a
Ho
spit
ali
zaci
ón
Co
nv
enci
on
al
Ho
spit
ali
zaci
ón
crí
tico
s -
UC
I
Cir
ug
ía A
mb
ula
tori
a
Cir
ug
ías
con
Ho
spit
ali
zaci
ón
Dx
. P
or
imá
gen
es
La
bo
rato
rio
Clí
nic
o
La
b. A
na
tom
ía P
ato
lógic
a
Med
icin
a N
ucl
ear
Pro
ced
imie
nto
s
Fa
rma
cia
Ra
dio
tera
pia
Posicionar la red Auna como la
primera opción de atención de
calidad al paciente
Asegurar reclutamiento de los mejores profesionales de salud x X x x x x x x x x x x x x x x x x x x x
Proporcionar una óptima atención médica a los pacientes
brindándole un servicio que satisfaga sus necesidades,
requerimientos y expectativas.
x X x x x x x x x x x x x X x x x x x x x
Incrementar el tráfico de pacientes x X x x x x x x
Ser líder en tecnología asistencial
que permita contar con
tecnología integrada en todos los
centros de la red Auna
Posicionar 3 centros de excelencia: Maternidad, Emergencia y
Cardiología x X x x
x x x x x x x x X
Brindar integración de información entre los tipos de atención
CEX, URG, HOS, CQX x X x x x x x x x x x x x X
Mantener tecnología de punta que proporcione el soporte a
todos los procesos de la clínica x X x x x x x x x x x x x X x x x x x x x
Brindar un ambiente de trabajo
de calidad al personal que
permita manejar un nivel de
compromiso con la red Auna
Lograr que cada empleado de la clínica trabaje conjuntamente
orientado hacia la cultura del paciente y sus familiares. x X x x
x x x x x x x x X x x x x x x x
Total 7 7 7 7 4 7 7 7 6 6 6 6 6 6 4 4 4 4 4 4 4
Porcentaje 100% 100% 100% 100% 71% 100% 100% 100% 86% 86% 86% 86% 86% 86% 57% 57% 57% 57% 57% 57% 57%
Fuente: Elaboración propia
115
Tabla 28- Arquitectura Línea Base – Matriz Objetivos estratégicos vs Procesos – Parte 2
OBJETIVOS ESTRATÉGICOS
RED AUNA OBJETIVOS ESTRATÉGICOS CLÍNICA DELGADO
Ban
co d
e S
ang
re
Qu
imio
tera
pia
Nu
tric
ión
y D
ieté
tica
Med
icin
a F
ísic
a y
reh
abil
itac
ión
Hem
od
iáli
sis
Ad
mis
ión
Caj
a
Ges
tió
n d
e ag
end
as
Ges
tió
n d
e C
itas
Co
cin
a
Lim
pie
za
Ho
tele
ría
Par
kin
g A
sist
enci
al
Au
dit
orí
a M
édic
a
Tra
nsp
ort
e d
e P
acie
nte
s
Tra
nsp
ort
e d
e ó
rgan
os
Cen
tral
de
Est
eril
izaci
ón
Ges
tió
n d
e cl
ien
tes
Aco
mp
añam
ien
to a
l p
acie
nte
Seg
uri
dad
del
Pac
ien
te
Seg
uri
dad
Fís
ica
Seg
uri
dad
In
du
stri
al
Posicionar la red Auna como la
primera opción de atención de
calidad al paciente
Asegurar reclutamiento de los mejores profesionales de salud x x x x x
Proporcionar una óptima atención médica a los pacientes brindándole
un servicio que satisfaga sus necesidades, requerimientos y
expectativas.
x x x x x
Incrementar el tráfico de pacientes
Ser líder en tecnología
asistencial que permita contar
con tecnología integrada en
todos los centros de la red Auna
Posicionar 3 centros de excelencia: Maternidad, Emergencia y
Cardiología
Brindar integración de información entre los tipos de atención CEX,
URG, HOS, CQX
Mantener tecnología de punta que proporcione el soporte a todos los
procesos de la clínica x x x x x x x x
Brindar un ambiente de trabajo
de calidad al personal que
permita manejar un nivel de
compromiso con la red Auna
Lograr que cada empleado de la clínica trabaje conjuntamente
orientado hacia la cultura del paciente y sus familiares. x x x x x x x x x x x x x x x x x x x x x
Total 4 4 4 4 4 2 2 2 1 1 1 1 1 1 1 1 1 1 1 1 1
Porcentaje 57% 57% 57% 57% 57% 29% 29% 29% 14% 14% 14% 14% 14% 14% 14% 14% 14% 14% 14% 14% 14%
Fuente: Elaboración propia
116
Tabla 29 - Arquitectura Línea Base – Matriz Objetivos estratégicos vs Procesos – Parte 3
OBJETIVOS ESTRATÉGICOS
RED AUNA OBJETIVOS ESTRATÉGICOS CLÍNICA DELGADO
Ges
tió
n d
e cr
isis
Ges
tió
n L
og
ísti
ca
Ges
tió
n d
e R
esid
uo
s
La
va
nd
ería
So
po
rte
TI
Ma
nte
nim
ien
to
Co
ntr
ol
Pa
trim
on
ial
Ing
enie
ría
Clí
nic
a
G. y
Co
ntr
ol
Pres
up
ues
tal
Co
nta
bil
ida
d
Rec
au
da
ció
n
Fa
ctu
raci
ón
Ga
ran
tes
Liq
uid
aci
ón
Asi
sten
cia
l
Ma
rket
ing
Ges
tió
n d
e co
nv
enio
s
Ad
min
. d
e p
erso
na
l
Sa
lud
en
el
tra
ba
jo
Rel
aci
on
am
ien
to C
lín
ico
Arc
hiv
o C
lín
ico
Ges
tió
n d
ocu
men
tari
a
Ges
tió
n d
e la
In
form
aci
ón
Posicionar la red Auna como la
primera opción de atención de
calidad al paciente
Asegurar reclutamiento de los mejores profesionales de salud
x
Proporcionar una óptima atención médica a los pacientes brindándole
un servicio que satisfaga sus necesidades, requerimientos y
expectativas.
Incrementar el tráfico de pacientes
Ser líder en tecnología asistencial
que permita contar con
tecnología integrada en todos los
centros de la red Auna
Posicionar 3 centros de excelencia: Maternidad, Emergencia y
Cardiología
Brindar integración de información entre los tipos de atención CEX,
URG, HOS, CQX
Mantener tecnología de punta que proporcione el soporte a todos los
procesos de la clínica x
x x
x
x
Brindar un ambiente de trabajo
de calidad al personal que
permita manejar un nivel de
compromiso con la red Auna
Lograr que cada empleado de la clínica trabaje conjuntamente
orientado hacia la cultura del paciente y sus familiares. x x x x x x x x x x x x x x x x x x x x x
Total 1 1 1 1 2 1 1 1 1 1 1 2 2 1 2 1 1 2 1 1 2
Porcentaje 14% 14% 14% 14% 29% 14% 14% 14% 14% 14% 14% 29% 29% 14% 29% 14% 14% 29% 14% 14% 29%
Fuente: Elaboración propia
117
ROLES DE NEGOCIO
Tabla 30 – Arquitectura Línea Base - Matriz de Asignación de Responsabilidades (RAM): A: Apoya, R: Registra y M: Modifica
PROCESOS / ÁREAS
Ger
enci
a G
ener
al
Dir
ecci
ón
Méd
ica
Ger
enci
a C
om
erci
al
Adm
in y
Op
erac
ion
es
Rec
urs
os
Hum
ano
s
Ex
per
ienci
a C
lien
te
Con
tro
l d
e G
esti
ón
Pro
ceso
s, c
alid
ad y
segu
rid
ad a
l P
acie
nte
Cre
den
cial
es y
Pri
vil
egio
s
Ep
idem
iolo
gía
Coo
rd S
erv
icio
s
Méd
icos
Dir
ecto
r T
écn
ico
En
ferm
ería
Aud
ito
ría
Méd
ica
Ase
gu
rado
s B
rook
er
Sal
ud
Mu
jer
Pro
du
cto
s D
elg
ado
Bra
nd
ing
Adm
isió
n
Adm
inis
trac
ión
y
Lo
gís
tica
Infr
aest
ruct
ura
Fac
tura
ción
Ingen
ierí
a C
lín
ica
TI
Fin
anza
s
Leg
al
Abas
teci
mie
nto
Rel
. In
stit
uci
on
ales
Con
tro
l In
tern
o
Planeamiento Estratégico R A A A A A A A A M
Planificación y Desarrollo R A A A A A A A A M
Marketing Estratégico de
los Servicios – Productos A A A A A RM A
Relaciones Institucionales A R
M
Gestión Legal A R RM
Gestión de Calidad A A R
Investigación y Docencia A AR A M
Gestión del Talento Clínico AR AM
Emergencia R A A A A A RM A A M A A A A A A A
Consulta Externa R A A A A A RM A A M A A A A A A
Hospitalización
Convencional R A A A A A RM A A M A A A A A A
Hospitalización de críticos
– UCI R A A A A A RM A A M A A A A A A
Cirugía Ambulatoria R A A A A A RM A A M A A A A A A
Cirugía de Hospitalización R A A A A A RM A A M A A A A A A
118
PROCESOS / ÁREAS
Ger
en
cia
Gen
era
l
Dir
ecció
n M
édic
a
Ger
en
cia
Com
ercia
l
Ad
min
y O
per
acio
nes
Recu
rso
s H
um
an
os
Ex
per
ien
cia
Cli
en
te
Co
ntr
ol
de G
est
ión
Pro
ces
os,
ca
lid
ad
y
seg
urid
ad
al
Pa
cie
nte
Cred
en
cia
les
y
Pri
vil
eg
ios
Ep
idem
iolo
gía
Coo
rd
Ser
vic
ios
Méd
ico
s
Dir
ecto
r T
écn
ico
En
ferm
ería
Au
dit
oría
Méd
ica
Ase
gu
rad
os
Bro
ok
er
Sa
lud
Mu
jer
Pro
du
cto
s D
elg
ad
o
Bra
nd
ing
Ad
mis
ión
Ad
min
istr
ació
n y
Log
ísti
ca
Infr
aest
ru
ctu
ra
Fa
ctu
ració
n
Ing
en
iería
Clí
nic
a
TI
Fin
an
zas
Lega
l
Ab
ast
ecim
ien
to
Rel.
In
stit
ucio
na
les
Co
ntr
ol
Inte
rn
o
Dx por imágenes A A A A RM A A A A A A
Laboratorio Clínico A A A A RM A A A A A A
Laboratorio Anatomía
Patológica A A A A RM A A A A A A
Medicina Nuclear A A A A RM A A A A A A
Procedimientos A A A A RM A A A A A A
Farmacia A A A A RM A A A A A A
Radioterapia A A A A RM A A A A A A
Banco de Sangre A A A A RM A A A A A A
Quimioterapia A A A A RM A A A A A A
Medicina Física y
Rehabilitación A A A A RM A A A A A A
Hemodiálisis A A A A RM A A A A A A
Nutrición y Dietética A A A A RM A A A A A A
Admisión – Caja RM A A A A A RM A A A
Gestión de citas RM A A RM A
Gestión de Agendas RM A A RM A
Auditoría Médica A A A A A RM A A A A
119
PROCESOS / ÁREAS
Ger
en
cia
Gen
era
l
Dir
ecció
n M
édic
a
Ger
en
cia
Com
ercia
l
Ad
min
y
Op
era
cio
nes
Recu
rso
s H
um
an
os
Ex
per
ien
cia
Cli
en
te
Co
ntr
ol
de G
est
ión
Pro
ces
os,
ca
lid
ad
y
seg
urid
ad
al
Pa
cie
nte
Cred
en
cia
les
y
Pri
vil
eg
ios
Ep
idem
iolo
gía
Coo
rd
Ser
vic
ios
Méd
ico
s
Dir
ecto
r T
écn
ico
En
ferm
ería
Au
dit
oría
Méd
ica
Ase
gu
rad
os
Bro
ok
er
Sa
lud
Mu
jer
Pro
du
cto
s D
elg
ad
o
Bra
nd
ing
Ad
mis
ión
Ad
min
istr
ació
n y
Log
ísti
ca
Infr
aest
ru
ctu
ra
Fa
ctu
ració
n
Ing
en
iería
Clí
nic
a
TI
Fin
an
zas
Lega
l
Ab
ast
ecim
ien
to
Rel.
In
stit
ucio
na
les
Co
ntr
ol
Inte
rn
o
Cocina A RM
Limpieza A RM
Parking Asistencial A RM
Hotelería A RM
Transporte de Pacientes A A A A RM
Transporte de órganos RM A A A A A A
Central de Esterilización A A A RM A
Gestión de Clientes A
Acompañamiento al
paciente A
R
M A R A A A
Seguridad del paciente A A A A A RM A
Seguridad física A RM A
Seguridad Industrial A A R A RM
Gestión de crisis A A R R M
Gestión Logística A RM RM
Gestión de residuos A A RM
Lavandería RM
Soporte TI A RM
120
PROCESOS / ÁREAS
Ger
en
cia
Gen
era
l
Dir
ecció
n M
édic
a
Ger
en
cia
Com
ercia
l
Ad
min
y
Op
era
cio
nes
Recu
rso
s H
um
an
os
Ex
per
ien
cia
Cli
en
te
Co
ntr
ol
de G
est
ión
P
roces
os,
ca
lid
ad
y
seg
urid
ad
al
Pa
cie
nte
C
red
en
cia
les
y
Pri
vil
eg
ios
Ep
idem
iolo
gía
Coo
rd
Ser
vic
ios
Méd
ico
s
Dir
ecto
r T
écn
ico
En
ferm
ería
Au
dit
oría
Méd
ica
Ase
gu
rad
os
Bro
ok
er
Sa
lud
Mu
jer
Pro
du
cto
s D
elg
ad
o
Bra
nd
ing
Ad
mis
ión
Ad
min
istr
ació
n y
Log
ísti
ca
Infr
aest
ru
ctu
ra
Fa
ctu
ració
n
Ing
en
iería
Clí
nic
a
TI
Fin
an
zas
Lega
l
Ab
ast
ecim
ien
to
Rel.
In
stit
ucio
na
les
Co
ntr
ol
Inte
rn
o
Mantenimiento A A RM A
Control Patrimonial RM A
Ingeniería Clínica A A A
Gestión y control
presupuestario A A A R RM
Contabilidad A A RM A
Recaudación (Tesorería) A A RM A
Facturación Garantes A M RM M
Liquidación Asistencial A M RM M
Marketing A A A M M
Gestión de convenios A A RM RM
Administración de
personal RM A A A A
Salud en el trabajo A A A
Relacionamiento Clínico A A RM M
Archivo clínico A A RM RM
Gestión documentaria A RM M
Gestión de la Información A A RM M
Fuente: Elaboración propia
121
PROCESO SELECCIONADO
El macroproceso seleccionado es Procedimientos Terapéuticos, este macroproceso es core del
negocio ya que la Clínica Delgado cuenta con 7 pisos de hospitalización con un total de 134
camas, teniendo un flujo mínimo de 200 transfusiones de sangre mensualmente.
Este macroproceso soporta los objetivos estratégicos indicados en la empresa y fortalecen el
negocio para lo cual tiene siete procesos Farmacia, Quimioterapia, Nutrición y Dietética,
Radioterapia, Medicina Física y Rehabilitación, Hemodiálisis y Banco de Sangre siendo este
último el objeto de estudio, donde veremos la gestión integral de las unidades de sangre
disponibles y requeridas, cuentan con los siguientes sub procesos:
- Donación de sangre
- Transfusión de sangre
122
MODELO DE DATOS DEL NEGOCIO
D O N A C I Ó N
No Aplica
T R A N S F U S I Ó N
Figura 18 – Arquitectura Línea Base - Modelo de datos de Negocio – Donación de Sangre
Fuente: Elaboración propia
123
DIAGRAMA DE PROCESO – DONACIÓN DE SANGRE
Figura 19 - Arquitectura Línea Base – Diagrama de flujo de proceso de Registro Donación de Sangre
Fuente: Elaboración propia
124
Figura 20 - Arquitectura Línea Base – Diagrama de flujo de proceso de Donación de Sangre
Fuente: Elaboración propia
125
Tabla 31 - Arquitectura Línea Base – Entradas y Salidas de proceso Donación de sangre
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE
TIPO DE
ACTIVIDAD
DURACIÓN
1 Llamada de
donante Recepción de llamada
Recibe llamada y
comunica a donante el
proceso básico para la
donación
Enfermera Manual 5 minutos
2
Comunica a donante
fecha y hora de
atención
Agenda de
donación
Valida fecha y hora
disponible y comunica al
donante la información
Enfermera Manual 3 minutos
3 Documento de
identidad
Recibir y confirmar
identificación del
donante
Se recibe al donante y se
valida su identificación Enfermera Manual 8 minutos
4
Confirmar ingreso de
donante a banco de
sangre
Se registra hora de entrada
en archivo Excel Enfermera Manual 2 minutos
5 Formulario de
donación
Comunica llenado de
formulario
Entrega formulario e
indica campos a rellenar a
donante
Enfermera Manual 3 minutos
126
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE
TIPO DE
ACTIVIDAD
DURACIÓN
6 Rellena formulario Formulario de
donación
Procede a rellenar
formulario con su
información personal
Donante Manual 15 minutos
7 Formulario de
donación
Validación de
formulario
Se procede a validar que
toda la información este
completa
Enfermera Manual 3 minutos
8
Formulario de
donación
Entrevista personal
Formulario de
donación
aceptada
Validara formulario y
adicionara preguntas
personales
Médico
Patólogo Manual 10 minutos
9 Tomar Signos Vitales Formulario de
signos vitales
Se procede a tomar los
signos vitales a donante Enfermera Manual 10 minutos
10 Formulario de
signos vitales Evaluar a donante
Formulario de
signos vitales
aceptado
Evalúa al donante según
los datos derivados de
signos vitales
Médico Manual 10 minutos
11 Realiza donación Se realiza la extracción de
la sangre Enfermera Manual 15 minutos
12 Registro del resultado Documento de Registra la información Médico Manual 10 minutos
127
resultado de
donación
sobre algún incidente
durante y al término de la
donación
Patólogo
13 Formulario de
sangre
Evaluar estado de
sangre
Se evalúa estado de la
sangre Laboratorista Sistema 7 horas
14 Resultado de
evaluación
Resultado de
sangre
Resultado de la sangre si
presenta alguna
observación
Laboratorista Sistema 10 minutos
15 Código de etiqueta
de sangre Almacenar sangre
Se almacena sangre con
sus principales
características
Laboratorista Manual 15 minutos
Fuente: Elaboración propia
128
DIAGRAMA DE PROCESO – TRANSFUSIÓN DE SANGRE
Figura 21 - Arquitectura Línea Base – Diagrama de flujo Proceso Transfusión de Sangre
Fuente: Elaboración propia
129
Tabla 32 - Arquitectura Línea Base – Entradas y Salidas de proceso Transfusión de sangre
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN
RESPONSABL
E
TIPO DE
ACTIVIDAD
DURACIÓN
1 Solicitud de
transfusión Pedido de transfusión
Recepción de solicitud de
transfusión de sangre
Médico
tecnólogo Manual 10 minutos
2 Revisión de sangre
Se valida grupo sanguíneo
de paciente con el
registrado en su historia
clínica
Enfermera Manual 10 minutos
3 Solicitud de
transfusión Registro de pedido Etiqueta
Se ingresa pedido al
sistema de banco de sangre
E-Delphyn e imprime
etiqueta
Médico
tecnólogo Manual 10 minutos
4 Extracción de sangre Se extrae muestra de
sangre de paciente Enfermera Manual 20 minutos
5 Solicitud de
transfusión Retiro de sangre
Se retira unidad elegida
del banco de sangre para
comparativo
Técnico
especializado Manual 20 minutos
6 Prueba cruzada Resultados de
prueba
Se realiza comparativo de
muestra extraída de
paciente con la elegida del
Médico
tecnólogo Sistema 2 horas
130
banco de sangre
7 Se libera unidades de
sangre
Bolsa de
sangre
Se libera unidades de
sangre solicitadas
Médico
tecnólogo Manual 30 minutos
8 Aplicar transfunde Se realiza transfusión a
paciente Enfermera Manual 20 minutos
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN
RESPONSABL
E
TIPO DE
ACTIVIDAD
DURACIÓN
9 Devolución de bolsa
de sangre
Se devuelve bolsa de
sangre utilizada Enfermera Manual 20 minutos
10 Registra transfusión Se registra transfusión y
elimina la bolsa
Médico
tecnólogo Sistema 20 minutos
Fuente: Elaboración propia
131
2.5.4.2 ARQUITECTURAS DE SISTEMAS DE INFORMACIÓN
ARQUITECTURA DE DATOS
La arquitectura de datos, estructura de datos, declarada en la Clínica Delgado para los
procesos elegidos en el análisis del presente trabajo se muestra a continuación:
MODELO LÓGICO DEL PROCESO DONACIÓN DE SANGRE
En la actualidad no se cuenta con un sistema para el proceso de Donación de sangre y todo el
flujo es de manera manual, por ello no se cuenta con el modelo conceptual.
132
MODELO LÓGICO DE TRANSFUSIÓN DE SANGRE
Figura 22 - Arquitectura Línea Base – Modelo Lógico del Proceso Transfusión de Sangre
Fuente: Elaboración propia
133
Tabla 33 - Arquitectura Línea Base – Descripcion Modelo Lógico
I D O B J E T O D E N E G O C I O D E S C R I P C I Ó N
1 USUARIO Es la tabla que almacena toda
información del usuario solicitante.
2 SOLICITUD_TRANSFERENCIA Contiene datos del paciente con la
cantidad de sangre que solicita.
3 MUESTRA_SANGRE Contiene la solicitud para sacar la
muestra de sangre.
4 PRUEBA_CRUZADA Contiene el estado de la prueba cruzada.
5 ALMACEN
Es la tabla donde se almacena la
información de la sangre que se tiene con
la característica de cada tipo.
Fuente: Elaboración propia
134
ARQUITECTURA DE APLICACIÓN
La arquitectura de aplicaciones de los subprocesos en análisis son declarados en el siguiente
diagrama
Figura 23 - Arquitectura Línea Base – Arquitectura de aplicaciones / Diagrama de
aplicaciones
Fuente: Elaboración propia
135
Tabla 34 - Arquitectura Línea Base – Arquitectura de aplicaciones / Componentes
ID Componente Descripción
1 xHIS
ERP Asistencial, contiene los módulos de
Estación médica, Central de enfermeras,
bloque quirúrgico, Liquidación,
facturación, Admisión, Urgencias,
Confirmación de citas.
2 xFarma
Módulo correspondiente a Farmacia,
movimientos de stock, dispensación de
carros de unidosis, órdenes médicas
3 eHC Módulo de Historia Clínica electrónica
4 HPresc Módulo de Prescripciones médicas
5 xGPC Módulo de Peticiones de procedimientos
6 Rispacs Módulo de imágenes, Rx, Tomografías
7 Endoc Módulo de endoscopia
8 Omega Módulo de laboratorio
9 SAP ERP operativo, logística y finanzas
10 BMatic Gestor de colas
11 E-Delphyn Software de banco de sangre
Fuente: Elaboración propia
136
2.5.4.3 ARQUITECTURA TECNOLÓGICA
La arquitectura tecnológica declara para los subprocesos, muestra el servidor único e
independiente “GSPEDELPHYN” y luego dos grupos de servidores los cuales conectan la
información mediante el sistema integrador llamado Mirth, el detalle se encuentra en el
siguiente cuadro.
Figura 24 - Arquitectura Línea Base – Arquitectura tecnológica / Diagrama de infraestructura
Fuente: Elaboración propia
137
Tabla 35 - Arquitectura Línea Base – Arquitectura Tecnológica/ Componentes de
Infraestructura
ID Infraestructura Descripción
1 GSPLMOISOFT01 Servidor Citrix ERP HIS, sede Clínica
Delgado
2 GSPLMOISOFT06 Servidor Citrix ERP HIS, sede Clínica
Delgado
3 GSPLMOISOFT07 Servidor Citrix ERP HIS, sede Clínica
Delgado
4 GSPEDELPHYN Servidor de banco de sangre E-Delphyn
5 GSPLMOHISEB Servidor Citrix ERP HIS, sede Clínica
Delgado
6 GSPLMOFS01 Servidor Citrix ERP HIS, sede Clínica
Delgado
7 AUNSNBCX02 Servidor Citrix ERP HIS, sede Call Center
8 GSPLMOISOFT05 Servidor Citrix ERP HIS, sede Call Center
9 GSPHISPRD Servidor de Base de Datos ERP HIS
10 GSPLMOISOFT04
Servidor del integrador Mirth, tiene como
función integrar los sistemas brindando
información de pase de un sistema a otro
11 GSPERPPRD Servidor del ERP SAP
12 AUNMOLCAS1 Servidor del sistema RISPACS (Módulo
Imágenes)
13 GSPLMOAP03 Servidor del sistema Omega (Laboratorio)
14 GSPDELAD01 Servidor del gestor de cola BMatic
15 Cliente Clínica Delgado Estaciones de trabajo ubicadas en la Clínica
Delgado
16 Cliente Call Center Estaciones de trabajo ubicadas en la estación
de Call Center
Fuente: Elaboración propia
138
2.5.5 FUNDAMENTO Y JUSTIFICACIÓN DEL ENFOQUE
ARQUITECTÓNICO
En el proceso de Banco de sangre que es el proceso elegido para el desarrollo de este
proyecto profesional se tienen 2 sub procesos que son Donación de Sangre y Transfusión de
sangre, en base al análisis de la situación actual de ambos procesos en cada una de las
arquitecturas se observaron los siguientes problemas:
En el proceso de donación de sangre:
La encuesta que se realiza a los donantes y el formulario de donación se realizan de
forma manual y posteriormente se archivan en un espacio físico.
Se observa que la cantidad de donaciones que se tiene es muy baja debido a que el
proceso toma mucho tiempo y los donadores deciden no regresar a donar.
El banco de sangre no cuenta con las unidades suficientes para poder atender con
todos los requerimientos de transfusiones de sangre de los pacientes de la clinica
Delgado.
En el proceso de Transfusión de sangre:
El proceso de solicitud de transfusión es manual lo que permite tener muchos errores
en el llenado de datos, esto hace que el proceso tome mas tiempo de lo debido.
La enfermera debe de trasladarse físicamente desde el piso donde se encuentra el
paciente hacia el banco de sangre para poder ver disponibildad de unidades de sangre
para la transfusión, esto hace que el proceso demore.
No existe una integración del sistema core de la clínica, en donde se encuentra toda la
información de los pacientes y las camas, con el sistema de Banco de sangre.
En base a los problemas encontrados, a continuación se plantea la propuesta de arquitectura
destino.
139
2.5.6 ARQUITECTURA DESTINO (TO BE)
2.5.6.1 ARQUITECTURA DE NEGOCIO
Para el caso de la Arquitectura de negocio, después de haber realizado el análisis de las
brechas, para el caso del proceso de Donación de Sangre lo que se propone es automatizar y
aumentar el numero de donantes a traves de una aplicación web y móvil. Para el caso del
proceso de Transfusión se propone la integración con el Sistem core de la Clinica Delgado,
que es el ERP xHIS con la finalidad de agilizar el proceso de transfusión de sangre asi como
tambien tener la data centralizada sobre transfusiones a pacientes de piso y emergencia, para
mostrar el esquema propuesto se detallan los flujos del proceso en base a la solución
propuesta:
140
DIAGRAMA DE PROCESO – DONACIÓN DE SANGRE – TO BE
Figura 25 - Arquitectura Destino – Diagrama de flujo de proceso Generar Cita Donación
Fuente: Elaboración propia
141
Figura 26 - Arquitectura Destino – Diagrama de flujo de proceso Donación de Sangre
Fuente: Elaboración propia
142
DIAGRAMA DE PROCESO – TRANSFUSIÓN DE SANGRE –TO BE
En este proceso se contempla que la propuesta para el esquema de transfusión debe tener una orden de transfusión automática que permita
hacer el pedido directamente en el sistema, con ello, se optimizarían los tiempos de solicitud y permita registrar esta información.
El módulo Transfusión se debe ubicar como opción en el ERP xHIS.
Figura 27 - Arquitectura Destino – Arquitectura de Negocio/ Flujo Transfusión de Sangre
Fuente: Elaboración propia
143
MODELO DE DATOS DEL NEGOCIO (MODELO CONCEPTUAL TO BE)
D O N A C I Ó N D E S A N G R E
Figura 28 – Arquitectura destino – Modelo de datos de negocio – Donación de Sangre
Fuente: Elaboración propia
144
T R A N S F U S I Ó N D E S A N G R E
Figura 29 – Arquitectura destino – Modelo de datos de negocio – Transfusión
Fuente: Elaboración propia
145
2.5.6.2 ARQUITECTURAS DE SISTEMAS DE INFORMACIÓN
ARQUITECTURA DE DATOS
En la arquitectura de datos TO BE, encontramos que se añadirán tablas ya existentes a este
esquema de datos propuesto para este subproceso, estas tablas corresponden a los nuevos
requerimientos, Avance de cuenta y App Móvil.
El modelo de datos que acogerá el App Móvil, es el modelo de datos ya existente por lo que
solo se deberá añadir tablas base de anotaciones adicionales que permitirá informar sobre los
cambios médicos.
146
MODELO DE DATOS LOGICO – DONACIÓN TO BE
Figura 30 - Arquitectura Destino – Modelo lógico del proceso de Donación de Sangre
Fuente: Elaboración propia
147
El modelo de datos que acogerá el Portal Web y App Móvil de donante, es nuevo y que se implementara en su totalidad.
Tabla 36 - Arquitectura destino – Descripcion Modelo Lógico
I D O b j e t o d e N e g o c i o D e s c r i p c i ó n
1 P E R S O N A C o n t i e n e i n f o r m a c i ó n g e n e r a l d e u n a p e r s o n a
2 D O N A N T E A l m a c e n a i n f o r m a c i ó n p e r s o n a l d e d o n a n t e
3 E X A M E N _ C L I N I C O A l m a c e n a i n f o r m a c i ó n d e t o d o s l o s e x a m e n e s d e l a n á l i s i s c l í n i c o
4 A L M A C E N A l m a c e n a i d e n t i f i c a c i ó n d e l a l m a c é n d e s a n g r e
5 S A N G R E _ D O N A D A A l m a c e n a l a s u n i d a d e s d o n a d a s
6 R E S E R V A _ S A N G R E A l m a c e n a i n f o r m a c i ó n d e l a c a n t i d a d d e u n i d a d e s d e s a n g r e e x i s t e n t e
7 R E P O R T E _ D E _ A N Á L I S I S _ C
L Í N I C O
A l m a c e n a r e s u l t a d o s d e l a n á l i s i s d e l c l í n i c o d e l a s a n g r e
8 D O N A C I O N C o n t i e n e l a i n f o r m a c i ó n d e l r e s u l t a d o d e l a s a n g r e
9 P R E G U N T A S _ E N C U E S T A C o n t i e n e l a i n f o r m a c i ó n d e l p r e - f o r m u l a r i o d e e v a l u a c i ó n a d o n a n t e s
10 E N C U E S T A C o n t i e n e l a i n f o r m a c i ó n d e t o d a s l a s e n c u e s t a s r e a l i z a d a s
11 M E D I C O R e g i s t r a l a i n f o r m a c i ó n d e l m é d i c o y l a s r e c o m e n d a c i o n e s p a r a e l d o n a n t e
12 F O R M U L A R I O R e g i s t r a i n f o r m a c i ó n r e s p o n d i d a a l a s p r e g u n t a s r e s p o n d i d a s d e l p a c i e n t e
Fuente: Elaboración propia
148
MODELO DE DATOS LOGICO – TRANSFUSIÓN TO BE
Figura 31 - Arquitectura Destino – Modelo lógico del proceso de Transfusión
Fuente: Elaboración propia
149
Para la arquitectura de datos de este proceso se integrara con las siguientes tablas que permitirá automatizar el envío y recepción de información
asignado a un paciente para su posterior tratamiento.
Tabla 37 - Arquitectura destino – Descripcion Modelo Lógico Transfusiones
I D O B J E T O D E N E G O C I O D E S C R I P C I Ó N
1 MUESTRA_SANGRE En esta entidad se registran la ID de la muestra de sangre del
paciente
2 PRUEBA_CRUZADA Tabla de información que guarda resultados de prueba cruzada
3 TRANSFUSION Almacena incidencias de la transfusión
4 ALMACEN Almacena información del tipo de sangre
5 RESERVA_SANGRE Almacena información de disponibilidad de unidades de sangre
6 TRANSFUSIÓN Almacena información de la transfusión
7 HISTORIA_CLÍNICA Almacena toda la información de su historia clínica
8 MEDICOS Almacena ID de médico
9
ENFERMERA Almacena ID de la enfermera
10 SOLICITUD_TRANSFEREN Almacena las hojas de solicitud de transfusiones.
150
CIA
11 PACIENTE Almacena información del paciente
12 CENTROS Lista de centros registrados en la red Auna
13 CLIENTES Registra los pacientes-clientes de la institución
14 HABITACION Se almacenan los tipos de habitación posibles
15 PERSONA Almacena información de los datos personales de médicos,
enfermera y paciente
Fuente: Elaboración propia
151
ARQUITECTURA DE APLICACIONES
Para el proceso de Donación de Sangre
Se incluirá dentro del diagrama de aplicaciones, las nuevas generadas a partir de los
requerimientos:
Aplicación Web y Móvil del Donante
Figura 32 - Arquitectura Destino – Arquitectura de Aplicaciones / Donación de Sangre
Fuente: Elaboración propia
152
Tabla 38 - Arquitectura Línea Base – Arquitectura de Aplicaciones / Donación de Sangre
ID COMPONENTE DESCRIPCIÓN
1 xHIS
ERP Asistencial, contiene los módulos de Estación
médica, Central de enfermeras, bloque quirúrgico,
Liquidación, facturación, Admisión, Urgencias,
Confirmación de citas.
2 xFarma
Módulo correspondiente a Farmacia, movimientos
de stock, dispensación de carros de unidosis,
órdenes médicas
3 eHC Módulo de Historia Clínica electrónica
4 Hpresc Módulo de Prescripciones médicas
5 xGPC Módulo de Peticiones de procedimientos
6 Rispacs Módulo de imágenes, Rx, Tomografías
7 Endoc Módulo de endoscopia
8 Omega Módulo de laboratorio
9 SAP ERP operativo, logística y finanzas
10 Bmatic Gestor de colas
11 Banco Sangre Portal Web y App móvil del donante
Fuente: Elaboración propia
153
Para el Proceso de Transfusión de Sangre
Esta arquitectura sufre modificaciones, ya que en este proceso se manejara
ERP xHIS de manera indepenediente pero se ahora se requiere integrar con la
aplicación de Banco de Sangre E-Delphyn.
Figura 33 - Arquitectura Destino – Arquitectura de aplicaciones / Transfusión de sangre
Fuente: Elaboración propia
154
Tabla 39 - Arquitectura Línea Base – Arquitectura de Aplicaciones / Transfusión de Sangre
ID COMPONENTE DESCRIPCIÓN
1 xHIS
ERP Asistencial, contiene los módulos de Estación
médica, Central de enfermeras, bloque quirúrgico,
Liquidación, facturación, Admisión, Urgencias,
Confirmación de citas.
2 xFarma
Módulo correspondiente a Farmacia, movimientos
de stock, dispensación de carros de unidosis,
órdenes médicas
3 eHC Módulo de Historia Clínica electrónica
4 Hpresc Módulo de Prescripciones médicas
5 xGPC Módulo de Peticiones de procedimientos
6 Rispacs Módulo de imágenes, Rx, Tomografías
7 Endoc Módulo de endoscopia
8 Omega Módulo de laboratorio
9 SAP ERP operativo, logística y finanzas
10 Bmatic Gestor de colas
11 E-DELPHYN Aplicación de gestión de banco de sangre
Fuente: Elaboración propia
155
ARQUITECTURA TECNOLÓGICA
Para el proceso Donación de Sangre
La arquitectura tecnológica del modelo propuesto incluye un servidor adicional y
terminales de conexión para la nueva aplicación.
Figura 34 - Arquitectura Destino –Arquitectura Tecnológica / Donación de Sangre
Fuente: Elaboración propia
156
Tabla 40 - Arquitectura Destino – Arquitectura Tecnológica / Donación de Sangre
ID Infraestructura Descripción
1 GSPLMOISOFT01 Servidor Citrix ERP HIS, sede Clínica
Delgado
2 GSPLMOISOFT06 Servidor Citrix ERP HIS, sede Clínica
Delgado
3 GSPLMOISOFT07 Servidor Citrix ERP HIS, sede Clínica
Delgado
4 GSPLMOHISEB Servidor Citrix ERP HIS, sede Clínica
Delgado
5 GSPLMOFS01 Servidor Citrix ERP HIS, sede Clínica
Delgado
6 AUNSNBCX02 Servidor Citrix ERP HIS, sede Call Center
7 GSPLMOISOFT05 Servidor Citrix ERP HIS, sede Call Center
8 GSPHISPRD Servidor de Base de Datos ERP HIS
9 GSPLMOISOFT04
Servidor del integrador Mirth, tiene como
función integrar los sistemas brindando
información de pase de un sistema a otro
10 GSPERPPRD Servidor del ERP SAP
11 AUNMOLCAS1 Servidor del sistema RISPACS (Módulo
Imágenes)
12 GSPLMOAP03 Servidor del sistema Omega (Laboratorio)
13 GSPDELAD01 Servidor del gestor de cola BMatic
14 Cliente Clínica Delgado Estaciones de trabajo ubicadas en la Clínica
Delgado
15 Cliente Call Center Estaciones de trabajo ubicadas en la estación
de Call Center
17 Banco Sangre Servidor que alojará la aplicación del Portal
157
Web y App Móvil de Donante
19 Portal Web Donante Terminal que usará el donante para
conectarse al portal
20 App Móvil Donante Terminal móvil que usará el donante para
conectarse al app Móvil
Fuente: Elaboración propia
Para el proceso de Transfusión de Sangre
De la mano con la problemática de Lentitud de la aplicación, encontramos que la
arquitectura tecnológica en este proceso se modificará incluyendo un servidor
adicional que permitan balancear la carga de la operación y la integración del servidor
E-DELPHYN con xHIS.
Figura 35 - Arquitectura Destino –Arquitectura Tecnológica / Transfusión de Sangre
Fuente: Elaboración propia
158
Tabla 41 - Arquitectura Destino – Arquitectura Tecnológica / Transfusión de Sangre
ID INFRAESTRUCTURA DESCRIPCIÓN
1 GSPLMOISOFT01 Servidor Citrix ERP HIS, sede Clínica Delgado
2 GSPLMOISOFT06 Servidor Citrix ERP HIS, sede Clínica Delgado
3 GSPLMOISOFT07 Servidor Citrix ERP HIS, sede Clínica Delgado
4 GSPLMOHISEB Servidor Citrix ERP HIS, sede Clínica Delgado
5 GSPLMOFS01 Servidor Citrix ERP HIS, sede Clínica Delgado
ID INFRAESTRUCTURA DESCRIPCIÓN
6 AUNSNBCX02 Servidor Citrix ERP HIS, sede Call Center
7 GSPLMOISOFT05 Servidor Citrix ERP HIS, sede Call Center
8 GSPHISPRD Servidor de Base de Datos ERP HIS
9 GSPLMOISOFT04
Servidor del integrador Mirth, tiene como función
integrar los sistemas brindando información de pase
de un sistema a otro
10 GSPERPPRD Servidor del ERP SAP
11 AUNMOLCAS1 Servidor del sistema RISPACS (Módulo Imágenes)
12 GSPLMOAP03 Servidor del sistema Omega (Laboratorio)
13 GSPDELAD01 Servidor del gestor de cola Bmatic
14 Cliente Clínica Delgado Estaciones de trabajo ubicadas en la Clínica Delgado
15 Cliente Call Center Estaciones de trabajo ubicadas en la estación de Call
Center
16 EDELPHYN Servidor de Banco de Sangre se integrara a los
servidores Citrix ERP HIS
20 GSPLMOISOFT21 Servidor adicional Citrix ERP HIS, sede Clínica
Delgado
Fuente: Elaboración propia
159
2.5.7 ANÁLISIS DE BRECHAS
Del análisis de la arquitectura empresarial mostrado en los puntos anteriores podemos
encontrar que el modelo ASIS presentado nos muestra la situación actual de los procesos en
la empresa, desde el punto de vista de la arquitectura de negocios, de datos, de aplicaciones y
tecnológica.
De esta revisión hemos definido el modelo TO BE propuesto a nivel de mejoras y solución de
problemas, y a continuación mostraremos el análisis de brechas que nos permitirá definir qué
estrategia utilizaremos para completar y llegar al modelo propuesto.
160
2.5.7.1 ARQUITECTURA DE NEGOCIO
DONACIÓN DE SANGRE
Tabla 42 - Análisis de Brechas / Arquitectura de Negocio / Donación de Sangre
Arquitectura Objetivo
Arquitectura Línea Base Recepción
de llamada
Comunicar a
donante
fecha y hora
de atención
Recibir y
confirmar
identificación
del donante
Confirmar
ingreso de
donante a
banco de
sangre
Comunicar
llenado de
formulario
Rellenar
formulario
Validación
de
formulario
Entrevista
Personal
Tomar
signos vitales
Evaluar al
donante
Realiza
donación
Recepción de llamada Se Mantiene
Comunicar a donante fecha y hora de
atención Eliminar
Recibir y confirmar identificación del
donante Se Mantiene
Confirmar ingreso de donante a banco de
sangre Eliminar
Comunicar llenado de formulario
Eliminar
Rellenar formulario
Eliminar
Validación de formulario
Eliminar
Entrevista Personal
Se Mantiene
Tomar signos vitales
Se Mantiene
Evaluar al donante
Se Mantiene
Realiza donación
Se Mantiene
161
Arquitectura Objetivo
Arquitectura Línea Base Registro del
resultado
Evaluar
estado de la
sangre
Resultado de
evaluación
Almacenar
Sangre
Crear
usuario de
donante en
portal o app
móvil
Registro de
información
personal
Elaboración
de pre
formulario
Generar cita Cancelar
cita
Re
programar
cita
Registro de
signos vitales
Registro del resultado Eliminar
Evaluar estado de la sangre Se mantiene
Resultado de evaluación Se mantiene
Almacenar sangre
Se
mantiene
Nuevo
Implementar Implementar Implementar Implementar Implementar Implementar Implementar
Arquitectura Objetivo
Arquitectura Línea Base
Registro de
incidentes de
donación
Recepción
de
resultados
Ingreso de
observaciones
del médico
del resultado
de sangre
Envió de
resultados a
donante
Visualizar
resultados
desde el
portal Web y
App Móvil
Consulta de
información
de donantes
Envió de
invitaciones
a donantes
para volver
a donar
Ingreso de
comentarios
del donante
Solicitar análisis de sangre
Nuevo Implementar Implementar Implementar Implementar Implementar Implementar Implementar Implementar Implementar
Fuente: Elaboración propia
162
TRANSFUSIÓN DE SANGRE
Tabla 43 - Análisis de Brechas / Arquitectura de Negocios / Transfusión de Sangre
Arquitectura Objetivo
Arquitectura
Línea Base
Pedido de
transfusión
Revisión de
sangre
Registro de
pedido
Extracción de
sangre Retiro de sangre Prueba cruzada
Se libera
unidades de
sangre
Aplicar
transfunde
Devolución de
bolsa de sangre
Pedido de transfusión Se mantiene
Revisión de sangre Se mantiene Registro de pedido Se mantiene
Extracción de sangre Se mantiene
Retiro de sangre Se mantiene
Prueba cruzada Se mantiene Se libera unidades de sangre Se mantiene
Aplicar transfunde Se mantiene
Devolución de bolsa de sangre Se mantiene
Registra transfusión
Pedido de transfusión Revisión de sangre Registro de pedido
Extracción de sangre
Retiro de sangre
Prueba cruzada
Se libera unidades de sangre
Aplicar transfunde
163
Arquitectura Objetivo
Arquitectura
Línea Base
Solicitud de
transfusión
Solicitud de perfil
pre-transfusional
Envió de datos
demográficos del
paciente
Modificación de
datos
demográficos
Envió de
realización de
transfusión
Envió de
incidentes post
transfusión
Resultados de
perfil pre
transfusional
Resultados de
prueba cruzada
Código de
reserva de bolsa
de sangre
Devolución de bolsa de sangre
Registra transfusión
Pedido de transfusión
Revisión de sangre
Registro de pedido
Extracción de sangre
Retiro de sangre
Prueba cruzada
Se libera unidades de sangre
Aplicar transfunde
Devolución de bolsa de sangre
Registra transfusión
Pedido de transfusión
Revisión de sangre
Registro de pedido
Extracción de sangre
Retiro de sangre Nuevo Implementar Implementar Implementar Implementar Implementar Implementar Implementar Implementar Implementar
Fuente: Elaboración propia
164
2.7.7.2 ARQUITECTURA DE SISTEMAS DE INFORMACIÓN
ARQUITECTURA DE DATOS
DONACIÓN DE SANGRE
Tabla 44 – Análisis de Brechas / Arquitectura de Datos / Donación de Sangre
Arquitectura Objetivo
Arquitectura
Línea Base PERSONA DONANTE
EXAMEN_C
ILINICO ALMACEN
SANGRE_D
ONADA
RESERVA_S
ANGRE
REPORTE_
DE_ANALIS
I_CLINICO
DONACIÓN
PREGUNTA
S_ENCUEST
A
ENCUESTA MEDICO FORMULARIO
NUEVO Implementar Implementar Implementar Implementar Implementar
Implementar Implementar Implementar Implementar Implementar Implementar Implementar
Fuente: Elaboración propia
165
TRANSFUSIÓN DE SANGRE
Tabla 45 – Análisis de Brechas / Arquitectura de Datos / Transfusión de Sangre – Parte 1
Arquitectura Objetivo
Arquitectura Línea Base
HISTORIA_
CLINICA PACIENTE ENFERMERA
MUESTRA_SA
NGRE
PRUEBA_CR
UZADA TRANSFUSION ALMACEN
SOLICITUD_TRANSFER
ENCIA
MEDICOS
HISTORIA_CLINICA Se mantiene
PACIENTE Se mantiene
ENFERMERA Se mantiene
MUESTRA_SAN Se mantiene
PRUEBA_CRUZADA Se mantiene
TRANSFUSION Se mantiene
ALMACEN_SANGRE Se mantiene
SOLICITUD_TRANSFERE
NCIA Se mantiene
MEDICOS
Se mantiene
Fuente: Elaboración propia
166
Tabla 46 – Análisis de Brechas / Arquitectura de Datos / Transfusión de Sangre – Parte 2
Arquitectura Obejtivo
Arquitectura Línea Base
SOLICITUD_TR
ANSFERENCIA CENTROS CLIENTES HABITACION PERSONA
HISTORIA_CLINICA PACIENTE ENFERMERA MUESTRA_SAN PRUEBA_CRUZADA TRANSFUSION ALMACEN_SANGRE SOLICITUD_TRANSFERE
NCIA MEDICOS ESPECIALIDADES NUEVO Implementar Implementar Implementar Implementar Implementar
Fuente: Elaboración propia
167
ARQUITECTURA DE APLICACIONES
DONACIÓN DE SANGRE
Tabla 47 - Análisis de Brechas / Arquitectura de Aplicaciones / Donación de Sangre
Fuente: Elaboración propia
Arquitectura Objetivo
Arquitectura
Línea Base xHIS xFarma eHC HPresc xGPC Rispacs Endoc Omega SAP EDelphyn
Portal Web
Donante
App Móvil
Donante
xHIS Se mantiene
xFarma
Se mantiene
eHC
Se mantiene
HPresc
Se mantiene
xGPC
Se mantiene
Rispacs
Se mantiene
Endoc
Se mantiene
Omega
Se mantiene
SAP
Se mantiene
EDelphyn
Se mantiene
Nuevo
Implementar Implementar
168
2.7.7.3 ARQUITECTURA TECNOLÓGICA
DONACIÓN DE SANGRE
Tabla 48 - Análisis de Brechas / Arquitectura de Tecnológica / Donación de Sangre – Parte 1
Fuente: Elaboración propia
Arquitectura Objetivo
Arquitectura
Línea Base
GS
PL
MO
ISO
FT
01
GS
PL
MO
ISO
FT
06
GS
PL
MO
ISO
FT
07
GS
PL
MO
HIS
EB
GS
PL
MO
FS
01
AU
NS
NB
CX
02
GS
PL
MO
ISO
FT
05
GS
PH
ISP
RD
GS
PL
MO
ISO
FT
04
GS
PE
RP
PR
D
AU
NM
OL
CA
S1
GSPLMOISOFT01 Se mantiene
GSPLMOISOFT06 Se mantiene
GSPLMOISOFT07 Se mantiene
GSPLMOHISEB Se mantiene
GSPLMOFS01 Se mantiene
AUNSNBCX02 Se mantiene
GSPLMOISOFT05 Se mantiene
GSPHISPRD Se mantiene
GSPLMOISOFT04 Se mantiene
GSPERPPRD Se mantiene
AUNMOLCAS1 Se mantiene
169
Tabla 49 - Análisis de Brechas / Arquitectura de Tecnológica / Donación de Sangre – Parte 3
Arquitectura Objetivo
Arquitectura
Línea Base
GS
PL
MO
AP
03
GS
PD
EL
AD
01
Cli
ente
Clí
nic
a
Del
ga
do
Cli
ente
Call
Cen
ter
SR
V B
an
co
Sa
ng
re
GSPLMOAP03 Se mantiene
GSPDELAD01 Se mantiene
Cliente Clínica Delgado Se mantiene
Cliente Call Center Se mantiene
NUEVO Implementar Fuente: Elaboración propia
170
TRANSFUSIÓN DE SANGRE
Tabla 50 - Análisis de Brechas / Arquitectura de Tecnológica / Transfusión de Sangre – Parte 1
Fuente: Elaboración propia
Arquitectura Objetivo
Arquitectura
Línea Base GSPLMOISOFT01 GSPLMOISOFT06 GSPLMOISOFT07 GSPLMOHISEB GSPLMOFS01 AUNSNBCX02 GSPLMOISOFT05 GSPHISPRD
GSPLMOISOFT01 Se mantiene
GSPLMOISOFT06 Se mantiene
GSPLMOISOFT07 Se mantiene
GSPLMOHISEB Se mantiene
GSPLMOFS01 Se mantiene
AUNSNBCX02 Se mantiene
GSPLMOISOFT05 Se mantiene
GSPHISPRD Se mantiene
171
Tabla 51 - Análisis de Brechas / Arquitectura de Tecnológica / Transfusión de Sangre – Parte 2
Arquitectura Objetivo
Arquitectura
Línea Base GSPLMOISOFT04 GSPERPPRD AUNMOLCAS1 GSPLMOAP03 GSPDELAD01
Cliente Clínica
Delgado
Cliente Call
Center EDelphyn GSPLMOISOFT20
GSPLMOISOFT04 Se mantiene
GSPERPPRD Se mantiene
AUNMOLCAS1 Se mantiene
GSPLMOAP03 Se mantiene
GSPDELAD01 Se mantiene
Cliente Clínica
Delgado Se mantiene
Cliente Call Center Se mantiene
EDelphyn Se mantiene
Nuevo
Implementar
Fuente: Elaboración propia
172
GAPS ARQUITECTURA DE NEGOCIO DONACION DE SANGRE
GAPS Arquitectura de Negocio
Implementar
El plan de acción para este caso es implementar los nuevos procesos descritos, para
ello se ejecutaran como proyecto de implementación de software que tendrá como
objetivo, cada uno de ellos, tener la aplicación móvil y de portal web de donante.
GAPS Arquitectura de Datos:
Implementar
El modelo de datos se implementara de cero, ya que para este caso, las mejoras
propuestas trabajaran en automatizar un proceso manual con ausencia de información.
GAPS Arquitectura de Aplicación
Implementar
El plan a seguir está en la implementación de dos nuevas aplicaciones para soportar la
propuesta definida del análisis realizado. En este caso incluiremos las aplicaciones
App Móvil Donante y Portal Web Donante.
GAPS Arquitectura Tecnológica
Implementar
Para dar soporte a lo establecido en los puntos anteriores, la estrategia será
complementar el modelo de infraestructura con un servidor que alojen estas
aplicaciones y respondan a los requerimientos establecidos en el proyecto.
GAPS ARQUITECTURA DE NEGOCIO TRANSFUSIÓN DE SANGRE
173
Implementar
El plan de acción a seguir para este caso es implementar las actividades dentro del
proceso de Transfusión de sangre, se implementara el módulo de Transfusión de
sangre, este es un módulo adicional al ERP xHIS, posteriormente se integrara con el
software EDelphyn.
GAPS Arquitectura de Datos:
Implementar
En este caso el modelo de datos se integrara con un conjunto de tablas que son parte
del proceso de transfusión, son 5 tablas para poder enviar y recibir la información que
viene de la mano con la actividad incluida en el punto anterior, estas tablas incluye
información de los esquemas de Hospitalización e Historia Clínica.
GAPS Arquitectura Tecnológica
Implementar
Si bien para la modificación del proceso no se requiere cambiar el esquema de
tecnología, es una problemática general la lentitud que presenta el sistema en distintos
rangos horarios, por lo que la estrategia en este caso es implementar la puesta en
marcha de un servidor Citrix adicional que permita balancear la carga de usuarios
conectados al esquema actual.
174
2.5.8 EVALUACIÓN DEL IMPACTO
Se empleará la matriz de probabilidad e impacto como apoyo para priorizar los riesgos.
La valoración que se asigna a cada riesgo es subjetiva y se basa en las siguientes tablas:
Tabla 52 – Valores para Probabilidad e Impacto
Probabilidad
Impacto
Nada probable 0.1
Muy bajo 0.05
Poco probable 0.3
Bajo 0.1
Medianamente probable 0.5
Moderado 0.2
Bastante probable 0.7
Alto 0.4
Muy probable 0.9
Muy alto 0.8
Fuente: Elaboración propia
La Matriz de Probabilidad e Impacto es una tabla de doble entrada que combina la
probabilidad de que ocurra un evento, con el impacto que éste puede causar en el Proyecto.
De esta manera, conseguimos establecer una priorización de los riesgos.
Tabla 53 – Matriz de Probabilidad e Impacto (escala relativa)
Probabilidad Amenazas Oportunidades
0.9 0.05 0.09 0.18 0.36 0.72 0.72 0.36 0.18 0.09 0.05
0.7 0.04 0.07 0.14 0.28 0.56 0.56 0.28 0.14 0.07 0.04
0.5 0.03 0.05 0.10 0.20 0.40 0.40 0.20 0.10 0.05 0.03
0.3 0.02 0.03 0.06 0.12 0.24 0.24 0.12 0.06 0.03 0.02
0.1 0.01 0.01 0.02 0.04 0.08 0.08 0.04 0.02 0.01 0.01
0.05 0.1 0.2 0.4 0.8 0.8 0.4 0.2 0.1 0.05
Impacto
Fuente : Elaboración propia
Finalmente, se listan los factores de riesgo que ponen en peligro el desarrollo del proyecto,
para este fin se evaluará la parte izquierda de la matriz, Amenazas.
175
Tabla 54 – Matriz de Análisis de riesgos
Fuente: Elaboración propia
N ° R i e s g o P r o b a b i l i d a d I m p a c t o R e s u l t a d o E s t r a t e g i a
1
Resistencia al cambio por parte de los médicos
y enfermeras respecto a la implementación del
aplicativo web y/o móvil de donante.
0.5 0.1 0.05
Realizar capacitaciones continuas sobre el nuevo
aplicativo sus funcionalidades y herramientas, y
comunicar anticipadamente su implementación.
2
Incremento en el tiempo y costo estimado para
el proyecto por no tener la disponibilidad al
100% de los recursos.
0.3 0.4 0.12
Asignación de recursos al 100% al proyecto para
lograr objetivo de tiempo y costo requerido, buscar
apoyo de Gerente de Operaciones y División de TI.
3
Disminución de la performance del aplicativo
core Xhis debido a que más usuarios en
simultáneo estarán haciendo uso por agregar el
módulo de transfusión de sangre.
0.3 0.4 0.12 Adquirir un nuevo servidor para balancear la carga
de concurrencia de usuarios al sistema Xhis.
4
No contar con los recursos técnicos necesarios
que puedan dar soporte a la propuesta de
negocio.
0.5 0.2 0.10
Brindar capacitaciones y manuales al equipo de
centro de servicios TI para que puedan brindar el
soporte a los aplicativos nuevos.
5
Actualización de versiones de software del
ERP xHIS que genere incompatibilidad con el
nuevo módulo de transfusión de sangre.
0.1 0.8 0.08 Solicitar a proveedor no generar actualizaciones
durante el periodo de dure el proyecto.
6 En la actualidad el equipo de TI no cuenta con
desarrolladores de aplicativos móviles. 0.3 0.2 0.06
Se requiere contratar un recurso externo
especializado en aplicaciones móviles para el
proyecto.
7
Incremento de costos del mantenimiento del
ERP-xHIS por un nuevo módulo e integración
con nuevos aplicativos (dependencia del
proveedor por ser el único proveedor local)
0.3 0.1 0.03 Realizar contratos que incluyan las tarifas a largo
plazo
176
2.9 OPORTUNIDADES Y SOLUCIONES
2.9.1 PLAN DE IMPLEMENTACIÓN Y MIGRACIÓN
2.9.1.1 DIRECCIÓN DE LA IMPLEMENTACIÓN ESTRATÉGICA
La Dirección de la implementación estratégica estará a cargo de Jefe de Desarrollo en
coordinación con la Gerencia de Operaciones TI y la Gerencia de Operaciones de Clínica
Delgado, para poder implementar la arquitectura destino, comprometiendo a todos los
involucrados en el proceso a cumplir con las nuevas actividades con la finalidad de tener una
transición sin complicaciones, además la contratación y coordinación con los proveedores de
desarrollo de la aplicación deberá ser controlada por Desarrollo TI con la finalidad de que se
desarrolle una herramienta que cubra todos los requerimientos funcionales identificados.
Generar la versión inicial y completa del plan de Itinerario de Arquitectura, basándose en el
análisis de brechas y en los componentes candidatos del plan de Itinerario de Arquitectura
resultantes de la arquitectura de Negocio, Sistemas de Información y Tecnológica.
Determinar si un enfoque incremental es requerido y si fuera así identificar las arquitecturas
de transición que proporcionaran valor continuo de negocio.
Para el presente proyecto se consideran las siguientes asunciones:
Se cuenta con servidores de contingencia que se puede utilizar para implementación.
Los recursos tecnológicos que tiene la organización soportan la plataforma del
software a implementar.
Se cuenta con información histórica para comparar resultados de los procesos del
nuevo software a implementar.
La implementación del proyecto será inicialmente para la Clínica Delgado.
Se contará con los recursos necesarios para la validación del desarrollo de la
aplicación, tomando en cuenta que los encargados del proceso y de la operación serán
los que validen cada desarrollo a implementar.
177
2.9.1.2 ENFOQUE DE SECUENCIA DE IMPLEMENTACIÓN
Debido a la cantidad de sedes con la que cuenta la organización, se requiere realizar una
transición gradual de la arquitectura empresarial en el negocio. En primer lugar, esta se
iniciará en la Clínica Delgado con el proceso de donación de sangre y luego de transfusión de
sangre. Dentro de esta transición, a su vez, se realizará un trabajo incremental que se define a
continuación:
- Desarrollo de la aplicación Web y App Móvil de donante.
- Integración con el software de banco de sangre E-Delphyn
- Implementación de módulo de solicitud de transfusión en ERP xHIS
- Integración con el software de banco de sangre E-Delphyn
178
EDT
Figura 36 - EDT
Fuente: Elaboración propia
2.9.1.3 CUADRO RESUMEN DEL PLAN DE IMPLEMENTACIÓN
La siguiente lista de Proyectos apoya a los procesos de negocio y al objetivo de Mantener
tecnología de punta que proporcione el soporte a todos los procesos de la clínica.
179
Tabla 55 - Cuadro resumen de implementación
BRECHA PROYECTO PROBLEMA COSTOS SOLUCIÓN
POTENCIAL RIESGOS
BN01
BN11
BN02
BN12
BN03
BN13
BN04
BN14
BN05
BN15
BN06
BN16
BN07
BN17
BN08
BN18
BN09
BN19
BN10
BN20
BN21
BD22
BD28
BD23
BD29
BD24
BD30
BD25
BD31
BD26
BD32
BD27
BD33
BA34
BA35
BT36
Implementar un
sistema web y
móvil de donante
Realizar citas y
donación de
sangre de
manera manual
S/
70,000.00
Desarrollar un
aplicativo web
y móvil para
la gestión de
la donación de
sangre
No contar con
la
infraestructura
necesaria que
pueda dar
soporte post
implementación
de la propuesta
de negocio.
No cumplir con
el plan
estimado en
tiempo, alcance
y costo.
180
BN37
BN38
BN39
BN40
BN41
BN42
BN43
BN44
BN45
BD46
BD47
BD48
BD49
BD50
BA51
BT52
Desarrollo de
módulo de
transfusión de
sangre en ERP
Xhis e
integración con
Edelphyn
Las enfermeras
realizan de
manera manual
las solicitudes de
transfusión de
sangre
S/
40,000.00
Desarrollar un
módulo de
transfusión de
sangre dentro
del ERPS
xHIS y luego
integrarlo con
el software de
banco de
sangre
Edelphyn.
No contar con
la
disponibilidad
de los Servicios
del ERP xHIS
El módulo de
transfusión no
esté finalizado
según el plan
de trabajo.
Fuente: Elaboración propia
181
2.10 CONCLUSIONES
El conocimiento adquirido sobre la arquitectura empresarial, ha permitido realizar un
análisis completo referente al Proyecto de mantenimiento de Software del ERP xHIS,
definiendo los puntos clave a mejorar para aquellos procesos que soportan los objetivos
estratégicos de la empresa.
Asimismo, del análisis se ha obtenido una propuesta del modelo TO-BE a implementar y
ha permitido realizar el análisis de brechas y encontrar los GAPs necesarios a cubrir
mediante las estrategias definidas para cada nivel de arquitectura.
Los proyectos de TI que estan alineados con el cumpliemiento de los objetivos
estratégicos tienen mayor prioridad por las gerencias ya que se tiene una percepción de
que habra un retorno de la inversión y se deja de ver como un gasto, de esta forma se
posiciona al área de TI como socio del negocio.
Posicionar al área de TI como socio del negocio permitirá que se planteen mejoras que
ayuden a obtener una venmtaja competitiva para la organización en relación con su
competencia.
Mejorar el proceso de donación de sangre permitirá aumentar la cantidad de donantes y
de esta forma poder tener la cantidad necesaria de unidades de sangre para poder cubrir
con las transfusiones que demandan los pacientes.
182
CAPÍTULO 3. MÉTODOS ÁGILES PARA EL
DESARROLLO DE SOFTWARE
3.1 INTRODUCCIÓN
El presente capítulo se centrara en el análisis de la situación actual del objeto de estudio, y
realizar un diagnóstico de esta de acuerdo a los problemas encontrados. Con esta
información, se propone la composición del grupo de trabajo con sus respectivos roles y
perfiles definidos, dinámicas para potenciar las fortalezas y herramientas a utilizar en el
equipo; tanto en el proceso de gestión de donación y transfusión de sangre, como en el equipo
de desarrollo de software de la empresa.
3.2 OBJETIVOS
Insertar y aplicar una filosofía ágil que se centre en las personas del equipo de trabajo y así
permita responder oportunamente a los cambios del entorno, tanto del proceso de gestión
donación de sangre como del equipo de desarrollo del área de TI, así también:
Mejorar la calidad: Las continuas interacciones que ofrece seguir el marco de trabajo
Scrum, generará satisfacer las expectativas del cliente con una alta calidad, debido a las
constantes entregas de software que permitirá las mejoras de los requerimientos y obtener
resultados tangibles.
Amoldar el producto y proceso: La flexibilidad que ofrece Scrum, permitirá que el equipo
de desarrollo se adapte a los cambios y esto a su vez los convierta en beneficios a favor
del cliente.
183
Mejorar la comunicación: La interacción constante entre el cliente y los diferentes
interesados es vital para mejorar el ambiente en el cual se desenvuelve el proyecto y
propicia para entornos orientados al trabajo en equipo.
Incrementar la productividad del equipo: El desarrollo de nuevos conocimientos y
habilidades como las entregas de corta duración permitirán mejorar los resultados del
equipo y esto también permitirá mejorar la satisfacción del cliente cumpliendo con las los
entregables acordados.
184
3.3 IDENTIFICACIÓN DE FORTALEZAS Y DEBILIDADES
Tabla 56 - Matriz Análisis FODA
Oportunidades Amenazas
1. Ausencia de aplicativos de donación de
sangre a nivel del mercado nacional
2. Uso de aplicativos web y/o
móviles para la donación de sangre
1. Tercerización de servicios TI.
Fortalezas Debilidades
1. Personal de salud altamente capacitado y
de prestigio
2. Diversidad de servicios de salud
3. Diversidad de clínicas como contingencia
4. Gran posicionamiento de marca en poco
tiempo
5. Adecuada contingencia en el proceso de
transfusión de sangre
6. Alto grado de coordinación entre las
partes involucradas en el proceso de
donación de sangre
7. El 10% del equipo de TI cuenta con
cursos y certificaciones en SCRUM
1. El área de TI no tiene las
responsabilidades bien definidas
2. No existe una línea de carrera definida en
el área de tecnología de información
3. Crecimiento de desmotivación del
personal
4. La información sobre los formularios de
donantes de sangre no cuenta con los
suficientes controles sobre los datos
ingresados
5. La información sobre las solicitudes de
transfusión de sangre no cuenta con los
suficientes controles sobre los datos
ingresados
6. El flujo de donación de sangre consume mucho tiempo.
7. Ausencia de iniciativas de innovación para el proceso de gestión de donación de sangre
Fuente: Elaboración propia
185
3.3.1 OPORTUNIDADES
1. Ausencia de aplicativos de donación de sangre a nivel del mercado nacional: A la
fecha no existen aplicativos en el país que apoyen a gestionar y optimizar el proceso
de donación de sangre.
2. Uso de aplicativos web y/o móviles para la donación de sangre: La empresa puede
aprovechar en ser la primera compañía en el país en lanzar un aplicativo de donantes
de sangre y estar a la vanguardia en el área de tecnología.
3.3.2 AMENAZAS
1. Tercerización de servicios TI: Empresas altamente calificadas y con amplia
experiencia que ofrecen servicios de gestión de proyectos de TI.
3.3.3 FORTALEZAS
1. Personal de salud altamente capacitado y de prestigio: La Clínica Delgado, cuenta con
personal de amplia experiencia en salud y los más reconocidos del país.
2. Diversidad de servicios de salud: La Clínica Delgado cuenta con diferentes servicios
de salud, tales como: Diagnostico y Tratamiento, Radioterapia, Quimioterapia,
Anatomía Patológica, Hotelería, Banco de Sangre, entre otros
3. Diversidad en clínicas como contingencia: La Clínica Delgado es parte de la red
AUNA que cuenta con una serie de Clínicas que apoyan como contingencia ante
alguna emergencia, entre ellas:
186
Clínica Oncosalud
Clínica Vallesur
Clínica Bellavista
Clínica Miraflores
Clínica Camino Real
4. Gran posicionamiento de marca en poco tiempo: La Clínica Delgado en la actualidad
es reconocida como una de las mejores clínicas del país debido a su alta tecnología y
atención al paciente pese a tener 2 años de haberse abierto.
5. Adecuada contingencia en el proceso de transfusión de sangre: La Clínica Delgado
cuenta con un Banco de Sangre que atiende la demanda del flujo de pacientes que
requieren y adicionalmente cuenta con Banco de Sangre de la Clínica Oncosalud y
Bellavista ante alguna contingencia.
6. Alto grado de coordinación entre las partes involucradas en el proceso de donación de
sangre: Debido a que el proceso de donación de sangre no cuenta con herramientas
tecnológicas para gestionar todo el flujo, el trabajo manual y la coordinación entre los
involucrados del proceso es fluido y cohesivo para lograr las unidades mínimas a
recabar.
7. El 10% del equipo de TI cuenta con cursos y certificaciones en SCRUM: La gerencia
de TI invirtió en capacitaciones para el personal en metodologías agiles, hoy cuentan
con 1 certificado en Scrum Product Owner, 2 certificados Scrum Master y 2
certificados en Scrum fundamentos.
187
3.3.4 DEBILIDADES
1. El área de TI no tiene las responsabilidades bien definidas: Actualmente, no existe un
MOF (manual de roles y funciones) definido y aprobado por la Gerencia de División
de TI. Por ejemplo, si existe algún problema en base de datos, lo podría tomar
cualquier desarrollador dependiendo. No existen especializaciones. Cuando surge
algún problema, el primero que se encuentre disponible atiende el problema. Existen
desarrolladores que tienen cierto conocimiento sobre tecnologías particulares, pero
esto no se aprovecha.
2. No existe una línea de carrera definida en el área de tecnología de información: Esto
se deriva como consecuencia del punto anterior y como resultado se dan dos casos, el
personal se limita a sus actividades cotidianas y no brinda un valor agregado y suele a
ver una rotación regular luego de haber estado un año, y el nuevo personal debe pasar
nuevamente por el proceso de aprendizaje.
3. Crecimiento de desmotivación del personal: En la última encuesta realizada por la
empresa TI subió al primer lugar como el área que cuenta con el mayor índice de
insatisfacción laboral.
4. La información sobre los formularios de donantes de sangre no cuenta con los
suficientes controles sobre los datos ingresados: Al ser un proceso con ausencia de
herramientas tecnológicas se hace uso de formularios físicos y archivos MS Excel los
cuales son rellenados de manera manual donde los errores de digitación son más
frecuentes, Así mismo la documentación física no tiene una adecuada gestión de
almacenaje en caso se requiera consultar alguna información a futuro.
5. La información sobre las solicitudes de transfusión de sangre no cuenta con los
suficientes controles sobre los datos ingresados: De la misma manera que el punto
anterior, el proceso de transfusión de sangre carece de herramientas tecnológicas se
hace uso de formularios físicos los cuales son rellenados de manera manual donde los
errores de digitación son más frecuentes, Así mismo esta documentación física no
188
tiene una adecuada gestión de almacenaje en caso se requiera consultar alguna
información.
6. El flujo de donación de sangre consume mucho tiempo: Como consecuencia de los
puntos anteriores, el ingreso de la información y corroborarla; así como realizar las
correcciones por cada formulario mal digitado demanda más tiempo de lo que
debería.
7. Ausencia de iniciativas de innovación para el proceso de gestión de donación de
sangre: El crecimiento acelerado de la empresa conlleva a tener una respuesta
reactiva. Así mismo los resultados negativos de la encuesta de clima laboral, hacen
que exista pocas iniciativas de innovación en el proceso de donación y transfusión de
sangre.
3.4 DIAGNÓSTICO DEL GRUPO
Figura 37 - Cuadro Cynefin
Fuente: http://www.javiergarzas.com/2016/07/entendiendo-modelo-cynefin.html
189
3.4.1 PARA EL PROCESO DE DONACIÓN DE SANGRE
De acuerdo al análisis FODA realizado y teniendo como referencia el cuadro de CYNEFIN,
el proceso de banco de sangre se ubica en el cuadrante COMPLICADO, puesto que existen
buenas prácticas en el proceso de donación sin embargo se busca eficiencia y eficacia a lo ya
implementado. Así mismo se requiere de expertos para evaluar la información recabada de
los donantes.
Sin embargo, a pesar de esta complejidad, y las tareas manuales para realizarlo, el proceso se
completa correctamente.
Se identifican los siguientes problemas:
1. La planificación de citas para la donación de sangre se realiza de manera manual y a
revisión de un archivo MS Excel para la programación de fecha y hora:
Programación errónea, debido a que no se cuenta con un sistema de programación de
citas, las enfermeras agendan doble cita en la misma fecha y hora, así también los el
registro erróneo del donante.
2. La información sobre los formularios de donantes de sangre no cuenta con los
suficientes controles sobre los datos ingresados:
Los errores de digitación tanto por parte de los donantes, enfermeras y médicos
ocasionan que se puedan registrar datos erróneos sobre el donante. Por ejemplo, si un
donante ingresa mal un dato personal en el formulario se debe generar otro de nuevo.
Casos similares ocurren al momento de registrar sus respuestas al pliego de preguntas
sobre su estado de salud, lo que ocasiona pérdida de tiempo al momento de validar la
información por parte del médico.
190
3. El flujo de donación de sangre consume mucho tiempo:
Duplicación de citas en el mismo horario, malos registros en el formulario, información
distorsionada de los donantes sobre los requisitos mínimos para la donación y por el retraso
que causa la excesiva cantidad de procedimientos manuales (registro de donantes, validación
de datos, consulta de formularios físicos, entrevistas con el médico, entre otros).
3.4.2 PARA EL EQUIPO DE DESARROLLO
En la actualidad la empresa cuenta con una estructura de aspecto de pirámide siendo así parte
de las organizaciones del tipo vertical, tiene 58 colaboradores y esta compuesta por el gerente
de tecnología de información que tiene 9 reportes directos: un gerente de operaciones, 5 jefes
de gestión de aplicaciones, un jefe de gobierno, un jefe de arquitectura y un jefe de seguridad
de información y cada jefatura cuenta con analistas y especialistas.
FORTALEZAS
1. Los analistas de procesos tienen buenas habilidades de comunicación con los usuarios y
comprenden los requerimientos solicitados, así como el conocimiento del negocio. Se
utiliza un checklist estándar de verificación para el levantamiento de requerimientos
2. La gerencia está apoyando esta iniciativa de insertar las metodologías agiles invirtiendo
en capacitaciones para un grupo de trabajadores.
3. Aunque no se aprovecha, se cuenta con desarrolladores que tienen conocimiento en las
tecnologías propuestas para el desarrollo del software
DEBILIDADES
1. Como se indicó en las debilidades del negocio, el equipo de TI no tiene las
responsabilidades bien definidas: Actualmente, no existe un MOF (manual de roles y
funciones) todos los miembros del área de TI podrían realizar cualquier función.
191
2. No se tiene experiencia en el desarrollo de aplicaciones móviles.
3. No se cuenta con experiencia de desarrollo utilizando alguna metodología ágil en la
empresa. Algunos miembros del área de TI cuentan con el conocimiento teórico de
SCRUM, pero nunca se ha aplicado en la empresa.
Ante este escenario, y utilizando el cuadro de CYNEFIN como referencia, se concluye que el
grupo de trabajo para desarrollar el software propuesto se encuentra en el cuadrante
COMPLEJO.
Existe un nivel de incertidumbre por los siguientes motivos:
1. No se ha aplicado el uso de metodologías ágiles en algún desarrollo en el negocio
(Sería la primera vez que se aplique)
2. No se cuenta con experiencia en el desarrollo de aplicativos móviles.
3. No existen roles definidos y se deberá realizar esta segmentación para el desarrollo.
Se requerirá de expertos: En el lado de TI, para aplicar y desarrollar el aplicativo móvil. Del
lado del negocio sí se cuenta con expertos en el proceso de donación y transfusión de sangre.
Sin embargo, el software propuesto en el capítulo anterior busca que el proceso sea más
eficaz y eficiente utilizando la información con la que se cuenta (y añadiendo información
adicional).
3.5 IDENTIFICACIÓN DE LAS DINÁMICAS PROPUESTAS
Se propone utilizar SCRUM como marco de trabajo para el desarrollo de las aplicaciones
propuestas: Portal Web y móvil de donación de sangre.
Por qué SCRUM:
La involucración de los roles que participan del proceso de donación de sangre en el
desarrollo de la aplicación Web y móvil es vital para que el producto final sume en la
192
eficacia y eficiencia del proceso. Con el rol de Product Owner, el Coordinador de
Servicios Médicos, el cual es el responsable de definir las metodologías, políticas,
procesos a utilizar en el área de TI y con la ayuda del equipo Scrum definirán el
comportamiento del software para que dé valor al proceso. La participación del
Coordinador de Servicios Médicos como Product Owner será constante para así
garantizar que el software a desarrollar cumpla con los requerimientos acordados.
Conseguir un producto software funcionando cada 3 semanas (el cual será la duración
de cada sprint), permitirá que se valide la funcionalidad de forma temprana y que se
identifiquen los cambios necesarios para que el este esté alineado con lo que necesita
el proceso.
Por medio del daily SCRUM, se podrá identificar desde el comienzo los problemas
que estén ocurriendo durante el desarrollo de los requerimientos. Por ejemplo, al tener
conocimiento de la complejidad de las tareas a realizar, si un miembro del equipo
reporta que sigue trabajando en una tarea sencilla que empezó el día anterior, se puede
identificar la posible existencia de un problema potencial en esa tarea. Así mismo, es
necesaria la transparencia del equipo para reportar las demoras en las tareas; ya que,
esto apoyara a identificar los problemas y por lo tanto buscar soluciones con todo el
equipo.
De la misma forma, el daily SCRUM apoyara a cohesionar al equipo; puesto que,
todos los miembros estarán informados de los estados de las tareas y qué persona está
realizando qué actividad. Además, al ocurrir problemas, todos los miembros del
equipo podrán aportar ideas para solución.
Las dinámicas a implementar utilizando SCRUM son las siguientes:
1. Daily Scrum: Se agendaran reuniones diarias entre todos los miembros del equipo de
trabajo. Estas reuniones serán programadas a las 8:45 am con todos los miembros del
equipo Scrum (SCRUM team). Todo el equipo deberá permanecer de pie durante la
reunión e irán turnándose para responder las siguientes preguntas:
193
En qué ha trabajado ayer
En qué trabajará hoy
Los impedimentos que ha tenido para realizar el trabajo o que estén
bloqueando el avance del trabajo. En caso no existan impedimentos, el locutor
omitirá esta sección
Esta reunión no debe extenderse más de 15 minutos.
El objetivo de estas reuniones es que todo el equipo esté alineado y que las actividades
que se realizan sean visible para todos. Además, permite detectar problemas de forma
temprana.
2. Sprint planning: Es una reunión que se llevará a cabo previó al inicio del Sprint. En
esta reunión se definirá el trabajo a realizar en el sprint utilizando como base el
product backlog definido.
Se realizará al iniciar el sprint. Esta reunión no debe exceder de más de 2 horas. En
esta, el product owner expondrá las user stories que se encuentran en el product
backlog que desea que se incluyan en el sprint. El equipo debatirá las user stories y
asignará un peso a cada una. Los pesos definirán la complejidad de la tarea a realizar:
Estos van en un rango del 1 al 5, donde 1 es muy fácil y 5 muy complejo.
Una vez establecidos los pesos de las user stories, se procede a elegir cuáles se
incluirán en el sprint, teniendo como consideración la capacidad de desarrollo para las
dos (2) semanas que durará el sprint.
Cada user story agregada al sprint backlog, se procederá a crear las tareas necesarias
para culminarlas.
Las user stories (y sus tareas asociadas) se colocarán en el scrum taskboard, el cual
estará compuesto de 4 columnas que indicarán el estado actual de la tarea:
194
Pendiente: Cuando el trabajo aún no se ha iniciado.
En progreso: Cuando el trabajo está en transcurso
Resuelto (en QA): Cuando la user story se encuentra en el ambiente de
calidad para ser probada y validada.
Cerrado: Cuando se aprueba que la user story cumple con todos los
criterios de aceptación.
3. User Stories Refinement (Refinamiento de las historias de usuario): Durante la
ejecución del sprint, se realizará una reunión para absolver las dudas que existan
sobre las user stories en el backlog. De esta forma, se busca claridad y entendimiento
para las siguientes reuniones de sprint planning; asimismo, la estimación de los pesos
será más precisa. Esta reunión no debe exceeder de más de 1 hora.
4. Sprint Review (Revisión de la iteración): Al finalizar el sprint, se realizará una reunión
en la cual se mostrará la iteración del software funcionando. El product owner
validara que el software cumpla con las user stories acordadas a desarrollar en el
sprint y brindara feedback al equipo. Esta reunión no debe exceder más de 2 horas
5. Sprint Retrospective (Retrospectiva de la iteración): Una vez culminado el sprint
review, el equipo se reunirá para identificar las lecciones aprendidas. Para esto, cada
miembro del equipo dará su opinión sobre las cosas a seguir en el futuro y aquellas
que deben mejorarse. Esta reunión no debe exceder de más de 1 hora.
Fuente (https://proyectosagiles.org/como-funciona-scrum/)
195
3.6 COMPOSICIÓN DE LOS GRUPOS DE TRABAJO
A continuación, se detalla la composición del equipo de trabajo necesario para la correcta
implementación de las dinámicas propuestas. Para ello, mencionar que los roles serán
asumidos por miembros actuales de la organización.
Tabla 57 - Composición de los grupos de trabajo
Rol Responsabilidades
Product Owner Este rol será llevado a cabo por el Coordinador de Servicios Médicos, el
cual conoce todo el proceso.
Es la cara del proceso hacia el equipo de desarrollo. Debe
transmitir lo que el proceso necesita hacia el software a
construir.
Recolectar todas aquellas user stories que serán tomadas en el
sprint, de acuerdo a qué le da más valor al negocio (en este
caso, los sub procesos de donación y transfusión de sangre)
Mantener el product backlog actualizado, indicando cuáles son
las prioridades de las user stories.
Habilidades:
Excelente nivel de comunicación y que también permita
transmitir sus ideas con claridad.
Orientado al cliente donde pueda gestionar las expectativas de
los stakeholders.
Conocer el proceso de donación y transfusión de sangre.
196
Scrum Master Este rol será llevado a cabo por el Jefe de Arquitectura, el cual conoce a
los Scrum Team ya que viene de interactuar de otros proyectos.
Responsabilidades
Liderar al equipo de trabajo.
Coordinar con el product owner para que este pueda mantener
el product backlog
Ser facilitador para resolver problemas y guiar al equipo en
cumplimiento con el marco de trabajo SCRUM
Habilidades
Conocer y dominar el framework SCRUM.
Capacidad de negociación y solucionador de conflictos
Pensamiento crítico
Investigador e inspirador
Manejo de habilidades blandas
Conocimiento en tecnologías de desarrollo
197
Scrum Team Estará compuesto por 3 desarrolladores, 2 analistas funcionales y un
analista QA, adicionalmente un analista de infraestructura. Asimismo, se
contará con un consultor externo de experiencia en aplicaciones móviles
Responsabilidades
Desarrollar el software Web y móvil de la aplicación de donación
de sangre.
Desarrollar la integración de la aplicación de donación de sangre
con el software EDelphyn.
Desarrollar el módulo de transfusión de sangre e integrarlo con
el ERP Xhis.
Desplegar las aplicaciones desarrolladas en la plataforma.
Habilidades
Compromiso para aplicar el marco de trabajo
Ser autosuficientes, con capacidad de tomar decisiones que
estén en su ámbito de trabajo.
Conocimientos técnicos
Conocimiento del lenguaje C#
Conocimiento de Web API .NET
Conocimiento de IOS y Android
Conocimiento de MSSQL Server 2012
Conocimiento de Oracle 11g R2
198
Conocimiento de Material Design
Conocimiento de Eclipse
Fuente: Elaboración propia
3.6.1 COSTO DEL EQUIPO
Tabla 58 - Costos del grupo de trabajo propuesto
Rol Rol actual ¿Forma parte de
la empresa? Costo por hora
Horas por
recurso Costo total del
Recurso
Product Owner Coordinador de
Servcios Médicos
Sí S/. 45.45 168 S/. 7650.00
Scrum Master Jefe Arquitectura Sí S/. 39.77 228 S/. 9080.00
Desarrollador 1 Analista Funcional Sí S/. 19.89 750 S/. 14917.33
Desarrollador 2 Analista Funcional Sí S/. 19.89 750 S/. 14917.33
Desarrollador 3 Analista QA Sí S/. 19.89 1161 S/. 23092.33
Analista de
Infraestructura
Analista de
Infraestructura
Sí S/. 17.05 90 S/. 1534.50
199
Consultor
Desarrollo Móvil
Externo Consultor externo por
horas para aplicar
Desarrollo Móvil
S/. 17.05 462 S/. 7877.00
Fuente: Elaboración propia
Para mayor detalle de los costos revisar Anexo 2
200
3.7 DEFINICIÓN DE LAS HERRAMIENTAS A UTILIZAR
3.7.1 SPRINT BACKLOG
Tablero en el cuál se mostraran las tareas a realizar en el sprint actual agrupadas de acuerdo
al estado en el que se encuentran. Inicialmente se colocarán los ítems a desarrollar en el sprint
actual en la columna “Item del Sprint Backlog” y luego se irán moviendo a las demás
columnas de acuerdo al progreso de la tarea.
Los estados propuestos son:
Pendiente: Ítems que aún no han sido iniciados
En Progreso: Ítems que están en ejecución
Resuelto (en QA): Ítems que han sido desplegados en el ambiente de QA y que el analista
puede validar
Cerrado: Cuando el ítem cumple con el criterio de aceptación establecido y ha sido
validador por QA
Tabla 59 – Tabla de SCRUM
ITEM DEL SPRINT
BACKLOG PENDIENTE EN PROGRESO
RESUELTO (EN
QA) CERRADO
Fuente: https://proyectosagiles.org
3.7.2 PLANNING POKER
Esta herramienta apoyara en el sprint planning y así colocar los pesos a las user stories.
Consiste en una baraja de cinco (5) cartas que se entrega a cada miembro del equipo. Cada
carta representa al peso con el que se calificará a una user story (1-5). Al realizar la
estimación, cada miembro del equipo escoge la carta que él considera debe ser la complejidad
201
del user story; y, luego de un tiempo determinado, cada miembro del equipo muestra su carta
y sustenta por qué consideró dicho peso.
Por ejemplo:
Figura 38 - Planning Poker Fuente
Fuente: https://www.crisp.se/bocker-och-produkter/planning-poker
3.7.3 USER STORIES
Las historias de usuario definirán la funcionalidad que tendrá el software propuesto en el
capítulo anterior. Se propone utilizar la siguiente plantilla, donde:
[Código de la historia de usuario]. [Nombre de la historia] – Se describe cómo un rol en
particular desea cubrir un requerimiento.
202
Cuando:
Se indica el escenario que debe cumplir la
funcionalidad.
Espero:
Se indican los criterios de aceptación:
Comportamiento esperado del software ante el
escenario identificado previamente
3.7.3.1 LISTADO DE USER STORIES
PARA EL SUB PROCESO DONACIÓN DE SANGRE
US01. Registro de Donante - Como Usuario Donante deseo registrarme en la aplicación web
y móvil para que me evalúen y pueda realizar la donación de sangre.
Cuando:
El usuario se registra debe indicar:
Tipo de documento, número de documento,
apellidos, nombres, fecha de nacimiento,
correo electrónico, ocupación, número de
celular y casa, dirección, ciudad y distrito.
Espero:
• Confirmación de registro exitoso.
• Mensaje de error si no se ingresan los datos.
• Mensaje de error si el formato de alguno de
los datos no es correcto (teléfono es
numérico)
US02. Registrar Formulario - Como Usuario Donante deseo responder el formulario de
preguntas que se requieren contestar como requisito en la aplicación web o móvil.
203
Cuando:
Responder formulario: Peso, has tenido
hepatitis, has donado sangre, etc. (Ver anexo
01 cuestionario modelo base para la
donación de sangre)
Espero:
Mensaje de error si no acepta
condiciones y términos.
Confirmación de registro exitoso.
Mensaje de error si no se ingresan los
datos como por ejemplo peso.
Mensaje de error si el formulario no
ha sido completado en su totalidad.
US03. Evaluar Donante - Como Usuario Donante mi formulario será evaluado para ver si
estoy apto para donar sangre en la aplicación web o móvil.
Cuando:
Indica si el formulario contestado
cumple con los requisitos para donar
sangre
Espero:
Confirmación de formulario aceptado.
Mensaje de error si el formulario no
cumple con los requisitos para donar
sangre.
US04. Solicitar Cita - Como Usuario Donante deseo agendar día y hora para realizar la
donación de sangre en la aplicación web o móvil.
204
Cuando:
Registrar fecha y hora: Mostrar condiciones
y términos.
Espero:
Confirmación de registro exitoso.
Mensaje de error si fecha está
ocupada.
US05. Modificar Cita - Como Usuario Donante deseo modificar la cita agendada para otro
día y hora para realizar la donación de sangre en la aplicación web o móvil.
Cuando:
Modificar fecha y hora: Mostrar condiciones
y términos de modificación de cita.
Espero:
Confirmación de modificación
exitosa.
Mensaje de error de condiciones y
términos si no es aceptada.
Mensaje de error si fecha está
ocupada.
US06. Consulta de Resultados - Como Usuario Donante deseo consultar los resultados del
análisis de la sangre donado en la aplicación web o móvil.
Cuando:
Cuando realizo la donación de sangre puedo
visualizar los resultados de la sangre con
parámetros básicos y genéricos.
Espero:
Visualizar el resultado del análisis de
sangre.
Mensaje indicando que puede
descargar el resultado de análisis de la
sangre.
205
US07. Consulta de Recomendaciones - Como Usuario Donante deseo consultar las
recomendaciones de acuerdo al análisis de la sangre donada en la aplicación web o móvil.
Cuando:
Cuando visualizo los resultados de la sangre
donada puedo visualizar las recomendaciones
generales por parte del médico.
Espero:
Visualizar las recomendaciones del
análisis de sangre.
Mensaje indicando que puede
descargar la recomendación.
US08. Generar Cita - Como Enfermera deseo crear, buscar, modificar y eliminar las citas de
los donantes en la aplicación web.
Cuando:
Registro y/o modificación de citas
Espero:
Confirmación de registro exitoso.
Mensaje de error si no se ingresan los
datos.
Mensaje de error si no se ubica a
donante.
206
US09. Recordar Cita - Como Enfermera puedo enviar el recordatorio de citas a los donantes
registrados en la aplicación web.
Cuando:
Realizo la búsqueda de los donantes que
tienen cita dentro de las próximas 24 horas
para enviar recordatorio.
Espero:
Listado de los donantes que tienen cita
en las próximas 24 horas.
Confirmación de envió de recordatorio
exitoso.
US10. Enviar Instrucciones - Como Enfermera puedo enviar las instrucciones a seguir al
donante para el día de la donación de sangre en la aplicación web.
Cuando:
Realizo la búsqueda de los donantes que
tienen cita dentro de las próximas 24 horas
para enviar recordatorio
Espero:
Listado de los donantes que tienen cita
en las próximas 24 horas.
Confirmación de envió de recordatorio
exitoso.
US11. Enviar Recomendaciones - Como Enfermera puedo enviar las recomendaciones
realizadas por el médico sobre el análisis de sangre del donante en la aplicación web.
Cuando:
Realizo la búsqueda del donante para enviar
las recomendaciones realizadas por el
Espero:
Listado de los donantes que tienen
recomendaciones del médico.
207
médico.
Confirmación de envió de las
recomendaciones exitosa.
US12. Mantenimiento Formularios - Como Enfermera y Médico deseo consultar, descargar
e imprimir los formularios de los donantes en la aplicación web.
Cuando:
Se realiza la consulta de formularios para
visualizar los formularios aceptados e
imprimirlos para la entrevista con él médico
Espero:
Visualizar formulario de donante.
Mensaje de error si no encuentra
impresora.
US13. Solicitar donación - Como Enfermera y Médico deseo buscar al donante con el tipo
de sangre que se requiere para invitarlo a donar en la aplicación web.
Cuando:
Se requiera un tipo de sangre en específico,
se realiza la búsqueda de los donantes que
tengan el mismo tipo de sangre.
Espero:
Listado de los donantes compatibles
con la sangre requerida.
Confirmación de envió de invitación a
donar exitosa.
Mensaje de búsqueda en caso no hay
donantes disponibles.
208
US14. Invitación a Donar - Como Enfermera y Médico deseo invitar a donar nuevamente a
los donantes que cumplan con los requisitos en la aplicación web.
Cuando:
Exista promociones especiales para donantes
por parte del área de Marketing, invitarlos a
donar.
Espero:
Visualizar la lista de los donantes
aptos para volver a donar.
Adjuntar promoción para donante.
Confirmación de invitación exitosa.
US15. Ingresa Recomendaciones - Como Médico deseo ingresar las recomendaciones para
donante de acuerdo a su análisis de sangre en la aplicación web.
Cuando:
Se tiene los resultados del análisis de sangre
de los donantes, ingresar las
recomendaciones de salud.
Espero:
Listar donantes con resultados.
Imgresar texto de recomendación.
Adjuntar algún documento.
Confirmación de ingreso de
información exitoso.
US16. Integración Con Software Edelphyn – Los resultados del análisis son brindados por
el software Edelphyn que deben ser enviados de manera automática a la cuenta del donante.
Cuando: Espero:
209
El software que realiza el análisis de sangre
genera los resultados debe enviarlo a la
cuenta del donante.
Lista de resultados de análisis.
Confirmación de envoi exitoso.
PARA EL SUB PROCESO TRANSFUSIÓN DE SANGRE
US17. Crear solicitud de transfusión - Como Enfermera deseo generar la solicitud de
transfusión de sangre que requiera el paciente dentro del ERP xHIS.
Cuando:
El paciente requiere una transfusión de
sangre, se debe generar la solicitud
ingresar el tipo de sangre y las unidades
requeridas.
Espero
Confirmación de registro exitoso
Mensaje de error si no se registra la
solicitud.
US18. Aprobación Transfusión - Como Médico debo aprobar la solicitud de acuerdo a la
disponibilidad de las unidades y tipo de sangre.
Cuando:
Existe una solicitud de transfusión de sangre,
se debe consultar el tipo de sangre y las
unidades disponible para aprobar la
Espero:
Aprobación de transfusión exitosa.
Mensaje de falta de unidades.
210
transfusión. Mensaje de falta de tipo de sangre.
US19. Mantenimiento Transfusión - Como Enfermera deseo buscar, modificar, eliminar e
imprimir las solicitudes de transfusión de sangre para los pacientes.
Cuando:
Se requiere acceso a las solicitudes de
transfusiones para modificar, anular e
imprimir las solicitudes.
Espero:
Visualizar las solicitudes de
transfusión de sangre.
Ver el detalle de la solicitud.
Confirmación de cambio exitoso.
Confirmación de eliminación exitosa.
Mensaje de error por falta de datos a
ingresar.
US20. Integración ERP Xhis - Edelphyn - Como Médico debo consultar la historia clínica
del paciente y se encuentre las transfusiones realizadas al paciente.
Cuando:
Consulto la historia clínica del paciente se
debe reflejar las transfusiones realizadas al
paciente.
Espero:
Visualizar las transfusiones realizadas al
paciente.
211
3.7.3.2 PLANTEAMIENTO DEL SPRINT 0:
Tabla 60 – Propuesta de mejora – Planteamiento Sprint 0
HISTORIA DE USUARIO ITEM DEL SPRINT
BACKLOG PENDIENTE EN PROGRESO
RESUELTO
(en QA) CERRADO
US01. Registro de Donante -
Como Usuario Donante deseo
registrarme en la aplicación web
para que me evalúen y pueda
realizar la donación de sangre.
Prioridad 1
40 Horas
Diseño de DB
Diseño de Página
Interfaz de usuario
Conexión a BD
Configuración de seguridad
212
US02. Registrar Formulario -
Como Usuario Donante deseo
responder el formulario de
preguntas que se requieren
contestar como requisito en la
aplicación web
Prioridad 2
20 Horas
Diseño de formulario
Interfaz de usuario
Configuración de seguridad
US03. Evaluar Donante - Como
Usuario Donante mi formulario
será evaluado para ver si estoy
apto para donar sangre en la
aplicación web
Interfaz de usuario
Conexión a BD
213
Prioridad 3
20 Horas
Diseño de mensajes de error
Validación
Pruebas
Prioridad 4
40 Horas
Registro de usuario
Registro de formulario
Mensajes de error
Conexión a BD
Prueba de seguridad
Fuente : Elaboración propia
214
3.7.4 CONCLUSIONES
El utilizar una herramienta de estudio como el FODA nos permitió conocer una fortaleza
y que había que explotar, que es la de contar con miembros del equipo de TI con
conocimientos y certificaciones en SCRUM y así nos permita armar un equipo de
desarrollo para implantar esta metodología ágil, para ello se requiere la disponibilidad de
todas las personas involucradas de acuerdo a los tiempos estimados requeridos a este
proyecto y así puedan dedicarse al proyecto, de lo contrario los tiempos planificados se
verán impactados y esto podría impactar en el tiempo y costo del proyecto.
Así también se requería complementar el análisis, pero ahora enfocado al proceso de
banco de sangre, para eso nos apoyamos en la herramienta Cynefin que nos permitió
conocer que si bien contábamos con buenas prácticas en la actualidad durante el flujo, se
requiere optimizar buscando ser eficiente y eficaz tanto en la donación de sangre como en
la transfusión y para lograrlo nos apoyaremos en la flexibilidad que tiene SCRUM con el
desarrollo de entregables, ya que luego de cada Sprint, nos permitirá tomar acciones
correctivas en caso se requiera modificar o corregir alguna funcionalidad que haya sido
propuesta en lugar de tener que esperar al término de todo el desarrollo para poder recién
realizar una gestión de cambios.
Si bien en la actualidad la organización trabaja bajo la guía de los fundamentos del
Pmbook, no existe una clara diferencia que conlleve a un cambio, ya que dependen de
varios factores, sin embargo para esta propuesta, se elige a SCRUM debido a que nos
permitirá explotar una fortaleza del equipo de TI y a la vez nos permitirá realizar
comparar que metodología genera mayor valor y que a la vez se adapte al negocio de la
empresa, asi también veremos una mejora notable para la organización por el lado de la
gestión de sus proyectos ya que Scrum permitirá que durante la ejecución del proyecto se
pueda actualizar el alcance del mismo sin verse impactado ni el tiempo ni el costo.
Una de las ventajas de usar el marco de trabajo Scrum es tener un equipo motivado,
debido a que las personas se sienten satisfechas cuando pueden mostrar sus habilidades y
logros obtenidos, esto es vital para atacar una de las falencias del equipo de TI que se
encuentra con poca motivación ya que el cambio de enfoque hacia el equipo de
215
desarrollo, pondrá en evidencia que al potenciar más el trabajo en equipo y las dinámicas
implementadas se logra mayor eficiencia.
Finalmente concluimos que el análisis FODA y Cynefin, sumado al marco de trabajo
Scrum nos permitirá buscar el cumplimiento del objetivo estratégico de “Mantener
tecnología de punta que proporcione el soporte a todos los procesos de la clínica”; puesto
que, son estas las que están buscaran anular el proceso manual para el banco de sangre y a
su vez optimizar el proceso; así también se pueda incorporar el uso de las metodologías
ágiles como su nuevo estándar de desarrollo para los futuros proyectos que busquen
mejorar los procesos de la organización.
216
CAPÍTULO 4: ESTRUCTURA PROPUESTA
4.1 PROPUESTA DE MEJORA DE LOS PROCESOS DE
DONACIÓN DE SANGRE Y TRANSFUSIÓN DE SANGRE
PARA LA CLÍNICA DELGADO
La finalidad de este capítulo es poder presentar los proyectos de mejora para los sub procesos
de Donación de sangre y Transfusión de sangre que son parte del macroproceso de Banco de
Sangre de la Clínica Delgado.
4.1.1 OBJETIVOS DE LA PROPUESTA
Presentar una propuesta de mejora para los procesos de Donación y Transfusión de sangre
de la Clínica Delgado basados en el análisis de una arquitectura empresarial aplicada
sobre estos procesos y planteando la implementación del marco de trabajo SCRUM para
el desarrollo de los proyectos de mejora que se encuentran alineados con los objetivos
estratégicos de la organización.
Mostrar los beneficios y factibilidad de aplicar los proyectos de mejora planteados para la
optimización de los procesos de Donación y Transfusión de sangre.
4.1.2 ALCANCE DE LA PROPUESTA
El alcance de la propuesta es para la clínica Delgado que pertenece a la red de clinicas Auna.
Esta empresa brinda de servicios de salud como hospitalizaciones, emergencia,
procedimientos médicos, etc. Como parte de los procedimientos médicos se tiene el
macroproceso Procedimientos Terapéuticos que es parte de los procesos core de la empresa y
217
el cual está constituido por dos (7) procesos: Los proyectos de mejora se plantearán sobre el
proceso de Banco de Sangre que abarca 2 sub procesos que
Donación de sangre
Transfusión de sangre
A continuación se muestra el mapa de procesos de la Clínica Delgado en donde se indica el
proceso que es parte del alcance de la propuesta:
218
A continuación se muestra el mapa de procesos de la Clínica Delgado:
Figura 39 – Propuesta de mejora – Mapa de procesos de la Clínica Delgado
Fuente: Elaboración propia
219
4.1.3 IMPACTO EN LOS OBJETIVOS ESTRATÉGICOS
Para poder ver el impacto de esta propuesta sobre los objetivos estratégicos de la Clínica
Delgado se muestra a continuación se muestra una matriz en donde realiza la trazabilidad de
los Objetivos Estratégicos de la organización con el Proceso Banco de sangre ( en este
proceso se encuentran Donación de Sangre y Transfusión de Sangre que son el alcance
definido de esta propuesta).
220
Tabla 61 – Propuesta de mejora - Matriz de procesos de negocio vs objetivos estratégicos – Parte 1
Objetivos Estratégicos red
AUNA Objetivos Estratégicos Clínica Delgado
Pla
nea
mie
nto
Est
raté
gic
o
Pla
nif
ica
ció
n y
Des
arr
oll
o
Ma
rket
ing
Est
raté
gic
o
Rel
aci
on
es I
nst
itu
cio
na
les
Ges
tió
n L
ega
l
Ges
tió
n d
e C
ali
da
d
Inv
esti
ga
ció
n y
Do
cen
cia
Ges
tió
n d
el T
ale
nto
Clí
nic
o
Em
erg
enci
a
Co
nsu
lta
Ex
tern
a
Ho
spit
ali
zaci
ón
Co
nv
enci
on
al
Ho
spit
ali
zaci
ón
crí
tico
s -
UC
I
Cir
ug
ía A
mb
ula
tori
a
Cir
ug
ías
con
Ho
spit
ali
zaci
ón
Dx
. P
or
imá
gen
es
La
bo
rato
rio
Clí
nic
o
La
b. A
na
tom
ía P
ato
lógic
a
Med
icin
a N
ucl
ear
Pro
ced
imie
nto
s
Fa
rma
cia
Ra
dio
tera
pia
Posicionar la red Auna como la
primera opción de atención de
calidad al paciente
Asegurar reclutamiento de los mejores profesionales de salud x x x x x x x x x x x x x x x x x x x x x
Proporcionar una óptima atención médica a los pacientes
brindándole un servicio que satisfaga sus necesidades,
requerimientos y expectativas. x x x x x x x x x x x x x x x x x x x x x
Incrementar el tráfico de pacientes x x x x x x x x
Ser líder en tecnología asistencial
que permita contar con
tecnología integrada en todos los
centros de la red Auna
Posicionar 3 centros de excelencia: Maternidad, Emergencia y
Cardiología x x x x
x x x x x x x x x
Brindar integración de información entre los tipos de atención
CEX, URG, HOS, CQX x x x x x x x x x x x x x x
Mantener tecnología de punta que proporcione el soporte a
todos los procesos de la clínica x x x x x x x x x x x x x x x x x x x x x
Brindar un ambiente de trabajo
de calidad al personal que
permita manejar un nivel de
compromiso con la red Auna
Lograr que cada empleado de la clínica trabaje conjuntamente
orientado hacia la cultura del paciente y sus familiares. x x x x
x x x x x x x x x x x x x x x x
Total 7 7 7 7 4 7 7 7 6 6 6 6 6 6 4 4 4 4 4 4 4
Porcentaje 100% 100% 100% 100% 71% 100% 100% 100% 86% 86% 86% 86% 86% 86% 57% 57% 57% 57% 57% 57% 57%
Fuente: Elaboración propia
221
Tabla 62 – Propuesta de mejora - Matriz de procesos de negocio vs objetivos estratégicos – Parte 2
Objetivos Estratégicos red
AUNA Objetivos Estratégicos Clínica Delgado
Ban
co d
e S
ang
re
Qu
imio
tera
pia
Nu
tric
ión
y D
ieté
tica
Med
icin
a F
ísic
a y
reh
ab
ilit
aci
ón
Hem
od
iáli
sis
Ad
mis
ión
Ca
ja
Ges
tió
n d
e a
gen
da
s
Ges
tió
n d
e C
ita
s
Co
cin
a
Lim
pie
za
Ho
tele
ría
Pa
rkin
g A
sist
enci
al
Au
dit
orí
a M
édic
a
Tra
nsp
ort
e d
e P
aci
ente
s
Tra
nsp
ort
e d
e ó
rga
no
s
Cen
tra
l d
e E
steri
liza
ció
n
Ges
tió
n d
e cl
ien
tes
Aco
mp
añ
am
ien
to a
l p
aci
ente
Seg
uri
da
d d
el P
aci
ente
Seg
uri
da
d F
ísic
a
Seg
uri
da
d I
nd
ust
ria
l
Posicionar la red Auna como la
primera opción de atención de
calidad al paciente
Asegurar reclutamiento de los mejores profesionales de salud x x x x x
Proporcionar una óptima atención médica a los pacientes brindándole un
servicio que satisfaga sus necesidades, requerimientos y expectativas. x x x x x
Incrementar el tráfico de pacientes
Ser líder en tecnología asistencial
que permita contar con tecnología
integrada en todos los centros de la
red Auna
Posicionar 3 centros de excelencia: Maternidad, Emergencia y Cardiología
Brindar integración de información entre los tipos de atención CEX, URG,
HOS, CQX
Mantener tecnología de punta que proporcione el soporte a todos los
procesos de la clínica x X x x x x x x
Brindar un ambiente de trabajo de
calidad al personal que permita
manejar un nivel de compromiso
con la red Auna
Lograr que cada empleado de la clínica trabaje conjuntamente orientado
hacia la cultura del paciente y sus familiares. x X x x x x x x x x
x x x x x x x x x x x
Total 4 4 4 4 4 2 2 2 1 1 1 1 1 1 1 1 1 1 1 1 1
Porcentaje 57% 57% 57% 57% 57% 29% 29% 29% 14% 14% 14% 14% 14% 14% 14% 14% 14% 14% 14% 14% 14%
Fuente: Elaboración propia
222
4.1.4 PROBLEMÁTICA
DONACIÓN DE SANGRE
El continuo incremento de pacientes que requieren transfusión de sangre en los diversos
procedimientos quirúrgicos que brinda la clínica hace que se requiera mayor cantidad de
unidades de sangre en el Banco de Sangre. Actualmente el porcentaje de donación es muy
baja y presenta un riesgo de desabastecimiento que podría generar que la Clínica no pueda
atender a sus pacientes con la misma calidad y eficiencia de siempre.
El problema de donación es un problema que no sólo parte de la clínica sino que a nivel
nacional no existe una cultura de donación, de acuerdo a los datos del minsa:
“La donación voluntaria de sangre en nuestro país es muy reducida, solo el 0.5% de la
población dona sangre. De este segmento, cerca de un 5% aporta voluntariamente, siendo la
donación por reposición la principal fuente de abastecimiento de sangre (95%)”8
TRANSFUSIÓN DE SANGRE
La problemática que se tiene este procedimiento es que el proceso desde que el médico da la
orden de transfusión hasta que se tienen las unidades de sangre toma bastante tiempo debido
a que, el registro de transfusión de sangre es manual y para poder realizar la verificación de
disponibilidad de unidades la enfermera debe de trasladarse hacia el Banco de sangre debido
a que la aplicación que administra el almacén de sangre no está integrado con el sistema core
de la clínica.
8 http://www.minsa.gob.pe/portada/Especiales/2010/donasangre/index.asp?op=3
223
Figura 40 – Propuesta de mejora - Estadistica de donaciones y transfusiones de la Clínica
Delgado
Fuente: Elaboración propia
4.1.5 PROPUESTA DE MEJORA
Para poder plantear la propuesta de mejora se realizó el análisis del problema a través de la
aplicación de una arquitectura empresarial utilizando el marco de trabajo TOGAF, mediante
el cual abordó la situación actual AS IS y se planteó la situación deseada TO BE.
La finalidad de este análisis fue detectar las brechas que permitan llegar a la mejora del
proceso, el análisis estuvo basado en los 4 dominios: Negocio, Datos, Aplicaciones y
Tecnología y se plantearon 2 proyectos: 1 para el proceso de Donación de sangre y 1 para el
proceso de Transfusión de sangre.
Para poder describir mejor los proyectos planteados a continuación se presentará el resumen
del análisis de la arquitectura empresarial y la propuesta de implementación de los proyectos.
224
4.1.5.1 RESUMEN DE APLICACIÓN DE ARQUITECTURA EMPRESARIAL
A través del análisis de la propuesta de arquitectura empresarial planteada se obtienen proyectos que permiten eliminar las brechas que se tienen
para poder optimizar los procesos de Donación y Transfusión de sangre. Asimismo estos proyectos deben de estar alineados con los objetivos
estratégicos de la organización. A continuación se describe el resumen de lo analizado a través de TOGAF a través de las 4 arquitecturas
(negocio, datos, aplicaciones y tecnológica):
Tabla 63 – Propuesta de mejora – Resumen Arquitectura Empresarial
SITUACIÓN ACTUAL
Principios de
Negocio
Limitaciones
SITUACIÓN DESEADA PROYECTOS BRECHAS
Donación de sangre:
1 . L a e n c u e s t a q u e s e r e a l i z a a l o s
d o n a n t e s y e l f o r m u l a r i o d e d o n a c i ó n
s e r e a l i z a n d e f o r m a m a n u a l y
p o s t e r i o r m e n t e s e a r c h i v a n e n u n
e s p a c i o f í s i c o .
2 . S e o b s e r v a q u e l a c a n t i d a d d e
d o n a c i o n e s q u e s e t i e n e e s m u y b a j a
Donación de sangre
1 . R e g i s t r o d e d o n a n t e , e n c u e s t a y
f o r m u l a r i o d e d o n a c i ó n
c e n t r a l i z a d o y d i g i t a l i z a d o .
2 . O p t i m i z a r e l t i e m p o d e
a t e n c i ó n d e l p r o c e s o d e
d o n a c i ó n .
3. I n c e n t i v a r l a c u l t u r a d e
d o n a c i ó n a t r a v é s d e l a
Implementación
de una aplicación
Web y móvil para
la donación de
sangre.
Las brechas
identificadas para
llegar a la
arquitectura deseada
se describen en el
225
d e b i d o a q u e e l p r o c e s o t o m a m u c h o
t i e m p o y l o s d o n a d o r e s d e c i d e n n o
r e g r e s a r a d o n a r .
3 . E l b a n c o d e s a n g r e n o c u e n t a c o n l a s
u n i d a d e s s u f i c i e n t e s p a r a p o d e r
a t e n d e r c o n t o d o s l o s r e q u e r i m i e n t o s
d e t r a n s f u s i o n e s d e s a n g r e d e l o s
p a c i e n t e s d e l a c l i n i c a D e l g a d o .
Principios de
Negocio
Limitaciones
t e c n o l o g í a . Anexo 03.
Transfusión de sangre
1 . E l p r o c e s o d e s o l i c i t u d d e t r a n s f u s i ó n
e s m a n u a l l o q u e p e r m i t e t e n e r
m u c h o s e r r o r e s e n e l l l e n a d o d e
d a t o s , e s t o h a c e q u e e l p r o c e s o t o m e
m a s t i e m p o d e l o d e b i d o .
2 . L a e n f e r m e r a d e b e d e t r a s l a d a r s e
f í s i c a m e n t e d e s d e e l p i s o d o n d e s e
e n c u e n t r a e l p a c i e n t e h a c i a e l b a n c o
Transfusión de Sangre
1 . P r o c e s o d e s o l i c i t u d d e t r a n s f u s i ó n
a u t o m a t i z a d o .
2 . A p l i c a c i ó n d e B a n c o d e s a n g r e
i n t e g r a d o c o n e l s i s t e m a c o r e d e l a
C í n i c a E R P x H I S .
3 . O p t i m i z a c i ó n d e l t i e m p o d e
a t e n c i ó n d e l a t r a n s f u s i ó n d e
s a n g r e .
Implementación
de un módulo
para la solicitud
de transfusión en
el sistema core de
la clínica ERP
xHIS con
integración con la
aplicación de
Banco de sangre
226
d e s a n g r e p a r a p o d e r v e r
d i s p o n i b i l d a d d e u n i d a d e s d e s a n g r e
p a r a l a t r a n s f u s i ó n , e s t o h a c e q u e e l
p r o c e s o d e m o r e .
3 . N o e x i s t e u n a i n t e g r a c i ó n d e l s i s t e m a
c o r e d e l a c l í n i c a , e n d o n d e s e
e n c u e n t r a t o d a l a i n f o r m a c i ó n d e l o s
p a c i e n t e s y l a s c a m a s , c o n e l s i s t e m a
d e B a n c o d e s a n g r e .
E-delphyn.
Fuente: Elaboración propia
4.1.5.2 ALINEACIÓN DE LOS PROYECTOS CON LOS OBJETIVOS ESTRATEGICOS
Los proyectos de mejora propuesto en base al análisis realizado en la arquitectura empresarial aplicada a la clínica Delgado tributan con el
cumpliendo de algunos objetivos estratégicos de la Organización de acuerdo a lo detallado en el siguiente cuadro:
227
Tabla 64 – Propuesta de mejora – Matriz de trazabilidad Proyectos/Objetivos Estratégicos
Procesos Proyectos Objetivos estratégicos impactados
Donación de Sangre P 1 : I m p l e m e n t a c i ó n d e u n a a p l i c a c i ó n W e b y m ó v i l p a r a
l a d o n a c i ó n d e s a n g r e
O E I 1 : P r o p o r c i o n a r u n a ó p t i m a a t e n c i ó n m é d i c a a
l o s p a c i e n t e s b r i n d á n d o l e u n s e r v i c i o q u e s a t i s f a g a
s u s n e c e s i d a d e s , r e q u e r i m i e n t o s y e x p e c t a t i v a s .
O E I 2 : M a n t e n e r t e c n o l o g í a d e p u n t a q u e p r o p o r c i o n e
e l s o p o r t e a t o d o s l o s p r o c e s o s d e l a c l í n i c a
Transfusión de Sangre P 2 : I m p l e m e n t a c i ó n d e u n m ó d u l o p a r a l a s o l i c i t u d d e
t r a n s f u s i ó n e n e l s i s t e m a c o r e d e l a c l í n i c a E R P x H I S c o n
i n t e g r a c i ó n c o n l a a p l i c a c i ó n d e B a n c o d e s a n g r e E -
d e l p h y n .
Fuente: Elaboración propia
228
4.1.5.3 BENEFICIOS DE LOS PROYECTOS DE MEJORA
De acuerdo a lo mostrado en el cuadro anterior, se detallan algunos beneficios de cada uno de
los proyectos que ayuden a tributar con los objetivos estratégicos:
P1: Aplicativo web y móvil de donación
- Permitirá agilizar el proceso ya que el registro y la encuesta podrá ser realizada a través
del aplicativo. Esto permitirá poder aplicar el primer filtro automatizado.
- Se automatizará el proceso de programación de citas para realizar la donación para los
que pasen el primer filtro.
- Se ofrecerá a los donantes información que ayude a fomentar la cultura de donación.
- A través del aplicativo se podrá enviar parte de los resultados de los análisis realizados
en la sangre del donante como un beneficio, asimismo se ofrecerán algunos descuentos en
citas médicas y exámenes en la Clínica.
P2: Módulo de Transfusión de Sangre e integración del sistema core ERP xHIS con el
aplicativo E-delphy
- Automatizar y agilizar el proceso de solicitud de transfusión de sangre y pueda ser
accedido por las enfermeras desde los módulos que existen en cada piso de la Clínica.
- Eliminar el archivado físico de las solicitudes ya que todos los registros estarán en una
base de datos.
- Integración de la información que existe en el sistema core con la información del
aplicativo de Banco de sangre.
229
4.1.5.4 RIESGOS IDENTIFICADOS
Se empleará la matriz de probabilidad e impacto como apoyo para priorizar los riesgos.
La valoración que se asigna a cada riesgo es subjetiva y se basa en las siguientes tablas:
Tabla 65 – Propuesta de mejora - Valores para Probabilidad e Impacto
Probabilidad
Impacto
Nada probable 0.1
Muy bajo 0.05
Poco probable 0.3
Bajo 0.1
Medianamente probable 0.5
Moderado 0.2
Bastante probable 0.7
Alto 0.4
Muy probable 0.9
Muy alto 0.8
Fuente: Elaboración propia
La Matriz de Probabilidad e Impacto es una tabla de doble entrada que combina la
probabilidad de que ocurra un evento, con el impacto que éste puede causar en el Proyecto.
De esta manera, conseguimos establecer una priorización de los riesgos.
Tabla 66 – Propuesta de mejora - Matriz de Probabilidad e Impacto (escala relativa)
Probabilidad Amenazas Oportunidades
0.9 0.05 0.09 0.18 0.36 0.72 0.72 0.36 0.18 0.09 0.05
0.7 0.04 0.07 0.14 0.28 0.56 0.56 0.28 0.14 0.07 0.04
0.5 0.03 0.05 0.10 0.20 0.40 0.40 0.20 0.10 0.05 0.03
0.3 0.02 0.03 0.06 0.12 0.24 0.24 0.12 0.06 0.03 0.02
0.1 0.01 0.01 0.02 0.04 0.08 0.08 0.04 0.02 0.01 0.01
0.05 0.1 0.2 0.4 0.8 0.8 0.4 0.2 0.1 0.05
Impacto
Fuente : Elaboración propia
Finalmente, se listan los factores de riesgo que ponen en peligro el desarrollo del proyecto,
para este fin se evaluará la parte izquierda de la matriz, Amenazas.
230
Tabla 67 – Propuesta de mejora – Matriz de Análisis de riesgos
Fuente: Elaboración propia
N° Riesgo Probabilidad Impacto Resultado Estrategia
1
Resistencia al cambio por parte de los médicos
y enfermeras respecto a la implementación del
aplicativo web y/o móvil de donante.
0.5 0.1 0.05
Realizar capacitaciones continuas sobre el nuevo
aplicativo sus funcionalidades y herramientas, y
comunicar anticipadamente su implementación.
2
Incremento en el tiempo y costo estimado para
el proyecto por no tener la disponibilidad al
100% de los recursos.
0.3 0.4 0.12
Asignación de recursos al 100% al proyecto para
lograr objetivo de tiempo y costo requerido, buscar
apoyo de Gerente de Operaciones y División de TI.
3
Disminución de la performance del aplicativo
core Xhis debido a que más usuarios en
simultáneo estarán haciendo uso por agregar el
módulo de transfusión de sangre.
0.3 0.4 0.12 Adquirir un nuevo servidor para balancear la carga
de concurrencia de usuarios al sistema Xhis.
4
No contar con los recursos técnicos necesarios
que puedan dar soporte a la propuesta de
negocio.
0.5 0.2 0.10
Brindar capacitaciones y manuales al equipo de
centro de servicios TI para que puedan brindar el
soporte a los aplicativos nuevos.
5
Actualización de versiones de software del
ERP xHIS que genere incompatibilidad con el
nuevo módulo de transfusión de sangre.
0.1 0.8 0.08 Solicitar a proveedor no generar actualizaciones
durante el periodo de dure el proyecto.
6 En la actualidad el equipo de TI no cuenta con
desarrolladores de aplicativos móviles. 0.3 0.2 0.06
Se requiere contratar un recurso externo
especializado en aplicaciones móviles para el
proyecto.
7
Incremento de costos del mantenimiento del
ERP-xHIS por un nuevo módulo e integración
con nuevos aplicativos (dependencia del
proveedor por ser el único proveedor local)
0.3 0.1 0.03 Realizar contratos que incluyan las tarifas a largo
plazo
231
4.1.5.5 PROPUESTA DE IMPLEMENTACIÓN DE LOS PROYECTOS DE MEJORA
Figura 41 – Propuesta de mejora – Diagrama de Implementación de proyectos
Fuente: Elaboración propia
Para poder determinar la mejor forma de desarrollo de los proyectos se realizado un análisis al proceso de Banco de sangre a través de un
análisis FODA (ver Anexo 03) y el marco de trabajo Cynefin, como conclusión de este análisis se tiene que el proceso se encuentra en un
dominio complicado.
23
2
Se realizó el mismo análisis para el equipo de desarrollo y la conclusión es que se encuentra en
un dominio complejo.
En base a este resultado se plantea la implementación del marco de trabajo SCRUM para el
desarrollo de los proyectos de mejora.
Por qué SCRUM:
La involucración de los roles que participan del proceso de donación de sangre en el
desarrollo de la aplicación Web y móvil es vital para que el producto final sume en la
eficacia y eficiencia del proceso. Con el rol de Product Owner, el Coordinador de
Servicios Médicos, el cual es el responsable de definir las metodologías, políticas,
procesos a utilizar en el área de TI y con la ayuda del equipo Scrum definirán el
comportamiento del software para que dé valor al proceso. La participación del Coordinar
de Servicios Médicos como Product Owner será constante para así garantizar que el
software a desarrollar cumpla con los requerimientos acordados.
Conseguir un producto software funcionando cada 3 semanas (el cual será la duración de
cada sprint), permitirá que se valide la funcionalidad de forma temprana y que se
identifiquen los cambios necesarios para que el este esté alineado con lo que necesita el
proceso.
Por medio del daily SCRUM, se podrá identificar desde el comienzo los problemas que
estén ocurriendo durante el desarrollo de los requerimientos. Por ejemplo, al tener
conocimiento de la complejidad de las tareas a realizar, si un miembro del equipo reporta
que sigue trabajando en una tarea sencilla que empezó el día anterior, se puede identificar
la posible existencia de un problema potencial en esa tarea. Así mismo, es necesaria la
transparencia del equipo para reportar las demoras en las tareas; ya que, esto apoyara a
identificar los problemas y por lo tanto buscar soluciones con todo el equipo.
De la misma forma, el daily SCRUM apoyara a cohesionar al equipo; puesto que, todos
los miembros estarán informados de los estados de las tareas y qué persona está
realizando qué actividad. Además, al ocurrir problemas, todos los miembros del equipo
podrán aportar ideas para solución.
23
3
EQUIPO DE DESARROLLO PROPUESTO
Tomando en cuenta que para la correcta aplicación del marco de trabajo SCRUM se debe de
tomar como base los valores de SCRUM:
Figura 42 – Propuesta de mejora – Valores de Scrum
Fuente: http://scrum.org
Se plantea el siguiente grupo de trabajo con sus respectivas habilidades blandas y duras:
23
4
Tabla 68 – Propuesta de mejora – Roles grupo Scrum propuesto
ROL RESPONSABILIDADES
Product Owner Este rol será llevado a cabo por el Coordinador de Servicios
Médicos, el cual conoce todo el proceso.
- Es la cara del proceso hacia el equipo de desarrollo. Debe
transmitir lo que el proceso necesita hacia el software a
construir.
- Recolectar todas aquellas user stories que serán tomadas
en el sprint, de acuerdo a qué le da más valor al negocio
(en este caso, los sub procesos de donación y transfusión
de sangre)
- Mantener el product backlog actualizado, indicando
cuáles son las prioridades de las user stories.
Habilidades:
- Excelente nivel de comunicación y que también permita
transmitir sus ideas con claridad.
- Orientado al cliente donde pueda gestionar las
expectativas de los stakeholders.
- Conocer el proceso de donación y transfusión de sangre.
23
5
Scrum Master Este rol será llevado a cabo por el Jefe de Arquitectura, el cual
conoce a los Scrum Team ya que viene de interactuar de otros
proyectos.
Responsabilidades
- Liderar al equipo de trabajo.
- Coordinar con el product owner para que este pueda
mantener el product backlog
- Ser facilitador para resolver problemas y guiar al equipo
en cumplimiento con el marco de trabajo SCRUM
Habilidades
- Conocer y dominar el framework SCRUM.
- Capacidad de negociación y solucionador de conflictos
- Pensamiento crítico
- Investigador e inspirador
- Manejo de habilidades blandas
- Conocimiento en tecnologías de desarrollo
23
6
Scrum Team Estará compuesto por 3 desarrolladores, 2 analistas funcionales y
un analista QA, adicionalmente un analista de infraestructura.
Asimismo, se contará con un consultor externo de experiencia en
aplicaciones móviles
Responsabilidades
- Desarrollar el software Web y móvil de la aplicación de
donación de sangre.
- Desarrollar la integración de la aplicación de donación de
sangre con el software EDelphyn.
- Desarrollar el módulo de transfusión de sangre e
integrarlo con el ERP Xhis.
- Desplegar las aplicaciones desarrolladas en la plataforma.
Habilidades
- Compromiso para aplicar el marco de trabajo
- Ser autosuficientes, con capacidad de tomar decisiones
que estén en su ámbito de trabajo.
Conocimientos técnicos
- Conocimiento del lenguaje C#
- Conocimiento de Web API .NET
- Conocimiento de IOS y Android
- Conocimiento de MSSQL Server 2012
- Conocimiento de Oracle 11g R2
23
7
- Conocimiento de Material Design
- Conocimiento de Eclipse
Fuente: Elaboración propia
FACTIBILIDAD DE IMPLEMENTACIÓN
COSTOS DEL PROYECTO
La empresa tiene limitaciones a nivel financiero el cual se describe a continuación:
Limitaciones financieras
La red Auna al cual pertenece la Clinica Delgado que es el objeto de estudio para la aplicación
de una arquitectura empresarial cuenta con la solidez económica necesaria para poder ejecutar
proyectos con la finalidad de conseguir los objetivos estratégicos de la organización. El
presupuesto para proyectos es de s/. 4’260,164.00 soles.
De acuerdo a lo verificado en el análisis de brechas (ver Anexo 03) se requiere cambios a nivel de
infraestructura y un equipo de desarrollo que será conformada por personal de la misma empresa
por lo cual se hizo el costeo de las horas hombre que se requieren para la implementación.
Tabla 69 – Propuesta de mejora – Tablas de costos de los proyecto
DESCRIPCIÓN COSTO
Infraestructura S/. 50.000,00
Servidor Banco de Sangre S/. 25.000,00
23
8
Servidor Balanceo EPR Xhis S/. 25.000,00
Equipo Humano S/. 107.106,00
Arquitecto Empresarial S/. 5.170,00
Arquitecto Negocio S/. 6.960,00
Arquitecto TI S/. 15.908,00
Product Owner S/. 7.650,00
Scrum Master S/. 9.080,00
Desarrolladores ( 3 ) S/. 52.927,00
Analista de Infraestructura S/. 1.534,00
Consultor Externo S/. 7.877,00
COSTO TOTAL S/. 157.106,00
Fuente: Elaboración propia
En conclusión, es factible la implementación del proyecto a nivel financiero.
TIEMPO DE EJECUCIÓN PROPUESTO
El tiempo de ejecución de los proyectos de mejora es de 5 meses. El tiempo se encuentra dentro
de los plazos establecidos por la Clínica para poder mejorar ambos procesos.
Adicional al cronograma de arquitectura empresarial detallada en el Anexo 04 se plantean el
detalle de ejecución de los proyectos de mejora:
23
9
Figura 43 – Propuesta – Cronograma de ejecución proyectos de mejora
Fuente: Elaboración propia
24
0
24
1
CONCLUSIONES
La tesis propuesta ayudará a la Clínica Delgado a obtener una ventaja competitiva debido a
que los proyectos de mejora para los procesos de donación y transfusión de sangre permitirán
brindar una servicio de calidad y a cumplir con los requerimientos y expectativas de los
pacientes que es un objetivo estratégico de la organización.
El aplicativo web y móvil para la donación de sangre permitirá reducir considerablemente el
tiempo de ejecución del proceso que es la principal limitante para captar potenciales
donadores
Integrar todas las aplicaciones de la red Auna permitirá poder tener información centralizada
necesaria para la toma de decisiones estratégicas que permitan mejorar el posicionamiento de
todas sus centros de salud.
Actualmente los proyectos de desarrollo en la clínica Delgado presentan problemas con cubrir
las expectativas del usuario final, el implementar el marco de trabajo SCRUM permitirá
mejorar ese punto ya que cambiará la forma de interacción del usuario de negocio con el
equipo de desarrollo, ya que se validará constantemente las funcionalidades que se vayan
construyendo y se podrán cambiar los alcances en caso se requiera.
La inversión de proyectos de TI se perciben con un gasto y no como una inversión, esto
disminuye el desarrollo de nuevas propuestas que permitan ayudar a la organización a
mejorar y cumplir con sus objetivos.
24
2
RECOMENDACIONES
Se recomienda realizar la implementación de todos los proyectos de la cartera listada para
poder lograr un resultado integral de la aplicación de arquitectura empresarial sobre los
procesos de estudio.
Se recomienda extender la aplicación de la arquitectura empresarial a todos los procesos de la
organización de tal forma que la calidad de servicio hacia los pacientes sea cada vez de mayor
calidad y mas eficaces.
Se debe de aprovechar el conocimiento que tienen más de 3 personas en el área de TI sobre el
marco de trabajo SCRUM para poder implantarlo en los proyectos de desarrollo de tal forma
que se pueda mejorar la calidad de las aplicaciones y se mejore con el cumplimiento de los
requerimientos del usuario de negocio.
Extender la inicitiva de aplicación de una arquitectura empresarial a todas las empresas que
conforman la red AUNA con la finalidad de mejorar sus procesos y asi poder brindar un
mejor servicio a los pacientes que genere una ventaja competitiva para la organización.
En base a la experiencia de aplicación del marco de trabajo SCRUM para el desarrollo de los
proyectos de mejora del Banco de sangre, se debe de evaluar la posibilidad de aplicar este
marco de trabajo progresivamente a los demás proyectos que tiene la clínica.
Se debe de implementar como buena práctica la automatización de procesos manuales de tal
forma que se elimine el uso del papel y se reutilice el espacio físico utilizado para el almacén
de esta información.
24
3
GLOSARIO DE TÉRMINOS
- xHIS: ERP HIS asistencial, el cual permite la automatización de procesos asistenciales desde
la admisión hasta la facturación y liquidación con aseguradoras.
- E-Delphyn: Programa de administración del Banco de sangre.
24
4
SIGLARIO
1. HIS: Hospital Information System
2. UCI: Unidad de cuidados intensivos
3. UCIN: Unidad de cuidados intensivos Neonatal
4. CEX: Consulta Externa
5. URG: Urgencias
6. HOS: Hospitalización
7. CQX: Cirugía
8. EDT: Estructura de descomposición del trabajo
9. ERP: Enterprise Resource Planning
10. PRD: Producción
11. TI: Tecnologías de Información
12. MOF: Manual de roles y funciones.
24
5
24
6
REFERENCIAS BIBLIOGRÁFICAS
Agiles, P. (2014) ¿Qué es Scrum?. Recuperado de http://www.proyectosagiles.org/que-es-scrum
Aikins J. S., Kunz J. C., Shortliffe E. H., Fallat R. J. (1983), PUFF: An Expert System for
Interpretation of Pulmonary Function Data. Computer Biomedical Research, 16(3), pp. 199-208
Arango, M.; Londoño, J.; Zapata, J. (2010) Arquitectura empresarial : una visión general. Revista
Ingenierías Universidad de Medellín, 9(16), pp. 101-111
Ato Ogoe. (2005). Medical Informatics: A look at Computer -Aided Diagnosis. Recuperado de
http://users.abo.fi/mwalden/SemiUpps05/AO_final.pdf
Duro, J. (2015) Nuevas tecnologías. Recuperado de:
https://www.miticatechnology.com/index.php/blog-nuevas-tecnologias/68-desarrollo-
%C3%A1gil-de-software-scrum
Federal Enterprise Architecture Framework Version 2 (2013) Recuperado de:
https://eapad.dk/gov/us/feaf2/
Gil, A. (2011) Descripción Conceptual de Arquitecturas Empresariales. Recuperado de
https://alekseigil.wordpress.com/2011/07/22/arquitecturas_empresariales/
Goethals, F.; Snoeck, M.; Lemahieu, W.; Vandenbulcke, J.(2006). Managements and enterprise
architecture click: The FAD(E)E framework. Information Systems Frontiers, 8(2), pp. 67-79.
Gonzáles, E., & Álzate, J. (2010). Frameworks de Arquitectura Empresarial. Recuperado de
https://arquitecturaempresarialcali.wordpress.com/2010/11/16/frameworks-dearquitectura-
24
7
empresarial/
Granja, C.; Vallejo, R. (2015) Adopción de un marco metodológico de arquitectura empresarial
en una empreesa gubernamental, caso de estudio de administración de impuestos (Tesis de
maestría) Quito, Pontificia Universidad Católica de Ecuador
Guillén, J. (2013) Modelo de dirección de proyectos complejos : aplicación a la gestión
integrada de la Comunidad de Regantes Lasesa (Huesca). (Tesis de doctorado) Madrid,
Universidad Politécnica de Madrid
Kurtz, C.F.; Snowden, D. (2003) The new dynamics of strategy : Sense-making in a complex and
complicated world. IBM Systems Journal, 42(3), pp. 462-483
Lagerström, R.; Sommestad, T.; Buschle, M.; Ekstedt, M. (2011). Enterprise architecture
management's impact on information technology success. Proceedings of 44th Hawaii
International Conference on System Sciences. Piscataway : IEEE
Lankhorst, M. (2009) Enterprise Architecture at Work : Modelling, Communication and
Analysis. 2da. ed. Novay : Springer
Lemaire J. B., Schaefer J. P., Martin L. A., Faris P. (1999). Ainslie M. D., Hull R. D.,
Effectiveness of the Quick Medical Reference as a Diagnostic Tool. CMAJ. 161(6).
Londoño, J. (2014) Modelo funcional de Integración de la Arquitectura Empresarial de ‘N’
entidades alrededor de un grupo empresarial. Un enfoque de orientación a servicios y modelado
de capacidades de negocio (Tesis de doctorado), Medellín, Universidad Nacional de Colombia.
Recuperado de: http://www.bdigital.unal.edu.co/46046/1/70322207.2014.pdf
Mariño , S.; Alfonzo, P. (2014) Implementación de SCRUM en el diseño del proyecto del
Trabajo Final de Aplicación. Scientia et Technica, 19(4), pp. 413-418.
24
8
Morales, C. (2010) Aplicación de los Frameworks CIMOSA y TOGAF en el ciclo de vida de la
arquitectura empresarial (Tesis de grado) Lima, Universidad Peruana de Ciencias Aplicadas.
Murillo, M. (2016) Modelo de referencia para la medición de capacidades en la implementación
de arquitectura empresarial caso : gobierno colombiano (Tesis de Maestría), Medellín,
Universidad de EAFIT. Recuperado de
https://repository.eafit.edu.co/bitstream/handle/10784/11354/Mauricio_MurilloBenitez_2016.pdf
?sequence=2
Rey Guevara, C. (2017) Estudio de la efectividad de la aplicación de metodología ágil de
desarrollo Scrum (Tesis de grado) Quito, Universidad Tecnológica Israel
Román, C. (2011) Integración de buenas prácticas para la definición de un framework de
arquitectura empresarial para la Universidad Técnica Particular de Loja (Tesis de Grado) Loja,
Universidad Técnica Particular de Loja
Rubin, K. (2012) Essential Scrum : A Practical Guide to the Most Popular Agile Process.
Reading : Addison-Wesley
Sajid, M.; Ahsan, K. (2016) Role of Enterprise Architecture in Healthcare Organizations and
Knowledge-Based Medical Diagnosis System. Journal of Information Systems and Technology
Management, 13(2). pp. 181-192
Sandoval, F.; Galvez, V; Moscoso, O. (2017) Desarrollo de Arquitectura Empresarial usando un
Framework con Enfoque Ágil. Enfoque UTE, 7(Sup.1), pp.135 – 147
Schwaber, K.; Sutherland, J. (2013) La guía definitiva de Scrum : las reglas de juego.
Westminter : Scrum
Snowden, D. (2000) The Social Ecology of Knowledge Management. En: Knowledge Horizons :
the present and the Promise of Knowledge Management. Oxford : Butterworth-Heinemann
24
9
The Open Group (2013) TOGAF® Version 9.1. San Francisco : TOG
Wolfram D. A. (1995). An Appraisal of Internist-I Oxford University Computing Laboratory,
Programming Research Group, UK., Artifil Internet Media, 7(2), pp. 93-116.
Xu, B.; Xu, L.; Cai, H.; Jiang, L.; Luo, Y.; Gu, Y. (2015) The design of an m-Health monitoring
system based on a cloud computing platform. Enterprise Information Systems, 11 (1)
25
0
ANEXOS
Anexo 01
Plantilla de Cuestionario para la Donación
25
1
ANEXO 02
Cuadro de estimación de costos
A continuación, se muestra el cuadro de estimación de costos, en él se incluyen los costos del recurso humano relacionados a los proyectos. Este cálculo se ha realizado en base al juicio de
expertos.
Tabla 70 – Cuadro de estimación de costos - Anexo
PROYECTO
MESES
DIAS POR
MES
HOR
AS
POR
DÍA
TOTAL DE
HORAS POR
PROYECTO
ROL
% DE
PARTICIPACIÓ
N EN
PROYECTO
HORAS
P
OR
RECURS
O
SUELDO
SUELDO
POR
HORA
CANTIDAD
DE
RECURSOS
TOTAL COSTO
RECURSOS (S/.)
P1 – Desarrollo Portal Web Donación
Costo total del proyecto
3.75 22 8 660 Desarrollador
Scrum Master
Product Owner
100
20
15
660
132
99
3500
7000
8000
19.89
39.77
45.45
3
1
1
39382
5250
4500
49132
P2 – Desarrollo Aplicativo
Móvil Donación
2.625
22
8
462
Desarrollador
50
231
3500
19.89
1
4595
Scrum Master 15 69.3 7000 39.77 1 2756
Product Owner 15 69.3 8000 45.45 1 3150
Consultor externo 100 462
3000 17.05 1 7877
Costo total del proyecto
18378
P3 – Desarrollo de módulo de
transfusión ERP xHIS
0.75
15
8
90
Desarrollador
Scrum Master
100
30
90
27
3500
7000
19.89
39.77
3
1
5370
1074
6444
25
2
Costo total del proyecto
P4 – Integración Aplicativo WEB/Móvil - Edelphyn
0.75
15
8
90
Desarrollador 100
90
3500
19.89
1
1790
Costo total del proyecto
Analista de Infraestructura
50 45 3000 17.05 1 767.25
2557.25
P5 – Integración ERP Xhis - Edelphyn
Costo total del proyecto
0.75
15
8
90
Desarrollador Analista de
infraestructura
100
50
90
45
3500
3000
19.89
17.05
1
1
1790
767.25
2557.25
Fuente: Elaboración propia
PROYECTO
MESES
DIAS POR
MES
HORAS
POR
DÍA
TOTAL DE
HORAS POR
PROYECTO
ROL
% DE
PARTICIPACIÓN
EN PROYECTO
HORAS
POR
RECURSO
SUELDO
SUELDO
POR
HORA
CANTIDAD
DE
RECURSOS
TOTAL COSTO
RECURSOS (S/.)
Propuesta de una Arquitectura Empresarial para una Empresa de Salud
Costo total del proyecto
2 22 8 350 Arquitecto E.
Arquitecto N.
Arquitecto TI
20
50
100
70
175
350
13000
7000
8000
73.86
39.77
45.45
1
1
1
5170
6960
15908
28038
25
3
ANEXO 03
ANÁLISIS DE BRECHAS
ARQUITECTURA DE NEGOCIO
DONACIÓN DE SANGRE
Tabla 71 – Análisis de Brechas / Arquitectura de Negocio / Donación de Sangre - Anexo
Arquitectura Objetivo
Arquitectura Línea Base Recepción
de llamada
Comunicar a
donante
fecha y hora
de atención
Recibir y
confirmar
identificación
del donante
Confirmar
ingreso de
donante a
banco de
sangre
Comunicar
llenado de
formulario
Rellenar
formulario
Validación
de
formulario
Entrevista
Personal
Tomar
signos vitales
Evaluar al
donante
Realiza
donación
Recepción de llamada Se Mantiene
Comunicar a donante fecha y hora de
atención Eliminar
Recibir y confirmar identificación del
donante Se Mantiene
Confirmar ingreso de donante a banco de
sangre Eliminar
Comunicar llenado de formulario
Eliminar
Rellenar formulario
Eliminar
Validación de formulario
Eliminar
Entrevista Personal
Se Mantiene
Tomar signos vitales
Se Mantiene
Evaluar al donante
Se Mantiene
Realiza donación
Se Mantiene
25
4
Arquitectura Objetivo
Arquitectura Línea Base Registro del
resultado
Evaluar
estado de la
sangre
Resultado de
evaluación
Almacenar
Sangre
Crear
usuario de
donante en
portal o app
móvil
Registro de
información
personal
Elaboración
de pre
formulario
Generar cita Cancelar
cita
Re
programar
cita
Registro de
signos vitales
Registro del resultado Eliminar
Evaluar estado de la sangre Se mantiene
Resultado de evaluación Se mantiene
Almacenar sangre
Se
mantiene
Nuevo
Implementar Implementar Implementar Implementar Implementar Implementar Implementar
Arquitectura Objetivo
Arquitectura Línea Base
Registro de
incidentes de
donación
Recepción
de
resultados
Ingreso de
observaciones
del médico
del resultado
de sangre
Envió de
resultados a
donante
Visualizar
resultados
desde el
portal Web y
App Móvil
Consulta de
información
de donantes
Envió de
invitaciones
a donantes
para volver
a donar
Ingreso de
comentarios
del donante
Solicitar análisis de sangre
Nuevo Implementar Implementar Implementar Implementar Implementar Implementar Implementar Implementar Implementar
Fuente: Elaboración propia
25
5
TRANSFUSIÓN DE SANGRE
Tabla 72 - Análisis de Brechas / Arquitectura de Negocios / Transfusión de Sangre - Anexo
Arquitectura Objetivo
Arquitectura
Línea Base
Pedido de
transfusión
Revisión de
sangre
Registro de
pedido
Extracción de
sangre Retiro de sangre Prueba cruzada
Se libera
unidades de
sangre
Aplicar
transfunde
Devolución de
bolsa de sangre
Pedido de transfusión Se mantiene
Revisión de sangre Se mantiene Registro de pedido Se mantiene
Extracción de sangre Se mantiene
Retiro de sangre Se mantiene
Prueba cruzada Se mantiene Se libera unidades de sangre Se mantiene
Aplicar transfunde Se mantiene
Devolución de bolsa de sangre Se mantiene
Registra transfusión
Pedido de transfusión Revisión de sangre Registro de pedido
Extracción de sangre
Retiro de sangre
Prueba cruzada
Se libera unidades de sangre
Aplicar transfunde
25
6
Arquitectura Objetivo
Arquitectura
Línea Base
Solicitud de
transfusión
Solicitud de perfil
pre-transfusional
Envió de datos
demográficos del
paciente
Modificación de
datos
demográficos
Envió de
realización de
transfusión
Envió de
incidentes post
transfusión
Resultados de
perfil pre
transfusional
Resultados de
prueba cruzada
Código de
reserva de bolsa
de sangre
Nuevo Implementar Implementar Implementar Implementar Implementar Implementar Implementar Implementar Implementar Fuente: Elaboración propia
25
7
ARQUITECTURA DE SISTEMAS DE INFORMACIÓN
ARQUITECTURA DE DATOS
DONACIÓN DE SANGRE
Tabla 73 – Análisis de Brechas / Arquitectura de Datos / Donación de Sangre - Anexo
Arquitectura Objetivo
Arquitectura
Línea Base
TIPO_SANGR
E DONANTE
ANALISIS_
CILINICO ALMACEN
SANGRE_D
ONADA
RESULTADO
_PACIENTE
CARACTER
ISTICAS_SA
NGRE
RESULTAD
O_ANALISI
S
DONACION ENCUESTA MEDICO ENFERMEDA
DES
NUEVO Implementar Implementar Implementar Implementar Implementar
Implementar Implementar Implementar Implementar Implementar Implementar Implementar
Fuente: Elaboración propia
25
8
TRANSFUSIÓN DE SANGRE
Tabla 74 – Análisis de Brechas / Arquitectura de Datos / Transfusión de Sangre – Parte 1 - Anexo
Arquitectura Objetivo
Arquitectura Línea Base
HISTORIA
_CLINICA PACIENTE ENFERMERA
MUESTRA_SA
N
PRUEBA_CR
UZADA TRANSFUSION
ALMACEN_SAN
GRE
SOLICITUD_TRAN
SFERENCIA MEDICOS
ESPECIALIDAD
ES
HISTORIA_CLINICA Se mantiene
PACIENTE Se mantiene
ENFERMERA Se mantiene
MUESTRA_SAN Se mantiene
PRUEBA_CRUZADA Se mantiene
TRANSFUSION Se mantiene
ALMACEN_SANGRE Se mantiene SOLICITUD_TRANSFERE
NCIA Se mantiene
MEDICOS Se mantiene
ESPECIALIDADES Se mantiene
Fuente: Elaboración propia
25
9
Tabla 75 – Análisis de Brechas / Arquitectura de Datos / Transfusión de Sangre – Parte 2 - Anexo
Arquitectura Obejtivo
Arquitectura Línea Base CAMAS CENTROS CLIENTES
TIPO_HABI
TACION ACTIVIDADES
HISTORIA_CLINICA PACIENTE ENFERMERA MUESTRA_SAN PRUEBA_CRUZADA TRANSFUSION ALMACEN_SANGRE SOLICITUD_TRANSFERE
NCIA MEDICOS ESPECIALIDADES NUEVO Implementar Implementar Implementar Implementar Implementar
Fuente: Elaboración propia
26
0
ARQUITECTURA DE APLICACIONES
DONACIÓN DE SANGRE
Tabla 76 - Análisis de Brechas / Arquitectura de Aplicaciones / Donación de Sangre – Anexo
Fuente: Elaboración propia
Arquitectura Objetivo
Arquitectura
Línea Base xHIS xFarma eHC HPresc xGPC Rispacs Endoc Omega SAP EDelphyn
Portal Web
Donante
App Móvil
Donante
xHIS Se mantiene
xFarma
Se mantiene
eHC
Se mantiene
HPresc
Se mantiene
xGPC
Se mantiene
Rispacs
Se mantiene
Endoc
Se mantiene
Omega
Se mantiene
SAP
Se mantiene
EDelphyn
Se mantiene
Nuevo
Implementar Implementar
26
1
ARQUITECTURA TECNOLÓGICA
DONACIÓN DE SANGRE
Tabla 77 - Análisis de Brechas / Arquitectura de Tecnológica / Donación de Sangre – Parte 1 - Anexo
Fuente: Elaboración propia
Arquitectura Objetivo
Arquitectura
Línea Base
GS
PL
MO
ISO
FT
01
GS
PL
MO
ISO
FT
06
GS
PL
MO
ISO
FT
07
GS
PL
MO
HIS
EB
GS
PL
MO
FS
01
AU
NS
NB
CX
02
GS
PL
MO
ISO
FT
05
GS
PH
ISP
RD
GS
PL
MO
ISO
FT
04
GS
PE
RP
PR
D
AU
NM
OL
CA
S1
GSPLMOISOFT01 Se mantiene
GSPLMOISOFT06 Se mantiene
GSPLMOISOFT07 Se mantiene
GSPLMOHISEB Se mantiene
GSPLMOFS01 Se mantiene
AUNSNBCX02 Se mantiene
GSPLMOISOFT05 Se mantiene
GSPHISPRD Se mantiene
GSPLMOISOFT04 Se mantiene
GSPERPPRD Se mantiene
AUNMOLCAS1 Se mantiene
26
2
Tabla 78 - Análisis de Brechas / Arquitectura de Tecnológica / Donación de Sangre – Parte 3 - Anexo
Arquitectura Objetivo
Arquitectura
Línea Base
GS
PL
MO
AP
03
GS
PD
EL
AD
01
Cli
ente
Clí
nic
a
Del
ga
do
Cli
ente
Call
Cen
ter
SR
V B
an
co
Sa
ng
re
GSPLMOAP03 Se mantiene
GSPDELAD01 Se mantiene
Cliente Clínica Delgado Se mantiene
Cliente Call Center Se mantiene
NUEVO Implementar Fuente: Elaboración propia
26
3
TRANSFUSIÓN DE SANGRE
Tabla 79 - Análisis de Brechas / Arquitectura de Tecnológica / Transfusión de Sangre – Parte 1 - Anexo
Fuente: Elaboración propia
Arquitectura Objetivo
Arquitectura
Línea Base GSPLMOISOFT01 GSPLMOISOFT06 GSPLMOISOFT07 GSPLMOHISEB GSPLMOFS01 AUNSNBCX02 GSPLMOISOFT05 GSPHISPRD
GSPLMOISOFT01 Se mantiene
GSPLMOISOFT06 Se mantiene
GSPLMOISOFT07 Se mantiene
GSPLMOHISEB Se mantiene
GSPLMOFS01 Se mantiene
AUNSNBCX02 Se mantiene
GSPLMOISOFT05 Se mantiene
GSPHISPRD Se mantiene
26
4
Tabla 80 - Análisis de Brechas / Arquitectura de Tecnológica / Transfusión de Sangre – Parte 2 - Anexo
Arquitectura Objetivo
Arquitectura
Línea Base GSPLMOISOFT04 GSPERPPRD AUNMOLCAS1 GSPLMOAP03 GSPDELAD01
Cliente Clínica
Delgado
Cliente Call
Center EDelphyn GSPLMOISOFT20
GSPLMOISOFT04 Se mantiene
GSPERPPRD Se mantiene
AUNMOLCAS1 Se mantiene
GSPLMOAP03 Se mantiene
GSPDELAD01 Se mantiene
Cliente Clínica
Delgado Se mantiene
Cliente Call Center Se mantiene
EDelphyn Se mantiene
Nuevo
Implementar
Fuente: Elaboración propia
A n e x o 0 4
C r o n o g r a m a A r q u i t e c t u r a e m p r e s a r i a l – D o n a c i o n y T r a n s f u s i ó n d e s a n g r e
Top Related