Introduccion A Servicios De Gestion De Aplicaciones

Servicio de gestión de
aplicaciones o AMS
“Como gestionar un servicio en forma
ordenada y predecible”

Agenda
► Presentación Personal
► Marco de referencia
• Que es un servicio de soporte de aplicaciones o AMS
• Ventajas y desventajas del outsourcing
• Tipos de delivery
►Componentes del servicio
• Modelo de Gestión del Servicio
• Esquema de Gobierno y Roles & Responsabilidades
• Ciclo de Vida – Entregables
• Knowledge Transfer
• Alcance detallado- Especificación de servicio
• SLAS y penalidades
►Complementos
• Change Management y BPM
•Esquema basado en prácticas

► Grupo de profesionales con mas de 25 años de experiencia en TI brindando servicios en
compañías como Texaco, Grant Thornton, EDS, Grupo ASSA , Neoris y Estratega.
►Experiencia en definición y gestión de proceso de TI y servicios de Outsourcing de gestión
de aplicaciones tanto a nivel local como regional para empresas como Arcos Dorados,
AstraZeneca, Pfizer, Johnson & Johnson, Kraft Foods, Molinos Rio de la Plata, Arcor, Owen
Illinois, DirecTV, Southern Peru Cooper Corporation, Telefónica de Argentina entre otras.
►Definición de centros regionales de soporte (nivel I, II y III) de aplicaciones y gestión de la
demanda. Capacitación en temas de Project Management y Outsourcing de aplicaciones.
►Evaluación de madurez de procesos (ITIL, CMMI, PMI, COPC)
►Definición e implementación de metodologías formales para administrar servicios .
►Generación de propuestas comerciales y contratos de alcance regional.
►Generación y Control de contratos de TI, RFP, RFQ y SLAs
Quienes somos

► Nombre – Empresa
► Cliente o Proveedor
► Experiencia en AMS
► Presentación en 15 seg !!!
Quienes son
Cliente Proveedor Servicio

Qué entendemos por AMS
AMS (Application Management Services) o servicio de outsourcing de
gestión de aplicaciones por parte de un proveedor.
En este sentido el cliente terceriza una función suya, manteniendo el
control del producto final y la calidad del servicio.
Entendemos por gestión de aplicaciones al soporte correctivo, evolutivo,
solicitudes y consultas de aplicaciones y , eventualmente , a su operación.

Qué entendemos por AMS
Se rompió.
Lo dejas andando?
Como se hace?
Quiero algo nuevo.
Lo agregas?
Todos los días
ejecutá…
Se rompió.
Lo arreglas definitivamente?
Gestión de Incidentes Gestión de Problemas
Gestión de Requerimientos
Consultas
Gestión de Solicitudes

Beneficios del modelo de AMS
► Beneficios estratégicos
 Liberar de tareas recurrentes y que no agregan valor a recursos claves de TI para
focalizarlos en actividades que acompañen a los negocios y a la estrategia de TI
 Preparar a TI para nuevos requerimientos de negocio (escenarios de M&A,
nuevas unidades de negocio, etc.)
 Incrementar satisfacción de usuarios
 Ventajas competitivas
► Beneficios operativos
 Reflejar los tipos de acuerdos que TI tiene asumidos con sus clientes internos
 Garantizar un servicio proactivo, que además de resolver las consecuencias,
busque las causas de los problemas para prevenir su repetición
 Minimizar esfuerzo en la gestión de múltiples proveedores a través de procesos
estandarizados de operación y control
 Delegar la gestión de los equipos de soporte y concentrarse en el cumplimiento
de los niveles de servicio acordados
 Mejorar al calidad de la aplicación a través del tiempo

Beneficios del modelo de AMS
► Beneficios en gestión de recursos humanos
 Equipos de trabajo con continuidad operativa
 Mitigar dependencia de recursos con conocimientos cautivos
 Disponibilidad de un mix de recursos con conocimiento de las aplicaciones y
procesos del cliente asignables a nuevos proyectos y variaciones de demanda
 Focalizar a TI del cliente en entender, conocer y especializarse en los negocios
de sus clientes interno, delegando el conocimiento específico de las aplicaciones
en los proveedores
► Beneficios económicos
 Costos conocidos y predecibles
 Atención de las metas de mayor eficiencia del servicio y reducción de costos a lo
largo de la prestación del servicio
 Disminución de costos de recursos propios focalizados en la operación de
soporte

Tipos de Delivery - Staffing
Cliente Proveedor Entregables
► Se proveen recursos capacitados
► No hay valor agregado por parte del proveedor
 Metodología
 Procesos
 Seguimiento de fechas y entregables
► La responsabilidad de cumplimiento de compromisos y entregable es del cliente
► SLAs muy acotados
Equipo mixto liderado x clienteEquipo del proveedorEquipo del cliente

