Escuela Superior Politécnica Del Litoral: Tesis de Grado "

ESCUELA SUPERIOR POLITÉCNICA DEL LITORAL
Facultad de Ingeniería en Electricidad y Computación
TESIS DE GRADO
“IMPLEMENTACIÓN DE LA METODOLOGÍA KANBAN PARA CONTROLAR

LA INTEGRIDAD DE LOS APLICATIVOS PUESTOS EN PRODUCCIÓN EN
ÁREAS DE TI Y GARANTIZAR LA CONSISTENCIA DE LOS DATOS,
APLICADO A COMPAÑÍAS DE TELECOMUNICACIONES”
Previa a la obtención del Título de:
MAGISTER EN SISTEMAS DE INFORMACIÓN

GERENCIAL
SYLVIA VERÓNICA MOREIRA NÚÑEZ

JIMMY IGNACIO SORNOZA MOREIRA
GUAYAQUIL - ECUADOR
Año 2015
AGRADECIMIENTO
A nuestra familia, compañeros y
amigos por el apoyo directo e
incondicional que nos brindaron, por
los consejos y/o experiencias
compartidas que nos sirvieron de
guía para moldear nuestro trabajo.
A Dios por bendecirnos y darnos la
oportunidad de haber culminado un
escalón más en nuestra vida
profesional.
ii
DEDICATORIA
A nuestra familia, a nuestros hijos
Naomi, Isaac y Ghislaine, inculcando
ejemplo, trabajo, humildad y
perseverancia, dejando nuestra
mayor herencia a la sociedad;
personas de bien.
iii
TRIBUNAL DE SUSTENTACIÓN
………………………………………
MG. Lenín Freire.
Director MSIG
………………………………………
MG. Ronny Santana E.
Director de Tesis
………………………………………
MG. Fausto Correa
Miembro Principal
iv
DECLARACIÓN EXPRESA
“La responsabilidad del contenido de este documento de tópico, nos
corresponde; y el patrimonio intelectual de la misma a la ESCUELA
SUPERIOR POLITÉCNICA DEL LITORAL”
(Reglamento de Graduación de la ESPOL)
____________________________
Ing. Sylvia Verónica Moreira Núñez
____________________________
Ing. Jimmy Ignacio Sornoza Moreira

v
RESUMEN
El siguiente documento está orientado a la implementación de una
Metodología de trabajo existente en el mercado mundial llamada KANBAN
aplicándola en áreas de Tecnologías de información en compañías de
Telecomunicaciones, ayudará a controlar la integridad de los aplicativos y de
esta forma también garantizar la consistencia de los datos, como su historia
lo muestra, sus primeros pasos e implementaciones empezaron en una
fábrica de automóviles llamada Toyota, pero se ha demostrado que es una
metodología que sirve en cualquier área de trabajo, indiferente de la actividad
comercial de la compañía.
Para la elaboración de esta propuesta se detallara la problemática, objetivos,
y las reglas para utilizar la metodología de trabajo, describiendo información
relevante y esquemas de conciliación del área. Se generaron tableros,
estableciendo nuevas políticas que se van encontrando al momento de
aplicar conceptos, así mismo, se analiza la información recolectada en la
encuesta realizada en el tercer capítulo, se prueba que existe un gran
segmento de mercado dentro de las compañías del Ecuador que no conoce
la metodología KANBAN y que pueden obtener muchos beneficios en

vi
logística y reducir costo económico, que impacta el presupuesto del área de
Tecnología o del área que solicita algún requerimiento.
En el sexto capítulo se analizan los resultados obtenidos al implementar la
metodología propuesta, mostrando estadísticas sobre los beneficios que nos
brinda la metodología aplicada.

vii
ÍNDICE GENERAL
AGRADECIMIENTO ........................................................................................i
DEDICATORIA................................................................................................ ii
TRIBUNAL DE SUSTENTACIÓN .................................................................. iii
DECLARACIÓN EXPRESA ........................................................................... iv
RESUMEN ......................................................................................................v
ÍNDICE GENERAL ........................................................................................ vii
ABREVIATURAS Y SIMBOLOGÍA ............................................................... xii
ÍNDICE DE FIGURAS .................................................................................. xiii
ÍNDICE DE TABLAS ................................................................................... xvii
INTRODUCCIÓN ....................................................................................... xviii
GENERALIDADES ......................................................................................... 1
1.1 Antecedentes ..................................................................................... 1
1.2 Descripción del Problema .................................................................. 3
1.3 Solución Propuesta ............................................................................ 5
1.4 Objetivo General ................................................................................ 7
1.5 Objetivos Específicos......................................................................... 7
1.6 Metodología ....................................................................................... 8

viii
MARCO TEÓRICO ....................................................................................... 10
2.1 Kanban ............................................................................................ 10
2.1.1 Principios de Kanban ................................................................... 11
2.1.2 Ventajas de Kanban..................................................................... 13
2.1.3 Elementos en Kanban................................................................... 15
2.1.3.1 Flujo de trabajo:.................................................................... 15
2.1.3.2 WIP - Limitar el trabajo en curso: .......................................... 19
2.1.3.3 Gestión del flujo:.................................................................... 21
2.1.3.4 Reglas del proceso:............................................................... 24
2.1.3.5 Mejora en equipo:.................................................................. 24
2.1.4 Implementación de Kanban en 4 Fases....................................... 25
2.1.5 Herramientas para utilizar Kanban............................................... 26
2.2 Organización de Tecnología de Información ................................... 30
2.2.1 Estructura de Proyectos ............................................................ 31
2.2.2 Estructura de Gerencia de Sistemas de Información ................ 32
2.2.3 Estructura de Network – Base de Datos ................................... 35
2.2.4 Estructura de Arquitectura ......................................................... 36
2.2.5 Estructura de Datawarehouse ................................................... 37
2.3 Plataformas de Producción .............................................................. 37

ix
2.4 Seguridad y accesos de producción ................................................ 39
LEVANTAMIENTO DE INFORMACIÓN ....................................................... 41
3.1 Arquitectura en ambientes de Producción ....................................... 41
3.2 Incidentes de pases a producción ................................................... 43
3.2.1 Calidad en proveedores ............................................................ 48
3.2.2 Calidad en los despliegues ....................................................... 49
3.2.3 Disponibilidad de recursos ........................................................ 51
3.3 Políticas de despliegues a Producción ............................................ 52
3.3.1 Política de despliegues proyectos y tareas. .............................. 53
3.3.2 Política de despliegues por cambios emergentes ..................... 59
3.4 Esquema de conciliación por incidentes ocurridos .......................... 61
3.5 Estudio de mercado sobre Metodología de trabajo ......................... 62
3.5.1 Recolección de datos - Encuestas: ........................................... 62
3.5.2 Población Objetivo .................................................................... 63
3.5.3 Cálculo de la muestra................................................................ 66
ANÁLISIS Y DISEÑO DE LA SOLUCIÓN..................................................... 70
4.1 Mapas de Flujo de Valor .................................................................. 70
4.2 Identificación de acciones del flujo de valor de la Unidades del Área
de producción ......................................................................................... 71
x
4.2.1 Mapa de Flujo de Valor grupo de Control de Cambios.............. 71
4.2.2 Mapa de flujo de valor Grupo de Control de Consistencia
de Datos. ............................................................................................... 74
4.3 Cálculo del tiempo real en cada acción del flujo .............................. 76
4.4 Identificar el tiempo entre acciones del flujo .................................... 78
4.5 Identificar Ciclos .............................................................................. 79
4.6 Cálculo de eficiencia del ciclo .......................................................... 80
4.6.1 Cálculo de eficiencia del proceso del grupo de control de
cambios ................................................................................................. 81
consistencia de datos ............................................................................ 83
IMPLEMENTACIÓN Y PRUEBAS DE KANBAN........................................... 87
5.1 Implementación de Kanban ............................................................. 87
5.2 Generación de tableros para unidad responsable del control de los
aplicativos en producción .......................................................................... 89
5.2.1 Tarjeta Visual definida para el grupo de control de cambios ..... 95
5.2.2 Tablero personal ....................................................................... 97
5.3 Generación de nuevas políticas para unidad responsable del control
de los aplicativos en producción................................................................ 98
5.4 Plan de pruebas ............................................................................. 102

xi
5.4.1 Unidad de análisis - Grupo de control cambios ....................... 102
5.4.2 Unidad de análisis - Encuesta áreas de TI en el mercado
ecuatoriano. ......................................................................................... 106
ANÁLISIS DE RESULTADOS..................................................................... 111
6.1 Análisis de cantidad de pases a producción al implementar
Kanban. ................................................................................................... 111
6.2 Análisis de efectividad de pases a producción al implementar
Kanban. ................................................................................................... 113
6.3 Análisis de inconsistencia de datos por pases mal realizados....... 115
6.4 Estadística de reversos de pases a producción............................. 118
CONCLUSIONES Y RECOMENDACIONES ............................................ 120
BIBLIOGRAFÍA .......................................................................................... 123
ANEXOS .................................................................................................... 126

xii
ABREVIATURAS Y SIMBOLOGÍA
EFA Eficiencia del flujo actual
EFP Eficiencia del flujo propuesto
EP Eficiencia del proceso
JIT Just in time
QC Control de Calidad
SLA Acuerdo de nivel de Servicio (Service Level Agreement)
WIP Work in progress

xiii
ÍNDICE DE FIGURAS
Figura 1.1 Beneficio Kanban ........................................................................... 5
Figura 1.2 Beneficios Generales utilizando Kanban ....................................... 9
Figura 2.1 Tablero Kanban ........................................................................... 16
Figura 2.2 Tarjeta Visual ............................................................................... 18
Figura 2.3 Tablero especificando WIP .......................................................... 20
Figura 2.4 Lead Time– Cycle Time ............................................................... 23
Figura 2.5 Tablero Trello ............................................................................... 27
Figura 2.6 Tablero visual con KANBAN TOOL ............................................. 28
Figura 2.7 Figura de estadísticas por fase del tablero .................................. 28
Figura 2.8 Empresas que utilizan KANBAN Tool .......................................... 29
Figura 2.9 Tablero Jira .................................................................................. 30
Figura 2.10 Estructura Organizacional en áreas de Tecnología Información 31
Figura 2.11 Estructura de Proyectos............................................................ 32
Figura 2.12 Estructura de Sistemas de Información Gerencial ..................... 34
Figura 2.13 Estructura de Network-Base de datos ....................................... 36
Figura 2.14 Estructura de Arquitectura ......................................................... 36
Figura 2.15 Estructura de Datawarehouse ................................................... 37
Figura 2.16 Esquema de Autorización de requerimientos de seguridad y
accesos ......................................................................................................... 40
Figura 3.1 Arquitectura en Ambiente de Producción..................................... 42
Figura 3.2 Flujo Actual de despliegues por proyecto .................................... 44

xiv
Figura 3.3 Flujo actual de despliegues por ajustes o pases emergentes a
producción .................................................................................................... 45
Figura 3.4 Flujo actual de requerimiento de mejoras internas de Producción
...................................................................................................................... 46
Figura 3.5 Flujo actual de atención de habilitación/deshabilitación de
funcionalidades ............................................................................................. 47
Figura 3.6 Despliegues fallidos vs despliegues realizados por año .............. 50
Figura 3.7 Despliegues fallidos vs despliegues realizados por mes. ............ 51
Figura 3.8 Esquema de conciliación por incidentes ocurridos ...................... 61
Figura 3.9 Total de Compañías pequeñas del Ecuador por ciudad .............. 64
Figura 3.10 Total de compañías medianas del Ecuador por ciudad ............. 65
Figura 3.11 Compañías grandes del Ecuador por ciudad ............................. 65
Figura 3.12 Resumen de encuestas realizadas ............................................ 68
Figura 4.1 Flujo de Valor actual para despliegues por proyectos y
habilitación/deshabilitación de funcionalidades............................................. 72
Figura 4.2 Flujo de Valor actual para despliegues o ajustes emergentes y
mejoras internas. .......................................................................................... 72
Figura 4.3 Propuesta de flujo de valor para requerimientos al grupo de control
de cambios.................................................................................................... 74
Figura 4.4 Flujo de valor actual del grupo de Control de Consistencia de
Datos ............................................................................................................ 75
xv
Figura 4.5 Flujo de valor propuesto al grupo de Control de Consistencia de
Datos ............................................................................................................ 76
Figura 4.6 Tiempo real de cada acción del flujo de valor del grupo de Control
de Cambios ................................................................................................... 77
Figura 4.7 Tiempo real de cada acción del flujo de valor del grupo de Control
de Consistencia de datos .............................................................................. 77
Figura 4.8 Tiempo entre acciones del grupo de Control de Cambios ........... 78
Figura 4.9 Tiempo entre acciones del grupo de Control de Consistencia de
Datos ............................................................................................................ 78
Figura 4.10 Ciclos identificados en el flujo de valor del grupo de control de
cambios ........................................................................................................ 79
Figura 4.11 Ciclos identificados en el flujo de valor del grupo de control de
consistencia de datos ................................................................................... 80
Figura 5.1 Grupo Control de cambios ........................................................... 88
Figura 5.2 Tablero General Kanban para el grupo de control de Cambios .. 91
Figura 5.3 Tablero Personal......................................................................... 98
Figura 5.4 Reuniones Kanban .................................................................... 103
Figura 5.5 Requerimientos emergentes (julio 2014 a julio 2015) Valor
referencial para el caso de estudio ............................................................. 105
Figura 5.6 Requerimientos por mejoras Proveedor 1 ................................. 106
Figura 5.7 Unidad de Análisis tamaño empresa, conocimiento KANBAN... 107

xvi
Figura 5.8 Unidad de análisis, esquema de control de tareas, tamaño
empresa ...................................................................................................... 108
Figura 5.9 Unidad de análisis, tamaño de empresa, frecuencia en posponer
tareas .......................................................................................................... 109
Figura 5.10 Unidad de análisis, cargo en empresa, cuellos de botella y/o
recursos sobrecargados ............................................................................. 110
Figura 6.1 Análisis cantidad de pases a producción implementando Kanban
.................................................................................................................... 112
Figura 6.2 Efectividad de pases a producción implementando Kanban...... 113
Figura 6.3 Cantidad de conciliaciones realizadas por tipo. Periodo enero -
julio 2015 - Grupo de control de consistencia de datos .............................. 116
Figura 6.4 Cantidad de conciliaciones mensuales - Grupo Control de
consistencia de datos ................................................................................. 117
Figura 6.5 Reversos de pases a producción. .............................................. 118

