Tog guillermo uribe

Instituto Tecnológico y de Estudios Superiores de Occidente
2014-03
Utilización de ITIL para la mejora de los
servicios de la Oficina de operación de
soluciones remota de la Gerencia ASARE de
la CFE
Uribe-Medina, Sergio G.
Uribe-Medina, S. G. (2014). Utilización de ITIL para la mejora de los servicios de la oficina de
operación de soluciones remota de la Gerencia ASARE de la CFE. Trabajo de obtención de grado,
Maestría en Informática Aplicada. Tlaquepaque, Jalisco: ITESO.
Enlace directo al documento: http://hdl.handle.net/11117/4039
Este documento obtenido del Repositorio Institucional del Instituto Tecnológico y de Estudios Superiores de
Occidente se pone a disposición general bajo los términos y condiciones de la siguiente licencia:
http://quijote.biblio.iteso.mx/licencias/CC-BY-NC-2.5-MX.pdf
(El documento empieza en la siguiente página)
Repositorio Institucional del ITESO rei.iteso.mx
Departamento de Electrónica, Sistemas e Informática DESI - Trabajos de fin de Maestría en Informática Aplicada

(1)
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE OCCIDENTE
MAESTRÍA EN INFORMÁTICA APLICADA
Reconocimiento de Validez Oficial de Estudios de Nivel Superior según acuerdo secretarial
15018, publicado en el
Diario Oficial de la Federación el 29 de Noviembre de 1976.
Utilización de ITIL para la mejora de los servicios de la Oficina de
operación de soluciones remota de la Gerencia ASARE de la CFE.
Reporte Final
Tesis que para obtener el título de
Maestro en Informática Aplicada
Presenta:
Sergio Guillermo Uribe Medina
Asesor:
Mtro. Ricardo Salas Mejía
Guadalajara, Jalisco Mayo 2014

(2)
ÍNDICE
ÍNDICE 2
INTRODUCCIÓN 4
Tema de la tesis 4
Antecedentes y razones para la implementación del proyecto 5
Antecedentes 5
Gerencia ASARE (Administración de Soluciones, Aplicaciones y Resultados) 8
Razones 10
Justificación 11
Objetivos a alcanzar 13
Objetivo general 13
Objetivos particulares 13
Marco teórico usado para la resolución de la problemática 14
Áreas del conocimiento aplicables al proyecto 14
ITIL - Information Technology Index Library 15
PMF - Modelo de Madurez 25
BPM – Business Process Management 29
KM – Knowledge Management - Gestión del conocimiento 44
Descripción de la solución propuesta 49
Estrategia metodológica (Metodología) 50
CAPÍTULO I - ANÁLISIS 56
1.1 Evaluación preliminar de la organización 56
Aplicación del proceso de Evaluación 57
Entrevistas 57
Matriz de responsabilidades 60
SIPOCs 63
Diagrama de vista horizontal 64
Mapa de distribución de documentos 67
1.2 Hallazgos y Recomendaciones 69

(3)
Hallazgos 69
Recomendaciones 74
1.3 Evaluación de madurez respecto de ITIL 77
CAPÍTULO II – DISEÑO Y REDISEÑO DE PROCESOS 85
2.1 ITIL (Information Technology Infrastructure Library) 85
2.2 Mapa de Arquitectura de procesos 89
2.3 Diseño de los procesos 97
Introducción a la Gestión de la configuración (Gestión de componentes,
inventarios y activos). 97
Proceso de gestión de la configuración 103
Introducción a la Gestión de Eventos (El monitoreo de la infraestructura). 120
Proceso de Gestión de Eventos (Monitoreo) 124
Introducción a la Gestión de Incidencias 137
Proceso de gestión de incidentes 140
CAPITULO III - OBSERVACIONES DEL PROCESO DE IMPLANTACIÓN Y RESULTADOS
162
3.1 Observaciones del proceso de implantación 162
3.2 Resultados obtenidos 167
3.3 Evaluación posterior de la organización 171
CONCLUSIONES 177
REFERENCIAS BIBLIOGRÁFICAS 181
ANEXOS 183
ÍNDICE DE ILUSTRACIONES 192
GLOSARIO DE TÉRMINOS 195

(4)
INTRODUCCIÓN
Tema de la tesis
En la actualidad la utilización de tecnologías de información para una empresa ya
no es solo un apoyo para realizar sus operaciones y llevar a cabo sus procesos, si
no se han vuelto indispensables para su operación y en algunos casos son el pilar de
muchos de sus procesos.
A medida que estas son implementadas dentro de las organizaciones estas se
vuelven más parte del todo, y comienzan a ser un factor determinante para que la
empresa alcance mayores objetivos, se vuelva competitiva o bien productiva.
También a medida que estos se involucran con el trabajo cotidiano, su
correcta administración y operación se vuelve igualmente un factor importante, ya
que el correcto funcionamiento, disponibilidad y explotación de estas tecnologías
dará como resultado un mejor desempeño de los procesos sustanciales de cada
empresa.
Hablando de tecnologías de información y su correcta administración existen
en la actualidad muchos mecanismos y marcos de referencia que dan un amplio
panorama de las formas más apropiadas para su gestión, y constan de un cumulo
de conocimientos y experiencias, adquiridas y recopiladas a lo largo del desarrollo
que estas mismas tecnologías han tenido, esta recopilación se le conoce como
mejores prácticas de la industria.
Entre ellas destacan un conjunto de libros denominados ITIL (Information
Technology Infrastructure Library) que representan un compendio de las mejores
prácticas para gestionar tecnologías de información de manera general.
Este trabajo está enfocado a mostrar una estrategia o método de la
utilización de ITIL como marco de referencia para el diseño de los procesos de una
dependencia de TI denominada "Oficina de operación de soluciones remota de la
Gerencia ASARE” perteneciente a la CFE (Comisión Federal de Electricidad).

(5)
Partiendo de un análisis inicial de la organización y sugiriendo los pasos
apropiados para que de forma gradual se puedan adoptar los esquemas de las
mejores prácticas (ITIL).
Dado que el trabajo refiere diseño de procesos se tocarán algunos aspectos
de metodologías para este propósito en específico de BPM (Business Process
Management). Algunos de sus conceptos pueden ser utilizados como habilitadores
para la adopción de los procesos que ITIL propone.
Antecedentes y razones para la implementación del proyecto
Antecedentes
La Comisión Federal de Electricidad es una empresa del gobierno mexicano que
genera, transmite, distribuye y comercializa energía eléctrica para más de 33.9
millones de clientes, lo que representa a más de 100 millones de habitantes.
La CFE es también la entidad del gobierno federal encargada de la planeación
del sistema eléctrico nacional, la cual es plasmada en el Programa de Obras e
Inversiones del Sector Eléctrico (POISE), que describe la evolución del mercado
eléctrico, así como la expansión de la capacidad de generación y transmisión para
satisfacer la demanda en los próximos diez años, y se actualiza anualmente.
El compromiso de la empresa es ofrecer servicios de excelencia, garantizando
altos índices de calidad en todos sus procesos, al nivel de las mejores empresas
eléctricas del mundo.
CFE es un organismo público descentralizado, con personalidad jurídica y patrimonio
propio.

(6)
Para su mejor funcionamiento la CFE está estructurada en varias
dependencias atendiendo a las diferentes actividades necesarias para alcanzar los
objetivos antes expuestos. Esta estructura está divida en las siguientes direcciones:
 Dirección General
 Dirección de Operación
 Dirección de Finanzas
 Dirección de Administración
 Dirección de Proyectos de Inversión financiada
 Dirección de Modernización
 Órgano Interno de Control
Para controlar y administrar de forma eficiente todos estos procesos se
requiere de muchos mecanismos y valerse de diversas herramientas, tanto
conceptuales como tecnológicas. La CFE como muchas empresas se vale de
herramientas de TI (Tecnologías de Información) para llevar a cabo sus tareas
cotidianas tanto operativas como administrativas.
A lo largo de su historia han existido infinidad de sistemas de información que
soportaron las diversas tareas que esta empresa realiza.
En 1998 la CFE a través de su Dirección de administración y su Dirección de
finanzas como patrocinadores llevaron a cabo una iniciativa para consolidar todos
estos sistemas usando la tecnología de un sistema ERP, teniendo como objetivo
general la instalación y puesta en productivo del sistema R/3 de SAP, en el ámbito
institucional de la CFE, aprovechando las mejores prácticas de negocios y alineando
los procesos de trabajo en forma horizontal a través de actividades
departamentales.
Para ello se creó un grupo de personas que conformaron un proyecto
denominado “ASARE”, Su misión era establecer una plataforma de información en
tiempo real, que mediante el uso de procesos automatizados y la modernización en

(7)
los procedimientos, mejorar las actividades de captura, integración, consulta y
explotación de la información técnica y financiera; mejorar el servicio a clientes
internos y externos, al capturarse las operaciones y sus consultas en forma
desconcentrada generando la información integrada en línea, de tal forma que
permitiera una ágil toma de decisiones a todos los niveles de la organización.
Como objetivos específicos:
 Modernizar los procedimientos de captura, procesos y explotación de
información técnica y financiera
 Mejorar el servicio a clientes internos y externos, soportada en tecnología
de punta
 Disponer de información integrada y en línea, que se capture y consulte en
forma desconcentrada y permita la toma de decisiones en todos los
niveles
La implantación del sistema se fundamentó en el cumplimiento de uno de los
objetivos institucionales, consistente en “Operar sobre bases de indicadores
internacionales en materia de productividad, competitividad y tecnología”. La
estrategia de implantación del Proyecto ASARE se ubicó en fases de capacitación,
análisis de procedimientos, para-metrización, prueba piloto e implantaciones de los
siguientes módulos del sistema SAP:
 Módulos Financieros: Contabilidad FI (Activos fijos, cuentas por pagar y
cuentas por cobrar), Costos (CO), Tesorería TR-FM/CM (Bancos y
presupuestos), Almacenes, compras y tráfico (MM), Flujos de trabajo (WF)
y Formulación del presupuesto (FP)
 Módulos de Mantenimiento de plantas (PM), Control de proyectos (PS),
Tesorería avanzada (TR-TM)
La Implantación se culminó en todo el ámbito nacional de CFE en el mes de
agosto del 2002.

(8)
Una vez implantado y en operación, fue necesario llevar a cabo la
administración de este recurso y buscar explotar todo su potencial, por ello el
proyecto se convierte en una dependencia de la Dirección de finanzas constituyendo
la Gerencia de ASARE (Administración de Soluciones, Aplicaciones y Resultados).
Gerencia ASARE (Administración de Soluciones, Aplicaciones y
Resultados)
El objetivo principal de esta Gerencia es proporcionar servicios de información para
la oportuna toma de decisiones en los diferentes niveles de la organización,
personal especializado y altamente calificado, con entendimiento del negocio, la
tecnología y el servicio.
Su misión es proporcionar servicios integrales de información para soportar la
toma de decisiones; así como integrar, mantener y compartir información
administrativa, financiera y técnica de todas las áreas de CFE con calidad y servicio;
que supere las expectativas del cliente, respete el entorno organizacional, el
desarrollo de sus colaboradores y garantice la aplicación de las mejores prácticas de
negocio de la institución.
El mercado objetivo son todas las áreas de CFE, tanto técnicas como
administrativas clasificadas en áreas:
 Normativas (administrativos, técnicos y operativos)
 Operativas (registro de operaciones)
 Directivas (apoyo en la toma de decisiones)
 Órgano Interno de Control / Auditores Externos (consulta de la
información de los sistemas)
Para poder satisfacer las necesidades y los requerimientos de los diferentes
clientes, los servicios que la Gerencia ASARE ofrece son:

(9)
 Procesamiento de Información mediante el uso de Tecnología de
Información (ERP, BI, Colaboración)
 Promoción de mejores prácticas de negocio en la CFE
 Automatización de las actividades financieras, administrativas y operativas
de la CFE
 Soporte técnico, asesoría, capacitación y entrenamiento a nuestros
clientes
 Promoción de la estandarización de normas, políticas y procedimientos
El servicio de procesamiento de información es entregado mediante un
complejo arreglo de equipos de cómputo y de Tecnologías de Información
distribuidas en 2 centros de cómputo en el país.
El primer centro de cómputo de alto rendimiento se creó en la CD. De México
y albergo los equipos necesarios para dar soporte a la aplicación y el motor de base
de datos que el sistema R/3 utiliza.
Debido al crecimiento y la importancia de la información que en este sistema
se registra, fue necesario implementar mecanismos de protección de información
como: Alta disponibilidad, sistemas de respaldo en línea y fuera de línea, replicación
de datos, etc. Finalizando con la idea de tener un centro de cómputo alterno como
medida de recuperación en caso de un desastre (DRP – Disaster Recovery Plan).
Los trabajos para la implementación del segundo centro se iniciaron en 2001,
y es en 2003 que queda terminado el centro de cómputo alterno en la CD. De
Guadalajara. La intención fue que este centro se equipara con lo necesario para
poder soportar la misma demanda de servicio que soportaba el centro de cómputo
que se encuentra en la CD. De México.
Ambos centros de cómputo fueron interconectados por medio propios y se
implementó un sistema de replicación de la información entre ellos de manera
constante.

(10)
Para ello fue necesario la adquisición de equipo de alta tecnología que
permitiera que las comunicaciones, el almacenamiento y el poder de computo
fueran lo más eficiente posible.
Para finales de 2004 ambos centros de cómputo se encontraban en
condiciones de soportar de manera indistinta la atención de 16,000 usuarios de toda
la república, con 5000 de esos usuarios trabajando de manera concurrente.
Estas entidades se definen como el Centro de Operaciones México (COM) y
Centro de Operaciones Guadalajara (COG). Siendo este último, por su modernidad
y características de las instalaciones el designado como centro principal (en el
esquema de DRP) y el COM como el centro de datos alterno.
Ambos centros son administrados y operados por personal de la citada
Gerencia, a través de 2 dependencias denominadas “Oficina de operación de
soluciones” para la CD. De México y “Oficina de operación de soluciones remota”
para el centro ubicado en Guadalajara, siendo esta última el ámbito donde se
aplicará el presente trabajo.
Razones
La Gerencia ASARE de la CFE, a través de sus centros de datos presta los servicios
de administración de la infraestructura de TI (cómputo, comunicaciones y
almacenamiento) donde es soportado el sistema institucional de información. Se
observa que el proceso de administración cumple con los objetivos pero opera en
condiciones de ineficiencia tales como: respuestas tardías a solicitudes y
requerimientos, indisponibilidad de información o información desactualizada
referente a la infraestructura y a su operación, control limitado de los cambios y
configuraciones de los elementos de la misma infraestructura, esto provoca
incertidumbre en los usuarios o clientes de los servicios.

(11)
Es deseable que esta administración se lleve a cabo dentro de un marco de
confiabilidad, seguridad y calidad de servicio. Que permita un acercamiento más
puntual con los clientes o usuarios, a partir de la declaración anterior surge el
siguiente cuestionamiento:
¿Cómo se puede mejorar la gestión de los recursos o infraestructura de TI en un
entorno de eficiencia de tal forma que al mismo tiempo se pueda mantener al
cliente permanentemente informado de todo el proceso?
Este trabajo pretende ayudar a responder este cuestionamiento.
Justificación
El desarrollo de este proyecto, es relevante para la Gerencia ASARE, debido a que
los servicios que esta brinda a la CFE, son sustantivos para apoyar los procesos de
generación, transmisión y distribución de energía eléctrica en el país, y se hace
necesario que se adopten mecanismos que garanticen las mejores condiciones de
entrega de estos servicios. Con esta propuesta se pretende:
 Evidenciar de forma fundamentada las condiciones de ineficiencia e ineficacia
del actual funcionamiento de la organización,
 Mostrar una estrategia para adoptar las mejores metodologías de
administración de centros de datos y sus tecnologías de información
asociadas,
 Proponer una guía para incorporar dichas metodologías de forma gradual,
 Elaborar un plan para optimizar el soporte de estos servicios, en referencia
los centros de cómputo y la infraestructura con la que cuentan,
 Mostrar una visión general del funcionamiento del área bajo condiciones de
calidad y eficiencia,
Con ello comenzar a atender y alinear los objetivos y los procesos que se
siguen para brindar estos servicios según la visión estratégica y dirección que se

(12)
marcan en los lineamientos que tanto la CFE como algunos organismos
gubernamentales han establecido para ello, tal como la SFP – Secretaría de la
Función Pública, y que se encuentran contenidos en los siguientes documentos:
 Manual Administrativo de Aplicación General en materia de Tecnologías de la
Información y Comunicaciones de la Secretaría de la Función Pública.
 Modelo de Gobierno y Políticas de Administración de TIC de la Comisión
Federal de Electricidad
 Manual de Políticas para la administración de TIC de la propia Gerencia
ASARE de la CFE
Estos manuales y modelos son publicados en el diario oficial de la federación
y que son de atención de todas aquellas instituciones gubernamentales y de orden
público. Son adaptación de los manuales de ITIL y COBIT como modelos de
administración de tecnologías de información y gobernanza, por lo que cualquier
iniciativa que se apegue a los modelos de ITIL y COBIT para llevar a cabo los
procesos de soporte de servicios y entrega de servicios relacionados con tecnologías
de información estará apegada a dichas disposiciones y lineamientos.

(13)
Objetivos a alcanzar
Objetivo general
Objetivo: elaborar un diagnóstico y análisis de las actividades y funciones que
realiza la oficina de operación de soluciones remotas. Desarrollando una propuesta
de mejora de los procesos y funciones de dicha oficina y una metodología de
implantación donde se consideren los marcos de calidad más convenientes y se
proponga una orientación de servicio al cliente.
Objetivos particulares
• Mostrar las causas de la baja eficiencia de los servicios con el método de
administración actual
• Evidenciar las ventajas al utilizar los modelos de gestión de TI más
reconocidos
• Generar una propuesta que considere los elementos más relevantes para la
implantación de un sistema de TI y/o un sistema de gestión de TI
• Generar una propuesta que considere los elementos más relevantes para la
implantación de un sistema de gestión de calidad (ISO)

(14)
Marco teórico usado para la resolución de la problemática
Áreas del conocimiento aplicables al proyecto
Como ya se expuso uno de los objetivos de trabajo es establecer una estrategia
metodológica que permita la aplicación de las mejores prácticas en materia de
Tecnologías de información (ITIL) y así poder contar con una mejor forma de
administración de las TI con las que cuenta el centro de trabajo donde se desarrolla
este trabajo. Estas mejores prácticas no son una receta de cocina, ni algo que
pueda adoptarse de facto, es necesario interpretarlas y buscar un mecanismo para
su adopción, y utilizar otras herramientas o disciplinas que en conjunto permitan su
correcta y exitosa adopción, Como base conceptual para el desarrollo de este
trabajo se buscaron algunos mecanismos que ayudarán a que se pudiera establecer
una estrategia que permitiera alcanzar este objetivo, entre ellos se listas los
siguientes:
 ITIL – Information Technology Index Library
 ITIL – PMF (Process Maturity Framework)
 BPM – Business Process Management
 KM – Knowledge Management – Gestión del conocimiento
Hablando en general no son probablemente todas las área de conocimiento
que puedan aplicarse al tema de ITIL y administración de tecnologías de
información, pero si los necesarios para dar soporte a la estrategia concebida para
tratar de resolver el problema y cuestionamiento planteado con anterioridad para el
centro de trabajo en cuestión , después de indagar sobre el tema, estas áreas se
relacionan de tal forma que puedan dar forma a la solución que de manera posterior
y que de forma gráfica se expone a continuación:

(15)
Figura 1 - Relación de las áreas de conocimiento – diseño del autor.
Se plantea que en su conjunto permitirán desarrollar una guía de aplicación de
mejores prácticas para mejorar los servicios del área en cuestión.
Para un mayor entendimiento y tratar de explicar en qué consiste cada una y
cómo se pretende utilizar el conocimiento que se obtiene de ellas en el desarrollo de
este trabajo, se tratará de describirlas de manera breve:
ITIL - Information Technology Index Library
El primer tópico se refiere a ITIL, The Information Technology Index Library
por su siglas en inglés, muchos autores han escrito con referencia a este tema, sin
embargo como base para explicar en qué consiste, a continuación se resumen
algunas de las ideas expresadas en el artículo de Mathias Sallé, publicado en 2004,
denominado: ‘IT Service Management and IT Governance: review, comparative
analysis and their impact on Utility Computing’, que a grandes rasgos expone lo
siguiente:
ITSM (Para proceso de operación)
Operación
del
Servicio
Cumplimiento
de Solicitudes
Gestión de
Problemas
Gestión de
Incidentes
Gestión de
Eventos
Gestión de
Accesos
ITIL V2
Mejores prácticas para
el Soporte de Servicio
Gestión de la
infraestructura
de TI
Centro de
Servicio al
Usuario
Gestión del
Incidente
Gestión
del
Problema Gestión de la
Configuración
Gestión del
Cambio
Gestión de
la Entrega
Business Process Management Tools
KM –
Knowledge
Management

(16)
Conforme las tecnologías de información (TI´s) avanzan y se renuevan se ha ido
transformando en una herramienta indispensable para las empresas hasta el punto
en que para muchas sería imposible funcionar sin estas. Por ello la función de las
TI’s está tornándose diferente, transformándose de funcionar como un proveedor de
tecnología en un socio estratégico. Al mismo tiempo, la infraestructura de TI avanza
hacia un modelo centralizado, con una utilidad mayor y adaptada a las nuevas
exigencias. En el documento se revisan los diferentes marcos abiertos y los
particulares de ciertas industrias que sirven de apoyo a las organizaciones que
manejan tecnologías de información y que están en esa transición además explora
el impacto en la próxima generación de infraestructura de TI.
De acuerdo al autor Las organizaciones de TI suelen seguir un enfoque de
tres etapas. Cada etapa evolutiva se basa en las otras partiendo de una primera
etapa, la gestión de infraestructuras de TI (ITIM). Durante esta etapa, las
organizaciones de TI se centran en la mejora de la gestión de la infraestructura de
la empresa. En realizar una gestión de la infraestructura eficaz, esto significa
incrementar el retorno de los activos de computación y tomar el control de la
infraestructura, los dispositivos que contiene y los datos que genera. La siguiente
etapa, llamada gestión de servicios TI (ITSM), considera que las organizaciones de
TI identifiquen activamente los servicios que sus clientes necesitan y se centren en
la planificación y la prestación de estos servicios para satisfacer disponibilidad,
rendimiento y requisitos de seguridad entre otros. Además, la TI se convierte en la
gestión de acuerdos de nivel de servicio, tanto interna como externamente, cuya
misión es hacer cumplir los objetivos acordados de calidad y costo. En última
instancia o etapa, las organizaciones evolucionan a la administración de TI con valor
del negocio (IT Governance), estas se transforman en verdaderos socios de
negocios que permiten nuevas oportunidades de acción.
Esta mencionada evolución de las organizaciones de TI, de ser los
proveedores de tecnología a ser los proveedores de servicios requiere tomar una
perspectiva diferente sobre la gestión de TI. La Gestión de Servicios TI pone los
servicios entregados por TI en el centro de la TI y los define comúnmente como "un

(17)
conjunto de procesos que cooperan para asegurar la calidad de los servicios de TI,
de acuerdo con los niveles de servicio acordados por el cliente. Que se superpone a
los dominios de gestión, tales como la gestión de sistemas, gestión de redes,
desarrollo de sistemas, y en muchos de los dominios de procesos como la gestión
del cambio, gestión de activos y administración de problemas". En pocas palabras la
gestión de TI se debe centrar en los servicios que entrega y no en la tecnología que
usa para soportarlos.
Con los años, diversos marcos de ITSM se han propuesto. Siendo los más
representativos: ITIL, MOF, HP ITSM, SMSL y EL BS 15000.
 ITIL que actúa como el estándar de facto para la definición de las mejores
prácticas y procesos que se refiere a las cinco disciplinas de servicios de
apoyo, y las cinco disciplinas de la prestación de servicios.
 MOF que extiende el marco de ITIL con directrices específicas para las
tecnologías de Microsoft. En cierto modo, MOF es mucho más operativo
que ITIL.
 El modelo de referencia de HP ITSM abarca todos los procesos de ITIL y
amplía el marco con los procesos derivados de su experiencia en el
campo.
 El SMSL de IBM se apoya en la Gestión de Recursos de infraestructura, un
conjunto de soluciones predefinidas derivadas de ITIL.
 El BS 15000 es un marco que utiliza el Código de Prácticas DISCO PD
0005 y la DP 0015 manual de trabajo para la autoevaluación. Usados
juntos, BS 15000 y PD 0005 constituyen un marco comprensible de
mejores prácticas. BS15000 es también integrada con ITIL.
En general se puede observar que ITIL y otros marcos de ITSM muestran los
mismos fundamentos que se utilizan para proporcionar una mejora de calidad. A
pesar de que ITIL tiene una mucho más tiempo y trayectoria además de un mayor
número de seguidores, los marcos como HP ITSM. MOF y SMSL ofrecen poner una

(18)
especial atención en las tecnologías y los dominios. En cuanto a BS15000 hasta
ahora no ha surgido como un estándar ampliamente adoptado. La probabilidad de
que NO será un estándar ISO para la certificación de la gestión de servicios de TI al
menos en el 2006 se estimaba en un 80%.
Sin embargo, los expertos convinieron en que todos los esfuerzos de mejora
en la gestión de servicios TI se deben hacer con ITIL y con el BS15000 como marco
de referencia y línea base, a pesar de BS15000 está en su infancia.
Además de los modelos de gestión de servicios TI (ITSM mencionados) están
los modelos de gobierno de TI, que fundamentalmente se preocupan por dos cosas:
que la tecnología ofrezca valor al negocio y que los riesgos de TI se vean mitigados.
Esto lleva a la atención a cuatro principales las áreas del Gobierno de TI, todos
impulsados por el valor de las partes interesadas. Dos de ellos son los resultados: la
entrega de valor y reducción del riesgo. Dos de ellos son los conductores:
Mediciones de alineamiento estratégico y el rendimiento.
El Gobierno de TI y Gestión de Servicios TI tienen dos propósitos distintos. El
Gobierno de TI a menudo se percibe como la definición del "qué" es lo que
organización de TI debe lograr y como ITSM definir el "cómo" la organización lo va a
lograr.
En el documento se revisan 2 marcos, el primero Control Objetives for Information
and related Technology (CobiT) - Objetivos de Control para la información y
tecnologías relacionadas. Y el segundo marco IT Balanced Scorecard (BSC TI) como
mecanismo de soporte para la desarrollo de la Gobernabilidad de TI dentro de una
organización con un enfoque particular en la alineación estratégica y medición del
desempeño.
CobiT crea el vínculo entre los objetivos de negocio de una entidad, una
tecnología de sus tareas de gestión a través de declaraciones sobre los Objetivos de
Control.

(19)
IT Balanced Scorecard Su idea básica es que la evaluación de una
organización no debe limitarse a una evaluación financiera tradicional, sino debe
completarse con medidas relativas a la satisfacción del cliente, procesos internos y
la capacidad de para innovar.
Para concluir, el Gobierno de TI, la Gestión de Servicios TI y las utilidades de
TI, no se pueden ignorar entre sí, si quieren lograr una nueva visión de
adaptabilidad, en relación a demanda de la infraestructura de TI. El autor sugiere
para asegurar esta nueva visión que la gestión de TI se alinee con los objetivos de
negocio y se adopte una actitud de servicio orientado a la entrega y gestión de las
TI como clave de éxito.
Este trabajo pretende buscar utilizar un marco de referencia para la mejor
administración de las tecnologías de información que se tienen en sitio. El
documento de Mathias Sallé da una visión de cuál es el mejor marco de referencia
(ITIL) y esclarece la visión de este marco. Orientar esta administración o gestión a
la entrega de servicios y no a la gestión de tecnología propiamente.
Para reforzar la idea de que ITIL es el marco de referencia apropiado para el
diseño de los procesos y la importancia que tiene el conocer el grado de evolución
que tiene la organización en cuanto a administración de tecnologías que
actualmente la organización que motiva este trabajo, a continuación se referencia el
siguiente artículo, denominado: “ITIL (Information Technology Infrastructure
Library) como Medio para Mejorar la Eficacia de los Servicios de TI. Un caso de
estudio.” De los autores: Sara Ortiz Cantú, Andrés Ruiz Sahagún, Oscar Fernández
Larios, Víctor Ortega Guzmán publicado en 2010. Ponencia escrita para el V
Congreso Internacional de Sistemas de Innovación para la Competitividad 2010
(SinncO 2010) Universidad de Guanajuato, Campus Celaya 25, 26 y 27 de Agosto
de 2010.

(20)
En este artículo se exponen las etapas evolutivas del proceso de
administración de tecnologías de información y cómo mejoran la entrega de
servicios, siempre y cuando estas se hagan de forma gradual, y lo exponen como
sigue:
Al igual que Sallé [1] los autores están de acuerdo en que las tecnologías de
información (TI) son un componente fundamental en las organizaciones y la
administración de los sistemas de información dentro de las organizaciones han
cambiado, ahora su función es la de respaldar estrategias de negocio, procesos
organizacionales, la estructura de la propia empresa y la cultura organizacional.
Además de cambiar su enfoque hacia la producción y atención de servicios y no solo
de hardware y aplicaciones.
Históricamente las tecnologías de información han servido a las organizaciones
como un proveedor de tecnología que ayuda a los negocios a desempeñarse con
mayor eficiencia y a expandirse en nuevas direcciones. Con el paso de los años las
TI se han vuelto la columna vertebral de los negocios al punto que sería imposible
para muchos de ellos funcionar sin ella y lograr el éxito, así lo expresa Sallé, 2004.
A su vez estas han sufrido cambios a lo largo de su existencia el mismo Sallé lo
establece mencionando tres etapas evolutivas de los servicios de TI en la
organización:

(21)
Figura 2 - Evolución de la función de TI en las organizaciones (Fuente: Sallé, 2004).
Como definición Sallé y los autores nos explican que la Administración de la
Infraestructura de Tecnologías de Información (ITIM por sus siglas en inglés) se
enfoca a mejorar la administración de la infraestructura tecnológica, mientras que la
Administración de los Servicios de TI (ITSM) identifica las necesidades de servicio
de los clientes y se enfoca en la planeación y entrega de estos servicios de tal forma
que cumpla los requerimientos de disponibilidad, desempeño y seguridad. Mientras
que la última etapa La Governanza de TI (IT Governance) se enfoca en la evolución
de estos servicios hacia generación de valor al integrarse con el ciclo de vida de los
procesos del negocio, mejorando la calidad de su servicio y la agilidad del negocio.
Para que este cambio o nuevo enfoque se pueda gestar, las organizaciones
deben considerar entre sus prácticas 6 puntos fundamentales según lo explican
Ortiz ET AL:
1) alinear la estrategia de TI a la del negocio u organización
2) difundir la estrategia y los objetivos de Ti en toda la empresa
3) facilitar una estructura para su implantación
4) crear relaciones constructivas y comunicaciones efectiva entre la
organización, el área de TI y los grupos relacionados con la organización