Tipos de Delivery - Servicio
Servicio acordado
► Mayor control por parte del cliente
► Menor riesgo para el negocio y el servicio
► Estrategia probada para la futura reubicación de recursos
► Proveedor responsable de los compromisos de fecha y calidad
 Metodología
 Procesos
 Seguimiento de fechas y entregables
Cliente Proveedor Entregables
Equipo del proveedorServicio solicitado

Mantener Revisar
Re ingeniería Tercerizar
ESTRATÉGICO NO ESTRATÉGICO
COMPETITIVONOCOMPETITIVO
?
Anexo-Matriz de Sourcing
Respecto al Servicio
RespectoalequipodeTI

“He comprendido
Que lo que árbol tiene de florido
Vive de lo que tiene
Sepultado”.
Francisco Luis Bernárdez
Poeta y diplomático argentino
Componentes

► Modelo de gestión
► Modelo de gobierno
► Roles y responsabilidades
► Ciclo de vida de un servicio
► Entregables
► Alcance detallado
► Acuerdo de nivel de servicio (SLA)
Componentes
Modelo de
Gestión
Modelo de
Gobierno
Roles&
Responsa
bilidades
Ciclo de
Vida
Entrega
bles
Alcance
detallado
SLA
Servicio

Modelo de Gestión del servicio
DEMANDA
PROCESOS
Gestión de
Incidentes
Mesa de Ayuda Gestión de
la Demanda
Usuarios, Áreas de
negocio y técnicas
Incidentes
Problemas
Consultas
Requerimientos de
negocio o legales
Incidentes
Problemas
Consultas
Requerimientos de negocio
o legales autorizados y
priorizados
CONTROL
Gestión del Servicio
Incidentes
Problemas
Consultas
Requerimientos de negocio
o legales autorizados y
priorizados
Gestión de
Problemas
Gestión de
Requerimientos
Consultas
Gestión de
Solicitudes
Proyectos

► La “capa de demanda” se refiere a las áreas que utilizan los servicios de soporte.
Estos se gestionan a través de la “Mesa de ayuda” (requerimientos o incidentes) o a
través de la “Gestión de la demanda” (Evolutivos o proyectos).
► La “capa de procesos” es la que ejecuta el delivery del servicio. Dependiendo del
tipo de solicitud, lo procesa : Soporte correctivo, Soporte evolutivo o Proyecto.
► La “capa de control” revisa y gestiona el cumplimiento y normal desenvolvimiento
del servicio.

Principales componentes del modelo
 Mesa de Ayuda: Principal punto de contacto entre el servicio de Soporte y los
usuarios, donde se reciben, registran y derivan todos los llamados. Responsable de
un seguimiento activo del incidente hasta su resolución. Puede resolver
incidentes de Nivel 1 (repetitivos, de rápida resolución)
 Nivel 2 o Soporte Correctivo: Resolución de incidentes de mayor complejidad y
análisis de problemas. Mediante parametrizaciones, “work around” o corrección
menor de código.
 Nivel 3 o Soporte Evolutivo: Desarrollo de mejoras funcionales, requerimientos
legales , corrección de defectos y otros desarrollos. Principalmente el análisis,
presupuesto, desarrollo, implementación, documentación y capacitación sobre
aquellas mejoras realizadas. Son el escalamiento natural del Nivel 2

 Gestión de la Demanda: Responsable de recibir todos los requerimientos
relacionados con los servicios aplicativos, de infraestructura y centro de
competencias del cliente, de su análisis y priorización.
 Proyectos: está relacionado con requerimiento que por variables tales como:
alcance, esfuerzo, impacto, etc. necesitan de un plan y modelo de gobierno
independiente.
 Gestión del servicio de AMS: es el componente que controla y gestiona el
cumplimiento del servicio. Administración de métricas y recursos, de niveles de
servicio acordados y relacionamiento con el cliente

“El personal determina el potencial del equipo.
La visión determina la dirección del equipo.
El trabajo determina la preparación del equipo.
El mando determina el éxito del equipo”.
John C. Maxwell
Experto en temas de Liderazgo
Modelo de Gobierno

► Este modelo define los niveles de jerarquía y escalamiento que gobiernan el servicio.
► Formado por comités con diferente grado de responsabilidad compartida en el
servicio.
► Permite definir claramente el esquema de relacionamiento y comunicación.
► Muestra el esquema de gestión de la demanda del cliente y la relación con el equipo
del servicio
► Existen diferentes modelos de acuerdo a la estructura de IT del cliente (centralizado,
descentralizado, centro de competencias, etc.).
► A continuación mostramos los componentes del esquema de gobierno.
Modelo de Gobierno

Modelo de Gobierno
Equipo de
Servicio
Director
Gerente o
Responsable
Líder
Comité
Dirección
Gestión
Operativo
Aéreas
usuarias
Directores
Gerentes
usuarios
Líderes o
Key users

