5.2 Change and Configuration SMF - Esp

Microsoft® Operations Framework
Version 4.0
Función de Cambio y Configuración para la

Administración del Servicio
Publicado: Abril 2008

Para la información más actual, por favor vea
microsoft.com/technet/solutionaccelerators
FPO
Copyright © 2008 Microsoft Corporation. This documentation is licensed to you under the Creative Commons
Attribution License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/us/ or send
a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA. When
using this documentation, provide the following attribution: The Microsoft Operations Framework 4.0 is provided
with permission from Microsoft Corporation.
This documentation is provided to you for informational purposes only, and is provided to you entirely "AS IS".
Your use of the documentation cannot be understood as substituting for customized service and information
that might be developed by Microsoft Corporation for a particular user based upon that user’s particular
environment. To the extent permitted by law, MICROSOFT MAKES NO WARRANTY OF ANY KIND,
DISCLAIMS ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, AND ASSUMES NO LIABILITY TO
YOU FOR ANY DAMAGES OF ANY TYPE IN CONNECTION WITH THESE MATERIALS OR ANY
INTELLECTUAL PROPERTY IN THEM.
Microsoft may have patents, patent applications, trademarks, or other intellectual property rights covering
subject matter within this documentation. Except as provided in a separate agreement from Microsoft, your use
of this document does not give you any license to these patents, trademarks or other intellectual property.
Information in this document, including URL and other Internet Web site references, is subject to change without
notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail
addresses, logos, people, places and events depicted herein are fictitious.
Microsoft is a registered trademark of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective
owners.
You have no obligation to give Microsoft any suggestions, comments or other feedback ("Feedback") relating to
the documentation. However, if you do provide any Feedback to Microsoft then you provide to Microsoft, without
charge, the right to use, share and commercialize your Feedback in any way and for any purpose. You also give
to third parties, without charge, any patent rights needed for their products, technologies and services to use or
interface with any specific parts of a Microsoft software or service that includes the Feedback. You will not give
Feedback that is subject to a license that requires Microsoft to license its software or documentation to third
parties because we include your Feedback in them.
Solution Accelerators microsoft.com/technet/SolutionAccelerators

Contenido
Lugar de la Función de Administración de Servicio (SMF) de Cambio y
Configuración dentro del MOF (Microsoft Operations Framework)..............¡Error!
Marcador no definido.
¿Porque utilizar una Función de Cambio y Configuración?....................¡Error!
Visión General de la Función de Cambio y Configuración...........¡Error! Marcador
no definido.
Roles para la (SMF) de Cambio y Configuración.............¡Error! Marcador no
definido.
Metas del SMF de Cambio y Configuración.................................................5
Términos Clave......................................................................................5
Diagrama de Flujo del SMF de Cambio y Configuración......................................7
Proceso 1: Documentar la configuración base actual............¡Error! Marcador no
definido.
Actividades: Documentar la configuración base actual........................¡Error!
Proceso 2: Iniciar el Cambio...............................¡Error! Marcador no definido.
Actividades: Iniciar el Cambio.......................¡Error! Marcador no definido.
Proceso 3: Clasificar el Cambio...........................¡Error! Marcador no definido.
Actividades: Clasificar el Cambio....................¡Error! Marcador no definido.
Proceso 4: Aprobar y programar el Cambio...........¡Error! Marcador no definido.
Actividades: Aprobar y programar el Cambio................¡Error! Marcador no
definido.
Proceso 5: Desarrollar y Probar el Cambio............¡Error! Marcador no definido.
Actividades: Desarrollar y Probar el Cambio..................¡Error! Marcador no
definido.
Proceso 6: Liberar el Cambio.......................................................................28
Actividades: Liberar el Cambio......................¡Error! Marcador no definido.
Process 7: Validar y Revisar el Cambio..........................................................34
Actividades: Validar y Revisar el Cambio......................¡Error! Marcador no
definido.
Conclusión................................................................................................39
Retroalimentación.......................................¡Error! Marcador no definido.

Lugar de la Función de Cambio y
Configuración para la Administración
del Servicio dentro del MOF
El marco de referencia MOF para el ciclo de vida de los Servicios de TIC, incluye todas
las actividades y procesos involucrados en la administración de Servicios de TIC: su
conceptualización, desarrollo, operación, mantenimiento y finalmente su retiro del
ambiente productivo. MOF organiza estas actividades y procesos en Funciones de
Administración del Servicio (SMF) que se agrupan en fases del ciclo de vida. Cada SMF
pertenece únicamente a una fase del ciclo de vida y contiene un único grupo de metas y
resultados esperados, que sirven para lograr los objetivos de esa fase en particular. Los
SMF se pueden utilizar como grupos independientes de procesos pero cuando se
utilizan los SMF´s juntos, son más efectivos para asegurar la Entrega del Servicio con la
calidad y los niveles de riesgo requeridos.
El SMF de Cambio y Configuración pertenece a la Capa de Administración dentro del
ciclo de vida del Servicio de MOF. La siguiente figura muestra el lugar del SMF de
Cambio y Configuración dentro de la capa de Administración así como el lugar de la
capa de Administración dentro del ciclo de vida de servicios de TIC.
Figura 1. Lugar del SMF de Cambio y Configuración dentro del ciclo de vida del
Servicio de TICs
Antes de utilizar esta SMF, se debería de leer la guía de MOF 4.0 para aprender más
acerca del ciclo de vida de Servicios de TIC planteados en el MOF, así como de la capa
de Administración:
 Visión General de MOF
 Visión General de la Capa de Administración

Porque utilizar una Función de Cambio y
Configuración
Esta función es útil para cualquiera que desee entender y tener control de los cambios
hechos en TIC y se incluye como hacer lo siguiente:
 Administrar los cambios
 Saber el estado actual de las configuraciones en todo tiempo
 Reducir el Riesgo de impactos negativos debidos a cambios en la Organización
Visión General de la Función de Cambio

y Configuración
La administración del cambio es muy importante. Para entregar un servicio de TIC de

forma confiable y efectiva, las organizaciones necesitan asegurar que el cambio es
planeado y que es de utilidad. El negocio confía en que las TIC siguen procesos de
administración del cambio, que toman en consideración las necesidades de acciones
rápidas, servicios confiables y cumplimiento con políticas y regulaciones.
El cambio en cualquiera de sus formas conlleva un Riesgo (Riesgo de falla, resistencia

cultural, interrupción de las operaciones, retos técnicos, falta de recursos y
consecuencias inesperadas). Pero muchas organizaciones fallan en la administración del
cambio, ya sea porque lo consideran tan grande y caro que ni siquiera lo intentan o
porque se quiere implementar de una manera tan complicada que nadie usa el nuevo
servicio. Y no tiene que ser de esa manera.
La administración del cambio y la configuración ofrece una guía basada en mejores

prácticas que permite a las áreas de TIC administrar el cambio mediante procesos
repetibles, predecibles y con parámetros de medición, al tiempo que se ocupa de los
Riesgos. La tolerancia de una Organización a el Riesgo, determina el nivel apropiado
de detalle y formalidad a aplicar en los procesos de cambio dependiendo del tipo,
tamaño y el tiempo requerido.
Cuando las áreas de TIC determinan las limitaciones y el nivel de formalidad que la
administración de cambios debería tener en cualquier punto del ciclo de vida del servicio,
estas áreas deben encontrar un balance entre el costo de controlar el cambio contra el
beneficio del propio control. Este balance depende del impacto entre hacer o no el
cambio, la tolerancia al Riesgo de la Organización y la velocidad a la que se deben de
tomar las decisiones. Los costos de los controles para la administración del cambio
deben de incluir el tiempo, el dinero y la velocidad. Otro costo puede ser el limitar el
análisis de otras opciones, demasiado pronto. Los beneficios de restringir los cambios
incluyen mayor eficiencia en el trabajo, un ambiente más estable, un menor impacto a
los servicios afectados, mismos que tienen implicaciones financieras y de tiempo.
La administración del cambio aplicada en un nivel apropiado a todo lo largo del ciclo de
vida del servicio de TIC, establece límites dentro de las cuales se puede tener un cierto
grado de flexibilidad. Estos límites se van estrechando durante las fases de

Chapter Title 3
Planeación, de Entrega y de Operación, cada vez que el impacto y los Riesgos al

ambiente de producción de los servicios de TIC se hacen más evidentes.
El Riesgo de un cambio está determinado por la etapa de del ciclo de vida del servicio de
TIC en la que se va a dar el cambio. El nivel del Riesgo que determina lo estricto que
debe ser el control del cambio.
El manejo del Riesgo se debe en parte, a la etapa en el ciclo de vida del servicio de TIC
donde se requiere el cambio. Los controles del cambio son menos rigurosos para las
solicitudes de cambio en las etapas de Planeación y al inicio de la etapa de Entrega, los
controles son más rigurosos hacia el final de la etapa de Entrega y en la etapa de
Operación. En la etapa de Planeación y al principio de la fase de Entrega, hay
Riesgos que se presentan al no permitir la exploración y evaluación de un rango más
amplio de alternativas. Conforme un servicio de TIC avanza en la etapa de Entrega, el
Riesgo se incrementa y se puede tener la opción de abandonar el trabajo realizado o
bien, de ampliar la visión original de tal manera que las decisiones tomadas en la etapa
de Planeación tengan que ser cambiadas. En la etapa de Operación, el mayor Riesgo
es el de desestabilizar el correcto funcionamiento de los servicios de TIC.
Los cambios se pueden clasificar en las siguientes categorías:

 Mayor. Es un cambio donde el impacto dentro de la Organización es a nivel
