TTULO: DISEO E IMPLEMENTACION DE UN SISTEMA DE GESTION DE CAMBIOS BASADO EN ITIL V3

EN CORPORACION CARGO MASTER

INDICE

INTRODUCCION................................................................................................... 3 CAPITULO I: GENERALIDADES ....................................................................... 4

1.1 Objetivos................................................................................................................. 4 1.2 Importancia............................................................................................................. 5 1.3 Justificacin ............................................................................................................ 5

CAPITULO II: MARCO TEORICO ...................................................................... 6

INTRODUCCION

Los cambios forman parte del trabajo diario de la Empresa, existen cambios generados por Agentes internos (reas de la empresa), o por Agentes Externos (Entidades Gubernamentales, Competencia), estos cambios tienen implicancias con el Departamento de TI, en donde trabajamos para que los cambios solicitados sean realizados de manera correcta y oportuna.

En mi experiencia de trabajar con Cambios en un Departamento de TI he notado que estos cambios son comunicados de distintas maneras, verbalmente en algunos casos o por correo o en otros, sin embargo no se ha definido un estndar en la Empresa de cmo manejar los cambios.

ITIL V3 ha desarrollado una metodologa de Gestin de Cambios, en la cual me basar, para Disear un Sistema que mejore la forma en la que los Cambios se realizan en la Empresa.

El sistema se basar en Cambios Estndares solicitados por usuarios autorizados, definiendo el proceso para cada cambio y dando un formato para cada Solicitud de Cambio, de esta forma el Cambio ser fcil de solicitar y el seguimiento se realizar desde el inicio hasta la culminacin del mismo.

La Empresa en la que se realizara el Sistema es la Corporacin Cargo Master, dedicada al rubro del Comercio Internacional con mas de 15 aos en el Mercado y con Oficinas Propias en 5 pases de Latinoamrica, y con una Red de Agentes que permite enviar y recibir carga desde y hacia cualquier parte del Mundo.

El Departamento de TI ubicado en Lima Per, brinda diferentes Servicios de TI a toda la Corporacin, entre ellos: Servicio de Correos, Servicio de Desarrollo de Aplicaciones de Negocio, Servicio de Archivos Compartidos, Servicio de Configuracin de Equipos, Servicio de Telefona IP,Servicio de Soporte de Aplicativos.

CAPITULO I

GENERALIDADES

1.1 Objetivos

Aminorar el tiempo de Solicitudes del Cambio. Crear un formato estndar de Solicitudes de Cambio que son constantes en el Trabajo. Tener un control del Cambio y poder realizar un seguimiento y verificar su estado. Que los cambios sean realizados de forma eficiente. Llevar un histrico de los Cambios solicitados con las Lecciones aprendidas de la implementacin.

1.2 Importancia

Llevar a cabo los cambios de forma eficiente, requiere de procesos estndar dentro de la empresa y esto no consigue sin un Sistema de Gestin de Cambios que le de soporte necesario, para el buen desempeo del rea de TI.

1.3 Justificacin

Los Cambios actualmente son solicitados por Correo Electrnico, de tal manera que no es fcil realizar un control o seguimiento de los mismos, ya que cada usuario solicita los cambios de diferente forma y de manera imprecisa, con datos faltantes o no siguen las polticas de la empresa.

Algunos Cambios son solicitados verbalmente y no se lleva registro de los mismos. No existe un tiempo estimado de duracin de los cambios.

CAPITULO II

ITIL V3

2.1 Introduccin a Itil

En la dcada de 1980, el servicio prestado a los departamentos del Gobierno Britnico por Empresas de TI internas y externas era de tal calidad que la CCTA (Agencia Central de Telecomunicaciones), recibi el encargo de desarrollar una metodologa estndar para garantizar una entrega eficaz y eficiente de los servicios de TI. El resultado fue el desarrollo y publicacin de la Biblioteca de la Infraestructura de Tecnologa de Informacin (ITIL), que est formada por una serie de Mejores Practicas procedentes de todo tipo de suministradores de servicios de TI.

2.2 Conceptos

A) Buena Practica ITIL se presenta como una Buena Practica (literalmente un mtodo correcto), es decir, un enfoque o mtodo que ha demostrado su validez en la prctica.

B) Servicio El Objetivo de un servicio es generar valor para el Cliente. ITIL define un servicio de la siguiente forma:

Un servicio es un medio para entregar valor a los clientes, facilitando los resultados que los clientes quieren conseguir sin asumir costes o riesgos especficos.

C) Valor Desde el punto de vista del cliente, el valor consta de dos componentes bsicos: funcionalidad y garanta. La funcionalidad es lo que el cliente recibe, mientras que la garanta reside en cmo se proporciona.

D) Gestin de Servicios La Gestin de Servicios es un conjunto de capacidades organizativas especializadas cuyo fin es generar valor para los clientes en forma de servicios.

E) Sistema Un sistema es un grupo de componentes interrelacionados o interdependientes que forman un conjunto unificado y que funcionan juntos para conseguir un objetivo comn.

F) Funcin Una Funcin es una subdivisin de una organizacin que est especializada en realizar un tipo concreto de trabajo y tiene la responsabilidad de obtener resultados concretos.

Las funciones son subdivisiones independientes que tienen las capacidades y recursos necesarios para alcanzar los resultados exigidos. Tienen sus propias prcticas y su propio cuerpo de conocimiento

G) Proceso Un proceso es un conjunto estructurado de actividades diseado para cumplir un objetivo concreto. Los procesos dan como resultado un cambio orientado hacia un objetivo y utilizan retroalimentacin para efectuar acciones de automejora y autocorreccin.

2.3 El Ciclo de Vida del Servicio

La versin 3 de ITIL enfoca la gestin de Servicios a partir del Ciclo de Vida de un Servicio, que es un modelo de organizacin que ofrece informacin sobre:

-La forma en que est estructurada la gestin del servicio. -La forma en que los distintos componentes del Ciclo de Vida estn relacionados entre s. -El efecto que los cambios en un componente tendrn sobre otros componentes y sobre todo el Sistema del Ciclo de Vida.

El Ciclo de Vida del Servicio consta de 5 fases:

2.3.1.-Estrategia del Servicio.- La fase de diseo, desarrollo e implementacin de la Gestin del Servicio como un recurso Estratgico.

2.3.2- Diseo del Servicio.- La fase de diseo para el desarrollo de Servicios de TI apropiados, incluyendo arquitectura, procesos, poltica y documentos; el objetivo del diseo es cumplir los requisitos presentes y futuros de la empresa.

2.3.3.-Transicin del Servicio.-La fase de desarrollo y mejora de las capacidades para el paso a produccin de servicios nuevos y modificados.

2.3.4.- Operacin del Servicio.- La fase en la que se garantiza la efectividad y eficacia en la provisin y el soporte de servicios con el fin de generar valor para el cliente y el proveedor del servicio.

2.3.5.-Mejora Continua del Servicio.-La fase en la que se genera y mantiene el valor para el cliente mediante la mejora contina del diseo y la introduccin y Operacin del Servicio.

Esquema 1: Ciclo de Vida del Servicio

