3-Entregar MOF

Entregar
Publicado: 25 de abril de 2008
La fase de entrega brinda a los profesionales de TI las herramientas necesarias para ofrecer
servicios de TI, proyectos de infraestructura o despliegues de productos empaquetados más
eficazmente, y ayuda a garantizar que dichos servicios se conciban, planifiquen, construyan,
estabilicen y desplieguen de acuerdo con los requisitos empresariales y las especificaciones del
cliente .
Contenido de la fase de entrega
 Presentación general
 Guardar
 Planificación de proyectos
 Construir
 Estabilizar
 Desplegar
Descripción de la fase de entrega

Publicado: 25 de abril de 2008 | Actualizado: 10 de octubre de 2008
Introducción a MOF
La guía en el Microsoft® Operations Framework abarca todas las actividades y procesos
involucrados en la administración de un servicio de TI: su concepción, desarrollo, operación,
mantenimiento y, en última instancia, su retiro. MOF organiza estas actividades y procesos en
[Date]
1
Funciones de Gestión de Servicios (SMF), que se agrupan en fases que reflejan el ciclo de vida del
servicio de TI. Cada SMF está anclado dentro de una fase de ciclo de vida y contiene un conjunto
único de metas y resultados que apoyan los objetivos de esa fase. La disponibilidad de un servicio
de TI para pasar de una fase a otra es confirmada por revisiones de la dirección, que aseguran que
las metas se están logrando de una manera apropiada y que las metas de TI están alineadas con las
metas de la organización.
Descripción general de la fase de entrega

Si uno piensa en el ciclo de vida del servicio de TI como un continuo que comienza con los
esfuerzos de TI para entender los servicios que necesita y termina con los servicios que operan en
un entorno de producción, entonces la Fase Deliver es la parte del continuo donde los servicios se
planifican, diseñan, construyen y despliegan. También es la parte del continuo donde se planea,
diseña, construye y despliega un proyecto de infraestructura o despliegue de un producto
empaquetado. Y finalmente, es el proceso a través del cual cualquier cambio debe ir, grande o
pequeño. El grado de rigor del cambio dependerá de la naturaleza y el tamaño del cambio.
Generalmente, los cambios estándar -que ya son conocidos y probados- se moverán a través del
proceso más rápidamente que otros tipos de cambios, como un cambio menor, significativo o
importante. Consulte SMF de modificación y configuración para obtener más información.
Este proceso comienza con una forma temprana de planificación llamada "previsión", se mueve a
través de una etapa de planificación de proyecto más formal, continúa con la fase de diseño y
construcción, sigue con las pruebas y termina con la implementación. Hay varias opciones que los
administradores de un proyecto pueden hacer en términos de una disciplina de gestión para aplicar
al proyecto. Las posibilidades incluyen Microsoft® Solutions Framework (MSF), desarrollo de
software ágil, gestión de procesos de Capability Maturity Model Integration (CMMI), Scrum y Project
Management Institute (PMI). Si bien MSF es la base para los SMF en la fase Deliver, las
organizaciones pueden adaptar fácilmente la información en esos SMFs a cualquier disciplina de
gestión. Para obtener más información sobre el desarrollo de software ágil, vea Inicio de guía de
procesos del sistema de equipos de Microsoft Visual Studio® en
http://msdn2.microsoft.com/en-us/teamsystem/aa718795.aspx .
La fase Entrega contiene las siguientes funciones de administración de servicios (SMF): Envision,
Project Planning, Build, Stabilize e Deploy. Consulte la sección "Funciones de administración de
servicios (SMF) dentro de la fase" de esta guía para obtener más información sobre estos SMF.
Esta fase comienza después de la Revisión de Gestión de Cartera (MR), que proporciona un puente
entre la Fase del Plan y la Fase Entrega. Esta fase es movida adelante por el MR del plan del
proyecto aprobado. La prontitud de liberación MR se acerca al final de la fase de estabilización y
despliegue. Estas MR de fase de entrega se describen con mayor detalle más adelante en este
documento.
Esta fase es aquella en la que los equipos de proyectos desempeñan frecuentemente un papel
importante. La responsabilidad primaria del equipo que se aplica a la fase es la Responsabilidad de
la Solución, con el tipo de rol responsable para la fase de ser el Gerente de Soluciones, quien tiene
la supervisión de todas las soluciones y sus equipos de proyectos.
Otros tipos de rol clave para la fase son el Administrador de programas, el Administrador de
productos y el Desarrollador. Más información acerca de estos y otros tipos de rol, así como la
[Date]
2
Responsabilidad de las soluciones a la que pertenecen, se pueden encontrar en el "Equipo SMF
Focus" de este documento .
Más información sobre los roles del equipo del proyecto también está contenida en cada uno de los
documentos SMF para la fase y en el SMF del equipo , que forma parte de la capa gerencial básica
del ciclo de vida del servicio de TI.
Figura 1. La fase Deliver dentro del ciclo de vida del servicio de TI
Objetivos de la fase de entrega

Los objetivos principales de la fase de ciclo de vida del servicio Entregar TI son garantizar que los
servicios de TI, los proyectos de infraestructura o las implementaciones de productos empaquetados
se conciban, planifiquen, construyan, estabilicen y desplieguen de acuerdo con los requisitos
empresariales y las especificaciones del cliente.
Específicamente, eso significa asegurar que el equipo del proyecto:
 Captura las necesidades y requerimientos del negocio antes de planificar una solución.
 Prepara una especificación funcional y un diseño de solución.
 Elaborar planes de trabajo, estimaciones de costos y calendarios para los entregables.
 Construye la solución según las especificaciones del cliente, de modo que todas las
funciones estén completas y de manera que la solución esté lista para pruebas y
estabilización externas.
 Lanzamientos de la solución de la más alta calidad mediante la realización de pruebas
exhaustivas y el lanzamiento de candidatos de pilotaje.
 Implementa una solución estable en el entorno de producción y estabiliza la solución en la
producción.
 Prepara los equipos de operaciones y soporte para gestionar y proporcionar servicio al
cliente para la solución.
[Date]
3
El cumplimiento de estos objetivos requiere:
 Alineación con las funciones de gestión de servicios (SMF) para esta fase.
 Utilizar revisiones de gestión periódicas (MRs) para evaluar la efectividad de la fase.
Espectáculo: Heredado Protegido
There are no mem

Flujo de trabajo de la fase de entrega
El siguiente diagrama muestra la relación entre los SMF y las revisiones de punto de control en la
fase Entrega. Es importante señalar que, si bien el diagrama sugiere un enfoque secuencial de
cascada para la gestión de proyectos, otros enfoques más iterativos funcionarán igual de bien
utilizando la guía proporcionada por los SMF en la fase.
Figura 2. Flujo de trabajo de la fase de entrega
Funciones de administración de servicios

dentro de la fase de entrega
Para ayudar a los profesionales de TI a diseñar y ofrecer una estrategia de TI de manera eficaz,
MOF ofrece funciones de gestión de servicios (SMF) que definen los procesos, las personas y las
actividades necesarias para alinear los servicios de TI con los requisitos del negocio. Las SMFs
identifican y describen las actividades principales que los profesionales de TI realizan en las distintas
fases del ciclo de vida del servicio de TI. Aunque cada SMF se puede pensar y utilizar como un
conjunto independiente de procesos, es cuando se combinan que más eficazmente garantizar que la
prestación de servicios es completa y en la calidad deseada y los niveles de riesgo. Los SMF en
esta fase se realizan secuencialmente en su mayor parte, aunque, como se señaló anteriormente, su
orientación funciona bien en una variedad de disciplinas de gestión de proyectos, incluidas las que
son iterativas.
La siguiente tabla identifica los SMFs que apoyan el logro de estos objetivos dentro de la fase
Deliver.
[Date]
4
Tabla 1. Entrega de Fase SMFs
Producto / Propósito Resultados

SMF
 La visión y el alcance del
proyecto están claramente
documentados y
comprendidos por el equipo y
el cliente
Entregable: documento de visión
 El diseño conceptual de la
solución propuesta está
Propósito:
claramente documentado
ENVISIONIN
como parte del documento
 Comunicar claramente la visión,
de visión
alcance y riesgo del proyecto
 Los riesgos del proyecto
están claramente
documentados y
el cliente
Entregable: Documento del plan del proyecto  El diseño y las

características de la solución
Propósito: están claramente
documentados en la
 Obtener el acuerdo del equipo del especificación funcional
Planificación proyecto, el cliente y las partes  El diseño y las
de proyectos interesadas de que todos los hitos características de la solución
intermedios se han cumplido, de que los son claramente trazables
planes del proyecto reflejan las para los requisitos de
necesidades del cliente y de que los negocio, usuario, operativos
planes del proyecto son realistas y del sistema
 Un diseño final que cumpla

Entregable: Solución desarrollada
con los requisitos del
negocio, usuario, operativo y
Propósito:
del sistema
 Una solución que satisface
Construir  Construir una solución que cumpla con
las expectativas y
las expectativas y especificaciones del
especificaciones del cliente
cliente tal como se define en la
según se define en la
especificación funcional
Estabilizar Entregable : Solución probada y estable  Se resuelven todos los

problemas encontrados
Propósito : mediante las pruebas y los
comentarios de los pilotos
 Resolver todos los problemas  Una solución de alta calidad
encontrados mediante las pruebas y que satisface las
mediante comentarios de los pilotos, y expectativas y
[Date]
5
lanzar una solución de alta calidad que especificaciones del cliente
cumpla con las expectativas del cliente tal y como se define en la
y las especificaciones definidas en la especificación funcional
 Una solución estable

Entregable : Servicio en funcionamiento desplegada en el entorno de
producción
Propósito :  Cliente que está satisfecho y
acepta la solución
Desplegar  Implementar una solución estable que implementada
satisfaga al cliente y transferirla con  Una solución transferida con
éxito del equipo del proyecto a los éxito del equipo del proyecto
equipos de Operaciones y Soporte a los equipos de
Operaciones y Soporte
Cada una de estas SMFs se explica en detalle en su propia guía:
 Función de administración de servicios de Envision

 Función de gestión de servicios de planificación de proyectos
 Función de gestión de servicios de compilación
 Estabilizar la función de administración de servicios
 Implementar la función de administración de servicios
Revisión de Gestión (MRs) para la Fase

La gerencia es responsable de establecer metas, evaluar el progreso y asegurar resultados. En
parte, la gobernanza consiste en los procesos de toma de decisiones (controles) que ayudan a la
administración a cumplir con esta responsabilidad. Cada fase del ciclo de vida del servicio de TI
tiene una o más revisiones de gestión (MR) que funcionan como controles de gestión. Esto significa
que las personas adecuadas se reúnen, en el momento adecuado y con la información adecuada,
para tomar decisiones de gestión. Cada fase tiene objetivos de gestión diferentes, por lo que cada
fase tiene un enfoque único centrado en los MR con las partes interesadas apropiadas, las
decisiones necesarias y el tipo de datos necesarios para tomar decisiones bien informadas y
completamente ponderadas.
Hay dos MR que son claves para el diseño y la prestación efectiva de los servicios de TI: el Plan de
Proyecto MR aprobado y el MR de Readiness de Liberación. El Proyecto Plan Aprobado MR finaliza
el alcance del proyecto. La prontitud de liberación MR es un puente entre la fase de entrega y la
fase de operación. La revisión se realiza justo después de la estabilización y antes del despliegue.
Revisión de la gestión aprobada por el plan de proyecto

Después de que se haya aprobado un concepto de proyecto y se haya identificado un equipo de
proyecto de arranque, es necesario trabajar para aclarar los requisitos del negocio y determinar con
mayor precisión el nivel de esfuerzo y recursos (personas y financiación) necesarios para completar
el trabajo. En este punto, el equipo prepara la especificación funcional, trabaja a través del proceso
de diseño, y prepara planes de trabajo, estimaciones de costos y programaciones para las diversas
[Date]
6
entregas. La especificación funcional cumple múltiples propósitos: actúa como:
 Un conjunto de instrucciones para los desarrolladores sobre qué construir

 Una base para estimar el trabajo
 Un acuerdo con el cliente sobre exactamente lo que será construido
 Un punto de sincronización para todo el equipo
Antes de que se pueda entender la naturaleza completa del proyecto y de que la administración
pueda proporcionar una aprobación informada, se necesita documentación adicional. Es probable
que los siguientes documentos y planes sean parte de la preparación para un proceso integral de
construcción de proyectos:
 Especificación técnica
 Plan de comunicación
 Plan de prueba maestro
 Plan de entrenamiento
 Plan de proyecto básico
 Plan de prueba de aceptación del usuario
 Plan de conversión de datos o de sistemas (si procede)
 Plan de evaluación de seguridad y modelado de amenazas
 Revisiones de privacidad y otras normas, cumplimiento de políticas generales
 Enfoque de la segregación de ambientes para el desarrollo, prueba y producción
 Segregación de funciones (cuando sea necesario para fines de control)
 Plan de gestión y análisis de riesgos del proyecto
Al documentar los planes en estas áreas, el equipo del proyecto aclara cómo cumplirá con las
expectativas de desempeño y cumplimiento. Mantener un registro desde el principio capta la
comprensión del equipo del proyecto de las metas y los intentos de la gerencia, y proporciona a los
auditores potenciales un cuerpo claro de la evidencia para ver cómo bien se capturaron estas metas
y, en última instancia, se encontraron.
El enfoque de gobernabilidad adoptado por la organización ayudará a determinar a los participantes

en el proceso de RM. Los participantes en el Plan de Proyecto MR aprobado vienen de una
variedad de áreas:
 El equipo del proyecto, que puede incluir:

o Director del programa
o Gerente de producto
o Especialistas técnicos
o Desarrolladores
o Probadores
 El equipo directivo (como el propietario de la solución, el arquitecto, los patrocinadores, las
finanzas y las partes interesadas)
 Representantes de operaciones y apoyo
 Auditores
 Clientes o usuarios finales
Tabla 2. Componentes del Plan de Proyecto Revisión de Gestión Aprobada
[Date]
7
Análisis Decisiones Salidas
Entradas
El plan del proyecto Refinada visión y
y los planes y alcance aprobado.
documentos
relacionados son Diseño y características
Carta de proyecto con suficientes y documentadas en la
visión y alcance detallados apoyarán un proceso especificación funcional y
de construcción firmadas por los
La visión del proyecto
Plan maestro del proyecto efectivo. propietarios de las
es clara y completa.
respectivas funciones.
Programa maestro del La evaluación del
Proyecto con alcance
proyecto riesgo del proyecto Plan de gestión del
significativo y eficaz.
es completa y riesgo del proyecto
Evaluación de riesgos del adecuada. aprobado.
Se identificaron
proyecto
deficiencias de
Los recursos Financiamiento para
capacidad o
Plan para la coordinación estarán en su lugar y proyectos aprobados
deficiencias de
del proyecto, incluyendo: la financiación (potencialmente
recursos.
adecuada está restringidos a una fase
 Enfoque para las disponible para ser de trabajo hasta un hito
Requisitos y
partes interesadas. asignado. de revisión).
especificaciones
 Comunicaciones.
funcionales evaluados
 Gestión de La consolidación y Planes de comunicación
en cuanto a
requisitos. la simplificación han y coordinación
adecuación, claridad y
 Gestión de riesgos. tenido la aprobados.
preparación para la
consideración
actividad de desarrollo.
Oportunidades necesaria. Lista de controles
identificadas para internos que se
Las métricas del
consolidar, simplificar o Las métricas son desarrollarán como parte
proyecto son
desactivar soluciones suficientes para de la solución aprobada.
apropiadas.
rastrear y evaluar el
Métricas para el proyecto. Aprobación
rendimiento del proyecto documentada del
Se están abordando proyecto, propiedad del
los aspectos de proyecto y
seguridad, responsabilidades
privacidad y política. definidas.
Como resultado de la MR aprobada por el plan de proyecto, se habrá realizado una revisión
completa y la aprobación de la especificación funcional, el plan maestro y el programa maestro del
proyecto y el grupo de MR habrá acordado que el equipo del proyecto ha cumplido con los requisitos
para la aprobación del plan. El equipo del proyecto está listo para pasar al desarrollo de la solución.
Revisión de la Administración de Readiness de Liberación

El MR de disponibilidad de liberación se acerca a la finalización de la fase Entrega, entre Estabilizar
e Implementar. Representa una revisión exhaustiva de los resultados que se han producido, así
como una evaluación de la preparación de la empresa para emplear esta solución en su trabajo y de
las operaciones de TI y la disposición de apoyo para asumir la responsabilidad de esta solución en el
entorno de producción.
[Date]
8
En este MR, un equipo de revisión especialmente formado evalúa cuatro aspectos distintos de la
preparación para la liberación:
 La operabilidad y la capacidad de soportar el propio lanzamiento

 La preparación del entorno de producción (organización e infraestructura) para apoyar y
operar el lanzamiento
 La disposición de la empresa o los clientes a utilizar nuevas características y funcionalidad
 La disponibilidad de los planes de estrategia de lanzamiento, incluyendo planes de rollout y
rollback, planes de capacitación y planes de apoyo
El propósito de la Readiness de liberación MR es confirmar o certificar estos elementos. Listo se

define como "satisface las necesidades empresariales y de TI y puede soportar el logro constante y
continuo de las expectativas de nivel de servicio".
Aunque la gestión de riesgos es evidente a lo largo del ciclo de vida de los servicios de TI, en cierta
medida, el MR de disponibilidad de versiones tiene el mayor énfasis en la gestión del riesgo
operacional. Esto se debe a que el acto de introducir una versión nueva o actualizada suele implicar
una gran incertidumbre y un impacto potencial en la disponibilidad, fiabilidad, seguridad,
cumplimiento y riesgo de reputación. La prontitud de liberación MR es la última oportunidad de
retroceder si los riesgos no se abordan adecuadamente o son inaceptables.
Todos los interesados clave confirman la preparación de los componentes y acuerdan continuar con
el despliegue. La evidencia de la aprobación debe ser retenida para el proyecto y almacenada con
los materiales del proyecto para las revisiones subsecuentes de la revisión.
Los participantes en la Preparación para la Liberación MR incluyen obviamente representantes del

equipo de operaciones y soporte, el equipo del proyecto, el equipo de seguridad y los usuarios
empresariales. Los representantes de la dirección de operaciones, negocios y administración de
proyectos también deben estar involucrados.
Tabla 3. Dimensiones de la revisión de la gestión de la preparación de la liberación

Entradas
Guía de soporte de Visión y alcance Acuerdo sobre la Firmado en el proyecto.
operaciones del proyecto disposición para
revisados. proceder y liberar el Operaciones y equipo de
Plan de despliegue y proyecto. apoyo en pleno control de la
plan de contingencia Preparación y solución.
finalización del Si no se acuerda,
Plan de proyecto evaluado. determine las áreas a Se promulgó un plan de
implementación de abordar con alguna comunicación, informando a
seguridad Guía de apoyo a perspectiva inicial sobre todas las partes afectadas de
las operaciones la cantidad de trabajo. la liberación programada.
Validación y evaluada.
conversión de datos Si la decisión no era proceder,
(si procede) Se evaluaron las el plan de remediación y las
cuestiones de responsabilidades se
Plan de gestión de seguridad comunicaban.
[Date]
9
operacional y
privacidad.
Riesgos
Impacto
Aprobación de
operacional de la
aceptación del
migración y gestión
usuario
de datos evaluados.
Reunión Go / No Go
Evaluar el impacto
de patrocinadores e
en los negocios y TI
interesados y firma
de proceder o no
proceder.
La prontitud de liberación MR resulta en una decisión ir / no ir sobre si implementar la liberación.

Tener criterios claros en el lugar que todos los miembros del equipo de preparación para la
liberación entienden y están de acuerdo es fundamental para la toma de decisiones efectivas. La
siguiente tabla proporciona un breve resumen de los indicadores que pueden utilizarse para facilitar
este entendimiento común.
Tabla 4. Indicadores Go / No-Go
Indicadores de "Go" Indicadores "No-Go"

Elemento
 Todos los requisitos previos se
 El lanzamiento no está construido
han cumplido.
según los estándares.
 Toda la documentación está en
 Falta documentación.
Lanzamiento orden.
 El personal de apoyo primario y
 Existe un plan de retroceso
secundario no ha sido asignado.
adecuado.
 El personal de apoyo ya está

capacitado.
 Todos los procedimientos  Los niveles de software o
administrativos para la infraestructura utilizados para crear
liberación son claros y la solución no son compatibles
alineados con las normas del (demasiado nuevos, demasiado
Entorno de
sitio. antiguos) en el entorno actual.
producción
 Existen acuerdos de nivel  No hay plan de entrenamiento del
operativo (OLA) y contratos de personal de apoyo.
apoyo (UC) que parecen  No hay plan de copia de seguridad.
apoyar los niveles de servicio
requeridos.
Planes de  Se ha comunicado el proceso  Un punto único de fallo o falla fatal

estrategia de de escalamiento y la lista de existe en el plan, por ejemplo, la
lanzamiento contactos. Todos los dependencia de un técnico o una
interesados clave han sido tecnología no probada.
notificados.  No se han cumplido los requisitos
[Date]
10
previos del plan, como la
 Todos los interesados clave
confirmación de que los usuarios
han sido notificados.
estarán disponibles para realizar las
 Todos los recursos necesarios
pruebas de aceptación.
para la implementación han
 La documentación de gestión de
sido confirmados.
cambios no está en orden.
Si la decisión es ir, la liberación se mueve a la planificación de lanzamiento y los preparativos como

impulsado por el equipo de gestión de la liberación. De lo contrario, el lanzamiento se pospone
hasta que se produzcan las mejoras necesarias, o se cancela el lanzamiento.
La revisión de preparación de liberación La aprobación de MR significa que el proyecto está listo

para ser desplegado. Una vez finalizado el despliegue, el proyecto se considera finalizado, lo que
significa que el equipo del proyecto se ha desacoplado completamente y transferido la solución al
personal de Operaciones y Soporte. La actividad final para los miembros del equipo del proyecto,
los miembros del equipo directivo y las partes interesadas es realizar una firma de análisis post
proyecto en el proyecto y luego cerrarlo .

There are no mem
Flujo de trabajo de la fase de entrega

El siguiente diagrama muestra la relación entre los SMF y las revisiones de punto de control en la
fase Entrega. Es importante señalar que, si bien el diagrama sugiere un enfoque secuencial de
cascada para la gestión de proyectos, otros enfoques más iterativos funcionarán igual de bien
utilizando la guía proporcionada por los SMF en la fase.
Figura 2. Flujo de trabajo de la fase de entrega
Funciones de administración de servicios

dentro de la fase de entrega
[Date]
11
Para ayudar a los profesionales de TI a diseñar y ofrecer una estrategia de TI de manera eficaz,
MOF ofrece funciones de gestión de servicios (SMF) que definen los procesos, las personas y las
actividades necesarias para alinear los servicios de TI con los requisitos del negocio. Las SMFs
identifican y describen las actividades principales que los profesionales de TI realizan en las distintas
fases del ciclo de vida del servicio de TI. Aunque cada SMF se puede pensar y utilizar como un
conjunto independiente de procesos, es cuando se combinan que más eficazmente garantizar que la
prestación de servicios es completa y en la calidad deseada y los niveles de riesgo. Los SMF en
esta fase se realizan secuencialmente en su mayor parte, aunque, como se señaló anteriormente, su
orientación funciona bien en una variedad de disciplinas de gestión de proyectos, incluidas las que
son iterativas.
La siguiente tabla identifica los SMFs que apoyan el logro de estos objetivos dentro de la fase
Deliver.
Tabla 1. Entrega de Fase SMFs

SMF
 La visión y el alcance del
proyecto están claramente
documentados y
el cliente
Entregable: documento de visión
 El diseño conceptual de la
solución propuesta está
Propósito:
claramente documentado
Guardar
como parte del documento
 Comunicar claramente la visión,
de visión
alcance y riesgo del proyecto
 Los riesgos del proyecto
están claramente
documentados y
el cliente
Entregable: Documento del plan del proyecto  El diseño y las

características de la solución
Propósito: están claramente
documentados en la
 Obtener el acuerdo del equipo del especificación funcional
Planificación proyecto, el cliente y las partes  El diseño y las
de proyectos interesadas de que todos los hitos características de la solución
intermedios se han cumplido, de que los son claramente trazables
planes del proyecto reflejan las para los requisitos de
necesidades del cliente y de que los negocio, usuario, operativos
planes del proyecto son realistas y del sistema
Construir Entregable: Solución desarrollada  Un diseño final que cumpla

con los requisitos del
negocio, usuario, operativo y
[Date]
12
del sistema
Propósito:
 Una solución que satisface
las expectativas y
 Construir una solución que cumpla con
las expectativas y especificaciones del
según se define en la
cliente tal como se define en la
Entregable : Solución probada y estable

 Se resuelven todos los
problemas encontrados
Propósito :
mediante las pruebas y los
comentarios de los pilotos
 Resolver todos los problemas
 Una solución de alta calidad
encontrados mediante las pruebas y
Estabilizar que satisface las
mediante comentarios de los pilotos, y
expectativas y
lanzar una solución de alta calidad que
cumpla con las expectativas del cliente
tal y como se define en la
y las especificaciones definidas en la
 Una solución estable

Entregable : Servicio en funcionamiento desplegada en el entorno de
producción
Propósito :  Cliente que está satisfecho y
acepta la solución
Desplegar  Implementar una solución estable que implementada
satisfaga al cliente y transferirla con  Una solución transferida con
éxito del equipo del proyecto a los éxito del equipo del proyecto
equipos de Operaciones y Soporte a los equipos de
Operaciones y Soporte
Cada una de estas SMFs se explica en detalle en su propia guía:
 Función de administración de servicios de Envision

 Función de gestión de servicios de planificación de proyectos
 Función de gestión de servicios de compilación
 Estabilizar la función de administración de servicios
 Implementar la función de administración de servicios
Revisión de Gestión (MRs) para la Fase

La gerencia es responsable de establecer metas, evaluar el progreso y asegurar resultados. En
parte, la gobernanza consiste en los procesos de toma de decisiones (controles) que ayudan a la
administración a cumplir con esta responsabilidad. Cada fase del ciclo de vida del servicio de TI
tiene una o más revisiones de gestión (MR) que funcionan como controles de gestión. Esto significa
que las personas adecuadas se reúnen, en el momento adecuado y con la información adecuada,
para tomar decisiones de gestión. Cada fase tiene objetivos de gestión diferentes, por lo que cada
fase tiene un enfoque único centrado en los MR con las partes interesadas apropiadas, las
decisiones necesarias y el tipo de datos necesarios para tomar decisiones bien informadas y
[Date]
13
completamente ponderadas.
Hay dos MR que son claves para el diseño y la prestación efectiva de los servicios de TI: el Plan de
Proyecto MR aprobado y el MR de Readiness de Liberación. El Proyecto Plan Aprobado MR finaliza
el alcance del proyecto. La prontitud de liberación MR es un puente entre la fase de entrega y la
fase de operación. La revisión se realiza justo después de la estabilización y antes del despliegue.
Revisión de la gestión aprobada por el plan de proyecto

Después de que se haya aprobado un concepto de proyecto y se haya identificado un equipo de
proyecto de arranque, es necesario trabajar para aclarar los requisitos del negocio y determinar con
mayor precisión el nivel de esfuerzo y recursos (personas y financiación) necesarios para completar
el trabajo. En este punto, el equipo prepara la especificación funcional, trabaja a través del proceso
de diseño, y prepara planes de trabajo, estimaciones de costos y programaciones para las diversas
entregas. La especificación funcional cumple múltiples propósitos: actúa como:
 Un conjunto de instrucciones para los desarrolladores sobre qué construir

 Una base para estimar el trabajo
 Un acuerdo con el cliente sobre exactamente lo que será construido
 Un punto de sincronización para todo el equipo
Antes de que se pueda entender la naturaleza completa del proyecto y de que la administración
pueda proporcionar una aprobación informada, se necesita documentación adicional. Es probable
que los siguientes documentos y planes sean parte de la preparación para un proceso integral de
construcción de proyectos:
 Especificación técnica
 Plan de comunicación
 Plan de prueba maestro
 Plan de entrenamiento
 Plan de proyecto básico
 Plan de prueba de aceptación del usuario
 Plan de conversión de datos o de sistemas (si procede)
 Plan de evaluación de seguridad y modelado de amenazas
 Revisiones de privacidad y otras normas, cumplimiento de políticas generales
 Enfoque de la segregación de ambientes para el desarrollo, prueba y producción
 Segregación de funciones (cuando sea necesario para fines de control)
 Plan de gestión y análisis de riesgos del proyecto
Al documentar los planes en estas áreas, el equipo del proyecto aclara cómo cumplirá con las
expectativas de desempeño y cumplimiento. Mantener un registro desde el principio capta la
comprensión del equipo del proyecto de las metas y los intentos de la gerencia, y proporciona a los
auditores potenciales un cuerpo claro de la evidencia para ver cómo bien se capturaron estas metas
y, en última instancia, se encontraron.
El enfoque de gobernabilidad adoptado por la organización ayudará a determinar a los participantes

en el proceso de RM. Los participantes en el Plan de Proyecto MR aprobado vienen de una
variedad de áreas:
[Date]
14
 El equipo del proyecto, que puede incluir:
o Director del programa
o Gerente de producto
o Especialistas técnicos
o Desarrolladores
o Probadores
 El equipo directivo (como el propietario de la solución, el arquitecto, los patrocinadores, las
finanzas y las partes interesadas)
 Representantes de operaciones y apoyo
 Auditores
 Clientes o usuarios finales
Tabla 2. Componentes del Plan de Proyecto Revisión de Gestión Aprobada

Entradas
Carta de proyecto con La visión del proyecto El plan del proyecto Refinada visión y
visión y alcance detallados es clara y completa. y los planes y alcance aprobado.
documentos
Plan maestro del proyecto Proyecto con alcance relacionados son Diseño y características
significativo y eficaz. suficientes y documentadas en la
Programa maestro del apoyarán un proceso especificación funcional y
proyecto Se identificaron de construcción firmadas por los
deficiencias de efectivo. propietarios de las
Evaluación de riesgos del capacidad o respectivas funciones.
proyecto deficiencias de La evaluación del
recursos. riesgo del proyecto Plan de gestión del
Plan para la coordinación es completa y riesgo del proyecto
del proyecto, incluyendo: Requisitos y adecuada. aprobado.
especificaciones
 Enfoque para las funcionales evaluados Los recursos Financiamiento para
partes interesadas. en cuanto a estarán en su lugar y proyectos aprobados
 Comunicaciones. adecuación, claridad y la financiación (potencialmente
 Gestión de preparación para la adecuada está restringidos a una fase
requisitos. actividad de desarrollo. disponible para ser de trabajo hasta un hito
 Gestión de riesgos. asignado. de revisión).
Las métricas del
Oportunidades proyecto son La consolidación y Planes de comunicación
identificadas para apropiadas. la simplificación han y coordinación
consolidar, simplificar o tenido la aprobados.
desactivar soluciones consideración
necesaria. Lista de controles
Métricas para el internos que se
rendimiento del proyecto Las métricas son desarrollarán como parte
suficientes para de la solución aprobada.
rastrear y evaluar el
proyecto. Aprobación
documentada del
Se están abordando proyecto, propiedad del
[Date]
15
los aspectos de proyecto y
seguridad, responsabilidades
privacidad y política. definidas.
Como resultado de la MR aprobada por el plan de proyecto, se habrá realizado una revisión
completa y la aprobación de la especificación funcional, el plan maestro y el programa maestro del
proyecto y el grupo de MR habrá acordado que el equipo del proyecto ha cumplido con los requisitos
para la aprobación del plan. El equipo del proyecto está listo para pasar al desarrollo de la solución.
Revisión de la Administración de Readiness de Liberación

El MR de disponibilidad de liberación se acerca a la finalización de la fase Entrega, entre Estabilizar
e Implementar. Representa una revisión exhaustiva de los resultados que se han producido, así
como una evaluación de la preparación de la empresa para emplear esta solución en su trabajo y de
las operaciones de TI y la disposición de apoyo para asumir la responsabilidad de esta solución en el
entorno de producción.
En este MR, un equipo de revisión especialmente formado evalúa cuatro aspectos distintos de la
preparación para la liberación:
 La operabilidad y la capacidad de soportar el propio lanzamiento

 La preparación del entorno de producción (organización e infraestructura) para apoyar y
operar el lanzamiento
 La disposición de la empresa o los clientes a utilizar nuevas características y funcionalidad
 La disponibilidad de los planes de estrategia de lanzamiento, incluyendo planes de rollout y
rollback, planes de capacitación y planes de apoyo
El propósito de la Readiness de liberación MR es confirmar o certificar estos elementos. Listo se

define como "satisface las necesidades empresariales y de TI y puede soportar el logro constante y
continuo de las expectativas de nivel de servicio".
Aunque la gestión de riesgos es evidente a lo largo del ciclo de vida de los servicios de TI, en cierta
medida, el MR de disponibilidad de versiones tiene el mayor énfasis en la gestión del riesgo
operacional. Esto se debe a que el acto de introducir una versión nueva o actualizada suele implicar
una gran incertidumbre y un impacto potencial en la disponibilidad, fiabilidad, seguridad,
cumplimiento y riesgo de reputación. La prontitud de liberación MR es la última oportunidad de
retroceder si los riesgos no se abordan adecuadamente o son inaceptables.
Todos los interesados clave confirman la preparación de los componentes y acuerdan continuar con
el despliegue. La evidencia de la aprobación debe ser retenida para el proyecto y almacenada con
los materiales del proyecto para las revisiones subsecuentes de la revisión.
Los participantes en la Preparación para la Liberación MR incluyen obviamente representantes del

equipo de operaciones y soporte, el equipo del proyecto, el equipo de seguridad y los usuarios
empresariales. Los representantes de la dirección de operaciones, negocios y administración de
proyectos también deben estar involucrados.
Tabla 3. Dimensiones de la revisión de la gestión de la preparación de la liberación
[Date]
16
Entradas
Visión y alcance
del proyecto
Guía de soporte de
revisados.
operaciones
Preparación y
Plan de despliegue y
finalización del
plan de contingencia
proyecto evaluado. Firmado en el proyecto.
Plan de
Guía de apoyo a Operaciones y equipo de
implementación de Acuerdo sobre la
las operaciones apoyo en pleno control de la
seguridad disposición para
evaluada. solución.
proceder y liberar el
Validación y proyecto.
Se evaluaron las Se promulgó un plan de
conversión de datos
cuestiones de comunicación, informando a
(si procede) Si no se acuerda,
seguridad todas las partes afectadas de
determine las áreas a
operacional y la liberación programada.
Plan de gestión de abordar con alguna
privacidad.
Riesgos perspectiva inicial sobre
Si la decisión no era proceder,
la cantidad de trabajo.
Impacto el plan de remediación y las
Aprobación de
operacional de la responsabilidades se
aceptación del
migración y gestión comunicaban.
usuario
de datos evaluados.
Reunión Go / No Go
Evaluar el impacto
de patrocinadores e
en los negocios y TI
interesados y firma
de proceder o no
proceder.
La prontitud de liberación MR resulta en una decisión ir / no ir sobre si implementar la liberación.
Tener criterios claros en el lugar que todos los miembros del equipo de preparación para la
liberación entienden y están de acuerdo es fundamental para la toma de decisiones efectivas. La
siguiente tabla proporciona un breve resumen de los indicadores que pueden utilizarse para facilitar
este entendimiento común.
Tabla 4. Indicadores Go / No-Go
Indicadores de "Go" Indicadores "No-Go"

