UNIVERSIDAD NACIONAL FEDERICO VILLARREAL ESCUELA

INGENIERA DE SISTEMAS

EVALUACIN DEL CASO: TAFI GROUP

UNIVERSIDAD NACIONAL FEDERICO VILLARREAL CURSO DE ACTUALIZACIN PROFESIONAL UNFV

PER, 2016

Profesor: Ing. Rodolfo Cubas Agreda

Presentado por:

AGUILAR PINEDA, ERICK MAX

GORDILLO ARROYO, EDISON PERCY

MARQUINA MEDINA, CRISTIAN

MUJICA CHIRINOS, MAYRA MILAGRITOS

 Contenido
IMPLEMENTACIN DE SOLUCIN: CASO TAFI GROUP: ...................................................................... 3
1. Service Desk: ............................................................................................................................... 3
2. Gestin de Incidentes:................................................................................................................. 7
3. Gestin de Problemas: ................................................................................................................ 8
4. Gestin de Cambios: ................................................................................................................... 9
5. Gestin de la Configuracin: ..................................................................................................... 17
6. Gestin Financiera..................................................................................................................... 19
7. Gestin de Release .................................................................................................................... 20
8. Gestin del Nivel de Servicio: .................................................................................................... 23

2
IMPLEMENTACIN DE SOLUCIN: CASO TAFI GROUP:

1. Service Desk:

Se sugiere la implementacin de Service Desk con estructura Centralizada (figura 1) debido

a que TAFI cuenta con sucursales en provincia y una sede central en Buenos Aires, que es
donde se encuentra el personal del Departamento de TI.
Al contar con el departamento de TI en Buenos Aires, permitir que podamos tener mejor
banco de recurso humano, mejor capacitado y actualizado. El personal tendra siempre la
informacin a primera mano sobre alguna actualizacin de los Sistemas de Informacin.
No obstante, se debe considerar que los sistemas de informacin son accedidos por las
PCs con arquitectura cliente / servidor; con lo que la estructura centralizada limitara de
cierta forma, la actualizacin de algn aplicativo, comparndose con la arquitectura web.
Se puede mencionar algunos de los beneficios que se obtiene de la estructura centralizada
de un Service Desk:

Manejo de base de datos centralizada de incidentes

Menor tiempo de respuesta ante eventualidades
Manejo de informacin conjunta y / consolidada.
Menor cantidad de departamentos por lo tanto ms rentable.

Figura 1. Modelo de Estructura Centralizada de Service Desk.

3
Teniendo en cuenta que el departamento de TI gestiona soporte de infraestructura,
aplicaciones propias y de terceros se sugiere implementar 4 lneas de soporte.

Primera Lnea: Help Desk

Segunda Lnea: Soporte de Infraestructura
Tercera Lnea: Soporte de Aplicaciones
Cuarta Lnea: Servicio de Proveedores
A continuacin se detalla las principales funciones y estructura de grupo de trabajo para
cada una de las lneas de soporte.

1) Primera Lnea: Help Desk

En esta primera lnea encontramos al personal encargado de gestionar y solucionar todas
las incidencias de manera ntegra, apoyndose de recursos como base de conocimiento,
registros previos entre otros. Esta primera lnea entra en funcionamiento desde la recepcin
de la llamada por algn requerimiento, incidencia o asesora y tiene como alcance todas las
sucursales de TAFI.
Principales funciones:
Recepcionar requerimientos o incidencias de usuarios.
Gestionar la atencin y resolucin de la incidencia.
Diagnstico y categorizacin de la incidencia.
Resolver dudas o consultas de usuarios.
Controlar tiempos de atencin para evitar colas en mesa de ayuda.
Derivar la incidencia al grupo de soporte que corresponda.
Dar seguimiento a las incidencias que hayan sido derivadas a grupos de soporte.
Verificar operatividad de medios de comunicacin entre sucursales y help desk.
Help Desk designado a provincia debe especializarse en los aplicativos que
maneja su respectiva sucursal.
En el caso no exista requerimiento de sucursales, deben funcionar como
contingencia de soporte a la casa central.

4
Grupo de Trabajo:
Se presenta la siguiente propuesta de Grupo de Trabajo Help Desk
Ubicacin Equipo Horario de Atencin C/Persona C/Equipo
Buenos 06 Help Desk Lunes a 7:00am a 7:00pm 1,200 7,200
Aires 02 Help Desk Sbado 7:00pm a 7:00am 1,500 3,000
02 Help Desk Lunes a 7:00am a 7:00pm 1,200 2,400
Rioja
02 Help Desk Sbado 7:00pm a 7:00am 1,500 3,000
01 Help Desk Lunes a 7:00am a 7:00pm 1,000 1,000
Crdoba
01 Help Desk Sbado 7:00pm a 7:00am 1,200 1,200
01 Help Desk Lunes a 7:00am a 7:00pm 1,000 1,000
Tucumn
01 Help Desk Sbado 7:00pm a 7:00am 1,200 1,200
16 Help
TOTALES S/.20,000
Desk

2) Segunda Lnea: Soporte de Infraestructura

A esta lnea de soporte llegan todos los requerimientos relacionados a infraestructura que
la primera lnea no haya podido dar solucin. Para la atencin de estas incidencias en
provincias se requiere persona de forma presencial, de esta forma habra unidad de Soporte
de Infraestructura en todas las sucursales, rompiendo un poco la estructura centralizada
del Service Desk.
Principales funciones:
Resolver incidencias no resueltas
Registrar bitcora de incidencias de infraestructura
Monitorear la calidad de la infraestructura
Verificar y analizar configuraciones establecidas en la infraestructura
Aplicar configuraciones a dems usuarios para evitar futuros incidentes
Grupo de Trabajo:
Se presenta la siguiente propuesta de Grupo de Trabajo Soporte Infraestructura
Ubicacin Equipo Horario de Atencin C/Persona C/Equipo
Buenos 05 Soporte Lunes a 7:00am a 7:00pm 1,500 7,500
Aires 02 Soporte Sbado 7:00pm a 7:00am 1,700 3,400
02 Soporte Lunes a 7:00am a 7:00pm 1,500 3,000
Rioja
02 Soporte Sbado 7:00pm a 7:00am 1,700 3,400
01 Soporte Lunes a 7:00am a 7:00pm 1,200 1,200
Crdoba
01 Soporte Sbado 7:00pm a 7:00am 1,400 1,400
Tucumn 01 Soporte 7:00am a 7:00pm 1,200 1,200