Fuente : www.itil.org

2.4 Transicin del Servicio

El objetivo de la Transicin del Servicio es convertir las especificaciones de la fase del Diseo del Servicio en un servicio nuevo o modificado.

A) Metas Dar soporte al proceso de cambio del negocio. Reducir las variaciones en el rendimiento y los errores del servicio nuevo o

modificado. Garantizar que el servicio satisface los requisitos de las especificaciones

B) Objetivos Producir los medios necesarios para realizar, planificar, y gestionar el nuevo

servicio Minimizar el impacto sobre los servicios que ya estn en produccin. Aumentar la satisfaccin del cliente y fomentar el uso correcto del servicio.

C) mbito La Transicin del Servicio incluye la gestin y coordinacin de los procesos, sistemas y funciones necesarios para la construccin, prueba y despliegue de una versin en produccin, asi como para la definicin del servicio segn las especificaciones del cliente y las partes interesadas.

D) Valor para el Negocio Una Transicin del Servicio eficaz garantiza que los servicios nuevos o modificados estn mejor alineados con las operaciones del negocio del cliente, concretamente:

Capacidad del negocio para reaccionar rpida y adecuada a los cambios del mercado.

Mejor gestin de cambios y versiones para el negocio. Menor diferencia entre los presupuestos previstos y los costes reales. Ms informacin sobre posibles riesgos durante la entrada de un servicio.

Mayor productividad de la plantilla del Cliente.

E) Optimizacin Es necesario que la fase y los planes de entrega estn coordinados con la empresa, la Gestin del Servicio y la estrategia de TI.

F) Conceptos Bsicos. Para que la Transicin del Servicio sea eficaz es importante aplicar las siguientes Polticas:

Definir e implementar directrices y procedimientos de Transicin del Servicio: Es necesario definir y documentar polticas de Transicin del Servicio y comunicarlas a la organizacin, a los proveedores de servicios y a los socios.

Implementar siempre todos los cambios a travs de la Transicin del Servicio: Cualquier cambio en la Cartera de Servicios o en el Catalogo de Servicios debe pasar por el Proceso de Gestin de Cambios y la Fase de Transicin del Servicio.

Alinear los planes de Transicin del Servicio con las necesidades del negocio Crear y mantener relaciones con las partes interesadas: esto para saber que es

lo que esperan del servicio nuevo o modificado Establecer controles eficaces Producir sistemas para transferir conocimientos y apoyar la toma de decisiones Planificar paquetes de versiones y despliegues Prever y gestionar cambios de direccin. Gestionar los recursos de manera Preactiva Garantizar la calidad de un servicio nuevo o modificado Mejorar la calidad de manera preactiva durante la Transicin del Servicio

G) Procesos y otras actividades Los siguientes son los procesos de la Transicin del Servicio: Planificacin y Soporte de la Transicin Gestin de Cambios Gestin de la Configuracin y Activos del Servicio Gestin de Versiones y Despliegues Validacin y pruebas de Servicio Evaluacin Gestin del Conocimiento del Servicio

H) Planificacin y Soporte de la Transicin

1) Metas Planificar y coordinar recursos para garantizar las especificaciones del Diseo

del Servicio. Identificar, gestionar y limitar riesgos que puedan interrumpir el servicio a

partir de la fase de transicin

2) Objetivos Planificar y coordinar medios y personas dentro de los marcos de trabajo Comprobar que todos aplican los mismos estndares y marcos de trabajo Comunicar problemas de servicio Elaborar planes claros y exhaustivos Dar soporte a los equipos de transicin y a otros que participen en el proceso Planificar cambios de forma controlada

3) mbito Incluir especificaciones de diseo y requisitos de producto en los planes de

Transicin. Gestionar:

Planes Actividades de Soporte Progreso de la Transicin Cambios Problemas Riesgos Desviaciones Procesos Sistemas y Herramientas de Soporte

4) Valor para el Negocio Mejora el alineamiento de los planes de transicin con los planes de proyectos de cambio de Cliente, proveedor de Servicio y negocio

5) Conceptos Bsicos El Paquete de Diseo de Servicio (SDP) contiene la siguiente informacin requerida para el equipo de Transicin del Servicio:

Paquetes de servicio aplicables Especificaciones del servicio Modelos de servicio Diseo de la arquitectura requerida para entregar el servicio, incluyendo

restricciones Definicin y Diseo de cada paquete de entrega Diseo con detalles de cmo se ensamblaran los componentes y se

integrarn en un paquete de entrega Planes de entrega y despliegue Criterios de aceptacin del servicio

En las directrices y polticas de entrega se tratan los siguientes aspectos: Convenios de nomenclatura que distingan tipos de entregas como: entrega

mayor, entrega menor o entrega de emergencia Roles y Responsabilidades, definir una matriz de responsabilidades Frecuencia de entrega prevista por cada tipo de entrega El planteamiento para aceptar y agrupar cambios en una entrega La forma en que se captura y verifica la linea base de configuracin respecto a

los contenidos reales de entrega La autoridad para aceptar la entrega en cada etapa de Transicin del Servicio Criterios de autorizacin para abandonar el Soporte Post implantacin(ELS) y

traspasar las operaciones del servicio

I) Gestin de Cambios Los cambios se realizan por una razn preactiva o reactiva. La reduccin de costes o la mejora del servicio son cambios proactivos, mientras que la solucin a interrupciones del servicio o adaptacin del servicio a cambios del entorno son cambios reactivos.

Los cambios se deben controlar correctamente para: Minimizar la exposicin al riesgo Minimizar la gravedad del impacto y la interrupcin del servicio Implementar el cambio correctamente en el primer intento

1) Metas Responder a cambios en el negocio del Cliente Responder a solicitudes de cambio de TI y del negocio

2) Objetivo Garantizar que los cambios son registrados, evaluados, autorizados,

priorizados, planificados, probados, implementados, documentados de una manera controlada.

El proceso de Gestin de Cambios debe:

1. Usar mtodos y procedimientos estndares 2. Registrar todos los cambios en una CMDB (Configuration Managment

Data Base) 3. Tener en cuenta los riesgos para el negocio

3) mbito Itil define un cambio de la siguiente manera:

Un cambio es la adicin, modificacin o eliminacin de un servicio o un componente de un servicio, autorizado, planificado o soportado y de su documentacin asociada.

Cada organizacin tiene que definir los cambios cubiertos por la Gestin de Cambios y los que quedan excluidos.

Esquema: mbito de la Gestin de Cambios

Cartera de Servicios

Gestionar el Negocio

Gestionar el proceso de Negocio

Gestionar la operacin de negocio

Gestionar el negocio

Operaciones Externas

Gestionar servicios

Gestionar Servicios de TI

Operaciones del Servicio

Cambio estratgico

Cambio Tctico

Cambio Operativo

Negocio Proveedor de Servicios Suministrador

4) Valor para el Negocio Los cambios en los servicios y la infraestructura pueden tener un impacto negativo sobre el negocio, debido a interrupciones del servicio, la Gestin de Cambios permite que los proveedores de Servicios puedan aadir valor al negocio

