mejorando el delivery de servicios mediante el uso del ...un variado rango de empresas de...

Universidad Técnica Federico Santa María

Departamento de Informática

Magíster en Tecnologías de la Información

1

Mejorando el Delivery de Servicios Mediante el uso del Framework eSCM para Proveedores de TI

Ricardo Escares R.

Maipú, Región Metropolitana de Santiago

[email protected]

Resumen: El presente trabajo propone incorporar un conjunto de prácticas pertenecientes al framework eSourcing Capability Model eSCM(SP) con el objetivo de mejorar el Service Delivery del área de Servicios TI de una importante empresa multinacional, específicamente, para los proyectos de continuidad operativa. El caso de uso en estudio corresponde al manejo del servicio de outsourcing entregado a un cliente nacional que posee sistemas a cargo de la administración del proveedor de tecnología. Para el desarrollo de este proyecto se consideran tres dimensiones: la operación diaria (delivery), el capital humano asignado y el apropiado manejo del servicio. A partir la implementación de las prácticas eSCM-SP seleccionadas, se espera mejorar los niveles de satisfacción que actualmente se tiene con este cliente, así como también reducir el número de incidentes que se reportan durante la operación diaria. Para cuantificar la efectividad de las prácticas seleccionadas e implementadas se realizarán mediciones de Customer Satisfaction así como el análisis de la causa de los incidentes reportados durante un periodo de 6 meses distribuidos en tres escenarios (antes, durante y después). En este contexto, a medida que la relación cliente-proveedor madura, el cliente espera mayor especialización, conocimiento de su negocio y que la calidad del servicio aumente. Resulta importante mantener a los clientes con índices de satisfacción estables para sustentar el servicio en el tiempo Palabras Clave: TI, outsourcing, servicios, service delivery, capability model

1. Introducción

La industria de los servicios de tecnología de la información (TI) es un mercado altamente competitivo, existe un variado rango de empresas de consultoría que ofrecen servicios de tecnología a clientes del mercado local. Los clientes por su parte exigen cada día un mejor estándar de servicio que debe ser complementado por buenas relaciones que perduren en tiempo y sean sustentados por procesos eficientes. En la actualidad son muchas las organizaciones que deciden tercerizar parte de sus plataformas tecnológicas para dejarlas en manos de un proveedor con el objetivo de reducir costos [1]. Esto se conoce como Outsourcing. Este término posee distintas definiciones, de forma genérica, es un concepto que motiva a una organización a externalizar de forma parcial o total su operación a terceros. Si bien el outsourcing no es una práctica nueva - sus inicios remontan desde mediados del siglo pasado con foco en la industria industrial y de manufactura – En TI es utilizada desde los años 60s con la llegada de recursos computacionales compartidos y se mantiene hasta la actualidad con el movimiento de la operación completa de TI a un proveedor de servicios especializado [2] en ciertos casos, involucrando procesos críticos para el negocio del cliente. De acuerdo a Rotevery [3] las organizaciones buscan externalizar la operación de los servicios de tecnología de información como parte una su estrategia para concentrar esfuerzos en el core de su negocio. Si por alguna razón una empresa ejecuta algo que otros hacen mejor y pueden comprar, se está sacrificando una ventaja competitiva.




2

2. Hipótesis y Objetivos

2.2 Hipótesis

“La aplicación del modelo eSCM-SP en un proveedor de servicios TI permite mejorar la calidad de los servicios entregados al cliente por medio de la adopción de mejores prácticas con un enfoque específico a servicios de continuidad operativa para sistemas críticos de tecnología.”

2.3 Objetivo

Esta tesina tiene por objetivo aplicar las buenas prácticas del modelo eSourcing Capability Model for Service Providers (eSCM-SP), un Framework de TI diseñado específicamente para proveedores de servicios que muestra las bases para apoyar la gestión del outsourcing. Los siguientes son los objetivos específicos considerados en el desarrollo del presente trabajo:

• Identificar puntos de mejora en los procesos actuales del ciclo de entrega de servicios en el proveedor. • Proponer un conjunto de prácticas eSCM al ciclo de Delivery para servicios de continuidad operativa. • Aplicar dichas prácticas. • Analizar los resultados obtenidos.

2.4 Metodología para validar la Hipótesis

Con el objetivo de validar la Hipótesis, las prácticas seleccionadas serán implementadas en un contrato de servicios que se encuentre en curso. Durante un periodo de 6 meses distribuidos en tres escenarios (antes, durante y después) se realizarán mediciones para cuantificar su efectividad mediante el análisis de Customer Satisfaction, CSAT y el análisis del número de incidentes reportados por el cliente.

3. Organización del documento

El presente trabajo contempla la siguiente estructura:

• Introducción: descripción del contexto y el entorno para el desarrollo de la tesina. • Hipótesis y Objetivos: corresponde a la definición de objetivos y la hipótesis planteada así como también

su metodología de validación. • Marco Teórico y Estado del Arte: en este apartado se muestra el estado del arte de las técnicas asociadas

a la entrega de servicios TI. • Definición del Problema: se presenta el problema principal abordado con el proveedor de servicios

seleccionado. • Solución Propuesta: descripción de la propuesta de solución. • Aplicación: considera los pasos tomados en la aplicación de las prácticas seleccionadas según la descripción

del problema. • Conclusiones: muestra el análisis y resultados del estudio así como también recomendaciones para la

mejora en el delivery del servicio.

4. Marco Teórico y Estado del Arte

Existen diferentes modelos que buscan mejorar la calidad de los servicios del tipo eSourcing - se denomina eSourcing a aquellos servicios que involucren algún tipo de tecnología de información [4]. Ejemplo de estos modelos son ITIL, ISO 9001 y COBIT




3

ITIL (Information Technology Infrastructure Library), es un framework que fue creado por Central Computing and Telecommunications Agency (CCTA), una agencia estatal británica durante los años ochenta. Proporciona orientación a organizaciones de diversa índole sobre cómo utilizar los recursos de TI como una herramienta para facilitar el cambio, la transformación y el crecimiento del negocio. Aboga por que los servicios de TI estén alineados con las necesidades del negocio y apoyen sus procesos centrales [5]. Existen tres versiones de este framework, siendo v3 la más reciente (publicada en 2007). A lo largo de sus 5 volúmenes, se cubren los siguientes tópicos:

• Service Strategy (estrategia de servicios) • Service Design (diseño de servicios) • Service Operations (operación de servicios) • Continual Service Improvement (mejora continua de servicios) • Service Transition (transición de servicios)

En el contexto del área de Delivery de un servicio, el módulo que aborda la problemática del eSourcing es "Service Operations", capítulo que define procesos y ciertas prácticas para ofrecer servicios de mejor nivel tales como: Service Level Agreements (SLA), gestión de eventos e incidentes, así como también definición de funciones y responsabilidades de quienes operan el servicio. A modo general y dentro de sus ventajas:

• ITIL es bastante aceptado a nivel global, posee un enfoque basado en procesos y es bastante maduro en sus casi 38 años de existencia.

• Internamente, la organización desarrolla una mejor estructura, se vuelve más eficaz, alineada con los objetivos que dicha área presenta perseguir.

Entre sus desventajas:

• ITIL posee un estrecho enfoque en TI, dicho de otra forma, la organización debe adaptarse a una transformación.

• Al estar basada en procesos, requiere de un cambio cultural potente en todo nivel. Una implementación demasiado ambiciosa podría fallar si la empresa no está lo suficientemente madura.

Existe también el ISO 9001 [6], un estándar de calidad que las organizaciones utilizan para demostrar su capacidad de ofrecer consistentemente productos (muy utilizado en sus inicios sólo en la industria de manufactura) En la actualidad, gran parte de las empresas de diversa índole incluida aquellas de servicios poseen este certificado. La certificación implica que, dicha organización cumplen con los requisitos especificados. En concreto:

1. Tiene una política de calidad definida. 2. Establece procesos y procedimientos para realizar las operaciones. 3. Capacita a sus trabajadores para efectuar sus labores. 4. Pasa por auditorías internas y externas.

Si bien, los modelos anteriores se centran en las capacidades de diseño y entrega a través de procesos, ninguno de ellos comprende un modelo por etapas durante el ciclo de vida completo de la entrega de un servicio eSourcing. El estándar ISO 9001, corresponde a un modelo de calidad genérico. De acuerdo al trabajo de Kumar [7] obtenido en entrevistas con clientes y proveedores de servicios TI, se han identificado ciertos escenarios que son críticos para la implementación de modelos de eSourcing. • Manejar las expectativas de los clientes no es un trabajo fácil. Con frecuencia el cliente puede ser demasiado

demandante y el proveedor debe ser capaz de responder de acuerdo al nivel de servicio comprometido (SLA). El desarrollo de confianza es vital para establecer una buena relación con el cliente.




4

• Una de las causales más comunes del fracaso entre clientes y proveedores en el proceso de eSourcing son los términos y condiciones establecidos en el contrato, esto genera roces entre las reales expectativas del cliente y el servicio ofrecido. Si se incurre en ambigüedades es necesario iterar sobre extensiones contractuales que no están exentas de problemas.

• Manejar correctamente el “Know-How” dentro del equipo de trabajo con el ánimo de evitar el re-trabajo como resultado de una mala documentación interna del proveedor. La comunicación entre los integrantes del equipo juega un papel fundamental (para la transferencia de conocimiento y sincronización).

• Establecer elementos de diferenciación claves con respecto a otros proveedores de servicio para mantener el contrato siendo capaz de adaptarse rápidamente a los cambios que el cliente pueda requerir.

En este contexto, un estudio global conducido por KPMG en año 2015 [8] muestra que el nivel de satisfacción de los clientes que realizan outsourcing de servicios TI es de solo un 47% (cifra promediada). [Figura 1, KPMG] El nivel de satisfacción más bajo corresponde a aquellos clientes localizados en Europa con sólo un 44% de aprobación al servicio de outsourcing recibido. Los clientes que perciben un mejor servicio están localizados en América (EEUU, Canadá, México, Latinoamérica y el caribe) con un 53%.

Figura 1: Nivel de satisfacción del outsourcing de TI (Global), KPMG 2015.

Aunque los niveles de CSAT en América muestran una cifra nueve puntos porcentuales mayores a Europa, es un resultado que no alcanza a ser el deseable (nivel de satisfacción por sobre el 70%). Evidentemente existe un problema de fondo que debe ser atacado. Para ello es necesario entender las razones detrás de estos resultados. Kumar [7] sostiene los puntos críticos que deben ponerse sobre la mesa en pos de obtener clientes más satisfechos. McCray [9], presenta una mirada similar que podría explicar los niveles bajos de CSAT:

• Incapacidad del proveedor para cumplir con los compromisos establecidos en el contrato. • Poco conocimiento del alcance del contrato de servicios en ambas partes (cliente y proveedor). • Problemas de comunicación como resultado de un choque cultural. • Pérdida de miembros clave del equipo (know-how).

Para obtener mejores niveles de CSAT, resulta importante manejar de manera eficiente las acciones de los proveedores, así como también las expectativas de sus clientes para alcanzar un nivel de satisfacción aceptable y, principalmente relaciones de trabajo que perduren en el tiempo.




5

E-Sourcing Capability Model (eSCM) El framework en estudio corresponde al eSourcing Capability Model, desarrollado por el IT Sourcing Qualification Center (ITSQC) de la Universidad Carnegie Mellon en el año 2003 [11]. A diferencia de otros modelos, eSCM está diseñado exclusivamente para manejar la gestión del outsourcing de servicios de tecnología con foco en relaciones profesionales de largo plazo. Comprende todo el ciclo de vida del eSourcing (desde el inicio/contratación del servicio, delivery y finalización) y puede ser aplicado por los proveedores de servicios habilitados para TI en casi todos los sectores de mercado y áreas de servicio. El modelo completo consta de dos variantes:

• eSCM-SP: diseñado para proveedores durante el Delivery del servicio. • eSCM–CL: orientado a las organizaciones con el rol de cliente (quien contrata el servicio).

Esta propuesta se centra en el eSourcing Capability Model for Service Providers (eSCM-SP) cuyo objetivo es guiar a los proveedores de servicios TI a mejorar su modelo de servicio, reducir riesgos y mantener una buena relación con los stakeholders durante el ciclo de vida del servicio ofrecido. El framework tiene tres propósitos claramente definidos:

• Ser una guía para los proveedores mejorando sus estándares de servicio. • Proporcionar a los clientes un medio objetivo de evaluación de la capacidad del proveedor de servicios. • Crear valor por medio de la diferenciación competitiva.

ESCM-SP consta de 84 buenas prácticas que buscan la excelencia operacional distribuida en tres dimensiones: Sourcing Life Cycle, Capability Area, Capability Model. 1. Sourcing Life Cycle El ciclo de vida del eSourcing, se distribuye en 3 etapas (Iniciación, Delivery, Finalización):

Durante la etapa de Inicio , el proveedor del servicio en conjunto con el cliente define el alcance, condiciones contractuales y requerimientos del servicio a entregar. Una vez hecho esto se da inicio al servicio (fase de Delivery), que corresponde netamente a entregar servicio de acuerdo a lo comprometido. En la fase de Finalización el proveedor transfiere el Know How al cliente u otro proveedor de servicios que el cliente especifique. Las 3 etapas comprenden el ciclo de vida denominado Ongoing:

Figura 2: Sourcing Life Cycle (Ongoing).

Inicio Delivery Finalización




6

2. Capability Model: El ITSQ define cinco niveles de capacidad, siendo el Nivel 1 el más básico:

• El primer nivel no posee ninguna práctica asociada, es el punto de partida del Framework. Un proveedor que está en esta posición, es usualmente catalogado como riesgoso puesto que tiende a ofrecer más de lo que es realmente capaz de entregar.

• Las organizaciones que se encuentran en el segundo nivel poseen todas las prácticas del nivel 2 del modelo

aplicadas, siendo capaces de administrar más eficazmente su proceso de Delivery cumpliendo así con los requerimientos pactados, cuentan con algunos procesos definidos y poseen la infraestructura adecuada para entregar el servicio.

• El tercer nivel habilita a las organizaciones a ser capaz de gestionar el eSourcing en un nivel estratégico en