xvii
ÍNDICE DE TABLAS
Tabla 1. Cantidad de Empresas según su tamaño ....................................... 64
Tabla 2. Distribución normal estándar .......................................................... 67
Tabla 3. Comparativo Flujo Actual vs. Flujo Propuesto Grupo Control de
Cambios ........................................................................................................ 82
Tabla 4. Comparativo Flujo Actual vs. Flujo Propuesto Grupo control de
consistencia de datos ................................................................................... 85
Tabla 5. Cantidad de pases a producción. ................................................. 112
Tabla 6. Porcentaje de despliegues con error o rechazados. ..................... 114

xviii
INTRODUCCIÓN
En el mercado Ecuatoriano existe un gran número de empresas dedicadas a
las telecomunicaciones, cada una de ellas establece una metodología de
trabajo propia o en el peor de los casos no utilizan ninguna.
El cumplimiento del plan de negocios no solo consiste en crear productos de
calidad, si no de optimizar recursos y costos, las empresas suelen apoyarse
en la metodología de trabajo para poder cumplir con los objetivos propuestos.
Muchas veces las metodologías suelen ser difíciles de implementar por su
complejidad y tiempo, lo que genera el rechazo por parte del grupo de trabajo
que se quiere hacer partícipe.
Otro factor importante son los costos, actualmente las empresas se rigen por
presupuestos asignados por lo cual buscan soluciones que sean eficientes y
de bajo costo, la tendencia actual es utilizar herramientas free que pueden
ser mejoradas internamente.

xix
En consecuencia, las empresas suelen desarrollar herramientas internas que
soporten la metodología de trabajo que utilizan, sin embargo, la utilización de
las mismas es empírica, no se sigue ningún tipo de regla, lo que puede
ocasionar la ineficiencia o no aprovechar el 100% los beneficios que podría
brindar.
Las metodologías de trabajo que se suelen implementar no son dinámicas, lo
cual genera problemas internos, considerando que el segmento de mercado
de telecomunicaciones es de constante cambio y en muchas ocasiones se
requiere cambios emergentes o drásticos que afectan varios factores como
son: recursos, costos, tiempo, calidad.
Por lo antes mencionado, para poder mantenerse en la vanguardia
tecnológica, las empresas deben ser flexibles al cambio, deben contar con
recursos que apoyen a la operativa del negocio y que estén dispuestos a los
retos que implican los cambios.

xx
Por lo expuesto anteriormente es necesario proponer una metodología de
trabajo, considerando que la misma no solo va orientada, como se podría
asumir a grupos de desarrollo, sino a cualquier área o grupo de la empresa,
siempre que se tenga claro lo que se quiere lograr y medir se logrará el éxito
de la misma.
CAPÍTULO 1
GENERALIDADES
1.1 Antecedentes
En el mercado existen varias empresas de telecomunicaciones, las
mismas que para mantener los niveles de servicio requeridos es
necesario que adopten una metodología de trabajo en los
departamentos de TI, para lo cual se propone la implementación de la
metodología KANBAN.
Utilizar esta metodología permitirá de una manera sencilla y en línea
visibilidad de puntos de falla como son: tiempos de respuestas,
cantidad de recursos, falencias actuales, no solo a nivel de proyectos,
sino también requerimientos o tareas sencillas que podrían ser la base
primordial para dar pase a algún proceso interno crítico o relevante, es

2
decir, que esta metodología puede ser usada en varios niveles,
departamentos, empresas.
Por otro lado en el tema de investigación propuesto se enfocará a los
problemas que se tiene actualmente de controlar la integridad de los
aplicativos puestos en producción y de esta forma garantizar la
consistencia de los datos que se maneja dentro del ambiente
productivo en el área de sistemas.
La competitividad que genera el permanecer en la vanguardia de la
tecnología hace que toda la empresa deba alinearse para poder
cumplir los objetivos con la finalidad de producir proyectos exitosos y
que generen valor a la misma, en este punto los departamentos de TI
juegan un papel importante, muchos se preguntarán como podemos
definir un proyecto exitoso? Brevemente podríamos decir que un
proyecto es exitoso si cumple con todas las características solicitadas,
con el presupuesto y con el tiempo programado, la metodología
KANBAN permitirá hacer evaluaciones en cualquier punto de una
tarea, requerimiento o proyecto de tal forma de tener avances a tiempo
lo que permitirá incrementar la calidad, satisfacción al usuario y la
productividad del departamento, asimismo ayudará a no sobrecargar
de tareas a los miembros del equipo.

3
1.2 Descripción del Problema
Por temas de confidencialidad para la elaboración de esta
documentación no se proporcionará el nombre de la empresa de
Telecomunicaciones que ha sido motivación para el tema propuesto.
Debido a la dinámica del tipo de negocio, los procesos que manejan
las empresas de telecomunicaciones y la competitividad que genera el
mercado, se requieren proyectos a corto plazo, muchas veces
sobrepasando el tiempo que ya se tiene proyectado.
Se cuentan con varios proveedores de software los cuales tienen
diferentes metodologías, lo que no garantiza que los entregables
cumplan con el estándar y la calidad que exige el negocio.
La cantidad de proyectos que se maneja es difícil de controlar y hacer
seguimiento puesto que al momento no se dispone de una herramienta
para este propósito.
Los aplicativos de baja calidad desarrollados por los proveedores que
prestan dicho servicio, al pasar a producción tienen deficiencias que
son detectadas muchas veces después de que se cumpla la garantía.
Esta situación genera costos adicionales al tener que contratar
recursos para mejorar los defectos de fábrica, ya sean de la misma
empresa o de algún otro proveedor.

4
La integración entre plataformas no considera esquemas de control de
errores. Es decir cuando ocurre algún tipo de inconveniente, sea este
a nivel de conexión, disminución del servicio, o algún factor externo, el
esquema de rollback no existe o no está bien definido generando
inconsistencia de información.
Las mejoras o actualizaciones sobre los aplicativos implica cambios
riesgosos y efectos colaterales sobre otras plataformas, esto se da
porque existe mucho código extenso y con demasiadas dependencias
que puede afectar el ingreso económico de la empresa.
La herramienta actual “In house” no cumple controles básicos que se
deben realizar a las actualizaciones o creaciones de fuentes en
ambientes de producción.
Los reversos y parches sobre los pases a producción, no cuentan con
estadísticas para determinar eficiencia y calidad de los recursos de un
proveedor.
Por lo anteriormente expuesto el ambiente productivo se ve altamente
comprometido, y este es el motivo por el cual se requiere adoptar una
metodología que si bien es cierto no solucionará todos los problemas
actuales permitirá de aquí en adelante tener un mayor control y calidad
en los nuevos procesos, tareas, proyectos que se implementen.

5
1.3 Solución Propuesta
Al implementar la utilización de metodología KANBAN sobre un área
de Tecnología de Información para el sector empresarial mencionado
anteriormente, se podrán comprobar los siguientes aspectos que se
muestran en la Figura 1.1.
Consistencia de
Metodología datos
KANBAN
Integridad Aplicativos
Figura 1.1 Beneficio Kanban
Con el uso continuo de la Metodología Kanban, se garantizará mayor
control y el incremento de la integridad de los aplicativos lo que traerá
como resultado el incremento de consistencia de datos; con el objeto
de obtener los resultados esperados, la metodología debe ser parte de
la cultura organizacional con la idea que se expanda a toda la
empresa.
Como características de la solución se considera:
Los recursos humanos del negocio y del proceso deben de
trabajar juntos en el transcurso del proyecto.

6
La información más efectiva es la de ida y vuelta, es decir,
cuando se realizan reuniones cara a cara para algún tipo de
levantamiento.
Las arquitecturas, diseños y desarrollos de calidad son originados
de las excelentes auto organizaciones del recurso.
El análisis de la fortaleza, oportunidades, debilidades y amenazas
pueden ser detectados con mayor facilidad.
Los requisitos que normalmente son cambiantes en el transcurso
del tiempo, pueden llegar tarde al desarrollo del proceso pero
adaptándose fácilmente al trabajo que se realiza.
El seguimiento continuo origina un progreso sostenido a los
recursos ya sean estos desarrolladores, usuarios finales,
administradores del proyecto incluso entre áreas, en este caso es
necesario mantener un ritmo constante al mismo nivel.
Es fácil detectar trabajos detenidos o cuellos de botella y de esta
manera analizar la causa y si es necesario realizar cambios en el
proceso.
Es fácil ajustar el tiempo o la carga de trabajo dentro de una
unidad del área de Tecnología.

7
Al involucrar a todo el grupo en la metodología KANBAN
aumentará el compromiso, la efectividad en el desarrollo y
cumplimiento del plan de negocios interno, así mismo, aumentará
la consistencia de los datos entre diferentes plataformas producto
de las mejoras en el control de los cambios en los aplicativos.
1.4 Objetivo General
El objetivo es proporcionar una metodología para controlar la
integridad de los aplicativos colocados en producción del área de
Tecnología de Información para garantizar la consistencia de los datos,
cumpliendo con las expectativas del plan de negocios generando valor
costo-beneficio a corto plazo.
1.5 Objetivos Específicos
Conocer los ambientes de producción, estructura actual del área de
TI y sus unidades.
Hacer el levantamiento de información para identificar la situación y
problemas actuales en el área de producción, relacionadas con la
integridad de los datos y aplicativos.
Analizar y diseñar la mejor alternativa de solución utilizando
Kanban.
8
Implementar la metodología en mención para probar que se cumple
con los objetivos.
Probar y analizar los resultados de la implementación realizada.
1.6 Metodología
Para la realización de esta investigación utilizaremos la metodología
KANBAN, hemos seleccionado la misma por ser fácil de usar,
actualizar y comprender por parte del equipo de trabajo, además de
permitirnos mejorar de manera continua el proceso, dándonos
visibilidad en cada etapa del mismo.
Por otro lado permitirá entregar productos de calidad, puede aplicarse
a cualquier tipo de trabajo, el éxito está en saberlo aplicar
correctamente, identificando las fases y la cantidad de recursos que
deben intervenir en las mismas.
Entre los beneficios generales que nos ofrece se detallan en la figura
1.2.
9
Figura 1.2 Beneficios Generales utilizando

Kanban
Lo anteriormente expuesto será revisado a mayor detalle en el capítulo
2.
CAPÍTULO 2
MARCO TEÓRICO
2.1 Kanban
Kanban es una metodología para la gestión de tareas en el trabajo, es
un proceso evolutivo e incremental de mejoras para Empresas, se
crean estructuras para mejoras basadas en reflexión; es un proceso
empírico, su significado en japonés quiere decir “tarjetas visuales”,
donde Kan es “visual” y Ban significa “tarjeta”. Su origen se debe a los
procesos de producción just-in-time” (JIT), ideados por Toyota, en los
que se usaban tarjetas para identificar las necesidades de material en
la cadena de producción [5].

11
En la actualidad Kanban forma parte de las llamadas Metodologías
Ágiles, no se trata de un método para la gestión del ciclo de vida del
desarrollo de software, se trata de implementar una estructura para
catalizar y gestionar cambios en la Empresa.
2.1.1 Principios de Kanban
Los principios de Kanban son:
Comenzar con lo que actualmente se hace: Kanban no indica
cómo hacer el trabajo ni cómo tiene que trabajar el grupo,
ayudará a visualizar y a decidir de mejor manera la
distribución y la carga del trabajo actual.
Llevar a cabo procesos evolutivos e incrementales: En este
caso el grupo debe alinearse a lo que se quiere conseguir
con Kanban, se podrá visualizar constantemente mejoras en
los procesos de manera incremental y en consecuencia si se
detectan procesos que no funcionan, debe de atacarse para
cambiar dicho proceso o proceder con la mejora o ajustes de
ser necesario.
Inicialmente se deben respetar los roles, responsabilidades y
procesos actuales: Se debe de saber los roles de cada
integrante del equipo, así mismo, cada integrante sabe lo

12
que tiene que realizar, de esta forma se evita la resistencia
al cambio y acoger la iniciativa de introducir Kanban.
Motivar actos de liderazgo a todo nivel: hay que tener
iniciativa, gestionar, y ejecutar correctamente, todas las
tareas son igual de importantes y deberán ser tomadas en
cuenta [4].
Las tareas realizadas son de calidad, se basa en que las
mismas sean finalizadas bien desde la primera vez, de esta
forma se garantiza ahorros al no tener que invertir recursos o
presupuestos por errores que se presenten posteriormente.
Aplicar solo lo que se necesita: utiliza el principio de YAGNI,
You Ain't Gonna Need It, solo se debe agregar funcionalidad
estrictamente necesaria [15]. De esta forma la funcionalidad
básica no se ve afectada.
Flexibilidad, la priorización de las tareas se las realiza
conforme puedan surgir las necesidades, basándonos
siempre en el principio de terminar la tarea en curso o no
afectarla y de no recargar los recursos.
Se debe tomar en cuenta que siempre existen imprevistos y
la propuesta debe ser flexible; no basarse en casos ideales.

13
Establecer políticas explícitas es un punto importante, el
equipo aprende constantemente, para esto se establece una
reunión diaria no más de 15 minutos donde se evalúa el
tablero y cada miembro del equipo debe indicar que está
haciendo, en qué estado se encuentra y si tiene algún
problema que requiera algún tipo de gestión de nivel superior
para avanzar o apoyo de los miembros del equipo [8].
2.1.2 Ventajas de Kanban
Si bien es cierto existen otras metodologías, Kanban es indicado
para empresas que requieren flexibilidad, poder dar prioridad a
las tareas y supervisar los equipos de trabajo, con esta
metodología se espera hacer entregas continuas y de buena
calidad, las ventajas que se logren dependerá en gran parte de
la empresa y la forma como se implemente la misma, a
continuación detallamos algunas ventajas:
Mayor Integridad en el equipo.
Se puede llevar a cabo sin necesidad de un software,
pueden utilizarse post-it y un tablero, es fácil de aplicar.
Mejor visualización de los procesos que generan cuellos de
botellas. (Control del flujo de trabajo).

14
Menor costo de retraso.
Mejor manejo de Riesgo, como se tiene la información de
forma visible a todo el equipo, los puntos críticos pueden ser
remarcados o manejarse de forma diferente de tal forma que
se tenga especial atención a cualquier actividad o problema
que se pueda presentar y no permitir la finalización como se
espera en tiempo y calidad de la tarea.
Mejoras en los tiempos de entrega [11].
Reducción del WIP. Es decir la cantidad de tareas
simultáneas son las necesarias para llevar de la mejor
manera la atención de las mismas.
Incentiva el trabajo en equipo, al presentarse algún problema
todos los miembros del equipo aportan para solución del
mismo.
No existen tiempos perdidos, se hace lo que es necesario y
en caso de liberación de recursos se puede distribuir los
mismos como apoyo a alguna etapa que necesite avanzar
para liberar alguna tarea.