Elemento
 Todos los requisitos previos se
 El lanzamiento no está construido
han cumplido.
según los estándares.
 Toda la documentación está en
 Falta documentación.
Lanzamiento orden.
 El personal de apoyo primario y
 Existe un plan de retroceso
secundario no ha sido asignado.
adecuado.
Entorno de  El personal de apoyo ya está  Los niveles de software o

producción capacitado. infraestructura utilizados para crear
 Todos los procedimientos la solución no son compatibles
administrativos para la (demasiado nuevos, demasiado
[Date]
17
liberación son claros y
alineados con las normas del
sitio. antiguos) en el entorno actual.
 Existen acuerdos de nivel  No hay plan de entrenamiento del
operativo (OLA) y contratos de personal de apoyo.
apoyo (UC) que parecen  No hay plan de copia de seguridad.
apoyar los niveles de servicio
requeridos.
 Un punto único de fallo o falla fatal

 Se ha comunicado el proceso
existe en el plan, por ejemplo, la
de escalamiento y la lista de
dependencia de un técnico o una
contactos. Todos los
tecnología no probada.
interesados clave han sido
 No se han cumplido los requisitos
Planes de notificados.
previos del plan, como la
estrategia de  Todos los interesados clave
confirmación de que los usuarios
lanzamiento han sido notificados.
estarán disponibles para realizar las
 Todos los recursos necesarios
pruebas de aceptación.
para la implementación han
 La documentación de gestión de
sido confirmados.
cambios no está en orden.
Si la decisión es ir, la liberación se mueve a la planificación de lanzamiento y los preparativos como

impulsado por el equipo de gestión de la liberación. De lo contrario, el lanzamiento se pospone
hasta que se produzcan las mejoras necesarias, o se cancela el lanzamiento.
La revisión de preparación de liberación La aprobación de MR significa que el proyecto está listo

para ser desplegado. Una vez finalizado el despliegue, el proyecto se considera finalizado, lo que
significa que el equipo del proyecto se ha desacoplado completamente y transferido la solución al
personal de Operaciones y Soporte. La actividad final para los miembros del equipo del proyecto,
los miembros del equipo directivo y las partes interesadas es realizar una firma de análisis post
proyecto en el proyecto y luego cerrarlo .

There are no mem
Integración de la fase de entrega con gestión

de SMF de capa
La Capa de administración es la base del ciclo de vida del servicio de TI. Esta fase no es un
segmento aparte, sino que las actividades de la capa de gestión se integran con todas las otras
fases del ciclo de vida. Los siguientes SMFs admiten las actividades principales de la Capa de
administración:
 Gobierno, Riesgo y Cumplimiento (GRC)

 Cambio y configuración
[Date]
18
 Equipo
Estas SMF de gestión de capas son elementos importantes en todas las otras fases del ciclo de
vida de TI. La mayoría de las SMF en las otras fases discuten procesos específicos y distintos. Sin
embargo, GRC y SMF de cambios y configuración tienen el objetivo de garantizar servicios de TI
efectivos, eficientes y compatibles. Con ese fin, contienen una guía que aborda la naturaleza única
de los objetivos de cada fase.
La fase de entrega se centra en la construcción de la solución correcta de la manera correcta. Aquí

GRC se centra en las decisiones de alcance del proyecto, la participación de los interesados en el
proyecto y los riesgos del proyecto. La gestión del cambio también está enfocada en proyectos,
conduciendo a menudo actividades de gestión de riesgos para cada proyecto.
El Equipo SMF asegura que alguien es en última instancia responsable del trabajo requerido para
entregar efectivamente servicios de TI. También asegura que todos los que hacen ese trabajo
tienen un papel claro, entienden las responsabilidades que van con ese papel y tienen las
habilidades adecuadas para llevar a cabo esas responsabilidades.
Cuadro 5. Gestionar la concentración de SMFs en la fase de entrega
Cambiar y
Objetivo de la fase GRC Focus configurar el Enfoque en equipo
de entrega enfoque
 La arquitectura de
la solución admite
los requisitos de la
organización
 Participantes del
 Principios para la
proyecto,  Alcance
Asegúrese de que los organización eficaz de
metodología, de la
servicios que el los equipos de
riesgos identificados solución
negocio y TI han proyecto
 Proceso de  Recursos
acordado se  Responsabilidades y
realización del valor  Gestión de
desarrollan con tipos de rol
 Ciclo de vida del proyectos
eficacia, desplegado  Alineación de
diseño de software  Impacto
con éxito y listo para responsabilidades
 Mitigación de financiero
las operaciones  Asignación de roles
riesgos
 Controles internos
definidos
 Procedimientos
definidos
Equipo SMF Focus

Hay un único foco de SMF en la fase Deliver. Es la Solución Responsabilidad.
Soluciones Responsabilidad
[Date]
19
La responsabilidad de soluciones incluye los tipos de rol que son importantes para los cinco SMF en
la fase de entrega del ciclo de vida de los servicios de TI: Envision, Project Planning, Build, Stabilize
e Deploy.
 El Envision SMF se centra en convertir los requisitos del negocio en nuevos servicios de TI
que pueden ser entregados a la producción.
 El SMF de planificación de proyectos se centra en cómo los equipos de proyectos completan
la mayor parte de su trabajo de planificación, preparando la especificación funcional, el diseño
de la solución, los planes de trabajo, las estimaciones de costos y los horarios.
 Build SMF se centra en desarrollar los productos de la solución de servicios de TI según las
especificaciones del cliente, desarrollando la documentación de la solución, creando el
laboratorio de desarrollo y prueba y preparando la solución para la implementación piloto.
 El Stabilize SMF se centra en la liberación de la solución de mayor calidad posible en el hito
de disponibilidad de la versión.
 Deploy SMF se centra en liberar una solución estable en el entorno de producción.
En la siguiente tabla se enumeran los tipos de rol asociados con la Responsabilidad de soluciones,
así como las responsabilidades y objetivos para cada tipo de rol.
Cuadro 6. Responsabilidad de las soluciones y sus tipos de funciones de los asistentes
Responsabilidades Gol
Tipo de rol
 Función responsable
 Posee todas las SMFs en
esta responsabilidad  Asegura que todos los proyectos
Gerente de  Director de proyectos para funcionen correctamente y la
soluciones todos los proyectos transición exitosa a las operaciones
 Resuelve conflictos entre
proyectos
 Asegura que los proyectos

 Controla el diseño, la
individuales funcionen sin problemas
Director del programación y los recursos a
y construya la solución correcta en el
programa nivel de proyecto
momento adecuado
 Construye la solución  Garantiza la entrega según las

Desarrollador acordada especificaciones acordadas
 Pruebas para determinar con  Garantiza que todos los problemas

precisión el estado del conocidos se resuelven antes de la
Ensayador
desarrollo de la solución liberación.
Gerente de  Actúa como defensor del  Garantiza la satisfacción del cliente

producto cliente
 Ayuda a conducir la visión de
proyecto compartida
 Gestiona las expectativas de
[Date]
20
los clientes
 Es el defensor del usuario en

los equipos de proyecto  Asegura que la solución liberada sea
Experiencia de  Ayuda a definir los requisitos utilizable y satisfaga las necesidades
usuario del usuario y ayuda a de los usuarios finales
diseñarlos para satisfacerlos
 Evalúa el diseño de la
solución
 Documenta los requisitos de
operaciones para asegurar
 Asegura que una solución estable se
Gestión de la que se cumplan con el diseño
despliegue al entorno de producción
liberación  Crea un piloto, plan de
despliegue y programación
 Administra la implementación
del sitio
 Defensores de operaciones
en el equipo del proyecto
 Requiere expertos en  Garantiza que los requisitos
operaciones según sea operativos forman parte del diseño de
Experiencia en
necesario para obtener la solución y se abordan antes de la
Operaciones
información detallada liberación.
 Coordina con la gestión de la
liberación
 Posee todas las pruebas en

todos los equipos del proyecto
 Desarrolla estrategias y  Asegura que la prueba coincida con
Gerente de planes de pruebas la producción
Pruebas  Garantiza la utilización de los  Asegura que no hay sorpresas
métodos de prueba de
mejores prácticas
Objetivos, Riesgos y Controles

La gobernanza proporciona los principios y estructuras para llevar a cabo los objetivos y prioridades
clave de una organización en el contexto de los requisitos y riesgos de la empresa. La gobernanza
se define en la fundación Manage Layer, pero está integrada en todas las fases. La siguiente tabla
enumera los objetivos clave de la Fase Deliver, junto con los riesgos para aquellos objetivos y
controles que aseguran que se cumplan los objetivos.
Tabla 7. Objetivos, riesgos y controles de la fase de entrega
Riesgo Controlar
Objetivo
[Date]
21
 Los servicios de TI no
proporcionan valor comercial
Asegúrese de que los servicios que el  Desarrollo inadecuado del
negocio y TI han acordado se servicio de TI (demasiado largo, Plan de Proyecto
desarrollan con eficacia, desplegado con demasiado caro, o ambos) Aprobado MR
éxito y listo para las operaciones  Operaciones que no pueden
operar con eficacia el servicio
 La solución de servicio no
cumple con los requisitos del
negocio
Construir la solución correcta de la Plan de Proyecto
 El esfuerzo de desarrollo no
manera correcta Aprobado MR
logra entregar soluciones a
tiempo o dentro del presupuesto
 El funcionamiento del servicio

provoca errores y posiblemente la
seguridad comprometida
Revisión de
Proporcione una solución lista para las  Los niveles de servicio no se
Readiness de
operaciones mantienen debido a errores de
Liberación MR
operaciones y errores de
configuración
Conclusión
Este documento proporciona una amplia visión general de la Fase de Entrega de MOF y sus SMFs
relacionados, revisiones de gestión y controles. El siguiente paso para poner en práctica MOF 4.0
es considerar las necesidades de su organización, y luego leer y utilizar los SMF relevantes. Su
guía paso a paso será de valor para las organizaciones de TI cuyo objetivo es confiable, eficiente y
obligar a los servicios de TI .
Entrega Fase SMFs
 Guardar
 Planificación de proyectos
 Construir
 Estabilizar
 Desplegar
Realimentación
Envíe preguntas y comentarios sobre esta guía a mof@microsoft.com .
Función de administración de servicios de

[Date]
22
Envision
Posición de la Envision SMF dentro del ciclo de vida del servicio de TI de MOF
El ciclo de vida del servicio de TI de MOF abarca todas las actividades y procesos involucrados en
la administración de un servicio de TI: su concepción, desarrollo, operación, mantenimiento y, en
última instancia, su retiro. MOF organiza estas actividades y procesos en Funciones de Gestión de
Servicios (SMF), que se agrupan en fases del ciclo de vida. Cada SMF está anclado dentro de una
fase de ciclo de vida y contiene un conjunto único de metas y resultados que apoyan los objetivos
de esa fase. Los SMF pueden ser usados como conjuntos independientes de procesos, pero es
cuando los SMFs se usan juntos que son más efectivos para asegurar la prestación de servicios con
los niveles de calidad y riesgo deseados.
El Envision SMF pertenece a la fase Deliver del ciclo de vida del servicio de TI de MOF. La
siguiente figura muestra el lugar del Envision SMF dentro de la fase Deliver, así como la ubicación
de la Deliver Phase dentro del ciclo de vida del servicio de TI.
Figura 1. Posición de la Envision SMF dentro del ciclo de vida del servicio de TI
Antes de utilizar este SMF, puede leer las siguientes guías de MOF 4.0 para obtener más
información sobre el ciclo de vida del servicio de TI de MOF y la fase Deliver:
 Descripción de MOF
 Descripción de la fase de entrega
¿Por qué utilizar el Envision SMF?
[Date]
23
Este SMF debe ser útil a cualquier persona que tenga la tarea de formar un equipo central del
proyecto, preparar y entregar un documento de visión / alcance que comunique claramente la visión
del proyecto y el alcance de esa visión y preparar una evaluación de riesgos.
Se trata de cómo hacer lo siguiente:
 Organizar el equipo principal del proyecto.

 Escriba el documento de visión / alcance.
 Aprobar el documento de visión / alcance.
Visión general de funciones de Envision

Service Management
Prever es el primer paso que un equipo de proyecto toma para convertir los requerimientos del
negocio en un cambio en la infraestructura de TI o en nuevos servicios de TI que pueden ser
entregados en la producción. Es el proceso de unificación de un equipo con una visión común y es
un requisito clave para asegurar el éxito de un proyecto. Un equipo de proyecto debe tener una
visión clara de lo que quiere lograr y ser capaz de comunicar esta visión en términos que motiven a
los miembros del equipo, sus clientes y sus partes interesadas. El proceso de visualización
comienza en la Fase del Plan y concluye en la Fase Entrega.
Durante la visualización, los equipos de proyecto identifican y analizan las necesidades y

requerimientos del negocio para que puedan comenzar a planear una solución. Esa solución podría
ser una sola aplicación, un servicio de TI completo, o una adición o modificación de la infraestructura
de TI existente. El tipo de rol de equipo primario es la Gestión de productos, cuyo objetivo principal
es garantizar que se aborden las necesidades de negocio identificadas del cliente. Puede encontrar
más información sobre el tipo de rol de Gestión de productos y otros tipos de rol implicados en
Envision SMF en la tabla Tipos de funciones de Envision SMF que se incluye a continuación.
Mediante la creación de vistas de alto nivel de las metas del proyecto y las limitaciones, el visionado
sirve como una forma temprana de planificación. Establece el escenario para el proceso de
planificación más formal que tendrá lugar durante la fase de planificación del proyecto.
La guía proporcionada por el Envision SMF está diseñada para ayudar a:
 La administración elige al equipo principal del proyecto y crea el documento de estructura del
proyecto que especifica las funciones y responsabilidades de los miembros del equipo.
 El equipo del proyecto crea el documento de visión / alcance, realiza una evaluación de
riesgos y completa el informe de revisión de hitos.
 Los miembros del equipo, los clientes y las partes interesadas aprueban el reporte de
revisión de hitos para el hito Aprobado por Visión / Alcance. En este hito, el equipo, los
clientes y las partes interesadas están de acuerdo en la dirección general del proyecto: el
alcance de las características del proyecto, el calendario general para entregar la solución del
proyecto y los riesgos asociados con el proyecto. Después del Hito Aprobado por Visión /
[Date]
24
Alcance, los equipos de proyecto continúan en la fase de planificación.
Tipos de rol SMF de Envision
La responsabilidad primordial del equipo que se aplica al Envision SMF es la Responsabilidad de la

Solución. Los tipos de rol dentro de esa responsabilidad y sus actividades principales dentro de
este SMF se muestran en la siguiente tabla.
Cuadro 1. Responsabilidad del proyecto y sus tipos de función de asistente
Responsabilidades Papel en este SMF

Tipo de rol
 Posee todas las SMFs en esta
responsabilidad
Gerente de  Supervisión continua
 Actua como director de proyectos
soluciones
para todos los proyectos
 Resuelve conflictos entre proyectos
 Establece objetivos de
diseño
 Controla el diseño, la programación y  Describe el concepto de
Director del
los recursos a nivel de proyecto solución
programa
 Crea la estructura del
proyecto
 Construye prototipos
 Investiga las opciones de
 Construye la solución acordada desarrollo y tecnología
Desarrollador
 Analiza la viabilidad del
proyecto
 Estrategias de pruebas
 Pruebas para determinar con  Criterios de aceptación de
precisión el estado del desarrollo de pruebas
Ensayador
la solución  Implicaciones del proyecto
de documentos
 Establece los objetivos

generales
 Actúa como defensor del cliente
 Identifica las necesidades
del cliente
Gerente de proyecto compartida
 Determina los requisitos
producto  Gestiona las expectativas de los
del proyecto
clientes
 Produce el documento de
visión / alcance
Experiencia de  Actúa como defensor del usuario en  Documentos requisitos de

usuario los equipos de proyecto rendimiento del usuario
[Date]
25
Tipo de rol
 Ayuda a definir los requisitos del
usuario  Documentos implicados en
 Ayuda a diseñar para satisfacer las las pruebas del proyecto
necesidades del usuario
 Evalúa el diseño de la solución  Implicaciones de

 Documenta los requisitos de implementación de
operaciones para asegurar que se documentos
Gestión de la cumplan con el diseño  Documentos gestión de
liberación  Crea un piloto, plan de despliegue y operaciones y apoyo
programación  Documentos criterios de
 Administra la implementación del sitio aceptación de operaciones
 Defensores de operaciones en el
equipo del proyecto
 Requiere expertos en operaciones
 Documentos requisitos de
Experiencia en según sea necesario para obtener
rendimiento de operaciones
Operaciones información detallada
liberación
 Posee todas las pruebas en todos los

equipos del proyecto
 Desarrolla estrategias y planes de
pruebas
Pruebas
 Garantiza la utilización de métodos
de prueba de las mejores prácticas
Objetivos de la proyección
Los objetivos principales del visionado son formar el equipo principal del proyecto, preparar y
entregar un documento de visión / alcance que comunique claramente la visión del proyecto y el
alcance de esa visión y prepare una evaluación del riesgo. La Tabla 2 muestra los resultados
deseados de los objetivos de Envision SMF y enumera las medidas que puede usar para medir con
qué éxito ha logrado estos objetivos después de completar este SMF.
Tabla 2. Resultados y Medidas de los Objetivos de Envision SMF
Medidas
Resultados
La visión y el alcance del proyecto están  No hay errores de comunicación y
claramente documentados y comprendidos por malentendidos se encuentran más
el equipo y el cliente. adelante en el proyecto.
 La visión y el alcance permanecen
intactos durante todo el proyecto.
 El documento de visión / alcance es
[Date]
26
aprobado por el equipo y las partes
interesadas.
 Signoff en la Visión / Alcance Aprobado
Hito ocurre.
 No ocurren problemas no tratados durante

el proyecto.
Los riesgos del proyecto están claramente  La evaluación del riesgo es aprobada por
documentados y comprendidos por el equipo y el equipo y las partes interesadas.
el cliente.  Signoff en la Visión / Alcance Aprobado
Hito ocurre.
Términos clave
La siguiente tabla contiene definiciones de los términos clave que se encuentran en esta guía.
Tabla 3. Términos clave
Definición
Término
Cliente El cliente es la persona u organización que comisiona y financia el proyecto.
Los primeros indicadores de progreso que segmentan grandes esfuerzos de trabajo
Hito en porciones manejables. La Fase Deliver sugiere un conjunto de hitos intermedios,
intermedio pero los equipos de proyecto deben definir sus propios hitos intermedios que tengan
sentido para sus proyectos.
Un punto de sincronización de proyecto. Los hitos principales marcan la transición
de un proyecto de una fase a la siguiente. También transfieren la responsabilidad
Hito primaria de una función a otra. Las funciones de gestión de servicio de la fase de
entrega (SMF) corresponden a los principales hitos de Microsoft Solutions
Framework (MSF).
Una visión de la visión del proyecto limitada por limitaciones como tiempo y
Alcance recursos. El ámbito de la solución describe las características y entregables de la
solución. El alcance del proyecto describe el trabajo a realizar por el equipo.
Una entrega coordinada de tecnologías, documentación, capacitación y soporte que
Solución responda con éxito al problema comercial de un cliente. Las soluciones suelen
combinar personas, procesos y tecnología para resolver problemas.
Las partes interesadas son personas o grupos que tienen interés en el resultado del
proyecto, aunque sus objetivos y prioridades no siempre son idénticos a los del
Tenedor de cliente. Entre los ejemplos de las partes interesadas se incluyen los directores
apuestas departamentales que se verán afectados por la solución, los miembros del personal
de TI que son responsables de ejecutar y apoyar la solución y los administradores
funcionales que aportan recursos al equipo del proyecto.
Usuarios Las personas que interactúan con la solución para realizar sus trabajos.
Visión Describe los objetivos fundamentales de la solución.
[Date]
27
Flujo del proceso de visualización
La Figura 2 ilustra el flujo de proceso para la gestión de visualización. Este flujo consiste en los
siguientes procesos:

[Date]
28
Figura 2. Flujo del proceso de visualización
La Figura 3 muestra el flujo del proceso con más detalle.
Figura 3. Flujo del proceso de visualización: detallado
[Date]
29
Proceso 1: Organizar el equipo central
Este acelerador forma
El primer proceso de visualización es que la administración organice el parte de una serie
equipo principal del proyecto y produzca el documento de estructura del más amplia de
proyecto. herramientas y
directrices de Solution
Accelerators .
Descargar
Obtenga el Microsoft
Operations
Framework 4.0
Notificaciones de
aceleradores de
soluciones
Regístrese para
conocer las
actualizaciones y los
nuevos lanzamientos
Figura 4. Organizar el equipo central Realimentación
Actividades: Organizar el equipo central Envíanos tus

comentarios o
Durante este proceso, la administración asigna los miembros principales al
equipo del proyecto. Típicamente, la gerencia no monta al equipo completo
todavía. El equipo inicial a menudo juega múltiples funciones hasta que
todos los miembros están en su lugar.
Después de asignar el equipo central, la administración crea un documento

de estructura de proyecto que describe la organización del equipo y las
funciones y responsabilidades específicas asignadas a cada miembro del
equipo. El documento de estructura del proyecto también aclara la cadena
de rendición de cuentas al cliente y especifica los puntos de contacto
designados que el equipo del proyecto tiene con el cliente. Estos pueden
variar dependiendo de las circunstancias del proyecto.
Tabla 4. Actividades y Consideraciones para la Organización del

Equipo Principal
Consideraciones
Ocupaciones
Asignar  ¿Cuál es la escala del proyecto, pequeña,
miembros mediana o grande?
principales al  ¿Estarán los miembros dedicados al equipo o
[Date]
30
Consideraciones
Ocupaciones
equipo del trabajarán en otros proyectos también?
proyecto  ¿Tendrán los miembros múltiples funciones o
cada miembro tendrá un papel único?
 ¿Tiene la organización un modelo de equipo
existente para proyectos de TI?
 ¿Están los miembros del equipo experimentados
en sus roles asignados? ¿Se requiere
entrenamiento?
Entradas:
 Propuesta de proyecto
Salidas:
 Documento de estructura del proyecto, que

incluye:
 Objetivos, objetivos, supuestos y
limitaciones del proyecto.
 Alcance del proyecto.
 Funciones y responsabilidades.
 Protocolos de proyectos.
 Evaluación de riesgo y emisión.
 Glosario del proyecto.
 Miembros principales asignados al equipo del
proyecto
Mejores prácticas:
 Aunque los miembros del equipo pueden cumplir

múltiples funciones en la mayoría de los casos,
los miembros del equipo a los que se asignan
funciones de desarrollo y prueba no deben asumir
otras funciones.
 Los miembros del equipo en las funciones de
administración de productos y administración de
programas deben estar totalmente dedicados al
proyecto durante la visualización.
 En el documento de la estructura del proyecto,
describa los hitos desde el principio para que el
cliente entienda cuándo deben ocurrir las cosas y
qué proyecto el equipo puede utilizar durante sus
actividades de planificación. Este documento
también identifica los puntos de control en los que
se realizarán revisiones de hitos para evaluar la
calidad del proyecto y sus resultados.
 Documentar la estructura organizativa del
proyecto, asegurándose de que todos los
[Date]
31
Consideraciones
Ocupaciones
miembros del equipo comprendan sus funciones
para hacer que el proyecto sea un éxito,
aclarando líneas de información y toma de
decisiones y proporcionando a los principales
interesados la oportunidad de asegurar que la
estructura organizativa del proyecto trabajo (la
función del proyecto).
Proceso 2: Escribir el Documento de Visión /

Alcance
En este proceso, el equipo del proyecto escribe el documento de visión / alcance y realiza una
evaluación de riesgos.
Figura 5. Escriba el documento de visión / alcance
Actividades: Escriba el Documento de Visión / Alcance
Durante este proceso, el equipo del proyecto completa el primer borrador del documento de visión /
alcance y lo distribuye al equipo, los clientes y las partes interesadas para su revisión. Durante el
proceso de revisión, el documento experimenta múltiples iteraciones de retroalimentación, discusión
[Date]
32
y cambio.
El documento de visión / alcance suele escribirse en un nivel estratégico de detalle y el equipo del
proyecto lo utiliza durante la planificación como contexto para desarrollar especificaciones técnicas y
planes de gestión de proyectos en mayor detalle. Proporciona una dirección clara para el equipo del
proyecto; describe las metas, prioridades y limitaciones explícitas del proyecto; y establece las
expectativas de los clientes.
La visión del proyecto y el alcance del proyecto son conceptos distintos, y los proyectos exitosos
requieren ambos. La visión del proyecto es una visión ilimitada de la solución. El alcance del
proyecto identifica las partes de la visión que un equipo de proyecto puede lograr dentro de sus
limitaciones. El documento de visión / alcance define ambos conceptos.
Otra actividad clave de este proceso es que el equipo evalúe y documente los riesgos del proyecto.
Esto se hace usando la Plantilla de Riesgo.
La siguiente tabla enumera las actividades involucradas en este proceso. Estas actividades
incluyen:
 Escribir el documento de visión / alcance.

 Evaluar y documentar los riesgos del proyecto.
Cuadro 5. Actividades y consideraciones para la redacción de la visión / documento de

alcance
Consideraciones
Ocupaciones
Escribir el Preguntas clave:
documento de visión
/ alcance  ¿Tiene el cliente una visión clara del proyecto?
 ¿Cuáles son los objetivos de negocio que el proyecto está tratando de
lograr?
 ¿Qué restricciones (tiempo o recursos) deben ser colocadas en la
visión?
 ¿El equipo del proyecto entiende los perfiles de los usuarios de la
solución?
 ¿La organización tiene estándares de documentación para proyectos
similares?
 ¿Tiene la organización un proceso de control de cambios? Para
obtener información sobre el control de cambios, consulte SMF de
cambio y configuración .
Entradas:
 Documento de estructura del proyecto

 Requisitos de fiabilidad (Consulte Fiabilidad SMF )
 Requisitos de política (Consulte Fiabilidad SMF )
Salidas:
[Date]
33
Consideraciones
Ocupaciones
 Documento de visión / alcance, que incluye:

 Oportunidad de negocio.
 Concepto de soluciones.
 Alcance.
 Estrategias de diseño de soluciones.
Preguntas clave:
 ¿Puede el equipo del proyecto identificar los riesgos conocidos para

el proyecto?
 ¿Cómo se puede estimar la probabilidad de cada riesgo?
 ¿Puede el equipo estimar el impacto de cada riesgo si se manifiesta?
Entradas:
 Ninguna
Evaluar y Salidas:
documentar los
riesgos del proyecto  Evaluación de riesgos utilizando la Plantilla de Riesgo
Mejores prácticas:
 Planificar y anticipar riesgos para evitar sorpresas que tengan un

impacto negativo.
 Si el equipo utiliza una escala numérica para evaluar la probabilidad y
el impacto de un riesgo, puede comparar la gravedad de cada riesgo
multiplicando los dos números. Para obtener más información sobre la
administración de riesgos, vea el SMF de Gobernabilidad, Riesgo y
Cumplimiento .
Proceso 3: Aprobar el Documento de Visión /

Alcance
Finalmente, el equipo del proyecto obtiene la aprobación del cliente y de las partes interesadas y
luego completa el informe de revisión del hito.
[Date]
34
Figura 6. Aprobar el documento de visión / alcance
Actividades: Aprobar el Documento de Visión / Alcance
Durante este proceso, el equipo completa el informe de revisión de hitos para el Hito Aprobado por
Visión / Alcance. El equipo, los clientes y las partes interesadas firman este informe para indicar su
aprobación del documento de visión / alcance. Signoff también indica que el equipo, los clientes y
las partes interesadas están de acuerdo en que el equipo del proyecto ha cumplido con los
requisitos para completar el hito de Visión / Alcance Aprobado y que el proyecto está listo para
proceder a la planificación.
Tabla 6. Actividades y Consideraciones para Aprobar la Visión / Documento de Alcance
Consideraciones
Ocupaciones
Firme en el reporte de revisión del Preguntas clave:
hito para el hito aprobado por
Visión / Alcance  ¿El equipo, los clientes y las partes interesadas están
de acuerdo con la visión?
 ¿El equipo, los clientes y las partes interesadas están
de acuerdo en el alcance del proyecto?
 ¿El equipo del proyecto ha cumplido con los
requisitos del hito de Visión / Alcance Aprobado?
Entradas:
 Documento de visión / alcance
[Date]
35
 Evaluación de riesgos (Plantilla de riesgos)
Salidas:
 Documento del informe de revisión del hito

 Mejores prácticas:
 Realizar una reunión de cierre para presentar el
documento de visión / alcance con el fin de:
 Asegurar la comprensión correcta del
problema / oportunidad.
 Asegúrese de que el cliente (o el destinatario
del servicio) tiene una imagen clara y una vista
previa de la solución.
 Confirme el alcance.
 Comunicar cualquier punto destacado (riesgos y
problemas).
Conclusión
Envision SMF describe el proceso para formar un equipo de proyecto central, preparando y
entregando un documento de visión / alcance que comunique claramente la visión del proyecto y el
alcance de esa visión, y la preparación de una evaluación de riesgos.
Los principales procesos de Envision descritos por el SMF son:

Realimentación
Función de gestión de servicios de

Ȁlanificación de proyectos
Posición del SMF de planificación de proyectos dentro del ciclo de vida del
servicio de TI de MOF
[Date]
36
El SMF de planificación de proyectos pertenece a la fase Deliver del ciclo de vida del servicio de TI
de MOF. La siguiente figura muestra el lugar del SMF de planificación de proyectos en la fase
Deliver, así como la ubicación de la fase Deliver dentro del ciclo de vida del servicio de TI.
Figura 1. Posición del SMF de planificación de proyectos dentro del ciclo de vida del servicio
de TI
¿Por qué utilizar el SMF de planificación de proyectos?
El SMF de planificación de proyectos debe ser útil para cualquier persona que tenga la función
principal en la planificación de un proyecto de servicio de TI, incluida la preparación de la
especificación funcional y el diseño de la solución y la preparación de planes de trabajo,
estimaciones de costos y programaciones.
Este SMF aborda las siguientes acciones de planificación de proyectos de servicios de TI:
 Evaluar productos y tecnologías.

 Escriba la especificación funcional.
[Date]
37
Visión Describe los objetivos fundamentales de la solución .
 Empaque el plan maestro del proyecto.
 Cree la planificación maestra.
 Revise los Hitos Aprobados de los Planes de Proyecto.
Descripción general de la administración de

servicios de planificación de proyectos
[Date]
38
Flujo de Gestión de Planificación de Proyectos
La Figura 2 ilustra el flujo del proceso para la gestión de la planificación del proyecto. Este flujo
consiste en los siguientes procesos:
 Evaluar productos y tecnologías.

 Escriba la especificación funcional.
 Empaque el plan maestro del proyecto.
 Cree la planificación maestra.
 Revisar los Planes de Proyecto Aprobados MR.
Figura 2. Flujo del proceso de gestión del plan del proyecto
[Date]
39
Proceso 1: Evaluar productos y tecnologías
El primer proceso en la planificación de proyectos es que el equipo del proyecto cree una línea de
base del cliente y evalúe los productos y tecnologías que está considerando usar.
Figura 3. Evaluación de productos y tecnologías
Actividades: Evaluar productos y tecnologías
Durante este proceso, el equipo del proyecto evalúa los productos y tecnologías que está
considerando utilizar para construir o implementar la solución. Los miembros del equipo con roles
de desarrollo y prueba realizan la evaluación para asegurar que los productos y tecnologías bajo
consideración funcionan de acuerdo con las especificaciones del proveedor y cumplen con los
requisitos del proyecto. Este esfuerzo eventualmente produce una prueba de concepto y finalmente
evoluciona hacia el desarrollo de la solución.
El equipo del proyecto también debe basar el entorno del cliente durante este proceso. Este es el
proceso de auditoría del entorno de producción del cliente para crear un inventario que incluya
configuraciones de servidor, componentes de red, aplicaciones y todo el hardware relevante. La
línea de base del cliente es útil para escribir la especificación funcional y es necesaria para construir
el laboratorio de desarrollo y pruebas.
La siguiente tabla enumera las actividades involucradas en este proceso. Éstas incluyen:
 Creación de una línea de base del cliente.
[Date]
40
Proceso 4: Creación del programa maestro
 Evaluación de productos y tecnologías.
Tabla 4. Actividades y consideraciones para la evaluación de productos y tecnologías
Consideraciones
Ocupaciones
Preguntas clave:
 ¿Ha documentado la organización la topología de la red?

 ¿Tiene la organización un inventario de activos? Para obtener más
información al respecto, consulte SMF de Business / IT Alignment y
SMF de cambio y configuración .
 ¿Está disponible una infraestructura de administración de sistemas que
el equipo del proyecto puede usar para crear un inventario de activos?
Crear una línea de
base de cliente
Entradas:
Información del sistema
Salidas:
 Línea de base del cliente (inventario)
Preguntas clave:
 ¿El equipo del proyecto ha identificado productos y tecnologías que

podrían ajustarse a la visión y alcance del proyecto?
 ¿El equipo tiene el requisito de usar productos o tecnologías
específicos?
 ¿El equipo del proyecto ya está familiarizado con algunos de los
productos y tecnologías que van a utilizar en este proyecto?
Entradas:
 Documento de visión / alcance

Evaluar productos
y tecnologías
Salidas:
 Evaluación de productos y tecnologías

 Utilice prototipos. El prototipado permite pre-desarrollo de pruebas
desde muchas perspectivas, especialmente la usabilidad, y ayuda a
crear una mejor comprensión de la interacción del usuario. También
conduce a especificaciones de producto mejoradas.
 Considerar la agilidad y la interoperabilidad con las herramientas y
tecnologías existentes.
 Tenga en cuenta los requisitos de gestión y fiabilidad.
Proceso 2: Escribir la especificación funcional

[Date]
41
Consideraciones
Ocupaciones
 ¿Cómo influye la filosofía de gestión elegida en la programación?
Entradas:
 Plan maestro del proyecto

 Horarios detallados
Salidas:
 Programa maestro
Mejores prácticas:
 Establezca horarios fijos. Los límites de tiempo internos (time-boxing)

mantienen al equipo del proyecto enfocado en priorizar características y
actividades.
 Utilizar la programación de abajo hacia arriba. Las estimaciones para los
proyectos de TI deben ser hechas por aquellos que harán el trabajo. La
estimación ascendente proporciona una mayor exactitud, rendición de
cuentas y empoderamiento del equipo. El resultado es un programa que
es totalmente apoyado por todo el equipo del proyecto.
 Priorizar mediante el uso de programación basada en el riesgo. La
evaluación del riesgo por el equipo identifica qué características son más
riesgosas. Los problemas que requieren cambios importantes en la
arquitectura se pueden manejar con anterioridad en el proyecto,
minimizando así el impacto en el calendario y el presupuesto.
 Añada tiempo de búfer a los calendarios del proyecto para permitir que el