5
 01 Soporte Lunes a 7:00pm a 7:00am 1,400 1,400
Sbado
TOTALES 15 Soporte S/.22,500

Tercera Lnea: Soporte de Aplicaciones

A esta lnea de soporte llegan todos los requerimientos relacionados a las aplicaciones con
las que cuenta TAFI, ya sean las que se adaptaron mediante el equipo de TI o de las que
fueron implementadas por terceros y an mantienen vigencia con los mismos. En esta lnea
tambin se analizan modificaciones respecto a los sistemas de informacin que maneja
TAFI. Todo el personal de esta tercera lnea labora en Buenos Aires con lo que fortalece a
la estructura centralizada de Help Desk.
Principales funciones:
Resolver incidencias no resueltas
Registrar bitcora de incidencias de aplicaciones
Recibir y analizar requerimientos para mejoras en los sistemas de informacin
Verificar vigencia de licencias de aplicativos de terceros.
Mantener entornos de trabajo diferenciados con sucursales debido a que cuentan
con adaptaciones distintas
Grupo de Trabajo:
Se presenta la siguiente propuesta de Grupo de Trabajo Soporte Infraestructura

Ubicacin Equipo Horario de C/Persona C/Equipo

Atencin
03 Diseador Funcional Lunes 7:00am 2,000 6,000
Buenos
03 Diseador Tcnico a a 2,000 6,000
Aires
10 Programadores Sbado 7:00pm 1,500 15,000
TOTALES 16 Soporte S/.21,000

Cuarta Lnea: Soporte de Proveedores

A esta lnea de soporte llegan todos los requerimientos relacionados con servicios de
externos que no hayan podido ser solucionados por el departamento de TI, debido a no
contar con fuentes de aplicativos o no contar con licencia adecuada o que no se encuentre
al alcance de TAFI como problemas con telefona o conexin a internet. Los tiempos y
mecanismos de comunicacin se debera manejar bajo los SLA correspondientes y
regulados en los contrato con cada proveedor.

6
 2. Gestin de Incidentes:

Planteamiento supuesto:
En el da del lanzamiento comenzaron a recibirse llamadas en el Service Desk reportando
incidentes con el uso del explorador de internet en las maquinas donde se instal la Suite
SpeedOffice
Clasificacin de Categora/ Subcategora de Incidencias:
Por ser incidencias relacionadas directamente a la etapa de implementacin de Suite
SpeedOffice y siendo repetitiva en cantidad de usuarios, llevar la siguiente clasificacin en
Categora / Sub-Categora:
Clasificacin: Suite SpeedOffice / Compatibilidad de Navegador

En caso el Service Desk y la gestin de Incidentes no consiguieran resolver el

incidente dentro de los plazos acordados se realizar lo siguiente:
Precedente de la gestin de Incidente:
1. Usuario requiere asistencia en Primera lnea de Help Desk.
2. Al no encontrar solucin ante incidente se releva a Lnea de Soporte de
Aplicaciones de Help Desk.
3. Al no poder solucionarlo la lnea de Soporte de Aplicaciones y al tratarse de un
software externo, se deriva a la Lnea de Soporte de Proveedores.
4. Se genera requerimiento de atencin y solucin de problemas por parte de
proveedor, y se lleva control de acuerdo a SLAs establecidos los tiempos de
respuesta y solucin al problema.

En caso el proveedor no cumpla con los tiempos establecidos, se realizar el

siguiente procedimiento:
1. Se eleva el problema a Gestor de Problemas.
2. Se procede con la desinstalacin de la Suite y se realizan las pruebas necesarias.
3 .Se determina que existe error de compatibilidad.
4. Se registra esta incidencia dentro del CMDB para que el Service Desk cuente
con documentacin de la incidencia y se evite problemas posteriores.
5. Se da por cerrado el incidente.
Nota.- Cabe indicar que el no cumplimiento de los Niveles de Acuerdo de Servicio,
facilitan el sustento de alguna renegociacin comercial y / o penalidad de ser el caso.

7
 3. Gestin de Problemas:

Problema supuesto:
En caso se detecte que la solucin de muchos incidentes recurrentes es la aplicacin de
un service pack a la SpeedOffice (suponiendo en caso la suite ya fue implementada). Se
realizar lo siguiente:
Procedimiento:
1) Usuario registra su incidencia (cual sea el medio).
2) Primera Lnea atiende incidencia. (No resuelve el caso).
3) Lnea de Soporte de Aplicaciones atiende incidencia (No resuelve el caso).
4) Lnea de Soporte de Proveedores asume el caso.
5) Genera Requerimiento a Proveedor de acuerdo a SLAs
6) Se eleva el incidente a Gestin de Problemas
7) Realiza seguimiento a eventos y encuentra solucin
8) Registra solucin en CMDB
9) Informa a Service Desk sobre solucin
10) Se cierre el Problema
FLUJOGRAMA DE GESTIN DE PROBLEMAS
FLUJOGRAMA
USUARIO SERVICE DESK GESTION DE INCIDENCIAS GESTION DE PROBLEMAS PROVEEDOR

REGISTRA
INCIDENCIA

PRIMERA LINEA
ATIENDE

RESULETO?

SI NO

ATIENDE SOPORTE
DE APLICACIONES

RESULETO?

SI NO

ATIENDE SOPORTE
DE PROVEEDORES

GENERA GESTIONA
RESULETO? REQUERIMIENTO REQUERIMIENTO
CON PROVEEDOR
SI NO

RESULETO DENTRO
DEL SLA? ATIENDE
PROBLEMA

NO
SI

APLICA CAMBIOS DE
SERVICE PACK
GESTION DE PROBLEMAS

RECIBE ACUSE DE REGISTRO DE

REGISTRO DE SOLUCION EN
SOLUCION CMDB Datos

CIERRE DE
PROBLEMA

8
 4. Gestin de Cambios:

Actualmente se ha identificado e inventariado que en la empresa TAFI GROUP, existen

