INSTITUTO POLITÉCNICO NACIONAL

INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE
INGENIERÍA Y CIENCIAS SOCIALES Y
ADMINISTRATIVAS
SECCIÓN DE ESTUDIOS DE POSTGRADO E INVESTIGACIÓN
“PROPUESTA METODOLÓGICA PARA LA
IMPLEMENTACIÓN DE LOS PRINCIPALES SERVICIOS
DE TECNOLOGÍAS DE INFORMACIÓN EN UNA
ASEGURADORA DENTAL”
T
E
S
I
S
QUE PARA OBTENER EL GRADO DE:
MAESTRO EN ADMINISTRACIÓN
P R E S E N T A
MENDOZA DE LA MADRID EDUARDO ANTONIO
DIRECTOR: Mtra. ELIZABETH ACOSTA GONZAGA
MÉXICO D.F.
2014
ÍNDICE
ÍNDICE
RESUMEN
I
SUMMARY
I
INTRODUCCIÓN
II
GLOSARIO DE TÉRMINOS
V
ABREVIACIONES
VII
CAPITULO 1. SITUACIÓN ACTUAL Y ANÁLISIS DEL NEGOCIO
1.1
La Empresa
1.1.1 Antecedentes e historia
9
9
1.1.2 Estructura organizacional
14
1.1.3 Mercado y competidores
16
1.2
Infraestructura tecnológica
20
1.2.1 Plataforma de Software
21
1.2.2 Hardware
22
1.2.3 Comunicaciones
23
1.2.4 Servicios
24
1.3
Planes de crecimiento y análisis del negocio
24
1.3.1 Debilidades
25
1.3.2 Oportunidades
26
1.3.3 Fortalezas
26
1.3.4 Amenazas
26
1.4
Problemática: Algunas posibles soluciones
27
CAPITULO 2. MARCO CONCEPTUAL: TENDENCIAS TECNOLÓGICAS EN
EL CONTROL DEL ÁREA DE TI
2.1
Tendencias tecnológicas en el control del área de TI (Servicios
Tecnológicos)
28
2.1.1 Características de los servicios tecnológicos
29
2.1.2 Generación un servicio tecnológico
29
2.1.3 Clasificación y tipos de servicios tecnológicos
31
2.1.4 Adquisición de los servicios tecnológicos
32
ÍNDICE
2.2
Metodologías basadas en las mejores prácticas
2.2.1 Administración en el departamento de TI
2.2.2 COBIT (Control Objectives for Information and related
Technology)
32
33
34
2.2.2.1
Requerimientos de Cobit
37
2.2.2.2
Recursos de TI
38
2.2.2.3
Componentes esenciales de COBIT
39
2.2.2.4
Planear y organizar (PO)
40
2.2.2.5
Adquirir e implementar (AI)
41
2.2.2.6
Entregar y dar soporte (DS)
42
2.2.2.7
Monitorear y evaluar (ME)
43
2.2.3 ITIL
44
2.2.3.1
Historia de ITIL
45
2.2.3.2
Estructura de ITIL
46
2.2.3.3
Concepto de 4 P’s
49
2.2.3.4
Funciones, procesos y roles
51
2.2.3.5
Matriz RACI
52
2.2.3.6
Mejores prácticas en la administración de servicios de
TI
2.2.3.7
2.3
Mejora continua del servicio y circulo de Deming
Cobit e ITIL, Alineando objetivos
53
54
56
CAPITULO 3. PROPUESTA METODOLÓGICA Y DISEÑO PARA LA
IMPLEMENTACIÓN EN EL ÁREA DE TI
3.1
Plan metodológico
60
3.1.1 Visión general de la situación
60
3.1.2 Selección de la metodología
61
3.1.3 Delimitación del problema
63
3.2
Soporte del servicio
64
3.2.1 Punto único de recepción de casos
64
3.2.2 Gestión de incidencias
65
3.2.3 Gestión de problemas
66
3.2.4 Gestión de cambios
64
ÍNDICE
3.3
Entrega de servicio
67
3.4
Base de datos relacional
68
3.5
Mejora continua
69
3.6
Plan de implementación
69
CAPITULO 4. IMPLEMENTACIÓN DE LA METODOLOGÍA: ENTREGA Y
SOPORTE DEL SERVICIO
4.1
Herramienta para Soporte del Servicio
71
4.1.1 Punto único de recepción de problemas (Service Desk)
71
4.1.2 Diferentes estructuras de Service Desk
73
4.1.3 Propuesta de Service Desk
77
4.1.4 Aplicación utilizada en el Service Desk
82
4.2
Gestión de incidencias
4.2.1 Proceso de gestión de incidencias
86
87
4.2.2 Apertura de incidencias
107
4.2.3 Resolución de incidencias
108
4.2.4 Niveles de soporte
109
4.3
Gestión de problemas
109
4.3.1 Relaciones entre incidencias y problemas
110
4.3.2 Descripción del sistema de gestión de problemas
111
4.4
Gestión de cambios
112
4.4.1 Análisis de soluciones
114
4.4.2 Definición del cambio
115
4.4.3 Petición del cambio
116
4.4.4 Acciones y pruebas
117
4.4.5 Implementación del cambio
118
4.5
Diseño inicial de la base de datos (CMDB)
119
4.5.1 Definición
119
4.5.2 Objetivos
119
4.5.3 Diseño conceptual
121
4.5.4 Ubicación y mantenimiento
121
4.6
Entrega de servicio (SLA)
122
4.7
Implementación de mejores prácticas
131
ÍNDICE
4.7.1 Estrategia del Servicio (Service Strategy)
142
4.7.2 Diseño del Servicio (Service Design)
143
4.7.3 Transición del Servicio (Service Transition)
144
4.7.4 Operación del Servicio (Service Operation)
145
4.7.5 Mejoramiento Continuo del Servicio (Continual Service
Improvement)
145
I.
Resultados
146
II.
Tendencias y comportamiento de las incidencias
146
III.
Tiempos de solución
152
IV.
Proyectos en el departamento de TI
160
V.
Evaluación de desempeño (RR)
162
Conclusiones
164
Referencias bibliográficas
171
Anexos
176
RESUMEN
RESUMEN
El presente trabajo muestra la incorporación de una metodología para ejercer control y
seguimiento sobre el departamento de tecnologías de la información dentro de una
aseguradora dental, mejor conocida como las “mejores prácticas”, esta metodología
nos da la posibilidad de no redescubrir hechos de la misma naturaleza que suceden en
otras organizaciones dentro de sus departamento de tecnología, sino más bien hacer
uso de experiencias previas e incorporarlas como parte de la organización misma.
Así mismo muestra un panorama de las principales actividades que se realizaron
dentro de la organización para lograr este objetivo y presentara las herramientas,
procesos e infraestructura organizacional que se utilizaron para este fin. Además
presenta una evaluación del primer trimestre de operaciones bajo esta metodología,
sus alcances, los resultados obtenidos hasta ese momento y en términos generales las
tendencias y el panorama que se observa para esta organización.
A lo largo de este trabajo se podrán observar los distintos momentos por los que pasa
la organización y los retos que tiene que sortear la alta dirección, la gerencia de TI y los
colaboradores del departamento de TI para conseguir un cambio sustancial en
prácticamente todos los niveles de la organización.
SUMMARY
This paper show the incorporation of a methodology to exercise control and monitoring
into the department of information technology within a dental insurer company, known
as "best practices", this methodology gives us the opportunity to do not rediscover facts
that happen in other organizations within their technology department, but rather make
use previous experiences and incorporate them as part of our organization.
Also show an overview of the main activities carried out within the organization to
achieve this goal and present the tools, processes and organizational infrastructure that
is used for this purpose. It also presents an evaluation of the first quarter of operations
under this methodology, its scope, the results obtained so far and the outlook is
observed for the insurer.
Throughout this work we can see the different stages through which it passes the
organization and the challenges it must overcome senior management, IT management
and employees of the IT department for a substantial change in almost all levels of the
organization.
I
INTRODUCCIÓN
INTRODUCCIÓN
Los grandes avances en el hardware, las distintas maneras de hacer más eficiente tal o
cual tecnología o el simple hecho de que exista una “mejor” computadora o algún
periférico todos los días, hace del estudio de la tecnología todo un reto para cualquier
individuo que pretenda saber lo “ultimo”, en estos términos.
Si bien, todo esto es difícil ubicar, las tendencias son una manera eficaz de conocer en
donde está y hacia dónde va el mundo de la tecnología, sin embargo ¿qué pasa
cuando la tecnología se conjuga con el ambiente social de cada empresa o de cada
individuo?, es decir; cuando interviene el carácter, la motivación o inclusive la forma de
ser (valores y principios) de aquellas personas que se encargan de resolver los
problemas referentes a este tema. En ese momento nos damos cuenta que la
tecnología deja de ser un “fenómeno” aislado y pasa a ser una herramienta para
conseguir uno o varios fines en una organización.
Así podemos entender a la tecnología como un medio y no como un fin dentro de las
organizaciones. Un medio que si bien tiene ciertas capacidades (por todos conocidos)
en algunas ocasiones parecería ser más ineficiente de lo que en realidad es.
El motivo de este trabajo es presentar y poner al descubierto esa delgada (y a veces
invisible) línea que existe entre la utilidad que obtengo de una computadora (y en
general toda la infraestructura tecnológica dentro de una organización) y el hecho de
que gracias a esa computadora yo pueda llevar a cabo los objetivos para los que fui
contratado en una organización.
Este trabajo presenta una propuesta metodológica de la implementación de los
principales servicios informáticos en una aseguradora dental, tomando como base una
metodología conocida, describiéndola en el transcurso de los capítulos y presentándola
de la siguiente manera:
En el capítulo 1 hablaremos de la situación actual de la empresa, su posición en el
mercado y sus principales indicadores para ubicarla de una manera objetiva y
dimensionar en el debido contexto el planteamiento del problema y la propuesta de
solución. Es importante mencionar que este capítulo es de suma importancia para la
justificación de la metodología ya que la base de la selección metodológica de esta
propuesta está basada en el análisis del negocio previsto en este capítulo.
En el capítulo 2 se presentaran los conceptos teóricos necesarios para la compresión
de los capítulos subsecuentes: las tendencias tecnológicas de control en el área de IT,
la importancia del uso de la aplicación de una metodología de estandarización, las
distintas metodologías para el control del área de IT, etc. Con esto se justifica el uso de
la metodología seleccionada.
En el capítulo 3 ya pondremos en marcha la propuesta de la metodología
seleccionada, es decir aquí hablaremos de la columna vertebral del área de IT y de la
manera de organizarla para poder otorgar respuestas y soluciones a los distintos
II
INTRODUCCIÓN
problemas con los que se enfrenta la organización. La entrega del servicio y el soporte
son los vértices principales para lograr esto, en este capítulo veremos cómo se
conforma cada uno, sus principales características, así como la manera en cómo se
relacionan entre sí para poder crear una sinergia completa dentro del área.
Por último en el capítulo 4 se presenta el plan para llevar a cabo esta tarea y se
propondrán los distintos esquemas, diagramas y se hablara de las decisiones tomadas
para la implementación de la metodología; además se generara la distinta
documentación necesaria para sustentar esta propuesta.
Justificación
En las empresas de hoy en día existe un gran conflicto llamado tecnología, y parecería
que muchas veces lejos de ayudarnos a resolver problemas relacionados con nuestro
negocio nos da cada vez más problemas, por esto un gran número de empresas están
implementando metodologías que permitan al área de IT ir de acuerdo con el negocio y
ya no más en su contra. La aplicación de las mejores prácticas en esta área trae
consigo una manera estandarizada de hacer las cosas, que si bien no quiere decir
necesariamente la “mejor manera” de hacerlas, esta será muy probablemente una
forma que se adapte al negocio y al crecimiento de la organización y que fluya junto
con ella.
En este trabajo encontrara una propuesta metodológica de cómo a través de servicios
informáticos podamos llevar este esquema a una empresa joven encargada de vender
seguros dentales y las distintas consideraciones a tomar en cuenta. Con esto
buscamos proporcionar un camino adecuado hacia la transición interna con el objeto
de obtener mejores resultados al momento de dar una solución informática a cada
problema.
Contexto
Las empresas como los organismos vivos van sufriendo transformaciones a lo largo de
su ciclo de vida, en algunos casos y para algunas empresas estos cambios son muy
lentos y requieren mucho menos esfuerzo para lograrlo que para otras, sin embargo la
globalización, los dispositivos móviles de comunicación, acceso a grandes fuentes de
interacción como las redes sociales y el vertiginoso cambio de la tecnología generan
distintos factores que influyen directamente en el desarrollo sustentable de las
organizaciones, estos los podemos englobar en dos grandes grupos:
 Dinámica en el mercado
 Expectativas de flexibilidad y respuesta inmediata por parte de los clientes
Objetivos

General: Proponer una metodología para la implantación de servicios
informáticos que sea capaz de especificar, regular y mantener los resultados de
las actividades del área de TI en una aseguradora dental.
III
INTRODUCCIÓN

Particulares:
o
o
o
o
Realizar una evaluación de la situación actual para vincular los puntos
de mejora con los procesos tecnológicos
Seleccionar, analizar y proponer una metodología para la implantación
de sus soluciones
Integrar un plan de trabajo detallado para la implementación de las
soluciones sugeridas
Implementar servicios específicos de acuerdo a las necesidades de la
organización
Métodos
Los métodos que se utilizaran para la generación de la propuesta se describen a
continuación:
1. Evaluación y análisis de la situación actual de la empresa: Ubicar las
circunstancias en las que se encuentra la empresa por medio de su estructura
organizacional, el impacto del mercado y sus competidores nos da un
panorama para visualizar las oportunidades que se podrían aprovechar;
minimizar sus debilidades y utilizar sus fortalezas para poder afrontar las
posibles amenazas por las que pudiera pasar la organización en términos de
apoyo a la operación a través de la tecnología
2. Selección de la metodología de manejo y entrega de servicios tecnológicos a
utilizarse. Considerando una de las metodologías mayormente aceptada por los
profesionales de TI (mejores prácticas), se recopila la información necesaria
para tener el marco de referencia que se utilizara durante la propuesta
3. Se llevara a cabo una analogía de los distintos procesos de la metodología para
adecuarlos de manera natural a los procesos actuales de la empresa. Se
consideraran las etapas de entrega y soporte del servicio tecnológico
4. Construcción de la propuesta de solución, indicando herramientas, procesos,
definiciones, políticas e implementación de las distintas etapas consideradas
dentro del marco de referencia
5. Realización de un plan de trabajo (tiempos y recursos) para llevar a cabo la
implementación. A través de la puesta en marcha y un extenso plan de
capacitación se da inicio a este nuevo esquema organiacional
6. Se realizan mediciones y comparaciones durante el primer trimestre de
operaciones con este programa. Se obtienen los resultados mismos que se
presentan y se analizan obteniendo así las conclusiones de este trabajo
IV
GLOSARIO DE TÉRMINOS
Glosario de Términos
Cloud Collaboration: Es una nueva manera emergente de compartir y generar
archivos de computadora a través del uso del Cloud Computing.
Cloud Computing (Computación en la nube): Es un paradigma que permite ofrecer
servicios de computación a través de Internet.
Coaching: Anglicismo que procede del verbo inglés “to coach”, (entrenar) es un
método que consiste en dirigir, instruir y entrenar a una persona o a un grupo de ellas,
con el objetivo de conseguir alguna meta o de desarrollar habilidades específicas.
Customer Relationship Management: Sistemas informáticos de apoyo a la gestión de
las relaciones con los clientes, a la venta y al marketing. Con este significado CRM se
refiere al sistema que administra un Data Warehouse (almacén de datos) con la
información de la gestión de ventas y de los clientes de la empresa.
Data Cloud: Servicio que ofrecen los proveedores de Cloud Computing para la
administración y mantenimiento de bases de datos que ponen al servicio de sus
clientes en un esquema Software como Servicio.
Data Warehouse (almacén de datos): Es una colección de datos orientada a un
determinado ámbito (empresa, organización, etc.), integrado, no volátil y variable en el
tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza.
Ofimática: Conjunto de técnicas, aplicaciones y herramientas informáticas que se
utilizan en funciones de oficina para optimizar, automatizar y mejorar los
procedimientos o tareas relacionadas
RACI, Matriz (Matriz de Asignación de Responsabilidades): Se utiliza generalmente en
la gestión de proyectos para relacionar actividades con recursos (individuos o equipos
de trabajo). De esta manera se logra asegurar que cada uno de los componentes del
alcance esté asignado a un individuo o a un equipo.
Sales Cloud: Es un concepto de software en la nube que pone al alcance de la mano
del cliente sus cuentas, contactos sociales y herramientas de colaboración para
finalizar negociaciones más rápidamente.
Service Cloud: Concepto asociado al software como servicio (SaaS) en donde la
atención al cliente se realiza a través de internet.
Siniestralidad: Frecuencia o índice de siniestros que se producen en un lugar o
situación.
Software como Servicio (Software as a Service : SaaS): Es un modelo de distribución
de software donde el soporte lógico y los datos que maneja se alojan en servidores de
V
GLOSARIO DE TÉRMINOS
una compañía de tecnologías de información y comunicación (TIC), a los que se
accede con un navegador web desde un cliente, a través de Internet.
TIER I, II, III: Jerarquías de niveles de servicios, siendo el I el más bajo o simple y el III
el más especializado.
Virtual Private Network: Es una tecnología de red que permite una extensión de la red
local sobre una red pública o no controlada, como por ejemplo Internet.
Work Around: Una solución alternativa se define en Informática como un método
temporal para alcanzar una solución cuando el camino tradicional no funciona. En
informática se usa para superar inconvenientes de programación, hardware o
comunicación.
VI
ABREVIACIONES
Abreviaciones
AICPA:
American Institute of Certified Public Accountants
CNSF:
Comisión Nacional de Seguros y Fianzas
COBIT:
Control Objectives for Information and related Technology
COSO:
Committee of Sponsoring Organizations of the Treadway Commission
CRM:
Customer Relationship Management
FAQ:
Frequently Asked Questions
IFAC:
International Federation of Automatic Control
IIA:
Institute of Internal Auditors
ISACA:
Information System Audit and Control Association
ISES:
Institución de Seguros Especializada en Salud
ITGI:
Information Technology Governance Institute
ITIL:
Information Technology Infrastructure Library
ITSM:
Information Technology Service Management
PDCA:
Plan, Do, Check, Act
PMI:
Project Management Institute
RACI:
Responsible, Accountable, Consulted, Informed
RR:
Resolution Rate
SaaS:
Software as a Service
SHCP:
Secretaria de Hacienda y Crédito Público
SLA:
Service Level Agreement
SLM:
Service Level Management
SUGEF:
Superintendencia General de Entidades Financieras (País: Costa Rica)
VII
ABREVIACIONES
STS:
Solicitud de Trabajo a Sistemas
TI:
Tecnologías de la Información
UPS:
Uninterruptible Power Supply
VPN:
Virtual Private Network
VIII
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
CAPÍTULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
En este capítulo revisaremos la situación de la empresa así como sus orígenes,
además revisaremos los conceptos necesarios de tecnología y terminología que
utilizaremos durante este trabajo.
Con estos conceptos tendremos elementos claves que nos ayudaran a comprender la
propuesta que aquí se presenta, estos conceptos son: metodologías, conceptos, tipos
de servicios, etc.
1.1
La Empresa
A continuación presentaremos las principales características de la empresa, su
estructura organizacional, el modelo de negocio, mercado y competidores.
1.1.1 Antecedentes e historia
La empresa Seguros Dentales Dentegra S.A. nació en el año 2007 como una
Institución de Seguros Especializada en Salud (ISES), con el objetivo de proveer al
mercado mexicano con servicios en el sector asegurador dental, utilizando la ventaja
competitiva del uso de tecnología especializada con respecto al resto del sector y
apoyándose en toda la experiencia de su principal accionista y guía. Una empresa
aseguradora dental en los Estados Unidos de Norteamérica que fue fundada por
grupos de dentistas hace 50 años y que actualmente lleva cuidados dentales a más 24
millones de asegurados por medio de 24,000 clientes y a través de una red de más de
60,000 dentistas. (Dentegra Seguros Dentales, 2007)
Figura 1. Logo Dentegra. (Dentegra Seguros Dentales, 2007)
Uno de los principales objetivos de Dentegra es estar a la vanguardia en la industria
aseguradora de México como una especialista en seguros dentales poniendo al
9
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
alcance de los asegurados programas innovadores para mejorar su salud dental y
fomentar el uso y acceso a todos los servicios dentales en la población.
Además busca desarrollar un alto desempeño en actividades tales como:




La atención al cliente
Formación y mantenimiento a la red de dentistas
Procesamiento y pago de siniestros (reclamaciones)
Entrega oportuna de información (reportes)
Servicios que ofrece Dentegra
Dentegra como una ISES está regulada y auditada periódicamente por la Comisión
Nacional de Seguros y Fianzas (CNSF) una dependencia desconcentrada de la
Secretaria de Hacienda y Crédito Público (SHCP) encargada de supervisar la
operación de los sectores asegurador y afianzador a través del apego normativo, el
monitoreo de la solvencia económica y la estabilidad financiera de las instituciones de
seguros y fianzas.
Por esta razón todos y cada uno de los servicios que ofrece Dentegra están validados
y certificados por dicha autoridad, esto con la finalidad de generar en los asegurados
una estrecha relación de confianza y dar a los clientes (empresas que contratan el
seguro dental para sus empleados) la certeza de que los beneficios que otorga a sus
empleados son de la mejor calidad y con alto nivel de confianza.
Con todo esto Dentegra está autorizada para comercializar los seguros en el ramo de
Accidente y Enfermedades con los subramos: Salud y Gastos Médicos tanto en grupo
como en colectivo. Para estos ramos y subramos tiene dos productos principales:
dental y visión.
En el producto Dental los beneficios que proporciona Dentegra son:









Diagnóstico y prevención
Restaurativo básico
Procedimientos quirúrgicos menores
Restaurativo
Correctivo básico estándar
Endodoncia
Periodoncia
Coronas y prostodoncia
Remoción de terceros molares
10
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
Y para el producto Visión los beneficios están dados en niveles del 1 al 5. Estos niveles
hacen referencia al tipo de lente o de armazón a los que tiene derecho el asegurado.
Otro de los servicios agregados que ofrece Dentegra son planes para aquellos
asegurados que previamente hayan adquirido un seguro de gastos médicos mayores
con alguna de las diferentes aseguradoras con las que trabaja Dentegra en el país, con
la finalidad de proporcionar una red más amplia de dentistas a los asegurados y hacer
asequibles todos los productos para la salud dental.
Por otro lado sin que aún se haya comercializado aun, el seguro Dental Individual es
uno de los propósitos de Dentegra a un mediano plazo, aquí se menciona porque este
seguro puede incrementar de manera exponencial el volumen de asegurados y será de
gran ayuda para la planificación de la entrega y soporte al servicio, mismos que se
hablaran más delante de ellos.
Para cada cliente (póliza emitida) Dentegra tiene el compromiso de realizar una serie
de actividades asociadas con el servicio post-venta de cada póliza, todo esto con el
afán de incrementar el valor agregado que ofrece a sus clientes, dentro de esta gama
de posibilidades las principales son:
1. Esquemas de reporteo de información que se entrega de manera regular según
el cliente lo solicite (mensual, trimestral, semestral o anual)




Reporte de primas vs. siniestralidad
Siniestralidad por tipo de asegurado (titular, cónyuge, hijos y otros)
Siniestralidad por tipo de cobertura (prevención, endodoncia,
procedimientos quirúrgicos, etc.)
Reportes de contención de costos por cliente
2. Consulta de información y estatus de los servicios dentales en línea, estos
servicios son otorgados tanto a clientes finales (asegurados) como a
proveedores (dentistas asociados a la red Dentegra), esto con el fin de que los
dentistas en la red también gocen de los beneficios de pertenecer a Dentegra






Consulta de dentistas a nivel nacional
Agenda de citas
Listado de asegurados que tienen acceso al seguro (elegibilidad)
Estatus de rechazo/pago de procedimientos realizados
Cobros realizados por el dentista al asegurado por concepto de
deducibles o copagos
Consulta de limites anuales y saldos
11
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
A continuación se presenta una relación de los distintos planes que ofrece Dentegra:
Figura 2. Planes dentales ofrecidos por Dentegra (Dentegra Seguros Dentales, 2007)
12
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
Canales de interacción con los clientes
Como una institución financiera Dentegra se alinea y trabaja de manera conjunta con
los principales agentes de seguros a nivel nacional para comercializar sus productos
como lo son:




















Aon Risk Services Agente De Seguros Y De Fianzas, S.A. De C.V.
Marsh Brockman y Schuh Agente de Seguros y de Fianzas S.A. de C.V.
Willis Agente de Seguros y de Fianzas, S.A. de C.V.
Hewitt Associates S.C.
Lockton Consultores Actuariales Agente de Seguros y de Fianzas S.A. de C.V.
Interprotección Agente de Seguros y de Fianzas, S.A. de C.V.
Prevex Agente de Seguros y de Fianzas, S.A. de C.V.
Interesse Agente de Seguros y de Fianzas S.A. de C.V.
Protección Técnica Interconsult Agente de Seguros y Fianzas S.A. de C.V.
Álamo Agente de Seguros y de Fianzas, S.A. de C.V.
Consultores Integrales Agente de Seguros S.A. de C.V.
Protección Técnica Internacional Agente de Seguros y Fianzas
Crg Agente De Seguros y de Fianzas S.A. de C.V.
Lorant Martínez Salas y Compañía, Agente de Seguros y Fianzas, S.A. de C.V.
Copse Agente de Seguros y De Fianzas, S.A. de C.V.
Grupo Sr Agente de Seguros, S.A. de C.V.
Fem, Agente de Seguros y de Fianzas S.A. de C.V.
Servicios Asegurables, Agente de Seguros y de Fianzas, S.A. de C.V.
Marquard Y Asociados Agente de Seguros, S.A. de C.V.
Grupo Sekura, Agente de Seguros y de Fianzas, S.A. de C.V.
Si bien los agentes ayudan a la comercialización de los seguros dentales Dentegra
pone al servicio de sus asegurados un Centro de Contacto que da servicio 7 días a la
semana las 24 horas del día, y que se encarga de recibir llamadas telefónicas, correos
electrónicos, solicitudes vía web (página web de Dentegra) y soporta consultas de
emergencia otorgados por dentistas, además de esto pone a disposición el portal
personalizado para Dentistas y Asegurados donde se pueden consultar todos los
procedimientos realizados por el dentista al asegurado así como los pagos, importes y
fechas de aplicación, recepción y pago de los siniestros que se hayan reportado.
Todo esto acompañado por una intensiva campaña masiva en radio, televisión, medios
impresos y presencia en las diferentes salas expositoras en congresos y ferias
relacionadas con la salud dental, así Dentegra se pone al servicio de las principales
compañías que quieran adquirir sus productos como un beneficio más al trabajador.
13
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
Por último para otorgar servicios en el interior de la república Dentegra cuenta con una
fuerza de ventas especializada en sitio, para dar el servicio y soporte a la contratación
del seguro dental a los clientes alojados en el interior de la república.
1.1.2 Estructura organizacional
La forma en cómo está distribuido el trabajo, las actividades y las responsabilidades en
Dentegra, va directamente ligado al giro de la empresa. Dentegra está denominada
como una ISES y se regula en base a todos los reglamentos de una institución
financiera, como lo puede ser un banco, casa de bolsa o afianzadora.
Personal
Dentegra cuenta con una plantilla de 92 personas divididas por área operativa de la
siguiente manera: (Dentegra Seguros Dentales, 2006)
Finanzas: 7 empleados
Ventas y marketing: 10 empleados
Operaciones y siniestros: 44 empleados
Centro de Contacto: 11 empleados
Redes: 11 empleados
Dental: 6 empleados
Sistemas: 2 empleados
Dirección General: 1 empleado
Solo para hacer referencia, la distribución anterior nos indica que hay dos personas del
departamento de TI para dar soporte a todos los servicios requeridos por Dentegra
hasta este momento. Más adelante haremos mención del incremento de recursos
dentro del departamento derivado de la implementación de la metodología.
Infraestructura inmobiliaria
Actualmente Dentegra cuenta con 800 metros cuadrados en sus oficinas centrales
ubicadas al sur de la ciudad de México en el DF y tiene oficinas representativas en las
ciudades de Guadalajara, Monterrey y Ciudad Juárez. Donde se ofrece servicio a los
principales clientes en el norte del país.
14
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
Figura 3. Oficinas distribuidas en el país (Elaboracion propia, 2007)
Planes de crecimiento
No obstante y gracias a que el negocio de los seguros dentales en México es de muy
reciente ingreso, se tienen grandes expectativas para la incorporación de cada vez
más personas a este tipo de beneficios.
Es por eso que el crecimiento en pólizas, clientes y a su vez en la plantilla de recursos
humanos para ofrecer este tipo de servicios se tiene planificado en un ascenso
importante en por lo menos los próximos 5 años, después de eso el crecimiento será
discreto, más sin embargo no deja de extenderse.
De acuerdo a las proyecciones estimadas en el volumen de información se espera
tener una plantilla de 250 empleados en los próximos 10 años, esto significa un
crecimiento del 100% y los subsecuentes costos asociados, por ejemplo un espacio de
al menos 1500 metros cuadrados en un solo complejo o dividido en varias sucursales.
Estas cifran fueron tomadas del anteproyecto entregado a la CNSF en el año en que
Dentegra se consolido y obtuvo la autorización para operar como una Institución de
Seguros Especializada en Salud (Dentegra Seguros Dentales, 2006).
Lo cual implicaría la búsqueda de nuevas oficinas para albergar a todo el personal que
se incrementará hasta en un 100% en este mismo periodo, sin embargo para otorgar
un nivel servicio de TI adecuado se deberá de considerar este tipo de crecimiento y si
15
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
bien no proponer una solución para atacar este problema de momento, si hay que
considerar que la propuesta deberá ser lo suficientemente flexible para adecuarse a
este crecimiento.
1.1.3 Mercado y competidores
Las ISES están reguladas por CNSF y evidentemente esta organización que congrega
a todas las aseguradoras en el territorio nacional es la que marca las reglas de
mercado, competencia y funge como autoridad entre los clientes y las aseguradoras.
Es por eso que si bien el seguro dental en México es relativamente nuevo los
segmentos de mercados a los que está enfocado pueden ser analizados o englobados
en otros rubros tales como los servicios de hospital, farmacias, gabinetes, etc.
Para estos casos la salud dental está considerada en el rubro de Accidentes y
Enfermedades en la subdivisión de salud, mercado en el cual compiten las grandes
aseguradoras a nivel mundial y es la misma razón por la que vemos aseguradoras de
segundo y tercer piso en comparación real con las aseguradoras más comerciales.
En la siguiente grafica veremos el total del mercado asegurador en México evaluado a
través de la emisión de primas vs. las principales instituciones de seguros (CNSF,
Comisión Nacional de Seguros y Fianzas, 2010).
No hay que olvidar que los principales ramos en los que se divide el mercado
asegurador son:








Vida
Accidentes y Enfermedades
Daños sin autos
Autos
Salud
Pensiones
Garantía Financiera
Crédito a la vivienda
Con la intención de posicionar a Dentegra en el mercado que le corresponde es
necesario mencionar que se presentara únicamente el mercado correspondiente al
ramo de accidentes y enfermedades subdivisión Salud.
16
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
Mercado Asegurador en Mexico
$20,000,000.00
$18,000,000.00
$16,000,000.00
$14,000,000.00
$12,000,000.00
$10,000,000.00
$8,000,000.00
$6,000,000.00
$4,000,000.00
$2,000,000.00
$Metlife México
Grupo Nacional Provincial
AXA Seguros
Seguros BBVA Bancomer
Seguros Monterrey New York Life
Seguros Inbursa
Seguros Banamex
Quálitas, Cía. de Segs.
Mapfre Tepeyac
Pensiones BBVA Bancomer
Seguros Banorte Generali
ABA Seguros
Pensiones Banorte Generali
Seguros Atlas
Allianz México
Aseguradora Interacciones
AIG México Seguros Interamericana
Seguros Santander
Zurich Cía. de Segs.
ACE Seguros
HSBC Seguros
Seguros Argos
Grupo Mexicano de Seguros
Otros
Figura 4. Mercado Asegurador Mexicano (CNSF, Comisión Nacional de Seguros y Fianzas, 2010)
Nota: Las cifras que se presentan en la figura anterior se encuentran en miles de pesos.
Con esto nos podemos dar una idea más clara del porcentaje que ocupa Dentegra en
el mercado de seguros especializados en salud (ISES), no obstante esta información
aun no es precisa debido a que como se comentó anteriormente la salud dental no es
un mercado donde las grandes instituciones estén interesadas, es decir, su mercado
objetivo está orientado hacia los rubros de hospitales, gabinetes, etc. dejando un
amplio margen para aquellos que quieran abordar el mercado de la salud dental.
Entendamos el mercado de la salud dental como aquel nicho donde se conforma una
red de proveedores destinados a proporcionar servicios relacionados con la salud
dental, es decir, dentistas u odontólogos, clínicas dentales, centros donde se agrupan
dentistas y juntos ofrecen servicios de odontología, etc.
17
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
Seguro de Salud
Dentegra Seguros
Dentales
3%
Preventis
8%
SaludCoop México
1%
Seguros Centauro, Salud
Especializada
3%
Vitamédica
0%
Allianz México
0%
Salud Inbursa
0%
Plan Seguro
44%
General de Salud Cía. de
Segs.
8%
AXA Salud
9%
Médica Integral GNP
12%
Servicios Integrales de Salud
Nova
12%
Figura 5. Mercado del Seguro de Salud (CNSF, Comisión Nacional de Seguros y Fianzas, 2010)
Por todo esto se identifica a un solo competidor en el mercado mexicano a nivel
nacional, Seguros Centauros Salud Especializada, es el único prestador de servicios
que ofrece productos similares a Dentegra, ofrece una red de dentistas propia con
precios integrados, servicios odontológicos propios (clínicas Centauro), precios
preferenciales por adquirir el seguro en procedimiento no cubiertos, etc.
Un constante monitoreo sobre la competencia es un punto importante para Dentegra, a
continuación se presentan distintos análisis basados en las primas de los seguros y los
años en Seguros Centauro.
18
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
Cartera por Tipo de Seguro: Seguros Centauro
100%
$$4,928,084.98
$308,167.68
$15,634,272.21 $17,511,335.06
$562,218.89
$8,698,622.32
$24,558,201.78
80%
$413,250.00
$38,978,999.45
$46,963,439.77
60%
$34,509,317.65
40%
$29,687,520.72 $34,632,518.79
$16,422,615.60
$35,387,352.40
$38,440,576.40
20%
$36,151,932.81
0%
2004
2005
2006
2007
2008
2009
2010
Año
Salud
Gastos Medicos
Individual
Figura 6. Cartera por Tipo de Seguro (Seguros Centauro, Salud Especializada SA de CV, 2010)
Nota: El año 2010 solo representa las primas emitidas a Junio del mismo.
Además podemos observar el crecimiento de Seguros Centauro en la siguiente figura:
Crecimiento en Primas: Seguros Centauro
$83,677,591.47
$77,727,743.53
Primas
$59,945,554.18
$52,143,853.85
$45,321,792.93
$39,437,402.63
2003
2004
2005
2006
2007
2008
2009
2010
Figura 7. Crecimiento en Primas (Seguros Centauro, Salud Especializada SA de CV, 2010)
19
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
Ya una vez revisada esta información, podemos compararla con la llegada al mercado
de Dentegra, mismo que se ha ido repartido de la siguiente manera.
Para efectos prácticos se compararan las primas de Centauro vs. Dentegra a partir del
año 2009 que es cuando el volumen en primas es significativo.
Primas Dentegra vs Centauro
$83,115,372.58
$77,419,575.85
$59,945,554.18
$52,143,853.85
$45,321,792.93
$35,080,372.53
$39,437,402.63
$-
$-
$-
$20,159,572.65
$-
2004 2005
2006
Año
$25,121,237.92
$-
2007
2008
Dentegra
2009
2010
Centauro
Figura 8. Comparativo Dentegra vs Centauro (Elaboracion propia, 2007)
Nota: El año 2010 solo representa las primas emitidas a Junio del mismo.
1.2
Infraestructura tecnológica
En Dentegra la infraestructura tecnológica es un conjunto de elementos que integra
distintos dispositivos para soportar los procesos de la operación de la empresa, es
decir, uno o varios conjuntos de hardware, software y servicios que entrelazados dan
soporte a todas las soluciones y aplicaciones (sistemas informáticos, léase sistema
como un punto de vista sistémico) con los que cuenta la empresa. Evidentemente
estos procesos van de la mano con una solución tecnológica en las que se apoyan los
empleados para cumplir con sus tareas.
Por eso es de suma importancia para una empresa nueva como Dentegra el sustentar
todas y cada una de soluciones implementadas para garantizar que los resultados
sean muy cercanos a los esperados.
20
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
Aquí se hace una breve descripción de las distintas plataformas con que cuenta
Dentegra para su futura evaluación, análisis y en su caso propuesta de modificación.
1.2.1 Plataforma de Software
Para todo fin práctico se han heredados algunas prácticas provenientes de la empresa
matriz, en la que por definición las estaciones de trabajo y los servidores deberán ser
formateados y configurados con discos creados internamente, esto para garantizar que
el software esté debidamente soportado y cumpla con todo los reglamentos internos.
De esta manera se garantiza que todo el equipo de soporte técnico tanto en EU como
en México puede resolver cualquier problema asociado a una estación de trabajo.
Aplicaciones