5) Polticas Las polticas que favorecen la Gestin de Cambios son: Creacin de una cultura de tolerancia cero ante los cambios no autorizados Alineacin de los procesos de Gestin de Cambios con otros procesos de

cambios de la organizacin Innovacin frente a prevencin, deteccin frente a cambios correctivos Establecimiento de responsabilidades finales y ejecutoras para los cambios Establecimiento de un punto nico para controlar los cambios

6) Diseo y planificacin El proceso de Gestin de Cambios se planifica conjuntamente con la Gestin de la Configuracin y la Gestin de la Versin. De esta forma es posible evaluar el impacto de los cambios sobre servicios y versiones.

Los requisitos y el diseo para el proceso de Gestin de Cambios incluyen: Requisitos a leyes y normativas relevantes Un mtodo de eliminacin de cambios no autorizados Identificacin y clasificacin Organizacin, roles y responsabilidades Agrupaciones y cambios relacionados Procedimientos Interfaces con otros procesos de Gestin del Servicio

7) Conceptos Bsicos

Una Solicitud de Cambio (RFC) es una peticin formal para cambiar uno o ms elementos de configuracin.

Un cambio estndar es un cambio de un componente de infraestructura o servicio que la Gestin de Cambios debe registrar, pero que presenta un bajo riesgo y tiene autorizacin previa, como la actualizacin de un equipo de cmputo.

Un cambio de emergencia se realiza para reparar lo antes posible un fallo en un servicio de TI que tiene un gran impacto negativo sobre el negocio. Si se requiere permiso del Comit de Cambios pero no es posible convocar una reunin se debe recurrir a una organizacin ms pequea que tome decisiones de emergencia: el Comit de Cambios de Emergencia (ECAB).

El Comit de Cambios (CAB) es un organismo asesor que se rene peridicamente para evaluar cambios y ayudar a la Gestin de Cambios a priorizarlos, puede incluir a: Clientes Usuarios finales Desarrolladores de aplicaciones Administradores de sistemas Expertos Representantes del Centro de Servicios al Usuario Produccin Representantes del proveedor de servicios

La agenda del Comit de Cambios debe incluir siempre: Cambios no autorizados Cambios autorizados excluidos del CAB Solicitudes de cambio que deban ser revisadas por los miembros del CAB

Cambios en curso o cerrados Evaluacin de cambios implementados

No se debe aprobar ningn cambio si no se tiene respuesta a la siguiente pregunta Qu se puede hacer si el cambio no tiene xito? En todo momento debe haber un plan de correccin en caso de fallo.

J) Gestin de la Configuracin y Activos del Servicio

El propsito de la Gestin de la Configuracin y Activos del Servicio (SACM) es proporcionar un modelo lgico de la infraestructura de TI, en el que los servicios de TI estn relacionados con los distintos componentes de TI necesarios para suministrar dichos servicios.

1) Objetivo Definir componentes de servicio e infraestructura y mantener los registros precisos de la configuracin. Para ello es importante que: La Integridad de los activos del servicio y los elementos de configuracin est

protegida. Todos los activos y elementos de configuracin estn localizados en el

Sistemas de Gestin de Configuracin (CMS).

2) mbito Todos los activos que se utilizan durante el Ciclo de Vida del Servicio estn incluidos. El proceso ofrece una imagen completa de todos los activos e indica quien es el responsable del control y el mantenimiento de los mismos.

La Gestin de la Configuracin garantiza que todos los componentes (elementos de configuracin) que forman parte del producto o servicio estn identificados, tienen una linea base de referencia (la configuracin) y se mantienen actualizados.

3) Valor para el negocio Mejor Previsin y planificacin de cambios Cambios y entregas que podrn ser valorados, planificados y provisionados

satisfactoriamente Incidencias y problemas que podrn ser resueltos dentro de los objetivos

estipulados en el nivel de servicio. Capacidad para identificar los costos asociados a un servicio

4) Conceptos Bsicos El establecimiento de relaciones entre los elementos de configuracin permite crear un modelo lgico de los servicios, los activos y la infraestructura. Este modelo proporciona informacin importante para otros procesos como: Anlisis de impacto para los cambios propuestos Investigacin de la causa de incidencias y problemas Planificacin y diseo de cambios, actualizaciones de software e innovacin

tecnolgica Planificacin de paquetes de versiones y despliegues.

ITIL define un elemento de Configuracin de la siguiente manera: Un elemento de configuracin es una activo, componente de servicio u otro elemento que est (o estar) bajo el control de la Gestin de la Configuracin. Existen muchos tipos de elementos de configuracin (CIs) como:

CIs del Ciclo de Vida del Servicio: para el soporte de las actividades tales como el Caso de Negocio y los planes de cambios y entregas.

CIs del Servicio, tales como activos de capacidades del servicio, activos de recursos del servicio, modelo del servicio, paquete del servicio, criterios de aceptacin del servicio.

CIs Organizativos, tales como documentos relativos a la estrategia del organizacin

CIs Internos, asociados a proyectos individuales

Para gestionar infraestructuras y servicios de TI de gran tamao y complejidad SACM necesita usar un sistema de soporte llamado Sistema de Gestin de la Configuracin (CMS).

K) Gestin de Entregas y Despliegues

Se ocupa de construir, probar y suministrar las capacidades, para proporcionar los servicios especificados en el Diseo del Servicio, cumpliendo los requisitos de los grupos de inters y proporcionando los objetivos planteados.

1) Meta La meta es poner las entregas en produccin y establecer el uso efectivo del servicio, al objeto de entregar valor al cliente y ser capaz de transferir las operaciones del servicio.

2) Objetivo Garantizar que existen planes de versiones y despliegues Garantiza que los paquetes de versiones se despliegan correctamente. Que exista transferencia de conocimiento a los clientes Que la perturbacin de los servicios sea mnima

3) mbito Los procesos, sistemas y funciones para el empaquetado, construccin, pruebas y despliegue de una entrega en el entorno de produccin y el establecimiento del servicio especificado en el paquete de Diseo del Servicio, antes de la transferencia final a operaciones del servicio

4) Valor para el Negocio Los cambios se realizan de forma ms rpido con menos costos y menos riesgos. El mtodo de implementacin es ms coherente y se mejora el cumplimiento de los requisitos de trazabilidad

5) Conceptos Bsicos Una entrega es un conjunto de elementos de configuracin, nuevos o modificados, que son probados e implementados conjuntamente en el entorno de produccin.

Una unidad de entrega es la porcin del servicio o la infraestructura que esta incluida en la entrega, de acuerdo a las directrices de entrega de la organizacin. Es importante determinar el nivel correcto de la versin. Para una aplicacin critica puede ser recomendable incluir toda la aplicacin en unidad de entrega, pero en el caso de un sitio Web, se puede incluir nicamente la pagina HTML que haya sido modificada.

Las opciones mas frecuentes para el paso a produccin son:

Big Bang versus planteamiento de fases: Bing Bang Ofrece el servicio nuevo o modificado para todos los usuarios al mismo tiempo mientras que por fases ofrece la entrega a parte del total de usuarios en cada fase. Automatizado o Manual: Las versiones se pueden automatizar en un grado considerable usando software de instalacin.