toda la organización. Son capaces de cumplir, e incluso exceder las expectativas del cliente en situaciones donde su experiencia puede no ser del todo completa.

• Una organización de nivel cuatro tiene un plan continuo de mejora, lo que da como resultado un mejor

desempeño en el Delivery del servicio. Aquellos proveedores que se ubican en este nivel son capaces no sólo de exceder las expectativas sus clientes, sino que además predecir su rendimiento.

• Finalmente, las organizaciones de nivel 5 se focalizan en mantener la excelencia operacional alcanzada. Si

bien el Nivel 5 no tiene ninguna práctica asociada, los proveedores deben permanecer a lo menos dos años con la totalidad de las prácticas del Nivel 4 implementadas.

Figura 3: Los cinco niveles de capacidad del eSCM (Hefley & Loesche, 2006, Hyder et al. 2006). 3. Áreas de Capacidad Finalmente, el modelo contempla Áreas de Capacidad que proporcionan agrupaciones lógicas de buenas prácticas. Los proveedores de servicios pueden entonces construir y/o demostrar capacidades en base a las siguientes Áreas: Contratación, Diseño y Despliegue de Servicio, Transferencia de Servicio, Entrega de Servicio , Gestión de Conocimiento, Gestión de Personal, Gestión de Desempeño, Gestión de Relaciones, Gestión de Tecnología, Gestión de Amenazas, Transferencia de Servicio. Esta matriz muestra el resumen según su distribución en el modelo eSCM-SP:




7

Tabla 1: Áreas de capacidad según eSCM-SP.

Fase Área de Capacidad No. de Prácticas

Iniciación Contratación Diseño y Despliegue de Servicio Transferencia de Servicio

21

Delivery Entrega de Servicio 8

Gestión de Conocimiento Gestión de Personal Gestión de Desempeño Gestión de Relaciones Gestión de Tecnología Gestión de Amenazas

51

Finalización Transferencia de Servicio 4

TOTAL PRACTICAS 84

Los beneficios de eSCM pasan por su flexibilidad. Al ser un modelo basado en prácticas. Un proveedor puede perfectamente aplicar parte de las prácticas del Nivel 3, sin necesariamente haber cumplido con todos los requerimientos del nivel anterior. Esto otorga mayor libertad a la organización para mejorar su Delivery donde más lo requiera en dicho momento. La figura 4 muestra la arquitectura del modelo sSCM:

Figura 4: Modelo eSCM-SP.




8

5. Análisis de la situación Actual Contexto

La firma en estudio es una importante compañía multinacional líder en la industria de las tecnologías de la información fundada a fines de los años setenta. El negocio de la empresa es la información – cómo administrarla, utilizarla, compartirla y protegerla. Durante más de cuatro décadas ha ofrecido el software para empresas más grandes del mundo.

La compañía ofrece una amplia gama de productos y servicios orientados a la implementación de los mismos por medio de su área de servicios.

En Chile, la subsidiaria tiene 30 años de trayectoria, ha consolidado una sólida presencia en el mercado nacional con más de 500 empresas que hoy son clientes. Cuenta 300 profesionales y una gran infraestructura, lo que le permite atender los requerimientos de productos y soluciones de sus clientes, así como también entregar un servicio de primer nivel en las áreas de soporte, educación y consultoría.

5.2 Definición del Problema

El área de Delivery de la firma, desarrolla y ejecuta una serie de proyectos de implementación de infraestructura TI, servicios de consultoría y de continuidad operacional a sus clientes en la región (LAD, Latin American Division). Internamente es una organización estructurada que cuenta con tres áreas técnicas de especialización (Middleware, Base de Datos y Systems), cada ellas tiene recursos dedicados para la ejecución de los proyectos y entrega de servicios.

En los últimos años, el área se ha fortalecido enormemente. Esto viene dado por un cambio de paradigma de la industria (mayoritariamente enfocada en servicios en lugar de implementación de infraestructura) para el caso de Chile, gran parte de la base de clientes cuenta con Infraestructura de primer nivel ya instalada. Por ende, hoy se requiere mayor foco en servicios de continuidad operativa con ingenieros especialistas para mantener adecuadamente dicha infraestructura y, al mismo tiempo apoyar al cliente en su operación diaria.

Advanced Customer Services, a pesar de mantener una buena estructura, para los proyectos de continuidad operativa requiere de mejores prácticas con foco en la excelencia de servicio. Existen puntos de mejora que son evidenciados en los siguientes escenarios:

• Baja estandarización de procesos y prácticas para mantener la operación de sistemas de misión crítica. • Escasa documentación de los problemas que se manifiestan durante operación diaria. • Preocupación constante acerca de las reales expectativas del cliente en relación al servicio. • En ciertos contratos, existe limitada capacidad para satisfacer las demandas del servicio establecidas por

contrato.

Para el caso en estudio, el servicio lleva una media de 1,5 años en ejecución, sin embargo, presenta uno de los niveles de satisfacción más bajos. A medida que la relación cliente-proveedor madura, el cliente espera mayor especialización, conocimiento de su negocio y que la calidad del servicio aumente. Resulta importante mantener a los clientes con índices de satisfacción estables para sustentar el área y asegurar nuevos contratos.

6. Propuesta de solución

Mediante el uso de un Framework de TI diseñado específicamente para proveedores, en concreto el eSCM (SP) sería posible mejorar la operación diaria para los proyectos de tipo eSourcing para el área de Delivery de la Firma y de esta forma enfrentar de mejor manera los puntos anteriores.

Los componentes técnicos de la solución se relacionan con la implementación de un conjunto de prácticas del modelo eSCM, en específico, la administración del servicio con foco en la operación diaria (Service Delivery) La principal contribución de este trabajo es mejorar la relación cliente-proveedor así como también mejorar los niveles de Customer Satisfaction. Se sugiere incorporar técnicas que apoyen a la organización a reducir la




9

problemática existente. El alcance de esta propuesta se basa exclusivamente en servicios de continuidad operativa que involucren manejar sistemas críticos ya sea on-site o de forma remota y que estén bajo la administración del proveedor seleccionado.

El cliente en particular es una importante empresa nacional que posee sistemas de tecnología a cargo de la administración de dicho proveedor. Los involucrados en el desarrollo de este trabajo son los siguientes (Proveedor):

• Technical Account Manager (TAM): Gerente de cuentas que proporciona la orientación técnica, planificación y gestión durante la ejecución de un proyecto. Trabaja directamente con el cliente durante el ciclo de vida del proyecto y/o servicio capturando requerimientos y necesidades de negocio. Mantiene comunicación el área comercial del proveedor y con el grupo de Support Engineers asignados al proyecto con el ánimo de mantener un apropiado control del mismo.

• Support Engineers (SE): Ingeniero de soporte avanzado que vela por el cumplimiento de las mejores prácticas de implementación recomendadas por el proveedor del servicio. En términos de operación diaria, son los ingenieros encargados de brindar el servicio y soporte técnico en el cliente asignado realizando análisis, consultoría y resolución de problemas complejos en ambientes productivos. Poseen amplio conocimiento de infraestructura tecnológica, sistemas middleware y operación de sistemas de misión crítica.

