Estudios Profesionales para Ejecutivos

Curso:
SIMULACIÓN DE SISTEMAS
TRABAJO FINAL

EMPRESA: FRACTALIA

Profesor:

Marcos Hernán Rivas Peña

Integrantes
 U201916812  Gutierrez Berrocal, Weizmann
 U201814751  Luyo Hernandez, Diego
 U201820131  Luza Segundo, Carlos
 U202016103  Quispe Torres, Freddy
 U202112739  Vargas Ccora, Jhordy

Tema
Simulación de sistemas aplicados a la automatización de un procedimiento
dedicado a la generación de reintentos de mensajes fallidos de la empresa
Fractalia

2021 - 2
 INDICE
.....................................................................................................................................................1
1.- DESCRIPCIÓN DE LA EMPRESA................................................................................................3
2.- DESCRIPCIÓN DEL PROCESO....................................................................................................4
REINTENTOS SCL.......................................................................................................................4
a) Realizar consulta en “SeaProduction”..............................................................................4
b) Realizar consulta en SCL”.................................................................................................4
c) Generar archivo Excel backup – histórico.........................................................................4
d) Copia columna “NUM MOVIMIENTO”..............................................................................4
e) Generar archivo de texto..................................................................................................4
f) Ejecutar Proceso “Reintentos”.........................................................................................4
DIAGRAMA BPMN AS-IS...........................................................................................................5
3.- DESCRIPCIÓN DE LA PROBLEMÁTICA......................................................................................6
4.- LISTA DE VARIABLES ALEATORIAS...........................................................................................7
5.- TABLA DE DATOS CON UNA MUESTRA DE CASOS EJECUTADOS A TRAVES DEL PROCESO. .7
6.- LISTA DE VARIABLES ALEATORIAS IDENTIFICADAS EN EL PROCESO........................................8
7.- Distribución de probabilidad asignada a cada variable aleatoria............................................9
Variable 1: Tiempo entre consulta y consulta..........................................................................9
Variable 2: Tiempo de validación y asignación de los casos...................................................10
Variable 3: Tiempo de consulta SCL.......................................................................................11
Variable 4: Tiempo de generación de archivo xls con histórico..............................................12
Variable 5: Tiempo de generar número de movimiento........................................................13
Variable 6: Tiempo para generar archivo .txt.........................................................................14
Variable 7: Tiempo en ejecutar el Jmeter para producir los reintentos.................................15
8.- MODELO DE SIMULACION AS-IS............................................................................................16
9.- SIMULACION Y ANALISIS DE INDICADORES DONDE SE REFLEJA EL PROCESO.......................17
10.- PROPUESTA DE MEJORA DEL MODELO...............................................................................20
11.- MODELO DE SIMULACION TO BE........................................................................................22
12.- ANALISIS DE RESULTADOS DE LA SIMULACIÓN...................................................................23
INTERVALOS DE CONFIANZA..................................................................................................23
13.- ANALISIS ECONOMICO DE LA PROPUESTA DE MEJORA......................................................24
FLUJO DE CAJA.......................................................................................................................24
14.- RECOMENDACIONES Y TOMA DECISION EN BASE A LA INFORMACIÓN BRINDADA POR EL
MODELO TO-BE..........................................................................................................................25
1.- DESCRIPCIÓN DE LA EMPRESA

Fractalia es una empresa de tecnología global especializada en gestión IT y comunicaciones.

Cuenta con más de 15 años de experiencia y una sólida presencia internacional, con actividad
en 12 países del mundo.

La compañía cuenta con más de 2000 empleados, distribuidos en diferentes continentes.

La actividad de Fractalia permite al cliente mejorar su productividad a través de la eficiencia,

reducir costos a través de la tecnología y crear fuentes de ingresos a través también de
innovadoras soluciones tecnológicas.

Su cartera de cliente está compuesta por prestigiosas compañías como:

 Bankiter
 Telefoncia
 Iberoestar
 Adeslas
 Vodafone
 Caser

Uno de los servicios que ofrece Fractalia es el de Soporte Tecnológico, que consiste en la
automatización de procesos operativos mediante herramientas y agentes autómatas como
ingenieros virtuales que monitorizan, diagnostican, resuelven y gestionan incidencias de un
determinado entorno que operan en servidores, redes, entornos virtualizados, help desk, base
de daros y aplicaciones.
2.- DESCRIPCIÓN DEL PROCESO

