Propuesta de una arquitectura empresarial para una empresa ...

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

http://creativecommons.org/licenses/by-nc-sa/4.0/

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


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


9

Figura 23 - Arquitectura Línea Base – Arquitectura de aplicaciones / Diagrama de

aplicaciones .................................................................................................................... 134


Figura 24 - Arquitectura Línea Base – Arquitectura tecnológica / Diagrama de infraestructura

........................................................................................................................................ 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


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


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


Figura 33 - Arquitectura Destino – Arquitectura de aplicaciones / Transfusión de sangre ... 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


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


Tabla 40 - Arquitectura Destino – Arquitectura Tecnológica / Donación de Sangre ............ 156

Tabla 41 - Arquitectura Destino – Arquitectura Tecnológica / Transfusión de Sangre ........ 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


........................................................................................................................................ 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


3...................................................................................................................................... 169

Tabla 50 - Análisis de Brechas / Arquitectura de Tecnológica / Transfusión de Sangre –

Parte 1 ............................................................................................................................ 170


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


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


Tabla 76 - Análisis de Brechas / Arquitectura de Aplicaciones / Donación de Sangre – Anexo

........................................................................................................................................ 260


1 - Anexo........................................................................................................................ 261


3 - Anexo........................................................................................................................ 262


Parte 1 - Anexo .............................................................................................................. 263


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


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.



Tabla 5 - Entradas y salidas en la Arquitectura de Negocios TOGAF 9

Entradas Salidas


Principios,objetivos de negocio y motivaciones de

negocio



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


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.


36


Tabla 7 - Entradas y salidas en la Arquitectura de Datos TOGAF 9

Entradas Salidas

Petición de Trabajo de Arquitectura

Evaluación de Capacidades


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


Versión preliminar del Documento de

Definición de la Arquitectura,

conteniendo:

Arquitectura de Negocio de la Línea de

Base (de alto nivel)


actualizada si fuera necesario

Principios de datos validados o nuevos

principios de datos


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


Arquitectura de aplicación


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


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


Arquitectura


38


Tabla 9 - Entradas y salidas en la Arquitectura de Aplicación en TOGAF 9

Entradas Salidas

Petición de trabajo de Arquitectura



Modelo organizacional de Arquitectura

empresarial

Marco de referencia de Arquitectura adaptado

Principios de Aplicación




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)


actualizado si fuera necesario

Principios de Aplicación validados o nuevos

principios de Aplicación


Arquitectura, conteniendo actualizaciones de

contenido:

Arquitectura de Aplicación de la Línea de

Base


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


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.


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


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


Arquitectura


40


Tabla 11 - Entradas y salidas en la Arquitectura Tecnológica en TOGAF 9

Entradas Salidas




Modelo Organizacional de Arquitectura Empresarial

Marco de Referencia de Arquitectura adaptado

Principios de Tecnología




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)



Principios de Tecnología validados o nuevos

principios de Tecnología (si se generaron

aquí)


Definición de Arquitectura, conteniendo


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



Requerimientos resultantes de las Fases B y

C Requerimientos de Tecnología

actualizados


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.


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.


42


Tabla 13 - Entradas y salidas en la fase Oportunidades y Soluciones en TOGAF 9

Entradas Salidas

Información del producto



Plan de comunicaciones Metodologías

de planifi cación

Modelos de gobierno y marcos de

referencia

Marco de Referencia de Arquitectura

adaptado



Repositorio de arquitectura



Visión de la Arquitectura, actualizada si

es necesario


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



Principios de Aplicación validados o nuevos

principios de Aplicación


Arquitectura, conteniendo actualizaciones de

contenido:

Arquitectura de Aplicación de la Línea de

Base


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


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


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


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


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


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


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


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


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


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


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


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


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%


68

Tabla 18 - Arquitectura Línea Base – Matriz Objetivos estratégicos vs Procesos - Parte 2



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



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




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




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%


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



calidad al paciente

Asegurar reclutamiento de los mejores profesionales de salud

x


servicio que satisfaga sus necesidades, requerimientos y expectativas.





red Auna



HOS, CQX


procesos de la clínica x

x x

x

x




con la red Auna


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%


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


74

1.7 ORGANIGRAMA

1.7.1 ORGANIGRAMA GENERAL DE LA RED AUNA

Figura 12 - Organigrama General Red Auna


75

1.7.2 ORGANIGRAMA DE LA CLÍNICA DELGADO

Figura 13 - Organigrama de la Clinica delgado


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


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


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


Clínica Delgado


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,


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


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.


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


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


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


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.


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


104

MAPA DE PROCESOS DE LA CLINICA DELGADO

Figura 17- Arquitectura Línea Base – Mapa de Procesos Clínica Delgado


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


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


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


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


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


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


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


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