masivo, por ejemplo, un cambio a nivel departamental o a lo largo de toda la
Organización, un cambio en toda la red de comunicaciones o un cambio en un
servicio que se presta en toda la Organización.
 Significativo. Cambio cuyo efecto abarca una parte de la Organización pero no
a nivel masivo, por ejemplo, un cambio que afecta a un grupo dentro de un
departamento o un cambio que afecta a un grupo específico de componentes de
configuración (CI´s ).
 Menor. Un cambio que afecta aun número reducido de individuos o de CI´s,
por ejemplo, un cambio a una impresora utilizada por un departamento que está
constituido por unas pocas personas.
 Estándar. Un cambio que se ha realizado antes y que es una práctica común
en la Organización, por ejemplo, la actualización de un perfil de usuario.
Los cambios Estándar proporcionan agilidad dentro de los límites de la Administración

del Cambio en la Fase de Operación. Cada Organización debe de desarrollar una
colección de cambios Estándar, asegurando la predictibilidad y la utilización eficiente de
recursos al implementar procesos Estándar “ya utilizados, probados y con resultados
predecibles”, para Solicitudes de Cambio comunes (RFC por sus siglas en inglés).
Esto se logra al identificar cambios que son comunes y recurrentes, y cuya ejecución se
haya optimizado. Idealmente, el 80% o más, de los cambios en la Fase de Operación
deberían de ser Estándar, esto es una señal de la madurez del proceso de
administración del cambio.
Un cambio Estándar comienza como Menor, Significativo o Mayor. Una vez que el
cambio ha sido probado exhaustivamente, implementado y validado y que los pasos de
su ejecución han sido documentados, un cambio se puede volver Estándar. Ejemplos
de cambios Estándar incluyen actualizaciones a configuraciones de equipos de cómputo,
instalaciones de software estándar, reseteo de contraseñas y administración de parches
de seguridad y actualización.

4 Microsoft Operations Framework v4
Conforme los cambios son aprobados e implementados, es critico registrar una

fotografía de la configuración del ambiente productivo antes y después de que se lleven
a cabo los cambios. Con la disponibilidad de la información de la configuración, las
áreas de TIC están mejor preparadas para:
 Evaluar los cambios propuestos
 Entender el estado actual del ambiente de producción
 Resolver problemas analizando los cambios recientes al ambiente de producción
 Regresar la configuración a un estado previamente conocido para resolver
problemas crónicos o para cumplir con requerimientos regulatorios.
 Probar los cambios fuera del ambiente de producción, con la confianza que el
ambiente productivo es similar al ambiente de prueba.

Chapter Title 5
Roles para la (SMF) de Cambio y

Configuración
El equipo principal de SMF de Rendición de Cuentas que aplica al SMF de Cambio y
Configuración es el de Rendición de Cuentas de Administración.
La siguiente tabla enlista los tipos de roles asociados con la Rendición de Cuentas de
Administración así como las responsabilidades y roles para cada tipo de rol
Tabla 1. Rendición de Cuentas de Administración y sus Tipos de Roles
correspondientes
Tipo de Rol Responsabilidades Rol en este SMF
Administrador del Cambio  Administrar las  Asegura que los
actividades del proceso cambios se lleven a
de administración del cabo con el menor
cambio para el área de Riesgo e impacto para
TIC la Organización
Administrador de  Hacer el seguimiento  Asegura que exista un
Configuración de lo que está estado conocido en
cambiando y el impacto todo tiempo
que se tiene
 Hacer el seguimiento
de los Elementos de la
Configuración (CI´s por
sus siglas en inglés), y
actualizar el Sistema de
Administración de la
Configuración (CMS
por sus siglas en
inglés)
Metas del SMF de Cambio y Configuración

La meta principal de la Administración de Cambio y Configuración, es crear un medio
ambiente donde los cambios puedan realizarse con el menor Riesgo e impacto para la
Organización.
La tabla 2 muestra los resultados buscados con las metas de SMF de Cambio y
Configuración, y enlista las mediciones que se pueden utilizar para verificar que tan
exitosamente se han alcanzado las metas.
Tabla 2. Resultados y mediciones de las metas del SMF de Cambio y Configuración

Resultados Mediciones
Tener un proceso predecible  Mejorar los marcadores de confiabilidad (ver el SMF
para administrar, los Cambios de Función de Confiabilidad para la Administración
al ambiente de producción, del Servicio, y la revisión de la salud (estado) de la
para mejorar la confiabilidad y Operación en el SMF de Función de Operación para
la satisfacción de los clientes. la Administración del Servicio)
 Mejorar los marcadores de la Satisfacción de los
Clientes (ver la Revisión del Servicio en el
documento Visión General de la Fase de
Planeación)
Eliminar cambios  Reducción de proyectos cancelados
Resultados Mediciones
innecesarios.  Reducción en cambios revertidos
Reducir efectos secundarios  Reducción de fallas en el ambiente de producción
no buscados de manera
intencional.
Habilitar al área de TIC para  Número de mapas de servicios administrados
revertir a un estado previo, en comparados con el número de servicios ofrecidos
respuesta a la interrupción de  Número de componentes en el Sistema de
servicios, mediante un Administración de Configuración, con registros
conocimiento preciso de la históricos de su estado
Configuración y los Cambios
 Rango de tiempo durante el cual se mantienen los
realizados.
datos históricos en el Sistema de Administración de
Configuración (por ejemplo, estados previos de los
últimos 6 meses)
Habilitar la resolución de  Los Cambios en el ambiente productivo son
problemas mediante el conocidos
análisis de los cambios  Bajar el tiempo para resolver problemas
recientes.

Chapter Title 7
Términos Clave
La siguiente tabla incluye las definiciones de los términos clave utilizados en este
documento.
Tabla 3. Términos clave
Término Definición
Cambio La adición, modificación o eliminación de: hardware, redes, software,
aplicaciones, ambientes, sistemas, configuraciones de equipo de
cómputo de escritorio o documentación asociada; aprobados,
soportados o de las configuraciones base.
Consejo Un grupo multidisciplinario conformado para evaluar solicitudes de
consultor de cambio por necesidades de negocio, prioridades, costo/beneficio,
Cambio (CAB) impactos potenciales a otros sistemas o procesos.
Categoría de Medida del impacto de un cambio tanto en TIC como en el negocio.
Cambio La complejidad del cambio y los recursos requeridos, incluyendo al
personal, dinero y tiempo, son medidos para determinar la categoría.
Bitácora de Un registro de las Solicitudes de Cambio (RFCs por sus siglas en
Cambio inglés), que se entregan para todos los cambios de un servicio y que
monitorea el progreso de cada cambio desde la solicitud, hasta la
revisión, aprobación, implementación y cierre. Un registro de Cambio
puede ser administrado de forma manual con un documento o una
hoja de cálculo o bien se puede administrar automáticamente
mediante el uso de alguna herramienta.
Administrador El Rol que tiene la responsabilidad de administrar el proceso de
del Cambio administración del Cambio en el área de TIC.
Elemento de la Un componente de TIC que se encuentra bajo el control de la
Configuración administración de Configuración. Cada CI puede estar conformado a
(CI) su vez por otros CI´s. Los CI´s varían en complejidad, tamaño y
tipo; su alcance puede ser desde un módulo de software o un
componente menor de hardware, hasta un sistema completo
(incluyendo hardware, software y documentación).
Sistema de Un conjunto de herramientas que se utiliza para administrar los
administración datos, generados en la administración de los servicios de TIC, tales
de la como cambios, versiones, errores conocidos e incidentes.
Configuración
(CMS)
Librería del Una librería segura de software donde las versiones de los
Software elementos CI´s de software, aprobados por el Consejo Consultor de
Definitivo (DSL) Cambio (CAB) para su implementación, son mantenidos en su forma
control de calidad definitiva.
Calendario de Un registro de cambios aprobados por realizar, también conocido
Cambios a como calendario de cambio de versiones, que sirve para entender el
Realizar (FSC) impacto que los cambios ya aprobados pueden tener sobre nuevos
cambios propuestos. Esto también se puede tener utilizando el
portafolio de servicios descrito en la Función de Administración de
Servicio descrita en el SMF de Función de Alineación de las TICs
con el Negocio.