Ofimática: Todos los puestos de trabajo están provistos del software requerido
de acuerdo a las responsabilidades del usuario, estos van desde el sistema
operativo Windows XP SP 3, la suite de office 2007 siendo Excel y Access 2007
el estándar para el manejo de base de datos. Los equipos que se encuentras
geográficamente dispersos, cuentan con un software denominada Cisco VPN v
5.2 para la conectividad entre los equipos remotos y todos los recursos propios
de la empresa. Para todos los equipo móviles (laptops, notebooks, etc.) se
cuenta con un software que permite la encriptación completa del disco duro
PointSec v 9.0
Gestión de recursos financieros (nomina, impuestos, contabilidad, etc.):
ContPaq es el software que se utiliza para el manejo, administración y
monitoreo de contabilidad, tesorería, finanzas, cobranza y cheques. Para este
paquete se tiene un software complementario que realiza las actividades de
backup de toda la información generada y que deposita los archivos en los
servidores, que a su vez generan un respaldo completo semanal
Comercial: Para el seguimiento, registro y evaluación de clientes, contactos y
futuros candidatos el CRM que se maneja es Sales Force, un sistema on-line
(en la nube) que se accede desde cualquier equipo y una conexión de Internet
Gestión de Pólizas: El producto para el manejo de nuevas pólizas,
mantenimiento a la cartera (endosos), casos para levantar siniestros, reporte
derivados de la operatividad diaria, etc. se tiene un producto hecho a la medida
denominado HealthCase. Este es un producto adquirido para Dentegra, con
una plataforma en Oracle 10g y su diseño orientado a objetos programado en
Delphi v 5. con una arquitectura cliente / servidor, instalado en prácticamente
todas las estaciones de trabajo para consulta y manejo de la información
21
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL


Centro de Contacto: El área encargada usa 2 herramientas antes mencionadas,
por un lado Sales Force que se modificó para aceptar el proceso de
levantamiento de casos y quejas por parte de los clientes, asegurados,
dentistas, etc. y por otro lado HealthCase que sirve para consulta de toda la
información requerida por los usuarios de sus pólizas
Web, correo y comercio electrónico: Dentegra cuenta con una compleja red de
servidores que proporcionan el servicio Web residente en las instalaciones de
Delta Dental en Rancho Córdoba CA. Utilizando como principal herramienta
WebSphere v 5. El correo electrónico corre por cuenta del software Microsoft
Outlook 2007 en las terminales y el Exchange Server v 4 del lado servidor. Para
la interacción del comercio electrónico Sales Force fue adaptado para estos
fines, tenido un portal personalizado por asegurado/cliente y dentista donde
permite él envió, transferencia y manipulación de la información existente entre
dentista/aseguradora y asegurado/ aseguradora
Sistemas Operativos



Windows XP SP 3: Todas las estaciones de trabajo utilizadas por los
empleados tienen este sistema operativo
Windows Server 2003: Dentegra cuenta con varios servidores mismos que tiene
este sistema operativo, gradualmente se está cambiando al sistema Windows
Server 2008 sin embargo todavía está en proceso de validación
Vmware v4: Este software de virtualización de equipos lógicos, es utilizado para
la generación de varios servidores que pueden convivir en una misma caja y
con optimizar recursos y espacio
1.2.2 Hardware
Servidores
Una de las tecnologías más modernas con las que cuenta Dentegra es la virtualización
de equipos, en este caso se cuenta con 7 servidores virtualizados en una misma caja,
es decir, se cuentan con el siguiente equipo de hardware para los servidores:


Chasis: Se cuenta con 1 chasis HP PROLIANT DL580 G5, 1 chasis DL580R05
HC G3 y 1 chasis DL360R6 G3
Dispositivos de almacenamiento: Una librería HP STORAGE WORKS MSL2024
junto con un HP MODULAR SMART ARRAY 500G2 STORAGE y sus
respectivas bandejas de 24 posiciones
22
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL



Procesadores: 2 procesadores INTEL X3.33GHZ 8MB 570/580 G3
PROCESSOR, y 4 procesadores HP PROLIANT DL580 G5 - HP DL580G5
E7440 2.4 16M 4 CORE
Memoria: 9 dims de HP 8GB FBD PC2-5300 2X4GB KIT
Servidores de Exchange, Black Berry, Web Server, VPN, WebMail, Citrix
disponibles para oficinas remotas. Estos servidores están ubicados en EU
Todo esto se resume en 7 servidores virtualizados que apoyan a las distintas
actividades de la empresa.
Estaciones de trabajo
Debido al constante cambio en los modelos de los equipos se intenta unificar los
modelos, sin embargo es difícil lograr esto por lo que se presentaran los modelos
actuales al momento de la investigación:




Desktop: 68 equipos HP 8100 elite SFF
Laptop: 14 equipos portátiles modelo HP ELITEBOOK 8440P
Monitores: 69 pantalla planas modelo LE2201W de 22”
Impresoras: 7 equipos de alto rendimiento y 2 equipos para impresión de
credenciales.
1.2.3 Comunicaciones
Red de área local



Switches: 3
Routers:2
Firewalls: 1
Telefonía Fija



Conmutador: BCM 400 Nortel con tarjetas incorporadas para el manejo de
tróncales digitales. Tecnología IP y analógica para faxes
Teléfonos IP: 73 teléfonos Nortel IP 2004 y 2002
Teléfonos para conferencias: 2 estrellas Vogen para conferencias en salas de
juntas
23
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
Telefonía Móvil


Nextel: Equipos Nextel para departamento de ventas con radio incluido ilimitado
BlackBerry: Servicio BES en 5 equipos blackberries, para conexión con correo
electrónico
Acceso a Internet


Servicio Dedicado: Servicio de ancho de banda dedicado con una capacidad de
un E1. Este servicio se otorga por fibra óptica y es para uso interno
Wireless: Puntos de acceso y manage handle Araba 200
1.2.4 Servicios


1.3
Soporte Técnico: Se tienen dos maneras de otorgar este servicio, en sitio y
remoto. Cuando se requiere una intervención física (cambio, adecuación,
movimiento, etc.) se acude al lugar donde se encuentra la estación de trabajo
por otro lado cuando se requiere una configuración, instalación o modificación
esta puede ser remotamente hablando a un teléfono y solicitando la
modificación
Capacitación: De acuerdo al departamento y su necesidad, se otorgan cursos
de manejo, administración y capacitación de herramientas tales como Sales
Force, suite de Office y paquetería en general
Planes de crecimiento
De acuerdo a las proyecciones consideradas en la siguiente figura, se prevé un
crecimiento en 10 de años de aproximadamente un 300% en la emisión de primas
(Dentegra Seguros Dentales, 2006), esta proyección trae consigo un incremento
asociado en la plantilla de empleados y por supuesto un incremento sustancial en los
ejecutivos de ventas para atender a los clientes.
Con estos pronósticos en el incremento de primas, colaboradores y volumen de
información el reto para la dirección es construir una infraestructura tecnológica que
permita la fluctuación de clientes, que mantenga o incluso incremente la calidad en el
servicio y que por supuesto tenga una relación sana entre el costo y el beneficio para
evitar gastos innecesarios.
24
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
Proyeccion Dentegra
$120,000,000.00
$100,000,000.00
$80,000,000.00
$60,000,000.00
$40,000,000.00
$20,000,000.00
$2010
2012
2014
2016
2018
2020
Año
Figura 9. Crecimiento estimado de emisión de primas para Dentegra (Dentegra Seguros Dentales, 2006)
El crecimiento de los ejecutivos de ventas está asociado a la apertura de distintos
centros en las plazas más importantes de la república mexicana tales como:





Tijuana
Mexicali
Cancún
Villa Hermosa
Acapulco
La intención de este análisis es la de poner en claro cuáles son los objetivos que se
buscan para el crecimiento de la empresa, que se espera como respuesta y por ultimo
de qué manera podemos vincular estos objetivos en un fin común con el área de TI,
para esto se requiere un análisis DOFA para identificar los puntos más relevantes.
1.3.1 Debilidades






Poco tiempo en el mercado
Nuevo producto
Desconocimiento del mercado
Poca penetración en el mercado
Empleados con poca experiencia en seguros
Altos gastos administrativos
25
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL


Generación de quejas por problemas no previstos
Generación de requerimientos para la administración de la cartera: Debido
a que todo es nuevo y hay pocas generadas los requerimientos para
modificación, adecuación y nuevos requerimientos siempre tiene una lista
interminable
1.3.2 Oportunidades








Mercado poco explorado
Abrir nuevos mercados
Hacer accesible este beneficio a todos los empleados en cualquier lugar de
la república mexicana
Innovar en el sector asegurador: Como es una nueva empresa tiene la
facilidad de hacer cambios en las reglas de los seguros sin que los
asegurados se sientan engañados
Crecer internamente de acuerdo al mercado optimizando costos
Optimizar costos enfocando los presupuestos
Solo un competidor
Confianza del cliente por ser empresa nueva
1.3.3 Fortalezas







Experiencia de 50 años vendiendo seguros dentales
Infraestructura tecnológica sólida
Red con más de 3000 dentistas
Plantilla de empleados jóvenes: Los empleados no son morosos o tienen
conductas mañosas
Tecnología de reciente adquisición
Uso de tecnologías por Internet
Tienes de respuesta muy competitivos
1.3.4 Amenazas


Falta de confianza en los seguros
Mercado no reacciones con el interés que se espera
26
CAPITULO 1. SITUACIÓN ACTUAL Y MARCO CONCEPTUAL
1.4
Problemática: Algunas posibles soluciones
Con todo lo anterior podemos conceptualizar una gama de posibles soluciones que van
desde la definición de un gobierno de TI por parte de la dirección, hasta la entrega y
soporte de los servicios del Service Desk así como la gestión de cambios en el
aplicativo correspondiente (HealthCase).
Es importante resaltar que los puntos que se intentaran resolver en este trabajo son los
puntos relacionados al área de TI, independientemente de todos aquellos que pudieran
derivarse de las áreas de oportunidad de otros departamentos.
Los objetivos que se buscara cubrir con la propuesta de solución son los siguientes:








Gobierno de TI
Dirigir, controlar y asignar responsable de los procesos
Un solo punto de atención al cliente
Conocimiento de las distintas etapas por lo que pasa una incidencia, problema
o nuevo requerimiento desde su apertura hasta la finalización o entrega del
mismo
Conocer la manera en que se relacionan los distintos problemas reportados con
aquellos ya resueltos con anterioridad
Generación de una base de conocimiento centralizada para futuras soluciones
de “autoservicio”
Obtención de métricas y estadísticas de los recursos utilizados en el soporte de
incidencias
Transferencia del conocimiento en el personal
27
CAPITULO 2. MARCO CONCEPTUAL
CAPITULO 2. MARCO CONCEPTUAL: LA IMPORTANCIA DE LAS MEJORES
PRÁCTICAS EN EL ÁREA DE TI
El cumplimiento de los objetivos es primordial para el éxito de prácticamente cualquier
actividad humana, las formas y las maneras de cumplir con estos es lo que hace la
diferencia en términos de calidad al momento de otorgar un servicio como el que ofrece
Dentegra.
En este capítulo revisaremos las metodologías utilizadas durante este trabajo de
investigación y observaremos las tendencias sugeridas por sus creadores para
sustentar la utilización de cada una. Como uno de los principales conceptos manejados
en este trabajo es la orientación al cliente y considerando que los principales usuarios
de los servicios informáticos tanto internos como externos no tienen una formación
tecnológica, las tendencias a continuación mostradas están dadas por organizaciones
que tienen un origen más operativo que tecnológico.
2.1
Tendencias tecnológicas en
Tecnológicos) (ISACA, 2010)
el
control
del
área de
TI (Servicios
Servicios tecnológicos
Hablar de los servicios podría ser muy ambiguo y sobre todo muy extenso, por esta
razón comenzaremos por enfocarnos únicamente a los servicios tecnológicos; y
podemos decir que es una actividad de naturaleza generalmente intangible, aunque no
necesariamente, se genera por la interacción entre el cliente y el personal o los
sistemas de una organización proveedora, en un mercado industrial y que proporciona
una solución basada en conocimiento científico o tecnológico, a los problemas del
cliente (OGC, Office of Government Commerce, 2003).
Con esto podemos determinar los principales conceptos de los servicios tecnológicos:






De carácter intangible del servicio
Interacción estrecha entre el cliente y la organización proveedora
El carácter público o privado de la organización proveedora
El mercado industrial en que se prestan los servicios tecnológicos, son parte del
proceso productivo de otras empresas
El servicio proporciona una solución al cliente
El servicio se basa en conocimiento científico o tecnológico
No hay que olvidar que un servicio de TI es un conjunto de actividades que buscan
responder a una o más necesidades de un cliente por medio de un cambio de
condición en los bienes informáticos potenciando el valor de estos y reduciendo el
riesgo inherente del sistema. (OGC, Office of Government Commerce, 2007)
Además los servicios son maneras de entregar valor a los clientes como soporte de los
resultados que los clientes pueden obtener sin incurrir en costos y riesgos específicos.
28
CAPITULO 2. MARCO CONCEPTUAL
2.1.1 Características de los servicios tecnológicos











Los servicios son intangibles, mientras que los productos son tangibles
Los servicios son heterogéneos, porque el servicio depende de circunstancias
que cambian en cada transacción, por ejemplo, el proveedor del servicio, los
clientes, el entorno, etc.
En los servicios la producción, la distribución y el consumo son simultáneos
En la transacción de un servicio la propiedad no se transmite con la compra,
como sucede con los bienes físicos
El servicio no es un objeto sino un proceso o un acto
El cliente participa en la producción, debe estar presente en el lugar en que el
servicio se suministra
Los servicios no se pueden revender
Los servicios no se pueden transportar, a menos que su sistema de prestación
se traslade
Los servicios son más una experiencia que un producto terminado, por lo que
los conocemos hasta que los consumimos
El contacto entre el cliente y el prestador es necesario
Los servicios no se pueden exportar, a menos que el sistema de prestación se
establezca en el extranjero
2.1.2
Generación un servicio tecnológico
La producción de servicios se puede explicar a través del concepto Servucción, que es
la organización sistemática y coherente de todos los elementos físicos y humanos de la
relación cliente-empresa necesaria para la prestación de un servicio cuyas
características comerciales y niveles de calidad han sido determinados (Pierre Eiglier,
1989). Este concepto puede aplicarse a los servicios tecnológicos.
Un sistema de servucción está compuesto por los siguientes elementos:


El cliente: Es el consumidor, implicado en la fabricación del servicio. Su
presencia es absolutamente indispensable, sin cliente el servicio no puede
existir, habría sólo capacidades disponibles o potencialidades de servicio. Los
clientes en el servicio tecnológico son empresas ubicadas en mercados
industriales para las que el servicio tecnológico es un componente intermedio
de su proceso productivo
El soporte físico: El soporte material que es necesario para la producción del
servicio, y del que se servirán o bien el personal en contacto, o bien el cliente, o
bien a menudo los dos a la vez. Este soporte físico puede tipificarse en dos
grandes categorías. Por un lado los instrumentos, es decir, los objetos, muebles
o máquinas puestos a disposición del personal en contacto o del cliente para la
realización del servicio. Por otro lado el entorno, es decir, la localización, los
edificios, el lugar en los que se efectúa la servucción. Los servicios tecnológicos
pueden requerir de un soporte físico especializado. En muchos casos la
prestación del servicio requiere instrumentos (laboratorios, equipos
especializados) pero en otros casos el conocimiento tecnológico es tácito y no
está en dispositivos de tipo tecnológico sino en el personal que presta el
29
CAPITULO 2. MARCO CONCEPTUAL


servicio (por ejemplo, consultoría). El entorno en que se ha de prestar el
servicio no difiere mucho del requerido por otros servicios profesionales
El personal de contacto: Son las personas empleadas por la empresa de
servicio, que están en contacto directo con el cliente: personal de recepción de
los hoteles, cajeros de banco, azafatas en los transportes, etc. Puede no existir
en algunas servucciones, en tal caso son realizadas únicamente por el cliente.
Es el caso de la habitación del hotel o del cajero automático. El personal en
contacto desempeña un papel muy importante en los servicios tecnológicos.
Además de cumplir las características del personal prestador de cualquier otro
servicio, son poseedores y administradores del conocimiento tecnológico que
se transfiere con el servicio
El servicio: Es la resultante de la interacción entre el cliente, el soporte físico y
el personal en contacto. Es el beneficio que debe satisfacer la necesidad del
cliente: es el hecho de estar descansado si se trata de un hotel, o de ser
transportado de una ciudad a otra si se trata del tren. El servicio es la
transferencia de conocimiento tecnológico. Físicamente puede adoptar, por
ejemplo, la forma de un informe escrito, software, un diseño, los planos de un
proyecto, etc. o simplemente la solución a un problema
Además podrían añadirse otros dos elementos:


El sistema de organización interna: El soporte físico y el personal en contacto
están condicionados por la organización interna de la empresa de servicio, es
decir, los objetivos que persigue, la estructura que ha adoptado, las
operaciones que efectúa, en una palabra, la administración; es la parte no
visible para el cliente de la empresa de servicio
Los demás clientes: Los prestadores de servicios rara vez atienden las
necesidades de un solo cliente. Varios clientes pueden coincidir en el tiempo y
el espacio como demandantes del mismo servicio, y esto puede influir en la
calidad del servicio y la satisfacción del cliente
Como podemos ver en la figura 10 el concepto de servicio está envuelto de múltiples
factores: las personas (en distintos papeles como clientes, proveedores, personal de
contacto, etc.), los objetos (como el soporte físico, las instalaciones, etc.), los sistemas
organizacionales (procesos y funciones dentro del área) y por ultimo un factor que va
de la mano con la condición humana como lo son el medio ambiente organizacional o
cultura organizacional y características particulares como la experiencia, trato o
conocimiento técnico de las personas.
Todos estos factores hacen que la experiencia de consumir un servicio sea evaluada a
través de una opinión subjetiva y precisamente es una de las principales aportaciones
del modelo de servucción de Langeard y Eiglier donde le da importancia a la
participación del cliente. Esta participación puede producirse en tres momentos
diferentes: en la especificación del servicio, en la acción propiamente dicha y en el
control del resultado o del proceso. Una organización rara vez busca una participación
plena de sus clientes. Lo más habitual es buscar la participación del cliente en la
prestación propiamente dicha, es decir, aumentar el autoservicio.
30
CAPITULO 2. MARCO CONCEPTUAL
Figura 10. Diagrama de servucción (importancia del cliente en el proceso de servicios) (Pierre Eiglier,
1989)
Aumentar la participación del cliente no consiste sólo en transferir una actividad al
cliente. A veces implica prestarle más ayuda porque, al menos durante un tiempo,
reclamarán más atención, algún tipo de formación e incluso apoyo para reducir el
esfuerzo percibido. La participación del cliente significa que a menudo el cliente deberá
complementar formularios, dar información, usar máquinas, etc. La buena disposición
del cliente a hacer estas actividades mejorará el servicio o a la inversa. Por ejemplo, si
un paciente no es capaz de explicar claramente su problema, el médico no hará un
diagnóstico correcto y podrá dar una prescripción incorrecta. En este caso el servicio
prestado se habrá visto afectado por la interacción del cliente.
El personal de contacto existe fundamentalmente por dos razones: servir al cliente y
representar y defender los intereses de la empresa, aunque en muchos casos este
orden de valores se invierte. La gestión del personal en contacto plantea tres conjuntos
de dificultades:



El personal en contacto representa a la organización, por lo tanto es un
importante elemento de su imagen
El personal en contacto se divide entre dos tipos de intereses divergentes: los
intereses de la organización y los intereses de los clientes. Es difícil mantener el
equilibrio entre ambos
El personal en contacto debe desempeñar dos papeles diferentes: el
operacional y el relacional. Es difícil encontrar personal que se encuentre
cómodo en ambas situaciones de forma simultánea
2.1.3

Clasificación y tipos de servicios tecnológicos
En primer lugar, hay servicios que usan tecnologías manufacturadas y bienes
de capital; tales servicios incluyen distribución y servicios financieros, y hasta
cierto punto servicios de reparación y mantenimiento. Estos servicios tienen dos
importantes subgrupos. Los servicios intensivos en computación, especialmente
31
CAPITULO 2. MARCO CONCEPTUAL



servicios financieros y los servicios intensivos en infraestructura como son el
transporte y las telecomunicaciones
En segundo lugar, hay servicios basados en la creación y uso perceptivo de
capacidades tecnológicas y funciones especializadas. La mayoría de los
servicios considerados como servicios tecnológicos en este trabajo se incluyen
en esta categoría, por ejemplo, la consultoría, la ingeniería, los proyectos de
I+D, el diseño industrial y el desarrollo de software y sistemas. Pero también se
pueden incluir en esta categoría los servicios de mantenimiento y reparación o
la gestión de infraestructuras
En tercer lugar, hay servicios basados en la aplicación de habilidades
profesionales codificadas y competencias. Estas incluyen los servicios legales y
contables. En estos servicios las organizaciones profesionales y de certificación
desempeñan un papel importante
Finalmente, hay servicios basados en habilidades tácitas. Estos incluyen
servicios tales como peluquería, restaurantes, diseño de moda, limpieza y otros.
El acceso a la prestación de estos servicios puede estar regulada formalmente
mediante el requerimiento de ciertas habilidades, o informalmente, dentro del
propio sector
2.1.4
Adquisición de los servicios tecnológicos
Dado que el conocimiento es un elemento clave de los servicios tecnológicos, es útil
analizar el siguiente modelo, que parte de las siguientes definiciones:





2.2
Las capacidades clave son la ventaja competitiva de la empresa; se han
construido a lo largo del tiempo y no se pueden imitar con facilidad. Son
distintas de las capacidades suplementarias y facilitadoras, que no son
suficientemente superiores a las de los competidores para ofrecer una ventaja
sostenible
Las capacidades suplementarias son las que añaden valor a las capacidades
clave pero que podrían ser imitadas –por ejemplo, canales de distribución
particulares o habilidades de diseño de envase fuertes pero no únicas
Las capacidades facilitadoras son necesarias pero no suficientes por si solas
para distinguir a la empresa competitivamente
Las empresas tienden a mantener las capacidades clave como actividades
internas y rara vez acuden al mercado para cubrirlas con servicios tecnológicos
Para crear y mantener capacidades tecnológicas clave, es necesario
comprender qué es una capacidad clave y sus dimensiones, y saber gestionar
las correspondientes actividades de creación de conocimiento
Metodologías basadas en las mejores prácticas
Actualmente, las áreas internas encargadas de la gestión de las Tecnologías de la
Información (TI) se orientan a proporcionar una visión de proveedores de servicios.
Esta nueva visión nace de la necesidad de establecer un modelo de administración
integral que permita implementar esquemas de trabajo basados en compromisos
formales, donde se determinen y comprometan niveles de servicio específicos que
32
CAPITULO 2. MARCO CONCEPTUAL
garanticen a las diferentes unidades de negocio el poder concentrarse en realizar sus
funciones y que no se preocupen por el buen funcionamiento de la tecnología que les
apoya.
2.2.1
Administración en el departamento de TI
Es por demás sabido el impacto de la tecnología en las organizaciones y esto gracias a
que influye directamente en el éxito de las mismas, el liderazgo en sea cual sea el
sector que las organizaciones se desempeñen va de la mano con la innovación y a su
vez ambas se estructuran en el término “tecnología” para ir fortaleciéndose y llegar a
un fin común.
También es por demás común apreciar que algunas organizaciones no entienden lo
importante del uso de la tecnología para su bienestar y peor aún, aquellas que aun
sabiéndolo, no saben cómo aprovechar al máximo los recursos con que cuentan.
Estos recursos generalmente crecen de manera exponencial y en un lapso de tiempo
generalmente corto, es por eso que ha vuelto indispensable para los usuario internos
(directivos, gerentes, etc.) y externos (auditores, proveedores, etc.) la necesidad de un
marco en donde basarse para validar la seguridad y el control en las tecnologías da
información.
Además de los riesgos inminentes que incurre una organización al utilizar la tecnología,
tales como:



Alta dependencia en las soluciones tecnológicas de las organizaciones
Hurto o fugas de información (manera digital)
Alto impacto potencial de la tecnología en las organizaciones (para bien y para
mal)
Hoy en día existen dos clases distintas de modelos de control, aquellos que se enfocan
al “control de negocios” y otros modelos más enfocados a “las tecnologías de
información”.
En ambos casos el objetivo es el mismo, controlar procesos y poner a disposición de
los administradores los principales indicadores que dan un panorama muy aproximado
de la situación actual de la organización.
Sin embargo estos modelos por su parte se enfocan única y exclusivamente o al
negocio puro o a los proceso operativos en el área de tecnología, por lo que aquí
hablaremos de un modelo denominado Cobit que intenta fusionar ambos mundos.
Existen distintas metodologías basadas en las mejores prácticas (como Cobit) que nos
sirven como marco de referencia para poder estandarizar los proyectos, procesos y
sobretodo poner en marcha acciones que nos lleven a generar puntos de control
medibles a todos los niveles de la organización para el apoyo, soporte, sustento y
obtención de información con un nivel muy confiable de calidad.
A continuación hablaremos de esta metodología y sus beneficios.
33
CAPITULO 2. MARCO CONCEPTUAL
2.2.2 COBIT (Control Objectives for Information and related Technology)
COBIT v 4.1 (Control Objectives for Information and related Technology | Objetivos de
Control para tecnología de la información y relacionada)
Es el modelo para el “Gobierno de la TI”1 desarrollado por la Information Systems Audit
and Control Association (ISACA) y el IT Governance Institute (ITGI).
El objetivo de este framework es organizar y armonizar distintos estándares
internacionales, relacionados con la administración de la Tecnología de la Información
en las organizaciones. COBIT presenta un conjunto de mejores prácticas, enfocadas
en el control más que en la ejecución, que permiten optimizar la inversión en TI que
una organización realiza. Este modelo define un conjunto de criterios de control, en
base a requisitos de calidad, confianza y seguridad.
Cobit fue lanzado en 1996 con la finalidad de consolidar y armonizar los estándares
globales para el control en el departamento de TI. Se aplica a todos los sistemas
informáticos y dispositivos de todos los tamaños dentro de la organización y su misión
es: investigar, desarrollar, publicar y promover un conjunto internacional actualizado de
objetivos de control para las tecnologías de información que sea de uso cotidiano para
los gerentes y auditores (ISACA, Information Systems Audit and Control Association,
2000).
Esta publicación ha tenido varias ediciones desde la primera publicada en 1996, la
segunda edición en 1998, la tercera en 2000; la cuarta en diciembre de 2005 y la
versión más reciente 4.1 disponible desde mayo 2007.
Un ejemplo (ISACA, Knowledge Center, 2009) lo podemos ver con el banco
ScotianBank en Costa Rica que en el año de 2009 el SUGEF (Superintendencia
General de Entidades Financieras de Costa Rica) aprobó el “reglamento sobre la
gestión de la TI” que aplica a todas las entidades bancarias y financieras del país y
establece la obligatoriedad de los 34 procesos de COBIT y alcanzar el nivel 3 de
madurez en todos los procesos durante los siguientes 3 años. En este caso
Scotianbank utilizo su infraestructura organizacional para realizar tareas de
planificación, organización, dirección, monitoreo y toma de decisiones para
implementación del gobierno de TI.
Su estrategia de implementación considero en una primera fase 17 procesos que
podían cumplir con el nivel 3 de madurez y en una segunda fase los otros 17 que se
iniciaron con un nivel 1 para que paulatinamente pudieran transformarse en niveles 2 y
3 a lo largo de los 3 años.
Dentro de los principales beneficios que podemos ver en esta implementación se
encuentran:

1
El fortalecimiento entre las estrategias de negocio y de TI
Del vocablo inglés “IT Governance”
34
CAPITULO 2. MARCO CONCEPTUAL



La creación de procesos definidos con estructuras internacionalmente
aceptadas, auditables, medibles y que integren las mejores prácticas de la
industria bancaria
Identificación de los controles claves que deben ser reforzados e
implementados para asegurar un adecuado control interno para TI
Procesos mejorados y más confiables que fortalecen la aplicación de las
prácticas relacionadas con la gestión de los cinco elementos de control que
constituyen el buen gobierno de TI
Es importante mencionar que COBIT ha sido desarrollado y se le da mantenimiento por
un instituto de investigación sin ánimo de lucro, tomando en cuenta la experiencia de
los miembros de sus asociaciones afiliadas, de los expertos de la industria, y de los
profesores de control y seguridad. Su contenido se basa en una investigación continua
sobre las mejores prácticas del área de TI y se le da un mantenimiento continuo, con el
objetivo de proporcionar un recurso objetivo y práctico para todo tipo de usuario.
Para poder consumar la alineación de las mejores prácticas con los requerimientos del
negocio se recomienda que COBIT se utilice al más alto nivel de la empresa, para así
tener un marco donde se controle de manera general los modelos de procesos de las
TI, ya que debe ser aplicable a toda la empresa por igual.
Las prácticas y los estándares específicos que se aplican en áreas muy particulares se
pueden comparar con el marco de trabajo de COBIT otorgando así una jerarquía de
materiales que sirven como guía.
Por lo tanto la información generada por Cobit puede resultar de suma importancia a
diferentes usuarios dentro de la organización, entre los más beneficiados se
encuentran:





Gerencia: Apoya la inversiones en tecnología y controla el rendimiento al
analizar los costos beneficios
Usuarios finales: Estos se benefician con la seguridad y el control de la
información recibida
Auditores: Ayuda a soportar sus opiniones sobre los controles de los proyectos
de tecnología y su impacto en la organización
Responsables de TI: Ayuda para identificar los controles sobre su área
Responsable del negocio: Para control de los aspectos de la información
Todos los usuarios potenciales se pueden beneficiar del uso del contenido de COBIT
como una aproximación completa a la administración y gobierno de TI junto con otros
modelos de estándares detallados como:
 ITIL para la entrega del servicio
 CMM para la entrega de soluciones
 ISO 17799 para seguridad de la información
 PMBOK o PRINCE2 para la administración de proyectos
Dentro de las principales características de Cobit se encuentran:

Orientado al negocio
35
CAPITULO 2. MARCO CONCEPTUAL



Alineado con estándares y regulaciones de “facto”
Se basa en una revisión crítica y analítica de las tareas y actividades del
departamento de TI
Se alinea con los estándares de control y auditoria (COSO, IFAC, IIA, ISACA,
AICPA)2
Se basa en tres niveles:



Dominio: Agrupación natural de todos los procesos, estos generalmente
corresponden a una área o responsabilidad organizacional. Existen 4 dominios
principales (se explican más adelante):
o Planificación y organización
o Adquisición e implementación
o Prestación y soporte
o Monitoreo
Procesos: Conjunto de actividades secuenciales delimitadas por procesos de
control
Actividades: Todas aquellas acciones requeridas para la obtención de un
resultado medible
En términos generales podemos decir que el Cobit como producto nos ofrece:




Marco referencial: Describe a detalle los 34 objetivos de control de alto nivel e
identifica los requerimientos de negocio para la información y los recursos de TI
que son impactados en forma primaria por cada objetivo de control
Objetivos de control: Contiene las declaraciones de los resultados deseados o
propósitos a ser alcanzados mediante la implementación de 302 objetivos de
control de tallados y específicos a través de los 34 procesos de TI
Guías de auditoría: Contiene los pasos de auditoría correspondientes a cada
uno a cada uno de los 34 objetivos de control de TI de alto nivel para
proporcionar asistencia a los auditores de sistemas en la revisión de procesos
de TI con respecto a los 302 objetivos detallados de control recomendados para
proporcionar a la gerencia certeza o una recomendación de mejora
Herramientas de Implementación: Proporciona lecciones aprendidas por
organizaciones que han aplicado Cobit rápida y exitosamente en sus ambientes
de trabajo
En la siguiente figura se presenta un diagrama esquematizando el marco de trabajo de
COBIT:
2
Acrónimos definidos en la sección de Glosario de términos y Abreviaciones
36
CAPITULO 2. MARCO CONCEPTUAL
Figura 11. Marco de Trabajo completo de COBIT (ISACA, Education, 2009)
2.2.2.1 Requerimientos de Cobit
Es importante mencionar que para orientarnos a los objetivos del negocio la
información necesita ser coherente y consistente a los criterios que Cobit hace
referencia como requerimientos del negocio para la información; para establecer la lista
de requerimientos Cobit combina los principios contenidos en los modelos existentes
como se observa en la siguiente figura:
37
CAPITULO 2. MARCO CONCEPTUAL
Figura 12. Flujo de Requerimientos en Cobit (ISACA, Education, 2009)
2.2.2.2
Recursos de TI
En Cobit se establecen los siguientes recursos en TI necesarios para alcanzar los
objetivos de negocio:





Datos: Todos los objetos de información. Considera información interna y
externa, estructurada o no, gráficas, sonidos, etc.
Aplicaciones: entendido como los sistemas de información, que integran
procedimientos manuales y sistematizados
Tecnología: incluye hardware y software básico, sistemas operativos, sistemas
de administración de bases de datos, de redes, telecomunicaciones,
multimedia, etc.
Instalaciones: Incluye los recursos necesarios para alojar y dar soporte a los
sistemas de información
Recurso Humano: Por la habilidad, conciencia y productividad del personal para
planear, adquirir, prestar servicios, dar soporte y monitorear los sistemas de
Información
A manera de resumen, los recursos de TI son manejados por procesos de TI para
lograr metas de TI que respondan a los requerimientos del negocio. Este es el principio
básico del marco de trabajo COBIT, como se ilustra en el cubo COBIT.
38
CAPITULO 2. MARCO CONCEPTUAL
Figura 13. Cubo Cobit (ISACA, Education, 2009)
2.2.2.3 Componentes esenciales de COBIT
Para cada uno de los procesos de TI de COBIT se proporciona un objetivo de control
de alto nivel, junto con las metas y métricas clave en forma de cascada. La forma
propuesta se encuentra en el Anexo A de la sección correspondiente. En la figura de
se muestra la iconografía que se utilizan en la metodología con el fin de hacer más
entendible el concepto descrito.
La intención es poner por escrito las declaraciones de acciones de la mínima
administración de las buenas prácticas para asegurar que el proceso se tiene bajo
control.
En la primera sección del machote nos muestra una descripción del proceso en donde
se resume el objetivo del proceso, con el control de alto nivel en forma de cascada;
además de que muestra el mapeo de este proceso con los criterios de información
indicando con una “P” la relación primaria y con una “S” la relación secundaria.
En la sección 2 se muestran los objetivos de control detallados para el proceso
descrito.
La tercera sección contiene las entradas y salidas del proceso, la matriz RACI3, las
metas y métricas.
Por último en la cuarta sección muestra el modelo de madurez del proceso.
3
Matriz RACI (quién es responsable, quién rinde cuentas, quién es consultado y quien informado)
39
CAPITULO 2. MARCO CONCEPTUAL
Dominios de Cobit
Por otra parte para gobernar efectivamente el departamento de TI, es importante
determinar las actividades y los riesgos que requieren ser controlados. Normalmente
se ordenan dentro de dominios de responsabilidad de planeación, construcción,
ejecución y monitoreo.
En la siguiente figura se muestran la interrelación de estos dominios según Cobit:
Figura 14. Los cuatro dominios interrelacionados de Cobit (ISACA, Education, 2009)
A continuación se describen dichos dominios.
2.2.2.4 Planear y organizar (PO)
Este dominio cubre las estrategias y las tácticas, y tiene que ver con identificar la
manera en que TI puede contribuir de la mejor manera al logro de los objetivos del
negocio. En otras palabras proporciona dirección para la entrega de soluciones (AI) y la
entrega de servicio (DS)
Sus actividades son:

PO1 Definir un Plan Estratégico de TI: La planeación estratégica de TI es
necesaria para gestionar y dirigir todos los recursos de TI en línea con la
estrategia y prioridades del negocio
40
CAPITULO 2. MARCO CONCEPTUAL









PO2 Definir la Arquitectura de la Información: La función de sistemas de
información debe crear y actualizar de forma regular un modelo de información
del negocio y definir los sistemas apropiados para optimizar el uso de esta
información
PO3 Determinar la Dirección Tecnológica: La función de servicios de
información debe determinar la dirección tecnológica para dar soporte al
negocio
PO4 Definir los Procesos, Organización y Relaciones de TI: Una organización
de TI se debe definir tomando en cuenta los requerimientos de personal,
funciones, rendición de cuentas, autoridad, roles, responsabilidades y
supervisión
PO5 Administrar la Inversión en TI: Establecer y mantener un marco de trabajo
para administrar los programas de inversión en TI que abarquen costos,
beneficios, prioridades dentro del presupuesto, un proceso presupuestal formal
y administración contra ese presupuesto
PO6 Comunicar las Aspiraciones y la Dirección de la Gerencia: La dirección
debe elaborar un marco de trabajo de control empresarial para TI, y definir y
comunicar las políticas
PO7 Administrar Recursos Humanos de TI: Adquirir, mantener y motivar una
fuerza de trabajo para la creación y entrega de servicios de TI para el negocio
PO8 Administrar la Calidad: Se debe elaborar y mantener un sistema de
administración de calidad, el cual incluya procesos y estándares probados de
desarrollo y de adquisición
PO9 Evaluar y Administrar los Riesgos de TI: Crear y dar mantenimiento a un
marco de trabajo de administración de riesgos. El marco de trabajo documenta
un nivel común y acordado de riesgos de TI, estrategias de mitigación y riesgos
residuales
PO10 Administrar Proyectos: Establecer un marco de trabajo de administración
de programas y proyectos para la administración de todos los proyectos de TI
establecidos
2.2.2.5 Adquirir e implementar (AI)
Para llevar a cabo la estrategia de TI, las soluciones de TI necesitan ser identificadas,
desarrolladas o adquiridas así como implementadas e integradas en los procesos del
negocio. Además, el cambio y el mantenimiento de los sistemas existentes está
cubierto por este dominio para garantizar que las soluciones sigan satisfaciendo los
objetivos del negocio. En otras palabras proporciona las soluciones y las pasa para
convertirlas en servicios.
41
CAPITULO 2. MARCO CONCEPTUAL
Sus actividades son:







AI1 Identificar soluciones automatizadas: La necesidad de una nueva aplicación
o función requiere de análisis antes de la compra o desarrollo para garantizar
que los requisitos del negocio se satisfacen con un enfoque efectivo y eficiente
AI2 Adquirir y mantener software aplicativo: Las aplicaciones deben estar
disponibles de acuerdo con los requerimientos del negocio
AI3 Adquirir y mantener infraestructura tecnológica: Las organizaciones deben
contar con procesos para adquirir, Implementar y actualizar la infraestructura
tecnológica
AI4 Facilitar la operación y el uso: El conocimiento sobre los nuevos sistemas
debe estar disponible
AI5 Adquirir recursos de TI: Se deben suministrar recursos TI, incluyendo
personas, hardware, software y servicios
AI6 Administrar cambios: Todos los cambios, incluyendo el mantenimiento de
emergencia y parches, relacionados con la infraestructura y las aplicaciones
dentro del ambiente de producción, deben administrarse formalmente y
controladamente
AI7 Instalar y acreditar soluciones y cambios: Los nuevos sistemas necesitan
estar funcionales una vez que su desarrollo se completa
2.2.2.6 Entregar y dar soporte (DS)
Este dominio cubre la entrega en sí de los servicios requeridos, lo que incluye la
prestación del servicio, la administración de la seguridad y de la continuidad, el soporte
del servicio a los usuarios, la administración de los datos y de las instalaciones
operativas. En otras palabras recibe las soluciones y las hace utilizables por los
usuarios finales.
Sus actividades son:



DS1 Definir y administrar los niveles de servicio: Contar con una definición
documentada y un acuerdo de servicios de TI y de niveles de servicio, hace
posible una comunicación efectiva entre la gerencia de TI y los clientes de
negocio respecto de los servicios requeridos
DS2 Administrar los servicios de terceros: La necesidad de asegurar que los
servicios provistos por terceros cumplan con los requerimientos del negocio,
requiere de un proceso efectivo de administración de terceros
DS3 Administrar el desempeño y la capacidad: La necesidad de administrar el
desempeño y la capacidad de los recursos de TI requiere de un proceso para
42
CAPITULO 2. MARCO CONCEPTUAL










revisar periódicamente el desempeño actual y la capacidad de los recursos de
TI
DS4 Garantizar la continuidad del servicio: La necesidad de brindar continuidad
en los servicios de TI requiere desarrollar, mantener y probar planes de
continuidad de TI, almacenar respaldos fuera de las instalaciones y entrenar de
forma periódica sobre los planes de continuidad
DS5 Garantizar la seguridad de los sistemas: La necesidad de mantener la
integridad de la información y de proteger los activos de TI, requiere de un
proceso de administración de la seguridad
DS6 Identificar y asignar costos: La necesidad de un sistema justo y equitativo
para asignar costos de TI al negocio, requiere de una medición precisa y un
acuerdo con los usuarios del negocio sobre una asignación justa
DS7 Educar y entrenar a los usuarios: Para una educación efectiva de todos los
usuarios de sistemas de TI, incluyendo aquellos dentro de TI, se requieren
identificar las necesidades de entrenamiento de cada grupo de usuarios
DS8 Administrar la mesa de servicio y los incidentes: Responder de manera
oportuna y efectiva a las consultas y problemas de los usuarios de TI, requiere
de una mesa de servicio bien diseñada y bien ejecutada, y de un proceso de
administración de incidentes
DS9 Administrar la configuración: Garantizar la integridad de las
configuraciones de hardware y software requiere establecer y mantener un
repositorio de configuraciones completo y preciso
DS10 Administrar los problemas: Una efectiva administración de problemas
requiere la identificación y clasificación de problemas, el análisis de las causas
desde su raíz, y la resolución de problemas
DS11 Administrar los datos: Una efectiva administración de datos requiere de la
identificación de requerimientos de datos
DS12 Administrar el ambiente físico: La protección del equipo de cómputo y del
personal, requiere de instalaciones bien diseñadas y bien administradas
DS13 Administrar las operaciones: Un procesamiento de información completo
y apropiado requiere de una efectiva administración del procesamiento de datos
y del mantenimiento del hardware
2.2.2.7 Monitorear y evaluar (ME)
Todos los procesos de TI deben evaluarse de forma regular en el tiempo en cuanto a
su calidad y cumplimiento de los requerimientos de control. Este dominio abarca la
administración del desempeño, el monitoreo del control interno, el cumplimiento
regulatorio y la aplicación del gobierno. En otras palabras monitorear todos los
procesos para asegurar que se sigue la dirección proyectada.
43
CAPITULO 2. MARCO CONCEPTUAL
Sus actividades son:




ME1 Monitorear y Evaluar el Desempeño de TI: El proceso incluye la definición
de indicadores de desempeño relevantes, reportes sistemáticos y oportunos de
desempeño y tomar medidas expeditas cuando existan desviaciones
ME2 Monitorear y Evaluar el Control Interno: Establecer un programa de control
interno efectivo para TI requiere un proceso bien definido de monitoreo
ME3 Garantizar el Cumplimiento Regulatorio: Una supervisión efectiva del
cumplimiento requiere del establecimiento de un proceso de revisión para
garantizar el cumplimiento de las leyes, regulaciones y requerimientos
contractuales
ME4 Proporcionar Gobierno de TI: El establecimiento de un marco de trabajo
de gobierno efectivo, incluye la definición de estructuras, procesos, liderazgo,
roles y responsabilidades organizacionales para garantizar así que las
inversiones empresariales en TI estén alineadas y de acuerdo con las
estrategias y objetivos empresariales
2.2.3 ITIL (Information Technology Infrastructure Library) (OGC, Office of
Government Commerce, 2007)
ITIL es un marco de referencia público que describe las mejores prácticas en la
administración de servicios de TI, además provee el marco de referencia para los
alcances del departamento de TI a través del “servicio cubierto” y se enfoca en la
mejora continua y control de la calidad de la entrega de los servicios de TI desde la
perspectiva del cliente y del negocio.
Este enfoque es el factor con mayor éxito dentro de la red virtual de ITIL, ha contribuido
en un redituante uso y ha sido la llave para la obtención de beneficios a favor de
aquellas organizaciones que implementan sus técnicas y procesos.
Por otra parte ITIL es la forma más ampliamente aceptada para la Gestión de Servicios
de TI en el mundo. ITIL proporcionará un conjunto coherente de mejores prácticas,
extraídas de los sectores público y privado a nivel internacional
Algunos de estos beneficios son:
 Incrementar la satisfacción de clientes y usuarios con los servicios de TI
 Mejorar la disponibilidad del servicio incrementando la renovación y las
ganancias
 Reducciones en costos, perdida de tiempos y mejora del uso y administración
de los recursos
 Maximizar la cadena de valor e inversiones en infraestructura, contribuyendo a
su estandarización mientras que los procesos de TI permiten reducir costos,
complejidad y el tiempo que toma valorar las nuevas inversiones en hardware,
software, utilidades y personal
 Mejora la toma de decisiones y disminuye el riesgo
 Potencializar el crecimiento de la organización y del negocio
44
CAPITULO 2. MARCO CONCEPTUAL
2.2.3.1 Historia de ITIL
ITIL fue publicado entre 1989 y 1995 por Her Magesty’s Stationery Office (HMSO) en
Inglaterra en conjunto con la Agencia Central de Comunicaciones y
Telecomunicaciones (Central Communications and Telecommunications Agency :
CCTA), ahora conocida como la Oficina Gubernamental de Comercio (Office of
Government Comerse; OGC). Al principio solo se usaba en Inglaterra y Holanda. Una
segunda versión fue publicación como un conjunto de libros entre el 2000 y 2004.
La versión inicial consistía de 31 libros asociados que cubrían todos los aspectos
involucrados en proveer servicios de TI. Esta versión inicial fue revisada y reemplazada
por 7 libros más consistentes (ITIL v2) que consolidaban en si un marco de referencia.
Esta segunda versión llego a ser mundialmente aceptada y ahora es usada en muchos
países por cientos de organizaciones como la base para proveer servicios de TI.
En 2007 ITIL fue revisada y mejorada por una consolidada tercera versión, que
consiste en 5 libros principales que cubren el ciclo de vida del servicio. Los 5 libros
cubren cada etapa del ciclo de vida del servicio, desde la definición inicial y el análisis
de los requerimientos del negocio en la estrategia del servicio y diseño del servicio a
través del transcurso del medio ambiente por medio de la transición del servicio a una
operación real y con una mejora continua.
Desarrollado en los 80’s, ITIL, se ha convertido en un estándar mundial, para la
Gerencia del Servicio, SM (Service Management). Empezó siendo una guía para el
gobierno de Reino Unido, descrito por la CCTA (Central Computer and
Telecommunications Agency), más conocido como OGC (Office of Government
Commerce), se ha convertido en un enfoque, probado y útil para organizaciones de
todos los sectores que lo ha utilizado como patrón y guía fundamental para la Gerencia
del Servicio.





1989: Se establece un reglamento en Reino Unido con la finalidad de
homologar los servicios de TI y constaba con alrededor de 40 libros
1991: Se crea el IT Service Management Forum (itSMF)
2000-2004: Se publica la segunda versión de ITIL con la aparición de 8 libros
para su completa implementación
2005: ITIL es aceptada y alineada como un parte de un estándar soportado por
la ISO bajo las reglas del ISO 20000
2007: Se publica la versión 3 de ITIL, donde se compone de solo 5 libros que
comprenden: la estrategia, diseño, transición, operación y mejora continua de
un servicio de TI
En la figura 15 podemos ver de manera gráfica los cambios que ha sufrido ITIL en la
línea del tiempo:
45
CAPITULO 2. MARCO CONCEPTUAL
Figura 15. Línea del tiempo para ITIL (itSMF, IT Service Management Forum, 2007)
2.2.3.2 Estructura de ITIL
De acuerdo a ITIL este se basa en los servicios y su administración, y tomando el
concepto de servicio según ITIL:
“Un servicio, es un medio de entregar valor a los clientes, facilitando los resultados que
ellos desean obtener, sin asumir los riesgos y costos asociados.
La Gestión de Servicios es una serie de funciones y procesos para gestionar los
servicios a lo largo de su ciclo de vida.
La Administración del Servicio transforma los recursos de TI y capacidades en
Servicios de TI necesarios para cumplir con los objetivos de negocio de una
organización” (OGC, Office of Government Commerce, 2007).
ITIL se soporta en cinco elementos principales totalmente interrelacionados:
46
CAPITULO 2. MARCO CONCEPTUAL
Figura 16. Ciclo de vida del servicio (itSMF, IT Service Management Forum, 2007)
La perspectiva del negocio
Las nuevas formas administrativas y la administración basada en las mejores prácticas
requieren un nuevo enfoque gerencial que vaya más allá de las clásicas prácticas,
donde se pueda disponer de los medios para el establecimiento de planificaciones
globales que ayuden a fortalecer la cultura organizacional, la administración de los
cambios, la planeación estratégica y el pensamiento sistémico, entre otros,
encaminados a consolidar la visión del negocio. Esta es una de las piedras angulares
del ITIL.
Entrega del servicio
En un ambiente de constante competitividad en el mercado, existen factores que son
determinantes para la continuidad del negocio, la oportunidad con que se entrega el
producto; la garantía, el costo, la utilidad y el beneficio son algunas de las condiciones
mínimas que se exigen a diario en el mercado. ITIL permite gestionar la entrega y
monitorización del producto (servicio informático) dentro de lo acordado con el cliente
(interno y externo), permitiendo a la organización administrar la forma, disponibilidad,
los aspectos financieros, el nivel y la continuidad del servicio ofrecido.
Es importante mencionar que para entregar el producto en tiempo y forma se requiere
de desarrollar una subestructura de la entrega del servicio y según el ITIL se realiza a
través de 5 fases determinantes para cubrir este objetivo.
47
CAPITULO 2. MARCO CONCEPTUAL
1. Manejo de nivel de servicio: Este es el proceso responsable de confirmar e
informar el impacto generado en la estructura global del departamento y de
realizar cambios y/o actualizaciones sobre este modelo una vez que sean
implementados los nuevos requerimientos y especificaciones del cliente.
2. Manejo financiero: Esta es la etapa responsable de determinar el costo real en
conjunto con el retorno de la inversión además de analizar exhaustivamente
todos los aspectos del retorno de la inversión hecho por los clientes. Para poder
realizar esta tarea se debe tener una coordinación total entre los procesos:
manejo de la capacidad, manejo de la configuración y manejo del nivel de
servicio; esto con el fin de evitar que haya fugas de gastos y determinar los
costos reales de la implementación, cambio o adecuación solicitada y que
consideren los requerimientos necesarios, así como los estándares requeridos.
3. Manejo de la capacidad: Esta es la fase responsable de asegurar que exista un
“inventario” de recursos adecuado para el momento en el que se requiera o una
vez que se detecten incidencias, problemas, cambios o nuevos requerimientos.
4. Manejo de la continuidad: Durante esta fase tenemos que maximizar la
habilidad de la organización con el fin de proveer un nivel predeterminado en
los servicios tecnológicos que se ofrece, hay que contar con los niveles
mínimos de operatividad del negocio en caso de que presente una interrupción
del servicio, ya sea prevista o no. Se requiere un análisis profundo de los
riesgos, las causas y las medidas a tomar para garantizar la continuidad del
negocio una vez que se presenten las fallas, incidencias o cambios por las
nuevas especificaciones.
5. Manejo de la disponibilidad: Esta fase la podemos como la encargada de tener
la visión completa concerniente al diseño, implementación y aplicación de
medidas de las tecnologías de información relacionadas con los servicios que
se ofrecen a los clientes. Para esto se requiere una comprensión total de las
razones por la cuales ocurren las fallas y sobre todo el tiempo que lleva
repararlas, en otras palabras es la fase encargada de la identificación de los
problemas y poner en marcha las acciones correctivas.
Soporte del servicio
La función de este proceso es garantizar la buena relación con el cliente en la medida
que las nuevas demandas, requerimientos, cambios o fallas sean soportados
integralmente dentro de la infraestructura tecnológica. Este proceso se realiza con la
configuración de 6 fases:
1. Manejo de la configuración: Es la fase que se encarga de identificar y
establecer los parámetros que se seguirán en el modelo de acuerdo a lo
establecido por ambas partes y de acuerdo con los nuevos requerimientos. Aquí
se identifican y analizan las relaciones, las propiedades, las características, los
efectos y los impactos que traen consigo una nueva necesidad o cambio. En
esta fase se tienen que involucrar los distintos actores que se involucran en el
48
CAPITULO 2. MARCO CONCEPTUAL
cambio o requerimiento, así como los dueños del proceso para determinar el
verdadero impacto en la infraestructura.
2. Manejo en el cambio: En esta etapa del proceso nos encargamos de
administrar con exactitud y de acuerdo a las nuevas especificaciones los datos
y especificaciones del nuevo requerimiento o cambio; garantizando que las
modificaciones sean conocidas por los distintos actores involucrados en el
proceso a cambiar.
3. Manejo de la remisión: Este componente del proceso es el encargado de
generar, administrar y consolidar los paquetes de todos aquellos documentos o
remisiones generados por el nuevo requerimiento o cambio; a menudo estos
cambios implican la necesidad de nuevos recursos tales como: hardware,
software, upgrades o inclusive nuevas documentaciones para ser controladas y
distribuidas posteriormente
4. Manejo de la incidencia: Esta es la fase encargada de procesas todas las
incidencias ocurridas, con esto deberá establecer prioridades y asignar tareas a
los demás procesos; además de mantener un histórico de todas las incidencias
para que sirvan de apoyo a los futuros requerimientos y no se repitan
situaciones similares en caso de fallas repetitivas
5. Manejo de problemas: Durante esta fase del proceso nos encargaremos de
recopilar y comprender con exactitud las incidencias, problemas y nuevos
requerimientos; tenemos que identificar y analizar las posibles causas que
originaron el incidente y de la misma manera proporcionar las distintas acciones
que se deben efectuar para la corrección del mismo.
6. Servicio de escritorio: Este es el punto de contacto entre el proveedor y el
usuario del servicio tecnológico, este servicio de escritorio dentro de su esfera
de autoridad puede realizar solicitudes al proceso de incidentes para cambiar
prioridades o alterar el proceso ya establecido. Esta es el escenario perfecto
para reportar y hacer nuevos requerimientos.
En la figura 17 observamos la relación existente y el manejo integrado entre la entrega
del servicio y el soporte.
2.2.3.1 Concepto de 4 P’s
La implementación de ITIL como una práctica involucra preparar y planear de manera
efectiva el uso de: Gente (People), Procesos (Processes), Productos (Products) y
Proveedores (Partners).
49
CAPITULO 2. MARCO CONCEPTUAL
Figura 17. Manejo del servicio: Entrega y Soporte del servicio (OGC, Office of Government Commerce,
2007)
Si bien esto es más un concepto que algo pragmático, es importante mencionar las
posibilidades que sugiere ITIL para la correcta fusión entre estas entidades, es
importante no olvidar que lo primero que buscamos es alinear los objetivos del negocio
con todas las funciones, procesos o roles que se tengan en el área de TI.
El concepto de las 4 P’s no es otra cosa más que resaltar la importancia y el beneficio
que producirá a la organización que todas las personas estén correctamente
entrenadas y comprometidas con su trabajo, que tengan procesos claros y bien
definidos para todas sus actividades, conociendo el impacto y las métricas necesarias
para su evaluación, soportadas por productos tecnológicos adecuados para su trabajo,
es decir; con aquellos productos que al igual que los procesos y actividades no den
margen al error humano, que sean confiables y que tengan el respaldo de aquellos
proveedores comprometidos con otorgar el mejor nivel de servicio a sus clientes.
50
CAPITULO 2. MARCO CONCEPTUAL
Figura 18. Interrelación de las 4 P’s (Osiatis, 2007)
2.2.3.2 Funciones, procesos y roles
ITIL hace una distinción entre funciones y procesos y en este apartado hablaremos de
ellos.
Una función es una unidad especializada en la realización de una cierta actividad y es
la responsable de su resultado (OGC, Office of Government Commerce, 2007). Las
funciones además incorporan a los recursos y las capacidades necesarias para el
correcto desarrollo y desempeño de la actividad en cuestión.
Las funciones tienen como objetivo principal dar a las organizaciones una estructura
que vaya conforme al negocio. Sin embargo si existe una falta de coordinación entre
las funciones puede resultar en la creación de áreas o actividades contraproducentes
para la organización como un todo.
Un modelo organizativo basado en procesos puede ayudar a mejorar la productividad
de la organización en su conjunto. Un proceso es un conjunto de actividades
interrelacionadas orientadas a cumplir un objetivo específico (OGC, Office of
Government Commerce, 2007).
Los procesos comparten las siguientes características:




Los procesos son cuantificables y se basan en el rendimiento
Tienen resultados específicos
Los procesos tienen un cliente final que es el receptor de dicho resultado
Se inician como respuesta a un evento
El centro de servicios y la gestión del cambio son dos claros ejemplos de función y
proceso respectivamente.
51
CAPITULO 2. MARCO CONCEPTUAL
Otro concepto ampliamente utilizado es el de rol. Un rol es un conjunto de actividades y
responsabilidades asignada a una persona o un grupo. Una persona o grupo puede
desempeñar simultáneamente más de un rol (OGC, Office of Government Commerce,
2007).
Hay cuatro roles genéricos que juegan un papel especialmente importante en la
gestión de servicios TI:




Gestor del Servicio: Es el responsable de la gestión de un servicio durante todo
su ciclo de vida: desarrollo, implementación, mantenimiento, monitorización y
evaluación. Responsable de un servicio específico. Representa el servicio en
toda la organización. Responsable de la mejora continua y la administración de
los cambios que afectan a los servicios bajo su supervisión
Propietario del Servicio: Es el último responsable cara al cliente y a la
organización TI de la prestación de un servicio específico
Gestor del Proceso: Es el responsable de la gestión de toda la operativa
asociada a un proceso en particular: planificación, organización, monitorización
y generación de informes
Propietario del Proceso: Es el último responsable frente a la organización TI de
que el proceso cumple sus objetivos. Debe estar involucrado en su fase de
diseño, implementación y cambio asegurando en todo momento que se dispone
de las métricas necesarias para su correcta monitorización, evaluación y
eventual mejora. Responsable de garantizar que el proceso este diseñado de
una forma efectiva y eficaz. Verificando que cumpla los requerimientos y esté
sujeto a la mejora continua
2.2.3.3 Matriz RACI
Al diseñar un servicio o proceso, es imprescindible definir claramente los roles para
permitir una toma de decisiones rápida y efectiva. Esto puede conseguirse mediante el
uso de una matriz de responsabilidad RACI para:









Clarificar roles operativos, responsabilidades y relaciones
Definir niveles de responsabilidad
Coordinar la participación en cada actividad del negocio
Acordar qué actividades deben ser realizadas
Definir y acordar responsabilidades
Mejorar la comunicación
Evitar la duplicidad de esfuerzos
Conseguir trabajos hechos, apropiadamente y en tiempo
Evitar la cultura de “la culpa”
Para la matriz RACI existen 4 tipos de actores

Responsable (Responsible)
o Aquellos que llevan a cabo la actividad o toman la decisión.
o Las responsabilidades pueden ser compartidas.
52
CAPITULO 2. MARCO CONCEPTUAL

Encargado (Accountable)
o Individuo, quien tiene en última instancia la responsabilidad.
o Solo una persona puede ser responsable por cada tarea.

Consultado (Consulted)
o Aquellos que deben ser consultados para proporcionar información
antes de que se ejecute una actividad o se tome una decisión.
o Es un proceso en dos direcciones – bidireccional.

Informado (Informed)
o Aquellos que deben ser informados después de que se lleve a cabo una
actividad o se tome una decisión.
o Es un proceso de una dirección - unidireccional.
Una matriz de responsabilidades según el conocido modelo RACI (Responsible Accountable - Consulted - Informed) le ofrece rápida y claramente la visión global
necesaria. En la figura 19 un ejemplo de una matriz RACI.
Los procesos ITIL aparecen en una columna en la parte izquierda y los roles en una fila
en la parte superior de la matriz (figura 19) con esto se puede explorar asignaciones
individuales para representar las responsabilidades de determinados roles.
La lista de procesos que aparece en la columna de la izquierda está provista de breves
descripciones sobre los procesos ITIL V3 y puede tener enlaces a modelos de
procesos.
2.2.3.4 Mejores prácticas en la administración de servicios de TI
A continuación se enlistan una serie de consideraciones basadas en las mejores
prácticas implementadas a nivel mundial y es frecuente que los clientes y proveedores
de servicios no definan adecuadamente sus expectativas y capacidades de TI para la
provisión del servicio:



Adoptar buenas prácticas puede ayudar a cerrar la brecha entre las
capacidades del proveedor y las expectativas del cliente
ITIL proporciona una guía sobre buenas prácticas aplicables a todos los tipos
de organizaciones que prestan servicios de TI a un negocio
ITIL adopta un enfoque del ciclo de vida para la Gestión de Servicios de TI
53
CAPITULO 2. MARCO CONCEPTUAL
Figura 19. Ejemplo de matriz RACI4
2.2.3.5 Mejora continua del servicio
La mejora continua del servicio nos da recomendaciones y los instrumentos necesarios
para crear y mantener un valor importante para los clientes a través de un mejor
diseño, entrega, soporte y operación de servicios.
Los objetivos de la mejora continua son:


4
Revisar, analizar y hacer recomendaciones sobre las oportunidades de mejora
en cada fase del ciclo de vida
Revisar y analizar los logros de los niveles de servicio
Ejemplo de una matriz RACI diseñada en Excel®, MS®
54
CAPITULO 2. MARCO CONCEPTUAL



Identificar e implementar actividades individuales para mejorar la calidad del
servicio de TI, mejorando la eficiencia y la efectividad de los procesos
Mejorar la rentabilidad de la prestación de servicios de TI sin sacrificar la
satisfacción del cliente
Garantizar que métodos de administración de calidad aplicables son utilizados
para soportar las actividades de mejora continua
Figura 20. Mejora continua según ITIL (OGC, Office of Government Commerce, 2007)
Circulo de Deming
El ciclo PDCA, también conocido como "Círculo de Deming"5, es una estrategia de
mejora continua de la calidad en cuatro pasos, basada en un concepto ideado por
Walter A. Shewhart. También se denomina espiral de mejora continua.
Las siglas PDCA son el acrónimo de Plan, Do, Check, Act (Planificar, Hacer, Verificar,
Actuar).
5
William Edwards Deming (14/10/1900 – 20/12/1993). Estadístico estadounidense, profesor universitario,
autor de textos, consultor y difusor del concepto de calidad total. Su nombre está asociado al desarrollo y
crecimiento de Japón después de la Segunda Guerra Mundial.
55
CAPITULO 2. MARCO CONCEPTUAL
Figura 21. Control continuo de calidad y consolidación según ITIL (OGC, Office of Government Commerce,
2007)
Es importante mencionar que tanto Cobit como ITIL presentan un enfoque de procesos
de acuerdo a las fases del ciclo de Deming dándonos una visión completa del
departamento de TI ayudándonos a identificar los recursos para planear (Plan), los
procesos a realizar (Do), las métricas de evaluación (Check) y los controles para
determinar qué tan alejados estamos de los objetivos y saber qué medidas tomar (Act).
2.3
Cobit e ITIL, Alineando objetivos
En términos generales podemos decir que COBIT e ITIL son más complementarios que
competitivos.
COBIT se centra en la definición, implementación, auditoria, medición y mejora de los
procesos específicos de control que cubren de manera total el ciclo de vida de una
implementación en el departamento de TI. Como tal es un modelo de referencia
excelente para los lugares donde gobierna el departamento de TI en todo el ciclo de
vida de la implementación.
El tema principal de ITIL es proveer de las definiciones de las mejores prácticas y
criterios para la administración de las operaciones. Más específicamente ITIL se centra
en la definición funcional, operacional y organizacional de los atributos que necesitan
ser aplicados en la administración de las operaciones, para ser realmente optimizados
en dos categorías diferentes. Estas categorías son la Administración del Soporte del
Servicio y la Administración de la Entrega del Servicio cada uno con diferentes
categorías y subcategorías.
56
CAPITULO 2. MARCO CONCEPTUAL
Figura 22. Funciones y/o Actividades según COBIT (Simone & Heschl, 2007)
Cada definición de las subcategorías incluye los criterios de las mejores prácticas en
muchas áreas, incluyendo el soporte organizacional, componentes de integración de
administración cruzada, administración de los reportes o del reporteo, capacidad de
productividad, calidad de la implementación y calidad en el servicio al cliente.
Si el objetivo es mejorar la calidad e incrementar las medidas de la gobierno de TI a
través de la implementación del ciclo de vida de una aplicación en la red de trabajo o
implementar sistemas de control para mejorar las regulatorias de la empresa, COBIT
probablemente sea más efectivo, por el otro lado si el objetivo es la mejora continua en
la eficiencia de las operaciones de TI y la calidad en el servicio orientado al cliente, ITIL
puede ser una mejor opción.
De cualquier manera uno no debe de ver esta comparación como una competencia
entre COBIT e ITIL, como vimos COBIT está basado en marcos de referencia
establecidos que no incluyen las tareas y pasos de los procesos, ya que, aunque está
orientado a procesos de TI, es un marco de referencia para gestión y control antes que
un marco de referencia para procesos y por el contrario ITIL está basado en la
definición de procesos de las mejores prácticas para la gestión y el soporte de servicios
de TI, antes que en la definición de un marco de control de amplio alcance.
Por lo tanto COBIT se focaliza en lo que una empresa necesita hacer, no cómo lo tiene
que hacer, y está ampliamente orientada a la alta gerencia, los gerentes funcionales,
los gerentes de TI y los auditores. Debido a su alto nivel y a la amplia cobertura de
objetivos Cobit es frecuentemente llamado como un ‘integrador’ donde se pueden
ubicar distintas practicas (formas de hacer las cosas) bajo un solo integrador o
“paraguas”.
Por otro lado ITIL intenta respaldar mas no fijar los procesos de negocio de una
organización. En este contexto, la OGC no aprueba el término "Cumplimiento con ITIL".
El papel del marco de trabajo de ITIL es describir los enfoques, las funciones, los roles
y procesos en los que las organizaciones pueden basar sus propias prácticas. El rol de
ITIL es brindar orientación en el nivel organizacional más bajo que pueda aplicarse
(OGC, Office of Government Commerce, 2007).
57
CAPITULO 2. MARCO CONCEPTUAL
Debajo de ese nivel, para implementar ITIL en una organización se requieren los
conocimientos específicos de sus procesos de negocio para ajustar ITIL a fin de lograr
una eficacia óptima
Dada la experiencia de la puesta en marcha de ambos estándares en la industria hoy
día, existe un sin fin de experiencias de donde echar mano para tomar un consejo. Lo
mejor de todo es que para implementar estos estándares los productos de hardware y
software son realmente mínimos y a precios muy accesibles.
Por lo que en la siguiente figura podemos ver la estructura de comparación y mapeo
entre COBIT e ITIL:
Figura 23. Estructura de comparación COBIT vs ITIL (Simone & Heschl, 2007)
En la siguiente figura veremos el mapeo de las actividades que se consideran tanto en
COBIT como en ITIL:
58
CAPITULO 2. MARCO CONCEPTUAL
Procesos Mapeados
Figura 24. Mapa de ITIL vs COBIT (Simone & Heschl, 2007)
Nota: El mapeo se realizó sobre los procesos de entrega y soporte de ITIL
59
CAPÍTULO 3. PROPUESTA METODOLÓGICA
CAPÍTULO 3. PROPUESTA METODOLÓGICA Y DISEÑO PARA LA
IMPLEMENTACIÓN EN EL ÁREA DE TI
El uso adecuado de la tecnología tiene muchas aristas que pueden impactar de una u
otra manera al negocio como podemos verlo en el siguiente comentario:
“El uso de TI tiene el potencial para ser el mayor impulsor de riqueza económica en el
siglo XXI. Además de que TI ya es crítica para el éxito empresarial, proporciona
oportunidades para obtener una ventaja competitiva y ofrece medios para incrementar
la productividad, e incluso hará aún más en el futuro.
TI también implica riesgos. Es evidente que en estos días de negocios globales, la
caída de los sistemas y las redes puede resultar muy costosa para cualquier empresa.
En algunas industrias, TI es un recurso competitivo necesario para diferenciarse y
obtener una ventaja competitiva, mientras que en otras, no sólo determina la
prosperidad sino la supervivencia” (Guldentops, 2003)
Para Dentegra una empresa con un porvenir importante implica rediseñar su estructura
con la que está ampliamente familiarizada y que va desde la alta gerencia hasta los
puestos operativos, con el firme objetivo de incorporar gobierno en su departamento de
TI y así asegurar que la tecnología soporta y facilita el desarrollo de los objetivos del
negocio.
En este capítulo conceptualizaremos las actividades que se requieren, así como la
manera de llevarlas a cabo.
3.1
Plan metodológico
Uno de los primeros alcances de esta propuesta es la de interpretar las distintas
metodologías y plantearlas de una manera simple y natural con los procesos del
negocio. A continuación se presenta este alcance.
3.1.1
Visión general de la situación
En términos generales y por medio del estudio de la situación de Dentegra, vemos que:




Hay (y habrá aún más) un creciente número de clientes que requerirá un nivel
de servicio importante
Hay clientes masivos potenciales (aseguradoras) que pueden formar parte del
grupo de convenios a los que Dentegra ofrece sus servicio
Existe una expansión geográfica tanto del personal como de la distribución de
los asegurados a nivel nacional
Crecimiento de la plantilla de empleados
60
CAPÍTULO 3. PROPUESTA METODOLÓGICA

Desconocimiento de la inversión en TI
Si a esto le sumamos los distintos problemas detectados en el servicio que reciben los
usuarios de los servicios tecnológicos tales como:







Poca disponibilidad de los sistemas informáticos y por consecuencia la pérdida
de oportunidades y clientes
Problemas de integridad en los datos (gestión de pólizas, proveedores, etc.)
Fallas en el proceso de comunicación entre los clientes internos, lo que
ocasiona que las actividades se tengan que repetir varias veces para obtener el
resultado deseado
Lentitud en el acceso y servicio de soporte a las personas que se encuentran
geográficamente distribuidas en el interior de la república
Patrón de comportamiento reactivo a los problemas, según estos vayan
surgiendo
Los mecanismos de comunicación y seguimiento de los problemas no están
bien definidos ni organizados y esto hace que se repitan las incidencias
Los tiempos de respuesta no están estandarizados
Además de factores tales como:




El poco personal existente en el departamento de TI, provoca que las
incidencias se resuelvan si llevar un control
Al no ser capaces de detectar de una manera eficiente los problemas de
nuestro proceso, ni una forma ordenada y consistente de registrar las
incidencias no se tienen las bases suficientes para medir los niveles de calidad
otorgados en la resolución de problemas
Dentegra no es capaz de establecer un nivel de servicio y cumplirlo de manera
garantizada
Se observa además la falta de un sistema de inventario
En conclusión observamos una clara oportunidad para la implementación de mejoras
en los procesos, que van desde el registro y seguimiento de los casos reportados hasta
una manera eficiente de evaluar los procesos y proponer mejoras para la satisfacción
de los usuarios.
3.1.2
Selección de la metodología
Como vimos en el capítulo anterior las metodologías presentadas están orientadas a
mejorar los niveles de calidad en la entrega de los servicios tecnológicos en conjunto
61
CAPÍTULO 3. PROPUESTA METODOLÓGICA
con los objetivos principales del negocio. Si bien estas no son las únicas metodologías
disponibles, para este trabajo se consideraron ambas debido a la relación tan estrecha
entre ellas y acorde a resolver los principales problemas detectados en el
departamento de TI de Dentegra.
Estas metodologías no se contraponen, más bien se complementan, esa es la razón
por la que se decide tomar ambas como marco referencial para desarrollar esta
propuesta e implementación.
Por una parte el enfoque macro de COBIT que nos ayuda a determinar las
necesidades de la organización y plasmarlas en un enfoque orientado a las tecnologías
de información, si a esto le sumamos las características que incorporan las mejores
prácticas como el ITIL al departamento de TI podemos enlistar un conjunto de objetivos
generales (que alinean el negocio con la tecnología) y uno de objetivos particulares
(que alinean los procesos de TI a las mejores prácticas) que durante el desarrollo del
presente trabajo se irán cubriendo, implementando y evaluando para su futuro análisis.
Objetivos generales:









Organizar los recursos de TI para tener procesos más eficientes y medibles
(hacer más con menos)
Delimitar las tareas (roles) y responsabilidades (funciones) del departamento de
TI
Preparación para un crecimiento exponencial debido a los clientes a sus niveles
de servicio
Generación de una estrategia a largo plazo pensando en la posibilidad de
otorgar soporte técnico en cada lugar donde se tiene una representación
Obtener métricas que sustenten la inversión en TI
Un esquema para visualizar todas las actividades del departamento como
proyectos asociados
Implementación de métricas que apoyen a las auditorias
Estandarización en el proceso de soporte técnico en toda la organización
Administrar de manera más eficiente los recursos del departamento de TI
Objetivos particulares:


Tener registro y control de todos las solicitudes de servicios que se realizan al
departamento de TI
Conocer los tipos, categorías y prioridades que se les asignan a las solicitudes
y bajo que esquema se resuelven
62
CAPÍTULO 3. PROPUESTA METODOLÓGICA





Llevar un registro estandarizado de la captura, documentación y solución de
cada solicitud aperturada al departamento de TI
Evaluar y conocer los tiempos de respuesta que se le dan a cada solicitud
Conocer los índices de productividad de los recursos humanos en del
departamento de TI
Obtener un compromiso por parte del usurario así como su visto bueno para
cada solicitud registrada, con la intención de evitar males entendidos y tiempos
muertos por ambas partes
Identificar las solicitudes más recurrentes para poder tomar acciones
preventivas antes que correctivas
De esta manera podemos aprovechar las ventajas que ofrece el establecimiento del
ITIL para poder homologar los procesos y las actividades de las personas encargadas
de resolver, atacar y prevenir los distintos problemas o requerimientos de servicios
tecnológicos solicitados por los usuarios, estos procesos se refieren a las distintas
fases que contemplan la aplicación de las mejores prácticas en relación al soporte y
entrega de servicios, descritos a continuación, durante la delimitación de la propuesta.
3.1.3
Delimitación del problema
Como se describió anteriormente, la consideración de varios factores de negocio y la
restricción de recursos traen consigo que el problema pueda ser exponencialmente
complejo en relación con la propuesta aquí descrita. La intención de este apartado es
delimitar el campo de acción que ocupara la propuesta metodología en la solución de
los problemas antes mencionados.
Por lo que enfocándonos en los objetivos generales del departamento de TI y que
como ya vimos están considerandos para cumplir con ciertos objetivos del negocio,
adicionando los recursos materiales y humanos, así como la estructura organizacional
y técnica del departamento de TI, y considerando el esfuerzo requerido así como el
tiempo establecido para la implementación de la propuesta de solución a continuación
se mencionan los módulos que esta solución propone atacar con el fin de cumplir con
los objetivos descritos con anterioridad.
Para administrar y mejorar el nivel de servicio requerido dentro de la organización, se
propone la implantación de los principales módulos correspondientes al soporte y
entrega de los servicios tecnológicos, la generación de una base de datos que sirva
como enlace entre la entrega de los servicios y los cambios que debe de sufrir la
infraestructura tecnológica de la organización (hardware y software).
63
CAPÍTULO 3. PROPUESTA METODOLÓGICA
En términos generales podemos hablar de la planeación, diseño, implementación y
mejora continua de los siguientes puntos:




La creación de un solo punto de atención y registro de problemas
La definición y conocimientos de los distintos estatus por lo que pasa un
problema antes de ser resuelto así como una correcta comunicación con el
usuario afectado para informarle del estatus en el que se encuentra el problema
anunciado
Poder generar una base de conocimientos para resolver problemas futuros
Establecimiento de métricas para determinar niveles de servicio
Es importante mencionar que durante todo el proceso de implementación los puntos en
los que más se enfoca la propuesta de solución son aquellos que tienen que ver
directamente con el cambio y estandarización de los procesos, por esta razón es que
nos enfocaremos en la entrega y soporte al servicio, que según las mejores prácticas
(ITIL) es en donde se debe trabajar una vez que ya se encuentra en operación un
departamento de TI. Una vez implementadas dichas prácticas en los principales
procesos de atención a los servicios analizaremos y discutiremos en qué medida estos
cambios han impactados a los objetivos generales propuestos con anterioridad.
3.2
Soporte para el servicio
Antes de pensar en cómo resolver un problema es importante conocer todos los
elementos asociados al mismo, el soporte del servicio mismo, son todos aquellos los
elementos que intervienen para poder proporcionar al usuario una atención y un nivel
de servicio necesario para cumplir con sus expectativas y las del negocio.
A continuación se describen estos elementos de manera representativa con la
intención de conocer de una manera general su funcionalidad y poder tener una
relación inmediata entre las herramientas y los objetivos que se intenta cubrir con ellas,
además de conocer la aportación a la solución propuesta.
3.2.1
Punto único de recepción de casos
Se propone un punto de atención único donde el usuario podrá levantar, revisar el
estatus y obtener los tiempos de entrega o de solución del problema reportado, aquí se
describirán las estructuras de soporte existentes y se propondrá una estructura.
64
CAPÍTULO 3. PROPUESTA METODOLÓGICA
Esta herramienta será la base para la generación de conocimiento dentro del
departamento, es decir se registraran las solicitudes de servicio, mismas que se
documentaran y a su vez se obtendrá un VoBo. para su liberación o cierre de caso, con
esta herramienta se conseguirá la estandarización para el registro, documentación y
cierre de solicitudes de servicio, además servirá como una guía para los usuario en el
momento de requerir el estatus de su solicitud.
Con todo esto la herramienta funcionara como repositorio para las preguntas
frecuentes “FAQ” (Frequently Asked Questions), es decir, cada vez que algún miembro
del departamento o usuario requiera de la solución de algún caso o necesite saber
cómo se resolvió su problema debido que se volvió a suscitar estos pueden tener
acceso a la solución otorgada por el departamento de TI.
3.2.2
Gestión de incidencias
La primera consideración que tenemos que realizar cuando hablamos de ITIL es la
diferencia entre ticket, caso, problema, solicitud de servicios, etc. como vimos, ITIL
maneja un lenguaje estructurado y previamente establecido, esto con la finalidad de
evitar cualquier malentendido en la connotación de los términos con alguna otra
metodología y con los mismos vicios propios de la profesión. ITIL define a todos los
“problemas” que tiene el usuario en dos tipos incidencias y problemas (Van Bon Jan,
2008), según sus definiciones y como ya se vio en el capítulo anterior.
“Incidencia: Interrupción no planificada de un servicio de TI o reducción en la calidad de
un servicio de TI. También lo es el fallo de un elemento de configuración que no ha
impactado todavía en el Servicio.
Problema: Causa de uno o más Incidentes. En el momento en el que se crea el
Registro del Problema, no es frecuente conocer su causa, por lo que es necesario
realizar su investigación mediante el Proceso de Gestión de Problemas” (OGC, Office
of Government Commerce, 2006).
Tomando en cuenta estas consideraciones es necesario hablar el “idioma” o nombrar
los fenómenos con los distintos acrónimos que ITIL proponen este caso las incidencias
se serán tratadas de acuerdo a las especificaciones que propone ITIL, es decir, se
describirá el proceso de registro de incidencias que funcionara como una guía para
conocer los pasos a realizar para el registro, documentación y seguimiento, así como
los estatus que deberá mantener una incidencia desde el momento de su creación
hasta la asignación pasando por la jerarquización y hasta el momento de su
aprobación y cierre de la misma.
65
CAPÍTULO 3. PROPUESTA METODOLÓGICA
Se desarrollara en la herramienta de recepción de incidencias una sección de control
de la incidencia en el formulario de levantamiento de información mismo que se llenara
de manera consistente.
Se anexara una sección de notificaciones de la incidencia y una sección donde se
registran las actividades realizadas para la solución del problema, la intención es
mantener un historial y en su caso poder asignar una posible solución a la incidencia
para futuras consultas.
Las métricas serán definidas por la cantidad de incidencias abiertas vs la cantidad de
incidencias cerradas con el fin de evaluar productividades en los recursos humanos del
departamento de TI, otra métrica es el tiempo de resolución de las incidencias mismo
que se determinara por el tiempo transcurrido entre la apertura de la incidencia y su
cierre.
3.2.3
Gestión de problemas
Los problemas estarán definidos por la inconsistencia en los servicios, es decir, una
interrupción constante o muy frecuente de algún servicio en particular nos generara la
apertura y administración de problemas.
Para esto las incidencias deberán contener información estandarizada para poder
detectar este tipo de tendencias, la documentación de la incidencia nos deberá llevara
al análisis de la misma y nos otorgara un punto de referencia para la apertura de un
problema.Una vez detectado el problema se le dará el trato necesario para evitar un
impacto profundo en la disponibilidad de los servicios y a su vez en el negocio.
La administración o gestión de los problemas estará a cargo del gestor, es decir, la
persona encargada del análisis de las métricas de las incidencias y de sus tendencias
de acuerdo a ciertas características definidas en el proceso de apertura de problemas.
Este proceso se documentara y se revisara para aplicarse como un proceso activo
dentro del departamento y estará dentro de las responsabilidades del gestor de
problemas, mismo que se determinara durante la implementación. Debido a la limitante
de los recursos es probable que un mismo recurso humano ejerza varios roles dentro
de un mismo proceso.
66
CAPÍTULO 3. PROPUESTA METODOLÓGICA
3.2.4
Gestión de cambios
Los cambios se deberán realizan de una manera ordenada y con la documentación
requerida. Los cambios pueden ser en software, hardware o procesos, para esto se
deberán describir los distintos procesos que se llevaran a cabo para su solución, tales
como:
 Describir problema o circunstancia
 Análisis de alternativas
 Petición del cambio
 Pruebas
 Aplicación del cambio
 Visto bueno por parte del usuario
 Cierre del cambio
Este proceso se documentara y se pondrá a disposición de todos los usuarios para
estandarizarlo en todos los niveles. El documento incorporara todas las medidas
necesarias para poder registrar, monitorear e informar del estatus de cada cambio
solicitado al usuario final.
Las métricas estarán definidas por la cantidad de cambios requeridos, los tiempos de
respuesta y dependiendo del nivel de complejidad de cada cambio.
En Dentegra los tiempos de respuesta en los cambios pueden ser un factor de éxito
que impactara de manera importante en el negocio y sus resultados, la intención es
que se lleve un control de cambios sobretodo en el los sistemas informáticos que
tienen la carga operativa del negocio y por ello mantendremos un enfoque cercano a
este proceso.
3.3
Entrega de servicio
Para una eficiente entrega de un servicio tecnológico se requiere el establecimiento de
los niveles de servicio (SLA: Service Level Agreement), estos niveles serán la guía
rápida de cualquier colaborador al momento de entregar un servicio o de proponer un
tiempo de respuesta. Además servirá como un referente para todos los usuarios que
requieran el servicio, es decir, para conocer el estatus, el tiempo de respuesta de la
incidencia y el colaborador o persona que está dando el servicio.
Esto además de ayudar al cliente y mejorar la experiencia al momento de recibir un
servicio ayuda a tener estadísticas comparativas para una mejora continua a través de
67
CAPÍTULO 3. PROPUESTA METODOLÓGICA
ejercicios de benchmarking o de encuestas de satisfacción, mismas que se describirán
en la implementación de cada proceso.
3.4
Base de datos relacional
La base de datos relacional deberá estar debidamente asociada a la administración de
la infraestructura tecnológica y es el enlace entre los servicios, proveedores y usuarios
de los servicios.
Se realizara una propuesta, modelos y estructura de la base de datos para relacionar
los servicios con las incidencias (cambios o problemas) y los principales actores
involucrados en la resolución de la misma, es decir, la base de datos es el elemento
central que servirá como inventario de todos los servicios, las relaciones existentes con
los proveedores y los usuarios finales a los hace referencia la solución de una
incidencia, problema o solicitud de cambio.
Si bien esta propuesta no será parte de la solución en la implementación original, si se
generara una propuesta que se puede aplicar en una segunda fase, esto con la
finalidad de generar en Dentegra un valor agregado a largo plazo y que puede ser
benéfico en la administración de recursos del departamento de TI.
Diseño conceptual
El diseño conceptual contendrá los principales objetos así como sus relaciones entre
ellos, el entregable en este apartado será la propuesta de un diccionario de datos que
contenga los nombres de los objetos, sus campos o atributos así como la tipificación de
cada uno de ellos y su longitud, además de las relaciones de dependencia entre ellos.
Si bien no habrá una explotación de los datos se puede recurrir a ellos para obtener
una lista de los distintos recursos tecnológicos, humanos y materiales con los que
cuenta el área.
El diseño conceptual será una guía para futuras aplicaciones que se podrán relacionar
directamente con la implantación de módulos más detallados de acuerdo a las mejores
prácticas, es decir, la intención de esta base de datos además de homologar y
concentrar gran parte del conocimiento de la infraestructura tecnológica de Dentegra
será el cimiento sobre la cual se podrán montar módulos cada vez más complejos de
administración en la entrega y soporte al servicio.
Por el momento y para fines de esta investigación la base de datos se propondrá como
parte de una serie de recursos necesarios para la implantación y el alineamiento a las
68
CAPÍTULO 3. PROPUESTA METODOLÓGICA
mejores prácticas aceptadas generalmente, sin embargo no se espera tener un
beneficio mediático de esta estructura de datos.
3.5
Mejora continua
La mejora continua como un proceso de planeación, acción, revisiones y poner manos
a la obra dentro del departamento esta se sustenta en una línea base, que es un
importante punto de inicio o punto de referencia que permite comparaciones
posteriores con lo realizado. En otras palabras es un punto inicial desde donde puede
ser determinado si un servicio o proceso necesita mejora.
En este caso es importante documentar las líneas base y asegurarse que son
reconocidas y aceptadas, para nuestro estudio e implementación generaremos
encuestas valorativas de los niveles de servicio para las dos principales funciones en el
departamento de TI: desarrollo y soporte técnico.
Las líneas base serán establecidas en los siguientes niveles:



Estratégico - metas y objetivos
Táctico - madurez del proceso
Operativo - métricas e indicadores clave de desempeño (KPI´s)
La línea base se determinara de acuerdo a los objetivos que se planea cubrir
previamente descritos, es decir, deberá enfocarse en los objetivos para los cuales se
pretende la implementación de las mejores prácticas en los dos principales procesos, si
bien esta línea será solo el principio de donde se partirá para posteriores evaluaciones,
deberá reflejar la situación real y objetiva de donde se encuentran los niveles de
servicio del departamento.
3.6
Plan de implementación
Si bien la mejora continua que estamos buscando incorporar a este proceso de
acuerdo a ITIL está ubicado como uno de los últimos pasos a conseguir en la
implementación, para la puesta a punto de todos estos elementos será tomada en
cuenta como la herramienta base de donde partiremos para ir incorporando procesos,
métricas y puntos de control para la evaluación de los resultados obtenidos.
69
CAPÍTULO 3. PROPUESTA METODOLÓGICA
Para efectos de implementación de las mejores prácticas en la entrega y soporte del
servicio partiremos de una evaluación inicial para conocer los indicadores de
satisfacción en los usuarios finales.
Una vez conocida la métrica anterior, se llevara a cabo una serie de actividades
relacionadas con la documentación y justificación del proyecto para Dentegra. Esta
documentación será presentada ante el equipo de trabajo y puesta a consideración
para su mejora y refinamiento.
Con este documento finalizado se continuara con la generación de los distintos
documentos (manuales de proceso) que servirán como guía para el registro, captura y
documentación de cada uno de las actividades que resolverá el departamento de IT.
Además se definirán los reportes por actividad que servirán como base para la
obtención de indiciadores en los niveles de servicio.
Una vez concluidos los manuales de proceso se realizara una evaluación y se
realizaran los cambios adecuados a la herramienta seleccionada para este propósito,
la intención de esta actividad es la de homologar conforme a las mejores prácticas la
herramienta de software. Con esto confirmaremos que tanto proceso, recursos
tecnológicos y humanos están debidamente preparados para la puesta en marcha.
El siguiente paso será el inicio de las operaciones y actividades por parte del
departamento de IT con las nuevas reglas, políticas y procedimientos definidos por las
mejores prácticas.
Se deberá permitir la ejecución de estas actividades al menos tres meses, mismas que
se llevaran a cabo bajo revisiones semanales y los reportes se obtendrán de manera
diaria para el constante monitoreo del departamento.
Por último se aplicara una vez más la evaluación primaria, se registraran los
resultados, mismos que se evaluaran y se analizaran para efectos de obtener las
conclusiones de esta investigación.
70
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN DE LA METODOLOGÍA:
ENTREGA Y SOPORTE DEL SERVICIO
Una vez establecida la metodología descrita, en este capítulo nos daremos a la tarea
de presentar las actividades realizadas durante la construcción de la propuesta. Estas
actividades van desde selección de la herramienta para el soporte del servicio,
pasando por la generación y desarrollo de procesos tales como: la gestión de
incidencias, problemas y cambios, hasta la definición inicial de la base de datos que
almacenara la información para una futura explotación, acuerdos en los niveles de
servicio y un mapeo de las actividades planteadas en ITIL v3 con las actividades dentro
del departamento de TI en Dentegra.
Sin embargo hay que tener presente que los procesos, aplicativos y mejoras
propuestas son importantes para Dentegra en este momento debido a su condición de
reciente creación, en donde con este nuevo modelo basado en servicios tecnológicos
se podrá contar con los beneficios de la metodología a largo plazo.
Esta propuesta cuenta con los principales procesos, gestiones y políticas de la
operatividad de Dentegra por lo que se realiza una implementación considerando la
entrega y el soporte a los servicios tecnológicos delimitados por la dirección. Con el
resultado de esta implementación se presentan los resultados obtenidos así como una
interpretación particular de los beneficios y costos asociados a esta nueva metodología
en Dentegra.
4.1
Herramienta para el Soporte del Servicio
Comenzaremos con el análisis de la herramienta que utilizaremos para el correcto
manejo de la información dentro del departamento.
4.1.1 Punto único de recepción de problemas (Service Desk)
Para el desarrollo de nuestra propuesta y aplicación de las mejores prácticas es
necesario la evaluación, selección y puesta a punto de la(s) herramientas que nos
permitan un registro, seguimiento, almacenamiento histórico y que nos den acceso a
métricas de los servicios que ofrece el departamento de TI.
Uno de los procesos a implementar es la definición de un punto único de recepción de
problemas, que para fines formales y de aceptación de uso generalizado en el ámbito
informático le denominaremos “Service Desk”.
Esto para ser consistente con el ITSM que define al Service Desk como “un servicio
primario y que la intención es proveer un único punto de contacto para usuarios” y
empleados de Dentegra.
Como se dijo en el capítulo 1 Dentegra tiene oficinas en distintas ciudades de la
república mexicana:
71
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN



Ciudad Juárez
Monterrey
Guadalajara
Estas oficinas se encuentran comunicadas por medio de una Red Privada Virtual (VPN
virtual private network) a través de una conexión directa a la red (Internet). Esta VPN
está considerada única y exclusivamente de manera lógica, es decir, solo por medio de
un software, con las medidas de seguridad necesarias para mantener la privacidad y la
integridad de la información de Dentegra. En la siguiente figura se puede ver la manera
en cómo se conectan las oficinas foráneas.
Figura 25. Comunicación interna Dentegra (Elaboracion propia, 2007)
Sin olvidar la dependencia que se tiene del corporativo y la necesidad de mantener
informada a la dirección. Es por esto que debemos analizar las distintas estructuras de
Service Desk que podemos implementar.
Es importante mencionar que la mayoría de los departamentos de soporte técnico
trabajan bajo presión para dar el servicio y reducir los costos y la mayoría de ellos
trabajan también de una manera reactiva, es decir, invierten muchos recursos
resolviendo los problemas de la operación y del día a día y dejando menos recursos
para la planeación y puesta a punto de los procesos internos del centro de soporte y
esto no es ajeno a Dentegra.
72
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
La verdadera aportación de estos puntos de contactos es captar todas las “señales” o
avisos que dan los usuarios al punto de contacto y poder otorgar un valor agregado al
servicio de soporte, para esto es necesario conocer los objetivos del negocio y los
objetivos de los usuarios para que en conjunto se puedan definir los alcances del
Service Desk o punto de contacto.
En muchas organizaciones este punto de contacto tiene distintos nombres, para esta
implementación se utilizara el denominado Service Desk, que se pretende extienda el
rango de servicios de un punto de contacto común y que ofrece un enfoque global al
momento de recabar información desde distintos puntos. Además permite integrar de
manera natural la infraestructura de administración de servicios propuesta por ITIL.
Con esto queremos decir que no solo debe de permitir manejar incidentes, problemas,
etc. si no que también debe de proveer una interface para algunas otras actividades
tales como: requerimientos de cambios mayores, mantenimiento de contratos,
licenciamiento de software, etc.
4.1.2 Diferentes estructuras de Service Desk
Para poder diseñar y/o seleccionar una solución capaz de responder a las necesidades
particulares de cada área, analizaremos los requerimientos de cada representación:
Ciudad Juárez
En la representación de Cd. Juárez se dispone de los siguientes recursos:




2 representantes de ventas
3 equipos de cómputo
Conexión ADSL a Internet de 5 MB
Módulo de impresión
Monterrey
En la representación de Monterrey se dispone de los siguientes recursos:




1 representante de ventas
1 equipos de cómputo
Conexión ADSL a Internet de 2 MB
Módulo de impresión
Guadalajara
En la representación de Guadalajara se dispone de los siguientes recursos:




1 representante de ventas
1 equipos de cómputo
Conexión ADSL a Internet de 2 MB
Módulo de impresión
73
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Al momento de hacer una evaluación para diseñar la estructura que deberá tener
nuestro Service Desk disponemos de tres tendencias. Estas tendencias están
marcadas por la estructura organizacional y los recursos con los que dispone
Dentegra.
Service Desk Centralizado
Mediante esta estructura podemos disponer de un Service Desk central que se
encargara de procesar todas las notificaciones de incidencias que pueden ser por
correo electrónico, llamada telefónica o por medio de un texto de mensajería
instantánea. Considerando el entorno de Dentegra, las principales ventajas y
desventajas de este tipo de Service Desk son:
Ventajas:


Baja en costos debido a que solo se tiene una misma aplicación que proviene
del corporativo
Toda la información está concentrada en una misma base de datos y es
consistente
Desventajas:




Herramienta especializada y requiere de conexiones directas a la base de datos
Capacitación especializada tanto para los que requieren el soporte como las
personas que lo otorgan
La caída del sistema central ocasionaría la inoperancia de todo el Service Desk
No se dispone de suficientes recursos humanos capacitados para poder
atender a todos los usuarios de Dentegra
Service Desk Local
El servicio de Service Desk local indicaría que cada representación tuviera un equipo
especializado para atender todas las incidencias pertenecientes a cada representación.
Dentro de las ventajas y desventajas que observamos:
Ventajas:



Se podrá resolver de manera local y en un menor tiempo los incidentes sin
necesidad de reportarlo a ninguna otra sede
El usuario recibiría un servicio personalizado
Las personas encargadas de los Service Desk locales tendrán un conocimiento
más amplio de las problemáticas y generalmente propondrán soluciones más
acordes a las incidencias y problemas
Desventajas:



Inversión considerable para Dentegra en cada una de las representaciones
Información dispersa en distintas fuentes y base de datos
Menor control de los problemas e incidencias
74
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Service Desk en la nube
En este apartado haremos un paréntesis para explicar la tecnología en la nube,
comúnmente denominada “Cloud Computing”
Cloud Computing (Torres, 2011)
Como sabemos la informática es una disciplina joven si la comparamos con otras
ingenierías, y por lo tanto sus orígenes los podemos remontar a mediados del siglo
pasado en donde John von Newman6 presento el primer modelo estructurado de una
computadora y que aún es vigente.
Las computadoras funcionaban a través de válvulas y bulbos y era de uso únicamente
científico y militar. Después de esto aparecieron los transistores que permitieron
equipos más compactos y sobre todo más rápidos.
Recordemos que fue hasta los años 60 que la informática se incorporó a los negocios y
ya por los años 80 cuando aparece la primera computadora personal y con esto una
serie de beneficios para soportar la operación de prácticamente cualquier actividad
humana.
Sin embargo en estos años una computadora personal solo le podía dar servicio o
atender una sola aplicación y generalmente conectándose a un equipo denominado
servidor, este concepto se conoció como la arquitectura cliente-servidor y como se
presenta en la figura 25 su utilización se logró gracias a la aparición del concepto de
redes locales. En este momento aunque ya se tenía toda la infraestructura necesaria
para la utilización del internet no fue sino hasta finales de los 90 cuando aparecieron
las primeras empresas que ofrecían páginas web.
Yahoo, Google y Amazon fueron de las primeras organizaciones que daban un servicio
amplio a usuarios que se podían conectar desde cualquier lugar con la intensión de
buscar información o adquirir productos sin salir de casa.
Después de este periodo surge la web 2.0 en donde los usuarios ya no solo son
consumidores de información sino que también son productores de la misma, y que
ahora puede ser consumida por el resto de las personas a través del internet. Y así es
como surgen los blogs, paginas personalizadas y por supuesto las redes sociales.
Sin embargo la explosión de los dispositivos móviles en los últimos años conectados al
internet han evidenciado la finalización del concepto cliente-servidor; debido a que hoy
en día los servidores no están preparados para soportar crecimientos repentinos de
usuarios que se pueden conectar desde prácticamente cualquier parte del mundo.
Ahora estos servidores ya no pueden estar alojados en las empresas que crean
programas informáticos (también denominados servicios) por lo que toda la
6
Matemático húngaro-estadounidense que realizó contribuciones fundamentales en física cuántica,
análisis funcional, teoría de conjuntos, ciencias de la computación, economía, análisis numérico,
cibernética, hidrodinámica, estadística y muchos otros campos (Regis, 2008).
75
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
infraestructura de computación y almacenamiento debe desplazarse hacia algún lugar
en el exterior donde se pueda acceder a través del internet. Y a esto es a lo que se le
conoce como Cloud Computing o informática en la Nube del Internet. Esto también
permite que los consumidores, empresas o particulares, no tengan que preocuparse de
la manera en que se prevé el servicio que se necesita, haciendo más sencillos el
consumo e interacción de los recursos tecnológicos.
En la figura siguiente podemos observar los esquemas antecesores del cloud
computing así como su desarrollo a través del tiempo.
Figura 26. Antecedentes del Cloud Computing (Torres, 2011)
Service Desk en la Nube
Como ya vimos este tipo de Service Desk corresponde a un paradigma en donde
distintas organizaciones ofrecen sus servicios tecnológicos a través de la red.
Esto implicaría que cada representación tuviera acceso a un grupo limitado de
servicios en Internet donde podría registrar y dar seguimiento a las incidencias
reportadas. Dentro de las ventajas y desventajas que se observan para Dentegra son:
Ventajas:

Cada sede podrá levantar y dar seguimiento a las incidencias reportadas desde
una misma herramienta
76
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN




Se optimizara el tiempo de captura de las incidencias ya que cada usuario
podrá registrar su propia incidencia
Se obtienen las mismas ventajas que se obtendrían con un esquema
centralizado con la diferencia que la información siempre estaría disponible
gracias a los niveles de servicio que ofrecen los proveedores de esta tecnología
Toda la información está concentrada en una misma base de datos, es
consistente y estaría disponible desde cualquier lugar donde se pueda acceder
a Internet
Reducirían tiempos de desarrollo e implementación de la herramienta debido
que la herramienta está completamente desarrollada
Desventajas:



Por deficiencia de la tecnología toda la información estaría en control de un
proveedor externo
Altos costos y una capacitación intensiva de los recursos encargados de la
administración de la herramienta
Costos altos a largo plazo debido al tipo de comercialización
4.1.3 Propuesta de Service Desk
Cuando un usuario tiene un problema, una queja o alguna pregunta, evidentemente
ellos quieren una respuesta rápida y lo más importante es un resultado o sea su
problema resuelto. Obvio no hay nada más frustrante que hablar al centro de soporte o
departamento sea cual fuese este, y pasar largo tiempo hablando con distintas
personas hasta encontrar a la persona adecuada y que cuando esto pasa sea su hora
de comida o resulta que está de vacaciones.
Un Service Desk eficiente es aquel que en un solo contacto con el usuario se enfoca
en sus principales objetivos y los resuelve, de esta manera mejora el servicio y lo
enfoca al negocio, es decir a soluciones que necesita el usuario. Desde un punto de
vista operacional el objetivo del Service Desk es proveer un solo punto de contacto, y
darle una guía al usuario para una rápida restauración de los servicios.
Los departamentos tradicionales de TI que están enfocados al manejo de la tecnología
y que cuentan con un Service Desk generalmente están conceptualizados con
procesos que provocan que el usuario se sienta incomodo al ponerse en contacto con
ellos y por lo tanto terminan siendo más una barrera para los problemas que un
“solucionador” de problemas y como es de suponer terminan en un fracaso total.
Estos Service Desk están siendo desplazados por departamentos enfocados al servicio
del cliente y que se poyan en el “servicio en equipo” es decir, que incluye gente con
experiencia técnica, conocimiento en el negocio, habilidades interpersonales y que se
apoya en un amplio rango de herramientas tecnológicas.
Esta nueva forma de ofrecer o poner a disposición los servicios profesionales se está
posicionando de una buena manera, ya que incrementa el servicio en varios aspectos y
se enfoca al negocio y va más allá de los servicios que debe proporcionar el
77
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
departamento de TI. Con buenos recursos humanos y herramientas de proceso el
producto generado (servicio) llegara a tener un buen valor agregado sobre todo para la
organización.
La interacción con el cliente
Como sabemos la interacción entre el Service Desktop y el usuario no va más allá de
una llamada telefónica o de un contacto personal, el servicio puede ser mejorado
extendiendo las herramientas que ponemos a la disposición del usuario, es decir
mejorando la manera de registro, actualización de las incidencias, búsqueda de
soluciones, etc. esto lo podemos observar en la figura 27, donde los métodos como
correo electrónico o Internet para las oficinas remotas puede ser la solución en cuanto
a tiempo y costo. Estos también pueden ser utilizados para actividades que no son
críticas para el negocio y tienen ciertas ventajas tales como:




Registro propio de las incidencias
Aplicaciones donde puede obtener sus propios reportes
Se puede solicitar movimiento de equipo, instalaciones de nuevos productos de
software, actualizaciones, etc.
Requerimientos para solicitar cosas como consumibles, papelería, etc.
Y esto trae algunos beneficios al equipo que otorga el soporte como:


El soporte personal no es necesario (interrupciones en el teléfono)
El trabajo se puede administrar de mejor manera
El uso de este tipo de administraciones basadas en las entradas o registro del usuario
incrementa la integridad de los datos que proporciona el usuario gracias a que se
puede determinar qué tipo de soporte o especialista requiere la incidencia para ser
trabajada y final cerrada.
Evidentemente la herramienta que utilice el Service Desk deberá proporcionar un
número único que el usuario podrá dar seguimiento a lo largo de todo el proceso para
resolver su incidencia.
Mantener al usuario informado
El proveer la confirmación de que su incidencia ha sido aceptada por medio de alguna
figura o forma y que está en progreso, es uno de los roles más importantes del Service
Desk, incluso muchas de las organizaciones que conocemos trabajan en este aspecto,
sin embargo el cambio real es crear una manera rápida y económica (en todos los
sentidos) para personalizar esta forma de mantener informado al usuario.
La propuesta de Service Desk para Dentegra y que integramos en este trabajo pasara
por un híbrido entre las estructuras planteadas en los puntos anteriores (centralizado y
en la nube), con esto se busca extraer las principales ventajas de cada una.
78
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Figura 27. Entradas del registro de incidencias (Elaboracion propia, 2007)
Objetivo de la propuesta





Atender a todos recursos de todas las sedes bajo los mismos niveles de
servicio
Optimizar en todo momento el uso de los recursos disponibles
Tener a recursos capacitados para resolver todo tipo de incidencias en el
Service Desk centralizado
Disponer de una lista de preguntas frecuentes en la red, con el fin de agilizar el
proceso de resolución de incidencias
Tener en tiempo real la situación, estatus y camino que va recorriendo la
incidencia hasta su solución
Optimización de los recursos
Dada la importancia de la implementación de un Service Desk y con la finalidad de que
los usuarios lo acepten de la manera más transparente, se decidió generar un proceso
para el levantamiento de incidencias en Dentegra.
Este proceso contempla:



Objetivo
Diagrama de flujo
Descripción narrativa
La intención de esta propuesta que es los mismos usuarios sean los responsables de
levantar, registrar y documentar (con sus limitaciones) las incidencias, de esta manera
se pueden optimizar los recursos en el departamento de TI, con sus debidas
limitaciones.
79
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Es decir el hecho de los usuarios registren las incidencias puede ocasionar otro tipo de
problemas mismos que se consideran más adelante y se definen procesos para evitar
inconsistencias al momento de registrarlas.
En caso de que el contacto sea de manera tradicional, es decir, por teléfono, presencial
o por algún medio conocido en donde no se registren las incidencias directamente en
la herramienta seleccionada para esta función, el agente de soporte técnico será el
responsable de registrar, documentar e informar la situación de la incidencia al usuario.
Por supuesto la intención de esta herramienta es evitar al máximo que el agente de
soporte registre la incidencia esto debido a que se requieren optimizar los tiempos del
agente y el registro es una de las actividades que pueden realizar los usuarios.
Dentro de la figura 28 observamos los 3 componentes principales del Service Desk
propuesto que son:

Cloud computing: Esquema que provee una aplicación para la recepción,
registro, captura, seguimiento y cierre de cada una de las incidencias
reportadas por el usuario

Esquema de cliente servidor: Esta arquitectura es importante debido a los
tiempos de respuesta que requiere el usuario final para poder gozar de todos
los beneficios de los servicios, es decir, debido a la infraestructura adquirida en
Dentegra la mayoría de los servicios proporcionados por el departamento de TI
están en servidores propios o sea localizados en el interior de la organización y
por lo tanto no podemos prescindir de esta arquitectura

Procesos en paralelo: Estos procesos en paralelo son básicamente los
procedimientos realizados de manera interna para poder mantener en un nivel
aceptable los servicios ofrecidos, en otras palabras para la solución de algunas
incidencias es requerido el apoyo del service desk interno que como ya se
comento está disponible en las oficinas centrales de Dentegra en Estados
Unidos. Este centro de servicio hace las funciones al momento de tener que
escalar el problema a un ingeniero especializado con el cual cuenta el
corporativo de Dentegra
El Service Desk entonces representa el único contacto que tiene el usuario final con el
departamento de TI a través de teléfono, correo electrónico, pagina web, etc. en donde
el usuario final o en su caso el ingeniero que esté tomando el reporte registra y asignan
una prioridad a cada una de las incidencias reportadas.
Una vez que el registro se encuentre en la base de datos de la aplicación se enviara un
correo electrónico a un ingeniero disponible o en caso de que el ingeniero este
registrando dicha incidencia será el responsable de darle el seguimiento
correspondiente. Este seguimiento implica la generación de la replicación del
problema, generar posibles soluciones, pruebas, solicitar el visto bueno por parte del
usuario final y por ultimo cambiar el estatus de la incidencia a “cerrado” cuando
concluya con todas las actividades, además de reportas todas aquellas actividades
requeridas para encontrar la solución dentro de la misma base de datos.
80
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
En la figura siguiente podemos ver el esquema hibrido propuesto para el Service Desk
de Dentegra:
Figura 28. Diagrama del Service Desk híbrido (Elaboracion propia, 2007)
Con este esquema abarcamos las principales actividades que se requieren para
otorgar un servicio de buenas condiciones:





Se limita a una aplicación el proceso para registrar las incidencias
Se registran las acciones que se realizaron para la solución de la incidencia aun
cuando estas no hayan solucionado el problema
Se tiene un estatus único de la incidencia
En caso de que se requiera escalar el problema a un ingeniero especializado se
tiene concentrada la información
Se tiene acceso a esta base de conocimientos desde cualquier parte (internet)
4.1.4 Aplicación utilizada en el Service Desk
La tecnología utilizada para la implementación del Service Desk será Sales Force©.
Esto debido a que Dentegra ya cuenta con esta herramienta y el esquema de
licenciamiento permite reducir costos en la incorporación de una herramienta
81
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
especializada, sin embargo se tiene que hacer una tarea de configuración y puesta a
punto para el correcto funcionamiento de la herramienta.
A continuación daremos una breve descripción de Sales Force© con el fin de
familiarizarse con la tecnología.
Sales Force©
“Salesforce.com es la compañía que ofrece cloud computing para empresas.
Ofrecemos aplicaciones comerciales a través de Internet para empresas de todos los
tamaños. Se puede acceder a nuestras aplicaciones Sales Cloud, Service Cloud y
plataforma Force.com a través del explorador web. El usuario paga una suscripción
mensual que le permite gestionar y desarrollar aplicaciones comerciales de todo tipo
sin necesidad de hardware o software” (Sales Force, 2008).
Sales Force© fundada en marzo de 1999, como una compañía especializada en
software como servicio (software as a service).
Productos
El principal producto es “Software para la administración de la relación con los clientes”
por sus siglas en ingles CRM (Customer Relationship Management).
El CRM de Sales Force© está dividido en varias categorías:





Sales Cloud
Service Cloud
Data Cloud
Collaboration Cloud
Custom Cloud
Sales Cloud
Es una aplicación que corre en la nube (cloud computing) y sirve para que la fuerza de
ventas de una organización pueda acceder a los datos de sus clientes en tiempo real y
sin ninguna restricción. De esta manera el representante de ventas puede tener
información actualizada en su computadora únicamente con una conexión a Internet.
Service Cloud
Una de las categorías más explotadas es el servicio en la red, si bien el servicio es
proporcionado generalmente por equipos de call center que están fijos en alguna
localidad la información de registro, documentación y seguimiento del “caso” levantado
reside en una aplicación en la nube y esto hace que la información pueda publicarse,
compartirse y enviarse de manera natural a cualquier red social o correo electrónico.
82
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Data Cloud
Debido a que todas las aplicaciones residen en la nube evidentemente los datos
también, si este servicio que se ofrece es parte de una administración y
almacenamiento de datos en la red.
Collaboration Cloud
El servicio de colaboración incluye una herramienta de mensajería instantánea, propio
de Sales Force© llamado Chatter©. Esta herramienta permite compartir datos e
información tales como documentos, etc. para las personas involucradas.
Custom Cloud
Por último la configuración de la herramienta permite al usuario (cliente) poder adecuar
todas sus pantallas y formas de sus sistemas de manera personalizada, además
permite la generación de un portal en la nube que da la flexibilidad a los usuarios
(clientes de Sales Force©) de atender a sus clientes (cliente de los clientes de Sales
Force©).
Como se describió anteriormente esta herramienta cuenta con una aplicación enfocada
al servicio, y esta será la aplicación que se utilizara en el departamento de TI para el
registro, carga, documentación, seguimiento y extracción de la información relacionada
con los incidentes.
Debido a que la herramienta está en la nube, se puede acceder prácticamente desde
cualquier lugar que tenga una conexión de Internet y que cuente con una licencia
activa.
El uso y la capacitación de la herramienta será parte del proyecto de implementación,
para esto se cuenta con una licencia “Premier Training” adquirida por Dentegra para
tener acceso a los principales cursos on-line que ofrece Sales Force© para todos sus
clientes.
Dentro de las principales ventajas de esta herramienta es el uso de los datos en la
nube y su fácil publicación en medios electrónicos, es decir, con esto podemos
incorporar de una manera eficiente y sin costos adicionales páginas de ayuda tales
como las FAQ o aplicaciones distribuidas para equipos móviles tales como iPhones o
BlackBerries.
Casos en Sales Force©
Dentro de Sales Force© existen registros conocidos como “casos” estos son
básicamente registros que nos ayudan a capturar la descripción de un problema, una
pregunta o información que requiere algún cliente o usuario de Sales Force©.
Para adecuar Sales Force© a las mejores prácticas utilicemos los “casos” para resolver
problemas de los clientes, ya que se puede crear, modificar, actualizar y visualizar los
registros con suma rapidez desde el fichero o forma de “casos”.
83
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Para agilizar este proceso los casos se pueden crear desde un correo electrónico o vía
una página web (se requiere cierta configuración y programación), también incluyen
ciertas características que nos servirán de ayuda en las incidencias al momento de
implementar las mejores prácticas como lo son:
Asignación de casos: Esta asignación puede ser dos maneras, asignación a un usuario
en particular o a una cola o equipo de usuarios. Y esto a su vez puede hacerse de una
manera manual o por medio de una regla de asignación al crear o modificar un caso.
Cada que un usuario tome la responsabilidad de revisar y resolver un caso, estaremos
hablando de que toma la “propiedad” del caso y por lo tanto es responsable de darle el
seguimiento correspondiente hasta la finalización del caso. Los casos también pueden
ser reasignados a otro usuario o a otra cola de usuarios.
Vistas de casos: Para cada caso pueden existir más de una cola o usuarios a los que
se les asignen casos, para facilitar su búsqueda y en general para limitar el número de
registros que visualiza el usuario se pueden crear vistas para observar única y
exclusivamente los registros asignados a este usuario o cola de usuarios.
Vista jerárquica de casos: Otra de las funcionalidades de Sales Force© en cuanto a
casos es la relación que puede existir entre uno o más casos, esta relación se ve
claramente en la lista relacionada que tiene cada caso con casos asociados, esto es
cuando se asocia un caso “simple” con un caso principal decimos que tenemos casos
relacionados o una relación entre casos, esto ayuda a poder relaciones uno a muchos
para casos que dependen directamente uno de otros o cuando queremos determinar
‘problemas’ provenientes de incidencias.
Cambio de estado o cierre de casos: Una de las principales actualizaciones que
sufrirán los casos ocurre cada vez que vaya cambiando de estatus el caso, es decir
mientras el usuario se encuentra resolviendo el caso este puede ir sufriendo ciertas
modificaciones sobre todo es su estado, así hasta llegar a la finalización o cierre del
caso. Una vez que el caso cambie de estado se deberá documentar el cambio de
estado y en caso de cierre o finalización se exige una breve descripción del cierre de
casos para así conformar la base de conocimiento.
Correos electrónicos desde casos: Una de las principales herramientas para el
monitoreo y seguimiento de los casos es la información enviada al cliente, es decir
cada vez que se haya una actualización del caso o se requiera alguna ayuda por parte
del cliente se pueden registrar eventos o correos electrónicos enviados al cliente para
poder resolver el caso, de esta manera se puede tener un completo historial de las
actividades que realizo el usuario para resolver el caso y sobretodo de las
notificaciones que se le hizo al cliente en caso de haber algún malentendido.
Solución de casos: Esta funcionalidad se refiere a la documentación requerida para
resolver un caso, es decir cada vez que se registran los comentarios que llevaron a la
solución de un caso un administrador puede seleccionar la mejor respuesta o
comentario para posteriormente publicarlo como una solución de algún caso en
particular.
84
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Informes (reportes) en Sales Force©
Esta herramienta ofrece una gama de herramientas analíticas para visualización y
análisis de datos. Sales Force© cuenta con una herramienta llamada “Analytics” que se
compone de múltiples secciones:





Tipos de informes: “Se define como un conjunto de registros y campos
disponibles en un reporte basado entre un objeto principal y sus objetos
relacionados” (Sales Force, 2008)
Informes: “Un informe o reporte devuelve un conjunto de registros que cumple
con ciertos criterios y los muestra en filas y columnas” (Sales Force, 2008)
Paneles: Los paneles en Sales Force© son una representación icónica de datos
con origen en un informe y estas pueden ser gráficas, indicadores, tablas o
páginas en un browser. El fin de estos paneles es proporcionar es proporcionar
un indicador (según sea el caso) de los datos en tiempo real
Carpetas: Como el concepto en Windows, las carpetas sirven para almacenar
informes, paneles, documentos o plantillas diseñadas y desarrolladas
previamente en Sales Force©
Instantáneas analíticas: Estos indicadores (datos) nos permiten crear informes
a través de datos históricos, es decir, se pueden guardar los resultados de
informes tabulares en los campos de un objeto personalizado y asignar los
mismos a un objeto destino. Así se podrá crear un informe a través de datos
previos de otro informe
Con esta descripción breve de la herramienta a utilizarse para el Service Desk es
importante mencionar que el Service Desk debe de mantener al tanto y de manera muy
cercana entre el proceso de administración de incidencias y la gestión de problemas y
cambios, ya que si no controla estos procesos es muy probable que los cambios
generen nuevas incidencias y se pueda volver un círculo vicioso. Por eso las mejores
prácticas recomiendan mantener en el mismo esquema (base de datos) los registros
de los problemas y los cambios con la intención de mejorar la administración de los
mismos.
Otra de las recomendaciones es que las prioridades y procesos de jerarquización sean
acordados entre las partes para en conjunto obtener los SLAs.
Por último comentaremos que el Service Desk deberá ser el único punto de contacto
entre las personas encargadas de dar el servicio de soporte y los usuarios y esto
deberá ser un acuerdo entre las partes para evitar cualquier problema a futuro. Para
esto se deberá considerar que los usuarios deberán tener acceso a la herramienta de
manera continua y establecida por medio del proceso de administración de incidencias
con la intención de que el usuario pueda utilizar la herramienta y así como sus
funcionalidades para mantenerse al tanto del progreso de sus incidencias
independientemente de que sea una responsabilidad del Service Desk mantener
informado al usuario.
85
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
4.2
Gestión de incidencias
De acuerdo a la definición de incidencia “Cualquier evento que no es parte de la
operación estándar de un servicio y que esto causa o puede causar una interrupción o
la reducción en la calidad del servicio” (HMSO, Her Majesty's Stationery Office, 2007).
La infraestructura para mantener las incidencias según ITIL v3 se presenta en la
siguiente figura:
Figura 29. Infraestructura de Incidencias (Elaboracion propia, 2007)
Considerando las mejores prácticas, cuando un incidente es registrado este deberá ser
automáticamente enrutado a la persona adecuada o al grupo de personas adecuadas
para resolver el incidente, sin embargo si la incidencia no ha sido tomada o recibida por
alguna de estas personas el proceso de jerarquización se alertara automáticamente y
el Service Desk deberá realizar una acción.
Otras de las funciones que sugieren las mejores prácticas para el Service Desk es
hacer las veces de un único punto de contacto entre los proveedores de servicio y los
usuarios finales, evidentemente este es un punto crucial para el reporte de incidentes y
hacer requerimientos de nuevos servicios y de mantener informado al usuario final, y la
intención es hacer del Service Desk una herramienta de uso diario.
Así es como el Service Desk se convierte en el parámetro de impacto directo en los
niveles de servicio y necesita flujos de información rápidos para que sea una
herramienta confiable y sustentable a lo largo del crecimiento de la organización.
Utilizaremos Sales Force© como nuestra aplicación de Service Desk, manejaremos
una categorización única para las incidencias, se desarrollaran los flujos de los datos
para que otorgue información confiable y de una manera rápida y se generara un plan
de capacitación para que todos los usuarios aprendan a utilizar la herramienta, de esta
manera estaremos realizando la entrega del servicio de Service Desk para Dentegra.
86
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
4.2.1 Proceso de gestión de incidencias
La definición del proceso para gestionar las incidencias en Dentegra está representado
en el siguiente diagrama:
Continúa…
87
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Figura 30. Proceso general de gestión de Incidencias (Dentegra Seguros Dentales, 2008)
Se considera el inicio del proceso con un contacto por parte del usuario que puede ser
de distintas formas:




Administrador de eventos: Debido a que en Dentegra existen distintas formas
de tener contacto con el personal técnico se decidió agrupar estas
circunstancias como un evento para fines de administración, el administrador de
evento solo funciona como una figura que agrupa los contactos de tipo
presencial, cuestionamientos rápidos (pasillo), incidencias levantadas por otro
usuario cuando detecta algún problema, etc.
Llamada telefónica: Incidencias que pueden ser levantadas por el usuario final o
en su caso por el Call Center (interno de Dentegra) a favor de algún cliente
externo
Correo electrónico: Herramienta utilizada generalmente para darle formalidad al
levantamiento de la incidencia o en su caso como contingencia cuando el portal
web (service desk en la nube) interrumpa sus servicios
Interfaz Web: (Service Desk en la nube) esta será la forma de levantar las
incidencias de manera natural para los usuarios internos para optimizar los
tiempos de respuesta. Únicamente por esta vía consideraremos que la
incidencia estará registrada
Durante esta parte del proceso de la incidencia se hace del conocimiento del personal
responsable del Service Desk sin siquiera tomar alguna acción al respecto. Esto se
identifica en el proceso con la intención de iniciar el flujo que tomara la incidencia más
88
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
sin embargo aún no forma parte como tal del proceso de gestión de incidencias, en
otras palabras no afecta los SLA’s ni a sus métricas.
Identificar incidente
Una vez contactado al personal del Service Desk la primera responsabilidad de este
funcionario es reconocer la interrupción o la degradación de uno o varios servicios a los
que tienen acceso los usuarios.
Este primer filtro nos evita pasar a la siguiente etapa del proceso donde por error se
pueden registrar incidencias que no corresponden como tal a la interrupción de un
servicio, de ser así la información contenida en las métricas se podría ver severamente
afectada ya que se puede contener información repetida o simplemente sin sentido que
aumenta el volumen de la misma y por lo tanto deja de ser oportuna.
Registrar incidente
Una vez identificada la incidencia el registro eficiente es de suma importancia para el
seguimiento, documentación y cierre de la incidencia reportada. El proceso de registro
de una incidencia se describirá de manera detallada en la siguiente sección dando una
alta prioridad a la forma, llenado y captura de la misma.
Categorizar incidente
La figura 30 es una representación gráfica y general del proceso de gestión de
incidencias, para Dentegra se identifican básicamente 6 tipos de incidencias que
comprenden las necesidades del negocio y de la operación establecida hasta este
momento. Estas categorías son independientes entre sí y pueden ser modeladas para
incidencias, cambios y problemas según sea el caso, con tal de robustecer esta
propiedad dentro de Sales Force© se definen un conjunto de campos asociados para
identificar de manera precisa la categoría y tipo de incidencia que se está registrando,
de esta manera el personal del Service Desk podrá enfocarse a una solución en
concreto para cada incidencia. Otra de las funciones de esta categorización es
determinar si el registro de la incidencia trae consigo el desarrollo e implementación de
un nuevo servicio, en caso de que sea así nos referiremos a los requisitos necesarios
para dar de alta un nuevo servicio, o sea al cumplimiento de los requerimientos
necesarios para este servicio.
Para efectos de este trabajo no estamos considerando el Service Desk como una
herramienta para el registro, captura y seguimiento de incidencias que deriven a un
nuevo servicio, esto debido a que como se comentó en el capítulo 1 Dentegra depende
directamente de su corporativo que es el encargado de las definiciones, registro,
implementación y puesta a punto de cada uno de los nuevos servicios. Para efectos
prácticos de esta implementación tomamos como base el hecho de que las mejores
prácticas serán implementadas única y exclusivamente para el registro de incidencias
que se generen debido a la interrupción de un servicio previamente implementado.
Priorizar incidente
89
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
De acuerdo a ITIL v3 la herramienta utilizada para la gestión de incidencias define de
manera automática la prioridad de acuerdo a factores dados y generalmente asigna
prioridades por default, para este caso y debido a que Sales Force© se puede adecuar
pero sin embargo no es una herramienta alineada 100% a las mejores prácticas este
proceso se queda a cargo del responsable del registro de la incidencia. Con esto no
decimos que se deba realizar de una manera inadecuada, con una correcta
capacitación y una constante supervisión, los registros de las incidencias deberán ser
registradas de una manera óptima. Otra de las razones por la cual no se puede adquirir
una herramienta especializada es debido a la intensa capacitación que deberán sufrir
los recursos y que se vería reflejado en un costo operativo, además de los costos
asociados a la implementación de una nueva herramienta.
Con este proceso el responsable deberá identificar si es un incidente mayor y aplicar
las medidas correspondientes a este nuevo proceso, en términos generales el
procedimiento de un incidente mayor va directamente relacionado con los tiempos de
respuesta, es decir cuando el responsable determine que es un incidente mayor
actualizara la prioridad a nivel 1 (Crítico) y deberá informar de manera inmediata a su
supervisor o al administrador en turno del registro de la incidencia, así como el número,
antecedentes y hora en la que se recibió el primer contacto por parte del usuario, en
caso de que la incidencia sea determinada por el mismo responsable del registro de la
incidencia este deberá hacer la veces del responsable de los procesos “Investigar y
diagnosticar” así como del proceso “Resolución y recuperar” en caso de que la
incidencia amerite estas acciones.
Diagnóstico Inicial
Esta parte del proceso se considera parte de la solución de la incidencia ya que implica
un análisis, evaluación y toma de decisiones de acuerdo al diagrama.
Existen diversas formas para la solución de una incidencia sin embargo la razón de
tener un diagnóstico inicial es para poder identificar de una manera fácil y rápida
aquellas incidencias que se consideren por su naturaleza de mayor rapidez en su
solución, esto para saber si la incidencia se tiene que escalar o no, en alguna de las
formas de jerarquización: Funcional (horizontal) o Jerárquico (Vertical).
Como su nombre lo dice: escala Funcional se refiere a derivar la incidencia hacia otro
departamento, área o en su caso encolarlo a otra fila del mismo Service Desk con la
intención de darle el seguimiento adecuado, esto generalmente sucede cuando
sobrepasa los conocimientos de la persona encargada de la incidencia o este tipo de
conocimiento pertenece a alguien más.
La escala Jerárquica se presenta cuando una incidencia después del diagnóstico inicial
se determina que la posible solución implica la generación, cambio o redefinición de
algún servicio ya en uso, para esto se deberá informar al usuario que después de una
análisis inicial se requiere una autorización y que deberá darle el seguimiento
correspondiente en caso de que se requiera su intervención, con estas dos formas de
derivar la incidencia se garantiza que ninguna persona del Service Desk puede
anteponer o decidir sobre el uso y manejo de los servicios y mucho menos de la
prioridad con la que se deberán atender las incidencias.
90
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Investigar y diagnosticar
El diagnostico en esta etapa del proceso es considera como un diagnostico-solución,
ya que previamente se realizó un análisis, evaluación y se consideraron las distintas
posibilidades para solucionar la incidencia.
El resultado final de este proceso es hacer un análisis exhaustivo de la incidencia, sus
causas, posibles efectos y distintas rutas de solución, ya con esta información
podemos iniciar la siguiente actividad.
Resolución y recuperar
En algunos casos las incidencias se puede tratar del mal funcionamiento de un servicio
físico, como lo puede ser: una impresora, un teclado, etc. y en algunos otros de
servicios tales como el correo electrónico, servicio de datos (base de datos), etc.
Le llamamos resolución cuando un problema “físico” es resuelto, pero para los casos
en los que el problema es una pérdida de datos, de correos electrónicos, o de
documentos le llamaremos recuperación.
Resolver
Generalmente dentro de cualquier área de servicio el encargado de restablecer el
servicio afectado realiza una serie de actividades y da por un hecho que el servicio fue
restablecido de manera normal, sin embargo eso no quiere decir que realmente el
servicio funcione o que esté funcionando al 100%, para esto aún se requieren generar
pruebas por parte del usuario responsable y que estas pruebas estén validadas por el
usuario final, sin embargo y debido a la experiencia se actualiza la incidencia como
resuelta para indicarle al usuario que está atendida la incidencia más aún falta el último
paso.
Cerrar
Para cerrar una incidencia se requieren dos cosas principales: el visto bueno del
usuario (previas pruebas puntuales y generales) y la documentación correspondiente.
En el Service Desk será de suma importancia cerrar de manera debida todas y cada
una de las incidencias para cumplir con los requisitos de las normas y políticas y como
un indicar de la calidad en el trabajo realizado.
Acabamos de describir el proceso general de la gestión de incidencias y la manera en
como el Service Desk deberá llevar paso a paso cada una de estas, sin embargo
tenemos que categorizar de manera particular cada una de la incidencias que se
presentan en Dentegra como parte de una operación diaria.
De acuerdo a los recursos con los que cuenta el departamento de IT y considerando
que el Service Desk es parte fundamental del departamento todos los integrantes del
equipo deberán formar del Service Desk distribuidos de la siguiente manera:
91
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN

Coordinador de Soporte
o Soporte Técnico
o Administración de usuarios

Coordinador de Proyectos Especiales
o Sales Force©
o Proyectos Especiales
o Solicitud de reporte

Coordinador de Desarrollo
o Healthcase (Desarrollo hecho en casa)

Gerente de Sistemas
o Gestor de Incidencias
o Gestor de Problemas
Una diferencia significativa en los recursos humanos del departamento de TI en
Dentegra se ve reflejada en este punto del trabajo, en el capítulo inicial
considerábamos un equipo de dos personas para esta labor, sin embargo y debido a la
gran cantidad de responsabilidades adquiridas y al incremento en el volumen de las
operaciones la gerencia se vio en la necesidad de incrementar la plantilla del
departamento en dos posiciones más, esto aun antes de la implementación de las
mejores prácticas, más adelante se considera el ingreso de un ingeniero más para
poder cumplir con los compromisos adquiridos por el departamento de TI.
Más adelante en las descripción de las aperturas de incidencias encontraremos las
distintas categorías en las que se pueden clasificar las incidencias, así como la manera
en como deberán de revisar las incidencias abiertas de acuerdo a la clasificación del
soporte.
Para evitar que los procesos del diagrama general de incidencias puedan parecer de
ambiguos o confusos se generan procesos específicos para la gestión de incidencias
de soporte y de cambios en las aplicaciones, vale la pena mencionar que las
incidencias clasificadas como Proyectos Especiales y Solicitudes de Reportes se
comportan de la misma manera que las incidencias de soporte por lo que el proceso
para registrar y darle mantenimiento a estas incidencias será el mismo que soporta a
las incidencias de tipo soporte.
Proceso de Incidencias de Soporte Técnico
A continuación se presenta el proceso (Dentegra Seguros Dentales, 2008):
92
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Índice del Manual
No. Página
1.
2.
3.
4.
Objetivo
Diagrama de Flujo
Descripción Narrativa
Catálogos
1
1
2
5
1. Objetivo:
Administrar y documentar de forma eficiente los incidentes y requerimientos de Soporte
Técnico que sean solicitados al Departamento de Sistemas; para efectos de seguir las mejores
prácticas y lograr una Gestión de Servicios IT exitosa.
2. Diagrama de Flujo:
93
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
3. Descripción Narrativa:
Responsable
Descripción

Solicita STS

El usuario puede requerir una STS por los siguientes medios:
Portal Web: Salesforce (SF)– Mis Casos – Requerimiento
Sistemas
E-mail: Correo Electrónico (Si no cuenta con acceso a
Salesforce)
Llamada telefónica
Communicator (Chat)


Usuario








Líder
de 
Proyecto
/
Coordinador
Sistemas




Clasifica STS
Se debe clasificar el incidente para efectos de determinar si es un incidente
que puede afectar la producción, o un requerimiento.
Registra STS
Aun cuando el usuario pudo haber registrado el caso en SF, es
responsabilidad del Líder de Proyecto o Coordinador de Sistema el registro
completo del caso utilizando el Tipo de Registro “Requerimiento Sistemas”.
Prioridad: Registra Nivel 1, 2, 3 ó 4 de acuerdo al Anexo.
Fecha de Solicitud: Fecha en que se solicitó la STS.
Nombre del Contacto: Todo usuario debe estar registrado
en la cuenta de Salesforce “Empleados Dentegra”. Ver Anexo.
Se debe registrar al usuario o contacto principal de la STS.
Origen del Mis Casos: Se documenta cual fue la forma en que
se recibió originalmente el caso: Correo Electrónico, Teléfono,
Salesforce.
Estado: El caso al momento de registrarse debe tener el Estado
“Nuevo” y debe actualizarse este campo de acuerdo a la etapa
de Desarrollo del mismo. Ver Anexo.
Clasificación de Soporte: El caso debe clasificarse de
acuerdo al Anexo.
Tipo de Soporte: El Tipo de Soporte es dependiente a la
Clasificación de Soporte. Ver Anexo.
Responsable de Caso IT. Se debe seleccionar a la persona
responsable por parte de Sistemas del Caso.
Asunto: Se registra el título que mejor describa a la STS,
utilizando el siguiente esquema:
SISTEMA – ISSUE – USER/GROUP AFFECTED
e.g. Outlook – Configuración de Perfil – Nuevo empleado


HealthCase – Sistema no disponible - Operaciones
Antecedentes: Se registra de forma breve las causas y
justificación que dan origen a la STS.
Descripción: Se registra a detalle la STS con los datos
proporcionados inicialmente por el usuario. Este campo deberá
mantenerse actualizado a lo largo del desarrollo de la STS y
94
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Responsable
Descripción
debe reflejar claramente los requerimientos del usuario.
Una vez registrado el caso SF genera un número de caso.



Líder
Proyecto
Coordinador
Sistemas









de
/ 


Documenta STS
Tanto el líder de Proyecto como el Coordinador de Sistemas deben
mantener una documentación detallada en todas las fases de la STS. Los
casos se documentan considerando lo siguiente:
Campos de documentación
Antecedentes: Debe reflejar de forma breve la justificación que
da origen a la STS.
Descripción: Debe reflejar claramente los requerimientos del
usuario o proyecto, tomando en cuenta el siguiente Checklist
básico:
Nombre completo del usuario
Teléfono con Extensión
Segundo Contacto / Teléfono (ext)
Usuario de Red ( si aplica)
Usuario SF ( si aplica)
IP ( si aplica)
Descripción de Incidente o Requerimiento
Workaround ( si aplica)
… etc.
Reporte Sistemas: Deberá describir a detalle la identificación del
problema, las soluciones propuestas, la solución elegida y su
justificación, así como las principales actividades realizadas
durante el desarrollo de la STS. Puede incluir la propuesta de
nuevos requerimiento o proyectos. El reporte de Sistemas
servirá como una base de conocimientos de la empresa y
ayudará a resolver casos futuros similares de forma más rápida.
Horas Sistemas: Debe reflejar las horas invertidas por Sistemas
en el desarrollo de la STS.
Comentarios: Se pueden incluir comentarios de cualquier
miembro del equipo que esté participando en el desarrollo de la
STS. Cuando el usuario no tenga acceso a Salesforce es
recomendable utilizar la opción de Chatter para poder
colaborar en equipo.
Tareas:
Durante el desarrollo de la STS se deberán registrar todas las
tareas relacionadas y el Líder de Proyecto deberá verificar su
oportuno cumplimiento.
Eventos:
Las juntas de trabajo, conferencias telefónicas, sesiones de
capacitación, etc. deberán programarse como eventos en SF y se
agregaran las minutas o reportes correspondientes.
95
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Responsable
Descripción
Llamadas:
Durante el desarrollo de la STS se deberán registrar todas las
llamadas realizadas relacionadas con la STS describiendo los
acuerdos o detalle de la llamada.
Correos Electrónicos:
Durante el desarrollo de la STS se deberán enviar desde el Caso
de SF todos los correos electrónicos relacionados con la STS.
De la misma manera se agregarán los correos relacionados que
sean relevantes y que se reciban por medio de Outlook.
Archivos Adjuntos:
Todos los archivos relacionados a la STS deberán ser agregados
al caso.
 Resuelve STS
El Líder de Proyecto o Coordinador de Sistemas desarrolla las actividades
requeridas para cumplir con las especificaciones de la STS de acuerdo a los
procesos establecidos en cada caso.
Es importante que si la resolución no está al alcance del de Proyecto o
Coordinador de Sistemas, se escale debidamente como se muestra en el
diagrama de Flujo; ya sea con un proveedor o con el “Support Center”. Toda
escalación deberá ser documentada en SalesForce con el objetivo de seguir
las mejores prácticas.
Líder
de  Prueba STS
Tanto el Líder de Proyecto como el Coordinador de Sistemas deben
Proyecto
/
asegurase que la STS cumpla con todos los requerimientos especificados por
Coordinador
el usuario o proyecto y se entregue un producto final con altos estándares
Sistemas
de calidad. Las pruebas y sus resultados deben quedar documentadas en la
STS.
 Aprueba Resultados
Usuario
Previo a la liberación o cierre de la STS el usuario principal deberá aprobar
los resultados con el visto bueno correspondiente (Vo.Bo.)
 Cierra STS
Toda STS debe ser cerrada en SF cuando el proyecto o requerimiento haya
concluido a satisfacción del usuario. Los campos para cerrar un caso son:
Campos dentro del detalle del Caso
Líder
de
Proyecto
/
Coordinador
Sistemas
Líder
de  Estado: Liberado a Producción (Si aplica)
Proyecto
/  Fecha Liberación: Fecha de conclusión de STS.
Coordinador
Campos dentro del detalle de Cerrar mis casos.
Sistemas
 Estado: Cerrado

Motivo del Mis Casos:
Información de la Solución
Cuando sea requerido publicar la solución identificada en la STS para casos
futuros se deberán registrar los detalles de la solución y enviar a soluciones
públicas.
4. Catálogos:
Definición de Prioridades:
96
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Nivel de Prioridad
Descripción
Nivel 1 – Crítico
Problema critico en producción que afecta varios usuarios o
compromete los niveles de servicio con clientes. No existen soluciones
alternativas viables. El tiempo esperado de respuesta es menor a 12
horas.
Nivel 2 - Urgente
Parte de la funcionalidad ha sido afectada o existe una degradación en el
desempeño del sistema. El problema es persistente y afecta a muchos
usuarios. No existen soluciones alternativas eficientes. También incluye
solicitudes con tiempos comprometidos de entrega a clientes, activación
de servicios o exportación de información. El tiempo esperado de
respuesta es menor a 24 horas.
Nivel 3 - Alta
Problema que afecta a un usuario. Existen soluciones alternativas viables
en el corto plazo, pero no escalables.
Nivel 4 - Media
Asesorías relacionadas a problemas técnicos de rutina, información
solicitada disponible, requerimientos de funcionalidades nuevas. Existen
soluciones alternativas.
Proceso para seleccionar al Contacto (Usuario).
Buscar al contacto en la cuenta “Empleados Dentegra” ya que puede existir el mismo nombre asignado a
otra cuenta: Ejemplo:
Estado de Casos


Nuevo: La STS ha sido registrada. El requerimiento puede o no estar
terminado, pero aún no ha sido analizado por el Líder de Proyecto o
Coordinador de Sistemas.
Análisis: La STS está siendo analizada por el Líder de Proyecto y/o
Coordinador de Sistemas. Algunas entrevistas con el usuario se pueden estar
llevando a cabo.
97
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN






Desarrollo Sistemas: La STS ha sido aprobada por el usuario y se encuentra
en proceso de desarrollo por parte del Líder de Proyecto o Coordinador de
Sistemas.
Pruebas: La fase de desarrollo ha concluido y se realizan pruebas para validar
la calidad del producto a entregar.
Liberado Producción: La STS ha sido concluida y liberada al usuario.
En espera de terceros: La STS esta suspendida en espera de algún
comentario o información de un tercero, ajeno al departamento de IT
Resuelto: Antes de obtener el VoBo. por parte del usuario
Cerrado. Al cerrar el caso se debe cambiar el estatus a Cerrado.
Esquema de Clasificación de Soporte
98
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Definiciones de Tipo de Soporte




Problema Producción: Existe una falla o error en un proceso de la aplicación
que está liberado en producción.
Soporte Operativo: El usuario requiere realizar una función en el sistema que
no está liberada en producción.
Requerimiento Nuevo: El usuario solicita una nueva funcionalidad en el
sistema.
Solicitud de Desarrollo: Se refiere a un requerimiento donde intervienen
usuarios de diferentes áreas y usualmente debe existir un líder de proyecto y un
plan de trabajo.
Este proceso consta de 3 secciones principales que describen el objetivo, diagrama de
flujo y descripción narrativa de dicho proceso.
El diagrama de flujo especifica de manera gráfica la secuencia de acciones que deben
de tomarse para cada uno de los actores involucrados en este proceso, se presentan
los distintos roles del Service Desk y se involucra al usuario final para darle el
seguimiento a la incidencia.
En el flujo se encuentran representados el usuario, el proyect lider (agente del Service
Desk), Support Center (que es la entidad que representa a los distintos niveles de
jerarquización) y por ultimo Sales Force© que es una representación del uso de le
herramienta para evitar cualquier mal entendido en cuanto al registro, seguimiento,
información y documentación de la incidencia.
Ya en la descripción narrativa se presenta una guía paso a paso de la descripción de
las actividades que debe realizar cada involucrado en el proceso. En esta descripción
podemos observar los distintos valores que pueden tomar las variable y su
dependencia.
Ya por último se presentan una serie catálogos que ayudan a reforzar estos valores.
Proceso de Incidencias: Nuevos desarrollos y/o Cambios (Dentegra Seguros Dentales,
2008):
Índice del Manual
No. Página
1.
2.
3.
4.
Objetivo
Diagrama de Flujo
Descripción Narrativa
Catálogos
1
1
2
5
99
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
1. Objetivo:
Administrar y documentar de forma eficiente los incidentes y requerimientos de los nuevos
desarrollos y/o cambios en las aplicaciones existentes que sean solicitados al Departamento de
Sistemas; para efectos de seguir las mejores prácticas y lograr una Gestión de Servicios IT
exitosa.
2. Diagrama de Flujo:
100
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
3. Descripción Narrativa:
Responsable
Descripción



Usuario








Líder de Proyecto /
Coordinador

Sistemas






Solicita STS
El usuario puede requerir una STS por los siguientes medios:
Portal Web: Salesforce (SF)– Mis Casos – Requerimiento
Sistemas
E-mail: Correo Electrónico (Si no cuenta con acceso a
Salesforce)
Llamada telefónica
Communicator (Chat)
Nota: El usuario debe registrar su Incidente o
Requerimiento vía SF.
Análisis
El Project Leader realizará un análisis para determinar si el
requerimiento o cambio solicitado por el usuario es viable o no.
Después de esto, será canalizado al área de Desarrollo.
Clasifica STS
Se debe clasificar el incidente para efectos de determinar si es un
incidente que puede afectar la producción, o un requerimiento.
Evalúa Tiempo de Resolución.
En base al conocimiento del área de Desarrollo y la colaboración con el
proveedor “Intercase”, se determinará el Tiempo de Resolución de los
requerimientos. En seguida, se notificará al usuario, con la correcta
actualización en SalesForce.
Registra STS
Aun cuando el usuario pudo haber registrado el caso en SF, es
responsabilidad del Líder de Proyecto o Coordinador de Sistema el
registro completo del caso utilizando el Tipo de Registro
“Requerimiento Sistemas”.
Prioridad: Registra Nivel 1, 2, 3 ó 4 de acuerdo al Anexo.
Fecha de Solicitud: Fecha en que se solicitó la STS.
Nombre del Contacto: Todo usuario debe estar
registrado en la cuenta de Salesforce “Empleados Dentegra”.
Ver Anexo. Se debe registrar al usuario o contacto principal
de la STS.
Origen del Mis Casos: Se documenta cual fue la forma en
que se recibió originalmente el caso: Correo Electrónico,
Teléfono, Salesforce.
Estado: El caso al momento de registrarse debe tener el
Estado “Nuevo” y debe actualizarse este campo de acuerdo
a la etapa de Desarrollo del mismo. Ver Anexo.
Clasificación de Soporte: El caso debe clasificarse de
acuerdo al Anexo.
Tipo de Soporte: El Tipo de Soporte es dependiente a la
Clasificación de Soporte. Ver Anexo.
101
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Responsable
Descripción


Responsable de Caso IT. Se debe seleccionar a la
persona responsable por parte de Sistemas del Caso.
Asunto: Se registra el título que mejor describa a la STS,
utilizando el siguiente esquema:
SISTEMA – ISSUE – USER/GROUP AFFECTED
e.g. Outlook – Configuración de Perfil – Nuevo empleado


HealthCase – Sistema no disponible - Operaciones
Antecedentes: Se registra de forma breve las causas y
justificación que dan origen a la STS.
Descripción: Se registra a detalle la STS con los datos
proporcionados inicialmente por el usuario. Este campo
deberá mantenerse actualizado a lo largo del desarrollo de la
STS y debe reflejar claramente los requerimientos del
usuario.
Una vez registrado el caso SF genera un número de caso.
 Documenta STS
Tanto el líder de Proyecto como el Coordinador de Sistemas deben
mantener una documentación detallada en todas las fases de la STS. Los
casos se documentan considerando lo siguiente:
Campos de documentación





Líder de Proyecto / 
Coordinador

Sistemas






Antecedentes: Debe reflejar de forma breve la justificación
que da origen a la STS.
Descripción: Debe reflejar claramente los requerimientos
del usuario o proyecto, tomando en cuenta el siguiente
Checklist básico:
Nombre completo del usuario
Teléfono con Extensión
Segundo Contacto / Teléfono (ext)
Usuario de Red ( si aplica)
Usuario SF ( si aplica)
IP ( si aplica)
Descripción de Incidente o Requerimiento
Workaround ( si aplica)
… etc.
Reporte Sistemas: Deberá describir a detalle la identificación
del problema, las soluciones propuestas, la solución elegida y
su justificación, así como las
principales actividades
realizadas durante el desarrollo de la STS. Puede incluir la
propuesta de nuevos requerimiento o proyectos. El reporte
de Sistemas servirá como una base de conocimientos de la
empresa y ayudará a resolver casos futuros similares de
forma más rápida.
Horas Sistemas: Debe reflejar las horas invertidas por
Sistemas en el desarrollo de la STS.
102
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Responsable
Descripción

Comentarios: Se pueden incluir comentarios de cualquier
miembro del equipo que esté participando en el desarrollo
de la STS. Cuando el usuario no tenga acceso a Salesforce es
recomendable utilizar la opción de Chatter para poder
colaborar en equipo.
Tareas:
Durante el desarrollo de la STS se deberán registrar todas
las tareas relacionadas y el Líder de Proyecto deberá
verificar su oportuno cumplimiento.
Eventos:
Las juntas de trabajo, conferencias telefónicas, sesiones de
capacitación, etc. deberán programarse como eventos en SF
y se agregaran las minutas o reportes correspondientes.
Llamadas:
Durante el desarrollo de la STS se deberán registrar todas
las llamadas realizadas relacionadas con la STS describiendo
los acuerdos o detalle de la llamada.
Correos Electrónicos:
Durante el desarrollo de la STS se deberán enviar desde el
Caso de SF todos los correos electrónicos relacionados con
la STS. De la misma manera se agregarán los correos
relacionados que sean relevantes y que se reciban por medio
de Outlook.
Archivos Adjuntos:
Todos los archivos relacionados a la STS deberán ser
agregados al caso.
 Resuelve STS
Líder de Proyecto /
Coordinador
Sistemas
Líder de Proyecto /
Coordinador
Sistemas
Usuario


El Líder de Proyecto o Coordinador de Sistemas desarrolla las
actividades requeridas para cumplir con las especificaciones de la STS de
acuerdo a los procesos establecidos en cada caso.
Es importante que si la resolución no está al alcance del de Proyecto o
Coordinador de Sistemas, se escale debidamente como se muestra en el
diagrama de Flujo; ya sea con un proveedor o con el “Support Center”.
Toda escalación deberá ser documentada en SalesForce con el objetivo
de seguir las mejores prácticas.
Prueba STS
Tanto el Líder de Proyecto como el Coordinador de Sistemas deben
asegurase que la STS cumpla con todos los requerimientos especificados
por el usuario o proyecto y se entregue un producto final con altos
estándares de calidad. Las pruebas y sus resultados deben quedar
documentadas en la STS.
Aprueba Resultados
Previo a la liberación o cierre de la STS el usuario principal deberá
aprobar los resultados con el visto bueno correspondiente (Vo.Bo.)
103
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Responsable
Descripción

Cierra STS
Toda STS debe ser cerrada en SF cuando el proyecto o requerimiento
haya concluido a satisfacción del usuario. Los campos para cerrar un
caso son:
Campos dentro del detalle del Caso
Líder de Proyecto /  Estado: Liberado a Producción (Si aplica)
Coordinador
 Fecha Liberación: Fecha de conclusión de STS.
Sistemas
Campos dentro del detalle de Cerrar mis casos.


Estado: Cerrado
Motivo del Mis Casos:
Información de la Solución
Cuando sea requerido publicar la solución identificada en la STS para
casos futuros se deberán registrar los detalles de la solución y enviar a
soluciones públicas.
4. Catálogos
Definición de Prioridades:
Nivel de Prioridad
Descripción
Nivel 1 – Crítico
Problema critico en producción que afecta varios usuarios o
compromete los niveles de servicio con clientes. No existen soluciones
alternativas viables. El tiempo esperado de respuesta es menor a 12
horas.
Nivel 2 - Urgente
Parte de la funcionalidad ha sido afectada o existe una degradación en el
desempeño del sistema. El problema es persistente y afecta a muchos
usuarios. No existen soluciones alternativas eficientes. También incluye
solicitudes con tiempos comprometidos de entrega a clientes, activación
de servicios o exportación de información. El tiempo esperado de
respuesta es menor a 24 horas.
Nivel 3 - Alta
Problema que afecta a un usuario. Existen soluciones alternativas viables
en el corto plazo, pero no escalables.
Nivel 4 - Media
Asesorías relacionadas a problemas técnicos de rutina, información
solicitada disponible, requerimientos de funcionalidades nuevas. Existen
soluciones alternativas.
Proceso para seleccionar al Contacto (Usuario).
Buscar al contacto en la cuenta “Empleados Dentegra” ya que puede existir el mismo nombre asignado a
otra cuenta: Ejemplo:
104
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Estado de Casos






Nuevo: La STS ha sido registrada. El requerimiento puede o no estar
terminado, pero aún no ha sido analizado por el Líder de Proyecto o
Coordinador de Sistemas.
Análisis: La STS está siendo analizada por el Líder de Proyecto y/o
Coordinador de Sistemas. Algunas entrevistas con el usuario se pueden estar
llevando a cabo.
Desarrollo Sistemas: La STS ha sido aprobada por el usuario y se encuentra
en proceso de desarrollo por parte del Líder de Proyecto o Coordinador de
Sistemas.
Pruebas: La fase de desarrollo ha concluido y se realizan pruebas para validar
la calidad del producto a entregar.
Liberado Producción: La STS ha sido concluida y liberada al usuario.
Cerrado. Al cerrar el caso se debe cambiar el estatus a Cerrado.
Esquema de Clasificación de Soporte
105
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Definiciones de Tipo de Soporte




Problema Producción: Existe una falla o error en un proceso de la aplicación
que está liberado en producción.
Soporte Operativo: El usuario requiere realizar una función en el sistema que
no está liberada en producción.
Requerimiento Nuevo: El usuario solicita una nueva funcionalidad en el
sistema.
Solicitud de Desarrollo: Se refiere a un requerimiento donde intervienen
usuarios de diferentes áreas y usualmente debe existir un líder de proyecto y un
plan de trabajo.
106
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
El proceso que consta de 3 secciones principales que describen el objetivo, diagrama
de flujo y descripción narrativa de dicho proceso.
Al igual que el anterior el diagrama de flujo que especifica de manera gráfica la
secuencia de acciones que deben de tomarse para cada uno de los actores
involucrados en este proceso, se presentan los distintos roles del Service Desk y se
involucra al usuario final para darle el seguimiento a la incidencia.
En el flujo se encuentran representados el usuario, el proyect lider (gestor de
incidencias y problemas), Desarrollo (agente del Service Desk y al mismo tiempo es la
entidad que representa a los distintos niveles de jerarquización) y por ultimo Sales
Force© que es una representación del uso de le herramienta para evitar cualquier mal
entendido en cuanto al registro, seguimiento, información y documentación de la
incidencia.
Como podemos observar en el proceso anterior no se involucra la figura del gestor de
incidencias y problemas, esto debido a que las modificaciones en el software son por
naturaleza de un mayor impacto para el negocio y para la primera fase o fase de
implementación de las mejores prácticas se deberá considerar de una manera
específica este tipo de incidencias o de aquellas que impacten de mayor manera al
negocio, como una segunda fase de la implementación de las mejores prácticas se
propone incluir al gestor de las incidencias para todas aquellas incidencias de Soporte
Técnico registradas en Sales Force©.
Ya en la descripción narrativa se presenta una guía paso a paso de la descripción de
las actividades que debe realizar cada involucrado en el proceso. En esta descripción
podemos observar los distintos valores que pueden tomar las variable y su
dependencia.
Ya por último se presentan una serie catálogos que ayudan a reforzar estos valores.
4.2.2 Apertura de incidencias
En el Anexo B vemos la forma detallada manera de abrir “caso” en Sales Force©. La
intención de incluir este manual es que el usuario tenga una manera gráfica de cómo
registrar sus propios “casos” en Sales Force©. En breve se describen:





Empezara por ubicar la sección de “Mis Casos” y dentro de ella el botón de
“Nuevo”
En la opción de tipo de registro seleccionara “Requerimiento Sistemas”
Una vez completada esta información inicial aparecerá una forma donde
requerirá información adicional para documentar la incidencia
Dentro de esta información podemos observar que algunos campos son
requeridos (obligatorios) y algunos otros son de vital importancia, como lo
pueden ser: “Clasificación de soporte” y “Tipo de soporte”. Que se describen de
manera puntual con la intención de que el responsable del registro de la
incidencia no tenga duda alguna en como clasificar los incidentes
Finalmente dar clic en botón de “Guardar”
107
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Además del registro de las incidencias algo que no podemos pasar por alto es el
seguimiento de las mismas, esto para llevar un registro completo, es decir, tener un
estatus en un tiempo determinado y por supuesto para tener un control de las
incidencias para su futura evaluación.
Si bien existen diferentes maneras de llevar este seguimiento, para este motivo nos
adecuaremos a los propuestos en Sales Force©, los propuestos dentro de la aplicación
son los siguientes, con sus respectivas características:
Estos apartados tienen la finalidad de registrar cada evento para cada incidencia.





Tareas: Actividades a cumplir por los distintos actores
Eventos: Juntas de trabajo, conferencias, sesiones, etc. que deberán registrar
Llamadas: Llamadas que se realicen durante el seguimiento y la resolución de
la incidencia
Correos electrónicos: Envió y recepción de la comunicación vía correo
electrónico
Archivos adjuntos: Archivos relacionados con la resolución de la incidencia
4.2.3 Resolución de incidencias
A continuación revisaremos el proceso de “Cerrar un ticket”, este proceso si bien es la
acción que cambia al último estatus un ticket, es por demás importante para la
generación de una base de datos de soluciones, que si bien no está dentro del alcance
de este proyecto si puede ser un tema que se puede abordar en otro caso de estudio.
El proceso consta de varios pasos:





Ubicar el caso correspondiente (caso a cerrar)
Pulsar el botón “Cerrar mis casos”
Seleccionar el estado “Cerrado”
Seleccionar el “Motivo de mis casos”, que se refiere principalmente al motivo
por el cual se está cerrando el “Caso”
Pulsar el botón de “Guardar”
Con esto podemos decir que la atención de incidentes y requerimientos para el área de
soporte está concluida, sin embargo antes de llegar a este estatus de la incidencia
puede pasar por muchos estatus intermedios.
Todos estos estatus generalmente van de la mano con un indicador que sirve de
referencia para la evaluación de y desempeño de los agentes del Support Center.
Más adelante hablaremos de estos indicadores y de qué manera hacen sentido en el
desempeño de los agentes.
108
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
4.2.4 Niveles de soporte
Los niveles de soporte en Dentegra son de manera muy simple y natural, en general
existen dos tipos:


Nivel con un impacto funcional (horizontal)
Nivel con un impacto Jerárquico (vertical)
La primera decisión que deberá tomar el encargado de resolver la incidencia, es si la
resolución de la incidencia está dentro de mi ámbito o de mi zona de influencia (área
departamental). En muchos casos las incidencias parten de permisos derivados de
perfiles, roles, puestos o inclusive de actividades relacionadas con el trabajo cotidiano
de cada usuario.
En muchos casos las políticas y procedimientos no son claros inclusive para las
personas que trabajan en la misma área departamental, esa es la razón por la cual se
deberá acudir a una jerarquización funcional (horizontal) en donde intervienen
supervisores, gerentes o directivos que autoricen los distintos permisos o accesos a
cierto recurso informático disponible para esa área departamental. Una vez otorgado el
acceso se procederá a la solución y cierre de las incidencias.
Por otro lado el impacto Jerárquico, depende de las habilidades técnicas del agente
que este resolviendo la incidencia. Para Dentegra existen hasta 4 tipos de
jerarquización (escalar problemas):




4.3
La primera línea o Front Line: Corresponde al agente que está tomando la
llamada e intentando resolver la incidencia
La segunda línea o Back Line: Se refiera a un agente con mayor experiencia o
al supervisor encargado
La tercera línea o Soporte Local: Corresponda al especialista en turno que
corresponda, en este caso Dentegra cuenta con especialistas en cada ramo
(servidores, redes, computadoras de escritorio, etc.) que pueden resolver casi
cualquier problema relacionado
Cuarta línea o Proveedor: De acuerdo a las políticas de Dentegra se tiene un
contrato para cada una de las principales líneas de infraestructura en el
departamento de IT, es decir, servidores, redes, equipo de escritorio, aire
acondicionado, UPS (No break), planta de luz, etc. cuentan con un contrato
vigente para soporte y reemplazo de piezas que generalmente están vigentes
365 días al año, los 7 días de la semana, las 24 horas al día
Gestión de problemas
El principal objetivo de la gestión de la gestión de los problemas es minimizar el
impacto ocasionado al negocio por los “problemas” derivados de la infraestructura
tecnológica, además de prevenir la recurrencia de los incidentes relacionados a estas
causas. Para alcanzar este objetivo es necesario monitorear la causa de estos
incidentes para después iniciar acciones para la mejora o corrección de la situación.
109
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
El manejo o gestión de los problemas tiene objetivos que se contraponen por
naturaleza, es decir, por un lado se concentra en aspectos reactivos que van en
función a la solución de problemas para atacar una o más incidencias y por el otro lado
se concentra en aspectos proactivos, identificando y haciendo del conocimiento de los
demás problemas (incidencias) o errores conocidos antes de que se presenten las
incidencias de manera formal.
4.3.1 Relaciones entre incidencias y problemas
La gestión de problemas se diferencia de la gestión de incidencias en que su principal
objetivo es detectar el origen o la causa de un incidente y de sus posibles
complicaciones para prevenir incidencias futuras.
Sin embargo puede verse afectado por la gestión de incidencias, es decir, cuando esta
intenta dar una solución parcial o restablecer el servicio lo antes posible por medio de
un “camino alterno” (work around) es vez de otorgar una solución de fondo, en este
aspecto la velocidad de solución pasa a ser parte de un segundo plano o de una
segunda opinión. Para el gestor de problemas la velocidad no es un factor que
represente o altere sus indicadores de servicio, si no por el contrario la intención de
que exista esta figura representa más un sentido de solución y prevención de futuras
incidencias derivadas de la infraestructura tecnológica. Evidentemente la prevención y
restauración de los servicios podrían verse afectados con tiempos cada vez más altos
al momento de evaluar un problema.
En general una incidencia que se repite lo podemos considerar como un problema y
aquí es donde el gestor de problemas entra en acción para la detección, coordinación,
registro, seguimiento y solución del problema de una manera íntegra.
No hay que olvidar que el proceso de gestión de problemas va de la mano con una
eficiente manera de manejar los problemas en sí. El verdadero sentido de gestionar los
problemas es identificar las causa y por lo tanto el origen y con esto poder proveer al
Support Center con información para resolver incidencias y rutas alternas cuando haya
disponibles alguna de ellas.
El reto de la gestión de problemas es muy similar y altamente dependiente de la
gestión de incidencias, no hay que olvidar que la gestión de incidencias se basa en
resolver interrupciones de los servicios y proveer caminos alternos o soluciones
temporales para incidentes específicos. En este punto si un incidente es identificado
como en un grupo de incidentes (incidentes similares) tiene caminos alternos o
soluciones temporales entonces es registrado como un problema por el gestor de
problemas. Que no solo registra sino que también provee el mejor camino corto
disponible para el problema antes de dar una solución alterna.
Debido a que la gestión de problemas está enfocada a prevenir la recurrencia de los
incidentes, el proceso deberá estar sujeto a una planeación y administración
cuidadosa, es decir, la planeación y administración deberá ser mayor que la que se
utiliza en la gestión de incidencias donde el objetivo principal será la restauración
110
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
normal del servicio tan pronto como sea posible y la prioridad será asignada basada en
el impacto que este tenga en el negocio.
4.3.2 Descripción del sistema de gestión de problemas
En el apartado anterior se describió la relación existente entre las incidencias y los
problemas, básicamente la manera de detectar un problema es basado en las
incidencias y en su frecuencia, si bien esto no se podría determinar de manera natural,
el gestor de problemas es el encargado de monitorear las incidencias que más
frecuencia tengan durante un periodo de tiempo y esto es a través de un reporte
previamente definido en Sales Force©.
Dicho reporte contempla las incidencias que tengan un prefijo o una palabra clave en la
documentación de la misma.
Una vez determinado el problema se registra de la misma manera que una incidencia
con la particularidad de una categorización distinta como se observa en la figura
siguiente:
Figura 31. Clasificación de problemas (Dentegra Seguros Dentales, 2008)
A partir de este momento el gestor de problemas es el encargado de darle un
seguimiento puntual a este problema, dentro de sus principales responsabilidades es
encontrar una solución de fondo y los distintos caminos alternos que puedan llevar a
una solución adecuada para este problema.
Otra de sus responsabilidades es la correcta jerarquización para determinar la
solución, así como la documentación necesaria para la generación de una base de
conocimientos en futuras incidencias a servicios asociados. La jerarquización si bien es
el mismo (no hay que olvidar que los recursos son limitados en Dentegra y la intención
es la mejora continua) la importancia de tener a un gestor de problemas es para poder
darle un seguimiento puntual y no dejar “problemas sueltos” sin una solución de fondo.
Cabe la pena mencionar que en Dentegra la manera de identificar los problemas será
basándose en una técnica denominada 20/80, que implica enfocarse en las incidencias
111
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
más ocurridas, es decir, que el 20% de las incidencias causan el 80% de la
degradación de los servicios ya implementados.
En el apartado anterior hablamos de un reporte, este reporte se basa en obtener
diariamente las incidencias ocurridas junto con su frecuencia y de esa manera trabajar
con un conjunto pequeño de incidencias que ocasionan la mayor parte de problemas
que afectan los servicios.
Esto por supuesto no sería posible si no se cuenta con:



4.4
Un efectivo registro de las incidencias, así como una correcta clasificación para
su administración
Aprovechamiento adecuado del talento de la persona a cargo de la gestión de
problemas, ya que estará sujeta a presiones por los tiempos de respuesta y a
otorgar soluciones adecuadas
Evitar posibles conflictos de interés entre los actores de la gestión de
incidencias y la gestión de problemas. Una buena cooperación entre ambos
equipos es esencial y sobretodo generara una gran sinergia para la solución
adecuada a los problemas/incidencias
Gestión de cambios
Proceso de cambios
Los cambios en general surgen como el resultado de los problemas comunes, es decir,
cuando tenemos un problema recurrente lo recomendable es buscar una solución de
fondo al problema y generalmente esto se ve reflejado como un cambio en la
infraestructura que soporta al servicio. Algunos cambios también pueden venir como el
resultado de un proceso de monitoreo de problemas y tendencias de los mismos, esto
con la intención de proponer de una manera proactiva cambios que pueden beneficiar
al negocio o a los mismos servicios.
La intención de implementar la gestión de cambios en Dentegra es garantizar que se
utilice una metodología estandarizada y por supuesto procesos que sean eficientes y
que nos ayuden al manejo e implementación de los cambios de una manera rápida. En
la sección de Proceso de Incidencias (de este capítulo) se puede observar el formato
disponible a los usuarios para hacer este requerimiento, considerando lo antes
mencionado.
Esta gestión de los cambios nos ayudara a minimizar los impactos de los problemas en
el negocio así como la mejora continua de los servicios.
El cambio no solo significa realizar un movimiento controlado en la infraestructura o en
los servicios, en realidad implica desde una evaluación de las posibles afectaciones
(riesgos) hasta el análisis de los recursos y por supuesto la aprobación del mismo, es
por eso que la gestión de los cambios debe conservar y equilibrio muy balanceado
entre la necesidad de realizar el cambio vs. lo que implica el cambio como tal o el
impacto del cambio en el negocio o en los indicadores.
112
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
En la siguiente figura podemos observar las responsabilidades de las dos roles
principales que se deben de contemplar en la gestión de los cambios, estos son el
gestor de los cambios y el gestor de los proyectos, aparentemente pudieran ser la
misma persona ejecutando dos roles, sin embargo es importante diferenciar que las
responsabilidades de cada uno son independientes y no dependen directamente uno
del otro. Por lo que se tiene un riesgo implícito al momento de asignarle está a una
misma persona.
Además es evidente pensar que para que esto se lleve a cabo es importante
mencionar que hay que contar con los recursos humanos suficientes y por supuesto
técnicos para la conservación de este equilibrio y de lo que dependerá mucho el éxito
de la aplicación del cambio.
Para Dentegra hablaremos de la gestión de cambios implementada únicamente en su
sistema central, que es aquel que permite la administración, registro, mantenimiento a
la cartera y pagos de los siniestros a los dentistas o asegurados. La herramienta se
denomina “HealthCase” y consta de varios módulos que en conjunto proveen a
Dentegra de la información necesaria para poder cumplir con sus clientes y la
autoridad.
El proceso como se comentó está especificado en el Proceso de Incidencias, mismo
que se explicara a continuación, debe entenderse como una breve explicación en caso
de que exista alguna duda.
El título del proceso: Atención de Incidentes y Requerimientos para el área de
Desarrollo (HealthCase).
Consta de 4 puntos principales que se describen en el mismo:
Objetivo: Describe la intención del proceso en un breve párrafo así como algunas
ventajas.
Diagrama de flujo: Se hace constar de cuatro figuras representativas en cada parte del
proceso, estas figuras pueden ser representadas por una o varias personas o en su
caso por responsables de las actividades:
a) Usuario: El encargado de identificar la incidencia, problema o circunstancia y/o
registrarla en la herramienta designada para este propósito
b) Líder de proyecto: Responsable del análisis y canalización de la incidencia, así
como informar al usuario el estatus del mismo
c) Área de desarrollo: Encargada de resolver o realizar en cambio solicitado,
responsable de las pruebas y obtención del VoBo. del usuario
d) Sales Force©: Herramienta seleccionada para el registro y seguimiento de las
incidencias, problemas, etc.
113
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Figura 32. Límites entre el gestor de cambios y el gestor de proyectos (OGC, Office of Government
Commerce, 2007)
Descripción narrativa: Explicación de cada uno de los pasos a seguir dentro del
proceso.
Anexos: Serie de catálogos, guías rápidas y descripciones utilizados en cada parte del
proceso.
4.4.1
Análisis de soluciones
En la definición de las mejores prácticas aplicadas encontramos muchos casos de éxito
que no necesariamente fueron concebidos de la misma manera y que sin embargo
dieron buenos resultados ya una vez implementadas, pero algo que tienen en común, y
114
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
es que tanto la administración del cambio como la configuración del mismo fueron
realizadas en un mismo paso, por la misma persona o en su caso por un mismo equipo
de trabajo. En realidad la participación y comunicación del equipo de trabajo es
importante aunque eso no quiere decir que un grupo de personas tendrán las mismas
actividades.
Con esto queremos decir que la responsabilidad de la acción Análisis, que aparece
como numero 2 dentro del proceso de incidencias para nuevos desarrollos (Proceso de
Incidencias) puede ser conceptualizado por una o más personas relacionadas entre sí,
del mismo departamento o incluso de diferentes. Sin embargo esta es una
responsabilidad del líder de proyecto, que como ya dijimos con anterioridad es el
encargado de coordinar las actividades necesarias para poder conceptualizar el
incidente de una manera particular y poder definir el mismo como un problema y si este
requiere un cambio o no.
Una vez tomada esta decisión habrá que determinar los costos y los recursos
necesarios para la resolver el problema, registrarlo y a su vez otorgar un prioridad de
acuerdo al tipo de problema asociado. También deberá otorgar otras características a
la incidencia como lo son: Estado de la incidencia, clasificación y tipo de soporte,
además del responsable, los antecedentes y una breve descripción del problema.
4.4.2 Definición del cambio
Una de las actividades más desafiantes dentro de cualquier área de desarrollo es
poder plasmar de una forma simple, detallada pero al mismo tiempo muy conciso y
sobre todo claro y fácil de entender la definición de un problema y al mismo tiempo que
su solución.
Dentro de la definición del cambio deberemos observar un rol que no se ha
mencionado dentro de la estructura del equipo de trabajo, que es el arquitecto de
soluciones del negocio, esta rol está presente en las distintas etapas de un STS dentro
del departamento.
La documentación se deberá integrar por una serie de atributos referentes a la
incidencia de la cual se dio origen, sin embargo hay un número importante de
apartados dentro de la herramienta que sirven como accesorios de apoyo para la
definición del problema.
Estos son las tareas, eventos, llamadas, correos electrónicos y archivos adjuntos; que
en conjunto con los comentarios y reporte de sistemas pueden darnos un panorama
completo del problema así como de su solución.
Generalmente cuando hablamos de un problema, nos referimos a una incidencia que
se ha repetido en varias ocasiones, este problema (por experiencia) se puede
determinar una solución a través de una serie de pasos o coordinación de actividades
referentes a determinar los impactos y futuros problemas asociados a la misma. El
arquitecto del negocio en conjunto con el líder de proyecto y en algunas ocasiones el
115
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
departamento de desarrollo tienen que combinar sus habilidades para poder
determinar una secuencia de actividades para resolver el problema.
Para llevar un seguimiento adecuado de todas las reuniones o eventos asociados a un
problema (y más adelante evaluar el costo unitario del problema) se utilizaran los
campos asignados para este propósito.
Con esto determinamos que la solución a un problema generalmente está compuesto
de minutas, documentos, conferencias, acuerdos y en muchas ocasiones haciendo uso
de dinámicas como lo son la lluvia de ideas, mapas mentales, analogías, entre muchas
de ellas. La intención del proceso así como de la herramienta utilizada es la de no
limitar al “solucionador” (una o varias personas) y poder dar al responsable de la
documentación las herramientas necesarias para poder organizar, priorizar y al mismo
tiempo clasificar cada una de estas ideas con el fin de obtener una solución integral.
4.4.3
Petición del cambio
A continuación se ejemplifica un machote de la carátula a llenar para este fin, la
petición del cambio incluye la documentación, referencias, definiciones y adecuaciones
requeridas para la solución a un problema. (Dentegra Seguros Dentales, 2008)
Índice del Manual
No. Página
1.
2.
3.
4.
Objetivo
Esquema
Descripción
Anexos
1
1
2
5
1. Objetivo:
Documentar de forma eficiente los requerimientos que sean solicitados al Departamento de
Sistemas; para la obtención de rubricas que avalen los VoBo. de cada una de las areas
involucradas
2. Esquema:
Ciudad, fecha exacta
Entidad a la que va dirigida
(Dirección, Departamento, Coordinación, etc.)
Autorización:
“Nombre completo” presenta documentación para el requerimiento número: XXXXXXXX referente al
mismo número de incidencia registrada con fecha dd/mm/yyyy para la autorización del cambio al sistema
HealthCase
116
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Firma Autorizada
Nombre:
Cargo:
Firma Autorizada
Nombre:
Cargo: Depto. Desarrollo
Firma Autorizada
Nombre:
Cargo: Gestor de Cambios
3. Descripción:
I. Llenar los campos necesarios en el documento
II. Anexar la documentación descrita a esta carátula
III. Determinar las firmas de autorización: El responsable deberá corroborar los VoBo. de los
participantes
IV. Presentar documento al departamento de desarrollo
V. Evaluar prioridades
VI. Designar tiempos de desarrollo y entrega
Este esquema es una formalidad propia de los procesos implementados de acuerdo a
las mejores prácticas; la herramienta Sales Force© utilizada para el seguimiento de las
incidencias da la oportunidad de mantener todo este tipo de documentación y
actividades realizadas para la solicitud del cambio. Dentro de las secciones descritas
se mantiene de manera digital todo el historial que sustenta el cambio.
La carátula llenada con anterioridad se deberá digitalizar y adjuntar a la incidencia para
conservar la integridad de la información antes de iniciar el desarrollo o la puesta en
marcha de las actividades descritas. La autorización es primordial para el inicio de
actividades en cualquier departamento que impacte la solución del problema.
4.4.4
Acciones y pruebas
La puesta en marcha de las actividades correctivas depende directamente de las
etapas evaluadas mismas que se determinan en los planes de trabajo, esta es una
responsabilidad del gestor de proyectos. Si bien no es la intención de este texto
determinar las actividades del gestor de proyectos solo mencionaremos las principales
actividades realizadas previas al cambio (PMI, Project Management Institute, 2005):





