ITIL - Actividad 2 Parte 2

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Rocket clouds
ITIL - Actividad 2 Parte 2 por Mind Map: ITIL - Actividad 2 Parte 2

1. Definición de la estructura de procesos

2. Selección de roles ITIL y propietarios de roles

2.1. Analicis crito de la estructura actual

2.1.1. Eurotrans no tiene un departamento centralizado de Informática

2.1.2. El Jefe de Administración local es el responsable de la informática de su oficina regional y de la región que cubren

2.1.3. Los Jefes de Administración emplean el 50% de su tiempo tratando asuntos de TI, y se apoyan en un conjunto de gerentes de sistemas y de redes.

2.2. Cambios a realizarce en la estructura

2.2.1. Ee debe realizar una centralización de la dirección para las operaciones y planificación TI

2.2.2. Definir la responsabilidad y escalamientos porque cada una de las sucursales

2.2.3. Reestructuracio de la dirección de TI que trabaje a tiempo completo en el monitoreo, opreación, proyectos y cambios en el servicio TI.

3. Análisis de procesos existentes

3.1. Identificacion de puntos fuertes/debiles con respecto al servicio.

3.1.1. SERVICE DESK/GESTIÓN DE INCIDENCIAS

3.1.1.1. Puntos fuertes

3.1.1.1.1. Está definido un soporte de primer nivel (Service Desk) en cada oficina regional

3.1.1.1.2. En cada oficina local de ventas hay un empleado formado para resolver los problemas más comunes.

3.1.1.1.3. Se realizan intercambios de información periódicos entre las oficinas regionales, aunque seguramente no es el mecanismo óptimo.

3.1.1.1.4. La proximidad al usuario final (en cada oficina local) se podría percibir como un beneficio.

3.1.1.1.5. Perfil de usuarios aparentemente uniforme.

3.1.1.2. Puntos débiles

3.1.1.2.1. A pesar de la similitud, los entornos desktop de las oficinas regionales son dispares (emuladores Web, cliente-servidor y emuladores host). Por tanto, excesiva diversidad de plataformas.

3.1.1.2.2. No existe un proceso formal con registro único de incidencias. Puede estar sucediendo que las mismas incidencias ocurran en todas las oficinas.

3.1.1.2.3. No se tiene constancia de la cantidad de incidencias atendidas en cada oficina.

3.1.1.2.4. Quizás es necesario disponer de varios Service Desk especializados para cada tipo de aplicación.

3.1.2. GESTIÓN DE PROBLEMAS

3.1.2.1. Puntos fuertes

3.1.2.1.1. Existe un gerente de aplicaciones en cada oficina regional responsable de la resolución de “problemas” menores en las aplicaciones.

3.1.2.2. Puntos débiles

3.1.2.2.1. No parece existir ninguna base de datos de conocimiento. Por tanto, no es posible reaprovechar el conocimiento.

3.1.2.2.2. No se dispone de un registro de incidencias/problemas.

3.1.3. GESTIÓN DEL CAMBIO

3.1.3.1. Puntos fuertes

3.1.3.1.1. Existe un gerente de aplicaciones en cada oficina regional responsable de cambios.

3.1.3.1.2. Parece que se trate de un entorno muy estable, sin gran volumen de cambios a la vista.

3.1.3.2. Puntos débiles

3.1.3.2.1. No existe ningún CAB.

3.1.3.2.2. Las decisiones de cambios son aisladas en cada oficina regional. No existe un único change manager.

3.1.3.2.3. No queda claro quiénes son los propietarios de los procesos.

3.1.3.2.4. No parece existir una categorización de los cambios (menor, sustancial, significativo).

3.1.3.2.5. No existe ningún proceso formal, luego no existen formularios, no existen procedimientos.

3.1.3.2.6. Probablemente tampoco se priorizan los cambios.

3.1.4. GESTIÓN DE LA CONFIGURACIÓN

3.1.4.1. Puntos fuertes

3.1.4.1.1. No existe gran dispersión de infraestructura, lo cual puede facilitar la creación de una CMDB.

3.1.4.1.2. Infraestructura técnica bien organizada y documentada que puede facilitar su gestión.

3.1.4.2. Puntos débiles

3.1.4.2.1. No existen herramientas de gestión remota (¿A lo mejor, no es necesario dado el volumen de infraestructura?).