15
2.1.3 Elementos en Kanban
Para aplicar Kanban en un Sistema Productivo se generará un
tablero donde se encuentre las tareas a realizar, deben de
cumplirse los siguientes elementos que se detallan a
continuación:
2.1.3.1 Flujo de trabajo:
Con respecto a este elemento, podemos indicar que el
uso del flujo de trabajo es importante en cualquier
tamaño y tipo de empresa, debido a que
frecuentemente existe desconocimiento de las fases de
un proyecto, las funciones o el trabajo que desempeña
uno de sus integrantes, consiste en crear un tablero
propio que deberá ser accesible a todos los miembros
del equipo. Se podrá agregar columnas en la que se
indicará los diferentes estados que puede pasar una
tarea.
En esta metodología las tareas continúan a la siguiente
etapa una vez que se liberan los recursos.
A continuación un ejemplo sencillo en la Figura 2.1

16
Figura 2.1 Tablero Kanban
Un dato importante es que las tareas se acumulan al
inicio en lo que llamaremos de aquí en adelante como
backlog, estas tareas se priorizan conforme se decida
en las reuniones que se mantenga con los miembros
del equipo.
El tablero puede ser genérico y puede irse actualizando
conforme se detecte mejoras para su seguimiento y
control.
17
Cómo llenar la tarjeta visual?
De igual manera otro elemento importante del tablero es
establecer la información que sea relevante y debe ser
ingresada en la tarjeta, la misma que varía de acuerdo a
la empresa y es configurable según lo que se requiera.
También se le puede asignar colores de tal forma que
se pueda agrupar por prioridad, por grupo o por tipo de
tarea. Con el objeto de visualizar como podría ser una
tarjeta para el caso de estudio que se va a analizar
posteriormente, se detalla a continuación información
mínima que se requiere para la realización de la misma.
Figura 2.2.
Nombre o Código de la tarea
Fecha De Solicitud de la tarea
Fecha de Inicio de atención de la tarea
Fecha Fin de la tarea
Duración
Breve resumen de la tarea

18
Avatar (Recurso que tiene a cargo la tarea)
Grupo o Persona que solicita
Figura 2.2 Tarjeta Visual
Qué es un avatar?
Avatar se conoce como la representación gráfica de
personas reales, en las tarjetas y tableros de Kanban
son muy utilizados y permite de mejor manera conocer
que persona está atendiendo la tarea. La elección del
avatar queda a criterio de cada miembro del equipo
puede elegir cualquier figura o imagen para que lo
represente, estos avatares también deben ser
detallados a un lado del tablero donde se indicará el
nombre de la persona a la que está representando.

19
2.1.3.2 WIP - Limitar el trabajo en curso:
Uno de los pilares fundamentales en el método
KANBAN, es no dejar a media una tarea, se debe
terminar una para empezar con la siguiente.
Un término que se utiliza es WIP (Work in Progress)
que consiste en asignar a cada etapa una cantidad
máxima de tareas en curso, es por este motivo que a
diferencia de otras metodologías como por ejemplo
SCRUM no se puede pasar o a la siguiente etapa si en
la siguiente no hay capacidad de atención [12].
El WIP tiene un gran impacto en la productividad del
equipo, no hay una regla para calcular el mismo puesto
que puede variar acorde a las tareas que se están
realizando sin embargo para calcular por primera vez el
valor podemos usar la siguiente fórmula 2n-1 donde n
es el número de miembros del equipo y el -1 se usa
para calcular el grado de colaboración [6].
Para entender un poco más como funciona esta
asignación, lo explicaremos en base al tablero de la
Figura 2.3.
20
Figura 2.3 Tablero especificando WIP
Como podemos observar la cantidad máxima (WIP) de
tareas simultáneas en la etapa de procesos es 3 y en
pruebas es 2, en este ejemplo podemos mover una
tarea del backlog a la etapa de procesos-en ejecución, y
aunque
Se tiene una tarea en esta etapa en finalizado no podrá
pasar a la siguiente etapa pruebas-en ejecución hasta
que se libere un recurso a finalizado.
Otra forma de representar el WIP son con el Avatars
con los mismos se puede detallar cuales y cuantos
recursos están trabajando en cada etapa, de esta forma
si algún recurso no se encuentra disponible por
cualquier motivo se podrá detectar fácilmente cuales
tareas deberían estar bloqueadas o deberían ser

21
reasignadas en caso de ser necesario, además de
conocer la cantidad real de procesos que se podrán
atender.
En consecuencia como resultado de no limitar el WIP o
no elegirlo correctamente se pueden presentar los
siguientes problemas:
Retraso en los tiempos de entrega.
Incremento en los tiempos del ciclo.
No se logra visibilidad de mejora en el proceso.
Degradación del conocimiento.
Puede caer en el doble trabajo.
Recursos disponibles sin realizar ninguna actividad.
Etapas cuello de botella.
2.1.3.3 Gestión del flujo:
Se debe visualizar el flujo de trabajo de tal forma que se
pueda verificar que cada pieza que lo integra esté
funcionando correctamente, si no lo está solucionarlo de
manera inmediata. El flujo de tareas debe ser continuo

22
no debe haber tiempos perdidos así como tampoco
interrumpir las tareas de los miembros del equipo.
En este punto es necesario hacer mediciones de los
tiempos en que se toma una tarea, hay varias formas de
medir estos tiempos las más comunes son conocidos
como “lead time” que es el tiempo en que se mide
desde que inicia la petición hasta que termina, otra
forma de medir es conocida como “cycle time” que se
mide desde que se comienza a trabajar en la tarea
hasta que termina [2]. Figura 2.4

23
Figura 2.4 Lead Time– Cycle Time
Esta información se la puede trabajar estadísticamente
de tal forma que nos permitirá estimar tiempos y
conocer oportunidades de mejora, por esta razón es
muy importante como se comentó anteriormente la
información que se ingrese en las tarjetas del tablero
del Kanban puesto que serán la base para realizar este
análisis.
24
2.1.3.4 Reglas del proceso:
Para poder aplicar bien el método, debemos entenderlo
a la perfección, es decir:
Conocer quien realiza la tarea.
Se debe conocer que es lo que se espera como
producto final en cada etapa.
Cada tarea en cada etapa debe terminar
correctamente, no se debe pasar a la siguiente
etapa con errores.
Se debe realizar lo estrictamente necesario.
Todo lo que ocurre en las tareas o proyecto debe ser
visible en el tablero, evitando especulaciones.
2.1.3.5 Mejora en equipo:
Al aportar con la experiencia de cada uno de los
integrantes del equipo, se logra una mejora continua
que es otro de los pilares de KANBAN, en este caso es
necesario que todos estén alineados al proceso.

25
Kanban puede aplicarse a cualquier entorno de trabajo,
el problema está en saberlo aplicar y seguir los
principios descritos anteriormente, asignando bien los
recursos, especificando roles, delimitando
correctamente cada fase del tablero, aplicando mejoras
continuas en procesos que pueden ser optimizados y
que puedan repercutir ganancia de tiempo, asimismo,
costo monetario en el proceso que se realice [4].
2.1.4 Implementación de Kanban en 4 Fases
Para poder implementar KANBAN, es necesario pasar por 4
fases las cuales describimos a continuación:
Entrenamiento del personal: Todo el personal involucrado
en el proceso de cambio, debe conocer los principios de
KANBAN y beneficios que se pueden adquirir al momento de
usarlo, por otra parte, es necesario identificar los recursos
multifuncionales que estén comprometidos con la empresa
para que colaboren con la mejora.
Identificación e implementación de procesos o
componentes con problemas: Entorno a lo expuesto
anteriormente, una vez que el personal tenga el
conocimiento de los principios, es necesario, identificar el

26
proceso o componente que tiene problemas, resaltando los
inconvenientes que se tienen y que pueden ser mejorados.
Implementar KANBAN en el resto del recurso humano:
Adoptar una cultura organizacional ayuda al fortalecimiento
de mejoras en los procesos, en efecto, se debe de escuchar
las opiniones de todos los integrantes.
Revisión del sistema KANBAN: Para el correcto
funcionamiento de KANBAN, se recomienda notificar al líder
o supervisor cualquier inconveniente encontrado, así mismo,
ninguna tarea debe de realizarse fuera de secuencia [9].
2.1.5 Herramientas para utilizar Kanban
El método KANBAN cada vez es más popular debido a que
aumenta la productividad, optimiza tareas y gestiona de mejor
manera el trabajo en equipo, en consecuencia se logra no
sobrecargar los recursos, la creación de los tableros
tradicionales fue un gran invento pero cuando se logra entender
cómo funciona es excelente utilizarlos de forma online ya que es
una combinación de lo tradicional con la tecnología, a
continuación detallaremos algunas herramientas que servirán
para implementar esta metodología.

27
TRELLO.- Esta aplicación sirve para crear, administrar,
tableros KANBAN, la aplicación está disponible en web o en
aplicaciones para Android y IPhone, se puede interactuar
entre el grupo de trabajo.
Además de las funciones básicas como crear, modificar, eliminar
columnas/tarjetas, poseen opciones adicionales como agregar
tareas dentro de una misma tarjeta, fechas inicio, fecha fin
de la tarea, adjuntar ficheros, colores, votos, agregar
comentarios, el ambiente de la aplicación es amigable y fácil de
usar entre varios integrantes del tablero [13].
Figura 2.5 Tablero Trello
KANBAN TOOL.- Ayuda a visualizar de mejora manera el
trabajo en equipo utilizando etiquetas de colores en el
tablero online.
28
Así mismo, pueden crearse columnas dependiendo a las fases
del proceso que desee representar, agregar comentarios por
tarjeta y WIP, la aplicación también ofrece proporcionar reportes
estadísticos o de otro tipo de criterio como cargas de trabajo.
Permite crear diferentes tableros dependiendo del área o
proceso que desee plasmar visualmente las fases que
intervienen.
Figura 2.6 Tablero visual con KANBAN TOOL
Figura 2.7 Figura de estadísticas por fase del tablero

29
Existen empresas grandes y pequeñas que al momento utilizan
esta herramienta, a continuación mostraremos algunas de ellas
[7], tal como se muestra en la figura 1.3
Figura 2.8 Empresas que utilizan KANBAN Tool
JIRA es una aplicación web muy robusta, ayuda para el
seguimiento de errores e incidentes, así como también para
la gestión operativa de proyectos lo que incluye la gestión de
tareas. Es muy útil para planificar, se define prioridades y se
puede observar lo que está realizando todo el equipo.
Por otro lado para hacer seguimiento, se crea hito, plazos y
se puede asignar tareas al equipo.

30
Se puede utilizar un flujo de trabajo predefinido o crear uno que
se ajuste a las necesidades de la empresa. A continuación
ejemplos de tablero en Jira.
Figura 2.9 Tablero Jira
2.2 Organización de Tecnología de Información
Dentro de las organizaciones de telecomunicaciones, en las áreas de
tecnología de Información sean las empresas públicas o privadas, se
manejan con una estructura muy similar a la que representan en la
figura 2.10
31
Figura 2.10 Estructura Organizacional en áreas de Tecnología

Información
Fuente: (CNT)
Elaborado por: CNT
2.2.1 Estructura de Proyectos
Las estructuras del departamento de proyectos de las
compañías de Telecomunicaciones tiene una semejanza en sus
diseños por los que separan en dos grupos descriptivos, sean
estos de:
Negocios: Donde desarrollan todo tipo de requerimientos del
Área Comercial.
32
Soporte: Desarrollan todo tipo de requerimiento del Áreas
Financiero y de Recurso Humanos.
Figura 2.11 Estructura de Proyectos
Fuente: Propio
Elaborado por: Propio
2.2.2 Estructura de Gerencia de Sistemas de Información
Dentro de la estructura General de Sistemas de las compañías
de telecomunicaciones se encuentra el área de Sistemas de
Información, la misma que se encuentra conformada por 2
grupos: Área de facturación y Área de producción en horarios
24x7(24 horas, 7 días de la semana).
Área de producción: es clave de toda compañía, esto se debe
a que en la misma se lleva el control de todos los procesos,
módulos, aplicaciones que se encuentran en el ambiente

33
productivo, así también la consistencia de la información entre
las plataformas y de las nuevas funcionalidades que ingresan
para mantener los niveles de servicio requeridos por los entes
reguladores.
Dentro del área de producción existen unidades que atienden
diferentes tipos de requerimientos:
Gestión de Incidentes, Atienden todo tipo de incidentes sean
estos por fallas o inconsistencias que reporta un usuario interno
o externo.
Control de Procesos: Unidad que controla y garantiza el nivel
de disponibilidad de todos los procesos de la compañía.
Control de cambios: Unidad que se encarga de garantizar que
los cambios que se realicen en los aplicativos no afecten el
ambiente productivo, así como también de gestionar y realizar
mejoras en los procesos actuales. Este grupo apoyo a toda el
área de producción.
Administración de recargas: Unidad que controla los procesos
de recargas, así como también todo lo relacionado a los
mismos.
34
Control de Consistencia de datos: Unidad encargada de
garantizar, validar la consistencia de la información entre las
diferentes plataformas, de ser necesario debe tomar acciones de
regularización sobre la misma.
Área de Billing: Encargada de la validación y monitoreo de los
procesos que llevaran a cabo para la facturación de los
diferentes abonados que tiene la compañía, entiéndase abonado
al usuario final que recibe el servicio de voz y datos de toda
compañía de Telecomunicaciones.
Figura 2.12 Estructura de Sistemas de Información Gerencial
Fuente: Propio

35
2.2.3 Estructura de Network – Base de Datos
Dentro de la estructura General de Sistemas de las compañías
de telecomunicaciones se encuentra el área de Networking,
conformado por Redes/Servidores, Base de datos y HelpDesk.
Redes/Servidores: Se encarga del Monitoreo de las redes y
Servidores que son administrados por Sistemas, así mismo tiene
el control de los backup y debe garantizar su correcta
restauración.
Helpdesk: Se encarga del soporte técnico de las pc y de los
aplicativos/utilitarios.
Seguridades: Controla el nivel de acceso a diferentes
plataformas tecnológicas administradas por el departamento.
Base de datos: administra las bases de datos asignadas
controlando disponibilidad y buen funcionamiento.