una lista de programas de escritorio que no est cumpliendo de manera eficiente los
procesos de diferentes tipos trabajos que se realizan a nivel de usuario de escritorio, lo cual
est paralizando la oportunidad de mejora y por ende no cumplir con el plan estratgico de
la empresa.
"El objetivo fundamental de la Gestin de Cambio es asegurar que todos los cambios son
registrados, clasificados, evaluados, aprobados, implantados y monitoreados de una
manera controlada".

De lo verificado:
Los programas constantemente necesitan servicio tcnico o simplemente tienen que ser
removidos por ser obsoletos. Se ha identificado que en algunos casos no existe soporte
tcnico, lo cual retrasa el avance de los trabajos, afectando la continuidad del negocio.
Puntos a realizar mejoras relacionados con las reas de la organizacin:

Diseo y innovacin de Productos : rea de Produccin

Control de calidad de Productos: rea de Produccin
Anlisis de oportunidades de negocio y comercializacin: rea de Ventas y
Marketing
Mecanismos de mercadeo y publicidad: rea de Ventas y Marketing
Mejoras en la atencin del soporte tcnico de los productos (compatibilidad;
configuraciones; actualizaciones: parches y upgrades de versiones): rea de
Tecnologa e Infraestructura.
Justificacin:

Los programas actuales de escritorio que no ayudan en el avance eficiente de

los diversos trabajos a nivel de escritorio
Lo programas no han sido de ayuda para tener mayores oportunidades de
mejora ya que constantemente necesitan de un soporte tcnico.
Los programas tienen que ser removidos por ser obsoletos y no existir un
soporte tcnico, afectando la actividad y continuidad del negocio.
Requerimiento del Cambio:
El rea de TI plantea hacer un cambio de los programas descritos anteriormente y en
su lugar implantar una suite de programas SPEEDOFFICE, gracias a la cual se podr
desarrollar con normalidad los trabajos de oficina.

9
 Descripcin Del Cambio:
TAFI plantea migrar de plataforma en el uso de programas de escritorio, a una suite
SpeedOffice.

Objetivos:
Brindar un mejor servicio al usuario.
Mejor performance en el desarrollo laboral de los usuarios
Reducir el costo en servicio tcnico para la plataforma de programas
desfasados.
Impacto en el Servicio

El corte de servicio para la reparacin o eliminacin de estos programas ocasiona perdida

de dinero mensual ya que por cada hora perdida, cada diseador, cada personal de
Marketing, de Ventas, pierden tiempo y dinero. Es por ello que con la implementacin de
SpeedOffice no habr corte de servicio y podr as la empresa tener mejores ventas,
mejores diseos, etc.

Con esta suite de programas podremos recuperar la inversin en un periodo de 6 meses.

Tiempo: Tiempo total: 8 das.

1 da firma del contrato (los puntos del SLR se establecieron previamente)
2 das de prueba de la suite en el 50% de los usuarios incluido el total de usuarios
en la central y las sedes.
2 das de capacitacin a los usuarios tanto de la casa central como de las
sucursales.
2 das de instalacin y configuracin en las PCs de los usuarios.
Riesgos: La instalacin de la plataforma SpeedOffice podra contraer los siguientes
Riesgos:
Lentitud en el Sistema
La necesidad de adquirir mayor memoria para cada una de las PCs que usaran la
suite.
La posibilidad de tener que adquirir un nuevo servidor, si fuera el caso de que el
actual no soporte la suite.
Que el usuario demore en aprender el funcionamiento de la nueva suite.
Recursos Humanos:
Negociaciones: rea de Aplicaciones.
Implementacin: rea de Infraestructura.

10
Mtricas del Impacto del Cambio:
Los Indicadores Clave de Rendimiento ITIL (KPIs) se utilizan para evaluar si los procesos
de una organizacin de TI los procesos de ITIL funcionan segn las expectativas.
Definir los KPIs adecuados es sobre todo decidir exactamente qu se considera una
"ejecucin exitosa de un proceso". Una vez queda esto establecido, es posible determinar
y medir indicadores especficos. Los Propietarios y Controladores de los Procesos estn
preparados para evaluar la calidad de sus procesos, que a su vez es la base para optimizar
y afinar continuamente los diseos de los procesos.

KPI (Mtrica de CSI) Descripcin

Cantidad de cambios Cantidad de cambios mayores evaluados por el CAB

mayores (Consejo Consultor para Cambios)

Cantidad de reuniones de
Cantidad de reuniones de CAB
CAB

Tiempo medio transcurrido desde la solicitud de una

Tiempo para autorizacin
RFC (Solicitud de Cambio) a la Gestin de Cambios
para cambios
hasta la autorizacin para el cambio

Tasa de aceptacin de
Cantidad de RFC's aceptadas vs. rechazadas
cambios

Cantidad de cambios Cantidad de cambios urgentes evaluados por el ECAB

urgentes (Consejo Consultor para Cambios de Emergencia)

Queremos medir la: satisfaccin del usuario"

Lista de Cdigo de Mtricas en RFC:

CIDM: CDIGO DE DESCRIPCIN

MTRICA
CIDM1 Total de cambios en espera
CIDM2 Total de cambios implementados
CIDM3 Nmero de cambios fallidos
CIDM4 Nmero de cambios de emergencia.
CIDM5 Nmero de cambios reprogramados.
CIDM6 Nmero de cambios resultantes en incidencias
CIDM7 Total de horas laborales disponibles para coordinar
cambios
CIDM8 Total de horas laborales disponibles para coordinar
cambios

11
KPIs:

Identificar: Recolectar requerimientos de cambios.

Definir : Tipificacin
Capturar: Registrar

Proteccin de los servicios cuando se ejecutan los cambios. Asociado a

las mtricas:

CIDM3: Nmero de cambios fallidos.

CIDM6: Nmero de cambios resultantes en incidencias.

Ejecutar cambios rpidamente y con precisin con las necesidades del

negocio. Asociado a las mtricas:

CIDM4: Nmero de cambios de emergencia.

CIDM5: Nmero de cambios reprogramados.
CIDM6: Nmero de cambios resultantes en incidencias.
CIDM7: Total de horas laborales disponibles para coordinar cambios.

Ejecutar cambios eficaz y eficientemente. Asociado a las mtricas:

CIDM1: Total de cambios en espera.
CIDM2: Total de cambios implementados.
CIDM5: Nmero de cambios reprogramados.