equipo se adapte a los problemas y cambios inesperados. La cantidad de
tampón a aplicar depende de la cantidad de riesgo. Al evaluar los riesgos
al inicio del proyecto, los riesgos más probables pueden ser evaluados
por su impacto en el programa y compensados mediante la adición de
tiempo de amortiguación al calendario del proyecto.
Proceso 5: Revisar el hito aprobado por los

planes del proyecto
En este proceso final, el equipo del proyecto, los clientes y las partes interesadas firman el informe
de revisión de hitos para el hito aprobado por los planes del proyecto, que también es una revisión
de la gestión del MOF.
[Date]
42
Figura 7. Revisar el Hito Aprobado de los Planes de Proyecto
Actividades: Revisar los Hitos Aprobados de los Planes de Proyecto
Antes de este proceso, el equipo, los clientes y las partes interesadas han revisado la
especificación funcional, el plan maestro del proyecto y el calendario del proyecto maestro. Han
acordado que se han cumplido todos los hitos intermedios, que las fechas de vencimiento son
realistas y que los proyectos, funciones y responsabilidades están bien definidos. También están de
acuerdo en que existen mecanismos para abordar los riesgos del proyecto.
Después de que el equipo apruebe las especificaciones, los planes y las programaciones, los
documentos se convierten en la línea de base del proyecto. La línea de base toma en cuenta las
diversas decisiones que se alcanzan por consenso aplicando las tres variables de planificación del
proyecto: recursos, programación y características. Una vez que el equipo define una línea base, se
coloca bajo control de cambio. Esto no significa que todas las decisiones alcanzadas en la fase de
planificación sean definitivas. Pero significa que a medida que el trabajo avanza en la fase de
desarrollo, el equipo debe revisar y aprobar cualquier cambio sugerido a la línea de base.
Después de aprobar los planes del proyecto, el equipo está listo para pasar al desarrollo de la
solución.
Cuadro 8. Actividades y consideraciones para la revisión de los planes del proyecto Hito
aprobado
[Date]
43
[Date]
44
compilación
Posición de la estructura SMF dentro del ciclo de vida del servicio de TI de MOF
El Build SMF pertenece a la fase Deliver del ciclo de vida del servicio de TI de MOF. La siguiente
figura muestra el lugar del SMF de Build dentro de la fase Deliver, así como la ubicación de la fase
Deliver dentro del ciclo de vida del servicio de TI.
Figura 1. Posición de la estructura SMF dentro del ciclo de vida del servicio de TI
¿Por qué usar el SMF de compilación?
Este SMF debe ser útil para cualquier persona que esté involucrada con un equipo de proyecto
[Date]
45
encargado del desarrollo real de una solución de servicios de TI, con la creación de un laboratorio
de desarrollo y prueba o con la preparación de una solución de servicio de TI para la
implementación piloto.
 Prepárate para el desarrollo.

 Construir la solución de servicios de TI.
 Prepárese para liberar la solución.
 Cumplir con los requisitos para el hito completo Scope.
Función de administración de servicios de

generación
La gestión de compilación es el proceso de desarrollo de componentes de solución: el código para

cualquier aplicación interna o solución de infraestructura y la documentación que crean los
desarrolladores, así como la infraestructura que los soporta. Todos los roles del equipo participan
en la construcción y pruebas internas de los entregables. El propósito de Build SMF es ayudar a las
organizaciones de TI a crear con éxito componentes de soluciones. El Build SMF corresponde a la
fase de desarrollo en el modelo de proceso de Microsoft Solutions Framework (MSF).
Building sigue la parte de planificación del proyecto de la fase Deliver y culmina en el Hito Completo
del Alcance. En Scope Complete Milestone, todas las funciones están completas y la solución está
lista para pruebas y estabilización externas. Este hito es la oportunidad para que los clientes, los
usuarios, las operaciones y el personal de soporte y los principales interesados en el proyecto
evalúen la solución e identifiquen cualquier problema que deba resolverse antes de lanzar la
solución a la producción.
Generar tipos de funciones SMF
La responsabilidad primordial del equipo que se aplica a Build SMF es la Responsabilidad de la

Solución. Los tipos de rol dentro de esa responsabilidad y sus actividades principales dentro de
este SMF se muestran en la siguiente tabla.
Cuadro 1. Responsabilidad del proyecto y sus tipos de función de asistente

Tipo de rol
Gerente de  Función responsable  Supervisión continua
soluciones  Posee todas las SMFs en esta
responsabilidad
 Actua como director de
proyectos para todos los
proyectos
[Date]
46
proyectos
 Controla el diseño, la  Asegura mapas de

Director del programación y los recursos a especificaciones a lo que se está
programa nivel de proyecto construyendo
 Construye la solución  Prepara para el desarrollo

Desarrollador acordada  Desarrolla la solución
 Pruebas para determinar con  Se prepara para probar la

precisión el estado del solución
Ensayador
desarrollo de la solución  Prueba la solución
 Actúa como defensor del

cliente
 Ayuda a conducir la visión de  Gestión continua de las
Gerente de
proyecto compartida expectativas de los clientes
producto
 Gestiona las expectativas de
los clientes

usuario en los equipos de
 Revisa la especificación de la
proyecto
solución para asegurar que cumple
 Ayuda a definir los requisitos
Experiencia de con las necesidades del usuario
del usuario
usuario final
 Ayuda a diseñar para
 Crea documentación de usuario
satisfacer las necesidades del
usuario
 Evalúa el diseño de la solución

operaciones para asegurar que
 Crea lista de comprobación de
se cumplan con el diseño
Gestión de la implementación y preparación del
 Crea un piloto, plan de
liberación sitio
del sitio
 Defensores de operaciones en
el equipo del proyecto
 Requiere expertos en  Revisa la especificación de la
operaciones según sea solución para asegurar que cumple
Experiencia en
necesario para obtener con los requisitos de las
Operaciones
información detallada operaciones
liberación
[Date]
47
 Desarrolla estrategias y planes
Gerente de de pruebas  Supervisión continua
Pruebas  Garantiza la utilización de
métodos de prueba de las
mejores prácticas
Objetivos del edificio
Los objetivos principales del proceso de construcción son desarrollar los productos de la solución
según las especificaciones del cliente, desarrollar la documentación de la solución, crear el
laboratorio de desarrollo y prueba y preparar la solución para la implementación piloto.
El tipo de rol Developer es el principal responsable de este objetivo, pero todos los roles participan
en la creación de la solución. Para lograr este objetivo, Development proporciona soluciones de
bajo nivel y diseño de funciones, estima el esfuerzo para entregar ese diseño y construye la
solución. Además, Development presta servicios a todo el equipo como consultor de tecnología,
validando las decisiones técnicas y mitigando los riesgos de desarrollo. La Tabla 2 muestra los
resultados deseados de los objetivos de Build SMF y enumera las medidas que puede usar para
medir con qué éxito ha logrado estos objetivos después de completar este SMF.
Cuadro 2. Resultados y Medidas de la Construcción SMF Objetivos
Medidas
Resultados
 Número de errores no resueltos o
diferidos
Una solución entregada al cliente libre de defectos  Signoff en el Alcance Hito
Completo
 Número de solicitudes de cambio

de diseño presentadas
 Número de errores presentados
Una solución que cumple con las especificaciones del
para implementación incorrecta
cliente como se describe en la especificación funcional
 Signoff en el Alcance Hito
Completo
 Fecha en que se aprobó el hito

Una solución entregada al cliente dentro del
completo del ámbito
cronograma especificado del cronograma
Términos clave
[Date]
48
Definición
Término
Una línea de base es un estado conocido por el cual algo se mide o compara.
Base Baselining está colocando algo bajo control de cambio. Las líneas de base
permiten gestionar el cambio en proyectos complejos.
Los miembros del equipo que representan cada función generan estimaciones
Programación de
de tiempo y programaciones para los entregables. El horario de cada equipo
abajo hacia arriba
está integrado en un programa maestro del proyecto.
El diseño conceptual implica entender los requisitos del negocio y definir las
características que los usuarios necesitan para hacer su trabajo. Product
Diseño conceptual Management toma la delantera en la creación del diseño conceptual, que
comienza durante la visualización y continúa a través de la planificación del
proyecto.
Cliente La persona u organización que comisiona y financia el proyecto.
Un indicador de progreso temprano que segmenta grandes esfuerzos de
trabajo en porciones manejables. La fase de entrega sugiere un conjunto de
Hito intermedio
hitos intermedios, pero los equipos de proyecto deben definir hitos intermedios
que tengan sentido para sus proyectos.
El diseño lógico utiliza el diseño conceptual y el estado actual de la
Diseño lógico
infraestructura tecnológica para definir la nueva arquitectura a un nivel alto.
Un punto de sincronización de proyecto. Los hitos principales marcan la
transición de los proyectos de una fase a la siguiente. También transfieren la
Hito
responsabilidad primaria de una función a otra. Los SMF de la fase de entrega
corresponden a los principales hitos de MSF.
El diseño físico entra en mayor detalle sobre la arquitectura deseada que el
diseño lógico y define las configuraciones de hardware y los productos de
Diseño físico software que se utilizarán. Como regla general, el diseño de la solución debe
contener suficiente detalle para permitir al equipo comenzar a trabajar en el
plan del proyecto.
Una visión de la visión del proyecto limitada por limitaciones como tiempo y
recursos. El ámbito de la solución describe las características y entregables
Alcance
de la solución. El alcance del proyecto describe el trabajo a realizar por el
equipo.
Una entrega coordinada de tecnologías, documentación, capacitación y
soporte diseñados para responder con éxito a un problema comercial único del
Solución
cliente. Las soluciones suelen combinar personas, procesos y tecnología para
resolver problemas.
Individuos o grupos con interés en el resultado del proyecto, aunque sus
objetivos y prioridades no siempre son idénticos a los del cliente. Ejemplos de
Tenedor de
partes interesadas son los directores departamentales que se verán afectados
apuestas
por la solución, el personal de TI responsable de ejecutar y apoyar la solución
y los administradores funcionales que aportan recursos al equipo del proyecto.
Caso de uso Describe una tarea individual realizada en un escenario de uso.
Describe una actividad particular que un usuario intenta realizar, como
Escenario de uso
procesar una transacción o verificar el correo electrónico.
Visión Describe los objetivos fundamentales de la solución.
[Date]
49
Crear flujo de proceso
La figura 2 ilustra el flujo de proceso para la construcción. Este flujo consiste en los siguientes
procesos:
 Prepararse para el desarrollo.

 Desarrollar la solución.
 Prepárese para la liberación.
 Revise el hito completo de Scope y firme el informe de revisión de hitos.
[Date]
50
Figura 2. Generar flujo de proceso
Proceso 1: Preparación para el desarrollo

[Date]
51
El primer proceso para construir la solución es que el equipo del proyecto se prepare para
desarrollar la solución.
Figura 3. Preparación para el desarrollo
Actividades: Prepararse para el Desarrollo
El desarrollo comienza con la preparación. El equipo del proyecto necesita establecer un

laboratorio de desarrollo y prueba, crear procedimientos de seguimiento de problemas y comenzar
los preparativos de la prueba.
La primera parte de la preparación para el desarrollo es la preparación de un laboratorio de

desarrollo y prueba. Aunque los equipos pueden crear laboratorios individuales, crear un laboratorio
compartido con áreas de trabajo individuales es más propicio para el trabajo en equipo necesario
para ofrecer soluciones complejas.
Un entorno de laboratorio de trabajo permite el desarrollo aislado y la prueba de la solución para

que no tenga ningún impacto en los sistemas de producción. El equipo desarrolla componentes de
infraestructura en el laboratorio, incluyendo configuraciones de servidor, herramientas de
automatización de despliegue y hardware relacionado. La configuración de servidores de desarrollo
separados que los desarrolladores pueden utilizar de forma aislada es una práctica recomendada.
[Date]
52
Es importante que todo el equipo entienda que lo que está en los servidores de laboratorio puede
volverse inestable y requerir reinstalación.
Si la organización aún no tiene un ambiente de laboratorio en su lugar, el equipo del proyecto debe
construir uno. El laboratorio de desarrollo y prueba debe simular el entorno de producción lo más
cerca posible sin interactuar con él. Aunque esto puede ser costoso, es crucial. De lo contrario, los
errores pueden pasar desapercibidos hasta que la solución se despliegue en el entorno de
producción. Las organizaciones pueden aprovechar la información contenida en el sistema de
gestión de configuración de la organización (CMS) como inventario para replicar el entorno de
producción.
El equipo también debe preparar procedimientos para el seguimiento de las cuestiones y sus
resoluciones. Estos procedimientos no sólo proporcionan información de seguimiento y de estado,
sino que también contienen información que las operaciones y el soporte encontrarán de valor
incalculable después de implementar la solución.
Después de que el laboratorio y los procedimientos de seguimiento de problemas estén en su lugar,

el equipo puede comenzar los preparativos de la prueba: Esto incluye revisar la especificación
funcional, preparar casos de prueba y preparar escenarios de prueba.
El equipo del proyecto no debe esperar hasta que finalice la planificación del proyecto antes de
comenzar este paso. El equipo debe establecer las estaciones de trabajo, servidores y
herramientas de desarrollo del entorno de laboratorio, ya que los planes se están finalizando y
revisando para evitar retrasar el inicio de la fase de construcción. También debe establecerse un
sistema de respaldo. Por lo tanto, este paso de construcción traslapa los procesos finales de la
planificación del proyecto.
 Preparación del laboratorio de desarrollo.

 Creación de procedimientos de seguimiento de problemas.
 Preparación para probar la solución.
Cuadro 4. Actividades y consideraciones para la preparación para el desarrollo
Consideraciones
Ocupaciones
Preparar el laboratorio Preguntas clave:
de desarrollo
 ¿Pueden los roles del equipo compartir un laboratorio común?
Recuerde, la prueba debe ser separada.
 ¿Hay equipo disponible para construir un laboratorio para simular
el entorno de producción?
 ¿La Administración de versiones entiende el entorno actual y
planificado lo suficientemente bien como para replicarlo en el
entorno del laboratorio?
 ¿Es necesario un inventario del hardware en el entorno de
producción?
 ¿Es necesario un inventario de las aplicaciones en el entorno de
[Date]
53
[Date]
54
Consideraciones
Ocupaciones
 Políticas y procedimientos de seguimiento de emisiones
(documento de pruebas y de informes)
Mejores prácticas:
 Resolver todos los problemas conocidos, si las resoluciones son

correcciones o aplazamientos.
 Defina y comunique los estándares de prioridad de emisión y
severidad a todos los miembros del equipo, incluyendo Desarrollo,
Prueba y Experiencia del usuario.
 Entregar la base de datos de emisión a la formación y al personal
de apoyo para proporcionar una visión más profunda de la historia
de la solución y los problemas encontrados en el desarrollo.
 Programar reuniones periódicas con los responsables del
desarrollo y las pruebas para revisar las cuestiones y planificar
estrategias para resolverlas.
Preguntas clave:
 ¿Tiene prueba el entrenamiento formal de la prueba?

 ¿Tienen experiencia usando metodologías de prueba formales,
procesos y prácticas (por ejemplo, caja blanca, caja negra y
prueba de caja gris)?
 ¿Prueba tiene experiencia escribiendo casos de prueba y
escenarios de prueba?
 ¿Está el software de prueba automatizado disponible para la
función de prueba?
Entradas:
 Plan maestro del proyecto, incluyendo:

Prepararse para probar  Plan de Desarrollo.
la solución  Plan de prueba.
 Especificacion funcional.
Salidas:
 Casos de prueba y escenarios
Mejores prácticas:
 Utilice software de prueba automatizado para asegurar la

repetibilidad.
 Empiece a probar tempranamente revisando la especificación
funcional y los planes de desarrollo para detectar errores y fallas
que puedan ocurrir en los productos de la solución.
[Date]
55
Proceso 2: Desarrollar la solución
En este proceso, Development desarrolla la solución, User Experience escribe la documentación y

Test revisa las compilaciones.
[Date]
56
Figura 4. Desarrollar la solución
Actividades: Desarrollar la Solución
[Date]
57
La principal actividad que ocurre durante este proceso es el desarrollo de los entregables, de los
que el desarrollo es el principal responsable.
Además, User Experience desarrolla documentación de usuario e IT durante este proceso. En

muchos casos, la documentación es la parte clave de la solución. Esto es particularmente cierto
cuando se construyen soluciones de infraestructura.
Prueba revisa cada compilación provisional de la solución, incluido el código y la documentación, y

registra los problemas en la base de datos de seguimiento de problemas. El proceso de desarrollo
no es lineal, sino iterativo que se basa en la creación de compilaciones provisionales. Al crear y
probar construcciones provisionales, el equipo puede encontrar y solucionar soluciones antes en el
proceso de desarrollo, antes de que esos problemas se conviertan en problemas importantes.
Debido a que el proceso de desarrollo se centra en el desarrollo de la solución, el proyecto necesita

hitos intermedios que pueden ayudar al equipo a medir el progreso de la construcción. El desarrollo
de los componentes de la solución se realiza en paralelo y en segmentos, por lo que el equipo
necesita una forma de medir el progreso en su conjunto. Las compilaciones internas logran esto
forzando al equipo a sincronizar componentes a nivel de solución. El número y la frecuencia de las
compilaciones depende del tamaño y la duración del proyecto. En la mayoría de los casos, tiene
sentido establecer hitos intermedios para completar el diseño de la interfaz de usuario y el esquema
de la base de datos, ya que hay muchas dependencias en ellos, por ejemplo, Experiencia de usuario
que necesita capturas de pantalla para la documentación.
 Desarrollar los productos de la solución.

 Desarrollo de la documentación de la solución.
 Comprobación de la solución.
Cuadro 5. Actividades y consideraciones para desarrollar la solución
Consideraciones
Ocupaciones
Desarrollar los Preguntas clave:
productos de la
solución  ¿Es este proyecto una continuación de una versión anterior?
 ¿Los desarrolladores necesitan capacitación para las herramientas
que usarán?
 ¿Existe un sistema de control de cambios para el seguimiento de
versiones?
 ¿El equipo del proyecto tiene un enfoque claro para manejar las
compensaciones (características comerciales para el horario,
rendimiento de las funciones, etc.)?
 ¿Comprende el desarrollo los impulsores del negocio y de la
tecnología?
 ¿El desarrollo tiene objetivos de diseño claros, como el diseño para la
seguridad, el diseño para la interoperabilidad, y así sucesivamente?
 ¿Qué pautas y estándares, como las normas de nomenclatura, deben
seguir al desarrollar el código de la solución?
[Date]
58
Consideraciones
Ocupaciones
 ¿Tiene el equipo del proyecto un sistema de control de versiones?
 ¿El equipo del proyecto tiene un proceso de construcción
automatizado y diario?
 ¿Qué componentes de terceros y herramientas de desarrollo utilizará
el equipo?
Entradas:
 Especificacion funcional
 Plan maestro del proyecto, incluyendo el plan de desarrollo
 Laboratorio de desarrollo y pruebas
Salidas:
 Creación de soluciones provisionales

 Entregas de soluciones, incluyendo:
 Notas de la versión.
 Código y archivos ejecutables.
 Documentación de configuración.
Mejores prácticas:
 El axioma mide una vez, corta dos veces; medir dos veces, cortar
una vez se aplica al desarrollo. Una planificación y un diseño
minuciosos conducen a un desarrollo más sencillo.
Desarrollar la Preguntas clave:

documentación de la
solución  ¿Es este proyecto una continuación de una versión anterior?
 ¿Está disponible un sistema de gestión de contenidos?
 ¿La experiencia del usuario reutilizará los documentos existentes o
comenzará desde cero?
 ¿La experiencia del usuario entiende completamente la tecnología
que se está desarrollando?
 ¿Comprende la experiencia del usuario los controladores
empresariales y tecnológicos?
 ¿La experiencia del usuario tiene objetivos de diseño claros para la
documentación, como la legibilidad, accesibilidad o portabilidad?
 ¿Qué pautas y estándares, como directrices editoriales o de estilo,
deben seguir la experiencia del usuario al desarrollar la
documentación de la solución?
Entradas:
 Plan maestro del proyecto
[Date]
59
Consideraciones
Ocupaciones
Salidas:
 Construcciones provisionales de documentación

 Documentación del usuario
 Documentación de operaciones
Mejores prácticas:
 Describir la documentación y obtener la aprobación de los interesados

antes de escribir.
 Utilice software colaborativo, como Microsoft® Groove®, para
garantizar la participación activa y las revisiones de la documentación.
 Programe reuniones regulares con Development and Test para
demostraciones y revisiones.
Pruebe la solución Preguntas clave:
 ¿Está preparado el laboratorio de pruebas?

 ¿Se han refinado el plan de prueba, los escenarios de prueba y los
casos de prueba?
 ¿El equipo de prueba ha capturado concienzudamente el documento
de visión / alcance y la especificación funcional en los escenarios de
prueba y casos de prueba?
 ¿Se está ejecutando un proceso de compilación diario que da código
de prueba fresca cada día?
 ¿La base de datos de seguimiento de problemas es lo
suficientemente dinámica como para permitir un desarrollo ágil? Por
ejemplo, ¿está disponible un sistema de notificación que puede alertar
al equipo del proyecto cuando se agregan nuevos bugs a la base de
datos de seguimiento de problemas o cuando cambia su estado?
 ¿El equipo del proyecto lleva adelante errores de una versión
anterior?
Entradas:
 Plan maestro del proyecto, incluyendo el plan de pruebas
 Laboratorio de desarrollo y pruebas
 Documentación provisional
 Escenarios de prueba y casos de prueba
 Políticas y procedimientos de seguimiento de emisiones
Salidas:
 Base de datos de seguimiento de problemas actualizada
[Date]
60
Consideraciones
Ocupaciones
Mejores prácticas:
 Utilice la virtualización para minimizar el hardware físico necesario

para probar.
 Si no está disponible un sistema formal de seguimiento de problemas,
cree un sistema de seguimiento de problemas utilizando un producto
como Microsoft SharePoint® Team Services.
 Cree un programa de laboratorio para evitar conflictos.
Proceso 3: Preparación para la liberación
En este proceso, el equipo del proyecto comienza a crear documentación de implementación y

capacitación.
[Date]
61
Figura 5. Preparación para la liberación
Actividades: Prepárese para el lanzamiento
Durante el proceso de preparación de la versión, el equipo comienza a desarrollar contenido y

procedimientos para implementar la solución en el entorno de producción. La primera actividad es
crear contenido de implementación. Esto incluye actualizar el plan maestro, incluido el plan de
despliegue. La segunda actividad es comenzar a desarrollar contenido de capacitación para los
usuarios que interactuarán con la solución y para los miembros del personal de TI que
implementarán, operarán y darán soporte a la solución.
 Preparación para el despliegue.
[Date]
62
 Preparación de contenidos de capacitación.
Tabla 6. Actividades y Consideraciones para Prepararse para la Liberación
Consideraciones
Ocupaciones
Preguntas clave:
 ¿El equipo entiende la topología del entorno de producción?

 ¿El equipo ha elegido un grupo piloto para la solución?
 ¿Hay un proceso de retroalimentación disponible para una prueba
piloto?
 ¿Tiene el equipo experiencia en implementar soluciones similares?
 ¿Está el equipo utilizando la infraestructura existente o desplegando
nueva?
 ¿El desarrollo y la experiencia del usuario documentan los procesos
de preparación, instalación, capacitación y estabilización?
Entradas:
Preparar el  Plan Piloto.
despliegue  Plan de empleo.
 Línea de base del cliente, incluyendo:
 Diagramas de topología del entorno de producción.
 Datos de inventario de hardware y software.
Salidas:
 Plan maestro del proyecto actualizado, incluyendo:

 Plan Piloto.
 Plan de empleo.
 Infraestructura de implementación, incluyendo hardware y
software.
Mejores prácticas:
 Asegúrese de que la línea de base del cliente sea precisa y actual.
Preparar contenido Preguntas clave:

de capacitación
 ¿Están familiarizados los usuarios con la tecnología que se está
desplegando?
 ¿El personal de TI está generalmente familiarizado con la tecnología
que se está implementando?
 ¿La solución afectará significativamente a cómo los empleados
realizan sus trabajos?
 ¿Los usuarios deben entender todas las características de la
solución o sólo una parte de ellas?
[Date]
63
Consideraciones
Ocupaciones
 ¿Cuál es el estado de ánimo general en la organización sobre el
cambio?
 ¿Se comunica regularmente con los usuarios sobre sus iniciativas?
 ¿Qué medios están disponibles para comunicarse con los usuarios?
Entradas:

 Construcciones provisionales de documentación
 Plan de entrenamiento.
 Plan de comunicaciones.
Salidas:
 Plan maestro del proyecto actualizado, incluyendo:

 Contenido de entrenamiento.
Mejores prácticas:
 Asegúrese de que cada grupo de la organización afectada por la

solución obtiene la información que necesita sin sobrecargarla con
demasiada información.
Proceso 4: Revisar el hito completo del ámbito
En este proceso final, se revisa el Hito Completo de Scope.
[Date]
64
Figura 6. Revise el hito completo del ámbito
Actividades: Repase el marco completo del alcance
Para completar este proceso, el equipo del proyecto, los clientes y las partes interesadas revisan el
hito completo de Scope. Están de acuerdo en que el equipo ha cumplido todos los hitos intermedios
y que se ha desarrollado el alcance completo de la solución tal como se define en la especificación
funcional. Después de revisar y aprobar el Hito Completo de Scope, el equipo del proyecto está listo
para pasar a la estabilización.
Tabla 7. Actividades y consideraciones para revisar el alcance Hito completo
Consideraciones
Ocupaciones
Firmar el informe de revisión Preguntas clave:
de hitos para el hito completo
[Date]
65
 ¿El equipo del proyecto, los clientes y las partes interesadas
han revisado las entregas de la solución, incluyendo el
código, la infraestructura y la documentación?
 ¿El equipo del proyecto, el cliente y las partes interesadas
están de acuerdo en que el equipo del proyecto ha cumplido
con los requisitos de Scope Complete Milestone?
Entradas:
 Entregas de soluciones, incluyendo:

 Notas de la versión.
 Código y archivos ejecutables.
 Documentación de configuración.
 Documentación, incluyendo:
 Documentación del usuario.
 Documentación de operaciones.
de Scope
 Plan maestro actualizado, incluyendo:
 Plan Piloto.
 Plan de empleo.
 Infraestructura de implementación, incluyendo hardware y
software
Salidas:

 Asegurar la alineación con la política de liberación de la
organización en términos de:
 Liberar contenido.
 Numeración de la versión.
 Libere la documentación.
 Plan de lanzamiento para esta compilación en particular.
Conclusión
Build SMF describe el proceso para desarrollar los componentes de la solución para un servicio de
TI. Estos componentes incluyen el código y la documentación que crean los desarrolladores y la
infraestructura que los soporta. El SMF también describe cómo crear el laboratorio de desarrollo y
prueba y preparar la solución para el despliegue piloto.
Los principales procesos de construcción descritos por el SMF son:
 Prepararse para el desarrollo.

 Desarrollar la solución.
 Prepárese para la liberación.
[Date]
66
 Revise el Hito Completo de Scope y firme en el reporte de revisión de hitos.
Realimentación
Estabilizar la función de administración de

servicios
Posición del SMF de estabilización dentro del ciclo de vida del servicio TI de MOF
El Stabilize SMF pertenece a la fase Deliver del ciclo de vida del servicio de TI de MOF. La
siguiente figura muestra el lugar del SMF de estabilización dentro de la fase de entrega, así como la
ubicación de la fase de entrega dentro del ciclo de vida del servicio de TI.
Figura 1. Posición del Stabilize SMF dentro del ciclo de vida del servicio de TI
[Date]
67
¿Por qué usar el Stabilize SMF?
Este SMF debe ser útil para cualquiera que tenga la tarea de garantizar el lanzamiento de la
solución de servicios de TI de la más alta calidad posible en el hito de disponibilidad de la versión.
Incluye orientación sobre cómo probar una solución completa de funciones, preparar versiones de
lanzamiento de candidato, tratar comentarios y solucionar problemas informados.
El SMF aborda específicamente los siguientes procesos de estabilización:
 Estabilizar un candidato de liberación.

 Realizar una prueba piloto.
 Revise la Revisión de la Administración de Readiness de Liberación.
Estabilizar la función de administración de

servicios
La estabilización comienza después del hito completo Scope, que finaliza el desarrollo. La guía
proporcionada por el SMF de Estabilización está diseñada para ayudar al equipo del proyecto en las
siguientes actividades:
 Pruebe la solución de características completas.

 Prepare las versiones candidatas de la solución.
 Tratar con comentarios.
 Corregir errores reportados.
Durante las pruebas, el énfasis está en usar y operar la solución en condiciones ambientales
realistas. El equipo del proyecto se centra en resolver y clasificar (priorizar) los errores y preparar la
solución para el despliegue.
Hay una serie de tipos de pruebas que se pueden utilizar en esta etapa, entre ellos los siguientes:
 Pruebas unitarias / funcionales

 Pruebas integradas
 Pruebas operacionales
Prueba a menudo informes bugs a un ritmo más rápido que el desarrollo puede resolverlos.
Aunque no hay forma de saber cuántos bugs probarán o cuánto tiempo tardará el desarrollo en
solucionarlos, existen indicadores estadísticos conocidos como convergencia de bugs y rebote de
errores cero que ayudan a los equipos a predecir cuándo las soluciones alcanzarán estabilidad.
Esta guía describe ambas señales.
[Date]
68
Una vez que el equipo del proyecto decide que una compilación es lo suficientemente estable como
para ser un candidato de liberación, despliega la solución a un grupo piloto. Estabilización culmina
en la prontitud de liberación MR. Este hito se produce cuando se han solucionado todos los
problemas pendientes y el equipo ha liberado la solución o la ha implementado en el entorno de
producción.
Estabilizar los tipos de funciones SMF
La responsabilidad primordial del equipo que se aplica al SMF de Stabilize es la Responsabilidad

de la Solución. Los tipos de rol dentro de esa responsabilidad y sus actividades principales dentro
de este SMF se muestran en la siguiente tabla.
Tabla 1. Responsabilidad de las soluciones y sus tipos de funciones de los asistentes
Responsabilidades Función en este SMF

Tipo de rol
 Posee todas las SMFs en esta
responsabilidad
 Actua como director de proyectos
soluciones
para todos los proyectos
 Resuelve conflictos entre proyectos
 Establece objetivos de
diseño
 Describe el concepto de
 Controla el diseño, la programación solución
Director del
y los recursos a nivel de proyecto  Crea la estructura del
programa
proyecto
 Requisitos de documentos
para probar contra
 Crea solución
 Construye la solución acordada
Desarrollador  Arregla errores
 Estrategias de pruebas
 Criterios de aceptación de
 Pruebas para determinar con
pruebas
precisión el estado del desarrollo de
Ensayador  Solución de pruebas
la solución
 Implicaciones del proyecto
de documentos
 Actúa como defensor del cliente  Participa en pruebas

 Ayuda a conducir la visión de generales
Gerente de proyecto compartida  Lleva las necesidades de la
producto  Gestiona las expectativas de los organización al proceso de
clientes prueba
[Date]
69
Responsabilidades Función en este SMF
Tipo de rol
 Actúa como defensor del usuario en  Documentos requisitos de
los equipos de proyecto rendimiento del usuario
 Ayuda a definir los requisitos del  Documentos implicados en
Experiencia de
usuario las pruebas del proyecto
usuario
 Ayuda a diseñar para satisfacer las  Participa en el análisis de
necesidades del usuario errores
 Implicaciones de
implementación de
documentos
operaciones para asegurar que se
 Documentos gestión de
cumplan con el diseño
Gestión de la operaciones y apoyo
 Crea un piloto, plan de despliegue y
liberación  Documentos criterios de
programación
aceptación de operaciones
 Administra la implementación del
 Se prepara para la
sitio
liberación
 Defensores de operaciones en el
 Documentos requisitos de
equipo del proyecto
rendimiento de operaciones
 Requiere expertos en operaciones
 Participa en el análisis de
Experiencia en según sea necesario para obtener
errores
Operaciones información detallada
 Se prepara para la
liberación
liberación
 Posee todas las pruebas en todos

los equipos del proyecto
 Desarrolla estrategias y planes de
pruebas
Pruebas
 Garantiza la utilización de métodos
de prueba de las mejores prácticas
Metas de Estabilización
El objetivo de la estabilización es liberar la solución de la más alta calidad posible en el hito de

disponibilidad de la versión. El equipo del proyecto logra esta meta identificando errores y
problemas a través de pruebas exhaustivas y el lanzamiento-piloto candidato. Luego, el equipo
triage y resuelve todos los errores conocidos. Resolver un error no significa necesariamente fijarlo:
se puede diferir a una versión posterior o declararse lo suficientemente grave como para arreglarlo.
Los objetivos de la estabilización incluyen:
 Prueba de la solución completa de funciones.

 Implementación de uno o más candidatos de liberación a un grupo piloto.
 Abordar la retroalimentación de la prueba piloto y los errores.
La Tabla 2 muestra los resultados deseados de las metas de Estabilizar SMF y enumera las
[Date]
70
medidas que puede usar para medir con qué éxito ha logrado estos objetivos después de completar
este SMF.
Cuadro 2. Resultados y Medidas de los Objetivos SMF de Estabilización
Medidas
Resultados
 Bug convergencia y cero rebote de
bugs alcanzados
 No hay errores no resueltos en la
Una solución estable y de alta calidad
base de datos de seguimiento de
problemas
 El número de errores no resueltos

en la base de datos de seguimiento
Se resuelven todos los problemas encontrados de problemas
mediante las pruebas y los comentarios de los pilotos  Firma en el hito de prontitud de
liberación
Una solución de alta calidad que satisface las  Firma en el hito de prontitud de
expectativas y especificaciones del cliente tal y como liberación
se define en la especificación funcional
Términos clave
Definición
Término
El punto en el que el número de errores fijados excede el número de errores
Convergencia
reportados. Bug convergence es la primera indicación de que la solución se está
de errores
convirtiendo en estable.
Pruebas
Prueba de una solución completa contra la especificación funcional.
funcionales
Pruebas de Prueba de componentes individuales ensamblados integrados con otros
integración componentes.
Pruebas realizadas por un subconjunto de usuarios en un entorno de
Prueba piloto producción. El grupo piloto utiliza la solución, proporcionando retroalimentación
y reportando cualquier error que encuentre el grupo.
El proceso de priorización y racionalización de errores y problemas con la
solución. Las prioridades asignadas a los bugs indican lo crítico que es
Triage
solucionarlos. Racionalizar es el proceso de determinar la gravedad del error y si
el error debe arreglarse para la versión actual.
Examen de la
Comprobación de los componentes individuales de la solución.
unidad
[Date]
71
Definición
Término
El punto en el que el desarrollo no tiene errores abiertos para arreglar. Aunque
Zero rebote de es muy probable que la prueba informe errores adicionales en el futuro, el rebote
errores de errores cero es la primera indicación de que la estabilización está llegando a
su fin.
Estabilizar el flujo del proceso

La figura 2 ilustra el flujo de proceso para estabilizar. El flujo consiste en los siguientes procesos:

 Revise el hito de disponibilidad de la versión.
[Date]
72
Figura 2. Estabilizar el flujo del proceso
Proceso 1: Estabilizar a un Candidato de