REINTENTOS SCL
Este proceso permite desencolar movimientos que van ingresando en el día. Se realiza una
ejecución en una consulta en la tabla “SeaProduction” para obtener el volumen total de los
casos que requieren un mensaje de alerta. Luego una consulta en la tabla “SCL” para identificar
los casos ya enviados y los que no. Estos que no fueron enviados necesitarían de un reintento
para que proceda su flujo en la herramienta llamada Jmeter. Son transacciones de una base de
datos de SCL. A veces éstas fallan y requieren un constante reintento para continuar con el
flujo y almacenarse en esa tabla.

Este proceso debe correr todos los días cada 30 minutos, por lo que se corre alrededor de 48
veces al día. Se sabe que el 85% de casos en el proceso necesitan un reintento.

a) Realizar consulta en “SeaProduction”

Como punto de partida se debe realizar una consulta en SQL para ir a buscar todos los
casos con la tipología. Asignación y validación de tickets en el proceso.

b) Realizar consulta en SCL”

Una vez obtenido el resultado de la consulta en SeaProduction se debe realizar la
consulta en SCL para identificar los casos que fueron enviados o necesitan reintento.
Esta consulta en SQL buscará todos los casos con la tipología de este proceso.

c) Generar archivo Excel backup – histórico

Cuando se hace la consulta en SCL para identificar los casos ya enviados por Jmeter, se
genera un archivo de respaldo para guardar como histórico todos los casos que han
seguido un flujo normal y no fue necesario proceder con un reintento.
 d) Copia columna “NUM MOVIMIENTO”
Una vez hecha la consulta se debe copiar completa la columna “NUM MOVIMIENTO”
para los casos que no pudieron salir de manera normal como intento. Esto en un
archivo txt.

e) Generar archivo de texto

Una vez copiada la columna completa se debe abrir un archivo .txt y copiar la tabla
completa en este archivo.

f) Ejecutar Proceso “Reintentos”

Con el archivo .txt creado sólo resta ejecutar el Jmeter.

DIAGRAMA BPMN AS-IS

3.- DESCRIPCIÓN DE LA PROBLEMÁTICA
Teniendo el proceso ya descrito, se han identificado problemas que hacen de esta
automatización poca productiva o no tanto como se desea.

 El proceso se realizó con la finalidad de tener 48 cortes diarios, donde cada uno en
promedio dure como máximo 30 minutos para que pueda ejecutarse uno tras otro sin
problema, sin embargo, diariamente se están identificando menos cortes de lo
pensado, por lo que se asume que existe una demora en el proceso.

A continuación, reporte adjunto de cortes en el mes de octubre de manera diaria:

 Como problema secundario, tenemos que los reportes generados tanto en el

archivo .txt y el .xlm no contienen la información completa del número de
movimiento, y eso puede deberse a una saturación en el proceso de consulta SCL que
causa inconvenientes en la tarea completa.

4.- LISTA DE VARIABLES ALEATORIAS

  Tiempo en ejecutarse el SEA PRODUCTION
 Tiempo en ejecutarse el SCL
 Tiempo en generar archivo Excel
 Tiempo en generar archivo de texto
 Tiempo en colocar número de movimiento
 Tiempo en ejecutarse el JMETER.

5.- TABLA DE DATOS CON UNA MUESTRA DE CASOS

EJECUTADOS A TRAVES DEL PROCESO

Mediante esta tabla de datos de tiempo de cada variable del proceso, se identifican los
tiempos de:

 Tiempo entre consulta y consulta observado.

 Demora en ejecutar la validación y asignación de casos para el proceso.
 Demora en realizar la consulta en la herramienta SCL para identificar los casos ya
enviados por el JMETER.
 Demora en generar el archivo de data histórica con los casos ya enviados.
 Demora de realizar la copia del número de movimiento en el archivo .txt.
 Demora en generar el archivo .txt.
 Demora en ejecutar el proceso de reintento en el JMETER
6.- LISTA DE VARIABLES ALEATORIAS IDENTIFICADAS
EN EL PROCESO
7.- Distribución de probabilidad asignada a cada variable aleatoria