114

MATRIZ DE PROCESOS DE NEGOCIO VS OBJETIVOS DE NEGOCIO


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



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




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


que permita contar con

tecnología integrada en todos los

centros de la red Auna


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


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%


115

Tabla 28- Arquitectura Línea Base – Matriz Objetivos estratégicos vs Procesos – Parte 2



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



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


Ser líder en tecnología

asistencial que permita contar

con tecnología integrada en

todos los centros de la red Auna


Cardiología


URG, HOS, CQX


procesos de la clínica x x x x x x x x






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%


116




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



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.







Cardiología


URG, HOS, CQX


procesos de la clínica x

x x

x

x






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%


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


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


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


124

Figura 20 - Arquitectura Línea Base – Diagrama de flujo de proceso de Donación de Sangre


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


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


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


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


128

DIAGRAMA DE PROCESO – TRANSFUSIÓN DE SANGRE

Figura 21 - Arquitectura Línea Base – Diagrama de flujo Proceso Transfusión de Sangre


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


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


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


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


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


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.


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


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


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


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


Delgado


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


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)


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


141

Figura 26 - Arquitectura Destino – Diagrama de flujo de proceso Donación de Sangre


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


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


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


145

2.5.6.2 ARQUITECTURAS DE SISTEMAS DE INFORMACIÓN


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


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


148

MODELO DE DATOS LOGICO – TRANSFUSIÓN TO BE

Figura 31 - Arquitectura Destino – Modelo lógico del proceso de Transfusión


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


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


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,


2 xFarma

Módulo correspondiente a Farmacia, movimientos

de stock, dispensación de carros de unidosis,

órdenes médicas


4 Hpresc Módulo de Prescripciones médicas






10 Bmatic Gestor de colas

11 Banco Sangre Portal Web y App móvil del donante


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


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,


2 xFarma

Módulo correspondiente a Farmacia, movimientos

de stock, dispensación de carros de unidosis,

órdenes médicas


4 Hpresc Módulo de Prescripciones médicas






10 Bmatic Gestor de colas

11 E-DELPHYN Aplicación de gestión de banco de sangre


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


156

Tabla 40 - Arquitectura Destino – Arquitectura Tecnológica / Donación de Sangre

ID Infraestructura Descripción


Delgado


Delgado


Delgado

4 GSPLMOHISEB Servidor Citrix ERP HIS, sede Clínica

Delgado

5 GSPLMOFS01 Servidor Citrix ERP HIS, sede Clínica

Delgado




9 GSPLMOISOFT04

Servidor del integrador Mirth, tiene como

función integrar los sistemas brindando

información de pase de un sistema a otro


11 AUNMOLCAS1 Servidor del sistema RISPACS (Módulo

Imágenes)


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


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


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



4 GSPLMOHISEB Servidor Citrix ERP HIS, sede Clínica Delgado

5 GSPLMOFS01 Servidor Citrix ERP HIS, sede Clínica Delgado

ID INFRAESTRUCTURA DESCRIPCIÓN




9 GSPLMOISOFT04

Servidor del integrador Mirth, tiene como función

integrar los sistemas brindando información de pase

de un sistema a otro


11 AUNMOLCAS1 Servidor del sistema RISPACS (Módulo Imágenes)


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


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


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 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 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


162

TRANSFUSIÓN DE SANGRE

Tabla 43 - Análisis de Brechas / Arquitectura de Negocios / Transfusión de Sangre


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

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


Pedido de transfusión

Revisión de sangre

Registro de pedido


Retiro de sangre

Prueba cruzada


Aplicar transfunde

Devolución de bolsa de sangre


Pedido de transfusión

Revisión de sangre

Registro de pedido


Retiro de sangre Nuevo Implementar Implementar Implementar Implementar Implementar Implementar Implementar Implementar Implementar


164

2.7.7.2 ARQUITECTURA DE SISTEMAS DE INFORMACIÓN


DONACIÓN DE SANGRE

Tabla 44 – Análisis de Brechas / Arquitectura de Datos / Donación de Sangre


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



165





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


166


Arquitectura Obejtivo


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


167


DONACIÓN DE SANGRE

Tabla 47 - Análisis de Brechas / Arquitectura de Aplicaciones / Donación de Sangre



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



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



GSPLMOHISEB Se mantiene

GSPLMOFS01 Se mantiene

AUNSNBCX02 Se mantiene


GSPHISPRD 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

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


Tabla 50 - Análisis de Brechas / Arquitectura de Tecnológica / Transfusión de Sangre – Parte 1



Arquitectura

Línea Base GSPLMOISOFT01 GSPLMOISOFT06 GSPLMOISOFT07 GSPLMOHISEB GSPLMOFS01 AUNSNBCX02 GSPLMOISOFT05 GSPHISPRD