www.estratega.org
Sponsor
CSC
Gerente
CSC
CIO LATAM
CFO LATAM
Gerente Sistemas
Aplicaciones
Empresariales x país
CIO país
Gobierno
CSC
regional
Ejemplo – Comité de Gobierno regional

www.estratega.org
Sponsor
CSC
Gerente
CSC
CIO LATAM
CFO LATAM
Gerente Sistemas
aplicaciones
CIO x país
Comité de
Gobierno
Comité de
Gestión de la demanda
Ejemplo – Comité de Gobierno regional

www.estratega.org
Gerente
CSC
Gerente Sistemas
aplicaciones
Gestión de la demanda
Referente, Analista,
Focal Point
Focal Point, Key user
 Factibilidad Funcional
 Factibilidad Técnica
 Revisión de Alternativas
 Revisión económica-financiera
 Revisión económico-financiera
 Aprueba
 Prioriza
 Planifica

www.estratega.org
Comité de Gobierno
Trimestral
CIO LATAM – CFO LATAM (opc.) - Sponsor CSC
Analizar resultados, tendencias. Ajustar el modelo del servicio, Aprobar y Planificar
futuros cambios
Gestión de la Demanda
 Estratégica
 Mensual
 Gerente de aplicaciones empresariales x país – Gerente CSC
 Aprobación, priorización y re planificación..
 Operativa
 Semanal
 Analistas de Negocio País – Líder Evolutivo – Funcionales (opc.)
 Revisión del Backlog - Revisar estado de avance de tareas operativas
Revisión del Servicio
Mensual
Gerente de aplicaciones empresariales x país – Gerente CSC – Sponsor CSC (opc.)
Analizar nivel de servicio e información de gestión. Revisar performance, issues y
riesgos del servicio
Plan de Comunicación

Yo hago lo que usted no puede y usted hace lo que yo
no puedo.
Juntos podemos hacer grandes cosas”.
Madre Teresa de Calcuta.
No hace falta presentación
Roles & Responsabilidades

► Su importancia radica en que define claramente el alcance de las tareas de cada
rol , tanto del equipo de soporte como de las áreas usuarias
► Durante el Start Up de cada servicio, este esquema se adapta a las particularidades
de cada cliente.

Gerente del Servicio:
► Administra el servicio en lo referido a su definición o conformación y gestión.
► Gestiona los recursos en su área de atención.
► Provee del estado de progreso a la dirección reportando métricas, riesgos e issues del servicio.
► Monitorea el cumplimiento del contrato.
► Apalanca el cumplimiento de roles & Responsabilidades del equipo de servicio y usuarios.
► Genera y revisa los indicadores mensuales del mismo.
► Escalamiento de temas diarios que requieren su participación.
Líder del Servicio:
► A cargo de la supervisión diaria del servicio.
► Foco en el cumplimento del SLA y en el seguimiento de las acciones definidas.
► Administra las tareas diarias de resolución de incidentes evolutivos y correctivos.
► Priorización y planificación.

Mesa de Ayuda- Soporte Nivel 1:
► Respuesta a preguntas “Cómo Hago…”
► Solución de problemas funcionales sin cambios en el customizing / parametrización.
► Documentación de instructivos de operación.
► Registro de los requerimientos y de las soluciones brindadas en la herramienta de gestión de
incidentes.
Soporte Nivel 2 - Correctivo:
► Corrección de funcionalidades existentes que involucren cambios menores en el customizing
/ parametrización.
► Corrección de programas que no involucren un cambio en el alcance original del desarrollo.
► Extensión de la funcionalidad existente vía customizing / parametrización que no involucre
cambios de estructura o que su impacto sea mínimo.
► Consultas al proveedor del ERP (SAP, Oracle, otro).
► Aplicación de notas correctivas del proveedor del ERP.
► Registro de soluciones en la herramienta de gestión de incidentes.
► Solicitud de transportes o pasajes entre ambientes.

Soporte Nivel 3 - Evolutivo:
► Implementación de nuevas funcionalidades o mejoras a las existentes (Estimar, analizar, diseñar,
desarrollar, testear y documentar)
► Definición de cambios en la aplicación tanto funcionales como técnicos.
► Soporte a pruebas de aceptación
► Registro de soluciones en la herramienta de gestión de incidentes.
► Transferencia de conocimientos a la Mesa de Ayuda y al grupo de Soporte correctivo.
Gestión de la Demanda:
► Recibe todos los requerimientos relacionados con los servicios aplicativos, de infraestructura y
centro de competencias del cliente.
► Analiza y prioriza junto a áreas internas de la compañía.
► Aprueba estimación o presupuesto.
► Punto de contacto para priorizaciones o cambios de alcance
Otra áreas:
► Administración de Perfiles y Seguridad.
► Gestionar transportes y releases.
► Mantenimiento y Administración de ambientes de Producción y QA.
► Administración de hardware y software de base.