Los equipos de versiones y despliegues deben estar familiarizados con la arquitectura de TI utilizada en el proceso. Esto es fundamental para determinar el orden en que se deben implementar las actividades y para identificar todas las dependencias mutuas.

Un paquete de entrega es una sola unidad de entrega o una coleccin (estructurada) de unidades de entrega. En el caso de un servicio nuevo o modificado se deben tener todos los elementos que forman el servicio (infraestructura, hardware software, aplicaciones, documentacin, conocimiento etc.)

Esquema: Ejemplo de paquete de entrega

L) Validacin y Pruebas del Servicio

Las pruebas del servicio realizan una contribucin importante a la calidad de la provisin de servicios de TI. Las pruebas garantizan que los servicios nuevos o modificados estn ajustados al propsito y ajustados al uso

Ajustado al propsito, significa que el servicio hace lo que el cliente espera y por lo tanto es til para el negocio.

Ajustado al uso se refiere a aspectos como la disponibilidad, la continuidad, la capacidad y la seguridad del servicio.

1) Meta Proporcionar un servicio que aporte valor a los clientes y a sus negocios.

2) Objetivo Comprobar que: La entrega proporciona los resultados y el valor esperado por los clientes. Los servicios estn ajustados al propsito y ajustados al uso. Se cumplen las especificaciones del cliente y de otras partes interesadas.

3) mbito Se ejecuta durante todo el Ciclo de Vida del Servicio con el fin de probar la calidad del servicio. Tambin verifica que el proveedor del servicio tiene la capacidad y los recursos necesarios para ofrecer con xito un servicio o una versin del servicio.

Las pruebas son especialmente tiles para la Gestin de entregas y despliegues. Tambin el proceso de evaluacin utiliza los resultados de las pruebas.

4) Valor para el Negocio Las interrupciones del servicio pueden ser muy perjudiciales para las operaciones del proveedor de servicios y para los clientes que reciben los servicios. Pueden daar la reputacin, causar prdidas econmicas, o incluso provocar accidentes fatales. Por ejemplo en el caso de hospitales, industria automovilstica o aeroespacial, el rol de TI puede suponer graves daos o accidentes mortales debido a fallos del servicio.

M) Evaluacin La evaluacin es un proceso genrico con el que se considera si algo tiene un rendimiento aceptable, si su relacin valor-precio es adecuada etc. o si se utilizar, aceptar o se pagar por ello.

1) Objetivo Determinar el rendimiento de un cambio en un servicio. Ese rendimiento se evala en funcin del rendimiento esperado.

2) mbito Se limita a la evaluacin de servicios nuevos o modificados.

3) Valor para el negocio Proporciona informacin importante para CSI, as como para futuras mejoras en el desarrollo del servicio y la Gestin de Cambio

4) Polticas, puntos de partida y conceptos bsicos Los diseos y los cambios de los servicios se evalan antes de la transicin El cliente participa en la evaluacin

Se deben identificar los efectos imprevistos de un cambio Un cambio en un servicio se evala de manera justa, coherente, abierta y objetiva

N) Gestin del Conocimiento del Servicio

1) Meta Mejorar la calidad del proceso de toma de decisiones (de la direccin) haciendo que durante el Ciclo de Vida del Servicio se disponga de informacin segura y confiable.

2) Objetivos Dar soporte al proveedor de servicios para mejorar la eficiencia y la calidad de los servicios Garantizar que el personal del proveedor de servicios dispone de la informacin adecuada

3) mbito Se utiliza durante todo el Ciclo de Vida.

4) Valor para el negocio La Gestin del Conocimiento es especialmente importante durante la Transicin del Servicio, ya que, el conocimiento adecuado y relevante es uno de los elementos claves del servicio en transicin. Algunos ejemplos: Formacin y transferencia de conocimiento, propiedad intelectual,

informacin sobre conformidad y estndares. Documentacin de errores, soluciones provisionales e informacin de

pruebas.

5) Conceptos Bsicos La Gestin del Conocimiento se suele visualizar mediante la estructura DIKW Datos-Informacin Conocimiento- Saber. La base del Sistema de Gestin del Conocimiento del Servicio (SKMS) esta formada por una considerable cantidad de datos en una base de datos central o sistema de Gestin de la Configuracin (CMS) y la CMDB. La CMDB enva datos

al CMS, que a su vez facilita informacin al sistema SKMS para facilitar el proceso de toma de decisiones Sin embargo el sistema SKMS tiene un mbito ms amplio, ya que tambin almacena informacin sobre aspectos como: La experiencia y los conocimientos del personal Temas perifricos, como el comportamiento de los usuarios y el rendimiento

de la organizacin Requisitos y expectativas de proveedores de servicios y asociados

2.5 PROCEDIMIENTOS DE LA GESTION DE CAMBIOS SEGN ITIL V3.-

A) Actividades, Mtodos y Tcnicas

Actividades generales: Planificacin y control de Cambios Programacin de cambios y entregas Comunicaciones Toma de Decisin y Autorizacin de cambios Aseguramiento de que existan planes de correccin Medicin y Control Generacin de informes de gestin Entendimiento del Impacto Mejora Continua

Actividades especificas para gestionar cambios individuales

1. Creacin y registro de solicitud de Cambio (RFC) 2. Revisin de RFC y de propuesta de cambio 3. Valoracin y evaluacin del cambio 4. Autorizacin del cambio 5. Actualizacin de planes 6. Coordinacin de la implantacin del cambio 7. Revisin y cierre del registro de cambio

B) Creacin y registro de solicitud de Cambio (RFC) El cambio aparece a partir de una solicitud del disparador: individuo o grupo organizativo que requiere el cambio. Por ejemplo, ste podra ser una unidad de negocio que requiera nuevas instalaciones, o personal de gestin de problemas que promueva la resolucin de un error. Todas las solicitudes de cambio (RFCs) quedan registradas y debe ser posible identificarlas mediante un nmero de identificacin nico. El alcance y el impacto del eventual cambio determinan cuanta informacin ser requerida sobre el cambio.

C) Revisin de RFC y de propuesta de cambio Una vez registrada la solicitud de cambio, los interesados la revisan para ver si es inviable, repite otra anterior, se acepta, se rechaza, o queda en consideracin, o esta incompleta. En los casos correspondientes la solicitud se rechaza y se devuelve al solicitante especificndose el motivo. El solicitante debera disponer de un derecho a apelacin.

D) Valoracin y evaluacin del cambio Este paso se inicia con la categorizacin del cambio. Los aspectos de riesgo deben ser considerados antes de autorizar cualquier cambio. La probabilidad de que el riesgo se haga realidad y su posible impacto determinan la categora de riesgo del cambio. En la prctica se utiliza una matriz de categorizacin del riesgo. Despus de categorizar el cambio es necesario evaluarlo. Dependiendo del impacto, la valoracin del riesgo y los beneficios y costes potenciales del cambio, la Autoridad de Cambios (Gestor de Cambios y/o el CAB) determina si se apoya o no ese cambio. Las siguientes preguntas se deben responder para todos los cambios. Sin esta informacin no se puede completar la valoracin del impacto, y no se entender el equilibrio de riesgos y beneficios para el servicio en produccin. Las siete R de la Gestin de Cambios son un buen punto de partida para el anlisis de impactos:

1.- Quin solicito el cambio? (Reclamacin) 2.- Cul es el motivo del Cambio? (Razn)

3.- Cul es el resultado requerido del cambio? (Resultado) 4.- Qu riesgos presenta el cambio? (Riesgo) 5.- Qu recursos se necesitan? (Recursos) 6.- Quines son los responsables de construir, probar e implementar el cambio?

(Responsabilidad) 7.- Qu relacin existen entre este cambio y otros? (Relacin)

Para establecer el orden en que se deben implementar los cambios es necesario determinar la prioridad de los cambios a partir de su impacto y urgencia. El impacto se basa en los beneficios que aportara el cambio al negocio, y debe considerar la cuanta en daos y costes en caso de que falle. La urgencia indica cuanto tiempo se puede retrasar la implementacin.

Los siguientes son ejemplos de cdigos de prioridad.

-Prioridad baja: Un cambio deseable, pero que puede esperar hasta una mejor oportunidad. -Prioridad media: Un cambio sin demasiada urgencia o impacto, pero que no se puede retrasar. El Comit de Cambios da a este cambio una prioridad media al momento de asignar recursos. -Prioridad alta: Un cambio que se refiere a un fallo grave para varios usuarios o un fallo molesto para un gran numero de usuarios, o que est relacionado con otros problemas urgentes. El comit de cambios dar a este cambio la mxima prioridad en su siguiente reunin. -Prioridad inmediata: Un cambio relacionado con un fallo que causa graves perdidas de ingresos o que impide prestar importantes servicios informticos. Requiere una accin inmediata.

Planificacin y programacin de cambios

La Gestin de Cambios programa los cambios en un calendario llamado Programacin de Cambios (SC), que contiene datos de todos los cambios aprobados y su planificacin.

Los cambios se pueden agrupar en una entrega. Previa consulta con los departamentos de TI afectados, el CAB puede definir las fechas de implementacin de cambios, eligiendo momentos en los que el efecto de los cambios sobre los servicios sea el menor posible. Se debe preparar un plan de recuperacin para los casos en que falle la implementacin de cambios.

E) Autorizacin del Cambio Todos los cambios requieren la autorizacin formal de una Autoridad de Cambios, que puede ser un rol, una persona o un grupo de personas. El nivel de aprobacin necesario depende del tipo de cambio.

F) Actualizacin de planes Se comprueban y actualizan los planes de: cambio, transicin, entrega y despliegue, pruebas, evaluacin, regresin.

G) Coordinacin de la implementacin del cambio Las RFCs autorizadas se pasan a los grupos tcnicos adecuados, que son quienes construyen los cambios. Los cambios, el mtodo de correccin y la implementacin se deben someter a pruebas exhaustivas.

H) Revisin y cierre del registro de cambio Con la posible excepcin de los cambios estndar, los cambios implementados se evalan una vez transcurrido algn tiempo, tras lo cual el CAB determina si es necesario algn otro tipo de seguimiento. El CAB debe tener en cuenta las siguientes cuestiones:

Ha conseguido el cambio los resultados previstos? Estn todos los grupos de inters satisfechos con el resultado? Ha surgido algn efecto secundario? Se ha sobrepasado los costes y esfuerzos estimados?

Si el cambio ha tenido xito, se puede proceder a su cierre. El resultado se debe incluir en la Revisin post-implantacin (PIR) del cambio. Si el cambio no tiene xito, la Gestin de Cambios, o el CAB, debe decidir lo que se debera hacer. El resultado puede ser una solicitud de cambio nueva o modificada.

2.6 Interfaces El proceso de Gestin de Cambios puede tener como disparadores, entre otros, los siguientes tipos de cambios: Cambios estratgicos Cambios que afecten a uno o ms servicios. Cambios operativos Cambios para mejora continua

A) Entradas a Gestin de Cambios: Polticas y estrategias de cambios y entregas RFCs Propuesta de cambio Planes de: cambio, transicin, entrega y despliegue, pruebas, evaluacin,

regresin. Programacin de Cambios(SC) y Paradas de Servicio Planificadas(PSOs) Activos y elementos de configuracin Resultados de pruebas, informes de pruebas y de evaluacin

B) Salidas a Gestin de Cambios: Solicitudes de cambio aprobadas y rechazadas. Servicios, elementos de configuracin y activos, nuevos y modificados. PSO ajustada Programacin de Cambios actualizada Decisiones, acciones, documentos, registros e informes de cambios

La Gestin de Cambios tiene interfaces con los procesos de cambio del negocio, con la gestin de programas y proyectos y con la organizacin de aprovisionamiento y asociacin.

C) Interfaces con otros procesos de Gestin del Servicio

1) Gestin de la Configuracin y Activos del Servicio La informacin del Sistema de Gestin de la Configuracin (CMS) ayuda a determinar el impacto de los cambios propuestos y a seguir el flujo de trabajo de los cambios. Tambin indica si el cambio afecta a otros elementos de configuracin que no estn incluidos en la solicitud de cambio.

2) Gestin de Problemas Es uno de los procesos que presenta ms solicitudes de cambio. Su contribucin es muy importante en las reuniones del CAB.

3) Gestin de la Continuidad del Servicio de TI Este proceso incluye un gran nmero de planes y procedimientos que se actualizan con el proceso de Gestin de Cambios.

4) Gestin de la Seguridad de la Informacin Todos los cambios relacionados con temas de seguridad se tratan con el proceso de Gestin de Cambios.

5) Gestin de la Capacidad y Gestin de la demanda Una demanda mal gestionada implica un mayor nmero de riesgos. La Gestin de la Capacidad desempea un papel importante en la evaluacin de cambios.

D) Mtricas Indicadores Clave de Rendimiento: El numero de cambios implementados que cumplen las especificaciones del

cliente.

Los beneficios del cambio en comparacin con los costes. La reduccin en el numero de interrupciones del servicio La reduccin en el numero de cambios no autorizados La reduccin en el nmero de marchas atrs.

La tasa de xito de los cambios despus de la evaluacin con respecto al nmero de solicitudes de cambio aprobadas.

2.7 SCRUM Como metodologa de desarrollo del Sistema de Gestin de Cambios segn ITIL v3, se utilizara SCRUM. Es una metodologa gil que proporciona un marco de trabajo para la gestin de proyectos cuyo objetivo es obtener resultados rpidos, adaptndose a los cambios de las necesidades de los clientes.

A) Caractersticas principales El desarrollo software mediante iteraciones incrementales. Las reuniones a lo largo del proyecto.

Para ello, como metodologa gil que es, Scrum define un ciclo de vida iterativo e incremental, mejorando la gestin de los riesgos y aumentado la comunicacin.

B) Pilares en los que se basa Scrum 1) Transparencia