• Systems Engineers: Ingenieros especializados en la instalación y configuración de servidores y storage, optimización de recursos y sistemas localizados en Datacenter de terceros, entre otros.

6.2 Metodología de Trabajo La metodología de este trabajo considera aplicar parte de las buenas prácticas del modelo eSourcing Capability Model for Service Providers (eSCM-SP) para los escenarios identificados adaptado a los servicios de continuidad operacional del Proveedor (SP) en el cliente asignado (CL). En específico, se considera atacar la problemática existente en la operación diaria (fase Delivery/DEL.). Las prácticas del Service Delivery se centran en la entrega continua del servicio de acuerdo con los compromisos asumidos con el cliente y en función de su diseño. Esto incluye la planificación, ejecución y el seguimiento de las actividades del día a día. El conjunto de prácticas seleccionadas y ajustadas al caso en estudio según eSCM-SP son las siguientes:

DEL01: Planificar y hacer seguimiento del Service Delivery Plan (SDP)

• Considera la existencia de un “Service Delivery Plan” con el ánimo de mantener un registro con la planificación de las actividades y tareas asignadas al equipo en sitio. Para lograrlo, es necesario definir las actividades que serán parte de este plan.

• Verifica que las tareas están asignadas al personal correcto asegurando la cobertura establecida en el contrato. El equipo asignado debe contar con las herramientas necesarias para realizar su trabajo apropiadamente.

DEL02: Establecer e Implementar procedimientos para entrenar al cliente

• Proporciona medidas de capacitación al cliente y usuarios finales a fin de respaldar el uso efectivo del servicio.

• Permite que el cliente aproveche el servicio para lo cual fue diseñado y ayuda a mejorar la relación cliente/proveedor. Tiene un impacto directo en la satisfacción general del cliente.

DEL03: Entregar el servicio de acuerdo a lo establecido en el SDP

• Recomienda el uso del “Service Delivery Plan” para entregar el servicio acorde a lo contratado.




10

• Sugiere mantener una interfaz de comunicación eficiente con el cliente para facilitar el contacto cuando lo requiera y/o para atender solicitudes.

DEL05: Corregir problemas

• Prepara a la organización para solucionar problemas durante la cobertura del servicio rápidamente. • Supone de forma ideal eliminar el problema. • En caso de no ser posible implementar una solución definitiva, vela por implementar un fix temporal (o

workaround) con el objeto de minimizar el impacto.

DEL06: Prevenir problemas conocidos

• Esta práctica tiene foco en analizar los problemas encontrados en el pasado y tomar medidas para evitar que vuelvan a ocurrir y, en caso que ocurran minimizar su impacto.

• Las acciones preventivas generalmente intentarán eliminar la causa raíz de los problemas para evitar volver a tenerlos por medio de documentación eficiente: (problemas conocidos/Known Issues).

• Sugiere la implementación de técnicas para la elaboración de análisis de causa raíz (RCA, Root Cause Analysis).

6.3 Desarrollo de Proyecto Análisis de la situación actual. El primer paso de este proyecto considera realizar un levantamiento de información de los procesos actuales para la entrega de servicios. El foco de este trabajo se centra en el proceso de Delivery (ver Figura número 2: Sourcing Life Cycle) Sin embargo, resulta importante comprender la metodología actual para el despliegue del servicio desde la Fase de Iniciación. Fase Iniciación:

Para efectos de esta tesina, el inicio de un proyecto o servicio asume que la situación contractual, alcance y objetivos del servicio ya se encuentran definidos. Este proceso involucra:

Figura 5: Fase iniciación del servicio.

Contrato de servicios

3. Pre-venta del servicio

2. Diseño del Servicio

1.Levantamiento de las

necesidades del Cliente




11

De forma general, en el contrato de servicios se especifica la siguiente información:

- Detalle de los objetivos, alcance, cobertura, cantidad de horas disponibles - Acuerdos de nivel de servicios (SLA), - Modalidad de entrega del servicio on-site/remota, etc.

Fase Delivery: Una vez que se firma el contrato, se da inicio a la fase de Delivery del servicio. Esta fase considera:

Asignación de los miembros del Equipo: Se encuentra a cargo del Resource Manager, quien determina a su criterio la asignación de los ingenieros en base a la disponibilidad y competencias técnicas que el servicio requiere. Delivery del Servicio (día a día): Durante la operación diaria (fase Delivery, usualmente en las dependencias del cliente), es donde se producen la mayoría de los eventos descritos por Kumar [7] y McCray [9] Complementando los puntos expuestos en el Capítulo 5.2 (Descripción del problema), al momento de evaluar la situación actual se detectan las siguientes problemáticas:

• Expectativas reales del cliente no están cubiertas en el contrato de servicios. • El cliente no utiliza los medios apropiados para utilizar el servicio. • El equipo asignado al proyecto carece de herramientas/conocimiento para entregar adecuadamente el

servicio. • El servicio tiene un carácter reactivo, más que proactivo. • Pérdida de miembros del equipo debido al contante roce entre cliente y proveedor, existe alta rotación. • Niveles inferiores a la media de CSAT.

6.4 Aplicación de las Prácticas seleccionadas Con el objetivo de validar la hipótesis, estas prácticas deben ser aplicadas. A continuación, se presenta el detalle de las prácticas efectivamente aplicadas al caso en estudio teniendo en cuenta las particularidades de la organización:

DEL01: Planificar y hacer seguimiento del Service Delivery Plan (SDP) DEL02: Establecer e Implementar procedimientos para entrenar al cliente DEL03: Entregar el servicio de acuerdo a lo establecido en el SDP DEL05: Corregir problemas DEL06: Prevenir problemas conocidos DEL01: Planificar y hacer seguimiento del Service Delivery Plan (SDP) El uso de esta primera práctica supone la existencia de un Service Delivery Plan (SDP) Trabajando con el Technical Account Manager (TAM) de la cuenta, se implementó un plan de trabajo trimestral que tiene por objetivo cubrir las necesidades del servicio contratado.

Asignacion de los miembros del Equipo

Delivery del servicio




12

El primer paso de esta práctica involucra definir las actividades que serán parte de este plan. El SDP considera los siguientes puntos:

• Planificación y formato de los documentos (entregables) clave del servicio: o Revisión de configuración y rendimiento de ambientes (Assessments): documento que valida el

correcto funcionamiento de la plataforma tecnológica del cliente. Entrega recomendaciones y mejores prácticas según la documentación del proveedor de la tecnología.

o Parchado de software: documento que tiene como objetivo realizar una revisión detallada de los parches y hot fixes aplicados en la infraestructura y entrega recomendaciones con el listado de los parches que deben aplicarse

• Asignación de actividades para los ingenieros (SE) en sitio. • Revisión semanal de los incidentes reportados (issues ongoing). • Revisión de los casos de soporte abiertos por el cliente con Global Customer Support. • Planificación de reuniones con el cliente (área operativa) de carácter semanal. • Calendarización de reuniones con el área Gerencial y Comercial del servicio. • Reuniones de equipo (TAM e Ingenieros/SE).