Ciclo de vida
Fase 1
Estrategia
Fase 4
Operación
Fase 5
Cierre
Fase 2
Diseño
Fase 3
Transición
Del delivery
Del Servicio OperativoSoporte
Knowledge
Transfer
Preparación
Operación inicial
Revisión y Ajuste
AdministrativoOperaciones
Mejora Continua de Procesos
Prácticas de Project Management
Prácticas de Ingeniería de Software
Del cliente

TransiciónDiseñoEstrategia
KT de producto y
BPM
Métricas y Métodos
de medición
Implementar
Infraestructura
Y herramientas
Implementar
planes y
procedimientos
Aprobación
Fase
Obtener
recursos
Actualizar
procesos y
planes
Implementar
procesos de
control de servicio
Problem
management
Change
management
Configuration
management
Release
management
Ajustar la
Especificación del
servicio y SLA
Actualizar métricas
Revisión de la
estrategia
Estrategia de
soporte y Delivery
Identificación de
stackeholders
Esquema
de costos
Revisar situación
actual
Planeamiento
inicial
Del
Delivery
Del
Cliente
Planes &
Procedimientos del
servicio
Risk Assessment
Herramienta de
control y KM
Revisión de
infraestructura
Ajuste del
Servicio
Análisis inicial
Roles &
Responsabilidades
Planeamiento
inicial y modelo de
gobierno
Definir
estrategia
Knowledge
Transfer
Diseño
del Servicio
Preparación
Operación
Acotada
Service desk
Incident
management
Integración y Mejora Continua del Servicio
Desarrollar la
oferta
Definición de Especificación de
Servicio , SLA, disponibilidad,
capacidad, seguridad
Ciclo de vida

Identificación y
registro
Registro y
clasificación
Investigación y
diagnostico
Resolución
inmediata
o derivación
Seguimiento
Cierre
Clasificación
soporte inicial
Investigación y
diagnóstico
Resolución
recupero
Cierre Cierre Cierre
RFC Aprobación
Identificación y
registro
Recepción y
estimación
Clasificación
Investigación y
diagnóstico
Aprobación x CAB
Priorización y
planificación
Operación
Service Desk
Incident
Management
Problem
Management
Change
Management
Cierre
Operativo Administrativo
Alcance y
Planificación
Cierre de
Pendientes
Transferencia de
conocimiento
Entrega del
servicio
Servicio
Entregado
Revisión del
Servicio
Lecciones
aprendidas
Revisión de QA
Cierre
Administrativo
Servicio
Finalizado
Integración y Mejora Continua del Servicio
Ciclo de vida
Procesos de fábrica, Gestión de la Configuración y de los Releases

Proceso de Knowledge Transfer
Integración y mejora continuaIntegración y mejora continua

FASE 1 FASE 2 FASE 3
100%
20%
100% 100%
20%
100%
Equipo saliente Equipo entrante
FTE
Tiempo
Esta distribución puede cambiar de acuerdo a cada servicio
Proceso de Knowledge Transfer

► La gestión del servicio se manifiesta a través de una serie de entregables formales.
► Un entregable es un activo organizacional (guías, planes, templates) adaptado al
servicio.
► A continuación mostramos los principales entregables del servicio en cada Fase del
Ciclo de vida.
Entregables

► Estrategia
 Propuesta técnica
 Catálogo del servicio
 Análisis de la Demanda organizacional
 Gestión financiera
 Risk assessment
► Diseño
 Planilla de tailoring del nuevo servicio
 Especificación de Servicio y SLA o indicadores
 Políticas y Flujos de procesos (incidentes, problemas, requerimientos,
Operaciones)
 Procesos de fábrica, Modelo de estimación.
 Plan de Capacitación (KM), Comunicaciones y Calidad
 Plan de Disponibilidad, Seguridad, Capacidad
 Documento de modelo implementado
 Documento de criticidad de procesos de negocio – BPM
Entregables

► Transición / Operación
 Reporte de avance semanal
 Reporte de avance mensual
 Análisis anual del servicio y encuesta de satisfacción
 Agendas y Minutas
 Log de issues y acciones
 Documentación de requerimientos e incidentes
► Cierre
 Plan de la etapa
 Transferencia de conocimiento
 Análisis final del servicio y encuesta de satisfacción
 Lecciones aprendidas
Entregables

► Al alcance detallado de cada servicio define los compromisos asumidos por el
proveedor del servicio ante el cliente/área usuaria respecto al servicio a entregar.
► Debe ser lo suficientemente detallado y específico para que no haya
ambigüedades y dudas al momento del delivery.
► Todo cambio al servicio se realiza sobre este alcance base.
► A continuación una serie de componentes del alcance a definir
Alcance detallado o Especificación de Servicio