(22)
5) facilitar el desarrollo de competencias del recurso humano para ejecutar
estrategias de TI
6) controlar y evaluar su desempeño
En concordancia con ellos ITIL (Information Technology Index Library)
representa un marco de referencia que permite integrar de forma única los servicios
de TI y los procesos de negocio a lo largo de la cadena de valor, estructurando y
estandarizando los procesos y procedimientos de los servicios de informáticos.
Se expone que el proceso de alineación de TI requiere de procesos,
estructuras, capacidades y relaciones a manera de bloques constructivos. Citando a
Luftman (2007) en ese sentido, quien propone de nuevo el conjunto de seis criterios
para evaluar la alineación de TI y determinar el grado de madurez alcanzado:
comunicaciones, valor, gobernanza, trabajo en equipo, arquitectura y competencias
del área. Según el desarrollo de estos elementos se puede determinar el grado de
madurez que tiene una organización de TI respecto de su alineación con el negocio,
entre mayor grado de madurez hay mayor definición, documentación y más
procesos de apoyo implantados, lo cual requiere de la administración de procesos
de TI; es ahí donde se puede usar como marco de referencia para lograrlo la
propuesta de ITIL.
La Administración de la Infraestructura de Tecnologías de Información (ITIM
por sus siglas en inglés) se enfoca a mejorar la administración de la infraestructura
tecnológica, mientras que la Administración de los Servicios de TI (ITSM) identifica
las necesidades de servicio de los clientes y se enfoca en la planeación y entrega de
estos servicios de tal forma que cumpla los requerimientos de disponibilidad,
desempeño y seguridad. La Gobernanza de TI (IT Governance) se enfoca en la
evolución de estos servicios hacia generación de valor al integrarse con el ciclo de
vida de los procesos del negocio, mejorando la calidad de su servicio y la agilidad
del negocio (Sallé, 2004).

(23)
Tomando en cuenta la visión de Sallé y lo expuesto por los anteriores autores
Ortiz ET AL, la utilización del marco de ITIL como el mecanismo de ITSM para el
diseño de los procesos de la organización mencionada como objeto de este trabajo,
resulta lo más apropiado, aunque se tendrá que evidenciar en qué punto de
evolución se encuentra. Como preámbulo y dados los problemas expresados que
motivan este trabajo, la organización parece encontrarse en el nivel referenciado
por los autores como “ITIM”.
La forma de poder evidenciar esto, es decir de sustentar y clarificar en nivel o
grado de evolución tiene esta organización deberá mostrarse con un análisis que
muestre una metodología y conclusiones bien fundamentadas. Esto es importante
ya que de acuerdo a nivel de madurez o evolución mostrado por la organización se
tendrá el punto de partida para comenzar a modificar los procesos y encaminarlos a
de forma gradual alcanzar los niveles siguientes en el marco de referencia.
Para ello se involucran en este proceso 2 disciplinas más, la primera
acompaña directamente al marco de ITIL. En las últimas versiones ITIL presenta un
marco de referencia para la evaluación de los niveles de madurez que se tienen en
cuanto a la administración de Tecnologías de información, se denomina PMF
(Process Maturity Framwork) esto es sumamente importante, tal como lo
mencionan en el artículo referido los autores Sallé y Ortiz ET AL, adoptar el marco
de referencia de ITIL no es proceso de facto, si no debe ser un proceso evolutivo.
Para ahondar un poco más en este concepto se resume en el siguiente
artículo donde Hank MARQUIS, trata en específico el tema de PMF y su aplicación
para ITIL, el artículo se denomina: “A PRESCRIPTION FOR ITIL”, publicado en la
revista electrónica “DITY™ NEWSLETTER”, IT Experience. Practical Solutions. VOL.
2.11, MAR. 15, 2006. Y este versa lo siguiente:
ITIL, aunque no tiene todas las herramientas, puede llegar a ser implementado de
manera práctica siguiendo algunos pasos que parecieran una receta de cocina.

(24)
El autor Hank Marquis, denota que comúnmente se dice que ITIL no es algo
prescrito, y esta librería no dice cuándo ni dónde empezar.
Según él, ITIL proporciona un marco de aplicación e indica que la evaluación
de la madurez es la clave del éxito. ITIL incluye un marco para medir proceso de
madurez (PMF), un modelo y las instrucciones para la evaluación de madurez de la
organización.
Aunque existen otros modelos que para medir la madurez de los procesos de
administración de TI en las organizaciones tales como COBIT GMM o CMM, PMF es
una solución práctica y aceptable.
Pero, ¿Qué es la madurez en términos de administración de tecnología? El
autor se refiere a la madurez de una organización como “La capacidad para llevar a
cabo”. En una organización madura las prácticas repetibles se convierten en una
norma, por lo que cada vez hay menos "actos individuales de heroísmo." Cuanto
mayor sea la madurez de la organización más eficiente, eficaz y económicas serán
sus operaciones.
En resumen, la madurez de la organización indica “la cantidad de ITIL” para
poner en práctica, y por dónde empezar. Por lo tanto, la evaluación de madurez de
la organización es fundamental para la implementación de ITIL.
Evaluaciones de Madurez
Marquis expresa que las evaluaciones de madurez se utilizan para medir el
grado en que una organización utiliza a su gente, sus procesos, sus herramientas y
productos, y la propia gestión. Las evaluaciones muestran cómo la organización se
compara con otras organizaciones. Se puede utilizar las evaluaciones de madurez
organizacional para ayudarle a manejar la evolución de una organización. Las
evaluaciones muestran oportunidades para mejorar, identifican los estándares
requeridos, los procesos y procedimientos, y facilitar la mejora continua. También

(25)
se puede utilizar la evaluación para mostrar las herramientas, técnicas y tecnologías
necesarias.
Por lo tanto, la evaluación de madurez de la organización se convierte en un
paso previo necesario antes de la implementación de ITIL. A medida que la
implementación progrese, la continuación de la evaluación de la madurez muestra la
mejora de la organización y muestra el momento de poner en práctica nuevos
procesos o actividades adicionales.
PMF - Modelo de Madurez
Un modelo de madurez es un sistema para medir la madurez de los procesos
de una organización. Un modelo de madurez incluye indicadores que muestran la
evidencia de las capacidades. Usando el modelo de madurez, se documentan las
capacidades de los procesos de su organización en una escala objetivo conocida.
Hay muchos modelos de madurez entre los cuales elegir. ITIL ofrece CMM,
COBIT (Modelo de Madurez de Gobierno o GMM) e ISO 15504 como ejemplos. ITIL
también incluye su propio modelo de madurez llamado Proceso de Modelo de
Madurez (PMF.) El PMF ITIL es un modelo de 5 capas como MMG, CMM, CMMI o
CMM (Integración).
La mayoría de modelos de madurez se basan en un modelo de 5 capas, que
van desde 1 a 5. Muy a menudo, el primera (1) representa una etapa "inicial " o la
madurez mínima, y el último (5) representa "optimización" o madurez plena de sus
capacidades.

(26)
Marco del Proceso de Madurez - PMF de ITIL
Este proceso proporciona el marco para la medición de la madurez. El PMF se
puede utilizar como un proceso de medida o de referencia en particular dentro de
una organización, o de un tercero que presta servicios a la organización. El PMF es
útil para examinar por completo los procesos de mejora continua y todos los
procesos ITIL implementados, o bien un proceso individual.
El PMF ITIL tiene 5 niveles:
Nivel PMF Enfoque Comentarios
1 Inicial Tecnología Excelencia tecnológica / Expertos
2 Repetible Productos /
Servicio
Procesos operacionales (Ej. Soporte de
Servicio)
3 Definido Enfoque al
Cliente
Servicio adecuado nivel de servicio
4 Gestionado Enfoque en el
Negocio
Negocios y TI alineados
5 Optimizado Cadena de
Valor
Perfecta integración de las TI en el
negocio y la planeación estrategia para la
toma de decisiones.
Tabla 1 - El PMF ITIL – tomado del artículo de Hank Marquis – “A PRESCRIPTION FOR ITIL”
En el PMF de ITIL según nuestro autor se definen varias dimensiones que
componen cada nivel. Un cierto nivel de madurez es el resultado de los siguientes
factores:
 Visión y estrategia - "La dirección general está en relación directa con el
papel y la posición de las TI en la empresa"
 Dirección - "Los objetivos y las metas de TI están en relación directa a la
realización de la estrategia"
 Procesos - "Los procedimientos necesarios para alcanzar las metas y
objetivos"

(27)
 Las personas - "Las habilidades y capacidades necesarias para llevar a
cabo los procesos"
 Tecnología - "La infraestructura de apoyo que permita la gestión a
realizar"
 La cultura - "El comportamiento y la actitud necesaria en relación con el
papel de las TI en la empresa"
Para cada una de estas dimensiones de la madurez, ITIL describe las formas
de evaluar esta madurez. El "libro verde" ofrece observaciones sobre la forma de
determinar el nivel de madurez adecuado mediante el examen de cada uno de los
factores que componen la madurez.
Hay que tomar en cuenta que para pasar de un nivel a otro se requiere de
cambios sustanciales en cada una de las dimensiones. ITIL incluso menciona que
tratar de mejorar más de un nivel incrementa la posibilidad de que la
implementación fracasara. Además, hay que tener en cuenta que en la organización
no todas las necesidades son las mismas, más aún, la madurez, para tener éxito.
Dado el número de factores que comprenden la madurez, esto es fácil de entender.
Hay que Asegurarse de tener esto en cuenta y no tratar de hacer demasiado o
mejorar muy rápido.
Uso de la madurez
Una vez que haya determinado en que escala de madurez se encuentra la
organización, a continuación, se puede determinar el mejor enfoque para su
implementación. ITIL ofrece tres grandes categorías de planes de aplicación:
1. Enfoque basado en procesos individuales
2. Multi-enfoque basado en procesos
3. Todos los procesos

(28)
ITIL indica que en los niveles de madurez inferiores se debe proceder a lo
largo del enfoque basado en procesos individuales. A medida que aumenta la
madurez, tendrá que moverse más hacia el enfoque basado en procesos múltiples
debido a las interacciones y dependencias de los procesos. De hecho, el nivel cuatro
o más requieren el enfoque de procesos a todos por esta misma razón. Los niveles
más altos de madurez sólo se producen a través de pequeños pasos en todos los
procesos en el tiempo.
Por todo lo anterior Marquis nos hace ver que ITIL es en realidad muy
“prescriptivo”, El define el "qué " (procesos), así como el "dónde / cuándo" (marco
de proceso de maduración) para iniciar su implementación. En general, el "Libro
Verde" de ITIL ofrece una guía completa para entender lo que hay que hacer para
implementar ITIL. Contiene una gran cantidad de información crítica para la
implementación.”
Al hablar de utilizar un marco de referencia como ITIL, surgen las preguntas
del ¿Cómo lograr la implementación? o bien ¿Dónde comenzar dicha
implementación? ¿De dónde partir o qué proceso comenzar a alinear?
El artículo habla sobre la evaluación inicial de la organización con el fin de
definir cuál será el comienzo usando claro está un marco de referencia adicional que
permite precisamente decidir por dónde comenzar.
El PMF es ese marco de referencia y forma parte de ITIL. La descripción que
hace respecto de la forma de utilización de esta herramienta llamada PMF para
definir el camino y el cómo de una implementación de ITIL o ITSM, es sumamente
valiosa ya queda la pauta para lograr alinear los procesos de la organización hacia el
marco de referencia ITIL.

(29)
BPM – Business Process Management
Después de exponer que es ITIL y su conveniente utilización dentro de una
organización de TI y la forma de poder comenzar su aplicación dentro de la
organización, falta algo sumamente importante, el análisis inicial que se realice de
la organización no puede ser subjetivo y no puede basarse en suposiciones, debe
ser una análisis formal que entregue información real y sustantiva de cómo se
llevan a cabo los procesos actualmente, que muestre su eficiencia y eficacia o bien
lo contrario. Además de las herramientas de PMF que puedan usarse para definir el
nivel donde la organización se encuentra, se necesita que se identifique primero el
estado actual que guarda la organización, su comunicación y relación entre los
actores del proceso o procesos a evaluar, etc.
Es ahí donde entra la siguiente disciplina. Tanto para realizar un diagnóstico o
análisis de la organización como para el diseño de los procesos debe usarse una
metodología que permita paso a paso cumplir con ambos objetivos. Para ello se
puso en la mira el uso de BPM (Business Process Management). La Gestión o
administración por procesos de negocio (Business Process Management o BPM en
inglés) es la metodología corporativa cuyo objetivo es mejorar el desempeño
(Eficiencia y Eficacia) de la Organización a través de la gestión de los procesos de
negocio, qué se deben diseñar, modelar, organizar, documentar y optimizar de
forma continua. El Modelo de Administración por Procesos, se refiere al cambio
operacional de la empresa al migrar de una operación funcional a una operación de
administrar por procesos.
Visto de otra manera y bajo la visión que algunos autores como Brett Champlin,
David Fisher, Harmon Paul y Michael Porter; que expresan en el libro ABPMP BPM
CBOK:
"Business Process Management" (BPM) es un enfoque disciplinado para identificar,
diseñar, ejecutar, documentar, medir, monitorear y controlar tanto de forma
automatizada como y no automatizada los procesos de negocio para lograr

(30)
resultados específicos, consistentes y en consonancia con los objetivos estratégicos
de la organización. BPM implica la deliberada, colaborativa y cada vez más la
tecnológicamente asistida, mejora, innovación y gestión de los procesos de
extremo a extremo que impulsan los resultados del negocio, crean valor, y permiten
a una organización cumplir sus objetivos de negocio con mayor agilidad. BPM
permite a una empresa alinear sus procesos de negocio, con su estrategia de
negocios, llevando a un efectivo rendimiento global de la empresa a través de
mejoras de las actividades de trabajo específicas, ya sea dentro de un
departamento específico, en toda la empresa, o entre organizaciones.”
BPM se puede utilizar como un método de intervención que consta de varias
etapas o tareas y actividades así como la aplicación de ciertas herramientas que
permiten esclarecer de forma gráfica o sistémica como se realizan los procesos de
una organización, entre ellas están las etapas de:
 Diagnostico
 Análisis
 Diseño
 Documentación
 Implantación
Esto es que además de ayudar al diseño de procesos de negocio, aporta una
serie de herramientas para el análisis de las organizaciones cuyo objetivo es
mostrar las deficiencias y da un panorama de cómo pueden corregirse y orientase
hacia procesos de mayor desempeño.

(31)
Figura 3 – Áreas del conocimiento de BPM - Tomado del libro ABPMP BPM CBOK®
Organization
Como se muestra en la figura BPM con sus diversas etapas apoya no solo a la
implementación de procesos de negocio sino engloba una visión general que puede
abarcar a toda la organización o empresa, ayudando a completar o concretar los
objetivos del negocio.
Podemos decir con esta sencilla declaración que BPM es: “El logro de los
objetivos de una organización a través de la mejora, la gestión y el control de los
procesos de negocio esenciales.” Pero, ¿Qué es un proceso y la gestión de
procesos?
Proceso y Gestión de procesos
De acuerdo a las definiciones de proceso referidas en el libro “Bussines Process
Management de John Geston”, publicado en 2008, por John Jeston and Johan Nelis.
Editorial: Elsevier Ltd. Roger Burlton expresa: “un proceso de negocio engloba
todas las actividades que deben realizarse para satisfacer las necesidades de los
usuarios de una organización”. Y su definición de Gestión: Gestión “Se refiere al
proceso y el rendimiento de las personas, medición y gestión. Se trata de organizar

(32)
el todo, componentes y subcomponentes esenciales para sus procesos. Con esto
queremos decir la organización de las personas, sus habilidades, motivación,
medidas de desempeño, las recompensas, los propios procesos, la estructura y los
sistemas necesarios para apoyar un proceso.”
Teniendo en consideración las definiciones anteriores, BPM mediante su
método, permite examinar dichos procesos y su gestión determinando mediante el
análisis de su componentes si estos se llevan a cabo o no de forma eficiente, el
método consta de varías etapa, no todas son aplicables a cada organización u
objetivo, pero a continuación se definen que apoyarán parte de este trabajo.
Diagnóstico y análisis de procesos
En las etapas de diagnóstico y análisis se implica la comprensión de los procesos de
negocio o métodos de trabajo, incluyendo la eficiencia y eficacia de los mismos. El
propósito y las actividades de análisis de procesos son una exploración, una
descomposición de componentes y atributos de los procesos, usando técnicas
analíticas, y patrones de procesos. Se usan modelos de proceso y documentación
preestablecida para validar y comprender tanto los procesos actuales como futuros.
Una variedad de tipos de análisis de procesos, herramientas y técnicas se incluyen
dentro de esta área de conocimiento.
Diseño y documentación
Esta metodología implica la creación de las especificaciones de los procesos
de negocio dentro del contexto de los objetivos de negocio y objetivos de
desempeño del propio proceso. Proporciona los planes y pautas de cómo fluye el
trabajo, cómo se aplican las reglas y cómo las empresas, aplicaciones, plataformas
tecnológicas, recursos de datos, controles financieros y operacionales interactúan
con otros procesos internos y externos. El diseño del proceso es la intencional y la
planificación cuidadosa de cómo funcionan los procesos de negocio y se miden,
como son gobernados y administrados. Esta área de conocimiento explora los roles

(33)
de diseño de procesos, las técnicas y los principios del buen diseño, junto con una
exploración del proceso común, patrones de diseño y consideraciones tales como el
cumplimiento, el liderazgo ejecutivo y alineación estratégica.
Desarrolla una etapa de Modelado de Procesos que incluye un conjunto crítico
de habilidades y procesos que permiten a las personas comprender, comunicar,
medir y gestionar los componentes primarios de negocio procesos. El Proceso de
Modelado proporciona una visión general de las habilidades, actividades y
definiciones clave, junto con una comprensión de la finalidad y beneficios del
modelado de procesos, un análisis de los tipos y usos de los modelos de procesos, y
las herramientas, técnicas y estándares para modelado.
Algunos autores consideran que por sus características esta disciplina además
de lo ya expuesto, en su parte de análisis, puede apoyar de forma significativa a la
implementación de procesos de administración de tecnologías como ITIL, ya que su
enfoque principal es que los procesos diseñados aporten a los objetivos de negocio
de una organización, que desde la visión de Sallé, es la mejor forma de visualizar el
aporte de las tecnologías de información a una organización.
Atendiendo a esa idea, se expone el siguiente artículo publicado por Michael
Brenner, donde se aborda el tema de BPM y su relación con ITIL. El artículo se
denomina: “Classifying ITIL Processes Taxonomy under Tool Support Aspects”,
publicado en 2006, por Munich Network Management Team, University of Munich
(LMU). Y este expone lo siguiente:
Referente A los diversos mecanismos que existen para el aseguramiento de la
calidad con lo que los servicios de TI se prestan hoy en día Michael Brenner nos da
a conocer su punto de vista y expone:
Proporcionar servicios de TI a los clientes con una mejor garantía de calidad, ha
sido el objetivo de muchos y diversos esfuerzos bajo el común denominador
"Gestión de Servicios TI".

(34)
Últimamente, muchas de estas iniciativas organizacionales han ido ganando
popularidad, especialmente las que se basan en la IT Infrastructure Library (ITIL)
para la Gestión de Servicios TI enfocados en los procesos de negocio.
Pero al igual que con la mayoría de otros procesos de negocio, la aplicación
de Procesos de ITIL de una manera eficiente implica la construcción o adquisición de
Herramientas de TI que pueden apoyarlos. En este aspecto, ITIL se ofrece sólo una
orientación mínima a este respecto.
Brenner aborda las cuestiones básicas de ITIL con el apoyo de herramientas
orientadas a procesos, tales como sistemas de gestión de flujo de trabajo. Brenner
hace hincapié en la necesidad de usar la gestión de flujos de trabajo para soportar
los procesos de la gestión de servicios, con el fin de lograr el cumplimiento de
niveles de servicio, y presenta criterios para determinar qué procesos de Gestión de
Servicios TI pueden y deben ser apoyados por los sistemas de flujo de trabajo. Los
procesos Gestión de Servicios TI definidos por ITIL se evalúan y se dividen en
cuatro clases de procesos básicos de acuerdo a su aptitud para la gestión de flujo de
trabajo.
Con ello Brenner nos da una visión de cómo la utilización de ITIL como
marco de referencia no es una aproximación correcta para poder decir que se
administran y gestionan los servicios de TI con calidad y eficiencia, por el contrario,
menciona que una de las partes más importantes es la de alinear los procesos de
negocio, y después alinear los procesos de TI a estos procesos de negocio, y para el
autor ITIL se queda corto en este sentido, por lo que debe valerse de otras
herramientas para su correcta aplicación.
El autor menciona que la Gestión de Servicios TI (ITSM) es la disciplina que
se esfuerza para mejorar la alineación de los esfuerzos de TI a las necesidades
empresariales y para gestionar la prestación eficiente de servicios de TI con una
garantía de calidad. Esta disciplina se basa en la administración de los servicios de
TI como procesos.

(35)
En la mayoría de los casos los servicios de TI están orientados a la gestión de
la infraestructura, lo que hace que se pierda o deje de lado el enfoque del cliente.
Deben tomarse en cuenta muchos aspectos que relacionen al cliente con el servicio
prestado, esto se logra comúnmente a través de llevar a cabo acuerdos de niveles
de servicio, estos también están descritos en el contexto de ITIL. Pero a su vez
estos deben de gestionarse de manera tal que también estén alineados con los
objetivos de la empresa o negocio.
Brenner nos hace ver que abordar la gestión de servicios de TI desde el solo
punto de vista tecnológico no es lo apropiado y utilizar solo un marco de referencia
que se basa netamente en las cuestiones técnicas o tecnológicas como ITIL no es
suficiente por el contrario el logro eficiente de mayores niveles de servicios
relacionados con la disponibilidad de los servicios, no se puede hacer sin una
organización que como ITSM puede brindar por ejemplo. La gestión de los Servicios
de TI Por lo tanto, debe basarse en dos pilares de con igualdad de importancia
según nos indica Brenner: Un enfoque tecnológico (ITIL) y un enfoque hacia la
organización, basado en los principios de gestión de procesos empresariales (BPM).
Como ya se ha expuesto el proyecto básicamente busca que los servicios de
TI que actualmente se prestan se gestionen de manera eficiente y en un marco de
calidad. El utilizar el enfoque tecnológico como se ha hecho hasta ahora, resultaría
en redundar en las mismas soluciones. De acuerdo al artículo de Brenner el uso de
otro marco de referencia con un enfoque hacia la organización acompañando al
marco técnico, es la mejor forma de poder gestionar los servicios con un valor
agregado para la empresa, en particular el uso de un marco denominado BPM, que
permite realizar el diseño y la gestión de procesos alineado a los objetivos de la
empresa que sumados al marco de referencia de ITIL, pueden dar como resultado la
correcta gestión de los servicios.
Basados en que el autor considera que utilizar ITIL puramente para la gestión
de servicios de TI no es suficiente y no presenta una garantía de la calidad y

(36)
eficiencia de los mismos. El marco de referencia o la metodología de BPM pueden
usarse como habilitadores del diagnóstico, diseño y la implantación los procesos de
ITIL en la organización.
Herramienta de Diseño - BPMN
El principal objetivo de BPMN es proporcionar una notación estándar que sea
fácilmente legible y entendible por parte de todos los involucrados e interesados del
negocio (stakeholders). Entre estos interesados están los analistas de negocio
(quienes definen y redefinen los procesos), los desarrolladores técnicos
(responsables de implementar los procesos) y los gerentes y administradores del
negocio (quienes monitorean y gestionan los procesos). En síntesis BPMN tiene la
finalidad de servir como lenguaje común para cerrar la brecha de comunicación que
frecuentemente se presenta entre el diseño de los procesos de negocio y su
implementación.
El modelado en BPMN se realiza mediante diagramas muy simples con un
conjunto muy pequeño de elementos gráficos. Con esto se busca que para los
usuarios del negocio y los desarrolladores técnicos sea fácil entender el flujo y el
proceso. Las cuatro categorías básicas de elementos son:
 Objetos de flujo: Eventos, Actividades, Rombos de control de flujo
(Gateway)
 Objetos de conexión: Flujo de Secuencia, Flujo de Mensaje, Asociación
 Swimlanes (Carriles de piscina): Pool, Lane
 Artefactos: Objetos de Datos, Grupo, Anotación
Estas cuatro categorías de elementos nos dan la oportunidad de realizar un
diagrama simple de procesos de negocio. La figura siguiente muestra estos
elementos:

(37)
 Eventos
 Actividades
 Compuertas (Control de
flujo)
 Conexiones
Figura 4 - Objetos de Flujo y Objetos de Conexión BPMN
Los objetos de Flujo son los elementos principales descritos dentro de BPMN y
consta de tres elementos principales; Eventos, Actividades y Compuertas (Control
de Flujo).

(38)
Eventos
Están representados gráficamente por un círculo y describen algo que sucede
(lo contrario de las Actividades que son algo que se hace). Los eventos también
pueden ser clasificados como Capturado o Lanzado.
Evento Inicial
Actúa como un disparador de un
proceso. Se representa gráficamente
por un círculo de línea delgada y
dentro del círculo este puede
rellenarse de color verde. Este evento
permite Capturar.
Evento Final
Indica el final de un proceso. Está
representado gráficamente por un
círculo de línea gruesa y dentro del
círculo este puede rellenarse del color
rojo. Este evento permite Lanzar.
Evento intermedio
Indica que algo sucede entre el evento
inicial y el evento final. Está
representado gráficamente por un
círculo de doble línea simple y dentro
del círculo este puede rellenarse de
color naranja. Este evento puede
Capturar o Lanzar.
Tabla 2 – Descripción de eventos BPMN
Actividades
Se representan por un rectángulo con sus vértices redondeados y describe el
tipo de trabajo que será realizado.

(39)
Tarea
Una tarea representa una sola unidad
de trabajo que no es o no se puede
dividir a un mayor nivel de detalle de
procesos de negocio sin diagramación
de los pasos de un procedimiento.
Subproceso
Se utiliza para ocultar o mostrar otros
niveles de detalle de procesos de
negocio - cuando se minimiza un
subproceso se indica con un signo más
contra de la línea inferior del
rectángulo, cuando se expande el
rectángulo redondeado permite
mostrar todos los objetos de flujo, los
objetos de conexión, y artefactos.
Tiene, de forma auto-contenida, sus
propios eventos de inicio y fin; y los
flujos de proceso del proceso padre no
deben cruzar la frontera.
Transacción
Es una forma de subproceso en la cual
todas las actividades contenidas deben
ser tratadas como un todo. Las
transacciones se diferencian de los
subprocesos expandidos por estar
rodeando por un borde de doble línea.
Tabla 3 – Descripción de actividades BPMN
Compuertas (Control de Flujo)
Se representan por una figura de diamante y determinan si se bifurcan o se
combinan las rutas dependiendo de las condiciones expresadas.

(40)
Los objetos de conexión permitirán conectar cada uno de los objetos de flujo.
Hay tres tipos: Secuencias, Mensajes y Asociaciones.
Flujo de Secuencia
Está representado por línea simple
continua y flechada; y muestra el
orden en que las actividades se
llevarán a cabo. El flujo de secuencia
puede tener un símbolo al inicio, un
pequeño diamante indica uno de un
número de flujos condicionales desde
una actividad, mientras que una barra
diagonal (slash) indica el flujo por
defecto desde una decisión o actividad
con flujos condicionales.
Flujo de mensaje
Está representado por una línea
discontinua con un círculo no relleno al
inicio y una punta de flecha no rellena
al final. Esto nos dice, que el flujo de
mensaje atraviesa la frontera
organizativa (por ejemplo, entre
piscinas). Un flujo de mensaje no
puede ser utilizado para conectar
actividades o eventos dentro de la
misma piscina.
Asociaciones
Se representan por una línea
punteada. Se suele usar para conectar
artefactos o un texto a un objeto de
flujo y puede indicar muchas
direcciones usando una punta de
flecha no rellena (hacia el artefacto
para representar a un resultado,
desde el artefacto para representar
una entrada, y los dos para indicar

(41)
que se lee y se actualiza). La No
Direccionalidad podría usarse con el
artefacto o un texto está asociado con
una secuencia o flujo de mensaje
(como el flujo muestra la dirección).
Tabla 4 – Descripción de Compuertas control de lujo BPMN
Carriles de Nado y Artefactos
Carriles de nado
Objetos de Datos
Grupos
Anotaciones
Figura 5 – Carriles de cado y artefactos BPMN
Los Carriles de Nado son un mecanismo visual de actividades organizadas y
categorizadas, basados en organigramas funcionales cruzados y en BPMN consta de
dos tipos:

(42)
Piscina Representa los participantes
principales de un proceso, por lo
general, separados por las diferentes
organizaciones. Una piscina contiene
uno o más carriles (en la vida real,
como una piscina olímpica). Una
piscina puede ser abierta (por
ejemplo, mostrar el detalle interno),
cuando se presenta como un gran
rectángulo que muestra uno o más
carriles, o cerrada (por ejemplo,
esconder el detalle interno), cuando
se presenta como un rectángulo vacío
que se extiende a lo ancho o alto del
diagrama.
Carril Usado para organizar y categorizar las
actividades dentro de una piscina de
acuerdo a su función o rol; y se
presenta como un rectángulo estrecho
de ancho o de alto de la piscina. Un
carril contiene objetos de flujo,
objetos de conexión y artefactos.
Tabla 6 – Descripción de carriles de cado BPMN
Los Artefactos permiten a los desarrolladores llevar algo más de información
al modelo o diagrama. De esta manera, el modelo o diagrama se hace más legible.
Son tres artefactos predefinidos y son:
Objetos de Datos Muestra al lector cual es el dato que
deberá ser requerido o producido en
una actividad.

(43)
Grupos Se representan por un rectángulo de
líneas discontinuas y vértices
redondeados. El Grupo se utiliza para
agrupar diferentes actividades pero no
afecta al flujo dentro de un diagrama.
Anotación Se utiliza para darle al lector una
descripción entendible del modelo o
diagrama.
Tabla 7 – Descripción de artefactos BPMN
Con la siguiente figura se ejemplifica un diagrama de proceso de negocio simple:
Figura 6 – Ejemplos de Diagramas de Procesos de Negocios en BPMN
Con el uso de esta herramienta se desarrollarán los primeros bosquejos de
los procesos seleccionados para ser rediseñados apoyando a la implementación.

(44)
KM – Knowledge Management - Gestión del conocimiento
Como parte final dentro de todo proceso, las experiencias acumuladas son
importantes y más aún es importante recopilarlas y dejarlas como evidencia y como
referencias futuras. Toda organización que sufre cambios o mejoras continuas ha
tenido que evaluarse y reevaluarse de forma constante y continua. Para ello recurre
a mecanismos que le permitan aprender de sus errores y aciertos. Es decir que en
transcurso del tiempo debe ser una organización que aprende.
Existe una disciplina que desarrolla este tema y se le conoce como KM
(Knowledge Management). La gestión del conocimiento (GC) es un concepto
aplicado en las organizaciones. Tiene el fin de transferir el conocimiento desde el
lugar dónde se genera hasta el lugar en dónde se va a emplear, e implica el
desarrollo de las competencias necesarias al interior de las organizaciones para
compartirlo y utilizarlo entre sus miembros, así como para valorarlo y asimilarlo si
se encuentra o se adquiere en el exterior de estas.
En general se puede considerar a la GC como una disciplina que se enfoca al
mejoramiento de los procesos de aprendizaje organizacional y a la innovación en los
negocios. Es decir consiste en producir, compartir y usar el conocimiento, se
encarga del registro y la disponibilidad del conocimiento, de la implementación del
mismo y provoca las condiciones para el desarrollo, crecimiento y la innovación de
nuevo conocimiento.
Para aprovechar las características de la Gestión del Conocimiento dentro de
la organización, es necesario entender que los problemas de las organizaciones
requieren procesos de solución basados precisamente en el aprendizaje
organizacional. Es a través del uso del conocimiento en la resolución de los
problemas de negocios, que se pueden obtener un conjunto de resultados
debidamente interpretados, para tomar las decisiones pertinentes y continuar con
un nuevo ciclo de solución de los problemas del negocio. Este concepto se puede
representar como sigue:

(45)
Figura 7 Solución de Problemas del Negocio y el ciclo de vida de conocimiento - Tomado de
APUNTES DE GESTIÓN DEL CONOCIMIENTO Autores: MTRA. SARA ORTIZ CANTÚ Y MTRO.
ANDRÉS RUIZ SAHAGÚN, GUADALAJARA, JALISCO. OCTUBRE DE 2009
Al llevar a cabo un proceso como la adopción de ITIL esto es muy importante,
ya que de manera paulatina, la organización tendrá que ir aprendiendo y
compartiendo lo aprendido para que pueda ir de forma progresiva, creciendo y
evolucionando.
Este es uno de los temas que deberán abordarse y tratar de enfatizar a lo
largo del diseño de los procesos basados en ITIL.
Este es una disciplina extensa, autores como Senge, Nonaka y Konno,
Davenport y Prusak, han escrito mucho referente a ello, sin embargo para
ejemplificar de manera puntual cuál sería la aportación a este proyecto de la
mencionada disciplina, se expone lo que María Mvungi and Ian Jay en su artículo:
Knowledge Management Model for Information Technology Support Service,
publicado en 2010 por: University of Cape Town, South África. Electronic Journal of

(46)
Knowledge Management Volume 7 Issue 3, (353 - 366). Expresan respecto del uso
de KM en uno de los procesos de ITIL, el artículo expresa lo siguiente:
Como resultado de una investigación realizada, que evalúa cómo una organización
puede conceptualizar la gestión del conocimiento (KM) y utilizarlo en el Soporte de
TI para maximizar la productividad del usuario.
Las autoras exponen que el soporte a usuarios ha existido desde la inclusión
de las computadoras en los negocios y con su fuerza de trabajo dependiendo de la
tecnología, las organizaciones dependen de la calidad de la tecnología de la
información (TI) y de los servicios de apoyo para restaurar de forma rápida y
prevenir cualquier inactividad debido a una falla en la tecnología. La normalización
de los sistemas, y la velocidad con la que el conocimiento llega a ser redundante,
hacen que el conocimiento del personal técnico de apoyo se adquiera y se deseche
en forma continua. Esta investigación encontró que la base para la gestión del
conocimiento para las áreas de soporte de TI son: la estrategia y la cultura basadas
en la construcción del compromiso y la reciprocidad. Además, la comunicación y la
competencia fueron identificadas como condiciones adicionales habilitadoras. A
partir de esto, nos presentan un modelo de KM – Knowledge Management o GC –
Gestión del conocimiento adaptado para Soporte de Servicio. El modelo está de
acuerdo con Nonaka y Konno y con el concepto de los procesos de Socialización-
Exteriorización-Combinación-La internalización (SECI).
El soporte a usuarios se define como "una función especializada que
conserva, en nombre de la población de usuarios de la empresa, los conocimientos
técnicos acerca de la información y la forma en que la empresa que la utiliza, con el
fin de ofrecer ese conocimiento en una forma enfocada a resolver determinados
problemas técnicos de dos formas reactiva y proactiva, de manera que la
productividad del usuario se mantenga y mejore, y así el usuario pueda contribuir a
los objetivos de negocio de la compañía ".

(47)
La Gestión del Conocimiento (GC) ha sido una disciplina establecida desde
1995. El movimiento de la gestión del conocimiento se expandió y puso en la visión
de los administradores "que lo que una organización y sus empleados sabemos es
fundamental para el éxito de las empresas” (Davenport y Prusak, 1998).
De acuerdo a las autoras del artículo muchos de los recursos dedicados a la
GC se pueden encontrar como parte de los departamentos de Tecnología de la
Información. Un punto de vista tecno céntrico de la GC es un enfoque en la
tecnología que mejora el intercambio de conocimientos y el crecimiento. Las
tecnologías para la gestión del conocimiento GC se han expandido desde mediados
de 1990 y se conocen como facilitadores del conocimiento (Davenport y Prusak
1998).
KM y servicios de soporte de TI
La falta de gestión de los conocimientos técnicos en tecnologías de servicios
de apoyo tiene un costo sustancial, basado en el hecho de que sin esa gestión se
puede cometer el mismo error dos veces (o más), o en la incapacidad para
encontrar lo que la empresa sabe rápidamente en la solución de problemas. Para
mitigar estos costos, los Servicios de TI Management (ITSM) analizan la gestión de
los sistemas de TI centrándose en la perspectiva del usuario y su contribución a la
empresa. ITSM es una disciplina de gestión de tecnología de la información cuya
función primaria es ser facilitador de los objetivos de Gobierno de TI. Basada en la
Information Technology Infrastructure Library (ITIL).
En pocas palabras las autoras describen que el uso de la Gestión de
conocimiento en el proceso de soporte de TI, como parte integral de los servicios de
TI basados en ITIL, puede ayudar a mejorar el rendimiento y tiempo de respuesta.
Usando lo que la organización ha aprendido durante el proceso de la entrega de
estos servicios.
El uso eficiente de los recursos de TI, tanto tecnológico como humano es
sumamente importante. El artículo describe como el uso de la GC pude ayudar a

(48)
mejorar la eficiencia de ambos, que es el objetivo ulterior del proyecto. Por lo que al
adoptar una estrategia basada en el marco de referencia de ITIL y del Soporte de
TI, es muy acertado adoptar una estrategia de GC, ya que puede ayudar a hacer
más eficiente el proceso.
Se puede sustentar la inclusión de una estrategia básica de GC, con el fin de
recabar y utilizar el conocimiento obtenido a través del soporte de los servicios de
TI en el área. Y tal vez del propio proceso de implementación de los procesos de
ITIL en esta área en particular, para ser compartido con el resto de la organización.

(49)
Descripción de la solución propuesta
Basados en todo lo expuesto anteriormente como marco o sustento teórico y con la
visión de conseguir los objetivos planteados se ha concebido llevar a cabo una
secuencia de trabajos comenzando con una etapa de diagnóstico de la organización
para situarla en un contexto que permita evaluar su madurez respecto de los
marcos de administración de tecnologías y de calidad de servicio. Con el fin de
establecer un punto de partida. En una segunda etapa realizar un diseño o rediseño
de procesos seleccionando los más apropiados y pertinentes, buscando que estos se
alineen a los objetivos de negocio que persigue la Gerencia ASARE y lineamientos
de “Gobernabilidad de TI” que a nivel institucional se han definido, en el ámbito
específico de la Oficina de Operación de Soluciones Remota.
Como tercera etapa se deberá llevar a cabo un plan de implementación de
estos nuevos procesos así como la medición de los mismos una vez implantados.
En una cuarta etapa se deberá llevar a cabo un siguiente diagnóstico para
medir el grado de avance de la organización con este rediseño de procesos y se
deberá plantear los pasos para una etapa posterior donde se deberá tender a incluir
estos procesos en una mejora continua y en el diseño de más procesos. De manera
tal que se lleven a cabo las iteraciones necesarias hasta terminar de incluir todos los
procesos del área que coincidan en el marco de ITIL, que es objetivo de este
trabajo.
En la siguiente figura se muestra un mapa conceptual del proceso concebido
para la realización de este trabajo:

(50)
Estrategia metodológica (Metodología)
Figura 8 - Estrategia metodológica – Diseño del autor.
Para lograr acabo estas etapas, se ha optado por utilizar la metodología de
BPM – Business Process Management, con la cual se pretende realizar el análisis
actual de las funciones del área en cuestión, a través de ella mostrar las
deficiencias. Y de forma posterior el rediseño de los procesos.
Para este diagnóstico y análisis se utilizarán las siguientes herramientas de
BPM:
Diagnostico
Mediante la aplicación de pruebas diagnósticas enfocadas a analizar áreas en
específico, se realiza una evaluación inicial de la organización, a continuación se
describe de manera general cuáles de estas pruebas se utilizaron para explicar lo
qué se espera obtener como resultado de cada una.
BPM
Planteamiento
y definición
del problema
Diagnostico
de la
organización
Diseño o
rediseño de
procesos
Implantación
de nuevos
procesos
Diagnostico
de la
organización
(PMF)
Marco de referencia Conceptual (ITIL, ITSM y KM)
Alineación a Objetivos de Negocio y Lineamientos de Gobernabilidad de TIC’s Institucionales
BPM
Planteamiento
y definición
del problema
Diagnostico
de la
organización
Diseño o
rediseño de
procesos
Implantación
de nuevos
procesos
Diagnostico
de la
organización
(PMF)
Marco de referencia Conceptual (ITIL, ITSM y KM)
Alineación a Objetivos de Negocio y Lineamientos de Gobernabilidad de TIC’s Institucionales

(51)
Diagnóstico Organizacional
Para desarrollar este diagnóstico, se lleva a cabo la aplicación de una serie de
entrevistas, que permiten esclarecer la visión que cada uno de los miembros tiene
de la organización y de las actividades que en ella se realizan. Con los resultados se
elabora un organigrama y además se construye un mapa de los roles y actividades
que cada uno de los miembros de la organización realiza.
Su aplicación determina el grado de homogeneidad de la visión y forma de
hacer las cosas en una organización. Muestra si estas son realizadas de manera
similar por todos los miembros, así como permite visualizar si la información sigue
un flujo correcto y apunta a seguir un proceso determinado.
Diagnóstico de Clientes, Productos y Servicios
Este diagnóstico nos permite entender qué productos y servicios ofrece la
organización y quiénes son los clientes, desde el punto de vista de quienes realizan
las actividades.
Esto se logra usando un mecanismo similar de entrevistas, donde se incluye
al personal directivo o de mayores jerarquías en primera instancia. Y después al
resto del personal. La intención es verificar si hay claridad con respecto a para
quiénes se trabaja y qué actividades se realizan de forma concreta para cada uno.
Diagnostico Tecnológico
Este diagnóstico tiene su base en la misma aplicación de las entrevistas realizadas, el
objetivo es verificar si la organización cuenta con las herramientas, documentación y
tecnologías necesarias para realizar las labores cotidianas.

(52)
Diagnóstico de procesos SIPOC
SIPOCs (Suppliers, Input, Process, Outputs, Customers) Este diagnóstico consiste
en elaboración de un documento que describe las actividades que se realizan de
forma pormenorizada y descriptiva donde se evidencian las entradas y salidas de
información para cada actividad o función. Tiene su base en las entrevistas tanto
iniciales como específicas. El fin es apreciar cómo se realiza el trabajo dentro de la
organización. Y verificar si las actividades se realizan de manera consistente por
todos los integrantes de la organización. Estos son un documento sumamente
importante, ellos describen el(los) proceso(s) que se siguen en la organización y
permiten ver sus deficiencias y posibles puntos de mejora.
Análisis
De la misma manera a continuación se explican las herramientas usadas para el
análisis de la información obtenida como parte del diagnóstico:
Análisis de Funciones y Actividades
Como parte del análisis de la situación actual de la empresa, se comienza por
realizar un documento denominado Diagrama de Vista Horizontal, esto consiste en
la elaboración de un gráfico que permite dibujar a todos los actores que participan
en un proceso o actividad, tales como: las entradas y salidas de información,
clientes y proveedores y sobre todo para resaltar los flujos de trabajo existentes.
Estos son perfilados utilizando los documentos SIPOC ya elaborados. Esto permite
de forma visual identificar cuellos de botella, flujos atascados o innecesarios, etc.
Análisis de Información y Trazabilidad
Este análisis consiste en la revisión de los documentos que se usan en la
organización, generando un diagrama de distribución de documentos. Este

(53)
documento nos permite darnos cuenta de cómo se comparte la información en la
empresa desde su origen hasta su destino final.
Para poder medir el grado de avance (de existir) que la organización tiene
referente al marco de ITIL se utilizará la siguiente herramienta:
Evaluación inicial de la madurez de procesos
PMF
Mediante el uso del marco de referencia PMF de ITIL, se calificará el grado de
cumplimiento con lo establecido en el propio marco de ITIL, realizando una
comparativa con las características que define contra los resultados obtenidos del
análisis previo. Esto nos podrá dar datos situacionales que permitan establecer el
punto de partida para el diseño o rediseño de los procesos.
Diseño de procesos
Toda vez que se tenga definido el estado dentro del marco de referencia PMF, se
llevará a cabo el rediseño de los procesos, usando el marco de ITIL para diseñar los
procesos más adecuados que encajan en el área, para comenzar a elevar el nivel de
madurez de la organización en cuanto a la gestión de tecnología. La intención es
hacerlo de forma paulatina, de tal forma que se puedan adoptar los modelos de ITIL
de la forma más transparente posible.
Primero, se desarrollará un anteproyecto general mediante la elaboración de
un mapa o documento denominado mapa de arquitectura de procesos, este mapa
arquitectura de procesos representa de manera gráfica el modelo de negocio de una
empresa, esto es la manera de conducir sus actividades con una orientación a
procesos.

(54)
Mapa de arquitectura de procesos
Esta figura es tomada de la metodología BPM y consiste en la representación (o
modelado) detallado de las actividades de cada uno de los procesos de negocios
identificados. La arquitectura de procesos constituirá en sí el modelo de negocio de
la empresa.
En esta concepción general se tratará de orientar los procesos modelos al
marco de ITIL comparando las actividades contra los procesos que propone ITIL,
ello nos permitirá proponer el primer diseño.
Para el diseño de los procesos de forma individual se utilizará otra
herramienta de BPM denominada BPMN.
Para el diseño de los procesos, se eligió continuar con el uso de las herramientas de
BPM, en este caso se utilizará la Business Process Modeling Notation o BPMN (en
español Notación para el Modelado de Procesos de Negocio), esta es una notación
gráfica estandarizada que permite el modelado de procesos de negocio, en un
formato de flujo de trabajo (workflow).
Implantación
La implementación se pretende realizar mediante la integración de grupos de
trabajo, de tal forma que la inclusión de los nuevos procesos se lleve de forma
colaborativa, prestando atención a los principios del marco de referencia de la
Gestión de Conocimiento (KM o GC). En adición se pretende establecer una
estrategia de captación de todo el conocimiento que se genera con la operación
diaria de los servicios de TI en esta entidad. Esta última de igual forma deberá ser
aplicada de forma gradual.

(55)
Segunda evaluación de la madurez de procesos
Una vez concluidas las primeras etapas, se entrara en un periodo de mejora,
donde usando el mismo marco de PMF se volverá a evaluar el grado de madurez
respecto de ITIL, corrigiendo y alineando los procesos, para que cumplan con las
disposiciones de los niveles superiores de madurez.

(56)
CAPÍTULO I - ANÁLISIS
1.1 Evaluación preliminar de la organización
Como ya se expuso el documento pretende establecer un mecanismo que de
manera paulatina permita realizar los cambios necesarios, con el objetivo de poder
llevar al proceso y a la organización a adoptar las mejores prácticas en cuanto a
administración de tecnologías y servicios de información. Estos cambios deberán ser
constantes de tal suerte que se establezca una sinergia de evolución y mejora
constante es decir, un mecanismo de “mejora continua”. Este término es
recurrentemente utilizado dentro de la metodología de rediseño o reingeniería de
procesos llamada BPM (Business Process Management) o BPI (Bussines Process
improvement), en donde se trata de conseguir mejoras en los productos y/o
servicios mediante la introducción de pequeños cambios de forma sistemática,
opuesta a la idea tradicional de conseguir mejoras a través de cambios radicales o
grandes innovaciones tecnológicas o directivas.
Es por ello que como primer etapa para este proyecto, se utilizó la
metodología de BPM, para realizar un análisis de la situación actual, con el fin de
esclarecer en qué punto se encuentra la organización, dónde se encuentran los
problemas principales y cuáles son los cambios pertinentes qué deberán hacerse
para conseguir de manera gradual la mejora en la forma en qué se realizan las
actividades diarias, utilización de documentos, cómo y dónde se generan, cómo y
dónde se aprovechan, cuál es el flujo siguen, etc.
Básicamente se aplicó un método de intervención que aplica tareas y
actividades, así como algunas de las herramientas que BPM ofrece y que permiten
esclarecer de forma gráfica o sistémica como se realizan los procesos de una
organización, a continuación se describen las herramientas que se utilizaron en
este trabajo:

(57)
 Diagnostico
 Análisis
Aplicación del proceso de Evaluación
Como ya se explicó, la primera etapa del proceso consiste en una evaluación
diagnostica de la organización que nos permita; establecer dónde se encuentra
posicionada, buscar los problemas y puntos de mejora, esto ayudará a rediseñar de
forma más acertada los procesos existentes y diseñar los nuevos que fueran
necesarios.
Entrevistas
Para dar inicio al análisis se realizó un programa de entrevistas aplicadas en
diferentes etapas, la primera se aplicó al personal directivo como entrevistas
preliminar para conocer la organización y funciones de forma general. Para llevar la
entrevista se diseñó el siguiente cuestionario1
:
1
Para mayor referencia consultar archivo anexo ejemplo de formato de entrevista inicial–
ver tabla de archivos anexos en la sección de anexos al final de este documento.

(58)
Figura 9 – Cuestionario aplicado en entrevista inicial – Diseño del autor.

(59)
Figura 9-A – Cuestionario aplicado en entrevista inicial – Diseño del autor.

(60)
Usando los resultados de dicha entrevista se determina el número de
personas a entrevistar y las posiciones del personal que se involucrará en dichas
entrevistas con el objetivo de profundizar en las funciones enunciadas en las
entrevistas preliminares y poder realizar una descripción más completa de las
actividades que se realizan, se determina entrevistar a todo el personal involucrado
dado que el área no tiene un gran número de personas. Tomando como base el
siguiente organigrama:
Figura 10 – Organigrama de la organización – “Oficina de operación de soluciones remota” –
Diseño del autor.
Matriz de responsabilidades
Derivado de las entrevistas iniciales se lleva a cabo un proceso de construcción de
un documento denominado Matriz de Roles y Responsabilidades, misma que se
anexa a continuación como ejemplo2
:
2
Para mayor referencia consultar archivo anexo ejemplo de matriz de roles y
responsabilidades – ver tabla de archivos anexos en la sección de anexos al final de este
documento.

(61)
Figura 11 – Ejemplo de Matriz de roles y responsabilidades – Diseño del autor.

(62)
Como resultado de la compilación de este documento, se obtuvo una visión
de la organización desde la perspectiva de cada miembro y de las actividades que
cada quien desarrolla, se pueden observar diferencias entre estas visiones y que en
algunos casos no se conoce el suficiente detalle de las actividades que parecen ser
un tanto desconocidas para el personal de operación sobre todo.
Utilizando estos resultados se realiza un programa de entrevistas más
detalladas para profundizar en cada de las actividades o funciones descritas con el
fin de clarificar el número de tareas y la manera de ejecutarlas, esto permite llegar
a la descripción más detallada y tratar de buscar los problemas más elementales
que pueden obstaculizar el correcto desarrollo de las tareas o actividades. Una vez
obtenida toda la información a través de las entrevistas hay que plasmar los
resultados, para representar esto se desarrolló una serie de documentos
denominados SIPOCs.

(63)
SIPOCs
Figura 12 - Ejemplo de SIPOC3
– Diseño del autor
3
Para mayor referencia consultar archivo anexo con ejemplo de SIPOC – ver tabla de archivos anexos en la sección de anexos al
final de este documento.
Análisis SIPOC
Proceso
Dueño del proceso Fecha
Puesto Tiempo en la Organización
Supplier - Proveedor Input - Entrada Process - Proceso Output - Salida Client - Cliente
Operador en turno A Hoja de Checklist El operador A da inicio y realiza un recorrido
por las instalaciones revisando el estado físico
de los equipos mediante la visualización de los
indicadores o displays. Basandose en la hoja
de checklist.
El operador A llena la información
correspondiente al estado de los equipos en la
hoja de checklist.
El operador A realiza una revisión de los
mensajes de error en los archivos de bitácora
en los equipos de computo, comunicaciones y
almacenamiento.
El operador A llena la información
correspondiente a los mensajes de error
encontrados en los equipos en la hoja de
checklist. Hoja de checklist debidamente llenada Operador en turno B
Operador A en turno Hoja de checklist debidamente llenada Una vez terminada la revisión el operador B
captura en contenido de la hoja de checklist en
la Bitácora electrónica de Lotus Notes,
evidenciando los errores. Bitácora de Lotus Notes debidamente
llenada
Operador del siguiente turno,
Supervisores
Operador en turno Bitácora de Lotus Notes debidamente
llenada
De existir mensajes de error durante la revisión,
el operador informa al nivel superior de las
anomalías o errores encontrados de manera
inmediata. Informe de fallas (mediante llamada
telefónica o correo electrónico)
Operador del siguiente turno,
Supervisores
Operadores
Operadores
Monitoreo del estado de la infraestructura
Dirección de Finanzas
Gerencia ASARE

(64)
A través del contenido de los SIPOCs, se realiza una secuencia de actividades
donde se implican a todos los actores que intervienen, los insumos y productos.
En ellos se encontró que en esta organización existen problemas de
comunicación, repetición de actividades, documentos cuyo uso y fin no queda del
todo claro. El origen de algunas actividades no es el mismo. La información
generada no se almacena en un lugar común ni es accesible para todos durante las
actividades, se observa que existen registros manuales lo que dificulta su consulta
posterior.
Diagrama de vista horizontal
Una vez realizada la descripción de funciones se realizó un mapa identificando
de manera gráfica las mismas funciones, se señalaron sus entradas y salidas de
información, obteniendo como resultado el siguiente gráfico, denominado “Diagrama
de vista horizontal de procesos4
”:
4
Para visualizar mejor el mapa consultar archivo anexo de diagrama de vista horizontal –
ver tabla de archivos anexos en la sección de anexos al final de este documento.

(65)
Diagrama de vista horizontal OOSR CFE-ASARE
Figura 13 - Diagrama de vista horizontal del proyecto – Diseño del autor
Instalación y
Actualización
Operación
Monitoreo a la infraestructura
Proveedores
Sun / Oracle
(Hardware / Software)
EMC2 (Hardware)
Cisco Partners
(Hardware)
Huawei Partners
(Hardware –
Comunicinaciones)
Grupo SAC (Facilities)
ALTEC (Facilities)
Servicio
Panamericano
Clientes
Administradores de
Aplicaciones:
Subgerencia de Soporte
de Negocios
Subgerencia de
Administración de
Soluciones
Subgerencia de Servicios
a Usuarios y Resultados
Clientes Externos:
Gerencia Regional de
Producción Occidente
Gerencia Regional de
Transmisión Occidente
Apoyo a
Instalación de
Nuevos Equipos
Monitoreo 1 Monitoreo 2
Cambio de Turno
Apoyo a
Actualizaciones
de equipo
Mantenimiento
Equipos
Control de accesosSalida de materiales
Elaboración de
Inventarios
Elaboración de
Estadísticas
(Desempeño)
Partes o
Equipos
Equipo en producción
O nuevo equipo
Bitácora para consulta
Servicio a Clientes
Entrega de Cintas
Recepción de Cintas
Elaboración de
Planes para Cambios
Elaboración de
Proyectos
Colaboración para
Adquisiciones
Adquisiciones
Locales
Mensaje de error
O nuevo equipo
O nuevo equipo
Monitoreo 1 (2)
O nuevo equipo
Bitácora electrónica
Cambio de turno nocturno
Gráficas de desempeño para consulta
Correo con aviso de Falla
Correo electrónico con Solicitud atendida
Correo electrónico con Solicitud
Correo electrónico con requerimiento
Atención a
Requerimientos 1
Atención a
Requerimientos 2
Req. De autorización
Manejo de fallas e
incidentes 1
Manejo de fallas e
incidentes 2
Manejo de fallas e
incidentes 3
Plan de Trabajo autorizado
Req. De planeación
Proyecto autorizado
Alerta o falla
Atención a
Solicitudes de
Servicio 1
Atención a
Solicitudes de
Servicio 2
Bitácora Electrónica
O nuevo equipo
Mensaje de error
Alerta o falla Alerta o falla
Mensaje de error
Mensaje de error
Mensaje de error
Mensaje de error
Correo de aviso de la falla corregida
Correo de aviso de la falla corregida
Correo electrónico con Solicitud
Req. De planeación
Proyecto autorizado
Correo electrónico con requerimiento
O nuevo equipo
O nuevo equipo
O nuevo equipo
Plan de trabajo
Plan de trabajo
Correo con Informe final y evidencias de instalación
Correo con Informe final y evidencias de instalación
Mantenimiento de
equipo
Listado de personal de manntto.
Correo con plan
de mantenimientos
Correo con
informe final del
mantenimiento realizado
Correo eñectrónico con Solicitud de Req. técnicos
Correo electrónico solicitud de compra
Correo con anexo técnico en formato apropiado
Oficio de solicitud de adquisición acompañado de Dictámenes y autorización
Correo con el listado de cintas
Correo electrónico con la confirmación de la entrega de paquete
Paquete con cintas correo electrónico con la confirmación de la Recepción de paquete
Elaboración de
proyectos para
nuevos servicios
Idea nueva o necesidad detectada
Proyecto aprobado
Control de Acceso al
Site
Salida de Materiales
Elaboración de
Inventarios
Correo con listado de personal a ingresar
Documento de ingreso autorizado y archivado
Material usado para
Atender fallas
Documento de salida autorizado y archivado
Documento con la descripción inicial del equipo Formato de Inventario en excel actualizado para consulta

(66)
El diagrama de vista horizontal como ya se expuso permite visualizar
problemas de flujo de información y falta de comunicación entre procesos, entre
otras cosas.
Para esta organización se observa que para la mayoría de los procesos, no se
tiene un punto único de contacto, lo que dificulta la atención de solicitudes, así
mismo para el monitoreo se tiene varios mecanismo de colección de información
referente a lo que le pasa a los diferentes elementos de TI que se administran,
pero el registro de los eventos que ocurren no se tiene centralizado, por lo que
puede se escapen de la vista de todos durante el proceso, no se observa que se
mantenga al cliente enterado de lo ocurrido en todo momento.
El flujo de la información parece congestionarse y es clara la duplicidad de
actividades.

(67)
Mapa de distribución de documentos
De la misma manera, se realizó un gráfico, dando seguimiento a los documentos utilizados como entradas y
salidas, para determinar su procedencia, flujo y destino final, denominado “Mapa de distribución de documentos”5
:
Figura 14 - Mapa de distribución de documentos – Diseño del autor.
5
Para visualizar mejor el mapa consultar archivo anexo diagrama de distribución de documentos– ver tabla de archivos anexos
en la sección de anexos al final de este documento.

(68)
La finalidad de la construcción de esta herramienta fue verificar la utilidad de
los registros y documentos durante los procesos, el nivel de accesos que tienen y su
utilización por los demás procesos.
El uso de esta herramienta mostro la existencia de documentos duplicados y
que no tienen un propósito específico. Documentos que son elaborados de forma
aislada y utilizados solo por el personal que los elabora, en algunos casos la
información de estos documentos resulto ser valiosa e útil para el proceso pero no
se comparte con el resto de la organización.
La mayoría de los documentos no sigue un estándar, y son elaborados en
formatos libres. Cuando se trata de información similar, esto causa confusión
porque se tiene varias vistas para un mismo contenido.

(69)
1.2 Hallazgos y Recomendaciones
Las herramientas utilizadas para construir los documentos anteriores permitieron
establecer un panorama general de la organización y mostrar de manera tangible
como se están llevando a cabo las actividades dentro de la misma, y con ello emitir
un juicio de valor que de la pauta a la mejora. A continuación se describen los
hallazgos y las recomendaciones y puntos de mejora.
Hallazgos
De acuerdo a las entrevistas se observa que el área es claramente operativa,
dedicada a funciones de administración de tecnologías de información (TI), con base
en las descripciones de actividades y funciones desarrolladas, con la elaboración de
los documentos denominados SIPOCs y los diagramas trazados, se evidencia que la
organización denominada “Oficina de operación de soluciones remota” trabaja con
mecanismos que se apegan más al trabajo por funciones que a trabajo con
procesos, lo que dificulta el flujo de información, re-trabajos y demasiada
documentación. Esto dificulta hacer eficiente el trabajo cotidiano.
Durante el desarrollo de las entrevistas se percibe un sesgo en la
comunicación, aparentemente emanado de diferencias contractuales, esto genera
fundamentalmente dos grupos ya que el personal directivo es empleado de
confianza y el personal operativo es sindicalizado. Aunque no se encuentra
plasmado en ningún lado, se aprecia a través de las respuestas obtenidas del
personal entrevistado. Esto puede representar un problema al momento de
implantar nuevos procesos. Sobre todo en el tema de resistencia al cambio.
Derivado del proceso de descripción mediante la herramienta SIPOC, de
manera puntual se pueden citar los siguientes hallazgos:
De las actividades referidas como “Monitoreo” se observa que no existe una
visión muy clara del propio proceso, y cómo debería manejarse de forma apropiada

(70)
los errores o fallas encontradas, así mismo no hay garantía del registro ni de la
continuidad con la que la información se transfiere entre los integrantes del proceso.
Debería existir un mecanismo estandarizado para el monitoreo de la infraestructura
y establecer bien la línea de escalación en caso de que se presente un error o falla.
Las entradas y salidas de información no están muy claras durante el
desarrollo de las actividades. Parece existir un repositorio común que no es del
conocimiento de todo el personal (según lo expresado en las entrevistas).
El mismo caso se encuentra en las actividades que tienen que ver con el
manejo de un “incidente, solicitud o requerimiento”, y no se tiene un punto de
contacto único, por lo que la atención puede variar dependiendo de la perspectiva
de quien los recibe primero. Esto causa confusión, ya que al momento de atender
cualquiera de ellos no se tiene la retroalimentación en el mismo sentido cuando esta
es atendida, además de que dentro del proceso, no se incluye al cliente de forma
directa o activa, por lo que éste no está enterado del proceso de atención, y causa
desconcierto y descontento porque no tiene la certeza de la atención ni del tiempo
que tardará un solicitud o problema en ser atendido.
No se observa una forma de medir los servicios, ya que no existen
indicadores que marquen la forma de medir la calidad o el tiempo de atención.
La realización de algunas actividades produce re trabajos y duplicado de
información, por ejemplo; una de las tareas que se describen es la obtención de los
“inventarios de los equipos y la infraestructura” con la que se cuenta, pero estos se
obtienen mediante el levantamiento de datos, cada vez que se requieren. Lo que
causa mucho re-trabajo y retraso en los tiempos de atención a la solicitud de
información relacionada. Y tanto el formato como el repositorio de estos datos no
está bien definido por lo que existen varias versiones de la misma información.
Se pueden observar que las actividades asignadas al personal, que aunque
se realizan de forma dispersa, forman grupos de actividades o funciones:

(71)
a) Manejo de información relacionada con los equipos (inventario), su mantenimiento,
entrada y salida de las instalaciones, descritas en las actividades de los SIPOCs:
Apoyo a instalación de Nuevos Equipos
Apoyo a Actualizaciones de Equipos
Mantenimientos
Control de acceso y salida de materiales
Elaboración de inventarios
Elaboración de estadísticas 1 y 2
b) Manejo del monitoreo y los sucesos a los equipos, descritos en las actividades de
los SIPOCs:
Monitoreo 1 y 2
Manejo de incidentes o fallas 1, 2 y 3
Cambio de Turno
Elaboración de estadísticas 1,2 y 3
c) Manejo de Solicitudes y requerimientos, descritos en las actividades de los SIPOCs:
Solicitudes 1 y 2
Requerimientos 1 y 2
d) Elaboración de planes de trabajo y proyectos, cambios en la configuración, etc.
Estos grupos de funciones pudieran describir cada uno un mismo proceso,
solo que no muestran un flujo correcto de información ni de las actividades, ya que
no están bien conectadas o relacionadas entre sí. Por consiguiente la información
que emana de ellos y los documentos o registros no son utilizados de forma
apropiada.
Después de elaborar el mapa de vista horizontal que refleja las actividades
antes descritas como hallazgos principales, se denotan la duplicidad de actividades,
salidas de información que no tiene un fin en particular, y documentación que no es
concentrada en el repositorio común ni está disponible para toda la organización.
De la misma forma el mapa de distribución de documentos para muestra que
hay una gran cantidad de documentos duplicados, precisamente porque no hay una
estandarización en cómo debe fluir la información.