Todos los aspectos del proceso que afectan al resultado son visibles para todos aquellos que administran dicho resultado. Por ejemplo se utilizan pizarras y otros mecanismos para mejorar la comunicacin.

2) Inspeccin Se debe controlar con la frecuencia suficiente los diversos aspectos del proceso para que puedan detectarse variaciones inaceptables en el mismo. En parte la transparencia se logra mediante la comunicacin de la informacin. Para obtener esta informacin es necesario conocer lo que sucede. Una de las caractersticas fundamentales de Scrum son las reuniones que sea realizan diariamente y son cortas.

3) Revisin El producto debe estar dentro de los lmites aceptables. En caso de desviacin se proceder a una adaptacin del proceso y el material procesado. Esto se relaciona directamente con el pilar de la Inspeccin.

C) El equipo en Scrum Cada equipo Scrum tiene tres roles:

1) Scrum Master Es el responsable que el equipo Scrum siga las practicas de Scrum. Sus principales funciones son: Ayudar a que el equipo y la organizacin adopten Scrum Liderar el equipo Scrum, buscando la mejora en la productividad y calidad

de los entregables Ayudar a las autogestin del equipo Gestionar e intentar resolver los impedimentos con los que el equipo se

encuentra para cumplir con las tareas del proyecto

2) Propietario del Producto Product Owner) Es la persona responsable de gestionar las necesidades que sern satisfechas por el proyecto y asegurar el valor del trabajo que el equipo lleva a cabo. Su aportacin al equipo se basa: en Recolectar las necesidades o historias de usuario, Gestionar y ordenar las necesidades representadas por historias de usuario, aceptar el producto software al finalizar cada iteracin, maximar el retorno de inversin del proyecto.

3) Equipo de desarrollo El equipo esta formado por los desarrolladores que convertirn las necesidades del Product owner en un conjunto de nuevas funcionalidades, modificaciones o incrementos del producto software final. El equipo de desarrollo tiene caractersticas especiales:

Autogestionado: el mismo equipo supervisa su trabajo. En Scrum se potenciaran las reuniones del equipo, aumentando la comunicacin. No existe el rol clsico de jefe de proyecto. El Scrum Master tiene otras responsabilidades.

Multifuncional: no existen especialistas, cada integrante del equipo, puede encargarse de tareas de programacin, pruebas, despliegue etc. Asimismo las personas pueden tener capacidades diferentes o conocimientos ms profundos en diferentes reas. Lo importante es que cualquier integrante del equipo sea capaz de realizar cualquier funcin.

No distribuidos: es conveniente que el equipo se encuentre en el mismo lugar fsico. Esto facilita la comunicacin y la autogestin que nace del mismo equipo.

Tamao optimo: un equipo que desarrolla scrum estara compuesto por al menos tres personas.

D) El Product Backlog La pila de producto o Product Backlog en Scrum es uno los elementos fundamentales. A partir del Product Backlog se logra tener una nica visin durante todo el proyecto. Consiste en un listado de historias del usuario que se incorporaran al producto software a partir de incrementos sucesivos. Seria similar a un listado de requisitos de usuario y representa lo que el cliente espera. Una diferencia respecto a un proceso tradicional es la evolucin continua de Product Backlog, buscando aumentar el valor del producto software desde el punto de vista del negocio. El descubrimiento y la descripcin de los elementos del Product Backlog es un proceso continuo. Las necesidades ya no estn congeladas desde el principio, sino que se descubren y se detallan a lo largo de todo el proyecto. Este descubrimiento

no se limita a las etapas iniciales del proyecto, sino que abarca todo el proyecto Scrum.

E) Cualidades del Product Backlog

1) Detallado adecuadamente El grado de detalle depender de la prioridad. Las historias de usuario que tengan una mayor prioridad se describen con ms detalle.

2) Estimado Las estimaciones a menudo se expresan en das ideales o trminos abstractos.

3) Emergente Las necesidades se van desarrollando y sus contenidos cambian con frecuencia. Los nuevos elementos se descubren y se agregan a la lista teniendo en cuenta los comentarios de los clientes y usuarios.

4) Priorizado Los elementos del Product Backlog se priorizan. Los elementos ms importantes y de mayor prioridad aparecen en la parte superior de la lista.

F) El Sprint Una de la bases de los proyectos giles es el desarrollo mediante las iteraciones incrementales. En Scrum a cada iteracin se le denomina Sprint. Scrum recomienda iteraciones cortas, por lo que cada Sprint durara entre 1 y 4 semanas. Y como resultado se creara un producto software potencialmente entregable, un prototipo operativo. Las caractersticas que van a implementarse en el Sprint provienen del Product Backlog.

El equipo de desarrollo selecciona las historias de usuario que se van a desarrollar en el Sprint conformando el Sprint Backlog.

PRODUCTBACKLOG

SPRINTBACKLOG INCREMENTO

Una de las implementaciones que ms se llevan a cabo para el Sprint Backlog es crear un desglose de tareas normalmente representadas en una tabla, donde se describe cmo el equipo de desarrollo va a implementar las historias de usuario durante el siguiente Sprint.

Al realizar las tareas dividen en horas, donde ninguna tarea debe durar ms de 16 horas al ser realizada por un integrante del equipo. Si una tarea es mayor a 16 horas, es recomendable dividirla en otras menores. Adems la lista de tareas se mantendr inamovible durante toda la iteracin.

G) Las Reuniones Las reuniones son un pilar importante dentro de Scrum, se realizan a lo largo de todo el Sprint.

1) Reunion de planificacin del Sprint (Sprint Planning Meeting) Se lleva a cabo al principio de cada Sprint, definiendo en ella que se va a realizar en ese Sprint. Esta reunin da lugar al Sprint Backlog, en esta reunin participan todos los roles. El Product Owner presenta el conjunto de historias de usuario en el Product Backlog y el equipo de desarrollo selecciona las historias de usuario sobre las que se trabajar. La duracin de la reunin no debe ser mayor de 8 horas y como resultado el equipo de desarrollo hace una previsin del trabajo que ser completada durante el Sprint.

2) Reunin diaria (Daily Scrum) Es una reunin diaria de no mas de 15 minutos en la que participan el equipo de desarrollo y el Scrum Master. En esta reunin cada miembro del equipo presenta lo que hizo el da anterior, lo que va a hacer hoy y los impedimentos encontrados.

3) Reunion de revision del Sprint (Sprint Review Meeting) Se realiza al final del Sprint. Participan el equipo de desarrollo, el Scrum Master y el Product Owner. Durante la misma se indica qu ha podido completarse y qu no, presentando el trabajo realizado al Product Owner. Por su parte el Product Owner (y dems interesados) verifican el incremento del producto y obtienen informacin necesaria para actualizar el Product Backlog, con nuevas historias de usuario No debe durar mas de 4 horas.

4) Retrospectiva del Sprint (Sprint Retrospective) Tambin al final del Sprint, sirve para que los integrantes del equipo Scrum y los Scrum Master den sus impresiones sobre el Sprint que acaba de terminar. Se utiliza para la mejora del proceso y normalmente trabaja con dos columnas, con los aspectos positivos y negativos del Sprint. Esta reunin no debera durar ms de 4 horas.

