Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Trabajo de Titulacin
para optar
al ttulo de Ingeniero Civil Industrial
I
DEDICATORIA
Quisiera dedicarles el presente trabajo de titulacin a mis padres Ins y Carlos, quienes han dado todo
por m, me han tenido fe y me han acompaado desde siempre, han sido mi motivacin y mi ejemplo a
seguir. De igual forma quisiera dedicarle este trabajo a mi polola Jenifer, que me ha acompaado durante
ms de 3 aos, y que me sigui hasta el otro lado del mundo cuando me toc estudiar en el extranjero,
en un gesto de amor tan hermoso que nunca olvidar.
Tambin quiero hacer presentes a mis tos, Marcela y Pedro, quienes me acogieron en su hogar durante
todo el transcurso de mi carrera y que fueron un apoyo fundamental para que concluya mis estudios,
estando siempre conmigo cuando lo necesit.
Finalmente, quiero dedicar este trabajo a los profesores y amigos que conoc en la universidad, quienes
contribuyeron a que el transcurso de la carrera fuera algo agradable, combinando la alegra y el
entusiasmo con la seriedad, el compromiso y la exigencia, especialmente al Mon, el Mak y el Cue,
amigos con los que compart gran parte de la carrera y que estuvieron presentes durante todo este
proceso educativo en la universidad.
II
AGRADECIMIENTO
Quisiera expresar mi gratitud primeramente a mi profesor gua, el Sr. Luis Daz, por toda la ayuda
brindada, su dedicacin y tiempo al ayudarme a revisar y mejorar mi trabajo, por la orientacin que me
brind durante todo este proceso, que me ayud a concluir con xito el presente informe.
Por otra parte quiero agradecer al Hospital Base de Puerto Montt, por abrirme sus puestas y darme la
oportunidad de desarrollar mi tesis, especialmente al departamento de Abastecimiento, Farmacia y
bodega, donde tuve el apoyo necesario para poder realizar este trabajo. Aqu quiero destacar
principalmente a la Sra. Jennifer Salgado, Sra. Nancy Villegas, Srta. Soraya Lagreze, Srta. Sandra
Morales, el Sr. Ral Correa, y el Sr. Jos Calisto, quienes dedicaron parte de su valioso tiempo para que
pueda obtener la informacin que requera, y quienes mostraron una excelente disposicin cuando
solicit su ayuda, haciendo de esta una experiencia grata y enriquecedora.
III
SUMARIO
El presente estudio se desarrollar dentro del Hospital Base de Puerto Montt, cuyo objetivo fue presentar
una propuesta que signifique una mejora en el sistema de Abastecimiento, Farmacia y Bodega,
puntualmente en lo que respecta a la gestin de compras y el control de inventarios.
Tomando en cuenta que gran parte de los costos operacionales de una organizacin pasan por la cadena
de suministro, se decidi realizar un estudio para establecer de qu forma eran gestionadas las compras
y los inventarios, para as poder establecer cambios que agilicen los procesos implicados y mejoren el
desempeo a travs de la reduccin de costos, reduccin de tiempos y reduccin de inventarios en
bodega.
Para poder llevar a cabo este estudio, se realizar previamente un levantamiento de informacin, con el
propsito de acotar el problema, el cual contemplar los resultados de las visitas al Hospital, revisin de
manuales de procedimientos y revisin de informacin externa, con lo cual se pudo contextualizar e
identificar con mayor precisin las caractersticas del problema estudiado.
Una vez que el problema est claramente definido, se proceder a realizar un diagnstico que mostrar la
situacin en la que se encontraba el Hospital, lo que contemplar una evaluacin de los procesos, las
comunicaciones entre sus departamentos y el sistema informtico que se utiliza.
Posteriormente, con los resultados obtenidos del levantamiento de informacin y del diagnstico, se
realizar una propuesta preliminar que modific los procesos necesarios de modificar para obtener
mejores resultados, la cual fue revisada por la directiva del Hospital
Finalmente se trabaj sobre la base de la propuesta preliminar sobre la cual se elabor el modelo de
gestin de compras y control de inventarios, el que contempl la adicin de informacin para la toma de
decisiones como indicadores de gestin, incorporacin de datos histricos, adicin de categoras,
atributos y una propuesta de interfaz.
VI
NDICE
1.
Introduccin .................................................................................................................. 1
1.2
1.2.1
1.2.2
Objetivos Especficos.......................................................................................... 2
1.3
2.
Pgina
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
1.3.8
1.4
1.5
Modelo ............................................................................................................................ 9
2.2
Gestin............................................................................................................................ 9
2.2.1
Inventarios ............................................................................................................ 10
2.2.2
2.2.3
2.3
Sistema ......................................................................................................................... 12
2.3.1
2.4
2.4.1
Modelamiento de procesos.............................................................................. 13
2.5
2.6
TOC ................................................................................................................................ 14
2.6.1
2.6.2
2.6.3
VI
2.7
2.7.1
Encuesta ............................................................................................................... 16
2.7.2
Entrevista .............................................................................................................. 18
2.7.3
Muestreo ............................................................................................................... 18
2.7.4
2.7.5
2.7.6
2.8
3.
3.1.1
4.
3.2
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.4
3.5
3.6
3.7
Retroalimentacin...................................................................................................... 25
3.8
RESULTADOS .................................................................................................................... 27
4.1
Anlisis ......................................................................................................................... 27
4.1.1
4.1.2
4.1.3
4.2
4.2.1
4.2.2
4.2.3
Diagnstico: ......................................................................................................... 30
Procesos: ..................................................................................................................... 30
Comunicaciones: ....................................................................................................... 31
VI
Atributos del sistema informtico: ........................................................................... 33
Desempeo del sistema informtico: ...................................................................... 34
4.3
Abastecimiento: ................................................................................................................ 37
Farmacia: ............................................................................................................................ 41
Bodega: ............................................................................................................................... 44
4.3.2
Retroalimentacin .............................................................................................. 50
4.3.3
5.
CONCLUSIONES ............................................................................................................... 64
6.
RECOMENDACIONES...................................................................................................... 66
7.
BIBLIOGRAFA .................................................................................................................. 67
8.
LINKOGRAFA ................................................................................................................... 68
9.
ANEXOS .............................................................................................................................. 70
ANEXO A: Notacin BPMN................................................................................................. 70
ANEXO B: Proceso de Compra del HBPM:.................................................................... 71
ANEXO C: Informacin Procesada del Insumo Povidona: ...................................... 72
ANEXO D: Comparativa Situacin Actual y Situaciones Propuestas: ................... 73
VII
NDICE DE TABLAS
Pgina
32
34
38
38
39
40
41
42
Tabla 4.9: Caso de Uso Elaboracin del Presupuesto del Plan Anual de Compras
42
45
46
46
47
47
48
48
49
59
59
60
60
VIII
NDICE DE FIGURAS
Pgina
Figura 1.1
Figura 2.1
Figura 2.2
15
Figura 2.3
16
Figura 3.1
21
Figura 4.1
32
Figura 4.2
33
Figura 4.3
35
Figura 4.4
35
Figura 4.5
37
Figura 4.6
37
Figura 4.7
37
Figura 4.8
41
Figura 4.9
41
Figura 4.10
44
Figura 4.11
44
Figura 4.12
45
Figura 4.13
45
Figura 4.14
54
Figura 4.15
61
Figura 4.16
63
1. ANTECEDENTES GENERALES
1.1
Introduccin
El sistema de salud chileno ha experimentado grandes reformas en el ltimo tiempo, en lo que respecta a
los procesos involucrados en la gestin y la toma de decisiones. Estos cambios tienen por objeto la
mejora continua del servicio de salud brindado a la comunidad, buscando alcanzar niveles de servicio
ms altos, sumando la complejidad no menor de desarrollar redes que permitan aumentar la cobertura
para poder llegar cada vez a una mayor poblacin. El Hospital Base de Puerto Montt no es la excepcin.
La historia del Hospital Base de Puerto Montt (de aqu en adelante HBPM) se remonta al ao 1972, y
desde entonces ha funcionado ininterrumpidamente hasta la actualidad, creciendo paulatinamente para
mejorar su nivel de servicio y se encuentra prximo a trasladarse a sus nuevas y modernas
dependencias. Como es de suponer, un hospital de esta envergadura cuenta con una gran cantidad de
subdivisiones, lo que incrementa el nivel de complejidad de la red en s, abriendo la brecha para la
aparicin de efectos indeseados que se deben corregir.
Es imprescindible que los sistemas hospitalarios avancen hacia una gestin integrada, donde la gestin
administrativa y mdica funcione en conjunto de manera sistemtica y eficiente, logrando de esta manera
cumplir con las metas de una manera eficaz en base a una gestin por procesos. sta visin hace que la
gestin de los hospitales sea algo sumamente importante, donde se pase de tomar decisiones basadas
en la experiencia, a tomar decisiones sujetas a criterios y normas establecidos basadas en la informacin,
para de esta manera poder asegurar que stas cumplen de manera eficiente con los objetivos del
Hospital.
Los principales egresos que tiene el Hospital Base de Puerto Montt son los que involucran el
aprovisionamiento de insumos, siendo los encargados de esto las unidades de Abastecimiento, Farmacia
y Bodega (de aqu en adelante AFyB). Estas unidades realizan principalmente la compra de insumos, el
anlisis de requerimientos y el manejo de inventarios respectivamente, por lo cual su trabajo es
fundamental en lo que respecta al manejo presupuestario del HBPM, donde actualmente existen
discordancias entre el sistema de registros y las existencias reales, que derivan en la prdida de
mercaderas, sobre stock, vencimiento de medicamentos y diversos tipos de mermas. En este mbito,
este trabajo realiza un estudio con el fin de proponer un modelo que ayude a la toma de decisiones en la
gestin de compras y el control de inventarios. Para lograr dicho objetivo se agruparn un conjunto de
herramientas que permitirn dar una solucin integral al problema planteado, a travs de un modelo que
aporte con un marco sistemtico en el cual fundamentar las decisiones.
1.2
1.2.1
Objetivo General
Disear, elaborar y proponer una mejora al sistema de informacin del HBPM que permita a travs de un
sistema informtico realizar la gestin de compras y el control de inventarios, mediante el levantamiento
de informacin y el anlisis de los requerimientos en el rea de AFyB.
1.2.2
Objetivos Especficos
i.
ii.
iii.
iv.
v.
Proponer un modelo que considere el consumo de medicamentos y los diversos insumos para
realizar proyecciones de compra.
1.3
Descripcin de la Organizacin
1.3.1
Servicio de Salud del Reloncav consiste en un conjunto de centros asistenciales que abarcan las
provincias de Llanquihue y Palena. El Servicio de Salud es el encargado de la organizacin, planificacin,
coordinacin y control de los establecimientos asistenciales a su cargo, en cumplimiento con las normas
establecidas por el ministerio de salud (Servicio de Salud del Reloncav. 2013).
2
La red de salud del Servicio de Salud del Reloncav conforma una superficie de 30.178 km , hacindolo el
ms extenso de la regin. sta red est conformada por todos los establecimientos de salud pblica de
dichas provincias, los cuales son coordinados para poder dar solucin a los problemas de salud de sus
beneficiarios.
El servicio de salud cuenta con diversos tipos de establecimientos para distintos tipos de necesidades:
Nivel primario: abarca los CES (Centros de Salud) CESFAM (centros de salud familiar), CECOSF
(Centros Comunitarios de Salud Familiar), SAPUS (Servicios de Atencin Primaria de Urgencia),
Centros de Salud Rural y Postas de Salud Rural.
Nivel Secundario: Este nivel corresponde a las especialidades (UCAE: Unidad Consultorio Adosado
de Especialidades), que se ubica en el Hospital Base de Puerto Montt. Por otro lado tambin existen
consultoras de especialidades en hospitales de menor complejidad, los cuales son mdicos que
salen a comunas a atender a otros pacientes que as lo requieran, especialmente en las reas de
ginecologa y obstetricia, cardiovascular, broncopulmonar y psiquiatra.
Nivel terciario: a este nivel corresponden las hospitalizaciones, que pueden ser en establecimientos
hospitalarios en sus diferentes complejidades (alta, mediana y baja complejidad).
Suprared: Son los establecimientos asistenciales en otras regiones del pas donde son derivados
los pacientes para completar los estudios de diagnstico y tratamiento en hospitales de Valdivia,
Temuco, Concepcin y Santiago.
1.3.2
Tipos de Hospitales
Los hospitales de baja complejidad (Servicio de Salud del Maule. 2009) corresponden a
establecimientos orientados hacia la familia y la comunidad, y son responsables de la provisin de
cuidados bsicos en salud para su poblacin beneficiaria, mediante actividades de promocin,
enfermedad.
Los hospitales de mediana complejidad (Servicio de Salud del Maule. 2009) son establecimientos
de salud responsable de la provisin de atenciones mdicas generales y de especialidad y cuidados
de enfermera a su poblacin beneficiaria y desarrolla actividades integrales de promocin,
prevencin, curacin, rehabilitacin y cuidados paliativos, a lo largo del proceso salud - enfermedad
y ciclo vital de las personas.
Los hospitales de alta complejidad (Servicio de Salud del Maule. 2009) son establecimientos de
salud responsables de la provisin de atenciones mdicas y cuidados de enfermera bsicos,
intermedios e intensivos a su poblacin beneficiaria y desarrolla para ello, actividades integrales de
promocin, prevencin, curacin, rehabilitacin y cuidados paliativos, a lo largo del proceso saludenfermedad y ciclo vital de las personas.
1.3.3
El HBPM es el establecimiento de mayor complejidad del Servicio de Salud Del Reloncav (Servicio de
2
Salud Del Reloncav. 2013). Este cuenta con una infraestructura de aproximadamente 26.000 [m ] lo cual
le permite tener una dotacin de 418 camas. Atiende a los beneficiarios del sistema pblico de salud de
las provincias de Llanquihue y Palena, as como a los que son derivados de la Macro - Red provenientes
de la provincia de Chilo y de la XI y XII regiones. En l trabajan cerca de 1.500 funcionarios. Este
hospital alberga unidades de gran demanda y complejidad tecnolgica como: Unidad de Emergencia,
Pabelln Central, Unidades de Cuidado Intensivo, Neonatologa, Partos y Esterilizacin. Su mayor
desarrollo es en el rea Neuroquirrgica, y tambin cuenta con fuertes avances en la integracin con
Universidades y Centros de Estudios Superiores, con el fin de transformarse en el corto plazo en un
establecimiento docente asistencial (HBPM. 2013), que cuente con los recursos humanos y tecnologas
para cumplir las complejas necesidades de salud de sus beneficiarios.
El HBPM se encuentra cercano a trasladarse a sus nuevas dependencias, las cuales cuentan con una
superficie de 111.394 m2, lo cual se estima beneficiar a una poblacin aproximada de 500 mil personas.
Estas dependencias constarn adems de 15 pabellones (actualmente 7) y 107 camas adicionales
(Servicio de Salud Del Reloncav. 2013).
1.3.4
1.3.5
Ser un complejo hospitalario, docente asistencial, autogestionado en red, que cuente con los recursos
necesarios para dar respuesta oportuna a las necesidades de salud de nuestra poblacin, con especial
nfasis en la atencin ambulatoria y la especialidad Neuroquirrgica (HBPM 2013)
1.3.6
1.3.7
Centro de Responsabilidad
dirigidas por un responsable al cual se le ha delegado un determinado nivel de decisin sobre el uso de
recursos para el logro de los objetivos del Centro de Responsabilidad, los cuales agrupan una serie de
centros de costo, acorde a similitudes en relacin a clientes, procesos clnicos, productos intermedios y
finales, lo cual da como resultado 16 centros de responsabilidad dentro del HBPM.
1.3.8
1.4
Para poder llevar a cabo dicha intervencin, se proceder en primera instancia a la recopilacin de
informacin, a travs de documentos, trato directo con el personal y herramientas como encuestas, con el
fin de acotar el problema y establecer con mayor detalle el rea y el enfoque que se le dar a la
investigacin. Posteriormente, teniendo claros los requerimientos, se procesar la informacin para poder
realizar un diagnstico que indique ms claramente las fortalezas y debilidades del sistema informtico y
de los procesos que se llevan a cabo en l, para finalmente realizar una propuesta que pueda ayudar a
solucionar ya sea total o parcialmente los problemas asociados a la gestin de compras y el control de
inventarios del rea de AFyB del HBPM.
Al concluir este estudio, se desea realizar una propuesta que logre mejoras al modelo utilizado por el
HBPM, de tal manera de impulsar avances en materia de reduccin de costos y tiempos, con lo cual se
espera contribuir de manera positiva al hospital regional, aminorando la carga laboral de los funcionarios,
normalizando los procesos, y estableciendo los parmetros que podran significar la renovacin de su
sistema informtico, lo cual se espera que a su vez aumente la productividad y mejore el desempeo
general del HBPM.
1.5
Supuestos y Restricciones
La solucin al problema propuesto est sujeta a una serie de condiciones, las cuales deben de ser
cumplidas para que el modelo sea til. Dichas condiciones son las siguientes:
El presente trabajo considera el levantamiento de los procesos que se ejecutan dentro del HBPM,
los que no son necesariamente los mismos para otro tipo de hospitales.
Al tratarse del diseo de un modelo, a este nivel de detalle no se consideran las limitantes legales
para integrar los procesos ni los sistemas analizados, lo cual si puede resultar interesante a un
nivel de trabajo ms especfico.
El HBPM utiliza un modelo de inventario que se asemeja ms al de periodo fijo, sin embargo, no
resulta ser tan estricto en ese sentido, por lo que da pie a realizar las modificaciones propuestas.
2. MARCO TERICO
2.1 Modelo
Un modelo es bsicamente una abstraccin de la realidad que busca dar una explicacin a los escenarios
complejos dentro de una organizacin. La RAE (2013) lo define como un esquema terico, generalmente
en forma matemtica de un sistema o una realidad compleja, que se elabora para facilitar su comprensin
y el estudio de su comportamiento. Otros autores sealan que es una representacin abstracta de
fenmenos, sistemas o procesos con el fin de predecirlos. En ambos casos se coincide en que es una
abstraccin de la realidad para posteriormente comprenderla mejor.
Las principales utilidades de un modelo o del modelamiento son reducir la complejidad y hacer
predicciones, lo cual ayuda de manera significativa a realizar la gestin dentro de las organizaciones,
aunque esto no garantiza el xito de ella. Los modelos deben ser validados a travs de los resultados
para corregir las desviaciones, realizando ajustes que lo adapten mejor a la realidad.
Elaboracin del
modelo
Retroalimentacin
activa
Organizacin de la
informacin
Anlisis de
informacin
Observacin y
medicin
categoras: planeacin, organizacin, direccin y control. Todas y cada una de ellas son fundamentales
para poder cumplir con los objetivos de la empresa, a travs de la gestin. Por lo tanto, se entender
como gestin como conducir a la empresa hacia los objetivos dentro de un tiempo determinado,
planificando las actividades, organizando los recursos para realizarlas dirigiendo a las personas y
controlando que los objetivos se cumplan para, de ser necesario, realizar las correcciones pertinentes.
2.2.1
Inventarios
Los inventarios son la cantidad de bienes o activos fijos (muebles o inmuebles) que una empresa
mantiene en sus existencias en un momento determinado en espera de ser vendidos o utilizados en el
proceso productivo. Otra definicin sugiere que es todo el dinero que el sistema invierte en la compra de
cosas que el sistema pretende vender (Goldratt 1994) y algunos autores lo definen de manera ms
simple como las existencias de una pieza o recurso utilizado en una organizacin (Chase 2009), vale
decir que se trata de un bien que la empresa pretende utilizar.
Las razones por las cuales las empresas mantienen inventarios estn relacionadas principalmente por la
reduccin de costos, los cuales pueden ser de diversa ndole, segn Chase, los costos asociados al
inventario son los siguientes:
Costos de configuracin: Estos costos estn asociados a los cambios que se deben de realizar en
la configuracin de equipos, papeleo y material al cambiar de un producto a otro.
Costos de pedidos: Son los costos administrativos que implican el preparar la orden de compra o
produccin.
Costos de faltantes: El costo de faltantes es el que se produce al haber un quiebre de stock, lo que
genera cancelacin de rdenes o esperas por falta de materia prima.
Materiales y suministros: Son los elementos que participan en la elaboracin del bien pero que no
forman parte de ste (herramientas).
10
Que aporte valor o genere ahorros: El indicador debe servir para mejorar el desempeo de la
organizacin.
100%
100%
Entregas correctas: Una entrega puede estar a tiempo pero no necesariamente estar
completas, por lo cual se utiliza este indicador para llevar un control ms minucioso. Se define
como:
100%
11
Atrasos: En el caso del control de atraso, tambin se establece para tener un control de los
proveedores, y corresponde a:
100%
100%
2.3 Sistema
Una de las definiciones ms claras de lo que es un sistema es la aportada por la teora de sistemas
misma, la cual dice que es un complejo de componentes que interactan (Bertalanffy. 1969), sin
embargo es necesario agregar que dicha interaccin se realiza para lograr un fin determinado, como bien
lo describe la RAE (2013) conjunto de cosas que relacionadas entre s ordenadamente contribuyen a
determinado objeto. Los sistemas pueden ser de carcter fsico (como el sistema solar) o abstracto (un
software) y pueden existir dentro de otros sistemas. Los sistemas tienen fronteras que lo diferencian del
ambiente, no obstante, dependiendo de la relacin que tengan con su entorno pueden ser de carcter
abierto (existe relacin con el entorno) o cerrado (no existe relacin con el entorno).
2.3.1
Un sistema de gestin informtico es un sistema que permite realizar la gestin a travs de una
plataforma informtica. Dicho de otra manera, es un conjunto de partes interrelacionadas con el fin de
cumplir los objetivos especificados, facilitando la planeacin, organizacin, direccin y control de la
12
organizacin a travs de una plataforma informtica. Dichas caractersticas sugieren un sistema que
pueda responder a las preguntas cuya respuesta requiera de la utilizacin de un procedimiento para la
toma de decisiones (Goldratt 1994). Est compuesto por el hardware (o sistema fsico), el software (o
sistema lgico) y los usuarios que lo utilizan. Su principal objetivo es el procesamiento de datos, para as
transformarlos en informacin til que ayude a la organizacin en toma de decisiones.
2.4.1
Modelamiento de procesos
Para poder llevar a cabo una gestin por procesos se hace necesario un conocimiento de ellos, para lo
cual se utiliza el modelamiento de procesos. Dicho modelamiento de procesos busca establecer de
manera ms sencilla la forma en que cada uno de los procesos debe de ser realizado. El modelamiento
de procesos se realiza generalmente a travs de un anlisis, para posteriormente efectuar una
representacin grfica que facilite su comprensin. Para este efecto existen herramientas que permiten
llevar a cabo un modelado a travs de un lenguaje estndar, como lo es la Notacin y Modelo de
Procesos de Negocio (BPMN: Business Process Model and Notation). La principal ventaja del uso de este
lenguaje radica en su carcter de estndar, lo que facilita su entendimiento.
13
monetario, riesgo o aportacin a las utilidades. El inconveniente que tiene la categorizacin ABC es que
es una evaluacin monocriterio, por lo que por s sola no representa una solucin completa a
determinado problema, lo que hace necesario que se utilice en conjunto con otras herramientas que
permitan una solucin ms integral.
Tipo A: Son los artculos que tienen un mayor valor y que requieren un mayor control. Generalmente
corresponden al 20 por ciento de los artculos cuyo valor se estima entre el 70 80 por ciento del
costo (Morn 2005).
Tipo B: Son artculos de menor valor y que requieren de un control normal. stos suelen representar
de un 20 al 30 por ciento de los artculos con un 15 por ciento del costo (Morn 2005).
Tipo C: Son los artculos de poco valor y que requieren de control simple, y que generalmente no
superan del 5 por ciento del costo total de los bienes pero representan un 50 por ciento de stos
(Morn 2005).
2.6 TOC
El TOC (Theory of Constraints) es un concepto que se ide para administrar ambientes industriales, con
el objetivo de aumentar las ganancias de las compaas en el corto y largo plazo (Cimatic 2001), el cual
se alcanza aumentando el throughput (ingreso de dinero a travs de las ventas) y reduciendo los
inventarios con los gastos operativos. Esto se logra mediante la previa identificacin de las restricciones
y los cuellos de botella del sistema ya que los eslabones ms dbiles y las restricciones son las que
determinan el desempeo total de la empresa (Goldratt 1994).
El TOC establece cinco etapas para el diseo de estrategias mediante un diagnstico que contempla:
1) Identificar restricciones del sistema.
2) Decidir como explotar las restricciones del sistema.
3) Subordinar el sistema a la restriccin anterior.
4) Elevar las restricciones del sistema.
5) Si con los pasos anteriores se llegase a romper una restriccin, volver al paso uno sin que la
inercia cause una restriccin al sistema.
2.6.1
Sistemas Push:
El trmino push es un vocablo ingls que significa empujar. Un sistema push trabaja con pronsticos
de venta o de consumo, donde se realiza el reaprovisionamiento basado en las necesidades
proyectadas (Ballou 2004), con lo que se busca lograr economas de escala. Bajo esta perspectiva la
produccin debe ir al ritmo del reaprovisionamiento para no colapsar la cadena productiva.
14
2.6.2
Sistemas Pull:
La palabra pull es un trmino ingls que significa jalar. Es un mtodo de manejo de inventarios basado
en la demanda, donde el pronstico de la demanda y la determinacin de las cantidades de
reaprovisionamiento se realizan tomando en consideracin las condiciones locales (Ballou 2004), por lo
que bajo esta perspectiva, lo que se busca es eliminar el sobre stock o compras innecesarias, ajustando
el abastecimiento de insumos al ritmo de la produccin, minimizando de esta manera el gasto
operacional, los inventarios y los desperdicios.
2.6.3
Enfoque DBR
El enfoque DBR (Drum Buffer Rope) es un enfoque que forma parte de la Teora de las Restricciones
(TOC), en el cual se busca conocer las restricciones del sistema o los recursos restriccin (Goldratt
1994) para as poder modelarlo y establecer polticas que ayuden al manejo de ste, a travs de una
explotacin eficiente de las limitaciones de l.
15
un cuello de botella). En consecuencia, el sistema debe adaptarse al tambor para evitar atascos que
perjudiquen su desempeo.
Rope (Cuerda): La cuerda es el elemento que une al cuello de botella con el inicio de la cadena, y
se encarga de mantener la comunicacin y el flujo de los materiales, evitando que se produzcan
materiales que no hagan falta (TEOC 2007), logrando de esta manera evitar las eficiencias locales
centrndose en la subordinacin y buscando la eficiencia global.
2.7.1
Encuesta
La encuesta es definida como el mtodo de investigacin capaz de dar respuestas a problemas tanto en
trminos descriptivos como de relacin de variables, tras la recogida de informacin sistemtica, segn
un diseo previamente establecido que asegure el rigor de la informacin obtenida"(Buenda et al, 1998),
otra definicin sugiere que la encuesta es una bsqueda sistemtica de informacin en la que el
investigador pregunta a los investigados sobre los datos que desea obtener, y posteriormente rene estos
datos individuales para obtener durante la evaluacin datos agregados.(De la Rada, 2001) . Con la unin
de ambas definiciones se puede hacer un diagrama de lo que es la encuesta:
Bsqueda de
Informacin
Diseo de la
Encuesta
Recogida de
Informacin
Dar Respuesta al
fenmeno en Estudio
No obstante, algunos autores clasifican las encuestas acorde a una serie de criterios los cuales se
muestran a continuacin (Universidad de Navarra, 2002):
a) Segn su Objetivo
16
Descriptivas: Encuesta que se realiza para definir la realidad, dando respuesta a la naturaleza del
fenmeno.
Predictivas: Las encuestas predictivas buscan como su nombre lo dice predecir el comportamiento
de las variables en estudio.
Evaluativas: Son las que buscan evaluar el grado de ejecucin, cumplimiento o satisfaccin de la
poblacin.
d) Segn su Finalidad:
Poltico Sociales: Encuestas que se realizan para evaluar el comportamiento de los individuos en
temas del mbito social y/o poltico.
Comerciales : Encuestas que se realizan para indagar acerca de las preferencias comerciales de los
encuestados.
Con Fines Especficos: Todo tipo de encuesta que no pertenezca a los grupos anteriormente
mencionados.
De esta forma, acorde a los criterios anteriormente expuestos, la encuesta que se emplear para la
realizacin de este estudio ser de carcter Exploratorio, Personal, Transversal y con Fines Especficos.
Esto quiere decir que se aplicar para realizar una primera aproximacin al fenmeno en estudio, referida
a las opiniones personales de los encuestados, realizada va web, transversal para conocer el estado de
las variables en un momento dado y con fines especiales dado que se har un estudio dentro de una
institucin pblica para recopilar informacin de carcter administrativo.
17
2.7.2
Entrevista
La RAE (2013) define la entrevista como vista, concurrencia y conferencia de dos o ms personas en
lugar determinado, para tratar o resolver un negocio, otros autores la definen como reunin o encuentro
formal que puede tener propsitos especficos, sin embargo una definicin que se asemeja ms al
objetivo de este trabajo de titulacin es un intercambio directo entre un analista y un componente de la
organizacin con el fin de recopilar informacin acerca de un tema en particular. La entrevista puede ser
aplicada a todo nivel dentro de la empresa, lo que posibilita la obtencin de informacin de diversa ndole.
2.7.3
Muestreo
El muestreo es la seleccin de una pequea parte estadsticamente determinada, utilizada para inferir el
valor de una o varias caractersticas del conjunto (RAE 2013). Estos se efectan para realizar estudios de
una poblacin a travs de muestras que resultan ms fciles y econmicas de medir.
El muestreo de una poblacin puede realizarse de diversas maneras, las cuales se exponen a
continuacin:
Muestreo Dirigido: El muestreo dirigido es aquel en que los elementos de la muestra son
seleccionados por decisin personal, y generalmente se utiliza en encuestas exploratorias.
Muestreo Sistemtico: Los elementos son seleccionados de una manera ordenada (sin embargo
dicho orden es al azar). Cada elemento se selecciona en funcin del nmero deseado de la muestra.
Muestreo Aleatorio Simple: Es un tipo de muestreo en el cual cada elemento tiene la misma
probabilidad de ser seleccionado, con lo cual se obtiene una muestra objetiva cuyo error muestral
puede ser medido.
Muestreo Aleatorio Mltiple: Este tipo de muestreo selecciona una muestra inicial pequea, pero
en caso de que los resultados del estudio no sean consistentes se incluyen mas casos a la muestra
y se repiten los anlisis.
Muestreo Aleatorio Estratificado: Este tipo de muestreo se utiliza cuando hay sospechas de que la
poblacin a estudiar es de carcter heterogneo, por lo cual se divide en estratos y se seleccionan
los elementos de manera sistemtica en cada estrato.
Muestreo por Clsters: En este muestreo la poblacin se divide en clsters o grupos, para luego
seleccionar parte de los grupos para realizar el anlisis.
18
2.7.4
2.7.5
El modelo de casos de uso es una herramienta de modelado UML que se centra en describir como
alcanzar una nica meta de negocio (Junta de Andaluca. 2013) y documentan el comportamiento de
un sistema desde el punto de vista del usuario (Cceres 2006), por lo tanto, describe una caracterstica
del sistema relacionada con las funciones que ste puede realizar. Entre las caractersticas que debe
poseer un caso de uso estn:
i.
Describir una tarea de negocio que sirva para las metas de ste.
ii.
iii.
Ser bastante sencillo como para que un desarrollador lo elabore en un solo lanzamiento.
Actor: Un actor es un algo o alguien que puede interaccionar con el sistema que se est
desarrollando(Mora 2002), vale decir, es un rol que realiza una labor frente al sistema y no un ente
en particular, por lo que no necesariamente tiene que ser una persona, tambin puede serlo un
sistema informtico o algn agente externo que interacte con el sistema.
Caso de Uso: Es una descripcin de un conjunto de secuencias de acciones que un sistema ejecuta
y que produce resultado observable de inters para un actor en particular. Son los requisitos
funcionales que indican qu es lo que har el sistema.
Tipo de Relacin (Document Information Retrieval Systems 2013) El tipo de relacin indica el
comportamiento que existe entre casos de uso, o entre los actores del sistema:
i.
Asociacin: Este tipo de relacin indica la invocacin de un actor o caso de uso a otra
operacin.
ii.
Dependencia: Este tipo de relacin se utiliza para cuando una clase depende de otra.
iii.
Generalizacin: Este tipo de relacin es exclusiva de los casos de uso, donde pueden
ser de tipo Extends, cuando se quiere especificar ciertas variantes de un caso de uso lo
que conlleva que el comportamiento de dicho caso de uso ser diferente, o de tipo
19
Dentro del presente trabajo de ttulo se utilizar el modelo de casos de uso para poder sealar las
responsabilidades que tendr el sistema en cuanto a su funcionalidad. stos describirn que es lo que el
sistema debe hacer, pero no especifican necesariamente el cmo.
2.7.6
Segn Cceres (2006), los casos de usos pueden describirse de la siguiente forma:
Descripcin: La descripcin contempla un breve resumen del caso de uso, donde se menciona lo
que debe hacer dicho caso de uso.
Pre Condicin: La Pre- Condicin indica lo que debe cumplirse previamente antes de iniciar el
caso de uso, por lo cual, dicha condicin se asume como verdadera al momento de comenzar el
caso de uso.
Post Condicin: La Post Condicin indica lo que debe suceder una vez finalizado el caso de
uso, por lo cual el caso de uso se considera realizado satisfactoriamente una vez que dicha
condicin es cumplida.
Flujo Principal: El flujo principal es la secuencia que sigue el caso de uso al realizarse de manera
normal, de esta manera, es la secuencia que ms se repite al momento de realizar un determinado
caso de uso.
Flujo(s)
desviaciones dentro del sistema, lo cual hace que tenga que efectuarse un tratamiento particular
dados los escenarios que se puedan dar en un determinado caso de uso. Estos flujos debieran
satisfacer el resto de posibilidades tanto de xito como de fracaso del caso de uso, aunque en
ocasiones puede que el cumplimiento del caso de uso este ligado a requisitos de carcter no
funcional, lo cual debe registrarse en las observaciones.
Observaciones : Las observaciones es el espacio donde se especifica todo lo que no tiene que ver
directamente en el caso de uso pero que puede afectar su funcionamiento, como los requisitos no
funcionales que pueden ser necesarios en determinados casos.
A mediados del ao 2006, el Hospital Escuela de Burlington, Massachusetts, decidieron que deban
eliminar la burocracia al hacer pedidos y almacenar, y empezar a ahorrar a travs de la cadena de
suministro (Chase 2009). Tras dicho estudio, se generaron una serie de modificaciones que finalmente
20
Una vez que se encuentre clarificada la realidad del HBPM, se requiere establecer cules sern los
cambios que se requieren para mejorar el desempeo. Primero que todo se espera realizar cambios en la
estructura o la forma en la cual se realizan los distintos procesos llevados a cabo dentro del HBPM. Es
aqu donde se plantea el uso de los modelos de Casos de Uso basados en UML y el modelamiento de
procesos a travs de BPMN los cuales muestran de manera esquemtica la estructura en la que se
sustenta cada uno de los procesos, brindando de esta manera los cimientos sobre los cuales se
construir la propuesta de mejora para el modelo de gestin de compras y control de inventarios del
HBPM.
21
3. DISEO METODOLGICO
La metodologa que se implement se basa bsicamente en 2 principios:
1. Requerimientos establecidos por el hospital.
2. Disponibilidad de recursos disponibles.
En la primera parte, el objetivo que persegua el HBPM era cambiar el sistema informtico que utilizaban
(Orden), por uno que se apegue ms a las necesidades que tenan. En este mbito se requera un
sistema que se apegue al nuevo modelo de abastecimiento que se deseaba implementar para el nuevo
HBPM. Este modelo implicaba una serie de cambios a los cuales el HBPM deba adaptarse, por lo que
fue indispensable realizar las correcciones al flujo de trabajo que se realizaba. De esta manera, se
requera un modelo que:
Reduzca tiempos.
Mejore la planeacin.
Por otro lado, la disponibilidad de recursos estuvo asociada al tiempo con que se contaba para obtener
informacin del personal, dado que los servicios de AFyB tienen una alta demanda diaria, a lo cual se le
suma el hecho de que los funcionarios participan regularmente en distintos tipos de capacitaciones, por
lo que se establecieron visitas regularmente a los departamentos mencionados previo acuerdo con los
funcionarios, de tal forma de aprovechar mejor el tiempo, evitar interrumpir el quehacer de ellos y de
trabajar de manera ms focalizada en los problemas analizados.
En la siguiente figura se muestra de manera esquematizada la forma mediante la cual el problema ser
abordado, la cual se desarrollar mediante 3 fases:
1. Anlisis del problema.
2. Recopilacin de informacin.
3. Elaboracin de la propuesta.
22
Anlisis
Anlisis del
Problema
Definicin del
rea de Estudio
Desarrollo de una
Propuesta de
Trabajo
Recopilacin
de
informacin
Bsqueda de
Informacin
Procesamiento de
Informacin
Desarrollo de un
Diagnostico
Elaboracin
de la
propuesta
Elaboracin de
una Propuesta
Inicial
Retroalimentacin
Elaboracin de la
Propuesta Final
3.1.1
Una vez establecidos el problema y el rea de estudio, se realiz una propuesta de trabajo, lo que
consisti en un plan de accin preliminar para sentar las bases del estudio que se iba a realizar. Dicha
propuesta se realiz ya que se necesitaba saber la manera en la cual el problema iba a ser abordado,
para as poder indicar con mayor eficacia aspectos como fuentes de informacin
informacin, procedimientos o
metodologas a emplear, etc.
23
3.3.1
Las entrevistas fueron realizadas al personal de distintos niveles dentro los departamentos de AFyB, ya
que se necesitaba conocer con mayor detalle el flujo de trabajo para as poder tener una visin global del
problema. Con estas entrevistas se busc obtener informacin acerca del funcionamiento del sistema
informtico, el manejo y seguimiento que se hace de los distintos requerimientos de los servicios del
hospital, desde el momento que surge la necesidad hasta que sta es satisfecha. Dichas entrevistas
fueron reiterativas en la medida que surgan nuevas necesidades.
3.3.2
Las reuniones realizadas con la directiva del Hospital fueron realizadas en distintas ocasiones puesto que
a la directiva le interesaba revisar los avances del proyecto para orientar el trabajo hacia las metas
propuestas del hospital. De esta forma se contaba con informacin actualizada del avance real del estado
del proyecto mientras que se corregan las desviaciones que surgan.
3.3.3
Una vez se tuvo claro los flujos de trabajo de las distintas reas, se procedi a elaborar una encuesta en
conjunto con la directiva del hospital puesto que se necesitaba conocer la apreciacin que tenan los
usuarios de los distintos atributos, funcionalidades e informes con el que contaba el sistema que
utilizaban y las expectativas que se tenan de lo que debiese ser un sistema informtico, de esta forma se
hizo a los distintos usuarios partcipes del proceso de cambio mientras que se obtena informacin valiosa
de lo que esperaban del nuevo sistema. Dicha encuesta fue realizada a los funcionarios de AFyB.
24
3.3.4
El hospital contaba con manuales de procedimientos de las unidades que lo componen, los cuales
establecan las tareas, actividades y objetivos de cada una de ellas. Estos manuales fueron revisados
puesto que se necesitaba conocer la forma en que estaban estipulados formalmente los procesos, de
esta forma se pudo saber si los resultados obtenidos de las entrevistas coincidan con lo que el hospital
estipulaba en sus manuales y posteriormente realizar las correcciones y consultas pertinentes.
Cuando se obtuvieron todos los datos de las distintas fuentes se procedi a procesarla de tal forma de
generar informacin que ayude a la toma de decisiones para enfocarlas en funcin de los distintos temas
abordados, generando de esta manera un sustento bajo el cual basar el diagnstico y la propuesta de
mejora.
Una vez realizado el diagnstico, con la informacin recopilada se realiz una propuesta inicial, la cual
consisti en la formalizacin de actores y los principales procesos llevados a cabo por ellos a travs del
modelo de casos de uso, pues se necesitaba conocer la base sobre la cual se construira el nuevo
modelo, por lo que se esquematizaron los procesos llevados a cabo a travs del sistema informtico por
los departamentos de AFyB.
3.7 Retroalimentacin
La retroalimentacin estuvo presente durante todo el proceso, ya que los distintos funcionarios
continuamente iban aportando, revisando y corrigiendo los avances, puesto que fue un trabajo realizado
25
en conjunto, de esta forma, se persegua obtener datos reales que representen fielmente la realidad del
HBPM.
Una vez que se tena toda la informacin recopilada, procesada y analizada, se hizo la entrega que
contena la propuesta final, la que corresponda a todo el proceso realizado: el levantamiento de
informacin, el establecimiento de los principales procesos, los requerimientos informticos necesarios
para el nuevo sistema y la propuesta de modelo para la gestin de compras y control de inventarios.
26
4. RESULTADOS
4.1 Anlisis
4.1.1 Anlisis del Problema:
4.1.2
El sistema informtico del Hospital Base de Puerto Montt era transversal a la organizacin, dado que era
usado por todos los servicios del hospital, ya sean estos de carcter clnico o administrativo. Sin
embargo, dado el tamao de la organizacin y en acuerdo con el HBPM, se opt por realizar un estudio a
nivel de los proveedores internos (AFyB), ya que eran ellos los principales afectados con el sistema
informtico, pues el resto de los usuarios en su calidad de clientes internos (Servicios Clnicos), utilizaban
el sistema mayoritariamente para realizar pedidos. De esta forma se redujo drsticamente la poblacin
que se tena que estudiar y se focaliz en los usuarios ms afectados por el problema.
4.1.3
La propuesta de trabajo inicial consisti en una breve presentacin en la cual se defini las posibles
formas en la cual el problema podra ser abordado y en cmo se comenzara a levantar la informacin,
esto es, el rea de estudio, fuentes de informacin y las herramientas a utilizar. En dicha propuesta se
estableci:
27
4.2.1
Bsqueda de Informacin
Entrevistas con el personal: Las entrevistas realizadas peridicamente a los distintos funcionarios
28
Bodega: Dentro del rea de bodega, se observ que el sistema informtico no le ayudaba a
realizar un control de existencias efectivo, puesto que en algunas oportunidades mostraba
inventarios que no existan o viceversa, adems de que tampoco generaba alertas ante eventuales
quiebres de stock. Tambin tenan un problema de espacio, ya que los pasillos siempre tenan
mercadera que no entraba en las respectivas bodegas y cierto desorden en la recepcin de
pedidos, derivado del mal manejo de las solicitudes de insumos y la descoordinacin entre
departamentos generadas por el sistema informtico y un flujo de proceso que no estaba
claramente establecido.
Reuniones con la Directiva: Las reuniones con la directiva fueron de carcter orientativo, las
cuales establecieron las directrices del trabajo que se deba realizar, estableciendo los alcances de
la investigacin, con lo cual se logr acotar el problema al rea de AFyB, apuntando principalmente
a analizar el sistema informtico y los procesos que se llevaban a cabo en l, para lo cual se elabor
una encuesta y se estableci analizar el sistema informtico a travs de un modelo de Casos de
Uso.
Encuesta: La encuesta que fue realizada en el HBPM se desarroll en conjunto con las jefaturas de
cada rea y la directiva del hospital, con el fin de conocer la percepcin que los usuarios tenan del
sistema informtico, evaluando sus distintas capacidades y deficiencias, as como para conocer las
expectativas de los usuarios ante la implementacin de un nuevo sistema informtico, lo cual se
esperaba utilizar en un eventual proceso de licitacin posterior. La encuesta fue de carcter
exploratorio con un muestreo dirigido y fue difundida por separado a quienes fueron considerados
como clientes internos (servicios clnicos) y los proveedores internos (AFyB). sta fue enviada va
correo electrnico por medio de la Subdireccin Administrativa del hospital con su debida
presentacin, objetivos, glosario y las preguntas hacia ambos grupos de encuestados. El grupo de
clientes internos compuesto por los servicios clnicos mostr un nulo inters, ya que slo siete
personas de los ms de 300 funcionarios respondieron la encuesta, por lo que se acord en conjunto
29
con la directiva del hospital descartar ese grupo, el cual fue considerado por parte de ellos como
secundario, ya que slo utilizan el sistema para revisar inventarios y solicitar insumos. El segundo
grupo compuesto por los funcionarios de AFyB respondi en su totalidad, por lo cual se trabajaron
con los resultados de dicho grupo ya que ellos son los principales afectados y los que ms utilizan el
sistema informtico.
4.2.2
Procesamiento de Informacin
La informacin recopilada de las distintas fuentes fue analizada y procesada de tal forma de elaborar un
diagnstico de la situacin en la cual se encontraba el departamento de AFyB en relacin a la gestin de
compras y el control de inventarios a travs de su sistema informtico, el cual se detalla a continuacin.
4.2.3
Diagnstico:
Procesos:
Los procesos llevados a cabo dentro del sistema informtico eran diversos, los cuales variaban en
funcin de los distintos departamentos. El sistema completo estaba sustentado en un proceso bsico el
cual era la solicitud de insumos. Dentro de este proceso de solicitud de insumos, se encontraban los
Centros de Costo, los que iniciaban el proceso de solicitud enviando los requerimientos al respectivo
encargado del Centro de Responsabilidad, para ser aprobado (o eventualmente rechazado). Luego este
requerimiento, en caso de ser aprobado, era enviado al departamento de Abastecimiento, el cual
verificaba las existencias de bodega. En caso de que existan los medios para satisfacer dicho
requerimiento en bodega, se le comunicaba a dicho departamento para que despache los insumos
30
necesarios y en caso contrario se iniciaba el proceso de compra para adquirir los bienes solicitados.
(Para mayor detalle revisar el Anexo B: Proceso de compra del HBPM).
El proceso de solicitud de insumos se encontraba correctamente definido en cuanto a los pasos
necesarios para completarlo satisfactoriamente, pero el problema era uno asociado a la forma en la cual
dicho proceso se ejecutaba. El proceso anteriormente descrito se realizaba de manera ms o menos
regular, pero con diversos matices dependiendo de la persona o el departamento que las ejecutaba, lo
cual claramente representaba una dificultad cuando el hospital buscaba establecer sus procesos
administrativos de forma estandarizada.
Utilizando el enfoque DBR, se puede establecer que para el proceso de compra de insumos, el tambor
(drum) era el departamento de Abastecimiento, que revisaba y consolidaba las solicitudes para
posteriormente solicitar el despacho o realizar las compras. Abastecimiento pasaba a ser el cuello de
botella ya que en este departamento las compras se filtraban para ser finalmente ejecutadas o
rechazadas. El colchn (buffer) resulta ser el departamento de Bodega, el cual mantena los stocks de los
insumos y medicamentos para su posterior distribucin, y la cuerda (rope) el sistema informtico, el cual
manejaba la informacin que era vista por los distintos usuarios del sistema.
Comunicaciones:
Los departamentos de AFyB no siempre trabajaban de manera ordenada y coordinada, puesto que el
sistema de comunicacin que utilizaban no era un sistema integrado, sino mas bien se utilizaban los
correos electrnicos y las llamadas telefnicas, lo cual es usual en todo tipo de organizaciones, pero que
dada la cantidad de pedidos y solicitudes que se generaban diariamente tanto de clientes como
proveedores, se haca difcil el manejo de tanta informacin para los funcionarios, por lo que no era
inusual que el ente solicitante tenga que insistir varias veces por diversos medios para poder ingresar su
solicitud. Por otro lado, algunos departamentos trabajan con otros sistemas informticos con fines ms
especficos, que muchas veces utilizan informacin comn pero que no se encuentran integrados, esto
generaba problemas en cuanto a la actualizacin de la informacin, ya que deba hacerse de manera
manual. En la encuesta realizada, se consult si funcionaba correctamente la comunicacin entre los
distintos usuarios y departamentos a travs del sistema informtico, lo cual mostr los siguientes
resultados:
31
15%
15%
15%
0%
Totalmente en
desacuerdo
En desacuerdo
Ni de acuerdo ni
en desacuerdo
De acuerdo
Totalmente de
acuerdo
Tal y como se puede apreciar, la percepcin de comunicacin a travs del sistema informtico en general
era mala. Ninguno de los encuestados declar estar totalmente de acuerdo en que el sistema informtico
contribua a mejorar la comunicacin, mas bien, la dificultaba al no tener bien implementados los distintos
procesos que se ejecutan en l, haciendo que los usuarios realicen las mismas tareas en reiteradas
ocasiones, malgastando tiempo y recursos en ello. En otra pregunta donde se pregunt qu beneficios
considera ms importantes dentro de un sistema informtico en una escala de 1 a 6, dentro de las
respuestas posibles, la que obtuvo resultados ms altos fue la mejora en la comunicacin ya sea entre
departamentos o dentro del mismo departamento, demostrando que los usuarios necesitan un sistema
que mejore la comunicacin entre ellos.
4,9
4,6
4,1
3
2,7
1,9
32
Sistema Informtico:
En cuanto a los atributos del sistema informtico, se incluyeron una serie de atributos a evaluar dentro de
la encuesta a los usuarios, lo que arroj resultados no muy favorables, puesto que de una escala de 1 a
8, siendo uno la nota mnima y ocho la mxima, el atributo ms valorado fue Funcionalidad con slo un
3.05, ni siquiera por sobre la media. La siguiente tabla y grfico muestran la evaluacin de todos los
atributos consultados:
Atributos valorados
Rapidez
4
Integracin
Interfaz
2
1
Funcionalidad
Fuentes de
informacin
Soporte
Flexibilidad
Es intuitivo
33
No contaba con perfiles de usuario: Todos los usuarios tenan acceso a casi la misma informacin.
Por otro lado se les consult a los encuestados acerca de qu atributo consideran que debiese mejorar:
Tabla 4.2: Ponderacin atributos a mejorar del sistema Orden
1.2.3.4.5.6.7.8.-
Soporte
Integracin
Es intuitivo
Flexibilidad
Funcionalidad
Fuentes de informacin
Interfaz
Rapidez
En primer lugar se ubic el soporte, el cual segn fue indicado por los encuestados, era realizado por tan
slo una persona, y en caso de que esta no se encuentre, se vean en graves dificultades para poder
restablecer los sistemas. Esto fue un hecho realmente preocupante pues el soporte de un sistema
informtico que alimenta a una organizacin tan grande e importante como lo es el HBPM no puede estar
a cargo de tan solo una persona.
En segundo lugar se encontr la integracin, lo cual hace alusin a la comunicacin que es tan necesaria
dentro de esta organizacin y que fue sealada con anterioridad.
En cuanto al desempeo del sistema informtico, se poda ver claramente que no era el esperado, sin
embargo se les consult a los usuarios respecto a la opinin que tenan acerca de l:
34
23,80%
14,30%
4,80%
0%
Psimo
Malo
Regular
Bueno
Excelente
Tal como se pudo apreciar, las opiniones de los usuarios indicaban que el sistema informtico utilizado
era entre regular y malo, debido principalmente a los problemas mencionados de Funcionalidad, Soporte,
Integracin y Seguridad.
Finalmente en este apartado se ahond ms dentro del sistema, consultando a los usuarios acerca del
sistema de reportes con el que cuenta, para lo cual se les pregunt si el sistema de reportes daba cuenta
a sus necesidades:
Adaptacin a necesidades
Porcentaje de Usuarios
47,60%
23,80%
19%
9,50%
0%
Totalmente en
desacuerdo
En desacuerdo Ni de acuerdo ni
en desacuerdo
De acuerdo
Totalmente de
acuerdo
35
En esta respuesta el sistema de reportes result ser mayoritariamente malo, lo cual se pudo corroborar al
ver que los informes presentaban informacin imprecisa (no siempre se encontraba actualizada),
informacin adicional que no era til as como informacin necesaria que no apareca. Ejemplos de
reportes con dichas falencias se muestran a continuacin:
Por otro lado los usuarios hicieron ver una gran cantidad de reportes que decan necesitar pero que no se
encontraban implementados dentro del sistema, como lo son:
Reporte de vencimientos.
Historial de acceso.
Esto hizo ver la necesidad de realizar una reestructuracin en lo que a informes se refiere, ya que era esa
la informacin en que los usuarios se basaban mayormente para realizar la toma de decisiones.
4.3 Elaboracin de la Propuesta
4.3.1
Primero que todo, dada la necesidad de conocer las interacciones que los distintos usuarios tienen con el
sistema informtico, la primera parte de la solucin a implementar consisti en la elaboracin de un
modelo de Casos de Uso. Estos Casos de Uso fueron realizados de manera independiente partiendo por
el departamento de Farmacia (en base al flujo normal), que es donde parte el ciclo de pedido, luego
Abastecimiento y finalizando con Bodega con el cual termina el ciclo realizando la entrega de cada uno
de los pedidos a los distintos servicios clnicos.
Para la realizacin de los casos de uso primero se identificaron los actores involucrados, para
posteriormente identificar los principales casos de uso de cada uno de ellos, y finalmente se realiz la
descripcin en detalle de los Casos de Uso en conjunto con los propios usuarios del sistema informtico
dentro del rea de AFyB para que ste se apegue de mejor manera a la realidad del HBPM, mostrando
de manera precisa cada uno de los procesos de las distintas reas y como stos debiesen ser
36
implementados dentro de un nuevo sistema informtico, para posteriormente continuar con el desarrollo
del modelo de Gestin de Compras y Control de Inventarios.
Abastecimiento:
37
Actores
Descripcin
Jefe de Abastecimiento.
Una vez al ao se realiza el plan anual de compras para planear las compras
del hospital para el ao siguiente.
Pre Condicin
Post Condicin
Flujo Normal
Observaciones
Como bien se seal, este proceso era realizado una vez al ao, donde se ingresaban al sistema los
requerimientos estimados de todos y cada uno de los Centros de Responsabilidad del HBPM. En este
proceso se cambi el enfoque bajo el cual era realizado, ya que anteriormente era realizado ntegramente
por una comisin. Bajo este enfoque, se busc que cada Centro de Responsabilidad realice su
planeacin anual en funcin de sus necesidades proyectadas, se carguen al sistema y que la comisin
solo evale y realice las correcciones pertinentes a cada uno de ellos, de esta manera poder ahorrar
tiempo y tener una mayor exactitud a la hora de proyectar las necesidades anuales. Adems el hecho de
que se encuentren en el sistema precargadas ayudara a realizar un seguimiento y a mejorar el control
por parte de la directiva.
Descripcin
Compra de Insumos.
Jefe de Abastecimiento.
Unidades Compradoras.
38
Pre Condicin
Post Condicin
Flujo Normal
Flujo Alternativo
Compra Directa:
En lo que respecta a la compra de insumos el proceso slo fue esquematizado, ya que no presentaba
variantes.
Descripcin
Consolidar Pedidos.
Jefe de Abastecimiento.
Unidades Compradoras.
Pre Condicin
Post Condicin
Flujo Normal
Flujo Alternativo
Pedido Rechazado:
Se rechaza el pedido.
39
Observaciones
En el caso de la consolidacin de pedidos, se propuso que tambin sea realizado va sistema, ya que con
los cambios que se sugieren, la aprobacin o rechazo de solicitudes de insumos se hara va sistema, y
los pedidos estaran validados electrnicamente, con lo que se hace posible realizar la consolidacin de
los pedidos de los distintos Centros de Responsabilidad a travs del sistema informtico, lo que se
espera reduzca la carga de trabajo de los funcionarios de Abastecimiento, evite el extravo de solicitudes,
mejore el control por parte de las unidades compradoras y agilice el proceso en general.
Gestin de Contratos.
Gestor de Contratos.
Pre Condicin
Post Condicin
Flujo Normal
La Gestin de contratos no sostuvo mayores cambios, puesto que parte importante del proceso se
realizaba a travs del portal de Mercado Pblico, el cual es de carcter estatal y a nivel nacional, lo que
imposibilit realizar cambios a nivel local.
40
Farmacia:
Figura 4.8: Modelo UML del rea de Farmacia - Encargado de Centro de Responsabilidad
Fuente: Elaboracin Propia
Figura 4.9: Modelo UML del rea de Farmacia - Encargado de Centro de Costo
Fuente: Elaboracin Propia
Autorizar Pedidos.
Pre Condicin
Post Condicin
Flujo Normal
Flujo Alternativo
41
Observaciones
de
Los distintos usuarios del rea de AFyB entrevistados del HBPM manifestaron en reiteradas ocasiones
que la validacin de pedidos es un proceso complicado. Esto se debe a que solan llegar pedidos
validados por centros de costo que no corresponden, no se encontraba a la persona que deba hacer la
validacin, o porque sola pasar que se realizaban pedidos sin ser previamente validados y
posteriormente ningn centro de costo se haca cargo del costo asociado. Con el fin de disminuir estos
problemas, en el nuevo modelo se opt por realizar la validacin electrnica. Anteriormente se realizaban
a travs de documentos firmados por el respectivo encargado del Centro de Responsabilidad, pero la
idea en este modelo es que la solicitud sea precargada al sistema por cada uno de los encargados del
Centro de Costo, para posteriormente ser validados o rechazados por el encargado del Centro de
Responsabilidad.
Ejecutar Pedidos.
Descripcin
Pre Condicin
Post Condicin
Flujo Normal
Se detecta la necesidad.
En el caso de la ejecucin de pedidos, el cambio fue que en vez de realizar los pedidos directamente al
encargado de Centro de Responsabilidad, los pedidos sean precargados al sistema para que
posteriormente el encargado del Centro de Responsabilidad realice la validacin para que posteriormente
ingresen al sistema de almacenamiento, integrando todos los pedidos en una sola interfaz donde puedan
ser fcilmente revisados y validados.
Tabla 4.9: Caso de Uso Elaboracin del Presupuesto del Plan Anual de Compras
Caso de Uso
Actores
42
Descripcin
Post Condicin
Flujo Normal
Se carga en el sistema.
El
encargado
del
Centro
de
Responsabilidad
revisa
los
En la elaboracin del Presupuesto del Plan Anual de Compras, como se mencion anteriormente, la idea
fue dividir el trabajo entre los respectivos encargados de Centros de Responsabilidad y la comisin que
evala los requerimientos. El primero deber realizar su proyeccin anual en base a pronsticos,
proyecciones, estadsticas (lo cual no se haca en aquel entonces) y presupuesto, velando por establecer
los requerimientos mensuales que sean pertinentes (dar estacionalidad a los pedidos) y el segundo
debera revisar dicha solicitud y hacer las observaciones que vengan al caso. De esta manera se busc
realizar una proyeccin ms precisa que ayude a la gestin de Bodega y disminuya los costos asociados
a almacenaje y pedidos.
43
Bodega:
44
Figura 4.13: Modelo UML del rea de Bodega - Encargado de Bodega General
Fuente: Elaboracin Propia
Prestar.
Jefe de Bodega.
Funcionarios de Bodega.
Unidades Compradoras.
Descripcin
Pre Condicin
Post Condicin
Que el prstamo sea efectuado y que lo prestado sea rebajado del sistema.
Flujo Normal
45
El caso de uso Prestar era considerado tambin como Donar por parte del Hospital Base de Puerto
Montt ya que muchas de las mercancas que se prestan no eran devueltas al hospital. Los prstamos
eran realizados preferentemente a hospitales con menos recursos como el Hospital de Maulln. Este caso
de uso era compartido por funcionarios de Abastecimiento y Bodega, ya que por una parte la solicitud era
recibida (abastecimiento) y la factibilidad del prstamo era chequeada por los funcionarios de Bodega.
Pedir Prestado.
Descripcin
Pre Condicin
Post Condicin
Flujo Normal
Funcionarios de Bodega.
Jefe de Bodega.
Descripcin
Pre Condicin
Post Condicin
Flujo Normal
Se recepciona el bulto.
46
Flujo Alternativo
Despachos no completos:
Entrega inmediata:
Se recepciona la mercadera.
Devoluciones:
Recepcin de Donaciones.
Funcionarios de Bodega.
Pre Condicin
Post Condicin
Flujo Normal
Se recepciona la donacin.
Jefe de Bodega.
47
Post Condicin
Flujo Normal
Se recibe el producto.
Transferir.
Descripcin
Pre Condicin
Post Condicin
Flujo Normal
En lo que respecta al Caso de Uso de Transferir, se vio que en rasgos generales no resultaba ser un
proceso que se realice con mucha eficiencia. No es que el proceso fuese mal ejecutado, sino que el
desorden generado en los pedidos repercuta directamente en el desempeo de este proceso.
Descripcin
Despacho de Pedidos.
Funcionarios de Bodega.
Jefe de Bodega.
Pre Condicin
Post Condicin
Flujo Normal
48
Flujo Alternativo
Se recibe el pedido.
Observaciones
Jefe de Bodega.
Funcionarios de Bodega.
Descripcin
Pre Condicin
Post Condicin
Flujo Normal
Flujo Alternativo
Falta de insumos:
49
El Caso de Uso de la Reposicin de Armarios digitales estaba bien implementado, pues las reposiciones
se encontraban programadas indicando niveles de inventario y sistemas de alerta temprana que evitaban
en gran parte los quiebres de stock.
4.3.2
Retroalimentacin
Durante el proceso de retroalimentacin, fueron revisados los procesos anteriormente modelados con
cada uno de los departamentos de Abastecimiento, Farmacia y Bodega, realizando las correcciones
necesarias e incorporando a dichos procesos los detalles especficos de la realidad del Hospital Base de
Puerto Montt. En este apartado se realizaron correcciones referente al como deberan ser los procesos
realmente, contrastado con el cmo era llevado hasta el momento.
4.3.3
Finalmente con toda la informacin reunida, se procedi a realizar el modelo de gestin de compras y
control de inventarios.
Una vez realizadas las modificaciones involucradas dentro del proceso de compra del HBPM a travs de
los Casos de Uso, se hizo posible elaborar la propuesta para el modelo de gestin de compras,
especificando la informacin necesaria y realizando una propuesta de interfaz.
Se sugiri modificar la forma en que la informacin era presentada al momento de efectuar las compras.
Para lograr esto se decidi incluir informacin de otras reas a la interfaz en la cual se realiza la compra
de insumos y/o medicamentos, como informacin de inventario restante del producto cotizado, consumo
promedio y disponibilidad aproximada (informacin que corresponde al rea de Bodega y Farmacia) Por
otro lado tambin se modific la bsqueda de proveedores y de productos, aadiendo distintas categora
para que as el usuario pueda encontrarlos de manera ms fcil en base a la informacin que se conozca
de stos.
Para poder realizar una propuesta de interfaz que cuente con los datos necesarios para poder encontrar
proveedores, productos, y efectuar una cotizacin, se establecieron los parmetros necesarios. Dichos
parmetros fueron los siguientes:
Categorizacin proveedores:
Dada la gran diversidad de insumos que se requieren en el hospital, existe tambin una gran cantidad de
proveedores que se manejan a la hora de solicitar productos. En este sentido, se sugiri realizar una
50
categorizacin de proveedores para de esta forma poder elegirlos de manera ms sencilla en funcin de
lo que se buscaba. Dentro de esta categorizacin los criterios sugeridos fueron:
a) Tipo de mercadera: Proveedores agrupados acorde al tipo de mercadera que venden, para de
esta manera facilitar la bsqueda de proveedores al momento de que surja la necesidad de un
insumo especfico.
b) Volumen de mercadera: El volumen de mercadera que se maneja con cada proveedor vara
enormemente, por lo cual esta categora se ide para encontrar proveedores teniendo claro el
volumen de mercadera que estos manejan.
c) Precio de los insumos: Agrupar los proveedores acorde al precio de los insumos que ellos
ofertan brinda la posibilidad de obtener mejores precios al momento de realizar una compra, por
lo que tambin se introdujo como categora.
d) Tiempo de respuesta: En caso de solicitar insumos con urgencia, se incorpor la clasificacin
de los proveedores acorde al tiempo de respuesta, para que de esta manera el HBPM pueda
obtener rpidamente los insumos que necesite.
e) Local / Nacional: En caso de requerir ciertos niveles de servicio o tiempo de respuesta, es
relevante conocer si el proveedor es de carcter local o nacional.
Niveles de stock:
El HBPM fija sus niveles de inventario para cada uno de sus productos acorde al siguiente criterio:
a) Stock mximo: La mxima cantidad que se puede tener de un producto antes de que genere
problemas de almacenamiento.
b) Stock mnimo: La mnima cantidad que se debe tener de determinado producto para que el
HBPM funcione con normalidad y evitar quiebres de stock.
Se sugiri por parte del HBPM que los inventarios fueran incluidos con un sistema de semforo, el cual
muestre en colores los distintos niveles de inventario para que de esta manera les sea ms fcil
estableces que productos se encuentran en niveles muy altos o muy bajos.
Categorizacin de productos:
Dentro del HBPM existan diversos tipos de insumos que se compraban, por lo cual se hizo necesario
realizar una categorizacin de los diferentes tipos de insumos que se requieren.
a) Insumos mdicos: Insumos requeridos para satisfacer las necesidades mdicas de los
pacientes del HBPM, como jeringas, catteres, etc.
b) Medicamentos: todo tipo de medicinas requeridas para el tratamiento de las enfermedades.
c) Equipamiento mdico: El equipamiento mdico abarca cualquier tipo de equipo que se utilice
para realizar exmenes mdicos, como escneres, mquinas de rayos x, incubadoras, etc.
51
Servicios: En esta categora se encuentran los servicios realizados al hospital que si bien
pueden ser de carcter intangible, se deben cotizar de igual manera.
g) Otros: Cualquier otro insumo o producto que no se encuentre incluido en las categoras
anteriormente expuestas.
Prioridad de productos:
Cada tipo de insumo tiene una prioridad distinta acorde a la urgencia con la que se necesite y a la
necesidad que vaya a satisfacer, por lo que se sugiri aadir el nivel de prioridad de cada uno de ellos. La
idea de la bsqueda por prioridad es que se establezca la prioridad del insumo que se desea buscar y
posteriormente al buscar un proveedor el sistema sugiera proveedores que puedan satisfacer dicha
necesidad en base a los tiempos de respuesta de cada uno de ellos, para as reducir la espera del
producto en caso de ser de prioridad alta.
a) Alta: Productos que se requieren en el hospital a la brevedad, por lo que necesitan ser adquiridos
de manera inmediata.
b) Media: Productos que debieran ser adquiridos en un plazo inferior a una semana.
c) Baja: Productos corrientes que pueden ser adquiridos en un plazo mayor a una semana.
Precio de compra: Se incluy tambin el precio en que finalmente se compra el insumo, para
poder ir actualizando el valor de referencia y el valor histrico.
52
g) Consumo semanal / mensual / anual: Se incluy el consumo promedio de cada producto con el
fin de poder establecer cundo se deber efectuar una compra (aunque no se realice una
solicitud de compra). De esta manera se podra anticipar ante un eventual quiebre de stock.
La propuesta de interfaz para realizar las compras del HBPM consta de lo siguiente:
Posteriormente con los cambios realizados, se elabor una propuesta de interfaz que contenga la
informacin que se desea incluir.
53
El plan anual de compra estara dentro del sistema y sera actualizado constantemente a travs
de los consumos efectuados, mejorando la previsin para los aos siguientes.
Finalmente, la compra se realizara con una mayor cantidad de informacin, que permitira reducir
la carga de bodega, evitando el sobreestock y quiebres de stock, reducira costos al permitir
postergar compras postergables, disminuyendo el costo de oportunidad del HBPM.
54
Para el modelo de control de inventarios primero se establecieron los datos que iban a ser necesarios,
para despus unirlos de tal forma que generen informacin til para la toma de decisiones.
Primero que todo se establecieron los atributos que eran necesarios para realizar el seguimiento de los
inventarios. Dentro de dichos atributos se establecieron los siguientes:
a) Nombre: Nombre del producto correspondiente.
b) Proveedor: Nombre de l o los proveedores del respectivo producto, para de esta manera poder
llevar un registro ms completo asociado tanto al producto como los proveedores, mostrando los
precios de compra, cantidades, tiempos de respuesta, etc.
c) Cantidad: La cantidad de bienes es un atributo bsico, pues el control de inventarios en gran
medida se basa en l, de esta forma se hace necesario llevar un registro de la cantidad de bienes
que se tienen en bodega para poder realizar gestin sobre ellos.
d) Niveles de stock: En una organizacin que compra mensualmente una gran cantidad y variedad
de productos, se hace necesario establecer los niveles de stock que se deben manejar para
poder satisfacer la demanda. De esta manera se incluy en los atributos los distintos niveles de
stock de cada producto. stos son:
Stock mximo: La mxima cantidad que se puede tener de un producto antes de que
genere problemas de almacenamiento.
Stock mnimo: La mnima cantidad que se debe tener de determinado producto para que el
HBPM funcione con normalidad.
e) SKU y cdigo interno: Estos cdigos se incluyen para poder llevar a cabo un control
computarizado de los inventarios y alimentar al sistema informtico.
f)
Presentacin: Fue necesario conocer de qu forma era presentado determinado insumo (botella,
unidad, kilo, etc.) por lo que fue aadido este dato.
j)
55
Datos histricos: Los datos histricos se manejaban dentro del HBPM, aunque no de la manera
ideal pues no se actualizaban correctamente y no eran lo suficientemente completos. En el nuevo
modelo se propuso incorporarlos de tal manera que se vayan actualizando con el consumo del
ao anterior, para que al momento de realizar la planeacin anual o mensual, se cuente con un
dato certero de cuanto se consumi a la misma fecha en periodos anteriores. La incorporacin de
los datos histricos es un aspecto que se debiera lograr en el mediano o largo plazo, pues se
requiere levantar informacin de varios periodos para que sta pueda arrojar resultados certeros.
56
h) Indicadores de entregas correctas: Las entregas correctas por su parte aadieron el dato de
qu porcentaje de las entregas cumplen con lo estipulado en la orden de compra o en el contrato.
i)
Indicadores de atraso: Los atrasos para cierto tipo de insumos pueden ser crticos, por lo que se
hizo necesario establecer el indicador de atraso para as de esta manera descartar proveedores
que puedan ser riesgosos para insumos crticos.
j)
Grficos:
El uso de interfaces grficas facilita la interpretacin de los datos que se obtienen del sistema, por lo cual
se incluyeron para mejorar la comprensin de los datos que se les presenten a los usuarios.
Con las variables y atributos necesarios previamente establecidos, se procedi a organizarlas para
elaborar la forma en la cual los datos debiesen estar estructurados para poder extraer de ellos
informacin til que permita la toma de decisiones. Para esto se realizaron varias propuestas en
diferentes reas.
Control de inventarios:
Esto es algo que se manejaba en el HBPM a travs de la Bincard, la cual muestra la siguiente
informacin:
a) Ubicacin fsica: Muestra en qu bodega se encuentra determinado producto.
b) Producto: Indica de que producto se trata.
c) Presentacin: La presentacin indica si el producto se almacena como caja, botella, unidad, etc,
aunque esta informacin no siempre se encontraba presente.
d) Fecha movimiento: Cundo era realizado determinado movimiento.
e) Origen: Muestra el proveedor de determinado producto.
f)
Cantidades: Mostraba la informacin de las cantidades involucradas en las salidas como en las
entradas.
j)
57
La informacin mostrada por la Bincard era suficiente, aunque contaba con ciertas falencias que debieron
ser tratadas:
a) Si bien contaba con fechas, las entradas y salidas no estaban organizadas por mes (slo
contenan la fecha), lo que en el caso de productos con muchos movimientos dificultaba la
obtencin de informacin especfica.
b) No contaba con grficos que puedan interpretar el comportamiento de los productos que all se
mostraban.
c) No se poda interactuar con ella dentro del sistema, slo a travs de una planilla Excel, por lo que
el usuario muchas veces tena que trabajar los datos para obtener la informacin que deseaba.
d) Indicaba el ultimo precio de adquisicin, pero no mostraba la tendencia de stos.
58
i.
En el modelo que se utilizaba en el hospital, la informacin que se pudo obtener a travs de la Bincard,
una vez procesada era la siguiente:
Tabla 4.18: Informacin cuantitativa sistema Orden
Povidona
Enero
Febrero
Marzo
Abril
Mayo
Junio
Cdigo:
217-6905
Proveedor:
Droguera Hoffmann
Bodega:
Bodega general
Presentacin:
Frasco
ltimo precio:
Destino de salida:
Stock mnimo:
20.000
Fuente: Elaboracin Propia
Como se pudo observar, si bien es cierto que la informacin generada a travs de la Bincard era
informacin valiosa, no era lo suficientemente completa, pues dejaba ciertos vacos de informacin ante
los cuales era necesario recurrir a otros informes que en algunas oportunidades haba que trabajarlos en
planillas de Excel.
Ante esta situacin se aadieron una serie de campos que permitan obtener mayor informacin dentro
del mismo informe para no tener que recurrir a otros informes adicionales que permitieran tener toda la
informacin que se deseaba.
59
ii.
Con la propuesta de modelo, tras el anlisis de diversos informes, la informacin se enriqueci brindando
los siguientes datos:
Tabla 4.20: Informacin cuantitativa modelo propuesto
Povidona
Enero
Febrero
Marzo
Abril
Mayo
Junio
Unidad
[Frasco]
[Frasco]
[Frasco]
[Frasco]
[Frasco]
[Frasco]
Rotacin
0,2%
31,7%
45,5%
71,2%
71,8%
66,3%
Cdigo:
217-6905
Proveedor:
Droguera Hoffmann
6,52 das
Desviacin estndar:
11,06 das
Bodega:
Bodega general
Presentacin:
Frasco
ltimo precio:
$857
Destino de salida:
Promedio de consumo:
21.940 unidades
Stock mnimo
13.350
Stock mximo
21.000
Fuente: Elaboracin Propia
El uso de grficos dentro de esta propuesta se utiliz para poder sensibilizar de mejor manera el
comportamiento de determinadas variables, para que de esta manera pueda ser ms notoria cualquier
anomala que se pueda producir en determinado producto. Continuando con el ejemplo de la Povidona,
se pudo apreciar que existi un comportamiento demasiado irregular, pues hubo periodos en que la
diferencia entre consumo y entrada fue excesiva como en los meses de enero, febrero y abril, donde se
registraron diferencias mayores a 35.000 unidades.
60
Consumo vs Entradas
Cantidad de Povidona
70000
60000
50000
40000
Consumo
30000
Entradas
20000
10000
0
Enero Febrero Marzo
Abril
Mayo
Junio
Para llegar a obtener estos datos, fue necesario el estudio y procesamiento de 3 informes diferentes
(Bincard, Entregas por Proveedor, y Despacho de Medicamentos), lo que represent un gran consumo de
tiempo. La idea de implementar una Bincard con estos datos es evitar tener que realizar todo trabajo y
tener la informacin de manera inmediata, ya que el software lo permite.
El anlisis de los datos obtenidos dio la posibilidad de plantear cambios al modelo de aprovisionamiento
de este insumo en particular en distintos mbitos:
a) Dado el tiempo de respuesta del proveedor, los pedidos que se realizan mensualmente podran
realizarse cada 10 das, lo cual posibilitara rebajar el stock mnimo a 15.217 unidades
(aproximadamente un tercio del promedio de consumo mensual ms un margen de seguridad del
20 por ciento).
b) El stock mximo no debiese ser mayor al peak histrico mensual de consumo. Tomando en
cuenta que los pedidos pudiesen realizarse cada 10 das, no debiese ser superior a las 18.950
unidades, aunque el criterio de fijacin puede variar.
c) Si bien es cierto el consumo no debiese variar al implementar este modelo, el realizar compras en
cantidades menores podra ahorrar un importante costo de oportunidad. Al realizar pedidos cada
10 das de 15.217 en vez de realizar una compra mensual de 38.043 unidades permitira al
HBPM ahorrar un costo de oportunidad de $19.561.882 en cada pedido.
d) Las bodegas del HBPM no eran particularmente espaciosas, y siempre en el pasillo de entrada a
las bodegas se encontraba gran cantidad de mercadera. Replicar el modelo expuesto para este
61
insumo en particular a los otros productos que se manejan en el HBPM podra significar un
ahorro en espacio que podra permitir mantener los pasillos despejados.
e) Los riesgos en los que se incurre al tener una gran cantidad de inventarios inmovilizados
(obsolescencia, caducidad, deterioro, etc.) se disminuiran al tener menos productos en las
bodegas.
f)
La rotacin promedio actual es de un 47.8 por ciento, esto significa que en promedio ms de la
mitad de los insumos adquiridos en cada mes quedan en bodega para el mes siguiente. Al aplicar
estos parmetros, la rotacin mensual debiese aumentar, al disminuir el nmero de productos
almacenados que quedan al no consumir un pedido completo, lo que muestra que el sistema
debiese mejorar la eficiencia.
Control de proveedores:
i.
Modelo Utilizado
El control de proveedores en el HBPM era bastante escaso, ya que los datos que se registraban eran de
carcter ms cualitativo que cuantitativo. Dentro de los registros del HBPM, se encontraban:
a) Nombre:
b) RUT:
c) Insumo entregado:
d) Orden de compra asociada:
Con dichos atributos, el control de proveedores que se llevaba en el HBPM era ms bien un control
contable, pero no un control apto para realizar gestin. Es por eso que realiz una propuesta que sirva de
base para realizar un control de proveedores que permita categorizarlos de tal forma que se sepa
claramente las diferencias entre uno y otro en lo que a cumplimiento respecta.
ii.
Modelo Propuesto
Como propuesta se quiso establecer una estructura que ayude a realizar el control de proveedores a
travs de indicadores de gestin. La idea de implementar los indicadores fue el poder categorizar a los
distintos proveedores en base a su nivel de cumplimiento y tiempos de respuesta para poder elegir entre
ellos (en caso de una compra directa) o para poder prever su comportamiento.
62
Indicadores de devoluciones:
Con dicha informacin, se podra conocer claramente el comportamiento de los distintos proveedores que
satisfacen las necesidades del HBPM.
El control de proveedores servira para alimentar el sistema de Abastecimiento, Farmacia y Bodega, pues
contar con mayor informacin a la hora de licitar o de escoger proveedores, a su vez debiera ayudar a
bodega, pues podra ayudar a reducir el volumen de existencias, al realizarse compras ms eficientes
que consideren los indicadores y los tiempos de respuesta.
63
5. CONCLUSIONES
De acuerdo con los objetivos establecidos, el trabajo realizado y los resultados obtenidos se pueden
obtener las siguientes conclusiones:
i.
satisfacer plenamente sus necesidades, pues existen tareas que pudiendo ser llevadas por el
sistema informtico, son llevadas de manera manual y las tareas que son llevadas a cabo dentro
de ste son satisfechas de manera incompleta, lo que genera prdidas de tiempo que podran ser
evitadas de contar con un sistema que se ajuste de mejor manera al HBPM.
ii.
iii.
El HBPM requiere mejorar su sistema de manejo de inventarios para que este le pueda ser de
mayor utilidad, explotando de mejor manera algunos atributos, como lo son:
Soporte: como se pudo apreciar era llevado por una sola persona, lo cual es una grave
falencia para una organizacin del tamao del HBPM, pues en ciertas instancias le
resulta difcil recuperarse de fallas en el sistema cuando dicha persona no se encuentra.
Seguridad: La informacin del sistema no debiese ser tan fcilmente modificable por
cualquier usuario y ms an que no se tenga un registro de quin realiz dicha
modificacin.
iv.
Si bien es cierto que como se demostr anteriormente, est claramente establecido que procesos
son llevados dentro del sistema informtico por cada uno de los usuarios, el cmo eran estos
realizados no lo estaba, sin embargo, el modelo propuesto sugiere cambios que de ser
implementados podran ayudar a mejorar el cmo cada uno de los procesos es realizado dentro
del sistema informtico, logrando posiblemente de esta manera un mejor desempeo de los
funcionarios.
64
v.
65
6. RECOMENDACIONES
Una vez concluido este estudio, se pueden realizar las siguientes recomendaciones, dirigidas tanto al
HBPM como a futuras investigaiones:
i.
Podra resultar interesante utilizar esta metodologa para analizar los requerimientos de los
servicios clnicos del HBPM.
ii.
La metodologa expuesta sugiere una forma de abordar problemas de carcter administrativo informtico en los que se desconozcan las causas especficas, pudiendo ser utilizada en otro tipo
de organizaciones con problemas similares.
iii.
Se sugiere al HBPM cambiar su sistema informtico por uno ms actualizado que sea ms
amigable con el usuario, seguro y que permita la incorporacin de mdulos que se adapten a las
necesidades de las distintas unidades y servicios clnicos.
iv.
Los costos asociados a realizar una orden de compra no fueron considerados dentro del modelo,
pero si podra ser objeto de otro estudio para un trabajo a nivel mas especfico.
v.
El HBPM debiera capacitar a ms personal para realizar el servicio de mantencin para evitar
problemas causados por un soporte deficiente.
vi.
De ser posible, el HBPM debiese implementar algn sistema de incentivos (no necesariamente
monetarios) e indicadores que fomenten el trabajo en equipo de los diversos departamentos que
lo componen, para mejorar la integracin y el cumplimiento de las metas.
66
7. BIBLIOGRAFA
GOLDRATT E. 1994. El Sndrome del Pajar. Madrid. Ediciones Daz de Santos. 248p.
KRAJEWSKY L. y Ritzman L.1999. Operations Management: Strategy and Analysis 6 ed. EE.UU,
Prentice Hall. 883p.
SERVICIO DE SALUD DEL MAULE. 2009. Red Asistencial Servicio de Salud del Maule. Chile. 51p.
STEVEN P. y Pooley R.2007. Utilizacin de UML en Ingeniera del Software con Objetos y
Componentes. Madrid, Addison Wesley. 277p.
67
8. LINKOGRAFA
CCERES
TELLO.
J.
2006.
Diagramas
de
Casos
de
Uso.
[en
lnea]
<
CHILE AVANZA CON TODOS. 2013. Construccin del nuevo Hospital de Puerto Montt muestra un
70% de avance [en lnea] < http://www.chileavanzacontodos.cl/chile-hoy/construccion-de-nuevohospital-de-puerto-montt-muestra-70-de-avance/index.html> [consulta 15 de julio 2013].
CIMATIC S.R.L 2001. El enfoque de la Teora de las Restricciones y el Drum Buffer Rope para la
manufactura [en lnea] < http://www.cimatic.com.ar/toc/articulos/teoria.asp> [consulta 16 de
septiembre 2013].
CRANFIELD
UNIVERSITY
2008.
La
Cadena
de
Suministro
gil
[en
lnea]
<
http://www.logistica.enfasis.com/adjuntos/12/documentos/000/060/0000060746.pdf> [consulta 16 de
septiembre 2013].
DOCUMENT
INFORMATION
RETRIEVAL
SYSTEMS.2013.
Qu
es
UML.
[en
lnea]
<
GOBIERNO
DE
CHILE.
2013.
NUEVO
HOSPITAL
Puerto
Montt
[en
lnea]
GUA DIGITAL. 2013. Gua Web. [en lnea] < http://www.guiadigital.gob.cl/guia-web> [consulta: 20
de julio 2013].
HOSPITAL
PUERTO
MONTT.
2013.
Quienes
Somos.
[en
lnea]
<
JUNTA DE ANDALUCA. 2013. Gua para la redaccin de casos de uso. [en lnea] <
http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/416> [consulta: 7 de septiembre
2013].
MALLAR, M. 2010. La Gestin por Procesos: un enfoque de gestin eficiente. [en lnea] <
http://www.scielo.org.ar/scielo.php?pid=S1668-87082010000100004&script=sci_arttext> [consulta
10 de octubre 2013].
MINISTERIO
DE
FOMENTO.
2005.
La
Gestin
por
Procesos.
[en
lnea]
<
MORA
F.
2002.UML:
Lenguaje
Unificado
de
Modelado
[en
lnea]
<
68
PIRES, A. MACHADO, V. 2005. Gestin por Procesos en el Diseo de las Organizaciones. [en lnea]
< http://www.scielo.cl/scielo.php?pid=S0718-07642006000100005&script=sci_arttext> [consulta 10
de octubre 2013].
REAL
ACADEMIA
espaola
2013.
Diccionario
de
la
lengua
espaola.
[en
lnea]
<
SERVICIO DE SALUD DEL RELONCAV. 2013. Hospital de Puerto Montt [en lnea] <
http://salunet.minsal.gov.cl/portal/page?_pageid=537,4873135&_dad=portal&_schema=PORTAL>
[consulta: 21 de julio 2013].
SERVICIO DE SALUD DEL RELONCAV. 2013. Nuevo Hospital de Puerto Montt [en lnea] <
http://ssrelon.redsalud.gob.cl/?page_id=930>[consulta:25 de julio 2013].
SERVICIO DE SALUD DEL RELONCAV. 2013. Red de Servicio de Salud Del Reloncav [en lnea] <
http://salunet.minsal.gov.cl/portal/page?_pageid=537,4838955&_dad=portal&_schema=PORTAL>
[consulta: 21 de julio 2013].
TEOC CONSULTORS
Teora de las limitaciones (Theory of Constraints T.O.C.) y sus sinergias con los sistema de mejora
continua. [en lnea] < http://www.teoce.com/rcs_prod/070201_dbr_smc.pdf> [consulta 16 de
septiembre 2013].
UNIVERSIDAD
DE
CRDOBA.
Diseo
de
Encuestas
<http://www.uco.es/zootecniaygestion/img/pictorex/09_13_21_sesion_6.pdf>
[en
[consulta:
lnea]
5
de
septiembre 2013].
69
9. ANEXOS
Evento Intermedio de
Mensaje
Trmino
Tarea de usuario
Tarea de envo
Tarea manual
Subproceso
Definicin
Las
decisiones
son
utilizadas
para
controlar
la
70
71
Povidona
Enero
Febrero
Marzo
Abril
Mayo
Junio
Unidad
[Frasco]
[Frasco]
[Frasco]
[Frasco]
[Frasco]
[Frasco]
228.257
218.158
[frascos/periodo]
[frascos/periodo]
Promedio de Entradas
47,8%
36.360
[%]
[frascos/mes]
21.000
20%
25.200
[frascos]
[%]
[frascos]
31.500
5%
33.075
[frascos]
[%]
[frascos]
Rotacin
0,2%
31,7%
45,5%
71,2%
71,8%
66,3%
Droguera Hoffmann
6,52 das
11,06 das
Bodega General
Insumo Mdico
Frasco
$ 857
Diversos servicios clnicos
38.043
21.941
20.000
80.000
72
Situacin Actual
Tiempo de pedido actual
Pedidos mensuales
Mximo tiempo de respuesta
Das de Riesgo
Promedio de consumo mensual
Costo del Insumo
Requerimiento por pedido
Costo del Pedido
30 [das]
1 [pedidos/mes]
17,58 [das]
-12 [das]
38.043 [frascos]
$ 857
38.043 [frascos]
$ 32.602.851
Situacin Propuesta 1
Tiempo de pedido 1
Pedidos mensuales
Mximo tiempo de respuesta
Das de Riesgo
Promedio de consumo mensual
Costo del Insumo
Requerimiento por pedido
Margen de Seguridad
Cantidad a pedir
Costo del pedido
Stock Mximo
10 [das]
3 [pedidos/mes]
17,58 [das]
7,58 [das]
38.043 [frascos]
$ 857
12.681 [frascos]
20% [%]
15.217 [frascos]
$ 13.041.083
25.200 [frascos]
Situacin Propuesta 2
Tiempo de pedido 2
Pedidos mensuales
Mximo tiempo de respuesta
Das de Riesgo
Promedio de consumo mensual
Costo del Insumo
Requerimiento por pedido
Margen de Seguridad
Cantidad a pedir
Costo del pedido
Stock Mximo
15 [das]
2 [pedidos/mes]
17,58 [das]
2,58 [das]
38.043 [frascos]
$ 857
19.021 [frascos]
5% [%]
19.972 [frascos]
$ 17.116.422
33.075 [frascos]
73
Costo
insumo
Situacin actual
Situacin propuesta 1
Situacin propuesta 2
$ 857
$ 857
$ 857
Cantidad
[frascos]
38.043
15.217
19.972
Costo Total
$ 32.602.851
$ 13.040.969
$ 17.116.004
74