Liberación
[Date]
73
El primer proceso de estabilización es que el equipo encuentre y solucione parte de una serie
errores en la solución y prepare un candidato de liberación. más amplia de
herramientas y
Accelerators .
Descargar
Operations
Framework 4.0
Notificaciones de
aceleradores de
soluciones
Regístrese para
conocer las
actualizaciones y los
nuevos lanzamientos
Realimentación
Envíanos tus
comentarios o
sugerencias
[Date]
74
Figura 3. Estabilizar un candidato a la liberación
Actividades : Estabilizar a un Candidato de Liberación
Durante las partes iniciales de la estabilización, Prueba y Desarrollo trabajan

juntos para encontrar y resolver los errores. Realizan reuniones de errores
regularmente programadas para analizar errores, y los miembros del equipo
informan y rastrea el estado de cada problema utilizando los procedimientos
de seguimiento de problemas desarrollados durante la planificación.
A medida que el proyecto avanza, el equipo comienza a preparar candidatos

a la liberación. La creación de un candidato a la liberación implica asegurar
su aptitud para la liberación, incluyendo si todos los componentes están
presentes. Típicamente, los equipos crearán varios candidatos de la
liberación con cada candidato de la liberación que es un hito intermedio. La
prueba después de cada candidato de liberación indica si el candidato está
en condiciones de desplegarse en un grupo piloto.
Para completar este proceso, los equipos deben permitir que las partes
interesadas interactúen con la solución mientras se encuentra en el entorno
de desarrollo. Por ejemplo, las partes interesadas pueden probar la solución
en un laboratorio o en un entorno de capacitación. Pero la prueba necesita
un ambiente separado para las pruebas. Los miembros del equipo de
despliegue, las operaciones, el soporte y los usuarios son candidatos típicos
para revisar la preparación del piloto.
La siguiente tabla enumera las actividades involucradas en este proceso.

Esto incluye:
 Escribir el documento de especificación de prueba.

 Identificar y resolver errores hasta que la solución se estabilice.
 Prueba del candidato a la liberación.
 Completar las pruebas de aceptación de usuarios.
Tabla 4. Actividades y Consideraciones para Estabilizar a un Candidato

de Liberación
Consideraciones
Ocupaciones
Escribir el Preguntas clave:
documento de
especificación de  ¿Cuál es el camino típico a través de la
prueba solución?
 ¿Cuáles son los escenarios clave?
 ¿Funciona la solución según lo esperado?
 ¿Cómo se puede probar la solución?
 ¿Qué requisitos se deben probar?
[Date]
75
Consideraciones
Ocupaciones
 ¿Cómo se ve el éxito?
Entradas:
Salidas:
 Documento de especificación de prueba
Identificar y Preguntas clave:

resolver errores
hasta que la  ¿La solución ha logrado convergencia de
solución se errores?
estabilice  ¿Ha logrado la solución un rebote de errores
cero?
 ¿Cuáles son las principales responsabilidades
de Test en este proyecto?
 ¿Hay alguna característica o funcionalidad que
tenga más riesgos o prioridades que otras?
 ¿La solución interactúa con otras
infraestructuras u organizaciones?
 ¿Se está ejecutando un proceso de compilación
diaria que da código fresco de prueba cada día?
 ¿La base de datos de seguimiento de
problemas es lo suficientemente dinámica como
para permitir un desarrollo ágil? Por ejemplo,
¿está disponible un sistema de notificación que
puede alertar al equipo del proyecto cuando se
agregan nuevos bugs a la base de datos de
seguimiento de problemas o si cambia de
estado?
 ¿Qué características o funcionalidades tienen el
mayor riesgo?
Entradas:
 Documento de especificación de prueba

 Plan maestro del proyecto, incluyendo el plan de
pruebas
 Entorno de laboratorio
 Construcciones provisionales, incluyendo:
 Soluciones disponibles.
 Documentación.
 Base de datos de seguimiento de problemas
 Políticas y procedimientos de seguimiento de
[Date]
76
Consideraciones
Ocupaciones
emisiones
Salidas:
 Liberar al candidato
Mejores prácticas:
 Utilice un sistema formal de seguimiento de

problemas para rastrear y reportar el estado de
los errores.
 Documentar los procedimientos de seguimiento
y presentación de informes en la planificación.
 Cree una matriz de prueba para identificar las
tareas de prueba y asignarlas a los probadores.
 Divida la matriz de prueba por áreas funcionales
de la solución.
Pruebe el Preguntas clave:

candidato a la
liberación  ¿Esta función de solución está completa o aún
faltan componentes?
 ¿Está listo el piloto candidato a la liberación o el
equipo necesita construir otro?
Entradas:
 Liberar al candidato
 Plan maestro del proyecto, incluyendo el plan de
pruebas
 Base de datos de seguimiento de problemas
 Políticas y procedimientos de seguimiento de
emisiones
Salidas:
 Piloto listo para la liberación

 Plan maestro del proyecto actualizado,
incluyendo:
 Plan de copia de seguridad y
recuperación.
 Plan de empleo.
 Plan de apoyo.
 Plan de monitoreo.
 Plan de operaciones.
[Date]
77
Consideraciones
Ocupaciones
Mejores prácticas:
 Focus Test y esfuerzos de desarrollo para

descubrir errores que representan problemas tan
serios que tienen que ser arreglados.
 Definir y acordar criterios de éxito para probar el
candidato a la liberación.
 No libere al candidato hasta que todo el equipo
firme su aptitud.
Prueba completa Preguntas clave:

de aceptación por
parte del usuario  ¿Quién hará las pruebas de aceptación del
usuario?
 ¿Qué escenarios son los más críticos para
probar?
 ¿Quién determina si pasa la prueba?
 ¿Quién representa a los usuarios?
 ¿Están representadas todas las categorías de
usuarios?
Entradas:
 Candidato a la liberación del piloto

 Formación o entorno de laboratorio (entorno de
formación no relacionado con la producción)
Salidas:
 Aceptacion de usuario
 Archivo de soluciones en la biblioteca de
software definitiva (DSL)
Mejores prácticas:
 Realice pruebas de aceptación por parte del

usuario para asegurarse de que la solución
satisface las necesidades de los clientes antes
de pasar a la prueba piloto.
 Dar apoyo y usuarios la oportunidad de practicar
la nueva tecnología de forma segura.
 Aproveche esta oportunidad para identificar
problemas que impiden el despliegue exitoso.
 Identifique primero los criterios de éxito para
mantener el enfoque en los requisitos acordados
y para evitar el deslizamiento del alcance.
[Date]
78
Consideraciones
Ocupaciones
 Tenga una manera de recopilar ideas para
futuros usuarios que surgieron durante las
pruebas.
Proceso 2: Realizar una prueba piloto

There are no mem
En este proceso, el equipo lleva a cabo una prueba piloto de la solución.
[Date]
79
Figura 4. Realizar una prueba piloto
Actividades : Realizar una prueba piloto
[Date]
80
Una prueba piloto verifica que la solución cumple con las expectativas y especificaciones del cliente
mediante la prueba de toda la solución en un entorno de producción. Normalmente, una prueba
piloto es un despliegue en un subconjunto del entorno de producción en directo. Este subconjunto
puede ser un grupo particular de usuarios, un departamento completo o un grupo de servidores en
un centro de datos. El proceso de prueba piloto ayuda a identificar áreas donde los usuarios tienen
problemas para entender, aprender y usar la solución. También ofrece a Release Management la
oportunidad de identificar problemas que pueden impedir el despliegue exitoso de la solución.
Durante la prueba piloto, el equipo recopila y evalúa datos piloto, tales como comentarios de los
usuarios. Una vez que el equipo ha reunido suficientes datos, el equipo debe elegir una de las
siguientes estrategias:
 Desplácese hacia adelante. Implementar un nuevo candidato de lanzamiento al grupo

piloto.
 Retroceda. Ejecute el plan de restauración para restaurar el grupo piloto a su estado de
configuración anterior. Pruebe el piloto de nuevo más tarde con un candidato de liberación
más estable.
 Suspender. Suspenda las pruebas piloto.
 Parche y continúe. Implementar parches para solucionar la solución existente.
 Desplegar. Proceda al despliegue de la solución.
Tabla 5. Actividades y Consideraciones para Realizar una Prueba Piloto
Consideraciones
Actividad
Pilote la solución y Preguntas clave:
recopile la
retroalimentación  ¿Es viable la solución en un entorno de producción?
 ¿Están listos todos los componentes de la solución para la
implementación?
 ¿El equipo del proyecto y los clientes han acordado criterios
piloto de éxito?
 ¿Tiene el equipo del proyecto un mecanismo para recolectar la
retroalimentación?
 ¿Qué sitios y grupos tiene el equipo de proyecto elegido para el
piloto? ¿Hay uno o más perfiles de usuario que el equipo está
apuntando para la prueba piloto?
 ¿Se preparan los usuarios objetivo para el piloto?
 ¿Ha documentado el equipo del proyecto un plan de transición
en el plan piloto?
 ¿Cómo evaluará el equipo del proyecto los resultados de la
prueba piloto?
 ¿Qué riesgos se asocian con la prueba piloto de la solución en
producción?
Entradas:

 Plan Piloto.
[Date]
81
Consideraciones
Actividad
 Plan de apoyo.
 Candidato de lanzamiento listo para el piloto, incluyendo:
 Documentación de la solución.
Salidas:
 Documento de revisión piloto

 Notas de la versión actualizadas
Mejores prácticas:
 No comience una prueba piloto hasta que el equipo del

proyecto, los clientes y los usuarios estén de acuerdo en los
criterios para un resultado exitoso.
 Pilote todo el proceso de implementación y no solo la
interacción del usuario.
 Comunique a los usuarios la longitud, propósito y progreso del
piloto.
 Asegurar que el apoyo esté entrenado y preparado para apoyar
a los usuarios piloto.
Proceso 3: Revisar el hito de prontitud de

liberación
En este proceso final, el equipo del proyecto, los clientes y las partes interesadas revisan y
aprueban el hito de preparación para la liberación.
[Date]
82
Figura 5. Revisar el hito de prontitud de liberación
Actividades: Revisar el hito de prontitud de lanzamiento
La estabilización culmina en el hito de Readiness de liberación. Este hito, que es una revisión de la
gestión de MOF, se produce después de que se ha llevado a cabo un piloto exitoso, se han
solucionado todos los problemas pendientes y se ha liberado y puesto a disposición para su
despliegue total en el entorno de producción. Este hito es la oportunidad para que los clientes y
usuarios, las operaciones y el personal de soporte y los principales interesados en el proyecto
evalúen la solución e identifiquen cualquier problema que deba resolver antes de su
implementación.
Tabla 6. Actividades y consideraciones para revisar el hito de prontitud de liberación
Consideraciones
Ocupaciones
Aprobar el hito de prontitud de Preguntas clave:
liberación
 ¿Fue exitoso el piloto en comparación con los criterios de
éxito?
 ¿El equipo documentó soluciones para problemas
encontrados durante el piloto?
 ¿Están todos satisfechos y preparados para firmar en su
trabajo?
[Date]
83
Consideraciones
Ocupaciones
 ¿Están plenamente documentados los procedimientos de
despliegue y operaciones?
 ¿Se probaron los procedimientos de despliegue y opciones
durante el piloto?
Entradas:
 Versión final, incluyendo:

 Código fuente.
 Notas de la versión
 Resultados de las pruebas y herramientas de prueba
 Plan Maestro, incluyendo:
 Plan de empleo.
 Plan de operaciones.
Salidas:
 Liberar documento de formulario de firma
Conclusión
Este SMF ha tratado cómo garantizar la liberación de la solución de servicios de TI de la más alta
calidad posible en el hito de disponibilidad de la versión. Incluye orientación sobre cómo probar una
solución completa de funciones, preparar versiones de lanzamiento de candidato, tratar comentarios
y solucionar problemas informados.
Lograr esto requiere una comprensión clara de los siguientes procesos de estabilización:

 Revise el hito de disponibilidad de la versión.
Realimentación
Implementar la función de administración de

servicios
[Date]
84
Posición de la implantación de SMF dentro del ciclo de vida del servicio de TI de

MOF
Deploy SMF pertenece a la fase Deliver del ciclo de vida del servicio de TI de MOF. La siguiente
figura muestra el lugar de implementación de SMF dentro de la fase de entrega, así como la
ubicación de la fase de entrega dentro del ciclo de vida del servicio de TI.
Figura 1. Posición de la implantación de SMF dentro del ciclo de vida del servicio de TI
¿Por qué utilizar el SMF de implementación?
Este SMF debe ser útil para cualquier persona que esté involucrada en la liberación de una solución
de servicio de TI estable en el entorno de producción, incluida la estabilización de la solución en el
entorno de producción y la transferencia de la responsabilidad del equipo de proyecto a los equipos
[Date]
85
de Operaciones y Soporte.
 Implementar los componentes principales de la solución de servicios de TI.

 Implementar sitios.
 Estabilice el despliegue.
 Revise el hito completo del despliegue.
Despliegue de la función de administración de

servicios
El despliegue comienza cuando la estabilización termina con el hito de disponibilidad de la versión,

que es una revisión de la gestión de MOF. Durante la implementación, el equipo de proyecto
despliega la solución central y los componentes del sitio en el entorno de producción; estabiliza el
despliegue; transfiere el proyecto a las operaciones; y obtiene la aprobación final del cliente para la
nueva solución.
Aunque el proceso de estabilización está terminado, la estabilización continúa durante la

implementación, ya que el equipo transfiere la solución desde un entorno de prueba al entorno de
producción. Después del despliegue, el equipo lleva a cabo una revisión del proyecto y una
encuesta de satisfacción del cliente.
El hito completo de implementación concluye la implementación. Con este hito, la solución debe
satisfacer las expectativas y especificaciones del cliente, proporcionando el valor comercial
esperado al cliente. El cliente debe acordar explícitamente que la solución cumple sus objetivos
antes de que el equipo declare que la solución se ha implementado con éxito en la producción. Esto
requiere una solución estable y criterios claramente comunicados para el éxito. Además, las
operaciones apropiadas y los sistemas de apoyo deben estar en su lugar. Al llegar al Hito Completo
de Despliegue, el equipo debería haber finalizado todas las actividades y terminado el proyecto.
Tipos de roles SMF de implementación
La responsabilidad primordial del equipo que se aplica al SMF de implementación es la

responsabilidad de la solución. Los tipos de rol dentro de esa responsabilidad y sus actividades
principales dentro de este SMF se muestran en la siguiente tabla.
Tabla 1. La Responsabilidad de la Solución y sus Tipos de Función de Operador

Tipo de rol
Gerente de  Función responsable  Supervisión continua
soluciones  Posee todas las SMFs en esta
responsabilidad
[Date]
86
Tipo de rol
 Actua como director de
proyectos para todos los
proyectos
proyectos
 Asegura que la solución esté

 Controla el diseño, la
dentro del alcance acordado
Director del programación y los recursos a
 Gestiona la estabilización de la
programa nivel de proyecto
solución
 Resuelve problemas con la

solución
 Construye la solución acordada
Desarrollador  Proporciona soporte para la
escalada de problemas
 Pruebas para determinar con  Prueba el rendimiento

precisión el estado del  Realiza seguimiento y
Ensayador
desarrollo de la solución clasificación de problemas
 Actúa como defensor del cliente

 Procesa los comentarios de los
clientes
Gerente de proyecto compartida
 Evalúa la implementación
producto  Gestiona las expectativas de
 Se apaga en la implementación
los clientes

usuario en los equipos de
proyecto  Usuarios de trenes
Experiencia de  Ayuda a definir los requisitos  Mantiene el programa de
usuario del usuario entrenamiento
 Ayuda a diseñar para satisfacer
las necesidades del usuario

operaciones para asegurar que
se cumplan con el diseño  Gestiona la implementación de la
Gestión de la
 Crea un piloto, plan de solución
liberación
del sitio
 Defensores de operaciones en  Funciona con Release

Experiencia en
el equipo del proyecto Management para asegurar que
Operaciones
 Requiere expertos en la solución esté lista para las
[Date]
87
Tipo de rol
operaciones según sea
necesario para obtener
información detallada operaciones
liberación

 Desarrolla estrategias y planes
Gerente de de pruebas  Supervisión continua
Pruebas  Garantiza la utilización de
métodos de prueba de las
mejores prácticas
Objetivos de la implementación
El objetivo del despliegue es liberar una solución estable en el entorno de producción. Esto incluye
estabilizar la solución en el entorno de producción y transferir la responsabilidad de la solución
desde el equipo del proyecto a los equipos de operaciones y soporte. La Tabla 2 muestra los
resultados deseados de las metas de Implementación de SMF y enumera las medidas que puede
utilizar para medir con qué éxito ha logrado estos objetivos después de completar este SMF.
Tabla 2. Resultados y Medidas de la Implementación de los Objetivos SMF
Medidas
Resultados
 Número de problemas de soporte abiertos
Solución estable implementada en el entorno
después del despliegue
de producción
 Todos los sitios están completamente
El cliente está satisfecho y acepta la solución desplegados
implementada  Firma en el hito completo del despliegue
 Ningún miembro del equipo de proyecto

sigue participando activamente en el
Solución transferida con éxito del equipo del
proyecto
proyecto a los equipos de operaciones y
 Número de escaladas de soporte de
soporte
operaciones y equipos de soporte
Términos clave
[Date]
88
Definición
Término
Un estado conocido por el cual algo se mide o compara. Baselining está
Base colocando algo bajo control de cambio. Las líneas de base permiten gestionar el
cambio en proyectos complejos.
Cliente La persona u organización que comisiona y financia el proyecto.
Una prueba realizada por un subconjunto de usuarios en un entorno de
Prueba piloto producción. El grupo piloto utiliza la solución, proporcionando retroalimentación y
reportando cualquier error que encuentre el grupo.
El período entre el hito intermedio estable de despliegue y el hito completo de
Periodo de despliegue. Durante este período, el equipo del proyecto ya no está activo, pero sí
silencio responde a los problemas a medida que las operaciones y el apoyo los escalan al
equipo. Típicos períodos de calma duran de 15 a 30 días.
Individuos o grupos que tienen interés en el resultado del proyecto, aunque sus
objetivos y prioridades no siempre son idénticos a los del cliente. Ejemplos de
Interesados partes interesadas son los directores departamentales que se verán afectados por
la solución, el personal de TI responsable de ejecutar y apoyar la solución y los
administradores funcionales que aportan recursos al equipo del proyecto.
La versión final, completamente probada de la solución. Una versión final se
Lanzamiento
considera estable y relativamente libre de errores con una calidad adecuada para
final
una amplia distribución y uso por parte de los usuarios finales.
Implementar flujo de proceso

La Figura 2 ilustra el flujo de proceso para el despliegue. Este flujo consiste en el siguiente
proceso:

[Date]
89
Figura 2. Flujo del proceso de implementación
Proceso 1: Implementación de componentes

principales
[Date]
90
El primer proceso de despliegue es desplegar la tecnología principal.
Figura 3. Implementación de componentes principales
Actividades: Implementación de componentes principales
Las soluciones de TI suelen requerir infraestructura de apoyo en la que desplegar y operar. Los
ejemplos de infraestructura incluyen controladores de dominio, servidores de correo electrónico,
servidores de acceso remoto y servidores de base de datos. Aunque los usuarios no interactúan
directamente con la infraestructura, la solución normalmente depende de ella. Los equipos de
proyecto pueden implementar la tecnología de núcleo antes o en paralelo con la solución,
dependiendo de los requisitos de la solución.
Tabla 4. Actividades y consideraciones para implementar los componentes principales
Consideraciones
Ocupaciones
Implementar la Preguntas clave:
infraestructura de la
solución en la producción  ¿Puede el equipo del proyecto implementar la tecnología central
en paralelo con la solución, o el equipo debe desplegar la
tecnología principal antes de la solución?
 ¿El equipo del proyecto comenzó a desplegar los componentes
[Date]
91
Consideraciones
Ocupaciones
básicos antes en el ciclo de vida del proyecto, como durante la
prueba piloto realizada en la estabilización?
 ¿Ha documentado el equipo del proyecto una estrategia para
desplegar la infraestructura?
 ¿Tiene el equipo del proyecto experiencia en el despliegue de
infraestructuras similares?
Entradas:

 Plan maestro del proyecto, incluido el plan de despliegue
Salidas:
 Componentes principales desplegados hoja de inicio de sesión

 Asegúrese de que haya una Solicitud de cambio (RFC)
procesada antes de introducir este cambio (despliegue de
componentes básicos) en el entorno de producción para
garantizar un ciclo de lanzamiento suave.
Proceso 2: Implementar sitios

En este proceso, el equipo implementa la solución en cada sitio.
[Date]
92
Figura 4. Implementación de sitios
Actividades: Implementar sitios
Este proceso es el objetivo final de todos los procesos anteriores del proyecto. Durante este
proceso, el equipo de proyecto despliega la solución a todos los usuarios y equipos de destino de
cada sitio. Los comentarios de clientes y usuarios de los sitios desplegados pueden revelar
problemas adicionales con la solución. Por lo tanto, el equipo del proyecto puede tener que revisar
algunos sitios después del despliegue. Sin embargo, el equipo del proyecto está haciendo un
esfuerzo concentrado para completar el despliegue y cerrar el proyecto. Al finalizar este proceso,
todos los usuarios y computadoras objetivo tienen acceso a la solución. Además, cada propietario
del sitio ha firmado que su sitio está funcionando como se esperaba.
Tabla 5. Actividades y consideraciones para implementar los sitios
Consideraciones
Ocupaciones
Implementar la Preguntas clave:
solución en cada sitio
 ¿Realmente la solución involucra implementación de cliente?
 ¿El equipo implementó los componentes básicos de la
infraestructura con éxito?
 ¿Ha establecido el equipo del proyecto expectativas con clientes y
usuarios?
 ¿El equipo del proyecto comunicó el plan de despliegue a cada
[Date]
93
Consideraciones
Ocupaciones
sitio?
 ¿El equipo utilizará un despliegue gradual en cada sitio?
 ¿Cuánto ancho de banda de la red y otros recursos son
necesarios?
Entradas:

 Plan de empleo.
Salidas:
 Implementaciones del sitio: hoja de inicio de sesión completa
Mejores prácticas:
 Implementar cada sitio por separado ya que cada uno puede tener
requisitos únicos, haciendo un despliegue general poco práctico.
 Tomar decisiones sobre la estrategia de despliegue a principios del
proyecto, en las fases de Envisioning o Project Planning, para
minimizar el riesgo.
Proceso 3: Estabilizar el despliegue

En este proceso, el cliente y el equipo coinciden en que la implementación parte de una serie
está completa. más amplia de
herramientas y
Accelerators .
Descargar
Operations
Framework 4.0
Notificaciones de
aceleradores de
soluciones
Regístrese para
[Date]
94
Figura 5. Estabilizar la implementación
Actividades: Estabilizar el despliegue
Al finalizar este proceso, el cliente y el equipo del proyecto están de acuerdo

en que las implementaciones del sitio están completas y que están
funcionando satisfactoriamente. Esto significa que la solución y las
implementaciones del sitio cumplen con las expectativas y especificaciones
del cliente y que el cliente está dispuesto a aprobarlas y firmarlas.
Determinar cuándo un proyecto está completo y el equipo del proyecto

puede desactivarse puede ser difícil. Las nuevas soluciones a menudo
están cambiando constantemente, y el equipo del proyecto es a menudo la
lucha contra incendios-identificar y gestionar problemas de soporte. A pesar
de que el equipo del proyecto puede tener dificultades para cerrar
formalmente el proyecto debido a problemas en curso, el equipo necesita
definir claramente un hito de terminación.
La siguiente tabla enumera las actividades involucradas en este proceso.

Esto incluye:
 Estabilizar el despliegue de la solución.

 Control de la solución durante el período de silencio.
Cuadro 6. Actividades y consideraciones para estabilizar el despliegue
Consideraciones
Ocupaciones
[Date]
95
Proceso 4: Revisión del hito completo de
implementación
En este proceso final, el equipo del proyecto completa su participación con la solución.
Figura 6. Revisión del hito completo de implementación
Actividades: Revisión del hito completo del despliegue
El hito completo de implementación finaliza el proyecto y significa que el equipo del proyecto se ha
desacoplado completamente y transferido la solución al personal permanente. Al finalizar este hito,
el equipo del proyecto firma el documento del informe de revisión del hito para indicar su aprobación
del hito. Además, el equipo del proyecto, los clientes y las partes interesadas completan el
documento de análisis posterior al proyecto y el informe de cierre del proyecto para documentar las
lecciones aprendidas y las mejores prácticas.
La siguiente tabla enumera las actividades involucradas en este proceso. Esto incluye:
 Aprobación del hito completo del despliegue.

 Revisar y cerrar el proyecto.
Tabla 7. Actividades y consideraciones para revisar el hito completo del despliegue
Consideraciones
Ocupaciones
Aprobar el hito Preguntas clave :
completo del despliegue
 ¿Se han completado y estabilizado todas las implementaciones
del sitio?
[Date]
96
Consideraciones
Ocupaciones
 ¿Están satisfechos los clientes y usuarios con la solución y el
despliegue?
 ¿Se han transferido todos los miembros del equipo del proyecto
del proyecto?
 ¿El período de tranquilidad fue sin incidentes o se documentaron
numerosos incidentes?
Entradas:
 Informes de implementación
Salidas:
Preguntas clave:
 ¿Están disponibles todos los miembros del equipo del proyecto,

clientes y partes interesadas para realizar un análisis posterior al
proyecto?
Entradas:
Revisar y cerrar el  Registros de incidentes para los registros de implementación

proyecto
Salidas:
 Documento de análisis posterior al proyecto

 Documento de informe de cierre del proyecto
 Involucre a los representantes de todas las funciones del proyecto
para obtener múltiples perspectivas.
Conclusión
Deploy SMF describe cómo liberar una solución estable en el entorno de producción. Este SMF
describe específicamente cómo estabilizar una solución de servicios de TI en el entorno de
producción y transferir la responsabilidad de la solución desde el equipo del proyecto a los equipos
de Operaciones y Soporte.
Los principales procesos de despliegue descritos por Deploy SMF son:
[Date]
97
Realimentación
Gestionar
Manage Layer establece un enfoque integrado de las actividades de gestión de servicios de TI.
Esta área de MOF ayuda a los profesionales de TI a coordinar los procesos descritos en la fase de
ciclo de vida de SMFs y proporciona orientación sobre:
 Establecimiento de procesos de toma de decisiones

 Emplear la gestión de riesgos y los controles como parte de todos los procesos
 Promoción de procesos de cambio y configuración adecuadamente controlados
 Dividir el trabajo para que las responsabilidades por los resultados sean claras y no
Administrar contenido de capa
 Administrar la visión general

 Gobierno, Riesgo y Cumplimiento
 Equipo
[Date]
98
La capa de gestión
Para ayudar a los profesionales de TI a planificar y optimizar eficazmente la estrategia de TI, MOF
proporciona funciones de gestión de servicios (SMF) que identifican los procesos, las personas y las actividades
necesarias para alinear los servicios de TI con los requisitos empresariales. Las SMFs identifican y describen
las actividades principales que los profesionales de TI realizan en las distintas fases del ciclo de vida del
servicio de TI. Aunque cada SMF se puede pensar y utilizar como un conjunto independiente de procesos, es
cuando se combinan que más eficazmente garantizar que la prestación de servicios es completa y en la calidad
deseada y los niveles de riesgo.
Funciones de administración de servicios dentro de la capa de administración
Como base de todas las fases del ciclo de vida, la capa de gestión integra las actividades separadas de todos los
SMF a través de sus propias SMF:
 Función de administración de servicios de gobernabilidad, riesgo y cumplimiento (GRC SMF)

 Función de gestión de servicio de cambio y configuración (CC SMF)
 Función de administración de servicio de equipo
La siguiente tabla explica estos SMFs con más detalle.
Tabla 1. Las SMF de la capa de gestión

SMF
Entregable: objetivos de TI logrados,
cambiados y gestionados y documentados
Los servicios de TI se adaptan
Gobierno, Riesgo
perfectamente a la estrategia y los objetivos
y Cumplimiento Propósito: Apoyar, sostener y hacer crecer
empresariales
la organización mientras se gestionan los
riesgos y limitaciones
Entregable: configuraciones conocidas y
adaptaciones predecibles
Cambio y Los servicios de TI son predecibles,
Propósito: Asegúrese de que los cambios
configuración confiables y confiables
están planificados, de que los cambios no
planificados son mínimos y de que los
servicios de TI son robustos
Entregable: Claras responsabilidades, roles
Soluciones de TI entregadas dentro de las
y asignaciones de trabajo
restricciones especificadas, sin degradación
Equipo
de servicio no planificada y con operación
Propósito: Equipos ágiles, flexibles y
de servicio confiable para el negocio
escalables que hacen el trabajo requerido
Las actividades de Gobernabilidad, Riesgo, Cumplimiento (GRC) y Cambio y Configuración (CC) ocurren a lo
largo del ciclo de vida, pero la perspectiva, alcance y enfoque de estas actividades varían por fase. Por ejemplo,
las actividades de gestión del cambio en la Fase del Plan serán de diferente magnitud e involucrarán a diferentes
[Date]
99
factores y participantes que las actividades de gestión del cambio en la Fase de Operación. Del mismo modo,
las preocupaciones de GRC reflejan los objetivos primarios de una fase; esto cambiará el enfoque en términos
de toma de decisiones, análisis de riesgo y las especificidades del cumplimiento.
GRC y CC crean más flujos de procesos unificados en todas las áreas del ciclo de vida estableciendo los
medios para tomar decisiones, equilibrar las compensaciones y establecer una estrategia de tierra mediante la
administración de los riesgos. Como base para el ciclo de vida de los servicios de TI, Manage Layer
proporciona una forma estructurada y planificada para que la TI contribuya a la viabilidad y mejora a largo
plazo de la organización.
Función de administrar SMF en las fases del ciclo de vida del servicio de TI
En la siguiente tabla se enumeran formas específicas en las que los SMF de la capa de gestión ayudan a
cumplir los objetivos de las otras tres fases del ciclo de vida del servicio de TI. Se pueden encontrar
explicaciones más detalladas de la función y el valor de las SMF de la capa de gestión en cada una de las SMF,
tal como se describen en sus respectivas fases.
Tabla 2. Foco de la gestión de SMFs de capa en las fases del ciclo de vida del servicio de TI
GRC Focus CC Focus Enfoque en equipo

Fase y su objetivo
 Liderazgo
 Transferencia de identificado y
estrategia corporativa solicitado a
 Los tomadores de
a estrategia de TI participar en la
Plan: decisiones
 Estructura de evaluación del
identificaron e
gobierno, derechos de cambio
Asegurar que los involucraron
decisión  Cambio del
servicios ofrecidos al  Responsabilidades
 Riesgos de alto nivel proceso
negocio sean valiosos, para determinar la
 Entorno normativo empresarial
predecibles, confiables tolerancia al riesgo
general  Cambio de
y rentables, y que asignada
 Definición de la arquitectura
respondan a las  Experiencia en
política  Cambio evaluado
necesidades gestión financiera
 Determinación de a través de las
empresariales en  Representación legal
inversiones dimensiones
constante cambio y de cumplimiento
 Definición de (financiero, cartera
objetivos de gestión de aplicaciones,
seguridad, etc.)
[Date]
100
GRC Focus CC Focus Enfoque en equipo
Fase y su objetivo
 Requisitos
organizacionales,
tanto funcionales
como operacionales,
soportados por la
arquitectura de la
Entregar:  Principios para la
solución
 Alcance de la organización eficaz
 Participantes del
Asegúrese de que los solución de los equipos de
proyecto,
servicios que el  Recursos proyecto
metodología, riesgos
negocio y TI han  Gestión de  Responsabilidades y
identificados
acordado se proyectos tipos de rol
 Proceso de
desarrollan con  Impacto  Alineación de
realización del valor
eficacia, desplegado financiero responsabilidades
 Ciclo de vida del
con éxito y listo para  Asignación de roles
desarrollo del servicio
las operaciones
 Mitigación de riesgos
 Controles internos
definidos
 Procedimientos
definidos
Funcionar:
 Principios para la
Asegurar que los organización de las
servicios desplegados  Entorno de TI y operaciones
 Procedimientos y
sean operados, configuración  Principios para la
controles
mantenidos y apoyados  Proceso y organización del
 Grabación y
de acuerdo con los procedimiento trabajo de monitoreo
documentación
objetivos del acuerdo  Cambio estándar  Principios para
de nivel de servicio organizar el trabajo
acordados entre la de apoyo
empresa y el
departamento de TI.
Controles internos
El concepto detrás de los controles internos es relativamente simple. Supongamos que sabe cómo hacer una
tarea sencilla de principio a fin. Usted lo sabe bien y puede confiable y consistente lograr el resultado final.
Ahora supongamos que necesita que otras personas realicen la misma tarea; las actividades, los cheques y los
saldos que usted pone en el lugar para cerciorarse de que esas personas hagan la misma tarea y alcancen las
mismas metas compone los controles internos para esa tarea.
Pero esos controles iniciales sólo abordan la tarea en sí. Cuando varias personas están involucradas, la
complejidad aumenta rápidamente. Supongamos que se vuelve más eficiente dividir la tarea y hacer que ciertas
personas se dirijan a ciertas partes. Ahora se necesitan controles para asegurar que los resultados individuales
se ajusten a lo que se pretende y que ninguna persona ha logrado defraudar el proceso. En las áreas de finanzas,
las cuestiones de control se vuelven aún más pronunciadas. La falta de control efectivo podría dar lugar a
errores contables, o incluso a fraude o malversación de fondos. Esto es cuando se agregan capas de control
relacionadas con el acceso, los roles y la segregación del deber que forman parte del cuadro.
[Date]
101
Los controles internos están presentes en todas las áreas dentro del ámbito de responsabilidad de TI. Algunos
controles se relacionan con el entorno físico donde se encuentra la infraestructura del centro de datos. Otros
controles implican la propia tecnología, por ejemplo, su configuración y quién tiene acceso a funciones
administrativas. Algunos controles abordan el acceso a los datos y el ciclo de vida de los datos a través de las
tecnologías, desde el cifrado hasta la autorización, la recuperación y la cadena de custodia.
Muchos de los controles internos relacionados con los negocios que afectan a los profesionales de TI se ven en
las aplicaciones de línea de negocio que conforman los sistemas financieros, de manufactura, de relaciones con
los clientes y de recursos humanos. En estas áreas, los controles deben expresarse como requisitos
empresariales que impulsan las características de la aplicación. Además de estos controles relacionados con los
procesos empresariales, los profesionales de TI deben abordar controles específicos para el funcionamiento de
sistemas y tecnologías que conforman la plataforma de aplicaciones.
La clasificación de los controles de TI en categorías generales ayuda a identificar la naturaleza de los controles
mientras se establece el enfoque probable para monitorear, probar y evaluar el diseño y la efectividad operativa
de los controles. La siguiente tabla explica los controles.
Tabla 3. Tipos de controles, su contenido y ejemplos
Tipo de Contenido Ejemplos

control
 Política de clasificación de la
información : garantiza la clasificación
de la información y los derechos de
acceso en cada nivel
Estándares, políticas y procedimientos, así  Política de continuidad de negocio:
como controles auxiliares tales como asegura que todos los aspectos del
Administrativo
programas de comunicación y capacitación negocio se consideren en caso de una
para concientizar interrupción o desastre
 Proceso de gestión de cambios :