171

Tabla 51 - Análisis de Brechas / Arquitectura de Tecnológica / Transfusión de Sangre – Parte 2


Arquitectura

Línea Base GSPLMOISOFT04 GSPERPPRD AUNMOLCAS1 GSPLMOAP03 GSPDELAD01

Cliente Clínica

Delgado

Cliente Call

Center EDelphyn GSPLMOISOFT20






Cliente Clínica

Delgado Se mantiene


EDelphyn Se mantiene

Nuevo

Implementar


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


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


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


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.


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


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


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


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:


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:


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


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


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



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



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



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






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






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%


221

Tabla 62 – Propuesta de mejora - Matriz de procesos de negocio vs objetivos estratégicos – Parte 2



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



calidad al paciente

Asegurar reclutamiento de los mejores profesionales de salud x x x x x


servicio que satisfaga sus necesidades, requerimientos y expectativas. x x x x x





red Auna



HOS, CQX


procesos de la clínica x X x x x x x x




con la red Auna


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%


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


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


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.


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 .


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


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


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


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


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:

http://scrum.org/

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


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


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


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

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-

http://www.proyectosagiles.org/que-es-scrum

http://users.abo.fi/mwalden/SemiUpps05/AO_final.pdf

https://www.miticatechnology.com/index.php/blog-nuevas-tecnologias/68-desarrollo-%C3%A1gil-de-software-scrum

https://www.miticatechnology.com/index.php/blog-nuevas-tecnologias/68-desarrollo-%C3%A1gil-de-software-scrum

https://eapad.dk/gov/us/feaf2/

https://alekseigil.wordpress.com/2011/07/22/arquitecturas_empresariales/

https://arquitecturaempresarialcali.wordpress.com/2010/11/16/frameworks-dearquitectura-empresarial/

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.

https://arquitecturaempresarialcali.wordpress.com/2010/11/16/frameworks-dearquitectura-empresarial/

http://www.bdigital.unal.edu.co/46046/1/70322207.2014.pdf

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

https://repository.eafit.edu.co/bitstream/handle/10784/11354/Mauricio_MurilloBenitez_2016.pdf?sequence=2

https://repository.eafit.edu.co/bitstream/handle/10784/11354/Mauricio_MurilloBenitez_2016.pdf?sequence=2

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


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


P4 – Integración Aplicativo WEB/Móvil - Edelphyn

0.75

15

8

90

Desarrollador 100

90

3500

19.89

1

1790


Analista de Infraestructura

50 45 3000 17.05 1 767.25

2557.25

P5 – Integración ERP Xhis - Edelphyn


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


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


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 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 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




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


25

5


Tabla 72 - Análisis de Brechas / Arquitectura de Negocios / Transfusión de Sangre - Anexo


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


Pedido de transfusión Revisión de sangre Registro de pedido


Retiro de sangre

Prueba cruzada


Aplicar transfunde

25

6


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


DONACIÓN DE SANGRE

Tabla 73 – Análisis de Brechas / Arquitectura de Datos / Donación de Sangre - Anexo


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



25

8


Tabla 74 – Análisis de Brechas / Arquitectura de Datos / Transfusión de Sangre – Parte 1 - Anexo



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


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


26

0


DONACIÓN DE SANGRE

Tabla 76 - Análisis de Brechas / Arquitectura de Aplicaciones / Donación de Sangre – Anexo



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



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












26

2

Tabla 78 - Análisis de Brechas / Arquitectura de Tecnológica / Donación de Sangre – Parte 3 - Anexo


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



Cliente Clínica Delgado Se mantiene


NUEVO Implementar Fuente: Elaboración propia

26

3


Tabla 79 - Análisis de Brechas / Arquitectura de Tecnológica / Transfusión de Sangre – Parte 1 - Anexo



Arquitectura

Línea Base GSPLMOISOFT01 GSPLMOISOFT06 GSPLMOISOFT07 GSPLMOHISEB GSPLMOFS01 AUNSNBCX02 GSPLMOISOFT05 GSPHISPRD









26

4

Tabla 80 - Análisis de Brechas / Arquitectura de Tecnológica / Transfusión de Sangre – Parte 2 - Anexo


Arquitectura

Línea Base GSPLMOISOFT04 GSPERPPRD AUNMOLCAS1 GSPLMOAP03 GSPDELAD01

Cliente Clínica

Delgado

Cliente Call

Center EDelphyn GSPLMOISOFT20






Cliente Clínica

Delgado Se mantiene


EDelphyn Se mantiene

Nuevo

Implementar


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

Propuesta de una arquitectura empresarial para una empresa ...

Documents

Transcript of Propuesta de una arquitectura empresarial para una empresa ...