Instrumentos de control para la gestión integrada de la tecnología de la información

Universidad Tecnológica Nacional Regional Córdoba – Dirección de Posgrado

Manuel Teigeiro Tesis Página - 1 -

Maestría en Ingeniería en Calidad

Tesis

“Instrumentos de control para la gestión integrada de la tecnología de la información

como área de servicio interno en una empresa del sector electrónico”

Autor: Ing. Manuel Mariano Teigeiro Director: Ing. Álvaro Ruiz de Mendarozqueta Co-Director: Esp. Ing. Ricardo Rezzónico



Integrantes del Tribunal de Tesis Dra. Mónica Balzarini Magister Lucía Pawluk Dr. Claudio Gabriel Ochoa

Córdoba, Junio 2009



A mi familia, amigos y todos aquellos que supieron esperarme y apoyarme en tiempos difíciles; reforzando mi convicción de que, luego de toda tormenta, deviene la paz y la tranquilidad. Para ellos, junto con los que he aprendido a disfrutar lo que la vida nos

brinda cada día, el presente, tratando de ser más humanos en nuestro mundo. Aprendiendo que de nada sirve ser luz si no vas a iluminar el camino de los demás.



Agradecimientos

Principalmente a Ricardo, mi co-director de tesis, que siempre me ayudó de diferentes formas, transfiriendo su experiencia y conocimiento, aplicando su espíritu crítico y dedicando tiempo para enriquecer mis borradores. Del mismo modo, a mi director, Álvaro, que orientó mi trabajo, aportando distintos puntos de vista. A Diego Rubio, por evacuar dudas estadísticas y consultas relacionadas. A las personas que me acompañaron durante mi carrera profesional, y a las empresas que me brindaron la oportunidad de desarrollarme; sin olvidar a mis amigos y compañeros de trabajo, con quienes comparto casi la mitad de mis días. Por último, y sobre todo, a mi familia, que me ha dado la fuerza para terminar esta tesis, tan postergada por el trabajo diario.



I. Nota preliminar aclaratoria La mayoría de las referencias técnicas y terminología en tecnología de la información (Information Technology, IT) se encuentran en idioma inglés, y de ese modo la utilizan las empresas habitualmente. Por lo tanto, la documentación de soporte, tanto de los productos relacionados como de las comunidades de usuarios, se halla en ese idioma. En otras palabras, la adopción de la terminología inglesa, en el ámbito de la IT, está totalmente diseminada. Esto permite un lenguaje genérico e inequívoco dentro de este área, dado que, de otra forma se dificultaría encontrar términos, en el idioma nativo, que representen con exactitud su verdadero significado. Por lo dicho, en el siguiente trabajo se usarán reiteradamente los términos originales -diferenciados en estilo cursivo-, aclarando el significado y siglas correspondientes entre paréntesis. Y por otro lado, la mayoría de las tablas y gráficos, que dan sostén a los respectivos planteos y conclusiones, así como los apéndices, que tienen por objeto mostrar fielmente diferentes tipos de reportes, se hallan en tal idioma. También el programa de cálculo estadístico utilizado en esta tesis es el ―Minitab v. 15‖ estaba disponible solo en inglés para el uso con licencia; resultando sus gráficos y referencias en el mismo idioma.



CONTENIDO

I. NOTA PRELIMINAR ACLARATORIA .............................................................................. 5

II. ABREVIATURAS Y SIGNIFICADOS .............................................................................. 18 III. INTRODUCCIÓN ...................................................................................................... 19

PARTE I MARCO DE TRABAJO ......................................................................................................... 26

1. DEFINICIÓN DEL MARCO DE TRABAJO .......................................................................... 26 1.1. Metodología Six Sigma .......................................................................................... 27

1.1.1. Clases de proyectos de Six Sigma (DMAIC, DMADV, DMADDD) ................. 27 1.1.2. Fases de un proyecto DMAIC........................................................................ 28

1.1.3. Relaciones entre DMAIC y PDCA ................................................................. 30 1.1.4. Ciclo de vida de un proyecto DMAIC ............................................................. 31

1.1.5. Listado de herramientas para Six Sigma ....................................................... 32 1.2. Tablero de control balanceado ............................................................................... 34

1.2.1. ¿Qué es un tablero de control balanceado? .................................................. 34

1.2.2. ¿Por qué se necesitan las métricas? ............................................................. 36 1.3. Objetivos de control para la información y tecnología relacionada ........................ 38

1.3.1. Relaciones entre ISACA, CObIT y COSO ..................................................... 38

1.3.2. CObIT como marco de referencia ................................................................. 40 1.3.3. La información gerencial en CObIT ............................................................... 40

1.3.4. Factores críticos del gobierno de IT .............................................................. 42 1.3.5. Estados de madurez del modelo de CObIT ................................................... 45

1.3.6. Marco de trabajo de CObIT ........................................................................... 46 1.3.7. Procesos de CObIT ....................................................................................... 49

1.4. Librerías de infraestructura de la tecnología de la información .............................. 52

1.4.1. Gerenciamiento de servicios de IT ................................................................ 52 1.4.2. Soporte de servicios ...................................................................................... 54

1.4.2.1. Gestión de incidentes ........................................................................ 55 1.4.2.2. Gestión de problemas ........................................................................ 55

1.4.2.3. Gestión de cambios ........................................................................... 56 1.4.2.4. Gestión de nuevas versiones de Hw y Sw ......................................... 56

1.4.2.5. Gestión de configuraciones ............................................................... 57 1.4.3. Entrega de servicios ...................................................................................... 58

1.4.3.1. Gestión de nivel de servicios ............................................................. 59 1.4.3.2. Gestión de disponibilidad ................................................................... 59

1.4.3.3. Gestión financiera de los servicios de IT ........................................... 60



1.4.3.4. Gestión de la capacidad .................................................................... 61 1.4.3.5. Gestión de la continuidad del negocio de IT ...................................... 62

1.4.4. Gestión de la seguridad de IT........................................................................ 62 1.5. Cómo implementar mejor CObIT, ITIL e ISO 17799 .............................................. 64

1.5.1. Alineación con las mejores prácticas ............................................................. 64 1.6. Introducción a CMMI .............................................................................................. 65

1.6.1. Beneficios de la mejora del proceso con CMMI............................................. 65

1.6.2. Representaciones de CMMI .......................................................................... 67 1.6.3. Mapeo de CMMI y CObIT a alto nivel ............................................................ 69

1.7. Relevamiento de la situación actual ....................................................................... 72

1.7.1. Tareas realizadas durante el relevamiento ...................................................... 72 1.7.2. Escenario actual............................................................................................... 73

1.7.3. Beneficios de operar sobre un marco de trabajo.............................................. 74 1.7.4. Importancia de las métricas ............................................................................. 75

PARTE II

PROYECTO DMAIC. FASES ............................................................................................... 77

2. DEFINICIÓN DE OPORTUNIDADES ................................................................................ 77

2.1. Voz del cliente ............................................................................................... 78 2.2. Definiciones útiles de la terminología usada.................................................. 80

2.3. SIPOC ........................................................................................................... 81 2.4. Estatutos del grupo ........................................................................................ 83

3. MEDICIÓN DE LA PERFORMANCE O ACTUACIÓN ............................................................ 84

3.1. Indicadores principales .................................................................................. 85 3.2. Entradas y salidas del proceso ...................................................................... 87

3.3. Matriz de causa-efecto .................................................................................. 87 3.4. Plan de medición ........................................................................................... 88

3.5. Análisis del sistema de medición ................................................................... 89 3.6. Servicios, tiempo de resolución (horas) y variables ....................................... 90

3.6.1. Gráficos de valores individuales – Estadísticas ................................. 90 3.6.2. Gráficos de cajas y bigotes – Estadísticas ......................................... 93

3.6.3. Resumen – Estadísticas ................................................................... 96 3.6.4. Gráficos de comportamiento – Estadísticas ....................................... 98

3.6.5. Gráficos de Pareto – Estadísticas .................................................... 100 3.7. Problemas, tiempo de resolución (horas) y variables .................................. 113

3.7.1. Gráficos de valores individuales - Estadísticas ................................ 113 3.7.2. Gráficos de cajas - Estadísticas ....................................................... 115

3.7.3. Resumen - Estadísticas ................................................................... 117 3.7.4. Gráficos de comportamiento - Estadísticas ..................................... 119

3.7.5. Gráficos de Pareto - Estadísticas .................................................... 121



4. ANÁLISIS DE OPORTUNIDADES ................................................................................. 134 4.1. Bases y definiciones para tickets de servicios y problemas ........................ 135 4.1.1. Análisis del tiempo de resolución de servicios - 2007 ................................. 135

Normalización, datos de servicios - 2007 ....................................................... 141 4.1.2. Análisis del tiempo de resolución de servicios - 2006 ................................. 144

4.1.2.1. Normalización, datos de servicios - 2006 ........................................ 145 4.1.3. Análisis del tiempo de resolución de servicios - 2005 ................................. 149

4.1.3.1. Normalización, datos de servicios - 2005 ....................................... 151 4.1.4. Análisis de variabilidad de servicios – 2005 a 2007 .................................... 156

4.1.4.1. Variabilidad - ANAVA – 2005 a 2007 ............................................... 157 4.1.4.2. Variabilidad - ANAVA – 2005 y 2007 ............................................... 162

4.1.5. Análisis del tiempo de resolución de problemas - 2007 ............................... 163 4.1.5.1. Tratamiento de distribuciones no normales ..................................... 165

4.1.5.2. Transformadas de Johnson ............................................................. 166 4.1.5.3. Transformadas seleccionadas para el análisis ................................ 167

4.1.5.4. Normalización, datos de problemas - 2007 ...................................... 168 4.1.5.5. Normalización, datos de problemas - 2006 ...................................... 172

4.1.5.6. Normalización, datos de problemas - 2005 ...................................... 178 4.1.6. Análisis de variabilidad de problemas – 2005 a 2007 .................................. 185

4.1.7. Análisis de variabilidad de problemas – 2006 y 2007 .................................. 188 4.1.8. Factores y efectos principales en la media (Servicios) ................................ 190

4.1.9. Interacciones de variables o efectos, sus relaciones (Servicios) ................. 194 4.1.10. Gráficos de intervalos de media (95%) vs. variables por año ...................... 198

4.1.11. Análisis de variabilidad de problemas (RT) vs miembros de TI - 2005 ........ 201 4.1.12. Análisis de variabilidad RT Problemas vs de perfil del ticket – 2005 ........... 204

4.1.13. Análisis de variabilidad de Media de problemas vs miembros TI 2007 ....... 213 4.1.14. Análisis de variabilidad de Problemas (RT) vs perfil del ticket - 2007 ......... 217

4.1.15. Conclusiones del análisis de variabilidad de factores por año .................... 222 4.2. Conclusiones de la fase de análisis de oportunidades ................................ 223

5. MEJORA DE LA PERFORMANCE O ACTUACIÓN ............................................................ 225

5.1. Proceso de mejora de 7 pasos (ITIL V3) ..................................................... 227 5.2. Compromiso de decisiones basadas en datos (Six Sigma) ......................... 230

5.2.1. Diferentes métodos de toma de decisiones ................................................. 230 5.3. Aplicación de indicadores para medición y análisis (SEI-CMMI) ................. 232

5.3.1. Errores frecuentes en los planes de medición ............................................. 232 5.3.2. Guía o plantilla de un indicador según SEI - CMMI ..................................... 234

5.4. Medición del desempeño organizacional (BS - CMMI) ................................ 235 5.4.1. Plan de desempeño de indicadores (Measurement Plan – MP) .................. 238

5.4.2. Formato sugerido para el cálculo de un indicador ....................................... 238 5.4.3. Ejemplos de representación de un indicador o métrica ............................... 240

5.5. ¿Por qué usar un tablero de control (dashboard) para los indicadores? ..... 262 5.5.1. Ejemplos de representación de indicadores en un dashboard .................... 264

5.6. Resumen de la etapa de mejora de la performance o actuación................. 265 6. CONTROL DE LA PERFORMANCE ............................................................................... 268

6.1. Fases y salidas del control del desempeño o performance ......................... 269

6.2. Elementos de un plan de implementación ................................................... 269



6.2.1. Análisis de problemas potenciales .............................................................. 269 6.2.2. Procedimientos y estándares ...................................................................... 270 6.2.3. Sistema de control estadístico de procesos (SPC) ...................................... 271

6.2.4. Plan de entrenamiento y comunicación ....................................................... 274 6.3. Cierre del proyecto y reconocimiento .......................................................... 274

IV. COMENTARIOS FINALES ........................................................................................ 275

V. BIBLIOGRAFÍA ...................................................................................................... 278 VI. APÉNDICES.......................................................................................................... 283



ÍNDICE DE TABLAS

Tabla 1.1.2-1 Pasos a seguir en las distintas etapas del proceso DMAIC ................................. 29

Tabla 1.1.5-1 Herramientas de Six Sigma utilizadas en distintas fases del proyecto ................. 32

Tabla 2.4-1 Estatuto del grupo .................................................................................................. 83

Tabla 4.1.1-1 Test de bondad de ajuste ...................................................................................140

Tabla 4.1.1.1-1 Análisis estadístico descriptivo (RT). Servicios 2007 .......................................141



Tabla 4.1.4.1-1 ANOVA – Media de Servicios vs. Año 2005 al 2007 ......................................158

Tabla 4.1.4.2-1 ANOVA – Media de Servicios vs. Año 2005 y 2007 ........................................162

Tabla 4.1.6-1 ANOVA – Media de problemas vs. Año 2005 al 2007 .........................................185

Tabla 4.1.7-1 ANOVA – Media de problemas vs. Año 2006 y 2007 ..........................................188

Tabla 4.1.11-1 ANOVA – Media de problemas vs. Miembros de TI 2005 .................................201

Tabla 4.1.12-1 ANOVA – Media de problemas vs. Perfil de tickets 2005 ..................................204

Tabla 4.1.13-1 ANOVA – Media de problemas vs. Miembros de TI 2007 .................................213

Tabla 4.1.14-1 ANOVA – Media de problemas vs. Perfil de tickets 2007 ..................................217

Tabla 5.4.3-1 Métrica: Encuesta de satisfacción al cliente por incidentes .................................240

Tabla 5.4.3-2 Métrica: Costo de la no calidad ..........................................................................243

Tabla 5.4.3-3 Métrica: Costo de la calidad ................................................................................245

Tabla 5.4.3-4 Métrica: Esfuerzo de entrenamiento ...................................................................248

Tabla 5.4.3-5 Métrica: Tiempo de remoción de vulnerabilidades e incidentes de seguridad .....250

Tabla 5.4.3-6 Métrica: Tiempo de resolución de incidentes en IT .............................................254

Tabla 5.4.3-7 Métrica: Gastos financieros reales vs. presupuestados ......................................260



ÍNDICE DE GRÁFICOS

Gráfico 1.1.1-1 Procesos de DMAIC, DMADDD y DMADV ........................................................ 28

Gráfico 1.1.3-1 Representación gráfica de DMAICS – PDCA .................................................... 30

Gráfico 1.1.4-1 Ciclo de vida de un proyecto de DMAIC ............................................................ 31

Gráfico 1.2.1-1 Factores claves y visión estratégica organizacional .......................................... 35

Gráfico 1.3.3-1 Información gerencial ........................................................................................ 42

Gráfico 1.3.4-1 Factores críticos del gobierno de IT .................................................................. 43

Gráfico 1.3.4-2 Relaciones de los componentes de CObIT ....................................................... 44

Gráfico 1.3.5-1 Representación gráfica de los modelos de madurez ......................................... 46

Gráfico 1.3.6-1 El cubo de CObIT.............................................................................................. 47

Gráfico 1.3.6-2 Marco de trabajo de CObIT ............................................................................... 48

Gráfico 1.3.7-1 Estándares y su relación con IT ........................................................................ 50

Gráfico 1.4.1-1 ITIL. Proceso de gerenciamiento de servicios ................................................... 53

Gráfico 1.4.1-2 Representación de la versión 3 de ITIL ............................................................. 53

Gráfico 1.4.2.1-1 Gestión de incidentes de ITIL ......................................................................... 55

Gráfico 1.4.2.2-1 Gestión de problemas de ITIL ........................................................................ 55

Gráfico 1.4.2.3-1Gestión de cambios de ITIL ............................................................................ 56

Gráfico 1.4.2.4-1Gestión de nuevas versiones (Hw & Sw) de ITIL ............................................. 57

Gráfico 1.4.2.5-1 Gestión de configuraciones de ITIL (CMDB) .................................................. 57

Gráfico 1.4.3-1 Gestión de servicios de entrega o pedidos de ITIL ............................................ 58

Gráfico 1.4.3.1-1Gestión de nivel de servicios de ITIL ............................................................... 59

Gráfico 1.4.3.2-1 Gestión de disponibilidad de ITIL ................................................................... 60

Gráfico 1.4.3.4-1 Gestión de capacidad de ITIL......................................................................... 61

Gráfico 1.4.3.5-1 Gestión de la continuidad de servicios de ITIL .............................................. 62

Gráfico 1.4.4-1 Gestión de la seguridad de ITIL ........................................................................ 63

Gráfico 1.6.1-1 Evolución del modelo CMM ............................................................................... 66

Gráfico 1.6.2-1 Objetivos genéricos requeridos por CMMI......................................................... 68

Gráfico 1.6.2-2 Prácticas requeridas por nivel de madurez de CMMI ........................................ 69

Gráfico 1.6.3-1 Prácticas requeridas por nivel de madurez de CMMI ........................................ 70

Gráfico 2-1 Definir oportunidades .............................................................................................. 78

Gráfico 2.3-1 Diagrama de SIPOC ............................................................................................ 82

Gráfico 3-1 Medición de la performance .................................................................................... 84

Gráfico 3.3-1 Matriz causa-efecto de entradas - salidas ............................................................ 87

Gráfico 3.4-1 Plan de medición ................................................................................................. 89

Gráfico 3.6.1-1 Valores individuales (RT) por mes – Servicios 2007 ......................................... 91





Gráfico 3.6.2-1 Gráfico de Cajas de Tickets (RT) por mes – Servicios 2007 ............................. 94

Gráfico 3.6.2-2 Gráfico de cajas de Tickets (RT) por mes – Servicios 2006 .............................. 95

Gráfico 3.6.2-3 Gráfico de cajas Tickets (RT) por mes – Servicios 2005 ................................... 95

Gráfico 3.6.3-1 Resumen de estadística Tickets (RT) – Servicios 2007 .................................. 96

Gráfico 3.6.3-2 Resumen de estadística Tickets (RT) – Servicios 2006 ................................... 97

Gráfico 3.6.3-3 Resumen de estadística Tickets (RT) – Servicios 2005 ................................... 97

Gráfico 3.6.4-1 De comportamiento de Tickets (RT) por mes – Servicios 2007 ......................... 98

Gráfico 3.6.4-2 De comportamiento de Tickets (RT) por mes – Servicios 2006 ......................... 99

Gráfico 3.6.4-3 De comportamiento de Tickets (RT) por mes – Servicios 2005 ........................ 99

Gráfico 3.6.5-1 Pareto de Tickets por severidad – Servicios 2007 ............................................101



Gráfico 3.6.5-4 Pareto de Tickets por impacto – Servicios 2007 ...............................................102



Gráfico 3.6.5-7 Pareto de Tickets por miembros de TI – Servicios 2007 ...................................104



Gráfico 3.6.5-10 Pareto de Tickets por días (agrupados) – Servicios 2007 ..............................105



Gráfico 3.6.5-13 Pareto de Tickets por días de espera (agrupados) – Servicios 2007 ..............107



Gráfico 3.6.5-16 Pareto de satisfacción del cliente por ticket – Servicios 2007 .........................109



Gráfico 3.6.5-19 Pareto de tickets reabiertos – Servicios 2007 .................................................111



Gráfico 3.7.1-1 Valores individuales (RT) por mes – Problemas 2007 ......................................113



Gráfico 3.7.2-1 Gráfico de Cajas de Tickets (RT) por mes – Problemas 2007 ..........................115



Gráfico 3.7.2-2 Gráfico de Cajas de Tickets (RT) por mes – Problemas 2006 ..........................116

Gráfico 3.7.2-3 Gráfico de Cajas de Tickets (RT) por mes – Problemas 2005 .........................116

Gráfico 3.7.3-1 Resumen de estadística Tickets (RT) – Problemas 2007 ..............................117



Gráfico 3.7.4-1 De comportamiento de Tickets (RT) por mes – Problemas 2007 .....................119



Gráfico 3.7.5-1 Pareto de Tickets por severidad – Problemas 2007 .........................................121



Gráfico 3.7.5-4 Pareto de Tickets por impacto – Problemas 2007 ............................................123



Gráfico 3.7.5-7 Pareto de Tickets por miembros de TI – Problemas 2007 ................................125



Gráfico 3.7.5-10 Pareto de Tickets por días (agrupados) – Problemas 2007 ............................126



Gráfico 3.7.5-13 Pareto de Tickets por días de espera (agrupados) – Problemas 2007 ...........128



Gráfico 3.7.5-16 Pareto de satisfacción del cliente por ticket – Problemas 2007 ......................130



Gráfico 3.7.5-19 Pareto de tickets reabiertos (cero) – Problemas 2007 ....................................132

Gráfico 3.7.5-20 Pareto de tickets reabiertos (cero) – Problemas 2006 ....................................132

Gráfico 3.7.5-21 Pareto de tickets reabiertos – Problemas 2005 ..............................................133

Gráfico 4-1 Análisis de oportunidades ......................................................................................134

Gráfico 4.1.1-1 Valores individuales (RT) por mes – Servicios 2007 ........................................136

Gráfico 4.1.1-2 Gráfico de Cajas de Tickets (RT) por mes – Servicios 2007 ...........................136

Gráfico 4.1.1-3 Resumen de estadística Tickets (RT) por mes – Servicios 2007 ..................137

Gráfico 4.1.1-4 Valores individuales (RT) por mes – Servicios 2007 - corregida.......................138

Gráfico 4.1.1-5 Gráfico de Cajas de Tickets (RT) por mes – Servicios 2007 - corregida ...........138

Gráfico 4.1.1-6 Resumen de estadística Tickets (RT) por mes – Servicios 2007 - corregida .139



Gráfico 4.1.1.1-1 Análisis de normalidad – Media semanal. Servicios 2007 .............................142

Gráfico 4.1.1.1-2 Análisis SixPack – Media semanal. Services 2007 ........................................143

Gráfico 4.1.1.1-3 Capacidad del proceso – Media semanal. Servicios 2007 ............................143

Gráfico 4.1.2-1 Valores individuales (RT) por mes – Servicios 2006 .......................................144

Gráfico 4.1.2-2 Gráfico de Cajas de Tickets (RT) por mes – Servicios 2006 ...........................144

Gráfico 4.1.2-3 Resumen de estadística Tickets (RT) – Servicios 2006 .................................145

Gráfico 4.1.2.1-1 Análisis de normalidad – Media semanal. Servicios 2006 .............................147

Gráfico 4.1.2.1-2 Análisis SixPack – Media semanal. Servicios 2006 .......................................148


Gráfico 4.1.3-1 Valores individuales (RT) por mes – Servicios 2005 ........................................149

Gráfico 4.1.3-2 Gráfico de Cajas de Tickets (RT) por mes – Servicios 2005 ............................150

Gráfico 4.1.3-3 Resumen de estadística Tickets (RT) por mes – Servicios 2005 ...................150

Gráfico 4.1.3.1-1 Análisis de normalidad – Media semanal. Servicios 2005 ............................152

Gráfico 4.1.3.1-2 Análisis SixPack – Media semanal. Servicios 2005 ......................................153


Gráfico 4.1.3.1-4 Niveles de Sigma vs. DPMO con 1.5 σ cambio .............................................154

Gráfico 4.1.3.1-5 Niveles de Sigma vs. LSL / USL (DPMO) ......................................................155

Gráfico 4.1.4-1 Test de análisis – Modelos continuos y discretos .............................................156

Gráfico 4.1.4.1-1 Grafico de cajas de medias de Servicios 2005 al 2007 - ANOVA .................160

Gráfico 4.1.4.1-2 Gráficos de Residuos de medias de Servicios 2005 al 2007 - ANOVA .........161

Gráfico 4.1.4.2-1 Grafico de cajas de medias de Servicios 2005 y 2007 - ANOVA ..................163

Gráfico 4.1.4.2-2 Gráficos de Residuos de medias de Servicios 2005 y 2007 - ANOVA ..........163

Gráfico 4.1.5-1 Valores individuales (RT) – Problemas 2007 ....................................................164

Gráfico 4.1.5-2 Gráfico de Cajas de Tickets (RT) – Problemas 2007 ........................................164

Gráfico 4.1.5-3 Resumen de estadística Tickets (RT) – Problemas 2007 ...............................165

Gráfico 4.1.5.4-1 Box-Cox aplicada al tiempo de resolución de problemas 2007......................168

Gráfico 4.1.5.4-3 Análisis SixPack Box-Cox – Media de Problemas 2007 ................................169

Gráfico 4.1.5.4-4 Capacidad del proceso Box-Cox – Problemas 2007 .....................................169

Gráfico 4.1.5.4-5 Johnson aplicada al tiempo de resolución de problemas 2007 ......................170

Gráfico 4.1.5.4-6 Probabilidad de Johnson (RT) de Problemas 2007 ......................................170

Gráfico 4.1.5.4-7 Análisis SixPack Johnson – Media de Problemas 2007 ...............................171

Gráfico 4.1.5.4-8 Capacidad del proceso Johnson – Problemas 2007 ......................................171

Gráfico 4.1.5.4-9 Capacidad del proceso Weibull – Problemas 2007 .......................................172

Gráfico 4.1.5.5-1 Valores individuales (RT) – Problemas 2006 ................................................173

Gráfico 4.1.5.5-2 Gráfico de Cajas de Tickets (RT) – Problemas 2006 ....................................173

Gráfico 4.1.5.5-3 Resumen de estadística Tickets (RT) – Problemas 2006 ............................174



Gráfico 4.1.5.5-4 Box-Cox aplicada al tiempo de resolución de problemas 2006 .....................174


Gráfico 4.1.5.5-7 Capacidad del proceso Box-Cox – Problemas 2006 .....................................175

Gráfico 4.1.5.5-8 Johnson aplicada al tiempo de resolución de problemas 2006 ......................176

Gráfico 4.1.5.5-9 Probabilidad de Johnson (RT) de Problemas 2006 .......................................176

Gráfico 4.1.5.5-10 Análisis SixPack Johnson – Media de Problemas 2006 ..............................177

Gráfico 4.1.5.5-11 Capacidad del proceso Johnson – Problemas 2006 ...................................177

Gráfico 4.1.5.5-12 Capacidad del proceso Weibull – Problemas 2006 ....................................178

Gráfico 4.1.5.6-1 Valores individuales (RT) – Problemas 2005 ................................................179

Gráfico 4.1.5.6-2 Gráfico de Cajas de Tickets (RT) – Problemas 2005 ....................................179

Gráfico 4.1.5.6-3 Resumen de estadística Tickets (RT) – Problemas 2005 ...........................180

Gráfico 4.1.5.6-4 Box-Cox aplicada al tiempo de resolución de problemas 2005 .....................180


Gráfico 4.1.5.6-7 Capacidad del proceso Box-Cox – Problemas 2005 ....................................181

Gráfico 44.1.5.6-8 Johnson aplicada al tiempo de resolución de problemas 2005 ....................182

Gráfico 4.1.5.6-9 Probabilidad de Johnson (RT) de Problemas 2005 ......................................182

Gráfico 4.1.5.6-10 Análisis SixPack Johnson – Media de Problemas 2005 .............................183

Gráfico 4.1.5.6-11 Capacidad del proceso Johnson – Problemas 2005 ...................................183

Gráfico 4.1.5.6-12 Capacidad del proceso Weibull – Problemas 2005 .....................................184

Gráfico 4.1.6-1 Grafico de cajas de medias de Problemas Año 2005 al 2007 - ANOVA ...........186

Gráfico 4.1.6-2 Gráficos de Residuos de medias de Problemas 2005 al 2007 - ANOVA ..........187

Gráfico 4.1.7-1 Grafico de cajas de medias de Problemas Año 2006 y 2007 - ANOVA ............189

Gráfico 4.1.7-2 Gráficos de Residuos de medias de Problemas 2006 y 2007 – ANOVA ..........189

Gráfico 4.1.8-1 Interacción: media de servicios vs. impacto y severidad - 2006/2007...............191

Gráfico 4.1.8-2 Efectos de severidad e impacto sobre la media (RT) - Servicios 2006 .............191

Gráfico 4.1.8-3 Efectos de severidad e impacto sobre la media (RT) - Servicios 2007 .............192

Gráfico 4.1.8-4 Efectos: Miembros de TI, tipo de ticket, media semanal de servicios 2006 ......192

Gráfico 4.1.8-5 Efectos: Miembros de TI, clase de ticket, media semanal servicios 2007 .........193

Gráfico 4.1.9-1 Interacción media de servicios y los efectos impacto y severidad – 2006 ........195

Gráfico 4.1.9-2 Interacción media de servicios y los efectos impacto y severidad – 2007 ........195

Gráfico 4.1.9-3 Interacción: media de servicios con miembros de TI y perfil del ticket – 2006 ..196

Gráfico 4.1.9-4 Interacción: media de servicios con miembros de TI y perfil del ticket – 2007 ..197

Gráfico 4.1.10-1 Intervalos de la media (RT) debido al impacto del servicio – 06/07 ................198

Gráfico 4.1.10-2 Intervalos de la media (RT) debido a la severidad de servicio - 06/07 ............198

Gráfico 4.1.10-3 Intervalos de la media de servicios por miembros de TI – 06/07 ....................199

Gráfico 4.1.10-4 Intervalos de la media servicios debido al perfil del ticket – 06/07 ..................200



Gráfico 4.1.10-5 Gráfico de cajas (RT) debido al perfil del ticket de servicio -06/07.................200

Gráfico 4.1.11-1 Grafico de cajas de problemas (RT) por miembros de TI – 05 - ANOVA ........202

Gráfico 4.1.11-2 Gráfica de Residuos problemas (RT) por miembros de TI -05- ANOVA .......203

Gráfico 4.1.11-3 Test de Varianzas iguales – Problemas (RT) vs miembros de TI .................204

Gráfico 4.1.12-1 Grafico de cajas de problemas (RT) por perfil del ticket – 05 - ANOVA ..........210

Gráfico 4.1.12-2 Gráfica de Residuos problemas (RT) por perfil del ticket -05- ANOVA ...........211

Gráfico 4.1.12-3 Test de Varianzas iguales – Problemas (RT) vs perfil del ticket ...................212

Gráfico 4.1.13-1 Grafico de cajas de problemas (RT) por miembros de TI – 07 - ANOVA ........215

Gráfico 4.1.13-2 Gráfica de Residuos problemas (RT) por miembros de TI -07- ANOVA .........215


Gráfico 4.1.14-1 Grafico de cajas de problemas (RT) por perfil del ticket – 07 - ANOVA .........219

Gráfico 4.1.14-2 Gráfica de Residuos problemas (RT) por perfil del ticket -07- ANOVA ...........220


Gráfico 5-1 Mejora de la performance ......................................................................................225

Gráfico 5-2 Herramientas para generar ideas sobre mejoras ..................................................226

Gráfico 5.1-1 Proceso de mejora de 7 pasos (ITIL V3) ............................................................229

Gráfico 5.2.1-1 Diagrama de flujo de toma de decisiones basada en datos ..............................231

Gráfico 5.3.1-1 CMMI - Actividades de mediciones y análisis de procesos ...............................233

Gráfico 5.3.2-1 Mapeo de las actividades de medición del CMMI ............................................234

Gráfico 5.4-1 ¿Cómo son generados y usados los datos?........................................................237

Gráfico 5.4-2 Ejemplo de indicadores incluidos en un BSC .....................................................237

Gráfico 5.5.1-1 IT Dashboard – Relojes indicadores................................................................264

Gráfico 5.5.1-2 IT Dashboard - Gráfico de barras de incidentes ..............................................264

Gráfico 5.5.1-3 IT Dashboard - Gráfico de barras de presupuesto............................................265

Gráfico 5.5.1-4 IT Dashboard - Gráfico de barras de satisfacción al cliente ..............................265

Gráfico 5.6-1 Modelos de calidad, relevancia y abstracción .....................................................267

Gráfico 6-1 Control de la performance ......................................................................................268

Gráfico 6.2.3-1 Ejemplo de procesos bajo SPC ........................................................................271

Gráfico 6.2.3-2 Proceso estable en el tiempo ...........................................................................272

Gráfico 6.2.3-3 Proceso inestable en el tiempo ........................................................................272

Gráfico 6.2.3-4 Gráfico de un proceso con límites de control ....................................................273

Gráfico 6.2.3-5 Ejemplo de estabilidad y capacidad de un proceso ..........................................273



ÍNDICE DE APÉNDICES

APÉNDICE 1. IT SLA PERFORMANCE DASHBOARD - ARGENTINA ...................................................288

APÉNDICE 2. IT SLA PERFORMANCE DASHBOARD - AUSTRALIA ....................................................290

APÉNDICE 3. IT SLA PERFORMANCE DASHBOARD - CANADA ........................................................292

APÉNDICE 4. IT SLA PERFORMANCE DASHBOARD - CHINA ...........................................................294

APÉNDICE 5. IT SLA PERFORMANCE DASHBOARD - INDIA .............................................................296

APÉNDICE 6. IT SLA PERFORMANCE DASHBOARD - ITALY ............................................................298

APÉNDICE 7. IT SLA PERFORMANCE DASHBOARD - MALAYSIA ......................................................300

APÉNDICE 8. IT SLA PERFORMANCE DASHBOARD - POLAND ........................................................302

APÉNDICE 9. IT SLA PERFORMANCE DASHBOARD - SINGAPORE ...................................................304

APÉNDICE 10. IT SLA PERFORMANCE DASHBOARD - RUSSIA .......................................................306

APÉNDICE 11. IT SURVEY ANALYSIS REPORT CCS 2002 – ARGENTINA ........................................308

APÉNDICE 12. IT SURVEY ANALYSIS REPORT CCS 2003 - ARGENTINA .........................................310



APÉNDICE 15. PLANNED & UNPLANNED OUTAGES REPORT - AVAILABILITY ...................................330

APÉNDICE 16. MAPPING ITIL & ISO 17799 TO COBIT CONTROL OBJECTIVES ..............................332

APÉNDICE 17. INDICATOR TEMPLATE SEI - CMMI .......................................................................368

APÉNDICE 18. MAPPING OF CMMI FOR DEVELOPMENT V1.2 WITH COBIT 4.0 ...............................372



II. Abreviaturas y significados

Acrónimo Significado en castellano Significado en inglés

BSC Tablero de control balanceado Balanced ScoreCard

CBR Requerimientos críticos del negocio Critical Business Requirements

CCR Requerimientos críticos del cliente Customer Critical Requirements

CMMI Integración del modelo de madurez de la capacidad.

Capability Maturity Model Integration

CObIT Objetivos de control para la información y tecnología relacionada

Control Objectives for Information and related Technology

COPQ Costo de no calidad Cost Of Poor Quality

COQ Costo de calidad Cost Of Quality

Cp Capacidad del proceso (límites naturales relacionados con los requerimientos del cliente)

Process Capability (natural process limit related to Customer requirement)

Cpk Índice de capacidad del proceso (alineación, centrado del proceso,

Cpk≤Cp)

Process Capability Index (Process

alignment to the center, Cpk≤Cp)

CSS Encuesta de satisfacción del cliente Customer Satisfaction Survey

CTB Crítico para el negocio Critical To Business

CTP Críticos para el proceso Critical To Process

CTQ Crítico para la calidad Critical To Quality

Ha Hipótesis alternativa Alternative hypothesis

Ho Hipótesis nula Null hypothesis

Hw Equipos Hardware

IT o TI Tecnología de la información Information Technology

MSA Análisis del sistema de medición Measurement System Analysis

Outlier Puntos o valores fuera de los límites de control de un proceso

Data or points outside the control limits of the process

P/T Relación precisión tolerancia Precision to Tolerance ratio

PDCA Planificar, hacer, verificar, actuar Plan, Do, Check, Act

R&R Repetitividad y reproducibilidad Repeatability & Reproducibility

ROI Retorno sobre la inversión Return Over Investment

RT Tiempo de resolución Resolution Time

SEI Instituto de ingeniería en software Software Engineering Institute

SS Seis sigma Six Sigma

Sw Licencias Software

TC Tablero de control o comandos Scorecard

TQC Control de calidad total Total Quality Control

TQM Gestión de calidad total Total Quality Management

VOB Voz del negocio Voice Of the Business

VOC Voz del cliente Voice Of Customer

Σ Sigma o desviación estándar Sigma or standard deviation

ANAVA Análisis de varianza paramétrico de datos

ANOVA



III. Introducción La falta de un sistema marco para la gestión de la calidad, asociada con las áreas de la tecnología de la información (Information Technology, IT), en la mayoría de las empresas del sector electrónico -donde principalmente la gestión de calidad está focalizada sólo al desarrollo o producción, dejando de lado otras áreas de soporte- conlleva a poca o mínima alineación con los objetivos del negocio. Esto determina una gestión deficiente, que debiera impulsar la búsqueda de información para la generación de indicadores y un plan de métricas que permitan tomar decisiones adecuadas relacionadas a la IT. Por otro lado, la mayoría de las empresas han desarrollado históricamente sus controles gerenciales resumiendo los parámetros considerados claves en su momento (e.g. ventas, gastos, beneficios, calendario y productividad); con una orientación únicamente financiera que cegaba muchos eventos que impactan directamente en los resultados finales. En aquel contexto, las áreas de tecnología de la información solo merecían un rol de soporte, y no su verdadero rol estratégico, que hoy da cuenta de su importancia y evoluciona rápidamente. Es conveniente -para apuntalar la mejora en la gestión organizacional y la competitividad empresarial- que tales decisiones se basen en indicadores e instrumentos de control, que se presentan en el correspondiente cuadro de control gerencial. Estos indicadores suministran información altamente organizada y útil, desde los puntos de vista estratégico, táctico y logístico. A su vez, permiten observar tendencias, comportamientos de los procesos, actuación de los factores críticos y explicitar los resultados que se alcanzan. Con lo anterior, y en base al análisis sistemático de ellos, se procederá a tomar las decisiones operativas y estratégicas que se adecuen a los escenarios en los que se actúa. Así, estos indicadores estructurados y relacionados, ayudarán a anticiparse a los problemas futuros, optimizando el esfuerzo invertido en acciones de control, prevención y corrección, típicos de las tareas empresariales. La ausencia del marco mencionado anteriormente, o bien definiciones nulas o poco claras, pueden conducir a interpretaciones erróneas acerca de la actuación del área bajo análisis. Un error conceptual y metodológico grave, que conduce a tales interpretaciones equívocas, se origina en los datos que se pretenden enfrentar en un proceso comparativo. Dado que, la comparación origina, generalmente, que se relacionen indicadores con idénticos nombres pero en una estructura conceptual diferente o con distintas bases de cálculo. Otra situación problemática que se observa -de modo más habitual que extraordinario- es que la integración funcional de los indicadores de control de la IT en muchos casos es omitida o construida de modo incorrecto, provocando la filtración de información clave para la toma de decisiones adecuada. Como destaca claramente Blanco Illescas1, una correcta construcción del sistema integrado de control ―debe asegurar que no existan lagunas en las medidas que

1 BLANCO ILLESCAS, F. El control integrado de gestión. Méjico: Editorial Limusa, 1995.



afectarán el resultado final, para lo cual, deben articularse controles que asignen responsabilidades por productos y traduzcan las desviaciones‖. La implementación de controles permite, a su vez, evaluar las responsabilidades y desempeño de cada área organizacional. Para cada período en análisis, deberán enfrentarse los resultados obtenidos, a las metas y objetivos que la empresa ha planteado para ese lapso, y que deben estar explicitados en el planeamiento estratégico de la misma. Esto ayudaría a la alineación de los resultados de todas las áreas con los objetivos claves del negocio, logrando una mayor consistencia y solidez en la actuación presente y futura de la organización. De lo anterior, se resalta en el área de IT, y especialmente en el sector electrónico, la necesitad de indicadores e instrumentos de control relacionados a procesos claves o críticos de los servicios prestados por esta. Tales instrumentos permiten a la alta gerencia el monitoreo, para prevenir fallas, observar tendencias y encontrar posibilidades de mejoras. También, facilitan la integración suficiente de los procesos claves de la IT, a través de un tablero de comando (TC) organizacional. El presente trabajo está enfocado en la identificación y definición de los indicadores de control, o métricas2, para una gestión integrada; y que forman parte del TC del área de IT, desarrollada particularmente en empresas del sector electrónico. Cabe aquí definir el significado de diferentes términos, asociados con las métricas y su obtención. Ellos son, medición3, que es el proceso, y medida4, que es el resultado de tal proceso; para la elaboración de las métricas a través de cálculos predefinidos. La identificación y su clara definición, también favorecen la comparación (por medio del benchmarking5) del área de IT, dentro de las unidades de negocio de la propia organización y entre distintas empresas (que utilicen y/o adopten tales indicadores con una estructura y bases de cálculo comunes). Es de considerar que, el benchmarking es una técnica gerencial que permite mejorar el desempeño, a través de análisis comparativos entre áreas o procesos internos, o con otras organizaciones6. Esto permite cerrar la brecha percibida respecto a la definición de los indicadores de la IT y su integración en un TC de gestión, permitiendo el flujo continuo de la información necesario para garantizar (junto con los indicadores emergentes de otras áreas) el estado funcional y competitivo de la empresa. Los tableros de control o comando, como plantean Kaplan y Norton7, se construyeron y usan actualmente para los sistemas de información gerencial automatizados, con el

2 Métrica: se la utiliza, en cierta literatura específica, como una función matemática que asocia a una

serie de elementos, con el objeto de cuantificarlos y/o cualificarlos. Como sinónimo de métrica habitualmente se utiliza el concepto de indicador, como aspecto cuantitativo de un sistema. El método de medición definido y la escala de medición. [ISO 14598-1:1999] 3 Medición: proceso de asignar un número a un concepto.

4 Medida: valor asignado al fenómeno.

Número o categoría asignada a un atributo de una entidad mediante una medición. [ISO 14598-1:1999] A quantitative measure of the degree to which a system, component, or process possesses a given attribute. [IEEE 610.12:1990] 5 Benchmarking: proceso de comparación, que puede ser continuo. Consiste en medir productos,

servicios y prácticas, contra competidores fuertes, o aquellas compañías reconocidas como líderes en la industria. 6 DETORO, I. The 10 pitfalls of benchmarking. New York: Quality Progress, 1995.

7 KAPLAN, R.S. y NORTON, D.S. Implantando el cuadro de mando integral. Barcelona: Gestión 2000.



propósito de ayudar en la toma de decisiones, en base al uso adecuado de indicadores que permitan un mejor control, planeamiento y conducción de la empresa. Según Blanco Illescas8, la rentabilidad de la empresa depende del desarrollo armónico de todas y cada una de las áreas críticas de la misma. Además, señala que los costos de calidad (Cost Of Quality, COQ) y los de no calidad (Cost Of Poor Quality, COPQ), la satisfacción del cliente, como así también el aseguramiento del servicio -junto a otros factores críticos de desempeño- no eran habitualmente ponderados de un modo adecuado o directamente estaban ausentes en los tableros de control gerencial. En este mismo sentido, Juran9 menciona que los procesos empresariales -no obstante ser estos claves en la construcción de la calidad- no eran tenidos en cuenta demasiado a la hora de comprender y diseñar intervenciones correctivas y preventivas ante situaciones problemáticas dentro del desempeño empresarial. Por ello, y hasta hace muy pocos años atrás, los TC no incluían el comportamiento del sistema con respecto a la calidad, excluyendo de ellos también a todas las áreas y variables, que en ese entonces -bajo el paradigma contable clásico- no eran consideradas como críticas para el logro de los objetivos. Dentro de tal grupo de factores, visualizados como no críticos en el desempeño organizacional, se encontraba área de la IT. Esto sucedió –y aún continúa- particularmente en pequeñas y medianas empresas, aunque también este fenómeno ocurre en ciertas empresas con presencia global. Definir instrumentos de control comunes para la IT, e integrarlos a un tablero de comando, que incorpore el enfoque y desempeño de las perspectivas organizacionales (respecto a finanzas, clientes, procesos internos del negocio, aprendizaje y crecimiento de los empleados, entre otras) implica desarrollar métricas, recolectar datos y analizarlos respecto de cada una de las dimensiones, las que debieran tener una fuerte relación con la visión y misión de la empresa. La selección de los indicadores claves, para informar a la alta dirección, depende de la tipología del sector, del modelo de gestión y de la experiencia empresarial acumulada, junto a otra serie de factores. Actualmente, siempre se intenta buscar una mezcla equilibrada de ellos (aquellos que representen lo ―físico‖ u observable, así como los omnipresentes de carácter monetario, y aún aquellos más ―blandos‖ o subjetivos, como las percepciones de los usuarios), teniendo en cuenta la información interna, del contexto y la estimada de corto, mediano y largo plazo. Dentro de la perspectiva de selección de indicadores, en los últimos años se ha difundido el ―tablero de control balanceado" (Balanced ScoreCard, BSC) de R. Kaplan y D. Norton; que en su innovación del tablero de mando integral, señalan lo que se viene afirmando hasta aquí: en el pasado inmediato se tenían en cuenta solamente las tradicionales medidas financieras para su confección. Los autores expresan que ―las medidas financieras por si solas son inadecuadas para dirigir y evaluar la información que las compañías necesitan. Se deben tener en cuenta también otros indicadores para

8 BLANCO ILLESCAS, op.cit.

9 JURAN, J.M. Juran y el liderazgo para la calidad – un manual para directivos, Madrid: Diaz de Santos,

1990.



crear el valor futuro a través de la inversión en clientes, proveedores, empleados, procesos, tecnología e innovación‖10. Un concepto clave, en esta perspectiva, es el control. Controlar significa observar e intervenir, guiando los hechos para que los resultados reales coincidan o superen a los deseados o planificados; y esto supone ejecutar cuatro funciones básicas, descriptas en detalle por Blanco Illescas11:

a) Fijación de estándares de actuación satisfactoria. b) Comprobación de los resultados reales frente a los estándares. c) Toma de una decisión crítica cuando los resultados reales no satisfacen

los estándares. d) Realización de la acción correctora.

Avanzando en este sentido, se aseguran las acciones necesarias para un mejor control de las funciones básicas en cada área en particular y permite un monitoreo en forma real, a través de todos los indicadores establecidos en su tablero de gestión integrado, el cual formará parte del general de la compañía. Además, Blanco Illescas observa que mejorar la calidad es un asunto central para cada una de las áreas que integran la empresa. Cada proyecto de mejora requiere una inversión en dos formas:

1. Realizar un diagnóstico, para descubrir las causas de la mala calidad. 2. Remediar o intervenir, para eliminar las causas identificadas.

El rendimiento resultante de tal inversión, se halla entre los más altos que puedan encontrarse en la actividad empresarial y ha provocado, en algunos directivos, avanzar sobre la idea de que ―el mejor negocio es mejorar la calidad‖. La medición sistemática y la incorporación de datos a un TC representan, entonces, simplemente el hábito de saber explicitar y comunicar cómo se va desempeñando el sistema objeto de estudio. En cada una de las etapas simplificadas, dentro del proceso de generación de bienes y servicios (insumos, procesos y productos), se pueden generar indicadores y, como lo destaca Crosby12, de esta manera cualquier tarea es mensurable si se utiliza este sencillo patrón. Las métricas y cartas de proceso, definidas y monitoreadas para tal fin, permitirán la optimización y mejora continua de los procesos existentes, ajustando permanentemente los límites de control de los mismos, lo cual debiera reflejarse en la productividad del área a través del tiempo. A los efectos del trabajo de tesis que se plantea aquí, el marco teórico que se viene explicitando puede complementarse de modo muy conveniente con el modelo de

10

KAPLAN, R.S. y NORTON, D.S., op. cit. 11

BLANCO ILLESCAS, F., op. cit. 12

CROSBY, P.B. Calidad sin lágrimas – El arte de administrar sin problemas. Méjico: Compañía editorial continental, 1992.



gestión de mejoras conocido como Six Sigma, desarrollado por la compañía internacional Motorola13. El sistema de gestión Six Sigma integra la filosofía de trabajo con las estrategias de negocios, basadas en el enfoque hacia el cliente y el diseño robusto, con un manejo eficiente de los datos y metodologías. Su objetivo es eliminar la variabilidad en los procesos y alcanzar un nivel de defectos mínimo, sino nulo. Adicionalmente, se obtienen otros beneficios, como la reducción en los tiempos del ciclo productivo y su variabilidad, reducción de costos, elevada satisfacción de los clientes y, más importante aún, efectos claves en el desempeño financiero de la empresa. Es una de las más exitosas estrategias de gerencia del último cuarto del siglo. De allí que, un buen número de empresas y organizaciones comprometidas con la satisfacción del cliente -en la entrega oportuna de productos y servicios, libres de defectos y a costos razonables- aplican Six Sigma (e.g. Motorola, Allied Signal, G.E., Polaroid, Sony, Lockheed, NASA, Black & Decker, Bombardier, Dupont, Toshiba, entre otras). Cabe destacar que, el modelo mencionado, no se aplica exclusivamente en asuntos de manufactura de bienes, sino también, puede ser utilizado en áreas de servicios y aquellas correspondientes a la IT; lo que conduciría a propiciar la mejora continua e innovación en todas las organizaciones y subsistemas que lo adopten, más allá de su tipología o actividades. Esta metodología particularmente es de uso muy difundido en sectores de desarrollo de software y servicios asociados, con lo cual se pronuncia aún más la importancia de la gestión y mejora de la IT, como soporte de los negocios. Según Harry y Schroeder14, Six Sigma puede también enfocarse como:

• Metodología: es una estrategia de negocios, basada en la mejora continua, que

busca encontrar y eliminar causas de errores o defectos en los procesos, enfocándose en las variables de importancia crítica para los consumidores. • Métrica: es considerada una medida de la calidad. Mientras mayor es el valor de

―sigma‖ de un proceso, producto o servicio, mejor es su calidad. En particular, la calidad de Six Sigma significa que, sólo se permiten 3.4 defectos por millón de oportunidades.

La aplicación del modelo Six Sigma implica el planteamiento de un proyecto determinado, según el objetivo foco de mejora, y el marco de trabajo específico. El proceso involucra una serie de pasos o fases, que contendrán las directivas a tener en cuenta, para alcanzar el resultado deseado. La ejecución de estos proyectos es llevada a cabo por personal idóneo, que ha recibido un entrenamiento avanzado en tratamiento estadístico de datos, análisis de procesos, técnicas de trabajo en equipo y diversas herramientas de gestión.

13

MOTOROLA. 2007. ―Six Sigma Programs‖. [en línea]. Disponible en Internet: http://www.motorola.com/content.jsp?globalObjectId=3049-11525 [Consulta: 11 Diciembre 2007] 14

HARRY, Mikel y SCHROEDER, Richard. Six Sigma: The Breakthrough Management Strategy Revolutionizing the World’s Top Corporations. New York, NY: Doubleday,2000.

http://www.motorola.com/content.jsp?globalObjectId=3049-11525



Las herramientas y técnicas claves, que se utilizan, son las manejadas en la disciplina de la gestión estratégica de calidad total (TQM, diseño/rediseño de procesos, análisis de varianza, ANOVA, cuadro de mando integral, benchmarking, voz del cliente, torbellino de ideas, pensamiento creativo, diseño de experimentos, gerencia de los procesos, control estadístico de procesos, entre otras)15. Así, el tema en estudio y sus resultados, permitirán orientar a aquellos que tengan que administrar el área de la IT -como área de servicios dentro del sector electrónico- a establecer métricas o indicadores críticos como instrumentos de control, en pos de generar mayor efectividad y eficiencia, permitiendo controlar los procesos de acuerdo a las expectativas y los requerimientos planteados por sus clientes. Los indicadores o métricas organizacionales de potencial uso común permitirán la comparación dentro de distintas unidades del negocio pues, de lo contrario, se corre el riesgo de que cada una realice sus estimaciones en base a factores diferentes; generándose índices no comparables entre sí. En esa adopción simultánea estriba una dificultad adicional, producto de cierta resistencia al cambio, conseguir que otras áreas de tecnología de la información implementen esta colección de métricas estandarizadas en su rutina diaria de trabajo. Para la generación de las métricas seleccionadas, se utilizan datos obtenidos del proceso y de repositorios de datos, asociados a mediciones de procesos anteriores y que son relativamente estables o están bajo control. Las métricas en el área de la IT deben ser construidas para alentar una mejora en el desempeño, efectividad, eficiencia y proveer al área de controles internos de los niveles apropiados exigidos por la empresa en cuestión. También en los indicadores deben incorporarse las mejores prácticas relacionadas con el desempeño incluyendo un análisis de costo, riesgo y beneficio asociado. Los elementos clave, para la generación de las métricas, deben ser los siguientes: alineación con la misión de la organización, calidad del producto, entrega a tiempo, reducción de costos, disminución del tiempo de ciclo productivo, satisfacción y requerimientos del cliente y compromisos establecidos. El aporte central del trabajo se enfoca en la definición y estandarización de los instrumentos de control del un tablero de gestión integrada para el área de IT. Lo cual, permite el análisis y facilita los reportes, para ser utilizados en la toma de decisiones, sustentada en la información obtenida a partir de indicadores, con bases de cálculo comunes. Viabilizando comparaciones entre distintas unidades de negocio (internas o externas), de las métricas estandarizadas, pertinentes, adoptadas. Se abordará de forma completa la metodología estratégica Six Sigma, para un sistema de indicadores y métricas, con el objetivo de mejorarlo. La meta es lograr un marco de trabajo con definiciones claras e inequívocas de tales indicadores, que permita, a través de las mejoras logradas, reforzar el valor de las actividades de la IT. El sustento práctico de los conceptos abordados, es que el estudio está basado en datos relevados de un sistema de pedidos de servicios electrónico, de encuestas de satisfacción realizadas a los usuarios finales y de pruebas de estabilidad y capacidad de los procesos disponibles.

15

PYZDEK, Thomas. The six sigma handbook, New York: McGraw-Hill, 2001.



El desarrollo de los contenidos comienza con la mención de las tres clases posibles de proyectos para llevar a cabo la implementación de la metodología Six Sigma, conocidos como DMAIC (Definition, Measurement, Analysis, Improvement, Control), DMADV (Define, Measure, Analyze, Design, Validate) y DMADDD (Define, Measure, Analyze, Design, Digitize, Draw Down). Dentro de esta primer parte se describe en profundidad el marco de trabajo. También allí se detallan las herramientas y estándares a utilizar para hacer posible su despliegue en el contexto citado. Luego, a partir del segundo capítulo, se hace énfasis en el proyecto DMAIC, el cual

supone las siguientes fases: definición, medición, análisis, mejora y control. Cada una de las etapas que involucra este proyecto será especificada en los sucesivos capítulos, para obtener el adecuado seguimiento de la evolución del proceso de mejora. Con tales fines, en un principio se llevó adelante un exhaustivo análisis del marco vigente en las actividades, y se demostró que no era unívoco en las diferentes unidades de negocio, en relación al reporte de indicadores. Por lo tanto se comenzó con un trabajo de investigación que permitiera el reordenamiento y definición necesarios. Se examinaron distintas metodologías, estándares y normas internacionales relacionadas, que pudieran brindar una base sólida referente al área de la IT; para contar con los mejores procesos y prácticas conducentes a los objetivos deseados. Los datos disponibles fueron estudiados para determinar su consistencia dentro del proyecto propuesto. Fueron elegidos aquellos concernientes a los pedidos de servicios y problemas, recolectados a lo largo de tres años consecutivos. Con ellos se realizó la comparación entre las medias anuales para ver si existían diferencias significativas, en cuyo caso, se rastrearon los factores que podían ser determinantes en mayor o menor medida de tales cambios. Con los resultados de las etapas anteriores se llevó a cabo un análisis de estabilidad y capacidad del proceso para advertir si se cumplía con los requerimientos del cliente, establecidos en el acuerdo de servicio interno del área de IT. Se definieron indicadores críticos, plan de desempeño y un tablero de gestión y control de la IT, que facilitan la aplicación de la metodología planteada. Finalmente, para la ejecución y puesta en marcha del proyecto, se concluye con una etapa de control que da lugar al monitoreo, implementación de mejoras, resolución de problemas y toma de decisiones en base a datos. Todo esto permitirá introducir un ciclo de mejora continua en los procesos y en la determinación de nuevas necesidades del negocio.



PARTE I.

MARCO DE TRABAJO En esta sección se abordará de manera completa el marco de trabajo en el cual se desplegará la metodología Six Sigma, con definiciones de los indicadores, que permitirán desarrollar adecuadamente las actividades de la IT.

1. DEFINICIÓN DEL MARCO DE TRABAJO

El desarrollo de la tesis se basa en la optimización de recursos y mejora en los servicios de la IT, con el fin de aumentar la competitividad de una organización determinada. Existen diferentes modelos y estándares propuestos para la adecuada gestión de la IT, y lograr que los servicios de esta se alineen con los objetivos de la empresa. Dado que ningún modelo abarca una solución completa, integrar las fortalezas de cada uno, combinando sus actividades y herramientas, en diferentes etapas de la metodología adoptada, permitirá maximizar los beneficios cualitativos y cuantitativos de su gestión. El trabajo profundiza la metodología Six Sigma, como herramienta administrativa para gestionar la IT. A su vez, se mencionan otros modelos, como el ―tablero de control balanceado‖, BSC (Balanced ScoreCard). Como marco de trabajo, o framework, para la gestión, se utiliza el modelo CObIT (Control Objectives for Information and related Technology); contemplando la implementación de mejores prácticas por medio de estándares como ITIL (Information Technology Infrastructure Library) o ISO 2000016, y CMMI (Capability Maturity Model Integration). También se tomará apoyo en la norma relacionada con la seguridad informática, Information Technology - Security techniques - Code of practice for information security management (ISO/IEC 27000)17. Para comenzar el análisis, se hará una breve revisión de los conceptos y herramientas, mencionados en el párrafo anterior, que ayudarán al entendimiento y definición del marco o estructura de trabajo. Considerando, además, su interrelación; dada la necesidad e importancia de que cada empresa pueda adaptarlos al ambiente en el que se encuentran. Los organismos que gestionan, regulan y actualizan estos estándares, o referencias, intentan integrarse y complementarse entre sí. Es decir, una acción conjunta -cooperación- entre empresas, en pos de lograr mejoras en el área de IT; esto es, compartir información vigente y útil para avanzar sobre la optimización de los servicios de la IT.

16

ISO 20000.‖ISO20000 - the IT Service Management standard‖ [en línea]. Disponible en Internet: http://www.itgovernance.co.uk/iso20000.aspx?gclid=CNzMtPHo0JMCFQE4GgodsVfGhw [Consulta: 11 Diciembre 2007] 17

ISO 27000. ―An Introduction to ISO 27001, ISO 27002....ISO 27008‖ [en línea]. Disponible en Internet: http://www.27000.org [Consulta: 11 Diciembre 2007]

http://www.itgovernance.co.uk/iso20000.aspx?gclid=CNzMtPHo0JMCFQE4GgodsVfGhw

http://www.27000.org/



1.1. Metodología Six Sigma

La aplicación de Six Sigma brinda beneficios como: reducción en los tiempos del ciclo productivo y su variabilidad, reducción de costos, elevada satisfacción de los clientes y, más importante aún, efectos claves en el desempeño financiero de la empresa. En la metodología Six Sigma (SS) son comúnmente reconocidas las herramientas que se utilizan en ella, llamadas Design For Six Sigma tools (DFSS tools), en Motorola18, la compañía tiene un sitio donde se puede encontrar diferente material y programas relacionados a ella, hacemos referencia a este sitio debido a que inicialmente en esa compañía se implementó SS aunque en otras compañías grandes como General Electric se obtuvieron mejores retornos sobre la inversión (ROI) en su implementación e inserción en los negocios. La aplicación del modelo Six Sigma implica el planteamiento de un proyecto determinado, según el objetivo foco de mejora, y el marco de trabajo específico. El proceso involucra una serie de pasos o fases, que contendrán las directivas a tener en cuenta, para alcanzar el resultado deseado.

1.1.1. Clases de proyectos de Six Sigma (DMAIC, DMADV, DMADDD)

Existen distintos procesos dentro de esta metodología, dependiendo de los escenarios a evaluar. De acuerdo a Kerry Simon19, los proyectos de SS se pueden dividir en tres clases, de acuerdo a que lo que se desee analizar o aplicar, a saber:

DMAIC (Define, Measure, Analyze, Improve, Control)

DMADV (Define, Measure, Analyze, Design, Validate)

DMADDD (Define, Measure, Analyze, Design, Digitize, Draw Down) El proceso DMAIC se utiliza cuando el objetivo es la mejora de un producto, proceso o servicio existente; frecuentemente aplicado en la mejora de la performance o actuación. En cambio, cuando lo que se desea es diseñar un nuevo producto o proceso, se usa DMADV. Por último, si se quiere incrementar la productividad, se emplea DMADDD. A través del siguiente gráfico se puede observar que todos los procesos están relacionados por fases comunes, pero existen derivaciones, que dependen del objetivo propuesto al aplicar la metodología.

18

MOTOROLA. , op. cit. 19

KERRY, SIMON. ―DMAIC versus DMADV Methodologies‖. [en línea] I SIX SIGMA. Disponible en Internet: http://www.isixsigma.com/library/content/c001211a.asp [Consulta: 11 Diciembre 2007]

http://www.isixsigma.com/library/content/c001211a.asp



Gráfico 1.1.1-1 Procesos de DMAIC, DMADDD y DMADV

Publicado por CSC. ―Patch Management using Six Sigma‖20

1.1.2. Fases de un proyecto DMAIC

En la tabla que se encuentra a continuación, se establecen las acciones involucradas en cada una de las fases de un proceso DMAIC, según Thomas Pyzdek21. Estas comienzan con acciones a seguir en cada una de las fases del mismo.

20

CSC. ―Patch Management using Six Sigma‖ [en línea]. Disponible en Internet: http://phoenix.issa.org/Six%20Sigma.ppt [Consulta: 11 Diciembre 2007] 21

PYZDEK, THOMAS.2003. ―DMAIC and DMADV‖. [en línea]. Disponible en Internet: http://www.pyzdek.com/DMAICDMADV.htm [Consulta: 11 Diciembre 2007]

http://phoenix.issa.org/Six%20Sigma.ppt

http://www.pyzdek.com/DMAICDMADV.htm



Tabla 1.1.2-1 Pasos a seguir en las distintas etapas del proceso DMAIC

D

Definición (Define):

Se establecen claramente los objetivos y métricas –indicadores- relevantes. Con los cuales, se podrá apreciar la línea base, brechas, impedimentos y barreras estructurales para el proceso de cambio, y finalmente, la evolución hacia las metas Los objetivos más importantes son obtenidos de los clientes o usuarios finales. En los niveles superiores, los objetivos serán estratégicos para la organización, tales como mejorar la lealtad de los clientes, lograr un alto retorno sobre la inversión (Return Over Investment, ROI), incrementar la porción de mercado, generar mayor satisfacción del empleado, entre otros. A nivel operativo, se podría, además, incrementar la efectividad y la eficiencia, y reducir el tiempo de resolución de problemas del departamento; mientras que, a nivel del proceso, se busca reducir los costos de calidad y de no calidad (Cost Of Quality, COQ y Cost Of Poor Quality, COPQ), reducir el nivel de defectos e incrementar la salida de un determinado proceso. Se pueden plantear objetivos a partir de la comunicación directa con clientes, accionistas y empleados.

M

Medición (Measure): Se analiza en detalle el desempeño, a lo largo del proceso, y se obtienen las relaciones causa-efecto entre todas las variables claves involucradas A partir del sistema existente, se establecen métricas válidas y confiables para ayudar a monitorear el progreso hacia los objetivos definidos en el paso anterior. Es decir, la situación actual determina la línea base del proyecto, luego se usan métodos de análisis de datos exploratorios y descriptivos que ayuden a entender la información.

A

Análisis (Analyze):

Se construyen relaciones y niveles de causalidad, entre los procesos y sus resultados. Se identifican los aspectos críticos, a partir de los cuales, se puede modificar la situación actual, utilizando herramientas y métodos estadísticos que guían el análisis. Se estudian los modos de falla y los efectos de la variabilidad. Todo ello, para determinar los efectos principales e interacciones, derivadas del análisis pasivo, y los compromisos, tanto operacionales como financieros. Es decir, conocer las causas o entradas al proceso, que tienen impacto directo en los resultados del mismo.

I

Mejora (Improve): Se realizan ejercicios interactivos de los procesos, mediante pruebas y experimentación estadística. Se definen las estrategias para lograr los cambios en el desempeño, la socialización, aceptación y definiciones claves para los planes de puesta en marcha o mejoramiento del diseño de control. Será necesaria la creatividad, para encontrar nuevas maneras de hacer las cosas, de forma tal que sean mejores, más baratas o más rápidas; por medio del gerenciamiento del proyecto u otras herramientas de administración, para implementar una nueva mirada; y usando métodos estadísticos para validar la mejora. Es aconsejable la aplicación de estándares, como las normas ISO 9000 e ISO 17799, el modelo CMMI, mejores prácticas a partir de ITIL y CObIT, para alinear la propuesta al negocio.



C

Control: Una vez definidos los métodos y mediciones para implementar y sustentar la mejora a través el tiempo; se monitorean y documentan, constantemente, las variables críticas, para conocer la estabilidad del proceso mejorado. A la vez que se realiza el desarrollo de competencias al personal operativo. El nuevo sistema debe ser institucionalizado a través de modificaciones en las políticas y procedimientos de compensación e incentivos, presupuestos, instrucciones operativas de trabajo y otras herramientas de gerenciamiento.

En los capítulos próximos, se vuelve sobre el proyecto DMAIC, para abarcar, en mayor

detalle, lo que representa e incluye cada una de sus fases. Se enfatiza que, DMAIC se utiliza cuando un producto o proceso, que existe dentro de la compañía, no cumple con ciertas especificaciones, o bien, no funciona adecuadamente.

1.1.3. Relaciones entre DMAIC y PDCA

La forma gráfica de representar un proceso DMAIC es muy similar al círculo de mejora continua de la calidad, de Deming, donde se destacan sus acciones por PDCA (Plan-Do-Check- Act). Además de las cinco fases que componen un DMAIC, algunos autores22 adicionan un paso más, que es la sinergia (Synergize, S), quedando representado por las siglas DMAIC-S. El concepto anterior se refiere a que, lo que ha ganado el grupo de trabajo, en cuanto a conocimiento y experiencia, con la aplicación del proyecto de Six Sigma, sea compartido con la totalidad de la organización. La comunicación y difusión de tal conocimiento, son absolutamente necesarias para el aprendizaje organizacional. Este es el principio de una organización ―inteligente‖.

Gráfico 1.1.3-1 Representación gráfica de DMAICS – PDCA

Publicado por Six Sigma US. ―What is Six Sigma‖

23

22

SIX SIGMA US. ―Step Six Synergize‖ [en línea]. Disponible en Internet: http://www.6sigma.us/dmaic-step-six-synergize.php [Consulta: 20 Mayo 2008] 23

SIX SIGMA US. ―What is Six Sigma‖ [en línea]. Disponible en Internet: http://www.6sigma.us/six-sigma.php [Consulta: 11 Diciembre 2007]

http://www.6sigma.us/dmaic-step-six-synergize.php

http://www.6sigma.us/dmaic-step-six-synergize.php

http://www.6sigma.us/six-sigma.php

http://www.6sigma.us/six-sigma.php



Diversas organizaciones han publicado investigaciones y estudios acerca de proyectos realizados con la metodología Six Sigma, donde la relacionan con la mejora continua de la calidad.

1.1.4. Ciclo de vida de un proyecto DMAIC

En el siguiente gráfico, se puede observar el ciclo de vida de un proyecto de DMAIC. Se ejemplifican en él, las preguntas que deberían satisfacerse en cada fase del mismo, y que determinarán las acciones, de acuerdo a los requerimientos, que deben llevarse a cabo. Las preguntas están definidas a través de un cuestionario base, no excluyente.

Gráfico 1.1.4-1 Ciclo de vida de un proyecto de DMAIC

Publicado por iSix Sigma, ―DMAIC Project Cycle Graphic‖24

24

ISIX SIGMA. ―DMAIC Project Cycle Graphic‖. Disponible en Internet: http://www.isixsigma.com/me/dmaic/ [Consulta: 11 Diciembre 2007]

http://www.isixsigma.com/me/dmaic/



1.1.5. Listado de herramientas para Six Sigma

En la metodología Six Sigma se utilizan diversas herramientas que ayudan a su consecución, y son comúnmente conocidas como DFSS tools (Design For Six Sigma tools). A continuación se enumeran algunas de ellas, no siendo exclusivas ni excluyentes, y que son útiles en las distintas etapas del proyecto.

Tabla 1.1.5-1 Herramientas de Six Sigma utilizadas en distintas fases del proyecto

Fase del Proyecto

Herramientas sugeridas

Definir

Carátula o capítulo del proyecto. Voice Of Customer tools (VOC), incluye las herramientas que

reflejan la voz del cliente (tales como encuestas, grupos de trabajos, cartas y tarjetas de comentarios).

Mapas de procesos. Quality Function Deployment (QFD), llamada casa de

calidad, diagramas de Suppliers-Inputs-Process-Outputs-Customers (SIPOCs), que corresponde a proveedores, entradas, proceso, salidas y clientes.

Benchmarking.

Medir

Análisis del sistema de mediciones. Análisis de datos exploratorios. Estadística descriptiva. Data Mining, o exploración exhaustiva de datos. Cartas de control. Análisis de Pareto.

Analizar

Diagramas de causa-efecto. Diagramas de estructura de árbol. Torbellino de ideas. Sheet - Process - Chart (SPC), o cartas de control estadístico

de procesos. Mapas de procesos. Diseño de experimentos. Test de hipótesis, estadística enumerativa. Estadística de inferencias (Xs e Ys). Failure mode and effects analysis (FMEA), o análisis de

modos de fallas y efectos. Simulaciones.

Mejorar

Force Field Diagram (FFD), o diagrama de fuerzas y restricciones, o diagrama de Kurt Lewin.

Diagrama de Pareto, diagrama causa-efecto, diagrama de estratificación, cartas de chequeo, diagramas o histogramas de



dispersión, gráficos y cartas de control (conocidas como las 7M tools).

Herramientas de gerenciamiento y manejo de proyectos. Estudio de prototipos y pilotos.

Controlar

SPC. FMEA. ISO 9000. Modelos de estimación de costos, presupuestos y cotizaciones. Sistema de reportes.

Con todo esto, se espera contar con la información suficiente de las fases del DMAIC para SS, y las herramientas que se pueden utilizar para el desarrollo e implementación de la metodología. En caso de ser necesario, se podrá indagar más profundo y realizar las consultas pertinentes a especialistas en la metodología, comúnmente llamados Green Belt (Cinturón Verde) o Black Belt (Cinturón Negro).



1.2. Tablero de control balanceado

El modelo denominado ―tablero de control balanceado‖ (Balanced ScoreCard, BSC) es un nuevo acercamiento para el gerenciamiento estratégico, que fue desarrollado a principios de los 90´s, en la Escuela de Negocio de Harvard, por los doctores Roberto Kaplan y David Norton; pero será tratado desde el punto de vista de Paul Arveson25. La generación de un tablero de gestión integrado le aporta, al área de tecnología de la información, el disponer de los indicadores claves para seguimiento, control y mejora de la actuación de la misma, como así también reflejar su estado de funcionamiento, evaluar riesgos, disparar acciones preventivas y correctivas, poder compararse con otras áreas de la misma especialidad y permitir a las unidades de negocio tener un mayor aprovechamiento de recursos que, a posteriori, implicaría un aumento probable en la rentabilidad anual26. Aunque todos los modelos presentan ciertas debilidades e imprecisiones, cada uno posee determinadas fortalezas. En este caso, BSC proporciona una descripción clara en cuanto a los puntos clave que las compañías deberían medir, para ―balancear‖ la perspectiva financiera.

1.2.1. ¿Qué es un tablero de control balanceado?

El BSC es un modelo de gerenciamiento (no sólo un sistema de medida), que permite a las organizaciones clarificar su visión y estrategia, traduciéndolas en acción. Permite la retroalimentación de los procesos internos del negocio y de los resultados externos, para mejorar continuamente las estrategias y su funcionamiento. Kaplan y Norton27 evalúan la aplicación del BSC "para dirigir y evaluar la información que las compañías deben considerar, para crear valor futuro, que son la inversión en clientes, proveedores, empleados, procesos, tecnología e innovación‖. En este sentido, el BSC sugiere ver la organización a partir de cuatro perspectivas:

Perspectiva del aprendizaje y crecimiento.

Perspectiva del proceso de negocio.

Perspectiva del cliente.

Perspectiva financiera. En el siguiente gráfico se reflejan las interacciones entre los factores claves y la visión organizacional de la empresa, de manera más clara.

25

ARVESON, PAUL.1998. ―What is the Balanced ScoreCard‖. [en línea]. Disponible en Internet: http://www.balancedscorecard.org/basics/bsc1.html [Consulta: 11 Diciembre 2007] 26

KAPLAN, R.S. y NORTON, D.S., op. cit. 27

KAPLAN, R.S. y NORTON, D.S., op. cit.

http://www.balancedscorecard.org/basics/bsc1.html



Gráfico 1.2.1-1 Factores claves y visión estratégica organizacional

Visión y Estrategia

FinanzasPara ser exitosos

financieramente, cómo

deberiamos aparecer antes

nuestros accionistas

Procesos internos de

negocios

Para satisfacer a nuestros

accionistas y clientes qué procesos

de negocios deberíamos mejorar

Aprendizaje y Crecimiento

Para lograr nuestra visión, cómo

sustanciaremos nuestra habilidad

al cambio y a la mejora

Clientes

Para lograr nuestra visión cómo

deberíamos ser ante nuestros

clientes

La metodología BSC se construye sobre algunos conceptos dominantes de las ideas anteriores de gerenciamiento, tales como gestión de la calidad total o Total Quality Management (TQM), incluyendo calidad definida por el cliente o mercado, mejora continua, delegación de toma de decisiones a subordinados (empowerment) y, sobre todo, mediciones respecto a la gerencia y su retroalimentación. En la actividad industrial tradicional, "control de calidad" y "cero defectos" eran las palabras claves e intocables. Para prevenir que el cliente recibiera productos de mala calidad, los esfuerzos se centraban en la inspección y prueba sólo en los extremos de la cadena de producción. Según lo precisado por Arveson28, donde hace referencia a Deming, el problema con este acercamiento es que las causas verdaderas de los defectos podrían no ser identificadas, y seguirían ocurriendo.

28

ARVESON, PAUL.1998. ―What is the Balanced Scorecard?‖ [en línea]. Disponible en Internet: http://www.balancedscorecard.org/basics/bsc1.html [Consulta: 11 Diciembre 2007]

http://www.balancedscorecard.org/basics/bsc1.html



Observó además que, las variaciones pueden ocurrir en cualquiera de los pasos del proceso productivo, y sus causas debían ser identificadas y solucionadas allí. Si esto podía ser realizado, entonces sería una manera de reducir los defectos y mejorar la calidad del producto indefinidamente. Para establecer tal actividad, Deming remarcó que todos los procesos del negocio deben ser parte de un sistema retroalimentado. Los datos de la retroalimentación deben ser examinados por los encargados o responsables de los procesos, para determinar las causas de la variación, y las etapas con problemas significativos, para centrar allí la atención y encontrar soluciones. El BSC incorpora la retroalimentación de las salidas del proceso, como en TQM, pero también agrega un lazo alrededor de los resultados de las estrategias de negocio. Esto genera un proceso de ―retroalimentación de doble lazo".

1.2.2. ¿Por qué se necesitan las métricas?

Una frase muy difundida, de Lord Kelvin, dice: ―si no puedes medirlo, no puedes mejorarlo‖ (“If you can not measure it, you can not improve it” 29). Las métricas deben definirse en base a las prioridades del plan estratégico, que proveerán a la gerencia los indicadores que desean monitorear. Los procesos serán entonces diseñados para recolectar la información relevante de tales métricas, que llevadas a un valor numérico o cualitativo, permitan su almacenamiento, visualización y su posterior análisis. Las personas que toman las decisiones examinaran las salidas de los procesos medidos, las estrategias y registraran los resultados para guiar a la compañía, implementando la retroalimentación en el proceso. Entonces, el valor de las métricas es su habilidad de proveer información relevante para la retroalimentación:

De la estrategia, mostrando la situación actual de la organización desde distintas

perspectivas, para las personas encargadas de tomar decisiones.

Del diagnóstico, exponiendo los procesos que están bajo mejora continua.

De las tendencias, en cuanto a la performance a través del tiempo, y cómo estas

son monitoreadas.

Del monitoreo, acerca de los sistemas de medición y el modo en que las

métricas deben ser controladas.

De las entradas cuantitativas, para pronosticar métodos y modelos de decisión

de los sistemas soportados. El logro de realizar mediciones –monitoreo- es que permite a los gerentes ver su propia compañía más claramente, desde distintas perspectivas y, por ende, poder tomar decisiones a largo plazo más sabias.

29

LORD KELVIN. ―Quotations from Lord Kelvin‖ [ en línea]. Disponible en Internet: http://zapatopi.net/kelvin/quotes/ [Consulta: 11 Diciembre 2007]

http://zapatopi.net/kelvin/quotes/



En “Criteria for Performance Excellence”, del programa de calidad nacional de Baldrige30, se reitera la concepción anterior acerca de la importancia de las métricas para la gerencia:

―Los negocios modernos dependen, sobre todo, de mediciones y análisis de la performance. Las mediciones deben derivar de la estrategia de la compañía y proveer los datos críticos e información acerca de los procesos claves, salidas y resultados de procesos o negocios. Los datos y la información necesitan de mediciones de performance y de mejoras de diferentes tipos; incluyendo la performance del cliente, producto y servicio, operaciones, mercado, análisis de la competencia, proveedores, satisfacción de empleados, costos y estado financiero. El análisis requiere el uso de datos para determinar tendencias, proyecciones, análisis de causa-efecto, que no podrían ser evidentes sin análisis. Los datos y su análisis dan soporte a una gran variedad de propósitos de la compañía, tales como planeamiento, revisión de la performance, mejoras en las operaciones, comparaciones de la performance entre la competencia y con las mejoras practicas (benchmarking). Una mayor consideración respecto a la mejora del desempeño o performance, involucra la creación y el uso de indicadores. Los indicadores son características medibles o mesurables de los productos, servicios, procesos y operaciones de la compañía, que se usan para el seguimiento y la mejora de la performance. Éstos deberían ser seleccionados para reflejar los factores que llevan a mejorar la performance del cliente, operacional y financiera. Un extensivo conjunto de indicadores atados o asociados al cliente y la performance de la empresa, requiere representar claramente la alineación de todas las actividades con las metas u objetivos del negocio. A través del análisis de datos, los procesos de seguimiento, mediciones e indicadores deberían ayudar a evaluar y re-alinear la empresa hacia los logros fijados‖

Los conceptos hasta aquí expuestos irán complementando el desarrollo del estudio, mencionando los puntos comunes o nexos entre ellos, y extrayendo su aplicación a nuestro caso.

30

BALDRIGE NATIONAL QUALITY PROGRAM. ‖Criteria for Performance Excellence‖ [en línea]. Disponible en Internet: http://baldrige.nist.gov/Business_Criteria.htm [Consulta: 11 Diciembre 2007]

http://baldrige.nist.gov/Business_Criteria.htm



1.3. Objetivos de control para la información y tecnología relacionada

El modelo CObIT (Control Objetives for Information and related Technology) incluye estándares sobre puntos de control que garantizan el cumplimiento de los procesos y permiten su control. Éstos proveen información detallada para administrar tales procesos. En otras palabras, es una guía para la gestión de la IT.

El CObIT incluye una serie de recursos como, por ejemplo, sumario ejecutivo, framework, control de objetivos, mapas de auditoría y un conjunto de procesos de trabajo ya establecidos y empleados por el mercado entre los cuales se incluye el CMM (Capability Maturity Model), la ISO 9000 (para calidad), BS7799/ISSO 17799 (normas para seguridad de la información) y el ITIL (para gestión del departamento de IT).

La metodología está dirigida a tres niveles diferentes: para gerentes que necesitan evaluar los riesgos y controlar las inversiones de TI; para los usuarios que necesitan asegurar la calidad de los servicios prestados a los clientes internos y externos; y para auditores que necesitan evaluar el trabajo de gestión de la IT y aconsejar el control interno de la organización. El foco principal es apuntar dónde deben realizarse las mejoras.

Para muchas empresas, la información y la tecnología que las soportan representan sus más valiosos activos, aunque con frecuencia son poco entendidos. Estas empresas reconocen los beneficios de la tecnología de información y la utilizan para impulsar el valor de sus interesados (stakeholders). Estas empresas también entienden y administran los riesgos asociados, tales como el aumento en requerimientos regulatorios, así como la dependencia crítica de muchos procesos de negocio en la IT. La necesidad del aseguramiento del valor de la IT, la administración de los riesgos asociados a ella, así como el incremento de requerimientos para controlar la información, se entienden ahora como elementos clave del gobierno de la empresa. El valor, el riesgo y el control constituyen la esencia del gobierno de la IT. Este es responsabilidad de los ejecutivos, del consejo de directores; y consta de liderazgo, estructuras y procesos organizacionales que garantizan que la TI de la empresa sostiene y extiende las estrategias y objetivos organizacionales.

1.3.1. Relaciones entre ISACA, CObIT y COSO

La organización que administra y regula todo lo relacionado con CObIT es la asociación para la auditoría y el control de sistemas de información, conocida como ISACA31 (Information System Audit and Control Association). Además del control de

31

ISACA. ―CObIT Executive Summary & Framework‖.[en línea] Disponible en Internet: http://www.isaca.org/Template.cfm?Section=COBIT6&Template=/TaggedPage/TaggedPageDisplay.cfm&TPLID=55&ContentID=7981 [Consulta: 11 Diciembre 2007]

http://www.isaca.org/Template.cfm?Section=COBIT6&Template=/TaggedPage/TaggedPageDisplay.cfm&TPLID=55&ContentID=7981

http://www.isaca.org/Template.cfm?Section=COBIT6&Template=/TaggedPage/TaggedPageDisplay.cfm&TPLID=55&ContentID=7981



auditorías, realiza proyectos de investigación para expandir los conocimientos, gobierno y control de la IT. Sus guías y estándares para el control de sistemas de información han sido aceptados y utilizados a nivel internacional. Los recursos de CObIT deben utilizarse como fuente de asesoría con respecto a las mejores prácticas; proporciona un conjunto detallado de controles y de técnicas de control para el entorno de la administración/gestión de sistemas de información. La selección del material más relevante en CObIT, aplicable al alcance de la auditoría en particular, se basa en la selección de procesos específicos de para la IT, considerando además sus criterios de información. CObIT está destinado para ser utilizado por la gerencia de la empresa y de la IT, así como por los auditores de sistemas de información; por lo tanto, su uso permite la comprensión de los objetivos del negocio, la comunicación de las mejores prácticas y las recomendaciones que deben hacerse, con base en estándares de referencia comúnmente comprendidos y respetados. ISACA ha definido una guía como el nivel mínimo de desempeño aceptable, requerido para cumplir con las responsabilidades profesionales, indicadas en el Código de Ética Profesional de ISACA. La publicación no debe considerarse como excluyente de otros procedimientos y pruebas que estén razonablemente dirigidos a la obtención de los mismos resultados. Para determinar la aplicabilidad de cualquier procedimiento o prueba específicos, el profesional de control debe aplicar su buen juicio a las circunstancias específicas presentadas por el entorno particular de sistemas o de la tecnología de información. La necesidad de asegurar el valor de la IT, del gerenciamiento de los riesgos y del incremento de control de la información, es ahora entendida como elemento clave para el gobierno de la empresa. El gerenciamiento o gobierno de la IT es responsabilidad de los ejecutivos y del directorio, y consiste en el liderazgo, estructuras organizacionales y procesos que aseguran que la IT de la empresa mantiene y cumple con los objetivos y estrategias del negocio. Más aún, el gobierno de la IT integra e institucionaliza las buenas prácticas para garantizar que la IT de la empresa sirve como base a los objetivos del negocio. De esta manera, el gobierno de ella facilita que la empresa aproveche al máximo su información, optimizando así los beneficios, capitalizando las oportunidades y ganando ventajas competitivas. Estos resultados requieren un marco de referencia para controlar la IT, que se ajuste y sirva como soporte al Committee Of Sponsoring Organisations Of The Treadway Commission (Control interno—Marco de referencia integrado); que es el marco de referencia de control ampliamente aceptado para gobierno de la empresa y para la administración de riesgos, así como marcos compatibles similares. El comité de organizaciones auspiciantes de la comisión de control interno de Treadway, COSO32 (Committee Of Sponsoring Organizations), publicó el Marco Integrado de Control Interno (Internal Control Integrated Framework) para ayudar a empresas y otras entidades a evaluar y mejorar sus sistemas de control interno. El denominado ―Informe COSO‖ surge como respuesta a las inquietudes que plantean la

32

HARRIS, TRISH. ‖COSO Releases Discussion Document with Guidance on Monitoring Internal Control‖. [en línea]. 17 Septiembre 2007. Disponible en Internet: http://www.theiia.org/theiia/newsroom/news-releases/?search=COSO&C=1042&I=4153 [Consulta: 11 Diciembre 2007]

http://www.theiia.org/theiia/newsroom/news-releases/?search=COSO&C=1042&I=4153



diversidad de conceptos, definiciones e interpretaciones existentes en torno al control interno. Realizado con el objetivo de ayudar a las organizaciones a mejorar el control de sus actividades, estableciendo un marco de conceptos que permita una definición común y la identificación de sus componentes. Las organizaciones deben satisfacer la calidad, los requerimientos fiduciarios y de seguridad de su información, así como de todos sus activos. La dirección también debe optimizar el uso de los recursos disponibles de IT, incluyendo aplicaciones, información, infraestructura y personas. Para descargar estas responsabilidades, así como para lograr sus objetivos, la dirección debe entender el estatus de su arquitectura empresarial para la IT y decidir qué tipo de gobierno y control debe aplicar.

1.3.2. CObIT como marco de referencia

Los Objetivos de Control para la Información y la Tecnología relacionada (CObIT) brindan buenas prácticas a través de un marco de trabajo de dominios y procesos, y presenta las actividades en una estructura manejable y lógica. Las buenas prácticas de CObIT representan el consenso de los expertos. Están enfocadas fuertemente en el control y menos en la ejecución. Estas prácticas ayudarán a optimizar las inversiones facilitadas por la TI, asegurarán la entrega del servicio y brindarán una medida contra la cual juzgar cuando las cosas no vayan bien. Para que la IT tenga éxito en satisfacer los requerimientos del negocio, la dirección debe implantar un sistema de control interno o un marco de trabajo. El marco de trabajo de control CObIT contribuye a estas necesidades de la siguiente manera:

Estableciendo un vínculo con los requerimientos del negocio Organizando las actividades de IT en un modelo de procesos generalmente

aceptado Identificando los principales recursos de IT a ser utilizados Definiendo los objetivos de control gerenciales a ser considerados

La orientación al negocio que enfoca CObIT consiste en vincular las metas de negocio con las metas de IT, brindando métricas y modelos de madurez para medir sus logros, e identificando las responsabilidades asociadas de los propietarios de los procesos de negocio y de IT. En conclusión, proporciona un marco de referencia administrativo orientado hacia una continua y proactiva auto-evaluación del control.

1.3.3. La información gerencial en CObIT

El enfoque hacia procesos de CObIT se ilustra con un modelo de procesos, el cual subdivide IT en 34 procesos de acuerdo a las áreas de responsabilidad de planear, construir, ejecutar y monitorear, ofreciendo una visión de punta a punta de la IT. Los



conceptos de arquitectura empresarial ayudan a identificar aquellos recursos esenciales para el éxito de los procesos, es decir, aplicaciones, información, infraestructura y personas. En resumen, para proporcionar la información que la empresa necesita para lograr sus objetivos, los recursos de IT deben ser administrados por un conjunto de procesos agrupados de forma natural. Pero, ¿cómo puede la empresa poner bajo control la IT de tal manera que genere la información que la empresa necesita? ¿Cómo puede administrar los riesgos y asegurar los recursos de IT de los cuales depende tanto? ¿Cómo puede la empresa asegurar que IT logre sus objetivos y soporte los del negocio?

En busca de respuestas a las cuestiones planteadas anteriormente, se arriba a las siguientes conclusiones:

Primero, la dirección requiere objetivos de control que definan la última meta de implantar políticas, procedimientos, prácticas y estructuras organizacionales diseñadas para brindar un nivel razonable para garantizar que: se alcancen los objetivos del negocio; y se prevengan o se detecten y corrijan los eventos no deseados.

En segundo lugar, en los complejos ambientes de hoy en día, la dirección busca continuamente información oportuna y condensada, para tomar decisiones difíciles respecto a riesgos y controles, de manera rápida y exitosa.

¿Qué se debe medir y cómo?

Las empresas requieren una medición objetiva de dónde se encuentran y dónde se requieren mejoras, y deben implantar una caja de herramientas gerenciales para monitorear esta mejora. El gráfico 1.3.3-1 muestra algunas preguntas frecuentes y las herramientas gerenciales de información usadas para encontrar las respuestas, aunque estos tableros de control requieren indicadores, los marcadores de puntuación requieren mediciones y los Benchmarking requieren una escala de comparación. Una respuesta a los requerimientos de determinar y monitorear el nivel apropiado de control y desempeño de IT son las definiciones específicas de CObIT de los siguientes conceptos:

• Benchmarking de la capacidad de los procesos de IT, expresada como

modelos de madurez, derivados del Modelo de Madurez de la Capacidad del Instituto de Ingeniería de Software.

• Metas y métricas de los procesos de IT para definir y medir sus resultados y

su desempeño, basados en los principios de balanced business scorecard de Kaplan y Norton.

• Metas de actividades para controlar estos procesos, con base en los objetivos de control detallados de CObIT.

La evaluación de la capacidad de los procesos basada en los modelos de madurez de CObIT es una parte clave de la implementación del gobierno de IT. Después de



identificar los procesos y controles críticos de IT, el modelado de la madurez permite identificar y demostrar a la dirección las brechas en la capacidad. Entonces se pueden crear planes de acción para llevar estos procesos hasta el nivel objetivo de capacidad deseado.

Gráfico 1.3.3-1 Información gerencial

Publicado por ISACA. ―CObIT Executive Summary & Framework‖ 8

1.3.4. Factores críticos del gobierno de IT

El modelo CObIT da soporte al gobierno de la IT (gráfico 1.3.4-1) al brindar un marco de trabajo que garantiza que:

• IT está alineada con el negocio • IT capacita el negocio y maximiza los beneficios • Los recursos de IT se usen de manera responsable • Los riesgos de IT se administren apropiadamente

La medición del desempeño es esencial para el gobierno de IT. CObIT le da soporte e incluye el establecimiento y el monitoreo de objetivos que se puedan medir, referentes a lo que los procesos de IT requieren generar (resultado del proceso) y cómo lo generan (capacidad y desempeño del proceso). Muchos estudios han identificado que la falta de transparencia en los costos, valor y riesgos de IT, es uno de los más importantes impulsores para el gobierno de IT. Mientras las otras áreas consideradas contribuyen, la transparencia se logra de forma principal por medio de la medición del desempeño. Estas áreas focales de gobierno de IT describen los tópicos en los que la dirección ejecutiva requiere poner atención para gobernar la IT en sus empresas. La dirección operacional usa procesos para organizar y administrar las actividades cotidianas de IT. CObIT brinda un modelo de procesos genéricos que representa todos los procesos que



normalmente se encuentran en las funciones de IT, ofreciendo un modelo de referencia común entendible para los gerentes operacionales de la IT y del negocio. Se establecieron equivalencias entre los modelos de procesos CObIT y las áreas focales del gobierno de TI, ofreciendo así un puente entre lo que los gerentes operacionales deben realizar y lo que los ejecutivos desean gobernar

Gráfico 1.3.4-1 Factores críticos del gobierno de IT

Alineación estratégica se enfoca en garantizar el vínculo entre los planes de negocio y de IT; en definir, mantener y

validar la propuesta de valor de IT; y en alinear las operaciones de TI con las operaciones de la empresa.

Entrega de valor se refiere a ejecutar la propuesta de valor a lo largo del ciclo de entrega, asegurando que IT genere los beneficios prometidos en la estrategia, concentrándose en

optimizar los costos y en brindar el valor intrínseco de la IT. Administración de recursos se trata de la inversión óptima,

así como la administración adecuada de los recursos críticos de IT, aplicaciones, información, infraestructura y personas. Los temas claves se refieren a la optimización de

conocimiento y de infraestructura. Administración de riesgos requiere conciencia de los riesgos

por parte de los altos ejecutivos de la empresa, un claro entendimiento del deseo de riesgo que tiene la empresa, comprender los requerimientos de cumplimiento, transparencia

de los riesgos significativos para la empresa, y la inclusión de las responsabilidades de administración de riesgos dentro de la organización.

Medición del desempeño rastrea y monitorea la estrategia de implementación, la terminación del proyecto, el uso de los recursos, el desempeño de los procesos y la entrega del servicio, con el uso, por ejemplo, de balanced scorecards que traducen la estrategia

en acción para lograr las metas que se puedan medir más allá del registro convencional.

Publicado por ISACA. ―CObIT Executive Summary & Framework‖

Para lograr un gobierno efectivo, los ejecutivos esperan que los controles a ser implementados por los gerentes operacionales se encuentren dentro de un marco de control definido para todos los procesos de IT. Los objetivos de control de IT de CObIT están organizados por proceso de IT; por lo tanto, el marco de trabajo brinda un vínculo claro entre los requerimientos de gobierno de IT, los procesos de IT y sus controles. CObIT se enfoca en qué se requiere para lograr una administración y un control adecuado de la IT, y se posiciona en un nivel alto. CObIT ha sido alineado y armonizado con otros estándares y mejores prácticas más detallados de IT. Actúa como un integrador de todos estos materiales guía, resumiendo los objetivos clave bajo un mismo marco de trabajo integral que también se vincula con los requerimientos de gobierno y de negocios. COSO33 (y similares marcos de trabajo) es generalmente aceptado como el marco de trabajo de control interno para las empresas. CObIT es el marco de trabajo de control interno generalmente aceptado para la IT.

33

HARRIS, TRISH, op.cit.



Todos estos componentes de CObIT se interrelacionan, ofreciendo soporte para las necesidades de gobierno, de administración, de control y de auditoría de los distintos interesados, como se muestra en el gráfico 1.3.4-2

Gráfico 1.3.4-2 Relaciones de los componentes de CObIT

Publicado por ISACA. ―CObIT Executive Summary & Framework‖

CObIT es un marco de referencia y un juego de herramientas de soporte que permiten a la gerencia cerrar la brecha con respecto a los requerimientos de control, temas técnicos y riesgos de negocio, y comunicar ese nivel de control a los participantes. Permite el desarrollo de políticas claras y de buenas prácticas para control de IT a través de las empresas. Constantemente se actualiza y armoniza con otros estándares. Por lo tanto, CObIT se ha convertido en el integrador de las mejores prácticas de IT y el marco de referencia general para el gobierno de ella, que ayuda a comprender y administrar los riesgos y beneficios asociados. La estructura de procesos de CObIT y su enfoque de alto nivel orientado al negocio brindan una visión completa de la IT y de las decisiones a tomar acerca de ella. Los beneficios de implementar CObIT como marco de referencia de gobierno sobre la IT incluyen:

• Mejor alineación, con base en su enfoque de negocios. • Una visión, entendible para la gerencia, de lo que hace TI. • Propiedad y responsabilidades claras, con base en su orientación a procesos. • Aceptación general de terceros y reguladores. • Entendimiento compartido entre todos los participantes, con base en un lenguaje

común.



• Cumplimiento de los requerimientos COSO para el ambiente de control de TI.

1.3.5. Estados de madurez del modelo de CObIT

Modelos de madurez

Los modelos de madurez empezaron a ser requeridos por los directivos de empresas corporativas y públicas al considerar qué tan bien se estaba administrando la IT. Para poder responder a esto, se debe desarrollar un plan de negocio para mejorar y alcanzar el nivel apropiado de administración y control sobre la infraestructura de información. Se debe considerar el equilibrio del costo beneficio y estas preguntas relacionadas:

¿Qué está haciendo la competencia en la industria, y cómo es la propia posición en relación a ellos?

¿Cuáles son las mejores prácticas aceptables en la industria, y cómo se esta posicionado con respecto a estas?

Con base en esas comparaciones, ¿se puede decir que se está haciendo lo suficiente?

¿Cómo identificar lo que se requiere hacer para alcanzar un nivel adecuado de administración y control sobre los procesos de IT?

La gerencia de la IT busca constantemente herramientas de evaluación por benchmarking y otras de auto-evaluación como respuesta a la necesidad de saber qué hacer de manera eficiente. Se debe contar necesariamente con:

1. Una medición relativa de dónde se encuentra la empresa. 2. Una manera de decidir hacia dónde ir de forma eficiente. 3. Una herramienta para medir el avance contra la meta.

El modelado de la madurez para la administración y el control de los procesos de IT se basa en un método de evaluación de la organización, de tal forma que se pueda evaluar a sí misma desde un nivel de no-existente (0) hasta un nivel de optimizado (5). Este enfoque se deriva del modelo de madurez que el Software Engineering Institute (SEI) definió para la madurez de la capacidad del desarrollo de software, CMMI. CObIT introduce algunos cambios al mismo adaptándolo a la IT, este modelo también se aplica con algunas adaptaciones a distintas áreas de la empresa como ser en el área de finanzas, de recursos humanos y otras. Los niveles de madurez están diseñados como perfiles de procesos de IT que una empresa reconocería como descripciones de estados posibles, actuales y futuros. No están diseñados para ser usados como un modelo limitante, donde no se puede pasar al nivel superior sin haber cumplido todas las condiciones del nivel inferior. En CObIT se evalúan los 34 procesos definidos, identificando:

La actual performance de la empresa



El estado actual de la industria, comparaciones.

Las metas de la empresa a mejorar, donde la empresa quiere estar.

El crecimiento requerido (camino a recorrer), de cómo es a cómo debería ser. En el gráfico 1.3.5-1 se puede ver la representación de modelos de madurez., donde se especifica los seis estados siguientes:

0 - No se aplican procesos administrativos en lo absoluto. 1 - Los procesos son ad hoc y desorganizados. 2 - Los procesos siguen un patrón regular. 3 - Los procesos se documentan y se comunican. 4 - Los procesos se monitorean y se miden. 5 - Las buenas prácticas se siguen y se automatizan.

Gráfico 1.3.5-1 Representación gráfica de los modelos de madurez


1.3.6. Marco de trabajo de CObIT

El marco de trabajo CObIT relaciona los requerimientos de información y de gobierno a los objetivos de la función de servicio de la IT. El modelo de procesos CObIT permite que las actividades de IT y los recursos que los soportan sean administrados y controlados, basados en los objetivos de control de este, y alineados y monitoreados. Para resumir, los recursos de la IT son manejados sus procesos, para lograr las metas que respondan a los requerimientos del negocio. Este es el principio básico del marco de trabajo CObIT, como se ilustra en el cubo CObIT (gráfico 1.3.6-1)



En el cubo de CObIT se observan fácilmente las tres dimensiones, y sus interrelaciones:

Requerimientos del negocio (Business Requirements), a través de la

efectividad, eficiencia, confidencialidad, integridad, disponibilidad, regulaciones (estándares requeridos, términos contractuales o gubernamentales) y confiabilidad.

Procesos de IT (IT Processes), a través de los dominios, procesos y

actividades.

Recursos de IT (IT Resources), a través de las aplicaciones, información,

infraestructura y personal.

Gráfico 1.3.6-1 El cubo de CObIT


En detalle, el marco de trabajo general CObIT se muestra en el gráfico 1.3.6-2, con el modelo de procesos de CObIT compuesto de cuatro dominios que contienen 34 procesos genéricos, administrando los recursos de IT para proporcionar información al negocio de acuerdo con sus requerimientos y los de gobierno. Los cuatro dominios principales, que conformarán un círculo de calidad, se postulan como:

PO: planear y organizar AI: adquirir e implementar DS: entrega (delivery) y soporte ME: monitorear y evaluar



Gráfico 1.3.6-2 Marco de trabajo de CObIT




1.3.7. Procesos de CObIT

A continuación se mencionan los 34 procesos de CObIT: PO1: Definir un plan estratégico de IT PO2: Definir la arquitectura de la información. PO3: Determinar la dirección tecnológica. PO4: Definir los procesos de IT, organización y relaciones. PO5: Administrar las inversiones de IT. PO6: Comunicar a la gerencia o directorio el plan y dirección a seguir. PO7: Administrar los recursos humanos de IT. PO8: Administrar la calidad. PO9: Evaluar y administrar los riesgos de IT. PO10: Administrar proyectos. AI1: Identificar soluciones automatizadas. AI2: Adquirir y mantener las aplicaciones de software. AI3: Adquirir y mantener la infraestructura de la información. AI4: Identificar operaciones o procesos y usarlos. AI5: Adquirir recursos para IT. AI6: Administrar los cambios. AI7: Instalar y documentar soluciones y cambios. DS1: Definir y administrar los niveles de servicio. DS2: Administrar los servicios provistos por terceras partes. DS3: Administrar la actuación o performance y la capacidad. DS4: Asegurar la continuidad del servicio. DS5: Asegurar el cumplimiento de seguridad de IT. DS6: Identificar y alocar costos. DS7: Educar y entrenar a los usuarios. DS8: Administrar el soporte a usuarios e incidentes de IT. DS9: Administrar la configuración o cambios de la mismas. DS10: Administrar o gestionar los problemas de IT. DS11: Administrar los datos. DS12: Administrar la seguridad física. DS13: Administrar las operaciones. ME1: Monitorear y evaluar la actuación o performance de IT ME2: Monitorear y evaluar los controles internos. ME3: Asegurar el cumplimiento con requerimientos externos (legislación). ME4: Proveer del gobierno de IT.



Todos los potenciales usuarios pueden beneficiarse de utilizar el contenido de CObIT, como también su acercamiento al gerenciamiento y gobierno en conjunto con los demás estándares como:

ITIL34 para la provisión de servicios (ISO 20000).

CMMI 35 para el desarrollo de soluciones.

ISO 2700136 para la seguridad de la información que reemplazó a la ISO 17799.

PMBOK o PRINCE237 para gerenciamiento o administración de proyectos.

COSO o su organización de auditores THEEIA38 En el siguiente gráfico se trata de reflejar cómo interactúan todos y cada uno de los procesos y estándares hasta aquí mencionados en el modelo de la IT.

Gráfico 1.3.7-1 Estándares y su relación con IT

Publicado por la IEEE Argentina. ―Que es ITIL‖ 39

34

ITIL(INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY). ―ITIL FAQ‖ [en línea]. Disponible en Internet: http://www.itlibrary.org/index.php?page=ITIL_FAQ [Consulta: 11 Diciembre 2007] 35

CARNEGIE MELLON UNIVERSITY. 2007. ―What is CMMI?‖ [en línea]. Disponible en Internet: http://www.sei.cmu.edu/cmmi/general/index.html [Consulta: 11 Diciembre 2007] 36

IT GOVERNANCE. 2007. ―What is ISO/IEC 27001?‖ [en línea]. Disponible en Internet: http://www.27001.com/27001.aspx [Consulta: 11 Diciembre 2007] 37

OFFICE OF GOVERNMENT COMMERCE. 2007. ―What does PRINCE2 work?‖ [en línea]. Disponible en Internet: http://www.ogc.gov.uk/methods_prince_2__whatisit.asp [Consulta: 11 Diciembre 2007] 38

THE INSTITUTE OF INTERNAL AUDITORS. 2007. ―About us‖. [en línea]. Disponible en Internet: http://www.theiia.org/theiia/ [Consulta: 11 Diciembre 2007] 39

IEEE ARGENTINA. ―Que es ITIL‖ [en línea]. Disponible en Internet: www.ieee.org.ar/downloads/2006-hrabinsky-itil.pdf [Consulta: 11 Diciembre 2007]

http://www.itlibrary.org/index.php?page=ITIL_FAQ

http://www.sei.cmu.edu/cmmi/general/index.html

http://www.27001.com/27001.aspx

http://www.ogc.gov.uk/methods_prince_2__whatisit.asp

http://www.theiia.org/theiia/

http://www.ieee.org.ar/downloads/2006-hrabinsky-itil.pdf

http://www.ieee.org.ar/downloads/2006-hrabinsky-itil.pdf



Diferentes leyes y regulaciones internacionales, como las que se mencionan a continuación, son además, marcos regulatorios para empresas que operan con el exterior, y buscan que los estándares se actualicen y ajusten a ellas. Algunos ejemplos muy conocidos son los siguientes:

Sarbanes-Oxley40 (SOx).

Basel II41.

Payment Card Industry Data Security Standard 42 (PCI- DSS).

Wet Bescherming Persoonsgegevens43 (Personal Data Protection Act) (WBP).

Generally Accepted Accounting Principles in the United States44 (US GAAP).

US Export Control Regulations for encryption technologies45.

40

SARBANES-OXLEY. ―Sarbanes-Oxley Act of 2002‖. [en línea]. Disponible en Internet: http://www.sarbanes-oxley.com/section.php [Consulta: 04 Marzo 2008] 41

BASEL II - REVISED INTERNATIONAL CAPITAL FRAMEWORK. ―Convergencia internacional de

medidas y normas de capital‖. [en línea]. Disponible en Internet: http://www.bis.org/publ/bcbs107esp.htm [Consulta: 04 Marzo 2008] 42

PCI SECURITY STANDART COUNCIL. ‖PCI Data Security Standard‖. [en línea]. Disponible en Internet: https://www.pcisecuritystandards.org/ [Consulta: 04 Marzo 2008] 43

WET BESCHERMING PERSOONSGEGEVENS (WBP). ―Personal Data Protection Act‖. [en línea]. Disponible en Internet: http://home.planet.nl/~privacy1/wbp_en_rev.htm [Consulta: 04 Marzo 2008] 44

US GAAP. ―US GAAP by Topic‖. [en línea]. Disponible en Internet: http://cpaclass.com/gaap/gaap-us-101.htm [Consulta: 04 Marzo 2008] 45

US DEPARTMENT OF COMMERCE. ―Introduction to Commerce Department Export Controls‖. [en línea]. Disponible en Internet: http://www.bis.doc.gov/licensing/exportingbasics.htm [Consulta: 04 Marzo 2008]

http://www.sarbanes-oxley.com/section.php

http://www.bis.org/publ/bcbs107esp.htm

https://www.pcisecuritystandards.org/

http://home.planet.nl/~privacy1/wbp_en_rev.htm

http://cpaclass.com/gaap/gaap-us-101.htm

http://cpaclass.com/gaap/gaap-us-101.htm

http://www.bis.doc.gov/licensing/exportingbasics.htm



1.4. Librerías de infraestructura de la tecnología de la información

Se realizará una breve revisión del concepto de librerías de infraestructura para la tecnología de la información (Information Technology Infrastructure Library, ITIL46. Como complemento se puede acceder a la información en el sitio oficial de ITIL47. ITIL es un estándar de aplicación y aseguramiento de mejores prácticas, con el fin de alinear la tecnología con los objetivos de negocio. ITIL actualiza constantemente sus proyectos, siendo apoyado por un esquema de evaluaciones completo, organizaciones de formación acreditadas y herramientas de asesoramiento e implementación.

El gerenciamiento de los servicios de la IT (IT Service Management, ITSM) de acuerdo a ITIL, está orientado a los beneficios y la eficacia hacia el cliente. El logro de las metas y objetivos del negocio se cumplen simultáneamente con las especificaciones internas y externas (políticas y regulaciones), como un pre-requisito fundamental para asegurar el éxito de la compañía en el mediano y largo plazo. ITSM permite obtener las enormes ventajas del enfoque de las mejores prácticas. Como ITSM es conducido tanto por la tecnología como la enorme variedad de ambientes organizacionales en los cuales opera, se encuentra en un estado de la evolución constante. Las mejores prácticas, basadas en asesoramiento experto y en los aportes de los usuarios de ITIL, es a su vez tanto corriente como práctica, combinando los pensamiento vigentes y dirección de sentido común.

Las distintas disciplinas de ITIL están orientadas especialmente a la parte operativa. Más adelante se profundiza esta afirmación, y se analiza cómo interactúan los diferentes modelos de gerenciamiento, CObIT, ITIL e ISO 17799 o ISO 27000.

1.4.1. Gerenciamiento de servicios de IT

El IT Service Management (ITSM) es el marco de trabajo para planear, controlar, chequear, coordinar todas las actividades y recursos relevantes de la IT, con el principal objetivo de lograr los proyectos operativos y estratégicos de la empresa. Existe también la función Service Desk, que describe las mejores prácticas para establecer y administrar un punto central de contacto entre los usuarios de los servicios de la IT. Sus responsabilidades más importantes son monitorear los incidentes y la comunicación con los usuarios. En la figura siguiente se muestra como la función del Service Desk sirve como punto de contacto para varios procesos de ITSM.

46

ITIL GLENFIS PORTAL. ―What is ITIL‖.[en línea]. Disponible en Internet: http://www.itil.org/en/index.php [Consulta: 25 de Febrero del 2008] 47

ITIL OFFICIAL SITE. [en línea]. Disponible en Internet: http://www.itil-officialsite.com/home/home.asp [Consulta: 25 de Febrero del 2008]

http://www.itil.org/en/index.php

http://www.itil-officialsite.com/home/home.asp



Gráfico 1.4.1-1 ITIL. Proceso de gerenciamiento de servicios

Publicado por Security Focus. ―How ITIL can improve Information Security‖48

A continuación se muestra gráficamente la interrelación entre las distintas disciplinas de ITIL V3 con la tecnología y los diferentes procesos del negocio.

Gráfico 1.4.1-2 Representación de la versión 3 de ITIL

Publicado por ITIL Org. ―The Core Framework‖49

48

SECURITY FOCUS. ―How ITIL can improve Information Security‖.[en línea]. Disponible en Internet: http://www.securityfocus.com/infocus/1815 [Consulta: 25 de Febrero del 2008] 49

ITIL GLENFIS PORTAL, op.cit.

http://www.securityfocus.com/infocus/1815



1.4.2. Soporte de servicios

El soporte de servicios (Service Support) es la parte de ITIL que se encarga de las operaciones dentro del framework de ITSM.

Este se subdivide en:

Incident Management o Gestión de incidentes.

Problem Management o Gestión de problemas.

Change Management o Gestión de cambios.

Configuration Management - CMDB o Gestión de configuraciones.

Release Management o Gestión de nuevas versiones de hardware y software.

Service Desk / Help Desk o Mesa de Ayuda. Con el gráfico 1.4.2-1 se tiene una rápida visión acerca de cómo funciona el servicio de soporte y sus componentes. Las diferentes herramientas que se usan en ellos, como así también sus respectivas interrelaciones.

Gráfico 1.4.2-1 Servicio de soporte de ITIL

Publicado por ITIL Org. ―ITIL V2 – ITSM Processes – Service Support‖

50

50

ITIL GLENFIS PORTAL. ―ITIL V2 – ITSM Processes‖. [en línea]. Disponible en Internet: http://www.itil.org/en/itilv2-itservmgmtprozesse/itilv2-itservicemanagementprozesse.php [Consulta: 25 de Febrero del 2008]

http://www.itil.org/en/itilv2-itservmgmtprozesse/itilv2-itservicemanagementprozesse.php



1.4.2.1. Gestión de incidentes

La gestión de incidentes (Incident Management) es un proceso para la restauración rápida del servicio normal de operaciones, interrumpido por algún evento que no es parte de los servicios estándares y que causa un impedimento o reduce la calidad del servicio.

Gráfico 1.4.2.1-1 Gestión de incidentes de ITIL

Publicado por ITIL Org. ―ITIL V2 – ITSM Processes – Service Support – Incident Management‖51

1.4.2.2. Gestión de problemas

Se define como gestión de problemas (Problem Management) al proceso donde se identifican y remueven los errores en la infraestructura de IT, y se previene proactivamente la recurrencia de incidentes. Los problemas son identificados por el análisis de incidentes con síntomas comunes o significativos.

Gráfico 1.4.2.2-1 Gestión de problemas de ITIL

Publicado por ITIL Org. ―ITIL V2 – ITSM Processes – Service Support – Problem Management‖

52

51




1.4.2.3. Gestión de cambios

En el caso de la gestión de cambios (Change Management), se manejan métodos estandarizados, procesos y procedimientos para la eficiencia y pronto manejo de los cambios de la IT. Una efectiva gestión del cambio minimiza el impacto de los cambios relacionados con los incidentes en los servicios.

Gráfico 1.4.2.3-1Gestión de cambios de ITIL

Publicado por ITIL Org. ―ITIL V2 – ITSM Processes – Service Support – Change Management‖53

1.4.2.4. Gestión de nuevas versiones de Hw y Sw

El manejo de todas las actividades asociadas con las nuevas y críticas versiones de software (Sw), hardware (Hw) y documentación asociada, entrenamiento y plan de comunicación, se conoce como gestión de nuevas versiones de Hw y Sw (Release Management).

52

ITIL GLENFIS PORTAL, op.cit. 53




Gráfico 1.4.2.4-1Gestión de nuevas versiones (Hw & Sw) de ITIL

Publicado por ITIL Org. ―ITIL V2 – ITSM Processes – Service Support – Release Management‖54

1.4.2.5. Gestión de configuraciones

Dentro del modelo lógico de la infraestructura de la IT, existe una base de datos de configuración (Configuration Management DataBase, CMDB), donde se registran todos los ítems correspondientes a ella (Configuration Items, CI). Gestiona tareas que incluyen identificación, control y verificación de todos los elementos de configuración y versiones (infraestructura, hardware, software, aplicaciones, redes, documentación relacionada con políticas, procedimientos, etc.) Gráfico 1.4.2.5-1 Gestión de configuraciones de ITIL (CMDB)

Publicado por ITIL Org. ―ITIL V2 – ITSM Processes – Service Support – Configuration Management‖55

54




1.4.3. Entrega de servicios

La parte de ITIL encargada de la logística o estrategia dentro del framework de ITSM, se denomina entrega de servicios (Service Delivery). Esta se subdivide en:

Service Level Management, gestión de nivel de servicios.

Availability Management, gestión de disponibilidad.

Capacity Management, gestión de la capacidad.

IT Service Continuity Management, gestión de la continuidad del negocio de la IT.

Financial Management for IT Services, gestión financiera de los servicios de la IT. En el gráfico que está a continuación, se expone el funcionamiento del servicio de entrega, sus componentes y las diferentes herramientas que se usan en ellos, además de sus interrelaciones.

Gráfico 1.4.3-1 Gestión de servicios de entrega o pedidos de ITIL

Publicado por ITIL Org. ―ITIL V2 – ITSM Processes – Service Delivery‖56

55

ITIL GLENFIS PORTAL, op.cit. 56




1.4.3.1. Gestión de nivel de servicios

La gestión de negociaciones de los servicios que se prestan, el monitoreo, reportes y revisión, como así también la implementación de acciones para mejorar el nivel de servicio es conocida como Service Level Management.

Gráfico 1.4.3.1-1Gestión de nivel de servicios de ITIL

Publicado por ITIL Org. ―ITIL V2 – ITSM Processes – Service Delivery- Level Management‖57

1.4.3.2. Gestión de disponibilidad

El Availability Management, o gestión de disponibilidad, es el procedimiento para mantener la capacidad de los servicios y dar soporte a la infraestructura de la IT. Una gestión efectiva asegura la disponibilidad de una manera sostenida, y a costos eficientes, de los niveles de servicios de IT para con los objetivos del negocio.

57




Gráfico 1.4.3.2-1 Gestión de disponibilidad de ITIL

Publicado por ITIL Org. ―ITIL V2 – ITSM Processes – Service Delivery- Availability Management‖58

1.4.3.3. Gestión financiera de los servicios de IT

La disciplina que asegura que la infraestructura de la IT es obtenida al precio más eficiente, es conocida como gestión financiera de los servicios de IT (Financial Management for IT Services), se encarga del cálculo de costos y su cobro a los clientes de los servicios, a través de las siguientes etapas:

Planeamiento del presupuesto

Definición de los costos y metas. Definición de costo estimado de los servicios. Definición de los planes de inversiones y financiero.

Contabilidad (créditos y débitos de cuentas)

Determinación de los costos actuales de los servicios ofrecidos. Determinación de los costos estándares. Monitoreo los gastos, comparación de los gastos presupuestados contra el

actual. Tipos y centros de costos, y costos unitarios contables.

58




Cargos (cálculo de costos, servicios de contabilidad)

Definición de los principios de facturación de cada servicio. Cálculo en forma transparente y comprensible de los costos de cada

servicio. Influencia sobre el comportamiento del cliente a través de los precios. Facturación de los costos en base a los servicios actualmente usados. Emisión de facturas a los clientes.

1.4.3.4. Gestión de la capacidad

La denominada Capacity Management es la gestión de procedimientos para determinar la actual y futura infraestructura de la IT de acuerdo a las necesidades del negocio. Una efectiva gestión de la capacidad asegura que tanto esta como su performance son adecuadas, y provistas consistentemente y de una manera efectiva en cuanto al costo.

Gráfico 1.4.3.4-1 Gestión de capacidad de ITIL

Publicado por ITIL Org. ―ITIL V2 – ITSM Processes – Service Delivery- Capacity Management‖59

59




1.4.3.5. Gestión de la continuidad del negocio de IT

La IT Service Continuity Management es la gestión de la estrategias y planes de acción para asegurar el recupero y continuidad de los servicios de la IT. También implementa medidas proactivas y preventivas de incidentes serios.

Gráfico 1.4.3.5-1 Gestión de la continuidad de servicios de ITIL

Publicado por ITIL Org. ―ITIL V2 – ITSM Processes – Service Delivery- IT Service Continuity Mgmt‖60

1.4.4. Gestión de la seguridad de IT

El nexo de unión entre el Service Support y Service Delivery, es la gestión de seguridad, o Security Management, dada la importancia de la seguridad en todos y cada uno de los estadios necesarios, debe ser independiente de ambos servicios para mayor eficacia.

60




Gráfico 1.4.4-1 Gestión de la seguridad de ITIL

Publicado por la Universidad New South Wales Australia ―Fundamentals of IT Security‖ 61

61

UNSW. ―Fundamentals of IT Security‖. [en línea]. Disponible en Internet: http://www.itee.adfa.edu.au/coursework/ZITE2302/pdfs/FundamentalsOfITSecurity.pdf [Consulta: 01 de Marzo del 2008]

http://www.itee.adfa.edu.au/coursework/ZITE2302/pdfs/FundamentalsOfITSecurity.pdf



1.5. Cómo implementar mejor CObIT, ITIL e ISO 17799

No existe ninguna duda de que las políticas y procedimientos de gestión ayudan a asegurar que la IT sea administrada como parte de la rutina diaria de actividades. La adopción de estándares y mejores prácticas ayudarán a habilitar una rápida implementación de los procedimientos correctos. Se ha producido una madurez creciente y la consecuente aceptación de marcos de trabajo respetados, tales como CObIT, ITIL, ISO 17799, ISO 9001, y CMM, entre otros. Sin embargo, las mejores prácticas adoptadas deben ser consistentes con la administración del riesgo y el marco de trabajo apropiado de para cada organización, y estar integradas con otros métodos y prácticas que están siendo usadas. Los estándares y las mejores prácticas no son la panacea, y su efectividad depende de cómo han sido implementadas y mantenidas al día. Estos son mucho más útiles cuando se aplican como parte de los principios y como punto de partida para adaptar procesos específicos. Para evitar que las practicas lleguen a ser solamente almacenadas en algún estante, la posibilidad de cambio es requerida, así la gerencia y su personal entienden qué hay que hacer, cómo hacerlo y la importancia del porque.

1.5.1. Alineación con las mejores prácticas

Las mejores prácticas de la IT necesitan estar alineadas a los requerimientos del negocio, e integradas unas a otras y con los procedimientos internos. El modelo CObIT puede ser usado al más alto nivel, proveyendo un marco de control envolvente, basado en los modelos de los procesos de IT que deberían genéricamente adecuarse a cada organización. Las prácticas específicas y estándares tales con ITIL e ISO 17799 cubren áreas discretas y pueden ser mapeadas o alineadas al framework de CObIT y así proveer una guía de materiales jerarquizados. Para entender mejor el alineamiento entre ITIL, ISO 17799 y CObIT, se hace mayor referencia a ellos en los apéndices respectivos, donde cada sección de los procesos de CObIT y los objetivos de control de alto nivel han sido mapeados a las secciones específicas de ITIL e ISO 17799. Esta alineación está basada en un punto de vista subjetivo y, por lo tanto, intentan ser solamente una guía. Existe, por parte de las organizaciones que administran ITIL y CObIT, un plan para la armonización entre la terminología y contenido de sus prácticas con otras deferentes, para permitir una fácil integración. La efectividad del uso de la IT es crítica para el éxito de la estrategia del negocio, como menciona el IT Governace Institute62 (ITGI): ―El uso de la IT tiene el potencial para ser el conductor principal de la riqueza económica en el siglo veintiuno. La IT es crítica para el éxito de empresa, proporciona oportunidades de obtener ventajas competitivas y ofrece un medio para aumentar la productividad; y será tanto más importante en el futuro".

62

ITGI. 2003. ―Board Briefing of IT Governance 2nd

Edition‖.[en línea]. Disponible en Internet: http://www.itgi.org [Consulta: 25 de Febrero del 2008]

http://www.itgi.org/



1.6. Introducción a CMMI

La integración del modelo de madurez de la capacidad (Capability Maturity Model Integration, CMMI)63 es un estándar utilizado por muchas organizaciones para identificar las mejores prácticas, las cuales son convenientes para ayudarles a evaluar y mejorar la madurez de su proceso de desarrollo de software. Este proceso de medición de mejoras proporciona a las organizaciones los elementos esenciales de procesos eficaces. Se puede utilizar para guiar la mejora del proceso a través de un proyecto, una división, o toda una organización. El CMMI ayuda a integrar las funciones de la organización, tradicionalmente separadas, mejorar el proceso estableciendo metas y prioridades, proporcionar orientación para los procesos de calidad, y sirve como punto de referencia para evaluar los procesos actuales. Además, mejora la capacidad de madurez modelo para el control de la elaboración, aplicación, adquisición y mantenimiento de sistemas y productos de software y servicios. Representa una integración de los órganos creados en virtud de los conocimientos que dirección de ingeniería de software, de sistemas, hardware y diseño de ingeniería, y su adquisición. El Software Engineering Institute (SEI), que definió el CMMI, ha tenido respuesta positiva de organizaciones de todo el mundo, para la suite de productos CMMI, que son adoptados por estas. Incluyendo América del Norte, Europa, Asia, Australia, América del Sur y África. Este tipo de respuesta ha fundamentado el compromiso de los modelos y estándares de CMMI, como método de evaluación de mejora de procesos. En paralelo con el desarrollo de CMMI, el SEI elaboró un método para la evaluación formal del modelo, denominado SCAMPI (Standard CMMI Appraisal Method for Process Improvement). Este método define una serie de reglas para la evaluación del modelo, las cuales deben utilizarse para valorar las distintas partes del mismo. Estas reglas hacen que sea necesario utilizar herramientas, ya que el método de evaluación deja de ser una simple encuesta para convertirse en una técnica de medición detallada y casi matemática.

1.6.1. Beneficios de la mejora del proceso con CMMI

Algunos de los beneficios y razones empresariales para la implementación de procesos de mejora como CMMI son:

La calidad de un sistema está altamente influenciada por la calidad del proceso utilizado para adquirirlo, desarrollarlo y mantenerlo.

El proceso de mejora aumenta la calidad del producto o servicio como así también el de las organizaciones que lo aplican para lograr sus objetivos de negocio.

63

SEI. ―What is CMMI?‖. [en línea]. Disponible en Internet: http://www.sei.cmu.edu/cmmi/general/index.html [Consulta: 24 de Junio del 2008]

http://www.sei.cmu.edu/cmmi/general/index.html



El proceso de mejora de objetivos permite que estos se alineen con los objetivos empresariales.

El CMMI está a la vanguardia del proceso de mejora, ya que proporciona las últimas mejores prácticas para productos y servicios de desarrollo y mantenimiento, incorporando continuamente los hallazgos importantes. Las mejores prácticas de CMMI facultan a las organizaciones para:

Tener una explícita vinculación de la gestión y las actividades de ingeniería con los objetivos de negocio.

Ampliar el alcance de la visibilidad y ciclo de vida del producto y las actividades de ingeniería, para garantizar que el producto o servicio cumple con las expectativas de los clientes.

Incorporar las lecciones aprendidas de otras áreas de las mejores prácticas (por ejemplo, la medición, gestión de riesgos y gestión de proveedores).

Aplicar de forma más robusta de alta madurez de las mejores prácticas.

Reforzar en la organización las funciones críticas para sus productos y servicios.

Estar alineado con las normas ISO. En el siguiente gráfico se muestra la evolución de CMM (Capability Maturity Model) de acuerdo al SEI, desde 1993 hasta la actualidad.

Gráfico 1.6.1-1 Evolución del modelo CMM

Publicado por ISACA



1.6.2. Representaciones de CMMI

Existen dos tipos de representaciones de CMMI, a saber: • Continua: una organización puede elegirla para mejorar el rendimiento de un único proceso de problemas, relacionados con el terreno, o que puede trabajar en varios ámbitos que están estrechamente alineados con los objetivos empresariales. Puede usarse dentro de un área de proceso que este organizado por capacidad. • Gradual: se trata de un método sistemático y estructurado, basado en la mejora del proceso de a una etapa a la vez. El orden de la aplicación de procedimientos se prescribe y organiza de acuerdo a los niveles de madurez. El logro de cada nivel de madurez sienta las bases para el siguiente, y permite la mejora incremental y duradera. El siguiente gráfico ilustra los objetivos genéricos, que son muestra de madurez, acrónimo, área y categoría del proceso (gestión del proceso, de proyectos, ingeniería o soporte).



Gráfico 1.6.2-1 Objetivos genéricos requeridos por CMMI

Publicado por ISACA



Las capacidades de las diferentes áreas de proceso se combinan para evaluar el nivel de madurez de la organización. En el gráfico 1.6.2-2 se puede observar la metodología; para evaluar por ejemplo el nivel de madurez 2 (Managed), todas las áreas de proceso son mostradas como el perfil buscado 2 (Target Profile 2), y deben ser evaluados los objetivos específicos de las áreas de procesos involucradas, indicando si cumplen con los objetivos genéricos y prácticas de capacidad del nivel correspondiente.

Gráfico 1.6.2-2 Prácticas requeridas por nivel de madurez de CMMI

Publicado por ISACA

1.6.3. Mapeo de CMMI y CObIT a alto nivel

Esta sección contiene el resultado del mapeo de las áreas de procesos de CMMI con el framework de alto nivel de objetivos de control y procesos, CObIT. El mapeo muestra en la primera columna la lista de objetivos de control CObIT, la segunda es la cobertura, indicada por las siglas. Los significados de las siglas del mapeo son los siguientes:



• E (Exceed): los requisitos establecidos en CMMI superan a los de CObIT. Por lo tanto, el CMMI debe considerarse como fuente primaria para más información y orientación para mejorar el proceso o control objetivo.

• C (Covered): los requisitos de control de los objetivos están cubiertos por el mapeo. • A (Addressed): algunos aspectos de los objetivos de control se tratan en CMMI,

pero las exigencias no están cubiertas completamente. • N/A (No Match): no existe correspondencia entre los requisitos de CObIT y CMMI.

Las áreas de procesos de CMMI se mapean con cada objetivo de control de CObIT de acuerdo al nivel de madurez. Las reseñas adicionales del CMMI hacen referencia a los objetivos y prácticas genéricas, las cuales se aplican a todas las áreas de procesos mapeadas. Por último, los productos integrados y los procesos de desarrollo (Integrated Product and Process Development, IPPD) son una cobertura adicional cuando se hace referencia a los mapas CObIT de requisitos. IPPD es un acercamiento sistemático que integra todas las actividades del concepto de producto usando un equipo multifuncional, para optimizar simultáneamente el producto y su fabricación, y encontrar objetivos de interpretación y costos.

Gráfico 1.6.3-1 Prácticas requeridas por nivel de madurez de CMMI

Publicado por ISACA

64

64

ISACA. ―COBIT MAPPING: MAPPING OF CMMI FOR DEVELOPMENT V1.2 WITH COBIT 4.0‖.[en línea]. Disponible en: http://www.isaca.org/ContentManagement/ContentDisplay.cfm?ContentID=31452 [Consulta: 24 de Junio del 2008]

http://www.isaca.org/ContentManagement/ContentDisplay.cfm?ContentID=31452



En el ejemplo de mapeo anterior están representados los objetivos de planeamiento y organización de CObIT con respecto a las prácticas de CMMI, por nivel de madurez. Los otros objetivos se detallan más extensamente en el apéndice 19.



1.7. Relevamiento de la situación actual

El soporte conceptual y fundamento de los análisis que se realizan a lo largo del trabajo, se basan en la recopilación de información y revisión de documentación pertenecientes a una compañía de jerarquía internacional, Motorola. La anterior, así como otras organizaciones mundiales, ha aplicado la metodología Six Sigma como base de gerenciamiento para la IT, y es por lo tanto, tomada como referencia para el presente estudio. Además de los mencionados anteriormente, otros reportes, como pedidos de solicitudes y resolución de problemas, se exponen en los apéndices, como información de respaldo.

1.7.1. Tareas realizadas durante el relevamiento

Se ha definido y revisado anualmente un “Acuerdo de provisión de servicio de IT” interno con la dirección de la empresa; donde se ponen en evidencia los

roles, responsabilidades, servicios brindados, tiempos de respuesta, disponibilidad, responsabilidades de las partes, entre otros. Se dispone de informes desde el año 2002 hasta el 2007. En los últimos dos años estos cambiaron su formato original, debido a una reorganización de la IT de la empresa, con el fin de lograr un marco unívoco a nivel mundial, para la totalidad de sus sucursales. Cabe señalar la falencia en cuanto a la definición de métricas, la forma de obtenerlas y la necesaria uniformidad en los reportes. Lo anterior hace dificultosa la comparación entre distintas unidades, dado que, la falta de unicidad conduce a errores en la interpretación de los indicadores por parte de aquellas personas que comparan o evalúan los mismos. Esto puede llevar a cotejar elementos desiguales o bien, disgregar aquellos análogos.

Se realizó la colección detallada, durante los años mencionados, de un sistema de soporte de a usuarios de la IT, donde se registran los pedidos, reclamos de incidentes, problemas y otros relacionados con el área de la IT por parte de los usuarios finales. Se cuenta con más de 16.908 registros de los mismos, donde ciertos campos se han mantenido ocultos, por una cuestión de confidencialidad de la información de la empresa analizada. De allí se obtuvo un muestreo para el establecimiento y cálculo de las métricas comunes, y su representación a través de un TC para la gerencia.

Se concretaron, en los últimos dos años, reuniones de análisis de causas de resultados de las encuestas, para detectar e introducir mejoras posibles a los servicios brindados por la IT.



Se verificó la existencia de políticas, procedimientos y órdenes de trabajo, como así también de listas de chequeo o verificación de rutina, planes y testeo de planes de contingencia, recuperación del negocio y continuidad.

Aunque estas no fueron adjuntadas al trabajo, se quiere destacar su necesidad e importancia en el ámbito de la industria donde se desempeña la empresa.

Se elaboró un relevamiento de los TC de diez países, entre los que se

encuentran Argentina, Australia, Canadá, China, India, Italia, Malasia, Polonia, Rusia y Singapur. Respecto de estos TC, implementados a partir del año 2006, se advierten resultados dispares en cuanto a la definición de métricas y su base de cálculo. La gerencia suele desconocer esta característica, y consideran que las mismas están estandarizadas, lo que conlleva inexactitudes en los análisis de las métricas reflejadas en los TC (falta de definiciones de métricas o forma de cálculo diferentes, métodos de recolección de datos y selección).

Se consultaron gerentes regionales de la IT de América, Europa y Asia, como así también a los de cada sucursal, para comprobar la existencia de definiciones estándares de métricas y verificar si las demás sucursales usaban las mismas. El resultado fue que ninguna tenía definida correctamente métricas estándares, por lo que se puso en marcha un proceso de unificación y estandarización.

A partir de los datos relevados, en base a la documentación, marco de trabajo seleccionado y fuentes bibliográficas consultadas, fue posible situar el escenario actual del área de IT. En tal contexto, y teniendo en cuenta los objetivos generales y específicos de la organización, se despliegan los conceptos examinados y sus correspondientes conclusiones.

1.7.2. Escenario actual

El entorno comprende a las empresas de sector tecnológico, en las que recientemente ha habido un auge en cuanto a la cantidad de mano de obra que incorporan. En lo que respecta al mercado de Córdoba (Argentina), estas empezaron a formar parte estratégica del plan de gobierno para el nuevo periodo que se inicia, estableciendo incentivos para la generación de nuevas fuentes de trabajo, como así también para la transferencia de tecnología. Tales empresas de servicios de por sí generan un valor agregado muy alto al producto, y esta es la base de la economía en los países del primer mundo, donde las materias primas sin procesar ocupan un papel secundario respecto a las exportaciones. Sin embargo, en nuestro país, Argentina, normalmente se exportan materias primas y se importan productos terminados; cuando el proceso de elaboración es el factor principal de generación de ganancias, como así también generador de nuevas tecnologías y pequeñas y medianas empresas que proveen a las manufactureras.



En el caso de las empresas de servicios la materia prima de los negocios son las personas -con el aporte de conocimiento-. En las pertenecientes al sector electrónico, el área de IT juega un factor fundamental ya que provee la infraestructura necesaria, como así también los servicios, para que las personas proporcionen su capital intelectual como materia prima, análogamente a aquellos sistemas que consisten en líneas de producción de las manufactureras. Poder conocer y gestionar los recursos e inversiones, a la vez de facilitar la toma de decisiones en base a información actualizada y alineada a la estrategia de la empresa, es fundamental en este rubro, ya que la mayoría de los productos tienen ciclos de vida muy cortos en relación con otros sectores. Esto hace indispensable la disponibilidad de resultados y tendencias de procesos, para supervivencia y mejor control. En sus principios el área de IT dependía organizacionalmente de Finanzas, pero a partir de que fue tomando más importancia el valor de la información, y el conservar la integridad, disponibilidad y seguridad de la misma, se sugirió un área propia con reportes directos para el directorio o gerencia general. Los modos de operación varían de acuerdo a las necesidades de cada negocio en particular. Normalmente en empresas de cierta envergadura tienen definidos acuerdos de servicios, ya sean internos o externos. En estos últimos, la IT está en manos de terceros, con los que se pactan convenios de confidencialidad a la empresa y personal que presta el mismo, de no exposición de la información que manejan. En general, estos acuerdos contienen detallados todos los servicios, tipos de prestaciones, tiempos de respuestas, penalidades y métricas a ser reportadas, para el seguimiento de la prestación, y personas responsables del gobierno o gerenciamiento del servicio para con la dirección.

1.7.3. Beneficios de operar sobre un marco de trabajo

Como se ha mencionado antes, la aplicación de CObIT como marco de gestión, permite la alineación de estrategias, metas y objetivos de la empresa con cada una de las áreas, no solamente con la de IT. Además brinda a la empresa la posibilidad de un uso más eficiente y eficaz de los recursos, que se traduce en dinero, o dividendos de los accionistas, donde se ven reflejadas las ganancias de la misma. Este marco de trabajo provee:

• Mejor alineación, con base en su enfoque de negocios. • Una visión, entendible para la gerencia, de lo que hace IT. • Propiedad y responsabilidades claras, con base en su orientación a procesos. • Aceptación general de terceros y reguladores. • Entendimiento compartido entre todos los participantes, con base en un lenguaje común. • Cumplimiento de los requerimientos COSO para el ambiente de control de la IT.



Todo esto en combinación con el modelo de madurez, da una idea del avance de los procesos de la IT dentro de la empresa, que consta de los seis estados expuestos anteriormente:

0 - No se aplican procesos administrativos en lo absoluto. 1 - Los procesos son ad hoc y desorganizados. 2 - Los procesos siguen un patrón regular. 3 - Los procesos se documentan y se comunican. 4 - Los procesos se monitorean y se miden. 5 - Las buenas prácticas se siguen y se automatizan a partir del análisis de los

resultados del estado de madurez anteriores y del benchmarking con otras empresas.

Como complemento Norton y Kaplan mencionan en su modelo de BSC que se debe ver a la organización a partir de cuatro perspectivas (del aprendizaje y crecimiento, del proceso de negocio, de clientes, y financiera) y desarrollar las métricas, recoger datos y analizar lo concerniente a cada una de ellas. Estas perspectivas serán consideradas y representadas a través de indicadores que reflejen una imagen representativa de la IT a los directores y accionistas, como así también permitirán la comparación para el benchmarking y la mejora continua, alineándose al mercado. Los factores críticos para el éxito surgen de observar algunas preguntas tradicionales, y las herramientas que la gerencia usa examinar las respuestas, como los tableros de control, dashboards o scorecards, necesitan indicadores. Los cuadros de resultados, de mediciones y las mejores prácticas o benchmarking de otras empresas líderes o áreas de negocio, necesitan una escala común para la apropiada comparación entre ellos. Dada la importancia de estos parámetros, se definirán cuales serían los indicadores críticos para el éxito, las métricas que los representan y su integración en un BSC, para proveer de ellos a las personas que necesitan tomar decisiones de valor o alto impacto en la empresa.

1.7.4. Importancia de las métricas

La gerencia tiene conocimiento acerca del significado de las métricas, pero suele haber falencias en cuanto a la base del cálculo para las mismas. Su frecuencia o ciclo de actualización es mensual y en la mayoría de los indicadores no están fijados los límites de control, y solamente en caso de no conformidad de una encuesta individual se investiga la causa de la no satisfacción por parte de usuario final. Esto ocurre en la totalidad de las sucursales a lo largo del mundo. La falta de generación y establecimiento de métricas organizacionales deberían ser contempladas con mayor atención. Cada indicador debe contar con:

su denominación o nombre,

el propósito u objetivo de su adopción,

la fuente de datos,



la metodología de cálculo,

la responsabilidad sobre la colección de datos,

las herramientas a utilizar,

el lugar de reposición de los datos,

el período del reporte,

criterios de colección de datos y análisis de los mismos.

Se recuerda que, es conveniente un catalogo de indicadores, donde cada métrica

cuente con información sobre las siguientes características:

1) Su denominación o nombre. 2) El propósito u objetivo de su adopción. 3) La fuente de datos. 4) La metodología de cálculo. 5) La responsabilidad sobre la colección de datos. 6) Las herramientas a utilizar. 7) El lugar de reposición de los datos. 8) El período del reporte. 9) Criterios de colección de datos y análisis de los mismos.

Además, es indispensable que las métricas seleccionadas utilicen datos tanto obtenidos del proceso como del repositorios de datos, asociados a mediciones de procesos anteriores y que son relativamente estables o están bajo control. Adoptando las pautas y consideraciones hasta aquí explicitadas, se tendrá un ámbito adecuado donde será posible implantar determinados modelos de gerenciamiento de la IT. Se prosigue entonces con el despliegue de las herramientas de la metodología elegida como marco de este trabajo, Six Sigma. En cada uno de los capítulos siguientes se exploran y ahondan las etapas correspondientes al proyecto DMAIC, uno de los tres posibles dentro del modelo anterior.



PARTE II.

PROYECTO DMAIC. FASES Como se ha mencionado anteriormente, la metodología Six Sigma integra una filosofía de trabajo con las estrategias de negocios. Basada en el enfoque hacia el cliente, el diseño robusto y un manejo eficiente de los datos, que permiten disminuir la variabilidad en los procesos y alcanzar un nivel de defectos mínimo (menor o igual a 3,4 defectos por millón), además de conducir un proceso de mejora continua. El proyecto DMAIC es aplicado cuando el objetivo a alcanzar es la mejora de un producto, proceso o servicio existente; frecuentemente aplicado en la mejora de la performance o actuación.

2. DEFINICIÓN DE OPORTUNIDADES

La primera etapa de un proyecto DMAIC consiste en definir los logros y oportunidades de la actividad de mejora. Los objetivos más importantes son obtenidos de los clientes o usuarios finales. En los niveles superiores, los objetivos serán estratégicos para la organización, tales como mejorar la lealtad de los clientes, lograr un alto retorno sobre la inversión (Return Over Investment, ROI), incrementar la porción de mercado, generar mayor satisfacción del empleado, entre otros. A nivel operativo, se podría, además, incrementar la efectividad y la eficiencia, y reducir el tiempo de resolución de problemas del departamento; mientras que, a nivel del proceso, se busca reducir los costos de calidad y de no calidad (Cost Of Quality, COQ y Cost Of Poor Quality, COPQ), reducir el nivel de defectos e incrementar la salida de un determinado proceso. Se pueden plantear objetivos a partir de la comunicación directa con clientes, accionistas y empleados.

Se establecen claramente los objetivos y métricas –indicadores- relevantes. Con los cuales, se podrá apreciar la línea base, brechas, impedimentos y barreras estructurales para el proceso de cambio, y finalmente, la evolución hacia las metas

En el siguiente gráfico se muestran los objetivos, actividades principales, herramientas y técnicas potenciales, y salidas -resultados- (key deliverables) de esta fase o subproceso.



Gráfico 2-1 Definir oportunidades

En conclusión esta etapa le permite a las empresas reconocer como sus procesos afectan la rentabilidad y la satisfacción del cliente desarrollando un proyecto de mejora. Durante esta etapa de implementación del Six Sigma:

- Se documenta la voz del cliente. - Se crean mapas de proceso de alto nivel. - Se forma un equipo de proyecto. - Se crean los estatutos del proyecto.

2.1. Voz del cliente

Una herramienta comúnmente utilizada para recolectar datos del cliente es conocida como Voice Of Customer (VOC). Se obtiene la información a través de encuestas o entrevistas, lo que permite desarrollar específicamente los requerimientos críticos del cliente (Customer Critical Requirements, CCR) y las prioridades asociadas. Frecuentemente es empleada para generar entradas adicionales, desde el punto de vista del cliente, tales como ideas y sugerencias, para la mejora o retroalimentación. No se usan herramientas estructuradas, ya que la información puede estar incompleta y desviada o no ser imparcial, debido a subjetividades en el punto de vista del cliente. Para una visión más certera de las condiciones en las cuales estas métricas son obtenidas y analizadas, se realizaron entrevistas a los responsables administrativos. Por un lado, el Gerente Regional de IT (responsable para toda América, Europa y Asia) planteó la necesidad de implementar este tipo de proyectos, las diferencias en cuanto a formar, definir y calcular métricas, las formas de reportarlas, y las particularidades de



cada lugar. También enfatizó la relevancia de unificar criterios para lograr, con indicadores inequívocos, tomar decisiones rápidas y acertadas al respecto. Por otro lado, dos Directores de Negocios manifestaron lo significativo de contar con gráficos de métricas que representen el estado del acuerdo de servicio firmado o convenido. Con estos se examinan los valores y tendencias de los indicadores, para realizar análisis adecuados del servicio recibido. Por último, se mantuvieron entrevistas telefónicas con los Gerentes de IT de lugares específicos (Canadá, Italia, Australia, India, China, Malasia, entre otros), y se los indagó acerca de las definiciones de métricas y su implementación. Entre otros, los cuestionamientos fueron:

1) Si disponían de un conjunto de métricas estándares en sus oficinas relacionadas con la IT.

2) Si podían suministrar un listado de ellas. 3) Con qué frecuencia se debían reportar esas métricas 4) Si eran capaces de explicar las definiciones, objetivos y forma de cálculo de

cada una de ellas. 5) Qué método utilizaban y desde dónde eran recolectados los datos para la

generación de las métricas. La consolidación de las respuestas y conclusiones se detallan a continuación:

1) Todos contaban con métricas relacionadas con la IT, que fueron surgiendo por la necesidad de monitorear procesos, por reportes a clientes internos, o debido a acuerdos de servicios brindados por ellos, que no eran estándares, sino particulares definidos o indefinidos.

2) El listado fue variado, no existía en ese entonces un repositorio donde se las pudiera encontrar fijadas por lugar. Cabe señalar que en el 2006 se comenzó a trabajar en un tablero de control donde fuera más fácil acceder a las mismas por sitios (ejemplos de estos se pueden encontrar en los apéndices respectivos), con ello se logro el establecimiento de ciertas métricas –repositorio- pero no la estandarización, ya que en cada lugar las fuentes y fórmulas de cálculo son distintas aunque tengan el mismo nombre.

3) La frecuencia de reporte coincidió ser mensual, aunque en ciertos casos se hacían semanales (si se encontraban en una situación crítica por requerimientos externos o internos).

4) Respecto a las definiciones, objetivos y formas de cálculo se produce un vacío, ya que en la mayoría de los lugares, incluido Argentina, no se cuenta con algún marco de referencia sentado con toda esta información.

5) Los métodos de obtención de datos y las fuentes fueron diversos. Solo existe en algunos sitios la herramienta de soporte de mesa de ayuda (Remedy - Help Desk System), que provee datos de manera consistente, relacionados con soporte de pedidos y solución de problemas referidos a la IT. Muchas oficinas usaban herramientas propias, en vez de estándares de la empresa global.

A partir del VOC, trasladado a los requerimientos críticos del cliente (CCR), es posible vislumbrar la necesidad, planteada como objetivo de la tesis, de definir y desarrollar



instrumentos de control para la gestión integrada de la tecnología de la información como área de servicio interno en empresas del sector electrónico.

Partiendo de la determinación de factores claves e indicadores críticos del área de la IT, se continúa con la definición de métricas organizacionales para poder realizar comparaciones adecuadas, con otras empresas o dentro de la misma compañía en diferentes unidades de negocios. Se exhiben elementos para el monitoreo de métricas, para concluir en el establecimiento de un tablero de control de gestión integrada para el área de la tecnología de la información, con las métricas seleccionadas.

2.2. Definiciones útiles de la terminología usada

En este apartado se recordarán específicamente algunos conceptos relevantes, que se manejan frecuentemente en este terreno:

Métrica

La norma ISO 14598-1:1999 la define como: ―El método de medición definido y la escala de medición‖. En otras literaturas específicas se la conceptualiza como: una función matemática que asocia valores a una serie de elementos, con el objeto de cuantificarlos y/o cualificarlos. Como sinónimo de métrica habitualmente se habla de indicador.

Citando a McCarty et. al.65, en su libro The Six Sigma Black Belt Handbook sugieren que las métricas debe ser:

Válida: Típicamente, múltiples métricas deben ser seleccionadas para hacer un seguimiento de los logros de los objetivos estratégicos. El liderazgo asevera eso, sumado el conjunto, cada grupo de las métricas soportadas muestran una razonable figura del estado de las metas estratégicas y sus objetivos relacionados. A esto le llaman validez de la métrica. Confiable: Las métricas no se puedan medir directamente sin tener en cuenta que el sistema de medición de métricas; debe ser algo concreto para que cada uno pueda convenir en el mismo valor medido de cada métrica. Esto es llamado confiabilidad de la métrica. Estas deben ser confiables o de lo contrario son inútiles. Son sinónimos de confiabilidad: seguridad, consistencia, repetibilidad, confianza. La confiabilidad la podemos plantear como la proporción entre la varianza verdadera y la varianza total. Calculadas con precisión: Diferenciando escalas, las métricas deben proveer datos precisos que muestren cambios significativos en los objetos que se están midiendo. Precisión indica bajo error en la medición. Efectivas en costos: Técnicamente y prácticamente realizables, que se permitan coleccionar o recolectar en el tiempo apropiado para dar soporte a la toma de decisiones. El costo, los desafíos técnicos y la dificultad práctica en la recolección de datos para una métrica deben ser siempre considerados.

65

MCCARTY, THOMAS; DANIELS, LORRAINE; BREMER MICHAEL; AND GUPTA, PRAVEEN. The Six Sigma Black Belt Handbook. New York: McGraw-Hill Publishers, 2004.



Scorecard

Es una herramienta de evaluación, generalmente en forma de cuestionario, que especifica el criterio que nuestros clientes usarán para evaluar la actuación del negocio en la satisfacción de sus requerimientos.

Dashboard

Similar al scorecard, se utiliza para colectar y reportar información vital acerca de los requerimientos del cliente y de la actuación del negocio con los clientes claves, proveyendo de un rápido resumen de la performance de los procesos.

Benchmarking

Es un mecanismo de mejora, donde cada compañía mide su performance o proceso en comparación con otras (mejores prácticas). Determina como aquellas lograron ese nivel de actuación y usa la información para mejorar la propia performance. En el marco CObIT fueron definidas las relaciones entre estas herramientas y sus entradas o inputs en el gráfico 1.3.3 - 1 (bajo el nombre de ―Información gerencial‖)

2.3. SIPOC

Un diagrama SIPOC es una herramienta utilizada para identificar los elementos para la mejora de los procesos en la empresa. Sus siglas corresponden a los siguientes elementos: proveedores, entradas, proceso, salidas y clientes (Suppliers, Inputs, Process, Outputs, Customers – SIPOC). Facilita la identificación de todos los elementos relevantes, refinando el alcance y complejidad de los proyectos. Permite crear un mapa de proceso de alto nivel que defina el alcance del mismo y sus principales ingresos, salidas, proveedores y clientes. La herramienta SIPOC puede ser entonces utilizada para identificar proyectos potenciales al separar las áreas de proceso que necesitan ser mejoradas. A continuación se presenta un diagrama SIPOC, con la correspondiente descripción de cada una de las cinco etapas o subprocesos relacionados.



Gráfico 2.3-1 Diagrama de SIPOC

SIPOC Diagram Suppliers

Inputs

Process

Outputs

Customers

Servicios Regionales de TI de la compañía. Servicios contratados a terceros.

Metas y Objetivos de Negocios. Scorecards. Acuerdo de niveles de servicios de TI. Sistema de Help Desk. Herramientas de Monitoreo de TI. Sistemas ERP.

Reducir el cicle time de los procesos relacionados con las métricas respectivas Mejorar la Satisfacción del cliente.

Cicle Time Satisfacción del cliente Cost Reduction

Áreas Internas del Negocio. Gerencia Local Gerencia Regional Directorio Accionistas

Otra herramienta utilizada son los factores rápidos de éxito (Quick Wins) son aquellos con los que se consigue un rápido impacto, con poco esfuerzo; se los conoce también como ―las frutas más bajas del árbol‖ (low hanging fruits), que incluyen: la definición de métricas estándares y la construcción de un BSC de IT, que permiten la

representación e interpretación ágil de las mismas, para la toma de decisiones basadas en valores reales y actualizados.



2.4. Estatutos del grupo

Por último, en esta fase de definición, se presenta el Team Charter o listado de los estatutos o compromisos del grupo y del proyecto en sí. Allí podemos identificar el caso del negocio, los objetivos, el plan del proyecto, las oportunidades y alcance del mismo, como así también las personas que participan.

Tabla 2.4-1 Estatuto del grupo



3. MEDICIÓN DE LA PERFORMANCE O ACTUACIÓN

En la segunda fase del proyecto DMAIC se mide el sistema existente. A partir de este, se establecen métricas válidas y confiables para ayudar a monitorear el progreso hacia los objetivos definidos en el paso anterior. Es decir, la situación actual determina la línea base del proyecto, en primera instancia se usan métodos de análisis de datos exploratorios por ejemplo para detectar errores en la digitación, códigos no validos, valores atípicos, valores extremos, supuestos de normalidad y luego análisis de datos estadísticos descriptivos que ayuden a entender la información más en detalle. Se analiza en detalle el desempeño, a lo largo del proceso, y se obtienen las relaciones causa-efecto entre todas las variables claves involucradas En el siguiente gráfico se muestran los 4 pasos correspondientes a esta etapa.

Gráfico 3-1 Medición de la performance

Resumiendo, esta etapa permite a las empresas evaluar donde se encuentra un proceso y determinar las metas apropiadas. En ella:

- Se define las variables de salida críticas. - Se confirma la integridad de medición. - Se desarrolla un plan de medición. - Se establece el desempeño de referencia.



3.1. Indicadores principales

El camino determinado a partir de la primera etapa, de definición, es identificar la voz del cliente (Voice Of Customer, VOC) y la voz del negocio (Voice Of the Business, VOB), entre las cuales a veces puede haber o no coincidencias en algunos puntos. La información que estos proveen se transforma o traslada a indicadores. Así, a partir de VOC se obtienen los requerimientos críticos del cliente (Customer Critical Requirements, CCR), con los cuales se identifican los indicadores críticos para la calidad (Critical To Quality, CTQ). Lo mismo ocurre con VOB, que deriva en los requerimientos críticos del negocio (Critical Business Requirements, CBR), los que finalmente darán los críticos para el proceso (Critical To Process, CTP).

VOC CCR CTQ

VOB CBR CTP

Los indicadores de salida de los procesos (outputs) relacionados con CTQ, también son comunes para CTP, y tienen por objeto:

Reducir el ciclo del proceso (cicle time), es decir tiempo que conlleva realizar el mismo, mejorando la productividad y eficiencia (CTQ & CTP).

Mejorar la satisfacción del cliente (CTQ & CTP).

Reducir costos, o bien no incrementarlos, agregándoles tareas que no tengan valor (CTP).

Es importante también analizar los factores de éxito rápido (Quick Wins), respecto a lo planteado para el negocio, a la confiabilidad de datos, a la fuente de información, unificación y representación a través de métricas comunes estándares. De acuerdo a lo determinado en los pasos anteriores, se requiere un cálculo estadístico de las métricas de procesos que reportan otras sucursales, para revelar la existencia de diferencias significativas entre ellas. Al no tener un sistema único de recolección de datos, es muy difícil aplicar estadísticas sobre los mismos en otras delegaciones. Se adjuntan en los apéndices los dashboards de la IT de diferentes lugares; a simple vista se perciben diferencias en las métricas definidas en ellos, que pone en evidencia la falta de estandarización de las métricas en sí mismas. Extrayendo diversos datos de Argentina, Australia, Canadá, China, Malasia e India es posible extrapolar algunas deducciones:

No existen valores definidos o calculados de procesos.

En algunos lugares hay métricas no definidas o establecidas.

En otros, se fijaron los valores pero los resultados son diferentes en que refiere a: La fuente de datos dónde se obtienen. La forma de calcularlos. El significado de las métricas en sí mismas. La base o método de cálculo y formulaciones matemáticas.



Estas desigualdades deben evitarse. El mejor criterio de gerenciamiento contempla a la vez que en el proceso esté controlada la variabilidad, estabilidad y capacidad del mismo. Más adelante se pondrá en práctica mediante un análisis estadístico. El siguiente es un ejemplo de análisis de ciertas métricas:

1. Efectividad del servicio de mesa de ayuda – Antigüedad de pedidos sin asignación.

Service Desk Effectiveness - Service Backlog (days) ≤ 30 ≤ 14 ≤ 7

2. Efectividad del servicio de mesa de ayuda – Antigüedad de los tickets relacionados con problemas sin asignación. Service Desk Effectiveness - Problem Backlog (days) ≤ 30 ≤14 ≤7

3. Eficiencia del servicio de mesa de ayuda – Tiempo de resolución de problemas.

Service Desk Efficiency - Problem Resolution Age (days) ≤ 14 ≤ 7 ≤ 1

4. Eficiencia del servicio de mesa de ayuda – Tiempo de resolución de pedidos.

Service Desk Efficiency - Service Resolution Age (days) ≤ 30 ≤ 14 ≤ 14

En los puntos 1, 2, 3 y 4 se muestran, a modo de ejemplo, los valores límites impuestos por el cliente; los máximos, esperados y valor actual del mismo en el corriente mes. En las sedes de Argentina se trabaja con límites de control predeterminados, que indican las estimaciones mínimas y esperadas, como así también sus valores actuales. Es primordial trabajar sobre los pedidos que más tiempo han estado sin asignar y reducir la cola de espera de los mismos, es decir, se procura para ellos la designación rápida de agentes de mesa de ayuda. Para esto, no sólo es preciso analizar la desviación estándar y ver si pertenecen al rango de los 3 σ ó 6 σ respecto de los límites de control definidos, sino también analizar los outliers (puntos fuera de los límites o valores extremos) que implican los pedidos o tickets aún no asignados, y reflejan si alguno de ellos tiene una antigüedad mayor a la tolerada.

5. Performance del servicio de mesa de ayuda - % de Llamadas o tickets

resueltos satisfactoriamente (Service Desk Performance - % Calls resolved satisfactorily).

Para esta métrica se toman las respuestas de encuestas pertinentes a tickets de clientes, evaluando su porcentaje del total que fueron contestadas. Aquí es vital considerar aquellas encuestas no satisfactorias y buscar la causa raíz de la disconformidad, dado que podría dar respuestas o entradas de ciertas posibilidades de mejora del proceso.

6. Satisfacción del cliente – Satisfacción total del cliente con los servicios de la IT (Customer Satisfaction – Overall Satisfaction with IT Services).

Para la determinación de esta métrica también existen valores mínimos y esperados previamente definidos. Lo importante aquí, además de la escala y objetivos uniformes en cada dependencia, es la confección de encuestas



comunes en todos los lugares. Estas deberían ser realizadas por terceros, tal que asegure el anonimato, independencia y no desviación o tendencia de datos, generadas por subjetividades entre las partes. Esto último es conducido y analizado por el área de Procesos y Calidad, para asegurar que las encuestas sean anónimas e independientes. Entre los apéndices 11 y 15 se pueden observar los análisis realizados por este área.

3.2. Entradas y salidas del proceso

Es importante entender las relaciones entre los indicadores de entrada, de procesos o inputs (Xs) –variables de control- y los de salida u outputs (Ys) –variables de respuesta-; que reflejarán los puntos significativos y sus efectos en la determinación de los Ys. Los Xs en este caso se dirigirán a la mejora de la satisfacción del cliente y la reducción del tiempo de resolución o cycle time.

3.3. Matriz de causa-efecto

Una correcta selección de los inputs asegura que las mejoras a introducir serán superiores, y se denotan en los outputs. Para ello se emplea una matriz de causa- efecto, en la cual se asignan prioridades a los inputs.

Gráfico 3.3-1 Matriz causa-efecto de entradas - salidas



3.4. Plan de medición

La recolección de información es un activo trascendental para cualquier grupo de mejora de procesos. Para esta fase del proyecto se deben considerar los diez elementos claves para el plan de medición:

1. La performance de la medida. 2. La definición de operadores. 3. Fuente y ubicación de los datos. 4. Tamaño de la muestra. 5. Quién recolectará los datos. 6. Cuándo se recolectarán. 7. Cómo se recolectarán. . 8. Otros datos que deberían ser recolectados al mismo tiempo. 9. Para qué van a ser usados. 10. Cómo van a ser mostrados.

En el presente, se focaliza al plan de medición en una sede argentina, de acuerdo a una investigación de tres años de duración, durante los cuales se acopió información. Para la generación de las métricas seleccionadas para el proyecto, se realizaron cálculos estadísticos de los datos y definiciones de estándares, en los cuales se podrían basar futuras métricas. Todos los inputs o indicadores de procesos descriptos en la matriz causa-efecto y otros adicionales se encuentran en el sistema de soporte de mesa de ayuda, del cual se extrajo la información pertinente. Muchos de estos indicadores ya existen, especialmente en verdaderos sistemas de producción, otros se deben generar a partir de los datos obtenidos con operadores matemáticos o transformaciones.



Gráfico 3.4-1 Plan de medición

3.5. Análisis del sistema de medición

El análisis del sistema de medición o Measurement System Analysis (MSA), es un procedimiento de recolección de datos, automatizado y sistematizado. Los valores no son influidos por errores inherentes a los instrumentos de medición, o a la apreciación de los inspectores que toman tales mediciones, ni tampoco por la variación del medio ambiente. Cabe aclarar que, independientemente de que los atributos de los datos sean continuos o discretos, el error introducido es muy difícil de calcular, pero se considera mucho menor al 10%, valor más que aceptable para procesos críticos. Es decir, el análisis del porcentaje de repetitividad y reproducibilidad (%R&R) y el de precisión con respecto a la tolerancia (%P/T) son admisibles en esos rangos.



Con el fin de graficar y mostrar los datos recolectados se utilizará el programa estadístico MINITAB66, el cual se encuentra en idioma inglés por eso los resultados o salidas se muestran en ese idioma. Para el análisis de performance se fija como marco que:

Los datos registrados entre enero del 2005 y octubre del 2007 serán incluidos en el análisis, pero aquellos con causa asignable y los excepcionales o especiales serán excluidos y analizados individualmente.

Aquellos outliers que correspondan al 5% o menos del tamaño de la muestra, que son mayores al percentil 97.5; también serán excluidos del estudio, siempre y cuando la exclusión provoque mejoras significantes en algunos de los análisis realizados. Los outliers con análisis de causa ya realizada e identificada y planes de acción definidos no serán contados tampoco.

3.6. Servicios, tiempo de resolución (horas) y variables

Como se mencionó antes, se cuenta con datos correspondientes a tres años consecutivos, entre el 2005 y 2007. Representando los gráficos y tablas estadísticas más comunes, se logró valuar el comportamiento de los mismos. En una primera instancia, se elaboraron gráficos por tipo de tickets, ya sea de servicios o problemas, por año. Pero luego de ciertas comparaciones se evidenció que era de mayor utilidad agruparlos en distintos tipos de gráficos, y observar las variaciones entre cada año, pero manteniendo la separación por tipo de tickets. De allí surge la categorización que se expone a continuación.

3.6.1. Gráficos de valores individuales – Estadísticas

En estos gráficos, también conocidos como Individual Value Plot, se plasma la distribución de los tickets de servicios mensuales. Allí se identifica que los valores máximos entre las 200 y 250 horas (equivalente a 10 días), considerando el tiempo fuera del horario de soporte, como así también feriados y fines de semana. Cabe destacar que el tiempo de resolución (Resolution Time, RT) es calculado como el tiempo total desde que se abrió el ticket, menos el tiempo que está en espera de una respuesta del usuario sobre más información o disponibilidad; en caso de requerir soporte solicitado a terceras empresas, como contratación de equipos, este también es restado del total. En las gráficas se visualizan también las variaciones en las cantidades por mes, que generalmente suelen ocurrir cuando comienzan nuevos proyectos y la cantidad de pedidos aumenta considerablemente.

66

MINITAB® 15.1.1.0. [en línea]. Disponible en Internet: http://www.minitab.com/products/ [Consulta: 25 de Febrero del 2008]

http://www.minitab.com/products/



Gráfico 3.6.1-1 Valores individuales (RT) por mes – Servicios 2007

10090807060504030201

250

200

150

100

50

0

Month

Re

so

luti

on

Tim

e (

hs)

Individual Value Plot of Resolution Time (hs) vs Month - Services 2007


121110090807060504030201

200

150

100

50

0

Month

Re

so

luti

on

Tim

e (

hs)

Individual Value Plot of Resolution Time (hs) Services 2006




121110090807060504030201

250

200

150

100

50

0

Month

Re

so

luti

on

Tim

e (

hs)

Individual Value Plot of Resolution Time (hs) - Services 2005



3.6.2. Gráficos de cajas y bigotes – Estadísticas

En los gráficos de cajas y bigotes (BoxPlot) se observan: la media, los cuartiles Q1 y Q3, el valor total, valores extremos y outliers, junto con cantidad mensual de los mismos. Examinando la gráfica se aprecia que la mayoría de los pedidos son resueltos en menos de 50 horas, y los pedidos de mayor complejidad son principalmente los outliers observados. A medida que se van analizando los gráficos ulteriores, la información obtenida de su análisis, permitirá formar una idea más global de los datos y su significado. BoxPlot es una representación gráfica de las dispersiones y las puntuaciones extremas. Representados en este gráfico son mínimo, máximo, y el cuartil resultados en forma de una caja con "bigotes". La caja incluye el rango de puntuaciones de caer en la media del 50% de la distribución (entre cuartil rango = percentil 75 - percentil 25) y los bigotes son líneas de extenderse a los mínimos y máximos resultados en la distribución o al definido matemáticamente (+ / - 1,5 * IQ) superior e inferior de las vallas. Outliers o valores atípicos son usualmente observaciones mayores o menores, estos pueden tener una influencia desproporcional en los resultados estadísticos los cuales pueden resultar en interpretaciones erróneas. Se debe de investigar los outliers porque ellos pueden proveer información útil acerca de los datos o proceso. Algunas explicaciones de que los outliers existan son: Errores de ingreso de datos: corregir el error y reanalizar los datos. Errores del proceso: investigar el proceso para determinar la causa de los outliers. Falta de algún factor: determinar si fallamos en no tener en cuenta algún factor o variable que pueda influenciar al proceso. Valores aleatorios: Investigar el proceso y el outlier para determinar si este ocurre por casualidad, realizar el análisis con y sin el outlier para ver el impacto en los resultados. Frecuentemente es muy fácil identificar outliers gráficamente, Minitab identifica a los outliers en los gráficos de cajas etiquetando con el asterisco (*) las observaciones que están al menos a 1,5 veces del rango intercuartil (Q3-Q1) desde el borde de la caja. Para otros modelos como ANOVA67 se usan gráficos de residuales versus valores ajustados. También existen diagnósticos de medidas tales como Cook’s68 o DFITS69 para determinar si el outlier es una observación influyente.

67

ANOVA [en línea]. Disponible en Internet: http://www.uaem.mx/ebe/stat/secc7.html [Consulta: 20 de Mayo del 2009] 68

COOK’S DISTANCE [en línea]. Disponible en Internet: http://en.wikipedia.org/wiki/Cook%27s_distance [Consulta: 20 de Mayo del 2009] 69

DFFITS [en línea]. Disponible en Internet: http://en.wikipedia.org/wiki/DFFITS [Consulta: 20 de Mayo del 2009]

http://www.uaem.mx/ebe/stat/secc7.html

http://en.wikipedia.org/wiki/Cook%27s_distance

http://en.wikipedia.org/wiki/DFFITS



Por ejemplo en los gráficos siguientes observamos: La mediana es la barra que divide la caja. La dispersión es la longitud de la caja en cuartiles. La asimetría la posición relativa de la mediana al cuarto superior o inferior. La longitud de las colas o bigotes mediante las líneas que se extienden desde la caja. Los valores atípicos u outliers son los representados por asteriscos.

Gráfico 3.6.2-1 Gráfico de Cajas de Tickets (RT) por mes – Servicios 2007

10090807060504030201

250

200

150

100

50

0

Month

Re

so

luti

on

Tim

e (

hs)

Boxplot of Resolution Time (hs) - Services 2007



Gráfico 3.6.2-2 Gráfico de cajas de Tickets (RT) por mes – Servicios 2006

121110090807060504030201

200

150

100

50

0

Month

Re

so

luti

on

Tim

e (

hs)


Gráfico 3.6.2-3 Gráfico de cajas Tickets (RT) por mes – Servicios 2005

121110090807060504030201

250

200

150

100

50

0

Month

Re

so

luti

on

Tim

e (

hs)




3.6.3. Resumen – Estadísticas

En los gráficos de estadísticas de resumen (Statistics Summary), a lo largo de tres años, correspondientes al sumario de tickets de valores estadísticos de los servicios, sugieren una distribución no normal de datos con asimetría derecha. Precisamente, la media de resolución de pedidos o tickets de servicios es entre las 11 y 14 horas y cuyas medianas tienden a 2 horas. Junto con lo anterior se observan valores mínimos y máximos de resolución de los mismos. La cantidad total de datos (N) que intervinieron en el análisis fue alrededor de 5000 por año.

Gráfico 3.6.3-1 Resumen de estadística Tickets (RT) – Servicios 2007

21017514010570350

Median

Mean

1412108642

1st Q uartile 0.337

Median 2.116

3rd Q uartile 18.981

Maximum 227.167

13.048 14.462

1.958 2.284

25.714 26.714

A -Squared 786.33

P-V alue < 0.005

Mean 13.755

StDev 26.205

V ariance 686.687

Skewness 3.0996

Kurtosis 11.3452

N 5283

Minimum 0.006

A nderson-Darling Normality Test

95% C onfidence Interv al for Mean

95% C onfidence Interv al for Median

95% C onfidence Interv al for StDev95% Confidence Intervals

Summary for Resolution Time (hs) - Services 2007




1801501209060300

Median

Mean

12108642

1st Q uartile 0.516

Median 2.308


Maximum 197.988

11.214 12.355

2.154 2.447

22.931 23.738

A -Squared 999.38

P-V alue < 0.005

Mean 11.785

StDev 23.328

V ariance 544.185

Skewness 3.5115

Kurtosis 14.8936

N 6429

Minimum 0.005







24020016012080400

Median

Mean

1412108642

1st Q uartile 0.654

Median 2.224


Maximum 259.533

13.065 14.633

2.080 2.410

26.888 27.997

A -Squared 750.50

P-V alue < 0.005

Mean 13.849

StDev 27.431

V ariance 752.466

Skewness 3.4758

Kurtosis 15.4668

N 4701

Minimum 0.009








3.6.4. Gráficos de comportamiento – Estadísticas

Los gráficos de comportamiento (Run Charts) exhiben los datos en el orden en que ellos fueron observados, se puede advertir si existen patrones obvios. Este test está basado en el número total de corridas que ocurren por encima y por debajo de la de mediana (Number of run about median), muestra si los datos están cerca de la mediana (Mixtures) y si se aglomeran (Clustering). Infiriendo sobre el comportamiento en los distintos años se tiene que: en el año 2005 existían valores de p>0.05, se tenían mezclas y no existían clusters (grupos o conjuntos) de los datos; para los años 2006 y 2007 ya no había mezcla ni cluster de acuerdo a los valores de p. Respecto al análisis de tendencia y oscilación (Number of run up or down), hubo oscilaciones todos los años, pero no tendencias sistemáticas. En el test de la hipótesis estadística, el valor p (p-value) es la probabilidad de obtener un resultado al menos tan extremo como uno que se observo, asumiendo que la hipótesis nula es verdadera. El hecho de que los valores de p están basados en el test y es fundamental para su correcta interpretación. Cuanto menor sea el valor de p, el test rechaza más fuerte la hipótesis nula, es decir, aceptando la hipótesis propuesta. Un valor de p de .05 o menor rechaza la hipótesis nula "al nivel del 5%", es decir, en los supuestos estadísticos utilizados implica que sólo el 5% de veces podría suponer el test valores extremos si la hipótesis nula es verdadera.

Gráfico 3.6.4-1 De comportamiento de Tickets (RT) por mes – Servicios 2007

200180160140120100806040201

250

200

150

100

50

0

Sample

Re

so

luti

on

Tim

e (

hs)

Number of runs about median: 110

Expected number of runs: 103.5

Longest run about median: 11

Approx P-Value for Clustering: 0.819

Approx P-Value for Mixtures: 0.181

Number of runs up or down: 139


Longest run up or down: 4

Approx P-Value for Trends: 0.671

Approx P-Value for Oscillation: 0.329

Run Chart of Resolution Time (hs) - Services 2007




280260240220200180160140120100806040201

200

150

100

50

0

Sample

Re

so

luti

on

Tim

e (

hs)











Run Chart of Resolution Time (hs) by Month - Services 2006


160140120100806040201

250

200

150

100

50

0

Sample

Re

so

luti

on

Tim

e (

hs)











Run Chart of Resolution Time (hs) by Month - Services 2005



3.6.5. Gráficos de Pareto – Estadísticas

Antes de comenzar a examinar los gráficos de Pareto, cabe aclarar los conceptos de definiciones de severidad e impacto que maneja la empresa estudiada. MONET es el sistema de mesa de ayuda con el que cuenta la empresa.

Estándar de mesa de ayuda. Definiciones de Severidad e impacto Severidad BAJA – La petición del cliente será automáticamente colocada en la severidad baja, para crear un nuevo ticket de cliente dentro de sistema de mesa de ayuda. El ticket de mesa de ayuda debería permanecer en el estado de severidad baja a menos que el cliente declare que la cuestión es más sensible al tiempo que una normal, o si el analista de mesa de ayuda determina que esta garantiza una prioridad más alta basada en una cuestión específica e impacto de usuario. Severidad MEDIA – Este nivel debería ser utilizado para cuestiones que requieren una atención más expeditiva, pero no una resolución inmediata. Severidad ALTA – Este nivel debería ser utilizado para cuestiones que requieren atención inmediata. Si un cliente solicita que un ticket sea colocado en la prioridad alta, todas las partes implicados (grupos de intensificación, etc.) deberían ser notificadas. Severidad CRÍTICA – Esta debería ser reservada para cuestiones que tienen un impacto inmediato, perjudicial en las operaciones comerciales del negocio. Incluiría todas las interrupciones de servidor y sitio web o cuestiones de la corporación en su totalidad. Impacto INDIVIDUAL - La petición del cliente será automáticamente colocada aquí para crear y ahorrar un nuevo ticket de cliente dentro del sistema de mesa de ayuda. El ticket debería permanecer en este estado a menos que el cliente declare que la cuestión afecta a más de un usuario, o si el analista de mesa de ayuda lo determina así y garantiza un nivel de impacto más alto, basado en una cuestión específica y severidad. Impacto de DEPARTAMENTO – Usuarios múltiples afectados, pero es una cuestión aislada a un departamento solo o una pequeña área. Impacto COMERCIAL – La cuestión afecta departamentos múltiples y/o posiciones. El impacto generalmente tiene que ver con tickets de severidad crítica. Impacto de CLIENTE EXTERNO – Esta categoría es la más alta y crítica de los niveles de impacto. Las cuestiones de este causarían la mayor pérdida potencial al negocio. Este generalmente tiene que ver con tickets de severidad crítica.

Con lo anterior, puede observarse en los gráficos de Pareto, que reflejan los servicios por severidad, que no más de un 5% del total corresponden a severidad alta o media. Esto da una idea clara de la distribución de la población en cuanto a la severidad, lo cual hace que un ticket de más alta severidad deba aguardar menos en su resolución debido a su importancia, es decir, priorizado sobre los otros. Las categorías están definidas previamente y la IT tiene la facultad de re-categorizar los datos de acuerdo a ellas.



Gráfico 3.6.5-1 Pareto de Tickets por severidad – Servicios 2007

MONET

4800

3600

2400

1200

0

MONET

4800

3600

2400

1200

0

Severity = Critical

System of Record

Co

un

t

Severity = High

Severity = Low Severity = Medium

MONET

of Record

System

3 8

4928

344

Pareto Chart of System of Record by Severity - Services 2007


MONET

6000

4500

3000

1500

0

MONET

6000

4500

3000

1500

0

Severity = High

Tickets

Co

un

t

Severity = Low

Severity = Medium

MONET

Tickets

13

6071

345

Pareto Chart of Tickets by Severity - Services 2006




MONET

4000

3000

2000

1000

0

MONET

4000

3000

2000

1000

0

Severity = High

Tickets

Co

un

t

Severity = Low

Severity = Medium

MONET

Tickets

7

4447

247

Pareto Chart of Tickets by Severity - Services 2005

En el caso de los gráficos de Pareto de los servicios por impacto, se observa que aproximadamente un 2% del total corresponden a aquellos individuales.

Gráfico 3.6.5-4 Pareto de Tickets por impacto – Servicios 2007

MONET

6000

4500

3000

1500

0

MONET

6000

4500

3000

1500

0

Impact = Company

Ticket

Co

un

t

Impact = Department

Impact = External Customer Impact = Individual

MONET

Tickets

6 81

3

5437

Pareto Chart of Ticket by Impact - Servicies 2007




MONET

6000

4500

3000

1500

0

MONET

6000

4500

3000

1500

0

Impact = Company

Tickets

Co

un

t

Impact = Department


MONET

Tickets

9 96

13

6308

Pareto Chart of Tickets by Impact - Services 2006


MONET

4000

3000

2000

1000

0

MONET

4000

3000

2000

1000

0

Impact = Company

Tickets

Co

un

t

Impact = Department


MONET

Tickets

3 70

1

4627

Pareto Chart of Tickets by Impact - Services 2005

Los integrantes del grupo de la IT tienen asignadas diferentes actividades. Hay quienes están enfocados principalmente al soporte de primer nivel, y son aquellos que más tickets resueltos tienen; otros miembros con más experiencia manejan otras tareas del área y sólo parcialmente dedicados a la resolución de tickets, que dependerá de su complejidad.



Se advierte que quizás se debería analizar más en profundidad la utilización del tiempo destinado a la resolución de tickets, correspondiente a cada uno de los recursos, en función a sistema de reportes de actividades.

Gráfico 3.6.5-7 Pareto de Tickets por miembros de TI – Servicios 2007

2000

1000

0

MO NET

MO NET

2000

1000

0

MO NET

2000

1000

0

O wner C ore ID = A JO 023

System of Record

Co

un

t

O wner C ore ID = A LM045 O wner C ore ID = A RG031

O wner C ore ID = FMXP43 O wner C ore ID = FQ G846 O wner C ore ID = Q BWD64

O wner C ore ID = TC Q N73

MONET

2007

Service

Tickets -

1875

763

305

754557

962

64

Pareto Chart of Tickets by IT Members - Services 2007


2000

1000

0

MO NET

MO NET

2000

1000

0

MO NET

2000

1000

0

O wner C ore ID = A JO 023

Tickets

Co

un

t

O wner C ore ID = A JR037 O wner C ore ID = A LM045

O wner C ore ID = A RG031 O wner C ore ID = FMXP43 O wner C ore ID = FQ G846

O wner C ore ID = Q BWD64

MONET

Tickets2475

256

2029

831

120270

445





MONET

2000

1500

1000

500

0

MONET

2000

1500

1000

500

0MONET

IT Members = AJO023

Tickets

Co

un

t

IT Members = AJR037 IT Members = ALM045

IT Members = AMT038 IT Members = ARC038 IT Members = ARG031

MONET

Tickets2127

240

1268

2

521 543


En los gráficos de Pareto que se presentan a continuación se intenta reflejar el tiempo de resolución de los tickets de servicios, agrupándolos en días. Allí se advierte que un gran porcentaje (aproximadamente el 85%) son resueltos dentro del mismo día, quedando una distribución que disminuye en el transcurso de los días subsiguientes.

Gráfico 3.6.5-10 Pareto de Tickets por días (agrupados) – Servicios 2007

MO NET

4000

3000

2000

1000

0

MO NET

4000

3000

2000

1000

0

MO NET

Bucket = 1 DA Y

System of Record

Co

un

t

Bucket = 1 WEEK+ Bucket = 2 DA YS

Bucket = 3 DA YS Bucket = 4 DA YS Bucket = 6 DA YS

MONET

2007

Servicies

Tickets -4359

30

474

183 124 110

Pareto Chart of Ticket by Bucket Day - Services 2007




MONET

6000

4500

3000

1500

0

MONET

6000

4500

3000

1500

0MONET

Bucket = 1 DAY

Tickets

Co

un

t

Bucket = 1 WEEK+ Bucket = 2 DAYS

Bucket = 3 DAYS Bucket = 4 DAYS Bucket = 6 DAYS

MONET

Tickets5561

30448

173 119 95

Pareto Chart of Tickets (RT) by Bucket day - Services 2006


MONET

4000

3000

2000

1000

0

MONET

4000

3000

2000

1000

0MONET

Bucket = 1 DAY

Tickets

Co

un

t



MONET

Tickets4024

36267

163 133 78

Pareto Chart of Tickets by Bucket Day - Services 2005

De los gráficos que prosiguen, los pertenecientes al año 2005 indican que el tiempo en cola (Backlog Bucket) o espera de un ticket que no tiene asignada una persona del área de IT o agente era como máximo de 6 días. Por otro lado, el 82% de los outliers no pasaban de un día en espera. En el 2006 se pasó a un máximo de entre 7 y 14 días,



pero con un 93% de espera de no más de un día. Y finalmente, en el 2007 también si tiene un máximo de entre 7 y 14 días, pero el porcentaje de los tickets no asignados varía del 2006 al 2007, desde el 0,2% al 0,1% del total respectivamente.

Gráfico 3.6.5-13 Pareto de Tickets por días de espera (agrupados) – Servicios 2007

MO NET

4800

3600

2400

1200

0

MO NET

4800

3600

2400

1200

0

MO NET

Backlog Bucket = 1 DA Y

System of Record

Co

un

t

Backlog Bucket = 1 WEEK+ Backlog Bucket = 2 DA YS

Backlog Bucket = 3 DA YS Backlog Bucket = 4 DA YS Backlog Bucket = 6 DA YS

MONET

2007

Services

Tickets -5012

5 109

94 37 23

Pareto Chart of Tickets by Backlog Bucket - Services 2007


MONET

6000

4500

3000

1500

0

MONET

6000

4500

3000

1500

0MONET

Backlog Bucket = 1 DAY

Tickets

Co

un

t

Backlog Bucket = 1 WEEK+ Backlog Bucket = 2 DAYS

Backlog Bucket = 3 DAYS Backlog Bucket = 4 DAYS Backlog Bucket = 6 DAYS

MONET

Tickets6013

13 176

118 64 42

Pareto Chart of Tickets by Backlog Bucket Days - Services 2006




MONET

MONET

80

60

40

20

0

MONET

80

60

40

20

0


Tickets

Co

un

t

Backlog Bucket = 2 DAYS Backlog Bucket = 3 DAYS


MONET

Tickets73

3 1

4 4

Pareto Chart of Tickets by Backlog Bucket Time - Problems 2005

En el año 2007 el 99,84% de las encuestas de satisfacción del cliente (CSS) fueron positivas. Para el 2006 este valor fue del 99,86%, y en el 2005 del 99,91%. Lo que denota una disminución en la satisfacción, aunque no significativa. Por otro lado el porcentaje de las encuestas individuales por ticket de satisfacción, que no fueron contestadas, en el 2007 alcanzaron el 37%, siendo que en el 2005 fue del 22%, con lo cual se concluye que ha aumentado la falta de retroalimentación disponible por el usuario sobre el servicio recibido. En lo que respecta a estas cuestiones, se podría considerar como costo de la calidad (Cost Of Quality, COQ) a la cantidad de tickets cuyas CSS fueron reportadas como satisfechas, de allí se obtuvo:

2005, el 0,09 % fue considerado como COQ para ticket de servicios.

2006, el 0,14 % fue considerado como COQ para ticket de servicios.

2007, el 0,16 % fue considerado como COQ para ticket de servicios. Esto indica que el COQ estaría dentro del 0,2 % en relación con los servicios.



Gráfico 3.6.5-16 Pareto de satisfacción del cliente por ticket – Servicios 2007

MONET

3000

2000

1000

0

MONET

3000

2000

1000

0

Monet C SS Results = Not Satisfied

Tickets

Co

un

t

Monet C SS Results = Satisfied

Monet C SS Results = Surv ey not C ompleted

MONET

2007

Services

Tickets -

5

3321

1954

Pareto Chart of Ticket by Monet CSS Results - Services 2007


MONET

4000

3000

2000

1000

0

MONET

4000

3000

2000

1000

0


Tickets

Co

un

t



MONET

Tickets

6

4295

2125

Pareto Chart Customer Satisfaction Survey by Tickets - Services 2006




MONET

4000

3000

2000

1000

0

MONET

4000

3000

2000

1000

0


Tickets

Co

un

t



MONET

Tickets

3

3636

1062

Pareto Chart of Tickets by Monet CSS Results - Services 2005

En base al mismo criterio anterior, fue analizado el costo de la no calidad o COPQ (Cost Of Poor Quality) de acuerdo a tickets que fueron reabiertos (re-opened). Los COPQ implican un re-trabajo, ya que no fueron resueltos desde el punto de vista del usuario final. Aunque, el área de la IT los había considerado como solucionados. Los datos reflejaron los siguientes porcentajes por año:

2005, el 0,5 % fue considerado como COPQ para ticket de servicios.

2006, el 0,48 % fue considerado como COPQ para ticket de servicios.

2007, el 0,49 % fue considerado como COPQ para ticket de servicios. Esto indica que el COPQ se mantuvo aproximadamente constante, dentro del 0,5% en relación con los servicios.

Con esto tenemos que el CTQ está alrededor del 0,7% del total de servicios, dado que: CTQ = COQ + COPQ.



Gráfico 3.6.5-19 Pareto de tickets reabiertos – Servicios 2007

MONET

6000

5000

4000

3000

2000

1000

0

MONET

Reopened Count = 0

Tickets

Co

un

t

Reopened Count = 1

MONET

2007

Services

Tickets -

5254

26

Pareto Chart of Ticket by Reopened Count - Services 2007


MONET

7000

6000

5000

4000

3000

2000

1000

0

MONET

Reopened Count = 0

Tickets

Co

un

t

Reopened Count = 1MONET

Tickets

6395

31

Pareto Chart of Tickets by Reopened Count Times - Services 2006




MONET

5000

4000

3000

2000

1000

0

MONET

Reopened Count = 0

Tickets

Co

un

t


Tickets

4674

27

Pareto Chart of Tickets by Reopened Count Times - Services 2005



3.7. Problemas, tiempo de resolución (horas) y variables

Cabe señalar que en esta sección 3.7 (tickets relacionados con problemas) se realizara el mismo análisis estadístico que el realizado en la sección 3.6 (tickets relacionados con servicios) por ende aquellos que no estén interesados en ver los resultados estadísticos podrán obviar la lectura de esta sección. Se lleva a cabo el análisis de aquellos tickets clasificados como problemas. Al igual que en el ítem anterior, se abarcan los años 2005, 2006 y 2007. En esta sección se representan los gráficos y tablas estadísticas más comunes, que permiten estimar el comportamiento de los mismos.

3.7.1. Gráficos de valores individuales - Estadísticas

En estos gráficos se reflejan las distribuciones de los tickets de problemas por mes. En los años registrados se obtuvo que los valores máximos entre las 100 y 120 horas (equivalente a 5 días), considerando el tiempo fuera del horario de soporte, como así también feriados y fines de semana. También aquí, es importante destacar que el tiempo de resolución (Resolution Time, RT) es calculado como el tiempo total desde que se abrió el ticket, menos el tiempo que está en espera de una respuesta del usuario sobre más información o disponibilidad; en caso de requerir soporte solicitado a terceras empresas, como contratación de equipos, este también es restado del total. Como resultado se manifiestan las variaciones en las cantidades, dependiendo del mes, y se concluye que en el 2006 los tiempos individuales máximos tuvieron un mejor tiempo de respuesta que en los otros dos años.

Gráfico 3.7.1-1 Valores individuales (RT) por mes – Problemas 2007

100908070504030201

100

80

60

40

20

0

Month

Re

so

luti

on

Tim

e (

hs)

Individual Value Plot of Resolution Time (hs) by Month - Problems 2007




121110090807060504030201

80

70

60

50

40

30

20

10

0

Month

Re

so

luti

on

Tim

e (

hs)

Individual Value Plot of Resolution Time (hs) - Problems 2006


1211100908070605040201

140

120

100

80

60

40

20

0

Month

Re

so

luti

on

Tim

e (

hs)




3.7.2. Gráficos de cajas - Estadísticas

En el caso de análisis de problemas se tiene poca cantidad de tickets por mes, y existe variación del RT entre ellos, por lo que los boxplots son más extensos que aquellos obtenidos para servicios, demostrando mayor diferencia entre cuartiles. La cantidad de datos es de 85 tickets para el 2005, 71 tickets para el 2006 y 27 tickets para el 2007. Las gráficas evidencian que en el año 2006 existe una mayor perfomance en cuanto al RT de los problemas, algunos de mayor complejidad suelen corresponder a los outliers. Se revelan más detalles al ir analizando el resto de los gráficos, que brindan información diversa para poder tener una idea más global de los datos y su significado.

Gráfico 3.7.2-1 Gráfico de Cajas de Tickets (RT) por mes – Problemas 2007

100908070504030201

100

80

60

40

20

0

Month

Re

so

luti

on

Tim

e (

hs)

Boxplot of Resolution Time (hs) by Month - Problems 2007




121110090807060504030201

80

70

60

50

40

30

20

10

0

Month

Re

so

luti

on

Tim

e (

hs)

Boxplot of Resolution Time (hs) - Problems 2006


1211100908070605040201

140

120

100

80

60

40

20

0

Month

Re

so

luti

on

Tim

e (

hs)




3.7.3. Resumen - Estadísticas

En los gráficos de resumen (Statistics Summary) de problemas se obtiene, al igual que en servicios, una distribución no normal de datos. La media de resolución de problemas entre las 18 y 22 horas y las medianas entre las 1,75 y 4,31 horas, sugieren una distribución no normal de datos con asimetría derecha. También se pueden observar valores mínimos y máximos de resolución de los mismos. La cantidad total de datos que intervinieron en el análisis fue alrededor de 75 a 80 por año excepto para el 2007 con 27 tickets.

Gráfico 3.7.3-1 Resumen de estadística Tickets (RT) – Problemas 2007

100806040200

Median

Mean

302520151050

1st Q uartile 0.614

Median 1.728


Maximum 99.040

8.312 31.800

0.923 24.213

23.380 40.686

A -Squared 3.13

P-V alue < 0.005

Mean 20.056

StDev 29.688

V ariance 881.387

Skewness 1.61790

Kurtosis 1.75041

N 27

Minimum 0.059





Summary for Resolution Time (hs) - Problems 2007




644832160

Median

Mean

2520151050

1st Q uartile 1.538

Median 5.414


Maximum 71.791

13.173 23.994

2.872 20.615

19.621 27.391

A -Squared 6.63

P-V alue < 0.005

Mean 18.584

StDev 22.860

V ariance 522.587

Skewness 1.08048

Kurtosis -0.22835

N 71

Minimum 0.026







120100806040200

Median

Mean

302520151050

1st Q uartile 0.646

Median 4.315


Maximum 123.203

15.213 30.198

2.244 14.373

30.184 40.916

A -Squared 11.22

P-V alue < 0.005

Mean 22.706

StDev 34.735

V ariance 1206.552

Skewness 1.72738

Kurtosis 1.70031

N 85

Minimum 0.029








3.7.4. Gráficos de comportamiento - Estadísticas

Los gráficos de comportamiento (Run Charts) exhiben los datos en el orden en que ellos fueron observados, se puede advertir si existen patrones sistemáticos o no aleatorios. Este test está basado en el número total de corridas que ocurren por encima y por debajo de la de mediana (Number of run about median), muestra si los datos están cerca de la mediana (Mixtures) y aglomeramiento (Clustering). El comportamiento advertido en los años 2005, 2006 y 2007 muestra que no existían valores de p<0.05, no hubo mezcla, ni aglomeramiento de datos. A su vez, no se hallaron tendencias ni oscilaciones entre ellos.

Gráfico 3.7.4-1 De comportamiento de Tickets (RT) por mes – Problemas 2007

10987654321

100

80

60

40

20

0

Sample

Re

so

luti

on

Tim

e (

hs)











Run Chart of Resolution Time (hs) by Month - Problems 2007




1413121110987654321

80

70

60

50

40

30

20

10

0

Sample

Re

so

luti

on

Tim

e (

hs)











Run Chart of Resolution Time (hs) by Month - Problems 2006


121110987654321

140

120

100

80

60

40

20

0

Sample

Re

so

luti

on

Tim

e (

hs)











Run Chart of Resolution Time (hs) - Problems 2005



3.7.5. Gráficos de Pareto - Estadísticas

En los gráficos de Pareto respectivos a problemas, estos se reflejan según el tipo de severidad. Esto da una idea clara de la distribución de la población en cuanto a la severidad, lo cual hace que un ticket de más alta severidad deba aguardar menos en su resolución debido a su importancia, es decir, priorizado sobre los otros. El análisis expuso que en el 2005 menos del 20% del total corresponden a severidad alta o media. Para el 2006 el valor alcanzó el 21% y el mismo para el 2007 fue de 18%.

Gráfico 3.7.5-1 Pareto de Tickets por severidad – Problemas 2007

MONET

20

15

10

5

0

MONET

20

15

10

5

0

Severity = High

Tickets

Co

un

t

Severity = Low

Severity = Medium

MONET

Tickets

3

22

2

Pareto Chart of Tickets by Severity - Problems 2007




MONET

60

45

30

15

0

MONET

60

45

30

15

0

Severity = High

Tickets

Co

un

t

Severity = Low

Severity = Medium

MONET

Tickets

1

56

14



MONET

60

45

30

15

0

MONET

60

45

30

15

0

Severity = High

Tickets

Co

un

t

Severity = Low

Severity = Medium

MONET

Tickets

1

69

15




En el caso de los gráficos de Pareto de los servicios por impacto, se observa entre el 7,5 y 8,5% del total corresponden a aquellos individuales.

Gráfico 3.7.5-4 Pareto de Tickets por impacto – Problemas 2007

MONET

25

20

15

10

5

0

MONET

Impact = Department

Tickets

Co

un

t

Impact = IndividualMONET

Tickets

2

25

Pareto Chart of Tickets by Impact - Problems 2007




MONET

60

45

30

15

0

MONET

60

45

30

15

0

Impact = Department

Tickets

Co

un

t

Impact = Individual

Impact = Motorola

MONET

Tickets

4

65

2



MONET

80

70

60

50

40

30

20

10

0

MONET

Impact = Department

Tickets

Co

un

t

Impact = IndividualMONET

Tickets

7

78




Gráfico 3.7.5-7 Pareto de Tickets por miembros de TI – Problemas 2007

10

5

0

MO NET

MO NET

10

5

0

MO NET

10

5

0

IT Members = A JO 023

Tickets

Co

un

t

IT Members = A LM045 IT Members = C DT012

IT Members = C KR024 IT Members = FMXP43 IT Members = Q BWD64

IT Members = TC Q N73

MONET

Tickets

Pareto Chart of Tickets by IT Members - Problems 2007


20

10

0

MO NET

MO NET

20

10

0

MO NET

20

10

0

IT Member = A JO 023

Tickets

Co

un

t

IT Member = A JR037 IT Member = A LM045

IT Member = A RG031 IT Member = FMXP43 IT Member = FQ G846

IT Member = Q BWD64

MONET

Tickets

14

26

3

11

1

15

1





MONET

MONET

60

45

30

15

0

MONET

60

45

30

15

0

IT Members = AJO023

Tickets

Co

un

t

IT Members = AJR037 IT Members = ALM045

IT Members = ARC038 IT Members = ARG031

MONET

Tickets

8

60

10

16


En los gráficos que prosiguen, se indica el tiempo de resolución de los tickets (Bucket Time) de problemas, agrupándolos en días. Se tiene que un gran porcentaje (aproximadamente el 66%) de los mismos son resueltos dentro del mismo día, y la distribución muestra una disminución en el transcurso de los días subsiguientes.

Gráfico 3.7.5-10 Pareto de Tickets por días (agrupados) – Problemas 2007

MONET

MONET

20

15

10

5

0

MONET

20

15

10

5

0

Bucket = 1 DAY

Tickets

Co

un

t

Bucket = 2 DAYS Bucket = 3 DAYS

Bucket = 4 DAYS Bucket = 6 DAYS

MONET

Tickets18

43

1 1

Pareto Chart of Tickets by Bucket Time - Problems 2007




MONET

40

30

20

10

0

MONET

40

30

20

10

0

Bucket = 1 DAY

Tickets

Co

un

t

Bucket = 2 DAYS

Bucket = 3 DAYS

MONET

Tickets47

12

12



MONET

60

45

30

15

0

MONET

60

45

30

15

0MONET

Bucket = 1 DAY

Tickets

Co

un

t



MONET

Tickets63

16

4 47




El primer gráfico indica que en el 2005 el tiempo en cola o espera de un ticket, que no tenía asignado un agente de IT, era como máximo de 6 días. Aunque los outliers, y con alto porcentaje (82%), no pasaban de un día en espera. En el 2006 se pasa a un máximo de 2 días, pero un 83% no demoraba más de un día. Finalmente en el 2007, el máximo fue de 3 días, aunque el 92% contaba con tiempos menores al día.

Gráfico 3.7.5-13 Pareto de Tickets por días de espera (agrupados) – Problemas 2007

MONET

24

18

12

6

0

MONET

24

18

12

6

0


Tickets

Co

un

t

Backlog Bucket = 2 DAYS

Backlog Bucket = 3 DAYS

MONET

Tickets25

1

1

Pareto Chart of Tickets by Backlog Bucket - Problems 2007


MONET

60

50

40

30

20

10

0

MONET


Tickets

Co

un

t

Backlog Bucket = 2 DAYSMONET

Tickets

59

12

Pareto Chart of Tickets by Backlog Bucket - Problems 2006




MONET

MONET

80

60

40

20

0

MONET

80

60

40

20

0


Tickets

Co

un

t



MONET

Tickets73

3 1

4 4

Pareto Chart of Tickets by Backlog Bucket Time - Problems 2005

En la totalidad de las encuestas realizadas en los distintos, el cliente estaba satisfecho con el trabajo realizado. Por otro lado el porcentaje de las encuestas individuales por ticket de satisfacción, que no fueron contestadas, en el 2007 alcanzaron el 30%, al igual que en el 2005, y durante el 2006 fue del 28%, con lo cual se concluye que no existen variaciones significativas entre los diferentes años. Sin embargo, el porcentaje de falta de retroalimentación con el usuario del servicio es alto. En lo que respecta a estas cuestiones, se podría considerar como costo de la calidad (Cost Of Quality, COQ) a la cantidad de tickets cuyas CSS fueron reportadas como no satisfechas, de allí se obtuvo:

2005, el 0,09 % fue considerado como COQ para ticket de problemas.

2006, el 0,14 % fue considerado como COQ para ticket de problemas.

2007, el 0,16 % fue considerado como COQ para ticket de problemas. Esto indica que el COQ estaría dentro del 0,2 % en relación con los servicios.



Gráfico 3.7.5-16 Pareto de satisfacción del cliente por ticket – Problemas 2007

MONET

20

15

10

5

0

MONET

Monet CSS Results = Satisfied

Tickets

Co

un

t

Monet CSS Results = Survey not Completed

MONET

Tickets19

8

Pareto Chart of Tickets by Monet CSS Results - Problems 2007


MONET

40

30

20

10

0

MONET


Tickets

Co

un

t


MONET

Tickets43

28





MONET

60

50

40

30

20

10

0

MONET


Tickets

Co

un

t


MONET

Tickets59

26


Fue analizado el costo de la no calidad o COPQ (Cost Of Poor Quality) de acuerdo a tickets que fueron reabiertos (re-opened). Los COPQ implican un re-trabajo, ya que no fueron resueltos desde el punto de vista del usuario final. Aunque, el área de la IT los había considerado como solucionados. Los datos reflejaron los siguientes porcentajes por año:

2005, el 1.17 % fue considerado como COPQ para ticket de problemas.

2006, el 0 % fue considerado como COPQ para ticket de problemas.

2007, el 0 % fue considerado como COPQ para ticket de problemas. Esto indica que el COPQ se mantuvo aproximadamente constante, y fue mejorando hasta obtener 0 % los últimos años.

Con esto tenemos que el CTQ está alrededor del 0,3% del total de servicios, dado que: CTQ = COQ + COPQ.



Gráfico 3.7.5-19 Pareto de tickets reabiertos (cero) – Problemas 2007

Count 27

Percent 100.0

Cum % 100.0

Tickets MONET

30

25

20

15

10

5

0

100

80

60

40

20

0

Co

un

t

Pe

rce

nt

27

Pareto Chart of Tickets Reopened Times - Problems 2007

Gráfico 3.7.5-20 Pareto de tickets reabiertos (cero) – Problemas 2006

Count 71

Percent 100.0

Cum % 100.0

Tickets MONET

80

70

60

50

40

30

20

10

0

100

80

60

40

20

0

Co

un

t

Pe

rce

nt

71

Pareto Chart of Tickets Reopened Times - Problems 2006



Gráfico 3.7.5-21 Pareto de tickets reabiertos – Problemas 2005

MONET

90

80

70

60

50

40

30

20

10

0

MONET

Reopened Count = 0

Tickets

Co

un

t


Tickets

84

1

Pareto Chart of Tickets by Reopened Count Time - Problems 2005



4. ANÁLISIS DE OPORTUNIDADES

Esta es la etapa que ayuda a las empresas a establecer la relación entre las variables de respuesta (Ys) y las de control (Xs) de proceso. Durante esta etapa de implementación de Six Sigma: - Se crean los mapas de proceso de bajo nivel. - Se establece la capacidad de procesos para las variables de salida críticas. - Se establece la relación entre las variables críticas de salida y las de control de

proceso. - Se identifican las causas aparentes de variación. Este análisis permite identificar las maneras de eliminar la diferencia entre la actual performance del sistema y el objetivo deseado; guiado a través de herramientas estadísticas. A continuación se muestran las características generales de esta etapa. Más adelante se presenta un detallado marco de datos, gráficas y conclusiones que le pertenecen.

Gráfico 4-1 Análisis de oportunidades



4.1. Bases y definiciones para tickets de servicios y problemas

Como es práctica común, en empresas que hacen manejo de cálculos estadísticos para estudios de capacidad y estabilidad de los procesos, se analizarán aquellos puntos que son outliers. Estos implican casos especiales, y para ellos se definen planes de acción, teniendo en cuenta la regla de no remover más del 5% del total de la muestra. En esta fase se comienza analizando en profundidad los datos disponibles de las métricas, de acuerdo al tiempo de resolución (RT) como variable (siempre medido en horas). Este será calculado como el tiempo total (Total Time, TT) menos el que permanece en espera en el cliente (Customer Hold, CH) y/o en el proveedor (Vendor Hold, VH). Es válida la siguiente aclaración:

El sistema acumula las 24 horas del día, aunque las correspondientes al soporte son 9. También se adicionan los fines de semana y feriados, que reflejan aquellos tickets abiertos después del horario de servicio de los viernes, y que recién al lunes siguiente serán analizados (introduciendo un backlog del ticket de 63 horas como mínimo sin asignación). Solamente los tickets críticos son tratados fuera del horario de soporte.

Los perfiles habilitados para los tickets son los servicios, problemas y pedidos de cambio. Cabe mencionar que estos últimos han sido implementados recientemente y no existe historia suficiente para su análisis en profundidad.

4.1.1. Análisis del tiempo de resolución de servicios - 2007

Se examinará el tiempo de resolución (hs) para servicios desde el 2005 hasta el 2007. Con los datos correspondientes a estos años, y mediante el programa estadístico

Minitab, se obtuvieron los gráficos subsecuentes:




10090807060504030201

700

600

500

400

300

200

100

0

Month

Re

so

luti

on

Tim

e (

hs)

Individual Value Plot of Resolution Time (hs) vs Month - Service 2007


10090807060504030201

700

600

500

400

300

200

100

0

Month

Re

so

luti

on

Tim

e (

hs)




Gráfico 4.1.1-3 Resumen de estadística Tickets (RT) por mes – Servicios 2007

6005004003002001000

Median

Mean

1412108642

1st Q uartile 0.338

Median 2.119


Maximum 668.903

13.406 14.971

1.968 2.287

28.492 29.599

A -Squared 806.19

P-V alue < 0.005

Mean 14.189

StDev 29.035

V ariance 843.015

Skewness 5.2145

Kurtosis 62.9354

N 5291

Minimum 0.006






La resolución muestra que la distribución no es normal, y por ende deber ser transformada y corregida para normalizarla. Con este fin primero se removió el 0.1% de los outliers, dadas la siguiente posibilidad: aquellos pueden ser errores del representante del servicio de soporte de ayuda de la IT, que ha olvidado colocar el ticket en el estado pertinente. Esto es, en vez de asentarlo en estado de espera del cliente o del usuario final, ha quedado en el área de IT; por ello el tiempo sigue sumando, cuando en realidad es incorrecto. El plan de acción se realizó resaltando que el estado de los tickets de cualquier tipo tiene que estar siempre actualizado, debiendo de registrarse toda la información para control del usuario final o de la IT. Con tales correcciones (remoción del 0.1% outliers) se reelaboraron los gráficos, presentados a continuación.



Gráfico 4.1.1-4 Valores individuales (RT) por mes – Servicios 2007 - corregida

10090807060504030201

250

200

150

100

50

0

Month

Re

so

luti

on

Tim

e (

hs)


Gráfico 4.1.1-5 Gráfico de Cajas de Tickets (RT) por mes – Servicios 2007 - corregida

10090807060504030201

250

200

150

100

50

0

Month

Re

so

luti

on

Tim

e (

hs)

Boxplot of Resolution Time (hs) - Service 2007



Gráfico 4.1.1-6 Resumen de estadística Tickets (RT) por mes – Servicios 2007 - corregida

21017514010570350

Median

Mean

1412108642

1st Q uartile 0.337

Median 2.116


Maximum 227.167

13.048 14.462

1.958 2.284

25.714 26.714

A -Squared 786.33

P-V alue < 0.005

Mean 13.755

StDev 26.205

V ariance 686.687

Skewness 3.0996

Kurtosis 11.3452

N 5283

Minimum 0.006





Summary for Resolution Time (hs) - Service 2007

Cuando se corroboró, con el programa estadístico Minitab, para la normalización de datos de servicios 2007 (tomados mensualmente), donde realiza distintos test de bondad de ajuste a los datos para normalizarlos tomando distintas bondad de ajustes, no se hallaron encontraron las mismas con de valores P > 0,05; de allí se desprende que es imposible utilizar las sugeridas por el programa. Minitab aplica el LRT70 (likelihood ratio test) que es un test estadístico de bondad de ajuste entre diferentes modelos, en este caso Minitab utiliza 10 modelos para el ejecutar el mismo. El test de bondad de ajuste o LRT determina cuando un modelo estadístico se ajusta a los datos analizando la diferencia de los valores observados y los valores esperados en el modelo. Para datos continuos, se puede valorar la bondad de ajuste visualmente con un grafico de probabilidad, o cuantitativamente con test de hipótesis tal como el de Anderson-Darling test. El test de bondad de ajuste usa las siguientes hipótesis:

H0: El modelo si se adecuadamente describe los datos provistos.

H1: El modelo no se adecuadamente describe los datos provistos.

70

LIKELIHOOD RATIO TEST (LRT) [en línea]. Disponible en Internet: http://www.molecularevolution.org/si/resources/lrt.php [Consulta: 20 de Mayo del 2009]

http://www.molecularevolution.org/si/resources/lrt.php



El valor de p para la distribución analizada para cada propuesta, si es menor a 0,05 podemos rechazar la hipótesis nula (H0) de un buen ajuste "al nivel del 5%", es decir, en

los supuestos estadísticos utilizados implica que sólo el 5% de veces podría suponer el test valores extremos si la hipótesis nula es verdadera. Cuanto menor sea el valor de p, el test rechaza más fuerte la hipótesis nula, es decir, aceptando la hipótesis propuesta (H1). Ahora bien, siempre podemos equivocarnos. Si rechazamos la hipótesis nula, existe la posibilidad de que sea cierta, es decir, que no haya diferencias entre los grupos. El error que se comete en este caso se denomina error tipo I o tipo alfa. Precisamente, los diferentes test estadísticos permiten conocer la magnitud de este tipo de error alfa. También, si no rechazamos la hipótesis nula, existe la posibilidad de que en realidad no sea cierta, es decir, que haya diferencias entre los grupos. El error que se comete en este segundo caso se denomina error tipo II o tipo beta. La potencia de un test estadístico, es decir su capacidad para detectar diferencias cuando realmente existen, es igual al valor 1- beta. Si el error tipo beta es pequeño y hay pocas posibilidades de no rechazar la hipótesis nula cuando no es cierta, decimos que el test es muy potente. Así mismo, se entiende que si somos muy exigen aumentamos las posibilidades de no rechazarla cuando en realidad no es cierta (tendremos mayor posibilidad de cometer un error beta). Por el contrario si somos menos exigentes con el error alfa, disminuimos el error beta y aumentamos la potencia del test estadístico para detectar diferencias.

Tabla 4.1.1-1 Test de bondad de ajuste

Goodness of Fit Test

Distribution AD P LRT P

Normal 786.331 <0.005

Box-Cox Transformation 36.039 <0.005

Lognormal 54.980 <0.005

3-Parameter Lognormal 58.053 * 0.000

Exponential 2369.525 <0.003

2-Parameter Exponential 2371.853 <0.010 0.132

Weibull 36.042 <0.010

3-Parameter Weibull 28.179 <0.005 0.000

Smallest Extreme Value 1009.694 <0.010

Largest Extreme Value 645.698 <0.010

Gamma 77.189 <0.005



Normalización, datos de servicios - 2007

Observando con mayor detenimiento los datos y haciendo referencia al teorema central del límite y plantea que para un tamaño de muestra grande, la distribución de la media muestral será aproximadamente normal; se decidió realizar el análisis basado

en las medias semanales -en vez de mensuales- para aumentar el tamaño de muestra.

Una vez calculadas las medias semanales de los tickets por servicio del año 2007, se aplicó un programa conveniente para su evaluación. Se obtuvo la siguiente tabla:

Tabla 0-1 Análisis estadístico descriptivo (RT). Servicios 2007

Descriptive Statistics: Resolution Time (hs) Variable Week (A) N N* Mean SE Mean StDev Minimum Q1

Resolution Time (hs) 01/07/07 132 0 9.87 1.80 20.66 0.01 0.20

01/14/07 146 0 10.24 1.71 20.60 0.01 0.19

01/21/07 112 0 6.20 1.44 15.23 0.01 0.05

01/28/07 140 0 11.02 1.75 20.74 0.01 0.02

02/04/07 111 0 11.13 1.97 20.74 0.01 0.62

02/11/07 126 0 12.84 2.18 24.46 0.01 1.06

02/18/07 112 0 9.57 2.11 22.31 0.01 0.22

02/25/07 120 0 15.02 2.25 24.64 0.01 0.49

03/04/07 153 0 12.20 1.65 20.36 0.01 0.54

03/11/07 117 0 22.82 3.26 35.22 0.01 0.37

03/18/07 153 0 9.41 1.87 23.12 0.01 0.40

03/25/07 131 0 12.09 2.13 24.41 0.01 0.63

04/01/07 30 0 5.80 1.73 9.47 0.02 0.07

04/08/07 136 0 5.284 0.913 10.647 0.009 0.162

04/15/07 145 0 2.139 0.449 5.403 0.006 0.046

04/22/07 135 0 9.86 1.49 17.34 0.01 0.13

04/29/07 104 0 12.82 2.22 22.61 0.01 0.48

05/06/07 150 0 15.51 1.99 24.40 0.01 0.06

05/13/07 160 0 11.77 1.64 20.73 0.01 0.32

05/20/07 79 0 15.00 3.22 28.63 0.01 0.19

05/27/07 130 0 14.41 2.56 29.19 0.01 0.18

06/03/07 144 0 15.30 2.32 27.84 0.01 0.62

06/10/07 138 0 8.36 1.53 17.96 0.01 0.56

06/17/07 97 0 15.34 2.60 25.64 0.01 0.64

06/24/07 101 0 11.78 1.82 18.33 0.01 1.16

07/01/07 89 0 17.12 3.62 34.12 0.01 0.14

07/08/07 78 0 14.59 3.48 30.72 0.01 0.10

07/15/07 118 0 14.30 2.22 24.11 0.01 0.14

07/22/07 155 0 17.01 2.05 25.46 0.01 0.24

07/29/07 172 0 11.87 1.69 22.12 0.01 0.09

08/05/07 131 0 14.73 2.31 26.42 0.01 0.43

08/12/07 168 0 19.51 2.26 29.29 0.01 0.64

08/19/07 128 0 24.95 3.41 38.62 0.01 0.72

08/26/07 127 0 10.30 1.74 19.65 0.01 0.73

09/02/07 133 0 20.26 2.73 31.53 0.01 1.22

09/09/07 165 0 20.32 2.20 28.22 0.01 0.68

09/16/07 112 0 18.11 3.61 38.21 0.01 0.40

09/23/07 107 0 20.69 3.80 39.36 0.01 0.40

09/30/07 172 0 14.46 2.01 26.42 0.01 0.29

10/07/07 99 0 13.83 3.21 31.96 0.02 0.27

10/14/07 93 0 17.17 3.56 34.31 0.01 0.77

10/21/07 89 0 17.46 3.52 33.20 0.01 1.08

10/28/07 45 0 25.42 6.25 41.92 0.01 1.03



Gráfico 0-1 Análisis de normalidad – Media semanal. Servicios 2007

2418126

Median

Mean

15141312

1st Q uartile 10.300

Median 14.300


Maximum 25.420

12.351 15.457

11.841 15.109

4.160 6.413

A -Squared 0.27

P-V alue 0.669

Mean 13.904

StDev 5.046

V ariance 25.459

Skewness 0.176600

Kurtosis 0.220309

N 43

Minimum 2.139





Summary for Mean by week - Services 2007

El error estándar de la media (SE media) es una indicación de cuan cerca la media muestral esta de la media de población cuya ecuación es σ / √ n. También podemos decir que SE media es la desviación estándar de aquellas medias muestrales tomadas desde la población. Con la distribución anterior se consigue un valor de P=0.669, que cumple con el test de normalidad, posibilitando el apropiado análisis de los datos. Empleando la herramienta six pack analisis de Minitab, se logra un gráfico integrado, con los datos estadísticos necesarios para realizar aquellos correspondientes al control de calidad. Se evidencia, con la nueva distribución, que los datos son normales, y otorgan los valores de límites -superior e inferior- de procesos y de la capacidad de este. Es preciso señalar que en este caso existe un límite físico inferior, dado que un servicio no puede resolverse en menos de cero horas. Se hace un estudio posterior de la capacidad del proceso, fijando el límite inferior como boundary; luego se realizan los cálculos del Cp (Process Capability) y del Cpk (Process Capability Index), que se relacionan con el límite superior de especificaciones (upper limit). Con esta restricción, se logra centrar el proceso y hacer que coincida el índice Cpu (Process Capability relative to upper specification limit) con el Cpk. Todos los índices mencionados permiten medir la capacidad del proceso, mientras mayores a 1 sean sus valores indican que aquel es más capaz de cumplir con las especificaciones que se le demandan. Se obtuvieron índices de Cpu y Cpk mayores a 2, lo que asegura una apropiada capacidad del proceso; además se muestra centrado con más de seis sigmas.



Gráfico 0-2 Análisis SixPack – Media semanal. Services 2007

4137332925211713951

20

10

0

In

div

idu

al V

alu

e

_X=13.90

UCL=25.02

LCL=2.79

4137332925211713951

16

8

0

Mo

vin

g R

an

ge

__MR=4.18

UCL=13.66

LCL=0

4035302520

24

16

8

Observation

Va

lue

s

672576480384288192960

LSL USL

LSL 0

USL 720

Specifications

3020100

Within

O v erall

Specs

StDev 3.7055

C p 32.38

C pk 1.25

Within

StDev 5.04573

Pp 23.78

Ppk 0.92

C pm *

O v erall

Process Capability Sixpack of Mean Resolution Time by week - Service 2007

I Chart

Moving Range Chart

Last 25 Observations

Capability Histogram

Normal Prob PlotA D: 0.268, P: 0.669

Capability Plot

Gráfico 0-3 Capacidad del proceso – Media semanal. Servicios 2007

672576480384288192960

LB Target USL

LB 0

Target 360

USL 720

Sample Mean 13.9043

Sample N 43

StDev (Within) 3.7055

StDev (O v erall) 5.04573

Process Data

C p *

C PL *

C PU 63.52

C pk 63.52

Pp *

PPL *

PPU 46.65

Ppk 46.65

C pm 0.34

O v erall C apability

Potential (Within) C apability

PPM < LB 0.00

PPM > USL 0.00

PPM Total 0.00

O bserv ed Performance

PPM < LB *

PPM > USL 0.00

PPM Total 0.00

Exp. Within Performance

PPM < LB *

PPM > USL 0.00

PPM Total 0.00

Exp. O v erall Performance

Within

Overall

Process Capability of Mean by week - Resolution Time - Service 2007




En cuanto al año 2006, los datos fueron tratados del mismo modo que aquellos correspondientes al 2007. Haciendo referencia al teorema central del límite y plantea que para un tamaño de muestra grande, la distribución de la media muestral será aproximadamente normal; se decidió realizar el análisis basado en las medias semanales -en vez de

mensuales- para aumentar el tamaño de muestra.


121110090807060504030201

200

150

100

50

0

Month

Re

so

luti

on

Tim

e (

hs)

Individual Value Plot of Resolution Time (hs) by Month - Service 2006


121110090807060504030201

200

150

100

50

0

Month

Re

so

luti

on

Tim

e (

hs)

Boxplot of Resolution Time (hs) by Month - Service 2006




1801501209060300

Median

Mean

12108642

1st Q uartile 0.516

Median 2.308


Maximum 197.988

11.214 12.355

2.154 2.447

22.931 23.738

A -Squared 999.38

P-V alue < 0.005

Mean 11.785

StDev 23.328

V ariance 544.185

Skewness 3.5115

Kurtosis 14.8936

N 6429

Minimum 0.005





Summary for Resolution Time (hs) by week - Service 2006

La resolución muestra que la distribución no es normal, y por ende deber ser transformada y corregida para normalizarla, para ello se decidió realizar el análisis basado en las medias semanales -en vez de mensuales- para aumentar el tamaño de muestra.

4.1.2.1. Normalización, datos de servicios - 2006

Se puede advertir un comportamiento similar al año 2007, es decir, al principio no se obtiene una distribución normal con medias mensuales y se decide trabajar con las medias semanales de servicios del 2006. Una vez calculadas las medias semanales de los tickets por servicio del año 2006, se aplicó un programa conveniente para su evaluación. Se obtuvo la siguiente tabla.



Tabla 4.1.2.1-1 Análisis estadístico descriptivo (RT). Servicios 2006 Descriptive Statistics: Resolution Time (hs) Variable Week (A) N N* Mean SE Mean StDev Minimum Q1


01/08/06 75 0 15.47 3.83 33.17 0.09 1.02

01/15/06 88 0 10.86 2.75 25.82 0.21 0.72

01/22/06 86 0 15.23 2.99 27.71 0.06 1.25

01/29/06 65 0 15.20 3.04 24.52 0.01 0.47

02/05/06 72 0 13.95 2.70 22.93 0.06 0.63

02/12/06 81 0 5.99 1.22 10.99 0.01 0.53

02/19/06 78 0 6.43 1.60 14.10 0.01 0.34

02/26/06 93 0 7.01 1.15 11.12 0.01 0.38

03/05/06 107 0 8.29 1.53 15.79 0.01 0.38

03/12/06 103 0 6.91 1.43 14.49 0.01 0.55

03/19/06 81 0 11.67 2.58 23.24 0.02 0.62

03/26/06 99 0 11.90 2.83 28.16 0.02 0.63

04/02/06 149 0 11.40 1.70 20.70 0.01 1.02

04/09/06 44 0 12.35 3.55 23.51 0.01 0.74

04/16/06 76 0 7.02 2.32 20.26 0.01 0.27

04/23/06 81 0 7.40 1.76 15.86 0.01 0.21

04/30/06 60 0 7.61 2.36 18.29 0.02 0.45

05/07/06 124 0 7.76 1.82 20.26 0.01 0.40

05/14/06 125 0 6.95 1.11 12.37 0.02 0.54

05/21/06 124 0 11.81 2.31 25.68 0.01 0.26

05/28/06 145 0 13.42 2.05 24.70 0.01 0.36

06/04/06 144 0 13.67 2.46 29.46 0.01 0.46

06/11/06 110 0 12.27 2.05 21.53 0.01 0.39

06/18/06 80 0 13.89 2.64 23.64 0.01 0.83

06/25/06 102 0 6.06 1.34 13.50 0.02 0.64

07/02/06 176 0 10.68 1.59 21.08 0.01 0.61

07/09/06 167 0 6.316 0.798 10.307 0.019 0.445

07/16/06 113 0 11.01 1.77 18.78 0.01 0.95

07/23/06 155 0 14.29 2.45 30.54 0.01 0.68

07/30/06 249 0 13.86 1.32 20.88 0.01 1.00

08/06/06 165 0 10.84 1.58 20.36 0.01 0.21

08/13/06 148 0 11.05 1.89 23.00 0.01 0.33

08/20/06 158 0 13.71 2.13 26.74 0.01 0.12

08/27/06 148 0 12.62 1.71 20.86 0.01 0.92

09/03/06 189 0 13.32 1.74 23.90 0.01 0.28

09/10/06 204 0 13.29 1.93 27.61 0.01 0.33

09/17/06 152 0 16.35 2.60 32.03 0.01 0.73

09/24/06 144 0 16.09 2.41 28.92 0.01 0.64

10/01/06 136 0 16.33 2.17 25.34 0.01 1.04

10/08/06 147 0 16.23 1.92 23.26 0.01 1.21

10/15/06 106 0 22.59 3.97 40.92 0.01 1.07

10/22/06 185 0 12.20 1.68 22.85 0.01 0.31

10/29/06 75 0 12.57 2.25 19.51 0.02 0.76

11/05/06 148 0 8.91 1.40 17.02 0.01 0.69

11/12/06 130 0 9.56 1.44 16.39 0.01 0.75

11/19/06 104 0 12.10 1.51 15.40 0.01 1.05

11/26/06 109 0 6.93 1.17 12.21 0.01 0.12

12/03/06 124 0 13.07 2.44 27.18 0.01 0.11

12/10/06 139 0 16.04 2.92 34.45 0.01 0.10

12/17/06 141 0 11.06 1.56 18.55 0.01 0.12

12/24/06 136 0 8.32 1.53 17.83 0.01 0.31

12/31/06 113 0 9.87 2.45 26.03 0.01 0.87



Gráfico 4.1.2.1-1 Análisis de normalidad – Media semanal. Servicios 2006

2016128

Median

Mean

13.012.512.011.511.010.5

1st Q uartile 8.305

Median 11.900


Maximum 22.590

10.625 12.551

10.858 13.092

2.933 4.323

A -Squared 0.64

P-V alue 0.091

Mean 11.588

StDev 3.494

V ariance 12.207

Skewness 0.318824

Kurtosis 0.376165

N 53

Minimum 5.990





Summary for Mean by week - Service 2006

Con la distribución anterior se consigue un valor de P=0.091, que cumple con el test de normalidad, posibilitando el apropiado análisis de los datos. Empleando la herramienta six pack análisis de Minitab, se logra un gráfico integrado, con los datos estadísticos necesarios para realizar aquellos correspondientes al control de calidad. Se evidencia, con la nueva distribución, que los datos son normales, y otorgan los valores de límites -superior e inferior- de procesos y de la capacidad de este. Es preciso señalar que en este caso existe un límite físico inferior, dado que un servicio no puede resolverse en menos de cero horas. Se hace un estudio posterior de la capacidad del proceso, fijando el límite inferior como boundary; luego se realizan los cálculos del Cp (Process Capability) y del Cpk (Process Capability Index), que se relacionan con el límite superior de especificaciones (upper limit). Con esta restricción, se logra centrar el proceso y hacer que coincida el índice Cpu (Process Capability relative to upper specification limit) con el Cpk.



Gráfico 4.1.2.1-2 Análisis SixPack – Media semanal. Servicios 2006

51464136312621161161

24

16

8

In

div

idu

al V

alu

e

_X=11.59

UCL=18.24

LCL=4.93

51464136312621161161

10

5

0

Mo

vin

g R

an

ge

__MR=2.50

UCL=8.17

LCL=0

5045403530

20

15

10

Observation

Va

lue

s

658564470376282188940

LSL USL

LSL 0

USL 720

Specifications

2015105

Within

O v erall

Specs

StDev 2.21781

C p 54.11

C pk 1.74

Within

StDev 3.4939

Pp 34.35

Ppk 1.11

C pm *

O v erall

Process Capability Sixpack of Mean by week - Service 2006

I Chart

Moving Range Chart




Capability Plot

Gráfico 4.1.2.1-3 Capacidad del proceso – Media semanal. Servicios 2006

658564470376282188940

LB USL

LB 0

Target *

USL 720

Sample Mean 11.5882

Sample N 53



Process Data

C p *

C PL *

C PU 106.47

C pk 106.47

Pp *

PPL *

PPU 67.59

Ppk 67.59

C pm *



PPM < LB 0.00

PPM > USL 0.00

PPM Total 0.00


PPM < LB *

PPM > USL 0.00

PPM Total 0.00


PPM < LB *

PPM > USL 0.00

PPM Total 0.00


Within

Overall

Process Capability of Mean by week - Service 2006



Al igual que en el año 2007, para el año 2006 los datos del proceso quedan centrados, y coinciden los índices Cpu y Cpk. Asimismo son mayores a 2, asegurando un proceso con adecuada capacidad y centrado con más de seis sigmas.


Nuevamente se aplican los criterios hasta aquí usados para los años anteriores (2007 y 2006). Obteniendo para el 2005 los resultados que se exponen en lo que siguientes gráficos en forma mensual de los servicios.


121110090807060504030201

250

200

150

100

50

0

Month

Re

so

luti

on

Tim

e (

hs)

Individual Value Plot of Resolution Time (hs) by Month - Service 2005




121110090807060504030201

250

200

150

100

50

0

Month

Re

so

luti

on

Tim

e (

hs)

Boxplot of Resolution Time (hs) by Month - Service 2005

Gráfico 4.1.3-3 Resumen de estadística Tickets (RT) por mes – Servicios 2005

24020016012080400

Median

Mean

1412108642

1st Q uartile 0.654

Median 2.224


Maximum 259.533

13.065 14.633

2.080 2.410

26.888 27.997

A -Squared 750.50

P-V alue < 0.005

Mean 13.849

StDev 27.431

V ariance 752.466

Skewness 3.4758

Kurtosis 15.4668

N 4701

Minimum 0.009




95% C onfidence Interv al for StDev

95% Confidence Intervals

Summary for Resolution Time by month -Service 2005



4.1.3.1. Normalización, datos de servicios - 2005

Tampoco en este año se encuentra una distribución normal al trabajar con medias mensuales de servicios, y se procede con la evaluación de las semanales.

Tabla 4.1.3.1-1 Análisis estadístico descriptivo (RT). Servicios 2005

Descriptive Statistics: Resolution Time (hs) Variable Week (A) N N* Mean SE Mean StDev Minimum Q1


01/09/05 90 0 10.91 2.14 20.31 0.01 0.62

01/16/05 68 0 8.51 1.57 12.98 0.03 0.87

01/23/05 86 0 19.03 2.69 24.99 0.17 1.55

01/30/05 82 0 20.25 3.49 31.61 0.01 1.92

02/06/05 133 0 17.02 2.59 29.86 0.04 2.00

02/13/05 85 0 23.00 4.16 38.31 0.03 2.08

02/20/05 90 0 26.36 4.08 38.73 0.01 0.95

02/27/05 92 0 15.53 3.37 32.35 0.09 1.47

03/06/05 94 0 13.93 3.74 36.21 0.02 1.03

03/13/05 96 0 6.63 1.32 12.94 0.08 0.83

03/20/05 44 0 9.45 2.55 16.93 0.03 0.38

03/27/05 91 0 10.82 3.04 28.97 0.03 0.53

04/03/05 118 0 13.35 1.98 21.46 0.01 0.51

04/10/05 89 0 15.08 2.98 28.09 0.01 0.50

04/17/05 110 0 12.02 2.46 25.78 0.01 0.10

04/24/05 98 0 10.71 1.84 18.21 0.01 0.74

05/01/05 107 0 21.47 2.85 29.47 0.06 1.19

05/08/05 125 0 14.83 2.31 25.81 0.02 0.88

05/15/05 79 0 8.24 2.54 22.55 0.01 0.51

05/22/05 63 0 11.15 2.56 20.29 0.01 1.13

05/29/05 105 0 8.65 1.95 19.95 0.01 0.38

06/05/05 125 0 11.67 2.04 22.76 0.01 0.24

06/12/05 115 0 14.97 2.53 27.16 0.01 0.79

06/19/05 86 0 19.29 4.22 39.16 0.01 0.44

06/26/05 75 0 21.23 4.26 36.91 0.02 0.69

07/03/05 110 0 19.75 3.36 35.21 0.02 0.64

07/10/05 100 0 8.87 1.77 17.72 0.02 0.51

07/17/05 103 0 6.27 1.45 14.73 0.02 0.34

07/24/05 78 0 5.85 1.48 13.08 0.01 0.30

07/31/05 86 0 13.79 3.76 34.87 0.01 0.52

08/07/05 79 0 9.90 1.78 15.81 0.03 0.50

08/14/05 88 0 9.34 2.97 27.82 0.02 0.49

08/21/05 128 0 15.39 3.40 38.43 0.03 1.16

08/28/05 89 0 20.18 4.17 39.32 0.01 0.15

09/04/05 57 0 11.84 3.02 22.80 0.01 0.61

09/11/05 70 0 15.88 3.55 29.67 0.01 0.51

09/18/05 83 0 10.29 2.12 19.35 0.02 0.63

09/25/05 66 0 11.29 2.33 18.95 0.01 0.57

10/02/05 61 0 10.54 2.82 22.05 0.01 0.35

10/09/05 64 0 15.22 3.53 28.25 0.02 0.29

10/16/05 110 0 12.95 2.21 23.13 0.01 0.67

10/23/05 80 0 13.59 2.56 22.87 0.01 0.78

10/30/05 77 0 7.47 2.23 19.59 0.02 0.43

11/06/05 88 0 10.75 1.88 17.65 0.02 1.13

11/13/05 106 0 16.11 2.87 29.53 0.02 0.83

11/20/05 114 0 10.25 2.20 23.48 0.01 0.28

11/27/05 102 0 19.31 3.63 36.68 0.01 0.67

12/04/05 91 0 20.81 3.26 31.14 0.01 0.93

12/11/05 77 0 16.92 4.05 35.54 0.05 0.84

12/18/05 68 0 14.35 2.21 18.21 0.01 0.63

12/25/05 86 0 8.57 2.11 19.59 0.02 0.68



Gráfico 4.1.3.1-1 Análisis de normalidad – Media semanal. Servicios 2005

252015105

Median

Mean

1514131211


Median 13.270


Maximum 26.360

12.384 15.031

11.031 15.025

3.984 5.896

A -Squared 0.61

P-V alue 0.109

Mean 13.707

StDev 4.754

V ariance 22.602

Skewness 0.533858

Kurtosis -0.310965

N 52

Minimum 5.850





Summary for Mean by week - Service 2005

Con la distribución anterior se consigue un valor de P=0.109, que cumple con el test de normalidad, posibilitando el apropiado análisis de los datos. Empleando la herramienta six pack análisis de Minitab, se logra un gráfico integrado, con los datos estadísticos necesarios para realizar aquellos correspondientes al control de calidad. Se evidencia, con la nueva distribución, que los datos son normales, y otorgan los valores de límites -superior e inferior- de procesos y de la capacidad de este. Es preciso señalar que en este caso existe un límite físico inferior, dado que un servicio no puede resolverse en menos de cero horas. Se hace un estudio posterior de la capacidad del proceso, fijando el límite inferior como boundary; luego se realizan los cálculos del Cp (Process Capability) y del Cpk (Process Capability Index), que se relacionan con el límite superior de especificaciones (upper limit). Con esta restricción, se logra centrar el proceso y hacer que coincida el índice Cpu (Process Capability relative to upper specification limit) con el Cpk.



Gráfico 4.1.3.1-2 Análisis SixPack – Media semanal. Servicios 2005

51464136312621161161

20

10

0

In

div

idu

al V

alu

e

_X=13.71

UCL=24.81

LCL=2.61

51464136312621161161

10

5

0

Mo

vin

g R

an

ge

__MR=4.17

UCL=13.64

LCL=0

5045403530

18

12

6

Observation

Va

lue

s

665570475380285190950

LSL USL

LSL 0

USL 720

Specifications

3020100

Within

O v erall

Specs

StDev 3.70011

C p 32.43

C pk 1.23

Within

StDev 4.75415

Pp 25.24

Ppk 0.96

C pm *

O v erall

Process Capability Sixpack of Mean by week - Service 2005

I Chart

Moving Range Chart




Capability Plot

Gráfico 4.1.3.1-3 Capacidad del proceso – Media semanal. Servicios 2005

665570475380285190950

LB USL

LB 0

Target *

USL 720

Sample Mean 13.7071

Sample N 52



Process Data

C p *

C PL *

C PU 63.63

C pk 63.63

Pp *

PPL *

PPU 49.52

Ppk 49.52

C pm *



PPM < LB 0.00

PPM > USL 0.00

PPM Total 0.00


PPM < LB *

PPM > USL 0.00

PPM Total 0.00


PPM < LB *

PPM > USL 0.00

PPM Total 0.00


Within

Overall

Process Capability of Mean by week - Service 2005



Luego de examinar gráficas y resultados, se pueden inferir para el año 2005 las mismas conclusiones que aquellas correspondientes a los años anteriores. Es decir, un proceso centrado, con índices Cpu y Cpk coincidentes y mayores a 2. Todo lo abarcado hasta aquí demuestra la estabilidad del proceso de resolución de tickets, a lo largo del período analizado. Posee la capacidad que amerita Six Sigma, y cumple con las especificaciones dadas.

Gráfico 4.1.3.1-4 Niveles de Sigma vs. DPMO con 1.5 σ cambio

El término Six Sigma tiene dos significados: a) En términos operacionales, este significa 3.4 defectos por millón de oportunidades (DPMO) o un proceso con índice de capacidad (Cp) igual a 2. Donde Cp es definido como: Cp = (USL – LSL)/6σ Entonces para un proceso de Six Sigma tenemos que Cp = 2 b) En términos gerenciales, este significa tener un programa de mejora continua que involucre todos los aspectos del negocio, involucrando cada producto importante y proceso de defectos. También estar enfocados a programas de procesos con análisis de causa raíz.

En la figura siguiente muestra a un proceso con distribución normal, operando dentro de 1.5 Sigma (σ) de su media (μ). Six Sigma implica que la ocurrencia de que cualquier valor o atributo caiga dentro del límite menor de especificación (LSL) y limite superior de especificación (USL) y que no tenga más de 3.4 partes por millón de oportunidades.



Gráfico 4.1.3.1-5 Niveles de Sigma vs. LSL / USL (DPMO)

Para un proceso no centrado tenemos: Lower Cp = Cpl = (μ – LSL)/3σ Upper Cp = Cpu = (USL – μ)/3σ Average Cp = Cpk = Min [Cpl⋅Cpk] Six Sigma supone en su metodología que los procesos siempre operan dentro de ±1.5σ de su media. Asumiendo esta desviación como el peor caso tenemos: Cpk = (6σ – 1.5σ)/3σ = 1.5 El coeficiente Cpk es preferido sobre Cp dado que en los procesos generalmente no operan a su valor de media, entonces Cpk = 1.5 es generalmente aceptado como requerimiento de Six Sigma.



4.1.4. Análisis de variabilidad de servicios – 2005 a 2007

Para tener una visión global del período abordado y ver si existen diferencias significativas entre sus medias respectivas, en relación a la resolución de tickets por servicios, se llevará a cabo un test ANOVA (análisis de varianza).

En la tabla siguiente se presenta el análisis ANOVA mencionado, pudiendo concluir a través de este, que en los años 2005 y 2007 no existen tales diferencias, pero sí ocurre en el 2006, aunque no es demasiado relevante. Se han representado las diferentes pruebas de acuerdo a valores discretos o continuos y al tipo de comparación.

Gráfico 4.1.4-1 Test de análisis – Modelos continuos y discretos



4.1.4.1. Variabilidad - ANAVA – 2005 a 2007

Se ha optado por la aplicación del test ANAVA (análisis de varianza paramétricos de datos - One Way ANOVA) por ser el recomendado para medias y variables continuas, y cuando se tienen más de dos muestras. Estos son los componentes de una tabla ANOVA: Fuente (Source): indica la fuente de variación, ya sea por el factor, la interacción, o el error. El total es la suma de todas las fuentes:

Modelo (Model): Esta es la fuente que se denomina tratamientos (treatments), representa la variación entre las medias muestrales. En Minitab se la llama factor. Error (Error): Esta fuente mide la variación dentro de las muestras. Total Corregido (Corrected Total): Esta fuente mide la variación de todos los valores x respecto a la media general del todos los n.

DF (Degree of freedom): Son los grados de libertad de cada fuente. Si un factor tiene tres niveles, los grados de libertad son de 2 (n-1). Si usted tiene un total de 30 observaciones, los grados de libertad total son 29 (n - 1). SS (Sum of squares): Es la suma de los cuadrados de las desviaciones, correspondientes a las tres fuentes de variación (factor, error y total corregido).

MS (Mean square): Es el cuadrado medio, da las estimaciones para σ2, basadas en la

variación entre las medias muestrales y en la variación dentro de las muestras cuando es verdadera la H0. Se calculan estas estimaciones dividiendo la suma de cuadrados entre los grados de libertad correspondientes. MST es cuadrado medio de tratamientos y MSE que es cuadrado medio del error.

Distribución F: Se calcula dividiendo el cuadrado medio de tratamiento (MST) por el cuadrado medio del error (MSE), se puede comparar este ratio contra la F crítica en tabla o se puede usar el p-value (α) para determinar si un factor es significativo. La distribución F está en función de α, grados de libertad del modelo (ν1) y grados de libertad del error (v2), entrando por tablas nos dará el valor de calculado de F. Si es mayor al valor F(α) crítico, F=(MST/MSE) para el cual se rechazara la H0. P: Se usa para determinar si un factor es significativo; típicamente se compara contra un valor alfa de 0,05. Si el p-valor es inferior a 0,05, entonces el factor es significativo. Se usa para decidir de rechazar o aceptar la H0. Si el valor calculado de p-value de un test estadístico es menor a 0,05, entonces rechazamos la H0. R-sq (Coefficient of determination): Indica cuanto la variación en la respuesta es explicada por el modelo. A mayor R2 (R-sq) mejor se ajusta el modelo a los datos.



R-sq (adj): Cuenta el número de predicciones en el modelo y es útil para comparar modelos con diferentes números de predicciones. Como hipótesis nula, Ho, se postula que “no existen diferencias significativas en las medias entre años 2005 y 2007”. La hipótesis alternativa, Ha, será por lo tanto, que “existen diferencias significativas en las medias por año”. La regla del pulgar indica rechazar la Ho si el valor de p es menor a 0.05. Esto implica que se asume un error del 5% al rechazarla, siendo la Ha verdadera (conocido como

Error Type I o Alfa Risk). Los datos fuente son: Services 2005, Mean by week P = 0.109 Cpu = 49.52 Cpk = 49.52 Services 2006, Mean by week P = 0.091 Cpu = 67.59 Cpk = 67.59 Services 2007, Mean by week P = 0.669 Cpu = 44.69 Cpk = 44.69 Se resalta que los índices Cpu y Cpk en el 2006 fueron mejores que en los otros dos años; aunque estos valores no indican la significatividad de tal diferencia, para ello se utiliza el test ANOVA, que permite averiguarlo.

Tabla 4.1.4.1-1 ANOVA – Media de Servicios vs. Año 2005 al 2007

One-way ANOVA: Mean versus Year 2005 to 2007 Source DF SS MS F P

Year 2 166.8 83.4 4.23 0.016

Error 145 2856.8 19.7

Total 147 3023.6

S = 4.439 R-Sq = 5.52% R-Sq(adj) = 4.21%

El valor P = 0.016 (menor a 0.05) demuestra la existencia de diferencias

significativas.



Individual 95% CIs For Mean Based on Pooled StDev

Level N Mean StDev -+---------+---------+---------+--------

2005 52 13.707 4.754 (-------*-------)

2006 53 11.588 3.494 (-------*-------)

2007 43 13.904 5.046 (--------*--------)

-+---------+---------+---------+--------

10.5 12.0 13.5 15.0

Pooled StDev = 4.439

Tukey 95% Simultaneous Confidence Intervals

All Pairwise Comparisons among Levels of Year

Individual confidence level = 98.08%

Year = 2005 subtracted from:

Year Lower Center Upper --------+---------+---------+---------+-

2006 -4.171 -2.119 -0.067 (--------*-------)

2007 -1.970 0.197 2.364 (--------*-------)

--------+---------+---------+---------+-

-2.5 0.0 2.5 5.0


Year Lower Center Upper --------+---------+---------+---------+-

2007 0.158 2.316 4.474 (-------*--------)

--------+---------+---------+---------+-

-2.5 0.0 2.5 5.



Gráfico 4.1.4.1-1 Grafico de cajas de medias de Servicios 2005 al 2007 - ANOVA

200720062005

25

20

15

10

5

0

Year

Me

an 13.9043

11.5882

13.7071

Boxplot of Mean - Services 2005 to 2007

A continuación veremos un ejemplo de Análisis de residuos ANOVA, gráficas ofrecidas por Minitab y su interpretación. Utilice para examinar las bondades del ajuste del modelo en regresión y en ANOVA. Examinar las gráficas de residuos le ayuda a determinar si los supuestos de los cuadrados mínimos ordinarios coinciden. Si estos supuestos cumplen con lo requerido, entonces la regresión de cuadrados mínimos ordinarios producirá estimaciones de coeficientes sin sesgo con la varianza mínima. Histograma de residuos: Una herramienta exploratoria para mostrar las características generales de los residuos incluyendo valores típicos, dispersión y forma. Una larga cola lateral puede indicar una distribución sesgada. Si una o dos barras están lejos de las demás, esos puntos pueden ser valores atípicos. Gráfica de probabilidad normal de residuos: Los puntos de esta gráfica deben generalmente formar una línea recta si los residuos están normalmente distribuidos. Si los puntos en la gráfica salen de una línea recta, el supuesto de normalidad puede ser inválido. Residuos versus valores ajustados: Esta gráfica deberá mostrar un patrón aleatorio de residuos a ambos lados de 0. Si un punto se encuentra lejos de la mayoría de los puntos, puede ser un valor atípico. No deberá haber algún patrón reconocible en la gráfica de residuos. Por ejemplo, si la dispersión de valores de residuos tiende a



incrementarse a medida que se incrementan los valores ajustados, entonces esto puede violar el supuesto de varianza constante. Residuos versus orden de datos: Esta es una gráfica de todos los residuos en el orden en el que se colectaron los datos y puede utilizarse para hallar errores no aleatorios, especialmente de efectos relacionados con el tiempo. Esta gráfica le ayuda a revisar el supuesto que establece que los residuos no se correlacionan unos a otros. Residuos versus predictores: Esta es una gráfica de los residuos versus un predictor. Esta gráfica deberá mostrar un patrón aleatorio de residuos a ambos lados de 0. Los patrones no aleatorios, tales como el ejemplo de la derecha, pueden violar el supuesto que establece que las variables predictoras no se relacionan con los residuos. Pudo haber utilizado una forma funcional incorrecta para modelar la curvatura.

Gráfico 4.1.4.1-2 Gráficos de Residuos de medias de Servicios 2005 al 2007 - ANOVA

100-10

99.9

99

90

50

10

1

0.1

Residual

Pe

rce

nt

141312

10

5

0

-5

-10

Fitted Value

Re

sid

ua

l

12840-4-8-12

30

20

10

0

Residual

Fre

qu

en

cy

140

130

120

110

1009080706050403020101

10

5

0

-5

-10

Observation Order

Re

sid

ua

l

Normal Probability Plot Versus Fits

Histogram Versus Order

Residual Plots for Mean - Services 2005 to 2007

El intervalo de confianza para las diferencias entre medias de los años 2005 y 2007, con respecto al 2006, es significante. Esto se deduce por dos hechos: el intervalo en el análisis individual no incluye el cero y el valor de p = 0.016 en el análisis general. En base a todo lo anterior corresponde rechazar la hipótesis nula Ho.

Por otro lado vemos en el análisis de los gráficos de los residuos que la normalidad de los mismos, el histograma muestra que tienen una distribución normal, que los residuos versus los valores ajustados están proporcionalmente distribuidos del cero y que las observaciones son aleatorias en el tiempo.



4.1.4.2. Variabilidad - ANAVA – 2005 y 2007

En esta sección se realiza un análisis de los años 2005 y 2007 solamente, donde se plantea:

Ho: no existen diferencias significativas entre los años 2005 y 2007. Ha: existen diferencias significativas entre los años 2005 y 2007.

Tabla 4.1.4.2-1 ANOVA – Media de Servicios vs. Año 2005 y 2007

One-way ANOVA: Mean versus Year 2005 & 2007 Source DF SS MS F P

Year 1 0.9 0.9 0.04 0.845

Error 93 2222.0 23.9

Total 94 2222.9

S = 4.888 R-Sq = 0.04% R-Sq(adj) = 0.00%

El valor P = 0.845 demuestra la Ho, no existen diferencias significativas

entre el 2005 y 2007.

Individual 95% CIs For Mean Based on

Pooled StDev

Level N Mean StDev -----+---------+---------+---------+----

2005 52 13.707 4.754 (---------------*----------------)

2007 43 13.904 5.046 (------------------*-----------------)

-----+---------+---------+---------+----

12.80 13.60 14.40 15.20






Year Lower Center Upper -------+---------+---------+---------+--

2007 -1.804 0.197 2.198 (----------------*---------------)

-------+---------+---------+---------+--

-1.2 0.0 1.2 2.4



Gráfico 4.1.4.2-1 Grafico de cajas de medias de Servicios 2005 y 2007 - ANOVA

20072005

25

20

15

10

5

0

Year

Me

an 13.904313.7071

Boxplot of Mean 2005 & 2007

El intervalo de confianza para las diferencias entre medias de los años 2005 y 2007 no es significativo, debido a que el intervalo en el análisis individual incluye el cero y el valor de p es 0.845 (mayor a 0.05). Con esto se acepta la hipótesis nula, es decir, no existen diferencias significativas entre las medias del 2005 y 2007.

Adicionalmente se realizó el diagrama del comportamiento de los residuos, en el que se puede ver una distribución normal y que las secuencias de observación son aceptables.

Gráfico 4.1.4.2-2 Gráficos de Residuos de medias de Servicios 2005 y 2007 - ANOVA

100-10

99.9

99

90

50

10

1

0.1

Residual

Pe

rce

nt

13.9013.8513.8013.7513.70

10

5

0

-5

-10

Fitted Value

Re

sid

ua

l

1050-5-10

20

15

10

5

0

Residual

Fre

qu

en

cy

9080706050403020101

10

5

0

-5

-10

Observation Order

Re

sid

ua

l



Residual Plots for Mean 2005 & 2007

4.1.5. Análisis del tiempo de resolución de problemas - 2007



En esta sección, a diferencia de la anterior, se tratarán los tickets de problemas, en vez de los de servicio. También aquí, la variable para su estudio será el tiempo de resolución de los tickets correspondientes. El período abarcado es, nuevamente, desde el año 2005 al 2007. Se reitera la utilización del programa estadístico Minitab para análisis de los datos y obtención de gráficos.

Gráfico 4.1.5-1 Valores individuales (RT) – Problemas 2007

100806040200

Resolution Time (hs)

Individual Value Plot of Resolution Time (hs) - problems 2007

Gráfico 4.1.5-2 Gráfico de Cajas de Tickets (RT) – Problemas 2007

100

80

60

40

20

0

Re

so

luti

on

Tim

e (

hs)

Boxplot of Resolution Time (hs) - problems 2007




100806040200

Median

Mean

302520151050

1st Q uartile 0.614

Median 1.728


Maximum 99.040

8.312 31.800

0.923 24.213

23.380 40.686

A -Squared 3.13

P-V alue < 0.005

Mean 20.056

StDev 29.688

V ariance 881.387

Skewness 1.61790

Kurtosis 1.75041

N 27

Minimum 0.059






La resolución muestra que la distribución no es normal y debido a la baja cantidad de datos o tickets de problemas durante el año se propone tratarla como distribuciones no normales analizado las diferentes alternativas a saber.

4.1.5.1. Tratamiento de distribuciones no normales

En referencia al tratamiento de curvas cuyos datos empíricos presentan distribuciones no normales, Ramos Wunderler71 propone una posibilidad para su resolución. Plantea que, luego de ajustar la curva, se puede calcular un porcentaje de ítems encima del máximo o debajo del mínimo de especificaciones y transformar los mismos en equivalentes. Un método para realizar este ajuste es el sistema de Johnson (1949). Este presenta algunas ventajas, conforme FARNUM (1997) en relación a otras formas desarrolladas (como la de Pearson):

El sistema de curvas de transformadas de Johnson cubren una vasta gama de diferentes formas de distribuciones, mayor que las disponibles en otros sistemas, siendo por lo tanto más flexible.

71

Ramos Wunderler, Alberto. “Estudos de capacidade para dados ñao-normais”. [en línea]. Disponible en Internet http://www.pro.poli.usp.br/internacional/faculty/alberto-wunderler-ramos [Consulta: 2 de Febrero del 2008]

http://www.pro.poli.usp.br/internacional/faculty/alberto-wunderler-ramos



El mecanismo para la selección de la familia de curvas más adecuada a los datos es más simple que con el resto de los casos, especialmente considerando que utiliza porcentajes.

Este sistema permite, como probabilidades, calcular distintos ítems (sobre las curvas ajustadas) a partir del uso de tablas sencillas de distribución normal, mediante transformaciones adecuadas a las funciones.

El sistema de Johnson se encuentra disponible en diversos softwares estadísticos de mercado.

4.1.5.2. Transformadas de Johnson

El sistema de curvas de Johnson está básicamente constituido para tres diferentes familias de distribuciones, generadas a partir de transformaciones de la siguiente forma genérica:

Donde z la variable normal o reducida depende de yqueson parámetros

específicos para cada familia.

Siendo z es el valor de la transformada, X es la variable a ser transformada, es el

parámetro de la forma 1, es el parámetro de la forma 2, es parámetro de locación y

es un parámetro escalar. En función del tipo de familia seleccionada para el ajuste, Johnson propone diferentes tipos de funciones:

Familia SU, o no limitada (unbounded); cuando la variable no posee un valor mínimo o máximo, pudiendo variar libremente entre menos infinito y más infinito.

En esta situación la función propuesta es del tipo:

Familia SB, o limitada (bounded); para aquellas distribuciones en que la variable

asume valores entre (



Familia SL, con logaritmo normal o neperiano. En esta situación la función propuesta es del tipo:

En resumen:

Nicolas R. Farnum (1996-97) ha dado una detallada descripción en el uso de las curvas de Johnson. El sistema de Johnson usa tres transformadas para normalizar datos descriptas en arriba.

4.1.5.3. Transformadas seleccionadas para el análisis

En este caso la transformada de Johnson sugerida por Minitab es la del tipo SB,

limitada, válida en el intervalo (Los valores límites del proceso y de especificaciones serán iguales, los que dará como resultado un Cpu y Cpk mucho menores a los reales. Por otro lado, no se pudo encontrar una forma de introducir los límites de especificaciones, dado que no existe una transformada válida para el rango, siendo este mayor a los límites del proceso.

También se han realizado los cálculos con la transformada de Box-Cox con sugerida por un Black Belt de la compañía en una primera instancia. Por lo tanto se graficaron y estimaron con ambos métodos los ticket clasificados como problemas desde el 2005 al 2007. De acuerdo al punto de vista propio, es más acertada la elección del método de Johnson, o en su defecto el de Weibull, por ser estos más representativos.



4.1.5.4. Normalización, datos de problemas - 2007

Por el mismo argumento de la sección anterior, aquí también se toma como límite inferior fijo el cero, por ser imposible resolver un problema en un tiempo menor. Siendo esto coincidente, la comparación del tiempo de resolución de servicios y problemas se enfoca en el límite superior (upper limit). De acuerdo a lo mencionado anteriormente, tratando de elegir a través del test de bondad de ajuste que mejor se adecue vemos que las transformadas para este análisis estadístico que surgen con las cuales se realizaron tres corridas diferentes: Box-Cox, Johnson y Weibull. En lo que continúa se exhiben los resultados a los que se arribó, en forma gráfica.

Gráfico 4.1.5.4-1 Box-Cox aplicada al tiempo de resolución de problemas 2007

1.51.00.50.0-0.5-1.0

45

40

35

30

25

20

15

10

Lambda

StD

ev

Lower CL Upper CL

Limit

Estimate -0.02

Lower CL -0.23

Upper CL 0.18

Rounded Value 0.00

(using 95.0% confidence)

Lambda

Box-Cox Plot of Resolution Time (hs) - problems 2007



Gráfico 4.1.5.4-2 Análisis SixPack Box-Cox – Media de Problemas 2007

252219161310741

5

0

-5

In

div

idu

al V

alu

e

_X=1.32

UCL=7.26

LCL=-4.62

252219161310741

8

4

0

Mo

vin

g R

an

ge

__MR=2.234

UCL=7.298

LCL=0

252015105

3

0

-3

Observation

Va

lue

s

6420-2-4-6

LSL* USL*

LSL* -6.90776

USL* 6.22258

Specifications

50-5

Within

O v erall

Specs

StDev 1.98022

Cp 1.11

Cpk 0.83

Within

StDev 2.18077

Pp 1

Ppk 0.75

Cpm *

Overall

Process Capability Sixpack of Resolution Time (hs) - service 2007Using Box-Cox Transformation With Lambda = 0

I Chart

Moving Range Chart



Normal Prob Plot

AD: 0.944, P: 0.014

T ransformed Capa Plot

Gráfico 4.1.5.4-3 Capacidad del proceso Box-Cox – Problemas 2007

6420-2-4-6

transformed data

LB* USL*

USL* 6.29157

Sample Mean* 1.31761

StDev (Within)* 1.98022

StDev (O v erall)* 2.18077

LB 0.001

Target *

USL 540

Sample Mean 20.0561

Sample N 27



LB* -6.90776

Target* *

A fter Transformation

Process Data

C p *

C PL *

C PU 0.84

C pk 0.84

Pp *

PPL *

PPU 0.76

Ppk 0.76

C pm *



PPM < LB 0.00

PPM > USL 0.00

PPM Total 0.00


PPM < LB* *

PPM > USL* 6005.46

PPM Total 6005.46


PPM < LB* *

PPM > USL* 11279.31

PPM Total 11279.31


Within

O v erall

Process Capability of Resolution Time (hs) - problems 2007Using Box-Cox Transformation With Lambda = 0



Se advierte que aplicando Box-Cox, para el análisis de problemas del año 2007, se llega a un P=0.014, valor que indica que la transformada no es normal.

Independientemente se hizo un análisis de capacidad y estabilidad en el tiempo, los resultados muestran un valor de CpK=0.84 y PpK=0.76, denotando que el proceso no está cumpliendo con las especificaciones dadas. Cabe destacar que al no estar normalizados los datos, estos dos últimos análisis no están soportados por la teoría estadística.

Gráfico 4.1.5.4-4 Johnson aplicada al tiempo de resolución de problemas 2007

100500-50

99

90

50

10

1

Pe

rce

nt

N 27

AD 3.132

P-Value <0.005

420-2

99

90

50

10

1

Pe

rce

nt

N 27

AD 0.607

P-Value 0.103

1.21.00.80.60.40.2

0.100

0.075

0.050

0.025

0.000

Z Value

P-V

alu

e f

or A

D t

est

0.68

Ref P

P-V alue for Best F it: 0.103221

Z for Best F it: 0.68

Best Transformation Ty pe: SB

Transformation function equals

1.09172 + 0.344979 * Ln( ( X - 0.0564232 ) / ( 105.153 - X ) )

Probability Plot for Original Data

Probability Plot for T ransformed Data

Select a T ransformation

(P-Value = 0.005 means <= 0.005)

Johnson Transformation for Resolution Time (hs) - Problems 2007

Gráfico 4.1.5.4-5 Probabilidad de Johnson (RT) de Problemas 2007

3210-1-2-3

99

95

90

80

70

60

50

40

30

20

10

5

1

Johnson

Pe

rce

nt

Mean 0.005749

StDev 1.035

N 27

AD 0.607

P-Value 0.103

Probability Plot of Johnson - Problems 2007Normal



Gráfico 4.1.5.4-6 Análisis SixPack Johnson – Media de Problemas 2007

252219161310741

2

0

-2

In

div

idu

al V

alu

e

_X=0.006

UCL=2.843

LCL=-2.832

252219161310741

4

2

0

Mo

vin

g R

an

ge

__MR=1.067

UCL=3.486

LCL=0

252015105

2

0

-2

Observation

Va

lue

s

3210-1-2

LSL USL

LSL -2.45

USL 3.34

Specifications

420-2

Within

O v erall

Specs

StDev 0.945916

C p 1.02

C pk 0.87

Within

StDev 1.03547

Pp 0.93

Ppk 0.79

C pm *

O v erall

2

Process Capability Sixpack of Johnson - Problems 2007

I Chart

Moving Range Chart




Capability Plot

Gráfico 4.1.5.4-7 Capacidad del proceso Johnson – Problemas 2007

43210-1-2

transformed data

USL*

Scale 105.097

LB* *

Target* *

USL* 4.69944


StDev * 1.03547

LB 0

Target *

USL 105.15

Sample Mean 20.0561

Sample N 27

StDev 29.6882

Shape1 1.09172

Shape2 0.344979

Location 0.0564232


Process Data

Pp *

PPL *

PPU 1.51

Ppk 1.51


PPM < LB 0.00

PPM > USL 0.00

PPM Total 0.00


PPM < LB *

PPM > USL 2.91

PPM Total 2.91


Process Capability of Resolution Time (hs) - Problems 2007Johnson Transformation with SB Distribution Type

1.092 + 0.345 * Ln( ( X - 0.056 ) / ( 105.153 - X ) )



Para el año 2007 se utiliza la transformada de Johnson sugerida por Minitab es la del tipo

SB, limitada, válida en el intervalo (El método de Johnson para este análisis arroja un P=0.103, que señala que la transformada es

normal. Por su parte, un análisis de capacidad y estabilidad en el tiempo, lleva a un valor de PpK=1.51, lo cual sugiere que el proceso cumple con las especificaciones dadas. La inferencia anterior también es soportada al aplicar Weibull, ya que se obtiene un valor de PpK= 1.20.

Gráfico 4.1.5.4-8 Capacidad del proceso Weibull – Problemas 2007

490420350280210140700

LB USL

LB 0

Target *

USL 504

Sample Mean 20.0561

Sample N 27

Shape 0.51674

Scale 10.9171

Process Data

Pp *

PPL *

PPU 1.20

Ppk 1.20


PPM < LB 0.00

PPM > USL 0.00

PPM Total 0.00


PPM < LB *

PPM > USL 713.93

PPM Total 713.93


Process Capability of Resolution Time (hs) - Problems 2007Calculations Based on Weibull Distribution Model


Para el tratamiento de datos del año 2006 también se realizo el test de bondad de ajuste y surgieron tres posibles ajustes diferentes (Box-Cox, Johnson y Weibull), las cuales fueron consideradas como más apropiadas para el tipo de información que se maneja. Arrojando los resultados que se reúnen a continuación.



Gráfico 4.1.5.5-1 Valores individuales (RT) – Problemas 2006

80706050403020100

Resolution Time (hs)

Individual Value Plot of Resolution Time (hs) - problems 2006

Gráfico 4.1.5.5-2 Gráfico de Cajas de Tickets (RT) – Problemas 2006

80

70

60

50

40

30

20

10

0

Re

so

luti

on

Tim

e (

hs)

Boxplot of Resolution Time (hs) - problems 2006



Gráfico 4.1.5.5-3 Resumen de estadística Tickets (RT) – Problemas 2006

644832160

Median

Mean

2520151050

1st Q uartile 1.538

Median 5.414


Maximum 71.791

13.173 23.994

2.872 20.615

19.621 27.391

A -Squared 6.63

P-V alue < 0.005

Mean 18.584

StDev 22.860

V ariance 522.587

Skewness 1.08048

Kurtosis -0.22835

N 71

Minimum 0.026





Summary for Resolution Time (hs) - problems 2006


1.51.00.50.0-0.5-1.0

140

120

100

80

60

40

20

0

Lambda

StD

ev

Lower CL Upper CL

Limit

Estimate 0.07

Lower CL -0.07

Upper CL 0.21

Rounded Value 0.00


Lambda

Box-Cox Plot of Resolution Time (hs) - Problems 2006




71645750433629221581

5

0

-5

In

div

idu

al V

alu

e

_X=1.66

UCL=7.41

LCL=-4.09

71645750433629221581

8

4

0

Mo

vin

g R

an

ge

__MR=2.162

UCL=7.065

LCL=0

7065605550

4

0

-4

Observation

Va

lue

s

4.82.40.0-2.4-4.8

LSL* USL*

LSL* -6.90776

USL* 6.22258

Specifications

1050-5

Within

O v erall

Specs

StDev 1.91685

Cp 1.14

Cpk 0.79

Within

StDev 1.9722

Pp 1.11

Ppk 0.77

Cpm *

Overall

11

2

Process Capability Sixpack of Resolution Time (hs) - problems 2006Using Box-Cox Transformation With Lambda = 0

I Chart

Moving Range Chart



Normal Prob Plot

AD: 1.246, P: < 0.005



4.82.40.0-2.4-4.8

transformed data

LB* USL*

USL* 6.22258




LB 0.001

Target *

USL 504

Sample Mean 18.5835

Sample N 71



LB* -6.90776

Target* *


Process Data

C p *

C PL *

C PU 0.79

C pk 0.79

Pp *

PPL *

PPU 0.77

Ppk 0.77

C pm *



PPM < LB 0.00

PPM > USL 0.00

PPM Total 0.00


PPM < LB* *

PPM > USL* 8606.24

PPM Total 8606.24


PPM < LB* *

PPM > USL* 10298.60

PPM Total 10298.60


Within

O v erall

Process Capability of Resolution Time (hs) problems 2006Using Box-Cox Transformation With Lambda = 0



Aplicando Box-Cox, para el análisis de problemas del año 2006, se obtiene un P<0.005, valor que indica que la transformada no es normal. Independientemente se hizo un análisis de capacidad y estabilidad en el tiempo, los resultados muestran un valor de CpK=0.79 y PpK=0.77, que revelan que el proceso no está cumpliendo con las especificaciones dadas. Se reitera que al no estar normalizados los datos, estos dos últimos análisis no están soportados por la teoría estadística.


100500-50

99.9

99

90

50

10

1

0.1

Pe

rce

nt

N 71

AD 6.629

P-Value <0.005

40-4

99.9

99

90

50

10

1

0.1

Pe

rce

nt

N 71

AD 0.602

P-Value 0.114

1.21.00.80.60.40.2

0.100

0.075

0.050

0.025

0.000

Z Value

P-V

alu

e f

or A

D t

est

0.65

Ref P





0.839892 + 0.385744 * Ln( ( X - 0.0245399 ) / ( 74.7388 - X ) )




(P-Value = 0.005 means <= 0.005)

Johnson Transformation for Resolution Time (hs) - problems 2006


43210-1-2-3-4

99.9

99

95

90

80

7060504030

20

10

5

1

0.1

Johnson

Pe

rce

nt

Mean -0.03692

StDev 1.057

N 71

AD 0.602

P-Value 0.114

Probability Plot of Johnson - Problems 2006Normal




71645750433629221581

2

0

-2

Indiv

idual V

alu

e

_X=-0.037

UCL=3.028

LCL=-3.102

71645750433629221581

4

2

0

Movin

g R

ange

__MR=1.152

UCL=3.765

LCL=0

7065605550

2

0

-2

Observation

Valu

es

210-1-2-3

Specifications

40-4

Overall

Specs

Location -0.0369202

Scale 1.05746

Pp *

Ppk *

Overall

Process Capability Sixpack of Resolution Time (hs) - problems 2006Johnson Transformation with SB Distribution Type

0.840 + 0.386 * Ln( ( X - 0.025 ) / ( 74.739 - X ) )

I Chart

Moving Range Chart



Normal Prob Plot

AD: 0.602, P: 0.114



4.53.01.50.0-1.5-3.0

transformed data

USL*

Scale 74.7142

LB* *

Target* *

USL* 5.27113

Sample Mean* -0.0369202

StDev * 1.05746

LB 0

Target *

USL 74.738

Sample Mean 18.5835

Sample N 71

StDev 22.8602

Shape1 0.839892

Shape2 0.385744

Location 0.0245399


Process Data

Pp *

PPL *

PPU 1.67

Ppk 1.67


PPM < LB 0.00

PPM > USL 0.00

PPM Total 0.00


PPM < LB *

PPM > USL 0.26

PPM Total 0.26



0.840 + 0.386 * Ln( ( X - 0.025 ) / ( 74.739 - X ) )



En el añ0 2006 la transformada de Johnson sugerida por Minitab es la del tipo SB, limitada,

válida en el intervalo (Al emplear el método de Johnson para este análisis, se obtiene un P=0.114, que señala una

transformada normal. Por otra parte, un análisis de capacidad y estabilidad en el tiempo, entrega un valor de PpK=1.67, lo cual sugiere que el proceso cumple con las especificaciones dadas.

La inferencia anterior también es soportada al aplicar Weibull, ya que se obtiene un valor de PpK= 1.85.


504432360288216144720

LB USL

LB 0

Target *

USL 504

Sample Mean 18.5835

Sample N 71

Shape 0.6228

Scale 13.3101

Process Data

Pp *

PPL *

PPU 1.85

Ppk 1.85


PPM < LB 0.00

PPM > USL 0.00

PPM Total 0.00


PPM < LB *

PPM > USL 66.74

PPM Total 66.74




Al igual que para el resto de los años, en el 2005 también se emplean los métodos estadísticos: Box-Cox, Johnson y Weibull. En las gráficas se resumen los resultados de ellos.



Gráfico 4.1.5.6-1 Valores individuales (RT) – Problemas 2005

140

120

100

80

60

40

20

0

Re

so

luti

on

Tim

e (

hs)


Gráfico 4.1.5.6-2 Gráfico de Cajas de Tickets (RT) – Problemas 2005

140

120

100

80

60

40

20

0

Re

so

luti

on

Tim

e (

hs)




Gráfico 4.1.5.6-3 Resumen de estadística Tickets (RT) – Problemas 2005

120100806040200

Median

Mean

302520151050

1st Q uartile 0.646

Median 4.315


Maximum 123.203

15.213 30.198

2.244 14.373

30.184 40.916

A -Squared 11.22

P-V alue < 0.005

Mean 22.706

StDev 34.735

V ariance 1206.552

Skewness 1.72738

Kurtosis 1.70031

N 85

Minimum 0.029







1.51.00.50.0-0.5-1.0

90

80

70

60

50

40

30

20

10

0

Lambda

StD

ev

Lower CL Upper CL

Limit

Estimate 0.02

Lower CL -0.08

Upper CL 0.15

Rounded Value 0.00


Lambda

Box-Cox Plot of Resolution Time (hs) - Problems 2005




81736557494133251791

5

0

-5In

div

idu

al V

alu

e

_X=1.42

UCL=7.70

LCL=-4.86

81736557494133251791

8

4

0

Mo

vin

g R

an

ge

__MR=2.362

UCL=7.717

LCL=0

8580757065

4

0

-4

Observation

Va

lue

s

6420-2-4-6

LSL* USL*

LSL* -6.90776

USL* 6.22258

Specifications

1050-5

Within

O v erall

Specs

StDev 2.09387

Cp 1.05

Cpk 0.76

Within

StDev 2.28326

Pp 0.96

Ppk 0.7

Cpm *

Overall

22

2

22

2

22

222

Process Capability Sixpack of Resolution Time (hs) - Problems 2005Using Box-Cox Transformation With Lambda = 0

I Chart

Moving Range Chart



Normal Prob Plot

AD: 1.009, P: 0.011



6420-2-4-6

transformed data

LSL* USL*

USL* 6.22258




LSL 0.001

Target *

USL 504

Sample Mean 22.7058

Sample N 85



LSL* -6.90776

Target* *


Process Data

C p 1.05

C PL 1.33

C PU 0.76

C pk 0.76

Pp 0.96

PPL 1.22

PPU 0.70

Ppk 0.70

C pm *



PPM < LSL 0.00

PPM > USL 0.00

PPM Total 0.00


PPM < LSL* 34.63

PPM > USL* 10951.92

PPM Total 10986.56


PPM < LSL* 131.74

PPM > USL* 17780.24

PPM Total 17911.98


Within

O v erall

Process Capability of Resolution Time (hs) - Problems 2005Using Box-Cox Transformation With Lambda = 0



Con Box-Cox se obtuvo P=0.011, es decir, una transformada no normal. Los análisis de capacidad y estabilidad en el tiempo, arrojaron CpK=0.76 y PpK=0.70, por lo tanto el proceso

no estaría cumpliendo con las especificaciones dadas. Nuevamente, al no estar normalizados los datos, estos dos últimos análisis no tienen soporte estadístico.


1000-100

99.9

99

90

50

10

1

0.1

Pe

rce

nt

N 85

AD 11.223

P-Value <0.005

40-4

99.9

99

90

50

10

1

0.1

Pe

rce

nt

N 85

AD 0.292

P-Value 0.599

1.21.00.80.60.40.2

0.60

0.45

0.30

0.15

0.00

Z Value

P-V

alu

e f

or A

D t

est

0.76

Ref P





1.26541 + 0.366073 * Ln( ( X - 0.0272102 ) / ( 127.493 - X ) )




(P-Value = 0.005 means <= 0.005)

Johnson Transformation for Resolution Time (hs) - Problems 2005


43210-1-2-3-4

99.9

99

95

90

80

7060504030

20

10

5

1

0.1

Johnson

Pe

rce

nt

Mean 0.09454

StDev 1.069

N 85

AD 0.292

P-Value 0.599

Probability Plot of JohnsonNormal




81736557494133251791

2

0

-2Indiv

idual V

alu

e

_X=0.095

UCL=3.002

LCL=-2.813

81736557494133251791

4

2

0

Movin

g R

ange

__MR=1.093

UCL=3.571

LCL=0

8580757065

2

0

-2

Observation

Valu

es

3210-1-2-3

LSL* USL*

LSL* -3.12436

USL* 3.29736

Specifications

40-4

Overall

Specs

Location 0.0945409

Scale 1.06949

Pp 1.00

Ppk 1.00

Overall

Process Capability Sixpack of Resolution Time (hs) - Problems 2005Johnson Transformation with SB Distribution Type

1.265 + 0.366 * Ln( ( X - 0.027 ) / ( 127.493 - X ) )

I Chart

Moving Range Chart



Normal Prob Plot

AD: 0.292, P: 0.599



4.53.01.50.0-1.5-3.0

transformed data

USL*

Scale 127.466

LB* *

Target* *

USL* 5.13606


StDev * 1.06949

LB 0

Target *

USL 127.49

Sample Mean 22.7058

Sample N 85

StDev 34.7355

Shape1 1.26541

Shape2 0.366073

Location 0.0272102


Process Data

Pp *

PPL *

PPU 1.57

Ppk 1.57


PPM < LB 0.00

PPM > USL 0.00

PPM Total 0.00


PPM < LB *

PPM > USL 1.21

PPM Total 1.21



1.265 + 0.366 * Ln( ( X - 0.027 ) / ( 127.493 - X ) )



En el año 2005 la transformada de Johnson sugerida por Minitab es la del tipo SB, limitada,

válida en el intervalo (El método de Johnson muestra un P=0.599, que indica que la transformada es normal. Por otra parte, un análisis de capacidad y estabilidad en el tiempo, entrega un valor de PpK=1.57, lo cual

sugiere que el proceso cumple con las especificaciones dadas. La inferencia anterior también es soportada al aplicar Weibull, ya que se obtiene un valor de PpK= 1.04.


490420350280210140700

LB USL

LB 0

Target *

USL 504

Sample Mean 22.7058

Sample N 85

Shape 0.51628

Scale 12.472

Process Data

Pp *

PPL *

PPU 1.04

Ppk 1.04


PPM < LB 0.00

PPM > USL 0.00

PPM Total 0.00


PPM < LB *

PPM > USL 1169.10

PPM Total 1169.10





4.1.6. Análisis de variabilidad de problemas – 2005 a 2007

Para analizar la variabilidad entre los años 2005 y 2007 de la media anual, y averiguar si existen o no diferencias significativas, se realizó un test de One Way ANOVA. Como se ha dicho antes, es el recomendado para medias y variables continuas, y cuando se tienen más de dos muestras. Al igual que para servicios, como hipótesis nula, Ho, se plantea que “no existen diferencias significativas en las medias entre años 2005 y 2007”. La hipótesis alternativa, Ha, será por lo tanto, que “existen diferencias significativas en las medias por año”. Se recuerda que se debe rechazar la Ho si el valor de p es menor a 0.05. Esto implica que se asume un error del 5% al rechazarla, tomando la Ha como verdadera.

Los datos usados como fuente del análisis de capacidad, aplicando la transformada de Johnson, dieron como resultado: Problems 2005, Mean by year Cpu=1 Cpk=1 Problems 2006, Mean by year Cpu=1.07 Cpk=1.07 Problems 2007, Mean by year Cpu=1.64 Cpk=1.64 Se puede ver que los índices Cpu y Cpk en el 2007 fueron mejores que en los otros dos años; aunque estos valores no indican significativamente tal diferencia, para ello se utiliza el test ANOVA, que permite averiguarlo.

Tabla 4.1.6-1 ANOVA – Media de problemas vs. Año 2005 al 2007

Source DF SS MS F P

Year 2 98.96 49.48 18.05 0.000

Error 180 493.45 2.74

Total 182 592.40

S = 1.656 R-Sq = 16.70% R-Sq(adj) = 15.78%

Con un P=0.000 se infiere que existen diferencias significativas entre los

años.




Pooled StDev

Level N Mean StDev -----+---------+---------+---------+----

2005 83 0.082 1.056 (-----*-----)

2006 73 1.628 1.966 (-----*------)

2007 27 1.318 2.181 (----------*---------)

-----+---------+---------+---------+----

0.00 0.60 1.20 1.80






Year Lower Center Upper --+---------+---------+---------+-------

2006 0.919 1.547 2.174 (-----*------)

2007 0.370 1.236 2.102 (-------*--------)

--+---------+---------+---------+-------

-1.0 0.0 1.0 2.0


Year Lower Center Upper --+---------+---------+---------+-------

2007 -1.191 -0.311 0.570 (--------*--------)

--+---------+---------+---------+-------

-1.0 0.0 1.0 2.0

Gráfico 4.1.6-1 Grafico de cajas de medias de Problemas Año 2005 al 2007 - ANOVA

200720062005

5

4

3

2

1

0

-1

-2

-3

-4

Year

Joh

nso

n

1.317611.62832

0.0815816

Boxplot of Johnson - Problems 2005 to 2007



Gráfico 4.1.6-2 Gráficos de Residuos de medias de Problemas 2005 al 2007 - ANOVA

5.02.50.0-2.5-5.0

99.9

99

90

50

10

1

0.1

Residual

Pe

rce

nt

1.61.20.80.40.0

2

0

-2

-4

-6

Fitted Value

Re

sid

ua

l

3.01.50.0-1.5-3.0-4.5

24

18

12

6

0

Residual

Fre

qu

en

cy

180160140120100806040201

2

0

-2

-4

-6

Observation Order

Re

sid

ua

l



Residual Plots for Johnson - Problems 2005 to 2007

El intervalo de confianza para las diferencias entre medias de los años 2006 y 2007, con respecto al 2005, es significante. Esto se deduce por dos hechos: el intervalo en el análisis individual no incluye el cero y el valor de p = 0.000 en el análisis general. En base a lo anterior corresponde rechazar la hipótesis nula Ho. Corresponde decir que existen diferencias significativas entre las medias de los años analizados



4.1.7. Análisis de variabilidad de problemas – 2006 y 2007

Aquí se realiza un análisis de los años 2006 y 2007 solamente, donde se plantea:

Ho: no existen diferencias significativas entre los años 2006 y 2007. Ha: existen diferencias significativas entre los años 2006 y 2007.

Tabla 4.1.7-1 ANOVA – Media de problemas vs. Año 2006 y 2007 Source DF SS MS F P

Year 1 0.22 0.22 0.22 0.639

Error 96 96.70 1.01

Total 97 96.92

S = 1.004 R-Sq = 0.23% R-Sq(adj) = 0.00%

Con un P=0.639 se puede decir que no existe diferencia significativa entre los

dos años.


Pooled StDev

Level N Mean StDev ------+---------+---------+---------+---

2006 71 -0.037 1.057 (-----------*-----------)

2007 27 -0.144 0.842 (------------------*------------------)

------+---------+---------+---------+---

-0.40 -0.20 -0.00 0.20






Year Lower Center Upper ---------+---------+---------+---------+

2007 -0.557 -0.107 0.344 (--------------*--------------)

---------+---------+---------+---------+

-0.30 0.00 0.30 0.60



Gráfico 4.1.7-1 Grafico de cajas de medias de Problemas Año 2006 y 2007 - ANOVA

20072006

2

1

0

-1

-2

-3

-4

Year

Joh

nso

n

-0.143678-0.0369202

Boxplot of Johnson - Problems 2006 to 2007

Gráfico 4.1.7-2 Gráficos de Residuos de medias de Problemas 2006 y 2007 – ANOVA

420-2-4

99.9

99

90

50

10

1

0.1

Residual

Pe

rce

nt

-0.050-0.075-0.100-0.125-0.150

2

0

-2

-4

Fitted Value

Re

sid

ua

l

210-1-2-3

24

18

12

6

0

Residual

Fre

qu

en

cy

9080706050403020101

2

0

-2

-4

Observation Order

Re

sid

ua

l



Residual Plots for Johnson - Problems 2006 to 2007



El intervalo de confianza para las diferencias entre medias de los años 2006 y 2007 no es significativo, debido a que el intervalo en el análisis individual incluye el cero y el valor de p es 0.639. Con esto se acepta la Ho, es decir, no existen diferencias significativas entre las medias del 2006 y 2007.

4.1.8. Factores y efectos principales en la media (Servicios)

En este escenario se encuentran diferencias significativas en la capacidad, pero los procesos siguen estando bajo control. En este momento es vital analizar las variables relacionadas con la principal, Resolution Time (RT), para ver qué factores influyen o pueden mejorar los procesos.

Los gráficos de efecto principal son mayormente útiles cuando se tienen varios factores, allí se pueden comparar los cambios en los niveles de la media para ver cuáles de ellos son más influyentes en la respuesta. Para esto se comenzará con los servicios, de allí surge que:

Un efecto principal está presente cuando distintos niveles de un factor afectan la respuesta de manera diferente. Para cada factor con dos niveles, podríamos encontrar que un factor incrementa la media comparada con la del otro nivel, esta diferencia es el efecto principal.

Cuando la línea es horizontal, o paralela al eje de las Xs, entonces no hay efecto principal presente. Cada nivel de factor afecta la respuesta en la misma forma, y la respuesta de la media es la misma a lo largo de todos los niveles del factor.

Cuando la línea no es horizontal, entonces existe un efecto principal. Distintos niveles de un factor afectan la respuesta diferentemente. Se busca la máxima diferencia en la posición vertical de los puntos graficados, mientras mayor sea la pendiente de la línea, mayor será la magnitud del efecto principal.

Tanto en el año 2006 como 2007, el RT en función de la severidad, muestra que en los tickets de severidad baja tiende a ser igual a la media; mientras que los de alta prioridad se resuelven en menos tiempo y los de media tardan más. En lo referente a aquellos con impacto en la compañía, departamentos o clientes externos, tienen un tiempo de resolución mayor a la media en ambos años, debido a la complejidad de los servicios requeridos por ellos. Sin embargo en el gráfico de interacción del tiempo hasta la asignación del ticket de acuerdo a la prioridad e impacto, se evidencia que la mayoría están asignados priorizando los de mayor impacto y mayor severidad.



Gráfico 4.1.8-1 Interacción: media de servicios vs. impacto y severidad - 2006/2007

MediumLowHighCritical

25

20

15

10

5

0

Severity

Me

an

Company

Department

External Customer

Indiv idual

Impact

Interaction Plot for First Asisgnation Time (hs) Service 06/07

Data Means

Gráfico 4.1.8-2 Efectos de severidad e impacto sobre la media (RT) - Servicios 2006

Med

ium

Low

High

1.1

1.0

0.9

0.8

0.7

0.6

0.5

0.4

Individu

al

External C

ustomer

Depa

rtmen

t

Compa

ny

Severity

Me

an

Impact

Main Effects Plot for Days -Severy & Impact Services 06

Data Means



Gráfico 4.1.8-3 Efectos de severidad e impacto sobre la media (RT) - Servicios 2007

Med

ium

Low

High

Critica

l

1.0

0.8

0.6

0.4

0.2

0.0

Individu

al

External C

ustomer

Depa

rtmen

t

Compa

ny

Severity

Me

an

Impact

Main Effects Plot for Days - Severity & Impact Services 07

Data Means

Gráfico 4.1.8-4 Efectos: Miembros de TI, tipo de ticket, media semanal de servicios 2006

TCQ

N73

QBW

D64

FQ

G846

FM

XP43

ARG

031

ALM

045

AJO

023

2.0

1.5

1.0

0.5

0.0

Tele

phony

Sys

tem

Opera

tions

Support

Serv

ices

Softw

are

Serv

er

Secu

rity

Rem

ote

Acc

ess

Pri

vile

ges

Pri

nting

Out O

f Sco

pe

Opera

ting S

yste

mN

on-I

TN

etw

ork

Mess

agin

gLA

NIn

tern

al IT

Help

Desk

Hard

ware

File S

erv

ices

Faci

lities

Engin

eeri

ng A

pps

EBusi

ness

Desk

top/W

ork

station

Desk

top A

pps

Data

base

Collabora

tive

Busi

ness

Apps

Back

up/R

est

ore

Acc

ount

ITIS Team

Me

an

Profile Level 2

Main Effects Plot for Days - IT Team & Ticket Profile Service 06

Data Means



Gráfico 4.1.8-5 Efectos: Miembros de TI, clase de ticket, media semanal servicios 2007

TCQ

N73

QBW

D64

FQ

G846

FM

XP43

ARG

031

ALM

045

AJO

023

1.4

1.2

1.0

0.8

0.6

0.4

0.2

0.0

Use

rid

Tele

phony

Sys

tem

Opera

tions

Support

Serv

ices

Softw

are

Serv

er

Secu

rity

Rem

ote

Acc

ess

Pri

vile

ges

Pri

nting

Out O

f Sco

pe

Opera

ting S

yste

mN

on-I

TN

etw

ork

Mess

agin

gLA

NIn

tern

al IT

In-s

cope A

pplica

tions

Help

Desk

Hard

ware

File S

erv

ices

Faci

lities

Engin

eeri

ng A

pps

Desk

top/W

ork

station

Desk

top A

pps

Data

base

Collabora

tive

Busi

ness

Apps

Back

up/R

est

ore

Acc

ount

ITIS Team

Me

an

Profile Level 2

Main Effects Plot for Days - ITIS Team & Ticket Profile Services 07

Data Means

En los gráficos anteriores se reflejan los efectos principales en el RT (en días) en función de los miembros de la IT y del perfil del ticket. Se concluye que la media del RT de los tickets de servicios tiene variaciones importantes; tanto el RT por IT Members como el de Ticket Profile, donde las medias cambian.

En cuanto a IT Members, la mayoría ha aumentado y en los perfiles de ticket se registran variaciones muy grandes entre cada año. Estos dos factores son importantes y se supone que son los que provocan las diferencias de capacidad en servicio entre los años 2006 y 2007.



4.1.9. Interacciones de variables o efectos, sus relaciones (Servicios)

Los factores tratados en esta sección son generalmente usados en conjunto con el análisis de varianza. Cada gráfico presentado muestra la interacción entre dos factores. Una interacción ocurre cuando el cambio en la respuesta, desde un nivel de un factor a otro, difiere del cambio en la respuesta en el mismo nivel del segundo factor. Esto es, cuando el efecto de un factor depende del otro. Los gráficos de interacción (o de perfil) sirven para comparar las medias marginales en un modelo, y se crean para cada variable dependiente. Son gráficos de líneas en el que cada punto indica la media marginal estimada de una variable dependiente, en un nivel de un factor. Los niveles de un segundo factor se pueden utilizar para generar líneas diferentes. Cada nivel en un tercer factor se puede utilizar para crear un gráfico. Los gráficos de interacciones se utilizan: Antes de hacer un análisis de varianza, para determinar cuáles de las

interacciones en dos sentidos se debe incluir en el modelo. El gráfico es la parte analógica de F-Test de una interacción en un análisis de varianza.

Para comparar la fortaleza relativa de los efectos con los factores. Permiten visualizar la posible interacción entre factores de un diseño. Si las líneas en el gráfico se cruzan, existe interacción. Por el contrario, si estas son paralelas no la hay. También con ellos, se puede observar la tendencia de los valores promedios de la variable dependiente para los distintos niveles de cada factor, ya que muestran si las medias marginales estimadas aumentan o disminuyen a través ellos. Luego, para determinar si el conjunto es estadísticamente significante, se debe hacer el test apropiado.



Gráfico 4.1.9-1 Interacción media de servicios y los efectos impacto y severidad – 2006

IndividualExternal CustomerDepartmentCompany

1.4

1.2

1.0

0.8

0.6

0.4

0.2

Impact

Me

an

High

Low

Medium

Severity

Interaction Plot for Days - Services 06

Data Means

Gráfico 4.1.9-2 Interacción media de servicios y los efectos impacto y severidad – 2007

IndividualExternal CustomerDepartmentCompany

1.2

1.0

0.8

0.6

0.4

0.2

0.0

Impact

Me

an

Critical

High

Low

Medium

Severity

Interaction Plot for Days - Services 07

Data Means



En el año 2006 se observa que existen diferencias, cuando se tiende al impacto individual la media tiende al mismo valor independientemente de la severidad. También se puede ver que para el caso de impacto departamental, la severidad y RS están en orden correcto. En el gráfico correspondiente al año 2007 se observa que la media de RT para impacto individual y todo tipo de severidad, a excepción de la media, son los tickets que han sido resueltos más rápido. En cuanto a tickets de severidad alta y de impacto individual, fueron resueltos más rápido que los críticos. También para el caso de impacto departamental, la severidad y RS están en orden correcto. Probablemente la falta de una adecuada categorización o individualización de la severidad e impacto del servicio, por parte del usuario final, como así también la complejidad de la solicitud, produce las variaciones exhibidas. Indudablemente los pedidos categorizados con alto impacto y alta severidad provocan en el sistema que se eleve la prioridad, dedicándole más recursos a su resolución, por ser generalmente más complejos. En los dos gráficos siguientes de interacción de IT Members (Team) con Service tickets profile, se advierte la variabilidad que existe en ambos efectos, de los integrantes entre sí, dentro del mismo año para la resolución de determinado perfil de ticket; como así también la de su comportamiento en el año siguiente (2007) respecto del 2006.

Gráfico 4.1.9-3 Interacción: media de servicios con miembros de TI y perfil del ticket – 2006



Gráfico 4.1.9-4 Interacción: media de servicios con miembros de TI y perfil del ticket – 2007



4.1.10. Gráficos de intervalos de media (95%) vs. variables por año

Gráfico 4.1.10-1 Intervalos de la media (RT) debido al impacto del servicio – 06/07

Indiv

idual

Exte

rnal C

usto

mer

Depa

rtmen

t

Compa

ny

3

2

1

0

-1

Indiv

idual

Exte

rna l C

usto

mer

Depa

rtmen

t

Compa

ny

2006

Impact

Da

ys

2007

Interval Plot of Days95% CI for the Mean

Panel variable: Year

Gráfico 4.1.10-2 Intervalos de la media (RT) debido a la severidad de servicio - 06/07


1.2

0.9

0.6

0.3

0.0


2006

Severity

Da

ys

2007

Interval Plot of Days95% CI for the Mean

Panel variable: Year



Gráfico 4.1.10-3 Intervalos de la media de servicios por miembros de TI – 06/07



Gráfico 4.1.10-4 Intervalos de la media servicios debido al perfil del ticket – 06/07

Gráfico 4.1.10-5 Gráfico de cajas (RT) debido al perfil del ticket de servicio -06/07



4.1.11. Análisis de variabilidad de problemas (RT) vs miembros de TI - 2005

Examinando en detalle cada conjunto de gráficos, se buscaron los factores que podrían ser las causas de las diferencias encontradas entre los años 2005 y 2007. Se plantearon como posibilidad los factores miembros de IT y tipo de ticket profile. Para corroborar estas inferencias, se hicieron análisis estadísticos de variabilidad para estos años, que se presentan en la sección siguiente. En una primera etapa se revisan los datos correspondientes al año 2005, realizando un análisis de varianza, One-Way ANOVA. Luego se ejecuto un test de varianzas iguales versus los factores para determinar la validez de ANOVA equilibrado, para estos casos se ejecutaron ambos tests que vienen incluidos en Minitab, basado ambos en el nivel de confidencia de Bonferroni. El test de Bartlett se usa cuando provienen de una distribución normal y el test de Levene cuando los datos vienen de una distribución continua, pero no necesariamente normal. La hipótesis nula, Ho, será que no existen diferencias significativas entre los miembros de IT, en cuanto a tiempo de resolución de tickets (RT). La hipótesis alternativa, Ha, por tanto, será que si existen tales diferencias.

Tabla 4.1.11-1 ANOVA – Media de problemas vs. Miembros de TI 2005

Source DF SS MS F P

IT Members 4 6.42 1.61 1.43 0.231

Error 80 89.66 1.12

Total 84 96.08

S = 1.059 R-Sq = 6.68% R-Sq(adj) = 2.02%

Se obtiene un P=0.231, se concluye que no existen diferencias

significativas entre ellos pero no es determinativo ya que falta

el análisis de varianzas iguales.


Pooled StDev

Level N Mean StDev --+---------+---------+---------+-------

AJO023 8 0.420 0.604 (------*-----)

AJR037 60 0.131 1.169 (-*-)

ALM045 10 0.222 0.596 (-----*----)

ARC038 1 -0.589 * (----------------*-----------------)

ARG031 6 -0.806 0.805 (------*------)

--+---------+---------+---------+-------

-2.4 -1.2 0.0 1.2



All Pairwise Comparisons among Levels of IT Members


IT Members = AJO023 subtracted from:



IT Members Lower Center Upper -------+---------+---------+---------+--

AJR037 -1.402 -0.289 0.824 (----*---)

ALM045 -1.601 -0.198 1.204 (----*-----)

ARC038 -4.145 -1.009 2.127 (------------*------------)

ARG031 -2.823 -1.226 0.371 (-----*-----)

-------+---------+---------+---------+--

-2.5 0.0 2.5 5.0

IT Members = AJR037 subtracted from:


ALM045 -0.919 0.091 1.101 (---*---)

ARC038 -3.701 -0.720 2.262 (-----------*-----------)

ARG031 -2.203 -0.937 0.329 (----*----)

-------+---------+---------+---------+--

-2.5 0.0 2.5 5.0

IT Members = ALM045 subtracted from:


ARC038 -3.912 -0.811 2.291 (------------*-----------)

ARG031 -2.555 -1.028 0.499 (-----*-----)

-------+---------+---------+---------+--

-2.5 0.0 2.5 5.0

IT Members = ARC038 subtracted from:


ARG031 -3.411 -0.217 2.977 (------------*------------)

-------+---------+---------+---------+--

-2.5 0.0 2.5 5.0

Gráfico 4.1.11-1 Grafico de cajas de problemas (RT) por miembros de TI – 05 - ANOVA

ARG031ARC038ALM045AJR037AJO023

3

2

1

0

-1

-2

-3

IT Members

Joh

nso

n

-0.805696-0.588509

0.222010.131279

0.42023

Boxplot of Johnson



Gráfico 4.1.11-2 Gráfica de Residuos problemas (RT) por miembros de TI -05- ANOVA

420-2-4

99.9

99

90

50

10

1

0.1

Residual

Pe

rce

nt

0.50.0-0.5

3.0

1.5

0.0

-1.5

-3.0

Fitted Value

Re

sid

ua

l

210-1-2-3

20

15

10

5

0

Residual

Fre

qu

en

cy

80706050403020101

3.0

1.5

0.0

-1.5

-3.0

Observation Order

Re

sid

ua

l



Residual Plots for Johnson

Test de varianzas iguales: Tiempo de respuesta de problemas vs Miembros de TI - 2005 95% Bonferroni confidence intervals for standard deviations

IT Members N Lower StDev Upper

AJO023 8 0.360141 0.60420 1.55058

AJR037 60 0.948885 1.16930 1.51028

ALM045 10 0.372895 0.59581 1.31763

ARC038 1 * * *

ARG031 6 0.446895 0.80484 2.67452

Bartlett's Test (Normal Distribution)

Test statistic = 8.76, p-value = 0.033

Levene's Test (Any Continuous Distribution)


Por lo que concluimos que aunque el análisis de varianza (ANOVA) obtuvimos un P > 0,05 pero en el test de varianzas de iguales de Bartlett vemos que p-value es menor que 0,05 por ende rechazamos la Ho. También en los gráficos de residuos (residual vs. fitted value) observamos que se alternan entre el cero pero existen ciertas concentraciones de los mismos superando el intervalo [-2,2] no reflejando una distribución aleatoria de los mismos. En cuando a la distribución de residuos vemos que se asemeja a un comportamiento normal con una distribución de observaciones aleatorias.



Este implicaría realizar un ANOVA no balanceado o de varianzas no iguales, que no lo desarrollaremos aquí debido a su complejidad para poder determinar que factor es el que esta desequilibrando el ANOVA. El gráfico siguiente muestra que la miembro de IT ―ARG031‖ es el que tiene mayor amplitud y que a priori podría ser una de varianzas que introducen las variaciones mayores.

Gráfico 4.1.11-3 Test de Varianzas iguales – Problemas (RT) vs miembros de TI

ARG031

ALM045

AJR037

AJO023

3.02.52.01.51.00.5

IT M

em

be

rs

95% Bonferroni Confidence Intervals for StDevs

Test Statistic 8.76

P-Value 0.033

Test Statistic 3.41

P-Value 0.021

Bartlett's Test

Levene's Test

Test for Equal Variances for Johnson

4.1.12. Análisis de variabilidad RT Problemas vs de perfil del ticket – 2005

Para este análisis se tomará como hipótesis nula, Ho, que no existen diferencias significativas entre los tipos de tickets, de acuerdo al perfil del problema (Tickets Profile), con el tiempo de resolución de los mismos (RT). Por lo tanto, la hipótesis alternativa, Ha, será que si existen tales diferencias.

Tabla 4.1.12-1 ANOVA – Media de problemas vs. Perfil de tickets 2005

Source DF SS MS F P

Profile Level 2 13 14.15 1.09 0.94 0.515

Error 71 81.93 1.15



Total 84 96.08

S = 1.074 R-Sq = 14.72% R-Sq(adj) = 0.00%

Se obtiene un P=0.515, por ende se concluye que no existen

diferencias significativas entre ellos, faltado realizar el test

de varianzas iguales de Bartlett a posterior.


Pooled StDev

Level N Mean StDev ----+---------+---------+---------+-----

Account 3 -0.125 0.573 (-------*-------)

Business Apps 17 0.234 1.394 (---*--)

CSC Supported 2 1.190 0.653 (---------*---------)

Database 6 -0.372 1.471 (-----*----)

Desktop Apps 18 0.255 1.005 (---*--)

EBusiness 1 0.661 * (-------------*--------------)

Engineering Apps 1 1.642 * (-------------*-------------)

Hardware 10 0.298 0.586 (----*----)

Messaging 2 0.320 0.430 (---------*---------)

Network 2 0.285 0.662 (---------*---------)

Operating System 2 -0.619 0.235 (---------*---------)

Printing 1 0.247 * (--------------*-------------)

Security 14 -0.507 0.974 (---*--)

Software 6 0.215 1.063 (----*-----)

----+---------+---------+---------+-----

-1.5 0.0 1.5 3.0



All Pairwise Comparisons among Levels of Profile Level 2


Profile Level 2 = Account subtracted from:

Profile Level 2 Lower Center Upper

Business Apps -1.977 0.358 2.694

CSC Supported -2.090 1.315 4.719

Database -2.885 -0.248 2.390

Desktop Apps -1.946 0.380 2.706

EBusiness -3.521 0.786 5.092

Engineering Apps -2.540 1.766 6.073

Hardware -2.032 0.423 2.878

Messaging -2.960 0.445 3.849

Network -2.995 0.410 3.815

Operating System -3.899 -0.495 2.910

Printing -3.935 0.371 4.678

Security -2.755 -0.383 1.990

Software -2.298 0.339 2.977

Profile Level 2 +---------+---------+---------+---------

Business Apps (------*------)

CSC Supported (---------*--------)

Database (------*-------)

Desktop Apps (------*------)

EBusiness (-----------*------------)



Engineering Apps (-----------*-----------)

Hardware (------*------)

Messaging (--------*---------)

Network (---------*---------)

Operating System (---------*--------)

Printing (-----------*-----------)

Security (------*------)

Software (-------*-------)

+---------+---------+---------+---------

-7.0 -3.5 0.0 3.5

Profile Level 2 = Business Apps subtracted from:


CSC Supported -1.832 0.956 3.744

Database -2.377 -0.606 1.165

Desktop Apps -1.240 0.022 1.283

EBusiness -3.410 0.427 4.265


Hardware -1.422 0.064 1.551

Messaging -2.702 0.087 2.875

Network -2.737 0.052 2.840


Printing -3.825 0.013 3.851

Security -2.087 -0.741 0.605

Software -1.790 -0.019 1.752

Profile Level 2 +---------+---------+---------+---------

CSC Supported (-------*-------)

Database (----*----)

Desktop Apps (---*---)

EBusiness (----------*----------)

Engineering Apps (----------*----------)

Hardware (---*---)

Messaging (-------*-------)

Network (-------*-------)

Operating System (-------*-------)

Printing (----------*----------)

Security (---*---)

Software (----*----)

+---------+---------+---------+---------

-7.0 -3.5 0.0 3.5

Profile Level 2 = CSC Supported subtracted from:


Database -4.608 -1.562 1.483

Desktop Apps -3.715 -0.935 1.845

EBusiness -5.097 -0.529 4.039


Hardware -3.781 -0.892 1.997

Messaging -4.599 -0.870 2.860

Network -4.634 -0.905 2.825


Printing -5.511 -0.943 3.624

Security -4.517 -1.697 1.122

Software -4.021 -0.975 2.070

Profile Level 2 +---------+---------+---------+---------

Database (--------*-------)

Desktop Apps (-------*-------)

EBusiness (------------*-------------)

Engineering Apps (------------*------------)



Hardware (-------*--------)

Messaging (----------*---------)

Network (---------*----------)

Operating System (----------*---------)

Printing (------------*------------)

Security (-------*-------)

Software (-------*--------)

+---------+---------+---------+---------

-7.0 -3.5 0.0 3.5

Profile Level 2 = Database subtracted from:


Desktop Apps -1.131 0.628 2.386

EBusiness -2.995 1.033 5.062


Hardware -1.256 0.670 2.596

Messaging -2.353 0.693 3.738

Network -2.388 0.658 3.703


Printing -3.410 0.619 4.647

Security -1.955 -0.135 1.685

Software -1.566 0.587 2.740

Profile Level 2 +---------+---------+---------+---------

Desktop Apps (----*----)

EBusiness (-----------*----------)

Engineering Apps (-----------*----------)

Hardware (-----*----)

Messaging (--------*--------)

Network (--------*--------)

Operating System (-------*--------)

Printing (-----------*----------)

Security (-----*----)

Software (-----*-----)

+---------+---------+---------+---------

-7.0 -3.5 0.0 3.5

Profile Level 2 = Desktop Apps subtracted from:


EBusiness -3.426 0.406 4.238


Hardware -1.428 0.043 1.514

Messaging -2.715 0.065 2.845

Network -2.750 0.030 2.810


Printing -3.841 -0.009 3.823

Security -2.092 -0.762 0.567

Software -1.799 -0.041 1.718

Profile Level 2 +---------+---------+---------+---------

EBusiness (----------*----------)

Engineering Apps (----------*----------)

Hardware (---*---)

Messaging (-------*-------)

Network (-------*-------)

Operating System (-------*------)

Printing (----------*----------)

Security (---*---)

Software (----*----)

+---------+---------+---------+---------

-7.0 -3.5 0.0 3.5



Profile Level 2 = EBusiness subtracted from:



Hardware -4.275 -0.363 3.549

Messaging -4.909 -0.341 4.227

Network -4.944 -0.376 4.192


Printing -5.689 -0.415 4.860

Security -5.029 -1.168 2.692

Software -4.475 -0.446 3.582

Profile Level 2 +---------+---------+---------+---------

Engineering Apps (--------------*--------------)

Hardware (----------*----------)

Messaging (------------*------------)

Network (------------*------------)

Operating System (------------*------------)

Printing (--------------*--------------)

Security (----------*----------)

Software (-----------*----------)

+---------+---------+---------+---------

-7.0 -3.5 0.0 3.5

Profile Level 2 = Engineering Apps subtracted from:


Hardware -5.255 -1.344 2.568

Messaging -5.889 -1.321 3.246

Network -5.924 -1.356 3.211


Printing -6.669 -1.395 3.880

Security -6.009 -2.149 1.712

Software -5.455 -1.427 2.602

Profile Level 2 +---------+---------+---------+---------

Hardware (----------*----------)

Messaging (------------*------------)

Network (------------*------------)

Operating System (-------------*------------)

Printing (--------------*--------------)

Security (----------*----------)

Software (-----------*----------)

+---------+---------+---------+---------

-7.0 -3.5 0.0 3.5

Profile Level 2 = Hardware subtracted from:


Messaging -2.867 0.022 2.911

Network -2.902 -0.013 2.876


Printing -3.963 -0.051 3.860

Security -2.349 -0.805 0.739

Software -2.009 -0.083 1.843

Profile Level 2 +---------+---------+---------+---------

Messaging (-------*-------)

Network (-------*-------)

Operating System (-------*--------)

Printing (----------*----------)



Security (----*---)

Software (-----*----)

+---------+---------+---------+---------

-7.0 -3.5 0.0 3.5

Profile Level 2 = Messaging subtracted from:


Network -3.765 -0.035 3.695


Printing -4.641 -0.074 4.494

Security -3.647 -0.827 1.992

Software -3.151 -0.105 2.940

Profile Level 2 +---------+---------+---------+---------

Network (----------*----------)

Operating System (---------*----------)

Printing (------------*------------)

Security (-------*-------)

Software (--------*-------)

+---------+---------+---------+---------

-7.0 -3.5 0.0 3.5

Profile Level 2 = Network subtracted from:



Printing -4.606 -0.039 4.529

Security -3.612 -0.792 2.027

Software -3.116 -0.070 2.975

Profile Level 2 +---------+---------+---------+---------

Operating System (---------*----------)

Printing (------------*------------)

Security (-------*-------)

Software (--------*-------)

+---------+---------+---------+---------

-7.0 -3.5 0.0 3.5

Profile Level 2 = Operating System subtracted from:

Profile

Level 2 Lower Center Upper +---------+---------+---------+---------

Printing -3.702 0.866 5.434 (------------*-------------)

Security -2.707 0.112 2.932 (-------*-------)

Software -2.211 0.834 3.879 (-------*--------)

+---------+---------+---------+---------

-7.0 -3.5 0.0 3.5

Profile Level 2 = Printing subtracted from:

Profile


Security -4.614 -0.754 3.107 (----------*----------)

Software -4.060 -0.032 3.997 (-----------*----------)

+---------+---------+---------+---------

-7.0 -3.5 0.0 3.5

Profile Level 2 = Security subtracted from:



Profile


Software -1.098 0.722 2.542 (----*----)

+---------+---------+---------+---------

-7.0 -3.5 0.0 3.5

Gráfico 4.1.12-1 Grafico de cajas de problemas (RT) por perfil del ticket – 05 - ANOVA

Softw

are

Secu

rity

Printin

g

Ope

ratin

g Sy

stem

Netw

ork

Mes

saging

Hard

war

e

Engine

ering Ap

ps

EBus

ines

s

Desktop Ap

ps

Databa

se

CSC Su

pported

Busine

ss A

pps

Acco

unt

3

2

1

0

-1

-2

-3

Profile Level 2

Joh

nso

n

0.214791

-0.507083

0.246648

-0.619296

0.285276

0.320257

0.298113

1.64162

0.661196

0.255372

-0.372245

1.19011

0.233739-0.124569

Boxplot of Johnson



Gráfico 4.1.12-2 Gráfica de Residuos problemas (RT) por perfil del ticket -05- ANOVA

20-2-4

99.9

99

90

50

10

1

0.1

Residual

Pe

rce

nt

1.51.00.50.0-0.5

3.0

1.5

0.0

-1.5

-3.0

Fitted Value

Re

sid

ua

l

210-1-2-3

20

15

10

5

0

Residual

Fre

qu

en

cy

80706050403020101

3.0

1.5

0.0

-1.5

-3.0

Observation Order

Re

sid

ua

l




Test de varianzas iguales: Tiempo de respuesta de problemas vs perfil del ticket - 2005 95% Bonferroni confidence intervals for standard deviations

Profile Level 2 N Lower StDev Upper

Account 3 0.232092 0.57260 12.004

Business Apps 17 0.919919 1.39420 2.628

CSC Supported 2 0.214040 0.65326 229.341

Database 6 0.762256 1.47053 6.049

Desktop Apps 18 0.670132 1.00516 1.851

EBusiness 1 * * *

Engineering Apps 1 * * *

Hardware 10 0.346427 0.58560 1.477

Messaging 2 0.140997 0.43033 151.076

Network 2 0.216893 0.66197 232.397

Operating System 2 0.077058 0.23518 82.566

Printing 1 * * *

Security 14 0.619524 0.97445 2.010

Software 6 0.551094 1.06316 4.373





Por lo que concluimos que aunque el análisis de varianza (ANOVA) obtuvimos un P > 0,05 y en el test de varianzas de iguales de Bartlett vemos que p-value > 0,05 por ende aceptamos la Ho.



También en los gráficos de residuos (residual vs. fitted value) observamos que se alternan entre el cero pero existen menos concentraciones de los mismos pocos puntos superando el intervalo [-2,2] reflejando una distribución aleatoria de los mismos. En cuando a la distribución de residuos vemos que se asemeja a un comportamiento normal con una distribución de observaciones aleatorias. En principio el perfil del ticket no sería significativo en el tiempo de resolución de problemas del 2005. El gráfico siguiente muestra que los perfiles de tickets de IT que tiene mayor amplitud y que a priori podría ser las varianzas que introducen las variaciones mayores.

Gráfico 4.1.12-3 Test de Varianzas iguales – Problemas (RT) vs perfil del ticket

Software

Security

Printing

Operating System

Network

Messaging

Hardware

Engineering Apps

EBusiness

Desktop Apps

Database

CSC Supported

Business Apps

Account

250200150100500

Pro

file

Le

ve

l 2


Test Statistic 11.66

P-Value 0.308

Test Statistic 1.53

P-Value 0.148

Bartlett's Test

Levene's Test




4.1.13. Análisis de variabilidad de Media de problemas vs miembros TI 2007

Para este análisis se tomará como hipótesis nula, Ho, que no existen diferencias significativas entre los miembros de IT en cuanto a tiempo de resolución de tickets (RT). De allí que, la hipótesis alternativa, Ha, será que si existen tales diferencias.

Tabla 4.1.13-1 ANOVA – Media de problemas vs. Miembros de TI 2007

Source DF SS MS F P

IT Members 6 10.635 1.773 2.06 0.105

Error 20 17.242 0.862

Total 26 27.877

S = 0.9285 R-Sq = 38.15% R-Sq(adj) = 19.60%


diferencias significativas entre ellos, faltaría el test de

varianzas iguales.

Aunque en comparación al año 2005 (P=0.231) el valor ha

disminuido.

Level N Mean StDev --------+---------+---------+---------+-

AJO023 3 -0.1247 0.7690 (--------*--------)

ALM045 2 0.3814 1.0079 (----------*-----------)

CDT012 3 0.9745 1.1222 (--------*--------)

CKR024 2 -0.8203 0.4553 (----------*-----------)

FMXP43 3 0.7748 1.2305 (--------*---------)

QBWD64 9 -0.6334 0.9875 (-----*----)

TCQN73 5 0.3720 0.6099 (------*------)

--------+---------+---------+---------+-

-1.2 0.0 1.2 2.4


Hsu's MCB (Multiple Comparisons with the Best)

Family error rate = 0.05

Critical value = 2.55

Intervals for level mean minus smallest of other level means

Level Lower Center Upper ----+---------+---------+---------+-----

AJO023 -1.0671 0.6957 2.8535 (-----------*-------------)

ALM045 -0.8331 1.2017 3.5655 (-------------*---------------)

CDT012 0.0000 1.7948 3.9527 (-----------*-------------)

CKR024 -2.0348 -0.1869 1.6610 (------------*-----------)

FMXP43 -0.1676 1.5952 3.7530 (-----------*-------------)

QBWD64 -1.6610 0.1869 2.0348 (-----------*------------)

TCQN73 -0.3130 1.1924 3.1701 (---------*------------)

----+---------+---------+---------+-----

-1.5 0.0 1.5 3.0


All Pairwise Comparisons among Levels of IT Members




IT Members = AJO023 subtracted from:

IT Members Lower Center Upper --------+---------+---------+---------+-

ALM045 -2.2629 0.5060 3.2750 (----------*----------)

CDT012 -1.3775 1.0991 3.5758 (---------*---------)

CKR024 -3.4646 -0.6957 2.0733 (----------*----------)

FMXP43 -1.5771 0.8995 3.3761 (---------*---------)

QBWD64 -2.5309 -0.5088 1.5134 (-------*-------)

TCQN73 -1.7184 0.4967 2.7119 (--------*--------)

--------+---------+---------+---------+-

-2.5 0.0 2.5 5.0

IT Members = ALM045 subtracted from:


CDT012 -2.1758 0.5931 3.3620 (----------*----------)

CKR024 -4.2349 -1.2017 1.8315 (-----------*-----------)

FMXP43 -2.3755 0.3935 3.1624 (-----------*----------)

QBWD64 -3.3860 -1.0148 1.3564 (---------*--------)

TCQN73 -2.5471 -0.0093 2.5285 (---------*---------)

--------+---------+---------+---------+-

-2.5 0.0 2.5 5.0

IT Members = CDT012 subtracted from:


CKR024 -4.5637 -1.7948 0.9741 (----------*----------)

FMXP43 -2.6762 -0.1996 2.2770 (---------*---------)

QBWD64 -3.6300 -1.6079 0.4143 (--------*-------)

TCQN73 -2.8176 -0.6024 1.6127 (--------*-------)

--------+---------+---------+---------+-

-2.5 0.0 2.5 5.0

IT Members = CKR024 subtracted from:


FMXP43 -1.1738 1.5952 4.3641 (----------*----------)

QBWD64 -2.1843 0.1869 2.5581 (---------*--------)

TCQN73 -1.3454 1.1924 3.7301 (---------*---------)

--------+---------+---------+---------+-

-2.5 0.0 2.5 5.0

IT Members = FMXP43 subtracted from:


QBWD64 -3.4304 -1.4083 0.6139 (-------*-------)

TCQN73 -2.6180 -0.4028 1.8124 (-------*--------)

--------+---------+---------+---------+-

-2.5 0.0 2.5 5.0

IT Members = QBWD64 subtracted from:


TCQN73 -0.6864 1.0055 2.6973 (------*------)

--------+---------+---------+---------+-

-2.5 0.0 2.5 5.0



Gráfico 4.1.13-1 Grafico de cajas de problemas (RT) por miembros de TI – 07 - ANOVA

TCQN73QBWD64FMXP43CKR024CDT012ALM045AJO023

2

1

0

-1

-2

-3

IT Members

Joh

nso

n

Boxplot of Johnson

Gráfico 4.1.13-2 Gráfica de Residuos problemas (RT) por miembros de TI -07- ANOVA

210-1-2

99

90

50

10

1

Residual

Pe

rce

nt

1.00.50.0-0.5-1.0

2

1

0

-1

-2

Fitted Value

Re

sid

ua

l

210-1-2

8

6

4

2

0

Residual

Fre

qu

en

cy

2624222018161412108642

2

1

0

-1

-2

Observation Order

Re

sid

ua

l






Test de varianzas iguales: Tiempo de respuesta de problemas vs miembros de TI – 2007 95% Bonferroni confidence intervals for standard deviations

IT Members N Lower StDev Upper

AJO023 3 0.323970 0.76903 12.857

ALM045 2 0.345918 1.00791 225.174

CDT012 3 0.472739 1.12217 18.761

CKR024 2 0.156264 0.45531 101.720

FMXP43 3 0.518377 1.23051 20.572

QBWD64 9 0.584383 0.98749 2.528

TCQN73 5 0.308631 0.60992 2.924





Por lo que concluimos que aunque el análisis de varianza (ANOVA) obtuvimos un P > 0,05 y en el test de varianzas de iguales de Bartlett vemos que p-value > 0,05 por ende aceptamos la Ho.

También en los gráficos de residuos (residual vs. fitted value) observamos que se alternan entre el cero dentro del intervalo [-2,2] reflejando una distribución aleatoria de los mismos. En cuando a la distribución de residuos vemos que se asemeja a un comportamiento normal con una distribución de observaciones aleatorias. En principio los miembros de TI no serían significativos en el tiempo de resolución de problemas del 2007. El gráfico siguiente muestra que los miembros de TI que tiene mayor amplitud y que a priori podría ser las varianzas que introducen las variaciones mayores ―ALM045‖.


TCQN73

QBWD64

FMXP43

CKR024

CDT012

ALM045

AJO023

250200150100500

IT M

em

be

rs


Test Statistic 2.07

P-Value 0.913

Test Statistic 0.28

P-Value 0.938

Bartlett's Test

Levene's Test




4.1.14. Análisis de variabilidad de Problemas (RT) vs perfil del ticket - 2007

Nuevamente, la hipótesis nula, Ho, será que no existen diferencias significativas entre los tipos de tickets (profile) con el tiempo de resolución de tickets (RT). La consiguiente hipótesis alternativa, Ha, será que existen diferencias.

Tabla 4.1.14-1 ANOVA – Media de problemas vs. Perfil de tickets 2007 Source DF SS MS F P

Profile Level 2 5 3.50 0.70 0.60 0.698

Error 21 24.37 1.16

Total 26 27.88

S = 1.077 R-Sq = 12.57% R-Sq(adj) = 0.00%


diferencias significativas entre ellos. Faltaría analizar el test

de varianzas iguales para concluir o no la aceptación de Ho

El valor de P ha mejorado respecto del año 2005 (P=0.515)


Pooled StDev

Level N Mean StDev ---+---------+---------+---------+------

Account 3 -0.621 0.098 (----------*----------)

CSC Supported 3 0.248 0.749 (----------*----------)

Engineering Apps 15 0.251 1.016 (----*----)

Hardware 1 -0.560 * (-----------------*------------------)

Network 3 -0.240 0.783 (----------*----------)

Software 2 -0.605 2.749 (------------*------------)

---+---------+---------+---------+------

-2.4 -1.2 0.0 1.2


Hsu's MCB (Multiple Comparisons with the Best)

Family error rate = 0.05

Critical value = 2.48

Intervals for level mean minus smallest of other level means

Level Lower Center Upper

Account -2.455 -0.015 3.026

CSC Supported -1.314 0.868 3.894


Hardware -3.026 0.060 3.318

Network -1.802 0.380 3.406

Software -2.424 0.015 3.228

Level -----+---------+---------+---------+----

Account (-----------*--------------)

CSC Supported (----------*--------------)

Engineering Apps (-------*-------------)

Hardware (--------------*----------------)

Network (----------*--------------)

Software (-----------*---------------)

-----+---------+---------+---------+----



-2.0 0.0 2.0 4.0


All Pairwise Comparisons among Levels of Profile Level 2


Profile Level 2 = Account subtracted from:


CSC Supported -1.881 0.868 3.618


Hardware -3.828 0.060 3.948

Network -2.369 0.380 3.129

Software -3.058 0.015 3.089

Profile Level 2 ---------+---------+---------+---------+

CSC Supported (----------*----------)

Engineering Apps (-------*--------)

Hardware (--------------*---------------)

Network (----------*----------)

Software (-----------*-----------)

---------+---------+---------+---------+

-2.5 0.0 2.5 5.0

Profile Level 2 = CSC Supported subtracted from:



Hardware -4.696 -0.808 3.080

Network -3.237 -0.488 2.261

Software -3.927 -0.853 2.221

Profile Level 2 ---------+---------+---------+---------+

Engineering Apps (--------*--------)

Hardware (---------------*--------------)

Network (----------*----------)

Software (------------*-----------)

---------+---------+---------+---------+

-2.5 0.0 2.5 5.0

Profile Level 2 = Engineering Apps subtracted from:

Profile

Level 2 Lower Center Upper ---------+---------+---------+---------+

Hardware -4.289 -0.811 2.666 (-------------*-------------)

Network -2.621 -0.491 1.638 (-------*--------)

Software -3.391 -0.856 1.678 (----------*---------)

---------+---------+---------+---------+

-2.5 0.0 2.5 5.0

Profile Level 2 = Hardware subtracted from:

Profile


Network -3.568 0.320 4.208 (--------------*---------------)

Software -4.169 -0.045 4.079 (----------------*---------------)

---------+---------+---------+---------+

-2.5 0.0 2.5 5.0



Profile Level 2 = Network subtracted from:

Profile


Software -3.439 -0.365 2.709 (------------*-----------)

---------+---------+---------+---------+

-2.5 0.0 2.5 5.0

Gráfico 4.1.14-1 Grafico de cajas de problemas (RT) por perfil del ticket – 07 - ANOVA

SoftwareNetworkHardwareEngineering AppsCSC SupportedAccount

2

1

0

-1

-2

-3

Profile Level 2

Joh

nso

n

Boxplot of Johnson



Gráfico 4.1.14-2 Gráfica de Residuos problemas (RT) por perfil del ticket -07- ANOVA

210-1-2

99

90

50

10

1

Residual

Pe

rce

nt

0.20.0-0.2-0.4-0.6

2

1

0

-1

-2

Fitted Value

Re

sid

ua

l

210-1-2

4.8

3.6

2.4

1.2

0.0

Residual

Fre

qu

en

cy

2624222018161412108642

2

1

0

-1

-2

Observation Order

Re

sid

ua

l




Test de varianzas iguales: Tiempo de respuesta de problemas vs perfil del ticket – 2007

95% Bonferroni confidence intervals for standard deviations

Profile Level 2 N Lower StDev Upper

Account 3 0.042418 0.09764 1.379

CSC Supported 3 0.325536 0.74932 10.584

Engineering Apps 15 0.679197 1.01587 1.883

Hardware 1 * * *

Network 3 0.340344 0.78341 11.065

Software 2 0.979215 2.74869 438.624




Test statistic = 4.31, p-value = 0.011 Por lo que concluimos que aunque el análisis de varianza (ANOVA) obtuvimos un P > 0,05 pero en el test de varianzas de iguales de Bartlett vemos que p-value es menor que 0,05 por ende rechazamos la Ho. También en los gráficos de residuos (residual vs. fitted value) observamos que se alternan entre el cero pero existen ciertas concentraciones de los mismos superando el intervalo [-2,2] no reflejando una distribución aleatoria de los mismos. En cuando a la distribución de residuos vemos que se asemeja a un comportamiento normal con una distribución de observaciones aleatorias.



Este implicaría realizar un ANOVA no balanceado o de varianzas no iguales, que no lo desarrollaremos aquí debido a su complejidad para poder determinar que factor es el que esta desequilibrando el ANOVA. El gráfico siguiente muestra que la perfil del ticket ―Software‖ es el que tiene mayor amplitud y que a priori podría ser una de varianzas que introducen las variaciones mayores.


Software

Network

Hardware

Engineering Apps

CSC Supported

Account

5004003002001000

Pro

file

Le

ve

l 2


Test Statistic 10.00

P-Value 0.040

Test Statistic 4.31

P-Value 0.011

Bartlett's Test

Levene's Test




4.1.15. Conclusiones del análisis de variabilidad de factores por año

Los análisis realizados de problemas y factores respecto al tiempo de resolución (RT), de los años 2005 y 2007, tienen como fin encontrar, a priori, si entre los miembros de IT que resuelven los problemas, perfiles o tipo de tickets existen diferencias. Para RT del 2005 perfil de ticket el P es de 0.515 y el test de varianzas de Bartlett p value = 0.308, se acepta la H0. (Homogeneidad de varianzas) Para RT del 2007 perfil de tickets el P es de 0.698 y el test de varianzas de Bartlett p value = 0.040, se rechaza la H0. (Heterogeneidad de varianzas) Para RT del 2005 miembros de IT el P es de 0.160 y el test de varianzas de Bartlett p value = 0.033, se rechaza la H0.(Heterogeneidad de varianzas) Para RT del 2007 miembros de IT el P es de 0.105 y el test de varianzas de Bartlett p value = 0.913, se acepta la H0. (Homogeneidad de varianzas) En el caso del 2007 RT vs perfil de tickets y el caso del 2005 RT vs miembros de IT donde alfa 0.05 es mayor que el P-value del test de varianzas se rechaza la H0. En los casos en que se rechaza la Ho es debido a que no cumple con el test de varianzas iguales que se debería hacer un análisis de estadístico de varianzas que contemple el modelo no equilibrado o de varianzas heterogéneas. Estos análisis estadísticos del modelo de varianzas heterogéneas de más de dos factores están fuera del alcance de esta tesis debido a su complejidad. Vemos que existen ciertos factores en cada uno de los test de rechazo que podría indicar que son las causas de los mismos pero sería necesario la verificación teórica.



4.2. Conclusiones de la fase de análisis de oportunidades

En la fase de análisis de datos se han realizado cálculos estadísticos que permitieron comprobar el comportamiento de las variables en cuanto a su estabilidad y capacidad. Los resultados obtenidos sirven de base para comenzar con la fase siguiente, de mejora de la performance. La confiabilidad y reproducibilidad de resultados son las principales preocupaciones en los procesos. Ha quedado demostrado, en el caso de estudio tratado aquí, que estas condiciones se mantienen al haber analizado estadísticamente los datos relacionados a tickets de servicios y de problemas por 3 años consecutivos demostrando que los procesos se encuentran bajo dentro de los limites de control, estables y capaces. Estas condiciones permiten avanzar un paso más y poder guiar el enfoque hacia la búsqueda de definiciones claras de las métricas. Las mismas serán incluidas dentro del sistema de medición, que además abarca las condiciones, responsables, gráficos de control, variables significativas, definiciones de indicadores que reflejen las métricas seleccionadas de acuerdo a las necesidades del negocio, entre otras. Esto genera un preciso nivel de indicadores de actuación del área, que lo hace comparable con otras unidades de negocios o empresas. Respecto a las métricas podemos asentar que los mayores esfuerzos están siendo validados sólo en las empresas de USA, relacionadas con los sistemas financieros y de contabilidad, a causa de Sarbanes-Oxley Act72 y otras reglamentaciones o normativas internacionales mencionadas anteriormente. No es usual encontrar estos niveles de diligencia en otros sistemas de métricas de los negocios o empresas. La idea básica detrás de un Balanced ScoreCard (BSC) es la de proveer a la gerencia de una perspectiva nítida de los aspectos del negocio, además de focalizar en el establecimiento de métricas claras y quiénes son los responsables de las mismas. En cuanto a las herramientas del control estadístico de procesos o SPC (Statistical

Process Control) que permiten recopilar y monitorear los resultados, y que están encaminadas a la mejora de los mismos, se distingue que:

Las cartas de control están siendo cada vez más utilizadas, señalando cómo los

gerentes buscan entender profundamente la performance o actuación del negocio y cómo deben invertir en los recursos cada vez más escasos.

Los gráficos de Pareto se presentan como una herramienta efectiva para visualizar donde deben ser concentrados los esfuerzos para lograr el mayor retorno sobre la inversión (ROI).

Los diagramas de causa-efecto, conocidos comúnmente como diagramas de espina de pescado (Fishbone) o de Ishikawa73, son usados por los miembros del

72

Sarbanes-Oxley Act [en línea]. Disponible en Internet: http://fl1.findlaw.com/news.findlaw.com/hdocs/docs/gwbush/sarbanesoxley072302.pdf [Consulta: 25 de Febrero del 2008] 73

Diagrama de Ishikawa [en línea]. Disponible en Internet: http://es.wikipedia.org/wiki/Diagrama_de_Ishikawa [Consulta: 25 de Febrero del 2008]

http://fl1.findlaw.com/news.findlaw.com/hdocs/docs/gwbush/sarbanesoxley072302.pdf

http://es.wikipedia.org/wiki/Diagrama_de_Ishikawa



management, enfocándose en su análisis y representación (cause effect analysis or diagrams) para entender las relaciones entre indicadores que pueden predecir (leading) y aquellos que reportan que algo sucedió (lagging). Posibilitando la creación de un portafolio balanceado de indicadores que les permita entender cuáles son aquellos claves de la actuación.



5. MEJORA DE LA PERFORMANCE O ACTUACIÓN

Esta es la etapa en que las empresas tratan de reducir las mayores fuentes de variación y redirigir el proceso. Durante esta etapa de implementación de Six Sigma: - Se identifican las variables de entrada críticas, y se determina su tolerancia. - La media del proceso es redirigida. - Se reduce la variación del proceso. - Se mejora la invulnerabilidad del proceso a las variaciones. A continuación se presenta un esquema que resume las características generales de esta etapa.

Gráfico 5-1 Mejora de la performance

Una vez identificadas y verificadas las causas raíces de los problemas en los procesos, deben proponerse posibles soluciones. Existen cuantiosas formas de generar ideas para mejorar y se puede usar una gran variedad de ellas para dar impulso a la creatividad. Antes de emprender la fase de mejora correspondiente al proyecto DMAIC, se centró la atención en herramientas analíticas y lógicas, y procesos para medir y analizar la performance. Sin embargo, pensar en soluciones novedosas requiere una manera diferente de operar las capacidades cognitivas, se necesita ser lo más creativo posible durante la fase de generación de soluciones.



Para promover la creatividad se pueden poner en práctica diferentes técnicas que ayudan a pensar fuera de los esquemas clásicos, es decir, a traspasar los paradigmas, considerando diversas perspectivas, y que terminarán por generar una visión mucho más amplia de los problemas. En el esquema que se presenta a continuación se listan algunas técnicas, que no son mutuamente excluyentes, por tanto se pueden utilizar en conjunto o combinaciones de ellas para maximizar el número de soluciones propuestas.

Gráfico 5-2 Herramientas para generar ideas sobre mejoras

Para comenzar con la fase de mejora de la performance o actuación, se han investigado las referencias de estándares y modelos como CObIT, ITIL, CMMI, ISO 20000, ISO 27000, BSC, construcción de TC y otras documentaciones relacionadas con la IT, con el fin de contar con definiciones claras y marcos de las mejores prácticas al respecto. Con ello se logra una base adecuada y sostenidos fundamentos para alcanzar el objetivo final, que es la determinación de instrumentos de control para la gestión integrada en el área de IT. Al aplicar el torbellino de ideas (brainstorming) se comprobó que la recopilación de esta información era básica para avanzar en el formato base (template) de definición de métricas. También para la definición de algunas contempladas en el acuerdo de servicios de Argentina y su integración a un TC o dashboard gerencial de las mismas. Como la compañía en la que se desarrolla el presente trabajo se ha alineado a los procesos de ITIL, en el corriente año (2008), se profundizarán sus respectivas versiones 2 y 3. De hecho, en Febrero del 2008 se hizo el reemplazo del sistema de Help Desk



Global por uno basado en los lineamientos de ITIL. De allí también se extraerán las mejores prácticas (Best Practices) como así también benchmarking con otras empresas. De todas formas, existen mapeos y relaciones equivalentes entre ITIL, CObIT, ISO 1779974. Se destaca que en ITIL V3 75 se incorpora el proceso de mejora de los 7 pasos, el cual cubre las etapas requeridas para la recolección de datos, el análisis para identificar tendencias y problemas, la presentación de información a la gerencia para su priorización y acuerdo, y la implementación de mejoras. Cada etapa es conducida por las metas estratégicas, tácticas y operacionales definidas durante el diseño del servicio.

5.1. Proceso de mejora de 7 pasos (ITIL V3)

En lo que sigue se explican los distintos pasos del proceso de mejora propuesto en ITIL:

Paso 1 - Definir que debería medirse

Debería ser definido un conjunto de métricas que de soporte total a las metas de la organización. El foco debería estar en identificar lo necesario para satisfacer las metas completamente, sin considerar si el dato o información están actualmente disponibles.

Paso 2 - Definir qué puede medirse

Las organizaciones deben ser conscientes de sus limitaciones, respecto a lo que pueden medir, y esto es útil para reconocer que existen esas diferencias o brechas y para evaluar los riesgos podrían involucrar en el resultado.

Un análisis de diferencias (Gap Analysis) debe ser conducido entre lo que puede medirse y lo idealmente requerido. Las disparidades e implicancias pueden entonces ser reportadas al negocio, los clientes y la gerencia de la IT, para la adecuación correspondiente en alguna etapa.

Paso 3 – Colectar datos

Este es el paso de monitoreo y recolección de datos. Una combinación de herramientas de control y de procesos manuales debería ser puesta para colectar los datos que se necesitan para las métricas definidas.

74

IT GOVERNANCE INSTITUTE. 2005. ―Aligning CoBIT, ITIL & ISO 17799 for Business Benefit: Management Summary.‖ [en línea]. Disponible en Internet: http://www.itgi.org [Consulta: 25 de Febrero del 2008] 75

ITSMF. ―An Introductory. Overview of ITIL. ®. V3‖. 2007‖ [en línea]. Disponible en Internet: www.itsmf.si/Shared%20Documents/itSMF_ITILV3_Intro_Overview.pdf [Consulta: 02 de Junio del 2008]


http://www.itsmf.si/Shared%20Documents/itSMF_ITILV3_Intro_Overview.pdf



La calidad es el objetivo clave del monitoreo, por lo tanto este ayuda a enfocarse en la efectividad de un servicio, proceso, herramienta, organización o elemento de configuración. Se pone énfasis en identificar donde pueden ser realizadas o introducidas las mejoras, en el nivel de servicio existente, en la performance o actuación de la IT, típicamente detectando excepciones y resoluciones. La mejora continua del servicio (Continual Service Improvement, CSI) no está interesada en las excepciones. Si un acuerdo de nivel de servicios (Service Level Agreement, SLA) es consistentemente cumplido en el tiempo, la CSI se destinará a determinar si el nivel de performance puede ser sustentable a bajos costos o si este necesita ser actualizado a un mayor o mejor nivel de actuación.

Paso 4- Procesar datos

Los datos obtenidos son procesados al formato requerido, típicamente dándole la perspectiva en la actuación de los servicios o procesos. El procesamiento de datos es una importante actividad de la CSI, aunque es frecuentemente omitida. Mientras el monitoreo y la recolección de datos en un componente de infraestructura simple son importantes, la anterior es clave para entender los impactos de los componentes dentro de una mayor infraestructura de servicio de la IT.

Paso 5- Analizar datos

El análisis de los datos transforma la información en conocimiento de los eventos que están afectando a la organización. Una vez que el dato es procesado a información, el resultado puede ser analizado para responder preguntas tales como: ¿Se están cumpliendo los objetivos? ¿Existe alguna tendencia clara? ¿Existen las acciones correctivas requeridas? ¿Cuál es el costo?

Paso 6- Presentar y usar la información

El conocimiento adquirido puede ahora ser presentado en un formato que sea fácil de entender y que permita a los que reciben la información tomar decisiones estratégicas, tácticas y operacionales. La información necesita ser provista al correcto nivel y de forma apropiada, enfocada a la audiencia que la recibirá. Esto debería proveer valor, notar excepciones al servicio y resaltar cualquier beneficio que haya sido identificado durante cierto período de tiempo. Ahora más que nunca, la IT debería invertir tiempo para entender las metas específicas del negocio y trasladarlas a métricas de su área, para reflejar su impacto en tales metas. Frecuentemente existe diferencia entre lo que este área reporta y lo que es de interés para el negocio. Aunque la mayoría de los reportes tienden a concentrarse en problemas de performance pobre, pero también las buenas noticias deben ser tenidas en



cuenta. Un reporte que exhiba las tendencias de mejora en los servicios de la IT es el mejor vehículo de mercadotecnia.

Paso 7- Implementar acciones correctivas

El conocimiento adquirido es usado para optimizar, mejorar y corregir servicios, procesos y todo otro tipo de actividades de soporte y tecnología. Las acciones correctivas requeridas para la mejora del servicio deberían ser identificadas y comunicadas a la organización. La CSI identificará muchas oportunidades para la mejora continua y una organización la debe priorizar basándose en sus objetivos, recursos y fondos disponibles.

La mejora continua de 7 pasos se convierte así en un círculo de calidad continuo, donde se hace una y otra vez el recorrido por cada uno de los pasos. Existen cuatro razones básicas para el monitoreo y medición, a saber:

Validar las decisiones que han sido tomadas previamente.

Dirigir las actividades para lograr los objetivos deseados, esta es la razón que más prevalece para sustentar el monitoreo y medición.

Justificar el curso de acción requerido, con evidencia real o pruebas.

Intervenir en el momento apropiado y tomar las acciones correctivas.

Gráfico 5.1-1 Proceso de mejora de 7 pasos (ITIL V3)

Publicado por ITIL V3



Para soporte de las actividades de CSI existen tres tipos de métricas fundamentales que las organizaciones necesitan recolectar de los procesos:

Métricas tecnológicas: frecuentemente asociadas con componentes y

aplicaciones basadas en métricas tales como actuación y disponibilidad.

Métricas de procesos: capturadas en forma de factores críticos de éxito

(Critical Success Factors, CSFs), indicadores claves de performance (Key Perfomance Indicators, KPIs) y otras métricas de actividades.

Métricas de servicios: resultado del servicio de principio a fin (end-to-end).

Métricas de componentes o tecnología son usadas para computar las pertinentes a servicios.

5.2. Compromiso de decisiones basadas en datos (Six Sigma)

Los proyectos de Six Sigma, donde eran validadas las mejoras de los procesos y ahorros con métodos estadísticos, eran el núcleo que hacía a esta metodología diferente y poderosa. Si las organizaciones desean un verdadero éxito del programa de mejora continua necesitan hacer énfasis en las decisiones basadas en datos. De acuerdo a la teoría organizacional enfocada por los autores French y Raven, se puede decir que las bases del poder social en las organizaciones derivan de tres fuentes: autoridad, carisma y conocimiento. Sin embargo, hay autores que han postulado algunas fuentes diferentes76. La metodología Six Sigma propone un acercamiento más participativo hacia la gerencia.

5.2.1. Diferentes métodos de toma de decisiones

En cuanto a la manera en que se lleva a cabo la toma de decisiones, la mayoría de los autores proponen cuatro categorías diferentes: tradicional, autoritaria, intuitiva y científica. Tradicional: toma de decisiones basada en la forma habitual de hacer las cosas, como han sido realizadas anteriormente. El modo queda codificado en procedimientos, estándares, regulaciones y doctrinas. Esto se vuelve inconsciente, es más fácil seguir las reglas establecidas que cuestionarlas, y aparece como un mecanismo natural para disminuir el stress y hacer uso eficiente de los recursos de las organizaciones. A veces los procesos tradicionales y conocimientos codificados son necesarios y poderosos, sin embargo, no siempre es así. En algún momento alguien puede encontrar ―una mejor forma‖ para conducir los negocios y resolver problemas. En estas

76

Wikipedia. ―Power Philosophy‖.[en línea]. Disponible en Internet: http://en.wikipedia.org/wiki/Power_(sociology)#Types_and_sources_of_power [Consulta: 02 de Junio del 2008]

http://en.wikipedia.org/wiki/Power_(sociology)#Types_and_sources_of_power



situaciones es donde las iniciativas de Six Sigma deberían de ser usadas como desafío para repensar, rediseñar y mejorar. Autoritaria: a diferencia del poder derivado del carisma o conocimiento, la toma de decisiones autoritaria se basa en el poder inherente a determinada posición jerárquica. Las decisiones autoritarias provienen de los puestos de dirección y son necesarias para que una moderna burocracia pueda funcionar correctamente. Sin embargo, es recomendada una gestión participativa de los empleados en todos los niveles de la organización. Según el profesor de negocios Edward Lawler, Six Sigma conlleva una gestión de este tipo. Así los equipos de Six Sigma utilizan la experiencia de los miembros de la organización junto con las perspectivas de las autoridades. Intuitiva: esta incluye muchas estrategias no estructuradas para la toma de decisiones,

algunas como prueba y error, predicción y experiencia. La mayoría de las personas que toman decisiones rápidas se basan en experiencias previas usando ambos razonamientos: deductivo e inductivo. Sin embargo, se requiere más que la propia intuición para un proyecto de mejora. Tanto la intuición como la experiencia acerca de las causas raíces y soluciones son aceptables solamente si las personas que toman las decisiones quieren hacer un mero balance con los datos disponibles. Científica: la toma de decisión incluye un acercamiento analítico y de ingeniería, en

donde el método científico y los planteos acerca de calidad ayudan a crear modelos matemáticos de problemas. El testeo del método científico induce y deriva en hipótesis y datos empíricos, y por su lado la calidad ayuda a combinar elementos analíticos y científicos en la metodología centrada en los datos. Los datos que se manejan pueden ser mejorados implementando procesos estadísticos de cálculo y control, obteniendo una mejor información, como muestra el gráfico 5.2.1-1. El flujo puede ser pensado de una forma simplificada:

Datos Información Gráficos Toma de decisiones

Gráfico 5.2.1-1 Diagrama de flujo de toma de decisiones basada en datos

Publicado por iSix Sigma

77

77

iSix Sigma.‖ Renew the Commitment to Data-Based Decision Making‖. [en línea]. Disponible en Internet: http://www.isixsigma.com/library/content/c070514a.asp?action=print [Consulta: 02 de Junio del 2008]

http://www.isixsigma.com/library/content/c070514a.asp?action=print



Esencialmente, la decisión basada en datos involucra utilizar gráficos de información para tomar mejores decisiones. Específicamente, la forma de las distribuciones resultantes, el establecimiento de probabilidades y los límites son lo que finalmente habilitan las decisiones.

5.3. Aplicación de indicadores para medición y análisis (SEI-CMMI)

Las organizaciones frecuentemente no alcanzan los beneficios potenciales de un programa o plan de mediciones debido a la inconsistencia que existe entre la construcción y la interpretación de los indicadores derivados de los datos medidos. El Software Engineering Institute (SEI) se ha dedicado a describir precisamente los indicadores, incluyendo su construcción, correcta interpretación y utilización para la recolección de datos y su presentación, en los procesos de medición y análisis. Un modelo, guía patrón o plantilla (template) puede ayudar a un negocio a definir indicadores y realizar representaciones graficas de las datos medidos, los cuales describen quién, qué, dónde, cuándo, porqué (conocidas como las 5 preguntas del porque o 5 W Questions); y cómo analizar y recolectar las medidas. Este también describe el uso del indicador dentro del contexto de la metodología Goal-Question-Indicator-Measurement (GQIM) y del marco de trabajo del modelo de Capability Maturity Model Integration (CMMI).

5.3.1. Errores frecuentes en los planes de medición

El desafío de este tipo de planes es potenciar los procesos de medición y análisis establecidos, tratando de no cometer los errores frecuentes, conocidos como pitfalls, que son dificultades no previstas. Aquí se listan algunos de ellos:

Analizar perdiendo de vista lo global (big picture).

Los gráficos son complejos pero sin significados relevantes.

Los gráficos y/o indicadores fueron mal interpretados.

Definiciones inconsistentes de mediciones y elementos de datos que son usados.

Incomprensión del contexto de los indicadores.

Conjunto de datos con información imprecisa.

No existe una línea base o benchmarking para comparar la actuación actual.



Actividades poco frecuentes o ineficientes de integridad de datos.

Procesos de comparación y predicción de resultados que no aseguran la estabilidad de los procesos.

La consecuencia de estos problemas puede ser significativa, por ejemplo un gráfico que luce complejo podría carecer de fundamentos, no estar soportado en tiempo real o no tener en cuenta decisiones de análisis de proyectos anteriores. Y aún peor, pueden reflejar posiciones, tendencias y predicciones no reales, que crean interpretaciones erróneas, obstaculizando comparaciones con la actuación histórica. El SEI ha trabajado con diferentes organizaciones, y algunas llegaron a descartar hasta el 70 % de su conjunto de datos para reemplazarlos por uno nuevo y válido. Las actividades de medición y análisis del área de procesos del CMMI se han representado en el gráfico 5.3.1-1, donde se resaltan el plan de mediciones, indicadores, repositorio, procedimientos y herramientas como los activos principales del proceso de medición y análisis.

Gráfico 5.3.1-1 CMMI - Actividades de mediciones y análisis de procesos

Publicado por SEI - CMMI78

78

SEI. 2004. ―Applications of the Indicator Template for Measurement and Analysis‖.[en línea]. Disponible en Internet: http://www.sei.cmu.edu/publications/documents/04.reports/04tn024.html [Consulta: 07 de Junio del 2008]

http://www.sei.cmu.edu/publications/documents/04.reports/04tn024.html



La medición y análisis de las áreas de proceso involucra las siguientes prácticas:

Especificar los objetivos de medición y análisis, tales que estén alineados con la necesidad de información identificada y con los objetivos del negocio.

Especificar las mediciones, recolección de datos y mecanismos de almacenamiento, técnicas de análisis y reporte, como también aquellos de retroalimentación.

Implementar la recolección, almacenamiento, análisis y reporte de datos.

Proveer de resultados objetivos que puedan ser usados en la toma de decisiones basada en la información, tomando las acciones correctivas apropiadas.

A su vez, es posible mapear cada una de estas prácticas de mediciones del CMMI con la plantilla de un indicador, resultando la cobertura de cada una de ellas en el mismo.

5.3.2. Guía o plantilla de un indicador según SEI - CMMI

En el gráfico siguiente se reflejan las mediciones dentro de la plantilla propuesta.

Gráfico 5.3.2-1 Mapeo de las actividades de medición del CMMI

Publicado por SEI – CMMI72



En lo que sigue, se aclara el significado de cada campo de la plantilla del indicador:

Objetivo del indicador: es el propósito del indicador.

Preguntas: aquellas que el usuario del indicador está tratando de responder.

Gráfico: una vista o representación esquemática del indicador.

Perspectiva o punto de vista: descripción de la audiencia a la cual está

orientada el indicador.

Entradas: listas de mediciones requeridas para construir el indicador, junto con

su definición.

Algoritmos: usados para la construcción del indicador a partir de las mediciones.

Supuestos: acerca de la organización, sus procesos, modelo de ciclo de vida,

entre otras importantes condiciones para la colección y uso del indicador.

Información de método de colección: información pertinente a cómo, cuándo,

con qué frecuencia y por quién son colectados los datos requeridos para la construcción del indicador.

Información de método de reporte: información de quién es responsable de

reportar los datos, para quién y con qué frecuencia.

Almacenamiento de los datos: información sobre el almacenamiento, forma de

recupero y seguridad de los datos.

Análisis e interpretación de los resultados: información sobre cómo analizar e interpretar el indicador.

Datos extras: más allá de su estructura básica, cada organización puede

profundizar más detalles o amoldarlos a su ambiente, tales como guía de acciones preventivas y correctivas.

5.4. Medición del desempeño organizacional (BS - CMMI)

Se aplicarán las recomendaciones realizadas por la comisión de investigación a la posición competitiva de la industria de Estados Unidos:

Desarrollar técnicas de medición y mejora de la eficiencia y calidad de los procesos de producción.

Identificar oportunidades para mejoras progresivas.

Desarrollar nuevas mediciones o indicadores de costo, calidad y entrega A fin de entender el significado de la medición del desempeño (Performance Measurement 79) se explicará en más detalle la terminología relacionada: Rendimiento del objetivo: nivel objetivo de una actividad, expresado tangible y mesurablemente contra el progreso real, que sea comparable.

79

GORE, A. 1997. ―Serving the American Public: Best Practices in Performance Measurement‖.1997.[en línea]. Disponible en: http://govinfo.library.unt.edu/npr/library/papers/benchmrk/nprbook.html [Consulta: 07 de Junio del 2008]



Gestión del rendimiento: el uso de la medición del desempeño de la información para ayudar a establecer objetivos, asignar recursos y prioridades, informar a los administradores para que puedan confirmar o modificar la política actual o programa de direcciones para alcanzar tales objetivos, e informar sobre el éxito en su cumplimiento. Medidas de la ejecución: aquellas cuantitativas o cualitativas de la caracterización del rendimiento. Medición del desempeño (Performance Measurement): proceso de evaluación de los

progresos hacia el logro de metas predeterminadas, incluida la información sobre la eficiencia con que los recursos se transforman en bienes y servicios (productos), la calidad de estos y resultados (correspondientes a un programa de actividad en comparación con su finalidad), y la eficacia de las operaciones en términos de sus contribuciones específicas a los objetivos del programa. Existen 7 pasos para desarrollar y usar la medición del desempeño80

Vincular los procesos de ingeniería de la organización con los objetivos.

Desarrollar medidas de ejecución.

Recolectar datos, analizar y presentar informes y procedimientos.

Integrar el empleo de medidas de desempeño con la gestión de procesos.

Establecer una línea base para comparar el rendimiento futuro.

Recoger, analizar e informar los resultados.

Evaluar la utilidad de la medición del desempeño y mejorar. En la representación de la pirámide de atención de la gerencia representada en el siguiente gráfico, se observa en el ápice la visión de la organización que termina en una base de indicadores de calidad, entrega, tiempo del ciclo de producción y desperdicios.

80 ISO 15939. " Proceso medición del software" [en línea]. Disponible en Internet: http://www.psmsc.com/ISO.asp [Consulta: 07 de Junio del 2008]

http://www.psmsc.com/ISO.asp



Gráfico 5.4-1 ¿Cómo son generados y usados los datos?

En el diagrama siguiente muestra ejemplos de indicadores de un BSC, considerados importantes para cada una de las perspectivas.

Gráfico 5.4-2 Ejemplo de indicadores incluidos en un BSC



5.4.1. Plan de desempeño de indicadores (Measurement Plan – MP)

Propósito: el MP tiene por objetivo definir en un documento todos los indicadores

recogidos en la organización o área de negocios. Estas definiciones se proporcionan con el fin de evitar ambigüedades y tener una sola definición de cada uno de ellos, que permita fijar una línea base y realizar un benchmarking con otras unidades del negocio u organizaciones. Para ello, la organización debe definir un grupo de gobierno sobre un grupo de métricas (recursos destinados a esta actividad), que se espera coordinar para las actividades relacionadas con la recopilación y presentación de estos indicadores, como se ha llevado a cabo hasta la fecha de la próxima revisión de este documento. Cualquier métrica o indicador que requiera específicamente adaptarse, deberá incorporar la modificación de la definición existente si es un reemplazo, o la creación de nuevas métricas de ser necesario, ellas deberían reflejarse en el MP. Por lo tanto este documento es una norma fundamental para la evolución de los indicadores. El grupo de gobierno de la organización tendrá injerencia sobre el grupo de métricas por las aclaraciones, actualizaciones y seguimiento de todos los aspectos relacionados con cada indicador. Alcance: conjunto herramientas en donde las métricas oficiales son definidas, como así

también su recopilación, y presentación de informes usando templates e información predefinida para cada una de ellas. Las métricas expresadas aquí deben tener un proceso definido de recolección, almacenamiento y, si fuera necesario, herramientas automatizadas asociadas.

5.4.2. Formato sugerido para el cálculo de un indicador

Una detallada descripción del indicador o métrica debe incluir al menos los siguientes elementos o ítems:



Elemento Descripción

Nombre del indicador

Identifica la métrica.

Propósito/Objetivo Describe la métrica y su aplicación.

Fuente de entrada Almacenamiento de datos usados como parámetros de entrada para el cálculo de la métrica.

Definición de entradas

Descripción de cada parámetro de entrada usado para el cálculo de la métrica.

Fórmula Expresión matemática para calcular la métrica.

Objetivo Performance o meta deseada para determinado plazo de tiempo.

Responsable de la colección

Rol o individuo designado para recolectar las métricas.

Herramienta para la colección

Mecanismo utilizado en la recolección. Son obligatorias las herramientas recomendadas.

Repositorio de datos

Almacenaje de datos de las métricas.

Período de reporte Frecuencia para reportar la métrica.

Ejemplo de reporte

Muestra de las métricas en una tabla. Se deben graficar las métricas y sus primeras derivadas, como entradas para el análisis de tendencias.

Criterio de colección de

datos

Definir las reglas que determinan la recuperación de datos para calcular las métricas, esto es, especificar bajo qué condiciones los datos de entrada serán tomados en cuenta o descartados.

Análisis Enfoque de análisis de las métricas.

Mapeo con

normas o reglamentaciones

vigentes

Opcional - Aquí se define con que parte de normas o

reglamentaciones exigibles este indicador está orientado.

Datos históricos Opcional - Gráficos del indicador del pasado año o historia mínima requerida dentro de la organización.

Para mayor detalle de la plantilla propuesta por el SEI puede referirse al apéndice18.



5.4.3. Ejemplos de representación de un indicador o métrica

A continuación se proponen algunos ejemplos de cómo deberían definirse en el MP los indicadores que componen el mismo según el template propuesto.

Tabla 5.4.3-1 Métrica: Encuesta de satisfacción al cliente por incidentes

Versión: 1.00 Fecha: 18 Febrero, 2008


Encuesta de satisfacción al cliente por incidentes (Incidents Customer Satisfaction Survey - ICSS)

Propósito u objetivo

Mejorar la percepción que se tiene de los servicios brindados por la IT, relacionados con el desempeño de la comunicación, dominio de conocimientos, manejo de proyectos y resolución de incidentes. Proveer un resultado de satisfacción promedio que pueda ser mostrado organizacionalmente con tendencias y efectividad de iniciativas de soporte hacia las necesidades de los clientes o usuarios finales.

Fuente de entrada

La CSS será provista al usuario final automáticamente cada vez que un incidente del sistema de servicio de mesa de ayuda es pasado al estado de resuelto. BMC – Sistema de Mesa de Ayuda.


Satisfecho. No satisfecho. No completa. (Pasará a este estado automáticamente cuando no

se tenga respuesta durante los 30 días subsiguientes al envío de la CSS). A las encuestas cerradas como ―no completa‖ se considerará que el servicio brindado satisfizo al usuario final computándose las mismas como satisfechas.

Fórmula Satisfacción del cliente % = [(Sumatoria de las encuestas en todos los estados) - (Sumatoria de las encuestas con respuesta No satisfecho)]*100 / (Sumatoria del total de encuestas).

Objetivo Valor mayor o igual al 90 %.


Gerente de servicios y entrega de la IT del sitio.

Audiencia Gerencia del negocio, usuarios finales y gerencia de IT (niveles regionales).

Herramienta para la

colección

BMC – Sistema de Mesa de Ayuda – Software de generación de reportes llamado Cristal Report. Generación automática del reporte

y envío por correo del mismo semanalmente. Posibilidad de generación manual en el momento requerido.


Servidor BMC.COM, base de datos de incidentes de BMC.

Almacenamiento y respaldo

Servidor BMC.COM, base de datos Oracle de BMC, backup de

acuerdo a las políticas de respaldo vigentes.

Período de reporte

A nivel interno de la IT: Semanalmente (Semanal y acumulado

anual. Se utilizará número de semana calendario anual). Nivel Organizacional: Mensualmente el acumulado del año calendario



Ejemplo de reporte

Nota: Los gráficos deben ser generados

para la métrica o indicador y luego derivados como entrada para el

análisis de tendencias.

Criterio de colección

Mandatorio para todos los incidentes registrados en BMC.

Análisis 1. Se consulta al usuario final el porque de la no satisfacción cuando en la encuesta de CSS no está explícitamente escrito.

2. Existe un plan para medir y reportar las CSS y hacer el

seguimiento de problemas, inconvenientes o sugerencias con los usuarios finales.

3. Existe un compromiso en el plan para registrar el monitoreo de los resultados CSS y como se debe de actuar en

consecuencia. 4. Esta el promedio de los resultados de CSS afectando nuestra

habilidad para iniciar y sostener el servicio pactado en el acuerdo interno de servicio (SLA) con los clientes y los usuarios finales.

5. Existen acciones planeadas si el objetivo no es alcanzado.

Recomendación del método de análisis: comparar cada 4 meses o cuatrimestres del año con un gráfico de barras para ver o detectar tendencias y realizar acciones pertinentes para dejar el proceso bajo control estadístico y orientarlo al objetivo.

Mapeo CObIT: Dominio M1 Monitorear los procesos. Objetivo de control M1.3 Evaluar la satisfacción del cliente,

identificar déficit de servicios. Áreas claves 4.4.8 Satisfacción del cliente, encuestas y análisis. 4.5.2 Meeting de revisión de servicios. Entrega de servicios, gerenciamiento del nivel de servicio (SLA). ITIL: Soporte de servicios Gerenciamiento mesa de ayuda, manejo de incidentes. BSC: Punto de vista del cliente CMMI: Organizational Process Performance (OPP). GP.28, 2.9, 2.10 – Causal Analysis and Resolution (CAR).

Datos históricos





Tabla 5.4.3-2 Métrica: Costo de la no calidad

Versión:1.00 Fecha: 06 de Febrero, 2008


Costo de la pobre o no calidad Cost of Poor Quality (COPQ)


Para realizar el seguimiento de la cantidad de esfuerzo y recursos asociados con pobres resultados en materia de calidad. Esto incluye los costos para corregir los problemas descubiertos por el cliente después de su entrega, y los costos para corregir los defectos internos descubiertos durante el proceso de resolución. La no calidad aparece como costos adicionales en vano; e.g. pruebas adicionales, gastos de inspección para asegurar el cumplimiento de las especificaciones y sanciones por retraso en la entrega de elementos o sistemas que no cumplan con los niveles de aceptación especificados por los clientes.

Fuentes de entradas

EPMS Teamplay (Software Time Management) con intervalos mínimos de 30 minutos para su carga semanal de esfuerzos.


Falla del esfuerzo interno: como resultado del esfuerzo de incumplimiento a las normas de calidad y aquel asociado con la superación de los efectos de las fallas encontradas antes de que el producto o servicio llegue al cliente (incluida la re-verificación y re-revisión de los productos). Falla del esfuerzo externo: como resultado del esfuerzo de

incumplimiento a las normas de calidad y aquel asociado con la superación de los efectos de los fallos encontrados después de la liberación oficial del producto (incluida la re-verificación y re-revisión de los productos). Esfuerzo total: como resultado del esfuerzo de todas las actividades del proyecto, tal como se definen en el correspondiente a la estructura de desglose del trabajo (Work Breakdown Structure - WBS).

Fórmula Esfuerzo relacionado con fallas internas % = (Esfuerzo de fallas internas *100) / Esfuerzo total Esfuerzo relacionado con fallas externas % = (Esfuerzo de

fallas externas *100) / Esfuerzo total COPQ % = Esfuerzo de fallas internas % + Esfuerzo de fallas externas %

Objetivo Menor o igual al 5% del costo de la calidad (COQ)


Líder de proyecto. Coordinador de mesa de ayuda de la IT.

Audiencia Gerencia del negocio, usuarios finales y gerencia de la IT (niveles regionales).


EPMS Teamplay (Software Time Management) con intervalos

mínimos de 30 minutos para su carga semanal de esfuerzos.


Servidor EPMS, base de datos Oracle de EPMS, backup de


Período de reporte A nivel de proyecto: semanalmente en las reuniones de revisión. A nivel organizacional: mensualmente con reporte a la gerencia superior.



Ejemplo de reporte Nota: Los gráficos

deben ser generados para la métrica o indicador y luego

derivados como entrada para el análisis de

tendencias. Observation

In

div

idu

al

Va

lue

161412108642

10

5

0

_X=3.52

UC L=9.92

LC L=-2.89

Observation

Mo

vin

g R

an

ge

161412108642

8

6

4

2

0

__MR=2.409

UC L=7.870

LC L=0

I-MR Chart of COPQ

Almacenamiento y

respaldo

Servidor BMC.COM, base de datos Oracle de BMC, backup de acuerdo a las políticas de respaldo vigentes.


Obligatorio para todo clase de proyectos o actividades de soporte.

Análisis ¿Cuál es la contribución del costo de la no calidad a los costos de la calidad? Identificar las principales fuentes de la no calidad en el proceso de desarrollo de correlacionar a COPQ fases del proyecto o servicio.

Entender el costo de reparación de productos para realizar el seguimiento de las mejoras en el desarrollo y proceso de entrega. ¿Cómo se va avanzando hacia los objetivos de los costos de no calidad? Recomendado método de análisis: control estadístico de procesos a nivel de organización y ejecución del gráfico con los límites de control a nivel de proyecto.

Mapeo CObIT: Dominio PO1 Definir el plan estratégico de la IT. Objetivo de control PO1.7 Monitoreo y evaluación de los

planes de la IT. Áreas claves Retroalimentación en calidad y utilidad. Dominio PO11 Administrar la calidad. Objetivo de control PO11.18 Métricas de calidad. Áreas claves Medir el logro del objetivo de calidad. ITIL: Gerenciamiento de servicios de la IT (soporte y entrega) BSC: Punto de vista interno, del cliente y financiero. CMMI: Organizational Process Performance (OPP),

Organizational Innovation & Deployment (OID). GP 2.7, 2.10.



Tabla 5.4.3-3 Métrica: Costo de la calidad


Nombre del Indicador

Costo de la calidad Cost of Quality (COQ)


Mejorar de manera colectiva la acción de prevención, evaluación y corrección de fallas en los procesos, en lo que respecta a costo total del proyecto desde la perspectiva de la alta dirección.

Fuente de entradas

EPMS Teamplay (Software Time Management) con intervalos mínimos de 30 minutos para su carga semanal de esfuerzos.


Esfuerzo de evaluación: esfuerzo de primera vez de verificación, control, o evaluación de un producto o servicio durante la creación o el proceso de entrega para asegurar la conformidad con las normas de calidad y detectar posibles fallos insertados en el producto o servicio antes de llegar al cliente. Esfuerzo de Prevención: el esfuerzo que incurra para garantizar que

las fallas no se hacen en cualquier etapa durante la producción y el proceso de entrega del producto o servicio a un cliente. Falla del esfuerzo interno: como resultado del esfuerzo de

incumplimiento a las normas de calidad y el esfuerzo asociado con la superación de los efectos de las fallas encontradas antes de que el producto o servicio llegue al cliente (incluida la re-verificación y re-revisión de los productos). Falla del esfuerzo externo: como resultado del esfuerzo de

incumplimiento a las normas de calidad y aquel asociado con la superación de los efectos de los fallos encontrados después de la liberación oficial del producto (incluida la re-verificación y re-revisión de los productos). Esfuerzo total: como resultado del esfuerzo de todas las actividades

del proyecto, tal como se definen en el correspondiente a la estructura de desglose del trabajo (Work Breakdown Structure - WBS).

Fórmula Esfuerzo de evaluación % = (Esfuerzo de evaluación *100) / Esfuerzo total. Esfuerzo de prevención % = (Esfuerzo de prevención *100) / Esfuerzo

total. Esfuerzo relacionado con fallas internas % = (Esfuerzo de fallas

internas *100) / Esfuerzo total. Esfuerzo relacionado con fallas externas % = (Esfuerzo de fallas

externas *100) / Esfuerzo total. Costo de la calidad (COQ) = Esfuerzo de evaluación % + Esfuerzo de

prevención + Esfuerzo relacionado con fallas internas % + Esfuerzo relacionado con fallas externas % Nota 1: La expresión equivalente es COQ % = Esfuerzo de evaluación % + Esfuerzo de prevención % + COPQ %.

Objetivo No mayor al 30 % del esfuerzo total

Responsable Líder de proyecto. Coordinador de mesa de ayuda de la IT.



de la colección



EPMS Teamplay (Software Time Management) con intervalos mínimos

de 30 minutos para su carga semanal de esfuerzos.

Período de reporte

A nivel de proyecto: semanalmente en las reuniones de revisión. A nivel organizacional: mensualmente con reporte a la gerencia superior.

Ejemplo del reporte Nota: Los

gráficos deben ser generados

para la métrica o indicador y luego derivados como

entrada para análisis de tendencias.

Observation

In

div

idu

al

Va

lue

161412108642

80

60

40

20

0

_X=28.08

UC L=68.34

LC L=-12.18

Observation

Mo

vin

g R

an

ge

161412108642

48

36

24

12

0

__MR=15.14

UC L=49.46

LC L=0

I-MR Chart of COQ


Obligatorio para todo clase de proyectos o actividades de soporte.

Análisis Verificar si la reducción de costo total de calidad ofrece oportunidades para una mayor satisfacción al cliente, un aumento de beneficios y la disponibilidad y predisposición para la creación de nuevos negocios. ¿Cómo hacer para que el COQ impacte en actividades libre de errores productos o servicios? Relacionar que COQ informó en horas de personal, y/o porcentaje de los costos totales para procesos y la falta de datos (por ejemplo, la calidad total, la frecuencia de fallos). Incluir el COQ en el análisis de causa raíz. Analizar el impacto de las actividades COQ en la disponibilidad de recursos, productividad y proyecto o servicio teniendo en cuenta que estimación COQ informó en horas de personal (esfuerzo) y / o porcentaje de los costos totales. ¿Cuánto es el gasto en la revisión / actividades de inspección? ¿Cuánto se gastó en actividades de prueba o testeo? Recomendaciones para el método de análisis: Control estadístico de procesos. Controlar a nivel de organización y ejecutar el gráfico con los umbrales a nivel de proyecto. Cuando el umbral o límite de control es cruzado, se recomienda utilizar un gráfico de Pareto para identificar los principales temas a analizar.

Mapeo CObIT: Dominio PO1 Definir el plan estratégico de la IT. Objetivo de control PO1.7 Monitoreo y evaluación de los planes

de la IT. Áreas claves Retroalimentación en calidad y utilidad.



Dominio PO11 Administrar la calidad. Objetivo de control PO11.18 Métricas de calidad. Áreas claves Medir el logro del objetivo de calidad. ITIL: Gerenciamiento de servicios de la IT (soporte y entrega) BSC: Punto de vista interno, del cliente y financiero. CMMI: Organizational Process Performance (OPP),

Organizational Innovation & Deployment (OID). GP 2.7, 2.10.



Tabla 5.4.3-4 Métrica: Esfuerzo de entrenamiento



Esfuerzo de entrenamiento Training Effort (TE)


Registrar la cantidad de esfuerzo asociado a los entrenamientos.

Fuente de entradas

Asistencia de cursos, registros on line, de entrenamientos en línea.

Sistema de reporte de administración del tiempo. EPMS report


Esfuerzo: total de esfuerzo por participante en horas de personal. Programa de entrenamiento: todos los entrenamientos que están

incluidos en el calendario anual de centro correspondiente.

Fórmula Σ esfuerzos de entrenamiento por persona.

Objetivo Mayor o igual a 40 horas anuales.

Responsable de la

colección

Cada empleado deberá de registrar el entrenamiento recibido en el repositorio global de la compañía trainning.per.com Los gerentes de las áreas deberán de generar reportes de seguimientos mensuales para alcanzar el objetivo anual.

Herramientas de la

colección

trainning.per.com



Base de datos Oracle relacionada con el sitio trainning.per.com

Período de reporte

A nivel organizacional: anualmente con reporte a la gerencia superior. Se recomienda hacer un seguimiento de reporte mensual.

Ejemplo de reporte Nota: Los




Criterios de colección

Registro de terminación del entrenamiento mandatorio para todos los cursos obligatorios definidos por la compañía.

Análisis ¿El esfuerzo total de entrenamiento es mayor que al mes anterior? ¿Se está cumpliendo con el plan de entrenamiento pautado, existen desviaciones? ¿Está afectando el entrenamiento al rendimiento del empleado?



¿Existen evaluaciones del entrenamiento luego de su dictado? ¿Qué acciones surgen cuando no se cumple con las expectativas? ¿Se evalúa calidad, experiencia, capacidad y cumplimiento de los objetivos previamente acordados con el proveedor de los entrenamientos? Método de análisis recomendado: Run Charts usando límites definidos

por la gerencia si no existen límites de control para analizar tendencias, sino usar SPC. Análisis de causa raíz, gráficos de Pareto para segregación.

Mapeo CObIT: Dominio DS7 Educar y entrenar a los usuarios. Objetivo de control DS7.1 Identificación de las necesidades de entrenamiento. Áreas claves Plan de entrenamiento para cada grupo de empleados. Objetivo de control DS7.2 Entrenamiento organizacional. Áreas claves Identificar y notificar a los entrenadores y el cronograma de entrenamiento. Objetivo de control DS7.3 Entrenamiento sobre principios de

seguridad y prevención. Áreas claves Prácticas de seguridad. ITIL: Servicio de soporte: administración de incidentes y problemas

proactiva. Administración de seguridad: mediciones de la administración de la seguridad, implementación. ISO27000: Política de seguridad de la información.

Entrenamiento del usuario. Responsabilidades del usuario. Infraestructura de la seguridad de la información. Respuesta ante un incidente o mal función de seguridad. Protección en contra del software malicioso. Trabajo móvil y desde el hogar. Cumplimiento de normas legales. BSC: Aprendizaje y crecimiento. CMMI: Organizational Training (OT), Decision Analysis & Resolution

(DAR), Integrated Process & Product development (IPPD). GP 2.1, 2.10.



Tabla 5.4.3-5 Métrica: Tiempo de remoción de vulnerabilidades e incidentes de seguridad


Nombre del Indicador

Tiempo de remoción de vulnerabilidades e incidentes de seguridad

Vulnerabilities & Security Incidents Removal Time


Determinar el tiempo de respuesta de la remediación de vulnerabilidades e incidentes de seguridad, y así lograr tendencias que permitan mejorarlos de acuerdo a las necesidades del negocio.

Fuente de entradas

Reporte mensual del servicio de protección de la información (MIPS).

Reporte de escaneo de generación manual producido por el software FoundStone (escaneo de vulnerabilidades). Sistema de reporte de incidentes. Reportes de CERT.


Fecha de notificación: de la vulnerabilidad o incidente de seguridad

producido. La fecha de notificación debe registrarse y es necesariamente requerida como disparador para contar el tiempo transcurrido entre la notificación y la remediación. Fecha de remediación: en la cual se puede considerar que se

realizaron todas las actividades relacionadas para asegurar que el incidente o vulnerabilidad fueron removidos o exceptuados en el caso de ser necesario. La fecha de remediación debe registrarse y es necesariamente requerida para el cálculo del tiempo de remoción de vulnerabilidades o incidentes de seguridad. Puede ser obligatoria y determinada previamente por el negocio de acuerdo a su criticidad. * Un incidente de seguridad es el reporte de problemas con la seguridad de la información que produce una brecha dentro estos sistemas. ** Una vulnerabilidad es el reporte de un problema con una versión de software o de firmware que podría resultar o causar una brecha de

seguridad y por ende un incidente de seguridad en los sistemas de información de la organización.

*** Una excepción de seguridad es un reporte por el cual se notifica con justificativos técnicos u operativos porqué no se puede remover la vulnerabilidad, debido a restricciones del sistema para que opere u otras, que tienen un circuito de aprobación pertinente. Después de la aprobación la vulnerabilidad se considera exceptuada hasta la fecha de expiración de tal excepción.

Fórmula Tiempo de respuesta y remediación de una vulnerabilidad o incidente de seguridad: fecha de remediación de la vulnerabilidad o incidente i – fecha de notificación de la vulnerabilidad o incidente i o de excepción de seguridad i i = desde 1 hasta n n = número de incidentes o de vulnerabilidades Tiempo de respuesta: duración en días, entre la fecha de la primera



notificación y la fecha de remediación de la misma. Es el tiempo en días de la remoción de la brecha de seguridad en los sistemas afectados, los cuales pueden nuevamente operar de modo normal sin estar vulnerables. %Remoción de vulnerabilidades e incidentes críticos y altos: total

de vulnerabilidades e incidentes removidos o exceptuadas en el plazo de 30 días respecto del total reportado del mes.

Objetivo 80% de las vulnerabilidades removidas o exceptuadas dentro de los 30 días de recibir el reporte mensual de las mismas (100% de las críticas y altas). 100% de remoción de incidentes dentro del plazo determinado por el grupo de incidentes de seguridad. 90% de las vulnerabilidades removidas o exceptuadas en los plazos previstos dentro del CERT.

Nota: Se deberán de tratar de acuerdo a la criticidad de la mismas asignándoles prioridad de acuerdo a si es considerada crítica (10-9), alta (8-7), media (6-3) o baja (3-1).

Responsable de la

colección

Responsable de seguridad de la información del sitio.

Audiencia Gerencia del negocio, responsable de seguridad global, gerencia de la IT (niveles regionales).

Herramientas de colección

Reporte mensual de los servicio de seguridad de la información. Reporte de FoundScan después de removidas las vulnerabilidades e

incidentes. Reporte en Excel de las acciones tomadas con cada vulnerabilidad o

incidente correspondiente .


Sitio de seguridad de la información de la organización. Directorio de Seguridad, reportes mensuales en Excel

Período de reporte

A nivel organizacional: mensualmente con reporte a la gerencia superior.








Mandatorio para todos los dispositivos y softwares instalados dentro de la red de la compañía.

Análisis El reporte del tiempo de respuesta de remoción de vulnerabilidades e incidentes de seguridad identificará la capacidad del negocio de trabajar con la detección y remoción de estas, aplicando las soluciones correspondientes a tiempo. La tendencia será obtener la menor cantidad de vulnerabilidades e incidentes de acuerdo a la criticidad, como así también que el porcentaje de remoción de los mismos sea en un tiempo menor indica que el proceso está mejorando su capacidad. Aplicar el análisis de causa-efecto o raíz para identificar vulnerabilidades e incidentes que se vuelven a repetir en el reporte mensual para eliminar las causas de los mismos. ¿Se están logrando o superando las metas relacionadas con la remoción de vulnerabilidades e incidentes? ¿Se tiene conciencia del tiempo que toma cerrar las vulnerabilidades o incidentes? ¿Se generaron los pedidos de cambios correspondientes a la aplicación de parches de seguridad en los ítems de configuración y, fueron aprobados por el comité de revisión de cambios?

Mapeo CObIT: Dominio PO9 Valorar los riesgos. Objetivo de control PO9.2 Administración del riesgo. Áreas claves Administración orientada a la identificación de

vulnerabilidades y el riesgo de mitigación o solución, contar con las habilidades apropiadas. ITIL: Entrega de servicios: administración de continuidad del

negocio, modelo de análisis de riesgo. Plan de administración de riesgos. Administración de la disponibilidad. Administración de seguridad. ISO27000: 3.1 Política de seguridad de la información.



4.1 Infraestructura de la seguridad de la información. BSC: Procesos internos del negocio. CMMI: Decision Analysis & Resolution (DAR), Integrated Project

Management (IPM), Risk Management (RSKM), Quantitative Project Management (QPM).



Tabla 5.4.3-6 Métrica: Tiempo de resolución de incidentes en IT

Versión: 1.00 Fecha: 10 de Febrero, 2008


Tiempo de resolución de incidentes en IT Incidents Resolution Time inside IT = (RT-CH-VH)


Establecer el tiempo promedio de resolución de incidentes, desde su apertura en el sistema de mesa de ayuda, estableciendo el esfuerzo que involucra la resolución de los mismos de acuerdo al impacto y severidad. Individualizar los tiempos de respuesta de los vendedores o proveedores como así también de clientes internos o usuarios finales para determinar el tiempo real de resolución en la IT. La resolución es notificada por el área de IT, pasando el incidente al estado resuelto. El usuario final procederá a pasar el incidente al estado cerrado, completando o no la CSS. En caso contrario, el incidente cambiará a la opción de cerrado después de 30 días de estar en estado de resuelto. El cliente o usuario final tendrá la opción de reabrir el incidente antes de pasar al estado de cerrado.

Nota: los incidentes son equivalentes a servicios de los años anteriores.

Fuente de entradas

BMC – Sistema de mesa de ayuda.


Tiempo de resolución del incidente (RT): fecha de resolución del

incidente - fecha de creación del incidente en el sistema de mesa de ayuda. Tiempo de permanencia en espera en proveedores (VH): tiempo total que el incidente permanece en el estado de espera en proveedores (Vendor Hold, VH). Tiempo de permanencia en espera en usuario final o cliente interno (CH): tiempo total que el incidente permanece en el estado de

espera en usuario final o cliente interno (Customer Hold, CH). Severidad: puede ser crítica, alta, media y baja. Impacto: puede ser significante, moderado y localizado.

Fórmula Tiempo resolución incidente dentro IT = (RT) – (CH) – (VH)

Objetivo Objetivo de máxima = tiempo resolución de incidentes (RT-CH-VH) menor o igual a 360 horas. Objetivo de mínima = tiempo resolución de incidentes (RT-CH-VH) menor o igual a 720 horas.

Se priorizará la resolución de los incidentes que tengan mayor impacto y severidad.


Gerente de servicios y entrega de la IT del sitio.


Herramientas

de colección

BMC – Sistema de Mesa de Ayuda – Software de generación de reportes, Cristal Report. Generación automática del reporte y envío por correo del mismo semanalmente. Posibilidad de generación manual en el momento requerido.


Servidor BMC.COM, base de datos de incidentes de BMC.


Servidor BMC.COM, base de datos Oracle de BMC, backup de




Reporte de datos

A nivel interno de la IT: semanalmente (semanal y acumulado anual. Se utilizará el número de semana del calendario anual). Nivel organizacional: mensualmente acumulado del año calendario.

Ejemplo de reporte

Nota: Los gráficos deben ser

generados para la métrica o indicador y

luego derivados como entrada para

el análisis de tendencias.




Mandatorio para todos los incidentes registrados en BMC.



Análisis ¿Cuál es el esfuerzo en resolver los incidentes? ¿Existe alguna tendencia en el esfuerzo inverso? ¿Se está mejorando la eficiencia en el tiempo de resolución de los incidentes? ¿Existen suficientes recursos dentro de la IT para el esfuerzo que requiere la unidad de negocio? ¿Se está cumpliendo lo establecido en el SLA?

Método de análisis recomendado: hacer gráficos por severidad, con los límites de control establecidos en el SLA. Control estadístico de

proceso, análisis de causas y efectos. Analisis de capacidad y de comparación con años anteriores de las medias, análisis de variabilidad.

Mapeo CObIT: Dominio DS7 Educar y entrenar los usuarios. Objetivo de control DS7.1 Identificación de las necesidades de entrenamiento. Áreas claves Plan de entrenamiento para cada grupo de

empleados. ITIL: Servicio de soporte: administración de incidentes y problemas

proactiva. ISO27000: Política de seguridad de la información. BSC: Aprendizaje y crecimiento. CMMI: GP 2.8, 2.10

Gráficos y análisis

adicionales (SPC)

10090807060504030201

250

200

150

100

50

0

Month

Re

so

luti

on

Tim

e (

hs)




10090807060504030201

250

200

150

100

50

0

Month

Re

so

luti

on

Tim

e (

hs)

Boxplot of Resolution Time (hs) - Service 2007

21017514010570350

Median

Mean

1412108642

1st Q uartile 0.337

Median 2.116


Maximum 227.167

13.048 14.462

1.958 2.284

25.714 26.714

A -Squared 786.33

P-V alue < 0.005

Mean 13.755

StDev 26.205

V ariance 686.687

Skewness 3.0996

Kurtosis 11.3452

N 5283

Minimum 0.006





Summary for Resolution Time (hs) - Service 2007

2418126

Median

Mean

15141312


Median 14.300


Maximum 25.420

12.351 15.457

11.841 15.109

4.160 6.413

A -Squared 0.27

P-V alue 0.669

Mean 13.904

StDev 5.046

V ariance 25.459

Skewness 0.176600

Kurtosis 0.220309

N 43

Minimum 2.139





Summary for Mean by week - Services 2007



4137332925211713951

20

10

0

In

div

idu

al V

alu

e

_X=13.90

UCL=25.02

LCL=2.79

4137332925211713951

16

8

0M

ov

ing

Ra

ng

e

__MR=4.18

UCL=13.66

LCL=0

4035302520

24

16

8

Observation

Va

lue

s

672576480384288192960

LSL USL

LSL 0

USL 720

Specifications

3020100

Within

O v erall

Specs

StDev 3.7055

C p 32.38

C pk 1.25

Within

StDev 5.04573

Pp 23.78

Ppk 0.92

C pm *

O v erall


I Chart

Moving Range Chart




Capability Plot

672576480384288192960

LB Target USL

LB 0

Target 360

USL 720

Sample Mean 13.9043

Sample N 43



Process Data

C p *

C PL *

C PU 63.52

C pk 63.52

Pp *

PPL *

PPU 46.65

Ppk 46.65

C pm 0.34



PPM < LB 0.00

PPM > USL 0.00

PPM Total 0.00


PPM < LB *

PPM > USL 0.00

PPM Total 0.00


PPM < LB *

PPM > USL 0.00

PPM Total 0.00


Within

Overall

Process Capability of Mean by week - Resolution Time - Service 2007

200720062005

25

20

15

10

5

0

Year

Me

an 13.9043

11.5882

13.7071

Boxplot of Mean - Services 2005 to 2007



Tabla 5.4.3-7 Métrica: Gastos financieros reales vs. presupuestados

Versión 1.00 Fecha: 20 Febrero, 2008


Gastos financieros actuales versus presupuestados Year to Date Finance Expenses Actual vs. Budget


Registrar el resultado financiero mensual, hacer un seguimiento contra el presupuestado para el mes y el acumulado para el período analizado del año. Registrar y analizar las variaciones.

Fuente de entradas

Registro de gastos de expensas del área por período contable mensual y anual. Sistema financiero / contable de registro.


Gastos de expensas: toda operación asociada financieramente con aquello que no signifique la incorporación de bienes capital por un valor menor a US$ 5000, aquella individual asociada a un centro de costo y a un plan de cuenta predeterminado para su imputación. Nota: estas facturas o documentos fiscales deberán estar previamente respaldados por órdenes de compra, de acuerdo a la política vigente y con la firma del gerente del área correspondiente donde se imputará el mismo, y nivel de aprobación necesario de acuerdo al monto, compras o adquisiciones mayores deberán también ser aprobadas por el director del negocio.

Fórmula ∑Gastos realizados por área, acumulados hasta el mes calendario en el análisis en dólares versus ∑Gastos presupuestados para ese mismo período de tiempo.

Objetivo No podrá excederse del 5% de diferencia entre el actual y el presupuestado, salvo el caso en que se justifique financieramente por situaciones especiales previamente acordadas por la gerencia general.

Responsable de la

colección

Se deberá de presentar y registrar toda la documentación dentro del sistema financiero en el plan de cuentas correspondiente de la compañía y de acuerdo a las políticas locales. Los gerentes de las áreas podrán solicitar a Finanzas y generar reportes de seguimientos mensuales para alcanzar el objetivo anual.

Herramientas de la

colección

Sistema Financiero / Contable

Audiencia Gerencia del negocio y gerencia de la IT (niveles regionales).


Base de datos Oracle relacionada con el sistema financiero / contable

Período de reporte

A nivel organizacional: mensualmente con reporte a la gerencia superior. Se recomienda hacer un seguimiento de reporte semanal de los mismos.







Criterios de colección

Registro obligatorio de todos los comprobantes de acuerdo a las leyes nacionales y normas definidas por la compañía en los centros de costos correspondientes.

Análisis ¿El gasto total del área es mayor que el del mes anterior? ¿Se está cumpliendo con el presupuesto pautado, existen desviaciones? ¿Está afectando la inflación al presupuesto? ¿Existe análisis de desviaciones por mes y por plan de cuentas? ¿Qué acciones surgen cuando se no cumplen las expectativas? ¿Se evalúa el cumplimiento de los objetivos previamente acordados? Método de análisis recomendado: gráfico de barras, o bien SPC. Análisis de causa raíz, gráficos de Pareto para segregación.

Mapeo CObIT: Dominio PO5 Manejar la inversión de IT. Objetivo de control PO5.1 Presupuesto anual operativo de IT. Áreas claves Plan de presupuesto (presupuestar gastos en base al

plan de negocio). ITIL: Servicio de entrega: administración financiera de los servicios de IT. Presupuesto. ISO27000: Política de seguridad de la información. BS: Finanzas. Perspectiva financiera. QPM: Quality Project Management.



5.5. ¿Por qué usar un tablero de control (dashboard) para los indicadores?

El uso de un lenguaje común en gestión es particularmente complejo en el área de la IT. Suele haber barreras comunicacionales causadas por el uso de diferentes idiomas operativos y modismos tradicionales, lo que a menudo le impide a la organización desplegar completamente su potencial capacidad para identificar oportunidades de negocio acordes a su estrategia. La dirección ejecutiva ha utilizado, tradicionalmente, indicadores financieros para impulsar el proceso de toma de decisiones de departamentos de la IT. Actualmente se le presta, además, mayor atención a métricas o indicadores cualitativos. Lo que se necesita es un proceso orientado al negocio, que conduzca a metas e inversiones en la IT, generando un lenguaje común en la empresa y proporcionando un marco coherente para su respectiva evaluación, utilizando criterios análogos en toda la organización. Dado que el objetivo primordial de la mayoría de las organizaciones es generar resultados financieros positivos, muchas intentan alcanzarlos con metas relacionadas con el cliente, fijando los aspectos necesarios para su adquisición, retención, satisfacción y lealtad que posibiliten tal objetivo. Sin embargo, el establecimiento de vínculos entre las personas, procesos, tecnología y cultura organizativa que permiten los resultados deseados no es una cuestión asequible para muchos. Los administradores en IT inquieren sobre sistemas de medición que puedan utilizarse para comunicar y demostrar la capacidad de su área para otorgarle el merecido valor, vinculando el rendimiento a los de objetivos del negocio y sus métricas. Uno de los más importantes impulsores de la formulación estratégica y cambio en el mundo tecnológico es la innovación. En particular, la aplicación de innovaciones a la IT ha alterado radicalmente la base de la competencia empresarial. Los dashboards o tableros corporativos se están convirtiendo en la tecnología imprescindible de inteligencia de negocios. Aunque su uso se promulga hace más de una década, recientemente han alcanzado una gran notoriedad, debido al acelerado avance tecnológico. El diseño de un tablero de instrumentos eficaces de negocios es dificultoso debido a que debe sintetizar allí una gran cantidad de información. El objetivo operacional del tablero es proporcionar a los usuarios de negocios las acciones e información que los faculten para hacer eficientes sus decisiones. En este contexto, la información pertinente será aquella directamente vinculada a la función del usuario y el nivel dentro de la organización. Por ejemplo, sería intrascendente proporcionar a un director de finanzas regional las cifras detalladas sobre el tráfico en el sitio web, que en cambio son adecuadas para presentar los costos de utilización en lo que respecta a consumo de ancho de banda. La información valorable se refiere a los datos que alertan acerca de cuándo y qué tipo de medidas deben ser adoptadas con el fin de cumplir con operativos u objetivos estratégicos.



Para el diseño de un panel eficaz se debe considerar el papel que desempeñan los usuarios dentro de la organización, junto con las tareas específicas y responsabilidades diarias. El primer paso para diseñar un tablero de instrumentos es comprender los indicadores clave de desempeño, Key Performance Indicators (KPI), que aquí han sido tratados como métricas o indicadores, de manera indistinta, seleccionados en base a los objetivos del negocio. Como se mencionó anteriormente, en un principio es indispensable contar con un plan de desempeño de indicadores (Measurement Plan), que contenga toda la información referente a ellos. Luego, de acuerdo al template sugerido por el SEI, se indicarán cuales se desean gestionar como solución a través del tablero de instrumentos. La correcta definición de los indicadores específicos para el negocio es una de las etapas más importantes de diseño, ya que establece las bases y el contexto de la información que posteriormente será visualizado en el panel. La visualización de los componentes de un dashboard se divide en dos categorías principales: los indicadores clave de rendimiento y el análisis de soporte. En cualquier caso, es primordial elegir aquella que mejor se ajuste a las necesidades de los usuarios finales en relación con la información de seguimiento o análisis. Según Cousins81 un dashboard se basa en cuatro pilares, a mencionar:

1) Finanzas 2) Entrega 3) Satisfacción al cliente 4) Calidad u otras áreas

Gráfico 5.5-1 ¿Qué es un dashboard?

81

COUSINS, TINA. 2007. "Dashboard" [en línea]. Disponible en Internet: www.proms-g.bcs.org/histevents/pdfs/psg0606%20-%20Dashboard.pdf [Consulta: 07 de Junio del 2008]

http://www.proms-g.bcs.org/histevents/pdfs/psg0606%20-%20Dashboard.pdf



A su vez, agrega que a través del dashboard es posible vislumbrar lo que sucede en la organización, permitiendo el control de diversas situaciones en tiempo real y con una visión global del negocio, por medio del registro de datos actuales e históricos para su mayor análisis.

5.5.1. Ejemplos de representación de indicadores en un dashboard

A continuación se mostrarán algunos modelos de dashboard simples, construidos en base a tres indicadores del MP definido para el presente trabajo, ellos corresponden a la resolución de incidentes, YTD actual versus presupuestado e índice de satisfacción del cliente. La información puede exponerse de diferentes formas, entre ellas se encuentran gráficos de reloj, que señalan el estado de los indicadores, y los de barras con históricos por mes.

Gráfico 5.5.1-1 IT Dashboard – Relojes indicadores

Gráfico 5.5.1-2 IT Dashboard - Gráfico de barras de incidentes



Gráfico 5.5.1-3 IT Dashboard - Gráfico de barras de presupuesto

Gráfico 5.5.1-4 IT Dashboard - Gráfico de barras de satisfacción al cliente

5.6. Resumen de la etapa de mejora de la performance o actuación

En esta etapa se han utilizado distintas herramientas para la generación de ideas conducentes a la mejora, como el análisis de fuentes de variación, torbellino de ideas, benchmarking, mejores prácticas del mercado, entre otras. A la vez, se consultaron diversas fuentes bibliográficas que hacen referencia al respecto, para contar con una



base teórica suficiente que permitiera seguir correctamente los pasos necesarios para introducir una mejora sustancial y real al sistema existente. Partiendo del proceso de mejora de 7 pasos de ITIL r3, se continuó con la toma de decisiones basadas en datos (SS), el desarrollo de un plan de desempeño (MP) y la construcción de indicadores (SEI-CMMI) basados en las mejores prácticas del mercado. Por otro lado se recurrió a un template o formato predefinido, donde la experiencia del SEI otorga un soporte confiable para la definición de indicadores y el método a seguir para aquellos que se incorporarán a futuro. El plan de desempeño de los indicadores es la base donde se documentan los KPI considerados necesarios para reflejar el alineamiento hacia los objetivos del negocio. Cada indicador fue claramente definido, para evitar confusiones entre ellos, y se presentaron algunos ejemplos de los estimados como críticos, resaltando la importancia de su integración en un tablero de mando o dashboard. A modo de resumen, para el diseño del plan de desempeño y tablero de indicadores correspondiente, se enumeran los pasos a seguir:

1) Conocer los objetivos estratégicos del negocio. 2) A partir de ellos seleccionar los tipos de métricas relacionadas (KPI). 3) Realizar un plan de desempeño (MP) que incluya las KPI. 4) Definir en detalle cada indicador en base a un formato seleccionado. 5) Recolectar datos e información que permitan el análisis y la consecuente toma

de decisiones basada en sus resultados, para introducir la mejora continua. 6) Construir un tablero de comando o indicadores que refleje los resultados

obtenidos. Esta metodología también es utilizada para otras unidades de negocio, y esto posibilita el benchmarking entre ellas y la mejora continua planteada en el proceso de los 7 pasos de ITIL. Existen distintos ―modelos de calidad‖ que han surgido a lo largo del tiempo. Hallowell82 propone una jerarquía de relevancia y grado de abstracción de aquellos utilizados habitualmente.

82

HALLOWELL, DAVE. SEI.‖A Measurement & Analysis Training Solution Supporting CMMI & Six Sigma Transition‖. [en línea]. Disponible en Internet: http://www.sei.cmu.edu/sema/presentations/training-solution.pdf

http://www.sei.cmu.edu/sema/presentations/training-solution.pdf



Gráfico 5.6-1 Modelos de calidad, relevancia y abstracción

Publicado por SEI

Debido a tal diversidad se llevaron a cado mapeos con los modelos CObIT, ITIL, ISO 27000, BSC y CMMI para cada indicador definido, para evaluar la superposición y relación respecto a diferentes temas, según puntos de vista disímiles. Todo lo anterior, en conjunto, hace factible la estandarización del proceso, respaldada con fundamentos estadísticos para la obtención de resultados.



6. CONTROL DE LA PERFORMANCE

Para mantener la calidad del proceso se necesita institucionalizar el sistema mejorado, a través de la modificación de políticas y procedimientos de compensación e incentivos, presupuestos, instrucciones operativas de trabajo y otras herramientas de gerenciamiento. Utilizando los estándares recomendados anteriormente respecto de las mejores prácticas y herramientas estadísticas para monitorear la estabilidad de los nuevos sistemas o procesos. La etapa de control es la que facilita a las empresas el sostén del desempeño mejorado del proceso, e incluye: - Confirmar la integridad de medición de las variables de entrada críticas. - Establecer la capacidad de proceso para las variables de entrada críticas - Implementar el control estadístico del proceso. - Identificar oportunidades para continuar la mejora.

Gráfico 6-1 Control de la performance

El objetivo último es garantizar que las mejoras introducidas son mantenidas en el tiempo, y asegurar que los problemas futuros relacionados a los nuevos procesos serán identificados y solucionados rápidamente.



6.1. Fases y salidas del control del desempeño o performance

La etapa de control del desempeño consta de varias fases, entre ellas se hará énfasis en:

Plan de implementación de la solución.

Implementación del control estadístico de proceso (SPC).

Integración del proceso.

Cierre del proyecto y reconocimiento. Las salidas de esta última fase del proyecto DMAIC de Six Sigma serán las siguientes:

Planes de control de procesos y sistemas de SPC.

Procedimientos y estándares.

Planes de entrenamiento.

Grupo de evaluación.

Análisis de problemas potenciales

Resultados de la solución.

Historia de éxitos.

Replicación de oportunidades.

Estandarización de oportunidades.

6.2. Elementos de un plan de implementación

Un plan de implementación debería incluir los siguientes elementos:

Análisis de problemas potenciales.

Procedimientos y estándares.

Sistema de control de procesos (SPC).

Plan de entrenamiento.

Plan de comunicación.

Presupuesto y casos de beneficios.

Plan de trabajo detallado de implementación.

6.2.1. Análisis de problemas potenciales

La evaluación de riesgos para la implementación del proyecto debe incluir eventos internos y externos, o circunstancias que pudieran impedir su éxito. Un análisis de problemas ayuda a identificar riesgos y detectar modos para minimizar el impacto en el éxito de la implementación.



La solución de la implementación no debe estar relacionada solamente al proceso de performance sino también debe asegurarse de:

Ajustarse a los requerimientos regulatorios.

Seguridad y salud de la fuerza laboral.

Adecuado entrenamiento de operadores.

Satisfacción y bienestar de los empleados.

Comunicación consistente a todas las áreas.

Aceptación general.

Líderes formales e informales que la apoyen.

Correspondiente adopción.

Continuar su aplicación. El caso aquí planteado se enfoca desde un principio en el alineamiento con los requerimientos regulatorios internacionales y normas relacionadas, con el fin de estandarizar los procesos, y en caso de ser necesario, adoptar medidas adicionales que permitan la aplicación en determinadas sucursales. La definición de un plan de mediciones o de desempeño para los objetivos del negocio relacionado con la IT facilita la aplicación y replicación de la solución hallada. Por supuesto también dependerá de que los líderes formales e informales de la organización la acepten e implementen, para luego estandarizarla en distintas unidades de negocio dentro del área respectiva. Una vez logrado esto, realmente se podrán comparar indicadores útiles, tanto para el gobierno de la IT como para la empresa en su totalidad; permitiendo la toma rápida de decisiones basada en información actualizada y orientada a los objetivos del negocio.

6.2.2. Procedimientos y estándares

El plan de desempeño es un estándar donde se describen los procedimientos de obtención y cálculo de los indicadores mínimos y necesarios. Es de gran utilidad el empleo de herramientas o softwares de reportes como Business Objects o Cristal Report, dentro de las que se definen los indicadores estándares. Como tales herramientas tienen interacción con la base de datos que funciona como repositorio común de la IT, podría fácilmente digitalizarse la solución para minimizar esfuerzos y errores de cálculo. Esto se conoce como inteligencia de negocio o Business Intelligence (BI). La tendencia es que, siempre que sea posible automatizar o digitalizar las soluciones serán estas las elegidas, dado que se independizan del error introducido por los operadores. Son finalmente más baratas y reusables, y aseguran el cumplimiento del proceso y previenen errores.



6.2.3. Sistema de control estadístico de procesos (SPC)

El control estadístico de procesos (SPC) es una herramienta que permite controlar y mejorar los procesos. Provee datos relevantes acerca de las prioridades que involucra la implementación de una solución, y esta información sirve como base para la toma de decisiones. El siguiente gráfico es un ejemplo de aplicación de SPC donde se observan distintos parámetros que permiten controlar el proceso (detallados en profundidad en la etapa de análisis del proyecto de DMAIC). Este es un gráfico que resumen 6 importantes análisis desde comportamiento individual de los datos, rangos, análisis de normalidad y de capacidad como así también el comportamiento de las últimas observaciones para ver la tendencia del proceso analizado.

Gráfico 6.2.3-1 Ejemplo de procesos bajo SPC

4137332925211713951

20

10

0

In

div

idu

al V

alu

e

_X=13.90

UCL=25.02

LCL=2.79

4137332925211713951

16

8

0

Mo

vin

g R

an

ge

__MR=4.18

UCL=13.66

LCL=0

4035302520

24

16

8

Observation

Va

lue

s

672576480384288192960

LSL USL

LSL 0

USL 720

Specifications

3020100

Within

O v erall

Specs

StDev 3.7055

C p 32.38

C pk 1.25

Within

StDev 5.04573

Pp 23.78

Ppk 0.92

C pm *

O v erall


I Chart

Moving Range Chart




Capability Plot

Para cada indicador clave de proceso (KPI) es recomendable, siempre que sea posible, aplicar un control estadístico de proceso para monitorearlos. Esto conducirá a actuar de manera preventiva, la mayoría de las veces, gracias al análisis de tendencias y comportamientos de los procesos en cuestión. También brindará la oportunidad de introducir mejoras y medirlas una vez implementadas. El objetivo del SPC es mantener el proceso estable, es decir, con la menor variabilidad posible, distinguiendo las causas de variación comunes de las especiales. En el siguiente gráfico podemos observar el comportamiento de un proceso que se encuentra estable en el tiempo, repitiendo la forma distribución de la muestras en el tiempo con una distribución normal de los datos.



Gráfico 6.2.3-2 Proceso estable en el tiempo

Cuando se detecta una causa especial de variación debe indagarse si es una tendencia o cambio en el proceso o es debida solo a un caso aislado. En cambio en el gráfico siguiente se puede observar cual es el comportamiento de un proceso que no se encuentra estabilizado en el tiempo, produciendo distintas distribuciones no normales o repetibles lo cual no nos permite predecir que sucederá en el próximo instante de tiempo.

Gráfico 6.2.3-3 Proceso inestable en el tiempo

Los limites de control superior e inferior se generan a través del la lectura de los datos, su línea central y la variación respecto a las mismas, existen distintas reglas a partir de los cuales a pesar de que el proceso este dentro de los límites impuestos o propios podemos predecir si esta saliéndose de control o producir un ajuste que nos permita aumenta la capacidad del proceso ajustándolo a la línea central o especificaciones. En grafico siguiente vemos como se reflejan los datos dentro de un grafico de un proceso dado con los límites de control establecidos.



Gráfico 6.2.3-4 Gráfico de un proceso con límites de control

Para tener un proceso bajo control hay que observar si ocurren cambios, si algún valor ha quedado fuera de ciertos límites determinados, utilizando los gráficos respectivos. Para analizar estos cambios y lograr que el proceso retorne a sus valores normales existen varias metodologías de resolución de problemas, tales como FMEA83 y/o Global 8D84, que serán aplicadas según criterios fijados por la empresa. Se destacan nuevamente en el gráfico siguiente algunas diferencias entre capacidad, estabilidad y límites del proceso. La capacidad implica cumplir con los requisitos del cliente, para monitorear e identificar los límites de las especificaciones. Esto define el rango aceptable de variación, dentro del cual el proceso funcionará correctamente. Pero no debe confundirse con el concepto de estabilidad, es decir, un proceso estable no es necesariamente será capaz. La estabilidad es una condición necesaria pero no suficiente para la capacidad. Por último, los límites de especificación son los requeridos por el cliente, y son diferentes a los de control, que quedan determinados por los niveles históricos de variación hallados en el proceso.

Gráfico 6.2.3-5 Ejemplo de estabilidad y capacidad de un proceso

83

FMEA. ―Modo de FMEA o de fallo y análisis de los efectos‖. [en línea]. Disponible en Internet: http://www.beyondlean.com/FMEA_es.html [Consulta: 04 de Julio del 2008] 84

Global 8D. ―The 8 Disciplines (8D) Process‖. [en línea]. Disponible en Internet: http://www.siliconfareast.com/8D.htm [Consulta: 04 de Julio del 2008]

http://www.beyondlean.com/FMEA_es.html

http://www.siliconfareast.com/8D.htm



Como se ha visto, en el capítulo 4 del presente trabajo se ha desarrollado en profundidad la etapa de análisis de oportunidades. Allí se evaluaron tanto los servicios como los problemas de pedidos realizados al área de IT por parte de usuarios finales, a lo largo de un período de 3 años consecutivos, y se puso de manifiesto el cumplimiento de las condiciones de estabilidad y capacidad.

6.2.4. Plan de entrenamiento y comunicación

Los planes de entrenamiento y comunicación deberán ser diseñados observando la audiencia a la que están enfocados. Existirán entrenamientos específicos orientados a los operadores directos y otros más generales para el resto de la empresa, con el propósito de que comprendan el significado de la implementación de los nuevos procesos. El modo de comunicación a utilizar dependerá de la empresa en cuestión, pero siempre se sugiere emplear varios tipos simultáneamente o en cadena para reforzarla y extenderla al mayor número de personas posible. Esto podría generar la formación de círculos de mejora de la calidad de procesos, integrados por personal de diferentes niveles técnicos o administrativos. Tanto la comunicación efectiva como el entrenamiento adecuado y focalizado permitirán romper las barreras potenciales de implementación y la resistencia al cambio por parte de quienes tienen que adoptarlos. Deberán tenerse en cuenta el aspecto cultural, la carga de trabajo y actividad actual del personal, como así también la capacidad de los mismos para absorber el esfuerzo que implica la implementación de nuevos procesos o cambios a los existentes; asegurándose de proveer los recursos humanos y financieros adecuados para que sucedan en tiempo y forma de acuerdo a los factores del negocio, en cuanto a la inversión que destine el mismo, la urgencia del mercado y el tiempo del año.

6.3. Cierre del proyecto y reconocimiento

Es fundamental en esta etapa la creación de la documentación relacionada con las lecciones aprendidas (lessons learned) del proyecto. Para ello se compilarán los conocimientos obtenidos en un documento accesible, categorizados por clase, estado de mejora, tipo de defecto, análisis utilizados, palabras claves, problemas u oportunidades, análisis de causa raíz, y demás características. Tales conocimientos se comunicarán a todos los miembros de la organización. Los elementos que deberían contener son las acciones realizadas por el equipo, encuestas, entrevistas, y recopilación de datos antes, durante y después de la implementación de la solución. También podría incluir planteos acerca de la dinámica del grupo, revisión de notas para listar las barreras de cambio y las mejores prácticas. Procurando la



retroalimentación de los participantes del proceso que origine propuestas de mejora para próximas implementaciones. No debe omitirse el correspondiente reconocimiento o recompensa por el logro alcanzado, es preciso otorgarlo a la brevedad, dejando claras las razones que lo impulsaron. Los reconocimientos suscitan la motivación y satisfacción de los miembros de la organización, y por ende, promueven una cultura de mejora continua.

IV. Comentarios finales El presente trabajo ha implantado un proyecto Six Sigma (DMAIC) para un sistema de indicadores y métricas, con el objetivo de mejorarlo. La meta fue lograr un marco trabajo que contuviera definiciones claras y unívocas de tales indicadores, y por lo tanto permitiera, a través de las mejoras logradas, reforzar el valor de las actividades de la IT. Los indicadores que se pusieron como ejemplos en el plan de medición están representados con gráficos de datos reales de centro. Las métricas o indicadores definidos en este trabajo fueron implementados en el centro de Argentina pero debido a la situación económica financiera de las empresas con casa matriz en Estados Unidos, el foco y mayores esfuerzos están orientados ahora a sostener las operaciones a través de ajustes muy fuertes, la propuesta no pudo ser replicadas en otros países todavía, está siendo analizada por el grupo de calidad que maneja las métricas de I.T. a nivel mundial para una futura implementación gradual por negocios. Se pudo observar a través de diferentes técnicas de análisis aplicadas que, más allá del debido reordenamiento de conceptos preexistentes, era indispensable la definición de nuevas métricas, consideradas claves o críticas, estandarizadas, y que se alinearan con los objetivos estratégicos del negocio; para luego reunirlas en un plan de mediciones común a todas las unidades de negocios. Algunos indicadores que inicialmente se incluyeron en el plan de mediciones son los siguientes:

Encuesta de satisfacción al cliente por incidentes

Costo de la pobre o no calidad

Costo de la calidad

Esfuerzo de entrenamiento

Tiempo de remoción de vulnerabilidades e incidentes de seguridad

Tiempo de resolución de incidentes en IT

Gastos financieros actuales versus presupuestados

Tiempo de espera de incidentes sin asignación de agentes Por otro lado, la definición de nuevos indicadores críticos y de un tablero de gestión y control de la IT, hizo posible la aplicación eficaz de la metodología propuesta. La introducción y representación de indicadores de gestión a través de un tablero de comandos permite a la gerencia saber cómo se encuentran los procesos y la consecuente toma de decisiones, con mayor certeza, en base a datos. Esto destaca su



importancia, dado que a partir de los objetivos estratégicos del negocio se definen las pautas óptimas de su procedimiento. Estos planes deben basarse en un patrón de métricas estándar (template) sugerido, indicando el contenido mínimo para su implementación. En cuanto a herramientas administrativas de apoyo, se halló positivo el reconocimiento al grupo de trabajo encargado del proyecto, como motor de otros futuros. Existen distintas formas de reconocimiento y recompensa, de acuerdo al tipo de proyecto, impacto, ahorros y personas que intervienen, y no solo monetarios sino aquellos que contemplan la parte humana. Por último, la etapa de control permitió el monitoreo, implementación de mejoras, resolución de problemas y toma de decisiones en base a datos. Todo esto se resume en un ciclo de mejora continua en los procesos y la determinación de nuevas necesidades del negocio. Cabe señalar que es cada vez mayor la necesidad de una gestión integrada de la IT, con las diferentes áreas dentro de la empresa, alineando sus objetivos a la estrategia global. Esto ayuda a mejorar los resultados, tanto cualitativa como cuantitativamente, permitiendo –como fuera expresado- optimizar su inteligencia competitiva. Como se menciona en varios artículos y sitios de internet tales como Artemis85, donde resalta que la Gestión Integrada de IT, manteniendo y ampliando las estrategias y objetivos de la organización, permite compartir una visión única de la demanda de negocio de IT, tanto de inversiones en curso como previstas, además de agilizar la asignación de fondos y de recursos para reflejar las prioridades del negocio, alinear el plan de inversiones con el de ejecución y asegurar la obtención de beneficios. En resumen, en todo momento se buscó reflejar la importante contribución que tienen los objetivos del negocio en el desarrollo y posterior éxito del proyecto. Además de basarse en fundamentos consistentes, como estándares internacionales, y llevar adelante un desempeño operativo competente, el proyecto debe recibir apoyo absoluto por parte de la gerencia. Los administradores deberán asegurar la difusión de la información en la totalidad de las áreas de la organización, junto con la distribución del conocimiento adquirido durante la evolución, para consolidar la sinergia organizacional, fomentar la creatividad hacia soluciones de mejora y evitar barreras para el cambio. Se concluye que para que un sistema de calidad funcione debe haber un compromiso sólido en toda la organización. Esto es en efecto, mantener una cultura organizacional dirigida a la mejora continua de sus logros.

85

ARTEMIS. ―IT Management and Governance‖. [en línea]. Disponible en Internet: http://es.aisc.com/solution/2 [Consulta: 21 de Mayo del 2009]

http://es.aisc.com/solution/2





V. Bibliografía

ARTEMIS. ―IT Management and Governance‖. [en línea]. Disponible en Internet: http://es.aisc.com/solution/2 [Consulta: 21 de Mayo del 2009]

ARVESON, PAUL.1998. ―What is the Balanced ScoreCard‖. [en línea]. Disponible en: http://www.balancedscorecard.org/basics/bsc1.html [Consulta: 11 Diciembre 2007]

ASQ STATISTICS DIVISION. Glossary and tables for statistical quality control. Milwaukee: ASQ Quality Press. Duncan, 1983.

BALDRIGE NATIONAL QUALITY PROGRAM. ‖Criteria for Performance Excellence‖ [en línea]. Disponible en: http://baldrige.nist.gov/Business_Criteria.htm [Consulta: 11 Diciembre 2007]

BASEL II - REVISED INTERNATIONAL CAPITAL FRAMEWORK. ―Convergencia internacional de medidas y normas de capital‖. [en línea]. Disponible en: http://www.bis.org/publ/bcbs107esp.htm [Consulta: 04 Marzo 2008]

BLANCO ILLESCAS, Francisco. El control integrado de gestión. Méjico: Editorial Limusa, 1995.

BROWN, Mark Graham. Keeping Score: Using the Right Metrics to Drive World-Class Performance, Hermosa Beach: Productivity, 1996.

CARNEGIE MELLON UNIVERSITY. 2007. ―What is CMMI?‖ [en línea]. Disponible en: http://www.sei.cmu.edu/cmmi/general/index.html [Consulta: 11 Diciembre 2007]

CARNEGIE MELLON UNIVERSITY. CMMISM for Systems Engineering / Software Engineering/Integrated Product and Process Development / Supplier Sourcing, Version 1.1, Staged Representation. Pittsburg: S.E.I., 2002.

COUSINS, TINA. 2007. "Dashboard" [en línea]. Disponible en: www.proms-g.bcs.org/histevents/pdfs/psg0606%20-%20Dashboard.pdf [Consulta: 07 de Junio del 2008]

CROSBY, Philip B. Calidad sin lágrimas – El arte de administrar sin problemas, Méjico: Compañía Editorial Continental, 1992.

CSC. ―Patch Management using Six Sigma‖ [en línea]. Disponible en: http://phoenix.issa.org/Six%20Sigma.ppt [Consulta: 11 Diciembre 2007]

DEMING, W.E. On probability as a basis for action. Cambridge: MIT, 1975. DETORO, I. The 10 pitfalls of benchmarking, New York: Quality Progress, 1995. DEW, John R. Quality-Centered Strategic Planning: A Step-By-Step Guide, New York:

Quality Resources, 2002. DRUCKER, Peter F. La gerencia de empresas, Buenos Aires: Editorial Sudamericana,

1963. ERNST & YOUNG. The Ernst & Young Guide to Performance Measurement for

Financial Institutions: Methods for Managing Business Results, Chicago: Ernst & Young Staff, 2001.

FMEA. ―Modo de FMEA o de fallo y análisis de los efectos‖. [en línea]. Disponible en: http://www.beyondlean.com/FMEA_es.html [Consulta: 04 de Julio del 2008]

FRENCH, J.R.P. Y RAVEN, B.H. Las bases del poder social. En: Cardwright, D. y Sander, A. (eds.) (1972). Dinámica de grupos. Investigación y teoría. Trillas, México,1972.

GLOBAL 8D. ―The 8 Disciplines (8D) Process‖. [en línea]. Disponible en: http://www.siliconfareast.com/8D.htm [Consulta: 04 de Julio del 2008]



GORE, A. 1997. ―Serving the American Public: Best Practices in Performance Measurement‖.1997.[en línea]. Disponible en: http://govinfo.library.unt.edu/npr/library/papers/benchmrk/nprbook.html [Consulta: 07 de Junio del 2008]

HALLOWELL, DAVE. SEI. ‖A Measurement & Analysis Training Solution Supporting CMMI & Six Sigma Transition‖. [en línea]. Disponible en: http://www.sei.cmu.edu/sema/presentations/training-solution.pdf

HARBOUR, Jerry L. The Basics of Performance Measurement, New York: Productivity, 1999.

HARRIS, TRISH. ‖COSO Releases Discussion Document with Guidance on Monitoring Internal Control‖. [en línea]. 17 Septiembre 2007. Disponible en: http://www.theiia.org/theiia/newsroom/news-releases/?search=COSO&C=1042&I=4153 [Consulta: 11 Diciembre 2007]

HARRY, Mikel y SCHROEDER, Richard. Six Sigma: The Breakthrough Management Strategy Revolutionizing the World’s Top Corporations. New York, NY: Doubleday, 2000.

HUMPHREY, Watts S. Managing the software process. USA: Addison –Wesley Publishing Company, 1990.

IEEE ARGENTINA. ―Que es ITIL‖ [en línea]. Disponible en: www.ieee.org.ar/downloads/2006-hrabinsky-itil.pdf [Consulta: 11 Diciembre 2007]

INFORMATION SYSTEMS AUDIT AND CONTROL FOUNDATION, Governance, Control an Audit for Information and Related Technology, Illinois: ISACA, 2000.

INTERNATIONAL STANDARIZATION ORGANIZATION. Norma Internacional ISO 690. Información y documentación. Referencias bibliográficas. Ginebra: ISO, 1987.

ISACA. ―CObIT Executive Summary & Framework‖.[en línea] Disponible en: http://www.isaca.org/Template.cfm?Section=COBIT6&Template=/TaggedPage/TaggedPageDisplay.cfm&TPLID=55&ContentID=7981 [Consulta: 11 Diciembre 2007]

ISACA. ―COBIT MAPPING: MAPPING OF CMMI FOR DEVELOPMENT V1.2 WITH COBIT 4.0‖.[en línea]. Disponible en: http://www.isaca.org/ContentManagement/ContentDisplay.cfm?ContentID=31452 [Consulta: 24 de Junio del 2008]

ISHIKAWA, K. What is total quality control? The Japanese way. New Jersey: Prentice-Hall, 1985.

ISIX SIGMA. ―DMAIC Project Cycle Graphic‖. Disponible en: http://www.isixsigma.com/me/dmaic/ [Consulta: 11 Diciembre 2007]

ISIX SIGMA. ‖Renew the Commitment to Data-Based Decision Making‖. [en línea]. Disponible en: http://www.isixsigma.com/library/content/c070514a.asp?action=print [Consulta: 02 de Junio del 2008]

ISO 15939. " Proceso medición del software" [en línea]. Disponible en: http://www.psmsc.com/ISO.asp [Consulta: 07 de Junio del 2008]

ISO 20000.‖ISO20000 - The IT Service Management Standard‖ [en línea]. Disponible en: http://www.itgovernance.co.uk/iso20000.aspx?gclid=CNzMtPHo0JMCFQE4GgodsVfGhw [Consulta: 11 Diciembre 2007]



ISO 27000. ―An Introduction to ISO 27001, ISO 27002....ISO 27008‖ [en línea]. Disponible en: http://www.27000.org [Consulta: 11 Diciembre 2007]

IT GOVERNANCE INSTITUTE. 2005. ―Aligning CoBIT, ITIL & ISO 17799 for Business Benefit: Management Summary.‖ [en línea]. Disponible en: http://www.itgi.org [Consulta: 25 de Febrero del 2008]

IT GOVERNANCE. 2007. ―What is ISO/IEC 27001?‖ [en línea]. Disponible en: http://www.27001.com/27001.aspx [Consulta: 11 Diciembre 2007]

ITGI. 2003. ―Board Briefing of IT Governance 2nd Edition‖.[en línea]. Disponible en: http://www.itgi.org [Consulta: 25 de Febrero del 2008]

ITIL GLENFIS PORTAL. ―ITIL V2 – ITSM Processes‖. [en línea]. Disponible en: http://www.itil.org/en/itilv2-itservmgmtprozesse/itilv2-itservicemanagementprozesse.php [Consulta: 25 de Febrero del 2008]

ITIL GLENFIS PORTAL. ―What is ITIL‖.[en línea]. Disponible en: http://www.itil.org/en/index.php [Consulta: 25 de Febrero del 2008]

ITIL OFFICIAL SITE. [en línea]. Disponible en: http://www.itil-officialsite.com/home/home.asp [Consulta: 25 de Febrero del 2008]

ITIL(INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY). ―ITIL FAQ‖ [en línea]. Disponible en: http://www.itlibrary.org/index.php?page=ITIL_FAQ [Consulta: 11 Diciembre 2007]

ITSMF. ―An Introductory. Overview of ITIL. ®. V3‖. 2007‖ [en línea]. Disponible en: www.itsmf.si/Shared%20Documents/itSMF_ITILV3_Intro_Overview.pdf [Consulta: 02 de Junio del 2008]

JURAN, J. M. and GRYNA, F.M. Quality planning and analysis. New York: McGraw-Hill, 1993.

JURAN, J. M. Juran y el liderazgo para la calidad – Un manual para directivos. Madrid: Díaz de Santos, 1990.

KAN, Stephen. Metrics & Models in Software Quality Engineering. USA: Addison-Wesley, 1995.

KAPLAN, R.S. y NORTON, D.S. Implantando el cuadro de mando integral. Barcelona: Gestión 2000.

KAPLAN, R.S. y NORTON, D.S. Strategy Maps: Converting Intangible Assets into Tangible Outcomes. Boston: Harvard Business School, 2004.

KERRY, SIMON. ―DMAIC versus DMADV Methodologies‖. [en línea] I SIX SIGMA. Disponible en: http://www.isixsigma.com/library/content/c001211a.asp [Consulta: 11 Diciembre 2007]

KOTTER, John P. What Leaders Really Do?. Boston: School Press, 1999. Limusa, 1995.

LORD KELVIN. ―Quotations from Lord Kelvin‖ [ en línea]. Disponible en: http://zapatopi.net/kelvin/quotes/ [Consulta: 11 Diciembre 2007]

MANNS, T; Coleman, M. Software Quality assurance. Great Britain: Macmillan Press, 1996.

MARAKAS, George M. Decision Support Systems in the 21st Century. New Jersey: Prentice-Hall, 1999.

MCCARTY, THOMAS; DANIELS, LORRAINE; BREMER MICHAEL; AND GUPTA, PRAVEEN. The Six Sigma Black Belt Handbook. New York: McGraw-Hill Publishers, 2004.

McLEOD, R. Sistemas de Información Gerencial. Méjico: Pearson Educación, 2000.



MENDENHALL, William. Estadística para administradores. México: Editorial Iberoamericana, 1990.

MERCADO, Salvador. Cómo hacer una tesis?, Méjico: Editorial Limusa, 1994. MINITAB® 15.1.1.0. [en línea]. Disponible en: ttp://www.minitab.com/products

[Consulta: 25 de Febrero del 2008] MIZUNO, S. Management for Quality Improvement: The 7 new QC Tools, Cambridge:

MA, 1998. MOTOROLA. 2007. ―Six Sigma Programs‖. [en línea]. Disponible en:

http://www.motorola.com/content.jsp?globalObjectId=3049-11525 [Consulta: 11 Diciembre 2007]

NIVEN, Paul R. Balanced Scorecard: Step by Step. New York: John Willey & Son, 2002.

OFFICE OF GOVERNMENT COMMERCE. 2007. ―What does PRINCE2 work?‖ [en línea]. Disponible en: http://www.ogc.gov.uk/methods_prince_2__whatisit.asp [Consulta: 11 Diciembre 2007]

PCI SECURITY STANDART COUNCIL. ‖PCI Data Security Standard‖. [en línea]. Disponible en: https://www.pcisecuritystandards.org/ [Consulta: 04 Marzo 2008]

PORTER, Michael. Competitive Strategy. New York: The Free Press, 1980. PRATT, Danielle. The Healthy Scorecard: Delivering Breakthrough Results that

Employees and Investors will Love. New Jersey: Paperback, 2003. PYZDEK, Thomas. The six sigma handbook. New York: McGraw-Hill, 2001. PYZDEK, THOMAS.2003. ―DMAIC and DMADV‖. [en línea]. Disponible en:

http://www.pyzdek.com/DMAICDMADV.htm [Consulta: 11 Diciembre 2007] RAMOS WUNDERLER, Alberto. ―Estudos de capacidade para dados ñao-normais‖. [en

línea]. Disponible en: http://www.pro.poli.usp.br/internacional/faculty/alberto-wunderler-ramos [Consulta: 2 de Febrero del 2008]

REZZONICO, Ricardo. Comunicaciones e informes científicos, académicos y profesionales. Córdoba: ComunicArte, 2003.

ROSE, Kenneth. A performance measurement model. USA: Quality Progress, 1995.

SARBANES-OXLEY. ―Sarbanes-Oxley Act of 2002‖. [en línea]. Disponible en: http://www.sarbanes-oxley.com/section.php [Consulta: 04 Marzo 2008]

SECURITY FOCUS. ―How ITIL can improve Information Security‖.[en línea]. Disponible en: http://www.securityfocus.com/infocus/1815 [Consulta: 25 de Febrero del 2008]

SEI. ―What is CMMI?‖. [en línea]. Disponible en: http://www.sei.cmu.edu/cmmi/general/index.html [Consulta: 24 de Junio del 2008]

SEI. 2004. ―Applications of the Indicator Template for Measurement and Analysis‖.[en línea]. Disponible en: http://www.sei.cmu.edu/publications/documents/04.reports/04tn024.html [Consulta: 07 de Junio del 2008]

SENGE, P.M. The fifth discipline – The art and practice of the learning organization. New York: Doubleday, 1990.

SIX SIGMA US. ―Step Six Synergize‖ [en línea]. Disponible en: http://www.6sigma.us/dmaic-step-six-synergize.php [Consulta: 20 Mayo 2008]

SIX SIGMA US. ―What is Six Sigma‖ [en línea]. Disponible en: http://www.6sigma.us/six-sigma.php [Consulta: 11 Diciembre 2007]



THE INSTITUTE OF INTERNAL AUDITORS. 2007. ―About us‖. [en línea]. Disponible en: http://www.theiia.org/theiia/ [Consulta: 11 Diciembre 2007]

TINGEY, M.O. Comparing ISO 9000, Malcolm Baldrige and the SEI CMM for Software. USA: Prentice Hall PTR, 1997.

UNSW. ―Fundamentals of IT Security‖. [en línea]. Disponible en: http://www.itee.adfa.edu.au/coursework/ZITE2302/pdfs/FundamentalsOfITSecurity.pdf [Consulta: 01 de Marzo del 2008]

US DEPARTMENT OF COMMERCE. ―Introduction to Commerce Department Export Controls‖. [en línea]. Disponible en: http://www.bis.doc.gov/licensing/exportingbasics.htm [Consulta: 04 Marzo 2008]

US GAAP. ―US GAAP by Topic‖. [en línea]. Disponible en: http://cpaclass.com/gaap/gaap-us-101.htm [Consulta: 04 Marzo 2008]

WEINBERG, Gerald M. Quality Software management: Volume 2 First-Order Measurement. USA: Dorset House Publishing, 1993.

WET BESCHERMING PERSOONSGEGEVENS (WBP). ―Personal Data Protection Act‖. [en línea]. Disponible en: http://home.planet.nl/~privacy1/wbp_en_rev.htm [Consulta: 04 Marzo 2008]

WIKIPEDIA. ―Power Philosophy‖. [en línea]. Disponible en: http://en.wikipedia.org/wiki/Power_(sociology)#Types_and_sources_of_power [Consulta: 02 de Junio del 2008]



VI. Apéndices

APÉNDICE 1. MONTHLY OPERATION REVIEW PRESENTATION - ARGENTINA

En el presente apéndice se muestra un ejemplo tipo de reporte mensual, realizado por el área de IT. Correspondiente al mes de Octubre del año 2007, por parte de la sucursal de Motorola en Córdoba, Argentina. Existe un repositorio de presentaciones, por mes y año, al que pueden acceder en cualquier momento los gerentes y directores regionales del negocio para su revisión.











APÉNDICE 1. IT SLA PERFORMANCE DASHBOARD - ARGENTINA

(Last update: 04 May 2007)

IT Service Delivery Organization

SLA Coordinator XXX

IT Service Delivery Center Manager XXX

IT Country Manager XXX

IT Regional Operations Manager XXX

Overall Service Delivery Health

VOC Schedule Cost Resources Risk

Key Performance Indicators

Key Performance Indicators Goal Expected

Goal Performance Status

Service Desk Performance - % Calls resolved satisfactorily

=>80% =>90% 100%

Service Desk Efficiency - Problem Resolution Age

=<14 =<7 =<1

Service Desk Efficiency - Service Resolution Age

=<30 =<14 =<14

Service Desk Effectiveness - Problem Backlog

=<7 =<7 =<1

Service Desk Effectiveness - Service Backlog

=<30 =<14 =<6

Network Management - WAN - Availability / Performance and Quality of the Network

170ms 162ms 189ms

Network Management - WAN - WAN/LAN Availability

99.92% 99.996% Metrics

unavailable

Network Management - WAN - Internet Access Availability

99.99% 99.999% Metrics

unavailable

Network Management - Circuit Quality 99.86% 99.963% Metrics

unavailable

http://set.mot.com/twiki4/bin/view/Saydo/SlaArgentina?sortcol=0;table=2;up=0#sorted_table










APÉNDICE 2. IT SLA PERFORMANCE DASHBOARD - AUSTRALIA



Center SLA Coordinator XXX





SLA Schedule Cost Resources Risk

Scheduled Activity Planned Act/Fcst Status

SW Build Time & DR Improvement (ITG 39341)

31 Dec 2007

Lab Process Improvement (ITG 39342) 31 Aug 2007

ISO17799 Remediation (ITG 39344) 31 Aug 2007

Application Improvement Project (ITG 39345) 31 Aug 2007

Desktop Virtualization (ITG TBA) 28 Sep 2007

Cost and Resources Planned Act/Fcst Status

Capital budget (in USD) XXK (additional being

planned)

Full time IT staff 4

IT contractors 1.5

Key Performance Indicators Min. Goal Target Goal Performance Status


=>83.75% =>93.56% 100%


Metric definition in

progress


progress 5.17



progress


progress 0.39



progress


progress 12



progress


progress 5

Network Management - WAN - Performance and Quality of the

206 ms 194 ms No CSC metrics



Network available

Network Management - WAN - WAN/LAN Availability

99.923% 99.996% No CSC metrics

available



available

Network Management - Circuit Quality


available

Network Management - WAN/LAN Problem Resolution

% =>80% =>90%

No CSC metrics

available

MRD & Utility Server Management - Application

Server Availability 98% 99.68% 98.0%

MRD & Utility Server Management - Infrastructure and Utility Server Availability

98% 99.68% 99.75%

Information Security - Maintain security compliance levels as

per MIPS, Vulnerabilities remediation, Antivirus & MCERT

patch

98% 100% 100%

Audit & Compliance - Compliance ISO17799

<2 major non conformance,

Lvl 2

No non conformance,

Lvl 3

No major non conformance

Audit & Compliance - Action item closure Status

On Site Audit 2006, Action

Items Addressed

On Site Audit 2006, Action

Items addressed

In Progress

Disaster Recovery - Compliance 90% by 3Q 100% by 3Q 100%

Customer Satisfaction - Overall Satisfaction with IT Services

=>3.75/5.0 =>3.25/5.0 No Survey

Metrics Available



APÉNDICE 3. IT SLA PERFORMANCE DASHBOARD - CANADA

(Last update: 05 Apr 2007)









Capital budget (in USD) 0

Full time ITIS staff 6

IT contractors 1



>85% >93% 77.9


Metric definition in progress











Network Management - WAN Performance and Quality of

the Network 57 ms 55 ms

Network Management - WAN/LAN Availability

99.99% 99.999%


99.99% 99.999%


99.862% 99.963%


% =>80% =>90%


=>99.9% =>99.95% 99.9



Server Availability


=>99.9% =>99.95% 99.9

Information Security - Maintain security compliance levels

98% 99% 99%

Audit & Compliance - Compliance to ISO17799

<2 Major non conformance, Lvl

2

No Major non-conformance, Lvl 3


Action items addressed

Action Items addressed

Disaster Recovery - Compliance

90% by 3Q 100% by 3Q 100%

Customer Satisfaction - Overall Satisfaction with IT

Services >3.75/5.0 >4.0/5.0 4.02



APÉNDICE 4. IT SLA PERFORMANCE DASHBOARD - CHINA










SOP upgrade 31 Jul 2007

Network upgarde 5 Mar 2007

LTO3 SAN backup implementation 10 Mar 2007

lab Migration 26 Feb 2006

Clearcase CC vob list deployment( including website) implement

30 Jun 2007


Capital budget (in USD)

Full time ITIS staff 10

IT contractors 13



=>80% =>90% 99%


=<14 =<7 10.8


=<30 =<14 1.1


=<7 =<7 0.06


=<30 =<14 0.71


Network 206 ms 194 ms

No CSC Metric

available


99.998% 99.998% No CSC Metric

available

Network Management - WAN - 99.990% 99.999% No CSC



Internet Access Availability Metric available


99.862% 99.963% No CSC Metric

available

Network Management - WAN/LAN Problem Resolution %

=>80% =>90% No CSC Metric

available


Server Availability 99.50% 99.90% 100%

MRD & Utility Server Management - Infrastructure and

Utility Server Availability 99.50% 99.90% 100%

Information Security - Maintain security compliance levels as per

MIPS, Vulnerabilities remediation, Antivirus & MCERT

patch

99% 100% 100%


<2 major non conformance,

Lvl 2

No major non conformance , Lvl 3




done



=<3.90/5.0 =<4.20/5.0 4.25



APÉNDICE 5. IT SLA PERFORMANCE DASHBOARD - INDIA










Build Environment 20 Feb 2007

SAN setup 5 Mar 2007

PowerBroker? Pilot & implementation 20 Feb 2007


Capital Budget (in USD) K

Full Time IT Employees 18

IT Contractors 48



=>80% =>90% 99.38%


=<14 =<7 0.63


=<30 =<14 0.51


=<7 =<7 1.29


=<30 =<14 1.48



No CSC Metric

available


99.923% 99.996% No CSC Metric

available


99.990% 99.999% No CSC Metric

available

http://set.mot.com/twiki4/bin/edit/Saydo/PowerBroker?topicparent=Saydo.SlaIndia




99.862% 99.963% No CSC Metric

available

Network Management - WAN/LAN Problem Resolution %

=>80% =>90% No CSC Metric

available

MRD & Utility Server Management - Application Server

Availability 98% 99.9% 98%

MRD & Utility Server Management - Infrastructure and

Utility Server Availability 99% 99.9% 98%


98% 100% 99%


Lvl 2 Lvl 3 No major non confromances


Action items

addressed


Working on the action

items & target dates



=>3.75/5.0 =>4.25/5.0 Q3'2007



APÉNDICE 6. IT SLA PERFORMANCE DASHBOARD - ITALY










Capital budget (in USD) TBD


IT contractors 1


Min. Goal Target Goal Performance Status


>57.8% >66.5% 50%


<8 <4 3


<5 <3 3

Service Desk Effectiveness - Problem

Backlog <19 <11 10

Service Desk Effectiveness - Service

Backlog =<54 =<38 49

Network Management - WAN Performance and Quality of the Network

185 ms 180 ms No Downtime


99.941% 99.998% No Downtime

Network Management - WAN - Internet Access

Availability 99.990% 99.999% No Downtime


99.862% 99.963% No Downtime



Network Management - WAN/LAN Problem

Resolution % >57.8% >66.5% No Downtime


Server Availability 99.9% 99.995% 98.256%

MRD & Utility Server Management -

Infrastructure and Utility Server Availability

99.9% 99.995% 100%

Information Security - Maintain security

compliance 99% 100% 100%


Lvl 2. Internal audit 2007.

Lvl 2 Compliant (Level

2). Self audit completed


Action items identified and

addressed

Action items closure in progress

Action items closure in progress


90% by 3Q 100% by 3Q 100 %

Customer Satisfaction - Overall Satisfaction with

IT Services >3.75/5.0 4.25/5.0 4.8



APÉNDICE 7. IT SLA PERFORMANCE DASHBOARD - MALAYSIA










ISO17799 Conformance Automation & Improvement

2 Apr 2007

Net phase 2 4 May 2007

Malaysia Server Support Model 28 Mar 2007

Automated WorkFlow? Engineering System 13 Feb 2007

Clearcase Platform Hardening 30 Apr 2007


Capital budget (in USD) XXXK


IT contractors 1



=>80% =>90% 98.73%


=<14 =<7 0.26


=<30 =<14 0.36


=<7 =<7 0


=<30 =<14 1

Network Management - WAN Performance and Quality of the


No CSC Metric

available



available


http://set.mot.com/twiki4/bin/edit/Saydo/WorkFlow?topicparent=Saydo.SlaMalaysia



Internet Access Availability metrics available


99.862% 99.963% No CSC Metric

available


% >80% >90%

No CSC metrics

available


Server Availability 99.9% 99.95% 99.98%


99.9% 99.95% 99.99%


99% 100% 100%


<2 Major non conformance,

Lvl 2

0 Major non conformance,

Lvl 2 1 Minor





Disaster Recovery - Compliance 90% 100% 100%


> 3.75/5.0 4.25/5.0 N/A



APÉNDICE 8. IT SLA PERFORMANCE DASHBOARD - POLAND




ITIS Service Delivery Center Manager XXX

ITIS EC Country Manager XXX

ITIS EC Regional Operations Manager XXX




Postponed! Upgrade of ClearCase? architecture

27 Nov 2006


Capital budget (in USD) XXX k carried over from

2007


IT contractors 0



>85% >90% 97.8%


8 4 2.12


8 4 2.17


20 12 16.4


20 12 3.3



CSC metrics unavailable


99.941% 99.998% CSC metrics unavailable





Network Management - >80% >90% CSC metrics

http://set.mot.com/twiki4/bin/edit/Saydo/ClearCase?topicparent=Saydo.SlaPoland



WAN/LAN Problem Resolution %

unavailable


Server Availability 99.82% 99.95% 99.996


99.9% 99.95% 99.743

Information Security - Maintain security compliance levels as

per MIPS, Vulnerabilities remediation, Antivirus & MCERT

patch

98% 100% 99.18


<2 Major non conformance,

Lvl 2


Lvl 3

Self-audit ISO17799+

scheduled to be done by

the end of Q2 2007




new action items to be defined and resolved by

the end of Q3 2007

Disaster Recovery - Compliance 90% by 3Q 100% by 3Q

80% (for 2007: BIA updates

needed; test plan needs to

be completed)


=>4.05/5.0 4.25/5.0 4.62/5.0



APÉNDICE 9. IT SLA PERFORMANCE DASHBOARD - SINGAPORE










DRP review 31 Mar 2007

Clearquest password synchronization with LDAP server

31 Mar 2007

Migration of unix application server to V210 machine

31 Mar 2007


Capital budget (in USD)Yr 2006 Xxx K

Capital budget (in USD)Yr 2007 Xxx K


IT contractors 2



=95.0% =>97.5% 98.88%


=<14 days =<7 days 2.57 days









No CSC metric

available


99.986% 99.998% No CSC metric

available




Internet Access Availability metric available


99.862% 99.963% No CSC metric

available


%


progress


progress

Metric collection in

progress




99.0% 99.0% 100%


95% 100% 100%


<2 Major Non conformance, Lvl 2,On site Audit 2006


Lvl 2

0 Major Non conformance






Customer Satisfaction - Overall Satisfaction with ITI Services Yr

2006 >3.75/5.0 4.25/5.0 3.91



APÉNDICE 10. IT SLA PERFORMANCE DASHBOARD - RUSSIA










Main IT Projects


Capital budget (in USD)


IT contractors 6


Min. Goal Target Goal Performance Status

Service Desk Performance - % Problem Calls resolved

satisfactorily =>80% =>90% 98.76%


(Biz. Hrs) =<14 =<8 4.56


(Biz. Hrs) =<30 =<14 7.99

Service Desk Effectiveness - Problem Backlog (Time to

Respond - Biz. Hrs) =<7 =<7 0.59

Service Desk Effectiveness - Service Backlog (Time to

Respond - Biz. Hrs) =<30 =<14 0.66

Network Management - WAN Performance and Quality of the Network

220 ms 180 ms 72.71 ms


99.941% 99.998% 100%

Network Management - WAN - Internet Access

99.0% 99.1% 99.24%



Availability


99.862% 99.963% CSC metric is

attached (graph)

Network Management - WAN/LAN Problem

Resolution % =>80% =>90% 96.41%



MRD & Utility Server Management -

Infrastructure and Utility Server Availability

99.9% 99.95% 99,96%


97% 100% 99,12%


<2 Major Nonconformance,

Lvl 2

0 Major non conformance.

Lvl 3

No Major Nonconformance


On-site Audit 2006, Action

items addressed


Self-audit ISO17799+ in

Oct'06


90% 100% 90%

Customer Satisfaction - Overall Satisfaction with IT

Services >3.75 / 5.0 4.25/5.0 4.17/5.0



APÉNDICE 11. IT SURVEY ANALYSIS REPORT CCS 2002 – ARGENTINA

1.0.0

© COPYRIGHT 2001 Revision History

Version Date Summary of Changes Author

1.0.0 18-Dec-2002

Baseline XXX

Survey Identification

Survey Number 02

Section Name IT

Survey Date

Assigned QS XX

Section Representatives

Position Name Interview Time

Manager XX

Analysis Purpose and Scope The purpose of this Analysis will be to ascertain the IT Department customer satisfaction survey validity. Also, Root Cause Analysis will be used to determine the main antecedents of the level achieved. Finally some actions tending to improvement will be delineated. Validity of the survey The Customer Satisfaction level was measured though a single question. The same approach is used by the site to assess the satisfaction of customers. Root Cause Analysis •Distribution of answers was normal, with a mean on 8.23 (excluding one outlier) •Significant increase on overall satisfaction level from last survey. Less significant increase on dimensions of this main constructor •General image of the area improved. Main areas to continue improvement: Availability of helpdesk, visibility of request status, alignment with business needs. Improvement Areas (survey process)



Conclusions •Validity and consistency of this survey improved compared to the first. •Increments on overall satisfaction solved the initial image/communication problem, will be harder to obtain. •Quality recommendations: -Obtain direct feedback (focus group?) on how to improve help desk availability. -Examine actions on IT every WPR -Be aware of dimensions not covered by the survey (e.g. the fact that requests are prioritized does not mean engineers agree on the way this is done) Metrics Audit effort Qlty: Preparation: 1 staff/hour Analysis: 1 staff/hour Reporting: 1.5 staff/hour



APÉNDICE 12. IT SURVEY ANALYSIS REPORT CCS 2003 - ARGENTINA

1.0.2 © COPYRIGHT 2001

Revision History Version Date Summary of Changes Author 1.0.0_Draft_A 30-Jun-2003 Base on CSS internal template. Xxxx 1.0.0_Draft_B 1-Jul-03 Basic outline of the process establish and ready to sent to approval. 1.0.0 1-Jul-03 Ready to approval. Xxxx 1.0.1 16-Jul-03 Results Presentation XXX Xxxx 1.0.2 16-Jul-03 Results Presentation XXX Xxxx 1 Survey Planning 1.1 Survey Identification and Requirements Survey Number 01-Internal CSS Section Name IT Survey Date 02-Jul-03 Assigned Staff ZZZ Section Representatives Position Name Software Eng. ZZZ IT Manager XzZ Req1: Perform an internal CSS survey Req2: 02-Jul-2003 shall run the survey (7 days open) Req3: The row data provided by WebSurvey tool will be process 1.2 Schedule Main Task Due Date Responsible % Complete Obtain a draft of the Questions 01-Jul-03 Xzz 100% Prepare the first draft of the survey 01-Jul-03 Xzz 100% Validate the draft of the survey 01-Jul-03 ZZZ 100% Run the survey 02-Jul-03 ZZZ 100% Process the raw data 10-Jul-03 / 17-Jul-03 ZZZ 100% Present the results to IT Manager 17-Jul-03 ZZZ 100% 2 Survey Results 2.1 Analysis Purpose and Scope The purpose of this Analysis will be to ascertain the IT Department customer satisfaction survey validity. Also, Root Cause Analysis will be used to determine the main antecedents of the level achieved. Finally some actions tending to improvement will be delineated.



For validate the survey contents we will perform test under WebSurvey tool environment to determinate the accuracy of the body of questions presented to the final user. 2.2 Survey Design The survey will be design using a basic template provide by IT Department at Argentina. For prototyping proposes we will use WebSurvey tool and IT Manager will validate that draft before sending it to site staff 2.3 Validity of the survey The Customer Satisfaction level was measured though a single question. The same approach is used by the site to assess the satisfaction of customers. Raw Data Processing 3 Root cause analysis The high overall CSS rating, 8.45, reflects the proficiency in the timely solutions of problems based in the high skills of the team. However non-satisfactory ratings in attitudinal items might indicate that if this gap (technical skills vs attitude) were smaller overall ratings could be even higher. 4 Conclusions Answers to question “AVERAGE NUMBER OF INDIVIDUALS / TIMES HAVE YOU

HAD TO CONTACT I.T. BEFORE PROBLEM RESOLUTION or SERVICE

DELIVERY” indicates more than one person needs to be contacted before problem

resolution in a 33.33% of the cases. Answers to questions ―Employees are courteous, responsive‖ are overall

satisfactory, but 28.21% between Neutral to Very Dissatisfied should be kept in mind for Help Desk planning. This answer impacts over others related such as ―I.T. staff is approachable, responsive, courteous and customer focused‖ where Neutral to Very Dissatisfied account for 43.59% of the total.

Questions related to commitment to the external customers of the organization, such as ―I.T. responsiveness to special project needs according to your plans‖ reflects to Neutral to Very Dissatisfied perception about 30%. Other questions impacted by this issue are: ―I.T. Business Understanding to serve your business needs & your planning‖ where the same range accounted for 25.64% of the answers. All answers in this section are impacted by this perception.

In Overall Satisfaction & Qualitative Comments the results are remarkable. The internal CSS score arise to 8.45 for local IT and 7.26 for IT Buenos Aires.

Regarding to this topic‖ Third Party‖ the most significant problem is VoIP with 56.41% answers in the range Neutral to Very Dissatisfied.

Regarding to open ended questions these are the comments of the survey: On I.T. SERVICES SATISFACTION: (Provide your comments on what services

and capability you are most and least satisfied with and why) Response 1. IT performs a very good job. Always is available to solve our area's problems and to provide advice. 2. The capability to get the entire job done with few human resources. 3. The people should be more polite when other engineers request their services. 4. IT services always works excellent.



5. I am very satisfied with the efficiency of the team, how quickly they solve every problem I might have, how they follow procedures and help me to do so too. I am also very satisfied with the team behavior; they are very nice and patient. 6. In my opinion IT members responds to our requests properly. I think that IT should research for free/available licenses from other centers (not only GSG). When buying licenses those licenses should be purchased with the possibility of sharing within the company. Provide your comments on what services and capability you consider the IT strong points Response 1. * Organization. * Communication. 2. The quick IT response. 3. Time to solve tickets. 4. Strong capabilities in time response and server/service availabilities. 5. IT strong point: their proficiency in a variety of systems programs and processes. Very helpful to clear out doubts and give tips. 6. High commitment with IT policies. 7. Fast Response in common problems 8. I am very satisfied with Day-to-day well known tasks and with the overall services and security strategy. 9. The staff. 10. The responses you give for standard requests (without considering software licenses...) and tickets. 11. Your internal organization. 12. Your responsibility and commitment. Provide your comments on what services and capability you consider the IT opportunities points Response 1. * Customer care. 2. I know that the IT resources are not enough for all the job that is required, but sometimes the IT people are not very kind to those who come with some doubt or a simple question. 3. The MONET Ticket doesn't have a possibility to attached files, and some times it is necessary to attach some files. 4. They could provide an even faster service if there were more people in the team. There are too many of us at the Center for the support of just a group of three. 5. An opportunity to improve is that we have to do all the work related with getting the license for all software installation requests. For some projects there are specific needs and we can not install software until the fulfillment of all the policies. We feel alone during this process. 6. Better understanding of customer business requirements that don't fit with the SLA (need to adapt SLA) 7. I feel there is still room for improvement in projects special requests, odd environments and installations. There should at least be a defined strategy and process



well communicated to all IT staff and ops engineers. That would save effort and time to all of us. 8. Technology roadmap is not an IT responsibility, leave it to the SEPG. 9. Don't delay project due to licenses problems. Whenever there's the need of going on with the project and the commitment to buy the licenses if necessary, avoid stopping the project until you have clear what should be done. We can go on and purchase the licenses once we have clear what we own and what we don't. 10. Be careful with the reading you do of the policies (mainly EISS) because in several cases you've delayed project. Try to be more flexible. Provide your comments on what services and capability you consider the Third Party opportunities points Response 1. Enhance responsiveness to unplanned requirements originated by changes from customer. 2. VOIP could be much better. It cuts off often, there are "silence" spells during conference calls. These are recurrent problems. Provide your comments on what services and capability you consider GIS (Bs As) strong points Response 1. None. Not only that I cannot see any kind of work from their part, but also I can hear the problems that they cause to our local IT dept. 5 Metrics Effort (staff/hrs) Survey Identification and Requirements: 4hs Analysis Purpose and Scope: 1hs Survey Design: 1hs Validity of the survey: 2hs Raw Data Processing and Conclusions: 2hs Product Versioning: 2hs 6 Product Versioning and Storage




1.0.0 XXX

© COPYRIGHT 2004 Revision History Version Date Summary of Changes Author 1.0.0_Draft_A 28-May-2004Initial version xxx 1.0.0 28-May-2004Reviewed by xxx 1 Survey Identification Survey Id 2004Q1_ITCSS Section Name I.T. Survey Date 04-May-2004/28-May-2004 Assigned QS xxx Section Representatives Position Name Interview Time Manager zzzz 0.5 hs 2 Analysis Purpose and Scope The purpose of this Analysis will be to ascertain the I.T. Department customer satisfaction survey validity. Also, Root Cause Analysis will be used to determine the main antecedents of the level achieved. Finally some actions tending to improvement will be delineated. 3 Results Analysis 1.1. Overall Customer Satisfaction The Customer Satisfaction level was measured though a single question. The same approach is used by the site to assess the satisfaction of customers. As shown in figure 1, the average overall customer satisfaction was 8.87 (computed including the 47 survey respondents), which is above the 8.75 goal. Nonetheless, further analyses were made in order to determine the clustering of the responses. As shown in figure 2 the overall satisfactions remains above the goal in all cases except for the oldest group (the median for employees older than 18 month is below the established goal). Figure 3 shows the distribution in percentages of the values obtained for the question.



10987

Median

Mean

9.29.08.88.68.48.28.0


V ariance 0.7225

Skewness 0.03053

Kurtosis -1.15801

N 47

Minimum 7.0000

A -Squared


Median 9.0000


Maximum 10.0000


8.6228

3.27

9.1219


8.0000 9.0000


0.7063 1.0676

P-V alue < 0.005

Mean 8.8723

StDev 0.8500


Summary for Overall Customer Satisfaction

Figure 1: Summary of Overall Customer Satisfaction

Figure 2: Overall customer satisfaction clustered by respondent time as an employee



Figure 3: Overall customer satisfaction distribution

1.2. Services Overall Customer Satisfaction For each primary service identify within the area, a question was included in the survey in order to determine the overall customer satisfaction for the service. As shown in figure 4, all the services, showed a notably stability and a very low dispersion.

Figure 4: I.T. services customer satisfaction

13, 27.7%

16, 34.0%

17, 36.2%

1, 2.1%

Category

7

8

9

10

Overall Customer Satisfaction Distribution

Labels indicates: number of respondants, percentages

Da

ta

CapabilityResponsivenessHelp deskServices availability

10

9

8

7

6

8.758.808518.6383

8.851068.76596

Boxplot of I.T. Services



An important remark is that the all identified services were highly correlated to the overall customer satisfaction (as shown in Figure 5). This situation out stands the importance of these items to the overall satisfaction of the customer.

Figure 5: Overall customer satisfaction and air conditioning service correlation

1.3. Summary of Questions Results

For all the questions included in the survey a mean analysis was performed to determine opportunities of improvement. Figure 6 and Figure 7 summarize both, the questions and its results.

I.T. internal Customer Satisfaction Survey

1) How long have you been a ZZZ employee? * (Required)

2) How often (Average) do you need to contact I.T. for services? * (Required)

3) What method do you use to contact I.T. and find effective?* (Required)

4) Wich is your most frequently used environment? * (Required)

5) Average number of individuals / Times you had to contact I.T. before problem resolution or service delivery: * (Required)

6) What is your overall satisfaction with the support given by your local I.T. department? * (Required)

7) I.T. delivers quality solutions (Systems, Hardware, Software, Network, Mail, file server, print server, Data Mgt etc) that meet your business requirements

8) I.T. delivers quality services (helpdesk etc) that meet your business requirements

9) Solutions are secure and integrity of data is preserved

10) Solutions and service add value to your business

11) Are you satisfied with the level of compliance of the SLA by IT area and approved by the management.

12) What is your overall satisfaction with I.T. services availability? * (Required)

Correlations: Overall Customer, Help Desk, Responsiveness, Capability Overall Cust.Sat. Help Desk Responsiveness

Help Desk 0.641

0.000

Responsiveness 0.607 0.697

0.000 0.000

Capability 0.744 0.741 0.800

0.000 0.000 0.000

Cell Contents: Pearson correlation

P-Value



13) I.T. Services such as WAN, LAN, Servers and desktops are available to support the business

14) Applications like Mail, tools like Clearcase are available

15) Duration, frequency of unscheduled systems & Network outages

16) Computer performance & Network responses are satisfactory

17) New Service / enhancements /migrations are implemented with minimal disruption

18) What is your overall satisfaction with I.T. Problem Management (Help Desk Services)? * (Required)

19) Employees are courteous, responsive

20) Helpdesk/employees have the technical ability to resolve or escalate the problem or service request

21) Availability of Helpdesk/employees satisfies your needs

22) I.T. updates you of status of your problem/request

23) Turnaround time for fixing your request meets your expectations & SLA

24) What is your overall satisfaction with I.T. responsiveness? * (Required)

25) I.T. Response to Routine Service Request

26) I.T. Response to Emergency Service Request according to the ticket priority you select

27) I.T. staff is approachable, responsive, courteous and customer focused

28) I.T. Time Frame for Services provisioning adecuate

29) I.T. responsiveness to special project needs according to your plans

30) Have I.T. prioritized your requests into Routine, Emergency, etc according to the SLA & your MONET selection

31) What is your overall satisfaction with I.T. capability? * (Required)

32) I.T. Technical capability to handle Services Provisioning and Problem Management

33) I.T. Business Understanding to serve your business needs & your planning

34) I.T. Planning and Project Management capability to meet commitments and appointments with customer according your requests & planning

35) I.T. Communication Capability to convey plans, update customers

36) I.T. Deployment capability for new systems, software that meet customer expectations & agree the SLA

37) I.T. Strategic Planning, Long-Range Planning, and Technology Roadmap Planning for the Center

38) I.T. Capacity Planning & Growth expansion handling

39) Could you name some improvement opportunity for the I.T. Department?

40) Other comments



Figure 6: Survey Questions

Da

ta

Q38

Q37

Q36

Q35

Q34

Q33

Q32

Q31

Q30

Q29

Q28

Q27

Q26

Q25

Q24

Q23

Q22

Q21

Q20

Q19

Q18

Q17

Q16

Q15

Q14

Q13

Q12

Q11

Q10Q

9Q8

Q7

Q6

9.5

9.0

8.5

8.0

7.5

8.75

8.8

7234

8.7

2727

8.2

5

8.1

5

8.6

383

8.9

3023

8.6

0976

8.6

8293

8.9

5122

8.9

2105

8.8

5106

8.7

6316

8.7

9545

8.8

1081

8.6

0465

8.6

8421

8.6

5789

8.6

1111

8.7

6596

8.6

1111

8.1

7647

8.5

8.5

8.8

8372

8.5

8.3

871

8.58

.55263

8.5

8.8

0851

8.8

25

7.8

25

8.6

75

95% CI for the Mean

Interval Plot of Q6 to Q38

Figure 7: Average value for survey responses.

Figure 7 show that some services are consistently not reaching the expected goal (Q14, Q17 and Q33). Although they do not have a remarkable influence over the overall customer satisfaction, they can be used as opportunities to improve it.

4. Open ended questions, Could you name some improvement opportunity for the I.T.?

Upgrade the Pentium III machines

A search engine to find software licenses availability like the one in Tucows or Download.com will be great.Keep like this, you're doing great!

If something needs checking and/or verification, do not make the user do it for you: he/she may not have the skills/tools to accomplish this task. While this may help balance your workload, the user ends up spending way more time than a knowledgeable IT professional would have invested go get the job done.

- Decrease the number of unplanned system activities. - Present in a regular basis the area status in WPRs. - Consider internal time buffers to attend special project needs. IT area is making a great job by fulfilling all Organizational requests! Thanks!

I don't know if it's for IT or Facilities department, but I think, could be interesting to have a power backup regarding to power outage.

Need more focus on customer. IT sector is extremely efficient in implement all patches, latest versions and IT mandates and not always this is the better solution to our customers. Customers need flexibility, this does not mean that they have to break the



rules, but more tolerance is desirable. Other centers has the same hardware but the efficiency of the software installed is superior. There are a lot of paperwork in IT related work. All these management approvals are very time consuming and don't add any value to our customers neither the center, since this data is just in paper and not metrics are collected using that. IT did a great work in setting up a define process. Now is time to improve the process doing it more efficient and not so defensive.

Apply a more rigorous project management approach to migrations, deployments, etc.

Clearcase need special attention, because is so slow that the work can hardly be done.

Please, let us define the priority of the tickets we generate. It's stupid to have the possibility of giving different levels of priority to the tickets and not being allowed to use them. IT shall have a more cooperative look at project needs that fall outside of any SLA. It shall first consider the business (projects) needs, and then providers and its own requirements. It doesn't make sense preventing a project from going-on just because of a particular interpretation of a policy.

5. Conclusions

The data shows a remarkable low dispersion within questions. In consequence the summary of data showed above seems to represent accurately the general perception of the service provided by the I.T. department.

The analysis of the overall customer satisfaction shows the principal opportunity of improvement in the ―clear case tool‖ area. Also, although a high level overall customer satisfaction, services means by itself are in general not much above the goal and in a lot of cases (21 out of 32) are under the goal.

Finally, a causal analysis is suggested in order to prioritize the areas to be adjusted in the near future and to segregate the areas that really need improvement from those that need maintenance.

6. Metrics: Survey Design: 6 staff/hour; Reporting: 3 staff/hour




1.0.0 XXX

© COPYRIGHT 2005 Revision History Version Date Summary of Changes Author 1.0.0_Draft_A 28-Jun-2005 Initial version XXX 1.0.0 28-Jun-2005 Reviewed by ZZZ XXX 1 Survey Identification Survey Id 2005Q2_ITCSS Section Name I.T. Survey Date 01-Jun-2004/28-Jun-2004 Assigned QS XXX Section Representatives Position Name Interview Time Manager ZXX 0.5 hs 2 Analysis Purpose and Scope The purpose of this Analysis will be to ascertain the I.T. Department customer satisfaction survey validity. Also, Root Cause Analysis will be used to determine the main antecedents of the level achieved. Finally some actions tending to improvement will be delineated. 3 Results Analysis 1.1. Overall Customer Satisfaction The Customer Satisfaction level was measured though a single question. The same approach is used by the site to assess the satisfaction of customers. As shown in figure 1, the average overall customer satisfaction was 8.16 (computed including the 66 survey respondents), which is below the 8.75 goal. Nonetheless, further analyses were made in order to determine the clustering of the responses. As shown in figure 2 the overall satisfactions remains below the goal in all cases except for the newest group (the median for employees with less than 6 month as Motorolan is above the established goal). Figure 3 shows the distribution in percentages of the values obtained for the question.



10864

Median

Mean

9.08.88.68.48.28.07.8


V ariance 2.8795

Skewness -1.43805

Kurtosis 2.12492

N 66

Minimum 3.0000

A -Squared


Median 9.0000


Maximum 10.0000


7.7495

3.49

8.5838


8.0000 9.0000


1.4487 2.0485

P-V alue < 0.005

Mean 8.1667

StDev 1.6969


Summary for Overall Customer Satisfaction - 2Q2005

Figure 1: Summary of Overall Customer Satisfaction

Figure 2: Overall customer satisfaction clustered by respondent time as employee



12, 18.2%

24, 36.4% 13, 19.7%

8, 12.1%

4, 6.1%

2, 3.0%3, 4.5%

Category

8

9

10

3

5

6

7

Overall Customer Satisfaction Distribution - 2Q2005


Figure 3: Overall customer satisfaction distribution

1.2. Services Overall Customer Satisfaction For each primary service identify within the area, a question was included in the survey in order to determine the overall customer satisfaction for the service. As shown in figure 4, all the services, showed a notably stability and a very low dispersion.

Data

CapabilityResponsivenessHelp deskServices availability

10

9

8

7

6

5

4

3

8.75

8.090918.25758 8.36364 8.27273

Boxplot of I.T. Services

Figure 4: I.T. services customer satisfaction.



An important remark is that the all identified services were highly correlated to the overall customer satisfaction (as shown in Figure 5 ). This situation outstands the importance of these items to the overall satisfaction of the customer.

Figure 5: Overall customer satisfaction and air conditioning service correlation

1.3. Summary of Questions Results For all the questions included in the survey a mean analysis was performed to determine opportunities of improvement. Figure 6 and Figure 7 summarize both, the questions and its results. I.T. internal Customer Satisfaction Survey 1) How long have you been a Motorola employee? * (Required) 2) How often (Average) do you need to contact I.T. for services * (Required) 3) What method do you use to contact I.T. and find effective * (Required) 4) What is your overall satisfaction with the support given by your local I.T. department? * (Required) 5) I.T. delivers quality solutions (Systems, Hardware, Software, Network, Mail, file server, print server, Data Mgt etc) that meet your business requirements 6) I.T. delivers quality services (helpdesk etc) that meet your business requirements 7) Solutions are secure and integrity of data is preserved 8) Solutions and service add value to your business 9) What is your overall satisfaction with I.T. services availability? * (Required) 10) I.T. WAN Services are available to support the business 11) Applications like Mail, tools like Clearcase are available 12) Duration, frequency of unscheduled systems & Network outages 13) Computer performance & LAN Network responses are satisfactory 14) New Service / enhancements /migrations are implemented with minimal disruption 15) What is your overall satisfaction with I.T. Problem Management (Help Desk Services)? * (Required) 16) Helpdesk/employees have the technical ability to resolve or escalate the problem or service request 17) Availability of Helpdesk/employees satisfies your needs

Correlations: Overall Customer, Help Desk, Responsiveness, Capability

Overall Cust.Sat. Availability Help Desk Responsiveness

Availability 0.877

0.000

Help Desk 0.914 0.825

0.000 0.000

Responsiveness 0.799 0.861 0.770

0.000 0.000 0.000

Capability 0.800 0.795 0.813 0.758

0.000 0.000 0.000 0.000

Cell Contents: Pearson correlation

P-Value



18) I.T. updates you of status of your problem/request 19) Turnaround time for fixing your request meets your expectations & SLA 20) What is your overall satisfaction with I.T. responsiveness? * (Required) 21) I.T. Response to Routine Service Request 22) I.T. Response to Emergency Service Request according to the ticket priority you select 23) I.T. staff is approachable, responsive, courteous and customer focused 24) I.T. Time Frame for Services provisioning adequate 25) I.T. responsiveness to special project needs according to project plans 26) Have I.T. prioritized your requests into Routine, Emergency, etc according to the SLA & your MONET selection 27) What is your overall satisfaction with I.T. capability? * (Required) 28) I.T. Technical capability to handle Services Provisioning and Problem Management 29) I.T. Business Understanding to serve projects' needs & planning 30) I.T. Planning and Project Management capability to meet commitments and appointments with customer according your requests & planning 31) I.T. Communication Capability to convey plans, update customers 32) I.T. Deployment capability for new systems, software that meet customer expectations & agree the SLA 33) How do you compare availability of applications like ClearCase with last year service? 34) How do you compare computer performance and network response with last year service? 35) How do you compare disruptions due to migrations and such with last year service? 36) How do you compare I.T. business understanding with last year? 37) Could you name some improvement opportunity for the I.T. Department 38) Other comments

Data

Q32Q31Q30Q29

Q28Q27Q26Q25Q24

Q23Q22Q21Q20Q19

Q18Q17Q16Q15Q14

Q13

Q12Q11Q10Q9

Q8

Q7

Q6

Q5

9.0

8.5

8.0

7.5

7.0

8.75

8.1

6949

7.9

3103

8.2

5758

7.9

0196 8.1

3725 8.4

0385

8.1

5556

8.3

6364

8.2

2727

7.9

7368

7.8

7.9

8.3

4483

7.4

0476

8.1

0256

8.2

7273

7.8

7.2

9268

7.3

4211

7.5

3846

7.5

8

8.0

9091

8.4

8.5

4545

7.9

5918

8.1

4545

8.0

1923

95% CI for the MeanInterval Plot of All questions



Figure 7: Average value for survey responses.

Figure 7 show that the majority of services are consistently not reaching the expected goal. These intervals can be used in order to prioritize the existent opportunities of improvement. 4 Comparisons and Trends Initial comparisons against last year survey were made to evaluate the evolution of the area and to endure the significance of differences when applicable. Although, trends can’t be generalized with only two data points, it is intended to give a two sample comparison that could lead to some conclusions regarding the evolution of services provided by the area. 1.4. Surveyed comparisons Four questions were explicitly added to the survey in order to compare this year the performance with last year. The following figure depicts the responses obtained in those questions (See questions 33, 34, 35 and 36 in section 3.1.3 for the detail test of the questions included).

2, 3.0%

19, 28.8%

23, 34.8%

22, 33.3%

availability of applications4, 6.1%

27, 40.9%

14, 21.2%

21, 31.8%

comp. and network performance

8, 12.1%

26, 39.4%

10, 15.2%

22, 33.3%

disruptions due to migrations4, 6.1%

27, 40.9%

13, 19.7%

22, 33.3%

I.T. business understanding

Category

Better

Equivalent

Worse

Surveyed Comparisons


Figure 8: Surveyed comparisons responses distributions As indicated in figure 8, the majority of responses indicate that services performance was equivalent to last year, with the exception of the ―availability of application like Clearcase‖ that showed an improvement. Although several respondents didn’t classify the area in these questions, the results could serve to analyze the improvements made in the particular areas included in these responses.



1.5. Trends Analysis As a negative tendency could be seen in the overall customer satisfaction when comparing these results with last year survey, an statistical analysis was performed in order to determine if the difference was ―statistically significant‖ and not within variation introduced by chance. As depicted in figure 9 and 10 a two side comparison of the samples was performed to address this question.

Data

2004 CSS2005 CSS

10

9

8

7

6

5

4

3

Boxplot of 2005 vs 2004 CSS

Figure 9: Two sided comparison boxplot

Two-Sample T-Test and CI: 2005 vs 2004 CSS Two-sample T for Q4 vs 2004 CSS

N Mean StDev SE Mean

Q4 66 8.17 1.70 0.21

2004 CSS 47 8.872 0.850 0.12

Difference = mu (Q4) - mu (2004 CSS)

Estimate for difference: -0.705674

95% CI for difference: (-1.187522, -0.223825) T-Test of difference = 0 (vs not =): T-Value = -2.91 P-Value = 0.005 DF = 101



As depicted in the figures above, the difference between this years overall customer satisfaction and last year is in fact statistically significant, indicating that the reduction in customer satisfaction is an actual phenomena and was not introduced by chance (as indicated by the confidence interval between -1.18 and -0.22). Finally, Appendix A shows a side by side comparison of the graphs included in both surveys to ease the comparison of the reader. 5. Open ended questions, Could you name some improvement opportunity for the I.T. Department you need to show MORE patience and courtesy with your customers take more risks and avoid 'avoiding' responsibilities It would be great if less bureaucracy were needed for installing new software on the user's workstations. I understand this decision is not in IT's hand (at least the local IT staff), and I'm very much satisfied with its responsiveness, but there are two alternatives: 1. One is 'stuck' with the default software installations (Internet Explorer instead of Firefox, Notepad instead of VIM, and so on), or 2. One must ask permission to his/her manager, forward the OK (if this was the case) to IT, and then have the software installed. I fully understand the need for controlled workstations, but nevertheless I think it is a bit too much for me. Clearly the IT Department should focus their improvement on the customer approach , courtesy and customer treatment. Network operations (especially ClearCase operations) are slow. Get more people. we are almost 200 persons and the department has not grown accordingly. Some easy improvements like availability of memory sticks would really facilitate the management of files of the employees (e.g. if i want to work on weekends or at nights i can't take a file with me) Individual PCs maintenance should be done periodically. Increase responsibility over systems (not just maintaining but being responsible) None at all, they do a great job!! IT is an outstanding team, great skills, fast response and very kind, ALWAYS! Wonderful supportive group for the Site. Congratulations. Make procedures less burocracy and more agile Customer adaptation. I suggest, less restriction in common usage of the PCs, restriction in a good way is ok, but extremes are negative. Improve technical capabilities. Allow the free usage of pen drives Focus on projects customers need please, do not the survey so long the next time It should be great and important that IT area improve people treatment and focus more in projects needs not only in policies. They always try to feet to company's policies, and that's great, but they should take more into account the special situations caused by the projects' needs. technical skills I think the only point where I could recommend a change is in the PC configuration. It has too many security checks that are not required inside Motorola intranet, and those checks use some processor capacity. Go ahead as you're doing!!! GREAT JOB!!! This survey must be an anonymous survey.



IT Dept. needs to understand its primary role as a service & support area improving its flexibility to serve changing business needs and growing population in the center, engineers are its end customers and require more focus. IT is quite good at handling routine situations but there is room for improvement in the way they deal with specific problems, escalation to the supplier of a solution may not be enough to solve an actual problem, they should proactively offer alternatives and workarounds. To be more up to date with the very new technologies so that they can be prepared beforehand for new requirements and can implement improvements to the systems. Though all the systems are working perfectly and I have absolutely nothing to say against them. Firewalls are not good enough. There are a lot of trash/spam emails

0. Conclusions The data shows a remarkable low dispersion within questions. In consequence the summary of data showed above seems to represent accurately the general perception of the service provided by the I.T. department. The analysis of the overall customer satisfaction shows the principal opportunity of improvement in the ―business understanding area‖. Nonetheless, the rest of the services still show a qualification near to 8 given the area an important start point from where to build it improvement plans. Finally, a causal analysis is suggested in order to prioritize the areas to be adjusted in the near future and to segregate the areas that really need improvement from those that need maintenance. In particular, the negative evolution of the overall customer satisfaction should be analyzed to undercover any potential cause of dissatisfaction that could be producing such a trend in the future.

1. Metrics Survey effort Survey Design: 2 staff/hour Reporting: 4 staff/hour



APÉNDICE 15. PLANNED & UNPLANNED OUTAGES REPORT - AVAILABILITY Planned & Unplanned Outages

Create a new outage

Graphics statistics

View past outages

No Status Detail Date Time From

Time To

System/s Reason Owner Cancel

1 Closed

As informed by Tools they

need to empty a directory

where Room Booking

temporary files are stored. In

order to do that we need to

stop Web services for a few

minutes. This might solve the

problem with RB application. Services affected: Intranet &

Intranet applications.

2007/11/19 14:00 14:30 Intranet

services Other alm045

2 Closed

Due to a vulnerability in PHP

we have to upgrade PHP

version. Service unavailable

MSG intranet.

2007/11/21 08:00 08:30 ZAR03DHP01 Other arg031

3 Closed

On Friday Nov, 16th Clearcase

services hanged and did not

respond for an hour

approximately. As part of the

troubleshooting indicated by

Rational support we need to

try to reproduce the problem

to find the root cause. CC

services won't be available

during this window.

2007/11/21 20:00 21:00 Clearcase

Services Other alm045

4 Closed

Due to an unsafe set in a

eeprom - autoboot variable.

We have to rebbot this server.

Service affected: VOB server,

home directories, /project

directory

2007/11/23 18:00 19:00 ZAR03UNIX01 Other arg031

5 Cancelled

Server will be rebooted at

6pm since we need to install

Partition Expert software to

resize C:/ partition. Affected

services: Intranet.

2007/11/26 18:00 18:30 ZAR03DHP01 Software

Installation alm045

6 Closed

Due to VBScript56 installation

we need to rebot this server.

Service affected: CQWeb;

oracle 8 server.

2007/11/27 08:00 08:30 zar03ora02 Software

Installation arg031

7 Cancelled

On Friday Nov, 16th Clearcase

services hanged and did not

respond for an hour

approximately. As part of the

troubleshooting indicated by

Rational support we need to

try to reproduce the problem

to find the root cause. CC

services won't be available

during this window.

2007/12/05 18:00 19:00 ClearCase

Services Other tcqn73

http://zar03dhp01/apps/outages/authenticate.php

http://zar03dhp01/apps/outages/authenticate.php

http://zar03dhp01/apps/outages/outagesreport.php

http://zar03dhp01/apps/outages/outagesreport.php

http://zar03dhp01/apps/outages/queries.php

http://zar03dhp01/apps/outages/queries.php





APÉNDICE 16. MAPPING ITIL & ISO 17799 TO COBIT CONTROL OBJECTIVES86

It is only a guide. The mapping is not considered to be definitive or prescriptive. Links are shown at the high level.

86

IT GOVERNANCE INSTITUTE. 2005. ―Aligning CoBIT, ITIL & ISO 17799 for Business Benefit: Management Summary.‖ [en línea]. Disponible en Internet: http://www.itgi.org [Consulta: 25 de Febrero del 2008]










































































APÉNDICE 17. INDICATOR TEMPLATE SEI - CMMI









APÉNDICE 18. MAPPING OF CMMI FOR DEVELOPMENT V1.2 WITH COBIT 4.087

87

ISACA. ―COBIT MAPPING: MAPPING OF CMMI FOR DEVELOPMENT V1.2 WITH COBIT 4.0‖.[en línea]. Disponible en Internet: http://www.isaca.org/ContentManagement/ContentDisplay.cfm?ContentID=31452 [Consulta: 24 de Junio del 2008]

http://www.isaca.org/ContentManagement/ContentDisplay.cfm?ContentID=31452





Date post:	20-Jun-2015
Category:	Documents
Upload:	mteigeiro9822
View:	498 times
Download:	3 times