Aplicaciones a dar soporte:
► Nombre
► Versión
► Módulos soportados
Líneas de servicio dentro del alcance:
► Mesa de ayuda
► Soporte correctivo
► Soporte evolutivo
► Proyectos
► Gestión del servicio
► Obtención, extracción y publicación de indicadores
► Otros
Líneas de servicio fuera del alcance:
► DBA, Security
► Soporte hardware y software de base

Herramientas de gestión:
► De incidentes y evolutivos (RFC)
► De Configuration Management
► Otras
Locaciones a dar el servicio:
► Países
► Horarios
► Idiomas
Servicios extras:
► Soporte “on site” en casos especiales
► Apoyo de consultoría adicional y puntual, basado en tiempo y materiales con tarifas
previamente acordadas
► Soporte Evolutivo- soporte a demanda, planificado, con costo adicional
► Guardias: Tipos y esquema
• Tipo: On call (Pasivas) / On site (Activas)
• Esquema : 7 x 24 – de 18 a 22 -
• Alcance: Solo incidentes críticos; Solo las fechas de cierre On site

Usuarios soportados:
► Por país,
► Región
► Aplicación
► Módulo
Línea base de horas contratadas:
► Por mes , año o periodo
► Por Línea de servicio
► Tendencia de cambio (decreciente, creciente)
Línea base de incidentes, solicitudes, requerimientos:
► Por Línea de Servicio
► Por mes , año o periodo
► Por criticidad
► Tendencia s(decreciente, creciente)

Acuerdo de Nivel de Servicio - SLA

► Conceptos a considerar en la definición del SLA
 Tiempo Atención: Es el tiempo en el cual se comienza a realizar una análisis de la
Incidencia, este tiempo no supone la solución de la misma.
 Tiempo Solución: Es el tiempo en el cual se brinda solución a la Incidencia comunicada con
por Cliente.
 Umbral Requerido: Define la cota mínima OBJETIVO del servicio bajo la cual el proveedor
tiene que explica acciones para llevar el servicio a un nivel aceptable
 Umbral inaceptable: Define la cota mínima bajo la cual se da por incumplido el SLA.
 Métrica: Valor que mide el cumplimiento del SLA.
Acuerdo de Nivel de Servicio o SLA

► Para medir la gestión del servicio y como herramienta fundamental para su
correcta planificación y dimensionamiento.
► La base para medir el nivel de servicio es el cumplimiento porcentual de los
tiempos máximos objetivos para la resolución de un incidente de acuerdo a su
criticidad .
► En este sentido se proponen una serie de criterios y métricas estandarizadas. Las
mismas se generan en la herramienta de gestión de incidentes para lograr obtener
valores objetivos y claros.
► A continuación se muestran diferentes modelos para la definición de un Acuerdo
de nivel de servicios (SLA).

► SLA Simple
 Solo se miden los tiempos en base a un único indicador por criticidad.
 Se propone un único umbral de objetivo/ cumplimiento.
 Puede ser que el cliente no tenga como medir el tiempo de atención. En ese caso se
mide solamente el tiempo de resolución.
 Los tiempos a medir son únicamente los insumidos por el proveedor del servicio
Criticidad Tiempo de
Atención
Tiempo de
resolución
SLA
1- Error Critico 2 h 4h 95%
2- Error Severo 2 h 12 h 90%
3- Error Moderado 2 h 24 h 85%
4- Error Leve 2 h 40 h 85%

► SLA con Umbrales
 Se proponen umbrales de penalización (inaceptable) y objetivo (requerido)
 Umbral requerido: No hay penalidad pero el proveedor tiene que explicar porque no
se cumplió y que acciones va a realizar para mejorar el indicador.
 Umbral Inaceptable: Es el piso a partir del cual se aplican penalidades . Mas adelante
explicamos el esquema de penalidades.
Criticidad Tiempo de
Atención
Tiempo de
resolución
Umbral
requerido
Umbral
inaceptable
1- Error Critico 2 h 4 h 95% 80%
2- Error Severo 2 h 12 h 90% 75%
3- Error Moderado 2 h 24 h 85% 70%
4- Error Leve 2 h 40 h 85% 70%

► SLA diferentes por criticidad
 Puede haber diferentes indicadores por criticidad del proceso de negocio o módulo,
donde se definen cuadros de Nivel de servicio diferenciales por cada grupo.
Criticidad – Grupo 1 Tiempo de
Atención
Tiempo de
resolución
SLA
1- Error Critico 2 h 4 h 95%
4- Error Leve 2 h 40 h 85%Criticidad – Grupo 2 Tiempo de
Atención
Tiempo de
resolución
SLA
1- Error Critico 2 h 6 h 90%
4- Error Leve 4 h 56 h 70%

► SLA por Ponderación Impacto/Urgencia
 Para poder aplicar un SLA de porcentajes, la cantidad de incidentes por criticidad sea
lo suficientemente grande como para que la medición por porcentajes sea aplicable.
 En el caso de que la ocurrencia no sea representativa se propone aplicar la siguiente