Variable 1: Tiempo entre consulta y consulta

A continuación, se adjunta la evaluación en el software Input Analyzer.

Distribución Uniforme

Sintaxis: UNIF (25,32)

Variable 2: Tiempo de validación y asignación de los casos
A continuación, se adjunta la evaluación en el software Input Analyzer.

Distribución Uniforme

Sintaxis: UNIF (2,4)

Variable 3: Tiempo de consulta SCL
A continuación, se adjunta la evaluación en el software Input Analyzer.

Distribución Uniforme

Sintaxis: UNIF (3,6)

Variable 4: Tiempo de generación de archivo xls con histórico
A continuación, se adjunta la evaluación en el software Input Analyzer

Distribución Normal

Sintaxis: NORM (4.66,0.85)

Variable 5: Tiempo de generar número de movimiento
A continuación, se adjunta la evaluación en el software Input Analyzer.

Distribución Uniforme

Sintaxis: UNIF (6,8)

Variable 6: Tiempo para generar archivo .txt
A continuación, se adjunta la evaluación en el software Input Analyzer.

Distribución Uniforme

Sintaxis: UNIF (15,20)

Variable 7: Tiempo en ejecutar el Jmeter para producir los reintentos
A continuación, se adjunta la evaluación en el software Input Analyzer.

Distribución Uniforme

Sintaxis: UNIF (24,32)

8.- MODELO DE SIMULACION AS-IS

Usando el software web bpmn.io se realizó el modelo de simulación As-is adjunto a

continuación:

Diagrama Modelo

Diagrama modelo bpmn

9.- SIMULACION Y ANALISIS DE INDICADORES DONDE
SE REFLEJA EL PROBLEMA

Teniendo en cuenta que en el procedimiento lo ideal deberían ser 48 cortes por día, hacemos
la simulación para un mes con 30 días, y generamos 1440 simulaciones en el sistema, con un
10% de exclusión para alcanzar la estabilidad de la simulación.

Los resultados obtenidos de la herramienta bimp fueron los siguientes:

Información General de la simulación

Gráficas de la simulación
 Datos estadísticos de la simulación

Cuadro de datos de la simulación

Mapa de calor de los tiempos de espera (embotellamiento)

 Mapa de calor de duración de actividades

De los resultados mostrados podemos indicar lo siguiente, evidenciando los problemas

desarrollados:

1. El tiempo promedio de ciclo del proceso es de 53.5 minutos

2. La actividad que realiza la consulta SCL tiene una demora promedio de 7.6 minutos.
3. Es importante mencionar también que el disparados de reintentos con el JMETER tiene
una duración promedio de 29 minutos, casi el 100% del intervalo esperado para
duración de todo el proceso.
4. Existen procesos con una baja duración por ciclo.
10.- PROPUESTA DE MEJORA DEL MODELO

Habiendo comparado con los resultados obtenidos los problemas del proceso presentados en
un inicio e identificado algunos posibles problemas en el proceso AS-IS, se han considerado las
siguientes mejoras en el procedimiento que nos llevaran a la presentación del TO BE.

1. Sabiendo que la consulta por el proveedor en SCL está demandado mucho mas tiempo
de lo requerido encolando todo el sistema, se propone poder cambiar la actividad al
proveedor de SEA PRODUCTION que ejecuta su tarea más rápido, demostrando mayor
eficiencia posiblemente por un mejor servidor que ejecuta las consultas de maneras
más rápida.
2. Considerando que el procedimiento esta demandando mucho tiempo en la ejecución
por ciclo, se recomienda revisar las herramientas que ejecutan estas actividades:
a. Genera archivo txt – SCL: se necesita que el tiempo de demora pase de una
distribución uniforme (15,20) a una distribución uniforme (6,9). Reducirla en
mas del 50%.
b. Ejecuta los reintentos en el JMETER: se necesita que el tiempo de demora de
esta actividad pase de una distribución uniforme (24,32) a una (12,16), es
decir, reducirla en un 50%.

Con este par de recomendaciones estaríamos logrando como resolución del problema lo
siguiente:

1. Se desencolaría el proceso de consulta para identificar los casos que necesitan