36
Figura 2.13 Estructura de Network-Base de datos
Fuente: Propio
2.2.4 Estructura de Arquitectura
Área encarga del mejoramiento continuo de la arquitectura de
sistemas, el enfoque de esta área es orientado al servicio,
utilizando marcos de trabajo para optimizar recursos
disminuyendo tiempos de implementación y aumentar la calidad
del trabajo.
Figura 2.14 Estructura de Arquitectura

37
2.2.5 Estructura de Datawarehouse
Área encargada de atender requerimientos internos y externos
como entes reguladores, analizando la información que se
entrega garantizando su calidad.
DIRECCIÓN
DATAWAREHOUSE
Figura 2.15 Estructura de Datawarehouse
2.3 Plataformas de Producción
A nivel general se detalla a continuación las plataformas que utilizan
las empresas de telecomunicaciones y que se pueden ver afectadas
por cambios en el ambiente de producción:
Facturador de Tarifario: Es una base de datos que contiene
información como costos de minutos, planes activos, estados de la
línea con los cuales se basa para realizar la factura al cliente.
Facturador de planes Prepago y planes Controlados: Es una base
de datos que contiene información como costos de minutos, planes
activos, estados del servicio, que permiten hacer los cobros en línea a
los clientes.
38
HLR (home location register, o registro de ubicación base).- Es una
base de datos que almacena y determina el estado del usuario en la
red, así también los distintos features del mismo, cada número se
encuentra situado en un único HLR que administra el operador móvil.
VLR (visitor location register o registro de ubicación de visitante): Es
una base de datos en donde los usuarios se van registrando conforme
se van enganchando en la red, tiene el control para determinar si el
usuario cumple con las condiciones para poder realizar llamadas.
Aplicación Front End Negocios: Sistema para la administración de
los clientes en el mismo se puede atender requerimientos tantos de
usuario final como de usuario interno (Propio de cada operadora)
Aplicación Front End Caja: Sistema para la administración de caja
utilizado en cada centro de atención al cliente (Propio de cada
operadora).
Contenidos - Shortcode: Plataforma que administra los shortcode
que son utilizados para ofrecer contenidos propios de la empresa o
terceros.
USSD.- Menú interactivo que el usuario puede acceder dependiendo
de los servicios que ofrece cada operadora móvil.

39
2.4 Seguridad y accesos de producción
Dentro del área de producción existen mecanismos para controlar los
accesos y la seguridad al ambiente de producción.
Mediante aplicativo in house se ingresan los siguientes tipos de
requerimientos:
Acceso a servidor de producción (este acceso consiste en asignar
una máquina con los permisos para acceder a los equipos de
producción).
Privilegios y Roles de Base de datos.
El custodio de usuarios, claves de Sistemas operativos y de Base
de datos del ambiente de producción es la jefatura de la misma.
Los requerimientos descritos, pueden necesitar ciertos niveles de
autorización (Jefatura de producción) para luego ser atendido y
ejecutado por el ingeniero de producción o el ingeniero asignado
según sea el caso.

40
Figura 2.16 Esquema de Autorización de requerimientos de

seguridad y accesos
Fuente: Propio

CAPÍTULO 3
LEVANTAMIENTO DE INFORMACIÓN
3.1 Arquitectura en ambientes de Producción
Antes de describir la arquitectura general que se tiene en producción,
es necesario conocer que el área de Gerencias de Sistemas de
información tiene como objetivo administrar, controlar, monitorear la
correcta funcionalidad de los procesos que se encuentran en el
ambiente productivo, el área debe de garantizar la operatividad y
efectividad de los mismos.
Como se describió anteriormente en el capítulo 2.2.2, el área tiene
diferentes unidades de apoyo, las mismas que realizan diferentes

42
tareas sobre las plataformas tal como se muestra en la arquitectura en
los ambientes de producción.
Debido al dinamismo de los negocios de telecomunicaciones, los
servicios por diferentes canales de atención deben ser escalables en
todo tipo de segmento de mercado, sin embargo, así como crece la
atención o el servicio al cliente, existe el crecimiento tecnológico dentro
de la empresa que debe cubrir la demanda.
A continuación en la figura 3.1 el esquema actual de la arquitectura de
producción.
Figura 3.1 Arquitectura en Ambiente de Producción

43
Plataforma de Cobro: Como su nombre lo indica tiene la lógica de
Cobro al cliente, de acuerdo a cada requerimiento de consumo que se
presente, manejando costo, expiración, entre otras características
propias de cada servicio de acuerdo al plan contratado, esta
plataforma suele ser administrada con proveedores internacionales;
como política interna de toda empresa controlada por la
Superintendencia de Telecomunicaciones, debe de existir un plan
anual de los trabajos que se van a realizar en las plataformas
definiendo días y horas para los trabajos estimados, los mismos que
deberán ser realizados en horarios de menor impacto hacia el cliente
final y previamente notificados al ente regulador en caso de que el
evento afecte el servicio al cliente [1].
3.2 Incidentes de pases a producción
Para poder dar paso a la revisión de la situación actual de los
incidentes de pases a producción, como información relevante, se
debe de considerar que el grupo de proyectos se encuentra en la fase
inicial de la implementación de la metodología Kanban con resultados
al momento exitosos, por su lado se está difundiendo el uso en las
empresas externas de tal forma que todos estén alineados a la misma
metodología de trabajo.
44
Con este precedente, aunque se está implementando y tomando
acciones previas al realizar un cambio en el ambiente productivo, de
igual forma es necesario tener un control intermedio, puesto que el
área de proyectos no debe ser juez y parte de la revisión, con este
objetivo se creó el grupo llamado “Grupo de Control” el mismo que no
tiene una metodología actual de trabajo.
Por otra parte debemos considerar las actividades que están dentro
del flujo del grupo antes mencionado:
Revisión de los despliegues que son parte de un
proyecto. Ejemplo Figura 3.1
Grupo de Control
•Despliegue Programado de cambios
30/06/2015 •Pase ambiente
•Proyecto Plan de •Revisión de información productivo
negocios •Autorización despliegue.
•Agendamiento de
despliegue
Grupo Proyecto Producción
Figura 3.2 Flujo Actual de despliegues por proyecto

45
Revisión de los despliegues por ajustes o pases emergentes a
producción. Estos ajustes se pueden dar por el reporte de una
afectación de servicio, informe de inconsistencia de datos reportado
por áreas internas o por definiciones no contempladas cuando salió
el proyecto a producción.
En este caso aplica para proyectos que está fuera de garantía.
Ejemplo figura 3.2
Grupo de Control
• Despliegue por Ajuste a de cambios
producción • Pase ambiente productivo
• Afectación de servicio • Revisión de información • Validación Usuario
• Inconsistencia de datos • Autorización, agendamiento • Conciliación en el ambiente
de despliegue productivo
• Solicitud de revisión al grupo
de consistencia de datos
Grupo Proyecto
Producción
para ajustes
Figura 3.3 Flujo actual de despliegues por ajustes o pases

emergentes a producción
Manejo de proveedor para revisión, implementación de mejoras
sobre procesos actuales.

46
Grupo de Control
• Pase ambiente productivo
• Grupo Procesos de cambios
• Grupo Incidentes
• Grupo Consistencia de datos • Revisión de información
• Asignación del requerimiento
• Validación
• Autorización, agendamiento de
despliegue
•.
Inicio
Producción
Requerimiento
Figura 3.4 Flujo actual de requerimiento de mejoras internas de

Producción
Atención de habilitación/deshabilitación de funcionalidades en el
sistema, este tipo de requerimientos es solicitado por personal de
proyectos, generalmente va de la mano con un despliegue
realizado.
47
Grupo de Control
•Ingreso de solicitud de cambios
e habilitación / •Atención de
•Revisión de solicitud
deshabilitación de solicitud
funcionalidad •Asignación de
solicitud
Grupo Proyecto Producción
Figura 3.5 Flujo actual de atención de habilitación/deshabilitación

de funcionalidades
Como se puede observar son varias las actividades y controles que se
debe realizar, en todas las tareas antes mencionadas se utiliza una
herramienta in-house, la misma que actualmente tiene adaptado un
tablero Kanban sencillo para poder hacer seguimiento de los
requerimientos, sin embargo no es utilizado, puesto que como se
indicó anteriormente no se tiene una metodología definida .
Otro grupo importante y que es tema de esta propuesta es el “Grupo
de Control de consistencia de Datos” el cual dentro de sus actividades
está el garantizar que la información que se encuentra entre
plataformas sea consistente, al momento cuenta con muchos de sus

48
procesos automatizados, sin embargo, esto genera que la solución
definitiva del origen de inconsistencias no sea revisada, puesto que no
son reportadas, es por este motivo que ambos grupos deben trabajar
en conjunto, es decir, reportar en este caso al grupo de control o de
ser necesario a proyectos para revisión de los escenarios y que se
genere el análisis respectivo y la solución definitiva.
Una vez que se tiene claro que implica la metodología Kanban, la
estructura organizacional de la empresa y los grupos de producción
que serán objeto de esta propuesta, a continuación se detallará cual es
la situación actual de los problemas que se han detectado hasta el
momento.
3.2.1 Calidad en proveedores
En la actualidad se cuenta con varios proveedores externos que
proporcionan servicios tanto a nivel de desarrollo como
operativo, como es de esperar la calidad en su trabajo afecta
directa e indirectamente a los ambientes productivos. La
metodología de trabajo no es igual a la empleada internamente,
no siempre cumplen con los estándares, lo que no garantiza que
el producto o trabajo final sea lo que se espera y sin defectos.
Por otro lado los recursos no tienen el grado de experiencia que
se requiere ante una empresa donde el ritmo de desarrollo es

49
acelerado por lo que no es posible invertir mucho tiempo en
aprendizaje de los mismos.
3.2.2 Calidad en los despliegues
En consecuencia del punto anterior al tener recursos con poca
experiencia el producto final entregado es de baja calidad, lo
que ocasiona afectaciones de servicios y pérdidas económicas
para la empresa, dependiendo del grado de afectación puede
incurrir en sanciones por el ente regulador.
No se mide los riesgos y los impactos en su totalidad sobre los
despliegues enviados, muchas veces se manejan códigos
demasiados extensos, así como también se envían demasiados
objetos o cambios en una misma petición lo que hace que el
esquema de reverso sea muy complicado, también en caso de
ocurrir alguna eventualidad el seguimiento toma demasiado
tiempo para llegar a una conclusión de reverso o ajuste.
Adicional a esto cuando ocurre un error en un despliegue implica
el tener que solicitar en muchas ocasiones recursos adicionales
para revisión del problema en caso de que el propio
desarrollador no encuentre la solución, esto genera también
carga operativa para el grupo de producción puesto que debe
estar listo para el ajuste respectivo en horarios que no son los

50
asignados para este tipo de actividades, así como también
presupuesto adicional al tener que asignar recursos para las
mismas.
Este presupuesto aumenta cuando el error no es detectado a
tiempo y el proyecto está fuera de garantía.
A continuación una muestra estadística de los despliegues
fallidos vs los realizados con corte hasta junio 2015.
3000 2804
2500 2264
2000
1500
1000 772
210 360 380
500
0
Semestre 1 Semestre 2 Semestre 1
2014 2015
fallida realizada
Figura 3.6 Despliegues fallidos vs despliegues realizados

por año
En el gráfico podemos observar el incremento de un 27,53% en
cantidad de pases del primer semestre del 2014 vs. el primer
semestre del 2015, esto se debe a que siguiendo la metodología
actual se propone que los despliegues no contengan tantos
objetos de tal forma que los mismos sean manejables y fáciles

51
de revisar y en caso de algún problema la detección del error es
más rápida, esto implica que la cantidad de despliegues también
aumente, de esta forma también se espera que la cantidad de
despliegues fallidos baje.
800
Cantidad despliegues
700
600
500
400
300
200
100
0
1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6
2014 2015
fallida 12 24 22 56 58 38 54 92 64 62 48 40 52 36 98 92 44 58
realizada 66 84 100 158 170 194 178 248 716 432 416 274 448 454 490 370 500 542
Figura 3.7 Despliegues fallidos vs despliegues realizados

por mes.
En el gráfico anterior podemos analizar por mes los despliegues
fallidos y poder tomar una acción o establecer un límite máximo
permitido, con los datos anteriores se tiene que el 11% del total
de pases por mes son fallidos.
3.2.3 Disponibilidad de recursos
Otro factor importante es la no disponibilidad de recursos en
general, al no tener el control y conocer lo que está realizando
cada miembro del equipo sea en este caso de producción o de

52
proyectos ocasiona que se asigne requerimientos o tareas a
recursos que están sobrecargados y en el peor de los casos no
disponibles.
En consecuencia, esto genera tiempos perdidos y afectaciones
que pudiendo haber sido atendidas, no son revisadas y menos
aún solucionadas.
Por otra parte el no llevar el control sobre la disponibilidad y
asignaciones que tienen los recursos, también ocasiona que la
misma tarea sea asignada y revisada por varias personas a la
vez, lo que implica pérdida de tiempo, aumento de costos,
desgaste por parte de los recursos y la percepción de la mala
organización que se tiene.
3.3 Políticas de despliegues a Producción
En relación a los despliegues, para detallarlos de mejor manera se los
ha dividido en:
Proyectos grandes: Son de gran impacto en la empresa, el grupo
de trabajo puede ser conformado para varios recursos de diferentes
áreas.
Proyectos pequeños, medianos o tareas específicas: son de
impacto menor y puede intervenir una sola área.

53
Despliegues emergentes los cuales pueden surgir por una
afectación al servicio, por necesidad del negocio, o por solicitudes a
nivel de dirección.
Por otra parte para la realización de despliegues se consideran los
siguientes puntos para dar prioridad a los mismos, en el siguiente
orden:
Despliegues para solucionar afectaciones de servicio.
Despliegues priorizados por la Dirección y la Gerencia.
Despliegues por temas regulatorios u áreas de auditoria.
Despliegues por cumplimiento de plan de negocio
3.3.1 Política de despliegues proyectos y tareas.
A continuación se detalla el flujo que se debe seguir para la
realización del despliegue en producción:
1. Antes de pasar la información a producción, el líder de
proyecto debe actualizar su ambiente para poder realizar las
pruebas y validaciones previas en pre-producción en caso de
que exista el mismo.