garantiza que los cambios en el entorno
de TI se aplican de la manera correcta
 Sistema de archivos con cifrado (EFS)

Controles de acceso, mecanismos de cifrado  Listas de control de acceso (ACL)
y otras tecnologías utilizadas para proteger  Acceso físico a las computadoras
Técnico
los activos de información lógica de uso no controladas a través de protectores de
autorizado pantalla protegidos con contraseña
Físico Controles que protegen los dispositivos  Los cables de seguridad en las
físicos en los que se almacena o transmite la computadoras inhiben la eliminación no
información autorizada de equipos
 Las cerraduras de las puertas y ventanas
ayudan a controlar el acceso físico a los
dispositivos
 La fuente de alimentación universal está
disponible para sostener la actividad
empresarial en las computadoras en caso
[Date]
102
Tipo de Contenido Ejemplos
control
de un apagón
 Data y OS son respaldados y
recuperables en una ubicación remota
para la continuidad del negocio
Demostración de que un servicio de TI es, de hecho, en el control se lleva a cabo a lo largo del ciclo de vida
del servicio de TI por:
 Definición de objetivos de alto nivel para cada fase del ciclo de vida.
 Identificar los riesgos para el logro de esos objetivos.
 Identificar los enfoques de gestión de riesgos en la forma de hacer coincidir los controles internos para
mitigar los riesgos.
Revisión de gestión para la capa de gestión
La gerencia es responsable de establecer metas, evaluar el progreso y asegurar resultados. En parte, la

gobernanza consiste en los procesos de toma de decisiones (controles) que ayudan a la administración a cumplir
con esta responsabilidad. Cada fase del ciclo de vida del servicio de TI tiene una o más revisiones de gestión
(MR) que funcionan como controles de gestión. Esto significa que las personas adecuadas se reúnen, en el
momento adecuado y con la información adecuada, para tomar decisiones de gestión. Cada fase tiene objetivos
de gestión diferentes, por lo que cada fase tiene un enfoque único centrado en los MR con las partes interesadas
apropiadas, las decisiones necesarias y el tipo de datos necesarios para tomar decisiones bien informadas y
completamente ponderadas. La capa de gestión es la misma que las fases del ciclo de vida cuando se trata de la
necesidad de supervisión de la gestión, y hay una revisión de la gestión específicamente para la capa de gestión.
Revisión de la gestión de políticas y control
La Revisión de la Gestión de Políticas y Control (MR) consiste en revisiones al menos semestrales que evalúan
la efectividad de las políticas y controles en el ciclo de vida del servicio de TI. El desempeño de TI y sus
socios, la confiabilidad y confiabilidad de los servicios proporcionados, y la capacidad de TI para responder a la
empresa son afectados por el entorno de políticas y control. A través de todas las fases y SMFs en el ciclo de
vida del servicio de TI, se presta atención explícita a identificar los objetivos de gestión, los riesgos que podrían
afectar adversamente estos objetivos y los controles puestos en marcha para mitigar estos riesgos. Este MR es
la oportunidad de la gerencia para evaluar las políticas y los controles y su impacto a lo largo del ciclo de vida
en términos de alcanzar los objetivos de la gerencia. La revisión da una visión de cómo se maneja el riesgo y
de la probabilidad de que se logren los objetivos de la gestión, y ejemplifica la "gobernanza en acción" para la
capa de gestión.
Las preguntas básicas para esta revisión incluyen:
 ¿Están las políticas adecuadas? (Teniendo en cuenta los objetivos de gestión, las regulaciones, las
normas y las prácticas de la industria)
 ¿Son eficaces las políticas? (Informes de cumplimiento, solicitudes de cambios en las políticas y
excepciones concedidas)
 ¿Están los controles correctos en su lugar? (Basado en evaluaciones y mitigaciones de riesgos, eventos
e incidentes no abordados por los controles, y costos y beneficios de los controles)
 ¿Están los controles funcionando efectivamente a través del ciclo de vida?
[Date]
103
 Centrándose en el cambio y la configuración: ¿Se producen los resultados esperados, cualquier
cambio fallido o reelaboración necesaria para corregir los cambios?
 Centrarse en la realización de valor: evalúe el ajuste entre el entorno de políticas y control y el
valor que la empresa necesita recibir de TI. ¿Es este el nivel de control adecuado dado los
impactos de riesgo identificados y los retornos esperados?
Mientras que el MR de políticas y control proporciona una vista de resumen en el entorno de políticas y
control, los procesos específicos para la administración de políticas se describen en la Política SMF SMF .
El objetivo del MR es proporcionar la gestión de TI:
 Comprender cómo se están abordando los riesgos para alcanzar los objetivos.
 Una evaluación de la carga del control para que pueda ajustarse apropiadamente a los beneficios
deseados.
 Una evaluación del comportamiento como un indicador de comunicación de políticas y enculturación.
Debería establecerse un conjunto de controles apropiados para asegurar los siguientes objetivos:
 Implementar los requisitos de la política de la organización, incluida la política de seguridad de la

información.
 Administre los riesgos asociados con los objetivos de gestión y ciertos controles generales de TI, como
el acceso adecuado a servicios o sistemas.
 Documentar los controles y las pruebas de las actividades de control.
Dado que los controles son fundamentales para proporcionar servicios seguros y confiables, es necesario
gestionar cualquier cambio en los controles. El MR de Políticas y Control debe evaluar el impacto de los
cambios en los controles realizados desde la revisión anterior. Debe darse un esfuerzo relacionado con la
revisión de las evaluaciones de los impactos potenciales del cambio realizados antes de la implementación real
de los cambios.
Un objetivo de este MR es evaluar la eficacia de la gestión del cambio del entorno de control. Esto es diferente
de las actividades que se producen en el SMF de Cambios y configuración de MOF . El enfoque se centra en
las prácticas de gestión en términos de cumplimiento de políticas y eficacia de control.
Este MR también evalúa las políticas y los controles que forman parte de los acuerdos con organizaciones
externas. Esto incluye los acuerdos y contratos relacionados con el acceso a los sistemas de información y
datos, así como los requisitos de seguridad y privacidad de los servicios.
Los participantes en este MR deben ser principalmente gerentes senior de TI con el apoyo de los miembros del
equipo de Cumplimiento, Política y Seguridad. Los auditores pueden proporcionar información útil sobre la
eficacia y eficiencia de los controles y consideraciones para compensar los controles. Los socios podrían
participar para asegurar que los objetivos de política y control sean alcanzables en sus entornos. Todas las
partes deben comprender los riesgos y las atenuaciones que se están trasladando entre ellos y proporcionar la
seguridad de que esto se está haciendo de manera eficaz.
Cuadro 4. Componentes de la revisión de la gestión de políticas y controles
[Date]
104
Entradas
 Evaluar los
incidentes y el
incumplimiento,
determinar la causa
raíz
 Revisar las
actividades de
 Políticas aplicación de
operacionales y de políticas
seguridad  Revisar las
 Violaciones de conclusiones y
políticas, incidentes recomendaciones de
de cumplimiento, la auditoría
acciones de gestión  En cada fase del
tomadas desde el ciclo de vida, evalúe
último MR los impactos de  Si el desempeño
 Solicitudes de política y control de las políticas y
 Documentación de
cambio de políticas para ver si: el control cumple
MR con acciones y
 Resultados del  Plan: promover con las
responsabilidades
proceso "Aplicar y servicios que el expectativas de la
 Solicitud de
Evaluar" en la negocio ve como administración
cambios a políticas
Política SMF valiosos,  Acuerdo sobre la
o controles
 Cambios en los predecibles, causa raíz del
específicos
reglamentos, normas confiables y incumplimiento y
 Solicitud de
o prácticas de la rentables cualquier cambio
cambios en la
industria  Entregar: en la gestión de
gestión de políticas
 Hallazgos de Desarrolle los políticas
 Solicitud de
auditoría, servicios de manera  Si el entorno de
cambios en la
recomendaciones, efectiva, despliegue control es
gestión de control
cuestiones con éxito y esté listo apropiado o si se
 Riesgos, incidentes para las necesitan cambios
imprevistos operaciones.
 Controles fallidos o  Operar: los
de bajo rendimiento servicios son
 Autoevaluaciones operados,
de control mantenidos y
 Actas y acciones de apoyados de
la última reunión de acuerdo con la OLA
MR / SLA y cumplen
con la política
 Revisar las
evaluaciones de
riesgo y las
mitigaciones para
ver si son completas
y efectivas
El MR de políticas y control debe dar lugar a solicitudes identificadas de cambios que mejorarán la gestión y el
[Date]
105
cumplimiento de las políticas, así como mejorar la gestión del riesgo y el entorno general de control. Las
acciones para mejoras identificadas durante este MR deben ser documentadas y se debe conservar un registro
para demostrar el compromiso de TI con los procesos clave relacionados con el riesgo, la política y la gestión
del control. Esto proporcionará transparencia y evidencia que la administración ejecutiva y la junta directiva
pueden usar para evaluar las actividades de administración de TI.
Equipo SMF Focus

Hay dos responsabilidades de SMF del Equipo que son áreas focales en la Capa de
Gestión. Ellos son la responsabilidad de la gestión y la responsabilidad de
cumplimiento. Estas responsabilidades están involucradas en cada uno de los tres
SMFs en la capa de gestión. Cada SMF tiene tablas con responsabilidades y metas
que están más directamente relacionadas con las actividades en ese SMF en
particular.
Las siguientes dos tablas muestran los tipos de rol y sus responsabilidades y metas
generales.
Cuadro 5. Responsabilidad de Gestión y sus Tipos de Función Auxiliar parte de una serie más
amplia de herramientas y
Responsabilidades Metas Accelerators .
Tipo de rol
Descargar
 Promueve iniciativas de
TI  Bien dirigido y eficaz de
Obtenga Microsoft
 Aprueba estructuras y servicios de TI
Operations Framework
procesos globales de TI  Mejorar continuamente
Ejecutivo de TI  Posee métricas y el rendimiento con una Notificaciones de
benchmarking y hoja de ruta de mejora en aceleradores de
relaciones de directorio el lugar soluciones
y ejecutivo
Regístrese para conocer
las actualizaciones y los
 Gestiona procesos nuevos lanzamientos
 Identifica e involucra a  Decisiones de gestión
Realimentación
los participantes eficaces
apropiados en el proceso  Cumple con las
Envíanos tus
de decisión directivas
comentarios o
 Gestiona las  El riesgo y el valor
sugerencias
Gerente de TI dependencias de realizado se equilibran
realización de valor de adecuadamente
negocio de riesgo y de  Las métricas se utilizan
TI para la planificación de
 Posee una relación de informes y mejoras
negocios / TI
Gerente de  Ve que las decisiones  Las políticas dirigen

políticas de TI de gestión están eficazmente a la
[Date]
106
Responsabilidades Metas
Tipo de rol
informadas por la
política y que la política organización hacia
se utiliza efectivamente actividades apropiadas
en toda la TI
 Gestiona los programas  Procesos y expectativas

generales de gestión de GRC bien comunicados
Gerente de
riesgos y cumplimiento  Las personas entienden
Riesgos y
 Comunica los procesos sus responsabilidades de
Cumplimiento de
y requisitos de GRC a la GRC y toman medidas
TI
organización en consecuencia
 La organización de TI
 Valida el diseño y la
constantemente bajo
eficacia operativa de la
revisión y continuamente
organización de TI, los
mejorada
Aseguramiento e procesos y el entorno de
 Consejo y accionistas
Informes control
con confianza en la
 Recomienda cambios
decisión de gestión y los
para mejorar
procesos resultantes
 Gestiona las actividades

 Cambio planeado y
del proceso de gestión
Administrador de comprendido, con
del cambio para la
cambios riesgos gestionados
organización de TI
 Sigue lo que está

 El cambio es aprobado y
cambiando y su impacto
resulta en un estado
Administrador de  Rastrea los elementos
conocido en todo
configuración de configuración (CI)
momento
 Actualiza CMS
Cuadro 6. Cumplimiento de la responsabilidad y tipos de funciones de los

asistentes
Tipo de rol
 Comunica la estrategia
de TI y aprueba los
objetivos de gestión de  Progreso constante
TI hacia los objetivos
 Aprueba la política estratégicos logrados a
Ejecutivo de TI
 Mantiene el tono en la través de actividades
parte superior para la apropiadas y deseadas
cultura de control y
cumplimiento
[Date]
107
Tipo de rol
 Cumplimiento de  Cumplimiento de
políticas y comunicación directivas y políticas
 Evalúa la eficacia de la  Resultados previsibles y
Gerente de TI política fiables obtenidos por
 Solicita cambios a la medios apropiados
política o excepciones  Violaciones de políticas
 Organización no viola
 Posee administración de leyes o regulaciones
Gerente de riesgos, hoja de ruta de  Los riesgos son
Riesgos y cumplimiento, identificados y
Cumplimiento cumplimiento y medición gestionados
 Las políticas se aplican
 Entorno de control bien

 Diseño de auditorías y
comprendido
efectividad operativa de
 Validación
procesos
independiente del
Aseguramiento e  Investiga el
programa de
Informes incumplimiento
cumplimiento
 Cuenta con informes y
 Fraude o actividad
recomendaciones
indeseada descubierta
 Gestiona el entorno de
control interno  Entorno de control
 Documentos objetivos efectivo documentado
Gerente de de control y diseño de con pistas de auditoría
Control Interno control  Retención apropiada de
 Conserva evidencia de pruebas de control
actividad de control
 Analiza las regulaciones

y determina el impacto
de las políticas  La política refleja la
 Evalúa la posición legal respuesta deseada a la
relacionada con el regulación
Legal
cumplimiento  Riesgos legales
 Representa la opinión gestionados
legal en la toma de
decisiones
Gerente de  Gestiona la creación, el  Uso efectivo de la

políticas de TI cambio y el política para guiar las
mantenimiento de acciones
políticas  Conciencia a través de
 Posee comunicación políticas claramente
política y mejoras en la
[Date]
108
Tipo de rol
efectividad de las
escritas y comunicadas
políticas
Conclusión
Este documento ofrece una amplia visión general de la capa de administración de MOF y sus SMF, revisiones
de gestión y controles relacionados. El siguiente paso para poner en práctica MOF 4.0 es considerar las
necesidades de su organización, y luego leer y utilizar los SMF relevantes. Su guía paso a paso será de valor
para las organizaciones de TI cuyo objetivo es confiable, eficiente y obligar a los servicios de TI.
Administrar SMF de capa
 Gobierno, Riesgo y Cumplimiento

 Equipo
Realimentación
Función de administración de servicios de gobierno,

riesgo y cumplimiento
Posición del GRC SMF Dentro del ciclo de vida del

servicio de TI de MOF
El ciclo de vida del servicio de TI de MOF abarca todas las actividades y procesos involucrados en la
administración de un servicio de TI: su concepción, desarrollo, operación, mantenimiento y, en última instancia,
su retiro. MOF organiza estas actividades y procesos en Funciones de Gestión de Servicios (SMF), que se
agrupan en fases del ciclo de vida. Cada SMF está anclado dentro de una fase de ciclo de vida y contiene un
conjunto único de metas y resultados que apoyan los objetivos de esa fase. Los SMF pueden ser usados como
conjuntos independientes de procesos, pero es cuando los SMFs se usan juntos que son más efectivos para
asegurar la prestación de servicios con los niveles de calidad y riesgo deseados.
El SMF de Gobierno, Riesgo y Cumplimiento (GRC) pertenece a Manage Layer, la base del ciclo de vida del
servicio de TI de MOF. La siguiente figura muestra el lugar del GRC SMF dentro de la capa de administración,
así como la ubicación de la capa de administración dentro del ciclo de vida del servicio de TI.
[Date]
109
Figura 1. Posición del GRC SMF dentro del ciclo de vida del servicio de TI
Antes de utilizar este SMF, puede leer las siguientes guías de MOF 4.0 para obtener más información sobre el
ciclo de vida del servicio de TI de MOF y la capa Administrar:
 Manejar la capa
¿Por qué utilizar el GRC SMF?

Este SMF debe ser útil para aquellos que toman decisiones de compensación de cómo los recursos de TI se
utilizarán para cumplir con las metas y entregar valor de negocio; para aquellos que necesitan manejar el riesgo
de muchas fuentes, no sólo el riesgo de seguridad de TI; y para aquellos que necesitan asegurarse de que las
actividades de TI cumplan con las regulaciones y directivas. Este SMF discute directrices y principios para
GRC que se llevará a cabo durante los procesos y actividades a lo largo del ciclo de vida del servicio de TI.
 Establecer gobierno de TI.

 Evaluar, monitorear y controlar el riesgo.
 Cumplir con las directivas.
Descripción de GRC
La gobernabilidad, el riesgo y el cumplimiento son potencialmente actividades de gran alcance y entrelazadas

que requieren la participación de todos en la organización. Establecer una comprensión común de un tema tan
[Date]
110
amplio puede ser un desafío. Para ayudar a aclarar el tema, las siguientes secciones desglosan el alcance de
GRC y discuten:
 Lo que define IT GRC.

 Por qué las tres actividades se consideran juntas.
 Diferentes funciones de TI y sus respectivas perspectivas GRC.
 Cómo GRC se integra en el ciclo de vida del servicio de TI.
¿Qué es GRC?
La gobernanza de TI es una actividad de alto nivel de gestión que, cuando está bien ejecutada, aclara quién
tiene la autoridad para tomar decisiones, determina la responsabilidad por las acciones y la responsabilidad por
los resultados y se ocupa de cómo se evaluará el rendimiento esperado. La mayoría de las organizaciones
logran el gobierno de TI creando grupos, tales como comités de dirección, que reúnen a las partes correctas para
tomar decisiones.
La gobernanza a nivel de toda la Organización establece, entre otras cosas, resultados positivos y expectativas
de crecimiento, caminos elegidos para mejorar la satisfacción del cliente, nuevos productos y desarrollo del
mercado, todas las áreas donde la TI puede hacer una contribución significativa cuando se coordinan todos los
esfuerzos de gobernabilidad.
Las actividades de gobierno se llevan a cabo, ya sean planificadas o no. La falta de procesos planificados de
gobernanza puede resultar en el establecimiento arbitrario de objetivos y la toma de decisiones, luchas políticas
en torno al césped y desperdicio de recursos de esfuerzos confusos y conflictivos. La gobernanza planificada
debería resultar en:
 Políticas consistentes que trabajan juntas de manera efectiva.

 Tomar decisiones claras y responsables con un plan acordado para hacer compensaciones.
 Objetivos de gestión bien comunicados.
 Establecer expectativas de desempeño y evaluar el cumplimiento.
 Expectativas claras para un comportamiento aceptable en la búsqueda de metas de la gerencia.
El riesgo representa posibles impactos negativos en el logro de metas y puede surgir de acciones tomadas o no
tomadas. Las organizaciones utilizan los procesos de gobernanza para decidir las prioridades y el nivel de
esfuerzo que debe dedicarse a reducir la probabilidad y la magnitud de los impactos del riesgo.
Los procesos de buen gobierno buscan riesgos y ofrecen discusiones abiertas y enfoques claros para abordar el
riesgo. Una cultura de gestión de riesgos ayuda a prevenir la ignorancia deliberada del riesgo o el ocultamiento
intencional del riesgo y reduce el número de riesgos desconocidos que pueden dar lugar a consecuencias
negativas.
Los controles internos son los procesos y sistemas que existen para abordar los riesgos e influenciar o mitigar
los resultados potenciales. En el sentido más general, los controles internos proporcionan los medios por los
cuales los objetivos de gestión se logran de manera confiable y, al hacerlo, contribuyen a resultados positivos
para las partes interesadas.
El cumplimiento es un proceso que asegura que las personas estén al tanto de las regulaciones, políticas y
procedimientos que deben seguirse como resultado de las decisiones de la alta dirección. El cumplimiento es
también la evaluación de lo que realmente sucede en la organización en comparación con los resultados
previstos establecidos por los objetivos de la administración, las políticas y los requisitos reglamentarios.
[Date]
111
Los esfuerzos de cumplimiento de TI serán mejorados si la organización ha establecido claramente y ha
comunicado las expectativas de TI y las políticas que deben seguirse, y si ha desarrollado de manera proactiva
formas de evaluar el desempeño y la toma de decisiones.
Factores externos a las organizaciones, tales como regulaciones, estándares y mejores prácticas de la industria,
tienen impacto en cómo se hace el trabajo. Estos factores se evalúan e implementan con mayor eficacia cuando
se aplican los procesos de GRC adecuados. Por ejemplo, hay una serie de organismos y reglamentos
relacionados con la fiabilidad de los datos y la fiabilidad de la organización. Es posible que las organizaciones
de TI tengan que responder a una variedad de organismos reguladores de la Comisión de Valores y Cambios
(SEC, por sus siglas en inglés) a la Unión Europea (UE), y tal vez necesite abordar los requisitos y reglamentos
de gestión de datos tan variados como la Health Insurance Portability and Accountability Act HIPAA), la Ley
de Protección de Datos, Basel I / II, y Sarbanes Oxley (SOX). Las actividades de GRC pueden ayudar a las
empresas (y sus departamentos de TI) a convertirse en:
 Mejores custodios de los datos.

 Más alineados con las regulaciones.
 Mejor equipada para lograr los objetivos de gestión.
 Menos susceptible a actos fraudulentos.
¿Por qué se agrupan estas actividades como GRC?

Las tres prácticas que conforman GRC-gobierno, gestión de riesgos y cumplimiento-comparten tareas comunes
e interrelacionadas. Debido a que la gobernabilidad, el riesgo y el cumplimiento tienen áreas de responsabilidad
y proceso superpuestas, son más eficaces cuando se integran y se tratan como prácticas combinadas. Esto
reduce las islas de datos y los silos de actividad que, en última instancia, ralentizan la capacidad de respuesta de
la organización y contribuyen a un mayor riesgo al obscurecer la identificación del riesgo y producir
evaluaciones inadecuadas del impacto del riesgo. La combinación puede agilizar los procesos y proporcionar
transparencia y responsabilidad en una organización. Esto lo logra mediante:
 Reunir a los grupos adecuados de personas ( gobernanza ) para aclarar lo que debe suceder y evaluar lo
que podría interponerse en el camino ( gestión del riesgo ).
 Ayudar a la organización a determinar los compromisos de recursos ( gobernabilidad ) necesarios para
asegurar que se logren sus objetivos ( gestión de riesgos ).
 Dejar claro ( gobernanza y cumplimiento ) qué procesos y actividades deben o no deben suceder (
gestión de riesgos y cumplimiento ).
 Capturar y documentar los procesos y sus resultados como evidencia ( cumplimiento ).
Cuando una organización se dirige a las actividades de GRC de TI, varias preguntas clave ayudan a establecer
el contexto. Responder a estas preguntas muy probablemente requerirá conversaciones con grupos externos a
TI, tales como auditoría interna, legal, cumplimiento, y recursos humanos.
 ¿Cuál es el plan de gobierno de nuestra organización? ¿Quién decide cómo y qué decidir?
 ¿Cuál es la tolerancia al riesgo de nuestra organización? ¿Dónde podemos aceptar más riesgos y en qué
áreas debemos ser más cautelosos?
 ¿Hay problemas específicos de regulación y cumplimiento que se aplican a nuestra industria?
 ¿Cuál es nuestra cultura de cumplimiento, es decir, cómo determinamos que estamos haciendo lo que
dijimos que haríamos?
Al responder a estas preguntas y trabajar en planes integrados de GRC, se mejora la alineación de las metas de
TI y de negocio porque las personas adecuadas están tomando las decisiones correctas en el momento adecuado.
[Date]
112
¿Quién debe cuidar de GRC?
Aunque todos en una organización están involucrados en actividades de GRC de TI en algún nivel, GRC
requiere que tres grupos principales sean eficaces: ejecutivos, administradores de TI y profesionales de TI.
Estos tres roles organizacionales tienen diferentes preocupaciones y implicaciones relacionadas con GRC.
El rol del GRC de los profesionales de TI enfatiza la aplicación de las decisiones que se han tomado a través de
los procesos de gobernanza a las actividades y procedimientos cotidianos. Los profesionales de TI se centran en
los aspectos de cumplimiento de GRC y el uso de conocimientos técnicos en profundidad para ayudar a
identificar y mitigar los riesgos y encontrar maneras de automatizar los controles de manera eficiente.
Aseguran que las actividades y los sistemas funcionen dentro de las directrices que se han establecido en el
proceso GRC. Tienen conocimientos especializados que pueden usarse para refinar controles basados en
capacidades o restricciones tecnológicas.
Los gerentes de TI a menudo participan en grupos de GRC que toman decisiones de trade-off. Un mandato
principal para la gerencia consiste en traducir los objetivos estratégicos (establecidos en los niveles ejecutivo y
de junta) en directivas y políticas tácticas y tangibles que resultarán en servicios, soluciones, políticas y
actividades cotidianas. Los gerentes de TI impulsan la traducción de los objetivos estratégicos en metas
tácticas, impulsan el análisis del riesgo a esos objetivos e impulsan la identificación de los controles internos
para mitigar esos riesgos.
Finalmente, en el nivel ejecutivo, el CIO tiene la responsabilidad de todo el proceso GRC dentro de TI. Deben
establecerse las estructuras adecuadas para reunir a las personas adecuadas en el momento adecuado para guiar
eficazmente la realización de la estrategia. El CIO debe asegurarse de que la gestión de riesgos es parte de la
discusión en estos foros de gobierno como una herramienta para ayudar a informar las opciones y avanzar hacia
un denominador común para tomar decisiones de trade-off.
Además, el CIO debe estar al tanto de las funciones de aseguramiento (auditoría), que evalúan los objetivos, los
controles internos y su diseño y eficacia operativa. La auditoría proporciona hallazgos y recomendaciones al
ejecutivo y al consejo para que la organización se beneficie de una gestión inteligente e intencional.
Evaluaciones similares de aseguramiento ayudan a proporcionar a los accionistas ya otras partes externas
interesadas una visión del funcionamiento de una organización. La toma de conciencia por parte del CIO de los
hallazgos de aseguramiento asegura que el enfoque de la organización a la gobernabilidad se fije en el nivel
superior y que las actividades de GRC se entiendan y se utilicen en todos los niveles.
¿Cuál es la relación entre el GRC SMF y el ciclo de

vida de TI?
Cada fase del ciclo de vida de los servicios TI tiene sus propias metas y actividades. Aunque los grupos y las
personas pueden variar según la fase y la actividad y los insumos y productos pueden diferir, la importancia de
tener claridad sobre la toma de decisiones, la gestión de riesgos y el cumplimiento de la normativa no cambia.
En la Fase del Plan, el objetivo es asegurarse de que los servicios de TI ofrecidos al negocio sean valiosos,
predecibles, confiables y rentables, y que respondan a las necesidades empresariales en constante cambio.
Para ayudar a alcanzar este objetivo, el GRC se centra en:
 Transferencia de estrategia corporativa a la estrategia de TI.
[Date]
113
 Estructura de gobierno y derechos de decisión.
 Objetivos de gestión definidos.
 Principales riesgos para alcanzar los objetivos identificados.
 Entorno normativo general.
 Política definida.
En la fase Entregar, el objetivo es asegurarse de que los servicios de TI que el negocio y la TI han acordado se
desarrollen de manera efectiva, se desplieguen con éxito y estén listos para Operaciones.
En esta fase, el enfoque de GRC es:
 Arquitectura de la solución compatible con los requisitos de la organización.

 Participantes del proyecto, metodología y riesgos identificados.
 El proceso de realización de valor.
 El ciclo de vida del desarrollo del servicio.
 Mitigación de riesgos.
 Definición de controles internos.
 Definición de procedimientos.
En la fase de operación, el objetivo es asegurarse de que los servicios desplegados son operados, mantenidos y
soportados de acuerdo con los objetivos SLA establecidos por el negocio y la TI.
 Procedimientos y actividades de control.

 Grabación y documentación.
 Retención de pruebas de que el control funciona según lo diseñado.
GRC crea flujos de procesos organizados en todas las fases del ciclo de vida, ayudando a la toma de decisiones,
equilibrando las compensaciones, estableciendo una estrategia mediante la gestión de los riesgos y
asegurándose de que la gestión de riesgos es apropiada para las actividades que se llevan a cabo. Al asistir a
estos GRC , la TI puede contribuir mejor a la viabilidad y mejoramiento a largo plazo de la organización y es
capaz de establecer con claridad: "Así es como manejamos la TI y gestionamos el riesgo".
Tipos de rol SMC de GRC

Las responsabilidades primarias de SMF del Equipo que se aplican a GRC son la rendición de cuentas de la
Administración y la Cumplimiento. Los tipos de rol dentro de estas responsabilidades y sus actividades
principales dentro de este SMF se muestran en las tablas siguientes.
Cuadro 1. Responsabilidad de gestión y sus tipos de función de asistente
Tipo de rol Responsabilidades Función en este SMF

Ejecutivo de TI  Patrocinadores IT GRC  Posee la guía de procesos de GRC y
 Aprueba estructuras y procesos toma de decisiones de TI
globales  Garantiza una clara apropiación y
 Utiliza métricas y responsabilidad
benchmarking para evaluar el  Tendencias claras en el rendimiento de
rendimiento de GRC GRC
[Date]
114
 Participa en la toma de  Asegura que la hoja de ruta de mejora
decisiones está en su lugar
 Gestiona los procesos de

gobierno  Garantiza que GRC se integra en las
 Identifica e involucra a los decisiones de gestión
participantes del GRC  Asegura que el estado de cumplimiento
 Gestiona las dependencias de se entiende
realización de valor de negocio  Facilita la alineación comercial / TI a
Gerente de TI
de riesgo y de TI través de procesos GRC
 Posee una relación de negocios  Garantiza que las métricas GRC se usan
/ TI para la planificación de informes y
 Utiliza métricas para evaluar el mejoras
rendimiento de GRC
 Entiende las decisiones de  Garantiza que las políticas reflejan los

compromiso del GRC y las resultados del proceso de GRC y dirigen a
Gerente de políticas
posiciones resultantes que se la organización hacia actividades
de TI
reflejan apropiadas
 Gestiona los programas

 Asegura procesos y expectativas GRC
generales de gestión de riesgos
bien comunicados
Gerente de Riesgos y cumplimiento
 Asegura que las personas entiendan sus
y Cumplimiento de  Comunica los procesos y
responsabilidades de GRC y tomen
TI requisitos de GRC a la
acción en consecuencia.
organización
efectividad operativa de las
 Resiste que GRC está constantemente
Aseguramiento e estructuras y procesos de GRC
bajo revisión y continuamente mejorado
Informes  Recomienda cambios para
mejorar
 Gestiona las actividades del  Garantiza que los procesos GRC resultan
Administrador de proceso de gestión del cambio en un cambio que se entiende
cambios para la organización de TI  Garantiza la gestión de los riesgos
 Sigue lo que está cambiando y

 Asegura que GRC da como resultado un
su impacto
cambio que es aprobado y da como
Administrador de  Rastrea los elementos de
resultado un estado conocido en todo
configuración configuración (CI)
momento
 Actualiza CMS
Cuadro 2. Cumplimiento de la responsabilidad y sus tipos de función de asistente

Ejecutivo de TI  Comunica la estrategia de TI y  Asegura que se logre un progreso
aprueba los objetivos de gestión de consistente hacia los objetivos
TI estratégicos mediante actividades
[Date]
115
 Aprueba la política
 Establece tonos en la cima para el apropiadas y deseadas
cultivo de control y cumplimiento
 Cumplimiento de las directivas y

 Hace cumplir la política de políticas
comunicación y cumplimiento  Asegura resultados predecibles y
 Evalúa la adherencia y eficacia de confiables que se logran a través de
Gerente de TI la política medios apropiados
 Solicita cambios a la política o  Garantiza que las violaciones de las
excepciones políticas se aborden de forma efectiva
y oportuna
 Gestiona los programas generales

 Asegura que los esfuerzos de riesgo y
de riesgo y cumplimiento
cumplimiento estén coordinados y
 Asegura que las personas estén
sean consistentes entre sí
entrenadas y comprendan los
Gerente de Riesgos  Proporciona capacitación y
mandatos de cumplimiento
y Cumplimiento de preparación suficientes para mantener
 Revisa eventos de riesgo no
TI el cumplimiento
anticipado y problemas de
 Asegura que los eventos imprevistos
incumplimiento para identificar
sean abordados
mejoras a procesos
 Gestiona los procesos generales de

políticas
 Asegura que las políticas son claras,
 Posee comunicación de la política a
actuales y bien comprendidas para
Gerente de políticas la organización y retroalimentación
que resulten en un comportamiento
de TI sobre temas de política
apropiado
 Coordina la gestión de solicitudes
de excepción de políticas
 Investiga el incumplimiento de las  Posee una validación independiente

políticas y la elusión del cumplimiento
Aseguramiento e
 Emite informes y recomienda  Detecta fraude o actividad
Informes
cambios intencional no permitida
Metas del GRC

El objetivo general de GRC es proporcionar servicios de TI que sean eficaces, eficientes y conformes .
Específicamente, esto implica:
 Establecer una toma de decisiones clara y efectiva en la gestión de los activos de TI.
 Gestionar el riesgo de manera eficaz.
 Cumplimiento de las políticas, leyes y reglamentos aplicables.
Tabla 3. Resultados y Medidas de los Objetivos del GRC SMF
Resultados Medidas
[Date]
116
 Las actividades de TI generan rentabilidad esperada de la inversión
 El uso de los activos de TI cumple con las previsiones
 La toma de decisiones es oportuna y no requiere reexamen
Buen gobierno  La confidencialidad, integridad y disponibilidad de los activos de TI son
congruentes con las necesidades y directivas de la empresa
 Las políticas se crean y se gestionan de manera oportuna
 Identificación y gestión proactiva de posibles amenazas y vulnerabilidades a

los activos de la empresa
 Proceso claro y documentado para identificar el riesgo; determinar el
impacto y la probabilidad; priorizar y gestionar mediante mitigación,
Gestión eficaz del riesgo
transferencia o aceptación; y la identificación de controles y soluciones
apropiados
 Confidencialidad, integridad y disponibilidad de los activos de TI
 Gestión del impacto de las leyes y reglamentos en la realización del valor

comercial
 Identificación de las políticas, leyes y reglamentos de la organización
Cumplimiento de los
aplicables
reglamentos, leyes y
 Diseño, desarrollo e implementación de activos de TI que soportan el
políticas
cumplimiento de las leyes y reglamentos
 Reporte de controles mensurables para auditoría y gestión