El Comit de Cambios (CAB)

Es quin evala y emite la aceptacin o rechazo a la solicitud de cambios.

El Comit de Cambios estar integrado por:

Jefe del rea de Finanzas, que por lo general es quin lidera el comit.
Integrantes del rea usuaria.
Integrantes del rea de Desarrollo y de Infraestructura.

Tambin lo pueden integrar consultores externos o representantes de los principales

proveedores de software y hardware segn se requiera para la evaluacin de la solicitud.
Las sesiones del CAB se realizarn cada 15 das, se realizarn los das mircoles de la
segunda y cuarta semana del mes, la hora predeterminada de la reunin es 10am.

12
En estas sesiones se evaluarn las solicitudes de cambio que se presentaron hasta un da
antes de la reunin.|

Los cambios menores pueden no necesitar la aprobacin del CAB y ser implementados
directamente. Cualquier otro cambio habr de ser discutido en el CAB y se habr de solicitar
la colaboracin de personal especializado para realizar tareas de asesoramiento.

Formato de RFC:

RFC_FORMATO_TAFI_GROUP.pdf

El flujo de RCF:

Se inicia mediante un RFC (Request For Change) Solicitud de Cambio, por parte
del rea o persona que requiere realizar algn cambio.
Posteriormente la solicitud es enviada para la revisin del mismo.
Una vez completado el RFC, mediante un formato. Se entrega al departamento de
Gestin de Cambios.
El departamento de Gestin de Cambios, cumple el rol de realizar una valoracin y
evaluacin inicial, en base a ello toma una decisin, la cual puede ser de:
aceptacin, rechazo o solicitar un cambio en el RFC.
Los RFC aprobados deben ser clasificados de acuerdo a su nivel de impacto.
Cuando el RFC ha sido autorizado, su ejecucin deber ser planificada, comunicada
a todos los interesados y ejecutada.
Una vez ejecutado o procesado el cambio, la persona o rea solicitante,
determinar mediante una evaluacin si fue exitosa o no.
El administrador de cambios verifica el progreso del cambio y cierra el RFC.

13
1. RFC: En primer lugar se plantea la Solicitud de cambio (RFC) con la finalidad de corregir
los errores antes mencionados, innovar y brindar mejores servicios a los usuarios que
hacen uso de estos programas.
2. Registro: El RFC debe estar debidamente registrado con la finalidad de darle un correcto
seguimiento a todo el proceso del cambio entre las descripciones debe incorporar:
2.1 Descripcin Del Cambio: El Cambio deber iniciarse con la aprobacin por parte del
Comit de Cambios.
A partir de la aceptacin se plantea estima unos 5 a 8 das para la implementacin total de
la suite, el proceso de compra y supervisin estar a cargo del rea de Aplicaciones y la
configuracin estar a cargo del rea de infraestructura.
El rea de Infraestructura ha determinado un total de 8 das desde la adquisicin de la suite
hasta la operatividad en el 100% de usuarios involucrados.
De acuerdo al Cronograma:

3 das de pruebas en el 70 % de los usuarios involucrados.

3 das de capacitacin a todos los usuarios.
2 das para implementar su uso en el 100% de usuarios.
Objetivos:
Estatus del RFC: Aspecto que ser actualizado segn el avance.
3. Aceptacin
El cambio debe ser aprobado por el comit de cambios para proceder con los siguientes
procesos.
Aceptado: si es aceptado, pasa a su impacto y clasificacin
Denegado: se devuelve el RFC al solicitante para que presente nuevas alegaciones.
4. Clasificacin: Para su correcto procesamiento de cambio, es necesario determinar tanto
su prioridad como su categora.
Prioridad: El avance de los trabajos por parte de los usuarios est siendo afectado en gran
manera tanto en calidad y tiempo por lo que el cambio a la nueva suite es de prioridad es
relevante.
Categora: Software.
Recursos Humanos:
Negociaciones: rea de Aplicaciones.
Implementacin: rea de Infraestructura.

14
Costos:
Costo total del Software incluido licencias
Gastos por Riesgos
Gatos De Implementacin
En gastos de Implementacin involucra los gastos de viajes a las sucursales, viticos, etc.
Por parte del personal encargado de la configuracin.
Plazos: El Plazo mximo establecido desde la aprobacin es de 8 das, donde incluye la
finalizacin del contrato, el periodo de prueba, capacitacin e implementacin final.
5. Urgencia
En ocasiones, el cambio no puede esperar debido a interrupciones de gran magnitud en el
negocio. De ser el caso, debe ser aprobada directamente por el comit de cambios y
algunos procesos sern necesarios su ejecucin a posteriori por ejemplo la integridad de la
CMDB.
De presentarse el caso de que la plataforma actual en TAFI, sea inoperativa
completamente, la prioridad de esta RFC sera de urgencia, procediendo con los pasos
antes mencionados.

6. Aprobacin y Planificacin:
Desde la aprobacin, se proceder con la siguiente planificacin antes mencionada:

1 da firma del contrato (los puntos del SLA se establecieron previamente)

3 das de prueba de la suite en el 65 % de los usuarios incluido el total de usuarios
en la central y las sedes.
3 das de capacitacin a los usuarios tanto de la casa central como de las
sucursales.
2 das de instalacin y configuracin en las PCs de los usuarios.
7. Roll out: La Gestin del cambio, no es la responsable directa de la realizacin del
cambio, pero es la responsable directa de la implementacin y debe coordinar todo el
proceso, desde el entorno de la adquisicin de la suite, el entorno de pruebas y la
implementacin.
8. Back out: De haber alguna falla en la implementacin de la nueva suite, se debe aplicar
un Back-out con la finalidad de evitar interrupciones graves del servicio, de tal manera que
se pueda volver, en menor tiempo posible, a la utilizacin de la plataforma que actualmente
se est usando.

9. Cierre: Tras los 7 das de implementacin total de la suite, de acuerdo al contrato con el
proveedor, el cierre de la implementacin es 3 das despus. En estos 3 das se evala el
rendimiento total de la nueva suite y de no presentarse incidencias, se procede con el cierre.

15
DIAGRAMA DE FLUJO DE GESTIN DE CAMBIOS

16
5. Gestin de la Configuracin:

(Proyecto: SpeedOffice)
Actividades que Realizar la Gestin de la Configuracin en el Proceso de
Implementacin y Anlisis del Cambio propuesto:

Los procesos de la Gestin de la Configuracin se realizan en la base de datos de

la configuracin (la BD recopila toda la informacin en detalle) de las distintas
configuraciones realizadas tanto en los elementos lgicos instalados y
desarrollados como los dispositivos fsicos.

Se Debe seguir los siguientes Procesos:

a. Planificacin:
Se implementara un sistema a aquellos usuarios que utilicen aplicativos de
escritorio, teniendo en cuenta lo siguiente:

Responsables:
Compra Jefe de Gestin de Aplicaciones
Implementacin Jefe de Gestin de Infraestructura

Alcance:

Capacidad 220 personas

Tiempo 100% en 1 semana
instalacin

b. Clasificacin y Registro:
Mantenimiento operativo de la base de datos de la gestin de
configuraciones (CMBD).
Llenado de la CMBD (clasificando la informacin).
Asignado de cdigo de identificacin a los usuarios.

c. Monitorizacin:
Identificar el estado de cada uno de los entregables (para este ao).
Definir la responsabilidad de los mismos al Jefe de Aplicaciones y de
Infraestructura.

17
d. Control:
Documentar el software y hardware adquirido dentro de la Base de
Datos de la Gestin de Configuracin (CMBD)
Llevar el control del uso de componentes de hardware y software
Informar el uso de licencias activas
Software Speed Office
Licencia 220 usuarios

e. Auditorias:
Constatar la estandarizacin de la configuracin de la informacin tanto
en la CMBD como en la estructura de TI
Verificar las correctas nomenclaturas de los registros en los Elementos
de Configuracin
Comunicar sobre la gestin de cambios que se realicen e informar sobre
las Peticiones de Cambios Realizados (RFC).

18
6. Gestin Financiera

En base al anlisis realizado, es recomendable utilizar el Modelo de Costos por

Cliente, lo cual nos permitira obtener de una forma ms ptima y a su vez
equitativa, calcular los costos propios en que incurre cada rea de la empresa.

Para poder obtener los costos se debe realizar lo siguiente:

Identificar los costos

Identificar todos los costos que puedan ser atribuidos directamente al
servicio analizado, del hardware, software, personal o contratos
dedicados.
Decidir cmo proporcionar los Costos Indirectos (por ejemplo la
Infraestructura)
Ajustar el total con los costos encubiertos o no absorbidos (Gestin de
TI o Instalaciones) por medio del mismo factor de ajuste calculado en el
modelo de costo por cliente.
Los inductores para poder hacer el prorrateo son los siguientes:

Costos Inductor
Licencias de Correos Nombre de Usuarios
Licencias de ERP Nmero de transacciones
Servidores Cantidad de Usuarios

Beneficios del Modelo de Costos por Clientes:

Se incrementa la rentabilidad del servicio debido a que hay una
reduccin de costos.
Ajuste, control, adecuacin y justificacin de los precios del servicio,
logrando un aumento en la satisfaccin del cliente.
Mejoras en la planificacin de inversiones dentro de TI, debido a un
mejor conocimiento de los costes reales de los servicios TI.
La organizacin TI funciona como una unidad de negocio y es posible
evaluar claramente su rendimiento global.

19
7. Gestin de Release
Roll Out Recomendado:
El cual nos permitir minimizar el costo y el impacto en los servicios y recursos:
Para implementar el SpeedOffice, es recomendable usar el Roll-out por fases. Se
comenzara por usuarios de la sede central y las de Rioja, Tucumn y Crdova;
continuando las acciones repetidamente con el resto de usuarios de TAFI.

DIAGRAMA DE FLUJO: IDENTIFICACIN DE LOS PUNTOS DE CONTACTO

ENTRE LOS PROCESOS

20
Explicacin del Flujo asociado a la Gestin de Cambios y Gestin de
Versiones:

1. La Gestin de Cambios recibe una la solicitud de Cambios (RFC) con el fin de

la implementacin de la suite de escritorio SpeedOffice.

2. Registra la RFC para dar el seguimiento y luego de una evaluacin inicial se

clasifica determinando su prioridad y categora.

3. Paso siguiente el Comit de Cambios evala y aprueba el cambio, para luego

realizar la planificacin de la instalacin de la suite SpeedOffice.

4. La Gestin de Cambios no implementa el cambio, slo monitorea.

5. La Gestin de Versiones y realiza los siguientes procesos:

Planificacin: Donde se tomar en cuenta las polticas, recursos humanos

y tcnicos, planes de back-out, mtricas de evaluacin, etc.
Desarrollo: Para asegurar que el paquete de software de la suite
SpeedOffice cumpla las especificaciones detalladas en la RFC. Se debe
configurar la suite SpeedOffice en las mquinas donde se realizarn las
pruebas iniciales.
Pruebas: Se verifica el correcto funcionamiento de los programas de la suite
SpeedOffice en un entorno realista. As como las pruebas de los planes de
back-out, en este caso desinstalacin de la suite del entorno.

6. Si la versin no fuera aceptada se devolver a la Gestin de Cambios para su

reevaluacin.

7. La Gestin de Versiones se encargar del rollout por fases de la suite

SpeedOffice, con una parte de los usuarios de cada sucursal para que den la
conformidad del buen funcionamiento de la suite Speed Office.

8. La Gestin de Versiones debe comunicar a los usuarios la implementacin de

la suite Speed Office. As como capacitar a los usuarios que usarn la suite
Speed Office.

9. Si las pruebas son exitosas, se repetir la operacin al resto de usuarios de la

empresa siguiendo el cronograma desarrollado.

10. La Gestin de Cambios se encarga de dar la aceptacin final para que se

proceda a la instalacin de la suite SpeedOffice. Si la versin no fuera aceptada
se devolver a la Gestin de Cambios para su reevaluacin.

21
11. La Gestin de Cambios debe supervisar y coordinar todo el proceso de
implementacin de la suite Speed Office.

12. La Gestin de Versiones debe guardar una copia de la suite Speed Office en la
Biblioteca de Software Definitivo (DSL), actualizar la Base de Datos de
Configuracin (CMDB) e identificar las mtricas que se usarn luego de la
implementacin de la suite Speed Office y monitorear su desempeo.