CAPITULO III: DISEO DEL SISTEMA

3.1 DATOS GENERALES DE LA EMPRESA.- Razn Social: Cargo Master S.A.C

3.2 SITUACION ACTUAL

Las solicitudes de cambios son enviadas al rea de TI por correo electrnico. No existe un formato estndar de solicitud

No hay reportes de cambios solicitados

A continuacin se detalla las solicitudes de cambios estndar que se implementaran en el Sistema de Gestin de Cambios:

A) Solicitud de asignacin de equipo a un nuevo personal B) Solicitud de cambio de correo electrnico C) Solicitud de acceso a pgina Web D) Solicitud de opciones en el Sistema Operacional de la Empresa E) Solicitud de instalacin de un programa determinado F) Solicitud de Cambio de equipo de computo G) Solicitud de baja de usuario

A) Solicitud de asignacin de equipo a un nuevo personal 1) Descripcin de la solicitud

Esta solicitud se realiza cuando hay un nuevo ingreso de personal al cual se le tiene que asignar un equipo y configurarlo para que pueda realizar su trabajo correctamente.

Es solicitado por el Jefe del rea.

2) Situacin Actual Los jefes de cada rea envan la solicitud va correo electrnico, esto no

permite que la informacin este estructurada siendo imposible llevar un control del estado de la solicitud

No existe un estndar de solicitud; cada jefe de rea enva la informacin de manera diferente y en algunos casos ambiguos, esto implica que se tenga que responder el correo de solicitud con algunas preguntas que esclarezcan las dudas. Un ejemplo de lo mencionado se refiere a los permisos sobre el sistema que maneja los procesos del negocio, la solicitud es Dar permisos al Sistema al modulo de Cotizaciones, sin embargo no especifica si se tiene que dar permisos de creacin, consulta, modificacin o eliminacin.

La informacin que envan no es completa, puede darse el caso en que no se informe si el usuario tendr o no anexo telefnico, o si necesitar una licencia de office.

El rea de TI actualiza los datos en un archivo Excel, una vez realizada la configuracin del equipo se tiene que actualizar la ip que le corresponde al equipo, el anexo telefnico, la cuenta de correo y las claves de usuario, esto en un excel y con el problema ya solo puede abrirse como escritura por una persona, para el caso que se configuren varios equipos de diferentes personas, esperan que se cierre el Excel para poder actualizar los datos, siendo esto improductivo.

El inventario de hardware se actualiza en un archivo Excel, terminada la configuracin del equipo se relaciona el equipo al usuario

El inventario de software se actualiza en Excel, se relaciona el usuario que con la licencia de determinado software, como por ejemplo el antivirus, el office, el Sistema Operativo etc.

La culminacin de la configuracin del equipo es comunicada verbalmente al responsable del rea de TI que es quien recibe la solicitud de cambio.

La culminacin del trabajo es comunicada al solicitante mediante respuesta a su correo electrnico por parte del responsable del rea.

El solicitante enva un correo confirmando la configuracin.

3) Situacin Propuesta Los jefes de cada rea realizaran la solicitud va el Sistema de Gestin de

Cambios, cada solicitud tendr un estado: Solicitado, En Proceso, Realizado, Rechazado, lo cual permitir que se tenga un conocimiento del estado en el que se encuentra la solicitud.

Se creara un formulario estndar para esta solicitud, que tendr toda la informacin que se necesita para poder configurar de manera correcta el equipo del nuevo personal.

El sistema permitir al solicitante escoger para el nuevo personal la parte hardware y el software que necesita el usuario de manera sencilla, de esta forma no habr omisiones en la informacin que necesita el rea de TI.

El rea de IT tendr una opcin en el Sistema de Gestin Cambios de migrar los datos ingresados en la solicitud de cambio, se actualizaran automticamente los datos de Inventario de Hardware, Inventario de

Software, Inventario de Licencias, Inventario de IPs, Inventario de Anexos Telefnicos, Inventario de passwords, esto le da mayor eficiencia y da mayor productividad al trabajo del personal del rea de TI, ahorrndose horas hombre por doble digitacin.

La culminacin de la configuracin del equipo es comunicada mediante el sistema (que adicional al estado de la solicitud enva una confirmacin de correo al responsable) de tal forma que el responsable del rea que es quien recibe la solicitud de cambio pueda evaluarlo y proceder a dar por realizada la solicitud.

El Responsable del rea utilizando el sistema cambia el estado de la Solicitud a Realizado y el sistema enva un correo al solicitante con la confirmacin del trabajo realizado.

El Solicitante podr confirmar el trabajo cambindole el estado de la Solicitud a Aceptado.

Despus de un determinado tiempo se da por Cerrada la Solicitud.

B) Solicitud de cambio de correo electrnico 1) Descripcin de la solicitud

El usuario va a ser cambiado a otra rea por lo que se le asignar un nuevo correo electrnico.

Esta solicitud es solicitada por el Jefe del rea. La solicitud puede tener una variante, el usuario tendr un nuevo correo y

su correo anterior ser asignado a otro usuario. El usuario puede recibir copias de otros correos corporativos. Los correos del usuario pueden ser copiados a una cuenta corporativa.

2) Situacin Actual El jefe del rea indica por correo electrnico cual es el nuevo correo que

se le asignara al usuario. En el correo enviado por el solicitante se indican las opciones de copias

que recibir el usuario. En el correo enviado por el solicitante se indica si el correo a cambiar ser

reasignado a otro usuario.

El solicitante no puede saber el estado de la solicitud porque no hay un Sistema donde consultar, la nica forma seria escribiendo un correo o llamando por telfono al rea de TI.

La actualizacin al inventario de cuentas de correo electrnico se hace en un archivo excel.

Una vez terminada la configuracin del nuevo correo se enva un correo electrnico al solicitante confirmando el cambio.

No se pueden sacar reportes de los cambios de correo electrnico

3) Situacin Propuesta El jefe del rea realizar la solicitud por sistema que le permitir elegir las

opciones que necesita para el cambio de correo. Cuando la solicitud es realizada el sistema enva un correo electrnico al

rea de TI, a manera de alerta para que pueda verificar en el sistema lo solicitado.

Las copias de los correos que se solicitan, permitirn que el Inventario de copias de correos se actualice automticamente, ahorrando as tiempo del personal de sistemas.

Si el correo que se va a cambiar se reasignara a otra persona, el Sistema realizara la actualizacin automtica del inventario de correos.

El solicitante podr verificar el estado de su solicitud en el sistema. El sistema permitir tener un inventario de correos electrnicos, que sern

actualizados automticamente una vez que el rea de TI genere la actualizacin.

Una vez terminada la configuracin del nuevo correo por parte del personal de TI se cambiar el estado de la solicitud a realizado y el Sistema enviar un correo electrnico al solicitante avisando del cambio realizado.

El solicitante verificar el cambio y modificar el estado del cambio dando su conformidad.

El responsable del rea de TI dar por cerrado el cambio en el Sistema. Se podrn obtener reportes de los cambios de correo electrnico

solicitados.