Términos clave
Término Definición
Procesos que aseguran la conformidad de TI con las regulaciones gubernamentales, las leyes y
las políticas específicas de la empresa-en otras palabras, un medio para informar a las personas
Conformidad
sobre la actividad apropiada y también asegurar que la organización está haciendo lo que ha
dicho que hará
Un proceso que prepara una organización para responder coherentemente a los resultados
Contingencia
planificados, así como a incidentes no planificados
Evidencia Prueba comprobable de que las políticas y los procesos funcionan como se esperaba
La gobernanza especifica quién debe tomar decisiones y cómo, cómo comunicarse eficazmente
Gobernancia y cuándo debe suceder, y cómo seguir el progreso de TI en relación con los objetivos
empresariales
Cualquier información, datos, propiedad intelectual, sistema o máquina propiedad de la
Activos de TI
empresa que se utilice en el curso de actividades empresariales
Controles de Una actividad específica realizada por personas o sistemas diseñados para asegurar el
TI cumplimiento de los objetivos empresariales
Procesos o actividades que se establecen con el propósito de reducir las posibles consecuencias
Mitigación
de un riesgo reduciendo la probabilidad o el impacto del riesgo
Riesgo La posibilidad de efectos adversos en los objetivos de negocio o TI. El riesgo se mide en
[Date]
117
términos de impacto, probabilidad y exposición
Gestión de
Los esfuerzos de una organización para abordar el riesgo en el entorno de TI
riesgos
Relación entre gobierno, riesgo y cumplimiento
Figura 2. La relación entre gobernabilidad, riesgo y cumplimiento
Desde el punto de vista del proceso, GRC es diferente de muchos de los SMF de MOF. Su aplicación no es,
estrictamente hablando, un flujo secuencial -primera A sucede, entonces B, entonces C. En cambio, como
muestra la Figura 2, son tres conjuntos separados de procesos-gobernabilidad, riesgo y cumplimiento-cualquiera
de los cuales puede tener lugar simultáneamente o en tándem con los otros procesos.
Sin embargo, para facilitar la comprensión, este SMF discutirá estas actividades interconectadas como procesos
separados:

Las siguientes secciones tratan estas actividades en detalle. En la Guía de administración de riesgos de
seguridad de Microsoft se puede encontrar un análisis exhaustivo de la gestión de riesgos especializada
relacionada con el riesgo de seguridad: http://www.microsoft.com/technet/security/guidance/default.mspx
Proceso 1: Establecer Gobierno de TI

There are no mem
La gobernanza describe el liderazgo, la estructura de toma de decisiones, los procesos y la rendición de cuentas
que determinan cómo una organización recibe el trabajo. La gobernanza comienza en la cima, pero requiere la
[Date]
118
participación en todos los niveles de la organización. La naturaleza de las decisiones tomadas y la información
pasada a otros participantes de GRC se retrata en la Figura 3. Como muestra, hay formas para que todos los
miembros de la organización contribuyan a una gobernabilidad exitosa.
Mirando los varios grupos que pasan la información a través de la organización demuestra que es provechoso
tener una manera común de comunicarse sobre la información de GRC. Este GRC SMF se centra en los
mecanismos para conectar estos niveles utilizando las actividades de gestión y control de riesgos, lo que resulta
en una mejor toma de decisiones y el establecimiento de la rendición de cuentas por los resultados.
Figura 3. El entorno de gobierno: participantes y tipos de información
La gobernanza de TI puede ser mejorada a través de la clarificación de objetivos, funciones y responsabilidades

y mediante la aplicación de la gestión de riesgos en todo el ciclo de vida de los servicios de TI. Esto asegura
que la TI es capaz de entender la estrategia y los requisitos empresariales, ofrecer valor al negocio mientras
mitiga los riesgos de TI, y establecer la rendición de cuentas durante todo el ciclo de vida.
En términos cotidianos, estos conceptos se harán más concretos por el papel específico y las actividades
involucradas. Por ejemplo, el profesional de TI que configure buzones de Microsoft® Exchange Server
necesitará conocer las políticas de retención y purga de correo electrónico y asegurarse de que estas políticas se
apliquen de manera efectiva mediante reglas de configuración y Directiva de grupo. El gerente de TI debe ser
consciente de los objetivos de la gerencia con respecto a las comunicaciones corporativas y qué requisitos
reglamentarios podrían estar involucrados para asegurarse de que la opinión legal apropiada es llevada a cabo
para que se desarrollen las políticas requeridas.
El CIO y otros ejecutivos deben hacer su determinación de que la estrategia de su organización y cualquier
regulación que afecte la comunicación corporativa es racional y que han establecido una dirección y una política
apropiadas para el resto de la organización.
[Date]
119
Figura 4. Establecer gobierno de TI
Actividades: Establecer Gobierno de TI

En el nivel de actividad, los procesos de gobierno de TI ayudan a alinear la TI con el negocio a través del
proceso de toma de decisiones utilizado para definir las acciones para alcanzar los objetivos estratégicos. Esta
alineación se produce a través de discusiones de trade-off y toma de decisiones. Como se mencionó
anteriormente, la gobernanza es un proceso de gestión que define los derechos de decisión, garantiza que la
tolerancia al riesgo se ha tenido en cuenta en las decisiones y proporciona una forma de establecer expectativas
que pueden evaluarse a través de un proceso de cumplimiento. El establecimiento de la estructura y el proceso
de gobierno debe hacerse antes de tomar decisiones. Hacer esto ayudará a identificar a los representantes
[Date]
120
empresariales y de TI que tomarán decisiones conjuntamente y se harán responsables. Los resultados de las
actividades de gobernabilidad en última instancia afectan cómo se eligen las iniciativas y las tecnologías y
proporcionan el contexto para los recursos de TI más valorados: las personas, para obtener oportunidades y
beneficios.
El proceso para establecer la gobernanza de TI incluye las siguientes actividades:
 Definición de la visión . Ajustar la visión no es un aderezo. Esta actividad determina la estructura

general de gobierno de la TI y crea poder de decisión y responsabilidad. La cultura de la organización
de TI estará fuertemente influenciada por la forma en que la gobernanza se abraza y se pone en acción.
 Alineación de TI para el negocio . Esta actividad también determinará la idoneidad del ajuste entre la
gobernanza general de la organización y la gobernanza de TI específicamente. La gobernanza de TI
sufrirá si esta coordinación no se establece.
 Identificación de reglamentos y normas . Los requisitos y estándares regulatorios específicos de la
industria juegan un papel crítico para medir la exactitud y el rigor requeridos para el gobierno de TI.
Estos factores deben ser examinados y aplicados apropiadamente.
 Creación de políticas . Obtener las políticas correctas ayuda a guiar el rendimiento que proporciona
resultados basados en los comportamientos esperados y en el uso adecuado de los recursos.
Tabla 5. Actividades y Consideraciones para Establecer Gobierno de TI
Ocupaciones Consideraciones
 La organización está sujeta a requisitos reglamentarios u otros requisitos externos
para la gobernanza
 La gerencia quiere una comprensión clara de la manera en que se ejecuta
Suposiciones
 La dirección de negocios quiere entender la contribución que hace TI a los
resultados empresariales
Establecer la Preguntas clave:

visión
 ¿Cuáles son los principales objetivos estratégicos del negocio?
 ¿Qué nivel de formalidad se necesita para cumplir con los requisitos de GRC?
 ¿Cómo se mide la realización del valor de TI?
 ¿Cómo se debe medir el rendimiento de TI?
Entradas:
 Objetivos estratégicos claros del negocio

 Requisitos relevantes de las normas y organismos reguladores aplicables
 Historia del cumplimiento de la organización (o incumplimiento)
 Indicación de la tolerancia al riesgo de la organización
 Recomendaciones de auditoría interna para la gobernanza
 Enfoque definido para medir la realización del valor
 Indicadores de rendimiento definidos
Salidas:
 Estructura de los foros para las actividades de gobernanza

 Políticas de gobierno y planes de comunicación
 Plan general de gestión de riesgos informáticos
[Date]
121
 Responsabilidad por las decisiones de gobernanza
 Monitoreo y métricas de rendimiento
 Requisitos de realización de valor
 Carta de gobierno de TI y propietario
Mejores prácticas:
 Objetivos comprensibles y claras implicaciones requieren una buena

comunicación. Dar muchas oportunidades para hacer preguntas, replantear y
parafrasear.
 Cuando sea posible, mapee las actividades de gobierno de TI a los procesos de
negocio existentes para la estrategia, la planificación y la toma de decisiones.
 Diseñe la arquitectura de la información para que el monitoreo del desempeño y el
monitoreo del cumplimiento normativo puedan hacer uso de la misma información
cuando sea posible.
 Para obtener más información acerca de la configuración de la visión y la
alineación de la estrategia, consulte la Función de gestión del servicio de alineación
empresarial / TI de MOF .
Alinear TI con el Preguntas clave:

negocio
 ¿Qué partes interesadas clave son necesarias para tomar decisiones de
compensación?
 ¿Qué procesos de calificación y toma de decisiones utiliza el negocio para
determinar iniciativas y proyectos generales?
 ¿Cuál es el enfoque de riesgo de la organización? ¿Cuál es su cultura de
cumplimiento de las directivas?
Entradas:
 Objetivos prioritarios para las empresas, directivas de gestión y propietarios

identificados
 Interpretación jurídica de los requisitos reglamentarios
 Borrar los requisitos de cumplimiento desde la perspectiva tanto del negocio como
de TI
Salidas:
 Participantes identificados para varias reuniones de gobernanza (como comités de

dirección)
 Actividades coordinadas de planificación empresarial y de TI
 Factores a considerar en la planificación estratégica de TI
 Funciones y responsabilidades claramente comprendidas entre los negocios y las TI
Mejores prácticas:
 Reducir las luchas políticas turf reuniendo a las partes interesadas con un proceso
claro para determinar las compensaciones y los caminos de escalada acordados.
 La alineación de negocios / TI puede ocurrir a través de muchos niveles de una
organización; proporcionar un foro para la discusión a múltiples niveles.
[Date]
122
alineación de estrategias, consulte Función de gestión del servicio de alineación de
negocios / IT de MOF .
Preguntas clave:
 ¿Qué normas o requisitos reglamentarios basados en la industria son los impulsores

de la organización?
 ¿Existe un marco generalmente aceptado (como COBIT o ISO 20000) que se
correlaciona bien con la organización en términos de la industria y la cultura de
conformidad de la empresa?
Entradas:
 Representación comercial de los requisitos reglamentarios para el negocio

 Análisis de TI de los marcos de gestión de servicios de TI
 Capacidades y limitaciones de TI: habilidades y tecnologías
Identificar normas
Salidas:
y normas
 Un marco de gobierno que represente la menor carga organizativa para el mayor
beneficio de la eficiencia, la efectividad, el cumplimiento y la alineación con el
negocio
Mejores prácticas:
 Los marcos son puntos de partida. Proporcionan los conceptos básicos que luego
requieren la elaboración y aplicación a las realidades de la organización específica.
 Se necesita una comprensión profunda de los factores de la empresa y de la
industria para adaptar el marco a las consideraciones únicas de la propia empresa.
 Los profesionales de TI tienen conocimientos técnicos que deben ser considerados
al aplicar el marco elegido para que sea alcanzable y soportable.
Crear política Preguntas clave:
 ¿Cuáles son las áreas en las que la compañía desea explícitamente requerir
comportamientos deseados?
 ¿Qué procesos deberían tener medidas específicas de desempeño definidas por la
política?
 ¿Qué dice la representación legal sobre la política propuesta?
Entradas:
 Cualquier incumplimiento o cuestiones reglamentarias en las que la empresa no

haya alcanzado las acciones deseadas
 Objetivos de gestión senior para el comportamiento corporativo con implicaciones
claramente entendidas
Salidas:
[Date]
123
 Política documentada y comunicada
 Mapeo de la política a los objetivos de control
 Políticas promulgadas en la práctica
Mejores prácticas:
 Para obtener más información acerca de la creación y el uso de políticas, consulte

Función de administración de servicios de políticas de MOF .
 La auditoría proporciona una evaluación basada en la evidencia y recomendaciones
sobre la promulgación de políticas y el ambiente de control.
Proceso 2: Evaluar, monitorear y controlar el riesgo

La gestión del riesgo es el intento de TI de abordar el riesgo mientras se alcanzan los objetivos de gestión. Las
organizaciones de TI logran un éxito a largo plazo al manejar el riesgo mediante el uso efectivo de los controles
internos .
Los controles internos son actividades específicas realizadas por personas o sistemas diseñados para asegurar
que se cumplan los objetivos del negocio. El diseño cuidadoso, la documentación y el funcionamiento de los
controles son cruciales en todos los niveles de la organización. Estar "en control" significa que las posibilidades
de experimentar impactos adversos de eventos indeseables están en niveles aceptables y que la probabilidad de
lograr objetivos es satisfactoria. El control interno está interrelacionado y directamente afectado por las
actividades de gobierno de una organización.
La Figura 5 ilustra las actividades de gestión de riesgos. Es importante entender que el proceso de gestión de
cada riesgo pasa por todas estas actividades al menos una vez y, a menudo, ciclos a través de numerosas veces.
Debido a que cada riesgo tiene su propia línea de tiempo, múltiples riesgos podrían estar en cada etapa en
cualquier punto dado.
[Date]
124
Figura 5. El ciclo generalizado de evaluación, monitoreo y control del riesgo
Actividades: Evaluar, monitorear y controlar el

riesgo
El proceso de identificar riesgos y controles toca todos los aspectos de la empresa. Proporciona una base para
los esfuerzos de cumplimiento de la empresa estableciendo claramente la relación entre las metas, los factores
que podrían impedir el logro de las metas y cómo se están tratando esos eventos potenciales.
Cada fase del ciclo de vida del servicio de TI tiene un conjunto asociado de riesgos característicos y actividades
correspondientes para gestionarlos:
 En la Fase del Plan, el enfoque se centra en los riesgos relacionados con estrategias específicas,
arquitecturas de información y riesgos en toda la cartera de TI.
 La fase de entrega evalúa el riesgo desde una perspectiva orientada al proyecto, que está más orientada
y limitada en el tiempo.
 La fase de operación se centra en las actividades cotidianas y los riesgos que pueden afectar a las
operaciones fiables.
 Por último, Manage Layer trata de la gestión de riesgos desde un punto de vista general y enfocado:
general en términos de estructuras de gobierno, coordinación organizacional, toma de decisiones y
planes de comunicación; centrada en la gestión del cambio y la configuración y los riesgos que
provienen de la modificación de elementos del entorno de servicios de TI, así como de los procesos y
recursos que forman parte de ese entorno.
Las categorías de riesgo surgen a lo largo de las diversas fases del ciclo de vida del servicio. Implican riesgos
financieros, operativos, de reputación, de cuota de mercado, de ingresos y regulatorios, así como otros riesgos
[Date]
125
que son más específicos para la industria de una organización en particular (por ejemplo, la asistencia sanitaria)
o una actividad que actualmente ocurre (como una fusión o adquisición) .
Al abordar la gestión de riesgos de una manera que estimule la reflexión sobre las posibles consecuencias de
las actividades, la evaluación de su impacto y, a continuación, adoptar un enfoque muy explícito para abordar
estos riesgos, la TI obtiene una ventaja considerable. Una organización no puede abordar el riesgo de manera
inteligente sin que la TI y el negocio se sienten juntos y definan tolerancias de riesgo y objetivos de control.
Dado que las consecuencias del riesgo se evalúan en términos de alcanzar los objetivos de negocio, esto ayuda a
integrar la TI en las discusiones de negocios y las compensaciones y elimina después del hecho de apuntar en
virtud de la transparencia que implica la gestión de riesgos.
Este proceso incluye las siguientes actividades:
 Mejorar los procesos para alcanzar los objetivos de gestión

 Identificación del riesgo
 Analizar y priorizar los riesgos
 Identificación de los controles
 Análisis de los controles
 Planificación y programación de la implementación
 Seguimiento e informes de riesgos y controles
 Mandos de mando
 Aprender de los esfuerzos previos y actualizar la base de conocimientos
Tabla 6. Actividades y Consideraciones para la Evaluación, Monitoreo y Control de Riesgos
 La gestión de los riesgos se extiende más allá de la seguridad y la privacidad de los