54
2. El líder de proyectos debe ingresar la petición y adjuntar el
plan de pruebas y documentación establecida según el caso.
3. La persona asignada de desarrollo validará los cambios y
confirmará al líder que la petición debe seguir el flujo, para lo
cual el líder deberá ingresar la información necesaria en la
petición y autorizar la misma.
4. Se asigna un TRM (Technical Release Manager) el mismo
que se encarga de revisar la petición previamente aprobada
por el líder, valida que cumpla con los formatos establecidos
y lo aprueba o rechaza según sea el caso.
5. Una vez aprobado el líder de proyectos debe revisar su plan
de despliegue y en caso de encontrar algún tipo de novedad
reportar al TRM mediante una solicitud formal, caso contrario
la petición está lista para ser atendida por la persona
asignada en el grupo de producción.
6. El líder de proyectos debe comunicar las posibles
afectaciones, controles o validaciones que se debe realizar
producto del despliegue.

55
7. El líder de proyectos se encargará de notificar la fecha de
agendamiento a los miembros del equipo, así como también
notificar cuando el mismo se encuentre realizado.
8. El agendamiento de peticiones de pases a producción tienen
horario establecido hasta las 18:00, considerando que las
peticiones ingresadas posterior a 14:00 puede ser
desplazado su agendamiento hasta el día siguiente
dependiendo de la cantidad de peticiones que se tenga.
9. El recurso asignado por producción para realizar los
agendamientos debe realizar las siguientes validaciones:
Validar las dependencias de objetos de base de datos, en
caso de que se trate de objetos críticos, el agendamiento
debe realizarse en un horario en que se garantice no
afectar el servicio.
No deberá agendar despliegues en fechas críticas para la
empresa, como son fechas de corte, días de promoción,
fin de semana o feriados, en caso que se requiera debe
validarse las prioridades como se indicó anteriormente,
así como también solicitar autorización a nivel de
gerencia.
56
Validar si el tipo de cambio es de alto riesgo en cuyo caso
deberá especificar para la realización del mismo que es
necesario soporte en sitio, en caso de que no se proceda
de esta manera el recurso asignado para el despliegue
debe rechazar el mismo. La responsabilidad de asignar
los recursos para soporte en sitio es del líder el cual de
ser necesario podría incluirse en esta revisión.
10. El recurso asignado para ejecutar el despliegue por parte de
producción debe conocer cómo proceder en caso que se
requiera realizar algún tipo de reverso.
11. El recurso asignado para ejecutar el despliegue debe realizar
respaldo de los objetos actuales.
12. El recurso asignado para ejecutar el despliegue debe validar
que los objetos que se muestren en la petición concuerden
con la solicitud que se está realizando.
13. Es responsabilidad del recurso que ejecuta el despliegue la
bitacorización de la petición realizada en un archivo creado
para este propósito, así como también cambiar el estado a la
petición la misma que puede quedar en estado atendida-

57
realizada o con error según sea el caso. Al momento no se
cuenta con herramienta automática para bitacorización.
14. El despliegue en caso de que aplique debe de considerar
esquemas de depuración el mismo que debe ser enviado por
el líder.
15. En caso de generarse alguna afectación se realiza un
análisis previo el mismo que indicará la posible solución y de
ser necesario la posible sanción tanto para el líder como para
el proveedor involucrado.
De lo anteriormente expuesto estas serían las políticas
propiamente de la etapa que corresponde al despliegue en
producción, sin embargo se debe considerar que posterior a
esto existe la etapa que es de estabilización y cierre del cambio
el cual también puede incurrir en cambios en el ambiente
productivo, por tal razón brevemente se indicará puntos
importantes que se pueden presentar en estas etapas:
1. Se debe definir el tiempo de estabilización para el cual se
asignarán recursos, los mismos que deberán estar
disponibles en caso que se requiera mejoras o ajustes esto
debe ser establecido por el Líder de sistemas que fue
asignado al cambio.
58
2. Durante el tiempo que se defina se deberá realizar las
verificaciones post-producción para confirmar el correcto
funcionamiento y garantizar que la funcionalidad sea la
esperada.
3. En caso de encontrar novedades que no correspondan al
cambio realizado actualmente el Líder de proyectos deberá
realizar el análisis y comunicar a la gerencia para decidir
cómo proceder, es decir si el mismo líder realiza el ajuste o
se lo asigna al mismo Líder causante de la novedad.
4. Todos los errores deben ser documentados y reportados.
5. Una vez finalizado el periodo de estabilización es
responsabilidad del líder de proyectos el cierre del proyecto
en el mismo debe contar la autorización y confirmación de
todos los miembros del proyecto.
6. El líder de proyecto debe comunicar a la persona
responsable administrativa para dar por cerrado el proyecto,
para liberación de recursos y revisión de presupuesto.
7. La garantía del proyecto se establece en 90 días.

59
3.3.2 Política de despliegues por cambios emergentes
Para los despliegues emergentes se debe considerar lo
siguiente:
1. Los cambios emergentes se dan por reporte de problemas
enviados directamente al área de producción y que están
ocasionando problemas en los aplicativos o causando
perjuicios económicos a la empresa.
2. No es necesario asignar un líder de proyecto, el recurso
asignado para la revisión será el idóneo ya sea por el
expertice que tenga sobre el tema o por estar disponible para
la revisión.
3. Las etapas de cambio emergentes:
Solicitud de cambio emergente
Asignación de recurso de proyecto para análisis y
cambio
Implementación del ajuste
Pruebas del cambio realizado
Puesta a producción
Confirmación de la solución del cambio emergente

60
Como se indicó anteriormente los cambios emergentes tienen
prioridad ante cualquier otro cambio o proyecto, por tal razón si
es necesario se puede disponer de los recursos necesarios para
asignarlos al mismo.
Al igual que en los despliegues por proyectos se debe validar la
etapa de estabilización y cierre de la misma manera que se
indicó en el punto anterior.
En ambos casos una vez que se hace la entrega formal y el
cierre del proyecto el área responsable del monitoreo y de
garantizar la funcionalidad de lo entregado al ambiente
productivo es el área de producción.
Cabe indicar que estas son las políticas actuales, más adelante
en el capítulo 6 para poder llevar un mejor control sobre los
objetos o cambios que se solicitan en el ambiente productivo se
indicará la propuesta de mejora en ciertos puntos, así como
también se incluirá revisiones adicionales que se deberá realizar
en el grupo que es motivo de esta propuesta.

61
3.4 Esquema de conciliación por incidentes ocurridos
Figura 3.8 Esquema de conciliación por incidentes ocurridos
Como se indicó anteriormente en el capítulo 3.2, un grupo importante
dentro del área de producción es el asignado al control de consistencia
de datos el mismo que se encarga de realizar conciliaciones entre las
diferentes plataformas garantizando que la información que se
encuentre en las mismas sea consistente y correcta.
Este grupo realiza revisiones periódicas las mismas que pueden estar
automatizadas o manuales; pueden ser diarias, semanales o

62
mensuales según se requiera. Adicional a esto como se indica en la
figura puede recibir requerimientos emergentes de conciliación de
datos, los mismos que se originan del análisis previo realizado por el
grupo de control de cambios, cuando se detecta que el problema
reportado ha originado inconsistencia de datos, además de canalizar
con personal de proyectos para el respectivo ajuste este grupo
canaliza la conciliación respectiva, de ser necesario la misma debe
repetirse una vez que se confirma que la mejora o ajuste se encuentra
en el ambiente productivo, sin embargo no existe control de
seguimiento en este grupo que garantice la solución definitiva y la
integridad de los datos puesto que estas tareas no se las toma como
propias del grupo, sino que deben ser solicitadas.
3.5 Estudio de mercado sobre Metodología de trabajo
Con el objeto de tener una idea Macro de cómo se encuentran las
áreas de TI en el mercado ecuatoriano, se procedió a recolectar
información relacionada con su metodología de trabajo, para este
propósito se utilizó 1a técnica tipo encuesta que se explica en el
siguiente punto.
3.5.1 Recolección de datos - Encuestas:
Las encuestas sirven para obtener información sobre una
muestra de un universo establecido, que servirá para analizar y

63
estudiar la información recolectada, utilizando cualquier medio
para llegar a individuos o grupos de individuos que integran la
población estudiada [10].
3.5.2 Población Objetivo
Para la propuesta que se está realizando se enfocará la
encuesta a empresas de telecomunicaciones, específicamente
áreas de TI, sin embargo, para realizar un sondeo y/o análisis
del sector empresarial del Ecuador sobre KANBAN el cálculo de
la muestra es tomada del total de empresas activas con
sociedades Anónimas corte año 2012 (último año disponible)
proporcionada por la SUPERINTENDECIA DE COMPAÑIAS
DEL ECUADOR en la sección portal de información / sector
societario, disponible en su página web:
http://appscvs.supercias.gob.ec/portalInformacion/sector_societa
rio.zul el tamaño de la empresa de acuerdo al portal es basado
en los informes financieros.

64
Tabla 1. Cantidad de Empresas según su tamaño
Tamaño de empresas Número de empresas
Pequeña 9464
Mediana 4130
Grandes 1964
Total 15558
Figura 3.9 Total de Compañías pequeñas del Ecuador por ciudad

65
Figura 3.10 Total de compañías medianas del Ecuador por ciudad
Figura 3.11 Compañías grandes del Ecuador por ciudad

66
3.5.3 Cálculo de la muestra
El cálculo de la muestra se realiza en base a una fórmula en la
cual intervienen dos términos. La incógnita es el número de
encuestas que se va a realizar y el término que despeja la
incógnita son los factores que condicionan el tamaño de la
muestra.
Entre estos factores intervienen: El nivel de confianza, medida
de dispersión de datos, costo de unidad de muestreo y tamaño
de la población.
En caso de que se conozca la población se aplica la siguiente
fórmula:
(3.1)
Dónde:
n es el tamaño de la muestra;
Z constante que depende del nivel de confianza que se
establezca, el nivel de confianza es el porcentaje que indica que
las encuestas realizadas son ciertas, un 96% de confianza