(72)
No hay procedimientos estandarizados y mucho de lo que se realiza, se lleva
a cabo sin un procedimiento escrito, más bien consiste en la aplicación de los
conocimientos personales y experiencias.
El diagnóstico organizacional muestra que aunque se cuenta estructura
(puestos y jerarquías) no se cuenta con documentos que describan las actividades
que la oficina debe realizar ni las responsabilidades. Como resultado de esto,
tampoco se tienen definidos los perfiles de puesto que describa las aptitudes y
habilidades qué debe tener el personal que labora en esta Oficina. Según lo
expresado por el personal durante las entrevistas se debe a que la organización
nació como un proyecto, donde el personal que la conforma fue extraído de diversas
áreas, se trabajó con un el objetivo y metas específicas que se trazaron con el
proyecto. Una vez que estas fueron satisfechas, esta organización se conformó
como un área más de la organización general (CFE). Sin existir un precedente de un
área como esta. Ni las definiciones expresadas.
Por otra parte la visión que se tiene en particular en esta oficina en cuanto a
quién o quiénes deben reportar, presenta dualidades. Lo que dificulta la
comunicación y la entrega de resultados.
De la descripción de quiénes son los clientes, productos y servicios en las
entrevistas se obtuvo como resultado que para los niveles directivos son bastante
claras, sin embargo para el resto de la organización no es así, no se conoce el
impacto de las actividades y a quiénes afecta, por lo que no se persigue un fin
común y no se trabaja en función de satisfacer las necesidades de los clientes desde
los niveles inferiores de la organización.
Tecnológicamente en general se obtuvo un buen resultado basados en las
actividades que cada quién describe. Sin embargo en muy marcado que no se
cuenta con procesos documentados que describan las actividades que la oficina
debe realizar, y la información relacionado con estas actividades se encuentra
dispersa, con diferentes dueños, es decir tiene silos aislados del resto, no se

(73)
comparten ni se encuentran disponibles para toda la organización, lo que dificulta la
resolución de problemas y la oportunidad de atención hacia los clientes.
Se encontraron tareas que se realizan bajo demanda, pero que implican gran
esfuerzo y duplicidad de información, además de mucha documentación que no
tiene un fin determinado.
La visibilidad de los clientes o usuarios de los servicios no es buena, ya que
no se le mantiene informado del proceso de atención, ni de los tiempos de solución.
Podemos notar que la falta de procesos causa confusión en cómo deben llevarse a
cabo las actividades de tal forma que existen varias versiones para hacer la misma
función.
En pocas palabras como ya se explicó el problema radica en el hecho de que
aun y cuando los objetivos que se le plantean a la oficina de operación de soluciones
remota son atendidos y resueltos. Las condiciones en las que los servicios se
prestan están muy alejadas de la eficiencia.
Dado que esta área es considerada un área de soporte y aunque este soporte
es solo interno, es decir que atiende solo a clientes que soportan otras áreas
funcionales de todo el proceso o servicio que se brinda como Gerencia de TI. Es
importante que estos clientes estén satisfechos con los servicios que se prestan, así
como el servicio este aportando al proceso lo necesario para cumplir con las
expectativas de los clientes externos o usuarios finales.

(74)
Recomendaciones
Con base en lo observado y de primera instancia, se sugiere reorganizarse cada
grupo de actividades y tratar de darles orden de tal forma que se lleve a cabo un
primer acercamiento a un enfoque de procesos donde se permita que la información
fluya de manera más coherente.
Esta es un área de tecnología por lo que sería muy bueno adoptar como
marco de referencia las mejores prácticas sobre el tema.
Se sugiere la eliminación de la documentación cuyo fin no sea claro. Y
sustituir en la medida de lo posible los registros manuales por mecanismo
electrónicos (bases de datos y sistemas de información) algunas de las tareas y
generación de información que pueda ser accedida en línea por los clientes o
usuarios con el fin de mantenerlos informados del camino que sigue la atención a
solicitudes, fallas e incidentes relacionados con la infraestructura que administran.
Atendiendo a la estrategia que plantea BPM con respecto de la aplicación de
los cambios y adecuaciones para los procesos en una organización, que dicta que
los cambios se realicen de forma paulatina, pero constante.
Se sugiere priorizar y escoger en base a criterios de mayor productividad o
mayor aportación a los objetivos de la organización, cuáles procesos se rediseñaran
primero.
En el rediseño de los procesos se deberá cuidar qué se puedan alinear con los
objetivos y estrategias de la organización, estos deberán poderse medir, es decir se
sugiere incluir indicadores.
Se propone definir de manera concreta los dueños de cada proceso, así como
los clientes y servicios a entregar, así como los productos esperados de cada
proceso de manera puntual.

(75)
Para las actividades de monitoreo de eventos y solicitudes, deberá
considerarse establecer un punto único de contacto, con el fin de evitar confusiones
y mantener la comunicación eficiente entre los clientes y proveedores de un servicio
o actividad.
La implementación de los procesos deberá atender a qué el área tenga un
mayor control sobre la tecnología y sea capaz de gestionar los elementos de
tecnología (equipos) de una forma ordenada y permita la visibilidad del estado que
guardan los mismos en todo momento por parte del cliente.
Que se gestionen de manera eficiente las solicitudes de servicio que se
realicen a esta área mediante la canalización de las mismas con un solo punto de
contacto. De tal forma que el cliente tenga todo el tiempo la certeza de ¿quién?
¿Cómo? Y ¿Cuándo? Se atiende su solicitud.
Así mismo al terminar este proyecto deberá existir un mecanismo que
permita atender los incidentes y problemas que se presentan con la infraestructura
de forma organizada, enfocando los esfuerzos a atender el menor tiempo y siempre
mantener informados a los clientes involucrados de las acciones tomadas para la
atención de dichos problemas y adicionalmente se establezcan las bases suficientes
para que todo el conocimiento que se genera de la experiencia atendiendo estos
eventos, se capitalice y pueda ser utilizado por toda la organización.
El primera instancia se deberá proponer y contar con un sistema de
información que permita la centralización de toda la información referente a este
proceso, es decir, de todos los componentes de tecnología asociados a los servicios,
de las solicitudes y su gestión, de los incidentes, problemas y su gestión, así como
de todo el conocimiento que se obtenga de la experiencias vividas en el desarrollo
de estos procesos.
Este sistema de información en una primera etapa, no tiene que ser
automatizado, pero si suficiente para permitir el ágil manejo de la información antes

(76)
descrita y tendrá que tener la estructura adecuada para que permita su posterior
conversión a un sistema de cómputo más automatizado.
Como punto final, se deberá mostrar que los cambios propuestos con la
implementación de este proyecto, apuntalan los procesos superiores y muestran
una mejor percepción en el servicio por parte de los clientes.
Ello deberá tender a mejorar la efectividad, la eficiencia, la adaptabilidad y el
control interno de esta área de TI en particular. En el sentido de:
 la efectividad y disponibilidad de la información técnico-administrativa
 el tiempo del ciclo y del tiempo total de los procesos (ej. Tiempos de
respuesta a solicitudes de servicio)
 efectividad y exactitud en el registro de solución a problemas e incidentes
 la relación de las funciones y tareas con la organización administrativa
 la efectividad y eficiencia de la rutina de los procesos técnico-
administrativos
 exactitud, conciencia y repetitividad de las operaciones de procesamiento
de datos, solicitudes, etc.
 productividad de los procesos de negocios técnico-administrativos
 uso y oportunidad de la estandarización
 efectividad y exactitud de los facilitadores tecnológicos (personal de
operación)
Al final deberían existir los indicadores de gestión más apropiados para la
medición del desempeño de esta área de servicio.

(77)
1.3 Evaluación de madurez respecto de ITIL
Con base en estas conclusiones y recomendaciones que hablan de la posición
o estado que guarda esta parte la organización y recordando que esta es un área
que se dedica a la administración de la infraestructura de cómputo, y
preponderantemente es un área de soporte que atiende a clientes internos de áreas
de TI relacionadas. Trataremos de ubicarla en el contexto de madurez de la gestión
de estos elementos, esto nos dará la pauta para que el diseño de procesos se
enfoque primero en cubrir las deficiencias ya mencionadas y segundo que estos se
vayan alineando al contexto de las mejores prácticas de gestión de tecnologías de la
información, tratando de realizar cambios pequeños pero continuos.
Para ello nos valdremos de un poco de la teoría de otra metodología, cuyo fin
en específico es tratar de colocar en un grado de avance o madurez a una
organización respecto de las mencionadas mejores prácticas.
El marco de referencia utilizado para esto, se denomina PMF (Process
Maturity Framework). Este marco de referencia que forma parte de las
recomendaciones contenidas en las librerías de ITIL, nos muestra que en una
organización el nivel de avance se puede medir de acuerdo a la siguiente escala:
Servicio
Servicio)
Cliente
Negocio
Valor
Perfecta integración de las TI en el
negocio y la planeación estrategia para la
toma de decisiones.

(78)
Cada una obedece a como la organización enfoca sus esfuerzos por la gestión
de recursos y servicios de TI, para ser un poco más claros se puede definir cada uno
de los niveles como sigue:
Inicial (Nivel 1): El proceso ha sido reconocido, pero hay poco o ningún proceso o
actividad de gestión y no se asigna importancia al mismo, los recursos no se
centran en la organización. Este nivel también se puede describir como "ad hoc" o
en ocasiones incluso "caótico."
Repetible (Nivel 2): El proceso ha sido reconocido y se asigna un poco de
importancia al mismo, los recursos o el enfoque se centran en la operación. En
general, las actividades relacionadas con la proceso son descoordinadas e
irregulares, sin rumbo y el proceso se dirige hacia eficacia (no a la eficiencia).
Definido (Nivel 3): El proceso ha sido reconocido y se ha documentado, pero no
hay acuerdos formales, existe la aceptación o el reconocimiento de su papel dentro
de la Operación de las TI como un conjunto. Sin embargo, el proceso tiene un
dueño, objetivos y metas formales con recursos asignados y se centra en la
eficiencia, así como la eficacia del proceso. Los informes y los resultados se guardan
para futuras referencias.
Gestionado (Nivel 4): El proceso ha sido totalmente reconocido y aceptado en
todas partes. El servicio está enfocado, tiene objetivos y metas. El proceso está
completamente definido, dirigido y ha adoptado una actitud proactiva con
documentación, interfaces establecidas y dependencias con otros procesos TI
Optimizado (Nivel 5): El proceso ha sido totalmente reconocido y tiene objetivos
estratégicos y objetivos alineados con la estratégica global de negocios y de los
objetivos de TI. Estos se han convertido en " Institucionalizados" en el marco de
actividad diaria para todo el mundo involucrado en el proceso. Un proceso
autónomo de mejora continua es establecido como parte del proceso, que está
desarrollando una capacidad preventiva.

(79)
Esta metodología propone dos perspectivas para el análisis de madurez la
primera nos permite evaluar a la organización en conjunto desde una visión de
múltiples procesos, la segunda desde el punto de vista de procesos individuales
tanto por las características que puede tener como, a través de la percepción que le
cliente tiene de cada proceso o bien del resultado que este pueda entregar.
PMF propone realizar un acercamiento o comparativa entre los objetivos de
cada proceso o procesos con las definiciones que hace de cada nivel tratando de
hacer un “match” para precisar con cuál nivel se identifica la organización o
proceso.
Para realizar identificación más cercana pueden usarse herramientas basadas
en cuestionarios que permitan verificar si se cumplen u observan las características
deseadas por cada nivel. A través de una de estar herramientas se evalúa la
organización motivo de este trabajo, recapitulando lo encontrado como resultado
del análisis de procesos BPM aplicado a esta parte de la organización.
A continuación se muestra este cuestionario6
:
6
Para mayor referencia consultar archivo anexo cuestionario de aplicación para
características del modelo de madurez PMF - ITIL – ver tabla de archivos anexos en la
sección de anexos al final de este documento.

(80)
Figura 15 – Cuestionario sobre características de los niveles de madurez en procesos de ITIL
– Diseño del autor, basado en el artículo: ITIL® Maturity Model and Self-assessment
Service: user guide, Autores: Colin Rudd y John Sansbury.

(81)
Figura 15-A – Cuestionario sobre características de los niveles de madurez en procesos de
ITIL – Diseño del autor, basado en el artículo: ITIL® Maturity Model and Self-assessment

(82)
Figura 15-B – Cuestionario sobre características de los niveles de madurez en procesos de

(83)
Figura 15-C – Cuestionario sobre características de los niveles de madurez en procesos de

(84)
Como puede observarse, de acuerdo al cuestionario en general el o los
procesos que se están llevando a cabo dentro de la organización cumplen con las
características relacionadas al nivel 1 de madurez según el modelo que describe el
PMF:
Servicio
Servicio)
Cliente
Negocio
Valor
Perfecta integración de las TI en el negocio
y la planeación estrategia para la toma de
decisiones.
Este resultado nos permite tener un punto de referencia para partir con la
propuesta de diseño o rediseño de los procesos para esta organización. Tomando en
cuentas las características que define el nivel situado y tratando de cumplir con las
de los niveles subsecuentes.

(85)
CAPÍTULO II – DISEÑO Y REDISEÑO DE PROCESOS
De acuerdo con este nivel de madurez mostrado, la organización se encuentra en un
estado donde el mayor esfuerzo se centra en La Administración de la Infraestructura
de Tecnologías de Información (ITIM) o en ser un proveedor tecnológico. Por lo que
habrá que dirigir los esfuerzos de rediseño de los procesos para que tiendan a
enfocarse más al servicio. Se deberá buscar cambiar el enfoque de funciones a
procesos tomando como referencia los definidos en las librerías de ITIL.
Partiendo de esta aseveración y retomando parte de los resultados del trabajo
de análisis para el rediseño de procesos realizado para este proyecto, se realizó la
identificación de los procesos de ITIL, que de acuerdo a las funciones observadas y
documentadas en el proceso de análisis (BPM) y los grupos de actividades
mencionados pueden encajar y desarrollarse.
2.1 ITIL (Information Technology Infrastructure Library)
Para explicar cómo se aplicará el marco de ITIL, esbocemos de nuevo qué es
y cómo funciona. ITIL fue desarrollado a finales de los ochentas, la Biblioteca de la
Infraestructura de TI (Information Technology Infrastructure Library), mejor
conocida en la industria por sus siglas en inglés, ITIL® es el estándar para la
Administración de Servicios de tecnología de información más aceptado en el
mundo.
Surgió como una guía para el gobierno de Gran Bretaña, pero sus buenas
prácticas han probado ser útiles a organizaciones de muy diversos sectores.
A mediados de los noventas, ITIL fue reconocido como el estándar mundial de
facto para la Administración de Servicios de TI. Una de las aportaciones más
importantes de ITIL a la industria es que introdujo un lenguaje común que ha
mejorado la comunicación entre las áreas de TI y el resto de la organización.

