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

Negocio
Cambio
estratgico

Gestionar el
Negocio

Proveedor de Servicios
Gestionar Servicios de TI

Suministrador
Gestionar el
negocio

Cambio
Tctico

Gestionar el proceso de
Negocio

Cartera de
Servicios

Gestionar
servicios

Cambio
Operativo

Gestionar la
operacin de negocio

Operaciones del
Servicio

Operaciones
Externas

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

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

aprovisionamiento y asociacin.

proyectos

con

la

organizacin

de

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.

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.

PRODUCT
BACKLOG

SPRINT
BACKLOG

INCREMENTO

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