67
significa que un 4% de probabilidad pueden estar con
equivocaciones.
Los valores de Z se la obtienen de la tabla de distribución
normal estándar [14]:
Tabla 2. Distribución normal estándar
e es la precisión o el error deseado.
p proporción de individuos que poseen características de
estudios de la población, se suele suponer que p=q=0.5
q proporción de individuos que no poseen esas características:
1-p
N es el tamaño de la población;
68
Se evaluará con el 92% de confiabilidad, el error será del 8%
(0.08)
(3.2)
Esto quiere decir que el tamaño de la muestra es de 119
encuestas (aproximación a la siguiente cantidad entera), sin
embargo se procedió a elaborar 130 encuesta.
Para realizar las encuestas se utilizó plataforma pagada
(http://es.surveymonkey.com), se realizaron 21 preguntas las
mismas que se encuentran detalladas en el Anexo 1.
Figura 3.12 Resumen de encuestas realizadas

69
En el Gráfico anterior, se ilustra el resumen de las encuestas
realizadas por día, se tomó 4 días para realizar la encuesta, fue
orientada a grupos relacionados con áreas de Tecnología de
Información.
CAPÍTULO 4
ANÁLISIS Y DISEÑO DE LA SOLUCIÓN
4.1 Mapas de Flujo de Valor
Los mapas de flujo de valor permiten visualizar los procesos que
intervienen en una actividad desde su inicio hasta obtener el producto
o requerimiento final, en el mismo; se debe definir los tiempos que
dura cada actividad así como también la duración entre la transición de
una a otra, al definir el mapa se puede realizar cambios continuos
detectando también procesos que no generan valor, la idea del flujo es
detallar todos los procesos que intervienen.
Para realizarlo es necesario considerar lo siguiente:
Determinar cuántos tipos de requerimientos se tiene.

71
Realizar el mapa actual
Realizar el mapa que se quiere lograr
Determinar el plan de acción.
4.2 Identificación de acciones del flujo de valor de la Unidades del
Área de producción
En la siguiente propuesta se analizará del área de producción los
grupos que tienen incidencia directa para garantizar la integridad de
los aplicativos y consistencia de datos, se presentan el flujo actual y
las etapas nuevas del flujo propuesto para alcanzar el objetivo
requerido.
4.2.1 Mapa de Flujo de Valor grupo de Control de Cambios
Como se mencionó anteriormente esta unidad tiene varias
tareas a su cargo a continuación en la figura 4.1 y 4.2 se detalla
el flujo actual de las actividades realizadas en este grupo, como
se puede observar en ambos casos es muy básico y solo en los
casos emergentes o de mejoras internas se tiene una acción
adicional que es la de pruebas y monitoreo.

72
Solicitud de
Revision y análisis básico
Requerimiento
Cerrar requerimiento Gestion del requerimiento
Figura 4.1 Flujo de Valor actual para despliegues por proyectos y

habilitación/deshabilitación de funcionalidades.
Solicitud de Revision y análisis Gestion del

Requerimiento básico requerimiento
Cerrar Pruebas y
requerimiento Seguimiento
Figura 4.2 Flujo de Valor actual para despliegues o ajustes

emergentes y mejoras internas.
En la figura 4.3 se puede observar que se ha realizado un ajuste
en la acción que indica revisión y análisis, el mismo que debería

73
ser detallado para garantizar que el requerimiento cumple con
las políticas y las revisiones previas a la solicitud, también se ha
agregado la etapa de autorización o negación del requerimiento;
esta acción debería mantenerse hasta que la metodología
alcance un grado de madurez que permita al flujo continuar sin
la necesidad de un recurso o una validación que autorice el
mismo, adicional se agregó confirmación del requerimiento, este
es un punto importante para poder dar paso a la siguiente
acción de seguimiento y pruebas que no estaba contemplado en
todos los flujos.
En este grupo aunque se tiene varios tipos de requerimientos el
mapa de flujo de valor propuesto es el mismo, esto con la idea
de alinearlos y hacerlos más fácil al grupo de trabajo, puesto
que; al tener varios flujos puede causar confusión en la atención
de los mismos, sin embargo; esto no quiere decir que no exista
la posibilidad de ajustarlos en el camino, tomando en cuenta que
la opinión del equipo es importante y se debe considerar las
sugerencias y opiniones que en su momento reporten.

74
Autorización o
Solicitud de Revision y análisis
negacion del
Requerimiento (detallado)
requerimiento
Confirmación de
Seguimiento y Gestion del
atención del
pruebas requerimiento
requerimiento
Cerrar
requerimiento
Figura 4.3 Propuesta de flujo de valor para requerimientos

al grupo de control de cambios.
4.2.2 Mapa de flujo de valor Grupo de Control de Consistencia de
Datos.
En la actualidad el grupo en mención recibe el requerimiento por
parte de cualquier unidad o de la Jefatura del área, procediendo
directamente con la conciliación o atención de la solicitud, se
propone dos acciones intermedias que consiste en revisar y
analizar la solicitud, identificando si se trata de un requerimiento
por falta de definición Comercial o inconveniente generado por
algún despliegue realizado por parte de la unidad de Control de
Cambios, así mismo, se sugiere crear una siguiente acción de

75
autorización para que la solicitud pueda ser asignada a un
recurso y sea atendida, procediendo a conciliar masivamente tal
como se lo realiza actualmente, en caso de ser recurrente la
solicitud, se desarrolla un proceso automático que concilie las
inconsistencias encontradas, paralelo a esto se dirige la solicitud
de corrección del escenario encontrado al grupo de control de
cambios quien a su vez deberá notificar cuando la corrección se
encuentre en el ambiente productivo, con esta confirmación
debe de existir una última acción de monitoreo hasta que se
certifique que el requerimiento fue solucionado o atendido
correctamente.
Solicitud de Conciliación de Casos

Requerimiento Masivos
Elaboración y
Notifcar el cierre de la
automatizacion de
solicitud
proceso conciliatorio
Figura 4.4 Flujo de valor actual del grupo de Control de

Consistencia de Datos
76
Autorizacion o
Solicitud de
Revision y análisis negacion del
Requerimiento
requerimiento
Elaboración y
Monitoreo de automatizacion de Conciliación de
nuevos casos proceso Casos Masivos
conciliatorio
Notifcar el cierre
de la solicitud
Figura 4.5 Flujo de valor propuesto al grupo de Control de

En estas propuestas se está agregando acciones al flujo con el
fin de que se contemple todos los estados por los que debe
pasar un requerimiento para que se pueda obtener el resultado
esperado y de buena calidad. Esto ayudará a tener mejor
visibilidad y control de lo que se está realizando.
4.3 Cálculo del tiempo real en cada acción del flujo
Con el objeto de visualizar los tiempos en el flujo, se explicará
brevemente en que consiste cada valor, el tiempo en horas que se
detalla dentro de la acción se conoce como hora real, el que se
registra afuera se conoce como hora calendario:

77
Revision y Autorización o
Solicitud de
análisis negación del
Requerimiento
1h 2h (detallado) requerimiento
0.50 h
5h 6h 2h
Confirmación de
atención del
4h requerimiento
1 h 2h
16 h 4h 8h
Cerrar
requerimiento
0.50 h
1h
Figura 4.6 Tiempo real de cada acción del flujo de valor del grupo
de Control de Cambios
Autorizacion o
Solicitud de Revision y
negacion del
Requerimiento análisis
1h 2h requerimiento
0.50 h
8h 4h 5h
Elaboración y
2h 4 h conciliatorio 2h
16 h 8h 8h
Notifcar el cierre
de la solicitud
0.50 h
1h
Figura 4.7 Tiempo real de cada acción del flujo de valor del
grupo de Control de Consistencia de datos
78
Los tiempos indicados son propuestos ya sea por SLA entre áreas o
grupos o por ser los tiempos estimados que en la actualidad se tiene.
4.4 Identificar el tiempo entre acciones del flujo
Solicitud de
Requerimiento
1h 2h (detallado) requerimiento
0.50 h
6h 0.50 h
5h 6h 2h 0.50 h
Confirmación de
atención del
4h requerimiento
1 h 72 h 2h
1 h
16 h 4h
1 h 8h
Cerrar
requerimiento
0.50 h
1h
Figura 4.8 Tiempo entre acciones del grupo de Control de Cambios
Autorizacion o
Solicitud de Revision y
negacion del
Requerimiento análisis
1h 1h 2h 0.25 h
requerimiento
0.50 h
4h 5h
8h
2h
Elaboración y
2hh 1h 4 h conciliatorio 3h 2h
16 h 8h 8h
0.50 h
Notifcar el cierre
de la solicitud
0.50 h
1hh
Figura 4.9 Tiempo entre acciones del grupo de Control de

79
Al igual que en el punto anterior los tiempos entre acciones son los
propuestos para este análisis y los que se tiene actualmente en estos
grupos.
4.5 Identificar Ciclos
Solicitud de
Requerimiento
1h 2 (detallado)
h requerimiento
0.50 h
6h 0.50 h
5h 6h 2h
0.50 h
Confirmación de
atención del
requerimiento
4h 72 h
1 h 1 h 2h
16 h 1 h 4h 8h
Cerrar
requerimiento
15% (1X)
0.50 h
1h
Figura 4.10 Ciclos identificados en el flujo de valor del grupo de

control de cambios
80
Autorizacion o
Solicitud de
Revision y análisis negacion del
Requerimiento
1h 1h 2h requerimiento
0.25 h 0.08 h
8h 4h
5h
Elaboración y
Monitoreo de Conciliación de
automatizacion de
nuevos casos proceso conciliatorio Casos Masivos
2h 1h 4h 3h 2h
16 h 8h
0.08 h 8h
15% (1X)
Notifcar el cierre
de la solicitud
0.08 h
1h
Figura 4.11 Ciclos identificados en el flujo de valor del grupo de

control de consistencia de datos
Un punto importante es la identificación de los ciclos puesto que de
esta forma se tiene identificado acciones que podrían influir en el
proceso y ser cuellos de botella posteriormente si no se define un
límite en las iteraciones del ciclo.
4.6 Cálculo de eficiencia del ciclo
(4.1) [11]
81
(4.2) t valor agregado = ∑ horas reales
(4.3) t ciclo total = ∑ horas calendario + ∑ horas de transición + ∑
Cálculo de los ciclos
((∑ horas calendario + ∑ horas de transición) *

(4.4) Cálculo de los ciclos =
% de ocurrencia * No. repeticiones del
ciclo)
cambios
Tomando en consideración los tiempos especificados en cada
acción que se representa en el flujo de valor y de acuerdo a la
fórmula indicada con anterioridad, se procede a calcular la
eficiencia del proceso:
1+2+0.5+4+1+2+0.5
(4.5) EP =
5+6+6+0.5+2+0.5+8+72+4+1+16+((16+1+4+72+8)*0.15*
1)+1+1
11
EP = = 7.96%
138.15
82
Analizando este resultado se puede expresar que el flujo del
grupo de control de cambio considerando los ciclos es 7.96%
eficiente, es decir que se debe trabajar en varios puntos del
proceso para eliminar tiempos de desperdicio así como también
procesos que no generan valor y deben ser evaluados.
Con el objeto de validar el efecto de agregar acciones al
proceso, a continuación se muestra un comparativo del flujo
actual vs. El flujo propuesto sin considerar ciclos.
Tabla 3. Comparativo Flujo Actual vs. Flujo Propuesto

Grupo Control de Cambios
T T T T
T real calendario transición T real calendario transición
Solicitud de
Requerimiento 1 5 6 1 5 6
Revisión y Análisis
Básico 2 6 0,5 2 6 0,5
Autorización o negación
del requerimiento 0 0 0 0,5 2 0,5
Gestión del
Requerimiento 2 8 72 2 2 72
Confirmación de
atención del
requerimiento 0 0 0 1 4 1
Seguimiento y pruebas 0 0 0 4 16 1
Cerrar requerimiento 0,5 1 0 0,5 1 0
Tiempo Total (horas): 5,5 20 78,5 11 36 81
EFA: 6% EFP: 9%
En el cuadro anterior se puede observar, que la propuesta inicial
implica el aumento en tiempo real y el tiempo calendario, esto es

83
consecuencia de las revisiones adicionales propias de cada
etapa del proceso que en la actualidad no se están realizando,
sin embargo a futuro servirán para mitigar falencias en los
resultados que se espera en cada etapa.
Una vez que la metodología se encuentre estable y madura en
el grupo, estos tiempos deben optimizarse y poder actuar con
mayor celeridad sobre todo en los casos emergentes, tomando
en cuenta también que se puede evaluar la eliminación de
alguna etapa que no genera valor en el proceso.
Por otro lado, se puede evidenciar que la eficiencia subió 3%
aunque como se indicó anteriormente el tiempo real total se
incrementó, este es el costo para lograr un resultado de buena
calidad que es el objetivo que se espera actualmente.
consistencia de datos
Tomando en consideración los tiempos especificados en cada
acción que se representa en el flujo de valor y de acuerdo ha la
formula indicada con anterioridad, se procede a calcular la
eficiencia del proceso:

84
1+2+0.08+2+4+2+0.08
(4.6) EP =
8+1+4+0.25+5+8+3+8+1+16+((16+1+8+3+8)*0.15*1)
+0.08+1
11.16
EP = = 18,37%
60.73
Se puede expresar en el cálculo realizado, que el grupo de
consistencia de datos es 18.37% eficiente al igual que el grupo
anterior se deben evaluar acciones y procesos de mejoras,
aunque se puede evidenciar que este grupo está siendo más
eficiente con su tiempo.
Al igual que con el grupo de Control de cambios, con el objeto
de validar el efecto de agregar acciones al proceso, a
continuación se muestra un comparativo del flujo actual vs. El
flujo propuesto sin considerar ciclos del grupo de control de
consistencia de datos.
85
Tabla 4. Comparativo Flujo Actual vs. Flujo Propuesto

Grupo control de consistencia de datos
T T T T T T
real calendario transición real calendario transición
Solicitud de requerimiento 1 8 1 1 8 1
Revisión y análisis 0 0 0 2 4 0,25
Autorización o negación
del requerimiento 0 0 0 0,5 5 2
Conciliación de Casos
Masivos 2 8 3 2 8 3
Elaboración y
automatización del
proceso conciliatorio 4 8 1 4 8 1
Monitoreo de nuevos
casos 0 0 0 2 16 0,5
Notificar el cierre de la
solicitud 0,5 1 0 0,5 1 0
Tiempo Total (horas): 7,5 25 5 12 50 7,75
EFA: 25% EFP: 21%
En el cuadro anterior se muestra que la eficiencia de este grupo
es relativamente buena, sin embargo se agregó etapas que se
consideran deben ser parte de las revisiones o actividades de
este equipo y que servirán para garantizar la consistencia de
datos que es la función principal del mismo.
En consecuencia de esto, se puede evidenciar que la eficiencia
disminuye un 4% esto se debe a que existían acciones que
aunque generan valor no habían sido tomadas en cuenta, como
se indicó anteriormente estos flujos deben ser revisados y
analizados, y de acuerdo a los resultados se debe tomar

86
acciones y optimizar tiempos, recursos, etapas según sea el
caso.
CAPÍTULO 5
IMPLEMENTACIÓN Y PRUEBAS DE KANBAN
5.1 Implementación de Kanban
A continuación se detallará los pasos para implementar Kanban en los
grupos de producción que son temas de esta propuesta (Control de
cambios y Control de consistencia de datos):
1. Se debe realizar el entrenamiento del personal, involucrar a todo el
grupo en este proceso de cambio, todos deben conocer el beneficio
que se tendrá a corto y mediano plazo, deben sentirse parte de
este proceso. Por otro lado es necesario conocer los recursos que
son multifuncionales, los mismos que deben estar involucrados en
todas las etapas de este proceso de cambio. En la siguiente figura

88
se muestra el grupo que va a intervenir en esta primera etapa, con
el fin de poder determinar la cantidad de personas que se debe
trabajar internas y externas.
Supervisor
Interno (1)
Ingenieros
Internos (2)
Ingenieros
Externos
(5)
Figura 5.1 Grupo Control de cambios
2. Conocer los principios de Kanban una vez que se los tiene claro, es
necesario identificar los procesos con problemas para buscar la
solución o mejora en los mismos, ver capítulo 2.

89
3. La implementación de Kanban no debe limitarse a los grupos de
trabajo antes expuestos, la idea es que esta metodología sea parte
de la cultura organizacional de la empresa y por tanto todos los
integrantes puedan aportar ideas de mejora para tener éxito en
este proceso.
4. En cada grupo de trabajo existe un ingeniero asignado como líder o
supervisor que será la persona encargada de receptar cualquier
inconveniente que reporte el grupo, y mantener el control de que
los cambios realizados están cumpliendo los objetivos que se
espera, así como también identificar tareas que no se estén
ejecutando en secuencia.
5.2 Generación de tableros para unidad responsable del control de
los aplicativos en producción
De lo expuesto en capítulos anteriores, se ha procedido a elaborar el
tablero que será de uso general para todo el grupo de control de
cambios, el mismo que tiene relación a los procesos que fueron
previamente establecidos cuando se elaboró el flujo de valor del grupo
en mención. Capítulo 4, figura 4.5.
Como se puede observar en la figura a continuación, se ha manejado
post it de colores, los que nos servirán para identificar de mejor
manera el recurso vs. El proveedor asignado, esta es una opción

90
particular de cada empresa o grupo, es decir; la decisión de manejar
post it de colores es propia y puede ir cambiando conforme vaya
madurando el uso de la metodología.
Por otro lado se ha usado avatar para identificar a los recursos que
integran el grupo, esta es una forma rápida de visualizar por ejemplo,
recursos sobrecargados, libres o cuellos de botella.

91
Figura 5.2 Tablero General Kanban para el grupo de control de

Cambios
92
A continuación se explicará detalladamente el tablero anterior. Se ha
dividido el mismo en columnas y filas:
Detalle de columnas:
Back Log: En esta columna se ingresan los requerimientos
conforme se van receptando, para que la atención de los mismos
se la realice en orden de llegada, esto no quiere decir que no se
puede cambiar el orden de atención en caso de requerir priorizar se
puede pasar cualquier tarea a la columna que indica asignar o
inicio dependiendo de la criticidad de la misma.
Inicio: Se ingresará los requerimientos listos para ser atendidos,
permanecerán en esta etapa hasta que se libere el proceso que
sigue. Se ha definido un wip de 6.
Asignar: En esta columna se ingresará los requerimientos
priorizados por la gerencia/jefatura/supervisor, a estos
requerimientos se les dará un post it de un color diferente para que
puedan ser identificados de mejor manera. Se ha definido un wip
de 3.
En Proceso: En esta columna registran las tareas que ya están
asignadas y en revisión, se ha definido un wip de (5) para todo el

93
proceso, considerando que no existe recursos adicionales para
cada sub-etapa. Esta columna se subdivide en:
o En ejecución: Si la tarea puede ser realizada directamente
continuará en la misma, hasta ser finalizada, caso contrario
pasará a revisión y análisis.
o En revisión y análisis: En esta etapa si es una tarea
directamente del grupo se revisará en su totalidad en la
misma, caso contrario puede pasar a la sección Investigar
o En espera.
o Finalizado: La tarea permanecerá en esta etapa si es que la
etapa siguiente no tiene recursos disponibles.
Investigar: Son tareas sobre las cuales se tienen dudas o no se
tiene conocimiento de cómo proceder, por lo que se necesita
consultar o validar con otros grupos de la empresa. Se ha definido
un wip de 4.
En espera: Como se indicó en capítulos anteriores dentro del grupo
de control se tienen tareas que involucran intervención por parte de
personal de proyectos, en general las tareas que se ubican en esta
etapa corresponden a ese tipo de requerimientos. Se ha definido un
wip de 7, el mismo que podría parecer alto, sin embargo se debe

94
considerar que en esta etapa intervienen recursos adicionales de
proyectos y por parte del grupo de control se libera la tarea a la
espera de la atención, es decir que el recurso de control puede
atender otras tareas en ese momento.
En Pruebas: al igual que en la etapa anterior se ha divido en sub
etapas y se ha definido un wip de 5.
o Validaciones Internas: Consiste en validaciones realizadas
directamente en sistemas.
o Validaciones Externas: Consiste en validaciones realizadas
que involucran otras áreas de la empresa.
Finalizado: Son las tareas que han pasado por el flujo, han sido
validadas y cumplido con todas las revisiones para considerarse
una tarea exitosa.
Detalle de filas:
Se pueden visualizar 5 filas:
La primera corresponde a los nombres propiamente de las etapas.
La segunda se detalla los casos en que existan sub etapas.
La tercera registran las tareas

95
La fila que indica recurrente consiste en registrar las tareas que son
cotidianas de cada recurso.
La fila que indica emergente son las tareas que tienen prioridad
sobre cualquier otra y generalmente se generan cuando se reporta
una afectación de servicio.
Detalle de los avatares:
En la parte inferior del tablero se han colocado los avatar, en los
mismos se indica el recurso al que se está haciendo referencia.
Se debe tomar en cuenta que en la generación de este tablero no se
ha considerado los recursos de los proveedores, puesto que los
mismos tienen asignado un recurso interno que es responsable de sus
tareas, el seguimiento de las mismas se lo realizará de dos maneras:
ingresando dentro de la tarjeta visual o post it un campo donde se lo
pueda identificar y elaborando un tablero personal por cada recurso
interno.
5.2.1 Tarjeta Visual definida para el grupo de control de cambios
A continuación se indicará como elaborar la tarjeta visual para el
grupo de control de cambios, así como también la elaboración
de un tablero personal.
96
Para este grupo se estableció que la tarjeta visual debía
contener la siguiente información, la misma que debe ser
relevante y que sirva posteriormente para poder realizar análisis
y tomar decisiones, con las mismas se podrá determinar tareas
fuera de tiempo, tareas con demasiado tiempo de espera,
recursos sobrecargados, etc.
Fecha Duración (h):
Solicitud:
Fecha Inicio:
Fecha Fin:
Código del requerimiento:
Resumen:
Solicitante: Avatar
Externo:
Avatar Interno:
SMR
JSO
Fecha De Solicitud de la tarea
Fecha de Inicio de atención de la tarea
Fecha Fin de la tarea
Duración se la medirá en horas.

97
Código del requerimiento.
Breve resumen de la tarea
Solicitante, corresponde a grupo o persona que solicita.
Avatar Externo, recurso que tiene a cargo la tarea. En la
parte inferior se detalla las siglas del mismo. Ej: Jimmy
Sornoza --- JSO
Avatar Interno, recurso responsable de la gestión,
seguimiento y finalización de la tarea, al igual que el caso
anterior en la parte inferior se ingresa las siglas del recurso.
5.2.2 Tablero personal
En la figura a continuación un ejemplo de tablero personal, es
menos elaborado que el grupal y es de uso de cada recurso, con
el mismo se puede llevar el control de las tareas propias y
además hacer seguimiento y control de recursos que tenga bajo
su cargo.
98
Figura 5.3 Tablero Personal
5.3 Generación de nuevas políticas para unidad responsable del
control de los aplicativos en producción
Adicional a las políticas ya establecidas en el punto 3.3 se ha
considerado agregar las siguientes políticas para realizar cambios o
ajustes de aplicativo en producción.
Para el grupo de control de cambios se establece las siguientes
revisiones:
99
Solicitar toda la documentación necesaria para la revisión del
proyecto o cambio a realizar, en los mismos deben incluirse
posibles escenarios de errores, plan de pruebas, manual de
usuario, etc.
Establecer un estándar en lo que se refiere a creación de
directorios para los procesos-aplicaciones, se debe proyectar
desde el inicio el espacio para filesystem.
Todo proyecto debe tener esquema incluido de depuración de logs
y de tablas - House Keeping caso contrario debe ser rechazado.
Se emitirá un formato para revisión de los Shell pasados a
producción en el mismo se indicará a manera de check lo que se
debe revisar, este mismo formato será proporcionado al grupo de
proyectos para que lo validen previo a un despliegue que soliciten a
producción.
No permitir envío de configuraciones de procesos a nivel de Jobs
de base de datos.
Dependiendo de la cantidad de veces que se debe ejecutar algún
proceso este grupo debe validar si el mismo debe ser configurado
por crontab, como demonio, en el aplicativo para este propósito.

100
A nivel de base de datos las tablas deben ser creadas con sus
respectivos comentarios.
No permitir despliegues de repositorios que ya tienen líder
asignado si no cuenta con la revisión y autorización del mismo.
Despliegues relacionados con conciliaciones o informes deben
venir con la revisión del grupo de control de consistencia de datos.
Para los puntos expuestos anteriormente se elaborará un cheklist que
deberá ser revisado por el recurso asignado para agendamiento de
despliegues, el mismo que será su soporte de revisión y es parte del
proceso de revisión y análisis cuando el requerimiento se encuentra en
la etapa de ejecución.
Para el grupo de proyectos se establece las siguientes revisiones:
Para proyectos que involucren procesos, se debe definir esquema
de reproceso masivos y puntuales.
Implementar alarmas, deben indicar como proceder, es decir a
quien reportar, que acciones tomar. Estas alarmas deben estar
estandarizadas y centralizadas para monitoreo de servicios,
procesos, colas.
101
Definir responsables del cambio, es decir asignar un administrador
o persona responsable del mismo, personal del grupo de control de
procesos debe asumir el control del monitoreo una vez aprobado el
cambio.
Establecer mínimo 6 meses de garantía en la que el proveedor
deberá hacerse responsable de ajustes o cambios por posibles
errores o deficiencias encontradas.
En los logs de errores se debe indicar si hay problemas de
conectividad, falta de espacio en Filesystem, encolamiento de
transacciones.
Se debe proporcionar esquema de QC centralizados para
garantizar que la información procesada sea correcta y no se
genere inconsistencias.
Incluir auditorías en procesos críticos.
Proporcionar procesos test con los cuales se pueden validar
escenarios básicos sobre las implementaciones realizadas.
Establecer SLA de atención para los despliegues emergentes en
máximo 7 días, para los casos de afectaciones de servicio la
solución debe ser el mismo día del reporte.

102
Establecer SLA de atención para los despliegues de mejoras de 15
a 30 días máximo.
5.4 Plan de pruebas
5.4.1 Unidad de análisis - Grupo de control cambios
Para la realización de esta propuesta se realizó un esquema
piloto, que consistió en los siguientes pasos para poder analizar
y validar los beneficios que se obtendría al implementar la
metodología Kanban en el grupo de control de cambios.
• Se realizaron reuniones con el grupo interno para explicar e
introducir la metodología.
• Se implementó el tablero el mismo que registra en la figura
5.2 para esto se involucró al grupo de trabajo, se recomienda
que el tablero sea ubicado en el área donde todos los
involucrados tengan acceso, puedan revisar y hacer
seguimiento a lo que ocurre en el mismo.

103
Las tareas que se ingresaron para seguimiento inicial fueron
las relacionadas con despliegues por afectaciones y
despliegues por mejoras, los despliegues por proyectos se
los ingresó como una tarea recurrente para una revisión
posterior.
• Se realizaron reuniones diarias no más de 15 minutos en la
que se debía revisar el estado de las tareas, así como
también, cada integrante del grupo debía exponer que fue lo
que había realizado el día anterior, lo que iba a realizar el día
actual y si tenía una tarea pendiente que necesitaba algún
tipo de gestión por parte del supervisor o jefatura.
Figura 5.4 Reuniones Kanban

104
Como resultado de lo indicado anteriormente se pudo
determinar:
• Cuello de botella en las revisiones previas para realizar
despliegues emergentes, no se estaba cumpliendo los
acuerdos de servicio establecidos entre el grupo de control
de cambios vs. El personal de proyectos. En el gráfico a
continuación se detalla la cantidad de requerimientos que
llegaron desde julio de 2014, de un total de 99, registran
atendidos 72 lo que implica un porcentaje de atención de
72,72%, aunque este porcentaje es alto el tiempo que se
tardó en atender los mismos no cumplió con los acuerdos
establecidos.
105
Total
Total
72
72,72 % de atención
13
6 5
2 1
asignada atendida cerrada en analisis nueva reabierta
Figura 5.5 Requerimientos emergentes (julio 2014 a julio

2015) Valor referencial para el caso de estudio
• Falta de compromiso y de involucramiento por parte de otras
áreas de la empresa, esto se lo podía evidenciar en la etapa
de pruebas externas al no recibir respuesta por parte de los
interesados.
• Cuello de botella en despliegues por mejoras, por la falta de
experiencia del proveedor asignado, lo que implicaba no
cumplir con los tiempos y el resultado del producto final no
era lo esperado, generando problemas en el ambiente
productivo. En el gráfico a continuación se puede observar
que existe un problema de atención por el proveedor 1 que
fue el asignado a la revisión de estos requerimientos.

106
Total
Total
3
16,66 % de atención
1 1 1
asignada cerrada en analisis nueva
Figura 5.6 Requerimientos por mejoras Proveedor 1
(Julio 2014 a julio 2015)
Valor referencial para el caso de estudio
De un total de 6 requerimientos en un periodo de 1 año solo se
dio por cerrada una tarea, y adicional 3 en etapa de revisión y
análisis, basados en este resultado se realizó una evaluación al
proveedor y se detectó que no se estaba cumpliendo en los
avances, los objetivos solicitados internamente, lo que generó
acciones administrativas.
5.4.2 Unidad de análisis - Encuesta áreas de TI en el mercado
ecuatoriano.
Como complemento a lo analizado anteriormente, dentro del
plan de pruebas incluimos resultados que fueron recolectados

107
en la encuesta que se mencionó en el capítulo 3, en la misma se
puede evidenciar las falencias que existen en un gran número
de empresas y que podrían reducirse al acoger una metodología
de trabajo, que en este caso la propuesta es KANBAN.
Se procedió a cuantificar por el tamaño de la empresa si tiene
conocimiento de KANBAN, el resultado de desconocimiento de
la misma fue de un 76.92% en empresas pequeñas, el 68.75%
en empresas medianas y el 73.08% en empresas grandes, solo
el 27.08% del total de encuestados sin importar su tamaño tiene
conocimiento de la metodología.
Figura 5.7 Unidad de Análisis tamaño empresa, conocimiento

KANBAN.
108
De acuerdo al tamaño de la empresa el uso de herramientas
para control de tareas, fue de 54.09%, esto incluye el poder
generar reportes estadísticos, es decir que existe un 45.91%
promedio de empresas que no posee una herramienta de control
(48.15% empresas pequeñas, 56.25% empresas medianas,
33.33% empresas grandes).
Figura 5.8 Unidad de análisis, esquema de control de tareas,

tamaño empresa
109
Un punto importante a evaluar es el porcentaje de tareas que se
posponen en la empresa, En general es muy común pospones
las tareas para empezar otra, con este precedente se pudo
confirmar la frecuencia con la que lo hacen y se determinó que:
Casi siempre un 7.75%, usualmente un 20.16%, a veces
35.66%, rara vez 27.91%, casi nunca 8.53%.
Figura 5.9 Unidad de análisis, tamaño de empresa, frecuencia en

posponer tareas
110
Tal como se describe en la siguiente figura, se puede visualizar
que: El 39.60% con perfil Operativo/Técnico, 14.85% con perfil
Supervisor/Senior, 4.95% con perfil de jefatura, 7.92% Gerencia,
1.98 % Directores, 30.69% Otros Perfiles, es decir, el 78.91%
globalizado, no tienen una herramienta o metodología que
ayude a identificar los recursos sobrecargados y/o cuellos de
botellas.
El 21.09% si tiene una herramienta, su mayor porcentaje son
herramientas realizadas dentro de la empresa.
Figura 5.10 Unidad de análisis, cargo en empresa, cuellos

de botella y/o recursos sobrecargados
CAPÍTULO 6
ANÁLISIS DE RESULTADOS
6.1 Análisis de cantidad de pases a producción al implementar
Kanban.
Como resultado de la implementación de la metodología, se analizará
a continuación el comportamiento de la cantidad de pases o
despliegues a producción que se realizaron antes de utilizar la misma,
así como también cual fue el cambio posteriormente.
Para la realización de este análisis se ha considerado evaluar un rango
desde enero 2014 hasta mayo del 2015, por confidencialidad los datos
han sido ajustados para el caso de estudio, sin afectar el beneficio que
se quiere mostrar.
112
Tabla 5. Cantidad de pases a producción.
Año Periodo Total

2014 enero a julio 774
2014 agosto a 1014
diciembre
2015 enero a mayo 1534
400
350
300 Antes Después
250
200
352
150 296 312 309
245 265
100 190 197 216 166
144
50 116 112 127
87 86 102
0
1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5
2014 2015
Total
Figura 6.1 Análisis cantidad de pases a producción implementando

Kanban
Como se puede observar la tendencia de cantidad de pases es
ascendente a partir de la implementación de Kanban, este sería el
comportamiento esperado dado que la metodología Kanban
considerada también parte de las metodologías ágiles, impulsa a que
se realicen ajustes de menor tamaño de tal forma que todo el flujo de
trabajo sea manejable y fácil de revisar, esto implica que los

113
despliegues actualmente manuales, sean enviados con pocos objetos
para garantizar de esta forma que la revisión a realizar en la etapa del
grupo de control sea eficiente y de esta forma minimizar las
afectaciones en ambientes productivos por la no revisión de cada
requerimiento que llega al grupo, así como también las inconsistencias
a nivel de datos que se puede generar por permitir el ingreso al
ambiente productivo de despliegues no validados.
6.2 Análisis de efectividad de pases a producción al implementar
Kanban.
Por otro lado para este punto se realizará un comparativo entre el año
2014 vs. 2015 considerando como meses de estudio de enero a mayo.
120
96
100
80
60
41 42
40 29
20
0
2014 2015
Error en despliegue Rechazada grupo control
Figura 6.2 Efectividad de pases a producción implementando Kanban

114
Considerando los siguientes valores referenciales para este análisis:
Tabla 6. Porcentaje de despliegues con error o rechazados.
Año Periodo Total %Error en % Rechazados

Requerimientos despliegue por grupo de
control
2014 Enero a 503 5,77% 8,15%
mayo
2015 Enero a 1534 2,74% 6,26%
mayo
El porcentaje de errores en despliegues disminuyó considerablemente
vs. el mismo periodo del año anterior, considerando también que la
cantidad total de requerimientos fue 3 veces mayor en este año, esto
nos confirma que el flujo de valor creado para este proceso, está
cumpliendo con el objetivo de minimizar las afectaciones que se puede
ocasionar por pases fallidos.
Por otro lado el porcentaje de rechazos por parte del grupo de control
aumentó, lo que indica que se está realizando revisiones de un mayor
número de requerimientos y tiene relación directa a que en el punto
anterior la cantidad de despliegues fallidos disminuya. La idea no es
aumentar la cantidad de requerimientos rechazados sino instruir a
todos los grupos relacionados a una metodología de trabajo y al
cumplimiento de las reglas y políticas que se establecen en la misma.

115
6.3 Análisis de inconsistencia de datos por pases mal realizados.
Como se expuso en el capítulo 3.2 y 3.4 el grupo de control de
consistencia de datos tiene procesos diarios, semanales o mensuales,
al tener mecanismos de corrección ya sea manual o automática,
origina que la detección de inconsistencias por pases mal realizados
se pierda con otros escenarios o problemas, como pueden ser:
Encolamiento de procesos, falla con plataformas externas, falta de
definición comercial, entre otros,
Sin embargo, para tener visibilidad de la cantidad de correcciones que
se ejecutan y poder tomar algún tipo de acción sobre el origen que
genera el tener que ejecutar este tipo de validaciones, se realizó el
análisis con las tareas de este tipo de un solo recurso del grupo, en el
periodo de enero a julio del 2015.

116
40
35
35
30
25
20
15
10 8
5
0
FIJA REQUERIMIENTO
Total
Figura 6.3 Cantidad de conciliaciones realizadas por tipo. Periodo enero

- julio 2015 - Grupo de control de consistencia de datos
En el gráfico anterior se detalla que se tiene 35 tipos de conciliaciones
fijas que va en aumento y 8 bajo requerimiento que pueden disminuir o
aumentar en el tiempo.
Como se indicó anteriormente, de la cantidad especificada no se
puede tener el detalle de lo que origina este tipo de inconsistencias,
sin embargo sí confirma que se debe tomar acciones y realizar
mejoras en el proceso actual de este grupo para poder dar solución
definitiva a estas inconsistencias, como se indica en el capítulo 3.4 y
4.6.2.
117
Enero Febrero Marzo Abril Mayo Junio Julio
130
122 119
110 113 110
98
17 16
7 11 10
6 6
Periódica REQUERIMIENTOS
Figura 6.4 Cantidad de conciliaciones mensuales - Grupo Control de

consistencia de datos
Con respecto al gráfico anterior, hemos dividido la atención en 2
grupos: Periódica que consiste en las conciliaciones que se realizaron
por mes de las diferentes inconsistencias detectadas, y requerimientos
que consiste en solicitudes especiales realizadas, generalmente en
este grupo se incluyen los requerimientos por afectaciones originadas
por pases mal realizados, o solicitudes internas o de otras áreas, la
propuesta actual sería crear un tablero para el grupo de control de
consistencia de datos donde se pueda controlar este tipo de
requerimientos, siguiendo el flujo de valor que se creó para este grupo
en el capítulo 4.2.2.
118
6.4 Estadística de reversos de pases a producción.
A continuación se ha realizado la estadística de reversos para el
periodo comprendido de julio de 2014 a mayo 2015, la tendencia debe
ser que este tipo de reversos no ocurra.
12 11
10
10 9
8 7 7
6 6
6 5
4
4 3
2 1
0
7 8 9 10 11 12 1 2 3 4 5
2014 2015
Total
Figura 6.5 Reversos de pases a producción.
Año Periodo Total %Reversos

2014 julio a 1158 3,88%
diciembre
2015 enero a mayo 1534 1,56%
Considerando que en el periodo evaluado del 2014 se tuvo una
cantidad total de 1158 requerimientos, gráfico 13, el porcentaje fue de
3,88 % de reversos, para el 2015 la cantidad total fue de 1534 lo que

119
implica un 1,56% de reversos. Es decir que tenemos un 2,32 % menos
de reversos hasta la fecha del análisis.

120
CONCLUSIONES Y RECOMENDACIONES
Conclusiones
1. La metodología Kanban nos ofrece de una forma sencilla la mejora
continua de cualquier tipo de proceso, como se indicó en el capítulo 2.1.1.
permite el cambio evolutivo, conforme se detectan defectos en el proceso,
se debe proceder con la mejora, su efectividad se debe a la visibilidad del
estado real del proyecto, que es representado en el tablero, lo que
permite detectar problemas de forma temprana, capítulo 5.2
2. Se motiva el trabajo en equipo y el liderazgo, al realizar reuniones diarias
se involucra a todo el equipo de trabajo, de tal forma que todos sean parte
de la solución a los problemas dando ideas de mejora, así como también
de ser necesario solicitar apoyo de niveles superiores, agilitando y
mejorando los tiempos de respuesta.

121
3. Ayuda a planificar, por su flexibilidad se puede ajustar el flujo de valor
acorde a la experiencia que se va adquiriendo y a las lecciones
aprendidas durante el proceso, las reglas a seguir como se indicó en el
capítulo 2.1.3.4 son sencillas y fáciles, las mismas que en ocasiones se
las realiza de manera intuitiva, la idea de esta propuesta es que sean
formalizadas y utilizadas dentro de cualquier tipo de proceso.
4. Incluso el método Kanban más básico producirá un aumento en el
rendimiento, esto se puede demostrar con el tablero personal que se
indicó en el capítulo 5.2.2 este tablero es efectivo para tener control de
una manera sencilla y poder hacer seguimiento a las tareas.
Recomendaciones
1. Al iniciar con esta propuesta para que la misma sea exitosa se debe tener
disciplina, seguir los lineamientos establecidos, los mismos que no deben
realizar cambios muy drásticos para que sean eficientes.
2. Debe haber comunicación, si el líder asignado no comunica se pierde el
objetivo de las reuniones que se realiza, las mismas que no deben durar
más de 15 minutos, es necesario que se indique si se tiene algún tipo de
bloqueo que no permita realizar la tarea que se tiene asignado, si se tiene
alguna sugerencia de mejora en el flujo de valor se comparte a todo el
equipo.
122
3. Definir el WIP de tal forma que se terminen más requerimientos en menos
tiempo y con mejor calidad, el líder debe saber cómo negociar, de tal
forma que no permita que se asignen tareas que no corresponden al
grupo de trabajo, tareas fuera de tiempo, así como también cambios de
prioridad de las mismas.
4. Se sugiere establecer desde el inicio cuales son las tareas que van a ser
ingresadas en el tablero, queda a criterio del grupo si lo definen por
ejemplo: por criticidad, por tiempo que demora en tención del
requerimiento, etc.
123
BIBLIOGRAFÍA
[1] Agencia de Regulación y Control de Telecomunicaciones. (s.f.). Arcotel,
Proyecto Manual de Interrupciones, www.arcotel.gob.ec/wp-
content/uploads/downloads/2014/03/Proyecto-Manual-de-Interrupciones-28-
03-2014.docx , Recuperado el 08 de 07 de 2015.
[2] Silva Alejandro, Kanban, http://slides.com/alejandrosilva/kanban#/7,
Recuperado el 23 de 06 de 2015.
[3] CNT. (s.f.). soy.cnt.com.ec., Estructura CNT enero 2012,
http://soy.cnt.com.ec/pdfs/comunicados/estructura_enero_2012.pdf,
[4] Empresarios en red. (s.f.), Método de producción japonés Kanban.,
https://www.empresariosenred.cl/noticias/conoce-el-metodo-de-produccion-
japones-kanban , Recuperado el 20 de 03 de 2015.
[5] Hypertextual. (s.f.), Aplicaciones para usar Kanban,
http://hipertextual.com/archivo/2014/08/aplicaciones-para-usar-kanban/,
[6] Lean from the Trenches, Managing Large-Scale Projects with Kanban,
http://www.amazon.es/gp/product/1934356859/ref=as_li_tf_tl?ie=UTF8&tag=
wwwjaviergarz-
124
21&linkCode=as2&camp=3626&creative=24790&creativeASIN=1934356859,
[7] Kanbantool. (s.f.). Kanban tool., Tablero Kanban,
http://kanbantool.com/es/tablero-kanban, Recuperado el 20 de 03 de 2015.
[8] Lean Agile Machine. (s.f.), Kanban,
http://leanagilemachine.blogspot.com/p/kanban.html, Recuperado el 22 de 06
de 2015.
[9] Lean Solutions. (s.f.), Conceptos Kanban,
http://www.leansolutions.co/conceptos/kanban/, Recuperado el 21 de 06 de
2015.
[10] Editorial Pax-México, Herramienta para elaborar tesis e investigación
socioeducativas. (s.f.), https://books.google.com.ec/books?id=i339_F3C1RIC
&printsec=frontcover&hl=es#v=onepage&q&f=false, Recuperado el 26 de 07
de 2015.
[11] Maeda Masa K., Kanban, http://www.valueinnova.com/, Recuperado el
20 de 03 de 2015.
[12] PERSONAL KANBAN. (s.f.), Limitación del WIP,
http://www.personalkanban.com/pk/primers/the-basics-of-limiting-wip-why-
limit-wip-series-post-1/#sthash.Bbe2MjeY.wdatlPFV.dpbs, Recuperado el 18
de 06 de 2015.
125
[13] Pymes y Autonomos, Gestión de proyecto Trello,
http://www.pymesyautonomos.com/tecnologia/trello-la-gestion-de-proyectos-
en-equipo-mas-simple, Recuperado el 18 de 06 de 2015.
[14] Solís, Lic. Salvador Elías Rodríguez, Obtención del Tamaño de la
muestra, http://www.monografias.com/trabajos60/tamano-muestra-
archivistica/tamano-muestra-archivistica2.shtml, Recuperado el 26 de 07 de
2015.
[15] Wikipedia, Concepto YAGNI, https://es.wikipedia.org/wiki/YAGNI,
126
ANEXOS
Anexo 1: Encuesta Metodologia de Trabajo

127
128
129
Anexo 2: Resultados estadísticos de encuestas realizadas

130
131
132
133
134
135
136
137
138

Escuela Superior Politécnica Del Litoral: Tesis de Grado "

Cargado por

Copyright:

Formatos disponibles

Escuela Superior Politécnica Del Litoral: Tesis de Grado "

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Escuela Superior Politécnica Del Litoral: Tesis de Grado "

Cargado por

Copyright:

Formatos disponibles

ESCUELA SUPERIOR POLITÉCNICA DEL LITORAL

Facultad de Ingeniería en Electricidad y Computación

“IMPLEMENTACIÓN DE LA METODOLOGÍA KANBAN PARA CONTROLAR

Previa a la obtención del Título de:

MAGISTER EN SISTEMAS DE INFORMACIÓN

SYLVIA VERÓNICA MOREIRA NÚÑEZ

A nuestra familia, compañeros y

amigos por el apoyo directo e

incondicional que nos brindaron, por

los consejos y/o experiencias

compartidas que nos sirvieron de

guía para moldear nuestro trabajo.

A Dios por bendecirnos y darnos la

oportunidad de haber culminado un

escalón más en nuestra vida

A nuestra familia, a nuestros hijos

Naomi, Isaac y Ghislaine, inculcando

ejemplo, trabajo, humildad y

perseverancia, dejando nuestra

mayor herencia a la sociedad;

MG. Lenín Freire.

MG. Ronny Santana E.

MG. Fausto Correa

“La responsabilidad del contenido de este documento de tópico, nos

corresponde; y el patrimonio intelectual de la misma a la ESCUELA

SUPERIOR POLITÉCNICA DEL LITORAL”

(Reglamento de Graduación de la ESPOL)

Ing. Sylvia Verónica Moreira Núñez

Ing. Jimmy Ignacio Sornoza Moreira

El siguiente documento está orientado a la implementación de una

Metodología de trabajo existente en el mercado mundial llamada KANBAN

aplicándola en áreas de Tecnologías de información en compañías de

Telecomunicaciones, ayudará a controlar la integridad de los aplicativos y de

esta forma también garantizar la consistencia de los datos, como su historia

lo muestra, sus primeros pasos e implementaciones empezaron en una

fábrica de automóviles llamada Toyota, pero se ha demostrado que es una

metodología que sirve en cualquier área de trabajo, indiferente de la actividad

Para la elaboración de esta propuesta se detallara la problemática, objetivos,

y las reglas para utilizar la metodología de trabajo, describiendo información

relevante y esquemas de conciliación del área. Se generaron tableros,

estableciendo nuevas políticas que se van encontrando al momento de

aplicar conceptos, así mismo, se analiza la información recolectada en la

encuesta realizada en el tercer capítulo, se prueba que existe un gran

segmento de mercado dentro de las compañías del Ecuador que no conoce

la metodología KANBAN y que pueden obtener muchos beneficios en

logística y reducir costo económico, que impacta el presupuesto del área de

Tecnología o del área que solicita algún requerimiento.

En el sexto capítulo se analizan los resultados obtenidos al implementar la

metodología propuesta, mostrando estadísticas sobre los beneficios que nos

brinda la metodología aplicada.

TRIBUNAL DE SUSTENTACIÓN .................................................................. iii

DECLARACIÓN EXPRESA ........................................................................... iv

ÍNDICE GENERAL ........................................................................................ vii

ABREVIATURAS Y SIMBOLOGÍA ............................................................... xii

ÍNDICE DE FIGURAS .................................................................................. xiii

ÍNDICE DE TABLAS ................................................................................... xvii

INTRODUCCIÓN ....................................................................................... xviii

1.1 Antecedentes ..................................................................................... 1

1.2 Descripción del Problema .................................................................. 3