Inicio: Autorización del proyecto, asignación de responsables, integración con el
negocio
Planificación: definición de alcance, definición de entregables, estimaciones de
recursos, evaluación de riesgos y consecuencias.
Ejecución: Coordinación de recursos, asignación de actividades, aseguramiento
de la calidad
Supervisión y control: Gestiones de los equipos de trabajo, de los cambios
realizados e informes de desempeño
Cierre: Resumen de actividades, cierre de proyecto
En esta etapa se ponen en marcha todas las actividades realizadas en las etapas de
planificación, ejecución y supervisión y control mencionadas. Cada una de estas tareas
trae consigo una serie de formatos y documentación anexa propia del gestor de
proyectos que en conjunto con el gestor de cambios tienen a bien evaluar y autorizar.
117
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
4.4.5
Implementación del cambio
La liberación y/o implementación del cambio corre a cargo del departamento de
desarrollo, este deberá generar la documentación necesaria para que se lleven a cabo
todos los pasos requeridos, esta etapa inicial al finalizar las pruebas y una vez que se
obtiene el visto bueno por parte del usuario.
Este proceso si bien es parte del proceso de pruebas se considera como el punto de
partida para la implementación debido a la coordinación que debe existir entre el
usuario y el equipo de desarrollo para llevar a cabo una correcta implementación del
cambio. Durante esta etapa del proceso se evalúa la satisfacción del usuario, los
tiempos de respuesta, el cumplimiento al requerimiento y sobretodo la calidad con la
que el equipo de desarrollo genera las soluciones.
Para llevar un seguimiento puntual de cada una de las etapas que lleva la gestión de
cambios se tiene una característica en el registro de la incidencia donde nos indica el
estado en que se encuentra el cambio, es decir, un campo de estatus durante toda la
gestión del cambio.
Este campo puede obtener los siguientes valores:







Nuevo
Análisis
Desarrollo de sistemas
Pruebas
Liberado a desarrollo
Liberado a producción
Cerrado
Como se describió anteriormente el registro y seguimiento del cambio se lleva en Sales
Force© y durante la fase de la implementación los estatus utilizados son: Liberado a
producción y Cerrado.
La razón para manejar dos estatus es debido a que en muchas ocasiones existen
confusiones tanto para los usuarios como para los implementadores al momento de
querer saber el estatus exacto del cambio, es decir, el estatus liberado a producción y
es paso antes de cerrar el caso, debido a que el cambio aún sigue en un proceso de
evaluación por parte del usuario y una vez que ya no existen comentarios o dudas en
cuanto al cambio se cambia el estatus a cerrado.
Por otra parte el equipo de desarrollo interpreta que cuando un caso está cerrado ya no
deberá existir por ningún motivo la asignación de recursos orientado a este cambio, si
existe algún problema asociado con el cambio este lo deberá atender el gestor de
cambios y en su momento de deberá crear en Sales Force© una incidencia
reclasificada como cambio y seguirá todo el proceso descrito en este apartado.
Dentro de la documentación a entregar por parte del equipo de desarrollo para realizar
la implementación del cambio esta:
118
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN






4.5
Bitácora de cambios realizados en cualquier archivo fuente o script
Archivos de comandos o scripts en caso de requerirse
Entrega de archivos fuentes modificados para la generación de la nueva versión
Documento de especificación del cambio
Lista de pasos a seguir para instalación del cambio y los equipos de trabajo
involucrados
Hora de ejecución y plan de contingencia en caso de algún problema
Diseño inicial de la base de datos (CMDB)
Uno de los puntos importantes al momento de implementar una metodología como ITIL
en un departamento con recursos humanos y financieros limitados es evitar dejar
huecos en el proceso que pudieran acarrear más problemas a futuro que soluciones,
esta es la razón por la cual se propone un diseño inicial de la implementación de la
gestión de la configuración aquí la intención es proporcionar un modelo lógico de la
infraestructura o de un servicio tecnológico en particular para mantener, verificar y
controlar las versiones de todos los elementos de configuración (Configuration Ítems:
CI) en existencia dentro del departamento y por supuesto de la organización; es decir
todo el hardware, software y documentación asociada que forme parte de la
infraestructura tecnológica de la organización.
4.5.1 Definición
También conocida como CMDB (Configuration Management Data Base), es la base de
datos que ayuda a la gestión de la configuración a llevar un control absoluto de todos
los recursos del departamento de IT.
Además es también una pieza clave dentro de algunas otras metodologías tales como
la BSM (Business Service Management) y que sirve como enlace de todos los entre
todos los componentes del departamento de TI. Esta base de datos proporciona un
depósito de datos compartido, un modelo para el servicio para unificar interfaces,
usuarios y apoya a la generación de informes comunes. En la figura 33 se muestra el
diseño conceptual de la CMDB.
4.5.2 Objetivos