Beneficios de la coordinacin de la Gestin de Cambios y la Gestin de

Versiones:

El software adquirido cumple con las especificaciones predeterminadas.

El cambio realizado genera un menor nmero de incidentes y problemas.
Cumplimiento de los calendarios previstos y la asignacin de recursos es
la adecuada.
Apreciacin ms significativa de los costes asociados al cambio y por
consiguiente es ms sencillo valorar el retorno real de la inversin.
Capacidad de desarrollar procedimientos de cambio estndar, con el fin de
realizar una rpida actualizacin.
Menor necesidad de cambios a deshacer y un mejoramiento de la
capacidad para realizar backouts.
Reduccin de las interrupciones de los procesos de negocio.
Optimizacin de la informacin de gestin.
Incremento de la productividad de los usuarios del servicio y del personal
TI.
El proceso de cambio se realiza no afecta la calidad del servicio ofrecido.

Medidas a tomar para conseguir la coordinacin:

La autoridad de la Gestin de Cambios debe ser aceptada por las distintas
reas de la empresa.
Los responsables de la Gestin de Cambios y de Versiones deben tener un
conocimiento profundo de las actividades, servicios, necesidades y
estructura de TI de la organizacin con el fin de desarrollar correctamente
su actividad.
Disponer de herramientas para monitorear y documentar adecuadamente
los procesos referentes a estas dos Gestiones una propuesta sera Mantis.
Implementar un ambiente donde se pueda testear de forma realista las
nuevas versiones de software y hardware para poder analizarlas.
Implementar un plan de comunicacin para que informe a todos los
responsables y usuarios de la organizacin TI de las ventajas de una
correcta gestin de todo el proceso de cambio.

22
 8. Gestin del Nivel de Servicio:

Catlogo de Servicios TAFI GROUP

Cdigo Descripcin de Servicio rea de Inicio de Disponibilida Criticidad

TI atencin d del Servicio

SERVICIO DE SERVICE DESK

S101 Administracin de requerimientos. rea de 15 min. 1 Horario diurno. Media
Infraestr hora
uctura

S102 Mantenimiento preventivo y rea de 1 hora 4 Horario diurno Media

correctivo de equipos. Infraestr horas y nocturno
uctura
S103 Brindar accesos a usuarios a rea de 15 30 Horario diurno. Media
ciertos grupos de dominio. Infraestr min.
uctura
S104 Recepcionar nuevos rea de 30 min. 1 Horario diurno, Baja
requerimientos que se puedan Infraestr hora nocturno.
presentar durante el desarrollo de uctura
las actividades cotidianas. |
S105 Brindar capacitacin en el uso de rea de 30 min. 1 Horario diurno. Media
nuevo software o hardware Infraestr hora
instalado. uctura

SERVICIO DE MANTENIMIENTO DE SI
S201 Brindar mantenimiento del rea de 1 hora 4 Horario diurno Alta
Sistema de Informacin SIC. Gestin horas
de
Aplicacio
nes

S202 Brindar mantenimiento del rea de 1 hora 4 Horario diurno. Alta

Sistema de Informacin SIP. Gestin horas
de
Aplicacio
nes
S203 Brindar mantenimiento del rea de 1 hora 4 Horario diurno Alta
Sistema de Informacin SIS. Gestin horas
de

23
 Aplicacio
nes
S204 Brindar mantenimiento del rea de 1 hora 4 Horario diurno Alta
Sistema de Informacin FACTIS. Gestin horas
de
Aplicacio
nes

S205 Brindar mantenimiento del rea de 1 hora 4 Horario diurno Alta

Sistema de Informacin ADMIN. Gestin horas
de
Aplicacio
nes
S206 Brindar mantenimiento del rea de 1 hora 4 Horario diurno Alta
Sistema de Informacin PRODIS. Gestin horas
de
Aplicacio
nes

S207 Capacitar a los usuarios en el uso rea de 30 minutos Horario diurno. Media
de Nuevas aplicaciones Gestin a1 hora
informticas desarrolladas. de
Aplicacio
nes
SERVICIO DE CORREO ELECTRNICO

S301 Administrar las cuentas de correo rea de 10 min 20 Horario diurno Alta
electrnico del usuario. Infraestr min
uctura

SERVICIO DE COMUNICACIONES

S401 Realiza el mantenimiento peridico rea de 30 - 50 min Horario diurno. Alta

de la pgina web de Tafi. Gestin
de
Aplicacio
nes
S402 Administrar la red informtica de rea de 30 40 min Horario diurno. Alta
Tafi que abarca desde el rea de Infraestr
informtica a las dems reas. uctura
S403 Reemplazo y/o mantenimiento de rea de 20 45 Horario diurno. Media
las lneas y de los accesorios Infraestr min.
telefnicos uctura

24
 SERVICIO DE SEGURIDAD

S501 Administrar permisos de usuarios a rea de 20 30 min Horario diurno. Alta

uso de Equipos Informticos de los Infraestr
usuarios de todas las areas de uctura
Tafi.

S502 Administrar las cuentas de rea de 20 30 min Horario diurno. Alta

usuarios de todas las areas de Infraestr
Tafi. uctura
S503 Administrar el proceso de generar rea de 15 30 min Horario diurno. Alta
backups de los diferentes sistemas Infraestr
de informacin. uctura
S504 Configuracin de Antivirus rea de 20 45 min Horario diurno. Media
Infraestr
uctura
S505 Actualizacin de firma de antivirus rea de 20 45 min Horario diurno. Media
Infraestr
uctura
S506 Deteccin de cdigo malicioso rea de 20 45 min Horario diurno. Media
Infraestr
uctura
SERVICIO DE ADICIONALES

S601 Administracin de incidencias de rea de 2 6 horas Horario diurno. Media

Base de Datos Infraestr
uctura
S602 Administracin de Backups de rea de 2 6 horas Horario diurno. Media
Base de datos Infraestr
uctura
S603 Administracin de Active Directory rea de 2 6 horas Horario diurno. Media
Infraestr
uctura
S604 Configuracin de Redundancia de rea de 2 8 horas Horario diurno. Media
servidores y escalamiento. Infraestr
uctura

25
 SLA HELP DESK:

1. Introduccin

1.1 Partes de Acuerdo:

El objetivo de este documento es el establecimiento de un acuerdo de Nivel de Servicio

para el Service Desk ofrecido por el rea de TI de la empresa Tafi y el Gerente General de
la empresa Tafi; cuyos beneficiarios sern los usuarios de las reas Administrativas y
Operativas de la mencionada empresa.

1.2 Cobertura y Exclusiones:

El presente acuerdo se aplica sobre el servicio de Service Desk ofrecido por el rea de TI
para la atencin de incidencias, problemas y peticiones sobre disponibilidad y uso de este
servicio por parte de los empleados de Tafi. La exclusin de este servicio es para los
empleados dados de baja.

El presente acuerdo tiene efecto y ser equivalente para todas las sedes de Tafi que hagan
uso de este servicio, independientemente del lugar donde se realice la atencin al usuario.

1.3 Responsabilidades:

Este acuerdo establece responsabilidades que el rea de TI adquiere frente a la Gerencia

General en cuanto al ofrecimiento del Service Desk. Las responsabilidades derivadas de
este acuerdo slo podrn ser reclamadas por la Gerencia General de la empresa.

1.4 Validez:

Este acuerdo tiene validez el da siguiente de la fecha de su firma y tiene una duracin
indefinida. En caso de nominacin de un nuevo jefe del rea de TI o del Gerente General,
estos debern ratificar por escrito el acuerdo para que ste mantenga su validez.
En caso que no se produzca esta ratificacin o que se establezca un nuevo acuerdo, se
entender que el presente acuerdo queda anulado a todos los efectos.

26
2. Condiciones del Servicio

2.1 Objetivo del Servicio:

El servicio de Service Desk tiene como objetivo atender y proceder a la solucin de

incidencias y problemas recurrentes notificados por el usuario.

2.2 Procesos que lo soportan:

El servicio de Service Desk ser soportado por unos procesos formales de Gestin, como
la Gestin de Incidencias y la Gestin de Problemas. Se considerar incidencia aquel
suceso o circunstancia inesperada que impida el funcionamiento normal y prestablecida del
servicio. Se considerar problema aquel conjunto de incidencias que indiquen un fallo
recurrente y focalizado en el sistema. La catalogacin y priorizacin de las notificaciones
recibidas ser realizada por el rea de Service Desk y no por parte del usuario.

2.3 Funcionamiento General:

El Service Desk ofrece dos formas de contacto: telfono y correo electrnico. Se usar un
nmero fijo para la atencin telefnica pero se proporcionar adems un nmero de celular
como respaldo a posibles cadas de la red telefnica fija.
Cualquiera de esos dos medios se considerar vlido y recibir el mismo trato una vez haya
entrado en proceso de resolucin. En caso que los datos de las vas de contacto cambien,
se notificar al personal la nueva informacin.

2.4 Requisitos para la Tramitacin

Un usuario deber cerciorarse que su tramitacin haya sido aceptada. Se considerar

aceptada a trmite una incidencia cuando el operador del Service Desk as lo notifique
expresamente, o cuando el Usuario reciba una notificacin por email.

27
Para que sea aceptado el trmite de una incidencia se debern cumplir obligatoriamente
una serie de requisitos:

La persona que notifica la incidencia debe ser un usuario reconocido y la persona

que deber dar soportar debe ser un miembro de la Mesa de Ayuda del rea de TI.

El usuario debe aportar todos los datos con veracidad, exactitud y de forma completa
y sin ambigedades. Adems este usuario tendr que seguir las instrucciones que
cualquier responsable de la Mesa de Ayuda le solicite realizar.

3. Disponibilidad:

Se establece una atencin ininterrumpida del servicio de Service Desk a lo largo de todo el
ao por lo que el usuario podr ponerse en contacto con el equipo de Service Desk en
cualquier momento.

Se determina como norma que el usuario tendr que usar el correo electrnico, el nmero
fijo o el nmero mvil del Service Desk antes de reclamar la no disponibilidad del servicio.
El rea de TI elude cualquier responsabilidad derivada de la imposibilidad de notificar una
incidencia como resultado del fallo en la prestacin de servicios por parte de los operadores
de telecomunicaciones.

4. Tiempo de Respuesta:

El tiempo mximo de resolucin de las incidencias, contando a partir del momento

en que se acepta a trmite la incidencia hasta que se enva la notificacin de que
sta ha sido resuelta.
El usuario dispondr de 15 minutos, a contar desde el momento de la recepcin de
la comunicacin de resolucin de la incidencia dentro del horario laboral del rea
del usuario, para comprobar que el fallo ha sido reparado; y en caso de permanencia
del fallo, podr solicitar la reapertura de la incidencia.
Se establece un tiempo mximo de resolucin de incidencias de 60 minutos y para
problemas de 4 horas segn el nivel del problema.

28
5. Notificacin de Resolucin:

En cuanto se haya resuelto una incidencia se notificar al usuario de su resolucin,

por cualquier medio sea mensaje va email, mensaje de texto o llamada telefnica
de comunicacin disponible, independientemente del medio utilizado por el usuario.

En caso se determine que no existe incidencia o que sta excede sus competencias,
se enviar una notificacin justificada indicando la razn por la cual no se puede
proceder a la resolucin de la incidencia y se proceder a derivar un tcnico
especializado.

SLA DEL SISTEMA PRODIS

PRODIS es el sistema de proceso de produccin, es el sistema ms crtico en Tafi Group,

de ah la vital importancia en no permitir cada de servicio de este sistema.

1. Requisitos previos:

El SLA slo se aplicar cuando los mensajes de soporte cumplan los siguientes
requisitos previos:
El Cliente enva los mensajes de soporte a travs de Service Desk segn el
procedimiento de conexin de procesamiento de mensajes de soporte de TI.
El Usuario est debidamente registrado en la lista de Usuarios con acceso a
PRODIS.

2. Alcance del Service Desk:

El Usuario puede solicitar y TI debe proporcionar, el Soporte en el grado en que TI presta

dichos servicios de manera general en la empresa.

3. Gestin global de mensajes y Acuerdo de nivel de servicio (SLA).

Cuando el Usuario notifica un mal funcionamiento, TI, por medio de Service Desk asiste al
Usuario ofrecindole informacin sobre cmo reparar, evitar o saltar errores. El canal
principal para dicha asistencia ser la infraestructura de soporte que TI ofrece en primera