3.1.4.2.2. Al parecer no existe ninguna CMDB definida.

3.1.5. GESTIÓN DE SOFTWARE

3.1.5.1. Puntos fuertes

3.1.5.1.1. Existen paquetes homologados de aplicaciones corporativas.

3.1.5.1.2. La ofimática de la empresa está definida a través de una única aplicación común OFICINA.

3.1.5.1.3. Existe un entorno de pruebas (servidor de UTRECHT) para los proveedores de software y para el personal de informática.

3.1.5.1.4. El acceso a las aplicaciones se realiza mayoritariamente a través de emulador Web.

3.1.5.1.5. Existe un gerente de aplicaciones en cada oficina regional responsable de pruebas.

3.1.5.2. Puntos débiles

3.1.5.2.1. Ni la oficina de Dusseldorf ni la de Orange disponen de un entorno de pruebas.

3.1.5.2.2. El acceso a las aplicaciones desde la oficina de Orange parece que funciona con modelo cliente-servidor (dificulta la gestión y el control de las versiones).

3.1.5.2.3. No existe ninguna DSL (de todas maneras parece que está basada en una infraestructura centralizada que lo facilitaría. Aun así es necesario disponer de la DSL).

3.1.5.2.4. Tampoco existe DHS.

3.1.5.2.5. Los entornos de pruebas solamente están contemplados para las aplicaciones de negocio (no incluye sistemas operativos, hardware, etc.,).

3.1.5.2.6. Probablemente exista una dispersión en las versiones de PCs puesto que cada oficina local podría comprarlas por separado.

3.1.6. GESTIÓN DE NIVELES DE SERVICIO

3.1.6.1. Puntos fuertes

3.1.6.1.1. Puntos fuertes

3.1.6.2. Puntos débiles

3.1.6.2.1. No son conocidos los detalles de los contratos de mantenimiento de los sistemas externalizados a varios proveedores de mantenimiento.

3.1.6.2.2. No son conocidos los proveedores de mantenimiento.

3.1.6.2.3. Se pretende involucrar más a menudo a terceras partes para ayudar a cumplir con los planes de los proyectos, y sin embargo, no existe reconocido ningún proceso de Service Level Management que garantice la existencia de UCs acordes con las necesidades de negocio.

3.1.6.2.4. No existen SLAs ni catálogo de servicios.

3.1.6.2.5. Hay insatisfacción en los niveles de disponibilidad y calidad de algunas aplicaciones.

3.1.6.2.6. Es necesario establecer quiénes son los propietarios de los servicios.

3.1.7. GESTIÓN DE LA DISPONIBILIDAD

3.1.7.1. Puntos fuertes

3.1.7.1.1. Existen soluciones de clúster sobre servidores de las oficinas regionales.

3.1.7.1.2. Se realizan reuniones periódicas (cada dos meses) para determinar políticas de TI y planes a meses vista.

3.1.7.1.3. Las conexiones entre las oficinas regionales depende de un único proveedor externo de telecomunicaciones (un único contrato).

3.1.7.2. Puntos débiles

3.1.7.2.1. El modelo de clúster de tres servidores en la oficina de Orange es obsoleto.

3.1.7.2.2. Doce de las veinte oficinas disponen de doce servidores sin ninguna definición explícita de disponibilidad y las restantes dependen, para su operativa, de una única conexión MODEM.

3.1.7.2.3. Se depende de un único proveedor de telecomunicaciones (si falla el enlace, no tenemos alternativas).

3.1.7.2.4. Han sido detectadas incidencias de disponibilidad puesto que ciertas transacciones se han perdido (proponer un SOA para identifica claramente la razón de las pérdidas de transacciones).

3.1.7.2.5. Los tiempos de respuesta en las oficinas locales son mejorables. Debe ser gestionado desde la oficina regional quien contacta directamente con el proveedor de la zona.

3.1.7.2.6. La infraestructura existente difícilmente podrá garantizar que un pedido se suministre en el plazo de una hora, las 24 horas del día.

3.1.7.2.7. No está establecida de manera explícita ninguna política de seguridad.

3.1.7.2.8. La posible centralización única de la infraestructura requeriría soluciones de disponibilidad.

3.1.7.2.9. Las nuevas exigencias de e-company aumentan los requisitos de disponibilidad.