El SDP podría tener variaciones de acuerdo a la operación diaria, sin embargo, los lineamientos principales ya se encuentran en definidos. El correcto uso de esta SDP ayuda a disminuir la improvisación dando paso a un servicio mejor estructurado. Entregables:

Se revisó la lista de actividades de los Ingenieros asignados al servicio y se determinaron fechas de entregas trimestrales para estos informes. Con el objetivo de mantener una estructura, se definieron los estándares en el formato de la entrega para los siguientes documentos:

• Revisión de configuración y rendimiento de ambientes (Assessments). • Parchado de software.

Esto ayuda a estandarizar el formato y disminuir las diferencias que podrían existir si no se cuenta con un formato tipo. Seguimiento de Casos de Soporte Se incorporó el seguimiento de los casos de soporte que el cliente mantiene abierto con Global Customer Support con el objetivo de mejorar los tiempos de resolución de los mismos aprovechando el dominio técnico de los ingenieros en sitio. Esto significa llevar un registro con cada uno de los casos de soporte que el cliente ha abierto durante la última semana, como se ilustra en la siguiente tabla:

Tabla 2: Seguimiento de casos de Soporte Global. ID Responsable Show

Stopper Descripción Product/Service

Type Status

3-17532 Producción SI OHS Error in Producción HTTP Server Review Update

3-17533 Producción NO Users created without a password

Identity Manager Close Initiated

3-17534 Producción SI OSB/SOA Transport Exception occurred

SOA Suite Work In Progress

3-17535 Producción SI Performance issues with WLS in Production

WebLogic Server Work In Progress




13

3-17536 Producción SI JVM Crash WebLogic Server Review Defect

3-17537 Producción NO OTD Issues Traffic Director Awaiting Internal Response

Con esto se logra identificar aquellos problemas que pueden ser resueltos por el equipo en sitio y contactar/notificar al área responsable con mayor celeridad. Existen algunos casos de soporte en donde se debe escalar directamente con los representantes de Global Customer Support ya que el ticket no está siendo actualizado regularmente o bien, necesita mayor visibilidad para acelerar su resolución. DEL02: Establecer e Implementar procedimientos para entrenar al cliente De acuerdo al levantamiento realizado, uno de los grandes desafíos desde la mirada del TAM y los Ingenieros asignados al servicio es trabajar con el cliente en su operación tecnológica diaria. En ocasiones se producen conflictos que podrían poner en riesgo la relación cliente/proveedor. Si bien, estos conflictos pueden resolverse rápidamente, es importante que existan ciertos lineamientos que ayuden a mantener una relación sana. La práctica DEL02/ Establecer e Implementar procedimientos para entrenar al cliente, establece un conjunto de acciones que ayudan a trabajar colaborativamente con el cliente:

• Educar al cliente en el correcto uso del servicio. • Establecer métodos de escalamiento. • Proveer información de contacto (especialmente para coberturas fuera de horario). • Vías de contacto para incidencias fuera de horario.

¿Cómo se logra esto? Realizando sesiones con el cliente y equipo asignado para dar a conocer la definición del servicio, así como los objetivos y alcances establecidos contractualmente. Las reuniones cubren los siguientes puntos:

• Definición del servicio, alcance y objetivos. • Métodos de contacto y escalamientos. • Track de actividades realizadas y pendientes. • Análisis de los issues ongoing, etc. • Levantamiento de requerimientos.

En este contexto, se educa al cliente para que saque el máximo provecho del servicio y busca que la relación entre ambas partes perdure en el tiempo. Una relación tóxica muy probablemente llevaría consigo un desgaste de todos los involucrados, pérdida de miembros del equipo del proveedor y aumenta la posibilidad de no renovación del servicio por un nuevo periodo. La matriz de escalamiento se encuentra disponible en el Anexo 1. DEL03: Entregar el servicio de acuerdo a lo establecido en el SDP La implementación y correcto uso de un plan de servicio (Service Delivery Plan) permite llevar un registro de las actividades que están en ejecución y aquellas que se encuentran pendientes. Esta práctica vela por el cumplimiento de los compromisos acordados con el cliente en tiempo y forma.




14

Para lograrlo, el TAM de la cuenta lleva un registro con las tareas y sus responsables. En caso de existir desviaciones, estas deben ser corregidas. Eventualmente y dadas las condiciones respecto al número de incidencias, tareas pendientes y carga de trabajo el equipo asignado podría tener variaciones en el número de integrantes. Bajo momentos de alta demanda, ya sea por el aumento de incidencias o planificación de actividades ya calendarizadas, el TAM podría gestionar apoyo con el Resource Manager para obtener la aprobación y el ingreso de ingenieros al servicio. Se han establecido métodos de contacto para el ingreso de requerimientos y solicitudes del cliente, en un principio fueron gestionadas directamente por los ingenieros en sitio, sin embargo, esto resulto ser ineficiente ya que ciertas actividades no estaban contempladas en el contrato de servicios. Visto de otra forma, se perdía el control de las tareas en ejecución y el TAM no tenía el registro de las actividades en ejecución. Después de analizar lo sugerido por eSCM, y ante la inexistencia de una herramienta de tickets, cualquier solicitud debe ser canalizada directamente con el TAM de la cuenta. DEL05: Corregir problemas Manejo de incidentes asociados a infraestructura: Debido a la naturaleza del servicio, durante el día a día pueden surgir problemas técnicos relacionados a la infraestructura tecnológica y el cliente requiera apoyo del proveedor. Se ha dispuesto de un completo sistema de alertas para realizar monitoreo proactivo de los distintos componentes de software que puedan poner en riesgo la operación del cliente. Para lograrlo, se utiliza una herramienta llamada Cloud Control. Funcionamiento de la herramienta: La herramienta posee un controlador central que actúa como motor central para ser administrado. Este motor central se denomina OMS (que despliega la parte web y funcional) y OMR (repositorio almacenado en una base de datos). Un agente monitoreo es instalado en cada una de las máquinas que forman parte del parque de servidores administrados. Una vez que los agentes están instalados y configurados en las máquinas, se deben descubrir los componentes de la infraestructura con el objetivo de administrarlos y definir umbrales. La definición de los umbrales viene dado por plantillas pre-definidas. Esto ayuda a acelerar el despliegue. Los siguientes puntos son parte de los umbrales definidos:

- Uso de memoria RAM, CPU de la máquina y de disco (file system). - Utilización de Heap para cada una de las JVM administradas. - Número de Hilos Pendientes/Stuck Threads para los servidores de aplicaciones. - Monitoreo del estado de salud de las Instancias (Up/Down).

Cuando los Targets están disponibles y los umbrales están definidos. El sistema es capaz de enviar alertas vía correo electrónico en caso de superar los niveles máximos definidos en el umbral con el detalle técnico del problema/incidente. El correo electrónico enviado por la herramienta tiene la siguiente estructura:




15

Tabla 3: Estructura de alerta enviada mediante correo electrónico

Event: Descripción con el resumen del problema Notification: Nombre del cliente Host=Maquina en donde se reporta el incidente Target type=Nombre del producto involucrado Target name=Nombre del target en donde sucede el problema Message=Mensaje de error Severity=Nivel del criticidad del evento Event reported time=Fecha y hora del incidente Platform=Plataforma (Windows, Linux, Unix) Operating System=Versión de sistema operativo Event Type=Tipo de alerta Update Details: Detalle del evento reportado