Término Definición
Revisión Post- Una revisión que ocurre después de dar de alta un nuevo servicio o
Implementación bien, después de actualizar un servicio. Esta revisión evalúa y mide
(PIR) el éxito de la versión en el ambiente de producción.
Liberación Una colección de uno o más cambios que incluyen nuevos
(Release) elementos de configuración (CI´s) y/o modificaciones a CI´s
existentes, los cuales son probados y luego introducidos al ambiente
de producción.
Administrador El Rol responsable de administrar y coordinar las actividades del
de Liberaciones proceso de administración de liberaciones en el área de TIC.
Solicitud de La solicitud formal de un Cambio, la que incluye una descripción del
Cambio (RFC) Cambio, los componentes que se verán afectados, la necesidad de
negocio, los costos estimados, evaluación del Riesgo, recursos
necesarios y el estado de la aprobación.
Valor del Riesgo Una parte del documento de RFC, que incluye la evaluación del
Riesgo que implica el Cambio.
Mapa de Una representación del servicio desde la perspectiva del negocio y
Servicio del usuario, misma que presenta las dependencias críticas,
configuraciones, y áreas de responsabilidad (para más información
acerca de los mapas de servicio, vea el SMF de Función de
Alineación de las TICs con el Negocio.
Cambio Una categoría de Cambio que describe los cambios que están pre-
Estándar aprobados y que pueden omitir el proceso de autorización para
proceder directamente a su implementación.
Diagrama de Flujo de Cambio y

Configuración
El diagrama de flujo del proceso de Cambio y Configuración, conforma la estructura de
esta Función de Administración de Servicios (SMF), mediante un grupo consistente de
procesos para iniciar y completar los Cambios.
La administración de Cambio y Configuración consiste de las siguientes actividades:

 Documentar la configuración base actual
 Iniciar el Cambio
 Clasificar el Cambio
 Aprobar y programar el cambio
 Desarrollar y probar el Cambio
 Liberar (implementar) el Cambio
 Validar y revisar el Cambio

Chapter Title 9
La figura 2 muestra el diagrama de flujo del proceso de la administración de Cambio y

Configuración.
Figura 2. Diagrama de flujo del proceso de administración de Cambio y

Configuración

Proceso 1: Documentar la configuración

base
Este primer proceso para poder iniciar e implementar Cambios, consiste en documentar
la configuración base para poder conocer la configuración de inicio. Esta configuración
base se puede necesitar para revertir los cambios, para la recuperación de desastres,
así como para entender el impacto del Cambio propuesto.
Figura 3. Documentar la configuración base
Actividades: Documentar la configuración

base
Para poder administrar exitosamente el Cambio, una Organización debe de administrar
la configuración del ambiente de producción. La forma más efectiva de lograrlo es
documentar la configuración base, antes y después de cada cambio.
Una Configuración base es una fotografía del ambiente de TIC, que sirve para identificar
la estructura y las dependencias que subyacen en ella. Los datos de esa fotografía
pueden ser capturados y guardados en un Sistema de Administración de la
Configuración (CMS por sus siglas en inglés). Un CMS puede ser tan simple como una
hoja de cálculo o tan complejo como una serie de herramientas que incluyan un
manejador de bases de datos.
Un CMS proporciona:
 Una forma de entender,controlar y predecir las consecuencias del Cambio.
 Una representación adecuada y comprensible del estado del ambiente de
producción.
 Una historia de los estados anteriores, para apoyar los esfuerzos de análisis y
solución de problemas.
Los profesionales de TIC pueden utilizar el CMS en todo el proceso de Cambio, para:

Chapter Title 11
 Revisarlo como parte de la evaluación de una nueva Solicitud de Cambio (RFC), con
la finalidad de entender el impacto del Cambio propuesto.
 Actualizarlo con las solicitudes de Cambio (RFC) aprobadas, con la finalidad de que
esta nueva información pueda ser utilizada en la evaluación de nuevas RFC´s.
 Actualizarlo con los Cambios liberados, para que esta información pueda ser
utilizada en la solución de problemas, que se presenten después de realizado el
Cambio.
 Utilizarlo para contar con un estado bien conocido y estable, en caso de que se
requiera revertir cualquier Cambio, que tenga impactos negativos inesperados
Un CMS contiene información de los Elementos de Configuración (CI´s), los cuales son
componentes importantes de TIC´s, para entender el estado del ambiente de
producción. Los CI´s varían en complejidad, tamaño y tipo; su alcance puede ser desde
un módulo de software o un componente menor de hardware, hasta un sistema completo
(incluyendo hardware, software y documentación). Todas las versiones de los CI´s de
software, que el Consejo Consultor de Cambios (CAB) ha aprobado para su
implementación deben de guardarse en el formato definitivo, que debe tener su control
de calidad, y dentro de la Librería de Software Definitiva (DSL por sus siglas en inglés).
Esta es una Librería de Software segura, que provee una buena fuente para conocer el
software que se usa en el ambiente de producción.
Documentar la configuración base es un gran reto. Una opción es documentar mientras
se van haciendo los cambios, así que eventualmente se va complementando toda la
información del ambiente de producción.
La siguiente tabla muestra las actividades que forman parte de la documentación de la
configuración.
Estas incluyen:
 Definir y guardar los datos de configuración que deben integrarse al CMS, cada vez
que un nuevo elemento de configuración (CI) se incorpora al ambiente de
producción.
 Auditar el contenido del CMS.
Tabla 4. Actividades y Consideraciones para documentar la Configuración base

Actividades Consideraciones
Definir y guardar Preguntas clave:
los datos de  ¿Cuál es la información que se debe de guardar?
configuración que
deben integrarse al  ¿Qué usuarios requieren accesar la información de los servicios
y/o componentes de sistemas?
CMS
 ¿En qué formato es más útil la información para cada usuario?
 ¿Alguna información en el CMS necesita tener un acceso
restringido?
 ¿Qué tan frecuentemente se requiere actualizar los datos?
 ¿Cómo se van a utilizar los datos?
Entradas:
 Acuerdos de niveles de Servicio (SLAs) (ver el SMF de Función
de Alineación de las TICs con el Negocio)
 Acuerdos de niveles de Operación (OLAs). (ver el SMF de
Función de Alineación de las TICs con el Negocio)
 Contratos con proveedores externos (UCs) (ver el SMF de
Función de Alineación de las TICs con el Negocio)
 Leyes y regulaciones aplicables (ver el SMF de Función de
Políticas para la Administración del Servicio)
 Políticas Internas (ver el SMF de Función de Políticas para la
Administración del Servicio)
 Análisis de Riesgo e Impacto (ver el SMF de Función de
Gobernabilidad, Riesgo y Cumplimiento)
 Lista de los requerimientos, los necesarios y los deseables,
para los reportes del sistema de administración de la
Configuración CMS
Salidas:
 Requerimientos de las RFC y del CMS
Mejores Prácticas:
 Definir el uso de los datos desde el punto de vista del negocio
(interdependencias de los servicios) y desde el punto de vista
técnico (componentes de los sistemas).
 Obtener una idea, lo más completa posible, de las necesidades,
involucrar a todo el personal, relevante para la etapa de
evaluación y planeación. Este grupo de personas puede incluir
a personal de desarrollo de soluciones,
arquitectura/infraestructura de la Organización,
soporte/operación, mesa de servicio y por supuesto del
negocio.
 Comenzar registrando tan pocos datos como sea posible e ir
añadiendo más datos según se vaya necesitando. Mantener
los registros actualizados, requiere de recursos. Asegurar que
los datos que se vayan adicionando, valgan la pena y que
aporten algo. Saber el por qué de los datos que se están
registrando.
 Cuando se añade un nuevo elemento de configuración (CI), hay
que reevaluar los datos de configuración, que deben ser
registrados.

Chapter Title 13
Auditar el Preguntas clave:
contenido del CMS  ¿Las auditorias se efectúan para cumplir con los requerimientos
de alguna regulación o por política?. ¿Qué tan seguido deben
de llevarse a cabo las auditorias?
 ¿Cómo se confirma la información contenida en el CMS?
 ¿Quién lo confirma?
 ¿Se requiere establecer restricciones para accesar al CMS?
Entradas:
 CMS
 Requerimientos de restricción de acceso
 Requerimientos de las regulaciones y/o políticas
 Ambiente de producción
Salidas:
 Reporte de el estado de exactitud de la información
 Planes de remediación para los datos inexactos
Mejores prácticas:
 No permitir que las auditorias al CMS, sean demasiado
espaciadas en el tiempo. Las correcciones menores son más
fáciles de realizar que las remediaciones muy grandes.
 Si el CMS se desactualiza frecuentemente, replantear los
procesos y ajustarlos para lograr más exactitud.

Proceso 2: Iniciar el Cambio

Después de documentar la configuración, se puede iniciar el Cambio.
Figura 4. Iniciar el Cambio
Actividades: Iniciar el Cambio

Las Solicitudes de Cambio (RFC), pueden provenir de diversas fuentes, incluyendo:
 Solicitudes de usuarios-finales. (ver el SMF de Función de Servicio al Cliente para la
Administración del Servicio y la Revisión Gerencial a la Alineación del Servicio en el
documento Visión General de la Fase de Planeación)
 Iniciativas del negocio. (ver el SMF de Función de Alineación de las TICs con el
Negocio)
 Iniciativas de las áreas de TIC. (ver el SMF de Función de Alineación de las TICs
con el Negocio y la Revisión Gerencial del estado de la Operación enel documento
Visión General de la Fase de Operación)
 Análisis de Problemas. (ver el SMF de Función de Administración de Problemas
para la Administración del Servicio)
 Del Monitoreo de los Servicios. (ver el SMF de Función de Monitoreo y Control para
la Administración del Servicio)

Chapter Title 15

Todas las solicitudes de cambio (RFC), requieren ser evaluadas tanto en el impacto,
como en el beneficio, que tienen sobre y para la Organización.
La siguiente tabla enlista las actividades involucradas en el Inicio del Cambio. Estas
incluyen:
 Iniciar una RFC.
 Revisar la configuración desde el punto de vista técnico.
 Revisar la configuración desde el punto de vista del proceso de negocio.
 Identificar el impacto al negocio.
 Actualizar la RFC.
Tabla 5. Actividades y Consideraciones para Iniciar el Cambio

Iniciar una Solicitud de Preguntas clave:
Cambio (RFC)  ¿Qué tipo de información se debe incluir en la
descripción del Cambio? Por ejemplo, el servicio
que se verá afectado, los beneficios al negocio y
la descripción exacta de los Elementos de
Configuración (CI´s) que sufrirán modificaciones.
 ¿Quién puede iniciar un Cambio? ¿Puede
cualquiera en la Organización iniciar un Cambio?
 ¿Cómo se categorizan las RFC y cómo se les da
seguimiento?
 ¿Cada Servicio tiene su propio conjunto de RFC
´s?
 ¿Cómo están interrelacionadas las RFC´s y como
se hacen las referencias cruzadas?
 ¿Hay una RFC específica para los cambios
estándar?
Entradas:
 Solicitud de Cambio
 Descripción del Cambio
Salida:
 Nueva RFC
Mejores prácticas:
 Mantener los formatos de RFC lo más sencillos
posibles, al tiempo que incluyan la suficiente
información para administrar el Riesgo.
 La RFC debe actualizarse continuamente a lo
largo del proceso; puede iniciarse sin la
necesidad de tener toda la información o sin un
análisis detallado y actualizarse después. Es
importante tener un fácil acceso a la RFC, de
manera que las modificaciones sean ágiles.
Adicionalmente, las Organizaciones pueden
utilizar autenticación a nivel de Roles, para
asegurar que los accesos de lectura o
modificación, se aplican correctamente en todo el
proceso. Determinar quién debería tener permiso
de lectura o cambio en la RFC en cada proceso.
 La Organización puede acelerar el proceso para
crear las RFC, utilizando campos prellenados así
como campos con listas desplegables, con
información, tal como el tipo de Cambio, el
Servicio afectado por el Cambio y la tecnología
aplicable.
 Debe de haber un punto de contacto para cada
solicitud de Cambio. Este puede ser el
Administrador del Cambio o el Iniciador del
Cambio. El punto de contacto debería tener
acceso a la información más actual, entender las
implicaciones de recursos, las implicaciones
técnicas y tener la visión de como el Cambio
afectaría a otros Cambios planeados, así como la
afectación al trabajo diario de la Organización.
 No confundir el proceso de la RFC con una
solicitud a la Mesa de Servicio. La última es una
solicitud, por cosas como acceso a un servicio
existente o preguntas de los servicios existentes, y
estas solicitudes se atienden mediante el SMF de
Función de Servicio al Cliente para la
Administración del Servicio. Una RFC se
completa por el grupo de TICs, para asegurar que
los Cambios en el ambiente de producción, se
analicen y se planeen adecuadamente.
 Asegurar que la forma para llenar la RFC, se
explica por si misma y que la forma de solicitar
ayuda es clara, para facilitar su llenado
Revisar la Configuración Preguntas clave::
Técnica  ¿Tiene la RFC identificados todos los Elementos
de Configuración (CI´s) que serán afectados o que
requieren algún Cambio?
 ¿Cuántos CI´s se verán afectados? ¿Es un
Cambio a nivel Global, como una actualización de
software, hay una relación entre los servicios o los
dispositivos en producción, que serán afectados?
 Cuando se busca en la base de datos CMS, ¿Hay
Ci´s adicionales que puedan ser afectados?
Entradas:
 CI´s
 Mapa de Servicio
 Servicios que tienen algún impacto y que han sido
obtenidos del documento de la RFC
Salida:
 CI´s que tienen algún impacto de acuerdo a la
RFC

Chapter Title 17
Revisar el proceso de negocio Preguntas clave:
y la configuración de  ¿Qué procesos de negocio pueden ser afectados
aplicaciones por los Cambios propuestos?
 ¿Qué se requiere cambiar para poder atender la
RFC?
 ¿Qué aplicaciones serán afectadas por la RFC?
 ¿Qué usuarios y qué grupos de negocio deben
estar enterados del Cambio?
Mejores prácticas:
 Se deben identificar las dependencias entre los
procesos de negocio y la funcionalidad de las
TICs. Si se cambia el flujo de una aplicación o de
cómo ésta es utilizada, se debe involucrar al
personal del negocio para identificar los impactos.
 Tomar en cuenta los servicios, procesos y
aplicaciones que tienen algún impacto, cuando se
considere qué tipo de comunicaciones se
requiere.
Identificar el impacto al Preguntas clave:
negocio y la evaluación del  ¿Cómo se va a beneficiar la Organización del
Riesgo Cambio? Si el Cambio no se lleva a cabo, ¿Hay
algún Riesgo potencial para la Organización?
 ¿Cómo se explicará y cuantificará la justificación
de negocio o el impacto? Por ejemplo, si los
cambios son solicitados para incrementar la
demanda de un servicio en particular, la demanda
puede ser expresada en términos de capacidad de
datos o por la proximidad de un evento del
negocio.
 ¿Cuales son los Riesgos asociados con el
Cambio?
Entradas:
 Solicitud de Cambio (RFC)
 Identificación del servicio de TIC, y del grupo de
negocio que será impactado por el Cambio
Salida:
 Razón de negocio bien fundamentada en un
documento, donde se incluye el impacto y el
Riesgo de la Solicitud de Cambio (RFC)
Mejor práctica:
 Para más información acerca de la evaluación de
Riesgo, ver el SMF de Función de
Gobernabilidad, Riesgo y Cumplimiento para la
Administración del Servicio.

Proceso 3: Clasificación del Cambio

El siguiente proceso es para clasificar el Cambio solicitado.
Figura 5. Clasificación del Cambio
Actividades: Clasificación del Cambio

Después que se inició la RFC, el siguiente proceso es clasificar la solicitud.
La siguiente tabla enlista las actividades involucradas en la clasificación del Cambio,
éstas incluyen:
 Identificar la prioridad del Cambio.
 Identificar la categorización del Cambio.
 Revisar y validar la configuración, evaluar el Riesgo, y actualizar la RFC.
Tabla 6. Actividades y consideraciones para clasificar el Cambio

Identificar la prioridad del Preguntas clave:
Cambio  ¿Es éste un Cambio de una prioridad baja, media,
alta o se trata de una emergencia?
Los niveles de priorización deben ser diseñados
considerando tiempos específicos para llevar a cabo
el Cambio, y estos niveles también deben soportar
requerimientos del negocio. Unos niveles de
priorización típicos pueden ser:
 Bajo. El Cambio puede esperar, hasta la
siguiente versión programada.
 Medio. Debido al nivel de impacto del Cambio,
éste no puede esperar hasta la siguiente versión
programada.
 Alto. El Cambio debe efectuarse tan pronto como
Chapter Title 19
pueda llevarse a cabo y haya sido probado.
 Emergencia. El Cambio requiere efectuarse tan
pronto como sea posible; muchos de los pasos
para su aprobación y su desarrollo se agilizan.
Mejores prácticas:
 El Administrador del Cambio y el Iniciador de la RFC,
necesitan negociar la prioridad, si es que no están de
acuerdo en su categorización. Definir un proceso de
escalación.
 Si hay demasiados Cambios tanto de Alta prioridad
como de Emergencia, revisar las causas del por qué.
Esto puede indicar que los miembros de la
Organización están tratando de evitar el proceso o
que el proceso no es efectivo.
Identificar la categoría del Preguntas clave:
Cambio  ¿A qué categoría pertenece el Cambio?
Las categorías toman en cuenta los requerimientos
de recursos para llevar a cabo el Cambio, el impacto
en el negocio al hacer o no el Cambio, la experiencia
de la Organización con el Cambio, y si el Cambio
incluye el uso de nuevas tecnologías ó procesos.
Típicamente las categorías incluyen:
 Cambio Estándar. Esta es una categoría de bajo
Riesgo, porque ya se tiene un método que ha
probado ser exitoso, tiene un impacto mínimo
hacia el negocio y se tienen un conjunto de
procedimientos bien probados.
 Cambio Menor. Esta categoría afecta a un
número pequeño de usuarios y recursos.
También el Riesgo de una caída del ambiente
productivo es poco, porque la Organización ya
tiene experiencia en la implementación de éste
tipo de Cambio.
 Cambio Significativo. Esta categoría tiene un
efecto moderado en los usuarios, recursos y en
el negocio. Puede incluir una caída de los
servicios y se puede dar el caso de que la
Organización tenga menos experiencia con el
producto, infraestructura o con los usuarios
involucrados en el Cambio.
 Cambio Mayor. Con un mayor Riesgo y con un
mayor costo, esta categoría conlleva un gran
potencial de impactar a los usuarios y a los
recursos. También puede afectar los sistemas
críticos del negocio y frecuentemente se incluye
una caída de los servicios durante su
implementación.
 Cambio de Emergencia. Esta categoría es de
alto Riesgo porque se tiene una urgencia para la
implementación con un tiempo reducido para
llevar a cabo pruebas. Hay cierta incertidumbre
de que el Cambio sea exitoso y hay un gran
impacto al negocio si el Cambio falla. Este tipo de
Cambio es frecuentemente resultado de un
incidente urgente. Estos cambios son escalados
al Comité de Emergencia del Consejo Consultor
del Cambio (CAB/EC), para su aprobación en
fast-track. (Para más información del CAB, ver
Proceso 4: “Aprobación del Cambio.”)
 Cambio No Autorizado. Esta categoría de
Cambio, involucra a aquellos Cambios que se
han llevado a cabo fuera de las políticas de
administración del Cambio o que
específicamente son Cambios prohibidos.
Mejores prácticas:
 Un uso efectivo de los Cambios Estándar, es
importante para mantener el proceso administrable y
fácil de utilizar. Los Cambios Menores, deben ser
evaluados mediante un proceso por el CAB para su
posible recategorización como futuros Cambios
Estándar
 Ser lo mas específico posible, al definir qué es y qué
no es un tipo de Cambio.
Actualización de la RFC Entrada:
 Revisar y validar la Configuración
 Evaluar el Riesgo
 Actualizaciones del Cambio
Salida:
 Documento de la RFC actualizado

Chapter Title 21
Proceso 4: Aprobar y programar el

Cambio
El siguiente es el proceso para Aprobar y programar el cambio.
Figura 6. Aprobar y programar el cambio
Actividades: Aprobar y programar el Cambio

La aprobación de un cambio está ligado a la categoría del mismo. La aprobación de un
cambio Significativo o Mayor, por lo general comienza con la presentación del Cambio
propuesto al organismo de aprobación adecuado, por ejemplo, un equipo de revisores
típicamente conocido como el Consejo de Consultores de Cambio (CAB). Este es un
grupo de personas clave, que representan las diversas perspectivas del negocio y que
tienen la responsabilidad de los resultados del cambio. Las consideraciones a tomar en
cuenta para establecer el CAB se discuten en el SMF de Función de Gobernabilidad,
Riesgo y Cumplimiento para la Administración del Servicio. Los Cambios de Emergencia,
normalmente se revisan por el Comité de Emergencia del Consejo Consultor del
Cambio (CAB/EC) para una aprobación fast-track.

Es responsabilidad del CAB, el determinar si el cambio debe:

 Ser aprobado y programado.
 Ser rechazado y terminado.
 Regresar a los procesos anteriores a éste, para aclaraciones y nuevas
consideraciones.
Entender el impacto potencial del Cambio, es fundamental, cuando se deben tomar
decisiones. Las entradas del proceso de aprobación incluyen:
 Tolerancia al Riesgo previamente determinada (Esto se explica en el SMF de
Función de Gobernabilidad, Riesgo y Cumplimiento para la Administración del
Servicio y en el SMF de Función de Políticas para la Administración del Servicio)
 La categoría del Cambio –Estándar, Menor, Significativo, Mayor o de Emergencia lo
que resume la complejidad y los recursos requeridos, incluyendo recursos humanos,
dinero y tiempo.
 El impacto potencial del Cambio en la configuración de la Organización y en los
usuarios, incluyendo los tiempos en que se pierdan los servicios.
Esta información ayuda a identificar y seleccionar a los revisores adecuados, con los
suficientes conocimientos y autoridad para la toma de decisiones.
Los Cambios Estándar requieren de poco esfuerzo para implementarse, tienen un bajo
nivel de Riesgo y una aprobación predefinida. Si un Cambio ha sido clasificado como
Estándar, pasa por un proceso muy rápido de aprobación, documentación y liberación.
Los Cambios Menores pueden ser aprobados por el Administrador de Cambio. Todas
las demás categorías requieren aprobación del CAB.
Los métodos para lograr una decisión ya sea de aprobación o rechazo, deben estar
determinados antes de que el CAB revise los Cambios propuestos. Dependiendo del
modelo de Gobernabilidad seleccionado por la Organización, la votación es utilizada
frecuentemente para lograr una decisión que mueva el Cambio a los siguientes procesos
o bien que lo detenga de una vez.
Una vez que el CAB toma una decisión, es importante que su conclusión sea
documentada en la RFC, de tal manera que el conocimiento obtenido durante el proceso
de administración del Cambio quede registrado. Esto permite una auditoría mas eficiente
del proceso de Administración del Cambio y al mismo tiempo se genera información que
puede utilizarse en iteraciones adicionales a lo largo del proceso de Administración del
Cambio.
La siguiente tabla enlista las actividades involucradas en la Aprobación del Cambio.
Éstas incluyen:
 Enviar la solicitud de Cambio al organismo de aprobación adecuado.
 Procesar los Cambios Estándar hasta la liberación.
 Analizar el impacto del Cambio e identificar a los revisores.
 Aprobar o rechazar el Cambio o buscar información adicional.

Chapter Title 23
Tabla 7. Actividades y Consideraciones para la Aprobación del Cambio

Enviar la solicitud de Preguntas clave:
Cambio al organismo  De acuerdo al proceso de Gobernabilidad de TICs,
de aprobación Basados en su clasificación ¿qué organismo de aprobación
adecuado tiene la autoridad para aprobar el Cambio?
Entrada:
 Estructura de Gobernabilidad (comités de dirección, foros)
(ver el SMF de Función de Gobernabilidad, Riesgo y
Cumplimiento para la Administración del Servicio para más
información)
Salidas:
 Documento de la RFC, integrado a la agenda del CAB, o
entregado al Administrador de Cambio
 Cambios Estándar o Menores entregados al Administrador
de Cambio
Mejores prácticas:
 Los Órganos de aprobación deben de tener algunos
miembros que participen en la aprobación de Cambios de
manera continua. Estos miembros deben tener experiencia
y una visión amplia, para considerar las implicaciones de
hacer Cambios.
 Además de los miembros permanentes con experiencia, se
debe de incluir personal y expertos de otras áreas de la
Organización, que serán afectados por el Cambio o que
puedan agregar valor a la discusión del Cambio propuesto.
Estos miembros adicionales se escogen caso por caso.
 Cuidado con el tipo de decisiones “esto es obvio,
hagámoslo”. Buscar todas las entradas posibles,
involucrando una variedad de áreas en el Órgano de
aprobación, de tal manera que haya más rigor para
identificar todos los pros y contras.

Procesar los Preguntas clave:
Cambios Estándar  ¿Este Cambio, ha sido clasificado como un Cambio
hasta la liberación Estándar?
 ¿Las actividades para llevar a cabo el Cambio son bien
conocidas y han sido probadas?
 Cuando este Cambio Estándar se ha llevado a cabo
¿siempre se han logrado los resultados esperados?
 ¿Este Cambio se puede llevar a cabo en la siguiente
ventana de tiempo disponible para hacer Cambios?
Entradas:
 El documento de la RFC bajo consideración
 Catálogo de Cambios Estándar aprobados
Salidas:
 Los Cambios identificados como Estándar, proceden
directamente a desarrollo (si se requiere) o a liberación
 Documentación del Cambio estándar una vez que ha
pasado por la Aprobación (ver Proceso 6: “Liberación del
Cambio” para más información)
Mejores prácticas:
 Realizado, probado y comprobado (”Tried, Tested, and
True”). Estas son las características de los Cambios
Estándar. Algunos Cambios no comienzan siendo de tipo
Estándar, pero conforme ese Cambio en particular se
repite, se va acumulando un conocimiento que queda
documentado y de esa forma se convierte en un Cambio
Estándar. Para este tipo de Cambios hay una certeza de
que se lograrán los resultados esperados, sin excepciones.
 En virtud de que los Cambios con categoría de Estándar y
que han sido preaprobados, tienen un bajo impacto en el
ambiente de producción y son de bajo Riesgo, no necesitan
ser revisados de nueva cuenta por el CAB e incluso ni por
el Administrador de Cambio. De todas maneras se debe
tener cuidado de que la solicitud de Cambio que se ha
categorizado como Estándar, efectivamente lo sea y de que
el tipo de Cambio concuerde con la ventana de tiempo
disponible para llevarlo a cabo.
 Documentar la aprobación del Cambio Estándar,
incluyendo la fecha de cuando fue aprobado y los
resultados que se buscaba obtener con el Cambio
propuesto.

Chapter Title 25
Analizar el impacto Preguntas clave:
del Cambio e  ¿Quien es el que mejor puede llevar a cabo el Cambio,
identificar a los evaluarlo y analizar su impacto?
Revisores  ¿El análisis del impacto, comprueba la clasificación que se
le dio al Cambio?
 ¿El Cambio propuesto afectará las políticas,
procedimientos, ó cualquier aspecto del cumplimiento con
las regulaciones?
 ¿El caso de negocio, ha cambiado desde que se inició el
proceso del Cambio?
 ¿Quién en la Organización será más afectado por el
Cambio, tanto en el caso de su éxito como de su fracaso?
 ¿Quién tiene el mejor conocimiento de TIC para este
Cambio?
 ¿Quién entenderá mejor las implicaciones para el negocio,
en caso de no llevarse a cabo el Cambio?
 ¿Quién entiende mejor las implicaciones de seguridad y
privacidad, para este Cambio?
 ¿Quién puede enfrentar los temas de política y
cumplimiento, que puedan llegarse a presentar, durante el
proceso del Cambio?
Entradas:
 El documento de RFC y cualquier RFC bajo consideración
 Cualquier información adicional que se requiera en el
proceso de revisión, acerca de las áreas que sufrirán algún
impacto
Salidas:
 Miembros permanentes de los Órganos de revisión del
Cambio
 Expertos invitados y representantes de los usuarios
afectados
Mejores prácticas:
 Que el Análisis de impacto sea integral, que incluya verificar todas
las solicitudes de Cambios que afectan a un Servicio, para que
los impactos se evalúen de una forma fácil de comprender. Los
procedimientos de evaluación, incluyen los procesos para evaluar
los costos de los cambios, y un medio para verificar que el
beneficio al negocio excede al costo (o que el cambio es
obligatorio).
 Revisar el caso de negocio y el análisis de impacto del cambio
para ayudar a asegurar que el cambio y el caso de negocios aún
hacen sentido. Utilizar el análisis de impacto para determinar las
áreas de la Organización que deben participar en la revisión del
Cambio, e identificar los expertos potenciales o representantes de
los usuarios que deben participar en la revisión.
 Registrar la forma como fueron identificados los Revisores, así
como el hecho de que aceptaran participar en la revisión.
Demostrar que el impacto del cambio fue considerado desde una
perspectiva amplia, gracias a una buena identificación de los
Revisores, de tal manera que se realice el mejor de los esfuerzos,
para tomar la decisión de aprobar el Cambio.

Aprobar, rechazar el Preguntas Clave:
cambio o buscar  ¿Todos los miembros del grupo de Revisión, están
información adicional preparados para tomar la decisión?
 ¿Hay un método predeterminado para, resolver los puntos
muertos al momento de aprobar las decisiones o para
desempatar las votaciones?
 ¿Realmente se requiere hacer el cambio?
 ¿Es el momento adecuado para realizar el Cambio o hay
una mejor ventana de tiempo para hacerlo?
Entradas:
 El documento de Solictud de Cambio (RFC) junto con la
Bitácora de Cambio y cualquier otra información que los
acompañe, proveniente del proceso de Análisis
Salidas:
 La Solicitud de Cambio (RFC), es aprobada y se programa
su ejecución o se rechaza y se regresa a quien la originó
 Conocer cualquier eventualidad, que se pueda presentar
en la implementación
 Documentación del proceso de aprobación
Mejores Prácticas:
 Implementar todas las solicitudes aprobadas en forma
oportuna. Mantener el caso de negocio y el análisis de
impacto, cercanos al momento de la aprobación de un
Cambio, para asegurar que éste es todavía pertinente y
que es correcto llevarlo a cabo.
 Conservar las minutas, de las reuniones de aprobación del
Cambio, como parte de la documentación del proceso y
evidencia de los participantes.
 Las eventualidades identificadas, deben de simplificarse
para atenderse lo más fácil posible, para minimizar los
malos juicios o malas interpretaciones acerca de la
Solicitud de Cambio (RFC).

Chapter Title 27
Actualizar la Solicitud Preguntas Clave:
de Cambio (RFC)  ¿Se tiene toda Ia información, para completar los
requerimientos de documentación para la RFC?
 ¿Quién actualizará la RFC?
 ¿Quién necesita saber los resultados de la revisión del
Consejo Consultor del Cambio (CAB)?
Entradas:
 La RFC y la Bitácora de Cambios
Salidas:
 RFC y Bitácora de Cambios actualizadas
 Comunicado a los grupos interesados
Mejores Prácticas:
 Completar la documentación a tiempo, para la RFC, reduce
la confusión y ambigüedad acerca del estado del Cambio.
 Completar la documentación a tiempo, también ayuda a la
Gestión del Cambio, a la mitigación de Riesgos de llevar el
Cambio al ambiente productivo, y a una métrica precisa
que indica la madurez del proceso de Cambio (por ejemplo,
el número de Cambios autorizados por semana, el número
de Cambios a los que se niega la aprobación y el número
de Cambios estándar aprobados automáticamente cada
semana).
 Cuando un Cambio es aprobado y programado, se debe
actualizar el Sistema de Administración de la Configuración
(CMS) con el estado futuro y la fecha del cambio de
configuración. Esto será utilizado en la evaluación de otros
Cambios propuestos.

Proceso 5: Desarrollar y Probar el

Cambio
Una vez que se ha aprobado un Cambio, entonces se puede iniciar con el Desarrollo y la
prueba del Cambio. Estas son actividades que coinciden con la Fase de Entrega del
ciclo de vida de los Servicios de TICs. Y están encaminadas a asegurar que los
Servicios de TICs son conceptualizados, planeados, creados, estabilizados y liberados
en línea con los requerimientos de la Organización y de acuerdo a las especificaciones
de los clientes.
Figura 7. Desarrollar y Probar el Cambio

Chapter Title 29
Actividades: Desarrollar y Probar el Cambio

Desarrollar y Probar el Cambio, son actividades que están ligadas a la Fase de Entrega
del ciclo de vida del Servicio de TICs. Más información acerca del Desarrollo y Prueba
del Cambio se encuentra en el documento Visión General de la Fase de Entrega.
Información aún más detallada se pude encontrar en los SMFs de la Fase de Entrega
que se enlistan a continuación:
 Función de Conceptualización para la Administración del Servicio

 Función de Planeaciónde Proyectos para la Administración del Servicio
 Función de Realización para la Administración del Servicio
 Función de Estabilización para la Administración del Servicio
 Función de Implementación para la Administración del Servicio
Los Cambios con bajo Riesgo y Mínimo Esfuerzo pasan por éste y el siguiente proceso
de forma rápida. Los Cambios de mayor complejidad, deben de seguir el proceso
señalado en los SMFs de la Fase de Entrega. Los grupos de procesos tienen el mismo
patrón. Hay que seguir los lineamientos que se enlistan a continuación, para cada
categoría de Cambio:
 Cambio Estándar: Siga los procedimientos establecidos para los cambios Estándar.
 Cambio Menor: Siga el proceso para Cambios Menores, que se describe en este
documento. Si se requiere más detalle, por favor vea el SMF de Entrega.
 Cambio Mayor o Significativo: Vea el SMF de la Fase de Entrega.
 Cambio de Emergencia: Haga lo necesario para levantar un Servicio esencial. Las
Pruebas pueden retrasarse, hasta después de la liberación del Cambio. Asegúrese
de realizar las Pruebas, para confirmar que no hay problemas desconocidos,
causados por el Cambio. Tenga cuidado, cuando se trata con Cambios de
Emergencia, ya que los niveles de Riesgo son generalmente más altos.
La Tabla siguiente, enlista las actividades que conforman este procedimiento:
 Diseño del Cambio.
 Identificar las dependencias en las configuraciones.
 Desarrollar y Probar el Cambio.
 Revisar que el Cambio está listo para su Liberación

Tabla 8. Actividades y Consideraciones para el Desarrollo y Prueba del Cambio

Diseño del Cambio Preguntas Clave:
 ¿El diseño muestra un entendimiento de los
requerimientos de la Organización, y define las
características que los usuarios necesitan para hacer su
trabajo?
 ¿Se han desarrollado escenarios, para utilizar el Cambio
de forma adecuada?
 ¿El diseño cubre los requerimientos de la Operación?
 ¿El diseño cubre los requerimientos del Sistema?
Entradas:
 Los requerimientos de la Organización y de los usuarios
para la solución
 Escenarios de uso
 Los requerimientos de la Operación y del Sistema
Salidas:
 Documento del Diseño
Mejores Prácticas:
 Mantener la trazabilidad entre los requerimientos y las
características de la solución. Esto sirve para checar que
el diseño sea el correcto y para asegurar que el propio
diseño cubre los objetivos y requerimientos de la
solución.
Identificar las Preguntas Clave:
dependencias de la  ¿Hay otros Elementos de Configuración (Cis), que
configuración tengan dependencias con o que se puedan ver afectados
con el Cambio propuesto?
 ¿El Cambio propuesto tiene dependencias con otros
Cambios, es decir, que si para poder terminar con el
Cambio propuesto, es necesario hacer otros Cambios
primero?
 ¿Todos los Cambios (nos referimos a los que son
prerrequisito y al que nos ocupa en ese momento) están
registrados en la CMS?
Entradas:
 Información de los demás Cambios propuestos, en la
CMS
Salidas:
 Un registro en el CMS, que muestre todos los Elementos
de configuración (CIs) y sus dependencias que se
pueden ver afectadas ó que tienen algún efecto en el
Cambio Propuesto
Mejores Prácticas:
 El CMS se debe actualizar cada vez que se aprueba una
RFC. Esto ayuda a saber que se ha planeado un
Cambio para un Elemento de Configuración o para un
grupo de estos elementos. También se debe de
actualizar el CMS, cuando el Cambio se ha completado
de forma exitosa.

Chapter Title 31
Desarrollar y Probar el Preguntas Clave:
Cambio  ¿El Cambio a desarrollar, cumple con las
especificaciones del cliente?
 ¿El Equipo de Desarrollo, ha preparado un laboratorio
para el Desarrollo?
 ¿El Equipo de Desarrollo, tiene preparado un proceso
para el seguimiento de los problemas por atender?
¿Cómo se van a pasar los problemas resueltos al Equipo
de Operación para su uso en la base de datos de
conocimiento?
 ¿Han trabajado juntos, los Equipos de Desarrollo y el
Equipo de Pruebas, para preparar una especificación de
las Pruebas?
 ¿El Equipo de Desarrollo tiene varias versiones para
Liberación y las ha Probado todas, para verificar si
alguna, es apta para liberarse al Grupo que llevará a
cabo el Piloto?
 ¿El Equipo, completó una Prueba de Aceptación por
parte del usuario?
 ¿El Equipo ha llevado a cabo un Piloto y ha reunido la
Retroalimentación?
Entradas:
 Documento de concepto y alcance
 Especificación Funcional
 Requerimientos del Cliente
 Código
 Documento de especificación de las Pruebas
 Plan para las Pruebas
 El ambiente del laboratorio
 Base de datos, polticas y procedimientos para el
seguimiento de problemas.
Salidas:
 Versiones candidatas para Liberación
 Versiones candidatas para Liberación , listas para llevar a
cabo un Piloto
Mejores Prácticas:
 Solucionar los problemas conocidos, ya sea que efectivamente
se solucionen o bien que se difiera la solución.
 Definir estándares de priorización y severidad de los problemas
y comunicarlos a todos los miembros de los Equipos de
Desarrollo, Pruebas y Experiencia de los Usuarios.
 Entregar la base de datos de problemas a los grupos de
capacitación y soporte, de tal manera que sus miembros tengan
un conocimiento completo de la historia de la solución y los
problemas que se presentaron durante su desarrollo.
 Programar reuniones periódicas con los responsables del
Desarrollo y de las Pruebas, para revisar los problemas y
planear las estrategias para resolverlos.

Revisar que el Cambio Preguntas Clave:
está listo para su  ¿Hay alineación con el negocio y se entienden las
Liberación prioridades?
 ¿Hay un dueño de cada una de las actividades y
acciones, a ejecutar?
 ¿Se han firmado todos lo planes, por parte del nivel
Administrativo adecuado?
 ¿Se ha llevado a cabo una comunicación efectiva, entre
todos los grupos involucrados?
 ¿Tanto los usuarios como los dueños, de los servicios
que guardan alguna dependencia con el Cambio saben
que el Cambio está programado y cuál es el impacto que
tendrá sobre ellos?
 ¿Hay usuarios de la Organización, que se encuentran
listos para recibir el Cambio y comprometidos con los
nuevos procesos?
 ¿Se terminaron las Pruebas?
 ¿Están listos los Equipos de Operación y Soporte, para la
Liberación?
Entradas:
 Reportes de estado para el Administrador de Liberación
Salidas:
 Una decisión de seguir o no seguir con la Liberación
Mejores Prácticas:
 Asegurar que el Administrador de Liberación, cuenta con
los Reportes de estado adecuados.
 Proporcionar retroalimentación y reconocimiento a
aquellos que han ayudado a la liberación y recordar a la
Organización cuáles son los beneficios esperados.
Actualizar la RFC Preguntas Clave:
 ¿Se han llevado a cabo actualizaciones que reflejen
cosas como la fecha planeada para la Liberación, planes
para sacar el servicio de operación y las razones por las
que es necesario sacar el servicio de operación (si se
requieren), los requerimientos de soporte, plan de
restablecimiento (a las condiciones anteriores al cambio),
resultados de las Pruebas, los problemas que se han
presentado y la fecha de la Revisión posterior a la
implementación (PIR por sus siglas en inglés)? (Para
más información acerca de la PIR, vea el proceso 7:
¨Validación y Revisión del cambio¨)
 ¿Se han llevado a cabo actualizaciones del estado, y
monitoreo, a lo largo de todo el proceso?
 ¿El iniciador del Cambio, ha podido ver la RFC, a lo largo
de todo el proceso para saber el estado?
 ¿Ha habido un comunicado oficial, en el momento de la
Liberación, con el Iniciador del Cambio?
Entradas:
 Actualizaciones acerca del Cambio

Chapter Title 33
Salidas:
 RFC actualizada
Mejores Prácticas:
 El Administrador del Cambio, debe monitorear los
Cambios que están pendientes de Liberarse, para
asegurar que la información se actualiza. Un Acuerdo
de Nivel de Operación (OLA), puede ayudar establecer
una expectativa para que esto se haga.

Proceso 6: Liberar el Cambio

Una vez que el Cambio se ha Desarrollado, Probado y Revisado para que esté Listo
para su Liberación, es hora de Liberar el Cambio.
Figura 8. Liberar el Cambio

Chapter Title 35
Actividades: Liberar el Cambio

La Revisión Gerencial de Preparado para Liberación, marca el final de las Pruebas de un
Cambio. En este punto, da comienzo el proceso para Liberar el Cambio. Liberar el
Cambio coincide con el SMF de Implementación en la Fase de entrega del ciclo de vida
del Servicio de TICs.
La Tabla siguiente, enlista las actividades involucradas en este proceso, las que
incluyen:
 Liberar el Cambio, y cualquier otro componente requerido, al ambiente de
producción.
 Estabilizar la versión liberada.
 Obtener la aprobación final del Cambio, por parte del cliente.
 Documentar el Cambio Liberado y comunicar el impacto a los usuarios.
 Transferir la responsabilidad, del Equipo de Proyecto que desarrolló el Cambio a los
Equipos de Operación y Soporte.
 Actualizar la RFC y la base de datos de Configuración.
Tabla 9. Actividades y Consideraciones para Liberar el Cambio
Liberar el Cambio Preguntas Clave:
 ¿El Cambio es lo suficientemente estable para Liberarlo?
 ¿Está listo el Equipo para Liberar el Cambio al ambiente
de producción?
Entradas:
 Liberar el Cambio, incluyendo:
 Entregables de la solución.
 Documentación de la solución.
 Plan de Liberación
Salidas:
 Cambio Liberado
Mejores Prácticas:
 Tomar decisiones, acerca de la estrategia de Liberación,
en las primeras etapas del proyecto, posiblemente en la
etapa de conceptualización o en la de planeación del
proyecto, lo anterior para buscar minimizar el Riesgo.

Estabilizar la versión Preguntas Clave:
Liberada  ¿El Equipo tiene un plan para monitorear la solución
durante el “periodo de calma”? Este “periodo de calma”,
se refiere al tiempo en que el Equipo de proyecto, ya no
está activo, pero responde a los issues que les escalan
los Equipos de Operación y Soporte. Típicamente estos
“periodos de calma” duran de 15 a 30 días.
 ¿El Cambio Liberado es estable?
 ¿Todos los issues, que se encontraron durante las
Pruebas y como resultado de la retroalimentación del
Piloto, están resueltos?
 ¿Se Probó la aceptación por parte del usuario?
Entradas:
 Documento de especificación de las Pruebas
 Plan Maestro, que incluye el Plan de Pruebas
 Escenarios de Prueba y casos de Prueba
 Ambiente de Laboratorio
 Desarrollos provisionales, que incluyen:
 Entregables de la Solución.
 Documentación.
 Base de datos de seguimiento de problemas.
 Políticas y procedimientos para el seguimiento de
problemas
Salidas:
 Versión candidata para Liberación
 Versión candidata Lista para el Piloto
Mejores Prácticas:
 Utilizar un sistema formal para seguimiento de issues y
un reporte del estado de las fallas (bugs).
 Documentar el seguimiento de issues y los
procedimientos de reportes, durante la Planeación.
 Definir y acordar los criterios, para considerar que las
Pruebas de la versión candidata, se consideran exitosas.
 No se debe Liberar la versión candidata, hasta que todo
el Equipo haya firmado, que esta versión se puede
utilizar.
 No comenzar el Piloto, hasta que el Equipo de Proyecto,
los clientes y los usuarios hayan acordado en un criterio
para considerar que el resultado es exitoso.
Obtener la aprobación Preguntas Clave:
final del Cambio, por  ¿El cliente está satisfecho con el Cambio?
parte del cliente
 ¿El cliente acepta el Cambio que ha sido Liberado?
Entradas:
 Cambio Liberado
Salidas:
 Firma de aprobación de la Liberación

Chapter Title 37
Documentar el Cambio Preguntas Clave:
Liberado y comunicar  ¿Todos los Cambios realizados, a los componentes de
el impacto a los TICs, durante la Liberación, han sido comunicados y
usuarios documentados en la Bitácora de Cambio?
 ¿El Equipo ha registrado en la Bitácora de Cambio,
cualquier solución temporal o solicitud de Cambio (RFC)
levantada como consecuencia de la Liberación?
Entradas:
 Información acerca del Cambio
 Mapa del Servicio
Salidas:
 Bitácora de Cambio actualizada
 Una solución estable, Liberada en el ambiente de
producción
 Un cliente que está satisfecho y que acepta la solución
Liberada
 Una solución transferida con éxito del Equipo de
Proyecto a los Equipos de Operación y Soporte
Mejores Prácticas:
 Comunicar el Cambio, de forma clara, a todas las partes
interesadas.
Transferir la Preguntas Clave:
responsabilidad, del  ¿La solución de Cambio, se ha transferido exitosamente,
Equipo de Proyecto del Equipo de Proyecto a los Equipos de Operación y
que desarrolló el Soporte?
Cambio a los Equipos
 ¿Se ha llevado a cabo la capacitación, de tal manera que
de Operación y Soporte
el personal de Operación y Soporte está preparado para
administrar y soportar la solución de Servicio?
Entradas:
 Cambio Liberado
Salidas:
 Una solución de Servicio, administrada y soportada
Actualizar la RFC y la Preguntas Clave:
base de datos de  ¿La RFC se ha estado actualizando, para reflejar
Configuración cualquier cambio hecho a la solicitud original?
 ¿Los cambios hechos a los componentes de TICs, se
han registrado en el CMS?
 ¿Las soluciones temporales o solicitudes de cambio,
levantadas para llevar a cabo la Liberación, se han
registrado en el CMS?
Entradas:
 Cambios hechos a la solicitud original
 Información acerca de los Elementos de Configuración
(Cis)
Salidas:
 RFC actualizada
 CMS actualizado
Mejores Prácticas:
 Cuando un Cambio se lleva a producción, se debe
actualizar el estado actual en el CMS, de tal manera que
se tenga una foto precisa, disponible para el análisis de
problemas y para otras RFCs.

Chapter Title 39
Proceso 7: Validar y Revisar el Cambio

El proceso final es, validar que el Cambio se Liberó correctamente y revisar la
efectividad del Cambio.
Figura 9. Validar y Revisar el Cambio

Actividades: Validar y Revisar el Cambio

Después de que el Equipo ha Liberado exitosamente el Cambio al ambiente de
producción, el siguiente proceso es Validar la Liberación y Revisarla. La meta de la
Validación es verificar que el Cambio se Liberó como se esperaba. La meta de la
Revisión del Cambio –que normalmente recibe el nombre de Revisión Post
Implementación (PIR por sus siglas en inglés)- es determinar si el Cambio ha tenido el
efecto deseado y ha cumplido con los requerimientos de la RFC original.
Determinar, si el Cambio Liberado ha sido efectivo y ha logrado los resultados deseados,
requiere monitorear el Cambio en el ambiente de producción. Para un Cambio pequeño,
esto puede ser cuestión de revisar la funcionalidad deseada. Para Cambios más
grandes, se puede requerir monitoreo de la red y de los servidores, datos sobre el
rendimiento, bitácoras de eventos y tiempos de respuesta.
Después de que la Liberación del Cambio ha sido validada, se puede llevar cabo la PIR.
Los resultados de la PIR deben incluir lo siguiente:
 Una decisión de éxito o fracaso, con respecto a la implementación del Cambio.
 Una revisión de la forma en que se Liberó el Cambio y de si ésto se hizo en tiempo y
con lo presupuestado.
 Documentación de toda lección aprendida, con respecto al proceso del Cambio.
La siguiente Tabla enlista las actividades, involucradas en la Validación y Revisión del
Cambio. Estas incluyen:
 Validar el éxito o el fracaso técnico del Cambio.
 Validar el éxito o el fracaso, con respecto a la Organización, del Cambio.
 Auditar la base de datos de Configuración.
 Comunicar y registrar el Cambio.
 Actualizar y cerrar la Solicitud de Cambio (RFC).
Tabla 10. Actividades y Consideraciones para Validar y Revisar el Cambio

Validar el éxito o el Preguntas Clave:
fracaso técnico del  ¿El Cambió cumplió con los requerimientos técnicos?, Esto
Cambio pude ser verificado de diferentes formas, dependiendo del tipo
de Cambio. Por ejemplo:
 Pruebas con el Usuario
 Pruebas de personas de TICs
 Herramientas de monitoreo
 ¿Todas las implementaciones, en los sitios donde se desplegó
el Cambio, están terminadas y estabilizadas?
 ¿Todos los miembros del Equipo, ya están fuera del Proyecto?
 ¿Durante todo el “periodo de calma” no se tuvieron incidentes
o se documentaron muchos incidentes?
Entradas:
 Datos acerca del éxito técnico del Cambio
Salidas:
 Reporte de Revisión Gerencial
Mejores Prácticas:
 Los incidentes relacionados con el Cambio, son indicadores
reactivos del éxito del Cambio.

Chapter Title 41
 Para los cambios en las PCs de los usuarios, una llamada
telefónica o una rápida visita después de que se hizo el
Cambio, son verificaciones proactivas.
Validar el éxito/ó el Preguntas Clave:
fracaso, con  ¿El Cambio cumple con los requerimientos y objetivos de la
respecto a la Organización?
Organización, del
 ¿Los clientes y los usuarios, están satisfechos con la solución
Cambio.
y su Liberación?
 ¿Los clientes y los usuarios están felices con los resultados?
 ¿Ha habido efectos secundarios, inesperados?
Entradas:
 Retroalimentación, con respecto a los aspectos técnicos del
Cambio
 Retroalimentación, con respecto a los requerimientos de la
Organización, del Cambio
Salidas:
 Validación del Cambio
Auditar la base de Preguntas Clave:
datos de  ¿Qué tan exactos son los datos, del Cambio, almacenados en
Configuración el CMS?
 ¿Quién actualiza el CMS y qué pasa si los datos son
incorrectos?
Entradas:
 Información acerca de los Elementos de Configuración Cis,
que sufrieron algún Cambio
Salidas:
 Información exacta y actualizada en el CMS

Comunicar y Preguntas Clave:
registrar el  El Equipo documentó, en una base de datos con capacidades
Cambio de búsquedas, los resultados del Cambio incluyendo el tipo de
Servicio, el día en que se concluyó, el tipo de tecnología
empleada?
 ¿El equipo ha proporcionado retroalimentación (incluyendo
issues y un resumen de la Revisión de Post-Implementación
(PIR) acerca del cambio, a los interesados adecuados? Por
ejemplo:
 Miembros del CAB
 Clientes y usuarios que fueron afectados
 Los Equipos de Administración del Cambio y Liberación
del Cambio
 La Administración de TICs
 El equipo de TICs
Entradas:
 Información acerca del Cambio
Salidas:
 Comunicado acerca del Cambio, registros del Cambio. Esta
información sirve para el Reporte Gerencial del Estado de
Operación (OHMR)
Actualizar y cerrar Preguntas Clave:
la Solicitud de  ¿La RFC, se actualizó, para incluir la retroalimentación del
Cambio (RFC) PIR?
 ¿La RFC refleja con exactitud, el Cambio que se llevó a cabo?
 ¿Se documentaron los resultados del PIR?
Entradas:
 Información actualizada acerca del Cambio
Salidas:
 RFC cerrada
Conclusión
El SMF de Cambio y Configuración, describe los procesos, para comprender y para
poder ganar control de los Cambios que se hacen en TICs. Los datos de los Elementos
de Configuración (CIs) y las RFCs, se colectan y se utilizan en este proceso. Las
solicitudes de Cambio se revisan, se aprueban y se implementan.
Los procesos principales descritos en este SMF son:
 Documentar la configuración base actual
 Iniciar el Cambio
 Clasificar el Cambio
 Aprobar y programar el cambio
 Desarrollar y probar el Cambio
 Liberar (implementar) el Cambio
 Validar y Revisar el Cambio

Chapter Title 43
Retroalimentación
Por favor dirija sus preguntas y comentarios acerca de ésta guía a mof@microsoft.com.

5.2 Change and Configuration SMF - Esp

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

5.2 Change and Configuration SMF - Esp

Uploaded by

Copyright:

Available Formats

Microsoft® Operations Framework

Función de Cambio y Configuración para la

Publicado: Abril 2008

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Visión General de la Función de Cambio

La administración del cambio es muy importante. Para entregar un servicio de TIC de

El cambio en cualquiera de sus formas conlleva un Riesgo (Riesgo de falla, resistencia

La administración del cambio y la configuración ofrece una guía basada en mejores

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Planeación, de Entrega y de Operación, cada vez que el impacto y los Riesgos al

Los cambios se pueden clasificar en las siguientes categorías:

Los cambios Estándar proporcionan agilidad dentro de los límites de la Administración

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Conforme los cambios son aprobados e implementados, es critico registrar una

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Roles para la (SMF) de Cambio y

Metas del SMF de Cambio y Configuración

Tabla 2. Resultados y mediciones de las metas del SMF de Cambio y Configuración

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Diagrama de Flujo de Cambio y

La administración de Cambio y Configuración consiste de las siguientes actividades:

Solution Accelerators microsoft.com/technet/SolutionAccelerators

La figura 2 muestra el diagrama de flujo del proceso de la administración de Cambio y

Figura 2. Diagrama de flujo del proceso de administración de Cambio y

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Proceso 1: Documentar la configuración

Figura 3. Documentar la configuración base

Actividades: Documentar la configuración

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Tabla 4. Actividades y Consideraciones para documentar la Configuración base

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Proceso 2: Iniciar el Cambio

Figura 4. Iniciar el Cambio

Actividades: Iniciar el Cambio

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Tabla 5. Actividades y Consideraciones para Iniciar el Cambio

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Proceso 3: Clasificación del Cambio

Figura 5. Clasificación del Cambio

Actividades: Clasificación del Cambio

Tabla 6. Actividades y consideraciones para clasificar el Cambio

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Proceso 4: Aprobar y programar el

Figura 6. Aprobar y programar el cambio

Actividades: Aprobar y programar el Cambio

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Es responsabilidad del CAB, el determinar si el cambio debe:

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Tabla 7. Actividades y Consideraciones para la Aprobación del Cambio

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Proceso 5: Desarrollar y Probar el

Figura 7. Desarrollar y Probar el Cambio

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Actividades: Desarrollar y Probar el Cambio