29
lnea por medio del Help Desk, en segundo lugar el area de infraestructura para incidentes
no resueltos por el Help Desk, en tercer lugar el rea de aplicaciones que ayuda a resolver
problemas con los sistemas desarrollados, y en cuarto lugar soporte de los proveedores.

3.1 SLA para los tiempos de respuesta iniciales en los siguientes horarios:

A. Mensajes de soporte de Prioridad 1 (Alta).

TI responder los mensajes de soporte dentro de la hora a partir de la recepcin por parte
de Help Desk, Se le asigna la Prioridad 1 al mensaje si el problema ocasiona graves
consecuencias en las transacciones comerciales normales y si las tareas comerciales
importantes y urgentes no pueden realizarse. Generalmente, esto puede ocurrir en las
siguientes circunstancias: interrupcin general del sistema, mal funcionamiento de las
funciones principales de PRODIS en el Sistema de produccin.

TI debe proporcionar una solucin, una respuesta provisoria o un plan de accin para la
resolucin ("Accin correctiva") del mensaje de soporte de Prioridad 1 del Usuario dentro
una hora. En el horario establecido.

B. Mensajes de soporte de Prioridad 2 (Media).

TI responder los mensajes de soporte de Prioridad 2 dentro de las cuatro (4) horas a partir
de la recepcin por parte de Helpdesk durante el Horario de oficina local de TI. Se le asigna
la Prioridad 2 a un mensaje si se ven gravemente afectadas las transacciones comerciales
normales en el sistema de produccin y si las tareas necesarias no pueden realizarse. Esto
sucede debido a que las funciones del sistema PRODIS que se requieren para efectuar
dichas transacciones y/o tareas son incorrectas e inoperables.

C. Mensajes de soporte de Prioridad 3 (Baja).

TI responder los mensajes de soporte dentro de ocho (08) horas a partir de la recepcin
por parte de Help desk, Se le asigna Prioridad 3 a la solicitud que no necesariamente afecte
a la produccin diaria, entre ellos estn: modificacin de algn reporte no crtico, agregar
y/o quitar algn campo del sistema, etc.

30
4. Persona dedicada de soporte de TI

En los casos de Prioridad 1 y Problemas principales relacionados directamente con el

Soporte de Help Desk, TI pondr a su disposicin una persona dedicada especializada de
la organizacin de soporten PRODIS para las solicitudes relacionadas con el soporte de
elementos crticos. Esta Persona de soporte realizar las siguientes tareas de soporte de
elementos crticos:

Soporte remoto para los Problemas principales, permitiendo el anlisis de causas

principales (las 24 horas del da y los 7 das de la semana) para la identificacin del
problema.
Esta persona de soporte de TI designado se encontrar disponible para el Usuario
autorizado las 24 horas del da, los 7 das de la semana para las solicitudes
relacionadas con el soporte de elementos crticos.

5. Verificacin:

Para verificar el cumplimiento de los trminos de este Acuerdo, TI est autorizado a

controlar peridicamente (como mnimo una vez al ao y de acuerdo con los procedimientos
estndar de PRODIS):

La exactitud de la informacin que proporcion el Usuario.

El uso por parte del Usuario de Help Desk de acuerdo con los procesos de
solicitudes de soporte tcnico.

6. Otros trminos y condiciones:

La no Utilizacin de Service Desk, puede impedir que TI identifique y asista en la correccin

de posibles problemas que a su vez podran ocasionar el rendimiento insatisfactorio del
Software, lo cual est fuera de la responsabilidad de TI.

31
El Inicio del Help Desk y alcance de afectacin:

La implementacin de un Service Desk beneficiara en tanto se siga con una debida

metodologa he implementen los procesos ya que este sistema asegura que, con
independencia de lo que pueda suceder (rotacin de personal, enfermedad de los
trabajadores, inasistencias, etctera), los niveles de servicio se mantienen trabajando con
normalidad.

Adems se contara con un marco de trabajo que en el tiempo permitir obtener un nivel de
madurez en cuanto a la metodologa establecida que funge como base para la operacin e
implementacin de los procesos, con lo cual la organizacin ya no debe preocuparse por
cmo va a operar o qu debe establecer para que el funcionamiento sea el adecuado.

Luego de una necesaria capacitacin de personal contara con personal totalmente

especializado, con amplio conocimiento, de la gestin de solicitudes e incidencias,
fundamentado en los SLAs definidos adems de poseer la capacidad para tratar de la
mejor manera a los usuarios y atender a sus cuestionamientos

Se mejora la calidad y capacidad de respuesta a las peticiones de los clientes y usuarios.

Las solicitudes sern enviadas a la persona correcta y resuelto menor tiempo.

El sistema PRODIS es crtico para la organizacin, una cada del PRODIS representa una
paralizacin total de la produccin.

32
Identificacin de Riesgos y/o Amenazas:

1) Riesgo: No se cuenta con una estrategia de Backup (Respaldo) definida, con lo cual
queda en alto riesgo la integridad de data lo cual puede ocasionar la prdida total o parcial
de informacin de la empresa.

Accin de Contramedida:

Se debe definir con el DBA una adecuada estrategia de backup acorde a sus
necesidades, considerando almacenamiento, frecuencia y test de
funcionamiento.

2) Riesgo: La arquitectura monoltica del servidor y sus servicios, concentra el riesgo de

cada por saturacin de recursos o corte de fluido elctrico, ya que no se dispone de
mecanismos de escalabilidad ni tolerancia a fallos.

Accin de Contramedida:

Se debera evaluar la implementacin de servidores espejos o clster para

manejar el balanceo de carga de acuerdo a demanda.

3) Riesgo: Teniendo en cuenta la arquitectura del servidor, el servicio de E-mail corporativo

est en alto riesgos debido a las condiciones ambientales, lo cual puede provocar la
interrupcin de comunicaciones internas con consecuencias importantes para el negocio.

Accin de Contramedida:

Se debera considerar que estamos inmersos en una economa de escala,

evaluar los servicios ofrecidos por Google o Microsoft en cuanto al servicio
de email en la nube, que se entregan a costo mdico y al ms breve plazo.
Considerando la confidencialidad, integridad y seguridad que garantizan con
ASL bien definidos que ofrece cada proveedor.

33