El correo electrónico contiene información de alto valor para el ingeniero de soporte en sitio (por ejemplo, el detalle de la máquina en donde sucede el problema, el producto/tecnología involucrado, el mensaje de error con la fecha y hora del incidente). Gracias a la configuración de esta alerta, es posible acotar los tiempos de resolución de incidentes manteniendo alertas proactivas en base a un agente de monitoreo. El ingeniero recibe la notificación en su bandeja de entrada y puede trabajar de manera inmediata en la resolución del problema. El Anexo N2 mantiene una muestra del correo enviado por el sistema de alertas. Resolución de problemas críticos En el evento de un incidente técnico mayor (severidad uno/critico, que pone en riesgo la operación del cliente), la organización debe estar preparada para enfrentar la resolución de problemas técnicos complejos y otorgar una solución al cliente. Bajo esta lógica, el equipo en sitio ha sido instruido para trabajar colaborativamente con el cliente en busca de una solución definitiva o proveer un workaround cuando es requerido. Para lograrlo, se forma una mesa de trabajo en donde participan los recursos técnicos del cliente (que conocen del negocio e impacto del problema) y el equipo técnico especialista por parte del proveedor del servicio. Gracias a las medidas de documentación implementadas (definidas en el SDP) de forma general se logra dar solución durante un periodo no superior a 2 horas desde la notificación al TAM de la cuenta o en caso contrario, diagnosticar el componente que presenta algún tipo de falla. En el caso que el problema sea de mayor complejidad y no se logre implementar una solución o workaround, bajo la sospecha de algún defecto en el producto de software o infraestructura, se ha dispuesto de medidas adicionales de apoyo para involucrar a un Ingeniero Avanzado de Resolución de Incidentes, ARE (Advanced Resolution Engineer) que tiene por objetivo apoyar al equipo de ingenieros en sitio para reducir el tiempo de resolución del incidente así como también reforzar el análisis técnico de la problemática en estudio (ver Figura 5).




16