reintentos, cambiándola de proveedor.
2. El tiempo promedio de la generación del archivo txt será de 7.5 minutos.
3. El tiempo promedio de la ejecución del envío de reintentos en el jmeter será de 14
minutos.
4. El tiempo de espera para iniciar la consulta será de 0 a 1 segundos.
5. El ciclo del procedimiento durará en promedio 29.5 minutos.
Se adjunta el diagrama con nuestra propuesta TO BE:
11.- MODELO DE SIMULACION TO BE
12.- ANALISIS DE RESULTADOS DE LA SIMULACIÓN

Para realizar la simulación TO BE se tomaron en cuenta las mismas condiciones del AS IN,
considerando 48 cortes por día para un mes (30 días), se realizan 1440 simulaciones con un
10% de exclusión para alcanzar la estabilidad.

1. El tiempo de espera se redujo a un pequeño intervalo de 0 a 1 segundo entre consulta

y consulta.
2. El tiempo promedio del ciclo pasó a 29.8 minutos.
3. La consulta para identificar los casos que no tienen reintentos paso a ser ejecutada por
el proveedor de SEA PRODUCTION, y con esto el tiempo medio en esta actividad es de
4.5 segundos, desencolando tal actividad.

INTERVALOS DE CONFIANZA
Trabajando con la data obtenida por el simulador bimp, calculamos los intervalos de confianza
para el tiempo de ciclo y saber si se lograron mejoras.

Analizamos los datos obtenidos y comentamos:

 Los intervalos de confianza son positivos.

 El 0 no está contenido en los intervalos.
 Se observa una mejora en los tiempos por ciclo.

Podemos decir que los cambios propuestos impactan positivamente en el proceso.

13.- ANALISIS ECONOMICO DE LA PROPUESTA DE
MEJORA

Teniendo en cuenta los resultados simulados y tomando los datos obtenidos como referencia
podemos indicar:

Con este estaríamos obteniendo un ahorro mensual en promedio de $48, generando no solo
un beneficio económico, sino también optimizando el servicio.

Adjunto detalle del cálculo:

FLUJO DE CAJA
Para llevar a cabo la mejora, se propone a la empresa invertir en el mejoramiento del proceso
hasta $350, la cual será recuperada a partir del 8vo mes desde la inversión con una tasa de
interés del 1.2%.

Podemos indicar que, al 8vo mes desde la inversión, se tendrá una rentabilidad favorable de
$14.07. Así al cierre del primer año, se tendrán $183.48 que podrán ser invertidos en algún
otro proceso.
14.- RECOMENDACIONES Y TOMA DECISION EN BASE A
LA INFORMACIÓN BRINDADA POR EL MODELO TO-BE

Con los datos obtenidos en el modelo TO-BE, hacemos las siguientes recomendaciones:

1. Habiendo identificado las actividades que tienen una demora muy larga y que hacen
que el tiempo de ciclo demore mas de lo previsto, se recomienda que alguna de las
actividades que hace el proveedor SCL, en este caso la de consulta SQL, las haga el
proveedor de SEA PRODUCTION que al parecer posee un servidor mucho mas rápido
para esta tarea específica.

2. Se recomienda también conversar con los proveedores para saber si es posible hacer
una limpieza general de sus servidores para que las actividades destinadas se ejecuten
de una manera más rápida que puedan reducir el tiempo de demora por ciclo.

3. Sabiendo que tenemos una PC robot que pertenece a la empresa, y que esta tiene un
bajo % de uso (0.63%), podemos implementar algunas otras tareas ya que también
tiene un bajo costo de producción por pertenecer al presupuesto interno.

4. Sabemos por reportes internos, que el % de casos que necesitan reintentos es del 85%
a más, haciendo que el proceso tenga también una demora larga por la cantidad de
movimientos que procesar. Se recomienda hacer una revisión a tareas previas a este
proceso que puedan tener quiebres que originen alta cantidad porcentual.

5. Teniendo en cuenta y habiendo demostrado que las mejoras nos originarán un ahorro
con retorno de inversión a corto plazo (menos de un año), se recomienda seguir
invirtiendo en este procedimiento, como hacer implementaciones de recursos en
diferentes actividades para reducir tiempos y mejor la efectividad de estas.