tabla de SLA, midiendo la cantidad de incidentes mas solucionados
IMPACTO
URGENCIA
MAYOR
Pone en riesgo al negocio e impacta…
· A mas de 3 servicios críticos y/o…
· A más de 100 usuarios y/o…
· A todos los usuarios críticos
Tiene impacto económico o ante
entes gubernamentales
No existe workaround
MEDIO
Genera una amenaza para el
negocio e impacta…
· De 1 a 3 servicios críticos y/o…
· Entre 20 y 100 usuarios NO
críticos y/o…
· A un grupo de usuarios críticos
BAJO
No impacta en el negocio pero…
· Afecta a uno o varios servicios NO críticos
· Afecta a menos de 20 usuarios NO críticos y a
ningún usuario crítico y/o…
· Puede resolverse de manera planeada
ALTA Prioridad 1 Prioridad 2 Prioridad 3
MEDIA Prioridad 2 Prioridad 3 Prioridad 4
BAJA Prioridad 3 Prioridad 4 Prioridad 5

► SLA por cantidad de defectos
 Para poder aplicar un SLA de porcentajes, la cantidad de incidentes por criticidad sea
lo suficientemente grande como para que la medición por porcentajes sea aplicable.
 En el caso de que la ocurrencia no sea representativa se propone aplicar la siguiente
tabla de SLA, midiendo la cantidad de incidentes mas solucionados
Cantidad de incidentes Acción
1 a 10 No se mide el SLA
11 a 20 Se acepta 1 solo incidente mal solucionado
21 a 30 Se aceptan solo 2 incidentes mal solucionados
Mas de 30 Aplica SLA de porcentajes

► SLA con indicadores incrementales
 Una opción cada vez más utilizada es la de proponer indicadores con un enfoque
incremental del nivel de servicio que acompañe la maduración del mismo. La estrategia
es subir el nivel de servicio en forma bimestral hasta llegar a un nivel operativo final.
Nombre Universo Período
Transición Mes 4 a 5 Mes 6 a 7 Mes 8 a 9 Resto
% de resueltos
en tiempo
Por cada ticket cerrado en el período,
se suman los tiempos en que estuvo
del lado del proveedor. Se divide por
la cantidad de tickets cerrados
Solo se mide
Urgente-75%
Alta- 70%
Media-60%
Baja-60%
Urgente-80%
Alta- 75%
Media-65%
Baja-65%
Urgente-90%
Alta- 80%
Media-70%
Baja-70%
Urgente-95%
Alta- 90%
Media-80%
Baja-80%
Satisfacción del
cliente
Índice de Satisfacción según encuesta
periódica
75% 80% 85% 90%
% de Rework Por cada ticket cerrado se suma la
cantidad de veces que tuvo que ser
reabierto
Urgente-75%
Alta- 70%
Media-60%
Baja-60%
Urgente-80%
Alta- 75%
Media-65%
Baja-65%
Urgente-90%
Alta- 80%
Media-70%
Baja-70%
Urgente-95%
Alta- 90%
Media-80%
Baja-80%
Estimaciones en
tiempo
Cantidad de estimaciones realizadas
en plazo vs total de estimaciones
solicitadas
75% 80% 85% 90%
Hitos finalizados
en plazo
Cantidad de hitos entregados en
plazo vs total de hitos del periodo
75% 80% 85% 90%

Modelo de Penalidades
# Componente Definición y mecanismo
1 ¿Cuáles son los componentes que se
medirán para declarar una
penalización?
Se medirá el cumplimiento del SLA de cada uno de
los niveles de severidad de los incidentes y
desarrollos evolutivos. Esto genera 4 bloques de
niveles de servicio para su cumplimiento:
Incidentes severidad 1
Incidentes severidad 2
Incidentes severidad 3 y 4
Desarrollos menores (evolutivo)
2 ¿Cuándo se declara que el SLA no se
cumplió?
Cuando por dos meses consecutivos o mas de 2 en cualquier
momento en alguno de los 4 bloques de niveles de servicio no
llega a su valor mínimo acordado por motivos imputables al
proveedor.
3 ¿Cuándo se aplicaría una
penalización?
Cuando en un mes se declare que el SLA no se cumplió.
¿En qué consistirá la penalización? Se reducirá el 1% de la facturación mensual por cada uno de
los 5 bloques de nivel de servicio que no cumpla con el
acuerdo
¿Cómo se reportará un incumplimiento
de SLA?
El proveedor mensualmente generará los reportes de gestión
del servicio donde se incluirá la sección de Incumplimiento de
SLA’s. En esta sección se hará explícito que SLA no se
cumplieron, una explicación del causal del por qué no se
cumplieron y una acción que mitigue dicho causal.