Figura 6: Proceso de resolución de problemas complejos (Flujo de escalamiento interno para obtener a un Ingeniero Avanzado de Resolución de Incidentes.

El criterio de éxito de esta práctica viene dado por la reducción del número de incidentes reportados por el Cliente y los resultados del Customer Satisfaction, CSAT. DEL06: Prevenir problemas conocidos En el marco de la práctica anterior, resulta necesario contar con un documento de análisis de causa raíz (Root Cause Analysis, RCA) por cada uno de los incidentes que se presenten durante la operación diaria y que impacte o ponga en riesgo el negocio del cliente esto, con el objetivo de prevenir problemas similares en el futuro. eSCM/Delivery define:

• Crear y mantener procedimientos para tomar acciones preventivas. • Documentar e implementar los procedimientos.

El documento de RCA presenta un análisis detallado del problema en cuestión así como también el plan de acción para mitigar el problema de raíz. Se registrarán en dicho documento las incidencias reportadas por el cliente en su plataforma productiva. El registro de las incidencias considerará la descripción de esta, ambiente y versiones afectadas, las medidas llevadas a cabo para su resolución o mitigación, y una descripción detallada de su resolución.

1. Abrir un caso de soporte con Global Customer Support con el componente afectado

2. Dar aviso interno al Resource Manager y Business Manager para que estén al tanto de la situación con el objetivo de involucrar recursos adicionales para la rápida solución al problema

3. Escalamiento Interno al área de Global Customer Support y Delivery

4. Un líder técnico del equipo local podrá proveer apoyo para disminuir el tiempo de resolución.

5. Implementar la solución




17

La estructura del reporte implementado se muestra a continuación:

Tabla 4: Modelo de documento RCA

Reporte de incidente/Root Cause Analisys Nombre del Cliente Descripción Breve: Fecha incidente

Hora incidente

Severidad (Alta, Media, Baja)

Ambiente:

Componente (BD, WLS, JVM, SOA, OSB, OS, Otro)

ID incidente (Ambiente+Componente+ddmmyyyy)

Descripción incidente

(Proveer detalle técnico del problema, indicando síntomas e impacto en el negocio del cliente cuando sea posible)

Verificación del incidente

(Proveer evidencia de la ocurrencia : mensaje de error en logs, adjuntar screenshot)

Resolución (Proveer descripción de los pasos ejecutados para la resolución del problema)

Adicionalmente y como parte de esta práctica, se mantiene un registro con los problemas conocidos con el ánimo de reducir los tiempos de resolución en caso que el mismo problema vuelva a ocurrir. El contenido de estos informes se almacena en un repositorio interno de conocimiento en todos los involucrados asignados al servicio mantienen acceso. El criterio de éxito de esta práctica viene dado por la reducción del número de incidentes y la recolección de problemas conocidos (Known Issue).

7. Análisis y Validación de la Propuesta

En esta sección se presenta el análisis de las prácticas señaladas en el capítulo anterior. Estas fueron seleccionadas en el mes de Noviembre de 2017 e implementadas a partir de Enero de 2018 por un periodo inicial de 6 meses. Con el objetivo de evaluar la efectividad de estas prácticas eSCM.SP/Delivery, de forma cuantitativa, es posible medir sus resultados utilizando métricas tales como: Customer Satisfaction, CSAT y el análisis de la cantidad de incidentes reportados por el cliente en un determinado periodo.




18

Como se mencionó el capítulo 5.2 “Definición del Problema” de esta tesina, los niveles de CSAT se encontraban bajo la media en comparación con otros servicios de esta firma. Se establecieron tres escenarios para efectuar la medición:

• Escenario 1: Medición obtenida sin el uso de eSCM-SP. Escenario de Control (Diciembre 2017). • Escenario 2: Obtenida a partir del tercer mes luego de aplicar las prácticas eSCM-SP/Delivery

seleccionadas (Mes 3: Marzo 2018). • Escenario 3: Realizada al finalizar el sexto mes (post eSCM-SP/ Mes 6: Junio 2018).

Existen dos tipos de KPI involucrados en el análisis (KPI cualitativo y cuantitativo). A continuación, se presenta el detalle de estos indicadores. KPI Cualitativo/Customer Satisfaction:

• Facilidad para contactar al proveedor: mide el grado de facilidad para contactar al proveedor de servicios ya sea presencialmente, vía correo electrónico o tickets de soporte.

• Definido en una escala de 1 a 10. • Comunicación durante incidencias en progreso: considera la comunicación que el proveedor entrega al

cliente en medio de un incidente, como por ejemplo, actualizaciones de estado. • Definido en una escala de 1 a 10. • Calidad técnica: valida el conocimiento y la expertise técnica del ingeniero a cargo del incidente. • Definido en una escala de 1 a 10. • Profesionalismo: implica demostrar habilidades de trabajo, buen juicio y comportamiento adecuado, por

ejemplo: apariencia profesional y/o cordialidad. • Definido en una escala de 1 a 10.

KPI Cuantitativo/Customer Satisfaction:

• Efectividad de la solución: mide la calidad de la solución técnica entregada. Definido en una escala de 1 a 10

KPI Cuantitativo/Incidentes:

Los siguientes KPIs no son incluidos en la encuesta de satisfacción al cliente ya que son parte del análisis de la aplicación de las prácticas eSCM/Delivery para medir el número de incidentes reportados por el cliente.

• Cantidad de Incidentes: Cantidad total de incidentes ocurridas. Medido en cantidad / mes. • Cantidad de Incidentes Repetidos (Known Issue): Cantidad de incidentes que ya han ocurrido en el pasado

y que están previamente documentados. Medidos en cantidad / mes. • Tiempo de resolución de incidencias: considera el tiempo total invertido en la resolución de un

requerimiento/incidente, medido en horas desde la declaración del incidente.

Un incidente se define como un problema técnico que impacta la operación del cliente. Este podría ser de alta criticidad -definido como severidad 1- o bien - de criticidad media, definido como severidad 2. Resultados La siguiente tabla resumen presenta los resultados de CSAT obtenidos en los tres escenarios analizados:




19

Tabla 5: Customer Satisfaction (CSAT) periodo Diciembre 2017 a Junio de 2018.

KPI Escenario 1 (Control)

Escenario (Mes 3)

Escenario (Mes 6)

KPI Cualitativo

Facilidad para contactar al proveedor 5 6 7

Comunicación durante incidencias en progreso

5 7 7

Calidad técnica 6 7 9

Profesionalismo 7 7 8

KPI Cuantitativo

Efectividad de la solución 6 8 8

Customer Satisfaction (Delivery) 58% 70% 78%

Se presenta a continuación la tabla resumen con el número de incidentes mensuales reportados por el cliente, así como también, el número de incidencias ya conocidas/repetidas por el equipo en sitio (Known Issue):

Tabla 6: Análisis de Incidentes reportados por el Cliente. Periodo Diciembre 2017 a Junio de 2018

KPI Cuantitativo/Análisis Escenario 1 (Control)

Escenario 2 (Mes 3)

Escenario 3 (Mes 6)

Número de Incidentes/Mes 24 11 7

Número de Incidentes Repetidos/Mes (Known Issue) 0 4 2

Tiempo de resolución de Incidencias (*) 125 min 95 min 80 min

(*) Medición realizada para los incidentes críticos/severidad 1 y severidad 2. Análisis de KPIs Customer Satisfaction, CSAT El siguiente gráfico, muestra los niveles de Customer Satisfaction obtenidos según los escenarios definidos al inicio de este capítulo, ilustrados por medio de la Tabla 3:

Figura 7: Análisis de customer satisfaction, CSAT.

Escenario 1 Escenario 2 Escenario 3

Customer Satisfaction

(Delivery)58% 70% 78%

58%

70%78%




20

Se evidencia una notable alza en los niveles de satisfacción desde la medición obtenida en el Escenario de control. En específico, existe un incremento de 12 puntos porcentuales en los niveles de Customer Satisfaction desde el Escenario 1 al Escenario 2 (con 58% y 70% respectivamente). La comparación final desde el Escenario 1 al Escenario 3 (al finalizar el sexto mes) se muestra un incremento de 20 puntos en los niveles de CSAT, logrando un auspicioso 78% de aprobación al servicio entregado por este proveedor. Con estos resultados, el cliente percibe una mejora en la calidad del servicio entregado ya, al tercer mes de implementadas las practicas eSCM/Delivery. Con respecto al detalle de los KPIs involucrados en la medición, el desglose es el siguiente:

Figura 8: Análisis de KPIs, CSAT.

El análisis de los resultados de CSAT revela una importante mejora en los principales KPI evaluados según la percepción del cliente. Los resultados más notables corresponden a los siguientes indicadores:

- Facilidad para contactar al proveedor. - Calidad técnica para la resolución del requerimiento/incidente. - Eficiencia de la solución implementada.

La respuesta a estas mejoras en la evaluación está explicada por la introducción de las prácticas eSCM/Delivery Facilidad para contactar al proveedor: Al cliente le es más sencillo contactar a algún miembro del equipo del proveedor ya sea dentro del horario laboral y/o fuera de éste (explicado por la matriz de escalamiento/Anexo 1) Profesionalismo: El cliente evidencia una mejora la estructura al servicio lo que permite planificar, dar orden y cubrir todos los puntos críticos del servicio evitando la improvisación que se tenía en ciertos momentos previos a la implementación de eSCM/Delivery. Gracias a la implementación de revisiones trimestrales de los ambientes tecnológicos del cliente a nivel de configuración y rendimiento, el enfoque del día a día es más proactivo. En lugar de atender requerimientos full time, se da espacio a la propuesta de mejoras y mejor calidad de la infraestructura que soportan las aplicaciones de clientes.

0 1 2 3 4 5 6 7 8 9 10

Facilidad para contactar al proveedor

Comunicación durante incidencias en progreso

Calidad técnica

Profesionalismo

Efectividad de la solución





21

Mediante el uso de eSCM/DEL03, el equipo fue documentando las tareas y procesos solicitados con mayor frecuencia por el cliente posibilitando el trabajo fuera de horario. Si por alguna razón el equipo local asignado no está disponible en el turno fuera de horario, la persona que tomará el requerimiento estará en conocimiento de la solicitud así como también la secuencia de pasos para su correcta ejecución. El personal asignado al servicio presenta menor rotación lo que otorga continuidad y minimiza los riesgos, en el pasado, una gran cantidad de gente salió de este servicio debido a la poca planificación e improvisación del día a día. Análisis del Número de Incidentes Reportados por el Cliente

Figura 9: Número de incidentes reportados.

La gráfica anterior muestra una disminución en el número de incidentes reportados por el cliente a partir del tercer mes (Escenario 2). Estos resultados son consistentes con la aplicación del conjunto de prácticas eSCM/Delivery, particularmente DEL05: Corregir problemas y DEL06: Prevenir problemas conocidos, ambas asociadas a troubleshooting y resolución de incidentes. Los resultados obtenidos en el Escenario 3, evidencian una notoria baja en el número de incidencias mensuales (no superior a 7 incidentes mensuales) esto significa una reducción de un 71% en la atención de incidentes de carácter técnico, lo que posibilita liberar al equipo de ingenieros de estas labores. Es importante destacar que la media de incidentes antes de aplicar las prácticas eSCM/Delivery era de 24 incidencias mensuales (Escenario de control). Con respecto al análisis de la causa de origen de estos incidentes, se presenta a continuación un diagrama que contiene la suma total de los incidentes registrados en los tres Escenarios (42 eventos).

24

11

7

0

42


Número de Incidentes/Mes Número de Incidentes Repetidos/Mes (Known Issue)




22

Figura 10: Causa de origen de los incidentes reportados. Se revela que la principal causa de los problemas están asociados un error de configuración para conectar la infraestructura con las aplicaciones del cliente (20). La segunda mayoría se la llevan las aplicaciones que son desplegadas en los sistemas administrados por este proveedor (11). El tercer puesto lo ocupan los errores de capacity (7), es decir un mal dimensionamiento y entonación de la infraestructura, lo que lleva a problemas de rendimiento general. Finalmente, el tiempo de resolución de incidentes críticos catalogados como severidad 1 y/o severidad 2 también obtuvo una mejora, pasando de 125 minutos promedio a sólo 84 minutos para su resolución (medición obtenida a través del KPI “Tiempo de resolución de Incidencias”).

8. Conclusiones y Trabajo Futuro

Las validaciones realizadas permiten determinar que la puesta en marcha de las prácticas eSCM seleccionadas contribuye positivamente a mejorar los niveles de Customer Satisfaction, los resultados obtenidos muestran una mejora en este indicador que paso desde un 58% a un 78% de CSAT. En este contexto, el trabajo de tesina tuvo un impacto directo en la percepción del cliente mejorando el servicio entregado. En términos de operación diaria, y luego de aplicar la metodología eSCM, existe una mejor planificación del servicio sin dejar especio a la improvisación que se solía presentar. El número de incidencias reportó una notoria disminución posibilitando cambiar el enfoque del servicio hacia un trabajo más proactivo, de los 24 incidentes que se manejaban normalmente, se pasó a no más de 7 incidencias mensuales, lo que representa una disminución de un 71%. Como resultado de esta notoria baja, el equipo asignado al servicio dispone de mayor holgura para realizar revisiones de la infraestructura trimestralmente, proponer mejoras a la configuración de los componentes de software, planificar parchado de software base y actualizaciones. El modelo de resolución de incidentes basado en DEL05 resultó ser altamente eficiente. Si bien gran parte de los problemas son resueltos por el equipo local, en momentos y situaciones en donde se requiere mayor celeridad en el diagnóstico técnico (ya sea por el impacto operativo y/o monetario que el cliente y el TAM

0

5

10

15

20

Defecto/Bug de producto

Error de aplicación

Error de configuración

Capacity

Sistema operativo

Red




23

establezca) en dicho escenario, se hace uso del modelo de escalamiento interno establecido en la práctica DEL02. En este mismo contexto, se cuenta con mejores herramientas para realizar análisis de causa raíz. Esto no solo ayuda a prevenir problemas futuros atacando la causa del problema con exactitud, representa además una metodología para enfrentar problemas de alta complejidad mejorando los tiempos de resolución, un pilar fundamental para fortalecer la confianza que el cliente mantiene con el equipo del servicio. En líneas generales, la mejora en los niveles de satisfacción en conjunto con la baja del número de incidencias reportadas por el cliente, representan un positivo balance de las prácticas eSCM-SP/Delivery implementadas lo que constituye una mejora en la calidad del servicio entregado. Los objetivos específicos planteados en la sección 2.3 son logrados por medio de la identificación de mejoras en los procesos actuales del ciclo de entrega de servicios en el proveedor, la propuesta e implementación de las prácticas eSCM en el ciclo de Delivery sustentado por el análisis de los resultados que evidenciaron una sólida mejora en los niveles de Customer Satisfaction. Con estos antecedentes, es posible validar la hipótesis planteada en este trabajo tesina. “La aplicación del modelo eSCM-SP en un proveedor de servicios TI permite mejorar la calidad de los servicios entregados al cliente por medio de la adopción de mejores prácticas con un enfoque específico a servicios de continuidad operativa para sistemas críticos de tecnología”. Trabajo Futuro eSCM propone prácticas adicionales documentadas que podrían ser consideradas para este caso en algún futuro no sólo en servicios de continuidad operacional, sino que también podrían ser compatibles en proyectos de implementación de infraestructura. Algunas de las áreas candidatas a ser exploradas son: gestión de conocimiento (knowledge management) y el manejo del capital humano asignado al proyecto (people management). La primera área busca documentar las actividades y tareas importantes para entregar el servicio de acuerdo a lo comprometido, así como llevar un apropiado repositorio de recursos técnicos y de apoyo a los procedimientos como parte del ciclo de ongoing en un proyecto/servicio, mientras que la segunda permite a mantener un apropiado registro de los conocimientos (skills) del equipo asignado al proyecto de modo que puedan efectuar correctamente sus labores. Su uso es un aporte para el resource manager para obtener un mapa de competencias técnicas de su equipo.




24

Referencias Bibliográficas

Las principales fuentes de información para el desarrollo de esta propuesta son las siguientes: [1] E. Beulen, Understanding transition performance during offshore IT outsourcing, Strategic Outsourcing, 2011.

[2] J.-N. Lee, The evolution of outsourcing research: what is the next issue?, 2002.

[3] B. Rothery, The Truth About Outsourcing, 1995.

[4] W. E. Hefley, eSourcing Capability Model for Client Organizations, 2010.

[5] F. O. I. (. Practices), NA, Van Haren Publishing, 2011.

[6] B. Poksinska, The state of ISO 9000 certification: A study of Swedish organizations, 2002.

[7] C. M. U. Mark C. Paulk, Measurement and the eSourcing Capability Model for Service Providers V2, 2005.

[8] K. Research, «Infographic Outsourcing: The radical new world of outsourcing for technology-related services,» KPMG, 2015.

[9] S. McCray, «The top 10 problems with outsourcing implementations (and how to overcome them),» 2008.

[10] Gartner, «Market Share Analysis: IT Outsourcing Services, Worldwide, 2016,» Gartner, 2017.

[11] I. S. Q. Center, «eSourcing Capability Model for Service Providers (eSCM-SP) v2,» Carnegie Mellon University, 2003.

[12] ITIL, «ITIL Service Design, 6.5.5 Sourcing Governance».




25

ANEXOS

ANEXO 1: Modelo de escalamiento

ANEXO 2: Correo electrónico enviado por el sistema de alertas:

Event: Warning: WLS_SERVER02 – The value of Health is Component:threadpool,State:HEALTH_WARN,MBean:ThreadPoolRuntime,ReasonCode: [ThreadPool has stuck threads] Notification: Customer Name 12:56 PM (8 minutes ago) SUMMARY: Host=ax-fmw110006.customer.com Target type=WebLogic Server Target name=/XYZCL_fmwservices/fmwservices/WLS_SERVER02 Categories=Capacity Message=The value of Health is Component:threadpool,State:HEALTH_WARN,MBean:ThreadPoolRuntime,ReasonCode:[ThreadPool has stuck threads] Severity=Warning Event reported time=Jun 25, 2018 11:54:15 AM CLT Line of Business=Customer Services Platform=x86_64 Operating System=Linux Event Type=Metric Alert Event name=ME$WLS_SERVER_HEALTH:WLS_ServerHealth Metric Group=ME$WLS_SERVER_HEALTH Metric=WLS_ServerHealth Metric value=Component:threadpool,State:HEALTH_WARN,MBean:ThreadPoolRuntime,ReasonCode: [ThreadPool has stuck threads] Key Value= Rule Name=WebLogic Server Alerts GTD,WLS Health Rule Owner=SYSADMIN Update Details:




26

The value of Health is Component:threadpool,State:HEALTH_WARN,MBean:ThreadPoolRuntime,ReasonCode:[ThreadPool has stuck threads]

ANEXO 3: Reglas de monitoreo proactivo creadas para el monitoreo de la Infraestructura

ANEXO 4:

Incidentes reportados por la herramienta

mejorando el delivery de servicios mediante el uso del ...un variado rango de empresas de...

Documents