LINEAMIENTOS PARA LA APLICACIÓN DE LA LEY 527 DE 1999
329
ESQUEMA DE DIAGNÒSTICO PARA LA PROPUESTA DE IMPLEMENTACIÒN ITIL, GESTIÒN DE SERVICIOS, EN LA EMPRESA PUNTO DE SERVICIO S.A GERALDINE GRASS ARDILA CAMILO EDUARDO MORENO SUÁREZ MAURICIO TRUJILLO JACKSON ARTURO VASQUEZ CASTRO UNIPANAMERICANA INSTITUCIÓN UNIVERSITARIA COMPENSAR FACULTAD DE INGENIERIA PROGRAMA DE INGENIERIA DE SISTEMAS BOGOTA D.C 2010
Transcript of LINEAMIENTOS PARA LA APLICACIÓN DE LA LEY 527 DE 1999
1
ESQUEMA DE DIAGNÒSTICO PARA LA PROPUESTA DE IMPLEMENTACIÒN
ITIL, GESTIÒN DE SERVICIOS, EN LA EMPRESA PUNTO DE SERVICIO S.A
GERALDINE GRASS ARDILA
CAMILO EDUARDO MORENO SUÁREZ
MAURICIO TRUJILLO
JACKSON ARTURO VASQUEZ CASTRO
UNIPANAMERICANA INSTITUCIÓN UNIVERSITARIA COMPENSAR
FACULTAD DE INGENIERIA
PROGRAMA DE INGENIERIA DE SISTEMAS
BOGOTA D.C
2010
2
ESQUEMA DE DIAGNÒSTICO PARA LA PROPUESTA DE IMPLEMENTACIÒN
ITIL, GESTIÒN DE SERVICIOS, EN LA EMPRESA PUNTO DE SERVICIO S.A
GERALDINE GRASS ARDILA
CAMILO EDUARDO MORENO SUÁREZ
MAURICIO TRUJILLO
JACKSON ARTURO VASQUEZ CASTRO
Trabajo de Grado
Asesor
FELIPE ORTIZ
Ingeniero de Sistemas
UNIPANAMERICANA INSTITUCIÓN UNIVERSITARIA COMPENSAR
FACULTAD DE INGENIERIA
PROGRAMA DE INGENIERIA DE SISTEMAS
BOGOTA
2010
3
Nota de aceptación:
________________________________
________________________________
________________________________
________________________________
________________________________
________________________________
Firma del presidente del jurado
Firma del jurado
Firma del jurado
Bogotá D.C. 10, 01, 2011
4
DEDICATORIA
Este trabajo está dedicado a Dios por la vida que nos ha brindado y la oportunidad
de llegar hasta el gran logro de aplicar nuestros conocimientos en nuestro trabajo
de grado.
También va dedicado a nuestros padres, hijos y familia quienes nos apoyan cada
día para alcanzar triunfos y metas.
5
AGRADECIMIENTOS
Agradecemos a PUNTO SERVICIOS por la oportunidad que nos brindo al permitir
y apoyar el desarrollo y aplicación de ITIL – GESTION DE SERVICIOS en su
empresa.
Agradecemos a la todos los docentes que nos colaboraron en el proceso y
desarrollo del trabajo de grado.
6
DECLARATORIA
Los autores certifican que para la elaboración del proyecto de tesis, se han
respetado las normas de citación de fuentes y ninguna copia textual supera las
400 palabras. Por tanto, no se ha incurrido en ninguna forma de plagio, ni por
similitud ni por identidad. Los autores son responsables del contenido, de los
juicios y opiniones emitidas.
Se autoriza a los interesados a consultar y reproducir parcialmente el contenido
del trabajo de investigación titulado ESQUEMA DE DIAGNÒSTICO PARA LA
PROPUESTA DE IMPLEMENTACIÒN ITIL, GESTIÒN DE SERVICIOS, EN LA
EMPRESA PUNTO DE SERVICIO S.A desarrollado por GERALDINE GRASS
ARDILA, CAMILO EDUARDO MORENO SUÁREZ, MAURICIO TRUJILLO y
JACKSON ARTURO VASQUEZ CASTRO siempre que se haga la respectiva cita
bibliográfica que de crédito al trabajo y sus autores, así: GRASS A. Geraldine,
MORENO. Camilo, TRUJILLO. Mauricio, VASQUEZ. Jackson, Metodología para
el análisis e implementación de ITIL – Gestión de servicios en medianas y
pequeñas empresas. Facultad de Ingeniería. Bogotá. Noviembres de 2010
Firma de los autores GERALDINE GRASS ARDILA __________________________________ CAMILO EDUARDO MORENO __________________________________ MAURICIO TRUJILLO RUBIO __________________________________ JACKSON ARTURO VASQUEZ __________________________________
7
TABLA DE CONTENIDO
RESUMEN ............................................................................................................. 12
INTRODUCCION ................................................................................................... 14
1. MARCO REFERENCIAL.................................................................................... 17
1.1 ANTECEDENTES ............................................................................................ 17 1.1.1 Historia de ITIL .............................................................................................. 17
1.1.2 Tipos de Certificaciones ................................................................................ 18
1.1.3 Casos de éxito en Colombia ......................................................................... 20
1.1.4 Casos de éxito en empresas de otros países ............................................... 31
1.2 MARCO TEORICO .......................................................................................... 36
1.2.1 Pymes en Colombia ...................................................................................... 36
1.2.2 ITIL ................................................................................................................ 43
1.2.3 ISO 20000 ..................................................................................................... 46
2. DISEÑO METODOLOGICO ............................................................................... 48
2.1 Tipo de Estudio ................................................................................................ 48
2.2 Población y muestra......................................................................................... 48
2.2.1 Empresa piloto PUNTO DE SERVICIOS ...................................................... 49
2.3 Supuestos ........................................................................................................ 51
2.4 Instrumentos .................................................................................................... 51
2.4.1 Encuesta. ...................................................................................................... 51
2.4.2 Entrevista. ..................................................................................................... 51
2.4.3 Análisis documental. ..................................................................................... 52
2.5 Procedimientos ................................................................................................ 52
2.6 Consideraciones éticas. ................................................................................... 53
3. RESULTADOS ................................................................................................... 54
3.1 Encuestas ........................................................................................................ 54
3.1.1 Aplicación de las encuestas .......................................................................... 55
3.2 Entrevistas ....................................................................................................... 73
3.2.1 Resultados de la entrevista ........................................................................... 73
8
3.3 Análisis Documental........................................................................................ 88
3.4 Incidentes Problemáticos ............................................................................... 100
3.5 Referencia de la metodología implementada ................................................. 106
3.5.1 Gestiones .................................................................................................... 106
3.6 Guía de aplicación ......................................................................................... 211
3.7 Propuesta y recomendaciones a Punto de servicios S. A ............................ 215
3.7.1 Recomendaciones por cada gestión analizada ........................................... 215
3.7.2 Matrices de proceso ITIL para PUNTO DE SERVICIOS............................. 224
3.7.3 Flujos de procesos aplicando ITIL .............................................................. 234
3.7.4 Base de Datos ............................................................................................ 247
3.7.5 Recomendaciones generales ...................................................................... 258
3.7.6 Gestiones de evaluación ITIL ...................................................................... 262
3.7.7 Alternativas de Software para Sistemas de Gestión de incidencias............ 268
3.7.8 Implementación de las recomendaciones, Modelo ITIL. ............................. 269
3.7.9 Conveniencia del modelo ITIL ..................................................................... 270
CONCLUSIONES ................................................................................................ 271
RECOMENDACIONES ........................................................................................ 272
BIBLIOGRAFÍA .................................................................................................... 273
ANEXOS .............................................................................................................. 276
Glosario ITIL ........................................................................................................ 316
9
LISTA DE FIGURAS
pág.
Figura 1: Distribución de las PYME ....................................................................... 36 Figura 2: Indicador PYME ANIF ............................................................................. 39
Figura 3: Situación económica general de las PYME en el 2009 ........................... 40 Figura 4: Costos de operación de las PYME ......................................................... 41
Figura 5: Principal problema de las PYME (%) ...................................................... 41 Figura 6: Situación económica general de las PYME en el 2010 ........................... 42
Figura 7: Resultados encuesta centro de servicios ................................................ 55 Figura 8: Resultados encuesta gestión de incidentes ............................................ 56
Figura 9: Resultados encuesta gestión de problemas ........................................... 58 Figura 10: Resultados encuesta gestión de configuración ..................................... 59
Figura 11: Resultados encuesta gestión de cambios ............................................. 60 Figura 12: Resultados encuesta gestión de versiones ........................................... 61
Figura 13: Resultados encuesta gestión de Niveles de servicio ............................ 62 Figura 14: Resultados encuesta gestión financiera ............................................... 63
Figura 15: Resultados encuesta gestión de capacidad .......................................... 64 Figura 16: Resultados encuesta continuidad del servicio ...................................... 65
Figura 17: Resultados encuesta gestión de disponibilidad .................................... 66 Figura 18: Resultados encuesta gestión de la seguridad ...................................... 67
Figura 19: Grado de Aprobación ............................................................................ 72 Figura 20: Nivel de Importancia ............................................................................. 73
Figura 21: Proceso general de incidencias ............................................................ 74 Figura 22: seguimientos a las órdenes de servicio ................................................ 77
Figura 23: Proceso de mantenimiento ................................................................... 79 Figura 24: Proceso de solicitud de repuestos ........................................................ 82
Figura 25: Proceso para validación de cumplimiento de los SLA .......................... 85 Figura 26: Proceso para divulgación de TIPS ........................................................ 87
Figura 27: Proceso de administración. ................................................................... 89 Figura 28: Proceso de mejora continua. ................................................................ 90
Figura 29: Proceso comercial y de servicio al cliente. ........................................... 91 Figura 30: Proceso de servicio técnico. ................................................................. 92
Figura 31: Proceso de gerencia. ............................................................................ 93 Figura 32: Proceso para el control del servicio no conforme. ................................ 94
Figura 33: Proceso de calidad - Indicadores SGC ................................................. 95 Figura 34: Proceso de calidad – Análisis de datos 1 ............................................. 96
Figura 35: Proceso de administración – Análisis de datos 2 .................................. 97 Figura 36: Procedimiento acciones correctivas y preventivas ................................ 98
Figura 37: Proceso de administración – Análisis de datos ..................................... 99 Figura 38: Proceso de soporte al servicio ............................................................ 106
Figura 39: Proceso para la gestión de incidentes ................................................ 113 Figura 40: Proceso para la gestión de problemas ................................................ 120
Figura 41: Proceso para la gestión de configuraciones ....................................... 126
10
Figura 42: Proceso para la gestión de Cambios .................................................. 132
Figura 43: Pasos para generar una correcta gestión de cambios ........................ 135 Figura 44: Proceso para la gestión de Versiones ................................................ 143
Figura 45: Proceso para la gestión de niveles de servicio ................................... 150 Figura 46: Proceso para la gestión financiera ...................................................... 158
Figura 47: Proceso para la gestión de la capacidad ............................................ 168 Figura 48: Proceso para la gestión de la continuidad del servicio ....................... 177
Figura 49: Proceso para la gestión de la disponibilidad ....................................... 191 Figura 50: Proceso para la gestión de seguridad................................................. 201
Figura 51: Nuevo Proceso de centro de servicios ................................................ 216 Figura 52: Nuevo proceso para gestión de incidentes ......................................... 219
Figura 53: Nuevo proceso para validación de cumplimiento de los SLA ............. 223 Figura 54: Relaciones existentes en la Base de datos de conocimiento ............. 247
Figura 55: Relaciones existentes en la CMDB ..................................................... 248 Figura 56: Modelo físico de la Base de Datos de Conocimiento .......................... 251
Figura 57: Modelo físico de la CMDB .................................................................. 252 Figura 58: Modelo Lógico de la Base de Datos de Conocimiento ........................ 252
Figura 59: Modelo Lógico de la CMDB ................................................................ 253 Figura 60: organización y flujo de procesos ......................................................... 259
11
LISTA DE ANEXOS
pág.
ANEXO A: Encuestas por gestión de la primera fase .......................................... 276 ANEXO B: Encuestas por gestión para la segunda fase ..................................... 288
ANEXO C: Carta de presentación a la empresa .................................................. 313 ANEXO D: Propuesta a PUNTO DE SERVCIO ................................................... 314
12
RESUMEN
En Colombia, un gran porcentaje de organizaciones se encuentran clasificadas
como pequeñas y medianas empresas (PYMES), estas afrontan diversos retos
como bajos presupuestos, poco personal con experiencia en TI y entornos
informáticos poco estructurados; sin embargo la demanda a la que se ven
enfrentadas estas organizaciones son las mismas de las grandes empresas, lo
que hace que las PYMES deban optimizar sus procesos para brindar niveles de
servicios más competitivos orientados a la calidad, para lo cual las buenas
prácticas recomendadas por la metodología ITIL servirán como referencia ya que
le permitirán estar mejor preparadas para enfrentarse al competitivo mercado
mundial.
El lenguaje de ITIL está encuadrado en el contexto de las grandes empresas,
generando la extendida creencia de que esta metodología está dirigida a ser
aplicada únicamente en las organizaciones de TI de gran envergadura, ignorando
la evidencia cada día mayor de que estas buenas prácticas también pueden
beneficiar a las empresas más pequeñas.
El propósito de este proyecto es Realizar un diagnóstico sobre los procesos de
una Pyme colombiana del sector tecnológico (Punto de servicio S.A) para
proponer una estructura de implementación de ITIL con el cual se pueda brindar
una mejor calidad en la prestación de servicios de TI, restándole de esta forma
valor al mito de que estas buenas prácticas solo puede ser implementadas por
grandes empresas.
PALABRAS CLAVE
ITIL (Information Technology Infrastructure Library), PYME, Estándar,
Organización, Servicio, Prácticas, TI (Tecnología Informática)
13
ABSTRACT
In Colombia, a great percentage of organizations are classified as small and
medium companies (PYMES), these confront diverse challenges as low budgets,
slightly personally with experience in TI and IT little structured environments;
nevertheless the demand to which these organizations meet conflicting they are
the same of the big companies, which does that the PYMES should optimize his
processes to offer levels of more competitive services orientated to the quality, for
which the good practices recommended by the methodology ITIL will serve as
reference since they will allow him to be better prepared to face the competitive
world market.
ITIL's language is fitted in the context of the big companies, generating the
widespread belief of which this methodology is directed to be applied only in the
organizations of TI of great importance, ignoring the evidence every major day of
which these good practices also can be of benefit to the smallest companies.
The intention of this project is to create a diagnosis on the processes of a
Colombian Pymes in the technological sector (Punto de servicio S.A), We want
to propose a structure of ITIL's implementation in order to offer a better quality in
the provision of services of IT; discrediting the myth that these best practices can
only be implemented by big companies.
KEY WORDS
ITIL (Information Technology Infrastructure Library), PYME, Standar, Organization,
Service, Practice, TI (Information Technology)
14
INTRODUCCION
Colombia es un país que se ve en la necesidad de abrirse al mercado mundial,
pero al hacerlo muchas de las empresas colombianas corren el riesgo de perecer
en el intento de competir con organizaciones mejor establecidas, con mayor
capacidad y con más experiencia en el mercado, la supervivencia de estas
organizaciones será completamente dependiente de que tan bien se encuentran
preparadas para competir.
En el campo de las Pequeñas y Medianas Empresas, muchas comienzan a invertir
en desarrollo de software e infraestructura para apoyar su negocio en busca de
ventaja ante la competencia, normalmente esto a mediano plazo, lo que les lleva a
generar en su interior un departamento de TI, adicionalmente muchas
organizaciones piensan en iniciar los procesos necesarios para obtener una
certificación ISO/IEC 20000, pero estos son muy costosos y suelen ser
traumáticos debido a las diferentes modificaciones o implementación de procesos
a los que se dé lugar, o en el mejor de los casos, es simplemente difícil aplicarlo a
organizaciones que no cuenten con el recurso de inversión necesario.
Muchas de estas organizaciones recurren entonces al marco de referencia de
buenas prácticas ofrecido por ITIL que sirve como una guía que abarca toda
infraestructura, desarrollo y operaciones de TI.
Es conocido que el lenguaje de ITIL está muy encuadrado en el contexto de las
grandes empresas, lo que llevó a la extendida creencia de este estándar está
dirigido a ser aplicado únicamente en las organizaciones de TI de gran
envergadura, pero no solo de su lenguaje se trata, muchos piensan que al tener
varios procesos de gestión involucrados será necesario un número similar de roles
para su correcta gestión, y esto conlleva tener una gran estructura y organización,
así que no es extraño ver que las medianas y pequeñas empresas se pregunten:
15
¿La empresa Punto de Servicio S.A, está en capacidad de implementar ITIL,
gestión de servicios, para formalizar y optimizar los procesos operativos asociados
a administración y prestación de asistencia tecnológica?
Erradas creencias y miedo a afrontar nuevos cambios son la principal causa de
falta de inversión e interés por parte de las Pymes a desarrollar gestión de servicio
de TI, que mejore sus formas de trabajar, ignorando la evidencia cada día mayor
de que estas buenas prácticas también pueden beneficiar a las empresas más
pequeñas.
En el otro extremo se pueden encontrar empresas que animadamente se centran
en el montaje de nuevas tecnologías y desarrollos, con la convicción y creencia de
que entre más tecnología implementen serán más competentes, pero incurren en
el problema de invertir más de lo necesario y de que las áreas de TI, pierdan su
objetivo como apoyo y soporte de los servicios que prestan las empresas.
Este proyecto nace por la importancia y la influencia que tienen las pymes en la
economía colombiana, y la necesidad de mejorar su calidad y competitividad ante
las grandes empresas a nivel global; por ello la propuesta de aplicar ITIL en las
PYMES, dado que cada vez es más frecuente que estas empresas hagan uso de
nuevas tecnologías buscando estar a la vanguardia del mercado pues los clientes
de estas PYMES demandan un soporte al servicio de alta calidad
independientemente de su localización geográfica, por ello se ve la necesidad de
que estas empresas tomen un estándar reconocido para la gestión de servicios de
tecnología, estando a la par de las grandes empresas.
El objetivo principal de este proyecto es Realizar un esquema de diagnóstico para
proponer una estructura de implementación de ITIL, gestión de servicios, en la
empresa Punto de Servicios S.A. Los objetivos específicos están definidos de tal
manera que permitan lograr lo propuesto anteriormente.
16
• Analizar la documentación de ITIL “Gestión de Servicios”, identificando los
conceptos, funcionalidad y aplicaciones transferibles a los procesos de
Punto de Servicios S.A.
• Realizar el estudio de procesos vigentes, dentro de la empresa Punto de
Servicios S.A, para generar un cuadro de comparaciones versus estructura
ITIL.
• Construir los diagramas de procesos actuales para generar el análisis
comparativo de los mismos, a través de la propuesta de flujos de proceso
según aplicación ITIL.
• Presentar diagnóstico, para el análisis de los aspectos y variables viables y
factibles a implementar en los procesos de la empresa Punto de Servicios
S.A., de acuerdo a la teoría específica ITIL.
• Presentar a la empresa Punto de Servicios S.A., un documento con la
propuesta de implementación de procesos y gestión, teniendo en cuenta el
marco base ITIL.
17
1. MARCO REFERENCIAL
1.1 ANTECEDENTES
1.1.1 Historia de ITIL
Fue iniciada a finales del año 1980 como una guía para el gobierno Británico, ITIL
se ha convertido en el estándar para la Gestión de servicios de TI, su estructura es
bastante útil para las organizaciones en cualquier sector quienes la usan de base
para consulta y soporte de herramientas informáticas, principalmente porque su
uso es libre y no tiene costo alguno.
La primera versión, fue desarrollada con el apoyo de la CCTA (Central Computer
and Telecomunications Agency), “se tituló Government Information Technology
Infrastructure Method („Método de Infraestructura de la Tecnología de Información
del Gobierno‟, GITM) está formada por un conjunto de 31 libros dentro de un
proyecto dirigido por Peter Skinner y John Stewart donde cada libro está enfocado
a un área específica dentro de la gestión de TI. Las publicaciones fueron
retituladas principalmente para que no fueran vistas como un método formal sino
como una guía, esta decisión se tomo al ver el creciente interés que había por el
tema, fuera del gobierno británico” 1.
El desarrollo de ITIL fue creado inicialmente porque los contratos de las empresas
del sector público y las del sector privado no manejaban los mismos estándares,
sino por el contrario cada una manejaba de forma independiente sus prácticas en
cuanto a los servicios de TI, lo que causaba mayores esfuerzos en los proyectos
de TI causando mayores costos y aumento en los errores cometidos
ITIL también se desarrollo debido a que cada vez más, las organizaciones se
están volviendo dependientes de las tecnologías de información para poder lograr
sus objetivos. Por ello surge la necesidad de lograr que la calidad en los servicios
1 SCRIBD, Exposición tgs (2003) – Auditoria de sistemas, [en línea] 22/08/2010, Disponible en internet
http://www.scribd.com/doc/23599285/exposicion-tgs-2003
18
informáticos sea mayor y de esta forma lograr cumplir los objetivos del negocio, y
satisfacer los requisitos y las expectativas del cliente. A través de los años, el
énfasis pasó de estar sobre el desarrollo de las aplicaciones TI a la gestión de
servicios TI.
En el año 2005 se realizo la última actualización de ITIL conocida como ITIL V3
que fue publicada en el año 2007, en la que se reúnen gran parte de las prácticas
de ITIL V2 en lo que se refiere al ciclo de vida de los servicios y la cual consta de
cinco libros principales (Diseño de servicios de TI, Introducción de los servicios de
TI, Operación de los servicios de TI, Mejora de los servicios de TI y Mejoras en los
servicios de TI).
“La aplicación TI (a veces nombrada como un sistema de información) sólo
contribuye a realizar los objetivos corporativos si el sistema está a disposición de
los usuarios y, en caso de fallos o modificaciones necesarias, es soportado por los
procesos de mantenimiento y operaciones”2.
1.1.2 Tipos de Certificaciones
Actualmente en la mayoría de organizaciones en las cuales se procede a hacer
implementación de ITIL V2 se exige personal certificado, existen tres diferentes
niveles de certificación los cuales se citan textualmente a continuación pues no
son datos que se puedan modificar.
• “ITIL Foundation: Certificación en Fundamentos de Administración de
Servicios de TI. Provee un conocimiento básico de los conceptos de la
administración de los servicios de TI así como la relación entre los distintos
procesos de Administración de Servicios de TI.
2 ORGANIZACIÓN OSIATIS ESPAÑA, ITIL – Gestión de Servicios TI – Fundamentos de la gestión de TI -
¿Qué es ITIL?, [en línea] 22/07/2010, Disponible en internet http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/fundamentos_de_la_gestion_TI/que_es_ITIL/que_es_ITIL.php
19
• ITIL Practitioner: Certificación Profesional en Administración de Servicios de
TI. Esta certificación ITIL concede las habilidades en aspectos concretos y
prácticos de un solo proceso de ITIL, es decir por cada proceso existe una
certificación profesional.
• ITIL Service Management: Certificación de Administrador de Servicios de
TI. En ella se obtiene un reconocimiento internacional, que muestra que se
tiene una clara demostración de la habilidad para implementar y administrar
los servicios de TI”3.
Actualmente, ITIL tiene más seguidores que opositores. Sin embargo, existen
pocos estudios que sean comprobados científicamente sobre su efectividad.
La razón principal es que ITIL no es una NORMA establecida, por el contrario es
una recomendación basada en BUENAS PRACTICAS y por tal motivo pareciera
mantenerse en el terreno experimental.
Sin duda, ITIL es importante y para muchas personas, estas buenas prácticas
entregan a la organización más ventajas que desventajas; pero el éxito de esta
metodología requiere de un sólido compromiso por parte de todos los integrantes
de la organización.
Con frecuencia se encuentra que los casos en los cuales se ha aplicado esta
metodología, han sido a grandes empresas, pero es necesario tener claro que el
tamaño de la organización no debe ser un limitante para la aplicación de ITIL, sin
embargo empresas más pequeñas son las más reacias y prefieren no implementar
este estándar principalmente por el temor a que la "metodología" impacte en su
flexibilidad actual.
3 FORMACION Y CURSOS. Utilidad y tipos de certificaciones ITIL, [en línea] 23/07/2010, Disponible en
internet http://www.formacioncursos.com/2009/02/tipos-certificaciones-itil.html#
20
Aunque ITIL tiene en cuenta todos los procesos, las empresas se han visto en la
necesidad tomar en cuenta otras prácticas que apoyen el desarrollo de dichos
procesos, algunos marcos de referencia son COBIT, CMMI, ISO 17799, ISO
20000, etc.
A continuación se darán a conocer algunos casos de éxito en los que al
implementar ITIL mejoraron los niveles de servicio de TI y los empleados se vieron
beneficiados con el cambio.
1.1.3 Casos de éxito en Colombia
Los casos de éxito mostrados, son citados textualmente para no alterar la
información respecto a la aplicación de ITIL y para que sea de mejor comprensión
para los interesados en el tema, teniendo en cuenta que son casos presentados al
público y que cualquier persona puede acceder a ellos.
1.1.3.1 Fiscalía General de la Nación
Para completar la cobertura nacional del Sistema Penal Oral
Acusatorio (SPOA) la Fiscalía necesitaba dimensionar el impacto en
recursos, hardware y la elaboración de la estrategia con la cual
podría ampliar el cubrimiento y al mismo tiempo mantener tanto la calidad del servicio
como la confidencialidad de la información.
Mediante un equipo interdisciplinario experto en la infraestructura empleada por la
Fiscalía en particular Java Enterprise Edition y Oracle se realizo una evaluación actual
del servicio y hacia donde se quería llegar basándose en la metodología definida por
el Information Technology Infraestructure Library (ITIL) y en el análisis de la
arquitectura de la aplicación utilizando herramientas de diagnostico y pruebas de
carga para medir y dimensionar las exigencias sobre la infraestructura actual a nivel
de servidores, arquitectura de software y comunicaciones. Al mismo tiempo se
identificaron oportunidades de mejora mediante la formulación de unos Acuerdos de
Niveles de Servicio (SLA) que le permitieran a la Fiscalía mejorar la relación con los
proveedores involucrados en la prestación del servicio.
21
Gracias al adecuado dimensionamiento de infraestructura y recomendaciones en la
arquitectura de la aplicación la Fiscalía pudo cumplir a tiempo y exitosamente la
tercera fase de su plan de cubrimiento del SPOA aumentando el número de usuarios a
nivel nacional a más del 30%.4
1.1.3.2 Secretaría Distrital de Ambiente de Bogotá D.C
Elaboración del Plan Estratégico de Sistemas de Información
(PESI) de la Secretaría Distrital de Ambiente (SDA).
El grupo consultor identifico los proyectos de TI que permitirán que
la SDA mejore su gestión con apoyo de los Sistemas de
Información nuevos y actuales utilizando la metodología de Planeación Estratégica
delineada por la Comisión Distrital de Sistemas. Algunos de los aspectos tenidos en
cuenta durante la elaboración del proyecto son: Planeación de Continuidad de
Negocio (BCP), Sistemas de Gestión de Seguridad de la Información (SGSI) con base
en la norma ISO 27001y recomendación de la implementación de mejores prácticas
según Information Technology Infraestructure Library (ITIL).5
1.1.3.3 Mesa de Ayuda (Servicios de Outsourcing)
Es una entidad corporativa con sede en Medellín de carácter
público y de orden nacional, integrada por ochenta
municipios antioqueños. Se encarga de administrar los
recursos naturales renovables a través de un conjunto de
actuaciones jurídicas y técnicas, tanto para el otorgamiento
de permisos, autorizaciones y licencias ambientales exigidos en la ley para el uso,
aprovechamiento y movilización de los mismos, como para regular el desarrollo de
actividades que puedan afectar el medio ambiente.
Necesidades del cliente. Adquisición de servicios de mesa de ayuda y soporte a
usuario final en herramientas teleinformáticas, oferta que fue elaborada de acuerdo al
pliego de condiciones expuestos por Corantioquia y obtenida por licitación.
4 INGENIAN SOFTWARE. clientes - casos de éxito – fiscalía general de la nación, [en línea],
15/08/2010, Disponible en internet http://ingenian.com/web/public/exito. 5 INGENIAN SOFTWARE. clientes - casos de éxito – Secretaría Distrital de Ambiente de Bogotá D.C, [en
línea], 15/08/2010, Disponible en internet http://ingenian.com/web/public/exito
22
Solución ofrecida Los trabajos que se realizaron dentro del servicio de MESA DE
AYUDA, incluyeron los servicios de asistencia a usuario final en el manejo de
aplicaciones, manejo de dispositivos, mantenimientos preventivos-correctivos, el
suministro de partes (repuestos), soporte técnico especializado (servidores), servicios
que fueron ejecutados en la jurisdicción de CORANTIOQUIA, Oficinas Territoriales,
Sedes Locales y Sede Central, con el alcance y condiciones contractuales que se
describen a continuación.
La Sede Central de Corantioquia fue el nodo principal de operaciones, en la cual
Corantioquia dispone de una oficina (taller), donde se instaló una base de equipos
propietarios (Servidor para software de mesa de ayuda, PC´s, impresoras, scanner y
la línea 018000 para cumplir con los niveles de soporte y servicios exigidos por el
cliente).
El contrato se desarrolló sobre un número aproximado de 350 dispositivos (equipos de
cómputo, ploters, servidores, impresoras y escáneres y demás dispositivos) descritos
en el numeral 4.4 de los términos de referencia de la licitación y distribuidos en las
diferentes sedes de Corantioquia.
Beneficios Gracias al acompañamiento a usuario final en el uso de las herramientas
ofimáticas que la Corporación pone a su disposición y las herramientas de navegación
y mensajería:
Se fortaleció y se creó cultura entorno en la formación de los usuarios con respecto al
uso ágil de la herramienta para solicitar la atención oportuna de servicios requeridos
en el puesto de trabajo.
Con el respaldo de la información de los usuarios y el cubrimiento a peticiones de las
oficinas territoriales y locales se optimizó el tiempo de respuesta disminuyendo las
cifras de atención de semanas a días.
Con la mesa de ayuda se sentó un precedente satisfactorio del cliente con respecto a
la calificación de la prestación de servicios Outsourcing dado a que las experiencias
anteriores no cumplieron las expectativas de los usuarios; a tal punto que se está en
conversaciones para plantear un nuevo contrato donde además de proporcionar
23
soluciones de mesa de ayuda se pretende hacer administración a la plataforma de
servidores.6
1.1.3.4 Isagem
Es una empresa de Colombia de servicios públicos
mixta, Sociedad Anónima, de carácter comercial,
de orden nacional y vinculada al Ministerio de
Minas y Energía. Su objeto social es la generación y comercialización de energía
eléctrica, así como la comercialización de gas natural por redes, carbón, vapor y otros
energéticos de uso industrial.
Para responder a las crecientes demandas energéticas de Colombia, ISAGEN posee y
opera sus propias centrales de generación con recursos de origen hídrico y térmico:
centrales hidroeléctricas San Carlos, Jaguas, Calderas y Miel I, y la central
termoeléctrica Termocentro.
Entre los principales servicios que presta ISAGEN se encuentran las soluciones
energéticas, el suministro de energía eléctrica y gas, y servicios asociados en tres
líneas principales: mantenimiento, expansión y eficiencia energética con programas
como los de uso racional de energía y sustitución de energéticos, las transacciones en
la Bolsa de Energía y los servicios complementarios a la generación.
Las operaciones de ISAGEN se realizan en Colombia. Actualmente se evalúa la
expansión a otros países, en los cuales actuaría con los valores que la caracterizan:
Responsabilidad Empresarial, sentido económico y enfoque al cliente.
“En ISAGEN planear es mejorar el presente y construir el futuro empresarial, mediante
la definición de: qué hacer, cuándo hacerlo, cómo hacerlo y quién lo hace, teniendo en
cuenta el ambiente en que se encuentra y la posición que se espera tener. La misión,
la visión y la estrategia definidas en la fase de alineación se operan y conectan con el
trabajo, mediante la definición de los objetivos estratégicos con sus principales
6 E-GLOBAL PROFESIONALES EN TICs. nuestros clientes - casos de éxito – mesa de ayuda, [en
línea], 19/08/2010, Disponible en internet http://www.e-global.com.co/portal/NuestrosClientes/Casosde%C3%A9xito/Corantioquia/tabid/79/Default.aspx
24
relaciones (construcción del mapa estratégico) y sus indicadores, iniciativas y metas.
Dicha planeación se realiza con proyección a cinco años, con revisión anual.
La metodología que se sigue en ISAGEN en la fase de conexión es la del Tablero
Balanceado de Indicadores – TBI – a nivel empresarial y de proceso”, describió Jorge
Julio García, líder de Proyecto. La definición de los objetivos estratégicos y los
programas de trabajo de las Tecnologías de Información y Comunicaciones –TIC se
proyectan a cinco años, con base en los objetivos estratégicos definidos a nivel de
empresa y de proceso, la evaluación de las tendencias del entorno y las
oportunidades de mejoramiento de los procesos. El plan estratégico de TIC establece
indicadores, metas y el portafolio de proyectos, con sus correspondientes recursos
para el logró de cada objetivo
Desafío: Procesos administrativos y de TI unificados
El Proceso de Gestión de la Integración Empresarial, del cual es responsable la
Gerencia
Administrativa, tiene como misión liderar con el trabajador su propio desarrollo y el de
la organización, mediante la integración corporativa, el desarrollo intensivo de
competencias, la gestión de la información y la habilitación requerida para construir
una organización sistémica, adaptativa e inteligente, y así contribuir al logro de la
competitividad de ISAGEN.
Debido a que el Proceso es uno de los habilitadores, recibe y debe atender desde
solicitudes de caracteres estratégicos y tácticos, hasta transaccionales u operativas,
es un factor importante en las operaciones, pero no estaba estandarizado. La
recepción de dicha solicitudes o los compromisos acordados con la propia empresa,
los otros procesos o los trabajadores eran realizados por diferentes medios, tales
como: mesas de servicios, correo electrónico, formatos en papel, memorandos,
compromisos en reuniones y encuentros no formales. Debido a lo anterior, no era
factible tener claridad sobre la totalidad de compromisos con los clientes internos, con
la consiguiente falta de un control integral y el desconocimiento, en muchos casos, del
avance en el trámite de la solución y el seguimiento al cumplimiento.
“En algunas situaciones esto afectaba la productividad porque un trabajador de
ISAGEN debía dedicar buena parte de su tiempo a indagar sobre el avance en el
trámite de la solicitud a cambio de dedicarlo a atender sus asuntos de trabajo. De igual
25
forma, no se contaba con un mecanismo formal de retroalimentación de los clientes
internos para conocer el grado de satisfacción en cuanto a la calidad de los servicios
ofrecidos y el nivel de cumplimiento”, explico Manuel Homero Fajardo, Gerente
Administrativo y principal patrocinador del proyecto.
Solución: Satisfacción con Niveles de Servicios
La solución planteada fue la adopción de un SPOC (Punto Único de Contacto - Single
Point Of Contact-, por sus siglas en inglés), para lo cual se tuvo en cuenta la adopción
de las buenas prácticas de ITIL, ISO 20000, los criterios de Charter Mark, los
conceptos de centros de servicios compartidos y la visión de redes de colaboración.
“Si bien ITIL e ISO 20000 se han aplicado para la administración de servicios de TI, en
ISAGEN estamos trascendiendo estas fronteras. En consecuencia, además de
aplicarlos a TI, hemos encontrando que podemos aplicar estos conceptos
perfectamente a cualquier esquema de prestación de servicios, en este caso, a
servicios administrativos”, comentó el líder del proyecto.
El proyecto se desarrollo trabajando en lo que han denominado los “tres vectores de
desarrollo”: personas, servicios y tecnología.
En el vector personas se ha utilizado la metodología ADKAR para sensibilizar y
movilizar el cambio en todas las personas, interviniendo los aspectos conductual,
emocional y cognitivo, apoyados en el desarrollo de programas de comunicación,
patrocinio, entrenamiento, acompañamiento y manejo de la resistencia al cambio.
Entre las actividades llevadas a cabo es bueno resaltar la realización de
entrenamiento básico en gerencia del servicio a todos los trabajadores del proceso y
contratistas y las acciones de patrocinio por parte de la Gerencia y el equipo directivo
del proceso.
El vector servicios incluyó el desarrollo del portafolio de servicios, análisis de procesos
y procedimientos y la definición del esquema de prestación de servicios. El portafolio
de servicios se encuentra en contante revisión y en la actualidad está conformado por
grupos de servicios y estos a su vez por productos fundamentales y suplementarios.
Cada uno de ellos con su respectiva definición, beneficios, atributos e interrelaciones
de primer nivel. El esquema de prestación de servicio define la forma como se reciben
y tramitan al interior del Proceso los incidentes, solicitudes de servicio, sugerencias,
quejas y reclamos.
26
El vector Tecnología definió la selección de la herramienta de gestión y la
parametrización. En la selección de la herramienta se tuvieron en cuenta, además de
los aspectos funcionales, que cumpliera con estándares internacionales para la
prestación de servicios, la facilidad de uso para clientes internos y contratistas y la
interacción con el ERP corporativo. Las herramientas de CA para gestión son: CA
Service Desk: 11.2 y CA CMDB: 11.1.
Resultados: Beneficios tangibles
Ahora se cuenta con un sistema de gestión de clientes a través del cual acceden a los
servicios del Proceso, que permite hacer trazabilidad, generar informes de gestión,
retroalimentar a los clientes, garantizar el cumplimiento de estándares de calidad y de
acuerdos de niveles de servicio.
Los servicios que ofrece el Proceso son: Herramientas organizacionales; Modelo
integral de gestión humana; Soluciones de tecnología de información; Soluciones
logísticas; Soluciones en seguridad y salud ocupacional.
La Organización tiene varias sedes y centros productivos, centralizando muchas de
las tareas de administración de los trabajadores en la sede principal. Por tal razón, los
procedimientos para acceder a estos servicios se han visto afectados por el trámite y
la logística de envío. Con la implementación de formas automatizadas en las
solicitudes, los trabajadores de los centros productivos se han visto beneficiados
porque los tiempos en trámites se han minimizado, ya que estas solicitudes cuentan
con flujos de trabajo, incluidos procesos de aprobación.
Al tener mecanismos mediante los cuales se conoce de una mejor forma la necesidad
de los otros procesos para cumplir con su razón de ser, se brindan las soluciones de
forma oportuna. Además, en algunas de las solicitudes que recibe el Proceso se
requiere la participación de otros procesos de la Empresa para la solución, por lo tanto
es necesario tener coherencia y para ello se han ido integrando.7
7 CA® TRASNSFORMING IT MANAGEMENT. ISAGEN presenta su Punto Único de Contacto para
gestionar servicios de negocio, [en línea], 20/08/2010, Disponible en internet http://www.ca.com/files/successstories/081209_sfhp_successstory_isagen_es_194164.pdf
27
1.1.3.5 CONSORCIO FIDUFOSYGA 2005
Solución: Consultoría e Implantación del Plan de Operaciones de Sistemas alineado
con ITIL.
Fecha: 30 / 12 / 2006
Duración: 8 meses
Resultados: La consultoría en ITIL en conjunto con las soluciones de Aranda
Software permitieron estandarizar la configuración de las máquinas, controlar de
manera efectiva las licencias de software y conocer el nivel de uso de las estaciones
de trabajo, es decir, definir y conocer quién las usa, para qué, cuál es su estado, y su
respectiva ubicación, entre otras características.
De acuerdo con lo establecido en el artículo 218 de la ley 100 de 1993 y el artículo 1
del Decreto 1283 del 23 de julio de 1996 el cual reglamento el funcionamiento del
Fondo de Solidaridad y Garantía del Sistema General de Seguridad en Salud donde
establece que el Fondo de Solidaridad y Garantía (Fosyga) es una cuenta adscrita al
Ministerio de la Protección Social manejada por encargo fiduciario, sin personería
jurídica ni planta de personal propia.
El proyecto nació de la necesidad de ofrecer un mejor servicio a los funcionarios del la
CONSORCIO FIDUFOSYGA 2005 quién maneja el encargo fiduciario del FOSYGA. El
soporte que presta el área de Sistemas se controla de forma centralizada, por lo que
era necesario mantener información confiable y poder llegar a todos los usuarios de
una manera eficiente para resolver las diferentes inquietudes o problemas que se les
pudieran presentar a nivel de Tecnología.
El CONSORCIO FIDUFOSYGA 2005 necesitaba instalar una solución integrada que
permitiera, de manera centralizada, gestionar correctamente los procesos de TI. Para
ello, contó con el acompañamiento de los consultores de INDRA, expertos en las
mejores prácticas de ITIL y en la implementación de las herramientas adquiridas
Objetivos.
• Diseño del modelo de mesa de ayuda ajustado a las necesidades específicas del
FOSYGA y de acuerdo con las mejores prácticas internacionales (ITIL)
28
• Licenciamiento de las herramientas de software para realizar adecuadamente las
actividades propias de mesa de ayuda, control de inventarios, y administración
remota.
• Instalación, configuración y parametrización del software.
• Acompañamiento de los consultores durante y luego de instalada la solución.
• Capacitación
Valor aportado al cliente La consultoría en ITIL en conjunto con las soluciones de
Aranda Software permitieron estandarizar la configuración de las máquinas, controlar
de manera efectiva las licencias de software y conocer el nivel de uso de las
estaciones de trabajo, es decir, definir y conocer quién las usa, para qué, cuál es su
estado, y su respectiva ubicación, entre otras características. Por lo tanto, la
terminación satisfactoria del proyecto fue de gran utilidad para brindar un adecuado
soporte a los usuarios del CONSORCIO.
Solución
• Implementar la mesa de ayuda y cumplir con el requerimiento de gestionar los
procesos de soporte mediante las mejores prácticas; y con una herramienta que
tuviese una interfaz amigable y de fácil uso, tanto para los administradores de la
misma, como para los funcionarios que hacen uso de ella.
• Cumplir con los requisitos de controlar los inventarios y cambios de componentes de
hardware y software, y poder tomar control remoto de las estaciones de trabajo de los
usuarios para agilizar el soporte y controlar las licencias de software
Observaciones generales
Las herramientas por si solas no son la solución para lograr optimizar la inversión es
necesario que su implementación este acompañada de políticas, procesos,
procedimientos y la respectiva capacitación a los implicados en la Gestión de
Infraestructura y lograr que el usuario final comprenda que existen Acuerdos de
Niveles de Servicios y en esa medida serán atendidos sus requerimientos sin
descuidar los procesos críticos del CONSORCIO FIDUFOSYGA 2005.8
8 ARANDA SOFTWARE. Consorcio FIDUFOSYGA 2005 - Consultoría e Implantación del Plan de
Operaciones de Sistemas alineado con ITIL, [en línea], 20/08/2010, Disponible en internet http://www.arandasoft.com/downloads/testimonios/casoExito_ITIL_Fosyga-V1.0.pdf
29
1.1.3.6 CERROMATOSO (CMSA)
La Gerencia de Informática en su interés por brindar un mejor servicio a los usuarios
de la unidad de Informática, identifica la necesidad de evaluar el nivel de madurez de
los procesos de su unidad sobre el marco de referencia de ITIL, para esto contrató los
servicios profesionales de Itera Colombia S.A. quienes realizaron una revisión de los
procesos de Gestión de Incidentes, Gestión de Problemas, Gestión de Cambios,
Gestión de Versiones y Liberaciones, y la función de Service Desk.
De igual manera, cabe recalcar que la evaluación también se realizó sobre las
herramientas de gestión que se encontraban en producción en el momento del
levantamiento de información, para verificar si cumplían con los mínimos
requerimientos mandatorios.
El criterio con el que se le dé el manejo a la valoración puede definir factores de éxito
para desarrollar las acciones de mejora que se sugieren a los procesos evaluados y
que se encuentran al final del presente documento.
Las entrevistas se llevaron a cabo con la participación del talento humano profesional
de la Unidad de Informática y de algunos usuarios de esta unidad. Los resultados
plasmados en este documento representan vivencias reales del ámbito laboral de
cada uno de estos grupos de trabajo.
Las evaluaciones de nivel de madurez son un método eficaz dentro del modelo de
mejora continua para responder a la pregunta “¿Dónde estamos ahora?". Ayuda a
entender el grado de eficacia realizado para un servicio existente y la apropiada
gestión de los servicios de TI. Se convierte en una herramienta importante para
identificar la brecha entre dónde estamos y dónde queremos estar. La evaluación
debe ser considerada para examinar la relación entre los procesos de negocio, los
servicios, los sistemas y los componentes que conforman un sistema de TI.
Objetivos El análisis de madurez desarrollado para los procesos de la Unidad de Informática de
CMSA, tiene como objetivo principal evaluar el cumplimiento de las mejores prácticas
de ITIL para los procesos de, Gestión de Incidentes, Gestión de Problemas, Gestión
de Cambios, Gestión de Liberación y la función de Service Desk.
30
Este análisis permite evaluar el estado de los procesos para determinar el
cumplimiento de las políticas, procedimientos, roles y responsabilidades, métricas e
informes de gestión que se desarrollan para cada uno de ellos dentro del marco de
ITIL, basado en las evidencias encontradas en el trabajo de campo.
El trabajo de campo realizado se enfocó en la revisión de las prácticas actuales, sus
fortalezas, debilidades, falencias y oportunidades de mejora que pueda presentar la
arquitectura de los procesos de ITIL en cuanto a la Transición, Operación y Mejora
Continua de Servicios de los procesos de soporte de Informática.
De igual manera, se proporcionan las recomendaciones e iniciativas necesarias para
que los procesos puedan optimizarse dentro de la unidad de informática de CMSA,
superando las brechas identificadas en cada proceso a fin de lograr un mejor
desempeño y la obtención de mejores resultados. Para cada proceso se hace el
análisis necesario para determinar si se está brindando el servicio que cumpla con los
siguientes objetivos:
Satisfaga las necesidades y estrategias del negocio de CMSA
Esté guiado por procesos estructurados
Cumpla con los objetivos en términos de administración de recursos y obtención de
resultados
Cumpla con los objetivos de desempeño de efectividad y productividad
especificados
Que los procesos estén divulgados apropiadamente a todos los usuarios de la
unidad de Informática.
Las ventajas de este análisis incluyen:
La proporción de una perspectiva objetiva de la operación actual de cada proceso
El estado de cada proceso frente a un nivel de madurez esperado
Una determinación precisa de cualquier falencia que se detecte en el proceso de
puede ser concluida rápidamente, al igual que las recomendaciones que se pueden
aplicar a futuro
La posibilidad de repetir la misma evaluación en un lapso de tiempo posterior para
evaluar en nivel de mejoramiento de cada proceso y el cumplimiento de las mejoras
propuestas.
31
Alcance
El alcance de este servicio es evaluar el cumplimiento de los procesos de la unidad de
Informática de CMSA con respecto al marco de referencia de ITIL. Los procesos
contemplados son:
Gestión de Incidentes
Gestión de Problemas
Gestión de Cambios
Gestión de Versiones y Liberación
Función de Service Desk
Actividades de la Evaluación
Programación de Entrevistas: 17 al 26 de Marzo de 2009
Preparación de la Evaluación: 1 al 8 Abril de 2009
Elaboración de Entrevistas: 13 al 17 de Abril de 2009
Análisis de Información: 20 al 21 de Abril de 2009
Presentación Ejecutiva de la evaluación: 22 de Abril de 2009
Generación del Documento Entregable: 22 al 23 de Abril de 2009
Participantes
La recolección de información para realizar el análisis de la misma fue llevada a cabo
través de una serie de entrevistas con las personas que hacen parte de la unidad de
informática de CMSA; las entrevistas consistían en una serie de preguntas para
conocer las actividades que se realizan al interior de la unidad y poder evaluar los
procesos, procedimientos utilizados en el día a día. 9
1.1.4 Casos de éxito en empresas de otros países
El caso de éxito mostrado, es citado textualmente para no alterar la información
respecto a la aplicación de ITIL y para que sea de mejor comprensión para los
interesados en el tema, teniendo en cuenta que son casos presentados al público
y que cualquier persona puede acceder a ellos. 9 ITERA COLOMBIA., Presentación introductoria diagnóstico situación actual CERRO MATOSO
CMSA, [en línea], 20/10/2010, Disponible en internet: http://www.guiaacademica.com/educacion/sitios/s699/index.aspx?id=699
32
1.1.4.1 Dexon Software Inc.
Es una compañía Norteamericana, establecida en el estado de Delaware USA,
innovadora en el desarrollo de software, con el objetivo de tener una presencia global.
Actualmente ofrece sus soluciones en América, con especial énfasis en el mercado
latinoamericano. Su software y servicios permiten a las empresas gestionar sus
entornos informáticos, incluyendo la gestión de sistemas, gestión de almacenamiento,
administración de infraestructura TI distribución de software, administración y soporte
a estaciones remotas, gestión de mesas de ayuda y soporte a usuarios.
Su visión: Ser una empresa desarrolladora e integradora de tecnología y servicios
informáticos altamente confiables e innovadores, reconocida por nuestros clientes por
el alto valor agregado ofrecido en nuestras soluciones, mediante una organización de
alto rendimiento que genere orgullo y satisfacción a nuestros colaboradores y
asociados de negocios en todo el mundo.
La misión: Desarrollar y ofrecer soluciones tecnológicas de calidad certificada,
altamente innovadoras, realizadas eficientemente de manera rentable, utilizando todas
las capacidades técnicas y profesionales de nuestros colaboradores, con el objetivo
fundamental de contribuir al negocio de nuestros clientes, nuestros aliados de
negocios y nuestros accionistas.
El Reto: Alinear las soluciones de software, para que cumplieran con los requisitos
que pide Pink Elephant para certificarse en ITIL.
La solución: La obtención del sello PinkVerify - Service Support de Pink Elephant con
el objetivo de validar que el software cumple con los requisitos de apoyo para varios
procesos que soportan la Administración de Servicios de TI.
Los Beneficios:
· Ofrecer una gama de servicios muy definidos en los sectores de administración de
activos tecnológicos y administración de mesas de ayuda, enmarcados en las mejores
prácticas de ITIL
· Adopción de estándares internacionales como ITIL para las mejores prácticas en
administración de servicios de TI.
33
· Aportar soluciones de administración TI mediante el análisis racional, eficaz, eficiente
de las tecnologías utilizadas por el cliente, las que se deben adoptar, o modificar,
logrando de esta manera la optimización de los recursos existentes, ampliando y
optimizando el ciclo de vida completo de los procesos operativos actuales.
Cómo Alinear la Tecnología a la Estrategia de Negocio
Dexon Software Inc. es una empresa económicamente sólida que está compuesta
por personas orientadas a servicio, como son consultores, ingenieros, instructores y
técnicos debidamente certificados. Se destaca por una constante renovación y
actualización de las soluciones de desarrollo de software. Dexon cuenta con una
oferta amplia e integrada, que va desde la provisión de soluciones para la
administración de infraestructura básica, hasta el desarrollo de proyectos y
consultorías con altos grados de complejidad, como son mesas de ayuda y centros de
soporte TI.
Es una empresa líder en investigación, desarrollo y fabricación de las Tecnologías de
la Información más avanzadas del sector, incluyendo sistemas de administración de
activos altamente productivos, distribución de software, administración de servidores,
herramientas para soporte o administración remota de estaciones, sistemas de
almacenamiento y mesa de ayuda.
Dexon se compromete a proporcionar los más altos niveles de calidad en sus
productos y servicios. Mantiene una constante actualización de sus soluciones,
adaptándolas a las necesidades reales de sus clientes, realizando constantemente
estudios de mercado para identificar puntos álgidos en los entornos de administración
y servicios de IT. Dexon atiende las solicitudes de sus clientes y asociados de
negocios, con gran velocidad de adaptación, haciendo de la misma, una compañía de
desarrollo de software bastante ágil y con gran capacidad de adaptación.
Desde hace 3 años, el departamento comercial del Dexon, decidió implementar un
software que tuviera aplicaciones basadas en ITIL (Information Technology
Infrastructure Library) dado que en Colombia es un requerimiento para brindar
soluciones de este tipo a las empresas. ITIL ofrece a las empresas (a base de libros),
la consulta de información sobre cómo poder administrar los procesos de servicio de
34
Tecnologías de Información soportando los objetivos empresariales. Los
Administradores de Tecnologías de Información han entendido que la solución a los
problemas de TI no está en la siguiente tecnología de moda, sino en el enfoque en los
procesos para el aprovechamiento de la misma. De igual forma, se empezó a
investigar que diversas compañías que son clientes de Dexon en Colombia, estaban
solicitando que los paquetes de software también tuvieran la certificación de ITIL
Compliance. Es a partir de entonces que surgió la necesidad dentro del área comercial
de desarrollar software que cumpliera con las especificaciones requeridas.
Por tal motivo, el Ing. Luis B. Chicaiza, Director de Ingeniería de Software, analizó el
tema y vio la importancia de adquirir dicha solución tecnológica y se tomó la decisión
de certificarse en ITIL, al evaluar los beneficios que esto traería a Dexon, pero sobre
todo a sus clientes. A partir de soluciones basadas en ITIL las empresas podrán
contar con mayor eficiencia al menor costo posible, al utilizar un lenguaje común para
optimizar la comunicación dentro de las Tecnologías de Información, con un menor
número de interrupciones en el servicio de TI, mayor satisfacción del cliente y calidad
en el servicio a un costo justificable.
“El área involucrada en la implementación de ITIL, fue la de ingeniería de desarrollo de
software, quien acondicionó el paquete que consiste en una serie de libros que
ofrecen una orientación en la provisión de servicios de TI de calidad. ITIL está basado
en un conjunto de experiencias de profesionales tanto del sector público como
privado, alrededor del mundo. Esto da como resultado, un enfoque coherente y
confiable, que es utilizado como el estándar de Administración de Servicios por varias
empresas líderes en el mundo. Pink nos envío cuestionarios para evaluar el nivel
donde nos encontrábamos y los contestamos descubrimos que cumplíamos con el
60% o 70% de los puntos requeridos. A partir de esto se trabajó en el desarrollo de los
puntos faltantes que estuvo a cargo del área de ingeniería de desarrollo de software,”
afirmó Jaime Torres, Marketing Manager de Dexon.
El principal reto que enfrentó Dexon fue acondicionar todos los mecanismos de sus
paquetes de software para que cumplieran con los requisitos que solicitaba Pink
Elephant México para llevar a cabo la certificación en ITIL. Un punto importante para
que se lograran los objetivos que indicó Pink Elephant, era ajustar el tiempo de
ingeniería invertido para el cumplimiento de los procesos y que el software contara
con los lineamientos requeridos.
35
Jaime Torres, comentó que algunos de los beneficios que encontraron fueron que
“Lograremos posicionarnos muy bien como marca y como producto. En este sentido
nosotros sabemos que Pink Elephant, cuenta con gran presencia en el mercado, no
cualquier empresa está certificada y no todas cumplen con los servicios que ofrece
Pink a sus clientes y esto nos dará una ventaja competitiva en el mercado, ante otras
empresas. En segundo lugar, nos dará nuevas oportunidades de negocio, sobre la
competencia, al cumplir con las demandas del mercado”.
“No hubo problemas de parte de Pink Elephant durante el proceso debido a que todo
se fue dando naturalmente, en la medida en que Dexon desarrolló las funciones,
ajustó el cuestionario y cuando el paquete estuvo listo, cumpliendo todos los puntos
del cuestionario, se envió a los consultores de Pink Elephant México para que los
evaluaran y otorgaran la certificación. Es preciso mencionar que este proceso fue
rápido. Posteriormente se llevaron a cabo reuniones con los ejecutivos de Pink
Elephant Canadá, para realizar algunos ajustes y cambios, los cuales se aplicaron en
un tiempo mínimo de menos de una semana. Al término de esa semana, Pink
Elephant nos notificó que habíamos cumplido con todos los requisitos y nos entregó la
certificación.”
“La inversión económica que realizó Dexon que incluyó la certificación, costo de
ingeniería, así como personal y tiempo, fue de 140 mil dólares,“ continúa Torres.” Solo
en ingeniería, se invirtieron más de 100 mil dólares. Sin embargo, nuestro retorno de
inversión inició en noviembre y esperamos recuperar otro porcentaje este año.”
Por tal motivo sin necesidad de evaluar a otro proveedor Dexon decidió trabajar con
Pink Elephant, ya que en el mercado es la compañía más conocida y que ha
desarrollado más el tema de ITIL a nivel global.10
10 PINK ELEPHANT. Caso de Éxito Dexon Software Inc, [en línea], 23/08/2010, Disponible en internet http://dexon.us/images/descargas/casos_de_exito/caso_pink.pdf
36
1.2 MARCO TEORICO
1.2.1 Pymes en Colombia
1.2.1.1 Definición de la PYME: En Colombia, según la Ley para el Fomento de la
Micro, Pequeña y Mediana Empresa (Artículo 2, Ley 590 del 10 de Junio de 2000)
las PYMES se clasifican así:
Se define por pequeña y mediana empresa, “toda unidad de explotación
económica, realizada por persona natural o jurídica, en actividades empresariales,
agropecuarias, industriales, comerciales o de servicios, rural o urbana que
responda a los siguientes parámetros” 11.
Figura 1: Distribución de las PYME
Fuente: COLOMBIA DIGITAL. Disponible en:
http://colombiadigital.net/index.php?option=com_content&view=article&id=376&Itemid=313
“Microempresa: Personal no superior a 10 trabajadores. Activos totales
inferiores a 501 salarios mínimos mensuales legales vigentes
11 COLOMBIA DIGITAL. ¿Qué es una Mipyme?, [en línea], 26/08/2010, Disponible en internet http://colombiadigital.net/index.php?option=com_content&view=article&id=376&Itemid=313
37
Pequeña Empresa: Personal entre 11 y 50 trabajadores. Activos totales
mayores a 501 y menores a 5.001 salarios mínimos mensuales legales
vigentes.
Mediana: Personal entre 51 y 200 trabajadores. Activos totales entre 5.001
y 15.000 salarios mínimos mensuales legales vigentes” 12.
Sin embargo la ley 905 del 2 de agosto del 200413 hace una modificación a la Ley
590 del 10 de Junio de 200014 donde dice que para que una empresa clasifique
como pequeña o mediana empresa debe responder a dos (2) de los parámetros
anteriores.
1.2.1.2 Importancia: El aporte de la micro, pequeña y mediana empresa se refleja
en estos indicadores:
Según la ANIF, el segmento de las PYME en el panorama empresarial colombiano
“representa cerca del 75% de los establecimientos y generan más del 40% del
total del empleo en el país” 15.
Debido a la importancia y el crecimiento que han tenido las PYME; diferentes
organizaciones se han motivado para apoyar e impulsar la creación y el desarrollo
de las mismas, estas entidades de apoyo a las PYME son:
MIPYME.com Web: www.mipyme.com
12 COLOMBIA INCLUYENTE. El trabajo en desarrollo empresarial, [en línea], 26/08/2010,
Disponible en internet http://go.microsoft.com/fwlink/?LinkId=121315 13
ACTUALICESE.COM. Ley 905 del 2 de agosto del 2004, [en línea], 29/08/2010, Disponible en
internet http://actualicese.com/normatividad/2004/Ley/L905-04.htm 14
ACTUALICESE.COM. Ley 590 del 10 de Julio del 2000, [en línea], 29/08/2010, Disponible en internet http://www.actualicese.com/normatividad/2000/07/10/ley-590-de-10-07-2000/ 15
DIARIO LA REPUBLICA. Indicador Pyme Anif: Midiéndole el pulso a las Pymes, [en línea], 31/08/2010, Disponible en internet http://rse.larepublica.com.co/archivos/OPINION/2010-08-02/indicador-pyme-anif-midiendole-el-pulso-a-las-pymes_106960.php
38
FUNDACIÓN COMPARTIR Tel: 3126055 Web: www.fundacioncompartir.org
FUNDES Tel: 6069252 Web: www.fundes.org
CORPORACIÓN INNOVAR Tel. 3684983 Web: www.innovar.org
BANCOLDEX Tel. 2868093 Web: www.bancoldex.com
PROE XPORT Tel: 5600146 Web: www.proexport.com.co
CINSET Tel. 2363263 Web: www.cinset.org.co
CONFECAMARAS Tel: 3467055 Web: www.confecamaras.org.co
DEPARTAMENTO NACIONAL DE PLANTACIÓN Tel: 5960300 Web: www.dnp.gov.o
FONDO NACIONAL DE GARANTÍAS Tel: 3382100 Web: www.fng.gov.co
MINISTERIO DE COMERCIO, INDUSTRIA Y TURISMO Tel: 6067676 Web: www.mincomercio.gov.co
MINISTERIO DE LA PROTECCIÓN SOCIAL Tel: 3365066 Web: www.minproteccionsocial.gov.co
39
1.2.1.3 Actualidad de las PYME colombianas:
En algunos estudios realizados por la ANIF16 patrocinados por el Banco
Interamericano de Desarrollo, el Banco de la República y Bancóldex; se analizaron
las opiniones de 1546 empresarios PYME de los sectores de industria, comercio y
servicios, y se logro definir que el IPA (Indicador Pyme Anif) para el primer
semestre del 2010 fue de 61 (ver figura 2) lográndose ubicar como “bueno” según
los umbrales manejados para la GEP (Gran Encuesta Pyme) la cual nos indica el
clima en el que se desarrollan los negocios en el segmento PYME. Según dicho
estudio, la actividad productiva y el crecimiento económico en el primer trimestre
de 2010 presento un crecimiento del 4.4% anual, lo que indica que se presento
una pronunciada mejora en la percepción de los empresarios acerca de la
evolución de sus negocios.
Figura 2: Indicador PYME ANIF
Fuente: LA GRAN ENCUENTA PYME 2010, Disponible en:
http://www.anif.org/includes/scripts/open.asp?ruta=/images/dynamic/articles/2832/EncuestaI-10.pdf
16
ANIF. La gran encuesta pyme 2010, [en línea], 31/08/2010, Disponible en internet http://www.anif.org/includes/scripts/open.asp?ruta=/images/dynamic/articles/2832/EncuestaI-10.pdf
40
En cuanto al sector servicios y según la encuesta, en el año 2009 los subsectores
de informática y de actividades de arquitectura e ingeniería presentaron las
percepciones más favorables como se muestra en la figura 3. Por otro lado el 34%
de las PYME de servicios reportaron haber sufrido un encarecimiento en sus
costos de operación en el segundo semestres del 2009 y solo el 17% informaron
que estos retrocedieron, lo cual ubica en 17 el balance de respuestas siendo el
más bajo entre todos los sectores (ver figura 4).
Figura 3: Situación económica general de las PYME en el 2009
Fuente: LA GRAN ENCUENTA PYME 2010, Disponible en:
http://www.anif.org/includes/scripts/open.asp?ruta=/images/dynamic/articles/2832/EncuestaI-10.pdf
41
Figura 4: Costos de operación de las PYME
Fuente: LA GRAN ENCUENTA PYME 2010, Disponible en: http://www.anif.org/includes/scripts/open.asp?ruta=/images/dynamic/articles/2832/EncuestaI-10.pdf
Por último, en el sector servicios el principal problema que señalaron las Pymes
para el desarrollo de su actividad en el segundo semestre de 2009 fue la falta de
demanda (32%). En segundo lugar se ubica la intensa competencia, con un 25%
de las repuestas, y en tercer lugar está las dificultades asociadas a la falta de
liquidez con un 12% (ver figura 5).
Figura 5: Principal problema de las PYME (%)
Fuente: LA GRAN ENCUENTA PYME 2010, Disponible en: http://www.anif.org/includes/scripts/open.asp?ruta=/images/dynamic/articles/2832/EncuestaI-10.pdf
42
Para el primer semestre del año 2010, un aproximado del 44% de los empresarios
manifestó que el desempeño de su empresa fue favorable y solo el 7% de los
empresarios encuestados anuncio que su desempeño fue desfavorable, lo que
indica que fue un porcentaje relativamente bajo los que presentaron reducciones
en su productividad. Las ramas de asesoramiento empresarial e informática
registraron el mayor grado de optimismo, mientras que en la de actividades de
arquitectura e ingeniería la percepción general fue la menos optimista como se
muestra en la figura 6.
Figura 6: Situación económica general de las PYME en el 2010
Fuente: LA GRAN ENCUENTA PYME 2010, Disponible en: http://www.anif.org/includes/scripts/open.asp?ruta=/images/dynamic/articles/2832/EncuestaI-10.pdf
43
Según una encuesta adelantada por la Acopi17 (oficina seccional de la Asociación
Colombiana de Pequeñas y Medianas Industrias) se encontró que el 66% de las
PYME aplazaron en el primer bimestre del 2010 sus exportaciones, mientras el
34% continúo sus ventas en el exterior.
El sondeo realizado destacó que “en el 2009 el 78% de las Pymes exportó a
Centro y Suramérica y el 22% a los Estados Unidos” 18.
Según las estadísticas anteriores, queda claro que el sector de las PYME cada día
crece más, por tal motivo estas organizaciones deben hacerse más fuertes y
prepararen para ser más competitivas y poder subsistir en el mercado mundial.
Para ello es necesario establecer sus fortalezas, delinear debilidades y dirigir paso
a paso los procesos necesarios en el desarrollo de sus proyectos para lo cual las
buenas prácticas de ITIL son una buena opción.
1.2.2 ITIL
En la actualidad cuando los gerentes comienzan con el proceso de
implementación de ITIL en sus organizaciones, buscan la experiencia y
conocimiento de consultores certificados para que les ayuden en sus procesos de
aplicación. La forma normal en que se aplican estos procesos depende en gran
medida de los recursos que esté dispuesto a invertir en los cambios
organizacionales que conllevan la aplicación de las buenas prácticas, ahora bien,
si un gerente cuenta con todos los recursos suficientes para esto (caso poco
frecuente) se dará cuenta que su organización cambiara por completo.
17 TORMO & ASOCIADOS S.L. 2010 rodaría mejor para las pymes, [en línea], 01/10/2010, Disponible en internet http://www.tormo.com.co/noticias/8177/2010%20rodar%C3%ADa%20mejor%20para%20las%20pymes 18 TORMO & ASOCIADOS S.L. “2010 rodaría mejor para las pymes”, [en línea], 01/10/2010, Disponible en internet http://www.tormo.com.co/noticias/8177/2010%20rodar%C3%ADa%20mejor%20para%20las%20pymes
44
Es claro para todos que la aplicación de ITIL redundará en beneficio para la
organización pero es necesario tener en cuenta el impacto que dichos cambios
generaran a corto plazo y como pueden estos afectar la operatividad de la
empresa, es por eso que proponemos un enfoque diferente para la aplicación de
ITIL, basándose en la afirmación de que no existen organizaciones totalmente
perdidas, que necesiten de un cambio absoluto a ITIL. Es normal encontrar al
interior de las organizaciones, gerentes que cuenten con experiencia y habilidades
determinadas en diferentes áreas. La labor de nosotros como investigadores y
consultores consiste en encontrar el reflejo de las cualidades del gerente al interior
de la organización y comenzar por estas, dado que será más fácil adaptarlas a las
buenas prácticas de ITIL, reduciendo el impacto, y los costos de aplicación al
tiempo que se reduce el temor y la reticencia al cambio del Gerente, al ver que se
aplican cambios sencillos que optimizan la gestión y procesos que él conoce y con
los cuales ya esta acostumbrados, esto permitirá facilitar el proceso general de
ITIL en la organización.
Para este paso inicial es necesario crear un esquema de análisis (aplicación de
pruebas, documentación, recolección de información) que permita identificar el
estado actual de la organización y de las para una fácil y sencilla transición a ITIL
1.2.2.1 Definición de ITIL
(Information Technology Infrastructure Library) que traducido al español (Biblioteca
de Infraestructura de Tecnologías de Información) es el método más ampliamente
adoptada para la Gestión de Servicios de tecnologías de la información (TI) en el
mundo. Proporciona un método práctico, no-absurdo para la identificación,
planificación, entrega y apoyo a los servicios de TI con el negocio.
Como bien ha quedado planteado ITIL, se considera como un marco de trabajo de
las buenas prácticas destinadas a facilitar la entrega de servicios de (TI).
45
“ITIL resume un extenso conjunto de procedimientos de gestión ideados para
ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI.
Estos procedimientos son independientes del proveedor y han sido desarrollados
para servir como guía que abarque toda infraestructura, desarrollo y operaciones
de TI” 19.
ITIL tiene como objeto brindar beneficios que abogan por que los servicios de TI
se alineen a las necesidades y procesos del negocio. Proporciona orientación a
las organizaciones sobre cómo utilizar las TI como una herramienta para facilitar el
cambio de negocios, la transformación y el crecimiento.
Las mejores prácticas de ITIL están detalladas dentro de un enfoque sistemático y
profesional para la gestión de servicios de TI, permitiendo a las organizaciones
prestar servicios adecuados y continuamente asegurar que se cumplan los
objetivos de negocio y la entrega de beneficio.
El ciclo de vida del Servicio de ITIL, comienza con la identificación de las
necesidades de los clientes y de los requisitos de TI, pasando por el diseño y la
implementación del servicio en funcionamiento y, por último, a la fase de
seguimiento y mejora del servicio.
La adopción de ITIL puede ofrecer a los usuarios una amplia gama de beneficios
que incluyen:
Mejora de los servicios de TI.
Reducción de los costos.
Satisfacción del cliente a través de un enfoque más profesional para la
prestación de servicios.
Mejora de la productividad.
Mejor uso de los conocimientos y experiencia.
Mejorar la prestación de servicios de terceros.
19
ITSENCIAL. Las buenas para las TI, [en línea], 23/09/2010, Disponible en internet http://itsencial-elvalordelatecnologia.blogspot.com/2008/01/las-buenas-prcticas-para-las-ti.html
46
1.2.3 ISO 20000
Aunque ITIL es un estándar bastante completo, existen normas que realizan un
gran aporte y sobre las cuales es posible apoyarse durante la implementación del
proceso como la norma ISO 20000.
La norma ISO busca reunir los requerimientos para la gestión de servicios de TI,
mientras ITIL es una recomendación de buenas prácticas; es decir que la
información reunida por ISO 20000 sirve para determinar si la organización cumple
con las prácticas propuestas por ITIL.
ISO 20000 e ITIL son completamente compatibles, la gran diferencia es que la
norma ISO 20000 es totalmente medible pues está debe ser auditada de acuerdo
a los requisitos establecidos en la norma mientras ITIL al ser una recomendación
de buenas prácticas no es medible.
1.2.3.1 ¿Qué es la ISO/IEC 20000?
La norma ISO 20000 antes llamada BS 15000 es la primera norma internacional
que está dedicada a la gestión de problemas de TI. “Es reconocida mundialmente
como un estándar para certificar la Gestión de Servicios de TI de las Empresas y
Organizaciones, ISO/IEC 20000 (International Organization for Standardization) e
IEC (International Electrotechnical Commission)” 20.
Este estándar esta divido en dos partes21.
• Parte 1 (ISO/IEC 20000 – 1): Denominada especificación formal en la cual se
determinan los requisitos que una organización debe cumplir para asegurar que
los servicios ofrecidos sean de buena calidad y cumplan con los requerimientos
20
LATINOAMERICA ISO 20000. Introducción a la ISO Dominicana, [en línea], 02/10/2010, Disponible en internet http://www.iso20000.com.ar/intro_dom.html 21
Ibid
47
exigidos por el cliente, asegurando una optimización de costos y cumplimiento en
la entrega del servicio.
Si la organización logra cumplir esta etapa, podrá garantizar que se encuentra
dentro de un proceso de mejora continua en la gestión de servicios de TI
• Parte 2 (ISO/IEC 20000 – 2): Denominada Código de Prácticas o procedimientos
donde se hace una descripción de las mejores prácticas, procesos o
procedimientos que se deben seguir para la gestión de servicios de TI. Está
fundamentada en el estándar ITIL que es tomado como base para identificar fallas
y determinar el plan de acción o acciones de mejora de los servicios para la
preparación de auditorías contra el estándar ISO/IEC 20000 – 1
48
2. DISEÑO METODOLOGICO
El diseño de la investigación es descriptivo porque va a detallar una serie de
cualidades o características que identifican a la metodología ITIL llamadas
“buenas prácticas”, las cuales permiten la identificación, planificación, entrega y
apoyo a los servicios de TI con el negocio. Con base a ello, se hace un análisis de
la situación actual de la empresa PUNTO DE SERVICIOS para optimizar los
procesos realizados por la misma.
2.1 Tipo de Estudio
El tipo de estudio es aplicado, ya que se elaboró y documentó una propuesta,
donde se entregarán las pautas y lineamientos para el estudio de la situación
actual de PUNTO DE SERVICIOS y la forma en que se debe implementar ITIL a
su interior, a partir de los conocimientos adquiridos a lo largo de la formación
académica como Ingeniero de sistemas.
2.2 Población y muestra
ITIL puede ser aplicado a toda organización independientemente de su tamaño o
actividad económica. La población general de esta investigación pueden ser todas
las organizaciones susceptibles de aplicar la metodología ITIL, las PYMES se
convierten en un sector de esta población desmitificando una creencia que ha sido
constante dentro del ámbito empresarial. El alcance de este trabajo es ajustar
dicho estándar para aplicarlo en la empresa PUNTO DE SERVICIOS.
49
2.2.1 Empresa piloto PUNTO DE SERVICIOS
2.2.1.1 Descripción de la empresa
El objeto social de Punto de Servicios S.A. es la prestación de servicios de
mantenimiento al Hardware y Software para equipos de cómputo de las líneas
corporativas y de hogar.
Sus servicios están dirigidos a clientes que deseen realizar una reparación de sus
equipos portátiles, desktop, servidores, impresoras láser, de inyección y matriz.
Provee repuestos, extensión de garantías, actualizaciones y opciones que
requieran nuestros clientes en cada una de las líneas para las cuales somos
Centro Autorizado de Servicio.
Punto de Servicios S.A. cuenta con el apoyo de sus comerciales como lo son
Acer, Apple, Asus, Dlink, IBM, Lenovo, MSI y Toshiba.
2.2.1.2 Misión
Desarrollo, producción y comercialización de servicios en el campo de la
informática con personal calificado que permita un trato profesional hacia nuestros
socios comerciales.
50
2.2.1.3 Visión
Consolidar a Punto de Servicios S.A. como una empresa especializada en la
prestación de servicios informáticos a nivel nacional fortaleciendo la relación
comercial con nuestros socios comerciales.
2.2.1.4 Política de Calidad
Nuestro compromiso es atender y solucionar requerimientos a nuestros clientes en
el campo de la informática de manera oportuna y cumpliendo con los requisitos
legales y del fabricante. Trabajamos con personal competente y autocrítico que
permite el mutuo beneficio y la mejora continua de nuestro Sistema de Gestión de
Calidad.
2.2.1.4 Listado de cargos
En la sede principal de la empresa punto de servicios, hay un total de 36
funcionarios, divididos de la siguiente forma.
1 Gerente general
1 Director técnico
1 Directora comercial
1 Contador
1 Director de recursos humanos
1 Coordinador administrativo
4 Coordinadores de línea
51
1 Recepcionista
3 Analistas de Service Desk
1 Auxiliar de almacén
2 Técnicos especialistas en impresoras
19 Técnicos
2.3 Supuestos
- La creación de un estándar aplicando la metodología ITIL “Gestión de
Servicios” es viable y aplicable a cualquier PYME.
- El diseñar el estándar de evaluación con base en los fundamentos de ITIL
mejorara la competitividad y calidad en la gestión de TI en PUNTO DE
SERVICIOS.
2.4 Instrumentos
2.4.1 Encuesta.
Es una práctica o técnica de investigación donde se hacen una serie de preguntas
de forma escrita o verbal a diferentes personas con el fin de conseguir la
información necesaria para la investigación sobre un tema en especial.
El tipo de encuesta realizada es semi-estructurada pues son casos donde se dio
libertad de modificar el orden, la forma de consultar y el contenido de las
preguntas dependiendo de la información suministrada por el encuestado sin que
se pierda el enfoque de la investigación y cumpliendo los objetivos que se desean
lograr, para cada una de las gestiones que requerían ser analizadas se estableció
un formato diferente pertinente para cado caso (ver anexos A y B).
2.4.2 Entrevista.
Conversación en la que el entrevistador realiza una serie de preguntas al
entrevistado con el fin de obtener información de forma verbal acerca de los
52
procesos llevados en el área donde desempeña su labor. El analista tiene la
opción de realizar entrevista grupal o individual dependiendo de la necesidad.
Para dar cumplimiento a lo anterior se realizaron entrevistas a los diferentes
líderes de cada área con el fin de obtener la información necesaria para dar
cumplimiento al objetivo de la investigación.
2.4.3 Análisis documental.
Es una un instrumento para obtener información que consiste en un conjunto de
operaciones intelectuales con las cuales se busca examinar, describir y
seleccionar ideas de un documento con el objetivo de expresar y analizar su
contenido.
Existen dos etapas del análisis documental:
Análisis formal: “es aquel que recoge todos los elementos objetivos del
documento: tipo, autor, título, editorial, fecha, número de páginas, idioma
original, etc. Se trata de un análisis externo del documento que extrae
aquellos datos que lo distinguen de los demás” 22.
Análisis de contenido: “es aquella operación intelectual o automática según
la cual se describe aquello que trata el documento y los productos
resultantes son: la clasificación, la indización y la condensación
(resumen)” 23.
2.5 Procedimientos
El procedimiento realizado durante el desarrollo del proyecto en la empresa
PUNTO DE SERVICIOS se resume en los siguientes pasos.
22
SOLIS, Isabel. El análisis documental como eslabón fundamental para la eficiencia de los servicios de información. Cuba, [en línea], 20/10/2010, Disponible en internet http://www.monografias.com/trabajos14/analisdocumental/shtm.
23 Ibid.
53
1. Se contacto personalmente al Gerente de PUNTO DE SERVICIOS dando a
conocer la idea y los fundamentos del proyecto de grado.
2. Por solicitud del Gerente, se presento una propuesta escrita, informando el
detalle de la metodología a tratar
3. La Gerente administrativa realizó el análisis de la propuesta y aprobó el
desarrollo de la investigación en la empresa.
4. Se asigno a una Coordinadora de línea como líder técnica para realizar el
acompañamiento durante todo el desarrollo del proyecto.
5. Se realizó un recorrido por toda la empresa para conocer las instalaciones,
áreas y empleados con los que cuenta la compañía.
6. Se hizo presentación formal de cada uno de los líderes de área con los cuales
se interactuó durante todo el proyecto.
7. Se aplicaron las entrevistas a cada líder de área.
8. Se aplicaron las encuestas a cada líder de área.
9. Se solicitaron formatos y documentos usados por la empresa en sus procesos.
10. Se realizó el análisis de la información adquirida.
11. Se generaron las recomendaciones pertinentes con base en el análisis
realizado.
12. Se efectuó el desarrollo de la propuesta que se entregara a la compañía
2.6 Consideraciones éticas.
Durante el proceso en el cual se realizó el levantamiento de la información fue
necesario establecer compromisos exigidos por la empresa piloto PUNTO DE
SERVICIOS en donde los estudiantes que realizaron las trabajo de grado, se
comprometen a manejar la información de manera confidencial y sólo se hará uso
de ella con fines de investigación. Para este acuerdo fue necesario presentar una
carta (ver Anexo C) donde se informan los datos personales de cada estudiante y
el compromiso adquirido; dicha carta fue firmada por el Coordinador de
Investigación de la universidad JAIME AGUSTO PINZON MENDIENTA
54
3. RESULTADOS
3.1 Encuestas
El análisis de las encuestas se hace a través de un sistema de seguimiento de
cada una de las gestiones que conforman la metodología ITIL. La aplicación de las
encuestas se hará en dos fases.
1. Primera fase: Se aplicaran las encuestas que mide la importancia de cada
gestión en la empresa. En ella se evaluara por puntos su desarrollo e
importancia, esto nos indicara cuáles son las gestiones que inicialmente se
deben reforzar en el desarrollo de la implementación de ITIL, dejando en un
segundo plano las gestiones que pueden tratarse en un segundo proyecto y
que no son significativas para el negocio.
2. Segunda Fase: Se aplicaran las encuestas con las cuales se realizara un
análisis donde se trata a profundidad cada una de las gestiones que
sobresalieron en la primera parte del análisis, dicha encuesta va enfocada a
determinar el estado real de cada gestión y se conocerá el cumplimiento que la
PYME le da a cada una de estas, con esta encuesta se sabrá exactamente
cuáles son los cambios que deben implementarse, esto permite reducir costos
y tiempos durante la implementación.
55
3.1.1 Aplicación de las encuestas
A continuación se mostrara las encuestas aplicadas sobre cada una de las
gestiones
Encuestas para desarrollar la primera fase:
Centro de servicios
Si X No
Si No X
Si X No
ALTA . X MEDIA . BAJA .
ALTA . X MEDIA . BAJA .
CENTRO DE SERVICIO
Tiene contacto con los clientes internos o externos en su área?
Que importancia Tiene para su negocio el reporte de incidentes?
Tiene un área u grupo destinado para contactar o interactuar con sus clientes
Posee un sistema para gestionar incidentes y/o problemas de TI los cuales serán tomados por un área de soporte?
Otorgue un valor de 1 a 3, Según la importancia que le de al caso: 1 para bajo, 2 medio, 3 alta
Que nivel de importancia le da al área que realiza contacto con el cliente
Figura 7: Resultados encuesta centro de servicios
CENTRO DE SERVICIO
Necesidad Importancia
CENTRO DE SERVICIO
Media
Baja
Alta
Punto de Servicio no cuenta con un centro de Servicio claramente establecido,
pero cuentan con un personal que está encargado de hacer la recepción de
equipos traídos directamente por los clientes, para punto está claro que un buen
servicio se ve reflejado en la atención al cliente que estos funcionarios hagan.
56
Cuando se recibe un equipo los encargados de hacer esta recepción crean el
incidente con el cual trabajara más adelante el área técnica, en ocasiones cuando
se realiza el registro del problema se detecta cual es el problema y es solucionado
de inmediato, pero no se guardan registro en el sistema de este incidente, por lo
cual se desconoce el grado de importancia de esta labor y su valor agregado a los
procesos de Punto de servicio.
Como se puede ver en la grafica de análisis para punto es muy importante definir
un centro de servicios claros para hacer la interacción entre clientes y áreas de
soporte, pero el valor que le dan a esta necesidad esta por debajo del que
realmente necesitan.
Gestión de Incidentes:
Figura 8: Resultados encuesta gestión de incidentes
G INCIDENTES
Necesidad Importancia
G INCIDENTES
Media
Baja
Alta
57
Para Punto de Servicio como una empresa orientada a dar soporte técnico a
personas naturales y jurídicas, el núcleo de su operación es la atención de
incidentes orientado a los clientes externos y no a los internos (Aunque el mismos
centro de soporte cubre las dos necesidades).
Como ocurre con el centro de servicios en la gestión de incidentes, la necesidad
que cree tener la empresa es inferior a la importancia real que tiene esta gestión
para sus intereses y el mantenimiento del negocio.
El principal fallo en la gestión de incidentes es que no existe una documentación o
acuerdo establecido para definir la forma en que se le da prioridad a los casos,
queda a criterio del técnico la prioridad que se le asigna y en ocasiones es
influenciado por el grado de importancia del cliente a atender, pero esto puede
ocasionar que se perjudique a otros clientes, afectando directamente el nombre de
la compañía y la calidad de su servicio.
Gestión de problemas:
58
Figura 9: Resultados encuesta gestión de problemas
G PROBLEMAS
Necesidad Importancia
G PROBLEMAS
Baja
Aunque la necesidad que le da actualmente la organización es inferior que la
importancia que realmente tiene la gestión de problemas, en general la
importancia para el negocio es muy baja, dado que el control de problemas en la
organizaron es limitado y en la atención de clientes externos el control de
problemas es llevado de la mano por cada una de las casa o marcas de productos
que manejan.
Gestión de la configuración:
59
Figura 10: Resultados encuesta gestión de configuración
G CONFIGURACION
Necesidad Importancia
G CONFIGURACION
Media
Baja
Alta
Aunque Punto de servicios no ve la necesidad de manejar una adecuada gestión
sobre sus elementos de configuración, si ve una gran importancia en ejercer un
Mayor control sobre la rapidez en la restauración del servicio para sus usuarios
externos.
Es importante conocer que se tiene en la infraestructura de TI para así mismo
poder hacer una adecuada gestión en la asignación de recursos para la solución
de incidentes.
Gestión de cambios:
60
Figura 11: Resultados encuesta gestión de cambios
G DE CAMBIOS
Necesidad Importancia
G DE CAMBIOS
Baja
En apunto de servicio la necesidad que ve la organización de implementar una
gestión de cambios es baja al igual que la necesidad real que tienen de usarla.
Dado a que no manejan aplicaciones y los cambios en cuanto a plataformas de
hardware son mínimos, históricamente la empresa no se ve en la necesidad de
invertir algún tipo de recursos en la gestión de cambios.
Aunque en las entrevistas se ve la necesidad de contar un administrador que
controle el software de incidentes, se debe tener en cuenta que ante esta
implementación seria necesario estudiar si un cambio en su sistema podría afectar
a otros usuarios internos de PS.
Gestión de versiones:
61
Figura 12: Resultados encuesta gestión de versiones
G VERSIONES
Necesidad Importancia
G VERSIONES
Baja
Punto de servicio como tal no hace lanzamiento de versiones nuevas, no ve la
necesidad de invertir en este tipo de gestión y no requiere realmente hacerlo.
Por el momento cuenta con una librería del software y un inventario de hardware
existente pero se presenta una carencia en la documentación de los diferentes
procesos de la empresa la cual a futuro tendría que revisarse a pesar de la poca
importancia que tiene la gestión al interior de la empresa.
Gestión de Niveles de servicio:
62
Figura 13: Resultados encuesta gestión de Niveles de servicio
N DE SERVICIO
Necesidad Importancia
N DE SERVICIO
Media
Baja
Alta
La necesidad que ve punto en la empresa es de nivel medio pero su importancia
es realmente alta.
Al realizar las encuestas y entrevista se destaca que a pesar de tener unos
servicios definidos la empresa no se compromete a dar tiempos fijos a los usuarios
por que depende de proveedores y refacciones de terceros que crean una gran
variación en sus tiempos de respuesta.
Gestión de Financiera:
63
Figura 14: Resultados encuesta gestión financiera
G FINANCIERA
Necesidad Importancia
G FINANCIERA
Media
Baja
A pesar de que la organización siente una gran necesidad de ejercer una gestión
financiera, la importancia que esta refleja para el negocio es baja, pero este
comportamiento es de esperarse al tratarse de una PYME que se esmera por
cuidar sus recursos y sacarles el mayor partido.
Gestión de la capacidad:
64
Figura 15: Resultados encuesta gestión de capacidad
G DE CAPACIDADO
Necesidad Importancia
G DE CAPACIDADO
Media
Baja
Dada la operatividad de la línea estudiada en punto, la gestión de capacidad
carece de importancia en comparación con las demás gestiones y para la
organización la necesidad de inversión es mínima, dado que las casas de marca
proporcionan las actualizaciones y componentes necesarios para la atención de
clientes externos e incluso de los internos.
Gestión de la continuidad del servicio:
65
Figura 16: Resultados encuesta continuidad del servicio
G DE CONTINUIDAD DEL SERVICIO
Necesidad Importancia
G DE CONTINUIDAD DEL SERVICIOMedia
Baja
La visión Punto de servicio es muy en cuanto a la forma de responder ante una
catástrofe de fuerza mayor basándose en sus recursos, no cuenta con una
infraestructura de respaldo, así que sus planes se limitan a informar de los
inconvenientes a los usuarios e informarlos de los avances para restaurar sus
servicios.
Gestión de la disponibilidad:
66
Figura 17: Resultados encuesta gestión de disponibilidad
G DE DISPONIBILIDAD
Necesidad Importancia
G DE DISPONIBILIDAD
Media
Baja
Punto de servicio no considera importante mantener una buena gestión de
disponibilidad, esencialmente por que su gestión de acuerdos de servicio no ha
madurado de tal forma que permita establecer tiempos concretos para sus
servicios, una vez esta gestión este bien establecida, la importancia de la
disponibilidad se incrementara en miras de poder respaldar los compromisos en
tiempos adquiridos con los SLA
Gestión de la seguridad:
67
Figura 18: Resultados encuesta gestión de la seguridad
G DE SEGURIDAD
Necesidad Importancia
G DE SEGURIDAD
Media
Baja
En este momento Punto de servicio siente la necesidad de pedir a los clientes que
aseguren su información y no se hacen responsable por ella, dejando esto en
manos de sus clientes, aparte de esto, punto no considera que existe información
interna que requiera una inversión para mantener de forma segura.
La información es manejada por cada uno de los jefes de línea, y las áreas
comerciales, los cuales se encargan de divulgarla a medida que lo creen
conveniente.
Encuestas de la segunda fase
Estas permiten determinar el nivel de profundidad y apropiación en la organización
y son las que determinaran la forma en que se debiera proceder a hacer una
implementación, dándole al consultor una clara indicación de la forma a proceder
dentro de la organización.
68
Si X No
Si No X
Si X No
Si No X
Si X No
Si No X
Si No X
Si No X
Si No X
Si No X
Si X No
(Solo quien respondió SI) ¿Cómo encuentra el producto?
Si No X
Si No X
Si No X
Tanto los operadores de incidentes como los usuarios conocen los tiempos para cada prioridad?
Se ajusta a las necesidades, pero hace falta un administrador que pueda adaptarlo a la medida del crecimiento de la
organización
Su área de contacto gestiona cambios solicitados por los clientes mediante peticiones de servicio.
Su área de contacto hace análisis del problema registrado en el incidente?
Su área de contacto cierra incidentes y confirma con los clientes.
Su área de contacto le informa a sus usuarios la prioridad de atención y tiempo relacionado que tendrá la atención del caso?
Su área de contacto monitoriza incidentes.
Su área aplica soluciones a errores conocidos en colaboración con las áreas técnicas
Su área de contacto colabora con la actualización de las bases de datos Sobre problemas.
Centro de Servicios
Tiene un área que Interactúa con usuarios
El área de contacto con el usuario funciona como centro neurálgico de todos los procesos de soporte al servicio
Su área de contacto Registra los incidentes de los usuarios
¿Usa algún sistema de registro de incidentes o software de Helpdesk?
¿Dispone de reportes mensuales indicando la productividad de los recursos TI (tiempo de respuesta, problemas solucionados, etc.)
Todos los incidentes pasan por un proceso de Evaluación de la prioridad?
Encontramos un nivel de apropiación del 30% sobre lo que dictan las mejores
practicas para un centro de servicios, es importante destacar que entre las
necesidades detectadas encontramos que no se hace un buen aprovechamiento
del recurso humano e intelectual que se cuenta con esta área, se debe revisar la
interacción del centro de servicio como foco de los incidentes que ingresan al área
de soporte, la interacción con el usuario final, la carencia asignación de una
prioridad para los incidentes y la falta de creación de indicadores para medir el
área.
69
La gestión de incidentes es la más importante para la organización, como tal la
línea de trabajo estudiada consiste en atender incidentes de usuarios externos,
por lo cual se ve la necesidad de hacer una cuidadosa implementación de esta
gestión. El nivel de apropiación en esta gestión es del 50% y es importante dedicar
especial atención en establecer una base de conocimientos que este disponible
para las áreas de soporte y la creación y seguimiento de informes de medición
que permitan mostrar el estado real del área.
70
Si No x
Si No x
Si No x
Si No x
Si No x
Si x No
Si No x
Si No x
Si No x
Si No x
Si x No
Si x No
Si No x
x
x
Si x No
Existe un responsable de la CMDB y su gestion?
Se ha definido una herramienta de control y un nivel de profundidad en el detalle de la CMDB?
Se realizan informes periódicos de la información y configuración registrada en la CMDB?
Existe información de las relaciones entre los diferentes elementos de configuración? (Padre – hijo, interdependencias)
Existe un tipo de nomenclatura utilizada para cada item de configuración?
Se monitorea con frecuencia el estado de los elementos de configuración?
Los elementos de configuración están compuestos por Hardware, software y documentación (SLA, SLO, Auditorias,
Gestión de Configuraciones
Poseen y lleva control de una Base de Datos de los elementos de Configuración (CMDB) de TI? (Físicos y logicos)
Las diferentes áreas de TI que intervienen en la gestión de Incidentes, Problemas, Cambios y Versiones tienen acceso a la
información de los elementos de configuración de TI y la actualizan constantemente?
Se monitorea y actualiza periódicamente Información de los elementos de configuración
d. Gestión de problemas
¿Se lleva un registro de los recursos informáticos y tecnológicos de la Organización?
¿Considera esto útil?
¿Cuenta en su empresa con una base de conocimientos que permite inferir respuestas a problemas comunes?
Indique cual de las siguientes opciones cuenta hoy en día su organización:
a. Inventario de Hardware
b. Inventario de Software
c. Gestión de incidentes
Indique de las opciones anteriores cuales de ellas les resultaría útil o cuales desearía tener
e. Encuesta de satisfacción al cliente
Incidentes
Puede realizar consultas mediante la aplicación que monitoriza las existencias de almacén de equipos y repuestos?
El nivel de apropiación de la gestión de configuraciones es de un 30% pero su
importancia radica en el soporte que dará a la gestión de incidentes, ya que para
punto de servicio estas dos se encuentran estrechamente relacionadas.
71
La necesidad de contar con una CMDB que pueda ser seguida, monitoreada y
puesta a disposición de los servicios ofrecidos al cliente es fundamental para
poder mejorar los niveles de calidad de Punto de servicio.
Si X No
Si X No
Si X No
Si No X
Si No X
Si No X
Si No X
Si No X
Si No X
Si No X
Si No X
Existe un documento en donde se especifiquen cuáles serán los indicadores clave de rendimiento para cada uno de los
servicios prestados?
Cada uno de sus servicios dispone de una guía dirigida a los clientes para que a la hora de seleccionar un servicio, este se
adapte a sus necesidades y no se presenten mal entendidos futuros?
Los informes de rendimiento elaborados incluyen factores como: Cumplimiento de los SLAs, nivel de satisfacción de cada
cliente, tiempos de respuesta, problemas detectados, cambios realizados, y calidad del servicio de los proveedores externos?
Se establecen niveles de urgencia y prioridad para la atención de incidentes los cuales conoce el usuario final y en el
momento de la medición se presentan resultados para cada una de estas clasificaciones?
Se llevan a cabo acuerdos de niveles de servicio entre clientes y proveedores de servicio, para establecer prioridades y
tiempos de respuesta?
Elabora métricas que le permiten evaluar los niveles de servicio?
Las áreas de centro de soporte disponen de un documento de referencia para la relación con el cliente en todo lo que respecta
a la provisión de los servicios acordados, como su descripción, disponibilidad, niveles de calidad, tiempos de recuperación,
etc.
Se dispone de un documento interno para la organización donde se especifican las responsabilidades y compromisos de los
diferentes departamentos de TI en la prestación de un servicio?
Gestión de Niveles de Servicio
Cuenta con una Definición de los servicios ofrecidos.
Conoce las necesidades de sus clientes, y orienta su servicio a satisfacer esta necesidades?
Existe un monitoreo constante de la calidad del servicio?
La gestión de nivel de servicio solo cuenta con un 25% de apropiación pero es
fundamental para garantizar la calidad del servicio y poder establecer un esquema
de medición y respuesta de cada una de las partes que interviene en las áreas de
soporte a usuarios.
72
Análisis General:
Como se indico anteriormente las organizaciones a pesar de no conocer ITIL,
pueden hacer uso de las mejores prácticas a un nivel intuitivo o informal, como
resultado del primer análisis podemos indicar cuales gestiones son las más
importantes para la empresa y si cuentan con algún grado de apropiación de
mejores prácticas.
Figura 19: Grado de Aprobación
Como se puede ver en el grafico (figura 19) encontramos que para la organización
punto de servicio se tienen unas gestiones que se acercan más a las mejores
prácticas.
Se estableció que según la evaluación de las encuestas se podía determinar que
las gestiones de Centro de servicio e incidentes tienen una apropiación de nivel
intuitivo, con procesos que siguen un patrón regular aunque no están
formalizados, las tareas son conocidas pero no estandarizadas, los recursos se
centran en la operación y no tienen métricas definidas.
Las gestiones de configuración y niveles de servicio tienen un nivel informal, con
procesos no documentados y desorganizados, no existe una correcta
planificación, lo que impide hacer un correcto seguimiento a los diferentes
esfuerzos de las áreas de la empresa.
73
Figura 20: Nivel de Importancia
0
0,5
1
1,5
2
2,5
3
3,5
C. Servicio G. Incidentes G. Problemas G. Configuracion
G. Cambios G. Versiones G. Niveles de Servicio G. Financiera
G. Capacidad G. Continuidad S G. Disponibilidad G. Seguridad
También se realiza un análisis de las gestiones que son realmente importantes
para la organización y que desde el punto de vista de la gerencia y coordinadores
de procesos son más importantes para el desarrollo de las tareas diarias que
mantienen el negocio.
3.2 Entrevistas
Para documentar mejor cada uno de los procesos relacionados que las diferentes
gestiones de TI de Punto de Servicio, se entrevisto a cada uno de los
representantes de área, el objetivo de estas entrevistas estaba el apoyar e
indagando sobre sus procesos de área para despejar algunas dudas encontradas
durante la realización de las encuestas de profundización.
Los videos de entrevistas hacen parte de los archivos adjuntos de este trabajo y
se encuentran en la carpeta Videos, Los videos están numerados en orden pero
se dejaron sin editar para mantener mayor claridad sobre la forma en que se
realizo la entrevista.
3.2.1 Resultados de la entrevista
Flujos de procesos Con base a las entrevistas realizada se generaron los flujos de los procesos más
importantes llevados por la empresa PUNTO DE SERVICIOS
74
1. Proceso de general de incidencias
Figura 21: Proceso general de incidencias
75
Descripción de proceso 1. El usuario lleva el equipo a la empresa PUNTO DE SERVICIOS.
2. El personal encargado de la recepción de equipos hace la validación de la falla
y determina si es algún inconveniente en la configuración o si es falla de
hardware.
3. En el caso en que la falla sea de configuración y su solución no necesite
asistencia técnica, se hace el proceso de solución y se entrega el equipo
funcionando. Este proceso no queda registrado en sistema.
4. En el caso en que la falla no se pueda solucionar inmediatamente o sea
problemas de hardware y necesite asistencia técnica, se hace el registro en
sistema donde se ingresan los datos personales del usuario (nombre,
apellidos, documento, celular, ciudad, email, etc), datos de la maquita (estado
físico o cosmético, detalle de cada parte que compone el equipo), y falla
reportada por el cliente.
5. Después de registrado en sistema, se envía el equipo a bodega donde realizan
una asignación de pin e ingresan el equipo a un stand mientras se hace la
asignación de técnico. Este proceso también queda registrado en sistema.
6. Diariamente el coordinador de línea (distribuido por marcas) valida las ordenes
ingresadas al sistema y el estado en que se encuentran; cuando la orden de
servicio no se encuentra asignada, se realiza la asignación del técnico que va
a dar trámite al daño reportado.
7. Los técnicos validan en sistema que ordenes tiene asignada, y posteriormente
se dirigen a bodega a retirar el equipo asignado para su respectiva reparación.
8. La persona encargada de bodega realiza la entrega del equipo y registra esta
entrega en sistema.
9. El técnico realiza la validación y el diagnostico de la falla presentada por la
maquina. En este paso se determina si es necesario cambiarle alguna parte al
equipo.
10. En caso de necesitar algún repuesto, se ingresa al sistema la información
correspondiente y la parte requerida para el cambio.
76
11. En el transcurso del día el coordinador de línea hace las validaciones
correspondientes en sistema y cuando hay órdenes de servicio con el estado
“Pendiente pedido proveedor”, realiza el trámite correspondiente para solicitar
el repuesto con el fabricante correspondiente.
12. El tiempo que dura en llegar el repuesto depende únicamente de la marca pues
hay fabricantes que envían la parte en menos días que otros.
13. Si el tiempo límite pasa y no llega el repuesto se hace necesario validar que la
orden se halla enviado correctamente y que los datos no estén incorrectos, en
caso de encontrar algún error se corrige lo antes posible para que la parte sea
enviada.
14. Cuando el repuesto llega, se hace la entrega al técnico para que cambie la
parte en el equipo y realice el respectivo reporte en sistema, en dicho reporte
debe quedar plasmado todo el proceso que se realizo con el equipo, que parte
se cambio y el motivo por el cual fue necesario el cambio.
15. Después de haber cambiado la parte defectuosa, el coordinador de línea
realiza los trámites correspondientes y trámites legales (en caso necesario)
para hacer la devolución de la parte al fabricante en caso que el servicio sea
por garantía, pero si la reparación se hizo por facturación, esta parte será
entregada al cliente.
16. Finalmente cuando el equipo ya se encuentra reparado, el técnico es el
encargado de ingresar el equipo nuevamente a bodega, donde realizan la
actualización del estado en el sistema y le asignan un nuevo pin el cual
identifica al equipo como reparado, después se archiva en un stand hasta que
sea entregado al usuario.
17. Cuando el usuario reclama el equipo, se hace la actualización en sistema y se
cierra el caso.
77
2. Proceso de seguimiento a las ordenes de servicio
Figura 22: seguimientos a las órdenes de servicio
Descripción de proceso
1. Este proceso se inicia cuando el coordinador de línea valida en sistema los
casos que aun se encuentran pendientes de gestión y solución. Dicha
validación se realiza por marca pues los técnicos se asignan dependiendo la
marca que esta reportada.
2. Una vez realizado el filtro por marca se valida el estado de las ordenes
registradas en sistema. Existen varios estados
- No asignada
- Pendiente diagnostico (asignada)
- Diagnosticada
- Pendiente pedido proveedor
78
3. Si la orden se encuentra “No asignada”, el coordinador de línea realiza la
asignación de técnico para realizar diagnostico y reparación de la falla.
4. Si la orden se encuentra en estado “Pendiente diagnostico”, significa que ya
fue asignada a un técnico y que se encuentra en proceso de reparación.
5. Para el caso anterior se valida cuanto tiempo lleva la orden en este estado, es
importante que el coordinador de línea esté pendiente que los tiempos de
respuesta establecidos se cumplan.
6. Si el tiempo en que la solicitud se encuentra en el mismo estado ha superado
el límite de 3 días, se valida cual es la falla, se le hace una retroalimentación al
técnico el cual deberá diagnosticar el equipo cuanto antes y se validaran los
motivos por los cuales se presenta retraso en la gestión realizada.
7. Si la orden se encuentra en estado “Diagnosticada”, significa que ya fue
asignada a un técnico y que este ya valido el daño del equipo, sin embargo no
has sido ejecutada la reparación.
8. Para el caso anterior se valida cuanto tiempo lleva la orden en este estado, es
importante que el coordinador de línea esté pendiente que los tiempos de
respuesta establecidos se cumplan.
9. Si el tiempo en que la solicitud se encuentra en el mismo estado ha superado
el límite de 3 días, se valida cual es la falla, se le hace una retroalimentación al
técnico el cual deberá diagnosticar el equipo cuanto antes y se validaran los
motivos por los cuales se presenta retraso en la gestión realizada.
10. Por último, si la orden no se encuentra en ninguno de los estados nombrados
en los anteriores pasos, el único estado en el que se puede encontrar es en
“Pendiente pedido proveedor” que es cuando ya fue diagnosticado el equipo,
pero no se ha podido efectuar la reparación pues se debe cambiar alguna
parte.
11. Para este caso se valida si la parte solicitada por el técnico ya fue pedida al
fabricante.
12. En caso de no haberse pedido el repuesto se hace el proceso de “Solicitud de
repuestos” descrito en la figura 23
79
13. En caso de haberse pedido el repuesto se valida el estado del pedido y se
confirma que los datos registrados estén correctamente diligenciados.
3. Proceso de mantenimiento
Figura 23: Proceso de mantenimiento
80
Descripción de proceso
1. Los mantenimientos pueden ser de 2 tipos: Preventivos o Correctivos.
2. En caso que el mantenimiento sea preventivo, se debe realizar un análisis a la
propuesta recibida por parte del fabricante.
3. En la propuesta se debe realizar el análisis de algunas variables como:
Disponibilidad de recursos.
Cantidad de técnicos.
Perfiles: conocimientos necesarios para el proceso.
Tiempo de duración: Servicio por días o por horas.
Rentabilidad del negocio.
Necesidades de diagnostico: enviar técnico a terreno o en laboratorio.
4. Una vez realizado dicho análisis se diligencia la información en formato de
propuesta el cual será estudiado para determinar si la propuesta es o no es
viable.
5. En caso de no ser viable, se le informa al fabricante que no se acepta la
propuesta y se finaliza el proceso.
6. En caso de no ser viable, se realiza el proceso descrito más adelante,
empezando por el punto 8.
7. En caso que el mantenimiento no sea preventivo, entonces es correctivo.
8. En este caso el coordinador de línea realiza la asignación de técnico para el
caso según la marca del equipo.
9. Una vez el técnico haya retirado el equipo de la bodega, realiza el inventario
del equipo (seriales, capacidad de cada parte, etc), se valida el estado físico y
cosmético en el que se encuentra la maquina. Esta información debe quedar
registrada en el sistema.
10. En caso que se encuentren inconsistencias entre la información registrada por
el personal de servicio al cliente y la información real del equipo, se informara
por correo o vía telefónica al cliente sobre el inconveniente.
11. Si el cliente después de conocer esta información, acepta que se realice la
reparación, se seguirá el proceso de reparación (punto 13)
81
12. Si por el contrario, el cliente no acepta dicha información y decide no seguir
con la reparación, se hará el proceso de entrega del equipo al cliente.
13. En caso que no se encuentren inconsistencias entre la información registrada
por el personal de servicio al cliente y la información real del equipo, el técnico
realizara la validación o diagnostico de la falla presentada por equipo
reportado.
14. Puede presentarse que la falla presentada por el equipo no sea un problema
conocido, en tal caso se enviara la información al fabricante para recibir
retroalimentación del procedimiento a seguir en esos casos especiales.
15. Cuando se recibe respuesta del fabricante sobre el procedimiento a seguir, se
envía la información al técnico encargado del caso y se realiza el
procedimiento para divulgación de tips (figura 25), después se realizaran los
pasos siguientes descritos desde el punto 16.
16. El técnico procede a realizar el mantenimiento del equipo, en este caso si hay
necesidad de cambiar una parte se hará el procedimiento “Solicitud de
repuestos” descrito en la figura 23
17. Se realiza registro en sistema del procedimiento realizado por el técnico con el
cual se dio solución a la falla.
18. Finalmente el coordinador de línea o el director técnico realizan una validación
para control de calidad en la cual se revisa que el equipo este en perfectas
condiciones, se hacen pruebas de rendimiento y se confirma que ya quedo
completamente reparada la falla.
19. En caso que la falla sea solucionada se hace actualización del estado de la
orden de servicio en sistema para que el caso ya quede cerrado, también se
ingresa el equipo a bodega para que esté listo para la entrega al usuario.
20. En caso que la falla no se haya solucionado, el caso será devuelto al punto 16.
82
4. Proceso de solicitud de repuestos
Figura 24: Proceso de solicitud de repuestos
83
Descripción de proceso
1. El coordinador de línea realiza la validación en sistema de los casos que se
encuentren en estado “Pendiente pedido proveedor”.
2. Se valida si el pedido ingresado esta por garantía o facturación.
3. En caso de estar por garantía, el coordinador de línea realiza el procedimiento
correspondiente para solicitar repuestos al fabricante, el sistema en el que se
hace este proceso varía dependiendo de la marca del equipo pues cada
fabricante tiene su página para realizar pedidos de partes por garantía.
En cualquier caso se debe diligenciar los datos de la persona que registra
como dueña de la maquina, datos del equipo (serial del equipo, tipo y modelo,
fecha de solicitud, persona encargada – director técnico, parte a solicitar, sede
a donde se despachara la parte, etc.), el sistema genera un numero de pedido
el cual se ingresa en sistema.
4. Se valida si la garantía fue aprobada por el fabricante, en caso de ser negativa
la aprobación se le informa al usuario lo sucedido para que de la autorización
de realizar el pedido pero no por garantía sino por facturación descrito desde el
punto 11.
5. En caso que la garantía sea aprobada, se espera el tiempo necesario para
recibir los repuestos enviados por el fabricante. En ocasiones no se cumplen
los SLA porque hay algunos fabricantes que se demoran mucho tiempo en
enviar los repuestos.
6. Se esperan los días establecidos para envió de repuestos dependiendo la
marca (máximo 8 días) y antes que se cumpla el tiempo establecido para
reparación de los equipos (10 días pero se espera llegar a 4 días) se valida si
ya llegaron los repuestos. El tiempo que se demora el fabricante en enviar la
parte defectuosa valida la marca pues todos no manejan los mismos tiempos.
7. En caso de no haber llegado los repuestos, se valida que los datos ingresados
en el pedido realizado al proveedor estén correctos y completos, de haber
algún error se hace la corrección para que el fabricante envíe la parte.
84
8. En caso de haber llegado los repuestos, se cierra el pedido y se envía la parte
al técnico para que ejecute la reparación del equipo, la cual no se puede
demorar más de 2 días después de recibida la parte.
9. Posteriormente el coordinador de línea realiza la devolución de los repuestos,
dependiendo la marca se entregan a medida que se van reemplazando y en
otras el mismo fabricante recoge las partes defectuosas. En los casos en que
se debe hacer la devolución fuera del país, se realiza el proceso
correspondiente, cumpliendo los requisitos de ley necesarios (factura
comercial, guía, etc.) para poder devolver la parte al fabricante.
10. Se entrega el equipo a bodega y se envía notificación por correo al cliente
sobre la solución del caso.
11. Si la orden es por facturación se cambia en sistema el estado a “Pendiente por
cotizar”
12. El coordinador de línea es el encargado de enviar el caso por correo al asesor
comercial para que realice el proceso correspondiente y la cotización de la
parte requerida al fabricante.
13. Una vez el asesor comercial tenga la información requerida, envía la cotización
al cliente para que apruebe o no la compra de la parte dañada.
14. En caso que el cliente apruebe la compra, se envía la solicitud de compra al
fabricante y se sigue el procedimiento realizado desde el punto 6.
15. En caso de no aprobarse la compra se realizara la entrega del equipo sin
reparar al cliente.
85
5. Proceso para validación de cumplimiento de los SLA Figura 25: Proceso para validación de cumplimiento de los SLA
86
Descripción de proceso
1. El director técnico realiza las mediciones de cumplimiento en cuanto a las
metas establecidas.
2. Inicialmente se descarga toda la información del sistema y se define cual será
el indicador que se medirá. Existen tres indicadores.
- TTS (Tiempo Total de Servicio): duración de reparación de del servicio.
- DT (Desempeño del técnico):
- Garantías de Servicio: Equipos que regresan al laboratorio en un
término menor a 90 días.
3. En caso que se desee medir el indicador TTS se debe validar los siguientes
datos
- Validación de metas: se hace por marcas
- Días: menor a 10 días para reparación con fines de bajarla a 4 días.
- Total de servicios reparados
- % cumplimiento
4. Después de tabulados estos datos se valida si se cumple o no la meta
establecida
5. En caso de no cumplirse las metas se realiza un análisis para determinar los
motivos por los cuales esa meta no fue cumplida.
6. Una vez se sepan los motivos del incumplimiento, se genera las
retroalimentaciones correspondientes al área o persona que cometió el error.
7. Finalmente se generan informes con la información sobre el caso y las
medidas tomadas para evitar el incumplimiento de los SLA.
8. En caso de cumplirse las metas se omiten los pasos 5 y 6.
9. En caso que se desee medir el indicador DT se debe validar los siguientes
datos
- Nombre del técnico
- # Equipos reparados ( 4 equipos por día)
- # Servidores reparados (1 servidor vale lo de 2 portátiles)
- # Impresoras reparadas (1 impresora vale lo de 2 portátiles)
87
10. Desde este momento se repiten los pasos desde el punto 5
11. En caso que se desee medir el indicador Garantías de servicios se debe
validar los siguientes datos
- # de garantías al mes por técnico (meta 3% máximo durante el mes)
- Motivo de la falla
12. Desde este momento se repiten los pasos desde el punto 5
6. Proceso para divulgación de TIPS Figura 26: Proceso para divulgación de TIPS
Buy SmartDraw!- purchased copies print this
document without a watermark .
Visit www.smartdraw.com or call 1-800-768-3729.
88
Descripción de proceso
1. Cuando el fabricante detecta una falla no conocida envía la información para
que sea divulgada.
2. Se recibe la información y se ingresa a un repositorio, pero esta información no
queda registrada en ningún sistema pues todo se maneja por correo.
3. El director técnico realiza una reunión con todos los técnicos para divulgar la
información enviada por el fabricante.
4. Se valida que todos los técnicos queden informados sobre el nuevo proceso y
en caso de no ser así se repite el paso 3 hasta que la falla sea divulgada a
todo el personal técnico.
3.3 Análisis Documental
Aquí se incluyen los documentos proporcionados por Punto de servicio.
Aunque la empresa carece de una buena documentación de todos sus procesos, y
no tiene graficas de proceso o jerarquías cuenta con una documentación básica
de los procesos que consideran más importantes indicando unas salidas y
entradas de cada proceso, a su vez que se identifican los agentes que participan e
intervienen en dichos procesos.
Uno de los principales problemas encontrados en punto de servicio consiste en
que no se realiza una medición cuantitativa de sus gestiones y procesos, la única
medición que se hace a la fecha de nuestro estudio consistía en encuestas de
satisfacción y cumplimiento a los usuarios como indicador de calidad y una
medición de casos cerrados antes de 10 días.
89
Figura 27: Proceso de administración.
Fuente: Documentación suministrada por la empresa punto de servicios
90
Figura 28: Proceso de mejora continua.
Fuente: Documentación suministrada por la empresa punto de servicios
91
Figura 29: Proceso comercial y de servicio al cliente.
Fuente: Documentación suministrada por la empresa punto de servicios
92
Figura 30: Proceso de servicio técnico.
Fuente: Documentación suministrada por la empresa punto de servicios
93
Figura 31: Proceso de gerencia.
Fuente: Documentación suministrada por la empresa punto de servicios
94
Figura 32: Proceso para el control del servicio no conforme.
Fuente: Documentación suministrada por la empresa punto de servicios
95
Figura 33: Proceso de calidad - Indicadores SGC
Fuente: Documentación suministrada por la empresa punto de servicios
96
Figura 34: Proceso de calidad – Análisis de datos 1
Fuente: Documentación suministrada por la empresa punto de servicios
97
Figura 35: Proceso de administración – Análisis de datos 2
Fuente: Documentación suministrada por la empresa punto de servicios
98
Figura 36: Procedimiento acciones correctivas y preventivas
Fuente: Documentación suministrada por la empresa punto de servicios
99
Figura 37: Proceso de administración – Análisis de datos
Fuente: Documentación suministrada por la empresa punto de servicios
100
3.4 Incidentes Problemáticos
Para verificar estado actual de la organización y su nivel de cumplimiento en sus
diferentes líneas de servicio, se realizó revisión en el sistema de información en el
cual se reportan los Incidentes de las áreas técnicas y administrativas. El sistema
basado en la plataforma File Maker MAC, no tiene desarrollado un módulo de
reportes que permita la consulta estadística de los incidentes cubiertos por las
diferentes líneas de servicio. Se muestran a continuación algunos incidentes
reportados por clientes o por los mismos funcionarios de Punto de servicios como
problemáticos o faltos de gestión.
Cas
o INC
Fecha
Apertura Fecha Cierre Marca Equipo
Observacio
nes Diagnóstico Cliente Proveedor
1 9815 15/06/2010 03/08/2010 Lenovo T43
El equipo
presenta demora hacer el
bypass de Bios al ingreso a
sistema operativo (4 minutos)
El equipo requiere cambio de Board, se realizan test de
rendimiento y no muestra falla, se prueba con otra board
y la falla no replica
Sanchobbdo Lenovo
2 9835 17/07/2010 02/08/2010 Lenovo T60 El equipo
no da video
El equipo requiere
cambio de display, el equipo presenta golpe en la pantalla, se
verifica con monitor externo y el equipo funciona
correctamente con video externo.
Sanchobbdo Lenovo
3 9915 17/07/2010 01/08/2010 Lenovo T43 El equipo
no enciende
El equipo require cambio de board, el
equipo presenta daño en el conector de AC del equipo, no existe la
posibilidad de reparar.
Sanchobbdo Lenovo
101
4 9922 18/07/2010 14/09/2010 Toshiba Satellit
e
El equipo no se
conecta por Wifi a internet
El equipo requiere cambio de Board, se verifica el equipo con
la red inhalambrica de Punto de Servicio no se conecta, se realiza
restauración de sistema operativo y la falla replica. - El
equipo nuevamente se verifica y se encuentra que el switch de la Wifi
presenta desconexión del board
Javier Ospina Toshiba
5 9984 22/07/2010 21/08/2010 HP LaserJet 3800
La
impresora de presidencia
reporta error 39.XXXX, la
impresora se encuentra
bloqueada
Se remite impresora a laboratorio de PDS, se realizan pruebas con el
equipo y no replica la falla, se instala equipo supletorio en el cliente.
- Se requiere cambio de board y tarjeta formatter de la
impresora. Se compraron las tarjetas fueron instaladas la
falla replicó aleatoriamente - La impresora continua en
operación en el laboratorio sin replicar la falla. - Realizando
consulta con el fabricante se establece que este error se
produce por corrupción de los datos enviados a la impresora. -
20/08/2010 el equipo regresa a Cliente sin cambiar las tarjetas.
Sanchobbdo HP
Análisis de los casos Caso 1 Teniendo la en cuenta la información recopilada en la herramienta y la información
proporcionada por el área técnica PDS, en este caso se diagnosticó el equipo, se
generó la orden de servicio a lenovo para la compra de este repuesto, el proceso
de cotización se demoró 4 días, el proceso de compra y envío tardo 24 días.
102
Durante este tiempo no se generó reporte informativo sobre el estado del caso al
cliente, lo que causó molestia e inconformidad así como el incumplimiento de los
acuerdos de servicio.
En consulta con el director técnico se confirmó que la demora en el trámite de este
repuesto responde a los tiempos de respuesta del proveedor Lenovo además de la
antigüedad del modelo del equipo. Se agrega que no existió seguimiento a este
caso por el área técnica por motivo del tráfico y la carga laboral de las diferentes
líneas de servicio del laboratorio de PDS. Analizando superficialmente la situación
se concluye que no existieron medidas contingentes para disminuir los tiempos de
respuesta frente al cliente. Por ejemplo la facilidad de tener un stock de este tipo
de repuesto, además de un nivel de acuerdo comercial con lenovo para tramitar
compras por demanda de diferentes repuestos, en este caso boards.
Dentro de las evidencias recopiladas, no se encuentra registro de comentarios o
gestiones realizadas en el sistema de información sobre esta incidencia. No existe
seguimiento de los caso.
Caso 2 Analizando la información presentada en la aplicación de los incidentes y la
información entregada por el Director Técnico de PDS, el caso 2 se presentó falla
de display por mal uso del equipo por parte del usuario, para este equipo por
equivocación del técnico encargado fue solicitado por garantía el repuesto con
falla, este proceso se debió gestionar por compra directa. En el momento de la
llegada del repuesto la Directora Comercial debió generar reporte a lenovo para
cambiar el trámite de Garantía por Compra, este proceso genero 24 días lo cual
género dificultades con el cliente además del sobrecosto de la operación del
trámite que no se pudieron facturar al cliente.
103
A nivel de los procesos técnico-comerciales, los niveles técnicos están
desinformados sobre las condiciones contractuales con los proveedores además
de los acuerdos de gestión de incidencias con los mismos. No existe un control de
cumplimiento sobre los proveedores en la cual se determinen las
responsabilidades comerciales y legales que relacionen a PDS con los
Proveedores.
Otro aspecto que representa una situación problemática, es la falta de
documentación de las incidencias en el sistema de información, así como los
proceso vinculados al proceso de apertura, gestión y cierre de la incidencia.
Caso 3
Para el caso 3, Se informa que el trámite fue acorde a los niveles de respuesta de
lenovo, se solicitó la board y el trámite demoro 24 días. Se puede analizar este
incidente de la misma manera que el caso 2, para este caso también no existió
contingencia a través de Stock en almacén. Según la información recopilada en el
laboratorio con el personal técnico de PDS, también en este caso surgió un
agravante, el equipo presento desperfectos físicos por daños causados por
técnico que recibió el servicio. El cliente reporto daño en las carcasas y teclado,
estos daños no se encontraban en el momento de enviar el equipo de las oficinas
del cliente al laboratorio de PDS. Inicialmente PDS generó reporte de condición
del cliente a Sanchobbdo en el cual se especificaba que los daños ya estaban
evidentes en el equipo en el momento de recepción del equipo.
Más adelante por comunicaciones internas en el laboratorio, se determinó que los
daños fueron efectivamente causados por el técnico que recibió el servicio.
Además dentro de los acuerdos de servicio con este cliente determinado se tiene
la instalación de un equipo supletorio o reemplazo de la máquina mientras se
104
encuentra el equipo propietario en reparación para mitigar el impacto en la
producción del cliente, para este ticket no se instaló equipo supletorio.
Esta situación generó más tiempo en la cotización, compra e instalación de las
partes dañadas. Como consecuencia se evidenció inconformidad con el servicio
de PDS y un incumplimiento con el acuerdo de servicio.
Un análisis preliminar de este escenario real, se concluye que no existe un
estándar de calidad en la prestación de los servicios de reparación, además del
incumplimiento de los procesos de los acuerdos de servicios. No se notificaron los
aspectos importantes de la gestión del trámite del caso al cliente en cuestión.
Además surge como falencia la no verificación del equipo en el proceso de
transporte del dispositivo del cliente al laboratorio de PDS.
No se documentó en el sistema de información el historial de incidentes,
modificaciones, aspectos importantes del trámite o el proceso. Con esto se limita
el seguimiento de la incidencia y cumplimiento de los acuerdos de servicio con el
cliente.
Caso 4
En este caso en el cual se reporta una falla de la conexión del Wifi, surge una
falencia en el proceso de diagnóstico nivel 1 y nivel 2 o exhaustivo donde se
evidencia la utilización inoperante de recursos. Una falla que debió solucionarse
en un tiempo de respuesta corto, paso varios filtros de gestión y revisión en los
cuales no se detectó esta falla de tipo simple.
De acuerdo con las diferentes entrevistas relacionadas con este incidente, se
define un problema de escalamiento de incidencias en cual no se determinó el
105
nivel de impacto de la falla al igual de la inoperancia del nivel 1 de soporte del
centro de servicios de PDS.
Los avances o la información del trámite de la incidencia no se documentaron en
el sistema de información de la compañía haciendo imposible un seguimiento que
permitirá controlar los tiempos de repuesta o el cumplimientos de los acuerdo de
servicio
Caso 5 Para el caso 5, según la documentación recopilada, surge la inoperancia del nivel
1 y nivel 2 de soporte en el cual la desinformación técnica sobre la incidencia en
cuestión, generó sobrecostos en la prestación de servicios además demoras en el
cumplimiento de los Acuerdos de servicio con el cliente.
Basados en la entrevistas recopiladas sobre este incidente, no se instaló el equipo
supletorio esto evidencio el incumplimiento de otro acuerdo de servicio con este
cliente especifico.
Se evidencia la preliminarmente la falta de una base de conocimientos de acuerdo
a manuales de fabricante o experiencia técnica sobre casos similares, el
escalamiento de la incidencia demostró un diagnóstico sin utilización de checklist
de servicio o troubleshoot.
Durante el trámite del servicio no se documentaron en el sistema de información
de PDS. La información sobre el proceso de trámite y tiempos de respuesta al
cliente no se informaron.
106
3.5 Referencia de la metodología implementada
3.5.1 Gestiones
Muchas empresas dependen de sus departamentos de tecnología para mantener
su negocio en funcionamiento, por esta razón los procesos eficaces y eficientes de
la Gestión de Servicios TI se convierten en esenciales para el éxito de toda la
organización., aun cuando los servicios de TI sean prestados por un ente externo.
En todos los casos, el servicio debe ser fiable, consistente, de alta calidad, de
coste aceptable y estar centrado en apoyar y mantener el negocio.
Por esta razón en ITIL se preocupa de todos los aspectos que garanticen la
continuidad, disponibilidad y calidad del servicio prestado al usuario, agrupando
estos aspectos en diferentes niveles de gestión:
3.5.1.1 Centro de servicios (Service Desk)
Figura 38: Proceso de soporte al servicio
107
Establecer un centro de servicios es la primera tarea que se debe ejecutar para
establecer una gestión de servicios de TI al interior de una PYME.
El Centro de Servicios será el primer punto de contacto y centro neurálgico entre
los usuarios y los diferentes niveles de los procesos de soporte de servicio.
Independientemente de la actividad de negocio de la organización es fundamental
establecer unos criterios que son básicos y de obligatoria aplicación para que la
funcionalidad del centro de servicio (SD) sea optima y cuantificable, lo cual nos
permitirá en un corto plazo ajustar los indicadores de medición y establecer unas
metas reales de cumplimiento para el SD
La implementación del Centro de Servicio debe incluir:
Punto y forma de contacto al usuario final:
Establecer el modelo que se usara para que los usuarios hagan el contacto y
reporte de incidentes al Centro de servicio depende directamente de los medio con
los que cuente la organización y de la urgencia con la que requiera que estos sean
atendidos.
Una alternativa económica es la de registro y atención de incidentes por un cliente
Web, pero esta alternativa es recomendada solo para la atención de incidentes
que no requieran de un tiempo de atención alto, es decir para casos no críticos o
con prioridad baja.
En caso de que se requieran soluciones más rápidas se aconseja la
implementación de un modelo telefónico, esta alternativa puede resultar más
costosa pero a largo plazo permitirá mejores tiempos de atención y una mejor
oportunidad de atención.
108
Se aconseja para una organización pequeña que pueda utilizar el modelo
telefónico, hacer la implementación también del modelo Web, dado que esto le
permitirá redirigir los incidentes de prioridades bajas al último modelo y enfocar
sus esfuerzos en los casos críticos de forma telefónica.
Para la implementación de un punto de atención existen varias alternativas, las
mas recomendadas para una pequeña o mediana empresa son :
Call Center: alto volumen de llamadas y redirigir a los usuarios, a otras
instancias de soporte (segundo o tercer nivel)
Mesa de ayuda (Help Desk): Su principal objetivo es ofrecer una primera
línea de soporte técnico que permita resolver en el menor tiempo las
interrupciones del servicio.
Registro de Incidentes
Uno de los pilares del Centro de servicio será el registro de todos los incidentes,
teniendo en cuenta el tema, problema, fecha de apertura y de solución, tiempo de
atención, solución implementada, usuario que resolvió, área afectada y datos del
contacto del usuario que radico el problema.
Esta información permitirá conocer tomar decisiones en cuanto a la administración
del centro de servicios, cuales son los temas críticos, si se cumplen las metras
establecidas o se requieren planes de acción para cumplirlas.
Establecer temas críticos de atención.
Las mediciones realizadas a partir del registro de incidentes, permiten el análisis
de los casos que son críticos para la organización, el tiempo, esfuerzo y costo que
se requieren para su atención, entre otros.
Tiempo medio de atención de incidentes por Analista del centro de servicio y
área según criticidad.
109
El seguimiento de los tiempos de atención para los diferentes incidentes, es
importante porque nos permite crear pautas de atención para evitar la congestión
en las líneas de atención y resolución d incidentes.
Aplicando soluciones temporales a errores conocidos en colaboración con
la Gestión de Problemas.
Es muy importante entender que el centro de servicios no soluciona en definitiva
los incidentes, solo se encarga de dar una solución inmediata, temporal y resolver
rápidamente las interrupciones del servicio para permitir que el negocio continué
con su operatividad y los clientes finales no se vean afectados.
Implementación La implementación requiere una meticulosa planificación. El objetivo NO es
implementar lo más rápidamente posible un Centro de Servicios sino que sus
objetivos se alineen con los procesos del negocio, manteniendo los sistemas con
un mínimo de interrupciones sin afectar a los clientes externos o internos, de esta
forma se optimiza la imagen externa de nuestra organización.
Cuando se está realizando el proceso de concepción y plantación del centro de
servicio, es necesario tener en cuenta cuáles son las necesidades, las funciones y
las responsabilidades del Centro de servicio.
Se debe tener en cuenta la infraestructura y las herramientas que serán
necesarias para su correcto funcionamiento (Hardware y software) teniendo en
cuenta el punto anterior para no incurrir en herramientas innecesarias o de un alto
costo.
Como último se debe considerar el perfil Humano de los analistas del centro de
Servicios, tanto en su formación profesional como humana.
110
Proveedores La implementación de un centro de servicio puede resultar sumamente costosa, si
no se enfoca adecuadamente, en algunos casos es mejor considerar en dejar a
proveedores externos el soporte de algunas elementos, estableciendo acuerdos
de servicio que nos permitan continuar con nuestra funcionalidad, por ejemplo, el
soporte técnico del hardware para computadores personales, se le puede dar a un
proveedor externo que solo cobre por servicios presentados, estos permite ahorrar
gastos por nomina y contratación.
Estructura
El Centro de servicio es el primer punto de contado entre los usuario y los niveles
de gestión de TI, por esta razón debe cumplir algunas condiciones de estructura:
Debe ser fácilmente accesible.
Debe Ofrecer un servicio de calidad consistente.
Contar con un personal adecuadamente capacitado, tanto para interactuar
remotamente con un usuario que no posea ningún conocimiento técnico,
como para saber cuándo se debe realizar un escalamiento a un segundo
nivel y asignar adecuadamente las prioridades a los casos para que se
cumplan entre las SLAs establecidas.
Contar con unas bases de conocimiento que le permita agilizar su tiempo
de atención.
Actividades y Funcionalidades
El Centro de Servicio debe ofrecer una primera línea de soporte para la solución
de todas las interrupciones de servicio.
Entre sus tareas y deberes se incluyen:
Registro y monitorización de cada incidente.
111
Comprobación de que el servicio de soporte requerido se incluye en el SLA
asociado.
Seguimiento del proceso de escalado.
Identificación de problemas.
Cierre del incidente y confirmación con el cliente.
El lanzamiento de nuevas versiones para la corrección de errores.
El cumplimiento de los SLAs.
Auto evaluarse y solicitar evaluación a sus usuarios después de la atención
de un servicio.
Compartir la filosofía de atención al cliente de la organización.
Comunicarse con corrección y buena educación y de una manera que el
cliente pueda comprender.
Comprender las necesidades de los clientes y redirigirlos, si fuera
necesario, a los expertos en cuestión.
Controlar todas las herramientas tecnológicas a su disposición para ofrecer
un servicio de calidad.
Ser capaz de trabajar en equipo.
Un seguimiento de cerca de los servicios prestados y su eficacia y
rendimiento.
El trabajo en equipo.
Control del proceso La mejor medida del éxito de un Centro de Servicios es la satisfacción del
cliente, aunque ésta, obviamente, no sea responsabilidad exclusiva de éste.
Es importante que se intenten establecer métricas bien definidas para medir el
rendimiento del Centro de Servicios y la apreciación que los usuarios tienen de
éste.
En los informes de control se deben considerar aspectos tales como:
112
Tiempo medio de respuesta a solicitudes cursadas por correo electrónico y
teléfono o fax.
Porcentaje de incidentes que se cierran en primera línea de soporte.
Porcentaje de consultas respondidas en primera instancia.
Análisis estadísticos de los tiempos de resolución de incidentes
organizados según su urgencia e impacto.
Cumplimiento de los SLAs.
Número de llamadas gestionadas por cada miembro del personal del
Centro de servicio
113
3.5.1.2 Gestión de incidentes
Figura 39: Proceso para la gestión de incidentes
Las organizaciones dependen cada vez más de las Tecnologías de la Información
para alcanzar sus objetivos, de igual forma sucede en una PYME. La misión del
departamento de TI es ofrecer servicios fiables, de alta calidad y a un coste
aceptable, por lo que debe incorporar de manera sistemática las mejores prácticas
del mercado para la optimización continua de sus procesos.
Todos los departamentos de TI atienden fallos en hardware o software, y otras
peticiones de servicio como altas de empleados, peticiones de información,
cambios de clave. Si esta labor de apoyo diario no se sistematiza se depende
mucho de la capacidad de cada técnico y no se reutiliza todo el conocimiento
empleado en resolver incidencias pasadas.
114
Un incidente o incidencia es definido como “Cualquier evento adverso real o
sospechoso en relación a los sistemas informáticos o redes computacionales que
afecte el buen funcionamiento y reduzca la calidad de los mismos”
El Objetivo de la Gestión de Incidentes es restablecer el funcionamiento normal
del servicio lo más rápidamente posible, y con el menor impacto sobre la actividad
del negocio
Principalmente la Gestión de Incidentes se encarga de
Detectar cualquiera alteración en los sistemas
Registrar y clasificar estas alteraciones.
Asignar el personal encargado de restaurar el servicio cumpliendo con los
tiempos establecidos para efectuar dicha solución (SLA).
Para realizar el proceso con éxito, el centro de servicios (Help Desk) se juega un
papel muy importante en este proceso ya que son ellos los encargados de
gestionar el inconveniente reportado.
Hay diferencias entre la Gestión de Incidentes y la Gestión de Problemas y es muy
importante que no lleguen a confundirse, aunque exista una relación muy estrecha
entre ellas. La gestión de problemas no está enfocada a analizar ni encontrar las
causas de un incidente pero si debe asegurarse de restaurar el servicio
Es importante tener en cuenta cualquier cambio o modificación de la
infraestructura requiere una Petición de Cambio y estas no son efectuadas por la
Gestión de Incidentes, por tal motivo debe ser tratada según lo determine la
Gestión de Cambios.
115
Los beneficios de una gestión eficaz de incidencias son:
Reducción del impacto de las incidencias sobre la empresa
Uso más eficiente de los recursos de personal.
Cumplimiento de los niveles de servicio acordados.
Usuarios más satisfechos.
Mayor visibilidad del trabajo realizado.
Es muy importante seguir todas las instrucciones de la Gestión de Incidentes, ya
que de lo contrario se presentarían efectos negativos que afectarían enormemente
el funcionamiento del servicio. Algunos casos donde no surge un buen efecto la
Gestión de Incidentes se presentan cuando
No se siguen los procedimientos previstos y se resuelven las incidencias sin
registrarlas o se escalan innecesariamente y/o omitiendo los protocolos
preestablecidos.
No existe un margen operativo que permita gestionar los “picos” de
incidencias por lo que éstas no se registran adecuadamente e impiden la
correcta operación de los protocolos de clasificación y escalado.
No están bien definidos los niveles de calidad de servicio ni los productos
soportados. Lo que puede provocar que se procesen peticiones que no se
incluían en los servicios previamente acordados con el cliente.
Proceso para la Gestión de Incidencias Inicialmente el usuario debe reportar la incidencia y esta será registrada en el
sistema empleado por la PYME para llevar el control de las mismas, el sistema
guardara información como: quién informa del problema, síntomas, equipo
involucrado, etc.
116
Las incidencias pueden ser reportadas por diferentes fuentes tales como usuarios
comunes, gestores de aplicaciones o el soporte técnico, entre otros.
Es importante realizar el registro de la incidencia inmediatamente se reporte
porque se corre el riesgo de que la aparición de nuevas incidencias demore
indefinidamente el proceso.
Se debe tener mucho cuidado al momento de registrar un inconveniente debió a
que varios usuarios reportan la mismo caso por tal motivo se debe comprobar que
el incidente no ha sido notificado anteriormente y se encuentre en estado abierto,
lo anterior con el fin de evitar duplicidad en los registros.
El registro de la incidencia se hará del siguiente modo:
Asignación de ticket: al incidente se le asignará ticket que identificará el
reporte generado y con el cual el usuario podrá hacer seguimiento a la
incidencia generada.
Registro: se han llenara la base de datos con la información básica
necesaria para el procesamiento del incidente (hora, descripción del
incidente, sistemas afectados...).
Información de apoyo: se incluirá cualquier información relevante para la
resolución del incidente que puede ser solicitada al cliente.
Notificación del incidente: en los casos en que el incidente pueda afectar
a otros usuarios estos deben ser informados para que conozcan como
esta incidencia puede afectar su flujo habitual de trabajo
Clasificación o prioridad del caso.
La clasificación de la incidencia consiste en darle un nivel de prioridad para la
solución de la misma; esto se hace con el fin de identificar cual se debe
117
gestionar con mayor prontitud cuando existan múltiples reportes abiertos.
Dicha clasificación está basada en los siguientes parámetros:
Impacto: Depende de la afectación del proceso, como afecta el negocio y
número de personas afectadas, lo cual determina la importancia del incidente.
Urgencia: depende del tiempo máximo de demora que acepte el cliente para
la resolución del incidente.
Es importante tener en cuenta que hay factores que influyen al momento de
tomar la decisión y saber que incidencias podemos tramitar primero. Por
ejemplo debemos saber que un Incidente fácil de solucionar se debe gestionar
en el menor tiempo posible.
La prioridad del incidente puede cambiar durante su ciclo de vida. Por ejemplo,
se pueden encontrar soluciones temporales que restauren aceptablemente los
niveles de servicio y que permitan retrasar el cierre del incidente sin graves
repercusiones.
Cuando ya se ha asignado la prioridad el incidente, se debe asociar un estado
al mismo (por ejemplo: registrado, activo, suspendido, resuelto, cerrado) y se
estima el tiempo de resolución del incidente.
Escalamiento a otro nivel
El proceso de escalamiento se presenta cuando una incidencia es asignada a
grupo de soporte (Help Desk) o al técnico encargado de la red en la empresa pero
este no puede resolver en primera instancia el inconveniente y es necesario
recurrir a alguna persona de jerarquía superior que pueda tomar decisiones que
no están bajo la responsabilidad del técnico.
El área o técnico al que se asigno el caso, debe investigar la causa de la
incidencia y compararla con otras incidencias anteriores para confirmar si ya se
había presentado y de ser así efectuar el proceso de solución correspondiente,
esto ayuda a disminuir gastos de tiempo y recursos. De lo contrario debe validar
cual sería la solución más optima para dicha incidencia.
118
Documentar la solución en el sistema usado por la empresa anexando ficheros
con información relacionada, éste con el fin de que al momento que se presente
nuevamente una incidencia como esta o parecida, sepan cual debe ser el
procedimiento a seguir. Es probable que en durante el transcurso de la solución
determinen que se debe hacer alguna modificación en la infraestructura, en tal
caso se debe solicitar a la Gestión de Cambios que se efectué dicho cambio.
Cierre Finalmente se debe cerrar la incidencia en el sistema y comunicar
automáticamente al usuario el estado de su solicitud a través del e-mail y/o portal
de soporte.
El control del proceso juega un papel fundamental en la Gestión de Incidentes.
Después de haber efectuado el cierre del caso, es de suma importancia elaborar
informes, que ayuden a conocer qué está sucediendo y a mejorar el proceso.
Estos informes deben aportar información esencial para, por ejemplo:
La Gestión de Niveles de Servicio: Los clientes deben estar informados
acerca de los tiempos estimados de solución de incidentes SLAs y adopten
medidas correctivas en caso de incumplir dichos tiempos.
Monitorizar el rendimiento del Centro de Servicios: conocer el grado de
satisfacción del cliente por el servicio prestado y supervisar el correcto
funcionamiento de soporte y atención al cliente.
Identificar errores.
Disponer de Información Estadística: que puede ser utilizada para hacer
proyecciones futuras sobre asignación de recursos, costes asociados al
servicio, etc.
En un buen seguimiento de todo el proceso es indispensable la utilización de
métricas que permitan evaluar de la forma más objetiva posible el funcionamiento
del servicio. Algunos de los aspectos clave a considerar son:
119
Número de incidentes clasificados temporalmente y por prioridades.
Tiempos de solución clasificados en función del impacto y la urgencia de los
incidentes.
Costes asociados.
Uso de los recursos disponibles en el Centro de Servicios.
Porcentaje de incidentes, clasificados por prioridades, resueltos en primera
instancia por el Centro de Servicios.
Grado de satisfacción del cliente.
120
3.5.1.3 Gestión de problemas Figura 40: Proceso para la gestión de problemas
La gestión de problemas tiene como objeto indagar todas las causas a cualquier
alteración ya sea subyacente, real o potencial del servicio de TI, y así mismo debe
definir las soluciones que den a lugar.
Se debe tener claro que los problemas pueden ser de tipo reactivo o proactivo.
En la gestión de incidentes se explica que dicha gestión es la encargada de
restablecer con la mayor rapidez la calidad del servicio, por otra parte en la gestión
de problemas se determina cuando un incidente es de tipo recurrente o si es de
gran impacto para la infraestructura de TI, se debe determinar las causas y
posibles soluciones.
121
Inicialmente se debe definir que es un problema y cuando es un error conocido.
Proceso
Las siguientes actividades son citadas según material suministrado por el Docente
Miguel Ángel Vargas de la Unipanamericana, las cuales son las principales según
de la gestión de problemas:
Control de Problemas: se encarga de registrar y clasificar los problemas
para determinar sus causas y convertirlos en errores conocidos.
Control de Errores: registra los errores conocidos y propone soluciones a
los mismos mediante RFCs que son enviadas a la Gestión de Cambios.
De la misma manera se debe realizar la Post Implementación de los mismos, y
cuando par la estructura de la organización sea viable, desarrollar una Gestión de
Problemas Proactiva para detectar los problemas con antelación para prevenir un
deterioro en la calidad del servicio.
Proceso - Control de Problemas
El control de problemas debe tener por objeto conseguir que todo problema se
convierta en un error conocido para que dicho control pueda proponer las
soluciones correspondientes.
El control de problemas se compone por tres factores principales.
1. Identificación y Registro
En la gestión de problemas, todas las áreas de la infraestructura de TI para
identificar problemas cuales son los problemas reales y potenciales.
El registro de problemas es similar al de los incidentes aunque el énfasis debe
hacerse en su naturaleza y posible impacto.
122
Las principales fuentes de información utilizadas se mostraran a continuación las
cuales son citadas según material suministrado por el Docente Miguel Ángel
Vargas de la Unipanamericana:
• La base de datos de Incidentes
• Análisis de la infraestructura TI
• Deterioro de os Niveles de Servicio
2. Clasificación y Asignación de Recursos
Determinar la prioridad del problema, como de su impacto (grado de
detrimento de la calidad del servicio).
3. Análisis y Diagnóstico: Error conocido
Los objetivos principales del proceso de análisis son:
Determinar las causas del problema.
Proporcionar soluciones temporales a la Gestión de Incidentes para
minimizar el impacto del problema hasta que se implemente los cambios
necesarios que lo resuelvan definitivamente.
Es importante tener en cuenta que no necesariamente el origen del problema es
un error de hardware o software; es normal que el problema este causado por
casos como:
• Errores de procedimiento.
• Documentación incorrecta.
• Falta de coordinación entre diferentes áreas.
123
Es muy probable que la causa del problema también sea un "bug" de alguna de
las aplicaciones. Por lo que es conveniente crear un contacto directo con el
entorno de desarrollo, cuando las aplicaciones son desarrolladas "en la casa”.
Una vez establecidas las causas del problema, se convierte en un Error Conocido
y se dirige al Control de Errores para su posterior procesamiento.
Proceso - Control de Errores
En el control de errores se debe llevar el registro como un error conocido una vez
que se haya determinado la causa del error en el control de problemas.
Identificación y Registro de errores
El registro de errores conocidos es de suma importancia para la Gestión de
Incidentes pues consigo debe tener relacionado alguna solución temporal
permitiendo minimizar el impacto de los incidentes asociados.
Análisis y Solución.
Para cada error evaluado, se debe investigar y tener diferentes soluciones, a
continuación se mostraran los ejemplos citados según material suministrado por
el Docente Miguel Ángel Vargas de la Unipanamericana:
El posible impacto de las mismas en la infraestructura TI.
Los costes asociados.
Sus consecuencias sobre los SLAs.
Algunas veces, cuando el impacto del problema presente graves consecuencias
en la calidad del servicio, se puede emitir una RFC de emergencia para procesar
con urgencia la Gestión de Cambios.
124
Al presentar la solución más óptima del problema, y antes de solicitar una RFC a
la Gestión de Cambios, se debe tener en cuenta alguna de las siguientes
consideraciones y preguntas:
¿Es conveniente demorar la solución?
¿Es la solución temporal aportada suficiente para mantener unos niveles de
calidad de servicios aceptable?
¿Los beneficios justifican los costes asociados?
Revisión Post Implementación y Cierre
Para cambiar el estado de un problema a cerrado, se debe analizar el resultado
arrojado por la implementación de la RFC solicitado a la Gestión de Cambios
(PIR).
Los problemas e incidentes relacionados se pueden dar como cerrados cuando los
resultados de la gestión de cambios son los esperados, y se debe emitir el informe
correspondiente.
Control del Proceso
El gran objetivo de la gestión de problemas es mejorar continuamente el
funcionamiento de la infraestructura TI, es necesario efectuar constantemente un
seguimiento a los procesos relacionados para evaluar su eficacia y rendimiento.
Para evaluar el rendimiento de la gestión de problemas, es imprescindible la
elaboración de informes detallados con el fin de aportar información necesaria e
importante a las diferentes áreas de la infraestructura TI.
Los informes de mayor envergadura y relevancia que debemos tener en cuenta
de la Gestión de Problemas son nombrados a continuación y se citaran según
material suministrado por el Docente Miguel Ángel Vargas de la Unipanamericana
125
Informes de Gestión Proactiva
Informes de Calidad de Productos y Servicios
Por último recordar que para llevar a cabo una excelente gestión de problemas se
necesita determinar para cada proceso un responsable; no obstante, se
recomienda que en pequeñas organizaciones para evitar el incremento de los
costos generados, no dividir en exceso las responsabilidades de los procesos,
pues esto sería contraproducente al asignar recursos desproporcionadamente
para el proceso de identificación y solución de problemas.
126
3.5.1.4 Gestión de configuraciones
Figura 41: Proceso para la gestión de configuraciones
En general las funciones de la Gestión de Configuraciones es controlar todos
los elementos de configuración de la infraestructura TI detalladamente y gestionar
ésta información a través de la Base de Datos de Configuración (CMDB).
127
También es importante poder proporcionar información exacta de la configuración
de TI para todos los procesos de la gestión; para ello se debe lograr interactuar
con las Gestiones de Incidentes, Problemas, Cambios y Versiones de tal
manera que se pueda solucionar más eficazmente las incidencias presentadas y
encontrar con agilidad la causa de dichos problemas y así realizar los cambios que
se den a lugar para su solución y actualizar en todo instante CMDB;
adicionalmente se debe tener monitorizado constante y periódicamente la
configuración de los sistemas en producción y contrastarla con la almacenada en
la CMDB.
Es claro que no todo se puede gestionar dado que es imposible solucionar lo que
se desconoce, sin embargo es primordial conocer minuciosamente la
infraestructura TI de la organización para obtener el mayor provecho de la misma.
La principal tarea de la Gestión de Configuraciones es tener un registro
actualizado de los elementos de configuración de la infraestructura TI junto con
sus interrelaciones.
La correcta aplicación de la gestión de Configuraciones se refleja en beneficios
como:
Resolución más rápida de los problemas
Una Gestión de Cambios más eficiente.
Reducción de costos.
Control de licencias.
Mayores niveles de seguridad.
Mayor rapidez en la restauración del servicio.
Pero aun cuando la gestión de configuraciones es muy beneficiosa para la
organización, también se pueden presentar algunas dificultades, como por
ejemplo:
128
Una incorrecta planificación
Estructura inadecuada de la CMDB
Herramientas inadecuadas
Falta de Coordinación con la Gestión de Cambios y Versiones
Falta de organización
Falta de compromiso
Definiciones:
Elementos de configuración (CI):
Dispositivos de hardware como PCs, impresoras, routers, monitores, etc.
Tarjetas de red, teclados, lectores de CDs, etc.
Documentación.
En resumen, todos los componentes que han de ser gestionados por la
Organización TI.
Base de Datos de la Gestión de Configuraciones (CMDB): esta base de datos
debe incluir:
Información detallada de cada elemento de configuración.
Interrelaciones entre los diferentes elementos de configuración.
Se debe tener presente que la CMDB no es simplemente la enumeración de los
elementos existentes en TI, es más bien un enfoque y conocimiento global de la
infraestructura de TI de toda la Organización.
Proceso:
La gestión de configuraciones debe tener principalmente las siguientes
actividades:
129
Planificación
Clasificación y Registro
Monitorización y Control
Realización de auditorías
Elaboración de informes
Planificación:
Para la metodología ITIl, uno de sus principales pilares para su correcta
implementación es la gestión de configuraciones dada la importancia e inter-
relatividad que presenta con las demás gestiones y procesos, por ello es tan
importante tener un plan muy bien detallado para llevar a cabo la implementación
de la gestión de configuraciones, y para ello e s necesario considerar los
siguientes ítem para elaborar una buena planificación:
Designar un responsable
Invertir en alguna herramienta de software.
Realizar un cuidadoso análisis de los recursos ya existentes
Establecer el alcance y objetivos.
Establecer el nivel de detalle o el proceso de implementación.
Coordinar el proceso estrechamente con la Gestión de Cambios, Gestión de
Versiones y los Departamentos de Compras y Suministros.
Clasificación y registro
La principal tarea de la Gestión de Configuraciones es mantener la CMDB. Es
imprescindible, para llevar esta labor con éxito, predeterminar la estructura del
CMDB de manera que:
Los objetivos sean realistas
La información sea suficiente
130
Alcance
En primera instancia se debe determinar los sistemas y componentes que se
incluirán dentro de la CMDB, por lo que es recomendable incluir los sistemas de
hardware y software involucrados en los servicios críticos.
También se debe definir de acuerdo al ciclo de vida que estos presenten, que CIs
van a incluirse; otro ítem importante a tener en cuenta es toda la documentación
asociada a los proyectos, SLA y licencias.
Nivel de detalle y profundidad
Es indispensable determinar la profundidad y nivel de detalle una vez se haya
establecido el alcance que tendrá la CMDB; para ello es necesario:
Determinar los atributos que describen a un determinado CI.
Tipo de relaciones lógicas y físicas registradas entre los diferentes CIs.
Subcomponentes registrados independientemente.
Nomenclatura
La nomenclatura en la gestión de configuraciones es muy importante ya que es
aquí en donde se definen códigos de clasificación de todos los CIs, haciendo así
funcional al sistema teniendo en cuenta los siguientes aspectos:
Cada identificación debe ser única y de fácil interpretación por el usuario.
Debe estar etiquetado y estar utilizado en todas las comunicaciones en
relación a cada CI.
Estos códigos se deben emplear también para el software y la
documentación.
131
Monitorización
Se debe conocer ampliamente el estado de cada componente sin importar en que
momento del ciclo de vida se encuentre ya que esta información puede ser de
mucha ayuda para el análisis y el uso de herramientas de software.
Control
Es necesario estar informado de de cada cambio y adquisición de cualquier tipo de
componente para lograr mantener actualizada la CMDB.
Cuando se trata de hardware, su registro debe iniciar desde el mismo momento de
su aprobación de compra, y actualizar constantemente su estado sin importar en
qué momento del ciclo de vida se encuentre.
El software de la misma manera se debe registrar aun cuando esté en producción.
Las tareas de control deben centrarse en:
Asegurar que todos los componentes están registrados en la CMDB.
Monitorizar el estado de todos los componentes.
Actualizar las interrelaciones entre los CIs.
Informar sobre el estado de las licencias.
Auditorias
El principal objetivo de las auditorias es comparar, verificar y asegurar que toda la
información plasmada en la CMDB es igual a la estructura de TI de toda la
organización.
Existen herramientas que permiten una gestión remota, centralizada y automática
de los elementos de configuración de hardware y software.
La información recopilada puede ser utilizada para actualizar la CMDB.
132
3.5.1.5 Gestión de Cambios
Figura 42: Proceso para la gestión de Cambios
El principal objetivo de la Gestión de Cambios es la evaluación y planificación del
proceso de cambio con el fin de asegurar que, si éste no se está llevando bien, se
logre hacer de la manera más eficiente, alcanzando los procesos ya establecidos y
asegurando en todo momento la calidad y continuidad del servicio TI.
Las razones para la realizar el cambio en la infraestructura TI son:
Solución de errores conocidos.
Desarrollo de nuevos servicios.
Mejora de los servicios existentes.
Imperativo legal.
La Gestión de Cambios debe asegurar que los cambios:
Estén justificados.
133
Se lleven a cabo sin menoscabar la calidad del servicio TI.
Estén debidamente registrados, clasificados y documentados.
Hayan sido minuciosamente testeados en ambiente de pruebas.
Se vean reflejados en la CMDB (Base de datos de la gestión de la
Configuración).
Puedan deshacerse mediante planes de "retirada del cambio" (back-outs)
para los casos en que después de haberlos implementado, estos presenten
un incorrecto funcionamiento.
Una gestión de cambios bien realizada genera beneficios a la organización tales
como:
Reducción del número de incidentes y problemas potencialmente asociados
a todo cambio.
Se puede retornar a configuraciones estables de manera sencilla y rápida
en caso de que el cambio tenga un impacto negativo en la estructura TI.
Gran reducción de "back-outs" necesarios.
Se evalúan los costos asociados al cambio y por lo que es más sencillo
valorar el retorno real a la inversión.
La CMDB está actualizada, algo necesario para la correcta gestión del resto
de procesos TI.
Se desarrollan procedimientos de cambio estándar que permiten la rápida
actualización de sistemas no críticos.
Debe existir una estrecha relación entre la GESTION DE CAMBIOS y los procesos
de TI para:
Asegurar que los cambios satisfagan las necesidades del servicio de TI
Preservar la calidad del servicio durante el proceso de cambio
Preservar la integridad de las bases de datos asociadas.
134
Todo proceso de cambio dentro de la GESTION DE CAMBIOS debe presentar
una monitorización con el fin de asegurar que la CMDB se mantenga actualizada,
también se deben desarrollar y emitir informes de rendimiento, finalmente se debe
monitorear elaborando métricas que permitan evaluar cada cambio.
Para poder conceptualizar y entender de una manera práctica, se debe tener en
cuenta ciertos conceptos básicos para describir y diferenciar sus respectivas
atribuciones.
En primera instancia, se debe tener completa claridad sobre los conceptos de
GESTOR DE CAMBIOS y CONSEJO ASESOR DE CAMBIOS (CAB).
El Gestor De Cambios es la persona encargada y responsable de todo el proceso
de cambio, motivo por el cual debe ser el último responsable de todas las tareas
asignadas a la Gestion De Cambios, este puede llegar a disponer de asesores
especializados en cada una de las diferentes áreas.
Por otra parte el Consejo Asesor De Cambios (CAB), es un grupo u órgano
interno de la organización el cual debe estar presidido o liderado por El GESTOR
DE CAMBIOS, en donde sus integrantes generalmente son los representantes de
las principales áreas de la gestión de servicios de TI; sin embargo este consejo
puede ser compuesto también por agentes externos, tales como:
Consultores externos
Representantes de los colectivos de usuarios
Representantes de los principales proveedores de software y hardware
Alcance de la gestión de cambios
En primera instancia, se debe tener claro que no todos los cambios son oportunos
ni eficientes, adicionalmente se deben establecer cuáles son los cambios
estandarizados y cuáles no, aunque en muchas ocasiones se puede tornar
impracticable los no estandarizados.
135
Para generar un cambio que no se encuentre estandarizado es necesario llevar un
control de las mismas, por lo que se recomienda llevar registros o formatos RFC
(Petición de Cambios), en donde los objetivos de cada petición deberá
comprender los siguientes ítem.
Corrección de errores
Innovación y mejora de los servicios
Cumplimiento de nuevas normas legales.
Se debe tener en cuenta que el alcance de la gestión de cambios debe
desarrollarse paralelamente con la gestión de de configuraciones ya que todos
estos cambios de CIs (Elementos de configuración) que están inventariados
dentro de la CMDB deberán estar correctamente supervisadas y registradas.
Pasos para generar una correcta gestión de cambios
Figura 43: Pasos para generar una correcta gestión de cambios
136
Proceso
Dentro del proceso de la gestión de cambio se debe:
Monitorizar y dirigir todo el proceso de cambio.
Registrar, evaluar y aceptar o rechazar las RFCs recibidas.
Convocar reuniones del CAB, excepto en el caso de cambios menores,
para la aprobación de las RFCs y la elaboración del FSC.
Coordinar el desarrollo e implementación del cambio.
Evaluar los resultados del cambio y proceder a su cierre en caso de éxito.
Registro
En primera instancia se debe registrar adecuadamente las RFC‟s, teniendo en
cuenta que su origen pueden ser de distinta índole.
Gestión de Problemas: Propone soluciones a errores conocidos.
Nuevos Servicios: Se debe coordinar todo el proceso con las Gestiones de
Capacidad, Disponibilidad y Niveles de Servicio para asegurar que estos
cambios no deterioran la calidad de los otros servicios prestados.
Estrategia empresarial: La dirección puede decidir una redirección
estratégica que puede afectar.
Actualizaciones de software de terceros: los proveedores pueden dejar
de soportar versiones anteriores de paquetes de software o introducir
nuevas versiones con grandes mejoras que recomienden la actualización.
Imperativo legal: Cambio de legislación (como, por ejemplo, la LOPD)
puede exigir cambios en la infraestructura TI.
Aceptación y clasificación
Aceptación
Después de elaborar el registro del RFC se debe evaluar con antelación su
pertinencia. Una RFC (Petición de Cambio) puede ser rechazada si se considera
que dicho cambio no se justifica o se puede solicitar su modificación si se
137
considera que algunos aspectos de la misma son susceptibles de mejora o mejor
definición.
Todos los casos la RFC debe ser devuelta al departamento o persona que la
solicito con el objetivo de que se puedan realizar las defensas a favor de dicha
RFC o para que pueda ser modificada.
El hecho que se acepte el cambio, no determina su posterior aprobación por el
CAB.
Clasificación
A cada RFC se le debe establecer una categoría y prioridad según la urgencia o
impacto que esta tenga.
La prioridad se establece según la importancia que presente la RFC y es relativa
con respecto a las RFCs que se encuentran pendientes, lo cual será el dato
relevante y de importancia para establecer el calendario de cambios que se
llevaran a cabo.
La categoría se determina de acuerdo al impacto de la RFC siendo este el
parámetro que determinara la asignación de recursos necesarios, los plazos
previstos y el nivel de autorización requerido para la implementación del cambio.
La clasificación se divide en cuatro niveles de prioridad así:
Baja
Normal
Alta
Urgente
138
Aprobación y planificación
En todo ejercicio, independientemente de su tipo de actividad es conveniente
realizar una planificación; por lo que la gestión de Cambio no está exenta para
llegar a una excelente gestión.
Se sabe que los sistemas de gestión de la información son muy susceptibles a los
cambios de configuración por las sofisticadas interrelaciones entre todos los CIs
involucrados. Un cambio aparentemente menor puede desencadenar una reacción
en cadena con resultados catastróficos. Es imprescindible, como mínimo, disponer
siempre de planes de "back out" que permitan la recuperación de la última
configuración estable antes del cambio. Pero esto obviamente no es suficiente.
En primer lugar el CAB debe reunirse periódicamente para analizar y
eventualmente aprobar los RFCs pendientes y elaborar el FSC o calendario del
cambio correspondiente.
Para su aprobación el cambio se debe evaluar minuciosamente:
¿Cuáles son los beneficios esperados del cambio propuesto?
¿Justifican esos beneficios los costes asociados al proceso de cambio?
¿Cuáles son los riesgos asociados?
¿Disponemos de los recursos necesarios para llevar a cabo el cambio con
garantías de éxito?
¿Puede demorarse el cambio?
¿Cuál será el impacto general sobre la infraestructura y la calidad de los
servicios TI?
¿Puede el cambio afectar los niveles establecidos de seguridad TI?
En el caso de cambios que tengan un alto impacto debe también consultarse a la
dirección pues pueden entrar en consideración aspectos de carácter estratégico y
de política general de la organización.
Una vez aprobado el cambio (en caso contrario se seguiría el proceso ya descrito
para el caso de no aceptación) debe evaluarse si este ha de ser implementado
139
aisladamente o dentro de un "paquete de cambios" que formalmente equivaldrían
a un solo cambio. Esto tiene algunas ventajas:
Se optimizan los recursos necesarios.
Se evitan posibles incompatibilidades entre diferentes cambios.
Sólo se necesita un plan de back-out.
Se simplifica el proceso de actualización de la CMDB y la revisión post-
implementación.
Implementación
Desde un principio, se debe tener en claro que la gestión de cambios no es la
encargada de implementar dichos cambios, ya que es la gestión de
configuraciones quien se encarga se realizar esta actividad, teniendo en cuenta y
recordando que es la gestión de cambios quien se encarga de supervisar y
coordinar todo el proceso.
En la fase de desarrollo del cambio se deberá monitorizar el proceso para
asegurar que:
Tanto el software desarrollado como el hardware adquirido se ajustan a las
especificaciones predeterminadas.
Se cumplen los calendarios previstos y la asignación de recursos es la
adecuada.
El entorno de pruebas es realista y simula adecuadamente el entorno de
producción.
Los planes de "back-out" permitirán la rápida recuperación de la última
configuración estable.
Para realizar una valoración preliminar, en lo posible debe permitirse el ingreso o
acceso restringido al entorno de pruebas a algunos usuarios a los nuevos
sistemas con el fin de verificar su funcionalidad, usabilidad y accesibilidad.
140
La opinión de los usuarios debe ser tomada en cuenta y la RFC debe ser revisada
en caso de que se encuentren objeciones justificadas al cambio (debe tenerse en
cuenta la resistencia habitual al cambio por parte de cierto tipo de usuarios).
Los clientes y proveedores no deben percibir el cambio como algo inesperado. Es
función tanto de la Gestión de Cambios como del Service Desk mantener
informados a los usuarios de los futuros cambios y, dentro de lo posible, hacerles
participes del mismo:
Escuchando sus sugerencias.
Comunicando las ventajas asociadas.
Aclarando sus dudas y dando soporte cuando ello sea necesario: la
percepción de mejora debe ser compartida por usuarios y clientes.
Evaluación
Se debe realizar una evaluación para poder determinar y valorar el verdadero
impacto en la calidad del servicio y beneficio que traerá a la organización, y así
poder llegar al cierre del cambio.
Los aspectos fundamentales a tener en cuenta son:
¿Se cumplieron los objetivos previstos?
En qué medida se aparto el proceso de las previsiones realizadas por la
Gestión de Cambios.
¿Provocó el cambio problemas o interrupciones del servicio imprevistas?
¿Cuál ha sido la percepción de los usuarios respecto al cambio?
¿Se pusieron en marcha los planes de "back-out" en alguna fase del
proceso?¿Por qué?
Si la evaluación final determina que el proceso y los resultados han sido
satisfactorios se procederá al cierre de la RFC y toda la información se incluirá en
la PIR (REVISION POST-IMPLEMENTACION) asociada.
141
Cambios de emergencia
Los cambios de emergencia son el resultado de las malas prácticas de
planificación pero que en algunas ocasiones estas son inevitables.
Cualquier interrupción del servicio de alto impacto, debe encontrar una respuesta
inmediata. Es importante que la solución al problema necesite un cambio y que
éste haya de realizarse siguiendo un procedimiento de urgencia.
Se debe prever el seguimiento a los casos de emergencia para establecer
protocolos de validación de los cambios urgentes que pueden requerir:
La reunión urgente del CAB y/o EC (COMITÉ DE EMERGENCIA) si esto
fuera posible.
Una decisión del Gestor del Cambio si es imposible demorar la resolución
del problema o éste sucede durante un fin de semana o periodo vacacional
(lo que puede dificultar la reunión del EC).
Es esencial que al cierre del cambio de emergencia se disponga de la misma
información de la que se dispone después de un cambio normal. Si esto no es así,
su resultado en situaciones de cambios futuros serán incompatibles,
configuraciones registradas incorrectas, etc. generando nuevas incidencias y
problemas.
Control del proceso
Es necesario elaborar informes que permitan evaluar el rendimiento de la Gestión
de Cambios.
Los informes deben ofrecer una información exacta y de sencilla evaluación; es
muy importante poder elaborar métricas de referencia que cubran aspectos tales
como:
RFCs solicitados.
Porcentaje de RFCs aceptados y aprobados.
142
Número de cambios realizados clasificados por impacto y prioridad y
filtrados temporalmente.
Tiempo medio del cambio dependiendo del impacto y la prioridad
Número de cambios de emergencia realizados.
Porcentaje de cambios exitosos en primera instancia, segunda instancia,
etc.
Numero de back-outs con una detallada explicación de los mismos.
Evaluaciones post-implementación.
Porcentajes de cambios cerrados sin incidencias ulteriores.
Incidencias asociadas a cambios realizados.
Número de reuniones del CAB con información estadística asociada:
número de asistentes, duración, nº de cambios aprobados por reunión, etc.
143
3.5.1.6 Gestión de Versiones
Figura 44: Proceso para la gestión de Versiones
Es necesario tener en cuenta que la gestión de Versiones debe estar inter-
relacionada con la gestión de cambio y de configuraciones asegurando así que la
CMDB estará siempre actualizada, permitiendo tener un amplio control de calidad
sobre el hardware y software existente en la organización y que se encuentre en
producción; así mismo, permite tener siempre actualizada la biblioteca de Software
Definitivo (DSL), y el Depósito de Hardware Definitivo (DHS).
La gestión de versiones debe ser la encargada de diseñar y construir las nuevas
versiones así como de hacer las pruebas y sobre todo supervisar la instalación de
los cambios realizados en el ambiente de producción.
144
La gestión de versiones, también es la encargada de establecer las políticas de
implementación para las nuevas versiones del software y hardware de la
organización; garantizando que en el proceso de cambio se cumpla con las
especificaciones de las RFCs.
Conceptos básicos
¿Qué es una versión?, es un grupo de CIs modificados y que fueron verificados
(testeados) para su puesta en producción, de acuerdo a las especificaciones
técnicas que fueron plasmadas en las RFCs.
Las versiones se pueden clasificar en:
Versiones mayores
Versiones menores
Versiones de emergencia
El ciclo de vida una versión puede encontrase en diversos estados:
Desarrollo.
Pruebas.
Producción.
Archivado.
El lanzamiento de las nuevas versiones es de la responsabilidad de la gestión de
cambios en donde se debe determinar cómo hacerlo y de la mejor forma:
Versión delta
Versión completa
Paquete de Versiones
145
Dsl
La Biblioteca de Software Definitivo (DSL), es la que contiene las copias del
software instalado en el entorno TI. Por ende se entiende por sistemas operativos,
controladores, aplicaciones y toda la documentación asociada.
La DSL debe presentar un completo histórico de versiones de cada software con
el fin de poder proporcionar la versión a ejecutar en el caso que se deba ejecutar
algún plan de back-out.
Es recomendable que la DSL se almacene en un entorno seguro y es conveniente
que se realicen back-up periódicos.
Dhs
El Depósito de Hardware Definitivo (DHS), en algunas organizaciones se les
conoce como almacén o bodega y es el que contiene las piezas de repuesto para
los CIs en el entorno de producción; teniendo en cuenta que todo estos deben
estar inventariados o registrados en la CMDB.
Proceso
La gestión de versiones debe establecer políticas de planificación y la
implementación de nuevas versiones, desarrollo o adquisición a terceros; también
debe ejecutar en un ambiente de pruebas las nuevas versiones para validar su
funcionalidad antes de ser puestas en marcha en ambiente producción; en dado
caso que éstas requieran ser retiradas se debe tener listo el plan de back-out.
Otro de los procesos y no de menor importancia es la actualización de la DSL, el
DHS y la CMDB; a su vez el de comunicar las nuevas funcionalidades o mejoras a
todos los clientes y usuarios y desplegar su respectiva capacitación.
146
Planificación
Es necesario generar un estándar para el lanzamiento de las nuevas versiones y
que enmarque una metodología de trabajo; más específicamente cuando se
trabaja sobre versiones menores y de emergencia lo que nos permite llevar un
mayor control sobre la liberación de cada versión.
Para el lanzamiento de las versiones mayores se debe desarrollar e implementar
planes más específicos en donde se tenga en cuenta las particularidades de cada
evento o caso.
En el caso que los desarrollos sean realizados por parte de terceros, la gestión de
versiones será la encargada de velar y asegurar que los paquetes de software o
hardware cumple con las especificaciones manifestadas en las RFCs,
adicionalmente es la responsable de de cualquier proceso de configuración.
Validación
Como se mencionó anteriormente, para garantizar el éxito del lanzamiento de la
nueva versión; es indispensable haber planificado con antelación un protocolo de
tests para llevar a cabo la liberación del producto al entorno de producción.
Es inapropiado limitarse a una validación de carácter técnico (ausencia de
errores), también se debe realizar pruebas reales con funcionarios o usuarios pues
son quienes finalmente validaran que los requisitos cumplen con todas las
exigencias de la nueva versión, teniendo en cuenta que en muchos casos siempre
existirá la resistencia al cambio y éstas deben ser consideradas.
No se debe olvidar bajo ninguna circunstancia incluir planes de back-out para
asegurar y garantizar que se podrá volver a la última versión estable de forma
rápida, ordenada y sin perdidas de información.
147
Se debe tener en cuenta que si después de realizar las respectivas validaciones y
las pruebas no son satisfactorias, no se recomienda ejecutar la instalación de
dicha versión hasta que se haya devuelto para una respectiva reevaluación.
Implementación
El rollout es también conocido como la distribución de la nueva versión, y el cual
dicho rollout puede ser de las siguientes maneras:
Completo y sincronizado que es la que se realiza simultáneamente.
Fragmentado que es la que se realiza parcialmente incrementando
progresivamente la funcionalidad ofrecida.
Se debe tener en cuenta y recordar que los rollouts deben estar perfectamente
documentados que para todos los involucrados en el cambio conozca
específicamente sus responsabilidades y deberes.
Finalmente los usuarios finales deben conocer con anterioridad sobre el calendario
del lanzamiento para que éstas no generen traumatismos en sus actividades
diarias.
Comunicación y formación
Por ninguna circunstancia se debe olvidar el factor humano cuando se habla de
temas técnicos, solamente cuando la relación usuario-aplicación representa un
eslabón débil de la cadena.
La (in)formación debe estructurarse en distintos niveles:
Es importante que los usuarios conozcan con anterioridad cuando se tiene
agendado el próximo lanzamiento y deben tener conocimiento de las
nuevas funcionalidades o errores que se pretenden resolver.
Para llevar a cabo las pruebas funcionales es recomendable asignar esta
tarea a un grupo especifico de usuarios finales, esto permite al final generar
148
algunas conclusiones en donde se documentarán y analizarán algunos de
los siguientes aspectos:
o La experiencia subjetiva del usuario.
o Todas las sugerencias acerca de la utilidad y funcionalidad
o Todas las dudas obtenidas durante la utilización del nuevo producto
o versión.
Dependiendo del avance o incremento de las mejoras de la versión, se
puede considerar oportuno implementar cursos remotos o presenciales
según sea la necesidad.
Siempre se debe desarrollar una página o sección de FAQs para que los
usuarios aclaren las dudas más comunes o habituales.
Control del proceso
Es necesario elaborar informes que permitan evaluar el rendimiento de la Gestión
de versiones.
Los informes deben ofrecer una información exacta y de sencilla evaluación; es
muy importante poder elaborar métricas de referencia que cubran aspectos tales
como:
Número de lanzamientos de nuevas versiones.
Número de back-outs y razones de los mismos.
Incidencias asociadas a nuevas versiones.
Cumplimientos de los plazos previstos para cada despliegue.
Asignación de recursos en cada caso.
Corrección y alcance de la CMDB y la DHS.
Existencia de versiones ilegales de software.
Adecuado registro de las nuevas versiones en la CMDB.
149
Incidencias provocadas por uso incorrecto (formación inadecuada) de la
nueva versión por parte de los usuarios.
Disponibilidad del servicio durante y tras el proceso de lanzamiento de la
nueva versión.
150
3.5.1.7 Gestión de Niveles de servicios Figura 45: Proceso para la gestión de niveles de servicio
Esta gestión es uno de los componentes en el área de prestación de servicios y
podría decirse que es el conjunto más importante de los proceso en el marco de
ITIL porque allí definimos los niveles de servicio requeridos y los más
convenientes para apoyar los proceso del negocio. Los Acuerdos de Nivel de
servicio (SLAs) y Acuerdos de Nivel Operacional (OLAs) son desarrollados para
cumplir los niveles establecidos y los gastos asociados.
Los SLAs definen las condiciones, los parámetros y los límites dentro de los
cuales se debe prestar el servicio y sirven como referencia para medir el éxito en
los procesos y calidad en los servicios prestados por la empresa.
Se puede empezar a implementar siguiendo los siguientes pasos:
Afianzar la comprensión del cliente por los servicios TI.
151
Continuamente realizar informes que nos muestren resultados de la
implementación de la TI y poder realizar mejoras.
Las actividades a seguir para la implementación de la gestión de niveles de
servicio son:
La identificación de los requerimientos y necesidades reales del cliente.
Establecer el alcance de los servicios, la puntualidad, las horas de
operación, los aspectos a mejorar y el rendimiento del servicio.
Valorar la tecnología que se está utilizando para solventar estas
necesidades.
Verificar que la TI cumple con las necesidades y comodidad tanto del
cliente externo como interno.
Desarrollar y mantener un catálogo de servicios, incluidos los costos de los
niveles de rendimiento de los servicios.
Realizar un análisis donde se identifique que carencias hay entre las
necesidades de negocios y servicios disponibles.
Determinar los costos relacionados con dichos servicios para que se pueda
satisfacer las necesidades del negocio a un precio razonable y que la
empresa pueda sostener.
Establecer los SLA con los clientes, garantizando que dichos
requerimientos se cumplan por parte de todas las partes implicadas.
Implementar SLA
Medir el rendimiento del SLA, informar de los resultados y ajustar si es
necesario.
Los beneficios inmediatos que se obtienen con la aplicación de la gestión de
niveles de servicio son:
152
Se hace más fácil el ajuste de las expectativas en cuanto a calidad del
servicio y evita que se presenten malos entendidos en los acuerdos a
obtenidos.
Hay mayor control e información sobre la calidad del servicio.
Es más evidente la determinación de los roles y responsabilidades.
Proporciona la flexibilidad necesaria para que las empresas reaccionen
rápidamente a las condiciones del mercado
Permite identificar las necesidades para la creación de una infraestructura
más precisa con la cual se puedan cumplir los niveles de servicio.
Ayuda a evitar o mitigar los costos generados por exceso de capacidad.
Los equipos de gestión de nivel de servicio tienen estrechos vínculos con los
procesos de negocio, Gestión de Clientes, Gestión Financiera y Gestión de la
Capacidad. Gestión de la Capacidad es probablemente el más importante y
proporciona datos de rendimiento en la infraestructura de TI al equipo de Gestión
de Niveles de Servicio para el dimensionamiento de SLA. Gestión de Niveles de
Servicio pasa información sobre deficiencias en los servicios y las interrupciones a
la Gestión de la Capacidad para su respectiva evaluación y la aplicación de los
cambios requeridos.
Al igual que con todos los grandes proyectos, la planificación es la clave para el
éxito por lo que se recomienda seguir estos pasos para la aplicación de ITIL –
Gestión de Niveles de servicio.
Reconexión de Datos: En este proceso se debe llevar a cabo lo siguiente.
Evaluar el estado actual, es decir, que se debe descubrir cómo está realizando
actualmente el trabajo en la PYME, que documentos e informes se llevan
actualmente, cuáles son sus políticas y procedimientos.
153
Realizar un inventario de herramientas y programas informáticos utilizados
actualmente, la capacidad de planificación y todo proceso que apoye la
gestión de niveles de servicio.
Validar el presupuesto del cual la PYME dispone para saber con qué
capacidad cuenta.
Realizar un análisis a la PYME para revelar las áreas que requieren mejoras
en los procesos, la formación, o software.
Desarrollar un plan o proyecto para transformar la PYME en una nueva
organización basada en los cambios necesario
Construir un plan.
Establecer los tres componentes principales de la gestión de las capacidades
- personas, procesos y herramientas.
Realizar un esquema de los costos necesarios para mantener los cambios en
la organización y construir un presupuesto preliminar.
Determinar dónde se debe implementar la gestión de niveles de servicio y
generar un informe al grupo o persona encargada de supervisar que se
cumplan estos niveles de servicio.
Describir el flujo de los procesos de trabajo, incluidas las entradas de datos y
divulgación de información.
Destinar suficiente tiempo para entrenamiento del personal.
Identificar cualquier trabajo necesario para adquirir, consolidar y poner en
funcionamiento las herramientas de trabajo.
Es necesario que se comunique a la empresa los nuevos procesos.
Después que el plan y el presupuesto estén terminados, es necesario que estos
estén sujetos a su aprobación por parte de la PYME.
154
Ejecutar el plan: el plan se deberá ejecutar siguiendo una serie de pasos
Asignar el personal.
Documentar y publicar los procesos. Este es un paso importante que
probablemente se tardará bastante tiempo durante la ejecución inicial. Es
necesario documentar el flujo de trabajo: entradas, salidas, trabajo realizado,
los pasos que se hacen para lograr objetivos, que hace el trabajo, quien recibe
el trabajo, y asistencia externa necesaria para ejecutar los procesos.
Adquirir y emplear las herramientas necesarias para la documentación del
proceso. Lo ideal sería que una sola herramienta permitiera realizar los
informes necesarios para la brindar información exacta acerca del rendimiento
del servicio.
Realizar un inventario de los servicios de TI y construir un catálogo de
servicios. Es necesario asegurar que se cumplan las exigencias de la Gestión
Financiera.
Identificar, desarrollar, negociar y aplicar los SLA y OLA. Para ello se requiere
una estrecha colaboración con las directivas de la empresa y todos sus
empleados.
Para determinar los SLA y OLA se debe incluir:
Partes interesadas.
Inicio, final y fechas de validación.
Alcance del acuerdo.
Descripción de los servicios prestados.
Roles y responsabilidades de cada empleado.
Las horas de operación.
Disponibilidad del servicio.
Fiabilidad del servicio.
155
Apoyo.
El rendimiento, los tiempos de operación y / o tiempos de
respuesta.
Requisitos de seguridad.
Continuidad del Servicio.
Costos de los servicios.
Incentivos y sanciones.
Identifique los servicios requeridos actualmente en TI que no se hayan
suministrado.
Definir las métricas para medir el éxito.
Diseñar el material de capacitación y ejecutar el plan de formación. Es
importante tener claro que no solo el equipo de Gestión de Niveles de servicio
debe saber del proceso, sino cualquier otro equipo que interactúa con el debe
estar preparado. La capacitación debe hacer basada en los procesos que se
crearon y hacer pruebas que demuestren la retención de la información.
Implementar informes y procedimientos. Hay dos tipos de informes que son
necesarios: El informe de alto nivel, utilizado para mantener informada a la
directiva de la empresa. El segundo contiene información es más detallada
usada por el equipo de Gestión de Niveles de Servicio para identificar las
áreas más problemáticas.
Iniciar el trabajo de la Gestión de Niveles de servicio: Después de que se ha
llegado a un acuerdo y se han firmado los SLA, se empieza el proceso de
implementación. Los procesos clave en la implementación son:
Alertar al equipo de SLM cuando se presente peligro de no cumplir los
objetivos de rendimiento en los servicios debido a cuellos de botella o picos
repentinos en la demanda.
156
Alertar al equipo de SLM cuando se evidencia que el rendimiento se acerca a
los límites acordados, de modo que se puedan tomar acciones correctivas
para prevenir interrupciones en la prestación del servicio.
Se debe llevar un proceso de mejora continua, para esto se debe realizar un
cronograma de reuniones para revisión mensual o trimestralmente donde se
discutan los resultados obtenidos en el rendimiento del servicio.
Iniciar los cambios necesarios que se pacten en dicha reuniones para atender
cualquier imprevisto o cambios en las prioridades del negocio.
Revisión de la Implementación: Para que la implementación de la Gestión de
Niveles de servicio tenga éxito, es necesario que se haga una continua auditoria a
la calidad de los servicios ofrecidos para determinar si los nuevos procesos se
están cumpliendo y si usted está consiguiendo los resultados esperados.
Algunas de las preguntas que deben plantearse son:
• ¿Logramos lo que intentamos hacer?
• ¿Los indicadores de medición y el desempeño del equipo son válidos?
• ¿Está el equipo de Gestión de Niveles de Servicio en exitosa comunicación con
la organización?
• ¿Trabajan los interfaces sin problemas?
• ¿Cumplimos las expectativas y beneficios que se querían entregar a la empresa?
• ¿Se han mejorado los servicios de TI en general?
• ¿Capturamos los datos correctos?
• ¿Son aceptados los procesos por el personal, tanto interno como externo?
157
El objetivo principal del esta validación no es enfocarse ni limitarse en los SLA
que no se pudieron cumplir, por el contrario se debe mirar por qué no fue posible
llegar a la meta y buscar la manera de brindar una mejor calidad en el servicio
Es importante documentar lo encontrado en la revisión para identificar los
cambios que se deben realizar en el proceso, para facilitar cualquier cambio en el
futuro.
158
3.5.1.8 Gestión financiera
Figura 46: Proceso para la gestión financiera
La Gestión Financiera determina y controla los costos que involucran los servicios
de TI y proporciona un apoyo al área de contabilidad de la empresa a fin de
garantizar que no se desperdicien los fondos de la organización y se cubran los
gastos incluidos en los planes ya aprobados, asegurando que los recursos sean
administrados de una manera eficaz y rentable.
El papel de la gestión financiera varía según el punto de vista de las TI en la
empresa. Algunas empresas lo ven como un centro de gastos, algunos como un
centro de beneficio, y otros como un centro de recuperación de costos. Sin
embargo, en todos los casos, la gestión financiera apoya el "negocio" de las TI.
La Gestión Financiera está fuertemente involucrada con la Gestión de Niveles de
Servicio, Gestión de Capacidad y Gestión de Configuración. Esta ayuda a la
159
gerencia a realizar un análisis y comprender los proyectos con respecto al costo –
beneficio que trae una propuesta de TI. Como resultado, los líderes de negocios
pueden tomar decisiones con base a la información adquirida y pueden considerar
o priorizar una labor futura.
Son responsabilidades de la gestión financiera:
Proporcionar la supervisión y evaluación de todos los gastos en TI
Garantizar que hayan fondos disponibles para cualquier requerimiento que
se necesite.
Suministrar información detallada acerca de las propuestas realizadas.
Realizar seguimiento de los gastos actuales vs presupuesto.
La gestión financiera se debe poner en práctica por que permite:
Planificar y predecir los gastos de TI necesarios para mantener o mejorar
los servicios.
Garantizar que los gastos incluidos en los proyectos aprobados se
reduzcan sin afectar la calidad del servicio.
Ayudar a los directivos en la comprensión del costo total que habrá al
implementar una propuesta de TI.
Promover una mejor comprensión de los costos asociados con la provisión
de servicios específicos.
Fomentar un ambiente de control para asegurar que los servicios son
utilizados con eficacia y eficiencia
Presupuesto
El proceso de presupuestación identifica todos los gastos de TI durante un período
determinado de tiempo para asegurar que el dinero requerido esté disponible y de
esta manera poder mantener las operaciones. El presupuesto normalmente toma
en cuenta costes de prestación de servicios actual, requisitos del proyecto y
crecimiento previsto del negocio. Los presupuestos son generalmente construidos
160
con las estimaciones anuales para lo cual se tiene en cuenta los costos actuales y
los costos posteriores.
El proceso de presupuestación proporciona una idea de cómo los gastos cambian
cada año. Además, ayuda a la gerencia a entender mejor los impactos de las
nuevas tecnologías. En un mínimo, las categorías del presupuesto deben contener
el hardware, el software, personal, telecomunicaciones y los servicios externos
(por ejemplo, recuperación de desastres).
También se deben tener en cuenta algunos gastos de apoyo fuera del costo real a
la hora de planificar el futuro de hardware y las compras de software.
Identificar los costos añadiendo el nuevo hardware para lo siguiente:
• Instalación
• El cableado
• Sistema operativo de software
• Capacidad basada en actualizaciones de software
• Servicios (por ejemplo, el espacio, energía, refrigeración)
• Administración
• Mantenimiento
• Artículos de consumo (por ejemplo, cintas, CD, papel)
• Copia de seguridad / recuperación
Además, identificar los costos al añadir aplicaciones de software para el
presupuesto:
• Instalación
• Hardware de capacidad
• Actualizaciones de software
• Base de datos de mantenimiento
• Administración
• Pruebas
161
• Aseguramiento de la Calidad
• Consumibles (por ejemplo: cintas, discos compactos, formularios en papel)
• Empresas de copia de seguridad / recuperación de datos
Uno de los beneficios del presupuesto es que justifica los gastos y ayuda a
priorizar la adquisición de los servicios de TI necesarios para apoyar las
operaciones del negocio. Además ayuda que los gerentes comprendan los
componentes de los costos y así puedan tener mejores decisiones sobre las
inversiones en TI para que se satisfagan las necesidades de la organización.
Toda la información del presupuesto puede ser llevada en formatos los cuales son
adaptables dependiendo la organización, pero que deben contener información
sobre los costos de operación, costos indirectos y costos ocultos los cuales se
explicaran más adelante.
Contabilidad
El objetivo de contabilidad asociada a TI es proporcionar información financiera
oportuna y exacta sobre las TI en cuanto a gastos actuales y presupuesto, de esta
forma los directivos de la PYME puede tomar decisiones sobre las prioridades en
el suministro de servicios TI para la empresa y tener una mejor comprensión de
los costos en cuanto a los componentes de TI.
Los componentes de contabilidad asociada a TI incluyen:
Seguimiento de los gastos actuales frente al presupuesto o plan financiero.
Coordinación de los datos contables de TI con los departamentos de
contabilidad de la empresa.
Análisis de las inversiones propuestas para identificar los verdaderos costos de
implementación y operación.
Proveer a las directivas de la empresa datos suficientes para entender las
implicaciones a corto y largo de las iniciativas de TI y evaluar los riesgos
financieros asociados con ellos.
162
Este trabajo se realiza solo desde la perspectiva de TI, para revelar los verdaderos
costos de servicios informáticos pero es importante tener claro que no pretende
involucrarse con la contabilidad corporativa como por ejemplo la contabilidad fiscal
de la empresa.
Hay dos componentes principales en el proceso de contabilidad: la contabilidad
analítica de costos y contabilidad analítica de inversión.
Existen dos tipos de costos:
Los costos de capital: Son los que se gastan ahora y afectan el flujo de caja de la
organización generando impacto en las finanzas de la organización. Estos costos
están generalmente relacionados con la adquisición de hardware, software.
Los costos de operación: Son los gastos cotidianos necesarios para sostener las
operaciones.
Los gastos operacionales se incluyen:
Mantenimiento de hardware y software.
Telecomunicaciones - datos y voz.
Personal.
Bienes consumibles - cintas, CD, papel, formularios, útiles de oficina.
Instalaciones - alquiler o asignación de espacio, energía, refrigeración,
alimentación, Seguridad física.
Servicios externos – tales como la recuperación de desastres, consultores,
proveedores.
Transferencia - costos tales como gastos indirectos corporativos, los costos
de recursos humanos, finanzas etc.
EL balance es el instrumento que debe usar la organización para recopilar los
datos e identificar los costos y las métricas de negocio. Se debe determinar cuáles
gastos son fijos y cuales son gastos variables.
163
Una vez que los costos están reunidos, es necesario dividirlos según su uso, estos
pueden estar asociados a la fabricación de los productos o la prestación del
servicio y pueden ser directos o indirectos.
Los costos directos son los que están asociados directamente a un área en
particular. Los ejemplos de costos directos son servidores, tableros del escritorio
departamentales, personal dedicado a apoyar un proceso del negocio.
Los costos indirectos son generalmente los que compartimos todos y son
asignados a diferentes áreas manera equitativa. Los ejemplos de costos indirectos
son las instalaciones, personal de ayuda, centrales telefónicas o PBX.
Análisis de inversiones
Cada área de la organización necesita un capital para mantener y hacer crecer el
negocio. Por lo general, los recursos de capital son limitados por lo que las
directivas de la empresa deben elegir las iniciativas que ofrecen la mejor
rentabilidad para el negocio. Una de las prácticas en TI de ITIL es el Análisis de
Inversiones, que proporciona la información financiera necesaria para tomar
decisiones sobre dotación o incremento en los servicios de TI. Los métodos
populares de análisis de inversiones son:
• ROI - Retorno de la Inversión - muy usado para determinar la longitud del tiempo
antes de que el costo de un activo adquirido se compense con el ahorro o nuevos
ingresos / beneficios.
• TCO - El coste total de la propiedad – permite entender mejor los costos reales
de poner en ejecución un proceso.
• ROCE – El rendimiento sobre el capital invertido es probablemente el método
más popular en todo el mundo.
164
Fijación de tarifas: no es frecuente que la misma organización fije los precios en
servicios de TI cuando ella es el mismo cliente, pero es indispensable cuando
queremos que se de uso eficaz de la infraestructura de TI.
Se debe tener cuidado al fijar las tarifas y no solo tener en cuenta la capacidad
que en teoría se tiene sino que también se debe contemplar la capacidad real de
cada componente de TI
Es necesario establecer una política para la fijación de precios. Para esto hay
varias opciones
Costo más margen: En esta política se agrega un margen de beneficios al
costo base o costo total.
Precio de mercado: En esta política no se cobra ningún valor adicional a
las tarifas que se encuentran actualmente en el mercado.
Precio negociado: En esta política se realiza un acuerdo con el cliente
sobre cuál será el valor que se cobrara por los servicios.
Precio flexible: En esta política depende de los objetivos que se cumplan y
de la capacidad que se use en los servicios de TI.
Al igual que con todos los grandes proyectos, la planificación es la clave. Algunas
recomendaciones a seguir para la aplicación de ITIL en Gestión Financiera de TI
son:
Reunir los datos. Asignar una persona que se encargue de las finanzas con
conocimientos de TI para garantizar una supervisión adecuada de los gastos en
TI, y asignar el personal adicional que sea necesario.
El equipo debe realizar varias funciones.
165
Realizar una evaluación del estado actual, usando ya sea un consultor o la
autoevaluación, para descubrir dónde y en qué medida el trabajo de gestión
financiera se está realizando en la actualidad.
Generar un inventario de herramientas y programas informáticos utilizados
actualmente para presupuesto, contabilidad y sistemas de devolución de cargo.
Realizar el análisis que revele cuales áreas requieren mejoras en los procesos,
en la formación o en el software.
Construir el plan. Para construir el plan debemos tomar en cuenta los siguientes
pasos:
Establecer los tres componentes principales de la gestión financiera (personas,
procesos y herramientas).
Realizar un esquema de los costes necesarios para mantener la organización y
construir un presupuesto preliminar.
Determinar dónde se encuentran el personal encargado de las finanzas en la
organización, de una persona con conocimientos en TI.
Describir el flujo de trabajo, incluidas las entradas de datos, difusión de
información, y procesos de trabajo.
Identificar y capacitar a las personas que realizarán el trabajo.
Identificar cualquier trabajo necesario para adquirir, consolidar y / o
implementar herramientas de gestión financiera.
Es necesario que se comunique a la empresa los nuevos procesos.
Después que el plan y el presupuesto estén terminados, es necesario que estos
estén sujetos a su aprobación por parte de la PYME.
Ejecutar el plan. El plan se deberá ejecutar siguiendo una serie de pasos
Asignar el personal.
166
Documentar y publicar los procesos. Este es un paso importante que
probablemente se tardará bastante tiempo durante la ejecución inicial. Es
necesario documentar el flujo de trabajo: entradas, salidas, trabajo realizado,
los pasos que se hacen para lograr objetivos, que hace el trabajo, quien recibe
el trabajo, y asistencia externa necesaria para ejecutar los procesos.
Adquirir y emplear las herramientas necesarias para la documentación del
proceso. Lo ideal sería que una sola herramienta permitiera realizar los
informes necesarios para la brindar información exacta acerca del rendimiento
del servicio.
Construir el marco de contabilidad y presupuesto. Se debe usar el presupuesto
existente como punto de partida y ajustarlo según sea necesario sobre la base
de la nueva estructura. Obtener facturas, gastos de personal, viajes,
alimentación, servicios de proveedores y programas de depreciación.
Establecer un calendario financiero para especificar cuando se realizaran los
análisis regulares y que puntos serán revisados.
Identificar, definir y aplicar las políticas de precios. Recopilar datos sobre los
servicios de TI para analizar su uso, establecer las tarifas, y finalizar con un
informe.
Definir las métricas para medir el éxito. Asegúrese de atar sus indicadores de
valor para el negocio, no las medidas técnicas. La mayoría de las métricas de
Gestión Financiera estará relacionado con el desempeño financiero de la
empresa.
Diseñar el material de capacitación y ejecutar el plan de formación. La
capacitación debe hacer basada en los procesos que se crearon y hacer
pruebas que demuestren la retención de la información.
Implementar informes y procedimientos. Hay dos tipos de informes que son
necesarios: el informe de alto nivel, utilizado para mantener informada a la
directiva de la empresa. El segundo contiene información es más detallada
usada por el equipo de Gestión Financiera para identificar las áreas más
problemáticas.
167
Iniciar el trabajo de la Gestión Financiera. Una vez que los presupuestos y
balances de contabilidad estén terminados, se deben generar los informes
financieros.
Alertar al equipo de Gestión Financiera cuando se presente peligro de no
cumplir los objetivos financieros y cuando se produzcan cambios sustanciales
en el comportamiento de los usuarios
Se debe llevar un proceso en el cual se evalúen los resultados, para esto se
debe realizar un cronograma de reuniones para revisión mensual o
trimestralmente donde se discutan los resultados obtenidos los cuales deben
ser precisos para determinar si se deben tomar acciones correctivas.
Realizar examen posterior a la ejecución. Al finalizar el proceso, el encargado
del proyecto deberá documentar todos los resultados e identificar los cambios que
deben realizar al proceso para facilitar cualquier cambio que se quiera realizar en
el futuro. Es necesario realizar una auditoria para determinar si los nuevos
procesos se están cumpliendo y si se están consiguiendo los resultados
esperados.
La Gestión Financiera no es quien debe realizar el catalogo de servicios y
negociarlos con los clientes, sin embargo si debe suministrarle información a la
Gestión de Niveles de Servicios sobre los costos reales de los servicios, métodos
y condiciones de pago, presupuestos, relación de costos reales vs gastos que
tendrá la organización.
168
3.5.1.9 Gestión de la capacidad
Figura 47: Proceso para la gestión de la capacidad
La Gestión de Capacidad es de naturaleza proactiva en vez de reactiva y su
función es lograr que se cumplan todas las necesidades de la empresa en cuanto
a recursos de infraestructura en TI para que se puedan desempeñar todas labores
de forma eficaz y sin que los gastos asociados estén desproporcionados.
Muchas empresas ya realizan la Gestión de Capacidad de una u otra forma y
pueden apenas refinar las técnicas para mejorar el proceso.
Existen muchos ingenieros que probablemente tengan una idea de donde existen
las oportunidades de mejora en el funcionamiento de los recursos de TI y la
reducción del costo pero puede que no se hayan implementado debido a la poca
comprensión de ventajas que esto podría traer a la empresa.
169
Con la implementación de la Gestión de la Demanda, los ahorros resultantes, a
menudo puede financiar un porcentaje considerable del resto del programa de ITIL
de la empresa.
Algunas de las ventajas inmediatas que se conseguirán con la implementación de
la Gestión de Capacidad son:
Costos más bajos:
Se puede validar con mayor precisión la eficiencia de las herramientas
informáticas existentes y así determinar cuál debe ser la capacidad máxima
que debe tener para brindar un optimo funcionamiento sin desperdiciar los
recursos, de esta forma se puede mejorar el costo por unidad de servicio.
Mejora continua en el uso de la infraestructura de TI, reduciendo el
consumo y aumentando la capacidad.
El uso de Bases de Datos disminuyen el trabajo redundante a través de
unidades de TI y asegura la coherencia de los informes, lo que mejora la
productividad del personal, reduce cada vez más los gastos de software.
Mejora la Calidad
Permite de manera eficiente distribuir la capacidad y proveer de una manera más
oportuna la información necesaria relacionada con los costos para realizar un
análisis sobre decisiones futuras relacionadas con servicios de TI.
Entre las actividades de la Gestión de Capacidad se incluyen:
Seguimiento, análisis, optimización e implementación de los cambios
necesarios en la utilización de recursos
La Gestión de la demanda de recursos informáticos, lo que requiere una
comprensión de las prioridades del negocio
170
Modelado para simular eficacia de la infraestructura y entender las
necesidades futuras en recursos.
El almacenamiento de datos.
La elaboración de un plan de capacidad que incluya la utilización de
recursos, documentos y requisitos previstos, así como los gastos de apoyo
para nuevas aplicaciones o versiones.
Construir la infraestructura con un plan anual de crecimiento donde se
planee el ingreso de otros equipos.
Los componentes principales de trabajo en la Gestión de Capacidad se describen
a continuación:
La gestión del rendimiento:
Es un proceso de mejora continua que examina la aplicación y rendimiento de los
componentes del sistema, los analiza para identificar posibles mejoras.
Carga de trabajo Usa herramientas de supervisión para gestionar el rendimiento
global en lugar del incremento individual en el uso de un componente de la
infraestructura. El objetivo es hacer frente a las necesidades de capacidad sobre
una base de procesos de negocio. Dado que algunos procesos del negocio tienen
efectos en otros procesos, éste es un método eficiente y eficaz de realizar la
planeación de capacidad.
Plan de capacidad es probablemente el más importante y el trabajo más
complejo, que el equipo de gestión de la capacidad produce.
En la mayoría de los casos el plan de la capacidad se produce sobre una base
anual y por supuesto las correcciones y ajustes por variaciones en los planes de
negocios, se hacen en los intervalos predeterminados, generalmente
trimestralmente o semestralmente. El plan considera volúmenes de negocio, el
crecimiento proyectado, consideraciones presupuestarias de la organización
financiera, los proyectos previstos en las solicitudes de los equipos y las
171
organizaciones de apoyo técnico; mantiene requisitos sobre la restauración de los
equipos de la Gestión de Disponibilidad, la contingencia los requerimientos del
negocio durante la recuperación de equipos por desastres, y el nivel de acuerdos
de servicios.
La Gestión de Capacidad trabaja de la mano con la Gestión de Niveles de
Servicios y la Gestión Financiera para elaborar el mejor plan que cumpla con los
requerimientos del negocio a un costo que se pueda pagar. Los datos más
importantes para el proceso de estimación son los planes de negocio, métricas, y
el nivel de acuerdos de servicios. Sin estas piezas importantes, los componentes
de la infraestructura no pueden ser diseñados con precisión y eficiencia.
Para la mayoría de las organizaciones éste es un esfuerzo grande que no debe
ser subestimado. Se deben asignar suficientes recursos del tiempo y gente para
que la tarea se realice correctamente. Un plan bien hecho de la capacidad bien
hecho tendrá un impacto positivo en los gastos de TI y el empleo de justo a tiempo
de técnicas de aprovisionamiento
La base de datos de la Gestión de Capacidad es un depósito de toda la
información acerca de las TI y la información comercial necesaria para realizar los
trabajos de gestión de capacidad. Esta información también puede ser utilizada
por otras áreas, eliminando así la redundancia en los datos.
El modelado es el proceso de utilizar software que emplea fórmulas matemáticas
para simular el rendimiento empresarial y permitir de crecimiento de la
infraestructura, con el fin de conseguir una aproximación de los recursos que se
necesitaran en el futuro.
El modelo puede encontrar cuellos de botella en la aplicación antes de que los
procesos del negocio tengan un impacto negativo y generará las alertas
necesarias que permitirá establecer acciones correctivas antes de que ocurran
interrupciones en el servicio.
172
Con base a lo anterior podemos decir que el modelado puede prevenir las
pérdidas de la productividad debido a las interrupciones que se puedan presentar
en el servicio y puede reducir o eliminar el riesgo de necesitar adquirir recursos
provisionales para mantener la actividad como de costumbre hasta que las
medidas correctivas se puedan lograr.
Gestión de la demanda se refiere a la gestión de los recursos de TI consumidos
por los usuarios. Esta gestión de demanda es la encargada de validar cuales son
los cambios que se necesitan hacer en la tecnología usada por la empresa para
satisfacer las necesidades del negocio, es decir es la encargada de optimizar los
recursos de TI para que cumplan los requerimientos de la empresa.
Esta gestión tiene mayor importancia cuando se presenta problemas de capacidad
entre los recursos de TI usados por la PYME pues debe brindar las posibles
opciones para solucionar inconvenientes como por ejemplo la degradación del
servicio por aumento de la demanda e interrupciones por errores de hardware y
software.
En caso de conflictos entre los requerimientos del negocio y las limitaciones
presupuestarias, la gestión de capacidad debe saber que opciones comerciales
están disponibles y establecer diálogos entre las partes afectadas para determinar
la mejor solución desde un punto de vista empresarial.
La gestión de capacidad está encargada de manejar los recursos durante períodos
extremos tales como reducciones inesperadas de los servicios de TI que se dan
como resultando de la disminución en la demanda de negocio o por el contrario,
cuando se presentan aumentos inesperados en los volúmenes de negocio,
también es la encargada de gestionar los recursos en TI cuando se presenten
desastres. Durante estos acontecimientos extraordinarios, la gestión de capacidad
es responsable de optimizar recursos existentes para satisfacer como sea posible
las necesidades del negocio basado en sus prioridades.
173
Es importante que la Gestión de la Capacidad se apoye en algunas herramientas
que permitan:
Recopilación de datos de aplicación y rendimiento del sistema, es decir,
una base de datos Capacidad (CDB).
Realizar informes para evaluar el estado actual de las aplicaciones críticas
de negocio.
Facilitar los procesos de análisis para descubrir tendencias problemáticas y
las interrupciones crónicas del servicio.
Analizar los datos de rendimiento para descubrir cuellos de botella a fin de
efectuar ajustes correspondientes de una forma más oportuna.
Proporcionar herramientas de simulación para predecir las necesidades
futuras.
Todos los proyectos exitosos comienzan con un plan de proyecto por lo cual se
recomienda seguir estos pasos para implementar ITIL Gestión de la Capacidad:
Reunir los datos Se debe formar un equipo de Gestión de Capacidad para
encabezar esta implementación piloto
El equipo debe realizar varias funciones:
Diseñar una misión, incluyendo los objetivos deseados al terminar el
proyecto, procesos y responsabilidades.
Evaluar el estado actual. Descubrir dónde y en qué medida el trabajo de
gestión de capacidad se está realizando actualmente, cuales son los
documentos, informes, políticas y procedimientos actuales.
Realizar un inventario con las capacidades que existen actualmente.
Hacer un inventario de herramientas y programas informáticos utilizados
actualmente para el monitoreo, la planificación de la capacidad, y la gestión
y rendimientos de los recursos en TI.
174
Recoger datos del presupuesto con el cual se cuenta para que la Gestión
de Capacidad realice su trabajo.
Realizar un análisis de para identificar qué áreas requieren mejoras en los
procesos, el hardware o software.
Construir el plan. Se debe diseñar un plan de ejecución donde:
Se establezcan los tres componentes principales de la gestión de
capacidad (Personas, Procesos y herramientas.).
Realizar un esquema de los costes necesarios para mantener la
organización
n y construir un presupuesto preliminar
Determinar dónde se debe colocar la gestión de capacidad en la
organización.
Describir el flujo de trabajo, incluidas las entradas de datos, difusión de
información, y procesos de trabajo.
Identificar y capacitar a las personas que realizarán el trabajo.
Identificar cualquier trabajo necesario para adquirir, consolidar y / o
implementar herramientas de gestión de capacidad.
Después que el plan y el presupuesto estén terminados, es necesario que estos
estén sujetos a su aprobación por parte de la PYME
Ejecutar el plan. El primer paso en la ejecución del proyecto consiste en levantar
información sobre la organización donde se implementara la gestión. Esto incluye
el tamaño de la organización, los procesos de trabajo con los nombres de las
personas y cargos que ocupan.
En segundo lugar, es necesario documentar y publicar los procesos. Esto
normalmente requiere una cantidad sustancial de trabajo. Es importante
documentar el flujo de trabajo y reducir al mínimo cualquier interrupción a las
actividades del día a día.
175
Los procesos que deben ser documentados son:
Gestión del rendimiento.
Plan de capacidad
Modelado
Recopilación de datos de rendimiento, almacenamiento y presentación de
informes.
En tercer lugar, usted debe adquirir y aplicar una herramienta que le permita:
Recopilación de datos y seguimiento a la utilización de la infraestructura.
Flexible, presentación de informes
Análisis de funciones
Modelado
En cuarto lugar, se debe definir las métricas necesarias con el fin de medir el éxito.
Por último, debe diseñar el material de capacitación y ejecutar el plan de
formación. Los miembros del equipo de Gestión de capacidad deben entender
muy bien los procesos para que sean mayores las posibilidades de éxitos. La
capacitación debe hacer basada en los procesos que se crearon y hacer pruebas
que demuestren la retención de la información.
Iniciar el trabajo de la Gestión de Niveles de servicio. En un principio, tendrá
que centrarse en la gestión del rendimiento, para reunir suficientes datos históricos
y poder usar esta información en el plan de capacidad.
Se debe realizar este proceso por al menos 30 días antes de desarrollar cualquier
tendencia o modelos.
176
Revisión de la Implementación. Para que la implementación de la Gestión de
Capacidad tenga éxito, es necesario que se haga una continua auditoria que
permita determinar si los nuevos procesos se están cumpliendo y si usted está
consiguiendo los resultados esperados, también se debe documentar los
resultados obtenidos e identificar los cambios que deben ser introducidos en el
proceso para facilitar los requerimientos que se puedan realizar en el futuro.
177
3.5.1.10 Gestión de continuidad del servicio
Figura 48: Proceso para la gestión de la continuidad del servicio
La Gestión de la Continuidad del Servicio se encarga de evitar que se produzca
una interrupción de los servicios de IT, debido a desastres naturales situaciones
técnicas catastróficas o agentes externos que afecten la infraestructura
tecnológica de una organización. Busca la continuidad del negocio.
La gestión de la continuidad debe involucrar los siguientes procesos:
1. Proactivos: Procesos que se enfocan en disminuir o contrarrestar la
interrupción de los servicios de IT.
2. Reactivos: Procesos que buscan poner en línea los servicios lo más rápido
posible después de un desastre.
178
Esta los beneficios de la Gestión de la Continuidad del servicio se ven reflejados a
largo plazo y representa un gran golpe al presupuesto de la compañía, pero
determina la capacidad de respuesta de la organización para mantener el negocio.
Así, los objetivos principales de la Gestión de la Continuidad de los Servicios TI
(ITSCM) se resumen en:
Garantizar la pronta recuperación de los servicios (críticos o core del
negocio) TI tras un desastre.
Establecer políticas y procedimientos que eviten las consecuencias de una
suspensión total de servicios de IT o la alta afectación porcentual del
negocio de la organización. La correcta aplicación de la ITSCM debe
integrar la Gestión de Continuidad del Negocio (BCM).
La Gestión de continuidad del servicio debe diferenciar entre los desastres
comunes como incendios, inundaciones entre otros y los desastres informáticos
como lo son los virus informáticos, fallas eléctricas internas y externas de la
compañía, etcétera. Aunque es responsabilidad de la Gestión de la Continuidad
prever los riesgos asociados en ambos casos y restaurar el servicio TI
rápidamente, en el segundo caso es donde la ITSCM se enfoca
Se pueden asumir que algunas de las características de los desastres informáticos
son:
Son más previsibles y más habituales.
La percepción del cliente es diferente: los desastres naturales son más
asumibles y no se asocian a actitudes negligentes, aunque esto no sea
siempre cierto.
Los beneficios de la ITSCM son:
Se gestionan adecuadamente los riesgos.
Se reduce el periodo de interrupción del servicio por causas de fuerza
mayor.
Se mejora la confianza en la calidad del servicio entre clientes y usuarios.
Sirve de apoyo al proceso de Gestión de la Continuidad del Negocio.
179
Dificultades para implementar correctamente la Gestión de la continuidad:
Puede haber resistencia a realizar inversiones cuya rentabilidad no es
inmediata.
No se presupuestan correctamente los costos asociados.
No se asignan los recursos suficientes.
No existe el compromiso suficiente con el proceso dentro de la organización
y las tareas y actividades correspondientes se demoran perpetuamente
para hacer frente a "actividades más urgentes".
No se realiza un correcto análisis de riesgos y se obvian amenazas y
vulnerabilidades reales.
El personal no está familiarizado con las acciones y procedimientos a tomar
en caso de interrupción grave de los servicios.
Falta de coordinación con la BCM.
Dentro del proceso, las principales actividades de la Gestión de la Continuidad del
Servicio se resumen en:
Establecer las políticas y alcance de la ITSCM.
Evaluar el impacto en el negocio de una interrupción de los servicios TI.
Analizar y prever los riesgos a los que esta expuesto la infraestructura TI.
Establecer las estrategias de continuidad del servicio TI.
Adoptar medidas proactivas de prevención del riesgo.
Desarrollar los planes de contingencia.
Poner a prueba dichos planes.
Formar al personal sobre los procedimientos necesarios para la pronta
recuperación del servicio.
Revisar periódicamente los planes para adaptarlos a las necesidades reales
del negocio.
180
El primer paso necesario para desarrollar una Gestión de la Continuidad del
Servicio coherente es establecer claramente sus objetivos generales, su alcance y
el compromiso de la organización TI: su política y alcance.
La gestión de la empresa debe mostrar su implicación con el proceso desde un
primer momento pues la implantación de la ITSCM puede resultar compleja y
costosa sin la contrapartida de un retorno obvio a la inversión.
Es imprescindible establecer el alcance de la ITSCM en función de:
Los planes generales de Continuidad del Negocio.
Los servicios TI estratégicos.
Los estándares de calidad adoptados.
El histórico de interrupciones graves de los servicios TI.
Las expectativas de negocio.
La disponibilidad de recursos.
La Gestión de la Continuidad del Servicio está abocada al fracaso si no se destina
una cantidad de recursos suficientes, tanto en el plano humano como de
equipamiento (software y hardware). Su dimensión depende de su alcance y sería
absurdo y contraproducente instaurar una política demasiado ambiciosa que no
dispusiera de los recursos correspondientes.
Una importante parte del esfuerzo debe destinarse a la formación del personal.
Éste debe interiorizar su papel en momentos de crisis y conocer perfectamente las
tareas que se espera desempeñe: una emergencia no es el mejor momento para
estudiar documentación y manuales.
Una correcta Gestión de la Continuidad del Servicio requiere en primer lugar,
determinar el impacto que una interrupción de los servicios TI pueden tener en el
negocio.
181
En la actualidad casi todas las empresas, grandes y pequeñas, dependen en
mayor o menor medida de los servicios informáticos, por lo cual, cabe esperar que
un "apagón" de los servicios TI afecte a prácticamente todos los aspectos del
negocio. Sin embargo, es evidente que hay servicios TI estratégicos de cuya
continuidad puede depender la supervivencia del negocio y otros que
"simplemente" aumentan la productividad de la fuerza comercial y de trabajo.
Asimismo, cuanto mayor sea el impacto asociado a la interrupción de un
determinado servicio mayor habrá de ser el esfuerzo realizado en actividades de
prevención. No obstante, en aquellos casos en que la "solución puede esperar"
se puede optar exclusivamente por planes de recuperación.
Los servicios TI han de ser analizados por la ITSCM en función de diversos
parámetros:
En cuanto a las consecuencias de la interrupción del servicio en el negocio, se
encuentran:
Pérdida de rentabilidad.
Pérdida de cuota de mercado.
Mala imagen de marca.
Otros efectos secundarios.
Cuánto se puede esperar a restaurar el servicio sin que tenga un alto
impacto en los procesos de negocio.
Compromisos adquiridos a través de los SLAs.
Dependiendo de estos factores se buscará un balance entre las actividades de
prevención y recuperación teniendo en cuenta sus respectivos costes financieros.
Asimismo, sin conocer cuáles son los riesgos reales a los que se enfrenta la
infraestructura TI es imposible realizar una política de prevención y recuperación
ante desastre, mínimamente eficaz. Así, la Gestión de la Continuidad del Servicio
debe enumerar y evaluar, dependiendo de su probabilidad e impacto, los
diferentes riesgos y factores de riesgo. Para ello la ITSCM debe:
182
Conocer en profundidad la infraestructura TI y cuáles son los elementos de
configuración (CIs) involucrados en la prestación de cada servicio,
especialmente los servicios TI críticos y estratégicos.
Analizar las posibles amenazas y estimar su probabilidad.
Detectar los puntos más vulnerables de la infraestructura TI.
Gracias a los resultados de este detallado análisis, puede disponerse de
información suficiente para proponer diferentes medidas de prevención y
recuperación que se adapten a las necesidades reales del negocio. No obstante,
la prevención frente a riesgos genéricos y poco probables puede ser muy cara y
no estar siempre justificada, sin embargo, las medidas preventivas o de
recuperación frente a riesgos específicos pueden resultar sencillas, de rápida
implementación y relativamente de un menor costo.
Por ejemplo, si el riesgo de pérdida de alimentación eléctrica es elevado debido,
por ejemplo, a la localización geográfica se puede optar por deslocalizar ciertos
servicios TI a través de ISPs que dispongan de sistemas de generadores
redundantes o adquirir generadores que proporcionen la energía mínima
necesaria para alimentar los CIs de los que dependen los servicios más críticos,
etc.
Por ende, dentro de las estrategias, la continuidad de los servicios TI puede
conseguirse, bien mediante medidas preventivas, que eviten la interrupción de los
servicios, o medidas reactivas, que recuperen unos niveles aceptables de servicio
en el menor tiempo posible. Por ende, es responsabilidad de la Gestión de la
Continuidad del Servicio diseñar actividades de prevención y recuperación que
ofrezcan las garantías necesarias a unos costes razonables.
Igualmente, las medidas preventivas requieren un detallado análisis previo de
riesgos y vulnerabilidades. Algunos de ellos serán de carácter general: incendios,
desastres naturales, etcétera, mientras que otros tendrán un carácter
183
estrictamente informático: fallo de sistemas de almacenamiento, ataques de
hackers, virus informáticos, etcétera.
La adecuada prevención de los riesgos de carácter general depende de una
estrecha colaboración con la Gestión de la Continuidad del Negocio (BCM) y
requieren medidas que implican a la infraestructura "física" de la organización. Así,
la prevención de riesgos y vulnerabilidades "lógicas" o de hardware requieren
especial atención de la ITSCM. En este aspecto es esencial la estrecha
colaboración con la Gestión de la Seguridad.
Por su parte, los sistemas de protección habituales son los de "Fortaleza" que
ofrecen protección perimetral a la infraestructura TI. Aunque, imprescindibles no
se hallan exentos de sus propias dificultades pues aumentan la complejidad de la
infraestructura TI y pueden ser a su vez fuente de nuevas vulnerabilidades.
Tarde o temprano, por muy eficiente que sea el resultado de las actividades de
prevención, será necesario poner en marcha procedimientos o actividades de
recuperación.
En líneas generales existen tres opciones de recuperación del servicio:
"Cold standby": que requiere una ubicación alternativa en el que podamos
reproducir en pocos días nuestro entorno de producción y servicio. Esta
opción es la adecuada si los planes de recuperación estiman que la
organización puede mantener sus niveles de servicio durante este periodo
sin el apoyo de la infraestructura TI.
"Warm standby": que requiere una instalación alternativa con sistemas
activos diseñados para recuperar los servicios críticos en un plazo de entre
24 y 72 horas.
"Hot standby": que requiere una instalación alternativa con una replicación
continua de datos y con todos los sistemas activos preparados para la
inmediata sustitución de la estructura de producción. Ésta es evidentemente
184
la opción más costosa y debe emplearse sólo en el caso de que la
interrupción del servicio TI tuviera inmediatas repercusiones comerciales.
Por supuesto, existe otra alternativa que consiste en hacer "poco o nada" y
esperar que las aguas vuelvan naturalmente a su cauce: una alternativa poco
recomendable para alguien que esté hojeando este curso sobre ITIL y del que se
supone que los servicios TI jugarán un papel importante en su organización.
Una vez determinado el alcance de la ITSCM, analizados los riesgos y
vulnerabilidades y definidas unas estrategias de prevención y recuperación es
necesario asignar y organizar los recursos necesarios.
Con ese objetivo la Gestión de la Continuidad del Servicio debe elaborar una serie
de documentos entre los que se incluyen:
Plan de prevención de riesgos.
Plan de gestión de emergencias.
Plan de recuperación.
Plan de prevención de riesgos
Cuyo objetivo principal es el de evitar o minimizar el impacto de un desastre en la
infraestructura TI.
Entre las medidas habituales se encuentran:
Almacenamiento de datos distribuidos.
Sistemas de alimentación eléctrica de soporte.
Políticas de back-ups.
Duplicación de sistemas críticos.
Sistemas de seguridad pasivos.
Las crisis suelen provocar "reacciones de pánico" que pueden ser
contraproducentes y a veces incluso más dañinas que las provocadas por el
185
incidente que las causo. Por ello, es imprescindible que en caso de situación de
emergencia estén claramente determinadas las responsabilidades y funciones del
personal así como los protocolos de acción correspondientes.
En principio los planes de gestión de emergencias deben tomar en cuenta
aspectos tales como:
Evaluación del impacto de la contingencia en la infraestructura TI.
Asignación de funciones de emergencia al personal de servicio TI.
Comunicación a los usuarios y clientes de una grave interrupción o
degradación del servicio.
Procedimientos de contacto y colaboración con los proveedores
involucrados.
Protocolos para la puesta en marcha del plan de recuperación
correspondiente.
Cuando la interrupción del servicio es inevitable, llega el momento de poner en
marcha los procedimientos o planes de recuperación.
El plan de recuperación debe incluir todo lo necesario para:
Reorganizar al personal involucrado.
Restablecer los sistemas de hardware y software necesarios.
Recuperar los datos y reiniciar el servicio TI.
Los procedimientos de recuperación pueden depender de la importancia de la
contingencia y de la opción de recuperación asociada ("cold o hot stand-by"), pero
en general involucran:
Asignación de personal y recursos.
Instalaciones y hardware alternativos.
Planes de seguridad que garanticen la integridad de los datos.
Procedimientos de recuperación de datos.
186
Contratos de colaboración con otras organizaciones.
Protocolos de comunicación con los clientes.
Cuando se pone en marcha un plan de recuperación no hay espacio para la
improvisación, cualquier decisión puede tener graves consecuencias tanto en la
percepción que de nosotros tengan nuestros clientes, como en los costos
asociados al proceso.
Aunque pueda resultar paradójico, un "desastre" puede ser una buena oportunidad
para demostrar a los clientes la solidez de nuestra organización TI y por tanto
incrementar la confianza que tiene depositada en nosotros. Ya conocen el dicho:
"No hay mal que por bien no venga".
Una vez establecidas las políticas, estrategias y planes de prevención y
recuperación es indispensable que estos no queden en papel mojado y que la
organización TI esté preparada para su correcta implementación. Esto, depende
de dos factores clave: la correcta formación del personal involucrado y la continua
monitorización y evaluación de los planes para su adecuación a las necesidades
reales del negocio.
No obstante, es inútil disponer de unos completos planes de prevención y
recuperación si las personas que eventualmente deben llevarlos a cabo no están
familiarizadas con los mismos.
Es indispensable que la ITSCM:
Dé a conocer al conjunto de la organización TI los planes de prevención y
recuperación.
Ofrezca formación específica sobre los diferentes procedimientos de
prevención y recuperación.
187
Realice periódicamente simulacros para diferentes tipos de desastres con el
fin de asegurar la capacitación del personal involucrado.
Facilite el acceso permanente a toda la información necesaria, por ejemplo,
a través de la Intranet o portal B2E de la empresa.
Asimismo, Tanto las políticas, estrategias y planes han de ser actualizados
periódicamente para asegurar que responden a los requisitos de la organización
en su conjunto.
Cualquier cambio en la infraestructura TI o en los planes de negocio, puede
requerir de una profunda revisión de los planes en vigor y una consecuente
auditoría que evalúe su adecuación a la nueva situación. Asimismo, en ocasiones
en que el dinamismo del negocio y los servicios TI lo haga recomendable, estos
procesos de actualización y auditoria pueden establecerse de forma periódica.
Por su parte, la Gestión de Cambios juega un papel esencial en asegurar que los
planes de recuperación y prevención estén actualizados manteniendo informada a
la ITSCM de los cambios realizados o previstos.
Por su parte, la Gestión de la Continuidad del Servicio debe elaborar
periódicamente informes sobre su gestión que incluyan información relevante para
el resto de la organización TI, como parte de un control del proceso.
Estos informes deben incluir:
Análisis sobre nuevos riesgos y evaluación de su impacto.
Evaluación de los simulacros de desastre realizados.
Actividades de prevención y recuperación realizadas.
Costos asociados a los planes de prevención y recuperación.
Preparación y capacitación del personal TI respecto a los planes y
procedimientos de prevención y recuperación.
188
Uno de los factores clave para el éxito de la Gestión de la Continuidad del Servicio
es mantener la "concentración". Tras largos periodos en los que la prevención o,
simple y llanamente, la suerte han impedido la existencia de graves interrupciones
del servicio se puede caer en un relajamiento que puede acarrear graves
consecuencias. Por esto es imprescindible llevar controles rigurosos que impidan
que la inversión y compromiso inicial se diluyan y la ITSCM no esté a la altura de
la situación cuando sus servicios sean vitales para evitar que "un desastre se
convierta en una catástrofe".
Pero si el control del proceso es importante en condiciones normales éste se
vuelve crítico durante las situaciones de crisis. La ITSCM debe garantizar:
La puesta en marcha de los planes preestablecidos.
La supervisión de los mismos.
La coordinación con la Gestión de Continuidad del Negocio.
La asignación de recursos necesarios.
Como caso práctico se puede establecer, la organización TI de "Cater Matters"
carece de una Gestión de la Continuidad del Servicio que merezca ese nombre.
La gestión de "Cater Matters" es consciente de la importancia que tienen en la
actualidad los servicios TI en toda su cadena de producción y distribución y
pretende corregir esa situación.
Entre todos los servicios TI, los asociados a la gestión de existencias, por estar
compuestas de productos perecederos, y los servicios online de pedidos son
considerados de importancia estratégica por la dirección de la empresa. Por ello
se decide que en primera instancia la ITSCM debe garantizar la continuidad de
dichos servicios en un plazo nunca superior a las 8 horas mientras que se
establecen objetivos menos ambiciosos para otros servicios.
189
Se asigna a un ejecutivo sénior del departamento TI el papel de gestor del proceso
y se le encarga coordinar todas las actividades con la Gestión de la Continuidad
del Negocio.
La Gestión de la Continuidad del Negocio ha firmado acuerdos de colaboración
con otras empresas de catering para suministros de emergencia que cubran los
clientes más importantes:
Servicios de catering de colegios y hospitales.
Congresos y eventos multitudinarios de todo tipo.
La coordinación en estos casos requiere el desarrollo de módulos especiales que
permitan exportar las bases de datos de pedidos a formatos estándar de
intercambio de datos para que estos puedan ser procesados por las otras
organizaciones.
Por otro lado, se desarrolla una aplicación de gestión de emergencia de las
existencias que permite administrar los pedidos a los proveedores y preservar la
integridad de las existencias dependiendo de su información de caducidad y del
impacto de la interrupción del negocio en las mismas.
Se establece asimismo:
Un calendario periódico de pruebas de los planes de recuperación.
Un calendario de cursos de formación sobre los protocolos de actuación en
situación de emergencia.
Pero la Gestión de la Continuidad del Servicio no sólo debe aplicar medidas
reactivas que mitiguen el impacto de una eventual interrupción del servicio, entre
sus obligaciones se encuentran la elaboración de unos planes de prevención que
eviten dichas situaciones.
190
Para evitar interrupciones de sus servicios online la ITSCM:
Contrata servicios de "housing" con un proveedor que dispone de
conexiones con varios operadores al "backbone de Internet" y asegura
alimentación eléctrica interrumpida.
Replica los sistemas críticos en diferentes localizaciones geográficas.
Supervisa la política de back-ups de los servidores de datos.
Instala sistemas de protección perimetral.
Así, nuestras vidas, tanto personales como profesionales, dependen cada vez más
de la tecnología. Ésta nos permite acceder a la información y a los servicios a una
velocidad que ni siquiera podríamos haber soñado hace unos pocos años.
Nuestro ritmo de vida se acelera y exigimos como clientes una disponibilidad
absoluta de nuestros proveedores tecnológicos. Con frecuencia una oferta
diferente sólo se encuentra a un par de clics de distancia.
Por otro lado, el rápido desarrollo tecnológico implica una constante renovación de
equipos y servicios. Como proveedores nos enfrentamos al reto de evolucionar sin
apenas margen para el error pues nuestros sistemas han de encontrarse a
disposición del cliente prácticamente 24/7.
La Gestión de la Disponibilidad es responsable de optimizar y monitorear los
servicios TI para que estos funcionen ininterrumpidamente y de manera fiable,
cumpliendo los SLAs y todo ello a un costo razonable. La satisfacción del cliente y
la rentabilidad de los servicios TI dependen en gran medida de su éxito.
191
3.5.1.11 Gestión de disponibilidad
Figura 49: Proceso para la gestión de la disponibilidad
El objetivo primordial de la Gestión de la Disponibilidad es asegurar que los
servicios TI estén disponibles y funcionen correctamente siempre que los clientes
y usuarios deseen hacer uso de ellos en el marco de los SLAs en vigor.
De esta forma, las responsabilidades de la Gestión de la Disponibilidad incluyen:
Determinar los requisitos de disponibilidad en estrecha colaboración con los
clientes.
Garantizar el nivel de disponibilidad establecido para los servicios TI.
Monitorear la disponibilidad de los sistemas TI.
Proponer mejoras en la infraestructura y servicios TI con el objetivo de
aumentar los niveles de disponibilidad.
Supervisar el cumplimiento de los OLAs y UCs acordados con proveedores
internos y externos.
192
Los indicadores clave sobre los que se sustenta el proceso de Gestión de la
Disponibilidad se resumen en:
1. Disponibilidad: porcentaje de tiempo sobre el total acordado en que los
servicios TI han sido accesibles al usuario y han funcionado correctamente.
2. Fiabilidad: medida del tiempo durante el cual los servicios han funcionado
correctamente de forma ininterrumpida.
3. Mantenibilidad: capacidad de mantener el servicio operativo y recuperarlo
en caso de interrupción.
4. Capacidad de Servicio: determina la disponibilidad de los servicios internos
y externos contratados y su adecuación a los OLAs y UCs en vigor. Cuando
un servicio TI es subcontratado en su totalidad la disponibilidad y la
capacidad de servicio son términos equivalentes.
Entre las actividades que la Gestión de la Disponibilidad se encuentra:
Determinar cuáles son los requisitos de disponibilidad reales del negocio.
Desarrollar un plan de disponibilidad donde se estimen las necesidades de
disponibilidad futura a corto y medio plazo.
Mantenimiento del servicio en operación y recuperación del mismo en caso
de fallo.
Realizar diagnósticos periódicos sobre la disponibilidad de los sistemas y
servicios.
Evaluar la capacidad de servicio de los proveedores internos y externos.
Monitorizar la disponibilidad de los servicios TI.
Elaborar informes de seguimiento con la información recopilada sobre
disponibilidad, fiabilidad, matenibilidad y cumplimiento de OLAs y UCs.
Evaluar el impacto de las políticas de seguridad en la disponibilidad.
Asesorar a la Gestión del Cambio sobre el posible impacto de un cambio en
la disponibilidad.
También, es indispensable cuantificar los requisitos de disponibilidad para la
correcta elaboración de los SLAs.
193
La disponibilidad propuesta debe encontrase en línea tanto con las necesidades
reales del negocio como con las posibilidades de la organización TI. Aunque en
principio todos los clientes estarán de acuerdo con unas elevadas cuotas de
disponibilidad, es importante hacerles ver que una alta disponibilidad puede
generar unos costos injustificados dadas sus necesidades reales. Quizá unas
pocas horas sin un determinado servicio pueden representar poco más allá de una
pequeña inconveniencia mientras que la certeza de un servicio prácticamente
continuo y sin interrupciones puede requerir la replicación de sistemas u otras
medidas igualmente costosas que no van a tener una repercusión real en la
rentabilidad del negocio.
Para llevar a cabo eficientemente está tarea es necesario que la Gestión de la
Disponibilidad:
Identifique las actividades clave del negocio.
Cuantifique los intervalos razonables de interrupción de los diferentes
servicios dependiendo de sus respectivos impactos.
Establezca los protocolos de mantenimiento y revisión de los servicios TI.
Determine las franjas horaria de disponibilidad de los servicios TI (24/7,
12/5, ...).
La correcta planificación de la disponibilidad permite establecer unos niveles de
disponibilidad adecuados tanto en lo que respecta a las necesidades reales del
negocio como a las posibilidades de la organización TI. Así como, el documento
que debe recoger los objetivos de disponibilidad presentes y futuros y que
medidas son necesarias para su cumplimiento es el Plan de Disponibilidad.
Esta planificación debe recoger:
La situación actual de disponibilidad de los servicios TI. Obviamente esta
información debe ser actualizada periódicamente.
Herramientas para la monitorización de la disponibilidad.
Métodos y técnicas de análisis a utilizar.
194
Definiciones relevantes y precisas de las métricas a utilizar.
Planes de mejora de la disponibilidad.
Expectativas futuras de disponibilidad.
Es imprescindible que este plan proponga los cambios necesarios para que se
cumplan los estándares previstos y colabore con la Gestión de Cambios y la
Gestión de Versiones en su implementación (en caso de ser aprobados, claro
está). Asimismo, para que este plan sea realista debe contar con la colaboración
de los otros procesos TI involucrados.
Es crucial para una correcta Gestión de la Disponibilidad participar desde el inicio
en el desarrollo de los nuevos servicios TI de forma que estos cumplan los
estándares plasmados en el Plan de Disponibilidad. Sin embargo, un diferente
nivel de disponibilidad puede requerir cambios drásticos en los recursos utilizados
o en las actividades necesarias para suministrar un determinado servicio TI. Si
éste se diseña sin tener en cuenta futuras necesidades de disponibilidad puede
ser necesario un completo rediseño al cabo de poco tiempo, incurriendo en costos
adicionales innecesarios.
Aunque hayamos realizado un correcto diseño de los servicios según el Plan de
Disponibilidad y se hayan tomado todas las medidas preventivas necesarias, tarde
o temprano, nos tendremos que enfrentar a interrupciones del servicio; en esos
casos es necesario recuperar el servicio lo antes posible para que no tenga un
efecto indeseado sobre los niveles de disponibilidad acordados.
Aunque la responsabilidad de restaurar el servicio corresponde a la Gestión de
Incidentes y las actividades de recuperación han de ser coordinadas por el Service
Desk, la Gestión de la Disponibilidad debe prestar su asesoramiento mediante
planes de recuperación que tengan en cuenta:
Las necesidades de disponibilidad del negocio.
195
Las implicaciones del incidente en la infraestructura TI y los procesos
necesarios para restaurar el servicio.
Independientemente de las interrupciones del servicio causadas por
incidencias es habitualmente necesario interrumpir el servicio para realizar
labores de mantenimiento y/o actualización. Estas interrupciones
programadas pueden afectar a la disponibilidad del servicio y por lo tanto
han de ser cuidadosamente planificadas para minimizar su impacto.
No obstante, en aquellos casos en que los servicios no son 24/7 es obvio que,
siempre que ello sea posible, deben aprovecharse las franjas horarias de
inactividad para realizar las tareas que implican una degradación o interrupción del
servicio.
Si el servicio es 24/7 y la interrupción es necesaria se debe:
Consultar con el cliente en que franja horaria la interrupción del servicio
afectará menos a sus actividades de negocio.
Informar con la antelación suficiente a todos los agentes implicados.
Incorporar dicha información a los SLAs.
En cuanto a la seguridad, Uno de los aspectos esenciales para obtener altos
niveles de fiabilidad y disponibilidad es una correcta Gestión de la Seguridad. Los
aspectos relativos a la seguridad deben ser tomados en cuenta en todas las
etapas del proceso.
Asimismo, es tan importante determinar cuándo el servicio estará disponible como
el "quién y cómo" va a utilizarlo. La disponibilidad y seguridad son
interdependientes y cualquier fallo en una de ellas afectará gravemente a la otra.
Por su parte, la monitorización de la disponibilidad del servicio y la elaboración de
los informes correspondientes son dos de las principales actividades de la Gestión
de la Disponibilidad. Desde el momento de la interrupción del servicio hasta su
196
restitución o "tiempo de parada" el incidente pasa por distintas fases que deben
ser individualmente analizadas:
1. Tiempo de detección: es el tiempo que transcurre desde que ocurre el fallo
hasta que la organización TI tiene constancia del mismo.
2. Tiempo de respuesta: es el tiempo que transcurre desde la detección del
problema hasta que se realiza un registro y diagnóstico del incidente.
3. Tiempo de reparación/recuperación: periodo de tiempo utilizado para
reparar el fallo o encontrar un "workaround" o solución temporal al mismo y
devolver el sistema a la situación anterior a la interrupción del servicio.
Es importante determinar métricas que permitan medir con precisión las diferentes
fases del ciclo de vida de la interrupción del servicio. El cliente debe conocer estas
métricas y dar su conformidad a las mismas para evitar malentendidos. En
algunos casos es difícil determinar si el sistema está "caído o en funcionamiento" y
la interpretación puede diferir entre proveedores y clientes, por lo tanto, estás
métricas deben de poder expresarse en términos que el cliente pueda entender.
Igualmente, algunos de los parámetros que suele utilizar la Gestión de la
Disponibilidad y que debe poner a disposición del cliente en los informes de
disponibilidad correspondientes incluyen:
Tiempo Medio de Parada (Downtime): que es el tiempo promedio de
duración de una interrupción de servicio, e incluye el tiempo de detección,
respuesta y resolución.
Tiempo Medio entre Fallos (Uptime): es el tiempo medio durante el cual el
servicio está disponible sin interrupciones.
Tiempo Medio entre Incidentes: es el tiempo medio transcurrido entre
incidentes que es igual a la suma del Tiempo Medio de Parada y el Tiempo
Medio entre Fallos. El Tiempo Medio entre Incidentes es una medida de la
fiabilidad del sistema.
197
Dentro de los métodos y técnicas a desarrollar, es habitual definir la disponibilidad
en tanto por ciento de la siguiente manera:
Donde:
De esta forma, AST se corresponde con el tiempo acordado de servicio, DT es el
tiempo de interrupción del servicio durante las franjas horarias de disponibilidad
acordadas.
Por ejemplo, si el servicio es 24/7 y en el último mes el sistema ha estado caído
durante 4 horas por tareas de mantenimiento la disponibilidad real del servicio fue:
- La Gestión de la Disponibilidad tiene a su disposición un buen número de
métodos y técnicas que le permiten determinar qué factores intervienen en
la disponibilidad del servicio y que le permiten consecuentemente prever
qué tipo de recursos se deben asignar para las labores de prevención,
mantenimiento y recuperación, así como elaborar planes de mejora a partir
de dichos análisis.
Entre dichas técnicas se cuentan:
CFIA: Que son las siglas de Component Failure Impact Analysis (Análisis
del Impacto de Fallo de Componentes).
Mediante este método se identifica el impacto que tiene en la disponibilidad de los
servicios TI, el fallo de cada elemento de configuración involucrado. Es evidente
que este método requiere una CMDB correctamente actualizada.
FTA: Que son las siglas de Failure Tree Analysis (Análisis del Árbol de
Fallos).
198
Su objetivo es estudiar cómo se "propagan" los fallos a través de la infraestructura
TI para comprender mejor su impacto en la disponibilidad del servicio.
CRAMM
Que son las siglas de CCTA Risk Analysis and Management Method (Método de
Gestión y Análisis de Riesgos de la CCTA).
Su objetivo es identificar los riesgos y vulnerabilidades a los que se haya expuesta
la infraestructura TI con el objetivo de adoptar contramedidas que los reduzcan o
que permitan recuperar rápidamente el servicio en caso de interrupción del mismo.
SOA: Que son las siglas de Service Outage Analysis (Análisis de
Interrupción del Servicio).
Ésta técnica tiene como objetivo analizar las causas de los fallos detectados y
proponer soluciones a los mismos.
Así, se diferencia de los anteriores métodos en que realiza el análisis desde el
punto de vista del cliente haciendo especial énfasis en aspectos no
exclusivamente técnicos ligados directamente a la infraestructura TI.
Por otra parte, dentro del control del proceso, la Gestión de la Disponibilidad debe
elaborar periódicamente informes sobre su gestión que incluyan información
relevante tanto para los clientes como para el resto de la organización TI.
Estos informes deben incluir:
Técnicas y métodos utilizados para la prevención y el análisis de fallos.
Información estadística sobre:
Tiempos de detección y respuesta a los fallos.
Tiempos de reparación y recuperación del servicio.
Tiempo medio de servicio entre fallos.
Disponibilidad real de los diferentes servicios.
199
Cumplimiento de los SLAs en todo lo referente a la disponibilidad y
fiabilidad del servicio.
Cumplimiento de los OLAs y UCs en todo lo referente a la capacidad de
servicio prestada por los proveedores internos y externos.
Para que toda esta información sea fácil y correctamente analizada es
imprescindible el establecimiento de métricas precisas, que permitan determinar
de forma inequívoca parámetros tales como tiempos de parada y funcionamiento.
Por ejemplo, en el caso de un servicio online de comercio electrónico se puede
considerar que tiempos de respuesta superiores a 10 segundos son equivalentes
a que el sistema esta caído, aunque estrictamente hablando el sistema termine
respondiendo.
De esta forma, como caso práctico puede tomarse, la disponibilidad 12/7 es algo a
lo que los clientes de "Cater Matters" otorgan una gran importancia. Los servicios
TI sólo juegan una pequeña, aunque importante, parte en los servicios prestados
por la organización a sus clientes y los problemas de disponibilidad suelen
proceder de procesos no directamente ligados con la tecnología. Sin embargo,
una interrupción de los servicios online pueden presuponer un grave problema
dado el alto volumen de pedidos que se reciben por dicho canal, la práctica
totalidad, así como su importancia en el apartado de la gestión de stocks de
materia prima.
También, la Gestión de la Disponibilidad, en colaboración con los responsables de
otros procesos TI ha sido encargada de elaborar nuevos planes de disponibilidad
que tengan en cuenta un rápido crecimiento del negocio que puede implicar una
disponibilidad 24/7 para diferentes líneas de negocio.
200
La elaboración de este nuevo plan requiere:
La revisión de los UCs en vigor con los proveedores de servicios de
Internet.
Definición de niveles de disponibilidad para los nuevos servicios.
Diseño para la disponibilidad 24/7 de los servicios TI ofrecidos.
Nuevos planes de gestión del mantenimiento que ahora requerirán una
interrupción real del servicio.
Por otro lado, la gestión de "Cater Matters" ha decidido informar periódicamente a
sus clientes sobre los niveles de rendimiento y disponibilidad de los diferentes
servicios prestados. Para ello ha encargado a la Gestión de la Disponibilidad que
implante los procedimientos necesarios para la medición de aspectos como:
Tiempo transcurrido entre incidentes.
Tiempo de parada del servicio.
Tiempo de respuesta para cada incidente.
Retraso en el la entrega del servicio.
Que se complementarán con un módulo de cálculo estadístico y de generación
automática de informes sobre el cumplimiento de los niveles de disponibilidad
acordados para cada cliente. De esta forma, "Cater Matters" busca entablar una
relación de confianza con sus clientes y mantener a la organización TI alerta sobre
posibles degradaciones de los niveles de calidad del servicio.
201
3.5.1.12 Gestión de seguridad
Figura 50: Proceso para la gestión de seguridad
La Gestión de la Seguridad de la Información se remonta al comienzo de los
tiempos. La cristología o la ciencia de la confidencialidad de la información se
remontan al inicio de nuestra civilización y ha ocupado algunas de las mentes
matemáticas más brillantes de la historia, especialmente (y desafortunadamente)
en tiempos de guerra.
Sin embargo, desde el advenimiento de las presentes redes de comunicación y en
especial Internet los problemas asociados a la seguridad de la información se han
agravado considerablemente y nos afectan prácticamente a todos. En alguna
ocasión todos hemos sido víctima de algún virus informático en el computador, del
spam (ya sea por correo electrónico o teléfono) por una deficiente protección de
sus datos personales o, aún peor, del robo del número de su tarjeta de crédito.
202
Asimismo, la información es consustancial al negocio y su correcta gestión debe
apoyarse en tres pilares fundamentales:
3 Confidencialidad: la información debe ser sólo accesible a sus destinatarios
predeterminados.
4 Integridad: la información debe ser correcta y completa.
5 Disponibilidad: debemos de tener acceso a la información cuando la
necesitamos.
La Gestión de la Seguridad debe, por tanto, velar por que la información sea
correcta y completa, esté siempre a disposición del negocio y sea utilizada sólo
por aquellos que tienen autorización para hacerlo.
Por otra parte, los principales objetivos de la Gestión de la Seguridad se resumen
en:
Diseñar una política de seguridad, en colaboración con clientes y
proveedores correctamente alineada con las necesidades del negocio.
Asegurar el cumplimiento de los estándares de seguridad acordados.
Minimizar los riesgos de seguridad que amenacen la continuidad del
servicio.
La correcta Gestión de la Seguridad no es responsabilidad (exclusiva) de
"expertos en seguridad" que desconocen los otros procesos de negocio. Así, si
caemos en la tentación de establecer la seguridad como una prioridad en sí misma
limitaremos las oportunidades de negocio que nos ofrece el flujo de información
entre los diferentes agentes implicados y la apertura de nuevas redes y canales de
comunicación.
Por ende, la Gestión de la Seguridad debe conocer en profundidad el negocio y
los servicios que presta la organización TI para establecer protocolos de seguridad
que aseguren que la información esté accesible cuando se necesita por aquellos
que tengan autorización para utilizarla.
203
Una vez comprendidos cuales son los requisitos de seguridad del negocio, la
Gestión de la Seguridad debe supervisar que estos se hallen convenientemente
plasmados en los SLAs correspondientes para, a renglón seguido, garantizar su
cumplimiento.
La Gestión de la Seguridad debe asimismo tener en cuenta los riesgos generales
a los que está expuesta la infraestructura TI, y que no necesariamente tienen
porque figurar en un SLA, para asegurar, en la medida de lo posible, que no
representan un peligro para la continuidad del servicio.
No obstante, es importante que la Gestión de la Seguridad sea proactiva y evalúe
a priori los riesgos de seguridad que pueden suponer los cambios realizados en la
infraestructura, nuevas líneas de negocio, etcétera.
Los principales beneficios de una correcta Gestión de la Seguridad son:
Se evitan interrupciones del servicio causadas por virus, ataques
informáticos, etcétera.
Se minimiza el número de incidentes.
Se tiene acceso a la información cuando se necesita y se preserva la
integridad de los datos.
Se preserva la confidencialidad de los datos y la privacidad de clientes y
usuarios.
Se cumplen los reglamentos sobre protección de datos.
Mejora la percepción y confianza de clientes y usuarios en lo que respecta a
la calidad del servicio.
Las principales dificultades a la hora de implementar la Gestión de la
Seguridad se resumen en:
No existe el suficiente compromiso de todos los miembros de la
organización TI con el proceso.
Se establecen políticas de seguridad excesivamente restrictivas que afectan
negativamente al negocio.
204
No se dispone de las herramientas necesarias para monitorizar y garantizar
la seguridad del servicio (firewalls, antivirus,...).
El personal no recibe una formación adecuada para la aplicación de los
protocolos de seguridad.
Falta de coordinación entre los diferentes procesos lo que impide una
correcta evaluación de los riesgos.
La Gestión de la Seguridad está estrechamente relacionada con prácticamente
todos los otros procesos TI y necesita para su éxito la colaboración de toda la
organización.
Para que esa colaboración sea eficaz es necesario que la Gestión de la
Seguridad:
Establezca una clara y definida política de seguridad que sirva de guía a
todos los otros procesos.
Elabore un Plan de Seguridad que incluya los niveles de seguridad
adecuados tanto en los servicios prestados a los clientes como en los
acuerdos de servicio firmados con proveedores internos y externos.
Implemente el Plan de Seguridad.
Monitorice y evalúe el cumplimiento de dicho plan.
Supervise proactivamente los niveles de seguridad analizando tendencias,
nuevos riesgos y vulnerabilidades.
Realice periódicamente auditorías de seguridad.
Por su parte, dentro de la política de seguridad, es imprescindible disponer de un
marco general en el que incluir todos los subprocesos asociados a la Gestión de la
Seguridad. Su complejidad e enredadas interrelaciones necesitan de una política
global clara en donde se fijen aspectos tales como los objetivos, responsabilidades
y recursos.
En particular la Política de Seguridad debe determinar:
La relación con la política general del negocio.
205
La coordinación con los otros procesos TI.
Los protocolos de acceso a la información.
Los procedimientos de análisis de riesgos.
Los programas de formación.
El nivel de monitorización de la seguridad.
Qué informes deben ser emitidos periódicamente.
El alcance del Plan de Seguridad.
La estructura y responsables del proceso de Gestión de la Seguridad.
Los procesos y procedimientos empleados.
Los responsables de cada subproceso.
Los auditores externos e internos de seguridad.
Los recursos necesarios: software, hardware y personal.
Asimismo, el objetivo del Plan de Seguridad es fijar los niveles de seguridad que
han de ser incluidos como parte de los SLAs, OLAs y UCs. Este plan ha de ser
desarrollado en colaboración con la Gestión de Niveles de Servicio que es la
responsable en última instancia tanto de la calidad del servicio prestado a los
clientes como la del servicio recibido por la propia organización TI y los
proveedores externos.
El Plan de Seguridad debe diseñarse para ofrecer un mejor y más seguro servicio
al cliente y nunca como un obstáculo para el desarrollo de sus actividades de
negocio. Siempre que sea posible deben definirse métricas e indicadores clave
que permitan evaluar los niveles de seguridad acordados.
Un aspecto esencial a tener en cuenta es el establecimiento de unos protocolos de
seguridad coherentes en todas las fases del servicio y para todos los estamentos
implicados. "Una cadena es tan resistente como el más débil de sus eslabones",
por lo que carece de sentido, por ejemplo, establecer una estrictas normas de
acceso si una aplicación tiene vulnerabilidades frente a inyecciones de SQL. Quizá
206
con ello podamos engañar a algún cliente durante algún tiempo ofreciendo la
imagen de "fortaleza" pero esto valdrá de poco si alguien descubre que la "puerta
de atrás está abierta".
No obstante, por muy buena que sea la planificación de la seguridad resultará
inútil si las medidas previstas no se ponen en práctica. Es responsabilidad de la
Gestión de Seguridad coordinar la implementación de los protocolos y medidas de
seguridad establecidas en la Política y el Plan de Seguridad.
Por ende, en primer lugar la Gestión de la Seguridad debe verificar que:
El personal conoce y acepta las medidas de seguridad establecidas así
como sus responsabilidades al respecto.
Los empleados firmen los acuerdos de confidencialidad correspondientes a
su cargo y responsabilidad.
Se imparte la formación pertinente.
Es también responsabilidad directa de la Gestión de la Seguridad:
Asignar los recursos necesarios.
Generar la documentación de referencia necesaria.
Colaborar con el Service Desk y la Gestión de Incidentes en el tratamiento y
resolución de incidentes relacionados con la seguridad.
Instalar y mantener las herramientas de hardware y software necesarias
para garantizar la seguridad.
Colaborar con la Gestión de Cambios y Versiones para asegurar que no se
introducen nuevas vulnerabilidades en los sistemas en producción o
entornos de pruebas.
Proponer RFCs a la Gestión de Cambios que aumenten los niveles de
seguridad.
Colaborar con la Gestión de la Continuidad del Servicio para asegurar que
no peligra la integridad y confidencialidad de los datos en caso de desastre.
207
Establecer las políticas y protocolos de acceso a la información.
Monitorear las redes y servicios en red para detectar intrusiones y ataques.
Es necesario que la gestión de la empresa reconozca la autoridad de la Gestión
de la Seguridad, respecto a todas estas cuestiones y que incluso permita que ésta
proponga medidas disciplinarias vinculantes cuando los empleados u otro personal
relacionado con la seguridad de los servicios incumplan con sus
responsabilidades.
Sin embargo, para evaluar estos procesos, no es posible mejorar aquello que no
se conoce, es por lo tanto indispensable evaluar el cumplimiento de las medidas
de seguridad, sus resultados y el cumplimiento de los SLAs. Aunque no es
imprescindible, es recomendable que estas evaluaciones se complementen con
auditorías de seguridad externas y/o internas realizadas por personal
independiente de la Gestión de la Seguridad.
Estas evaluaciones/auditorias deben valorar el rendimiento del proceso y proponer
mejoras que se plasmaran en RFCs que habrán de ser evaluados por la Gestión
de Cambios. Independientemente de estas evaluaciones de carácter periódico se
deberán generar informes independientes cada vez que ocurra algún incidente
grave relacionado con la seguridad. De nuevo, si la Gestión de la Seguridad lo
considera oportuno, estos informes se acompañaran de las RFCs
correspondientes.
En cuanto el mantenimiento, la Gestión de la Seguridad es un proceso continúo y
se han de mantener al día el Plan de Seguridad y las secciones de seguridad de
los SLAs. Los cambios en el Plan de Seguridad y los SLAs pueden ser resultados
de la evaluación arriba citada o de cambios implementados en la infraestructura o
servicios TI. Así, no hay nada más peligroso que la falsa sensación de seguridad
que ofrecen medidas de seguridad obsoletas.
208
Es asimismo importante que la Gestión de la Seguridad esté al día en lo que
respecta a nuevos riesgos y vulnerabilidades frente a virus, spyware, ataques de
denegación de servicio, etcétera, y que adopte las medidas necesarias de
actualización de equipos de hardware y software, sin olvidar el apartado de
formación: el factor humano es normalmente el eslabón más débil de la cadena.
Por otra parte, en el control del proceso, al igual que en el resto de procesos TI es
necesario realizar un riguroso control del proceso para asegurar que la Gestión de
la Seguridad cumple sus objetivos. Una buena Gestión de la Seguridad debe
traducirse en una:
Disminución del número de incidentes relacionados con la seguridad.
Un acceso eficiente a la información por el personal autorizado.
Gestión proactiva que permita identificar vulnerabilidades potenciales antes
de que estas se manifiesten y provoquen una seria degradación de la
calidad del servicio.
La correcta elaboración de informes permite evaluar el rendimiento de la
Gestión de Seguridad y aporta información de vital importancia a otras
áreas de la infraestructura TI.
Entre la documentación generada cabría destacar:
Informes sobre el cumplimiento, en lo todo lo referente al apartado de
seguridad, de los SLAs, OLAs y UCs en vigor.
Relación de incidentes relacionados con la seguridad, calificados por su
impacto sobre la calidad del servicio.
Evaluación de los programas de formación impartidos y sus resultados.
Identificación de nuevos peligros y vulnerabilidades a las que se enfrenta la
infraestructura TI.
Auditorías de seguridad.
Informes sobre el grado de implementación y cumplimiento de los planes de
seguridad establecidos.
209
Así, como caso práctico, cabe resaltar, la gestión de "Cater Matters" es consciente
que un enfoque sobre la seguridad basado exclusivamente en el concepto de
"fortificación frente a ataques" no se corresponde con las necesidades de negocio.
Es importante que los clientes de "Cater Matters" tengan acceso a información
actualizada sobre sus pedidos, pagos pendientes, etcétera y eso requiere la
interacción con el ERP de la empresa.
Esto, obviamente, presenta algunos problemas de seguridad adicionales pues han
de abrirse canales al exterior desde el núcleo TI de la organización. La dirección
de "Cater Matters" ha decidido crear una serie de Web Services que permitan el
acceso a dicha información preservando su confidencialidad e integridad. Esto
requiere la revisión del Plan de Seguridad y las secciones de seguridad de los
SLAs en vigor.
Como medidas de seguridad básicas:
Se limitan los rangos de IPs que pueden acceder al servicio. Sólo IPs
autorizadas de clientes podrán disponer del servicio.
Se implementan protocolos de encriptación de los archivos XML
intercambiados.
Se requiere autenticación para el acceso al servicio.
Se monitoriza la interacción con la aplicación para detectar posibles
ataques externos.
Se guarda un registro de uso: quién, cuándo y cómo utilizó la aplicación.
Se autoriza un solo canal de entrada a los servidores locales a través de los
servidores web de la empresa.
Finalmente, se propone una evaluación periódica del servicio con el objetivo de
detectar vulnerabilidades y adoptar medidas correctivas. El objetivo es dar un
servicio de calidad y con altos niveles de seguridad que fidelice a los clientes en
210
un tiempo de rápido desarrollo en el que la competencia se encuentra a un "solo
clic de distancia".
211
3.6 Guía de aplicación
Al iniciar el proceso de análisis para la implementación de ITIL en una PYME es
importante que se establezcan los actores que participaran en este proyecto.
En primera medida se cuenta con un Grupo de trabajo el cual será liderado por un
experto o consultor en ITIL y conformado por un líder técnico y representantes de
las diferentes áreas de tecnología de la organización, los cuales tendrán a su
cargo la conformación oficial del proyecto al interior de la compañía, para esto se
aconseja matricular el proyecto siguiendo alguno de los estándares ya conocidos
para proyectos (Creando cronogramas, asignando tareas, identificando riesgos,
etc.)
El segundo actor que encontramos está conformado por la alta gerencia que está
encargado de fomentar y dar su apoyo al proceso de análisis e implementación de
ITIL al interior de la organización.
La gerencia aparte de impulsar la apropiación de ITIL en la Organización debe en
conjunto con el líder o consultor establecer los objetivos finales de la
implementación para el negocio, buscando que la tecnología sea un medio para el
sustento y apoyo de la PYME más no el fin de esta.
Para esto se deben evaluar los procesos de tecnología de la compañía que están
directamente ligados a las unidades de negocio, y establecer el grado de
influencia de la infraestructura de TI y trabajar sobre estas unidades, ya que es en
estas donde la aplicación de ITIL traerá mayores beneficios. La gerencia debe
tener claro si los procesos de su negocio son modernos y tecnificados, ya que esto
determina una alta dependencia de servicios de tecnología, mientras que una
compañía con procesos manuales no tendrá tanta dependencia de TI.
212
Primera parte: El análisis.
Una vez establecidos los objetivos de la implementación de ITIL y las diferentes
áreas de negocio sobre las que se trabajará, se debe revisar el estado de las
diferentes gestiones de servicio de ITIL al interior de la organización, incluso si
ninguno de los miembros de la PYME ha escuchado en el pasado sobre ITIL, se
debe entender que al ser ITIL una recopilación de las mejores prácticas, las
organizaciones tendrán muchas de estas ya aplicadas y esto es un indicador
natural de la importancia que ésta gestión tiene para la empresa.
Como inicio del análisis se estableció un sistema de seguimiento de estas
gestiones evaluando por puntos su desarrollo e importancia, esto le permitirá al
experto y su grupo establecer el enfoque a seguir y cuáles son las gestiones a
reforzar en el desarrollo de la implementación de ITIL. Es importante el recordar
que al tratarse de la primer implementación en una PYME y que se cuentan con
recursos limitados, se deben reforzar las gestiones más importantes dejando en
un segundo plano las gestiones que pueden tratarse en un segundo proyecto y
que no son significativas para el negocio.
En el anexo número A se puede ver el detalle del formato utilizado para aplicar
esta primera parte del análisis.
En la segunda parte del análisis se trata a profundidad cada una de las gestiones
que sobresalieron en la primera parte del análisis a partir de aplicar una segunda
serie de encuestas (Anexo B) que va enfocada a determinar el estado real de cada
gestión para que el experto y su grupo conozcan el cumplimiento de la gestión con
la PYME y sepan exactamente cuáles son los cambios que deben implementarse,
esto permite reducir costos y tiempos durante la implementación.
Para la correcta aplicación de la segunda parte del análisis debe aplicarse los
formatos de guía a cada uno de los actores que participe en el proceso que
interviene en la gestión que se está evaluando. En este caso se le recomienda al
213
asesor de ITIL que aplique las encuestas guías mediante entrevista, de ser posible
las documente y tome nota de las inquietudes que se generen y que por las
particularidades de la organización se salgan del contexto de la guía.
Segunda parte: El diagnostico.
Al analizar la información recolectada tendremos como resultado:
Las gestiones que son más importantes para el negocio de la PYME
El nivel de aplicación actual de cada una de las gestiones en los procesos
de la empresa
Las fallas o falencias de las gestiones más importantes.
Esto nos permite conocer el estado actual de la empresa y del las áreas de TI,
mostrando a donde apuntan sus gestiones.
El resultado de este diagnostico le permitirá al especialista de ITIL y su grupo de
trabajo, crear un plan de trabajo estratégico con los pasos para aplicar las mejoras
a cada uno de los procesos en base a la apropiación de las gestiones de servicio
de ITIL.
Cuando se contextualice el plan estratégico de trabajo se debe tener en cuenta los
objetivos iniciales establecidos por la gerencia, así como los lineamientos
establecidos por la empresa.
Tercera parte: Implementación.
La implementación se realiza a través de la puesta en marcha del plan de trabajo
estratégico. Se recomienda que la apropiación de ITIL se realice gestión por
gestión y que cada una se maneje como un proyecto de pequeña escala.
214
La documentación es de vital importancia, y tanto el especialista de ITIL y su
grupo de trabajan, deben dejar evidencia de todos los procesos realizados,
teniendo en cuenta que la mayoría de gestiones interactúan entre ellas y es de
esperar que durante la apropiación se modifiquen varias veces el mismo proceso
hasta dejarlo relacionado de una forma óptima y coherente con todas las
gestiones.
Como ya se mencionó, los recursos físicos, económicos y humanos de las PYMES
son limitados, por lo cual no se debe invertir ninguno de estos recursos en la
apropiación de una gestión de ITIL que no redundara en un beneficio a la PYME.
ITIL es una guía flexible que se acomoda a las necesidades de la organización y
que en ningún momento se debe interpretar como obligatoria.
Recomendaciones:
Reuniones periódicas con los involucrados en los procesos y presentación de
informe de avance a la gerencia.
Monitorear los cambios en los procesos, establecer guías y procesos de
contingencia
Hacer partícipe a las áreas relacionadas con los procesos a cambiar para que
estén al tanto de los cambios implementados.
215
3.7 Propuesta y recomendaciones a Punto de servicios S. A
3.7.1 Recomendaciones por cada gestión analizada
3.7.1.1 Centro de servicios
Coordinador de centro de servicio: Se debe establecer un coordinador quien debe
hacer seguimiento y establecer métricas para medir el centro de servicios y su
calidad y eficiencia generando una mejor atención al cliente que impacte en un
mayor grado de satisfacción y fidelización del mismo.
El centro de servicios debe registrar en el sistema todos los casos que lleguen a
punto de servicios sin importar que sea solucionado en el primer nivel, esto
ayudara a incrementar el nivel de cumplimiento de los SLA.
Sondear a los clientes para poder establecer el problema real y hacer registro de
éste en la orden de servicio ingresada al sistema.
A partir del sondeo realizado al usuario, el centro de servicio debe establecer la
urgencia y nivel de prioridad del incidente, este debe quedar registrado en sistema
y se le debe dar aviso al usuario del tiempo de respuesta según el SLA.
El centro de servicio debe dar un soporte de primer nivel donde establezca si la
falla se debe a problemas de configuración y de ser posible resolverlos en el
mismo instante, hacer registro en el sistema y cerrar el caso como atendido.
Se deben establecer guiones de atención al usuario según el servicio presentado
(presencial o telefónico).
Informar a los clientes de los beneficios de este nuevo servicio de atención y
soporte.
216
Todas las llamadas que lleguen a PUNTO DE SERVICIO por gestión de incidentes
deben ingresar inicialmente al centro de servicios ya que este debe ser el único
punto de contacto con el cliente.
Mantener informados a los usuarios acerca de las inconsistencias presentadas en
la atención del servicio, las cuales generan retraso en la solución de la misma.
Conocer los check list técnicos para la atención de usuarios en primer nivel, estos
debe ser proporcionado por el área técnica.
Contar con un administrador para la herramienta de registro de incidentes que
permita adaptar el sistema a las necesidades de la mesa de servicio.
Tener rápido acceso a las bases de conocimiento para ofrecer un mejor servicio a
los usuarios de primer nivel.
Figura 51: Nuevo Proceso de centro de servicios
217
3.7.1.2 Gestión de incidentes
Crear una base de datos de conocimiento (knowledge database) para registrar
cada uno de los problemas presentados y sus posibles soluciones.
El coordinador de línea debe asignar la persona idónea para resolver cada uno de
los incidentes escalados por el centro de servicios.
Se debe adquirir o modificar el sistema actual del registro de incidentes para que
cada uno de los técnicos pueda visualizar el SLA establecido.
El coordinador debe realizar el seguimiento a cada uno de los SLA para cada
incidente.
Se debe establecer métricas y parámetros para la medición de la productividad de
cada una de las áreas de soporte, se debe tener en cuenta:
Número de incidentes abiertos
Número de incidentes cerrados
Técnico al que se le asignó el incidente.
Cumplimiento con el SLA
Nivel de satisfacción
Seguimiento a los casos reincidentes
Marcación del caso reincidente
Tener en cuenta que los informes deben ser generados con una periocidad
mensual.
Una vez analizada la información en cada informe se debe establecer métricas
para la generación de planes de mejoramiento continuo.
218
Se debe establecer la capacidad de respuesta de cada uno de los técnicos y de
sus habilidades, para establecer las cargas operativas de cada colaborador.
Los técnicos deben registrar en las CMDB el problema presentado y realizar el
registro de solución.
Todo técnico debe consultar en la CMDB la posible solución al problema que está
intentando solucionar, de esta forma se agiliza el tiempo de respuesta a cada
caso.
Crear un informe a nivel de coordinación en donde mida el nivel de ocupación de
los técnicos y así determinar la capacidad de productividad y de respuesta.
El técnico debe actualizar en el sistema cada cambio del caso para que se pueda
consultar por la mesa de servicio cuando sea necesario.
219
Figura 52: Nuevo proceso para gestión de incidentes
220
3.7.1.3 Gestión de las configuraciones.
Crear una base de datos de configuraciones (CMDB) en donde se llevará el
registro de cada uno de los activos de la empresa tales como repuestos,
hardware, dispositivos, etc, en uso y en stock.
Tener un amplio conocimiento de los elementos de configuración de cada una de
las organizaciones a las que “Puntos de Servicios” les presta el servicio de
soporte.
Actualizar la CMDB a medida que sus elementos son utilizados o actualizados
para responder al servicio.
Generar una adecuada interacción entre los elementos de la CMDB de “Punto de
Servicios” con los elementos que se conocen de las empresas a las que le prestan
el soporte.
Realizar trimestralmente auditorias para asegurar que la información registrada en
la CMDB coincida con la configuración real de los servicios de la organización.
Elaborar informes de las auditorías realizadas.
Asignar un responsable “coordinadores de línea” que actualice las CMDB cada
vez que ésta cambie.
Adquirir un nuevo software o modificar el existente para ingresar toda la
información en la CMDB.
Generar un indicador mensual en donde se reflejen las entradas y salidas de los
elementos en la CMDB
221
3.7.1.4 Gestión Niveles de Servicio.
Deben ofrecer los servicios de forma clara y entendible para los clientes, estos
deben estar Propuestos de forma realista y ajustada a la capacidad de Centro de
Servicios, centrados en el cliente y su servicio y no en la tecnología.
Dejarle claro a todo cliente los términos del servicio a prestar, desde la apertura
del incidente para evitar mal entendidos con los usuarios por las características y
calidad de los servicios.
Se debe establecer acuerdos con los proveedores y fabricantes en busca de
mejorar los tiempos de respuesta para los usuarios, esta labor desde estar
apoyada por la gerencia y dirigida por la parte comercial.
Se debe establecer los indicadores claves para los tiempos de respuesta de los
servicios.
Se debe monitorear la calidad de los servicios y los tiempos de respuesta
acordados con los usuarios, con el objetivo de mejorarlos a un costo aceptable
para PS.
La monitorización de los servicios se debe realizar a partir de la gestión de soporte
incidentes, con el cumplimiento de los SLA, y las encuestas de satisfacción.
Se debe establecer procesos para los casos en que se incumplan los tiempos
acordados en los SLA y la forma en que se le divulgue al usuario.
Capacitar correctamente la fuerza comercial para evitar acuerdos errados con
proveedores y contratistas.
222
Informar al personal de mesa de servicios sobre toda la documentación para que
transmitan la información pertinente a cada cliente.
Todos los procesos que se describan deben ser documentados y necesariamente
establecer su nivel de privacidad, es decir, si la publicación es de carácter interno
o externo.
Definir los SLA de la siguiente manera:
Describir los aspectos más generales hasta los detalles específicos del
servicio.
Estructurar todo acuerdo documentalmente en forma individual.
Generar informes que determinen el cumplimiento de los SLA con la información
detallada de frecuencia e impacto de los incidentes responsables.
Generar informes que determinen el cumplimiento de los proveedores.
223
Figura 53: Nuevo proceso para validación de cumplimiento de los SLA
224
3.7.2 Matrices de proceso ITIL para PUNTO DE SERVICIOS
Matriz Comparativa para la gestión Centro de Servicios
ITIL Punto de Servicio Modificación para punto según ITIL Beneficios
Los miembros del centro de servicio tienen claras sus funciones,
SI (Cumple con las definiciones de ITIL
Los miembros del centro de servicio tienen claras sus funciones,
Existe un responsable de monitorear el centro de servicio,
No, como tal no existe un encargado de esta tarea por lo cual no se monitorea el área encargada de hacer las funciones de un centro de servicio,
Se debe asignar esta tarea, se recomienda asignarla a uno de los coordinadores de línea con menos carga operativa,
Al contar con un responsable de monitorear el CS se pueden comenzar la gestión de medir y supervisar el CS para crear planes de cambios y corregir errores del área
Se determina qué perfiles profesionales poseerán sus integrantes.
No existe un Proceso de selección con un perfil determinado para la contratación de cargos de los integrantes del SC
Se debe definir con el Coordinador encargado del SC, el área de selección y las directivas el perfil que deben tener los miembros del SC, se recomienda un perfil técnico profesional en sistemas,
Se crea un estándar que facilite al área de selección el personal más indicado para el cargo, y su posterior capacitación
Se Establecen estrictos protocolos de interacción con el cliente.
No, ni existe un proceso alternativo que supla esta necesidad,
Se deben establecer estrictos protocolos de interacción con el cliente.
Se mejora la imagen del área y la organización, los clientes se sienten bien atendidos con todos los asesores del SC
Los miembros del centro de servicio Informan a los clientes de los beneficios de este nuevo servicio de atención y soporte.
No, ni existe un proceso alternativo que supla esta necesidad,
Los miembros del centro de servicio deben Informar a los clientes de los beneficios de este nuevo servicio de atención y soporte.
Pro actividad del área y apoyo comercial
Los miembros del centro de servicio Sondean a los clientes para conocer mejor sus expectativas y necesidades.
Se realiza una serie de preguntas dependiendo los síntomas del problema y la experiencia de cada miembro del SC
Se debe crear una lista de checklist estándar para apoyar esta labor evitando que la experiencia sea un factor decisivo en la gestión y atención del personal del SC
Esta información permite crear mejores planes comerciales que apoyen los objetivos de la empresa
El centro de servicio es accesible para los clientes?
El Centro de servicio se encuentra en la sede principal y abre únicamente en horarios de oficina, telefónicamente solo atiende una persona, lo cual dificulta el contacto telefónico
Todo el personal del SC debe estar en capacidad de realizar la atención telefónica, es recomendable que a futuro se cuente con una opción Web para consultas de casos en todo horario,
Agilidad en la atención de usuarios, mayor nivel de servicio
225
Procura ofrecer un servicio de calidad consistente y homogénea.
Se realizan encuestas de satisfacción al cliente para mantener un buen servicio,
Se debe trabajar constantemente en los planes de acción como resultado a las encuestas realizadas,
Los clientes pueden percibir los cambios de la empresa lo cual genera fidelizacion
Disponer de herramientas de software que les permitan llevar un registro de la interacción con los usuarios.
Se dispone de una herramienta para crear incidentes y hacer control y monitoreo sobre ellos
Sin cambios
Mantenga puntualmente informados a los usuarios y lleve un registro de toda la interacción con los mismos.
Solo se crea el incidente en el sistema, no se vuelve a tener contacto hasta que se acerca el cliente a reclamar su equipo,
Todas las actividades realizadas para solucionar los incidentes debe detallarse en la aplicación que se usa para su control y una vez solucionado el caso o si se presenta alguna anomalía o incumplimiento debe hacerse una comunicación con el usuario para notificarlo
Mantener a los usuarios informados, hace que la compañía se vea más profesional, competitiva y se muestre comprometida con los clientes y sus soluciones. Un adecuado registró permite identificar los problemas en la solución de incidentes
Los miembros del CS conocen todos los protocolos de interacción con el cliente: guiones, checklists,...
No existen estos protocolos Deben crearse y documentarse de tal forma que estén disponibles para los miembros nuevos y antiguos del SC
Permite que la migración de conocimiento al nuevo personal más rápido
Registro y monitorización de cada incidente, los integrantes están en capacidad de saber cuándo se debe realizar un escalado a instancias superiores o entrar en discusiones sobre cumplimiento de SLAs.
Todos los casos que se ingresan al sistema son escalados, los casos que se resuelven de inmediato con el usuario no se ingresan al sistema, no se tienen SLA
Se deben ingresar al sistema todos los casos, solo se escalan los que no son solucionados, se debe trabajar en la creación de SLA y capacitar a los integrantes del SC en su correcto uso y aplicación
La creación de SLA permite medir a las áreas y establecer acuerdos para trabajar con los clientes
Tener rápido acceso a las bases de conocimiento para ofrecer un mejor servicio a los usuarios.
No existen BD de conocimiento
Se deben crear, y alimentar para tener rápido acceso a las bases de conocimiento para ofrecer un mejor servicio a los usuarios.
esto permite que las áreas de soporte trabajen más rápido y se agilicen los tiempos de respuesta para los usuarios
Recibir formación sobre los productos y servicios de la empresa.
Los integrantes del SC tienen amplios conocimientos sobre esto,
No cambia, pero debe actualizarse a medida que lo haga el negocio,
Cierre del incidente y confirmación con el cliente
No se hace, a pesar de que el caso se considera atendido (Cerrado) no se hace confirmación con el cliente (Proceso incompleto)
a todos los casos atendidos se les debe dar una marcación de cierre y confirmación con el cliente
Con esto se mejora el servicio al cliente, se genera fidelidad y se liberan equipos de bodega
226
Hacer un seguimiento de cerca de los servicios prestados y su eficacia y rendimiento.
No se hace, ni existe un proceso alternativo
Hacer un seguimiento de cerca de los servicios prestados y su eficacia y rendimiento.
Se mejora el servicio y se hace más competitivo
El encargado del centro de servicios diseña las métricas que permiten determinarán el rendimiento del Centro de Servicios.
No se hace por qué no se tiene un encargado del centro de servicio (No se mide esta área)
El encargado del centro de servicios diseña las métricas que permiten determinarán el rendimiento del Centro de Servicios.
Se puede conocer el rendimiento del SC y crear planes para que este mejore
Se realiza medición del porcentaje de incidentes que se cierran en primera línea de soporte.
No se hace, ni existe un proceso alternativo que permita establecer una medición
Se realiza medición del porcentaje de incidentes que se cierran en primera línea de soporte.
Se conoce la efectividad del SC y qué tipo de servicio se presta
Se realiza medición del porcentaje de consultas respondidas en primera instancia.
No se hace, ni existe un proceso alternativo que permita establecer una medición
Se realiza medición del porcentaje de consultas respondidas en primera instancia.
Se conoce la efectividad de la BC
Se realiza medición del tiempo medio de respuesta a solicitudes cursadas por correo electrónico y teléfono o fax.
No se hace, ni existe un proceso alternativo que permita establecer una medición
Se realiza medición del tiempo medio de respuesta a solicitudes cursadas por correo electrónico y teléfono o fax.
Se realiza análisis estadísticos de los tiempos de resolución de incidentes organizados según su urgencia e impacto.
No se hace. Existe un proceso en donde se revisan los casos que superen el tope máximo establecido por el jefe de línea, pero en estos no se toma encuesta sino el tiempo que esta con el técnico (no el tiempo de espera de repuesto) no se hace clasificación de impacto o urgencia
Se realiza análisis estadísticos de los tiempos de resolución de incidentes organizados según su urgencia e impacto.
Se realiza medición del número de llamadas o servicios gestionados por cada miembro del SC
No se hace, ni existe un proceso alternativo que permita establecer una medición
Se realiza medición del número de llamadas o servicios gestionados por cada miembro del SC
Permite estandarizar el servicio por integrante del SC, para exigir mayor calidad en los mismos
227
Matriz Comparativa para la gestión Gestión de Incidentes
ITIL Punto de Servicio Modificación para punto según ITIL Beneficios
Asignar el personal encargado de restaurar el servicio según se define en el SLA correspondiente
Cada uno de los coordinadores de línea realiza la asignación de casos, por experto y disponibilidad
La asignación se debe realizar según los parámetros que se determinen en los SLA
Se hace clasificación de los incidentes por impacto y urgencia
No se hace, ni existe un concepto que permita determinar qué caso es más importante que otro (Se le da más
importancia a algunos clientes pero no existe un estándar o documentación de
esta práctica)
Se deben clasificar todos los incidentes teniendo en cuenta dos aspectos: Impacto: determina la importancia del incidente dependiendo de cómo éste afecta al negocio y/o del número de usuarios afectados. (Alto, Medio, Bajo) Urgencia: depende del tiempo máximo de demora que acepte el cliente para la resolución y/o el nivel de servicio acordado en el SLA.(Alta, Media, Baja)
Esto permite que se atiendan primero los casos más importantes, se garantiza una
optima utilización del tiempo Establecimiento del nivel de prioridad: dependiendo del impacto y la urgencia se determina, según criterios preestablecidos
No se hace, ni existe un concepto que permita determinar qué caso es más importante que otro (Se le da más
importancia a algunos clientes pero no existe un estándar o documentación de
esta práctica)
Estos criterios deben ser establecidos por los coordinadores de línea y las directivas, se aconseja utilizar una formula de valores para que no se den pie a libre interpretación por los funcionarios del centro de servicio (Ver tabla al final del cuadro)
El Centro de Servicios debe de ser capaz de evaluar si el servicio requerido se incluye en el SLA del cliente y en caso contrario reenviarlo a una autoridad competente.
Esta labor se realiza pero no se deja constancia en el sistema, si el caso es atendido por el centro de servicio, se tampoco se deja constancia en el sistema,
Se debe dejar registro completo de toda la labor y el escalamiento de los incidentes en el sistema
Asignación de número de referencia al incidente se le asignará una referencia que le identificará unívocamente tanto en los procesos internos como en las comunicaciones con el cliente.
Se realiza una asignación de numero de incidente al caso pero solo para control interno
El encargado de atender en la mesa de servicio debe dar el numero de incidente al usuario para su seguimiento,
El usuario puede estar al tanto de su caso, de esta forma se genera seguridad en el cliente
Se han de introducir en el sistema la información básica necesaria para el procesamiento del incidente (hora, descripción del incidente, sistemas afectados...).
Se realiza incluida la descripción física de los recursos afectados
No cambia
228
Si existe la posibilidad de que el incidente afecte a otros usuarios, estos deben ser notificados para que conozcan como esta incidencia puede afectar su trabajo.
No se hace, ni existe una práctica alternativa que supla este proceso
Si existe la posibilidad de que el incidente afecte a otros usuarios, estos deben ser notificados para que conozcan como esta incidencia puede afectar su trabajo.
Genera fidelizacion y confianza con el usuario, se pueden tomar medidas preventivas para minimizar el impacto
Se asigna a cada incidente una categoría que debe estar a su vez subdividida en más niveles dependiendo del tipo de incidente identificando los servicios afectados para el incidente.
Se realiza la clasificación del caso dependiendo la línea, no existen niveles
Es importante realizar una sub clasificación de niveles, los cuales ayudaran a controlar y monitorear las incidencias resueltas por cada área,
Control y monitoreo de problemas por áreas permitiendo generar planes de mejoramiento en donde sea necesario
Cuando el Centro de Servicios no puede resolver el incidente designara al personal de soporte técnico responsable de su resolución (segundo nivel).
Si se realiza. El escalamiento se hace a los coordinadores de línea
Cuando el Centro de Servicios no puede resolver el incidente escalara el caso al coordinador de línea de soporte técnico responsable de su resolución (segundo nivel).
Incorpora el proceso de resolución a la Base de conocimientos
No se hace por que no existe BC Incorpora el proceso de resolución a la Base de conocimientos
Con la BC se gana tiempo en la atención de casos
Reclasificar el incidente si fuera necesario.
No se hace, dado que no se generan estadísticas no se toma encuesta la
clasificación de incidentes Reclasifica el incidente si fuera necesario.
le permite a la organización conocer que tipos de incidentes resuelve y como prepararse para atenderlos de forma eficiente
Actualiza la información en la CMDB sobre los elementos implicados en la solución del incidente.
No se hace, no existe CMDB Actualiza la información en la CMDB sobre los elementos implicados en la solución del incidente.
Para atender los incidentes de forma eficiente y rápida es necesario conocer los elementos que se usan para su atención.
Cierra el incidente cuando se confirme con el usuario que el caso quedo resuelto de forma satisfactoria
No existe como tal un proceso de cierre, solo se considera atendido
Cierra el incidente cuan do se confirme con el usuario que el caso quedo resuelto de forma satisfactoria
Permite diferenciar el estado de un incidente al momento de generar estadísticas
Los clientes disponen de información puntual sobre los niveles de cumplimiento de los SLAs y que se adopten medidas correctivas en caso de incumplimiento.
No se hace, no existen SLA
Los clientes disponen de información puntual sobre los niveles de cumplimiento de los SLAs y que se adopten medidas correctivas en caso de incumplimiento.
Da seguridad a los clientes, los SLA sirven para el proceso comercial de contratación y permite mostrar a la organización mas competitiva.
Disponer de Información Estadística que puede ser utilizada para hacer proyecciones futuras, medición del servicio de la gestión de incidentes y acciones correctivas
Solo se revisa la cantidad de casos atendidos por usuario
Se debe generar Información Estadística de los casos atendidos en un periodo de tiempo donde se pueda analizar el servicio de la gestión de incidentes, se recomienda que se haga mensualmente
A través de la generación de informes que midan los indicadores establecidos, se puede determinar el estado actual de cumplimiento de cada servicio o proceso
229
Generar periódicamente información sobre número de incidentes clasificados temporalmente y por prioridades.
No se hace, Solo se generan estadística por tiempo de atención del técnico
Generar periódicamente información sobre número de incidentes clasificados temporalmente y por prioridades.
de atención, a través de esta información se puede determinar en donde están las
falencias o problemas que impidan el cumplimiento del servicio o las
debilidades del mismo, de esta forma se pueden desarrollar planes de
mejoramiento para fortalecer o corregir los problemas
Generar periódicamente información sobre tiempos de resolución clasificados en función del impacto y la urgencia de los incidentes.
No se hace, Solo se generan estadística por tiempo de atención del técnico
Generar periódicamente información sobre tiempos de resolución clasificados en función del impacto y la urgencia de los incidentes.
Generar periódicamente información sobre nivel de cumplimiento de los SLA.
No se hace, Solo se generan estadística por tiempo de atención del técnico
Generar periódicamente información sobre nivel de cumplimiento de los SLA.
Generar periódicamente información sobre porcentaje de incidentes, clasificados por prioridades, resueltos en primera instancia por el Centro de Servicios.
No se hace, Solo se generan estadística por tiempo de atención del técnico. No se genera información del centro de servicio
Generar periódicamente información sobre porcentaje de incidentes, clasificados por prioridades, resueltos en primera instancia por el Centro de Servicios.
Generar periódicamente información sobre grado de satisfacción del cliente.
Punto realiza encuesta a los usuario en el momento que recogen sus equipo
Se recomienda que la encuesta se haga 5 días después de cerrado el caso, para que el usuario tenga tiempo de evaluar la calidad de la solución,
230
Matriz Comparativa para la gestión Gestión de Niveles de Servicio
ITIL Punto de Servicio Modificación para punto según ITIL Beneficios
Se tienen establecidos los servicios que se ofrecen a los clientes?
Se tienen establecidos los servicios que se ofrecen a los clientes
No cambia
el negocio entiende cuáles son las necesidades de los clientes?
el negocio entiende cuáles son las necesidades de los clientes
No cambia
Establecer listado de los recursos necesarios para proveer los servicios propuestos con los niveles de calidad acordados
Solo Existe un Inventario de Hardware
Se debe Establecer listado de los todo los recursos necesarios para proveer los servicios propuestos con los niveles de calidad acordados (Software, Hardware, Humano)
Permite crear planes de respuesta que sean eficientes, cumplirles y aplicados a la realidad del negocio, reducción de costos, mejor utilización de los recursos
Se deben establecer niveles de servicio. No se tienen Se deben establecer niveles del servicio. (Alta, media, baja) Permite asignar los recursos adecuados
a cada incidente según su importancia real para el negocio y el cliente Se deben establecer tiempos y
procedimientos para niveles del servicio. No se tienen
Se debe establecer un tiempo para cada nivel de servicio,
Se deben crear OLAs (Acuerdos de Nivel de Operación) documentos de carácter interno de la propia organización en donde se detalla la prestación del servicio (transparente para el cliente)
No se tienen establecidos
Se deben crear OLAs (Acuerdos de Nivel de Operación) documentos de carácter interno de la propia organización en donde se detalla la prestación del servicio (transparente para el cliente)
Pronta recuperación ante afectación de los recursos físicos, lógicos o humanos de la organización
Se deben establecer Contratos de Soporte (UCs) donde se determinen las responsabilidades de los proveedores externos en el proceso de prestación de servicios.
En este momento no aplica, pues no se da manejo de contrato permanente a
proveedores
Se debe tener en cuenta este proceso definido por ITIL para futuras intervenciones,
Permite la administración y control sobre el trabajo de los proveedores
Se deben crear informes de rendimiento que evalúen el cumplimiento de los SLAs, con información sobre la frecuencia y el impacto de los incidentes responsables de la degradación del servicio.
No se generan dado que no existen SLA
Se deben crear informes de rendimiento que evalúen el cumplimiento de los SLAs, con información sobre la frecuencia y el impacto de los incidentes responsables de la degradación del servicio.
A través de la generación de informes que midan los indicadores establecidos, se puede determinar el estado actual de cumplimiento de cada servicio o proceso de atención, a través de esta información se puede determinar en donde están las
falencias o problemas que impidan el cumplimiento del servicio o las
Se deben crear informes sobre las quejas, justificadas o no, de los clientes,
Se genera un informe mensual de cantidad de quejas presentadas por los usuarios, pero no se hace profundidad
sobre este
Se deben crear informes sobre las quejas, justificadas o no, de los clientes,
231
Se deben crear informes de rendimiento que evalúen los tiempos de respuesta.
No se realiza, tan solo se revisa que los técnicos no tengan los casos más de 10
días, pero no se evalúa ningún otro aspecto
Se deben crear informes de rendimiento que evalúen los tiempos de respuesta.
debilidades del mismo, de esta forma se pueden desarrollar planes de
mejoramiento para fortalecer o corregir los problemas
Se deben crear informes de rendimiento que evalúen la calidad del servicio de los proveedores externos
No se mide el proveedor encargado de reparar impresoras
Se deben crear informes de rendimiento que evalúen la calidad del servicio de los proveedores externos
Se deben crear informes de rendimiento que evalúen el rendimiento y capacitación del personal involucrado.
No se generan dado que no existen SLA Se deben crear informes de rendimiento que evalúen el rendimiento y capacitación del personal involucrado.
Se deben crear informes que evalúen el Cumplimiento de los OLAs y UCs relacionados.
No se realiza, ni se tiene algún proceso parecido
Se deben crear informes que evalúen el Cumplimiento de los OLAs y UCs relacionados.
Se establecen indicadores clave de rendimiento para los servicios prestados
No se realiza para ningún nivel Se deben establecer los indicadores tal como se detalla en las recomendaciones de la gestión de incidentes y C de Servicio
Percepción del cliente y usuarios sobre la calidad de servicio.
Se realiza encuesta de satisfacción al cliente
En la encuesta se deben incluir los puntos críticos que se miden dentro de las áreas pero desde la perspectiva del cliente
232
Matriz Comparativa para la gestión Gestión de Configuraciones
ITIL Punto de Servicio Modificación para punto según ITIL Beneficios
Se requiere la creación de una base de conocimiento
No existe, se guarda información en correos electrónicos o manuales
impresos, pero no se tiene un control sobre la información, ni todos los
usuarios tienen acceso a ella
Punto requiere generar una base de conocimiento los cuales permitan estables normas sobre el proceso de servicio, control de cambios y rápida gestión de Incidentes
A través de la generación de informes que midan los indicadores establecidos, se puede determinar el estado actual de
cumplimiento de cada servicio o proceso de atención, a través de esta información se puede determinar en donde están las
falencias o problemas que impidan el cumplimiento del servicio o las debilidades
del mismo, de esta forma se pueden desarrollar planes de mejoramiento para
fortalecer o corregir los problemas
Documentación Detallada Sobre la Base de conocimientos
No existe, ni se tiene un proceso alterno
Punto de servicio debe documentar cada caso o incidencia reportada por los clientes, cada caso debe alimentar la base de conocimientos, para centralizar las posibles procesos asociados con la solución de un problema, Esto con fin de monitorizar los acuerdos de niveles de servicio.
Se requiere Generar CI, Ítems de configuración
No existe, ni se tiene un proceso alterno
Los procesos técnico debe ser creados entorno a ítems de configuración, los cuales son parámetros que se deben seguir para la generación soluciones a nivel de infraestructura de IT
Permite tener clasificación de los Items a usar en la organización y de esta forma saber con que se cuenta y como usarlo Se deben Identificar los elementos de
configuración y sus diferentes interrelaciones
No existe, ni se tiene un proceso alterno
Los procesos de servicio de Punto de servicios deben definir los roles de cada elemento de configuración, hardware, software entre otros además de sus interrelaciones. Con esto las soluciones IT tendrán tiempos de respuesta más cercanos a los márgenes establecidos en los Niveles de servicio del cliente.
Se realizan auditorias Punto esquematiza unos controles de
calidad similares a los procesos de auditoría estándar
Se debe generar cronogramas de auditoría que permitan evaluar los indicadores de cumplimiento, además de la evaluación de los acuerdo de servicio con los clientes. Los procesos de calidad deben ser enfocados en la capacitación y la evaluación continua del personal. tiempos de respuesta y conocimientos de las incidencias deben encabezar la medición de los procesos de servicio de Punto de Servicio
Aplicación de Auditorías internas a procesos
233
Informes de Rendimiento Parcialmente desde la creación del
modelo ISO Agosto 2010
Punto de servicios debe generar un plan de informes que informen el estado real de la compañía enfocado al cumplimiento de los niveles de servicio y a los acuerdos de niveles de Servicio.
Se puede determinar en donde están los problemas y retrasos del servicio, el cumplimiento de los acuerdos con los usuarios y crear planes para mejorarlos
Monitorización y Control de cada uno de los Items de la CMDB
No existe, ni se tiene un proceso alterno
Después de crear la CMDB se debe monitorizar para asegurar que todos los componentes autorizados estén correctamente registrados y se conoce su estado actual.
mejor aprovechamiento de los recursos y la inversión financiera
Costos Asociados al Proceso Punto genera una estrategia global de
presupuesto sin discriminar las áreas de servicio
Punto de servicios debe cambiar su estructura de costos, la base de conocimiento genera una clasificación que permite presupuestar costos de solución implementación.
Clasificación y Registro CI No existe, ni se tiene un proceso alterno
Se deben jerarquizar y registrar los diferentes elementos de configuración que intervienen en el proceso de prestación de servicio de Punto de Servicios.
234
3.7.3 Flujos de procesos aplicando ITIL
3.7.3.1 Proceso general de incidencias
PROCESO ACTUAL DE LA EMPRESA NUEVO PROCESO APLICANDO ITIL
Cliente
Atención al cliente
Bodega
Técnico
Coordinador de línea
Se realiza el proceso para
solución de la falla
Usuario reporta falla del equipo
Registro de caso en sistema, ingreso de datos básicos de
usuario, maquina y falla
No
SI
Se puede solucionar la falla sin asistencia
técnica
Se envía el equipo a bodega
Registro en sistema el ingreso y asignación de pin
Se validan los casos ingresados en sistema
El caso tiene técnico asignado
Se hace asignación de técnico
No
Técnico retira equipo de bodega
SI
Registro en sistema, entrega equipo al técnico
Técnico realiza diagnostico de la falla
Se necesitan repuestos
Se hace
reparación
No
Se ingresa al sistema repuesto a solicitar
SI
Se realiza la solicitud al proveedor
Ya llego el repuesto
SI
Se verifica estado de petición
Técnico cambia la parte y registra el cambio en sistema
Se realiza la devolución de la parte defectuosa al proveedor
Se ingresa equipo
de bodega
Se registra el cambio de estado en sistema
y se cambia el pin
Se ubica el equipo en el stand
correspondiente
Reclama equipo
Se entrega equipo
funcionando
SI
No
No
Usuario reporta falla del equipo
Se puede solucionar en la mesa de servicio
Se busca falla en base de conocimiento
Se realiza el proceso para solución de la falla
SI
Se actualiza Base
de Conocimiento
Se entrega equipo
funcionando
Registro de caso en sistema, ingreso de datos básicos de usuario, maquina y falla. Se asigna una urgencia e impacto. El sistema asigna pin y técnico encargado
No
Se envía el equipo a bodega
Registro en sistema del ingreso del equipo a bodega
Técnico retira equipo de bodega
Registro en sistema, entrega equipo al técnico
Técnico realiza
diagnostico de la falla
Se necesitan repuestos
Se ingresa al sistema repuesto a solicitar
SI
Validar en bodega si hay el repuesto
Existe el repuesto
Se hace reparación
SI
No
Se realiza la solicitud al
proveedor
Ya llego el repuesto
SI
Se verifica estado
de petición
Técnico cambia la parte y registra el cambio en sistema
No
Se realiza la devolución de la
parte defectuosa
Actualizar CMDB
Se ingresa equipo de
bodega
Se registra el cambio de estado en sistema
a reparado
Se ubica el equipo en el stand de salida, y se
comunica al usuario
Reclama equipo
SI
No
No
235
Objetivo: Describir el proceso que se sigue desde que se ingresa en sistema una orden de servicio hasta que se entrega el equipo reparado al usuario
PROCESO ACTUAL DE LA EMPRESA NUEVO PROCESO APLICANDO ITIL
PASO ENCARGADO DESCRIPCION INSTRUCCIONES PASO ENCARGADO DESCRIPCION INSTRUCCIONES
1. Cliente Usuario reporta falla del equipo El usuario lleva el equipo a la empresa PUNTO DE SERVICIOS. 1. Cliente Usuario reporta falla del equipo El usuario lleva el equipo a la empresa PUNTO DE SERVICIOS.
2. Atención al cliente ¿Se puede solucionar la falla sin
asistencia técnica?
El personal encargado de la recepción de equipos hace la validación de la falla y determina si es algún inconveniente en la configuración o si es falla de hardware. En caso de poderse solucionar se ejecuta el punto 3, de lo contrario se ejecuta el punto 4.
2. Service Desk Se busca falla en base de
conocimiento
El personal del service desk debe buscar si la falla es conocida o no, es decir si esta falla ya está registrada en sistema (base de conocimiento) para de esta forma seguir el procedimiento adecuado para solución de la falla.
3. Atención al cliente Se realiza el proceso para solución
de la falla
En el caso en que la falla sea de configuración y su solución no necesite asistencia técnica, se hace el proceso de solución y se entrega el equipo funcionando. Este proceso no queda registrado en sistema.
3.
Service Desk Registro en sistema del ingreso
del equipo.
Se realiza en sistema el registro de caso en sistema, se hace el ingreso de datos básicos de usuario, maquina y falla. También se asigna una urgencia e impacto. El sistema automáticamente asigna pin o numero de caso y realiza asignación del técnico encargado de tramitar el caso.
4. Atención al cliente
Registro de caso en sistema, ingreso de datos básicos de
usuario, maquina y falla
En el caso en que la falla no se pueda solucionar inmediatamente o sea problemas de hardware y necesite asistencia técnica, se hace el registro en sistema donde se ingresan los datos personales del usuario (nombre, apellidos, documento, celular, ciudad, email, etc), datos de la maquita (estado físico o cosmético, detalle de cada parte que compone el equipo), y falla reportada por el cliente.
4.
Service Desk ¿Se puede solucionar el caso en
la mesa de servicio?
El personal del Service desk revisa el equipo y hace la validación de la falla, después de hacer la validación en la base de conocimiento se determina si la falla es solucionable desde esta área. En caso de poderse solucionar se ejecuta el punto 5, de lo contrario se ejecuta el punto 7.
5. Atención al cliente /
Bodega Se envía el equipo a bodega Después de registrado en sistema, se envía el equipo a bodega.
5. Service Desk Se realiza reparación
En el caso en que la falla se pueda solucionar en el centro de servicios y no necesite asistencia de los técnicos, se hace el proceso de solución y se entrega el equipo funcionando.
6. Bodega Registro en sistema el ingreso y
asignación de pin En bodega realizan una asignación de pin e ingresan el equipo a un stand mientras se hace la asignación de técnico. Este proceso también queda registrado en sistema.
6. Service Desk Actualizar Base de Conocimiento
Después de reparado el servicio se debe actualizar la base de conocimiento con la información de la falla presentada y la solución dada al inconveniente. Finalmente se procede a realizar el punto 13
7. Coordinador de línea Se validan los casos ingresados
en sistema Diariamente el coordinador de línea (distribuido por marcas) valida las ordenes ingresadas al sistema y el estado en que se encuentran.
7. Service Desk / Bodega Se envía el equipo a bodega Después de registrado en sistema, se envía el equipo a bodega.
8. Coordinador de línea El caso tiene técnico asignado Se valida si el caso tiene o no técnico asignado, en caso de no estar asignado se ejecuta el paso 9 de lo contrario se ejecuta el paso 10.
8. Bodega
Registro en sistema del ingreso del equipo a bodega
En bodega ingresan el equipo a un stand mientras el técnico retira el equipo para su reparación.
9. Coordinador de línea Se hace asignación de técnico Cuando la orden de servicio no se encuentra asignada, se realiza la asignación del técnico que va a dar trámite al daño reportado.
9. Técnico / Bodega Técnico retira equipo de bodega
Los técnicos validan en sistema que ordenes tiene asignada, y posteriormente se dirigen a bodega a retirar el equipo asignado para su respectiva reparación.
10. Técnico / Bodega Técnico retira equipo de bodega Los técnicos validan en sistema que ordenes tiene asignada, y posteriormente se dirigen a bodega a retirar el equipo asignado para su respectiva reparación.
10. Bodega
Registro en sistema de entrega de equipo al técnico
La persona encargada de bodega realiza la entrega del equipo y registra esta entrega en sistema.
11. Técnico Registro en sistema, entrega
equipo al técnico La persona encargada de bodega realiza la entrega del equipo y registra esta entrega en sistema.
11. Técnico
Técnico realiza diagnostico de la falla
El técnico realiza la validación y el diagnostico de la falla presentada por la maquina. En este paso se determina si es necesario cambiarle alguna parte al equipo.
12. Técnico Técnico realiza diagnostico de la
falla El técnico realiza la validación y el diagnostico de la falla presentada por la maquina. En este paso se determina si es necesario cambiarle alguna parte al equipo.
12. Técnico Se necesitan repuestos
En caso de necesitar repuestos se ejecuta el paso 14 de lo contrario se ejecuta el paso 13.
13. Técnico Se necesitan repuestos En caso de necesitar repuestos se ejecuta el paso 15 de lo contrario se ejecuta el paso 14.
13. Técnico Se hace reparación
Se hace la reparación de la maquina y posteriormente se ejecutan los puntos desde el 23 en adelante.
14. Técnico Se hace reparación Se hace la reparación de la maquina y posteriormente se ejecutan los desde el 21 en adelante.
14.
Técnico Validar existencia de repuesto en
bodega
El técnico revisa si el repuesto que necesita se encuentra en la bodega de PUNTO DE SERVICIOS. Es importante que la empresa tenga en STOCK los repuestos más solicitados para realizar la reparación sin solicitar la parte al fabricante agilizar tiempos.
15. Técnico Se ingresa al sistema repuesto a
solicitar En caso de necesitar algún repuesto, se ingresa al sistema la información correspondiente y la parte requerida para el cambio.
15. Técnico Existe el repuesto
En caso de existir el repuesto se ejecuta el paso 16, de lo contrario se procede a ejecutar el punto 17.
16. Coordinador de línea Se realiza la solicitud al proveedor
En el transcurso del día el coordinador de línea hace las validaciones correspondientes en sistema y cuando hay órdenes de servicio con el estado “Pendiente pedido proveedor”, realiza el trámite correspondiente para solicitar el repuesto con el fabricante correspondiente.
16.
Técnico Actualización de CMDB Se debe actualizar la base de datos de configuración con la información de la parte requerida. Posteriormente se procede a ejecutar el punto 13.
17. Coordinador de línea ¿Ya llego el repuesto? El tiempo que dura en llegar el repuesto depende únicamente de la marca pues hay fabricantes que envían la parte en menos días que otro, en caso de haber llegado el repuesto se ejecuta el punto 19, de lo contrario se ejecuta el punto 18.
17. Técnico
Se ingresa al sistema repuesto a solicitar
En caso de necesitar algún repuesto, se ingresa al sistema la información correspondiente y la parte requerida para el cambio.
18. Coordinador de línea Se verifica estado de petición
Si el tiempo límite pasa y no llega el repuesto se hace necesario validar que la orden se halla enviado correctamente y que los datos no estén incorrectos, en caso de encontrar algún error se corrige lo antes posible para que la parte sea enviada. Después se devuelve el punto 16.
18.
Coordinador de línea Se realiza la solicitud al proveedor
En el transcurso del día el coordinador de línea hace las validaciones correspondientes en sistema y cuando hay órdenes de servicio con el estado “Pendiente pedido proveedor”, realiza el trámite correspondiente para solicitar el repuesto con el fabricante correspondiente.
19. Técnico Técnico cambia la parte y registra
el cambio en sistema
Cuando el repuesto llega, se hace la entrega al técnico para que cambie la parte en el equipo y realice el respectivo reporte en sistema, en dicho reporte debe quedar plasmado todo el proceso que se realizo con el equipo, que parte se cambio y el motivo por el cual fue necesario el cambio.
19.
Coordinador de línea ¿Ya llego el repuesto?
El tiempo que dura en llegar el repuesto depende únicamente de la marca y de los tiempos que se hayan establecido para envío de los repuestos. En caso de haber llegado el repuesto se ejecuta el punto 21, de lo contrario se ejecuta el punto 20.
20. Coordinador de línea Se realiza la devolución de la parte
defectuosa al proveedor
Después de haber cambiado la parte defectuosa, el coordinador de línea realiza los trámites correspondientes y trámites legales (en caso necesario) para hacer la devolución de la parte al fabricante en caso que el servicio sea por garantía, pero si la reparación se hizo por facturación, esta parte será entregada al cliente.
20.
Coordinador de línea Se verifica estado de petición
Si el tiempo límite pasa y no llega el repuesto se hace necesario validar que la orden se halla enviado correctamente y que los datos no estén incorrectos, en caso de encontrar algún error se corrige lo antes posible para que la parte sea enviada. Después se devuelve el punto 18.
21. Técnico / Bodega Se ingresa equipo de bodega Finalmente cuando el equipo ya se encuentra reparado, el técnico es el encargado de ingresar el equipo nuevamente a bodega.
21.
Técnico Técnico cambia la parte y registra
el cambio en sistema
Cuando el repuesto llega, se hace la entrega al técnico para que cambie la parte en el equipo y realice el respectivo reporte en sistema, en dicho reporte debe quedar plasmado todo el proceso que se realizo con el equipo, que parte se cambio y el motivo por el cual fue necesario el cambio.
22. Bodega Se registra el cambio de estado en
sistema y se cambia el pin En bodega realizan la actualización del estado en el sistema y le asignan un nuevo pin el cual identifica al equipo como reparado.
22.
Coordinador de línea Se realiza la devolución de la parte
defectuosa.
Después de haber cambiado la parte defectuosa, el coordinador de línea realiza los trámites correspondientes y trámites legales (en caso necesario) para hacer la devolución de la parte al fabricante en caso que el servicio sea por garantía y que se haya solicitado repuesto al proveedor o en caso de haber sacado la parte del stock de la empresa, pero si la reparación se hizo por facturación, esta parte será entregada al cliente.
23. Bodega Se ubica el equipo en el stand
correspondiente Después se archiva en un stand hasta que sea entregado al usuario
23. Técnico / Bodega Se ingresa equipo de bodega
Finalmente cuando el equipo ya se encuentra reparado, el técnico es el encargado de ingresar el equipo nuevamente a bodega.
Proceso general de incidencias
236
24. Cliente ¿Reclama equipo? Si el usuario reclama el equipo, se ejecuta el punto 25 de lo contrario se ejecuta el punto 23.
24. Bodega
Se registra el cambio de estado en sistema a reparado
En bodega realizan la actualización del estado en el sistema y le actualizan el estado del equipo a reparado
25. Atención al cliente /
Cliente Se entrega equipo funcionando
Cuando el usuario reclama el equipo, se hace la actualización en sistema y se cierra el caso.
25. Bodega
Se ubica el equipo en el stand correspondiente
Después se archiva en un stand hasta que sea entregado al usuario. También se realiza comunicación con el usuario para informar que ya puede retirar el equipo.
26. 26.
Cliente ¿Reclama equipo? Si el usuario reclama el equipo, se ejecuta el punto 27 de lo contrario se ejecuta el punto 25.
27. 27. Atención al cliente /
Cliente Se entrega equipo funcionando
Cuando el usuario reclama el equipo, se hace la actualización en sistema y se cierra el caso.
237
3.7.3.2 Proceso para seguimiento a las órdenes de servicio
PROCESO ACTUAL DE LA EMPRESA NUEVO PROCESO APLICANDO ITIL
Coordinador de línea
Técnicos
Ingreso al sistema
Se valida en sistema por marca
Estado de orden “No asignada”
Estado de orden “Pendiente diagnostico”
Estado de orden “Diagnosticada”
Validar tiempo que lleva en ese estado
Supero el límite
Se retroalimenta al técnico
Si
No No
Si
Si
Repuesto solicitado
Validación estado de orden “Pendiente
pedido proveedor”
Validar estado de la solicitud
Se realiza solicitud del repuesto
Si
Se realiza asignación de técnico
Finaliza proceso
No
No
Si
No
Ingreso al sistema
Se valida en sistema por marca
Estado de orden “Pendiente diagnostico”
Estado de orden “Diagnosticada”
Validar tiempo que lleva en ese estado
Supero el límite
Se retroalimenta al técnico
No
Si
Si
Repuesto solicitado
Validación estado de orden “Pendiente
pedido proveedor”
Validar estado de la solicitud
Se realiza solicitud del repuesto
Si
Finaliza proceso
No
No
Si
Validar en bodega que no esté la parte
solicitada
Esta el repuesto en bodega
Se entrega parte al técnico y se cambia el estado de la solicitud
Si
No
No
Actualiza CMDB
238
Proceso para seguimiento a las órdenes de servicio
Objetivo: Realizar seguimiento al estado actual de las órdenes de servicio para asegurar que se gestionen en el tiempo estipulado y en caso de retraso que sea detectado a tiempo y poder conocer cuáles fueron las causales del mismo.
PROCESO ACTUAL DE LA EMPRESA NUEVO PROCESO APLICANDO ITIL
PASO ENCARGADO DESCRIPCION INSTRUCCIONES PASO ENCARGADO DESCRIPCION INSTRUCCIONES
1. Coordinador de línea Ingreso al sistema El usuario ingresa al sistema para extraer la información necesaria para la validación.
1. Coordinador de línea Ingreso al sistema El usuario ingresa al sistema para extraer la información necesaria para la validación.
2. Coordinador de línea Se valida en sistema por marca
Este proceso se inicia cuando el coordinador de línea valida en sistema los casos que aun se encuentran pendientes de gestión y solución. Dicha validación se realiza por marca pues los técnicos se asignan dependiendo la marca que esta reportada. Una vez realizado el filtro por marca se valida el estado de las ordenes registradas en sistema. Existen varios estados +No asignada +Pendiente diagnostico (asignada) +Diagnosticada +Pendiente pedido proveedor
2. Coordinador de línea Se valida en sistema por marca
Este proceso se inicia cuando el coordinador de línea valida en sistema los casos que aun se encuentran pendientes de gestión y solución. Dicha validación se realiza por marca pues los técnicos se asignan dependiendo la marca que esta reportada. Una vez realizado el filtro por marca se valida el estado de las ordenes registradas en sistema. Existen varios estados +No asignada +Pendiente diagnostico (asignada) +Diagnosticada +Pendiente pedido proveedor
3. Coordinador de línea Estado de orden “No asignada” Se valida el estado de la orden y en caso de ser “No asignada” se ejecuta el punto 4, en caso contrario se ejecuta el punto 5
3. Coordinador de línea Estado de orden “Pendiente
diagnostico”
Si la orden se encuentra en estado “Pendiente diagnostico”, significa que el técnico que tiene asignada la orden la tiene en proceso de reparación, en caso de ser así se ejecuta el punto 4, de lo contrario se ejecuta el punto 7.
4. Coordinador de línea Se realiza asignación de técnico Si la orden se encuentra “No asignada”, el coordinador de línea hace la asignación de técnico para realizar diagnostico y reparación de la falla.
4. Coordinador de línea Validar tiempo que lleva en ese
estado
Se debe validar cuanto tiempo lleva la orden en este estado, es importante que el coordinador de línea esté pendiente que los tiempos de respuesta establecidos en los SLA se cumplan.
5. Coordinador de línea Estado de orden “Pendiente
diagnostico”
Si la orden se encuentra en estado “Pendiente diagnostico”, significa que ya fue asignada a un técnico y que se encuentra en proceso de reparación, en caso de ser así se ejecuta el punto 6, de lo contrario se ejecuta el punto 9.
5. Coordinador de línea ¿Supero el límite? Si el tiempo en que la solicitud ha superado el límite de acordado con el fabricante, se ejecuta el punto 6, de lo contrario se ejecuta el punto 16
6. Coordinador de línea Validar tiempo que lleva en ese
estado
Se debe validar cuanto tiempo lleva la orden en este estado, es importante que el coordinador de línea esté pendiente que los tiempos de respuesta establecidos se cumplan
6. Coordinador de línea /
técnicos Se retroalimenta al técnico
Se valida cual es la falla, se le hace una retroalimentación al técnico el cual deberá diagnosticar el equipo cuanto antes y se validaran los motivos por los cuales se presenta retraso en la gestión realizada, finalmente se pasa al punto 16
7. Coordinador de línea ¿Supero el límite? Si el tiempo en que la solicitud se encuentra en el mismo estado ha superado el límite de 3 días, se ejecuta el punto 8, de lo contrario se ejecuta el punto 14
7. Coordinador de línea Estado de orden “Diagnosticada” Si la orden se encuentra en estado “Diagnosticada”, significa que el técnico ya valido el daño del equipo, sin embargo no has sido ejecutada la reparación. En caso que de ser así se ejecutan los puntos del 4 al 6, en caso contrario se ejecuta el punto 8
8. Coordinador de línea /
técnicos Se retroalimenta al técnico
Se valida cual es la falla, se le hace una retroalimentación al técnico el cual deberá diagnosticar el equipo cuanto antes y se validaran los motivos por los cuales se presenta retraso en la gestión realizada, finalmente se pasa al punto 14
8. Coordinador de línea Validación estado de orden
“Pendiente pedido proveedor”
Por último, si la orden no se encuentra en ninguno de los estados nombrados en los anteriores pasos, el único estado en el que se puede encontrar es en “Pendiente pedido proveedor” que es cuando ya fue diagnosticado el equipo, pero no se ha podido efectuar la reparación pues se debe cambiar alguna parte, y el técnico no la encontró en bodega
9. Coordinador de línea Estado de orden “Diagnosticada”
Si la orden se encuentra en estado “Diagnosticada”, significa que ya fue asignada a un técnico y que este ya valido el daño del equipo, sin embargo no has sido ejecutada la reparación. En caso que de ser así se ejecutan los puntos del 6 al 8, en caso contrario se ejecuta el punto 10
9. Coordinador de línea Validación en bodega de
existencia de parte
En este paso, el coordinador de línea rectifica que efectivamente no esté la parte necesitada en bodega, esto con el fin de evitar solicitarla de forma innecesaria al proveedor y ahorrar tiempos.
10. Coordinador de línea Validación estado de orden
“Pendiente pedido proveedor”
Por último, si la orden no se encuentra en ninguno de los estados nombrados en los anteriores pasos, el único estado en el que se puede encontrar es en “Pendiente pedido proveedor” que es cuando ya fue diagnosticado el equipo, pero no se ha podido efectuar la reparación pues se debe cambiar alguna parte.
10. Coordinador de línea Esta el repuesto en bodega Si el coordinador de línea encuentra la parte solicitada en bodega se ejecuta el punto 11, de lo contrario ejecuta el punto 13
11. Coordinador de línea Repuesto solicitado Para este caso se valida si la parte solicitada por el técnico ya fue pedida al fabricante, en caso que ya se haya pedido se ejecuta el punto 13, de lo contrario se ejecuta el punto 12.
11. Coordinador de línea /
técnicos Entrega la parte al técnico y
cambio de estado de la solicitud En caso que el coordinador de línea encuentre la parte solicitada en bodega, entrega la parte al técnico para que ejecute la reparación
12. Coordinador de línea Se realiza solicitud del repuesto En caso de no haberse pedido el repuesto se hace el proceso de “Solicitud de repuestos” y después se ejecuta el punto 14
12. Coordinador de línea Actualizar CMDB Una vez entregada la parte al técnico se actualiza la base de datos de configuración con los datos de la parte que se saco de bodega. Finalmente se procede a realizar el paso 16
13. Coordinador de línea Validar estado de la solicitud En caso de haberse pedido el repuesto se valida el estado del pedido y se confirma que los datos registrados estén correctamente diligenciados, finalmente se ejecuta el punto 14.
13. Coordinador de línea Repuesto solicitado Para este caso se valida si la parte solicitada por el técnico ya fue pedida al fabricante, en caso que ya se haya pedido se ejecuta el punto 15, de lo contrario se ejecuta el punto 14.
14. Coordinador de línea Finaliza proceso Después de que el coordinador de línea realiza las validaciones, se finaliza el proceso de seguimiento a las órdenes de servicio.
14. Coordinador de línea Se realiza solicitud del repuesto En caso de no haberse pedido el repuesto se hace el proceso de “Solicitud de repuestos” y después se ejecuta el punto 16.
15. 15. Coordinador de línea Validar estado de la solicitud En caso de haberse pedido el repuesto se valida el estado del pedido y se confirma que los datos registrados estén correctamente diligenciados, finalmente se ejecuta el punto 16.
16. 16. Coordinador de línea Finaliza proceso Después de que el coordinador de línea realiza las validaciones, se finaliza el proceso de seguimiento a las órdenes de servicio.
239
3.7.3.3 Proceso de mantenimiento
PROCESO ACTUAL DE LA EMPRESA NUEVO PROCESO APLICANDO ITIL
Cliente
Director técnico
Gerencia comercial
Coordinador de línea
Técnico
Se realiza inventario del equipo, se valida estado y se registra
en sistema
Se realiza asignación de técnico
Coincide el estado registrado en servicio
al cliente vs real
Se informa al cliente la inconsistencia
No
El mantenimiento es correctivo
El técnico realiza el diagnostico
Si
Es un problema
conocido No
Realiza mantenimiento al equipo
Si
Registro en sistema de datos y procedimiento realizado
Ingresa solicitud de servicio
Es preventivo
Se realiza análisis de la propuesta.
+ Disponibilidad de recursos. + Cantidad de técnicos. + Tiempo de duración. + Rentabilidad. + Perfiles. + Necesidades de diagnostico.
Si
No
Se diligencia el formato de propuesta
Es viable la propuesta
Se aprueba propuesta
Si
No se aprueba propuesta
No
Se acepta reparación
Entrega de equipo
No
Se envía novedad al fabricante
Se recibe respuesta
Si
No
Confirma correcto
funcionamiento
Falla solucionada
Si
No
Si
Se hace validación de técnico asignado
El mantenimiento es correctivo
El técnico realiza el diagnostico
No
Realiza mantenimiento al equipo
Si
Registro en sistema de datos y procedimiento realizado
Entrega de equipo
Se envía novedad al fabricante
Se recibe respuesta
Si
No
Confirma correcto
funcionamiento
Falla solucionada
Si
No
Ingresa solicitud de servicio
Es preventivo
Se realiza análisis de la propuesta.
+ Disponibilidad de recursos. + Cantidad de técnicos. + Tiempo de duración. + Rentabilidad. + Perfiles.
+ Necesidades de diagnostico.
Si
No
Se diligencia el formato de
propuesta
Es viable la propuesta
Se aprueba propuesta
Si
No se aprueba propuesta
No
Se busca falla en base de
conocimiento
Falle registrada en la base de conocimiento
Se necesitan repuestos
Se ingresa al sistema repuesto a solicitar
SI
Validar en bodega si hay el repuesto
Existe el repuesto
SI
No
Actualizar CMDB
SI
Ya llego el repuesto
Se verifica estado
de petición
No SI
Actualizar DB de conocimiento
240
Proceso de mantenimiento
Objetivo: Realizar seguimiento y validación a los mantenimientos realizados por los técnicos a los equipos reportados por el usuario.
PROCESO ACTUAL DE LA EMPRESA NUEVO PROCESO APLICANDO ITIL
PASO ENCARGADO DESCRIPCION INSTRUCCIONES PASO ENCARGADO DESCRIPCION INSTRUCCIONES
1. Cliente Ingresa solicitud de servicio Cuando la solicitud ingresa puede ser de dos tipos, existen mantenimientos de tipo preventivos o correctivos
1. Cliente Ingresa solicitud de servicio Cuando la solicitud ingresa puede ser de dos tipos, existen mantenimientos de tipo preventivos o correctivos
2. Director técnico Es preventivo En caso que el mantenimiento sea preventivo se ejecuta el paso 3, de lo contrario se ejecuta el paso 8
2. Director técnico Es preventivo En caso que el mantenimiento sea preventivo se ejecuta el paso 3, de lo contrario se ejecuta el paso 8
3. Director técnico Se realiza análisis de la propuesta.
Se debe realizar un análisis a la propuesta recibida por parte del fabricante. En la propuesta se debe realizar el análisis de algunas variables como:
Disponibilidad de recursos.
Cantidad de técnicos.
Perfiles: conocimientos necesarios para el proceso.
Tiempo de duración: Servicio por días o por horas.
Rentabilidad del negocio.
Necesidades de diagnostico: enviar técnico a terreno o en laboratorio
3. Director técnico Se realiza análisis de la propuesta.
Se debe realizar un análisis a la propuesta recibida por parte del fabricante. En la propuesta se debe realizar el análisis de algunas variables como:
Disponibilidad de recursos.
Cantidad de técnicos.
Perfiles: conocimientos necesarios para el proceso.
Tiempo de duración: Servicio por días o por horas.
Rentabilidad del negocio.
Necesidades de diagnostico: enviar técnico a terreno o en laboratorio
4. Director técnico Se diligencia el formato de
propuesta
Una vez realizado dicho análisis se diligencia la información en formato de propuesta el cual será estudiado para determinar si la propuesta es o no es viable
4. Director técnico Se diligencia el formato de
propuesta Una vez realizado dicho análisis se diligencia la información en formato de propuesta el cual será estudiado para determinar si la propuesta es o no es viable
5. Director técnico /
Gerencia comercial Es viable la propuesta
En caso que la propuesta sea viable, se ejecuta el paso 7, de lo contrario se ejecuta el paso 6
5. Director técnico /
Gerencia comercial Es viable la propuesta
En caso que la propuesta sea viable, se ejecuta el paso 7, de lo contrario se ejecuta el paso 6
6. Gerencia comercial No se aprueba propuesta En caso de no ser viable, se le informa al fabricante que no se acepta la propuesta y se finaliza el proceso.
6. Gerencia comercial No se aprueba propuesta En caso de no ser viable, se le informa al fabricante que no se acepta la propuesta y se finaliza el proceso.
7. Gerencia comercial Se aprueba propuesta En caso de ser viable, se realiza el proceso descrito más adelante, empezando por el punto 9
7. Gerencia comercial Se aprueba propuesta En caso de ser viable, se realiza el proceso descrito más adelante, empezando por el punto 9
8. Coordinador de línea El mantenimiento es correctivo En caso que el mantenimiento no sea preventivo, entonces es correctivo 8. Coordinador de línea El mantenimiento es correctivo En caso que el mantenimiento no sea preventivo, entonces es correctivo
9. Coordinador de línea Se realiza asignación de técnico En este caso el coordinador de línea realiza la asignación de técnico para el caso según la marca del equipo
9. Coordinador de línea Validación de técnico asignado En este caso el coordinador de línea valida que técnico tiene asignado el caso.
10. Técnico Se realiza inventario del equipo, se
valida estado y se registra en sistema
Una vez el técnico haya retirado el equipo de la bodega, realiza el inventario del equipo (seriales, capacidad de cada parte, etc), se valida el estado físico y cosmético en el que se encuentra la maquina. Esta información debe quedar registrada en el sistema
10. Técnico El técnico realiza el diagnostico El técnico realizara la validación o diagnostico de la falla presentada por equipo reportado
11. Técnico Coincide el estado registrado en
servicio al cliente vs real
Se valida que coincidan los datos registrados en servicio a cliente vs los reales, en caso que no coincidan se ejecuta el paso 12, de lo contrario se ejecuta el punto 14
11. Técnico
Falla está registrada en la base de datos de conocimiento
Se valida si el inconveniente se encuentra registrado en la base de datos de conocimiento, es decir si es una falla conocida y si se conoce la forma de darle solución. En caso de no conocerse la falla se ejecuta el punto 12 de lo contrario se ejecuta el punto 20.
12. Coordinador de línea Se informa al cliente la
inconsistencia
En caso que se encuentren inconsistencias entre la información registrada por el personal de servicio al cliente y la información real del equipo, se informara por correo o vía telefónica al cliente sobre el inconveniente
12. Director técnico Se envía novedad al fabricante En caso que no sea un problema conocido se enviara la información al fabricante para recibir retroalimentación del procedimiento a seguir en esos casos especiales.
13. Cliente Se acepta reparación
El usuario decide si acepta o no la reparación, Si el cliente después de conocer esta información, acepta que se realice la reparación, se seguirá el proceso de reparación desde el punto 14 , Si por el contrario, el cliente no acepta dicha información y decide no seguir con la reparación, se hará el proceso de entrega del equipo al cliente, es decir se ejecuta le punto 22
13. Director técnico Se recibe respuesta
Se espera que el fabricante envíe la información solicitada, en caso de haber llegado la información del fabricante sobre el procedimiento a seguir, se envía la información al técnico encargado del caso y se realiza el procedimiento para divulgación de tips, después se realizaran los pasos siguientes descritos desde el punto 14, de lo contrario se ejecuta el punto 12
14. Técnico El técnico realiza el diagnostico En caso que no se encuentren inconsistencias entre la información registrada por el personal de servicio al cliente y la información real del equipo, el técnico realizara la validación o diagnostico de la falla presentada por equipo reportado
14. Técnico Actualizar base de datos de conocimiento
Cuando se recibe el procedimiento a seguir de la nueva falla, se realiza la actualización de la base de datos de conocimiento.
15. Técnico Es un problema conocido Puede presentarse que la falla presentada por el equipo no sea un problema conocido, en tal caso se ejecuta el punto 16, de lo contrario se ejecuta el punto 18
15. Técnico Realiza mantenimiento al equipo El técnico procede a realizar el mantenimiento del equipo.
16. Director técnico Se envía novedad al fabricante En caso que no sea un problema conocido se enviara la información al fabricante para recibir retroalimentación del procedimiento a seguir en esos casos especiales.
16. Técnico Registro en sistema de datos y
procedimiento realizado Se realiza registro en sistema del procedimiento realizado por el técnico con el cual se dio solución a la falla
17. Director técnico Se recibe respuesta
Se espera que el fabricante envíe la información solicitada, en caso de haber llegado la información del fabricante sobre el procedimiento a seguir, se envía la información al técnico encargado del caso y se realiza el procedimiento para divulgación de tips, después se realizaran los pasos siguientes descritos desde el punto 18, de lo contrario se ejecuta el punto 16
17. Director técnico Confirma correcto funcionamiento Finalmente el director técnico realizan una validación para control de calidad en la cual se revisa que el equipo este en perfectas condiciones, se hacen pruebas de rendimiento y se confirma que ya quedo completamente reparada la falla
18. Técnico Realiza mantenimiento al equipo El técnico procede a realizar el mantenimiento del equipo, en este caso si hay necesidad de cambiar una parte se hará el procedimiento “Solicitud de repuestos”
18. Director técnico Falla solucionada
Se valida que la falla haya quedado solucionada, en caso de ser así se se hace actualización del estado de la orden de servicio en sistema, se ingresa el equipo a bodega para que esté listo para la entrega y se ejecuta el punto 19 de lo contrario se ejecuta el punto 10.
19. Técnico Registro en sistema de datos y
procedimiento realizado Se realiza registro en sistema del procedimiento realizado por el técnico con el cual se dio solución a la falla
19. Cliente Entrega de equipo Se entrega equipo al cliente.
20. Director técnico Confirma correcto funcionamiento
Finalmente el director técnico realizan una validación para control de calidad en la cual se revisa que el equipo este en perfectas condiciones, se hacen pruebas de rendimiento y se confirma que ya quedo completamente reparada la falla
20. Técnico Se necesitan repuestos En caso de necesitar repuestos se ejecuta el paso 21 de lo contrario se ejecuta el paso 15.
21. Director técnico Falla solucionada
Se valida que la falla haya quedado solucionada, en caso de ser así se se hace actualización del estado de la orden de servicio en sistema, se ingresa el equipo a bodega para que esté listo para la entrega y se ejecuta el punto 22 de lo contrario se ejecuta el punto 14.
21. Técnico Validar existencia de repuesto en
bodega
El técnico revisa si el repuesto que necesita se encuentra en la bodega de PUNTO DE SERVICIOS. Es importante que la empresa tenga en STOCK los repuestos más solicitados para realizar la reparación sin solicitar la parte al fabricante agilizar tiempos.
22. Cliente Entrega de equipo Se entrega equipo al cliente. 22. Técnico Existe el repuesto En caso de existir el repuesto se ejecuta el paso 23, de lo contrario se procede a ejecutar el punto 24.
23. 23. Técnico Actualización de CMDB Se debe actualizar la base de datos de configuración con la información de la parte requerida. Posteriormente se procede a ejecutar el punto 15.
241
24. 24. Técnico Se ingresa al sistema repuesto a
solicitar En caso de necesitar algún repuesto, se ingresa al sistema la información correspondiente y la parte requerida para el cambio.
25. 25. Técnico ¿Ya llego el repuesto? El tiempo que dura en llegar el repuesto depende únicamente de la marca y de los tiempos que se hayan establecido para envío de los repuestos. En caso de haber llegado el repuesto se ejecuta el punto 15, de lo contrario se ejecuta el punto 20.
26. 26. Técnico Verificar estado de petición En caso de haber cumplido el tiempo límite para entrega de repuesto, se valida el estado en le que se encuentra la petición y se hacen las correcciones correspondiente para que sea enviada la parte por el fabricante.
242
3.7.3.4 Proceso de solicitud de repuestos
PROCESO ACTUAL DE LA EMPRESA NUEVO PROCESO APLICANDO ITIL
Coordinador de línea
fabricante
Técnico
Asesor Comercial
Cliente
Atención al cliente
Garantía aprobada
No SI
Se entrega equipo
No
Se valida el caso por
facturación Se cambia estado de la orden a “Pendiente por
cotizar”
Se envía el caso al asesor comercial
Es garantía
Validación orden de servicio
Se valida en sistema caso con estado “Pendiente
pedido proveedor”
Se ingresa el pedido al proveedor con información
de máquina y cliente
No
SI
Llegaron repuestos
+ Validar # días pendientes. + Verificar datos completos y correctos
No
Se cierra el pedido
SI
Se hace devolución de repuestos
Se envía por correo notificación al cliente
Se genera y envía cotización al cliente para su aprobación
Cliente aprueba la compra
SI
+ Se envía solicitud al fabricante.
+ Se hace orden de compra
Técnico realiza el mantenimiento
Garantía aprobada
No SI
Se entrega equipo
No
Se valida el caso por
facturación Se cambia estado de la orden a “Pendiente por
cotizar”
Se envía el caso al asesor comercial
Se hace devolución de repuestos
Se envía por correo notificación al cliente
Se genera y envía cotización al cliente para su aprobación
Cliente aprueba la compra
SI
+ Se envía solicitud al fabricante. + Se hace orden de compra
Técnico realiza el mantenimiento
Es garantía
Validación orden de servicio
Se valida en sistema caso con estado “Pendiente
pedido proveedor”
Se ingresa el pedido al proveedor con información
de máquina y cliente
No
SI
Llegaron repuestos
+ Validar # días pendientes. + Verificar datos completos y correctos
No
Se cierra el pedido
SI
Validar en bodega si hay el repuesto
Existe el repuesto
SI No
Entrega la parte al técnico y cambio de estado de la solicitud
Actualizar CMDB
243
Proceso para solicitud de repuestos
Objetivo: Validar si el mantenimiento necesita uso de repuestos ya sea por garantía o facturación y realizar la solicitud al fabricante para cambiar la parte y solucionar el inconveniente presentado por el equipo.
PROCESO ACTUAL DE LA EMPRESA NUEVO PROCESO APLICANDO ITIL
PASO ENCARGADO DESCRIPCION INSTRUCCIONES PASO ENCARGADO DESCRIPCION INSTRUCCIONES
1. Coordinador de línea Validación orden de servicio El coordinador de línea realiza la validación en sistema de los casos que tiene pendientes.
1. Coordinador de línea Validación orden de servicio El coordinador de línea realiza la validación en sistema de los casos que tiene pendientes.
2. Coordinador de línea Se valida en sistema caso con
estado “Pendiente pedido proveedor”
El coordinador de línea realiza la validación en sistema de los casos que se encuentren en estado “Pendiente pedido proveedor”.
2. Coordinador de línea Se valida en sistema caso con
estado “Pendiente pedido proveedor”
El coordinador de línea realiza la validación en sistema de los casos que se encuentren en estado “Pendiente pedido proveedor”.
3. Coordinador de línea ¿Es garantía? Se valida si el pedido ingresado inicialmente esta por garantía o facturación, si es garantía se pasa al punto 4, en caso de ser por facturación se pasa al punto 12.
3. Coordinador de línea Validar existencia de repuesto en
bodega
El coordinador de línea revisa si el repuesto que necesita se encuentra en la bodega de PUNTO DE SERVICIOS. Este proceso con el fin de evitar que se solicite innecesariamente una parte al fabricante, la cual se tiene en STOCK
4. Coordinador de línea Ingreso del pedido al proveedor
con información correspondiente
En caso de estar por garantía, el coordinador de línea realiza el procedimiento correspondiente para solicitar repuestos al fabricante, el sistema en el que se hace este proceso varía dependiendo de la marca del equipo pues cada fabricante tiene su página para realizar pedidos de partes por garantía. En cualquier caso se debe diligenciar los datos de la persona que registra como dueña de la maquina, datos del equipo (serial del equipo, tipo y modelo, fecha de solicitud, persona encargada – director técnico, parte a solicitar, sede a donde se despachara la parte, etc.), el sistema genera un numero de pedido el cual se ingresa en sistema.
4. Coordinador de línea Existe el repuesto En caso de existir el repuesto se ejecuta el paso 5, de lo contrario se procede a ejecutar el punto 7.
5. Coordinador de línea ¿Garantía aprobada?
Se valida si la garantía fue aprobada por el fabricante, en caso de ser negativa la aprobación se le informa al usuario lo sucedido para que de la autorización de realizar el pedido pero no por garantía sino por facturación descrito desde el paso 11. En caso que la garantía sea aprobada, se espera el tiempo necesario para recibir los repuestos enviados por el fabricante. En ocasiones no se cumplen los SLA porque hay algunos fabricantes que se demoran mucho tiempo en enviar los repuestos
5. Coordinador de línea Entrega la parte al técnico y
cambio de estado de la solicitud En caso que el coordinador de línea encuentre la parte solicitada en bodega, entrega la parte al técnico para que ejecute la reparación.
6. Coordinador de línea ¿Llegaron repuestos?
Se esperan los días establecidos para envió de repuestos dependiendo la marca (máximo 8 días) y antes que se cumpla el tiempo establecido para reparación de los equipos (10 días pero se espera llegar a 4 días) se valida si ya llegaron los repuestos. El tiempo que se demora el fabricante en enviar la parte defectuosa varía según la marca pues todos no manejan los mismos tiempos. En caso de no haber llegado repuestos se ejecuta el punto 7, pero si ya llegaron se pasa al punto 8.
6. Coordinador de línea Actualización de CMDB Se debe actualizar la base de datos de configuración con la información de la parte requerida. Posteriormente se procede a ejecutar el punto 13.
7. Coordinador de línea Validación datos del pedido En caso de no haber llegado los repuestos, se valida que los datos ingresados en el pedido realizado al proveedor estén correctos y completos, de haber algún error se hace la corrección para que el fabricante envíe la parte y se pasa al punto 4.
7. Coordinador de línea ¿Es garantía? Se valida si el pedido ingresado inicialmente esta por garantía o facturación, si es garantía se pasa al punto 8, en caso de ser por facturación se pasa al punto 16.
8. Coordinador de línea Cierre del pedido En caso de haber llegado los repuestos, se cierra el pedido y se envía la parte al técnico para que ejecute la reparación del equipo.
8. Coordinador de línea Ingreso del pedido al proveedor con información correspondiente
En caso de estar por garantía, el coordinador de línea realiza el procedimiento correspondiente para solicitar repuestos al fabricante, el sistema en el que se hace este proceso varía dependiendo de la marca del equipo pues cada fabricante tiene su página para realizar pedidos de partes por garantía. En cualquier caso se debe diligenciar los datos de la persona que registra como dueña de la maquina, datos del equipo (serial del equipo, tipo y modelo, fecha de solicitud, persona encargada – director técnico, parte a solicitar, sede a donde se despachara la parte, etc.), el sistema genera un numero de pedido el cual se ingresa en sistema.
9. Técnico Ejecución del mantenimiento El técnico realiza el mantenimiento del equipo el cual no se puede demorar más de 2 días después de recibida la parte.
9. Coordinador de línea ¿Garantía aprobada?
Se valida si la garantía fue aprobada por el fabricante, en caso de ser negativa la aprobación se le informa al usuario lo sucedido para que de la autorización de realizar el pedido pero no por garantía sino por facturación descrito desde el paso 16. En caso que la garantía sea aprobada, se espera el tiempo necesario para recibir los repuestos enviados por el fabricante.
10. Coordinador de línea Devolución de repuestos
Posteriormente el coordinador de línea realiza la devolución de los repuestos, dependiendo la marca se entregan a medida que se van reemplazando y en otras el mismo fabricante recoge las partes defectuosas. En los casos en que se debe hacer la devolución fuera del país, se realiza el proceso correspondiente, cumpliendo los requisitos de ley necesarios (factura comercial, guía, etc.) para poder devolver la parte al fabricante
10 Coordinador de línea ¿Llegaron repuestos?
Se esperan los días acordados con el fabricante para envió de repuestos dependiendo la marca y antes que se cumpla el tiempo establecido con el fabricante en los SLA para reparación de los equipos se valida si ya llegaron los repuestos. En caso de no haber llegado repuestos se ejecuta el punto 11, pero si ya llegaron se pasa al punto 12.
11. Coordinador de línea Envío por correo, notificación al
cliente Se entrega el equipo a bodega y se envía notificación por correo al cliente sobre la solución del caso, y se ejecuta el punto 18.
11. Coordinador de línea Validación datos del pedido
En caso de no haber llegado los repuestos, se valida que los datos ingresados en el pedido realizado al proveedor estén correctos y completos, de haber algún error se hace la corrección para que el fabricante envíe la parte y se pasa al punto 8.
12. Coordinador de línea Se valida el caso por
facturación En caso que la orden de servicio no sea una garantía queda la opción de que sea por facturación.
12. Coordinador de línea Cierre del pedido En caso de haber llegado los repuestos, se cierra el pedido y se envía la parte al técnico para que ejecute la reparación del equipo.
13. Coordinador de línea Cambio de estado de la orden Si la orden es por facturación se cambia en sistema el estado a “Pendiente por cotizar” 13. Técnico Ejecución del mantenimiento El técnico realiza el mantenimiento del equipo el cual no se puede demorar más días de los establecidos en los SLA.
14. Coordinador de línea Envío del caso al asesor
comercial
El coordinador de línea es el encargado de enviar el caso por correo al asesor comercial para que realice el proceso correspondiente y la cotización de la parte requerida al fabricante
14. Coordinador de línea Devolución de repuestos
Posteriormente el coordinador de línea realiza la devolución de los repuestos, dependiendo la marca se entregan a medida que se van reemplazando y en otras el mismo fabricante recoge las partes defectuosas. En los casos en que se debe hacer la devolución fuera del país, se realiza el proceso correspondiente, cumpliendo los requisitos de ley necesarios (factura comercial, guía, etc.) para poder devolver la parte al fabricante. En caso que el repuesto se hubiera sacado de la bodega de PUNTO DE SERVICIOS, este se devuelve a la bodega.
15. Asesor Comercial / Cliente Se genera y envía cotización al
cliente para su aprobación Una vez el asesor comercial tenga la información requerida, envía la cotización al cliente para que apruebe o no la compra de la parte dañada.
15. Coordinador de línea Envío por correo, notificación al
cliente Se entrega el equipo a bodega y se envía notificación por correo al cliente sobre la solución del caso, y se ejecuta el punto 22.
16. Cliente Cliente aprueba la compra Si el cliente aprueba la compra se procede a realizar el punto 17, de lo contrario se ejecutara el punto 18
16. Coordinador de línea Se valida el caso por facturación En caso que la orden de servicio no sea una garantía queda la opción de que sea por facturación.
17. Asesor Comercial Ejecución orden de compra En caso que el cliente apruebe la compra, se envía la solicitud de compra al fabricante y se sigue el procedimiento realizado desde el punto 6
17. Coordinador de línea Cambio de estado de la orden Si la orden es por facturación se cambia en sistema el estado a “Pendiente por cotizar”
18. Atención al cliente Entrega equipo En caso de no aprobarse la compra se realizara la entrega del equipo sin reparar al cliente.
18. Coordinador de línea Envío del caso al asesor comercial El coordinador de línea es el encargado de enviar el caso por correo al asesor comercial para que realice el proceso correspondiente y la cotización de la parte requerida al fabricante
19. 19. Asesor Comercial / Cliente Se genera y envía cotización al
cliente para su aprobación Una vez el asesor comercial tenga la información requerida, envía la cotización al cliente para que apruebe o no la compra de la parte dañada.
244
20. 20. Cliente Cliente aprueba la compra Si el cliente aprueba la compra se procede a realizar el punto 21, de lo contrario se ejecutara el punto 22
21. 21. Asesor Comercial Ejecución orden de compra En caso que el cliente apruebe la compra, se envía la solicitud de compra al fabricante y se sigue el procedimiento realizado desde el punto 10
22. 22. Atención al cliente Entrega equipo En caso de no aprobarse la compra se realizara la entrega del equipo sin reparar al cliente.
245
3.7.3.5 Proceso para validación de cumplimiento de los SLA
PROCESO ACTUAL DE LA EMPRESA NUEVO PROCESO APLICANDO ITIL
Director técnico
Técnicos
Gerencia Comercial
Se cumplen metas
Generación de informes
Análisis de las causas del incumplimiento
Retroalimentación a
los técnicos
Inicio de validación
Descarga información del sistema
Indicador 1 Validar TTS
Indicador 2 Validar DT
- Validación de Metas - Días - Total de servicios
- % de cumplimiento
- Nombre del técnico - # de equipos reparados - # de servidores reparados
- # de impresoras reparadas
- # de garantías al mes por técnico. - Motivo de la falla
Se valida el Indicador 3: Garantías de servicio
Entrega de informes
Retroalimentación a
los técnicos
Inicio de validación
Descarga información del sistema
Se cumplió SLO
- Validación tipo SLA. - Validación prioridad SLO. - % de cumplimiento
Se realiza análisis de los casos en los que no se cumplieron los SLA
Ya hay SLA definidos
No No
Si Si
Si No
Si Se envía requerimiento al área comercial.
Se realizan reuniones con los fabricantes para
establecer acuerdos
Los SLA y OLA ya están definidos
Se acuerda con el fabricante fecha de reunión
para hacer acuerdos
No Si
No
Se generan documentos con los acuerdos establecidos
por ambas partes
Se genera informes
Si
No
246
Proceso para validación de cumplimiento de los SLA
Objetivo: Realizar seguimiento a las órdenes de servicio gestionadas por los técnicos de la empresa PUNTO DE SERVICIOS para validar el nivel de cumplimiento de los SLA establecidos y tomar las acciones de mejora pertinente para cumplir con los Niveles de servicio acordados.
PROCESO ACTUAL DE LA EMPRESA NUEVO PROCESO APLICANDO ITIL
PASO ENCARGADO DESCRIPCION INSTRUCCIONES PASO ENCARGADO DESCRIPCION INSTRUCCIONES
1. Director técnico Inicio de validación El director técnico debe realizar las mediciones de cumplimiento en cuanto a las metas establecidas
1. Director técnico Inicio de validación El director técnico debe realizar las mediciones de cumplimiento en cuanto a las metas establecidas
2. Director técnico Descarga información del
sistema El director técnico debe descargar la información del sistema file maker para empezar a hacer las mediciones.
2. Director técnico Ya hay SLA definidos Se valida si los acuerdos de niveles de servicio que se deben cumplir ya fueron establecidos entre el fabricante y la empresa, en caso de no haber establecidos acuerdos, se ejecuta el punto 10, de lo contrario el punto 3.
3. Director técnico Indicador 1 Validar TTS
El director e define cual será el indicador que se medirá. En caso de medir el indicador 1 TTS (Tiempo Total de Servicio) que hace referencia a la duración de reparación de del servicio, se debe pasar al punto 4.
3. Director técnico Descarga información del
sistema El director técnico debe descargar la información del sistema file maker para empezar a hacer las mediciones.
4. Director técnico Procedimiento para validación de metas
Se debe validar los siguientes datos y tabular los resultados. - Validación de metas: se hace por marcas - Días: menor a 10 días para reparación con fines de bajarla a 4 días. - Total de servicios reparados - % cumplimiento
4. Director técnico Generación de informes Después de descargada la información necesaria, se realizan los informes correspondientes para validar si se cumplen los acuerdos establecidos por el fabricante y la empresa.
5. Director técnico Validación de cumplimiento
metas
Después de tener los resultados, se valida si se cumple o no la meta establecida en caso de cumplirse la meta se pasa al punto 8. En caso de no cumplir la meta se pasa al punto 6.
5. Director técnico Validación de SLA, SLO y %
de cumplimiento
Después de tener los resultados, se empiezan a validar los acuerdos, es decir se que se valida según el tipo de SLA (ya sea por prioridad, impacto, urgencia), SLO (tiempos de solución de cada caso),y %porcentaje en que se están cumpliendo estos acuerdos.
6. Director técnico Análisis de las causas del
incumplimiento En caso de no cumplirse las metas se realiza un análisis para determinar los motivos por los cuales esa meta no fue cumplida
6. Director técnico Se cumplió SLO Cuando ya tenemos definida la información del punto 5, validamos si se cumplieron o no los SLO. En caso de haberse cumplido se ejecuta el punto 9 de lo contrario se ejecuta el punto 7.
7. Director técnico/ técnicos Retroalimentación a los
técnicos Una vez se sepan los motivos del incumplimiento, se genera las retroalimentaciones correspondientes al área o persona que cometió el error
7. Director técnico Análisis de incumplimiento de
SLA En caso de no cumplirse los SLA se realiza un análisis para determinar los motivos por los cuales estos acuerdos no fueron cumplidos.
8. Director técnico Generación de informes Finalmente se generan informes con los datos obtenidos sobre el caso y las medidas tomadas para evitar el incumplimiento de los SLA, este informa se hace manual pues el sistema no genera informes por el momento
8. Director técnico/ técnicos Retroalimentación a los
técnicos Una vez se sepan los motivos del incumplimiento, se genera las retroalimentaciones correspondientes al área o persona que cometió el error
9. Director técnico Indicador 2 Validar DT
En caso que el indicador que se desea medir no sea el 1, se tiene la opción de medir el indicador 2 DT (Desempeño del técnico)
9. Director técnico Entrega de informes Finalmente se entregan los informes con los datos obtenidos sobre el caso y las medidas tomadas para evitar el incumplimiento de los SLA, este se entrega a la gerencia para que este enterada del nivel de cumplimiento de la compañía.
10. Director técnico Procedimiento para validación de metas
Para medir el indicador 2 DT, se debe validar los siguientes datos - Nombre del técnico - # Equipos reparados: ( se tiene la menta de 4 equipos por día) - # Servidores reparados ( se tiene una aprox de que 1 servidor vale lo de 2 portátiles) - # Impresoras reparadas ( se tiene una aprox de que 1 impresora vale lo de 2 portátiles) y se deben repetir los puntos del 4 al 8
10. Gerencia comercial Acuerdo fecha de reunión Se envía la solicitud al fabricante para realizar la reunión correspondiente donde serán pactados los acuerdos de niveles de servicio que beneficien ambas partes.
11. Director técnico Indicador 3
Garantías de servicio
Si no se midió el indicador 1 ni el 2, el último indicador es el 3 que hace referencia a las garantías de servicios.
11. Gerencia comercial Realizar reunión Se ejecuta la reunión con el fabricante donde se definen los SLA, que se empezaran a medir.
12. Director técnico Procedimiento para validación de metas
Para medir el indicador 3 se debe validar los siguientes datos - # de garantías al mes por técnico (meta 3% máximo durante el mes) - Motivo de la falla
12. Gerencia comercial Generación de documento
Se generan los documentos donde quedan plasmados los acuerdos a los que se llego con el fabricante, este documento debe estar firmado por ambas partes para posteriormente empezar a realizar las mediciones acordadas. Después de establecidos los acuerdos se procede a realizar el punto 3.
247
3.7.4 Base de Datos
A continuación se hace una descripción básica de la definición de bases de datos
que deben ser implementadas para la Base de Conocimientos y la CMDB.
Es necesario que se tenga en cuenta la posibilidad de crecimiento y adaptación de
dichas bases, dado que aquí se presenta una normalización básica para que se
apliquen a las recomendaciones dadas en este texto.
3.7.4.1 Modelo ENTIDAD – RELACION Figura 54: Relaciones existentes en la Base de datos de conocimiento
248
Figura 55: Relaciones existentes en la CMDB
3.7.4.2 Diccionario de Datos de la Base de Datos de Conocimiento
nombre de la tabla
nombre del campo
tipo dato del campo
longitud del campo
valor predeterminado
descripción de los datos del
campo
Casos Id Autonumérico Entero largo Auto numérico Incrementable
Casos id_caso Número Entero largo
Casos cod_problema Texto 10
Casos fecha_registro Fecha/hora Fecha actual (Date)
Categorias Id Autonumérico Entero largo Autonumérico Incrementable
Categorias id_categoria Texto 10
Categorias Categoría Texto 50
Categorias Descripción Texto 255
Subcategorias
Id Autonumérico Entero largo Autonumérico Incrementable
Subcategorias
id_subcategoria
Texto 10
Subcategorias
Subcategoria Texto 50
Subcategorias
Descripción Texto 255
Problemas Id Autonumérico Entero largo Autonumérico Incrementable
Problemas cod_problema Texto 10
Problemas Problema Texto 100
Problemas Descripción Texto 255
Problemas Solución Texto 255
Problemas palabra_clave Texto 50
Eventos Id Autonumérico Entero largo Autonumérico Incrementable
Eventos usuario_registra
Texto 10
Eventos fecha_creacion
Texto Fecha/hora Fecha actual (Date)
Eventos usuario_actualiza
Texto 10
Eventos fecha_actualiza
Texto Fecha/hora Fecha actual (Date)
249
3.7.4.3 Normalización de la Base de Datos de Conocimiento
1FN NOMBRE
DE LA TABLA
NOMBRE DEL CAMPO
TIPO DATO DEL CAMPO
LONGITUD DEL
CAMPO
VALOR PREDETERMINADO
DESCRIPCION DE LOS DATOS
DEL CAMPO
Casos Id Autonumérico Entero largo Autonumérico Incrementable
Casos id_caso Número Entero largo
Casos cod_problema Texto 10
Casos fecha_registro Fecha/hora Fecha actual (Date)
2FN NOMBRE
DE LA TABLA
NOMBRE DEL CAMPO
TIPO DATO DEL CAMPO
LONGITUD DEL
CAMPO
VALOR PREDETERMINADO
DESCRIPCION DE LOS DATOS
DEL CAMPO
Categorias Id Autonumérico Entero largo Autonumérico Incrementable
Categorias id_categoria Texto 10
Categorias Categoría Texto 50
Categorias Descripción Texto 255
3FN
NOMBRE DE LA TABLA
NOMBRE DEL
CAMPO
TIPO DATO DEL CAMPO
LONGITUD DEL CAMPO
VALOR PREDETERMINAD
O
DESCRIPCION DE LOS DATOS
DEL CAMPO
Subcategorias
Id Autonumérico Entero largo Autonumérico Incrementable
Subcategorias
id_subcategoria
Texto 10
Subcategorias
Subcategoria
Texto 50
Subcategorias
Descripción Texto 255
4FN NOMBRE
DE LA TABLA
NOMBRE DEL CAMPO
TIPO DATO DEL CAMPO
LONGITUD DEL
CAMPO
VALOR PREDETERMINADO
DESCRIPCION DE LOS DATOS
DEL CAMPO
Problemas Id Autonumérico Entero largo Autonumérico Incrementable
Problemas cod_problema Texto 10
Problemas Problema Texto 100
Problemas Descripción Texto 255
Problemas Solución Texto 255
Problemas palabra_clave Texto 50
250
NOMBRE
DE LA TABLA
NOMBRE DEL CAMPO
TIPO DATO DEL CAMPO
LONGITUD DEL
CAMPO
VALOR PREDETERMINADO
DESCRIPCION DE LOS DATOS
DEL CAMPO
Eventos Id Autonumérico Entero largo Autonumérico Incrementable
Eventos usuario_registra
Texto 10
Eventos fecha_creacion
Texto Fecha/hora Fecha actual (Date)
Eventos usuario_actualiza
Texto 10
Eventos fecha_actualiza
Texto Fecha/hora Fecha actual (Date)
3.7.4.4 Diccionario de Datos de la CMDB
NOMBRE DE LA TABLA
NOMBRE DEL CAMPO
TIPO DATO DEL CAMPO
LONGITUD DEL
CAMPO
VALOR PREDETERMINAD
O
DESCRIPCION DE LOS
DATOS DEL CAMPO
Tipo_activo Id Autonumérico Entero largo Autonumérico Incrementable
Tipo_activo id_tipo_activo Texto 10
Tipo_activo tipo_activo Texto 50
Tipo_activo Descipcion Texto 255
Activo Id Autonumérico Entero largo Autonumérico Incrementable
Activo id_activo Texto 10
Activo nom_activo Texto 50
Activo Descripción Texto 255
Activo Condición Texto 50
Activo fecha_adquisicion
Fecha/hora Fecha/hora Fecha actual (Date)
Activo precio_adquisicion
Moneda Entero largo
Activo valor_actual Moneda Entero largo
Activo Ubicación Texto 50
Activo Fabricante Texto 50
Activo Modelo Texto 50
Status Id Autonumérico Entero largo Autonumérico Incrementable
Status id_status Texto 10
Status Status Texto 50
Status Descripción Texto 255
3.7.4.5 Normalización de la CMDB
1FN NOMBRE DE
LA TABLA NOMBRE
DEL CAMPO TIPO DATO DEL CAMPO
LONGITUD DEL CAMPO
VALOR PREDETERMINADO
DESCRIPCION DE LOS
DATOS DEL CAMPO
Tipo_activo Id Autonumérico Entero largo Autonumérico Incrementable
Tipo_activo id_tipo_activo Texto 10
Tipo_activo tipo_activo Texto 50
Tipo_activo Descipcion Texto 255
251
2FN NOMBRE
DE LA TABLA
NOMBRE DEL CAMPO
TIPO DATO DEL CAMPO
LONGITUD DEL CAMPO
VALOR PREDETERMINADO
DESCRIPCION DE LOS
DATOS DEL CAMPO
Activo Id Autonumérico Entero largo Autonumérico Incrementable Activo id_activo Texto 10 Activo nom_activo Texto 50 Activo Descripción Texto 255 Activo Condición Texto 50 Activo fecha_adquisicion Fecha/hora Fecha/hora Fecha actual (Date) Activo precio_adquisicion Moneda Entero largo Activo valor_actual Moneda Entero largo Activo Ubicación Texto 50 Activo Fabricante Texto 50 Activo Modelo Texto 50
3FN NOMBRE DE
LA TABLA NOMBRE DEL
CAMPO TIPO DATO DEL CAMPO
LONGITUD DEL CAMPO
VALOR PREDETERMINADO
DESCRIPCION DE LOS
DATOS DEL CAMPO
Status Id Autonumérico Entero largo Autonumérico Incrementable
Status id_status Texto 10
Status Status Texto 50
Status Descripción Texto 255
3.7.4.6 Modelo Fisico Figura 56: Modelo físico de la Base de Datos de Conocimiento
252
Figura 57: Modelo físico de la CMDB
3.7.4.7 Modelo Logico Figura 58: Modelo Lógico de la Base de Datos de Conocimiento
253
Figura 59: Modelo Lógico de la CMDB
3.7.4.8 Recomendaciones tecnicas para la implementación de la BD
Para la implementación de las CMDB y la KBD se hace necesario tener en cuenta
las siguientes recomendaciones:
En primera instancia se debe determinar la clase de BD a emplear en el desarrollo
de las mismas; es decir, si son de licencia libre, GNU o copyright.
Licencias Libres: Algunas sugerencias de software libre son MySQL y
PostgreSQL
Para el uso de Herramientas con MySQL:
En el caso de desarrollar software en ambiente WEB se hace necesario tener en
cuenta las siguientes especificaciones técnicas:
254
Dirección Web: Se requiere un nombre de dominio, dirección única que identificará
las páginas de Internet.
Plataforma tecnológica para el alojamiento:
Software:
Servidor Web Apache 2.0.54 o superior que será el encargado de atender las
solicitudes a través de Internet.
Php 5.0.4 o superior que es el lenguaje de programación utilizado por las
Aplicaciones de Acción.
MySQL 4.1.15 o superior que es el servidor de bases de datos que se
encargará del almacenamiento de los datos del sistema.
Salida de correo activa para el envió de notificaciones (servicio que posee el
software).
Hardware:
512 Memoria Ram.
10 Gb de espacio en disco.
Procesador de 1 Ghz.
Enlace dedicado a Internet de 512Kbps.
Una unidad de backup (o DVD) para realizar copias diarias de la información.
Plataforma tecnológica para el alojamiento:
Software:
Cualquier navegador Web (Internet Explorer 5.5 ó superior, Mozilla FireFox 1X
ó superior, Netscape 6.0 ó superior, entre otros), se sugiere tener software de
ofimática.
255
Hardware:
Conexión a Internet en funcionamiento en la entidad. (Telefónica, satelital o por
cable).
Equipo de cómputo con características mínimas de: Procesador 450Mhz,
memoria 64MB, disco duro 5Gb y módem 56Kbps.
Para el uso de Herramientas con PostGreSQL:
Requerimientos:
Los requerimientos mínimos para instalar PostgreSQL son:
8 megabytes de RAM
30 megabytes de espacio en disco para el cogido fuente
5 megabytes de espacio en disco para la instalación de los ejecutables
1 megabyte extra para las bases de datos básicas
3 megabytes de espacio en disco rígido para el tarball con el cogido fuente
Licencias copyright: SQL SERVER 2008
Requisitos de hardware y software para instalar SQL Server 2008
Componente Requisito
Marco de
trabajo
El programa de instalación de SQL Server instala los siguientes
componentes de software requeridos por el producto:
.NET Framework 3.5 SP1
SQL Server Native Client
Archivos auxiliares para la instalación de SQL Server
Software2 El programa de instalación de SQL Server requiere Microsoft
Windows Installer 4.5 o una versión posterior.
256
Software de
red
Los requisitos de software de red para las versiones de 64 bits de
SQL Server 2008 son los mismos que para las versiones de 32
bits.
Los sistemas operativos compatibles tienen el software de red
integrado. Las instancias predeterminadas y con nombre
independientes admiten los siguientes protocolos de red:
Memoria compartida
Canalizaciones con nombre
TCP/IP
VIA
Nota La memoria compartida y VIA no se admiten en clústeres de
conmutación por error.
Software de
Internet
Para todas las instalaciones de SQL Server 2008 se requiere
Microsoft Internet Explorer 6 SP 1 o una versión posterior. Se
requiere Internet Explorer 6 Service Pack 1 o una versión posterior
para Microsoft Management Console (MMC), SQL Server
Management Studio, Business Intelligence Development Studio, el
componente Diseñador de informes de Reporting Services y la
Ayuda HTML.
Disco duro Las necesidades de espacio en disco variarán con los
componentes de SQL Server 2008 que instale. Para obtener más
información, vea Requisitos de espacio en disco duro.
Unidad Para la instalación desde disco se necesita una unidad de CD o
DVD.
Pantalla Las herramientas gráficas de SQL Server 2008 requieren VGA o
una resolución mayor: resolución mínima de 1.024 x 768 píxeles.
Otros Dispositivo señalador: se necesita un mouse Microsoft o
257
dispositivos dispositivo señalador compatible.
Requisitos de espacio en disco duro (32 y 64 bits)
Durante la instalación de SQL Server 2008, Windows Installer crea archivos
temporales en la unidad del sistema. Antes de ejecutar el programa de instalación
para instalar o actualizar SQL Server, Compruebe que dispone de al menos 2,0
GB de espacio en disco en la unidad del sistema para estos archivos. Este
requisito es aplicable incluso si instala todos los componentes de SQL Server en
una unidad distinta de la predeterminada.
Los requisitos reales de disco duro dependen de la configuración del sistema y de
las características que decida instalar. En la tabla siguiente se muestran los
requisitos de espacio en disco de los componentes de SQL Server 2008:
Característica Requisito de
espacio en disco
Database Engine (Motor de base de datos) y archivos de
datos, Replicación y Búsqueda de texto
280 MB
Analysis Services y archivos de datos 90 MB
Reporting Services y Administrador de informes 120 MB
Integration Services 120 MB
Componentes de cliente 850 MB
Libros en pantalla de SQL Server y Libros en pantalla de
SQL Server Compact
240 MB
BACKUP DE LAS BD
258
Tanto para el caso de bases de datos desarrolladas con herramientas libres o
copyright, por seguridad de la información se recomienda generar los backups
todos los días en las horas de la noche con el fin no generar traumatismos en la
operación diaria.
Por tratarse de una PYME no se hace necesario la contratación de un
DATACENTER que no es más que un centro de procesamiento de datos en
donde se concentran todos los recursos necesarios para el procesamiento de
información de una organización.
3.7.5 Recomendaciones generales
De acuerdo con la información recolectada en el proceso de investigación se
realiza un informe para la implementación de ITIL en la empresa Punto de
Servicios S. A.
Introducción
En la actualidad Punto de servicios presta soporte de garantías y técnico de las
marcas más populares del mercado de los computadores personales, además
mantiene contratos de soporte corporativo de mesa ayuda con diferentes
compañías entre las cuales se encuentra Sancho bbdo, compañía multinacional
cuya finalidad es la representación de marcas a través de multimedios
publicitarios. Otro cliente importante de esta Pyme, es Colsubsidio con quien
mantiene una relación comercial basada en contrato de repuestos a nivel nacional
de toda su infraestructura tecnológica, agregando como ítem contractual, la
prestación de servicios de soporte computacional y de impresión en sitio.
Punto de servicios ha iniciado distintos procesos de certificación de calidad, los
cuales han obligado a la compañía a iniciar un proceso de reingeniería en sus
259
procesos administrativos y operativos en sus distintas líneas de servicios. Las
líneas de servicio se mencionan a continuación.
- Soporte de Garantías a Marcas.
- Soporte En Sitio Corporativo- Mesa de Ayuda.
- Mantenimiento Preventivo Corporativo.
- Contratos de repuestos Corporativos.
Organización y flujo de procesos
Figura 60: organización y flujo de procesos
Punto de servicios S. A. cuenta con una organización la cual define una estructura
de proceso, los cuales establecen las reglas de comunicación con la misma
organización y con los clientes.
-Diagrama de procesos.
Los procesos de la compañía se mueven entorno a 4 direcciones: Gerencia,
Director Técnico, Director Comercial y Coordinador administrativo los cuales
apoyan los procesos de servicio al cliente solución de incidencias y cliente interno
de la compañía.
260
En el escenario de investigación se centrara el proceso en 3 actores que influyen
en la gestión de los procesos y como consecuencia en los indicadores de
productividad y calidad de la compañía.
Organigrama Facilitado por PUNTO DE SERVICIO
En la organización se está generando una conciencia hacia la mejora continua
vinculada a la certificación de los procesos en calidad ISO. Para lograr la
certificación de los procesos y de la compañía como tal se están efectuando
diversas tareas corporativas que vinculan a todo el personal de la organización
que se integra a los procesos operativos y administrativos entre las cuales se
encuentran:
Reuniones de Gestión
Estas reuniones se realizan con fin de mantener comunicación entre los
diferentes actores de los proceso operativos de la empresa. Además para conocer
de las relaciones y los estados actuales de los contratos de las diferentes líneas
de servicios. A nivel operativo se busca amplificar las directrices de alta gerencia
a las diferentes escalas organizativas de la compañía. Además se busca que en la
estructura se conozca los dueños de los diferentes procesos operativos como
administrativos en sus distintas áreas transversales, Financiera, administrativa,
técnica, comercial, Servicio al cliente y Gerencial.
261
Reuniones con los clientes
Estas reuniones se efectúan para conocer inquietudes u observaciones de los
clientes sobre el desempeño de diferentes recursos que participan en los
contratos que Punto de servicio tiene a su Cargo. Las reuniones implican un
análisis de los distintos servicios contratados además de su indicador principal los
SLA (Acuerdos de Nivel de Servicio).
Procesos de Capacitación y Certificación
Desde la dirección técnica con el fin de cumplir estándares de calidad establecidos
por la norma ISO, se vienen capacitando a técnicos con poca experiencia en
marcas exigentes como Apple, para tener un mejor desempeño en la prestación
de soporte a diicha marca. Los procesos de capacitación van enfocados en la
certificación de los técnicos por parte de los fabricantes de equipos a los cuales se
les presta soporte y garantía, además buscan disminuir los tiempos de repuesta
de las líneas de servicio y tener una percepción del cliente más favorable.
Calificación Interna y Externa
Se han realizado evaluaciones de desempeño por parte de las diferentes
direcciones organizativas de la empresa, estas evaluaciones vinculan Técnicos
de planta e Ingenieros de soporte radicados en proyectos de mesa de ayuda.
Los clientes también realizan diferentes evaluaciones al personal de Punto de
Servicios que participan en sus organizaciones. A nivel externo, a mediados de
Agosto de 2010 se informó a los diferentes clientes de la compañía los procesos
de certificación ISO, los clientes realizaron en formatos emitidos por Punto de
servicios la cualificación de los Ingenieros vinculados laboralmente con Punto de
Servicios que prestan servicios de soporte en sus compañías.
262
3.7.6 Gestiones de evaluación ITIL
El modelo ITIL implica generar un ámbito general en la organización teniendo en
cuenta las unidades de negocio y como tal el CORE de negocio de Punto de
servicio, se basa este estudio y el diagnóstico efectuado en las siguientes
Gestiones de buenas prácticas del modelo ITIL : Centro de Servicio, Gestión de
incidentes, Configuración y Gestión de acuerdos de niveles de servicio.
Diagnostico
Para el proceso de diagnóstico se han empleado 4 aspectos que hacen parte de
las gestiones ITIL de evaluación ya mencionadas. Administración de Procesos,
Control, Seguridad, Calidad.
Administración de Procesos
El personal de la organización conoce la visión y el objetivo de la misma, pero no
tienen una visión y objetivos propios enfocados a la compañía lo cual hace que no
se integre con claridad su propio concepto sobre los procesos operativos de la
compañía y su objetivo con la compañía sea mínimo. Por esta razón se debe
definir un plan del proceso que defina guías o estrategias que se integren con los
objetivos de la organización, además de las hojas de ruta que contemplen los
procedimientos para realizar estos objetivos.
El diagnóstico muestra que las responsabilidades no se encuentran bien definidas
en las áreas técnicas donde la línea de servicio debe ser ágil, continua y
capacitada. Aunque las responsabilidades técnicas están distribuidas la
asignación de trabajo depende de la disponibilidad de técnicos. Por ejemplo un
técnico en Apple que se encuentre con la ocupación al máximo delega la
responsabilidad de verificación y diagnostico a otro técnico asi no tenga
experiencia en el campo. Esto compromete la calidad de trabajo y tiempo de
respuesta.
263
El centro de servicios está sub utilizado, debiendo hacer registro de todos los
incidentes que atienden incluso de las pequeñas soluciones dadas directamente al
usuario, es importante que se pueda establecer una parametrización de los
diferentes casos que llegan para establecer una prioridad, la cuales deben ser
coherentes con los tiempos que se asignaran en los SLA acuerdos de niveles de
servicio que al ser medidos permitirán una mejor utilización de recursos y brindar
alternativas para el mejoramiento en los tiempos de respuesta, lo cual impacta
directamente a los usuarios
Entendiendo que una de las unidades de negocio de Punto de Servicio es la
gestión e instalación de repuestos. Existe una dependencia exagerada en
proveedores externos. Por ejemplo los tiempos de cotización compra de repuestos
e instalación demoran en promedio 15 a 30 días creando una percepción negativa
en los clientes. Aunque estos problemas se reflejan más en repuestos específicos
de equipos de marcas propietarias como lenovo, Apple, acer, representan un ítem
de desequilibrio en la gestión de procesos de la compañía y se ven reflejados en
la productividad de la organización. Los repuestos genéricos de tipo consumible o
multioperativo y funcional (Memorias, Discos Duros, Fuentes) tardan mucho
menos en ser instalados en los equipos cliente, se recomienda cambiar el proceso
de estos dispositivos sabiendo que su gestión actual es menos rigurosa que la de
repuestos específicos y de marca para este caso a nivel gerencial se recomienda
generar lo que empresarialmente se denomina integración hacia atrás, busca
tener el control de proveedores o generar los contacto comerciales que permitan
ser su propio proveedor. A nivel del proceso de cotización, compra, instalación de
repuestos específicos y propietarios de marca (Displays de portátiles, Teclados
Portatiles, entre otros) se recomienda evaluar la variedad de modelos más
representativos de las marcas y que estadísticamente representen la mayor parte
del volumen de tráfico de repuestos según marca. Por ejemplo evaluando la
cantidad de equipos de un modelo determinado que está instalada en un proyecto
como Sancho bbdo o Colsubsidio los clientes más grandes de PUNTO DE
264
SERVICIO, se podría determinar un stock de repuestos para este equipo además
de analizar la falla recurrente de estos equipos.
Para este caso también se recomienda que los Ingenieros que se encuentran
fuera del core de Punto de Servicio que prestan su servicio en proyectos de
outsourcing de la compañía tengan la información actualizada frente a trámites de
repuestos gestionados por Punto de Servicio, ya que ellos representan línea
directa de información frente al cliente corporativo externo.
En el diagnóstico se verifica que no existe una caducidad de incidencias, esto
quiere decir que la gestión para un repuesto, servicio o solución tiene rangos de
oscilación muy variado y en algunos casos muy largos, algunos casos se
resuelven en un día o inmediatamente y su seguimiento estadístico es mínimo,
para los casos sin solución temprana o por indisponibilidad del proveedor no existe
seguimiento registrado de los tiempos de respuesta de la gestión de PUNTO DE
SERVICIO. Por ejemplo si no se consigue un repuesto no se realiza un
seguimiento hasta que el cliente presenta una queja por la demora o cuando
existen reuniones de seguimiento.
Se recomienda generar en el aplicativo de gestión de incidencias sistemas de
alarmas por mail, o notificaciones que permitan informar cuando un Incidente
registrado en el aplicativo incumpla con un acuerdo de servicio pactado. Si no es
basado en la administración del aplicativo de incidencias cada parta del sistema
del recurso humano de Punto de Servicio debe conocer los acuerdos de servicio
de cada línea de servicio y sobre todo de cada cliente. Cuando se generen
observaciones en el incidente la notificación vía mail debe ser reportada al tercer
día. Esto con el fin de tener control sobre las incidencias reportadas al core de
PUNTO DE SERVICIO.
265
Para este caso lo importante es mantener los acuerdos de servicio con los clientes
cubiertos a un 100 % de acuerdo a cada línea de servicio.
En la organización no existe una herramienta de consulta que permita a los
técnicos verificar la gestión de una falla o la solución de los problemas, solo existe
el acceso a internet como mecanismo de consulta o los sistemas de solución en
línea de los fabricantes. Se recomienda una herramienta de consulta propia o
WIKI o Ayuda o How To que integre soluciones a problemas técnicos que en su
mayoría pueden ser frecuentes y presentarse en distintas líneas de servicio. Con
esto se reducirían los tiempos de repuesta y los conocimientos en fallas frecuentes
determinarían una línea de trabajo más productiva.
Durante la etapa de diagnóstico se verifica que no existe un proceso de
indagación de nuevas necesidades de cliente, por ejemplo para ampliar el
portafolio de servicios. Se recomienda generar un proceso de consulta hacia los
clientes para determinar nuevas necesidades del clientes y no solo centrarse en
los actuales acuerdos de servicio contractual sino buscar valores agregados o
nuevas líneas de servicio con esto generar un portafolio de servicios más amplio.
Con el actual diagnóstico se demuestra que gran porcentaje de la responsabilidad
de los procesos vinculados con las líneas de servicio de la compañía están
asignados a 2 cargos, Director comercial y Director Técnico. Se recomienda
diversificar la estructura de la compañía a este nivel para generar fluidez en los
procesos de toma de decisiones y de acuerdo a la estructura de PUNTO DE
SERVICIO, facilitar la compra de repuestos, el diagnóstico técnico especializado,
asignación de recursos y la coordinación de grupos de trabajo para la resolución
de problemas.
A nivel de acuerdos de servicio, se recomienda informar a toda la organización
sobre los acuerdos de servicio en los que se encuentra responsabilizado PUNTO
266
DE SERVICIO, así como los estándares de calidad frente a cada uno de los
clientes. Se debe orientar a toda la organización al cumplimiento de objetivos así
como su evaluación por este mismo mecanismo.
La información recopilada demuestra que la totalidad de los procesos de la
organización no se encuentra documentada al no estar documentados es
imposible generar una evaluación o política orientada al cambio. Se recomienda
generar en el departamento administrativo un sistema documental que permita
discriminar cada uno de los procesos vinculados o no al proceso productivo de la
organización.
La base de los procesos empresariales es la documentación, se encontraron
falencias a nivel de registro y gestión de casos. Un ejemplo es que al recibir un
Equipo que se encuentra con algún tipo de falla no se genera un reporte de su
estado físico aunque se encuentra estipulado en la orden de servicio en la
información analizada no se encontró en ningún incidente consultado esta
información o documentación, esto puede generar sobrecostos y fallas al
momento de la valoración de un equipo o en el cumplimiento o no de los periodo o
condiciones de garantía de equipos de computo. Se recomienda generar además
de las ordenes de servicio incluir un archivo visual del equipo pre-diagnóstivo que
permita establecer las condiciones iniciales del caso a valorar.
El grupo de trabajo recomienda estructurar el departamento de almacén el cual
debe verificar los dispositivos en stock, gestión de repuestos, y administración de
equipos en reparación o alistamiento para retiro de Punto de Serviciopor parte de
clientes y usuarios.
Control
El diagnóstico muestra que no existe un mecanismo de control tecnológico sobre
los procesos de la compañía, ya que el software encontrado está aislado para
algunos procesos de la organización, no existe un sistema trasversal que acople
267
todas las áreas de la compañía como lo sería un sistema de gestión documental.
Se propone un sistema global que permita la gestión de clientes. A nivel de
clientes se deben administrar no solo incidencias que se registran a partir de los
clientes que visitan las instalaciones de PUNTO DE SERVICIO, sino también debe
existir para administrar incidencia externas a partir de un portal o un front end, que
permita a los clientes asignar incidencias a los recursos de Punto de Servicio
desde sus instalación.
Se propone la creación de una aplicación web con acceso externo. Actualmente
se verifica que las incidencias asignadas por los Ingenieros externos ubicados en
proyectos o compañías en outsourcing Punto de Servicio para la solicitud de
partes o servicios especializados, realizan estas asignaciones vía mail, o vía
telefónica, esto implica que no se tenga información complementaria sobre los
trámites o su curso, disponibilidad de partes y tiempo de respuesta.
El diagnóstico demuestra que se requiere evaluar un proyecto para la
implementación y mejora de los sistemas de información de la compañía así como
los recursos de conectividad de Punto de Servicio con sus clientes.
Se recomienda crear sistema de información corporativa (intranet, wiki, etc) de
bajo costo y que funcione como base de conocimientos para la atención de
incidentes y que preste también servicios de información para el personal sobre
futuros cambios en la compañía. Cambios que se pueden exponer en
modificaciones a procesos, la entrada de nuevos clientes o simplemente exponer
nuevas políticas de la compañía, en este caso se puede incluir acceso a los
sistemas de ayuda de la compañía que ya se había recomendado anteriormente.
Calidad
Otro aspecto analizado en este diagnóstico, es la calidad según la evidencia
encontrada en PUNTO DE SERVICIO, Se recomienda establecer un
departamento de calidad e incorporarlo de manera trasversal a todas las áreas de
268
la compañía. A nivel técnico se debe generar una política de calidad que se
enfoque en seguir las normas técnicas establecidas por los fabricantes a los
cuales se les presta soporte así como evaluar continuamente al personal sobre
esquemas planteados por entidades tecnológicas reconocidas.
Se recomienda facilitar procesos de certificación del personal técnico de PUNTO
DE SERVICIO, para asegurar la calidad de los procesos técnicos. También se
recomienda crear un agente de calidad que apruebe o descarte los diferentes
trabajos asignados al personal técnico de PUNTO DE SERVICIO. Los procesos
deben estar documentados para asegurar la calidad de la resolución de casos.
Verificando las evidencias que se integran a los procesos de calidad en el área
técnica, se recomienda equipar al personal técnico con la herramienta adecuada
así como establecer una política de manejo adecuado de la misma.
3.7.7 Alternativas de Software para Sistemas de Gestión de incidencias
Mantis Bug Tracker
Es un gestor de Incidencias, libre ligero, utiliza una base de datos de Mysql. Este
sistema determina las necesidades de implementación en PUNTO DE SERVICIO.
Aunque se encuentra aplicado a sistemas de gestión de desarrollo de software, su
versatilidad integraría los procesos necesarios para la gestión de incidentes que
requiere PUNTO DE SERVICIO.
GLPI
Es una herramienta que permite la gestión de Incidencias, tiempos de respuesta,
inventarios, es una aplicación muy versátil de código abierto GNU/GPL. Facilita la
administración de recursos de tecnología, permite el seguimiento de contratos y la
269
asignación de recursos. Administración de licencias, documentación anexa a
procesos de tecnología, Multiusuario con diferentes niveles de permisos, Múltiple
autentificación - local, LDAP, AD,POP/IMAP, etc., Sistema de búsquedas
avanzada, Reportes en PDF, CSV y SLK, Respaldo de la base de datos en
formato SQL, Exportación de la base de datos en XML, Sistema de notificaciones
de stock, contratos y licencias, Seguimiento de incidencias desde la interfase web
o por email, Posibilidad de agregar comentarios a las incidencias por interfase web
o por email, Histórico de las incidencias por equipo y por técnico, Manejo de
planeamiento de resolución de incidencias, Estadísticas por técnico, hardware,
usuario, categoría, prioridad, etc., Reserva de insumos.
Modificación del software actual
Otra alternativa es contar con un ingeniero de programación que les permita
modificar el sistema actual y adaptarlo a las necesidades de gestión de incidentes
desde el punto de las recomendaciones de ITIL.
Para el caso de Punto de servicio esta es la opción mas recomendada, permite
una mejor adaptación de los gestores de las áreas de soporte y puede resultar
muy económica.
3.7.8 Implementación de las recomendaciones, Modelo ITIL.
De acuerdo a la guía de implementación, debe existir en Punto de Servicio un
promotor del modelo ITIL, según en la etapa de diagnóstico no se reportó ningún
conocimiento por parte de la organización del modelo ITIL. Para la
implementación en Punto de Servicio se recomienda que este proceso sea
encabezado por la gerencia general ya que la disposición de la organización
implica que el resto de los recursos estén con disponibilidad mínima para afrontar
la implementación de los procesos y las gestiones de ITIL. Inicialmente la
implementación en Punto de Servicios debe enfocar en el estudio de las buenas
270
prácticas de las gestiones: Centro de Servicio, Gestión de incidentes,
Configuración y Gestión de acuerdos de niveles de servicio. Se propone la
posibilidad que el grupo de investigación sirva como ente promotor en llave con la
alta gerencia de la compañía.
3.7.9 Conveniencia del modelo ITIL
En reunión con la Coordinadora administrativa en una reunión de 1 hora, se
comentó la importancia de esta implementación al inicio, la CA, no mostró interés
en este estudio más allá de la colaboración académica, al exponer los ítems de
conveniencia de este proceso y los altos niveles de productividad que alcanzan las
organizaciones que adoptan ITIL en su manual de procesos, la CA genero interés
en la idea. La coordinadora administrativa demostró las falencias en los procesos
tanto técnicos como administrativos. El escenario ITIL genera un proceso
escalonado de mejoras aplicadas a toda la organización PUNTO DE SERVICIO.
271
CONCLUSIONES
ITIL surge como un conjunto de recomendaciones y mejores prácticas para
indicar a los gerentes de TI el mejor método de organizar las actividades de su
departamento, de modo que proporcione un mejor servicio a toda la compañía
y haga que esta sea más competitiva ante otras del mercado.
ITIL ayuda en la necesidad de reducir el riesgo frente a la competencia y
mejorar el control mediante procesos predecibles y homogéneos.
La información obtenida a través de esta investigación nos permite mediante
su diagnostico, definir los procesos óptimos que faciliten la implementación de
ITIL en la empresa Punto de Servicio, sin necesidad de incurrir en grandes
costos.
Mediante la ejecución del diagnostico se destaca el echo de que las gestiones
interactúan entre si, y que es necesario tener esto en cuenta al momento de
definir los procesos para realizar una implementación por los fuertes vínculos
de relación entre las gestiones.
Antes de hacer un análisis de diagnostico se deben identificar las áreas claves
y los objetivos de la empresa.
Para el estudio de diagnostico fue crucial el apoyo de la gerencia y establecer
un grupo de trabajo en donde cada área tenía un representante que estaba al
tanto de los procesos de su área y como estos se relacionaban con las demás.
La flexibilidad que da ITIL permite que se aplique a la empresa Punto de
Servicio, sin importar que sea una PYME o baja capacidad operativa.
La implementación de ITIL debe estar siempre orientada al mantenimiento del
negocio buscando sacar el mayor provecho implementándose siempre en
donde sea necesario y en donde la inversión de recursos y tecnología sea
recuperable.
El monitoreo constante de las áreas que intervienen en las gestiones es
importante, pues es la única forma que se puede medir y ajustar los procesos
claves de las áreas implicadas.
272
RECOMENDACIONES
Se recomienda a la universidad hacer énfasis en las materias orientadas a la
gerencia y administración de ambientes de tecnología, la globalización económica
genera apertura de mercados lo que nos enfrenta ante las necesidades de un
mercado que busca profesionales con las capacidades que permitan a una
empresa hacer uso de la tecnología para destacar en el mercado.
273
BIBLIOGRAFÍA
ACTUALICESE.COM. Ley 905 del 2 de agosto del 2004 [en línea]. Disponible en: http://actualicese.com/normatividad/2004/Ley/L905-04.htm [Consulta: 29/08/2010] ACTUALICESE.COM. Ley 590 del 10 de Julio del 2000 [en línea]. Disponible en: http://www.actualicese.com/normatividad/2000/07/10/ley-590-de-10-07-2000/ [Consulta: 29/08/2010] ANIF. La gran encuesta pyme 2010 [en línea]. Disponible en: http://www.anif.org/includes/scripts/open.asp?ruta=/images/dynamic/articles/2832/EncuestaI-10.pdf [Consulta: 31/08/2010] APM Group – The Accreditor. What is ITIL? [en línea]. Disponible en: http://www.itil-officialsite.com/AboutITIL/WhatisITIL.asp [Consulta: 21/08/2010] ARANDA SOFTWARE. Consorcio FIDUFOSYGA 2005 - Consultoría e Implantación del Plan de Operaciones de Sistemas alineado con ITIL [en línea]. Disponible en: http://www.arandasoft.com/downloads/testimonios/casoExito_ITIL_Fosyga-V1.0.pdf [Consulta: 20/08/2010] BUSINESSCOL.COM. Sección PYMES. [en línea]. Disponible en: http://www.businesscol.com/empresarial/pymes/ [Consulta: 21/08/2010] CA® TRASNSFORMING IT MANAGEMENT. ISAGEN presenta su Punto Único de Contacto para gestionar servicios de negocio, [en línea]. Disponible en: http://www.ca.com/files/successstories/081209_sfhp_successstory_isagen_es_194164.pdf [Consulta: 20/08/2010] COLOMBIA DIGITAL. ¿Qué es una Mipyme? [en línea]. Disponible en: http://colombiadigital.net/index.php?option=com_content&view=article&id=376&Itemid=313 [Consulta: 26/08/2010] COLOMBIA INCLUYENTE. El trabajo en desarrollo empresarial [en línea]. Disponible en: http://go.microsoft.com/fwlink/?LinkId=121315 [Consulta: 26/08/2010] Consultor ITERA Colombia, Presentación introductoria diagnóstico situación actual CERRO MATOSO CMSA. DIARIO LA REPUBLICA. Indicador Pyme Anif: Midiéndole el pulso a las Pymes [en línea]. Disponible en: http://rse.larepublica.com.co/archivos/OPINION/2010-08-
274
02/indicador-pyme-anif-midiendole-el-pulso-a-las-pymes_106960.php [Consulta: 31/08/2010] E-GLOBAL PROFESIONALES EN TICs. Nuestros clientes - casos de éxito – mesa de ayuda [en línea]. Disponible en: http://www.e-global.com.co/portal/NuestrosClientes/Casosde%C3%A9xito/Corantioquia/tabid/79/Default.aspx [Consulta: 19/08/2010] Fanning Peter, Service Desingn. Ed The stationary office. LONDON, 2007. ISBN 978 0 11 331047 0 FORMACION Y CURSOS. Utilidad y tipos de certificaciones ITIL [en línea]. Disponible en: http://www.formacioncursos.com/2009/02/tipos-certificaciones-itil.html# [Consulta: 23/07/2010] INGENIAN SOFTWARE. Clientes - casos de éxito – fiscalía general de la nación [en línea]. Disponible en: http://ingenian.com/web/public/exito [Consulta: 15/08/2010] INGENIAN SOFTWARE. Clientes - casos de éxito – Secretaría Distrital de Ambiente de Bogotá D.C [en línea]. Disponible en: http://ingenian.com/web/public/exito [Consulta: 15/08/2010] ITILLIBRARY. Welcome to the Itil Open Guide [en línea]. Disponible en: http://www.itlibrary.org/index.php?page=ITIL [Consulta: 15/07/2010] ITIL LATINOAMERICA. Introducción ITIL Colombia [en línea]. Disponible en: http://www.itil.com.ar/ [Consulta: 21/08/2010] ITSENCIAL. Las buenas para las TI [en línea]. Disponible en: http://itsencial-elvalordelatecnologia.blogspot.com/2008/01/las-buenas-prcticas-para-las-ti.html [Consulta: 23/09/2010] ITSMF España. Tendencias en Gestión de TI: El futuro de ITSM [en línea]. Disponible en: http://www.itsmf.es/index.php?searchword=itil&ordering=&searchphrase=all&Itemid=54&option=com_search [Consulta: 19/07/2010] LATINOAMERICA ISO 20000. Introducción a la ISO Dominicana [en línea]. Disponible en: http://www.iso20000.com.ar/intro_dom.html [Consulta: 02/10/2010] ORGANIZACIÓN OSIATIS ESPAÑA. ITIL – Gestión de Servicios TI – Fundamentos de la gestión de TI - ¿Qué es ITIL?. [en línea]. Disponible en: http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/fundamentos_de_la_gestion_TI/que_es_ITIL/que_es_ITIL.php [Consulta: 22/07/2010]
275
PINK ELEPHANT. Caso de Éxito Dexon Software Inc [en línea]. Disponible en: http://dexon.us/images/descargas/casos_de_exito/caso_pink.pdf [Consulta: 23/08/2010]
Revista ITmanager, articulo Pymes a la carga por Rozo G Noviembre de 2008
SCRIBD. Exposición tgs (2003) – Auditoria de sistemas [en línea]. Disponible en: http://www.scribd.com/doc/23599285/exposicion-tgs-2003 [Consulta: 22/08/2010] SOLIS, Isabel. El análisis documental como eslabón fundamental para la eficiencia de los servicios de información. Cuba [en línea]. Disponible en: http://www.monografias.com/trabajos14/analisdocumental/shtm [Consulta: 20/10/2010] TORMO & ASOCIADOS S.L. 2010 rodaría mejor para las pymes [en línea]. Disponible en: http://www.tormo.com.co/noticias/8177/2010%20rodar%C3%ADa%20mejor%20para%20las%20pymes [Consulta: 01/10/2010]
276
ANEXOS
ANEXO A: Encuestas por gestión de la primera fase
Esta serie de preguntas preliminares determinaran la situación actual de cada una de las gestiones en la organización
Por cada pregunta afirmativa otorgue un valor de 1, por respuesta negativa otorgue un valor de 0,
En las preguntas de triple opción, otorgue un valor de 1 a 3, Según la importancia que le dé al caso: 1 para bajo, 2 medio, 3 alta
CENTRO DE SERVICIO Tiene contacto con los clientes internos o externos en su área?
Si No
Tiene un área u grupo destinado para contactar o interactuar con sus clientes
Si No
Posee un sistema para gestionar incidentes y/o problemas de TI los cuales serán tomados por un área de soporte?
Si No
Otorgue un valor de 1 a 3, Según la importancia que le dé al caso: 1 para bajo,
2 medio, 3 alta Que nivel de importancia le da al área que realiza contacto con el cliente
ALTA MEDIA BAJA
Que importancia Tiene para su negocio el reporte de incidentes?
ALTA MEDIA BAJA
277
Esta serie de preguntas preliminares determinaran la situación actual de cada una de las gestiones en la organización
Por cada pregunta afirmativa otorgue un valor de 1, por respuesta negativa otorgue un valor de 0,
En las preguntas de triple opción, otorgue un valor de 1 a 3, Según la importancia que le de al caso: 1 para bajo, 2 medio, 3 alta
GESTION DE INCIDENTES Posee áreas especializadas en dar soporte a clientes interno o externo del orden de TI
Si NO
Tiene servicios o actividades que de fallar se vería seriamente afectado su negocio?
Si NO
Otorgue un valor de 1 a 3, 1 para bajo, 2 medio, 3 alta Es importante para usted el seguimiento de los casos o incidencias que llegan a las áreas de soporte e incidentes
ALTA MEDIA BAJA
que nivel de importancia le da al área que se encarga de resolver los incidentes?
ALTA MEDIA BAJA
Que importancia Tiene para su negocio restablecer los servicios, procesos o componentes de sus usuarios?
ALTA 3 MEDIA BAJA
278
Esta serie de preguntas preliminares determinaran la situación actual de cada una de las gestiones en la organización
Por cada pregunta afirmativa otorgue un valor de 1, por respuesta negativa otorgue un valor de 0,
En las preguntas de triple opción, otorgue un valor de 1 a 3, Según la importancia que le de al caso: 1 para bajo, 2 medio, 3 alta
GESTION DE PROBLEMAS Posee un área encargada de hacer seguimiento a los incidentes que se presenten continuamente?
Si NO
Tiene procesos o servicios que podrían afectar a un alto porcentaje de sus clientes de tener algún problema?
Si NO
Realiza seguimiento a los problemas detectados en su área y los divulga a todo el grupo
Si NO
Otorgue un valor de 1 a 3, 1 para bajo, 2 medio, 3 alta
que nivel de importancia le da al área que se encarga de seguir los incidentes repetitivos o los problemas detectados
ALTA MEDIA BAJA
Que importancia Tiene para su negocio el control y divulgación de los problemas detectados?
ALTA MEDIA BAJA
279
Esta serie de preguntas preliminares determinaran la situación actual de cada una de las gestiones en la organización
Por cada pregunta afirmativa otorgue un valor de 1, por respuesta negativa otorgue un valor de 0,
En las preguntas de triple opción, otorgue un valor de 1 a 3, Según la importancia que le de al caso: 1 para bajo, 2 medio, 3 alta
GESTION DE LA CONFIGURACION. Tiene configurada una base de datos de los elementos de configuración?
Si NO
Diversas áreas de la organización deben recurrir a la base de elementos de configuración con alguna periodicidad?
Si NO
Otorgue un valor de 1 a 3, 1 para bajo, 2 medio, 3 alta
Que nivel de importancia tiene para la organización la CMDB
ALTA MEDIA BAJA
Que importancia Tiene para su negocio el control de hardware y software de la organización?
ALTA MEDIA BAJA
280
Esta serie de preguntas preliminares determinaran la situación actual de cada una de las gestiones en la organización
Por cada pregunta afirmativa otorgue un valor de 1, por respuesta negativa otorgue un valor de 0,
En las preguntas de triple opción, otorgue un valor de 1 a 3, Según la importancia que le de al caso: 1 para bajo, 2 medio, 3 alta
GESTION DE CAMBIOS Existe una persona, grupo o área responsable de los procesos de planificación de cambios, su autorización y posterior control? .
Si NO
son Justificados todos los cambios aplicados en la organización teniendo en cuenta los potenciales riesgos?
Si NO
Otorgue un valor de 1 a 3, 1 para bajo, 2 medio, 3 alta
En el pasado la implementaron de cambios ocasionó perdida en la prestación de servicios o afecto directa o indirectamente a los clientes?
ALTA MEDIA BAJA
Es Importante que todas las personas de la organización están enteradas a ante un cambio inminente?
ALTA MEDIA BAJA
281
Esta serie de preguntas preliminares determinaran la situación actual de cada una de las gestiones en la organización
Por cada pregunta afirmativa otorgue un valor de 1, por respuesta negativa otorgue un valor de 0,
En las preguntas de triple opción, otorgue un valor de 1 a 3, Según la importancia que le de al caso: 1 para bajo, 2 medio, 3 alta
GESTION DE VERSIONES Cuenta con una librería de hardware y software actualizada?
Si NO
Los cambios en versiones están cuidadosamente documentados para que todas las partes conozcan sus tareas y responsabilidades específicas?
Si NO
Otorgue un valor de 1 a 3, 1 para bajo, 2 medio, 3 alta
Cuando se realiza el lanzamiento de una versión es importante que los usuarios finales estén informados del calendario de lanzamiento y de cómo este puede afectar a sus actividades diarias?
ALTA MEDIA BAJA
Es importante para Área que después de la implementaron de una versión se recojan los comentarios, quejas, incidentes, etc. que la nueva versión haya podido suscitar?
ALTA MEDIA BAJA
282
Esta serie de preguntas preliminares determinaran la situación actual de cada una de las gestiones en la organización
Por cada pregunta afirmativa otorgue un valor de 1, por respuesta negativa otorgue un valor de 0,
En las preguntas de triple opción, otorgue un valor de 1 a 3, Según la importancia que le de al caso: 1 para bajo, 2 medio, 3 alta
Gestión de Niveles de Servicio Conoce las necesidades de sus clientes y monitorea la calidad del servicio que le ofrece?
Si NO
Tiene definidos correctamente los servicios ofrecidos a sus clientes?
Si NO
Otorgue un valor de 1 a 3, 1 para bajo, 2 medio, 3 alta
Para usted alinear la tecnología con los procesos de negocio tiene un grado de importancia?
ALTA MEDIA BAJA
Para usted la necesidad de establecer acuerdos de niveles de servicio con los clientes tiene un grado de importancia?
ALTA MEDIA BAJA
283
Esta serie de preguntas preliminares determinaran la situación actual de cada una de las gestiones en la organización
Por cada pregunta afirmativa otorgue un valor de 1, por respuesta negativa otorgue un valor de 0,
En las preguntas de triple opción, otorgue un valor de 1 a 3, Según la importancia que le de al caso: 1 para bajo, 2 medio, 3 alta
Gestión Financiera Tiene establecida una política consistente de precios?
Si NO
Se presupuestan correctamente los gastos asociados a las áreas de tecnología?
Si NO
Otorgue un valor de 1 a 3, 1 para bajo, 2 medio, 3 alta
Para usted la importancia de evaluar y controlar los costes asociados a los servicios TI es?
ALTA MEDIA BAJA
Para usted es importante justificar los precios ante el resto de la organización y otras áreas de TI?
ALTA MEDIA BAJA
284
Esta serie de preguntas preliminares determinaran la situación actual de cada una de las gestiones en la organización
Por cada pregunta afirmativa otorgue un valor de 1, por respuesta negativa otorgue un valor de 0,
En las preguntas de triple opción, otorgue un valor de 1 a 3, Según la importancia que le de al caso: 1 para bajo, 2 medio, 3 alta
Gestión de la Capacidad Desarrolla planes de capacidad asociados a los niveles de servicio acordados con los clientes?
Si NO
Cuenta con una planificación que le permite facilidad en la asignación de recursos a sus diferentes servicios de TI?
Si NO
Otorgue un valor de 1 a 3, 1 para bajo, 2 medio, 3 alta
Que importancia tiene para usted asegurar la capacidad de los servicios de TI
ALTA MEDIA BAJA
Para usted la importancia del monitoreo, análisis y evaluación del rendimiento y capacidad de la infraestructura TI es?
ALTA MEDIA BAJA
285
Esta serie de preguntas preliminares determinaran la situación actual de cada una de las gestiones en la organización
Por cada pregunta afirmativa otorgue un valor de 1, por respuesta negativa otorgue un valor de 0,
En las preguntas de triple opción, otorgue un valor de 1 a 3, Según la importancia que le de al caso: 1 para bajo, 2 medio, 3 alta
Gestión de la Continuidad del Servicio La compañía mantiene programas de servicio que satisfagan el nivel de cumplimiento con los clientes.?
Si NO
En la compañía existen recursos que permitan disminuir la afectación de un servicio por falla en los recursos de TI
Si NO
Otorgue un valor de 1 a 3, 1 para bajo, 2 medio, 3 alta
Para la compañía que importancia tienen la continuidad de servicios, basados en pólizas contractuales 7X24
ALTA MEDIA BAJA
La importancia de la asignación de recursos y esfuerzos para mantener la continuidad de los servicios respaldos al clientes
ALTA MEDIA BAJA
286
Esta serie de preguntas preliminares determinaran la situación actual de cada una de las gestiones en la organización
Por cada pregunta afirmativa otorgue un valor de 1, por respuesta negativa otorgue un valor de 0,
En las preguntas de triple opción, otorgue un valor de 1 a 3, Según la importancia que le de al caso: 1 para bajo, 2 medio, 3 alta
Gestión de la Disponibilidad Existe una política de monitoreo de servicios de TI en la Organización
Si NO
Existe un análisis de impacto de fallas en el core IT de la organización
Si NO
Otorgue un valor de 1 a 3, 1 para bajo, 2 medio, 3 alta
Que importancia tienen los tiempos de respuesta a posibles incidencias o causas de interrupción de los servicios IT en la organización
ALTA MEDIA BAJA
La importancia reflejada a los tiempos de detección y restauración de los servicios de IT es
ALTA MEDIA BAJA
287
Esta serie de preguntas preliminares determinaran la situación actual de cada una de las gestiones en la organización
Por cada pregunta afirmativa otorgue un valor de 1, por respuesta negativa otorgue un valor de 0,
En las preguntas de triple opción, otorgue un valor de 1 a 3, Según la importancia que le de al caso: 1 para bajo, 2 medio, 3 alta
Gestión de la Seguridad En la compañía existen políticas de aseguramiento de Información de clientes internos y externos
Si NO
La compañía maneja políticas de confidencialidad para establecer niveles de acceso a la información
Si NO
Otorgue un valor de 1 a 3, 1 para bajo, 2 medio, 3 alta
Para la organización los estudios de riesgos tienen una importancia
ALTA MEDIA BAJA
La importancia de los acuerdos de servicios y distintas obligaciones para la prestación de servicios de IT es
ALTA MEDIA BAJA
288
ANEXO B: Encuestas por gestión para la segunda fase
Centro de Servicios
Tiene un área que Interactúa con usuarios
Si No
El área de contacto con el usuario funciona como centro neurálgico de todos los procesos de soporte al servicio
Si No
Su área de contacto Registra los incidentes de los usuarios
Si No
Su área de contacto monitoriza incidentes.
Si No
Su área aplica soluciones a errores conocidos en colaboración con las áreas técnicas
Si No
Su área de contacto colabora con la actualización de las bases de datos Sobre problemas.
Si No
Su área de contacto gestiona cambios solicitados por los clientes mediante peticiones de servicio.
Si No
Su área de contacto hace análisis del problema registrado en el incidente?
Si No
289
Su área de contacto cierra incidentes y confirma con los clientes.
Si No
Su área de contacto le informa a sus usuarios la prioridad de atención y tiempo relacionado que tendrá la atención del caso?
Si No
¿Usa algún sistema de registro de incidentes o software de Helpdesk?
Si No
(Solo quien respondió SI) ¿Cómo encuentra el producto?
Se ajusta a las necesidades, pero hace falta un administrador que pueda adaptarlo a la medida del crecimiento de la organización
¿Dispone de reportes mensuales indicando la productividad de los recursos TI
(tiempo de respuesta, problemas solucionados, etc.)
Si No
Todos los incidentes pasan por un proceso de Evaluación de la prioridad?
Si No
Tanto los operadores de incidentes como los usuarios conocen los tiempos para
cada prioridad?
Si No
290
Gestión de Incidentes
Tiene un área o personal encargado de hacer la atención de los incidentes registrados en el centro de servicios (Llamado de ahora en adelante centro de soporte)
Si No
Los casos o incidentes reportados al centro de soporte tienen una categorización de prioridad y/o impacto?
Si No
El centro de soporte tiene una bese de conocimiento con errores y soluciones frecuentes? (Bitácora, wiki, base de datos, etc)
Si No
Se guarda la solución y problema en la base de conocimientos para futuras consultas?
Si No
El centro de soporte se divide en sub - áreas especializadas?
Si No
Cuando se soluciona un incidente se registra el proceso realizado en el sistema en donde se creo el mismo?
Si No
Una vez cerrado el caso se monitorea el tiempo de atención
Si No
Se emiten informes con algún tipo de frecuencia indicando el nivel de atención, cumplimiento y tiempos de los casos?
Si No
Para resolver los incidentes, se hace una asignación de recursos en el centro de soporte?
291
Si No
Se realizan actualizaciones de los diferentes procesos realizados en el sistema donde se relaciono el incidente?
Si No
En que área cree que se toma mas tiempo para resolver problemas de los clientes
Área técnica (Incidentes) omiten procedimientos
¿Dispone de reportes mensuales indicando la productividad de los recursos TI
(tiempo de respuesta, problemas solucionados, etc.)
Si No
De que forma es Medido el cumplimiento del tiempo de cada incidente?
Tiene una forma de control para actualizaciones de incidente?
Si No
Consulta la Base de Conocimiento para investigar si el incidente es
consecuencia de un error conocido?
Si No
Realiza pruebas de cada incidente solucionado?
Si No
292
Gestión de Problemas
Se realiza análisis de casos con problemas comunes que son reportados al centro de soporte?
Si No
Mantiene informadas a las diferentes áreas de TI de los problemas encontrados.?
Si No
Se relacionan a los incidentes reportados a los problemas conocidos?
Si No
Se realiza una Investigación de las causas comunes que afecten estos casos y se invierten recursos en la posibles soluciones a las mismas. ?
Si No
Determina una solución temporal para ser aplicada por el centro de soporte mientras se soluciona el problema?
Si No
Propone las peticiones de cambio necesarias para solucionar estos problemas y evalúa si el beneficio del cambio justifican los costes?
Si No
Cuando el problema es resuelto mediante un cambio al origen del mismo, informa a sus áreas de TI?
Si No
Se emiten reportes periódicos de los problemas presentados y resueltos?
Si No
Se alimentan las bases de conocimientos con la información de problemas y soluciones?
293
Si No
Realizar Revisiones Post Implementación para asegurar que los cambios han surtido los efectos buscados sin crear problemas de carácter secundario.
Si No
Observa en su empresa problemas repetitivos que tiene que resolver la gente de sistemas.
Si No
Tiene equipos, sistemas o procedimientos para aplicar posibles soluciones
temporales?
Si No
Cuales?
Contacta con otra área, departamento o proveedor de sistemas previendo que el
incidente pueda repetirse durante un lapso de tiempo?
Si No
Cuenta con alguna aplicación que le permita realizar control la gestión de
problemas?.
Si No
Se establece de las posibles causas?
Si No
Realiza la comprobación de la causa más probable?
Si No
Realiza Verificación de la causa verdadera, y hace pruebas en varios de los
incidentes reportador?
294
Si No
Se genera un control de cambios con cada problema resuelto?
Si No
Se evalúa los tiempos de tramite de solución, y recursos invertidos en cada
problema?
Si No
Se realiza una evaluación del impacto del problema para la organización?
Si No
295
Gestión de Configuraciones
Poseen y lleva control de una Base de Datos de los elementos de Configuración (CMDB) de TI? (Físicos y lógicos)
Si No
Las diferentes áreas de TI que intervienen en la gestión de Incidentes, Problemas, Cambios y Versiones tienen acceso a la información de los elementos de configuración de TI y la actualizan constantemente?
Si No
Se monitorea y actualiza periódicamente Información de los elementos de configuración
Si No
Existe información de las relaciones entre los diferentes elementos de configuración? (Padre – hijo, interdependencias)
Si No
Existe un tipo de nomenclatura utilizada para cada item de configuración?
Si No
Se monitorea con frecuencia el estado de los elementos de configuración?
Si No
Los elementos de configuración están compuestos por Hardware, software y documentación (SLA, SLO, Auditorias, licencias, etc)
Si No
Existe un responsable de la CMDB y su gestión?
Si No
Se ha definido una herramienta de control y un nivel de profundidad en el detalle de la CMDB?
296
Si No
Se realizan informes periódicos de la información y configuración registrada en la CMDB?
Si No
¿Se lleva un registro de los recursos informáticos y tecnológicos de la Organización?
Si No
¿Considera esto útil?
Si No
¿Cuenta en su empresa con una base de conocimientos que permite inferir
respuestas a problemas comunes?
Si No
Indique cual de las siguientes opciones cuenta hoy en día su organización:
a. Inventario de Hardware
b. Inventario de Software
c. Gestión de incidentes
d. Gestión de problemas
e. Encuesta de satisfacción al cliente
Indique de las opciones anteriores cuales de ellas les resultaría útil o cuales
desearía tener y por que
Incidentes
Consulta, mediante la aplicación que monitoriza las existencias de almacén de
equipos y repuestos?
Si No
297
Gestión de Cambios
Posee un método para planificar y evaluar los procesos de cambios y de esta forma asegurar que si éste se lleva a cabo, se haga de la forma más eficiente?
Si No
Su gestión de cambios se preocupa por mantener la calidad y disponibilidad del servicio durante un cambio?
Si No
Se tienen en cuanta la integridad de las bases de datos durante la aplicación de cambios?
Si No
Los cambios se realizan mediante una única petición la cual es clasificada, estudiada y aprobada por un único individuo o grupo que se encarga de evaluar el riesgo y la posibilidad de dicho cambio?
Si No
Se crea un cronograma para la aplicación de cambios y se informa a toda la organización del mismo y a las áreas de TI para que se preparen para dicho cambio?
Si No
Se crean planes para volver a la configuración previa en caso de que un cambio tenga inconvenientes (Back-out)
Si No
En el caso de que se deba aplicar un Back out, se crean medidas para evitar la perdida de datos?
Si No
Se evalúa el cumplimiento de los objetivos y de las perspectivas de clientes y usuarios ante la implementación del cambio
298
Si No
Se emiten informes de rendimiento de cada uno de los cambios realizados?
Si No
299
Gestión de Versiones
Dispone de una gestión encargada de la implementación y control de calidad de todo el software y hardware instalado en el entorno de producción?
Si No
Mantiene una Biblioteca actualizada de Software (DSL), donde se guardan copias de todo el software en producción, y de Depósito de Hardware (DHS), donde se almacenan piezas de repuesto y documentación para la reparación de problemas en el entorno de producción.?
Si No
Se realiza una planeación para la ejecución de una nueva versión?
Si No
Se crea un entorno de pruebas para la emulación y aplicación de las nuevas versiones
Si No
Se toma en cuenta la disponibilidad del servicio durante y tras el proceso de lanzamiento de la nueva versión.
Si No
Antes de la implementación de una versión, se realiza la documentación para usuarios y personal de servicio, y se difunde entre los usuarios?
Si No
Se realiza control de fuentes, para que solo un usuario o grupo trabaje en ellas a la vez?
Si No
Todas las versiones son documentadas y llevan un numero consecutivo de control y versión
Si No
300
Una vez aplicada una versión se actualiza la Biblioteca de software, el deposito de hardware y la CMDB?
Si No
Se supervisa la calidad de la aplicación de la versión y se generan Informes de rendimiento.
Si No
301
Gestión de Niveles de Servicio
Cuenta con una Definición correctamente los servicios ofrecidos.
Si No
Conoce las necesidades de sus clientes, y orienta su servicio a satisfacer esta necesidades?
Si No
Existe un monitoreo constante de la calidad del servicio?
Si No
Se llevan a cabo acuerdos de niveles de servicio entre clientes y proveedores de servicio, para establecer prioridades y tiempos de respuesta?
Si No
Elabora métricas que le permiten evaluar los niveles de servicio?
Si No
Las áreas de centro de soporte disponen de un documento de referencia para la relación con el cliente en todo lo que respecta a la provisión de los servicios acordados, como su descripción, disponibilidad, niveles de calidad, tiempos de recuperación, etc.
Si No
Se dispone de un documento interno para la organización donde se especifican las responsabilidades y compromisos de los diferentes departamentos de TI en la prestación de un servicio?
Si No
Existe un documento en donde se especifiquen cuáles serán los indicadores clave de rendimiento para cada uno de los servicios prestados?
302
Si No
Cada uno de sus servicios dispone de una guía dirigida a los clientes para que a la hora de seleccionar un servicio, este se adapte a sus necesidades y no se presenten mal entendidos futuros?
Si No
Los informes de rendimiento elaborados incluyen factores como: Cumplimiento de los SLAs, nivel de satisfacción de cada cliente, tiempos de respuesta, problemas detectados, cambios realizados, y calidad del servicio de los proveedores externos?
Si No
Se establecen niveles de urgencia y prioridad para la atención de incidentes los cuales conoce el usuario final y en el momento de la medición se presentan resultados para cada una de estas clasificaciones?
Si No
303
Gestión de la Continuidad del Servicio
Existe alguna política o proceso para prevenir la interrupción de los servicios de tecnología, Desastres Naturales o Informáticos
Si No
La organización implementa Procedimientos Proactivos que eviten la interrupción de los Servicios de IT para Clientes Internos o Externos.
Si No
La organización implementa Procedimientos Reactivos que eviten la interrupción de los Servicios de IT para Clientes Internos o Externos.
Si No
Existen niveles de Gestión de riesgos en la organización
Si No
Existen parámetros de medición de interrupción de servicios IT
Si No
En los Acuerdos de niveles de servicio con clientes internos y externos se validan las tolerancias de interrupciones de servicios
Si No
Los procesos de gestión de riesgos tienen prioridad en la organización
Si No
Se integran en el presupuesto de la compañía los posibles planes de contingencia vinculados a las interrupciones de los servicios de IT
Si No
Se realizan estudios programáticos sobre las vulnerabilidades informáticas de la compañía frente a desastres Naturales e Informáticos
304
Si No
Se integran al estudio de vulnerabilidades Informáticas las posibles afectaciones al core del negocio. O las afectaciones globales a las unidades de Negocio
Si No
Se ponen a prueba los planes de contingencia adoptados para proteger la continuidad de los servicios de la infraestructura IT
Si No
305
Gestión de Disponibilidad
Existen procedimientos estandarizados para la disponibilidad de servicios IT 7X24
Si No
Se realizan estudios de requerimientos de servicios de IT sobre clientes Internos y Externos
Si No
Para el caso de la mejora continua. Se enfoca los esfuerzos de la organización en la Innovación de infraestructura que permita la optimización de la disponibilidad de servicios IT
Si No
Existen políticas y estándares de cumplimiento basados en los contratos de Soporte y los acuerdos de nivel de operación con clientes Internos y Externos.
Si No
Existen indicadores de cumplimiento de disponibilidad de servicios de infraestructura IT
Si No
Se desarrollan planes de disponibilidad de servicio en la organización que garanticen el parámetro 7X24 en servicios IT para clientes Internos y Externos
Si No
Se evalúan parámetros de capacidad en los Clientes Internos y Proveedores de servicios de IT
Si No
Se evalúa el impacto de las políticas de seguridad frente a la disponibilidad de los servicios IT
Si No
306
Se confrontan resultados del estudio de Gestión del Cambio frente a la gestión de disponibilidad
Si No
Se identifican las actividades clave del negocio para evaluar su requerimiento de disponibilidad
Si No
Se establecen protocolos que permitan en el mantenimiento de la infraestructura de servicios de IT
Si No
307
Gestión de Seguridad
Existe una política de seguridad informática, que involucre clientes y proveedores además que sea correctamente alineada con las necesidades del negocio.
Si No
Existen planes o estrategias de seguridad que eviten la la corrupción de Información que se integra al core del negocio
Si No
Existen protocolos de escalamiento de la seguridad de información, diferenciación de permisos de modificación de información por distintos grupos de usuarios
Si No
Se realiza pruebas de seguridad sobre los distintos servicios IT que presta la infraestructura tecnológica de la organización
Si No
Los planes de seguridad se vinculan con todos los procesos informáticos del negocio
Si No
Se realizan evaluaciones sobre los planes de seguridad informática, que demuestren la efectividad de los mismos además del estudio de nuevos riesgo y vulnerabilidades de la infraestructura IT
Si No
Se generan informes de gestión de seguridad con evaluaciones periódicas
Si No
Se establecen procesos y subprocesos que determinen la política de seguridad de la compañía a nivel tecnológico
308
Si No
Se realizan estudios de requerimientos de software y hardware que permitan velar por el cumplimiento de la política de seguridad de la compañía
Si No
A nivel especifico, se realizan acuerdo de confidencialidad de la información con Clientes y Proveedores de la compañía
Si No
Se realizan evaluaciones de Impacto de posibles vulnerabilidades de la infraestructura IT y consecuencias sobre el negocio.
Si No
309
Gestión de Capacidad
En la organización los servicios TI están respaldados por una capacidad de proceso y almacenamiento suficiente y correctamente dimensionada.
Si No
Se realizan estudios que aseguren que se cubren las necesidades de capacidad TI tanto presentes como futuras.
Si No
Se establecen controles para verificar el rendimiento de la Infraestructura IT
Si No
Se Desarrollan planes de capacidad asociados a los niveles de servicio acordados.
Si No
Se realizan estrategias y políticas que aseguren la faculta de Gestionar y racionalizar la demanda de servicios TI.
Si No
Se realizan modelos y simulaciones de capacidad para diferentes escenarios futuros previsibles.
Si No
Se dimensionan adecuadamente los servicios y aplicaciones alineándolos a los procesos de negocio y necesidades reales del cliente.
Si No
En la organización se desarrolla un Plan de Capacidad.
Si No
En ambientes controlados y fuera de producción se realizan Modelado y
310
simulación de diferentes escenarios de capacidad.
Si No
Existe una Base de Datos de Capacidad (CDB)
Si No
311
Centro de Servicios
En la organización se evalúan y controlan los costos asociados a los servicios TI de forma que se ofrezca un servicio de calidad a los clientes Internos y Externos con un uso eficiente de los recursos TI necesarios.
Si No
En la organización existe una política de administración eficaz y rentable de los servicios de la organización TI
Si No
Se realizan evaluaciones periódicas sobre la rentabilidad de los costos reales asociados a la prestación de servicios IT.
Si No
Existen estrategias que Proporcionen a la organización TI toda la información financiera precisa para la toma de decisiones y fijación de precios.
Si No
Se evalúa el retorno de la Inversión en Tecnología.
Si No
Se lleva una contabilidad sobre los costos y administración de servicios de IT
Si No
Se efectúan estudios de costos Directos e Indirectos sobre la plataforma tecnológica
Si No
Se efectúan estudios de costos fijos y variables sobre la plataforma tecnológica
Si No
Se evalúa los costos de operación de servicios IT y su posible optimización
312
Si No
Se realiza una política de Precios de servicios tecnológicos
Si No
La organización tiene en el presupuesto general tiene un unidad presupuestal enfocada al área de la infraestructura IT
313
ANEXO C: Carta de presentación a la empresa
Bogotá, 9 de Septiembre de 2010 Señores
PUNTO DE SERVICIO S.A.
Señora Lorena Parada
Gerente Administrativa
La Ciudad
Asunto: Propuesta para la implementación de ITIL – gestión de servicios, en medianas y pequeñas empresas. Estimada Ingeniera: La UNIPANAMERICANA INSTITUCIÓN UNIVERSITARIA – COMPENSAR se
permite presentar a los estudiantes Geraldine Grass Ardila, Camilo Eduardo
Moreno Suárez, Mauricio Trujillo Y Jackson Arturo Vasquez Castro quienes hacen
parte del programa INGENIERIA DE SISITEMAS. Estos estudiantes se
encuentran desarrollando la TESIS - METODOLOGÍA PARA EL ANÁLISIS E
IMPLEMENTACIÓN DE ITIL – GESTIÓN DE SERVICIOS EN MEDIANAS Y
PEQUEÑAS EMPRESAS y como parte de su trabajo de grado necesitan realizar
una investigación y análisis en su empresa
Por lo anterior, se hace necesario solicitar la colaboración de la empresa para
permitir el ingreso de los estudiantes y de igual forma facilitar el levantamiento de
la información la cual será confidencial y se usara solo con fines de investigación.
Cordialmente, JAIME AUGUSTO PINZON MENDIENTA
Coordinador de Investigación - Facultad de Ingeniería
314
ANEXO D: Propuesta a PUNTO DE SERVCIO
Bogotá, 20 de Julio de 2010 Señores PUNTO DE SERVICIOS Ingeniera Lorena Parada
Coordinadora Administrativa La Ciudad Asunto: Propuesta para realizar consultoría de los procesos de ITIL – gestión de servicios al interior de PUNTO DE SERVICIO. Estimada Ingeniera: ITIL (Information Technology Infrastructure Library) que traducido al español (Biblioteca de Infraestructura de Tecnologías de Información) es el método más ampliamente adoptada para la Gestión de Servicios de tecnologías de la información (TI) en el mundo. Proporciona un método práctico, no-absurdo para la identificación, planificación, entrega y apoyo a los servicios de TI con el negocio. Como bien ha quedado planteado ITIL, se considera como un marco de trabajo de las buenas prácticas destinadas a facilitar la entrega de servicios de (TI). ITIL resume un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para servir como guía que abarque toda infraestructura, desarrollo y operaciones de TI. ITIL tiene como objeto brindar beneficios que abogan por que los servicios de TI se alineen a las necesidades y procesos del negocio. Proporciona orientación a las organizaciones sobre cómo utilizar las TI como una herramienta para facilitar el cambio de negocios, la transformación y el crecimiento. Las mejores prácticas de ITIL están detalladas dentro de un enfoque sistemático y profesional para la gestión de servicios de TI, permitiendo a las organizaciones prestar servicios adecuados y continuamente asegurar que se cumplan los objetivos de negocio y la entrega de beneficios. El ciclo de vida del Servicio de ITIL, comienza con la identificación de las necesidades de los clientes y de los requisitos de TI, pasando por el diseño y la
315
implementación del servicio en funcionamiento y, por último, a la fase de seguimiento y mejora del servicio. La adopción de ITIL puede ofrecer a los usuarios una amplia gama de beneficios que incluyen:
Mejora de los servicios de TI.
Reducción de los costos.
Satisfacción del cliente a través de un enfoque más profesional para la prestación de servicios.
Mejora de la productividad.
Mejor uso de los conocimientos y experiencia.
Mejorar la prestación de servicios de terceros.
En resumen, los beneficios de la Administración es lograr definir que ITIL puede ser enfocado en el estudio de mercado y posibilidades mediante la búsqueda de servicios innovadores que satisfagan al cliente tomando en cuenta la real factibilidad de su puesta en marcha. De la misma manera se analizan las posibles mejoras para servicios ya existentes. Se verifican los contratos en base a las nuevas ofertas de proveedores antiguos y posibles nuevos proveedores, lo que incluye la renovación o revocación de los contratos vigentes; asegurar que la gerencia tenga los conocimientos fundamentales para asegurar que en su organización hablen el mismo idioma en materia de Proyectos, mejorando las comunicaciones de la organización o con otras empresas asociadas.
Presentamos a ustedes la presente propuesta como proyecto de TESIS – PROYECTO DE GRADO, preparada especialmente a PUNTO DE SERVICIO, con
el objetivo de capacitar y entrenar a sus profesionales para implementación de ITIL – gestión de servicios. Por lo anterior, se hace necesario solicitar la colaboración de la empresa para facilitar el ingreso de los estudiantes, así mismo con el levantamiento de la información y todo aquello que dependa del mismo. Cordialmente, JORGE MAURICIO TRUJILLO RUBIO Estudiante
316
GLOSARIO
Glosario ITIL
En este Glosario ITIL se encuentran las definiciones de los principales términos, procesos y roles de ITIL en orden alfabético.
Acuerdo de Nivel de Servicio (SLA)
Es un acuerdo entre un proveedor de servicios de TI y un cliente.
El Acuerdo de Nivel de Servicio (Service Level Agreement, SLA) describe un servicio de TI, documenta los objetivos de nivel de servicio y especifica las responsabilidades del proveedor de servicios de TI y del cliente.
En un mismo SLA pueden incluirse varios servicios y clientes.
Acuerdo de Nivel Operacional (OLA)
Se trata de un acuerdo entre un proveedor de servicios de TI y otra parte de la misma organización.
Un Acuerdo de Nivel Operacional (Operational Level Agreement, OLA) brinda apoyo en la prestación de servicios al cliente por parte de proveedor de servicios de TI.
El OLA define los bienes y servicios que se proveen y las responsabilidades de ambas partes.
Por ejemplo, podría haber un Acuerdo de Nivel Operacional entre el proveedor de servicios de TI y un departamento de compras para la obtención de equipos en determinado momento, o entre el Service Desk y algún grupo de apoyo para proveer soluciones a Incidentes en ocasiones acordadas previamente.
Advertencias de Seguridad
Es una lista de vulnerabilidades de seguridad conocidas y compiladas gracias a la aportación de proveedores de productos externos.
La lista contiene instrucciones para medidas preventivas y para el manejo de infracciones de seguridad una vez ocurran.
Alerta de Seguridad
Se trata de una advertencia producida por la Gestión de la Seguridad de TI que generalmente se hace pública cuando se prevé el surgimiento de infracciones de seguridad o cuando ya están ocurriendo.
Se busca asegurar que los usuarios y el personal de TI sean capaces de identificar cualquier ataque y de tomar medidas de precaución.
Análisis del Impacto y Riesgo al Negocio
El Análisis de Impacto Empresarial (Business Impact Analysis, BIA) identifica las Funciones Empresariales Vitales (Vital Business Functions, VBF) y sus dependencias.
317
Estas dependencias pueden incluir suministradores, individuos, otros procesos de negocio, servicios, etc.
El Análisis del Riesgo identifica las amenazas y vulnerabilidades de los activos de la empresa e indica el nivel de vulnerabilidad de cada activo ante determinadas amenazas.
Análisis Financiero
El Análisis Financiero es un componente importante del proceso de Gestión del Portafolio de Servicios.
Contiene información sobre el costo de proveer servicios y arroja luz sobre la rentabilidad de los servicios y los clientes.
Arquitectura de Procesos
Es una perspectiva general de todos los procesos e interfaces de procesos que se usa como herramienta para asegurar que todos los procesos organizativos cooperan a la perfección.
Arquitectura de TI
Provee un programa estratégico general para el desarrollo e implementación de infraestructura y aplicaciones de TI.
La Arquitectura de TI también incluye los estándares y las guías que orientan el uso de tecnologías y el diseño y evolución de aplicaciones y componentes de infraestructura de TI.
Los sub-componentes de la Arquitectura de TI son las arquitecturas de aplicación, de infraestructura y de información.
Asignación Presupuestaria
Es un presupuesto asignado por el Gestor Financiero para implementar algún cambio.
Las asignaciones se emiten en respuesta a Requisiciones Presupuestarias originadas en cualquier proceso de Gestión de Servicio junto con Solicitudes de Cambio.
Biblioteca Definitiva de Medios (DML)
Una o varias localidades en las que se almacenan seguramente las versiones operativas definitivas de todos los Elementos de Configuración de los programados.
La Biblioteca Definitiva de Medios (Definitive Media Library, DML) también puede contener Elementos de Configuración asociados tales como licencias y otros documentos.
La DML es un área de almacenamiento lógico aun cuando se divida en varias localidades.
Todos los programados en la biblioteca son controlados por Gestión del Cambio y Gestión de Ediciones y se registran en el CMS.
Sólo los programados de la DML pueden usarse con fines de difusión e implementación.
318
Calendario de Cambios
Es una lista de todos los Cambios aprobados y las fechas tentativas de su implementación.
Cambios Sugeridos a los SLA's, OLA's y UC's
Contiene sugerencias para mejorar la calidad del servicio o sobre cuestiones de economía, transmitida desde otros procesos de Gestión de Servicio hasta afectar el proceso de Perfeccionamiento Continuo del Servicio (CSI).
Las sugerencias para mejorar los servicios pueden originarse desde cualquier parte al interior o exterior de la organización de TI.
Catálogo de Servicios
Es una base de datos o documento estructurado que contiene información sobre todos los servicios vigentes e incluye aquellos que se pueden implementar.
El Catálogo de Servicios es la única parte del Portafolio de Servicios que es publicada para los clientes y se usa como herramienta de apoyo a la venta y prestación de servicios de TI.
El Catálogo de Servicios incluye información sobre servicios disponibles, precios, puntos de contacto, y procesos de pedidos y requisiciones.
Catálogo y Estructura de SLA/ OLA/ UC
Es un índice estructurado de Acuerdos de Nivel de Servicio (SLA), Acuerdos de Nivel Operacional (OLA) y de Contratos de Apoyo (UC).
Dependiendo del acercamiento usado en la estructuración de los acuerdos, podría haber varias capas o niveles de acuerdo, desde los genéricos que se ocupan de asuntos de Gestión del Nivel de Servicio hasta los más específicos que se ocupan de los servicios, sus componentes y clientes.
Categorías de Datos Financieros
Se usan varias categorías para estructurar la información financiera, como medio para llegar a comprender los costos subyacentes a la rentabilidad y el aprovisionamiento de los servicios.
Categorías de Eventos y Reglas de Correlación
Son criterios y reglas usados para decidir la respuesta adecuada ante determinados Eventos.
Las reglas de categorización y correlación se usan como parte de los sistemas de monitorización de Eventos.
CMS/ CMDB
El Sistema de Gestión de la Configuración (Configuration Management System, CMS/ Configuration Management Database, CMDB) es un modelo lógico coherente de
319
la infraestructura de la organización de TI, típicamente compuesto de varias Bases de Datos de la Gestión de Configuración que operan como sub-sistemas físicos.
Se usa para almacenar información acerca de los Elementos de Configuración controlados por Gestión de la Configuración.
Contrato de Apoyo (UC)
Es un contrato entre el proveedor de servicios de TI y un tercero.
El tercero brinda apoyo en los servicios ofrecidos a clientes.
El Contrato de Apoyo (Underpinning Contract, UC) define objetivos y responsabilidades necesarias para cumplir con los niveles de servicio acordados en un Acuerdo de Nivel de Servicio.
Declaración de Proyecto
Se trata de una declaración en que se especifican el alcance, los objetivos y los participantes de un proyecto.
Contiene un plano preliminar de los objetivos del proyecto, identifica las partes interesadas, establece la autoridad del gestor de proyecto y los recursos que están a su disposición, y contiene una lista de las limitaciones y suposiciones que afectan el proyecto.
Diseño de Proceso
Es la descripción de un proceso; incluye sus necesidades, resultados, actividades y responsabilidades.
Los Diseños de Procesos son controlados por Gestión de Procesos.
Documentación Control de Calidad (Desarrollo/ Instalación)
Se trata de la documentación de las pruebas de las medidas de control de calidad aplicadas en el desarrollo o instalación de aplicaciones, sistemas y otros componentes de infraestructura (por ejemplo, pruebas de componentes, ensayos codificados, ...).
La documentación completa de Control de Calidad (Desarrollo/ Instalación) actúa como prueba de que las medidas de control de calidad necesarias se aplicaron antes de presentarle un componente a Gestión de Ediciones.
Documentación del Usuario
Contiene instrucciones de cómo usar una aplicación o un sistema.
Documentación Operativa
Describe los procedimientos necesarios para hacer funcionar y mantener una aplicación o un componente de infraestructura.
Error Conocido
Es un Problema cuya raíz y solución temporal han sido documentadas.
320
Los Errores Conocidos se crean y se gestionan a lo largo de su ciclo de vida por personal de Gestión de Problemas.
Pueden ser identificados por desarrolladores o suministradores.
Escalado por Parte del Usuario
Se trata de un escalado relacionada con el procesamiento de un Incidente; se origina luego de que un usuario experimenta retrasos o fallos durante la restauración de un servicio.
Estrategia de Continuidad de Servicios de TI
Contiene una guía de acercamiento para asegurar la continuidad de los servicios de TI en casos de desastre.
Incluye una lista de Funciones Empresariales Vitales y opciones de aplicaciones para la reducción de riesgo (recuperación).
La Estrategia de Continuidad de Servicios de TI debe basarse en una Estrategia de Continuidad del Negocio.
Estrategia de Continuidad del Negocio
Es una guía general de acercamiento para asegurar la continuidad de funciones vitales para la empresa en caso de eventos de desastre.
La Estrategia de Continuidad del Negocio es preparada por la empresa y sirve de punto de partida para la producción de la Estrategia de Continuidad de Servicios de TI.
Estrategia de Negocios
Un plan de acción sistemático y a largo plazo diseñado para lograr metas de negocio particulares.
Estrategia de Seguridad de TI
Contiene una guía de acercamiento para procurar la seguridad de los sistemas y servicios de TI.
Incluye una lista de riesgos de seguridad y de Controles de Seguridad existentes o planificados para el manejo de riesgos.
Estrategia del Servicio
La Estrategia del Servicio es un plan sistemático y a largo plazo, diseñado por la Organización de Servicios de TI para alcanzar objetivos estratégicos determinados.
Evaluación de Encuesta al Cliente
La evaluación de una Encuesta de Servicio al Cliente presenta los resultados y los hallazgos sintetizadamente.
321
Evaluación Estratégica de Servicios
La Evaluación Estratégica de Servicios se usa para tener una idea más clara de los puntos débiles y fuertes de un proveedor de servicios antes de desarrollar una Estrategia del Servicio.
Índice de Datos Relevantes en Casos de Desastre
Es un catálogo con toda la información relevante en casos de desastre.
Este documento es actualizado y puesto a circular por la Gestión de la Continuidad de los Servicios de TI entre todo el personal de TI a cargo de contrarrestar desastres.
Información Pro-Activa al Usuario
Es una notificación de que se avecinan fallos en el servicio cuando los usuarios no estén al tanto de las mismas, para darles la oportunidad de que se preparen para un período de indisponibilidad del servicio.
Información sobre Estado de Incidente
Es un mensaje que contiene el estatus actual de un Incidente, generalmente enviado a un usuario que lo reportó inicialmente.
Información sobre Estado de Solicitud de Servicio
Es un mensaje que contiene el estatus actual de una Solicitud de Servicio, usualmente enviado a un usuario que lo haya solicitado.
Informe de Continuidad de Servicios de TI
Se crea cada cierto tiempo y provee información relacionada con la prevención de desastres a otros procesos de Gestión de Servicios y la dirección de TI.
Informe de Disponibilidad
Provee, a otros procesos de Gestión de Servicios y la dirección de TI, información relacionada con servicios y disponibilidad de componentes de infraestructura.
Informe de Evaluación de Procesos
Contiene los resultados de Evaluaciones de Madurez, Comparativas, Auditorías o Revisiones de Procesos, e incluyen desventajas identificadas en áreas que deben ser atendidas mediante iniciativas de mejoramiento.
Informe de Evaluación de Servicios
Es un documento que contiene los resultados y los hallazgos de una Revisión de Servicio.
322
Este protocolo constituye un aporte importante en el establecimiento de iniciativas de mejora.
Informe de Gestión de Incidentes
Provee información relacionada con Incidentes a los procesos de Gestión de Servicio.
Informe de Gestión de Problemas
Es un informe que provee información relacionada con la solución de Problemas a otros procesos de Gestión de Servicios.
Informe de la Capacidad
Provee información relacionada con factores de uso y desempeño a otros procesos de Gestión de Servicios y la dirección de TI.
Informe de Nivel de Servicio
Este informe ayuda a entender la habilidad que tiene un proveedor de servicios para lograr la calidad de servicio acordada.
A estos efectos, compara los niveles de servicio logrados con los propuestos, y también incluye información sobre el uso de servicios, las medidas de mejoramiento continuo a los servicios y eventos excepcionales.
Los Informes de Nivel de Servicio son emitidos por el proveedor de servicios para sus clientes, la dirección de TI y otros procesos de Gestión de Servicios.
Los suministradores de servicios externos también preparan un informe similar para documentar el desempeño de sus servicios.
Informe de Seguridad de TI
El Informe de Seguridad de TI provee información sobre asuntos de Seguridad de TI a los procesos de Gestión de Servicios y la dirección de TI.
Informe de Transición del Servicio
Es un resumen general de todos los proyectos, planificados o vigentes para la implementación de Ediciones operativas importantes.
Contiene una lista de datos relevantes sobre cada proyecto como los logros y el estatus actual de un proyecto dado.
Informe de Validación del Diseño del Servicio
En él se resumen los resultados de las actividades de prueba de la Validación del Diseño del Servicio y se deja establecido que el Paquete de Diseño del Servicio (SDP) corresponde a los Requisitos del Servicio.
323
Jerarquía de Autorización de Cambios
Define a quién le corresponde evaluar los cambios propuestos, según el nivel de riesgo de los mismos.
Manual de Pruebas
Es un conjunto de instrucciones detalladas para poner a prueba ciertos aspectos de una aplicación o de un componente de infraestructura.
En esencia, define las actividades que se llevarán a cabo y los resultados esperados.
Meta del Valor del KPI
Se trata del valor futuro de una Métrica (Key Performance Indicator, KPI).
Es responsabilidad de los Gestores de Proceso gestionar y optimizar los procesos para que se cumplan los objetivos en términos de los indicadores de rendimiento.
Modelo de Cambio
Los Modelos de Cambio describen procedimientos para el manejo de cambios recurrentes.
Por lo general, son provistos por el Gestor de Cambios en cada uno de los renglones de Cambio de Estándar (poco riesgo, cambios pre-autorizados).
Modelo de Incidentes
Contiene pasos predefinidos que deben tomarse para manejar cierto tipo de Incidentes.
Es un modo de asegurar que los Incidentes que ocurren de manera rutinaria se manejen eficiente y efectivamente.
Modelo de Prueba
Se crea en la fase de planificación de la versión operativa para especificar detalladamente el acercamiento de prueba que se usó en la implementación de la versión en un entorno de producción.
Constituye un aporte importante al Plan de Proyecto. Sobre todo, este documento define los puntos de cotejo requeridos en el proceso de control de calidad durante la implementación de la versión operativa.
Notificación de Fallos al Servicio
Es el informe de un fallo en el servicio al personal del Service Desk, que puede llegar por vía telefónica o por correo electrónico de parte de un usuario, o a través de alguna herramienta de monitorización de sistemas.
324
Perfil de Acceso de Rol de Usuario
Es un conjunto de datos que definen el nivel de acceso a un servicio o conjunto de servicios brindaos a ciertos tipos de usuarios (Roles de Usuario).
Los Perfiles de Acceso de Rol de Usuario sirven para proteger la confidencialidad, la integridad y la disponibilidad de los activos al definir qué información puede ser usada por los clientes, qué programas pueden usar y qué modificaciones pueden hacer.
Plan de Capacidad
Se usa para gestionar los recursos requeridos para prestar los servicios de TI requeridos.
Contiene escenarios de posibilidades según distintas predicciones de demanda de servicios, así como opciones y sus costos para cumplir con los niveles de servicio acordados.
Plan de Disponibilidad
Contiene información detallada sobre iniciativas orientadas al mejoramiento del servicio y/o a hacer que los componentes estén disponibles.
Plan de Proyecto
Es un documento formal, aprobado, que muestra los entregables principales, los logros, las actividades y los recursos de un proyecto.
Se usa como guía tanto para quienes controlan los proyectos como para quienes los llevan a cabo.
Plan de Recuperación
Los planes de recuperación son creados principalmente por la Gestión de la Disponibilidad y de Continuidad de los Servicios de TI.
Contienen instrucciones detalladas para la restitución de los servicios a su fase operativa.
Plan Estratégico de Servicios
Es un plan para implementar la Estrategia del Servicio, contiene objetivos específicos, actividades y responsabilidades.
Plantilla para Solicitudes de Cambio
Es una plantilla usada cuando se solicita formalmente un Cambio.
Los pedidos de cambio incluyen detalles del Cambio propuesto, y pueden estar en formato electrónico o en papel.
Plantillas para Documentos de SLM
Son plantillas para los documentos usados en la Gestión del Nivel de Servicio, por ejemplo los Requisitos de Nivel de Servicio (SLR), los Acuerdos de Nivel de Servicio
325
(SLA), los Acuerdos de Nivel Operacional (OLA), los Contratos de Apoyo (UC), los Criterios de Aceptación de Servicios (SAC), ...
Política de Cambios al CMS
Es un conjunto de reglas que establece quién está autorizado a modificar la estructura y los contenidos del Sistema de Gestión de la Configuración (CMS).
Política de Despliegue
Es un conjunto de reglas usadas durante la implementación de Ediciones operativas en entornos de producción real y que definen los distintos acercamientos en la difusión de Ediciones según consideraciones de urgencia y de impacto.
Política de Seguridad de TI
Establece reglas vinculantes para el uso de servicios y de sistemas con miras a mejorar la seguridad de TI.
Políticas y Regulaciones Empresariales
Es un conjunto de políticas y regulaciones empresariales vinculantes que constituyen un aporte esencial para el proceso de Gestión de Cumplimiento.
Portafolio de Servicios
Representa una lista completa de los servicios gestionados por un proveedor de servicios; algunos de estos servicios son visibles a los clientes. Contiene compromisos contractuales vigentes, información sobre el desarrollo de servicios nuevos y planes de mejoramiento continuo a los servicios, iniciados por Perfeccionamiento Continuo del Servicio.
También incluye servicios externos que forman parte integral de la oferta de servicios a los clientes.
El Portafolio de Servicios se divide en tres fases: Proyección de Servicios, Catálogo de Servicios y Servicios Retirados.
Preguntas Frecuentes de los Usuarios
Información de autoayuda para los usuarios, provista por el Service Desk como parte de las Páginas de Apoyo o de una red interna.
Preguntas sobre Estado de Incidentes
Cualquier pregunta sobre el estatus actual de un Incidente, generalmente provienen de un usuario que lo reportó inicialmente.
326
Presupuesto de TI
El Presupuesto de TI es un plan financiero anual que pronostica los gastos esperados y asigna recursos financieros a varios de los procesos de Gestión de Servicio y a unidades organizativas dentro de la organización de TI.
Problema Sugerido
Se trata de una notificación para indicar la sospecha de un Problema, transmitida a Gestión de Problemas para que sea investigada.
Programación de Pruebas (Dispon./ Contin./ Segur.)
Es un programa de pruebas frecuentes para todos los mecanismos de disponibilidad, continuidad y seguridad, mantenido por las Gestiones de la Disponibilidad, de la Continuidad y de la Seguridad.
Protocolo de Auditorías de Configuración
Es un informe que resume los resultados de una auditoría al Sistema de Gestión de la Configuración (CMS), destacando las diferencias reveladas entre los registros del CMS y los Elementos de Configuración instalados.
Protocolo de Pruebas
Es un protocolo que abarca la preparación, el progreso y la evaluación de una prueba, creado a modo de ejemplo durante las pruebas llevadas a cabo por las Gestiones de la Disponibilidad, de la Continuidad y de la Seguridad.
Registro de Cambio
Contiene todos los detalles de un Cambio, documenta su ciclo de vida y dónde se define a manera de adición, cambio o remoción de cualquier objeto que pueda afectar los servicios de TI.
Registro de Cumplimiento
Es una herramienta usada por Gestión de Cumplimiento para mantener una perspectiva general de todos los requisitos de cumplimiento y de las medidas que se aplican para asegurar que se respeten.
Registro de Incidente
Es un conjunto de datos con todos los detalles de un Incidente, que documenta la historia de los mismos desde su registro hasta su resolución.
Un Incidente se define como una interrupción no planificada o como la reducción de calidad de algún servicio de TI.
Cualquier evento con potencial de interrumpir un servicio de TI en el futuro también se considera un Incidente (por ejemplo, el fallo de un disco duro).
327
Registro de Problema
Contiene todos los detalles de un Problema y documenta el historial de ese Problema desde su detección hasta su resolución.
Registro de Quejas
El Registro de Quejas contiene un historial completo de las quejas de los clientes, e incluye las acciones que se tomaron a raíz de las mismas.
Registro de Riesgos
El Registro de Riesgos es una herramienta usada en el proceso de Gestión del Riesgo para tener una idea general de ciertos riesgos y sus respectivas contramedidas.
Reglas de Escalado de Incidentes
Se usan para establecer la jerarquía en caso de escalado de Incidentes. Sus indicadores se basan en la gravedad de los Incidentes y en los períodos de resolución.
Requisitos de Nivel de Servicio (SLR)
Los Requisitos de Nivel de Servicio (Service Level Requirements, SLR) son un documento que contiene las requisiciones de servicio desde el punto de vista del cliente y define los niveles de servicio propuestos, las responsabilidades mutuas y otros requisitos específicos de los clientes o grupos de clientes.
Requisitos de Rol de Usuario
Son establecidos por la empresa para el catálogo o jerarquía de Roles de Usuario (tipos de usuario) en la organización.
Los derechos de acceso se basan en los roles que los usuarios tienen como parte de su organización.
Requisitos de Servicio
El resultado deseado de un servicio, expresado en términos de la funcionalidad del servicio requerido y de los niveles de servicio.
SI
Sistema de Información
Sistema de Información de Gestión de la Capacidad (CMIS)
El Sistema de Información de Gestión de la Capacidad (Capacity Management Information System, CMIS) es un depósito virtual de todos los datos de Gestión de la Capacidad, usualmente almacenados en varias localidades físicas.
328
Sistema de Información de Gestión de la Disponibilidad (AMIS)
El Sistema de Información de Gestión de la Disponibilidad (Availability Management Information System, AMIS) es un depósito virtual de todos los datos de Gestión de la Disponibilidad, usualmente almacenados en varias localidades físicas.
Sistema de Información de Gestión de la Seguridad (SMIS)
El Sistema de Información de Gestión de la Seguridad (Information Security Management System, SMIS) es un depósito virtual de todos los datos de Gestión de la Seguridad de TI, generalmente almacenados en varias localidades físicas.
Solicitud de Apoyo
Es una solicitud de apoyo en la solución de un Incidente o problema, usualmente generado como parte de los procesos de Gestión de Incidentes o Problemas cuando se requiere de más ayuda por parte de técnicos expertos.
Solicitud de Cambio (RFC)
La Solicitud de Cambio (Request for Change, RFC) es una requisición formal de Cambio en espera de ser implementada.
Incluye detalles del Cambio propuesto, y puede estar en formato electrónico o en papel.
Las siglas (en inglés) RFC a menudo se usan equivocadamente para referirse al Registro de Cambio o al Cambio mismo.
Solicitud de Cambio a Arquitectura de Procesos
Se trata de una solicitud para cambiar o extender la Arquitectura de Procesos, a menudo emitida durante el proceso de Diseño del Servicio cuando la introducción o modificación de un servicio no es posible dadas las limitaciones de los procesos existentes.
Solicitud de Servicio
Generado por un usuario que busca información o consejo, o que desea solicitar un Cambio menor o que se le conceda acceso a algún servicio de TI.
Esta solicitud puede ser de cambio de contraseña, o de que se le provean servicios comunes de TI a otro usuario.
Las Solicitudes de Servicio se manejan desde un Service Desk o por parte de un Grupo de Cumplimiento de Solicitud de Servicio y no requieren la formalidad de una Solicitud de Cambio (RFC).
Sugerencia de Error Conocido
Se trata de una sugerencia para crear una entrada nueva en la Base de Datos de Errores Conocidos (Known Error Database, KEDB), y puede ser presentada por el Service Desk o por Gestión de Ediciones.
329
Los Errores Conocidos se gestionan a lo largo de su ciclo de vida por personal de Gestión de Problemas.
Sugerencia de Mejoras al Proceso
Las sugerencias para mejorar los procesos de Gestión de Servicio pasan a manos de los encargados del proceso de Perfeccionamiento Continuo del Servicio (CSI).
Estas sugerencias pueden ser originadas en cualquier parte de la organización de
TI. 24
24
WIKIPEDIA. Glosario ITIL, [en línea], 20/10/2010, Disponible en internet: http://wiki.es.it-processmaps.com/index.php/Glosario_ITIL