C) Solicitud de acceso a pgina Web 1) Descripcin de la solicitud

Las pginas web estn controladas para los usuarios mediante un proxy, esto da la seguridad de que no puedan ingresar a pginas que no estn relacionadas con el trabajo que desempean.

Se cuenta con una lista de pginas habilitadas, sin embargo los usuarios pueden necesitar alguna pgina adicional sea de un cliente o de un proveedor nuevo.

La solicitud de una nueva pgina web es lo que realiza el usuario para que pueda acceder a la pgina web que necesita.

2) Situacin Actual El usuario que solicita la habilitacin de una pgina web enva un correo

electrnico al rea de TI solicitando la pgina que necesita. Coloca en copia del correo electrnico a su jefe inmediato. No es necesario que se apruebe la solicitud por parte del jefe. La habilitacin de la pgina por parte del rea de TI, se hace

manualmente.

Una vez terminada la habilitacin de la pgina web solicitada, se enva un correo electrnico al solicitante confirmando el cambio.

No se pueden sacar reportes de las solicitudes de pginas web. Par saber quien solicitud la pagina se tendra que revisar los correos

electrnicos lo que muchas veces es lento.

3) Situacin Propuesta

El usuario solicita la habilitacin de una o ms pginas web mediante el Sistema.

El sistema enva una copia de alerta de solicitud al jefe del rea del usuario que realiza la solicitud, y al rea de TI para que realizar la solicitud.

La habilitacin de la pgina por parte del rea de TI, se realizar de manera automtica desde el sistema.

Una vez terminada la habilitacin de la pagina web, se cambiar el estado de la solicitud a realizado y el usuario solicitante recibir un correo a manera de alerta.

Una vez que el usuario verifique la habilitacin de la pagina deber dar su conformidad cambiando el estado de la solicitud.

El rea de TI dar por cerrado la solicitud cambiando el estado de la misma.

Se podr sacar reportes de las solicitudes. Par saber quien realiz la solicitud de determinada pgina.

D) Solicitud de opciones en el Sistema Operacional de la Empresa 1) Descripcin de la solicitud

El Sistema Operacional controla todas las operaciones que realiza la empresa, es decir el core del negocio.

El Sistema Operacional incluye las reas de: Comercial, Operaciones, Facturacin, Cuenta con Agentes, Contabilidad.

Para acceder al sistema a cada usuario se le tiene que registrar como usuario del sistema, y designarle permisos sobre cada opcin.

Esta solicitud de asignacin de permisos se refiere a darle autorizacin a un usuario sobre el sistema operacional, para que acceda a determinadas opciones y que pueda crear, modificar, eliminar, consultar, imprimir registros de la opcin autorizada.

2) Situacin Actual El jefe del rea indica por correo electrnico cuales son las opciones que

se le tienen que habilitar en el Sistema Operacional al usuario.

En el correo enviado por el solicitante se indican las opciones que deber tener el usuario, estas opciones normalmente no son muy detalladas, por ejemplo se puede solicitar dar permiso a la parte comercial en modo consulta, sin embargo hay opciones de la parte comercial que son reportes gerenciales que no deberan tener, esto no se especifica, se da por sobreentendido por el personal de TI que ya conoce las opciones.

El solicitante no puede saber el estado de la solicitud porque no hay un Sistema donde consultar, la nica forma seria escribiendo un correo o llamando por telfono al rea de TI.

La asignacin de permisos al Sistema la realiza el personal de TI, ingresando al Sistema y asignando los permisos.

Una vez terminada la asignacin de permisos sobre el Sistema Operacional enva un correo electrnico al solicitante confirmando el cambio.

3) Situacin Propuesta El jefe del rea realizar la solicitud por sistema que le permitir elegir las

opciones que necesita el usuario y las opciones sobre los registros. Cuando la solicitud es realizada el sistema enva un correo electrnico al

rea de TI, a manera de alerta para que pueda verificar en el sistema lo solicitado.

El personal de TI podr asignar los permisos al usuario automticamente desde el Sistema, utilizando las opciones seleccionadas por el solicitante.

Asignacin automtica a partir de una solicitud ahorrara tiempo al personal de TI y la eficiencia del trabajo ser la optima, ya que no habr error humano al trasladar la informacin manualmente de la solicitud.

El solicitante podr verificar el estado de su solicitud en el sistema. Una vez terminada la asignacin por parte del personal de TI se cambiar

el estado de la solicitud a realizado y el Sistema enviar un correo electrnico al solicitante avisando del cambio realizado.

El solicitante verificar el cambio y modificar el estado del cambio dando su conformidad.

El responsable del rea de TI dar por cerrado el cambio en el Sistema. Se podrn obtener la informacin de manera sencilla de los cambios

solicitados de asignacin de permisos sobre el Sistema Operacional.

E) Solicitud de instalacin de una aplicacin determinada 1) Descripcin de la solicitud

Las aplicaciones informticas o programas que necesita el usuario son solicitadas cuando el usuario ingresa a la empresa.

Pueden darse situaciones en las que se necesite instalar un nuevo aplicativo o cambiarlo por otro. Este es el caso que se necesita realizar una solicitud de instalacin de un nuevo aplicativo.

2) Situacin Actual El jefe del rea indica por correo electrnico cual es el aplicativo que se le

tiene que instalar al usuario. En el correo enviado por el solicitante se indican las opciones que deber

tener el usuario, estas opciones normalmente no se indica el nombre del aplicativo.

Se lleva un control de los aplicativos con licencia en un cuadro excel para El solicitante no puede saber el estado de la solicitud porque no hay un

Sistema donde consultar, la nica forma seria escribiendo un correo o llamando por telfono al rea de TI.

La asignacin de permisos al Sistema la realiza el personal de TI, ingresando al Sistema y asignando los permisos.

Una vez terminada la asignacin de permisos sobre el Sistema Operacional enva un correo electrnico al solicitante confirmando el cambio.

3) Situacin Propuesta

El jefe del rea realizar la solicitud por sistema que le permitir elegir las opciones que necesita el usuario y las opciones sobre los registros.

Cuando la solicitud es realizada el sistema enva un correo electrnico al rea de TI, a manera de alerta para que pueda verificar en el sistema lo solicitado.

El personal de TI podr asignar los permisos al usuario automticamente desde el Sistema, utilizando las opciones seleccionadas por el solicitante.

Asignacin automtica a partir de una solicitud ahorrara tiempo al personal de TI y la eficiencia del trabajo ser la optima, ya que no habr error humano al trasladar la informacin manualmente de la solicitud.

El solicitante podr verificar el estado de su solicitud en el sistema. Una vez terminada la asignacin por parte del personal de TI se cambiar

el estado de la solicitud a realizado y el Sistema enviar un correo electrnico al solicitante avisando del cambio realizado.

El solicitante verificar el cambio y modificar el estado del cambio dando su conformidad.

El responsable del rea de TI dar por cerrado el cambio en el Sistema. Se podrn obtener la informacin de manera sencilla de los cambios

solicitados de asignacin de permisos sobre el Sistema Operacional.

F) Solicitud de Cambio de equipo de computo G) Solicitud de baja de usuario