(86)
ITIL se centra en la provisión de servicios de alta calidad, poniendo un énfasis
especial en las relaciones con los clientes/usuarios.
Originalmente, la colección de ITIL constaba de diez libros básicos que eran
soportados por treinta libros complementarios, pero al día de hoy ITIL ha sido
reestructurado a fin de facilitar el acceso a la información necesaria para
administrar los servicios de TI.
Los libros básicos han sido condensados en dos, los cuales cubren las áreas
de Soporte de Servicio (Libro Azul) y Entrega de Servicio (Libro Rojo).
Los procesos tácticos, que se incluyen en el Libro Rojo, se centran en la
relación entre el área de TI y sus clientes. Entre tanto, los procesos de Soporte de
Servicio pueden entenderse como una reacción a las necesidades de cambio que
surgen a fin de poder cumplir con los niveles de servicio pre-acordados con los
clientes.
ITIL se centra en la provisión de servicios de alta calidad, poniendo un énfasis
especial en las relaciones con los clientes/usuarios.
ITIL se compone de 5 procesos relacionados con la entrega del servicio, 5
procesos de soporte al servicio y una función que es el Service Desk o Mesa de
Servicio:
• Mesa de Servicio (Service Desk):
Procesos orientados a dar Soporte al Servicio; son los relacionados con el día a día
del servicio de TI
• Administración de Eventos (Event Management)
• Administración de Incidente (Incident Management)
• Administración de Problema (Problem Management

(87)
• Administración de Configuración (Configuration Management)
• Administración de Cambio (Change Management)
• Administración de Liberaciones (Release Management)
Procesos relacionados con la entrega del servicio de TI
• Administración de Nivel de Servicio (Service Level Management –SLM)
• Administración Financiera de los Servicios de TI (Financial Management)
• Administración de la Capacidad (Capacity Management)
• Administración de la Continuidad de los Servicios de TI (Continuity
Management)
• Administración de la Disponibilidad (Availability Management)
Figura 16 – Modelo de ITIL basado en Entrega de servicio y Soporte de servicio – Gráfico
Tomado de ITIL V3, libro azul.

(88)
Basados en esto, y tomando en cuenta las premisas declaradas con
antelación, donde se explica que en dicha organización los servicios son
preponderantemente de soporte y poniendo especial atención en los grupos de
actividades que se identificaron en la etapa de análisis, se reconoce que de los
procesos que ITIL describe, los siguientes empatan con las actividades que se
realizan:
 Manejo y administración de Solicitudes (Help Desk)
 Administración de las configuraciones e inventarios (Gestión de la
configuración)
 Administración de las operaciones (Operación del servicio)
 Monitoreo y administración de eventos (Gestión de eventos)
 Monitoreo y administración de Incidentes (Gestión de Incidentes)
 Monitoreo y administración de Problemas (Gestión de problemas)
 Administración de Cambios (Gestión de cambios)
En función de esto y para dar una mejor visión y claridad se elabora un
documento denominado “mapa de arquitectura”, es una herramienta para la
representación del modelo de negocio de una empresa, esto es que representa la
manera de conducir sus actividades con una orientación a procesos. Donde se
establecen las ligas de comunicación entre los procesos y cómo se relacionan tanto
con los clientes como con los proveedores identificados en el proceso de análisis, a
través de ella se puede mostrar la propuesta de los nuevos procesos identificados
para esta organización, la siguiente figura es el ejemplo del mapa de arquitectura7
propuesto que incluye los procesos identificados:
7
Para visualizar mejor el mapa consultar archivo anexo de mapa de arquitectura de
procesos – ver tabla de archivos anexos en la sección de anexos al final de este documento.

(89)
2.2 Mapa de Arquitectura de procesos
Figura 17 - Mapa de arquitectura de procesos propuesta – diseño del autor – Basado en los modelos de procesos de ITIL V3.
Infraestructura:Registrosybasesdedatos
Clientes Internos Administradores de Aplicaciones: Clientes Externos:
Manejo y administración de solicitudes
Registro y categorización de
solicitudes
Atención de solicitudes por
soporte o personal de primer
nivel
Atención de solicitudes por
soporte o personal de segundo
nivel o tercer nivel (Proveedor
externo)
Cierre y evaluación de
solicitudes
Notificación con la asignación
y numero de solicitud
Y número de solicitud
Y numero de solicitud
Solución final
Informes sobre el estado y
manejo de solicitudesActualización
De
estado
Datos para cierre (Solución final)
Subgerencia de Soporte
de Negocios
Subgerencia de
Administración
de Soluciones
Subgerencia de
Servicios a
Usuarios y
Resultados
Gerencia
Regional de
Producción
Occidente
Gerencia
Regional de
Transmisión
Occidente
Base de datos de registro de
solicitudes y soluciones (KM)
Solicitud vía correo
electrónico
o
telefónico
Datos de Estado
o
correo de cierre
Datos para registro
De solicitud
Datos para consulta
De estado
Proveedores
Sun / Oracle
(Hardware /
Software)
EMC2
(Hardware)
Cisco Partners
(Hardware)
IBM / THEOS
(Hardware /
Software)
Grupo SAC
(Facilities)
ALTEC
(Facilities)
Servicio
Panamericano
Solicitud de servicio
Solución a solicitud de servicio
Administracióndelasconfiguracioneseinventarios
Registro y clasificación de
equipos
Verificación y auditorías de
configuraciones
Administracióndecambios(ProcesoExterno)
Recepción de equipos
Información para llenado
De plantilla de equipo
Modificación de estado y
configuraciones de los equipos
Base de Datos de
Configuraciones (CMS/CMDB)
Documentación de nuevos equipos
Y
Planes de trabajo
Equipos nuevos o actualizaciones de equipos existe
Plantilla de datos
De equipos
debidamente completada
Estado de modificación
Plantilla de datos
De equipos debidamente
completada y modificada
Solicitud de cambio
De Configuración
Solicitud de cambio
atendida
Modificación a la conf.
Debido a la atención de la
Solicitud.
Modificación a la conf.
Debido a la atención de la
Solicitud.
Plantilla de datos
Consulta de Datos
De
Configuraciones
De Equipos
Baja de equipos
Estado de Baja del equipo
Plantilla de datos
De equipos debidamente
completada y modificada
Para su baja
Administracióndelasoperaciones
Revisión e inspección de
equipos
(checklist’s)
Mantenimiento a equipos
Pruebas a equipos
Política de revisión de equipos
Base de datos de eventos y
bitacora
Registro de estado
anormal de equipos
Hoja de inspección de
mantenimiento
Programa anual de mantenimiento
Registro de evento de
mantenimieto
Programa anual de pruebas a equipos
Registro de resultados
De evento de pruebas
Informe de actividades
Consulta de
Datos
Resultado de la
Consulta de
Datos
Resultadodelaconsulta
Dedatos
MonitoreoyadministracióndeEventos
Monitoreo de eventos
Clasificación, categorización y
registro
Interpretación de eventos y
selección de respuestas
Revisión y cierre de eventos
Base de Datos de Eventos
Documentación del evento
para su registro en la BD
Documentación del evento
Documentación
del evento
para resolución
Documentación del
evento para
revisión y cierre
Documentación
del evento
cerrado
para registro
histórico y
consultas
Consulta en
Registros
anteriores
Plantilla de datos con documentación para monitoreo de eventos
Base de Datos de Incidentes
MonitoreoyadministracióndeIncidentes MonitoreoyadministracióndeProblemas
Notificación del incidente en el
Help Desk o generado por un
evento
Notificación de
incidente generado
por un evento
Notificación de incidente al Help Desk
Recepción y registro de
incidentes
Información para
el documento
del incidente
Categorización y priorización
del incidente
Resolución del incidente de
base a categoría/prioridad
Evaluación y cierre
Documento
del incidente
para registro
en BD
Documentación
del incidente
para resolución
Documento
del incidente
con categoría
y prioridad
Documentación
del incidente
escalado
Documentación
del incidente
atendido
Documentación
del incidente
cerrado para
registro histórico
y consultas
Notificación del
problema generado
por uno o más
incidentes
Documentación
inicial del
incidente
Base de Datos de Problemas
Recepción del problema
Categorización del problema Resolución del problema
Evaluación y cierre
Documento
del problema
para registro
en BD
Documentación
del problema
para análisis
de causas
Documento
del problema
con categoría
Documentación
del problema
resuelto
Documentación
del problema
cerrado para
registro histórico
y consultas
Documentación
inicial del
problema
Determinar la causa del
problema
Actualización
De
estado
Actualización
De
estado
Notificación de evento

(90)
Esto nos da una imagen más clara de hacia dónde hay que llegar, plantea de
forma clara las entradas y salidas de los procesos, su relación y comunicación. Es
una visión general de todo, partiendo de ella puede comenzarse a desarrollar por
partes la implementación de cada proceso, en relación a esto y atendiendo al marco
de referencia PMF que ya se mencionó y a la propia metodología de BPM, tratar de
abordar todos los procesos señalados no resulta una estrategia inteligente, ya que
supondría un cambio radical en la forma de trabajo.
PMF e ITIL a este respecto proponen abordar esto desde el mejor enfoque
posible. Para ello ofrece tres grandes categorías de planes de aplicación:
1. Enfoque único de proceso
2. Enfoque basado en procesos múltiples
3. Acercamiento de todos los procesos
El ITIL indica que en los niveles más bajos de madurez se deben proceder a
lo largo del proceso de enfoque único. A medida que aumenta la madurez, se tendrá
que moverse más hacia el enfoque basado en procesos de múltiples, debido a las
interacciones y dependencias de procesos. De hecho, el nivel cuatro y cinco
requieren el enfoque de todos los procesos por esta misma razón. Los niveles más
altos de madurez sólo se producen a través de pequeños pasos en todos los
procesos en el tiempo.
Eso supondría que para efectos de la implementación deberá iniciarse con
solo uno o algunos procesos, de tal manera que resulten metas a corto plazo y de
manera paulatina se aborden o redefinan el resto de los procesos, estos deberán
diseñarse tratando de cumplir con la características más deseables, y apegados lo
más posible al marco de referencia (ITIL), una vez implantados cada uno por
separado deberá evaluarse de manera periódica, tanto en el cumplimiento de los
niveles de madurez, como en la percepción del cumplimiento de la entrega del
servicio que el cliente tiene respecto del proceso. Esto atendería a la estrategia de
enfoque único de proceso, y a medida que se van cubriendo e integrando el resto de

(91)
los procesos, la visión y las evaluaciones de cada proceso deberán cambiar hacia el
enfoque de procesos múltiples.
Pero, ¿Cómo seleccionar cuáles procesos deberán ser diseñados e
implementados primero? ¿Cómo saber si esa selección es la más apropiada para
comenzar?
Para contestar esto, es muy importante no perder de vista que en la
implementación de estos procesos, debe descuidarse la visión de que los procesos
deben estar enfocados hacia el servicio y la satisfacción de quienes se definen como
clientes o usuarios de los servicios. Y sobre todo que deben aportar algo de valor a
los objetivos y metas de la organización.
Es por ello, guiado por el análisis previo, hecho mediante el proceso de BPM,
se toma en cuenta el resultado que arroja el análisis denominado cadena de valor.
El análisis de cadena de valor es un modelo teórico que permite describir el
desarrollo de las actividades de una organización empresarial mostrando cuales
generan mayor valor al cliente final, el cual fue descrito y popularizado por Michael
Porter en su obra Competitive Advantage: Creating and Sustaining Superior
Performance (1985). Y es muy utilizado por BPM.
Así, en él se plasman cuáles son los procesos y objetivos que de esta parte de
la organización aportan mayor valor a la organización, lo que resulta útil como
punto de partida para comenzar con la implementación de los procesos de ITIL en la
misma. A continuación se muestra en la siguiente figura los resultados obtenidos8
:
8
Para visualizar mejor el gráfico consultar archivo anexo diagrama cadena de valor – ver
tabla de archivos anexos en la sección de anexos al final de este documento.

(92)
Figura 18 – Diagrama de análisis de cadena de valor para la organización: Oficina de operación de soluciones remota, Gerencia
ASARE, CFE. – Diseño del autor.
Infraestructura de la
empresa
Administración de
recursos humanos
Entrenamiento especializado y
relacionado con las tecnologías
y servicios ofertados
Entrenamiento especializado Entrenamiento especializado Entrenamiento especializado
Abastecimiento
-Provisión de materiales y
servicios necesarios para las
actividades de mantenimiento
Desarrollo
Tecnológico
-Sistema de información
relacionado con la
admnistración de Solicitudes de
servicio.
-Sistema de información para el
registro de componentes de
tecnología (inventario)
monitoreo integral de las
tecnologías
relacionado con la
servicio.
'-Sistema de información para el
tecnologías
-Manuales, procedimientos y politicas
bien establecidos
relacionado con la
servicio.
'-Sistema de información para el
tecnologías
-Captación de Eficiente de
Solicitudes de servicios y
requerimientos de nuestros
clientes
-Amplio conocimiento relacioado
con las nuevas tecnologías
utilizadas para brindar el servicio
-Control y registro de las nuevas
tecnologías y modificaciones a
las existentes (inventario)
-Monitoreo Eficiente de la
infraestructura
-Disponibilidad de la información
relacionada con las tecnologías
-Seguimiento oportuno de las
solicitudes de servicios
-Resolución de solicitudes de
manera rápida y eficiente
-Mantenimiento pro-activo a las
tecnologías administradas
Visibilidad por parte del cliente
de lo siguiente:
-Flujo y estado de solicitudes
-Estado de las Tecnologías
-Indicadores de desempeño de
las tecnologías
-Indicadores de desempeño
relacionados con la atención de
solicitudes y requerimientos
-Acuerdos de servicio
-Cumplimiento de indicadores
-Capacidad de respuesta para nuevas
instalaciones o solicitudes de servicios
-Asignación de especialistas y
niveles de escalación
-Encuestas de satisfacción de
servicios
-Recopilación de soluciones
para consulta
Logística Interna Operaciones Logística Externa
Mercadotecnía/Comercializació
n y Ventas
Servicio
La Gerencia ASARE cuenta con un 2 centros de computo que permite garantizar la operación de los equipos de computo, almacenamiento y comunicaciones, ya que estan
pensados para dar redundancia y un nivel de disponibilidad de servicios muy alto. Basado en altos estandarés de calidad.
Administración y
dirección
(Jefatura de la oficina)
(Oficina de enlace
administrativo)
Cadena de Valor Gerencia ASARE, CFE.
Actividades primarias
Actividades de apoyo o secundarias
M
A
R
G
E
N

(93)
El modelo de la cadena de valor resalta las actividades específicas del negocio
o de la organización en las que pueden aplicar mejor las estrategias competitivas,
entendiendo en este caso como estrategias competitivas la mejora de sus procesos,
y en las que es más probable que los sistemas de información tengan un impacto
estratégico. El modelo considera a la empresa como una serie de actividades
primarias y de apoyo o secundarias que agregan valor a los productos y servicios de
una empresa. Las actividades primarias están más relacionadas con la producción y
distribución de los productos y servicios de la empresa que crean valor para el
cliente. Las actividades primarias incluyen logística de entrada, operaciones,
logística de salida, ventas y marketing y servicio. Las actividades de apoyo
consisten en la infraestructura (administración y gerencia), recursos humanos,
tecnología y adquisiciones de la organización. El uso del modelo de la cadena de
valor de una empresa considera la comparación de sus procesos de negocios con los
de sus competidores o con otras empresas de industrias relacionadas y a identificar
las mejores prácticas de la industria. El benchmarking implica la comparación de la
eficiencia y efectividad de sus procesos de negocios contra estándares estrictos y
luego la medición del desempeño contra esos estándares.
En la figura 3 podemos observar en la línea inferior, las descripción de las
actividades primarias que se consideran sustantivas para el proceso y que tienen o
aportan más valor a proceso o servicio entregado por esta organización. De las
actividades que se describen de acuerdo al propósito de la organización, que es ser
una entidad de soporte, se destacan:
 Captación de Eficiente de Solicitudes de servicios y requerimientos de
nuestros clientes
 Amplio conocimiento relacionado con las nuevas tecnologías utilizadas
para brindar el servicio
 Control y registro de las nuevas tecnologías y modificaciones a las
existentes (inventario)
 Monitoreo Eficiente de la infraestructura
 Disponibilidad de la información relacionada con las tecnologías

(94)
 Seguimiento oportuno de las solicitudes de servicios
 Resolución de solicitudes de manera rápida y eficiente
 Mantenimiento pro-activo a las tecnologías administradas
 Visibilidad por parte del cliente de lo siguiente:
o Flujo y estado de solicitudes
o Estado de las Tecnologías
o Indicadores de desempeño de las tecnologías
o Indicadores de desempeño relacionados con la atención de
solicitudes y requerimientos
En resumen se puede decir que lo que genera más valor para el mismo es:
Llevar el control de todos los elementos de configuración de la infraestructura
TI con el adecuado nivel de detalle y gestionar dicha información a través de alguna
Base de Datos.
Monitorear todos los sucesos importantes que se produzcan para poder
anticiparse a los problemas, resolverlos o incluso prevenirlos.
Además de detectar y notificar los sucesos, clasificarlos y dimensionar su
impacto en el servicio. Y realizar la atención de los mismos manteniendo estrecha
comunicación con los clientes o usuarios del servicio
Tomando en cuenta esto y las definiciones de procesos que ITIL describe se
puede empatar con tres procesos básicos para ser candidatos a ser implementados,
ya que aportarían mucho a la cadena de valor del servicio que entrega esta parte de
la organización.
Estos procesos candidatos pueden ser:

(95)
 Gestión de la configuración (Gestión de componentes, inventarios y
activos)
 Gestión de eventos (Monitoreo)
 Gestión de incidentes
La propuesta inicial será entonces comenzar con la implementación de estos
procesos como punto de partida, y paulatinamente serán siendo implementados el
resto de los procesos, realizando siempre que se adopte un proceso más, un análisis
del avance en los niveles de madurez y sería deseable desde la primer revisión
incluir la percepción del cliente o usuario.

(96)
Para apoyar el diseño de los procesos, se eligió continuar con el uso de las
herramientas de BPM, en este caso se utilizará la Business Process Modeling
Notation o BPMN (en español Notación para el Modelado de Procesos de Negocio),
esta es una notación gráfica estandarizada que permite el modelado de procesos de
negocio, en un formato de flujo de trabajo (workflow).
El principal objetivo de BPMN es proporcionar una notación estándar que sea
fácilmente legible y entendible por parte de todos los involucrados e interesados del
negocio (stakeholders). En síntesis BPMN tiene la finalidad de servir como lenguaje
común para cerrar la brecha de comunicación que frecuentemente se presenta entre
el diseño de los procesos de negocio y su implementación.
El modelado en BPMN se realiza mediante diagramas muy simples con un
conjunto muy pequeño de elementos gráficos. Con esto se busca que para los
usuarios del negocio y los desarrolladores técnicos sea fácil entender el flujo y el
proceso.

(97)
2.3 Diseño de los procesos
Introducción a la Gestión de la configuración (Gestión de
componentes, inventarios y activos).
Se decide este proceso como el inicial debido a que se considera que es de
suma importancia conocer y controlar toda la infraestructura con la que se cuenta,
además la naturaleza de la oficina es principalmente administrar la infraestructura
de TI.
De acuerdo a ITIL el proceso de Configuration Management (Gestión de la
configuración) ofrece un modelo lógico de los configuration items CI (Elementos de
la configuración) que de manera conjunta conforman la infraestructura de servicios.
La Misión principal del Proceso de “Configuration Management” para los
Servicios de TI se define como sigue:
“Identificación, control, registro del estatus, administración de
relaciones y verificación de los componentes de la infraestructura de servicios
de TI”
El proceso de Configuration Management proporciona información vital a
todas y cada una de las disciplinas de ITIL, y así se ha convertido en una función
crítica. Algunos de los beneficios clave son:
 Mantener una imagen precisa de qué infraestructura soporta qué servicios
 Protección y difusión de los niveles de servicio mediante el registro detallado
de información sobre la disponibilidad y el desempeño de la infraestructura
 Ayudar a garantizar el cumplimiento de obligaciones legales
 Proporcionar información sobre la infraestructura que sirve de apoyo en la
planeación financiera y de gastos
 Asegurar la visibilidad de cambios de software

(98)
 Proporcionar información precisa sobre la infraestructura a los ciclos de
planeación de Continuity y Capacity
 Ayudar a Release Management a administrar el uso autorizado de software
 Proporcionar información clave sobre tendencias a los procesos de “Incident y
Problem Management”
La práctica de Configuration Management necesita tener o ser apalancada por
los siguientes componentes o ingredientes para una implementación exitosa en la
organización. Esto se debe hacer de una manera paulatina pero clara los elementos
que se muestran en seguida son claves:
 Un repositorio central (lógico) para toda la información de configuración,
conocido como Configuration Management Database (CMDB)
 Estándares para definir los Configuration Items (CIs)
 Estándares para describir las relaciones entre CIs
 Equipo de detección automática y población de CIs
 Participación temprana en la cadena de provisión de los servicios
 Soporte para la Definitive Software Library (DSL)
 Soporte para la Definitive Hardware Store (DHS)
 Prácticas integradas con Change y Release Management
 Interface común con la administración de activos y los procesos de
adquisición
En este primer acercamiento se tratará de cubrir la mayoría de los aspectos,
tomando en cuenta la disponibilidad de recursos actuales, las mejoras al proceso se
darán de forma paulatina con las revisiones subsecuentes.
Para la implementación se realizaron 2 trabajos principales, el primero es la
estandarización de la información, mediante un proceso que consiste en abstraer y
construir modelos o estructuras de representación (plantillas) para los diferentes
tipos de elementos de la infraestructura de servicios de TI, esto nos permitirá contar

(99)
con las especificaciones y modelos básicos para la posterior construcción de las
estructuras de datos y meta datos de una base de datos de configuraciones.
El segundo consistió en el diseño del proceso para manipular la información
estandarizada.
Estandarización de la información – Creación de CMDB
Este trabajo se realizó mediante la ejecución de un proyecto denominado:
“Desarrollo del Modelo Lógico para la creación de la CMDB para el Centro de
Operaciones ASARE-GDL de la CFE usando el modelo de referencia ITIL”
El objetivo de este proyecto consistió en trabajar mediante una serie de
talleres que incluían a especialistas de diferentes áreas de TI. Se utilizó la
metodología de ITIL y su proceso de administración de Configuraciones para
identificar y clasificar los componentes de la infraestructura de TI perteneciente al
centro de operaciones de ASARE-GDL, sus atributos y las asociaciones entre éstos,
y estos se aplicarán en el desarrollo práctico de los modelos de datos de una CMDB.
Al termino del proyecto, se buscaba contar con los modelos (plantilla) para
los tipos de componentes identificados, las cuales serán utilizados posteriormente
para registrar los datos estos componentes y generar el primer acercamiento a la
base de datos de configuraciones o CMDB.
Como resultado de este primer proceso se logró identificar y elaborar plantillas
para los siguientes elementos de TI:
 Equipos de cómputo
 Equipos de comunicaciones
 Equipos de Almacenamiento
 Equipos PDU
 Equipos de Aire acondicionado
 Equipos Seccionadores

(100)
 Equipo de sistema contra incendio
 Equipos Transformadores
 Equipo de energía in-interrumpible
Para ellos se obtuvo una clasificación mediante categorizaciones, se elaboró un
sistema de codificación para dar un identificador único a cada elemento.
Y por consiguiente las plantillas que definen los campos que describen
atributos de cada elemento. En el anexo 1 y 1-A, se muestra un ejemplo de dichas
plantillas, favor de referirse a la tabla de anexos en la sección de anexos a final del
documento.
En primera instancia, Las plantillas fueron diseñadas como hojas de Excel, ya
que no se cuenta con un sistema que permita almacenar estos datos, sin embargo
el diseño de las mismas fue pensado para que puedan ser traducidas en estructuras
de datos para una base de datos como tal.
Se dispuso que estas fueran concentradas en un repositorio único. Para ello
se designó un servidor de archivos que es accesible por toda la organización y se le
dio una estructura de directorios que permitiera una fácil navegación y permitiera
compartir esta información sin mayor desarrollo. A continuación en la figura se
muestra el contenido inicial de este repositorio que fungirá como la CMDB:

(101)
Figura 19 – Disposición de repositorio único para información de la infraestructura - CMDB

(102)
Diseño del proceso.
Este trabajo consistió en la elaboración del documento que describe el
proceso, métricas, ciclos de vida y procedimientos para la administración de dichos
componentes enunciados en dichas plantillas.
Este proceso se llevó a cabo de la misma manera, que la definición de las
plantillas, mediante talleres con personal especialista en diversas áreas de TI,
durante el desarrollo del mismo, se consideró como indispensable la capacitación
del personal involucrado en el conocimiento de las librerías de ITIL y el proceso de
configuraciones. El proceso está basado en la propuesta de ITIL a este respecto y
fue adaptado para las necesidades de la organización, dando como resultado el
documento que se enuncia a continuación9
.
Nota: El formato y distribución de los documentos mostrados a continuación
para este y los otros dos procesos, atienden a la estandarización de documentos
interna de la organización en cuestión, se hizo una adaptación para el presente
documento por cuestiones de conveniencia, también se han omitido algunas partes
que se consideran de orden confidencial para la empresa, por lo que su
representación es meramente para ejemplificar y puede diferir de documento
original.
9
Se incluyó un archivo anexo con el mapa de proceso – ver tabla de archivos anexos en la

(103)
Proceso de gestión de la configuración
Tabla de contenidos
1. Misión
2. Descripción y narrativa de las actividades del proceso y sus subprocesos
2.1 adquisición de nuevos elementos de configuración CIs
2.2 actualización de información de proveedores
2.3 registro de nuevos ci
2.4 actualización de información de elementos de configuración CIs
2.5 registro y actualización de información de contratos y licencias
3. Ámbito
4. Roles y responsabilidades
5. Indicadores del proceso KPIs
6. Propietario

(104)
1. Misión
La misión del proceso de gestión de la configuración es hacer que la información
relevante acerca de la infraestructura ESTE disponible para los demás procesos de
gestión de servicios de una manera precisa, completa y oportuna.
2. Descripción y narrativa del proceso y sus sub-procesos
Para ello se utilizará una serie de registros de información referente todos los
elementos de tecnología que son administrados por la entidad en particular, esto
son denominados: “elementos de la configuración” o “CI” por sus siglas en inglés
“Configuration ITEM”.
La información se colocará en un repositorio común denominado
“Configuration Management Data Base” o CMDB. La información que se almacena
de cada elemento de la configuración será la absolutamente indispensable que
describa a dicho elemento y aporte lo suficiente para su correcta administración así
como las relaciones que guarda con otros elementos. Esta información será descrita
a través de documentos o registros denominados plantillas.
Esta base de datos además contener registro de los elementos de
configuración, contendrá también en plantillas correspondientes, la información de
los proveedores de CI con los que se trabaja, los contratos de servicio o
mantenimiento, así como los acuerdos de licenciamiento u utilización de software en
caso de que aplique.
El proceso de gestión de la configuración consiste en cinco subprocesos:
El primer proceso se llama "Adquisición de nuevos elementos de configuración
(CI)”. Es utilizado para la incorporación de nuevos elementos de configuración a la
infraestructura desde el punto de vista de su compra.
El segundo proceso se llama "Actualización de información de proveedores”.
Se utilizará cuando se tiene la necesidad de registrar nuevos proveedores de CI o
cuando se tenga que actualizar los datos de contacto de los proveedores
previamente registrados en la CMDB.
El tercer proceso se nombra como "Registro de nuevos CI”. Este
procedimiento es utilizado cuando se ha adquirido un nuevo CI para registrar su
información por primera vez en la CMDB
El cuarto proceso se denomina "Actualización de información de CIs”. Se
utilizará cuando se actualicen los atributos y / o relaciones de los elementos de
configuración que ya estaban registrados previamente en la CMDB, debido a un
cambio, reconfiguración, actualización o reparación.

(105)
El quinto proceso se llama "Registro y actualización de información de
contratos y licencias”. Será utilizado se tenga la necesidad de registrar o actualizar
los contratos de servicio y mantenimiento relacionados con los elementos de
configuración registrados previamente en la CMDB.
La representación gráfica del proceso se proporciona en la siguiente, figura:

(106)
Figura 20 – Descripción de proceso de gestión de la configuración
Proceso de Gestión de la Configuración
OficinadeOperacióndeSolucionesRemota
Versión 2
¿Actualización de
información de
proveedores
requerida?
Subproceso de
actualización de
información de
proveedores
SI
¿Solicitud de
adquisición de nuevo
CI?
Subproceso de
Adquisición de nuevos
CI’s
¿Solicitud de
Registro de nuevo
CI?
NO NO ¿Actualización de
datos de CI´s
existentes?
¿Registros o
actualización de
información de
contratos?
Subproceso de Registro
de nuevos CI’s
Subproceso de
actualización de
información de CI’s
Subproceso de Registro
y actualización de
información de
contratos y licencias
Notificación de actualización
de registros de configuración a
gestión de cambios
NO
NO NO
SI SI SI SI
Se recibe Solicitud
de cambio
en la configuración
del proceso de
Gestión de cambios
Revisar información
de la solicitud
Continuar
revisando
información de
la solicitud
Continuar
revisando
información de
la solicitud
Continuar
revisando
información de
la solicitud
Continuar
revisando
información de
la solicitud
Notificación de registro de
solicitud errónea a gestión de
cambios
Enviar
información de
solicitud
Enviar
información de
solicitud
Enviar
información de
solicitud
Enviar
información de
solicitud
Enviar
información de
solicitud

(107)
2.1 Adquisición de nuevos elementos de configuración (CI)
Las tareas para adquisición de nuevos CI se dispara a partir de una solicitud
de los coordinadores de cambio (Change Managers) cuando nuevos CIs deben ser
ordenados o adquiridos.
Después de que esta tarea se ha asignado a un administrador de
configuración, él / ella revisarán los detalles de la solicitud. Y comenzará a elaborar
una requisición de pedido, donde detallará las características de CI a adquirir,
además de elaborar una orden de compra de acuerdo al procedimiento establecido
para ello.
Se comprobará si los datos de contacto de los posibles que deben ser
invitados a presentar cotizaciones, están actualizados a la fecha. Si un proveedor no
se ha registrado, o si sus datos de contacto ya no son actuales a la fecha, se llevará
a cabo el proceso de registro o actualización descrito en el proceso de actualización
de información de proveedores.
Después de haber asegurado que los datos de contacto del o los
proveedor(es), se llevará a cabo la solicitud de cotizaciones de acuerdo al
documento de requisición de pedido. Una vez recabadas las cotizaciones, deberá ser
presentada la solicitud de aprobación de compra al área de compras.
El personal de compras corroborará las cotizaciones necesarias de los
proveedores o en su caso solicitará nuevas. Completará la solicitud y solicitará la
aprobación para la solicitud de compra. De acuerdo a los procesos internos de
compra.
Esta deberá ser revisada por el personal con facultades para aprobar dicha
adquisición quien en su caso aprobará o rechazará la solicitud de pedido. Si es
aprobada, el personal de compras ordena el CI (s) solicitado. Si la solicitud de
pedido se rechazó, se realiza la notificación de negativa a la solicitud hecha por el
proceso de administración de cambios.
El subproceso de adquisición de nuevos elementos de configuración (CIs) se
presenta en la figura siguiente:

(108)
Figura 21 – Descripción de subproceso de adquisición de nuevos elementos de configuración CIs
Subproceso de adquisición de nuevos CI
Administradordelaconfiguración
Jefedeoficinaosupervisores
ÁreadecomprasAprobaciones
Versión 2
Revisar que la
información y
actualizar tarea
¿Se require la
adquisición de un
nuevo(s) CI(s)?
Elaborar
requisición de
pedido con bases
técnicas, y orden
de compra en
base a
procedimiento
SI Verificar
información del
proveedor
¿El proveedor ya esta
registrado y sus datos
son actuales?
NO
Solicitar
cotizaciones
Obtener
cotización y
detalles de la
compra
Solicitar
aprobación de la
compra
Completar
requisición de
compra y obtener
firmas de
aprobación
¿Se aprueba la
requisición de
compra?
Colocar
requisición de
compra, esperar
la compra
SI
SI
NO
Firmar aprobación
de compra
NO
Enviar Solicitud
de información
De nuevo
proveedor a
Gestión de
Cambios
Enviar a
proceso de
Administración
De cambios,
negativa de
adquisición
Enviar a
proceso de
Administración
De cambios,
aviso de
próxima de
Adquisición.
Se recibe nueva
solicitud de Proceso
de Gestión de
Cambios
Enviar aviso de
solicitud errónea
a Gestión de
Cambios

(109)
2.2 Actualización de Información de proveedores
Los administradores de configuración son responsables de registrar y
actualizar la información de las organizaciones que suministran los elementos de
configuración y / o el apoyo a la organización en cuanto a servicios.
Un administrador de configuración realiza las tareas de mantenimiento de la
información de proveedores, según sea necesario; cuando va a llenar las solicitudes
de compra, antes de registrar o actualizar contratos, o cuando se recibe
directamente información de contacto de un proveedor existente o ya registrado en
la CMDB.
Si una organización o proveedor no está registrado, el administrador de
configuración lo agrega. Si la organización del proveedor ya existe en la CMDB, el
administrador de configuración actualiza sus datos de contacto, según sea
necesario. Esto se hace de acuerdo con las pautas de utilización de campos de las
plantillas de información de proveedores diseñadas para ello.
El subproceso de actualización de información de proveedores se presenta en la
figura siguiente:

(110)
Figura 22 – Descripción de subproceso de actualización de Información de proveedores
Subproceso de actualización de información de proveedores
Supervisoresopersonaldeoperación
Versión 2
¿El proveedor esta
ya registrado?
Registrar la
información
del nuevo
proveedor
En CMDB
Actualizar
información
del nuevo
proveedor
en CMDB
¿Se registrará o
actualizará
información sobre
contrato con este
proveedor?
NO
SI
NO
SI
Enviar a proceso
de Administración
De cambios,
Solicitud de datos
de contrato
Enviar a proceso de
Administración de
cambios,
notificación de
información
actualizada
Se recibe nueva
de Gestión de
Cambios
Revisar la
información y
actualizar
tarea

(111)
2.3 Registro de nuevos CI
El subproceso de administración de cambios es comúnmente quien solicita el
registro de un nuevo CI.
El registro de uno o más elementos de configuración se realiza ya sea que
haya presentado una solicitud formal de compra o no, por ejemplo, en el caso de
software desarrollado de forma interna o equipo en préstamo o traspasado de otra
área. Para ellos primero el administrador de configuración deberá verificar que el
CI(s) haya sido entregado, asegurándose de que las licencias de hardware, software
y / o software adecuados se han recibido e instalado, que no faltan elementos, y
que el CI (s) no están dañados y estén operando de forma correcta. Si la entrega no
es del todo satisfactoria, el administrador de configuración informa al proveedor y
posteriormente informa al coordinador de cambios de la demora y se marca dicho
CI como pendiente de registro hasta que no se reciba de forma correcta.
Para el caso de los CI (s) que se ordenan mediante una orden de compra y
que se han recibido en buenas condiciones, el administrador de configuración
informa al área de compras, marca el elemento como entregado y posteriormente
realiza el registro del nuevo CI en la CMDB de acuerdo a la plantilla dispuesta para
ello y al procedimiento correspondiente. Si una solicitud de pedido formal no se
presentó pero el CI(s) se ha recibido en buenas condiciones, el administrador de
configuración también realiza el registro del nuevo CI en la CMDB de acuerdo a la
plantilla dispuesta para ello y al procedimiento correspondiente.
El administrador de configuración se asegurará que los atributos necesarios
(por ejemplo, el número de serie) se especifican para cada nuevo CI y si está
relacionado con otros registros de CI, servicios y usuarios, según sea necesario.
Todo esto se hace en conformidad con las directrices de utilización de campos para
las plantillas que están disponibles para registro en la CMDB.
El subproceso de registro de CIs se presenta en la figura siguiente:

(112)
Figura 23 – Descripción de subproceso de registro de nuevos CI
Subproceso de registro de nuevos CI
Áreadecompras
Versión 2
¿Se solicita el
registro de un
nuevo CI?
Verificar si el CI
fue entregado
¿El CI fue instalado
y esta operando de
manera correcta?
¿El CI fue adquirido
por una orden de
compra?
Informar al
área de
compras que
el CI fue
entregado y
esta funcional
Actualizar
orden de
compra,
marcando
partida
entregada
Asignar ID de CI,
etiquetar y registrar
información de CI
conforme a plantilla y
procedimiento
Marcar CI como no
entregado, y
esperar a que este
quede operando
Informar al
proveedor de la
situación para que
tome las acciones
necesarias y quede
operando
SI
SI
SI
NO
NO
Enviar a proceso de
Administración
De cambios, aviso
informando de alta
Del nuevo CI
Revisar la
información y
actualizar tarea
Se recibe nueva
de Gestión de
Cambios
Enviar aviso de
solicitud errónea
a Gestión de
Cambios
NO
Revisar la
información de
adquisición

(113)
2.4 Actualización de información de elementos de configuración CIs
Cuando el administrador de configuración se ocupa de una tarea que solicita
la actualización de atributos y / o relaciones de CI, él / ella verifica la configuración
real de la infraestructura para confirmar que las modificaciones de CMDB solicitados
son realmente necesarias para mantener la actualizada.
Si resulta que la CMDB debe ser actualizada, el administrador de
configuración realiza la actualización de los atributos de CI y / o relaciones
necesarias. Esto se hace de acuerdo con las directrices de utilización de campos
para las plantillas que están disponibles para registro en la CMDB y al procedimiento
correspondiente.
Después de haber actualizado la CMDB, o si resulta que la CMDB no necesitan
ser actualizados, el administrador de configuración pasa a verificar si es necesario
también realizar una actualización de información de contratos y licencias.
El subproceso de actualización de información de CI’S se presenta en la figura
siguiente:

(114)
Figura 24 – Descripción de subproceso de actualización de información de CI
Subproceso de actualización de información de CI
Versión 2
¿Se solicita el
actualización de
información de un
CI registrado?
Revisar
configuración actual
del elemento de
configuración (CI)
¿La información del CI
realmente necesita
actualizarse, existe algún
cambio respecto de lo
registrado?
Realizar los cambios a la
información del CI y/o sus
relaciones conforme a
procedimiento
SI
SI
NO
NO
Enviar aviso a proceso
de Administración
De cambios, informando
de la modificación del CI
o NO modificación del CI
Revisar la
información y
actualizar tarea
Se recibe nueva
de Gestión de
Cambios
Enviar aviso de
solicitud errónea
a Gestión de
Cambios

(115)
2.5 Registro y actualización de información de contratos y licencias
Antes de realizar un nuevo registro o la actualización de un contrato o
certificado de licencia existente, el administrador de configuración primero se
asegura de que existen los datos de contacto de su proveedor. Si la organización del
proveedor del certificado de licencia o contrato ya se ha registrado, el administrador
de configuración verifica los datos de contacto registrados, para ver si todavía están
actualizados a la fecha. Si el proveedor no se ha registrado, o si sus datos de
contacto ya no son actuales, el administrador de configuración garantiza primero
que la información de proveedores se ha registrado o actualizado mediante el
proceso de actualización de información de proveedores.
Después de haber asegurado que los datos de contacto del proveedor están
registrados y actualizados a la fecha, el administrador de configuración registra o
actualiza el contrato o certificado de licencia de acuerdo con las directrices de
utilización de campos para las plantillas que están disponibles para registro en la
CMDB y al procedimiento correspondiente.
Después de que la información del contrato o certificado de licencia ha sido
actualizado y si la tarea no solicita el registro o actualización de más contratos o
certificados de licencia, el administrador de configuración cierra la tarea.
El subproceso de registro y actualización de información de contratos y
licencias se presenta en la figura siguiente:

(116)
Figura 25 – Descripción de subproceso de registro y actualización de información de contratos y licencias
Subproceso de registro y actualización de información de contratos y licencias
JefedeoficinaoSupervisores
Versión 2
¿Se requiere registrar o
actualizar información de
un contrato o certificado de
licencias?
Revisar detalles de
la información
proveedor del
contrato
¿El proveedor ya esta
registrado y sus datos
son actuales?
¿Se requiere registrar
información de un nuevo
contrato o certificado de
licencias?
Actualizar información
referente al contrato o
certificado de licencias
de acuerdo a
procedimiento
Registrar nuevo
contrato o certificado
de licencias
Completar solicitud, Y enviar
aviso a proceso de Gestión
De cambios, informando de la
Modificación / Alta de la
Información del Contrato o
licencia.
SI
SI
NO
SINO
NO
Enviar solicitud de
información de
nuevo proveedor,
proceso
De Gestión de
cambios
Revisar la
información y
actualizar tarea
Se recibe nueva
de Gestión de
Cambios
Enviar aviso de
solicitud errónea
a Gestión de
Cambios
Revisar detalles de
la información del
contrato

(117)
3. Alcance
El alcance del proceso de gestión de la configuración se limita a los tipos de
CI para los que una solicitud ha sido puesta a disposición de la aplicación de un
servicio (esta en producción), e incluye la información de compra, contratos y
proveedores que se relaciona con este tipo de entidades.
4. Roles y Responsabilidades
La siguiente tabla muestra los diferentes roles que intervienen en el proceso
de gestión de la configuración, junto con sus respectivas responsabilidades.
Rol Responsabilidad
Administrador de configuración
Jefe de Oficina
Supervisor
Personal de Operación
(Operadores)
 Somete solicitudes de compra
después de que esto ha sido
solicitado por la Gestión del
Cambio.
 Informa al área de compras
después de que los CI ordenados se
han entregado en buenas
condiciones.
 Se asegura de que los CI, que caen
bajo la responsabilidad del grupo
administrador de configuraciones,
se etiquetan después de que hayan
sido entregados.
 Asegura que la información de los
CI, para los cuales el grupo
administrador de configuraciones es
responsable, se mantiene
actualizada.
 Mantiene actualizada la información
de las organizaciones externas o de
apoyo, relacionada con los CIs para
los cuales el grupo administrador de
configuraciones es responsable.
 Registra y actualiza de los contratos
y certificados de licencia para CIs
para los cuales el grupo
responsable.
 Mantiene los vínculos de los CIs
para los cuales el grupo
responsable. Estos son los vínculos
entre la CI y otros CI, sus

(118)
proveedores, sus contratos, y las
infraestructuras de servicios de las
que forman parte.
Área de compras  Obtiene cotizaciones de los
proveedores de los CIs que se ha
solicitado para adquisición.
 Envía las solicitudes de aprobación
de compra CIs después de que las
cotizaciones de los proveedores de
estos CIs haya sido recolectadas.
 Ingresa las órdenes de compra para
su adquisición una vez que han sido
aprobada.
 Actualizar las órdenes de comprar
después de administradores de
configuración han confirmado la
recepción de los CI para las que se
presentaron órdenes de compra.
Personal para aprobaciones
Niveles directivos
 Decide si aprobar o rechazar las
solicitudes para la adquisición de
nuevos elementos de configuración
Tabla 10 – Roles y responsabilidades del proceso de gestión de la configuración
5. KPIs (Key Performance Indicators)
La tabla siguiente muestra los indicadores clave de rendimiento (KPI) que han
sido definidos para el seguimiento del éxito del proceso de gestión de la
configuración.
KPI Definición Frecuencia Unidad
Tiempo para
actualizar la
CMDB.
El tiempo promedio que
tarda la tarea de
actualización de la CMDB
después de que una tarea
de actualización ha sido
"Asignada" ya hasta que se
completa o “Cierra”
Mensual No. de horas
de trabajo

(119)
% De CI
Registrados
El porcentaje de registros
de CI de hardware
existentes, dentro de la
CMDB, el indicador
deseado después de la
primer versión de este
proceso será entre el 98%
y 100% de CI Registrados
Mensual % de CI
registrados
del Total de
CI de
Hardware
existentes.
Tabla 11 – Descripción KPIs del proceso de gestión de la configuración
6. Propietario
El propietario del proceso de gestión de la configuración es el CAB de gestión
de servicios.
Este CAB es responsable de revisar y, posteriormente, aprobar o rechazar, las
solicitudes de mejora del proceso de gestión de la configuración y su funcionalidad
de apoyo en la aplicación de gestión de servicios.

(120)
Introducción a la Gestión de Eventos (El monitoreo de la
infraestructura).
Visión general
Una vez que un servicio está operando y son controlados todos sus
componentes o elementos de configuración (CIs) a través de los registros en la
CMDB, es necesario monitorear todos los sucesos importantes que se produzcan
para poder anticiparse a los problemas, resolverlos o incluso prevenirlos. Esta
función representa una tarea en sí misma y por tanto constituye un proceso
independiente: la Gestión de Eventos.
A efectos de la operación del servicio, se denomina evento a todo suceso
detectable que tiene importancia para la estructura de la organización TI, para la
prestación de un servicio o para la evaluación del mismo. Ejemplos típicos de
eventos son las notificaciones creadas por los servicios, los elementos de
configuración o las herramientas de monitoreo y control.
Un aspecto clave en la Gestión de Eventos es, como resulta evidente, un buen
monitoreo y efectivos sistemas de control. Encontramos dos tipos:
 Herramientas de monitoreo activas. Comprueban los CIs uno a uno para
verificar su estado y disponibilidad. Si detecta excepciones, la herramienta de
monitoreo genera una alerta y la envía al equipo o mecanismo de control
asignado.
 Herramientas de monitoreo pasiva. Detectan y correlacionan alertas
operacionales generadas por los propios CIs.
Cabe mencionar que estas pueden o no ser herramientas automatizadas, es
deseable que así sean ya que permiten el monitoreo de más elementos de

(121)
configuración en poco tiempo o en tiempo real. Las herramientas manuales son
aceptadas, pero tendrán que tender a ser automatizadas.
Los eventos no tienen por qué ser siempre negativos o extraordinarios,
también pueden ser rutinarios. De hecho, podemos distinguir varios tipos de
eventos dependiendo de su impacto:
 Eventos que indican que el servicio está operando con normalidad.
 Eventos que indican una excepción.
 Eventos que indican una operación inusual pero no excepcional, y que
requieren un monitoreo exhaustivo.
La Gestión de Eventos, además de detectar y notificar los sucesos, se encarga
de clasificarlos y dimensionar su impacto en el servicio. Llegado el caso, se ocupa
también de documentar el evento y derivarlo al proceso correspondiente para que
tome medidas:
 A la Gestión de Incidencias, en caso de que el evento suponga una
interrupción no planificada del servicio o fallos en uno o más CIs.
 A la Gestión de Problemas, si una incidencia se repite a menudo y no se
conoce la causa que la provoca.
Y también envía a la Gestión de Cambios, a través de la Mejora Continua del
Servicio, ya que puede generar nuevas solicitudes de cambio basadas en la
correlación de eventos.
Introducción y Objetivos
El principal objetivo de la Gestión de Eventos, en su función de monitoreo de
todos los sucesos importantes, consiste en detectar y escalar condiciones de
excepción para así contribuir a una operación normal del servicio:

(122)
 Proporcionando puntos de entrada para varios procesos de la fase de
Operación (p. ej. Gestión de Incidencias).
 Posibilitando la comparación entre el rendimiento real del servicio con los
estándares de diseño y los SLAs.
 Contribuyendo a la Mejora Continua del Servicio mediante informes de
mejora.
Algunas de las ventajas que una correcta Gestión de Eventos aporta a la
organización TI son:
 Ayuda a la detección temprana de incidentes, llegando incluso a evitar que
éstos se manifiesten a los usuarios.
 Además, la coordinación directa con otros procesos hace posible que éstos
reaccionen con mayor rapidez, resultando en una mayor eficiencia de toda la
organización TI.
 Posibilita el monitoreo automatizado de determinadas actividades. Es más
barato que un monitoreo en tiempo real y disminuye considerablemente el
periodo de inactividad del servicio que media entre la aparición del incidente
y su resolución definitiva.
 Proporciona la base para las operaciones automatizadas, que incrementan la
eficiencia y descargan de trabajo a los recursos humanos que, así, pueden
ser empleados en otras tareas como diseñar nuevas funcionalidades, etc.
Entre los principales desafíos que pueden obstaculizar la labor de la Gestión
de Eventos encontramos:
 Dificultades en la obtención de fondos para contratar las herramientas
necesarias y el esfuerzo necesario para configurarlas y explotar sus
beneficios.

(123)
 Los niveles de filtrado no son adecuados, bien por exceso (se gestionan
eventos sin impacto real en el servicio) o por defecto (algunos eventos de
importancia no se detectan hasta que es demasiado tarde)
 No existe suficiente compromiso con la Gestión de Eventos en otros procesos,
ocasionando retrasos en la repuesta a los eventos.
 Adquirir las habilidades necesarias exige tiempo y dinero.
Al igual que el proceso de Gestión de la Configuración el diseño y la
implementación de este proceso, se tratará de apegar lo más posible al proceso que
describe ITIL, es posible que en este primer esbozo no se cubran todos los
aspectos, pero estos podrán corregirse paulatinamente con las revisiones del mismo
y la evaluaciones de madurez que se elaboren.
A continuación se muestra el diseño de este proceso para esta primera
revisión10
:
10

(124)
Proceso de Gestión de Eventos (Monitoreo)
Tabla de contenidos
1. Objetivo del proceso
2. Descripción del proceso
3. Descripción y narrativa de las actividades del proceso y sus
subprocesos
3.1 manejo de eventos
3.2 evaluación de eventos
3.3 evaluación del proceso de gestión de eventos
4. Descripción de roles
5. Indicadores del proceso (KPIs)
6. Propietario
7. Reglas del proceso
8. Documentación soporte al proceso

(125)
Gestión de Eventos (Monitoreo)
1. Objetivo del proceso
La gestión de eventos tiene como propósito o misión el manejo adecuado
de los eventos relacionados con la infraestructura de computo, obtenidos
mediante el monitoreo constante y consiste en registrar y atender estos eventos
lo más rápido posible, siguiendo el propio procedimiento de control y manejo de
eventos.
2. Descripción del proceso
El proceso de gestión de eventos consiste en tres subprocesos:
El primer subproceso se denomina propiamente "Manejo de eventos". Es
utilizado por los operadores cuando se relacionan con los eventos generados por
las aplicaciones o sistemas de monitoreo (manuales o automatizados) de la
infraestructura.
El segundo subproceso se llama "Evaluación de Eventos". Este
procedimiento es utilizado por el responsable de operación para identificar
oportunidades de mejora de la eficiencia con que se manejan los eventos.
El tercer y último subproceso se denomina "Evaluación del proceso de
gestión de eventos". El gerente de operaciones sigue este procedimiento para
identificar las debilidades en la supervisión de los servicios mediante la revisión
periódica de la información acerca de las interrupciones del servicio que afectan
a varios usuarios.

(126)
Figura 26 – Descripción del proceso de Gestión de Eventos (Monitoreo) - General
Proceso de Gestión de Eventos
OperadoresResponsabledeoperaciones
Versión 2
¿El evento se trata
de una alerta de
disminución de
capacidad?
SI
NO
Se registra evento
mediante un sistema
de monitoreo
automático
o manual
Manejo de Eventos
Proceso de
Gestión de la
Capacidad
Proceso de
Gestión de
Incidentes
Inicia revisión
periódica de
eventos
Evaluación de
eventos
Se recibe sugerencia
Mejora o sugerencia
de monitoreo
automático
Inicia Evaluación
periódica de
La Gestión de
eventos
Evaluación del
proceso de Gestión
de eventos
Cerrar evento
Proceso de
Gestión de
Incidentes
Enviar
solicitud de
adecuación a
Gestión de
incidentes
Se recibe
aviso de
atención de
incidente
completo
Periodo semanal
Periodo mensuall

(127)
3. Descripción de las actividades de los procesos
3.1 Manejo de eventos
Después de que se registra un nuevo evento emanado de los sistemas de
monitoreo, el operador revisa su información para determinar qué elementos de
configuración (CI) han fallado o están a punto de fallar, y procede a averiguar la
causa aparente del evento.
A continuación, el operador deberá revisar los otros eventos generados
recientemente para asegurar que el evento no se ha repetido o bien se agravo
derivado de un estado anterior (de acuerdo a los umbrales definidos). Además,
el operador verifica si el evento es el resultado de un cambio planificado o un
evento planificado.
Si el evento representa la primera advertencia de una inminente
disminución de la capacidad (por ejemplo, debido a que un umbral de capacidad
se ha sobrepasado) el operador registrará una nueva solicitud de incidente para
evitar este inminente problema. El operador nombrará el tipo de servicio o
incidente como "Evento Infraestructura" y se asegurará de que el servicio
dependiente del CI y como el propio CI está vinculado a la solicitud de incidente.
El operador se asegurará de que el incidente es canalizado al administrador de
la capacidad de la infraestructura de servicios con los que el CI está vinculado.
Si el evento representa la primera notificación de una interrupción del
servicio no planificado o degradación, el operador registrará una nueva solicitud
de incidente nombrando el tipo de servicio o incidente como "Restauración
Infraestructura" para ello. El asegurará de que el servicio dependiente del CI
como el propio CI está vinculado a la solicitud del incidente. Si el operador es
capaz de resolver este incidente o falla (en términos de competencias, derechos
de acceso, procedimientos y las restricciones de tiempo), él / ella resuelven y
cierran el incidente. Si no es así, el operador se asegura de que la solicitud del
incidente se asigné al grupo apropiado. El operador cierra el evento después de
que se haya resuelto, así como cerrará la solicitud del incidente que se ha
registrado para ello. Cerrando el evento se asegura de que se elimina de la lista
de eventos abiertos.
El operador deberá cerrar el evento si no fuera la primera vez que se ha
generado (es decir, cuando una solicitud de incidente ya había sido registrada
para este), o si el evento representa una degradación del servicio o un corte que
se había previsto.

(128)
Figura 27 – Descripción de Subproceso de manejo de eventos
Subproceso de Manejo de Eventos
Operador
Versión 2
Revisar
información del
evento
Co-relacionar
evento con CI y
Servicio
¿Se trata de la primer
alerta de un evento de
disminución de
capacidad?
Registrar una solicitud
de incidente, conforme
a procedimiento
Asignar la solicitud
de incidente a
Gestión de la
Capacidad
¿Se trata de la primer
alerta de un evento de
falla no planeada o
degradación del
servicio?
Cerrar evento,
comentando el detalle.
Registrar una
solicitud de
incidente, conforme
a procedimiento
¿El operador es capaz
de resolver el
incidente?
Asignar solicitud
de incidente al
grupo apropiado
Resolver el
incidente
Cerrar la solicitud
de incidente
conforme a
procedimiento
SI
NO
SI
SI
NO
Se registra evento
mediante un sistema
de monitoreo
automático
o manual
NO
Proceso de Gestión de
Incidentes
Capacidad
Revisar naturaleza
del evento para
clasificarlo
Revisar detalles
del evento para
medir impacto
Aviso de
Solucion de
incidente
Aviso de
Solucion de
incidente

(129)
3.2 Evaluación de eventos
El responsable de operaciones revisará periódicamente todos los eventos
que se han manejado por los operadores. El responsable considerará las
sugerencias hechas por los operadores y especialistas para la mejora de la
manera en que los servicios y la infraestructura están siendo monitoreados. El
responsable de operaciones hará esto con el fin de identificar:
 Supervisión de las tareas que generan eventos innecesarios,
 Falta o reglas de correlación de eventos automatizados ineficaces y
 Falta o insuficiencia de las instrucciones o procedimientos para el manejo
de eventos por los operadores.
Cuando el responsable de operaciones ha identificado una oportunidad de
mejora, registrará un incidente y explicará lo que debe ser cambiado. Después
de haber completado el incidente, el responsable de operaciones se asegurará
que se le asigna al grupo que se encargará de la aplicación de la mejora
solicitada.

(130)
Figura 28 – Descripción de Subproceso de evaluación de eventos
Subproceso de evaluación de eventos
ResponsabledeOperación
Versión 2
Se realiza revisión
de eventos
atendidos o
manejados
Se examina el
primer evento no
revisado
¿Se debió haber
generado el evento?
¿Debió el monitoreo
automático haber
prevenido el evento?
¿El monitoreo esta
disponible y es
adecuado para el
monitoreo del evento?
Se solicita ajuste
en el trabajo de
monitoreo
Se solicita ajuste a
las reglas y
parámetros de
monitoreo
Solicitar mejora en
el proceso de
monitoreo para
incluir el evento
Asignar solicitud de
incidente al grupo
apropiado y continuar con
revisión de incidentes
SI NO
NO SI NO
Iniciar revisión
periódica de
eventos
Se recibe sugerencia
Mejora o sugerencia
de monitoreo
automático
SI
¿Todavía hay registros
a revisar?
SI Revisar
información del
evento
Continuar
Revisando
información del
evento
Continuar
Revisando
información del
evento
Se examina el
siguiente evento
no revisado
Finalizar revisión
periódica de
eventos
NO
Periodo semanal

(131)
3.3 Evaluación del proceso de gestión de eventos
El responsable de operaciones periódicamente revisa todas las solicitudes de
incidentes de alto impacto (es decir, todas las interrupciones del servicio para varios
usuarios afectados). Para cada una de estas solicitudes de incidentes, el
responsable de operaciones determina primero si un evento genero una notificación
al usuario de los servicios que se vieron interrumpidos.
Si se genera un evento, el responsable de operaciones descubre si el operador
(es) siguió el manejo de eventos correctamente. Si este no es el caso, el
responsable de operaciones recopila la información para su revisión con los
operadores.
Si un evento no fue generado aun cuando existió la interrupción de un servicio,
esto puede ser correcto (por ejemplo, porque se ha decidido que es demasiado caro
para controlar automáticamente la infraestructura de servicios que se vio afectada o
no se ha incluido en ningún sistema de monitoreo, manual o automático. El
responsable de operaciones posteriormente registrará una solicitud de incidente
para solicitar la inclusión de ese elemento a alguno de los sistemas de monitoreo
existentes.
Después de completar el examen de una solicitud de incidente de alto impacto,
el responsable de operaciones revisa la siguiente hasta que todas las solicitudes de
incidentes de alto impacto que se resolvieron durante el periodo de revisión pasado
hayan sido revisadas.

(132)
Figura 29 – Descripción de Subproceso de evaluación del proceso de gestión de eventos
Subproceso de evaluación del proceso de gestión de eventos
ResponsabledeOperación
Versión 2
Se realiza revisión
de incidentes de
alto impacto
Se examina el
primer evento no
revisado
¿Se registro de
manera oportuna el
evento?
¿El operador siguió las
instrucciones para
manejo de eventos?
¿Se debió registrar el
evento?
Se discutirá con el
operador la falla al seguir
las instrucciones para el
manejo de eventos
¿Fue el evento omitido
por el monitoreo
automático?
Se solicita el ajuste
de las reglas de
monitoreo
Se solicita la
inclusión del evento
en el monitoreo
Asignar solicitud de
incidente al grupo
apropiado y continuar con
revisión de incidentes
SI
NO
NO
NO
SI
SI
NO
SI
Iniciar Evaluación
periódica de
La Gestión de
eventos
¿Todavía hay registros
a revisar?
Revisar
información del
evento
Finalizar revisión
periódica de
eventos
SI
Continuar revisando
detalles de
información del
evento
Se examina el
siguiente evento
no revisado
Continuar revisando
detalles del evento
no registrado
Revisar las
características y
circunstancias del
evento no registrado
NO
Periodo mensuall

(133)
4. Descripción de roles
Rol Responsabilidad
Responsable de
operaciones
 Se asegura de que cada nuevo caso se
cierra de una manera eficiente y
consistente, según lo especificado por el
procedimiento de gestión de eventos.
 revisa todos los eventos cerrados para
identificar oportunidades de mejora de la
eficiencia con que se manejan los eventos.
 revisa todas las interrupciones del servicio
que varios usuarios afectados para
comprobar si la funcionalidad de
monitorización automatizada de la red y
las aplicaciones de gestión del sistema está
funcionando correctamente, y también
para asegurarse de que las tareas de
manejo de eventos se llevan a cabo
correctamente. Esto se hace para asegurar
que el tiempo de inactividad se minimiza
cuando se produce un corte de luz.
Operador  Revisa todos los nuevos eventos.
 Relaciona cada nuevo caso con otros
eventos y la información sobre los cambios
y eventos planificados.
 Registra una solicitud de incidente para
cada evento que representa la primera
advertencia de una inminente escasez de
capacidad y asigna la solicitud de incidente
al administrador de la capacidad
responsable.
 Registra una solicitud incidente para cada
evento que representa la primera
notificación de una degradación del
servicio no planificado o un corte y se
asegura de que la información de petición
incidente es completa y significativa.
 Asigna las solicitudes de incidentes de
degradaciones de servicio no planificados o
interrupciones a otro grupo cuando así se
especifique en las instrucciones de manejo
de eventos o si las instrucciones de
manejo de eventos aún no están
disponibles para el tipo de evento para el
cual las solicitudes de incidentes se
registró.
 Resuelve las solicitudes de incidentes de

(134)
Rol Responsabilidad
degradaciones de servicio no planificadas o
cortes cuando ello responda las
instrucciones de manejo de eventos.
Tabla 12 – Descripción de roles y responsabilidades del proceso de gestión de eventos
5. Indicadores del proceso (KPIs)
KPI Definición Frecuenci
a
Unidade
s
Tiempo para
cerrar
eventos
El tiempo promedio que le toma a
un evento para conseguir que se
genere de estar cerrado.
Mensual # de
horas
No. de
eventos
solucionados
por operador
El número de peticiones de
incidentes que fueron tanto
registrado y resuelto por un
operador, dividido por el número
total de peticiones de incidentes
registrados por los operadores.
Mensual %
Eventos no
cerrados
El número de eventos que aún no
se han cerrado.
Diario # de
eventos
% De CI
Registrados
que son
monitoreado
s
El porcentaje de CI de hardware
registrados dentro de la CMDB,
que están siendo monitoreados, el
indicador deseado después de la
primer versión de este proceso
será entre el 98% y 100% de CI
Monitoreados
Mensual % No.
de CI
Registra
dos
Tabla 13 – Descripción KPIs del proceso de gestión de eventos
6. Propietario
El propietario del proceso de gestión de la configuración es el CAB de gestión
de servicios.
solicitudes de mejora del proceso de gestión de la configuración y su funcionalidad
de apoyo en la aplicación de gestión de servicios.

(135)
7. Reglas del proceso
Deberá existir un acuerdo previo con los usuarios de este servicio, donde se
definan las variables y método de monitoreo, así como los umbrales de cada
variables y se documentarán los casos que se consideran como un evento anormal.
8. Documentación soporte al proceso
Anexo A - Acuerdo de servicio
Anexo B - Tabla con umbrales y valores

(136)
Para dar soporte a este proceso y para la implementación del mismo, se
llevaron a cabo una serie de talleres, donde se involucró al personal técnico
relacionado con los elementos de configuración y los servicios.
El objetivo era establecer cómo funcionaría este mecanismo y acordar los
parámetros más adecuados para el monitoreo y la gestión de los eventos
relacionados con estos.
Por este motivo fue necesario complementar el diseño del proceso con el
diseño y elaboración de matrices de condiciones consideradas como de operación
normal y sus umbrales de alerta y excepción. Con los cuales se puede dar marcha
hacia adelante al proceso de gestión de los eventos relacionados con la
infraestructura.
En el anexo 2 y 2-A se ejemplifican algunos de estas matrices elaboradas en
hojas de Excel, favor de referirse a la tabla de anexos en la sección de anexos a
final del documento.

(137)
Introducción a la Gestión de Incidencias
Visión general
Cuando se tiene ya la forma de mantener la información de la infraestructura
con la que se cuenta para entregar servicios de TI, actualizada y existe el método
para poder monitorear como está trabajando y se tiene la visibilidad de todo lo que
le ocurre, es decir, su comportamiento, funcionamiento normal y sobre todo el
posible comportamiento anormal, es necesario contar con un proceso que permita
que todo comportamiento de este tipo (anormal) pueda ser tratado de tal manera
que pueda ser corregido en el menor tiempo posible, pensando en que este es parte
de un servicio que se entrega y que se verá afectado de una manera u otra.
La Gestión de Incidencias tiene como objetivo resolver, de la manera más
rápida y eficaz posible, cualquier incidente que cause una interrupción en el servicio.
La Gestión de Incidencias no debe confundirse con la Gestión de Problemas,
pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas
subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio.
Sin embargo, existe una fuerte interrelación entre ambas.
Por otro lado, también es importante diferenciar la Gestión de Incidencias de
la Gestión de Solicitudes, que se ocupa de las diversas solicitudes que los usuarios
plantean para mejorar el servicio, no cuando éste falla.
Los objetivos principales de la Gestión de Incidencias son:
 Detectar cualquier alteración en los servicios TI.
 Registrar y clasificar estas alteraciones.
 Asignar el personal encargado de restaurar el servicio según se define en el
acuerdo correspondiente con el usuario del servicio.

(138)
Esta actividad requiere un estrecho contacto con los usuarios, por lo que la
utilización de una mesa de ayuda juega un papel esencial en el mismo.
Aunque el concepto de incidencia se asocia naturalmente con cualquier
malfuncionamiento de los sistemas de hardware y software, según el libro de
Soporte del Servicio de ITIL® una incidencia es:
“Cualquier evento que no forma parte de la operación estándar de un servicio
y que causa, o puede causar, una interrupción o una reducción de calidad del
mismo”.
Por lo que casi cualquier llamada a la mesa d ayuda puede clasificarse como
un incidente, a excepción las Solicitudes de Servicio tales como autorización de
nuevas licencias, cambio de información de acceso, etc.
Cualquier cambio que requiera una modificación de la infraestructura no se
considera un servicio estándar y requiere el inicio de una Solicitud de Cambio (RFC)
que debe ser tratada a través de otro proceso llamado Gestión de Cambios.
Los principales beneficios de una correcta Gestión de Incidencias incluyen:
 Mejorar la productividad de los usuarios.
 Cumplimiento de los niveles de servicio acordados.
 Mayor control de los procesos y monitorización del servicio.
 Optimización de los recursos disponibles.
 Una CMDB más precisa, pues se registran los incidentes en relación con los
elementos de configuración.
 Y principalmente: mejora la satisfacción general de clientes y usuarios.
Por otro lado una incorrecta Gestión de Incidencias puede acarrear efectos
adversos tales como:
 Reducción de los niveles de servicio.

(139)
 Se malgastan valiosos recursos: demasiada gente o gente del nivel
inadecuado trabajando concurrentemente en la resolución de la incidencia.
 Se pierde valiosa información sobre las causas y efectos de las incidencias
para futuras reestructuraciones y evoluciones.
 Se crean clientes y usuarios insatisfechos por la mala y/o lenta atención de
sus incidencias.
Las principales dificultades a la hora de implementar la Gestión de Incidencias se
resumen en:
 No se siguen los procedimientos previstos y se resuelven las incidencias sin
registrarlas o se escalan innecesariamente y/u omitiendo las reglas
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 las reglas de clasificación y escalado.
Siguiendo el mismo desarrollo para el diseño y la implementación de este
proceso, se tratará de acercarlo lo más posible al proceso que describe ITIL, este
de acuerdo a las evaluaciones, podrá corregirse paulatinamente para que
incremente su nivel madurez.
A continuación se muestra el diseño de este proceso para esta primera
intervención11
:
11

(140)
Proceso de gestión de incidentes
Tabla de contenidos
1. Misión
2. Descripción y narrativa de las actividades del proceso y sus subprocesos
2.1 Registro de solicitud de incidente
2.2 Asignación de solicitud de incidente
2.3 Seguimiento de solicitud de incidentes
2.4 Solicitud de incidente resuelta por un especialista
2.5 Escalación de incidente
2.6 Cierre de solicitud de incidente
2.7 Aprobación de solución de incidente
3. Ámbito
6. Propietario

(141)
1. Misión
La misión del proceso de Gestión de Incidencias es resolver las solicitudes de
incidentes lo más rápidamente posible de manera priorizada.
2. Descripción
El proceso de Gestión de Incidentes se compone de siete sub-procesos o
procedimientos para atender las solicitudes de los usuarios o los incidentes
derivados de un evento detectado y derivado de la gestión de eventos.
El primer procedimiento se llama "Registro de solicitud de incidente”. Este
procedimiento es utilizado por los analistas de mesa de servicio cuando se registran
las solicitudes de incidentes para los usuarios o de los incidentes derivados de
eventos acaecidos en la infraestructura.
El segundo procedimiento es llamado "Asignación de solicitud de incidente”.
Es utilizado por los analistas de la mesa de servicio y coordinadores de grupo para
asignar las solicitudes de incidentes a los especialistas apropiados o cambiar los
coordinadores para la resolución o la ejecución.
El tercer procedimiento es llamado "Seguimiento de solicitud de incidentes”.
Es utilizado por los coordinadores de los grupos cuando se trata de las notificaciones
de reasignación o una escalación derivada de un SLA.
El cuarto procedimiento es llamado "Solicitud de incidente resuelta por un
especialista”. Es utilizado por los especialistas en la resolución de las solicitudes de
incidentes que se han asignado a los mismos.
El quinto procedimiento se llama "Escalación de incidente”. Después de un
incidente se ha escalado, el propietario del servicio del servicio afectado usará este
procedimiento para determinar la forma en que el incidente se puede resolver de la
manera más eficiente.
El sexto procedimiento es llamado "Cierre de solicitud de incidente”. Este
procedimiento es utilizado por los analistas de mesa de servicio cuando se resuelven
las solicitudes de incidentes, y por los solicitantes cuando examinen las solicitudes
de incidentes que se han terminado para ellos.
El séptimo y último procedimiento se llama "Aprobación de solución de
incidente”. Este procedimiento es utilizado por los coordinadores de los grupos, para
la aprobación de una solución que se ha propuesto para uso general.
Una representación gráfica del subproceso se proporciona en la siguiente figura:

(142)
Figura 30 – Descripción de proceso de gestión de Incidentes
Proceso de Gestión de Incidentes
Oficinadeoperacióndesolucionesremota
Versión 2
¿La solicitud es
de un usuario
que contacta la
mesa de
servicio?
Subproceso de
registro de solicitud
de incidente
Subproceso de
asignación e solicitud
de incidente
¿Se requiere de
la Gestión de
Cambios?
Enviar solicitud de
cambio tipificada a
Gestión de cambios
SI
NO
Subproceso de
seguimiento de
solicitudes
Subproceso de
solicitud de incidente
resuelta por un
especialista
¿Se requiere la
escalación del
incidente?
Subproceso de
escalación de
incidente
¿Se requiere el
uso del sitio
alternativo para
resolver el
incidente?
Enviar solicitud de
inicio de servicio en
sitio alternativo a
Gestión de la
Continuidad
SI
NO
SI
SI
NO
Subproceso de cierre
de solicitud de
incidente
Subproceso de
aprobación de
solución de incidente
Proceso de
Gestión de
cambios
Proceso de
Gestión de la
continuidad
NO
Se recibe
solicitud de
Incidente
Canalizar
solicitud para
Registro
Canalizar
solicitud para
asignacion
Evaluar
posible
solución
Enviar
actualización
del incidente
Enviar
actualización
del incidente
Evaluar
posible
solución
Enviar
actualización
del incidente
Enviar actualización del
incidente con la
solución aplicada
Enviar actualización del
incidente con la solución
aplicada para aprobación
de solución estandar
Aviso de
solución
aceptada o
rechazada
Notificación de cambio
aprobado e implementado
Se envia aviso de
activación de sitio
alterno

(143)
2.1 Registro de solicitud de incidente
Cuando un usuario contacta la mesa de servicio, el analista de la mesa de
servicio indaga cómo el usuario puede estar asistido. Si el usuario contactó con la
oficina de mesa de servicio por teléfono o en persona, el analista de la mesa de
servicios hará una serie de preguntas mediante las cuales le que pide al usuario
describa su solicitud o problema para determinar cómo él / ella puede ser auxiliado
y así obtener la información necesaria para realizar el registro. Alternativamente, si
el usuario contactó con la mesa de servicio por escrito (por ejemplo, con un correo
electrónico) el analista del servicio determinará la naturaleza de la solicitud a través
de la lectura y análisis de la información proporcionada por el usuario o solicitante,
de creerlo pertinente solicitará mayor información con el fin de obtener lo necesario
para realizar el registro.
Si el usuario contactó con la oficina de mesa de servicio sobre una solicitud
de incidente registrado anteriormente (con independencia de que ya se ha resuelto
o no), el analista de la mesa de servicio buscará esta solicitud de incidente y tomará
las acciones necesarias (por ejemplo, proporcionará al usuario una actualización del
estado o reabrirá la solicitud si la solución presentada anteriormente no funciona).
Si el usuario en contactó con la oficina de mesa de servicio para presentar
una nueva solicitud, el analista de la mesa de servicio registra la solicitud como una
nueva solicitud de incidente. Si el analista de la mesa de servicio es capaz de
resolver la solicitud (en términos de competencias, los derechos de acceso y las
consideraciones de tiempo), aplicará la solución y procederá al proceso de cierre de
la solicitud y de cierre de incidente (no olvidará documentar la solución de acuerdo
al procedimiento). Sin embargo, si el analista del servicio no es capaz de resolver la
solicitud incidente, él / ella procederán a aplicar el procedimiento de asignación de
solicitud de incidente.
El procedimiento de Solicitud de Registro de incidentes se presenta en la figura
siguiente.

(144)
Figura 31 – Descripción de subproceso de registro de solicitud de Incidentes
Subproceso de registro de solicitud de incidentes
Analistademesadeservicio
Versión 2
Seleccionar usuario y
determinar la
naturaleza de la
solicitud
¿Se trata de una
registrada
previamente?
Revisar el registro
existente
Informar al usuario y
actualizar la solicitud de
servicio
¿El incidente fue
completado y necesita
ser reabierto?
¿Existe una plantilla
para solicitud del
incidente disponible?
Utilizar plantilla para
llenar solicitud de
incidente
Seguir instrucciones de
llenado de plantila
Llenar la solicitud de
incidente y recabar
toda la información
necesaria
Revisar y analizar la
problemática expuesta
en la solicitud de
incidente
Reabrir la solicitud de
incidente
¿El analista de la mesa
de servicio puede
resolver la solicitud de
incidente?
SI
NO
NO
SI
NO
SI
SI
NO
Se revisa procedencia
de la solicitud (sistema
de eventos) u otro
proceso
Se recibe
solicitud de
Incidente
Se emite solicitud de
asignación de incidente
a subproceso e
asignación de
incidentes
Se asigna solicitud
directamente y
continua con proceso
de cierre
¿Usuario
contacta
la mesa de
Servicio?
SI
NO
Verificar repositorio de
plantillas de incidentes

(145)
2.2 Asignación de solicitud de incidente
Después de haber completado una nueva solicitud de incidente, el analista de
la mesa de servicio se asegura de que la aplicación de gestión de servicio aplica las
reglas de asignación automática para derivar el incidente al grupo más apropiado, si
no lo asignará de forma manual.
Si el analista de la mesa de servicio reabrió de nuevo una solicitud de un incidente
existente, él / ella seleccionará manualmente el grupo de asignación más apropiado.
Cuando la reciba el coordinador del grupo al que se le ha asignado la solicitud
de incidente debe revisarla lo más pronto posible. Él / ella podrá enviar de regreso
la solicitud de incidente bajo las siguientes condiciones: Si falta información
necesaria para la resolución normal y eficiente, y / o si le fue asignada de forma
equivocado. Esto podrá ayudar a los analistas de la mesa de servicio a entender
que información debe ser recopilada de los usuarios de tales solicitudes de
incidentes y para qué grupo deben ser asignadas las solicitudes de incidentes
cuando estas son asignadas manualmente.
Si la solicitud de incidente contiene la información necesaria y se le ha
asignado al grupo correcto, el coordinador del grupo determina si este debe o no
ser resuelto a través del proceso de Gestión de Cambios. Las solicitudes de solicitud
de incidente que deberán ser resueltas a través del proceso de Gestión de
Cambios, serán aquellas que para su resolución implique:
 Que un servicio durante las horas de servicio salga de línea o se degrade,
 Que la funcionalidad de un servicio cambie para convertirse en diferente,
 O que la CMDB vaya requerir una actualización posterior a la resolución.
El coordinador del grupo será quién asigne las solicitudes de incidentes que
requieran ser atendidas por el proceso de Gestión de Cambios.
Si una solicitud de incidente no requiere de Gestión de Cambios, el
coordinador del grupo asigna al especialista más adecuado dentro de su grupo
basado en las habilidades, disponibilidad y derechos de acceso.
El procedimiento de Solicitud de asignación de Incidentes se presenta en la
siguiente figura:

(146)
Figura 32 – Descripción de subproceso de asignación de solicitudes de Incidentes
Subproceso de asignación de solicitudes de incidente
AnalistadeMesa
deServicio
CoordinadordeGrupodeSoporte
Versión 2
Asignar la solicitud de
incidente al grupo de
soporte apropiado
Revisar los detalles de
la solicitud de servicio
¿La
solicitud se
asigno al grupo
apropiado y la
información es
completa?
Rechazar la solicitud de
incidente
¿Se requiere de
la Gestión de
Cambios?
Revisar y analizar los
detalles de la solicitud
de servicio
Revisar los detalles de
la solicitud de incidente
rechazada
Asignar la solicitud de
incidente al especialista
apropiado
Elaborar solicitud de
cambio basada en la
solicitud de incidente y
asignarla al coordinador
de Gestión de cambios
NO
SI
SI
NO
Se recibe
solicitud de
asignación de
Incidente
Verificar estado de la
solicitud en base a acuerdos
de servicio, mediante
subproceso de seguimiento
de solicitudes
Revisar y analizar los
detalles de la solicitud
de servicio

(147)
2.3 Seguimiento de solicitud de incidentes
El coordinador de grupo se mantendrá pendiente del tiempo de resolución de
incidentes, de acuerdo a lo expresado en los acuerdos de servicio, cada incidente
tendrá un tiempo de resolución asignado. Si este es superado deberá generarse un
mensaje de escalación dependiendo de su criticidad, es decir si la solicitud si se
refiere a un incidente de interrupción de un servicio o no, el coordinador de grupo
deberá informar al propietario del servicio afectado que la solicitud de incidente
tomará más tiempo para su resolución, ambos verificarán si no se ha excedido el
tiempo de solución para el servicio y determinarán en conjunto si se activa el sub-
proceso de escalación de incidente o revisarán si es necesario escalar el problema
con otro especialista.
Una vez que se ha superado el umbral de resolución de una interrupción de
servicio, el coordinador del grupo determinará quién será el mejor especialista para
seguir trabajando en la resolución de la solicitud de incidente. Para ello puede
obtener asesoramiento de uno o más especialistas dentro del grupo según sea
necesario para determinar si la solicitud de incidente debe ser reasignada a otro
especialista, o debe ser resuelta por el especialista al que se le asignó originalmente
la solicitud de incidente.
Si la solicitud de incidente debe ser reasignada a otro especialista, el
coordinador del grupo basará su decisión de acuerdo a quién se encuentra en una
mejor posición (en términos de habilidades, disponibilidad y / o derechos de acceso)
para resolverlo. Si el coordinador del grupo ha decidido no volver a asignar la
solicitud de incidente, informará al especialista al que se le asignó originalmente la
solicitud de incidente, que la solicitud de incidente debe resolverse rápidamente
para evitar o reducir al mínimo las violaciones al acuerdo de servicio en términos de
tiempo.
El procedimiento de seguimiento de solicitud de incidentes se presenta en
siguiente figura:

(148)
Figura 33 – Descripción de subproceso de seguimiento de solicitudes de Incidentes
Subproceso de seguimiento de solicitudes de incidentes
Coordinadordegrupodesoporte
Versión 2
Revisar la solicitud de
incidente en base a
acuerdos
¿Se
ha superado el
tiempo de
resolución para
el incidente?
Discutir la situación con
el especialista asignado
u otros especialistas
según sea necesario
¿Es necesario
reasignar la
solicitud de
incidente?
Reasignar la solicitud
de incidente
Informar al especialista
responsable de resolver
la solicitud de incidente
acerca del tiempo de
resolución
Escalar el incidente con el
propietario del servicio
afectado por la solicitud de
incidente, a través del
Subproceso de escalación de
incidente
SI
NO
¿Se
ha superado el
tiempo de
indisponibilidad
para el servicio
afectado?
SI
NO
SI
NO
Se recibe solicitud
de Incidente
asignada
Continuar revisando la
en base a acuerdos
Continuar atención de
solicitud mediante
Subproceso de solicitud
resuelta por un especialista

(149)
2.4 Solicitud de incidente resuelta por un especialista
Después de que una solicitud de incidente se ha asignado a un especialista
específico, este deberá revisar la información y tratará de determinar la forma en
que debe ser resuelto.
Si el especialista determina que la solución para el incidente puede implicar:
 O que la CMDB vaya requerir una actualización posterior a la resolución.
Entonces la solicitud de incidente debe ser resuelta a través del proceso de
Gestión de Cambios. El especialista documentará la solución y enviará la solicitud
de cambio conteniendo la solución del incidente al proceso de Gestión de cambios. E
informará al propietario del servicio afectado que la solicitud de incidente tomará
más tiempo para su resolución, ambos verificarán si no se ha excedido el tiempo de
solución para el servicio y determinarán en conjunto si se activa el sub-proceso de
escalación de incidente.
Si el especialista determina que la solicitud de incidente no debe ser escalada
a Gestión de cambios, él / ella deberá aplicar la solución encontrada y resolver el
incidente. Después de haber resuelto la solicitud de incidente, deberá actualizar su
información en la aplicación de gestión de servicios para garantizar que el solicitante
es notificado.
Si el especialista considera que la información para solución de la solicitud de
incidente podría ayudar a los solicitantes, los analistas de la mesa de servicio u
otros especialistas para resolver los casos futuros que son similares, se propondrá
para uso general. Por último, si después de aplicar la solución propuesta para
resolver la solicitud de incidente, el especialista cree que el incidente por el cual se
proporcionó la solución es probable que se repita, deberá informar al coordinador de
Gestión del problemas, del servicio afectado para garantizar que se toman medidas
para prevenir futuros ocurrencias .
El procedimiento de Solicitud de incidente resuelta por un especialista se
presenta en la siguiente figura:

(150)
Figura 34 – Descripción de subproceso de Solicitud de incidente resuelta por un especialista
Subproceso de solicitud de incidente resuelta por un especialista
Especialista
Versión 2
Revisar, analizar y
actualizar los detalles
de la solicitud de
servicio
Determinar como
resolver la solicitud de
incidente
¿Se requiere de
la Gestión de
Cambios?
Escalar el incidente con el
propietario del servicio
afectado por la solicitud de
incidente, a través del
Subproceso de escalación
de incidente
Resolver la solicitud de
incidente
Completar y
documentar la solución
en la solicitud de
incidente
NO
SI
Se recibe notificación
de asignación de
para atención
Enviar notificación de
solución, mediante
subproceso de cierre de

(151)
2.5 Escalación de incidente
Después de que un coordinador de grupo o especialista ha escalado un
incidente y ha notificado al para el propietario del servicio afectado, el propietario
del servicio habla con el especialista (s) que han estado lidiando con el incidente
para obtener información y comprender de la situación actual para determinar la
mejor forma en que el incidente puede ser resuelto. Si la recuperación del servicio
afectado va a tardar más tiempo del acordado como umbral para su solución
entonces se tomará la decisión de mover el servicio a su sitio alterno (DRP) para
ello el propietario del servicio escalará el incidente al gerente de turno para solicitar
la autorización de inicio del servicio en el sitio alterno.
Una vez que el servicio fue iniciado en el sitio alterno, se dará continuidad a
la atención de la solicitud de incidente sobre el CI donde se originó, de acuerdo a lo
que el especialista determine.
De no existir un sitio alterno, se procederá a continuar con la atención del
incidente de acuerdo a lo que el especialista determine.
Si el especialista determina que la solución para el incidente puede implicar:
 que la CMDB vaya requerir una actualización posterior a la resolución.
Entonces la solicitud de incidente debe ser resuelta a través del proceso de
Gestión de Cambios. El especialista documentará la solución e informará al
propietario del servicio afectado que la solicitud de incidente tomará este camino
para su resolución. Ambos, deberán consensuar la mejor manera de mantener el
riesgo y el impacto de la implementación de cambios en un nivel aceptable.
Después de que se ha establecido cómo debe implementarse el cambio, el
propietario del servicio solicitará al especialista (s) se elaboré la solicitud
correspondiente para llevar a cabo la ejecución del cambio como un cambio de
emergencia y envíe la solicitud de cambio conteniendo la solución del incidente al
proceso de Gestión de cambios.
Si no es necesaria la Gestión de Cambios, el especialista (s) procederá a
resolver el incidente dentro del proceso de Gestión de Incidentes.
Habrá que tomar en cuenta que el papel de propietario del servicio será realizado
por el gerente de turno cuando el propietario del servicio del servicio afectado no
está disponible.
El procedimiento de escalación de incidente se presenta en la siguiente figura:

(152)
Figura 35 – Descripción de subproceso de escalación de incidente
Subproceso de escalación incidente
PropietariodelservicioEspecialista
Propietariodel
servicioyespecialista
Versión 2
Determinar la mejor
manera de resolver el
incidente en consenso
con el especialista
¿Se
requiere la
utilización del
sitio alterno para
dar continuidad
la servicio?
Escalar la solicitud al
gerente de turno
¿Se requiere de
la Gestión de
Cambios?
Analizar en consenso
con el especialista el
riesgo e impacto del
cambio para resolver la
Solicitar la
implementación como
un cambio de
emergencia
Elaborar solicitud de
cambio basada en la
solicitud de incidente y
asignarla al coordinador
de Gestión de cambios
Continuar atención de
solicitud mediante
Subproceso de solicitud
resuelta por un
especialista
NO
SI
SI
NO
de escalación de
Revisar estado de la
solicitud y analizar
motivo de la escalación
Solicitar activación de
sitio alterno, mediante
la continuidad
Analizar en consenso
con el especialista las
tareas para resolver la

(153)
2.6 Cierre de solicitud de incidente
Cuando un analista del servicio es capaz de resolver una solicitud de incidente
(en términos de competencias, los derechos de acceso, y las consideraciones de
tiempo), resuelve y actualiza la solicitud de incidente en consecuencia. El analista
del servicio cierra la solicitud de incidente se pondrá en contacto con el usuario y le
indicará que el incidente ha sido resuelto y está en condiciones para que pueda
verificar la solución.
Si el analista del servicio cree que la información que la solución a la solicitud
de incidente podría ayudar a los solicitantes, los analistas de la mesa de servicio y /
o especialistas para resolver los casos futuros que son similares propondrá la
solución para uso general, para ello documentará dicha solución conforme a formato
y procedimiento para ello.
Después de que el usuario ha recibido una notificación de finalización de la
solicitud de incidente, examinará la información de solución a su solicitud de
incidente. El usuario entonces procederá a verificar la solución. Si el usuario
considera que la solución aceptable, enviará la notificación de aceptación de la
solución. Si la solución no es aceptable, sin embargo, el usuario volverá a abrir la
solicitud de incidente, solicitando por lo tanto una mejor solución.
El procedimiento de cierre de solicitud de incidente se presenta en la
siguiente figura:

(154)
Figura 36 – Descripción de subproceso de Cierre de solicitud de incidente
Subproceso de cierre de solicitud de incidente
AnalistadelamesadeservicioUsuariooCliente
Versión 2
Resolver la solicitud de
incidente
¿El usuario
puede verificar la
solución de
manera
inmediata?
Revisar la notificación
de incidente resuelto
¿La solución es
aceptable?
¿El usuario
acepto la
solución?
Validar solución y
enviar notificación de
aceptación de cierre
Solicitar reabrir el
incidente, mediante
nueva solicitud
Completar y
documentar la solicitud
de incidente
Cerrar solicitud de
incidente
Notificar a usuario que
la solicitud ha sido
completada y deberá
revisar a la brevedad
SI
SI
NO
NO
SI
NO
Actualiza solicitud que
se asigno directamente
Enviar solicitud para
analisis de solución a
Subproceso de
aprobación de solución
de incidente
Solicitar al usuario
verifique la solución
aplicada
Actualizar incidente,
generando una nueva
de solicitud completada
y atendida por un
especialista

(155)
2.7 Aprobación de solución de incidente
Después de que un coordinador de grupo ha recibido una notificación de que
una nueva solución ha sido propuesta, deberá revisar la información de la solución
propuesta. Si el coordinador del grupo está de acuerdo en que la solución propuesta
podría ayudar a los usuarios, los analistas y / o especialistas de la mesa de servicio
para resolver las solicitudes de incidentes futuros que son similares, lo aprobará y
pondrá a disposición en la CMDB (después de haber mejorado la información de
solución si esto se considera necesario). Esto hace que la solución esté disponible
para uso general.
Por otro lado, si el coordinador del grupo no cree que la solución propuesta
ofrece ningún beneficio, el desechará la propuesta como de uso general.
El procedimiento de aprobación de solución de incidente se presenta en la
siguiente figura:

(156)
Figura 37 – Descripción de subproceso de aprobación de solución de incidente
Subproceso de aprobación de solución de incidente
Coordinadordegrupodesoporte
Versión 2
Revisar y analizar la
nueva solución aplicada
¿La solución
aplicada puede
ser usada como
solución de uso
general?
Aprobar la solución
para uso general en
incidentes futuros y
ponerla a disposición en
la CMDB
Desechar la solución
como de uso general
para incidentes futuros
SI
NO
Se recibe solicitud de
incidente completa y
cerrada

(157)
3. Ámbito
El alcance del proceso de Gestión de Incidentes se limita a las categorías de
solicitudes de incidentes enumerados en la siguiente tabla.
Categoría de la Solicitud Descripción
Solicitud de resolución de
Incidentes
Solicitud de un usuario para restablecer un
servicio que no está funcionando de la manera
que se supone que debe.
Nota: Una solicitud de restablecimiento
de contraseña de un usuario que ha
olvidado su contraseña, o la solicitud de
una restauración de una copia de
seguridad de un usuario que ha perdido
datos, también cae dentro de esta
categoría.
Solicitud de cambio Solicitud de un usuario para crear, modificar,
añadir, mover o quitar una parte o toda la
funcionalidad del servicio, el acceso, o
componentes de la infraestructura.
Nota: Una solicitud de la copia de datos
(por ejemplo, para hacer una copia de
seguridad o restaurar una copia de
seguridad en un lugar diferente), o una
solicitud para correr un proceso de
trabajo por lotes (batch), también cae
dentro de esta categoría.
Solicitud de Información Solicitud de un usuario de una respuesta a una
pregunta relacionada con el servicio.
Tabla 14 - Descripción de categorías de incidentes del proceso de gestión de Incidentes

(158)
La siguiente tabla muestra los diferentes roles que intervienen en el proceso
de Gestión de Incidentes, junto con sus respectivas responsabilidades.
Rol Responsabilidad
Coordinador de Grupo  Distribuye todas las solicitudes de incidentes
que se han asignado a su grupo / entre los
especialistas del grupo y coordinadores de
cambio, teniendo en cuenta las aptitudes, la
disponibilidad y los derechos de acceso a los
especialistas individuales y de servicios para
los cuales los coordinadores de cambio son
responsables.
 Se asegura de que las solicitudes de incidentes,
que están asignados a su grupo, se resuelvan
dentro de los objetivos de finalización dictados
por los acuerdos. Esto se hace al asegurar que
los mecanismos de escalación, son objeto de
seguimiento en forma eficaz y oportuna.
 Deriva interrupciones del servicio al propietario
del servicio afectado cuando no se han resuelto
en el tiempo dictado por el acuerdo
correspondiente.
 Revisa, acepta o rechaza las soluciones que se
han propuesto para su uso general después de
haber recibido una notificación de cierre y
solución.
Gerente de turno  Asume las responsabilidades de los propietarios
de servicios cuando no están disponibles.
Analista de Mesa de
Servicio
 Proporciona la interfaz entre la organización
proveedora de servicios y los usuarios de los
servicios que la organización ofrece.
 Obtiene la información necesaria de los
usuarios cuando están solicitando el apoyo y
realiza los registros de esta información en las
solicitudes de incidentes de una manera
eficiente, precisa y completa.
 Resuelve el mayor número de solicitudes de
incidentes ha registrado como sea posible
dentro de las limitaciones en sus derechos de
acceso y las limitaciones de tiempo.
 Se asegura de que la solicitud de incidente que
ha registrado, pero que no puede resolver, se
asigna al grupo más apropiado para su
resolución.
Servicio al propietario  Decide si un incidente escalado debe resolverse
mediante la aplicación de un cambio de

(159)
emergencia, mediante la recuperación del
servicio afectado en su sitio alterno, o por la
continuación de la resolución de la incidencia
en el proceso de Gestión de Incidentes.
Especialista  Resuelve las solicitudes de incidentes.
 Actualiza solicitudes de incidentes con
información de estado y los cambios
pertinentes.
 Deriva incidentes, donde la resolución sólo
podrá ser implementada a través del proceso
de Gestión del Cambio, al propietario del
servicio del servicio afectado para consensuar
la solución.
Cliente  Pide ayuda cuando sea necesario y proporciona
la información necesaria para ayudar a resolver
las solicitudes. Las solicitudes serán
presentadas mediante el llenado del formulario
de solicitud, o poniéndose en contacto con la
oficina de servicio por correo electrónico o
teléfono.
 Comprueba las soluciones que la organización
proveedora de servicios ha provisto para sus
solicitudes de incidentes y los vuelve a abrir
cuando las soluciones no son aceptables.
Tabla 15 - Descripción de roles y responsabilidades del proceso de gestión de Incidentes

(160)
La tabla siguiente muestra los indicadores clave de rendimiento (KPI) que han
sido seleccionados para el seguimiento del éxito del proceso de Gestión de
Incidentes.
KPI Definición Frecuen
cia
Unidad
Incidencias
resueltas dentro
de la meta
El número de solicitudes de
incidentes cerrados con el estado
de "Restauración del Servicio de
usuario" que se resolvieron sin
escalamientos y el número total de
incidentes cerrados.
mensual #
Resoluciones
hechas por la
mesa de servicio
incidentes que fueron tanto
registrados y resueltos en el
mostrador de servicio sin la ayuda
de otro grupo y el número total de
solicitudes de incidentes registrados
por los analistas de la mesa de
servicio.
mensual #
Soluciones
rechazadas
El número de veces que una
solicitud incidente fue reabierto, ya
que su solución no fue aceptada y
el número total de solicitudes de
incidentes resueltos.
mensual #
Atrasos en la
resolución de
solicitudes de
incidentes
incidentes que aún no tienen su el
estado de "Resuelto".
Diaria # de
Solicitud
es de
incidente
s
Tabla 16 - Descripción de KPIs del proceso de gestión de Incidentes
6. Propietario
El propietario del proceso de Gestión de Incidentes es el CAB de gestión de
servicios.
solicitudes de mejora del proceso de Gestión de Incidentes y su funcionalidad de
apoyo en la aplicación de gestión de servicios.

(161)
Al igual que en los procesos anteriores para la correcta implementación de
este último proceso, fue necesario elaborar información complementaria, con el fin
de pudiera usarse en las mejores condiciones.
Se llevaron a cabo talleres con la participación del personal técnico que labora
en esta organización para establecer las reglas de clasificación de los incidentes y
sus niveles de atención, así como la tipificación de los registros que se llevarían a
cabo para los incidentes que se presentarán. Teniendo como resultado y documento
que sirve de apoyo al diseño de este proceso.

(162)
CAPITULO III - OBSERVACIONES DEL PROCESO DE
IMPLANTACIÓN Y RESULTADOS
3.1 Observaciones del proceso de implantación
A lo largo del proceso de diseño se ha intercalado algunos comentarios referentes al
proceso de implementación, para sustentar el propio diseño. Sin embargo es
necesario ahondar un poco en este proceso, ya que es muy importante para que se
tenga éxito en la implementación de los nuevos procesos diseñados, para comenzar
se puede decir que esta se llevó a cabo mediante la firme idea de la colaboración de
todo el personal.
Basados en uno de los hallazgos mencionados en la etapa de diseño que a
luces del proceso técnico no pareciera relevante, si lo es para efectos de la
implementación dado que representa un obstáculo para el éxito de la implantación,
porque un nuevo proceso representa un cambio en la forma de trabajo, la forma de
pensamiento y prácticas que se venían realizando en la organización objeto de este
trabajo.
El hallazgo del que se habla tiene que ver con la comunicación y sobre todo
con la capacidad de la propia organización a adoptarse a los cambios, cito lo
expresado en dicho análisis:
“Durante el desarrollo de las entrevistas se percibe un sesgo en la
comunicación, aparentemente emanado de diferencias contractuales, esto genera
fundamentalmente dos grupos ya que el personal directivo es empleado de
confianza y el personal operativo es sindicalizado. Aunque no se encuentra
plasmado en ningún lado, se aprecia a través de las respuestas obtenidas del
personal entrevistado. Esto puede representar un problema al momento de
implantar nuevos procesos. Sobre todo en el tema de resistencia al cambio.”

(163)
Cuando se quiere realizar un cambio en la forma de trabajo de un grupo en
particular debe cuidarse que este grupo este motivado y crea que el cambio es un
beneficio tanto para la organización como para el mismo. Debe entender que los
cambios se realizan para mejorar en todos los sentidos.
Al existir una división del personal y problemas de comunicación entre los
diferentes grupos es más difícil que quienes proponen un cambio puedan llevarlo a
cabo, porque es difícil vender la idea y que se permee a toda la organización.
De ahí que se recurriera un poco a los principios de la Gestión del
Conocimiento y las teorías de las organizaciones que aprenden. Desde el punto de
vista de que las organizaciones que aprenden se constituyen por grupos que se
sustentan en la capacidad de aprendizaje de sus miembros y están abiertas a
cambios en su estructura, es decir, son capaces de rediseñarse continuamente a sí
mismas y en ellas se dan tres niveles de aprendizaje: individual, grupal y
organizacional, con el objetivo común no sólo de realizar mejor las tareas sino de
edificar una sólida base de conocimiento y revisar continuamente los procesos y los
productos. En pocas palabras hay que involucrar a todos los miembros en la
creación de las nuevas formas de trabajo, para que estas fluyan dentro de la
organización de manera más natural.
Por tanto para la implementación de estos procesos se decidió incluir al
personal en el proceso de desarrollo, usando los documentos de procesos referidos
en el capítulo de diseño de procesos de este trabajo, como guía, con ellos se marcó
la pauta para lo que se pretendía mejorar, y se involucró al personal para que los
enriqueciera aportando de manera directa, colaborando en el desarrollo de todos
aquellos elementos que sirven como apuntalamiento para esos procesos, es decir,
que apoyaran en el diseño de la documentación (incluyendo diseño de formatos),
reglas para el proceso y procedimientos o guías más técnicas que ayudarían a la
ejecución del propio proceso, esto tendería al éxito de la implementación.

(164)
Para lograr esto se llevó a cabo el desarrollo de varios proyectos alternos al
diseño de estos procesos, la mayoría se llevaron a cabo mediante la organización de
talleres, donde el personal pudo debatir y consensuar, la mejor forma de llevar el
proceso. En estos talleres como parte del contenido, se dieron nociones del marco
de referencia usado para el desarrollo de los procesos, es decir se dieron cursos de
ITIL adaptados de forma particular para cada proceso desarrollado, para que el
personal pudiera entender los porqués del rediseño y constatará las bondades del
uso de las mejores prácticas.
Cada taller tenía como objetivo final un entregable, este consistía en la
elaboración de diferentes documentos, lo que permitió comenzar con la
estandarización de la información en la organización.
En cada taller se hizo hincapié en que, el registro eficiente de todo lo que se
estaba produciendo, la centralización de la información, así como su estandarización
eran muy importantes. Que la disponibilidad de la información para toda la
organización es indispensable. Esto finco las bases para comenzar a tratar el tema
de gestión de conocimiento.
El proceso de cada taller se desarrolló de forma no tan dinámica como se
hubiera esperado, ya que tomo más tiempo del planeado para obtener resultados,
pero el haber establecido que al término de cada taller, debería existir un
entregable fue clave del éxito de cada uno.
Una vez que se tuvieron los elementos para completar al menos lo básico de
cada proceso y todas las partes estuvieron de acuerdo en las reglas e información
que se usarían, se pensó en la mejor forma de llevar tecnológicamente este cambio.
Desafortunadamente no se pudo contar con un sistema de información
automatizado que nos permitiera llevar el proceso de una forma más ágil, por lo que
se optó por utilizar las herramientas y medios tecnológicos con los que cuenta la
organización, para atender el uso de estos procesos.

(165)
Para poder centralizar la información se optó por generar un repositorio
central en un servidor de archivos, compartido en la red y accesible por todos los
miembros de la organización, esto hace las veces de la CMDB.
Se definió una estructura de directorios, organizados de tal manera que
fueran de fácil e intuitiva navegación, donde se depositó la información referente a
la infraestructura (plantillas), documentación cómo: procedimientos y guías, listado
de parámetros, umbrales y alertas, niveles de escalación, listado de contactos
(clientes, proveedores, contratos y licencias), software e incluso manuales técnicos
y documentación adicional de los elementos de configuración.
Se establecieron las reglas de quién y cómo se debe modificar la información
contenida en dicho repositorio, esto para sustentar el proceso de gestión de
configuraciones.
Se desarrollaron dos procedimientos para el monitoreo de toda la
infraestructura, que básicamente establecen dos mecanismos: el primero es un
mecanismo que indica los aspectos y la manera de revisar de la infraestructura de
forma manual. El segundo explica cómo utilizar una herramienta que ya se tenía
para el monitoreo activo de los umbrales de operación de los equipos, ambos
procedimientos se desarrollaron tomando en cuenta los aspectos más importantes
que para el cliente y que él considera que deberían de ser monitoreados, esto
mediante una serie de reuniones directas con los usuarios de la infraestructura. Esto
es muy deseable ya que las alertas y desviaciones del correcto funcionamiento de la
infraestructura que se está monitoreando deben ser las que al cliente le interesan,
esto se hizo para apuntalar el proceso de gestión de eventos.
Por último, en la organización se contaba con una herramienta de software
muy básica para el registro de novedades, desarrollada de forma interna a manera
de “bitácora electrónica”. Para apoyar al proceso de gestión de incidentes se elaboró
un procedimiento para utilizar esta bitácora como el repositorio de los registros de
incidentes. Este procedimiento indica la tipificación que debe hacerse y la forma de

(166)
atender dichos incidentes, así como la forma de documentación de los mismos para
efectos de consulta.
Una vez acordado y establecido todo esto y con el fin de darle formalidad a la
implementación, se solicitó al responsable de la organización que diera la
instrucción de comenzar a trabajar mediante estos mecanismos. Se llevó a cabo una
reunión de “kick-off” para dar inicio, esto fue muy importante y fundamental para
que la implementación fuera exitosa.
Se dio un plazo de tres meses desde del inicio del trabajo con esto tres
procedimientos. Al término se planteó la revisión de los mismos en conjunto de
nuevo con todo el personal involucrado, para comentar todos los aspectos negativos
y positivos del esta nueva forma de trabajo, revisar si los indicadores son
adecuados, si se llevan de forma correcta, etc.
Sin embargo, este periodo no fue suficiente por lo que se decidió extender
este periodo tres meses más y realizar la revisión y evaluación después del primer
semestre del año.

(167)
3.2 Resultados obtenidos
A pesar de que al momento de concluir este trabajo, el proceso de implantación
continúa, todavía se están haciendo ajustes a los procedimientos y guías iniciales
que son necesarios para el trabajo cotidiano y que no podían esperar a la revisión
formal programada, se pueden enumerarse algunas mejoras que son tangibles y
que describo a continuación:
Del trabajo en los talleres se obtuvieron los siguientes resultados:
 Se diseñaron plantillas para el registro de los elementos de configuración de
toda la infraestructura que se administra,
 Se definió y creo el espacio que sirve como repositorio centralizado de toda
esta información la CMDB,
 Se definieron las reglas para el uso de este repositorio,
 Se definieron los parámetros que deberían ser monitoreados por el proceso
de gestión de eventos y se plasmaron en formatos únicos para toda la
infraestructura,
 Se definieron los umbrales de esos parámetros y establecieron niveles de
criticidad y de escalación en base a esos umbrales, todo mediante formatos
únicos,
 Se definieron las reglas para el registro de incidentes y las políticas usadas
para el control, clasificación y evaluación de la atención a los mismos,
 Se elaboraron una serie de procedimientos tanto para la ejecución como para
el registro de toda la información que se genere durante el seguimiento de
cada proceso, así como su validación y control.
Es decir que a través de esta intervención, se ha logrado que la organización
deje de tener dispersa su información, se pudo lograr que la información que se
tiene tenga una estructura, disponibilidad, sea estandarizada y que todos los
involucrados en el proceso tengan una visibilidad homogénea. También a través de
los talleres se pudo provocar en el personal la sensibilidad de que se trabaja para

(168)
atender un servicio, que este servicio está enfocado en atender las necesidades de
un cliente, que es importante no perder de vista que la percepción y satisfacción
que este último tiene del servicio es imperante, por tanto las actividades que se
realizan tienen que tener eso como objetivo principal.
Se ha logrado que se lleve a cabo el registro si no completo en su mayoría de
todas las actividades, eventos e incidencias que ocurren en la infraestructura de un
manera más organizada, a través de este registro ya es visible para todos los
involucrados en el proceso. Se ha obtenido un cumulo de nuevos procedimientos
para resolver incidentes similares que ocurren o reportan los usuarios, estos han
sido plasmados en documentos estandarizados, validados y están disponibles para
el personal involucrado con el proceso de operación. Incluso se han compartido con
personal de otra área de operación similar que se encuentra en la ciudad de México.
Esto es destacable ya que el conocimiento que antes se quedaba en quién atendía
un incidente, ahora se encuentra en papel, está disponible para toda el área y se
comienza a permear hacia el resto de organización, hacia otras áreas.
En principio, para poder medir el impacto del cambio, los indicadores que se
plasmaron en cada uno de los procesos se definieron con alcances limitados para
ver la eficacia y utilidad en la medición del desempeño del propio proceso.
Por ejemplo, se decidió que para el proceso de Gestión de la Configuración,
no se incluyera el cien por ciento de los elementos de la infraestructura, si no que
se fueran agregando paulatinamente y que el indicador constara en registrar el
mayor número de elementos posibles. Y su vez que de estos últimos, si se
mantuviera la información actualizada al cien por ciento.
Hoy día se lleva un avance del 70% de elementos registrados y controlados
por el proceso. Pero se estima que al final del año sea al menos el 98%. No
obstante lo más relevante de esto es el hecho que ya es posible medir el avance y
establecer metas en el tiempo.

(169)
De igual forma se estableció una meta para los elementos que deben estar
monitoreados por el proceso de Gestión de Eventos. Se estableció que al menos los
elementos de configuración más importantes ya registrados en la CMDB por el
proceso de Gestión de la Configuración deberían estar siendo controlados por el
proceso, mediante los mecanismos automatizados y manuales que se definieron
para ello.
A este respecto podemos decir que el 100% de esos elementos está siendo
controlado por el proceso, además de otro porcentaje más que no estaba acordado.
Gracias a ese proceso, se han detectado que algunos no estaba siendo
monitoreados de forma apropiada y se han llevado a cabo las tareas necesarias
para corregirlas.
Derivado de ello, ya se cuenta con una estadística de los eventos ocurridos,
los eventos que fueron atendidos mediante el proceso de Gestión de Incidentes.
En cuanto a este último proceso, también es posible, mediante los registros
que se han llevado de los incidentes, conocer cuántos de estos han sido atendidos,
por quién fueron atendidos, cómo fueron atendidos, cuántos fueron atendidos con
éxito, cuántos no lo fueron, cuántos fueron documentados de forma correcta y de
cuáles se obtuvo una solución estándar y se creó un documento formal
(procedimiento). En la sección de anexos, el anexo 3 y 3-A muestra un ejemplo de
la bitácora de eventos e incidentes, donde se plasman los diferentes registros y su
seguimiento, favor de referirse a la tabla de anexos en la sección de anexos a final
del documento.
Así mismo, en la citada sección de anexos, el anexo 4 muestra cómo se está
usando ese registro para obtener estadísticas de atención como seguimiento al
proceso, favor de referirse también a la tabla de anexos en la sección de anexos a
final del documento.

(170)
De forma colateral esto ha servido para evaluar el desempeño del personal de
operación, detectar sus deficiencias en cuanto a habilidades, aptitudes, actitudes y
capacidad al momento de la atención a eventos e incidentes. Lo que nos ha
permitido establecer una meta en cuanto a desarrollo del personal y planificar como
cubrir los aspectos negativos, como la modificación del plan de capacitación,
atendiendo de forma particular los rezagos observados por el personal que atiende
los incidentes.
A su vez se ha podido establecer el mecanismo para que el cliente al
momento de suscitarse un incidente, se le informe de manera oportuna o bien
pueda reportarlo, sepa quién lo atenderá y este informado sobre el proceso de
atención que se sigue. Aunque no se tiene propiamente una mesa de servicio, se
estableció un punto único de contacto, en la figura del responsable de la operación,
qué se encarga de recibir, canalizar los incidentes al personal apropiado y de
mantener al usuario enterado del proceso de atención. Además cualquier solución
que implique un cambio mayor y que pudiera afectar en mayor medida a la
infraestructura, se planea y acuerda con la parte usuaria.
Al punto en donde se encuentra la madurez de estos procesos y tomando en
consideración que para la implementación de la mesa de servicio se necesita que los
procesos estén más relacionados y existan otros procesos implementados para que
esta tenga sentido, se considera su inclusión hasta posteriores revisiones.

(171)
3.3 Evaluación posterior de la organización
Ahora bien en cuanto a la medición de avance usando los mecanismos
enfocados a los propios procesos, entiéndase la medición de madurez del proceso
implementado respecto de su marco de referencia (ITIL), representado en este caso
por las características enunciadas por el método de PMF. Se puede volver a aplicar
el acercamiento o comparativa entre los objetivos de cada proceso o procesos, las
actividades que se realizan y los resultados logrados después del rediseño o
adecuación, con las definiciones que hace PMF de cada nivel de madurez. Para
realizar esto se puede volver a aplicar el mismo cuestionario que se usó para
evaluar el nivel de madurez posterior al proceso de análisis inicial de la
organización.
Se tomaron en cuenta todos los resultados antes expresados, y se aplica para
cada proceso de forma individual, dado que la implementación se llevó a cabo
tomando en cuenta el “Enfoque basado en procesos individuales”. Obteniendo como
resultado un avance dentro de esta definición de madurez, se muestra a
continuación el grado de avance:

(172)
– Aplicado al proceso de Gestión de la Configuración - Diseño del autor, basado en el
artículo: ITIL® Maturity Model and Self-assessment Service: user guide, Autores: Colin
Rudd y John Sansbury.
A continuación se muestra una lista de las características genéricas y el nivel de madurez que el
proceso implementado: Gestión de la Configuración cumple hasta ahora.
Estas características se derivan de una variedad de fuentes, incluyendo los atributos genéricos
del Modelo de Madurez de ITIL y el Servicio de Auto-evaluación.
Nivel 2: repetible ( activo) Se observa en
la organización
1 Existe cierto compromiso de la dirección .
2 Las actividades cuentan con recursos formalmente.
3 Las metas y objetivos se definen.
4 El alcance del proceso o función y sus interfaces con otros procesos o funciones dependientes se
definen y estan de acuerdo.
5 Existen procedimientos, pero puede no estar completamente documentado.
6 Los procedimientos son seguidos generalmente, pero varían de persona a persona y de un
equipo a otro.
7 Las personas que llevan a cabo las actividades tienen las habilidades, la experiencia, la
competencia y los conocimientos para llevar a cabo su función.
X
8 Los Roles son reconocidos, incluso si no se definen formalmente. X
9 El rendimiento se mide y se informa a los interesados, al menos internos. X
10 El Rendimiento es cada vez más consistente, pero sigue siendo variable. X
11 Algunos procesos de automatización se están empezando a utilizar para mejorar la eficiencia. X
12 Deficiencias significativas son reconocidos y las medidas correctivas adoptadas, aunque de una
manera un tanto ad hoc.
13 Las personas que realizan el rol reciben formación básica, muy poca o ninguna, relacionada con
el trabajo que desempeñan cuando ingresan y mucho despues de ingresar.
14 Se recibe algo de información de los interesados ??y las principales problemascomo
retroalimentación
15 Las mejoras se centran en las actividades en lugar de los resultados que esperan de las partes
interesadas.
Nivel 3: define ( proactivo ) Se observa en
la organización
1 Compromiso de la dirección es visible y evidente. X
2 Las actividades están adecuadamente dotadas de recursos, aunque de vez en cuando, y en
circunstancias excepcionales, pueden ser inadecuados.
X
3 Se está empezando a focalizar en el funcionamiento de forma proactiva , aunque la mayor parte
del trabajo sigue siendo reactiva.
X
4 Los Documentos importantes son controlados con números de versión y está sujeto a cambios
de control.
X
5 El alcance del proceso o función y sus interfaces con otros procesos o funciones dependientes
están documentados.
X
6 Los procedimientos e instrucciones de trabajo se documentan y mantienen actualizados. X
7 Las actividades se llevan a cabo con un grado razonable de coherencia. X
8 Los resultados son cada vez más predecibles y por lo general responden a las necesidades de las
partes interesadas (clientes).
X
9 Las variaciones entre las personas y los equipos que realizan las actividades son mínimos. X
10 Los roles son reconocidos formalmente , definidos y asignados. X
11 El rendimiento se mide usando una variedad de métricas . X
12 El desempeño se presenta a los interesados internos y externos. X
13 Al menos algunas de las actividades están automatizadas .
14 Los errores y los fracasos al seguir procedimientos son la excepción. X
15 Cuando se cometen errores, éstos a menudo se reconocen y están empezando a ser
investigados para mejorar el rendimiento y reducir los errores posteriores.
X
16 Las personas que realizan el rol reciben tanto formación inicial como algún tipo de formación
continua.
X
17 La retroalimentación de las partes interesadas se busca en forma activa . X
18 Relaciones entre procesos y dependencias son reconocidos. X
19 Las actividades están sujetas a la planificación y rara vez se tienen en una base "ad hoc" o no
planificadas.
X
20 El proceso o función se emplea sistemáticamente en toda la organización .
21 Las Habilidades de la gente se evalúan y validan con las necesidades cambiantes. X
22 Hay un método formal para la gestión de los cambios en el proceso o función.
X
23 Las actividades rutinarias son automatizados.
24 Para los procedimientos y actividades se realizán pruebas de cumplimiento y las excepciones
claras se registran y son utilizadas como base para la mejora.
X
25 El enfoque interno ( técnico) como externa ( cliente ) son equilibrados.
Características de los niveles de madurez

(173)
– Aplicado al proceso de Gestión de Eventos - Diseño del autor, basado en el artículo:
ITIL® Maturity Model and Self-assessment Service: user guide, Autores: Colin Rudd y John
Sansbury.
proceso implementado: Gestión de Eventos cumple hasta ahora.
la organización
equipo a otro.
X
9 El rendimiento se mide y se informa a los interesados, al menos internos.
X
10 El Rendimiento es cada vez más consistente, pero sigue siendo variable.
X
14 Se recibe algo de información de los interesados y las principales problemas como
retroalimentación
interesadas.
la organización
1 Compromiso de la dirección es visible y evidente.
X
X
X
de control.
X
X
X
9 Las variaciones entre las personas y los equipos que realizan las actividades son mínimos.
X
11 El rendimiento se mide usando una variedad de métricas .
X
12 El desempeño se presenta a los interesados internos y externos.
X
13 Al menos algunas de las actividades están automatizadas . X
X
continua.
X
17 La retroalimentación de las partes interesadas se busca en forma activa .
X
18 Relaciones entre procesos y dependencias son reconocidos.
X
planificadas.
X
X
X

(174)
– Aplicado al proceso de Gestión de Incidentes - Diseño del autor, basado en el artículo:
ITIL® Maturity Model and Self-assessment Service: user guide, Autores: Colin Rudd y John
Sansbury
proceso implementado: Gestión de Incidentes cumple hasta ahora.
la organización
equipo a otro.
X
9 El rendimiento se mide y se informa a los interesados, al menos internos.
X
10 El Rendimiento es cada vez más consistente, pero sigue siendo variable.
X
14 Se recibe algo de información de los interesados ??y las principales problemascomo
retroalimentación
interesadas.
la organización
1 Compromiso de la dirección es visible y evidente.
X
X
X
de control.
X
X
X
9 Las variaciones entre las personas y los equipos que realizan las actividades son mínimos.
X
11 El rendimiento se mide usando una variedad de métricas .
X
12 El desempeño se presenta a los interesados internos y externos.
X
13 Al menos algunas de las actividades están automatizadas .
X
continua.
X
17 La retroalimentación de las partes interesadas se busca en forma activa .
18 Relaciones entre procesos y dependencias son reconocidos.
X
planificadas.
X
X
X

(175)
Como puede observarse, de acuerdo al cuestionario, en general los procesos
diseñados para la organización y los resultados obtenidos hasta ahora, cumplen
preponderantemente con las características relacionadas al nivel 3 de madurez
según el modelo que describe el PMF:
Servicio
Servicio)
Cliente
Negocio
Valor
Perfecta integración de las TI en el negocio
y la planeación estrategia para la toma de
decisiones.
Eso representa un grado de avance aceptable, y nos permite marca la pauta
para continuar ascendiendo de nivel de madurez, ya que podemos trabajar de
manera puntual en los aspectos o características faltantes del propio nivel si fuera el
caso y marcar la ruta que habrá que seguir para alcanzar las del siguiente nivel.
Si bien al marcar el avance de los procesos verificando y validando las
características con las que cumplen, se encuentra que en algunos casos no las
cumplen al cien por ciento, por lo que todavía hay que hacer ajustes para que se
pueda dar por asentada cada aseveración de cumplimiento.
Por ejemplo los procesos son hasta cierto punto manuales, la automatización
es indispensable en algunos casos para hacer más eficiente el proceso y aunque se
ha incluido al cliente en el proceso y se ha tratado de que los mecanismos
implementados lo mantengan informado de las acciones y la atención que se le
brindan, es de suma importancia que se le incluya de manera más activa y este
retroalimente con su percepción externa al proceso. No puede haber mejoras
substanciales al mismo si no se toma en cuenta esto último.

(176)
Por lo que el enfoque en la siguiente revisión se centrará en que los servicios
se sustenten completamente en la satisfacción final del cliente.

(177)
CONCLUSIONES
Del proyecto
El planteamiento fundamental de este trabajo de tesis era buscar un
mecanismo para implementar una forma de administración de tecnologías de
información que entregará mayor valor a la organización, enfocándose más al
servicio y a los clientes que a las propias tecnologías. Este planteamiento surge
debido a la problemática que se observa en un área específica que administra
tecnologías de este tipo para la CFE (Comisión federal de electricidad), donde los
métodos de trabajo se llevaban en base al “mejor esfuerzo”.
Ello motivó la siguiente interrogante:
¿Cómo se puede mejorar la gestión de los recursos o infraestructura de TI en un
entorno de eficiencia de tal forma que al mismo tiempo se pueda mantener al
cliente permanentemente informado de todo el proceso?
Esta interrogante se pretendía contestar mediante el uso de las mejores
prácticas que existen a este respecto, descritas en la documentación denominada
ITIL, pero esta documentación describe solo “el qué hay que hacer” y no “el cómo”.
En la mayoría de los casos constituye un problema para su adopción y puesta en
marcha.
A lo largo de este documento se describió como a través de diferentes
disciplinas y el seguimiento de un método, que consistió en ir del análisis previo de
la forma de trabajo que se realizaba, denotando sus deficiencias, hasta la corrección
de las mismas mediante la adaptación de la propuesta que ITIL hace, usando las
características que apuntan a realizar el trabajo con mayor eficiencia pero dando
más valor, tomando en cuenta en todo momento quién es el depositario de los
servicios que se entregan, el cliente.

(178)
Se mostró una forma de implementación que incluía en involucramiento de
todo el personal, para lograr el éxito deseado. Además de que se logró reflejar que
el uso de indicadores de medición ayudan de manera significativa a los procesos y
son el mecanismo de control para la mejora continua.
Tomando en cuenta los resultados expresados con anterioridad y aunque los
mismos no representan un cambio radical en la forma de trabajo y todavía quedan
actividades pendientes con la implementación completa de la primera revisión de los
procesos diseñados, podemos concluir que la propuesta de solución planteada
cumple con los objetivos establecidos.
El método ayudo a abordar los procesos de ITIL de forma ordenada,
comenzando por los más apropiados, mostrando primero las deficiencias y áreas de
oportunidad, permitiendo evaluar los resultados de acuerdo a su grado de madurez.
Cada proceso diseñado comenzó a enfocarse en proveer un servicio eficiente y a
incluir al cliente, dándole visibilidad de lo que está pasando, aunque no es al ciento
por ciento, se dirigen hacia allá.
Otro aspecto a resaltar es que toda vez que se empezó a ordenar el método
de trabajo y que existe más coherencia tanto en la información como en su manejo,
como resultado, los entregables o salidas del proceso o procesos, son más útiles y
la percepción del resto de la organización con respecto de esta área ha cambiado,
además de que ha estado forzando a otras áreas a tratar de cambiar, dado que los
procesos implementados requieren entradas de información bien estructuradas y
con formatos que incluyen información más puntual para garantizar la mejor
atención.
Derivado de esto, dos áreas más de la organización que se relacionan con la
administración de tecnología a otro nivel, en específico con las aplicaciones y no
tanto con la infraestructura, se han visto forzadas a ordenarse debido a la relación
tan estrecha que hay con la organización objeto de este trabajo, por lo que han

(179)
decido comenzar a trabajar en aplicar el mismo método usado para esta área y
rediseñar su forma de trabajo (procesos). El que existiera un método para la
adopción de los procesos de ITIL en toda la organización era uno de los fines
principales de este trabajo.
En conclusión y contestando la interrogante planteada, si es posible mejorar
la gestión de servicios de TI de una forma eficiente y enfocados al mismo tiempo en
las necesidades del cliente. Este trabajo constituye una de las muchas formas que
probablemente pueden diseñarse para ese propósito.
Profesionales
Todo cambio supone y exige un esfuerzo, no solo por el esfuerzo que habrá
que realizar per se, si no en la forma de pensar y en la capacidad de adopción para
dicho cambio. Es de esperarse que dicho cambio represente evolución, para que
tenga valor.
Este proyecto en particular y en general todo el contenido de la maestría, ha
representado para mí y mi vida profesional esa evolución, marcada por el
crecimiento en la perspectiva para resolver los problemas que se presentan en el
ámbito laboral.
Cuando se trabaja en áreas de naturaleza técnica, es muy común que se
pierda la visión de que se trabaja para colaborar con los objetivos de toda la
organización y los esfuerzos que se realizan se focalizan en resolver solo problemas
específicos y valga la redundancia, técnicos o tecnológicos.
El conocer y profundizar en otras áreas de conocimiento, tanto en el
desarrollo de cada materia y los trabajos presentados para aprobar cada una, como
toda la investigación realizada para la integración y conclusión de este trabajo,
cambiaron mi criterio, mi sensibilidad y ampliaron mi panorama, haciendo que

(180)
comenzara a buscar soluciones aplicables a mi entorno de trabajo que tendieran a
mejorar las condiciones en las que me desempeño y que tratará de compartirlas y
permearlas hacia el personal que tengo como responsabilidad a mi cargo.
Me ayudó a entender la importancia del liderazgo, y lo importante que es
para la organización que quién lo ejerce, tiene que tener una visión más extensa,
capaz de transmitirla hacia las persona a su cargo e invitarlos a compartirla.
Me dio herramientas para realizar los cambios necesarios que antes no se
habían podido realizar por esa recortada posibilidad de opciones, basada solo en el
pensamiento técnico.
Todo ello me ha abierto las puertas para colaborar en proyectos más
trascendentales y dejar un poco de lado el proceso solo operativo y técnico, para
apoyar procesos más estratégicos para la organización.
Personales
No es posible que cambios que uno sufre en un aspecto de la vida puedan
ignorarse y no se vean reflejados en otros, ya que nos constituimos como un todo.
Sobre todo cuando estos representan un crecimiento. Para mí la maestría ha
representado el crecimiento laboral que me ha llevado a salir de un estado
monótono y aportar más a la organización.
Me ayudo a abrir mi visión y tener un plan más amplio para mi carrera
profesional, lo que me da más alicientes para el futuro.
De igual forma, muchos de los conocimientos adquiridos, me han ayudado a
estructurar más mi vida personal, y sobre todo, lograr implantar mecanismos más
eficientes para desarrollar mi trabajo, teniendo como consecuencia que logrará
equilibrar el trabajo con mi vida personal y familiar.

(181)
REFERENCIAS BIBLIOGRÁFICAS
1) Sallé, Mathias (2004); ‘IT Service Management end IT Governance:
review, comparative analysis and their impact on Utility Computing’, HP
Laboratories, Palo Alto, CA.
2) Sara Ortiz Cantú, Andrés Ruiz Sahagún, Oscar Fernández Larios, Víctor
Ortega Guzmán (2010), ITIL (Information Technology Infrastructure
Library) como Medio para Mejorar la Eficacia de los Servicios de TI. Un
caso de estudio. Ponencia escrita para el V Congreso Internacional de
Sistemas de Innovación para la Competitividad 2010 (SinncO 2010)
Universidad de Guanajuato, Campus Celaya 25, 26 y 27 de Agosto de
2010.
3) MARQUIS, Hank (2006); ‘A PRESCRIPTION FOR ITIL’, Revista
electronica “DITY™ NEWSLETTER”, IT Experience. Practical Solutions.
VOL. 2.11 MAR. 15, 2006 Liga:
http://www.itsmsolutions.com/newsletters/DITYvol2iss11.htm
4) Michael Brenner (2006), Classifying ITIL Processes A Taxonomy under
Tool Support Aspects, Munich Network Management Team, University
of Munich (LMU)
5) Maria Mvungi and Ian Jay (2010), Knowledge Management Model for
Information Technology Support Service, University of Cape Town,
South Africa. Electronic Journal of Knowledge Management Volume 7
Issue 3, (353 - 366). http://www.ejkm.com
6) Senge, Peter M. “La Quinta Disciplina. El arte y la práctica de la
organización abierta al aprendizaje”, Ed. Garnica, México, D.F., 1998.
Apuntes de Sara Ortiz Cantú.
7) Building the Knowledge-Based Organization: How Culture Drives
Knowledge Behaviors, David De Long, May 1997
8) What is a Knowledge Management Project? By David De Long, Tom
Davenport & Mike Beers.
9) Apuntes De Gestión Del Conocimiento Autores: Mtra. Sara Ortiz Cantú
Y Mtro. Andrés Ruiz Sahagún, Guadalajara, Jalisco. Octubre De 2009

