Embed Size (px)
Citation preview
UNIVERSIDAD DE CHILE
FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS
DEPARTAMENTO DE INGENIERIA INDUSTRIAL
REDISEÑO DEL MODELO DE NEGOCIOS DEL DATACENTER DE TELEFÓNICA EMPRESAS
EN FUNCIÓN DE PRÁCTICAS ITIL
PROYECTO DE GRADO PARA OPTAR AL GRADO DE MAGISTER EN INGENIERIA DE NEGOCIOS CON TECNOLOGIAS DE LA INFORMACION
MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL INDUSTRIAL
PABLO ANDRÉS RODRÍGUEZ RODRÍGUEZ
PROFESOR GUÍA: Sr. Óscar Barros Vera
MIEMBROS DE LA COMISIÓN EVALUADORA
Sr. Antonio Holgado San Martín Sr. Sigifredo Laengle Scarlazetta
Sr. César Cantuarias Chazarro
SANTIAGO DE CHILE JULIO 2007
AGRADECIMIENTOS
Agradezco a mi madre, Edith, por creer y confiar a ojos cerrados siempre en
mí, por su cariño y apoyo, por enseñarme que la honestidad y sinceridad son los
valores fundamentales en la vida, por internalizar en mí la frase célebre “los
grandes hombres no se miden por las veces que se caen, sino por cuántas se
levantan”, y lo más importante, por ser todo y más de lo que su hijo ha necesitado,
haciendo que me enorgullezca de tenerla a mi lado, agradeciéndole a Dios por
esto.
A mi abuela, María, “mi mamagüela”, mi segunda madre, quien me ha
apoyado y querido siempre, acompañándome en todo lo que he necesitado.
A mi abuelo, Oscar, quien me acompañó en todo lo que pudo y ahora lo
sigue haciendo desde el cielo, enseñándome que si uno es honesto y verdadero
en la vida, esto siempre es agradecido.
A mi tía Belia, por ser una excelente madrina, y quererme de la forma que lo
ha hecho, haciéndome sentir como uno de sus hijos. Lo mismo para Octavio, mi
padrino, quien me ha ayudado en todo lo que le he pedido. A mis primos Juan
Pablo y Andrés, por su amistad y cariño.
A mis tíos Julio y Claudio, por sus consejos, cariño y el apoyo recibido. En
fin, a toda mi familia por todo el afecto que han tenido conmigo.
A mis mejores amigos Marco, Perla, Werner, Sofía y Cristóbal, por su
apoyo, consejos y compañía durante los años de Universidad, que siempre
valoraré.
A Natalia, por su amistad y apoyo en los momentos de estudio.
1
A Claudia y Frank por ser mis amigos y compañeros.
A mis compañeros y amigos de Magister Jonathan, Jaime y Gerardo, por
enseñarme que el trabajo en equipo puede ser un factor determinante en el logro
de los objetivos.
A la gente del Departamento de Industrias, mis profesores Oscar Barros,
Antonio Holgado y Eduardo Olguín, gracias por su buena disposición y apoyo
durante todo este proceso. En especial agradezco a Ana María, secretaria del
magíster, por su apoyo desde el comienzo.
A Telefónica Empresas, por darme la posibilidad de desarrollar este
proyecto y compartir con las valiosas personas que la componen, en especial a
César Cantuarias, Gerente eSolutions: Marta Rojo, Subgerenta Datacenter;
Leoncio Cornejo, Jefe de Servicios TIC; y a toda la gente del Datacenter, por la
disponibilidad y amistad que han tenido conmigo.
Al Instituto Nacional, por darme la “fortuna de poder ser parte del primer
foco de luz de la nación”.
A Stephanie, por su amor, compañía, y alegría.
2
TABLA DE CONTENIDOS
RESUMEN EJECUTIVO ................................................................................................................................ 4
CAPÍTULO I: PLANTEAMIENTO Y MOTIVACIONES INICIALES DEL PROYECTO ............ 8
I.1 LA EMPRESA ......................................................................................................................................... 8 I.2 TENDENCIA ACTUAL EN TI ................................................................................................................. 11 I.3 MODELO DE NEGOCIO TELEFÓNICA EMPRESAS .................................................................................. 14
I.3.1 Descripción de la Oportunidad ................................................................................................. 14 I.3.2 El Servicio Telefónica Empresas .............................................................................................. 17 I.3.3 Mercado Telefónica Empresas.................................................................................................. 22 I.3.4 Precio ........................................................................................................................................ 24 I.3.5 Tecnología ................................................................................................................................ 25
I.4 ORIGEN DE LA INICIATIVA DE REDISEÑO............................................................................................. 26
CAPÍTULO II: MARCO TEÓRICO-CONCEPTUAL......................................................................... 29
CAPÍTULO III: METODOLOGÍA DEL REDISEÑO........................................................................... 46
III.1 METODOLOGÍA PARA EL REDISEÑO DEL PROCESO DE NEGOCIO ..................................................... 46
CAPÍTULO IV: MODELO DE NEGOCIO PROPUESTO................................................................... 48
IV.1 DESCRIPCIÓN DE LA OPORTUNIDAD ............................................................................................... 48 IV.2 DEFINICIÓN DEL PROYECTO ........................................................................................................... 49
IV.2.1 Objetivos (Negocio) ............................................................................................................. 49 IV.2.2 Producto del Rediseño (Entrega).......................................................................................... 50 IV.2.3 Alcance del Rediseño (Soporte) ........................................................................................... 51 IV.2.4 Papel de las Tecnologías de Información............................................................................. 51
CAPÍTULO V: MODELAMIENTO IDEF0 DEL REDISEÑO PROPUESTO.................................. 52
V.1 PRINCIPALES LOGROS A ALCANZAR ............................................................................................... 53 V.2 DIAGRAMAS DE PROCESOS DISEÑADOS/REDISEÑADOS .................................................................. 53
CAPÍTULO VI: DEFINICIÓN DE APOYO COMPUTACIONAL ..................................................... 87
VI.1 LÓGICA DE INTERFAZ USUARIO...................................................................................................... 87 VI.2 LÓGICAS DEL SISTEMA ................................................................................................................... 87
VI.2.1 Lógica de Verificación Usuario ........................................................................................... 87 VI.2.2 Lógica de Clasificación, Priorización, Optimización, y Asignación de Requerimientos ..... 88
CAPÍTULO VII: DEFINICIÓN DE CASOS DE USO ....................................................................... 97
CAPÍTULO VIII: DIAGRAMAS DE SECUENCIA DE SISTEMA................................................... 99
VIII.1 DSS ESCENARIOS CASO DE USO INGRESO Y PROCESAMIENTO DE REQUERIMIENTOS................ 99 VIII.1.1 DSS Escenario Ingreso y Procesamiento de Información de Proyectos............................... 99 VIII.1.2 DSS Escenario Ingreso y Procesamiento de Requerimientos............................................. 100 VIII.1.3 DSS Escenario Ingreso y Procesamiento Información CMDB .......................................... 101
VIII.2 DSS ESCENARIOS CASO DE USO VERIFICAR INFORMACIÓN .................................................... 102 VIII.2.1 DSS Escenario Verificar Información Proyectos ............................................................... 102 VIII.2.2 DSS Escenario Verificar Información Requerimiento ....................................................... 103 VIII.2.3 DSS Escenario Verificar Información CMDB ................................................................... 104
VIII.3 DSS ESCENARIOS CASO DE USO ACTUALIZAR INFORMACIÓN................................................. 105 VIII.3.1 DSS Escenario Actualizar Información de Proyectos ........................................................ 105 VIII.3.2 DSS Escenario Actualizar Información de Requerimiento ................................................ 106 VIII.3.3 DSS Escenario Actualizar Información de CMDB ............................................................ 107
CAPÍTULO IX: DIAGRAMAS DE SECUENCIA ............................................................................... 108
IX.1 DIAGRAMA DE SECUENCIA PARA CASO DE USO “INGRESO Y PROCESAMIENTO DE REQUERIMIENTOS
108 IX.2 DIAGRAMA DE SECUENCIA PARA CASO DE USO “INGRESO Y PROCESAMIENTO INFORMACIÓN”.... 109
3
CAPÍTULO X: DIAGRAMAS DE CLASES....................................................................................... 110
X.1 DIAGRAMA DE CLASES PARA INGRESO Y PROCESAMIENTO REQUERIMIENTO .............................. 110 X.2 DIAGRAMA DE CLASES INGRESO Y PROCESAMIENTO REQUERIMIENTO........................................ 111
CAPÍTULO XI: DISEÑO DETALLADO DE LA APLICACIÓN...................................................... 112
XI.1 ARQUITECTURA TECNOLÓGICA .................................................................................................... 112 XI.2 PÁGINAS DE LA APLICACIÓN ........................................................................................................ 113
CAPÍTULO XII: IMPLEMENTACIÓN ORGANIZACIONAL DE LOS PROCESOS DE CAMBIO Y LAS ESTRUCTURAS DE APOYO ...................................................................................... 134
XII.1 GESTIÓN DEL CAMBIO .................................................................................................................. 134 XII.1.1 Descripción de la situación actual ...................................................................................... 135 XII.1.2 Análisis de los factores....................................................................................................... 135 XII.1.3 Visión ................................................................................................................................. 137 XII.1.4 Interpretación de la situación ............................................................................................. 137 XII.1.5 Objetivos generales ............................................................................................................ 138 XII.1.6 Objetivos específicos.......................................................................................................... 138 XII.1.7 Factores críticos ................................................................................................................. 139 XII.1.8 Poder .................................................................................................................................. 140 XII.1.9 Recursos ............................................................................................................................. 141 XII.1.10 Plan de acción .................................................................................................................... 142
XII.2 INDICADORES ............................................................................................................................... 143 XII.3 RESULTADOS INICIALES ............................................................................................................... 143 XII.4 RESULTADOS FINALES.................................................................................................................. 145 XII.5 EJECUCIÓN DE LAS PRUEBAS ........................................................................................................ 148 XII.6 EVALUACIÓN APLICACIÓN ........................................................................................................... 148 XII.7 PLAN DE TRABAJO IMPLEMENTACIÓN DEFINITIVA....................................................................... 150
CAPÍTULO XIII: DESARROLLO DEL PROTOTIPO DE LA APLICACIÓN............................. 151
CAPÍTULO XIV: EVALUACIÓN ECONÓMICA DEL PROYECTO............................................ 157
XIV.1 COSTOS DEL SISTEMA .............................................................................................................. 157 XIV.2 INGRESOS DEL SISTEMA........................................................................................................... 158 XIV.3 FLUJO DE CAJA DEL PROYECTO ............................................................................................... 162
CAPÍTULO XV: GENERALIZACIÓN DE LA EXPERIENCIA EN EL DESARROLLO DE UN FRAMEWORK 163
XV.1 DESARROLLO DEL FRAMEWORK................................................................................................... 165 XV.2 APLICACIÓN DEL FRAMEWORK .................................................................................................... 167 XV.3 CONSTRUCCIÓN DEL FRAMEWORK ............................................................................................... 170 XV.4 APLICACIÓN DEL FRAMEWORK AL CASO DE “MANTENIMIENTO DE AVIONES” ............................ 172
CAPÍTULO XVI: CONCLUSIONES .................................................................................................. 174
CAPÍTULO XVII: BIBLIOGRAFÍA .................................................................................................... 176
CAPÍTULO XVIII: ANEXOS ................................................................................................................. 177
XVIII.1 CÓDIGOS PÁGINAS PROTOTIPO ................................................................................................ 177 XVIII.1.1 Código Página inicio.html ............................................................................................. 177 XVIII.1.2 Código Página reqprocesado.jsp.................................................................................... 178 XVIII.1.3 Código Página respuesta.jsp .......................................................................................... 179 XVIII.1.4 Código Página error.jsp ................................................................................................. 180
XVIII.2 CÓDIGOS SERVLET PROTOTIPO ................................................................................................ 180 XVIII.2.1 VerificaServlet............................................................................................................... 180 XVIII.2.2 ProcesaServlet ............................................................................................................... 183 XVIII.2.3 ClienteP ......................................................................................................................... 198
XVIII.3 REGLAS DE ESCALADO ............................................................................................................ 203 XVIII.3.1 Escalado Funcional vs. Jerárquica................................................................................. 206
4
RESUMEN EJECUTIVO
El negocio de los Datacenter consiste en la prestación de servicios de
tecnologías de información con altos niveles de seguridad y disponibilidad, que
son desarrollados según las necesidades de cada cliente. Para ofrecer esto, se
requiere contar con una infraestructura adecuada, donde los procesos que
interactúan con los recursos, pasen a ser el elemento vital del negocio.
Es por ello, que el aseguramiento del nivel de servicio acordado con los
clientes, y de los procesos que lo sustentan, pasa a ser una actividad crítica dentro
del negocio, y puede significar la obtención de una diferenciación en un mercado
con requerimientos de clientes cada vez más exigentes, en cuanto a efectividad
operacional, estandarización y certificación de procesos, personas y herramientas.
Por lo tanto, este proyecto se relaciona directamente con la competitividad
del Datacenter de Telefónica Empresas, permitiendo:
• Disminuir los tiempos de respuesta de requerimientos.
• Asegurar la calidad de los servicios y niveles de atención ofrecidos por la
empresa.
• Introducir el concepto de conocimiento centralizado de la organización, que
es la base para conocer las especificaciones de cada proyecto en curso.
• Tener un Modelo De Procesos diseñado de acuerdo a las mejores prácticas
de mercado para empresas de provisión de servicios de tecnologías de
información.
El proyecto de rediseño del modelo de negocios del Datacenter de
Telefónica Empresas en función de ITIL, consiste en una optimización de los
procesos actuales según las mejores prácticas de mercado, y la introducción de
nuevos conceptos relevantes en cuanto al soporte y entrega de servicios,
estandarizando cada uno de ellos.
5
El objetivo general del proyecto es la “Obtención de Procesos acordes a las
Mejores Prácticas de Mercado ITIL”, lo cual implica, tener como objetivos
específicos:
• Reducir los tiempos de resolución de requerimientos
• Mejorar la Gestión de Inventario y de la Información dentro de la
organización.
• Asegurar la calidad y seguridad de servicio, a través de los procesos que lo
soportan y del conocimiento que tiene la organización.
La metodología que se usará es la propuesta por el Magíster en Ingeniería
de Negocios con Tecnologías de Información (MBE). Esta se basa en el uso de los
patrones de negocios formulados por el Dr. O. Barros, que buscan eliminar
ineficiencias en los procesos actuales, mediante su modelamiento y la aplicación
de patrones basados en las mejores prácticas de gestión utilizando TI. Esta
metodología culmina con el desarrollo de una herramienta tecnológica que apoya
el proceso rediseñado.
Esta Metodología consiste en:
1. Definir un Marco Teórico Conceptual.
• Introducción a las Mejores Prácticas de Provisión de Servicios de
Tecnologías de Información (ITIL).
• Justificar la relevancia de la aplicación de esta metodología para el negocio.
• Explicar cómo las mejores prácticas se introducen en los Procesos de
Datacenter.
• Complementar este enfoque con el uso de tecnologías y modelamiento
adecuado de los procesos.
2. Análisis de la situación Actual.
3. Rediseño de procesos asociados.
6
• Establecer nuevas necesidades de los procesos.
• Modelar los nuevos procesos mediante el uso de patrones de diseño.
4. Diseño de la Aplicación Computacional basada en Orientación a Objetos.
• Desarrollo de casos de uso para el sistema.
• Desarrollo de escenarios de realización para los casos de uso.
• Desarrollo de diagramas de Clases.
• Desarrollo de un prototipo de la aplicación.
5. Gestión del Cambio asociada al rediseño.
• Estudio del impacto del nuevo proceso en la organización.
• Desarrollo de un plan de gestión de cambio que permita la introducción de
los nuevos procesos en forma adecuada.
6. Plan Piloto.
• Estados de satisfacción con el nuevo proceso.
• Prueba del nuevo proceso.
7. Evaluación Económica.
• Establecimiento de los costos del proyecto.
• Cuantificación de los beneficios del proyecto.
• Estado de resultados para el proyecto.
8. Generalización de la experiencia
• Desarrollo de un Framework de evaluación que permita extender y volver a
usar la estructura de software desarrollada a otros dominios de aplicación
similares a los de planes de salud.
Con esto, la Gerencia de Outsourcing y Datacenter de la Vicepresidencia de
Empresas de Telefónica Chile, pretende ventajas competitivas, que respondan a
una necesidad de mercado impulsada fuertemente por los clientes representativos
que tienen contratados servicios de datacenter, esto se traduce en tener procesos
7
de calidad certificada a nivel mundial, cuya forma de hacer las cosas demuestra
que se ha recogido la experiencia exitosa de otros en el manejo de las tecnologías
de información. Por lo tanto, del proyecto se pueden tener los siguientes
beneficios:
• Mejoras Operacionales experimentas por la reducción de los tiempos de
resolución de requerimientos, lo que se debe a diferentes factores, como
minimización del tiempo de asignación, clasificación, y priorización de los
requerimientos, aumento de la disponibilidad de la información. Y, tener
asociadas al modelo de negocio las mejores prácticas de mercado,
absorbiendo el conocimiento histórico de las TI.
• Ventajas Competitivas, generadas por menor tiempo de respuesta ante
requerimientos, y forma de manejar la información, que son actividades
críticas en servicios de alta disponibilidad.
• Una herramienta diseñada acorde a las necesidades del negocio, que
apoye los procesos del modelo de negocio.
• Personal capacitado en mejores prácticas ITIL y en el manejo de la
aplicación.
8
CAPÍTULO I: PLANTEAMIENTO Y MOTIVACIONES INICIALES DEL PROYECTO
Esta sección pretende dar a conocer el contexto en el que el proyecto se
lleva a cabo, a través de una descripción de Telefónica Empresas, su modelo de
negocio y las situaciones que han generado la necesidad de implementar
prácticas estandarizadas en gestión de la información.
I.1 La Empresa
Telefónica es una de las empresas de telecomunicaciones líder a nivel
mundial, presente en Europa, África y Latinoamérica. En junio de 2006, el número
de clientes de Telefónica era de 191,7 millones.
Telefónica es uno de los operadores integrados con mayor cuota de negocio
fuera de su mercado de origen y el operador de referencia en el mercado de habla
hispano-portuguesa. Por todo esto, se está convirtiendo en el líder de los
proveedores multiservicio y multidoméstico.
En España, el Grupo cuenta con más de 80 años de experiencia y a junio de
2006 cuenta con más de 16 millones de accesos fijos, más de 4,5 millones de
accesos de datos e internet y más de 20,6 millones de clientes de telefonía móvil.
Telefónica está presente en Latinoamérica desde hace 15 años, con una
inversión acumulada en infraestructuras y adquisiciones que supera los 70.000
millones de euros. En junio de 2006, Telefónica es el operador líder en Brasil,
Argentina, Chile y Perú y está desarrollando importantes operaciones en
Colombia, Ecuador, El Salvador, Guatemala, México, Marruecos, Nicaragua,
Panamá, Puerto Rico, Uruguay y Venezuela.
En Europa, Telefónica O2 tiene presencia en el Reino Unido, Irlanda,
Alemania y República Checa. A junio de 2006, el Grupo tenía más de 33,5
9
millones de accesos celulares y 4 millones de accesos fijos en la región. Así
mismo, Telefónica O2 ha ganado el concurso para la obtención de una licencia de
telefonía móvil de tercera generación en Eslovaquia durante un período de 20
años.
En junio de 2006, la plantilla promedio ascendió hasta los 222.678
empleados (+23,5% respecto al mismo período del año anterior) que se justifica
por los cambios en el perímetro de consolidación contable y al Grupo Atento.
El Grupo Telefónica ocupa la quinta posición en el sector
Telecomunicaciones a nivel mundial en capitalización bursátil y la octava en el
ranking Eurostoxx 50 (25 de Agosto de 2006). Además, cuenta con más de 1,5
millones de accionistas directos y cotiza en las principales bolsas nacionales y
extranjeras.
Telefónica Chile aborda el negocio de las telecomunicaciones desde la
perspectiva de sus clientes y buscando la mejor forma de atender sus
necesidades presentes y futuras.
Los tres grandes segmentos que atiende la Corporación son: Residencial,
cuyo foco está en las familias; Negocios, que atiende a pequeñas empresas y
profesionales; y Empresas, que atiende las necesidades de compañías, industrias
y corporaciones.
Los más importantes principios que guían la acción de los negocios son: una
estrecha relación con los clientes y empleados; el estímulo constante de la
innovación; la explotación eficiente de la infraestructura; las sinergias con el Grupo
Telefónica; y la creación de valor para los accionistas.
Telefónica Chile atiende las necesidades de comunicación de clientes
globales, corporativos y grandes empresas a nivel nacional, a través de la filial
Telefónica Empresas. Este importante segmento de clientes tiene una alta
10
concentración de ingresos y variadas necesidades al estar presentes en distintas
industrias del quehacer nacional, como banca, sector “retail”, minería, servicios,
etc. Además, son clientes que requieren de altos estándares de servicio y niveles
de especialización debido a que operan en ambientes de misión crítica para la
atención de sus negocios. Ante estas necesidades, cada vez más diversas,
Telefónica Empresas responde con una organización y propuesta de valor
diferenciado, con una especialización cada vez mayor por tipo de cliente y sector
industrial. Entre estos servicios destacan los de outsourcing en procesamiento de
datos, a través de su Datacenter.
Para entregar soluciones de Internet y procesamiento de datos, la Compañía
instaló su Telefónica Data Internet Center (TIC o Datacenter), en un emblemático
edificio de la empresa ubicado en el centro de Santiago. Se trata de un
emplazamiento estratégico porque está dentro del doble anillo de seguridad
eléctrico de la capital - punto donde no hay cortes de energía - y es además la
zona donde convergen todas las comunicaciones del país.
Conectado directamente con todo el país y otros centros similares en Brasil,
Argentina, España, Estados Unidos (Miami) y Perú, el TIC de Santiago permite a
sus clientes externalizar con seguridad sus necesidades de conectividad,
presencia en Internet y almacenamiento de datos.
El TIC, al ser un primer acercamiento para los clientes, en una línea de
externalización de sus servicios de procesamiento de datos, los cuales le dan
soporte a sus servicios de operación continua 7x24 (7 días a la semana, las 24
horas del día), hace que la misión crítica de negocio sea el poder satisfacer los
niveles de servicio acordados con sus clientes (SLAs o Service Level Agreement),
que dependerán directamente de la efectividad operacional que se pueda lograr
no sólo por el área Datacenter propiamente tal, sino también por los acuerdos de
niveles operacionales con otras áreas de la empresa (OLAs u Operational Level
Agreement).
11
Los clientes más importantes que son atendidos por Telefónica Empresas a
través de su Datacenter, tienen características globales, y que buscan fuertemente
procesos homologados a través de proveedores globalizados, como es el caso de
la empresa. Esto se debe a la necesidad de tener estándares conocidos de
servicio en cada una de las localidades donde se contratan. Por esta razón,
muchos clientes requieren demostrar que los procesos del Datacenter, pueden ser
verificados bajo estándares internacionales, que funcionan de acuerdo a modelos
conocidos, cuya ejecución asegura que los servicios críticos que serán
contratados, serán soportados con el nivel de servicio deseado; además de
asegurar la continuidad de servicio en caso de cualquier incidencia presentada.
I.2 Tendencia Actual en TI
Con el cambio de siglo se ha pasado en pocos años de la euforia al
pesimismo respecto a lo que las tecnologías de la información pueden hacer por
las empresas: si en la década de los 90 las tecnologías eran una fuente inagotable
de mejoras en la productividad, con el nuevo siglo algunos se cuestionan si las
tecnologías realmente importan1.
Lo cierto es que ni existían razones para la euforia de los años 90 ni las hay
para el pesimismo del 2000.
Los felices 90 trajeron consigo la semilla de algunos de los problemas que
hoy atraviesan las empresas. Los 90 fueron una década marcada, como definió
Alan Greenspan, por la "exuberancia irracional". Estableciendo un paralelismo
entre la economía en general, y el mercado de las tecnologías de la información
en particular, esta exuberancia puede ser descrita del siguiente modo:
Después de años esperando ganancias en productividad prometidas por las
nuevas tecnologías de la información – por ejemplo, en la década de los 80 se
acuñó el término de paradoja de la productividad para describir el fenómeno por el
1 “IT doesn´t matter”. Nicholas G. Carr. Harvard Business School Press.
12
cual se consideraba que, si bien la tecnología se había convertido en una
condición de permanencia en el mercado, las ganancias en productividad
prometidas no terminaban de producirse-, los 90 se caracterizaron por contínuas
mejoras de productividad que, en gran medida, fueron atribuidas a las TI.
Bajo la bandera de la productividad y los beneficios asociados a la misma,
las empresas se lanzaron a la búsqueda de ventajas competitivas basadas en las
tecnologías, llegando a confundir, algunas veces, los medios con el propio fin; por
ejemplo, a finales de los 90 se confundió la estrategia CRM con la tecnología que
daba soporte a esta estrategia.
A principios del 2000, debido fundamentalmente a la subida de los precios
del petróleo, se inicia el final de un ciclo económico. Si el cambio de ciclo acabó
con la "exuberancia", la llegada de métricas financieras hizo lo propio con la
"irracionalidad" de las inversiones que se llevaban a cabo.
Sin embargo, no todo fue negativo durante los excesos de los 90: la burbuja
permitió que se invirtiera en infraestructura de redes en pocos años, debido a que
el financiamiento de las mismas se llevó a cabo con capital privado. Mirando al
futuro, la burbuja tecnológica fue necesaria, el haber invertido en infraestructura
permitirá que la recuperación de la inversión sea rápida, debido a que ahora las
inversiones podrán dirigirse a la creación de valor.
No obstante, realizando un análisis retrospectivo, con las ventajas que ello
conlleva, hoy se hace patente que, en muchos casos, "los árboles impidieron ver
el bosque", ya que se ofrecieron soluciones puntuales a problemas específicos sin
una visión de conjunto y en muchos casos, el ritmo de innovación obligó a las
empresas a saltar de una tecnología a otra sin un análisis de los efectos a
mediano y largo plazo. En resumen, existió una doble problemática: visión de corto
plazo y falta de visión conjunta.
Como consecuencia, hoy las empresas se enfrentan a lo que se denomina
13
crisis de la complejidad, es decir, mientras que el número de tecnologías
adoptadas creció aritméticamente, la complejidad de integrarlas y gestionarlas lo
hizo en forma geométrica.
Por lo tanto, desde principios del 2000 las empresas vienen buscando una
mayor consolidación de las tecnologías existentes dentro de la compañía, ya no se
salta de una tecnología a otra con la facilidad del pasado. Además, la
consolidación ha traído consigo, previa inversión, un ahorro en costes recurrentes,
permitiendo liberar recursos para nuevas inversiones.
Actualmente se huye de la falta de visión conjunta al desarrollar planes
estratégicos, a partir de estos se concretan las inversiones que se llevarán a cabo
y que, a su vez, dependerán del presupuesto disponible, que es limitado.
Esta restricción presupuestaria se ha traducido en la necesidad de
desarrollar métricas financieras y de operación, que establezcan una jerarquía
entre los distintos proyectos que compiten por un mismo presupuesto.
Lo importante en el uso de la tecnología, es poder elegir qué diseño de
procesos le podrá dar un correcto soporte a una herramienta, generando ventajas
competitivas y ahorros operacionales en una determinada empresa. Para lograr
esto, y dejar de lado el paradigma de que la implementación de diversas
tecnologías de información no implica necesariamente el incremento de la
productividad, se debe diseñar sobre patrones de procesos que reflejen las
necesidades de los clientes, y según esto, asegurar los niveles de servicio que
ellos requieren.
Por lo tanto, el actual valor comercial que tiene la estandarización y
homologación de procesos que integran las mejores prácticas de mercado, es muy
alto, y debe ser usado como una ventaja competitiva mientras se pueda, pero lo
más importante, es que puede transformarse en un factor de decisión en la
elección de un proveedor de TI, diferenciándolo de su competencia.
14
I.3 Modelo de Negocio Telefónica Empresas
Telefónica Empresas Chile SA es una filial de la compañía multinacional
Telefónica Chile S.A., organización asociada al Grupo Telefónica, con sede en
España y con presencia mundial.
Nace originalmente en 1989 bajo el nombre de CTC Negocios para
desarrollarse en el mercado de las telecomunicaciones privadas, ganando en este
período una importante experiencia.
En 1992, CTC Negocios pasa a ser CTC Corp con el fin de optimizar sus
relaciones con los clientes y adaptarse a las nuevas condiciones imperantes en el
mercado. A fines de 1999, se acordó utilizar indistintamente los nombres de
fantasía de CTC Corp o Telefónica Empresas.
Al inicio del 2003 se fusiona con Telefónica Data, consolidándose como una
compañía multinacional, naciendo la actual Telefónica Empresas que vela por el
segmento de las grandes corporaciones y empresas del país.
I.3.1 Descripción de la Oportunidad
Telefónica Empresas, ha dispuesto como estrategia comercial, transformarse
en el líder de mercado como proveedor de soluciones de tecnologías de
información para las grandes empresas del país, para esto se pretende conseguir
tener una atención diferenciada para cada uno de sus clientes, manteniendo un
rentabilidad operacional adecuada, lo que le permita obtener una consolidación
financiera.
La pregunta que surge es, ¿cómo se logra tener una adecuada atención para
cada uno de sus clientes?, primero, se debe tener un riguroso cuidado en las
expectativas de ellos, cuyo conocimiento es generado a través del establecimiento
de una relación de largo plazo, ofreciendo soluciones integradas en el período,
que combinen diversos tipos de tecnologías, que hagan posible mejorar la
15
eficacia y la eficiencia de sus clientes, desde la infraestructura, hasta la ingeniería
y el asesoramiento. Esto a su vez, se potencia por la diferenciación tecnológica a
través de la mejora continua de su Red IP2, y del impulso de los Telefónica
Internet Centers (Datacenters de Telefónica).
Un punto importante, y central en la estrategia de la empresa, es tener en
cuenta los perfiles y necesidades de sus clientes, los cuales se resumen en los
puntos que se detallan a continuación:
• Dentro del segmento empresas se atiende a necesidades de clientes
globales, corporativos y grandes empresas a nivel nacional.
• Este segmento de clientes se caracteriza por generar altas facturaciones y
variadas necesidades.
• Los clientes requieren elevados estándares de servicios y niveles de
especialización en el Datacenter.
Si bien es cierto, el Datacenter de Telefónica Empresas nace como una
estructura de seguridad física y lógica para las grandes empresas del país, se
consolida por las distintas necesidades de mercado y la tendencia en poseer
servicios de operación 7x24, de régimen continuo, estos servicios se han
transformado, en algunos casos, en actividades críticas de empresas, donde la
maximización de las sinergias entre grupos de trabajo, y la minimización de
incidentes, representan la clave del éxito para el negocio.
Actualmente los clientes de Telefónica Empresas, requieren asegurar sus
procesos de negocio, con fidelidad y calidad. Pero, ¿de dónde surge esto?,
principalmente, nace porque los clientes más importantes, que son de
características globales, poseen casa matrices centralizadas, con filiales alrededor
2 El Datacenter es considerado como un elemento terminal de la extensa Red IP de Telefónica, que le suma valor a esta, debido a ofrecer la posibilidad de integrar diferentes tipos de servicios contratados, disminuyendo el riesgo y los costos operacionales.
16
del mundo, las que requieren procesos homogéneos, para asegurar las mejores
prácticas y, en los casos más particulares, disminuir el valor de los seguros
comprometidos.
Es debido a este análisis que se considera ITIL (Information Technology
Infrastructure Library), como la orientación del modelo de negocios que debiera
ser considerado en el Datacenter de Telefónica Empresas, basado en que esta
metodología es:
• Una guía de mejores prácticas.
• Aplicable a todo tipo de organizaciones.
• Sus principios son:
o Procesos
o Calidad
o Orientado al cliente
o Independencia de proveedores de TI.
• Su objetivo es apoyar a las organizaciones a desarrollar una estructura para
la gestión de servicios de TI.
Para que el funcionamiento de esta metodología cumpla con los objetivos
planificados, se debe lograr que personas, herramientas y procesos, funcionen de
manera sincronizada, por lo que se debe capacitar a las personas, para que
realicen sus actividades según el nuevo diseño de procesos, soportado por el uso
de diversas herramientas, como software o sistemas de información.
Este nuevo modelo de negocios de Datacenter, trabajará en forma conjunta
con otro tipo de certificaciones de calidad como, la ya adquirida certificación
BS7799 (Diciembre 2005), y su actualización ISO 27001.
Lo que se traducirá en tener un modelo de negocios único en este momento
en el mercado chileno, capaz de demostrar que la empresa se encuentra
totalmente actualizada y preocupada de cuáles son las necesidades de sus
17
clientes. Además, implícitamente, se encuentra el compromiso de tener mejora
continua en los procesos, debido al conocimiento que se acumulará de incidentes,
problemas, cambios en configuración y atención de requerimientos.
I.3.2 El Servicio Telefónica Empresas
La misión de la empresa, es ser líder en la satisfacción de las necesidades
comunicacionales de sus clientes, buscando un completo entendimiento de sus
requerimientos, para así ofrecer soluciones integrales de vanguardia tecnológica y
alta calidad enfocada en sus negocios.
Para esto, se cuenta con profesionales especializados en el área comercial,
más de 100 Account Managers, una plataforma de apoyo a través de Ingeniería de
clientes para el diseño de propuestas, y un gran equipo de atención al cliente y
soporte de postventa, ofreciendo soluciones de calidad y gran respaldo, teniendo
como desafío constante el entregar soluciones a medida para cada negocio.
De acuerdo a esto, las soluciones ofrecidas abarcan distintas tecnologías
que dan flexibilidad a nuestras ofertas. Para las soluciones de voz, se cuenta con
planes integrales de fidelización, que incluyen telefonía tradicional y/o telefonía IP,
enlaces, larga distancia y equipos de voz, realizando así una integración global en
las ofertas presentadas.
Además, Telefónica Empresas aporta soluciones avanzadas en los campos
de transmisión de datos y servicios de valor agregado, desarrollando soluciones
de datos tales como VPN IP-MPLS, Citynet, Videoconferencia IP, Frame Relay,
ATM, entre otros. Para las soluciones de TI, se cuenta con un equipo que provee
asesorías, servicios profesionales y externalización, por ejemplo, housing, hosting,
datacenter y seguridad.
El Resumen de los servicios ofrecidos por Telefónica Empresas puede ser
observado a continuación (Figura I.1).
18
Fig. I.1: Servicios de Telefónica Empresas
Específicamente, el Datacenter, agrupa una serie de servicios, los que se
detallan a continuación:
1. Housing: Es el Centro de Soluciones Internet y procesamiento de datos, donde
los Accesos E1 permiten interconectar Redes de Área Local (LAN), interconexión
de centrales telefónicas de clientes y otras arquitecturas de comunicaciones
predominantes en el mercado (SNA, TCP/IP; IPX; DEC Net, entre otros) de forma
sencilla y eficiente.
2. Hosting dedicado (Hosting): El servicio Web Hosting Dedicado está dirigido a
todas las empresas que desean tener presencia o publicar sus contenidos en
Internet. Las aplicaciones típicas del Servicio Hosting Dedicado son:
• Conexión Directa a la Red Wan o LAN del Cliente.
• Alojamiento de cualquier tipo de aplicaciones. Estas pueden ser de tipo
contables, bodegaje, ERP, SAP, Correo Exchange, etc.
• Acceso rápido e interactivo a la información contenida.
19
• Apoyo a campañas publicitarias con información adicional.
• Diferenciación respecto a la competencia.
El servicio Hosting Dedicado está dirigido a todas las empresas que deseen
externalizar sus sistemas informáticos, incluyendo la operación y mantención del
sistema operativo. Adicionalmente podrá sumar a este servicio otras herramientas
de gestión (monitoreo proactivo de servidores con HP Open View), también con
productos de seguridad (Análisis de Vulnerabilidades, Firewall Virtual, etc).
Este es un servicio de altas prestaciones y calidad basado en el uso de
máquinas dedicadas en exclusiva para cada cliente, lo que posibilita una
explotación intensiva de su presencia en Internet, mayor personalización,
autonomía y seguridad.
El Servicio Hosting Dedicado incluye todos los elementos necesarios de
hardware, software, comunicaciones, operación y mantenimiento, lo que le permite
a los clientes despreocuparse de la gestión, administración o configuración de
herramientas técnicas complejas, para centrarse en su negocio principal.
El Data Center forma parte de la red de comunicaciones de Telefónica
Empresas, por lo que se disminuye considerablemente el riesgo asociado a la Red
de Acceso (última milla). La diferencia fundamental del servicio Web Hosting
Dedicado y este servicio, es el tipo de conectividad. El Hosting Dedicado está
conectado a una red privada (Red IP, ATM, Frame Relay, PPP, etc) y no a una red
pública (Internet).
Este servicio también puede ser evaluado como un Site de Contingencia. Es
decir, las aplicaciones críticas de una empresa pueden estar respaldadas por otro
equipo de similares características en un Site distinto, el Site de Telefónica
Empresas.
3. Mail Hosting (Hosting): Este es un servicio de outsourcing de correo
electrónico preparado para ajustarse a las necesidades de la empresa. Con Mail
Hosting, el cliente puede acceder a los beneficios de la comunicación electrónica a
20
bajo costo, evitando costosas inversiones como hardware, software y otras.
4. Storage (Housing): Servicio de almacenamiento de información, que se orienta
a aplicaciones de misión crítica del cliente, permitiéndole pagar por uso y disponer
de una plataforma de alta disponibilidad, escalable y redundante. Las principales
actividades que se realizan son:
• Instalación, configuración y Start Up: se cuenta con la supervisión de un
profesional capacitado en la instalación y puesta en marcha de la solución
propuesta.
• Evaluación de la Arquitectura: la evaluación de la arquitectura incluye la
recomendación de componentes de Hardware, niveles de almacenamiento
primario, elementos de conectividad y componentes de software requeridos
de acuerdo a los requerimientos planteados por el cliente
• Administración de capacidad: la infraestructura instalada permite
recolectar estadísticas e información del uso de los espacios de
almacenamiento contratados por el cliente, entregando reportes
consolidados por el servidor sobre el uso del almacenamiento.
• Administración del rendimiento: se chequea mensualmente el
rendimiento de la arquitectura montada en la solución, para verificar los
niveles de servicio comprometidos.
5. Servicios Gestionados (Hosting): ofrece diversos niveles de gestión para el
negocio de los clientes a través de múltiples tecnologías. Usted puede contratar
fuera de las instalaciones de su empresa (outsourcing) uno o varios elementos de
su entorno operativo. Algunos de ellos son:
• Estadísticas de Uso: Medición de visitas y acceso a los diferentes
servicios Internet (http, ftp, smtp, etc).
• Aplicaciones Finales/Middleware: Monitorización del funcionamiento de
las principales aplicaciones disponibles en el mercado.
• Seguridad: Firewall gestionados, asesoría en la definición de políticas,
sistemas de detección de intrusos (IDS)
21
• Servidores y S.O.: Gestión de plataformas y Sistemas Operativos.
• Supervisión de Redes: Gestión de equipos terminales de comunicación en
dependencias del cliente.
• Storage y Backup: Soluciones de almacenamiento y respaldo en cinta al
problema de manejo de la información.
• Conectividad: La mejor conectividad y máxima disponibilidad al mejor
precio.
• Housing: Espacio físico en el Data Center más confiable en términos de
continuidad operacional, seguridad lógica y ambiental.
Los principales beneficios que trae este último servicio son:
• Predicción y reducción de Costos: El cliente no tendrá que realizar
grandes inversiones en herramientas de gestión. Se podrá prever los costos
mensuales que destina a la gestión de sus sistemas de información.
• Acuerdos de nivel de servicio: En función de sus necesidades,
llegaremos a un acuerdo sobre el nivel de servicio y le ofreceremos las
prestaciones y garantías que usted precisa. Y siempre con nuestro
compromiso de calidad.
• Atención continua: En Telefónica Empresas se está siempre a disposición
de sus clientes a través de su servicio de atención 24 horas.
• Manejo de la complejidad: Telefónica Empresas pone a disposición de
sus clientes el equipo más completo de especialistas en manejo de
sistemas a nivel de disponibilidad, seguridad y medición del rendimiento.
• Escalabilidad: Se ofrece un entorno que va aumentando las posibilidades
de los clientes, a medida que la empresa y las necesidades de ésta van
creciendo. Este es el modelo denominado internacionalmente como "Pay as
you grow".
Estos servicios son complementarios, y se combinan para generar servicios
compuestos, customizados de acuerdo a los requerimientos de cada cliente y su
negocio.
22
I.3.3 Mercado Telefónica Empresas
Telefónica Empresas cuenta con alrededor de 5.000 clientes, de los cuales
330 corresponden a grandes corporaciones, ministerios y organismos de gobierno;
cerca de 50 son NEPs y alrededor de 4.600 son grandes empresas. Los cuales
representan el 13,5% de los ingresos de la Corporación Telefónica, por lo que se
deduce, de los resultados del ejercicio del año 2005, que las comunicaciones de
empresas contribuyen con $78.214 millones. De estos clientes, aproximadamente
700 de ellos, tienen servicios de Datacenter contratados, los que están hechos a la
medida de cada uno. Este tipo de clientes, tiene a la tecnología como uno de los
factores críticos de sus negocios, por ello necesitan procesos que aseguren que
los altos niveles de servicio requeridos puedan ser cumplidos por su proveedor.
De hecho, los clientes que poseen este tipo se servicios, tienen una cultura
tecnológica de alta disponibilidad, es decir, cada uno de los temas que deben ser
tratados con respecto a toma de decisiones, manejo de incidentes, cambios, u otro
tipo de tema relacionado a esta área, son manejados con extremo cuidado y
carácter de urgencia, debido a la criticidad de los procesos, para el correcto
funcionamiento del negocio. Es por esto, que la empresa proveedora de este tipo
de servicios, debe ser capaz de manejar este tipo de situaciones con la misma
prioridad, impacto y urgencia que requieren sus clientes.
El mercado chileno de prestación de servicios de Data Center, es de un
total de $ 20.400 millones al año (Promedio Calculado en base a los últimos 3
años, con tendencia de crecimiento de un 15% anual), de los cuales, según puede
verse en la Figura I.2, Telefónica posee el 10% de mercado.
23
Fig. I.2: Mercado Chileno de Prestación de Servicios de Data Center.
El crecimiento acumulado de la industria del Data Center en Chile, puede
observarse en la Figura I.3.
Fig. I.3: Crecimiento acumulado respecto 2002.
La capacidad instalada en Chile, en cuanto a superficie en metros
cuadrados de sala de equipos, asciende a 7.500 [metros2], de los cuales
Telefónica posee, al año 2006, un 6,4% con 480 [metros2], realizando actualmente
una inversión que le permitirá alcanzar 750 [metros2] de sala a fines de 2007. Es
importante destacar que Telefónica posee actualmente una tasa de ocupación de
su Data Center de un 95%. La relación entre los principales competidores y su
capacidad instalada puede verse en la Figura I.4.
24
Fig. I.4: Fracción de Capacidad Total instalada en superficie de Data Center, por los
principales competidores en el mercado chileno.
De los principales competidores en la prestación de servicios de Data
Center en el mercado chileno, Sonda es el líder en Capacidad instalada en cuanto
a superficie de sala, con un 16% de la Capacidad Total, ocupando 1.200 [metros2],
claro que esta empresa tiene la particularidad de que no vende servicios de Data
Center, como un producto, sino que es una característica más de su Servicio de
outsourcing informático ofrecido a las grandes empresas de este país, liderando el
mercado en ese ámbito.
Telefónica, en cambio, ha adoptado una posición de no vender más
servicios de outsourcing, si estos no vienen con otros de Data Center incluidos.
En la actualidad, de las 2.500 empresas a las que le factura Telefónica
Empresas, solo un 10% tienen contratados servicios de Data Center, pero se
estima que en 3 años más, el 30% de los clientes de la empresa, contarán con
este tipo de servicios.
I.3.4 Precio
Los valores de los servicios varían de un cliente a otro, debido a que son
contratados frecuentemente como un paquete. Según ciertos precios base, es
armada la solución final tomando en cuenta necesidad de renta para la empresa
proveedora, y conveniencias de outsourcing por parte del cliente. Un ejemplo
25
de solución teórica, es cuando un cliente lleva un servidor que ocupa 1 U (1
unidad de espacio3 en un rack ubicado sobre superficie de sala de datacenter), y
contrata un Servicio básico de Hosting, los valores por Servicio son los siguientes
(Ilustración 2).
Fig. I.5: Precio cobrado a un cliente que aloje 1 Servidor de 1 U en Datacenter.
Estos precios solo son referencias de la gama total que presenta una
empresa, debido a que si se desagrega una oferta completa de la solución a
medida ofrecida a un cliente, serán muchos niveles más en los que se podrán
desagregar.
I.3.5 Tecnología
La tecnología tiene un rol fundamental en este negocio, siendo de vital
importancia para la organización, ya que constituye los insumos que hacen posible
brindar un determinado servicio. En cuanto a los equipos físicos específicos de
red, no puede decirse que la obtención del hardware más avanzado constituirá
una ventaja competitiva, pero sí la forma de usarla, y las aplicaciones de
desarrollo que puedan generar nuevos servicios o formas de comunicación con el
cliente. Los procesos que apoyan el desarrollo de requerimientos, si están bajo las
mejores prácticas de mercado, y unidos a una adecuada estructura organizacional
y procedimientos de escalado, constituyen la configuración de una empresa de TI
para que logre alcanzar su verdadero potencial y generar ventajas competitivas.
3 1 U = 1 Unidad de espacio ocupada en los Racks, los que tienen espacio para 42 U. Cada U puede ser calculada, como 1 U = 0,6[m]*0,7[m]*0,2[m] = 0,084 [m3]. (ancho*largo*alto de un servidor respectivamente).
26
I.4 Origen de la Iniciativa de Rediseño
Telefónica Empresas, si bien es cierto no aparece como el líder en servicios
de datacenter a nivel nacional en cuanto a porción de mercado ocupado, es la
única empresa capaz de ofrecer una gama tan extensa y variada de servicios, los
cuales permiten a sus clientes tener un solo proveedor. El caso diferenciador más
común, es la contratación de enlaces más servicios de procesamiento de datos,
que puede dar respuesta a soluciones integradas, en las que el cliente debe
plantear su necesidad y la empresa se encarga de implementar toda la solución,
desde la construcción física de enlaces hasta respuesta de servicios de valor
agregado de procesamiento de datos. Esta es una de las características, que
hacen de Telefónica Empresas, un proveedor integral de servicios de Outsourcing
y Datacenter, lo que le ha permitido en los últimos cuatro años crecer
constantemente, en cuanto a porción de mercado ocupado. Por el lado
operacional/económico, existen dos formas para una empresa proveedora de
servicios de TI, de poder introducirse en el mercado de datacenter, la primera, es
construir un gran datacenter, en cuanto a dimensiones físicas (3.000 mts.2 aprox.),
y mantener bajos precios en un comienzo para adquirir nuevos clientes; y la
segunda, es construir un datacenter pequeño (300 mts.2 de sala), para tener un
precio ajustado al de mercado, creciendo físicamente de acuerdo a la tendencia
de él.
Históricamente, para el mercado chileno, el primer modelo puede hacer que
las empresas que lo tomen, presenten problemas de flujo de caja, ya que la
inversión inicial es muy alta, y si no se tiene una penetración rápida de mercado (1
a 2 años), los valores previstos como ingresos para esos períodos dificultan la
valorización de la empresa, adquiriendo deudas.
Telefónica ha asumido el segundo modelo, para introducirse al mercado
nacional de servicios de datacenter, lo que le ha permitido generar constantes
aumentos en los ingresos percibidos, y olvidarse los constantes problemas de flujo
de caja por inversiones iniciales muy altas.
27
Pero este tipo de crecimiento, ha hecho que la empresa tenga
preferencialmente un rol de bombero en la mayoría de sus actividades, incluyendo
las críticas, satisfaciendo demandas de capacidad, insumos, y horas hombre, de
acuerdo a las necesidades periódicas del negocio, sin una planificación inicial, o
un modelo que pueda dar fe de que se están ejecutando actividades de forma
correcta.
Por este constante crecimiento en la industria de las telecomunicaciones, y
especialmente del área servicios de datacenter, a nivel nacional, es que la
Gerencia eSolutions en su momento (parte de ella ahora especializada en la
Gerencia Outsourcing y Datacenter de Telefónica Empresas), ha analizado
diferentes modelos de estandarización de procesos, y se ha llegado como
conclusión que en una primera instancia, los servicios más críticos, como los de
Datacenter, debieran ser soportados por las mejores prácticas de mercado para
empresas de provisión de servicios de tecnologías de información, mostrando al
cliente una vía en que los estándares de servicio exigidos por ellos, pueden ser
asegurados bajo un modelo conocido de mercado, como es ITIL, el cual
funcionará asegurando la información bajo la norma británica BS7799:2002 (lo que
representa un acercamiento a la obtención de la certificación ISO27001 a fines de
2006).
Además, el constante crecimiento de la cantidad de servicios ofrecidos por
telefónica y del número de clientes instalados en su Datacenter, constituyen
situaciones complejas de priorización, clasificación y resolución de requerimientos,
y cambios, los que sino son llevados por procesos establecidos de acuerdo a las
necesidades del negocio, como su magnitud y criticidad, constituyen un sinónimo
de mal servicio por parte de Telefónica.
La implementación de estos modelos de seguridad, estandarización, y
homologación, a través del rediseño de los procesos que le dan soporte a los
servicios de datacenter, bajo las mejores prácticas de mercado, permiten a la
28
Gerencia de Outsourcing y Datacenter, tener un control eficaz y efectivo frente al
manejo de infraestructura y costos, atención de requerimientos, implementación
de cambios y su posterior revisión (PIR o Post Implementation Review), entre
otros aspectos. Por lo tanto, la Gerencia puede tener un mayor alcance y
gobernabilidad, mejorando indicadores de eficiencia y costos, optimizando
recursos, y mejorando la utilización de activos dentro de la organización.
29
CAPÍTULO II: MARCO TEÓRICO-CONCEPTUAL
La industria de las tecnologías de información ha adquirido una alta
complejidad y competitividad, además se han incorporado en ella, nuevas formas
de realizar negocios. Específicamente, Provisión de Servicios de Datacenter
consiste en dar diferentes opciones de alojamiento de Servidores, a las que se
suma una gama diversa de servicios de valor agregado, ejecutados por personal
de la empresa, y que pueden ser el motivo de que un cliente perciba el servicio
como algo eficiente y ajustado a sus necesidades, o como uno que lo deja
descontento por diferentes razones, desde características técnicas a tiempos de
respuesta lentos para sus requerimientos.
Debido a lo competitivo de la industria, y a la creciente necesidad de hacer
más eficientes y estandarizados los procesos, sumado a la obligación de presentar
mayor valor agregado, es que surge la necesidad de implementar metodologías
que rediseñen los procesos, en función de las mejores prácticas de la industria.
Una pregunta que nace a partir de esto es, ¿por qué es considerada una
necesidad para una compañía como Telefónica Empresas en sus Servicios de
Datacenter, tener procesos homologados y estandarizados?, la respuesta es que
la rentabilidad de los negocios meta de la empresa, pertenece preferentemente a
clientes globales, los cuales exigen actualmente a proveedores de tecnologías de
información de carácter global, que puedan certificar que realizan los trabajos de
una determinada forma, cuya calidad es reconocida a nivel internacional.
Desde inicios de los años 80, se ha hecho una recopilación mundial de
cuáles son las mejores prácticas de la industria, y esto se ha traducido en que en
que actualmente se tenga una biblioteca de ellas, la que es llamada ITIL
(Information Technology Infrastructure Library), o Biblioteca de Infraestructura de
Tecnologías de Información, la que se ha transformado en el estándar de facto
mundial.
30
Por lo tanto, la oportunidad que se presenta al mejorar los procesos que
soportan la prestación de servicios de datacenter de Telefónica Empresas, es muy
valiosa, porque tiene la capacidad de generar ventajas competitivas dentro del
mercado nacional, y de aumentar la opciones de la empresa para responder a
necesidades contractuales de mercado a nivel global.
Lo importante es la forma en la que se puede generar ventajas
competitivas. Esto puede ser alcanzado por dos líneas principales, una es a través
de producir eficacia operacional en algunas actividades de la organización, y otra,
que es la más importante, tiene que ver con el aporte de valor que producen las
mejoras en el modelo de negocio de la empresa.
En la actualidad, los proveedores de servicios TI ya no pueden permitirse el
lujo de centrarse en la tecnología y en su organización interna, sino que ahora
deben considerar la calidad de los servicios que ofrecen y concentrarse en la
relación con sus clientes.
Antes de comprar un producto, generalmente se evalúan: calidad,
apariencia, utilidad y sus prestaciones. En general, el cliente tiene pocas
oportunidades para influir sobre la calidad del producto. Esto se debe a que ese
producto ha sido desarrollado en una fábrica mediante un proceso sobre el que el
cliente no tiene control. Gestionando efectivamente la planta de producción, el
fabricante tratará por su parte de entregar un producto de calidad constante. En
este caso, la fabricación, las ventas y el consumo del producto son procesos
independientes.
Sin embargo, los servicios se proporcionan en relación con el cliente, y no
pueden evaluarse por adelantado, sino sólo una vez prestados. La calidad de un
servicio depende de cierta forma de la manera en la que el proveedor del servicio
y su cliente interactúan. A diferencia del proceso de fabricación, el cliente y el
proveedor pueden realizar cambios cuando se está desarrollando y utilizando el
servicio. La forma en la que el cliente percibe el servicio y lo que el proveedor
31
piensa que ofrece, dependen ampliamente de sus experiencias personales y de
sus expectativas.
La percepción del cliente es esencial para la provisión de los servicios, ellos
generalmente se harán las siguientes preguntas:
• ¿El servicio cumple con mis expectativas?
• ¿Puedo esperar un servicio similar la próxima vez?
• ¿Es razonable el costo del servicio?
Si el servicio cumple o no con las expectativas depende ante todo de cuan
eficazmente se acordaron los entregables con el cliente, más que de la propia
forma en la que se provee el servicio. Un diálogo continuo con el cliente es
esencial para refinar los servicios y asegurarse de que tanto el cliente como el
abastecedor sepan lo que se espera del servicio.
Uno de los aspectos importantes al momento de suministrar servicios, es
que esto requiere actividades, y la calidad de un servicio depende mucho de la
manera en la que se organizan estas actividades. El Círculo de calidad de Deming
(Fig. II.1), muestra un modelo simple y eficaz para controlar la calidad, que asume
que para dar una calidad apropiada, se deben seguir los siguientes pasos:
• Planificar (Plan): ¿Qué se debe hacer?, ¿cuándo?, ¿quién debe hacerlo?,
¿cómo? y ¿utilizando qué?.
• Hacer (Do): Se llevan a cabo las actividades programadas.
• Verificar (Check): Ajustar los planes basándose en la información recogida
al comprobar.
• Actuar (Act): Determinar si las actividades dan los resultados esperados.
Una intervención eficaz y a tiempo significa que las actividades están
divididas en procesos que incluyan sus propios planes y oportunidades para
analizar. Debe estar claro quién es responsable de la organización y qué autoridad
32
tiene para cambiar planes y procedimientos, incluyendo actividades y procesos.
Fig. II.1: Círculo de Calidad de Deming.
La Gestión de Calidad es responsabilidad de todos los que trabajan en la
organización proveedora de servicios, donde cada empleado debe saber como su
contribución a la organización afecta a la calidad de trabajo provista por sus
colegas, y eventualmente al servicio que proporciona a la organización. La gestión
de calidad también significa estar en la búsqueda de nuevas oportunidades todo el
tiempo e implementar mejoras en las actividades relacionadas con la calidad.
Aseguramiento de la calidad es un aspecto político dentro de la
organización, y se refiere al conjunto de medidas y procedimientos que utiliza la
organización para asegurar que los servicios proporcionados continúen
cumpliendo las expectativas del cliente y los acuerdos establecidos. El
compromiso de calidad garantiza que las mejoras originadas en la gestión de
calidad se mantengan.
La experiencia en la mejora de calidad de los servicios TI ha demostrado
que ya no es suficiente estructurar y definir las prácticas actuales. El origen de las
diferencias entre el servicio provisto y los requisitos del cliente se relacionan
33
generalmente con la forma en la que se gestiona la organización TI. Una mejora
permanente de calidad demanda una cierta madurez de la organización.
El modelo de la Fundación Europea para la Gestión de la Calidad (EFQM)
(Figura II.2) puede resultar útil para determinar la madurez de una organización.
Este modelo identifica las áreas más importantes a considerar cuando se gestiona
una organización.
Fig. II.2: Modelo EFQM.
El círculo de Calidad de Deming está incorporado en el modelo EFQM. Las
medias (estrategia, políticas) se toman basándose en los resultados de las
diferentes áreas. Estas medias sirven para apoyar la planificación (por ej. La
estructura de procesos), que debería conducir a los resultados deseados. El
modelo EFQM identifica nueve áreas.
Como herramienta adicional, la organización holandesa de calidad INK,
dividió el modelo en etapas que indican hasta qué punto una empresa ha
implementado la Gestión de Calidad Total, tanto en un área en particular, como en
general. Existen cinco etapas:
• Orientada al producto: también conocida como ad hoc, orientada a la
34
producción; todo el mundo en la organización trabaja mucho (pero sus
esfuerzos no están dirigidos).
• Orientada al proceso: también conocida como “sabemos de qué se trata
nuestro negocio”, el desempeño de la organización está planificado y es
repetible.
• Orientada al sistema: o “cooperación entre departamentos”.
Las áreas cubiertas en el modelo EFQM pueden combinarse con los niveles
de madurez organizativa y sus cuestionarios pueden utilizarse para determinar la
madurez de la organización en las distintas áreas.
Cuando una organización determina su madurez, puede desarrollar una
estrategia para perfeccionarse y transformarla después de un plan basado en el
modelo de etapas, el que por un período de un año, describirá las mejoras que
deben hacerse en aspectos específicos de cada área y cómo. Al repetir este
proceso de auto-evaluación y planificación año tras año, la organización se
percata de cómo está madurando. Las mayores ventajas de este planteamiento
son que la organización puede mejorar su calidad paso a paso, que los resultados
intermedios son visibles, y que la dirección puede pilotar la organización según su
estrategia.
En el sector de las TI, el proceso de mejora de madurez más conocido es el
Modelo de Madurez de Capacidad (CMM)4, y tiene como objetivo mejorar la
madurez del proceso de creación de software. CMM incluye los siguientes niveles:
• Inicial: el proceso ocurre ad hoc.
• Repetible: los procesos han sido diseñados de manera tal que el servicio
de calidad pueda repetirse.
• Definido: los procesos han sido documentados, estandarizados e
integrados.
4 CMM fue desarrollado pro el Instituto de Ingeniería de Software (SEI) de la Universidad de Carnegie Mellon.
35
• Gestionado: la organización mide los resultados y utiliza esas medidas
conscientemente para mejorar la calidad de sus servicios.
• Óptimo: la organización optimiza conscientemente el diseño de sus
procesos para mejorar la calidad de sus servicios o para desarrollar nuevas
tecnologías o servicios.
Los modelos de madurez basados en los niveles de CMM también han sido
creados para la Gestión de Servicios TI.
Desarrollar y mantener un sistema de calidad que cumpla con los requisitos
de la norma ISO 9000 (2000), puede ser considerado por la organización como la
herramienta para alcanzar y mantener el nivel de madurez orientado al sistema (o
“Gestionado” en el CMM de Servicio TI). Esos estándares ISO hacen hincapié en
la definición, descripción y diseño de procesos.
Cuando se evalúa la madurez de una organización no se debe restringir al
proveedor del servicio. El nivel de madurez del cliente (Fig. II.3) también es
importante. Si existen grandes diferencias entre al abastecedor y el cliente,
entonces éstas deberían ser consideradas para evitar un error en el
planteamiento, los métodos y las expectativas mutuas. En concreto, esto afecta a
la comunicación entre el cliente y el abastecedor. Es aconsejable que ambas
organizaciones tengan el mismo nivel de desarrollo para operar a ese nivel, o para
ajustar la comunicación en línea con el nivel más bajo.
Fig. II.3: Niveles de Comunicación y madurez: cliente y proveedor.
36
La calidad de los servicios de TI depende ampliamente de la buena relación
con los clientes de la organización. Estas relaciones sientan la base para
establecer y actualizar los acuerdos. La Gestión de Relaciones con el Cliente TI es
la encargada de mantener la relación con los clientes y de coordinar a nivel
estratégico, táctico y operativo con las organizaciones de clientes. La Fig. II.4
muestra un diagrama de las relaciones con el cliente, e ilustra la comunicación
horizontal que se da entre los clientes y la organización TI, con respecto al soporte
y a la coordinación. La comunicación vertical tiene relación con las políticas, el
control y generación de informes.
Fig. II.4: Gestión de Relaciones con el Cliente.
En la Gestión de Relaciones con el Cliente TI, el mayor desafío es asegurar
que existan relaciones buenas y eficaces a todo nivel entre la organización TI y la
del cliente. Sin embargo, la Gestión de Relaciones con el Cliente TI será diferente
según los niveles. Uno de los elementos en las relaciones con el cliente es el
Centro de Servicios, el que se puede basar en la Gestión de Niveles de Servicio.
En estas áreas, la gestión de Relaciones con el Cliente TI representará
principalmente un papel de soporte organizado.
Todas las organizaciones se orientan en hacer realidad su visión, misión,
37
objetivos y políticas. Para ello se deben realizar las actividades correctas, y
estructurarlas en procesos, que si están claramente descritas, mostrarán:
• Qué debe hacerse.
• Qué resultado se espera.
• Cómo se mide si los procesos dan los resultados esperados.
• Cómo los resultados de un proceso afectan a los de otros procesos.
Las preguntas de la Figura II.5 surgen continuamente durante el típico
planteamiento basado en el proceso de la gestión de Servicios TI. Las
herramientas para responder a estas preguntas se encuentran a la derecha.
Fig. II.5: Modelo de mejora del proceso.
Cuando se organizan las actividades en procesos, no se utiliza la
asignación existente de tareas, ni las divisiones departamentales existentes, ya
que es una elección consciente. Al optar por una estructura de proceso, se puede
demostrar que ciertas actividades de la organización no están coordinadas, sino
que duplicadas, descuidadas o simplemente, son innecesarias.
Las actividades se deben organizar en procesos, los que se agrupan de
38
acuerdo a la estructura mostrada en la Figura II.6, la que explica el modelo de
proceso genérico ITIL.
Fig. II.6: Modelo de proceso genérico ITIL.
De este diseño, nace la Biblioteca de Infraestructura de Tecnologías de
Información, o ITIL (IT Infrastructure Library), que es el marco de procesos de
Gestión de Servicios de TI más aceptado. ITIL proporciona un conjunto de mejores
prácticas extraídas de organismos líderes del sector público y privado a nivel
internacional, que han sido recogidas por la Oficina Gubernativa de Comercio
Británica (OGC, Office of Goverment Comerce). Este framework, es utilizado por
cientos de organizaciones en el mundo y ha sido desarrollado reconociendo la
dependencia creciente que tienen las empresas en la tecnología para alcanzar sus
objetivos. Esta metodología está dividida en módulos, donde se puede ir
implementando desde el núcleo de la organización, en la medida que ésta lo
requiera. Los módulos pueden ser observados en la Figura 2.
39
Fig. II.7: Módulos de Procesos ITIL.
Cada uno de los módulos mostrados en la Figura II.7, se encuentra
explicado con los principales procesos que involucra, que tienen como fin resolver
y asegurar las principales demandas de las organizaciones de TI, las cuales son:
• Eficiencia en la gestión de TI.
• Flexibilidad y adaptabilidad.
• Time to Market.
• Calidad de los servicios de TI.
• Cumplimiento de compromisos.
• Alineación de TI con el negocio. Comunicación y planificación.
Los actuales retos de las unidades de TI, se ven representadas en la Figura
II.8.
40
Fig. II.8: Retos de las unidades de TI según Gartner5.
La Fig. II.8 muestra los retos que se desprenden para las unidades de
provisión de servicios de tecnologías de información. Aquí, surge como objetivo la
mejora de la agilidad dentro de la unidad, lo que significa mejorar los ambientes de
TI, para adaptarse a los cambios y necesidades del negocio, sujeto a una buena
administración de los costos, incrementando la calidad del servicio entregado, y
replicando una constante mitigación del riesgo. Existen en la actualidad diversas
líneas de acción para lograr esto, donde el gestionar TI por procesos, es el primer
paso de acercamiento. La Gestión de los sistemas de Información por procesos y
la orientación a servicios, son los pasos previos en el camino de evolución hacia
otras mejoras (Centros de recuperación ante desastres, Virtualización, On
demand, etc.) que permitan el alineamiento de las infraestructuras de sistemas de
información con las necesidades del negocio.
5 Gartner es una de las consultoras con más estudios del impacto de los procesos de rediseño en organizaciones de TI, y es usada como referencia en diversas líneas de investigación.
41
Fig. II.9: Gestión de TI por procesos en la línea de la evolución contemporánea.
Según la evolución de la Gestión de Procesos de apoyo a empresas de
prestación de servicios de tecnologías de información, en una línea de evolución
contemporánea, el principal paso a realizar; es la Gestión de Sistemas de
Información por procesos, para luego pasar a una etapa de transición, en la que la
Resolución Automatizada de Problemas cobra mayor importancia,
transformándose en un elemento de valor para las organizaciones6. Es importante
destacar, que dentro de este ámbito, la relación existente en las organizaciones
entre la estrategia que se ha de implementar para lograr los objetivos planteados,
y la efectividad operacional deseada, deben estar alineadas, y para lograr esto en
detalle, la implementación de ITIL en una empresa debe realizar los siguientes
pasos:
• Determinar claramente los principales objetivos que se esperan conseguir
con la implementación de ITIL.
• Implementar un Service Desk alineado con ITIL, que implemente la Gestión
de Incidencias, Problemas, Cambios y Gestión de la Configuración.
6 Fuente: Fundamentos de Gestión de Servicios TI v2.0. Business IT. 2005.
42
Otra de las prácticas a ser tomadas en cuenta en un proceso de
implementación o mejoramiento de calidad en los procesos de un determinado
modelo de negocio, es el análisis de cómo está inserto este proyecto, en particular
con respecto a la evolución de la curva visibilidad v/s madurez del negocio, desde
la perspectiva de la evolución de éstos, derivada de lo que se ha observado en la
industria de las telecomunicaciones en los últimos años (Figura II.10).
Fig. II.10: Evolución Visibilidad de Oper. vs Madurez de Negocio en G. de Operaciones de TI.
La evolución de distintas actividades y/o objetos con respecto a la madurez
del negocio, muestra que el establecimiento de una CMDB (Configuration
Management Data Base), junto con el establecimiento de ITIL (Information
Technology Infrastructure Library), se encuentran en la parte más alta de
visibilidad para una empresa de TI que está en un período de 2 a 5 años de
madurez, rango en el que se encuentra el Datacenter de Telefónica Empresas, y
los competidores directos a nivel nacional, donde existe una alta expectación por
cómo se desenvolverá el negocio, esto indica que entrar en procesos de calidad,
43
es trascendental para el negocio en el que se está desarrollando el proyecto, pero
también se debe tener un alto respaldo de la compañía para que todo resulte
según lo debido. Esto puede ser apreciado en la Fig. II.11.
Fig. II.11: Interés de Telefónica en Diferentes Procesos/Actividades de Mejora/Innovación.
De lo anterior se puede destacar que Telefónica presenta un alto interés por
ITIL, intentándose que esté disponible en los procesos de las unidades de
provisión directa de tecnologías de información, en un período no mayor a 3 años.
La inclusión de prácticas ITIL, al tener mejoras en los procesos, genera un
ahorro en el costo relativo que se obtiene al dar un determinado servicio, por
ejemplo, puede significar una disminución en los tiempos de asignación de
requerimientos, y aumento en la disponibilidad de la información, lo que traería
consigo una disminución de horas hombre ocupadas periódicamente al buscar los
detalles de diferentes proyectos o artículos de configuración. A la vez, el desarrollo
de nuevas aplicaciones o canales de comunicación con los clientes, o certificación
de actividades de operación que son ejecutadas al interior de la unidad de TI,
pueden asegurar los niveles de servicio acordados con los clientes (SLA), lo que al
fin y al cabo, dentro de medio nacional e internacional, significa para una empresa
44
proveedora de TI, tener un valor en sus servicios mayor que el de sus
competidores, lo que actualmente podría ser considerado una ventaja competitiva.
La combinación de las características efectividad operacional, en su componente
ahorro en costos, asociado a aumento de valor en los servicios entregados,
permiten plantear un acercamiento hacia la Frontera de productividad de la
empresa. (desde el punto A al B en la Figura II.12).
Fig. II.12: Movimiento en la FPP producido por Implantación de Prácticas ITIL.
El rediseño del modelo de negocios de la prestación de servicios de
datacenter de Telefónica Empresas, afecta de manera explícita, diversas
actividades de las unidades de TI, lo que implica que el alto impacto que esto
significa debe ser tratado en forma detallada y siguiendo los pasos recomendados
para procesos de cambio en organizaciones de TI.
Al ser una recopilación de mejores prácticas, ITIL no certifica empresas ni
procesos, lo que si lo hace es el estándar ISO/IEC 20000:2005, que es el primer
estándar mundial para IT Service Management basado en ITIL. Este estándar
permite que las organizaciones puedan mejorar su capacidad en la entrega de los
servicios administrados, medir los niveles del servicio y evaluar el performance.
También permite a los proveedores del servicio entender cómo aumentar la
calidad del servicio entregado a los clientes internos y externos.
45
Al ser ITIL un librería de mejores prácticas para empresas de servicios de
tecnologías de información, que nació gracias a la recopilación de ellas en
empresas de gran éxito dentro de la industria de las tecnologías de información,
representa, al compararla con otras metodologías de mejores prácticas, que tienen
sus propios framework, una consolidación de este tipo de análisis, lo que será
demostrado en la sección metodología empleada de este estudio, donde al
analizar los conceptos congruentes entre ITIL y Metodologías de Rediseño de
Procesos mediante el uso de Patrones, se podrá ver cómo se complementan y
consolidan mutuamente en el diseño de procesos que necesita tener una empresa
para brindar un servicio que tenga valor para sus clientes, y mantenga niveles
altos de eficacia operacional, asegurando una posición competitiva de mercado.
46
CAPÍTULO III: METODOLOGÍA DEL REDISEÑO
En este capítulo se explica la metodología que se utilizará para realizar los
aspectos de este trabajo, que son: el rediseño del proceso de negocio,
presentación de la evaluación económica del proyecto e implementación
organizacional.
III.1 Metodología para el Rediseño del Proceso de Negocio
Esta parte del trabajo consiste en rediseñar las actividades que forman
parte del proceso de negocio, para lo que se utilizará la metodología propuesta en
el libro: “Ingeniería e-Business: Ingeniería de negocios para la economía digital”
del Dr. Oscar Barros. Esta metodología incluye un enfoque normativo, que abarca
un conjunto de mejores prácticas probadas en casos exitosos. En el caso
particular de este proyecto, estas mejores prácticas, son complementadas con las
que se derivan directamente de ITIL, las cuales son específicas para empresas de
prestación de servicios de tecnologías de información. Por lo tanto, la mezcla de
ambas metodologías en este proyecto, van en una misma dirección sin interferirse
una a la otra, y facilitan el tener un modelo de procesos ratificado por dos
metodologías distintas, que apuntan o formas exitosas de ejecutar las diversas
actividades. A continuación, se describen las componentes principales que son
presentadas en la Figura III.1.
• Definir el proyecto: Se establecen los objetivos del rediseño, el ámbito del
proceso a rediseñar, y se analiza si se hace un estudio de la situación
actual.
• Entender la Situación Actual: Donde se modela la situación actual, para
validar y medir.
• Rediseñar: Se establece la dirección de cambio, seleccionando las
47
tecnologías habilitantes, modelando y evaluando el rediseño, para detallar y
probarlo.
• Implementar: Se construye e implementa el software, para implementar los
procesos que le den soporte.
Figura III.1: Metodología del rediseño
48
CAPÍTULO IV: MODELO DE NEGOCIO PROPUESTO
Es importante analizar la forma en que el rediseño se relaciona con el
negocio de Telefónica Empresas Chile, y la Gerencia de Outsourcing y
Datacenter, por esto se hace necesario el análisis del modelo de negocios actual,
y como el rediseño afecta a este, adicionando funciones y cambiando la forma de
ejecutar ciertas actividades.
La Implementación de prácticas ITIL dentro del Datacenter, que constituyen
las líneas guías del cambio en el diseño de los procesos, incide directamente en el
proceso de administración de la relación con el cliente, y con producción y entrega
de un servicio.
IV.1 Descripción de la Oportunidad
Como se menciona en la sección planteamiento y motivaciones iniciales del
proyecto, la oportunidad se centra en que debido al explosivo aumento del número
de clientes instalados en el Datacenter, y de la infraestructura instalada, situación
que se suma a la forma de introducción que ha tenido Telefónica en el mercado,
aumentando su capacidad a medida que las necesidades de la demanda lo han
requerido, ha traído consigo desorden en la forma de administrar los recursos
disponibles, ya sea en el modo de atender requerimientos de clientes, como en la
organización de la infraestructura física y lógica, teniendo poco control sobre
diversas métricas de eficiencia operacional. Además, las exigencias de los
clientes en cuanto a sus proveedores de tecnologías de información han ido en
aumento, presentando cada vez requerimientos de un alto nivel de estructuración
y definición de procesos, sobre todo en los temas que se relacionan con
contingencia y continuidad del negocio.
Por esta razón, Telefónica inicia una búsqueda de metodologías
especializadas para empresas de tecnologías de información, que le permita
49
asegurar a sus clientes el cumplimiento de los SLA comprometidos, por medio del
aumento en la eficacia operacional, correcto manejo de activos dentro de la
organización, y adecuado uso de herramientas de control sobre métricas de
cumplimiento de OLAs (Operational Level Agreement).
La respuesta a esta búsqueda será rediseñar el modelo de negocio que
soportan los servicios de Datacenter, a través de ITIL y BS7799:2002 (Norma
Británica de Seguridad de la Información, siendo un primer paso hacia ISO
27001), con el fin de cumplir con las necesidades de mercado, satisfaciendo las
exigencias planteadas por los clientes principalmente en seguridad de la
información y adecuado establecimiento de procesos, de la mano con la estrategia
del negocio.
IV.2 Definición del Proyecto
Se explicará a través de tres ámbitos el proyecto de rediseño. El primero,
serán los objetivos generales y específicos de él, para después, definir cuál será el
producto del rediseño, finalizando con el alcance, incluyendo en él, la descripción
a grandes rasgos del soporte necesario para realizar la entrega, siendo esto el
trabajo que se debe realizar para sustentar el producto del rediseño.
IV.2.1 Objetivos (Negocio)
EL proyecto de rediseño pretende mejorar la gestión y eficacia operacional
de Telefónica en sus servicios de datacenter, garantizando a la vez, la seguridad y
continuidad en el negocio de sus clientes.
IV.2.1.1 Objetivo General
“Implementar Prácticas ITIL en los procesos que soportan los servicios de
datacenter. Esto significa rediseñar el modelo de negocios del área acorde a
50
la estrategia del negocio, utilizando planes operacionales y sistemas de
información que mejoren la relación con cliente, disponibilidad de la información, y
administración de activos dentro de la organización”.
IV.2.1.2 Objetivos Específicos
1. Aumentar la disponibilidad de la información, haciendo más eficiente la
gestión sobre requerimientos de clientes.
2. Alinear la estructura de la organización y la estrategia de la empresa,
habilitándola para cumplir los acuerdos de servicio con sus clientes.
3. Reducir los tiempos de solución de requerimientos de clientes.
4. Reducir las pérdidas de inventario, aumentando el control sobre los activos
dentro de la organización.
5. Generar información para sustentar la mejora continua dentro de la
organización, a través del aprendizaje histórico.
IV.2.2 Producto del Rediseño (Entrega)
Los objetivos detallados anteriormente pretenden ser realizados a través de
la intervención de los procesos: administración de la relación con el cliente,
gestión de producción y entrega, y producción y entrega de un servicio,
permitiendo:
• Realizar un análisis sobre los requerimientos de clientes.
• Controlar el estado y uso de activos dentro de la organización.
51
• Buscar Información detallada de proyectos, y de soluciones adecuadas a
distintos tipos de incidentes.
• Responder eficazmente a peticiones de clientes.
• Disminuir problemas de asignación de trabajo.
IV.2.3 Alcance del Rediseño (Soporte)
Rediseñar los procesos de soporte del datacenter de Telefónica Empresas,
incluye realizar diferentes actividades para que éstos funcionen correctamente
bajo prácticas ITIL. Estos procesos se explican a continuación.
1. Levantamiento de bases operacionales de inventario, y servicios de
clientes.
2. Alineamiento con otras certificaciones como BS7799:2002.
3. Diseño de procesos de datacenter de acuerdo a ITIL, y a necesidades de
clientes en particular.
4. Prueba de concepto de los Procesos de Administración de la relación con el
cliente.
IV.2.4 Papel de las Tecnologías de Información
Las Tecnologías de Información habilitarán el funcionamiento de los
procesos rediseñados del datacenter de Telefónica Empresas, reduciendo el costo
de adquirir información acerca de resolución de requerimientos, habilitando a la
vez funciones de búsqueda e ingreso de información de proyectos y activos, lo
que permite que la gestión sobre ellos pueda hacerse eficientemente.
52
CAPÍTULO V: MODELAMIENTO IDEF0 DEL REDISEÑO PROPUESTO
Los procesos del Datacenter de Telefónica Empresas han sido adecuados
acorde al crecimiento sostenido registrado los últimos años, teniéndose al
comienzo, un relativo orden, que se ha ido perdiendo con el paso de los años
debido principalmente al explosivo aumento del número de clientes que requieren
servicios de este tipo. Por lo tanto, la implementación de las mejores prácticas de
mercado, como ITIL y otro tipo de certificaciones anteriormente mencionadas,
apuntan a pasar de ser “artesanos” a verdaderos “profesionales” en el manejo de
las TI, en cuanto a su forma de gestionarlas, con el fin de asegurar los niveles de
servicio acordados con sus clientes, los que son un aspecto crítico del negocio de
ellos.
Es la criticidad de los niveles de servicio de los clientes, la que hace
imprescindible un diseño de procesos acorde a los tiempos de respuesta
requeridos que logre disminuir el tiempo que se demora la unidad en solucionar
incidentes, problemas y cambios requeridos. Todo esto, se ve favorecido en mayor
manera, si es que también disminuye la no-disponibilidad de los servicios
ofrecidos, la cual depende directamente de la buena gestión de configuración e
infraestructura que se tenga. Por lo tanto, el establecimiento de mejores prácticas
de mercado pretende asegurar y mejorar los niveles de gestión, disminuyendo
fallas en diferentes aspectos y niveles, tanto en gestión como en el área
operacional.
Las prácticas ITIL para el Datacenter de Telefónica Empresas, han sido
modeladas según la metodología IDEF0 en el Software BPwin, y son presentadas
a partir del punto V.2.
53
V.1 Principales Logros a Alcanzar
Los principales logros que serán alcanzados por el diseño son:
• Establecimiento de un proceso ITIL bien detallado.
• Asignación clara de roles y responsabilidades.
• Disminución de incidentes y problemas, y del tiempo empleado en solucionarlos.
• Gestión de Mejora Continua de procesos.
• Mejoras Operacionales.
V.2 Diagramas de Procesos Diseñados/Rediseñados
El Macroproceso de Provisión de Servicios de tecnologías de Información
del Datacenter de Telefónica Empresas, se observa en siguiente figura, donde se
destaca el nivel A-0 del nuevo proceso.
Fig. V.1: Nivel A-0 Macroproceso Provisión de Servicios Datacenter Telefónica Empresas.
54
Bajando un nivel en el modelamiento, se encuentra el nivel A0, el cual
muestra que se usó para este diseño el patrón de procesos Macro1, debido a que
este concuerda con la gestión, producción y entrega de un bien y/o servicio, lo que
se adapta al caso en estudio, con lo que el nivel A0 queda como lo detalla
siguiente Figura.
Fig. V.2: Nivel A0 Provisión Servicios Datacenter Telefónica Empresas.
En la Figura anterior, se destacan los procesos que forman el modelo de
negocios del Datacenter, los que son muy parecidos a los de Macro1, debido a
que este es un caso de gestión, provisión y entrega de un bien o servicio, por lo
que es totalmente aplicable este patrón. Cabe destacar que los procesos de
gestión ITIL de diversos aspectos, estarán incluídos en el proceso Gestión
Producción y Entrega (A3), pero que su ejecución propia estará ligada al proceso
Producción y Entrega del Servicio (A4). En diagrama, se destaca que la
Administración de la relación con el cliente será el proceso que involucre toda la
55
interacción con ellos, teniéndose en él una clasificación casi totalmente automática
de los requerimientos acerca de servicios.
En la figura siguiente, se puede ver el nivel A1, que muestra los
subprocesos pertenecientes a Administración de relación con el cliente.
Fig. V.3: Nivel A1, Administración de la relación con el cliente.
En la Fig. anterior se destacan los subprocesos, Análisis de Necesidades
de Mercado, que es el responsable de analizar cuáles son los nuevos servicios
que se están entregando, para generar nueva información al mercado, y cambios
de estado en la proyección de requerimientos; también se ve el subproceso
Gestión de Venta de Nuevos Servicios y Atención al Cliente, el que conforma la
plataforma de atención al cliente, los que son llevados a cabo a través de
diferentes canales; Además, está el tercer subproceso, que es la decisión de
satisfacción de requerimientos.
56
La Fig. siguiente (V.4), muestra el detalle del subproceso Gestión de Venta
de nuevos servicios y atención al cliente.
Fig. V.4: Nivel A12, Gestión de Venta Nuevos Servicios y Atención al Cliente.
Del nivel A12, podemos ver la actividad de recepción de requerimientos de
clientes, la que se muestra en detalle en la fig. siguiente.
57
Fig. V.5: Nivel A122, Recepción de Requerimientos Clientes.
Dentro de la Recepción de Requerimientos de Clientes, se encuentra la
Clasificación Automática de Requerimientos, la que será la encargada de
clasificar, y asignar en forma automática los requerimientos que tengan
características susceptibles de hacerlo. Estos requerimientos serán aceptados y
ejecutados en las actividades pertenecientes al proceso de Producción y Entrega
de Servicio (Nivel A41), lo que se verá en las figuras que se presentan a
continuación
58
Fig. V.6: Nivel A1221, Clasificación Automática de Requerimientos.
En la actividad Clasificación Automática de Requerimientos, se tiene que el
cliente del sistema de gestión de requerimientos, accede a la página web
(browser), para ingresar su requerimiento, el que puede ser desde una solicitud de
servicio hasta el reporte de un incidente. Con esta información el Coordinador de
Interacción buscará en su lógica de interfaz, y la lógica de negocio, la clasificación,
priorización y asignación del requerimiento dado.
Volviendo al nivel A0, se tiene que el proceso de Gestión de la Producción y
Entrega, queda definido de la siguiente manera.
59
Fig. V.7: Nivel A3, Gestión de la producción y entrega.
. En la Fig. anterior, se muestran los subprocesos pertenecientes a la
Gestión Producción y Entrega, de los que destacan Implementación Nuevos
Servicios, Gestión de Producción y Decisión entrega del servicio, es importante
destacar que dentro del subproceso Gestión de Producción, se encuentran las
subprocesos ITIL, es decir, dentro de él se realizará la gestión de requerimientos,
para que las actividades que estén bajo Producción y Entrega (Nivel A41), sean
las encargadas de realizarlas. A continuación, se presenta el detalle de la Gestión
de Producción, incluyéndose las dos áreas de trabajo ITIL, que son Gestión de
Soporte de Servicio y Gestión de Entrega de Servicio. Estas constituyen el núcleo
de trabajo ITIL (Service Support y Service Delivery).
60
Fig. V.8: Nivel A32, Gestión de Producción.
Como se había explicado anteriormente, en la gestión de Producción, se
tienen las dos actividades asociadas al núcleo de trabajo ITIL, que son Gestión de
Producción y gestión de la entrega de servicio (Niveles A321 y A322
respectivamente). Estas actividades incluyen los cinco subprocesos propios de
ITIL, lo que se ve en las siguientes Figuras.
A continuación se presenta el marco de trabajo de la Gestión de Soporte de
Servicio, que incluye cinco subprocesos, y una función que es la de soporte de
primera línea, que es el Service Desk (A3211). Estos cinco subprocesos son los
encargados de dar, como su nombre lo indica, el soporte adecuado para que los
niveles de servicios acordados con los clientes se mantengan de acuerdo a lo
previamente establecido.
61
Fig. V.9: Nivel A321, Gestión de Soporte de Servicio.
En la Fig. anterior, se observan los subprocesos propios de la Gestión de
Soporte de Servicio ITIL, los cuales son: Service Desk, Gestión de Incidentes,
Gestión de Problemas, Gestión de Configuración, Gestión de Cambios, y Gestión
de Releases, los que contemplan la ejecución de un cierto ciclo cada vez que
sucede algún incidente y/o problema, una de estas es la actualización de la CMDB
que albergará toda la información histórica de estos sucesos. Cada uno de los
subprocesos será explicado en detalle a continuación, con sus respectivos
objetivos y entregables.
El flujo de actividades propias del Service Desk, se ve en detalle en la figura
siguiente.
62
Fig. V.10: Nivel A3211, Service Desk
El Service Desk (A3211) tiene como objetivo actuar como punto central de
contacto entre los usuarios y la gestión de servicio de TI (incluyéndose la Gestión
de Soporte y Entrega de Servicio). Otras de sus funciones son: manejar incidentes
y requerimientos y proveer una interfaz a otros procesos, facilitar la restauración
del servicio normal con impacto mínimo y según lo acordado, generar informes,
promocionar, comunicar. Por lo tanto, la inclusión del Service Desk es de vital
importancia para la organización, debido a que:
• Actúa como una función estratégica para identificar y reducir el costo de
propiedad al soportar la infraestructura de soporte e informática.
• Soporta la integración y Gestión del Cambio a lo largo de los límites del
negocio distribuido, tecnología y procesos.
• Reduce costos con el uso eficiente de recursos y tecnología.
• Soporta la optimización de inversiones y la gestión de servicios de soporte
de negocios.
63
• Ayuda a asegurar la satisfacción de oportunidades de negocio.
Es importante destacar que el Service Desk tiene como objetivo extender
los servicios a un nivel proactivo, y ser un gestor de expectativas de clientes en
sus requerimientos.
A continuación se presenta el detalle de otro de los subprocesos de la
Gestión de Soporte de Servicio (A321), que es Gestión de Incidentes (A3212).
Fig. V.11: Nivel A3212, Gestión de Incidentes.
En la figura anterior, se presentan las actividades del subproceso Gestión
de Incidentes, lo importante de él, se puede resumir en lo siguiente: un usuario
experimenta un incidente, y el proceso de Gestión de Incidentes asegurará que el
servicio del usuario estará conectado de nuevo tan pronto como sea posible. Los
objetivos primarios de este subproceso son:
• Reestablecer la operación normal del servicio lo más rápido posible.
64
• Minimizar el impacto adverso en las operaciones de negocio.
• Asegurar que los niveles de calidad y disponibilidad de los servicios se
mantengan en lo establecido.
Por lo tanto, este subproceso tiene algunas entradas, que son: los
incidentes que vienen a partir del service desk, información de configuración (la
que a su vez puede traer respuesta que corresponde a incidentes7), problemas o
KE8 (know errors), detalles de resolución, respuesta de RFC9 para efectuar
resolución de incidentes, y recursos como información proveniente de la CMDB10.
Algunas salidas de este subprroceso de Gestión de Incidentes, son:
Informes de Gestión, Requerimiento Gestión, Creación de un problema (un
incidente no resuelto), o el registro de un incidente actualizado. Implícitamente en
ellos están incluídos RFCs para resolución de incidentes, incidentes cerrados y
resueltos, comunicación a clientes.
Dentro de este proceso se destaca la CMDB o Configuration Management
Data Base, como uno de los recursos a emplear. Consultarla es necesario para
obtener información sobre el servicio que se interrumpe, los datos de acuerdos de
nivel de servicio, los CI´s11 relacionados a este servicio y con incidencias pasadas,
errores conocidos y cambio de expedientes.
La actividad cierre del incidente, significa que si se indica una solución
permanente o un workaround12, se implementará y restaurará el servicio. El grupo
7 Incidente: cualquier evento que no es parte de la operación estándar de un servicio y que causa, o puede causar, una interrupción o una reducción, de la calidad de servicio. 8 Know Error: Error Conocido, que es la condición que prevalece después de haber realizado un diagnóstico exitoso de la causa raíz de un problema y cuando se confirma que un CI (Elemento de Configuración), presenta una falla (El error es eliminado mediante la implementación de un cambio). 9 RFC: Request for change, o petición de cambio que debe ser autorizado por la Junta Asesora de Cambio perteneciente al subproceso Gestión de Cambios. 10 CMDB: Configuration Management Data Base, Base de datos de gestión de configuración, que es la que guarda todas las especificaciones de los CI´s(configuration Item) o artículo de configuración, que es todo elemento necesario para brindar un determinado servicio. 11 CI: Configuration Item, o Artículo de Configuración, que es todo elemento necesario para brindar un servicio. 12 Workaround: método de evitar un incidente o problema, orientado a reestablecer el servicio.
65
de solución informará al personal de Service Desk, para que ellos investiguen con
el cliente si la solución o workaround ofrecidos han restaurado el servicio como se
requiere. Si es el caso, el personal puede cerrar los incidentes.
Siguiendo con el flujo de la gestión de un incidente o algún otro tipo de
requerimiento, si este no fue solucionado por la gestión de incidentes, se
transforma en un problema13, y es derivado a Gestión de Problemas (Nivel
A3213), cuyas actividades y subprocesos son presentadas en la siguiente figura.
Fig. V.12: Nivel A3213, Gestión de Problemas.
La Gestión de Problemas, tiene como objetivo manejar todo tipo de
servicios de TI fallidos, principalmente, intentando identificar las causas raíz de
aquellos fallos y recomendar cambios en los Artículos de Configuración (CI´s) a
13 Problema: la cuasa raíz de uno o más incidentes (aunque no es necesario, pero es frecuente, que al momento de resolverse el incidente se cierre).
66
Gestión de Cambios (Nivel A3215). Por lo tanto, los objetivos primarios de este
subproceso son:
• Minimizar la adversidad del impacto de los incidentes y problemas en el
negocio, que son causados por errores en la infraestructura.
• Prevenir la recurrencia de incidentes ocasionados por un mismo error.
• Encontrar la causa raíz de los errores e iniciar las acciones correctivas.
Dentro de la Gestión de problemas, tenemos dos tipos de acciones: las
reactivas, representadas por el registro, control de problemas y errores, y las
preactivas, que son la prevención preactiva, y el control post implementación (PIR
o Post Implementation Review).
Las responsabilidades de la Gestión de Problemas son:
• Control de Problemas (Nivel A32132): Esta función realizará análisis de
tendencias, registrará problemas y realizará análisis de causas de raíz para
solucionar en forma permanente los problemas.
• Control de Errores Conocidos (Nivel A32133): Controla los errores
conocidos, genera RFCs a Gestión de Cambios para eliminar los errores
conocidos de infraestructura. Mantiene las bases de datos de conocimiento,
errores conocidos y workarounds. Publica los errores conocidos para que el
proceso de Incidencias pueda resolver antes incidencias e investigará si
problemas y/o errores conocidos también están presentes o no en otras
partes de la infraestructura controlada.
• Prevención Preactiva: Previene la introducción de nuevas incidencias o
problemas, a través de Información a la organización. También realiza
Análisis de Tendencias, y Acciones Preventivas Planificadas.
• Revisión Post Implementación (PIR): Gestión de Problemas archiva las
solicitudes de Cambios, y solo después de implementar un cambio, se
67
puede tomar la determinación de si el cambio ejecutado hizo lo que se
esperaba, es decir, la reducción o eliminación de incidencias. Debido a
esto, la revisión post implementación tiene como objetivo comprobar si el
cambio fue bien ejecutado.
A continuación se presentan las actividades propias del Control de
Problemas (Nivel A32132), que debe ser hecho por Gestión de Problemas (Nivel
A3213).
Fig. V.13: Nivel A32132, Control de Problemas.
La principal salida del subproceso Control de Problemas, es el KE (Know
Error), que es la principal entrada del Control de Errores (Nivel A32133), donde se
tienen las siguientes actividades:
• Identificación de error: es cuando se detecta un CI roto, por lo que el status
68
de error conocido se asigna cuando se encuentra la causa raíz del
problema.
• Evaluación de Error: en este paso se realiza una evaluación inicial de los
medios para resolver el error, en colaboración con personal especialista. El
proceso de cada Error Conocido debe ser grabado en el Sistema de
Gestión de Problemas. Es vital que los datos de los CI´s, síntomas y
acciones de resolución o workarounds relacionados con todos los errores
conocidos, se registren en la tabla de la base de datos de errores
conocidos, porque entonces estaría disponible para emparejamiento de
incidencias, proporcionando una guía para futuras investigaciones y para
proporcionar información de gestión.
• Registro de Error/resolución (envío de RFC): este paso registra una
resolución de un error y completa una RFC de acuerdo con los
procedimientos de Gestión de Cambio. La prioridad de la RFC se determina
por la urgencia e impacto del error en el negocio. El identificador de la FRC
se incluye en el registro de error conocido y viceversa a fin de mantener un
rastro de auditoría completo. Las etapas finales de la resolución de error –
análisis de impacto, evaluación detallada de la acción de resolución a llevar
a cabo, modificación del artículo en error, y la prueba de cambio – están
bajo el control de gestión de cambio.
• Cierre del Error: tras implementar con éxito los cambios (determinado por la
revisión post implementación), para resolver errores, el Error Conocido
relevante se cierra, junto con los expedientes de Incidencias o Problemas
relacionados.
Por lo tanto, como se ve en la siguiente figura, que muestra el Nivel
A32133, Control de Errores, se tiene como principal salida del subproceso el
Cierre del Problema.
69
Fig. V.14: Nivel A32133, Control de Errores.
A continuación se presenta el Nivel A3214, Correspondiente al Subproceso
Gestión de Configuración, el que permite a la gestión de TI obtener un control
escrito sobre los bienes de TI tales como aparatos de hardware, programas
informáticos, documentación y cualquier otro artículo (llamados Artículos de
Configuración o CI´s), que se relacionen con la infraestructura de TI. El objetivo
principal de éste, es ayudar a la organización en su necesidad de controlar todos
los componentes que soportan un servicio para asegurar la calidad, eficiencia y
economía de la operación.
Gestión de Configuración, provee un modelo lógico de la infraestructura y
servicio, identificando, controlando, manteniendo y verificando las versiones de los
componentes.
Por lo tanto, el proceso permite:
70
• Proporcionar información precisa de los componentes de configuración (CI),
como por ejemplo: sus relaciones y configuraciones, así como su
documentación, estado actual y su historia para soportar todos los demás
procesos de Gestión de Servicio.
• Proporcionar una base sólida para Gestión de Incidentes, Gestión de
Problemas, Gestión de Cambios y Gestión de Release.
• Contabilizar, Monitorear y mantener actualizada la información de todos los
bienes y configuraciones de TI dentro de la organización que sean
necesarios para la entrega de servicios.
• Verificar los registros de configuración contra la infraestructura y corregir
cualquier excepción.
Fig. V.15: Nivel A3214, Gestión de Configuración.
71
Gestión de Configuración (Nivel A3215), es el proceso responsable de
registrar en la CMDB, o Base de Datos de Gestión de Configuración todo lo
necesario para que sea un apoyo eficaz a los otros procesos.
A continuación se muestra el proceso Gestión de Cambios (Nivel A3215),
cuyo objetivo principal es asegurar que se usen procedimientos y métodos
estandarizados en el manejo de todos los cambios, además de minimizar el
impacto que puedan provocar.
Fig. V.16: Nivel A3215, Gestión de Cambios.
El primer objetivo de Gestión de Cambio, es asegurar que se utilicen
procedimientos y métodos estandarizados para el manejo eficiente y puntual de
todos los cambios, a fin de minimizar el impacto de los cambios sobre la calidad
del servicio y la continuidad del negocio, además de requisitos de recursos,
aprobación e impacto de cambios. Este enfoque es esencial para mantener un
equilibrio apropiado entre la necesidad de cambio frente al impacto de él.
72
Gestión de Cambios no está a cargo de implementar cambios, sólo
controlará que se aprueben y se implementen de forma eficiente y efectiva en lo
que se refiere a costo y, con un mínimo de riesgo para los servicios nuevos y
existentes.
Por lo tanto, este proceso es el encargado de manejar cambios14,
solicitudes de cambio (RFC)15, programa adelantado de cambios (FSC)16,
coordinar la Junta Asesora de Cambios (CAB), y la Junta Asesora de Cambios de
Emergencia (CAB/EC).
Gestión de Cambios, comienza con la llegada de una RFC o un FSC, la
cual, se registra y clasifica, recogiendo la información necesaria para tomar
decisiones sobre qué se ha de cambiar, la categoría y el impacto para que la
autorización se pueda hacer correctamente. Se asigna una prioridad y categoría
basada en el impacto del cambio. Luego, se coordina la implementación, y
cuando es necesario se convoca a una junta asesora de cambios, conformada por
personas autorizadas a tomar decisiones respecto a esto. Para asegurarse de que
el cambio está siendo bien implementado, se monitorea la implementación, para
posteriormente revisar y cerrar la RFC.
A continuación, se presenta el subproceso Gestión de Release (Nivel
A3216), el cual tiene como objetivo proteger el ambiente de producción y de sus
servicios a través de procedimientos formales y apropiados, además de tomar una
visión general de un cambio en los servicios de TI, asegurando que todos los
aspectos técnicos y no técnicos sean tenidos en cuenta.
Dentro del ámbito de acción de este proceso, se encuentra el manejo de la
DSL (Definitive Software Library), y DHL (Definitive Hardware Library). Donde
14 Cambio: La adición, modificación o eliminación aprobada y soportada, o inclusive el retorno a la línea base de cualquier CI. 15 Solicitud de Cambio (RFC): Forma o pantalla usada para registrar los detalles de una solicitud de cambio (RFC) de cualquier CI o de cualquier procedimiento asociado con la infraestructura. 16 Programa Adelantado de Cambios (FSC): Programa que contiene los detalles de todos los Cambios aprobados para implementar así como sus fechas de implementación propuestas. Cuando un programa está aprobado, se denomina con la sigla FSCA.
73
cada una de estas bibliotecas es responsable de almacenar diferentes
especificaciones como:
• DSL: Actualización CMDB, Distribución, Almacén Físico, Alamacenaje
Lógico, Resguardo de Versiones Autorizadas.
• DHL: Actualización CMDB, Repuestos para recuperación, Componentes
para Cambios, Almacén Físico, Resguardo de Repuestos y Componentes
de Hardware.
Fig. V.17: Nivel A3216, Gestión de Releases.
Por lo tanto, las principales responsabilidades de la Gestión de Release
son:
• Programar y Supervisar la liberación de software y hardware.
• Diseñar e Implementar procedimientos eficaces para la distribución e
instalación de cambios a los sistemas de TI.
• Gestionar expectativas de clientes durante la liberación, vía Service Desk.
74
• Asegurar que todas las copias maestras queden almacenadas en la
biblioteca definitiva de software.
• Actualizar la base de datos de gestión de configuración con el fin de que
todo el hardware quede distribuido y que cada cambio sea seguro y
rastreable.
Los subprocesos explicados anteriormente, Service Desk (A3211), Gestión
de Incidentes (A3212), Problemas (A3213), Cambios (A3214), Configuración
(A3215) y Release (A3216), pertenecen a Gestión de Soporte de Servicio, que a
su vez, es uno de los subprocesos de Gestión de Producción (A3). El otro
subproceso del Nivel A3, es Gestión de Entrega de Servicio (Nivel A322), cuyos
subprocesos se presentan en la siguiente figura.
Fig. V.18: Nivel A322, Gestión de Entrega de Servicio.
En la Gestión de entrega de servicio, se encuentran los subprocesos de
gestión de capacidad, continuidad, disponibilidad, financiera, y del nivel de
servicio.
75
La Gestión de Capacidad (Nivel A3221), presentada a continuación, tiene
como objetivo entender requerimientos futuros del negocio, necesidades actuales
de la operación e infraestructura, con el fin de asegurar la capacidad actual y
futura y los aspectos de performance de los requerimientos de negocio, sean
provistos con un costo efectivo.
Fig. V.19: Nivel A3221, Gestión de Capacidad.
Esta gestión debe focalizarse en la capacidad, performance y monitoreo,
abarcando todo el hardware, desde pc´s, servidores, mainframe, componentes de
red WAN, LAN, bridges, routers, periféricos de almacenamiento, software (sistema
operativo, de red, paquetes, desarrollos in-house, etc.) y recursos humanos
(donde la ausencia redunde en una baja de performance).
76
Cada una de las actividades de Gestión de la Capacidad tiene un objetivo
diferente:
• Gestión de Capacidad Empresarial (Gestión de la Demanda): se preocupa
de la tendencia, pronóstico, modelo, prototipo, tamaño y requisitos para un
futuro negocio.
• Gestión de Capacidad de Servicio (Gestión de la Carga de Trabajo): vigila,
analiza, ajusta e informa sobre servicios, estableciendo líneas base y
perfiles de uso de servicios, manejando la demanda de ellos.
• Gestión de Capacidad de Recursos: vigila, analiza, e informa sobre la
utilización de componentes a nivel individual, estableciendo líneas base y
perfiles del uso de componentes.
La principal salida del proceso Gestión de Capacidad, son Instrucciones de
Servicio que incluyen Informes de Capacidad, de acuerdo a lo explicado en sus
actividades.
A continuación se presenta el subproceso Gestión de Disponibilidad (Nivel
A3222), el cual tiene como objetivos predecir, planear y gestionar la disponibilidad
de los servicios asegurando que:
• Todos los servicios estén soportados por CI´s confiables, suficientes y con
un mantenimiento adecuado.
• Cuando los CI´s no sean soportados internamente, que existan acuerdos
apropiados con cláusulas contractuales con los proveedores.
• Se propongan cambios para prevenir la pérdida de la disponibilidad de
servicio a futuro.
77
Cumpliendo con este objetivo, entonces, el Datacenter de Telefónica
Empresas, puede asegurar la entrega de los niveles de disponibilidad acordados
con los clientes en los SLA.
Fig. V.20: Nivel A3222, Gestión de Disponibilidad.
Por lo tanto, las principales responsabilidades de la Gestión de
Disponibilidad, son:
• Determinar los requisitos de disponibilidad en términos del negocio.
• Optimizar la disponibilidad a través del monitoreo y el informe de
resultados.
• Determinar las funciones vitales del negocio.
• Definir los objetivos de Disponibilidad, Confiabilidad y Sostenibilidad para
los componentes de la infraestructura de TI, así como medirlos e
informarlos.
78
• Monitoreo y Análisis del rendimiento de los CI´s con el objetivo de obtener
tendencias de la Disponibilidad, Fiabilidad17 y Sostenibilidad18 de los
componentes.
• Revisar los niveles de disponibilidad de los CI´s para asegurar el
cumplimiento de los SLA y los OLA:
• Investigación de las razones para la no-disponibilidad.
• Desarrollo y Mantenimiento de un Plan de Disponibilidad e introducirlo en la
organización a través de Instrucciones de Servicio o Requerimientos.
17 Fiabilidad: La habilidad del componente de entregar la funcionalidad deseada durante un período de tiempo dado y bajo ciertas circunstancias. Pero la fiabilidad no sólo considera la tecnología, también personas y procesos, ya que un servicio será más fiable si la Gestión de Cambio estabiliza el entorno controlándolo y Gestión de Problemas consigue eliminar las causas raíz y/o previene la infraestructura de incidencias y problemas. 18 Sostenibilidad: La habilidad de un componente o servicio de volver a un estado en el que se proporcione la funcionalidad deseada de nuevo. Aquí, se apoya mayoritariamente en procesos y personas, ya que el componente puede volver antes si se tiene un proceso eficiente de problemas e incidentes y el personal tiene conocimientos suficientes para subsanar la interrupción.
79
A continuación se presentan las actividades propias de Gestión de
Continuidad (Nivel A3223).
Fig. V.21: Nivel A3223, Gestión de Continuidad.
Gestión de Continuidad (Nivel A3223), tiene como objetivo, soportar la
continuidad del negocio, asegurando que todos los requerimientos de tecnología y
de facilidades para los servicios, puedan ser recuperados según lo requerido, y en
los tiempos acordados.
El inicio del proceso Gestión de Continuidad, está constituido por un
análisis de impacto al negocio, seguido por una evaluación del riesgo que puede
tener tanto en infraestructura, como en recursos lógicos, para después crear la
estrategia de continuidad de negocio, a través de la creación de un plan de
recuperación, cuyo soporte está en el desarrollo de diversos procedimientos.
80
Es importante destacar la diferencia que existe entre Gestión de
Continuidad (Nivel A3223) y de Disponibilidad (Nivel A3222), y es que la primera
se preocupa de los desastres, es decir de cómo proceder en caso de que suceda
un evento de probabilidad menor, pero de alto impacto. Por su parte, Gestión de
Disponibilidad, es el encargado de prevenir y dictar la forma de actuar en cuanto a
fallos esperados con probabilidad mayor de ocurrencia, pero de un impacto menor.
A continuación se presentan las actividades del subproceso Gestión de
Nivel de Servicio (Nivel A3224), cuyo objetivo es mantener y mejorar
gradualmente la calidad de los servicios de TI del negocio, a través de un
constante ciclo de acuerdos, monitoreo, reportes y revisión de los objetivos de los
servicios.
Las responsabilidades de la Gestión de Nivel de Servicio son:
• Analizar la relación de negocio entre el cliente y el proveedor.
• Mejorar las especificaciones y el entendimiento de requisitos del servicio.
• Obtener mayor flexibilidad y respuesta en la provisión de servicio.
• Equilibrar las exigencias del cliente y el costo de la provisión de servicio.
• Tener niveles de servicio medibles.
• Mejorar la calidad a través de una revisión continua.
La Gestión de Nivel de Servicio (SLM), es esencial para el Datacenter, ya
que se requiere demostrar un compromiso con la provisión de servicio orientada al
cliente para el negocio.
81
Fig. V.22: Nivel A3224, Gestión de Nivel de Servicio.
Por lo tanto, es esencial que este proceso sea capaz de manejar diferentes
especificaciones de servicio, tales como:
• Catálogo de Servicio: detalles del rango completo de servicios que el
departamento de TI puede entregar y los distintos niveles de servicio que
están disponibles a los clientes.
• Acuerdos de Nivel de Servicio (SLA): negociados para alcanzar un
compromiso entre las necesidades de servicio del cliente (SLR o Service
Level Request) y lo que se entrega propiamente tal.
• Acuerdo de Nivel Operacional (OLA) y Contrato Subyacente (UC o
Underpinning Contract): son documentos que soportan los SLA y son
acordados con proveedores internos (OLA) y externos (UC), para describir
82
la entrega de uno o más componentes del servicio del principio hasta el
final.
En la siguiente figura, se observan los procesos pertenecientes a la
producción propiamente tal, donde la ejecución de las actividades tendrá como
resultado la entrega del servicio al cliente. Además, de la producción de servicios,
se presenta la Generación de Proyectos (Nivel A42), puesto que una de las
funciones del Datacenter es generar proyectos a través de la detección de
oportunidades.
Fig.V.23: Nivel A4, Producción y Entrega de un Servicio.
La Producción de Servicios (A41), es la actividad que realiza las funciones
propiamente tal del Datacenter en cuanto a dar la provisión continua de servicios
TI, esto significa que bajo el, se encuentran actividades que tienen como fin operar
en servicios 7x24, asegurando que no existan caídas de servicios u otros
incidentes que afecten los SLAs de cada cliente.
83
Fig. V.24: Nivel A42, Generación de Proyectos.
La producción de los Servicios del Datacenter queda como lo muestra la
siguiente figura, donde se pueden observar los subprocesos Gestión de Tickets,
Operaciones, Informes, Infraestructura, Ingeniería y Producción.
Cada uno de ellos comprende diferentes actividades propias de la
producción de servicios de TI de un Datacenter, y a la vez constituyen el soporte
de segunda y tercera línea, respondiendo requerimientos que vienen desde
Gestión de la Producción.
84
Fig. V.25: Nivel A41, Producción de Servicios.
En la figura anterior se pueden observar los subprocesos Gestión de
Tickets, Operaciones, Informes, Infraestructura, Ingeniería y Producción, con sus
respectivas interacciones.
El subproceso de Infraestructura (Nivel A414), cumple las siguientes
actividades:
• Observar todo lo que entra o sale del TIC.
• Control de acceso de personas.
• Control de acceso técnico.
• Determinar la distribución de equipos en la sala.
• Implementación Sistemas Aire y Clima.
• Habilitación energética de los Racks.
• Monitoreo de Fallas.
• Modificaciones en Sala.
• Responder a requerimientos de Ingeniería.
85
• Registro de Datos en Bitácora.
• Respuesta a requerimientos de clientes (Phelps Dodge y Chiquita
Chile).
• Interacción de Operaciones. El subproceso de Ingeniería (Nivel A415) tiene las siguientes actividades: • Administración de Servidores UNIX, Linux, Solaris, Hp.
• Respuesta a reclamos.
• Administrar Sistemas Operativos (Windows 2000, etc.).
• Gestión de Aplicaciones.
• Soporte a Clientes.
• Ejecutar Respaldos.
• Gestión de Incidentes.
• Validación.
• Administración asignación de clientes por plataformas.
• Recepción de información de Monitoreo.
• Configuración y respuesta de correos a Operaciones.
• Generación de Informes de Incidentes para Service Manager y Account
Manager.
• Recepción Propuestas Gerencia de Proyectos.
El subproceso de Operaciones (Nivel A412) tiene las actividades:
• Monitoreo (Hp Openview, Whatsup, Nagios).
• Gestión de Remedy.
• Respaldos en DataProtector y Legato Networker.
• Configuración de Correo (Máquina Gandalf): lo que comprende
configuración de casillas, habilitación de páginas, habilitación de
webmail, administración delegada).
• Habilitación DNS.
• Solicitudes Operaciones TIE19 (Webhosting, WebUNIX, Win, Correo).
19 TIE: Telefónica Internet Empresas, Ärea de Telefónica Chile que se preocupa de las comunicaciones de clientes y de distintas unidades de la organización.
86
• Respuesta Requerimientos SISON20.
• Respuesta Solicitudes Cliente.
• Realización de Informes Mensuales para Clientes, Servicios Housing.
20 SISON: Sistema de Oportunidades de Negocio interno de Telefónica Chile.
87
CAPÍTULO VI: DEFINICIÓN DE APOYO COMPUTACIONAL
VI.1 Lógica de Interfaz Usuario
La lógica de interfaz usuario entrega la forma en como serán desplegados
los requerimientos http de los usuarios, enviando como respuesta una página
HTML. Básicamente, se desplegarán 3 tipos de página, una de ingreso donde se
cargarán datos, otra de respuesta, donde se mostrarán opciones de ingreso de
información de segundo nivel, y una tercera, que será el despliegue final de la
resolución de ingreso de requerimientos y/o información de proyectos.
VI.2 Lógicas del Sistema
VI.2.1 Lógica de Verificación Usuario
Para que un usuario pueda acceder al Sistema, primero debe
autenticarse, esta lógica, será considerada como Verificación de Usuario. Y se
puede observar en la siguiente figura.
Si //Cliente no está registrado Entonces Mensaje de bienvenida informando que debe ingresar nombre usuario como login. Desplegar formulario de registro Digita datos cliente, login y password Sino //Cliente está registrado Ingresar login y password Si (password=OK) Entonces Lógica Autenticación = OK_usuario Sino Pedir password por 2° vez Si (2° password = OK)
88
Entonces Lógica autenticación = OK_usuario Sino Rechazar requerimiento
Fig. VI.1: Lógica verificación cliente.
VI.2.2 Lógica de Clasificación, Priorización, Optimización, y Asignación de Requerimientos
La lógica de negocio se divide en cuatro partes. La primera, que es la
clasificación de los requerimientos, y se realiza con las recomendaciones del
estándar ITIL. La segunda, que es la priorización, calculada a partir del tiempo req.
(tpo. necesario para solucionar un req.). La tercera, que es la optimización
(minimiza el tiempo de solución de requerimientos, a través de una eficiente
asignación a los recursos disponibles). La cuarta y final, es la asignación del
requerimiento al recurso que asegure un menor tiempo de resolución.
Las mejoras que se pueden obtener, se observan en los resultados
arrojados por la simulación de él en el software Arena (Figs. VI.3 y VI.4), utilizando
los cinco tipos de requerimientos más frecuentes presentados históricamente.
La forma en que se realiza la asignación en la simulación, es explicada en
la lógica mostrada en la Fig. VI.2.
Si //Cliente ingresa requerimiento Entonces Recibir clasificación requerimiento Recibir tiempo de solución requerido Ejecutar cálculo de prioridad Asignar valor prioridad Calcular tiempo de ocupación de cada recurso Asignar valor tiempo de ocupación a cada recurso Calcular tiempo disponible de cada recurso Ordenar recursos de mayor a menor tiempo disponible Asignar requerimiento a recurso con menor tiempo disponible
Fig. VI.2: Lógica asignación requerimientos.
89
A continuación se presentan las imágenes de la simulación. (Figs. VI.3 y
VI.4)
Fig. VI.3: Vista General Simulación del Modelo en Arena.
Fig. VI.4: Simulación del Modelo en Arena.
90
En las Figs. VI.3 y VI.4 se puede ver la simulación del modelo en Arena, la
que se realizó tomando los tiempos de solución promedio de los 5 requerimientos
más frecuentes que se presentan en el Datacenter, los que son mostrados en la
Tabla VI.1.
Tipo Tiempo de Solución [min]
Tipo 1 10
Tipo 2 25
Tipo 3 40
Tipo 4 60
Tipo 5 90 Tabla VI.1: Tiempos de Solución Promedio Requerimientos más frecuentes.
Tipo Cantidad [unid]
Tipo 1 440
Tipo 2 528
Tipo 3 660
Tipo 4 770
Tipo 5 858
Total 3.256 Tabla VI.2: Cantidad de Requerimientos Mensuales por Tipo.
Tiempo Promedio Total [hr] Tipo
Actual Modelo Tipo 1 3,1550 2,5461 Tipo 2 5,5719 3,7218 Tipo 3 6,5402 6,0591 Tipo 4 9,8186 6,9350 Tipo 5 11,6067 8,3377
Tabla VI.3: Tiempo Promedio en cola por tipo de requerimiento.
Situación Tiempo Total de Proceso [hr]
Actual 158,85
Propuesta 131,35
% Disminución de Tiempo 17,83% Tabla VI.4: Tiempo de Solución de los 3.256 requerimientos al mes, por los 22 receptores.
A partir de los datos de las tablas VI.1 y VI.2, tomados de los archivos
históricos del Datacenter, y la aplicación de ellos en el modelo de simulación en
Arena, se generaron los tiempos de la Tabla VI.3, los cuales muestran en dos de
91
sus columnas, la demora promedio en cola por tipo de requerimiento, lo que
generó los resultados presentados en la Tabla VI.4, donde se muestra que el
modelo, genera una reducción de tiempo de un 17,83%, es decir, redujo el tiempo
de solución de los requerimientos mensuales comparado con lo que sucede
actualmente.
Además, se debe categorizar y priorizar un requerimiento, lo que se hará
con indicaciones de prácticas ITIL, explicadas a continuación.
La prioridad es el valor dado a un incidente para indicar su importancia
relativa, con el objetivo de asegurar la adecuada asignación de recursos y para
determinar el intervalo de tiempo en el que se requiere una acción.
La prioridad indica el orden o secuencia de atención, relacionado con la
importancia o criticidad de un incidente. Esto permite priorizar los recursos para el
tratamiento de incidentes.
La prioridad con la que un incidente necesita resolverse, y por consiguiente
el esfuerzo que se ponga en la resolución y recuperación, dependerá de:
- El impacto: medida del efecto sobre el negocio que un incidente tiene
actualmente o podría tener potencialmente.
- La urgencia: medida de la criticidad de un incidente, en función de las fechas
límites para su resolución que fueron pactadas con el negocio. Puede identificarse
con el tiempo disponible para la resolución, y se puede establecer mediante la
estimación del tiempo necesario para la resolución.
- El esfuerzo técnico estimado: depende del ámbito y complejidad técnica del
incidente, y de los recursos necesarios para su solución mediante “work-arounds”
disponibles, o soluciones definitivas.
92
VI.2.2.1 Tabla de Prioridades La prioridad de un requerimiento se establece combinando el Impacto y la
Urgencia. Los tiempos de resolución deben establecerse en los Acuerdos de
Niveles de Servicio (SLA).
La siguiente tabla muestra el impacto asociado a un requerimiento.
Tabla VI.5: Cuantificación de Impacto según tiempo de resolución requerido.
Las horas se refieren a tiempo efectivo de trabajo realizado. Si la jornada es
de 8 hrs., las 24 hrs. Podrían significar 3 días de trabajo.
VI.2.2.2 Lista de umbrales basada en prioridades La lista de umbrales es un ejemplo de cómo se deben escalar los
requerimientos. Las reglas de escalado se detallan en el anexo de “Reglas de
Escalado”.
Prioridad Tiempo de
Resolución Umbrales de Evaluación
Umbral superado
Crítica 4 horas > 0,5 hrs. y < 3,5 hrs. Ver reglas de escalado
Alta 8 horas > 4 hrs. y < 7 hrs. Ver reglas de escalado
Media 24 horas > 8 hrs. y < 16 hrs. Ver reglas de escalado
Baja 48 horas > 24 hrs. y < 36 hrs. Ver reglas de escalado
Tabla VI.6: Umbrales basados en prioridades.
IMPACTO
Prioridad /Tiempo de resolución
Alto Medio Bajo
Alta Crítico /< 4 hrs. Alto /< 8 hrs. Medio /< 24 hrs.
Media Alto /< 8 hrs. Medio /< 24 hrs. Bajo /< 48 hrs.
URGEN
CIA
Baja Medio /< 24 hrs. Bajo /< 48 hrs. Planificar / Cuando se planifique
93
VI.2.2.3 Clasificación o Categoría de un incidente
La clasificación tiene como objeto identificar formalmente el requerimiento
en base a su origen, sus síntomas y causa (si es detectada), lo que permitirá
relacionarlo con un error conocido o asociarlo a un problema. Esto resultará
fundamental para la comparación automática del incidente frente a las bases de
datos de problemas y errores conocidos.
En base a los síntomas se hará una distinción entre la categoría inicial o de
entrada, y la final o de cierre, basada en la causa real. Asimismo, el requerimiento
podrá ser reclasificado hasta su cierre a lo largo de su ciclo de vida.
En el momento del cierre, es necesario revisar la categoría o tipificación
final de los requerimientos, ya que esta información es clave para:
• Asociar el incidente con el Elemento de Configuración (CI - Configuration Item)
afectado (utilizando para ello la CMDB).
• Facilitar la identificación de los incidentes.
• Disponer de estadísticas fiables.
94
El listado de clasificación de requerimientos es el siguiente:
Clase Sub clase
Instalación / Configuración
Rotura
Factor Humano
Hardware
Funcionalidad
Inconsistencia / Corrupción
Rendimiento /Bloqueos
Software
Factor Humano
Servicios internos
Defecto de fabricación hardware
Bug Red Corporativa
Causa ajena a TI
Otras compañías Grupo
Desconocida
Puesta en Producción Tabla VI.7: Clasificación de requerimientos.
95
VI.2.2.4 Roles y Responsabilidades
Rol Es responsable de
Análisis de causa raíz
Prevención de incidentes y problemas
Administrador de Problemas
Análisis de tendencias
Administrador de Soporte Técnico
Soporte técnico y mantenimiento de Equipo Central, Servidores, Sistemas Operativos, etc.
Incluye el rol del Help Desk
Integración de los procesos del negocio con la infraestructura de la administración de servicios
Administrador de Service Desk
Realiza actividades de varios procesos ITIL no solamente del proceso de incidentes
Administrador de Cambios, Configuraciones y Release
Teniendo un administrador combinado de CCR, los aspectos requeridos en el rol se pueden hacer por una persona, mientras que las actividades del día a día pueden ser desarrolladas por otras personas
Administrador de Pruebas ITIL define la necesidad de una función de pruebas (testing) independiente, pero no especifica en dónde deberá ser desempeñada dentro de la estructura. El lugar más adecuado es dentro de los servicios de entrega (Service Delivery) ya que de esta forma es independiente de las construcciones de cambios y de la función de Release. Sin embargo en pequeñas organizaciones se combina con la administración de Release.
Administrar los SLAs y OLAs
Definir los Servicios de TI
Administrar los Proveedores
Administrador de Niveles de Servicio
Administrar las relaciones con los clientes
Administrador de Disponibilidad y Capacidad
Considerar el tamaño de la Infraestructura de acuerdo a las necesidades del negocio (ITIL asigna la responsabilidad de estar actualizado con las nuevas tecnologías en el rol de la Administración de Capacidad, pero algunas organizaciones grandes tienen para esta actividad el rol del Arquitecto Técnico)
Administrador de Continuidad de Servicios TI
Este rol tiene la responsabilidad de la Continuidad de los Servicios TI pero debería ser parte del Equipo de Continuidad del Negocio de la organización. En pequeñas organizaciones puede ser combinado como se describió anteriormente con la Administración de Disponibilidad y Capacidad. Este rol puede ser combinado con un rol de Seguridad, particularmente si la organización está buscando la certificación en seguridad (ej: BS7799).
Administrador Financiero de TI
En algunas organizaciones este rol reporta directamente a la cabeza de TI, y además incluye toda la responsabilidad de la planificación y administración financiera de los grupos de desarrollo.
Tabla VI.8: Asignación de Responsabilidades Procesos ITIL.
96
La Tabla VI.8 muestra la asignación de responsabilidades a ciertos roles
creados dentro de la organización, los que responden a necesidades proactivas y
reactivas de los subprocesos ITIL, con lo que se estructuran las responsabilidades
dentro de la organización, según lo recomendado por las mejores prácticas de
mercado.
A continuación (Tabla VI.8), se define la Matriz RACI específica para el
proceso de Gestión de Incidentes, donde existen roles específicos que deben
cumplir con ciertas tareas ante la presentación de requerimientos que sean
incidentes, es decir, que signifiquen que el servicio normal ha dejado de estar en
régimen normal o podría dejar de hacerlo.
GESTIÓN DE INCIDENTES – MATRIZ RACI Proceso de Gestión de Incidentes
COD ACTIVIDADES ROLES
Agente
CSU (Service
Desk)
Técnicos
de
de
Soporrte (Niveles 1, 2 y
3)
Gestor del P
roceso de
Gestión de In
cide
ntes
Responsable
Proceso
Gestión Inciden
tes
Gestor
de
CSU
(Service Desk)
Gestor de Cambios
Reponsable
del
proceso
GestIón
de
Problem
as
Adm
inistrador
Gestión
Incidente
Gestor
Nivel
de
Servicio
Director de Explotación
CSU (Service Desk)
1 Registro de Contacto R 2 Clasificación y Soporte Inicial R R C/I I 3 Asignación y Escalado R R I 4 Resolución Incidente R/I R C/I C/I C/I I 5 Comprobación Usuario R 6 Reabrir Incidente R C/I I 7 Cierre Contacto R 8 Solicitud Servicio R 9 Seguimiento de Gestión Incidentes A/R Gestión de Incidentes Niveles 2 y 3 10 Investigación y Diagnóstico R C/I C/I 11 Aumentar Soporte (Escalada Funcional) R C/I A 12 Comunicar Situación (Escalada
Jerárquica) I C R A R C/I I C/I
Gestión de Mejora del Proceso de Gestión de Incidentes 13 Auditoría Periódica R A R I 14 Captura de Indicadores A/R A/R R 15 Análisis de Valores Obtenidos C C R I R 16 Generción Informes R A/C R 17 Distribuir Informes I A/R I I I I I I 18 Análisis de Resultados C C R C R 19 Tratar Conclusiones C C R A R C C C C 20 Propuestas de Mejoras C C R A R I I C I I 21 Ejecutar Mejoras R R R A R R R R R I R = Responsable directo de realizar/ejecutar la tarea. A = Responsable último o indirecto, puede delegar, debe supervisar. C = Consulta antes de hacer. I = Informa después de hacer
Tabla VI.8: Roles y Responsabilidades de Requerimientos.
97
CAPÍTULO VII: DEFINICIÓN DE CASOS DE USO
Fig. VII.1: Casos de Uso.
En la Fig. VII.1 se observan los casos de uso que representan las acciones
a realizar por la aplicación a crear en el Marco del Rediseño de Procesos del
Datacenter de Telefónica Empresas en función de Normas ITIL. Esta aplicación
tiene como función principal el apoyo de la Gestión de Atención a clientes,
permitiendo automatizar la petición de requerimientos de ellos. Entre estos
requerimientos se encuentran: el reporte de incidentes, consulta de monitoreo de
aplicaciones, y verificación del estado de requerimientos. Además, por el lado de
los trabajadores del Datacenter, permite verificar qué requerimientos han sido
asignados y actualizar el estado de ellos.
Por lo tanto, según se observa en la Fig. VII.1, el primer caso de uso es el
de Ingreso y Procesamiento de requerimiento, el cual incluye realizar otros casos
de uso, los cuales son Clasificación de Requerimientos, Cálculo de la Prioridad de
ellos y Asignación de Requerimientos.
El Caso de Uso N°2 es el Ingreso de Requerimiento de Informe, en el que la
aplicación mostrará automáticamente, según el perfil de cliente y los servicios
contratados por este, un informe del estado de aplicaciones en los servidores del
Datacenter.
El Caso de Uso N°3 es la verificación de estado de requerimientos, la cual
98
es llevada a cabo por un trabajador del Datacenter.
El Caso de Uso N°4 es la actualización del estado de requerimientos, por
parte de un trabajador del Datacenter.
99
CAPÍTULO VIII: DIAGRAMAS DE SECUENCIA DE SISTEMA
VIII.1 DSS Escenarios Caso de Uso Ingreso y Procesamiento de Requerimientos
VIII.1.1 DSS Escenario Ingreso y Procesamiento de Información de Proyectos
Fig. VIII.1: Diagrama de Secuencia Ingreso y Procesamiento Información Proyectos.
El Ingreso y Procesamiento de Información se refiere a cuando el usuario
del sistema, ingresa a él, enviando nuevos datos de un determinado proyecto, los
cuales al ser ingresados, permite que los indicadores asociados a él se actualicen
guardando la información en la base de datos correspondiente. Además, si se
100
necesita anexar campos de ingreso de información, se abre una nueva pantalla
con las opciones correspondientes a estas.
VIII.1.2 DSS Escenario Ingreso y Procesamiento de Requerimientos
Fig. VIII.2: Diagrama de Secuencia Ingreso y Procesamiento de Requerimientos.
El Ingreso y Procesamiento de Requerimientos, como se ve en la Figura
VIII.2, es el escenario que se presenta cuando un usuario, tanto interno como
externo a la organización, necesita reportar un cierto requerimiento, como puede
ser un incidente, problema, solicitud de cambios o de servicios en general. Para
esto, el usuario que accede al Sistema, luego de ingresar su nombre y password,
accede a una página de ingreso de requerimientos, los que son posteriormente
101
procesados, clasificados, y priorizados, para luego asignar a un responsable del
requerimiento, que le dará una solución o escalará el problema según el
procedimiento adecuado.
VIII.1.3 DSS Escenario Ingreso y Procesamiento Información CMDB
Fig. VIII.3: Diagrama de Secuencia Ingreso y Procesamiento Información CMDB.
El Escenario de Ingreso y Procesamiento de Información de la CMDB, o
Base de Datos de Artículos de Configuración, se produce cuando un usuario
interno requiere ingresar información de algún artículo de configuración (CI), para
lo cual luego de autenticarse, accede a una página que le permite ingresar
información en un formato preestablecido. Luego de esto, el sistema se encarga
102
de separar la información, actualizar indicadores de la CMDB, y guardarla en la
base de datos respectiva, haciendo que quede disponible en el repositorio
principal.
VIII.2 DSS Escenarios Caso de Uso Verificar Información
VIII.2.1 DSS Escenario Verificar Información Proyectos
Fig. VIII.4: Diagrama de Secuencia Verificar Información Proyecto.
En el escenario Verificar Información de Proyectos, mostrado en la Fig.
VIII.4, un usuario interno o externo, puede verificar información referente a un
determinado cliente, en un formato preestablecido para esto, el que permite
mostrar directamente a clientes o a usuarios internos, información que no es de
exclusivo uso interno, sino que puede ser vista por ciertas personas autorizadas
tanto internas como externas.
103
VIII.2.2 DSS Escenario Verificar Información Requerimiento
Fig. VIII.5: Diagrama de Secuencia Verificar Información Requerimiento.
En el escenario verificar información de requerimiento, un usuario interno o
externo, luego de autenticarse, accede a una página con opciones de despliegue
de información acerca de un determinado requerimiento, pudiendo obtener el
estado de él, y la asignación que fue realizada.
104
VIII.2.3 DSS Escenario Verificar Información CMDB
Fig.VIII.6: Diagrama de Secuencia Verificar Información CMDB.
En el escenario Verificar Información de la CMDB, un usuario interno o
externo autorizado, puede acceder a ver información de los diferentes artículos de
configuración ingresados (CI´s), con lo que, después de una primera página de
validación de usuario, se llega a otra que muestra opciones de despliegue de
búsqueda de CI´s, para luego enviar la información solicitada al usuario.
105
VIII.3 DSS Escenarios Caso de Uso Actualizar Información
VIII.3.1 DSS Escenario Actualizar Información de Proyectos
Fig. VIII.7: Diagrama de Secuencia Actualizar Información de Proyectos.
Como de ve en la Figura VIII.7, el Escenario Actualizar Información de
Proyectos, se produce cuando un usuario interno o externo, según el perfil definido
previamente, y luego de acceder al sistema, con su nombre de usuario y password
106
registrado, ingresa las opciones de búsqueda de información de un proyecto, con
lo que se envían los registros encontrados, con opciones de modificación en una
página que trae un formato de ingreso de información, para que una vez que se ha
ingresado la información de actualización, esta sea guardada en la CMDB.
VIII.3.2 DSS Escenario Actualizar Información de Requerimiento
Fig. VIII.8: Diagrama de Secuencia Actualizar Información de Requerimiento.
En el Escenario Actualizar Información de Requerimiento (Fig. VIII.8), un
usuario ingresa al sistema, para entrar a una página con opciones de búsqueda de
información de requerimientos, luego de que se encuentra el registro a actualizar,
se ingresa la información en una segunda página, la que hace que el sistema
actualice las variables asociadas al requerimiento.
107
VIII.3.3 DSS Escenario Actualizar Información de CMDB
Fig. VIII.9: Diagrama de Secuencia Actualizar Información de CMDB.
La Figura VIII.9, muestra cuando un usuario interno y externo (según su
perfil), accede al sistema actualizando información de la CMDB, por ejemplo,
cambiando el estado de un determinado CI, o ingresando uno nuevo, luego de
esto, el sistema actualiza indicadores de CI en la base de datos, e informa al
usuario de que su actualización fue exitosa.
108
CAPÍTULO IX: DIAGRAMAS DE SECUENCIA
IX.1 Diagrama de Secuencia para caso de uso “Ingreso y Procesamiento de Requerimientos
Fig. IX.1: Diagramas de Colaboración entre Clases para Ingreso y Procesamiento Req.
La Fig. IX.1 muestra el diagrama de colaboración entre clases para el caso
de uso “Ingreso y Procesamiento de Requerimientos”, donde un usuario ingresa al
sistema, y al registrar un determinado requerimiento, el sistema lo clasifica,
consulta los sla comprometidos para este, analiza las responsabilidades, para
priorizar y asignarlo posteriormente, guardando la información de esta acción en la
base de datos, asignándole un número identificador con el que el usuario externo
o interno puede realizar el seguimiento de él, viendo en qué estado se encuentra.
109
IX.2 Diagrama de Secuencia para caso de uso “Ingreso y Procesamiento Información”
Fig. IX.2: Diagramas de Colaboración entre Clases para Ingreso y Procesamiento Información. La Figura IX.2 muestra el Diagrama de Colaboración entre Clases para el
Caso de Uso “Ingreso y Procesamiento de Información”, donde un usuario interno
o externo, dependiendo de su perfil, puede ingresar información de artículos de
configuración o de proyectos, donde las páginas de ingreso, dan la opción de
ajustar el formato de la información, permitiendo al sistema guardar ésta en las
entidades respectivas.
110
CAPÍTULO X: DIAGRAMAS DE CLASES
X.1 Diagrama de Clases para Ingreso y Procesamiento Requerimiento
Fig. X.1: Diagrama de Clases para Ingreso y Procesamiento Req.
111
X.2 Diagrama de Clases Ingreso y Procesamiento Requerimiento
Fig. X.2: Paquete de Clases Ingreso y Procesamiento Requerimiento.
112
CAPÍTULO XI: DISEÑO DETALLADO DE LA APLICACIÓN
En este capítulo se presenta las imágenes de la solución diseñada en
términos de la arquitectura tecnológica de soporte y las pantallas desarrolladas
para el piloto.
XI.1 Arquitectura Tecnológica
Fig. XI.1: Arquitectura Tecnológica de la Solución.
La Figura XI.1 muestra la arquitectura tecnológica de la solución, alojada en
un Servidor ubicado en el Datacenter de Telefónica Empresas, que se beneficiará
de la red de alta disponibilidad que dispone este proveedor de servicios de TI, ya
que, tiene 2 Switch 3560 y 2550, conectados a su vez a 2 Firewall Netscreen en
paralelo, brindando la seguridad de disponibilidad de la información que se busca.
A su vez, el servidor ocupado para la aplicación se conecta a una unidad de
Storage, la que permite tener a través de la segunda tarjeta de red de la máquina,
respaldos automáticos generados por el software Legato Networker. La forma de
respaldar la información se hace de la siguiente forma: incrementales diarios, full
semanal, histórico mensual, esto se guarda en cintas, medio magnético que es
almacenado en librerías del Datacenter, asegurando la integridad de la
113
información.
XI.2 Páginas de la Aplicación
A continuación se presentan las imágenes de las páginas que constituyen la
aplicación diseñada, cuya navegación será explicada a través del esquema
presentado en la Figura XI.2.
Fig. XI.2: Esquema de Navegación Aplicación.
Según muestra la Figura XI.2, las páginas que tiene la aplicación son las
siguientes:
• Inicio.html (Fig. XI.3): Es la página con la cual se accede al Sistema de
Gestión de Requerimientos, y dependiendo del perfil de usuario, se deriva a
la página menu.jsp.
114
• Menu.jsp (Fig. XI.4): Contiene el menú principal del sistema, brindando
tres opciones al usuario: gestión de requerimientos, información de
inventario o de proyectos.
• Menusgi.jsp (Fig. XI.5): Es la página que contiene las opciones de
información de gestión de inventario, en ella se puede buscar información
de un CI21 existente, o ingresar información de un nuevo CI.
• Buscarci.jsp (Fig. XI.6): Página con opciones de búsqueda de CI.
• Ingresarci.jsp (Fig. XI.7): Página con opciones de ingreso de información
de un nuevo Ci, con lo que se actualizan indicadores.
• ci.jsp (Fig. XI.9): Muestra un registro de CI encontrado, brindando opciones
de ver otros artículos de configuración relacionados a él.
• conec.jsp (Fig.XI.10): Muestra artículos de configuración relacionados
entre sí, con flechas que permiten ver más CI conectados en la serie
respectiva.
• menureq (Fig. XI.11): Es la página que contiene opciones de ingreso de
nuevo requerimiento, o buscar información de uno ya ingresado.
• ingresanreq.jsp (Fig. XI.12): Página que provee opciones de ingreso de un
nuevo requerimiento.
• reqing (Fig. XI.13): Muestra el número de requerimiento ingresado, el cual
puede ser usado posteriormente para realizar un seguimiento del estado de
él.
21 CI: Configuration Item, o artículo de configuración.
115
• verificaestador.jsp (Fig. XI.14): Página con campos de opciones de
búsqueda de requerimientos.
• listarreq.jsp (Fig. XI.15): Contiene los requerimientos encontrados
posteriores a una búsqueda.
• req.jsp (Fig. XI.16): Página con registro encontrado.
• menuip.jsp (Fig. XI.17): Página con opciones de búsqueda de información
de proyectos.
• buscarinfo.jsp (Fig. XI.18): Contiene opciones de búsqueda de
información de proyectos.
• ingresainformacion.jsp (Fig. XI.19): Página con campos de texto que
permiten el ingreso de información de un nuevo proyecto.
• registroencontrado.jsp (Fig. XI.20): Contiene un registro encontrado de
información de proyectos.
• actualizar.jsp (Fig. XI.21): Brinda al usuario la posibilidad de actualizar o
modificar información de proyectos ya existente.
A continuación se presentan las pantallas de las páginas que fueron
explicadas anteriormente.
116
Fig. XI.3: Página inicio.html
Fig. XI.4: menu.jsp
117
Fig. XI.5: Página menusgi.jsp
118
Fig. XI.6: Página buscarci.jsp
119
Fig. XI.7: ingci.jsp
120
Fig. XI.8: Página listarci.jsp
121
Fig. XI.9: Página ci.jsp
122
Fig. XI.10: Página conec.jsp
123
Fig. XI.11: Página menureq.jsp
124
Fig. XI.12: Página ingresarnreq.jsp
125
Fig. XI.13: Página reqing.jsp
126
Fig. XI.14: Página verificarestador.jsp
127
Fig, XI.15: Página listareq.jsp
128
Fig. XI.16: Página req.jsp
129
Fig. XI.17: Página menuip.jsp
130
Fig. XI.18: Página buscarinfo.jsp
131
Fig. XI.19: Página ingresarinformacion.jsp
132
Fig. XI.20: Página registroencontrado.jsp
133
Fig. XI.21: Página actualizar.jsp
134
CAPÍTULO XII: IMPLEMENTACIÓN ORGANIZACIONAL DE LOS PROCESOS DE CAMBIO Y LAS ESTRUCTURAS DE APOYO
En el presente capítulo, se presenta la forma en que fue diseñada la
implementación del proyecto en Telefónica Empresas, específicamente en la
Subgerencia Datacenter, perteneciente a la Gerencia Outsourcing y Datacenter.
Se comenzará con la gestión del cambio organizacional, donde se estudian
las fuerzas que determinarán el éxito o fracaso del proyecto.
Para finalizar, se presentan los resultados de las pruebas de conceptos
dentro del marco ITIL realizadas a los usuarios del sistema.
XII.1 Gestión del Cambio
A continuación se explica cómo se pretende enfrentar la Gestión de
Cambio, en el marco del desarrollo del proyecto “Rediseño de Procesos del
Datacenter de Telefónica Empresas en función de Prácticas ITIL”, el cual pretende
realizar un Automatización en la Gestión de Requerimientos de clientes, además
de otras funciones como, permitir la Gestión de Información y de Inventario.
Esencialmente la realización de un Plan de Cambio para un proyecto de
implementación de tecnologías de información, significa preocuparse de todas las
variables que rodean principalmente, la ejecución propia del proyecto, como
estados de ánimo de la unidad en la que está inmersa, tipos de liderazgo que
intervienen, mapas de poder que denotan la forma en que se dirigen los proyectos,
y todos aquellos aspectos que pueden ser factores de éxito o fracaso en la
implementación.
135
XII.1.1 Descripción de la situación actual
Lo que lo que se desea cambiar, es la forma de gestionar el inventario, la
asignación de requerimientos, y la información de proyectos. Este cambio,
involucra la forma de compartir la información, que hasta el momento, para los
aspectos específicos de cada proyecto, es manejada por cada uno de los
responsables.
En lo que existe incertidumbre, con respecto al desarrollo del proyecto es
que las nuevas prácticas sean adoptadas por las personas que le pueden dar vida
al sistema que se está diseñando, ya que si no se da la aceptación por parte de
todos con respecto a esto, habrá información faltante, lo que significa que el
sistema pierda fiabilidad e integridad. Para que esto no suceda, se deben trabajar
las variables de cambio respectivas, que puedan estar incidiendo en la
implementación de él, y posterior puesta en marcha. La incertidumbre
anteriormente descrita, tiene que ver con una característica bastante fuerte que se
presenta en la unidad, y es que al ser personas que saben mucho de aplicaciones
y de TI en general, hay un sentimiento de que ya se tiene el conocimiento de todos
los detalles que hacen falta en la organización, por lo tanto, no colaboran con las
nuevas ideas, es ese el ámbito que debe ser atacado por el plan de cambio, ya
que es crítico para la ejecución del proyecto.
También existen personas que son las que influencian a las demás en
cuanto a lo buena que es una idea, y es a ellos a los que se debe prestar más
atención, para que exista un convencimiento de los beneficios que se pueden
alcanzar, lo que podría generar “conversaciones de pasillo” favorables.
XII.1.2 Análisis de los factores
Según Kaizen, una estrategia empresarial debería ser, la acción sistemática
a largo plazo destinada a la acumulación de mejoras y ahorros, con el objeto de
superar a la competencia en niveles de calidad, productividad, costos y plazos
136
de entrega, esto en sí, es la esencia de lo que postula el proyecto de Rediseño de
procesos en función de las mejores prácticas de mercado.
Como observación de la organización y distribución de los roles para el
proceso de cambio, se tiene un líder del Proyecto, Pablo Rodríguez, y hay una
coalición conductora formada por la Gerente del Área Outsourcing y Datacenter de
la Vice Presidencia (VP) de Empresas de Telefónica Chile, el Gerente Comercial
de la misma VP, y un equipo de cerca de 5 personas que entregan las directrices
del Proyecto ITIL en todas las VP de Empresas de Latinoamérica, desde la Casa
Matriz de la Corporación, que está en España. Además, se tiene un equipo de
trabajo estable, el que cuenta una persona implementadora de la herramienta, el
Jefe de Servicios del Datacenter, y una Analista que alinea el proyecto con otro de
calidad que se está ejecutando en forma conjunta, que es el de la ISO 27001. En
general, existe bastante apoyo al proyecto, ya que sigue la corriente de nivel
latinoamericano en cuanto a directrices, pero la implementación en cada uno de
ellos puede diferir bastante.
Es por esto, que según “El Monstruo del Cambio” y los Círculos que
propone (Vicioso y Virtuoso), se pueden inferir bastantes observaciones del
proceso que se está viviendo, como las siguientes:
- Colaboración Efectiva: Dentro de esta dimensión, las diferencias culturales que
hacen aspirar al aprendizaje mutuo se dan en la unidad, a veces para bien y otras
para mal, debido a que la mayoría de las personas tienen un perfil técnico
orientado a ejecutar las tareas del día a día, y el hacer gestión, o intentar ejecutar
un proyecto de mayor valor agregado, puede significar ser “extraño” dentro del
ambiente, comenzando a circular la pregunta “y para qué sirve esto”. Pero si la
situación es tomada de la debida forma, se podrá avanzar y aprovechar las
diferencias para analizar el problema desde varios puntos de vista. Esto, podría
ser la clave para generar una mayor confianza en el proyecto, y en el ejecutante,
lo que derivaría en tener colaboración efectiva entre las partes, que se traduce
finalmente, en la concepción de que existen objetivos comunes, que conducen a
137
una estructura clara, mediante una relación profunda. Esto es, esencialmente lo
que se ha realizado en el proyecto, y el ámbito de intervención será explicado con
más detalle en el siguiente punto.
- Colaboración No Efectiva: Si llegara a existir una estructura poco clara, falta de
objetivos comunes, y con competencia entre las partes, podría traducirse en que
las diferencias entre las personas sean percibidas como amenazas, con la
consiguiente desconfianza que eso generaría, pudiendo llevar esto a no alcanzar
los resultados. Durante la ejecución del proyecto, se percibe que estas variables
han sido controladas, estando dentro del círculo virtuoso.
XII.1.3 Visión
El logro de los objetivos planteados para este proyecto, permite cambiar la
forma de compartir la información en la organización, quedando esta donde
realmente debe estar, que es en la empresa. Esto a su vez, genera eficiencia
operacional, y valor al negocio, pudiendo revertir burocracias históricas de la
unidad.
A la vez, el contacto con el cliente tendrá nuevos canales para generar
requerimientos, lo que hará disminuir la confusión que se da cuando hay poca
claridad en la fecha y hora de la asignación.
XII.1.4 Interpretación de la situación
La resistencia al cambio, se presenta principalmente por una lucha de poder
dentro de la unidad donde se está realizando el proyecto, debido a que la
presencia de algunos elementos que influyen en la opinión de los otros es muy
importante, y quizás sea lo que ocurre comúnmente en una unidad de provisión de
servicios de tecnologías de información, donde el perfil de las personas que ahí
trabajan es de carácter técnico y acostumbradas a tareas del día a día, por lo que
138
un proyecto que pretende rediseñar procesos, es visto a primera instancia como
un invasor de la cultura predominante, sobretodo si este pasa a llevar algunas
ideas de los líderes de la unidad en cuanto a opinión.
El programa de mejora continua que se pretende implementar en la unidad,
permitirá tener la posibilidad de generar instancias de participación, en las que
todos puedan participar y sentirse parte del equipo de trabajo, abriendo la
posibilidad de tener mayor visibilidad en la empresa.
XII.1.5 Objetivos generales
En una Evaluación hecha en Mayo de 2005, la cual genera una apreciación
de la posición de los procesos del Datacenter con respecto a las mejores prácticas
(ITIL), para la industria de las tecnologías de información, estas actividades
tuvieron una evaluación de 3,1; siendo la escala de 0 a 6, donde el estar entre 5 y
6, es estar operando según lo que se debe hacer en este negocio para cumplir con
estándares de seguridad, aseguramiento de SLA con clientes, y programas de
mejoramiento continuo; es decir, funcionar según las necesidades de mercado.
Además, con el desarrollo de un Sistema de Control de Inventario, se
pretende reducir en al menos un 70% las pérdidas, y disminuir, con el módulo de
Información de Proyectos, en un 80% la No Disponibilidad de información.
XII.1.6 Objetivos específicos
Las acciones que se han realizado y las que se pretender efectuar para
conseguir los objetivos generales son las siguientes:
- Rediseño de Procesos según la metodología de patrones, asociando estos a las
mejores prácticas de mercado (ITIL).
- Capacitación del personal del Datacenter, en cuanto a ITIL, y los procesos
139
rediseñados.
- Conformación Grupo de Trabajo.
- Presentaciones en otras áreas de la empresa, con el fin de dar a conocer el
proyecto.
- Diseño de una Aplicación Computacional de apoyo a los nuevos procesos.
- Confección de Manual de Procesos y de Uso de la Aplicación.
XII.1.7 Factores críticos
Uno de los factores críticos con respecto a la ejecución del proyecto es el
porcentaje de personal capacitado y certificado en mejores prácticas, para esto se
están capacitando en grupos de 8 personas, esto es imprescindible para la
formalidad y entendimiento del proyecto, ya que genera un entendimiento mucho
más profundo por parte de las personas que deben trabajar con las aplicaciones
que se diseñarán, y también un estado de ánimo diferente, porque impulsa la
percepción de que la empresa invierte en las personas.
Otro factor crítico de éxito, es el entendimiento de los beneficios que
entrega el proyecto, para lo cual se pretende efectuar varias capacitaciones, y
hacer partícipes a los involucrados para que vean que sus opiniones son
consideradas en el desarrollo del proyecto.
140
XII.1.8 Poder
A continuación se muestra el mapa de poder asociado al proyecto y la
organización en la que está inmersa, que es Telefónica Empresas Chile.
Fig. XII.1: Mapa de Poder.
En la figura se pueden ver las relaciones que generan poder para el alcance
de los objetivos asociados al proyecto. El ejecutor del proyecto tiene una cercana
relación con su tutora y jefa directa, que es la Gerente de Outsourcing y
Datacenter, a la vez, existe una muy buena relación con uno de los Gerentes
Comerciales, quien era hasta hace unos meses el Gerente del Área donde está
inmerso el proyecto, a través de ellos de puede llegar hasta la Gerencia General,
lo que se ha hecho en reiteradas ocasiones, donde se han presentado los
beneficios del proyecto. Además, existe una estrecha relación con el Jefe de
Servicios del Datacenter, lo que permite generar llegada con las unidades del
mismo.
141
XII.1.9 Recursos
- Económicos: La capacitación de las personas tiene un valor de US$1.000 por
cada una, lo cual no tiene problemas debido a que estaba considerado en el
presupuesto del año pasado. Además de esto, se requiere comprar Hardware, lo
que tampoco presenta problemas, porque se utilizará espacio libre de Datacenter.
Por lo general, en el aspecto económico no hay problemas, debido a que existe
apoyo desde la Casa Matriz, gracias a la gestión de la Subgerente del Área, una
de los creadores del proyecto.
- Recursos Humanos: Se contratará 1 programador durante la etapa de
implementación y desarrollo de la herramienta, la que se estima dure 2 meses.
- Tiempo Dedicado: Las personas involucradas en la unidad Datacenter deberán
asistir a periódicas reuniones de capacitación, en las que se les explicará acerca
de mejores prácticas y de la nueva forma de operar en algunos sentidos.
142
XII.1.10 Plan de acción
Las etapas del proyecto se pueden ver en la siguiente figura:
Fig. XII.2: Plan de Acción.
En la Figura XII.2, se puede ver que la Ejecución de Proyectos y
Actividades en la Empresa está fijada desde Marzo hasta Octubre de 2006, donde
se pretende tener implementada la aplicación que se requiere. Además, se puede
visualizar la relación entre el proyecto ITIL y la Sección “Común a la Iniciativa”,
que es la planificación del proyecto corporativo de implementación de mejores
prácticas en la organización.
143
XII.2 Indicadores
Los indicadores de cumplimientos del proyecto, serán, como se había
explicado en la Sección XII.1.5 (Objetivos Generales), tener un nivel de evaluación
sobre 4,5 en una escala de 0 a 6, que es un checklist de qué actividades de las
mejores prácticas se están realizando y de qué forma se están ejecutando.
En cuanto a la Gestión de Inventario, se medirá la correcta inclusión de la
información de los artículos de configuración sobre los que se hará control, y se
pretende tener un ahorro sustancial en los costos que implican las continuas
pérdidas.
Por el lado de Gestión de Proyectos, las mejoras serán medidas según el
aumento de disponibilidad de la información, y de cálculo de indicadores
pertinentes para cada proyecto.
XII.3 Resultados Iniciales
La evaluación de la brecha inicial existente entre los procesos iniciales y las
prácticas ITIL, fue medida mediante un Formulario de Autoevaluación ITIL (Fig.
XII.3), la que consiste en una serie de 79 preguntas, las cuales fueron respondidas
por las personas claves de los procesos en el TIC. Esta Guía de Autodiagnóstico
permite realizar una valoración rápida de cómo se está desempeñando el trabajo
en comparación a lo que dicen las mejores prácticas de ITIL.
Esta guía también pretende:
� Provocar una reflexión sobre las actividades que realiza una Organización
de TI, y las posibles iniciativas de mejora que se pueden adoptar.
� Crear conciencia que una buena gestión y control es la base de la mejora.
� Impulsar una serie de iniciativas de evolución en las empresas.
144
Fig. XII.3: Herramienta Autodiagnóstico ITIL.
La figura anterior muestra la Herramienta de Autodiagnóstico ITIL que fue
usada, obteniéndose los siguientes resultados en Mayo de 2005 (Tabla XII.1).
Proceso Subproceso DC TE Mejores Prácticas GAP Mejores Prácticas [%]
Soporte de Servicios Cambios 2,90 4,50 35,56 Configuración 3,10 4,50 31,11 Incidencias 3,10 4,50 31,11 Problemas 2,50 4,50 44,44 Versiones 1,70 4,50 62,22
Total 2,60 4,50 42,22 Entrega de Servicio Capacidad 4,00 4,50 11,11 Continuidad 1,80 4,50 60,00 Disponibilidad 4,30 4,50 4,44 Gestión Financiera 3,90 4,50 13,33 Gestión del Servicio 3,70 4,50 17,78
Total 3,50 4,50 22,22
Valoración Total 3,10 4,50 31,11
Tabla XII.1: Resultados Autoevaluación ITIL Datacenter Telefónica Empresas Mayo 2005.
Como se observa en la tabla XII.1, el valor promedio obtenido es de 3,1
145
para el Datacenter de Telefónica Empresas, en una escala de 0 a 6, donde las
mejores prácticas ITIL están entre 4,5 y 6.
En el siguiente gráfico se muestra la relación de estos valores obtenidos, en
una escala de 0 a 6.
Fig. XII.4: Gráfico Autoevaluación ITIL Mayo 2005.
Se observa que hay varios procesos que al inicio del proyecto presentaron
valores muy bajos, en cuanto a la aplicación de mejores prácticas, como Gestión
de Continuidad, Versiones, Problemas, Incidencias, Configuración y Cambios.
XII.4 Resultados Finales
En Octubre de 2006, se realiza una segunda autoevaluación de ITIL según
los parámetros fijados por la herramienta diseñada por la coalición conductora del
proyecto, formada en su dirección por Ingenieros certificados en el máximo nivel
de ITIL (Master), que dirigen desde TEA (Telefónica Empresas Americas), el
proceso de implantación de prácticas ITIL en diferentes unidades de la
Corporación Telefónica, este tuvo como resultado lo que muestra la siguiente
tabla.
146
Proceso Subproceso DC TE Mejores Prácticas GAP Mejores Prácticas [%] Soporte de Servicios Cambios 4,9 4,5 -8,89 Configuración 4,2 4,5 6,67 Incidencias 4,8 4,5 -6,67 Problemas 4,1 4,5 8,89 Versiones 4,8 4,5 -6,67
Total 4,6 4,5 -1,33
Entrega de Servicio Capacidad 4,7 4,5 -4,44 Continuidad 4,5 4,5 0,00 Disponibilidad 4,7 4,5 -4,44 Gestión Financiera 4,5 4,5 0,00 Gestión del Servicio 4,4 4,5 2,22
Total 4,6 4,5 -1,33
Valoración Total 4,6 4,5 -1,33
Tabla XII.2: Resultados Autoevaluación Datacenter Telefónica Empresas Octubre 2006.
De acuerdo a estos resultados, el siguiente gráfico muestra la comparación
de la situación inicial con la presentada en Octubre de 2006.
Fig. XII.5: Gráfico Comparativo Autoevaluación Mayo 2005 y Octubre 2006.
Se observa en la figura anterior que las mayores mejoras realizadas en los
procesos están en Gestión de Cambios, Versiones (Releases), Incidencias,
Problemas y Configuración, lo importante en sí, es que se ha reducido en la
147
mayoría de los procesos, la brecha existente entre la forma en que se hacen las
cosas y las mejores prácticas ITIL. Estas diferencias de brecha entre la situación
presente en Mayo de 2005 y Octubre de 2006, pueden ser vistas en el siguiente
gráfico.
Fig. XII.6: Porcentaje de Diferencia de cada Proceso ITIL con las Mejores Prácticas.
De todos los procesos impactados por el proyecto, existen tres de ellos que
no han alcanzado como mínimo un promedio de mejores prácticas ITIL (4,5 en
escala de 0 a 6), que son Gestión de Configuración, Problemas y Nivel de
Servicio, esto se debe a detalles que no se han resuelto aún o a procedimientos
que falta implantar y alinear con otros procesos de certificación como ISO 27001.
148
XII.5 Ejecución de las Pruebas
Para realizar las pruebas, se seleccionó un grupo de personas para que
realizaran algunas actividades de búsqueda de información. Se evaluaron las
siguientes características:
• Diseño interfaz.
• Usabilidad.
• Formato de Ingreso de Información: Se evalúo si la aplicación permitía ingresar
la información de manera correcta, utilizando todas las páginas de ingreso.
Las pruebas fueron realizadas por espacio de 5 días, durante el mes de
Diciembre de 2006, por períodos de 4 horas diarias, con el fin de simular, con las
personas seleccionadas para las pruebas, la llegada de requerimientos, y artículos
de inventario, los cuales debían ser ingresados y/o buscados para verificar el
estado de cada uno de ellos.
XII.6 Evaluación Aplicación
Los usuarios evaluaron en forma positiva el desarrollo de la aplicación,
encontrando como mayores beneficios, la mejora en la disponibilidad y
actualización de la información, además de la disminución del tiempo de búsqueda
de ella.
Debido a que se trata de una evaluación formal de herramientas
tecnológicas, se pidió a los usuarios que las evaluaran cuantitativamente,
declarando su grado de conformidad con diferentes afirmaciones con una escala
de 1 a 7, desde “Muy en desacuerdo” a “Muy de acuerdo”. En la Tabla XII.3 se
puede observar el resumen de los resultados de la encuesta realizada a los
usuarios del sistema.
149
Pregunta Promedio Evaluación La aplicación es fácil de usar 6,3 La interfaz es adecuada 6,3 Mejora la disponibilidad de la información 6,5 Permitirá mantener actualizada la información 6,5 El vocabulario empleado es correcto 6,3 Disminuirá el tiempo de búsqueda 6,5 La visualización de resultados es adecuada 5,9 Usaría la herramienta a diario 6,3 Se asegura un manejo adecuado de Infraestructura de TI 5,7 Mejora el cumplimiento de SLAs 5,7 Mejora la eficacia del negocio 6,1
Promedio General 6,2
Tabla XII.3: Resumen Resultados.
De la evaluación realizada, se encontraron ciertos aspectos positivos de
ella, como la facilidad de búsqueda de la información con el constructor de
consultas asociado, lo que a su vez, permite una rápida actualización de las bases
de datos que soportan la aplicación, y los campos predefinidos de ingreso de
requerimientos, que ayudan a acotar los dominios necesarios de ingreso para
especialización de la asignación.
A si como se encontraron diversos aspectos positivos de la aplicación, se
puede apreciar que los resultados no fueron perfectos, y los comentarios de los
usuarios dejaron oportunidades de mejora como las siguientes:
• Podría generarse a futuro una evolución de la aplicación que mostrara los
resultados de búsqueda con una interfaz estilo Cubos OLAP, donde se
pudieran mezclar diferentes dimensiones con el fin de tener una mejor
especificación de la conectividad de diversos artículos de configuración.
• La aplicación es una oportunidad de crecimiento, ya que puede integrarse
con otras aplicaciones de monitoreo de desempeño de aplicaciones
específicas de servidores a través de diversos agentes.
150
XII.7 Plan de Trabajo Implementación Definitiva
Con el fin de detallar las actividades de la implementación final de la
aplicación y los procesos rediseñados, se muestra en la Tabla XII.4 las actividades
a realizar.
2007
Marzo Abril Mayo Junio Julio Agosto Septiembre
Actividad 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
1. Aplicación de Roles 2. Compra Hardware Aplic. 3. Instalación Data Center 3.1 Instalación Comunic. 3.2 Rackeo 3.3 Cableado 3.4 Fuentes de Energía 3.5 Configuración de Serv. 3.6 Instalación Aplicación 4. Levantamiento CIs 5. Etapa Prueba 6.Revisión Auditoría
7. Puesta en Marcha
Tabla XII.4: Plan De trabajo Implementación Definitiva.
En la Tabla anterior se explican las actividades a realizar para dar por
finalizada la implementación definitiva de los procesos rediseñados y de la
aplicación que les da soporte. En cuanto a los procesos, se pondrá énfasis en la
aplicación de los roles respectivos a quienes corresponda. Para realizar esto, se
planifica en forma secuencial las actividades necesarias, desde comprar el equipo
necesario, hasta la instalación propia de ella, para posteriormente realizar una
etapa de prueba de 3 semanas, y una puesta en marcha definitiva de la misma
extensión.
151
CAPÍTULO XIII: DESARROLLO DEL PROTOTIPO DE LA APLICACIÓN
Para mostrar los beneficios del Sistema, se realizó un Prototipo de ella, la
que mostraba el funcionamiento de la Aplicación en pantallas simplificadas, el cual
fue desarrollado en la herramienta IBM WebSphere Application Developer for
Windows, Versión 4.0.3, y que además interactúa con una interfaz web y de base
datos EasyPHP.
El objetivo de esto, es dar a conocer las funcionalidades básicas del
sistema a las personas que serán beneficiadas por el uso de este, probando así la
factibilidad de las consultas a la base de datos, extracción correcta de lo que se
necesita, ejecución de lógica de negocio y la capacidad de dar al usuario una
respuesta correcta.
La elaboración del prototipo, como su nombre lo indica, incluye solamente
una función de todas las que serán implementadas en el sistema, que es la
asignación de requerimientos, en especial, de un solo tipo de requerimientos.
Lo primero que se hizo, en la realización del prototipo, es la construcción de
la estructura que debía tener la base de datos, la que puede ser apreciada a
continuación.
152
Fig. XIII.1 : Estructura en EasyPHP de la Base de Datos.
Cada una de las tablas de la base de datos de la aplicación, llamada “base7”, tiene la siguiente estructura:
Fig. XIII.2: Estructura Tabla “asignación”.
Fig. XIII.3: Estructura de la Tabla “cliente”.
153
Fig. XIII.4: Estructura de la Tabla “requerimiento”.
Fig. XIII.5: Estructura de la Tabla “responsable”.
La base de datos es consultada por una aplicación, cuyo prototipo tiene las
siguientes páginas:
• Inicio.html : Es la página de ingreso, donde el usuario debe autenticarse
por medio de su número de usuario y password. Al obtener los datos, se
van a un Servlet, de nombre VerificaServlet, el que consulta a la base de
datos el número de usuario y password de él, además, de cargar el perfil de
opciones disponibles en la siguiente página, que es reqprocesado.jsp.
• Reqprocesado.jsp: Es la página de ingreso de requerimientos por parte
del usuario, específicamente en el prototipo solo fue desarrollada una de las
opciones que tendrá la aplicación. Está página recoge las opciones, y se
envían a una Servlet llamado ProcesaServlet, el que ejecuta la lógica de
negocio, para priorizar y asignar los diferentes requerimientos a los
responsables.
154
• Respuesta.jsp: Es la página que informa al usuario que su requerimiento
ha sido asignado correctamente, entregándole un número de asignación,
por si lo necesita posteriormente para verificar el estado del requerimiento.
• Error.jsp: Es la página que informa al usuario que su número de usuario o
contraseña ha sido ingresado en forma incorrecta, o que no existe en la
base de datos.
A continuación se presentan las imágenes de las páginas, cuyas funciones
fueron explicadas anteriormente.
Fig. XIII.6: Página inicio.html
155
Fig. XIII.7: Página reqprocesado.jsp
Fig. XIII.8: Página respuesta.jsp
156
Fig. XIII.9: Página error.jsp
La interacción entre las páginas de la aplicación y la base de datos, está
regida por las clases de control en el sistema, las cuales son representadas por
los Servlet en el desarrollo propio de la Aplicación. Para lograr la funcionalidad
necesaria para el caso del Prototipo, se hicieron dos, los que son VerfificaServlet y
ProcesaServlet. Los códigos de cada uno de ellos pueden ser vistos en la sección
Anexos (Capítulo XVIII).
157
CAPÍTULO XIV: EVALUACIÓN ECONÓMICA DEL PROYECTO
Para realizar una efectiva evaluación económica del proyecto, se deben
tener claro los costos e ingresos producto del rediseño.
XIV.1 Costos del Sistema
Entre los costos en que se incurre en un proyecto como este, se encuentra
fundamentalmente, el costo de desarrollo del proyecto, que consiste
principalmente en la formación del equipo de trabajo. Estos costos son mostrados
en la tabla 1.
Cargo Tiempo [meses] Remuneración Mensual [$] Total Anual [$] Encargado del Proyecto 14 990.000 13.860.000 Alineación con BS7799 2 750.000 1.500.000 Gerente Área 0,25 6.000.000 1.500.000 Subgerente Área 1 3.000.000 3.000.000 Oficial Seguridad 1 1.950.000 1.950.000 Programador 2 450.000 900.000 Total 20,25 13.140.000 22.710.000
Tabla XIV.1: Costos Equipo Desarrollo.
En la tabla XIV.1, se incluyeron todos los costos en los que se ha incurrido,
intentando especificar el número de horas exacta, como lo representa la
estimación de tiempo en la que participó en Gerente de Área.
Cuando se implementan prácticas ITIL, se debe capacitar a las personas
pertenecientes al equipo de trabajo, que tendrá una nueva forma de operar, lo
principal, es que la mayoría de los que se encuentren en el área que se está
rediseñando, tengan, principalmente por una función comercial, el primer nivel de
certificación ITIL de tres existentes, que es “Foundations”. Para esto, cada
persona debe asistir a un curso, que tiene un valor aproximado de US$1.000 por
persona. Estos costos de capacitación, para el personal del Datacenter, se
encuentra representado en la siguiente tabla (XIV.2).
158
Etapa N°Personas Costo [$] Total [$] Primera 8 600.000 4.800.000 Segunda 6 600.000 3.600.000 Tercera 10 600.000 6.000.000 Total Costo Capacitación 24 1.800.000 14.400.000
Tabla XIV.2: Costos Capacitación Datacenter.
Además de esto, existe un costo de almacenamiento, el cual incluye la
adquisición de un Servidor, y otros equipos como lectores de código de barra, una
impresora de código de barras, los que son mostrados en la Tabla XIV.3.
Item N°Equipos Costo [$] Total [$] Equipo Almacenamiento 1 2.500.000 2.500.000 Kit Rackeo 1 70.000 70.000 Lector Código Barra 2 150.000 300.000 Notebook Wifi 1 500.000 500.000 Impresora Código de Barra 1 120.000 120.000 Etiquetas 2000 20 40.000 Total Costo Almacenamiento 2006 3.340.020 3.530.000
Tabla XIV.3: Costo Almacenamiento.
Con esto, se tiene un costo total de $40.640.000, por concepto de inversión,
capacitación y formación del equipo de trabajo. (Tabla XIV.4).
Costos Totales Total [$] Equipo Desarrollo 22.710.000 Capacitación 14.400.000 Almacenamiento 3.530.000 Costo Total Proyecto 40.640.000
Tabla XIV.4: Costo Total Proyecto.
XIV.2 Ingresos del Sistema
Los Ingresos del Sistema, vienen dados por diferentes aspectos de mejora
del rediseño e implementación de la herramienta diseñada. Existen cinco aspectos
en los que el sistema permite establecer mejoras en los flujos que serán
presentados posteriormente en el Flujo de Caja del Proyecto, estos son:
Reducción de Tiempos en Consulta de Información y Asignación de
159
Requerimientos, Reducción de Pérdidas de infraestructura, Reducción de Riesgo
de Pérdida de Clientes e Ingresos por Nuevos Servicios.
La Tabla presentada a continuación (XIV.5) muestra la reducción de riesgo
anual, en términos de la prevención de fuga de clientes, por aplicación del modelo
de negocio rediseñado con las mejores prácticas de mercado ITIL.
Tabla XIV.5: Ingreso Anual Clientes con ITIL.
La reducción de riesgo mostrada anteriormente surge del hecho de que ITIL
ya no es solamente una metodología de mejora de procesos, o prácticas que traen
consigo mejoras operacionales, o valor agregado al modelo de negocio, sino que
es una necesidad de mercado, impuesta por algunos clientes, lo que significa hoy
y en el futuro (de acuerdo a la tasa de estimación calculada con la Subgerente del
Área, Marta Rojo, en el porcentaje de clientes representativos que requieren ITIL),
reducción de fuga de clientes representativos, quienes simplemente requieren si o
si que su proveedor de tecnologías de información, tenga asociadas prácticas ITIL
en su modelo de negocios. Estos clientes, los cuales son los de mayor interés
para la empresa, ya que ellos representan el 80% de la renta total de los servicios
de Datacenter de Telefónica Empresas. Actualmente, este tipo de clientes
asciende a 60, de 250 RUT diferentes a los que se les facturan este tipo de
servicios. Entre los clientes representativos, los cuales según proyecciones de la
Gerencia de Marketing tendrán una tasa sostenida de crecimiento anual de un
10%. Además, según las proyecciones de niveles de servicio ofrecidos a los
clientes, se ha encontrado que un 30% de ellos actualmente requieren ITIL,
requerimiento que crecería en un 10% anualmente hasta el 2010, de acuerdo a
proyecciones de auditorías internas de clientes representativos de servicios de
160
Datacenter de Telefónica Empresas. Es importante destacar, cuál es la definición
de clientes representativos, y son todos aquellos que tienen una renta anual
promedio en este tipo de servicios no menor a $20.800.000, y son (por nombrar
algunos): Codelco, CTC (SAP, MECO, GAUDÍ), Banco Penta, Coopeuch, Ripley,
MINSAL (Ministerio de Salud del Gobierno de Chile), Phelps Dodge, Dos en Uno,
Pullman Bus, Hewlett Packard, Sun, EDS, Banco Central de Chile, Chiquita, TCS
(Tata Consulting Services), y otros. Por lo tanto, el cálculo de disminución de
riesgo por fuga de clientes está hecho en la cota inferior de lo que se estima
actualmente, y no incluye la disminución de riesgo que provoca el modelo, en
cuanto a la posibilidad de adquirir nuevos clientes representativos en el período
determinado. Un dato anexo, que no fue considerado en tasa de crecimiento de
clientes representativos de un 10%, fue que los clientes que tienen servicios de
datacenter contratados actualmente representan el 10% del número total de
clientes (RUT distintos) de Telefónica Empresas, lo que en 3 años más debiera
crecer a un 30%.
Se destaca que el cálculo anterior y las tablas siguientes de ahorros
directos, fueron validados por Marta Rojo, Subgerente de Outsourcing y
Datacenter de la Vice Presidencia Empresas de Telefónica Chile.
A continuación se presenta la Tabla XIV.6, la que muestra el cálculo del
Valor Horas Hombre [$], de cada una de las áreas del Datacenter.
Área Sueldo Horas Mensuales Valor HH [$]
Operaciones 330.000 180 1.833 Ingeniería 1.000.000 180 5.556 Proyectos 1.400.000 180 7.778
Tabla XIV.6: Cálculo del Valor HH por Área del Datacenter.
El valor obtenido en la Tabla XIV.6, es usado en la Tabla XIV.7, y a partir de
la cantidad de personas de cada área, sus horas hombre disponibles mensuales, y
su fracción de tiempo dedicado a atender requerimientos (datos históricos), se
calculan las Horas Hombre dedicadas a atender requerimientos, de las cuales se
161
obtiene el 17%, debido a lo expuesto según la simulación del modelo, con lo que
se produce un ahorro mensual estimado de $3.665.880.
Tabla XIV.7: Ahorro Anual en Asignación de Requerimientos.
La Tabla XIV.8 muestra el ahorro anual en Consulta de Información,
derivado del cálculo histórico de Horas Hombre dedicadas a esto, a la vez, la
implantación de otros sistemas ha determinado que el área se ve beneficiada en
un ahorro del 50% del tiempo empleado en la actividad, por lo que el ahorro anual
percibido por búsqueda de información es de $819.000.
Tabla XIV.8: Ahorro Anual en Consulta Información.
A la vez, el Sistema que se implementará, permitirá incluir nuevos servicios
a clientes, la proyección de esto, se ve reflejada en la Tabla XIV.9.
Valor Un. [$] N°Contratos Valor Anual [$]
Consulta Web Requerimientos 600.000 10 6.000.000
Total Año Nuevos Servicios 6.000.000 Tabla XIV.9: Ingresos por Concepto de Nuevos Servicios.
Otro ahorro que no fue explicado en tablas, es el de pérdidas de
infraestructura, el cual debido a no tener un sistema de información que controle
esto, ha ascendido a $4.000.000. Por lo tanto, se espera que este ítem sea
reducido completamente.
162
XIV.3 Flujo de Caja del Proyecto
Año 0 [$] Año 1 [$] Año 2 [$] Año 3 [$]
Reducción Riesgo
Ingreso Clientes Representativos 374.400.000 549.120.000 748.800.000
Nuevos Servicios
Nuevos Servicios 6.000.000 6.000.000 6.000.000
Ahorros Directos
Consulta Información 819.000 819.000 819.000
Asignación Requerimiento 3.665.880 3.665.880 3.665.880
Pérdidas Infraestructura 4.000.000 4.000.000 4.000.000
Subtotal Ahorros 388.884.880 563.604.880 763.284.880
Costos Directos
Costos Equipo Desarrollo 22.710.000 22.710.000 22.710.000
Subtotal Costos Directos 22.710.000 22.710.000 22.710.000
Resultado Operacional 366.174.880 540.894.880 740.574.880
Gastos en Administración
Gasto en Marketing y Capacitación 14.400.000 14.400.000 14.400.000
Depreciación (-) 1.176.667 1.176.667 1.176.667
Subtotal Gastos 15.576.667 15.576.667 15.576.667
Resultado No Operacional (-) 15.576.667 15.576.667 15.576.667
Resultado Antes Impuesto 350.598.213 525.318.213 724.998.213
Impuesto (17%) 59.601.696 89.304.096 123.249.696
Utilidad del Ejercicio 290.996.517 436.014.117 601.748.517
Depreciación (+) 1.176.667 1.176.667 1.176.667
Flujo Caja Bruto Permanente 292.173.184 437.190.784 602.925.184
Inversión
Desarrollo Aplicación 22.710.000
Equipo Almacenamiento 3.530.000
Flujo Caja Libre -26.240.000 292.173.184 437.190.784 602.925.184
VAN con tasa 14% 973.413.704
TIR 1150% Tabla XIV.10: Flujo de Caja.
163
CAPÍTULO XV: GENERALIZACIÓN DE LA EXPERIENCIA EN EL DESARROLLO DE UN FRAMEWORK
Los frameworks orientados al objeto (llámense simplemente frameworks),
son la piedra angular de la moderna ingeniería del software, su desarrollo está
ganando rápidamente la aceptación debido a su capacidad para promover la
reutilización del código del diseño y el código fuente (source code). Los
frameworks son los Generadores de Aplicación que se relacionan directamente
con un dominio específico, es decir, con una familia de problemas relacionados.
Además, deben generar las aplicaciones para un dominio entero. Por lo tanto,
debe haber puntos de flexibilidad que se puedan modificar los requisitos
particulares para ajustarse a la aplicación.
Los puntos flexibles de un framework se llaman puntos calientes (hot-
spots), y son las clases o los métodos abstractos que deben ser implementados o
puestos en ejecución. Los frameworks no son ejecutables, para generar un
ejecutable, uno debe "especificar en una instancia" el framework (llámese
especificar en una instancia, al hecho de producir y completar un objeto llenando
con valores en lugar de variables en una clase), poniendo el código específico de
la aplicación en ejecución para cada Hot-spots, los que, una vez que son
especificados en una instancia, son usados por el framework, especialmente
aquellas clases que usan el callback o repetición de la llamada (acto de repetir la
autentificación del número de usuario en caso de reconección) . En esta repetición
de la llamada o callback, el código del usuario del servicio declara que desea ser
llamado en la ocurrencia un determinado evento. Entonces, el código del
proveedor del servicio realiza la repetición de la llamada o callback con el código
del usuario del servicio al momento de ocurrir ese determinado evento. Por esta
razón, en primera instancia, el framework se caracteriza a veces como " el viejo
código que llama al nuevo código."
Algunas de las características del framework no son mutables ni tampoco
pueden ser alteradas fácilmente. Estos puntos inmutables constituyen el núcleo o
kernel de él, también llamados como los puntos congelados o frozen-spots del
164
framework. A diferencia de los puntos calientes o hot-spots, los puntos congelados
o inmutables son los pedacitos del código puestos en ejecución ya dentro del
framework que llaman a uno o más puntos calientes proporcionados por el
ejecutor. El núcleo o Kernel será la constante y presentará siempre la parte de
cada instancia del framework
Se puede pensar en un framework como si fuese un motor, que requiere
potencia. A diferencia de un motor tradicional, un motor del framework tiene
muchas entradas de potencia, donde cada una de estas entradas de potencia es
un Hot-spot del framework, y cada uno de ellos debe ser accionado para que el
motor funcione. Los generadores de potencia son el código específico de la
aplicación que se debe enchufar a los Hot-spot. El código agregado de la
aplicación será utilizado por el código kernel del framework. El motor no correrá
hasta que todos los enchufes estén conectados. Esta metáfora se ilustra en la
Figura XV.1.
Fig. XV.1: Ilustración de la Metáfora Motor del Framework.
La capacidad de reutilización del código y del diseño de frameworks
orientados al objeto permite una productividad mayor y un tiempo de Mercado
breve en el desarrollo de aplicaciones, en comparación con el desarrollo
165
tradicional de los sistemas de software22. La configuración flexible de frameworks,
permite la reutilización del núcleo kernel. El desarrollo del framework ha sido
exitoso en muchos dominios.
XV.1 Desarrollo del Framework
Las tres etapas principales del desarrollo del framework son análisis del
dominio, diseño del framework, y la "instantiación"23 del framework.
El análisis del dominio procura descubrir los requisitos del dominio y los
posibles requerimientos futuros. Para completar los requerimientos sirven las
experiencias previamente publicadas, los sistemas de software similares
existentes, las experiencias personales, y los estándares considerados. Durante el
análisis del dominio, los puntos calientes y los puntos congelados se destapan
parcialmente.
La fase del diseño del framework define las abstracciones de éste. Se
modelan los puntos calientes y los puntos congelados, la extensión y la flexibilidad
propuesta en el análisis del dominio se esboza en líneas generales. Según lo
mencionado arriba, los modelos del diseño se utilizan en esta fase.
Finalmente, en la fase de "instantiación", los puntos calientes del framework
son implementados, generando un software del sistema. Es importante observar
que cada uno de estas aplicaciones tendrá los puntos congelados del framework
en común. Las fases del proceso del desarrollo del framework son comparados
con las tradicionales fases del diseño orientados al objeto, según se puede
apreciar en la Figura XV.2., donde se nombran las fases del desarrollo según lo
descrito24.
22 Fayad, M. E., Schmidt, D. C., and Johnson, R. E. Building Application Frameworks. Addison-Wesley Pub Co, 1st edition, 1999. 23 Intantiar: especificar una instancia. 24 Jacobson, I., Booch, G., Rumbaugh, J. The Unified Software Developement Process. Addison-Wesley, 1999.
166
Fig. XV.2: Proceso de Desarrollo del Framework.
Según lo mostrado en la Figura XV.2, el desarrollo tradicional Orientado al
Objeto se diferencia del desarrollo del framework, ya que en él, la fase de análisis
del problema, también llamada inicio, estudia solamente los requisitos de un solo
problema. En cambio, el desarrollo del framework captura los requisitos para un
dominio entero. Además, el resultado final del desarrollo orientado al objeto
tradicional es una aplicación que es completamente ejecutable, mientras que
muchas aplicaciones resultan a partir de la fase de "instantiación" del desarrollo
del framework, que abarca las fases de construcción y de transición del desarrollo
tradicional. Así, la construcción y las fases separadas de la transición están
presentes en cada uno de las instancias del framework. Para cada una de las
instancias del framework hay un esfuerzo de implementación o puesta en práctica
introducido por estas fases.
167
XV.2 Aplicación del Framework
En general, la gestión de requerimientos del Datacenter de Telefónica
Empresas, puede ser generalizada a la gestión de cualquier otro tipo de
requerimiento. Esto se debe a que los principios básicos que apoyan esto son los
mismos, es decir, atención de requerimientos mediante optimización de los
recursos disponibles con el fin de minimizar el tiempo de resolución de
requerimientos. La Gestión de estos, se ve especificada y sustentada por las
mejores prácticas de mercado, que proveen los criterios de clasificación,
priorización y asignación, definiendo a su vez los diferentes intervalos.
Se puede definir un Requerimiento general como un arreglo de n
componentes, las cuales definen diferentes especificaciones, las que deben ser
calculadas por un modelo, intentando optimizar el uso de los recursos encargados
de recibir estos tipos de requerimientos, quienes también pueden ser definidos
como un arreglo de n componentes, teniendo diferentes atributos en ellos, los que
pueden ser los que explican la capacidad disponible, cuánto tiempo de espera se
tendría si se asignara a ese recurso un determinado requerimiento, etc.
Este framework puede ser muy útil para sistemas que operen según fue
explicado en el párrafo anterior, y su desarrollo se justifica porque las lógicas
generales son comunes para muchos casos particulares, y dado el modelo de
patrones de diseño aplicados, se permite una especificación lógica del negocio
posterior, por lo que sólo faltaría definir las lógicas particulares, con sus entidades,
atributos y métodos respectivos, demostrando que se facilitan otros desarrollos.
La figura XV.3 muestra el Framework procesamiento de requerimientos, el
cual si es aplicado al diagrama de clases desarrollado, se puede apreciar que las
especializaciones de lógica se encontrarán en las clases de control, que es donde
se define la lógica de negocio, y la especialización de entidades, que se hará
mediante la inclusión de entidades específicas del caso particular.
168
Fig. XV.3: Framework Procesamiento de Requerimiento.
Las clases mostradas en la Fig. XV.3, se deben especializar de la siguiente
forma:
• Procesar: Es donde se aplican las lógicas específicas de procesamiento de
requerimientos, por lo tanto, se den detallar los criterios de clasificación y
priorización. La forma del algoritmo de asignación, solo debe ser
particularizado en las capacidades definidas.
• Asignación: Corresponde a una clase entity que relaciona los diferentes
requerimientos con los recursos que se encargan de resolverlos, al
especificar las entidades que se relacionan con ella, esta quedará
funcionando de la misma forma.
• Requerimiento: Es una clase entity que contiene los atributos de un
determinado requerimiento, para algún caso particular, se deben cambiar
los atributos.
• SLA: Es una clase entity que relaciona los diferentes requerimientos con los
acuerdos previamente establecidos entre quienes piden requerimientos y
los ejecutores de ellos. Para un caso particular, esto debe variar.
169
Fig. XV.4: Diagrama de Clases de Procesamiento de Requerimientos.
La Figura XV.4 muestra el diagrama de clases de procesamiento de
requerimientos, que contiene la lógica del negocio y que son modificables en la
generalización necesaria para la construcción del Framework.
170
XV.3 Construcción del Framework
En base a lo anteriormente explicado, la estructura del framework se
construye en base a las siguientes clases entity y control, que son presentadas en
la Figura XV.5.
Fig. XV.5: Diagrama de Clases del Framework.
Según la estructura mostrada en la Figura anterior, se puede generalizar el
desarrollo de un sistema de procesamiento de requerimiento. Las clases son
explicadas a continuación.
• Procesamiento: Clase control que se encarga de ser el clasificador,
priorizador, calculador de tiempo disponible de los recursos o de la carga de
trabajo, y asignador de acuerdo al algoritmo de optimización.
171
• Requerimiento: Clase entity que guarda la información específica técnica y
de características de cada requerimiento que llega al sistema.
• Asignación: Clase entity que relaciona las clases requerimiento y recurso,
información relevante para la lógica del negocio.
• Recurso: Clase entity que guarda la información de los recursos
responsables de solucionar requerimientos.
• Parámetro: Clase entity que guarda información acerca de los acuerdos
previamente establecidos entre clientes y recursos del sistema.
172
XV.4 Aplicación del Framework al Caso de “Mantenimiento de Aviones”
De manera de probar la aplicabilidad del framework diseñado, se aplicó el
modelo planteado anteriormente al desarrollo de un sistema de apoyo al
procesamiento de requerimientos del mantenimiento de aviones.
Fig. XV.6: Diagrama de Clases en el Mantenimiento de Aviones.
La Figura XV.6 muestra el Diagrama de Clases en el Mantenimiento de
Aviones, cuya definición fue extraída del área “Mantenimiento de Aviones” de la
empresa Lan Chile. En el diagrama se puede apreciar que la clase control de
requerimientos no pierde su estructura particular, pero si son especificados dos
métodos nuevos de esa clase. A la vez, es agregada una clase control llamada
paradas_asignadas, la que tiene cómo función, a partir de tablas extraídas de una
aplicación ERP, especificar las fechas en las que un determinado avión estará
173
parado, y a partir de esto generar órdenes de trabajo (WO o Work Orders), con las
asignaciones previamente realizadas por la clase procesamiento.
174
CAPÍTULO XVI: CONCLUSIONES
Los procesos diseñados bajo el estándar ITIL responden a una necesidad
de mercado, y de mejora en la gestión de soporte y entrega de servicios, con esto,
la prestación de servicios de Datacenter de Telefónica Empresas, se encuentra
actualizada y vigente en valor agregado demostrado a sus clientes, los que
requieren satisfacer sus requerimientos de acuerdos a los niveles de servicio
contratados, ya que estos han sido especificados en relación a sus respectivos
SLAs y OLAs (Operacional Level Agreement), teniéndose generalmente multas
considerables si es que estos no llegaran a cumplirse.
La Aplicación desarrollada para el proyecto, permite realizar una acertada
gestión de requerimientos, tomando en cuenta el tiempo de solución que necesita
el cliente, que es comparado con el SLA contratado, para asignar de acuerdo a
esto, y a la carga de trabajo de cada uno de las personas disponibles para
solucionar el requerimiento, con lo que se optimiza la asignación de ellos,
produciendo eficacia operacional, la que puede a su vez, directamente ahorrar
horas hombre dedicadas a resolución. Además, al tener incorporada la Gestión de
Inventario en ella, se minimizan las pérdidas de infraestructura, con registros
actualizados de los diferentes artículos de configuración, debido a tener la
información de proyectos actualizada en un repositorio centralizado, permitiendo
que esta quede en el lugar donde realmente debe estar y pertenecer, que es la
organización, incrementando la disponibilidad de recursos que es indispensable,
como la información.
Es importante destacar, que un proyecto de Ingeniería de Negocios como
este, trae beneficios para Telefónica Chile en muchas aristas, las que combinadas,
hacen que la posición competitiva de mercado mejore, a través de diferentes
factores, como mejora de resultados operacionales, disminución de riesgo de fuga
de clientes, y el respectivo aumento en la satisfacción de ellos, lo que beneficia
directamente la imagen de la empresa, de mucha importancia, sobre todo cuando
están involucrados los clientes de más alta rentabilidad para la organización.
175
La tendencia de las tecnologías de información, sobretodo en Chile, país
históricamente destacado por ser un adoptante tempranero de TI, es de tener un
ritmo de crecimiento en capacidad de forma aritmética, pero en complejidad de
forma geométrica, lo que hace necesario tener herramientas de control
desarrolladas de acuerdo a las necesidades del negocio y de la criticidad de
algunos de sus aspectos, como es la atención de requerimientos de clientes de
alta disponibilidad, con SLAs contratados de tiempos de solución ajustados. Esto,
y la capacidad de una empresa de entender el cambio constante que tiene este
sector industrial, adaptándose después de cada cambio, para dar un servicio en el
que se cumplan los acuerdos con sus clientes, es la base para mantener vigente
una empresa proveedora de servicios de tecnologías de información en un
mercado competitivo y que está en una carrera vertiginosa por especializar y
estandarizar sus procesos, pudiendo demostrar a clientes de carácter global que
se pueden hacer las cosas según dictan las mejores prácticas.
La prestación de Servicios de Datacenter de Telefónica Empresas se
caracteriza por tener altos niveles de cumplimiento de servicio con sus clientes, y
el crecimiento del número de ellos y de la complejidad de sus sistemas soportados
por el hardware instalado, hacen que se renueve constantemente el compromiso
por seguir creciendo en confiabilidad, integridad, y confidencialidad en el manejo
de la información, homologando ahora Procesos ITIL en su Modelo de Negocios, y
a fines del año en curso la norma ISO 27001, para en el futuro dar paso a
estándares más exigentes como SAS 70, perfilándose como el líder del mercado
nacional en cuanto a mejores prácticas aplicadas al modelo de negocio.
176
CAPÍTULO XVII: BIBLIOGRAFÍA
1. Barros, O. “Rediseño de Procesos de negocios mediante el uso de
patrones: mejores practicas de gestión para aumentar competitividad”; Dolmen
Ediciones, 2000.
2. Barros, O. “Ingeniería E-Business: Ingeniería de Negocios para la
Economía Digital”; Dolmen Ediciones, 2004.
3. EXIN. “Gestión de Servicios de TI, Fundamentos de ITIL”, 2005.
4. Kemmerling, G. “Gestión de Servicios TI, una introducción a ITIL”; Van
Haren Publishing, 2004.
5. Dorgan, S.; Dowdy, J. “When IT lift productivity”; The McKinsey Quarterly,
2004 Number 4.
6. Kotter, J. “Porqué los esfuerzos de transformación fracasan”; Harvard
Business Review, 1995.
7. Senge, P. “La Danza del Cambio” ; Editorial Norma, Año 2000.
8. Fayad, M. E., Schmidt, D. C., and Johnson, R. E. Building Application
Frameworks. Addison-Wesley Pub Co, 1st edition, 1999.
177
CAPÍTULO XVIII: ANEXOS
XVIII.1 Códigos Páginas Prototipo
XVIII.1.1 Código Página inicio.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML> <HEAD> <META name="GENERATOR" content="IBM WebSphere Studio"> <TITLE>inicio.html</TITLE> </HEAD> <BODY> <CENTER> <TABLE border="1"> <TBODY> <TR> <TD width="83"><IMG src="logoazulchico.jpg" width="105" height="45" border="0"></TD> <TD width="214">Sistema Gestión Requerimientos<BR> Datacenter Telefónica Empresas</TD> </TR> </TBODY> </TABLE> </CENTER> <P><BR> </P> <CENTER> <FORM method="POST" action="VerificaServlet"> <TABLE border="1"> <TBODY> <TR> <TD>Código</TD> <TD><INPUT size="20" type="text" name="codigo"></TD> </TR> <TR> <TD>Contraseña</TD> <TD><INPUT size="20" type="password" name="contrasena"></TD> </TR> </TBODY> </TABLE> <INPUT type="submit" name="enviar" value="ENVIAR"> <INPUT type="reset" name="limpiar" value="LIMPIAR"></FORM> </CENTER> </BODY> </HTML>
178
XVIII.1.2 Código Página reqprocesado.jsp
<BODY> <CENTER> <TABLE border="1"> <TBODY> <TR> <TD><IMG src="logoazulchico.jpg" width="105" height="45" border="0"></TD> <TD>Sistema Gestión Requerimientos<BR> Datacenter telefónica Empresas</TD> </TR> </TBODY> </TABLE> </CENTER> <P align="center">Ingrese su Requerimiento</P> <CENTER> <FORM method="POST" action="ProcesaServlet"> <TABLE border="1"> <jsp:useBean id="cod" class="java.lang.String" scope="request"/> <TBODY> <TR> <TD>Código Cliente</TD> <TD><INPUT size="5" type="text" name="cod"></TD> </TR> <TR> <TD>Nombre</TD> <TD><INPUT size="40" type="text" name="nombrereq"></TD> </TR> <TR> <TD>Descripción</TD> <TD><INPUT size="80" type="text" name="descripcion"></TD> </TR> <TR> <TD>Tipo1</TD> <TD><SELECT name="tipo1"> <OPTION value="1">Hardware</OPTION> <OPTION value="2">Software</OPTION> </SELECT></TD>
179
</TR> <TR> <TD>Tipo2</TD> <TD><SELECT name="tipo2"> <OPTION value="2">Respaldo Legato</OPTION> <OPTION value="3">Respaldo Legato Protector</OPTION> <OPTION value="4">Plataforma UNIX</OPTION> <OPTION value="5">Clima</OPTION> <OPTION value="6">Migración de Equipos</OPTION> <OPTION value="7">Plataforma Windows</OPTION> <OPTION value="8">Solicitud de Acceso</OPTION> <OPTION value="9">Consulta Estado Configuración</OPTION> <OPTION value="1">Respaldo</OPTION> </SELECT></TD> </TR> <TR> <TD>Tiempo Respuesta Req.</TD> <TD><SELECT name="tiemporesp"> <OPTION value="1">1 Hora</OPTION> <OPTION value="2">2 Horas</OPTION> <OPTION value="3">3 horas</OPTION> <OPTION value="4">4 horas</OPTION> <OPTION value="12" selected>12 horas</OPTION> <OPTION value="24">24 horas</OPTION> </SELECT></TD> </TR> </TBODY> </TABLE> <BR> <INPUT type="submit" name="enviar" value="ENVIAR"> <INPUT type="reset" name="borrar" value="BORRAR"><BR> <BR> </FORM> </CENTER> </BODY> </HTML>
XVIII.1.3 Código Página respuesta.jsp
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML> <HEAD> <META name="GENERATOR" content="IBM WebSphere Studio"> </HEAD> <BODY> <jsp:useBean id="codifin" class="java.lang.String" scope="request"/>
180
<P><IMG src="logoazulchico.jpg" width="105" height="45" border="0"><BR> <BR> <BR> <BR> Su requerimiento fue procesado, y asignado correctamente.<BR> <BR> El número de Registro es: <%=codifin%><BR> <BR> Muchas Gracias por usar SGR.<BR> <BR> <BR> <BR> </P> </BODY> </HTML>
XVIII.1.4 Código Página error.jsp
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML> <HEAD> <META name="GENERATOR" content="IBM WebSphere Studio"> <TITLE>error.jsp</TITLE> </HEAD> <jsp:useBean id="n_a_mostrar" class="java.lang.String" scope="request"/> <P><BR> <BR> <B><FONT size="+2">El código no existe, por favor inténtelo nuevamente. </FONT></B></P> </BODY> </HTML>
XVIII.2 Códigos Servlet Prototipo
XVIII.2.1 VerificaServlet
import javax.servlet.http.HttpServlet; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; import java.sql.*; import java.lang.Object.*; import java.util.*;
181
public class VerificaServlet extends HttpServlet { public void doPost( javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) throws javax.servlet.ServletException, java.io.IOException { // Se definen las variables String nombre, cod =null; String codicli,contrasena=null; Connection DBConexion; RequestDispatcher disp=null; ClienteP cliente; String codi_inc=null; String nombre_completo=null; String url = null; Vector Aux = new Vector(); // Se reciben datos del formulario de entrada codicli= (String) request.getParameter("codigo"); contrasena= (String) request.getParameter("contrasena"); // Se conecta con la base de datos System.out.println("paso 1"); DBConexion=Conectar(); cliente=new ClienteP(codicli,contrasena); System.out.println("paso 2"); if (cliente.ValidaUsuario(DBConexion)) { System.out.println("Usuario Autenticado"); cliente=null; cliente=new ClienteP(codicli,DBConexion); System.out.println("paso 4"); nombre=cliente.getNombre(); cod=codicli; System.out.println("paso 5"); url = "reqprocesado.jsp"; } else{ System.out.println("Usuario No Valido"); nombre=null;
182
cod=null; url = "error.jsp"; System.out.println("paso 7"); } System.out.println("paso 12"); this.DesplegarResultado(url,cod,nombre,request,response); System.out.println("paso 13"); } // Se definen los Metodos private void DesplegarResultado( String url, String cod, String nombre, HttpServletRequest request, HttpServletResponse response) throws javax.servlet.ServletException, java.io.IOException { RequestDispatcher disp = null; request.setAttribute("cod", cod); request.setAttribute("nombre", nombre); disp = getServletContext().getRequestDispatcher("/" + url); disp.forward(request, response); } private Connection Conectar() { System.out.println("Abriendo Conexión"); Connection conexion = null; String DBurl = "jdbc:odbc:base7"; try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
183
conexion = DriverManager.getConnection(DBurl, "root", ""); } catch (Exception e) { e.printStackTrace(); } return conexion; } public void doGet( javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) throws javax.servlet.ServletException, java.io.IOException { this.doPost(request, response); } }
XVIII.2.2 ProcesaServlet
import javax.servlet.http.HttpServlet; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; import java.sql.*; import java.lang.Object.*; import java.util.*; public class ProcesaServlet extends HttpServlet { public void doPost( javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) throws javax.servlet.ServletException, java.io.IOException { // Se definen las variables String codigo = null; String nombrer,descr =null; String url = null; int ultimoreq, codireq;
184
Connection DBConexion; ClienteP cliente; // Se conecta a la base de datos codigo= (String) request.getParameter("cod"); DBConexion = Conectar(); System.out.println("paso 1001"); cliente = new ClienteP (codigo, DBConexion); System.out.println("paso 1002"); // Se reciben datos de la página reqprocesado.jsp nombrer= (String) request.getParameter("nombrereq"); descr= (String) request.getParameter("descripcion"); String tip1= (String) request.getParameter("tipo1"); String tip2= (String) request.getParameter("tipo2"); String tiem= (String) request.getParameter("tiemporesp"); System.out.println("paso 1003"); // Se ejecuta la lógica de Negocio // Para efectos del Prototipo, se omitió la priorización en la asignación. // Además, está simplificado el listado de opciones. String codires1 = null; String codires2 = null; String codires3 = null; if (tip1.equals("1")){ if (tip2.equals("1")){ if(tiem.equals("1")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "14"; codires2 = "0"; codires3 = "0";
185
} else if(tiem.equals("3")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("12")){ codires1 = "14"; codires2 = "11"; codires3 = "9"; } else if(tiem.equals("24")){ codires1 = "14"; codires2 = "11"; codires3 = "9"; } } else if (tip2.equals("2")){ if(tiem.equals("1")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("3")){ codires1 = "14"; codires2 = "9"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "14"; codires2 = "9"; codires3 = "0"; } else if(tiem.equals("12")){ codires1 = "14"; codires2 = "9"; codires3 = "0"; }
186
else if(tiem.equals("24")){ codires1 = "14"; codires2 = "9"; codires3 = "0"; } } else if (tip2.equals("3")){ if(tiem.equals("1")){ codires1 = "11"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "11"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("3")){ codires1 = "11"; codires2 = "9"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "11"; codires2 = "9"; codires3 = "0"; } else if(tiem.equals("12")){ codires1 = "11"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("24")){ codires1 = "11"; codires2 = "0"; codires3 = "0"; } } else if (tip2.equals("4")){ if(tiem.equals("1")){ codires1 = "13"; codires2 = "14"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "13"; codires2 = "14"; codires3 = "0";
187
} else if(tiem.equals("3")){ codires1 = "13"; codires2 = "14"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "13"; codires2 = "14"; codires3 = "15"; } else if(tiem.equals("12")){ codires1 = "13"; codires2 = "14"; codires3 = "15"; } else if(tiem.equals("24")){ codires1 = "13"; codires2 = "14"; codires3 = "15"; } } else if (tip2.equals("5")){ if(tiem.equals("1")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("3")){ codires1 = "14"; codires2 = "16"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "14"; codires2 = "16"; codires3 = "1"; } else if(tiem.equals("12")){ codires1 = "14"; codires2 = "16"; codires3 = "1"; }
188
else if(tiem.equals("24")){ codires1 = "14"; codires2 = "16"; codires3 = "1"; } } else if (tip2.equals("6")){ if(tiem.equals("1")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("3")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("12")){ codires1 = "14"; codires2 = "16"; codires3 = "1"; } else if(tiem.equals("24")){ codires1 = "14"; codires2 = "16"; codires3 = "1"; } } else if (tip2.equals("7")){ if(tiem.equals("1")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "14"; codires2 = "0"; codires3 = "0";
189
} else if(tiem.equals("3")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "14"; codires2 = "16"; codires3 = "0"; } else if(tiem.equals("12")){ codires1 = "14"; codires2 = "16"; codires3 = "8"; } else if(tiem.equals("24")){ codires1 = "14"; codires2 = "16"; codires3 = "8"; } } else if (tip2.equals("8")){ if(tiem.equals("1")){ codires1 = "14"; codires2 = "16"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "14"; codires2 = "16"; codires3 = "0"; } else if(tiem.equals("3")){ codires1 = "14"; codires2 = "16"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "14"; codires2 = "16"; codires3 = "0"; } else if(tiem.equals("12")){ codires1 = "14"; codires2 = "16"; codires3 = "0"; }
190
else if(tiem.equals("24")){ codires1 = "14"; codires2 = "16"; codires3 = "0"; } } else if (tip2.equals("9")){ if(tiem.equals("1")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("3")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("12")){ codires1 = "14"; codires2 = "16"; codires3 = "3"; } else if(tiem.equals("24")){ codires1 = "14"; codires2 = "16"; codires3 = "3"; } } } else if (tip1.equals("2")){ if (tip2.equals("1")){ if(tiem.equals("1")){ codires1 = "11"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "11";
191
codires2 = "0"; codires3 = "0"; } else if(tiem.equals("3")){ codires1 = "11"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "11"; codires2 = "9"; codires3 = "3"; } else if(tiem.equals("12")){ codires1 = "11"; codires2 = "9"; codires3 = "3"; } else if(tiem.equals("24")){ codires1 = "11"; codires2 = "9"; codires3 = "3"; } } else if (tip2.equals("2")){ if(tiem.equals("1")){ codires1 = "9"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "9"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("3")){ codires1 = "9"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "9"; codires2 = "11"; codires3 = "3"; } else if(tiem.equals("12")){ codires1 = "9"; codires2 = "11";
192
codires3 = "3"; } else if(tiem.equals("24")){ codires1 = "9"; codires2 = "11"; codires3 = "3"; } } else if (tip2.equals("3")){ if(tiem.equals("1")){ codires1 = "11"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "11"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("3")){ codires1 = "11"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "11"; codires2 = "9"; codires3 = "3"; } else if(tiem.equals("12")){ codires1 = "11"; codires2 = "9"; codires3 = "3"; } else if(tiem.equals("24")){ codires1 = "11"; codires2 = "9"; codires3 = "3"; } } else if (tip2.equals("4")){ if(tiem.equals("1")){ codires1 = "13"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "13";
193
codires2 = "0"; codires3 = "0"; } else if(tiem.equals("3")){ codires1 = "13"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "13"; codires2 = "3"; codires3 = "0"; } else if(tiem.equals("12")){ codires1 = "13"; codires2 = "3"; codires3 = "0"; } else if(tiem.equals("24")){ codires1 = "13"; codires2 = "3"; codires3 = "0"; } } else if (tip2.equals("5")){ if(tiem.equals("1")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("3")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "14"; codires2 = "16"; codires3 = "3"; } else if(tiem.equals("12")){ codires1 = "14"; codires2 = "16";
194
codires3 = "3"; } else if(tiem.equals("24")){ codires1 = "14"; codires2 = "16"; codires3 = "3"; } } else if (tip2.equals("6")){ if(tiem.equals("1")){ codires1 = "16"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "16"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("3")){ codires1 = "16"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "16"; codires2 = "5"; codires3 = "0"; } else if(tiem.equals("12")){ codires1 = "16"; codires2 = "5"; codires3 = "0"; } else if(tiem.equals("24")){ codires1 = "16"; codires2 = "5"; codires3 = "1"; } } else if (tip2.equals("7")){ if(tiem.equals("1")){ codires1 = "8"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "8";
195
codires2 = "0"; codires3 = "0"; } else if(tiem.equals("3")){ codires1 = "8"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "8"; codires2 = "14"; codires3 = "3"; } else if(tiem.equals("12")){ codires1 = "8"; codires2 = "14"; codires3 = "3"; } else if(tiem.equals("24")){ codires1 = "8"; codires2 = "14"; codires3 = "3"; } } else if (tip2.equals("8")){ if(tiem.equals("1")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("3")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "14"; codires2 = "16"; codires3 = "0"; } else if(tiem.equals("12")){ codires1 = "14"; codires2 = "16";
196
codires3 = "0"; } else if(tiem.equals("24")){ codires1 = "14"; codires2 = "16"; codires3 = "0"; } } else if (tip2.equals("9")){ if(tiem.equals("1")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("2")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("3")){ codires1 = "14"; codires2 = "0"; codires3 = "0"; } else if(tiem.equals("4")){ codires1 = "14"; codires2 = "15"; codires3 = "0"; } else if(tiem.equals("12")){ codires1 = "14"; codires2 = "15"; codires3 = "0"; } else if(tiem.equals("24")){ codires1 = "14"; codires2 = "15"; codires3 = "0"; } } } codireq = cliente.cuentaReq(DBConexion)+1; cliente.upEstado(codireq, codigo, codires1, codires2, codires3, nombrer, descr, tip1, tip2, tiem, DBConexion);
197
// Se envía a la Página respuesta.jsp , el mensaje de que el requerimiento fue asignado, con su número respectivo. url = "respuesta.jsp"; RequestDispatcher disp = null; String codifin = null; codifin = String.valueOf(codireq); request.setAttribute("codifin", codifin); disp = getServletContext().getRequestDispatcher("/" + url); disp.forward(request, response); } public void doGet( javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) throws javax.servlet.ServletException, java.io.IOException { } private Connection Conectar() { Connection conexion = null; String DBurl = "jdbc:odbc:base7"; try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); conexion = DriverManager.getConnection(DBurl, "root", ""); } catch (Exception e) { e.printStackTrace(); } return conexion; } }
198
XVIII.2.3 ClienteP
import javax.servlet.http.HttpServlet; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; import java.sql.*; import java.lang.Object.*; import java.util.*; import java.net.*; public class ClienteP { private String Codigo = null; private String Nombre = null; private String Contrasena = null; int Codireq; String Codires1; String Codires2; String Codires3; String NombreR = null; String Descripcion = null; String Tipo1 = null; String Tipo2 = null; String Tiemporesp = null; String codbd; String Estado = null; String Codicl =null; int cla; int claok; public ClienteP(String codigo, String contrasena) { this.Codigo = codigo; this.Contrasena = contrasena; } public ClienteP(String codigo, Connection conexion) { this.Codigo = codigo; Statement statement = null; ResultSet rs = null; try { statement = conexion.createStatement();
199
String a= "SELECT * FROM cliente WHERE cliente.CODICLI='"+ this.Codigo +"'" ; rs = statement.executeQuery(a); while (rs.next()) { this.Codigo = rs.getString("CODICLI"); this.Nombre = rs.getString("NOMBRE"); this.Contrasena = rs.getString("CONTRASENA"); } rs.close(); statement.close(); } catch (Exception e) { e.printStackTrace(); } } public String getNombre() { return this.Nombre; } public String getContrasena() { return this.Contrasena; } public int cuentaReq(Connection conexion){ Statement statement = null; ResultSet tabla= null; try { // statement = conexion.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_UPDATABLE);
200
statement = conexion.createStatement(); tabla = statement.executeQuery("SELECT MAX(CODIREQ) from asignacion"); while (tabla.next()) { cla = tabla.getInt(1); } tabla.close(); statement.close(); } catch (Exception e) { e.printStackTrace(); } System.out.println("Paso 5010"); return cla; } public void upEstado(int codireq, String codigo, String codires1, String codires2, String codires3, String nombrer, String descripcion, String tipo1, String tipo2, String tiemporesp, Connection conexion){ System.out.println("Paso 2383"); this.Codireq = codireq; this.Codicl = codigo; this.Codires1 = codires1; this.Codires2 = codires2; this.Codires3 = codires3; this.NombreR = nombrer; this.Descripcion = descripcion; this.Tipo1 = tipo1; this.Tipo2 = tipo2; this.Tiemporesp = tiemporesp; this.Estado = "ABIERTO"; System.out.println("Paso 2384"); Statement statement = null; System.out.println("Paso 2385"); ResultSet rs = null; try { statement = conexion.createStatement();
201
System.out.println("Paso 2386"); String a= "INSERT INTO `asignacion` VALUES ('"+ this.Codireq +"', '"+ this.Codicl +"','"+ this.Codires1 +"','"+ this.Codires2 +"','"+ this.Codires3 +"')"; System.out.println("Paso 2387"); String b= "INSERT INTO `requerimiento` VALUES ('"+ this.Codireq +"','"+ this.NombreR +"','"+ this.Descripcion +"', '"+ this.Tipo1 +"', '"+ this.Tipo2 +"', '"+ this.Tiemporesp +"','"+ this.Estado +"')"; System.out.println("Paso 2388"); statement.executeUpdate(a); System.out.println("Paso 2389"); statement.executeUpdate(b); System.out.println("Requerimiento registrado en Base de Datos"); statement.close(); } catch (Exception e) { e.printStackTrace(); } } private boolean ValidaRut() { // Se asume que es correcto para efectos del prototipo. boolean respuesta = true; return respuesta; } public boolean ValidaUsuario(Connection conexion) { System.out.println("paso 10"); String codcli = this.Codigo; String codbd = null; String Contracli = this.Contrasena; String Contrabd = null; // if (this.ValidaRut()) { //BUSCAMOS EN BASE DE DATOS LA INFO DEL CLIENTE.
202
Statement statement = null; ResultSet rs = null; try { statement = conexion.createStatement(); rs = statement.executeQuery("SELECT * FROM cliente WHERE CODICLI='"+ codcli +"'"); while (rs.next()) { codbd = rs.getString("CODICLI"); Contrabd = rs.getString("CONTRASENA"); } rs.close(); statement.close(); } catch (Exception e) { e.printStackTrace(); } if (codcli.equals(codbd) & Contracli.equals(Contrabd)) { System.out.println("paso 70"); return true; } else { System.out.println("paso 71"); return false; } } else { System.out.println("paso 72"); return false; } } }
203
XVIII.3 Reglas de Escalado
Las reglas de escalado se basan normalmente en la prioridad del incidente
y se deben establecer en función de los niveles de servicio acordados, de modo
que se pongan en marcha en cuanto se detecta el mínimo riesgo de
incumplimiento de dichos niveles de servicio acordados (ANS).
Es aconsejable el implementar estas reglas dentro del sistema de Gestión
de Incidentes para tener un control más riguroso del seguimiento de estas reglas.
Ejemplos de reglas de escalado:
Prioridad Crítica En el caso de un incidente con prioridad crítica, se informa de inmediato al
Gestor del Proceso de Gestión de Incidentes. El Gestor del Proceso de Gestión de
Incidentes debe realizar las siguientes acciones:
• Reunir un primer grupo de expertos con el objetivo de encontrar una
solución temporal al incidente lo antes posible.
• Informar al Cliente de la situación antes de la primera media hora.
• Escalar el incidente jerárquicamente si entramos en riesgo de incumplir los
niveles de servicio acordados, con el objetivo de tener informada a la
Dirección del incidente y obtener, si es necesario, las autorizaciones para
poder realizar los escalados funcionales que sean necesarios hasta la
resolución del incidente.
• Realizar un seguimiento continuo de la situación del incidente y mantener
informado al Cliente del estado del incidente periódicamente.
204
Alta Prioridad Las acciones a tomar en caso de un incidente de alta prioridad son las siguientes:
• Si el Equipo de Soporte Inicial es capaz de resolver el incidente durante los
primeros 10 minutos recurriendo a las herramientas a su alcance
(incidentes similares, errores conocidos, etc.) o a sus propios
conocimientos, etc., lo resuelve y cierra el incidente. Notifica al cliente de la
situación.
• Si el Equipo de Soporte Inicial no es capaz de resolver el incidente en los
10 primeros minutos, debe asignar y notificar el incidente a un equipo de
soporte de nivel superior, que debe resolver el incidente antes de 8 horas.
• El Equipo de Soporte Inicial debe informar al Cliente antes de 1 hora de la
situación.
• El Equipo de Soporte Inicial debe realizar un seguimiento del incidente a las
4 horas y a las 7 horas. Si comprueba que no se ha resuelto antes de las 7
horas, debe comunicárselo al Gestor del Proceso de Gestión de Incidentes
que deberá tomar las medidas oportunas con el fin de tener resuelto el
incidente a tiempo.
• Si el incidente no se resuelve a tiempo, el Gestor del Proceso de Gestión de
Incidentes debe comunicárselo al Cliente y decidir si el incidente debe
escalarse a crítico.
205
Prioridad Media Las acciones a tomar en caso de un incidente de prioridad media son las
siguientes:
• Si el Equipo de Soporte Inicial es capaz de resolver el incidente durante los
primeros 10 minutos recurriendo a las herramientas a su alcance
(incidentes similares, errores conocidos, etc.) o a sus propios
conocimientos, etc., lo resuelve y cierra el incidente. Notifica al cliente de la
situación.
• Si el Equipo de Soporte Inicial no es capaz de resolver el incidente en los
10 primeros minutos, debe asignar y notificar el incidente a un equipo de
soporte de nivel superior, que debe resolver el incidente antes de 24 horas.
• El Equipo de Soporte Inicial debe informar al Cliente antes de 4 horas de la
situación.
• El Equipo de Soporte Inicial debe realizar un seguimiento del incidente a las
4, 8, 16 y 23 horas. Si comprueba que no se ha resuelto antes de las 23
horas, debe comunicárselo al Cliente e incrementar la prioridad del
incidente.
Prioridad Baja Las acciones a tomar en caso de un incidente de prioridad baja son las
siguientes:
• Si el Equipo de Soporte Inicial es capaz de resolver el incidente durante los
primeros 10 minutos recurriendo a las herramientas a su alcance
(incidentes similares, errores conocidos, etc.) o a sus propios
conocimientos, etc., lo resuelve y cierra el incidente. Notifica al cliente de la
situación.
• Si el Equipo de Soporte Inicial no es capaz de resolver el incidente en los
10 primeros minutos, debe asignar y notificar el incidente a un equipo de
soporte de nivel superior, que debe resolver el incidente antes de 48 horas.
206
• El Equipo de Soporte Inicial debe informar al Cliente antes de 8 horas de la
situación.
• El Equipo de Soporte Inicial debe realizar un seguimiento del incidente a las
24, 36 y 48 horas. Si comprueba que no se ha resuelto antes de las 48
horas, debe comunicárselo al Cliente e incrementar la prioridad del
incidente.
XVIII.3.1 Escalado Funcional vs. Jerárquica
Otro factor que marca el ciclo de vida de un incidente es su sistema de
escalado con el objetivo de resolver el fallo y restaurar el servicio lo mas
rápidamente y sin impactar los ANS acordados con los clientes.
La “escalada” es el mecanismo que permite el traspaso de información y/o
la solicitud de actuación sobre una incidente a niveles prefedinidos y
especializados de resolución contribuyendo a que las incidentes sean resueltas a
tiempo.
El escalado puede tener lugar durante todas las actividades del subproceso
de diagnostico y solución.
Los tipos de escalado contemplados son:
Escalado funcional (horizontal) se busca mayor implicación funcional para la
resolución del incidente, recurriendo a otros especialistas de soporte con mayor
nivel de conocimiento. Se realiza generalmente desde un grupo de primera línea a
uno de segunda línea.
Escalado jerárquico (vertical) se transfiere la incidente a un grupo funcional de
mayor rango en la organización al objeto de obtener más información, y en su
caso, la autorización para utilizar más recursos.