► ITIL® suele utilizarse como marco para definir los procesos de definición y operación
del servicio.
► PMBOK® del PMI suele utilizarse como marco para definir los procesos de gestión
del servicio.
► BPM – Business Process Management. Es un enfoque holístico que permite
optimizar los procesos de negocio de una organización
► People Management. Gestión del cambio en las personas
Enfoque

Mejores Prácticas
60
ITIL V3 (IT Infrastructure Library)
• Es un conjunto de mejores prácticas para la implementación de
servicios de TI.
CMMI (Capability Maturity Model)
• Modelo de madurez que evalúa las capacidades de las organizaciones
de ingeniería de sistemas y de software, además del desarrollo del
producto y del proceso.
PMBoK (Project Management body of Knowledge)
• Es una guía que contiene las mejores prácticas definidas por el PMI
para una correcta Gestión de Proyectos organizada en áreas de
conocimiento.

Mejores Prácticas adicionales
61
IAOP (International Association of Outsourcing
Professionals)
• Es un conjunto de mejores prácticas para la gestión de
servicios tercerizados, desde la definición hasta la
generación de contratos
ISO 20000 (IT-Service management)
• Estándar de Calidad para la Gestión de Servicios de TI .
Fuertemente alineada a ITIL

Relación con PMI – Grupo de Procesos
Monitoreo y
control
Inicio
Planificación
Ejecución
Cierre

Relación con PMI
Areas
Alcance
Tiempos
Calidad
Riesgos
Comunicac
iones
Costos
RRHH
Compras
Integración

► BPM se pueden introducir a lo largo del ciclo de servicio para agregar valor a:
 Gestión de incidentes
 Desarrollo evolutivo,
 Proyectos embebidos en el servicio,
 A la propia evolución del cliente en su madurez en la gestión de procesos.
► Los componentes BPM a incluir en cada servicio dependerán de las
características del servicio de gestión de aplicativos (por ejemplo su alcance y
tipo), de la madurez BPM de la organización cliente, y otros factores como
evolución de la relación con el cliente.
Actividades de BPM

Knowledge
Transfer
Diseño
Operación inicial
Preparación
Ajuste
Operativo
Administrativo
Modelado de
Procesos de
Negocio
Selección y
Priorización
Documentación
de los Procesos
de Negocio
Procesos de
Incident
management
Lecciones
aprendidas
KT de procesos
BPM Plan del
servicio
Business Process Management
Procedimientos
orientados a la
Gestión de la
demanda
Implementación
de repositorio
AMS
Procesos de
Problem &
Change
management
Evolución de
los procesos de
negocio
Actividades de BPM
Soporte
Operaciones
Diseño CierreOperaciónTransición

► People Management facilita la transición del servicio, reducir sus riesgos,
mejorar la integración con el equipo de IT y de usuarios del cliente y con otros
participantes del servicios si intervienen en la cadena de valor (por ejemplo un
help desk externo, o de un Centro de Servicios del cliente, o los servicios de
plataforma e infraestructura provistos por el área de tecnología del cliente o por
un tercero).
► Los componentes People Management a incluir en cada servicio dependerán de
las características del servicio de gestión de aplicativos (por ejemplo su alcance y
tipo), de los desafíos específicos de People Management de la organización
cliente como hábitos previos de soporte y evolución de procesos y aplicaciones,
relación entre IT y/o el prestador previo y las áreas usuarias, y otros factores
como evolución de la relación con el cliente.
Actividades de People Management

NO CONOZCO
NO PUEDO
NO QUIERO
PLAN DE
COMUNICACIÓN
TRAINING
COACHING

Identificación de
Stakeholders
Evaluación
Organizacional
Team building
Monitoreo y
Coaching
Lecciones
Aprendidas
Ajuste
Organizacional
Entrenamiento
People Management processes
Ajustes
Organizacionales
Comunicación
AMS
Acciones
Correctivas
Operación inicial
Preparación
Ajuste
Operativo
Administrativo
Soporte
Operaciones
Diseño CierreOperaciónTransición
Knowledge
Transfer
Diseño

►Objetivos del Área
 Definir las características principales de los servicios AMS
 Desarrollar e implementar una metodología única y común para el delivery de
los servicios de Application Management.
 Esto incluye procesos, documentación y herramientas que van a usar los
proyectos de Applicaton Management Services como así también monitorear
su implementación y medir los resultados.
 Soporte Preventa y start up de servicios
 Revisiones de calidad – soporte en desarrollo de findings
 Capacitación
Área de procesos

►Actividades
 Investigar mejores practicas del mercado y competencia
 Definir, Desarrollar y mantener la metodología
 Herramientas: Seleccionar, implementar. Mantener la metodología en
herramienta corporativa
 Capacitar e Implementar en las cuentas
 Revisar su uso. Publicar Métricas de Servicios unificadas
 Coaching a nuevos gerentes
 Soporte venta