3.1.8. GESTIÓN DE LA CAPACIDAD

3.1.8.1. Puntos fuertes

3.1.8.1.1. Se realizan reuniones periódicas (cada dos meses) para determinar políticas de TI y planes a seis meses vista.

3.1.8.1.2. Los servidores están consolidados en tres oficinas, sería mucho mejor consolidarlos en un único centro.

3.1.8.1.3. La posible centralización de la infraestructura, por temas de escalabilidad, podía suponer una reducción en los costes de propiedad.

3.1.8.2. Puntos débiles

3.1.8.2.1. El acceso a las aplicaciones FLETES y VIAJES desde ocho de las oficinas locales de ventas, se realiza desde un módem.

3.1.8.2.2. No existe trazabilidad de las transacciones (Pérdidas detectadas).

3.1.8.2.3. Posibles soluciones ad-hoc en las oficinas locales.

3.1.8.2.4. En la oficina de Orange, el clúster de servidores es obsoleto.

3.1.8.2.5. Los recursos en las diferentes oficinas regionales no son iguales ¿se han realizado análisis de cargas de trabajo?

3.1.9. GESTIÓN DE LA CONTINUIDAD

3.1.9.1. Puntos fuertes

3.1.9.1.1. El hecho de disponer de tres oficinas regionales con una infraestructura similar y alojando las mismas aplicaciones parece ser una situación de partida ventajosa para proporcionar sites de disaster recovery, aunque quizás se deba tender a un único punto centralizado (consolidación de servidores) y entonces debe preverse un site alternativo.

3.1.9.1.2. Una posible solución de continuidad podría contemplarse en alguno de los nuevos países (menores costes).

3.1.9.2. Puntos débiles

3.1.9.2.1. No aparece explícitamente definido ningún plan de continuidad

3.1.9.2.2. Se depende excesivamente de un único proveedor de telecomunicaciones que puede dificultar las estrategias de continuidad.

3.1.10. GESTIÓN FINANCIERA

3.1.10.1. Puntos fuertes

3.1.10.1.1. Uno de los objetivos de la compañía es proveer a las oficinas regionales de más autonomía, por tanto que actúen como unidades de negocio.

3.1.10.1.2. En cuanto a la previsión del presupuesto, debe tenerse en cuenta la posible expansión a otros países europeos.

3.1.10.1.3. Una posible solución de continuidad (site alternativo) podría contemplarse en los nuevos países (menores costes).

3.1.10.2. Puntos débiles

3.1.10.2.1. No parece que esté definidos los modelos de coste ni la metodología de costes.

3.1.10.2.2. No se explicita la creación de presupuestos.

3.1.10.2.3. No se contabiliza por el uso de los servidores.

3.1.10.2.4. No se repercute, ni que sea con noción, luego no se crea conciencia de uso.

3.1.10.2.5. Varía mucho entre países.

4. Beneficios

4.1. Centralizacion de los SLA del servicio, entregando un servicio estandar en cualquiera de la regiones donde opera la empreza.

4.2. Menor tiempo de respuesta en la operacion, dado que se tendra una matriz de escalamiento definida, con responsables identificados.

4.3. Mayor capacidad de planificacion y toma de deciciones, ya que se tendra personal dedicado.

5. Se ha decidido implantar una infraestructura que facilite la implementación del proceso.

5.1. Un correcto sistema automatizado de registro de incidentes y relación con los clientes para lo que se ha elegido la Herramienta HP OpenView Service Desk.

5.2. Una Base de Conocimiento actualizada (KB) para comparar nuevos incidentes con los anteriores ya sea en curso o resueltos.

5.3. Poner directamente a disposición del cliente parte de estos datos (a la manera de FAQs) en una WEB. Lo que puede permitir que a veces el usuario no necesite siquiera notificar la incidencia.

5.4. Una CMDB que contenga todas las configuraciones y el impacto que estas puedan tener en la resolución del incidente.

5.5. Centralización de la estructura de liderazgo/reporte, creando una cadena de escalamientos de acuerdo a la responsabilidad asignada a cada área resolutora, para el manejo centralizado de incidencias/requerimientos.

5.6. Medición/catalogación del impacto de los incidentes y requerimientos, según SLA que representen el esfuerzo que se realiza para resolver el caso.