(182)
10) ABPMP - Guide to the Bussines Process Management common
Body of Knowledge (BPM CBOK) Version 2.0 - Second Release, © 2009
11) Business Process Management, Practical Guidelines to Successful
Implementations - John Jeston and Johan Nelis - Second Edition©
2008
12) ITIL® Maturity Model and Self-assessment Service: user guide,
Autores: Colin Rudd (IT Enterprise Management Services Ltd (ITEMS)),
John Sansbury (Infrassistance), Editorial board Graham Bosman (P5),
Lucy de Best (TSO), Ian Fik (TSO) and Phil Hearsum (AXELOS),
Octubre de 2013
13) ITIL Process Assessment Framework, Ian MacDonald FBCS CITP
FISM, Senior IT Specialist, The Co-operative Financial Services, August
2010
14) Biblioteca de Infraestructura de Tecnologías de la Información
(ITIL®) V3

(183)
ANEXOS
Índice de anexos
1 Ejemplo de plantilla para equipos de cómputo para registro en la
CMDB
184
1-A Ejemplo de plantilla para equipos de cómputo para registro en la
CMDB
185
2 Ejemplo de definición de umbrales para el monitoreo gestión de
eventos
186
2-A Ejemplo de definición de umbrales para el monitoreo gestión de
eventos
187
3 Ejemplo de bitácora de eventos e incidencias 188
3-A Ejemplo de seguimiento de incidente mediante la bitácora de
eventos e incidentes
189
4 Ejemplo de graficas de medición para el registro y la atención de
190
5 Tabla de archivos anexos 191