datos a una variedad de riesgos que pueden afectar el cumplimiento de los objetivos
Suposiciones de la administración (incluyendo, entre otros: riesgo financiero, riesgo de no cumplir
compromisos de desempeño.
Dirección de los Preguntas clave:

objetivos de
gestión  ¿Qué podría ocurrir que pudiera afectar el logro de las metas y objetivos de la
administración?
 ¿Qué se puede hacer para maximizar la capacidad de alcanzar los objetivos?
 ¿Cuáles son los procesos comerciales sensibles al riesgo que utilizan los sistemas de
TI?
 ¿Cuál es el perfil de tolerancia al riesgo que mejor describe esta empresa?
Entradas:
 Plan estratégico y los objetivos de gestión resultantes

(ver el Business / IT Alignment SMF )
 Condiciones reglamentarias y comerciales
 Resultados (éxito y fracaso) de la gestión de riesgos hasta la fecha
Salida:
[Date]
126
 La tolerancia al riesgo y el enfoque de la gestión de riesgos de la organización
Mejores prácticas:
 La gestión de riesgos ocurre muchas veces durante cada fase del ciclo de vida del
servicio de TI. La comprensión de los riesgos relativos a los objetivos de una fase
particular establecerá el dominio del riesgo.
 Este dominio de riesgo, combinado con la única tolerancia al riesgo de la compañía,
guiará el enfoque de la gestión de riesgos en esa fase del ciclo de vida del servicio de
TI.
 La tolerancia al riesgo es fluida y cambia con oportunidades y recompensas
potenciales, así como incidentes y posibles sanciones.
Identificar riesgo Preguntas clave:
 ¿Cómo se clasifican los servicios empresariales en términos de criticidad

empresarial y la naturaleza de los datos utilizados en esos servicios?
 ¿Cuál es la historia del cambio para los sistemas que componen cada servicio? ¿Qué
cambios se planean?
 ¿Cuál es la complejidad del sistema end-to-end (atraviesa múltiples interfaces, se
extiende a los sistemas de socios comerciales, se basa en datos o servicios fuera del
control de la empresa)?
Entradas:
 Misión de la empresa (y unidades de negocio, en su caso)

 Tolerancia al riesgo y enfoque de la gestión de riesgos
 Cartera de TI (consulte el Business / IT Alignment SMF )
 Mapas de servicios de TI (consulte el SMF de Business / IT Alignment )
 Informes de incidentes, eventos de seguridad
 Entorno normativo, eventos de incumplimiento
Salida:
 Informe de caracterización de riesgos de servicios de TI
Mejores prácticas:
 Asegurar que la alta dirección está comprometida con el proceso de gestión de

riesgos.
 Asegurar que los participantes en la gestión de riesgos tengan experiencia en
sistemas de TI y procesos empresariales y comprensión del impacto potencial para el
negocio.
 Revisar los servicios empresariales críticos; evaluar cada uno de los riesgos
estándar y la lluvia de ideas para los posibles riesgos. Haga esto con un equipo que
represente diferentes perspectivas y áreas de especialización.
 La identificación del riesgo también debe incluir la notificación al stakeholder de
riesgo. La identificación del riesgo debe repetirse frecuentemente.
[Date]
127
 Para obtener más información sobre la identificación de riesgos, consulte NIST SP
800-30 ( http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf ).
Preguntas clave:
 ¿Qué impactos tendrán los riesgos y amenazas (situaciones o estados que podrían
causar daño) en la organización en su conjunto?
 ¿Cuáles son los impactos probables de las amenazas a objetivos de gestión
específicos y procesos de negocio asociados?
 ¿Se pueden descomponer las amenazas y los impactos en aquellos que podrían
perjudicar el rendimiento del servicio de TI pero no comprometer los datos?
 ¿Cuáles son las vulnerabilidades conocidas en los sistemas que componen los
servicios de TI?
 ¿Cuáles son las amenazas para los sistemas individuales?
Entradas:
 Caracterización de los riesgos de los servicios de TI

 Amenazas
 Vulnerabilidades
Analizar y
priorizar los Salida:
riesgos
 Lista de amenazas y vulnerabilidades con riesgo prioritario puntuaciones
Mejores prácticas:
 Transformar las estimaciones o datos sobre los riesgos específicos que se

desarrollaron durante la identificación del riesgo en una forma que puede utilizarse
para tomar decisiones sobre la priorización.
 Mida el riesgo en términos de probabilidad multiplicado por el impacto y utilice las
puntuaciones resultantes para ayudar a priorizar.
 Priorizar los riesgos para que los más importantes se puedan abordar con recursos
suficientes.
 Haga una lluvia de ideas para posibles riesgos insospechados. Si se identifican
algunos, tratar de evaluar si su impacto potencial (incluso si hay una baja
probabilidad) aún merece atención.
 Ver Recursos de mitigación de vulnerabilidades y amenazas de Microsoft a
http://www.microsoft.com/technet/security/learning/threats/all/default.mspx .
Identificar los Preguntas clave:

controles
 Sobre la base de amenazas y vulnerabilidades para la compañía, ¿cuáles son los
mejores puntos de control y actividades para mitigar esos riesgos?
 ¿Qué vulnerabilidades de confidencialidad, integridad y acceso a los datos deben
abordarse con controles explícitos?
Entradas:
 Listados de amenazas y vulnerabilidades con calificaciones
[Date]
128
 Lista de controles primarios y controles de compensación (que usualmente operan
para detectar problemas después del hecho)
 Entrevistas con el personal responsable de los objetivos de negocio y procesos
asociados
 Entrevistas con personal en áreas de control de TI
 Cuestiones y informes de auditoría
Salida:
 Plan que asigna controles a los servicios de TI ya los procesos empresariales
Mejores prácticas:
 Los controles trabajan juntos para crear un entorno de control. Al evaluar un solo
control, tenga en cuenta la constelación de controles relacionados, y considere cómo
un control podría compensar a otro.
Preguntas clave:
 ¿Qué objetivos empresariales están siendo abordados por los controles

identificados?
 ¿Qué evidencia demuestra que los controles están funcionando como se desea?
 ¿Qué requiere la auditoría en términos del tipo de evidencia y su retención?
Entradas:
 Informes de auditoría
 Lista de controles existentes
 Entrevistas con personal en cada área de control
 Plan que asigna controles a los servicios de TI ya los procesos empresariales
Analizar los Salida:

controles
 Plan de desarrollo del control
Mejores prácticas:
 Los informes de auditoría proporcionan un análisis independiente de los controles y

por lo general tienen recomendaciones para mejorar el entorno de control.
 Un foco prioritario debe estar en controles fundamentales que deben funcionar
correctamente para que otros controles puedan depender de ellos (por ejemplo,
controles para acceso a datos).
 Controles de diseño con procesos de recolección de evidencia construidos para hacer
más eficientes y eficaces la auditoría y otras pruebas de control. Las pruebas de
control requieren la prueba (en forma de evidencia) de que el control está en su lugar
y funciona como se esperaba.
Planificar y Preguntas clave:

programar la
implementación  De la lista de controles planeados, ¿qué controles no están en su lugar?
[Date]
129
 ¿Cuál es la prioridad de desarrollo para los controles que no están en su lugar?
Entradas:

Salidas:
 Plan de desarrollo de riesgos y control

 Mitigación identificada
 Lista de solicitudes de cambio relacionadas con el control
Mejores prácticas:
 Utilice la información obtenida del análisis de riesgo para ayudar a formular

estrategias, planes, peticiones de cambio y acciones.
 Utilizar los procesos de gestión del cambio para garantizar que los planes de riesgo
se aprueben e incorporen a los procesos e infraestructuras habituales del día a día.
Consulte el SMF Cambiar y configurar MOF .
Preguntas clave:
 ¿Cuál es el estado de los riesgos y los controles?
Entradas:
 Monitoreo del servicio de TI

 Evidencia retenida de la actividad de control
 Informes de estado para proyectos de desarrollo de control
Salidas:
Rastrear y
 Informes de riesgos
reportar riesgos y
 Control de informes de estado de desarrollo
controles
Mejores prácticas:
 Monitorear el estado de los riesgos específicos y el progreso en sus respectivos

planes de acción.
 Monitorear la probabilidad, el impacto, la exposición y otras medidas de riesgo para
cambios que podrían alterar los planes de prioridad o riesgo (y, en última instancia,
la disponibilidad del servicio de TI relacionado).
 Asegúrese de que el personal de operaciones, el gerente de servicio y otros
interesados conozcan el estado de los principales riesgos y los planes para
manejarlos.
Operar controles Preguntas clave:
 ¿Funcionan los controles como se esperaba?
[Date]
130
 ¿Están los niveles de tolerancia al riesgo y los disparadores de acción funcionando
según sea necesario?
 ¿Están los planes de acción de gestión de riesgos siguiendo los pasos esperados?
Entradas:
 Reporte de cumplimiento de SLA
Salidas:
 Reporte de operaciones de control

 Impactos en el nivel de servicio
Mejores prácticas:
 Ejecutar planes de acción de riesgo y evaluar su estado a través de informes de

riesgo.
 Inicie solicitudes de control de cambios cuando los cambios en el estado de riesgo o
los planes de riesgo puedan afectar la disponibilidad del servicio o SLA.
 Recoja y almacene evidencia de que los controles están operando. Esto puede tomar
muchas formas (por ejemplo, registros del sistema, documentación que está bajo
control de cambio o firmas de individuos autorizados).
 Notificar a las partes interesadas los cambios en los servicios que abordan los
problemas de riesgo.
Aprender de los Preguntas clave:

esfuerzos
anteriores y  ¿Está la administración satisfecha con la forma en que los controles se ocupan de los
actualizar la base riesgos conocidos?
de conocimientos  ¿Están ajustados los niveles de tolerancia al riesgo y las acciones previstas cuando
las condiciones exceden los niveles aceptables?
 ¿Se han identificado nuevos riesgos?
 ¿Las auditorías indican un entorno de control efectivo?
Entradas:
 Auditoría de operaciones normales

 Análisis coste / beneficio de los controles
Salidas:
 Reporte de riesgos al menos mensualmente

 Dashboard de riesgo si está disponible
 Base de conocimientos de riesgo actualizada
 Resultados reportados a la MR de Salud Operacional
[Date]
131
Mejores prácticas:
 La aplicación de controles es un ejercicio costo / beneficio; debe reflejar la

evaluación de la administración del objetivo del negocio, el riesgo identificado, y el
beneficio de desarrollar y aplicar el control. El análisis costo / beneficio debe reflejar
la voluntad de la empresa de asumir riesgos, reconociendo que existe, pero se
permitirá que ocurra su impacto potencial (en lugar de mitigar el riesgo, lo que
implica intentar reducir el impacto o la probabilidad del riesgo ).
 El aprendizaje del riesgo formaliza las lecciones aprendidas y utiliza herramientas
para capturar, categorizar e indexar ese conocimiento en una forma reutilizable que
se puede compartir con otros en la organización.
Proceso 3: Cumplimiento de las Directivas

El cumplimiento es una aplicación de la gestión de riesgos que garantiza la conformidad de TI con las políticas
de la empresa, las regulaciones gubernamentales y las leyes específicas de la industria. Algunas de las leyes de
cumplimiento más conocidas y sus funciones se incluyen en la siguiente tabla.
Tabla 7. Ejemplos de Leyes de Cumplimiento y Sus Funciones
Ley de cumplimiento Función

Normas y controles mejorados para todas las juntas de empresas
La Ley Sarbanes-Oxley (SOX)
públicas y firmas de contabilidad pública en los Estados Unidos
Ley de Portabilidad y Responsabilidad Normas nacionales para las transacciones de asistencia sanitaria
del Seguro de Salud (HIPAA) electrónica
Basilea II Norma internacional para bancos
Cada vez más, las actividades de cumplimiento requieren mayor diligencia y responsabilidad de parte de los
profesionales de TI. Por ejemplo, muchas grandes corporaciones han automatizado significativamente sus
sistemas de gestión financiera, lo que ha dado lugar a la automatización de los controles internos del negocio.
Estos controles de aplicación forman parte del entorno de cumplimiento; cuando se automatizan, se convierten
en parte del entorno de TI. Los profesionales de TI también deben ser conscientes de los controles informáticos
generales (por ejemplo, la separación de entornos de desarrollo y de prueba), que se definen como aquellos
procesos, actividades y configuraciones que se aplican a través de múltiples componentes de infraestructura
para garantizar que la tecnología funciona como se esperaba .
Informes de evidencia y aseguramiento

Aseguramiento es el proceso de proporcionar a la dirección ejecutiva una indicación de lo bien que la
organización cumple con sus metas y objetivos. Los informes de garantía son responsabilidad del departamento
de auditoría, que proporciona una evaluación imparcial. Esta información se basa en datos que demuestran el
efecto de los controles puestos en marcha para lograr resultados de una manera intencionada. La evidencia es el
término usado para describir estos datos, y la prueba es el proceso de ejercer los controles para generar
evidencia. También puede referirse a la evaluación de la evidencia generada.
[Date]
132
Esto puede ser confuso para los profesionales de TI que suelen utilizar el término "pruebas" para referirse a los
procesos de aseguramiento de calidad (QA) utilizados en el desarrollo de software y el despliegue del sistema.
Guardar los datos reales utilizados para realizar las pruebas (la evidencia) no es una parte común de la
metodología de pruebas del profesional de TI. Sin embargo, los auditores quieren que las pruebas recopiladas
durante un período de tiempo suficientemente largo para poder formarse una opinión sobre la eficacia y la
eficiencia de los controles. Otro punto de confusión entre las pruebas de aseguramiento y el uso del término
"pruebas" por parte del profesional de TI es que las pruebas de aseguramiento generalmente se centran en
controles y procesos en el entorno de producción. Se centra en lo que realmente está sucediendo en la
experiencia del mundo real de la organización, no en el entorno de prueba aislado, donde los problemas
funcionales pueden ser aislados y resueltos.
Por último, los informes de aseguramiento pueden obtenerse de varias fuentes (por ejemplo, auditorías de
cumplimiento, auditorías de seguridad o auditoría relacionadas con obligaciones contractuales), y los
profesionales de TI pueden encontrar que se les pide pruebas muy similares en numerosas ocasiones. Al tomar
conciencia de las actividades de aseguramiento en su organización, explorar los requisitos de retención de
evidencia y comprender el uso de la evidencia requerida, los profesionales de TI pueden mejorar la eficiencia y
reducir los aspectos perturbadores del proceso de aseguramiento.
[Date]
133
Figura 6. Cumplir con las directivas
Actividades: Cumplir con las Directivas

El proceso de cumplimiento es iterativo; La TI debe monitorear continuamente el medio ambiente,
adaptarse a los cambios normativos y responder a las directivas de gestión. Los profesionales de TI
deben tener cuidado de mirar a la directiva de la empresa para las directivas, en lugar de interpretar
las regulaciones sin aportaciones de otras áreas de la empresa. Los propios reglamentos deben ser
evaluados por diversos grupos dentro de la empresa (por ejemplo, jurídico, de recursos humanos y
de finanzas), que luego determinará la posición de la compañía con respecto a cualquier regulación
en particular.
[Date]
134
El profesional de TI debe traer activamente a la atención de la empresa las regulaciones relevantes
para TI. Estas regulaciones pueden entonces ser evaluadas, la compañía puede determinar su
posición relativa a cada una, y las políticas y las directivas apropiadas se pueden construir para guiar
decisiones y actividades. Con esta vía establecida, el auditor podrá tomar los objetivos de gestión-
ahora en forma de directrices- y verificar el cumplimiento de dichas directivas.
 Identificación de políticas, leyes, reglamentos y contratos

 Selección de políticas, leyes, reglamentos y contratos
 Evaluación del estado de cumplimiento actual
 Establecimiento del estado de cumplimiento futuro
 Creación de un plan de cumplimiento
 Mantener el cumplimiento
 Auditoría del cumplimiento
Cuadro 8. Actividades y consideraciones para el cumplimiento de las directivas
 La organización quiere asegurarse de que las directivas son seguidas,
estén o no sujetas a requisitos formales de gobernabilidad.
 TI puede tener servicios que llevan requisitos de desempeño con
sanciones por incumplimiento.
Suposiciones
 La organización ha estado sujeta a hallazgos de auditoría que indican
que su ambiente de control es ineficaz o ineficiente o que han resultado
en que la compañía está fuera de cumplimiento.
Identificar políticas, Preguntas clave:

leyes, reglamentos y
contratos  ¿Qué leyes y reglamentos (locales, nacionales o globales) se aplican a
la empresa?
 ¿Qué entidades reguladoras aplican a las actividades de la empresa?
 ¿Qué objetivos requieren que la política demuestre la intención de la
administración y se asegure de que la actividad deseada se pueda
hacer cumplir?
 ¿Qué compromisos de servicio de TI conllevan requisitos de
cumplimiento de cumplimiento?
Entradas:
 Leyes y regulaciones a nivel mundial, nacional y local

 Requisitos de la entidad gobernante
 Directivas de gestión
 Revisión legal de las necesidades de cumplimiento
 Requisitos de rendimiento de los contratos de nivel de servicio de TI
Salidas:
 Las leyes y reglamentos identificados y las directivas de la

organización para el cumplimiento
[Date]
135
 Directivas de cumplimiento identificadas que apoyan la intención de la
organización de cumplir con la estrategia
Mejores prácticas:
 El cumplimiento tiene múltiples facetas, pero las consideraciones

principales se relacionan con el cumplimiento de los objetivos de
gestión, las directivas de la empresa y los requisitos legales. Además,
los servicios deben desempeñarse de manera que cumpla con los
acuerdos y contratos. El monitoreo y las métricas pueden proporcionar
información para ambas áreas de cumplimiento.
Preguntas clave:
 ¿El negocio ha revisado y determinado qué leyes y regulaciones está

claramente sujeto a la compañía?
 ¿Existe un marco de control que cubra efectivamente las leyes y
reglamentos a los que está sujeto el negocio?
Entradas:
 Lista revisada de leyes y reglamentos e interpretaciones

 Tolerancia al riesgo de la empresa
 Informes de auditoría anteriores
 Objetivos de control potencial de los marcos relevantes
Seleccione políticas,
Salida:
contratos
 Lista de leyes, reglamentos y objetivos de desempeño y control a ser
abordados por la política de la compañía
Mejores prácticas:
 La cultura de una organización y la forma en que trabaja para alcanzar

los objetivos estratégicos afectarán en gran medida las áreas
seleccionadas para las actividades de cumplimiento. Equilibrar los
requisitos para el cumplimiento y la cultura requiere que las decisiones
se tomen abiertamente con las partes interesadas apropiadas.
 Incluir profesionales legales y de auditoría en la discusión.
Evaluar el estado de Preguntas clave:

cumplimiento actual
 ¿Cuál es el estado actual del cumplimiento de las leyes, reglamentos y
directivas pertinentes?
 ¿Cuál es el estado de cumplimiento de los objetivos de desempeño?
 ¿Cuál es el historial de incidentes de incumplimiento y hay una
tendencia identificable?
Entradas:
[Date]
136
 Evaluaciones de riesgos para sistemas y procesos de negocio (ver
"Proceso 2: Evaluar, monitorear y controlar el riesgo")
 Políticas y directivas existentes
 Informes de cumplimiento, actividad de denunciante
 Cumplimiento del rendimiento para contratos y acuerdos de servicios
de TI
Salida:
 Estado de cumplimiento salud (informe o salpicadero)
Mejores prácticas:
 Cumplimiento de la salud puede ser volátil. Uno de los objetivos de un

vigoroso programa de cumplimiento es disminuir la volatilidad a través
del monitoreo activo de los controles y la detección de tendencias. Un
panel de control de cumplimiento que se actualiza frecuentemente con
datos de monitoreo recientes mantendrá informados a los gerentes
superiores, pero no cargados con los informes de cumplimiento. Un
tablero de instrumentos debe apoyar una investigación más detallada
sobre los detalles de los incidentes de cumplimiento.
Establecer futuro Preguntas clave:

estado de
cumplimiento  ¿En qué áreas hay incidentes recurrentes de incumplimiento?
 ¿Qué riesgos de cumplimiento están fuera de la tolerancia al riesgo de
la compañía?
 ¿Se han incurrido en sanciones por servicios de TI que no cumplen
con los requisitos de desempeño?
Entradas:
 Estado actual de cumplimiento

 Cambios en la cartera de TI y catálogo de servicios
 Cambios en el entorno regulatorio relevante para el negocio
 Tendencias regulatorias y normas legales que pueden afectar el
negocio
 Cambios en la tolerancia comercial del riesgo
 Modificaciones, reducciones y adiciones potenciales al ambiente de
control
Salida:
 Hoja de ruta documentada sobre el cumplimiento para el estado futuro
Mejores prácticas:
 Considere el incumplimiento desde varias perspectivas: ¿Son

inadecuados o confusos los procedimientos y la orientación
[Date]
137
relacionados? ¿Es la política demasiado pesada y pesada, que podría
resultar en un conflicto entre el desempeño y el cumplimiento? ¿Es
adecuada la capacitación?
 Consulte con un abogado antes de finalizar la política basada en la
regulación. Es importante tener una interpretación de cómo la
compañía debe cumplir con las regulaciones que incluye una
comprensión más amplia del precedente legal y de la madurez de
regulaciones.
Preguntas clave:
 ¿De qué manera se diferenciará la empresa conforme (el estado "a

ser") de la empresa actual?
 ¿Qué no funciona de manera efectiva en el programa de cumplimiento
actual?
 ¿Qué requerimientos de recursos, capacitación y cambios en las
políticas, procesos y sistemas se requerirán para ser compatibles?
 ¿Es necesario abordar los contratos de servicios de TI con cláusulas
de rendimiento?
Entradas:

 Revisión por parte de la alta gerencia del estado "futuro", objetivos
estratégicos y objetivos comerciales
 Acuerdo de que la empresa identificada "a ser" y los objetivos
estratégicos son compatibles
Crear plan de  Planes de proyecto para cambiar servicios de TI identificados para
cumplimiento lograr un mejor cumplimiento de cumplimiento
Salida:
 Proyecto de plan de cumplimiento propuesto aprobado por todos los

interesados
Mejores prácticas:
 Preste atención a la cultura de cumplimiento en la empresa. Si la

empresa se encuentra en una industria fuertemente regulada, es
probable que la expectativa de que los requisitos de cumplimiento son
parte integrante de la actividad cotidiana. Por otro lado, si la industria
es un cambio acelerado impulsado por el crecimiento, el cumplimiento
podría ser visto como una carga o un "impuesto" que debe evitarse.
Los planes futuros de cumplimiento deben tener esto en cuenta y
mover la cultura de cumplimiento en la dirección deseada en base a su
carácter actual.
Mantener el Preguntas clave:

cumplimiento
[Date]
138
 ¿Qué problemas de incumplimiento están ocurriendo?
 ¿Hay formas de reducir los costos de cumplimiento sin aumentar el
riesgo?
Entradas:
 Plan de cumplimiento
 Informes de gestión y control de servicios
(consulte el SMF de supervisión y control de servicios )
 Informes de auditoría, monitoreo de control
 Riesgo y niveles de tolerancia de cumplimiento
Salidas:
 Informes de cumplimiento
 Actualizaciones del panel de control de cumplimiento
Mejores prácticas:
 Los problemas de cumplimiento a menudo contienen información

confidencial. Ciertas personas deben ver ciertas partes de esta
información; otras personas otra información. Múltiples vistas de la
información, junto con el acceso basado en roles a informes y / o
cuadros de mando, ayudarán a resolver los problemas de privacidad.
 El entorno de cumplimiento es dinámico: requiere revisiones
frecuentes de los controles aplicables. Estas revisiones de control
deben incluir un análisis costo / beneficio que incluya las dimensiones
del riesgo, así como la eficacia operativa.
Cumplimiento de Preguntas clave:

auditorías
 ¿Qué está cambiando en términos de leyes y reglamentos pertinentes
o de nuevos requisitos a los que la empresa puede estar sujeta?
 ¿Es aceptable para la alta dirección el estado actual de cumplimiento?
 ¿Hay evidencia suficiente de actividad de control, pruebas y
mantenimiento del cumplimiento del control mantenido actual y
debidamente almacenado?
Entradas:
 Revisiones legales y actualizaciones de interpretaciones regulatorias

 Informando y entrevistando entrevistas con gerentes senior sobre el
estado de cumplimiento
Salidas:
 Resultados de la auditoría de cumplimiento
[Date]
139
 Plan de cumplimiento actualizado
Mejores prácticas:
 Los reglamentos pueden tener claras consecuencias por

incumplimiento, como multas y / o penas de prisión, pero a menudo
tienen requisitos muy generales. Representantes legales y de auditoría
pueden ayudar a aclarar lo que realmente necesita suceder para que la
TI sea compatible.
 Asegúrese de que la evidencia apropiada y suficiente de la actividad
de control se almacena para una evaluación posterior. Trabajar con los
auditores internos y externos para entender los requisitos para la
recolección y almacenamiento de evidencia e iniciar esa conversación
meses antes de cualquier actividad de auditoría planificada en esa
área.
 Asegurar el uso de acuerdos de nivel de servicio (SLA) para ayudar a
definir la calidad de los servicios de TI y establecer directrices para el
rendimiento y los requisitos de cumplimiento. Para obtener más
información acerca de los acuerdos de nivel de servicio, consulte el
Business / IT Alignment SMF .
Conclusión
El SMF de Gobierno, Riesgo y Cumplimiento proporciona orientación para integrar las actividades
de GRC en el contexto de procesos y actividades a lo largo del ciclo de vida del servicio de TI. Esta
integración hace uso de la gestión de riesgos y controles internos presentes en cada SMF para
proporcionar formas consistentes de tomar decisiones y gestionar las actividades de TI.
Los principales procesos descritos en el GRC SMF son:
 Establecimiento de gobierno de TI.

 Cumplimiento de las directivas.
Realimentación
Posición del GRC SMF Dentro del ciclo de vida

del servicio de TI de MOF
[Date]
140
fase de ciclo de vida y contiene un conjunto único de metas y resultados que apoyan los objetivos de
esa fase. Los SMF pueden ser usados como conjuntos independientes de procesos, pero es cuando
los SMFs se usan juntos que son más efectivos para asegurar la prestación de servicios con los
niveles de calidad y riesgo deseados.
El SMF de Gobierno, Riesgo y Cumplimiento (GRC) pertenece a Manage Layer, la base del ciclo de
vida del servicio de TI de MOF. La siguiente figura muestra el lugar del GRC SMF dentro de la capa
de administración, así como la ubicación de la capa de administración dentro del ciclo de vida del
servicio de TI.
Figura 1. Posición del GRC SMF dentro del ciclo de vida del servicio de TI
información sobre el ciclo de vida del servicio de TI de MOF y la capa Administrar:
 Manejar la capa
¿Por qué utilizar el GRC SMF?

Este SMF debe ser útil para aquellos que toman decisiones de compensación de cómo los recursos
de TI se utilizarán para cumplir con las metas y entregar valor de negocio; para aquellos que
necesitan manejar el riesgo de muchas fuentes, no sólo el riesgo de seguridad de TI; y para
aquellos que necesitan asegurarse de que las actividades de TI cumplan con las regulaciones y
directivas. Este SMF discute directrices y principios para GRC que se llevará a cabo durante los
procesos y actividades a lo largo del ciclo de vida del servicio de TI.
[Date]
141
Descripción de GRC
La gobernabilidad, el riesgo y el cumplimiento son potencialmente actividades de gran alcance y

entrelazadas que requieren la participación de todos en la organización. Establecer una
comprensión común de un tema tan amplio puede ser un desafío. Para ayudar a aclarar el tema, las
siguientes secciones desglosan el alcance de GRC y discuten:
 Lo que define IT GRC.

 Por qué las tres actividades se consideran juntas.
 Diferentes funciones de TI y sus respectivas perspectivas GRC.
 Cómo GRC se integra en el ciclo de vida del servicio de TI.
¿Qué es GRC?
La gobernanza de TI es una actividad de alto nivel de gestión que, cuando está bien ejecutada,
aclara quién tiene la autoridad para tomar decisiones, determina la responsabilidad por las acciones
y la responsabilidad por los resultados y se ocupa de cómo se evaluará el rendimiento esperado. La
mayoría de las organizaciones logran el gobierno de TI creando grupos, tales como comités de
dirección, que reúnen a las partes correctas para tomar decisiones.
La gobernanza a nivel de toda la Organización establece, entre otras cosas, resultados positivos y
expectativas de crecimiento, caminos elegidos para mejorar la satisfacción del cliente, nuevos
productos y desarrollo del mercado, todas las áreas donde la TI puede hacer una contribución
significativa cuando se coordinan todos los esfuerzos de gobernabilidad.
Las actividades de gobierno se llevan a cabo, ya sean planificadas o no. La falta de procesos
planificados de gobernanza puede resultar en el establecimiento arbitrario de objetivos y la toma de
decisiones, luchas políticas en torno al césped y desperdicio de recursos de esfuerzos confusos y
conflictivos. La gobernanza planificada debería resultar en:
 Políticas consistentes que trabajan juntas de manera efectiva.

 Tomar decisiones claras y responsables con un plan acordado para hacer compensaciones.
 Objetivos de gestión bien comunicados.
 Establecer expectativas de desempeño y evaluar el cumplimiento.
 Expectativas claras para un comportamiento aceptable en la búsqueda de metas de la
gerencia.
El riesgo representa posibles impactos negativos en el logro de metas y puede surgir de acciones
tomadas o no tomadas. Las organizaciones utilizan los procesos de gobernanza para decidir las
prioridades y el nivel de esfuerzo que debe dedicarse a reducir la probabilidad y la magnitud de los
impactos del riesgo.
[Date]
142
Los procesos de buen gobierno buscan riesgos y ofrecen discusiones abiertas y enfoques claros
para abordar el riesgo. Una cultura de gestión de riesgos ayuda a prevenir la ignorancia deliberada
del riesgo o el ocultamiento intencional del riesgo y reduce el número de riesgos desconocidos que
pueden dar lugar a consecuencias negativas.
Los controles internos son los procesos y sistemas que existen para abordar los riesgos e influenciar
o mitigar los resultados potenciales. En el sentido más general, los controles internos proporcionan
los medios por los cuales los objetivos de gestión se logran de manera confiable y, al hacerlo,
contribuyen a resultados positivos para las partes interesadas.
El cumplimiento es un proceso que asegura que las personas estén al tanto de las regulaciones,
políticas y procedimientos que deben seguirse como resultado de las decisiones de la alta dirección.
El cumplimiento es también la evaluación de lo que realmente sucede en la organización en
comparación con los resultados previstos establecidos por los objetivos de la administración, las
políticas y los requisitos reglamentarios.
Los esfuerzos de cumplimiento de TI serán mejorados si la organización ha establecido claramente

y ha comunicado las expectativas de TI y las políticas que deben seguirse, y si ha desarrollado de
manera proactiva formas de evaluar el desempeño y la toma de decisiones.
Factores externos a las organizaciones, tales como regulaciones, estándares y mejores prácticas de
la industria, tienen impacto en cómo se hace el trabajo. Estos factores se evalúan e implementan
con mayor eficacia cuando se aplican los procesos de GRC adecuados. Por ejemplo, hay una serie
de organismos y reglamentos relacionados con la fiabilidad de los datos y la fiabilidad de la
organización. Es posible que las organizaciones de TI tengan que responder a una variedad de
organismos reguladores de la Comisión de Valores y Cambios (SEC, por sus siglas en inglés) a la
Unión Europea (UE), y tal vez necesite abordar los requisitos y reglamentos de gestión de datos tan
variados como la Health Insurance Portability and Accountability Act HIPAA), la Ley de Protección de
Datos, Basel I / II, y Sarbanes Oxley (SOX). Las actividades de GRC pueden ayudar a las empresas
(y sus departamentos de TI) a convertirse en:
 Mejores custodios de los datos.

 Más alineados con las regulaciones.
 Mejor equipada para lograr los objetivos de gestión.
 Menos susceptible a actos fraudulentos.
¿Por qué se agrupan estas actividades como

GRC?
Las tres prácticas que conforman GRC-gobierno, gestión de riesgos y cumplimiento-comparten
tareas comunes e interrelacionadas. Debido a que la gobernabilidad, el riesgo y el cumplimiento
tienen áreas de responsabilidad y proceso superpuestas, son más eficaces cuando se integran y se
tratan como prácticas combinadas. Esto reduce las islas de datos y los silos de actividad que, en
última instancia, ralentizan la capacidad de respuesta de la organización y contribuyen a un mayor
riesgo al obscurecer la identificación del riesgo y producir evaluaciones inadecuadas del impacto del
riesgo. La combinación puede agilizar los procesos y proporcionar transparencia y responsabilidad
en una organización. Esto lo logra mediante:
[Date]
143
 Reunir a los grupos adecuados de personas ( gobernanza ) para aclarar lo que debe suceder
y evaluar lo que podría interponerse en el camino ( gestión del riesgo ).
 Ayudar a la organización a determinar los compromisos de recursos ( gobernabilidad )
necesarios para asegurar que se logren sus objetivos ( gestión de riesgos ).
 Dejar claro ( gobernanza y cumplimiento ) qué procesos y actividades deben o no deben
suceder ( gestión de riesgos y cumplimiento ).
 Capturar y documentar los procesos y sus resultados como evidencia ( cumplimiento ).
Cuando una organización se dirige a las actividades de GRC de TI, varias preguntas clave ayudan a
establecer el contexto. Responder a estas preguntas muy probablemente requerirá conversaciones
con grupos externos a TI, tales como auditoría interna, legal, cumplimiento, y recursos humanos.
 ¿Cuál es el plan de gobierno de nuestra organización? ¿Quién decide cómo y qué decidir?
 ¿Cuál es la tolerancia al riesgo de nuestra organización? ¿Dónde podemos aceptar más
riesgos y en qué áreas debemos ser más cautelosos?
 ¿Hay problemas específicos de regulación y cumplimiento que se aplican a nuestra industria?
 ¿Cuál es nuestra cultura de cumplimiento, es decir, cómo determinamos que estamos
haciendo lo que dijimos que haríamos?
Al responder a estas preguntas y trabajar en planes integrados de GRC, se mejora la alineación de

las metas de TI y de negocio porque las personas adecuadas están tomando las decisiones
correctas en el momento adecuado.
¿Quién debe cuidar de GRC?

Aunque todos en una organización están involucrados en actividades de GRC de TI en algún nivel,
GRC requiere que tres grupos principales sean eficaces: ejecutivos, administradores de TI y
profesionales de TI. Estos tres roles organizacionales tienen diferentes preocupaciones y
implicaciones relacionadas con GRC.
El rol del GRC de los profesionales de TI enfatiza la aplicación de las decisiones que se han tomado
a través de los procesos de gobernanza a las actividades y procedimientos cotidianos. Los
profesionales de TI se centran en los aspectos de cumplimiento de GRC y el uso de conocimientos
técnicos en profundidad para ayudar a identificar y mitigar los riesgos y encontrar maneras de
automatizar los controles de manera eficiente. Aseguran que las actividades y los sistemas
funcionen dentro de las directrices que se han establecido en el proceso GRC. Tienen
conocimientos especializados que pueden usarse para refinar controles basados en capacidades o
restricciones tecnológicas.
Los gerentes de TI a menudo participan en grupos de GRC que toman decisiones de trade-off. Un
mandato principal para la gerencia consiste en traducir los objetivos estratégicos (establecidos en los
niveles ejecutivo y de junta) en directivas y políticas tácticas y tangibles que resultarán en servicios,
soluciones, políticas y actividades cotidianas. Los gerentes de TI impulsan la traducción de los
objetivos estratégicos en metas tácticas, impulsan el análisis del riesgo a esos objetivos e impulsan
la identificación de los controles internos para mitigar esos riesgos.
Finalmente, en el nivel ejecutivo, el CIO tiene la responsabilidad de todo el proceso GRC dentro de
TI. Deben establecerse las estructuras adecuadas para reunir a las personas adecuadas en el
momento adecuado para guiar eficazmente la realización de la estrategia. El CIO debe asegurarse
de que la gestión de riesgos es parte de la discusión en estos foros de gobierno como una
[Date]
144
herramienta para ayudar a informar las opciones y avanzar hacia un denominador común para tomar
decisiones de trade-off.
Además, el CIO debe estar al tanto de las funciones de aseguramiento (auditoría), que evalúan los
objetivos, los controles internos y su diseño y eficacia operativa. La auditoría proporciona hallazgos
y recomendaciones al ejecutivo y al consejo para que la organización se beneficie de una gestión
inteligente e intencional. Evaluaciones similares de aseguramiento ayudan a proporcionar a los
accionistas ya otras partes externas interesadas una visión del funcionamiento de una organización.
La toma de conciencia por parte del CIO de los hallazgos de aseguramiento asegura que el enfoque
de la organización a la gobernabilidad se fije en el nivel superior y que las actividades de GRC se
entiendan y se utilicen en todos los niveles.
¿Cuál es la relación entre el GRC SMF y el

ciclo de vida de TI?
Cada fase del ciclo de vida de los servicios TI tiene sus propias metas y actividades. Aunque los
grupos y las personas pueden variar según la fase y la actividad y los insumos y productos pueden
diferir, la importancia de tener claridad sobre la toma de decisiones, la gestión de riesgos y el
cumplimiento de la normativa no cambia.
En la Fase del Plan, el objetivo es asegurarse de que los servicios de TI ofrecidos al negocio sean
valiosos, predecibles, confiables y rentables, y que respondan a las necesidades empresariales en
constante cambio.
Para ayudar a alcanzar este objetivo, el GRC se centra en:
 Transferencia de estrategia corporativa a la estrategia de TI.

 Estructura de gobierno y derechos de decisión.
 Objetivos de gestión definidos.
 Principales riesgos para alcanzar los objetivos identificados.
 Entorno normativo general.
 Política definida.
En la fase Entregar, el objetivo es asegurarse de que los servicios de TI que el negocio y la TI han
acordado se desarrollen de manera efectiva, se desplieguen con éxito y estén listos para
Operaciones.
 Arquitectura de la solución compatible con los requisitos de la organización.

 Participantes del proyecto, metodología y riesgos identificados.
 El proceso de realización de valor.
 El ciclo de vida del desarrollo del servicio.
 Mitigación de riesgos.
 Definición de controles internos.
 Definición de procedimientos.
En la fase de operación, el objetivo es asegurarse de que los servicios desplegados son operados,
mantenidos y soportados de acuerdo con los objetivos SLA establecidos por el negocio y la TI.
[Date]
145
 Procedimientos y actividades de control.

 Grabación y documentación.
 Retención de pruebas de que el control funciona según lo diseñado.
GRC crea flujos de procesos organizados en todas las fases del ciclo de vida, ayudando a la toma
de decisiones, equilibrando las compensaciones, estableciendo una estrategia mediante la gestión
de los riesgos y asegurándose de que la gestión de riesgos es apropiada para las actividades que se
llevan a cabo. Al asistir a estos GRC , la TI puede contribuir mejor a la viabilidad y mejoramiento a
largo plazo de la organización y es capaz de establecer con claridad: "Así es como manejamos la TI
y gestionamos el riesgo".
Tipos de rol SMC de GRC

Las responsabilidades primarias de SMF del Equipo que se aplican a GRC son la rendición de
cuentas de la Administración y la Cumplimiento. Los tipos de rol dentro de estas responsabilidades y
sus actividades principales dentro de este SMF se muestran en las tablas siguientes.
Cuadro 1. Responsabilidad de gestión y sus tipos de función de asistente

 Patrocinadores IT GRC  Posee la guía de procesos de GRC
 Aprueba estructuras y y toma de decisiones de TI
procesos globales  Garantiza una clara apropiación y
 Utiliza métricas y responsabilidad
Ejecutivo de TI benchmarking para evaluar  Tendencias claras en el rendimiento
el rendimiento de GRC de GRC
 Participa en la toma de  Asegura que la hoja de ruta de
decisiones mejora está en su lugar
 Gestiona los procesos de

gobierno
 Garantiza que GRC se integra en las
 Identifica e involucra a los
decisiones de gestión
participantes del GRC
 Asegura que el estado de
 Gestiona las dependencias
cumplimiento se entiende
de realización de valor de
 Facilita la alineación comercial / TI a
Gerente de TI negocio de riesgo y de TI
través de procesos GRC
 Posee una relación de
 Garantiza que las métricas GRC se
negocios / TI
usan para la planificación de
 Utiliza métricas para
informes y mejoras
evaluar el rendimiento de
GRC
 Entiende las decisiones de  Garantiza que las políticas reflejan

compromiso del GRC y las los resultados del proceso de GRC y
Gerente de
posiciones resultantes que dirigen a la organización hacia
políticas de TI
se reflejan actividades apropiadas
[Date]
146
 Gestiona los programas
 Asegura procesos y expectativas
generales de gestión de
GRC bien comunicados
Gerente de riesgos y cumplimiento
 Asegura que las personas entiendan
Riesgos y  Comunica los procesos y
sus responsabilidades de GRC y
Cumplimiento de TI requisitos de GRC a la
tomen acción en consecuencia.
organización
efectividad operativa de las
 Resiste que GRC está
estructuras y procesos de
Aseguramiento e constantemente bajo revisión y
GRC
Informes continuamente mejorado
 Recomienda cambios para
mejorar
 Gestiona las actividades del  Garantiza que los procesos GRC

proceso de gestión del resultan en un cambio que se
Administrador de
cambio para la organización entiende
cambios
de TI  Garantiza la gestión de los riesgos
 Sigue lo que está

 Asegura que GRC da como
cambiando y su impacto
resultado un cambio que es
Administrador de  Rastrea los elementos de
aprobado y da como resultado un
configuración configuración (CI)
estado conocido en todo momento
 Actualiza CMS
Cuadro 2. Cumplimiento de la responsabilidad y sus tipos de función de asistente

 Comunica la estrategia de TI y
aprueba los objetivos de gestión  Asegura que se logre un
de TI progreso consistente hacia los
 Aprueba la política objetivos estratégicos mediante
Ejecutivo de TI
 Establece tonos en la cima actividades apropiadas y
para el cultivo de control y deseadas
cumplimiento
 Cumplimiento de las directivas y

 Hace cumplir la política de políticas
comunicación y cumplimiento  Asegura resultados predecibles y
 Evalúa la adherencia y eficacia confiables que se logran a través
Gerente de TI de la política de medios apropiados
 Solicita cambios a la política o  Garantiza que las violaciones de
excepciones las políticas se aborden de forma
efectiva y oportuna
Gerente de  Gestiona los programas  Asegura que los esfuerzos de

Riesgos y generales de riesgo y riesgo y cumplimiento estén
Cumplimiento de TI cumplimiento coordinados y sean consistentes
 Asegura que las personas entre sí
[Date]
147
estén entrenadas y comprendan
 Proporciona capacitación y
los mandatos de cumplimiento
preparación suficientes para
 Revisa eventos de riesgo no
mantener el cumplimiento
anticipado y problemas de
 Asegura que los eventos
incumplimiento para identificar
imprevistos sean abordados
mejoras a procesos
 Gestiona los procesos

generales de políticas
 Posee comunicación de la
 Asegura que las políticas son
política a la organización y
claras, actuales y bien
Gerente de retroalimentación sobre temas
comprendidas para que resulten
políticas de TI de política
en un comportamiento apropiado
 Coordina la gestión de
solicitudes de excepción de
políticas
 Investiga el incumplimiento de  Posee una validación

las políticas y la elusión independiente del cumplimiento
Aseguramiento e
 Emite informes y recomienda  Detecta fraude o actividad
Informes
cambios intencional no permitida
Metas del GRC

El objetivo general de GRC es proporcionar servicios de TI que sean eficaces, eficientes y
conformes . Específicamente, esto implica:
 Establecer una toma de decisiones clara y efectiva en la gestión de los activos de TI.
 Gestionar el riesgo de manera eficaz.
 Cumplimiento de las políticas, leyes y reglamentos aplicables.
Tabla 3. Resultados y Medidas de los Objetivos del GRC SMF
Resultados Medidas
 Las actividades de TI generan rentabilidad esperada de la inversión
 El uso de los activos de TI cumple con las previsiones
 La toma de decisiones es oportuna y no requiere reexamen
Buen gobierno  La confidencialidad, integridad y disponibilidad de los activos de TI
son congruentes con las necesidades y directivas de la empresa
 Las políticas se crean y se gestionan de manera oportuna
Gestión eficaz del  Identificación y gestión proactiva de posibles amenazas y

riesgo vulnerabilidades a los activos de la empresa
 Proceso claro y documentado para identificar el riesgo; determinar el
impacto y la probabilidad; priorizar y gestionar mediante mitigación,
transferencia o aceptación; y la identificación de controles y
soluciones apropiados
[Date]
148
 Confidencialidad, integridad y disponibilidad de los activos de TI
 Gestión del impacto de las leyes y reglamentos en la realización del

valor comercial
 Identificación de las políticas, leyes y reglamentos de la organización
Cumplimiento de los
aplicables
reglamentos, leyes y
 Diseño, desarrollo e implementación de activos de TI que soportan el
políticas
cumplimiento de las leyes y reglamentos
 Reporte de controles mensurables para auditoría y gestión
Términos clave
Término Definición
Procesos que aseguran la conformidad de TI con las regulaciones gubernamentales,
las leyes y las políticas específicas de la empresa-en otras palabras, un medio para
Conformidad
informar a las personas sobre la actividad apropiada y también asegurar que la
organización está haciendo lo que ha dicho que hará
Un proceso que prepara una organización para responder coherentemente a los
Contingencia
resultados planificados, así como a incidentes no planificados
Prueba comprobable de que las políticas y los procesos funcionan como se
Evidencia
esperaba
La gobernanza especifica quién debe tomar decisiones y cómo, cómo comunicarse
Gobernancia eficazmente y cuándo debe suceder, y cómo seguir el progreso de TI en relación con
los objetivos empresariales
Cualquier información, datos, propiedad intelectual, sistema o máquina propiedad de
Activos de TI
la empresa que se utilice en el curso de actividades empresariales
Controles de Una actividad específica realizada por personas o sistemas diseñados para asegurar
TI el cumplimiento de los objetivos empresariales
Procesos o actividades que se establecen con el propósito de reducir las posibles
Mitigación
consecuencias de un riesgo reduciendo la probabilidad o el impacto del riesgo
La posibilidad de efectos adversos en los objetivos de negocio o TI. El riesgo se
Riesgo
mide en términos de impacto, probabilidad y exposición
Gestión de
Los esfuerzos de una organización para abordar el riesgo en el entorno de TI
riesgos
Relación entre gobierno, riesgo y

cumplimiento
[Date]
149
Figura 2. La relación entre gobernabilidad, riesgo y cumplimiento
Desde el punto de vista del proceso, GRC es diferente de muchos de los SMF de MOF. Su
aplicación no es, estrictamente hablando, un flujo secuencial -primera A sucede, entonces B,
entonces C. En cambio, como muestra la Figura 2, son tres conjuntos separados de procesos-
gobernabilidad, riesgo y cumplimiento-cualquiera de los cuales puede tener lugar simultáneamente o
en tándem con los otros procesos.
Sin embargo, para facilitar la comprensión, este SMF discutirá estas actividades interconectadas
como procesos separados:

Las siguientes secciones tratan estas actividades en detalle. En la Guía de administración de

riesgos de seguridad de Microsoft se puede encontrar un análisis exhaustivo de la gestión de riesgos
especializada relacionada con el riesgo de seguridad:
http://www.microsoft.com/technet/security/guidance/default.mspx
Proceso 1: Establecer Gobierno de TI

La gobernanza describe el liderazgo, la estructura de toma de decisiones, los procesos y la

rendición de cuentas que determinan cómo una organización recibe el trabajo. La gobernanza
comienza en la cima, pero requiere la participación en todos los niveles de la organización. La
naturaleza de las decisiones tomadas y la información pasada a otros participantes de GRC se
retrata en la Figura 3. Como muestra, hay formas para que todos los miembros de la organización
contribuyan a una gobernabilidad exitosa.
Mirando los varios grupos que pasan la información a través de la organización demuestra que es
provechoso tener una manera común de comunicarse sobre la información de GRC. Este GRC SMF
se centra en los mecanismos para conectar estos niveles utilizando las actividades de gestión y
[Date]
150
control de riesgos, lo que resulta en una mejor toma de decisiones y el establecimiento de la
rendición de cuentas por los resultados.
Figura 3. El entorno de gobierno: participantes y tipos de información
La gobernanza de TI puede ser mejorada a través de la clarificación de objetivos, funciones y

responsabilidades y mediante la aplicación de la gestión de riesgos en todo el ciclo de vida de los
servicios de TI. Esto asegura que la TI es capaz de entender la estrategia y los requisitos
empresariales, ofrecer valor al negocio mientras mitiga los riesgos de TI, y establecer la rendición de
cuentas durante todo el ciclo de vida.
En términos cotidianos, estos conceptos se harán más concretos por el papel específico y las
actividades involucradas. Por ejemplo, el profesional de TI que configure buzones de Microsoft®
Exchange Server necesitará conocer las políticas de retención y purga de correo electrónico y
asegurarse de que estas políticas se apliquen de manera efectiva mediante reglas de configuración y
Directiva de grupo. El gerente de TI debe ser consciente de los objetivos de la gerencia con
respecto a las comunicaciones corporativas y qué requisitos reglamentarios podrían estar
involucrados para asegurarse de que la opinión legal apropiada es llevada a cabo para que se
desarrollen las políticas requeridas.
El CIO y otros ejecutivos deben hacer su determinación de que la estrategia de su organización y

cualquier regulación que afecte la comunicación corporativa es racional y que han establecido una
dirección y una política apropiadas para el resto de la organización.
[Date]
151
Figura 4. Establecer gobierno de TI
Actividades: Establecer Gobierno de TI

En el nivel de actividad, los procesos de gobierno de TI ayudan a alinear la TI con el negocio a
través del proceso de toma de decisiones utilizado para definir las acciones para alcanzar los
objetivos estratégicos. Esta alineación se produce a través de discusiones de trade-off y toma de
decisiones. Como se mencionó anteriormente, la gobernanza es un proceso de gestión que define
los derechos de decisión, garantiza que la tolerancia al riesgo se ha tenido en cuenta en las
decisiones y proporciona una forma de establecer expectativas que pueden evaluarse a través de un
proceso de cumplimiento. El establecimiento de la estructura y el proceso de gobierno debe hacerse
[Date]
152
antes de tomar decisiones. Hacer esto ayudará a identificar a los representantes empresariales y de
TI que tomarán decisiones conjuntamente y se harán responsables. Los resultados de las
actividades de gobernabilidad en última instancia afectan cómo se eligen las iniciativas y las
tecnologías y proporcionan el contexto para los recursos de TI más valorados: las personas, para
obtener oportunidades y beneficios.
El proceso para establecer la gobernanza de TI incluye las siguientes actividades:
 Definición de la visión . Ajustar la visión no es un aderezo. Esta actividad determina la

estructura general de gobierno de la TI y crea poder de decisión y responsabilidad. La cultura
de la organización de TI estará fuertemente influenciada por la forma en que la gobernanza se
abraza y se pone en acción.
 Alineación de TI para el negocio . Esta actividad también determinará la idoneidad del
ajuste entre la gobernanza general de la organización y la gobernanza de TI específicamente.
La gobernanza de TI sufrirá si esta coordinación no se establece.
 Identificación de reglamentos y normas . Los requisitos y estándares regulatorios
específicos de la industria juegan un papel crítico para medir la exactitud y el rigor requeridos
para el gobierno de TI. Estos factores deben ser examinados y aplicados apropiadamente.
 Creación de políticas . Obtener las políticas correctas ayuda a guiar el rendimiento que
proporciona resultados basados en los comportamientos esperados y en el uso adecuado de
los recursos.
Tabla 5. Actividades y Consideraciones para Establecer Gobierno de TI
 La organización está sujeta a requisitos reglamentarios u otros requisitos
externos para la gobernanza
 La gerencia quiere una comprensión clara de la manera en que se
Suposiciones ejecuta
 La dirección de negocios quiere entender la contribución que hace TI a
los resultados empresariales
Establecer la Preguntas clave:

visión
 ¿Cuáles son los principales objetivos estratégicos del negocio?
 ¿Qué nivel de formalidad se necesita para cumplir con los requisitos de
GRC?
 ¿Cómo se mide la realización del valor de TI?
 ¿Cómo se debe medir el rendimiento de TI?
Entradas:
 Objetivos estratégicos claros del negocio

 Requisitos relevantes de las normas y organismos reguladores aplicables
 Historia del cumplimiento de la organización (o incumplimiento)
 Indicación de la tolerancia al riesgo de la organización
 Recomendaciones de auditoría interna para la gobernanza
 Enfoque definido para medir la realización del valor
 Indicadores de rendimiento definidos
[Date]
153
Salidas:
 Estructura de los foros para las actividades de gobernanza

 Políticas de gobierno y planes de comunicación
 Plan general de gestión de riesgos informáticos
 Responsabilidad por las decisiones de gobernanza
 Monitoreo y métricas de rendimiento
 Requisitos de realización de valor
 Carta de gobierno de TI y propietario
Mejores prácticas:
 Objetivos comprensibles y claras implicaciones requieren una buena

comunicación. Dar muchas oportunidades para hacer preguntas,
replantear y parafrasear.
 Cuando sea posible, mapee las actividades de gobierno de TI a los
procesos de negocio existentes para la estrategia, la planificación y la
toma de decisiones.
 Diseñe la arquitectura de la información para que el monitoreo del
desempeño y el monitoreo del cumplimiento normativo puedan hacer uso
de la misma información cuando sea posible.
alineación de estrategias, consulte Función de gestión del servicio de
alineación de negocios / IT de MOF .
Alinear TI con el Preguntas clave:

negocio
 ¿Qué partes interesadas clave son necesarias para tomar decisiones de
compensación?
 ¿Qué procesos de calificación y toma de decisiones utiliza el negocio
para determinar iniciativas y proyectos generales?
 ¿Cuál es el enfoque de riesgo de la organización? ¿Cuál es su cultura de
cumplimiento de las directivas?
Entradas:
 Objetivos prioritarios para las empresas, directivas de gestión y

propietarios identificados
 Interpretación jurídica de los requisitos reglamentarios
 Borrar los requisitos de cumplimiento desde la perspectiva tanto del
negocio como de TI
Salidas:
 Participantes identificados para varias reuniones de gobernanza (como

comités de dirección)
 Actividades coordinadas de planificación empresarial y de TI
 Factores a considerar en la planificación estratégica de TI
 Funciones y responsabilidades claramente comprendidas entre los
[Date]
154
negocios y las TI
Mejores prácticas:
 Reducir las luchas políticas turf reuniendo a las partes interesadas con un
proceso claro para determinar las compensaciones y los caminos de
escalada acordados.
 La alineación de negocios / TI puede ocurrir a través de muchos niveles
de una organización; proporcionar un foro para la discusión a múltiples
niveles.
alineación de estrategias, consulte Función de gestión del servicio de
alineación de negocios / IT de MOF .
Preguntas clave:
 ¿Qué normas o requisitos reglamentarios basados en la industria son los

impulsores de la organización?
 ¿Existe un marco generalmente aceptado (como COBIT o ISO 20000)
que se correlaciona bien con la organización en términos de la industria y
la cultura de conformidad de la empresa?
Entradas:
 Representación comercial de los requisitos reglamentarios para el

negocio
 Análisis de TI de los marcos de gestión de servicios de TI
 Capacidades y limitaciones de TI: habilidades y tecnologías
Salidas:
Identificar normas
y normas
 Un marco de gobierno que represente la menor carga organizativa para el
mayor beneficio de la eficiencia, la efectividad, el cumplimiento y la
alineación con el negocio
Mejores prácticas:
 Los marcos son puntos de partida. Proporcionan los conceptos básicos

que luego requieren la elaboración y aplicación a las realidades de la
organización específica.
 Se necesita una comprensión profunda de los factores de la empresa y
de la industria para adaptar el marco a las consideraciones únicas de la
propia empresa.
 Los profesionales de TI tienen conocimientos técnicos que deben ser
considerados al aplicar el marco elegido para que sea alcanzable y
soportable.
Crear política Preguntas clave:
 ¿Cuáles son las áreas en las que la compañía desea explícitamente
[Date]
155
requerir comportamientos deseados?
 ¿Qué procesos deberían tener medidas específicas de desempeño
definidas por la política?
 ¿Qué dice la representación legal sobre la política propuesta?
Entradas:
 Cualquier incumplimiento o cuestiones reglamentarias en las que la

empresa no haya alcanzado las acciones deseadas
 Objetivos de gestión senior para el comportamiento corporativo con
implicaciones claramente entendidas
Salidas:
 Política documentada y comunicada

 Mapeo de la política a los objetivos de control
 Políticas promulgadas en la práctica
Mejores prácticas:
 Para obtener más información acerca de la creación y el uso de políticas,

consulte Función de administración de servicios de políticas de MOF .
 La auditoría proporciona una evaluación basada en la evidencia y
recomendaciones sobre la promulgación de políticas y el ambiente de
control.
Proceso 2: Evaluar, monitorear y controlar el

riesgo
La gestión del riesgo es el intento de TI de abordar el riesgo mientras se alcanzan los objetivos de
gestión. Las organizaciones de TI logran un éxito a largo plazo al manejar el riesgo mediante el uso
efectivo de los controles internos .
Los controles internos son actividades específicas realizadas por personas o sistemas diseñados
para asegurar que se cumplan los objetivos del negocio. El diseño cuidadoso, la documentación y el
funcionamiento de los controles son cruciales en todos los niveles de la organización. Estar "en
control" significa que las posibilidades de experimentar impactos adversos de eventos indeseables
están en niveles aceptables y que la probabilidad de lograr objetivos es satisfactoria. El control
interno está interrelacionado y directamente afectado por las actividades de gobierno de una
organización.
La Figura 5 ilustra las actividades de gestión de riesgos. Es importante entender que el proceso de
gestión de cada riesgo pasa por todas estas actividades al menos una vez y, a menudo, ciclos a
[Date]
156
través de numerosas veces. Debido a que cada riesgo tiene su propia línea de tiempo, múltiples
riesgos podrían estar en cada etapa en cualquier punto dado.
Figura 5. El ciclo generalizado de evaluación, monitoreo y control del riesgo
Actividades: Evaluar, monitorear y controlar el

riesgo
El proceso de identificar riesgos y controles toca todos los aspectos de la empresa. Proporciona
una base para los esfuerzos de cumplimiento de la empresa estableciendo claramente la relación
entre las metas, los factores que podrían impedir el logro de las metas y cómo se están tratando
esos eventos potenciales.
Cada fase del ciclo de vida del servicio de TI tiene un conjunto asociado de riesgos característicos y
actividades correspondientes para gestionarlos:
 En la Fase del Plan, el enfoque se centra en los riesgos relacionados con estrategias
específicas, arquitecturas de información y riesgos en toda la cartera de TI.
 La fase de entrega evalúa el riesgo desde una perspectiva orientada al proyecto, que está
más orientada y limitada en el tiempo.
 La fase de operación se centra en las actividades cotidianas y los riesgos que pueden afectar
a las operaciones fiables.
 Por último, Manage Layer trata de la gestión de riesgos desde un punto de vista general y
enfocado: general en términos de estructuras de gobierno, coordinación organizacional, toma
de decisiones y planes de comunicación; centrada en la gestión del cambio y la configuración
y los riesgos que provienen de la modificación de elementos del entorno de servicios de TI,
así como de los procesos y recursos que forman parte de ese entorno.
[Date]
157
Las categorías de riesgo surgen a lo largo de las diversas fases del ciclo de vida del servicio.
Implican riesgos financieros, operativos, de reputación, de cuota de mercado, de ingresos y
regulatorios, así como otros riesgos que son más específicos para la industria de una organización
en particular (por ejemplo, la asistencia sanitaria) o una actividad que actualmente ocurre (como una
fusión o adquisición) .
Al abordar la gestión de riesgos de una manera que estimule la reflexión sobre las posibles
consecuencias de las actividades, la evaluación de su impacto y, a continuación, adoptar un enfoque
muy explícito para abordar estos riesgos, la TI obtiene una ventaja considerable. Una organización
no puede abordar el riesgo de manera inteligente sin que la TI y el negocio se sienten juntos y
definan tolerancias de riesgo y objetivos de control. Dado que las consecuencias del riesgo se
evalúan en términos de alcanzar los objetivos de negocio, esto ayuda a integrar la TI en las
discusiones de negocios y las compensaciones y elimina después del hecho de apuntar en virtud de
la transparencia que implica la gestión de riesgos.
 Mejorar los procesos para alcanzar los objetivos de gestión

 Identificación del riesgo
 Analizar y priorizar los riesgos
 Identificación de los controles
 Análisis de los controles
 Planificación y programación de la implementación
 Seguimiento e informes de riesgos y controles
 Mandos de mando
 Aprender de los esfuerzos previos y actualizar la base de conocimientos
Tabla 6. Actividades y Consideraciones para la Evaluación, Monitoreo y Control de Riesgos
 La gestión de los riesgos se extiende más allá de la seguridad y la
privacidad de los datos a una variedad de riesgos que pueden afectar el
Suposiciones cumplimiento de los objetivos de la administración (incluyendo, entre otros:
riesgo financiero, riesgo de no cumplir compromisos de desempeño.
Dirección de los Preguntas clave:

objetivos de
gestión  ¿Qué podría ocurrir que pudiera afectar el logro de las metas y objetivos de
la administración?
 ¿Qué se puede hacer para maximizar la capacidad de alcanzar los
objetivos?
 ¿Cuáles son los procesos comerciales sensibles al riesgo que utilizan los
sistemas de TI?
 ¿Cuál es el perfil de tolerancia al riesgo que mejor describe esta empresa?
Entradas:
 Plan estratégico y los objetivos de gestión resultantes

(ver el Business / IT Alignment SMF )
 Condiciones reglamentarias y comerciales
[Date]
158
 Resultados (éxito y fracaso) de la gestión de riesgos hasta la fecha
Salida:
 La tolerancia al riesgo y el enfoque de la gestión de riesgos de la

organización
Mejores prácticas:
 La gestión de riesgos ocurre muchas veces durante cada fase del ciclo de
vida del servicio de TI. La comprensión de los riesgos relativos a los
objetivos de una fase particular establecerá el dominio del riesgo.
 Este dominio de riesgo, combinado con la única tolerancia al riesgo de la
compañía, guiará el enfoque de la gestión de riesgos en esa fase del ciclo
de vida del servicio de TI.
 La tolerancia al riesgo es fluida y cambia con oportunidades y recompensas
potenciales, así como incidentes y posibles sanciones.
Identificar Preguntas clave:

riesgo
 ¿Cómo se clasifican los servicios empresariales en términos de criticidad
empresarial y la naturaleza de los datos utilizados en esos servicios?
 ¿Cuál es la historia del cambio para los sistemas que componen cada
servicio? ¿Qué cambios se planean?
 ¿Cuál es la complejidad del sistema end-to-end (atraviesa múltiples
interfaces, se extiende a los sistemas de socios comerciales, se basa en
datos o servicios fuera del control de la empresa)?
Entradas:
 Misión de la empresa (y unidades de negocio, en su caso)

 Tolerancia al riesgo y enfoque de la gestión de riesgos
 Cartera de TI (consulte el Business / IT Alignment SMF )
 Mapas de servicios de TI (consulte el SMF de Business / IT Alignment )
 Informes de incidentes, eventos de seguridad
 Entorno normativo, eventos de incumplimiento
Salida:
 Informe de caracterización de riesgos de servicios de TI
Mejores prácticas:
 Asegurar que la alta dirección está comprometida con el proceso de gestión

de riesgos.
 Asegurar que los participantes en la gestión de riesgos tengan experiencia
en sistemas de TI y procesos empresariales y comprensión del impacto
potencial para el negocio.
 Revisar los servicios empresariales críticos; evaluar cada uno de los
riesgos estándar y la lluvia de ideas para los posibles riesgos. Haga esto
[Date]
159
con un equipo que represente diferentes perspectivas y áreas de
especialización.
 La identificación del riesgo también debe incluir la notificación al stakeholder
de riesgo. La identificación del riesgo debe repetirse frecuentemente.
 Para obtener más información sobre la identificación de riesgos, consulte
NIST SP 800-30 ( http://csrc.nist.gov/publications/nistpubs/800-30/sp800-
30.pdf ).
Preguntas clave:
 ¿Qué impactos tendrán los riesgos y amenazas (situaciones o estados que

podrían causar daño) en la organización en su conjunto?
 ¿Cuáles son los impactos probables de las amenazas a objetivos de gestión
específicos y procesos de negocio asociados?
 ¿Se pueden descomponer las amenazas y los impactos en aquellos que
podrían perjudicar el rendimiento del servicio de TI pero no comprometer los
datos?
 ¿Cuáles son las vulnerabilidades conocidas en los sistemas que componen
los servicios de TI?
 ¿Cuáles son las amenazas para los sistemas individuales?
Entradas:
 Caracterización de los riesgos de los servicios de TI

 Amenazas
 Vulnerabilidades
Analizar y
priorizar los
Salida:
riesgos
Mejores prácticas:
 Transformar las estimaciones o datos sobre los riesgos específicos que se

desarrollaron durante la identificación del riesgo en una forma que puede
utilizarse para tomar decisiones sobre la priorización.
 Mida el riesgo en términos de probabilidad multiplicado por el impacto y
utilice las puntuaciones resultantes para ayudar a priorizar.
 Priorizar los riesgos para que los más importantes se puedan abordar con
recursos suficientes.
 Haga una lluvia de ideas para posibles riesgos insospechados. Si se
identifican algunos, tratar de evaluar si su impacto potencial (incluso si hay
una baja probabilidad) aún merece atención.
 Ver Recursos de mitigación de vulnerabilidades y amenazas de Microsoft a
http://www.microsoft.com/technet/security/learning/threats/all/default.mspx .
Identificar los Preguntas clave:

controles
 Sobre la base de amenazas y vulnerabilidades para la compañía, ¿cuáles
son los mejores puntos de control y actividades para mitigar esos riesgos?
[Date]
160
 ¿Qué vulnerabilidades de confidencialidad, integridad y acceso a los datos
deben abordarse con controles explícitos?
Entradas:
 Listados de amenazas y vulnerabilidades con calificaciones

 Lista de controles primarios y controles de compensación (que usualmente
operan para detectar problemas después del hecho)
 Entrevistas con el personal responsable de los objetivos de negocio y
procesos asociados
 Entrevistas con personal en áreas de control de TI
 Cuestiones y informes de auditoría
Salida:
 Plan que asigna controles a los servicios de TI ya los procesos

empresariales
Mejores prácticas:
 Los controles trabajan juntos para crear un entorno de control. Al evaluar

un solo control, tenga en cuenta la constelación de controles relacionados, y
considere cómo un control podría compensar a otro.
Analizar los Preguntas clave:

controles
 ¿Qué objetivos empresariales están siendo abordados por los controles
identificados?
 ¿Qué evidencia demuestra que los controles están funcionando como se
desea?
 ¿Qué requiere la auditoría en términos del tipo de evidencia y su retención?
Entradas:
 Informes de auditoría
 Lista de controles existentes
 Entrevistas con personal en cada área de control
 Plan que asigna controles a los servicios de TI ya los procesos
empresariales
Salida:
Mejores prácticas:
 Los informes de auditoría proporcionan un análisis independiente de los

controles y por lo general tienen recomendaciones para mejorar el entorno
de control.
 Un foco prioritario debe estar en controles fundamentales que deben
[Date]
161
funcionar correctamente para que otros controles puedan depender de ellos
(por ejemplo, controles para acceso a datos).
 Controles de diseño con procesos de recolección de evidencia construidos
para hacer más eficientes y eficaces la auditoría y otras pruebas de control.
Las pruebas de control requieren la prueba (en forma de evidencia) de que
el control está en su lugar y funciona como se esperaba.
Preguntas clave:
 De la lista de controles planeados, ¿qué controles no están en su lugar?

 ¿Cuál es la prioridad de desarrollo para los controles que no están en su
lugar?
Entradas:

Planificar y Salidas:
programar la
implementación  Plan de desarrollo de riesgos y control
 Mitigación identificada
 Lista de solicitudes de cambio relacionadas con el control
Mejores prácticas:
 Utilice la información obtenida del análisis de riesgo para ayudar a formular

estrategias, planes, peticiones de cambio y acciones.
 Utilizar los procesos de gestión del cambio para garantizar que los planes
de riesgo se aprueben e incorporen a los procesos e infraestructuras
habituales del día a día. Consulte el SMF Cambiar y configurar MOF .
Rastrear y Preguntas clave:

reportar riesgos
y controles  ¿Cuál es el estado de los riesgos y los controles?
Entradas:
 Monitoreo del servicio de TI

 Evidencia retenida de la actividad de control
 Informes de estado para proyectos de desarrollo de control
Salidas:
Mejores prácticas:
 Monitorear el estado de los riesgos específicos y el progreso en sus
[Date]
162
respectivos planes de acción.
 Monitorear la probabilidad, el impacto, la exposición y otras medidas de
riesgo para cambios que podrían alterar los planes de prioridad o riesgo (y,
en última instancia, la disponibilidad del servicio de TI relacionado).
 Asegúrese de que el personal de operaciones, el gerente de servicio y otros
interesados conozcan el estado de los principales riesgos y los planes para
manejarlos.
Preguntas clave:
 ¿Funcionan los controles como se esperaba?

 ¿Están los niveles de tolerancia al riesgo y los disparadores de acción
funcionando según sea necesario?
 ¿Están los planes de acción de gestión de riesgos siguiendo los pasos
esperados?
Entradas:
 Reporte de cumplimiento de SLA
Salidas:
Operar
controles
 Impactos en el nivel de servicio
Mejores prácticas:
 Ejecutar planes de acción de riesgo y evaluar su estado a través de

informes de riesgo.
 Inicie solicitudes de control de cambios cuando los cambios en el estado de
riesgo o los planes de riesgo puedan afectar la disponibilidad del servicio o
SLA.
 Recoja y almacene evidencia de que los controles están operando. Esto
puede tomar muchas formas (por ejemplo, registros del sistema,
documentación que está bajo control de cambio o firmas de individuos
autorizados).
 Notificar a las partes interesadas los cambios en los servicios que abordan
los problemas de riesgo.
Aprender de los Preguntas clave:

esfuerzos
anteriores y  ¿Está la administración satisfecha con la forma en que los controles se
actualizar la ocupan de los riesgos conocidos?
base de  ¿Están ajustados los niveles de tolerancia al riesgo y las acciones previstas
conocimientos cuando las condiciones exceden los niveles aceptables?
 ¿Se han identificado nuevos riesgos?
[Date]
163
 ¿Las auditorías indican un entorno de control efectivo?
Entradas:

 Análisis coste / beneficio de los controles
Salidas:
 Reporte de riesgos al menos mensualmente

 Dashboard de riesgo si está disponible
 Base de conocimientos de riesgo actualizada
 Resultados reportados a la MR de Salud Operacional
Mejores prácticas:
 La aplicación de controles es un ejercicio costo / beneficio; debe reflejar la

evaluación de la administración del objetivo del negocio, el riesgo
identificado, y el beneficio de desarrollar y aplicar el control. El análisis costo
/ beneficio debe reflejar la voluntad de la empresa de asumir riesgos,
reconociendo que existe, pero se permitirá que ocurra su impacto potencial
(en lugar de mitigar el riesgo, lo que implica intentar reducir el impacto o la
probabilidad del riesgo ).
 El aprendizaje del riesgo formaliza las lecciones aprendidas y utiliza
herramientas para capturar, categorizar e indexar ese conocimiento en una
forma reutilizable que se puede compartir con otros en la organización.
Proceso 3: Cumplimiento de las Directivas

El cumplimiento es una aplicación de la gestión de riesgos que garantiza la conformidad de TI con

las políticas de la empresa, las regulaciones gubernamentales y las leyes específicas de la industria.
Algunas de las leyes de cumplimiento más conocidas y sus funciones se incluyen en la siguiente
tabla.
Tabla 7. Ejemplos de Leyes de Cumplimiento y Sus Funciones
Ley de cumplimiento Función

Normas y controles mejorados para todas las juntas de
La Ley Sarbanes-Oxley (SOX) empresas públicas y firmas de contabilidad pública en los
Estados Unidos
Ley de Portabilidad y
Normas nacionales para las transacciones de asistencia
Responsabilidad del Seguro de Salud
sanitaria electrónica
(HIPAA)
Basilea II Norma internacional para bancos
[Date]
164
Cada vez más, las actividades de cumplimiento requieren mayor diligencia y responsabilidad de
parte de los profesionales de TI. Por ejemplo, muchas grandes corporaciones han automatizado
significativamente sus sistemas de gestión financiera, lo que ha dado lugar a la automatización de
los controles internos del negocio. Estos controles de aplicación forman parte del entorno de
cumplimiento; cuando se automatizan, se convierten en parte del entorno de TI. Los profesionales
de TI también deben ser conscientes de los controles informáticos generales (por ejemplo, la
separación de entornos de desarrollo y de prueba), que se definen como aquellos procesos,
actividades y configuraciones que se aplican a través de múltiples componentes de infraestructura
para garantizar que la tecnología funciona como se esperaba .
Informes de evidencia y aseguramiento

Aseguramiento es el proceso de proporcionar a la dirección ejecutiva una indicación de lo bien que
la organización cumple con sus metas y objetivos. Los informes de garantía son responsabilidad del
departamento de auditoría, que proporciona una evaluación imparcial. Esta información se basa en
datos que demuestran el efecto de los controles puestos en marcha para lograr resultados de una
manera intencionada. La evidencia es el término usado para describir estos datos, y la prueba es el
proceso de ejercer los controles para generar evidencia. También puede referirse a la evaluación de
la evidencia generada.
Esto puede ser confuso para los profesionales de TI que suelen utilizar el término "pruebas" para
referirse a los procesos de aseguramiento de calidad (QA) utilizados en el desarrollo de software y el
despliegue del sistema. Guardar los datos reales utilizados para realizar las pruebas (la evidencia)
no es una parte común de la metodología de pruebas del profesional de TI. Sin embargo, los
auditores quieren que las pruebas recopiladas durante un período de tiempo suficientemente largo
para poder formarse una opinión sobre la eficacia y la eficiencia de los controles. Otro punto de
confusión entre las pruebas de aseguramiento y el uso del término "pruebas" por parte del
profesional de TI es que las pruebas de aseguramiento generalmente se centran en controles y
procesos en el entorno de producción. Se centra en lo que realmente está sucediendo en la
experiencia del mundo real de la organización, no en el entorno de prueba aislado, donde los
problemas funcionales pueden ser aislados y resueltos.
Por último, los informes de aseguramiento pueden obtenerse de varias fuentes (por ejemplo,
auditorías de cumplimiento, auditorías de seguridad o auditoría relacionadas con obligaciones
contractuales), y los profesionales de TI pueden encontrar que se les pide pruebas muy similares en
numerosas ocasiones. Al tomar conciencia de las actividades de aseguramiento en su organización,
explorar los requisitos de retención de evidencia y comprender el uso de la evidencia requerida, los
profesionales de TI pueden mejorar la eficiencia y reducir los aspectos perturbadores del proceso de
aseguramiento.
[Date]
165
Figura 6. Cumplir con las directivas
Actividades: Cumplir con las Directivas

El proceso de cumplimiento es iterativo; La TI debe monitorear continuamente el medio ambiente,
adaptarse a los cambios normativos y responder a las directivas de gestión. Los profesionales de TI
deben tener cuidado de mirar a la directiva de la empresa para las directivas, en lugar de interpretar
las regulaciones sin aportaciones de otras áreas de la empresa. Los propios reglamentos deben ser
evaluados por diversos grupos dentro de la empresa (por ejemplo, jurídico, de recursos humanos y
de finanzas), que luego determinará la posición de la compañía con respecto a cualquier regulación
en particular.
[Date]
166
El profesional de TI debe traer activamente a la atención de la empresa las regulaciones relevantes
para TI. Estas regulaciones pueden entonces ser evaluadas, la compañía puede determinar su
posición relativa a cada una, y las políticas y las directivas apropiadas se pueden construir para guiar
decisiones y actividades. Con esta vía establecida, el auditor podrá tomar los objetivos de gestión-
ahora en forma de directrices- y verificar el cumplimiento de dichas directivas.
 Identificación de políticas, leyes, reglamentos y contratos

 Selección de políticas, leyes, reglamentos y contratos
 Evaluación del estado de cumplimiento actual
 Establecimiento del estado de cumplimiento futuro
 Creación de un plan de cumplimiento
 Mantener el cumplimiento
 Auditoría del cumplimiento
Cuadro 8. Actividades y consideraciones para el cumplimiento de las directivas
 La organización quiere asegurarse de que las directivas son seguidas,
estén o no sujetas a requisitos formales de gobernabilidad.
 TI puede tener servicios que llevan requisitos de desempeño con
sanciones por incumplimiento.
Suposiciones
 La organización ha estado sujeta a hallazgos de auditoría que indican
que su ambiente de control es ineficaz o ineficiente o que han resultado
en que la compañía está fuera de cumplimiento.
Identificar políticas, Preguntas clave:

contratos  ¿Qué leyes y reglamentos (locales, nacionales o globales) se aplican a
la empresa?
 ¿Qué entidades reguladoras aplican a las actividades de la empresa?
 ¿Qué objetivos requieren que la política demuestre la intención de la
administración y se asegure de que la actividad deseada se pueda
hacer cumplir?
 ¿Qué compromisos de servicio de TI conllevan requisitos de
cumplimiento de cumplimiento?
Entradas:
 Leyes y regulaciones a nivel mundial, nacional y local

 Requisitos de la entidad gobernante
 Directivas de gestión
 Revisión legal de las necesidades de cumplimiento
 Requisitos de rendimiento de los contratos de nivel de servicio de TI
Salidas:
 Las leyes y reglamentos identificados y las directivas de la

organización para el cumplimiento
[Date]
167
 Directivas de cumplimiento identificadas que apoyan la intención de la
organización de cumplir con la estrategia
Mejores prácticas:
 El cumplimiento tiene múltiples facetas, pero las consideraciones

principales se relacionan con el cumplimiento de los objetivos de
gestión, las directivas de la empresa y los requisitos legales. Además,
los servicios deben desempeñarse de manera que cumpla con los
acuerdos y contratos. El monitoreo y las métricas pueden proporcionar
información para ambas áreas de cumplimiento.
Preguntas clave:
 ¿El negocio ha revisado y determinado qué leyes y regulaciones está

claramente sujeto a la compañía?
 ¿Existe un marco de control que cubra efectivamente las leyes y
reglamentos a los que está sujeto el negocio?
Entradas:
 Lista revisada de leyes y reglamentos e interpretaciones

 Tolerancia al riesgo de la empresa
 Informes de auditoría anteriores
 Objetivos de control potencial de los marcos relevantes
Seleccione políticas,
Salida:
contratos
 Lista de leyes, reglamentos y objetivos de desempeño y control a ser
abordados por la política de la compañía
Mejores prácticas:
 La cultura de una organización y la forma en que trabaja para alcanzar

los objetivos estratégicos afectarán en gran medida las áreas
seleccionadas para las actividades de cumplimiento. Equilibrar los
requisitos para el cumplimiento y la cultura requiere que las decisiones
se tomen abiertamente con las partes interesadas apropiadas.
 Incluir profesionales legales y de auditoría en la discusión.
Evaluar el estado de Preguntas clave:

cumplimiento actual
 ¿Cuál es el estado actual del cumplimiento de las leyes, reglamentos y
directivas pertinentes?
 ¿Cuál es el estado de cumplimiento de los objetivos de desempeño?
 ¿Cuál es el historial de incidentes de incumplimiento y hay una
tendencia identificable?
Entradas:
[Date]
168
 Evaluaciones de riesgos para sistemas y procesos de negocio (ver
"Proceso 2: Evaluar, monitorear y controlar el riesgo")
 Políticas y directivas existentes
 Informes de cumplimiento, actividad de denunciante
 Cumplimiento del rendimiento para contratos y acuerdos de servicios
de TI
Salida:
 Estado de cumplimiento salud (informe o salpicadero)
Mejores prácticas:
 Cumplimiento de la salud puede ser volátil. Uno de los objetivos de un

vigoroso programa de cumplimiento es disminuir la volatilidad a través
del monitoreo activo de los controles y la detección de tendencias. Un
panel de control de cumplimiento que se actualiza frecuentemente con
datos de monitoreo recientes mantendrá informados a los gerentes
superiores, pero no cargados con los informes de cumplimiento. Un
tablero de instrumentos debe apoyar una investigación más detallada
sobre los detalles de los incidentes de cumplimiento.
Establecer futuro Preguntas clave:

estado de
cumplimiento  ¿En qué áreas hay incidentes recurrentes de incumplimiento?
 ¿Qué riesgos de cumplimiento están fuera de la tolerancia al riesgo de
la compañía?
 ¿Se han incurrido en sanciones por servicios de TI que no cumplen
con los requisitos de desempeño?
Entradas:
 Estado actual de cumplimiento

 Cambios en la cartera de TI y catálogo de servicios
 Cambios en el entorno regulatorio relevante para el negocio
 Tendencias regulatorias y normas legales que pueden afectar el
negocio
 Cambios en la tolerancia comercial del riesgo
 Modificaciones, reducciones y adiciones potenciales al ambiente de
control
Salida:
Mejores prácticas:
 Considere el incumplimiento desde varias perspectivas: ¿Son

inadecuados o confusos los procedimientos y la orientación
[Date]
169
relacionados? ¿Es la política demasiado pesada y pesada, que podría
resultar en un conflicto entre el desempeño y el cumplimiento? ¿Es
adecuada la capacitación?
 Consulte con un abogado antes de finalizar la política basada en la
regulación. Es importante tener una interpretación de cómo la
compañía debe cumplir con las regulaciones que incluye una
comprensión más amplia del precedente legal y de la madurez de
regulaciones.
Preguntas clave:
 ¿De qué manera se diferenciará la empresa conforme (el estado "a

ser") de la empresa actual?
 ¿Qué no funciona de manera efectiva en el programa de cumplimiento
actual?
 ¿Qué requerimientos de recursos, capacitación y cambios en las
políticas, procesos y sistemas se requerirán para ser compatibles?
 ¿Es necesario abordar los contratos de servicios de TI con cláusulas
de rendimiento?
Entradas:

 Revisión por parte de la alta gerencia del estado "futuro", objetivos
estratégicos y objetivos comerciales
 Acuerdo de que la empresa identificada "a ser" y los objetivos
estratégicos son compatibles
Crear plan de  Planes de proyecto para cambiar servicios de TI identificados para
cumplimiento lograr un mejor cumplimiento de cumplimiento
Salida:
 Proyecto de plan de cumplimiento propuesto aprobado por todos los

interesados
Mejores prácticas:
 Preste atención a la cultura de cumplimiento en la empresa. Si la

empresa se encuentra en una industria fuertemente regulada, es
probable que la expectativa de que los requisitos de cumplimiento son
parte integrante de la actividad cotidiana. Por otro lado, si la industria
es un cambio acelerado impulsado por el crecimiento, el cumplimiento
podría ser visto como una carga o un "impuesto" que debe evitarse.
Los planes futuros de cumplimiento deben tener esto en cuenta y
mover la cultura de cumplimiento en la dirección deseada en base a su
carácter actual.
Mantener el Preguntas clave:

cumplimiento
[Date]
170
 ¿Qué problemas de incumplimiento están ocurriendo?
 ¿Hay formas de reducir los costos de cumplimiento sin aumentar el
riesgo?
Entradas:
 Plan de cumplimiento
 Informes de gestión y control de servicios
(consulte el SMF de supervisión y control de servicios )
 Informes de auditoría, monitoreo de control
 Riesgo y niveles de tolerancia de cumplimiento
Salidas:
 Informes de cumplimiento
 Actualizaciones del panel de control de cumplimiento
Mejores prácticas:
 Los problemas de cumplimiento a menudo contienen información

confidencial. Ciertas personas deben ver ciertas partes de esta
información; otras personas otra información. Múltiples vistas de la
información, junto con el acceso basado en roles a informes y / o
cuadros de mando, ayudarán a resolver los problemas de privacidad.
 El entorno de cumplimiento es dinámico: requiere revisiones
frecuentes de los controles aplicables. Estas revisiones de control
deben incluir un análisis costo / beneficio que incluya las dimensiones
del riesgo, así como la eficacia operativa.
Cumplimiento de Preguntas clave:

auditorías
 ¿Qué está cambiando en términos de leyes y reglamentos pertinentes
o de nuevos requisitos a los que la empresa puede estar sujeta?
 ¿Es aceptable para la alta dirección el estado actual de cumplimiento?
 ¿Hay evidencia suficiente de actividad de control, pruebas y
mantenimiento del cumplimiento del control mantenido actual y
debidamente almacenado?
Entradas:
 Revisiones legales y actualizaciones de interpretaciones regulatorias

 Informando y entrevistando entrevistas con gerentes senior sobre el
estado de cumplimiento
Salidas:
 Resultados de la auditoría de cumplimiento
[Date]
171
 Plan de cumplimiento actualizado
Mejores prácticas:
 Los reglamentos pueden tener claras consecuencias por

incumplimiento, como multas y / o penas de prisión, pero a menudo
tienen requisitos muy generales. Representantes legales y de auditoría
pueden ayudar a aclarar lo que realmente necesita suceder para que la
TI sea compatible.
 Asegúrese de que la evidencia apropiada y suficiente de la actividad
de control se almacena para una evaluación posterior. Trabajar con los
auditores internos y externos para entender los requisitos para la
recolección y almacenamiento de evidencia e iniciar esa conversación
meses antes de cualquier actividad de auditoría planificada en esa
área.
 Asegurar el uso de acuerdos de nivel de servicio (SLA) para ayudar a
definir la calidad de los servicios de TI y establecer directrices para el
rendimiento y los requisitos de cumplimiento. Para obtener más
información acerca de los acuerdos de nivel de servicio, consulte el
Business / IT Alignment SMF .
Conclusión
El SMF de Gobierno, Riesgo y Cumplimiento proporciona orientación para integrar las actividades
de GRC en el contexto de procesos y actividades a lo largo del ciclo de vida del servicio de TI. Esta
integración hace uso de la gestión de riesgos y controles internos presentes en cada SMF para
proporcionar formas consistentes de tomar decisiones y gestionar las actividades de TI.
Los principales procesos descritos en el GRC SMF son:
 Establecimiento de gobierno de TI.

 Cumplimiento de las directivas.
Realimentación
[Date]
172

3-Entregar MOF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

3-Entregar MOF

Cargado por

Copyright:

Formatos disponibles

Entregar

Publicado: 25 de abril de 2008

Contenido de la fase de entrega

Descripción de la fase de entrega

Descripción general de la fase de entrega

Figura 1. La fase Deliver dentro del ciclo de vida del servicio de TI

Objetivos de la fase de entrega

Específicamente, eso significa asegurar que el equipo del proyecto:

Espectáculo: Heredado Protegido

There are no mem

Figura 2. Flujo de trabajo de la fase de entrega

Funciones de administración de servicios

Producto / Propósito Resultados

Entregable: Documento del plan del proyecto  El diseño y las

 Un diseño final que cumpla

Estabilizar Entregable : Solución probada y estable  Se resuelven todos los

 Una solución estable

Cada una de estas SMFs se explica en detalle en su propia guía:

 Función de administración de servicios de Envision

Revisión de Gestión (MRs) para la Fase

Revisión de la gestión aprobada por el plan de proyecto

 Un conjunto de instrucciones para los desarrolladores sobre qué construir

El enfoque de gobernabilidad adoptado por la organización ayudará a determinar a los participantes

 El equipo del proyecto, que puede incluir:

Tabla 2. Componentes del Plan de Proyecto Revisión de Gestión Aprobada

Revisión de la Administración de Readiness de Liberación

 La operabilidad y la capacidad de soportar el propio lanzamiento

El propósito de la Readiness de liberación MR es confirmar o certificar estos elementos. Listo se

Los participantes en la Preparación para la Liberación MR incluyen obviamente representantes del

Tabla 3. Dimensiones de la revisión de la gestión de la preparación de la liberación

Análisis Decisiones Salidas

La prontitud de liberación MR resulta en una decisión ir / no ir sobre si implementar la liberación.

Tabla 4. Indicadores Go / No-Go

Indicadores de "Go" Indicadores "No-Go"

 El personal de apoyo ya está

Planes de  Se ha comunicado el proceso  Un punto único de fallo o falla fatal

Si la decisión es ir, la liberación se mueve a la planificación de lanzamiento y los preparativos como

La revisión de preparación de liberación La aprobación de MR significa que el proyecto está listo

Espectáculo: Heredado Protegido

Flujo de trabajo de la fase de entrega

Figura 2. Flujo de trabajo de la fase de entrega

Funciones de administración de servicios

Tabla 1. Entrega de Fase SMFs

Producto / Propósito Resultados

Entregable: Documento del plan del proyecto  El diseño y las

Construir Entregable: Solución desarrollada  Un diseño final que cumpla

Entregable : Solución probada y estable

 Una solución estable

Cada una de estas SMFs se explica en detalle en su propia guía:

 Función de administración de servicios de Envision

Revisión de Gestión (MRs) para la Fase

Revisión de la gestión aprobada por el plan de proyecto

 Un conjunto de instrucciones para los desarrolladores sobre qué construir

El enfoque de gobernabilidad adoptado por la organización ayudará a determinar a los participantes

Tabla 2. Componentes del Plan de Proyecto Revisión de Gestión Aprobada

Análisis Decisiones Salidas

Revisión de la Administración de Readiness de Liberación

 La operabilidad y la capacidad de soportar el propio lanzamiento

El propósito de la Readiness de liberación MR es confirmar o certificar estos elementos. Listo se

Los participantes en la Preparación para la Liberación MR incluyen obviamente representantes del

Tabla 3. Dimensiones de la revisión de la gestión de la preparación de la liberación

Tabla 4. Indicadores Go / No-Go

Indicadores de "Go" Indicadores "No-Go"