Calcular y evaluar toda la tecnología de información y sus componentes de toda
la organización y sus servicios
Proporcionar información exacta de la configuración de los recursos de TI y la
documentación de la misma
119
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Figura 33. Modelo conceptual de la CMDB (OGC, Office of Government Commerce, 2007)



Proporcionar una herramienta segura para dar seguimiento a todos los casos o
incidencias reportadas a este servicio
Poder verificar los registros de configuración en comparación con las
configuraciones físicas y corregir inconsistencias
Evaluar y determinar la asignación de recursos informáticos por usuario
Además contendrá la información relacionada con:






Inventario completo de todos los elementos de tecnología: hardware, software y
su ubicación, además de los elementos con los que se encuentran conectados
Manuales de instalación, configuración, mantenimiento e implementación
Mapeo de cada servicio con los componentes que lo soportan
Usuarios de los servicios
o Nombre
o Nombre de usuario
o Email
o Teléfono – extensión
o Departamento
Información de las incidencias
o Fecha de alta
o Fecha de cierre
o Estado actual
o Tipo
Historial de problemas, incidencias y cambios
120
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
4.5.3 Diseño conceptual
Esta representación propone los objetos de la base de datos y las relaciones entre sí,
los campos llave que mencionan la manera de organización de cada objeto para su
futura explotación y las flechas indican el tipo de relación existente entre los mismos.
Este tipo de diagramas (entidad-relación) también nos da la oportunidad de generar un
diccionario de datos que nos sirve como documentación y es un elemento importante
para futuros cambios, adecuaciones o nuevos desarrollos que tenga que sufrir la
CMDB. El diseño gráfico lo podemos observar a continuación, esta representación
propone un diseño inicial de cómo se almacenan los datos físicamente dentro de la
base de datos, para efectos de esta implementación se cumple con los requisitos
necesarios para poder cubrir los objetivos propuestos, sin embargo es
considerablemente factible una mejora para apoyar y sustentar otros alcances, se deja
hasta este punto con la finalidad de una que en una segunda fase se realice una
propuesta de mejora que ayude a los administradores a cubrir sus necesidades de
manera integral. Figura 34.
4.5.4 Ubicación y mantenimiento
Esta base de datos residirá en la herramienta que hemos seleccionado para Service
Desk, esto es con la intención de poder tener en una sola instancia todos los objetos
relacionados con el soporte y la entrega de los servicios tecnológicos.
Como se ha mencionado esta herramienta cuenta con los requisitos mínimos
necesarios para poder albergar a una base de datos de estas dimensiones, registrar
sus incidencias y poder otorgar un mantenimiento necesario para poder tener
información confiable en ella.
Esta base de datos está creada en los servidores destinados por Sales Force© para el
uso de Dentegra, se han incorporado múltiples tablas y relaciones con la finalidad de
adecuar Sales Force© a las mejores prácticas y al diseño especifico requerido por
Dentegra.
Dentro de los procesos de mantenimiento los recursos encargados de generar los
casos o tickets de soporte serán los encargados de dar el mantenimiento a esta base
de datos de acuerdo a los servicios que les corresponda administrar, sin embargo
existe un administrador de la base de datos que será el encargado de mantener al día
catálogos tales como las cuentas, usuarios o empleados (contactos), servicios,
inventario, etc. que servirán como insumos necesarios para que los recursos Ingeniero
1, 2 y 3 puedan administrar de manera adecuada cada caso o ticket abierto por los
usuarios.
121
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Figura 34. Modelo gráfico de la DB (Dentegra Seguros Dentales, 2008)
El principal mantenimiento que deberá sufrir esta base de datos es la de conservar los
servicios registrados actualizados en todos momento para poder contar con
información importante, vigente y con validez.
4.6
Entrega de servicio (SLA)
La entrega del servicio se enfoca en alinear todos los procesos que en conjunto llevan
a la realización o puesta a punto (entrega) de un servicio, desde su inicio, es decir
desde que se detecta una oportunidad o una necesidad del usuario, hasta el
mantenimiento o actualización de un servicio con herramientas de última generación.
Este proceso de entregar o poner en las manos de los usuarios un conjunto de
herramientas tecnológicas para que hagan uso de ella y se obtenga un valor agregado
dentro de los servicios que ofrece Dentegra a sus clientes se vuelve cada vez más
relevante conforme se tengan más clientes, personal en Dentegra y por supuesto
beneficios económicos derivados de estos.
Debido a esto para la entrega de los servicios se propone un acuerdo de nivel en el
servicio y por lo tanto se requiere una gestión en el nivel de los servicios, que lo
122
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
entendemos como “el proceso de negociar definir, medir, manejar, y mejorar la calidad
de los servicios de TI a un coste aceptable o en otras palabras, es encontrar el balance
correcto entre proveer el servicio, la demanda, la satisfacción del cliente y el costo de
los servicios” (itSMF, IT Service Management Forum, 2007)
Es importante mencionar que esto no es tema de este trabajo por lo que no se describe
el marco teórico de la gestión de la entrega de los servicios, sin embargo es una parte
fundamental de la aplicación de las mejores prácticas y que se ha decidido incorporar
por considerarla de gran ayuda para los objetivos de este trabajo.
Para generar un compromiso dentro y fuera del departamento de TI la formalización de
esta gestión se da a través de un acuerdo en el nivel de servicio, es decir un
documento que compromete a ambas partes.
Acuerdos de nivel de servicio (SLA)
Un Acuerdo de Nivel de Servicio lo consideramos como la formalización de un acuerdo
entre el departamento de TI y su cliente en este caso Dentegra, este acuerdo describe
los servicios de una manera clara y poco técnica para Dentegra de forma que se eviten
confusiones y malos entendidos a momento de atender un requerimiento por parte de
Dentegra.
Además sirve para garantizar la calidad y la fiabilidad en los servicios soportados por el
departamento de TI.
Se presenta el Acuerdo de Nivel de Servicio firmado entre Dentegra y el departamento
de TI, donde se detallan todos los pormenores, características y situaciones de este
acuerdo.
Acuerdo de Nivel de Servicio, Service Desk (Dentegra Seguros Dentales, 2008)
Índice del SLA
Sección
No. Página
5.
6.
Objetivo
Descripción
I. Introducción
II. Inicio y duración del acuerdo
III. Revisiones periódicas
IV. Descripción del servicio
V. Responsabilidad de Dentegra
VI. Responsabilidad del Departamento de TI
VII. Administración del servicio
7. Anexos
1
1
1
2
2
2
3
4
4
12
1. Objetivo
Este Acuerdo de Nivel de Servicios (SLA) establece las expectativas de Dentegra (Dirección General y
Departamento de Operaciones) hacia el departamento de tecnologías de la información (TI) que brinda
123
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
los servicios de atención telefónica, soporte técnico/operativo, seguimiento de incidencias y resolución
de problemas a nivel 1.
La SLA ayuda a definir la relación entre las dos partes y ayuda como referencia para que el departamento
de TI establezca y mantenga los compromisos con las áreas operativas de Dentegra y a su vez con el
cliente final, este documento contiene las áreas de desempeño de los servicios provistos, servicios
definidos, términos y condiciones de entrega, criterios y métricas de desempeño, así como las
penalidades aplicables cuando no se cumplan los compromisos adquiridos de alguna de las dos partes.
Este documento es un anexo al plan integral de incorporación de las mejores prácticas en Dentegra, por
lo su regulación está definida en el plan general y se requiere contar con todas las funcionalidades y
recursos mencionados en dicho plan para una correcta implementación de este nivel de servicio.
Los ejemplos aquí planteados se pueden considerar como una guía referencial con la finalidad de ilustrar
un posible contenido.
2. Descripción
I.
Introducción
Este acuerdo contiene los términos y condiciones con los que el departamento de TI (personal ejecutivo,
coordinadores e ingenieros de soporte), realizara el servicio de atención a usuarios de recursos
informáticos a la aseguradora Dentegra Seguros Dentales SA de CV. El objetivo es proporcionar las
bases teóricas y prácticas de la utilización de los recursos informáticos con que cuenta la aseguradora a
todos los ejecutivos, empleados y operadores técnicos que hacen uso de estos recursos para contar con
una operación libre de obstáculos tecnológicos.
Este acuerdo lo celebra por una parte el Departamento de Tecnologías de la Información perteneciente
a la dirección de Operaciones y Sistemas a quien se le denominara como el “proveedor” y por la otra la
Dentegra Seguros Dentales SA de CV, en lo sucesivo se le denominara “Dentegra”, quien por así
convenir a sus interés se someten a las clausulas mencionadas a continuación:
II.
Inicio y duración del acuerdo
Las responsabilidades y obligaciones que se obtienen de ambas partes debido al goce y otorgamiento del
servicio, comenzaran el primer día hábil del siguiente mes después de haber sido firmado este acuerdo
tanto por las autoridades de la Dentegra como por el proveedor y tendrá como duración efectiva 1
(uno) año natural a partir de esta fecha.
III.
Revisiones periódicas
Las revisiones a este acuerdo deberán ser al menos una vez al año y puede coincidir con el fin de
vigencia del acuerdo o en cualquier momento durante la vigencia del mismo. En caso de no realizarse la
revisión pertinente anual el acuerdo puede considerarse cancelado por cualquiera de las dos partes.
Es responsabilidad de ambas partes solicitar la evaluación y en caso de existir cambios al servicio deberán
ser autorizados por ambas partes. En caso de que se realice alguna modificación a este acuerdo deberá
ser presentado al equipo de trabajo por escrito y otorgar al menos 30 días naturales para asegurarse que
estos han comprendido las modificaciones en el servicio
IV.
Descripción del servicio
A continuación se describen las actividades que se realizaran durante el servicio:
124
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Actividad
1
Nombre del
Servicio
Centro
Telefónico
2
Centro de
Mensajería
instantánea
3
Atención en
sitio
4
Apoyos a
eventos,
campañas, etc.
V.
Descripción
Especificaciones
Asistencia a todas las
llamadas provenientes de
los usuarios
El centro telefónico deberá aceptar
llamadas durante 8 horas, 5 días a la
semana, excepto por aquellos días que
son considerados festivos
El centro de mensajería instantánea
deberá aceptar solicitudes provenientes
de los usuarios de 8 horas al día, 5 días a
la semana
Asistencia a todas las
solicitudes por medio
virtual de los usuarios
(correo electrónico,
chats, mensajeros
instantáneos, solo
aquellas aplicaciones
autorizadas para este
servicio)
Apoyo y soporte en sitio
en cualquiera de las
instalaciones de
Dentegra
Soporte a la toma de
decisiones durante la
celebración de eventos
extraordinarios en
Dentegra
Se brinda el servicio en sitio
dependiendo de la disponibilidad de los
ingenieros. En caso de que el soporte
requiera ser fuera de las oficinas de
Dentegra se deberá tener un pase de
autorización y solo podrá ser durante el
horario de atención del centro
telefónico.
Servicio solo para ocasiones en las
cuales Dentegra requiera de un apoyo
expreso
Responsabilidad de Dentegra
Las siguientes son responsabilidades por parte de los usuarios del servicio, estos pueden ser empleados,
proveedores, partners, colaboradores o que tengan una relación directa con Dentegra y con la
infraestructura tecnológica de la misma.
1.
Comunicar inmediatamente cualquier anomalía o casi extraño referente a los recursos
tecnológicos de Dentegra, esta comunicación deberá ser por escrito (correo electrónico, carta,
memorándum, etc.), llamada telefónica, a través del uso de herramientas virtuales, comunicación
oral y cualquier otro medio para reportar un desperfecto o mal funcionamiento relacionado con
los recursos tecnológicos de Dentegra
2. La manera oficial para reportar todo este tipo de eventos será a través del Service Desk
3. Proporcionar toda la información posible relacionada al problema reportado
4. Generar la documentación necesaria para reportar una incidencia
5. Contar con el tiempo suficiente para realizar todas las indicaciones que el ingeniero de soporte
requiera
6. Tomar nota y tener conocimiento del número de ticket asignado al reporte realizado
7. En caso de contar con las herramientas y el conocimiento necesario registrar en la aplicación
Sales Force la incidencia para obtener el número de atención y esperar el contacto del ingeniero
8. Realizar el conjunto de pruebas requeridas por el centro de servicio para corroborar la solución
de la incidencia
9. Autorización los cierres de incidencias cuando estas estén perfectamente resueltas
10. Tener el conocimiento de las clasificaciones del soporte para identificar a que tipo apoyo se
requiere:
125
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
a.
b.
c.
d.
e.
f.
VI.
Healthcase
Sales forcé
Soporte técnico
Administración de usuarios
Proyectos especiales
Solicitud de reporte
Responsabilidad del Departamento de TI
1.
Atender todos los requerimientos solicitados al centro de atención por parte de empleados de
Dentegra
2. La herramienta oficial para dar seguimiento a todo tipo de eventos será a través del Service
Desk
3. Otorgar un servicio rápido, cálido y acorde a las necesidades de los usuarios
4. Registro, seguimiento y solución de los problemas relacionados con los recursos informáticos
de Dentegra
5. Proporcionar orientación y capacitación de acuerdo a las necesidades de los usuarios
6. Registrar de acuerdo a las políticas y procedimientos todos los problemas (incidencias) que los
usuarios reporten al centro de atención
7. Documentar todas las actividades realizadas para la solución de incidencias
8. Cumplir con los tiempos de respuesta acordados en este documento
9. Reportar cualquier actividad sospechosa o cualquier mal uso de algún servicio o equipo
tecnológico
10. Cuidar y mantener todos los recursos tecnológicos de Dentegra
11. Mantener y seguir las medidas de seguridad de los recursos
VII.
Administración del servicio
En esta sección se especifica la disponibilidad del servicio, métricas, el mantenimiento y los reportes
necesarios para la evaluación del servicio.
a.
Disponibilidad del servicio
La disponibilidad de los servicios informáticos esta dado a razón de la siguiente tabla:
%
Disponibilidad
Restricciones
Servicio
Disponibilidad
Mantenimiento
Centro
de
Atención
Telefónica
Centro
de
Mensajería
instantánea
Atención
en
sitio
Herramientas
de computación
(PC,
periféricos,
digitalizadores,
cámaras, etc.)
Correo
electrónico
8 horas / día
5 días / semana
Fines de semana y
días feriados
99%
Falta de ingenieros
por apoyo urgente
8 horas / día
5 días / semana
Fines de semana y
días feriados
99%
Falta de ingenieros
por apoyo urgente
8 horas / día
5 días / semana
8 horas / día
5 días / semana
Fines de semana y
días feriados
Fines de semana y
días feriados
80%
80%
24 horas / día
7 días / semana
Segundo fin de
semana de cada
126
99%
Gravedad
de
la
incidencia
Gravedad
de
la
incidencia, tiempo
de
llegada
de
repuestos, etc.
Durante
mantenimiento
el
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Telefonía
24 horas / día
7 días / semana
Impresión
8 horas / día
5 días / semana
24 horas / día
7 días / semana
Portal WEB
Redes
y
cableado
estructurado
Respaldo
de
información
24 horas / día
7 días / semana
Conexión
internet
24 horas / día
7 días / semana
a
24 horas / día
7 días / semana
HealthCase
(ERP)
24 horas / día
7 días / semana
Atención
y
seguimiento a
incidencias de
cambios
(Healthcase)
8 horas / día
5 días / semana
b.
mes
Segundo fin de
semana de cada
mes
Fines de semana y
días feriados
Segundo fin de
semana de cada
mes
Segundo fin de
semana de cada
mes
Segundo fin de
semana de cada
mes
Segundo fin de
semana de cada
mes
Segundo fin de
semana de cada
mes
Fines de semana y
días feriados
Durante
mantenimiento
el
de
99%
Depende
suministros
Durante
mantenimiento
99%
Durante
mantenimiento
el
99%
Durante
mantenimiento
el
99%
Durante
mantenimiento
el
99%
Durante
mantenimiento
el
99%
90%
99%
el
Sujeto a cambios por
el usuario, tiempo
en las pruebas y
liberación
Mantenimientos del sistema
Con la intensión de mantener el nivel en el servicio aquí se presenta el esquema de mantenimiento como
un proceso obligatorio. La intención es tener lapsos de tiempo acordados para resolver problemas
asociados con el gasto habitual de los componentes o dispositivos que otorgan servicios y ventanas de
tiempo que se pueden utilizar para reacomodar, mover o intercambiar dispositivos.
El mantenimiento está dado a razón de aquellos dispositivos que se utilizan para otorgar servicios
tecnológicos a los usuarios, estos componentes y sus esquemas de mantenimientos se describen a
continuación:
Componente
Servidores
de
dominio,
aplicaciones, respaldos y de
impresión
Equipo de comunicación
(hubs,
bridges,
routers,
firewalls, wireless, etc.).
Redes (Ethernet y wireless)
UPS
Manto1
Segundo fin
de
semana de cada
mes. Sábado de las 8
pm a domingo 18:00
horas
Segundo fin
de
semana de cada
mes. Sábado de las 8
pm a domingo 18:00
horas
Segundo
fin
de
semana de cada
mes. Sábado de las 8
pm a domingo 18:00
127
Manto 2
Aplicaciones urgentes
de
parches
o
actualizaciones. Lunes
a Domingo 10 pm a
2:00 am
Reconfiguraciones
inmediatas,
falla,
reinicio de servicio.
Lunes a Domingo 10
pm a 2:00 am
Mantenimiento
preventivo cada 2
meses. Sábado de las 8
pm a domingo 18:00
Manto 3
Reemplazo
de
piezas, sustitución de
equipo, etc. Cada 36
meses
Reemplazo
de
piezas, sustitución de
equipo, etc. Cada 72
meses
Sustitución
equipo
de
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
horas
Segundo fin de
semana de cada
mes. Sábado de las 8
pm a domingo 18:00
horas
Segundo fin
de
semana de cada
mes. Sábado de las 8
pm a domingo 18:00
horas
Aire acondicionado
Base de datos
Equipo de telefonía (VoIP,
IVR, analógicas, fax, etc.)
Segundo fin
de
semana de cada
mes. Sábado de las 8
pm a domingo 18:00
horas
Equipo de cómputo
Cableado estructurado
c.
horas
Mantenimiento
preventivo cada 2
meses. Sábado de las 8
pm a domingo 18:00
horas
Liberaciones, cambios
y modificaciones a
datos o aplicativos.
Aplicaciones urgentes
de
parches
o
actualizaciones. Lunes
a Domingo 6 pm a
10:00 pm
Reconfiguraciones
inmediatas,
falla,
reinicio de servicio.
Lunes a Domingo 10
pm a 2:00 am
Mantenimiento
preventivo cada 6
meses. Sábado de las 8
am a domingo 18:00
horas
Mantenimiento
preventivo cada 12
meses. Sábado de las 8
am a domingo 18:00
horas
Sustitución
equipo
de
Migración
de
servidores o de
versión en la BD
Reemplazo
de
piezas, sustitución de
equipo, etc. Cada 36
meses
Reemplazo
de
piezas, sustitución de
equipo, etc. Cada 36
meses
Métricas del servicio
Esta sección establece las medidas utilizadas para garantizar el otorgamiento del servicio. Se basan en
tres puntos básicos, disponibilidad del servicio, desempeño del servicio y calidad en el servicio. A
continuación se presentan las métricas utilizadas para medir estos conceptos.
Métrica
Porcentaje
incidencias
cerradas
Definición
de
Tiempo
de
resolución
por
tipo
o
clasificación
de
soporte (cuando
no
son
requerimientos
HC)
Tiempo
de
resolución
por
ingeniero(cuando
La
cantidad
de
incidencias cerradas
de acuerdo a los
incidencias abiertas
Tiempo
que
transcurre entre que
se
registra
la
incidencia y se da por
resuelta y cerrada
Tiempo que tarda un
ingeniero en resolver
una tarea asignada
Bajo
Desempeño
Alto
Desempeño
Desviación
Significante
95%
85%
97%
5%
2 - 3 días
4 días
1 día
5 días
4 horas
8 horas
2 horas
24 horas
Línea
base
128
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
no
son
requerimientos
HC)
Resolution Rate
d.
Cantidad
de
incidencias resueltas
por ingeniero en un
periodo de tiempo
NA
NA
NA
NA
Requerimientos del servicio
Para el otorgamiento del servicio se establecen los tiempos de respuesta que otorgara el proveedor
dependiendo de las cargas de trabajo, el establecimiento de prioridades, las horas de atención y el desvió
de recursos por parte de la dirección. El proveedor responderá a los servicios relacionados de acuerdo a
la clasificación del soporte y bajo las circunstancias ya mencionadas a razón de los siguientes parámetros
de tiempo:
Clasificación
Tipo de Soporte
HealthCase
Problema
de
producción
Requerimiento nuevo
Solicitud
desarrollo
Sales Force
Admon.
usuarios
Proyecto
especial
de
de
Tiempo
estimado
4 hrs.
Observaciones
24 hrs.
Los nuevos requerimientos están sujetos
autorizaciones, validaciones, etc. por lo
que el tiempo descrito es para la atención
Las
solicitudes
están
sujetas
autorizaciones, validaciones, etc. por lo
que el tiempo descrito es para la atención
24 hrs.
Soporte Operativo
24 hrs.
Problema
de
producción
Asesoría técnica
Requerimiento nuevo
4 hrs.
4 hrs.
24 hrs.
Altas
24 hrs.
Bajas
Cambios
24 hrs.
24 hrs.
Adquisiciones
NA
BCP
Cambio de ofnas
Capacitación
Check out
Leasing
Servicios
Soluciones
NA
NA
NA
NA
NA
NA
NA
Los nuevos requerimientos están sujetos
autorizaciones, validaciones, etc. por lo
que el tiempo descrito es para la atención
Por la naturaleza de los proyectos
especiales, los tiempos se acuerdan con el
usuario y se respetan los tiempos
comprometidos
129
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Solicitud
reporte
e.
de
Web
AMIS
NA
48 hrs.
Aseguradoras
Clientes
CNSF
SS
48 hrs.
48 hrs.
48 hrs.
48 hrs.
Tiempo dado a razón de que no
corresponde a un nuevo desarrollo o a
un nuevo reporte
Reportes
Porcentaje de incidencias cerradas
Reporte donde se indican las incidencias abiertas durante un periodo de tiempo (generalmente 1 mes),
de esas incidencias se agrupan por la clave del estado en el que se encuentran en el momento del
reporte. Diagrama de barras donde se expresan la cantidad de incidencias vs los distintos estados de las
incidencias: Cerrados, Nuevo, En análisis, Liberados a desarrollo y En espera de terceros. Tiempo de
resolución por tipo o clasificación de soporte (cuando no son requerimientos HC)
En este reporte se entregaran los tiempos que se consumieron para la resolución y cierre de las
incidencias de acuerdo a la clasificación de soporte:
a.
b.
c.
d.
e.
Sales force
Soporte técnico
Administración de usuarios
Proyectos especiales
Solicitud de reporte
Tiempo de resolución por ingeniero (cuando no son requerimientos HC)
En este reporte se entregaran los tiempos que se consumieron para la resolución y cierre de las
incidencias que atendió cada ingeniero y de acuerdo a la clasificación de soporte:
a.
b.
c.
d.
e.
Sales force
Soporte técnico
Administración de usuarios
Proyectos especiales
Solicitud de reporte
Resolution Rate (RR)
Reporte que indica cuantas incidencias y de qué tipo, ha resuelto cada ingeniero
f.
Penalidades
Las penalidades se reportaran a la dirección y estas quedaran a reserva del Gerente y/o Director de
Sistemas o en su caso se harán llegar a la dirección general para su consideración.
Las penalidades podrán ir desde una llamada de atención a los ingenieros o quien resulte responsable de
una desviación significativa de las métricas; hasta consecuencias tales como una falta administrativa o en
su caso el descuento proporcional de la retribución de la persona que resulte responsable. Esto siempre
y cuando se compruebe que fue debido a una falta de seguimiento o a una falta de seguimiento a las
reglas
130
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
4.7
Implementación de mejores prácticas
Existen diversos factores para mejorar procesos, métodos o mecanismos dentro de
una organización y en general tienen que ver con la optimización de los recursos, sin
embargo en ocasiones las personas encargadas de que ocurran estos cambios suelen
ser afectadas por diversos factores, como pueden ser: sus principios o la manera de
hacer las cosas, la rutina para ejecutar una acción que se ha realizado durante un
lapso importante de tiempo y en determinado momento hasta la creatividad para
realizar una actividad con resultados cada vez mejores, es por eso la importancia de
tener un marco de referencia relacionado con las actividades propias de lo que nos
compete.
Las mejores prácticas (y como lo hemos venido manejando, ITIL v3) tienen que ver con
la implementación de un marco de trabajo (una manera de hacer las cosas dentro del
departamento de TI y por lo tanto de la organización) que no solo es un concepto
desarrollado por uno o varios autores y que pudiera ser o no aceptado, mejor aún, es
una opción de trabajar con conceptos prácticamente aceptados a nivel mundial y esta
aceptación ha sido acreditada gracias a que se ha podido comprobar que no importa el
tamaño o la manera de administrar una organización, son conceptos que a todos los
niveles tienen un sustento teórico/practico y que en algún momento una organización
tuvo que echar mano de estos procesos obteniendo un alto porcentaje de éxito en la
optimización de sus recursos.
Tampoco pretendemos decir que las mejores prácticas son una receta directa al éxito,
en realidad no la podríamos considerar siquiera una receta, más bien, la consideramos
como una manera de asegurar que el departamento de TI trabaje con objetivos
alineados al negocio en lugar de trabajar únicamente para resolver problemas técnicos
que pudieran llegar a tener los usuarios.
Y la manera de lograr esto es considerando a los procesos de TI y la infraestructura
tecnológica como piezas fundamentales para el éxito de la organización. También hay
que considerar una sencilla ecuación antes de implementar las mejores prácticas: si
queremos que el resultado de esta implementación sea exitosa, debemos considerar la
disciplina que todo el equipo de trabajo debe observar durante el día a día, no hay que
olvidar que si no se puede medir, no se puede controlar; si no se puede controlar, no
se puede administrar; y peor aún, si no se puede administrar, no se puede mejorar.
Evidentemente Dentegra carece de estos conceptos y la manera de realizar sus
actividades dentro del departamento de TI es de una forma reactiva, no existen
reportes o estadísticas que nos indiquen la utilización de los recursos, los problemas
que más recursos consumen o los tiempos que tardan las personas en el
departamento de TI para resolver alguna situación.
Por lo que esta implementación se basa en poner las guías necesarias para la puesta
en marcha de los procesos relacionados con la atención y servicio al cliente para
promover un aprovechamiento de las personas, el negocio y la tecnología a través de
la mejora de los servicios informáticos con los que cuenta Dentegra, además de evitar
la dependencia hacia los individuos y equipos claves haciendo funcionar el
departamento de TI como un todo orientado a un fin común.
El resultado esperado se encuentra determinado en:
131
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN





La reducción de costos
La mejora de los servicios de TI
Una mayor satisfacción de los usuarios
Mejora en la productividad (generando un mayor valor agregado)
Mejor aprovechamiento de las habilidades y experiencia con que cuenta el
equipo del departamento de TI
Además de esto, no podemos dejar afuera las regulaciones y el marco jurídico que la
misma autoridad nos requiere por lo que dentro de esta implementación se manejan
algunos conceptos propios de la regulación Cobit, y que básicamente está orientada
para:




Prevención de fraudes
Control de presupuestos
Asignación de recursos informáticos
Administración de proveedores
En términos generales la aportación que tomamos de Cobit para esta implementación
es la Administración de actividades dentro del departamento de TI a través de
proyectos y la definición de los roles y el tipo de comunicación existente entre cada uno
de los involucrados en los departamentos de soporte técnico y desarrollo,
representados en el siguiente esquema.
Matriz RACI
En seguida se muestra la definición de los roles correspondientes a la matriz RACI
respecto a las mejores prácticas (ITIL, COBIT), (Dentegra Seguros Dentales, 2008):




R: Responsable (Responsible)

Aquellos que llevan a cabo la actividad o toman la decisión.

Las responsabilidades pueden ser compartidas.
A: Encargado (Accountable)

Individuo, quien tiene en última instancia la responsabilidad.

Solo una persona puede ser responsable por cada tarea.
C: Consultado (Consulted)

Aquellos que deben ser consultados para proporcionar información antes de que se
ejecute una actividad o se tome una decisión.

Es un proceso en dos direcciones – bidireccional.
I: Informado (Informed)
132
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN

Aquellos que deben ser informados después de que se lleve a cabo una actividad o se
tome una decisión.

Es un proceso de una dirección - unidireccional.
A continuación se muestran los roles para el área de Soporte Técnico.
Coordinador de
Soporte Técnico
Tier 1 (T1)
Christian Hernandez
Support Center
Tier 2 (T2)
Usuario IT
Support Center , CA.
Usuarios que
utilizan el Servicio
Cliente
DENTEGRA
Proveedores
A continuación se define la matriz RACI correspondiente al Área de Soporte Técnico para el área de
Sistemas.
133
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Coordinado
r de
Soporte
Técnico
T1
Support
Center
Usuario
IT
T2
Operation
Manager /
Incident
Manager
Detectar
R
I
A
I
Registrar
R
I
C
Clasificar
R
I/C
C
Investigar y
Diagnosticar
I/R
I/C
I/A
C
Resolver/Recuperar
I/R
I/R
A
I
Cerrar
R
R
C
Monitorear,
seguimiento y
Comunicar
R
R
I
Mejora del Proceso
I
I
A
Reporteo de
Incidentes
I
I
I/C
Cliente
I
I
Detectar Problemas
Alimentar Base de
Datos
I
Evaluar Servicio
Feedback
A
134
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
A continuación se muestran los roles para el área de Desarrollo (HealthCase).
Coordinador de
Desarrollo
Tier 1 (T1)
Omar Ramírez
Delta
(Development,
DBA)
Tier 2 (T2)
Support Center ,
CA.
Proveedor
(Intercase)
Tier 3 (T3)
Usuario IT
Cliente
Usuarios que
utilizan el Servicio
DENTEGRA
Proveedores
A continuación se define la matriz RACI correspondiente al Área de Desarrollo (HC) para el área de
Sistemas.
135
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Project
Leader
Evaluar
Desarrollo
A/R
Detectar
A
Coordina
dor de
Desarrollo
Tier 1
(T1)
Delta
(Developm
ent, DBA)
Tier 2 (T2)
Proveedor
(Intercase)
Tier 3 (T3)
Usuario
IT
Cliente
A
R
I
I
A/R
Registrar
R
I
I
R
Clasificar
R
I/C
I/C
C
Investigar y
Diagnostica
r
I/A
I/R
I/C
I/C
C
Resolver/Re
cuperar
A
I/R
I/R
I/R
I
Cerrar
R
R
R
C
Monitorear,
seguimient
oy
Comunicar
R
R
R
I
I/A
Mejora del
Proceso
A
I
I
I
Reporteo
de
Incidentes
I/C
I
I
I
I
Detectar
Problemas
Alimentar
Base de
Datos
I
Evaluar
Servicio
Feedback
A
136
A
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Por último diremos que las mejores prácticas van de la mano con el ciclo de vida del
servicio tecnológico, es decir, al igual que los productos comerciales, los servicios
también van de la mano con un ciclo de vida típico de cualquier producto, que inicia
con la introducción del servicio al mercado o a la organización para su uso y consumo
y finaliza con la baja o extracción de este servicio en el catálogo. Así es como daremos
inicio a la implementación de las mejores prácticas en Dentegra, tomando como base
la iniciación de dos servicios, dándole seguimiento hasta su implementación y
consolidando las bases para su mejora continua. Para efectos de este trabajo es
importante decir que solo se mencionaran dos servicios o la implementación de estos
hacia las mejores prácticas, ya que se considera que pueden ser los más
representativos con la finalidad de mostrar de manera didáctica los pasos seguidos
para la introducción de las mejores prácticas en una aseguradora dental como lo es
Dentegra. Evidentemente la implementación se realizó en un número importante de
servicios, desafortunadamente y por tratarse de información confidencial para Dentegra
solo se presentan estos servicios para su estudio e implementación.
La propuesta de implementación en Dentegra se considera en 5 etapas principales:
1. El análisis de las condiciones en las que se encuentran los servicios
actualmente
Como vimos en el capítulo 1 Dentegra es una organización de reciente creación y que
como todas las empresas tiene fortalezas y debilidades. Dentro del departamento de TI
cuenta con las normas, políticas y procedimientos desarrollados a través de una
metodología tradicional, es decir, el departamento de TI hace las funciones de un
proveedor de soluciones que apoyan las actividades de la organización.
Sin embargo en los últimos 18 meses ha tenido un crecimiento importante tanto en
clientes como en empleados (usuarios) y esto hace que el trabajo sea mayor y las
tareas sean cada vez más complejas. El concepto de servicios tecnológicos en
Dentegra es nulo, y prácticamente inexistente la obtención de alguna métrica para
evaluar el desempeño dentro del departamento o el conocimiento de la distribución de
los recursos.
Los procesos que se utilizan para la obtención de resultados tienen una relación directa
con el número de quejas que se tienen del departamento, es decir, que los procesos
han sido modificados tomando en consideración las peticiones del usuario y estos a su
vez son los encargados de dar una retroalimentación o una calificación al
departamento, por lo que el servicio se torna de manera reactiva.
Cada vez que un usuario tiene un problema con su computadora, el correo electrónico
o su teléfono, se evalúa el nivel de usuario que tiene el problema y se le da una
prioridad, entre más alto sea el rango del usuario mayor será la prioridad asignada para
resolver el problema. De esa manera el departamento de TI obtiene una “calificación”
ante la dirección y en base a esa percepción se le dan recursos y presupuesto al
departamento.
137
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
2. Fijación de metas y objetivos
Los objetivos en términos general pueden mostrarse muy ambiciosos y no es para
menos ya que se pueden obtener un número importante de beneficios, sin embargo
para efectos de este estudio los limitaremos a:




Implantación de una manera consistente de evaluación del personal de TI
Mejorar la calidad en el servicio
Enfoque orientado a los servicios tecnológicos en Dentegra
Alinear los objetivos de Dentegra con los del departamento de TI
Estos objetivos se acotaron durante la definición del dominio de Planear y
Organizar y están divididos en dos tipos:
o
Orientados a la Alta dirección y gerencias funcionales / Auditoria
 Compromiso por parte del personal (solo aquel personal que
está altamente relacionado con el departamento de TI:
operaciones, call center, mesa de control, etc.) que entiende los
objetivos del departamento de TI
 Incrementar la confianza y el involucramiento de los usuarios y
patrocinadores del negocio a través de acciones de
retroalimentación
 Mejorar la calidad, respuesta y fiabilidad de las soluciones y
servicios de TI
 Establecimiento de un comité de dirección y gobierno de TI con
las responsabilidad de comunicar aspectos a la dirección
 Garantizar la entrega de proyectos de TI en tiempo y forma
 Garantizar el cumplimiento de los requisitos regulatorios por
parte del departamento de TI
o
Orientados a la Gerencia de TI
 Asegurar que los recursos de TI se han organizado de manera
eficiente y que existe la capacidad para soportar nuevas
funcionalidades
(infraestructura
tecnológica,
procesos,
habilidades del personal)
 Reducir riesgos, incidentes y fallas en los servicios, procesos y
proyectos
 Incrementar el potencial del staff del departamento de TI, es
decir, tener menos recursos expertos pero mejor capacitados
 Lograr el cumplimiento y aplicación de controles internos
3. Plan de acción
El plan de acción se divide en 6 puntos que contemplan las principales actividades
realizadas:
I. Punto único de recepción de problemas (Service Desk)
Con la selección del Service Desk hibrido con el que contara Dentegra y con el
esquema de registro y atención a los usuarios se espera:
138
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
a. Definición de métricas: Utilización de la herramienta para registro de
incidencias, tiempos de resolución de incidencias
b. Documentación del proceso: Manuales de generación de casos o incidencias
en Sales Force©
c. Mejora el servicio al usuario: Encuesta de satisfacción del usuario final
II. Gestión de incidencias y Gestión de problemas
Dentro de las actividades de la gestión de incidencias y problemas se consideran
las siguientes metas a alcanzar:
a. Identificar, registrar y categorizar, priorizar, resolver y cerrar una incidencia.
Anexo B
b. Generación de procesos para soporte técnico. (Proceso de apertura de
incidencias para Soporte Técnico)
c. Niveles de soporte para la jerarquización de una incidencia
d. Determinar la relación entre incidencia y problema
e. Proceso para gestionar problemas
III. Gestión de cambios
En la gestión de cambios lo más representativo para la implementación es definir la
siguiente documentación:
a. Generación de procesos para desarrollo. (Proceso de apertura de
incidencias para nuevos desarrollos y/o cambios a una aplicación existente)
b. Análisis, definición, petición e implementación del cambio
IV. Capacitación
Dentro del proceso de capacitación para la adopción de las mejores prácticas se
preparan 3 tipos de materiales:
a. Presentación en diapositivas.
b. Videos relacionados. Videos no proporcionados por temas de derechos
c. Papelería y formatos necesarios para el seguimiento de los procesos.
(machote de Petición del cambio)
V. Implementación
La implementación es un proceso que va de la mano con los tiempos y la puesta a
punto, para esto se genera un plan de trabajo con las principales actividades:
a. La adecuación de la aplicación para el Service Desk
b. La instalación del software y herramientas necesarias para la iniciación del
servicio
c. Capacitación a distintos niveles
d. Puesta en marcha (go-live7)
7
La primera vez que un sistema informático es usado, después de realizarle todas las pruebas requeridas y
con la aprobación del equipo de trabajo, departamento, etc.
139
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
A continuación se presenta el diagrama de Gantt referente a las actividades de la
implementación de las mejores prácticas:
Figura 35. Diagrama de actividades de la implementación de las mejores prácticas (Elaboracion propia,
2007)
140
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
Además en la siguiente figura se puede observar el catálogo de servicios en donde se
representan los responsables de los distintos servicios, organizacionalmente están
dividas los equipos de trabajo en 4 sectores:




Negocio
Servidores y acceso centralizado
Telecomunicaciones
Estación de trabajo
Figura 36. Diagrama del catálogo de servicios en Dentegra (Dentegra Seguros Dentales, 2008)
Cada uno de estos equipos es responsable de otorgar un servicio de calidad a los
usuarios finales considerando todos los requisitos anteriormente platicados para
asegurar la entrega y servicio de estos.
Los recuadros grises contemplan los servicios implementados en esta investigación, ya
que por efectos de confidencialidad no es posible presentar en su totalidad la
implementación de todos los servicios descritos en la figura 36.
Para ser consistente con la metodología de ITIL v3 a continuación se describen las
acciones realizadas de acuerdo a los puntos que propone la metodología.
141
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
4.7.1 Estrategia del Servicio (Service Strategy)
En esta etapa es necesario determinar la clase de servicios que deberán ofrecerse a
los clientes del departamento de TI, en este caso solo hablaremos de los servicios que
se presentan en este trabajo, es de suponerse que la implementación en Dentegra
incorporo algunas otras situaciones mismas que derivaron en otros servicios.
Para entender el motivo del porque se requieren implementar tanto los servicios del
Service Desk como los de Incidencias y Problemas a las mejores prácticas, haremos
un breve análisis de lo que ocurre en Dentegra y en base a eso podremos cubrir el
principal objetivo de la Estrategia del Servicio: Que la organización piense y actué
estratégicamente de la mano con la tecnología.
Dentegra y el síndrome del Súper Héroe
Es común que en las organizaciones existan recursos con un mayor número de
habilidades que otros, estos recursos generalmente sobresalen de los demás y
muchas veces debido a su potencial y en general a todos nos gustaría contar con
colaboradores de este tipo.
En Dentegra y más específicamente en el departamento de TI existe una persona que
sabe todo acerca de la infraestructura, que todas las personas lo buscan cuando existe
un problema y que mejor aún sabe cómo manejar una situación de crisis, conoce a
todo el personal y por supuesto cumple con todas sus tareas en tu tiempo
razonablemente bueno, podemos decir que es el Súper Héroe de Dentegra. Sale muy
tarde, tiene que acudir en horarios y días inhábiles, el trabajo es manejable y sin duda
Dentegra no podría operar sin este individuo.
Esto es muy común en empresas de reciente creación, donde como en Dentegra un
mismo empleado debe utilizar varias gorras o cachuchas desempeñando distintos roles
y esto generalmente debido a los bajos presupuestos. Sin embargo se trabaja así
porque ha funcionado hasta ese momento y no se requiere una mayor inversión.
Afortunadamente Dentegra crece en clientes, empleados y en volumen de actividades
y por supuesto cada vez requiere de un mayor número de servicios tecnológicos y le
demanda cada vez más cosas a nuestro Súper Héroe. Ahora este personaje ya no
puede tomar vacaciones, no se puede enfermar, tiene que dormir cada vez menos
horas y se siente cada vez menos valorado por la organización, ya que su esfuerzo es
mayor y la recompensa sigue siendo la misma.
La situación se vuelve caótica y las funciones sobrepasan a nuestro personaje, en
algunos casos se puede resistir a este cambio sin mucha evolución, pero en algunas
otras se siente amenazado en su situación laboral, porque “ya no puede con el trabajo”
y siente que lo van a correr; así que decide retirarse por sus propios medios.
Evidentemente lo que menos necesita Dentegra es que el conocimiento se vaya con
una persona.
Este es un caso de análisis en el que por supuesto nuestro personaje no deja su
puesto en Dentegra pero logra representar un fenómeno muy común dentro de las
142
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
organizaciones que de seguir así en Dentegra hubiera terminado en lo inevitable y lo
peor para ambas partes.
Para entender la estrategia de los servicios podemos citar a Peter F. Druker
considerado como el más grande filosofo del management en el siglo XXI cuando dice:
"…posiblemente ninguna organización pueda sobrevivir si necesita genios o
superhombres para ser administrada. Se debe poder gestionar de una manera
tal que permita ser liderada por hombres comunes." (Druker, 1974)
Por lo que lo primero que requerimos es el establecimiento de un paradigma que se
enfoque a los servicios (dentro de la organización) y una vez conseguido esto
evaluamos los servicios existentes que para la situación actual de Dentegra los
servicios del Service Desk, Gestión de Incidentes y Problemas, así como la Gestión de
los Cambios es nula por lo que se inicia con la definición de la estrategia de estos
servicios.
La estrategia de los servicios está considerada en los puntos 4.1, 4.2, 4.3 y 4.4 de este
capítulo.
Gestión Financiera
Los costos relacionados con estos servicios son directamente sumados a la facturación
del proveedor de Sales Force©.
La actualización del licenciamiento es un monto perfectamente aceptable y que
además es único anual, por los presupuestos financieros no se verán afectados en
Dentegra.
4.7.2 Diseño del Servicio (Service Design)
Gestión del Catálogo de Servicios
Como se observa en el catálogo de servicios se enlistan los servicios definidos para
Dentegra, aquellos que están sombreados en color gris son aquellos que se
implementan en este momento, los demás tendrán un proceso similar.
Se denota la interrelación entre estos servicios y el lugar que ocuparan de acuerdo a la
prioridad asignada.
Gestión del Nivel de Servicio (SLM)
Se considera un Acuerdo de Nivel de Servicio para el esquema de Service Desk, es
decir se genera un documento que compromete a ambas partes y donde se regulan los
compromisos. (Acuerdo de Nivel de Servicio)
143
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
4.7.3 Transición del Servicio (Service Transition)
Gestión de Cambios
Para el servicio de HealthCase (ERP de Dentegra) se implementa la gestión de los
cambios, este proceso está documentado en la sección 4.4 de este capítulo y
contempla los pasos requeridos para el mantenimiento del funcionamiento del servicio
HealthCase con un mínimo impacto en el negocio. No hay que olvidar que HealthCase
es la columna vertebral de la operación de Dentegra y su porcentaje de disponibilidad
deberá ser alrededor del 99%.
Otra gestión de cambios también tiene que ver con cambiar un servicio, es decir, el
servicio actual no cubre con las necesidades del cliente y requiere una mejora o
adecuación, para esto se tomara el mismo formato del proceso presentado y se
seguirán los mismos pasos hasta llegar a la implementación del cambio.
Desarrollo y Personalización de Aplicaciones
Todos los cambios propuestos están referenciados en la sección 4.1.4 de este capítulo.
Ahí se explican los cambios necesarios a la aplicación de Sales Force© para poder
satisfacer las necesidades de esta implementación.
En la figura 37 se presentan los principales cambios realizados a la aplicación.
Figura 37. Adecuaciones a SF de acuerdo a las mejores prácticas (Dentegra Seguros Dentales, 2008)
Gestión del Conocimiento
El diseño de la CMDB lo podemos observar en el Diseño conceptual de la Base de
Datos y se describe su funcionalidad en el punto 4.5 de este capítulo, como podemos
observar esta base de conocimiento es el primer paso para crear una base de datos de
conocimientos donde se puedan relacionar las incidencias más comunes con posibles
soluciones y así evitar un redescubrimiento de los conocimientos.
144
CAPITULO 4: PROPUESTA DE IMPLEMENTACIÓN
4.7.4 Operación del Servicio (Service Operation)
Gestión de Incidentes y Problemas
Llevar y mantener el registro, análisis, jerarquización, solución, autorización o
verificación y cierre de todos los incidentes reportados por los usuarios, en otras
palabras manejar el ciclo de vida de las incidencias (apartado 4.2 de este capítulo) y
por supuesto el seguimiento y mejora de estas incidencias, es decir, los problemas;
manteniendo un firme control sobre las incidencias podemos manejar los problemas y
gracias a esto evitar incidencias futuras esto gracias a una gestión proactiva de los
problemas (apartado 4.3 de este capítulo).
4.7.5 Mejoramiento Continuo del Servicio (Continual Service Improvement)
Evaluación de Servicios
Para efectos de esta investigación solo se presentan las bases para la mejora
continua, desafortunadamente por efectos de tiempo y recursos no es posible realizar
un análisis completo de los servicios, realizar una encuesta de satisfacción de los
usuarios, darle seguimiento con un cambio al servicio y realizar con esto todos los
pasos relacionados con el ciclo de vida de un servicio, sin embargo se considera que
están todas las herramientas necesarias para poder realizar esto en un momento
adecuado para Dentegra.
Por el momento solo mencionaremos que la mejora de estos procesos está basada en
la correcta interpretación de las métricas, un apropiada gestión de los servicio y sobre
todo en el control y la disciplina que se tenga en el departamento de TI.
145
RESULTADOS
I.
Resultados
El marco de referencia, la metodología e incluso la literatura nos dan herramientas para
llevar a cabo actividades y estas a su vez nos arrojan un resultado, que puede ser
bueno o malo. La evaluación de los resultados es un proceso largo complejo y más aún
cuando las actividades que estamos considerando nunca antes se habían realizado,
cuando es una metodología nueva o de reciente ingreso en nuestro país y además
cuando el equipo de trabajo no tiene una formación orientada a los servicios
tecnológicos.
Este proceso de evaluación de resultados lo abordaremos de dos maneras: la primera
haciendo hincapié en los resultados esperados y la segunda presentando todos
aquellos fenómenos que aportan un valor agregado a nuestro producto.
A continuación se presentaran los resultados obtenidos durante los primeros 3 meses
de operación con esta nueva metodología en Dentegra.
El objetivo de este primer trimestre es:



Presentar, reportar y analizar la tendencia de los principales indicadores de
servicio en el departamento
Dar a conocer los avances en requerimientos y proyectos atendidos en el área
de Sistemas
Llevar un control mensual para la evaluación y desempeño de los integrantes
del equipo
Las métricas que se consideran para los reportes serán los siguientes:



II.
Tendencias y comportamiento de las incidencias
Tiempo de solución
Evaluación de desempeño (RR)
Tendencias y comportamiento de las incidencias
La grafica siguiente nos muestra el uso de la aplicación de Service Desk durante los
tres primeros meses. La tendencia de la gráfica muestra claramente como el uso de la
aplicación es cada más ves requerido; esto nos da una señal clara de que el
compromiso tanto de Dentegra como del departamento de TI es fuerte en el sentido de
seguir la metodología y da una certidumbre de que todo el equipo de trabajo está
involucrado y convencido de que estas prácticas llevaran a una mejora integral.
146
RESULTADOS
Figura 38. Tendencias de las incidencias durante el primer trimestre de operaciones (Elaboracion propia,
2012)
Las siguientes graficas nos muestra la cantidad de incidencias reportadas en este
mismo periodo comparado con las del año anterior. Los datos del año anterior se
obtuvieron de los reportes mensuales entregados a la dirección antes de la aplicación
de la metodología.
Para poder realizar una comparativa efectiva se realizó la transformación de los datos
del año anterior y equiparándolos podemos ver una pequeña pero significativa
desviación en las incidencias clasificadas como soporte técnico (Servicio de Estación
de Trabajo). Aquí podemos observar una de las ventajas que nos ofrece la
metodología, una mayor precisión en los datos arrojados y por lo tanto una visión más
acercada a la realidad, existen más de 10 puntos porcentuales en esta clasificación y
es factor para la toma de decisiones. A continuación se analizan las incidencias de tipo
soporte técnico y se presentan los cambios generados en el departamento.
147
RESULTADOS
Figura 39a. Comparación de incidencias del 2011 al 2012 (Elaboracion propia, 2012)
Figura 39b. Comparación de incidencias del 2011 al 2012 (Elaboracion propia, 2012)
148
RESULTADOS
Gestión de Incidencias
Incidencias de tipo Soporte técnico
En la siguiente grafica vemos el estatus de las incidencias que se aperturarón durante
los meses analizados (incidencias solo de tipo soporte técnico). Es una comparativa de
3 factores principales, todas las incidencias abiertas vs los estatus en los que se
encuentran estas mismas al final del mes y por ultimo todas aquellas incidencias
cerradas al fin de mes o al final de cada evaluación.
Figura 40a. Estado de incidencias de Soporte Técnico por mes (Elaboracion propia, 2012)
149
RESULTADOS
Figura 40b. Estado de incidencias de Soporte Técnico por mes (Elaboracion propia, 2012)
Figura 40c. Estado de incidencias de Soporte Técnico por mes (Elaboracion propia, 2012)
150
RESULTADOS
El resumen lo podemos observar en la siguiente grafica – tabla:
Figura 41. Estado de incidencias de Soporte Técnico en el trimestre (Elaboracion propia, 2012)
Estado
Enero
Febrero
Marzo
Cerrado
92%
94%
86%
Nuevo
1%
5%
12%
Análisis
En espera de tercero
3%
4%
0%
1%
0%
2%
100%
100%
100%
TOTAL
(Elaboracion propia, 2012)
Existen 3 factores principales a evaluar con esta información, el porcentaje de
incidencias cerradas, el porcentaje de incidencias en estatus “En espera de tercero” y
el porcentaje de incidencias en estado “Análisis” y “Nuevo”.
Incidencias Cerradas: Un promedio de 90.6% de incidencias cerradas en el trimestre,
muy por debajo de lo comprometido en el SLA desde el mes de enero; una vez
obtenidos los datos del primer mes con la metodología y previamente el bajo
rendimiento en la solución de las incidencias durante los años previos dieron la pauta
para incrementar la plantilla en el área de soporte técnico. Esta información fue el
detonante para incrementar en una posición los ingenieros que otorgaban el soporte.
Aquí se presenta la primera decisión estratégica que toma la dirección de Dentegra
considerando la metodología de las mejores prácticas.
151
RESULTADOS
III.
Tiempos de solución
Una posición extra en los ingenieros de soporte ayuda a disminuir el porcentaje de
incidencias con estatus en Análisis y Espera de Terceros, sin embargo se incrementan
las de tipo Nuevo. La conclusión que podemos obtener de esto es que el nuevo
recurso podía atender más incidencias, pero eso no garantizaba que le diera una
solución, las incidencias dejaban de estar en estatus de análisis o esperando por el
apoyo de un nivel más alto de soporte pero a cambio de eso pasaban a estar en el
estatus de nuevo, que para fines de evaluación de servicio esto es aún peor.
El comportamiento de los tiempos de solución para los casos de soporte técnico (no
HC) se muestra en la siguiente gráfica:
Tiempos de solución de incidencias
Días
12
10
8
6
4
2
0
Enero
5
Febrero
5
Marzo
3
Soporte Técnico
2
3
3
Admon. usuarios
1
1
2
Proyecto especial
12
5
8
Sol. de Reporte
5
4
5
Sales Force
Figura 41. Tiempo de solución de incidencias de Soporte Técnico en el trimestre (Elaboracion propia,
2012)
Tomando en consideración los valores acordados en el SLA podemos evaluar el
desempeño del departamento en los tiempos de solución por clasificación de soporte,
aquí podemos observar 3 rubros Sales Force©, Proyecto Especial y Solicitud de
Reportes donde claramente vemos una desviación importante en las métricas; existen
valores con más de 5 días tomados para la solución de la incidencia y esto representa
una desviación significante de acuerdo a nuestro SLA. La medida de solución para este
caso específico fue la separación de métricas, es decir, el SLA contempla dos tipos de
tiempos de solución: los referentes a HC y los que están fuera de HC, considerando a
todos las demás incidencias como un subtipo de soporte técnico; sin embargo esto no
es del todo cierto, es decir, existen rubros como los proyectos especiales donde
pueden tomar desde 1 hasta 20 días hábiles para la solución y eso no recae como una
responsabilidad del departamento y por lo tanto deberá estar en otro tipo de métrica
dentro del SLA y así se realizó la propuesta a la dirección con el fin de contar con
evaluaciones reales con resultados reales.
152
RESULTADOS
Incidencias Generales
En la siguiente grafica vemos el estatus de las incidencias que se aperturarón durante
los meses analizados (incidencias no solo de tipo soporte técnico). Es una comparativa
de 3 factores principales, todas las incidencias abiertas vs los estatus en los que se
encuentran estas mismas al final del mes y por ultimo todas aquellas incidencias
cerradas al fin de mes o al final de cada evaluación.
Figura 42a. Estado de incidencias por mes (Elaboracion propia, 2012)
153
RESULTADOS
Figura 42b. Estado de incidencias por mes (Elaboracion propia, 2012)
Figura 42c. Estado de incidencias por mes (Elaboracion propia, 2012)
154
RESULTADOS
El resumen lo podemos observar en la siguiente grafica – tabla:
Figura 43. Estado de incidencias en el trimestre (Elaboracion propia, 2012)
Resumen
Estado
Enero
Febrero
Marzo
Cerrado
91%
94%
91%
Nuevo
4%
4%
7%
Análisis
1%
0%
0%
Liberado Desarrollo
En espera de tercero
1%
3%
0%
1%
1%
1%
100%
100%
100%
TOTAL
(Elaboracion propia, 2012)
Del promedio de las incidencias abiertas observamos que solo el 92% de ellas se han
cerrado y según el acuerdo de nivel en el servicio el departamento se encuentra en
falta ya que se acordó cerrar al menos el 95% de ellas, las razones han sido de distinta
índole, sin embargo el principal problema que se observa es el reciente ingreso de un
ingeniero de soporte que por su curva de aprendizaje se han visto deteriorados los
tiempos. Las acciones a tomar serán:

Una extensa capacitación hacia recursos de recién ingreso
155
RESULTADOS


No incluir a ningún recurso de recién ingreso a las actividades operativas hasta
garantizar que este tenga el nivel de atención mínimo requerido para otorga el
servicio
Considerar en el SLA un lapso de tiempo piloto para los recursos de recién
ingreso
Gestión de Cambios
Como podemos observar en el catálogo de servicios la gestión de cambios está
planteada básicamente como un servicio para el sistema de HealthCase (HC), a
continuación analizaremos el comportamiento de las incidencias de HC y su estatus
(abiertos vs cerrados) por mes.
Figura 44a. Estado de incidencias mes Enero HC (Elaboracion propia, 2012)
156
RESULTADOS
Figura 44b. Estado de incidencias mes Enero HC (Elaboracion propia, 2012)
Figura 45a. Estado de incidencias mes Febrero HC (Elaboracion propia, 2012)
157
RESULTADOS
Figura 45b. Estado de incidencias mes Febrero HC (Elaboracion propia, 2012)
Figura 46a. Estado de incidencias mes Marzo HC (Elaboracion propia, 2012)
158
RESULTADOS
Figura 46. Estado de incidencias mes Marzo HC (Elaboracion propia, 2012)
El primer factor a evaluar es la cantidad de incidencias abiertas por mes, si bien los dos
primeros meses son muy parecidos para el mes de marzo podemos observar un
incremento significativo, debido principalmente a las incidencias que terminan en
problemas. Si bien la gestión de cambios la podemos observar en las incidencias
clasificadas como problemas de producción y soporte operativo el verdadero aporte de
la metodología se encuentra en aquellos clasificados como Solicitud de Desarrollo.
Esto gracias a que la gestión de problemas nos da la pauta para hacer cambios en la
aplicación y con esto evitar una gran cantidad de incidencias de problemas de
producción y soporte operativo.
Si bien con estas graficas no se observa al 100% el beneficio si podemos concluir que
las solicitudes de desarrollo son directamente proporcional a la solución de problemas
encontrados en HC.
Los tiempos acordados están basados en horas para todo lo referente a HC, las
solicitudes de contraseñas muestran un desempeño excelente en cuanto a los tiempos
de solución; los problemas de producción y soporte operativo están dentro de los
rangos permitidos sin embargo se puede analizar de una manera exhausta para poder
mejorar estos números, los requerimientos nuevos y las solicitudes de desarrollo están
fuera de todo margen identificándose como otra subcategoría de las incidencias de HC.
Se recomienda la generación de otra clasificación con métricas y análisis por separado.
En cuanto a los tiempos de solución de las incidencias en HC podemos observar lo
siguiente:
159
RESULTADOS
Figura 47. Tiempo de solución de incidencias en el trimestre de HC (Elaboracion propia, 2012)
IV.
Proyectos en el departamento de TI
A continuación vemos una diapositiva de la presentación realizada a la dirección del
esquema de proyectos manejados actualmente en el departamento de TI. Este es uno
de los principales cambios y aportaciones de Cobit hacia el ejercicio de gobierno en TI.
Uno de los objetivos de control es la reducción de riesgos, incidentes y fallas en los
proyectos, en otras palabras tener gobierno en los proyectos de TI. Debido a la
naturaleza de confidencialidad de todos estos proyectos para Dentegra no es posible
presentar a detalle la implementación de cada uno de estos, sin embargo podemos
decir que se tomó como base metodológica la definida por el PMI (PMI, Project
Management Institute, 2000) (Project Management Institute) para la gestión de los
proyectos. PMI que es una asociación profesional fundada en 1969 en Newton Square
Pennsylvania, Estados Unidos y que se encarga de:



Homologar estándares en la administración de proyectos
Certificar profesionales en la administración de proyectos
Realizar programas de investigación, prácticas y ejecución de la administración
de proyectos
Todo esto en conjunto con el comité de TI para comunicar la situación, avances y
conflictos que se presentan en los distintos proyectos, en la figura 48 podemos
observar una diapositiva de una de las presentaciones del comité a la dirección
indicando los proyectos y sus estatus.
160
RESULTADOS
Figura 48. Presentación de nuevo esquema por proyectos (Dentegra Seguros Dentales, 2010)
En la figura 49 observamos el seguimiento a detalle de uno de los proyectos
presentados así como la iconografía necesaria para administración del mismo.
161
RESULTADOS
Figura 49. Ejemplo de la representación de un proyecto (Dentegra Seguros Dentales, 2010)
V.
Evaluación de desempeño (RR)
El siguiente reporte muestra el desempeño por ingeniero de soporte, desarrollador
(HC) y proveedor (Intercase).
El conocer la cantidad de incidencias atendidas por ingeniero nos da dos ventajas,
como primera opción conocemos al recurso humano que tiene un mayor conocimiento
de la infraestructura de Dentegra y por otro lado podemos aprovechar de una mejor
manera sus habilidades y experiencias, además de esto, esta métrica nos da
elementos para la evaluación de los recursos, poder otorgar una buena
retroalimentación o de acuerdo a las nuevos conceptos poder otorgar un “coaching”
adecuado a cada integrante del departamento.
Otra medida que nos arroja este reporte es que el recurso que más cierra incidencias
también deberá ser el que más soluciones reporta y por lo tanto el que más aporte a la
base de datos de conocimientos. Es importante hacer una auditoria a las incidencias
cerradas de este recurso para validar que la calidad de la documentación que realice
sea la adecuada, de ser así, podemos confirmar que estamos aprovechando las
habilidades y experiencia de un recurso a favor de todo un equipo de trabajo.
162
RESULTADOS
A continuación se presenta el modelo del reporte RR.
Figura 50. Reporte “Resolution Rate” (Dentegra Seguros Dentales, 2008)
163
CONCLUSIONES
CONCLUSIONES
Los marcos de referencia como su nombre lo dice nos sirven para obtener
generalidades al momento de implementar una metodología, sin embargo no hay que
olvidar que se requieren los conocimientos específicos de cada uno de los procesos
enfocados al negocio para ir ajustando estos marcos de referencia a un caso en
particular.
Durante la primera parte de este trabajo se describieron los distintos protocolos que
nos ayudaron a generar la propuesta aquí mencionada para obtener control en el
departamento de TI; el nivel de acción que tiene cada uno de ellos con respecto a la
organización y por supuesto los beneficios que se pueden obtener de estos, por otro
lado estos marcos no hacen referencia a aquellos factores que pueden poner en riesgo
el éxito de este tipo de implementaciones y que consideramos importantes mencionar
para el dimensionamiento de la propuesta en una organización mexicana y de
características específicas como lo es Dentegra.
Estos factores están asociados básicamente con el contexto financiero y geográfico de
Dentegra, es decir, la mayoría de los casos de estudio o de éxito para la
implementación de las mejores prácticas en el departamento de TI están referenciados
a organizaciones internacionales multinacionales y muy pocas relacionadas con
pequeñas organizaciones específicamente hablando de México.
Es por eso que consideramos de manera importante mencionar estos factores que
impactaron de manera directa la forma en cómo se diseñó la propuesta y puesta en
marcha de la misma. Estos son:
El apego a una metodología dentro del departamento de TI: Una de las limitantes más
importantes dentro del equipo de trabajo de TI es apegarse una estructura de trabajo o
a una disciplina, es decir, la mayoría de la oferta laboral que existe para recursos de TI
no tienen un sustento académico o una capacitación orientada a este tipo de
esquemas; es el caso de Dentegra donde todos los colaboradores de TI desconocen
las razones, esquemas y por supuesto beneficios de este tipo de marcos de trabajo y
un cambio siempre es difícil de implementar sobre todo en los recursos humanos.
Limitantes presupuestales: Es un hecho que los recursos financieros siempre son
limitados en cualquier organización y no cabe la menor duda que el cambio hacia una
metodología dentro del departamento de TI podría garantizar la sustentabilidad del
negocio a largo plazo, sin embargo la inversión mediática para llevar a cabo este tipo
de proyectos es significativa y en una organización de reciente creación sin lugar a
duda es un cuestionamiento que puso en riesgo la viabilidad de este proyecto.
Resultados a largo plazo: Por si esto no fuera poco los resultados de la implementación
de un marco de trabajo generalmente no son inmediatos y aquellos que si los son
particularmente no tienen un impacto mediático con los objetivos del negocio, en otras
palabras, el esfuerzo es importante en todos los sentidos, una buena planificación y un
cambio de paradigma que deberán sustentar los directivos y ejecutivos para delegar
estas responsabilidades; una manera distinta de enfocar los esfuerzos (actividades,
164
CONCLUSIONES
procesos y funciones) con la firme intención de que estén orientadas a objetivos en
común y por último el compromiso de todos los involucrados (proveedores, clientes,
personas encargadas de la atención, etc.) nos dio un panorama poco alentador de ver
resultados cuantificables en un corto plazo y esto significó un riesgo importante sobre
todo si las personas encargadas de la toma de decisiones no contaban con una
tolerancia importante y evaluaban de manera objetiva los avances graduales de la
implementación.
En otras palabras el primer reto para la implementación fue el cambio de paradigma
dentro de la dirección de Dentegra y la gerencia del departamento de TI, donde
predominaba un efecto reactivo a los problemas, una manera tradicional de apoyo o
soporte a la operación por parte del departamento de TI y un bajo control de las
actividades, esto a su vez generó acciones que deberán seguir los directivos y la
gerencia para coincidir con los objetivos del marco de referencia, entre esas están:




Alinear los objetivos del departamento al negocio
Evaluar tareas en el departamento a través de proyectos de TI
Enfocarse a una estrategia de servicios tecnológicos orientados al servicio y la
calidad
Evaluar y controlar los actuales procesos para la obtención de métricas
Por otro lado la incorporación de una nueva metodología dentro de una organización a
cualquier escala es sin lugar a duda un reto que involucra a todos los niveles de la
organización y que está expuesto a múltiples factores para lograr el éxito. La disciplina,
el compromiso y el firme apego a la metodología fueron esenciales para que este
proyecto concluyera de manera satisfactoria, sin embargo los recursos humanos,
técnicos y el tiempo de implementación superó la expectativa planteada en un
principio.
El resultado lo podemos catalogar como positivo bajo prácticamente cualquier punto de
vista, pero no podemos dejar a un lado todos aquellos factores que por un momento
representaron una amenaza directa a la finalización del proyecto y más aún dieron pie
a cambios importantes en la estructura de la organización.
Llevar a cabo un cambio de paradigma dentro de Dentegra o en su departamento de TI
por supuesto no fue cosa fácil más aún si consideramos que es una organización de
reciente creación en donde el sector estratégico y táctico están más enfocado en el
punto de retorno de la inversión que en una estrategia de servicios; el camino para
llegar a este objetivo se vio envuelto de múltiples matices que por más de una ocasión
llevaron al borde de la suspensión al proyecto y que gracias a los objetivos bien
definidos de la estrategia a implementar y a los resultados cuantificables a obtener
dieron pie a que el proyecto siguiera hasta su finalización.
La reducción de costos es uno de estos objetivos, y para Dentegra tuvo matices grises,
es decir, este beneficio no fue uno de los más importantes o más significativos que dio
como resultado la implementación de las mejores prácticas, ya que se incrementó la
plantilla de colaboradores en el departamento de TI, se requirieron mayores esfuerzos
para poder controlar y administrar el departamento, fue necesaria una capacitación
intensa para todos los usuarios, se realizó una inversión importante en el software para
165
CONCLUSIONES
administrar las incidencias y por supuesto no existe un punto exacto en el retorno de la
inversión; esto puede resultar algo frustrante para las personas que toman las
decisiones más sin embargo como en todo proyecto de tecnología la reducción de los
costos está asociada con el largo plazo.
Una implementación de más de 1 año, el incremento en la plantilla de colaboradores
(de 2 a 5 recursos) y el alto costo en tiempo invertido para poder percibir los resultados
de esta implementación fueron las características más significativas dentro de los
primeros seis meses de operaciones con esta metodología.
Sin embargo, los procesos bien definidos, la estructura organizacional para ofrecer un
apoyo (soporte) de calidad a los usuarios finales, la metodología para transformar una
simple pregunta o un problema mayor a una estructura que se pueda administrar (dar
seguimiento) y el compromiso por parte del departamento de TI hacia toda las aéreas
de la organización considero son los pilares fundamentales que se crearon para que
Dentegra y su infraestructura tecnológica afronten el futuro a corto y mediano plazo
obteniendo resultados enfocados a los objetivos del negocio.
En la gráfica del número de incidencias (figura 39 capitulo 4) observamos como el uso
de la herramienta para el registro y administración de las incidencias va un constante
aumento y con esta tendencia podemos decir que la inversión realizada en esta
aplicación tendrá en pocos meses un retorno de la misma. Así dejara a Dentegra con
una sólida cultura organizacional además de una ventaja competitiva importante ante
su principal competidor que se verá reflejado en una disminución de costos a largo
plazo.
Un punto que se vio altamente reforzado durante la implementación y que dio
resultados de manera muy rápida fue la implementación del esquema de servicios o
dicho de otra manera la manera de conceptualizar el trabajo a través de proporcionar
atención (servicios) a los usuarios. El catálogo de servicios se tuvo que actualizar de
manera constante conforme se iba avanzando en el proyecto, esto no necesariamente
refleja errores en la etapa de diseño (Service Desing) básicamente representa la
oportunidad de mejorar los servicios aun cuando estos no hayan sido implementados
aun y que por supuesto enriquecen el alcance del proyecto.
La gestión de cambios sin lugar a dudas también es un potenciador de las mejoras a
los servicios, durante el último mes se observa la inclusión de una solicitud de cambio
(gestión de problemas) y su solución, con esto podemos indicar que el atacar de
manera frontal las causas que originan una incidencia constante repercute de manera
directa en las incidencias reportadas, a su vez en los tiempos de que se asignan para
su solución, minimiza los tiempos que requieren los usuarios para realizar una
determinada acción y por supuesto en una mejor atención al cliente.
En concreto podemos decir que a diferencia de los costos, el nuevo paradigma en
Dentegra ha traído mejoras significativas tanto en forma como en fondo; y que de
manera natural traen consigo otros beneficios igualmente valiosos para organización
como: la cultura organizacional de Dentegra, el apego a los objetivos del negocio, etc.
166
CONCLUSIONES
Una mejora en la productividad de los colaboradores de Dentegra es un punto
importante que difícilmente se puede medir pero que sin embargo se pueden observar
entre los resultados al analizar la información arrojada con la metodología. Es decir, el
tiempo dedicado para el registro, seguimiento y aceptación de los resultados de una
incidencia indican que los colaboradores de todos los departamentos de Dentegra han
sufrido modificaciones en sus tiempos laborales, no quiere decir que tenga más trabajo
(porque no se han incrementado sus labores) lo que podemos interpretar es que ese
tiempo ahora tiene un fin común para la organización y es el de reportar, que va desde
interpretar una falla en un servicio hasta verificar que funcione correctamente; generar
una lista de casos (usos) para poder comprobar la funcionalidad del servicio, llegar a
acuerdos de cómo se debe realizar una actividad (para lograr los objetivos en tiempo y
forma de la organización) y por supuesto el sentirte parte de esa cadena que agrega
valor a los productos ofrecidos por Dentegra.
Los nuevos paradigmas también traen consigo una serie de responsabilidades
asociadas a las actividades u objetivos para los cuales se plantearon, estas actividades
presentan para Dentegra una manera diferente de plantear el trabajo en el
departamento de TI.
Con la incorporación de la metodología se presenta a la dirección una manera diferente
de resolver los distintos problemas que tiene que atacar el departamento, en otras
palabras el trabajo se distribuye de una manera formal y ordenada; el administrador del
departamento tiene claros cuales son los objetivos y que es lo que se espera de cada
proyecto asignado, cuales son los recursos con que cuenta y a quien hay que
entregarle los resultados.
De esta manera se evitan problemas en la comunicación, todas las personas
involucradas saben cuánto costara el proyecto y cuanto durara, cada proyecto se
presenta en forma de diagrama (figura 49 capitulo 4) y con elementos icónicos que
indican el progreso del mismo y lo más importante se tiene un control total (desde la
dirección hasta la parte operativa) de cada uno de los proyectos y sus estatus. Con
esto podemos afirmar que de una manera simple Dentera puede saber la cantidad de
proyectos en el departamento (semanal, mensual, anual, etc.), el estatus de los
mismos, los tiempos de solución, la cantidad de recursos invertidos y en una sola
palabra podemos decir que Dentegra cuenta con una manera para administrar el
trabajo y los resultados de su departamento de TI, que si lo asociamos con las
regulaciones a las que está expuesta Dentegra, esta una manera sana de cumplir con
todas sus obligaciones frente a la autoridad.
Hablando de las habilidades técnicas con que cuentan los recursos en el departamento
podemos ver claramente en el reporte de evaluación de desempeño (figura 50 capitulo
4) la diferencia significativa de conocimientos que tienen los colaboradores dentro del
departamento de TI, esto no es representa un problema si no por el contrario
encontramos una amplia área de oportunidad dentro de departamento.
La pobre homologación de conocimientos dentro de un equipo de trabajo sin lugar a
duda da pie a tomar acciones para contrarrestar esta uniformidad, no podemos hablar
de una mala selección de recursos ya que esto depende de cada organización y de la
manera en como pretenden administrar sus recursos humanos, de lo que si podemos
167
CONCLUSIONES
hablar de todas aquellas acciones que durante la implementación de la metodología se
fueron considerando para tratar de disminuir esta brecha. Evidentemente el nivel de
conocimientos entre los recursos depende directamente de un sin número de variables
como la edad, la curva de aprendizaje, la experiencia profesional, el ambiente de
desarrollo o sector en el que se han desenvuelto, mas sin embargo es claro que se
tiene que distribuir de una manera uniforme el conocimiento técnico y del negocio y
hacerlo a través de la tecnología considero que es una manera ordenada y a la
disposición de todos los colaboradores no solo del área si no de Dentegra.
Durante la implementación se crearon herramientas como la CMDB que nos permiten
obtener este tipo de información de una manera rápida y en poco tiempo, sin
necesidad de depender de un recurso humano en específico y con todos los
inconvenientes que esto acarrea.
Si bien las mejores prácticas no son una receta para conseguir un objetivo, ni tampoco
nos garantizan este, las mejores prácticas como cualquier actividad humana nos dan
un panorama de cómo realizar nuestras actividades, sin embargo, la planeación, la
organización, la dirección y el control siguen siendo pilares fundamentales para el éxito
de casi cualquier actividad humana, pero en el caso de las tecnologías de información
la formación académica puede ser un factor importante y determinante para el
desarrollo de los futuros profesionistas; es decir, existe un número importante de
recursos humanos sin conocimientos sólidos en una metodología o forma de realizar
sus actividades profesionales y esto se vio reflejado en el momento de la selección y
capacitación de los candidatos que se sumaron al departamento de TI en Dentegra.
Dentro de las reflexiones que podemos mencionar de esta implementación están:
Costos: Definitivamente la implantación ordenada de una metodología dentro del
departamento de TI requiere una alta inversión, en mi experiencia mucha más
inversión que la imaginada al principio del proyecto. El incremento de 2 a 10 recursos
humanos dentro del departamento de TI considerando las nuevas responsabilidades
(con la incorporación de la metodología) así como el incremento en el volumen de la
operación, las múltiples acciones tomadas para la capacitación de los usuarios, la
incorporación de personal experto en la implementación de mejores prácticas y las
adecuaciones a la infraestructura tecnológica y a los procesos, son sin duda una
inversión altamente significativa que muy probablemente no pueda ser cubierta por
organizaciones con limitantes de recursos.
Beneficios: Sin lugar a duda estos son muy significativos empezando en el
departamento de TI y diversificándose en otras áreas, habiendo un antes y un después
de la implementación de la metodología; con esta nueva manera de hacer las cosas en
el departamento de TI cada uno: usuarios, proveedores (colaboradores del
departamento de TI) y alta gerencia de Dentegra saben cuál es el objetivo del
departamento y por lo tanto son parte importante al momento de agregar valor a los
productos ofrecidos por Dentegra.
Formación académica y/o profesional: Los recursos técnicos/humanos que laboramos
en un departamento de TI (en este caso Dentegra), no solo no cuentan con el
conocimiento de las mejores prácticas en el área de TI, si no de alguna metodología
168
CONCLUSIONES
formal que les indique como hacer sus actividades profesionales por lo que esto puede
ser una desventaja importante en el rubro de la competitividad al momento de
compararnos con organizaciones de otras latitudes.
Procesos no presentados en este trabajo: Por causas de confidencialidad existen
múltiples procesos, planes, diseños, estrategias, etc. que no pueden presentarse en
este trabajo. Sin embargo no quiere decir que fueron considerados, diseñados e
incluso implementados; por mencionar algunas actividades de acuerdo a su dominio
son:

Planear y Organizar (PO)
o Determinar la Dirección Tecnológica
o Comunicar las Aspiraciones y la Dirección de la Gerencia

Adquirir e Implementar (AI)
o Identificar soluciones automatizadas
o Facilitar la operación y el uso
o Plan de capacitación al personal y material de apoyo

Entrega y Soporte (DS)
o Garantizar la seguridad de los sistemas
o Administrar los datos
Trabajos futuros: Como se planteó desde el capítulo 3, este trabajo de investigación es
el inicio de una serie de decisiones a tomar por parte de la directiva de Dentegra, sin
lugar a duda hay áreas de oportunidad que quedaron al descubierto y que se podrían
fortalecer si se decide continuar por este camino administrativo. El incremento de la
infraestructura (base de datos) para generar una base de conocimientos que pueda
fortalecer la autoayuda, la posibilidad de ofrecer los servicios de Dentegra a través de
su página de internet, el incremento de la presencia de Dentegra en el mercado a
través de tecnología móvil (apps) y la posibilidad de alinear los objetivos empresariales
con su corporativo en E.U. (implementación de Cobit a nivel corporativo) hacen de
estos puntos el inicio de una lista de posibles temas que podrían ser resueltos a través
de este tipo de metodologías. Sin embargo hay que tomar en cuenta que mucho
depende de las circunstancia, crecimiento, comportamiento del mercado y
disposiciones oficiales que afectan al sector donde se desenvuelve Dentegra.
Equipo de trabajo: Todo este esfuerzo es sin lugar a dudas el resultado del trabajo de
un gran equipo con quien tuve el placer de colaborar; todos ellos aportaron de una
manera u otra tanto su conocimiento, ideas; así como su empeño y compromiso para
poder obtener los resultados aquí presentados. Sin lugar a dudas mucho del éxito
obtenido y recopilado en este trabajo tiene sus bases en todos y cada uno de ellos. El
equipo de trabajo estuvo conformado por:
La Dirección General y del Área
Las Gerencia de TI y Gerencias Asociadas
Departamento de TI:
 Coordinadores
 Ingenieros
169
CONCLUSIONES
Proveedores
 Desarrollo (software)
 Hardware
 Comunicaciones
A quien por supuesto mis más sincero agradecimiento y reconocimiento.
La metodología y la realidad: Uno de los retos más importantes durante la
implementación de esta metodología es la decisión de seguir o no al pie de la letra el
marco de referencia que proponen las mejores prácticas. La realidad es sin lugar a
dudas el resultado de las circunstancias específicas en un momento determinado y la
metodología por otro lado son las acciones a realizar para obtener un resultado
esperado, que sin embargo deben de converger en un fin común, mejorar la
organización y generalmente en un tiempo determinado. Esto fue un reto al que se
enfrentó el equipo de trabajo durante prácticamente toda la implementación de la
metodología y sobre todo al momento de finalizar cada una de las etapas sugeridas. Es
un hecho que se tuvieron que realizar ciertos cambios en las propuestas metodológicas
adecuándolas a la infraestructura, formas de trabajo, ambiente organizacional y
mayormente a los objetivos buscados por la directiva y la gerencia.
170
BIBLIOGRAFÍA
BIBLIOGRAFÍA
Balañá, M., & Minguella, M. (1984). La transferencia de tecnología in VV.AA.
Enciclopedia de Dirección y Administración de la Empresa, Madrid.
Barry, C., & Lang, M. (2009). Information System Development, challenges in practice,
theory and education. Estados Unidos: Springer.
Benavides, C. (1998). Tecnología, innovación y empresa. Madrid: Ediciones Pirámide.
Bilderbeek, R., & Den Hertog, P. (1998). S3: Services in Innovation: Knowledge
Intensive Business Servicios (KIBS) as co-producers de innovation. Oslo: STEP
Group.
Cartlidge, A., & Hanna, A. (2007). An introductory overview of ITIL V3. Reino Unido:
itSMF & Best Management Practice Partnership.
Chrissis, M. (2003). CMMI: Guidelines for process integration and product
improvement. Estados Unidos: Addison-Wesley.
Christopher, M., & Payne, A. (1994). Marketing Relacional. Integrando la Calidad, el
Servicio al Cliente y el Marketing. Madrid: Ediciones Díaz de Santos.
CNSF, Comisión Nacional de Seguros y Fianzas. (2010). Actualidad en Seguros y
Fianzas. CNSF.
Deming, W. (1989). Calidad, productividad y competitividad: la salida de la crisis.
Madrid: Ediciones Díaz de Santos.
Dentegra Seguros Dentales. (2006). Anteproyecto para la conformación de una ISES.
México, DF.
Dentegra Seguros Dentales. (Septiembre de 2007). Dentegra Seguros Dentales.
Recuperado en Septiembre de 2007, de Dentegra Seguros Dentales:
http://www.dentegra.com.mx
Dentegra Seguros Dentales. (2008). Carpeta de procesos para el área de TI. México
DF.
Dentegra Seguros Dentales. (2010). Formatos y machotes corporativos. México DF.
Druker, P. (1974). Management, task, responsabilities, practices. Reino Unido: Brithis
Library.
Elaboracion propia. (2007). Propuesta metodológica para la implementación de los
principales servicios de tecnologías de información en una aseguradora dental.
México DF.
171
BIBLIOGRAFÍA
England, R. (2009). Owning ITIL: A Skeptical Guide for Decision-Makers. Reino Unido:
Two Hills.
Fernández Sánchez, E. (1996). Innovación, Tecnología y Alianzas Estratégicas.
Madrid: Civitas.
Grönroos, C. (2000). Service Management and Marketing. Reino Unido: Lexington
Books.
Guldentops, E. (2003). Board Briefing on IT Governance. IT Governance.
Hauknes, J. (1998). Services in innovation – Innovation in services. SI4S Final report.
Oslo: STEP Group.
Hernández Sánchez, E., & Fernández Casariego, Z. (1988). Manual de Dirección
Estratégica de la Tecnología. La producción como ventaja competitiva.
Barcelona: Ariel.
HMSO, Her Majesty's Stationery Office. (Mayo de 2007). HMSO, Her Majesty's
Stationery Office. Recuperado en Abril de 2010, de HMSO, Her Majesty's
Stationery Office: http://www.hmso.gov.uk
Hyder, E. (2006). The ESCM-SP V2.01: The ESourcing Capability Model for Service
Providers (eSCM-SP) V2.01. Reino Unido: Carnegie Mellon University,
Information Technology Services Qualification Center.
IBM, International Business Machines. (2000). IBM and the IT Infrastructure Library,
Reference Manual. Estados Unidos: IBM.
ISACA. (Febrero de 2010). ISACA. Recuperado en Febrero de 2010, de ISACA:
https://www.isaca.org/Pages/default.aspx
ISACA, Education. (Mayo de 2009). ISACA. Recuperado en Febrero de 2010, de
ISACA: http://www.isaca.org/Education/COBIT-Education/
ISACA, Information Systems Audit and Control Association. (Mayo de 2000). ISACA.
Recuperado en Febrero de 2010, de ISACA: http://www.isaca.org/KnowledgeCenter/COBIT/Pages/Overview.aspx
ISACA, Knowledge Center. (Marzo de 2009). ISACA. Recuperado en Agosto de 2010,
de
ISACA:
http://www.isaca.org/Knowledge-Center/cobit/cobitfocus/Pages/Implementacion-de-COBIT-4-0-en-Scotiabank-Costa-Rica.aspx
itSMF, IT Service Management Forum. (2007). Fundamentos de gestión de servicios
TI: basado en ITIL. Reino Unido: Van Haren.
itSMF, IT Service Management Forum. (Mayo de 2007). itSMFI. Recuperado en Mayo
de 2008, de itSMFI: http://www.itsmfi-forum.org
172
BIBLIOGRAFÍA
Klosterboer, L. (2007). Implementing ITIL configuration manager. Estados Unidos: IBM
Press.
Leonard, D. (1998). Wellsprings de Knowledge. Boston: Harvard Business School
Press.
Morency, J. (2005). Best practice, practice, practice. Estados Unidos: Network World.
Nonaka, I., & Takeuchi, H. (1995). The Knowledge Creating Company. New York:
Oxford University Press.
Norman, R. (2002). Service Management: Strategy and Leadership in Service
Businesses. Chichester: John Wiley & Sons, Ltd.
OECD, Organization for Economic Co-operation and Development. (2006). Innovation
and Knowledge-Intensive Service Activities. Estados Unidos: OECD Publishing.
OGC, Office of Government Commerce. (2003). Best Practice for Application
Management. Reino Unido: The Stationery Office .
OGC, Office of Government Commerce. (2006). ITIL Glossary v01, 1 May 2006:
Acronyms. Reino Unido: Office of Government Commerce.
OGC, Office of Government Commerce. (2006). Service Support. Reino Unido: Office
of Government Commerce.
OGC, Office of Government Commerce. (Mayo de 2007). Office of Government
Commerce. Recuperado en Abril de 2011, de Office of Government Commerce:
http://itilv3.osiatis.es/funciones_procesos_roles.php
OGC, Office of Government Commerce. (2007). The Introduction to the ITIL Service
Lifecycle Book. Reino Unido: TSO, The Stationery Office.
OGC, Office of Government Commerce. (2007). The key to managing IT Services v2.
Reino Unido: The Stationery Office.
Osiatis. (Noviembre de 2007). Osiatis. Recuperado en Julio de 2008, de Osiatis:
http://itilv3.osiatis.es/contacto.php
Pierre Eiglier, E. L. (1989). Servucción: el marketing de servicios. Paris: MvGrawHill.
PMI, Project Management Institute. (Enero de 2000). Project Management Institute.
Recuperado en Septiembre de 2010, de What is PMI?: http://www.pmi.org
PMI, Project Management Institute. (Enero de 2005). Project Management Institute.
Recuperado en Abril de 2010, de Project Management Institute:
http://www.pmi.org
173
BIBLIOGRAFÍA
Pultorak, D. (2008). Microsoft Operations Framework 4.0. Estados Unidos: Van Haren
Publishing.
Regis, E. (Febrero de 2008). Johnny Jiggles the Planet. The New York Times.
Robinson, P., & Faris, C. (1967). Industrial Buying and Creative Marketing. Estados
Unidos: Allyn & Bacon.
Robinson, R. (1988). The international transfer of technology. Cambridge: Ballinger
Publishing Empresa.
Rozemeijer, E. (2007). Frameworks for IT Management. Estados Unidos: Van Haren
Publishing.
Sales Force. (Enero de 2008). Sales Force. Recuperado en Abril de 2010, de Sales
Force: http://www.salesforce.com/mx/
Seguros Centauro, Salud Especializada SA de CV. (Juliio de 2010). Seguros Centauro.
Recuperado
en
Julio
de
2010,
de
Seguros
Centauro:
http://www.centauro.com.mx
Simone, E., & Heschl, J. (2007). COBIT Mapping: Mapping of ITIL with COBIT 4.0.
Estados Unidos: IT Gobernance Institute.
Simone, E., & Heschl, J. (2007). COBIT Mapping: Mapping of ITIL with COBIT 4.0.
Reino Unido: IT Gobernance Institute.
Somorrostro López, P. (2002). Technical Service Demand in Galician Industry. Reino
Unido: University of Brighton.
Somorrostro Lopéz, P. (2005). XI Encuentro empresarial Gijón. Encuentros
empresariales Gijón. Gijon.
Torres, J. (2011). Empresas en la nube, ventajas y retos del cloud computing. España:
Libros de cabecera SL.
Van Bon Jan, D. (2008). Fundamentos de la gestión de servicios de TI basados en ITIL
v3. Reino Unido: ItSMF International.
Van Bon Jan, D. J. (2009). ITIL v3 – A pocket guide. Reino Unido: Van Haren
Publishing.
Van Bon Jan, P. S. (2008). ISO/IEC 20000, una introducción. Reino Unido: Van Haren
Publishing.
Van Looy, B. V. (1998). Service Management. An Integrated Approach. Londres:
Pitman Publishing.
174
BIBLIOGRAFÍA
Vázquez Casielles, R. S. (1998). Estrategias de marketing para mercados industriales:
producto y distribución. Madrid: Civitas.
Webster, F. (1995). Industrial Marketing Strategy. Reino Unido: Chichester, John Wiley
& Sons.
West, M. (2004). Real process improvement using the CMMI. Estados Unidos: CRC
Press.
Zeithaml, V. (1981). How consumer evaluation processes differ between goods and
services. Estados Unidos: American Marketing Association.
175
ANEXOS
Anexos
Anexo A. Formato de control para los procesos de TI (navegación en
COBIT)
176
ANEXOS
Anexo B. Proceso para la creación de casos en Sales Force©
177
ANEXOS
178
ANEXOS
179
ANEXOS
180