(184)
Anexo 1 – Ejemplo de plantilla para equipos de cómputo para registro en la
CMDB
Plantilla de Atributos Generales Hardware de Cómputo - COG
Atributo
Código del CI
Descripción del CI
Categoría
Tipo
Marca
Modelo
Número de serie
Origen/Proveedor
Fecha de provisión
Fecha de Aceptación
No.de Contrato
Fecha de Expiración
de garantía/Contrato
Contacto para soporte
Nombre
Puesto
Teléfono/Ext.
Fecha de asignación
de responsabilidad
Número de Activo
Nùmero de Versión
Ubicación general
Ubicación específica
Servicio
Dominio de
Infraestructura de
servicio (SID)
OLA Asociado
Nivel de Criticidad
RFCs
Cambios
Problemas
Incidentes
Documentación
Comentarios
Estados
Estado Actual
Estado programado
Fecha para estado
programado
Evento para estado
programado
Dato
Propietario
responsable
Dato

(185)
Anexo 1-A – Ejemplo de plantilla para equipos de cómputo para registro en la CMDB
Plantilla de Atributos Especificos Servidores de Rango-Alto - COG
Dato
Alto
Ancho
Fondo
No. Maximo
Instaladas
Voltaje de Entrada
Corriente de Entrada
Potencia
Tipo de contacto eléctrico
No. de procesadores (Max)
No. de procesadores Instalados
Arquitectura
Familia Velocidad Cache L1 Cache L2
Altitud
Emisión de calor
Peso (kg)
Fuentes de Poder
Micro-Procesadores
Procesamiento
Atributo
No Fantrays
Temperatuta de operacion
Humedad Relativa
Dimensiones