o Información institucional
o Brochure
o Marketing
o Preventa
o Asignación de recursos
o Relación con otras prácticas
Área de procesos

Como se implementa?
► Evaluación y diagnóstico de estado de los procesos
 Basado en mejores prácticas del mercado
 ITIL v3 para los procesos de TI
 CMMI para los proceso de ingeniería de producto
 PMI para la gestión de proyectos o servicios
 IAOP para la definición de servicios de Outsourcing y contratos
 De una evaluación previa se define la estrategia de evaluación y las mejores prácticas
a utilizar
 Puede ser todos los procesos de TI o solo un grupo de procesos puntuales, por
ejemplo : Service Desk, Incident y Problem Management
 Entrega de diagnóstico inicial comparado con las mejores practicas seleccionadas
► Recomendaciones :
 En base a los marcos teóricos seleccionados y, fundamentalmente a la experiencia de
los consultores y grado de madurez del cliente se realizan una serie de
recomendaciones para salvar la brecha entre la situación actual y la deseada.
 Las mismas tienen un alto grado de detalle y criterios de agrupamiento cómo prioridad,
esfuerzo, área de aplicación, etc.
► Acompañamiento en la ejecución :
 Finalmente, si el cliente lo desea, acompañamos la ejecución de las recomendaciones.

Como se implementa?
Preparación
Evaluación
Recomendación
Capacitación
Mejora de
Procesos
Mejora
continua

Resultados
0
1
2
3
4
Finanzas
Portfolio de Servicios
Demanda
Disponibilidad
Capacidad
Continuidad
Seguridad
Proveedores
Catálogo de Servicios
Niveles de Servicio
Planeamiento y soporte a la
Transición
Evaluación
Validación y Pruebas del
Servicio
Entregas y Despliegues
Cambios
Conocimiento
Configuración
Accesos.
Peticiones
Eventos
Problemas
Incidentes
Aplicaciones
OperacionesTI
Service Desk
Técnica
Medición del Servicio
Reporte de Servicios
ProcesosMejora Continua
Actual
Deseable
Situación deseada vs situación actual
Resultado de revisión por área de conocimiento

Resultados
Recomendaciones por diversos parámetros
16
74
48
Esfuerzo
1-Alto
2-Medio
3-Bajo
75
54
8
Prioridad
1-Alta
2-Media
3-Baja
(en blanco)
55
59
23
Plazo
1-Corto
2-
Mediano
3-Largo

Resultados – Recomendación ejemplo
Marco referencial: ITIL
Área de conocimiento: ESTRATEGIA - G. de la Demanda
Situación: No se registran ni analizan patrones de actividad del negocio.
Recomendación: Establecer objetivos y métricas definidas para medir el desempeño de la infraestructura en
base a patrones de actividad del negocio.
Tomar mediciones históricas como parámetros, analizar su necesidad de actualización en virtud de crecimiento
vegetativo o nuevos negocios y definir umbrales de acción. Adicionalmente definir, para cada acción, los
responsables y su tiempo de ejecución. Anualmente revisar objetivos y métricas.
Mejora obtenida: Establecer metas y umbrales para tomar acciones correctivas y verificar las necesidades de
cambios en la infraestructura en base a cambios en los patrones de utilización. Desarrollar modelos predictivos
de crecimiento que pueden ser verificados antes de comprometer la provisión del servicio.
Prioridad: Media
Esfuerzo: Mediano

Workshop de recomendaciones
Finalmente las recomendaciones se muestran y analizan en un
workshop con los interesados e involucrados donde se revisan:
 Detalle de recomendación
 Criticidad y Prioridad
 Cronograma de implementación

Entregables
► Acompañamiento en la ejecución de las recomendaciones
 Nos comprometemos con las recomendaciones definidas
 Desarrollo , en conjunto, del plan detallado para la ejecución.
 Podemos ser el líder de proyecto o acompañar a este como soporte
experto
 Referentes de las mejores practicas seleccionadas o sugeridas
 Capacitación a equipos de trabajo
 Gestión de cambio
 Documentación de procesos
 Entrega de guías y templates
 Adaptación del marco teórico a las políticas, estrategias y limitaciones
de la empresa
No le dejamos un documento . Nos comprometemos con la ejecución
de las recomendaciones y lo ayudamos a su ejecución para lograr
resultados concretos y visibles

Donde encontrarnos
Web: www.grizzuti.com.ar Mail: pablo@grizzuti.com.ar Twitter: @GrizzutiyAsoc
Linkedin: Pablo Grizzuti Celular: 54 9 11 4173 2602 Skype: Pablo.grizzuti

Introduccion A Servicios De Gestion De Aplicaciones

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (9)

Similaire à Introduccion A Servicios De Gestion De Aplicaciones

Similaire à Introduccion A Servicios De Gestion De Aplicaciones (20)

Dernier

Dernier (20)

Introduccion A Servicios De Gestion De Aplicaciones