(186)
Anexo 2 – Ejemplo de definición de umbrales para el monitoreo gestión de eventos
Acciones en base a valores de criticidad
Grupo
Menor Mayor Critico Acción
Clave de Área a
Notificar Acción
Clave de Área a
Notificar Acción
Clave de Área a
Notificar
ERPDBPR1 70% 80% 90% Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO, BD, R3 Envió de alerta vía SMS a Telefonos SO, BD, R3
ERPCIPR1 70% 80% 90% Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO,R3 Envió de alerta vía SMS a Telefonos SO,R3
ERPAPP01 70% 90% 95% Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO,R3 Envió de alerta vía SMS a Telefonos SO,R3
QMSAPPRD 70% 80% 90% Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO,R3 Envió de alerta vía SMS a Telefonos SO,R3
ERPDBERD 70% 80% 90% Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO, BD, R3 Envió de alerta vía SMS a Telefonos SO, BD, R3
ERPCIERD 70% 80% 90% Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO,R3 Envió de alerta vía SMS a Telefonos SO,R3
ERPDBERT 70% 80% 90% Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO, BD, R3 Envió de alerta vía SMS a Telefonos SO, BD, R3
ERPCIERT 70% 80% 90% Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO,R3 Envió de alerta vía SMS a Telefonos SO,R3
ERPDBCL1 70% 80% 90% Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO, BD, R3 Envió de alerta vía SMS a Telefonos SO, BD, R3
ERPCICL1 70% 80% 90% Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO,R3 Envió de alerta vía SMS a Telefonos SO,R3
ERPDCPR1 70% 80% 90% Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO, BD, R3 Envió de alerta vía SMS a Telefonos SO, BD, R3
Grupo
Clave de Área a
Notificar Acción
Clave de Área a
Notificar Acción
Clave de Área a
Notificar
30% 20% 10% Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO, BD, R3 Envió de alerta vía SMS a Telefonos SO, BD, R3
30% 20% 10% Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO,R3 Envió de alerta vía SMS a Telefonos SO,R3
Grupo
Clave de Área a
Notificar Acción
Clave de Área a
Notificar Acción
Clave de Área a
Notificar
> 200 > 300 > 500 Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO, BD, R3 Envió de alerta vía SMS a Telefonos SO, BD, R3
> 200 > 300 > 500 Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO,R3 Envió de alerta vía SMS a Telefonos SO,R3
DRP Productivo
Real memory available for use by applications Menor
Critico
ERP Productivo
ERP Desarrollo
ERP Capacitación
ERP Calidad
% Utilización CPU Menor Mayor
ERP Calidad
DRP Productivo
Acceso a disco (IOS/Seg * TrasferSizeInBytes = BytesPerSec)
Mayor Critico
ERP Productivo
ERP Desarrollo
ERP Capacitación
Critico
ERP Productivo
ERP Desarrollo
ERP Capacitación
ERP Calidad
Num Of Read And Write MB per Second Menor Mayor
Linea Base - Utilización de CPU
Linea Base - Utilización de canal de acceso a discos
Linea Base - Utilización de Memoria
DRP Productivo

(187)
Anexo 2-A – Ejemplo de definición de umbrales para el monitoreo gestión de eventos
Grupo
Menor Mayor Critico Menor Mayor Critico Acción
Clave de Área a
Notificar Acción
Clave de Área a
Notificar Acción
Clave de Área a
Notificar
> 200,000,000 > 1,000,000,000 > 2,000,000,000 > 200,000,000 > 1,000,000,000 > 2,000,000,000 Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO, BD, R3 Envió de alerta vía SMS a Telefonos SO, BD, R3
> 200,000,000 > 1,000,000,000 > 2,000,000,000 > 200,000,000 > 1,000,000,000 > 2,000,000,000 Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO,R3 Envió de alerta vía SMS a Telefonos SO,R3
Disponibilidad Acciones en base a valores de criticidad
Grupo Ping
Critico Acción
Clave de Área a
Notificar Acción
Clave de Área a
Notificar Acción
Clave de Área a
Notificar
Sin Resp. De un minuto ( > 1 Min) Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO, BD, R3 Envió de alerta vía SMS a Telefonos SO, BD, R3
Sin Resp. De un minuto ( > 1 Min) Alerta en pantalla o notificación en consola Personal de operación Notificación por correo electronico y Ticket asignación para el área de SO SO,R3 Envió de alerta vía SMS a Telefonos SO,R3
Transmitted Bytes Rate per Second Menor
DRP Productivo
Critico
ERP Productivo
ERP Desarrollo
ERP Capacitación
ERP Calidad
Menor Mayor
Linea Base - Disponibilidad
Received Bytes Rate per Second
Linea Base - Utilización de Canal de Red
ERP Calidad
DRP Productivo
Mayor Critico
ERP Productivo
ERP Desarrollo
ERP Capacitación

(188)
Anexo 3 – Ejemplo de bitácora de eventos e incidencias

(189)
Anexo 3-A – Ejemplo de seguimiento de incidente mediante la bitácora de

(190)
Anexo 4 – Ejemplo de graficas de medición para el registro y la atención de eventos e incidentes

(191)
Anexo 5 - Tabla de archivos anexos
Descripción de archivo o
formato
Ruta o localización del archivo anexo a este documento
Ejemplo de formato de
entrevista inicial
AnexosCapitulo I1 – Ejemplo_Entrevista_Inicial.pdf
Ejemplo de matriz de roles
y responsabilidades
elaborada
AnexosCapitulo I2 – Matriz_de_Roles_y_Responsabilidades.pdf
Ejemplo de SIPOC
desarrollados
AnexosCapitulo I3 – Ejemplos_de_SIPOC.pdf
Diagrama de vista
Horizontal
AnexosCapitulo I4 – Diagrama_de_Vista_Horizontal.pdf
Diagrama de distribución
de documentos
AnexosCapitulo I5 – Diagrama_de_Distribucion_de_Documentos.pdf
Cuestionario de aplicación
para características del
modelo de madurez PMF -
ITIL
AnexosCapitulo I6 – Cuestionario_Caracteristicas_PMF.pdf
Mapa de arquitectura de
procesos propuesto
AnexosCapitulo II7 - Mapa_de_Arquitectura_de_procesos_ITIL.pdf
Diagrama de cadena de
valor elaborado
AnexosCapitulo II8 – Cadena_de_Valor_de_CFE_ASARE.pdf
Mapa de procesos de
gestión de la configuración
AnexosCapitulo II9 - Mapas_de_Proceso_de_Gestión_de_la_configuración.pdf
Mapa de procesos de
gestión de eventos
AnexosCapitulo II10 - Mapas_de_Proceso_de_Gestión_de_eventos.pdf
Mapa de procesos de
gestión de incidentes
AnexosCapitulo II11 - Mapas_de_Proceso_de_Gestión_de_Incidentes.pdf

(192)
ÍNDICE DE ILUSTRACIONES
Figura 1 - Relación de las áreas de conocimiento 15
Figura 2 - Evolución de la función de TI en las organizaciones 21
Tabla 1 - El PMF ITIL 26
Figura 3 – Áreas del conocimiento de BPM 31
Figura 4 - Objetos de Flujo y Objetos de Conexión BPMN 37
Tabla 2 – Descripción de eventos BPMN 38
Tabla 3 – Descripción de actividades BPMN 39
Tabla 4 – Descripción de Compuertas control de lujo BPMN 41
Figura 5 – Carriles de cado y artefactos BPMN 41
Tabla 6 – Descripción de carriles de cado BPMN 42
Tabla 7 – Descripción de artefactos BPMN 43
Figura 6 – Ejemplos de Diagramas de Procesos de Negocios en BPMN 43
Figura 7 Solución de Problemas del Negocio y el ciclo de vida de conocimiento 45
Figura 8 - Estrategia metodológica 50
Figura 9 – Cuestionario aplicado en entrevista inicial 58
Figura 9-A – Cuestionario aplicado en entrevista inicial 59
Figura 10 – Organigrama de la organización 60
Figura 11 – Ejemplo de Matriz de roles y responsabilidades 61
Figura 12 - Ejemplo de SIPOC 63
Figura 13 - Diagrama de vista horizontal del proyecto 65
Figura 14 - Mapa de distribución de documentos 67
Figura 15 – Cuestionario sobre características de los niveles de madurez en
procesos de ITIL 80
Figura 15-A – Cuestionario sobre características de los niveles de madurez en
procesos de ITIL 81
Figura 15-B – Cuestionario sobre características de los niveles de madurez en
procesos de ITIL 82

(193)
Figura 15-C – Cuestionario sobre características de los niveles de madurez en
procesos de ITIL 83
Figura 16 – Modelo de ITIL basado en Entrega de servicio y Soporte de servicio 87
Figura 17 - Mapa de arquitectura de procesos propuesta 89
Figura 18 – Diagrama de análisis de cadena de valor para la organización 92
Figura 19 – Disposición de repositorio único para información de la infraestructura -
CMDB 101
Figura 20 – Descripción de proceso de gestión de la configuración 106
Figura 21 – Descripción de subproceso de adquisición de nuevos elementos de
configuración CIs 108
Figura 22 – Descripción de subproceso de actualización de Información de
proveedores 110
Figura 23 – Descripción de subproceso de registro de nuevos CI 112
Figura 24 – Descripción de subproceso de actualización de información de CI 114
Figura 25 – Descripción de subproceso de registro y actualización de información de
contratos y licencias 116
Tabla 10 – Roles y responsabilidades del proceso de gestión de la configuración 118
Tabla 11 – Descripción KPIs del proceso de gestión de la configuración 119
Figura 26 – Descripción del proceso de Gestión de Eventos 126
Figura 27 – Descripción de Subproceso de manejo de eventos 128
Figura 28 – Descripción de Subproceso de evaluación de eventos 130
Figura 29 – Descripción de Subproceso de evaluación del proceso de gestión de
eventos 132
Tabla 12 – Descripción de roles y responsabilidades del proceso de gestión de
eventos 134
Tabla 13 – Descripción KPIs del proceso de gestión de eventos 134
Figura 30 – Descripción de proceso de gestión de Incidentes 142
Figura 31 – Descripción de subproceso de registro de solicitud de Incidentes 144
Figura 32 – Descripción de subproceso de asignación de solicitudes de Incidentes
146

(194)
Figura 33 – Descripción de subproceso de seguimiento de solicitudes de Incidentes
148
Figura 34 – Descripción de subproceso de Solicitud de incidente resuelta por un
especialista 150
Figura 35 – Descripción de subproceso de escalación de incidente 152
Figura 36 – Descripción de subproceso de Cierre de solicitud de incidente 154
Figura 37 – Descripción de subproceso de aprobación de solución de incidente 156
Tabla 14 - Descripción de categorías de incidentes del proceso de gestión de
Incidentes 157
Tabla 15 - Descripción de roles y responsabilidades del proceso de gestión de
Incidentes 159
Tabla 16 - Descripción de KPIs del proceso de gestión de Incidentes 160
procesos de ITIL – Aplicado al proceso de Gestión de la Configuración 172
procesos de ITIL – Aplicado al proceso de Gestión de Eventos 173
procesos de ITIL – Aplicado al proceso de Gestión de Incidentes 174

(195)
GLOSARIO DE TÉRMINOS
Término Significado
ASARE Administración de Soluciones, Aplicaciones y Resultados
BPM Bussines Process Management
BPMN Bussines Process Management Notation
BSC Balanced Scorecard
CFE Comisión Federal de Electricidad
CI Configuration Item
CMDB Configuration Management Database
CMM Capability Maturity Model
COBIT Control Objectives for Information and related Technology
DHS Definitive Hardware Store
DRP Disaster Recovery Plan
DSL Definitive Software Library
ITIL Information Technology Index Library
ITIM Information Technology Infrastructure Management
ITSM Information Technology Service Management
KM Knowledge Management
KPI Key Process Indicator
OOSR Oficina de Operación de Soluciones Remota
PMF Process Maturity Framework
SAP Systems, Applications, Products in Data Processing.
SIPOC Supplier Inputs Process Outputs Customers
SLA Service Level Agreement
TI Tecnologías de Información
TIC Tecnologías de la Información y las comunicaciones

Tog guillermo uribe

Más contenido relacionado

La actualidad más candente (20)

Similar a Tog guillermo uribe (20)

Último (20)

Tog guillermo uribe